DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claims 1-4, 6-11, 13-17 and 19-23 have been examined.
Response to Arguments
Applicant's arguments filed 7/28/26 have been fully considered but they are not persuasive.
Regarding Applicant’s remarks, Applicant mainly argues that the prior art of record do not explicitly disclose “inline analysis of emails” and “obtaining content of an email via a connector or a webhook to which the email application is configured to communicate indication of message, based on subscription to an event stream to which the email application publishes messages, and/or based on polling of an API of the email application.” However, the examiner disagrees for the following reasons.
As well-known in the art, use of APIs is the standard and most common way for communication between cloud services. Additionally, Singh discloses use of API for communication between cyberthreat detection system and cloud mail server/SaaS application, wherein the cyberthreat detection system , via push/pull operations, e-mail messages to detect malicious content transmitting through cloud-based mail system (Singh: [0097]-[0100]: the e-mail passes through the firewall may be intercepted for initial pre-processing…the cyberthreat detection system utilizes a retrospective API to pull/remove the email from the inbox of the mail client; [0102]: the cyberthreat detection system may be communicatively coupled to the cloud mail server to retrieve, via push/pull operations, emails received at the cloud mail server prior to transmission of the emails). Therefore, based on broadest interpretation consistent with the Specification, the combination of references teaches or at least suggests the disputed limitations.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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.
Claims 1, 6-10, 13-15 and 19-23 are rejected under 35 U.S.C. 103 as being unpatentable over Starink et al. U.S. 2015/0381653 (hereinafter Starink) in view of Singh U.S. 2025/0184349 (hereinafter Singh).
As per claim 1, 10 and 15, Starink discloses a method/CRM/apparatus comprising processor and memory for storing instructions to:
for each message of a plurality of messages sent within a Software-as-a-Service (SaaS) application (Starink: [0027]: messages might be in the form of e-mail, instant messages, and the like) obtaining content of the message from the SaaS application, based on determining that the message comprises a first uniform resource locator (URL), extracting the first URL from the message (Starink: [0032]: process email by analyzing a link included in the email; [0040]-[0041]: receive message at intermediary node to identify and analyze URLs in the message);
determining a category of the URL, wherein the category of the first URL indicates at least one of whether the first URL is malicious and a risk level of the first URL (Starink: Fig. 5; [0043]-[0044]: determine type of email and risk level); and
modifying the message in the SaaS application to modify or delete the first URL in the message based on the category of the first URL, wherein modifying the message based on the category of the URL comprises modifying or deleting the first URL in the message based on determining that the category of the first URL indicates that the first URL is at least one of malicious and high risk (Starink: [0041]-[0047]: various actions taken based on type of email and risk level).
Starink discloses cloud-based intermediary node that detects malicious content transmitted through SMTP servers (Starink: Fig. 1). Starink does not explicitly disclose, verbatim, “SaaS application” and detecting message being sent by a first service external to the SaaS application, based on at least one of configuration of the SaaS application to communicate indication of message to the first service via a webhook or connector, subscription to an event stream to which the SaaS application publishes messages, and polling an application programming interface (API) of the SaaS application; determining message comprise URL based on content of the message obtained from the SaaS application, and perform action via the API when malicious content is detected. However, Singh discloses cloud mail server that detects and analyzes message for malicious content and/or hyperlink and transmit notifications/protective measures via API to the recipient’s inbox (Singh: Abtract; [0097]-[0100]: the e-mail passes through the firewall may be intercepted for initial pre-processing…the cyberthreat detection system utilizes a retrospective API to pull/remove the email from the inbox of the mail client; [0102]: the cyberthreat detection system may be communicatively coupled to the cloud mail server to retrieve, via push/pull operations, emails received at the cloud mail server prior to transmission of the emails). It would have been obvious to one having ordinary skill in the art to establish communication between SaaS application with cloud-based intermediary via API because they are analogous art. The motivation to combine would be that the use of APIs is the standard and most common method for communication between cloud services.
As per claim 6, 13 and 19, Starink as modified discloses the limitations of claims 1, 10 and 15 respectively. Starink as modified teaches or at least suggests wherein determining the category of the URL comprises forwarding the first URL to a URL analyzer and determining the category of the first URL based on a response obtained from the URL analyzer (Starink: Fig. 5 and [0044]-[0048]).
As per claim 7, 14 and 20, Starink as modified discloses the limitations of claims 1, 10 and 15 respectively. Starink as modified teaches or at least suggests wherein determining the category of the first URL comprises determining if the first URL is at least one of a phishing URL, a malicious URL, a benign URL, an unknown URL, a low risk URL, and a high risk URL, wherein determining that the category of the first URL indicates that the first URL is at least one of malicious and high risk comprises determining that the category of the first URL indicates that the first URL is at least one of a phishing URL, a malicious URL, and a high risk URL (Starink: Fig. 5 and [0044]-[0048]).
As per claim 8, Starink as modified discloses the method of claim 7. Starink as modified does not explicitly disclose based on determining that the URL is a phishing URL, determining exposure of the phishing URL among users of the SaaS application based at least partly on a number of users of the SaaS application with which the phishing URL has been shared; and prioritizing remediation of the phishing URL based on determining that the phishing URL has had high exposure. However, prioritizing protective/remediation measures based on higher volume of incident is well-known in the art.
As per claim 9, Starink as modified discloses the method of claim 1. Starink as modified teaches or at least suggests wherein the SaaS application is a collaboration-based SaaS application (Starink: [0027]: email or instant message).
As per claim 21-23, Starink as modified discloses the limitations claims 1, 10 and 15 respectively. Starink as modified further discloses wherein obtaining the notification or event indicating content of the message from the SaaS application is based on sending of the message via a direct message within the SaaS application or via posting of the message in a channel within the SaaS application (Singh: [0102]: push/pull notification). Use of APIs for push/pull operations is well-known in the art.
Claims 2-4, 11, 16 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Starink et al. U.S. 2015/0381653 (hereinafter Starink) in view Singh and further in view of Carames U.S. 2016/0285824 (hereinafter Carames).
As per claim 2, 11 and 16, Starink discloses the limitations of claims 1, 10 and 15 respectively. Starink also teaches or at least suggests wherein modifying the first URL in the message to redirect user to a trusted landing page (Starink: [0047]-[0048]: replace URL with another URL to direct user to the trusted landing page, which also indicate potential spammer website). Starink does not explicitly disclose appending the first URL to a second URL to create a third URL, wherein the second URL corresponds to a secure environment; and replacing the first URL in the message with the third URL, wherein navigating to the third URL loads a resource corresponding to the first URL in the secure environment. However, Carames discloses modifying URL in the message by including link to sandbox to allow user to access URL content in trusted environment (Carames: Abstract; [0017] and [0022]: the user device may be presented with a representation of the host content as rendered at the sandbox system via remote desktop interface; [0038]-[0040]: reconfigured link). It would have been obvious to one having ordinary skill in the art to modify the teachings of Starink to provide actual access to unknown/potential malicious content within sandbox model when user is redirected to the trusted landing page because both disclose intermediary nodes that analyzes message for potential malicious hyperlinks. The motivation to combine would be to allow access to unknown content in a secure manner instead of blocking access.
As per claim 3 and 17, Starink as modified discloses the limitations of claims 2 and 16 respectively. Starink as modified further discloses wherein appending the first URL to the second URL comprises appending a query string to the second URL that comprises the first URL (Carames: [0022]). Same rationale applies here as above in rejecting claim 2.
As per claim 4, Starink as modified discloses the method of claim 2. Starink as modified teaches or at least suggests wherein modifying the first URL in the message is based on determining that the category of the first URL indicates that the first URL is unknown and high risk (Starink: [0071]-[0076]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Zimmermann et al. U.S. 2020/0137097 discloses method for securing enterprise computing environment, wherein cloud security fabric monitors and detects malicious communication of SaaS application via APIs.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 SHIN HON (ERIC) CHEN whose telephone number is (571)272-3789. The examiner can normally be reached Monday to Thursday 9am- 7pm.
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, Lynn Feild can be reached at 571-272-2092. 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.
/SHIN-HON (ERIC) CHEN/ Primary Examiner, Art Unit 2431
Prosecution Insights