Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
DETAILED ACTION
This final action is responsive to amendment filed on 08/12/2026. Claims 1-24 are pending, with claims 1 and 13 being independent.
Priority
This application claims the benefit of and priority to Indian Provisional Application No. 202221075243, filed on December 23, 2022, and U.S. Provisional Application No. 63/443,891 filed on February 7, 2023.
Response to Arguments
Claim Objections
Previous objections have been withdrawn in view of amendment.
35 U.S.C. § 103 Rejections
Applicants’ arguments have been fully considered but they are not persuasive.
A. On pages 7 and 8 of remarks, applicant argues that Jeyakumar does not disclose "receiving, by one or more servers, a selection of one or more messages from a plurality of messages identified as threats."
Examiner respectfully disagrees. Jeyakumar teaches ingestion of threat intelligence from different types of sources such as: Inferred IOCs based on statistics of previously-seen attacks (e.g., the number of good or bad emails sent from the same source IP address)) (paragraphs 151-154). These citations indicate that there is selection of certain bad emails with certain IP address from a plurality of bad emails (corresponds to a plurality of messages identified as threats). Therefore, Jeyakumar teaches "receiving, by one or more servers, a selection of one or more messages from a plurality of messages identified as threats."
B. On page of remarks, applicant argues that Jeyakumar also does not disclose "identifying ... one or more candidate blacklist entries (BLEs)" or "determining ... a recommendation of one or more BLEs to add to a blacklist."
Examiner respectfully disagrees. Jeyakumar teaches inferred IOCs (paragraphs 151-154), and permit enabling/disabling of IOCs on a per-enterprise basis. For example, an enterprise may upload a list of IOCs to the threat detection platform that should be used specifically when examining their emails. Moreover, the threat detection platform may annotate IOCs with a probability so that those IOCs which are probably malicious can be supported. Thus, the threat detection platform could be designed to flag those emails determined to be malicious, as well as those emails that may be malicious (paragraph 157). These citations indicate that, from inferred IOCs (corresponds to candidate blacklist entries (BLEs)), IOCs with probability indicating malicious are enabled/selected/recommended for examining emails to detect malicious emails. Therefore, Jeyakumar teaches "identifying ... one or more candidate blacklist entries (BLEs)" or "determining ... a recommendation of one or more BLEs to add to a blacklist."
C. On pages 8 and 9 of remarks, applicant argues that Jeyakumar does not disclose "adding ... the one or more BLEs to the blacklist, wherein the blacklist is used by an email system to block messages that match at least the one or more BLEs on the blacklist."
Examiner respectfully disagrees. As shown in part (B), Jeyakumar teaches that the enterprise may upload a list of IOCs for examining emails to detect malicious emails. Jeyakumar also teaches malicious emails are prevented from reaching their intended destination (see Figure 2). Therefore, that Jeyakumar teaches "adding ... the one or more BLEs to the blacklist, wherein the blacklist is used by an email system to block messages that match at least the one or more BLEs on the blacklist."
Claim Objections
Claim 1 is objected to because of the following informalities:
“one or more servers severs” should read “one or more servers”.
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.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-3, 5-7, 9, 13-15, 17-19 and 21 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Jeyakumar et al. (US 2020/0389486, published Dec. 10, 2020).
As per claim 1, Jeyakumar discloses a method comprising:
receiving, by one or more servers, a selection of one or more messages from a plurality of messages identified as threats (Jeyakumar Fig. 15A and par. 151-154, At a high level, the threat detection platform can be designed to perform various tasks including: Ingestion of threat intelligence from different types of sources such as: Inferred IOCs based on statistics of previously-seen attacks (e.g., the number of good or bad emails sent from the same source IP address). [These citations indicate that there is selection of certain bad emails with certain IP address from a plurality of bad emails (corresponds to a plurality of messages identified as threats)]);
identifying, by the one or more servers based at least on the one or more messages, one or more candidate blocklist entries (BLEs) (Jeyakumar Fig. 15A and par. 151-154, At a high level, the threat detection platform can be designed to perform various tasks including: Ingestion of threat intelligence from different types of sources such as: Inferred IOCs [candidate BLEs] based on statistics of previously-seen attacks (e.g., the number of good or bad emails sent from the same source IP address));
determining, by the one or more servers based at least on the more or more candidate BLEs, a recommendation of one or more BLEs to add to a blocklist (Jeyakumar par. 157, Embodiments of the threat detection platform may also be designed to permit enabling/disabling of IOCs on a per-enterprise basis. For example, an enterprise may upload a list of IOCs to the threat detection platform that should be used specifically when examining their emails. Moreover, the threat detection platform may annotate IOCs with a probability so that those IOCs which are probably malicious can be supported. Thus, the threat detection platform could be designed to flag those emails determined to be malicious, as well as those emails that may be malicious. [These citations indicate that, from inferred IOCs (corresponds to candidate blacklist entries (BLEs)), IOCs with probability indicating probably malicious are enabled/selected/recommended for examining emails to detect malicious emails]); and
adding, by the one or more servers, the one or more BLEs to the blocklist (Jeyakumar par. 157, an enterprise may upload a list of IOCs to the threat detection platform that should be used specifically when examining their emails), wherein the blocklist is used by an email system to block messages that match at least the one or more BLEs on the blocklist (Jeyakumar par. 157, an enterprise may upload a list of IOCs to the threat detection platform that should be used specifically when examining their emails… Thus, the threat detection platform could be designed to flag those emails determined to be malicious; Jeyakumar Fig. 2, malicious emails are prevented from reaching their intended destination).
As per claim 2, Jeyakumar discloses the method of claim 1, further comprising receiving, by the one or more servers, the plurality of messages from a threat detection system (Jeyakumar Fig. 15A and par. 151-154, At a high level, the threat detection platform can be designed to perform various tasks including: Ingestion of threat intelligence from different types of sources such as: Inferred IOCs based on statistics of previously-seen attacks (e.g., the number of good or bad emails sent from the same source IP address)).
As per claim 3, Jeyakumar discloses the method of claim 2, further comprising adding, by the threat detection system, a label to the one or more messages to identify potential threats in the one or more messages (Jeyakumar Fig. 15A and par. 151-154, At a high level, the threat detection platform can be designed to perform various tasks including: Ingestion of threat intelligence from different types of sources such as: Inferred IOCs based on statistics of previously-seen attacks (e.g., the number of good or bad emails sent from the same source IP address)).
As per claim 5, Jeyakumar discloses the method of claim 1, further comprising determining, by the one or more servers, the recommendation of the one or more BLEs to add to the blocklist according to a BLE characteristic type of a plurality of BLE characteristic types (Jeyakumar Fig. 15B and par. 178, the interface may allow the enterprise to readily sort IOCs by severity level so that those IOCs representing the largest threat [recommendation of BLEs] can be dealt with).
As per claim 6, Jeyakumar discloses the method of claim 1, further comprising providing, by the one or more servers, a user interface to an administrator to select a confidence level for which to block messages similar to the plurality of messages identified as threats (see Jeyakumar Fig. 15B, the interface selecting confidence level).
As per claim 7, Jeyakumar discloses the method of claim 6, further comprising determining, by the one or more servers, the recommendation of the one or more BLEs based at least on the selected confidence level (Jeyakumar par. 157, Embodiments of the threat detection platform may also be designed to permit enabling/disabling of IOCs on a per-enterprise basis; Jeyakumar Fig. 15B and par. 170-178, A schema may be employed to ensure that threat intelligence is accounted for in a consistent manner. For a given IOC, the scheme may indicate… A severity… A confidence metric… the interface may allow the enterprise to readily sort IOCs by severity level so that those IOCs representing the largest threat [recommendation of BLEs] can be dealt with).
As per claim 9, Jeyakumar discloses the method of claim 1, wherein the blocklist is a private blocklist (Jeyakumar par. 157, Embodiments of the threat detection platform may also be designed to permit enabling/disabling of IOCs on a per-enterprise basis. For example, an enterprise may upload a list of IOCs to the threat detection platform that should be used specifically when examining their emails).
Claims 13-15, 17-19 and 21 do not teach or further define over the limitations in claims 1-3, 5-7 and 9 respectively. As such, claims 13-15, 17-19 and 21 are rejected for the same reasons as set forth in claims 1-3, 5-7 and 9, respectively.
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 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 4 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Jeyakumar et al. (US 2020/0389486, published Dec. 10, 2020) and Acton et al. (US 10,587,551, published Mar.10,2020).
As per claim 4, Jeyakumar discloses the method of claim 1, but does not explicitly disclose further comprising receiving, by the one or more servers, the selection of the one or more messages from an administrator via a user interface.
Acton teaches:
receiving the selection of the one or more messages from an administrator via a user interface (Acton 19:9-11, Agents and administrators may be empowered to sort and select message threads based on tags).
It would have been obvious to one skilled in the art before the effective filing date of the claimed invention to modify the method of Jeyakumar with the teaching of Acton for receiving, by the one or more servers, the selection of the one or more messages from an administrator via a user interface. One of ordinary skilled in the art would have been motivated because it offers the advantage of allowing administrators to select desired messages to target specific threat.
Claim 16 does not teach or further define over the limitations in claim 4. As such, claim 16 is rejected for the same reasons as set forth in claim 4.
Claims 8 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Jeyakumar et al. (US 2020/0389486, published Dec. 10, 2020) and Thomas et al. (US 2016/0191465, published Jun. 30, 2016).
As per claim 8, Jeyakumar discloses the method of claim 1, but does not explicitly disclose further comprising determining, by the one or more servers, a recommendation of a Time-To-Live (TTL) for each of the one or more BLEs.
Thomas teaches:
determining a recommendation of a Time-To-Live (TTL) for each of the one or more BLEs (Thomas par. 250, The threat management facility 1002 may provide a reputation score 1024 and a time to live 1026 for a particular IOC 1006).
It would have been obvious to one skilled in the art before the effective filing date of the claimed invention to modify the method of Jeyakumar with the teaching of Thomas for determining, by the one or more servers, a recommendation of a Time-To-Live (TTL) for each of the one or more BLEs. One of ordinary skilled in the art would have been motivated because it offers the advantage of ensuring that information that will remain relevant over time.
Claim 20 does not teach or further define over the limitations in claim 8. As such, claim 20 is rejected for the same reasons as set forth in claim 8.
Claims 10 and 22 are rejected under 35 U.S.C. 103 as being unpatentable over Jeyakumar et al. (US 2020/0389486, published Dec. 10, 2020) and Sanjeev et al. (US 2015/0074802, published Mar. 12, 2015).
As per claim 10, Jeyakumar discloses the method of claim 1, further comprising private blocklists of multiple organizations (Jeyakumar par. 157, Embodiments of the threat detection platform may also be designed to permit enabling/disabling of IOCs on a per-enterprise basis. For example, an enterprise may upload a list of IOCs to the threat detection platform that should be used specifically when examining their emails).
Jeyakumar does not explicitly disclose:
receiving, by the one or more processors, a global blocklist of one or more BLEs identified by a security services provider that aggregates private blocklists.
Sanjeev teaches:
receiving, by the one or more processors, a global blocklist of one or more BLEs identified by a security services provider that aggregates private blocklists (Sanjeev par. 70, messaging center device 230 may receive blacklist information from a set of user devices 210 (e.g., first blacklist information from a first user device 210-1, second blacklist information from a second user device 210-2, etc.), and may aggregate the blacklist information. In some implementations, messaging center device 210 may analyze the aggregated blacklist information to determine global blacklist information for user devices 210 (e.g., all or a subset of user devices 210 associated with messaging center device 230)).
It would have been obvious to one skilled in the art before the effective filing date of the claimed invention to modify the method of Jeyakumar with the teaching of Sanjeev for receiving, by the one or more processors, a global blacklist of one or more BLEs identified by a security services provider that aggregates private blacklists of multiple organizations. One of ordinary skilled in the art would have been motivated because it offers the advantage of enhancing detection accuracy, speed, and coverage.
Claim 22 does not teach or further define over the limitations in claim 10. As such, claim 22 is rejected for the same reasons as set forth in claim 10.
Claims 11 and 23 are rejected under 35 U.S.C. 103 as being unpatentable over Jeyakumar et al. (US 2020/0389486, published Dec. 10, 2020) and Baptist et al. (US 2017/0031760, published Feb. 2, 2017).
As per claim 11, Jeyakumar discloses the method of claim 1, but does not explicitly disclose further comprising providing, by the one or more processors, a priority indicator to each of the one or more BLEs, the priority indicator indicating an order for which each of the one or more BLEs are to be added to the blocklist used by the email system.
Baptist teaches:
providing, by the one or more processors, a priority indicator to each of the one or more integrity check algorithms, the priority indicator indicating an order for which each of the one or more integrity check algorithms are executed (Baptist par. 36, generate a plurality of priority levels corresponding to each of the plurality of integrity check algorithms, where the plurality of integrity check algorithms are executed in an order based on the plurality of priority levels).
It would have been obvious to one skilled in the art before the effective filing date of the claimed invention to modify the method of Jeyakumar with the teaching of Baptist to incorporate priority levels for providing, by the one or more processors, a priority indicator to each of the one or more BLEs, the priority indicator indicating an order for which each of the one or more BLEs are to be added to the blocklist used by the email system. One of ordinary skilled in the art would have been motivated because it offers the advantage of prioritizing those IOCs representing the largest threat.
Claim 23 does not teach or further define over the limitations in claim 11. As such, claim 23 is rejected for the same reasons as set forth in claim 11.
Allowable Subject Matter
Claims 12 and 24 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten to include all of the limitations of the base claim and any intervening claims because none of the prior art of record either taken by itself or in any combination teaches all limitations as currently presented in the claims.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 20200186499 A1; Dynamic Filter Generation And Distribution Within Computer Networks
The present disclosure relates to implementing filters within a network environment and, in particular, to systems and methods for generating and distributing filters to devices within the network environment.
US 20230006971 A1; Anti-Piracy Control Based On Blacklisting Function
Various embodiments of the disclosure relate to an electronic device and method for control of execution of a third-party application for anti-piracy control based on a blacklisting function.
US 9241009 B1; Malicious Message Detection And Processing
The present technology relates generally to detecting and processing malicious messages, and more specifically, but not by way of limitation, to systems and methods for detecting and processing malicious and potentially malicious email messages, which protect email message recipients from exposure to spam, phishing, bulk, adult, and other similar types of deleterious and undesirable email messages and exposure to malicious and potentially malicious resources included in such emails.
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KHANG DO whose telephone number is (571)270-7837. The examiner can normally be reached Monday-Friday 8:00 - 5:00 EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, RUPAL DHARIA can be reached at (571) 272-3880. 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.
/KHANG DO/Primary Examiner, Art Unit 2492
Prosecution Insights