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 .
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1, 2, 4, 9-15 and 18 are rejected under 35 U.S.C. 102(a)(1) and (a)(2) as being anticipated by Strogov (US 11,436,328).
Regarding claims 1 and 14, Strogov teaches A method, applied to a computer device, comprising:
obtaining an input/output (I/O) command for a file system of the computer device (see col. 8, lines 59-65: “one or more software components can be used to safeguard user data by performing operations that include one or more of monitoring a plurality of processes executing on a computing device; and detecting when a first process of the plurality of processes attempts to modify one or more parameters of a user data file”. And see col. 11, lines 60-63: “As shown in FIG. 4, initially the driver 102 receives a write block from a process running on the computing device or devices being monitored by the AR service (Step 205)”); and
in response to the I/O command instructing to perform a modification operation on an existing file in the file system,
performing a data backup procedure on the existing file (see Abstract: “The method includes monitoring a plurality of processes executing on a computing device; detecting when a first process of the plurality of processes attempts to modify one or more parameters of a user data file; determining if first process is a trusted process or an untrusted process using one or more heuristics; and if the first process is determined to be an untrusted process, create a backup version of the user data file”), and
modifying the existing file according to the I/O command (see col. 11, lines 41-49 and Fig. 2: “a snapshot of a given file 105 is created by the file protection driver 102 in response to an attempt to change such a given file 105 such as pursuant to Step D. … If the file is subsequently encrypted or otherwise modified by malware, the uncorrupted version of the file can be used to subsequently restore access to the file for a given user.”), wherein the modification operation comprises one or more of a delete operation, a rename operation, or a write operation (see col. 11, line 65-col. 12, line 18: “the write process associated with the write block received by the driver 102 is evaluated to determine if it is a trusted process or an untrusted process (Step 210). … In addition to using a write process and a write block to determine if a process is a trusted process or an untrusted process, other processes and blocks or files can be used such as a generalized first process and an associated first block or first file operated upon by the first process to provide a heuristic and other mechanisms for evaluating and detecting untrusted processes and events. In one embodiment, the write process may also operate as one or more of a write process, an overwrite process, a delete process and combinations thereof.”); and
the data backup procedure comprises:
determining whether a target process initiating the I/O command is a trusted process (see col. 11, lines 66-67: “the write process associated with the write block received by the driver 102 is evaluated to determine if it is a trusted process or an untrusted process (Step 210)”), wherein the trusted process is a non-malicious process known to the computer device (see col. 13, lines 35-38: “once the analysis by the AR Service 101 has completed, if the process is recognized or otherwise determined to be a non-malicious process (a trusted process)”); and
in response to the target process being an untrusted process, performing data backup on the existing file to obtain backup data of the existing file (see col. 13, lines 12-17: “as part of the evaluation of the process relative to the two databases, the process will be determined to be trusted or untrusted. If the process is trusted, then no further actions are required. Conversely, if the process is untrusted, file protection driver 102 creates one or more backup files of the unchanged file”).
Regarding claims 2 and 15, Strogov further teaches The method according to claim 1, wherein the computer device stores a trusted process list, the trusted process list comprises a process identifier of one or more trusted processes, and determining whether the target process initiating the I/O command is the trusted process further comprises:
in response to the trusted process list not comprising a process identifier of the target process, determining that the target process is the untrusted process (see col. 2, lines 11-16: “processes or data associated with ransomware or otherwise not identified as trusted by the trusted database can be flagged as a candidate for being associated with ransomware or other malware.”).
Regarding claims 4 and 16, Strogov teaches wherein the computer device stores an untrusted process list, the untrusted process list comprises a process identifier of one or more untrusted processes, and determining whether the target process initiating the I/O command is the trusted process further comprises:
in response to the untrusted process list comprising the process identifier of the target process, determining that the target process is the untrusted process; and
in response to the untrusted process list not comprising the process identifier of the target process, determining whether the trusted process list comprises the process identifier of the target process (see col. 10, lines 46-63: the system includes a database with a list of known untrusted processes. As a result, this database is referred to as an untrusted/unsafe database 104 because the information stored in the database is used to evaluate other processes or other data and identify such other processes or other data as untrusted or unsafe. The untrusted database can be used to flag various data and processes as unsafe.).
Regarding claims 9 and 18, Strogov teaches wherein the computer device stores a file type list, the file type list comprises one or more file types, and performing the data backup on the existing file in response to the target process being the untrusted process further comprises:
in response to the target process being the untrusted process and the file type list comprises a file type of the existing file, performing data backup on the existing file (Col. 10, lines 16-25: The rules provide a mechanism to identify the set of one or more files or folders that should be monitored. In one embodiment, the rules include file masks, folder masks, or other masks suitable for identifying files or groups of files. In one embodiment, the rules include one or more parameters selected from a group of file parameters, fixed characters, wildcard characters, folder names, file names and combinations and subsets of the foregoing. Usually, the rules include the file masks, types of files which should be monitored, or the lists of the certain files (defined by AR service 101 or by user input).).
Regarding claim 10, Strogov teaches wherein determining whether the target process initiating the I/O command is the trusted process further comprises:
in response to the file type list comprising the file type of the existing file, determining whether the target process is the trusted process (Col. 10, lines 16-25: The rules provide a mechanism to identify the set of one or more files or folders that should be monitored. In one embodiment, the rules include file masks, folder masks, or other masks suitable for identifying files or groups of files. In one embodiment, the rules include one or more parameters selected from a group of file parameters, fixed characters, wildcard characters, folder names, file names and combinations and subsets of the foregoing. Usually, the rules include the file masks, types of files which should be monitored, or the lists of the certain files (defined by AR service 101 or by user input).).
Regarding claim 11, Strogov teaches wherein after performing the data backup on the existing file, the method further comprises:
in response to that the target process is ransomware, recovering the existing file based on the backup data of the existing file (Col. 11, lines 47-56: If the file is subsequently encrypted or otherwise modified by malware, the uncorrupted version of the file can be used to subsequently restore access to the file for a given user. Thus, in one embodiment the file protection driver 102 or another component of the AR system restores one or more of user files 122 from one or more local back up 108 or cloud backup copies 107 (Step E)).
Regarding claim 12, Strogov teaches sending a file behavior log of the target process to the management device, wherein the file behavior log comprises related information about an I/O operation performed by the target process on the file system within preset duration (see col. 13, lines 28-34 and Fig. 2: “Once the initial version of the user data has been effectively preserved, the file protection driver 102 notifies AR Service 101 about the detected untrusted process. After receipt of the notification from the driver, the AR Service 101 analyzes the information received and tries to identify, if the process flagged as untrusted is a malicious process (such as malware, ransomware, etc.) or not.”); and
receiving a determining result of the target process that is sent by the management device, wherein the determining result indicates whether the target process is ransomware (see col. 13, lines 28-34 and Fig. 2: “Once the initial version of the user data has been effectively preserved, the file protection driver 102 notifies AR Service 101 about the detected untrusted process. After receipt of the notification from the driver, the AR Service 101 analyzes the information received and tries to identify, if the process flagged as untrusted is a malicious process (such as malware, ransomware, etc.) or not.”).
Regarding claim 13, Strogov teaches wherein a minifilter driver for the file system is installed in the computer device, a callback function is compiled in the minifilter driver, and an operating system of the computer device is configured to (col. 9, lines 15-22: AR processes operate with one or more services of the operating system for a given computing device to provide the features disclosed herein):
when receiving the I/O command instructing to perform the modification operation on the existing file in the file system, call the callback function to perform the data backup procedure (col. 9, lines 29-30: “a specialized file protection driver 102. This driver is also referred to as a file protector 102.” And see col. 11, lines 5-9: the file protection driver 102 is a software driver configured to monitor any attempts to change user files 105 (Step B). If a process attempts to change a file 104, the file protection driver 102 notifies the AR Service 101 about such attempts (Step C).).
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim 3 is rejected under 35 U.S.C. 103 as being unpatentable over Strogov (US 11,436,328), and further in view of Official Notice 1.
Regarding claim 3, Strogov teaches receiving the trusted process list sent by a management device (see col. 10, lines 36-41 and Fig. 2: “the system includes a database (DB) with a list of known trusted processes. As a result, this database is referred to as a trusted database 103 because the information stored in the databases is used to evaluate other processes or other data and identify such other processes or other data as trusted or safe.” And see col. 10, lines 64-65: “the databases are updated with new entries received from AR Service 101”), wherein the trusted process list is generated based on processes that have been run by multiple computer devices (see col. 13, lines 28-34 and Fig. 2: “Once the initial version of the user data has been effectively preserved, the file protection driver 102 notifies AR Service 101 about the detected untrusted process. After receipt of the notification from the driver, the AR Service 101 analyzes the information received and tries to identify, if the process flagged as untrusted is a malicious process (such as malware, ransomware, etc.) or not.”).
Strogov fails to teach a trusted process indicated by a process identifier in the trusted process list meets that the trusted process has been run by the multiple computer devices for a quantity of times greater than a quantity-of-times threshold.
The Examiner takes Official Notice 1 that it is a well-known method to let a trusted process indicated by a process identifier in the trusted process list meet that the trusted process has been run by the multiple computer devices for a quantity of times greater than a quantity-of-times threshold.
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to improve Strogov by letting a trusted process indicated by a process identifier in the trusted process list meet that the trusted process has been run by the multiple computer devices for a quantity of times greater than a quantity-of-times threshold as disclosed by Official Notice 1. It would have been obvious because doing so prevents zero-day attacks from becoming a problem.
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Strogov (US 11,436,328), and further in view of Official Notice 2.
Regarding claim 5, Strogov fails to teach wherein the untrusted process list comprises a process identifier of a process used for file compression and/or a process identifier of a process used to run a Java program.
The Examiner takes Official Notice 2 that it is a well-known method to let the untrusted process list comprise a process identifier of a process used for file compression and/or a process identifier of a process used to run a Java program.
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to improve Strogov by letting the untrusted process list comprise a process identifier of a process used for file compression and/or a process identifier of a process used to run a Java program as disclosed by Official Notice 2. It would have been obvious because a person of ordinary skill has good reason to pursue the known options within his or her technical grasp.
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Strogov (US 11,436,328), and further in view of Official Notice 3.
Regarding claim 6, Strogov fails to teach wherein a process identifier of a process comprises a process file path of the process and/or a process file content hash value of the process.
The Examiner takes Official Notice 3 that it is a well-known method to let a process identifier of a process comprise a process file path of the process and/or a process file content hash value of the process.
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to improve Strogov by letting a process identifier of a process comprise a process file path of the process and/or a process file content hash value of the process as disclosed by Official Notice 3. It would have been obvious because a person of ordinary skill has good reason to pursue the known options within his or her technical grasp.
Claims 7, 8 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Strogov (US 11,436,328).
Regarding claims 7 and 17, Strogov teaches wherein the computer device stores a file path list, the file path list comprises one or more file paths (Col. 10, lines 16-25: The rules provide a mechanism to identify the set of one or more files or folders that should be monitored. In one embodiment, the rules include file masks, folder masks, or other masks suitable for identifying files or groups of files. In one embodiment, the rules include one or more parameters selected from a group of file parameters, fixed characters, wildcard characters, folder names, file names and combinations and subsets of the foregoing. Usually, the rules include the file masks, types of files which should be monitored, or the lists of the certain files (defined by AR service 101 or by user input).), and performing the data backup on the existing file in response to the target process being the untrusted process further comprises:
in response to the target process being the untrusted process, and the file path list does (see col. 12, lines 59-63: a user can identify which files to protect and monitor such as financial records or family photos. These files would then be flagged for backup via snapshots or other backup operations).
Strogov differs from claim 7 in that it fails to in response to the target process being the untrusted process, and the file path list does not comprise a file path of the existing file, performing data backup on the existing file.
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to modify Strogov by letting performing data backup on the existing file be in response to the file path list does not comprise a file path of the existing file. It would have been obvious because doing so is a trivial design choice.
Regarding claim 8, Strogov as modified as described above in the rejection of claim 7 would teach wherein determining whether the target process initiating the I/O command is the trusted process further comprises:
in response to the file path list not comprising the file path of the existing file ((Col. 10, lines 16-25: The rules provide a mechanism to identify the set of one or more files or folders that should be monitored. In one embodiment, the rules include file masks, folder masks, or other masks suitable for identifying files or groups of files. In one embodiment, the rules include one or more parameters selected from a group of file parameters, fixed characters, wildcard characters, folder names, file names and combinations and subsets of the foregoing. Usually, the rules include the file masks, types of files which should be monitored, or the lists of the certain files (defined by AR service 101 or by user input).), determining whether the target process is the trusted process.
Claims 19 are 20 rejected under 35 U.S.C. 103 as being unpatentable over Strogov (US 11,436,328), further in view of Rotstein (US 2024/0121249), and further in view of Official Notice 1.
Regarding claim 19, Strogov teaches A management device (see col. 6, line 16 and Fig. 1: server computer 20), comprising a memory, a network interface (see col. 6, lines 16-18 and Fig. 1: “server computer 20), which may be in communication with network 22 (e.g., the Internet or a local area network)”), and at least one processor, wherein the memory is configured to store program instructions; after the at least one processor reads the program instructions stored in the memory, the management device is caused to perform the following operations (see col. 6, lines 14-16 and Fig. 1: “server-side AR process 10 (e.g., in an embodiment, AR service 101 as shown in FIG. 2) may reside on and may be executed by server computer 20”.):
receiving process logs sent (see col. 13, lines 28-34 and Fig. 2: “Once the initial version of the user data has been effectively preserved, the file protection driver 102 notifies AR Service 101 about the detected untrusted process. After receipt of the notification from the driver, the AR Service 101 analyzes the information received and tries to identify, if the process flagged as untrusted is a malicious process (such as malware, ransomware, etc.) or not.”) by multiple computer devices (see col. 5, lines 44-46 and Fig. 1: “there is shown a server-side Anti-Ransomware (AR) application or service 10 and client-side AR applications 12, 14, 16, and 18”. And see col. 6, lines 51-53 and Fig. 1: “Client-side AR processes 12, 14, 16, 18 may reside on and may be executed by client electronic devices 28, 30, 32, and/or 34 (respectively)”)
generating a trusted process list based on the process logs sent by the multiple computer devices (see col. 10, lines 36-41 and Fig. 2: “the system includes a database (DB) with a list of known trusted processes. As a result, this database is referred to as a trusted database 103 because the information stored in the databases is used to evaluate other processes or other data and identify such other processes or other data as trusted or safe.” And see col. 10, lines 64-65: “the databases are updated with new entries received from AR Service 101”. The Examiner interprets new entries of known trusted processes received by the Trust Database 103 on the client electronic devices 28, 30, 32, and/or 34 in Fig. 2 from the Anti-Ransomware Service 101 on the server 20 as a trusted process list based on the process logs sent by the multiple computer devices generated by the server 20. And see col. 13, lines 28-34 and Fig. 2: “Once the initial version of the user data has been effectively preserved, the file protection driver 102 notifies AR Service 101 about the detected untrusted process. After receipt of the notification from the driver, the AR Service 101 analyzes the information received and tries to identify, if the process flagged as untrusted is a malicious process (such as malware, ransomware, etc.) or not.” And see col. 9, lines 53-67: “the AR service 101 performs a heuristic analysis relative to the processes executing on a computing device's processor or otherwise resident in memory for the computing device or devices the AR service 101 is monitoring. The heuristic analysis of the AR service 101 is configured to identify any suspicious processes that may be malware such as ransomware, root kits, viruses or other untrusted software that presents a risk to user data 105. In one embodiment, the heuristic analysis is performed on a per write basis. The various heuristics described herein, including those relating to write processes, overwrite processes, delete processes, a first process, and the associated blocks and files operated upon or used with the foregoing processes can be used with some of all of the embodiments disclosed herewith.”), wherein the trusted process list comprises a process identifier of one or more trusted processes (see col. 2, line 66-col. 3, line 1: “the one or more heuristics includes one or more databases including data identifying trusted process parameters or trusted processes.”)
sending the trusted process list to the multiple computer devices (see col. 10, lines 36-41 and Fig. 2: “the system includes a database (DB) with a list of known trusted processes. As a result, this database is referred to as a trusted database 103 because the information stored in the databases is used to evaluate other processes or other data and identify such other processes or other data as trusted or safe.” And see col. 10, lines 64-65: “the databases are updated with new entries received from AR Service 101”. The Examiner interprets new entries of known trusted processes received by the Trust Database 103 on the client electronic devices 28, 30, 32, and/or 34 in Fig. 2 from the Anti-Ransomware Service 101 on the server 20 as the trusted process list.), wherein the trusted process list is used by the computer device to perform a data backup procedure on an existing file in a file system of the computer device (see Abstract: “The method includes monitoring a plurality of processes executing on a computing device; detecting when a first process of the plurality of processes attempts to modify one or more parameters of a user data file; determining if first process is a trusted process or an untrusted process using one or more heuristics; and if the first process is determined to be an untrusted process, create a backup version of the user data file”. And see col. 2, line 66-col. 3, line 1: “the one or more heuristics includes one or more databases including data identifying trusted process parameters or trusted processes.”).
Strogov differs from claim 19 in that it fails to teach wherein the process log comprises a process identifier of a process that has been run by the computer device.
However, Rotstein discloses wherein the process log comprises a process identifier of a process that has been run by the computer device (see [0052]: “Matching may include identifying a process identifier in the log activity data. Matching may also include matching a timestamp included in the metadata with an execution timestamp of the process and based on matching the timestamp, identifying the process identifier in the log activity data as a source of the suspected malicious activity (e.g., as discussed with respect to operation 218)”).
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to improve Strogov by letting the process log comprise a process identifier of a process that has been run by the computer device as disclosed by Rotstein in order to achieve the commonly understood benefit of uniquely identifying the process in the process log.
Strogov modified in view of Rotstein fails to teach a trusted process indicated by a process identifier in the trusted process list meets that the trusted process has been run by the multiple computer devices for a quantity of times greater than a quantity-of-times threshold.
The Examiner takes Official Notice 1 that it is a well-known method to let a trusted process indicated by a process identifier in the trusted process list meet that the trusted process has been run by the multiple computer devices for a quantity of times greater than a quantity-of-times threshold.
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to improve Strogov modified in view of Rotstein by letting a trusted process indicated by a process identifier in the trusted process list meet that the trusted process has been run by the multiple computer devices for a quantity of times greater than a quantity-of-times threshold as disclosed by Official Notice 1. It would have been obvious because doing so prevents zero-day attacks from becoming a problem.
Regarding claim 20, Strogov teaches wherein after the program instructions are read by the at least one processor, the management device is caused to further perform the following operations:
receiving a file behavior log of a target process sent by the computer device, wherein the file behavior log comprises related information about an input/output (I/O) operation performed by the target process on the file system of the computer device within preset duration (see col. 13, lines 28-34 and Fig. 2: “Once the initial version of the user data has been effectively preserved, the file protection driver 102 notifies AR Service 101 about the detected untrusted process. After receipt of the notification from the driver, the AR Service 101 analyzes the information received and tries to identify, if the process flagged as untrusted is a malicious process (such as malware, ransomware, etc.) or not.”);
determining, based on the related information about the I/O operation performed by the target process on the file system of the computer device within the preset duration, whether the target process is ransomware (see col. 13, lines 28-34 and Fig. 2: “Once the initial version of the user data has been effectively preserved, the file protection driver 102 notifies AR Service 101 about the detected untrusted process. After receipt of the notification from the driver, the AR Service 101 analyzes the information received and tries to identify, if the process flagged as untrusted is a malicious process (such as malware, ransomware, etc.) or not.”); and
sending a determining result of the target process to the computer device, wherein the determining result indicates whether the target process is ransomware (see col. 13, lines 28-34 and Fig. 2: “Once the initial version of the user data has been effectively preserved, the file protection driver 102 notifies AR Service 101 about the detected untrusted process. After receipt of the notification from the driver, the AR Service 101 analyzes the information received and tries to identify, if the process flagged as untrusted is a malicious process (such as malware, ransomware, etc.) or not.”).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ZHIMEI ZHU whose telephone number is (571)270-7990. The examiner can normally be reached 10am-6pm Monday-Friday.
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, Farid Homayounmehr can be reached at 571-272-3739. 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.
/ZHIMEI ZHU/Examiner, Art Unit 2495
Prosecution Insights