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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 02/16/2026 has been entered.
Response to Arguments
The present office action is responsive to communication filed on 02/16/2026. Claims 1, 3, 4, 9, and 12 have been amended. Claims 2 and 10 are cancelled. Claims 21 and 22 have been added. Claims 1, 3-9, 11-22 are currently pending.
Applicant’s arguments and amendments, with respect to 35 USC 112(a) , as seen on pages 10-12 of the Remarks, have been fully considered and are persuasive. Therefore, the rejection under 35 USC 112(a) has been withdrawn.
Applicant’s argument, with respect to the rejections of claims 1 and 9 under 35 USC 103 over Zhu et al. (US-20210182387-A1) in view of Golshan et al. (US-9686293-B2), Meir et al. (US-20210067531-A1), Efron et al. (US-20170359376-A1), and Bhogal et al. (US-20170109261-A1) with the amended limitations, as seen in pages 12-15, of the Remarks, are met have been fully considered and are persuasive. Therefore, the rejection have been withdrawn. However, upon further consideration, a new grounds of rejection of is made in view of Aharoni et al. (US Pat No. 11010469-B2), Eshkenazi et al. (US PGPub No. 20180107821-A1), and Soryal et al. (US Pat No. 11741225-B2).
The office action have been updated reflecting the claims as currently presented.
Claim Objections
Claim 1 is objected to because of the following informalities: “…conducting by the analysis module of the security agent…” should be amended to “…conducting by an analysis module of the security agent…”. Appropriate correction is required.
Claims 1 and 9 objected to because of the following informalities: “…including by excluding at least one known legitimate enumeration request...” is a paradoxical phrase acting as a technical oxymoron, and it should be amended for purposes of clarity. 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 following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
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:
“…determining, by prediction unit whether the storage operation is indicative of a malicious enumeration…” in claim 1.
“…a prediction unit… analyze the tracked storage operations of the process to determine whether the storage operations is indicative of a malicious enumeration…” in claim 9.
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.
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 the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1, 3-9, 11-22 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Regarding claims 1 and 9:
Claims 1 and 9 recite the limitations, “…determining, by the prediction unit, whether the storage operation is indicative of a malicious enumeration including by excluding at least one known legitimate enumeration request …” , and “…conducting, by the analysis module of the security agent, advanced analysis of the process to determine whether the process is a malicious process.”. The specification fails to demonstrate that the applicant possessed the step of making the determination by the prediction unit whether the storage operation is indicative of a malicious enumeration. As explained in MPEP § 2161.01, the written description requirement is separate and distinct from enablement, and requires that the specification describe the claimed invention in sufficient detail that one of ordinary skill in the art can reasonably conclude that the inventor had possession of the claimed invention at the time of filing. This requirement applies to computer-implemented inventions recited in functional terms, and simply restating the claimed function or a desired result is not sufficient. Rather, the specification must disclose the computer and the algorithm, steps, or procedure for performing the claimed function in sufficient detail to show possession of that functionality. See Ariad Pharm., Inc. v. Eli Lilly & Co., 598 F.3d 1336, 1351 (Fed. Cir. 2010); LizardTech, Inc. v. Earth Res. Mapping, Inc., 424 F.3d 1336, 1345-46 (Fed. Cir. 2005); Vasudevan Software, Inc. v. MicroStrategy, Inc., 782 F.3d 671, 681-83 (Fed. Cir. 2015); Finisar Corp. v. DirecTV Grp., Inc., 523 F.3d 1323, 1340 (Fed. Cir. 2008).
The specification does identify some inputs or clues. It says maliciousness may be indicated by request data parameters such as file mask, request frequency, requests to enumerate many files or root folders, and sequential folder enumeration, and it also says the security sensor can detect enumeration requests of a particular volume, folder, or file type such as *.doc, *.pdf, and *.xls. Those passages support that certain characteristics of enumeration activity are relevant. However, under MPEP § 2161.01 and the cited case law, identifying relevant inputs or factors does not by itself provide adequate written description support for a functionally claimed determination unless the specification also explains how those factors are actually used to perform the determination.
Moreover, the key gap is the actual decision logic supposedly used by the prediction unit. The disclosure says that the prediction unit performs a “preliminary analysis” to check whether an event/process includes malicious enumeration, and that the ML module is trained on a malware dataset and preliminary verdict data. It then says the attack predictor analyzes the storage operation, generates a first probabilistic value, and compares “resulting parameters of the analysis” to parameters related to known malware attacks to determine a degree of similarity. That is still very high level. It never really explains what features are extracted from the storage operation, how those features are encoded, what the “resulting parameters” are, what constitutes a match or exclusion, or how the system distinguishes malicious enumeration from legitimate enumeration beyond the result-oriented statement that false positives are ruled out. In other words, the disclosure describes the desired result of the analysis, but not how the claimed determination is actually performed. As MPEP § 2161.01 explains, original claims may lack written description when they define the invention in functional language specifying a desired result but the specification does not sufficiently describe how the function is performed or the result is achieved. This is the same type of deficiency identified by the Patent Trial and Appeal Board (PTAB) in previous instances (see Ex parte Corville Allen et al., 2020-005211), where claims reciting computer-based analysis (e.g., classification, scoring, or determination steps) were found unsupported because the specification only described the desired result and general factors, but failed to disclose how the determination was actually performed (e.g., how scores were generated, how comparisons were made, or what specific logic governed the outcome).
That problem becomes more pronounced with the amended claim language. The claim now requires “determining … whether the storage operation is indicative of malicious enumeration including by excluding at least one known legitimate enumeration request”. But the specification, as quoted by the applicant in the remarks, mainly points to ¶6 and ¶41 for this point, i.e., suspicious enumeration requests and a preliminary analysis/filter that rules out false positives. Those passages do not appear to disclose any concrete exclusion rule, whitelist structure, classifier feature set, thresholding mechanism for legitimate requests, or other algorithm for performing the claimed exclusion of known legitimate enumeration requests. As reflected in MPEP § 2161.01, generic or functional claim language does not satisfy the written description requirement where the specification fails to support the full scope of the claimed genus, and a disclosure of one general objective does not entitle the applicant to claim any and all means for achieving that objective. As reflected in the earlier-cited PTAB decision, Ex parte Corville Allen et al., merely identifying relevant considerations (e.g., suspicious patterns or factors) without explaining how those considerations are operationalized into a determination is insufficient to demonstrate possession of the claimed functionality, particularly where the claim recites a specific determination—here, excluding known legitimate enumeration requests—that is not tied to any disclosed logic or algorithm.
Claims 3-8 and 11-22 do not overcome the rejection of their respective base claims that have been rejected above, and therefore rejected under the same grounds provided to claims 1 and 9.
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-9, and 11-22 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Claim 1 recites a method which appears to a ‘process’ and one of the four statutory subject matter categories of invention (Step 1 of the Subject Matter Eligibility Test).
However, the claim appears to qualify for a streamlined analysis thus a full eligibility and thus a full eligibility analysis is a necessary (Step 2A and Step 2B of the Subject Matter Eligibility Test).
In Step 2A, Prong One, examiners evaluate whether the claim recites a judicial exception, i.e., whether a law of nature, natural phenomenon, or abstract idea is set forth or described in the claim. The claim recites the steps of:
“…tracking… one or more system events of a process…”
“…determining a sequence of operations… associated with one or more system events …”
“…monitoring… the sequence of operations…”
“…analyzing… the storage operations…”
“…determine whether the storage operation corresponds to an enumeration request…”
“…determining.... whether the storage operation is indicative of malicious enumeration including by excluding at least one known legitimate enumeration request…”
“…generating a first verdict indicative of a suspicious process…”
“when the first verdict is indicative of a suspicious process, conducting… advanced analysis of the process…”
“…determine whether the process is a malicious process based on analysis of a full stack trace including by comparison of the full stack trace to at least one known preset pattern that corresponds to a known malicious process…”
“…receives a full stack trace…. characterizing… the particular process as malicious…”
“…when the advanced analysis determines that the process is a malicious process, and generating a second verdict indicative of the process being the malicious process.”
The steps performing amount to an abstract idea which falls under a judicial exception (Step 2A Prong 1, of Subject Matter Eligibility). Abstract ideas fall in the category. The abstract idea falls in the categories of a mental process, for example evaluation, judgements, and opinion and mathematical concepts (MPEP 2106.04(a)(2) & MPEP 2106.06) such as comparing enumeration request to an known legitimate enumeration request and comparing a process to a known preset process to determine an enumeration attack. For example, the courts found that a claim to "collecting information, analyzing it, and displaying certain results of the collection and analysis," where the data analysis steps are recited at a high level of generality, could practically be performed in the human mind, Electric Power Group v. Alstom, S.A., 830 F.3d 1350, 1353‐54, 119 USPQ2d 1739, 1741‐42 (Fed. Cir. 2016).
In Step 2A, Prong Two, examiner determine whether the claim as a whole integrates the judicial exception into a practical application to disqualify abstract as a judicial exception. However, the judicial exception in claim 1 Is not integrated into practical application because the generically recited computer elements:
“… a security sensor…”
“…a prediction unit of a security agent…”
“…the analysis module of the security agent…”
do not add meaningful limitation to an abstract idea because they do not add a meaningful limitation to an abstract idea because they amount to simply implementing the abstract idea on a computer. The implementation of using a one known legitimate enumeration request and one known preset pattern enabling human decision making without using the user actions in any meaningful to improve the functioning of a computer or another technology without reference to what is well-understood, routine, and conventional activity. The claim do not include additional elements that are sufficient to amount to significantly more than the judicial exception because simply appending well-understood, routine, conventional activities previously known to the industry, specified at a high level of generality, to the judicial exception, e.g., a claim to an abstract idea requiring no more than a generic computer to perform generic computer function that are well-understood, routine and conventional activities previously known to the industry, as discussed in Alice Corp., 573 U.S. at 225, 110 USPQ2d at 1984.
Thus, the analysis concludes is ineligible under 35 U.S.C. § 101 as it is directed to a judicial
exception.
Regarding to claims 3-8 and 21:
Claims 3-8 and 21 do not add any additional elements than those already disclosed in claim 1, and merely adds further abstract ideas. Furthermore, none of the claims integrate the judicial exception into a practical application.
Claim 9 recites a system which appears to a ‘machine’ and one of the four statutory subject matter categories of invention (Step 1 of the Subject Matter Eligibility Test).
However, the claim appears to qualify for a streamlined analysis thus a full eligibility and thus a full eligibility analysis is a necessary (Step 2A and Step 2B of the Subject Matter Eligibility Test).
In Step 2A, Prong One, examiners evaluate whether the claim recites a judicial exception, i.e., whether a law of nature, natural phenomenon, or abstract idea is set forth or described in the claim. The claim recites the steps of:
“…track one or more system events …”
“…determine a sequence of operations executed in response to the one or more system events of a process…”
“…monitor the sequence of operations…”
“…track the storage operation …”
“…analyze the tracked storage operations of the process to determine whether the storage operation is indicative of a malicious enumeration including by excluding at least one known legitimate enumeration request …”
“…generate a first security verdict indicative of a malicious process when the storage operation is indicative of a malicious enumeration…”
“…when the first verdict is indicative of a suspicious process: receive….full stack trace…”
“…perform an advanced analysis of the process, wherein the advanced analysis includes an analysis of the full stack trace including a comparison of the full stack trace at least one known preset pattern that corresponds to a known malicious process, to generate second verdict…”
“…characterize the process as a malicious process, when the advanced analysis determines that the process is malicious process.”
The steps performing amount to an abstract idea which falls under a judicial exception (Step 2A Prong 1, of Subject Matter Eligibility). Abstract ideas fall in the category. The abstract idea falls in the categories of a mental process, for example evaluation, judgements, and opinion and mathematical concepts (MPEP 2106.04(a)(2) & MPEP 2106.06) such as comparing enumeration request to an known legitimate enumeration request and comparing a process to a known preset process to determine an enumeration attack. For example, the courts found that a claim to "collecting information, analyzing it, and displaying certain results of the collection and analysis," where the data analysis steps are recited at a high level of generality, could practically be performed in the human mind, Electric Power Group v. Alstom, S.A., 830 F.3d 1350, 1353‐54, 119 USPQ2d 1739, 1741‐42 (Fed. Cir. 2016).
In Step 2A, Prong Two, examiner determine whether the claim as a whole integrates the judicial exception into a practical application to disqualify abstract as a judicial exception. However, the judicial exception in claim 9 Is not integrated into practical application because the generically recited computer elements:
“…one process… and memory operably coupled to the at least one processor…”
“…a security sensor…”
“…a security agent operably coupled the security sensor including a prediction unit comprising instructions stored in the memory that, when executed by the at least one processor, cause the at least one processor…”
“…an analysis module comprising instructions comprising instructions stored in the memory that…”
do not add meaningful limitation to an abstract idea because they do not add a meaningful limitation to an abstract idea because they amount to simply implementing the abstract idea on a computer. The implementation of using a one known legitimate enumeration request and one known preset pattern enabling human decision making without using the user actions in any meaningful to improve the functioning of a computer or another technology without reference to what is well-understood, routine, and conventional activity. The claim do not include additional elements that are sufficient to amount to significantly more than the judicial exception because simply appending well-understood, routine, conventional activities previously known to the industry, specified at a high level of generality, to the judicial exception, e.g., a claim to an abstract idea requiring no more than a generic computer to perform generic computer function that are well-understood, routine and conventional activities previously known to the industry, as discussed in Alice Corp., 573 U.S. at 225, 110 USPQ2d at 1984.
Thus, the analysis concludes is ineligible under 35 U.S.C. § 101 as it is directed to a judicial
exception.
Regarding to claims 11-20 and 22:
Claims 11-20 and 22 do not add any additional elements than those already disclosed in claim 9, and merely adds further abstract ideas. Furthermore, none of the claims integrate the judicial exception into a practical application.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
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.
Claims 1, 4, 7, 9, 12, and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Zhu et al. (US-20210182387-A1) in view of Aharoni et al. (US Pat No. 11010469-B2) and Eshkenazi et al. (US PGPub No. 20180107821-A1) .
With respect to claim 1, Zhu teaches a method for predicting data threats, the method comprising: tracking, by a security sensor, one or more system events of a process and determining a sequence of operations executed and associated with the one or more system events, (¶0004-0006: A new class of detection tries to port more and more intelligence into an endpoint. Intra-processor behavior modeling and detecting also is well-known, as evidenced by program anomaly detection literature, as well as most state-of-the-art commercial endpoint intrusion detection products. These mechanism basically monitor system events e.g., system calls and/or Windows APIs of each process, and then decide whether the process is malicious based on its behavior model.);
wherein each system event has an associated sequence of operations; (¶0055-0056: As seen in Figure 6, the computing system 605 being monitored may be implemented as described above with respect to Figure 2, and it is assumed to comprise executing a set of (runtime) processes 603. System events, e.g., system calls and API calls of each process 603, are continuously monitored and recorded e.g., in a data store 607. The particular manner in which the system events are monitored, identified and stored is not an aspect of this disclosure. In a typical implementation, system activities of this type are logged, e.g., by the operating system, or by via syscall monitoring and program instrumentation.);
monitoring, by the security sensor, the sequence of operations, (¶0039-0040: As seen in Figure 3, the platform provides search-driven data exploration, session reconstruction, and forensics intelligence to assist security incident investigation. In pertinent part, the platform 300 comprises a of packet capture appliances 302, an incident forensics module appliance 304, a distributed database 306, and a security intelligence console 308. The packet capture and module appliances are configured as network appliances, or they may be configured as virtual appliances. The packet capture appliances 302 are operative to capture packets off the network (using known packet capture (pcap) application programming interfaces (APIs) or other known techniques), and to provide such data (e.g., real-time log event and network flow) to the distributed database 306, where the data is stored and available for analysis by the forensics module 304 and the security intelligence console 308.);
wherein at least one of the sequence of operations is a storage operation; (¶0006: Although the system call is insufficient to understand the detailed behavior of an underlying program, it may reveal the actions and intent of attack at a high-level. For example, disk operations can be recorded by API call traces, and writes (e.g., to rundll32.exe) indicates that malicious code is injected in the system file. Excepting disk operations, other behaviors—e.g. communications with remote servers, registry changes, process spawning, and the like—usually are exhibited through system calls, and these behaviors thus are capable of being recorded by a monitoring system.).
Zhu does not disclose:
analyzing, by a prediction unit of a security agent, the storage operation associated with the process to determine whether the storage operation corresponds to an enumeration request of at least one of a volume, a folder, or a file type; determining, by the prediction unit whether the storage operation is indicative of a malicious enumeration including by excluding at least one known legitimate enumeration request, and
generating a first verdict indicative of a suspicious process when the storage operation is indicative of a malicious enumeration; and
However, Aharoni teaches analyzing, by a prediction unit of a security agent, (¶0002: Figure 1 is a process in which file open event is monitored for triggering a processing for preventing ransomware encrypting files on a target machine that is trigged based on a target machine that is triggered based on a file open event monitored using endpoint agent. ) the storage operation associated with the process to determine whether the storage operation corresponds to an enumeration request of at least one of a volume, a folder, or a file type; (¶0055-0056: In an example implementation, upon an open request to a protected directory, the endpoint agent performs a stack walk on the user mode part of the request and searches for return address in the stack. Referring to Figure 1, at 12, a file open event x is detected on a target system. For example, the file system event associated with x (e.g., x can be a directory or a file) can be detected using the mini filter driver. );
determining, by the prediction unit whether the storage operation is indicative of a malicious enumeration including by excluding at least one known legitimate enumeration request, and (¶0057-0058: At 104, whether x is on a protected volume (e.g., the configuration can be based on the volume’s drive letter and/or other criteria/attributes) is determined. At 106, whether x is protected directory is determined. For example, the endpoint agent can be configured with set of protected directories on the target system as described above. If x is a protected directory (known legitimate enumeration request) for further operations on the object as shown at 108.);
generating a first verdict indicative of a suspicious process when the storage operation is indicative of a malicious enumeration; and (¶0059: Otherwise (i.e., x is not a protected directory), processing continues at 110, and whether x is under a protected directory is determined. At 114, whether x is a target file (e.g., forged honeypot file) is determined. If x is a target file, then the endpoint agent determines whether file open of the file x is dangerous as shown at 118 (generating a first indicative of a suspicious process).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Aharoni with regards to the prediction unit to the method of Zhu in order to prevent ransomware and security risks (Aharoni ¶0001-0002).
Zhu in view of Aharoni does not disclose:
when the first verdict is indicative of a suspicious process, conducting, by the analysis module of the security agent, advanced analysis of the process to determine whether the process is a malicious process based on analysis of a full stack trace including by comparison of the full stack trace to at least one known preset pattern that corresponds to a known malicious process,
wherein the analysis module receives the full stack trace from the security sensor; and characterizing, by the analysis module of the security agent, the particular process as malicious when the advanced analysis determines that the process is a malicious process, and generating a second verdict indicative of the process being the malicious process.
However, Eshkenazi teaches when the first verdict is indicative of a suspicious process, conducting, by the analysis module of the security agent, (¶0097-0100: As seen in Figure 1, when an output is found to match a cached input, processor 40 checks whether the target of the output is potentially vulnerable to attack by the cached input, at a vulnerability checking step 66. If so, processor 40 invokes protective action, at a protection step 68, which is described in greater detail hereinbelow. Upon finding a match, detectors that have been instrumented into the application may apply various tests to the output in order to identify attacks at step 66. Tests used at step 66 to detect file-path manipulation vulnerabilities. The detector associated with such a method checks the corresponding file-path parameter against the cached inputs. If the target contains a cached input, the detector trims the input out of the target in order to get the path prefix (if it exists in the target). The detector may then convert the path to a canonical form in order to get the full, unique, absolute path. This conversion can be performed using methods that are known in the art, as provided, for example, by the C# methods known as Path.GetFullPath and HttpServerUtility.MapPath that are available as part of the Microsoft .NET framework and are described on the msdn Web site. Further ¶0114 shows in step 6 wherein RASP logic is utilized );
advanced analysis of the process to determine whether the process is a malicious process based on analysis of a full stack trace including by comparison of the full stack trace to at least one known preset pattern that corresponds to a known malicious process, (¶0007: In the disclosed embodiments, instrumenting the input points includes adding a sensor routine to each identified input point, wherein the sensor routine examines the input for syntax that is characteristic of an attack pattern. In one embodiment, the attack pattern is selected from a set of attack patterns consisting of SQL injection, cross-site scripting (XSS), file path manipulation, and JavaScript Object Notation (JSON) injection. Further in ¶0104: Figure 3, shows details on input/output identification step 50, in accordance with an embodiment in which static analysis used to enhance RASP instrumentation. The RASP patcher running on processor 26 uses the attack vectors provided by the SAST tool at step 72 in identifying instrumentation points to add to the corresponding assembly code. Specifically, the list of vector attack sources provided by the SAST tool includes, like the query results described above, corresponding method names and code context. The RASP patcher uses this information in converting the list of attack source locations in the source code to a list of RASP instrumentation points, and associates RASP sensor logic with these points at step 76);
wherein the analysis module receives the full stack trace from the security sensor; and characterizing, by the analysis module of the security agent, the particular process as malicious when the advanced analysis determines that the process is a malicious process, and generating a second verdict indicative of the process being the malicious process. (¶0101: If the canonical path does not contain the path prefix that was included in the target, the detector will recognize a possible attack at step 66, since the user input has apparently overridden the existing path prefix that was included in the target code and may thus gain access to a path that was not intended to be accessed by this output. In this case, the detector will typically raise an alert at step 68 regarding file-path manipulation and/or will take other preventive action. )
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Eshkenazi regards to the advanced analysis to the method of Zhu in view of Aharoni in order to protect the system again security vulnerability (Eshkenazi ¶0002).
With respect to claim 4, the combination of Zhu in view of Aharoni and Eshkenazi teaches the method of claim 1 (see rejection of claim 1 above), wherein the advanced analysis is at least one of static analysis or dynamic analysis. (Eshkenazi ¶0104: Figure 3, shows details on input/output identification step 50, in accordance with an embodiment in which static analysis used to enhance RASP instrumentation.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Eshkenazi regards to the advanced analysis to the method of Zhu in view of Aharoni in order to protect the system again security vulnerability (Eshkenazi ¶0002).
With respect to claim 7, the combination of Zhu in view of Aharoni and Eshkenazi teaches the method of claim 1 (see rejection of claim 1 above), further comprising: analyzing storage operation parameters including at least one of a file type, a volume, a file name or a file mask encoded into the storage operation. (Aharoni ¶0056-0057: Referring to Figure 1, at 102, a file open event x is detected on a target system. For example, the file system event associated with x (e.g., x can be a directory or a file) can be detected using the mini filter driver as described above. At 104, whether x is on a protected volume (e.g., the configuration can be based on the volume's drive letter and/or other criteria/attributes) is determined. For example, the endpoint agent can be configured with a set of protected volumes on the target system as similarly described above. If x is not a protected volume, then processing proceeds to 124.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Aharoni with regards to analyzing storage operation parameters to the method of Zhu in view of Eshkenazi in order to prevent ransomware and security risks (Aharoni ¶0001-0002).
With respect to claim 9, Zhu teaches a system for predicting an enumeration-based attack comprising: at least one processor and memory operably coupled to the at least one processor; (¶0027-0032: With reference now to Figure , a block diagram of a data processing system is shown in which illustrative embodiments may be implemented. Data processing system 200 is an example of a computer, such as server 104 or client 110 in Figure 1, in which computer-usable program code or instructions implementing the processes may be located for the illustrative embodiments. In this illustrative example, data processing system 200 includes communications fabric 202, which provides communications between processor unit 204, memory 206, persistent storage 208, communications unit 210, input/output (I/O) unit 212, and display 214. );
a security sensor configured to: track one or more system events and determine a sequence of operations executed in response to the one or more system events of a process, (¶0004-0006: A new class of detection tries to port more and more intelligence into an endpoint. Intra-processor behavior modeling and detecting also is well-known, as evidenced by program anomaly detection literature, as well as most state-of-the-art commercial endpoint intrusion detection products. These mechanism basically monitor system events e.g., system calls and/or Windows APIs of each process, and then decide whether the process is malicious based on its behavior model. Excepting disk operations, other behaviors—e.g. communications with remote servers, registry changes, process spawning, and the like—usually are exhibited through system calls, and these behaviors thus are capable of being recorded by a monitoring system. Stated another way, typically it is practical and potentially important to detect attacks at the level of API calls (attacks on API calls may be a form of a enumeration attack) and system events.);
wherein each system event has an associated sequence of operations and wherein at least one of the sequence of operations is a storage operation; (¶0006: Although the system call is insufficient to understand the detailed behavior of an underlying program, it may reveal the actions and intent of attack at a high-level. For example, disk operations can be recorded by API call traces, and writes (e.g., to rundll32.exe) indicates that malicious code is injected in the system file. Excepting disk operations, other behaviors—e.g. communications with remote servers, registry changes, process spawning, and the like—usually are exhibited through system calls, and these behaviors thus are capable of being recorded by a monitoring system.);
monitor the sequence of operations, and track the storage operation; (¶0039-0040: As seen in Figure 3, the platform provides search-driven data exploration, session reconstruction, and forensics intelligence to assist security incident investigation. In pertinent part, the platform 300 comprises a of packet capture appliances 302, an incident forensics module appliance 304, a distributed database 306, and a security intelligence console 308. The packet capture and module appliances are configured as network appliances, or they may be configured as virtual appliances. The packet capture appliances 302 are operative to capture packets off the network (using known packet capture (pcap) application programming interfaces (APIs) or other known techniques), and to provide such data (e.g., real-time log event and network flow) to the distributed database 306, where the data is stored and available for analysis by the forensics module 304 and the security intelligence console 308.);
Zhu does not disclose:
a security agent operably coupled to the security sensor, including a prediction unit comprising instructions stored in the memory that, when executed by the at least one processor, cause the at least one processor to analyze the tracked storage operations of the process to determine whether the storage operation is indicative of a malicious enumeration including by excluding at least one known legitimate enumeration request and generate a first security verdict indicative of a malicious process when the storage operation is indicative of a malicious enumeration; and
However, Aharoni teaches a security agent operably coupled to the security sensor, including a prediction unit comprising instructions stored in the memory that, when executed by the at least one processor, (¶0002: Figure 1 is a process in which file open event is monitored for triggering a processing for preventing ransomware encrypting files on a target machine that is trigged based on a target machine that is triggered based on a file open event monitored using endpoint agent. ) cause the at least one processor to analyze the tracked storage operations (¶0055-0056: In an example implementation, upon an open request to a protected directory, the endpoint agent performs a stack walk on the user mode part of the request and searches for return address in the stack. Referring to Figure 1, at 12, a file open event x is detected on a target system. For example, the file system event associated with x (e.g., x can be a directory or a file) can be detected using the mini filter driver. ) of the process to determine whether the storage operation is indicative of a malicious enumeration including by excluding at least one known legitimate enumeration request (¶0057-0058: At 104, whether x is on a protected volume (e.g., the configuration can be based on the volume’s drive letter and/or other criteria/attributes) is determined. At 106, whether x is protected directory is determined. For example, the endpoint agent can be configured with set of protected directories on the target system as described above. If x is a protected directory (known legitimate enumeration request) for further operations on the object as shown at 108.) and generate a first security verdict indicative of a malicious process when the storage operation is indicative of a malicious enumeration; and (¶0059: Otherwise (i.e., x is not a protected directory), processing continues at 110, and whether x is under a protected directory is determined. At 114, whether x is a target file (e.g., forged honeypot file) is determined. If x is a target file, then the endpoint agent determines whether file open of the file x is dangerous as shown at 118 (generating a first indicative of a suspicious process).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Aharoni with regards to the prediction unit to the method of Zhu in order to prevent ransomware and security risks (Aharoni ¶0001-0002).
Zhu in view of Aharoni does not disclose:
an analysis module comprising instructions stored in the memory that, when executed by the at least one processor, cause the at least one processor to: when the first verdict is indicative of a suspicious process: receive a full stack trace from the security sensor, perform an advanced analysis of the process, wherein the advanced analysis includes an analysis of the full stack trace including by comparison of the full stack trace to at least one known preset pattern that corresponds to a known malicious process , to generate a second verdict, and characterize the process as a malicious process , when the advanced analysis determines that the process is a malicious process.
However, Eshkenazi teaches an analysis module comprising instructions stored in the memory that, when executed by the at least one processor, cause the at least one processor to: when the first verdict is indicative of a suspicious process: receive a full stack trace from the security sensor, perform an advanced analysis of the process, (¶0097-0100: As seen in Figure 1, when an output is found to match a cached input, processor 40 checks whether the target of the output is potentially vulnerable to attack by the cached input, at a vulnerability checking step 66. If so, processor 40 invokes protective action, at a protection step 68, which is described in greater detail hereinbelow. Upon finding a match, detectors that have been instrumented into the application may apply various tests to the output in order to identify attacks at step 66. Tests used at step 66 to detect file-path manipulation vulnerabilities. The detector associated with such a method checks the corresponding file-path parameter against the cached inputs. If the target contains a cached input, the detector trims the input out of the target in order to get the path prefix (if it exists in the target). The detector may then convert the path to a canonical form in order to get the full, unique, absolute path. This conversion can be performed using methods that are known in the art, as provided, for example, by the C# methods known as Path.GetFullPath and HttpServerUtility.MapPath that are available as part of the Microsoft .NET framework and are described on the msdn Web site. Further ¶0114 shows in step 6 wherein RASP logic is utilized );
wherein the advanced analysis includes an analysis of the full stack trace including by comparison of the full stack trace to at least one known preset pattern that corresponds to a known malicious process , (¶0007: In the disclosed embodiments, instrumenting the input points includes adding a sensor routine to each identified input point, wherein the sensor routine examines the input for syntax that is characteristic of an attack pattern. In one embodiment, the attack pattern is selected from a set of attack patterns consisting of SQL injection, cross-site scripting (XSS), file path manipulation, and JavaScript Object Notation (JSON) injection. Further in ¶0104: Figure 3, shows details on input/output identification step 50, in accordance with an embodiment in which static analysis used to enhance RASP instrumentation. The RASP patcher running on processor 26 uses the attack vectors provided by the SAST tool at step 72 in identifying instrumentation points to add to the corresponding assembly code. Specifically, the list of vector attack sources provided by the SAST tool includes, like the query results described above, corresponding method names and code context. The RASP patcher uses this information in converting the list of attack source locations in the source code to a list of RASP instrumentation points, and associates RASP sensor logic with these points at step 76);
to generate a second verdict, and characterize the process as a malicious process , when the advanced analysis determines that the process is a malicious process. (¶0101: If the canonical path does not contain the path prefix that was included in the target, the detector will recognize a possible attack at step 66, since the user input has apparently overridden the existing path prefix that was included in the target code and may thus gain access to a path that was not intended to be accessed by this output. In this case, the detector will typically raise an alert at step 68 regarding file-path manipulation and/or will take other preventive action. )
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Eshkenazi regards to the advanced analysis to the method of Zhu in view of Aharoni in order to protect the system again security vulnerability (Eshkenazi ¶0002).
With respect to claim 12, the combination of Zhu in view of Aharoni and Eshkenazi teaches the system of claim 9 (see rejection of claim 9 above) wherein the advanced analysis is at least one of static analysis or dynamic analysis. (Eshkenazi ¶0104: Figure 3, shows details on input/output identification step 50, in accordance with an embodiment in which static analysis used to enhance RASP instrumentation.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Eshkenazi regards to the advanced analysis to the method of Zhu in view of Aharoni in order to protect the system again security vulnerability (Eshkenazi ¶0002).
With respect to claim 16, the combination of Zhu in view of Aharoni and Eshkenazi teaches the system of claim 9 (see rejection of claim 9 above) wherein the security agent is further configured to analyze storage operation parameters consisting of at least one of a file type, a volume, a file name or a file mask encoded into the storage operation. (Aharoni ¶0056-0057: Referring to Figure 1, at 102, a file open event x is detected on a target system. For example, the file system event associated with x (e.g., x can be a directory or a file) can be detected using the mini filter driver as described above. At 104, whether x is on a protected volume (e.g., the configuration can be based on the volume's drive letter and/or other criteria/attributes) is determined. For example, the endpoint agent can be configured with a set of protected volumes on the target system as similarly described above. If x is not a protected volume, then processing proceeds to 124.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Aharoni with regards to analyzing storage operation parameters to the method of Zhu in view of Eshkenazi in order to prevent ransomware and security risks (Aharoni ¶0001-0002).
Claims 3 and 11 are rejected under 35 U.S.C. 103 as being unpatentable over Zhu et al. (US-20210182387-A1) in view of Aharoni et al. (US Pat No. 11010469-B2), Eshkenazi et al. (US PGPub No. 20180107821-A1), and Chiu et al. (US PGPub No. 20200067971-A1) .
With respect to claim 3, the combination of Zhu in view of Aharoni and Eshkenazi teaches the method of claim 1 (see rejection of claim 1 above) does not disclose further comprising: determining, by a cross-process correlator, correlation between the malicious process and a plurality of processes, wherein the plurality of processes is associated with the malicious process and correspond to the one or more system events associated with the malicious process; and characterizing one or more processes amongst the associated processes as malicious.
However, Chiu teaches further comprising: determining, by a cross-process correlator, correlation between the malicious process and a plurality of processes, (¶0074: As seen in a combination of Figure 1 and Figure 3, for event analysis 310, the aforementioned multiple suspicious activities records, the corresponding time stamps, and the multiple attribute tags are digital evidence that can be utilized for analyzing whether specific events took places in the target network system 102)
wherein the plurality of processes is associated with the malicious process and correspond to the one or more system events associated with the malicious process; and characterizing one or more processes amongst the associated processes as malicious. ( ¶0075: For example, the event analysis module 310 may conduct various cross-comparisons and event correlation analyses based on multiple suspicious activities records related to a specific computing device, so as to find out one or more suspicious events having sufficiently affirmative digital evidences capable of proving that the one or more suspicious events took place in the specific computing device. ¶0078: The types and quantity of the device internal events identified by the event analysis module 310 based on the aforementioned digital evidences (i.e., the suspicious activities records, the time stamps, and the attribute tags) are determined by the actual situation of the target network system 102);
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Chiu with regards to the a cross-process to the method of Zhu in view of Aharoni and Eshkenazi in order to identify multiple suspicious events that are possibly associated with cyber breach activities in the targe network system and to identify multiple time records respectively corresponding to the aforementioned multiple suspicious events (Chiu ¶0074).
With respect to claim 11, the combination of Zhu in view of Aharoni and Eshkenazi teaches the system of claim 9 (see rejection of claim 9 above) does not disclose further comprising: a cross-process correlator configured to determine a correlation between the malicious process and a plurality of processes, wherein the plurality of processes is associated with the malicious process and corresponds to the system event containing the malicious process.
However, Chiu teaches further comprising: a cross-process correlator configured to determine a correlation between the malicious process and a plurality of processes, (¶0074: As seen in a combination of Figure 1 and Figure 3, for event analysis 310, the aforementioned multiple suspicious activities records, the corresponding time stamps, and the multiple attribute tags are digital evidence that can be utilized for analyzing whether specific events took places in the target network system 102. ).
wherein the plurality of processes is associated with the malicious process and corresponds to the system event containing the malicious process. ( ¶0075: For example, the event analysis module 310 may conduct various cross-comparisons and event correlation analyses based on multiple suspicious activities records related to a specific computing device, so as to find out one or more suspicious events having sufficiently affirmative digital evidences capable of proving that the one or more suspicious events took place in the specific computing device. ¶0078: The types and quantity of the device internal events identified by the event analysis module 310 based on the aforementioned digital evidences (i.e., the suspicious activities records, the time stamps, and the attribute tags) are determined by the actual situation of the target network system 102. ).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Chiu with regards to a process to the method of Zhu in view of Aharoni and Eshkenazi in order to identify multiple suspicious events that are possibly associated with cyber breach activities in the targe network system and to identify multiple time records respectively corresponding to the aforementioned multiple suspicious events (Chiu ¶0074).
Claims 5, 13, 14 are rejected under 35 U.S.C. 103 as being unpatentable over Zhu et al. (US-20210182387-A1) in view of Aharoni et al. (US Pat No. 11010469-B2), Eshkenazi et al. (US PGPub No. 20180107821-A1), and Gupta et al. (US PGPub No. 20200372129-A1) .
With respect to claim 5, the combination of Zhu in view of Aharoni and Eshkenazi teaches the method of claim 1 (see rejection of claim 1 above), but does not disclose further comprising: upon characterizing at least one process as malicious, rectifying the malicious process with the security sensor, wherein the rectification comprises at least one of deletion, quarantining, terminating, and restoring the system from a system backup.
However, Gupta teaches further comprising: upon characterizing at least one process as malicious, rectifying the malicious process with the security sensor, wherein the rectification comprises at least one of deletion, quarantining, terminating, and restoring the system from a system backup. (¶0014: The systems, methods, and program products take a protective action on the process if the execution meets the defined pattern. The protective action may include any of terminate the thread, terminate the process, move the process to a quarantine area, load one or more patches to remedy the process file, and report the process as malicious to the user.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Gupta with regards to the security sensor to the method of Zhu in view of Aharoni and Eshkenazi in order to further protect the system from being exploited (Gupta ¶0007).
With respect to claim 13, the combination of Zhu in view of Aharoni and Eshkenazi teaches the system of claim 12 (see rejection of claim 12 above) but does not disclose further comprising: an event processing automation unit configured to: process the event containing the particular process based on configured rules; and send a command for the advanced analysis of the process to identify the malicious thread, wherein the command is sent to the security sensor, which collects additional data including a collection of the call stack.
However, Gupta teaches further comprising: an event processing automation unit configured to: process the event containing the particular process based on configured rules; and (¶0033: The framework instruments the particular instructions based on the specified type of construct identified by the framework (e.g., an if-then statement or an indirect branch instruction). The framework may apply rule-based policies based on security technical implementation guides (STIGS) or user configuration to monitor the application and patch the vulnerability with particular instructions.);
send a command for the advanced analysis of the process to identify the malicious thread, ( ¶0036: If the process is identified to include such a signature, as the process executes, the framework monitors the process in real-time (e.g., using mechanisms such as dynamic binary instrumentation or function hooking technology) to detect if the process executes the signature in accordance with a defined pattern (e.g., flushing at a certain frequency or speed, or reading a cache line for a particular variable faster than other cache lines or flushing instruction within a TSX bookend) characteristic of exploiting such vulnerabilities. ¶0050-0051: Figure 1A illustrates an example speculative execution engine 100 in some embodiments of the present disclosure. Speculative execution introduces concepts, like out-of-order execution and branch prediction, which are not normal paradigms in software design. Such speculative execution causes vulnerabilities (e.g., Spectre, Meltdown, Foreshadow, etc.) while executing an application. ).
wherein the command is sent to the security sensor, which collects additional data including a collection of the call stack. ( ¶0060-0062: When the RSB “stack is empty on these speculative execution processor, a RET instruction may speculate based on the contents of the indirect predictor, the structure that retpoline is designed to avoid. This means that defenses around “retpoline” becomes useless. The RSB may become empty under the following conditions. One conditions is Call stacks deeper than the minimum RSB depth (16) may empty the RSB when executing RET instructions. The depth of the call stack may depend on many factors that are not known until runtime which makes the call stack difficult to mitigate in software. However, exploiting a deep call stack is expected to require much more comprehensive control and prediction of the behavior of the CPU and program state than a traditional branch target injection (Spectre variant 2) attack.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Gupta with regards to advanced analysis to the method of Zhu in view of Aharoni and Eshkenazi in order to further protect the system from being exploited (Gupta ¶0007).
With respect to claim 14, the combination of Zhu in view of Aharoni and Eshkenazi teaches the system of claim 9 (see rejection of claim 9 above) but does not disclose wherein the security sensor, upon characterizing at least one process as malicious, is further configured to rectify the malicious process, wherein the rectification comprises at least one of deletion, quarantining, terminating, or a combination thereof, and restoration of the system from a system backup.
However, Gupta teaches wherein the security sensor, upon characterizing at least one process as malicious, is further configured to rectify the malicious process, wherein the rectification comprises at least one of deletion, quarantining, terminating, or a combination thereof, and restoration of the system from a system backup. (¶0014: The systems, methods, and program products take a protective action on the process if the execution meets the defined pattern. The protective action may include any of terminate the thread, terminate the process, move the process to a quarantine area, load one or more patches to remedy the process file, and report the process as malicious to the user.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Gupta with regards to the security sensor to the method of Zhu in view of Aharoni and Eshkenazi in order to further protect the system from being exploited (Gupta ¶0007).
Claims 6 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Zhu et al. (US-20210182387-A1) in view of Aharoni et al. (US Pat No. 11010469-B2), Eshkenazi et al. (US PGPub No. 20180107821-A1), and Beveridge et al. (US PGPub No. 20230412629-A1) .
With respect to claim 6, the combination of Zhu in view of Aharoni and Eshkenazi teaches the method of claim 1 (see rejection of claim 1 above), but does not disclose further comprising: prior to analyzing by the prediction unit, filtering the storage operations based on at least one of a type of operation, a type of call, or a list of trusted requests from known processes or services, wherein the filtering is performed by at least one of per-process, per-device, per-storage object, or per-call type criteria.
However, Beveridge teaches further comprising: prior to analyzing by the prediction unit, filtering the storage operations based on at least one of a type of operation, a type of call, or a list of trusted requests from known processes or services, (¶0043-0044: As seen in Figure 3, at step 304, collection agent 202 can filter and/or aggregate the API call traces received at step 302 based on various criteria. For example, the filtering can include identifying and dropping API call traces that are not deemed relevant for anomaly detection, such as traces pertaining to routine/health sent between routine liveness/health checks send between microservices.).
wherein the filtering is performed by at least one of per-process, per-device, per-storage object, or per-call type criteria. (¶0043-0044: The aggregating can include identifying multiple identical API call traces and combining those into a single aggregated trace, with an added count element indicating the number of API calls represented by that single aggregated trace.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Beveridge with regards to the security sensor to the method of Zhu in view of Aharoni and Eshkenazi in order to reduce the false positive rate of being detected by the system (Beveridge ¶0035).
With respect to claim 15, the combination of Zhu in view of Aharoni and Eshkenazi teaches the system of claim 9 (see rejection of claim 9 above) but does not disclose wherein the prediction unit is further configured to filter the storage operations, before initiating analysis, based on at least one of a type of operation, a type of call, or a list of trusted requests from known processes or services, wherein the filtration is performed by at least one of per-process, per-device, per-storage object, or per-call type criteria.
However, Beveridge teaches wherein the prediction unit is further configured to filter the storage operations, before initiating analysis, based on at least one of a type of operation, a type of call, or a list of trusted requests from known processes or services, (¶0043-0044: As seen in Figure 3, at step 304, collection agent 202 can filter and/or aggregate the API call traces received at step 302 based on various criteria. For example, the filtering can include identifying and dropping API call traces that are not deemed relevant for anomaly detection, such as traces pertaining to routine/health sent between routine liveness/health checks send between microservices.);
wherein the filtration is performed by at least one of per-process, per-device, per-storage object, or per-call type criteria. (¶0043-0044: The aggregating can include identifying multiple identical API call traces and combining those into a single aggregated trace, with an added count element indicating the number of API calls represented by that single aggregated trace.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Beveridge with regards to the security sensor to the method of Zhu in view of Aharoni and Eshkenazi in order to reduce the false positive rate of being detected by the system (Beveridge ¶0035).
Claims 8 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Zhu et al. (US-20210182387-A1) in view of Aharoni et al. (US Pat No. 11010469-B2), Eshkenazi et al. (US PGPub No. 20180107821-A1), and Kuperman et al. (US PGPub No. 20170244737-A1) .
With respect to claim 8, the combination of Zhu in view of Aharoni and Eshkenazi teaches the method of claim 1 (see rejection of claim 1 above), but does not disclose further comprising: performing analysis of storage operations in synchronous or asynchronous mode, with or without interrupting the execution of a process code.
However, Kuperman teaches further comprising: performing analysis of storage operations in synchronous or asynchronous mode, with or without interrupting the execution of a process code. (¶0091: Under the asynchronous blocking scheme illustrated by way of example in Figure 3, unknown request information is collected by proxy runtimes 305 and a prediction service 327 is queried for classification. In turn, the proxy runtimes 305 may asynchronously receive request classifications. For malicious request classifications, the proxy runtime 305 may update an active block list by identifying the offending source IP address of the client to the user agent database 325 as malicious.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Kuperman with regards to synchronous or asynchronous mode to the method of Zhu in view of Aharoni and Eshkenazi in order to avoid blockage of legitimate user traffic (Kuperman ¶0009).
With respect to claim 17, the combination of Zhu in view of Aharoni and Eshkenazi teaches the system of claim 9 (see rejection of claim 9 above) but does not disclose wherein analysis of storage operations is performed in synchronous or asynchronous mode, and with or without interrupting the execution of a process code, by the prediction unit.
However, Kuperman teaches wherein analysis of storage operations is performed in synchronous or asynchronous mode, and with or without interrupting the execution of a process code, by the prediction unit. (¶0091: Under the asynchronous blocking scheme illustrated by way of example in Figure 3, unknown request information is collected by proxy runtimes 305 and a prediction service 327 is queried for classification. In turn, the proxy runtimes 305 may asynchronously receive request classifications. For malicious request classifications, the proxy runtime 305 may update an active block list by identifying the offending source IP address of the client to the user agent database 325 as malicious.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Kuperman with regards to synchronous or asynchronous mode to the method of Zhu in view of Aharoni and Eshkenazi in order to avoid blockage of legitimate user traffic (Kuperman ¶0009).
Claim 18 is rejected under 35 U.S.C. 103 as being unpatentable over Zhu et al. (US-20210182387-A1) in view of Aharoni et al. (US Pat No. 11010469-B2), Eshkenazi et al. (US PGPub No. 20180107821-A1), and Chaudhari et al. (US PGPub No. 20230367877-A1) .
With respect to claim 18, the combination of Zhu in view of Aharoni and Eshkenazi teaches the system of claim 9 (see rejection of claim 9 above), but does not disclose wherein the first verdict is stored in an event store of the security agent.
However, Chaudhari teaches wherein the first verdict is stored in an event store of the security agent. (¶0030-0032: In some examples, such verdicts of sandboxing analysis are linked to identifiers of the script and/ or patterns of script data in the script, such that the verdicts can be stored in a map (e.g., script data identifies and/or patterns mapped to verdicts) in the cache of the AMS 114.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Chaudhari with regards to storing a verdict to the method of Zhu in view of Aharoni and Eshkenazi l in order to reduce malware footprint and to be use for future scanning (Chaudhari ¶0019).
Claim 19 is rejected under 35 U.S.C. 103 as being unpatentable over Zhu et al. (US-20210182387-A1) in view of Aharoni et al. (US Pat No. 11010469-B2), Eshkenazi et al. (US PGPub No. 20180107821-A1), and Hajimirsadeghi et al. (US PGPub No. 20200076841-A1) .
With respect to claim 19, the combination of Zhu in view of Aharoni and Eshkenazi teaches the system of claim 12 (see rejection of claim 12 above), but does not disclose wherein the full stack is built from a user mode or at the kernel level, based on the mode of operation of the security sensor.
However, Hajimirsadeghi teaches wherein the full stack is built from a user mode or at the kernel level, based on the mode of operation of the security sensor. (¶0128: For example, the autoencoder may be trained or retrained as a full stack of MLPs, then dissected into subset of layer to isolate the encoder MLP for production deployment encoder 390. ¶0136: As seen in Figure 5, full stack 505 consists essentially of transcoders 561-562 and RNN 570 in between them. Transcoders 561-562 function together in series as a codec to mediate between full stack 505 that internally uses dense encoding and the rest of computer 500 that provides and expects raw (i.e. sparse) encoding. ¶0358: As seen in Figure 25, Software system 2500 is provided for directing the operation of computing system 2400. Software system 2500, which may be stored in system memory (RAM) 2406 and on fixed storage (e.g., hard disk or flash memory) 246, includes a kernel or operating system (OS) 2510.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Hajimirsadeghi with regards to a full stack to the method of Zhu in view of Aharoni and Eshkenazi in order to handle traffic and analysis in a manageable way (Hajimirsadeghi ¶0009).
Claim 20 is rejected under 35 U.S.C. 103 as being unpatentable over Zhu et al. (US-20210182387-A1) in view of Aharoni et al. (US Pat No. 11010469-B2), Eshkenazi et al. (US PGPub No. 20180107821-A1), and Gupta et al. (US PGPub No. 20210029170-A1) .
With respect to claim 20, the combination of Zhu in view of Aharoni and Eshkenazi teaches the system of claim 9 (see rejection of claim 9 above), but does not disclose wherein the security sensor is operated in a least one of a user mode, a kernel mode, as a set of injections into controlled applications, or a combination of thereof.
However, Gupta ( US-20210029170-A1) teaches wherein the security sensor is operated in a least one of a user mode, a kernel mode, as a set of injections into controlled applications, or a combination of thereof. (¶0128:As seen in Figure 2, the detection engine 260 runs the target process scanner 208 to perform scanning on the memory of the customer endpoint 112 and detect currently executing processes and threads performing CRUD operations. In some embodiments, the target process scanner 208 detects the processes and threads performing CRUD operations by employing API hooking using DLL injection, system calls hooking, or a kernel driver (e.g., a ring 0 kernel driver).).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Gupta ( US-20210029170-A1) with regards to injections to the method of Zhu in view of Aharoni and Eshkenazi in order to detect malicious attacks in real-time on a computer network and prevent memory corruption attacks triggered remotely by malicious attacks. (Gupta ( US-20210029170-A1) ¶0002-0004).
Claim 21 and 22 rejected under 35 U.S.C. 103 as being unpatentable over Zhu et al. (US-20210182387-A1) in view of Aharoni et al. (US Pat No. 11010469-B2), Eshkenazi et al. (US PGPub No. 20180107821-A1), and Soryal et al. (US Pat No. 11741225-B2) .
With respect to claim 21, the combination of Zhu in view of Aharoni and Eshkenazi teaches the method of claim 1 (see rejection of claim 1 above),but does not disclose wherein the sequence of operations comprises a root operation and a plurality of subsequent operations, wherein the enumeration request is from one of the plurality of subsequent operations.
However, Soryal teaches wherein the sequence of operations comprises a root operation and a plurality of subsequent operations, wherein the enumeration request is from one of the plurality of subsequent operations. (¶0034: As seen in Figure 5A, the machine learning tree structure 500A shows a root transaction (“R”) that leads into four different paths towards an end/destination transaction (“X”). Paths represented with a solid line are viable/normal paths (i.e., R-1-X, R-2-X, and R-4-X). The path R-9-X with dotted line is suspicious (enumeration request is one of the plurality of subsequent operations) . Figure 5B further shows transaction correlation for the same destination transaction. That is, starting from the same root transaction, the number of transactions that were similar along respective paths can be determined. );
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Soryal with regards to sequence of operations to the method of Zhu in view of Aharoni and Eshkenazi in order to prevent zero data attack exploitation. (Soryal ¶0001).
With respect to claim 22, the combination of Zhu in view of Aharoni and Eshkenazi teaches the system of claim 9 (see rejection of claim 9 above), wherein the wherein the sequence of operations comprises a root operation and a plurality of subsequent operations, wherein the enumeration request is from one of the plurality of subsequent operations.
However, Soryal teaches wherein the sequence of operations comprises a root operation and a plurality of subsequent operations, wherein the enumeration request is from one of the plurality of subsequent operations. (¶0034: As seen in Figure 5A, the machine learning tree structure 500A shows a root transaction (“R”) that leads into four different paths towards an end/destination transaction (“X”). Paths represented with a solid line are viable/normal paths (i.e., R-1-X, R-2-X, and R-4-X). The path R-9-X with dotted line is suspicious (enumeration request is one of the plurality of subsequent operations) . Figure 5B further shows transaction correlation for the same destination transaction. That is, starting from the same root transaction, the number of transactions that were similar along respective paths can be determined. );
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention utilize the teachings of Soryal with regards to sequence of operations to the method of Zhu in view of Aharoni and Eshkenazi in order to prevent zero data attack exploitation. (Soryal ¶0001).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TAYLOR P VU whose telephone number is (703)756-1218. The examiner can normally be reached MON - FRI (7:30 - 5:00).
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, Alexander Lagor can be reached at (571) 270-5143. 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.
/T.P.V./Examiner, Art Unit 2437
/ALEXANDER LAGOR/Supervisory Patent Examiner, Art Unit 2437
Prosecution Insights