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 .
Response to Arguments
In the remarks filed on 02/12/2026. The applicant amended claims 1,9 and 17 are amended. No claims were added.
With respect to claim objections:
Applicant’ claim amendments and remarks filed on 02/12/2026 have been fully considered and overcame the claim objections as presented in the non-final office action filed 11/12/2025. Therefore, objections have been withdrawn.
With respect to 35 U.S.C. §103 rejections:
Applicant's arguments filed on 02/12/2026 have been received and entered.
Applicant's arguments with respect to the newly amended independent claims, see Applicant Arguments 11-13, with respect to the rejection (s) of independent claims 1,9 and 17 have been fully considered.
Applicant argues that Saad (US 20200099699 A1) in view of Afek (US 20120243551 A1) in further view of Penton (US 20140115703 A1) fails to disclose compression performed as part of a designated file transfer protocol connection layer (i.e., SMB, FTP, or SFTP) therefore fail to teach the limitations of amended claim 1. Applicant further asserts that cited references do not disclose user side compression and system side decompression performed within the same file transfer protocol. Examiner understand the applicant’s perspective; however, the argument are not persuasive. Saad discloses receiving compressed data, determining a compression or processing ration based on data before and after compression, and identifying potential ransomware activity based on changes in that ratio, [0028, fig 3] Saad further teaches initiating remedial actions upon detecting a potential ransomware conditions. Thus, Saad teaches the core concept of detecting ransomware based on compression characteristics of transmitted data. Afek further discloses compressing data streams transmitted across a network protocol using compression algorithms (e.g., GZIP, Huffman decoding) and decompressing the received data to construct the transmitted stream, see [0003, 0009, 0025,0044]. Afek further explains that compressed packet streams correspond to a network session or TCP connection. Accordingly, performing compression at a transmitting system and decompression at receiving system within a network protocol stack is well known in the art.
Applicant’s argument the cited references do not explicitly disclose compression performed specifically within a designated file transfer protocol such as SMB, FTP, or SFTP, the argument is not persuasive. Since, establishing protocol level compression within network session are well known techniques, it is obvious to POSITA to understand that such compression technique are applicable across various network communication protocols, including file transfer protocols. Nevertheless, examiner adds new reference that explicitly teaches compression and decompression performed within a file transfer protocol connection. Thus, The combination of Saad, Afek, Penton and added new reference teaches the amended limitation claim 1.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 6-9, and 14-17 are rejected under 35 U.S.C. 103 as being unpatentable over Saad (US 20200099699 A1) in view of Afek (US 20120243551 A1) in further view of Agarwal (US 20110277026 A1) in further view of Penton (US 20140115703 A1).
Regarding claim 1, Saad teaches a method, comprising:
receiving compressed written data in a processor-based ransomware detection system, wherein the written data is compressed as part of a transmission process, the transmission process including (i) user device side compression performed in conjunction with transmission of the compressed written data from a user device side to a system side, by executing a first set of one or more protocol instructions of a designated file transfer protocol to perform connection level compression in a protocol layer and (ii) system side decompression performed in conjunction with reception of the compressed written data in the processor-based ransomware detection system (Saad, Fig 2, The data transferred from the replication virtual appliance (i.e., the user side) 26 via the network 16 to the remote disaster recovery site 14 may be received by another replication virtual appliance 30 of the second computer system at the remote recovery site (i.e., the server side). [0019] , the replication virtual appliance 26 may also perform.. compress the deduplicated data to reduce transmission bandwidth to the remote recovery site and storage requirements at the remote storage system, [0020] the remote replication virtual appliance 30 at the remote recovery site receives the data from the local replication virtual appliance 26 of the local production site 12. ..it may perform the reverse decompression function on the compressed data before it is written to disks 34, [0022]) [ Examiner interprets that replication virtual appliance (i.e., the user side) 26 compressing the deduplicated data and transmitting to remote replication virtual appliance 30 (i.e., the server side) and replication virtual appliance 30 (i.e., the server side) decompressing the compressed deduplicated data before writing it to the disks 34 as limitation above].
determining, in the processor-based ransomware detection system, a compression ratio of the compressed written data in a time window of a predetermined time length, wherein the compression ratio is a ratio of the data amount of the written data before being compressed, as determined by decompressing the received compressed written data in the processor-based ransomware detection system, to a data amount of the written data after being compressed, as determined from the received compressed written data (Saad, FIG. 3, The detection process of FIG. 3 may begin at 50 by selecting a sliding time window having a predetermined time span, T, corresponding to a desired number, N, blocks of data to be analyzed. The time span, T, of the window, and the number, N, of data blocks analyzed, may be selected based upon the type of data. At 52, a processing module (either 40 or 42 depending upon whether the process is deduplication or compression) may receive N blocks of unprocessed data from the sliding window, and process the received data at 54, e.g., compress the data (i.e., received compressed data). At 56, the monitor (44 or 46 as appropriate) connected to the module performing the processing may determine the processing ratio of the data processed by the module (i.e., received compressed data) as the ratio, r, of (Data In)/(Data Out). The processing ratio will be …the compression ratio if the processing was compression. The higher the ratio, the more the data was compressed, [0028]) [ Examiner interprets that system monitoring the data such as data in (i.e., before compression) and data out (i.e., the after compression) using a sliding time window having a predetermined time span and processing the compression ratio of data within the predetermined time length as limitation above].
determining, in the processor-based ransomware detection system and based on the compression ratio, a user device side connection associated with the written data at least according to determining that the compression ratio is less than a threshold compression ratio, by comparing the compression ratio to the threshold compression ratio and identifying the corresponding user device side connection at least in part responsive to the compression ratio being less than the threshold compression ratio (Saad, At 58, the current processing ratio as determined at 56 may be compared to one or more previously determined processing ratios for the same data stream to detect significant changes in the ratio. At 60 any change in current processing ratio from the previous ratios that is more than a predetermined threshold amount may be determined to significant. For instance, if the compression ratio for a data stream has previously been measured to be between 1.5-2.0, and the ratio suddenly drops to about 1.0, indicating little or no compression, that may be an indication of encryption and possible ransomware because encrypted data cannot be compressed as much as unencrypted data. Thus, if the change in ratio is more than the predetermined threshold, this is an indication of a possible ransomware, [0028]) [ Examiner interprets that comparing the calculated processing ratio (i.e., the compression ratio) to predetermined threshold, identifying the drop in compression ratio than predetermined threshold and indicating the drop as potential ransomware attack as limitation above].
determining, in the processor-based ransomware detection system, data received from the user device side connection as being part of a network attack (Saad, At 58, the current processing ratio as determined at 56 may be compared to one or more previously determined processing ratios for the same data stream to detect significant changes in the ratio. At 60 any change in current processing ratio from the previous ratios that is more than a predetermined threshold amount may be determined to significant. For instance, if the compression ratio for a data stream has previously been measured to be between 1.5-2.0, and the ratio suddenly drops to about 1.0, indicating little or no compression, that may be an indication of encryption and possible ransomware because encrypted data cannot be compressed as much as unencrypted data. Thus, if the change in ratio is more than the predetermined threshold, this is an indication of a possible ransomware, [0028] an additional process 76 may be included that tracks Shannon entropy to determine a measure of order in the data to detect data encryption, [0030]) [ Examiner interprets that comparing the calculated processing ratio (i.e., the compression ratio) to predetermined threshold, checking if there is a the drop in compression ratio than predetermined threshold and indicating the drop as potential ransomware attack (i.e., the network) as limitation above]; and
initiating one or more actions in the processor-based ransomware detection system to mitigate the network attack, wherein the one or more actions initiated to mitigate the network attack comprise blocking the user device side connection (Saad, Next, at 82, upon detecting the possibility of ransomware, the process may determine whether there is a defined response applicable to the remote site. If so, at 84 the process may perform the defined response. The defined response may be, for example, to automatically stop writing changes to the data at the remote site. In this case, the virtual replication appliance may continue to receive data changes and write them to the log journal, but will not apply them to remote storage. This will contain the spread of the ransomware encryption within the remote copy of the data, and allow a faster recovery to an earlier point in time and faster restoration of normal operations, [0031] The response may comprise, for example, stopping writing changes to the local site and stopping acknowledgment (“ACK”) writes to the hosts, [0032]) [Examiner interprets that initiating alert to user and determinizing defined response such as automatically stop writing changes to the data at the remote site, stopping acknowledgment (“ACK”) writes to the hosts etc., in response to possible indication of ransomware attack as limitation above].
Saad does not explicitly teach:
user device side compression performed in conjunction with transmission of the compressed written data from a user device side to a system side, by executing a first set of one or more protocol instructions of a designated file transfer protocol, the designated file transfer protocol comprising one of SMB, FTP and SFTP, to perform connection level compression, on a per-connection basis for each of a plurality of distinct user side connections from the user device side to the system side, in a protocol layer and (ii) system side decompression performed in conjunction with reception of the compressed written data in the processor-based ransomware detection system, by executing a second set of one or more protocol instructions of the designated file transfer protocol to perform connection level decompression in the protocol layer, wherein the connection level compression and the connection level decompression are part of the same designated file transfer protocol comprising one of SMB, FTP and SFTP, and are performed separately on the per-connection basis for each of the plurality of distinct user side connections from the user device side to the system side; executing, on at least one processor of the processor-based ransomware detection system, the second set of the one or more protocol instructions of the designated file transfer protocol, to decompress the received compressed written data to determine a data amount of the written data before being compressed; performing, in the processor-based ransomware detection system, a file integrity check on one or more files associated with the user device side connection; determining, in the processor-based ransomware detection system, data received from the user device side connection as being part of a network attack according to determining that the one or more files associated with the user device side connection cannot pass the file integrity check;
However, Afek teaches:
User side compression by executing a first set of one or more protocol instructions of a designated file transfer protocol to perform connection level compression in a protocol layer and system side decompression by executing a second set of one or more protocol instructions of the designated file transfer protocol to perform connection level decompression in the protocol layer, wherein the connection level compression and the connection level decompression are part of the same designated file transfer protocol (Afek, methods for data compression are known in the art. Many Web servers, for example, use the GZIP algorithm to compress Hypertext Transfer Protocol (HTTP) symbol streams that they transmit, [0003] the data in the incoming stream are compressed in accordance with a GZIP algorithm, and the data packets are transmitted using a Hypertext Transfer Protocol (HTTP). Typically, receiving the incoming stream includes applying Huffman decoding to the data packets in order to recover the incoming stream, which includes a symbol stream that is compressed in accordance with a LZ77 algorithm, [0009] Upon receiving packets from network 22 containing compressed HTTP data, a demultiplexer 23 separates the incoming packets into multiple streams, and the data in each stream are directed to a Huffman decoder 25 in apparatus 20, which removes the HTTP header and stores the Huffman dictionaries for the session in question. Decoder 25 uses the dictionaries to convert the stream of Huffman codes into the corresponding symbols of the compressed LZ77 data stream, [0024] A "stream" of packets in this context may be identified, for example, as a sequence of packets belonging to the same TCP connection or HTTP session. The data are stored in buffers 26 in compressed form, and are periodically decompressed and then recompressed by processing circuitry, referred to as packing logic 28, [0025]) [Examiner interprets that system compressing at the sender within HTTP (i.e., the designated file transfer protocol) and decompression at the receiver within that same protocol stack (i.e., same TCP/HTTP session) as limitation above]; and
executing, on at least one processor of the processor-based ransomware detection system, the second set of the one or more protocol instructions of the designated file transfer protocol, to decompress the received compressed written data to determine a data amount of the written data before being compressed (Afek, The first part performs Huffman decoding of the incoming packet in order to determine its uncompressed size, which in turn determines the new boundary of the 32 KB buffer, [0044]) [Examiner interprets that system using Huffman decoding (i.e., decompression) to compute the uncompressed size as limitation above].
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Saad to include a concept of User side compression by executing a first set of one or more protocol instructions of a designated file transfer protocol to perform connection level compression in a protocol layer and system side decompression by executing a second set of one or more protocol instructions of the designated file transfer protocol to perform connection level decompression in the protocol layer, wherein the connection level compression and the connection level decompression are part of the same designated file transfer protocol; executing, on at least one processor of the processor-based ransomware detection system, the second set of the one or more protocol instructions of the designated file transfer protocol, to decompress the received compressed written data to determine a data amount of the written data before being compressed as taught by Afek for the purpose of compressing at the sender within HTTP (i.e., the designated file transfer protocol) and decompression at the receiver within that same protocol stack (i.e., same TCP/HTTP session) [Afek:0009, 0025] and performing Huffman decoding of the incoming packet in order to determine its uncompressed size [Afek:0044].
Saad and Afek does not explicitly teach:
executing a first set of one or more protocol instructions of a designated file transfer protocol, the designated file transfer protocol comprising one of SMB, FTP and SFTP, to perform connection level compression, on a per-connection basis for each of a plurality of distinct user side connections from the user device side to the system side, in a protocol layer and wherein the connection level compression and the connection level decompression are part of the same designated file transfer protocol comprising one of SMB, FTP and SFTP, and are performed separately on the per-connection basis for each of the plurality of distinct user side connections from the user device side to the system side; performing, in the processor-based ransomware detection system, a file integrity check on one or more files associated with the user device side connection; determining, in the processor-based ransomware detection system, data received from the user device side connection as being part of a network attack according to determining that the one or more files associated with the user device side connection cannot pass the file integrity check; initiating one or more actions in the processor-based ransomware detection system to mitigate the network attack, wherein the one or more actions initiated to mitigate the network attack comprise blocking the user device side connection;
However, Agarwal teaches:
executing a first set of one or more protocol instructions of a designated file transfer protocol, the designated file transfer protocol comprising one of SMB, FTP and SFTP, to perform connection level compression, on a per-connection basis for each of a plurality of distinct user side connections from the user device side to the system side, in a protocol layer and wherein the connection level compression and the connection level decompression are part of the same designated file transfer protocol comprising one of SMB, FTP and SFTP, and are performed separately on the per-connection basis for each of the plurality of distinct user side connections from the user device side to the system side (Agarwal, the network environment comprises one or more clients 102a-102n (also generally referred to as local machine(s) 102, or client(s) 102) in communication with one or more servers 106a-106n (also generally referred to as server(s) 106, or remote machine(s) 106) via one or more networks 104, 104' (generally referred to as network 104), [0060] multi-protocol compression engine 238 compresses bi-directionally between clients 102a-102n and servers 106a-106n any TCP/IP based protocol, including Messaging Application Programming Interface (MAPI) (email), File Transfer Protocol (FTP), HyperText Transfer Protocol (HTTP), Common Internet File System (CIFS) protocol (file transfer)…, [0123] the appliance 200 provides one or more of the following acceleration techniques 288 to communications between the client 102 and server 106: 1) compression; 2) decompression; 3) Transmission Control Protocol pooling; 4) Transmission Control Protocol multiplexing; 5) Transmission Control Protocol buffering; and 6) caching. In one embodiment, the appliance 200 relieves servers 106 of much of the processing load caused by repeatedly opening and closing transport layers connections to clients 102 by opening one or more transport layer connections with each server 106 and maintaining these connections to allow repeated data accesses by clients, [0137] the vServer 275 establishes the transport layer connection to an internet protocol address and port of a server 270 running on the server 106, [0134] any TCP/IP based protocol may be used, including Messaging Application Programming Interface (MAPI) (email), File Transfer Protocol (FTP), HyperText Transfer Protocol (HTTP), Common Internet File System (CIFS) protocol (file transfer),.. [0147]) [Examiner interprets that system performing compression and decompression as part of that protocol’s communication session using FTP, CIFS (SMB), system managing transport layer connection between client and server, compression of protocol traffic occurs within those connections, containing multiple clients and each establishing transport layer connections to the appliance/server (i.e., separate connection) as limitation above Examiner note: FTP and SMB are session based protocols operating over TCP connections, therefore compression applies to a protocol traffic operates within those individual sessions which corresponds to the claimed per
connection compression].
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Saad, and Afek to include a concept of executing a first set of one or more protocol instructions of a designated file transfer protocol, the designated file transfer protocol comprising one of SMB, FTP and SFTP, to perform connection level compression, on a per-connection basis for each of a plurality of distinct user side connections from the user device side to the system side, in a protocol layer and wherein the connection level compression and the connection level decompression are part of the same designated file transfer protocol comprising one of SMB, FTP and SFTP, and are performed separately on the per-connection basis for each of the plurality of distinct user side connections from the user device side to the system side as taught by Agarwal for the purpose of compressing bi-directionally between clients 102a-102n and servers 106a-106n any TCP/IP based protocol, including Messaging Application Programming Interface (MAPI) (email), File Transfer Protocol (FTP), HyperText Transfer Protocol (HTTP), Common Internet File System (CIFS) protocol (file transfer) by using multi-protocol compression engine 238 [Agarwal: 0123].
Saad, Afek, and Agarwal does not explicitly teach:
performing, in the processor-based ransomware detection system, a file integrity check on one or more files associated with the user device side connection; determining, in the processor-based ransomware detection system, data received from the user device side connection as being part of a network attack according to determining that the one or more files associated with the user device side connection cannot pass the file integrity check; initiating one or more actions in the processor-based ransomware detection system to mitigate the network attack, wherein the one or more actions initiated to mitigate the network attack comprise blocking the user device side connection;
However, Penton teaches:
performing, in the processor-based ransomware detection system, a file integrity check on one or more files associated with the user device side connection (Penton, The detection techniques facility 130 may include monitoring the enterprise facility 102 network or end-point devices, such as by monitoring streaming data through the gateway, across the network, through routers and hubs, Detection techniques, such as streaming file management, may provide the capability of checking files received at the network, gateway facility, client facility 144, and the like. This may provide the capability of not allowing a streaming file or portions of the streaming file containing malicious code from entering the client facility 144, gateway facility, or network…the streaming file may be broken into blocks of information, and a plurality of virus identities may be used to check each of the blocks of information for malicious code, any blocks that are not determined to be clear of malicious code may not be delivered to the client facility 144, gateway facility, or network, [0039]) [Examiner interprets that system performing file scanning/checking on files by receiving at the network , gateway or client facility, gateway facility (i.e., as files traverses between client (user device side connection) and the network as limitation above];
determining, in the processor-based ransomware detection system, data received from the user device side connection as being part of a network attack according to determining that the one or more files associated with the user device side connection cannot pass the file integrity check (Penton, The detection techniques facility 130 may include monitoring the enterprise facility 102 network or end-point devices, such as by monitoring streaming data through the gateway, across the network, through routers and hubs, Detection techniques, such as streaming file management, may provide the capability of checking files received at the network, gateway facility, client facility 144, and the like. This may provide the capability of not allowing a streaming file or portions of the streaming file containing malicious code from entering the client facility 144, gateway facility, or network…the streaming file may be broken into blocks of information, and a plurality of virus identities may be used to check each of the blocks of information for malicious code, any blocks that are not determined to be clear of malicious code (i.e. not passing file integrity check hence “the network attack”) may not be delivered to the client facility 144, gateway facility, or network, [0039] When a threat or policy violation (i.e. the network attack) is detected by the threat management facility 100, the threat management facility 100 may provide for a remedial action facility 128, [0038]) [Examiner interprets that system determining that file “is not clear of malicious code” and based on the determination, system recognizing the data is the part of attack and immediately preventing further transmission (i.e., blocking the delivery of the file) as limitation above];
initiating one or more actions in the processor-based ransomware detection system to mitigate the network attack, wherein the one or more actions initiated to mitigate the network attack comprise blocking the user device side connection (Penton, the streaming file may be broken into blocks of information, and a plurality of virus identities may be used to check each of the blocks of information for malicious code, any blocks that are not determined to be clear of malicious code (i.e. not passing file integrity check hence “the network attack”) may not be delivered to the client facility 144, gateway facility, or network, [0039] When a threat or policy violation (i.e. the network attack) is detected by the threat management facility 100, the threat management facility 100 may provide for a remedial action facility 128, Remedial action may take a plurality of forms, such as terminating or modifying an ongoing process or interaction, the remedial action facility may interact with the received information and may perform various actions on a client requesting access to a denied network location. The action may be one or more of continuing to block all requests to a denied network location, a malicious code scan on the application, a malicious code scan on the client facility 144, quarantine of the application, terminating the application, isolation of the application, isolation of the client facility 144 to a location within the network that restricts network access, blocking a network access port from a client facility 144, reporting the application to an administration facility 134, [0038] the end-point computer security facility 152 may perform specific actions to remediate possible threat incursions or policy violations during or after the unprotected connection, [0052]) [Examiner interprets that system recognizing the data is the part of attack and immediately initiating remedial actions such as preventing further transmission (i.e., blocking the delivery of the file), blocking ports or terminating connectivity to stop attack propagation as limitation above];
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Saad, Afek, and Agarwal to include a concept of performing, in the processor-based ransomware detection system, a file integrity check on one or more files associated with the user device side connection; determining, in the processor-based ransomware detection system, data received from the user device side connection as being part of a network attack according to determining that the one or more files associated with the user device side connection cannot pass the file integrity check as taught by Penton for the purpose of monitoring streaming data through the gateway, across the network, through routers and hubs for detecting streaming file or portions of the streaming file containing malicious code from entering the client facility 144, gateway facility, or network and providing remedial actions such as terminating or modifying an ongoing process or interaction etc., [Penton:0038,0039].
Regarding claim 6, Saad, Afek, Agarwal, and Penton teaches the method according to claim 1, further comprising: determining the threshold compression ratio based on a compression ratio of earlier historical data written in multiple time windows with the predetermined time length (Saad, FIG. 3, The detection process of FIG. 3 may begin at 50 by selecting a sliding time window having a predetermined time span, T, corresponding to a desired number, N, blocks of data to be analyzed. The time span, T, of the window, and the number, N, of data blocks analyzed, may be selected based upon the type of data. At 52, a processing module (either 40 or 42 depending upon whether the process is deduplication or compression) may receive N blocks of unprocessed data from the sliding window, and process the received data at 54, e.g., compress the data (i.e., received compressed data). At 56, the monitor (44 or 46 as appropriate) connected to the module performing the processing may determine the processing ratio of the data processed by the module (i.e., received compressed data) as the ratio, r, of (Data In)/(Data Out). The processing ratio will be …the compression ratio if the processing was compression. The higher the ratio, the more the data was compressed, At 58, the current processing ratio as determined at 56 may be compared to one or more previously determined processing ratios for the same data stream to detect significant changes in the ratio. At 60 any change in current processing ratio from the previous ratios that is more than a predetermined threshold amount may be determined to significant. For instance, if the compression ratio for a data stream has previously been measured to be between 1.5-2.0, and the ratio suddenly drops to about 1.0, indicating little or no compression, that may be an indication of encryption and possible ransomware because encrypted data cannot be compressed as much as unencrypted data. Thus, if the change in ratio is more than the predetermined threshold, this is an indication of a possible ransomware, [0028] [Examiner interprets that examining the current processing ratio (i.e., the compression ratio) by comparing its deviation with respect to the processing ratio of the data being processed to previous ratios of the same data stream based on predetermined threshold over multiple earlier time windows as determining the threshold compression ratio based on a compression ratio of earlier historical data written in multiple time windows with the predetermined time length].
Regarding claim 7, Saad, Afek, Agarwal, and Penton teaches the method according to claim 1, wherein the one or more actions initiated to mitigate the network attack further comprise: saving a historical snapshot associated with the user side connection and/or creating a snapshot associated with the user side connection (Saad, Next, at 82, upon detecting the possibility of ransomware, the process may determine whether there is a defined response applicable to the remote site. If so, at 84 the process may perform the defined response. The defined response may be, for example, to automatically stop writing changes to the data at the remote site. In this case, the virtual replication appliance may continue to receive data changes and write them to the log journal, but will not apply them to remote storage. This will contain the spread of the ransomware encryption within the remote copy of the data, and allow a faster recovery to an earlier point in time and faster restoration of normal operations, [0031] The response may comprise, for example, stopping writing changes to the local site and stopping acknowledgment (“ACK”) writes to the hosts, at 90, the system may enter a recovery phase. In the recovery phase, a user may take steps to remove the ransomware and to recover the system to an earlier point in time, as by replicating the clean system data using the remote data storage and the journal logs, [0032]) [Examiner interprets that upon detecting ransomware detection, going on recovery phase by recovering the system to an earlier point in time, as by replicating the clean system data using the remote data storage and the journal logs (i.e., the historical snapshot) as saving a historical snapshot associated with the user side connection or creating a snapshot associated with the user side connection].
Regarding claim 8, Saad, Afek, Agarwal, and Penton teaches the method according to claim 1, wherein the network attack is a ransomware attack (Saad, detecting a ransomware attack is to detect abnormal I/O activity and to alert the user as to a potential attack, [0004] Next, at 82, upon detecting the possibility of ransomware, the process may determine whether there is a defined response applicable to the remote site. If so, at 84 the process may perform the defined response, [0031])
Regarding claim 9, Claim 9 recite commensurate subject matter as claim 1. Therefore, they are rejected for the same reasons. Except the additional elements.
Saad further teaches:
An electronic device (Saad, local production site computer system 12, a second remote disaster recovery site computer system 14, [0014]) , comprising:
at least one processor and memory coupled to the at least one processor and having instructions stored therein, wherein the instructions, when executed by the at least one processor, cause the electronic device to perform actions (Saad, claim 11) comprising:
Regarding claim 17, Claim 17 recite commensurate subject matter as claim 1. Therefore, they are rejected for the same reasons. Except the additional elements.
Saad further teaches
A computer program product tangibly stored on a non-transitory computer-readable medium and comprising machine-executable instructions, wherein the machine-executable instructions, when executed by a machine, cause the machine to perform actions (Saad, claim 11) comprising:
Regarding claim 14-16, Claim 14-16 recite commensurate subject matter as claim 6-8. Therefore, they are rejected for the same reasons.
Claims 2-4, 10-12 and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over Saad (US 20200099699 A1) in view of Afek (US 20120243551 A1) in further view of Agarwal (US 20110277026 A1) in further view of Penton (US 20140115703 A1) in further view of Sternfeld (US 20230023584 A1).
Regarding Claim 2, Saad, Afek, Agarwal, and Penton teaches the method according to claim 1, wherein determining the user device side connection associated with the written data comprises: in response to the compression ratio being less than the threshold compression ratio, determining a number of times of abnormal operations in the time window (Saad, FIG. 3, At 58, the current processing ratio as determined at 56 may be compared to one or more previously determined processing ratios for the same data stream to detect significant changes in the ratio. At 60 any change in current processing ratio from the previous ratios that is more than a predetermined threshold amount may be determined to significant. For instance, if the compression ratio for a data stream has previously been measured to be between 1.5-2.0, and the ratio suddenly drops to about 1.0, indicating little or no compression, that may be an indication of encryption and possible ransomware because encrypted data cannot be compressed as much as unencrypted data. Thus, if the change in ratio is more than the predetermined threshold, this is an indication of a possible ransomware, [0028]) [Examiner interprets that calculating processing ratio (i.e., the compression ratio) for data and comparing it to predetermined threshold, identifying the drop in compression ratio than predetermined threshold and indicating the drop as potential ransomware attack as determining the user side connection associated with the written data comprises: in response to the compression ratio being less than the threshold compression ratio]
Saad, Afek, Agarwal, and Penton does not explicitly teach:
determining a number of times of abnormal operations in the time window; and in response to the number of times being greater than a threshold number of times, determining the user device side connection associated with the written data.
However, Sternfeld teaches:
determining a number of times of abnormal operations in the time window; and in response to the number of times being greater than a threshold number of times, determining the user device side connection associated with the written data (Sternfeld, detecting the at least one additional event for the file can include detecting the at least one additional event for the file within a pre-defined time window, [0008] Fig 4, At block 402, ransomware detection module 116, once a file is detected as being encrypted, identifies an entity associated with the file encryption (i.e., user side connection associated with the written data). The entity is a single process, multiple processes, or individual injected threads within a process. At block 404, ransomware detection module 116 increments an encryption count (i.e., the number of times of abnormal operations) associated with the entity (i.e., a number of encrypted files associated with the entity). At block 406, ransomware detection module 116 compares statistics of the entity to various thresholds. For example, if, at any point, an entity has encrypted a number of files above a certain threshold (referred to herein as a ransomware threshold) within a predefined time period (e.g., one minute), and the number of different file types encrypted is also above a second threshold (referred to herein as a file type threshold), then, at block 408, ransomware detection module 116 determines that the entity is exhibiting ransomware-like behavior, [0058]) [Examiner interprets that tracking abnormal file events (i.e. encryptions, deletions) and calculating counts for those events within predefined window as determining the number of times of abnormal operations in response to the number of times being greater than a threshold number of times, determining the user side connection associated with the written data].
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Saad, Afek, Agarwal, and Penton to include a concept of determining a number of times of abnormal operations in the time window; and in response to the number of times being greater than a threshold number of times, determining the user device side connection associated with the written data as taught by Sternfeld for the purpose of determining whether an entity is determining ransomware-like behavior, such as the rarity of files that have been changed, whether the files which have been changed are changed often or not, whether the total volume of space occupied by files which have been changed is large, whether the total changes (e.g., as measured by entropy) across the changed files is large, etc. [Sternfeld:0058].
Regarding claim 3, Sternfeld further teaches the method according to claim 2, wherein determining the number of times of the abnormal operations in the time window comprises:
determining a first count of file deletion operations after a file reading operation in the time window (Sternfeld, file modification detection module 108 tracks the file's events and generates “after” statistical snapshots for a predefined time window, which can be on the order of a few seconds [0048] In the case of a delete event, when a tracked file is deleted or opened for deletion, file modification detection module 108 tags the file as deleted [0053] some ransomware use “truncate to zero” instead of delete. Therefore, file modification detection module 108 treats truncate events the same as delete events (i.e., marking the file as deleted) [0055]) [Examiner interprets that detecting and counting deletion events in relation to file reads events within a time window as determining a first count of file deletion operations after a file reading operation in the time window];
determining a second count of file encryption operations after a file creation operation in the time window (Sternfeld, there are several ways to encrypt a file in user-mode such as the original file is deleted and a replacement file is created instead which contains the encrypted data [0024]. Ransomware detection module 116 analyzes the detected file encryptions to detect ransomware-like behavior which involves determining that a specific process is responsible for a certain number of file encryptions within a specified time period [0043] file modification detection module 108 tracks the file's events and generates “after” statistical snapshots for a predefined time window, which can be on the order of a few seconds [0048]) [Examiner interprets that tracking encryption events after file creation operations (e.g., replacing deleted files) with in a predefined time window as determining a second count of file encryption operations after a file creation operation in the time window];
determining the number of times of the abnormal operations based on at least one of the first count and the second count (Sternfeld, Fig 4, At block 404, ransomware detection module 116 increments an encryption count associated with the entity (i.e., a number of encrypted files associated with the entity). At block 406, ransomware detection module 116 compares statistics of the entity to various thresholds. For example, if, at any point, an entity has encrypted a number of files above a certain threshold (referred to herein as a ransomware threshold) within a predefined time period (e.g., one minute), then, at block 408, ransomware detection module 116 determines that the entity is exhibiting ransomware-like behavior [0058]) [Examiner interprets that tracking encryption counts to determine ransomware-like behavior (i.e., encryptions higher than thresholds) within predefined window as determining the number of times of the abnormal operations based on at least one of the first count and the second count].
Regarding claim 4, Saad, Afek, Agarwal, and Penton teaches the method according to claim 1, further comprising:
Saad, Afek, Agarwal, and Penton does not explicitly teach:
determining an additional compression ratio of read data in the time window, wherein the additional compression ratio is a ratio of a data amount of the read data before being compressed to a data amount of the read data after being compressed
However, Sternfeld teaches:
determining an additional compression ratio of read data in the time window, wherein the additional compression ratio is a ratio of a data amount of the read data before being compressed to a data amount of the read data after being compressed (Sternfeld, Fig 2, At block 204, file modification detection module 108, via the kernel driver, detects a plurality of file events from the file system such as open events, read events, and close/finish events. After detection of the file events, file modification module 108 sends the file events to a user-mode portion of the module for analysis. At block 206, file modification detection module 108 generates statistical snapshots for each of the plurality of file events detected. For example, file modification detection module 108 may generate a before snapshot and an after snapshot [0032] At block 208, encryption detection module 114 analyzes the statistical snapshots for each detected file event in order to determine whether that respective file event involves encryption of a file. Encryption detection module 114 utilize a variety of techniques (i.e., an assembly of statistical features) to determine whether or not a file has been encrypted. For example, encryption detection module 114 can use one or more (or all) of the techniques such as Shannon entropy spikes, aggregated printable strings ratio drops to analyze each statistical snapshot, [0033] For aggregated printable strings ratio drops, the lengths of all printable strings in the data can be summed and divided by the total size. Based on this calculation, significant drops in printable strength lengths can be detected. A printable string is defined as a sequence of consecutive printable characters of a fixed length. In some embodiments, the length can be eight characters. In some embodiments, at least one of ASCII (American Standard Code for Information Interchange) and wide-char strings can be considered. [0040]) [Examiner interprets that detecting and analyzing read file events (i.e., read data) and generating snapshots to evaluate data transformation before and after encryption and determining data states before and after using various technique such as Shannon entropy spikes, aggregated printable strings ratio drops as determining an additional compression ratio of read data in the time window, wherein the additional compression ratio is a ratio of a data amount of the read data before being compressed to a data amount of the read data after being compressed].
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Saad, Afek, Agarwal, and Penton to include a concept of determining an additional compression ratio of read data in the time window, wherein the additional compression ratio is a ratio of a data amount of the read data before being compressed to a data amount of the read data after being compressed as taught by Sternfeld for the purpose of determining whether an entity is determining ransomware-like behavior, such as the rarity of files that have been changed, whether the files which have been changed are changed often or not, whether the total volume of space occupied by files which have been changed is large, whether the total changes (e.g., as measured by entropy) across the changed files is large, etc. [Sternfeld:0058].
Regarding claims 10-12 and 18-20, Claims 10-12 and 18-20 recite commensurate subject matter as claims 2-4. Therefore, they are rejected for the same reasons.
Claims 5 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Saad (US 20200099699 A1) in view of Afek (US 20120243551 A1) in further view of Agarwal (US 20110277026 A1) in further view of Penton (US 20140115703 A1) in further view of Sternfeld (US 20230023584 A1) in further view of Berk (US 11748475 B1).
Regarding Claim 5, Saad, Afek, Agarwal, Penton, and Sternfeld teaches the method according to claim 4, wherein determining the user device side connection associated with the written data comprises: determining the user device side connection associated with the written data according to determining that the compression ratio is less than the threshold compression ratio (Saad, FIG. 3, The detection process of FIG. 3 may begin at 50 by selecting a sliding time window having a predetermined time span, T, corresponding to a desired number, N, blocks of data to be analyzed. The time span, T, of the window, and the number, N, of data blocks analyzed, may be selected based upon the type of data. At 52, a processing module (either 40 or 42 depending upon whether the process is deduplication or compression) may receive N blocks of unprocessed data from the sliding window, and process the received data at 54, e.g., compress the data (i.e., received compressed data). At 56, the monitor (44 or 46 as appropriate) connected to the module performing the processing may determine the processing ratio of the data processed by the module (i.e., received compressed data) as the ratio, r, of (Data In)/(Data Out). The processing ratio will be …the compression ratio if the processing was compression. At 58, the current processing ratio as determined at 56 may be compared to one or more previously determined processing ratios for the same data stream to detect significant changes in the ratio. At 60 any change in current processing ratio from the previous ratios that is more than a predetermined threshold amount may be determined to significant. For instance, if the compression ratio for a data stream has previously been measured to be between 1.5-2.0, and the ratio suddenly drops to about 1.0, indicating little or no compression, that may be an indication of encryption and possible ransomware because encrypted data cannot be compressed as much as unencrypted data. Thus, if the change in ratio is more than the predetermined threshold, this is an indication of a possible ransomware, [0028]) [Examiner interprets that calculating processing ratio (i.e., the compression ratio) for data within a predetermined time span and comparing it to predetermined threshold, identifying the drop in compression ratio than predetermined threshold and indicating the drop as potential ransomware attack as determining the user side connection associated with the written data comprises: determining the user side connection associated with the written data according to determining that the compression ratio is less than a threshold compression ratio]
Saad, Afek, Agarwal, Penton, and Sternfeld does not explicitly teach:
determining that the compression ratio is less than the additional compression ratio.
Berk teaches:
determining that the compression ratio is less than the additional compression ratio (Berk, analyzing read and write requests to the file system includes calculating a compression ratio for compressing a file block associated with a write request. Specifically, when a file block is modified, the compression ratio before the modification and after the modification may be compared. The likelihood that a ransomware attack is in progress may increase if the compression ratio of the file block decreases by more than a threshold amount after the modification, See Col 1, lines 55-63) [Examiner interprets under Broadest Reasonable interpretation that comparing compression ratio of file block before modification (i.e., read data) and compression ratio of after modification (i.e., write data) and detecting ransomware attack is compression ratio after modification (i.e., write data) is less than the compression ratio before modification (i.e., read data) as determining that the compression ratio is less than the additional compression ratio].
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Saad, Afek, Agarwal, Penton, and Sternfeld to include a concept of determining that the compression ratio is less than the additional compression ratio as taught by Berk for the purpose of detecting and recovering from ransomware infections [Berk: Col1 lines 34-41).
Regarding Claim 13, Claim 13 recites commensurate subject matter as claim 5. Therefore, it is rejected for the same reasons.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 20080224906 A1: “relates to systems and methods for compressing data streams and improving network performance by leveraging previously stored data”
US20210314377: “generally to an apparatus and method for streaming content from multiple servers, and, in particular, to concurrently streaming video content from multiple sources, such as from multiple Content Distribution Networks (CDNs).”
US20200404044 : “file transfer method defines predefined channels, interfaces, security, and compression mechanisms to which both the parties to the transfer (the server and the client) must strictly align to complete a file transfer”
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 SAMIKSHYA POUDEL whose telephone number is (703)756-1540. The examiner can normally be reached 7:30 AM - 5PM Mon- Fri.
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.
/S.N.P./Examiner, Art Unit 2436 /SHEWAYE GELAGAY/Supervisory Patent Examiner, Art Unit 2436