DETAILED ACTION
The following claims are pending in this office action: 1-9, 11-18 and 20-22
The following claims are amended: 1, 3-4, 6-7, 9, 11-12 and 14-17
The following claims are new: 21-22
The following claims are cancelled: 10 and 19
Claims 1-9, 11-18 and 20 are rejected. This rejection is FINAL.
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 .
Allowable Subject Matter
Claims 21-22 are objected 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.
RESPONSE TO ARGUMENTS
Applicant’s arguments in the amendment filed 02/25/2026 have been fully considered but are moot in view of new grounds of rejection necessitated by amendment.
Applicant notes: Holub does not teach or suggest at least “based at least on the data representing the performance of the precursor event, blocking the user account or the user session from performing the incrimination action in the computer system while permitting the user account or the user session to attempt execution of the incrimination action and permitting the user account or the user session to execute a subsequent action other than the incrimination action.” This limitation is disclosed by Hazony et al. (US Pub. 2021/0240836) as explained below and rejected accordingly.
Independent claims 9 and 16 are amended in a similar way to claim 1. The amended limitations are disclosed by Hazony et al. (US Pub. 2021/0240836) as explained below and rejected accordingly.
Dependent claims 2-8, 11-15, 17-18 and 20 depend on independent claims 1, 9 and 16. The amended elements in the claims are disclosed by Hazony et al. (US Pub. 2021/0240836) as explained below, and so any additional features to the dependent claims are rejected accordingly.
As for taking of Official Notice, in addition to the new rejection of the claims as necessitated by amendment, Examiner would like to clarify on the record that this rejection (as well as the prior non-final rejection) relies/relied on the broadest reasonable interpretation of the plain language of the claims and not on taking Official Notice. In a subsequent call to Applicant, Examiner noted the language used in the prior rejection, specifically taking “Official Notice” was an inadvertent error in communication and not to invoke Official Notice as the basis for the rejection. For example, amended claims 4, 5, 11 and 17 recites “comprises at least one of”, “configured to at least one of”, “analyzing at least one of” or “by at least one of” A or B (or C, etc.) where A and B (and C, etc.) are different actions. The broadest reasonable interpretation of this requires at least A or B (or C etc.) to be performed, thus further limiting the claims, but not requiring all the actions listed to be performed. This limitation is satisfied as at least one of the recited actions are disclosed to be performed in the cited prior art as explained in the rejection below and in the non-final rejection.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. § 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-9, 11-18 and 20 are rejected under 35 U.S.C. § 103 as being unpatentable over Holub et al. (US Patent No. 12,289,323) (hereinafter “Holub”) in view of Hazony et al. (US Pub. 2021/0240836) (hereinafter “Hazony”).
As per claim 1, Holub teaches a method performed in a computing system, the method comprising automatically: ([Holub, col. 1, ln. 29-51] “method described herein ... to implement a cyberattack monitoring system [in a computing system] configured to identify successful attacks”)
observing data representing a performance of a precursor event in the computing system by a user account or a user session; ([Holub, col. 3, ln. 23-28] “the monitoring system ... analyze a flow of log entries [observing data] ... The system may apply an evaluation function to detect attack patterns in the log and determine ... particular client actions [by a user account or a user session] that correspond to an attempted attack”; [col. 6, ln. 9-10] “the monitoring system ... implement a successful attack detection component 148”; [col. 10, ln. 46-50] “the successful attack detector 148 ... to recognize particular actions or action sequences as attack actions after the initial attack attempt [precursor event]”; [col. 14, ln. 19-24] “a suspected attacker [user account] is recorded in an attacker database ... wherein an attacker may be remembered ... a client session”; [col. 16, ln. 13-18] “computer system that can be used to implement ... a cyberattack monitoring system configured to detect successful attacks”)
discerning that the precursor event is associated in the computing system with an incrimination action which has not yet been performed by the user account or the user session after the performance of the precursor event, ([Holub, col. 10, ln. 46-53] “the successful attack detector 148 ... to recognize particular actions or action sequences as attack actions [incrimination action after the performance of the at least one precursor event] after the initial attack attempt [the precursor event is associated in the computing system with an incrimination action] ... For example, a single failed login attempt may be considered an attack action, even though it does not rise to the level of an attempted attack, which may require multiple failed logins [an incrimination action which has not yet been performed by the user account or the user session]”) wherein the incrimination action is more likely to be performed by an attacker-driven account or an attacker-driven user session than by a non-attacker-driven account or a non-attacker-driven user session; and ([col. 6, ln. 34-48] “attack detection component 148 ... employ one or more statistical measures to determine if the benign action sequence indicates a successful attack [incrimination action] ... track statistics such as ... a ratio of attack actions [performed by an attack-driven account] to benign actions [performed by a non-attack-driven account] ... these metrics [likelihood – see col. 12, ln. 11-15: “the follow-on activities, which may be computed by the successful attack detection component 148 ... indicate a probability or likelihood that the observed activities represent a genuine attack”] may be tracked over time ... a successful attack may be detected when the overall attack-to-benign action ratio of the attacker exceeds a specified threshold [incrimination action is more likely to be performed by an attack-driven account than by a non=attack-driven account]”)
blocking the user account or the user session from performing the incrimination action in the computing system. ([Holub, col. 7, ln. 32-34] “a detected successful attack will also trigger an attack mitigation component 152 to initiate mitigation actions for the attack”; [col. 7, ln. 63-67] “the service may be configured to route further requests of the attacker to a separate server specifically designated to handle requests from suspected attackers, so that activities of the attacker can be isolated [blocking the user account or the user session from performing the incrimination action as they are prevented] and better monitored and controlled”)
Holub does not clearly teach based at least on the data representing the performance of the precursor event, blocking the user account or the user session from performing the incrimination action in the computing system while permitting the user account or the user session to attempt execution of the incrimination action and permitting the user account or the user session to execute a subsequent action other than the incrimination action.
However, Hazony teaches based at least on the data representing the performance of the precursor event, blocking the user account or the user session ([Hazony, para. 0119] “detect that an employee [user account – see para. 0048: “A policy ... used for ... a single employee ... control ... actions performed”] tends to click on a dangerous links in emails, websites, popups, and so on .... At the first time the user clicks on a dangerous link, [performance of the precursor event: first time clicking a dangerous link] ... select an action based on ... a history of actions of the user [data representing the performance of the precursor event] ... the type of action to select ... a prevention of an action”) from performing the incrimination action in the computing system ([para. 0119] “prevent the user from further clicking such links ... prevent links from being clickable by (or being displayed to) the user [the incrimination action]”) while permitting the user account or the user session to attempt execution of the incrimination action ([para. 0119] “if within a specific or predefined time interval, the employee again clicks a link that may be risky ... AU 315 may highlight the link and/or cause a 3rd party unit to do so and AU 315, in addition to highlighting the link may prompt the user to confirm the link is to be pressed [permitting the user account or the user session], if, after the second time, the employee again clicks on a dangerous link [attempt execution of the incrimination action: confirm clicking on a dangerous link]”) and permitting the user account or the user session to execute a subsequent action other than the incrimination action. ([Para. 0120] “following a sequence of risky actions or behavior related to links as described [a subsequent action] ... may force a user to participate in a training session related to links and, only if the user successfully completes the training session AU 315 may enable the user ... to click links [permitting the user account or the user session to execute a subsequent action link, other than the incrimination action: clicking a safe link]”)
It would have been obvious before the effective filing date of the claimed invention for one of ordinary skill in the art to have modified the elements disclosed by Holub with the teachings of Hazony to include based at least on the data representing the performance of the precursor event, blocking the user account or the user session from performing the incrimination action in the computing system while permitting the user account or the user session to attempt execution of the incrimination action and permitting the user account or the user session to execute a subsequent action other than the incrimination action. One of ordinary skill in the art would have been motivated to make this modification because by responding to a user’s action immediately, in real-time, such steps are far more effective and efficient to increase awareness of security risks. (Hazony, para. 0120)
As per claim 2, Holub in view of Hazony teaches claim 1.
Holub also teaches detecting an attempt by the user account or the user session to perform the blocked incrimination action; and ([Holub, col. 7, ln. 63-67] “a detected successful attack [detecting an attempt by the user account or the user section to perform the blocked incrimination action] will also trigger an attack mitigation component 152 to initiate mitigation actions for the attack”)
in response to detecting the attempt, restricting a capability of the user account or the user session in addition to the blocking the user account or the user session from performing the incrimination action. ([Holub, col. 7, ln. 49-52] “the service 120 ... reconfigured to block the attacker (e.g. client X) [blocking the user session from performing the incrimination action] from performing further actions on the service (e.g. by denying further requests from client X) [restricting a capability of the user account or the user session in addition to the blocking]”; this is in addition to the blocking described above – see col. 15, ln. 7-9] where remedial actions may be additionally applied in a loop)
As per claim 3, Holub in view of Hazony teaches claim 1.
Holub also teaches designating the incrimination action based at least on a determination that an attacker likelihood of performing the incrimination action is greater than a non-attacker likelihood of performing the incrimination action. ([Holub, col. 6, ln. 34-48] “attack detection component 148 ... employ one or more statistical measures to determine if the benign action sequence indicates a successful attack [designating the incrimination action] ... track statistics such as ... a ratio of attack actions [an attacker likelihood] to benign actions [non-attacker likelihood] ... these metrics [likelihood – see col. 12, ln. 11-15: “the follow-on activities, which may be computed by the successful attack detection component 148 ... indicate a probability or likelihood that the observed activities represent a genuine attack”] may be tracked over time ... a successful attack may be detected when the overall attack-to-benign action ratio [attacker likelihood of performing the incrimination action] of the attacker exceeds [is greater than] a specified threshold [non-attacker likelihood of performing the incrimination action]”)
As per claim 4, Holub in view of Hazony teaches claim 1.
Holub also teaches wherein the incrimination action that is blocked is configured to at least one of: ([Holub, col. 7, ln. 36 to col. 8, ln. 4] “the mitigation actions ... to stop furtherance of the attacks ... the mitigation measures ... vary”)
add an additional user account to the computing system; (Examiner interprets the BRI of at least one of: x, y ... or z to require one of the set to be disclosed to meet the limitation as is disclosed by Holub below)
run a specified process; (Examiner interprets the BRI of at least one of: x, y ... or z to require one of the set to be disclosed to meet the limitation as is disclosed by Holub below)
change a resource configuration in the computing system; (Examiner interprets the BRI of at least one of: x, y ... or z to require one of the set to be disclosed to meet the limitation as is disclosed by Holub below)
create a resource in a cloud computing environment; (Examiner interprets the BRI of at least one of: x, y ... or z to require one of the set to be disclosed to meet the limitation as is disclosed by Holub below)
request an internet connection; or ([Holub, col. 7, ln. 49-52] “the service 120 ... reconfigured to block the attacker (e.g. client X) from performing further actions on the service (e.g. by denying further requests from client X) [blocking an action which is configured to upon execution request the service]”; [col. 4, ln. 17-19] “the service 120 may be a web-based service, such as a website or web application that is accessed over a network such as the Internet [request an internet connection]”)
transmit data over an internet connection. (Examiner interprets the BRI of at least one of: x, y ... or z to require one of the set to be disclosed to meet the limitation as is disclosed by Holub above)
As per claim 5, Holub in view of Hazony teaches claim 1.
Holub also teaches wherein blocking the user account or the user session from performing the incrimination action comprises at least one of: ([Holub, col. 7, ln. 36 to col. 8, ln. 4] “the mitigation actions ... to stop furtherance of the attacks ... the mitigation measures ... vary”)
changing an association in the computing system between a role and the user account; (Examiner interprets the BRI of at least one of: x, y ... or z to require one of the set to be disclosed to meet the limitation as is disclosed by Holub below)
prohibiting changing an association in the computing system between a role and a different user account than the user account; (Examiner interprets the BRI of at least one of: x, y ... or z to require one of the set to be disclosed to meet the limitation as is disclosed by Holub below)
preventing creation of a virtual machine; (Examiner interprets the BRI of at least one of: x, y ... or z to require one of the set to be disclosed to meet the limitation as is disclosed by Holub below)
prohibiting email activity from a specified IP address; ([Holub, col. 2, ln. 58-60] “this disclosure describes embodiments of a cyberattack monitoring system capable of identifying cyberattacks against web-based services”; [col. 7, ln. 10-11] “a detected successful attack over a communication system such as an email system [web-based services]”; [col. 5, ln. 41-43] “record the identity of the attacker client ... a source IP address of the client [a specified IP address]”; [col. 7, ln. 49-52] “reconfigured to block the attacker ... client X [from a specified IP address] ... from performing further actions on the service [prohibiting email activity]”)
prohibiting email activity from a specified shell; or (Examiner interprets the BRI of at least one of: x, y ... or z to require one of the set to be disclosed to meet the limitation as is disclosed by Holub above)
prohibiting email activity from a specified web app. (Examiner interprets the BRI of at least one of: x, y ... or z to require one of the set to be disclosed to meet the limitation as is disclosed by Holub above)
As per claim 6, Holub in view of Hazony teaches claim 1.
Holub teaches wherein the blocking is completed ([Holub, col. 15, ln. 5-8] “a GUI ... provide user controls that allow a user to ... initiate mitigation actions to respond to the attack”; [col. 12, ln. 35-37] “the user controls allow the user to block further actions from the attacker on the service”) before any security alert is automatically raised ([col. 14, ln. 61-62] “At operation 750, the attack monitoring system will generate a report of the successful attacks detected”; [Fig. 7, col. 15, ln. 8-9] “the depicted process may be repeated in a loop”; the second [one of the any security alert] is automatically raised after the first round of mitigation action) in response to the performance of the precursor event. ([Fig. 7; col. 13, ln. 64 to col. 14, ln. 1] “At operation 720, [before the reporting, making the performing in response to this step] the monitoring system identifies ... an attempted attack on the service [the performance of the precursor event]”)
As per claim 7, Holub in view of Hazony teaches claim 1.
Holub also teaches wherein no alert is raised in the computing system in response to the performance of the precursor event. ([Abstract] “the system identifies the initial attack [the performance of the precursor event] by matching client actions to known attack patterns ... the presence of follow-on benign actions is used as a filter to filter out unsuccessful attacks [no alert is raised] and false positives detected by the system”; [col. 11, ln. 61 to col. 12, ln. 4] “As shown, the GUI 500 displays a list of potentially successful attacks detected by the cyberattack monitoring system to security analysts [raising an alert] ... As discussed, by filtering observed attacks based on the attackers' follow-on activities, [in response to the performance of the precursor event as the follow-on activities are performed in response to the initial attack/precursor event] the monitoring system is able to drastically reduce the number of attacks reported by the GUI, [no alert is raised in the computing system]”)
As per claim 8, Holub in view of Hazony teaches claim 1.
Holub also teaches ascertaining that a precursor state is also associated in the computing system with the incrimination action; and ([Holub, col. 14, ln. 35-37] “At operation 740, the monitoring system [in the computing system] identifies a subset of the attempted attacks [a precursor state] as successful attacks based on [ascertaining is also associated in] follow-on ... actions of suspected attackers [with the incrimination action]”)
verifying that the precursor state is present in the computing system ([Holub, col. 14, ln. 35-60] “At operation 740 [before blocking], the monitoring system [in the computing system] identifies a subset of the attempted attacks [the precursor state is present] ... may be evaluated [verifying] by a component such as the successful attack detection component ... the successful attack detector may evaluate ... to recognize successful attacks”) before blocking the user account or the user session from performing the incrimination action in the computing system. ([Col. 14, ln. 61 to col. 15, ln. 8] “At operation 750, the attack monitoring system will ... initiate mitigation actions to respond to the attack”; [col. 12, ln. 35-37] “the user controls allow the user to block further actions from the attacker on the service”)
As per claim 9, Holub teaches a computing system, comprising: ([Holub, col. 16, ln. 13-18] “computer system ... to implement ... a cyberattack monitoring system configured to detect successful attacks”)
a digital memory; ([Holub, col. 16, ln. 60-61] “computer system 1000 ... include ... system memories”)
a processor in operable communication with the digital memory, the processor configured to observe data which represents a performance of a precursor event by a user account or a user session; ([Holub, col. 3, ln. 23-28] “the monitoring system ... analyze a flow of log entries [observing data] ... The system may apply an evaluation function to detect attack patterns in the log and determine ... particular client actions [by a user account or a user session] that correspond to an attempted attack”; [col. 6, ln. 9-10] “the monitoring system ... implement a successful attack detection component 148”; [col. 10, ln. 46-50] “the successful attack detector 148 ... to recognize particular actions or action sequences as attack actions after the initial attack attempt [precursor event]”; [col. 14, ln. 19-24] “a suspected attacker [user account] is recorded in an attacker database ... wherein an attacker may be remembered ... a client session”; [col. 16, ln. 13-18] “computer system that can be used to implement ... a cyberattack monitoring system configured to detect successful attacks”)
discern that the precursor event is associated in the digital memory with an incrimination action that has not yet been performed by the user account or the user session after the performance of the precursor event, ([Holub, col. 10, ln. 46-53] “the successful attack detector 148 ... to recognize particular actions or action sequences as attack actions [incrimination action after the performance of the precursor event] after the initial attack attempt [the precursor event is associated in the digital memory with an incrimination action] ... For example, a single failed login attempt may be considered an attack action, even though it does not rise to the level of an attempted attack, which may require multiple failed logins [an incrimination action which has not yet been performed by the user account or the user session]”) wherein the incrimination action is more likely to be performed by an attacker-driven account or an attacker-driven session than by a non-attacker-driven account or a non-attacker-driven session; and ([col. 6, ln. 34-48] “attack detection component 148 ... employ one or more statistical measures to determine if the benign action sequence indicates a successful attack [incrimination action] ... track statistics such as ... a ratio of attack actions [performed by an attack-driven account] to benign actions [performed by a non-attack-driven account] ... these metrics [likelihood – see col. 12, ln. 11-15: “the follow-on activities, which may be computed by the successful attack detection component 148 ... indicate a probability or likelihood that the observed activities represent a genuine attack”] may be tracked over time ... a successful attack may be detected when the overall attack-to-benign action ratio of the attacker exceeds a specified threshold [incrimination action is more likely to be performed by an attack-driven account than by a non=attack-driven account]”)
blocking the user account or the user session from performing the incrimination action in the computing system. ([Holub, col. 7, ln. 32-34] “a detected successful attack will also trigger an attack mitigation component 152 to initiate mitigation actions for the attack”; [col. 7, ln. 63-67] “the service may be configured to route further requests of the attacker to a separate server specifically designated to handle requests from suspected attackers, so that activities of the attacker can be isolated [blocking the user account or the user session from performing the incrimination action as they are prevented] and better monitored and controlled”)
Holub does not clearly teach based at least on the data representing the performance of the precursor event, block the user account or the user session from performing the incrimination action while permitting the user account or the user session to attempt execution of the incrimination action and permitting the user account or the user session to execute a subsequent action other than the incrimination action.
However, Hazony teaches based at least on the data representing the performance of the precursor event, block the user account or the user session ([Hazony, para. 0119] “detect that an employee [user account – see para. 0048: “A policy ... used for ... a single employee ... control ... actions performed”] tends to click on a dangerous links in emails, websites, popups, and so on .... At the first time the user clicks on a dangerous link, [performance of the precursor event: first time clicking a dangerous link] ... select an action based on ... a history of actions of the user [data representing the performance of the precursor event] ... the type of action to select ... a prevention of an action”) from performing the incrimination action ([para. 0119] “prevent the user from further clicking such links ... prevent links from being clickable by (or being displayed to) the user [the incrimination action]”) while permitting the user account or the user session to attempt execution of the incrimination action ([para. 0119] “if within a specific or predefined time interval, the employee again clicks a link that may be risky ... AU 315 may highlight the link and/or cause a 3rd party unit to do so and AU 315, in addition to highlighting the link may prompt the user to confirm the link is to be pressed [permitting the user account or the user session], if, after the second time, the employee again clicks on a dangerous link [attempt execution of the incrimination action: confirm clicking on a dangerous link]”) and permitting the user account or the user session to execute a subsequent action other than the incrimination action. ([Para. 0120] “following a sequence of risky actions or behavior related to links as described [a subsequent action] ... may force a user to participate in a training session related to links and, only if the user successfully completes the training session AU 315 may enable the user ... to click links [permitting the user account or the user session to execute a subsequent action link, other than the incrimination action: clicking a safe link]”)
It would have been obvious before the effective filing date of the claimed invention for one of ordinary skill in the art to have modified the elements disclosed by Holub with the teachings of Hazony to include based at least on the data representing the performance of the precursor event, block the user account or the user session from performing the incrimination action while permitting the user account or the user session to attempt execution of the incrimination action and permitting the user account or the user session to execute a subsequent action other than the incrimination action. One of ordinary skill in the art would have been motivated to make this modification because by responding to a user’s action immediately, in real-time, such steps are far more effective and efficient to increase awareness of security risks. (Hazony, para. 0120)
As per claim 11, Holub in view of Hazony teaches claim 9.
Holub also teaches wherein the processor is also configured to form data representing the precursor event and the incrimination event at least in part by computationally analyzing at least one of: ([Holub, col 5, ln. 63-65] “the dataset 130 indicates that after the initial attack actions 132, [data representing the precursor event] client X later performs a sequence of ... additional suspicious actions that may be seen as attack actions [data representing the incrimination event]”)
a non-empty set of events and alerts; ([Holub, col 4, ln. 37-39] “the dataset 130 may be an activity log that captures user actions (e.g. user commands) [events] submitted to the service 120”; [col. 5, ln. 63-65] “dataset 130 may record ... a series of attack actions [alerts]”; Examiner interprets the BRI of at least one of: x, y ... or z to require one of the set to be disclosed to meet the limitation as is disclosed by Holub)
a non-empty set of alerts; or ([Holub, col 4, ln. 37-39] “the dataset 130 may be an activity log that captures user actions (e.g. user commands) submitted to the service 120”; [col. 5, ln. 63-65] “dataset 130 may record ... a series of attack actions [alerts]”; Examiner interprets the BRI of at least one of: x, y ... or z to require one of the set to be disclosed to meet the limitation as is disclosed by Holub)
a non-empty event log. ([Holub, col 4, ln. 37-39] “the dataset 130 may be an activity log [event log] that captures user actions (e.g. user commands) submitted to the service 120”; Examiner interprets the BRI of at least one of: x, y ... or z to require one of the set to be disclosed to meet the limitation as is disclosed by Holub)
As per claim 12, Holub in view of Hazony teaches claim 9.
Holub also teaches wherein the processor is also configured to form data representing the precursor event and the incrimination event ([Holub, col. 12, ln. 5-11; Fig. 5] “the GUI [the processor is configured to form] ... the attack pattern 512 that matched the initial attack attempt [data representing the precursor event] ... the follow-on activities of the attacker [data representing the incrimination event] ... which may be computed by the successful attack detection component [at least in part by the described process below]”) correlating, with a correlation model, candidate precursor events with a candidate incrimination action. ([col, 11, ln. 15-19] “the successful attack detector ... using an anomaly detection model [with a correlation model] ... the anomaly detection model 450 ... to distinguish between [correlate] follow-on actions [candidate incriminate action] that look like furtherance of an attack [candidate precursor events]”; [col. 11, ln. 24-27] “The anomaly detection model 450 [correlation model] ... to keep up with the changing behavior patterns of attackers ... implement a clustering technique that assigns action sequences of suspected attackers [candidate precursor events with a candidate action] to different clusters [correlate], where certain clusters are associated with malicious behavior”)
As per claim 13, Holub in view of Hazony teaches claim 12.
Holub also teaches wherein the correlation model comprises at least one of: a statistical model, or a machine learning model. ([Holub, col. 11, ln. 15-17] “The anomaly detection model 450 may be a machine learning model”)
As per claim 14, Holub in view of Hazony teaches claim 9.
Holub also teaches wherein the processor is also configured to form data representing the precursor event and the incrimination event at least in part by ([Holub, col. 12, ln. 5-11; Fig. 5] “the GUI [processor is configured to form] ... the attack pattern 512 that matched the initial attack attempt [data representing the precursor event] ... the follow-on activities of the attacker [data representing the incrimination event] ... which may be computed by the successful attack detection component [at least in part by the described process below]”) filtering out a candidate incrimination action ([col, 11, ln. 15-19] “the successful attack detector ... to distinguish [filtering out] ... “normal” behaviors of clients [a candidate incrimination action] that are not furthering the attack”) after determining that the candidate incrimination action is more likely, by a threshold likelihood, ([col. 11, ln. 25-27] “an anomaly metric [by a threshold likelihood] ... used to determine whether [is more likely] the follow-on actions [the candidate incrimination action] constitute a furtherance of a successful attack”) to be performed by a non-attacker-driven user account or a non-attacker-driven user session than by an attacker-driven user account or an attacker-driven user session. ([Col. 6, ln. 64-67] “anomaly metric that indicates the degree of strangeness [likelihood threshold] of the client's behavior and recognize the attack as successful [to be performed by an attacker-driven user account or a attacker-driver user session than by an non-attacker-driven user account or an non-attacker-driven user session] when the anomaly metric exceeds a threshold”; as the anomaly metric indicates the degree of strangeness, its inverse when it does not meet the threshold necessarily indicates a degree of non-strangeness performed by a non-attacker-driven user account)
As per claim 15, Holub in view of Hazony teaches claim 9.
Holub also teaches wherein the processor is also configured to designate the incrimination action as incriminating based at least on a determination that an attacker likelihood of performing the incrimination action is more likely than a non-attacker likelihood of performing the incrimination action. ([Holub, col. 6, ln. 34-48] “attack detection component 148 ... employ one or more statistical measures to determine if the benign action sequence indicates a successful attack [designating the incrimination action as incriminating] ... track statistics such as ... a ratio of attack actions [an attacker likelihood] to benign actions [non-attacker likelihood] ... these metrics [likelihood – see col. 12, ln. 11-15: “the follow-on activities, which may be computed by the successful attack detection component 148 ... indicate a probability or likelihood that the observed activities represent a genuine attack”] may be tracked over time ... a successful attack may be detected [a determination] when the overall attack-to-benign action ratio [attacker likelihood of performing the incrimination action] of the attacker exceeds [is greater than] a specified threshold [non-attacker likelihood of performing the incrimination action]”)
As per claim 16, Holub teaches a computer-readable storage device configured with data and instructions which upon execution by a processor perform a method comprising automatically: ([Holub, col. 16, ln. 60 to col. 17, ln. 3] “computer system 1000 ... include ... system memories ... used to store ... executable instructions to implement the methods and the techniques described”)
observing data representing a performance of a precursor event in a computing system by a user account or a user session; ([Holub, col. 3, ln. 23-28] “the monitoring system ... analyze a flow of log entries [observing data] ... The system may apply an evaluation function to detect attack patterns in the log and determine ... particular client actions [by a user account or a user session] that correspond to an attempted attack”; [col. 6, ln. 9-10] “the monitoring system ... implement a successful attack detection component 148”; [col. 10, ln. 46-50] “the successful attack detector 148 ... to recognize particular actions or action sequences as attack actions after the initial attack attempt [precursor event]”; [col. 14, ln. 19-24] “a suspected attacker [user account] is recorded in an attacker database ... wherein an attacker may be remembered ... a client session”; [col. 16, ln. 13-18] “computer system that can be used to implement ... a cyberattack monitoring system configured to detect successful attacks”)
discerning that the precursor event is associated, by an association mechanism in the computing system, with an incrimination action which has not yet been performed by the user account or the user session after the performance of the precursor event, ([Holub, col. 10, ln. 46-53] “the successful attack detector 148 [by an association mechanism in the computing system] ... to recognize particular actions or action sequences as attack actions [incrimination action after the performance of the precursor event] after the initial attack attempt [the precursor event is associated in the computing system with an incrimination action] ... For example, a single failed login attempt may be considered an attack action, even though it does not rise to the level of an attempted attack, which may require multiple failed logins [an incrimination action which has not yet been performed by the user account or the user session]”) wherein the incrimination action is more likely to be performed by an attacker-driven session than by a non-attacker-driven account or a non-attacker driven session; and ([col. 6, ln. 34-48] “attack detection component 148 ... employ one or more statistical measures to determine if the benign action sequence indicates a successful attack [incrimination action] ... track statistics such as ... a ratio of attack actions [performed by an attack-driven account] to benign actions [performed by a non-attack-driven account] ... these metrics [likelihood – see col. 12, ln. 11-15: “the follow-on activities, which may be computed by the successful attack detection component 148 ... indicate a probability or likelihood that the observed activities represent a genuine attack”] may be tracked over time ... a successful attack may be detected when the overall attack-to-benign action ratio of the attacker exceeds a specified threshold [incrimination action is more likely to be performed by an attack-driven account than by a non=attack-driven account]”)
blocking the user account or the user session from performing the incrimination action in the computing system. ([Holub, col. 7, ln. 32-34] “a detected successful attack will also trigger an attack mitigation component 152 to initiate mitigation actions for the attack”; [col. 7, ln. 63-67] “the service may be configured to route further requests of the attacker to a separate server specifically designated to handle requests from suspected attackers, so that activities of the attacker can be isolated [blocking the user account or the user session from performing the incrimination action as they are prevented] and better monitored and controlled”)
Holub does not clearly teach based at least on the data representing the performance of the precursor event, blocking the user account or the user session from performing the incrimination action in the computing system, while permitting the user account or the user session to attempt execution of the incrimination action, and permitting the user account or the user session to execute a subsequent action other than the incrimination action.
However, Hazony teaches based at least on the data representing the performance of the precursor event, blocking the user account or the user session ([Hazony, para. 0119] “detect that an employee [user account – see para. 0048: “A policy ... used for ... a single employee ... control ... actions performed”] tends to click on a dangerous links in emails, websites, popups, and so on .... At the first time the user clicks on a dangerous link, [performance of the precursor event: first time clicking a dangerous link] ... select an action based on ... a history of actions of the user [data representing the performance of the precursor event] ... the type of action to select ... a prevention of an action”) from performing the incrimination action in the computing system, ([para. 0119] “prevent the user from further clicking such links ... prevent links from being clickable by (or being displayed to) the user [the incrimination action]”) while permitting the user account or the user session to attempt execution of the incrimination action, ([para. 0119] “if within a specific or predefined time interval, the employee again clicks a link that may be risky ... AU 315 may highlight the link and/or cause a 3rd party unit to do so and AU 315, in addition to highlighting the link may prompt the user to confirm the link is to be pressed [permitting the user account or the user session], if, after the second time, the employee again clicks on a dangerous link [attempt execution of the incrimination action: confirm clicking on a dangerous link]”) and permitting the user account or the user session to execute a subsequent action other than the incrimination action. ([Para. 0120] “following a sequence of risky actions or behavior related to links as described [a subsequent action] ... may force a user to participate in a training session related to links and, only if the user successfully completes the training session AU 315 may enable the user ... to click links [permitting the user account or the user session to execute a subsequent action link, other than the incrimination action: clicking a safe link]”)
It would have been obvious before the effective filing date of the claimed invention for one of ordinary skill in the art to have modified the elements disclosed by Holub with the teachings of Hazony to include based at least on the data representing the performance of the precursor event, blocking the user account or the user session from performing the incrimination action in the computing system, while permitting the user account or the user session to attempt execution of the incrimination action, and permitting the user account or the user session to execute a subsequent action other than the incrimination action. One of ordinary skill in the art would have been motivated to make this modification because by responding to a user’s action immediately, in real-time, such steps are far more effective and efficient to increase awareness of security risks. (Hazony, para. 0120)
As per claim 17, Holub in view of Hazony teaches claim 16.
Holub also teaches wherein the method further comprises: in response to detecting an attempt by the user account or the user session to perform the incrimination action, ([Holub, col. 7, ln. 63-67] “a detected successful attack [in response to detecting an attempt by the user account or the user section to perform the incrimination action] will also trigger an attack mitigation component 152 to initiate mitigation actions for the attack”) restricting a capability of the user account or the user session by at least one of: ([col. 7, ln. 49-52] “the service 120 ... reconfigured to block the attacker (e.g. client X) [blocking the user session from performing the incrimination action] from performing further actions on the service (e.g. by denying further requests from client X) [restricting a capability of the user account or the user session in addition to the blocking]”)
disabling the user account or the user session; ([Holub, col. 7, ln. 50-52] “block the attacker (e.g. client X) from performing further actions on the service ... by denying further requests [disabling the user session] from client X”)
adding an authentication requirement to the user account or the user session; (Examiner interprets the BRI of at least one of: x, y ... or z to require one of the set to be disclosed to meet the limitation as is disclosed by Holub above and below)
adding an authorization requirement to the user account or the user session; or (Examiner interprets the BRI of at least one of: x, y ... or z to require one of the set to be disclosed to meet the limitation as is disclosed by Holub above and below)
simulating, to the user account or the user session, a simulated performance of the blocked incrimination action and not actually performing the blocked incrimination action. ([Holub, col. 7, ln. 63-67] “the service may be configured to route further requests of the attacker [simulating to the user account or the user session] to a separate server specifically designated to handle requests from suspected attackers [a simulated performance of the blocked incrimination action], so that activities of the attacker can be isolated [not actually performing the blocked incrimination action]”)
As per claim 18, Holub in view of Hazony teaches claim 16.
Holub also teaches obtaining, at least in part by executing a machine learning model, at least one of: ([Holub, col. 11, ln. 15-17] “The anomaly detection model 450 may be a machine learning model”)
a likelihood that the incrimination action is performed by an attacker-driven account or an attacker-driven session; or ([Holub, col, 11, ln. 15-19] “the successful attack detector ... using an anomaly detection model [by executing a machine learning model] ... the anomaly detection model 450 ... to distinguish between follow-on actions [incrimination action] that look like furtherance of an attack [is performed by an attack-driven account or an attack-driven session]”; [col. 11, ln. 24-27] “The anomaly detection model 450 ... to keep up with the changing behavior patterns of attackers ... implement a clustering technique that assigns action sequences of suspected attackers to different clusters, where certain clusters are associated with malicious behavior [performed by an attack-driven account or an attack-driven session])
a likelihood that the incrimination action is performed by an account or a session that is not categorized as an attacker-driven account or an attacker-driven session. (Examiner interprets the BRI of at least one of: x, y ... or z to require one of the set to be disclosed to meet the limitation as is disclosed by Holub above)
As per claim 20, Holub in view of Hazony teaches claim 16.
Holub also teaches wherein the method further comprises: detecting an attempt by the user account or the user session to perform the blocked incrimination action; and ([Holub, col. 7, ln. 63-67] “a detected successful attack [detecting an attempt by the user account or the user section to perform the blocked incrimination action] will also trigger an attack mitigation component 152 to initiate mitigation actions for the attack”)
in response to detecting the attempt, automatically and proactively categorizing the user account or the user session as an attacker-driven account or an attacker-driven session. ([Holub, col. 15, ln. 7-9] “initiate mitigation actions to respond to the attack ... the depicted process may be repeated in a loop [in response to detecting the attempt]”; [col. 14, ln. 35-36] “the monitoring system identifies a subset of the attempted attacks as successful attacks based on follow-on benign actions of suspected attackers [automatically and proactively categorizing the user account or the user session as an attacker-driven account or an attacker-driven session]”)
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
More et al. (US Pub. 2017/0279819) discloses detecting an attempt to access a suspicious file (permitting to attempt execution of the incrimination action) where a detection module monitors any attempt to access a file and before permitting a computing device to complete such an attempt, determining whether the file is legitimate and blocking the device from accessing the file (blocking from performing the incrimination action) until the system performs analysis is performed to determine whether the file is trustworthy (permitting a subsequent action). The suspiciousness of the file is identified prior by a third-party resource analyzing the file or the platform that generated the file and identifying the platform is an unverified and/or malicious source (a precursor event).
Bates et al. (US Pub. 2016/0098749) discloses preventing the user/account from obtaining digital media content (incrimination action) when the user performs a precursor action of blocking advertisements. After subsequently viewing the advertisements, the user may then follow the download link again and obtain the content.
Meaburn (US Patent No. 11,743,260) allowing repeated DNS exfiltration attempts to occur so that they can be identified and isolated. A malicious source generates a DNS query which is forwarded to the sinkhole DNS server when it is determined that the address is not identified in the whitelist (precursor action). The source of the DNS query will resubmit the DNS query until either it receives a response or deduces that DNS server timeout has occurred (allowing attempt of the incrimination action while blocking/preventing the exfiltration attempt).
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 ZHE LIU whose telephone number is (571) 272-3634. The examiner can normally be reached on Monday - Friday: 8:30 AM to 5:30 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, Carl Colin can be reached on (571) 272-3862. 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 https://ppair-my.uspto.gov/pair/PrivatePair. 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.
/ZHE LIU/Examiner, Art Unit 2493
Prosecution Insights