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 .
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1-4, 6, 8-12, 14, and 16-19 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Majila (US 20230113466 A1).
Regarding claim 1, Majila teaches a method, comprising:
sending, by a first network device in a network, a first packet of a first data flow to a second network device in the network, wherein a source of the first data flow is associated with a first role and a destination of the first data flow is associated with a second role; (Fig. 1: host 121-126, switch 101-105 (e.g., including the first and second network device). Fig. 2A: Policy table. [0031]-[0032]: By associating host 123 to role 134, host 123 can be allocated to a group of hosts belonging to role 134. A host (e.g., including source and destination) may be associated with one or more groups.)
receiving, from the second network device, a control packet indicating that the second role is precluded from receiving traffic from the first role; ([0032]: For packets received via tunnels, switch 103 (e.g., the second network device) can operate as a policy-enforcement switch and maintain a policy table 150 comprising a set of policies (e.g., GBPs or user-configured policies) 152 defined based on the source and destination roles.)
identifying the first data flow based on information in a payload of the control packet; ([0032]: A respective policy or GBP in policies 152 can indicate whether a class of traffic (e.g., with certain traffic attributes) from a source role is allowed or permitted to be forwarded to a destination role. For example, a GBP can indicate whether role 134 is permitted to receive Transmission Control Protocol (TCP) traffic from role 132 at port 80. Furthermore, switch 103 may only enable a policy associated with a role if a host with that role is detected at a port of switch 103.)
and
removing an entry from a flow data structure maintained in forwarding hardware of the first network device, wherein the entry comprises identifying information of the first data flow. (Fig. 2F and 2G. [0058]: The system can match multiple overlapping entries against the traffic with a matching pattern and can remove the overlap to ensure that the policies and decision model result in a deterministic decision. [0070]: All policy elements which do not result in successful validation against the original policy can be pruned from the list of newly created policy elements, such that only the valid policy elements remain in the imploded list.)
Regarding claim 2, Majila teaches the method of claim 1.
Majila teaches receiving the first packet from an end device coupled to a device port of the first network device; and ([0032]: Furthermore, switch 103 may only enable a policy associated with a role if a host with that role is detected at a port of switch 103.)
generating the entry in the flow table in response to receiving the packet. [0033]: host 125 can send a packet to host 122. Access switch 115 can receive the packet and forward it to fabric 110. Ingress switch 105 can receive the packet and determine the source role (i.e., role 132 of source host 125) associated with the packet. Switch 105 can further determine a remote tunnel endpoint, such as switch 103, in fabric 110 based on the header information of the packet. Subsequently, switch 105 can forward the encapsulated packet via the tunnel to switch 103. [0034]: Egress switch 103, which can be the other tunnel endpoint of the tunnel, can obtain the source role from the tunnel header and decapsulate the tunnel header to obtain the packet. Based on the destination address of the packet, switch 103 can determine the destination role (i.e., role 134 of destination host 122). Switch 103 can traverse policies 152 to determine whether the traffic class of the packet is permitted to be forwarded from role 132 to role 134. If permitted, switch 103 can forward the packet to host 122.)
Regarding claim 3, Majila teaches the method of claim 2.
Majila teaches converting the entry to a generic entry independent of a source protocol port; and storing the generic entry in a cache data structure maintained by a control plane of the network device. (Fig. 2A-2F. [0032]: switch can operate as a policy-enforcement switch and maintain a policy table (e.g., control plane of the switch) comprising a set of policies (e.g., GBPs or user-configured policies) defined based on the source and destination roles. [0040]: The system can generate a set of synthesized policies from the user-configured policies of table in stages. Each policy in the policy table applies to a range of ports, so it s independent of a source protocol port.)
Regarding claim 4, Majila teaches the method of claim 1.
Majila teaches determining, by the first network device, that a second packet of a second data flow matches the generic entry in the cache data structure; and refraining from sending the second packet from the first network device. (Fig. 2A-2C. [0039]: Each policy can include one or more policy entries, and each policy can indicate or include: a sequence number (e.g., “10,” “20,” and “30”); a source role; the destination role; one or more traffic attributes; and an action (e.g., “Allowed” or “Denied”). [0048]: Each entry in the matrix of table 210 can indicate one or more traffic attributes and a corresponding action to be taken for a packet with matching traffic attributes. For example, an entry 217 for a destination role of Security 216 and a source role of Admin 211 can indicate the following two policy elements or traffic attributes and actions: “10 IP Protocol UDP, L4 Port Any, Denied”.)
Regarding claim 6, Majila teaches the method of claim 1.
Majila teaches wherein the identifying information of the first data flow comprises one or more of: a source protocol port identifier, a source network address, a destination protocol port identifier, a destination network address, and a name of a protocol associated with the first data flow. (Fig. 2A-2G. [0039]: each policy can indicate or include: a sequence number (e.g., “10,” “20,” and “30”); a source role; the destination role; one or more traffic attributes; and an action (e.g., “Allowed” or “Denied”). For example, policy P1 for destination role Finance 204 can include two policy entries. The first policy entry can indicate: a sequence number of “10”; a source role of “Admin”; a destination role of “Finance”; traffic attributes of “IP Protocol TCP” and “L4 Port 10-100”; and an action of “Allowed.” A second policy entry can indicate: a sequence number of “20”; a source role of “Any”; a destination role of “Finance”; traffic attributes of “IP Protocol TCP Traffic” and “L4 Port 80”; and an action of “Allowed.”.)
Regarding claim 8, Majila teaches the method of claim 1.
Majila teaches wherein the second network device is to enforce role-based segmentation on the first data flow based on the first and second roles; and (Fig. 2A-2F. [0032]: For packets received via tunnels, switch 103 (e.g., the second network device) can operate as a policy-enforcement switch and maintain a policy table 150 comprising a set of policies (e.g., GBPs or user-configured policies) 152 defined based on the source and destination roles.)
wherein receiving the control packet from the second network device indicates that the second network device is to refrain from forwarding the first packet to the destination. ([0036]: User-configured policies 152 can take as input a source role, a destination role, and traffic attributes in order to output an action of allow/drop for a packet. [0039]: Each policy can include one or more policy entries, and each policy can indicate or include: a sequence number (e.g., “10,” “20,” and “30”); a source role; the destination role; one or more traffic attributes; and an action (e.g., “Allowed” or “Denied”).)
Same rationales apply to claim 9 (CRM) and claim 17 (system) because they are substantially similar to claim 1 (method).
Same rationales apply to claim 10 (CRM) because it is substantially similar to claim 2 (method).
Same rationales apply to claim 11 (CRM) and claim 18 (system) because they are substantially similar to claim 3 (method).
Same rationales apply to claim 12 (CRM) and claim 19 (system) because they are substantially similar to claim 4 (method).
Same rationales apply to claim 14 (CRM) because it is substantially similar to claim 6 (method).
Same rationales apply to claim 16 (CRM) because it is substantially similar to claim 8 (method).
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.
Claim(s) 5, 13 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Majila (US 20230113466 A1) in view of Mishra (US 20200287737 A1).
Regarding claim 5, Majila teaches the method of claim 4.
Majila does not explicitly disclose generating, at the first network device, a loop-back control packet destined to the network device; and removing, from the flow data structure, a second entry comprising identifying information of the second data flow in response to receiving the loop-back control packet.
However, Mishra teaches generating, at the first network device, a loop-back control packet destined to the network device; and removing, from the flow data structure, a second entry comprising identifying information of the second data flow in response to receiving the loop-back control packet. ([0024]: The multicast routing message can include a multicast source indicator of the multicast source, a multicast group identifier of the multicast traffic, and a loopback address of the first provider edge router. [0083]: a clear flag multicast routing message can include a source active clear flag for a specific multicast group and a loopback address to indicate that a provider edge router associated with the loopback address is no longer an active source for the multicast group. In turn, devices can clear routing tables, e.g. remove entries associating a loopback address/provider edge router with a specific multicast group and multicast source, based on a clear flag multicast routing message.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include above limitation into Majila. One would have been motivated to do so because a clear flag multicast routing message can include a source active clear flag for a specific multicast group and a loopback address to indicate that a provider edge router associated with the loopback address is no longer an active source for the multicast group. In turn, devices can clear routing tables, e.g. remove entries associating a loopback address/provider edge router with a specific multicast group and multicast source, based on a clear flag multicast routing message. As taught by Mishra, [0083].
Same rationales apply to claim 13 (CRM) and claim 20 (system) because they are substantially similar to claim 5 (method).
Claim(s) 7 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Majila (US 20230113466 A1) in view of Kajizaki (US 2001005531 A1).
Regarding claim 7, Majila teaches the method of claim 1.
Majila does not explicitly disclose wherein the control packet comprises an Internet Control Message Protocol (ICMP) packet indicating unreachability of a destination of the first packet.
However, Kajizaki teaches wherein the control packet comprises an Internet Control Message Protocol (ICMP) packet indicating unreachability of a destination of the first packet. ([0068]: When an ICMP Destination Unreachable message is received from a router located along a transmission route, the routing information gathering unit 9 recognizes that a failure has occurred along the route passing through that router, and either sets “FAILED” in the network condition column or deletes all information concerning that route from the routing table.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include above limitation into Majila. One would have been motivated to do so because when an ICMP Destination Unreachable message is received from a router located along a transmission route, the routing information gathering unit recognizes that a failure has occurred along the route passing through that router, and either sets “FAILED” in the network condition column or deletes all information concerning that route from the routing table. As taught by Kajizaki, [0068].
Same rationales apply to claim 15 (CRM) because it is substantially similar to claim 7 (method).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ZI YE whose telephone number is (571)270-1039. The examiner can normally be reached Monday - Friday, 8:00am - 4:00pm.
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, Emmanuel Moise can be reached at 5712723865. 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.
/ZI YE/Primary Examiner, Art Unit 2455