Real-Time Anomaly Detection and Rapid Mitigation in a Hybrid Cloud Environment

Application No. 18/474,185

• Filed: Sep 25, 2023
• Priority: Sep 22, 2022 — provisional 63/376,727
• Examiner: OLAEGBE, MUDASIRU K
• Art Unit: 2495
• Tech Center: 2400 — Computer Networks
• Assignee: Panzura LLC
• OA Round: 2 (Final)

Office Action

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 .
This communication is in response to the amendments filed on 04/06/2026. Claims 1-27 are currently pending in the application.

Response to Arguments
Applicant's arguments filed on 04/06/2026 have been fully considered but they are not persuasive. Applicant argued that Vasudeva et al. (US 20210334374) does not disclose all the limitations of the independent claim 1, including data security management system (DSM), the client node, and client-side data security event confirmation and response (CDSECR) as three separate components and that the agent 300 is the only component carrying out all the functions of the claim.
This argument is not correct because Vasudeva discloses these three components as
separate entities. With reference to figure. 3, of Vasudeva, the client 305 represents the claimed client node, the protection agent 300 that tracks the number of entries in the suspicious file log 310 to determine whether the number of suspicious files meets a suspicion threshold 312, which may also be referred to as a risk threshold or at-risk threshold and identifies a client or computing device on which the malware (e.g., ransomware) is running based on the information identified in the suspicious file log 310, the file event log 318, represents the claimed DSM and the administrator system from where the administrator confirms whether a malware attack is underway and responds by identifying and blocking the source of the attacks represents the claimed data security event confirmation and response (CDSECR). These components are separate but communicatively coupled together which make DSM and CDSECR capable of delivering services to nodes. These disclosures can be found in paragraphs 67-68, 71, 16, 80, and 83. The agent 300 (DSM) monitors the network to detect attacks while the administrator confirms and mitigates the detected attacks such as malware. This is a confirmation that it is not the agent 300 alone that is responsible for all the function of the limitations as recited in claim 1.

Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.

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-13 and 14-26 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 and 14 recite “and the DSM system and CDSECR are capable of providing services to multiple client nodes”. The function of this limitation is not clear in the claimed invention. Being capable of providing services does not necessarily mean that the services are being provided. Are DSM system and CDSECR just capable of providing services to multiple client nodes or are they really providing the services? Thus, this limitation renders the claims indefinite and unclear. Claims 2-13, and 15-26 are rejected due to dependency on the independent claims 1 and 14.

Claim Rejections - 35 USC § 102
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)(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-3, 5-6, 10-16, 18-19, and 24-27 rejected under 35 U.S.C. 102(a)(2) as being anticipated by U.S. PGPub. No. 20210334374 to Vasudeva et al. (hereinafter Vasudeva).

Regarding claim 1, Vasudeva discloses a method of managing data security events, the method comprising (¶0002, “The present description relates to data security, and more specifically, to systems and methods for detecting malicious software attacks and mitigating data loss associated with such malicious software attacks.”), (¶0018, “…the techniques described herein may be implemented within a distributed computing platform 102 such as a cloud computing environment (e.g., a cloud storage environment, a multi-tenant platform, a hyperscale infrastructure comprising scalable server architectures and virtual networking, etc.) configured to manage the storage and access to data on behalf of client devices and/or nodes.”):
accessing, with a data security management (DSM) system, one or more client file event records (¶0071, “The protection agent 300 also maintains a file event log 318 that tracks file events. For example, the file event log 318 tracks when a file is created, deleted, renamed, truncated, or controlled in some other manner…”), (¶0067, “The protection agent 300 tracks the number of entries in the suspicious file log 310 to determine whether the number of suspicious files meets a suspicion threshold 312, which may also be referred to as a risk threshold or at-risk threshold…”, wherein the protection agent 300 is interpreted as the claimed data security management (DSM) system), wherein:
each client file event record is uniquely associated with a client file (¶0076, “…the protection agent 300 may identify a client or computing device on which the malware (e.g., ransomware) is running based on the information identified in the suspicious file log 310, the file event log 318, or both.”);
the client node is separate from the DSM system (wherein FIG. 2, which comprises the plurality of client nodes is separate from FIG. 3 which comprises the protection agent 300 (DSM)”);
the DSM system and the client node are separate from a client-side data security event confirmation and response (CDSECR) system; and the DSM system and CDSECR are capable of providing services to multiple client nodes (¶0064, FIG. 3, wherein client 305 (client node), protection agent 300 (DSM), and user interface 324 (CDSECR), are separate components and are communicatively coupled together as depicted by the arrow, and being communicatively coupled as shown in FIG. 3 is an indication of being capable of providing services to multiple client nodes);
each of the client files includes primary file content separate from the associated client file event record (¶0095-¶0098, FIG. 7, “…Operation 714 may be performed using, for example, a format checker that analyzes the contents of the file to thereby analyze a recognizability of the file format of the file…”), (¶0084, “the suspicious file log 310 as described with respect to FIGS. 3 and 4, the file event log 318 as described with respect to FIGS. 3 and 5, or both may be used to mitigate data loss and/or identify the source of a malware attack. The suspicious file log 310 may track suspicious write requests while the file event log 318 may track all file activity so that suspicious write activity may be associated with other related suspicious file activity.”), (¶0065, “… the original file is deleted such that the original file is effectively “replaced” with the new encrypted file…”); and
the client file event record logs information directly related to the associated client file (¶0088, “… If, however, a determination is made that the file is associated with a malware attack risk, an entry for the file is added to a file log (operation 608). This file log may be, for example, the suspicious file log 310 described above in connection with FIG. 3. The entry added to this file log may include, for example, at least a portion of the information described in connection with the suspicious file entry 400 in FIG. 4…”), (¶0093, “In response to receiving a file request, a determination is made as to whether the file request is a write request to write a file to the storage node (operation 704). If the file request is not a write request, an entry is added to a file event log with the entry including information about the file corresponding to the request (operation 706)”);
monitoring the one or more client file event records with the DSM system (¶0067, “The protection agent 300 tracks the number of entries in the suspicious file log 310 to determine whether the number of suspicious files meets a suspicion threshold 312, which may also be referred to as a risk threshold or at-risk threshold…”, wherein the protection agent 300 is interpreted as the claimed data security management (DSM) system), (¶0071, “The protection agent 300 also maintains a file event log 318 that tracks file events. For example, the file event log 318 tracks when a file is created, deleted, renamed, truncated, or controlled in some other manner. This type of tracking of file activity allows the protection agent 300 to monitor for an irregular pattern or behavior that would be expected from a malware attack”);
detecting an indication of a potential data security event involving the one or more client files associated with the client file record (¶0068, “The number of entries in the suspicious file log 310 meeting the suspicion threshold 312 may be used as a signal that the storage node 304 is associated with the malware attack risk. This may be a provisional detection of a presence of a malware attack…”), (¶0089, “…A determination is made, based on an analysis of the file log, as to whether a presence of a malware attack is detected (operation 610). This detection in operation 610 is a provisional detection…”); and
upon detection by the DSM of the potential data security event (¶0068, “…The protection agent 300 uses additional evidence to determine whether a malware attack that has been provisionally detected can be confirmed as being underway, thereby making the provisional detection an official or corroborated detection. This corroborated detection may be considered a “confirmation,” with an acceptable degree of certainty, that the malware attack is underway…”), sending information to a client computing environment that causes the CDSECR system to inspect the one or more client files associated with the potential data security event to determine whether an actual data security event occurred and initiate a responsive action when the CDSECR determines an occurrence of an actual data security event (¶0016, “… When the protection agent detects (e.g., determines that the activity over time meets the threshold or other metric) that a malware attack is underway, an administrator (e.g., a storage administrator) or some other user is notified via, for example, an alert that is presented to the administrator or user via a user interface. The protection agent may also present options for data recovery to the administrator or user.”), (¶0080, “Information in any of the fields may be displayed to an administrator by, for example, the user interface 324, to assist the administrator in confirming whether a malware attack is underway and how to respond…”, wherein the administrator’s /user’s system that confirmed/corroborated the attack and responds copiously is interpreted as the claimed data security event confirmation and response (CDSECR)). See also ¶0083.

Regarding claim 2, Vasudeva discloses the method of claim 1 wherein each cloud file event record contains a file name, file path, client node identifier, user entity, event, event details, and file size (¶0078-¶0082, “…the suspicious file entry 400 may include one or more of the following fields: file name 410, path 412, inode number 414, encrypted data block numbers 416, write event time 418, user identifier (UID) 420, group identifier (GID) 422, and network session identifier 424, though any appropriate number or type of fields may be used…”).

Regarding claim 3, Vasudeva discloses the method of claim 2 wherein each client file event record is a record in an event audit table (¶0071, “The protection agent 300 also maintains a file event log 318 that tracks file events. For example, the file event log 318 tracks when a file is created, deleted, renamed, truncated, or controlled in some other manner...”), (¶0064, “the data storage node 304 takes the form of an external storage array. In these examples, a client, such as a client 305, may communicate, via one or more intermediaries (e.g., one or more web services, one or more node computing devices such as one or more of the node computing devices 206(1)-206(n), etc.), with the storage node 304 to create, delete, rename, or otherwise modify files that are stored in the storage node 304.”). See also FIGs 4-5 and ¶0080-¶0082.

Regarding claim 5, Vasudeva discloses the method of claim 1 wherein if inspection-of the client file data record indicates malicious tampering, activating a client taking protective action (¶0016, “…When the protection agent detects (e.g., determines that the activity over time meets the threshold or other metric) that a malware attack is underway, an administrator (e.g., a storage administrator) or some other user is notified via, for example, an alert that is presented to the administrator or user via a user interface. The protection agent may also present options for data recovery to the administrator or user.”), (¶0098, “if the malware attack is confirmed as being underway, a notification is generated, and any previously generated snapshots are locked (operation 724). In other examples, only the most recent snapshot or recent few snapshots may be locked. In one or more examples, the notification that is generated may be visually presented via a user interface to, for example, a storage administrator, to allow the user to determine whether to restore any impacted files from one or more of the previously generated snapshots or from the deleted files directory.”). See also ¶0080.

Regarding claim 6, Vasudeva discloses the method of claim 1 wherein the data security event is an anomalous activity that comprises at least one of:
a. a content mismatch in the client file between a type of content of the client file and an extension of a name of the client file;
b. a signature or file fingerprint indicating an encrypted file when the signature or file fingerprint is not expected to have encrypted content (¶0087, “…Accordingly, data that is encrypted is considered as being encrypted due to malware. When the data in the file is determined to be encrypted, the file is flagged as being suspicious or, in other words, as potentially being part of a malware attack.”);
c. at least one of the client files is encoded in a binary file format and the client files are unintelligible;
d. at least one of the client files is an undetectable type of file (¶0069, “Recognizable file formats may include, for example, but are not limited to, compressed file formats (e.g., a zip file format, a gzip file format, etc.) and media file formats (e.g., a video file format, an image file format, etc.). In one or more examples, the protection agent 300 may consider the file 306 suspicious (or associated with a malware attack risk) in the event that both the data 308 is determined to be encrypted and the format checker 316 is unable to recognize the file format 315 of the file 306.”),
(¶0070, “…The corresponding entry is then added if the format checker 316 is unable to recognize the file format 315 of the file 306…”);
e. at least one of the client files has an extension known to correspond to an extension associated with a ransomware attack; and
f a user entity of the client node deviating from a predetermined normal file interaction behavior of the user entity, wherein the file interaction behavior of the user entity includes one or more of file read/writes, abnormal number of file deletions, abnormal number of reads of files not normally accessed by the user entity, files accessed, files deleted, and files renamed (¶0073, “…Irregular file activity may include, for example, accessing multiple files within a short period of time, where those files have no known correlation and are rarely accessed. In another example, the pattern analyzer 319 may look for an unusual amount of file deletion and file creation activity within a certain period of time as an indicator of a malware attack…”), (¶0071, “…the file event log 318 tracks when a file is created, deleted, renamed, truncated, or controlled in some other manner. This type of tracking of file activity allows the protection agent 300 to monitor for an irregular pattern or behavior that would be expected from a malware attack”), (¶0065, “For a particular file stored on the storage node 304, a malware attack may attempt to retrieve the file, encrypt data in that file, and write the encrypted data to a new encrypted file on the storage node 304. In many cases, the original file is deleted such that the original file is effectively “replaced” with the new encrypted file…”).

Regarding claim 10, Vasudeva discloses the method of claim 1 wherein the responsive action comprises at least one of:
a. sending an alert (¶0016, “When the protection agent detects (e.g., determines that the activity over time meets the threshold or other metric) that a malware attack is underway, an administrator (e.g., a storage administrator) or some other user is notified via, for example, an alert that is presented to the administrator or user via a user interface…”);
b. restricting access to the client node used by a most recent user entity connected to the data security event;
c. taking a snapshot of the metadata of each of the one or more client files (¶0017, “Thus, the methods, systems, and machine-readable media described herein enable early detection of malware attacks, such as ransomware attacks, as well as data loss mitigation via special snapshot creation and/or notification of the detected malware attacks.”), (¶0068, “The number of entries in the suspicious file log 310 meeting the suspicion threshold 312 may be used as a signal that the storage node 304 is associated with the malware attack risk. This may be a provisional detection of a presence of a malware attack. Accordingly, this signal may trigger the generation of a snapshot 314 of the volume 309 by the protection agent 300…”);
taking a snapshot of a mapping of each of the one or more client files to blocks of memory; and
utilizing the snapshot to revert the one or-more client files to a pre-data security event backup copy (¶0075, “…The protection agent 300, the storage administrator, or a combination of the two may determine whether a given impacted file should be restored from a snapshot or from the deleted files directory 320. For example, if the deleted files directory 320 contains a version of the impacted file at a timepoint that is closer to when the malware attack is determined to have begun or when the malware attack was detected as compared to the snapshot, the impacted file may be restored from the deleted files directory 320.”).

Regarding claim 23, Vasudeva discloses the system of claim 14 further comprising a client-side data security event confirmation and response system (CDSECR) (¶0016, “… When the protection agent detects (e.g., determines that the activity over time meets the threshold or other metric) that a malware attack is underway, an administrator (e.g., a storage administrator) or some other user is notified via, for example, an alert that is presented to the administrator or user via a user interface. The protection agent may also present options for data recovery to the administrator or user.”), (¶0080, “Information in any of the fields may be displayed to an administrator by, for example, the user interface 324, to assist the administrator in confirming whether a malware attack is underway and how to respond…”, wherein the administrator’s /user’s system that confirmed/corroborated the attack and responds copiously is interpreted as the claimed data security event confirmation and response (CDSECR)). See also ¶0082, wherein the CDSECR system includes one or more processors and a memory, coupled to the one or more processors, that includes code that when executed by the one or more processors causes the one or-more processors to perform operations comprising (claim 14, “… and a processor coupled to the at least one memory, the at least one processor configured to execute the machine-executable code to cause the processor to: detect an incoming request to write a file to a storage node…”):
receiving the information from the DSM (¶0075, “…the protection agent 300 employs a user interface 324 that is displayed on client 305 to present information about the one or more files that are potentially impacted to, for example, the storage administrator…”), (¶0080, “…an identification of the source may be used to block any further file requests from the source, may be included in an alert and/or a report generated in response to the corroborated detection of the malware attack, may be used in one or more mitigation techniques, or a combination thereof.”); and
performing a response action (¶0080, “…an identification of the source may be used to block any further file requests from the source, may be included in an alert and/or a report generated in response to the corroborated detection of the malware attack, may be used in one or more mitigation techniques, or a combination thereof.”), wherein the responsive action comprises:
determining if an actual data security event occurred (¶0072, “the protection agent 300 uses pattern analyzer 319 to analyze the suspicious file log 310, the file event log 318, or both to determine whether the provisional detection can be corroborated and thereby confirm, with an acceptable degree of certainty, that a malware attack is underway whether a malware attack is underway. The pattern analyzer 319 evaluates the file activity over a plurality of files stored in the volume 309 (e.g., by reference to the file event log 318) to determine whether the volume 309 has a malware attack underway…”); and
when an actual data security event occurs, performing one or more responsive actions (¶0075, “When the protection agent 300 has made a corroborated detection of a malware attack (e.g., confirmed that a malware attack is underway with an acceptable degree of certainty), the protection agent 300 uses the suspicious file log 310, the file event log 318, or both to identify the one or more files that are potentially impacted. In one or more examples, the protection agent 300 employs a user interface 324 that is displayed on client 305 to present information about the one or more files that are potentially impacted to, for example, the storage administrator. The protection agent 300 may also identify and present recovery options for the one or more files that are potentially impacted.”) comprising:
a. sending an alert (¶0016, “When the protection agent detects (e.g., determines that the activity over time meets the threshold or other metric) that a malware attack is underway, an administrator (e.g., a storage administrator) or some other user is notified via, for example, an alert that is presented to the administrator or user via a user interface…”);
b. restricting access to the client node used by a most recent user entity connected to the data security event;
c. taking a snapshot of the metadata of each of the one or more client files (¶0017, “Thus, the methods, systems, and machine-readable media described herein enable early detection of malware attacks, such as ransomware attacks, as well as data loss mitigation via special snapshot creation and/or notification of the detected malware attacks.”), (¶0068, “The number of entries in the suspicious file log 310 meeting the suspicion threshold 312 may be used as a signal that the storage node 304 is associated with the malware attack risk. This may be a provisional detection of a presence of a malware attack. Accordingly, this signal may trigger the generation of a snapshot 314 of the volume 309 by the protection agent 300…”);
taking a snapshot of a mapping of each of the one or more client files to blocks of memory; and
utilizing the snapshot to revert the one or-more client files to a pre-data security event backup copy (¶0074, “…The protection agent 300, the storage administrator, or a combination of the two may determine whether a given impacted file should be restored from a snapshot or from the deleted files directory 320. For example, if the deleted files directory 320 contains a version of the impacted file at a timepoint that is closer to when the malware attack is determined to have begun or when the malware attack was detected as compared to the snapshot, the impacted file may be restored from the deleted files directory 320.”).

Regarding claim 11, Vasudeva discloses the method of claim 1 wherein the data security event is a ransomware attack (¶0076, “For example, the protection agent 300 may identify a client or computing device on which the malware (e.g., ransomware) is running based on the information identified in the suspicious file log 310, the file event log 318, or both.”). See also ¶0066, ¶0111 and ¶0065 for ransomware attack.

Regarding claim 24, Vasudeva discloses the system of claim 14 wherein the data security event is a ransomware attack (¶0076, “For example, the protection agent 300 may identify a client or computing device on which the malware (e.g., ransomware) is running based on the information identified in the suspicious file log 310, the file event log 318, or both.”). See also ¶0066, ¶0111 and ¶0065 for ransomware attack.

Regarding claim 12, Vasudeva discloses the method of claim 1 wherein the one or more client file event records are created by the client node and stored in an audit table in a folder shared by the DSM system and the client node (¶0064-¶0065, FIGs. 2 and 3, “…a client, such as a client 305, may communicate, via one or more intermediaries (e.g., one or more web services, one or more node computing devices such as one or more of the node computing devices 206(1)-206(n), etc.), with the storage node 304 to create, delete, rename, or otherwise modify files that are stored in the storage node 304.”, wherein node 304 with different directories/folders is interpreted as the audit table, and wherein agent 300 and client node 305 are collocated within node 304), (¶0019, “For example, the client node 128 may transmit operations, such as data operations to read data and write data and metadata operations (e.g., a create file operation, a rename directory operation, a resize operation, a set attribute operation, etc.), over a network 126 to the first node 130 for implementation by the first node 130 upon storage…”), (¶0054, “…Volumes 218(1)-218(n) can span a portion of a disk or other storage device, a collection of disks, or portions of disks, for example, and typically define an overall logical arrangement of data storage. In one example volumes 218(1)-218(n) can include stored user data as one or more files, blocks, or objects that may reside in a hierarchical directory structure within the volumes 218(1)-218(n).”) and accessing the one or more client file event records comprises:
accessing the audit table in the shared folder (¶0071, “The protection agent 300 also maintains a file event log 318 that tracks file events. For example, the file event log 318 tracks when a file is created, deleted, renamed, truncated, or controlled in some other manner…”), (¶0067, “The protection agent 300 tracks the number of entries in the suspicious file log 310 to determine whether the number of suspicious files meets a suspicion threshold 312…”).

Regarding claim 25, Vasudeva discloses the system of claim 14 wherein the one or more client file event records are created by the client node and stored in an audit table in a folder shared by the DSM system and the client node (¶0064-¶0065, FIGs. 2 and 3, “…a client, such as a client 305, may communicate, via one or more intermediaries (e.g., one or more web services, one or more node computing devices such as one or more of the node computing devices 206(1)-206(n), etc.), with the storage node 304 to create, delete, rename, or otherwise modify files that are stored in the storage node 304.”, wherein node 304 with different directories/folders is interpreted as the audit table, and wherein agent 300 and client node 305 are collocated within node 304), (¶0019, “For example, the client node 128 may transmit operations, such as data operations to read data and write data and metadata operations (e.g., a create file operation, a rename directory operation, a resize operation, a set attribute operation, etc.), over a network 126 to the first node 130 for implementation by the first node 130 upon storage…”), (¶0054, “…Volumes 218(1)-218(n) can span a portion of a disk or other storage device, a collection of disks, or portions of disks, for example, and typically define an overall logical arrangement of data storage. In one example volumes 218(1)-218(n) can include stored user data as one or more files, blocks, or objects that may reside in a hierarchical directory structure within the volumes 218(1)-218(n).”) and accessing the one or more client file event records comprises:
accessing the audit table in the shared folder (¶0071, “The protection agent 300 also maintains a file event log 318 that tracks file events. For example, the file event log 318 tracks when a file is created, deleted, renamed, truncated, or controlled in some other manner…”), (¶0067, “The protection agent 300 tracks the number of entries in the suspicious file log 310 to determine whether the number of suspicious files meets a suspicion threshold 312…”).

Regarding claim 13, Vasudeva discloses the method of claim 1 further comprising:
inspecting in the client node the one or more client files directly to determine whether an existence of an actual data security event occurred (¶0076, “…the protection agent 300 may identify a client or computing device on which the malware (e.g., ransomware) is running based on the information identified in the suspicious file log 310, the file event log 318, or both.”); and
generating the responsive action if the client node detects the actual data security event (¶0015, “…The protection agent can quickly identify when files that are being requested to be written to the storage node are suspicious and can generate a snapshot of at least a portion of the storage node (e.g., a volume of the storage node to which the file was to be written) in response to detecting suspicious files. A suspicious file may be a file that is associated with a malware attack risk…”), (¶0080, “Information in any of the fields may be displayed to an administrator by, for example, the user interface 324, to assist the administrator in confirming whether a malware attack is underway and how to respond. Additionally, one or more of the fields may be used by the protection agent 300 to suggest options to the administrator (e.g., by displaying via the user interface 324) for protecting against the malware attack or for fixing the file 306. For example, the inode number 414 may be matched to a snapshot or another copy of the data, thereby allowing the snapshot or other copy to be used as an alternative to data that may be surreptitiously encrypted…”).

Regarding claim 26, Vasudeva discloses the-system of claim 14 further comprising a client-side data security event confirmation and response system (CDSECR) (¶0016, “… When the protection agent detects (e.g., determines that the activity over time meets the threshold or other metric) that a malware attack is underway, an administrator (e.g., a storage administrator) or some other user is notified via, for example, an alert that is presented to the administrator or user via a user interface. The protection agent may also present options for data recovery to the administrator or user.”), (¶0080, “Information in any of the fields may be displayed to an administrator by, for example, the user interface 324, to assist the administrator in confirming whether a malware attack is underway and how to respond…”, wherein the administrator’s /user’s system that confirmed/corroborated the attack and responds copiously is interpreted as the claimed data security event confirmation and response (CDSECR)), wherein the CDSECR system includes one or more processors and a memory, coupled to the one or more processors, that includes code that when executed by the one or more processors causes the one or more processors to perform operations (claim 14, “…and a processor coupled to the memory, the processor configured to execute the machine-executable code to: analyze data in a file associated with a write request to the storage node to determine whether the file is associated with a malware attack risk, the analysis comprising…”) comprising:
inspecting in the client node the one or more client files directly to determine whether an existence of an actual data security event occurred (¶0076, “…the protection agent 300 may identify a client or computing device on which the malware (e.g., ransomware) is running based on the information identified in the suspicious file log 310, the file event log 318, or both.”); and
generating the responsive action if the client node detects the actual data security event (¶0015, “…The protection agent can quickly identify when files that are being requested to be written to the storage node are suspicious and can generate a snapshot of at least a portion of the storage node (e.g., a volume of the storage node to which the file was to be written) in response to detecting suspicious files. A suspicious file may be a file that is associated with a malware attack risk…”), (¶0080, “Information in any of the fields may be displayed to an administrator by, for example, the user interface 324, to assist the administrator in confirming whether a malware attack is underway and how to respond. Additionally, one or more of the fields may be used by the protection agent 300 to suggest options to the administrator (e.g., by displaying via the user interface 324) for protecting against the malware attack or for fixing the file 306. For example, the inode number 414 may be matched to a snapshot or another copy of the data, thereby allowing the snapshot or other copy to be used as an alternative to data that may be surreptitiously encrypted…”).

Regarding claim 14, Vasudeva discloses data security management (DSM) system (¶0002, “The present description relates to data security, and more specifically, to systems and methods for detecting malicious software attacks and mitigating data loss associated with such malicious software attacks.”), (¶0018, “…the techniques described herein may be implemented within a distributed computing platform 102 such as a cloud computing environment (e.g., a cloud storage environment, a multi-tenant platform, a hyperscale infrastructure comprising scalable server architectures and virtual networking, etc.) configured to manage the storage and access to data on behalf of client devices and/or nodes.”) comprising one or more processors and a memory, coupled to one or more processors, wherein the memory includes stored code that when executed by the one or more processors causes the DSM system to perform operations comprising (claim 14, “…and a processor coupled to the memory, the processor configured to execute the machine-executable code to: analyze data in a file associated with a write request to the storage node to determine whether the file is associated with a malware attack risk, the analysis comprising…”):
accessing one or more client file event records (¶0071, “The protection agent 300 also maintains a file event log 318 that tracks file events. For example, the file event log 318 tracks when a file is created, deleted, renamed, truncated, or controlled in some other manner…”), (¶0067, “The protection agent 300 tracks the number of entries in the suspicious file log 310 to determine whether the number of suspicious files meets a suspicion threshold 312, which may also be referred to as a risk threshold or at-risk threshold…”, wherein the protection agent 300 is interpreted as the claimed data security management (DSM) system), wherein:
each client file event record is uniquely associated with a client file (¶0076, “…the protection agent 300 may identify a client or computing device on which the malware (e.g., ransomware) is running based on the information identified in the suspicious file log 310, the file event log 318, or both.”);
the client node is separate from the DSM system (wherein FIG. 2, which comprises the plurality of client nodes is separate from FIG. 3 which comprises the protection agent 300 (DSM)”);
the DSM system and the client node are separate from a client-side data security event confirmation and response (CDSECR) system; and the DSM system and CDSECR are capable of providing services to multiple client nodes (¶0064, FIG. 3, wherein client 305 (client node), protection agent 300 (DSM), and user interface 324 (CDSECR), are separate components and are communicatively coupled together as depicted by the arrow, and being communicatively coupled as shown in FIG. 3 is an indication of being capable of providing services to multiple client nodes);
each of the client files includes primary file content separate from the associated client file event record (¶0096-¶0098, FIG. 7, “…Operation 714 may be performed using, for example, a format checker that analyzes the contents of the file to thereby analyze a recognizability of the file format of the file…”), (¶0084, “the suspicious file log 310 as described with respect to FIGS. 3 and 4, the file event log 318 as described with respect to FIGS. 3 and 5, or both may be used to mitigate data loss and/or identify the source of a malware attack. The suspicious file log 310 may track suspicious write requests while the file event log 318 may track all file activity so that suspicious write activity may be associated with other related suspicious file activity.”), (¶0065, “… the original file is deleted such that the original file is effectively “replaced” with the new encrypted file…”); and
the client file event record logs information directly related to the associated client file (¶0088, “… If, however, a determination is made that the file is associated with a malware attack risk, an entry for the file is added to a file log (operation 608). This file log may be, for example, the suspicious file log 310 described above in connection with FIG. 3. The entry added to this file log may include, for example, at least a portion of the information described in connection with the suspicious file entry 400 in FIG. 4…”), (¶0093, “In response to receiving a file request, a determination is made as to whether the file request is a write request to write a file to the storage node (operation 704). If the file request is not a write request, an entry is added to a file event log with the entry including information about the file corresponding to the request (operation 706)”);
monitoring the one or more client file event records with the DSM system (¶0067, “The protection agent 300 tracks the number of entries in the suspicious file log 310 to determine whether the number of suspicious files meets a suspicion threshold 312, which may also be referred to as a risk threshold or at-risk threshold…”, wherein the protection agent 300 is interpreted as the claimed data security management (DSM) system), (¶0071, “The protection agent 300 also maintains a file event log 318 that tracks file events. For example, the file event log 318 tracks when a file is created, deleted, renamed, truncated, or controlled in some other manner. This type of tracking of file activity allows the protection agent 300 to monitor for an irregular pattern or behavior that would be expected from a malware attack…”);
detecting an indication of a potential data security event involving the one or more client files associated with the client file record (¶0068, “The number of entries in the suspicious file log 310 meeting the suspicion threshold 312 may be used as a signal that the storage node 304 is associated with the malware attack risk. This may be a provisional detection of a presence of a malware attack…”), (¶0089, “…A determination is made, based on an analysis of the file log, as to whether a presence of a malware attack is detected (operation 610). This detection in operation 610 is a provisional detection…”); and
upon detection by the DSM of the potential data security event (¶0068, “…The protection agent 300 uses additional evidence to determine whether a malware attack that has been provisionally detected can be confirmed as being underway, thereby making the provisional detection an official or corroborated detection. This corroborated detection may be considered a “confirmation,” with an acceptable degree of certainty, that the malware attack is underway…”), sending information to a client computing environment that causes the CDSECR system to inspect the one or more client files associated with the potential data security event to determine whether an actual data security event occurred and initiate a responsive action when the CDSECR determines an occurrence of an actual data security event (¶0016, “… When the protection agent detects (e.g., determines that the activity over time meets the threshold or other metric) that a malware attack is underway, an administrator (e.g., a storage administrator) or some other user is notified via, for example, an alert that is presented to the administrator or user via a user interface. The protection agent may also present options for data recovery to the administrator or user.”), (¶0080, “Information in any of the fields may be displayed to an administrator by, for example, the user interface 324, to assist the administrator in confirming whether a malware attack is underway and how to respond…”, wherein the administrator’s /user’s system that confirmed/corroborated the attack and responds copiously is interpreted as the claimed data security event confirmation and response (CDSECR)). See also ¶0083.

Regarding claim 15, Vasudeva discloses the method of claim 14 wherein each cloud file event record contains a file name, file path, client node identifier, user entity, event, event details, and file size (¶0078-¶0082, “…the suspicious file entry 400 may include one or more of the following fields: file name 410, path 412, inode number 414, encrypted data block numbers 416, write event time 418, user identifier (UID) 420, group identifier (GID) 422, and network session identifier 424, though any appropriate number or type of fields may be used…”).

Regarding claim 16, Vasudeva discloses the system of claim 14 wherein each client-file event record is a record in an event audit table (¶0071, “The protection agent 300 also maintains a file event log 318 that tracks file events. For example, the file event log 318 tracks when a file is created, deleted, renamed, truncated, or controlled in some other manner...”), (¶0064, “the data storage node 304 takes the form of an external storage array. In these examples, a client, such as a client 305, may communicate, via one or more intermediaries (e.g., one or more web services, one or more node computing devices such as one or more of the node computing devices 206(1)-206(n), etc.), with the storage node 304 to create, delete, rename, or otherwise modify files that are stored in the storage node 304.”). See also FIGs 4-5 and ¶0080-¶0082.

Regarding claim 18, Vasudeva discloses the system of claim 14 wherein if inspection-of the client file data record indicates malicious tampering, activating a client taking protective action (¶0016, “…When the protection agent detects (e.g., determines that the activity over time meets the threshold or other metric) that a malware attack is underway, an administrator (e.g., a storage administrator) or some other user is notified via, for example, an alert that is presented to the administrator or user via a user interface. The protection agent may also present options for data recovery to the administrator or user.”), (¶0098, “if the malware attack is confirmed as being underway, a notification is generated, and any previously generated snapshots are locked (operation 724). In other examples, only the most recent snapshot or recent few snapshots may be locked. In one or more examples, the notification that is generated may be visually presented via a user interface to, for example, a storage administrator, to allow the user to determine whether to restore any impacted files from one or more of the previously generated snapshots or from the deleted files directory.”). See also ¶0080.

Regarding claim 19, Vasudeva discloses the method of claim 14 wherein the data security event is an anomalous activity that comprises at least one of:
a. a content mismatch in the client file between a type of content of the client file and an extension of a name of the client file;
b. a signature or file fingerprint indicating an encrypted file when the signature or file fingerprint is not expected to have encrypted content (¶0087, “…Accordingly, data that is encrypted is considered as being encrypted due to malware. When the data in the file is determined to be encrypted, the file is flagged as being suspicious or, in other words, as potentially being part of a malware attack.”);
c. at least one of the client files is encoded in a binary file format and the client files are unintelligible;
d. at least one of the client files is an undetectable type of file (¶0069, “Recognizable file formats may include, for example, but are not limited to, compressed file formats (e.g., a zip file format, a gzip file format, etc.) and media file formats (e.g., a video file format, an image file format, etc.). In one or more examples, the protection agent 300 may consider the file 306 suspicious (or associated with a malware attack risk) in the event that both the data 308 is determined to be encrypted and the format checker 316 is unable to recognize the file format 315 of the file 306.”),
(¶0070, “…The corresponding entry is then added if the format checker 316 is unable to recognize the file format 315 of the file 306…”);
e. at least one of the client files has an extension known to correspond to an extension associated with a ransomware attack; and
f a user entity of the client node deviating from a predetermined normal file interaction behavior of the user entity, wherein the file interaction behavior of the user entity includes one or more of file read/writes, abnormal number of file deletions, abnormal number of reads of files not normally accessed by the user entity, files accessed, files deleted, and files renamed (¶0073, “…Irregular file activity may include, for example, accessing multiple files within a short period of time, where those files have no known correlation and are rarely accessed. In another example, the pattern analyzer 319 may look for an unusual amount of file deletion and file creation activity within a certain period of time as an indicator of a malware attack…”), (¶0071, “…the file event log 318 tracks when a file is created, deleted, renamed, truncated, or controlled in some other manner. This type of tracking of file activity allows the protection agent 300 to monitor for an irregular pattern or behavior that would be expected from a malware attack”), (¶0065, “For a particular file stored on the storage node 304, a malware attack may attempt to retrieve the file, encrypt data in that file, and write the encrypted data to a new encrypted file on the storage node 304. In many cases, the original file is deleted such that the original file is effectively “replaced” with the new encrypted file…”).

Regarding claim 27, Vasudeva discloses a non-transitory, computer readable medium having code stored therein to manage data security events, wherein when execution of the code by one or more processors causes the one or more processors to perform operations comprising (¶0112, “…it is understood that any operation of the computing systems of the computing environment 100, the network environment 200, and the storage node 304 may be implemented by a computing system using corresponding instructions stored on or in a non-transitory computer-readable medium accessible by a processing system…”), (¶0002, “The present description relates to data security, and more specifically, to systems and methods for detecting malicious software attacks and mitigating data loss associated with such malicious software attacks.”), (¶0018, “…the techniques described herein may be implemented within a distributed computing platform 102 such as a cloud computing environment (e.g., a cloud storage environment, a multi-tenant platform, a hyperscale infrastructure comprising scalable server architectures and virtual networking, etc.) configured to manage the storage and access to data on behalf of client devices and/or nodes.”):
accessing, with a data security management (DSM) system, one or more client file event records (¶0071, “The protection agent 300 also maintains a file event log 318 that tracks file events. For example, the file event log 318 tracks when a file is created, deleted, renamed, truncated, or controlled in some other manner…”), (¶0067, “The protection agent 300 tracks the number of entries in the suspicious file log 310 to determine whether the number of suspicious files meets a suspicion threshold 312, which may also be referred to as a risk threshold or at-risk threshold…”, wherein the protection agent 300 is interpreted as the claimed data security management (DSM) system), wherein:
each client file event record is uniquely associated with a client file (¶0076, “…the protection agent 300 may identify a client or computing device on which the malware (e.g., ransomware) is running based on the information identified in the suspicious file log 310, the file event log 318, or both.”);
the client node is separate from the DSM system (wherein FIG. 2, which comprises the plurality of client nodes is separate from FIG. 3 which comprises the protection agent 300 (DSM)”);
each of the client files includes primary file content separate from the associated client file event record (¶0096-¶0098, FIG. 7, “…Operation 714 may be performed using, for example, a format checker that analyzes the contents of the file to thereby analyze a recognizability of the file format of the file…”), (¶0084, “the suspicious file log 310 as described with respect to FIGS. 3 and 4, the file event log 318 as described with respect to FIGS. 3 and 5, or both may be used to mitigate data loss and/or identify the source of a malware attack. The suspicious file log 310 may track suspicious write requests while the file event log 318 may track all file activity so that suspicious write activity may be associated with other related suspicious file activity.”), (¶0065, “… the original file is deleted such that the original file is effectively “replaced” with the new encrypted file…”); and
the client file event record logs information directly related to the associated client file (¶0088, “… If, however, a determination is made that the file is associated with a malware attack risk, an entry for the file is added to a file log (operation 608). This file log may be, for example, the suspicious file log 310 described above in connection with FIG. 3. The entry added to this file log may include, for example, at least a portion of the information described in connection with the suspicious file entry 400 in FIG. 4…”), (¶0093, “In response to receiving a file request, a determination is made as to whether the file request is a write request to write a file to the storage node (operation 704). If the file request is not a write request, an entry is added to a file event log with the entry including information about the file corresponding to the request (operation 706)”);
monitoring the one or more client file event records with the DSM system (¶0067, “The protection agent 300 tracks the number of entries in the suspicious file log 310 to determine whether the number of suspicious files meets a suspicion threshold 312, which may also be referred to as a risk threshold or at-risk threshold…”, wherein the protection agent 300 is interpreted as the claimed data security management (DSM) system), (¶0071, “The protection agent 300 also maintains a file event log 318 that tracks file events. For example, the file event log 318 tracks when a file is created, deleted, renamed, truncated, or controlled in some other manner. This type of tracking of file activity allows the protection agent 300 to monitor for an irregular pattern or behavior that would be expected from a malware attack…”);
detecting an indication of a potential data security event involving the one or more client files associated with the client file record (¶0068, “The number of entries in the suspicious file log 310 meeting the suspicion threshold 312 may be used as a signal that the storage node 304 is associated with the malware attack risk. This may be a provisional detection of a presence of a malware attack…”), (¶0089, “…A determination is made, based on an analysis of the file log, as to whether a presence of a malware attack is detected (operation 610). This detection in operation 610 is a provisional detection…”); and
upon detection by the DSM of the potential data security event (¶0068, “…The protection agent 300 uses additional evidence to determine whether a malware attack that has been provisionally detected can be confirmed as being underway, thereby making the provisional detection an official or corroborated detection. This corroborated detection may be considered a “confirmation,” with an acceptable degree of certainty, that the malware attack is underway…”), sending information to a client computing environment that causes a client-side data security event confirmation and response (CDSECR) system to inspect the one or more client files associated with the potential data security event to determine whether an actual data security event occurred and initiate a responsive action when the CDSECR determines an occurrence of an actual data security event (¶0016, “… When the protection agent detects (e.g., determines that the activity over time meets the threshold or other metric) that a malware attack is underway, an administrator (e.g., a storage administrator) or some other user is notified via, for example, an alert that is presented to the administrator or user via a user interface. The protection agent may also present options for data recovery to the administrator or user.”), (¶0080, “Information in any of the fields may be displayed to an administrator by, for example, the user interface 324, to assist the administrator in confirming whether a malware attack is underway and how to respond…”, wherein the administrator’s /user’s system that confirmed/corroborated the attack and responds copiously is interpreted as the claimed data security event confirmation and response (CDSECR)). See also ¶0083.

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.

The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.

Claims 4, 7-8, 17, and 20-21 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. PGPub. No. 20210334374 to Vasudeva et al. (hereinafter Vasudeva) in view of U.S. PGPub. No. 20230289443 to Sinha et al. (hereinafter Sinha).

Regarding claim 4, Vasudeva discloses the method of claim 1wherein each cloud file event record includes a file name, an event time, and an activity type (¶0081, “… the file event entry 500 may include one or more of the following fields: file name 510, path 512, inode number 514, size 516, extension 518, event time 520, event type 521, user identifier (UID) 522, group identifier (GID) 524, and network session identifier 526.”), (¶0072, “…The pattern analyzer 319 evaluates the file activity over a plurality of files stored in the volume 309 (e.g., by reference to the file event log 318) to determine whether the volume 309 has a malware attack underway…”),
However, Vasudeva does not explicitly disclose file event record includes a multipurpose Internet Mail Extension (MIME) type.
Sinha discloses the limitation of file event record includes a multipurpose Internet Mail Extension (MIME) type (¶0317, “…File type may generally refer to a format of the file, and an identification of the file type may be included in metadata associated with the file (e.g., a header of the file). In some examples, the file type may be indicated by the extension of the file. In some examples, the file type may be a Multipurpose Internet Mail Extension (MIME) type of the file.”).
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the method of Vasudeva in claim 1 to include a multipurpose Internet Mail Extension (MIME) type in the file event record as disclosed by Sinha and be motivated in doing so in order to validate the detection of the malicious activity in the file-Sinha ¶0319 in parts.

Regarding claim 17, Vasudeva discloses the system of claim 14 wherein each cloud file event record includes a file name, an event time, and an activity type (¶0081, “… the file event entry 500 may include one or more of the following fields: file name 510, path 512, inode number 514, size 516, extension 518, event time 520, event type 521, user identifier (UID) 522, group identifier (GID) 524, and network session identifier 526.”), (¶0072, “…The pattern analyzer 319 evaluates the file activity over a plurality of files stored in the volume 309 (e.g., by reference to the file event log 318) to determine whether the volume 309 has a malware attack underway…”),
However, Vasudeva does not explicitly disclose file event record includes a multipurpose Internet Mail Extension (MIME) type.
Sinha discloses the limitation of file event record includes a multipurpose Internet Mail Extension (MIME) type (¶0317, “…File type may generally refer to a format of the file, and an identification of the file type may be included in metadata associated with the file (e.g., a header of the file). In some examples, the file type may be indicated by the extension of the file. In some examples, the file type may be a Multipurpose Internet Mail Extension (MIME) type of the file.”).
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the method of Vasudeva in claim 1 to include a multipurpose Internet Mail Extension (MIME) type in the file event record as disclosed by Sinha and be motivated in doing so in order to validate the detection of the malicious activity in the file-Sinha ¶0319 in parts.

Regarding claim 7, Vasudeva discloses the method of claim 6 wherein every client file has a header, a specific fingerprint, or both a header and a specific fingerprint and once the client file is encrypted, the specific fingerprint changes or is deleted (¶0021-¶0022, “…the file system may be implemented through a file system layer that stores data of the storage objects in an on-disk format representation that is block-based (e.g., data is stored within 4 kilobyte blocks, and inodes are used to identify files and file attributes such as creation time, access permissions, size and block location, etc., wherein the inodes are the headers of files)…Whenever data is to be written to the storage device, a fingerprint of that data is calculated, and the data structure is looked up using the fingerprint to find duplicates (e.g., potentially duplicate data already stored within the storage device)”), (¶0065, “… For a particular file stored on the storage node 304, a malware attack may attempt to retrieve the file, encrypt data in that file, and write the encrypted data to a new encrypted file on the storage node 304. In many cases, the original file is deleted such that the original file is effectively “replaced” with the new encrypted file…”), wherein to detect an indication of a potential data security event involving encryption of the one or more client file associated with the client file event record (¶0087, “…Accordingly, data that is encrypted is considered as being encrypted due to malware. When the data in the file is determined to be encrypted, the file is flagged as being suspicious or, in other words, as potentially being part of a malware attack.”) further comprises at least one of:
However, Vasudeva does not explicitly disclose the following limitations:
A. determining if a previously recorded fingerprint of the client file has changed or has been deleted;
determining if the fingerprint correctly corresponds to contents of the client file; and
detecting a data security event if the fingerprint does not correctly correspond to the contents of the client file;
B. comparing an entropy score of the client file to an expected entropy score for a file type of the client file;
determining if the entropy score and expected entropy score match; and
detecting a data security event if the entropy score does not match the expected entropy score.
C. determining and storing an original entropy score of the client file;
detecting activity involving the client file;
determining a new entropy score of the client file after detecting the activity;
comparing the original entropy score of the client file to the new entropy score;
determining if the original entropy score and the new entropy score match; and
detecting a data security event if the original entropy score does not match the new expected entropy score.
Sinha discloses:
B. comparing an entropy score of the client file to an expected entropy score for a file type of the client file (Claim 7, “...wherein said detect one or more file server events comprises compare a file entropy measurement of a file of the distributed file server to a threshold file entropy measurement.”);
determining if the entropy score and expected entropy score match (¶0301, “event pattern analysis may be implemented by the AVM 1070 using a supervised machine learning algorithm, other machine learning technique and/or neural network and/or by similarity measurement and consideration of file entropy (e.g., a measure of the “randomness” of the data in a file—measured on a scale of 1 to 8, where typical text files will have a low value, and encrypted or compressed files will have a high measure). The machine learning technique may identify files that are or have been subject to a ransomware attack. In some examples, the similarity measurement and/or file entropy measurement may indicate that the file is or has been subject to a ransomware attack.”); and
detecting a data security event if the entropy score does not match the expected entropy
score (¶0314, “…For example, these may include the set of files that have been subjected to a particular pattern of file server events and/or have greater than a threshold level of entropy and/or have otherwise been identified by malicious activity detection methodologies described herein.”)
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the method of Vasudeva to include entropy comparison of file to detect attack as disclosed by Sinha and be motivated in doing so in order to validation of candidate files suspected of being affected by malicious activity-Sinha ¶0312 in parts.

Regarding claim 20, Vasudeva discloses the system of claim 19 wherein every client file has a header, a specific fingerprint, or both a header and a specific fingerprint and once the client file is encrypted, the specific fingerprint changes or is deleted (¶0021-¶0022, “…the file system may be implemented through a file system layer that stores data of the storage objects in an on-disk format representation that is block-based (e.g., data is stored within 4 kilobyte blocks, and inodes are used to identify files and file attributes such as creation time, access permissions, size and block location, etc., wherein the inodes are the headers of files)…Whenever data is to be written to the storage device, a fingerprint of that data is calculated, and the data structure is looked up using the fingerprint to find duplicates (e.g., potentially duplicate data already stored within the storage device)”), (¶0065, “… For a particular file stored on the storage node 304, a malware attack may attempt to retrieve the file, encrypt data in that file, and write the encrypted data to a new encrypted file on the storage node 304. In many cases, the original file is deleted such that the original file is effectively “replaced” with the new encrypted file…”), wherein to detect an indication of a potential data security event involving encryption of the one or more client file associated with the client file event record (¶0087, “…Accordingly, data that is encrypted is considered as being encrypted due to malware. When the data in the file is determined to be encrypted, the file is flagged as being suspicious or, in other words, as potentially being part of a malware attack.”) further comprises at least one of:
However, Vasudeva does not explicitly disclose the following limitations:
A. determining if a previously recorded fingerprint of the client file has changed or has been deleted;
determining if the fingerprint correctly corresponds to contents of the client file; and
detecting a data security event if the fingerprint does not correctly correspond to the contents of the client file;
B. comparing an entropy score of the client file to an expected entropy score for a file type of the client file;
determining if the entropy score and expected entropy score match; and
detecting a data security event if the entropy score does not match the expected entropy score.
C. determining and storing an original entropy score of the client file;
detecting activity involving the client file;
determining a new entropy score of the client file after detecting the activity;
comparing the original entropy score of the client file to the new entropy score;
determining if the original entropy score and the new entropy score match; and
detecting a data security event if the original entropy score does not match the new expected entropy score.
Sinha discloses:
B. comparing an entropy score of the client file to an expected entropy score for a file type of the client file (Claim 7, “...wherein said detect one or more file server events comprises compare a file entropy measurement of a file of the distributed file server to a threshold file entropy measurement.”);
determining if the entropy score and expected entropy score match (¶0301, “event pattern analysis may be implemented by the AVM 1070 using a supervised machine learning algorithm, other machine learning technique and/or neural network and/or by similarity measurement and consideration of file entropy (e.g., a measure of the “randomness” of the data in a file—measured on a scale of 1 to 8, where typical text files will have a low value, and encrypted or compressed files will have a high measure). The machine learning technique may identify files that are or have been subject to a ransomware attack. In some examples, the similarity measurement and/or file entropy measurement may indicate that the file is or has been subject to a ransomware attack.”); and
detecting a data security event if the entropy score does not match the expected entropy
score (¶0314, “…For example, these may include the set of files that have been subjected to a particular pattern of file server events and/or have greater than a threshold level of entropy and/or have otherwise been identified by malicious activity detection methodologies described herein.”)
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the method of Vasudeva to include entropy comparison of file to detect attack as disclosed by Sinha and be motivated in doing so in order to validation of candidate files suspected of being affected by malicious activity-Sinha ¶0312 in parts.

Regarding claim 8, Vasudeva in view of Sinha discloses the method of claim 7.
Vasudeva further discloses wherein to determine whether an actual data security event occurred comprises one or more of steps a-f:
b. a signature or file fingerprint indicating an encrypted file when the signature or file fingerprint is not expected to have encrypted content (¶0087, “…Accordingly, data that is encrypted is considered as being encrypted due to malware. When the data in the file is determined to be encrypted, the file is flagged as being suspicious or, in other words, as potentially being part of a malware attack.”);
d. at least one of the client files is an undetectable type of file (¶0069, “Recognizable file formats may include, for example, but are not limited to, compressed file formats (e.g., a zip file format, a gzip file format, etc.) and media file formats (e.g., a video file format, an image file format, etc.). In one or more examples, the protection agent 300 may consider the file 306 suspicious (or associated with a malware attack risk) in the event that both the data 308 is determined to be encrypted and the format checker 316 is unable to recognize the file format 315 of the file 306.”),
(¶0070, “…The corresponding entry is then added if the format checker 316 is unable to recognize the file format 315 of the file 306…”);
f. a user entity of the client node deviating from a predetermined normal file interaction behavior of the user entity, wherein the file interaction behavior of the user entity includes one or more of file read/writes, abnormal number of file deletions, abnormal number of reads of files not normally accessed by the user entity, files accessed, files deleted, and files renamed (¶0073, “…Irregular file activity may include, for example, accessing multiple files within a short period of time, where those files have no known correlation and are rarely accessed. In another example, the pattern analyzer 319 may look for an unusual amount of file deletion and file creation activity within a certain period of time as an indicator of a malware attack…”), (¶0071, “…the file event log 318 tracks when a file is created, deleted, renamed, truncated, or controlled in some other manner. This type of tracking of file activity allows the protection agent 300 to monitor for an irregular pattern or behavior that would be expected from a malware attack”), (¶0065, “For a particular file stored on the storage node 304, a malware attack may attempt to retrieve the file, encrypt data in that file, and write the encrypted data to a new encrypted file on the storage node 304. In many cases, the original file is deleted such that the original file is effectively “replaced” with the new encrypted file…”) and Sinha further discloses one of steps
A-C:
B. comparing an entropy score of the client file to an expected entropy score for a file type of the client file (Claim 7, “...wherein said detect one or more file server events comprises compare a file entropy measurement of a file of the distributed file server to a threshold file entropy measurement.”);
determining if the entropy score and expected entropy score match (¶0301, “event pattern analysis may be implemented by the AVM 1070 using a supervised machine learning algorithm, other machine learning technique and/or neural network and/or by similarity measurement and consideration of file entropy (e.g., a measure of the “randomness” of the data in a file—measured on a scale of 1 to 8, where typical text files will have a low value, and encrypted or compressed files will have a high measure). The machine learning technique may identify files that are or have been subject to a ransomware attack. In some examples, the similarity measurement and/or file entropy measurement may indicate that the file is or has been subject to a ransomware attack.”); and
detecting a data security event if the entropy score does not match the expected entropy
score (¶0314, “…For example, these may include the set of files that have been subjected to a particular pattern of file server events and/or have greater than a threshold level of entropy and/or have otherwise been identified by malicious activity detection methodologies described herein.”)
Thus, one of ordinary skill in the art would have found it obvious before the effective
filing date of applicant’s claimed invention to modify the method of Vasudeva and Sinha to include entropy comparison of file to detect attack as disclosed by Sinha and be motivated in doing so in order to validation of candidate files suspected of being affected by malicious activity-Sinha ¶0312 in parts.

Regarding claim 21, Vasudeva in view of Sinha discloses the system of claim 20.
Vasudeva further discloses wherein to determine whether an actual data security event occurred comprises one or more of steps a-f:
b. a signature or file fingerprint indicating an encrypted file when the signature or file fingerprint is not expected to have encrypted content (¶0087, “…Accordingly, data that is encrypted is considered as being encrypted due to malware. When the data in the file is determined to be encrypted, the file is flagged as being suspicious or, in other words, as potentially being part of a malware attack.”);
d. at least one of the client files is an undetectable type of file (¶0069, “Recognizable file formats may include, for example, but are not limited to, compressed file formats (e.g., a zip file format, a gzip file format, etc.) and media file formats (e.g., a video file format, an image file format, etc.). In one or more examples, the protection agent 300 may consider the file 306 suspicious (or associated with a malware attack risk) in the event that both the data 308 is determined to be encrypted and the format checker 316 is unable to recognize the file format 315 of the file 306.”),
(¶0070, “…The corresponding entry is then added if the format checker 316 is unable to recognize the file format 315 of the file 306…”);
f. a user entity of the client node deviating from a predetermined normal file interaction behavior of the user entity, wherein the file interaction behavior of the user entity includes one or more of file read/writes, abnormal number of file deletions, abnormal number of reads of files not normally accessed by the user entity, files accessed, files deleted, and files renamed (¶0073, “…Irregular file activity may include, for example, accessing multiple files within a short period of time, where those files have no known correlation and are rarely accessed. In another example, the pattern analyzer 319 may look for an unusual amount of file deletion and file creation activity within a certain period of time as an indicator of a malware attack…”), (¶0071, “…the file event log 318 tracks when a file is created, deleted, renamed, truncated, or controlled in some other manner. This type of tracking of file activity allows the protection agent 300 to monitor for an irregular pattern or behavior that would be expected from a malware attack…”), (¶0065, “For a particular file stored on the storage node 304, a malware attack may attempt to retrieve the file, encrypt data in that file, and write the encrypted data to a new encrypted file on the storage node 304. In many cases, the original file is deleted such that the original file is effectively “replaced” with the new encrypted file…”) and Sinha further discloses one of steps
A-C:
B. comparing an entropy score of the client file to an expected entropy score for a file type of the client file (Claim 7, “...wherein said detect one or more file server events comprises compare a file entropy measurement of a file of the distributed file server to a threshold file entropy measurement.”);
determining if the entropy score and expected entropy score match (¶0301, “event pattern analysis may be implemented by the AVM 1070 using a supervised machine learning algorithm, other machine learning technique and/or neural network and/or by similarity measurement and consideration of file entropy (e.g., a measure of the “randomness” of the data in a file—measured on a scale of 1 to 8, where typical text files will have a low value, and encrypted or compressed files will have a high measure). The machine learning technique may identify files that are or have been subject to a ransomware attack. In some examples, the similarity measurement and/or file entropy measurement may indicate that the file is or has been subject to a ransomware attack.”); and
detecting a data security event if the entropy score does not match the expected entropy
score (¶0314, “…For example, these may include the set of files that have been subjected to a particular pattern of file server events and/or have greater than a threshold level of entropy and/or have otherwise been identified by malicious activity detection methodologies described herein.”)
Thus, one of ordinary skill in the art would have found it obvious before the effective
filing date of applicant’s claimed invention to modify the method of Vasudeva and Sinha to include entropy comparison of file to detect attack as disclosed by Sinha and be motivated in doing so in order to validation of candidate files suspected of being affected by malicious activity-Sinha ¶0312 in parts.

Claims 9 and 22 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. PGPub. No. 20210334374 to Vasudeva et al. (hereinafter Vasudeva) in view of U.S. PGPub. No. 20180248896 to Challita et al. (hereinafter Challita).

Regarding claim 9, Vasudeva discloses the method of claim 6 wherein a user entity is one or more of an individual user of one or more client nodes, multiple users of one or more of the client nodes, and one or more users of multiple client nodes, the method further comprising for one or more of the user entities (¶0003, “…The victim may be an individual person, an organization, a business enterprise, or some other type of entity.”), (¶0039, “The distributed computing platform 102 may be a multi-tenant and service platform operated by an entity in order to provide multiple tenants with a set of business related applications, data storage, and functionality. These applications and functionality may include ones that a business uses to manage various aspects of its operations…”), (¶0036, “The distributed computing platform 102, such as a multi-tenant business data processing platform or cloud computing environment, may include multiple processing tiers, including the user interface tier 104, the application server tier 106, and a data storage tier 108…”):
However, Vasudeva even though discloses the protection agent may intercept write requests and observe file events over time to detect anomalous behavior in ¶0015-¶0016, does not explicitly disclose the following limitation:
building a file of file interaction behaviors of the user entity of the client node to determine a normal file interaction behavior for each entity over a period of time and
deriving the predetermined normal file interaction behavior of the user entity from the determined normal file interaction behavior for each user entity.
Challita discloses:
building a file of file interaction behaviors of the user entity of the client node to determine a normal file interaction behavior for each entity over a period of time (¶0040, “The component 22 determines a baseline for different files in different location, as to normal usage, to provide a baseline for benign, normal user activity. The system must learn to identify them to avoid taking action when these benign activities are undertaken. Through machine learning, the system determines normal use thresholds for file changes and stores these thresholds for future reference. The machine learning observes the normal processes of the machine, including behavior that results in large changes at one time to particular files, such as compressing or encrypting files within normal use of the computer, that weren't previously encrypted or representing user content…”); and
deriving the predetermined normal file interaction behavior of the user entity from the determined normal file interaction behavior for each user entity (¶0042, “…Rapid file activity generally means many file changes occur in a short duration of time. The threshold is determined by the machine learning observing normal usage for a period of time (1 day or 1 week) based on the fact of ransomware being unlikely to strike within that early learning period. The learning period may be based on the specification of the computer, rather than a learning period. Clustering monitoring works using two parameters: inter-cluster distance and critical cluster size. The time stamps of file changes made by a process are recorded and compared; if they are close together in time (less than inter-cluster distance), then they may be designated as part of the same cluster. If a cluster reaches the critical cluster size, determined by the pre-determined criteria resulting in optimal parameters, the process is designated as effecting rapid activity. The two parameters are determined by the machine-learning component to reduce the number of false positives.”).
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant claimed invention to modify the method of Vasudeva to include building a file of file interaction behaviors of the user entity of the client node to determine a normal file interaction behavior for each entity over a period of time as disclosed by Challita and be motivated in doing so in order to avoid taking an action by the system when the user behavior is normal and safe.

Regarding claim 22, Vasudeva discloses the system of claim 19 wherein a user entity is one or more of an individual user of one or more client nodes, multiple users of one or more of the client nodes, and one or more users of multiple client nodes, the method further comprising for one or more of the user entities (¶0003, “…The victim may be an individual person, an organization, a business enterprise, or some other type of entity.”), (¶0039, “The distributed computing platform 102 may be a multi-tenant and service platform operated by an entity in order to provide multiple tenants with a set of business related applications, data storage, and functionality. These applications and functionality may include ones that a business uses to manage various aspects of its operations…”), (¶0036, “The distributed computing platform 102, such as a multi-tenant business data processing platform or cloud computing environment, may include multiple processing tiers, including the user interface tier 104, the application server tier 106, and a data storage tier 108…”):
However, Vasudeva even though discloses the protection agent may intercept write requests and observe file events over time to detect anomalous behavior in ¶0015-¶0016, does not explicitly disclose the following limitation:
building a file of file interaction behaviors of the user entity of the client node to determine a normal file interaction behavior for each entity over a period of time and
deriving the predetermined normal file interaction behavior of the user entity from the determined normal file interaction behavior for each user entity.
Challita discloses:
building a file of file interaction behaviors of the user entity of the client node to determine a normal file interaction behavior for each entity over a period of time (¶0040, “The component 22 determines a baseline for different files in different location, as to normal usage, to provide a baseline for benign, normal user activity. The system must learn to identify them to avoid taking action when these benign activities are undertaken. Through machine learning, the system determines normal use thresholds for file changes and stores these thresholds for future reference. The machine learning observes the normal processes of the machine, including behavior that results in large changes at one time to particular files, such as compressing or encrypting files within normal use of the computer, that weren't previously encrypted or representing user content…”); and
deriving the predetermined normal file interaction behavior of the user entity from the determined normal file interaction behavior for each user entity (¶0042, “…Rapid file activity generally means many file changes occur in a short duration of time. The threshold is determined by the machine learning observing normal usage for a period of time (1 day or 1 week) based on the fact of ransomware being unlikely to strike within that early learning period. The learning period may be based on the specification of the computer, rather than a learning period. Clustering monitoring works using two parameters: inter-cluster distance and critical cluster size. The time stamps of file changes made by a process are recorded and compared; if they are close together in time (less than inter-cluster distance), then they may be designated as part of the same cluster. If a cluster reaches the critical cluster size, determined by the pre-determined criteria resulting in optimal parameters, the process is designated as effecting rapid activity. The two parameters are determined by the machine-learning component to reduce the number of false positives.”).
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant claimed invention to modify the method of Vasudeva to include building a file of file interaction behaviors of the user entity of the client node to determine a normal file interaction behavior for each entity over a period of time as disclosed by Challita and be motivated in doing so in order to avoid taking an action by the system when the user behavior is normal and safe.

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 MUDASIRU K OLAEGBE whose telephone number is [phone]. The examiner can normally be reached MON-FRI. 7.30AM-5.30PM.
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 5712723739. 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.

/MUDASIRU K OLAEGBE/Examiner, Art Unit 2495

/FARID HOMAYOUNMEHR/Supervisory Patent Examiner, Art Unit 2495

Prosecution Timeline

• Sep 25, 2023: Application Filed
• Oct 06, 2025: Non-Final Rejection mailed — §102, §103, §112
• Apr 06, 2026: Response Filed
• May 13, 2026: Final Rejection mailed — §102, §103, §112 (current)