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 .
DETAILED ACTION
This Office Action is in response to application 17/387,237 in response to Pre-Brief Appeal Conference decision on 10/01/2025. A conference has been held and the previous rejection is withdrawn and Prosecution will be reopened. This action is a non-final.
Claims 1, 3-7 have been examined and are pending in this application.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim 1, 6-7 is rejected under 35 U.S.C. § 103 as being unpatentable over Cornell (US 2017/0243008 A1), in view of Bailey (US 2017/0048276 A1).
Regarding Claim 1
Cornell discloses:
A computer-implemented method for responding to network threat, carried out by a threat responding device including a threat detection module, a ticket management module, a workflow module workflow module executed based on the ticket ¶0033, 0041], the method comprising: receiving, by the threat detection module, security-associated data of a suspected threat from security device [monitored systems 102 generate and communicate logs and alarms 104 for security operations system 106, the logs/alarms identifying security threats and providing information associated with the security threat captured by the monitored systems; ¶0020];
generating, by the threat detection module, a ticket based on the received security-associated data [security operations system 106 responds to the logs and alarms 104 by generating tickets, using conditions evaluated on the initial security threat and gathered characteristics; ¶0021-0022];
requesting, by the ticket management module, ticket analysis and response according to the ticket analysis to the workflow module [security operations system 106 uses form 204 (the ticket) to execute workflow 206, the workflow being executed by considering the values of fields in the form and enabling security operations system 106 to act by sending notifications, collecting security contextual data, submitting threat intelligence, opening records, and closing records, in response to the form; ¶0033, 0041];
wherein the task comprises at least one of an inquiry task, a blocking task, an alarm task, and or a follow-up action task [security operations system 106 may query for, submit, and/or retrieve security contextual data (inquiry); updates to monitored systems include blocking IP addresses, blocking access to domains, preventing mail from particular email addresses (blocking); workflow 602 sends notifications (alarm); workflow closes records and collects further contextual data (follow-up); ¶0023, 0033, 0038];
Cornell teaches ticket driven triggering of workflow execution, attributing both functions to security operations system 106 generally rather than to separately named ticket management and workflow modules. Cornell does not explicitly teach a plugin program module that is executed by a query and calls the API of the security device, nor a workflow module carrying out a task by use of that API through such a plugin architecture. On the other hand, Bailey teaches a plugin program module executed by a query which calls the API of the security device or external security service, and a workflow module carrying out a task by use of that API [plug-ins 302/512 associated with commands 308/514 that leverage an API to perform an action on a network device, the plugin being invoked from a start node or adapter representing a specific trigger condition; 0035, 0039, 0042; the Orchestration Engine, executing a course of action, communicates instructions from a plug-in identified in a task over the LAN to network appliance devices to mitigate a cyber security threat; 0081]. Bailey further teaches the task comprises an inquiry task and a blocking task, wherein the inquiry task comprises an inquiry about IP reputation of the suspected threat, and the blocking task comprises IP blocking of the suspected threat which is determined as a real threat by the inquiry task [a task to pull a reputation of an IP address, to then make a decision based on that score, wherein the decision may be to permanently block the IP address or put it on a temporary block; 0050].
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify Cornell's ticket API interacting threat response workflow with Bailey's query triggered plugin program module because Cornell and Bailey are analogous art involving automated cybersecurity threat detection and orchestrated response using third party device and service APIs. The motivation to combine would have been to organize Cornell's existing API interaction into a modular plugin architecture as expressly taught by Bailey, allowing new security devices and services to be integrated into the threat response workflow without modifying the core system, and enabling the workflow module to reliably invoke and use a security device's or external service's API to carry out a specific task such as an inquiry or blocking task in response to a detected threat.
Regarding Claim 6
Claim 6 is directed to a computer-implemented system corresponding to the computer-implemented method in claim 1. Claim 6 is similar in scope to claim 1 and is therefore rejected under similar rationale.
Regarding Claim 7
Claim 7 is directed to a computer program product corresponding to the computer-implemented method in 1. Claim 7 is similar in scope to claim 1 and is therefore rejected under similar rationale.
Claim 3-5 is rejected under 35 U.S.C. § 103 as being unpatentable over Cornell (US 2017/0243008 A1), in view of Bailey (US 2017/0048276 A1) as applied to claim 1 above, and in further view of Veeramachaneni (US 2017/0169360 A1).
Regarding Claim 3
As per claim 3, the combination of Cornell and Bailey teaches the method according to claim 1 as set forth above. Cornell teaches that a ticket (record) comprises a mix of indicator-type data and general/administrative data [the characteristics of the threat may include an origination IP address, a target IP address, a severity score, a suggested action, and/or the threat type; ¶0006; list 300 may include additional fields 320 such as host names, domains, IP addresses, email accounts, or other data related to a record 318; ¶0028], and Bailey teaches that each task carries out I/O by passing parameter data between tasks [the result of one task can become an input to the start of another task; ¶0037; the output parameters of one command may be used as input parameters for other commands triggered by downstream tasks in the CoA; ¶0055]. However, the combination of Cornell and Bailey does not explicitly teach that the ticket data is partitioned into two named variable categories, an "Indicator of Compromise (IoC) variable" and a "general variable." On the other hand, Veeramachaneni teaches organizing security data into an indicator-type category and a separate, general/behavioral category types [the one or more log line parameters comprises at least one of: user ID, session, IP address, and URL query; ¶0054; a features matrix in which the one or more features make up the columns and the one or more log line parameters make up the rows, the features matrix comprising features such as user session duration, number of requests in user session, and percentage of responses in user session; ¶0058, 0091].
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the combined Cornell/Bailey threat response system with Veeramachaneni's data categorization technique because Cornell, Bailey, and Veeramachaneni are analogous art involving the collection and processing of security data for automated threat detection and response. The motivation to combine would have been to organize the ticket and task data already disclosed by Cornell and Bailey, which includes both indicator data (Cornell's IP addresses, domains, and hashes) and general/administrative data ( Cornell's severity, status, and assignment fields) into two distinguished variable categories as expressly taught by Veeramachaneni, thereby enabling more structured and efficient use of the ticket data by the workflow's tasks which is consistent with Bailey's practice of passing parameter data as I/O between tasks.
Regarding Claim 4
Cornell, Bailey, and Veeramachaneni teaches the method according to claim 3 as set forth above. Veeramachaneni further teaches wherein the threat responding device further comprises an AI learning module that receives at least one of categorizable variable which is extracted from the general variable, numerical variable which is extracted from the general variable, or determination as to whether an IoC is malicious for each module, the received information being input feature of the AI learning module [a features matrix in which one or more features make up the columns and one or more log line parameters make up the rows, the features matrix comprising numerical-type features such as user session duration, number of requests in user session, and percentage of responses in user session (numerical variable); ¶0058, 0091; an analyst inputs label information for statistical outliers as malicious, non-malicious, or another analyst defined label, and the labeled statistical outliers are incorporated into a labeled features matrix (categorizable variable / determination as to whether an IoC is malicious); ¶0081, 0095; the labeled features matrix is then sent to a supervised learning module 328 configured to create one or more rules for identifying threats, the labeled features matrix thereby serving as input features to the supervised learning module; ¶0095].
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the combined Cornell/Bailey threat response system with Veeramachaneni's AI learning module because Cornell/Bailey and Veeramachaneni are analogous art involving automated threat detection and response using extracted data features. The motivation to combine would have been to improve the accuracy and adaptability of the Cornell/Bailey threat response system by incorporating Veeramachaneni's technique of classifying extracted threat data into numerical and categorizable feature types and using an IoC-maliciousness determination as an input feature, thereby enabling the system to learn from accumulated threat data and improve threat identification over time.
Regarding Claim 5
Cornell, Bailey, and Veeramachaneni teaches the method according to claim 4 as set forth above. Veeramachaneni further teaches accumulating, by the AI learning module, the input feature and the response result provided by a security analyst; carrying out, by the AI learning module, a supervised learning with the accumulated data to generate an AI learning model; and determining, by the workflow module, a threat according to the AI learning model and responding to the threat [an analyst inputs label information for the statistical outliers as malicious, non-malicious, or another analyst defined label, and the labeled statistical outliers are incorporated into a labeled features matrix; ¶0081, 0095; the labeled features matrix is sent to a supervised learning module 328 configured to create from the labeled matrix one or more rules for identifying threats; ¶0095; the one or more rules are sent to one or more threat detectors for real time monitoring and if threats are detected, the incoming data traffic is blocked and/or challenged, wherein the supervised learning module may detect threats and block and/or challenge the incoming threat; ¶0082, 0096].
The claim is obvious for the same reasons set forth above with respect to claim 4 because Veeramachaneni's supervised learning technique accumulates analyst provided labels with extracted input features to train a model that is then used to detect and respond to threats in real time, this would have been obvious to incorporate into the Cornell/Bailey threat response system to achieve the predictable result of an adaptive automated threat detection and response capability.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SAAD ABDULLAH whose telephone number is 571-272-1531. The examiner can normally be reached on Monday-Friday 9am-5pm EST. If attempts to reach the examiner by telephone are unsuccessful, the examiner's supervisor, LYNN FIELD can be reached on 571-272-2092.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800- 786-9199 (IN USA OR CANADA) or 571-272-1000.
/SAAD AHMAD ABDULLAH/ Examiner, Art Unit 2431
/LYNN D FEILD/ Supervisory Patent Examiner, Art Unit 2431
Prosecution Insights