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 .
Response to Amendment / Arguments
Regarding claims rejected under 35 USC 101:
Applicant's arguments have been fully considered but they are not persuasive.
Applicant argues that “[training] cannot practically be performed in the human mind. For example, the human mind is not equipped to train a large language model by adjusting weights based on system log data, as recited in amended independent claim 1. As described in the Specification, "refinement of the identity LLM 226 may include fine tuning, by training the model with training datasets, such as training datasets of system log 227 entries, which may cause one or more weights of the model to be updated or adjusted to improve the model's performance and accuracy with regard to predictions." Specification T [0041]. This process of weight adjustment in machine learning models is a technical process that cannot be performed mentally by humans.”
In response, it is noted that adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely using a computer as a tool to perform an abstract idea is sufficient—see MPEP 2106.05(f). In this case, the limitation “train, using one or more system logs associated with the identity management system, a large language model (LLM) to learn a sequence of system events associated with each user of a plurality of users of the identity management system, wherein training the LLM comprises an adjustment to one or more weights of the LLM” is drawn to training a neural network at the level of generality of adjusting its weights and choosing which data to train on. The choice of data is something that is known in the art to be performed by humans, and the claim does not specify any particular machine for selecting or parsing the logs. Additionally, a neural network is comprised of weights and connections such that training the network involves modifying these aspects (e.g., backpropagation). Thus, the claim limitation can be interpreted as modifying weights in a neural network such as an LLM without any particular machine for doing so. Since the claim scope includes modifying merely a single weight (i.e., “an adjustment to one or more weights of the LLM”), this is considered to be something achievable by a human changing values in a model rather than a computerized process that is beyond a mental process analogue (e.g., a particular backpropagation algorithm that works on millions of nodes). The argued limitation is therefore considered to be a mere computerization of a human-performable process, where the process and computerization are both at a high level of generality.
Applicant further argues that “the human mind is not equipped to perform the specific remediation actions recited in amended independent claim 1, including "performing a single sign-off procedure associated with the user; performing a quarantining procedure associated with one or more resources associated with the detected system event; updating a watchlist with identification information associated with the user; [or] sending, to an administrator associated with the identity management system, a notification of the detected system event associated with the user."” While some of these are technical operations that would overcome the rejection (e.g., “performing a single sign-off procedure associated with the user” or “performing a quarantining procedure associated with one or more resources associated with the detected system event” where the “resource” is a computer resource), only one choice is required by the limitation. The choices include “updating a watchlist with identification information associated with the user” and “sending, to an administrator associated with the identity management system, a notification of the detected system event associated with the user,” which are both abstract limitations respectively drawn to a mental process and certain methods of organizing human activity.
Where Applicant argues that the above-argued limitations an improvement over the art on pages 12-13, it is first noted that the training limitation is substantially drawn to the benefit of training as a concept rather than a particular implementation of a training algorithm. As discussed above, merely selecting input data and adjusting weights is part of training a neural network. The claim is not drawn to a specific algorithm for performing one or both of those functionalities. Instead, it recites the concept of training a neural network at a high level of generality. Likewise, “automatically responding to detected threats in ways that enhance the defensive capabilities of the identity management system” is accomplished at a high level of generality by performing actions such as updating a list or alerting an administrator. The invention is addressing a problem that transcends computing (adjusting model inputs and weights; alerting) rather than improving the functioning of a computer, or an improvement to other technology or a technical field.
Furthermore, the entire claim (except for “wherein the decision model comprises a large language model”) is infringeable by a human-being i) reading training material to create a mental decision model with weights; ii) reading through logs comprising event data and performing determinations according to their trained decision model and policies that ii)(a) identifies a sequence of log-in events, ii)(b) mentally determines a predicted sequence of log-in events that are “normal” or “expected”, ii)(c) compares the actual logged log-in events against the predicted “normal” or “expected” sequence, ii)(d) assigns a risk rating based on whether the actual log-in events match the predicted “normal” or “expected” sequence and how far they deviate, ii)(e) identifying whether the risk rating is “enough” to take action such as notifying their supervisor; and iii) writing or speaking their findings to their supervisor. With specific regard to the “decision model” and “adjusting weights” to learn a sequence of ‘expected’ or ‘normal’ events during log-in, and applicant’s contention that this is not performable in the human mind: The examiner finds this wholly unpersuasive and can provide a simple example that invalidates applicant’s baseless assertions. A fledging IT security administrator can look at, read, and comprehend logs with log-in events (and their sequences) for different operating systems or versions of operating systems. The IT security administrator will be able to identify differences between operating systems and versions of an operating system just based on the sequences within the logs. A “sequence fingerprint”, if you will. If an IT security administrator is then contextually aware what portion of their networked systems use certain operating systems or versions of operating system, then they will “weight” more common example training logs more heavily than the less frequently used ones. For example, if there are 99 Windows OS machines and 1 Linux machine on their network, then when looking at the past-logs to train on and learn the log-in sequences of, they will adjust the weight of the Windows machines’ logs to be much higher than the weight of the logs of the Linux machine, because those will be the most relevant in the future.
Regarding claims rejected under 35 USC 103:
Applicant's arguments have been fully considered but they are not persuasive.
Applicant argues that “Neagu describes performing an anomaly response when a number of actions exceeds a threshold. However, performing a response action after a number of actions exceed a second threshold does not teach or suggest "perform[ing], based at least in part on policy information associated with the identity management system and in response to a determination that the risk level satisfies a threat threshold, a remediation action," as recited in amended independent claim 1. Indeed, if an anomaly score exceeds the first threshold described by Neagu, no anomaly response may be performed.” In response, it is first noted that the argued claim language does not distinguish between first and second thresholds. Instead, it merely requires the risk level “satisfying a threat threshold.” In at least Col. 4, Ll. 16-27 and Col. 11, Ll. 60-Col. 12, Ll. 5 of Neagu, anomaly scores (i.e., risk level) are obtained and it is determined whether to perform a remedial action based on the anomaly scores being sufficient or not. This is considered to be a threshold. Further, Col. 4, Ll. 16-27, Col. 10, Ll. 40-46, and Col. 13, Ll. 57-Col. 14, Ll. 9 of Neagu explicitly recite a threshold associated with performing a remedial action. Either the first or second cited thresholds may satisfy the claimed “threat threshold.”
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-2, 4-6, 8-14, and 16-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. Note that the courts do not distinguish between mental processes that are performed entirely in the human mind and mental processes that require a human to use a physical aid (e.g., pen and paper or a slide rule) to perform the claim limitation (refer to MPEP 2106.04(a)(2)).
Example independent claim 13 recites the following abstract idea limitations: An identity management system, comprising:
cause the identity management system to:
train, using one or more system logs associated with the identity management system, a [model] to learn a sequence of system events associated with each user of a plurality of users of the identity management system, wherein training the [model] comprises an adjustment to one or more weights of the [model] (evaluation as part of a mental process—e.g., the analyst fills out event probabilities for the model based on system log data, where the probabilities serve as weights);
generate, using the [model] and based at least in part on training the [model], a predicted sequence of next system events associated with a user of the identity management system (evaluation and judgement as part of a mental process—e.g., an analyst guessing a user’s next actions based on their previous behavior and using calculated probabilities; if a user always checks their email then logs into their workspace 90% of the time as the next step, then it is a fair guess that they will log into their workspace after checking their email);
compare, using the [model], a detected system event associated with a predicted next system event of the predicted sequence of next system events (observation and evaluation as part of a mental process—e.g., the analyst compares actual events with their predictions; the user may have checked their email and then opened an encryption application, where they previously had a 0% chance of opening said encryption application);
determine, using the [model] and based at least in part on a difference between the detected system event and the predicted next system event, a risk level associated with the detected system event (evaluation and judgement as part of a mental process—e.g., the analyst identifies that the user opening an encryption application is atypical for the user and out of line with their usual routine, and further derives an associated risk level which may be a binary Risk/No Risk determination); and
perform, based at least in part on policy information associated with the identity management system and in response to a determination that the risk level satisfies a threat threshold, a remediation action (observation, evaluation, and judgement as part of a mental process—e.g., the analyst checks a policy book to determine a next course of action for a determination of risk, where the analyst further performs the next course of action according to the policy; the analyst may ask the user what they are doing or inform a superior),
wherein the remediation action comprises: a performance of a single sign-off procedure associated with the user; a performance of a quarantining procedure associated with one or more resources associated with the detected system event; an update of a watchlist with identification information associated with the user (evaluation as part of a mental process—e.g., the analyst writing the user’s name to a list of flagged users); a notification, to an administrator associated with the identity management system (escalating to a superior as part of certain methods of organizing human activity—e.g., the analyst informs an administrator of a detected problem event), of the detected system event associated with the user; or a combination thereof.
Example independent claim 13 recites the following limitations which may comprise additional elements that are sufficient to amount to significantly more than the abstract idea: “one or more memories storing processor-executable code; and one or more processors coupled with the one or more memories and individually or collectively operable to execute the code to [perform the steps of the abstract idea limitations];” the model further comprising “a large language model (LLM).”
With respect to step 2A, the judicial exception is not integrated into a practical application because it is drawn to evaluating the probability of a next action at a high level of generality, and because adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely using a computer as a tool to perform an abstract idea is not considered to be sufficient—see MPEP 2106.05(f). For instance, the claim concerns calculating event probabilities and determining whether an actual event aligns with the calculated event probability. Based on the comparison, a generic remediation action is initiated.
The claim does incorporate using ““a large language model (LLM),” but this is considered to be the equivalent of merely using the LLM as a tool to perform the abstract idea of calculating and checking probabilities. The LLM is specified at a high level of generality (i.e., merely mentioned as being used, where the use can be an analyst querying the LLM in any manner), and the claim is otherwise drawn to evaluating probabilities rather than how the LLM is set up as a particular machine. Where the claim recites “one or more memories storing processor-executable code; and one or more processors coupled with the one or more memories and individually or collectively operable to execute the code to [perform the steps of the abstract idea limitations],” this is considered to merely require implementing the abstract idea on a base level computer (processor and memory). The computer is not otherwise specified in any particular detail.
As such, the invention is addressing a problem that transcends computing (determining event probabilities and checking whether an actual event is the same as an expected event) rather than improving the functioning of a computer, or an improvement to other technology or a technical field.
With respect to step 2B, the claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception because adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely using a computer as a tool to perform an abstract idea is not considered to be sufficient—see MPEP 2106.05(f). In this case, the ““one or more memories storing processor-executable code; and one or more processors coupled with the one or more memories and individually or collectively operable to execute the code to [perform the steps of the abstract idea limitations]” may be interpreted as any generic base level computer (processor and memory) for performing the judicial exception. Merely performing the judicial exception using a base level computer is not considered to be sufficient. Regarding “using a large language model,” this is considered to be using a computer as a tool to perform the abstract idea. In this case, the LLM is being used to help evaluate event probabilities, without otherwise detailing the particular machine of the LLM.
Independent claims 1 and 20 are substantially similar to independent claim 13, and are therefore rejected under the same analysis.
Regarding dependent claim 2, it is considered to merely further specify the abstract idea, and is therefore rejected under the same analysis.
Regarding dependent claim 3, it recites the following abstract idea limitations: training, using one or more system logs associated with the identity management system, the LLM to learn a sequence of system events associated with each user of a plurality of users of the identity management system (evaluation as part of a mental process—e.g., the analyst fills out event probabilities for the model based on system log data). As such, it is rejected under the same analysis.
Regarding dependent claims 4-6, they are considered to merely further specify data evaluated as part of the abstract idea. As such, they are rejected under the same analysis.
Regarding dependent claim 8, it recites the following abstract idea limitations: outputting, to a user interface associated with the identity management system and based at least in part on a determination that the risk level satisfies the threat threshold, a listing of one or more system events associated with the identity management system (posting information within an organization as part of certain methods of organizing human activity—e.g., the analyst posts a list of events potentially indicative of a threat to a bulletin board); and receiving, via the user interface, a user selection to debug a first system event of the one or more system events (posting information within an organization as part of certain methods of organizing human activity—e.g., another organization member selects one of the posted events to focus on by marking it or otherwise relaying the selection to the analyst). As such, claim 8 is rejected under the same analysis.
Regarding dependent claim 9, it recites the following abstract idea limitations: wherein the first system event comprises the detected system event, and wherein the method further comprises: generating, based at least in part on the user selection to debug the detected system event and using the LLM, a summary of system events associated with the user (observation, evaluation, and judgement as part of a mental process—e.g., the analyst reviews events based on the selection and further writes a report with summaries), wherein the summary of system events associated with the user comprises a summary of historical customary behavior associated with the user, a summary of a potential risk associated with the user, a summary of recommendations for remediating a risk associated with the user, or a combination thereof (merely further specifying the data—e.g., what’s written in the summaries). As such, claim 9 is rejected under the same analysis.
Regarding dependent claim 10, it is considered to merely further specify data (what’s written in the summaries in claim 9), and is therefore rejected under the same analysis.
Regarding dependent claims 11-12, they are rejected for substantially the same reasons as claims 8-10 above and under the same analysis. The claim element of “a chat box at the user interface” is interpreted as being part of the same certain methods of organizing human activity as above (e.g., a comments section on information posted to a bulletin board).
Regarding dependent claims 14 and 16-19, they are substantially similar to claims 2 ,4-6, and 8-12 above, and are therefore likewise rejected.
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.
Claim(s) 1-2, 4-6, 8-11, 13-14, and 16-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Neagu (US 12,437,192 B1) in view of Murphy (US 2024/0305651 A1).
Regarding claim 1, Neagu discloses: A method of [a service provider] system (e.g., provider network; Col. 5, Ll. 47-56 of Neagu), comprising:
training, using one or more system logs associated with the [service provider], a [neural network] (e.g., neural network as in FIG. 5 of Neagu; Col. 4, Ll. 41-53 of Neagu) to learn a sequence of system events associated with each user of a plurality of users of the identity management system, wherein training the [neural network] comprises an adjustment to one or more weights (e.g., Col. 12, Ll. 44-Col. 13, Ll. 11 of Neagu concerning a neural network having trained weights) of the [neural network];
Refer to at least Col. 3, Ll. 33-Col. 4, Ll. 15 and Col. 7, Ll. 10-55 of Neagu with respect to training the neural network concerning individual user event sequences using log data.
generating, using the [neural network] and based at least in part on training the [neural network], a predicted sequence of next system events associated with a user of the [service provider] system;
Refer to at least Col. 3, Ll. 54-Col. 4, Ll. 15 of Neagu with respect to the neural network being trained to predict a next event of an input event sequence. Further see at least Col. 7, Ll. 56-60 of Neagu with respect to using the model post-training to predict future events corresponding to users’ event sequences.
comparing, using the [neural network], a detected system event (e.g., Col. 11, Ll. 5-15 and Col. 16, Ll. 10-18 of Neagu) associated with the user to a predicted next system event of the predicted sequence of next system events;
Refer to at least Col. 7, Ll. 60-67 and Col. 11, Ll. 57-67 of Neagu with respect to comparing predicted events to actual events.
determining, using the [neural network] and based at least in part on a difference between the detected system event and the predicted next system event, a risk level associated with the detected system event; and
Refer to at least Col. 4, Ll. 16-21, Col. 7, Ll. 64-Col. 8, Ll. 13, and Col. 11, Ll. 60-Col. 12, Ll. 5 of Neagu with respect to computing an anomaly score based on the comparison. The anomaly score can be per-event or per-short-event-sequence.
performing, based at least in part on policy information (e.g., Col. 8, Ll. 17-25 of Neagu) associated with the [service provider] system and in response to a determination that the risk level satisfies a threat threshold (e.g., Col. 4, Ll. 16-40 of Neagu), a remediation action
Refer to at least Col. 2, Ll. 59-Col. 3, Ll. 2, Col. 8, Ll. 1-34, and Col. 12, Ll. 5-8 of Neagu with respect to deciding whether the anomaly score necessitates a response, and further remediation via response action.
wherein the remediation action comprises: performing a single sign-off procedure associated with the user; performing a quarantining procedure associated with one or more resources associated with the detected system event;
Refer to at least Col. 2, Ll. 65-Col. 3, Ll. 2 of Neagu with respect to example remedial actions (e.g., blocking a user from accessing application resources).
updating a watchlist with identification information associated with the user; sending a notification of the detected system event associated with the user;
Refer to at least Col. 14, Ll. 53-Col. 15, Ll. 13 of Neagu with respect to a report detailing anomalous user behavior.
or a combination thereof.
Although Neagu concerns provider networks generally, and further implements a neural network, it does not explicitly disclose: the service provider further comprising an identity management system; the neural network further comprising a large language model (LLM). Neagu further does not disclose: the remedial action further comprising a quarantining procedure / the remedial action further comprising sending a notification to an administrator associated with the identity management system. Additionally, However, Neagu in view of Murphy discloses: the service provider further comprising an identity management system;
Refer to at least [0101]-[0104] of Murphy with respect to a computing platform including Identity and Access Management (IAM) systems which are associated with monitoring and logging actions (e.g., by an SIEM).
the neural network further comprising a large language model (LLM);
Refer to at least [0396]-[0398] and [0442] of Murphy with respect to LLMs being a type of neural network.
the remedial action further comprising a quarantining procedure (refer to at least [0642] of Murphy with respect to quarantining data received from a given identity) / the remedial action further comprising sending a notification to an administrator associated with the identity management system (refer see at least [0413] of Murphy with respect to reporting suspicious activities to administrators.).
The teachings of Neagu and Murphy both concern event monitoring, threat mitigation, and neural networks, and are considered to be within the same field of endeavor and combinable as such.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Neagu to further implement a large language model, and also to include anomalous activity detection for IAM, because design incentives or market forces provided a reason to make an adaptation (i.e., LLMs being currently popular with consumers and having widespread support; expanding the scope of monitoring to additional services such as IAM), and the invention resulted from application of the prior knowledge in a predictable manner (i.e., implementing a particular type of neural network; monitoring event logs from an additional source). It also would have obvious to implement additional remedial action types because the particular known technique (e.g., quarantining responsive to anomalies; sending a report to an administrator responsive to anomalies) was recognized as part of the ordinary capabilities of one skilled in the art.
Regarding claim 2, Neagu-Murphy discloses: The method of claim 1, further comprising: classifying, using the LLM and based at least in part on the determination that the risk level satisfies the threat threshold, the detected system event as a first threat type of a plurality of threat types;
Refer to at least Col. 9, Ll. 43-Col. 10, Ll. 4 and Col. 4, Ll. 63-Col. 5, Ll. 2 of Neagu with respect to categorizing event actions and further categorizing associated user roles.
determining a first policy configured for the first threat type; and determining, based at least in part on the first policy, the policy information.
Refer to at least Col. 9, Ll. 12-29 of Neagu with respect to flagging differently categorized actions as either anomalous or not depending on the associated user roles.
This claim would have been obvious for substantially the same reasons as claim 1 above concerning the LLM.
Regarding claim 4, it is rejected for substantially the same reasons as claim 3 above (i.e., the citations).
Regarding claim 5, Neagu-Murphy discloses: The method of claim 1, wherein the predicted next system event comprises an indication of a date, a timestamp, a geographical location, an application, an IP address, an event type, an event duration, or a combination thereof of an expected system event.
Refer to at least FIG. 4, Col. 7, Ll. 2-9, Col. 5, Ll. 2-7, and Col. 11, Ll. 28-56 of Neagu with respect to event metadata such as timestamp, timings, user identity, location, and so forth.
Regarding claim 6, it is rejected for substantially the same reasons as claim 5 above (i.e., the citations).
Regarding claim 8, Neagu-Murphy discloses: The method of claim 1, further comprising: outputting, to a user interface associated with the identity management system and based at least in part on a determination that the risk level satisfies the threat threshold, a listing of one or more system events associated with the identity management system; and
Refer to at least Col. 14, Ll. 48-Col. 15, Ll. 13 of Neagu with respect to presenting anomaly analysis to a user via graphical user interface based on obtaining anomaly scores for new events.
receiving, via the user interface, a user selection to debug a first system event of the one or more system events.
Refer to at least Col. 8, Ll. 14-33 of Neagu with respect to additional review and feedback by security experts; initiating a root cause analysis workflow; Col. 14, Ll. 58-64 of Neagu with respect to dynamically updating information about the events via interface.
Refer to at least FIG. 23-24, [0214]-[0217], [0175], and [0185] of Murphy with respect to allowing an analyst to generate revised security-relevant information for an initial report (e.g., “assume that a third-party (e.g., the user/owner/operator of computing platform 60) wishes to execute a search concerning the activity of a specific employee... the third-party (e.g., the user/owner/operator of computing platform 60) may formulate the appropriate unified query (e.g., unified query 262) that defines the employee name, the computing device(s) of the employee, and the date range of interest”).
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Neagu-Murphy to further implement additional interface options for drilling down associated information and revising the report interface for at least the purpose of improving analyst workflow (i.e., to help better review anomalous events). This claim also would have been obvious for substantially the same reasons as claim 1 above concerning the identity management system.
Regarding claim 9, Neagu-Murphy discloses: The method of claim 8, wherein the first system event comprises the detected system event, and wherein the method further comprises: generating, based at least in part on the user selection to debug the detected system event and using the LLM, a summary of system events associated with the user, wherein the summary of system events associated with the user comprises a summary of historical customary behavior associated with the user, a summary of a potential risk associated with the user, a summary of recommendations for remediating a risk associated with the user, or a combination thereof.
Refer to at least [0492], [0503], [0539]-[0541], and [0575]-[0576] of Murphy with respect to providing, using an LLM, a summary of system events (e.g., having recommended remedial actions).
Refer to at least Col. 14, Ll. 64-Col. 15, Ll. 3 of Neagu with respect to easy-to-understand explanations concerning the report.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Neagu-Murphy to further implement using an LLM to summarize associated security information as part of dynamically updating information about the events / revising the report for substantially the same reasons as claim 8 above.
Regarding claim 10, Neagu-Murphy discloses: The method of claim 9, wherein the summary of historical customary behavior associated with the user comprises a summary of customary system events, user activities, devices used, applications accessed, geographical locations, activity times, types of events or activities, periods of inactivity, or a combination thereof.
Refer to at least Col. 14, Ll. 64-Col. 15, Ll. 3 of Neagu, which states that “explanations may, for example, indicate precisely how (in terms of the kinds of actions initiated or resources accessed, the sequence of successive anomalous actions, the timings of the actions, etc.) the user behavior designated as an actionable anomaly differs from the typical behaviors for the category of user involved.”
This claim would have been obvious for substantially the same reasons as claim 8 above.
Regarding claim 11, it is rejected for substantially the same reasons as claim 8 above (i.e., revising the report based on feedback in Murphy; further see at least [0054] of Murphy concerning text-based feedback).
Regarding independent claim 13, it is substantially similar to independent claim 1 above, and is therefore likewise rejected (i.e., the citations and obviousness rationale).
Regarding claims 14 and 16-19, they are substantially similar to claims 2 and 4-9 above, and are therefore likewise rejected.
Regarding independent claim 20, it is substantially similar to independent claim 1 above, and is therefore likewise rejected (i.e., the citations and obviousness rationale).
Claim(s) 12 is/are rejected under 35 U.S.C. 103 as being unpatentable over Neagu-Murphy as applied to claims 1-2, 4-6, 8-11, 13-14, and 16-20 above, and further in view of Andrabi (US 2023/0007023 A1).
Regarding claim 12, Neagu-Murphy discloses: wherein the first system event comprises the detected system event, and wherein the method further comprises: receiving, at a chat box output at the user interface, [feedback];
Refer to at least [0054] and [0503] of Murphy with respect to text-based feedback and feedback such as “I would appreciate a more detailed roadmap for remediation.”
Neagu-Murphy does not specify: the feedback further comprising a user request to perform a second remediation action associated with the detected system event, wherein the second remediation action is different from the remediation action; performing the second remediation action; and updating, based at least in part on feedback indicating the second remediation action, the LLM. However, Neagu-Murphy in view of Andrabi discloses: the feedback further comprising a user request to perform a second remediation action associated with the detected system event, wherein the second remediation action is different from the remediation action; performing the second remediation action; and updating, based at least in part on feedback indicating the second remediation action, the LLM.
Refer to at least 708-714 in FIG. 7, [0029], and [0139] of Andrabi with respect to obtaining administrator interactions concerning a chosen remedial action, and further training the anomaly detection model based on the administrator chosen remedial action.
The teachings of Andrabi likewise concern event monitoring, threat mitigation, and neural networks, and are considered to be within the same field of endeavor and combinable as such.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Neagu-Murphy to further implement using administrator feedback concerning remediation actions to update the model because the particular known technique was recognized as part of the ordinary capabilities of one skilled in the art (i.e., feedback loop).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to VADIM SAVENKOV whose telephone number is (571)270-5751. The examiner can normally be reached 12PM-8PM.
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, Jeffrey L Nickerson can be reached at (469) 295-9235. 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.
/Jeffrey Nickerson/Supervisory Patent Examiner, Art Unit 2432
/V.S/Examiner, Art Unit 2432
