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 .
Claims 21-38 have been examined.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 06/03/2026 has been entered.
Response to Amendment
Claims 21 and 31 have been amended.
The amendment to claim 21 filed on 05/18/2026 does not comply with the requirements of 37 CFR 1.121(c) because of the failure to provide a marked up version of the amended claim. Amendments to the claims filed on or after July 30, 2003 must comply with 37 CFR 1.121(c) which states:
(c) Claims. Amendments to a claim must be made by rewriting the entire claim with all changes (e.g., additions and deletions) as indicated in this subsection, except when the claim is being canceled. Each amendment document that includes a change to an existing claim, cancellation of an existing claim or addition of a new claim, must include a complete listing of all claims ever presented, including the text of all pending and withdrawn claims, in the application. The claim listing, including the text of the claims, in the amendment document will serve to replace all prior versions of the claims, in the application. In the claim listing, the status of every claim must be indicated after its claim number by using one of the following identifiers in a parenthetical expression: (Original), (Currently amended), (Canceled), (Withdrawn), (Previously presented), (New), and (Not entered).
(1) Claim listing. All of the claims presented in a claim listing shall be presented in ascending numerical order. Consecutive claims having the same status of “canceled” or “not entered” may be aggregated into one statement (e.g., Claims 1–5 (canceled)). The claim listing shall commence on a separate sheet of the amendment document and the sheet(s) that contain the text of any part of the claims shall not contain any other part of the amendment.
(2) When claim text with markings is required. All claims being currently amended in an amendment paper shall be presented in the claim listing, indicate a status of “currently amended,” and be submitted with markings to indicate the changes that have been made relative to the immediate prior version of the claims. The text of any added subject matter must be shown by underlining the added text. The text of any deleted matter must be shown by strike-through except that double brackets placed before and after the deleted characters may be used to show deletion of five or fewer consecutive characters. The text of any deleted subject matter must be shown by being placed within double brackets if strike-through cannot be easily perceived. Only claims having the status of “currently amended,” or “withdrawn” if also being amended, shall include markings. If a withdrawn claim is currently amended, its status in the claim listing may be identified as “withdrawn—currently amended.”
(3) When claim text in clean version is required. The text of all pending claims not being currently amended shall be presented in the claim listing in clean version, i.e., without any markings in the presentation of text. The presentation of a clean version of any claim having the status of “original,” “withdrawn” or “previously presented” will constitute an assertion that it has not been changed relative to the immediate prior version, except to omit markings that may have been present in the immediate prior version of the claims of the status of “withdrawn” or “previously presented.” Any claim added by amendment must be indicated with the status of “new” and presented in clean version, i.e., without any underlining.
(4) When claim text shall not be presented; canceling a claim.
(i) No claim text shall be presented for any claim in the claim listing with the status of “canceled” or “not entered.”
(ii) Cancellation of a claim shall be effected by an instruction to cancel a particular claim number. Identifying the status of a claim in the claim listing as “canceled” will constitute an instruction to cancel the claim.
(5) Reinstatement of previously canceled claim. A claim which was previously canceled may be reinstated only by adding the claim as a “new” claim with a new claim number.
Since the reply filed on 05/18/2026 appears to be bona fide, applicant is given a TIME PERIOD of ONE (1) MONTH or THIRTY (30) DAYS from the mailing date of this notice, whichever is longer, within which to submit an amendment in compliance with 37 CFR 1.121 in order to avoid aban-donment. EXTENSIONS OF THIS TIME PERIOD MAY BE GRANTED UNDER 37 CFR 1.136(a).
Response to Arguments
Applicant's arguments filed with respect to claim 21 have been fully considered but they are not persuasive. Applicant’s arguments on page 9 of the Remarks state that claim 21 has been amended to recite: “a smart meter logic configured to: execute within a first hardware-based trusted execution environment; receive, through the communication port, attested power source data wherein the power source data comprises a plurality of metrics”. However, these limitations are not present in claim 21. Moreover, the examiner has not found support for these limitations in the specification of the instant application.
Applicant’s arguments on page 9 of the Remarks state that prior art of record Venkataramani fails to teach determining an interest level based on the connection being anomalous in the specific context of the "historic behavior of a device associated with the connection" or the "peer group behavior for the device". However, these limitations are not present in claim 21 and therefore, the arguments are moot.
Applicant’s arguments on page 9 state that prior art of record Venkatramani fails to disclose applying an "interest classifier" that dictates a "first interest level" for analyzing packets by a deep packet inspection engine and a "second interest level less than the first interest level" for actively redirecting packets away from the deep packet inspection engine without processing. The examiner respectfully disagrees with these arguments. According to the published specification of the instant application: [0152]: A classifier module of the traffic manager module can execute a comparison of features of the connection to a set of interest criteria to determine an interest level for the cyber threat defense platform in the connection (Block 1804). The classifier module can determine that the connection is interesting based on the connection being at least one of a short-lived connection, able to be decrypted within a parameter set for the client device, or outside a normal connection pattern (Block 1806). The classifier module can determine that the connection is not interesting based on the connection being at least one of a long-lived connection, unable to be decrypted within a parameter set for the client device, and within a normal connection pattern (Block 1906), i.e., the connection is determined to be interesting if the connection is outside the normal connection pattern and the connection is determined to be not interesting if the connection is within the normal connection pattern. Prior art of record Venkatramani teaches: [0137]-[0138]: The process 500 includes receiving (502) one or more pieces of activity data (e.g., connection information and/or application execution information) from one or more connectivity and application execution sensors. The process combines (506) context information with the received activity data to generate an activity record, i.e., an activity record includes connection information. [0139] When the security application is in a learning period or mode, a set of baseline signatures (connection lineage signatures and/or application execution signatures) is built from incoming activity records (e.g., session records and/or application execution records). [0142] During the learning period, new signatures should be carefully reviewed to identify if they are indeed normal traffic, i.e., baseline signatures for connections are built based on normal traffic. [0144] When the security application is in a detection period or mode, incoming records are compared against a set of baseline signatures stored in the signature database. [0145] The incoming activity record(s) (comprising of connection information) are compared (528) against the set of baseline signatures. An exact or close match (e.g., by a distance measure or difference in number of attributes as discussed further above) to one or more baseline signatures can be considered a normal or acceptable behavior. Larger deviations from matching the baseline signatures can indicate an anomalous condition. [0150]: Connection Lineage Signature (CLS) information can be used to refine (amplify or dampen) the estimation of abnormality in a network connection, i.e., if connection information matches a baseline signature, then it is considered to be within a normal connection pattern whereas if the connection information has a large deviation from the baseline signatures, it is considered to anomalous/abnormal (outside the normal connection pattern). Therefore, Venkatramani’s teachings are in accordance with the specification of the instant application.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 21-30 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of U.S. Patent No. 11997113. Although the claims at issue are not identical, they are not patentably distinct from each other because:
Instant application
U.S. Patent No. 11997113
21. A method for a cyber threat defense system to differentiate between data flows, comprising: determining an interest level in a connection by at least conducting a comparison of features of the connection to a set of interest criteria is used in determining routing of one or more data packets associated with the connection;
applying an interest classifier describing the interest level to the connection;
applying an interest classifier describing the interest level to the connection;
analyzing, by a deep packet inspection engine, one or more data packets of the connection for cyber threats in response to the interest classifier indicating a first interest level; and
redirecting the one or more data packets of the connection away from the deep packet inspection engine without processing of the one or more data packets by the deep packet inspection engine if the interest classifier indicating a second interest level less than the first interest level.
22. The method for the cyber threat defense system of claim 21, wherein the second interest level represents no interest in the connection.
25. The method for the cyber threat defense system of claim 21 further comprising: identifying at least one dropped packet in the connection operating as a passthrough connection by the deep packet inspection engine; and shunting the passthrough connection with the dropped packet away from the deep packet inspection engine.
28. The method for the cyber threat defense system of claim 21, further comprising: reconnecting the connection to the deep packet inspection engine upon detection by an analyzer module of an anomalous event at a first device in a client network being a destination for the one or more data packets; and adjusting the set of interest criteria based on the anomalous event.
29. The method for the cyber threat defense system of claim 21 further comprising: severing the connection upon detection by an analyzer module of an anomalous event at a first device in a client network being a destination for the one or more data packets.
30. A non-transitory computer readable medium comprising computer readable code operable, when executed by one or more processing apparatuses in the cyber threat defense system to instruct a computing device to perform the method of claim 21.
1. A method for a cyber threat defense system to differentiate between data flows, comprising: registering, at a traffic manager module of the cyber threat defense system, a connection between one or more devices within a client network to transfer a series of one or more data packets; executing a comparison of features of the connection to a set of interest criteria to determine an interest level for the cyber threat defense system in the connection; applying an interest classifier describing the interest level to the connection based on the comparison;
passing the one or more data packets of the connection to a deep packet inspection engine for further examination for cyber threats if the interest classifier indicates interest;
shunting the one or more data packets of the connection away from the deep packet inspection engine if the interest classifier indicates no interest;
identifying a dropped packet in a passthrough connection being processed by the deep packet inspection engine; and shunting the passthrough connection with the dropped packet away from the deep packet inspection engine.
5. The method for the cyber threat defense system of claim 1, further comprising: reconnecting a shunted connection to the deep packet inspection engine upon detection by an analyzer module of an anomalous event at a first device in the client network; and adjusting the set of interest criteria based on the anomalous event.
6. The method for the cyber threat defense system of claim 5, further comprising: severing the connection upon detection by the analyzer module of the anomalous event at the first device in the client network.
8. A non-transitory computer readable medium comprising computer readable code operable, when executed by one or more processing apparatuses in the cyber threat defense system to instruct a computing device to perform the method of claim 1.
Claims 31-38 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of U.S. Patent No. 11997113 in view of prior art of record US 20170163666 to Venkatramani et al (hereinafter Venkatramani).
Instant application
U.S. Patent No. 11997113
31. (Currently Amended) A cyber threat defense system, comprising: One or more processors; and a non-transitory computer readable medium accessible by the one or more processors, the non-transitory computer readable medium includes a tracker manager module that comprises a classifier module that, when executed by the one or more processors, is configured to (i) compare features of a connection to a set of interest criteria to determine an interest level by the cyber threat defense system in the connection in which the interest level corresponding to a likelihood of the connection being anomalous in context of historic behavior of a device associated with the connection or peer group behavior for the device, and (ii) apply an interest classifier describing the interest level to the connection based on the comparison,
a deep packet inspection engine that when executed by the one or more processors, is configured to identify a dropped packet in a passthrough connection; and
a diverter being software that, when executed by the one or more processors, is configured to;(i) route the connection to the deep packet inspection engine as the passthrough connection based on the applied interest classifier indicating a first interest level, and(ii) shunt the connection away from the deep packet inspection engine based on the applied interest classifier indicating a second interest level, and iii shunt the passthrough connection with the dropped packet away from the deep packet inspection engine.
32. The traffic manager module of claim 31, wherein the deep packet inspection engine is further configured to examine the one or more data packets of the connection for cyber threats if the interest classifier indicates a first interest level.
33. The traffic manager module of claim 32, wherein the diverter is further configured to shunt the one or more data packets of the connection away from the deep packet inspection engine.
34. The traffic manager module of claim 31, wherein the classifier module is further configured to adjust the set of interest criteria based on a set of host parameters for a client network.
35. The traffic manager module of claim 34, wherein the set of host parameters are at least one of storage capacity, processing capacity, and network bandwidth.
36. The traffic manager module of claim 31, wherein the deep packet inspection engine is configured to collect a packet capture of the one or more data packets for the connection.
37. The traffic manager module of claim 36 further comprising: an offload module configured to (i) send the packet capture to a cloud storage system and
(ii) set an expiration date for the packet capture in the cloud storage system indicating when the packet capture can be overwritten.
38. The traffic manager module of claim 31 being located at least one of a host- based agent, a virtualized sensor installed on a hypervisor, a centralized physical appliance, and a centralized cloud appliance.
9. A traffic manager module for a cyber threat defense system, comprising: a registration module stored in a non-transitory computer readable medium, the registration module is configured, when executed by a processor, to register a connection between one or more devices within a client network to transmit a series of one or more data packets; a classifier module stored in the non-transitory computer readable medium, the classifier module is configured, when executed, to compare to execute a comparison of features of the connection to a set of interest criteria to determine an interest level for the cyber threat defense system in the connection and to apply an interest classifier describing the interest level to the connection based on the comparison;
a deep packet inspection engine stored in the non-transitory computer readable medium, the deep packet inspection engine is configured to (ii) examine the one or more data packets of the connection for cyber threats if the interest classifier indicates interest and (ii) identify a dropped packet in a passthrough connection; and
a diverter stored in the non-transitory computer readable medium, the diverter is configured to shunt (i) the one or more data packets of the connection away from the deep packet inspection engine and (ii) the passthrough connection with the dropped packet away from the deep packet inspection engine.
10. The traffic manager module of claim 9, wherein the classifier module is further configured to adjust the set of interest criteria based on a set of host parameters for the client network.
11. The traffic manager module of claim 10, wherein the set of host parameters are at least one of storage capacity, processing capacity, and network bandwidth.
12. The traffic manager module of claim 9, wherein the deep packet inspection engine is configured to collect a packet capture of the one or more data packets for the connection.
13. The traffic manager module of claim 12, wherein further comprising: an offload module configured to send the packet capture to a cloud storage system.
14. The traffic manager module of claim 13, wherein the offload module is configured to: set an expiration date for the packet capture in the cloud storage system indicating when the packet capture should be overwritten.
15. The traffic manager module of claim 4, wherein the traffic manager module is located at least one of a host-based agent, a virtualized sensor installed on a hypervisor, a centralized physical appliance, and a centralized cloud appliance.
In claim 31, U.S. Patent No. 11997113 does not teach: determine an interest level by the cyber threat defense system in the connection in which the interest level corresponding to a likelihood of the connection being anomalous in context of historic behavior of a device associated with the connection or peer group behavior for the device. However, Venkatramani teaches:
determine an interest level by the cyber threat defense system in the connection in which the interest level corresponding to a likelihood of the connection being anomalous in context of historic behavior of a device associated with the connection or peer group behavior for the device (Venkatramani: [0007] In still another embodiment, the connection information includes the attributes of: user name initiating the communication, identification of the user device, etc. [0136] The collector application gathers the connectivity records from all connectivity and application execution sensors and normalizes them with the context information and stores the records in the connection and application execution monitoring database. [0138] The process receives (504) context information from one or more directory servers. As discussed further above, context information can include identity information about the entity involved with the activity data and/or information about files accessed. The process combines (506) context information with the received activity data to generate an activity record. In many embodiments, this provides that the actual end points (e.g., user, user account, device) are known for connections, i.e., the historical connections (historical behavior) of a device are collected. [0139] When the security application is in a learning period or mode, a set of baseline signatures (connection lineage signatures and/or application execution signatures) is built from incoming activity records (e.g., session records and/or application execution records). In many embodiments, the set of baseline signatures is built by counting (e.g., keeping a running count) of incoming records that match in a number of attributes, i.e., a baseline signature is based on a device’s historical behavior. [0144] When the security application is in a detection period or mode, incoming records are compared against a set of baseline signatures stored in the signature database. [0145] The incoming activity record(s) are compared (528) against the set of baseline signatures. An exact or close match (e.g., by a distance measure or difference in number of attributes as discussed further above) to one or more baseline signatures can be considered a normal or acceptable behavior. Larger deviations from matching the baseline signatures can indicate an anomalous condition. [0152]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to employ the teachings of Venkatramani in the invention of U.S. Patent No. 11997113 to include the above limitations. The motivation to do so would be to detect the vertical and horizontal propagation of the threat within an enterprise environment (Venkatramani: [0035]).
Claim Objections
Claim 21 is objected to because of the following informalities: claim 21 recites the limitation: “applying an interest classifier describing the interest level to the connection” two times. Also, claim 21 recites: “determining an interest level in a connection by at least conducting a comparison of features of the connection to a set of interest criteria is used in determining routing of one or more data packets associated with the connection” instead of “determining an interest level in a connection by at least conducting a comparison of features of the connection to a set of interest criteria wherein the interest level is used in determining routing of one or more data packets associated with the connection”. Appropriate correction is required.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 21, 22, 23, 29, and 30 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by prior art of record US 20170163666 to Venkatramani et al (hereinafter Venkatramani).
As per claim 21, Venkatramani teaches:
A method for a cyber threat defense system to differentiate between data flows, comprising:
determining an interest level in a connection by at least conducting a comparison of features of the connection to a set of interest criteria is used in determining routing of one or more data packets associated with the connection (Venkatramani: [0053]: a connectivity and application execution sensor implemented via hardware (e.g., a connectivity and application execution sensor security co-processor) or software (e.g., a connectivity and application execution sensor application) on a server captures envelope information of communications to and from the server. In several embodiments, a connectivity and application execution sensor generates one or more connection lineage signatures and can associate each signature with a connection to or from the server. [0144] When the security application is in a detection period or mode, incoming records are compared against a set of baseline signatures stored in the signature database. [0145] The incoming activity record(s) are compared (528) against the set of baseline signatures. An exact or close match (e.g., by a distance measure or difference in number of attributes as discussed further above) to one or more baseline signatures can be considered a normal or acceptable behavior (interest level). Larger deviations from matching the baseline signatures can indicate an anomalous condition. [0150]: Connection Lineage Signature (CLS) information can be used to refine (amplify or dampen) the estimation of abnormality (interest level) in a network connection. [0045]: route traffic associated with particular connections to filters for deeper inspection, i.e., an anomalous connection is routed to deep packet inspection filters));
applying an interest classifier describing the interest level to the connection; applying an interest classifier describing the interest level to the connection (Venkatramani: [0003]. [0038]. [0045]: Comparison data can be received from user-defined policies and a signature and baseline database built through unsupervised learning. Using the collected information, the collector server system within the threat detection and response system can identify potential threats. [0137]-[0138]: The process 500 includes receiving (502) one or more pieces of activity data (e.g., connection information and/or application execution information) from one or more connectivity and application execution sensors. The process combines (506) context information with the received activity data to generate an activity record, i.e., an activity record includes connection information. [0139] When the security application is in a learning period or mode, a set of baseline signatures (connection lineage signatures and/or application execution signatures) is built from incoming activity records. [0142] During the learning period, new signatures should be carefully reviewed to identify if they are indeed normal traffic. [0145] The incoming activity record(s) are compared (528) against the set of baseline signatures. An exact or close match (e.g., by a distance measure or difference in number of attributes as discussed further above) to one or more baseline signatures can be considered a normal or acceptable behavior (i.e., the connection is considered to be within normal connection patterns). Larger deviations from matching the baseline signatures can indicate an anomalous condition (i.e., the connection is considered to be outside normal connection patterns), i.e., the interest level in the connection is normal or anomalous. [0147], [0152]);
analyzing, by a deep packet inspection engine, one or more data packets of the connection for cyber threats in response to the interest classifier indicating a first interest level (Venkatramani: [0040] The threat detection and response system can respond to detected threats by performing enforcement against connections and/or application execution events involving specific IP addresses, machines, applications, processes, files, and/or users. In a number of embodiments, enforcement is determined based upon system administrator defined policies and enforcement can involve … reconfiguring connections within the network to route suspicious traffic (first interest level) through additional filters for heightened scrutiny using deeper levels of data inspection. [0045]: route traffic associated with particular connections to filters for deeper inspection, i.e., an anomalous connection is analyzed by deep packet inspection filters); and
redirecting the one or more data packets of the connection away from the deep packet inspection engine without processing of the one or more data packets by the deep packet inspection engine if the interest classifier indicating a second interest level less than the first interest (Venkatramani: [0040] The threat detection and response system can respond to detected threats by performing enforcement against connections and/or application execution events involving specific IP addresses, machines, applications, processes, files, and/or users. In a number of embodiments, enforcement is determined based upon system administrator defined policies and enforcement can involve … reconfiguring connections within the network to route suspicious traffic through additional filters for heightened scrutiny using deeper levels of data inspection. [0145]: An exact or close match (e.g., by a distance measure or difference in number of attributes as discussed further above) to one or more baseline signatures can be considered a normal or acceptable behavior (second interest level), i.e., connections considered normal or acceptable are not routed to additional filters for deeper data inspection).
As per claim 22, Venkatramani teaches:
The method for the cyber threat defense system of claim 21, wherein the second interest level represents no interest in the connection (Venkatramani: [0040]: In a number of embodiments, enforcement is determined based upon system administrator defined policies and enforcement can involve … reconfiguring connections within the network to route suspicious traffic through additional filters for heightened scrutiny using deeper levels of data inspection. [0145]: An exact or close match (e.g., by a distance measure or difference in number of attributes as discussed further above) to one or more baseline signatures can be considered a normal or acceptable behavior (second interest level), i.e., connections considered normal or acceptable represent connections of no interest and are not routed to additional filters for deeper data inspection).
As per claim 23, Venkatramani teaches:
The method for the cyber threat defense system of claim 22, wherein the interest classifier is assigned the first interest level when the connection is a short-lived connection or a connection associated with an abnormal connection pattern (Venkatramani: [0145] The incoming activity record(s) are compared (528) against the set of baseline signatures. Larger deviations from matching the baseline signatures can indicate an anomalous condition (i.e., the connection is considered to be outside normal connection patterns). [0150]: A connection lineage signature together with networking information about the associated connection (e.g., envelope information) can represent a comprehensive profile for a network connection record seen in enterprise networks. Connection Lineage Signature (CLS) information can be used to refine (amplify or dampen) the estimation of abnormality (first interest level) in a network connection).
As per claim 29, Venkatramani teaches:
The method for the cyber threat defense system of claim 21 further comprising: severing the connection upon detection by an analyzer module of an anomalous event at a first device in a client network being a destination for the one or more data packets (Venkatramani: [0054]: Enforcement actions can include, but are not limited to, dropping a specific connection).
As per claim 30, Venkatramani teaches:
A non-transitory computer readable medium comprising computer readable code operable, when executed by one or more processing apparatuses in the cyber threat defense system to instruct a computing device to perform the method of claim 21 (See claim 21).
Claim 24 is rejected under 35 U.S.C. 103 as being unpatentable over Venkatramani and prior art of record US 20110185419 to Boteler et al (hereinafter Boteler).
As per claim 24, Venkatramani does not teach the limitations of claim 24. However, Boteler teaches:
wherein the interest classifier is assigned the first interest level when contents of the connection are unable to be decrypted within a parameter set for a first device in a client network being a destination for the one or more data packets (Boteler: [0040] unknown network flows = a network communication which cannot be deciphered. [0077]: The event can be indicated by for instance the detection of a login attack, or for instance anomalous packet detection, unknown network flow detection. [0079]: When, as illustrated by threshold circuit 22, 100 detected events within an hour exceed a T=100 threshold an alarm condition is initiated by activating an alarm 24).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to employ the teachings of Boteler in the invention of Venkatramani to include the above limitations. The motivation to do so would be to reduce the manual work required by the application of correlation to digital event filters (Boteler: [0051]).
Claims 27 and 28 are rejected under 35 U.S.C. 103 as being unpatentable over Venkatramani and prior art of record US 20180219879 to Pierce (hereinafter Pierce).
As per claim 27, Venkatramani does not teach the limitations of claim 27. However, Pierce teaches:
further comprising: monitoring at least one of a connection length and a payload size associated with the connection associated with the redirecting of the one or more packets (Pierce: [0249] In some embodiments, the security monitoring program 1230 may identify a network traffic metric representing the duration of a network connection, where this duration metric is included in the received network traffic data. [0250] The duration of the connection indicates the longevity of the network connection and may be measured in any time unit, such as seconds. [0299] In some embodiments, the security monitoring program 1230 may determine when one or more of the metrics for the connection violate the permissible values or value ranges for the communication protocol being used. Accordingly, the security monitoring program 1230 may determine that such protocol violations represent a potential security threat to the network connection. [0318]. [0345]: In some embodiments, the security monitoring system 1116 may perform one or more corrective actions to correct the potential security threat, such as by executing anti-virus software, anti-malware operations, or any technically feasible software or hardware corrective actions to mitigate potential security threats).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to employ the teachings of Pierce in the invention of Venkatramani to include the above limitations. The motivation to do so would be to detect potential security threats with increased efficiency and accuracy (Pierce: [0010]).
As per claim 28, Venkatramani does not teach the limitations of claim 28. However, Pierce teaches:
further comprising: reconnecting the connection to the deep packet inspection engine upon detection by an analyzer module of an anomalous event at a first device in a client network being a destination for the one or more data packets; and adjusting the set of interest criteria based on the anomalous event (Pierce: [0241]. [0305] In some embodiments, the security monitoring program 1230 may determine that the additional or subsequent metrics no longer exhibit the same behavior as the previous behavior of the connection by determining that the connection no longer meets one or more of the same behavior profiles as determined by the initial categorization. For example, a network connection could be used for certain types of communications, such as when a connection is used for client-server request/response interactions, such as a user surfing the web. Subsequently, in some embodiments, the behavior of the connection may change radically, such as when the connection is later used for large file transfers or probing activity. In such embodiments, the security monitoring program 1230 may determine that the connection no longer resembles or corresponds to the same behavior profile, and such a significant change in the behavior of the connection represents a potential security threat to the connection. [0341]-[0344]. [0345]: In some embodiments, the security monitoring system 1116 may perform one or more corrective actions to correct the potential security threat, such as by executing anti-virus software, anti-malware operations, or any technically feasible software or hardware corrective actions to mitigate potential security threats (reconnecting to deep packet inspection engine)).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to employ the teachings of Pierce in the invention of Venkatramani to include the above limitations. The motivation to do so would be to detect potential security threats with increased efficiency and accuracy (Pierce: [0010]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
US 20180146007 to Cruz Mota et al: In one embodiment, a traffic model manager node receives data flows in a network and determines a degree to which the received data flows conform to one or more traffic models classifying particular types of data flows as non-malicious. If the degree to which the received data flows conform to the one or more traffic models is sufficient, the traffic model manager node characterizes the received data flows as non-malicious. Otherwise, the traffic model manager node provides the received data flows to a denial of service (DoS) attack detector in the network to allow the received data flows to be scanned for potential attacks.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MADHURI R HERZOG whose telephone number is (571)270-3359. The examiner can normally be reached 8:30AM-4:30PM.
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, Taghi Arani can be reached at (571)272-3787. 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.
MADHURI R. HERZOG
Primary Examiner
Art Unit 2438
/MADHURI R HERZOG/Primary Examiner, Art Unit 2438
Prosecution Insights