DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on February 4, 2025 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Specification
For clarity and consistency of the record, references within the specification shall be made to its Pre-Grant Publication, US 20250260720.
The disclosure is objected to because it contains an embedded hyperlink and/or other form of browser-executable code at [0070]: “…or maximum effectiveness from user behavior point of view considering in accordance with Usability Principles of Communications that require proximity of warning based on Gestalt principles, which can be understood from information website https://digital.gov/communities/user-experience/#related-resources-2[.] Also, definitions for usability can be further understood in accordance with information provided at https://www.iso.org/obp/ui/#iso:std:iso:9241:-11:ed-2:v1:en”. Applicant is required to delete the embedded hyperlink and/or other form of browser-executable code; references to websites should be limited to the top-level domain name without any prefix such as http://, https://, or other browser-executable code (e.g., “huggingface.co” or “github.com” in [0125]). See MPEP §608.01.
Appropriate correction is required.
Claim Objections
Claims 1-20 are objected to due to the following grammatical informalities:
Claims 1, 8 and 15:
The first instance of “sender ID” should be defined as “sender identity (ID)”;
The first instance of “IP address” should be defined as “Internet Protocol (IP) address”;
The first instance of “LLM” should be defined as “large language model”.
“the sender associated with rogue domain” should be “the sender associated with a rogue domain”;
“does not have suspected domain name” should be “does not have a suspicious domain name”;
“checksum hit technique” should be “a checksum hit technique”
“wherein the plurality of parameters comprising geocoding, device type…” should be “wherein the plurality of parameters comprises: geocoding, device type…”
“a warning indicating IP address is mobile” should be “a warning indicating an IP address is mobile”
“wherein phishing warnings in form of text message are displayed with change the font type face” should be “wherein phishing warnings in form of text messages are displayed “with changes to the font type face”
Claim 2, 9 and 16: “each cluster is associated with word-word phrase” should be “each cluster is associated with a word-word phrase”
Claims 4, 12 and 18: There is no definition for the acronym “API”. For purposes of examination of the instant application, “API” shall be construed to mean “Application Programming Interface”.
Claims 5, 11 and 19: “using voice to text technique” should be “using a voice to text technique”
Claims 6, 13 and 20:
“valid non- existent or impersonate domain names” should be “valid non- existent or impersonated domain names”
“each of the valid domain name” should be “each of the valid domain names” or “each valid domain name”
“presence of invalid domain” should be “presence of an invalid domain”
Claims 7 and 14: “and in presented in a local language registered by the receiver if the receiver is a Basic Emergent User (BEU)” should be “and
Appropriate correction is required.
Interpretation
The claim refers to a “Sender Profile Framework (SPF)”, defining an acronym contrary to its known meaning in the art. For purposes of examination of the instant application, "Sender Profile Framework" shall be interpreted as equivalent to "Sender Policy Framework".
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 claims contain 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.
These claims, along with claims 5, 11, and 19, recite a “checksum hit technique”. However, the specification does not detail what checksum is computed or what qualifies as a “hit”. Table 2 has a column labeled “hitCounter” but the specification gives no indication how the hits are counted; the values appear random to a person having ordinary skill in the art reading the specification. Therefore, the “checksum hit technique” lacks adequate written description.
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.
Claims 1, 8 and 15:
There is insufficient antecedent basis for “the sender ID tagged as SPF-fail…”. For purposes of examination of the instant application, the limitation shall be construed “the sender ID, when tagged as SPF-fail, indicates that a domain …”
“ if the domain IP address is detected …” : “the domain IP address” lacks antecedent basis and is interpreted as “a domain IP address”;
The term “accurate real-time positioning” is not defined by the claim, the specification does not provide a standard for ascertaining the requisite degree of “accuracy”, and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention. For purposes of examination of the instant application, the limitation shall be interpreted as reading “real-time positioning”.
The term “short” in “short reasons excluding technical jargons” is not defined by the claim, the specification does not provide a standard for ascertaining the requisite degree of “shortness”, and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention. For purposes of examination of the instant application, the limitation shall be interpreted as reading “reasons excluding technical jargon”.
There is insufficient antecedent basis for “the Document Object Module”. For purposes of examination of the instant application, the limitation shall be construed as “a Document Object Module …”.
There is insufficient antecedent basis for “the DOM nodes”. For purposes of examination of the instant application, the limitation shall be construed as “DOM nodes…”.
There is insufficient antecedent basis for “the font type face”. For purposes of examination of the instant application, the limitation shall be construed as “a font type face in which the message is displayed or a font type face used for the message…”.
Claim 2 is rejected as being indefinite because the term “word-word phrase” is unclear. For purposes of examination of the instant application, the limitation shall be construed as “an association of 2 or more words…”
It is unclear whether “the geo codes of the sender device” are the “geocoding” of claim 1. The “geo codes” and “the sender device” lack antecedent basis. For purposes of examination of the instant application, the limitation shall be construed as referring to said geocoding.
“the hits” in claim 1 and in claim 5 lacks antecedent basis;
Claim 6 is rejected for containing the following issues which render the claim indefinite:
There is insufficient antecedent basis for “each valid domain name” as recited in claim 6.
The claim recites “during a reasoning analysis of LLM”. It is unclear whether the LLM in question is the “first LLM” introduced in claim 1 or the “second LLM” introduced in claim 6. Claim 6 is rejected as indefinite. For purposes of examination of the instant application, the limitation shall be construed as “during a reasoning analysis of the first LLM or the second LLM”.
Claim 7 recites “…wherein positions for the phishing warning… are in accordance with Usability Principles of Communications that require proximity of warning based on Gestalt principles…”Claim 7 is rejected as indefinite. because the scope of the positions warnings … in accordance with Usability Principles of Communications that require proximity of warning based on Gestalt principles” is not understood.
Allowable Subject Matter
Claims 1-20 are found to contain allowable subject matter. The following is a statement of reasons for the indication of allowable subject matter:
The closest prior art of record is US 10284579 to Goutal as provided in the IDS submitted February 4, 2025 (hereinafter “Goutal”).
Regarding claim 1, Goutal discloses:
A processor implemented method for providing usable security, the method comprising:
initiating, for each message among a plurality of messages received (Goutal 4:25-27: “As shown at 210, the processing portion 204 may also be configured to classify received email, as described in detail herein.”) from one or more senders associated with sender IDs (Goutal 5:36-37: “…the sender of the email is extracted from the From header of the received email…”), a Sender Profile Framework (SPF) check (Goutal Fig. 3, B33), via a plugin usable security module (Goutal Fig. 1: ESPL 110, 114, 118) executed by one or more hardware processors of a message exchange and communication server (Goutal 3:35-37: “…according to one embodiment, as an email filtering service in the executing on remote servers (i.e., the cloud).”);
modifying, by the one or more hardware processors, the records with a set of custom headers comprising a plurality of parameters associated with a sender device profile, (Goutal: The headers are described throughout, including From (5:37-38), To (11:22), X-Mailer (5:57, Table 1), User-Agent (5:58), Content-Language (6:50), Reply-To (11:1), Return-Path (11:12), Subject (11:30). Headers are added at (6:60-61) containing source and destination IP addresses), wherein the plurality of parameters comprising geocoding (Goutal 6:61-7:1: “Received header will typically contain… the source IP address and destination IP address of the SMTP connection. ESPL may be configured to, according to one embodiment, extract the IP address that has initiated the sending of the email by parsing these Received headers. ESPL may be also configured to, according to one embodiment, associate a geolocation to the IP address by using a local geolocation database.”), device type (Goutal 6:1, Table 1: individual iOS and MacOS versions, e.g., “iPhone Mail (14C92)”), device type profile (Goutal 6:1, Table 1: Simplified Name, e.g., “iPhone”), and accurate real-time positioning and timing services (Goutal 6:61-63: “Received header will typically contain the time, the source IP address and destination IP address of the SMTP connection.”);
analyzing, by the one or more hardware processors, the one or more sender IDs [] in conjunction with one or more of the set of custom headers by performing one of:
(ii) stripping body of the message (Goutal 11:37: “…This value may be set to 1 if the email body is determined to contain language indicative of topics which are deemed to be of a suspicious nature.”), if the message does not belong to the mass mailer communication and does not have suspected domain name (Goutal Fig. 3: Passed B32 to arrive at B43).
Goutal also discloses performing such operations using machine learning by using a Support Vector Machine (SVM) (Goutal 9:31-34: “As alluded to above, one embodiment uses a supervised learning algorithm to make the classification decision. Popular supervised learning algorithms include Support Vector Machine (SVM) and Random Forest.”).
However, Goutal does not teach the remainder of the claim.
Other art hereby made of record also partially disclose the matter of the claim:
“Sender Policy Framework” on Wikipedia, as stored on the Internet Archive on Feb. 7 2023 (hereinafter “Wiki”) adds further detail on SPF as known in the art. Specifically, Wiki discloses that an SPF check is performed by checking records storing authorized domain names (Wiki p. 1: “The list of authorized sending hosts and IP addresses for a domain is published in the DNS records for that domain”), wherein the sender ID tagged as SPF-fail indicates that a domain name associated with the sender ID belongs to an unauthorized domain IP address (Wiki p. 1: “SPF allows the receiving mail server to check during mail delivery that a mail claiming to come from a specific domain is submitted by an IP address authorized by that domain's administrators.”) and that a SPF stores a legal record of a plurality of domains and associated domain owner and organization details (Wiki p. 1: “The list of authorized sending hosts and IP addresses for a domain is published in the DNS records for that domain.”).
In addition, “Countering Phishing Threats with Trust-by-Wire in Packet-switched IP Networks A Conceptual Framework” by Kubisch et al. (hereinafter “Kubisch”) describes one or more senders (Kubisch p. 4, Fig. 4: Alice and Eve) associated with sender ID (Kubisch p. 2, III. Common Anti-Phishing Mechanisms: “Various filtering mechanisms can be applied on any level to filter e-mails, IPs, or HTTP content.” Examiner notes in this context, “e-mails” is used to refer here to the e-mail addresses of senders i.e., filtering malicious e-mails or domains.) and geo-sensor (Kubisch p. 4, IPclip’s Position within the Network Infrastructure: “Thus, our approach is based on the assumption that LI [Location Information] can be added… by the CPEs [Customer Premises Equipment] (only GPS location information)…”) equipped sender devices (Kubisch p. 4, B. IPclip’s Position within the Network Infrastructure: CPEs) for protecting against phishing attacks (Kubisch p. 8, VI. Conclusions: “The paper discussed a conceptual framework to tighten measures against phishing frauds.”).
In addition, US 20100153511 by Lin (hereinafter “Lin”) describes generating a checksum to derive presence of the mass mailer communication using checksum hit technique, wherein if the hits are beyond a threshold count the sender is identified as potentially malicious (Lin [0026]: “…compare the checksums with stored checksums from previously sent alert messages 115 and received content files, and may determine based on the comparison whether the alert message 115 or content file is a duplicate.”).
In addition, US 20070033639 by Goodman (hereinafter “Goodman”) describes processing, by the one or more hardware processors, the message [] in conjunction with a phishy-domain-permutations database (Goodman [0031]: “The list of known phishing domains 222 includes a list of known bad URLs (e.g., URLs associated with phishing Web sites) and a list of suffixes of the known bad URLs.”), if the sender of the message is identified as potentially malicious (Goodman [0031]: “…known bad URLs (e.g., URLs associated with phishing Web sites) and a list of suffixes of the known bad URLs.”), wherein the processing comprises:
(i) analyzing the message body to provide reasons for sender indicated as malicious, wherein the reasons are in natural language and machine interpretable language (Goodman [0043]: “For example, a user can be warned with messages such as "Warning: this message is from Districbank-Security.com, which, to the best of our knowledge, is not affiliated with Districbank.com…"” Examiner notes that natural language, i.e. text, is machine-interpretable.).
In addition, US 11132495 to Doke et al. (hereinafter “Doke ‘495”) describes (ii) iteratively processing the reasons to generate short reasons excluding technical jargons to be embedded in the body of the message (Doke ‘495 5:18-21: “Natural language processing (NLP) is further applied on each message to condense text in the message such that maximum information is conveyed while displaying minimum words.”). Doke ‘495 also describes displaying a text message are displayed with change the font type face with kerning models as per a device form factor of a receiver device (Doke ‘495 9:44-50: “The typeface is determined based on user's reading capability, which is identified in accordance to readability test cases the user is requested to attempt. Determining the typeface utilizes applying kerning spacing adjustment and glyphs adjustment techniques to squeeze area of the displayed text still maintaining reduced ambiguity while reading of the text by the specific user type.”).
In addition, US 10620977 to Doke et al. (hereinafter “Doke ‘977”) describes using the sensor types and sensor type profiles as part of the “plurality of parameters” (Doke ‘977: 2:3-33: “…a set of sensors on the smartphone corresponding to the identified set of applications, and generates a threat model using the identified set of sensors and corresponding threats…”). Doke ‘977 also describes if the sender of the message is identified as potentially malicious, performing actions comprising [] (iii) generating an image using text-to-Image models (Doke ‘977 8:14-19: “Multi modal design module: It is a unique visual design of curated semiotics which is used to translate the threat model to audio/visual/haptic in alignment with the cognitive abilities of the basic user archetype. The text is displayed in local language and the audio interface could be via PIM2R protocol.”), wherein the image is indicative of potentially malicious mail and sentiment in the mail (Doke ‘977 6:13-16: “The multimodal design module 116 is configured to translate the threat model to one or more of an audio or visual haptic in alignment with the cognitive abilities of the basic user archetype”).
In addition, US 7461339 to Liao et al. (hereinafter “Liao”) describes modifying, by the one or more hardware processors, the Document Object Module (DOM) instance for the message to incorporate the processed results of the LLM (Liao 6:8-11: “The inserted script program can also modify the HTML content of the message or perform other useful events or methods provided by a browser DOM (Document Object Model).”) associated with phishing warnings (Liao 10:66-11:4: “In step 430 of FIG. 10, the process begins by replacing the message body 506 of e-mail message 502 with new plain text 557 that provides a warning that a phishing scam might be underway, or an explanation regarding any modifications to the e-mail message that have been performed. Plain text 557 can be customized by an IT administrator at any time.”), wherein the message is displayed to a receiver on a receiver device (Liao 1:6-7: “The present invention relates generally to screening of electronic information destined for an end user.”) with one or more phishing warnings (Liao 5:63-67: “Thus, the script program is able to modify the e-mail body, retrieve URL link information, perform rule-based intelligence, and provide warnings to the user when he or she is trying to link to a suspected phishing web site.”), wherein the phishing warnings are displayed at the DOM nodes based on positions indicated by the LLM (Liao 10:66-11:4: “In step 430 of FIG. 10, the process begins by replacing the message body 506 of e-mail message 502 with new plain text 557 that provides a warning that a phishing scam might be underway, or an explanation regarding any modifications to the e-mail message that have been performed. Plain text 557 can be customized by an IT administrator at any time.”).
Goutal, alone or in combination with any of the aforementioned prior arts, fails to fully disclose or suggest:
initiating, for each message among a plurality of messages received from one or more senders associated with sender ID and geo- sensor equipped sender devices, a Sender Profile Framework (SPF) check by checking records storing authorized domain names, via a plugin usable security module executed by one or more hardware processors of a message exchange and communication server, wherein the sender ID tagged as SPF-fail indicates that a domain name associated with the sender ID belongs to an unauthorized domain IP address, wherein a SPF stores a legal record of a plurality of domains and associated domain owner and organization details;
modifying, by the one or more hardware processors, the records with a set of custom headers comprising a plurality of parameters associated with a sender device profile, wherein the plurality of parameters comprising geocoding, device type, device type profile, sensor type, sensor type profile and accurate real-time positioning and timing services received from satellite agencies;
analyzing, by the one or more hardware processors, the one or more sender IDs tagged with SPF-fail in conjunction with one or more of the set of custom headers by performing one of:
initiating a two factor authentication (2FA), if the message is associated with at least one of a mass mailer communication and an unauthorized domain IP address, the 2FA comprises:communicating with a domain owner to confirm authorization of the unauthorized domain IP address, wherein the domain is classified as rogue if authorization is not confirmed, and identifying the sender associated with rogue domain as malicious and quarantining the message;
stripping body of the message, if the message does not belong to the mass mailer communication and does not have suspected domain name, and generating a checksum to derive presence of the mass mailer communication using checksum hit technique, wherein if the hits are beyond a threshold count the sender is identified as potentially malicious; and
if the domain IP address is detected to be mobile based on the geo code associated with the sender device present in the set of custom headers and captured in message header, then identify the sender as potentially malicious;
processing, by the one or more hardware processors, the message using prompt engineering, by a first LLM in conjunction with a phishy-domain-permutations database, if the sender of the message is identified as potentially malicious, wherein the processing comprises:
analyzing the message body to provide reasons for sender indicated as malicious, wherein the reasons are in natural language and machine interpretable language;
iteratively processing the reasons to generate short reasons excluding technical jargons to be embedded in the body of the message;
generating an image using text-to-Image models, wherein the image is indicative of potentially malicious mail and sentiment in the mail; and
including a warning indicating IP address is mobile and not fixed; and
modifying, by the one or more hardware processors, the Document Object Module (DOM) instance for the message to incorporate the processed results of the LLM associated with phishing warnings, wherein the message is displayed to a receiver on a receiver device with one or more phishing warnings, wherein the phishing warnings are displayed at the DOM nodes based on positions indicated by the LLM, and wherein phishing warnings in form of text message are displayed with change the font type face with kerning models as per a device form factor of a receiver device., as recited in claims 1, and substantially in claims 8 and 15.
Therefore, claims 1, 8 and 15 are allowable.
Claims 2-7, 9-14, and 16-20 dependent respectively upon claims 1, 8 and 15, are also allowable.
Conclusion
The following prior art made of record and not relied upon is considered pertinent to applicant’s disclosure:
“Prompt Engineering or Fine-Tuning? A Case Study on Phishing Detection with Large Language Models” by Trad & Chehad discloses how LLMs can be prompted more effectively by prompt engineering to detect phishing.
“GeoIP2 Connection Type Databases” by MaxMind details how IP address databases can store whether a user’s IP address is mobile or not.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DANIEL HABASHI whose telephone number is (571)272-2245. The examiner can normally be reached M-F: 9 AM-6 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Catherine Thiaw can be reached at (571)270-1138. 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.
DH
Examiner
Art Unit 2407
/Catherine Thiaw/Supervisory Patent Examiner, Art Unit 2407 7/8/2026
Prosecution Insights