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 .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 02/06/2026 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Objections
Claim(s) 27 and 29 is/are objected to because of the following informalities:
Regarding claim 27, the term “the session” should read as “a session.” Regarding claim 29, the terms “the session” should read as “a session.” Appropriate correction is required.
Response to Amendment
Claims 1-29 are currently pending. Claims 17 and 20-21 have been amended and claims 27-29 have been added.
Response to Arguments
With respect to the §102 rejection of claim 1, Applicant argues that (pg. 9) FREITAS ‘963 does not teach “receive a network traffic sample that is obtained by a security entity; obtain context information for the network traffic sample” because the aggregated statistical features transmitted to the cloud are NOT “session-level request/response context or command combinations.” Applicant further contends that (pg. 9) FREITAS ‘963 fails to disclose “a security entity (such as an inline firewall) obtaining and forwarding a traffic sample specifically selected for deeper contextual analysis.” In other words, FREITAS ‘963 does not teach “session-based context information and the specific security-entity-to-cloud sample flow for context-driven classification.”
Applicant’s argument is based on two principal assertions: (1) the claimed “context information” is session-based, and (2) the claimed “security entity” is distinct from the edge server disclosed in FREITAS ‘963.
Regarding (1), the Examiner is not persuaded that the claimed “context information” is session-based. The claim does not recite that the context information is required to be associated with a session. Rather, the first appearance of the term “session” occurs in dependent claims. Furthermore, FREITAS ‘963 discloses (FIG. 7, [0052] and [0067]) extracting and normalizing network flow features from the network traffic, such as flow duration and a total number of packets, for purposes of data pattern evaluation. The Examiner considers such extracted network flow features to reasonably correspond to the claimed context information obtained for the network traffic sample. Moreover, the claim does not further define or limit the specific contents of the recited context information.
Regarding (2), the Examiner is not persuaded that the claimed “security entity” excludes the edge server disclosed in FREITAS ‘963. Although Applicant relies on examples in the Specification, such as an “inline firewall,” the claim does not positively recite an inline firewall or otherwise define the security entity in a manner that would exclude the edge server of FREITAS ‘963. Accordingly, the Examiner considers the edge server to reasonably correspond to the claimed security entity. In particular, FREITAS ‘963 discloses (FIG. 7 and [0067]) that when captured traffic is suspected to be malicious, the edge server transmits an anomaly message based on the captured traffic sample to an anomaly classifier for classifying cyber-attacks at a cloud server (FIG. 8 and [0072]). The Examiner considers this disclosure to teach or at least reasonably suggest the limitation of “receive a network traffic sample that is obtained by a security entity.”
Thus, the Examiner maintains that the rejections under 35 USC § 102 are proper and are therefore maintained.
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.
Claim(s) 1, 11, 19, 22 and 24-26 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by FREITAS DE ARAUJO FILHO et al., US-20240250963-A1 (hereinafter “FREITAS ‘963”).
Per claim 1 (independent):
FREITAS ‘963 discloses: A system, comprising:
one or more processors configured to:
receive a network traffic sample that is obtained by a security entity;
obtain context information for the network traffic sample;
determine a maliciousness classification for the network traffic sample based at least in part on the context information; and
perform an action based at least in part on the context information; and
a memory coupled to the one or more processors and configured to provide the one or more processors with instructions
(FIG. 7, [0067], a method 700 for detecting cyberattacks at edge servers (a security entity). The method comprises receiving network traffic (receive a network traffic sample that is obtained by a security entity), step 702. The method comprises extracting and normalizing, step 704, network flow features (obtain context information; [0052] recites examples of network flow features, including “flow duration, total number of packets ...”) from the network traffic to produce a data pattern for evaluation. The method comprises computing, step 706, an anomaly detection score for the data pattern (based at least in part on the context information) for evaluation (in preparation for determining a maliciousness classification). The method comprises comparing, step 708, the anomaly detection score with a threshold and determining if the network traffic corresponds to normal traffic or to an anomaly. The method comprises, upon determining that the network traffic corresponds to an anomaly, mitigating, step 710, malicious network traffic by triggering a mitigation strategy and sending an anomaly message to an anomaly classifier (which corresponds to the AC module 110 of FIG. 1, and furthermore, according to [0055], “The AC module receives report anomaly messages from AD modules”); FIG. 8, [0072], a method 800 for classifying cyber-attacks at a cloud server (which corresponds to the AC module 110 of FIG. 1). The method comprises receiving, step 802, an anomaly message (including context information for the network traffic sample; [0067] indicates that an “anomaly message” is generated based on information derived from “network flow features”, i.e., context information, which is extracted from network traffic) from at least one anomaly detector (the security entity). The method comprises extracting and normalizing, step 804, aggregated features from the anomaly message to produce a data pattern for evaluation. The method comprises computing, step 806, for the data pattern under evaluation, a score (a malicious classification) for each of a plurality of classes trained in an anomaly classifier running in the cloud server (determines a malicious classification based at least in part on context information). The method comprises comparing, step 808, a highest of the computed scores with a threshold and, if the highest of the computed scores is greater than the threshold assigning a class, which corresponds to the class associated with the highest score, to the data pattern under evaluation, and, assigning "unknown class" otherwise; [0074], If the class assigned to the data pattern under evaluation is a "normal class" (based at least in part on the context information), the method may comprise reverting mitigation strategies (perform an action) triggered by a corresponding anomaly detector, otherwise (based at least in part on the context information) it may be verified whether another mitigation strategy is more appropriate and triggering the other mitigation strategy (perform an action) if more appropriate).
Per claim 11 (dependent on claim 1):
FREITAS ‘963 discloses the elements detailed in the rejection of claim 1 above, incorporated herein by reference.
FREITAS ‘963 discloses: The system of claim 1, wherein performing the action comprises generating a report pertaining to the maliciousness classification (FIG. 8, [0074], If the class assigned to the data pattern under evaluation is a "normal class" (pertaining to the maliciousness classification) , the method may comprise reverting mitigation strategies triggered by a corresponding anomaly detector, otherwise (pertaining to the maliciousness classification) it may be verified whether another mitigation strategy is more appropriate and triggering the other mitigation strategy if more appropriate – in other words, through generating a report for the edge servers).
Per claim 19 (dependent on claim 1):
FREITAS ‘963 discloses the elements detailed in the rejection of claim 1 above, incorporated herein by reference.
FREITAS ‘963 discloses: The system of claim 1, wherein the network traffic sample corresponds to east-west network traffic activity, and determining the maliciousness classification for the network traffic sample comprises performing internal threat detection (FIG. 7, [0067], a method 700 for detecting cyberattacks at edge servers 90 (a plurality of devices are subordinate to a single AD module such as edge servers, which is also limited to a cloud covered by a single cloud server or the AC module, that is, east-west network traffic activity). The method comprises receiving network traffic (the network traffic sample), step 702. The method comprises extracting and normalizing, step 704, network flow features from the network traffic to produce a data pattern for evaluation. The method comprises computing, step 706, an anomaly detection score for the data pattern for evaluation. The method comprises comparing, step 708, the anomaly detection score with a threshold and determining if the network traffic corresponds to normal traffic or to an anomaly. The method comprises, upon determining that the network traffic corresponds to an anomaly, mitigating, step 710, malicious network traffic by triggering a mitigation strategy and sending an anomaly message to an anomaly classifier; FIG. 8, [0072], a method 800 for classifying cyber-attacks at a cloud server. The method comprises receiving, step 802, an anomaly message (including context information for the network traffic sample; as explained with respect to claim 1, [0067] indicates that an “anomaly message” is generated based on information derived from “network flow features”, i.e., context information, which is extracted from network traffic) from at least one anomaly detector. The method comprises extracting and normalizing, step 804, aggregated features from the anomaly message to produce a data pattern for evaluation. The method comprises computing, step 806, for the data pattern under evaluation, a score (the maliciousness classification) for each of a plurality of classes trained in an anomaly classifier (performing internal threat detection) running in the cloud server).
Per claim 22 (independent):
FREITAS ‘963 discloses: A system, comprising:
one or more processors configured to: obtain a network traffic sample;
determine whether the network traffic sample is suspicious;
in response to determining that the network traffic sample is suspicious, query a cloud security service for a maliciousness classification
(FIG. 7, [0067], a method 700 for detecting cyberattacks at edge servers. The method comprises receiving network traffic (obtain a network traffic sample), step 702. The method comprises extracting and normalizing, step 704, network flow features from the network traffic to produce a data pattern for evaluation. The method comprises computing, step 706, an anomaly detection score for the data pattern for evaluation (determine whether the network traffic sample is suspicious). The method comprises comparing, step 708, the anomaly detection score with a threshold and determining if the network traffic corresponds to normal traffic or to an anomaly. The method comprises, upon determining that the network traffic corresponds to an anomaly (in response to determining that the network traffic sample is suspicious), mitigating, step 710, malicious network traffic by triggering a mitigation strategy and sending an anomaly message to an anomaly classifier (a cloud security service, which corresponds to the AC module 110 of FIG. 1, and furthermore, according to [0055], “The AC module receives report anomaly messages from AD modules”) – query a cloud security service for a maliciousness classification),
wherein the cloud security service determines the malicious classification based at least in part on context information for the network traffic sample;
obtain the maliciousness classification from the cloud security service
perform an action based at least in part on the maliciousness classification; and
a memory coupled to the one or more processors and configured to provide the one or more
processors with instructions.
(FIG. 8, [0072], a method 800 for classifying cyber-attacks at a cloud server (the cloud security service). The method comprises receiving, step 802, an anomaly message (including context information for the network traffic sample; as explained with respect to claim 1, [0067] indicates that an “anomaly message” is generated based on information derived from “network flow features”, i.e., context information, which is extracted from network traffic) from at least one anomaly detector. The method comprises extracting and normalizing, step 804, aggregated features from the anomaly message to produce a data pattern for evaluation. The method comprises computing, step 806, for the data pattern under evaluation, a score for each of a plurality of classes trained in an anomaly classifier running in the cloud server (determines the malicious classification based at least in part on context information). The method comprises comparing, step 808, a highest of the computed scores with a threshold and, if the highest of the computed scores is greater than the threshold assigning a class, which corresponds to the class associated with the highest score, to the data pattern under evaluation, and, assigning "unknown class" otherwise – obtain the maliciousness classification from the cloud security service); [0074], If the class assigned to the data pattern under evaluation is a "normal class" (based at least in part on the maliciousness classification), the method may comprise reverting mitigation strategies (perform an action) triggered by a corresponding anomaly detector, otherwise (based at least in part on the maliciousness classification) it may be verified whether another mitigation strategy is more appropriate and triggering the other mitigation strategy (perform an action) if more appropriate ).
Per claim 24 (independent):
The limitations of the claim(s) correspond(s) to features of claim 1 and the claim(s) is/are rejected for the reasons detailed with respect to claim 1.
Per claim 25 (independent):
The limitations of the claim(s) correspond(s) to features of claim 1 and the claim(s) is/are rejected for the reasons detailed with respect to claim 1.
Per claim 26 (independent):
The limitations of the claim(s) correspond(s) to features of claim 22 and the claim(s) is/are rejected for the reasons detailed with respect to claim 22.
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.
Claim(s) 2-3 is/are rejected under 35 U.S.C. 103 as being unpatentable over FREITAS ‘963 in view of Kaidi, US-20250150463-A1 (hereinafter “Kaidi ‘463”).
Per claim 2 (dependent on claim 1):
FREITAS ‘963 discloses the elements detailed in the rejection of claim 1 above, incorporated herein by reference.
FREITAS ‘963 does not disclose but Kaidi ‘463 discloses: The system of claim 1, wherein the network traffic sample is classified by the security entity based at least in part on a set of one or more pre-filtering signatures (FIG. 2, [0032], process 200 may begin at a step 202 with detecting matches with malicious signatures. For example, at step 202, the systems and methods described herein may scan network traffic (the network traffic sample) to extract signatures and compare the extracted signatures with known malicious signatures (a set of one or more pre-filtering signatures, that is, stored security signatures) to identify (classify) known malicious signatures arising from the network traffic (by the security entity); [0039], at a step 210 the systems and methods described herein may identify one or more anomalies in patterns of network traffic associated with one or more groups of signatures, and, at a step 222, the systems and methods described herein may investigate the identified anomalies ( e.g., analyze network and/or computing environment activity to identify potential attacks associated with the anomalies, including potential attack targets and/or potential methods of attack)).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified FREITAS ‘963 with the identification of known malicious signatures arising from the network traffic by matching to stored malicious signatures as taught by Kaidi ‘463 because it would track signatures and classify them (e.g., as malicious, benign, unknown, etc.) and take different actions based on the classification [0022]. Additionally, Kaidi ‘463 is analogous to the claimed invention because it teaches using known signatures (e.g., hashes or strings for static files and/or fingerprints for network traffic) to identify computing security threats [0011].
Per claim 3 (independent on claim 2):
FREITAS ‘963 in view of Kaidi ‘463 discloses the elements detailed in the rejection of claim 2 above, incorporated herein by reference.
FREITAS ‘963 does not disclose but Kaidi ‘463 discloses: The system of claim 2, wherein the security entity intercepts network traffic, classifies the network traffic based at least in part on the set of one or more pre-filtering signatures to obtain a set of suspiciousness classifications, detects whether a network traffic sample among the intercepted network traffic is suspicious based at least in part the suspiciousness classification (FIG. 2, [0032], process 200 may begin at a step 202 with detecting matches with malicious signatures. For example, at step 202, the systems and methods described herein may scan network traffic (the security entity intercepts network traffic) to extract signatures and compare the extracted signatures with known malicious signatures (the set of one or more pre-filtering signatures, that is, stored security signatures) to identify known malicious signatures arising from the network traffic (classifies the network traffic); [0034], Following step 202 and/or step 203, the systems and methods described herein may proceed to a step 204 by grouping network traffic by signatures (and/or behavioral fingerprints). In some examples, these systems and methods may group some network traffic (obtain a set of suspiciousness classifications) according to exact signature matches ; [0039], at a step 210 the systems and methods described herein may identify one or more anomalies in patterns of network traffic associated with one or more groups of signatures (the suspiciousness classification) – detects whether a network traffic sample among the intercepted network traffic is suspicious, and, at a step 222, the systems and methods described herein may investigate the identified anomalies ( e.g., analyze network and/or computing environment activity to identify potential attacks associated with the anomalies, including potential attack targets and/or potential methods of attack)).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified FREITAS ‘963 with the identification of known malicious signatures arising from the network traffic by matching to stored malicious signatures for identifying anomalies as taught by Kaidi ‘463 because it would track signatures and classify them (e.g., as malicious, benign, unknown, etc.) and take different actions based on the classification [0022].
Claim(s) 4-6, 12-15 and 23 is/are rejected under 35 U.S.C. 103 as being unpatentable over FREITAS ‘963 in view of Goyal, US- 20220070183-A1 (hereinafter “Goyal ‘183”).
Per claim 4 (dependent on claim 1):
FREITAS ‘963 discloses the elements detailed in the rejection of claim 1 above, incorporated herein by reference.
FREITAS ‘963 does not disclose but Goyal ‘183 discloses: The system of claim 1, wherein the context information is determined based at least in part on a plurality of requests and a plurality of responses (FIG. 10, [0066], a machine learning process 700 implemented in a node 152 in the cloud-based system 100 for classifying mobile apps on a user device 300; [0067], (step 704). This data extraction module extracts the relevant fields (the context information) such as destination IP address, destination Port, protocol, user agent, HTTP method, content-length, Server Name Indication (SNI) host, extra header fields, etc. (whichever is relevant for the traffic) from each transaction ... the data extraction is performed in the cloud-based system 100, after the cloud tunnel 500 terminates; it is noted that as shown in FIG. 6, the context information is collected on a per-user basis via individual tunnels corresponding to respective session, and as shown in FIGS. 7-9, is obtained through multiple client-server request and response exchanges, that is, a plurality of requests and a plurality of responses; [0068], The process 700 includes analyzing the data (for the network traffic sample – received at step 702 – based at least in part on the context information, which is extracted at step 704) for a transaction utilizing a machine learning model to obtain a score indicative of possible maliciousness of an application associated with the transaction (step 706).).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified FREITAS ‘963 with the extraction of the relevant field associated with network traffic on multiple client-server request and response exchanges via a tunnel as taught by Goyal ‘183 because it would ensure the security of new mobile apps [0002]. Additionally, Goyal ‘183 is analogous to the claimed invention because it teaches a machine learning process 700 implemented in a node 152 in the cloud-based system 100 for classifying mobile apps on a user device 300 [0066].
Per claim 5 (dependent on claim 4):
FREITAS ‘963 in view of Goyal ‘183 discloses the elements detailed in the rejection of claim 4 above, incorporated herein by reference.
FREITAS ‘963 does not disclose but Goyal ‘183 discloses: The system of claim 4, wherein the plurality of responses and the plurality of responses are associated with a same session (FIG. 10, [0066], a machine learning process 700 implemented in a node 152 in the cloud-based system 100 for classifying mobile apps on a user device 300; [0067], (step 704). This data extraction module extracts the relevant fields such as destination IP address, destination Port, protocol, user agent, HTTP method, content-length, Server Name Indication (SNI) host, extra header fields, etc. (whichever is relevant for the traffic) from each transaction ... the data extraction is performed in the cloud-based system 100, after the cloud tunnel 500 terminates; it is noted that as shown in FIG. 6, the context information is collected on a per-user basis via individual tunnels corresponding to respective session i.e., associated with a same session, and as shown in FIGS. 7-9, is obtained through multiple client-server request and response exchanges, that is, the plurality of responses; [0068], The process 700 includes analyzing the data for a transaction utilizing a machine learning model to obtain a score indicative of possible maliciousness of an application associated with the transaction (step 706).).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified FREITAS ‘963 with the extraction of the relevant field associated with network traffic on multiple client-server request and response exchanges via a tunnel as taught by Goyal ‘183 because it would ensure the security of new mobile apps [0002].
Per claim 6 (dependent on claim 5):
FREITAS ‘963 in view of Goyal ‘183 discloses the elements detailed in the rejection of claim 5 above, incorporated herein by reference.
FREITAS ‘963 does not disclose but Goyal ‘183 discloses: The system of claim 5, wherein the context information is determined based at least in part on network activity associated with the session (FIG. 10, [0066], a machine learning process 700 implemented in a node 152 in the cloud-based system 100 for classifying mobile apps on a user device 300; [0067], (step 704). This data extraction module extracts the relevant fields (the context information) such as destination IP address, destination Port, protocol, user agent, HTTP method, content-length, Server Name Indication (SNI) host, extra header fields, etc. (whichever is relevant for the traffic) from each transaction ... the data extraction is performed in the cloud-based system 100, after the cloud tunnel 500 terminates; it is noted that as shown in FIG. 6, the context information is collected on a per-user basis via individual tunnels corresponding to respective session i.e., associated with the session, and as shown in FIGS. 7-9, is obtained through multiple client-server request and response exchanges, that is, network activity; [0068], The process 700 includes analyzing the data for a transaction utilizing a machine learning model to obtain a score indicative of possible maliciousness of an application associated with the transaction (step 706).).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified FREITAS ‘963 with the extraction of the relevant field associated with network traffic on multiple client-server request and response exchanges via a tunnel as taught by Goyal ‘183 because it would ensure the security of new mobile apps [0002].
Per claim 12 (dependent on claim 11):
FREITAS ‘963 discloses the elements detailed in the rejection of claim 11 above, incorporated herein by reference.
FREITAS ‘963 does not disclose but Goyal ‘183 discloses: The system of claim 11, wherein the performing the action further comprises providing the report to the security entity (FIG. 10, [0066], a machine learning process 700 implemented in a node 152 in the cloud-based system 100 for classifying mobile apps on a user device 300 (the security entity); [0068], Specifically, the data extraction module output is fed to the machine learning model, which is a classifier to provide a score for the transaction. The model can provide a score, such as from 1 to 100, that is indicative of the maliciousness of the application associated with the transaction, e.g., based on the security and privacy parameters; [0069], The process 700 includes communicating the score to the user device (providing the report to the security entity – performing the action) via the tunnel (step 708. The score for a transaction is communicated to the user device 300, such as on the control channel 540. The application 350 (of the user device 300, i.e., the security entity) can then flag the app corresponding to that transaction, including blocking the app, deleting the app, providing a notification, etc.).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified FREITAS ‘963 with the provision of a score from a classifier in the cloud-based system to a user device for enforcing security on the user device as taught by Goyal ‘183 because it would ensure the security of new mobile apps [0002].
Per claim 13 (dependent on claim 1):
FREITAS ‘963 discloses the elements detailed in the rejection of claim 1 above, incorporated herein by reference.
FREITAS ‘963 does not disclose but Goyal ‘183 discloses: The system of claim 1, wherein performing the action comprises providing an indication of the maliciousness classification to a security entity (FIG. 10, [0066], a machine learning process 700 implemented in a node 152 in the cloud-based system 100 for classifying mobile apps on a user device 300 (the security entity); [0068], Specifically, the data extraction module output is fed to the machine learning model, which is a classifier to provide a score for the transaction. The model can provide a score, such as from 1 to 100, that is indicative of the maliciousness of the application associated with the transaction, e.g., based on the security and privacy parameters; [0069], The process 700 includes communicating the score to the user device (providing an indication of the maliciousness classification to a security entity – performing the action; according to FIG.1, there are multiple users, i.e., multiple security entities) via the tunnel (step 708. The score for a transaction is communicated to the user device 300, such as on the control channel 540. The application 350 (of the user device 300, i.e., the security entity) can then flag the app corresponding to that transaction, including blocking the app, deleting the app, providing a notification, etc.).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified FREITAS ‘963 with the provision of a score from a classifier in the cloud-based system to a user device for enforcing security on the user device as taught by Goyal ‘183 because it would ensure the security of new mobile apps [0002].
Per claim 14 (dependent on claim 1):
FREITAS ‘963 discloses the elements detailed in the rejection of claim 1 above, incorporated herein by reference.
FREITAS ‘963 does not disclose but Goyal ‘183 discloses: The system of claim 1, wherein:
the network traffic sample is associated with a session; and
the security entity handles network traffic for the session based at least in part on the maliciousness classification
(FIG. 10, [0066], a machine learning process 700 implemented in a node 152 in the cloud-based system 100 for classifying mobile apps on a user device 300 (the security entity) ... obtaining network traffic (the network traffic sample) associated with mobile applications operating on a user device via a tunnel (associated with a session) between the user device and the node ... (step 702); [0068], Specifically, the data extraction module output is fed to the machine learning model, which is a classifier to provide a score for the transaction. The model can provide a score, such as from 1 to 100 (an example of the maliciousness classification), that is indicative of the maliciousness of the application associated with the transaction, e.g., based on the security and privacy parameters; [0069], The process 700 includes communicating the score to the user device (provides the maliciousness classification to the security entity) via the tunnel (step 708. The score for a transaction is communicated to the user device 300, such as on the control channel 540. The application 350 (of the user device 300, i.e., the security entity) can then flag the app corresponding to that transaction, including blocking the app, deleting the app, providing a notification, etc. – the security entity handles network traffic for the session based at least in part on the maliciousness classification).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified FREITAS ‘963 with the provision of a score from a classifier in the cloud-based system to a user device for enforcing security on the user device as taught by Goyal ‘183 because it would ensure the security of new mobile apps [0002].
Per claim 15 (dependent on claim 14):
FREITAS ‘963 in view of Goyal ‘183 discloses the elements detailed in the rejection of claim 14 above, incorporated herein by reference.
FREITAS ‘963 does not disclose but Goyal ‘183 discloses: The system of claim 14, wherein:
determining the maliciousness classification and handling of the network traffic for the session is performed in real-time; and
the handling of the network traffic comprises blocking the network traffic for the session in response to determining that an indication of the maliciousness classification indicates that the network traffic sample is malicious
(FIG. 10, [0066], a machine learning process 700 implemented in a node 152 in the cloud-based system 100 for classifying mobile apps on a user device 300 ... obtaining network traffic (the network traffic sample) associated with mobile applications operating on a user device via a tunnel (for the session) between the user device and the node ... (step 702); FIG. 1, [0024], The cloud-based system 100 can also include a management system 120 for tenant access to provide global policy and configuration as well as real-time analytics (the handling of the network traffic for the session is performed in real-time); [0068], Specifically, the data extraction module output is fed to the machine learning model, which is a classifier to provide a score for the transaction. The model can provide a score, such as from 1 to 100 (an example of the maliciousness classification), that is indicative of the maliciousness of the application associated with the transaction, e.g., based on the security and privacy parameters; [0069], The process 700 includes communicating the score to the user device (an indication of the maliciousness classification indicates that the network traffic sample is malicious) via the tunnel (step 708. The score for a transaction is communicated to the user device 300, such as on the control channel 540. (in response to determining that ...) The application 350 (of the user device 300, i.e., the security entity) can then flag the app corresponding to that transaction, including blocking the app, deleting the app, providing a notification, etc. – the handling of the network traffic comprises blocking the network traffic for the session).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified FREITAS ‘963 with the provision of a score from a classifier in the cloud-based system to a user device for enforcing security on the user device as taught by Goyal ‘183 because it would ensure the security of new mobile apps [0002].
Per claim 23 (independent):
FREITAS ‘963 discloses: A security platform system comprising:
a security entity that is configured to monitor network traffic and detect suspicious network traffic from among the monitored network traffic; and
a cloud security service that is configured to perform a maliciousness classification for at least the suspicious network traffic
(FIG. 1, [0037], The proposed security solution 100 aims to detect and classify cyber-attacks on communication networks (among the monitored network traffic); [0038], AD modules 120 (a security entity) are deployed as applications on edge servers 115, such that devices can send their network traffic for analysis and receive back alerts of detected attacks (monitor network traffic and detect suspicious network traffic); [0039], the AC module 110 (a cloud security service) is deployed as an application on the cloud 105. It receives anomalies detected by different AD modules ... for evaluating the potential risks and impacts of sophisticated distributed cyber-attacks (perform a maliciousness classification for at least the suspicious network traffic));
wherein:
the security entity:
obtains a network traffic sample;
determines whether network traffic sample is suspicious;
in response to determining that the network traffic sample is suspicious, query the cloud security service for a maliciousness classification
(FIG. 7, [0067], a method 700 for detecting cyberattacks at edge servers (the security entity, which corresponds to the AD modules 120 of FIG. 1). The method comprises receiving network traffic (obtains a network traffic sample), step 702. The method comprises extracting and normalizing, step 704, network flow features from the network traffic to produce a data pattern for evaluation. The method comprises computing, step 706, an anomaly detection score for the data pattern for evaluation (determines whether the network traffic sample is suspicious). The method comprises comparing, step 708, the anomaly detection score with a threshold and determining if the network traffic corresponds to normal traffic or to an anomaly. The method comprises, upon determining that the network traffic corresponds to an anomaly (in response to determining that the network traffic sample is suspicious), mitigating, step 710, malicious network traffic by triggering a mitigation strategy and sending an anomaly message to an anomaly classifier (the cloud security service, which corresponds to the AC module 110 of FIG. 1, and furthermore, according to [0055], “The AC module receives report anomaly messages from AD modules”) – query the cloud security service for a maliciousness classification);
the cloud security service:
obtains the network traffic sample;
obtains context information for the network traffic sample;
determines a maliciousness classification for the network traffic sample based at least in part on the context information; and
(FIG. 8, [0072], a method 800 for classifying cyber-attacks at a cloud server (the cloud security service, which corresponds to the AC module 110 of FIG. 1). The method comprises receiving, step 802, an anomaly message (including context information for the network traffic sample; as explained with respect to claim 1, [0067] indicates that an “anomaly message” is generated based on information derived from “network flow features”, i.e., context information, which is extracted from network traffic) from at least one anomaly detector. The method comprises extracting and normalizing, step 804, aggregated features from the anomaly message to produce a data pattern for evaluation. The method comprises computing, step 806, for the data pattern under evaluation, a score for each of a plurality of classes trained in an anomaly classifier running in the cloud server (determines a malicious classification based at least in part on context information). The method comprises comparing, step 808, a highest of the computed scores with a threshold and, if the highest of the computed scores is greater than the threshold assigning a class, which corresponds to the class associated with the highest score, to the data pattern under evaluation, and, assigning "unknown class" otherwise).
FREITAS ‘963 does not disclose but Goyal ‘183 discloses:
the security entity:
obtains the maliciousness classification from the cloud security service; and
performs an active measure based at least in part on the maliciousness classification;
the cloud security service:
provides the maliciousness classification to the security entity
(FIG. 10, [0066], a machine learning process 700 implemented in a node 152 (the cloud security service) in the cloud-based system 100 for classifying mobile apps on a user device 300 (the security entity); [0068], Specifically, the data extraction module output is fed to the machine learning model, which is a classifier to provide a score for the transaction. The model can provide a score, such as from 1 to 100 (an example of the maliciousness classification), that is indicative of the maliciousness of the application associated with the transaction, e.g., based on the security and privacy parameters; [0069], The process 700 includes communicating the score to the user device (provides the maliciousness classification to the security entity; in other words, the security entity obtains the maliciousness classification from the cloud security service) via the tunnel (step 708. The score for a transaction is communicated to the user device 300, such as on the control channel 540. The application 350 (of the user device 300, i.e., the security entity) can then flag the app corresponding to that transaction, including blocking the app, deleting the app, providing a notification, etc. – performs an active measure based at least in part on the maliciousness classification).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified FREITAS ‘963 with the provision of a score from a classifier in the cloud-based system to a user device for enforcing security on the user device as taught by Goyal ‘183 because it would ensure the security of new mobile apps [0002].
Claim(s) 7 is/are rejected under 35 U.S.C. 103 as being unpatentable over FREITAS ‘963 in view of LUK-ZILBERMAN et al., US-20240015177-A1 (hereinafter “LUK ‘177”).
Per claim 7 (dependent on claim 1):
FREITAS ‘963 discloses the elements detailed in the rejection of claim 1 above, incorporated herein by reference.
FREITAS ‘963 does not disclose but LUK ‘177 discloses: The system of claim 1, wherein the one or more processors are further configured to detect lateral movement for a session associated with the network traffic sample ([0017], The various disclosed embodiments include a method and system for detecting malicious lateral movement (detect lateral movement) using remote system protocols. The disclosed embodiments provide techniques for detecting abnormal tunnels (a session) realized via remote system protocols (associated with the network traffic sample, e.g., RDP), which can potentially lead to network hacking and data breaches. These abnormal tunnels may be further analyzed to determine whether they are malicious. Traffic occurring via these malicious tunnels can therefore be detected as malicious lateral movement using remote system protocols).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified FREITAS ‘963 with the detection of malicious lateral movement using remote system protocols in tunnels as taught by LUK ‘177 because it would mitigate the damage caused by malicious lateral movement. Additionally, LUK ‘177 is analogous to the claimed invention because it teaches detecting malicious lateral movement using remote system protocols [0017].
Claim(s) 8 and 10 is/are rejected under 35 U.S.C. 103 as being unpatentable over FREITAS ‘963 in view of Goyal ‘183 and Kaidi ‘463.
Per claim 8 (dependent on claim 1):
FREITAS ‘963 discloses the elements detailed in the rejection of claim 1 above, incorporated herein by reference.
FREITAS ‘963 does not disclose but Goyal ‘183 discloses: The system of claim 1, wherein:
the network traffic sample is associated with a session; and
determining the maliciousness classification for the network traffic sample based at least in part on the context information comprises determining whether network activity associated with the session is malicious
(FIG. 10, [0066], a machine learning process 700 implemented in a node 152 in the cloud-based system 100 for classifying mobile apps on a user device 300 ... obtaining network traffic (the network traffic sample) associated with mobile applications operating on a user device via a tunnel (associated with a session) between the user device and the node ... (step 702); [0067], (step 704). This data extraction module extracts the relevant fields (the context information) such as destination IP address, destination Port, protocol, user agent, HTTP method, content-length, Server Name Indication (SNI) host, extra header fields, etc. (whichever is relevant for the traffic) from each transaction (network activity associated with the session) ... the data extraction is performed in the cloud-based system 100, after the cloud tunnel 500 terminates; [0068], The process 700 includes analyzing the data (for the network traffic sample – received at step 702 – based at least in part on the context information, which is extracted at step 704) for a transaction utilizing a machine learning model to obtain a score indicative of possible maliciousness of an application associated with the transaction (step 706). Specifically, the data extraction module output is fed to the machine learning model, which is a classifier to provide a score for the transaction (determining the maliciousness classification; determining whether network activity associated with the session, i.e., the tunnel, is malicious). The model can provide a score, such as from 1 to 100, that is indicative of the maliciousness of the application associated with the transaction, e.g., based on the security and privacy parameters).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified FREITAS ‘963 with the extraction of the relevant field associated with network traffic via a tunnel for providing a score indicative of the maliciousness as taught by Goyal ‘183 because it would ensure the security of new mobile apps [0002].
FREITAS ‘963 in view of Goyal ‘183 does not disclose but Kaidi ‘463 discloses: determining whether network activity comprises a combination of commands that is malicious (FIG. 2, [0032], process 200 may begin at a step 202 with detecting matches with malicious signatures. For example, at step 202, the systems and methods described herein may scan network traffic (network activity) to extract signatures and compare the extracted signatures with known malicious signatures to identify known malicious signatures arising from the network traffic; [0038], at a step 212, the systems and methods described herein may identify one or more instances of false-flag activity (determining whether network activity comprises a combination of commands that is malicious) ... benign activity that accompanies malicious activity (e.g., a command-and-control call-back to a benign or trusted target accompanying a command-and-control callback to a malicious target (a combination of commands that is malicious); [0039], at a step 210 the systems and methods described herein may identify one or more anomalies in patterns of network traffic associated with one or more groups of signatures).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified FREITAS ‘963 in view of Goyal ‘183 with the identification of known malicious signatures arising from the network traffic by matching to stored malicious signatures for identifying anomalies after identifying one or more instances of false-flag activity as taught by Kaidi ‘463 because it would track signatures and classify them (e.g., as malicious, benign, unknown, etc.) and take different actions based on the classification in a more secure manner [0022].
Per claim 10 (dependent on claim 8):
FREITAS ‘963 in view of Goyal ‘183 and Kaidi ‘463 discloses the elements detailed in the rejection of claim 8 above, incorporated herein by reference.
FREITAS ‘963 in view of Goyal ‘183 does not disclose but Kaidi ‘463 discloses: The system of claim 8, wherein the combination of commands comprises one or more commands that are individually legitimate commands (FIG. 2, [0038], at a step 212, the systems and methods described herein may identify one or more instances of false-flag activity ... the term "false-flag activity" may refer to any computing activity that is not directly a part of a computing attack but which potentially obscures the computing attack (indicating individually legitimate commands) ... benign activity that accompanies malicious activity (e.g., a command-and-control call-back to a benign or trusted target accompanying a command-and-control callback to a malicious target) (the combination of commands) ... identify false-flag activity by determining that activity with the form of malicious activity (e.g., a command-and-control callback) involves benign content (e.g., a trusted target).).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified FREITAS ‘963 in view of Goyal ‘183 with the identification of known malicious signatures arising from the network traffic by matching to stored malicious signatures for identifying anomalies after identifying one or more instances of false-flag activity as taught by Kaidi ‘463 because it would track signatures and classify them (e.g., as malicious, benign, unknown, etc.) and take different actions based on the classification in a more secure manner [0022].
Claim(s) 16-18 is/are rejected under 35 U.S.C. 103 as being unpatentable over FREITAS ‘963 in view of KUMAR et al., US-20260010711-A1 (hereinafter “KUMAR ‘711”).
Per claim 16 (dependent on claim 1):
FREITAS ‘963 discloses the elements detailed in the rejection of claim 1 above, incorporated herein by reference.
FREITAS ‘963 does not disclose but KUMAR ‘711 discloses: The system of claim 1, wherein performing the action comprises querying a machine learning model for an explanation of the maliciousness classification based at least in part on the context information (FIG. 1, [0028], an artificial intelligence (AI)-based fraud detection system 100 for monitoring alerts ... receiving a request (querying a machine learning model), at block 110, for evaluating an alert to predict whether the alert warrants an investigation (an explanation of the maliciousness classification), where the alert may be associated with suspicious activities (based at least in part on the context information) listed in tabular data, receiving the tabular data and converting the received tabu-lar data, at block 120, into natural language strings for inputting into an LLM by creating prompts and completions from the tabular data, generating a predictive score, at block 150, via an LLM-trained machine learning (ML) model (the machine learning model) ... the predictive score (an explanation of the maliciousness classification) indicates whether any of the suspicious activities warrant an investigation, comparing the predictive score to a threshold value for classification, and providing an alert prioritization, at block 160, based on the classification of the predictive score).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified FREITAS ‘963 with the generation of a predictive score indicating whether suspicious activities warrant an investigation based on an LLM-trained language model as taught by KUMAR ‘711 because it would enable identification of complex and evolving fraud patterns across large and diverse data sets, improving detection accuracy. Additionally, KUMAR ‘711 is analogous to the claimed invention because it teaches an artificial intelligence (AI)-based fraud detection system 100 for monitoring alerts [0028].
Per claim 17 (dependent on claim 16):
FREITAS ‘963 in view of KUMAR ‘711 discloses the elements detailed in the rejection of claim 16 above, incorporated herein by reference.
FREITAS ‘963 does not disclose but KUMAR ‘711 discloses: The system of claim 17, wherein the machine learning model is a large language model (FIG. 1, [0028], an artificial intelligence (AI)-based fraud detection system 100 for monitoring alerts ... receiving a request, at block 110, for evaluating an alert to predict whether the alert warrants an investigation, where the alert may be associated with suspicious activities listed in tabular data, receiving the tabular data and converting the received tabu-lar data, at block 120, into natural language strings for inputting into an LLM by creating prompts and completions from the tabular data, generating a predictive score, at block 150, via an LLM-trained machine learning (ML) model (the machine learning model is a large language model) ... the predictive score indicates whether any of the suspicious activities warrant an investigation, comparing the predictive score to a threshold value for classification, and providing an alert prioritization, at block 160, based on the classification of the predictive score).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified FREITAS ‘963 with the generation of a predictive score indicating whether suspicious activities warrant an investigation based on an LLM-trained language model as taught by KUMAR ‘711 because it would enable identification of complex and evolving fraud patterns across large and diverse data sets, improving detection accuracy.
Per claim 18 (dependent on claim 1):
FREITAS ‘963 discloses the elements detailed in the rejection of claim 1 above, incorporated herein by reference.
FREITAS ‘963 discloses: The system of claim 1, wherein determining the maliciousness classification for the network traffic sample based at least in part on the context information (FIG. 8, [0072], a method 800 for classifying cyber-attacks at a cloud server. The method comprises receiving, step 802, an anomaly message (including the context information for the network traffic sample; as explained with respect to claim 1, [0067] indicates that an “anomaly message” is generated based on information derived from “network flow features”, i.e., context information, which is extracted from network traffic) from at least one anomaly detector. The method comprises extracting and normalizing, step 804, aggregated features from the anomaly message to produce a data pattern for evaluation. The method comprises computing, step 806, for the data pattern under evaluation, a score for each of a plurality of classes trained in an anomaly classifier running in the cloud server (determining the malicious classification based at least in part on context information). The method comprises comparing, step 808, a highest of the computed scores with a threshold and, if the highest of the computed scores is greater than the threshold assigning a class, which corresponds to the class associated with the highest score, to the data pattern under evaluation, and, assigning "unknown class" otherwise) comprises:
FREITAS ‘963 does not disclose but KUMAR ‘711 discloses: querying a machine learning model for a predicted maliciousness classification based at least in part on the context information (FIG. 1, [0028], an artificial intelligence (AI)-based fraud detection system 100 for monitoring alerts ... receiving a request (querying a machine learning model), at block 110, for evaluating an alert to predict whether the alert warrants an investigation, where the alert may be associated with suspicious activities (based at least in part on the context information) listed in tabular data, receiving the tabular data and converting the received tabu-lar data, at block 120, into natural language strings for inputting into an LLM by creating prompts and completions from the tabular data, generating a predictive score, at block 150, via an LLM-trained machine learning (ML) model (the machine learning model) ... the predictive score (a predicted maliciousness classification) indicates whether any of the suspicious activities warrant an investigation, comparing the predictive score to a threshold value for classification, and providing an alert prioritization, at block 160, based on the classification of the predictive score).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified FREITAS ‘963 with the generation of a predictive score indicating whether suspicious activities warrant an investigation based on an LLM-trained language model as taught by KUMAR ‘711 because it would enable identification of complex and evolving fraud patterns across large and diverse data sets, improving detection accuracy.
Claim(s) 20-21 is/are rejected under 35 U.S.C. 103 as being unpatentable over FREITAS ‘963 in view of TOGARI et al., US-20210306351-A1 (hereinafter “TOGARI ‘351”).
Per claim 20 (dependent on claim 1):
FREITAS ‘963 discloses the elements detailed in the rejection of claim 1 above, incorporated herein by reference.
FREITAS ‘963 does not disclose but TOGARI ‘351 discloses: The system of claim 1, wherein:
the network traffic sample comprises a predefined number of packets; and
the security entity determines to send the network traffic sample to a cloud security service based at least in part on a determination that the predefined number of packets matches a pre-filtering signature
(FIG. 7, [0078], Also, the packet forwarding device 100 (the security entity) includes an information collection unit 120 (collecting the network traffic sample) that sets, to the ACL, conditions (a pre-filtering signature) of each piece of attribute information (e.g. address, transmission source IP address) of a communication packet, and thus transmits the number of packets that match the conditions (based at least in part on a determination that the predefined number of packets matches a pre-filtering signature) in a predetermined sampling time as traffic information to the anomaly detection storage device 300 – a cloud security service; FIG. 8, [0080], the forwarding device controller 200; [0081], generating a configuration of the packet forwarding device 100 to pull only a specific flow into the security device 4).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified FREITAS ‘963 with the transmission of the number of packets that match the condition to the anomaly detection storage device as taught by TOGARI ‘351 because the processing load on the security device can be reduced by analyzing only traffic that satisfies specified conditions [0012][0014]. Additionally, TOGARI ‘351 is analogous to the claimed invention because it teaches a network configuration of the infection-spreading attack detection system [FIG. 6].
Per claim 21 (dependent on claim 1):
FREITAS ‘963 discloses the elements detailed in the rejection of claim 1 above, incorporated herein by reference.
FREITAS ‘963 does not disclose but TOGARI ‘351 discloses: The system of claim 1, wherein:
the network traffic sample comprises a predefined number of bytes; and
the security entity determines to send the network traffic sample to a cloud security service based at least in part on a determination that the predefined number of bytes matches a pre-filtering signature
(FIG. 7, [0078], Also, the packet forwarding device 100 (the security entity) includes an information collection unit 120 (collecting the network traffic sample) that sets, to the ACL, conditions (a pre-filtering signature) of each piece of attribute information (e.g. address, transmission source IP address) of a communication packet, and thus transmits the number of packets that match the conditions in a predetermined sampling time (based at least in part on a determination that the predefined number of bytes matches a pre-filtering signature; it is noted that for network traffic conforming to the IPv4 protocol (see [0005]), the packet size can be extracted from the “Total Length” field of the header, and a number of bytes can be calculated along with a “predetermined sampling time”) as traffic information to the anomaly detection storage device 300 – a cloud security service; FIG. 8, [0080], the forwarding device controller 200; [0081], generating a configuration of the packet forwarding device 100 to pull only a specific flow into the security device 4).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified FREITAS ‘963 with the transmission of the number of packets that match the condition to the anomaly detection storage device as taught by TOGARI ‘351 because the processing load on the security device can be reduced by analyzing only traffic that satisfies specified conditions [0012][0014].
Claim(s) 27 is/are rejected under 35 U.S.C. 103 as being unpatentable over FREITAS ‘963 in view of Mandal et al., US-20210097186 -A1 (hereinafter “Mandal ‘186”).
Per claim 27 (dependent on claim 1):
FREITAS ‘963 discloses the elements detailed in the rejection of claim 1 above, incorporated herein by reference.
FREITAS ‘963 discloses: The system of claim 1, wherein determining the maliciousness classification for the network traffic sample based at least in part on the context information (FIG. 8, [0072], a method 800 for classifying cyber-attacks at a cloud server (which corresponds to the AC module 110 of FIG. 1). The method comprises receiving, step 802, an anomaly message (including the context information for the network traffic sample; [0067] indicates that an “anomaly message” is generated based on information derived from “network flow features”, i.e., the context information, which is extracted from network traffic) from at least one anomaly detector. The method comprises extracting and normalizing, step 804, aggregated features from the anomaly message to produce a data pattern for evaluation. The method comprises computing, step 806, for the data pattern under evaluation, a score (the maliciousness classification) for each of a plurality of classes trained in an anomaly classifier running in the cloud server (determining the maliciousness classification based at least in part on the context information). The method comprises comparing, step 808, a highest of the computed scores with a threshold and, if the highest of the computed scores is greater than the threshold assigning a class, which corresponds to the class associated with the highest score, to the data pattern under evaluation, and, assigning "unknown class" otherwise).
FREITAS ‘963 does not disclose but Mandal ‘186 discloses: determining that a combination of commands associated with the session is malicious even though one or more of the individual commands in the combination are individually legitimate commands when considered in isolation (FIG. 2, [0044], selected elements of an analysis pipeline 204, which can be used to analyze a process such as a Windows PowerShell command line or other command line script (a combination of commands) to determine if the process is part of a "living off the land" style attack; [0049], a pre-execution phase 208 first receives the command line script 202 ... analyze the command line itself for suspicious factors (determining that a combination of commands associated with the session is malicious). This could include looking for suspicious flags or operations, such as execution with no profile, execution in Hidden Mode, a non-interactive PowerShell (associated with the session of Windows PowerShell), an encoded command (e.g., encoded within Base64), execution policy bypass attempt (associated with the session of Windows PowerShell) ... However, because there are many legitimate uses for each of these flags and solutions (even though one or more of the individual commands in the combination are individually legitimate commands when considered in isolation), per se triggering may result in a substantial number of false positives, which ultimately may result in the detection being disabled; [0052], From pre-script execution stage logs, several important behaviors may be inspected within memory; [0053], Pre-execution phase 208 may provide a preliminary score to be associated with command line script 202. This preliminary score may include a degree of suspiciousness based on a sum of individual scores provided within pre-execution phase 208; note that a combination of commands refers to a set of PowerShell commands, command-line arguments, flags, or expressions whose collective occurrence is analyzed based on their behavioral correlation, rather than evaluating each command individually – see [0022]).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified FREITAS ‘963 with the pre-execution analysis of a command-line script for identification of suspicious command-line arguments, flags, and execution parameters as taught by Mandal ‘186 because by correlating a plurality of behaviors, the number of false positives can be reduced, while the number of correct positive detections can remain high [0022]. Additionally, Mandal ‘186 is analogous to the claimed invention because it teaches analyzing a process such as a Windows PowerShell command line or other command line script [0044].
Claim(s) 29 is/are rejected under 35 U.S.C. 103 as being unpatentable over FREITAS ‘963 in view of Mushtaq, US-11595437-B1 (hereinafter “Mushtaq ‘437”).
Per claim 29 (dependent on claim 1):
FREITAS ‘963 discloses the elements detailed in the rejection of claim 1 above, incorporated herein by reference.
FREITAS ‘963 does not disclose but Mushtaq ‘437 discloses: The system of claim 1, wherein the security entity handles network traffic for the session by blocking the network traffic for the session in real-time in response to receiving an indication of the maliciousness classification from the cloud security service (FIG. 2, [Col. 15], ll.39 – [Col. 16], ll.19, data flows within a remote endpoint protection platform 200 ... the endpoint agent 210 (the security entity) deployed to an endpoint device and an endpoint management system 220 (the cloud security service) residing on a remote cloud in communication with the endpoint agent and/or the endpoint device ... The endpoint agent 210 may be built-in agents such as browser extension or mobile application for processing captured SMS, network flow data (e.g., capture network session activity between the endpoint device and one or more internet servers (the security entity handles network traffic for the session) ... the endpoint agent 210 and the detection cloud 223 may perform real-time URL scanning (in real-time). For instance, the endpoint agent may download the intelligence data such as domain/url block list 231 (e.g., real-time domain streaming data and IP blacklist feed) from the cloud for blacklist matching analysis (in response to receiving an indication of the maliciousness classification from the cloud security service) ... If there is a match, malicious traffic may be blocked (e.g., block phishing sites 213 – by blocking the network traffic for the session).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified FREITAS ‘963 with the blocking of malicious traffic if there is a match based on the domain/url block list downloaded from the detection cloud as taught by Mushtaq ‘437 because the architecture enables real-time phishing protection at the end point while leveraging cloud-based threat intelligence and analytics. Additionally, Mushtaq ‘437 is analogous to the claimed invention because it teaches data flows within a remote endpoint protection platform 200 such as between the endpoint agents 210 and the backend endpoint management system 220 [FIG. 2].
Allowable Subject Matter
Claim(s) 9 and 28 is/are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
XIANG et al., US-20250016220-A1 – the disclosure provides intrusive and non-intrusive Honeypot deployment modes in which malicious traffic is either dynamically redirected to a Honeypot cluster while normal traffic is forwarded to a production service, or all traffic is led to separately deployed Honeypots through probes such as EIPs, domain-name IRIs, and intranet IPs.
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 SANGSEOK PARK whose telephone number is (571)272-4332. The examiner can normally be reached Monday-Friday 7:30-5:30 and Alternate Fridays 9:00 am-5:00 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, PHILIP CHEA can be reached at (571)272-3951. 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.
/SANGSEOK PARK/Primary Examiner, Art Unit 2499
Prosecution Insights