Prosecution Insights
Last updated: October 04, 2026
Application No. 18/548,514

AUTOMATED USER-ASSISTED WORKFLOWS FOR CLOUD-BASED COMPUTER FORENSIC ANALYSIS

Non-Final OA §103§112
Filed
Aug 31, 2023
Priority
Apr 08, 2021 — provisional 63/172,596 +1 more
Examiner
POUDEL, SAMIKSHYA NMN
Art Unit
2436
Tech Center
2400 — Computer Networks
Assignee
Cado Security Ltd.
OA Round
3 (Non-Final)
52%
Grant Probability
Moderate
3-4
OA Rounds
0m
Est. Remaining
99%
With Interview

Examiner Intelligence

Grants 52% of resolved cases
52%
Career Allowance Rate
14 granted / 27 resolved
-6.1% vs TC avg
Strong +78% interview lift
Without
With
+77.8%
Interview Lift
resolved cases with interview
Typical timeline
2y 11m
Avg Prosecution
15 currently pending
Career history
48
Total Applications
across all art units

Statute-Specific Performance

§101
16.2%
-23.8% vs TC avg
§103
56.9%
+16.9% vs TC avg
§102
12.3%
-27.7% vs TC avg
§112
13.8%
-26.2% vs TC avg
Black line = Tech Center average estimate • Based on career data from 27 resolved cases

Office Action

§103 §112
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 . 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/25/2026 has been entered. Response to Amendment In the response filed on 02/25/2026. The applicant amended claims 1-2, 8-9, and 15-16 are amended. No claims were added. Response to Arguments With respect to claims objections: Applicant’ claim amendments and remarks filed on 02/25/2026 have been fully considered and overcame some of the claim objections but do not fully overcome the objections as presented in the final office action filed 12/01/2025. With respect to 35 U.S.C. §102 and 103 rejections: Applicant's arguments filed on 02/25/2026 have been received and entered. Applicant's arguments with respect to the newly amended independent claims, see Applicant Arguments 10-12, with respect to the rejection (s) of independent claims 1,8 and 15 have been fully considered. Applicant argues that Sirianni and Lansford fail to teach “dynamically generating , by automated processing of the forensic data, a workflow of suggested tasks and an order of performance of the suggested tasks,” including analyzing characteristics or attributes of the forensic data to automatically and dynamically determine a number and type of tasks to remediate the security incident. Applicant further characterizes Lunsford’s playbooks as merely “preconfigured or attribute driven user/agent task lists” or procedural checklists that are not dynamically generated computational workflows. The examiner respectfully disagrees with this characterization of Lunsford. Lunsford teaches identifying tasks based on attributes of an incidents. In particular, Lunsford states that the process 1200 “identifies tasks based on the incident” and may identify the incident”, [0134]. Lunsford further teaches that tasks associated with particular incident types, data classification, event types, and combinations can be automatically added to the incident when corresponding attribute values are present, [0137]. Applicant further argue that Lunsford does not dynamically determine the number and type of tasks is also not persuasive. Lunsford teaches that one combination of incident attribute value results in a particular task being added to task list 1312, whereas a different combination of incident attribute values results in many other tasks being added to task list 1362, [0138]. Thus, the particular attributes of an incident determine both which tasks are included and the resulting number of tasks. The claims do not require that the number of tasks be separately represented as an explicit numerical variable. Applicant further characterizes Lunsford’s playbooks as merely “preconfigured or attribute driven user/agent task lists” or procedural checklists rather than dynamically generated workflows. This argument is not persuasive. Although Lunsford states that a playbook may contain a preconfigured set of tasks, Lunsford expressly provides that tasks for responding to an incident may be “assembled (e.g., collected, derived) from the tasks of other playbooks” and that based on the attribute values of an incident, appropriate tasks from other playbooks may be associated with tasks for resolving the incident, [0061]. Thus, under BRI, dynamically generating a workflow encompasses automatically selecting and assembling an incident specific collection of tasks from available tasks; the claims does not require creation of previously nonexistent task definitions. Applicant argues that Lunsford is limited to a fixed procedural checklist is additionally inconsistent with Lunsford’s disclosure that the system may “scan and access events” received from a SEIM to determine an updated risk and that “playbooks and/or tasks can be added, deleted, and changed” to reflect that updated risk, [0108]. Accordingly, Lunsford expressly teaches modification of the incident response task set in response to subsequently assessed security event information. Applicant assertion that Lunsford merely provide tasks for incident response teams is also not persuasive. Lunsford expressly teaches that cyber event tasks may be assigned to an “automated agent” and defines such an agent as “programmed set of instructions that are executable by a processor to accomplish a task”, [0054]. Lunsford reiterates that a task may be assigned to an automated agent and that the task performing user may therefore be either a human or an automated agents. Applicant also argues that Lunsford does not disclose computational task performance. But, Lunsford expressly assigns tasks to processor executable automated agent, [0054, 0124]. Lunsford also describes distributed and cloud computing systems, processing threads, virtual machine instantiations, and operations distributed across multiple processors or physical device, [0030], [0037] [0043]. Examiner agrees that the Lunsford does not explicitly teaches “wherein the group of working resources comprises computing resources to process the number of tasks and the group of working resources is automatically scaled in response to the determined number of tasks, and wherein the computing resources operate in parallel and are released upon completion of their assigned tasks” but are moot because the claim amendment introduces new claim limitations that have not previously been considered. Therefore, the new grounds of rejection under 35 U.S.C. 103 relies on new references in combination as presented below. Claim Objections Regarding claims 1, 8, and 15, Claims 1, 8, and 15 are objected to because of the following informalities: Claim recite “receiving a copy of data from each the computing device and the containerized system which accesses the network”. The phrase “each the computing device” is grammatically improper and is inconsistent with the preceding recitation of “plurality of computing devices and/or containerized systems.” Applicant is required to amend the claim to clearly and grammatically identify the devices and/or systems from which the copy of the data is received. The claims “assigning the number of task and the type of tasks..”. The singular term “task” should be corrected to “tasks”. Appropriate correction is required. Regarding claims 3, 10, and 17, Claims 3, 10, and 17 are objected to because of the following informalities: The claims recite “modifying, deleting and/or acquiring data to the network without authorization”. Applicant is required to review and correct the phrase “acquiring data to the network.” The specification describes a computing device as deleting, modifying or acquiring data from the network in an authorized manner, [0024]. Appropriate correction is required. Regarding claims 4, 11 and 18, Claims 4, 11 and 18 are objected to because of the following informalities: In line 1-2, “the group of resources are scaled” should read “the group of resources is scaled”. Appropriate correction is required. Regarding claims 5, 7, 12, 14, and 19, Claims 5, 7, 12, 14, and 19 are objected to because of the following informalities: The claims recite “a set of tasks correspond to the number of tasks..” the recitation is grammatically improper. Applicant should amend the language, for example, to recite “a set of tasks corresponding to the number of tasks”, if that reflects the intended scope. Appropriate correction is required. Regarding claims 13, 14, and 20, Claims 13, 14, and 20 are objected to because of the following informalities: The claim recite “further comprising “ should read “wherein the operation further comprise”. In claims 13 and 14, “a user based on suspicious login” should read “a user based on the suspicious remote login”. Appropriate correction is required. Claim Rejections - 35 USC § 112 The following is a quotation of 35 U.S.C. 112(b): (b) CONCLUSION. —The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention. The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph: The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention. Claims 1,3, 8, 10, 15, and 17 rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention. Claims 1,8, 15 recites the limitation “wherein the security incident includes unauthorized access of the network has been accessed by an unauthorized computing device”. The limitation doesn’t clearly define the relationship between the security incident, the unauthorized access, and the unauthorized computing device. It is unclear whether the claims require that the security incident comprises unauthorized access to the network by an unauthorized computing device, that processing of the forensic data determines that the network has been accessed by an unauthorized computing device or some other relationship. Claims 1,8, and 15 further recite “processing the number of tasks if it is determining that the unauthorized computing device has accessed the network”. The phrase “it is determining” is unclear because the term “it” lacks a clear antecedent basis and the claims do not otherwise identify what entity or operation performs the recited determination. Furthermore, the phrase does not clearly establish whether the number of tasks is processed while the determination is being made or in response to a determination that the unauthorized computing device has accessed the network. Examiner suggest applicant to clarify the scope of the claims. Dependent claims are also rejected for inheriting the deficiencies set forth above for independent claims. Appropriate correction is required. Claims 3, 10, and 17 recite “determining if the network has been accessed by the unauthorized computing device includes the computing system modifying, deleting and/or acquiring data to the network without authorization” .The term “the computing system” lacks antecedent basis. The claim recite several computing related entities including computing devices, containerized system, computing resources, and an unauthorized computing device, but do not previously introduce “a computing system” corresponding to the subsequently recited “the computing system”. Consequently, it is unclear which entity is alleged to modify, delete, and /or acquire data without authorization. The identity of that entity materially affects the scope of the claimed determination of unauthorized access. Examiner suggest applicant to clarify the scope of the claims. Dependent claims are also rejected for inheriting the deficiencies set forth above for independent claims. Appropriate correction is required. Claim Rejections - 35 USC § 103 In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action: A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made. Claims 1-3, 6-10, 13-17, and 20-21 are rejected under 35 U.S.C. 103 as being unpatentable over Sirianni (US 10885393 B1) in view of Lunsford (US 20200193022 A1) in further view of Choi (US 20180081728 A1). Regarding claim 1, Sirianni teaches computer security method for analyzing forensic data for remediating security incidents in a multi-tenant environment the computer security (Sirianni, performing data analytics using an incident response and monitoring solution (e.g., a Scalable Incident-response and Forensics Toolkit (SIFT)), built for distributed processing, that streamlines cyber defense by unifying datasets, via a data translator, from sensors and tools into a uniform schema to provide real-time anomaly detection, via an anomaly detection system that may prevent malware from establishing a foothold on the network, (Col 1, lines 38-46) In some examples, incident-response system 100 may support for one or more (e.g., thirty or more) concurrent users 118, and may support global network access from users 118 (e.g. cyber defense analysts), see col 7, lines 65-67, Col 8, line 1) method comprising: receiving the forensic data from a network for a tenant of the multi-tenant environment, wherein: the network includes a premises network and/or a cloud network, the network is connected to a plurality of computing devices and/or containerized systems, the receiving of the forensic data includes receiving a copy of data from each the computing device and the containerized systems which accesses the network, the copy of data includes logs of data of the computing device and/or the containerized systems (Sirianni, Inputs into translation module 102 may include data streams 110 which include network traffic 112, device logs, 114, and sensor alerts 116. Data streams 110 may include a sequence (e.g., at a regular predetermined interval) of information in a specific format delivered to a specific input/output (I/O) port of a computer system. Network traffic 112 may include a sequence of network packets or PCAP (packet captures). Device logs 114 may include the logging of information collected by a device and then transmitted to a collection point including, e.g., Syslog, Windows® events, and firewall logs. Sensor alerts 116 may include input data from a sensor that is contained in the system (e.g., a radar output in a Structured Threat Information eXpression (STIX™) format), or from security alerts or breaches detected by, for example, Mandiant® Incident Response tool, Bro network security monitor, and/or Endpoint anti-virus, See (Col 2, lines 43-59) Incident-response system 100 may connect, via communication device 204, to distributed computing system 250. System nodes 252 may comprise constituent devices of distributed computing system 250. …some system nodes 252 may have data relevant to a sub-network (e.g., devices in network enclave 270) and other system nodes 252 (i.e., a premises network and/or a cloud network) may have data relevant to another sub-network. Anomaly detection module 106 may find anomalies within each sub-network. …one or more system nodes 252 may comprise server blades, graphical processing units (GPUs), server computers, personal computers, mobile computing devices, supercomputers, Internet-of-Things (IOT) devices, one or more virtual machines (i.e., containerized system) etc., . Distributed computing system 250 may ingest or import OpenIOC's by maintaining and updating a list of changes to the OpenIOC data… leverage tools such as FireEye® Redline® tool to analyze a potentially compromised memory and file structure to find signs of malicious activity, (See Col 14, lines 23-48)) [Examiner interprets that system collecting data streams from different network connected devices such as server computers, personal computers, mobile computing devices, virtual machines that contains device logs, network traffic logs and sensor alert as limitation above]. processing the forensic data received from the network to identify whether a security incident has occurred by at least parsing the logs of data to identify attributes of the security incident, wherein the security incident includes unauthorized access of the network has been accessed by an unauthorized computing system (Sirianni, Translation module 102 may send data to a distributed platform of federated storage and analytics such as distributed database 104. …This data may then be combined and analyzed to make a conclusion. For example, anomaly detection module 106 may determine whether packets received were part of a cyber-attack by using information about the order of receipt of the packets and/or their original source address. Anomaly detection module 106 may determine from the original source address that a source is a concern while the anomaly detection module 106 may determine an intent or actions that are considered out of the allowable bounds of input behavior based on the sequence and content of received packets, See (Col 3, lines 14-29) Anomaly detection module 106 may be configured to detect anomalies including malicious activity including intrusion, exfiltration, and lateral movement. Malicious activity may take the form of cyber-attacks and inappropriate use of a system resource including access of a website or other network resource that the system owner thinks is blocked, See (Col 12, lines 25-31)) [ Examiner interprets that combining and analyzing data (i.e., the device logs and data packet) to detect or identify the a cyber-attack e.g., malicious activity including intrusion, exfiltration, and lateral movement (i.e., attributes of the security incident) by using information about the order of receipt of the packets and/or their original source address as limitation above]. Although Sirianni teaches SITF performing distributed processing by splitting data into partitions and processing them on plurality of distributed nodes, see Fig 4 description, performing routine analysis ..automated to complete on specified schedule and generating alerts/reports for analysis for analyst via web interface, Sirianni does not explicitly teach: dynamically generating, by automated processing of the forensic data, a workflow of suggested tasks and an order of performance of the suggested tasks to respond to the security incident, wherein the generating of the workflow comprises (i) analyzing characteristics or attributes of the forensic data to automatically and dynamically determine a number of tasks and a type of tasks to be performed to remediate the security incident, (ii) assigning the number of task and the type of tasks to a group of working resources, wherein the group of working resources comprises computing resources to process the number of tasks and the group of working resources is automatically scaled in response to the determined number of tasks, and wherein the computing resources operate in parallel and are released upon completion of their assigned tasks; and processing the number of tasks if it is determining that the unauthorized computing device has accessed the network. However, Lunsford teaches: dynamically generating, by automated processing of the forensic data, a workflow of suggested tasks and an order of performance of the suggested tasks to respond to the security incident (Lunsford, The tasks of a playbook for responding to an incident can be assembled (e.g., collected, derived) from the tasks of other playbooks. For example, based on the parameters (i.e., attribute values) of an incident, the appropriate (e.g., relevant, related, etc.) tasks from other playbooks can be associated with the tasks for resolving the incident, [0061] Workflows and states may be associated with different incidents types (for example, based on attribute values of the incidents). The incidents module 312 can be used to shepherd an incident through its associated workflow. The incidents module can be used to ensure that an incident does not advance to a next state in its lifecycle unless certain specified criteria (e.g., gate criteria) are met, [0062] the system 302 can scan and assess events that are received from the S 326 to determine an updated risk to the instant enterprise of a cyber event. Playbooks and/or tasks can be added, deleted, and/or changed, by one or more components of the system 302, to reflect the updated risk, [0108] Completing a task by a user may merely change the status of the task and cause the task to move in a workflow to a next user (e.g., a collaborating user, a reviewing user, etc.). A task may advance through several statuses until the process 800 can consider the task the be completed. At each status, the task may be assigned to different user groups, [0126] At 1202, the process 1200 receives an incident of a cyber event. The incident can be received from a user. The user can be a human user or an external system. At 1204, the process 1200 identifies tasks based on the incident. For example, the process 1200 can identify the tasks based on attribute values of the incident, [0134] when the particular attribute value (or a combination thereof) is selected by the user, when using the user interface 1300 to create or modify an incident, then the associated task can be automatically added to the incident, [0137]) [Examiner interprets that system dynamically assembling, selecting, adding, deleting , and changing the particular collection of tasks used for the incident based on incident attributes and updated security information, associating the incident with a workflow, following the incident through that workflow, and preventing advancement to a next state until specified criteria are met as limitation above] analyzing characteristics or attributes of the forensic data to automatically and dynamically determine a number of tasks and a type of tasks to be performed to remediate the security incident (Lunsford, the system 302 can receive (e.g., in real-time, in near real-time, on a scheduled basis, by pull, etc.), from the SIEM 326, analysis of security alerts generated by applications and network hardware. In an example, the system 302 can receive aggregated log data, correlated data, alerts based on analysis of aggregated and/or correlated data, more or fewer data types, or a combination thereof from the SIEM 326, [0103] At 1202, the process 1200 receives an incident of a cyber event. The incident can be received from a user. The user can be a human user or an external system. At 1204, the process 1200 identifies tasks based on the incident. For example, the process 1200 can identify the tasks based on attribute values of the incident, [0134] The attribute 1302 indicates the incident type(s), the attribute 1304 indicates the data classification(s) of the data impacted by the incident, the attribute 1306 indicates the event type(s) of the incident, the attribute 1308 indicates the country(ies) where the incident has occurred, the attribute 1310 indicates the state(s) where the incident has occurred, [0136] a task can be associated with at least one of a particular incident type, a type of data (i.e., a data classification), a particular event type, a specific country, a specific state, other attribute values, or a combination thereof. As such, when the particular attribute value (or a combination thereof) is selected by the user, when using the user interface 1300 to create or modify an incident, then the associated task can be automatically added to the incident, [0137] The user interface 1300 illustrates that the task “ISO Task” is added to a tasks list 1312 upon the user selecting the combination of attribute values “Negligence” (for the attribute 1302), “Personal Information” (for the attribute 1304), “Emergency” (for the attribute 1306), “Afghanistan” (for the attribute 1308), and “Badakhsan” (for the attribute 1310). Contrastingly, the user interface 1350 illustrates that many other tasks are added to a task list 1362 upon the user selecting “Third Party Loss or Theft” and “Illegal Access to System or Information” for incident type (i.e., an attribute 1352), “Personal Information” and “Public Data” for data classification (i.e., an attribute 1354), “Emergency” as the event type (i.e., an attribute 1356), “France” for country (i.e., an attribute 1358), and “Paris” for state (i.e., an attribute 1360), [0138]) [Examiner interprets that security/forensic information is characterized by incident attributes, those attributes are analyzed to identify the applicable tasks, and different attributes result in different task sets having different numbers and types of tasks as limitation above] assigning the number of task and the type of tasks to a group of working resources (Lunsford, Tasks related to cyber events can be assigned to user groups, individual users, roles, or automated agents…a task can be assigned to a system (i.e., automated) agent (e.g., a programmed set of instructions that are executable by a processor to accomplish a task), [0054] When a task related to a cyber event is instantiated, the system 302, or the users/groups module 304, determines, based on attributes of the task, which user group(s) and/or which user(s), the task is to be assigned to (e.g., who can view and/or complete the task), [0055] When an incident is created in the system 302, the tasks module 310 can be used to assign tasks, which are necessary for resolving the incident, to respective user groups, [0061] the tasks (i.e., the playbook) associated with the common incident 904 to be instantiated and assigned to the respective teams (e.g., user groups)… a task can be assigned to an automated agent. As such, the user can be the automated agent [0124]) processing the number of tasks if it is determining that the unauthorized computing device has accessed the network (Lunsford, If the system 302 cannot determine whether the database is encrypted, and if the IP address is outside the range of IPs of the instant enterprise, then the system 302 can determine that unencrypted PII data was moved outside the instant enterprise in violation of GDPR. As such, the system 302 can initiate an incidence response, [0107] At 804, the process 800 can identify a playbook of tasks. The playbook constitutes a response to the cyber event, [0124]) [Examiner interprets that system determining the violation (i.e., unauthorized IP access)and triggering the initiation an incident response such as identifying and executing the playbook tasks as part of remediation steps as processing the number of tasks if it is determining that the unauthorized computing device has accessed the network]; Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Sirianni to include a concept of generating a workflow of suggested tasks and order of performance of the suggested tasks to respond to the security incident, wherein the workflow comprises splitting the processing of the forensic data into a number of tasks, wherein the number of tasks are determined based on processing resources scaled for the forensic data, assigning the number of tasks to a group of working resources, processing the number of tasks if it is determining that the unauthorized computing device has accessed the network as taught by Lunsford for the purpose of responding to cyber events by receiving a cyber event, identifying a playbook of tasks, where the playbook constitutes a response to the cyber event, and assigning task to respective user group, receiving a proof of completion of the task from a user or user groups, and generating a compliance report including the task and the proof of completion, [Lunsford: 0008]. Although Lunsford describes distributed, cloud, clustered, and provisioned computing resources, Sirianni, and Lunsford do not explicitly teach: assigning the number of task and the type of tasks to a group of working resources, wherein the group of working resources comprises computing resources to process the number of tasks and the group of working resources is automatically scaled in response to the determined number of tasks, and wherein the computing resources operate in parallel and are released upon completion of their assigned tasks However, Choi teaches: assigning the number of task and the type of tasks to a group of working resources, wherein the group of working resources comprises computing resources to process the number of tasks and the group of working resources is automatically scaled in response to the determined number of tasks, and wherein the computing resources operate in parallel and are released upon completion of their assigned tasks (Choi, With the proliferation of a cloud service, the number of cases of processing a massive task in parallel using a plurality of virtual machines, in the technology for running virtual machines in parallel, [0003-0004] The task input interface 102 receives a plurality of processing-target tasks and sequentially inputs the processing-target tasks to a task queue (worker queue) of a memory… exemplary embodiments of the present disclosure are not limited to specific types of tasks and may be applied to any kind of series of tasks requiring computing resources, [0035] duplicate devices are virtual machines… The duplicate devices process tasks assigned by the duplicate device manager 106 among the plurality of processing-target tasks, and may generate one or more secondary duplicate devices as necessary and recursively reassign some of the tasks assigned thereto, [0038] , it is possible to assign optimal computing resources for the computation amount of processing-target tasks by dynamically generating one or more duplicate devices in stages according to the computation amount of processing-target tasks and distributing the processing-target tasks, [0039] the duplicate device manager 106 waits for the unprocessed waiting time from a point in time when the task queue is filled to a certain level or higher, and then calculates the number or a ratio of unprocessed tasks (tasks which have not been input into the task queue yet), [0048] the duplicate device manager 106 may determine that it is necessary to generate the one or more duplicate devices when the number of unprocessed tasks is a preset value or more, [0049] the duplicate device manager 106 determines the number of duplicate devices to be generated according to the number or the ratio of unprocessed tasks, [0051] When a duplicate device is generated, the duplicate device manager 106 assigns the unprocessed tasks of the apparatus 100 for managing computing resources to the duplicate device. When two or more duplicate devices are generated, the duplicate device manager 106 may equally assign the unprocessed tasks to the two or more duplicate devices, [0052] After the unprocessed tasks are assigned, the duplicate device manager 106 determines whether the unprocessed tasks assigned to the duplicate device have been completed… When it is determined that the unprocessed tasks assigned to the duplicate device have been completed, the duplicate device manager 106 deletes the duplicate device, [0053]) [Examiner interprets that system dynamically generating virtual machines (i.e., group of working computing resources) whose size is automatically adjusted in response to task quantity, whose members process distributed tasks in parallel and are released by deletion upon completion of their assigned tasks as limitation above]. Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Sirianni, and Lunsford to include a concept of a) assigning the number of task and the type of tasks to a group of working resources, wherein the group of working resources comprises computing resources to process the number of tasks and the group of working resources is automatically scaled in response to the determined number of tasks, and wherein the computing resources operate in parallel and are released upon completion of their assigned tasks as taught by Choi for the purpose of dynamically assigning optimal computing resources for the number or the computation amount of tasks to be processed and minimizing the load of managing and administering computing resources required for processing a series of tasks [Choi: 0005-0006]. Regarding claim 2, Sirianni, Lunsford, and Choi teaches the method of claim 1, further comprising: identifying a sequence of events employed by an adversary, the sequence of events being associated with the network; detecting a missing event in the sequence of events (Sirianni, anomaly detection module 106 may determine whether packets received were part of a cyber-attack by using information about the order of receipt of the packets and/or their original source address. Anomaly detection module 106 may determine from the original source address that a source is a concern while the anomaly detection module 106 may determine an intent or actions that are considered out of the allowable bounds of input behavior based on the sequence and content of received packets, See (Col 3, lines 19-28) Anomaly detection module 106 includes the use of probability distribution module 120 over datasets to expose statistical anomalies which include an unsupervised learning module configured to find the common values of features and outliers to model constraints that are considered anomalous. For example, the time of a user's login could be examined and it could form an understanding of when that user typically logs in. When that user logs in at an unusual hour, for example 3 AM, that may be considered anomalous. Over time anomaly detection module 106 may develop a statistical profile of behavior. By looking at the current statistics and comparing them to historical data sets anomaly detection module 106 detect whether there are changes and then investigate the changes based upon how widely they diverge from history, See (Col 3, lines 48-64)) [ Examiner interprets that system receiving information about the order of receipt of the packets and/or their original source address (i.e., the sequence of events) and looking at the current statistics and comparing them to historical data sets to detect whether there are changes and then investigate the changes based upon how widely they diverge from history as identifying a sequence of events employed by an adversary, the sequence of events being associated with the network; detecting a missing event in the sequence of events]. identifying one or more new suggested tasks, wherein each new suggested task of the one or more new suggested tasks is designed to assist a user in searching for one or more attack techniques associated with the missing event (Sirianni, Incident-response system 100 may filter new data streams and steer analysts toward previously unknown attacks, See (Col 4, lines 2-4) Analysis computing system 200 may provide a report based on the analysis of the first data set and the second data set. The report may be provided via the secure web interface 108 to user 118, See (Col 17, lines 54-57)) [Examiner interprets the system’s ability to “steer analysts” which is a built-in recommendation engine that suggests the next investigative steps (i.e., suggested tasks) to search for technique associated with the detected anomaly as identifying one or more new suggested tasks, wherein each new suggested task of the one or more new suggested tasks being designed to assist a user in searching for one or more attack techniques associated with the missing event]. Regarding claim 3, Sirianni, Lunsford, and Choi teaches the method of claim 1, wherein determining if the network has been accessed by the unauthorized computing system includes the computing device modifying, deleting and/or acquiring data to the network without authorization (Sirianni, Anomaly detection module 106 may be configured to detect anomalies including e.g., malicious activity including intrusion, exfiltration, and lateral movement. Malicious activity may take the form of cyber-attacks and inappropriate use of a system resource including access of a website or other network resource that the system owner thinks is blocked, See (Col 12, lines 25-31)) [ Examiner interprets that anomaly detection module detecting anomalies such as intrusion, exfiltration (i.e., acquiring and deleting data to the network without authorization) , and lateral movement (i.e., unauthorized modification of data) as determining if the network has been accessed by the unauthorized computing system includes the computing system modifying, deleting and/or acquiring data to the network without authorization]. Regarding claim 6, Sirianni, Lunsford, and Choi teaches the method of claim 1, further comprising: identifying a suspicious remote login, suggesting a set of tasks to a user based on suspicious login, wherein the set of tasks includes a suggested task designed to assist the user in: determining whether a source connection associated with the suspicious remote login is detect on a system; reviewing account activity associated with the source connection; and performing an analysis of the system (Sirianni, Anomaly detection module 106 includes the use of probability distribution module 120 over datasets to expose statistical anomalies which include an unsupervised learning module configured to find the common values of features and outliers to model constraints that are considered anomalous. For example, the time of a user's login could be examined and it could form an understanding of when that user typically logs in. When that user logs in at an unusual hour, for example 3 AM, that may be considered anomalous. Over time anomaly detection module 106 may develop a statistical profile of behavior. By looking at the current statistics and comparing them to historical data sets anomaly detection module 106 detect whether there are changes and then investigate the changes based upon how widely they diverge from history, See (Col 3, lines 48-64) Incident-response system 100 may filter new data streams and steer analysts toward previously unknown attacks, See (Col 4, lines 2-4) user 118 may select logs that occurred throughout the network at a given time for a specific severity at incident-response system 100. User 118 may get data points for a specific user during a certain time, for example, through graphical queries that may allow user 118 to select out of the available options and put the criteria they wanted for a variable from incident-response system 100 via web interface 108. Queries may also take the form of a Cassandra Query Language (CQL) query in an Apache® Cassandra database or a Structured Query Language (SQL) query of a SQL based database. Results may be displayed in a column/row format or a hierarchical format depending on the data retrieved from the query, See (Col 5, lines 15-27) Results may be returned to the users 118 in the form of alerts for less detailed incidents or generated reports for more in-depth analysis and tailored with a selection of graphs to display results visually, See (Col 5, lines 30-33)) [ Examiner interprets that system learning the normal login patterns, flagging if any out of bounds logins as suspicious, auto generating “steer analysts” recommendations when anomalies occur, providing UI to query to pull all log in related events for the specific connection ID or user account, and automatically running deeper analytics (i.e., ML models , statistical reports) on collected logs and displaying the findings as identifying a suspicious remote login, suggesting a set of tasks to a user based on suspicious login, wherein the set of tasks includes a suggested task designed to assist the user in: determining whether a source connection associated with the suspicious remote login is detect on a system; reviewing account activity associated with the source connection; and performing an analysis of the system]. Regarding claim 7, Sirianni, Lunsford, and Choi teaches the method of claim 1, further comprising suggesting a set of tasks correspond to the number of tasks to a user, wherein the set of tasks includes executing a wizard, evaluating an enrichment to one or more log events, or managing a task using an auto-suggest technique (Sirianni, Incident-response system 100 may filter new data streams and steer analysts toward previously unknown attacks, Incident-response system 100 may use Indicators of Compromise (IOCs) 124 for identifying forensic artifacts—data that can be found on a computer system—that are known to be associated with a particular attack or attacker. IOCs 124 including the OpenIOC format may be a way for incident-response system 100 to describe characteristics of an attack or attacker, See (Col 4, lines 2-11) Alerts may be displayed in a dashboard or alerts tab that is accessible through web interface 108. Alerts may have a description of what has occurred and related points of data that led to that alert. Reports may be a generated and a detailed document (in, for example PDF format) describing an alert or user generated query, with user defined graphs that visualize the data may be generated and provided to user 118, via for example web interface 108. Web interface 108 may accommodate technicians of all skill levels, and may provide guided graphical user interface (GUI) interactions, as well as more advanced command line options for power users, Col 5, lines 36-47) ) [ Examiner interprets that system providing guided GUI interaction to user, tagging raw log entries with IOCs with a particular attack or attacker, and automatically “steering analysts” to next investigative steps for auto suggestion and recommendation of tasks based on detected anomalies as suggesting a set of tasks correspond to the number of tasks to a user, wherein the set of tasks includes executing a wizard, evaluating an enrichment to one or more log events, or managing a task using an auto-suggest technique] Regarding claims 8 and claim 15, Claims 8 and 15 recite commensurate subject matter as claim 1. Therefore, they are rejected for the same reasons. Except the additional elements: Sirianni further teaches: A non-transitory computer-readable medium comprising instructions that are executable by a processing device for causing the processing device to perform operations (Sirianni, a non-transitory computer-readable storage medium stores instructions that, when executed, cause one or more processors…, See (Col 2, lines 6-12) comprising: A system for analyzing forensic data for remediating security incidents in a multi-tenant environment (Sirianni, anomaly detection system for performing data analytics using an incident response and monitoring solution (e.g., a Scalable Incident-response and Forensics Toolkit (SIFT)), built for distributed processing, that streamlines cyber defense, See Col 1, lines 38-42) comprising: one or more processors (Sirianni, computing system 300 includes one or more processing units 228, Col 15, lines 41-42); and a non-transitory computer-readable storage medium containing instructions which, when executed on the one or more processors, cause the one or more processors to perform operations (Sirianni, a non-transitory computer-readable storage medium stores instructions that, when executed, cause one or more processors…, See (Col 2, lines 6-12) including: Regarding claims 9,10, 13, and 14, Claims 9, 10,13, and 14 recite commensurate subject matter as claims 2, 3, 6, and 7. Therefore, they are rejected for the same reasons. Regarding claims 16, 17, and 20, Claims 16, 17, and 20 recite commensurate subject matter as claims 2 , 3, and 6 . Therefore, they are rejected for the same reasons. Regarding claim 21, Sirianni and Lunsford and Choi further teaches the method of claim 1, Lunsford further teaches: wherein each task of the number of tasks includes one or more processing operations to be conducted within the multi-tenant environment (Lunsford, A distributed computing system can allocate resources of a computer network using a multi-tenant or single-tenant architecture, for example. Allocating resources in a multi-tenant architecture can include installations or instantiations of one or more servers, such as application servers, database servers, or any other server, or combination of servers, that can be shared amongst multiple customers, [0040] The tasks module 310 can be used to manage tasks associated with cyber events. For example, the tasks module 310 can be used to create tasks, which includes assigning tasks to one or more user groups. When an incident is created in the system 302, the tasks module 310 can be used to assign tasks, which are necessary for resolving the incident, to respective user groups. The playbook module 308 can be used to collect a set of tasks into a playbook. A playbook can provide a recipe (e.g., a pre-configured or prespecified set of tasks) for responding to specific incident types. More generally, a playbook can be any collection of tasks. For example, a playbook can be associated with an authority. For example, the collection of tasks that is associated with the GDPR can be referred as a playbook. The tasks of a playbook for responding to an incident can be assembled (e.g., collected, derived) from the tasks of other playbooks. For example, based on the parameters (i.e., attribute values) of an incident, the appropriate (e.g., relevant, related, etc.) tasks from other playbooks can be associated with the tasks for resolving the incident, [0061]) [Examiner interprets that system carrying out each task in a playbook (i.e., an operation or set of operations) within the cloud incident management system (i.e., multitenant environment) as each task of the number of tasks includes one or more processing operations to be conducted within the multi-tenant environment] The motivation applies same as claim 1. Claim 4, 11, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Sirianni (US 10885393 B1) in view of Lunsford (US 20200193022 A1) in further view of Choi (US 20180081728 A1) in further view of Halpern (US 20170126792 A1). Regarding claim 4, Sirianni, Lunsford, and Choi teaches the method of claim 1, Sirianni and Lunsford does not explicitly teach: wherein the group of working resources are scaled using machine learning techniques However, Halpern teaches: wherein the group of working resources are scaled using machine learning techniques (Halpern, The autoscale ML system is trained online using machine learning to predict an amount of resources to be utilized by the vNF. The autoscale ML system is configured to receive as input an amount of resources currently utilized by the vNF and an amount of resources currently available to the vNF, determine using machine learning the suggested adjustment to the amount of resources provisioned for the vNF based on the amount of resources currently utilized by the vNF and the amount of resources currently available to the vNF, and output the suggested adjustment to the amount of resources provisioned for the vNF. The method further includes providing the suggested adjustment to the amount of resources provisioned for the vNF to a resource re-allocator component, [0006] Embodiments introduce machine learning systems that can learn the resource consumption tendencies of SFCs. The machine learning systems can provide a more accurate determination of the amount of resources that an SFC will need and can predict when the amount of resources provisioned for an SFC needs to be adjusted. Embodiments utilize information obtained from machine learning systems to optimize resource usage of SFCs, [0031])[ Examiner interprets that system using machine learning models to learning the resource consumption tendencies of SFCs, providing a more accurate determination of the amount of resources that an SFC will need and continuously predicting and adjusting resource levels as the group of working resources are scaled using machine learning techniques]. Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Sirianni, Lunsford, and Choi to include a concept of the group of working resources are scaled using machine learning techniques as taught by Halpern for the purpose of using machine learning models to learning the resource consumption tendencies of SFCs, providing a more accurate determination of the amount of resources that an SFC will need and continuously predicting and adjusting resource levels, [Halpern:0031]. Regarding claims 11 and 18, Claims 11 and 18 recite commensurate subject matter as claim 4. Therefore, they are rejected for the same reasons. Claims 5, 12, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Sirianni (US 10885393 B1) in view of Lunsford (US 20200193022 A1) in further view of Choi (US 20180081728 A1) in further view of Nickl (US 20210125089 A1). Regarding claim 5, Sirianni, Lunsford, and Choi teaches the method of claim 1, Sirianni, Lunsford, and Choi does not explicitly teach: wherein, when the forensic data includes credit card information, suggesting a set of tasks correspond to the number of tasks to a user, wherein the set of tasks includes a suggested task designed to assist the user in determining whether or not to notify customers of a security incident associated with the network However, Nickl teaches: wherein, when the forensic data includes credit card information, suggesting a set of tasks correspond to the number of tasks to a user, wherein the set of tasks includes a suggested task designed to assist the user in determining whether or not to notify customers of a security incident associated with the network (Nickl, data breach events may be associated with personal or company financial information such as credit card or bank details, an individual's personal health information (“PHI”), an individual's personally identifiable information (“PII”), or intellectual property, among other things, [0004] For protected information that is financial information, the system can be configured to identify protected information that is associated with finances, financial institutions, tax records, etc. Payment card information (e.g., credit/debit card numbers, PIN, expiration, security code, security questions, etc.), [0189-0191] the systems generates automatic notifications of the data breach to each identified entity as required by each applicable laws, rules, regulations, policies, or contractual obligations. In this regard, a reporting obligation associated with an identified entity is determined for an identified entity, where the reporting obligation is derived from at least the applicable laws, rules, regulations, policies, or contractual obligations, the residence, location, or citizenship of the identified entity, and whether protected information for the identified entity was present in or can be derived from the data files associated with the identified entity. If a reporting obligation is present, the system is configurable to provide such automatic notification via letter using address information derivable from the compliance-related database, [0282]) [Examiner interprets that identifying protected information (i.e. credit card information) and checking if there is any data breach events associated with credit card info and suggesting to notify the customers via letter using address information derivable from the compliance-related database if it reporting obligation is present as when the forensic data includes credit card information, suggesting a set of tasks to a user, wherein the set of tasks includes a suggested task designed to assist the user in determining whether or not to notify customers of a security incident associated with the network]. Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Sirianni, Lunsford, and Choi to include a concept of when the forensic data includes credit card information, suggesting a set of tasks to a user, wherein the set of tasks includes a suggested task designed to assist the user in determining whether or not to notify customers of a security incident associated with the network as taught by Nickl for the purpose of identifying data breach events may be associated with personal or company financial information such as credit card [Nickl:0004] and generating automatic notifications of the data breach to each identified entity as required by each applicable laws, rules, regulations, policies, or contractual obligations when a reporting obligation associated with an identified entity is determined [Nickl:0282]. Regarding claims 12 and 19, Claims 12 and 19 recite commensurate subject matter as claim 5. Therefore, they are rejected for the same reasons. Conclusion The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. US 11714683 B1: “relates to playbook execution architecture enables an IT and security operations application to vertically scale the computing resources used to execute playbooks, provides users with more control over an amount of computing resources devoted to the execution of playbooks, and enables more expressiveness in the types of actions and efficiency of playbooks by providing support for multiple programming languages and programming language versions” US 8850588 B2: “relates to the field of data center virtualization and, more particularly, to systems and methods for providing dynamic operational integrity attestation of application security and a user reputation at runtime” Any inquiry concerning this communication or earlier communications from the examiner should be directed to SAMIKSHYA POUDEL whose telephone number is (703)756-1540. The examiner can normally be reached 7:30 AM - 5PM Mon- Fri. 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, SHEWAYE GELAGAY can be reached at (571)272-4219. 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. /S.N.P./Examiner, Art Unit 2436 /SHEWAYE GELAGAY/Supervisory Patent Examiner, Art Unit 2436
Read full office action

Prosecution Timeline

Aug 31, 2023
Application Filed
May 20, 2025
Non-Final Rejection mailed — §103, §112
Sep 22, 2025
Response Filed
Dec 01, 2025
Final Rejection mailed — §103, §112
Feb 02, 2026
Response after Non-Final Action
Feb 25, 2026
Request for Continued Examination
Mar 08, 2026
Response after Non-Final Action
Sep 08, 2026
Non-Final Rejection mailed — §103, §112 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12717884
PROACTIVE BIOMETRIC SIGNATURE GENERATION
3y 9m to grant Granted Aug 25, 2026
Patent 12645787
STACK TRACE ANALYSIS MODEL
2y 11m to grant Granted Jun 02, 2026
Patent 12619726
CYBER RESILIENCE INTEGRATED SECURITY INSPECTION SYSTEM (CRISIS) AGAINST FALSE DATA INJECTION ATTACKS
4y 1m to grant Granted May 05, 2026
Patent 12591663
INFORMATION PROCESSING DEVICE, INFORMATION PROCESSING METHOD, AND INFORMATION PROCESSING COMPUTER PROGRAM PRODUCT
2y 7m to grant Granted Mar 31, 2026
Patent 12470379
LINK ENCRYPTION AND KEY DIVERSIFICATION ON A HARDWARE SECURITY MODULE
3y 0m to grant Granted Nov 11, 2025
Study what changed to get past this examiner. Based on 5 most recent grants.

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

3-4
Expected OA Rounds
52%
Grant Probability
99%
With Interview (+77.8%)
2y 11m (~0m remaining)
Median Time to Grant
High
PTA Risk
Based on 27 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month