DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
On page 5 of the previous non-final action, mailed on 5/23/25, claim 14 was indicated as being rejected under 35 U.S.C. 102 over Govardhan on the header. However, the non-final action missed to provide art rejection to claim 14. This office action includes art rejection to claim 14 and thereby reopened.
Claims 2, 9 and 16 are canceled. Claims 21-23 are newly added. Claims 1, 3-8, 10-15 and 17-23 are pending and in rejected status.
Response to Arguments
Regarding the 101 rejection arguments to claims 1-20, Applicant’s arguments have been fully considered but are not persuasive. The amendment to claim 1 does not overcome the rejection under 35 U.S.C. § 101. The rejection is therefore maintained for at least the reasons below. Claims 8 and 15 stand or fall with claim 1 because they recite commensurate limitations in system and computer-readable-medium form.
Applicant argument: the claim is not mental because it is performed by a processing device
Response: Not persuasive. A claim can still recite a mental process even when implemented on a computer. Further, a generic computer implementation does not remove a claim from the mental-process grouping.
Applicant argument: a human could not practically perform the claimed matching because it involves many calculations
Response: Not persuasive. The claim does not recite any specific number of calculations, any particular algorithmic complexity, or any kernel-specific operation. Under BRI, the claim encompasses mental comparison of command sequences to predefined patterns and selection of actions based on the match.
Applicant argument: the claim is integrated into a practical application because it performs process-level and system-level remedial actions
Response: Not persuasive. The claim recites those actions only functionally and at a high level of desired result. It does not recite a specific technical implementation for those remedial actions, and thus does not transform the abstract analysis into a practical application.
Applicant argument: the claim improves computing technology by improving attack pattern matching
Response: Not persuasive. The alleged improvement is not captured in the claim with sufficient technological specificity. The claims do not recite particular technical features.
Regarding the 102/103 rejection to the claims, the arguments are fully considered but moot in view of new ground of rejection (new reference Parla et al. is applied).
Regarding argument to limitation “First action comprising a process-level remedial action directed to the process transmitting the at least part of the sequence of commands”, Govardhan expressly teaches remedial action directed to the malware-associated execution behavior, including: blocking the process associated with the matched commands; monitoring the process; isolating the device associated with the matched commands; suspending the instructions being executed by the processor; blocking execution of the malware; undoing changes made by the malware. See, e.g., Govardhan ¶¶ 0018, 0026, 0041, 0042, 0050, 0052. These disclosures make clear that Govardhan does not merely detect the malicious behavior, but also applies a remedial action to the offending execution context. The new reference Parla further reinforces this teaching by expressly disclosing actions directed to the offending process, including killing the process, terminating the VM/container, blocking specific function calls, blocking communications, and ejecting the offending process. See Parla ¶¶ 0061–0067, 0129–0138, 0204–0205. Accordingly, the combination teaches or renders obvious a remedial action that is directed to the process associated with the detected malicious sequence.
Regarding argument to limitation “Identifying a severity level associated with the predefined attack pattern”, Applicant argues that Govardhan’s security risk score does not teach identifying a severity level associated with the predefined attack pattern. This argument is also unpersuasive. Govardhan teaches a severity-based framework in which:
a security risk score is dynamically determined, a security threat zone is determined,
and a predicted security threat is generated based on those values. See Govardhan ¶¶ 0027, 0028, 0035. Govardhan further explains that different threat zones correspond to different levels of threat and that as indicators reach predefined thresholds, the system threat level increases. This is the functional equivalent of associating a severity level with the detected attack pattern. The claim does not require use of the exact words “severity level” in the prior art; it requires the functional concept of a value indicative of severity. Govardhan’s risk score/threat zone framework meets that concept. The new reference Parla further strengthens this by expressly teaching risk-based response selection, including: risk classification of system calls, high-risk versus low-risk behavior,
and action selection based on risk. See Parla ¶¶ 0103, 0134, 0167, 0175, 0204. Thus, the claimed severity-level concept is taught or rendered obvious by the combination.
Regarding argument to limitation “Performing a second action corresponding to the severity level, the second action comprising a system-level remedial action regarding a device implementing the process”, Applicant’s argument that Govardhan does not disclose a system-level action tied to the severity/risk score is not persuasive. Govardhan expressly teaches that, upon pattern match and threat escalation, the system may take remedial measures including: isolating the device, sending notifications, blocking the process, suspending events/activities, undoing malicious changes. See Govardhan ¶¶ 0018, 0026, 0041, 0042, 0050, 0052. The new reference Parla further teaches broader process level actions, including: killing the process, terminating the VM, terminating the container, block specific function calls or communications, and etc. See paragraphs [0061]–[0067], [0076]–[0078], [0129]–[0133], [0138]], [0204]–[0205]. See further Parla ¶¶ 0123, 0130, 0136–0138, 0184, 0228 for additional remediation types. Thus, the claimed second action corresponding to severity is supported by the combined teachings of the references.
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, 3-8, 10-15 and 17-23 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception without significantly more. Under Step 1, claims 1, 3-7, and 17-23 are directed to a process, claims 8 and 10-14 are directed to a machine, and claims 15 and 17-20 are directed to a manufacture, and thus fall within statutory categories.
Under Step 2A, Prong 1, representative claims 1, 8, and 15 recite an abstract idea, namely mental processes, because they recite observing and analyzing information and making decisions based thereon, as shown by the limitations of “identifying … a sequence of commands … within a specified time window,” “matching the at least part of the sequence of commands to a predefined attack pattern,” “identifying a first action,” “identifying a severity level associated with the predefined attack pattern,” and “performing a second action corresponding to the severity level”; under a broadest reasonable interpretation, these limitations amount to collecting command information, comparing it to known patterns, evaluating severity, and deciding responses, which are acts that can be performed in the human mind or with pen and paper. Dependent claims 3, 10, and 17 further recite generic information organization in a data structure; claims 4, 11, and 18 further recite generic analytical techniques, i.e., “machine learning, text matching, or graph matching,” which are additional abstract analysis and/or mathematical concepts; claims 5, 12, and 19 add mere data gathering from command interfaces; claims 6, 13, and 20 merely recite use of eBPF as a tool for collecting data; claims 7 and 14 add post-solution record creation and storage; claim 21 recites generic remedial outputs such as blocking, isolating, or notifying; claim 22 recites accessing a stored value indicating a remedial action; and claim 23 recites retrieving and selecting predefined severity values, all of which remain within the abstract idea.
Under Step 2A, Prong 2, the claims do not integrate the recited abstract idea into a practical application because the additional elements do not recite any specific technological improvement or concrete technical implementation for collecting commands, matching commands to attack patterns, or carrying out the claimed remedial actions, but instead merely invoke generic computer components and generic cybersecurity context, e.g., a processing device, memory, process, device, time window, data structure, dataset, and broadly recited process-level or system-level actions, which amount to no more than field-of-use limitations, insignificant extra-solution activity, and result-oriented functional language.
Under Step 2B, the claims do not recite an inventive concept because the additional elements, individually and as an ordered combination, are no more than well-understood, routine, and conventional computer and security-monitoring components and functions, as supported by the Specification’s disclosure of generic processors, memory, operating systems, kernels, user space, datasets, records, conventional matching techniques including machine learning/text matching/graph matching, known eBPF technology, and conventional security responses such as blocking, isolating, monitoring, or notifying (see, e.g., Spec. [0013], [0015]-[0019], [0022]-[0033], [0035]-[0043], [0055]-[0067]).
Accordingly, claims 1, 3-8, 10-15, and 17-23 are directed to an abstract idea and do not include additional elements sufficient to amount to significantly more than the abstract idea itself.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1, 3-8, 10-15 and 17-23 are is/are rejected under 35 U.S.C. 103 as being unpatentable over Govardhan (US 20190197239 A1) in view of Parla et al. (US 2024/0031394 A1).
Regarding claims 1, 8 and 15, Govardhan teaches method, system and non-transitory computer-readable media storing instructions, when executed, cause a processing device to perform operation (Abstract; para. 0005, [0018] The system 100 may include one or more processors 101, a computer-readable medium (e.g., a memory) 10… The computer-readable storage medium 102 may store instructions that, when executed by the one or more processors 101, cause the one or more processors 101 to…) comprising:
identifying, by a processing device, a sequence of commands [collected from a process] (monitoring instructions being executed by a processor and determining events triggered and activities performed by those instructions. See ¶ [0005], ¶ [0017], ¶ [0033]; correlating those events and activities to determine a sequence of events and activities. See ¶ [0005], ¶ [0025], ¶ [0033], ¶ [0034]), the process transmitting at least part of the sequence of [commands], within a specified time window (monitoring execution of instructions in real time and correlating those instructions into a sequence. See ¶ [0017], ¶ [0025], ¶ [0033], ¶ [0035]; the system may detect behavior based on a sequence of events and activities as they occur during execution. See ¶ [0025], ¶ [0033], ¶ [0035]; [0037]–[0038]: capture system processes/services/registry/data activities using OPCODE trapper; para. 0025, [t]he sequence monitor 204 may correlate the events and activities reported by the event monitor 201 and the activities monitor 202 either directly or through the OPCODE trapper 203. The sequence monitor 204 may then determine a sequence of events and activities based on the correlation. Further, the sequence monitor may receive a topographical threat map from the cognitive engine 205. As will be described in detail below, the topographical threat map may be event and activity behavior map of different categories of malwares, and may be generated by the cognitive engine 205 based on a cognitive analysis of external knowledge, or historic knowledge. The sequence monitor 204 may map the sequence of events and activities with the received topographical threat map to detect a pattern match corresponding to a malware. In some embodiments, the sequence monitor 204 may overlay the correlated flow of events and activities with the topographic threat map so as to check for the pattern match. In other words, the sequence monitor 204 may determine whether the determined sequence of events and activities is analogous to or similar to a sequence of event and activities demonstrated by the malware using the topographical threat map. If the pattern match is detected, the anomaly (i.e., suspicious sequence of events and activities) is reported to the cognitive engine 205);
responsive to matching the at least part of the sequence of commands to a predefined attack pattern of a plurality of predefined attack patterns (mapping the sequence of events and activities with a topographical threat map to detect a pattern match corresponding to a malware. See ¶ [0005], ¶ [0017], ¶ [0025], ¶ [0033], ¶ [0035]; a topographical threat map i.e., an event and activity behavior map of a plurality of categories of malwares. See ¶ [0005], ¶ [0017], ¶ [0025], ¶ [0034]), identifying a first action, the first action comprising a [process-level] remedial action [directed to the process transmitting] the at least part of the sequence of commands (blocking the process associated with the matched commands and isolating the device associated with the matched commands. See ¶ [0018], ¶ [0041], ¶ [0042]; upon detecting a pattern match, the system effects a remedial measure to prevent the malware by constructing remedial instructions. See ¶ [0005], ¶ [0017], ¶ [0026], ¶ [0033], ¶ [0034]; remedial measures include suspending the instructions being executed by the processor, blocking execution of the malware, or undoing the changes made by the malware. See ¶ [0026], ¶ [0034], ¶ [0050], ¶ [0052]; para. 0026, [t]he cognitive engine 205 may employ deep-learning algorithms to build behavioral profiles for different malwares, and, in some embodiments, different versions or variations of different malwares. The cognitive engine 205 may connect to internal data sources (e.g., database of security device with historic knowledge of malwares, enterprise security database, etc.) or external data sources (e.g., Internet with external knowledge of malwares) for continuous learning of new threats and patterns of malwares. The cognitive engine 205 may then generate topography threat map based on events and activity of various categories of malware infections. The topographic threat map may have indicators for each critical markers. As one or more critical markers reach a pre-defined corresponding thresholds, a threat level of system may be increased closer to a malware infection. The cognitive engine 205 may determine a pattern match based on the inputs received from sequence monitor 204 that monitors the critical markers. The cognitive engine may then effect a remedial measure to prevent the malware upon detecting the pattern match corresponding to the malware. For example, the cognitive engine 205 may instruct the remediation controller 206 to construct a remediation package (e.g., remedial instructions) based on the profile of the malware, and push the remediation package to the system processor 207 for preventing the malware. As will be appreciated, such remedial measure may be effected in real-time);
performing the first action (para. 0026, [t]he cognitive engine may then effect a remedial measure to prevent the malware upon detecting the pattern match corresponding to the malware. For example, the cognitive engine 205 may instruct the remediation controller 206 to construct a remediation package (e.g., remedial instructions) based on the profile of the malware, and push the remediation package to the system processor 207 for preventing the malware. As will be appreciated, such remedial measure may be effected in real-time. The remedial measures may include, but are not limited to, suspending the instructions being executed by the processor (i.e., blocking the execution of the malware), suspending the plurality of events, blocking the plurality of activities, or undoing the changes made by the malware).
identifying a severity level associated with the predefined attack pattern, the severity level comprising a value indicative of a severity of a result of the predefined attack pattern ([0027]: dynamically determining a security risk score, a security threat zone, predicting a security threat based on score and zone; [0028]: threat zones increase from Threat Zone-1 to Threat Zone-3; [0035]: predicting security threat based on risk score and security threat zone); and
performing a second action corresponding to the severity level, the second action comprising a system-level remedial action regarding a device implementing the process transmitting the at least part of the sequence of commands (0026]: remedial measures performed to prevent malware; [0027], [0033], [0035]: remedial measure based on predicted security threat; [0050]–[0052]).
Govardhan teaches a system-level remediation against malware infection generally.
However, it does not specifically teach command sequences collected from a process within a specified time window; a process-level remedial action directed to the transmitting process; severity level associated with a predefined attack pattern;
Parla et al. teaches identifying a sequence of commands collected from a process, the process transmitting at least part of the sequence of commands, within a specified time window ([0194]–[0197]: observation phase, telemetry representing execution, control flow directed graph generation; [0200]–[0205]: telemetry representing execution of a process, determining a transfer of an instruction pointer, and validating a predetermined number of transitions before a system call; [0166]–[0169]: intercepted system calls and CPU telemetry processed to make enforcement decisions based on a predetermined number of transitions; [0096]–[0097]: determining a system call during execution and determining a predetermined number of transitions leading to the system call… control-flow telemetry analogue: it collects and evaluates execution transitions during runtime, including transitions preceding a system call, within a bounded telemetry window);
identifying a first action, the first action comprising a process-level remedial action directed to the process transmitting the at least part of the sequence of commands ([0061]–[0067]: enforcement actions including killing the process, terminating the VM, blocking function calls, blocking communications; [0076]–[0078]: determining an action to terminate the process based on validity; blocking a set of system calls; excluding communications; [0129]–[0133]: kill the process, terminate VM/container, block specific function calls or communications; [0138]: halt the faulting instruction and eject the offending process; [0204]–[0205]: action to terminate the process; blocking system calls; allowing/disallowing execution based on validity);
identifying a severity level associated with the predefined attack pattern, the severity level comprising a value indicative of a severity of a result of the predefined attack pattern ([0134]: system calls may be classified based on behavior and given a risk score; [0167]: differing telemetry lengths may be based on differences in system call type, destinations, and/or risk scored; [0175]: risk-based technique; functions with system calls are high risk; low-risk vs high-risk system calls; permissions and data can affect risk; [0204]: determining an action may be based on a risk score; [0103]: risk profile depends on OS, permissions, data passed … risk scoring / risk profile / high-risk vs low-risk classification);
performing a second action corresponding to the severity level, the second action comprising a system-level remedial action regarding a device implementing the process transmitting the at least part of the sequence of commands ([0130]: terminate VM or container; [0136]–[0137]: CPU-freeze operation, sidecar hardware sending violation to another component outside CPU/OS ecosystem; [0138]: halt instruction, OS kills execution, suspend threads, terminate process entirely; [0204]: action based on risk score; [0123]: control center can direct response such as kill process, shut down host, etc.).
Therefore, it would have been obvious to one ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Govardhan’s attack pattern-matching approach with the Parla et al.’s system-level enforcement logic to enable graduated, device-level remediation tied to the seriousness of the detected behavior, which improves containment and operational flexibility; and to provide a structured severity indicator that can drive more calibrated remediation, rather than using a single undifferentiated response for all matches.
Regarding claims 3, 10 and 17, Govardhan in view of Parla et al. teaches all of the limitations of claims 1, 8 and 15, respectively, as shown above. Govardhan further teaches wherein the predefined attack pattern is stored in a data structure, wherein the data structure comprises a plurality of records, wherein each record of the plurality of records specifies a particular sequence of commands and a corresponding attack pattern (dataset can contain multiple records corresponding to different predefined attack patterns and that each attack pattern may be stored as a representative parameter or fingerprint. See Govardhan [0015], [0016], [0032], [0034], [0035]; para. 0049, computer system 601 may store user/application data 621, such as the data, variables, records, etc. (e.g., events, activities, sequence of events and activities, topographical threat map, remedial measures, security risk scores, security threat zones, predicted security threat, and so forth) as described in this disclosure. Such databases may be implemented as fault-tolerant, relational, scalable, secure databases such as Oracle or Sybase. Alternatively, such databases may be implemented using standardized data structures, such as an array, hash, linked list, struct, structured text file (e.g., XML), table, or as object-oriented databases (e.g., using ObjectStore, Poet, Zope, etc.). Such databases may be consolidated or distributed, sometimes among the various computer systems discussed above in this disclosure. It is to be understood that the structure and operation of the any computer or database component may be combined, consolidated, or distributed in any working combination).
Regarding claims 4, 11 and 18, Govardhan in view of Parla et al. teaches all of the limitations of claims 1, 8 and 15, respectively, as shown above. Govardhan further teaches wherein matching the at least part of the sequence of commands to the predefined attack pattern, and wherein matching the at least part of the sequence of commands to the predefined attack pattern further comprises: using a pattern matching technique comprising at least one of: machine learning, text matching, or graph matching (para. 0038, the control logic 500 may build behavior pattern for operating system events and activities for continuous self-learning and for pattern matching with the topographic threat maps. The event and activity monitoring platforms 201 and 202 (including individual sensors or micro-sensors), the OPCODE trapper 203, and the sequence monitor 204 may interface with the cognitive engine 205 to enable machine-learning capability onto each of the above module. This will support in continuous self-learning of the system environment, thus enabling each agent and modules to work independently and reduce latency occurring due to consistent communication; para. 0039, the control logic 500 may monitor for anomalous changes to the normal behavior pattern and report to the cognitive engine for remediation action. The event and activity-monitoring platform 201 and 202 may collate system events and user actions behavior details in real-time. In some embodiments, the monitoring platform 201 and 202 may provide the container space for micro-sensors 201-1-201-5 and 202-1-202-3, which may then monitor the OPCODEs of system events and user actions in real-time. This data may then be analyzed by the sequence monitor 204 using the machine-learning algorithm, to check for any anomaly. If any anomaly detected is detected, the information may be fed into the deep learning algorithm in-built in the sequence monitor 204 to check if sequence of events and activities detected is anomaly or not. If any anomaly is detected in the sequence of events and activities, the information may be further fed to the cognitive engine 205 for further and deeper anomaly analysis; transforming command sequences into a numeric vector or attack fingerprint and comparing those vectors using a threshold-based similarity measure. See Govardhan [0016]). Parla et al. teaches commands collected from the process and processor level remediation (([0194]–[0197]: observation phase, telemetry representing execution, control flow directed graph generation; [0200]–[0205]: telemetry representing execution of a process, determining a transfer of an instruction pointer, and validating a predetermined number of transitions before a system call; [0166]–[0169]: intercepted system calls and CPU telemetry processed to make enforcement decisions based on a predetermined number of transitions; [0175]: risk-based technique; functions with system calls are high risk; low-risk vs high-risk system calls; permissions and data can affect risk;). The rational for combining is the same as claim 1 above.
Regarding claims 5, 12 and 19, Govardhan in view of Parla et al. teaches all of the limitations of claims 1, 8 and 15, respectively, as shown above. Govardhan further teaches further comprising: identifying a plurality of command interfaces associated with the device implementing the process, wherein identifying the sequence of commands further comprises obtaining commands received by each command interface of the plurality of command interfaces during the specified time window (para. 0047, [t]he memory devices may store a collection of program or database components, including, without limitation, an operating system 616, user interface application 617, web browser 618, mail server 619, mail client 620, user/application data 621 (e.g., any data variables or data records discussed in this disclosure), etc. The operating system 616 may facilitate resource management and operation of the computer system 601. Examples of operating systems include, without limitation, Apple Macintosh OS X, Unix, Unix-like system distributions (e.g., Berkeley Software Distribution (BSD), FreeBSD, NetBSD, OpenBSD, etc.), Linux distributions (e.g., Red Hat, Ubuntu, Kubuntu, etc.), IBM OS/2, Microsoft Windows (XP, Vista/7/8, etc.), Apple iOS, Google Android, Blackberry OS, or the like. User interface 617 may facilitate display, execution, interaction, manipulation, or operation of program components through textual or graphical facilities. For example, user interfaces may provide computer interaction interface elements on a display system operatively connected to the computer system 601, such as cursors, icons, check boxes, menus, scrollers, windows, widgets, etc. Graphical user interfaces (GUIs) may be employed, including, without limitation, Apple Macintosh operating systems' Aqua, IBM OS/2, Microsoft Windows (e.g., Aero, Metro, etc.), Unix X-Windows, web interface libraries (e.g., ActiveX, Java, Javascript, AJAX, HTML, Adobe Flash, etc.), or the like; para. 0048, application programming interfaces (APIs); identifying one or more command interfaces associated with the monitored system and collecting commands from those interfaces during the window. Although Govardhan uses broader terminology such as shells, APIs, and user interfaces, the disclosure expressly contemplates multiple interfaces from which execution-related inputs are obtained and monitored. See Govardhan [0028], [0030], [0031], [0034], [0035].).
Regarding claim 7, Govardhan in view of Parla et al. teaches all of the limitations of claim 1, as shown above. Govardhan further comprising: subsequent to matching the at least part of the sequence of commands to the predefined attack pattern, creating a record [specifying the matched sequence of commands and the corresponding predefined attack pattern]; and storing the record in a dataset that includes the predefined attack pattern (para. 0049, In some embodiments, computer system 601 may store user/application data 621, such as the data, variables, records, etc. (e.g., events, activities, sequence of events and activities, topographical threat map, remedial measures, security risk scores, security threat zones, predicted security threat, and so forth) as described in this disclosure. Such databases may be implemented as fault-tolerant, relational, scalable, secure databases such as Oracle or Sybase. Alternatively, such databases may be implemented using standardized data structures, such as an array, hash, linked list, struct, structured text file (e.g., XML), table, or as object-oriented databases (e.g., using ObjectStore, Poet, Zope, etc.). Such databases may be consolidated or distributed, sometimes among the various computer systems discussed above in this disclosure. It is to be understood that the structure and operation of the any computer or database component may be combined, consolidated, or distributed in any working combination).
Govardhan teaches detecting a malware pattern by mapping a monitored sequence to a topographical threat map. However, Govardhan does not expressly teach creating a record of the matched sequence and corresponding pattern.
Parla et al. further discloses creating a record of the matched sequence and corresponding pattern (Prla’s teaches telemetry, anomalies, reports, and graph updates creating a stored record tied to the observed execution: see: [0093]–[0097]: telemetry is accumulated, decoded, compared to the learned graph, and can result in enforcement/action; [0104]–[0105]: unobserved transitions are classified and may be added to the learned control flow graph if safe; [0110]–[0111]: real-time anomaly reports can be generated and provided to a cloud-based exploit reporting tool; [0164]–[0165]: a vulnerability or tainted code portion can be identified, converted into a graph representation, and excluded/marked in the learned graph; [0181]–[0184]: reports and data can be shared, updated, and used to adapt policies; [0211]–[0225]: unobserved transitions may be added to the learned graph if deemed safe; Parla teaches collecting execution telemetry, generating structured anomaly/report data, and updating a learned security data structure based on observed behavior and vulnerabilities.).
Accordingly, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Govardhan’s malware detection system in view of Parla to record and store the matched sequence and corresponding attack pattern after a successful match, because Parla teaches collecting monitored execution data, generating structured anomaly/exploit information, and using that information to update a learned security representation. A person of ordinary skill would have been motivated to preserve the match result in the dataset for future comparison, auditability, and improvement of detection accuracy, thereby yielding a predictable use of prior-art elements according to their established functions.
Regarding claim 14, Govardhan in view of Parla et al. teaches the system of claim 8, wherein the operations further comprises:
subsequent to matching the at least part of the sequence of commands to the predefined attack pattern, creating a record [specifying the matched sequence of commands and the corresponding predefined attack pattern]; and storing the record in a dataset that includes the predefined attack pattern (para. 0049, In some embodiments, computer system 601 may store user/application data 621, such as the data, variables, records, etc. (e.g., events, activities, sequence of events and activities, topographical threat map, remedial measures, security risk scores, security threat zones, predicted security threat, and so forth) as described in this disclosure. Such databases may be implemented as fault-tolerant, relational, scalable, secure databases such as Oracle or Sybase. Alternatively, such databases may be implemented using standardized data structures, such as an array, hash, linked list, struct, structured text file (e.g., XML), table, or as object-oriented databases (e.g., using ObjectStore, Poet, Zope, etc.). Such databases may be consolidated or distributed, sometimes among the various computer systems discussed above in this disclosure. It is to be understood that the structure and operation of the any computer or database component may be combined, consolidated, or distributed in any working combination).
Govardhan teaches detecting a malware pattern by mapping a monitored sequence to a topographical threat map. However, Govardhan does not expressly teach creating a record of the matched sequence and corresponding pattern.
Parla et al. further discloses creating a record of the matched sequence and corresponding pattern (Prla’s teaches telemetry, anomalies, reports, and graph updates creating a stored record tied to the observed execution: see: [0093]–[0097]: telemetry is accumulated, decoded, compared to the learned graph, and can result in enforcement/action; [0104]–[0105]: unobserved transitions are classified and may be added to the learned control flow graph if safe; [0110]–[0111]: real-time anomaly reports can be generated and provided to a cloud-based exploit reporting tool; [0164]–[0165]: a vulnerability or tainted code portion can be identified, converted into a graph representation, and excluded/marked in the learned graph; [0181]–[0184]: reports and data can be shared, updated, and used to adapt policies; [0211]–[0225]: unobserved transitions may be added to the learned graph if deemed safe; Parla teaches collecting execution telemetry, generating structured anomaly/report data, and updating a learned security data structure based on observed behavior and vulnerabilities.).
Accordingly, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Govardhan’s malware detection system in view of Parla to record and store the matched sequence and corresponding attack pattern after a successful match, because Parla teaches collecting monitored execution data, generating structured anomaly/exploit information, and using that information to update a learned security representation. A person of ordinary skill would have been motivated to preserve the match result in the dataset for future comparison, auditability, and improvement of detection accuracy, thereby yielding a predictable use of prior-art elements according to their established functions.
Regarding claim 21, Govardhan in view of Parla et al. teaches the method of claim 1. Parla et al. further teaches wherein the process-level remedial action comprises blocking the process transmitting the sequence of commands ([0061]: simply kill the process; [0129]: kill the process; [0138]: OS expected to eject offending process; suspend threads or terminate entirely
[0204]–[0205]: action to terminate the process based on validity … blocking/terminating the process as a remedial action); and
wherein the system-level remedial action comprises at least one of isolating the device implementing the process or communicating a notification regarding the severity level ([0123]: control center may direct response, including shutting down the monitored host; [0137]: CPU-freeze operation from outside OS/CPU ecosystem; [0184]: dynamic policy changes based on attack in progress; [0228]: cloud-based exploit reporting tool and reporting to centralized system; [0106]–[0111]: control plane receives reports and can provide exploit data to other systems … host/device isolation-like responses through shutdown/freezing and centralized reporting, supports reporting/notification-type outputs via control center/cloud reporting).The rational for combining is the same as claim 1.
Regarding claim 22, Govardhan in view of Parla et al. teaches the method of claim 3. Parla et al. further teaches wherein identifying the first action comprises accessing a value indicating the process-level remedial action that is stored with the predefined attack pattern in the data structure (0134]: system calls can be classified based on behavior and given a risk score
[0175]: risk-based technique, with system calls classified high/low risk; [0204]: action may be based on a risk score; [0132]: different function-call blocking based on execution context/permissions; [0167]: differing telemetry / enforcement based on risk … accessing or applying a risk score / risk classification to determine the action taken). The rational for combining is the same as claim 1.
Regarding claim 23, Govardhan in view of Parla et al. teaches the method of claim 3. Parla et al. further teaches wherein identifying the severity level comprises retrieving a set of predefined values of the severity level stored with the predefined attack pattern in the data structure; and selecting the severity level from the set of predefined values based on a field of the predefined attack pattern ([0134]: risk score associated with a system call; [0175]: low-risk / high-risk classifications; [0204]: action based on risk score; [0103]: risk profile depends on system, permissions, and passed data; [0167]: risk score influences how much telemetry is used and how the call is handled …selecting a severity/risk level from predefined values based on a field or attribute of the detected behavior). The rational for combining is the same as claim 1.
Claims 6, 13 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Govardhan (US 20190197239 A1) in view of Parla et al. (US 2024/0031394 A1), and further in view of Southgate et al. (US 20240281352 A1), hereinafter, Southgate.
Regarding claims 6, 13 and 20, Govardhan in view of Parla et al. teaches all of the limitations of claims 1, 8 and 15, respectively, as shown above. Govardhan further teaches collecting command-like execution inputs from a runtime environment and monitoring them in user space. See Govardhan [0013], [0014], [0028], [0031], [0035].
Govardhan does not explicitly teach wherein identifying the sequence of commands is performed by an extended Berkeley packet filter (eBPF). However, in an analogous art, Southgate teaches wherein identifying the sequence of commands is performed by an extended Berkeley packet filter (eBPF) (para. 0051, [t]he AI monitoring service 48 may determine the AI behavior 38 based on the network traffic 120. The AI agent 22 may report all packet headers to the AI monitoring service 48. The AI monitoring service 48 may even receive and inspect encrypted network traffic 122, such as by inspecting packet headers in HTTPS traffic (such as by using the extended Berkeley Packet Filter or eBPF) to extract and identify security observability data).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the invention to implement Govardhan’s command collection using a kernel-efficient tracing mechanism such as eBPF, because eBPF was well known as a safe, low-overhead mechanism for extracting runtime observability data from live execution paths without materially changing the monitored program. Southgate provides the specific example of eBPF as an appropriate extraction tool, and Govardhan provides the target monitoring use case. (Southgate para. 0051).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 20240031403 A1: collecting a sequence of commands from a process and comparing it to a predefined malicious pattern[0004], [0011], [0012], [0017]–[0019] [0052]–[0059]
US 6370648 B1: Computer Network Intrusion Detection using command sequence
US 20130212669 A1: command-stream sequencing, pattern validation, and remedial suspension/termination of processes in an industrial control environment
US 20190228154 A1: A malware-sequence-learning; process-level malicious behavior detection and process termination
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ELENI A SHIFERAW whose telephone number is (571)272-3867. The examiner can normally be reached 7-3:30 M-F.
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.
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.
/ELENI A SHIFERAW/Supervisory Patent Examiner, Art Unit 2497
Prosecution Insights