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
An Information Disclosure Statement (IDS) has not been submitted as of the mailing of the last Office Action dated 24 September 2025. Applicant is reminded of the continuing obligation under 37 CFR 1.56 to timely apprise the Office of any information which is material to patentability of the claims under consideration in this application.
Introductory Remarks
In response to communications filed on 23 December 2025, claims 1, 6, 12, 16, and 21 are amended per Applicant's request. Claims 3-4 and 14 are cancelled. No claims were withdrawn. No new claims were added. Therefore, claims 1-2, 5-13, and 15-23 are presently pending in the application, of which claims 1, 12, and 21 are presented in independent form.
The previously raised 112 rejection of the pending claims is withdrawn in view of the amendments to the claims. A new ground(s) of rejection has been issued.
The previously raised 103 rejection of the pending claims is withdrawn in view of the amendments to the claims. A new ground(s) of rejection has been issued.
Response to Arguments
Applicant’s arguments with respect to the priority of the application in the context of claim 3 (see Remarks, p. 9) has been fully considered and is persuasive, as Claim 3’s cancellation renders this issue moot.
Applicant’s arguments filed 23 December 2025 with respect to the non-statutory double patenting rejection of the pending claims (see Remarks, p. 9-10) have been fully considered but are not persuasive. The claims are still subject to a non-statutory double patenting (see the Double Patenting Rejection below for further details), and Applicant has not filed a Terminal Disclaimer. Therefore, the non-statutory double patenting rejection has been maintained.
Applicant’s arguments filed 23 December 2025 with respect to the rejection of the claims under 35 U.S.C. 112 (see Remarks, p. 10) have been fully considered but are not persuasive. Applicant solely argues that the amendments overcome the 112 rejections. However, Applicant’s amendments raise new issues; see the 112 rejections below for further details.
Applicant’s arguments filed 23 December 2025 with respect to the rejection of the claims under 35 U.S.C. 103 (see Remarks, p. 10-12) have been fully considered but are moot because the arguments do not apply to the new reference (and thus new combination of references) being used in the current rejection.
Double Patenting
Claims 1-2, 5-13, and 15-23 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-5, 8, 10, 12-16, and 18-19 of U.S. Patent No. 11,500,847 B2. Although the claims at issue are not identical, they are not patentably distinct from each other (see the table below for comparison of the two claims, where italicized and bolded text refers to matching claim language).
Claims 1-2, 5-13, and 15-23 of the present application (17/971,378)
Claims 1-5, 8, 10, 12-16, and 18-19 of U.S. Patent No. 11,500,847 B2
1. A computer program product comprising a non-transitory computer-readable medium storing a set of computer-readable instructions, the set of computer-readable instructions executable to:
register with an operating system of a target computer to receive file change notifications for files in a specified directory in a file system of the target computer;
receive a file change event for a file in the specified directory via a monitoring hook into a notification interface of the operating system of the target computer;
determine, by a forensic artifact filter configured as a kernel-mode filter driver, that the file change event represents a forensic artifact change according to a forensic artifact definition, the kernel-ode filter driver comprising a registered callback routine;
based on a determination that the file change event represents the forensic artifact change:
pass, by the registered callback routine, event information for the file change event to an out-of-band forensic interpreter, wherein passing the event information by the registered callback routine is performed as the file change event from proceeding through a driver stack of the operating system;
load the file into volatile memory of the target computer for analysis by the target computer;
determine a forensic artifact type of the file;
map, by the out-of-band forensic interpreter, the file to a first code library from a set of code libraries stored on the target computer, each code library in the set of code libraries corresponding to a different type of forensic artifact, wherein each code library is configured to identify a specific activity different from activities being identified by the other code libraries, wherein the mapping of the file comprises selecting the first code library from the set of code libraries based on the forensic artifact type determined,1 and wherein each of the set of code libraries includes a template activity description into which forensic analysis results are inserted to generate an activity description of a user activity on the target computer;
responsive to mapping the file, pass the file to the first code library;
apply, by the first code library, a forensic analysis to the file according to the forensic artifact type to determine an activity on the target computer;
collect forensic metadata associated with the file, the forensic metadata comprising a user identifier of a user correlated to the activity on the target computer;
generate, by the first code library, a first forensically interpreted, human-understandable, textual activity for the file change event using a first template activity description of the plurality of stored template activity descriptions; and
store, by the first code library, the forensically interpreted activity in a digital forensics store for the target computer.
1. A computer program product comprising a non-transitory computer-readable medium storing a set of computer-readable instructions, the set of computer-readable instructions comprising instructions executable on a computer that has an operating system with a notification interface to:
use a monitoring hook into the notification interface of the operating system to receive an event;
provide a forensic artifact filter coupled to the monitoring hook, the forensic artifact filter comprising code executable to:
for the event received using the monitoring hook, evaluate the event according to a forensic artifact definition to determine if the event represents a change to a forensic artifact, wherein evaluating the event according to the forensic artifact definition to determine if the event represents the change to the forensic artifact comprises determining that a registry path included in the event corresponds to a ShellBag artifact; and
based on a determination that the event represents the change to the forensic artifact, output a forensic artifact filter output that includes event information for the event, the event information including an indication of the forensic artifact;
based on the forensic artifact filter output, collect, at the computer, forensic metadata associated with the forensic artifact but not included in the forensic artifact filter output and apply a forensic analysis to the forensic artifact to generate a result that indicates a first activity with respect to the forensic artifact, the forensic metadata including a user identifier for a user of the operating system who carried out the first activity, wherein applying the forensic analysis to the forensic artifact comprises parsing the ShellBag artifact to determine a folder browsed and reconstructing a folder path for the folder browsed;
generate in real-time, at the computer, a forensically interpreted activity for the event, the forensically interpreted activity comprising a human-understandable description of the folder path for the folder browsed, the first activity and the user who carried out the first activity with respect to the forensic artifact; and
store the forensically interpreted activity in a digital forensics store for the computer.
2. The computer program product of claim 1, wherein the set of computer-readable instructions are executable to implement a filter driver to receive the file change event and determine that the file change event represents the forensic artifact change.
2. The computer program product of claim 1, wherein the set of computer-readable instructions comprises instructions executable to implement a filter driver, the filter driver comprising the forensic artifact filter.
5. The computer program product of claim 1, wherein the set of computer-readable instructions comprises code executable to register a callback with the notification interface of the operating system.
4. The computer program product of claim 1, wherein the set of computer-readable instructions comprises code executable to register a callback with the notification interface of the operating system.
6. The computer program product of claim 5, wherein the set of computer-readable instructions comprises a callback routine for the callback, the callback routine executable to perform the said determining that the file change event represents the forensic artifact change.
5. The computer program product of claim 4, wherein the set of computer-readable instructions comprises a callback routine for the callback, the callback routine comprising the forensic artifact filter.2
10. The computer program product of claim 1, wherein the set of computer-readable instructions comprises a template activity description and said generating the forensically interpreted activity for the file change event comprises inserting the forensic metadata into the template activity description.
8. The computer program product of claim 1, wherein the set of computer-readable instructions comprises a template activity description and wherein said generating the forensically interpreted activity for the event comprises inserting the forensic metadata and the result into the template activity description.
11. The computer program product of claim 1, wherein the forensic artifact change comprises at least one of a creation of the file, an update to the file or a deletion of the file.
10. The computer program product of claim 1, wherein the change to the forensic artifact comprises at least one of a creation of the forensic artifact, an update to the forensic artifact or a deletion of the forensic artifact.
12. See claim 1 above
12. See claim 1 above.
13. See claim 2 above.
13. See claim 2 above.
15. See claim 5 above.
15. See claim 4 above.
16. See claim 6 above.
16. See claim 5 above.
20. See claim 11 above.
18. See claim 10 above.
21. See claim 1 above.
19. See claim 1 above.
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 §§ 706.02(I)(1) – 706.02(I)(3) 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 USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The filing date of the application will determine what form 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/process/file/efs/guidance/eTD-info-I.jsp.
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-2, 5-13, and 15-23 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.
Independent Claims 1, 12, and 21 recite “a forensic artifact filter configured as a kernel-mode filter driver”. However, Specification, [0027] states that “a forensic artifact filter 114 is implemented as a filter driver (e.g., a kernel-mode driver)”. The claims’ use of the language “configured as” is therefore not supported, as “implemented” is not equivalent to “configured”. “Configured”, for example, means to set up; in other words, the claimed “configure” means, for example, an object (forensic artifact filter) may be set up in a particular way with respect to various limited objects. However, the Specification states “implemented” as, which means that the forensic artifact filter is a kernel-mode filter driver. Therefore, there is a lack of support that the forensic artifact filter is “configured as” a kernel-mode filter driver; rather, the forensic artifact filter is a kernel-mode filter driver.
The independent claims further recite “the kernel-mode filter driver comprising a registered callback routine”. Specification, [0027], states that “forensic artifact filters 114”—i.e., the kernel-mode filter driver being claimed—"are implemented as callback routines that are called when an event is received using the respective monitoring hook 112”. In other words, the filter is implemented using callback routines that are called when an event is received via the respective monitoring hook. Thus, the filter (i.e., kernel-mode filter driver) does not “comprise” a callback routine; instead, the filter is invoked upon a callback routine being called when an event is received.
See also, e.g., Specification, [0038], where “The driver is executable to register a pre-operation callback routine, a post-operation callback routine or both, where the callback routine(s) implement one or more forensic artifact filters 114”. Thus as seen, the callback routine explains how the deployment of the filter occurs, not that the filter “comprises” the callback routine.
The independent claims further recite “pass, by the registered callback routine, event information for the file change event to an out-of-band forensic interpreter, wherein passing the event information by the registered callback routine is performed as the file change event proceeds through a driver stack of the operating system”.
A registered callback routine are functions/executables for executing/implementing a forensic artifact filter 114 on the operation. However, the forensic artifact filter 114 is not a registered callback routine. Therefore, these claim limitations which appear to substitute the language of “forensic artifact filter” with “registered callback routine”, is not proper within the context of the claimed invention. See, e.g., Specification, [0036], where the forensic artifact filter 114 is what passes the event information to the forensic interpreter. However, note that the forensic artifact filter 114 is invoked, i.e., implemented, via the registered callback routine, not that the forensic artifact filter 114 is the registered callback routine.
The independent claims further recite “load…the file into volatile memory buffer of the target computer for analysis by the target computer”. There is no mention of a buffer or equivalent buffer-type memory that supports such a limitation. The closest paragraph may possibly be Specification, [0033]; however, this indicates that the forensically interpreted activity 124 is stored locally to a cache before it is sent to a server. However, this is the step at the end, i.e., after the file had been loaded into memory and analyzed, not before, i.e., prior to analysis.
The independent claims further recite “generate, by executing the first code library on a processor of a target computer, a forensically interpreted activity description…; store, by the first code library, the forensically interpreted activity description in a digital forensics store for the target computer”. Specification, [0010], states that the processor generates a forensically interpreted activity for the event, i.e., performing the steps of the claimed “forensic interpreter”. From the Specification, it appears that the forensically interpreted activity description, which is outputted by the forensic interpreter (or processor), is stored using a processor of (a/the) target computer (see, e.g., Specification, [FIG. 1]). It appears then, that the forensic interpreter / processor (which comprises the code libraries) may be performing the storing; see also, e.g., Specification, [0052].
The dependent claims are rejected for at least by virtue of their dependency on their respective independent claims.
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-2, 5-13, and 15-23 are 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.
Independent Claims 1, 12, and 21 recite “a forensic artifact filter configured as a kernel-mode filter driver”. However, Specification, [0027] states that “a forensic artifact filter 114 is implemented as a filter driver (e.g., a kernel-mode driver)”. The claims’ use of the language “configured as” is therefore not supported, as “implemented” is not equivalent to “configured”. “Configured”, for example, means to set up; in other words, the claimed “configure” means, for example, an object (forensic artifact filter) may be set up in a particular way with respect to various limited objects. However, the Specification states “implemented” as, which means that the forensic artifact filter is a kernel-mode filter driver. Therefore, the metes and bounds of “configured” cannot be ascertained within the context of the claimed invention. For purposes of examination, the interpretation that “configured as” to mean “implemented as” has been taken. Applicant is recommended to incorporate elements of claims 2, 13, and 22 into their respective independent claims (which utilizes the language “implement a filter driver”) as a result.
The independent claims further recite “the kernel-mode filter driver comprising a registered callback routine”. Specification, [0027], states that “forensic artifact filters 114”—i.e., the kernel-mode filter driver being claimed—"are implemented as callback routines that are called when an event is received using the respective monitoring hook 112”. In other words, the filter is implemented using callback routines that are called when an event is received via the respective monitoring hook. Thus, the filter (i.e., kernel-mode filter driver) does not “comprise” a callback routine; instead, the filter is invoked upon a callback routine being called when an event is received.
See also, e.g., Specification, [0038], where “The driver is executable to register a pre-operation callback routine, a post-operation callback routine or both, where the callback routine(s) implement one or more forensic artifact filters 114”. Thus as seen, the callback routine explains how the deployment of the filter occurs, not that the filter “comprises” the callback routine.
Therefore, because the claims contradict the Specification (the claims indicating that the callback routine is a part of the filter driver, whereas the Specification treats the callback routine as something that appears to be external to the filter driver), therefore, the metes and bounds of the limitation that the filter driver “comprises” the callback routine, cannot be ascertained. For purposes of examination, the interpretation of the Specification has been taken (i.e., that the callback routine implements the filter driver, e.g., by calling on the filter driver).
The independent claims further recite “pass, by the registered callback routine, event information for the file change event to an out-of-band forensic interpreter, wherein passing the event information by the registered callback routine is performed as the file change event proceeds through a driver stack of the operating system”.
Because “registered callback routine” is not interchangeable with “forensic artifact filter” (which is what is performing this claimed step; see, e.g., Specification, [0036]), therefore the metes and bounds of such a limitation cannot be established, as the role of the registered callback routine is simply to invoke the filter, not to perform the steps of the filter.
Given that the forensic artifact filter and the callback routine appear to be two distinct components/elements of the claimed invention, yet are used interchangeably throughout the claims, the metes and bounds of “forensic artifact filter” and “callback routine” cannot be established. For purposes of examination, a callback routine and filter have been treated as separate components, as disclosed in the Specification.
This also has resulted in issues with dependent claims 6 and 16; see below for further detail.
The independent claims further recite “generate, by executing the first code library on a processor of a target computer…”. There is a lack of antecedent basis issue for such a limitation, as the phrase “target computer” had already been used. For purposes of examination “the” (same) target computer has been taken.
Dependent Claim 6 recites “comprises callback routine for the callback”. There is a lack of antecedent basis issue with this limitation.
Dependent Claims 6 and 16 recite that the callback routine is responsible for determining that the file change event represents the forensic artifact change. However, in the independent claims, the forensic artifact filter is responsible for performing this step. Given that the forensic artifact filter and the callback routine appear to be two distinct components/elements of the claimed invention, yet are used interchangeably throughout the claims, the metes and bounds of “forensic artifact filter” and “callback routine” cannot be established.
The rest of the dependent claims are rejected for at least by virtue of their dependency on their respective independent claims, and for failing to cure the deficiencies of their respective independent claims.
The following is a quotation of 35 U.S.C. 112(d):
(d) REFERENCE IN DEPENDENT FORMS.—Subject to subsection (e), a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
The following is a quotation of pre-AIA 35 U.S.C. 112, fourth paragraph:
Subject to the following paragraph [i.e., the fifth paragraph of pre-AIA 35 U.S.C. 112], a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
Claims 2, 13, and 22 are rejected under 35 U.S.C. 112(d) or pre-AIA 35 U.S.C. 112, 4th paragraph, as being of improper dependent form for failing to further limit the subject matter of the claim upon which it depends, or for failing to include all the limitations of the claim upon which it depends. The claims recite “implementing a filter driver to receive the file change event and determine that the file change event represents the forensic artifact change”. However, their respective independent claims already recite “determining, by a forensic artifact filter configured as a kernel-mode filter driver, that the file change event represents a forensic artifact change…”. Thus, dependent claims 2, 13, and 22 do not further limit the subject matter of their respective independent claims they depend upon.
Applicant may cancel the claim(s), amend the claim(s) to place the claim(s) in proper dependent form, rewrite the claim(s) in independent form, or present a sufficient showing that the dependent claim(s) complies with the statutory requirements.
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.
Claims 1-2, 5-13, and 15-23 are rejected under 35 U.S.C. 103 as being unpatentable over Hoog (“Hoog”) (US 2012/0191660 A1), in view of Mu (“Mu”) (US 7,908,656 B1), in further view of Halcrow et al. (“Halcrow”) (US 2021/0012000 A1).
Regarding claim 1: Hoog teaches A computer program product comprising a non-transitory computer-readable medium storing a set of computer-readable instructions, the set of computer-readable instructions executable to (Hoog, [0034-0036], where the disclosed system may be implemented as a computer program product comprising a non-transitory computer-readable medium storing computer-readable program instructions executable by a processor embodied in one or more computing devices):
receive a file change event for a file …; determine … that the file change event represents a forensic artifact change … (Hoog, [0051-0101], where the extracted forensic data, e.g., forensic artifacts (i.e., “forensic artifact filter output”), may include any number of forensic data types and may vary depending on the type of system and/or applications implemented on the monitored apparatus. The extracted forensic data may include a large variety of information (i.e., “event information for the event”) such as user profile info, deleted data, user activity data, and so forth (i.e., “the event information including an indication of the forensic artifact”). See also Hoog, [0114-0126], where the system may detect users being created/deleted (i.e., “change to the forensic artifact”)); and
based on a determination that the file change event represents the forensic artifact change: … load, by the … forensic interpreter, the file into volatile memory buffer of the target computer for analysis by the target computer (Hoog, [0042], where the memory 312 may store (i.e., “load”) information in the form of static and/or dynamic information (i.e., “volatile memory”), where this stored information may be used by the analysis module 318 during the course of performing its functionalities. See also, e.g., Hoog, [0036], where memory 212 is configured to buffer input data for processing by the processor 320 (i.e., “volatile memory buffer…for analysis by the target computer”). See Hoog, [0105] below where the analysis module receives and processes forensic data, which may include files and/or portions of file data (Hoog, [0048]). See Hoog, [0034], where the monitored apparatus may include various means for performing the various functions described herein, including one or more of a processor and memory, and the means may be embodied as, e.g., a computer program product comprising a computer-readable medium (memory) storing computer-readable program instructions.
Although Hoog does not appear to explicitly state that the analysis module resides on the monitored apparatus (i.e., such that the steps are performed on “the target computer” as claimed and that the analysis module, or “forensic interpreter” performs the loading of the file into memory), because both the monitored apparatus and the forensic analysis apparatus contain the same hardware components for carrying out the claimed steps, one of ordinary skill in the art would have found it obvious to modify Hoog such that the monitored apparatus contains Hoog’s disclosed analysis module such that the file is loaded into volatile memory “of the target computer for analysis by the target computer” as claimed with the motivation of having faster mitigation processes (e.g., instead of sending information to the security center and waiting for results to return before taking any mitigating actions, the local monitored apparatus can detect this and automatically respond as appropriately) in addition to saving bandwidth (e.g., avoiding having to send information over the network));
determine, by the … forensic interpreter, a forensic artifact type of the file (Hoog, [0105], where the analysis module receives and processes forensic data, where the analysis module may be configured to process received forensic data based at least in part on the type of forensic data received (implying that the forensic data type was previously determined));
… [wherein the product includes] a first code library from a set of code libraries stored on the target computer, each code library in the set of code libraries corresponding to a different type of forensic artifact (Hoog, [0105], where the processing procedure (i.e., “code library”) performed by the analysis module may be specific to each of a plurality of forensic data types (i.e., “corresponding to a different type of forensic artifact”). See Hoog above with regards to having the claimed steps being performed at “the target computer”) …;
apply, by the first code library, a forensic analysis to the file according to the forensic artifact type to determine an activity on the target computer (Hoog, [0105], where the analysis module receives and processes forensic data, where the analysis module may be configured to process received forensic data based at least in part on the type of forensic data received (implying that the forensic data type was previously determined). In this regard, the analysis module 318 may be configured to perform a processing procedure specific to each of a plurality of forensic data types in processing forensic data. See Hoog, [0048], where the forensic data may consist of files, portions of files, and/or the like, which contain evidence of activity on the monitored apparatus 102. See Hoog, [0114-0126], where the analysis module 318 may generate one or more reports including file system activity timeline, web browsing activity, user login activity, etc. (i.e., “determine an activity on the target computer”));
collect forensic metadata associated with the file, the forensic metadata comprising a user identifier of a user correlated to the activity on the target computer (Hoog, [0033], where a forensic analysis apparatus may comprise any computing device or plurality of computing devices configured to receive forensic data from a monitored apparatus (i.e., “collect, at the computer, forensic metadata”). See Hoog, [0051-0101], where extracted forensic data (i.e., “forensic artifact filter output”) includes user activity data, such as user profile information (i.e., “user identifier for a user of the operating system”). See also Hoog, [0129], where an aggregate report may provide forensic data for a given user (e.g., user activity data) (i.e., “generate a result that indicates a first activity with respect to the forensic artifact”) over a period of time (indicating that data may be aggregated on a user-by-user basis, implying some sort of user identification or identifier for distinguishing between users));
generate, by executing the first code library on a processor of a target computer, a forensically interpreted activity description for the file change event using the template activity description (Hoog, [0105-0109], where the analysis module may process received forensic data based at least in part on the type of forensic data received, i.e., performing a processing procedure (i.e., “code library”) specific to each of a plurality of forensic data types, where the analysis module may perform at least a high level preliminary analysis of the processed forensic data, and may calculate or otherwise generate key risk indicator (KRI) values (e.g., PASS/WARN/FAIL, a numeric score value, and/or the like) from processed forensic data. For example, if no new user accounts are supposed to be created on a monitored system, then any new user account is a significant risk. During processing of received forensic data, if the forensic data contains an indication of a creation of a new user account where the analysis module may set a KRI value for “New User Creation” to “FAIL” (i.e., “generate…a forensically interpreted activity description for the file change event”), where the analysis module may further flag data representing evidence of the created user account. See Hoog, [0127], where a report may be generated, including the output of the analysis; see Hoog, [0131-0132] and [FIG. 4], where the report may include a main dashboard that includes values for KRIs, aggregate measures, etc., which may be expressed as text (i.e., “activity description”). For example, the dashboard example shows a list of activity descriptions, e.g., “Failed Logins Count”, “New User(s) Created”, may be regarded as “using the template activity description”)); and
store, by the first code library, the forensically interpreted activity description in a digital forensics store for the target computer (Hoog, [0108], where a high level preliminary analysis of the processed forensic data may be performed, and values, data, and/or other information resulting from this analysis may be loaded into a forensic database (i.e., “forensics store”). Although Hoog does not appear to explicitly state that the reports (i.e., “activity description”) are stored, but rather generally states that analysis of the processed forensic data may be stored in the forensic database (i.e., “forensics store”), one of ordinary skill in the art would have found it obvious to have modified Hoog’s disclosure to also store the generated reports with the motivation of providing later retrieval in order to save processing time and resources from having to re-compute the analyses involved in the report generation).
Although the cited portions of Hoog pertain to user creation/deletion and other user-account related activities, Hoog discloses in [0051-0101] and [0114] that file system activities may be extracted from the forensic data and analyzed/recognized by the analysis module. One of ordinary skill in the art would have recognized that file system activities would include file creation, deletion, and update events.3,4 Therefore, it would have been obvious to one of ordinary skill in the art to have substituted the user-related activities with Hoog’s file system activities (e.g., such that it pertains to file events) with predictably equivalent operating characteristics—which is that certain forensic event information is received, analyzed, and used to generate a particular output. One of ordinary skill in the art would have found it obvious to do so with the motivation of tracking file system events for security purposes, since, e.g., malware, viruses, malicious bots, etc., tend to leave traces in file system events.
Furthermore, although Hoog does not appear to explicitly state that a “code library” is utilized, Hoog’s disclosed “processing procedure” are a series of computing instructions/steps/functions that are implemented in accordance with a particular event type (i.e., corresponding to analyzing that particular event type), and thus is equivalent to the claimed “code library”, which is also a series of computing instructions/steps/functions for analyzing certain event types.
Hoog does not appear to explicitly teach register with an operating system of a target computer to receive file change notifications for files in a specified directory in a file system of the target computer; [receive a file change event for a file] in the specified directory via a monitoring hook into a notification interface of the operating system of the target computer; [determine], by a forensic artifact filter configured as a kernel-mode filter driver, [that the file change event represents a forensic artifact change] according to a forensic artifact definition, the kernel-mode filter driver comprising a registered callback routine; and [based on a determination that the file change event represents the forensic artifact change:] pass, by the registered callback routine, event information for the file change event to an out-of-band forensic interpreter, wherein passing the event information by the registered callback routine is performed as the file change event proceeds through a driver stack of the operating system; map[ing], by the out-of-band forensic interpreter, the file to [a first code library from a set of code libraries, each code library in the set of code libraries corresponding to a different type of forensic artifact], wherein each code library is configured to identify a specific activity different from activities being identified by the other code libraries, wherein the mapping of the file comprises selecting the first code library from the set of code libraries based on the forensic artifact type determined, and wherein each of the set of code libraries includes a template activity description into which forensic analysis results are inserted to generate an activity description of a user activity on the target computer; [and] responsive to mapping the file, pass[ing] the file to the first code library.
Mu teaches register with an operating system of a target computer to receive file change notifications for files in a specified directory in a file system of the target computer (Mu, [26:40-60], where when security filter 94 registers with filter framework 92, a number of request types initiated by a client are selected for registration by the security filter, including file open, file create, file lookup, file read, get attributes, directory read, and directory write (i.e., “file change notifications for files in a specified directory in a file system”). See Mu, [15:36-49], where a filter framework or architecture is provided for filter operations related to data access requests and responses to and from a filer, e.g., file server, storage servers, storage appliances, etc. (Mu, [1:24-42]) (i.e., “target computer”). See Mu, [15:61-67]-[16:1-3], where the filter framework 42 is realized as part of storage OS 300 (implying that the filter, when registering with the filter framework, is thus registered with the “operating system of a target computer” as claimed));
[receive a file change event for a file] in the specified directory via a monitoring hook into a notification interface of the operating system of the target computer (Mu, [26:40-60], where upon receiving any of these types of requests (including, e.g., file create, file write, directory read, directory write, etc.), filter framework 92 invokes security filter 94 with the particular request appropriate to the call out for security filter 94, where the call may be a simple function call or passing of a message.
See Mu, [13:48-56], where the file system filter establishes software hooks in storage operating system (OS) 300 for connecting the file system filter to the filer. See, e.g., Mu, [5:41-67]-[6:1-3], where the locations for hooking the filter framework include points in a dataflow, e.g., a messaging interface for communicating with storage devices (i.e., “notification interface”), where filter controller is provided to capture request and responses for file system data and invoke applicable filters);
[determine], by a forensic artifact filter configured as a kernel-mode filter driver, [that the file change event represents a forensic artifact change] according to a forensic artifact definition, the kernel-mode filter driver comprising a registered callback routine (Mu, [6:50-67]-[7:1-10], where the security filter is a kernel mode filter. See Mu, [32:9-15] and [34:1-18], where security filter 94 implements callbacks for, e.g., file open, file read, file lookup, file write, get attribute and directory read. See Mu, [32:6-8], where filter 94 includes a number of definitions of security events, indicated as definitions 102. Security events have attributes that contribute to produce security event definitions, e.g., the security event definitions include attributes of certain types of I/O combinations (such as, e.g., the claimed “forensic artifact change”; recall from, e.g., Mu, [26:40-60], where the I/O requests include file open, file create, file lookup, file read, get attributes, directory read and directory write). Security filter may 94 detects a security event based on the security event definition. See Hoog, [0048], where the monitoring module extracts forensic data (i.e., “forensic artifact”) based on the monitored activity, including one or more defined activities to monitor (i.e., thus the combination representing “determining that the file change events represent the forensic artifact change”)); and
[based on a determination that the file change event represents the forensic artifact change:] pass, by the registered callback routine, event information for the file change event to an out-of-band forensic interpreter, wherein passing the event information by the registered callback routine is performed as the file change event proceeds through a driver stack of the operating system (Mu, [26:16-26], where the security filter can track and log an event history of an intruder that may be used for further analysis. See, e.g., Hoog, [0105], above where an analysis module receives and processes forensic data.
See Mu, [20:57-65], where after a request callout to a filter (i.e., “wherein passing the event information by the registered callback routine is performed”), filter framework 62 need not wait for a filter return to continue processing, where the current request may be forwarded to protocol interface backend 54 and on to file system 56 (i.e., “as the file change event proceeds through a driver stack of the operating system”, i.e., the protocol interface and file system being a part of the “driver stack” as claimed).
Note that it would have been obvious to one of ordinary skill in the art to have modified Mu such that the security filter is separate from the interpreter (i.e., analysis), and thus directly passes the event information for further analysis to Hoog’s analysis module (and resulting in an “out-of-band” forensic interpreter, as claimed), with the motivation of segmenting the various operations for greater efficiency (e.g., enabling Mu’s security filter to continue performing monitoring and filtering operations, while having Hoog’s analysis module performing analysis) as well as modularization (i.e., greater programming convenience and efficiency), while also automatically pushing information to the analysis module for more immediate analysis, i.e., faster processing).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined the teachings of Hoog and Mu (hereinafter “Hoog as modified”) with the motivation of (1) using hooks, which eases implementation (i.e., as hooks are built into many operating system kernels, and may easily provide functions to filter drivers); (2) registering for certain file events, which avoids invoking a filter callback in undesirable circumstances, thereby helping to avoid message traffic congestion and improve overall filter operation (Mu, [20:3-33]); (3) utilizing kernel-mode drivers and callback routines, which enhances security (see, e.g., Mu, [6:50-67]-[7:1-10], where the security filter is a kernel mode filter due to the sensitive nature of data being processed), as well as allowing filters to be executed in asynchronous release mode, which causes the filter to execute without blocking incoming I/O or the calling thread (Mu, [6:1-3]), thereby avoiding delays in servicing requests while still enabling security reviews to take place; and (4) passing event information while the request proceeds through a driver stack, which allows a computing environment to continue operating without experiencing the workload detrimental effects of in-band security tools, as well as allowing out-of-band solutions/remediation that does not affect computing system performance.5
Hoog as modified does not appear to explicitly teach map[ing], by the out-of-band forensic interpreter, the file to [a first code library from a set of code libraries, each code library in the set of code libraries corresponding to a different type of forensic artifact], wherein each code library is configured to identify a specific activity different from activities being identified by the other code libraries, wherein the mapping of the file comprises selecting the first code library from the set of code libraries based on the forensic artifact type determined, and wherein each of the set of code libraries includes a template activity description into which forensic analysis results are inserted to generate an activity description of a user activity on the target computer; [and] responsive to mapping the file, pass[ing] the file to the first code library.
Halcrow teaches map[ing], by the out-of-band forensic interpreter, the file to [a first code library from a set of code libraries, each code library in the set of code libraries corresponding to a different type of forensic artifact], wherein each code library is configured to identify a specific activity different from activities being identified by the other code libraries, wherein the mapping of the file comprises selecting the first code library from the set of code libraries based on the forensic artifact type determined (Halcrow, [0032], where a detector manager includes a plurality of detectors (i.e., “set of code libraries”) configured to determine whether certain events are indicative of a potential threat. Each detector may be configured to determine whether events for a specific type of file are indicative of a potential threat, e.g., a first detector for a first type of executable binary may analyze events involving executable binaries of the first type, a second detector for a second type of executable binary may be configured to analyze events involving executable binaries of a second type, etc. See also Halcrow, [0075], where the type of file may be more generally defined for, e.g., all executable binaries, all library files, all scripts, etc., such that, e.g., detector A is configured for analyzing events involving a specific type of file such as file A, detector B may be configured for analyzing events involving a specific type of file such as file B (i.e., “map the file to a first code library from a set of code libraries, each code library in the set of code libraries corresponding to a different type of forensic artifact”), etc.
Halcrow suggests/renders obvious “the mapping of the file comprises selecting the first code library from the set of code libraries based on the forensic artifact type determined” at Halcrow, [0076-0078], where detector C may analyze events involving file C, detector B may analyze events involving file B, and detector A may analyze events involving file A. Although Halcrow does not explicitly state that, e.g., file A is mapped to detector A, file B is mapped to detector B, and file C is mapped to detector C (or alternatively, that detector A is selected for analyzing file A, detector B is selected for analyzing file B, etc.), it would have been obvious to not map/pass a file to the other detectors not specialized/equipped to handle such a file type, i.e., not passing file A to detectors B and C, file B to detectors A and C, and file C to detectors A and B, with the motivation of avoiding wasted processing power/resources which would occur if the system were to pass a file to a detector that was already known not to be capable of analyzing it.
See Mu, [26:40-60], where types of requests (i.e., event types) that a filter can specifically register to receive a callback function for involve file open, file create, file lookup, file read, get attributes, directory read, and directory write, etc. (i.e., “identify a specific activity different from [other] activities [being monitored]”. See Mu, [20:57-65], [26:16-26], and Hoog, [0105], above, with regards to the forensic interpreter being “out-of-band” as claimed), and wherein each of the set of code libraries includes a template activity description into which forensic analysis results are inserted to generate an activity description of a user activity on the target computer (see Halcrow, [0032] above with respect to the “set of code libraries”. See Halcrow, [0033-0034], where the detector manager may generate findings on the potential threat (i.e., “at least one of a plurality of…template activity descriptions into which forensic analysis results are inserted to generate a human-understandable textual activity description of a user activity on the target computer”). See Hoog, [FIG. 4], where various categories of event types, e.g., “Hardware”, “Security”, “System”, and “User Activity” have a plurality of KRI values, i.e., activity descriptions); [and]
responsive to mapping the file, pass[ing] the file to the first code library (Halcrow, [0076-0078], where detector C may analyze events involving file C, detector B may analyze events involving file B, and detector A may analyze events involving file A. Although Halcrow does not appear to explicitly state that the file is “passed” as claimed, such a step is implied, as the detectors output some value corresponding to the results of the analysis of the file, i.e., the file is the input (i.e., passed to the detector), and ultimately a value related to the analysis of that file is outputted, e.g., indicating whether the file has any potential threat, in addition to assigning confidence scores to the detected potential threats (see, e.g., Halcrow, [0079-0080])).
Although Halcrow does not appear to explicitly state that a “code library” is utilized, Halcrow’s disclosed “detectors” are a series of computing instructions/steps/functions that are implemented in accordance with a particular event type (i.e., corresponding to analyzing that particular event type), and thus is equivalent to the claimed “code library”, which is also a series of computing instructions/steps/functions for analyzing certain event types. Therefore, Halcrow is equivalent to the claimed invention and the claimed invention does not distinguish over the prior art.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined the teachings of Hoog as modified and Halcrow (hereinafter “Hoog as modified”) with the motivation of allowing custom analysis steps/frameworks corresponding to different types to be utilized which has the advantages of better accuracy (i.e., certain event types may have different structures such as one has a series of events/paths that are followed, another may weigh more on simply just one dimension such as path information, etc.
Furthermore, one of ordinary skill in the art would have found it obvious to have associated each of the Halcrow’s detectors with each of Hoog’s categories of “Hardware”, “Security”, “System”, etc., seen in Hoog, [FIG. 4], each with a plurality of (template) activity descriptions, with the motivation of separating out the different types of activities/tasks being analyzed by each of the detectors and simply aggregating the results of the detectors’ findings (i.e., greater efficiency for reporting).
Lastly, it would have been obvious to one of ordinary skill in the art to have applied Halcrow’s detectors into Hoog as modified by Nguyen by substituting the type of information being analyzed in Halcrow by each of the detectors (i.e., specific events corresponding to specific file types corresponding to each detector) with Nguyen’s event types (i.e., modifying Halcrow’s detectors to analyze specific activities corresponding to each detector) with the motivation of providing more granular analysis leading to potentially better classification of whether certain activities are malicious (i.e., segmenting based on specific events as seen in Nguyen, as opposed to general files such as binaries, executables, etc., which may have a wider range of events).
Regarding claim 2: Hoog as modified teaches The computer program product of claim 1, wherein the set of computer-readable instructions are executable to implement a filter driver to receive the file change event and determine that the file change event represents the forensic artifact change (Mu, [26:40-60], where upon receiving any of these types of requests (including, e.g., file create, file write, directory read, directory write, etc.), filter framework 92 invokes security filter 94 with the particular request appropriate to the call out for security filter 94, where the call may be a simple function call or passing of a message.
See Mu, [6:50-67]-[7:1-10], where the security filter is a kernel mode filter. See Mu, [32:9-15] and [34:1-18], where security filter 94 implements callbacks for, e.g., file open, file read, file lookup, file write, get attribute and directory read. See Mu, [32:6-8], where filter 94 includes a number of definitions of security events, indicated as definitions 102. Security events have attributes that contribute to produce security event definitions, e.g., the security event definitions include attributes of certain types of I/O combinations (such as, e.g., the claimed “forensic artifact change”; recall from, e.g., Mu, [26:40-60], where the I/O requests include file open, file create, file lookup, file read, get attributes, directory read and directory write). Security filter may 94 detects a security event based on the security event definition. See Hoog, [0048], where the monitoring module extracts forensic data (i.e., “forensic artifact”) based on the monitored activity, including one or more defined activities to monitor (i.e., thus the combination representing “determining that the file change events represent the forensic artifact change”)).
Regarding claim 5: Hoog as modified teaches The computer program product of claim 1, wherein the set of computer-readable instructions comprises code executable to register a callback with the notification interface of the operating system (Mu, [26:40-60], where when security filter 94 registers with filter framework 92, a number of request types initiated by a client are selected for registration by the security filter, including file open, file create, file lookup, file read, get attributes, directory read, and directory write. See Mu, [15:36-49], where a filter framework or architecture is provided for filter operations related to data access requests and responses to and from a filer, e.g., file server, storage servers, storage appliances, etc. (Mu, [1:24-42]). See Mu, [15:61-67]-[16:1-3], where the filter framework 42 is realized as part of storage OS 300 (implying that the filter, when registering with the filter framework, is thus registered with the “operating system of a target computer” as claimed).
See Mu, [26:40-60], where upon receiving any of these types of requests (including, e.g., file create, file write, directory read, directory write, etc.), filter framework 92 invokes security filter 94 with the particular request appropriate to the call out for security filter 94, where the call may be a simple function call or passing of a message).
Regarding claim 6: Hoog as modified teaches The computer program product of claim 5, wherein the set of computer-readable instructions comprises callback routine for the callback, the callback routine executable to perform the said determining that the file change event represents the forensic artifact change (Mu, [26:40-60], where upon receiving any of these types of requests (including, e.g., file create, file write, directory read, directory write, etc.), filter framework 92 invokes security filter 94 with the particular request appropriate to the call out for security filter 94, where the call may be a simple function call or passing of a message.
See Mu, [32:9-15] and [34:1-18], where security filter 94 implements callbacks for, e.g., file open, file read, file lookup, file write, get attribute and directory read. See Mu, [32:6-8], where filter 94 includes a number of definitions of security events, indicated as definitions 102. Security events have attributes that contribute to produce security event definitions, e.g., the security event definitions include attributes of certain types of I/O combinations (such as, e.g., the claimed “forensic artifact change”; recall from, e.g., Mu, [26:40-60], where the I/O requests include file open, file create, file lookup, file read, get attributes, directory read and directory write). Security filter may 94 detects a security event based on the security event definition. See Hoog, [0048], where the monitoring module extracts forensic data (i.e., “forensic artifact”) based on the monitored activity, including one or more defined activities to monitor (i.e., thus the combination representing “determining that the file change events represent the forensic artifact change”)).
Regarding claim 7: Hoog as modified teaches The computer program product of claim 1, wherein the activity on the target computer comprises a run command activity (Hoog, [0114-0126], where the analysis module 318 may generate one or more reports including file system activity timeline, web browsing activity, user login activity, etc. (i.e., “determine an activity on the target computer”)).
Although Hoog does not appear to explicitly state that the type of information of the activity relates to a “run command” activity as claimed, the claimed invention does not distinguish over the prior art because the differences in the claim limitations and the prior art’s disclosure are only found in the nonfunctional descriptive material and are not functionally involved in the steps recited. The various analysis and determination steps would have been performed the same regardless of the specific data involved (i.e., a “run command” activity as claimed, the activities disclosed by Hoog, or some other data). Thus, this descriptive material will not distinguish the claimed invention from the prior art in terms of patentability. See In re Gulack, 703 F.2d 1381, 1385, 217 USPQ2d 401, 404 (Fed. Cir. 1983); In re Lowry, 32 F.3d 1579, 32 USPQ2d 1031 (Fed. Cir. 1994).
Therefore, it would have been obvious to one of ordinary skill in the art to have referred to Hoog’s teachings in making the claimed invention, because such data does not functionally relate to the steps in the method claimed and because the subjective interpretation of the data does not patentably distinguish the claimed invention over the prior art.
Regarding claim 8: Hoog as modified teaches The computer program product of claim 1, wherein the activity on the target computer comprises a click file activity (Hoog, [0114-0126], where the analysis module 318 may generate one or more reports including file system activity timeline, web browsing activity, user login activity, etc. (i.e., “determine an activity on the target computer”)).
Although Hoog does not appear to explicitly state that the type of information of the activity relates to a “click file” activity as claimed, the claimed invention does not distinguish over the prior art because the differences in the claim limitations and the prior art’s disclosure are only found in the nonfunctional descriptive material and are not functionally involved in the steps recited. The various analysis and determination steps would have been performed the same regardless of the specific data involved (i.e., a “click file” activity as claimed, the activities disclosed by Hoog, or some other data). Thus, this descriptive material will not distinguish the claimed invention from the prior art in terms of patentability. See In re Gulack, 703 F.2d 1381, 1385, 217 USPQ2d 401, 404 (Fed. Cir. 1983); In re Lowry, 32 F.3d 1579, 32 USPQ2d 1031 (Fed. Cir. 1994).
Therefore, it would have been obvious to one of ordinary skill in the art to have referred to Hoog’s teachings in making the claimed invention, because such data does not functionally relate to the steps in the method claimed and because the subjective interpretation of the data does not patentably distinguish the claimed invention over the prior art.
Regarding claim 9: Hoog as modified teaches The computer program product of claim 1, wherein the activity on the target computer comprises a click attachment activity (Hoog, [0114-0126], where the analysis module 318 may generate one or more reports including file system activity timeline, web browsing activity, user login activity, etc. (i.e., “determine an activity on the target computer”)).
Although Hoog does not appear to explicitly state that the type of information of the activity relates to a “click attachment” activity as claimed, the claimed invention does not distinguish over the prior art because the differences in the claim limitations and the prior art’s disclosure are only found in the nonfunctional descriptive material and are not functionally involved in the steps recited. The various analysis and determination steps would have been performed the same regardless of the specific data involved (i.e., a “click attachment” activity as claimed, the activities disclosed by Hoog, or some other data). Thus, this descriptive material will not distinguish the claimed invention from the prior art in terms of patentability. See In re Gulack, 703 F.2d 1381, 1385, 217 USPQ2d 401, 404 (Fed. Cir. 1983); In re Lowry, 32 F.3d 1579, 32 USPQ2d 1031 (Fed. Cir. 1994).
Therefore, it would have been obvious to one of ordinary skill in the art to have referred to Hoog’s teachings in making the claimed invention, because such data does not functionally relate to the steps in the method claimed and because the subjective interpretation of the data does not patentably distinguish the claimed invention over the prior art.
Regarding claim 10: Hoog as modified teaches The computer program product of claim 1, wherein the set of computer-readable instructions comprises a template activity description and said generating the forensically interpreted activity for the file change event comprises inserting the forensic metadata into the template activity description (Hoog, [0109] and [0127], where the analysis module may generate one or more reports (i.e., “forensically interpreted activity for the event”) and the results of the analysis including, for example, setting a KRI value for “New User Creation” to “FAIL” (i.e., “result”). See Hoog, [0131], where a report may include a main dashboard that includes values for KRIs, where the dashboard may include a tabular representation with graphical indications of KRI values for a variety of forensic categories (i.e., thus in this manner, the disclosed dashboard corresponds to the claimed “template activity description”)).
Regarding claim 11: Hoog as modified teaches The computer program product of claim 1, wherein the forensic artifact change comprises at least one of a creation of the file, an update to the file or a deletion of the file (Hoog, [0051-0101] and [0114], where extracted forensic data may include file system timelines, and determined activities include file system activities. Note that “file system” timelines and activities implicitly include, e.g., directory and file operations such as create, delete, update, etc.6).
Regarding claim 12: Claim 12 recites substantially the same claim limitations as claim 1, and is rejected for the same reasons.
Regarding claim 13: Claim 13 recites substantially the same claim limitations as claim 2, and is rejected for the same reasons.
Regarding claim 15: Claim 15 recites substantially the same claim limitations as claim 5, and is rejected for the same reasons.
Regarding claim 16: Claim 16 recites substantially the same claim limitations as claim 6, and is rejected for the same reasons.
Regarding claim 17: Claim 17 recites substantially the same claim limitations as claim 7, and is rejected for the same reasons.
Regarding claim 18: Claim 18 recites substantially the same claim limitations as claim 8, and is rejected for the same reasons.
Regarding claim 19: Claim 19 recites substantially the same claim limitations as claim 9, and is rejected for the same reasons.
Regarding claim 20: Claim 20 recites substantially the same claim limitations as claim 11, and is rejected for the same reasons.
Regarding claim 21: Claim 21 recites substantially the same claim limitations as claim 1, and is rejected for the same reasons.
Regarding claim 22: Claim 22 recites substantially the same claim limitations as claim 2, and is rejected for the same reasons.
Regarding claim 23: Claim 23 recites substantially the same claim limitations as claim 9, and is rejected for the same reasons.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to IRENE BAKER whose telephone number is (408)918-7601. The examiner can normally be reached M-F 8-5PM PT.
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, Boris Gorney can be reached at (571) 270-5626. 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.
/IRENE BAKER/Primary Examiner, Art Unit 2154
29 April 2026
1 This claim language corresponds closely to claim 3 of the issued ’847 patent (not shown here).
2 Recall that the forensic artifact filter performs the step of “determining that the file change event represents the forensic artifact change”; thus, the fact that the issued patent uses the phrase “forensic artifact filter” does not distinguish from the action of the forensic artifact filter that is being claimed in the present application.
3 Small. US Patent Publication No. 2008/0077988 A1 at [0012] (“Types of file system activity that may be specified by a user include directory and file operations such as create, delete, move, rename, security change, access denied while creating and access denied while opening actions”).
4 Vishnubhotia. US Patent Publication No. 2007/0011207 A1 at [0009] (“Such file events include, but are not limited to, file creation, file update and file deletion”).
5 Adams et al. US 2020/0167463 A1 at [0015].
6 See footnotes [1] and [2] above.
Prosecution Insights