Prosecution Insights
Last updated: May 29, 2026
Application No. 18/207,058

ANALYSES AND AGGREGATION OF DOMAIN BEHAVIOR FOR EMAIL THREAT DETECTION BY A CYBER SECURITY SYSTEM

Non-Final OA §103§112
Filed
Jun 07, 2023
Priority
Jun 09, 2022 — provisional 63/350,781 +1 more
Examiner
CELANI, NICHOLAS P
Art Unit
2449
Tech Center
2400 — Computer Networks
Assignee
Darktrace Holdings Limited
OA Round
3 (Non-Final)
46%
Grant Probability
Moderate
3-4
OA Rounds
2m
Est. Remaining
89%
With Interview

Examiner Intelligence

Grants 46% of resolved cases
46%
Career Allowance Rate
210 granted / 457 resolved
-12.0% vs TC avg
Strong +43% interview lift
Without
With
+42.6%
Interview Lift
resolved cases with interview
Typical timeline
3y 2m
Avg Prosecution
27 currently pending
Career history
496
Total Applications
across all art units

Statute-Specific Performance

§101
3.0%
-37.0% vs TC avg
§103
88.8%
+48.8% vs TC avg
§102
1.0%
-39.0% vs TC avg
§112
5.7%
-34.3% vs TC avg
Black line = Tech Center average estimate • Based on career data from 457 resolved cases

Office Action

§103 §112
DETAILED ACTION The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . Status of Claims The following claim(s) is/are pending in this office action: 1-19 The following claim(s) is/are amended: 1, 9, 16 The following claim(s) is/are cancelled: - The following claim(s) is/are new: - Claim(s) 1-19 is/are rejected. Response to Arguments Applicant’s arguments filed in the amendment filed 2/6/2026, have been fully considered but are moot in view of new grounds of rejection. The reasons set forth below. Applicant’s Invention as Claimed Claim Rejections - 35 USC § 112 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. Claim(s) 1-19 is/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 pre-AIA the applicant regards as the invention. Claim 1 is representative and claims “in response to the email module detecting the email is directed a source email address falsely identifying the domain as part of the source email address.” The limitation makes no sense. Examiner construes the language based on the included Remarks (see Remarks, 2/6/2026) as calling back to the functionality of the email module. Claim limitation “email module,” “autonomous response module,” and “inoculation module” invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. Claims 1 and 9 claim modules configured to perform functions and therefore invoke means plus without the specification disclosing an algorithm of sufficient specificity for performing the function. Therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph. Applicant may: (a) Amend the claim so that the claim limitation will no longer be interpreted as a limitation under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph; (b) Amend the written description of the specification such that it expressly recites what structure, material, or acts perform the entire claimed function, without introducing any new matter (35 U.S.C. 132(a)); or (c) Amend the written description of the specification such that it clearly links the structure, material, or acts disclosed therein to the function recited in the claim, without introducing any new matter (35 U.S.C. 132(a)). If applicant is of the opinion that the written description of the specification already implicitly or inherently discloses the corresponding structure, material, or acts and clearly links them to the function so that one of ordinary skill in the art would recognize what structure, material, or acts perform the claimed function, applicant should clarify the record by either: (a) Amending the written description of the specification such that it expressly recites the corresponding structure, material, or acts for performing the claimed function and clearly links or associates the structure, material, or acts to the claimed function, without introducing any new matter (35 U.S.C. 132(a)); or (b) Stating on the record what the corresponding structure, material, or acts, which are implicitly or inherently set forth in the written description of the specification, perform the claimed function. For more information, see 37 CFR 1.75(d) and MPEP §§ 608.01(o) and 2181. The above cited rejections are merely exemplary. The Applicant(s) are respectfully requested to correct all similar errors. Claims not specifically mentioned are rejected by virtue of their dependency. Claim Rejections - 35 USC § 103 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 1-19 are rejected under 35 U.S.C. 103 as being unpatentable over Dreller (US Pub. 2014/0082726) in view of Gilliam (US Pat. 11,277,375) and further in view of Adams (US Pub. 2018/0007064). With respect to Claim 1, Dreller teaches a cyber security appliance to protect a domain associated with an organization or user, comprising: (Fig. 1, paras. 5, 29-32; system classifies incoming mail and uses a phishing/spoofing detection engine to determine if an email is malicious.) One or more processors; and a non-transitory storage medium accessible by the one or more processors, the non-transitory storage medium comprises (para. 26; processor and hard disk.) an email module communicatively coupled to the communication module, the email module comprises email report analysis logic configured to analyze content within an email authentication report received via the one or more input/output (I/O) ports to detect an email suspected of being malicious (I/O ports will be taught later. para. 29-31; classification server parses parts of messages such as FROM DOMAIN and SENDING IP ADDRESS to classify messages as possibly being suspicious or having authentication problems. para. 32-35; phish detection engine receives the data from the classifier and other data to analyze messages from domains not owned by a customer. The engine provides results to alerting and reporting servers to notify of possible security events. Fig. 3, paras. 40-49; Classifier runs multiple checks including DMARC analysis.) when the email is directed to a computing device operating outside of the domain and a source email address of the email falsely identifying the domain as part of the source email address; (para. 32; analysis of message from domains not owned by a customer. Paras. 8-9; DMARC is used to authenticate that a message is from a particular domain it claims to be from. Para. 50; system considers both domain and non-domain phishing. Paras. 51-52; system searches for messages from outside corporation that may use corporate lookalike messages.) But Dreller does not explicitly teach a communication module including one or more input/output (I/O) ports. Gilliam, however, teaches a communication module including one or more input/output (I/O) ports, (Fig. 4, col. 4, ln. 62 to col. 5, ln. 13 and col. 6, lns. 4-20; network interface to allow computer to communicate with other devices such as a wireless data port. See also Dreller, Fig. 1, para. 26; devices communicating in a networked system, which suggests a communication module with input/output. Para. 36; data source inputs.) an autonomous response module communicatively coupled to the email module, the autonomous response module is configured, in response to the email module detecting the email is directed a source email address falsely identifying the domain as part of the source email address to cause a first set of autonomous actions to mitigate one or more emails directed to the computing device or falsely identifying the domain from dissemination over a network; and (col. 2, lns. 32-54 and col. 3, ln. 58 to col. 4, ln. 5; system uses GUI to present report on SPF validity to admin that includes reasons why domains are invalid and allow actions that facilitate contacting owners of invalid domains. See also Dreller, para. 26; method is performed automatically in real time without delay. para. 54; system sends out alerts and reports to clients, ISPs, mailbox providers and security take down vendors. Figs. 4, 6, paras. 56-60, 63-64, 67; system provides information to help identify which servers or IPs are failing SPF and DKIM authentication and identify malicious messages including how other systems handled the message and providing the ability to take action.) It would have been obvious to one of ordinary skill prior to the effective filing date to combine the appliance of Dreller with the I/O ports of Gilliam in order to communicate over a network and to allow for facilitating contact of owners or updating of SPF records. But modified Dreller does not explicitly teach an inoculation module configured to perform a DOS. Adams, however, does teach an inoculation module communicatively coupled to the email module, the inoculation module is configured, in response to the email module detecting the email is directed a source email address falsely identifying the domain as part of the source email address to further cause a second set of autonomous actions, wherein the second set of autonomous actions includes one or more offensive actions including issuance of a Denial of Service (DOS) attack on a malicious server from which the email originated in response to the email module identifying the malicious server sending the email falsely identifying the domain. (para. 106; security server identifies a malicious server and initiates a DOS attack on it to cause it to crash.) It would have been obvious to one of ordinary skill prior to the effective filing date to combine the appliance of modified Dreller with the DOS attack in order to protect the system by crashing the malicious device. With respect to Claim 2, modified Dreller teaches the cyber security appliance of claim 1, and Gilliam also teaches wherein the email module further comprises email authentication set-up logic configured to notify and assist domain administrators in response to the email report analysis logic identifying potential Domain Name System (DNS) sever misconfiguration based on the content of the email authentication report. (col. 2, lns. 32-54 and col. 3, ln. 58 to col. 4, ln. 5; system uses GUI to present report on SPF validity to admin that includes reasons why domains are invalid and allow actions that facilitate contacting owners of invalid domains or performing SPF updating. See also Dreller, para. 36; report output for an authentication problem contains DKIM and SPF results that a customer will find useful to understand authentication problems on their mail servers. Fig. 6, paras. 64, 67; system provides information to help identify which servers or IPs are failing SPF and DKIM authentication including rDNS hostname.) The same motivation to combine as the independent claim applies here. With respect to Claim 3, modified Dreller teaches the cyber security appliance of claim 2, and Dreller also teaches wherein the email authentication report corresponds to a Domain-based Message Authentication, Reporting and Conformance (DMARC) aggregate report includes content associated with emails that utilize the domain as part of its source address. (paras. 8-9; DMARC aggregate report) With respect to Claim 4, modified Dreller teaches the cyber security appliance of claim 3, and Dreller also teaches wherein the DMARC aggregate report includes content that identifies an email failing at least one of a plurality of authentications to categorize the email as malicious, the plurality of authentications include a Sender Policy Framework (SPF) authentication that confirms that the email is being sent from a mail server authorized to send emails on behalf of the domain and a DomainKeys Identified Mail (DKIM) authentication that confirms that the content of the email has not been modified during transit.( paras. 8, 30, 41; SPF and DKIM results. paras. 29-31, 36; messages marked as suspicious. para. 41; DKIM and SPF results. Para. 48; Forwarder check by sending DKIM result to DMARC aggregate data. Paras. 8-9; DMARC combines DKIM and SPF check with an identifier alignment check. Paras. 45-46; authentication check that includes FROM, MFROM and DKIM alignment. Para. 9; SPF deals with authorization use of domains in email.) With respect to Claim 5, modified Dreller teaches the cyber security appliance of claim 4, and Dreller also teaches wherein the plurality of authentications include DMARC authentication that detects whether a misalignment between an actual email address of an email sender and the source email address included within a From header field of the email identifying the domain as part of the source email address. (Paras. 8-9; DMARC combines DKIM and SPF check with an identifier alignment check. Para. 46; FROM, MFROM and DKIM domains are compared to check alignment.) With respect to Claim 6, modified Dreller teaches the cyber security appliance of claim 4, and Gilliam also teaches wherein the autonomous response module configured to provide data to be rendered on a display to assist a domain administrator in configuring a DMARC record that adjusts the DMARC authentication or a SPF record that adjusts the SPF authentication. (col. 2, lns. 32-54 and col. 3, ln. 58 to col. 4, ln. 5; system uses GUI to present report on SPF validity to admin that includes reasons why domains are invalid and allow actions that facilitate contacting owners of invalid domains or performing SPF updating. See also Dreller, para. 54; system sends out alerts and reports to clients, ISPs, mailbox providers and security take down vendors. Figs. 4, 6, paras. 56-60, 63-64, 67; system provides information to help identify which servers or IPs are failing SPF and DKIM authentication and identify malicious messages including how other systems handled the message and providing the ability to take action.) The same motivation to combine as the independent claim applies here. With respect to Claim 7, modified Dreller teaches the cyber security appliance of claim 1, and Dreller also teaches wherein the inoculation is further configured to the second set of autonomous actions including one or more defensive actions including issuance of an alert. (para. 54; system sends out alerts and reports to clients, ISPs, mailbox providers and security take down vendors. Figs. 4, 6, paras. 56-60, 63-64, 67; system provides information to help identify which servers or IPs are failing SPF and DKIM authentication and identify malicious messages including how other systems handled the message and providing the ability to take action.) With respect to Claim 8, modified Dreller teaches the cyber security appliance of claim 1, and Dreller also teaches communicatively coupled to a global domain intelligence data store to provide results of the analysis of the content within the email authentication report along with the content of the email authentication report to assist in reconfiguration of a plurality of email authentications conducted during transmission of the email and global tracking of behavior of a source of the suspected malicious email. (Examiner asserts the language after “to assist in” is not entitled to patentable weight. Regardless, Examiner cites Dreller to teach. para. 13, 41, 51, 85; message attributes including body content are stored and used in reports. Para. 54; reports to third parties such as ISPs. Para. 34; alerting and reporting happens in real-time.) With respect to Claim 9, Dreller teaches implemented within a cyber security appliance, a non-transitory storage medium configured to store instructions in a format that, when executed by a processor, (para. 26; processor and hard disk.) identifies malicious spoofing and phishing emails to protect a domain associated with an organization or user, the non-transitory storage medium comprising: (Fig. 1, paras. 5, 29-32; system classifies incoming mail and uses a phishing/spoofing detection engine to determine if an email is malicious.) an email module including email report analysis logic is configured to, when executed by the processor, analyze content within an email authentication report (para. 29-31; classification server parses parts of messages such as FROM DOMAIN and SENDING IP ADDRESS to classify messages as possibly being suspicious or having authentication problems. para. 32-35; phish detection engine receives the data from the classifier and other data to analyze messages from domains not owned by a customer. The engine provides results to alerting and reporting servers to notify of possible security events. Fig. 3, paras. 40-49; Classifier runs multiple checks including DMARC analysis.) received from an Internet Service Provider (ISP) (para. 32; analysis of message from domains not owned by a customer. Paras. 8-9; DMARC is used to authenticate that a message is from a particular domain it claims to be from. Para. 50; system considers both domain and non-domain phishing. Paras. 51-52; system searches for messages from outside corporation that may use corporate lookalike messages. Para. 30, 60, 69; data is from ISPs. To the extent that some functionality is performed by the classifier server it would have been obvious to one of ordinary skill prior to the effective filing date to move the reporting functionality of the classifier server to the ISP because it is a simple substitution for predictable results in that the ownership of the server does not affect its functionality.) to detect an email suspected of being malicious upon failure of an authentication process that detects when the email is directed to a computing device operating outside of the domain and a source address of the email falsely identifies the domain as part of the source email address; (para. 32; analysis of message from domains not owned by a customer. Paras. 8-9; DMARC is used to authenticate that a message is from a particular domain it claims to be from. Para. 50; system considers both domain and non-domain phishing. Paras. 51-52; system searches for messages from outside corporation that may use corporate lookalike messages.) But Dreller does not explicitly teach an autonomous response module communicatively coupled to the email module, the autonomous response module is configured to, when executed by the processor, cause a first set of autonomous actions to mitigate one or more emails directed to the computing device or falsely identifying the domain from dissemination over a network. Gilliam, however, does teach and an autonomous response module communicatively coupled to the email module, the autonomous response module is configured to, when executed by the processor, cause a first set of autonomous actions to mitigate one or more emails directed to the computing device or falsely identifying the domain from dissemination over a network; and (col. 2, lns. 32-54 and col. 3, ln. 58 to col. 4, ln. 5; system uses GUI to present report on SPF validity to admin that includes reasons why domains are invalid and allow actions that facilitate contacting owners of invalid domains. See also Dreller, para. 26; method is performed automatically in real time without delay. para. 54; system sends out alerts and reports to clients, ISPs, mailbox providers and security take down vendors. Figs. 4, 6, paras. 56-60, 63-64, 67; system provides information to help identify which servers or IPs are failing SPF and DKIM authentication and identify malicious messages including how other systems handled the message and providing the ability to take action.) It would have been obvious to one of ordinary skill prior to the effective filing date to combine the appliance of Dreller with the autonomous response module of Gilliam in order to contact owners of invalid domains to provide a fast and accurate method of determining validity. (Gilliam, col. 2, lns. 32-54) But modified Dreller does not explicitly teach an inoculation module configured to perform a DOS. Adams, however, does teach an inoculation module communicatively coupled to the email module, the inoculation module is configured to, when executed by the processor and in response to the email module detecting the email is directed a source email address falsely identifying the domain as part of the source email address cause a second set of autonomous actions, wherein the second set of autonomous actions includes one or more offensive actions including issuance of a Denial of Service (DOS) attack on a malicious server from which the email originated. (para. 106; security server identifies a malicious server and initiates a DOS attack on it to cause it to crash.) It would have been obvious to one of ordinary skill prior to the effective filing date to combine the appliance of modified Dreller with the DOS attack in order to protect the system by crashing the malicious device. With respect to Claims 10-15, they are substantially similar to Claims 2-7, respectively, and are rejected in the same manner, the same art and reasoning applying. With respect to Claim 16, Dreller teaches a method for a cyber security appliance to protect a domain associated with an organization or user, comprising: (Fig. 1, paras. 5, 29-32; system classifies incoming mail and uses a phishing/spoofing detection engine to determine if an email is malicious.) analyzing content within an email authentication report received from a resource external to the domain (para. 29-31; classification server parses parts of messages such as FROM DOMAIN and SENDING IP ADDRESS to classify messages as possibly being suspicious or having authentication problems. para. 32-35; phish detection engine receives the data from the classifier and other data to analyze messages from domains not owned by a customer. The engine provides results to alerting and reporting servers to notify of possible security events. Fig. 3, paras. 40-49; Classifier runs multiple checks including DMARC analysis.) to determine whether an email, observed as using the domain as part of its source email address, has failed at least one of a plurality of email authentication processes, (para. 32; analysis of message from domains not owned by a customer. Paras. 8-9; DMARC is used to authenticate that a message is from a particular domain it claims to be from. Para. 50; system considers both domain and non-domain phishing. Paras. 51-52; system searches for messages from outside corporation that may use corporate lookalike messages.) wherein the plurality of email authentication processes include (i) a first authentication process configured to confirm that the email is being sent from a mail server authorized to send emails on behalf of the domain, (paras. 8, 30, 41; SPF result. Applicant also admits this functionality preexisted, see Spec, Background, para. 5; SPF) (ii) a second authentication process configured to confirm that the content of the email has not been modified during transit, (paras. 8, 30, 41; DKIM result. Applicant also admits this functionality preexisted, see Spec, Background, para. 7; DKIM) and (iii) a third authentication process configured to detect misalignment between an actual email address of an email sender and the source email address included within a From header field of the email identifying the domain as part of the source email address; (para. 8; DMARC checks for alignment between FROM header, mail from, and the DKIM domain. Paras. 29-31; DMARC forensic and aggregate data) determining whether the email corresponds to a suspected malicious email upon the email failing at least one of the plurality of email authentication processes; (para. 29-31; classification server parses parts of messages such as FROM DOMAIN and SENDING IP ADDRESS to classify messages as possibly being suspicious or having authentication problems. para. 32-35; phish detection engine receives the data from the classifier and other data to analyze messages from domains not owned by a customer. The engine provides results to alerting and reporting servers to notify of possible security events. Fig. 3, paras. 40-49; Classifier runs multiple checks including DMARC analysis.) But Dreller does not explicitly teach and performing a first set of autonomous actions to mitigate continued dissemination of emails over a network by a malicious actor originating the suspected malicious email. Gilliam, however, does teach and performing a first set of autonomous actions to mitigate continued dissemination of emails over a network by a malicious actor originating the suspected malicious email. (col. 2, lns. 32-54 and col. 3, ln. 58 to col. 4, ln. 5; system uses GUI to present report on SPF validity to admin that includes reasons why domains are invalid and allow actions that facilitate contacting owners of invalid domains. See also Dreller, para. 26; method is performed automatically in real time without delay. para. 54; system sends out alerts and reports to clients, ISPs, mailbox providers and security take down vendors. Figs. 4, 6, paras. 56-60, 63-64, 67; system provides information to help identify which servers or IPs are failing SPF and DKIM authentication and identify malicious messages including how other systems handled the message and providing the ability to take action.) It would have been obvious to one of ordinary skill prior to the effective filing date to combine the method of Dreller with the actions of Gilliam in order to improve security by validating emails and responding to threats. But modified Dreller does not explicitly teach performing a DOS. Adams, however, does teach performing a second set of autonomous actions to further mitigate continued dissemination over the network in response to detecting the email is directed a source email address falsely identifying the domain as part of the source email address, wherein the second set of autonomous actions includes one or more offensive actions including issuance of a Denial of Service (DOS) attack on a malicious server from which the email originated. (para. 106; security server identifies a malicious server and initiates a DOS attack on it to cause it to crash.) It would have been obvious to one of ordinary skill prior to the effective filing date to combine the method of modified Dreller with the DOS attack in order to protect the system by crashing the malicious device. With respect to Claim 17, modified Dreller teaches the method of claim 16, and Dreller also teaches wherein the first set of autonomous actions include (i) one or more defensive actions including issuance of an alert across to multiple cyber security appliances across multiple domains including the domain or (ii) one or more offensive actions including issuance of a Denial of Service (DoS) attack on a malicious server from which the suspected malicious email originated. (para. 54; system sends out alerts and reports to clients, ISPs, mailbox providers and security take down vendors. Figs. 4, 6, paras. 56-60, 63-64, 67; system provides information to help identify which servers or IPs are failing SPF and DKIM authentication and identify malicious messages including how other systems handled the message and providing the ability to take action.) With respect to Claim 18, modified Dreller teaches the method of claim 16, and Dreller also teaches wherein the first email authentication process corresponds to a Sender Policy Framework (SPF) authentication that confirms that the email is being sent from a mail server authorized to send emails on behalf of the domain, (paras. 8, 30, 41; SPF result. Applicant also admits this functionality preexisted, see Spec, Background, para. 5; SPF) the second email authentication process corresponds to a DomainKeys Identified Mail (DKIM) authentication that confirms that the content of the email have not been modified during transit, (paras. 8, 30, 41; DKIM result. Applicant also admits this functionality preexisted, see Spec, Background, para. 7; DKIM) and the third email authentication process corresponds to a DMARC authentication that detects whether a misalignment between an actual email address of an email sender and the source email address included within a From header field of the email identifying the domain as part of the source email address. (para. 8; DMARC checks for alignment between FROM header, mail from, and the DKIM domain. Paras. 29-31; DMARC forensic and aggregate data) With respect to Claim 19, modified Dreller teaches the method of claim 16, and Gilliam also teaches further comprising: provide results of an analysis of the content within the email authentication report along with the content of the email authentication report to a global domain intelligence data store to (i) provide real-time access of the results and the content to an administrator to assist in reconfiguration of one or more of the plurality of email authentication processes and (ii) enable global tracking of behavior of the email sender of the suspected malicious email. (Examiner asserts that anything beyond providing the results to a global data store is not entitled to patentable weight. Regardless, Examiner cites Gilliam, col. 2, lns. 32-54 and col. 3, ln. 58 to col. 4, ln. 5; system uses GUI to present report on SPF validity to admin that includes reasons why domains are invalid and allow actions that facilitate contacting owners of invalid domains. See also Dreller, para. 26; method is performed automatically in real time without delay. para. 54; system sends out alerts and reports to clients, ISPs, mailbox providers and security take down vendors. Figs. 4, 6, paras. 56-60, 63-64, 67; system provides information to help identify which servers or IPs are failing SPF and DKIM authentication and identify malicious messages including how other systems handled the message and providing the ability to take action. Para. 34; alerting and reporting happens in real-time.) The same motivation to combine as the independent claim applies here. Remarks Applicant argues at Remarks, pgs. 8-9 that the claim terms of “email module” “autonomous response module” and “inoculation module” do not invoke 112f because “a POSITA in the field of cybersecurity…would understand [them] to be specific software within a networked security architecture, not generic black box placeholders.” Examiner disagrees. The claims use a stand in for means – “module[s] configured to.” See MPEP 2181(I)(A), listing “module for” as invoking 112f and 2181(I)(B) listing “configured to” as a known linking word. Those terms are then followed by a description of a functional result: analyzing content to detect malicious emails, mitigation of dissemination of those emails and launching a DoS attack on the origination server of the emails. That is a recitation of function without specific structure for achieving the function, see MPEP 2181(I)(C). Applicant’s argument that a POSITA would know the modules to be “specific software” lacks an evidentiary basis for the claim and is expressly disputed in the following section. Contrary to the argument that a person of skill would know these references to be made to specific known structure, Applicant argues in the 103 section that the modules are novel to the art. Nor is the argument that other terms do not invoke 112f availing. Examiner agrees a computer program does not invoke 112f, but the claim does not claim a computer program. It claims a module that performs functions. Examiner appreciates that Applicant could be referring to computer programs that perform functions, but a module and a program are not the same thing and they do not have the same meaning either legally or within the usage of the field. The claim language meets the three limitations of MPEP 2181(I). Applicant provides no evidence, and Examiner does not believe it to be the case, that “module” connotes a specific algorithmic structure. MPEP 2181(II)(B) specifically points out the Williamson court found “distributed learning control module” to invoke means-plus, which suggests that module does not present structure and “email module” “autonomous response module” and “inoculation module” are not unique terms of art. They stand in the same position as the “distributed learning control module” as Williamson. Examiner maintains the rejection. Applicant argues at Remarks, pgs. 10-11 that the claims are nonobvious. Applicant amends the autonomous response module and the inoculation module of Claim 1 to function “in response to” the email module. Applicant then argues that because the secondary references (which are cited for the response and inoculation modules) do not perform their actions because of an email module, they fail to anticipate the element. Specifically, Applicant points to Adams, para. 106, and notes that the denial of service attack that is made in Adams is performed pursuant to a stored list of addresses associated with malicious servers, and not an email module detecting an email with a false identification. The claim is obvious over the combination of teachings. Applicant’s argument lies on the faulty premise that Applicant may show nonobviousness by considering only one reference individually as to whether it anticipates an element on its own. The correct analysis is to ask if the claim as a whole would have been obvious to one of ordinary skill based on all the knowledge cited from all the references. In response to applicant’s arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986). Specifically, Applicant does not dispute that Dreller discloses the email module functionality, nor does Applicant dispute that Adams discloses the inoculation module functionality. Nor, critically, does Applicant provide a reason that a person of skill who was made aware that one could crash malicious devices using a DoS attack (as in Adams) would not find it obvious to initiate a DoS attack against a server that originated an email falsely identifying itself as in Dressler. In short, Applicant confuses Adams not anticipating the entirety of the claim (a true but irrelevant fact in an obviousness rejection) with Adams in view of Dressler not rendering the claimed inoculation module obvious. Applicant further argues that “the claimed invention allows for real-time detection of new attacks, while Adams describes a blacklist from which identified servers can be counter-attacked.” But Claim 1 has no temporal limitation on the inoculation module’s actions and even if it did Applicant is again piecemealing the rejection. Examiner has already cited that Dressler functions in real-time. In other words, even if “real-time detection” were a limitation of the claims, the combination of references already teaches real-time detection because the detection element (the email module) is taught by a real-time reference. Adams stands only for the proposition that the art knew that one could, and was motivated to, crash a malicious server by initiating a DoS attack against it. Applicant does not dispute Adams provides that teaching. Examiner maintains the obviousness rejection. All claims remain rejected. Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to NICHOLAS P CELANI whose telephone number is (571)272-1205. The examiner can normally be reached on M-F 9-5. 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, Vivek Srivastava can be reached on 571-272-7304. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300. Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. /NICHOLAS P CELANI/Examiner, Art Unit 2449
Read full office action

Prosecution Timeline

Jun 07, 2023
Application Filed
Jun 16, 2025
Non-Final Rejection mailed — §103, §112
Sep 08, 2025
Response Filed
Oct 08, 2025
Final Rejection mailed — §103, §112
Feb 06, 2026
Request for Continued Examination
Feb 21, 2026
Response after Non-Final Action
Apr 01, 2026
Non-Final Rejection mailed — §103, §112 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12634201
Detecting site locations of unknown network devices
4y 10m to grant Granted May 19, 2026
Patent 12625938
ELECTRONIC DEVICE FOR PERFORMING USER AUTHENTICATION BY USING USER BIOMETRIC INFORMATION, AND OPERATION METHOD THEREOF
4y 6m to grant Granted May 12, 2026
Patent 12592949
METHODS AND SYSTEMS FOR CATEGORIZING CYBER INCIDENT LOGS FEATURING DYNAMIC RELATIONSHIPS TO PRE-EXISTING CYBER INCIDENT REPORTS IN REAL-TIME
2y 5m to grant Granted Mar 31, 2026
Patent 12580823
ON-PREMISE MACHINE LEARNING MODEL SELECTION IN A NETWORK ASSURANCE SERVICE
7y 9m to grant Granted Mar 17, 2026
Patent 12574424
Systems and methods for video-conference network system suitable for scalable, automatable, inter-social domain, private tele-consultation service
6y 6m to grant Granted Mar 10, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

3-4
Expected OA Rounds
46%
Grant Probability
89%
With Interview (+42.6%)
3y 2m (~2m remaining)
Median Time to Grant
High
PTA Risk
Based on 457 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month