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 .
DETAILED ACTION
1. This action is in response to application amendments filed on 7-2-2026.
2. Claims 1 - 14, 16 - 18 are pending. Claim 15 has been canceled. Claims 1, 12 are independent. This application was filed on 8-1-2024.
Response to Arguments
3. Applicant's arguments have been fully considered, however upon further consideration of the prior art and the claimed limitation, they were not persuasive.
A. The 112 Rejection for Claim 12 has been withdrawn due to claim amendments.
B. Applicant argues on page 10 of Remarks: … for a given user session, tracking file access by repeatedly: intercepting an attempt to access a file in a monitored location of a computer file system, determining a user identification of the user associated with the user session attempting to access the file, checking corruption of the file after access to the file by the user is closed; … .
The Examiner respectfully disagrees. Kramer discloses monitoring and intercepting file access and management operations. (see Kraemer paragraph [0017]: the modification operations include one or more file modification operations targeting one or more files, and the protection actions include intercepting the file modification operations and creating backup copies of the files before permitting the file modification operations to modify the files. In some embodiments, permitting the file modification operations to modify the files includes permitting the file modification operations to encrypt the files.)
Kramer discloses identification of a particular user (or system) attempting file access. (see Kraemer paragraph [0004]: When a user attempts to access (e.g., download, open, or execute) a file, the cybersecurity engine scans the file and extracts the file's static signature. If the file's static signature matches a signature on the blacklist, the cybersecurity engine detects the presence of a threat and intervenes to prevent the threatware from executing (e.g., by quarantining or deleting the file).)
Raju discloses checking whether the file has become corrupted after user access. (see Raju page 11: The ReadUsn API 66 may be configured to report file change activity only when the final handle has been closed on the file. As can be appreciated, for indexing purposes this provides a significant efficiency advantage over the use of the FindFirstChangeNotification and FindNextChangeNotification APIs 80, 82 which provide information on virtually all file activity,; page 20: A test for such corruption can be performed wherever appropriate, such as by file system checks, or by Index Server 60 itself.)
C. Applicant argues on page 10 of Remarks: … in a case in which more than a predefined number of the files accessed by the user become corrupted, blocking access of the user to the computer and restoring the files accessed and/or changed by the user from the backup copies of the files, … .
The Examiner respectfully disagrees. Kramer discloses tracking the number of file accesses and when the number of file accesses surpasses a threshold parameter blocking further file accesses. (see Kraemer paragraph [0021]: detecting the computational entity engaging in the instance of the second behavior includes detecting an increase in a number of files modified by the computational entity, an increase in a number of distinct file type classes associated with files modified by the computational entity, and/or an increase in a rate of file modification by the computational entity, and assigning the score to the computational entity includes increasing the score based on the increased number of modified files, the increased number of distinct file type classes, and/or the increased rate of file modification.; paragraph [0024]: determining whether the assigned score exceeds a threshold score associated with the assigned potential ransomware subcategory, and if so, initiating a mitigation action associated with the ransomware subcategory. In some embodiments, the mitigation action includes terminating execution of the computational entity, preventing the computational entity from accessing a communication network, preventing the computational entity from modifying the storage resources, (blocking access))
Raju discloses checking whether the file has become corrupted after user access. (see Raju page 11: The ReadUsn API 66 may be configured to report file change activity only when the final handle has been closed on the file. As can be appreciated, for indexing purposes this provides a significant efficiency advantage over the use of the FindFirstChangeNotification and FindNextChangeNotification APIs 80, 82 which provide information on virtually all file activity,; page 20: A test for such corruption can be performed wherever appropriate, such as by file system checks, or by Index Server 60 itself.)
D. Applicant argues on page 11 of Remarks: … Kraemer does not disclose or suggest for a given user session, tracking file access by repeatedly: intercepting an attempt to access a file in a monitored location of a computer file system, and determining a user identification of the user associated with the user session attempting to access the file.
The Examiner respectfully disagrees. Kramer discloses monitoring and intercepting file access and management operations. (see Kraemer paragraph [0017]: the modification operations include one or more file modification operations targeting one or more files, and the protection actions include intercepting the file modification operations and creating backup copies of the files before permitting the file modification operations to modify the files. In some embodiments, permitting the file modification operations to modify the files includes permitting the file modification operations to encrypt the files.)
Kramer discloses identification of a particular user attempting file access. (see Kraemer paragraph [0004]: When a user attempts to access (e.g., download, open, or execute) a file, the cybersecurity engine scans the file and extracts the file's static signature. If the file's static signature matches a signature on the blacklist, the cybersecurity engine detects the presence of a threat and intervenes to prevent the threatware from executing (e.g., by quarantining or deleting the file).)
E. Applicant argues on page 11 of Remarks: … Kraemer does not disclose identifying the user and following the user and the user session. Specifically, Kraemer does not disclose or suggest tracking multiple accessed files within the same user session based on the determined user identification.
The Examiner respectfully disagrees. Kramer discloses identification of a particular user attempting file access. (see Kraemer paragraph [0004]: When a user attempts to access (e.g., download, open, or execute) a file, the cybersecurity engine scans the file and extracts the file's static signature. If the file's static signature matches a signature on the blacklist, the cybersecurity engine detects the presence of a threat and intervenes to prevent the threatware from executing (e.g., by quarantining or deleting the file).)
Kramer discloses tracking the number of file accesses and when the number of file accesses surpasses a threshold parameter blocking further file accesses. (see Kraemer paragraph [0021]: detecting the computational entity engaging in the instance of the second behavior includes detecting an increase in a number of files modified by the computational entity, an increase in a number of distinct file type classes associated with files modified by the computational entity, and/or an increase in a rate of file modification by the computational entity, and assigning the score to the computational entity includes increasing the score based on the increased number of modified files, the increased number of distinct file type classes, and/or the increased rate of file modification.; paragraph [0024]: determining whether the assigned score exceeds a threshold score associated with the assigned potential ransomware subcategory, and if so, initiating a mitigation action associated with the ransomware subcategory. In some embodiments, the mitigation action includes terminating execution of the computational entity, preventing the computational entity from accessing a communication network, preventing the computational entity from modifying the storage resources, (blocking access))
F. Applicant argues on page 12 of Remarks: … Kraemer does not disclose or suggest, in a case in which more than a predefined number of the files accessed by the user become corrupted, blocking access of the user to the computer and restoring the files accessed and/or changed by the user from the backup copies of the files.
The Examiner respectfully disagrees. Kramer discloses making backup copies of files as file are monitored. (see Kraemer paragraph [0019]: the modification operations include one or more file modification operations targeting one or more backup files, and the protection actions include intercepting the file modification operations and creating backup copies of the backup files before permitting the file modification operations to modify the backup files.)
Kramer discloses tracking the number of file accesses and when the number of file accesses surpasses a threshold parameter blocking further file accesses. (see Kraemer paragraph [0021]: detecting the computational entity engaging in the instance of the second behavior includes detecting an increase in a number of files modified by the computational entity, an increase in a number of distinct file type classes associated with files modified by the computational entity, and/or an increase in a rate of file modification by the computational entity, and assigning the score to the computational entity includes increasing the score based on the increased number of modified files, the increased number of distinct file type classes, and/or the increased rate of file modification.; paragraph [0024]: determining whether the assigned score exceeds a threshold score associated with the assigned potential ransomware subcategory, and if so, initiating a mitigation action associated with the ransomware subcategory. In some embodiments, the mitigation action includes terminating execution of the computational entity, preventing the computational entity from accessing a communication network, preventing the computational entity from modifying the storage resources, (blocking access))
Kramer discloses restoring files modified or changed by the user using the backup copies. (see Kraemer paragraph [0024]: determining whether the assigned score exceeds a threshold score associated with the assigned potential ransomware subcategory, and if so, initiating a mitigation action associated with the ransomware subcategory. In some embodiments, the mitigation action includes terminating execution of the computational entity, preventing the computational entity from accessing a communication network, preventing the computational entity from modifying the storage resources, and/or replacing one or more files modified by the computational entity with respective backup files.)
G. Applicant argues on page 12 of Remarks: … Kraemer does not disclose applying a threshold and response to files accessed by the user.
The Examiner respectfully disagrees. Kramer discloses tracking number of file accesses and when he number of file accesses surpasses a threshold parameter blocking further file accesses. (see Kraemer paragraph [0021]: detecting the computational entity engaging in the instance of the second behavior includes detecting an increase in a number of files modified by the computational entity, an increase in a number of distinct file type classes associated with files modified by the computational entity, and/or an increase in a rate of file modification by the computational entity, and assigning the score to the computational entity includes increasing the score based on the increased number of modified files, the increased number of distinct file type classes, and/or the increased rate of file modification.; paragraph [0024]: determining whether the assigned score exceeds a threshold score associated with the assigned potential ransomware subcategory, and if so, initiating a mitigation action associated with the ransomware subcategory. In some embodiments, the mitigation action includes terminating execution of the computational entity, preventing the computational entity from accessing a communication network, preventing the computational entity from modifying the storage resources, (blocking access))
H. Applicant argues on page 12 of Remarks: … Kraemer does not disclose or suggest checking corruption of the file after access to the file by the user is closed.
The Examiner respectfully disagrees. Kramer discloses tracking number of file accesses and when he number of file accesses surpasses a threshold parameter blocking further file accesses. (see Kraemer paragraph [0021]: detecting the computational entity engaging in the instance of the second behavior includes detecting an increase in a number of files modified by the computational entity, an increase in a number of distinct file type classes associated with files modified by the computational entity, and/or an increase in a rate of file modification by the computational entity, and assigning the score to the computational entity includes increasing the score based on the increased number of modified files, the increased number of distinct file type classes, and/or the increased rate of file modification.; paragraph [0024]: determining whether the assigned score exceeds a threshold score associated with the assigned potential ransomware subcategory, and if so, initiating a mitigation action associated with the ransomware subcategory. In some embodiments, the mitigation action includes terminating execution of the computational entity, preventing the computational entity from accessing a communication network, preventing the computational entity from modifying the storage resources, (blocking access))
Raju discloses checking whether the file has become corrupted after user access. (see Raju page 11: The ReadUsn API 66 may be configured to report file change activity only when the final handle has been closed on the file. As can be appreciated, for indexing purposes this provides a significant efficiency advantage over the use of the FindFirstChangeNotification and FindNextChangeNotification APIs 80, 82 which provide information on virtually all file activity,; page 20: A test for such corruption can be performed wherever appropriate, such as by file system checks, or by Index Server 60 itself.)
I. Applicant argues on page 13 of Remarks: … Raju does not disclose or suggest for a given user session, tracking file access by repeatedly: intercepting an attempt to access a file in a monitored location of a computer file system, determining a user identification of the user associated with the user session attempting to access the file.
The Examiner respectfully disagrees. Kramer discloses tracking number of file accesses and when the number of file accesses surpasses a threshold parameter blocking further file accesses. (see Kraemer paragraph [0021]: detecting the computational entity engaging in the instance of the second behavior includes detecting an increase in a number of files modified by the computational entity, an increase in a number of distinct file type classes associated with files modified by the computational entity, and/or an increase in a rate of file modification by the computational entity, and assigning the score to the computational entity includes increasing the score based on the increased number of modified files, the increased number of distinct file type classes, and/or the increased rate of file modification.; paragraph [0024]: determining whether the assigned score exceeds a threshold score associated with the assigned potential ransomware subcategory, and if so, initiating a mitigation action associated with the ransomware subcategory. In some embodiments, the mitigation action includes terminating execution of the computational entity, preventing the computational entity from accessing a communication network, preventing the computational entity from modifying the storage resources, (blocking access))
Kramer discloses identification of a particular user (or system) attempting file access. (see Kraemer paragraph [0004]: When a user attempts to access (e.g., download, open, or execute) a file, the cybersecurity engine scans the file and extracts the file's static signature. If the file's static signature matches a signature on the blacklist, the cybersecurity engine detects the presence of a threat and intervenes to prevent the threatware from executing (e.g., by quarantining or deleting the file).)
J. Applicant argues on page 13 of Remarks: … checking corruption of the file after access to the file by the user is closed, and in a case in which more than a predefined number of the files accessed by the user become corrupted, blocking access of the user to the computer and restoring the files accessed and/or changed by the user from the backup copies of the files.
The Examiner respectfully disagrees. Raju discloses checking whether the file has become corrupted after user access. (see Raju page 11: The ReadUsn API 66 may be configured to report file change activity only when the final handle has been closed on the file. As can be appreciated, for indexing purposes this provides a significant efficiency advantage over the use of the FindFirstChangeNotification and FindNextChangeNotification APIs 80, 82 which provide information on virtually all file activity,; page 20: A test for such corruption can be performed wherever appropriate, such as by file system checks, or by Index Server 60 itself.)
Kramer discloses tracking number of file accesses and when the number of file accesses surpasses a threshold parameter blocking further file accesses. (see Kraemer paragraph [0021]: detecting the computational entity engaging in the instance of the second behavior includes detecting an increase in a number of files modified by the computational entity, an increase in a number of distinct file type classes associated with files modified by the computational entity, and/or an increase in a rate of file modification by the computational entity, and assigning the score to the computational entity includes increasing the score based on the increased number of modified files, the increased number of distinct file type classes, and/or the increased rate of file modification.; paragraph [0024]: determining whether the assigned score exceeds a threshold score associated with the assigned potential ransomware subcategory, and if so, initiating a mitigation action associated with the ransomware subcategory. In some embodiments, the mitigation action includes terminating execution of the computational entity, preventing the computational entity from accessing a communication network, preventing the computational entity from modifying the storage resources, (blocking access))
Kramer discloses restoring files modified or changed by the user using the backup copies. (see Kraemer paragraph [0024]: determining whether the assigned score exceeds a threshold score associated with the assigned potential ransomware subcategory, and if so, initiating a mitigation action associated with the ransomware subcategory. In some embodiments, the mitigation action includes terminating execution of the computational entity, preventing the computational entity from accessing a communication network, preventing the computational entity from modifying the storage resources, and/or replacing one or more files modified by the computational entity with respective backup files.)
K. Applicant argues on page 14 of Remarks: … Claims 2-11, 13, 14, and 16-18 depend either directly or indirectly from independent claims 1 and 12, and are therefore patentably distinguished over the references relied upon for at least the reasons discussed above.
Responses to arguments against the independent claims also answer arguments against the associated dependent claims.
Claim Rejections - 35 USC § 103
4. 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.
5. Claims 1, 2, 4, 5, 7, 12 - 14, 16, 17 are rejected under 35 U.S.C. 103 as being unpatentable over Kraemer et al. (US PGPUB No. 20190121978) in view of Raju et al. (Patent No. WO 99/14692).
Regarding Claim 1, 12, Kraemer discloses a computer implemented method for preventing file share related threats in a computer, or computer network and an arrangement for preventing file share related threats in a computer or computer network, the method and the system comprising:
a) for a given user session, tracking file access by repeatedly: b) intercepting an attempt to access a file (tracking file access) in a monitored location of a computer file system, (see Kraemer paragraph [0017]: the modification operations include one or more file modification operations targeting one or more files, and the protection actions include intercepting the file modification operations and creating backup copies of the files before permitting the file modification operations to modify the files. In some embodiments, permitting the file modification operations to modify the files includes permitting the file modification operations to encrypt the files.)
c) determining a user identification of the user associated with the user session attempting to access the file, (see Kraemer paragraph [0064]: Additional high-value directories may be monitored (e.g., high-value directories that could be derived by ransomware in some other way than using recursive enumeration, such as by querying the system state for mount points or user names). For example, network share mounts that often use directory structure conventions may be monitored.)
d) creating a backup copy of the file, (see Kraemer paragraph [0019]: the modification operations include one or more file modification operations targeting one or more backup files, and the protection actions include intercepting the file modification operations and creating backup copies of the backup files before permitting the file modification operations to modify the backup files.)
e) allowing the attempt to access the file in the monitored location of the computer file system after creating the backup copy of the file, (see Kraemer paragraph [0019]: the protection actions include intercepting the file modification operations and creating backup copies of the backup files before permitting the file modification operations to modify the backup files.) and
g) in a case in which more than a predefined number of the files accessed by the user become corrupted, blocking access of the user to the computer (see Kraemer paragraph [0021]: detecting the computational entity engaging in the instance of the second behavior includes detecting an increase in a number of files modified by the computational entity, an increase in a number of distinct file type classes associated with files modified by the computational entity, and/or an increase in a rate of file modification by the computational entity, and assigning the score to the computational entity includes increasing the score based on the increased number of modified files, the increased number of distinct file type classes, and/or the increased rate of file modification.; paragraph [0024]: determining whether the assigned score exceeds a threshold score associated with the assigned potential ransomware subcategory, and if so, initiating a mitigation action associated with the ransomware subcategory. In some embodiments, the mitigation action includes terminating execution of the computational entity, preventing the computational entity from accessing a communication network, preventing the computational entity from modifying the storage resources, (blocking access)) and
h) restoring the files accessed and/or changed by the user from the backup copies of the files. (see Kraemer paragraph [0024]: determining whether the assigned score exceeds a threshold score associated with the assigned potential ransomware subcategory, and if so, initiating a mitigation action associated with the ransomware subcategory. In some embodiments, the mitigation action includes terminating execution of the computational entity, preventing the computational entity from accessing a communication network, preventing the computational entity from modifying the storage resources, and/or replacing one or more files modified by the computational entity with respective backup files.)
Kraemer does not specifically disclose for f) checking corruption of file after access to file by the user is closed.
However, Raju discloses for f) wherein checking corruption of the file after access to the file by the user is closed. (see Raju page 11: The ReadUsn API 66 may be configured to report file change activity only when the final handle has been closed on the file. As can be appreciated, for indexing purposes this provides a significant efficiency advantage over the use of the FindFirstChangeNotification and FindNextChangeNotification APIs 80, 82 which provide information on virtually all file activity,; page 20: A test for such corruption can be performed wherever appropriate, such as by file system checks, or by Index Server 60 itself.)
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Kraemer for f) checking corruption of file after access to file by the user is closed as taught by Raju. One of ordinary skill in the art would have been motivated to employ the teachings of Raju for the flexibility of a system that enables multiple techniques for processing file system information such as testing for file corruption after a file has been released by a user. (see Raju page 11; page 20)
Furthermore, for Claim 12, Kraemer discloses wherein the arrangement comprises at least one computer, that is configured to perform operations. (see Kraemer paragraph [0190]: The processor 510 is capable of processing instructions for execution within the system 500. In some implementations, the processor 510 is a single-threaded processor. In some implementations, the processor 510 is a multi-threaded processor. The processor 510 is capable of processing instructions stored in the memory 520 or on the storage device 530.)
Regarding Claim 2, Kraemer-Raju discloses the method according to claim 1, wherein only the files of predefined file types are checked for corruption. (see Kraemer paragraph [0004]: When a user attempts to access (e.g., download, open, or execute) a file, the cybersecurity engine scans the file and extracts the file's static signature. If the file's static signature matches a signature on the blacklist, the cybersecurity engine detects the presence of a threat and intervenes to prevent the threatware from executing (e.g., by quarantining or deleting the file).; paragraph [0084]: Modifications of all files may be accounted for and/or prevented, however, modifications of particular file types may carry more weight than others. For example, data files may be assigned more weight. [0090] Filtering file modifications based on file location. The system may not track modifications of files located in specific directories (e.g., user folders, on network shares or backup devices, etc.) when the modifications are performed by specific computational entities. For example, events associated with known backup software modifying files on backup store may be filtered out. [0091] Filtering file modifications based on file location and file type.)
Regarding Claim 4, Kraemer-Raju discloses the method according to claim 1, wherein said checking the file corruption comprises analyzing the file structure based on a type of the file. (see Kraemer paragraph [0084]: Modifications of all files may be accounted for and/or prevented, however, modifications of particular file types may carry more weight than others. For example, data files may be assigned more weight. [0090] Filtering file modifications based on file location. The system may not track modifications of files located in specific directories (e.g., user folders, on network shares or backup devices, etc.) when the modifications are performed by specific computational entities. For example, events associated with known backup software modifying files on backup store may be filtered out. [0091] Filtering file modifications based on file location and file type.)
Regarding Claim 5, Kraemer-Raju discloses the method according to claim 1, wherein said checking corruption of the file after accessing the file comprises comparing the created backup copy and a latest version of the file and/or checking whether either or both of the created backup copy and a latest version of the file are corrupted. (see Kraemer paragraph [0075]: A computational entity may be assigned to ransomware Category C if the entity exhibits behaviors associated with disabling a computer system's backup capabilities, including, without limitation, deleting/disabling backup files and/or disabling backup/restore functionality.; (selected: created backup copy is corrupted (deleted, disabled))
Regarding Claim 7, Kraemer-Raju discloses the method according to claim 1, wherein, if less than a predefined number of files become corrupted within the given user session, allowing access by the user associated with the user session to the computer for a predefined duration without tracking or checking the files accessed by the user. (see Kraemer paragraph [0021]: detecting the computational entity engaging in the instance of the second behavior includes detecting an increase in a number of files modified by the computational entity, an increase in a number of distinct file type classes associated with files modified by the computational entity, and/or an increase in a rate of file modification by the computational entity, and assigning the score to the computational entity includes increasing the score based on the increased number of modified files, the increased number of distinct file type classes, and/or the increased rate of file modification.)
Regarding Claim 13, Kraemer-Raju discloses the system according to claim 12, wherein only the files of predefined file types are checked for corruption. (see Kraemer paragraph [0084]: The system may not track modifications of files located in specific directories (e.g., user folders, on network shares or backup devices, etc.) when the modifications are performed by specific computational entities (specific file types are processed). For example, events associated with known backup software modifying files on backup store may be filtered out.)
Regarding Claim 14, Kraemer-Raju discloses a non-transitory computer readable medium on which is stored a computer program comprising instructions which, when executed by a computer, cause the computer to carry out the method according claim 1. (see Kraemer paragraph [0190]: The processor 510 is capable of processing instructions for execution within the system 500. In some implementations, the processor 510 is a single-threaded processor. In some implementations, the processor 510 is a multi-threaded processor. The processor 510 is capable of processing instructions stored in the memory 520 or on the storage device 530.; paragraph [0193]: In some implementations, at least a portion of the approaches described above may be realized by instructions that upon execution cause one or more processing devices to carry out the processes and functions described above.)
Regarding Claim 16, Kraemer-Raju discloses the method according to claim 1, wherein said checking the file corruption comprises at least one of: checking the selected file by parsing the file; analyzing the file structure based on a type of the file; comparing the created backup copy and a latest version of the file and/or checking whether either or both of the created backup copy and a latest version of the file are corrupted; and determining ASCII-rate of the file. (see Kraemer paragraph [0004]: When a user attempts to access (e.g., download, open, or execute) a file, the cybersecurity engine scans the file and extracts the file's static signature. If the file's static signature matches a signature on the blacklist, the cybersecurity engine detects the presence of a threat and intervenes to prevent the threatware from executing (e.g., by quarantining or deleting the file).; paragraph [0084]: Modifications of all files may be accounted for and/or prevented, however, modifications of particular file types may carry more weight than others. For example, data files may be assigned more weight. [0090] Filtering file modifications based on file location. The system may not track modifications of files located in specific directories (e.g., user folders, on network shares or backup devices, etc.) when the modifications are performed by specific computational entities. For example, events associated with known backup software modifying files on backup store may be filtered out. [0091] Filtering file modifications based on file location and file type.); (selected: analyzing the file structure based on a type of the file))
Regarding Claim 17, Kraemer-Raju discloses the method according to claim 16, wherein a list of methods for said checking the file corruption is received from a server. (see Kraemer paragraph [0134]: The configuration module 140 may configure (or permit a user or administrator to configure) various parameters and settings of the behavioral security engine, including but not limited to (1) units and weights of the scoring heuristics, (2) categorization and subcategorization parameters, (3) threshold scores that trigger application of protection or mitigation actions for different ransomware categories and subcategories, and (4) protection and mitigation policies (e.g., the particular policy that is triggered when a computational entity's score reaches a particular threshold).)
6. Claim 3 is rejected under 35 U.S.C. 103 as being unpatentable over Kraemer in view of Raju and further in view of Kozlowski et al. (US PGPUB No. 20220198043).
Regarding Claim 3, Kraemer-Raju discloses the method according to claim 1.
Kraemer does not specifically disclose checking the file corruption comprises checking the selected file by parsing the file.
However, Kozlowski discloses wherein said checking the file corruption comprises checking the selected file by parsing the file. (see Kozlowski paragraph [0093]: the local management agent may receive definition files (e.g., JSON, XML, etc.) from the orchestration service, and it may parse the file to implement security risk controls such as: threat monitoring:)
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Kraemer for checking the file corruption comprises checking the selected file by parsing the file as taught by Kozlowski. One of ordinary skill in the art would have been motivated to employ the teachings of Kozlowski for the enhanced security of a system that enables multiple operations to implement security controls such as parsing a file. (see Kozlowski paragraph [0093])
7. Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Kraemer in view of Raju and further in view of Ramirez et al. (Patent No. WO 2022195134).
Regarding Claim 6, Kraemer-Raju discloses the method according to claim 1, including checking the file corruption.
Kraemer does not specifically disclose determining ASCII-rate of the file.
However, Ramirez discloses wherein said checking the file corruption comprises determining ASCII-rate of the file. (see Ramirez page 5: nchars is the number of characters in the original file. Since each character is represented by a byte, the number of bytes in the ascii file is equal to the total number of characters.)
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Kraemer for determining ASCII-rate of the file as taught by Ramirez. One of ordinary skill in the art would have been motivated to employ the teachings of Ramirez for the flexibility of a system that enables multiple types of parameters processed such as a ASCII-rate parameter. (see Ramirez page 5)
8. Claims 8, 9, 18 are rejected under 35 U.S.C. 103 as being unpatentable over Kraemer in view of Raju and further in view of Sakamoto et al. (US PGPUB No. 20050203881).
Regarding Claim 8, Kraemer-Raju discloses the method according to claim 1.
Kraemer does not specifically disclose the accessed and/or analyzed files are grouped per user to determine which said user session is malicious.
However, Sakamoto discloses wherein the accessed and/or analyzed files are grouped per user to determine which said user session is malicious. (see Sakamoto paragraph [0052]: database management systems also provide dynamic system views. The dynamic system view provides information on current user sessions and resource utilization.; paragraph [0063]: implement one or more approaches to intrusion detection data analysis. In one embodiment, statistics-based intrusion detection (SBID) and rule-based intrusion detection (RBID) maybe used in conjunction to detect anomalous database accesses.)
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Kraemer for the accessed and/or analyzed files are grouped per user to determine which said user session is malicious as taught by Sakamoto. One of ordinary skill in the art would have been motivated to employ the teachings of Sakamoto for the flexibility of a system that enables security system information from multiple parameters such as user session information. (see Sakamoto paragraph [0052]; paragraph [0063])
Regarding Claim 9, Kraemer-Raju discloses the method according to claim 1.
Kraemer does not specifically disclose the user session is a session which comprises operations performed by different processes from a process tree, or a session which comprises operations performed by a given said user per network session.
However, Sakamoto discloses wherein the user session is a session which comprises operations performed by different processes from a process tree, or a session which comprises operations performed by a given said user per network session. (see Sakamoto paragraph [0052]: database management systems also provide dynamic system views. The dynamic system view provides information on current user sessions and resource utilization.; paragraph [0063]: implement one or more approaches to intrusion detection data analysis. In one embodiment, statistics-based intrusion detection (SBID) and rule-based intrusion detection (RBID) maybe used in conjunction to detect anomalous database accesses.)
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Kraemer for the user session is a session which comprises operations performed by different processes from a process tree, or a session which comprises operations performed by a given said user per network session as taught by Sakamoto. One of ordinary skill in the art would have been motivated to employ the teachings of Sakamoto for the flexibility of a system that enables security system information from multiple parameters such as user session information. (see Sakamoto paragraph [0052]; paragraph [0063])
Regarding Claim 18, Kraemer-Raju discloses the method according to claim 1.
Kraemer does not specifically disclose all operations performed by different processes from a process tree, or a session which comprises all operations performed by a given said user per network session.
However, Sakamoto discloses wherein the user session is a session which comprises all operations performed by different processes from a process tree, or a session which comprises all operations performed by a given said user per network session. (see Sakamoto paragraph [0052]: database management systems also provide dynamic system views. The dynamic system view provides information on current user sessions and resource utilization.; paragraph [0063]: implement one or more approaches to intrusion detection data analysis. In one embodiment, statistics-based intrusion detection (SBID) and rule-based intrusion detection (RBID) maybe used in conjunction to detect anomalous database accesses.; (selected: a session which comprises all operations performed by a given said user per network session))
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Kraemer for all operations performed by different processes from a process tree, or a session which comprises all operations performed by a given said user per network session as taught by Sakamoto. One of ordinary skill in the art would have been motivated to employ the teachings of Sakamoto for the flexibility of a system that enables security system information from multiple parameters such as user session information. (see Sakamoto paragraph [0052]; paragraph [0063])
9. Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Kraemer in view of Raju and further in view of Cockayne et al. (US PGPUB No. 20090204507).
Regarding Claim 10, Kraemer-Raju discloses the method according to claim 1.
Kraemer does not specifically disclose the user identification is a global user identification (ID) on a server or a service.
However, Cockayne discloses wherein the user identification is a global user identification (ID) on a server or a service. (see Cockayne paragraph [0020]: each user must register with the client and server system using a globally distinct user identification, which can either be generated and managed by the system or through leveraging an existing global user identification generated by another system and accessible to the client and server system.)
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Kraemer for the user identification is a global user identification (ID) on a server or a service as taught by Cockayne. One of ordinary skill in the art would have been motivated to employ the teachings of Cockayne for the flexibility of a system that enables multiple parameters to be utilized in the secure processing of information such as a global user identification. (see Cockayne paragraph [0020])
10. Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Kraemer in view of Raju and further in view of Schmugar et al. (US PGPUB No. 20180018458).
Regarding Claim 11, Kraemer-Raju discloses the method according to claim 2.
Kraemer does not specifically disclose a list of the predefined file types.
However, Schmugar discloses wherein a list of the predefined file types. (see Schmugar paragraph [0024]: Communication system 100 can be configured to protect documents and other critical files from being modified or removed by encryption ransomware regardless of the type of ransomware, including unknown ransomware and ransomware using legitimate tools. In a specific example, communication system 100 can be configured to establish access control (e.g., using access control list 118) to documents or other critical types of files as well as document paths commonly targeted by ransomware. ... A security application (e.g., security engine 114) can monitor attempts to modify files including write, rename, and remove such files and block modification attempts by processes or applications not in the white-list for the type of file being modified. The white-lists can be predefined for each type of monitored file, can be extended or updated after alerting the user, extended or updated dynamically based on the reputation of the process attempting to modify the file or its parent process, or could be created dynamically depending on the applications installed on a system. Upon detecting an attempt to modify monitored files by not white-listed applications, the system can block the attempt, prevent modification, alert the user or administrator of the system or save the original unmodified version of the file)
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Kraemer for a list of the predefined file types as taught by Schmugar. One of ordinary skill in the art would have been motivated to employ the teachings of Schmugar for the enhanced security of a system the enables multiple parameters to be utilized processing information such as a list of predefined file types being accessed. (see Schmugar paragraph [0024])
Conclusion
THIS ACTION IS MADE FINAL. 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 extension fee 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 CARLTON JOHNSON whose telephone number is (571)270-1032. The examiner can normally be reached Work: 12-9PM (most days).
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, Shewaye Gelagay can be reached at 571-272-4219. 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.
/CJ/
August 24, 2026
/SHEWAYE GELAGAY/Supervisory Patent Examiner, Art Unit 2436
Prosecution Insights