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 .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 06/18/2025, 01/05/2026, and 05/05/2026 have been considered by the examiner.
Drawings
Figures 13 and 15 are objected to because they contain blurry portions. Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. The figure or figure number of an amended drawing should not be labeled as “amended.” If a drawing figure is to be canceled, the appropriate figure must be removed from the replacement sheet, and where necessary, the remaining figures must be renumbered and appropriate changes made to the brief description of the several views of the drawings for consistency. Additional replacement sheets may be necessary to show the renumbering of the remaining figures. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
Claim Objections
Claims 1 and 2 are objected to because of the following informalities:
In claims 1 and 2, “the lineage including a list a globally unique identifier” should read “the lineage including a list of globally unique identifiers.”
Appropriate correction is required.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are:
“a timeline service configured to perform” in claim 18.
“the threat management facility is configured to augment” in claim 20.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof. For “a threat management facility” see specification [para. 0052] for the structure.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
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.
Claim 4 is 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.
Regarding claim 4, the claim recites “a natural language explanation of the detection”. It is unclear if the term “the detection” is referring to “detecting a security event” or “threat detection”, therefore, the claim is rendered indefinite. For the purpose of examination, the term “the detection” will be interpreted as referring to the detected security event.
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 2-7 and 11-17 have been rejected under 35 U.S.C. § 101 under the 2019 PEG framework. The claim recites a judicial exception (an abstract idea falling within the “mental processes” grouping) that is not integrated into a practical application.
Step 1: Statutory Category. Claims 2-7 and 11-17 satisfy the statutory category requirement because it is directed to a “process” under 35 U.S.C. § 101(a). The claims recite a system/series of steps, including at least detecting a security event, identifying multiple processes, and creating a lineage for the security event, and displaying the lineage.
Step 2A, Prong 1: Identification of Judicial Exception. Claims 2-7 and 11-17 recite multiple judicial exceptions within the abstract idea category. The claims recite data analysis and information processing: “detecting a security event”, “identifying a plurality of related processes”, and “creating a lineage for the security event” constitute mental processes that could be performed by a human using paper and pencil.
Step 2A, Prong 2: Integration into a Practical Application. Claims 2-7 and 11-17 fail the integration analysis. The claims recite “transmitting the lineage to a threat management facility… for use in visualization” which merely uses a computer as a tool to perform an abstract idea. The claims recite a detection of a security event and identifying related processes, however, there is no recitation of mitigation/action being done in response to the detection.
Step 2B: Significantly More / WURC Analysis. The additional elements of “augmenting the lineage with additional data”, is merely data generating operations which are well-understood, routine, and conventional in the field of cybersecurity. The additional element “transmitting the lineage to a threat management facility… for use in visualization” merely uses a computer as a tool to perform an abstract idea. Therefore, the claims do not recite additional elements that amount to significantly more than the abstract idea.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claim(s) 1-3, 5-9, and 11-13, and 15-19 is/are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent Number 12,206,696 B1 To Kapoor et al. (Kapoor).
Regarding claim 1, Kapoor teaches a computer program product comprising computer executable code embodied in a non-transitory computer readable medium (Kapoor Col. 3, lines 34-51, e.g., a computer program product embodied on a computer readable storage medium…… computer program instructions) that, when executing on one or more processors (Kapoor Col. 3, lines 34-51, e.g., a processor, such as a processor configured to execute instructions stored on and/or provided by a memory coupled to the processor), causes the one or more processors to perform the steps of: detecting a security event on a compute instance associated with an enterprise network (Kapoor Col. 6, lines 52-62, e.g., An agent (e.g., agent 112) monitors its node (e.g., node 116) for network activity. One example way that agent 112 can monitor node 116 for network activity is by using a network packet capture tool (e.g., listening using libpcap). As packets are received (202), the agent obtains and maintains (e.g., in an in memory cache) connection information associated with the network activity (204)); identifying a plurality of related processes including: a first process associated with the security event (Kapoor Col. 6, 7, lines 63-67, 1-5, e.g., The agent also determines a process associated with the network connection (206). One example approach is for the agent to use a kernel network diagnostic API (e.g., netlink_diag) to obtain inode/process information from the kernel. Another example approach is for the agent to scan using netstat to obtain sockets and relate them to processes; Col. 8, lines 17-26, e.g., Once the agent has determined which process is associated with the network connection (206), the agent can then collect additional information associated with the process (208). As will be described in more detail below, some of the collected information comprises attributes of the process (e.g., a process parent hierarchy)), one or more parent processes that launched the first process (Kapoor Fig. 28B, e.g., sudo (parent process) launches sneak.sh (first process); Col. 8, lines 17-26, e.g., As will be described in more detail below, some of the collected information comprises attributes of the process (e.g., a process parent hierarchy)), and one or more child processes launched by the first process (Kapoor Fig. 28B, e.g., sneak.sh (first process) launches post.sh (child process); Col. 8, lines 17-26, e.g., As will be described in more detail below, some of the collected information comprises attributes of the process (e.g., a process parent hierarchy)); creating a lineage for the security event (Kapoor Col. 13, lines 28-40, e.g., In particular, using techniques described herein, periodic graphs can be constructed (also referred to herein as polygraphs), in which the nodes are applicable logical entities, and the edges represent behavioral relationships between the logical entities in the graph. Baselines can be created for every node and edge; Col. 13, 14, lines 57-67, 1-5, e.g., Examples of process level information collected by agents include attributes (user ID, effective user ID, and command line). Information such as what user/application is responsible for launching a given process and the binary being executed (and its SHA-256 values) is also provided by agents), the lineage including a list a globally unique identifier for each of the plurality of related processes for the security event (Kapoor Col. 24, lines 1-14, e.g., The cumulative graph (also referred to herein as a cumulative PType graph and a polygraph) is a running model of how processes behave over time. Nodes in the cumulative graph are PType nodes, and provide information such as a list of all active processes and PIDs in the last hour), each globally unique identifier further including: a process identifier for a corresponding one of the related processes (Kapoor Col. 24, lines 1-14, e.g., Nodes in the cumulative graph are PType nodes, and provide information such as a list of all active processes and PIDs in the last hour), [and a time stamp for the corresponding one of the related processes] ; transmitting the lineage to a threat management facility associated with the enterprise network for use in visualizing the security event (Kapoor Col. 13, lines 16-27, e.g., As previously mentioned, platform 102 can model activities that occur within datacenters, such as datacenters 104 and 106; Col. 16, lines 6-21, e.g., In the following examples, suppose that Bob, an administrator of datacenter 106, is interacting with platform 102 to view visualizations of polygraphs in a web browser (e.g., as served to him via web app 120); Col. 15, lines 39-55, e.g., FIG. 7 illustrates a communication polygraph for a datacenter. In particular, the polygraph indicates a one hour summary of approximately 500 virtual machines, which collectively run one million processes, and make 100 million connections in that hour. As illustrated in FIG. 7, a polygraph represents a drastic reduction in size (e.g., from tracking information on 100 million connections in an hour, to a few hundred nodes and a few hundred edges). Further, as a datacenter scales up (e.g., from using 10 virtual machines to 100 virtual machines as the datacenter uses more workers to support existing applications), the polygraph for the datacenter will tend to stay the same size (with the 100 virtual machines clustering into the same nodes that the 10 virtual machines previously clustered into). As new applications are added into the datacenter, the polygraph will automatically scale to include behaviors involving those applications); augmenting the lineage with additional data from the threat management facility (Kapoor Col. 13, lines 4-15, e.g., Customer data included in database 142 can be augmented with data from additional data sources, such as AWS Cloud Trail Analyzer 144, which is another microservice. AWS Cloud Trail Analyzer 144 pulls data using Amazon Cloudtrail for each applicable customer account, as soon as the data is available. AWS Cloud Trail Analyzer 144 normalizes the Cloudtrail data as applicable, so that it can be inserted into database 142 for later querying/analysis); and displaying [the lineage and] the additional data to a user as a threat timeline visualization (Col. 51, lines 1-12, e.g., Alice notes in the timeline (3316) that a user, Harish, connected to a known bad server (examplebad.com) using wget, an event that has a critical severity level. Alice can click on region 3318 to expand details about the event inline (which will display, for example, the text “External connection made to known bad host examplebad.com at port 80 from application ‘wget’ running on host dev1.lacework.internal as user harish”) directly below line 3316. Alice can also click on region 3320, which will take her to a dossier for the event (depicted in FIG. 34). As will be described in more detail below, a dossier is a template for a collection of visualizations).
Kapoor does not explicitly teach a lineage including a list of process IDs and timestamps for each of the plurality of related process. However, Kapoor teaches the collection of timestamps for processes (Col. 5, lines 16-39, e.g., example type of information sent by agent 112 to data aggregator 114 is event data (described in more detail below), which includes a UTC timestamp for each event; and Fig. 3A, e.g., “created_time”). Kapoor also teaches the graph containing a list of all active processes and PIDs in the last hour (Kapoor Col. 24, lines 1-14, e.g., Nodes in the cumulative graph are PType nodes, and provide information such as a list of all active processes and PIDs in the last hour). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have modified Kapoor to include the timestamps with the list of active processes and PIDs because the creation time is already collected and the list of active processes is sorted by time (last hour) and include timestamps yields the expected result of supplementing the lineage with more accurate timestamp data.
Kapoor does not explicitly teach displaying the lineage that has been augmented with additional data. However, Kapoor teaches displaying data for visualization by querying a database (Kapoor Col. 50, lines 37-49, e.g., FIG. 33 illustrates an example of a user interacting with a portion of an interface. When a user visits platform 102 (e.g., via web app 120 using a browser), data is extracted from database 142 as needed (e.g., by query service 166), to provide the user with information, such as the visualizations depicted variously throughout the Specification (e.g., in FIGS. 9 and 33). As the user continues to interact with such visualizations (e.g., clicking on graph nodes, entering text into search boxes, navigating between tabs (e.g., tab 3302 vs. 3322)), such interactions act as triggers that cause query service 166 to continue to obtain information from database 142 as needed). Kapoor also teaches customer data being augmented with additional data in the database (Kapoor Col. 13, lines 4-15, e.g., Customer data included in database 142 can be augmented with data from additional data sources, such as AWS Cloud Trail Analyzer 144). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to have modified Kapoor to display lineage that has been augmented with additional data because the data being queried from database 142 (customer data) is already augmented with additional data. A person of ordinary art would be motivated to make this modification in order to provide the user with the additional already collected information thus enabling the user to better assess vulnerabilities.
Regarding claim 2, Kapoor teaches a method comprising: detecting a security event on a compute instance associated with an enterprise network (Kapoor Col. 6, lines 52-62, e.g., An agent (e.g., agent 112) monitors its node (e.g., node 116) for network activity. One example way that agent 112 can monitor node 116 for network activity is by using a network packet capture tool (e.g., listening using libpcap). As packets are received (202), the agent obtains and maintains (e.g., in an in memory cache) connection information associated with the network activity (204)); identifying a plurality of related processes including: a first process associated with the security event (Kapoor Col. 6, 7, lines 63-67, 1-5, e.g., The agent also determines a process associated with the network connection (206). One example approach is for the agent to use a kernel network diagnostic API (e.g., netlink_diag) to obtain inode/process information from the kernel. Another example approach is for the agent to scan using netstat to obtain sockets and relate them to processes; Col. 8, lines 17-26, e.g., Once the agent has determined which process is associated with the network connection (206), the agent can then collect additional information associated with the process (208). As will be described in more detail below, some of the collected information comprises attributes of the process (e.g., a process parent hierarchy)), one or more parent processes that launched the first process (Kapoor Fig. 28B, e.g., sudo (parent process) launches sneak.sh (first process); Col. 8, lines 17-26, e.g., As will be described in more detail below, some of the collected information comprises attributes of the process (e.g., a process parent hierarchy)), and one or more child processes launched by the first process (Kapoor Fig. 28B, e.g., sneak.sh (first process) launches post.sh (child process); Col. 8, lines 17-26, e.g., As will be described in more detail below, some of the collected information comprises attributes of the process (e.g., a process parent hierarchy)); creating a lineage for the security event (Kapoor Col. 13, lines 28-40, e.g., In particular, using techniques described herein, periodic graphs can be constructed (also referred to herein as polygraphs), in which the nodes are applicable logical entities, and the edges represent behavioral relationships between the logical entities in the graph. Baselines can be created for every node and edge; Col. 13, 14, lines 57-67, 1-5, e.g., Examples of process level information collected by agents include attributes (user ID, effective user ID, and command line). Information such as what user/application is responsible for launching a given process and the binary being executed (and its SHA-256 values) is also provided by agents), the lineage including a list a globally unique identifier for each of the plurality of related processes for the security event (Kapoor Col. 24, lines 1-14, e.g., The cumulative graph (also referred to herein as a cumulative PType graph and a polygraph) is a running model of how processes behave over time. Nodes in the cumulative graph are PType nodes, and provide information such as a list of all active processes and PIDs in the last hour), each globally unique identifier further including: a process identifier for a corresponding one of the related processes (Kapoor Col. 24, lines 1-14, e.g., Nodes in the cumulative graph are PType nodes, and provide information such as a list of all active processes and PIDs in the last hour), [and a time stamp for the corresponding one of the related processes]; and transmitting the lineage to a threat management facility associated with the enterprise network for use in visualizing the security event (Kapoor Col. 13, lines 16-27, e.g., As previously mentioned, platform 102 can model activities that occur within datacenters, such as datacenters 104 and 106; Col. 16, lines 6-21, e.g., In the following examples, suppose that Bob, an administrator of datacenter 106, is interacting with platform 102 to view visualizations of polygraphs in a web browser (e.g., as served to him via web app 120); Col. 15, lines 39-55, e.g., FIG. 7 illustrates a communication polygraph for a datacenter. In particular, the polygraph indicates a one hour summary of approximately 500 virtual machines, which collectively run one million processes, and make 100 million connections in that hour. As illustrated in FIG. 7, a polygraph represents a drastic reduction in size (e.g., from tracking information on 100 million connections in an hour, to a few hundred nodes and a few hundred edges). Further, as a datacenter scales up (e.g., from using 10 virtual machines to 100 virtual machines as the datacenter uses more workers to support existing applications), the polygraph for the datacenter will tend to stay the same size (with the 100 virtual machines clustering into the same nodes that the 10 virtual machines previously clustered into). As new applications are added into the datacenter, the polygraph will automatically scale to include behaviors involving those applications).
Kapoor does not explicitly teach a lineage including a list of process IDs and timestamps for each of the plurality of related processes. However, Kapoor teaches the collection of timestamps for processes (Col. 5, lines 16-39, e.g., example type of information sent by agent 112 to data aggregator 114 is event data (described in more detail below), which includes a UTC timestamp for each event; and Fig. 3A, e.g., “created_time”). Kapoor also teaches the graph containing a list of all active processes and PIDs in the last hour (Kapoor Col. 24, lines 1-14, e.g., Nodes in the cumulative graph are PType nodes, and provide information such as a list of all active processes and PIDs in the last hour). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have modified Kapoor to include the timestamps with the list of active processes and PIDs because the creation time is already collected and the list of active processes is sorted by time.
Regarding claim 3, most of the limitations of this claim have been noted in the rejection of claim 2. Kapoor further teaches wherein the security event includes a threat detection (Kapoor Col. 13, lines 41-57, e.g., A model of communications between processes is an example of a behavioral model. As another example, the launching of applications is another example of a behavior that can be modeled. The baselines are updated hourly for every entity. Deviations from the expected normal behavior can then be detected and automatically reported (e.g., as anomalies or threats detected). Such deviations may be due to a desired change, a misconfiguration, or malicious activity).
Regarding claim 5, most of the limitations of this claim have been noted in the rejection of claim 2. Kapoor further teaches comprising transmitting the lineage to a data store for the enterprise network for short term use in visualization (Kapoor Col. 12, lines 54-67, e.g., DB Loader 140 is a microservice that is responsible for loading data into an appropriate database service (142), such as SnowflakeDB or Amazon Redshift. DB Loader 140 manages throughput, errors, etc., to make sure that data is loaded consistently and continuously; Col. 50, lines 37-49, e.g., FIG. 33 illustrates an example of a user interacting with a portion of an interface. When a user visits platform 102 (e.g., via web app 120 using a browser), data is extracted from database 142 as needed (e.g., by query service 166), to provide the user with information, such as the visualizations depicted variously throughout the Specification (e.g., in FIGS. 9 and 33). As the user continues to interact with such visualizations (e.g., clicking on graph nodes, entering text into search boxes, navigating between tabs (e.g., tab 3302 vs. 3322)), such interactions act as triggers that cause query service 166 to continue to obtain information from database 142 as needed; Fig. 1, e.g., Database 142) and to a data lake for the enterprise network for long term storage (Kapoor Col. 12, lines 36-53, e.g., Kinesis is a streaming service with a limited period (e.g., 1-7 days). To persist data longer than a day, it is copied to long term storage (e.g., S3). S3 Loader 136 is a microservice that is responsible for picking up data from Kinesis stream 134 and persisting it in S3 (138); Fig. 1, e.g., Long-term storage (S3) 138).
Regarding claim 6, most of the limitations of this claim have been noted in the rejection of claim 2. Kapoor teaches wherein the time stamp includes a Unix epoch time in milliseconds (Kapoor Col. 8, lines 41-49, e.g., Depicted in FIG. 3A is initial information collected by an agent about a process. Region 302 indicates the time at which the agent generated event 300; Fig. 3A e.g., “created time”: 1501626889179; this format is a UNIX Epoch time in milliseconds which translates to Tue Aug 01 2017 18:34:49).
Regarding claim 7, most of the limitations of this claim have been noted in the rejection of claim 2. Kapoor further teaches wherein the security event includes at least one of a registry update, a network request, a file action, and a process launch (Kapoor Col. 4, lines 21-36, e.g., Agents monitor the nodes on which they execute for a variety of different activities, including: connection, process, user, machine, and file activities; Col. 51, lines 48-67, e.g., A second example of an Activity is a “launch” Activity, in which a parent process launches a child process (with a directed edge from the parent to the child)).
Regarding claim 8, most of the limitations of this claim have been noted in the rejection of claim 2. Kapoor further teaches displaying the lineage to a user as a threat timeline visualization (Kapoor Col. 50, lines 50-67, e.g., In the example shown in FIG. 33, ACME administrator Alice is viewing a dashboard that provides various information about ACME users (3302), during the time period March 2 at midnight—March 25 at 7 pm (which she selected by interacting with region 3304). Various statistical information is presented to Alice in region 3306. Region 3308 presents a timeline of events that occurred during the selected time period).
Regarding claim 9, most of the limitations of this claim have been noted in the rejection of claim 8. Kapoor further teaches augmenting the threat timeline visualization with reputation data for one or more of the plurality of related processes (Kapoor Col. 51, lines 1-12, e.g., Alice notes in the timeline (3316) that a user, Harish, connected to a known bad server (examplebad.com) using wget, an event that has a critical severity level. Alice can click on region 3318 to expand details about the event inline (which will display, for example, the text “External connection made to known bad host examplebad.com at port 80 from application ‘wget’ running on host dev1.lacework.internal as user harish”) directly below line 3316; Col. 20, lines 36-47, e.g., ThreatAggr (150) is a microservice that is responsible for obtaining third party threat information from various applicable sources, and making it available to other micro-services. Examples of such information include reverse DNS information, GeoIP information, lists of known bad domains/IP addresses, lists of known bad files etc; Note ThreatAggr (150) provides reputation data (i.e. list of known bad domains/ip address) and makes it available to other micro-services. User can expand details in the timeline about event inline which will display, for example, the text “External connection made to known bad host”).
Regarding claim 11, most of the limitations of this claim have been noted in the rejection of claim 2. Kapoor further teaches wherein the first process causes the security event (Kapoor Col. 48, lines 1-35, e.g., Suppose Bill's credentials are compromised by a nefarious outsider (“Eve”). FIG. 28B depicts an embodiment of how the graph depicted in FIG. 28A would appear once Eve begins exfiltrating data from the datacenter. Eve logs into the datacenter (using Bill's credentials) from 52.5.66.8 (2852). As Bill, Eve escalates her privilege to root (e.g., via su), and then becomes a different user, Alex (e.g., via su alex). As Alex, Eve executes a script, “sneak.sh” (2854), which launches another script, “post.sh” (2856), which contacts external server 2858 which has an IP address of 52.5.66.7, and transmits data to it. Edges 2860-2866 each represent changes in Bill's behavior. As previously mentioned, such changes can be detected as anomalies and associated alerts can be generated. As a first example, Bill logging in from an IP address he has not previously logged in from (2860) can generate an alert. As a second example, while Bill does typically make use of sudo (2806), he has not previously executed sneak.sh (2854) or post.sh (2856) and the execution of those scripts can generate alerts as well. As a third example, Bill has not previously communicated with server 2858, and an alert can be generated when he does so (2866); Fig. 28A and 28B).
Regarding claim 12, most of the limitations of this claim have been noted in the rejection of claim 2. Kapoor further teaches wherein the security event includes a known risk associated with the first process (Kapoor Col. 48, lines 36-47, e.g., In some cases, a single edge can indicate a serious threat. For example, if server 2852 (or 2858) is included in a known bad IP listing, edge 2860 (or 2866) indicates compromise. An alert that includes an appropriate severity level (e.g., “threat level high”) can be generated. In other cases, a combination of edges could indicate a threat (where a single edge might otherwise result in a lesser warning). In the example shown in FIG. 28B, the presence of multiple new edges is indicative of a serious threat. Of note, even though “sneak.sh” and “post.sh” were executed by Alex, because platform 102 also keeps track of an original user, the compromise of Bob's account will be discovered).
Regarding claim 13, most of the limitations of this claim have been noted in the rejection of claim 2. Kapoor further teaches wherein the lineage includes at least one related process that is not a child process or a parent process of the first process (Kapoor Fig. 28B, e.g., sneak.sh (first process) is related to root’s application (sibling process) via sudo (parent process)).
Regarding claim 15, most of the limitations of this claim have been noted in the rejection of claim 2. Kapoor further teaches wherein the lineage includes at least one process that is related to the first process through a static detection on the compute instance (Kapoor Col. 10, lines 54-61, e.g., As mentioned above, agents can be configured to report certain types of information (e.g., attribute information) once, when the agent first becomes aware of a process. In various embodiments, such static information is not reported again (or is reported once a day, every twelve hours, etc.), unless it changes (e.g., a process changes its parent, changes its owner, or a SHA-1 of the binary associated with the process changes)).
Regarding claim 16, most of the limitations of this claim have been noted in the rejection of claim 2. Kapoor further teaches wherein the lineage includes at least one process that is related to the first process based on shared detection criteria (Kapoor Col. 23, lines 25-62, e.g., FIG. 18 illustrates an example of a process for detecting anomalies in a network environment…… At 1804, a logical graph model is generated, using at least a portion of the monitored activities…… Another example of a model is a CType model, which clusters together processes that share command line similarity. Yet another example of a model is a PType model, which clusters together processes that share behaviors over time).
Regarding claim 17, most of the limitations of this claim have been noted in the rejection of claim 2. Kapoor further teaches wherein the lineage includes at least one process executing on a second endpoint (Kapoor Col. 39, lines 50-57, e.g., FIG. 23 depicts a representation of a user logging into a first machine, then into a second machine from the first machine, and then making an external connection. The scenario depicted in FIG. 23 is used to describe an example of processing that can be performed on data collected by agents to generate extended user session tracking information).
Regarding claim 18, the claim recites a system performing the method of claim 2, and is similarly analyzed.
Regarding claim 19, the claim recites a system performing the method of claim 5, and is similarly analyzed.
Claim(s) 4, 10, and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kapoor in view of US Publication No. 20240414211 A1 to Boyer et al. (Boyer).
Regarding claim 4, most of the limitations of this claim have been noted in the rejection of claim 3. Kapoor further teaches augmenting the threat detection (Kapoor Col. 13, lines 4-15, e.g., Customer data included in database 142 can be augmented with data from additional data sources, such as AWS Cloud Trail Analyzer 144, which is another microservice. AWS Cloud Trail Analyzer 144 pulls data using Amazon Cloudtrail for each applicable customer account, as soon as the data is available. AWS Cloud Trail Analyzer 144 normalizes the Cloudtrail data as applicable, so that it can be inserted into database 142 for later querying/analysis).
Kapoor does not explicitly teach, but Boyer teaches augmenting the threat detection with a natural language explanation of the detection (Boyer [0060], e.g., The cyber security components and the LLMs 188 assist humans in summarizing current breaches and then also suggest how to prioritize the order in which an organization should triage breaches in a native human, friendly way; [0061], e.g., the summary and added information produced by the LLM 188 helps to prioritize model breaches including alerts produces in the past timeframe, for example, of the last 24 hours. The LLM 188 explains terminology, breaches and their scores and relatedness, and draws upon other contextual sources, such as threat intelligence, to ensure that those summarizations for other audiences are more compelling).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to have modified the teachings of Kapoor with the teachings of Boyer with reasonable expectation of success. One of ordinary skill in the art would have been motivated to make the modification for the benefit of leveraging speed and computational power of AI to detect and respond to threats more efficiently (Boyer [0104], e.g., In addition to its technical capabilities, the artificial intelligence-based cyber threat analyst module 120 facilitates human-machine collaboration to tackle the challenges posed by adversaries. By leveraging the speed and computational power of AI, combined with human expertise and intuition, security teams can gain a significant advantage. The tool serves as a force multiplier, augmenting the capabilities of security analysts and enabling them to detect and respond to threats more efficiently; [0113], e.g., Note, the cyber threat analyst module 120 cooperating with the AI model(s) 160 trained with machine learning on how to form cyber threat hypotheses and how to conduct investigations for a cyber threat hypothesis in the AI-based cyber security appliance 100 provides an advantage as it reduces the time taken for human led or cyber security investigations, provides an alternative to manpower for small organizations and improves detection (and remediation) capabilities within the cyber security appliance 100)
Regarding claim 10, most of the limitations of this claim have been noted in the rejection of claim 8. Kapoor does not explicitly teach, but Boyer further teaches augmenting the threat timeline visualization with natural language explanations of causal relationships among the plurality of related processes (Boyer [0061], e.g., The summary and added information produced by the LLM 188 helps to prioritize model breaches including alerts produces in the past timeframe, for example, of the last 24 hours. The LLM 188 explains terminology, breaches and their scores and relatedness, and draws upon other contextual sources, such as threat intelligence, to ensure that those summarizations for other audiences are more compelling; [0157], e.g., The process identifier classifier (not shown) in the gather module 110 can cooperate with additional classifiers in each of the domain modules 145/150 to assist in tracking individual processes and associating them with entities in a domain under analysis as well as individual processes and how they relate to each other).
The motivation to combine is the same as that of claim 4.
Regarding claim 20, most of the limitations of this claim have been noted in the rejection of claim 18. Kapoor further teaches wherein the threat management facility is configured to augment the timeline with at least one of reputation data for one or more of the plurality of processes [and a natural language explanation of causal relationships among the plurality of processes] (Kapoor Col. 51, lines 1-12, e.g., Alice notes in the timeline (3316) that a user, Harish, connected to a known bad server (examplebad.com) using wget, an event that has a critical severity level. Alice can click on region 3318 to expand details about the event inline (which will display, for example, the text “External connection made to known bad host examplebad.com at port 80 from application ‘wget’ running on host dev1.lacework.internal as user harish”) directly below line 3316; Col. 20, lines 36-47, e.g., ThreatAggr (150) is a microservice that is responsible for obtaining third party threat information from various applicable sources, and making it available to other micro-services. Examples of such information include reverse DNS information, GeoIP information, lists of known bad domains/IP addresses, lists of known bad files etc; Note ThreatAggr (150) provides reputation data (i.e. list of known bad domains/ip address) and makes it available to other micro-services. User can expand details in the timeline about event inline which will display, for example, the text “External connection made to known bad host”).
Kapoor does not explicitly teach, but Boyer teaches wherein the threat management facility is configured to augment the timeline with a natural language explanation of causal relationships among the plurality of processes (Boyer [0061], e.g., The summary and added information produced by the LLM 188 helps to prioritize model breaches including alerts produces in the past timeframe, for example, of the last 24 hours. The LLM 188 explains terminology, breaches and their scores and relatedness, and draws upon other contextual sources, such as threat intelligence, to ensure that those summarizations for other audiences are more compelling; [0157], e.g., The process identifier classifier (not shown) in the gather module 110 can cooperate with additional classifiers in each of the domain modules 145/150 to assist in tracking individual processes and associating them with entities in a domain under analysis as well as individual processes and how they relate to each other).
The motivation to combine is the same as that of claim 4.
Claim(s) 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kapoor in view of US Publication No.20200404007 A1 to Singh et al. (Singh).
Regarding claim 14, most of the limitations of this claim have been noted in the rejection of claim 2. Kapoor does not explicitly teach, but Singh further teaches wherein the lineage includes at least one process that is related to the first process through a code injection (Singh [0223], e.g., FIG. 8 shows a dynamic call graph when the OS command injection exploit is sent to the vulnerable application in accordance with an embodiment of the invention. As seen from the dynamic call graph due to the exploitation, a new node having the value “/bin/ls”, the injected OS command, is spawned. This value of the additional node due to OS Command injection exploitation can be traced up the graph and is the same as the appended command “is” to the value field “kral.php” of the GET method. The command “ls” is separated by the delimiter “;”. Besides “;”other delimiters which can be used to inject OS command in Linux and Windows environment are “|”, “;”, “&”, “$”, “>”, “<”, “\”, “!”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to have modified the teachings of Kapoor with the teachings of Singh with reasonable expectation of success. One of ordinary skill in the art would have been motivated to make the modification for the benefit of automatically identifying vulnerable parts of code and aiding in patching the code to prevent further exploitation (Singh [0329]-[0330] Approaches taken using algorithms to detect injection-based exploitation according to embodiments of the invention can provide at least the following inherent advantages: It identifies the injection vulnerability in the code during the invocation of the program execution functions, SQL, NoSQL and/or query execution functions. With each detected exploitation attempt, the vulnerable code path can also be detected. This automatic identification of the vulnerable part of the code can aid in patching the code preventing further exploitation)
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claim 18 is provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claim 20 of copending Application No. 19/096,234 (reference application). Although the claims at issue are not identical, they are not patentably distinct from each other.
This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
19/096,152 (Instant)
19/096,234 (co-pending application)
18. A system comprising: a local security agent executing on an endpoint, the local security agent configured to perform the steps of: detecting a security event, creating a lineage for the security event, the lineage including identifiers and time stamps for a plurality of processes associated with the security event, the plurality of processes including at least a first process that caused the security event, a second process that is a parent of the first process, and a third process that is a child of the first process, and transmitting the lineage to a threat management facility for an enterprise network associated with the endpoint; and a threat management facility, the threat management facility executing a timeline service configured to perform the steps of: receiving the lineage from the local security agent, and graphically presenting a timeline for the security event to a user based on the lineage.
20. A system comprising: a threat management facility for an enterprise network; a local security agent executing on an endpoint associated with the enterprise network, the local security agent configured to perform the steps of: detecting a security event; creating a lineage for the security event, the lineage including identifiers and time stamps for a plurality of processes associated with the security event, the plurality of processes including at least a first process that caused the security event, a second process that is a parent of the first process, and a third process that is a child of the first process; and transmitting the lineage to the threat management facility for the enterprise network associated with the endpoint; and a data lake storing a plurality of temporal partitions for event data from the enterprise network, the data lake optimized for long term storage of unstructured data, wherein the threat management facility executes a timeline service configured to perform the steps of: displaying a graphical representation of the security event to a user as a threat timeline visualization based on the lineage, and progressively updating the threat timeline visualization with data from the data lake based on periodic queries to the data lake using a time stamp for one of the plurality of processes identified in the lineage.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. US 20230262074 A1 to Guo et al. discloses techniques to facilitate clear visualization of an attack progression in real-time, including origination, movement within the network, and the current state. Security analyst utilize the visualization to identify weakness and mitigate the attack.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LAWRENCE TRUONG whose telephone number is (571)272-6973. The examiner can normally be reached Monday - Friday, 8:00 am - 4 pm ET.
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, Ali Shayanfar can be reached at (571) 270-1050. 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.
/LAWRENCE TRUONG/Examiner, Art Unit 2434
/NOURA ZOUBAIR/Primary Examiner, Art Unit 2434
Prosecution Insights