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 . 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.
DETAILED ACTION
The following NON-FINAL Office Action is in response to Request for Continued Examination filed on 2/12/2026.
Continued Examination under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 02/12/2026 has been entered.
Status of Claims
Claims 1-10, 13-15, 20, 23-28 are currently pending.
Claims 1, 15, 20 are currently amended.
Claims 11, 12 are previously cancelled.
Claims 16-19, 21, 22 are currently cancelled.
Claims 23-28 are newly added.
Claims 1-10, 13-15, 20, 23-28 are currently under examination and have been rejected as follows.
IDS
The information disclosure statements filed on 04/24/2024, 09/12/2024, 4/9/2026 comply with the provisions of 37 CFR 1.97, 1.98 and MPEP § 609 and is considered by the Examiner.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Response to Amendment
The previously pending rejections under 35 USC 101 will be maintained. The 101 rejection is updated in view of the amendments.
The previously pending rejections under 35 USC 103 will be maintained. The 103 rejection is updated in view of the amendments.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Response to Arguments
Regarding Applicant’s remarks pertaining to 35 USC 101:
Step 2A Prong One:
Applicant argues on page 13 of remarks 2/12/2026:
“The Office Action alleges that the claims are directed to "mitigating risk" under the "Certain Methods of Organizing Human Activity" enumerated grouping. Applicant respectfully disagrees. When considered as a whole, the claims are not directed to an abstract idea, but rather toward a specific technological improvement in cybersecurity incident response tracking and visualization….
“Specifically, how the platform automatically collects data without user prompting, generates a specific graphical representation, and causes automated progression through that representation in response to selection of a play button. The characterization in the Office Action that the claims are directed to "mitigating risk" improperly abstracts away the specific technical features recited in the claims, and goes against the Federal Circuit's guidance in Enfish, LLC v. Microsoft Corporation ("describing the claims at such a high level of abstraction and untethered from the language of the claims all but ensures that the exceptions to § 101 swallow the rule").
Examiner respectfully disagrees. The claims as amended recite, describe or set forth identifying potentially threatening cyber events, matching them to protective actions, and documenting and communicating a timeline of an incident response lifecycle from beginning to end for a customer (also see Applicant specification ¶ [0003]), which fall within mitigating risk as it pertains to fundamental economic principles and business relations as they pertain to commercial or legal interactions, each under the broader abstract grouping of Certain Methods of Organizing Human Activity (MPEP 2106.04(a)(2) II).
Step 2A Prong Two:
Applicant argues on page 15 of remarks 2/12/2026:
“Even assuming, without conceding, that the claims recite an abstract idea at Step 2A, Prong One, the claims integrate any such exception into a practical application at Step 2A, Prong Two….
“Here, the specification identifies a specific technical problem: "[i]t may be difficult, however, to obtain the analysis and/or remediation action information without impairing, hindering, and/or otherwise delaying the analysis process (e.g., by prompting an analyst to record this information), which may, e.g., result in decreased efficiency in the cyber threat remediation process and/or increased prevalence/effectiveness of these cyber threats (e.g., resulting from delays to perform the remediation)." Specification, ¶ [0002]. The specification further describes a specific technical solution: "a software threat that runs in the background of a threat investigator's computer to track the threat work being done and automatically generate reports/logs. This may save the threat investigator time by allowing them to avoid manually preparing a report of a threat investigation after the fact." Specification, ¶ [0027]….
“As amended, claim 1 recites specific technical features that address this problem/solution”.
Examiner respectfully disagrees. The technical solution described in Applicant specification ¶ [0002] and ¶ [0027] above seem to focus on automatic recording of a human analysts actions, in other words a mere automation of a manual process. Improvement to the computer technology itself is unclear from these descriptions or the claims. See MPEP 2106.05(a) I (iii) - Acceptance Corp. v. Westlake Services and LendingTree, LLC v. Zillow, Inc.
Applicant argues on page 17 of remarks 2/12/2026:
“…USPTO Eligibility Example 40. In particular, "the method limits collection of additional Netflow protocol data to when the initially collected data reflects an abnormal condition, which avoids excess traffic volume on the network and hindrance of network performance." US PTO Eligibility Example 40. The example further notes that "[t]he collected data can then be used to analyze the cause of the abnormal condition," which provides a specific improvement over prior systems, resulting in improved network monitoring… Similarly, Applicant's claims provide a specific improvement in collecting incident response information - namely, the system automatically collects investigation information in real time without prompting the analyst to record it, which avoids delaying the remediation process. This provides a specific improvement over prior investigation systems."
Examiner respectfully disagrees. As cited above, Example 40 achieves eligibility by demonstrating technological improvement to the network performance by reducing network volume. While Examiner acknowledges potential improvement in entrepreneurial cybersecurity incident response tracking, particularly reducing or eliminating time consumption due to analyst manual reporting as well as providing real-time observation to clients, improvement to the computer technology itself is unclear.
Applicant argues on page 17 of remarks 2/12/2026:
“The Desjardins memo also cites to SRI Int'l, Inc. v. Cisco Systems, noting that "claims to
detecting suspicious activity by using network monitors and analyzing network packets were found to be an improvement in computer network technology and not directed to an abstract idea."
Desjardins memo, p. 3. Likewise, Applicant's claims are similarly directed to improvements in cybersecurity technology - specifically, the automated tracking and visualization of incident response actions.”
Examiner respectfully disagrees. The SRI v Cisco decision elaborates: “The “focus of the claims is on the specific asserted improvement in computer capabilities”—that is, providing a network defense system that monitors network traffic in real-time to automatically detect large-scale attacks.” While the present invention is analogous in that it concerns cyber threat detection, the claims and specification appear to focus on the automated documentation, presentation, and communication of threat detection and remediation rather than the threat detection and remediation itself.
Applicant argues on page 18 of remarks 2/12/2026:
“In their analysis, the USPTO explains that this claim [claim 1 from USPTO SME Example 23] is patent eligible at step 2A. In particular, they note that "the claim recites dynamically relocating textual information within a window displayed in a graphical user interface based upon a detected overlap condition," and as such, "the claimed method is necessarily rooted in computer technology to overcome a problem specifically arising in graphical user interfaces"… Similar to the example claim, pending claim 1 recites relocating textual/graphical elements within a window displayed in a graphical user interface based on detecting that the time-series representation of the actions performed to address an identified threat has progressed (e.g., based on selection of a play button) to reflect elements not currently displayed on the graphical user interface), and is necessarily rooted in computer technology to overcome a similar problem.”
Examiner respectfully disagrees. While a significant feature of the present claims, the time-series graphical interface does not appear to be directed to a technical problem with user interfaces; rather to solving an entrepreneurial problem of cybersecurity incident response tracking, particularly reducing or eliminating time consumption due to analyst manual reporting as well as providing real-time observation to clients. Dynamic time-series user interfaces are conventional in the field, inter alia the primary and secondary references Bhargava and Atkinson.
Step 2B:
Applicant argues on page 19 of remarks 2/12/2026:
“…the rejection of the claims does not support the conclusion that the actual language of the claims, or the claims as a whole recite a combination of elements that represent well understood, routine, conventional activity widely prevalent or in common use in the relevant industry….
“Here, the combination of: 1) automated collection without prompting the analyst, 2) a play
button causing automated progression, 3) a specific temporal sequence of incident response lifecycle elements, and 4) dynamic real-time updating of the interface represents a non-conventional and non-generic arrangement that provides a technical improvement in cybersecurity incident response tracking.”
Examiner respectfully disagrees. Applicant specification ¶ [0077] discloses conventional technology applied to the automated data collection, process progression, and display rendering. Examiner points to analogous arrangements of said technology in primary and secondary references Bhargava and Atkinson. Further, while Examiner acknowledges potential improvement in entrepreneurial cybersecurity incident response tracking, particularly reducing or eliminating time consumption due to analyst manual reporting as well as providing real-time observation to clients, improvement to the computer technology itself is unclear.
Accordingly, the previously pending rejections under 35 USC 101 will be maintained. The 101 rejection is updated in view of the amendments.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Regarding Applicant’s remarks pertaining to 35 USC 103:
Applicant argues on page 21 of remarks 2/12/2026:
“Accordingly, Atkinson's timeline requires a user to manually select individual elements (e.g., elements A, B, C, D, E, etc.) to update the display. This is fundamentally different than the claimed "play button," which, upon a single selection, causes "automated progression" through the time-series graphical representation (e.g., advancing the representation without further user input). While Atkinson's Figures 5A-5E show forward and backward arrow buttons adjacent to the timeline, Atkinson's specification is silent as to what these buttons do. The only described interaction is the manual selection discussed above, and thus a prima facie case of obviousness
cannot be based on these arrow buttons. Accordingly, Atkinson fails to cure the deficiencies of Bhargava with regard to these features.”
Examiner respectfully disagrees. See additional support for automated progression of display of an incident lifecycle at Bhargava ¶ [0186]: “As illustrated in FIG. 20, an artificial intelligence system may carry out a number of tasks for a particular incident. As the artificial intelligence system progresses through the steps, the progress may be recorded in real time in the user interface 800.” This automated feature in combination with Atkinson’s visualizations and advancement buttons would achieve the claimed functionality.
Applicant argues on page 21 of remarks 2/12/2026:
“Furthermore, claim 1, as amended, recites a specific temporal sequence for displaying incident response lifecycle elements….
“While, Atkinson displays events that threat events on a timeline, the features recited in claim 1 recite a specific order in which graphical elements associated with different incident response lifecycle stages are performed.
“Further, the claim specifically recites that the "alert generated element" is displayed "at a
second point in time ... later than the one or more initial points in time" at which the one or more events are displayed/occurring. Accordingly, the temporal positions on the graphical representation of the events and the alert are different. The same issue pertains to the position of
the "information enrichment element," which is displayed at yet a third time.”
Examiner respectfully disagrees. Examiner points to Atkinson Figs. 5A-5E chronologically progressing through time-series graphical representations displayed as a user presses the play button, dynamically illustrating various “suspicious” cyber threat activities in the graphical representation in a specific temporal order (labelled A through E and time stamped chronologically). See Atkinson ¶ [0215]: “Thus, over time, a significant case will be populated with a time sequence of interrelated events, i.e. events that are potentially related to a common security threat, and as such exhibit a potential threat pattern.” See also Atkinson ¶ [0126], [0243], and [0253].
Applicant argues on page 23 of remarks 2/12/2026:
“Furthermore, claim 1, as amended, recites in part, "wherein the cyber threat investigation
information is collected through a threat framework interface at the enterprise user device configured for automated collection of the cyber threat investigation information in real time as the actions are performed at the enterprise user device, without prompting an analyst operating the enterprise user device to record the cyber threat investigation information… Although Bhargava describes automated process for remediation of the cyber security incident, it does not describe automated recording of the analyst's actions without prompting for manual documentation.”
Examiner respectfully disagrees. See additional support for automating recording of analyst actions without prompting for manual documentation from Bhargava at ¶ [0115]: “One analyst may be assigned a number of different incidents. The analyst may not be aware of the automated tasks being performed. Manual tasks from each of the different incidents may appear as they begin on the analyst's terminal. The analyst may simply perform each one and click complete [EN: without prompt] so that each playbook may continue”; and ¶ [0186]: “…As the artificial intelligence system progresses through the steps, the progress may be recorded in real time [EN: without prompt] in the user interface 800. As the artificial intelligence system finishes a task, the artificial intelligence system may post a message 2000 stating that the task has been completed.”
Accordingly, the previously pending rejections under 35 USC 103 will be maintained. The 101 rejection is updated in view of the amendments.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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-10, 13-15, 20, 23-28 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Claims 1-10, 13-14, 23-28 are directed to a computing platform or machine which is a statutory category.
Claims 15 is directed to a method or process which is a statutory category.
Claim 20 is directed to non-transitory computer-readable media or article of manufacture which is a statutory category.
Step 2A Prong One: The claims recite, describe, or set forth a judicial exception of an abstract idea (see MPEP 2106.04(a)). Specifically, the claims recite, describe or set forth mitigating risk and business relations including: “generation of an enhanced cyber threat analysis framework”, “cyber threat investigation information indicating actions performed to address an identified threat for a client through an incident response lifecycle of the identified threat”, “a request for the cyber threat investigation information”, “events of the incident response lifecycle”, “alert… generated corresponding to the one or more events”, “events… enriched with additional threat information”, “pattern matching… performed for the one or more events to identify the actions”, “a checklist of the actions”, “client communication”, “a dynamic timeline of the incident response lifecycle from birth of the identified threat to resolution of the identified threat”, and “receive… feedback on the incident response lifecycle”. Identifying potentially threatening cyber events, matching them to protective actions, and documenting and communicating a timeline of an incident response lifecycle from beginning to end for a customer fall within mitigating risk as it pertains to fundamental economic principles and business relations as they pertain to commercial or legal interactions, each under the broader abstract grouping of Certain Methods of Organizing Human Activity (MPEP 2106.04(a)(2) II). Accordingly, the claims recite an abstract idea.
Step 2A Prong Two: Independent claims 1, 15, 20 recite the following additional elements: “computing platform”, “processor”, “communication interface”, “memory”, “enterprise user device”, “client user device”, “client interface”, and “non-transitory computer-readable media”. The functions of these additional elements include examples such as “receive, from an enterprise user device, cyber threat investigation information”, “cyber threat investigation information is collected through a threat framework interface at the enterprise user device”, “receive, from a client user device of the client, a request for the cyber threat investigation information”, “generate, using the cyber threat investigation information, a client interface”, and “send, to the client user device, the client interface and one or more commands directing the client user device to cause display of the client interface”. The additional elements are recited at a high level of generality (i.e. as a generic computer performing functions sending and receiving information, generating user interfaces based on the information, and displaying the information) such that they amount to no more than mere instructions to apply the exception using generic computer components. Therefore, these functions can be viewed as not meaningfully different than a business method or mathematical algorithm being applied on a general-purpose computer as tested per MPEP 2106.05(f)(2)(i), generating a second menu from a first menu and sending the second menu to another location as performed by generic computer components as tested per MPEP 2106.05(f)(2)(ii), or requiring the use of software to tailor information and provide it to the user on a generic computer as tested per MPEP 2106.05(f)(2)(v). The claims are directed to an abstract idea and the judicial exception does not integrate the abstract idea into a practical application.
Step 2B: According to MPEP 2106.05(f)(1), considering whether the claim recites only the idea of a solution or outcome i.e., the claims fail to recite the technological details of how the actual technological solution to the actual technological problem is accomplished. The recitation of claim limitations that attempt to cover an entrepreneurial and thus abstract solution to an entrepreneurial problem with no technological details on how the technological result is accomplished and no description of the mechanism for accomplishing the result do not provide significantly more than the judicial exception.
Dependent claim 5 recites the additional element “background software thread”. Dependent claim 7 recites the additional elements “scoring algorithms” and “analyst interface”. Dependent claim 8 recites the additional element “second enterprise user device”. Dependent claims 23-24 recite the additional elements “event circle element”, “exclamation triangle element”, “brain element”, “bracket element”, “clipboard element”, “group of people [element]”, and “protection shield element”. Dependent claims 26 recites the additional element “incident response documentation software”. The additional elements are also recited at a high level of generality (i.e. as a generic computer performing functions of receiving selections, compiling information, scoring events, displaying information, recording actions, etc.) such that they amount to no more than mere instructions to apply the exception using generic computer components.
Further, dependent claims 2-4, 6, 9, 13-19, 25-28 merely incorporate the additional elements recited in claims 1, 15, 20 along with further narrowing of the abstract idea of claims 1, 15, 20 along with their execution of the abstract idea. Specifically, dependent claims narrow the computing platform, processor, communication interface, memory, enterprise user device, client user device, client interface, non-transitory computer-readable media, background software thread, scoring algorithms, second analyst interface, and second enterprise user device to capabilities such as display, receive, identify, indicate, compile, generate, send, shift, and update various forms of data such as alerts, events, enrichment information, graphical representations, graphical elements, timelines, intelligence, incidents, actions, addresses, domains, users, files etc. which, when evaluated per MPEP 2106.05(f)(2) represent mere invocation of computers to perform existing processes. Therefore, the additional elements recited in the claimed invention individually and in combination fail to integrate a judicial exception into a practical application (Step 2A prong two) and for the same reasons they also fail to provide significantly more (Step 2B). Thus, claims 1-10, 13-15, 20, 23-28 are reasoned to be patent ineligible.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
REJECTIONS BASED ON PRIOR ART
Examiner Note: Some rejections will contain bracketed comments preceded by an “EN” that will denote an examiner note. This will be placed to further explain a 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 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-10, 13-15, 20, 25, 27-28 are rejected under 35 U.S.C. 103 as being unpatentable over:
Bhargava US 20200067985 A1 hereinafter Bhargava in view of
Atkinson et al. US 20210250365 A1 hereinafter Atkinson. As per,
Regarding Claims 1, 15, 20: Bhargava teaches:
“A computing platform for generation of an enhanced cyber threat analysis framework, the computing platform comprising: at least one processor; a communication interface communicatively coupled to the at least one processor; and memory storing computer-readable instructions that, when executed by the at least one processor, cause the computing platform to: (claim 1)” (see Bhargava Fig.1 and related text)
“A method for generation of an enhanced cyber threat analysis framework, the method comprising: at a computing platform comprising at least one processor, a communication interface, and memory: (claim 15)” (see Bhargava Fig.1 and related text)
“One or more non-transitory computer-readable media storing instructions that, when executed by a computing platform, comprising at least one processor, a communication interface, and memory, and configured to perform a method for generation of an enhanced cyber threat analysis framework, cause the computing platform to: (claim 20)” (see Bhargava Fig.1 and related text)
“receive (claims 1, 20) / receiving (claim 15), from an enterprise user device, cyber threat investigation information indicating actions performed to address an identified threat for a client through an incident response lifecycle of the identified threat” (Bhargava Figs. 19-22 show real-time updates of actions performed to address an identified threat for a client. ¶ [0050]: when a cyber-security incident occurs, a security analyst may use one window on his or her personal computer to run investigation commands, another window to converse with fellow analysts, and a third window to document IR [incident response] processes [EN: lifecycle] and logs. Using a system as described herein, a security analyst may use a single window to run investigation commands, converse with fellow analysts, and to document the process [EN: incident response lifecycle]. ¶ [0092]: When details of a potential cyber security threat are received by a security operation platform, the security operation platform may begin a process of analysis of the potential threat. The process of analyzing the potential threat may begin by selecting a playbook from memory. One or more local databases accessible by a security operation platform may be capable of storing a number of playbooks in memory. A playbook may comprise a series of tasks [EN: actions]. In some embodiments, a playbook may comprise a workflow for security analysts [EN: enterprise users] working with automated processes during a cyber security incident. A playbook may comprise a mix of both manual and automated processes or tasks),
“wherein the cyber threat investigation information is collected through a threat framework interface at the enterprise user device configured for automated collection of the cyber threat investigation information in real time as the actions are performed at the enterprise user device, without prompting an analyst operating the enterprise user device to record the cyber threat investigation information” (Bhargava ¶ [0115]: One analyst may be assigned a number of different incidents. The analyst may not be aware of the automated tasks [EN: actions] being performed. Manual tasks from each of the different incidents may appear as they begin on the analyst's terminal [EN: enterprise user device]. The analyst may simply perform each one and click complete so that each playbook may continue. ¶ [0119]: …an analyst creating or editing a playbook may be assisted by the security platform pre-calculating possible tasks and flows for the playbook. Real-time calculations of the path may be made as the playbook is edited. Pre-filtering the list of options available for the user to choose based on real-time path calculation in the playbook may enable a more efficient workflow to be created. [Also see Fig. 5A and related text]. ¶ [0115]: One analyst may be assigned a number of different incidents. The analyst may not be aware of the automated tasks being performed. Manual tasks from each of the different incidents may appear as they begin on the analyst's terminal. The analyst may simply perform each one and click complete [EN: without prompt] so that each playbook may continue. ¶ [0186]: …As the artificial intelligence system progresses through the steps, the progress may be recorded in real time [EN: without prompt] in the user interface 800. As the artificial intelligence system finishes a task, the artificial intelligence system may post a message 2000 stating that the task has been completed);
“receive (claims 1, 20) / receiving (claim 15), from a client user device of the client, a request for the cyber threat investigation information” (Bhargava ¶ [0090]: When a user becomes aware of a potential cyber security threat, the user may report the threat to a security operation platform via a form 400 as illustrated in FIG. 4. A form 400 may comprise a user interface displayed on a user device. ¶ [0115]: a user may submit information to a security operation platform providing details on a suspected cyber security threat. ¶ [0123]: When a user request for analysis of a potential security threat is received, or when a potential security threat is detected by a security operation platform, a playbook may be triggered);
“generate (claims 1, 20) / generating (claim 15), using the cyber threat investigation information, a client interface, wherein the client interface includes (Bhargava Figs. 19-22 show real-time updates of actions performed to address an identified threat for client. ¶ [0186]: …As the artificial intelligence system progresses through the steps, the progress may be recorded in real time in the user interface 800. As the artificial intelligence system finishes a task, the artificial intelligence system may post a message 2000 stating that the task has been completed).
Although Bhargava teaches a user interface showing the actions performed to mitigate the threat, it does not explicitly teach the interface having a play button and time series graphical representation. Bhargava also does not explicitly teach “send, to the client user device, the client interface and one or more commands directing the client user device to cause display of the client interface, wherein sending the one or more commands directing the client user device to cause display of the client interface causes the client user device to cause display of the client interface”.
However, Atkinson in analogous art of cybersecurity threat analysis teaches or suggests “generate (claims 1, 20) / generating (claim 15), using the cyber threat investigation information, a client interface, wherein the client interface includes a time-series graphical representation (See Atkinson Figs. 5-5E illustrating a time bar, forward and backward buttons, and time stamps comprising a time-series graphical representation of events, and related text. ¶ [0252]: FIG. 5 shows an example of a page rendered by the case UI 126 at the analyst device 130. A list of cases 502 is shown, each of which is selectable to view further details of the case in question… Further details of the currently selected case are shown in a region 508 adjacent to the case list 502. In particular, a timeline 510 of the events on which the case is based is shown. That is, the events with which the case is populated in the experience database 124. ¶ [0253]: As shown in FIGS. 5A through 5E, the timeline 510 comprises selectable elements corresponding to the underlying events, which are labelled 510a to 510e respectively. This can be seen, selecting these timeline elements causes the accompanying graphical representation 512 to be updated to focus on the corresponding network components. The widgets below the timeline are also updated to show the information that is most relevant to the currently selected timeline element),
“and causes a first portion of the time-series graphical representation to shift off the client interface and a second portion of the time-series graphical representation to shift on to the client interface, wherein actions represented in the first portion occurred prior to actions represented in the second portion, wherein generating the client interface includes dynamically updating the client interface in real time throughout the incident response lifecycle, and wherein updating the client interface includes updating the time-series graphical representation” (See Atkinson Figs. 5A-5E chronologically progressing through individual time-series graphical representations as a user presses the play button, dynamically illustrating various “suspicious” cyber threat activities in the graphical representation. The transition between each instance on the timeline involves removing at least one graphical illustrative portion and replacing it with at least one other portion); “and
“send (claims 1, 20) / sending (claim 15), to the client user device, the client interface and one or more commands directing the client user device to cause display of the client interface, wherein sending the one or more commands directing the client user device to cause display of the client interface causes the client user device to cause display of the client interface (Atkinson ¶ [0093]: Each case may be populated with data of the event or events associated with it. ¶ [0094]: The common case may be rendered accessible via a case user interface, in response to the threat score for one of the cases meeting a significance condition, rendering that case accessible via a case interface),
“wherein displaying the client interface includes displaying the automated progression through the time-series graphical representation comprises, in response to the selection of the play button:
“initially displaying one or more events of the incident response lifecycle at one or more initial points in time on the time-series graphical representation” (See Atkinson Figs. 5-5E illustrating a time bar, forward and backward buttons, and time stamps comprising a time-series graphical representation of events, and related text),
“displaying, after displaying the one or more events and at a second point in time on the time-series graphical representation, later than the one or more initial points in time, an alert generated element, indicating that an alert has been generated corresponding to the one or more events” (See Atkinson Figs. 5-5E illustrating a time bar, forward and backward buttons, and time stamps comprising a time-series graphical representation of alerts, and related text. Also see threat feed in left column in Figs. 5-5E), “and
“displaying, after displaying the alert generated element and at a third point in time on the time-series graphical representation, later than the second point in time, an information enrichment element, indicating that the one or more events have been enriched with additional threat information” (Atkinson ¶ [0255]: Returning to FIG. 1, micro services 138 are provided, from which enrichment data can be obtained, both by the batch enrichment framework 134 (second stage enrichment) and the enrichment component 110 (first stage enrichment). These can for example be cloud services which can be queried based on the events to obtain relevant enrichment data. The enrichment data can be obtained by submitting queries to the micro services based on the content of the events. For example, enrichment data could be obtained by querying based on IP address (e.g. to obtain data about IP addresses known to be malicious), file name (e.g. to obtain data about malicious file names) etc. ¶ [0257]: In addition to the case UI 126, a “hunting” UI 140 is provided via which the analyst can access recent events from the message queue 106. These can be events which have not yet made it to the observation delay line 116, but which have been subject to first stage enrichment and correlation at the event enhancement system 108)”.
Atkinson and Bhargava are found as analogous art of cybersecurity threat analysis. It would have been obvious to one skilled in the art, before the effective filing date of the invention, to have modified Bhargava’s interactive and intelligent cybersecurity system to have included Atkinson’s teachings around threat analysis performed with a time series graphical representation of events and subsequent event enrichment information; and displaying events in the incident response lifecycle, alerts corresponding to the events, information enrichment about the events. The benefit of these additional features would have provided deeper analysis a more comprehensive view of potential threats to analysts (Atkinson ¶ [0013, 0017]). The predictability of such modifications and/or variations, would have been corroborated by the broad level of skill of one of ordinary skills in the art as articulated by Bhargava in view of Atkinson (see MPEP 2143 G).
Further, the claimed invention could have also been viewed as a mere combination of old elements in a similar field of endeavor of cybersecurity threat analysis. In such combination each element would have merely performed same organizational and managerial function as it did separately. Thus, one of ordinary skill in the art would have recognized that, given existing technical ability to combine the elements, as evidenced by Bhargava in view of Atkinson above, the to- be combined elements would have fit together like pieces of a puzzle in a logical, complementary, technologically feasible and/or economically desirable manner. Thus, it would have been reasoned that the results of the combination would have been predictable (see MPEP 2143 A).
Regarding Claims 2, 16: Bhargava / Atkinson teaches all of the limitations of claims 1, 15 above.
Bhargava further teaches:
“displaying, after displaying the pattern matching element and at a fifth point in time (See Bhargava Fig. 5E with checklists for pending tasks and completed tasks, Fig. 11 showing Malware Playbook actions, Fig. 20 showing dynamically updating tasks with time stamps, and related text); “and
“displaying, after the client communication element and at a seventh point in time (See Bhargava Figs. 8-23 showing the timeline of the incident response life cycle on the user interface, and related text. See Fig. 1 showing both remote users and local users with access to the communication subsystem and user interface. ¶ [0085]: …An exemplary incident data entry 382 may comprise a number of data fields including, but not limited to, an incident identifier, time stamps relating to incident creation, detection, and completion, known client devices affected by the incident, known networks affected by the incident, contact information associated with the one or more users reporting the incident, a rating of severity of the incident, an owner of the incident, an identification of a device associated with the owner of the incident, one or more experts associated with one or more tasks associated with the incident, one or more playbooks associated with the incident, one or more other incidents associated with the incident ,one or more details of the incident, any other fields as may be defined by a user or customer, etc.).
Although Bhargava addresses a dynamically updating checklist of actions, a protective actions element, and displaying the lifecycle to both analyst and client, Bhargava does not explicitly teach the “time series graphical representation” for the analyst and client as indicated with strikethroughs above.
Bhargava also does not explicitly teach displaying events in the incident response lifecycle, pattern matching identification, or a client communication element indicator.
However, Atkinson in analogous art of cybersecurity threat analysis teaches or suggests the “time series graphical representation” (See Atkinson Figs. 5-5E illustrating a time bar, forward and backward buttons, and time stamps comprising a time-series graphical representation of events, and related text).
Further, Atkinson teaches or suggests “The computing platform of claim 1 (claim 2) / the method of claim 15 (claim 16), wherein the automated progression through the time-series graphical representation comprises, in response to the selection of the play button:
“displaying, after displaying the information enrichment element and at a fourth point in time on the time-series graphical representation, later than the third point in time, a pattern matching element, indicating that pattern matching has been performed for the one or more events to identify the actions” (Atkinson ¶ [0238]: This can involve matching a received event or sets of events to known tactics that are associated with known types of attack (attack techniques). Within the analysis engine 118, a plurality of analysis modules ("analytics") are provided, each of which queries the events (and possibly other data) to detect suspicious activity. Each analytics
associated with a tactic and technique that describes respective activity it can find); “and
“displaying, after displaying the checklist and at a sixth point in time on the time-series graphical representation, later than the fifth point in time, a client communication element indicating that the client has been notified of one or more of: the one or more events, the additional threat information, the pattern matching, the actions, and the checklist” (See Atkinson Figs. 5-5E threat feed column indicators “dismiss”, “actioned”, and flag icons indicating status of communication to the user).
Atkinson and Bhargava are found as analogous art of cybersecurity threat analysis. It would have been obvious to one skilled in the art, before the effective filing date of the invention, to have modified Bhargava’s interactive and intelligent cybersecurity system to have included Atkinson’s teachings around threat analysis performed with a time series graphical representation of events, the incident response lifecycle, pattern matching identification, or a client communication element indicator. The benefit of these additional features would have provided deeper analysis a more comprehensive view of potential threats to analysts (Atkinson ¶ [0013, 0017]). The predictability of such modifications and/or variations, would have been corroborated by the broad level of skill of one of ordinary skills in the art as articulated by Bhargava in view of Atkinson (see MPEP 2143 G).
Further, the claimed invention could have also been viewed as a mere combination of old elements in a similar field of endeavor of cybersecurity threat analysis. In such combination each element would have merely performed same organizational and managerial function as it did separately. Thus, one of ordinary skill in the art would have recognized that, given existing technical ability to combine the elements, as evidenced by Bhargava in view of Atkinson above, the to- be combined elements would have fit together like pieces of a puzzle in a logical, complementary, technologically feasible and/or economically desirable manner. Thus, it would have been reasoned that the results of the combination would have been predictable (see MPEP 2143 A).
Regarding Claims 3, 17: Bhargava / Atkinson teaches all of the limitations of claims 1, 15 above.
Bhargava further teaches “The computing platform of claim 1 (claim 3) / the method of claim 15 (claim 17), wherein the memory stores additional computer readable instructions that, when executed by the at least one processor, cause the computing platform to: (claim 3) / further comprising (claim 17):
“receive (claim 3) / receiving (claim 17), from the client user device, client identification information” (Bhargava ¶ [0076]: A data packet, or incident identifier, 300 may comprise data such as associated user information 303 for users associated with the incident. For example, the user requesting the cyber security analysis may automatically be added as an associated user. Information identifying the requesting user may be a user ID, an email address, a device IP address, a phone number, etc. Other data associated with an associated user may be saved within the incident identifier, or may be saved in a database accessible to a cyber security analyst. For example, an associated user information filed may be a user ID which may be used by a cyber security analyst (or by a security operation platform ) to look up additional user information, such as a phone number, email address , list of associated devices , etc.); “and
“identify (claim 3) / identifying (claim 17), based on the client identification information, a corresponding view of the client interface, wherein sending the one or more commands directing the client user device to cause display of the client interface causes the client user device to cause display of the corresponding view of the client interface” (Bhargava ¶ [0090]: When a user becomes aware of a potential cyber security threat, the user may report the threat to a security operation platform via a form 400 as illustrated in FIG. 4. A form 400 may comprise a user interface displayed on a user device. In some embodiments, a form 400 may provide entry blanks for a user to fill out descriptions of a number of attributes associated with a potential cyber security threat. Information entered into a form 400 may be used to automatically create an entry in a database as illustrated in FIG. 3B).
Regarding Claims 4, 18: Bhargava / Atkinson teaches all of the limitations of claims 3, 17 above.
Bhargava further teaches “The computing platform of claim 3 (claim 4) / the method of claim 17 (claim 18), wherein the client identification information indicates a client type” (Bhargava ¶ [0081]: An incident identifier 300 may also comprise data associated with associated IP addresses 318. For example, each of the known affected devices may be associated with an IP address. Such IP addresses may be listed in the associated IP address 318 field. Other IP addresses may also be listed. Each IP address may also be tagged with additional information, such as “affected device”, “first affected device”, etc. The IP addresses may belong to any network device (or group of network devices) belonging to the local network. [0130]: As an example, one playbook may be designed to send an email to all users of a particular type of client device alerting those users to a potential security threat).
Regarding Claims 5, 19: Bhargava / Atkinson teaches all of the limitations of claims 1, 15 above.
Bhargava further teaches “The computing platform of claim 1 (claim 5) / the method of claim 15 (claim 19), wherein the cyber threat investigation information comprises a report, automatically compiled by a background software thread during the incident response lifecycle” (Bhargava ¶ [0199]: Reports may be run upon a command from a user scheduled for a particular future date, scheduled for a repeating schedule [EN: thus compiling automatically], or may be shared with other users. The reports user interface 2700 may allow a user to search among the currently existing reports or to create a new report. ¶ [0072]: Similarly, emails may be automatically drafted and sent by the security operation platform 106 in some embodiments…. ¶ [0083]: …In some embodiments, a security operation platform may automatically add notes based on analysis. [Also see Fig. 27 and related text]).
Regarding Claim 6: Bhargava / Atkinson teaches all of the limitations of claim 5 above.
Bhargava further teaches “The computing platform of claim 5, wherein the cyber threat investigation information is compiled without receipt of user input requesting compilation of the cyber threat investigation information” (Bhargava ¶ [0073]: The security operation platform 106 may be capable of automatically making a number of machine-to-machine inquiries. For example, if the security operation platform 106 determines certain data is required, the security operation platform 106 may determine a location, e.g. a network location, where such data may be found. The security operation platform 106 may then send a request or poll or otherwise gather such data. ¶ [0074]: In some embodiments , a workflow may begin upon a cyber security event being detected [without user input] or upon a user request).
Regarding Claim 7: Bhargava / Atkinson teaches all of the limitations of claim 1 above.
Bhargava further teaches “The computing platform of claim 1, wherein the memory stores additional computer readable instructions that, when executed by the at least one processor, cause the computing platform to:
“receive, from the enterprise user device, a request to view threat intelligence information” (Bhargava ¶ [0173]: After entering a command in the text box 812 and hitting a send button 815, the command may be displayed in the window 806 to be viewable by any other security analysts working on the incident. ¶ [0174] One such command may be to request a display 1100 of steps to be performed in accordance with a playbook related to the incident);
“generate, using proprietary intelligence, data aggregation, and scoring algorithms, an analyst interface” (Bhargava ¶ [0165]: In some embodiments, an incident may be associated with an interactive user interface 800 as illustrated in FIG. 8. The interactive user interface 800 may be accessible by multiple users, or security analysts. ¶ [0166] The interactive user interface 800 may comprise a text field 803 identifying an associated incident. The interactive user interface 800 may comprise a window 806 which may be used to display a number of entries 809 from one or more users and / or artificial intelligence bots. The interactive user interface 800 may be similar to an Internet relay chat application layer protocol. Each user interface 800 may be associated with a particular cyber security incident. ¶ [0082]: An incident identifier 300 may also comprise data associated with a severity level 321 [score]… the severity level maybe set automatically by a security operation platform. ¶ [0075]: All known information associated with a particular cyber security event may be collected. Such information may be used to generate an incident identifier. An incident identifier may comprise a data packet, csv file, etc. and may be used as a database of all known information associated with the particular cyber security event.); “and
“send, to the enterprise user device, the analyst interface and one or more commands directing the enterprise user device to display the analyst interface, wherein sending the one or more commands directing the enterprise user device to display the analyst interface causes the enterprise user device to display the analyst interface, wherein the analyst interface is configured to enable the incident response lifecycle” (Bhargava ¶ [0168]: As one or more analysts work through the process of resolving a cyber-security incident [incident response lifecycle], any steps taken by an analyst may be recorded in the user interface 800. ¶ [0165]: In some embodiments, an incident may be associated with an interactive user interface 800 as illustrated in FIG. 8. The interactive user interface 800 may be accessible by multiple users, or security analysts. ¶ [0174]: One such command may be to request a display 1100 of steps to be performed in accordance with a playbook related to the incident. [Also see Fig. 11 and related text]).
Regarding Claim 8: Bhargava / Atkinson teaches all of the limitations of claim 7 above.
Bhargava further teaches “The computing platform of claim 7, wherein the memory stores additional computer readable instructions that, when executed by the one or more processors, cause the computing platform to:
“receive, from a second enterprise user device, a second request for the cyber threat investigation information and information indicating that the second enterprise user device is operated by an analyst” (Bhargava ¶ [0184]: When a security analyst sends a message 1800 including a command as illustrated in FIG. 18, an artificial intelligence system may respond with a message 1803 showing the command has been received. The message 1803 from the artificial intelligence system may be displayed in the user interface 800 for any security analysts to view);
“identify, based on the information indicating that the second enterprise user device is operated by the analyst, a corresponding view of the analyst interface, different than a view of the analyst interface displayed at the enterprise user device” (Bhargava ¶ [0183]: The user interface 800 may allow for a number of security analysts to communicate. For example, a message 1500 may be sent by a first security analyst from a first terminal and may be read by a second security analyst at a second terminal. The second security analyst may respond with a message 1700 as illustrated in FIG. 17. The messages 1500, 1700 may be analyzed by an artificial intelligence system); “and
“send, to the second enterprise user device, the analyst interface and one or more commands directing the second enterprise user device to display the analyst interface, wherein sending the one or more commands directing the second enterprise user device to display the analyst interface causes the second enterprise user device to display the corresponding view of the analyst interface” (Bhargava ¶ [0219]: determining the second cyber-security analyst is not associated with the user interface; and based on the determination that the second cyber-security analyst is not associated with the user interface, associating the second cyber-security analyst with the user interface).
Regarding Claim 9: Bhargava / Atkinson teaches all of the limitations of claim 7 above.
Bhargava further teaches “The computing platform of claim 7, wherein the memory stores additional computer readable instructions that, when executed by the one or more processors, cause the computing platform to:
“automatically execute, based on historical cyber threat investigation information corresponding to one or more analysts, one or more actions of the incident response lifecycle” (Bhargava ¶ [0092]: A playbook may comprise a mix of both manual and automated processes or tasks. ¶ [0093]: A task in a playbook is typically any piece of an action that could be automated or scripted. ¶ [0168]: The window 604 may further comprise one or more popularly chosen new tasks based on one or more tasks previously performed on the current incident based on tasks performed by one or more analysts working on similar tasks in the past. ¶ [0169]: Using a user interface 800 as described herein in conjunction with an artificial intelligence bot, a highly efficient way of saving records of cyber-security incident resolutions and of learning from past cyber-security incident resolutions may be established as described herein).
Regarding Claim 10: Bhargava / Atkinson teaches all of the limitations of claim 7 above.
Bhargava further teaches “The computing platform of claim 7, wherein the analyst interface includes client identifiers and the corresponding cyber threat investigation information, wherein the corresponding cyber threat investigation information includes one or more of: corresponding addresses, domains, users, processes, or files” (Bhargava ¶ [0076]: A data packet, or incident identifier, 300 may comprise data such as associated user information 303 for users associated with the incident. For example, the user requesting the cyber security analysis may automatically be added as an associated user. Information identifying the requesting user may be a user ID, an email address, a device IP address, a phone number, etc. Other data associated with an associated user may be saved within the incident identifier, or may be saved in a database accessible to a cyber security analyst. For example, an associated user information filed may be a user ID which may be used by a cyber security analyst (or by a security operation platform) to look up additional user information, such as a phone number, email address, list of associated devices, etc. ¶ [0180]: An artificial intelligence system may actively monitor any input into a user interface 800. The artificial intelligence system may be capable of identifying data entered in the user interface 800 as evidence and use data identified as evidence to build an evidence file. Each incident may be associated with an evidence file. An evidence file may comprise a list of information and attached files relating to an investigation of a particular incident ¶ [0181]: An artificial intelligence system may further be capable of identifying other actionable items entered by a security analyst into the text box 812 and sent to the user interface 800. For example, as illustrated in FIG. 15, a security analyst may send a message 1500 to another analyst requesting a task to be performed or some piece of information to be gathered. Such a message 1500 may comprise information such as an IP address, a URL, or other identifiable information. An artificial intelligence system may be capable of identifying such identifiable information and performing an action).
Regarding Claim 11: claim 11 is cancelled.
Regarding Claim 12: claim 12 is cancelled.
Regarding Claim 13: Bhargava / Atkinson teaches all of the limitations of claim 1 above.
Bhargava further teaches “The computing platform of claim 1, wherein the memory stores additional computer readable instructions that, when executed by the one or more processors, cause the computing platform to:
“receive, from the client user device and via the client interface, feedback on the incident response lifecycle” (Bhargava ¶ [0185]: Commands [feedback] entered into the user interface 800 may be interpreted and carried out by an artificial intelligence system…);
“update, based on the feedback, an analyst interface configured to display remaining actions to be performed within the incident response lifecycle” (Bhargava ¶ [0185]: …As illustrated in FIG. 19, after performing a commanded task [action], the artificial intelligence system may display results of the task in the user interface 800 in the form of a message 1900…); “and
“send, to the enterprise user device, the updated analyst interface and one or more commands directing the enterprise user device to display the updated analyst interface, wherein sending the one or more commands directing the enterprise user device to display the updated analyst interface causes the enterprise user device to display the updated analyst interface” (Bhargava ¶ [0185]: …This process of displaying commands, displaying responses, and displaying communications between members of an investigation team for a particular incident, results in a fully transparent system of analyzing security threats. This transparent system may be used by future analysts when confronted by a similar incident).
Regarding Claim 14: Bhargava / Atkinson teaches all of the limitations of claim 1 above.
Bhargava does not explicitly teach the time series graphical representation including analyst findings, investigation information, enrichment information, or events corresponding to analyst findings.
However, Atkinson in analogous art of cybersecurity threat analysis teaches or suggests “The computing platform of claim 1, wherein the time-series graphical representation includes one or more of: analyst findings, investigation information, enrichment information of the analyst findings, and events corresponding to the analyst findings” (Atkinson ¶ [0252]: …Further details of the currently selected case are shown in a region 508 adjacent to the case list 502. In particular, a timeline 510 of the events on which the case is based is shown. That is, the events with which the case is populated in the experience database 124. In addition, a graphical illustration 512 of network components to which those events relate is shown in association with the timeline 510. This can, for example, include endpoints, infrastructure components, software components and also external components which components of the network are in communication with. Additional information that is relevant to the case is also shown, including a threat summary 514 that provides a natural language summary of the threat to which the case relates. [Also see Fig. 5 and related text]).
Rationales to have modified / combined Bhargava / Atkinson are above and reincorporated.
Regarding Claim 21: Bhargava / Atkinson teaches all of the limitations of claim 19 above.
Although Bhargava teaches automatically compiling cyber threat information, Bhargava does not specifically teach doing so without prior user input.
However, Atkinson in analogous art of cybersecurity threat analysis teaches or suggests “wherein the cyber threat investigation information is compiled without receipt of user input requesting compilation of the cyber threat investigation information” (Atkinson ¶ [0017]: The linking together of network and endpoint events has been found to provide a powerful basis for automated cyber defence analysis, due to the fact that threats often manifest themselves on both the network and the endpoints. ¶ [0264]: Accompanying FIG . 7 shows a highly schematic block diagram for an event processing scenario. An event 804 is received at an event processing component 802. A function performed by the processing component 802 is one of automatically [EN: without user input] associating relevant external reconnaissance data with the received event 804. The processing component 802 determines that the event 804 is associated with an internal port in a listening state. For example, the generated in response to the port entering a listening state (i.e. when an internal service started listening on that port). Mid-¶ [0267]: Such an event may be referred to herein as a “reconnaissance - triggered network event”).
Atkinson and Bhargava are found as analogous art of cybersecurity threat analysis. It would have been obvious to one skilled in the art, before the effective filing date of the invention, to have modified Bhargava’s interactive and intelligent cybersecurity system to have included Atkinson’s teachings around compiling cyber threat information without prior user input. The benefit of these additional features would have provided deeper analysis a more comprehensive view of potential threats to analysts (Atkinson ¶ [0013, 0017]). The predictability of such modifications and/or variations, would have been corroborated by the broad level of skill of one of ordinary skills in the art as articulated by Bhargava in view of Atkinson (see MPEP 2143 G).
Further, the claimed invention could have also been viewed as a mere combination of old elements in a similar field of endeavor of cybersecurity threat analysis. In such combination each element would have merely performed same organizational and managerial function as it did separately. Thus, one of ordinary skill in the art would have recognized that, given existing technical ability to combine the elements, as evidenced by Bhargava in view of Atkinson above, the to- be combined elements would have fit together like pieces of a puzzle in a logical, complementary, technologically feasible and/or economically desirable manner. Thus, it would have been reasoned that the results of the combination would have been predictable (see MPEP 2143 A).
Regarding Claim 22: Bhargava / Atkinson teaches all of the limitations of claim 15 above.
Bhargava further teaches:
“receiving, from the enterprise user device, a request to view threat intelligence information” (Bhargava ¶ [0090]: When a user becomes aware of a potential cyber security threat, the user may report the threat to a security operation platform via a form 400 as illustrated in FIG. 4. A form 400 may comprise a user interface displayed on a user device. ¶ [0115]: a user may submit information to a security operation platform providing details on a suspected cyber security threat. ¶ [0123]: When a user request for analysis of a potential security threat is received, or when a potential security threat is detected by a security operation platform, a playbook may be triggered);
[..].
Although Bhargava teaches receiving a request to view threat intelligence information on a user device, Bhargava does not specifically teach rendering and displaying an analyst user interface using intelligence, data aggregation, and scoring algorithms.
However, Atkinson in analogous art of cybersecurity threat analysis teaches or suggests
“generating, using proprietary intelligence, data aggregation, and scoring algorithms, an
analyst interface; and sending, to the enterprise user device, the analyst interface and one or more commands directing the enterprise user device to display the analyst interface, wherein sending the one or more commands directing the enterprise user device to display the analyst interface causes the enterprise user device to display the analyst interface, wherein the analyst interface is configured to enable the incident response lifecycle” (Atkinson ¶ [0093]: Each case may be populated with data of the event or events associated with it. ¶ [0094]: The common case may be rendered accessible via a case user interface, in response to the threat score for one of the cases meeting a significance condition, rendering that case accessible via a case interface. End ¶ [0125]: Another aspect of the invention provides a system that uses data [EN: aggregated] from both endpoint systems and networks as a basis for cybersecurity analysis, for example to [EN: algorithmically] compile and score cases. This may be combined with other information such threat intelligence).
Atkinson and Bhargava are found as analogous art of cybersecurity threat analysis. It would have been obvious to one skilled in the art, before the effective filing date of the invention, to have modified Bhargava’s interactive and intelligent cybersecurity system to have included Atkinson’s teachings around rendering and displaying an analyst user interface using intelligence, data aggregation, and scoring algorithms. The benefit of these additional features would have provided deeper analysis a more comprehensive view of potential threats to analysts (Atkinson ¶ [0013, 0017]). The predictability of such modifications and/or variations, would have been corroborated by the broad level of skill of one of ordinary skills in the art as articulated by Bhargava in view of Atkinson (see MPEP 2143 G).
Further, the claimed invention could have also been viewed as a mere combination of old elements in a similar field of endeavor of cybersecurity threat analysis. In such combination each element would have merely performed same organizational and managerial function as it did separately. Thus, one of ordinary skill in the art would have recognized that, given existing technical ability to combine the elements, as evidenced by Bhargava in view of Atkinson above, the to- be combined elements would have fit together like pieces of a puzzle in a logical, complementary, technologically feasible and/or economically desirable manner. Thus, it would have been reasoned that the results of the combination would have been predictable (see MPEP 2143 A).
Regarding Claim 25: Bhargava / Atkinson teaches all of the limitations of claim 1 above.
Bhargava further teaches:
receive, from the client user device and via the client interface, a selection of an element
on the time-series graphical representation (Bhargava ¶ [0141]: …As can be appreciated, a security analyst terminal user interface 585 may display one or more pending tasks assigned to the security analyst as well as one or more tasks completed by the security analyst. A security analyst at the security analyst terminal may be capable of selecting a pending task and the user interface 585 may display information about the selected task); and
in response to receiving the selection of the element, cause the client user device to display audit logs including a list of completed actions to address the identified threat (Bhargava ¶ [0115] … One analyst may be assigned a number of different incidents. The analyst may not be aware of the automated tasks being performed. Manual tasks from each of the different incidents may appear as they begin on the analyst's terminal. The analyst may simply perform each one and click complete so that each playbook may continue. ¶ [0186]: As the artificial intelligence system progresses through the steps, the progress may be recorded in real time in the user interface 800. As the artificial intelligence system finishes a task, the artificial intelligence system may post a message 2000 stating that the task has been completed).
Regarding Claim 27: Bhargava / Atkinson teaches all of the limitations of claim 1 above.
wherein the automated collection of the cyber threat investigation information causes the cyber threat investigation information to be made visible, in real time, to one or more analysts, including the analyst, and the client, without manual recordation of the cyber threat investigation information by the analyst (Bhargava ¶ [0157]: In some embodiments , a playbook may be selected automatically based on one or more qualities of the incident. ¶ [0186]: As the artificial intelligence system progresses through the steps, the progress may be recorded in real time in the user interface 800. As the artificial intelligence system finishes a task, the artificial intelligence system may post a message 2000 stating that the task has been completed. ¶ [0181]: An artificial intelligence system may further be capable of identifying other actionable items entered by a security analyst into the text box 812 and sent to the user [EN: client] interface 800.).
Regarding Claim 28: Bhargava / Atkinson teaches all of the limitations of claim 1 above.
identify completion of a particular action performed by an analyst operating the enterprise
user device (Bhargava ¶ [0141]: …As can be appreciated, a security analyst terminal user interface 585 may display one or more pending tasks assigned to the security analyst as well as one or more tasks completed by the security analyst); and
store, in real time, an indication of the completion, a timestamp of the completion, and results of the completion, wherein the particular action comprises one or more of: an alert generation action, an information enrichment action, a pattern matching action, a checklist completion action, a client notification action, or a threat remediation action (Bhargava mid-¶ [0141]: Information about the selected task [EN: which maybe be a completed task as stated earlier in the paragraph] may comprise information such as a deadline timestamp for the security analyst to complete the task, a severity of the task, an assigned analyst ID, a task ID, an incident ID, a playbook ID [EN: pattern matching], as well as instructions for completing the task [EN: remediation action] and buttons to input the information needed by the task. The user interface 585 may also allow for a security analyst to input notes associated with completing the task which may be saved in a report associated with the incident [Also see timestamps of completed tasks in Figs. 20-22).
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Allowable Subject Matter
Claims 23-24, 26 are allowable over the prior art in light of the amendments. However, these claims remain rejected under 35 USC 101.
Closest prior art to the invention includes Bhargava US 20200067985 A1, Systems and methods of interactive and intelligent cyber – security; and Atkinson et al. US 20210250365 A1, Cyber defence system. None of the prior art of record, taken individually or in combination, teach or suggest the claim limitations as detailed below:
Claim 23:
[..]
the checklist of the actions is displayed as a clipboard element, wherein checkmarks are
dynamically added to the clipboard element as corresponding actions are completed;
[..]
Claim 24:
the one or more event circle elements are displayed at an initial point on the time-series
graphical representation;
the exclamation triangle element is displayed at the second point on the time-series graphical representation, after the one or more event circle elements and before the brain element;
the brain element is displayed at the third point on the time-series graphical representation, after the exclamation triangle element and before the bracket element;
the bracket element is displayed at the fourth point on the time-series graphical representation, after the brain element and before the clipboard element;
the clipboard element is displayed at the fifth point on the time-series graphical representation, after the bracket element and before the group of people;
the group of people is displayed at the sixth point on the time-series graphical representation, after the group of people and before the one or more protection shield elements; and
the one or more protection shield elements is displayed at the seventh point on the timeseries graphical representation, after the group of people.
Claim 26:
the memory stores additional computer readable instructions that, when executed by the at least one processor, cause the computing platform to:
send, to the enterprise user device, incident response documentation software and one or more commands directing the enterprise user device to install the incident response documentation software, wherein:
the incident response documentation software comprises the background software
thread, and
the background software thread is configured to automatically compile the report
during the incident response lifecyle by recording actions performed at the enterprise user
device to address the identified threat.
Thus, dependent claims 23-24, 26 are objected to as being dependent upon a rejected base claim 1 but would be allowable over the prior art if the allowable limitations above are rewritten in independent form including all the limitations of the base claim 1 and any intervening claims. However, these claims remain rejected under 35 USC 101.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Conclusion
The following art is made of record and considered pertinent to Applicant’s disclosure:
Amsler US 20140259170 A1, Internet security cyber threat reporting system and method.
Bazalgette et al. US 20220224724 A1, Artificial intelligence based analyst as an evaluator.
Beck et al. US 20190260804 A1, Secure communication platform for a cybersecurity system.
Bednash et al. US 20240045964 A1, Cybersecurity active defense and rapid bulk recovery in a data storage system.
Böhm, Fabian, Florian Menges, and Günther Pernul. "Graph-based visual analytics for cyber threat intelligence." Cybersecurity 1.1 (2018): 16.
https://link.springer.com/article/10.1186/s42400-018-0017-4#citeas
Boyer WO 2021171093 A1, Cyber security software for a software-as-a-service factoring risk.
Dominessy et al. US 10868825 B1, Cybersecurity and threat assessment platform for computing environments.
Kashyap et al. US 9092625 B1, Micro-virtual machine forensics and detection.
Lewis US 20220046047 A1, Monitoring and preventing remote user automated cyber attacks.
Lim US 20180324202 A1, System and method for threat incident corroboration in discrete temporal reference using 3D dynamic rendering.
Muddu et al. US 20170063899 A1, Interactive threat geo-map for monitoring computer network security.
Ringlein et al. US 20200401696 A1, Security incident disposition predictions based on cognitive evaluation of security knowledge graphs.
Thomas et al. US 20170063920 A1, Dynamic adaptive defense for cyber-security threats.
Tock et al. US 20220414217 A1, System and method of protecting client computers.
Dames US20200374681A1, Situational awareness systems and methods.
Forte US20210398001A1, Cybersecurity incident response and security operation system employing playbook generation and parent matching through custom machine learning.
Ingalls US20210218649A1, Network security monitoring and correlation system and method of using same.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to REED M. BOND whose telephone number is (571) 270-0585. The examiner can normally be reached Monday - Friday 8:00 am - 5:00 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, Patricia Munson can be reached at (571) 270-5396. 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.
/REED M. BOND/Examiner, Art Unit 3624 April 29, 2026
/HAMZEH OBAID/Primary Examiner, Art Unit 3624