DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
1. This communication is in response to amendments filed on 03/16/2026.
Claims 1-20 have been cancelled, and claims 21-40 have been newly added.
Claim Objections
Applicant’s cancellation of previously presented claims replaced with newly added claims 21-40 in response to the previous objection for the numbering of claims in the preliminary amendment obviates previous objection, however newly added claims 26, 33, 34, and 40 are objected to because of the following informalities:
2. Claims 26, 33 and 40 recite “the second packet” in the extracting, determining and applying limitations. Although these recitations are understood to refer to the “second network packet” introduced in the previous receiving limitation in the claims, Applicant is urged to amend subsequent recitations to “the second network packet” in order to provide clear and consistent antecedent basis throughout the claims.
3. Claim 34 recites “the second source identifier” in the preamble of the claim. Although this recitation is understood to refer to the “second source identifier value” disclosed in claim 33, from which claim 34 depends, Applicant is urged to amend this recitation in the preamble of claim 34 to “the second source identifier value” in order to provide clear and consistent antecedent basis throughout the claims.
Appropriate correction is requested.
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.
Claim 27 is 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. Specifically for the following reason:
4. Claim 27 recites “the second source identifier” in the preamble, “the VXLAN header for the second packet” in the first and second limitation, and “the second source identifier value” at the end of the second limitation. There is insufficient antecedent basis for these limitations in the claim. Although these elements are disclosed in previous claim 26, claim 27 depends from claims 21, 24, and 25 which do not provide antecedent basis for these limitations.
For purposes of examination, these limitations are interpreted as referring to a second source identifier and a VXLAN header of a second network packet received by the leaf switch.
Double Patenting
5. The Terminal Disclaimer filed in response to the double patenting rejection in view of US Patent No. 12,021,740 has been approved, and therefore the double patenting rejection is hereby withdrawn.
Response to Arguments
6. Applicant's arguments that the previously applied references fail to disclose or suggest the features defined by Applicant’s new claims have been fully considered but they are not persuasive. Specifically, Applicant assets that Chang in view of Ramasubramanian fail to disclose or suggest “based on the hardware source port being mapped to the source identifier value, adding, by the leaf switch, the source identifier value to a Virtual Extensible Local-Area Network (VXLAN) header for the packet” where “the source identifier value indicates a particular security routing policy to be applied to packets from an application”, as currently included in the independent claims. Applicant’s basis for this argument alleges that cited portion of Chang reciting “provide certain CVM application processes separate route paths through different spine switches” in combination with Chang’s teachings that providing separate route paths for improved quality of service or security does not disclose or suggest an identifier (e.g., GTID of Chang) “indicates a particular security routing policy to be applied to packets from an application”, as claimed.
As discussed during the interview on 03/05/2026 and acknowledged by Applicant, Chang expressly teaches certain applications require different quality of service for security purposes and that, based on these different security requirements, particular route paths are selected. For example, column 7 lines 49-52 of Chang expressly discloses that certain application processes are provided separate route paths for security. It is noted that the claim language is silent regarding any specific details or characteristics of the claimed security routing policy, and it is therefore submitted that a selected route path of Chang, selected based on security requirements of an application identified by an identifier value such as the GTID of Chang, is unambiguously within the scope of a security routing policy indicated by an identifier value. The correlation between the source identifier value indicating a particular security routing policy for an application is further supported by Chang’s teachings that GTIDs are associated with different classes of applications mapped to different route paths. It is submitted that Applicant’s remarks fail to provide sufficient rationale for the argued distinction between a particular security routing policy applied to packets from an application, as claimed, and applying, using a policy table, a particular route path (or routing policy) to packets from an application based on security requirements of the application, as taught by Chang.
The rejection is therefore maintained.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not 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 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.
7. Claims 21, 24, 26-28, 31, 33-35, 38 and 40 are rejected under 35 U.S.C. 103 as being unpatentable over Chang (US 11,070,471) in view of Ramasubramanian et al. (US 2016/0020939).
Regarding claim 21, Chang teaches a method comprising:
maintaining, by a leaf switch of a plurality of switches arranged according to a spine and leaf topology (a switch fabric for Container/Virtual Machines (CVM) where one or more spine switches are coupled to plurality of leaf switches through leaf switch uplink ports, column 1 lines 66-67 – column 2 lines 1-3; FIG. 2 shows an example switch fabric 200 comprising a plurality of spine switches 252A . . . 252N and a plurality of leaf switches 202, 264, . . . , 266, column 8 lines 4-6), data mapping a hardware source port (downlink port DL_port_n in Chang) to a source identifier value (Global Tenant IDentifier (GTID) in Chang) (The leaf switch thereby receives VLAN packets from CVMs on leaf switch downlink ports, uses the VLAN_ID and downlink port to search the LTID table for the associated GTID for the CVM, column 4 lines 13-15; The LTID table 204 has a first set of entries providing forward associations from Tenant_id (VLAN_ID) to GTID organized as: DL_port_n, VLAN_ID [Wingdings font/0xE0] Global Tenant IDentifier (GTID), column 8 lines 29-33), wherein the source identifier value indicates a particular security routing policy to be applied to packets from an application (the selection of which particular leaf switch uplink sub-port is selected relies on a combination of two or more of: IP address, MAC address, or GTID, such as by using a mixture of bits of each. For example, in one example of the invention, it is desired for certain CVMs to receive a higher quality of service than other CVMs, and simultaneously, to provide certain CVM application processes separate route paths through different spine switches, perhaps for security, separating streams by quality of service, or other motivations, column 7 lines 43-52);
receiving, by the leaf switch, a packet from a network device supporting the application (CVM packets are received on interface 210 and processed by packet engine 208 in step 302, column 9 lines 12-13), wherein the network device (server_0 212 or server_m 214 of FIG. 2) is separate from the plurality of switches (switch fabric 200 comprising a plurality of spine switches 252A . . . 252N and a plurality of leaf switches 202, 264, . . . , 266, column 8 lines 4-8);
responsive to determining a hardware source port of the leaf switch receiving the packet from the network device supporting the application (which extracts the downlink port from the interface port, column 9 lines 13-14), determining, by the leaf switch and based on the data mapping the hardware source port to the source identifier value, that the hardware source port is mapped to the source identifier value (The engine 208 connects to the LTID table 340 and does a lookup of the GTID from the VLAN_ID and downlink port, column 9 lines 17-19);
based on the hardware source port being mapped to the source identifier value, adding, by the leaf switch, the source identifier value to a Virtual Extensible Local-Area Network (VXLAN) header for the packet (the VLAN packet being encapsulated into a VxLAN packet in step 320, column 9 lines 38-39; VxLAN header 812, where the VNID field is used to communicate the GTID associated with the VLAN packet 814, column 12 lines 31-33; The VxLAN example was selected to provide understanding of a mechanism to carry the GTID in an easily accessible header field of VxLAN, column 14 lines 43-46); and
responsive to adding the source identifier value to the VXLAN header, forwarding, by the leaf switch, the packet to a spine switch of the plurality of switches (the VxLAN packet encapsulating the VLAN being sent to the spine switch leaf port 262 where it is processed by the spine switch 252 in step 322, column 9 lines 47-49).
However, Chang does not explicitly disclose mapping a plurality of hardware source ports to the source identifier value or that the data mapping is received from a controller device for the plurality of switches.
Ramasubramanian teaches receiving, by a leaf switch (Edge switches such as E1, E2, E3, and E4 that are coupled to end hosts are sometimes referred to as leaf switches, [0067]) of a plurality of switches arranged according to a spine and leaf topology (Switches 114 that are coupled to each of the leaf switches are sometimes referred to as spine switches, [0067]), data mapping a plurality of hardware source ports (the switch may implement link aggregation that assigns a link aggregation group (LAG) to groups of ports of the switch. LAG mapping module 144 may maintain databases or tables that identify mappings between link aggregation groups and switch ports. L2 forwarding module 134 may identify link aggregation groups instead of switch ports, [0080]) to a source identifier value (The virtual switch identifier of a network packet may effectively identify the virtual switch of the source end host that sent the network packet, [0094]; Each virtual switch identification entry 152 may identify end hosts and a virtual switch identifier to assign to network packets matching the identified end hosts. In the example of FIG. 10, end hosts may be identified by the switch ports at which network packets are received, [0089]; Link aggregation table 270 may include intra-rack LAG groups for each server (e.g., L2 for server X1 and L1 for server X2), [0119]) from a controller device for the plurality of switches (controller server 18 may provide controller clients 30 with data that determines how switch 14 is to process incoming packets from input-output ports 34, [0041]; virtual switch identification table 132 may include entries 152 that a controller has provided to switch E4 for assigning virtual switch identifiers to incoming packets, [0088]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize a controller server for providing data that determines how switches are to process packets from input-output ports in the system/method of Chang as suggested by Ramasubramanian in order to efficiently manage a plurality of switches with multiple ports aggregated in groups for forwarding packets between end hosts. One would be motivated to combine these teachings to effectively handle port failure and identify appropriate paths for packets based on current port conditions.
Regarding claim 24, Chang teaches the method of claim 21, further comprising receiving, by the leaf switch, a plurality of policies (The slice configuration is a static or dynamic value which may be set up during the switch fabric initialization phase by the cloud operator responsible for generation of the CVMs or this may be done using control plane software which performs the task of reassigning table entries across old and new spine switches, column 11 lines 1-6) that each are associated with a respective source identifier value and a respective destination address (selecting an uplink port associated with a particular spine switch using bits from at least one of: destination MAC address, destination IP address, or GTID of the associated CVM, column 4 lines 34-37; the selection of a sub-port may rely on bits of the CVM destination MAC address or CVM destination IP address as well as bits of the GTID, column 7 lines 52-55; the particular spine switch slice selected is based on bits of a destination address or GTID, column 8 lines 50-54; each leaf switch uplink port is configurable to multiple sub-ports, allowing the VxLAN packet formed by VxLAN engine 208 to be directed to any of several spine switches 252 based on bits of the destination CVM layer 2 (MAC) address, CVM layer 3 (IP) destination address, or GTID, column 12 line 64-column 13 line 2), wherein the plurality of policies include the particular security routing policy (the selection of which particular leaf switch uplink sub-port is selected relies on a combination of two or more of: IP address, MAC address, or GTID, such as by using a mixture of bits of each. For example, in one example of the invention, it is desired for certain CVMs to receive a higher quality of service than other CVMs, and simultaneously, to provide certain CVM application processes separate route paths through different spine switches, perhaps for security, separating streams by quality of service, or other motivations, column 7 lines 43-52).
Regarding claim 26, Chang teaches the method of claim 21, wherein the packet is a first packet and the source identifier value is a first source identifier value, and wherein the method further comprises:
receiving, by the leaf switch, a second network packet (When the VxLAN packet arrives at a leaf switch uplink port, column 5 lines 1-3; The VxLAN engine 208 receives the incoming spine switch leaf port packet in step 502, column 10 lines 7-8);
extracting, by the leaf switch, a second source identifier value from a VXLAN header for the second packet (the leaf switch un-encapsulates the incoming VxLAN packet, retrieves the VLAN packet inside the incoming VxLAN packet, looks up into its LFIB table with VLAN packet destination address (MAC or IP) and the GTID from the VxLAN VNID field, column 5 lines 2-6; gets the GTID from the VNID field of the VxLAN packet, column 10 lines 8-9);
determining, by the leaf switch, at least one policy of a plurality of policies to apply to the second packet according to the second identifier value (Find the leaf destination downlink port and destination CVM MAC address, column 5 lines 6-7; the recovered VxLAN GTID value and VLAN MAC (or IP) address are applied to the FIG. 3C LFIB table, which provides the destination leaf downlink port and destination CVM MAC address for layer-3 packets from table 354 in step 510. In step 512, the VxLAN forwarder 256 retrieves the new VLAN_ID from LTID table 342 using the destination leaf downlink port and GTID, column 10 lines 12-18); and
applying, by the leaf switch, the at least one policy to the second packet (modify the VLAN packet VLAN_ID with a lookup of LTID using GTID and destination downlink port, for a layer-3 packet modify the VLAN packet destination MAC address to destination CVM MAC address and VLAN packet source address to leaf switch MAC address and forwards the VLAN packet onto the leaf downlink port, column 5 lines 7-13; changes the VLAN packet VLAN_ID to the new VLAN_ID, changes the VLAN packet destination MAC to the destination CVM MAC address, changes the VLAN packet source MAC to the leaf switch MAC address, and sends the VLAN packet to the destination spine switch leaf port (coupled to the selected leaf switch uplink port), where the packet is directed to the associated CVM by the selected leaf switch, column 10 lines 18-25).
Regarding claim 27, Chang teaches the method of claim 25, wherein extracting the second source identifier comprises:
parsing bits of the VXLAN header for the second packet (the leaf switch un-encapsulates the incoming VxLAN packet, column 5 lines 1-3; the VxLAN is un-encapsulated to retrieve the respective MAC or IP destination address of the VLAN packet which was encapsulated, column 10 lines 9-12); and
based on parsing the bits of the VXLAN header for the second packet (VxLAN header 812, where the VNID field is used to communicate the GTID associated with the VLAN packet 814, column 12 lines 31-33), extracting the second source identifier value (retrieves the VLAN packet inside the incoming VxLAN packet, looks up into its LFIB table with VLAN packet destination address (MAC or IP) and the GTID from the VxLAN VNID field, column 5 lines 3-6; the recovered VxLAN GTID value and VLAN MAC (or IP) address are applied to the FIG. 3C LFIB table, which provides the destination leaf downlink port and destination CVM MAC address for layer-3 packets from table 354 in step 510, column 10 lines 12-16).
Regarding claim 28, Chang teaches a leaf switch device of a plurality of switches arranged according to a spine and leaf topology (a switch fabric for Container/Virtual Machines (CVM) where one or more spine switches are coupled to plurality of leaf switches through leaf switch uplink ports, column 1 lines 66-67 – column 2 lines 1-3; FIG. 2 shows an example switch fabric 200 comprising a plurality of spine switches 252A . . . 252N and a plurality of leaf switches 202, 264, . . . , 266, column 8 lines 4-6), the leaf switch device comprising:
a memory;
one or more network interfaces communicatively coupled to a first spine switch and a second spine switch (Spine L2/L3 Switches 252A…252n of FIG. 2) of the plurality of switches (Uplink Port 257 of FIG. 2); and
a processing system implemented in circuitry and configured to:
maintain data mapping a hardware source port (downlink port DL_port_n in Chang) to a source identifier value (Global Tenant IDentifier (GTID) in Chang) (The leaf switch thereby receives VLAN packets from CVMs on leaf switch downlink ports, uses the VLAN_ID and downlink port to search the LTID table for the associated GTID for the CVM, column 4 lines 13-15; The LTID table 204 has a first set of entries providing forward associations from Tenant_id (VLAN_ID) to GTID organized as: DL_port_n, VLAN_ID [Wingdings font/0xE0] Global Tenant IDentifier (GTID), column 8 lines 29-33), wherein the source identifier value indicates a particular security routing policy to be applied to packets from an application (the selection of which particular leaf switch uplink sub-port is selected relies on a combination of two or more of: IP address, MAC address, or GTID, such as by using a mixture of bits of each. For example, in one example of the invention, it is desired for certain CVMs to receive a higher quality of service than other CVMs, and simultaneously, to provide certain CVM application processes separate route paths through different spine switches, perhaps for security, separating streams by quality of service, or other motivations, column 7 lines 43-52);
store, to the memory, the data mapping the hardware source port to the source identifier value (204 LTID and 206 LFIB tables, respectively, maintained and used by each leaf switch, column 9 lines 6-8);
receive a packet from a network device supporting the application (CVM packets are received on interface 210 and processed by packet engine 208 in step 302, column 9 lines 12-13), wherein the network device (server_0 212 or server_m 214 of FIG. 2) is separate from the plurality of switches (switch fabric 200 comprising a plurality of spine switches 252A . . . 252N and a plurality of leaf switches 202, 264, . . . , 266, column 8 lines 4-8);
responsive to determining a hardware source port receiving the packet from the network device supporting the application (which extracts the downlink port from the interface port, column 9 lines 13-14), determine, based on the leaf switch using the data mapping the plurality of hardware source ports to the source identifier value, that the hardware source port is mapped to the source identifier value (The engine 208 connects to the LTID table 340 and does a lookup of the GTID from the VLAN_ID and downlink port, column 9 lines 17-19);
based on the hardware source port being mapped to the source identifier value, add the source identifier value to a Virtual Extensible Local-Area Network (VXLAN) header for the packet (the VLAN packet being encapsulated into a VxLAN packet in step 320, column 9 lines 38-39; VxLAN header 812, where the VNID field is used to communicate the GTID associated with the VLAN packet 814, column 12 lines 31-33; The VxLAN example was selected to provide understanding of a mechanism to carry the GTID in an easily accessible header field of VxLAN, column 14 lines 43-46); and
responsive to adding the source identifier value to the VXLAN header for the packet, forward the packet to a spine switch of the plurality of switches (the VxLAN packet encapsulating the VLAN being sent to the spine switch leaf port 262 where it is processed by the spine switch 252 in step 322, column 9 lines 47-49).
However, Chang does not explicitly disclose mapping a plurality of hardware source ports to the source identifier value or that the data mapping is received from a controller device for the plurality of switches.
Ramasubramanian teaches a leaf device (Edge switches such as E1, E2, E3, and E4 that are coupled to end hosts are sometimes referred to as leaf switches, [0067]) comprising a processing system implemented in circuitry and configured to:
receive data mapping a plurality of hardware source ports (the switch may implement link aggregation that assigns a link aggregation group (LAG) to groups of ports of the switch. LAG mapping module 144 may maintain databases or tables that identify mappings between link aggregation groups and switch ports. L2 forwarding module 134 may identify link aggregation groups instead of switch ports, [0080]) to a source identifier value (The virtual switch identifier of a network packet may effectively identify the virtual switch of the source end host that sent the network packet, [0094]; Each virtual switch identification entry 152 may identify end hosts and a virtual switch identifier to assign to network packets matching the identified end hosts. In the example of FIG. 10, end hosts may be identified by the switch ports at which network packets are received, [0089]; Link aggregation table 270 may include intra-rack LAG groups for each server (e.g., L2 for server X1 and L1 for server X2), [0119]) from a controller device for a plurality of switches (controller server 18 may provide controller clients 30 with data that determines how switch 14 is to process incoming packets from input-output ports 34, [0041]; virtual switch identification table 132 may include entries 152 that a controller has provided to switch E4 for assigning virtual switch identifiers to incoming packets, [0088]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize a controller server for providing data that determines how switches are to process packets from input-output ports in the system/method of Chang as suggested by Ramasubramanian in order to efficiently manage a plurality of switches with multiple ports aggregated in groups for forwarding packets between end hosts. One would be motivated to combine these teachings to effectively handle port failure and identify appropriate paths for packets based on current port conditions.
Regarding claim 31, the leaf switch device claim includes subject matter similar to method claim 24, and is therefore rejected in view of the same rationale.
Regarding claim 33, the leaf switch device claim includes subject matter similar to method claim 26, and is therefore rejected in view of the same rationale.
Regarding claim 34, the leaf switch device claim includes subject matter similar to method claim 27, and is therefore rejected in view of the same rationale.
Regarding claim 35, the non-transitory computer-readable storage medium claim includes subject matter similar to leaf switch device claim 28, and is therefore rejected in view of the same rationale.
Regarding claim 38, the non-transitory computer-readable storage medium claim includes subject matter similar to method claim 24 and leaf switch device claim 31, and is therefore rejected in view of the same rationale.
Regarding claim 40, the non-transitory computer-readable storage medium claim includes subject matter similar to method claim 26 and leaf switch device claim 33, and is therefore rejected in view of the same rationale.
8. Claims 22, 29, and 36 are rejected under 35 U.S.C. 103 as being unpatentable over Chang-Ramasubramanian in view of Gai et al. (US 2009/0300350).
Regarding claim 22, Chang teaches the method of claim 21, wherein the source identifier value indicates a category for at least one object of the application (GTIDs ending in ‘000’ is assigned to high priority traffic, and a comparatively large number of GTIDs ending in ‘111’ is assigned to low priority traffic, column 11 lines 11-14; Premium Tenants, regular tenants, mission critical applications, and best effort applications, according to the separation of CVMs to particular servers and route paths. In the below example, a remapping may also be done such that 4 bits of GTID and address resolve to 8 spine switches rather than 16, such that Premium Tenants and Mission Critical Applications are both directed to spine switches [0 . . . 3] and other traffic routed to spine switches [4 . . . 7], column 13 lines 44-54), wherein the category corresponds to the particular security routing policy (it is desired for certain CVMs to receive a higher quality of service than other CVMs, and simultaneously, to provide certain CVM application processes separate route paths through different spine switches, perhaps for security, separating streams by quality of service, or other motivations, column 7 lines 43-52).
However, Chang-Ramasubramanian do not explicitly disclose a security category.
Gai teaches a source identifier value (An indicator, referred to as a security group tag (SGT), abstract) indicates a security category (identifies members of a security group, abstract; there are seven different roles defined for security groups within enterprise network 200 and seven corresponding SGTs indicated on FIG. 2, [0070]) for at least one object of an application (roles are assigned to users or applications instead of devices, [0071]), wherein the security category corresponds to a particular routing policy (FIG. 8 depicts table 800, which provides an example of applying policies according to some aspects of the invention, [0082]).
It would have been obvious to one of ordinary skill in the art at the time of the claimed invention to apply a policy based on a security group tag associated with a packet in the system/method of Chang-Ramasubramanian as suggested by Gai in order to efficiently enforce security for certain classes of users and applications. One would be motivated to combine these teachings to ensure sensitive network resources are protected.
Regarding claim 29, the leaf switch device claim includes subject matter similar to method claim 22, and is therefore rejected in view of the same rationale.
Regarding claim 36, the non-transitory computer-readable storage medium claim includes subject matter similar to method claim 22 and leaf switch device claim 29, and is therefore rejected in view of the same rationale.
9. Claims 23, 30, and 37 are rejected under 35 U.S.C. 103 as being unpatentable over Chang-Ramasubramanian in view of Panchalingam et al. (US 2019/0297114).
Regarding claim 23, Chang teaches the method of claim 21, further comprising storing, by the leaf switch, the particular security routing policy in the leaf switch (The slice configuration is a static or dynamic value which may be set up during the switch fabric initialization phase by the cloud operator responsible for generation of the CVMs or this may be done using control plane software which performs the task of reassigning table entries across old and new spine switches, column 11 lines 1-6).
However, Chang-Ramasubramanian do not explicitly disclose ternary content-addressable memory (TCAM).
Panchalingam teaches storing, by a leaf switch, a particular security routing policy in ternary content-addressable memory (TCAM) of the leaf switch (security rules installed on the TCAM of Leafs 104, [0056]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to install security policy rules on a TCAM of leaf switch in the system/method of Chang-Ramasubramanian as suggested by Panchalingam in order for the leaf switch to compare many rules at once for quick and efficient policy enforcement. One would be motivated to combine these teachings to enable processing of large amounts of traffic more quickly.
Regarding claim 30, the leaf switch device claim includes subject matter similar to method claim 23, and is therefore rejected in view of the same rationale.
Regarding claim 37, the non-transitory computer-readable storage medium claim includes subject matter similar to method claim 23 and leaf switch device claim 30, and is therefore rejected in view of the same rationale.
10. Claims 25, 32, and 39 are rejected under 35 U.S.C. 103 as being unpatentable over Chang-Ramasubramanian in view of Devaraj et al. (US 2021/0352013).
Regarding claim 25, Chang-Ramasubramanian do not explicitly disclose the method of claim 24, wherein receiving the plurality of policies comprises receiving one or more Border Gateway Protocol (BGP) messages specifying the plurality of policies from a controller device for the plurality of switches.
Devaraj teaches wherein receiving a plurality of policies comprises receiving one or more Border Gateway Protocol (BGP) messages specifying the plurality of policies (if switches support the border gateway protocol (BGP), the ACL rules can be expressed in a BGP flow specification (Flowspec) comprising a set of flow filters and communicated to the switches, [0037]) from a controller device for a plurality of switches (the data network controller can generate a set of ACL rules from the policies. As noted above, the policies received at operation 302 can be the basis (policy basis) for ACL rules that are provided to the switches, [0037]; the data network controller can propagate the ACL rules to the switches, [0038]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide policy rules using BGP in the system/method of Chang-Ramasubramanian as suggested by Devaraj to allow a controller to efficiently share rules and updates across multiple network switches. One would be motivated to combine these teachings for quick and consistent distribution of policies on larger growing networks.
Regarding claim 32, the leaf switch device claim includes subject matter similar to method claim 25, and is therefore rejected in view of the same rationale.
Regarding claim 39, the non-transitory computer-readable storage medium claim includes subject matter similar to method claim 25 and leaf switch device claim 32, and is therefore rejected in view of the same rationale.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Dixit et al. US 2020/0007582 – a leaf switch storing rules on a TCAM memory.
Mackie et al. US 2020/0314006 – a control device communicating forwarding policy to switches via BGP.
Panchalingam et al. US 2020/0389432 – a leaf switch using a class ID included in a packet to determine a security policy to apply.
Zuk et al. US 2021/0006539 – classification including an application ID used to apply a security policy to direct routing of a packet.
Ford et al. US 2022/0232111 – determining traffic classification for a packet and generating a flag used for routing the packet based on the traffic classification.
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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MADHU WOOLCOCK whose telephone number is (571)270-3629. The examiner can normally be reached Tuesday, Thursday 9-6 ET.
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, Chris Parry can be reached at 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://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.
MADHU WOOLCOCK
Examiner
Art Unit 2451
/MADHU WOOLCOCK/Primary Examiner, Art Unit 2451
Prosecution Insights