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 .
DETAILED ACTION
The instant application having Application No. 18/779,683 is presented for examination by
the examiner. Claims 1, 8 and 15 are amended. Claims 1-20 have been examined.
Response to Arguments
Applicant mainly argues that the proposed Pandian/Neil combination is improper because combining the references would change the principle of operation of Pandian, render Pandian inoperable for its intended purpose, Neil teaches away from Pandian's approach, and there is no reasonable expectation of success. However, the examiner disagrees. The modification proposed by the examiner does not require transforming Pandian's device profile architecture into a path centric graph system. Rather, the examiner proposes incorporating Neil's technique of associating historical network communications with anomalous or safe path indications into Pandian's existing machine learning framework as a labeled training data enhancement and not replacing Pandian's classifier mechanism. Neil's criticism of conventional host detection is directed to standalone device monitoring and does not discourage using Neil's path anomaly indications as supplemental training data in a system that also performs device level analysis. Both references are directed to network anomaly detection using historical communications, and a skilled artisan would have reasonably expected success in augmenting Pandian's training corpus with Neil's path level anomaly indications, as such data augmentation is a well understood practice in the network security and machine learning arts. Therefore, Applicant's arguments are not persuasive in light of the above explanation.
Applicant further argues that neither Pandian nor Neil teaches a memory configured to store a training dataset wherein each historical data communication is associated with an indication of an anomalous or safe network path. However, the examiner disagrees. Based on broadest reasonable interpretation, Neil teaches or at least suggests the disputed limitation by disclosing collecting individual network communication data as triples comprising a time of communication, a source IP address, and a destination IP address for communications between hosts, analyzing that collected data to detect anomalous behavior during a predetermined time period, and providing an indication that anomalous behavior occurred (Neil ¶¶0132–0134: data collected from host agents includes a list of triples indicating network communications between hosts; the collected data is analyzed to detect anomalous behavior during a predetermined time period, and when anomalous behavior is detected, an indication that the anomalous behavior occurred is provided). Under BRI, the claim does not require a particular data structure or storage format, Neil's collection of individual historical communications and generation of associated anomaly indications satisfies the claimed training dataset structure. Therefore, Applicant's argument is not persuasive in light of the above explanation.
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-4, 7-11, and 14-18 are rejected under 35 U.S.C. 103 as being unpatentable over Pandian (US 20200076853 A1), in view of Neil (US 20150020199 A1) and Nakil (US 20130332602 A1).
Regarding Claim 1
Pandian discloses:
A system comprising:
a processor, operably coupled to the memory, and configured to:
access a data packet that is intended to be communicated to a first destination device in a network (Pandian ¶60–63, 67: traffic sensors (e.g., TAP/SPAN) capture data packets transmitted to and/or from devices in the network and send copies of those packets to the device management system for analysis.);
extract a first set of network features from the data packet, wherein the first set of network features comprises at least one of content, a type of request, an Internet Protocol (IP) address of a source device, or an IP address of the first destination device (Pandian ¶79, 139: data packets are parsed, interpreted, and analyzed to determine attribute values, including flow attributes such as source and destination IP addresses and ports.),
determine a network path associated with the data packet based at least in part upon the extracted first set of network features (Pandian ¶79, 137: extracted network features including source and destination addresses are used to associate data packets with a communication session, where packets transmitted between a particular source address and destination address are determined to be part of the same communication session.);
determine, using a machine learning algorithm, based at least in part upon the training dataset and the extracted first set of network features, that the first destination device is anomalous (Pandian ¶51-52, 96: expected attribute values are learned via supervised or unsupervised machine learning from previously observed communication attributes, extracted network features including source and destination network addresses are evaluated against the learned expected values, and a device (including a destination device) is determined to exhibit anomalous behavior when its communication attributes fall outside the learned expected values, where the anomaly determination is based in part on the network addresses with which the device is communicating.); and
in response to determining that the first destination device is anomalous, perform one or more countermeasure actions, wherein the one or more countermeasure actions comprise preventing the data packet from traversing to the first destination device in the network (Pandian ¶51, 227: teaches that in response to determining a device is anomalous, the system performs countermeasure actions, including re-routing packets that are otherwise intended for a destination address instead of transmitting them as intended, thereby preventing the data packets from traversing to the destination device.).
Pandian discloses collecting and analyzing network communications using machine learning to detect anomalous network behavior based on extracted network features and historical communication data. Pandian, however, does not expressly disclose that each historical data communication stored in memory is associated with an explicit indication of whether a corresponding network path is anomalous or safe. On the other hand, Neil discloses storing and analyzing historical network communications, including network paths formed by communications between computing systems, and determining whether those paths are anomalous or normal based on statistical models derived from historical baseline parameters. Neil further discloses that historical parameters representing normal activity levels are compared against observed network paths to identify anomalous paths, thereby associating historical network communications with indications of anomalous or safe network paths (Neil ¶10-11, 26-27 and 132-134).
It would have been obvious to one of ordinary skill in the art to incorporate Neil’s technique of associating historical network communications with anomalous or safe network and path indications into the system of Pandian in order to improve the accuracy and effectiveness of Pandian’s machine learning based anomaly detection. Both references are directed to detecting anomalous behavior in network communications using historical data, and the modification merely applies a known technique of labeling historical network paths as anomalous or normal to enhance training data and anomaly classification, yielding predictable results consistent with established network security practices.
Pandian and Neil do not expressly disclose that the first set of network features comprises protocol tunneling information associated with the data packet, or that determining the network path comprises using protocol tunneling information and identifying IP addresses of one or more intermediate network devices along the network path based at least in part upon headers of the data packet. However, Nakil discloses a flow trace module (FTM 48) that accesses and processes protocol tunneling information from packets traversing overlay networks, including tunnel header fields such as outer IP headers, GRE protocol fields, MPLS labels, and VxLAN VNI identifiers, as part of its packet flow analysis (Nakil ¶¶0039, 0079, 0086–0093: the flow trace module queries the network forwarding table corresponding to the virtual network of the packet flow to obtain a tunnel header and tunneling information for the packet flow, and processes tunneling protocol fields including those associated with GRE, VxLAN, MPLS-in-GRE, MPLS-in-IP, and NVGRE encapsulation schemes). Nakil further discloses determining a physical network path traversed by packets of a packet flow by using the tunnel header and protocol tunneling information corresponding to the packet flow to generate flow trace packets that follow the same physical network path as the original packet flow (Nakil ¶¶0032–0034, 0046–0049, 0079–0083: the flow trace module receives a request to trace a physical network path for a packet flow, obtains a tunnel header and other tunneling information for packets of the packet flow, generates flow trace packets having corresponding packet header fields and tunnel-header information, and forwards the flow trace packets so that they traverse the same physical network path as the packet flow being traced). Nakil further discloses identifying IP addresses of one or more intermediate network devices along the network path based at least in part upon packet headers by iteratively generating flow trace packets with incrementally increasing TTL values in the outer IP packet header, causing each successive intermediate physical network element along the path to decrement the TTL value to zero and return an ICMP Time Exceeded message having a source IP address corresponding to that intermediate physical network element (Nakil ¶¶0033–0034, 0046–0049, 0057–0058, 0081–0083: successive flow trace packets with increasing TTL values cause successive physical next hops, such as TOR switches and chassis switches, to return ICMP Time Exceeded messages, and the flow trace module aggregates the source IP addresses from the respective messages into a list of physical network element addresses representing the physical network path).
It would have been obvious to one of ordinary skill in the art to modify the system of Pandian and Neil to incorporate Nakil's path determination technique because all references are directed to network traffic analysis and security monitoring in virtualized network environments, and Pandian's anomaly detection system would benefit from an accurate mechanism for reconstructing the physical network path traversed by a data packet in order to provide the routing context necessary to assess whether a destination device is anomalous based on the full traversal path of the communication. Nakil's established flow trace mechanism provides exactly this capability using tunneling protocol information already present in the packet headers, yielding predictable improvements in the completeness and accuracy of anomaly path determination.
Regarding Claim 2
Pandian in view of Nakil discloses determining anomalous network behavior using machine learning based on extracted network features and historical communication data. Pandian/Nakil, however, does not expressly disclose determining that a network path is anomalous by comparing extracted network features to historical anomalous communications and applying a threshold proportion of matching features. Neil discloses comparing observed network communication features to historical parameters derived from prior network communications associated with anomalous behavior, applying threshold criteria to deviations across multiple features or edges, and determining that a network path is anomalous when deviations exceed a threshold (Neil ¶26–27, 34, 50–51). Neil thus teaches determining anomalous network paths based on feature comparisons to historical anomalous communications and threshold-based classification.
It would have been obvious to one of ordinary skill in the art to incorporate Neil’s threshold comparison of extracted network features to historical anomalous communications into Pandian’s machine learning anomaly detection system in order to improve the accuracy and reliability of network path anomaly classification, because both references address detecting anomalous network behavior using historical data and threshold-based determinations, and the modification merely applies a known statistical decision technique to enhance anomaly detection with predictable results.
Regarding Claim 3
Pandian discloses:
The system of Claim 1, wherein the processor is further configured to block data communications to and from the first destination device (Pandian ¶51, 226: upon determining that a device exhibits anomalous behavior, the system performs corrective actions that include blocking, redirecting, or controlling communications to and/or from the device, including refraining from routing or forwarding data packets transmitted to and/or from the device).
Regarding Claim 4
Pandian discloses:
The system of Claim 1, wherein the one or more countermeasure actions further comprise at least one of the following:
associating the first destination device with an anomalous indication (Pandian ¶51, 115: labels/associates a device with anomalous behavior and presents an anomalous alert tied to that device.);
implementing a firewall policy to block communications associated with the IP address associated with the first destination device (Pandian ¶51, ¶226: upon determining anomalous behavior of a device, the system performs corrective actions that include blocking or controlling communications to and/or from the device);
or logging data requests and data usage associated with the first destination device.
Regarding Claim 7
Pandian discloses:
The system of Claim 1, wherein the processor is further configured to update the training dataset to include the network path to the first destination device associated with an anomalous indication (Pandian ¶51: teaches updating a machine learning training dataset to include information associated with anomalous network activity, including network location and path information of destination devices, and retraining the model using that updated dataset.).
Regarding Claim 8
Claim 8 is directed to a method corresponding to the system in claim 1. Claim 8 is similar in scope to claim 1 and is therefore rejected under similar rationale.
Regarding Claim 9
Claim 9 is directed to a method corresponding to the system in claim 2. Claim 9 is similar in scope to claim 2 and is therefore rejected under similar rationale.
Regarding Claim 10
Claim 10 is directed to a method corresponding to the system in claim 3. Claim 10 is similar in scope to claim 3 and is therefore rejected under similar rationale.
Regarding Claim 11
Claim 11 is directed to a method corresponding to the system in claim 4. Claim 11 is similar in scope to claim 4 and is therefore rejected under similar rationale.
Regarding Claim 14
Claim 14 is directed to a method corresponding to the system in claim 7. Claim 14 is similar in scope to claim 7 and is therefore rejected under similar rationale.
Regarding Claim 15
Claim 15 is directed to computer-readable medium storing instruction corresponding to the system in claim 1. Claim 15 is similar in scope to claim 1 and is therefore rejected under similar rationale.
Regarding Claim 16
Claim 16 is directed to computer-readable medium storing instruction corresponding to the system in claim 2. Claim 16 is similar in scope to claim 2 and is therefore rejected under similar rationale.
Regarding Claim 17
Claim 17 is directed to computer-readable medium storing instruction corresponding to the system in claim 3. Claim 17 is similar in scope to claim 3 and is therefore rejected under similar rationale.
Regarding Claim 18
Claim 18 is directed to computer-readable medium storing instruction corresponding to the system in claim 4. Claim 18 is similar in scope to claim 4 and is therefore rejected under similar rationale.
Claims 5, 6, 12, 13 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Pandian (US 20200076853 A1), Neil (US 20150020199 A1) and Nakil (US 20130332602 A1) as applied to claims 1, 8 and 15 above, and in further view of Li (US 2024/0259397 A1).
Regarding Claim 5
Pandian discloses:
The system of Claim 1, wherein the processor is further configured to: detect a data request to access the data packet; extract a second set of network features from the data request, wherein the second set of network features comprises a type of request, the IP address associated with the data request, or a type of network traffic (Pandian ¶148: discloses detecting a data packet and extracting network features from the data packet by parsing the packet to determine identifiers of the communicating device and associated port information using in the communication session.);
Pandian/Neil/Nakil discloses a network security system configured to extract network features from the and analyze the extracted features to identify anomalies using trained detection models. However, Pandian and Neil combined do not expressly describe that the data request is a SQL query encapsulating a DNS traffic and in response to determining that the SQL query is used to obfuscate the DNS traffic to redirect the data packet to another domain, deny the data request. On the hand, Li discloses detecting DNS tunneling and obfuscated DNS communications, including scenarios in which DNS traffic is encapsulated within structured queries (including SQL or command injection strings), extracting feature vectors from such traffic, classifying the traffic using trained machine-learning models, determining that the traffic is malicious DNS tunneling used to redirect communications to another domain, and denying or blocking the request in response to such determination (Li ¶62–66, 68–71).
It would have been obvious to one of ordinary skill in the art to modify the system of Pandian/Neil/Nakil learning classification, to incorporate Li’s DNS tunneling and obfuscation detection techniques in order to identify SQL queries encapsulating DNS traffic and deny such requests, because all references are directed to network security systems that analyze traffic using extracted features and trained models to detect covert or malicious communications, and the combination merely applies known and predictable detection techniques to improve security against DNS tunneling and redirection attacks.
Regarding Claim 6
Pandian/Neil/Nakil discloses a network security system configured to extract network features from the and analyze the extracted features to identify anomalies using trained detection models. However, Pandian/Neil/Nakil do not expressly describe determining that a data request is a SQL query encapsulating DNS traffic by comparing extracted network features of the data request to features associated with a historical data communication from a training dataset and determining that more than a threshold percentage of the features correspond. Li on the other hand discloses extracting feature vectors from input strings such as SQL statements and DNS-related traffic, and comparing the extracted features to feature vectors associated with historical samples stored in a training dataset to determine whether the input corresponds to a known malicious pattern, including DNS tunneling or SQL-based exploit traffic (Li ¶43–46, 52, 62–66). Li further discloses determining whether a received sample corresponds to a previously analyzed sample by comparing extracted features to historical feature mappings and classifying the sample based on whether similarity exceeds a threshold value (Li ¶49, 52, 65).
It would have been obvious to one of ordinary skill in the art to modify the teachings of Pandian/Neil/Nakil, to determine that a data request is an SQL query encapsulating DNS traffic by comparing extracted network features of the data request with counterpart features associated with historical data communications in a training dataset using the similarity and threshold-based comparison techniques taught by Li, because all references are directed to network security systems that classify traffic using machine learning and historical feature comparison, and the modification merely applies a known and predictable pattern-matching technique to improve accuracy in detecting obfuscated DNS traffic.
Regarding Claim 12
Claim 12 is directed to a method corresponding to the system in claim 5. Claim 12 is similar in scope to claim 5 and is therefore rejected under similar rationale.
Regarding Claim 13
Claim 13 is directed to a method corresponding to the system in claim 6. Claim 13 is similar in scope to claim 6 and is therefore rejected under similar rationale.
Regarding Claim 19
Claim 19 is directed to a method corresponding to the system in claim 5. Claim 19 is similar in scope to claim 5 and is therefore rejected under similar rationale.
Claims 20 are rejected under 35 U.S.C. 103 as being unpatentable over Pandian (US 20200076853 A1), Neil (US 20150020199 A1) and Nakil (US 20130332602 A1) as applied to claims 15, and in further view of Rahman (US 2025/0294050 A1).
Regarding Claim 20
Pandian/Neil/Nakil discloses a network security system configured to extract network features from the and analyze the extracted features to identify anomalies using trained detection models. However, Pandian/Neil/Nakil combined do not expressly describe utilizing quantum entanglement principles to reposition a data packet to a secure location or network path in response to determining that a destination device is anomalous. On the other hand, Rahman discloses a hybrid classical and quantum network security system in which artificial intelligence detects security threats or anomalous conditions in network communications and, in response, dynamically migrates or repositions communication services to a quantum-secure network path. Rahman further teaches the use of quantum entanglement-based techniques, including quantum integrity verification and quantum seals, to ensure secure and authenticated data transmission, as well as control-plane-driven relocation of traffic to secure quantum network paths when a threat is detected (Rahman ¶28–31).
It would have been obvious to one of ordinary skill in the art at the time of the invention to modify the system of Pandian/Neil/Nakil to incorporate Rahman’s quantum entanglement secure path repositioning techniques, because all references are directed to improving network security in response to the detected anomalous or malicious activity, and Rahman merely applies known quantum networking techniques to reroute communications to a secure network path once a threat is identified. Such a combination represents the predictable use of prior-art elements according to their established functions to enhance the security and integrity of network communications.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SAAD A ABDULLAH whose telephone number is (571) 272-1531. The examiner can normally be reached on Monday - Friday, 8:30am - 5:00pm, EST. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Lynn Feild can be reached on (571) 272-2092. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/SAAD AHMAD ABDULLAH/Examiner, Art Unit 2431
/MICHAEL R VAUGHAN/Primary Examiner, Art Unit 2431
Prosecution Insights