Details
Claims 1-26 are pending.
Claims 1-26 are rejected.
Claim Rejections - 35 USC § 102
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.
Claims 1-2, 5-12, 14-15, 18-20, and 22-25 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Kasralikar et al (Pub. No.: US 2009/00003317 A1).
As per claim 1, Kasralikar discloses a computer-implemented method for detecting a threat in a communication sent from an initiating network entity to a destination network entity (Kasralikar, Fig 1, abstract, wherein “a method for selectively redirecting a data packet to a port on a switching device which is associated with a corresponding network service. In one embodiment, the data packet is redirected to an intrusion prevention service (IPS) for security analysis of the data packet”), the method comprising: by a processor of a router (Kasralikar, Fig 1, paragraph 0015, wherein “switching device 110 may be a multi-layer switch (MLS), a hybrid OSI L2/L3 switch router, or other network device having a switching capability”): - receiving, the communication, wherein the communication is directed from an initiating address of an initiating network entity to a destination address of a destination network entity (Kasralikar, Fig 1, paragraph 0019, wherein “At 105, switch 110 receives a data packet from the network 130, the data packet to be directed to one or more destinations in network 140”); - in accordance with a predefined rule associated with at least one of the initiating address or the destination address (Kasralikar, Fig 1, paragraph 0022, wherein “In one embodiment, the network condition may be a condition of the data packet itself. For example, the network condition may be a type of traffic which the data packet represents. This traffic type of the data packet may be indicated by information contained in the data packet itself. For example, the traffic type of the data packet may be based on information which includes, but is not limited to, a network source identifier of the data packet, a network destination identifier of the data packet, a protocol type of the data packet, a service type of the data packet, and/or an application associated with the data packet”), rerouting the communication to a designated appliance (DEAP) (Kasralikar, Fig 1 item 120, Fig 2 item 211, paragraph 0018, 0020, wherein “An embodiment of the invention selectively performs a data link layer redirect of a data packet to a port associated with an IPS. For the sake of clarity, "redirecting a data packet" refers herein to the sending of the data packet on a different network path, at least temporarily, instead of directing the data packet on any of the one or more destination paths to which the data packet was otherwise meant to be sent”), to enable monitoring of the communication to detect threats (Kasralikar, Fig 1, paragraph 0016, wherein “In one embodiment, network service 120 may provide an intrusion prevention service (IPS) to detect security threats found in network traffic of switching device 110”), wherein the predefined rule is indicative of a required security monitoring of communications involving at least one of the initiating network entity or the destination network entity (Kasralikar, Fig 1, paragraph 0031, wherein “Detected conditions (e.g., a spike in traffic, traffic congestion, etc.) are analyzed using the rules and/or thresholds of the set of policies 207 to determine whether a service or flow associated with a detected condition warrants further inspection by IPS 211. In one embodiment, sensors 210 may detect an abnormal increase in email traffic entering switch 201. If the abnormality triggers a rule or exceeds a threshold of one of the set of policies 207, then selection manager 206 may automatically update table 209 to include email traffic”); and - in case no indication of a threat is identified, routing the communication to the destination network entity (Kasralikar, Fig 1-2, paragraph 0020, wherein “Based at least in part on a result of the performed analysis, the redirected data packet may be returned, at 125, from the network service 120 to the switching device 110. In one embodiment of the invention, any returned data packet may be sent from switching device 110 to at least one of the one or more destinations in network 140”);
As per claim 2, claim 1 is incorporated and Kasralikar further discloses wherein initiating network entity and the destination network entity belong to the same organization network (Kasralikar, Fig 1, paragraph 0014, wherein “Networks 130 and 140 are shown as distinct networks to help demonstrate how switching device 110 may redirect a received data packet according to one embodiment of the invention. It is understood to one of ordinary skill in the relevant art that switching device 110 may also send and/or selectively redirect network traffic from network 140 to network 130. It is also understood to one of ordinary skill in the networking arts that networks 130 and 140 may represent arbitrary parts of a larger single network (not shown), to which switching device 110 also belongs”);
As per claim 5, claim 1 is incorporated and Kasralikar further discloses wherein the method further comprises, by a processor of the DEAP: monitoring the communication to detect threats (Kasralikar, Fig 1, paragraph 0016, wherein “In one embodiment, network service 120 may provide an intrusion prevention service (IPS) to detect security threats found in network traffic of switching device 110”);
As per claim 6, claim 5 is incorporated and Kasralikar further discloses by the processor of the DEAP: transmitting data indicative of the communication to a different appliance to monitor (Kasralikar, paragraph 0028, wherein “IPS 211 may analyze redirected traffic 223 to determine whether a particular flow is good (e.g., safe, not a threat, etc.) or bad (e.g., viruses, worms, denial of service (DoS) attacks, etc.). For example, an IPS device might determine that a particular flow (e.g., flow A) is a good flow. Data packets from good flows 224 may be returned to a packet forwarder 232, which may perform further analysis and/or other operations on a returned data packet. After any additional analysis or other operations, packet forwarder 232 may either drop a returned data packet or send the returned data packet as outbound network traffic 225 of switch 201”);
As per claim 7, claim 5 is incorporated and Kasralikar further discloses by the processor of the DEAP: enabling selective monitoring of the communication to detect threats (Kasralikar, abstract, paragraph 0014, 0027-0028, wherein “The IPS may receive redirected data 223, for example, via any of a coaxial cable, a twisted pair cable, a parallel bus, a serial bus, etc. Traffic selector 208 may include a table 209 having entries that identify flows and/or services that have been flagged for further packet inspection. In this case, a data packet associated with a service that matches an entry in table 209 may be redirected to a port on switch 201 associated with IPS 211”);
As per claim 8, claim 1 is incorporated and Kasralikar further discloses receiving an indication of a potential threat (Kasralikar, paragraph 0032, 0045, wherein “anomaly receiver 205 to receive and process anomaly detection information for use by switch 201. As used herein, "anomaly detection" is understood to refer to any of a variety of analytical methods, well known in the networking arts, which are performed to determine potential security risks to a network”; “Accordingly, an embodiment of the invention includes in the selective redirecting of data packet 300 an assessment of whether data packet 300 is one of these potentially problematic data packets to be flooded from switch 201”);
As per claim 9, claim 8 is incorporated and Kasralikar further discloses taking at least one action (Kasralikar, paragraph 0034, , wherein “An example of such a security rules engine 203 is the Extreme Networks.RTM. CLEAR-Flow Security Rules Engine, which may determine whether to filter, redirect, block, and/or forward services and/or flows based on network traffic analysis and security rules such as rules 204. Furthermore, a security rules engine 203 such as a CLEAR-Flow Security Rules Engine may also relay to anomaly receiver 205 any anomaly detection information resulting from this network traffic analysis. Third, the information provided by various sensors 210 internal to switch 201 may be received by anomaly receiver 205. Still other sources of anomaly detection information--not shown in FIG. 2--may include security detection and/or mitigation agents operating on network traffic which is external to switch 201”);
As per claim 10, claim 9 is incorporated and Kasralikar further discloses wherein the at least one action can be applied on the initiating and destination network entities and/or on communications flow between the network entities and can be selected from a group comprising: blocking transmission of future communications, conditional blocking one or more of the network entities from engaging in further communications, enforcing pre-configured rules that involve timing restrictions on communications applying, or a combination thereof (Kasralikar, paragraph 0034, , wherein “An example of such a security rules engine 203 is the Extreme Networks.RTM. CLEAR-Flow Security Rules Engine, which may determine whether to filter, redirect, block, and/or forward services and/or flows based on network traffic analysis and security rules such as rules 204. Furthermore, a security rules engine 203 such as a CLEAR-Flow Security Rules Engine may also relay to anomaly receiver 205 any anomaly detection information resulting from this network traffic analysis. Third, the information provided by various sensors 210 internal to switch 201 may be received by anomaly receiver 205. Still other sources of anomaly detection information--not shown in FIG. 2--may include security detection and/or mitigation agents operating on network traffic which is external to switch 201”);
As per claim 11, claim 9 is incorporated and Kasralikar further discloses wherein the at least one action is applied on the communications themselves (Kasralikar, paragraph 0034, , wherein “An example of such a security rules engine 203 is the Extreme Networks.RTM. CLEAR-Flow Security Rules Engine, which may determine whether to filter, redirect, block, and/or forward services and/or flows based on network traffic analysis and security rules such as rules 204. Furthermore, a security rules engine 203 such as a CLEAR-Flow Security Rules Engine may also relay to anomaly receiver 205 any anomaly detection information resulting from this network traffic analysis. Third, the information provided by various sensors 210 internal to switch 201 may be received by anomaly receiver 205. Still other sources of anomaly detection information--not shown in FIG. 2--may include security detection and/or mitigation agents operating on network traffic which is external to switch 201”);
As per claim 12, claim 1 is incorporated and Kasralikar further discloses wherein prior to routing the communication, the method further comprising: receiving the communication back from the DEAP (Kasralikar, Fig 1-2, paragraph 0020, wherein “Based at least in part on a result of the performed analysis, the redirected data packet may be returned, at 125, from the network service 120 to the switching device 110. In one embodiment of the invention, any returned data packet may be sent from switching device 110 to at least one of the one or more destinations in network 140”);
As per claim 14, claim 1 is incorporated and Kasralikar further discloses a system comprising a plurality of network entities configured to exchange communications with each other, wherein the method of claim 1 is selectively implemented on at least one of the communications (Kasralikar, Fig 1-2, paragraph 0014, wherein “FIG. 1 illustrates a system 100 wherein a switching device 110 may selectively redirect data packets according to one embodiment of the invention. System 100 may represent any of a variety of "bump-in-the-wire" configurations, wherein data packets from received network traffic may be selectively redirected at least temporarily to a port of switching device 110 associated with an external network service 120. Networks 130 and 140 represent, respectively, a source network from which switching device 110 receives a data packet, and a destination network to which switching device 110 selectively sends the received data packet. Networks 130 and 140 are shown as distinct networks to help demonstrate how switching device 110 may redirect a received data packet according to one embodiment of the invention”);
As per claim 15, claim 14 is incorporated and Kasralikar further discloses wherein the method of claim 1 is selectively implemented on communications exchanged between a subgroup of the network entities (Kasralikar, Fig 1-2, paragraph 0014, wherein “FIG. 1 illustrates a system 100 wherein a switching device 110 may selectively redirect data packets according to one embodiment of the invention. System 100 may represent any of a variety of "bump-in-the-wire" configurations, wherein data packets from received network traffic may be selectively redirected at least temporarily to a port of switching device 110 associated with an external network service 120. Networks 130 and 140 represent, respectively, a source network from which switching device 110 receives a data packet, and a destination network to which switching device 110 selectively sends the received data packet. Networks 130 and 140 are shown as distinct networks to help demonstrate how switching device 110 may redirect a received data packet according to one embodiment of the invention”);
Claims 18-20, and 22-25 are rejected under the same rationale as claims 1-2, 5-12 and 14-15.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 3-4, 16-17, and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Kasralikar et al (Pub. No.: US 2009/00003317 A1) in view of ZAFER et al. (Pub. No.: US 2019/0149396 A1).
As per claim 3, claim 1 is incorporated and Kasralikar does not explicitly disclose wherein the address of at least one of the initiating network entity or the destination network entity emerges from configuration update at a Dynamic Host Configuration Protocol (DHCP) server, assigning a new address to respective network entity, thereby facilitating rerouting of communications involving the respective network entity based on the associated predefined ruler. However, using a DHCP server to assign new address is well known in the art. For example, ZAFER discloses wherein the address of at least one of the initiating network entity or the destination network entity emerges from configuration update at a Dynamic Host Configuration Protocol (DHCP) server, assigning a new address to respective network entity, thereby facilitating rerouting of communications involving the respective network entity based on the associated predefined rule (ZAFER, paragraph 0139, wherein “the disclosed system and method dynamically tracks the bindings between a user and the network (IP address, MAC address, physical port) as a user changes devices, plugs into a different sub-network, and receives a new IP address from a dynamic host configuration protocol (DHCP) server. According to some embodiments, the present system and method binds an application/network performance issue to specific traffic forwarding decisions”).
Therefore, it would have it would have been obvious to one ordinary skill in the art before the effective filing date of the invention to incorporate ZAFER teachings into Kasralikar to achieve the claimed limitations because this would have provided a way to dynamically assign appropriate network addresses to network entities to allow data communication between the network entities according to a specific policy/rule which enhances the system security and flexibility.
As per claim 4, claim 3 is incorporated and ZAFER further discloses wherein the address from the configuration update is allocated in a designated segment of addresses, wherein addresses in the designated segment are isolated such that communications directed to or from addresses in the designated segment are associated with one or more predefined rules pertaining to rerouting of communications to at least one DEAP (ZAFER, paragraph 0140, 0144-0145, 0148, wherein “the present system and method programs rules to drop traffic from/to user X's IP address(es) at the routers in the network”, “Another implementation of an automatic closed loop control is where the control objective is to maintain high performance for application X. In this case, the present system and method simply programs rules that place all traffic corresponding to that application into the highest performing queue. If improved application X performance is not observed, the present system and method attempts to program rules that re-route or rate-limit traffic from applications that share common network links with application X”; “The policy to prioritize user X.fwdarw.application Z traffic may be applied by the controller that sends rules to switch s3 that matches user X's IP address (as source IP) and the application server IP address (as destination IP), and has an action that marks the IP diffserv code point (DSCP) bits to represent the highest class of service”);
As per claim 16, claim 15 is incorporated and Kasralikar does not explicitly disclose wherein each address of each network entity in the subgroup emerges from a configuration update at a Dynamic Host Configuration Protocol (DHCP) server, assigning a new address to the respective network entity, thereby facilitating rerouting of communications involving the respective network to the DEAP, based on the associated predefined rule. However, using a DHCP server to assign new address is well known in the art. For example, ZAFER discloses wherein each address of each network entity in the subgroup emerges from a configuration update at a Dynamic Host Configuration Protocol (DHCP) server, assigning a new address to the respective network entity, thereby facilitating rerouting of communications involving the respective network to the DEAP, based on the associated predefined rule (ZAFER, paragraph 0139, wherein “the disclosed system and method dynamically tracks the bindings between a user and the network (IP address, MAC address, physical port) as a user changes devices, plugs into a different sub-network, and receives a new IP address from a dynamic host configuration protocol (DHCP) server. According to some embodiments, the present system and method binds an application/network performance issue to specific traffic forwarding decisions”).
Therefore, it would have it would have been obvious to one ordinary skill in the art before the effective filing date of the invention to incorporate ZAFER teachings into Kasralikar to achieve the claimed limitations because this would have provided a way to dynamically assign appropriate network addresses to network entities to allow data communication between the network entities according to a specific policy/rule which enhances the system security and flexibility.
As per claim 17, claim 16 is incorporated and ZAFER further discloses wherein the addresses from the configuration update are allocated in at least one designated segment of addresses, and are isolated such that communications directed to or from addresses in the designated segment are associated with one or more predefined rules, pertaining to rerouting of communications to at least one DEAP (ZAFER, paragraph 0140, 0144-0145, 0148, wherein “the present system and method programs rules to drop traffic from/to user X's IP address(es) at the routers in the network”, “Another implementation of an automatic closed loop control is where the control objective is to maintain high performance for application X. In this case, the present system and method simply programs rules that place all traffic corresponding to that application into the highest performing queue. If improved application X performance is not observed, the present system and method attempts to program rules that re-route or rate-limit traffic from applications that share common network links with application X”; “The policy to prioritize user X.fwdarw.application Z traffic may be applied by the controller that sends rules to switch s3 that matches user X's IP address (as source IP) and the application server IP address (as destination IP), and has an action that marks the IP diffserv code point (DSCP) bits to represent the highest class of service”);
Claim 21 is rejected under the same rationale as claim 3.
Claim 13 is rejected under 35 U.S.C. 103 as being unpatentable over Kasralikar et al (Pub. No.: US 2009/00003317 A1).
As per claim 13, claim 1 is incorporated and Kasralikar further discloses wherein the predefined rule involves monitoring communications to or from the DEAP to detect threats (Kasralikar, abstract, paragraph 0014, 0027-0028, wherein “The IPS may receive redirected data 223, for example, via any of a coaxial cable, a twisted pair cable, a parallel bus, a serial bus, etc. Traffic selector 208 may include a table 209 having entries that identify flows and/or services that have been flagged for further packet inspection. In this case, a data packet associated with a service that matches an entry in table 209 may be redirected to a port on switch 201 associated with IPS 211”). Kasralikar does not explicitly disclose wherein the DEAP is either the initiating network entity or the destination network entity. However, implementing the functions of the network service in the initiating network entity or the destination network entity would have been obvious to one ordinary skill in the art before the effective filing date of the invention because this would have provided a way to detect threats between communication originating and/or destined to the network service node and thus enhancing the system security.
Claim 26 is rejected under 35 U.S.C. 103 as being unpatentable over Kasralikar et al (Pub. No.: US 2009/00003317 A1) in view of Neil et al. (Pub. No.: US 2021/0406365 A1).
As per claim 26, Kasralikar discloses computer-implemented method for facilitating detection of threats in a network (Kasralikar, Fig 1, abstract, wherein “a method for selectively redirecting a data packet to a port on a switching device which is associated with a corresponding network service. In one embodiment, the data packet is redirected to an intrusion prevention service (IPS) for security analysis of the data packet”), comprising:- (Kasralikar, Fig 1, abstract, wherein “a method for selectively redirecting a data packet to a port on a switching device which is associated with a corresponding network service. In one embodiment, the data packet is redirected to an intrusion prevention service (IPS) for security analysis of the data packet”); and - applying at least one security method based on the determined type by executing operations by a processor of a router (Kasralikar, Fig 1, paragraph 0015, wherein “switching device 110 may be a multi-layer switch (MLS), a hybrid OSI L2/L3 switch router, or other network device having a switching capability”) on communication sent from an initiating network entity to a destination network entity, wherein at least one of the initiating network entity and the destination network entity (Kasralikar, Fig 1, paragraph 0019, wherein “At 105, switch 110 receives a data packet from the network 130, the data packet to be directed to one or more destinations in network 140”);- receiving, the communication, wherein the communication is directed from an initiating address of an initiating network entity to a destination address of a destination network entity (Kasralikar, Fig 1, paragraph 0019, wherein “At 105, switch 110 receives a data packet from the network 130, the data packet to be directed to one or more destinations in network 140”); - in accordance with a predefined rule associated with at least one of the initiating address or the destination address (Kasralikar, Fig 1, paragraph 0022, wherein “In one embodiment, the network condition may be a condition of the data packet itself. For example, the network condition may be a type of traffic which the data packet represents. This traffic type of the data packet may be indicated by information contained in the data packet itself. For example, the traffic type of the data packet may be based on information which includes, but is not limited to, a network source identifier of the data packet, a network destination identifier of the data packet, a protocol type of the data packet, a service type of the data packet, and/or an application associated with the data packet”), rerouting the communication to a designated appliance (DEAP) (Kasralikar, Fig 1 item 120, Fig 2 item 211, paragraph 0018, 0020, wherein “An embodiment of the invention selectively performs a data link layer redirect of a data packet to a port associated with an IPS. For the sake of clarity, "redirecting a data packet" refers herein to the sending of the data packet on a different network path, at least temporarily, instead of directing the data packet on any of the one or more destination paths to which the data packet was otherwise meant to be sent”), to enable monitoring of the communication to detect threats (Kasralikar, Fig 1, paragraph 0016, wherein “In one embodiment, network service 120 may provide an intrusion prevention service (IPS) to detect security threats found in network traffic of switching device 110”), wherein the predefined rule is indicative of a required security monitoring of communications involving at least one of the initiating network entity or the destination network entity (Kasralikar, Fig 1, paragraph 0031, wherein “Detected conditions (e.g., a spike in traffic, traffic congestion, etc.) are analyzed using the rules and/or thresholds of the set of policies 207 to determine whether a service or flow associated with a detected condition warrants further inspection by IPS 211. In one embodiment, sensors 210 may detect an abnormal increase in email traffic entering switch 201. If the abnormality triggers a rule or exceeds a threshold of one of the set of policies 207, then selection manager 206 may automatically update table 209 to include email traffic”); and - in case no indication of a threat is identified, routing the communication to the destination network entity (Kasralikar, Fig 1-2, paragraph 0020, wherein “Based at least in part on a result of the performed analysis, the redirected data packet may be returned, at 125, from the network service 120 to the switching device 110. In one embodiment of the invention, any returned data packet may be sent from switching device 110 to at least one of the one or more destinations in network 140”). Kasralikar does not explicitly disclose selecting at least one group of network entities, based on a respective calculated risk score of the one or more network entities. However, Neil discloses selecting at least one group of network entities, based on a respective calculated risk score of the one or more network entities (Neil, paragraph 0054, wherein “Once all nodes and edges of an enterprise are sorted according to their corresponding risk score at block 302, embodiments of the present disclosure select the edge or node with the highest risk score at block 304 to form a new sub-graph at block 306. Initially, the sub-graph at block 306 may only contain a single node or edge. At block 308, embodiments of the present disclosure sort the reachable nodes, edges, and sub-graphs connected to new sub-graph formed at block 306 by their corresponding risk score. Reachable nodes, edges, and sub-graphs include any node, edge, or combination thereof (e.g., sub-graph) that is can be reached via another node, edge, and/or sub-graph. In other words, embodiments of the present disclosure search for all enterprise objects connected to the sub-graph formed at block 306. For example, the sub-graph formed at block 306 may be able to reach another node having the highest probability through a series of edges connected to other nodes. After the reachable nodes, edges, and sub-graphs are sorted according to their corresponding risk scores at block 308, embodiments of the present disclosure select the highest risk probability reachable enterprise object(s) such as nodes, edges, sub-graph or combination thereof”).
Therefore, it would have it would have been obvious to one ordinary skill in the art before the effective filing date of the invention to incorporate Neil teachings into Kasralikar to achieve the claimed limitations because this would have provided a way to identify malicious behavior in an enterprise by focusing on the most suspicious computing behaviors among nodes in a computing environment and thus improve the accuracy and efficiency.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HAMZA N ALGIBHAH whose telephone number is (571)270-7212. The examiner can normally be reached 7:30 am - 3:30 pm.
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, Wing Chan can be reached on (571) 272-7493. 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.
/HAMZA N ALGIBHAH/Primary Examiner, Art Unit 2441