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 .
Response to Arguments
In response to 35 USC 103 on pages 9-11, filed 09/19/2025, for independent claims 1, 10 and 16 along with their respective dependent claims, applicant argues that Feier and Compton fails to teach or suggest the claim element admittedly absent from White and Yermakov.
Applicant’s argument have been considered but are moot, because the newly recited amendment does not rely on the newly recited reference being applied to the prior rejection of record or any teaching or matter specifically challenged in the argument.
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.
Claims 1-20 are 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.
Regarding claims 1, 10 and 16, the phrase "such that" renders the claim indefinite because it is unclear whether the limitations following the phrase are part of the claimed invention. See MPEP § 2173.05(d).
Re. claims 2-9, 11-15 and 17-20 fall together accordingly as they do not cure the deficiencies of the independent claims.
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 1-3, 6-12, 14-17 and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over White (US 11870754) in view of Yermakov (US 20180288081) and in further view of Uzelac et al. (US 20230029971, hereinafter Uzelac).
Re. claim 1, White discloses a method comprising: receiving, by a device on a network, a packet stream from a user device (White discloses a packet stream being sent from an example source 30 to an example destination 40. A packet is received from the source 30 at the receiving router [Col 9 lines 22-27]);
determining, by the device, based on the policy information based analysis, whether deep inspection is required for the packet stream of the user device (White discloses packets are received from a source external to the network one or more of the packets are identified as requiring deep packet inspection. Policy updates carrying instructions on handling packets. [Col 2 lines 1-41]), the determination further comprising: when the determination indicates that deep packet inspection is not required, determining the packet stream of the user device to proceed to a next-hop router on the network (White discloses packets not requiring deep packet inspection being routed with a higher priority than packets requiring deep packet inspection one or more copies are made of each packet carrying indicating data. Packets that do not have indicating data identifying the packet as requiring deep packet inspection, the downstream router forwards such packets to addresses specified in a packet header for packets having indicating data identifying the packet as requiring deep packet inspection [Col 2 lines 1-41]), and when the determination indicates that deep packet inspection is required, diverting the packet stream for the deep packet inspection (White discloses packets may be subject to DPI, but in others packets initially identified as potentially damaging (hereinafter referred to as “suspicious” packets) may be marked for further investigation before release [Col 4 lines 44-59]. The control plane 5 can transmit instructions to the various network elements 1, 2, 3, 4, 7 to perform an operation on all packets carrying the same marking. This allows all packets in such a group to be released from a cache, forwarded, deleted, or have their priority modified in response to completion of analysis of a sample of one or more packets from the group [Col 8 line 52 – Col 9 line 2]. The decision may be to forward the packet to a destination beyond the DPIDA group. If the packet is cleared for release, then the downstream edge router removes any shims or flags that were used within the group to mark this packet as being subject to a DPI process and not ready for release outside the group, and forwards it to a destination beyond the DPIDA group [Col 13 line 64 – Col 14 line 3] Figs. 1, 5 and 8);
and outputting, by the device, the packet stream based on the determination (White discloses messages may be transmitted ‘downstream’ i.e. towards the intended destination or exit router [Col 4 lines 23-38]. Each packet may be analyzed by a respective member of the plurality of computing resources, or each packet may be analyzed by a plurality of computing resources, each resource performing a respective test on the packets and transmitting a report to the downstream route [Col 3 lines 19-31]), the outputting comprising: communicating the packet stream to the next-hop router on the network when deep packet inspection is determined to not be required (White discloses packets not requiring deep packet inspection being routed with a higher priority than packets requiring deep packet inspection one or more copies are made of each packet carrying indicating data. Packets that do not have indicating data identifying the packet as requiring deep packet inspection, the downstream router forwards such packets to addresses specified in a packet header for packets having indicating data identifying the packet as requiring deep packet inspection [Col 2 lines 1-41][Col 11 lines 44-52]).
Although White discloses analyzing traffic with policy information, White does not explicitly teach but Yermakov teaches generating, by the device, flow data records based on the packet stream, the flow data records comprising information related to activity of the user device on the network (Yermakov teaches if the network device receives any additional packets with these characteristics, the network device regards the packets as belonging to a new data flow and represents them with a new network flow data record. Each network flow record, such as a netflow record, may include, but is not limited to, the data flow's (1) source and destination IP addresses, (2) source port number and destination port number, (3) type of layer 3 protocol (e.g., TCP or UDP), (4) start and end times, (5) size (e.g., number of bytes), and (6) input logical interface (ifIndex). The last field, input logical interface, is also called a circuit, which can be used to identify a user (e.g., a subscriber to the network services provided by a service provider) [0021]);
analyzing, by the device, the flow data records based on policy information, the policy information indicating a criteria for controlling data traffic on the network (Yermakov teaches a detection module so that the detection module could process and analyze the flow data, and detect possible network anomalies based on the analysis [0031][0048][0014-0015]).
Therefore, it would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to modify the method and system disclosed by White to include generating, by the device, flow data records based on the packet stream, the flow data records comprising information related to activity of the user device on the network; analyzing, by the device, the flow data records based on policy information, the policy information indicating a criteria for controlling data traffic on the network as disclosed by Yermakov. One of ordinary skill in the art would have been motivated for the purpose of detecting possible network anomalies and treat network flow records (Yermakov [0031][0019]).
White discloses diverting the packet stream for the deep packet inspection, the combination of White-Yermakov does not explicitly teach but Uzelac teaches diverting the packet stream to another node on the network, such that performance of the deep packet inspection is performed at the other node, the diversion of the packet stream to the other node occurring prior to the packet stream being routed to the next-hop router from the other node (Uzelac teaches the computing system may reroute the first SIP data to a security deep packet inspection (“DPI”) engine. The security DPI engine may perform a deep scan of the received first SIP data to identify any known fraudulent or malicious attack vectors contained within the received first SIP data and to determine whether the calling party is a known malicious entity or whether the source address is associated with a known malicious entity [0018]);
and causing the other node, upon completion of the deep packet inspection, to send the packet stream to the next-hop router, the caused sending of the packet stream comprising information related a result of the deep packet inspection that controls how the next-hop router handles the packet stream upon reception (Uzelac teaches reroute the SIP data to a security DPI engine for a deep scan in the case the policy engine encounters, discovers, or identifies signs or indication of potential fraudulent or malicious actions when analyzing the SIP data or the like. Send instructions to one or more routers 145 and/or one or more routers 150 to control routing of network traffic data with network [0049] Fig. 1), such that: when the deep packet inspection information indicates a warning related to the packet stream, the next-hop router quarantines the packet stream and sends to a destination on the network an indication that the packet stream is being blocked from being sent from the next-hop router (Uzelac teaches rerouting or blocking all network traffic to the destination address from the source address [0034] Fig. 1), and when the deep packet inspection information indicates approval of the packet stream, the next-hop router is enabled to send the packet stream to the destination on the network (Uzelac teaches that the deep scan of the received first SIP data does not reveal or identify any known fraudulent or malicious then establish session [0018-0019][0054] Fig. 1).
Therefore, it would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to modify the method and system disclosed by the combination of White-Yermakov to include diverting the packet stream to another node on the network, such that performance of the deep packet inspection is performed at the other node, the diversion of the packet stream to the other node occurring prior to the packet stream being routed to the next-hop router from the other node; and causing the other node, upon completion of the deep packet inspection, to send the packet stream to the next-hop router, the caused sending of the packet stream comprising information related a result of the deep packet inspection that controls how the next-hop router handles the packet stream upon reception, such that: when the deep packet inspection information indicates a warning related to the packet stream, the next-hop router quarantines the packet stream and sends to a destination on the network an indication that the packet stream is being blocked from being sent from the next-hop router, and when the deep packet inspection information indicates approval of the packet stream, the next-hop router is enabled to send the packet stream to the destination on the network as disclosed by Uzelac. One of ordinary skill in the art would have been motivated for the purpose of determining malicious entity and performing mitigations actions (Uzelac [0027]).
Re. claim 2, the combination of White-Yermakov-Uzelac teach the method of claim 1, further comprising: receiving, by the device, policy data for performing the deep packet inspection; and performing the deep packet inspection based on the policy data (White discloses the network comprises one or more caches which are capable of storing packets indexed according to respective values of the indicating data, and in response to the policy updates perform forwarding or deletion actions on the packets. Each router in the network may have a routing table carrying instructions on forward routing caches of packets received over the network, and wherein the routing instructions are dependent on the indicating data carried by the packets [Col 2 lines 42-67]).
Re. claim 3, the combination of White-Yermakov-Uzelac teach the method of claim 2, further comprising: analyzing a header and contents of each packet in the data stream based on the policy data, wherein the deep packet inspection is based on the header and packet content analysis (White discloses the downstream router forwards such packets to addresses specified in a packet header for packets having indicating data identifying the packet as requiring deep packet inspection Col 2 lines 1-41]).
Re. claim 6, the combination of White-Yermakov-Uzelac teach the method of claim 1, further comprising: routing, by the device, information related to the packet stream to the next-hop router based on the deep packet inspection, wherein the information routed is based on a result of the deep packet stream (White discloses the routing policy information may be forwarded to all devices on the network, or alternatively only those anticipated by the control plane to see the group of packets to which the policy applies. This will include the receiving router 1, and in the case of the receiving router the policy forwarded will include an instruction to release and forward to a next destination [Col 11 lines 44-52]).
Re. claim 7, the combination of White-Yermakov-Uzelac teach the method of claim 1, further comprising: receiving, by the device, the set of policy information, wherein the set of policy information is based on a type of protocol implemented by the network (White discloses the routing policy information may be forwarded to all devices on the network, or alternatively only those anticipated by the control plane to see the group of packets to which the policy applies. This will include the receiving router 1, and in the case of the receiving router the policy forwarded will include an instruction to release and forward to a next destination [Col 11 lines 44-52]).
Re. claim 8, the combination of White-Yermakov-Uzelac teach the method of claim 1, wherein the criteria of the policy information relates to at least one of a type, value, pattern and identity of activity on the network (White discloses the network devices may store control policy instructions which are sent to them from the control plane or directly from the computational analysis components. These include policies to either drop packets with a certain tag or combination of tags, or to forward packets to a location, which may be amended or determined by the policy itself, or may simply be a policy to forward packets to the default location stored in the network device's routing table [Col 6 lines 37-44]. A packet identified as benign would have a malignity value of zero [Col 3 lines 1-2]).
Re. claim 9, the combination of White-Yermakov-Uzelac teach the method of claim 1, wherein the flow data records comprise information related to at least one of a source, a destination, protocol in use on the network, protocol information, a number of bytes/octets sent and received, a data and time of packet transmission and reception (Yermakov teaches if the network device receives any additional packets with these characteristics, the network device regards the packets as belonging to a new data flow and represents them with a new network flow data record. Each network flow record, such as a netflow record, may include, but is not limited to, the data flow's (1) source and destination IP addresses, (2) source port number and destination port number, (3) type of layer 3 protocol (e.g., TCP or UDP), (4) start and end times, (5) size (e.g., number of bytes), and (6) input logical interface (ifIndex). The last field, input logical interface, is also called a circuit, which can be used to identify a user (e.g., a subscriber to the network services provided by a service provider) [0021]).
Therefore, it would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to modify the method and system disclosed by White to include wherein the flow data records comprise information related to at least one of a source, a destination, protocol in use on the network, protocol information, a number of bytes/octets sent and received, a data and time of packet transmission and reception as disclosed by Yermakov. One of ordinary skill in the art would have been motivated for the purpose of detecting possible network anomalies and treat network flow records (Yermakov [0031][0019]).
Re. claim 10, White discloses a device comprising: a processor configured to (White discloses a network device containing a processor [Col 14 7-19]): receive a packet stream from a user device (White discloses a packet stream being sent from an example source 30 to an example destination 40. A packet is received from the source 30 at the receiving router [Col 9 lines 22-27]); and determine, based on the policy information based analysis, whether deep inspection is required for the packet stream of the user device (White discloses packets are received from a source external to the network one or more of the packets are identified as requiring deep packet inspection. Policy updates carrying instructions on handling packets. [Col 2 lines 1-41]), wherein the processor is further configured to: when the determination indicates that deep packet inspection is not required, enable the packet stream of the user device to proceed to a next-hop router on the network (White discloses packets not requiring deep packet inspection being routed with a higher priority than packets requiring deep packet inspection one or more copies are made of each packet carrying indicating data. Packets that do not have indicating data identifying the packet as requiring deep packet inspection, the downstream router forwards such packets to addresses specified in a packet header for packets having indicating data identifying the packet as requiring deep packet inspection [Col 2 lines 1-41]), and when the determination indicates that deep packet inspection is required, divert the packet stream for the deep packet inspection (White discloses packets may be subject to DPI, but in others packets initially identified as potentially damaging (hereinafter referred to as “suspicious” packets) may be marked for further investigation before release [Col 4 lines 44-59]. The control plane 5 can transmit instructions to the various network elements 1, 2, 3, 4, 7 to perform an operation on all packets carrying the same marking. This allows all packets in such a group to be released from a cache, forwarded, deleted, or have their priority modified in response to completion of analysis of a sample of one or more packets from the group [Col 8 line 52 – Col 9 line 2]. The decision may be to forward the packet to a destination beyond the DPIDA group. If the packet is cleared for release, then the downstream edge router removes any shims or flags that were used within the group to mark this packet as being subject to a DPI process and not ready for release outside the group, and forwards it to a destination beyond the DPIDA group [Col 13 line 64 – Col 14 line 3] Figs. 1, 5 and 8); And output he packet stream based on the determination (White discloses messages may be transmitted ‘downstream’ i.e. towards the intended destination or exit router [Col 4 lines 23-38]. Each packet may be analyzed by a respective member of the plurality of computing resources, or each packet may be analyzed by a plurality of computing resources, each resource performing a respective test on the packets and transmitting a report to the downstream route [Col 3 lines 19-31]), the output comprising: communicating the packet stream to the next-hop router on the network when deep packet inspection is determined to not be required (White discloses packets not requiring deep packet inspection being routed with a higher priority than packets requiring deep packet inspection one or more copies are made of each packet carrying indicating data. Packets that do not have indicating data identifying the packet as requiring deep packet inspection, the downstream router forwards such packets to addresses specified in a packet header for packets having indicating data identifying the packet as requiring deep packet inspection [Col 2 lines 1-41][Col 11 lines 44-52]).
Although White discloses analyzing traffic with policy information, White does not explicitly teach but Yermakov teaches generate flow data records based on the packet stream, the flow data records comprising information related to activity of the user device on the network (Yermakov teaches if the network device receives any additional packets with these characteristics, the network device regards the packets as belonging to a new data flow and represents them with a new network flow data record. Each network flow record, such as a netflow record, may include, but is not limited to, the data flow's (1) source and destination IP addresses, (2) source port number and destination port number, (3) type of layer 3 protocol (e.g., TCP or UDP), (4) start and end times, (5) size (e.g., number of bytes), and (6) input logical interface (ifIndex). The last field, input logical interface, is also called a circuit, which can be used to identify a user (e.g., a subscriber to the network services provided by a service provider) [0021]);
analyze the flow data records based on policy information, the policy information indicating a criteria for controlling data traffic on the network (Yermakov teaches a detection module so that the detection module could process and analyze the flow data, and detect possible network anomalies based on the analysis [0031][0048][0014-0015]).
Therefore, it would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to modify the method and system disclosed by White to include generating, by the device, flow data records based on the packet stream, the flow data records comprising information related to activity of the user device on the network; analyzing, by the device, the flow data records based on policy information, the policy information indicating a criteria for controlling data traffic on the network as disclosed by Yermakov. One of ordinary skill in the art would have been motivated for the purpose of detecting possible network anomalies and treat network flow records (Yermakov [0031][0019]).
White discloses diverting the packet stream for the deep packet inspection, the combination of White-Yermakov does not explicitly teach but Uzelac teaches divert the packet stream to another node on the network, such that performance of the deep packet inspection is performed at the other node , the diversion of the packet stream to the other node occurring prior to the packet stream being routed to the next-hop router from the other node (Uzelac teaches the computing system may reroute the first SIP data to a security deep packet inspection (“DPI”) engine. The security DPI engine may perform a deep scan of the received first SIP data to identify any known fraudulent or malicious attack vectors contained within the received first SIP data and to determine whether the calling party is a known malicious entity or whether the source address is associated with a known malicious entity [0018]);
and causing the other node, upon completion of the deep packet inspection, to send the packet stream to the next-hop router, the caused sending of the packet stream comprising information related a result of the deep packet inspection that controls how the next-hop router handles the packet stream upon reception (Uzelac teaches reroute the SIP data to a security DPI engine for a deep scan in the case the policy engine encounters, discovers, or identifies signs or indication of potential fraudulent or malicious actions when analyzing the SIP data or the like. Send instructions to one or more routers 145 and/or one or more routers 150 to control routing of network traffic data with network [0049] Fig. 1), such that: when the deep packet inspection information indicates a warning related to the packet stream, the next-hop router quarantines the packet stream and sends to a destination on the network an indication that the packet stream is being blocked from being sent from the next-hop router (Uzelac teaches rerouting or blocking all network traffic to the destination address from the source address [0034] Fig. 1), and when the deep packet inspection information indicates approval of the packet stream, the next-hop router is enabled to send the packet stream to the destination on the network (Uzelac teaches that the deep scan of the received first SIP data does not reveal or identify any known fraudulent or malicious then establish session [0018-0019][0054] Fig. 1).
Therefore, it would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to modify the method and system disclosed by the combination of White-Yermakov to include diverting the packet stream to another node on the network, such that performance of the deep packet inspection is performed at the other node, the diversion of the packet stream to the other node occurring prior to the packet stream being routed to the next-hop router from the other node; and causing the other node, upon completion of the deep packet inspection, to send the packet stream to the next-hop router, the caused sending of the packet stream comprising information related a result of the deep packet inspection that controls how the next-hop router handles the packet stream upon reception, such that: when the deep packet inspection information indicates a warning related to the packet stream, the next-hop router quarantines the packet stream and sends to a destination on the network an indication that the packet stream is being blocked from being sent from the next-hop router, and when the deep packet inspection information indicates approval of the packet stream, the next-hop router is enabled to send the packet stream to the destination on the network as disclosed by Uzelac. One of ordinary skill in the art would have been motivated for the purpose of determining malicious entity and performing mitigations actions (Uzelac [0027]).
Re. claim 11, rejection of claim 10 is included and claim 11 is rejected with the same rationale as applied in claim 2 above.
Re. claim 12, rejection of claim 11 is included and claim 12 is rejected with the same rationale as applied in claim 3 above.
Re. claim 14, rejection of claim 10 is included and claim 14 is rejected with the same rationale as applied in claim 6 above.
Re. claim 15, rejection of claim 10 is included and claim 15 is rejected with the same rationale as applied in claims 7 and 8 above.
Re. claim 16, White discloses the limitation of when executed by a processor of a device (White discloses a network device containing a processor [Col 14 7-19]. A memory [Col 6 lines 49-52]), perform a method comprising: receiving, by the device on a network, a packet stream from a user device(White discloses a packet stream being sent from an example source 30 to an example destination 40. A packet is received from the source 30 at the receiving router [Col 9 lines 22-27]);
and determining, by the device, based on the policy information based analysis, whether deep inspection is required for the packet stream of the user device (White discloses packets are received from a source external to the network one or more of the packets are identified as requiring deep packet inspection. Policy updates carrying instructions on handling packets. [Col 2 lines 1-41]), the determination further comprising: when the determination indicates that deep packet inspection is not required, enabling the packet stream of the user device to proceed to a next-hop router on the network (White discloses packets not requiring deep packet inspection being routed with a higher priority than packets requiring deep packet inspection one or more copies are made of each packet carrying indicating data. Packets that do not have indicating data identifying the packet as requiring deep packet inspection, the downstream router forwards such packets to addresses specified in a packet header for packets having indicating data identifying the packet as requiring deep packet inspection [Col 2 lines 1-41]), and when the determination indicates that deep packet inspection is required, diverting the packet stream for the deep packet inspection (White discloses packets may be subject to DPI, but in others packets initially identified as potentially damaging (hereinafter referred to as “suspicious” packets) may be marked for further investigation before release [Col 4 lines 44-59]. The control plane 5 can transmit instructions to the various network elements 1, 2, 3, 4, 7 to perform an operation on all packets carrying the same marking. This allows all packets in such a group to be released from a cache, forwarded, deleted, or have their priority modified in response to completion of analysis of a sample of one or more packets from the group [Col 8 line 52 – Col 9 line 2]. The decision may be to forward the packet to a destination beyond the DPIDA group. If the packet is cleared for release, then the downstream edge router removes any shims or flags that were used within the group to mark this packet as being subject to a DPI process and not ready for release outside the group, and forwards it to a destination beyond the DPIDA group [Col 13 line 64 – Col 14 line 3] Figs. 1, 5 and 8);
and outputting, by the device, the packet stream based on the determination (White discloses messages may be transmitted ‘downstream’ i.e. towards the intended destination or exit router [Col 4 lines 23-38]. Each packet may be analyzed by a respective member of the plurality of computing resources, or each packet may be analyzed by a plurality of computing resources, each resource performing a respective test on the packets and transmitting a report to the downstream route [Col 3 lines 19-31]), the outputting comprising: communicating the packet stream to the next-hop router on the network when deep packet inspection is determined to not be required (White discloses packets not requiring deep packet inspection being routed with a higher priority than packets requiring deep packet inspection one or more copies are made of each packet carrying indicating data. Packets that do not have indicating data identifying the packet as requiring deep packet inspection, the downstream router forwards such packets to addresses specified in a packet header for packets having indicating data identifying the packet as requiring deep packet inspection [Col 2 lines 1-41][Col 11 lines 44-52]).
Although White discloses analyzing traffic with policy information, White does not explicitly teach but Yermakov teaches generating, by the device, flow data records based on the packet stream, the flow data records comprising information related to activity of the user device on the network (Yermakov teaches if the network device receives any additional packets with these characteristics, the network device regards the packets as belonging to a new data flow and represents them with a new network flow data record. Each network flow record, such as a netflow record, may include, but is not limited to, the data flow's (1) source and destination IP addresses, (2) source port number and destination port number, (3) type of layer 3 protocol (e.g., TCP or UDP), (4) start and end times, (5) size (e.g., number of bytes), and (6) input logical interface (ifIndex). The last field, input logical interface, is also called a circuit, which can be used to identify a user (e.g., a subscriber to the network services provided by a service provider) [0021]);
analyzing, by the device, the flow data records based on policy information, the policy information indicating a criteria for controlling data traffic on the network (Yermakov teaches a detection module so that the detection module could process and analyze the flow data, and detect possible network anomalies based on the analysis [0031][0048][0014-0015]).
Therefore, it would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to modify the method and system disclosed by White to include generating, by the device, flow data records based on the packet stream, the flow data records comprising information related to activity of the user device on the network; analyzing, by the device, the flow data records based on policy information, the policy information indicating a criteria for controlling data traffic on the network as disclosed by Yermakov. One of ordinary skill in the art would have been motivated for the purpose of detecting possible network anomalies and treat network flow records (Yermakov [0031][0019]).
White discloses diverting the packet stream for the deep packet inspection, the combination of White-Yermakov does not explicitly teach but Uzelac teaches diverting the packet stream to another node on the network, such that performance of the deep packet inspection is performed at the other node (Uzelac teaches the computing system may reroute the first SIP data to a security deep packet inspection (“DPI”) engine. The security DPI engine may perform a deep scan of the received first SIP data to identify any known fraudulent or malicious attack vectors contained within the received first SIP data and to determine whether the calling party is a known malicious entity or whether the source address is associated with a known malicious entity [0018]);
and causing the other node, upon completion of the deep packet inspection, to send the packet stream to the next-hop router, the caused sending of the packet stream comprising information related a result of the deep packet inspection that controls how the next-hop router handles the packet stream upon reception (Uzelac teaches reroute the SIP data to a security DPI engine for a deep scan in the case the policy engine encounters, discovers, or identifies signs or indication of potential fraudulent or malicious actions when analyzing the SIP data or the like. Send instructions to one or more routers 145 and/or one or more routers 150 to control routing of network traffic data with network [0049] Fig. 1), such that: when the deep packet inspection information indicates a warning related to the packet stream, the next-hop router quarantines the packet stream and sends to a destination on the network an indication that the packet stream is being blocked from being sent from the next-hop router (Uzelac teaches rerouting or blocking all network traffic to the destination address from the source address [0034] Fig. 1), and when the deep packet inspection information indicates approval of the packet stream, the next-hop router is enabled to send the packet stream to the destination on the network (Uzelac teaches that the deep scan of the received first SIP data does not reveal or identify any known fraudulent or malicious then establish session [0018-0019][0054] Fig. 1).
Therefore, it would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to modify the method and system disclosed by the combination of White-Yermakov to include diverting the packet stream to another node on the network, such that performance of the deep packet inspection is performed at the other node, the diversion of the packet stream to the other node occurring prior to the packet stream being routed to the next-hop router from the other node; and causing the other node, upon completion of the deep packet inspection, to send the packet stream to the next-hop router, the caused sending of the packet stream comprising information related a result of the deep packet inspection that controls how the next-hop router handles the packet stream upon reception, such that: when the deep packet inspection information indicates a warning related to the packet stream, the next-hop router quarantines the packet stream and sends to a destination on the network an indication that the packet stream is being blocked from being sent from the next-hop router, and when the deep packet inspection information indicates approval of the packet stream, the next-hop router is enabled to send the packet stream to the destination on the network as disclosed by Uzelac. One of ordinary skill in the art would have been motivated for the purpose of determining malicious entity and performing mitigations actions (Uzelac [0027]).
Re. claim 17, rejection of claim 16 is included and claim 17 is rejected with the same rationale as applied in claims 2 and 3 above.
Re. claim 19, rejection of claim 16 is included and claim 19 is rejected with the same rationale as applied in claim 6 above.
Re. claim 20, rejection of claim 16 is included and claim 20 is rejected with the same rationale as applied in claims 7 and 8 above.
Claims 4, 5, 13 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over White (US 11870754) in view of Yermakov (US 20180288081), in view of Uzelac et al. (US 20230029971, hereinafter Uzelac) and in further view of Ramamurthy et al. (US 9864422, hereinafter Ramamurthy).
Re. claim 4, the combination of White-Yermakov-Uzelac teach the method of claim 1, further comprising: the combination of White-Yermakov-Uzelac do not explicitly teach but Ramamurthy teaches determining, by the device, based at least on the policy information based analysis, a time to perform the deep packet inspection; and performing the deep packet inspection at the determined time (Ramamurthy teaches deep packet inspection can be performed for any amount of time. In some embodiments, deep packet inspection is performed for a predetermined amount of time. In other embodiments, deep packet inspection is performed for an amount of time determined, for example, by the management entity, the connectivity gateway 210, and/or the deep packet inspector 212. For instance, such an amount of time may be determined based on amount of traffic flow to and/or from the user device, number of transitions detected, upon a lapse of a time, such as 30 minutes, without any data flow, or the like [Col 12 lines 38-48]).
Therefore, it would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to modify the method and system disclosed by the combination of White-Yermakov-Uzelac to include determining, by the device, based at least on the policy information based analysis, a time to perform the deep packet inspection; and performing the deep packet inspection at the determined time as disclosed by Ramamurthy. One of ordinary skill in the art would have been motivated for the purpose of pattern(s) exhibited by the user device, an inactivity time duration used by a communication tower can be established for the specific user device to avoid unnecessary transitions between active and idle states, triggering deep packet inspection (Ramamurthy [Col 1 lines 14-27]).
Re. claim 5, the combination of White-Yermakov-Uzelac-Ramamurthy teach the method of claim 4, wherein the time determination is based on a type of anomaly identified during the policy information based analysis (Ramamurthy teaches deep packet inspection can be performed for any amount of time. In some embodiments, deep packet inspection is performed for a predetermined amount of time. In other embodiments, deep packet inspection is performed for an amount of time determined, for example, by the management entity, the connectivity gateway 210, and/or the deep packet inspector 212. For instance, such an amount of time may be determined based on amount of traffic flow to and/or from the user device, number of transitions detected, upon a lapse of a time, such as 30 minutes, without any data flow, or the like [Col 12 lines 38-48]).
Therefore, it would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to modify the method and system disclosed by the combination of White-Yermakov-Uzelac to include wherein the time determination is based on a type of anomaly identified during the policy information based analysis as disclosed by Ramamurthy. One of ordinary skill in the art would have been motivated for the purpose of pattern(s) exhibited by the user device, an inactivity time duration used by a communication tower can be established for the specific user device to avoid unnecessary transitions between active and idle states, triggering deep packet inspection (Ramamurthy [Col 1 lines 14-27]).
Re. claim 13, rejection of claim 10 is included and claim 13 is rejected with the same rationale as applied in claims 4 and 5 above.
Re. claim 18, rejection of claim 16 is included and claim 18 is rejected with the same rationale as applied in claims 4 and 5 above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Lu et al. (US 20190075056, hereinafter Lu) discloses the traffic flow data record includes a firewall rule ID field 510, a logical entity (e.g., a virtual interface (VIF)) UUID field 520, a set of fields 530 for a set of flow identifiers (e.g., an n-tuple comprising n separate data fields), and additional fields 540 that contain additional information.
Di Pietro et al. (US 20170099310, hereinafter Pietro) discloses traffic flow data/records (e.g., Netflow records, IPFIX information, etc.), 2.) raw packets, and/or 3.) other information from other sources regarding the state of the network (e.g., device information such as queue states, processor or memory usage, etc.).
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 KEVIN A AYALA whose telephone number is (571)270-3912. The examiner can normally be reached Monday-Thursday 8AM-5PM; Friday: Variable EST.
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, Jorge Ortiz-Criado can be reached at 571-272-7624. 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.
/KEVIN AYALA/Primary Examiner, Art Unit 2496