Detailed Action
This office action is in response to applicant’s submission filed on May 15, 2026. Claims 2, 12, and 20 have been canceled. Claims 1, 3-11, and 13-19 are pending and rejected.
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 Amendment
This communication is in response to the amendment filed on May 15, 2026. The Examiner has acknowledged the amended claims 1, 3, 9, 10, 11, 13, 18, and 19. Claims 2, 12, and 20 have been canceled. Claims 1, 3-11, and 13-19 are pending and rejected.
Response to Arguments
Applicant’s Arguments (Remarks) filed May 15, 2026 have been fully considered, but are not persuasive. Note that this action is made FINAL. See MPEP § 706.07(a).
Applicant's arguments filed May 15, 2026 have been fully considered but they are not persuasive. Applicant states that the secondary reference, Sukhomlinov, does not teach the claimed limitations properly. Examiner disagrees. Firstly, applicant’s statement that the Primary Examiner agreed during the interview that Sukhomlinov’s no overwrite architecture constitutes a “core operating principle” that must be incorporated when considering the proposed combination is not an accurate characterization of the interview. The interview did not establish such an agreement. Please also see Interview Summary dated 03/24/2026. Secondly, Applicant’s argument assumes that the rejection requires incorporation of Sukhomlinov’s continuous checkpointing/write-to-unused-physical-address architecture into Berler. This assumption is misplaced. Thirdly, applicant has not established that incorporating the relied upon data structure teachings of Sukhomlinov necessarily causes Berler to abandon its LBA-level monitoring or otherwise prevents Berler from detecting the read/write behavior on which its ransomware detection operates. Fourthly, the rejection does not disregard Sukhomlinov’s disclosure as a whole. Rather Sukhomlinov is relied upon for the specific teachings concerning hash tables/linked lists, etc. Considering a reference as a whole does not require bodily incorporation of every unrelated architectural feature disclosed in that reference. Fifth, applicant’s teaching away argument depends upon an unstated premise that the proposed combination requires Berler to adopt Sukhomlinov’s architecture and the rejection does not require such a wholesale substitution. Applicant therefore attacks a modification that is not the proposed combination, rather than explaining why the specific teachings of Sukhomlinov relied upon for the claimed limitations could not have been applied to Berler all of this was already told to the attorney in the Examiner interview.
The rest of the amendments were reworded/rearranged and therefore, have been rejected based on the same rationale. See also 103 rejection below.
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, 3-6, 11, 13-15, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over US 2019/0130097 A1 to Berler et al. (hereinafter, “Berler”) in view of US 2019/0102262 A1 to Sukhomlinov et al. (hereinafter, “Sukhomlinov”).
Regarding claim 1, Berler discloses: A nonvolatile memory device comprising:
a memory storing a read segments database; and processing circuitry configured to (“a computer program product for determining whether a ransomware attack is suspected, includes a non-transitory, computer-readable storage medium encoded with instructions adapted to be executed by a processor to implement: monitoring activity between a controller and a non-volatile memory; identifying in the activity indications of a ransomware attack; once indications of a ransomware attack have been identified, calculating an entropy of a data set to be written to the non-volatile memory; analyzing the calculated entropy; and determining whether a ransomware attack is suspected to have occurred” [0009]),
parse read and write commands received from a host (“The anti-ransomware module 150 may monitor the data path 125 between the controller 130 and the NVM 140. In some embodiments, the anti-ransomware module 150 may monitor the data path 125 by calculating the entropy of data to be written to the NVM. In some embodiments, the anti-ransomware module 150 may monitor the data path 125 by identifying abnormal read-write patterns to the NVM” [0031]; “Furthermore, the anti-ransomware module may be configured to monitor read and/or write accesses to the NVM with the same LBA ranges” [0023] [Examiner notes that monitoring the data path between the controller and the NVM necessarily requires observing read/write commands before they reach storage]),
detect write after read operations based on the read and write commands and the read segments database (“In one or more embodiments disclosed herein, activity indicative of ransomware comprises at least one of: a read access of the data set from a first logical block address range and a subsequent write access to the first logical block address range” [0053]; “FIG. 4 is a flowchart illustrating another embodiment of a device-based anti-ransomware method 400. As in the previous example, the data storage device is an SSD data storage device having a controller, NVM, and an anti-ransomware module. The method 400 begins at 410 wherein the data path between the controller and the NVM is monitored. During the monitoring 410, at 412, historic norms and/or patterns of read and/or write activity may be identified. In some embodiments, read-write activity may be logged to provide a standard for identifying anomalous read-write patters” [0026] [Examiner notes that the logging mechanism that tracks read activity for later comparison to writes functionality corresponds to a read segments database]),
determine features of the write after read operations (“In one or more embodiments disclosed herein, the analyzing further comprises at least one of: comparing a first amount of data in the data set that is read from the non-volatile memory with a second amount of data in the data set that is subsequently written to the non-volatile memory; and comparing a first entropy calculation of the data set that is read from the non-volatile memory and a second entropy calculation of the data set that is subsequently written to the non-volatile memory” [0048]; “For example, amount of data read and/or written may be calculated. The method 300 continues at 330 wherein the calculation is analyzed to identify whether a suspected ransomware attack has occurred. In some embodiments, the analysis proceeds at 332 wherein the entropy of the data written to the NVM is compared to a threshold value. The analysis 330 proceeds at 336 wherein a calculated entropy higher than the threshold value indicates that a suspected ransomware attack has occurred. In some embodiments, the analysis proceeds at 334 wherein the entropy is compared to historic norms. The analysis 330 proceeds at 336 wherein a calculated entropy higher than the historic norm indicates that a suspected ransomware attack has occurred. In some embodiments, other types of analysis may be done in addition to, or in lieu of, comparison of the entropy of the data written to the NVM. For example, the amount of data read may be compared to the amount of data written. As another example, the entropy of a file that is read may be compared to the entropy of a file that is written. Differences in the amount and/or entropy of written data when compared to read data may be an indication that a suspected ransomware attack has occurred” [0025] [Examiner noes that these are characteristics derived from the read to write relationship]),
determine a probability of a ransomware attack based on the features (“To detect activity indicative of ransomware while a write operation is in progress, an anti-ransomware module of a data storage device may monitor write buffer payloads on the data path. For example, the anti-ransomware module may calculate cross-entropy. Since in encrypted data the probability of distribution of numbers of bits will be even, this comparison of cross-entropy may identify an attempt to encrypt plain text, an activity indicative of ransomware. Another example of activity indicative of ransomware includes overwrites of deterministic content by data with high entropy. The anti-ransomware module may inform the host system of such activity indicative of ransomware, signaling that data on that LBA should not be changed” [0027]; “The method 300 continues at 330 wherein the calculation is analyzed to identify whether a suspected ransomware attack has occurred. In some embodiments, the analysis proceeds at 332 wherein the entropy of the data written to the NVM is compared to a threshold value. The analysis 330 proceeds at 336 wherein a calculated entropy higher than the threshold value indicates that a suspected ransomware attack has occurred. In some embodiments, the analysis proceeds at 334 wherein the entropy is compared to historic norms. The analysis 330 proceeds at 336 wherein a calculated entropy higher than the historic norm indicates that a suspected ransomware attack has occurred. In some embodiments, other types of analysis may be done in addition to, or in lieu of, comparison of the entropy of the data written to the NVM” [0025] [Examiner notes that the threshold decision here is the probabilistic determination]), and
output a warning in response to determining a likely ransomware attack (“For example, the anti-ransomware module may block suspicious host writes 332, may inform the host system that a suspected ransomware attack has been detected 334, and/or may automatically backup LBA ranges that were deemed to be attacked 336” [0025]),
Berler does not disclose: wherein the read segments database includes a static hash table portion and a dynamic extensions list portion, and wherein the static hash table portion is connected with the dynamic extensions list portion via a pointer.
However, Sukhomlinov discloses: wherein the read segments database includes a static hash table portion (“In one embodiment, ledger 430 is implemented as a hash-table, with a hash-function and collision handling scheme as may be understood in the art. In one embodiment, ledger 430 has a maximum of S list nodes. In one embodiment, ledger 430 is maintained in SSD DRAM. In one embodiment, ledger 430 is stored as SPI flash filesystem metadata. In one embodiment, ledger 430 is stored as filesystem metadata on the host. In one embodiment, the information of system 400 is kept non-volatilely across power-events, either by storing it in nonvolatile memory, or by using volatile memory storing techniques, such as save on shutdown, checkpointing and rebuilds, PLI-saves, or some other technique” [0083] [Examiner notes that the ledger 430 is interpreted as the read segments database as it is where the address information is logged]) and
a dynamic extensions list portion (“Ledger 430 is illustrated as being keyed by the LBA or logical address. In one embodiment, ledger 430 is keyed by physical address, rather than logical address. In one embodiment, keying ledger 430 with logical address requires the tracking of a P2L (physical to logical) table for the multiple current EUs. When keying with the physical address instead of logical address, tracking the P2L table may not be necessary, since physical addresses can be directly used to key into the ledger, without requiring the corresponding logical address. In one embodiment, entries in ledger 430 include next/previous entries, in time-order, across LBAs. Thus, the ledger can be implemented as a doubly-linked list. A doubly-linked list can be used to reduce computation required for rollbacks” [0084] [Examiner notes that a doubly-linked list allocates nodes dynamically, expands as entries are added, and is not a fixed size])
and wherein the static hash table portion is connected with the dynamic extensions list portion via a pointer (“In one embodiment, ledger 430 is implemented as a hash-table, with a hash-function and collision handling scheme as may be understood in the art. In one embodiment, ledger 430 has a maximum of S list nodes” [0083]; “In one embodiment, entries in ledger 430 include next/previous entries, in time-order, across LBAs. Thus, the ledger can be implemented as a doubly-linked list. A doubly-linked list can be used to reduce computation required for rollbacks” [0084] [Examiner notes that the hash table provides the chunk entry structure. Each entry in the hash table can be viewed as a chunk entry. Each ledger entry is interpreted as a segment allocation. The "fourth" segment allocation can be any one of the entries in the chunk entry that contains a pointer. The next/previous links are pointers connecting entries in the ledger. The linked nodes in the doubly-linked list are allocated as needed beyond the static hash table (dynamically) and the collection of dynamically allocated ledger nodes connected via the linked list acts as the overflow or extension portion beyond the static hash table (interpreted as the dynamic extensions list)]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Berler with the added structure of Sukhomlinov in order for the system to be able to efficiently map with a fixed size hash table along with a dynamic allocation extension and be able to expand beyond a fixed limit without making the main hash table bigger.
Claim 11 recites substantially the same limitation as claim 1, in the form of a method for implementing the corresponding nonvolatile memory device, therefore it is rejected under the same rationale.
Regarding claims 3 and 13, Berler-Sukhomlinov discloses the system of claims 1/11.
Berler does not disclose: wherein the static hash table portion includes a plurality of chunk entries, and wherein one or more of the chunk entries includes a pointer to a linked list of segment allocations.
However, Sukhomlinov discloses: wherein the static hash table portion includes a plurality of chunk entries (“In one embodiment, ledger 430 is implemented as a hash-table, with a hash-function and collision handling scheme as may be understood in the art. In one embodiment, ledger 430 has a maximum of S list nodes. In one embodiment, ledger 430 is maintained in SSD DRAM. In one embodiment, ledger 430 is stored as SPI flash filesystem metadata. In one embodiment, ledger 430 is stored as filesystem metadata on the host. In one embodiment, the information of system 400 is kept non-volatilely across power-events, either by storing it in nonvolatile memory, or by using volatile memory storing techniques, such as save on shutdown, checkpointing and rebuilds, PLI-saves, or some other technique” [0083] [Examiner notes that hash tables have some of "entries" so those slots are seen as the chunk entries. They correspond directly to the pre-allocated slots of ledger 430 since each entry represents a fixed location]), and
wherein one or more of the chunk entries includes a pointer to a linked list of segment allocations (“In one embodiment, entries in ledger 430 include next/previous entries, in time-order, across LBAs. Thus, the ledger can be implemented as a doubly-linked list. A doubly-linked list can be used to reduce computation required for rollbacks [0084]; In one embodiment, ledger 430 is implemented as a hash-table, with a hash-function and collision handling scheme as may be understood in the art. In one embodiment, ledger 430 has a maximum of S list nodes. In one embodiment, ledger 430 is maintained in SSD DRAM. In one embodiment, ledger 430 is stored as SPI flash filesystem metadata. In one embodiment, ledger 430 is stored as filesystem metadata on the host” [0083] [Examiner notes that these texts explicitly show that entries in the ledger can be linked to one another via pointers, supporting the concept of a pointer to a dynamic linked list of segment allocations. Hash tables often handle multiple entries per chunk using a linked list (list nodes) and these texts provide the structural basis for having chunk entries point to a linked list for additional segments]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Berler with the added structure of Sukhomlinov in order for the system to be able to efficiently manage the allocations in the segment list.
Regarding claim 4, Berler-Sukhomlinov discloses the system of claim 3.
Berler does not disclose: wherein the linked list of segment allocations includes a maximum of four segment allocations in the hash table portion corresponding with each chunk entry of the plurality of chunk entries.
However, Sukhomlinov discloses: wherein the linked list of segment allocations includes a maximum of four segment allocations in the hash table portion corresponding with each chunk entry of the plurality of chunk entries (“In one embodiment, ledger 430 is implemented as a hash-table, with a hash-function and collision handling scheme as may be understood in the art. In one embodiment, ledger 430 has a maximum of S list nodes” [0083]; “In one embodiment, entries in ledger 430 include next/previous entries, in time-order, across LBAs. Thus, the ledger can be implemented as a doubly-linked list. A doubly-linked list can be used to reduce computation required for rollbacks” [0084] [Examiner notes that these texts shows that there is a maximum number of list nodes in the ledger. This supports the idea that each chunk entry's linked list can have a fixed upper limit on nodes. The text also shows that the ledger entries are linked in a list. Combining these texts supports the idea that each chunk entry can have a limited length linked list]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Berler with the added structure of Sukhomlinov in order for the system to be able to efficiently handle collision schemes.
Regarding claim 5, Berler-Sukhomlinov discloses the system of claim 4.
Berler does not disclose: wherein a fourth segment allocation of a respective chunk entry of the plurality of chunk entries includes a pointer to a dynamic allocation included in the dynamic extensions list portion.
However, Sukhomlinov discloses: wherein a fourth segment allocation of a respective chunk entry of the plurality of chunk entries includes a pointer to a dynamic allocation included in the dynamic extensions list portion (“In one embodiment, ledger 430 is implemented as a hash-table, with a hash-function and collision handling scheme as may be understood in the art. In one embodiment, ledger 430 has a maximum of S list nodes” [0083]; “In one embodiment, entries in ledger 430 include next/previous entries, in time-order, across LBAs. Thus, the ledger can be implemented as a doubly-linked list. A doubly-linked list can be used to reduce computation required for rollbacks” [0084] [Examiner notes that the hash table provides the chunk entry structure. Each entry in the hash table can be viewed as a chunk entry. Each ledger entry is interpreted as a segment allocation. The "fourth" segment allocation can be any one of the entries in the chunk entry that contains a pointer. The next/previous links are pointers connecting entries in the ledger. The linked nodes in the doubly-linked list are allocated as needed beyond the static hash table (dynamically) and the collection of dynamically allocated ledger nodes connected via the linked list acts as the overflow or extension portion beyond the static hash table (interpreted as the dynamic extensions list)]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Berler with the added structure of Sukhomlinov in order for the system to be able to efficiently expand beyond a fixed limit without making the main hash table bigger.
Regarding claim 6, Berler-Sukhomlinov discloses the system of claim 1.
Berler further discloses: wherein the processing circuitry is further configured to manage the read segments database (“In another embodiment, a computer program product for determining whether a ransomware attack is suspected, includes a non-transitory, computer-readable storage medium encoded with instructions adapted to be executed by a processor to implement: monitoring activity between a controller and a non-volatile memory; identifying in the activity indications of a ransomware attack; once indications of a ransomware attack have been identified, calculating an entropy of a data set to be written to the non-volatile memory; analyzing the calculated entropy; and determining whether a ransomware attack is suspected to have occurred” [0009]).
Regarding claim 14, Berler-Sukhomlinov discloses the system of claim 3.
Berler does not disclose: wherein the linked list of segment allocations includes a number of segment allocations in the hash table portion corresponding with each chunk entry of the plurality of chunk entries.
However, Sukhomlinov discloses: wherein the linked list of segment allocations includes a number of segment allocations in the hash table portion corresponding with each chunk entry of the plurality of chunk entries (“Ledger 430 represents a mapping of previous write information. As illustrated, ledger 430 operates based on a logical block address (LBA), but could alternatively be maintained based on physical address. In one embodiment, ledger 430 represents a dictionary that maps logical addresses to a list or string of physical addresses. In one embodiment, each list is in write-order, with most recent physical address corresponding to the logical address being first or at the head. For example, consider LBA8, which is identified in L2P 410 as being associated with current physical address “EU3:P3”. Ledger 430 identifies a previous physical address (prey phy addr) 432 as “EU1:P3”. For LBA9, L2P 410 includes current physical address 412, and ledger 430 includes previous physical address 432, previous-previous physical address (prey-prey phy addr) 434, and previous-previous-previous physical address (prey-prey-prey phy addr) 436. Thus, LBA8 can be understood to have one former state available for rollback, and LBA9 has three former states available for rollback” [0080] [Examiner notes that these texts shows that each logical address in the ledger has a list of physical addresses]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Berler with the added structure of Sukhomlinov in order for the system to be able to efficiently handle collision schemes.
Regarding claim 15, Berler-Sukhomlinov discloses the system of claim 14.
Berler does not disclose: wherein a last segment allocation of the number of segment allocations of a respective chunk entry of the plurality of chunk entries includes a pointer to a dynamic allocation included in the dynamic extension list portion.
However, Sukhomlinov discloses: wherein a last segment allocation of the number of segment allocations of a respective chunk entry of the plurality of chunk entries includes a pointer to a dynamic allocation included in the dynamic extension list portion (“In one embodiment, ledger 430 is implemented as a hash-table, with a hash-function and collision handling scheme as may be understood in the art. In one embodiment, ledger 430 has a maximum of S list nodes” [0083]; “In one embodiment, entries in ledger 430 include next/previous entries, in time-order, across LBAs. Thus, the ledger can be implemented as a doubly-linked list. A doubly-linked list can be used to reduce computation required for rollbacks” [0084] [Examiner notes that the hash table provides the chunk entry structure. Each entry in the hash table can be viewed as a chunk entry. Each ledger entry is interpreted as a segment allocation. The “last” segment allocation can be any one of the entries in the chunk entry that contains a pointer. The next/previous links are pointers connecting entries in the ledger. The linked nodes in the doubly-linked list are allocated as needed beyond the static hash table (dynamically) and the collection of dynamically allocated ledger nodes connected via the linked list acts as the overflow or extension portion beyond the static hash table (interpreted as the dynamic extensions list)]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Berler with the added structure of Sukhomlinov in order for the system to be able to efficiently expand beyond a fixed limit without making the main hash table bigger.
Claim 19 recites substantially the same limitation as claim 1, in the form of a system for implementing the corresponding nonvolatile memory device, therefore it is rejected under the same rationale.
Claims 7, 8, 16, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over US 2019/0130097 A1 to Berler et al. (hereinafter, “Berler”) in view of US 2019/0102262 A1 to Sukhomlinov et al. (hereinafter, “Sukhomlinov”) and in further view of US 2023/0259625 A1 to Gechman et al. (hereinafter, “Gechman”).
Regarding claims 7 and 16, Berler-Sukhomlinov discloses the system of claims 1/11.
Berler-Sukhomlinov does not disclose: classify the features using a random forest state machine.
However, Gechman discloses: classify the features using a random forest state machine (“Machine learning involves training a computing system—using training data—to identify features in data that may facilitate detection and classification. Training can be supervised or unsupervised. Machine learning models can use various computational algorithms, such as decision tree algorithms (or other rule-based algorithms), artificial neural networks, and the like. During an inference stage, new data is input into a trained machine learning model, and the trained machine learning model can classify items of interest using features identified during training” [0003]; “The ML detection system can include a random-forest classification model. The random-forest classification model is a time-series-based model trained to classify a process as ransomware or non-ransomware using cascading of different numbers of snapshots in the series of snapshots (e.g., 3, 5, and 10 snapshots)” [0029]; “In at least one embodiment, data extraction logic 146 extracts and sends a series of snapshots to ML detection system 134, and ML detection system 134 includes feature extraction logic 144 to extract a set of features from different process plugins such as memory plugins. Feature extraction logic 144 extracts a set of features from different memory plugins from each snapshot of the series of snapshots. In at least one embodiment, extract features are fed into ransomware detection system 136. In at least one embodiment,
ransomware detection system 136 includes a random-forest classification model. The random-forest classification model can be a time-series-based model trained to classify a process as ransomware or non-ransomware using cascading of different numbers of snapshots in the series of snapshots. In at least one embodiment, the cascading of a different number of snapshots in the series includes a first number of snapshots obtained over a first amount of time, a second number of snapshots obtained over a second amount of time greater than the first amount of time, and a third number of snapshots obtained over a third amount of time greater than the second amount of time. The second number of snapshots includes the first number of snapshots, and the third number of snapshots includes the second number of snapshots. Additional details of the different memory plugins and the random-forest classification model are described below with respect to FIGS. 3A-4” [0035] [Examiner notes that these two texts together support the claim limitation as it shows how features are classified by a tree-based ML model while maintaining state via a finite state machine. Examiner also notes that the last text was brought it because it shows that the model considers snapshots over time, effectively capturing a state-based evaluation]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Berler with the added structure of Gechman in order for the system to be able to efficiently classify adaptive behavior within time frames.
Regarding claims 8 and 17, Berler-Sukhomlinov discloses the system of claims 7/16.
Berler-Sukhomlinov does not disclose: wherein the processing circuitry is further configured to determine the probability of the ransomware attack based on a majority vote of trees included in the random forest state machine.
However, Gechman discloses: wherein the processing circuitry is further configured to determine the probability of the ransomware attack based on a majority vote of trees included in the random forest state machine (“In at least one embodiment, data extraction logic 146 extracts and sends a series of snapshots to ML detection system 134, and ML detection system 134 includes feature extraction logic 144 to extract a set of features from different process plugins such as memory plugins. Feature extraction logic 144 extracts a set of features from different memory plugins from each snapshot of the series of snapshots. In at least one embodiment, extract features are fed into ransomware detection system 136. In at least one embodiment, ransomware detection system 136 includes a random-forest classification model. The random-forest classification model can be a time-series-based model trained to classify a process as ransomware or non-ransomware using cascading of different numbers of snapshots in the series of snapshots. In at least one embodiment, the cascading of a different number of snapshots in the series includes a first number of snapshots obtained over a first amount of time, a second number of snapshots obtained over a second amount of time greater than the first amount of time, and a third number of snapshots obtained over a third amount of time greater than the second amount of time. The second number of snapshots includes the first number of snapshots, and the third number of snapshots includes the second number of snapshots. Additional details of the different memory plugins and the random-forest classification model are described below with respect to FIGS. 3A-4” [0035]; “In at least one embodiment, a first random-forest classification model 302 receives a first feature set in a first snapshot 304, a second feature set in a second snapshot 306, and a third feature set in a third snapshot 308. First random-forest classification model 302 classifies a process as ransomware 301 or non-ransomware 303 using the feature sets from these snapshots 304-308. In at least one embodiment, first random-forest classification model 302 can output an indication of ransomware 305 responsive to the process being classified as ransomware 301. The indication of ransomware 305 can specify a level of confidence that the process corresponds to the ransomware class. The level of confidence can be a prediction percentage of being ransomware. For example, if the level of confidence satisfies a level of confidence criterion (e.g., a confidence threshold), first random-forest classification model 302 can classify the process as ransomware 301. Alternatively, first random-forest classification model 302 can output an indication of non-ransomware responsive to the process being classified as non-ransomware 303. The indication of non-ransomware can indicate a level of confidence that the process corresponds to the non-ransomware class. In this embodiment, first random-forest classification model 302 is used as a first stage of multiple stages in the time-series-based model (random-forest classification model 300)” [0076] [Examiner notes that in a random forest, each tree votes and the majority vote determines the class. The level of confidence reflects the fraction of trees voting for the ransomware).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Berler with the added structure of Gechman in order for the system to be able to efficiently classify adaptive behavior within time frames.
Claims 9 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over US 2019/0130097 A1 to Berler et al. (hereinafter, “Berler”) in view of US 2019/0102262 A1 to Sukhomlinov et al. (hereinafter, “Sukhomlinov”) in further view of US 2015/0269279 A1 to Bosshart.
Regarding claims 9 and 18, a combination of Berler-Sukhomlinov disclose the system of claims 1/11.
Berler-Sukhomlinov do not disclose: manage the static hash table portion using cuckoo hashing.
However, Bosshart discloses: manage the static hash table portion using cuckoo hashing (“In some preferred implementations, the first storage 204 to store the Cuckoo hash table may be a first type of memory, and the second storage 206 to store the graph may be a second type of memory different from the first type. For example, if the Cuckoo hash table is stored in an on-chip array of static random-access memory (SRAM), and the graph is stored in an external commodity dynamic random-access memory (DRAM). The processor 202 may perform all computations regarding to updating the graph and subsequently direct an exact minimal sequence that is required for additions and relocations of entries in the Cuckoo hash table stored in the SRAM. As such, for some suitable applications, since the SRAM is configured to be accessed with a higher bandwidth and a faster speed compared to the DRAM, the system 200 may advantageously best use available resources in the Cuckoo hash table by filling the hash table to its maximum capacity. However, in some alternate applications, if a larger size of Cuckoo hash table is required, the first storage 201 and the second storage 206 may be resided in a same memory or storage device” [0030]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Berler-Sukhomlinov with the added structure of Bosshart because Cuckoo hashing is an algorithm in computer programming for resolving hash collisions in a hash table (see Bosshart 0019).
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over US 2019/0130097 A1 to Berler et al. (hereinafter, “Berler”) in view of US 2019/0102262 A1 to Sukhomlinov et al. (hereinafter, “Sukhomlinov”) in further view of US 5706462 A to Matousek.
Regarding claim 10, a combination of Berler-Sukhomlinov disclose the system of claim 2.
Berler-Sukhomlinov do not disclose: manage the static hash table portion to be below 80% utilization.
However, Matousek discloses: manage the static hash table portion to be below 80% utilization (“Still more particularly described, the present invention determines whether the performance of the hash table falls below the predetermined threshold by determining whether a predetermined percentage of the slots in the hash table are being used or whether a predetermined percentage of accesses to the hash table result in collisions” [Col. 4, lines 5-10] [Examiner notes that this reference teaches monitoring whether a predetermined percentage of slots are used, which inherently manages table utilization relative to a threshold, clearly representing a threshold-based occupancy control mechanism]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Berler-Sukhomlinov with the added structure of Matousek in order to prevent collisions from happening.
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 extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should
be directed to SARON MATTHEWOS WORKU whose telephone number is (703)756-1761. The
examiner can normally be reached Monday - Friday, 9:30am - 6: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, Linglan Edwards can be reached on 571-270-5440. 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.
/SARON MATTHEWOS WORKU/Examiner, Art Unit 2408
/CHAU LE/Primary Examiner, Art Unit 2408
Prosecution Insights