DETAILED ACTION
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 1/22/26 has been entered.
Response to Arguments
Applicant’s arguments with respect to the §101 rejections of the amended claims (see Remarks, pages 8-10) have been fully considered and are persuasive. The §101 rejections are withdrawn. However, the new limitation of the independent claims, which is essential to overcome the §101 rejection, is new matter. The claims are now rejected under §112a for lack of written description.
Applicant’s arguments with respect to the §103 rejection has been fully considered but are not persuasive. Applicant argues Rego ‘711 does not teach the claims as amended because the scoring system of Rego ‘711 does not disclose a prediction model that is independent of malignancy.
As an initial matter, the new limitation in question “predicting, in real-time and independent of whether the IOC is malignant, a priority of investigation …” is indefinite. See §112b rejection below. Moreover, as best understood, the “IOC” specified in this claim element is the IOC of activity that triggered the alert specified in the first limitation of the claim (“acquiring an observation result by a predetermined organization with respect to an indicator of compromise (IOC) included in a latest alert”). In Rego ‘711, the actual malignancy of the activity identified by the IOC is not determined until after one or more indicators in a network threat report are analyzed and scored/prioritized. See Rego ‘711, para 0014-0018. Hence, Rego ‘711 still reads on this new claim element. With respect to applicant’s assertion that the claim as amended recites a prediction model that operates “independent” of malignancy, it is not clear how applicant can make such a blanket assertion when the prediction model relies on indicator of compromises (IOC) from past alerts. As known in the art, IOCs are evidence that suggests a computer or network attack is imminent or is currently underway or that a compromise may have already occurred.1 Any prediction model that is based on IOCs from past alerts are dependent on the events that precipitated these alerts. Since IOCs by definition are indicators of an attack or compromise, the underlining events identified by the IOC have a likelihood of being an attack or compromise.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention. The independent claims incorporate new limitation “automatically processing an alert including a same IOC of the IOC when the predicted priority of the investigation of the IOC is high by configuring an analysis engine to apply the IOC as a custom blacklist or a custom signature to automatically detect the same IOC in a security log.” On page 9 of their Remarks filed on 12/19/25, Applicant provides the following explanation of the claimed subject matter: “… once an IOC is identified via the prediction, ‘the triggered conditions of the alert in the analysis engine 10 can be changed … [and] the IOC can be used in the analysis engine 10 as a custom blacklist or a custom signature.’” However, the lone support in the specification (see para 0042) describes using the IOC in the analysis engine as a custom blacklist or a custom signature, when “a malicious IOC is clearly specified by an analyst’s evaluation.” Applicant further explains in footnote 1 of their Remarks, a high priority of investigation does not inherently mean an IOC [identifies activity that] is malignant. As such, there is no support in applicant’s specification for configuring an analysis engine to apply the IOC as a custom blacklist or a custom signature in order to automatically process an alert including the same IOC when the predicted priority of the investigation of the IOC (from the latest alert) is high. New dependent claim 17 recites a similar limitation and is rejected for the same reasons. The other dependent claims inherit the defect of their parent claims.
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention. The independent claims incorporate a new limitation “predicting, in real-time and independent of whether the IOC is malignant, a priority …” As known in the art, an IOC, which stands for indicator of compromise, is evidence that suggests a computer or network attack is imminent or is currently underway or that a compromise may have already occurred.2 However, IOCs, in and of themselves, are not malignant. It is unclear what event(s), entit(ies) and/or object(s) are the basis for determining “whether the IOC is malignant.” The dependent claims inherit the defect of their parent claims.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-10 and 13-17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Rego et al. US 20200014711 (hereinafter Rego ‘711) in view of Stewart et al. US 8539577 (hereinafter Stewart ‘577) and Wu et al. US 20180365417 (hereinafter Wu ‘417).
As per claim 1, Rego ‘711 discloses a method comprising:
acquiring an observation result by a predetermined organization with respect to an indicator of compromise (IOC) included in a latest alert, the latest alert being information on cyber security (para 0022: “As another example, the network threat report 101 could include reports of network threats published by a network security organization.”; para 0023: “In this aspect the threat report analyzer 150 extracts the indicator 103 from the network threat report 101 by parsing the network threat report 101 based on the corresponding format or structure. … In a particular implementation, the indicator 103 corresponds to an indicator of compromise (IOC). An IOC includes an artifact (i.e., an observable feature) that indicates a network threat (e.g., a computer intrusion).”);
creating feature information of the IOC based on information obtained from the observation result (para 0024: “The threat report analyzer 150 determines one or more properties 105 associated with the indicator 103. The properties 105 include, for example, an indicator type, a threat type, an attack type, a registration date, a first seen date, a last seen date, a first reported date, a last reported date, a report source, a particular keyword, a kill chain phase, an attribution identifier, an attribution confidence, a report volume, a false positive rate, another property, or a combination thereof, as further described with reference to FIG. 2.”);
predicting, in real-time and independent of whether the IOC is malignant3, a priority of an investigation of the IOC using a learned model trained to output a label related to the priority based on feature information extracted from a plurality of past alerts and a plurality of correct labels related to an operation amount of an analyst applied to a corresponding IOC from the plurality of past alerts, the plurality of correct labels including a label indicating that priority is high to an IOC in which a number of times of manual investigation4 is equal to or more than a predetermined value and a label indicating that the priority is not high to an IOC in which the number of times of manual investigation is less than the predetermined value (para. 0022: “As an example, the network threat report 101 could include user posts on a web forum that discuss network security issues… In a particular implementation, the threat report analyzer 150 subscribes to receive network threat reports from various sources. For example, the threat report analyzer 150 subscribes to a service offered by the first source and receives the network threat report 101 from the second device 124 as part of the subscription. In a particular aspect, the first source includes a third-party (e.g., a business entity, a security expert, or both) that monitors network threats and publishes network threat reports (e.g., the network threat report 101).”; para. 0024, “The threat report analyzer 150 determines one or more properties 105 associated with the indicator 103. The properties 105 include, for example, an indicator type, a threat type, an attack type, a registration date, a first seen date, a last seen date, a first reported date, a last reported date, a report source, a particular keyword, a kill chain phase, an attribution identifier, an attribution confidence, a report volume, a false positive rate, another property, or a combination thereof, as further described with reference to FIG. 2.”; para. 0032: “In a particular example, the overall score 111 corresponds to a weighted sum of the confidence score 107 and the impact score 109. The overall score 111 indicates a first priority of the indicator 103.”; para 0042: “The system 100 thus enables the indicator 103 to be prioritized based on the confidence score 107 and the impact score 109.”; para 0054: “The report volume 205 (e.g., 451) indicates a count of reports that indicated that the indicator 103 is associated with malicious activity. For example, the network threat report 101 is based on a plurality of reports from a plurality of sources. To illustrate, the network threat report 101 indicates that a first particular source received a first number of reports (e.g., 51) indicating that the indicator 103 is associated with malicious activity and that a second particular source received a second number of reports (e.g., 400) indicating that the indicator 103 is associated with malicious activity. … In a particular example, the confidence score 107 is higher for the report volume 205 that is higher than a report volume confidence threshold. For example, if many reports indicate that the indicator 103 is associated with malicious activity, the indicator 103 is more likely to be associated with potential malicious activity. In a particular example, the impact score 109 is higher for the report volume 205 that is higher than a report volume impact threshold. For example, if many reports indicate that the indicator 103 is detected in association with malicious activity, the potential malicious activity associated with indicator 103 is likely to have a more severe impact.”; para 0070: “The properties 105 enable the threat report analyzer 150 to determine a priority (e.g., the overall score 111) of the indicator 103, as described with reference to FIG. 1.”); and
automatically processing an alert including a same IOC of the IOC when the predicted priority of the investigation of the IOC is high by configuring an analysis engine to apply the IOC as a custom blacklist or a custom signature to automatically detect the same IOC in a security log (para 0016, “The threat report analyzer determines, based on the confidence score and the impact score, a position of the indicator in a response queue and adds the indicator at the position in the response queue.”; para 0017, “The threat report analyzer retrieves the indicator from the response queue in response to determining that the indicator is a next indicator to be processed in the response queue. The threat report analyzer identifies, based on the confidence score and the impact score, an action to be performed. For example, the action includes monitoring network traffic corresponding to the indicator or blocking network traffic corresponding to the indicator. In a particular example, the threat report analyzer identifies the action to be performed in response to retrieving the indicator from the response queue. In another example, the threat report analyzer identifies the action to be performed independently of adding the indicator to the response queue. The threat report analyzer initiates performance of the action. In a particular example, the action is performed independently of receiving user input indicating that the action is to be performed.”; para 0018: “Indicators with a higher likelihood of being associated with malicious activity and/or indicators that indicate higher potential severity of malicious activity are processed earlier. Faster searching of (or access to) higher priority indicators improves computer functionality by enabling the threat report analyzer to prevent or reduce an impact of the corresponding malicious activity. … The threat report analyzer enables filtering of internet traffic that can be customized based on rules associated with computing the confidence score and the impact score for particular properties of indicators. Performing the action automatically (e.g., without receiving user input indicating that the action is to be performed) reduces (e.g., eliminates) a mean time to respond to malicious activity”; para 0087, “In a particular aspect, the threat report analyzer 150 selects medium-aggressive actions as the action 115 in response to determining that a second criterion is satisfied … The threat report analyzer 150, in response to determining that the second criterion is satisfied, sets the action 115 to include blocking proxy traffic associated with the indicator 103 and monitoring proxy traffic, email traffic, RP traffic, virtual private network (VPN) traffic, and external web logs associated with the indicator 103.”).
Although Rego ‘711 discloses that the threat report can include a user post on a web forum that discusses network security issues or can be published by a security expert who monitors network threats, which are both instances of manual investigation, Rego ‘711 does not expressly disclose the report volume, and corresponding report volume confidence threshold, is based on manual investigation. However, such a modification would have been obvious. For some indicators of malicious activity, the reports identifying these indicators would be generated, or at least initiated, by administrators or human analysts. In these situations, the report volume will identify the number of times someone was involved to generate the reports. For example, Stewart ‘577 discloses a method for fast flux detection, whereby a network administrator uses a GUI engine to input a domain name or a filename that the user has identified as being part of a fast flux network to generate a report (col. 7, lines 9-18; col. 10, lines 35-41). Since the network administer initiates the analysis by providing the domain name or filename, the generated report would have been indicative of manual investigation, and moreover, the report volume for this indicator of malicious activity would be reflective of a number of manual investigations. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Rego ‘711 such that the priority determination is based on the number of times of manual investigation. One would have been motivated to do so because reports generated by a human user may reflect more useful sources of actual threat detections for certain indicators of malicious activity since a network administrator can draw upon their experiences and knowledge.
Moreover, Rego ‘711 does not disclose, but Wu ‘417 discloses using a trained machine learning model to predict the priority of investigation of the IOC (fig. 3, ref. no. 304; para 0039-40: “At step 304, one or more of the systems described herein may assign at least one label from a set of labels to at least one incident report in the manually analyzed subset of the set of incident reports based on applying a machine learning model to the manually generated information. For example, assignment module 106 may, as part of computing device 202 in FIG. 2, assign at least one label from set of labels 218 to at least one incident report in manually analyzed subset 210 of set of incident reports 208 based on applying machine learning model 216 to manually generated information 212. The term “label,” as used herein, generally refers to any description, term, and/or categorization applied to an incident report. In some embodiments, a label may include an alphanumeric string. For example, a label may include a severity category, such as “severe,” “moderate,” “trivial,” and/or “not severe.” In other examples, a label may include a type of incident, such as “virus,” “network attack,” “Trojan,” “denial of service attack,” and/or “data exfiltration.” In some examples, a label may relate to how the incident is to be processed. For example, a label such as “ignore: false positive” may indicate that the incident should not be further analyzed while a label such as “escalate” may incident report should be assigned to an analyst.”; para. 0058: “At step 506, the systems described herein may propagate labels from labeled incident reports to unlabeled incident reports by applying a similarity metric to incident reports. For example, the systems described herein may establish a similarity metric based on the distance measures of step 504 and use the similarity metric to identify incident reports that are similar to labeled incident reports. In some embodiments, the systems described herein may propagate labels only when the neighborhood of the incident consists only of high-value or low-value security issues, and not a mixture of both. In some embodiments, the systems described herein may also propagate manually entered notes while propagating labels. In some examples, at step 508, the systems described herein may train a machine learning classification model based on text-mining-generated labels, similarity-propagated labels, and selected features and/or classify new incident reports to predict the incidents' severities. In one embodiment, the systems described herein may build a model on current features and labels and, when new incident reports arrive, quickly assign a severity score to the new incident reports for use by security analysts. At step 510, the systems described herein may assign incident reports labeled as severe to analysts for manual analysis. In some embodiments, the systems described herein may assign severe incident reports to analysts who recently handled incident reports with similar labels, features, and/or characteristics. In some embodiments, the systems described herein may repeat steps 502 and/or 504 with the newly labeled data produced by step 506 and/or perform some other type of supervised learning on the labeled incident reports produced by step 506.” [emphasis added]). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Rego ‘711 by using a trained machine learning model to predict the priority of investigation of an IOC. As known to one of ordinary skilled in the art, trained machine learning models are conventional and well utilized means to improve the accuracy and efficiency of automating a wide range of tasks, including prioritizing the processing of incident reports as taught by Wu ‘417. One would have been motivated to do so to use a known technique (trained machine learning model) to improve similar devices (Rego ’711) in the same way.
As per claim 2, Rego ‘711 in view of Stewart ‘577 and Wu ‘417 discloses the method according to claim 1 (supra). In addition, Rego ‘711 discloses wherein the method includes acquiring a detection status of an IOC-related matter by a threat intelligence service, and the feature information is created based on the detection status (para 0022: “In a particular aspect, the second device 124 is associated with a first source, such as a particular website, a particular organization, a third-party, or a combination thereof. As an example, the network threat report 101 could include user posts on a web forum that discuss network security issues. As another example, the network threat report 101 could include reports of network threats published by a network security organization. The threat report analyzer 150 can receive reports from many different sources concurrently.… In a particular implementation, the threat report analyzer 150 subscribes to receive network threat reports from various sources. For example, the threat report analyzer 150 subscribes to a service offered by the first source and receives the network threat report 101 from the second device 124 as part of the subscription. In a particular aspect, the first source includes a third-party (e.g., a business entity, a security expert, or both) that monitors network threats and publishes network threat reports (e.g., the network threat report 101).”; para 0023: “For example, an organization reports that the indicator 103 is associated with a network threat. As another example, a user posts the indicator 103 in a network security forum. In a particular implementation, the indicator 103 corresponds to an indicator of compromise (IOC). An IOC includes an artifact (i.e., an observable feature) that indicates a network threat (e.g., a computer intrusion).”; para 0024: “The threat report analyzer 150 determines one or more properties 105 associated with the indicator 103.”).
As per claim 3, Rego ‘711 in view of Stewart ‘577 and Wu ‘417 discloses the method according to claim 1 (supra). In addition, Rego ‘711 discloses wherein the observation result includes a domain name system (DNS) record corresponding to a domain name associated with the IOC (para 0050: “The registration date 242 (e.g., Jan. 16, 2017) indicates a date (e.g., a timestamp) at which a report indicates that the indicator 103 was registered with a registration authority. For example, the network threat report 101 is based on a report that indicates that the indicator 103 (e.g., a domain name) was registered on the registration date 242 (e.g., Jan. 16, 2017) with a registration authority (e.g., a domain name registrar).”).
Rego ‘711 does not disclose, but Stewart ‘577 discloses wherein the observation result includes a DNS record corresponding to a domain name associated with the IOC and the feature information is created based on a number of changes in the information of the DNS record (col. 2, lines 29-39: “A method and apparatus is disclosed herein for detecting fast flux networks. In one embodiment a method includes querying domain name system (DNS) records associated with a domain, and determining whether the domain name is part of a fast flux network from results of one or more queries. The DNS record queries are used to record unique instances of IP addresses, name servers, subnets, web servers, etc. associated with the domain. When the number or properties of unique entries associated with a DNS record exceeds a threshold or demonstrates certain properties, the network can be classified as a fast flux network.”; col. 3, lines 47-59: “Fast Flux Detector 102 analyzes the data in FF Detection Database 110 to detect which domain names are part of fast flux networks. In one embodiment, Fast Flux Detector 102 determines the number of unique records it sees over a certain time period for each domain's IP addresses and name servers. If the number of unique entries reaches a threshold, Fast Flux Detector 102 flags that domain as a fluxing domain and logs the domain, flux type, and threshold numbers to Fast Flux (FF) Log 108. In one embodiment, Fast Flux Detector 102 analyzes the data in FF Detection Database 110 for evidence of different types of fast flux networks based one or more configurable threshold values and time periods.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Rego ‘711 with the DNS record monitoring technique disclosed by Stewart ‘577. One would have been motivated to do so to detect and identify a fast flux network.
As per claim 4, Rego ‘711 in view of Stewart ‘577 and Wu ‘417 discloses the method according to claim 1 (supra). In addition, Rego ‘711 discloses wherein the observation result includes a domain name system (DNS) record corresponding to a domain name associated with the IOC (para 0050: “The registration date 242 (e.g., Jan. 16, 2017) indicates a date (e.g., a timestamp) at which a report indicates that the indicator 103 was registered with a registration authority. For example, the network threat report 101 is based on a report that indicates that the indicator 103 (e.g., a domain name) was registered on the registration date 242 (e.g., Jan. 16, 2017) with a registration authority (e.g., a domain name registrar).”).
Rego ‘711 does not disclose, but Stewart ‘577 disclose wherein the observation result includes a domain name system (DNS) record corresponding to a domain name associated with the IOC, and the feature information is created based on a number of times of use and a period of use of the DNS record (col. 3, lines 47-59: “Fast Flux Detector 102 analyzes the data in FF Detection Database 110 to detect which domain names are part of fast flux networks. In one embodiment, Fast Flux Detector 102 determines the number of unique records it sees over a certain time period for each domain's IP addresses and name servers. If the number of unique entries reaches a threshold, Fast Flux Detector 102 flags that domain as a fluxing domain and logs the domain, flux type, and threshold numbers to Fast Flux (FF) Log 108. In one embodiment, Fast Flux Detector 102 analyzes the data in FF Detection Database 110 for evidence of different types of fast flux networks based one or more configurable threshold values and time periods.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Rego ‘711 with the DNS record monitoring technique disclosed by Stewart ‘577. One would have been motivated to do so to detect and identify a fast flux network.
As per claim 5, Rego ‘711 in view of Stewart ‘577 and Wu ‘417 discloses the method according to claim 1 (supra). In addition, Rego ‘711 discloses the extraction method according to claim 1 (supra), wherein the feature information is created based on information obtained from the observation result and a statistic calculated from the information (para 0024: “The threat report analyzer 150 determines one or more properties 105 associated with the indicator 103. The properties 105 include, for example, … false positive rate”).
Claim 6 is a device comprising processing circuity that corresponds to claim 1. Hence, claim 6 is rejected for the same reasons as claim 1.
Claim 7 is a non-transitory computer-readable recording medium storing therein an extraction program that corresponds to claim 1. Hence, claim 7 is rejected for the same reasons as claim 1.
As per claim 8, Rego ‘711 in view of Stewart ‘577 and Wu ‘417 discloses the method according to claim 3 (supra). In addition, Stewart ‘577 discloses wherein creating the feature information based on the number of changes in the information of the DNS record includes counting a number of times of change of a resource record for at least one of an A, AAAA, CNAME, MX, NS, SOA, or TXT record type (col. 4, lines 1-9: “"Top Tier Flux" Networks--are those in which records at the registrar level are changed--where the registrar is an entity with the ability to register domain names with the registry on behalf of third parties. That is, changing address (A) records for QNAMES registered as hosts with a registrar, or changing NS records for a second level domain. These changes are all visible in, for example, VeriSign.RTM. Domain Name Zone Alerts (DNZA).”: col. 9, lines 1-29: “Processing logic compares the history or results of the DNS query analysis against one or more threshold values (processing block 506). In one embodiment, the default threshold values utilized by processing logic in the comparison are: max_soa=10; This is especially useful with retries since it indicates that something in a domain is being changed at a fairly fast rate. It means that, for example, a sub domain changed. max_TLD_ns_a_subnet=16; The number of unique class C subnets found in TLD NS Address records. max_ns_a_subnet=16; The number of unique class C subnets found in NS Address records (auth servers). max_domain_a_subnet=10; The number of class C subnets found in Domain Address records (auth servers). Although the threshold values utilized by Analysis Engine are modifiable, the default values listed above were selected to both maximize the detection of malicious fast flux networks, while minimizing the erroneous logging of legitimate network changes (e.g., network changes due to load balancing, harmless IP reassignment, etc.). As discussed above, in one embodiment the threshold values are located in a configuration file accessible by processing logic. Thus, the threshold values may be modified based on user needs, system resources, detected trends, type of network flux to be detected, etc. In one embodiment, threshold values may be modified by domain, domain group, or other set of data.”).
As per claim 9, Rego ‘711 in view of Stewart ‘577 and Wu ‘417 discloses the method according to claim 4 (supra). In addition, Stewart ‘577 discloses wherein creating the feature information based on the number of times of use of the DNS record includes calculating one or more statistics from a plurality of past DNS query counts for the DNS record. (col. 3, lines 47-59: “Fast Flux Detector 102 analyzes the data in FF Detection Database 110 to detect which domain names are part of fast flux networks. In one embodiment, Fast Flux Detector 102 determines the number of unique records it sees over a certain time period for each domain's IP addresses and name servers. If the number of unique entries reaches a threshold, Fast Flux Detector 102 flags that domain as a fluxing domain and logs the domain, flux type, and threshold numbers to Fast Flux (FF) Log 108. In one embodiment, Fast Flux Detector 102 analyzes the data in FF Detection Database 110 for evidence of different types of fast flux networks based one or more configurable threshold values and time periods.” [emphasis added]).
As per claim 10, Rego ‘711 in view of Stewart ‘577 and Wu ‘417 discloses the method according to claim 9 (supra). In addition, Stewart ‘577 discloses wherein the one or more statistics include at least one of an average value, a minimum value, a maximum value, a standard deviation, or a dispersion of the plurality of past DNS query counts. (col. 3, lines 47-59: “Fast Flux Detector 102 analyzes the data in FF Detection Database 110 to detect which domain names are part of fast flux networks. In one embodiment, Fast Flux Detector 102 determines the number of unique records it sees over a certain time period for each domain's IP addresses and name servers. If the number of unique entries reaches a threshold, Fast Flux Detector 102 flags that domain as a fluxing domain and logs the domain, flux type, and threshold numbers to Fast Flux (FF) Log 108. In one embodiment, Fast Flux Detector 102 analyzes the data in FF Detection Database 110 for evidence of different types of fast flux networks based one or more configurable threshold values and time periods.” [emphasis added]).
As per claim 13, Rego ‘711 in view of Stewart ‘577 and Wu ‘417 discloses the method according to claim 4 (supra). In addition, Stewart ‘577 discloses wherein creating the feature information based on the period of use of the DNS record includes calculating one or more statistics based on a duration between a first DNS query and a last DNS query associated with the DNS record. (col. 3, lines 47-59: “Fast Flux Detector 102 analyzes the data in FF Detection Database 110 to detect which domain names are part of fast flux networks. In one embodiment, Fast Flux Detector 102 determines the number of unique records it sees over a certain time period for each domain's IP addresses and name servers. If the number of unique entries reaches a threshold, Fast Flux Detector 102 flags that domain as a fluxing domain and logs the domain, flux type, and threshold numbers to Fast Flux (FF) Log 108. In one embodiment, Fast Flux Detector 102 analyzes the data in FF Detection Database 110 for evidence of different types of fast flux networks based one or more configurable threshold values and time periods.”).
As per claim 14, Rego ‘711 in view of Stewart ‘577 and Wu ‘417 discloses the method according to claim 2 (supra). In addition, Rego ‘711 and Stewart ‘577 discloses wherein the feature information is created based on a number of detections by a plurality of detection engines within the threat intelligence service (Rego ‘711, para. 0022, “As another example, the network threat report 101 could include reports of network threats published by a network security organization. The threat report analyzer 150 can receive reports from many different sources concurrently.”; para. 0055: “The false positive rate 244 (e.g., 33%) is based on a number of times the indicator 103 is detected (or reported) as associated with non-malicious (or benign) activity and a number of times the indicator 103 is detected (or reported) as associated with malicious activity. For example, the network threat report 101 indicates that the indicator 103 is reportedly associated with malicious activity. The threat report analyzer 150 determines, based on the historical data 121, the network threat report 101, or both, that the indicator 103 has been reported (or detected) as associated with non-malicious activity a first number of times (e.g., 1) and that the indicator 103 has been reported (or detected) as associated with malicious activity a second number of times (e.g., 2). The threat report analyzer 150 determines the false positive rate 244 (e.g., 33%) based on the first number of times and the second number of times (e.g., the false positive rate 244=the first number of times/(the first number of times+the second number of times)). In a particular example, the confidence score 107 is lower for the false positive rate 244 that is higher than a false positive threshold.”; para. 0068: “The internal hits 237 (e.g., 500) indicates a number of times that indicator 103 is detected in network traffic. For example, the historical data 121 includes network logs, system logs, or both, that track network traffic in a particular network portion of the network 102.”; para. 0084, “In the first example 510, the threat report analyzer 150 determines that the action 115 associated with the indicator 103 has a low potential business impact because the second value (e.g., 0) of the internal hits 237 is below an internal hit threshold (e.g., 10).”; see also Stewart ‘577, fig. 2, ref. no. 220, engines 222-230; one of ordinary skill would have been motivated to rely on the system of Stewart ‘577 for threat reports in order to detect fast flux networks).
As per claim 15, Rego ‘711 in view of Stewart ‘577 and Wu ‘417 discloses the method according to claim 14 (supra). In addition, Rego ‘711 discloses wherein the feature information is created based on one or more statistics calculated from the number of detections, and the one or more statistics includes at least one of an average value, a minimum value, a maximum value, a standard deviation, or a dispersion (para. 0055: “The false positive rate 244 (e.g., 33%) is based on a number of times the indicator 103 is detected (or reported) as associated with non-malicious (or benign) activity and a number of times the indicator 103 is detected (or reported) as associated with malicious activity. For example, the network threat report 101 indicates that the indicator 103 is reportedly associated with malicious activity. The threat report analyzer 150 determines, based on the historical data 121, the network threat report 101, or both, that the indicator 103 has been reported (or detected) as associated with non-malicious activity a first number of times (e.g., 1) and that the indicator 103 has been reported (or detected) as associated with malicious activity a second number of times (e.g., 2). The threat report analyzer 150 determines the false positive rate 244 (e.g., 33%) based on the first number of times and the second number of times (e.g., the false positive rate 244=the first number of times/(the first number of times+the second number of times)). In a particular example, the confidence score 107 is lower for the false positive rate 244 that is higher than a false positive threshold.”; para. 0068: “The internal hits 237 (e.g., 500) indicates a number of times that indicator 103 is detected in network traffic. For example, the historical data 121 includes network logs, system logs, or both, that track network traffic in a particular network portion of the network 102.”; para. 0084, “In the first example 510, the threat report analyzer 150 determines that the action 115 associated with the indicator 103 has a low potential business impact because the second value (e.g., 0) of the internal hits 237 is below an internal hit threshold (e.g., 10).” [emphasis added]).
As per claim 16, Rego ‘711 in view of Stewart ‘577 and Wu ‘417 discloses the extraction method according to claim 1 (supra). In addition, Rego ‘711 discloses wherein the correct labels correspond to a number of times of manual investigation for the past alerts being equal to or more than a predetermined value. (para 0054: “The report volume 205 (e.g., 451) indicates a count of reports that indicated that the indicator 103 is associated with malicious activity. For example, the network threat report 101 is based on a plurality of reports from a plurality of sources. To illustrate, the network threat report 101 indicates that a first particular source received a first number of reports (e.g., 51) indicating that the indicator 103 is associated with malicious activity and that a second particular source received a second number of reports (e.g., 400) indicating that the indicator 103 is associated with malicious activity. … In a particular example, the confidence score 107 is higher for the report volume 205 that is higher than a report volume confidence threshold. For example, if many reports indicate that the indicator 103 is associated with malicious activity, the indicator 103 is more likely to be associated with potential malicious activity. In a particular example, the impact score 109 is higher for the report volume 205 that is higher than a report volume impact threshold. For example, if many reports indicate that the indicator 103 is detected in association with malicious activity, the potential malicious activity associated with indicator 103 is likely to have a more severe impact.”; para 0070: “The properties 105 enable the threat report analyzer 150 to determine a priority (e.g., the overall score 111) of the indicator 103, as described with reference to FIG. 1.”); see also Wu 417, fig. 3, ref. no. 304; para 0039-40: “At step 304, one or more of the systems described herein may assign at least one label from a set of labels to at least one incident report in the manually analyzed subset of the set of incident reports based on applying a machine learning model to the manually generated information. For example, assignment module 106 may, as part of computing device 202 in FIG. 2, assign at least one label from set of labels 218 to at least one incident report in manually analyzed subset 210 of set of incident reports 208 based on applying machine learning model 216 to manually generated information 212. The term “label,” as used herein, generally refers to any description, term, and/or categorization applied to an incident report. In some embodiments, a label may include an alphanumeric string. For example, a label may include a severity category, such as “severe,” “moderate,” “trivial,” and/or “not severe.” In other examples, a label may include a type of incident, such as “virus,” “network attack,” “Trojan,” “denial of service attack,” and/or “data exfiltration.” In some examples, a label may relate to how the incident is to be processed. For example, a label such as “ignore: false positive” may indicate that the incident should not be further analyzed while a label such as “escalate” may incident report should be assigned to an analyst.”).
As per claim 17, Rego ‘711 discloses the method according to claim 1 (supra). In addition, Rego ‘711 discloses wherein the analysis engine is a Security Information and Event Management (SIEM) system, and configuring the analysis engine to apply the IOC as the custom blacklist or the custom signature includes changing a logic of the SIEM system (fig. 1, SOC; para 0016, “The threat report analyzer determines, based on the confidence score and the impact score, a position of the indicator in a response queue and adds the indicator at the position in the response queue.”; para 0017, “The threat report analyzer retrieves the indicator from the response queue in response to determining that the indicator is a next indicator to be processed in the response queue. The threat report analyzer identifies, based on the confidence score and the impact score, an action to be performed. For example, the action includes monitoring network traffic corresponding to the indicator or blocking network traffic corresponding to the indicator. In a particular example, the threat report analyzer identifies the action to be performed in response to retrieving the indicator from the response queue. In another example, the threat report analyzer identifies the action to be performed independently of adding the indicator to the response queue. The threat report analyzer initiates performance of the action. In a particular example, the action is performed independently of receiving user input indicating that the action is to be performed.”; para 0018: “Indicators with a higher likelihood of being associated with malicious activity and/or indicators that indicate higher potential severity of malicious activity are processed earlier. Faster searching of (or access to) higher priority indicators improves computer functionality by enabling the threat report analyzer to prevent or reduce an impact of the corresponding malicious activity. … The threat report analyzer enables filtering of internet traffic that can be customized based on rules associated with computing the confidence score and the impact score for particular properties of indicators. Performing the action automatically (e.g., without receiving user input indicating that the action is to be performed) reduces (e.g., eliminates) a mean time to respond to malicious activity”; para 0087, “In a particular aspect, the threat report analyzer 150 selects medium-aggressive actions as the action 115 in response to determining that a second criterion is satisfied … The threat report analyzer 150, in response to determining that the second criterion is satisfied, sets the action 115 to include blocking proxy traffic associated with the indicator 103 and monitoring proxy traffic, email traffic, RP traffic, virtual private network (VPN) traffic, and external web logs associated with the indicator 103.”).
Claims 11 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Rego ‘711 in view of Stewart ‘577 and Wu ‘417, and further in view of Mandrychenko US 20210084071 (hereinafter Mandrychenko) ‘071.
As per claim 11, Rego ‘711 in view of Stewart ‘577 and Wu ‘417 discloses the method according to claim 4 (supra). Rego ‘711 does not disclose, but Mandrychenko ‘071 discloses wherein creating the feature information based on the period of use of the DNS record includes [calculating one or more statistics based on a number of elapsed] days from a first DNS query associated with the DNS record (para 0038: “Further, DNS monitoring engine 202 can detect any modifications made in the DNS records from the obtained DNS results in a predefined or configurable time-frame according to requirements. .... The criticality value can further be based on attributes indicative of a time at which the modification was made or a record type of the DNS record; para. 0053: “According to an embodiment, database 310 can be used for storing information associated with various entities such as their domains; subdomains; DNS records; DNS modification with associated time, date and location information; information of the user who made the modification, and the like. In case if the modification to DNS is determined to be anomalous, then the modified information can be stored on database 310 with associated time, date and location information; information of the user who made the modification and the like.” [emphasis added]).
Although Mandrychenko ‘071 does not disclose, Rego ‘711 discloses calculating one or more statistics based on a number of elapsed days (para 0048: “The first seen date 201 (e.g., Mar. 12, 2018 4:33) indicates a date (e.g., a timestamp) at which a report indicates that the indicator 103 was first seen (or detected). For example, the network threat report 101 is based on a plurality of reports and a first report (e.g., a user post on a public forum) having an earliest seen date among the plurality of reports indicates that the indicator 103 was detected at the first seen date 201 (e.g., Mar. 12, 2018 4:33). In a particular example, the confidence score 107 is lower for the first seen date 201 that is prior to a threshold first seen date. For example, if the indicator 103 was first seen two years ago, the indicator 103 is less likely to be associated with potential malicious activity” [emphasis added]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of Rego ‘711 such that creating the feature information based on the period of use of the DNS record includes calculating one or more statistics based on a number of elapsed days from a first DNS query associated with the DNS record. One would have been motivated to do so 1) to identify anomalous modifications to DNS records as a potential DNS hijacking as taught by Mandrychenko ‘071 and 2) to determine whether a detected anomalous modification was likely not a malicious event as taught by Rego ‘711.
As per claim 12, Rego ‘711 in view of Stewart ‘577 and Wu ‘417 discloses the method according to claim 4 (supra). Rego ‘711 does not disclose, but Mandrychenko ‘071 discloses wherein creating the feature information based on the period of use of the DNS record includes [calculating one or more statistics based on a number of elapsed] days from a last DNS query associated with the DNS record (para 0038: “Further, DNS monitoring engine 202 can detect any modifications made in the DNS records from the obtained DNS results in a predefined or configurable time-frame according to requirements. .... The criticality value can further be based on attributes indicative of a time at which the modification was made or a record type of the DNS record; para. 053: “According to an embodiment, database 310 can be used for storing information associated with various entities such as their domains; subdomains; DNS records; DNS modification with associated time, date and location information; information of the user who made the modification, and the like. In case if the modification to DNS is determined to be anomalous, then the modified information can be stored on database 310 with associated time, date and location information; information of the user who made the modification and the like.” [emphasis added]).
Although Mandrychenko ‘071 does not disclose, Rego ‘711 discloses calculating one or more statistics based on a number of elapsed days (para 0049: “The last seen date 203 (e.g., May 12, 2018 8:23) indicates a date (e.g., a timestamp) at which a report indicates that the indicator 103 was last seen (or detected). For example, a second report (e.g., a network security publication) having a most recent seen date among the plurality of reports indicates that the indicator 103 was detected at the last seen date 203 (e.g., May 12, 2018 8:23). In a particular example, the confidence score 107 is lower for the last seen date 203 that is prior to a threshold last seen date. For example, if the indicator 103 was last seen a year ago, the indicator 103 is less likely to be associated with potential malicious activity.” [emphasis added]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of Rego ‘711 such that creating the feature information based on the period of use of the DNS record includes calculating one or more statistics based on a number of elapsed days from a last DNS query associated with the DNS record. One would have been motivated to do so 1) to identify anomalous modifications to DNS records as a potential DNS hijacking as taught by Mandrychenko ‘071 and 2) to determine whether a detected anomalous modification was likely not a malicious event as taught by Rego ‘711.
Claim 18 is rejected under 35 U.S.C. 103 as being unpatentable over Rego ‘711 in view of Stewart ‘577 and Wu ‘417, and further in view of Nabeel et al. US 20200382533 (hereinafter Nabeel ‘533).
As per claim 18, Rego ‘711 in view of Stewart ‘577 and Wu ‘417 discloses the method according to claim 4 (supra). Rego ‘711 does not disclose, but Nabeel ‘533 discloses wherein the observation result is acquired from a passive DNS database that records a history of DNS messages (para 0050, “The domain-IP data 106 may include passive DNS lists 116. The DNS lists 116 may include information on a corresponding apex domain 112 and hosting provider 110 for each entry on the DNS list.”), and creating the feature information based on the number of times of use of the DNS record includes counting a number of DNS queries observed for a combination of the domain name and a specific resource record in the passive DNS database (after para 0078, Table 3, “The number of times the DNS query for the domain-IP resolution is seen during time_first and time_last”) and calculating at least one of a standard deviation or a dispersion of the counted number of DNS queries (para 0060, “Another set of attributes used by the apex domain classifier 142 may include a query based attribute set. In an example, the attributes may comprise the average number of daily DNS lookup queries issued to all domains belonging to each apex domain, and the standard deviation of the number of DNS lookup queries for each apex domain. For example, if the query counts for an IP address exhibits larger variation per hosted domain, it may be more likely that the queried apex domain is a public apex, rather than a dedicated apex domain that may typically experience less variation due to a stable user base.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Rego ‘711 by acquiring the observations from a passive DN database and to generate statistics of the counted number of DNS queries as taught by Nabeel ‘533. One would have been motivated to do so to enable identification of actual domain queries/responses over a period and to utilize additional statistics based on DNS queries/responses over this period for improved malicious behavior detection.
Claim 19 is rejected under 35 U.S.C. 103 as being unpatentable over Rego ‘711 in view of Stewart ‘577 and Wu ‘417, and further in view of Taniguchi US 20200137095 (hereinafter Taniguchi ‘095).
As per claim 19, Rego ‘711 in view of Stewart ‘577 and Wu ‘417 discloses the method according to claim 4 (supra). Rego ‘711 does not disclose, but Taniguchi ‘095 discloses wherein creating the feature information based on the period of use of the DNS record includes:
extracting a date of a first observed DNS query and a date of a last observed DNS query for each of a plurality of resource records corresponding to the domain name (fig. 7, ref. no. S32; para 0057, “Then, the indicator diagnosing section 12 selects, for the selected domain, one of unselected A records registered in Passive DNS (in S32). Then, the indicator diagnosing section 12 calculates the number of dates elapsed from first seen and last seen for the selected A record (in S33).”),
calculating a duration of use for each of the plurality of resource records based on the extracted dates (fig. 7, ref. no. S33; para 0057, “Then, the indicator diagnosing section 12 calculates the number of dates elapsed from first seen and last seen for the selected A record (in S33). The indicator diagnosing section 12 causes the calculated result to be stored as existence period learning data in a memory.”) and
calculating a variance or a dispersion of the calculated durations (fig. 9, ref no. S43, S48; para 0062-0067, identify usage period of each A record for a domain using existence period learning data). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Rego ‘711 by generating statistics of the period of use of a domain as taught by Nabeel ‘533. One would have been motivated to do so to utilize additional statistics to ascertain particular utilization of the domain for improved malicious behavior detection.
Claim 20 is rejected under 35 U.S.C. 103 as being unpatentable over Rego ‘711 in view of Stewart ‘577 and Wu ‘417, and further in view of Yu et al. US 20160294773 (hereinafter Yu ‘773).
As per claim 20, Rego ‘711 in view of Stewart ‘577 and Wu ‘417 discloses the method according to claim 3 (supra). Furthermore, Stewart ‘577 discloses acquiring the observation result includes querying a passive DNS database containing historical resource records (col. 3, lines 49-51, “Fast Flux Detector 102 determines the number of unique records it sees over a certain time period for each domain's IP addresses and name servers.”), and
creating the feature information includes counting a total number of times the DNS record changed from a past time point to a present time point for each of an A record, (col. 3, lines 47-55, “Fast Flux Detector 102 analyzes the data in FF Detection Database 110 to detect which domain names are part of fast flux networks. In one embodiment, Fast Flux Detector 102 determines the number of unique records it sees over a certain time period for each domain's IP addresses and name servers. If the number of unique entries reaches a threshold, Fast Flux Detector 102 flags that domain as a fluxing domain and logs the domain, flux type, and threshold numbers to Fast Flux (FF) Log 108.”; col. 6, lines 26-29, “Fast Flux Monitoring Engine 228 then provides the monitoring results (e.g., domains, records, changes, etc.) to Analysis Engine 232. Analysis Engine 232 tests the values against thresholds.”; col. 6, lines 40-65, Table 1, “maxTLDNS The number of seen unique NS records (from the TLD server) detection threshold. maxTLDNSA The number of seen unique A records (for the NS records from the TLD server) detection threshold. maxNS The number of seen unique NS records (from the authoritative NS server) detection threshold. maxNSA The number of seen unique A records (for the NS records from the authoritative NS servers) detection threshold. maxDomainA The number of seen unique A records (for the domain from the authoritative NS servers) detection threshold. maxSOA The number of seen unique SOA records (for the domain from the authoritative NS servers) detection threshold. maxTLDNSASubnet The number of seen unique class C subnets (for the NS records from the authoritative NS servers) detection threshold. maxNSASubnet The number of unique class C subnets (for the domain from the authoritative NS servers) detection threshold.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Rego ‘711 with the DNS record monitoring technique disclosed by Stewart ‘577. One would have been motivated to do so to detect and identify a fast flux network by detecting an elevated number of changes to DNS records over time.
Stewart ’577 does not disclose counting unique AAAA, CNAME, MX and TXT records associated with a domain name. Yu ‘773 discloses using passive DNS traffic analysis to collect DNS data [para 0118]. Yu ‘773 discloses “[a]lthough most DNS tunneling techniques typically use ‘TXT’ type queries in DNS that can maximize the payload in response packets, there are implementations that make use of DNS query types other than ‘TXT’ such as ‘A’, ‘AAAA’, ‘CNAME’, ‘NS’, ‘MX’ and so on” [para 0017], and moreover, “[a] tunnel will use a query name to carry outbound payloads. The inbound payloads are carried in many different ways depending on the DNS resource record type. For example, in TXT type, the payload is encoded in the text. For many other types, such as A, AAAA, or CNAME, the payload is carried in one or more FQDNs. Unlike legitimate DNS queries that have consistency in query and response, a malicious tunnel tends to change the payload from message to message.” [emphasis added] [para 0059]. Hence, Yu ‘773 identifies that an elevated number of unique AAAA, CNAME, MX and TXT that are detected over time in DNS responses to the same DNS query are likely indicators of malicious DNS tunneling.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Rego ‘711 in view of Stewart ‘577 and Wu ‘417 to count the number of unique AAAA, CNAME, MX and TXT records associated with a domain name as taught by Yu ‘773, since Stewart ‘577 discloses counting unique records for a domain over time to detect malicious behavior and Yu ‘773 discloses that an elevated number of changes to certain resource records for a domain could be an indicator of malicious behavior. Tracking the number of unique AAAA, CNAME, MX and TXT records associated with a domain name would be desirable in order to identify malicious DNS tunneling.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JUNG W KIM whose telephone number is (571)272-3804. The examiner can normally be reached Monday-Friday, 10 a.m. - 6 p.m..
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, Amy Cohen Johnson can be reached at 571-272-2238. 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.
/JUNG W KIM/Supervisory Patent Examiner, Art Unit 2494
1 From NIST Computer Security Resource Center Glossary, https://csrc.nist.gov/glossary/term/indicator_of_compromise
2 From NIST Computer Security Resource Center Glossary, https://csrc.nist.gov/glossary/term/indicator_of_compromise
3 The limitation “predicting, … independent of whether the IOC is malignant, a priority” is construed as: predicting, independent of whether the activity evidenced by the IOC is malignant, a priority. See 112b rejection above. In Rego ‘711, since the underlying activity that generated the IOC can eventually be identified as benign, their prediction is independent of whether “the IOC is malignant” (see Rego, para 0055).
4 The limitation “manual investigation” in the context of the claim is construed to be any instance whereby a person is involved with the identification, analysis, or reporting of an IOC. Moreover, an individual can perform multiple “manual investigations” for the same IOC, each performed at separate discrete times. Likewise, multiple individuals can each perform one or more “manual investigations” for the same IOC.
Prosecution Insights