DETAILED ACTION
Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
2. This Office Action is in response to the application filed on 01/08/2026. Claims 1 and through 20 are presently pending and are presented for examination.
3. In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Response to Arguments
4. Applicant’s arguments with respect to claims have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Claim Rejections - 35 USC § 103
5. 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-7, 10-18, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Jagadeesan (US 2022/0417058 A1) in view of Pfaff (US 2017/0034082 A1).
For claim 1 Jagadeesan teaches a computing device (Fig. 2 “network device (VTEP) 50”) comprising:
a network interface controller (NIC) (Fig. 2 “network interface 56 (NIC 56)”); and
processing circuitry having access to storage media encoded with instructions, the processing circuitry (Fig. 2 “CPU 60 has access to MEM 62”) configured to:
execute a main packet processor and a plurality of tenant-specific packet processors, wherein each of the plurality of tenant-specific packet processors is associated with a corresponding virtual extensible local area network (VXLAN) tunnel endpoint (VTEP) (see Fig. 2 “main packet processor 54 and plurality of VRF processors 66” , paragraph 8 “VRFs mapped VTEPs, and paragraph 11 “VTEPs are assigned VXLAN identifiers (specific)”);
receive, by a main packet processor (Fig. 2 “packet processor 54”), a packet from the NIC (Fig. 2 “packet processor 54 receives a packet from NIC 56” and paragraph 5 “the packet processor (main packet processor) receives a packet destined to the remote VRF”);
send, by the main packet processor, based on a VTEP indicated by the packet, the packet to the tenant-specific packet processor of the plurality of tenant-specific packet processors associated with the VTEP (Fig. 2 “packet processor 54 receives a packet from NIC 56 and sends the received packet to a VRF instance (tenant-specific processor of the plurality of VRF instance (tenant-specific processor)”, Fig. 3A-3B “received packet by the main packet processor is looked up according to the packet destined VRF with D-VNI and then the received packet is routed to the destination VRF”, paragraph 5 “the packet processor receives a packet destined to the remote VRF, looks up the packet in the one or more route entries in the local VRF instance to retrieve the unique egress RIP, translates the unique egress RIP into the imported D-VNI, encapsulates the packet with the imported D-VNI, and forwards the encapsulated packet in accordance with the unique egress RIP (workload)”, and paragraph 120 “some elements of network device (VTEP) 50, such as packet processor 54 may be implemented in hardware, e.g., in one or more Application-Specific Integrated Circuits
(ASICs) or FPGAs”);
send, by the tenant-specific packet processor, at least a portion of the packet to a workload (Fig. 2 “packet processor 54 receives a packet from NIC 56”, Fig. 3A-3B , and paragraph 5 “the packet processor 54 receives a packet destined to the remote VRF, looks up the packet in the one or more route entries in the local VRF instance to retrieve the unique egress RIP, translates the unique egress RIP into the imported D-VNI, encapsulates the packet with the imported D-VNI, and forwards the encapsulated packet in accordance with the unique egress RIP (workload)”); and
process, by the workload, the at least a portion of the packet (Fig. 2 “packet processor 54 receives a packet from NIC 56” and Fig. 3A-3B , and paragraph 5 “the packet processor 54 receives a packet destined to the remote VRF, looks up the packet in the one or more route entries in the local VRF instance to retrieve the unique egress RIP, translates the unique egress RIP into the imported D-VNI, encapsulates the packet with the imported D-VNI, and forwards the encapsulated packet in accordance with the unique egress RIP (workload)”).
Jagadeesan does not explicitly teach the tenant-specific packet processor being different from main packet processor.
However, Pfaff teaches that in Fig. 6 that a packet receives by packet processor which is in turn to an action processor (tenant-specific packet processor) and the action processor sends the packet to virtual machine (workload) to be processed (Pfaff: Fig. 6). In addition, Pfaff teaches the tenant (i.e., the owner of the VM) can choose which applications to operate on top of the guest operating system… host operating system isolates the containers for different tenants and therefore provides operating-system level segregation of the different groups of applications that operate within different containers (tenant-specific processor) (Pfaff: paragraph 117).
Thus, it would have been obvious to a person of ordinary skill to use the teachings of Pfaff in the network device of Jagadeesan in order to pass the received packet by the packet processor to classifier to be classified for a specific action processor (e.g., tenant-specific packet processor) and further the host operating system isolates the containers of different tenants (Pfaff: Fig. 6 and paragraph 117).
For claim 12 Jagadeesan in view of Pfaff teaches a computing system comprising:
a first computing device configured with a first virtual extensible local area network (VXLAN) tunnel endpoint (VTEP) for a tenant (Jagadeesan: Fig. 2 and as discussed in claim 1), the first VTEP having an interface configured with a virtual network address; and
a second computing device configured with a second VTEP for the tenant, the second VTEP having an interface configured with the virtual network address (Jagadeesan: Fig. 2 and as discussed in claim 1).
For claim 13 Jagadeesan in view of Pfaff teaches the computing system, wherein the first computing device comprises:
a main packet processor configured to obtain a packet (as discussed in claim 1),
wherein the main packet processor is further configured to send, based on the packet having a destination virtual network address that matches the virtual network address configured for the interface of the first VTEP, the packet to a tenant-specific packet processor of a plurality of tenant-specific packet processors associated with the first VTEP, wherein each of the plurality of tenant-specific packet processors is associated with a corresponding VTEP (as discussed in claim 1);
the tenant-specific packet processor, configured to send at least a portion of the packet to a workload (as discussed in claim 1); and
the workload, configured to process the at least a portion of the packet (as discussed in claim 1).
For claim 14 Jagadeesan in view of Pfaff teaches a method (as discussed in claim 1) comprising:
executing, by a computing device, a main packet processor and a plurality of tenant- specific packet processors, wherein each of the plurality of tenant-specific packet processors is associated with a corresponding virtual extensible local area network (VXLAN) tunnel endpoint (VTEP) (as discussed in claim 1);
receiving, by the main packet processor of a packet from a network interface controller (NIC) of the computing device (as discussed in claim 1);
sending, by the main packet processor, based on a VTEP indicated by the packet, the packet to the tenant-specific packet processor of the plurality of tenant-specific packet processors associated with the VTEP (as discussed in claim 1);
sending, by the tenant-specific packet processor, at least a portion of the packet to a workload of the computing device (as discussed in claim 1); and
processing, by the workload, the at least a portion of the packet (as discussed in claim 1).
For claim 2 Jagadeesan in view of Pfaff teaches the computing device, wherein the main packet processor processes the packet with a first network stack (Pfaff: Fig. 6 “packet processor”), and
wherein the tenant-specific packet processor processes the packet with a different, second network stack (Pfaff: Fig. 6 “action processor”).
For claim 3 Jagadeesan in view of Pfaff teaches the computing device (as discussed in claim 1), wherein the packet comprises a first packet (Jagadeesan: paragraph 5 “packets” and as discussed in claim 1),
wherein the tenant-specific packet processor comprises a first tenant-specific packet processor (Pfaff: paragraph 117 “tenant (i.e., the owner of the VM)…different tenants” and as discussed in claim 1),
wherein the VTEP comprises a first VTEP (Jagadeesan: paragraph 5 “VTEP” and as discussed in claim 1),
wherein the workload comprises a first workload associated with a first tenant (as discussed in claim 1), and
wherein the processing circuitry (as discussed in claim 1) is configured to:
receive, by the main packet processor, a second packet from the NIC (as discussed in claim 1);
send, by the main packet processor, based on a second VTEP indicated by the second packet, the second packet to a second tenant-specific packet processor of the plurality of tenant-specific packet processors associated with the second VTEP (as discussed in claim 1);
send, by the second tenant-specific packet processor, at least a portion of the second packet to a second workload associated with a second tenant (as discussed in claim 1); and
process, by the second workload, the at least a portion of the second packet (as discussed in claim 1).
For claim 4 Jagadeesan in view of Pfaff teaches the computing device of claim 3, wherein the first VTEP is associated with a first virtual network address (Jagadeesan: paragraph 104 “VTEP IP address” and as discussed in claim 1), and
wherein the second VTEP is associated with a different, second virtual network address (Jagadeesan: paragraph 104 “VTEP IP address” and as discussed in claim 1).
For claim 5 Jagadeesan in view of Pfaff teaches the computing device of claim 3, wherein the main packet processor processes the packet with a first network stack (Pfaff: paragraph 60 “network stack”),
wherein the first tenant-specific packet processor processes the first packet and the second packet with a different, second network stack (Pfaff: paragraph 60 “network stack”), and
wherein the second tenant-specific packet processor processes the second packet with a different, third network stack (Pfaff: paragraph 60 “network stack”).
For claim 6 Jagadeesan in view of Pfaff teaches the computing device, wherein the VTEP is associated with a virtual network address (Jagadeesan: paragraph 104 “VTEP IP address” and as discussed in claim 1), and
wherein the main packet processor sends the packet to the tenant-specific packet processor associated with the VTEP based on a destination network address of the packet matching the virtual network address associated with the VTEP (Jagadeesan: paragraph 104 “VTEP IP address” and as discussed in claim 1).
For claim 7 Jagadeesan in view of Pfaff teaches the computing device, wherein the workload implements a tenant control plane for a tenant associated with the VTEP (Pfaff: Fig. 6 “bridge 650”).
For claim 10 Jagadeesan in view of Pfaff teaches the computing device, wherein the main packet processor and the tenant-specific packet processor are configured with a shared memory interface (Jagadeesan: Fig. 2 “MEM 62”),
wherein the main packet processor is configured to send, via the shared memory interface, the packet to a tenant-specific packet processor associated with the VTEP (Jagadeesan: Fig. 2 “packet processor 54 sends received packet via MEM 62 to CPU”).
For claim 11 Jagadeesan in view of Pfaff teaches the computing device, wherein the main packet processor and the tenant-specific packet processor execute in separate namespaces (Jagadeesan: Fig. 2 “packet processor namespace and CPU namespace”).
For claim 15 Jagadeesan in view of Pfaff teaches the method, wherein the main packet processor processes the packet with a first network stack, and wherein the tenant-specific packet processor processes the packet with a different, second network stack (as discussed in claim 2).
For claim 16 Jagadeesan in view of Pfaff teaches the method, wherein the packet comprises a first packet (as discussed in claim 3),
wherein the tenant-specific packet processor comprises a first tenant-specific packet processor (as discussed in claim 3),
wherein the VTEP comprises a first VTEP (as discussed in claim 3),
wherein the workload comprises a first workload associated with a first tenant (as discussed in claim 3), the method further comprising:
receiving, by a main packet processor, a second packet from the NIC (as discussed in claim 3);
sending, by the main packet processor, based on a second VTEP indicated by the second packet, the second packet to a second tenant-specific packet processor of the plurality of tenant-specific packet processors associated with the second VTEP (as discussed in claim 3);
sending, by the second tenant-specific packet processor, at least a portion of the second packet to a second workload associated with a second tenant (as discussed in claim 3); and
processing, by the second workload, the at least a portion of the second packet (as discussed in claim 3).
For claim 17 Jagadeesan in view of Pfaff teaches the method claim 16, wherein the first VTEP is associated with a first virtual network address, and wherein the second VTEP is associated with a different, second virtual network address (as discussed in claim 4).
For claim 18 Jagadeesan in view of Pfaff teaches the method, wherein the VTEP is associated with a virtual network address (as discussed in claim 6), and
sending, by the main packet processor, the packet to the tenant-specific packet processor associated with the VTEP based on a destination network address of the packet matching the virtual network address associated with the VTEP (as discussed in claim 6).
For claim 20 Jagadeesan in view of Pfaff teaches the method, wherein the main packet processor and the tenant-specific packet processor execute in separate namespaces (as discussed in claim 11).
6. Claims 1-7, 10-18, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Jagadeesan (US 2022/0417058 A1) in view of Pfaff (US 2017/0034082 A1) and further in view of Kwong et al. (US 2016/0055042 A1).
For claims 8-9 and 19 Jagadeesan in view of Pfaff teaches the computing device (Jagadeesan: Fig. 2 “network device 50”), wherein:
the storage media is configured to store a flood list for a tenant associated with the VTEP, the flood list storing an entry specifying an underlay network address for another computing device,
the packet comprises a first packet (Jagadeesan: Fig. 3A “input packet ”), and
the processing circuitry (Jagadeesan: Fig. 2 “CPU 60”) is configured to:
receive, by the tenant-specific packet processor, an original packet from the workload (Jagadeesan: Fig. 3A “originated packet”);
generate a second packet (Jagadeesan: Fig. 3A “output packet with encapsulated imported D-VNI”) comprising:
a tunnel header comprising the underlay network address for the another computing device (Jagadeesan: Fig. 3A “incapsulated packet with imported D-VNI (underlay network address)”),
an outer header comprising a virtual network address associated with the VTEP, a VXLAN header, and the original packet (Jagadeesan: Fig. 3B “re-encapsulated packet routed to destination VRF”); and
output the second packet via the NIC to the another computing device (Jagadeesan: Fig. 3A “output packet with encapsulated imported D-VNI” and Fig. 2 “NIC 56”).
Jagadeesan in view of Pfaff does not explicitly teach the storage media is configured to store a flood list a tenant associated with the VTEP, the flood list storing an entry specifying an underlay network address for another computing device.
However, Kwong teaches in the case that the enqueue count exceeds a predetermined enqueue threshold value, decision 532, the process identifies the responsible tenant, and adds it to a “flooder list,” block 540. The flooder list entry, in this example, is a message type-tenant combination (Kwong: paragraph 54). In addition, Kwong teaches since the system operates in a multi-tenant system, it is important that we isolate the traffic from flooders into physically different queues (underlay network address), so that messages from other message types or tenants are not adversely impacted, e.g., stuck behind the messages of a flooder in the same queue (Kwong: paragraph 55).
Thus, it would have been obvious to a person of ordinary skill to use the teachings of Kwong in the combined network device of Pfaff and Jagadeesan in order isolates flooders into physically different queues, so that messages from other message types or tenants are not adversely impacted (Kwong: paragraph 55).
For claim 9 Jagadeesan in view of Pfaff and further in view of Kwong teaches the computing device of claim 8, wherein the processing circuitry is configured to:
receive, by an agent, the entry (as discussed in claim 8);
store the entry to the flood list (as discussed in claim 8).
For claim 19 Jagadeesan in view of Pfaff and further in view of Kwong teaches the method of claim 14 (as discussed in claim 8), further comprising
storing, by the computing device, a flood list for a tenant associated with the VTEP, the flood list storing an entry specifying an underlay network address for another computing device (as discussed in claim 8),
wherein the packet comprises a first packet (as discussed in claim 8);
the method (as discussed in claim 8) further comprising:
receiving, by the tenant-specific packet processor, an original packet from the workload (as discussed in claim 8);
generating a second packet (as discussed in claim 8) comprising:
a tunnel header comprising the underlay network address for the another computing device, an outer header comprising a virtual network address associated with the VTEP, a VXLAN header, and the original packet (as discussed in claim 8);
outputting the second packet via the NIC to the another computing device (as discussed in claim 8).
Conclusion
7. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure Jeuk et al. (2019/0065278 A1) (Title: “TENANT-SPECIFIC POLICY GENERATION AND ENFORCEMENT WITHIN CONTAINERS” and Fig.2 “software package for Tenants 1-6”).
8. Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any 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.
9. Any inquiry concerning this communication or earlier communications from the examiner should be directed to David M OVEISSI whose telephone number is (571)270-3127. The examiner can normally be reached Monday-Friday 8Am-5PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jeffrey Rutkowski can be reached at (571) 270-1215. 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.
/MANSOUR OVEISSI/Primary Examiner, Art Unit 2415