Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
DETAILED ACTION
This office action is in response to the application filed on 01/29/2026. Claim(s) 1-13 and 15-20 is/are pending and are examined. Claim 14 is cancelled.
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 .
Priority
Acknowledgment is made of applicant’s claim for foreign priority under 35 U.S.C. 119 (a)-(d). The certified copy has been filed in parent Application No. 10-2023-0191463, filed on 12/26/2023.
Response to Arguments
Applicant's arguments filed on 1/29/2026 have been fully considered but they are not persuasive for the following reasons:
Applicant’s Argument:
Nossik merely discloses a trap object which may be a memory block as disclosed in Col. 1, ln 43-65. Nossik is completely silent on "physical address history information stored in a decoy page within the decoy memory block". Moreover, unlike the present disclosure, Nossik's "trap objects", also referred to as "honeypots" (col 6, ln 8), which are deployed with a determined number and determined arrangements of the trap objects
(Co. 6, ln 20-23). That is, Nossik's storage controller is NOT capable of identifying "a victim page within the victim memory block based on physical address history information stored in a decoy page", because 1) physical address history information is not disclosed and 2) the trap object is predetermined. (Applicant’s response filed on 1/29/2026, page 9-10).
Examiner’s Response:
The Examiner respectfully disagrees. The cited portion of Nossik Col. 1 Ln. 43-65 teaches, “at least one trap object particularly configured for use in detection of a ransomware attack and not otherwise utilized for storage of operational data in the storage device. (i.e. decoy memory block) the trap object may comprise one or more specific storage blocks of the storage device with the one or more specific storage blocks being determined at least in part by the file system of the storage device. (i.e., memory block)” which clearly establishes the idea of these memory blocks that are designed to trick or trap an attacker to prevent an attack. The idea of the address history is further alluded to in Nossik Col. 7 Ln. 41-48 teaches, “confirm integrity of the trap object, the ransomware detector 126 can compute an instance of a designated function of contents of the trap object and compare the instance to a previously-computed instance of the designated function of the contents of the trap object. The designated function may comprise a hash function, a checksum function or another type of function.” Which teaches the idea of checking the data in the trap for verification of the data and identifying if an attack has occurred. Nossik in combination with the teachings of Tal cover the concepts of physical addresses and memory pages. As such the combination of Tal with Nossik teach each and every limitation of the claimed limitation. It would have been obvious to one with ordinary skill the art, prior to the applicant's earliest effective filing date, to combine the teachings of Tal with Nossik, to modify the recovering of data with parity checking with RAID strips of Tal with the automated detection and remediation of ransomware of Nossik. The motivation to do so, Nossik Col. 1 Ln. 30-32, to detect ransomware attacks.
Applicant’s Argument:
Moreover, regarding the determining whether a garbage collection has been executed on
the victim memory block after the ransomware attack, pages 12-13 of the Office Action states that Tal in view of Nossik dies not disclose determining whether a garbage collection has been
executed. The Office Action attempted to cure the deficit with Kannan. However, as the Office Action states, 1) Tal fails to disclose such feature, 2) Nossik merely discloses that the reporting is performed after the ransomware attack (col 13, ln 20-26:"the process moves to step 506 toDB1/
report a detected instance of ransomware"), and 3) Kannan merely discloses a garbage collection is performed if there is an imbalance and fails to disclose "determining whether a garbage collection has been executed". In addition, page 13 of the Office Action alleges that the motivation to combine Kannan to modify Tal in view of Nossik is to "correct an imbalance in the memory." However, the combination of Tal, Nossik, and Kannan appears to be based solely on improper hindsight reasoning using only Applicants' specification as a guide to reconstruct the claimed combination by picking and choosing prior art elements and recombining them to reach the specifically arranged combination embodied by claim 13. MPEP 2142 states "impermissible hindsight must be avoided and the legal conclusion must be reached on the basis of the facts
gleaned from the prior art." MPEP 2144.03(A) (emphasis added). (Applicant’s response filed on 01/29/2026, page 10-11).
Examiner’s Response:
The Examiner respectfully disagrees. The first portions are addressed by the previous argument above. Addressing the combination of Tal with Nossik with Kannan one with ordinary skill in the art would be motivated to combine the arts of Tal, Nossik, and Kannan to achieve the claimed limitations. As the traps of Nossik being implemented in the environment of Tal would allow for the memory of Tal to be protected by the trapping method introduced in Nossik which is an obvious combination to make. For the inclusion of Kannan into the system it is well known in the art the data especially in storage environments involving stripes that the organization, protection, and cleaning of memory to maintain a fast, reliable, and secure system is a necessity. Which is where the introduction of Kannan comes in, a garbage collector that is keeping the memory system balanced is going to aid in keeping the system running smoothly especially as the trap objects of Nossik are operating. If a trap object where to get full, become faulty, or irresponsive having a garbage collecting system to help clear and balance the memory of the system would be an obvious improvement to make to the system. As such the teachings of Nossik, Tal, and Kannan teach the claimed limitation above and it would be obvious to one having ordinary skill in the art to do so for the stated reasons above.
Applicant’s Argument:
Moreover, the cited references are completely silent on time points that when features of the elements of the storage device as recited in claim 18 of the present disclosure are to perform. The Office Action not only fails to point to the portion in the cited reference which allegedly corresponding to the elements of the claim storage device, but also used only Applicants' specification as a guide to reconstruct the claimed combination by picking and choosing prior art elements and recombining them to reach the specifically arranged combination embodied in claim 18.
Even assuming arguendo Tal, Nossik and Kanna disclose individual features as recited in claim 18, it is respectfully submitted that such a conclusion is not sufficient for making a
rejection under 35 USC 103. The Examiner is further directed to MPEP § 2143.01 under the subsection entitled "Fact that the Claimed Invention is Within the Capabilities of One of Ordinary Skill in the Art is Not Sufficient by Itself to Establish Prima Facie Obviousness", which sets forth the applicable standard:
A statement that modifications of the prior art to meet the claimed invention would have been [obvious] because the references relied upon teach that all
aspects of the claimed invention were individually known in the art is not
sufficient to establish aprimafacie case of obviousness without some objective
reason to combine the teachings of the references. (citing Ex parte Levengood, 28
USPQ2d 1300 (Bd. Pat. App. & Inter. 1993)). (Applicant’s response filed on 1/29/2026, page 11-12).
Examiner’s Response:
The Examiner respectfully disagrees. While the cited portions of Nossik-Tal-Kannan-Hansen may not use the specific wording of, “at x time point”, it would be obvious to one having ordinary skill in the art for the actions taught to be done in the order that they are cited, Kannan ¶ 298 teaches, “if there is no imbalance, flow branches back to the action, in order to continue monitoring storage space available. (i.e., memory was in free state) If there is an imbalance, flow branches to the action. In the action, garbage collection is performed to rebalance storage space available. (i.e., the garbage collector has not run)” At this first point in time the memory is balanced and Kannan specifically recites that there is a branch to an action, i.e., a second point in time. Basically, when the system balanced move onto step two, Nossik Col. 1 Ln. 43-65 teaches, “at least one trap object particularly configured for use in detection of a ransomware attack and not otherwise utilized for storage of operational data in the storage device. (i.e. decoy memory block) the trap object may comprise one or more specific storage blocks of the storage device with the one or more specific storage blocks being determined at least in part by the file system of the storage device. (i.e., memory block)” which clearly implementing the claimed decoy to capture an attacker. Then it would make sense at a third point in time coming after the trap has been placed to introduce Tal Col. 7 Ln. 5-15 teaches, “RAID configurations, etc., managing system capacity including device allocations and/or release of capacity, performing operations for recovering from errors and failures.” The clearing of information after the trap has captured memory. Leading finally into recovery of data and final processing at a fourth point in time as taught by Tal Col. 12 Ln. 50-60 teaches, “the parity data for a given stripe is computed using an XOR function, wherein a given parity strip is computed by XORing the data of the log segments (data strips) of the given stripe” and Hansen ¶233 teaches, “the RMM platform ransomware monitor configuration data including an exclusion list of one or more files, drives, and volumes to exclude from monitoring for ransomware detection; and step b) further comprising the filewatcher handler ignoring each create, delete, update and rename file-event included in the exclusion list.” As such the combination of Nossik-Tal-Kannan-Hansen taught teaches the claimed limitation and it would have been obvious to one with ordinary skill the art, prior to the applicant's earliest effective filing date, to combine the teachings of Nossik-Tal-Kannan with Hansen, to modify the recovering of data with parity checking with RAID strips of Tal with the automated detection and remediation of ransomware of Nossik with the raw data and garbage collector conditions of Kannan with the select deletion of data of Hansen. The motivation to do so, Hansen ¶ 17, to detect a potential ransomware-encryption in a plurality of files.
Applicant's remaining arguments with respect to amended claim 1, 13, and 18 have been fully considered but are moot in view of the new ground(s) of rejection.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1, 4, 5, and 11-12 is/are rejected under 35 U.S.C. 103 as being unpatentable over Tal (US 11,704,053 B1), hereinafter Tal in view of Nossik (US 10,609,066 B1), hereinafter Nossik in further view of Byun (US 2020/0125488 A1), hereinafter Byun.
Regarding Claim(s) 1 Tal teaches:
A storage device comprising:
a non-volatile memory device that includes a first stripe including a victim memory block and a plurality of striping memory blocks associated with the victim memory block, and a second stripe (Tal Col. 12 and 50-60 teaches, the parity data for a given stripe is computed using an XOR function, wherein a given parity strip is computed by XORing the data of the log segments (data strips) of the given stripe. Col. 10 Ln. 63-67 teaches, the out-of-place writes result in invalid blocks of data which cannot be reused until they are reclaimed. (i.e., victim memory). Col. 13 Ln. 60-65 teaches, “optimized” direct stripe write mode that is implemented using an interim stripe 500 (first stripe) and a destination stripe 510 (second stripe). (i.e., first and second stripe) )
generate recovery data based on a plurality of striping pages, respectively included in the plurality of striping memory blocks, wherein the plurality of striping pages corresponds to the victim page; and
program the recovery data into the victim page. (Tal Col. 7 Ln. 5-15 teaches, RAID configurations, etc., managing system capacity including device allocations and/or release of capacity, performing operations for recovering from errors and failures. Col. 12 Ln. 50-55 teaches, the parity data for a given stripe is computed using an XOR function, wherein a given parity strip is computed by XORing the data of the log segments (data strips) of the given stripe. Col. 10 Ln. 1-6 teaches, the log segments 302 can be, e.g., 32 KB, 64 KB, 128 KB, 256 KB, etc., depending on the application. Assuming that each logical block of a given storage device (e.g., cluster of sectors on HDD, or page of SSD. (i.e., the log segments contain memory pages which when performed with the parity would equate to the striping pages.))
Tal does not appear to explicitly teach but in related art:
including a decoy memory block; (Nossik Col. 1 Ln. 43-65 teaches, at least one trap object particularly configured for use in detection of a ransomware attack and not otherwise utilized for storage of operational data in the storage device. (i.e. decoy memory block) the trap object may comprise one or more specific storage blocks of the storage device with the one or more specific storage blocks being determined at least in part by the file system of the storage device. (i.e., memory block)) and
a memory controller configured to:
identify a victim page within the victim memory block based on physical address history information stored in in a decoy data of a decoy page within the decoy memory block; (Nossik Col. 1 Ln. 43-65 teaches, at least one trap object particularly configured for use in detection of a ransomware attack and not otherwise utilized for storage of operational data in the storage device. (i.e. decoy memory block) the trap object may comprise one or more specific storage blocks of the storage device with the one or more specific storage blocks being determined at least in part by the file system of the storage device. (i.e., memory block))
It would have been obvious to one with ordinary skill the art, prior to the applicant's earliest effective filing date, to combine the teachings of Tal with Nossik, to modify the recovering of data with parity checking with RAID strips of Tal with the automated detection and remediation of ransomware of Nossik. The motivation to do so, Nossik Col. 1 Ln. 30-32, to detect ransomware attacks.
wherein the physical address history information comprises a physical address corresponding to an original data of the victim page. (Byun ¶ 6 teaches, a logical address detector suitable for detecting logical addresses corresponding to physical addresses of valid data stored in a victim block based on physical-to-logical address information; a sorter suitable for arranging the detected logical addresses in a specific order; and a garbage collection module suitable for controlling the memory device to perform a garbage collection operation by sequentially programming the valid data into a target block according to the arranged logical addresses. (i.e., original data))
It would have been obvious to one with ordinary skill the art, prior to the applicant's earliest effective filing date, to combine the teachings of Tal in view of Nossik with Byun, to modify the recovering of data with parity checking with RAID strips of Tal with the automated detection and remediation of ransomware of Nossik with the arranged address and garbage collecting of Byun. The motivation to do so, Byun ¶ 64, to prevent the flash memory space from being wasted due to the invalidated page in the process of modifying the data.
Regarding Claim(s) 4 Tal-Nossik-Byun teaches:
The storage device of claim 1, wherein the memory controller comprises: (Tal-Nossik-Byun teaches the parent claim above.)
a recovery coding module configured to generate the recovery data by performing a recovery decoding operation based on a plurality of striping data respectively stored in the plurality of striping pages. (Tal Col. 7 Ln. 5-15 teaches, RAID configurations, etc., managing system capacity including device allocations and/or release of capacity, performing operations for recovering from errors and failures. Col. 12 Ln. 50-55 teaches, the parity data for a given stripe is computed using an XOR function, wherein a given parity strip is computed by XORing the data of the log segments (data strips) of the given stripe. Col. 10 Ln. 1-6 teaches, the log segments 302 can be, e.g., 32 KB, 64 KB, 128 KB, 256 KB, etc., depending on the application. Assuming that each logical block of a given storage device (e.g., cluster of sectors on HDD, or page of SSD. (i.e., the log segments contain memory pages which when performed with the parity would equate to the striping pages.))
Regarding Claim(s) 5 Tal-Nossik-Byunteaches:
The storage device of claim 4, wherein the recovery coding module is configured to: (Tal-Nossik-Byun teaches the parent limitation above.)
generate the recovery data by performing an XOR operation for bits included in the same bit position of each of the plurality of striping data. (Tal Col. 12 Ln. 50-55 teaches, the parity data for a given stripe is computed using an XOR function, wherein a given parity strip is computed by XORing the data of the log segments (data strips) of the given stripe.)
Regarding Claim(s) 11 Tal-Nossik-Byun teaches:
The storage device of claim 1, wherein the memory controller further comprises: (Tal-Nossik-Byun teaches the parent claim above.)
a ransomware detect module configured to detect a ransomware attack on the victim page. (Nossik Col. 1 Ln. 43-65 teaches, at least one trap object particularly configured for use in detection of a ransomware attack and not otherwise utilized for storage of operational data in the storage device.)
The motive given in Claim 1 is equally applicable to the above claim.
Regarding Claim(s) 12 Tal-Nossik-Byun teaches:
The storage device of claim 1, wherein a position of the victim page in the victim memory block corresponds to: (Tal-Nossik-Byun teaches the parent claim above.)
a position of each of the plurality of striping pages in the plurality of stripe blocks. (Tal Col. 7 Ln. 5-15 teaches, RAID configurations, etc., managing system capacity including device allocations and/or release of capacity, performing operations for recovering from errors and failures. Col. 12 Ln. 50-55 teaches, the parity data for a given stripe is computed using an XOR function, wherein a given parity strip is computed by XORing the data of the log segments (data strips) of the given stripe. Col. 10 Ln. 1-6 teaches, the log segments 302 can be, e.g., 32 KB, 64 KB, 128 KB, 256 KB, etc., depending on the application. Assuming that each logical block of a given storage device (e.g., cluster of sectors on HDD, or page of SSD.) For the parity check to be successful the bits and positions checked must match.)
Claim(s) 2 is/are rejected under 35 U.S.C. 103 as being unpatentable over Tal-Nossik-Byun as applied to claim 1 above, and further in view of Yun (US 2024/0036741 A1), hereinafter Yun.
Regarding Claim(s) 2 Tal-Nossik-Byun teaches:
The storage device of claim 1, wherein: (Tal-Nossik-Byun teaches the parent claim above.)
Tal-Nossik-Byun does not appear to explicitly teach but in related art:
the physical address history information is included in a meta region in the decoy page, wherein the meta region is not accessible by an external host device. (Yun ¶ 151 teaches, meta data may include master data which is data used during a booting operation of the memory system 100, history data which is system data capable of being changed during a runtime, and map data which is data indicating mapping information between logical addresses and physical addresses.)
It would have been obvious to one with ordinary skill the art, prior to the applicant's earliest effective filing date, to combine the teachings of Tal in view of Nossik with Yun, to modify the recovering of data with parity checking with RAID strips of Tal with the automated detection and remediation of ransomware of Nossik with the reading of physical addresses of Yun. The motivation to do so, Yun ¶ 5, to prevent the memory system from malfunctioning.
Claim(s) 3 is/are rejected under 35 U.S.C. 103 as being unpatentable over Tal-Nossik-Byun-Yun as applied to claim 2 above, and further in view of Suzuki (US 2024/0061785 A1), hereinafter Suzuki.
Regarding Claim(s) 3 Tal-Nossik-Byun-Yun teaches:
The storage device of claim 2, wherein: (Tal-Nossik-Byun-Yun teaches the parent claim above.)
Tal-Nossik-Byun-Yun does not appear to explicitly teach but in related art:
the physical address history information comprises a physical page number of the victim page. (Suzuki ¶ 52 teaches, The placement unit 132 outputs access resume data including a trigger address included in the address list output from the access history analysis unit 40 and a physical address with a page number to identify a resume target page (page number allocated to the page) (hereinafter, referred to as resume target physical address) to the access resume unit 133.)
It would have been obvious to one with ordinary skill the art, prior to the applicant's earliest effective filing date, to combine the teachings of Tal-Nossik-Byun-Yun with Suzuki, to modify the recovering of data with parity checking with RAID strips of Tal with the automated detection and remediation of ransomware of Nossik with the reading of physical addresses of Yun with the page numbers of Suzuki. The motivation to do so, Suzuki ¶ 52, to identify a target page.
Claim(s) 6 and 10 is/are rejected under 35 U.S.C. 103 as being unpatentable over Tal-Nossik-Byun as applied to claim 1 above, and further in view of Kannan (US 2022/0300413 A1), hereinafter Kannan.
Regarding Claim(s) 6 Tal-Nossik-Byun teaches:
The storage device of claim 1, wherein the plurality of striping memory blocks comprises: (Tal-Nossik-Byun teaches the parent claim above.)
a first parity memory block including first parity data for the victim data stored in the victim page and the plurality of first […] data. (Tal Col. 1 Ln. 55-65 teaches, The storage control node writes the received data to at least one data strip of the first stripe, computes parity data based on the data written to the first stripe, and writes the parity data to at least one parity strip of the first stripe.)
Tal-Nossik-Byun does not appear to explicitly teach but in related art:
a first plurality of data memory blocks respectively storing a first plurality of raw data; and (Kannan ¶ 181 teaches, ingesting the data from an external source into the training system and storing the data in raw form)
It would have been obvious to one with ordinary skill the art, prior to the applicant's earliest effective filing date, to combine the teachings of Tal-Nossik-Byun with Kannan, to modify the recovering of data with parity checking with RAID strips of Tal with the automated detection and remediation of ransomware of Nossik with the raw data and garbage collector conditions of Kannan. The motivation to do so, Kannan ¶ 294, to correct an imbalance in the memory.
Regarding Claim(s) 10 Tal-Nossik-Byun-Kannan teaches:
The storage device of claim 1, wherein: (Tal in view of Nossik teaches the parent claim above.)
the storage device is configured to generate the recovery data (Tal Col. 7 Ln. 5-15 teaches, RAID configurations, etc., managing system capacity including device allocations and/or release of capacity, performing operations for recovering from errors and failures.) when the victim page is in a free state. (Kannan ¶ 298 teaches, if there is no imbalance, flow branches back to the action, in order to continue monitoring storage space available. (i.e., memory was in free state) If there is an imbalance, flow branches to the action. In the action, garbage collection is performed to rebalance storage space available. (i.e., the garbage collector has not run))
The motive given in Claim 6 is equally applicable to the above claim.
Claim(s) 7 and 9 is/are rejected under 35 U.S.C. 103 as being unpatentable over Tal-Nossik-Byun-Kannan as applied to claim 6 above, and further in view of Xu (US 2021/0334200 A1), hereinafter Xu.
Regarding Claim(s) 7 Tal-Nossik-Byun-Kannan teaches:
The storage device of claim 6, wherein: (Tal-Nossik-Byun-Kannan teaches the parent limitation above.)
Tal-Nossik-Byun-Kannan does not appear to explicitly teach but in related art:
each of the victim memory block and the plurality of striping memory block is included in a different superblock. (Xu ¶ 34 teaches, Accordingly, a set of blocks distributed across a set of dies of a memory device using a striping scheme is referred herein to as a “superblock.”)
It would have been obvious to one with ordinary skill the art, prior to the applicant's earliest effective filing date, to combine the teachings of Tal-Nossik-Byun-Kannan, to modify the recovering of data with parity checking with RAID strips of Tal with the automated detection and remediation of ransomware of Nossik with the raw data and garbage collector conditions of Kannan with the superblock of Xu. The motivation to do so constitutes applying a known technique of Superblocks to known devices and/or methods for ransomware detection in memory ready for improvement to yield predictable results of organized data that can be better protected and remediated.
Regarding Claim(s) 9Tal-Nossik-Byun-Kannan-Xu teaches:
The storage device of claim 6, wherein: (Tal-Nossik-Byun-Kannan teaches the parent claim above.)
the plurality of striping memory blocks further comprise a second parity memory block configured to store second parity data for the victim data and the plurality of first raw data, and (Tal Col. 2 Ln. 1-6 teaches, The storage control node writes additional data to the second stripe, computes updated parity data based on the additional data written to the second stripe and the parity data of the first stripe, and writes the updated parity data to at least one parity strip of the second stripe.)
the victim memory block is included in the same superblock as one of the plurality of striping memory blocks. (Xu ¶ 34 teaches, Accordingly, a set of blocks distributed across a set of dies of a memory device using a striping scheme is referred herein to as a “superblock.”)
The motive given in Claim 7 is equally applicable to the above claim.
Claim(s) 8 is/are rejected under 35 U.S.C. 103 as being unpatentable over Tal-Nossik-Byun-Kannan as applied to claim 6 above, and further in view of Bhardwaj (US 2021/0191808 A1), hereinafter Bhardwaj.
Regarding Claim(s) 8 Tal-Nossik-Byun-Kannan teaches:
The storage device of claim 6, wherein: (Tal-Nossik-Byun-Kannan teaches the parent limitation above.)
Tal-Nossik-Byun-Kannan does not appear to explicitly teach but in related art:
each of the victim memory block and the plurality of striping memory blocks is included in the same plane. (Bhardwaj ¶ 13 teaches, A LUN stripe is a collection of planes that are treated as one unit when writing, reading, or erasing data. Each plane in a LUN stripe can carry out the same operation, in parallel, of all of the other planes in the LUN stripe.)
It would have been obvious to one with ordinary skill the art, prior to the applicant's earliest effective filing date, to combine the teachings ofTal-Nossik-Byun-Kannan, to modify the recovering of data with parity checking with RAID strips of Tal with the automated detection and remediation of ransomware of Nossik with the raw data and garbage collector conditions of Kannan with the planes of Bhardwaj. The motivation to do so constitutes applying a known technique of Planes to known devices and/or methods for ransomware detection in memory ready for improvement to yield predictable results of organized data that can be better protected and remediated.
Claim(s) 13-15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Tal in view of Nossik in further view of Kannan.
Regarding Claim(s) 13 Tal teaches:
An operation method of a memory controller configured to control a non-volatile memory device, comprising: (Tal Col. 5 Ln. 18-25 teaches, the device controller 152 comprises device controllers which are configured to manage stored data depending on the type(s) of storage devices that are implemented by the storage device array 154.)
recovering the victim memory block by performing a recovery decoding based on a first stripe that includes the victim memory block (Tal Col. 7 Ln. 5-15 teaches, RAID configurations, etc., managing system capacity including device allocations and/or release of capacity, performing operations for recovering from errors and failures. Col. 12 Ln. 50-55 teaches, the parity data for a given stripe is computed using an XOR function, wherein a given parity strip is computed by XORing the data of the log segments (data strips) of the given stripe.)
It would have been obvious to one with ordinary skill the art, prior to the applicant's earliest effective filing date, to combine the teachings of Tal with Nossik, to modify the recovering of data with parity checking with RAID strips of Tal with the automated detection and remediation of ransomware of Nossik. The motivation to do so, Nossik Col. 1 Ln. 30-32, to detect ransomware attacks.
Tal does not appear to explicitly teach but in related art:
detecting a ransomware attack on the non-volatile memory device; (Nossik Col. 1 Ln. 30-40 teaches, efficient detection of on-going ransomware attacks directly on a storage device rather than on associated user devices.)
identifying a victim memory block subject to the ransomware attack; (Nossik Col. 1 Ln. 43-65 teaches, at least one trap object particularly configured for use in detection of a ransomware attack and not otherwise utilized for storage of operational data in the storage device. the trap object may comprise one or more specific storage blocks of the storage device with the one or more specific storage blocks being determined at least in part by the file system of the storage device. (i.e., memory block)) based on physical address history information included in a decoy data, which is generated by the ransomware attack. (Nossik Col. 1 Ln. 43-65 teaches, at least one trap object particularly configured for use in detection of a ransomware attack (i.e., decoy data) and not otherwise utilized for storage of operational data in the storage device. the trap object may comprise one or more specific storage blocks of the storage device with the one or more specific storage blocks being determined at least in part by the file system of the storage device. (i.e., memory block))
on the victim memory block after the ransomware attack; (Nossik Col. 13 Ln. 20-26 teaches, an attempt may have been made to modify, delete or relocate the trap object. If the integrity of the trap object has changed, the process moves to step 506 to report a detected instance of ransomware. (i.e., after the ransomware attack))
recovering the victim memory block by validating invalid data stored in the victim memory block (Nossik Col. 15 Ln. 35-45 teaches, the metadata server 624 can direct the COW storage tier 614 to recover the snapshot data from its recorded last healthy state. (i.e., validating invalid data))
It would have been obvious to one with ordinary skill the art, prior to the applicant's earliest effective filing date, to combine the teachings of Tal with Nossik, to modify the recovering of data with parity checking with RAID strips of Tal with the automated detection and remediation of ransomware of Nossik. The motivation to do so, Nossik Col. 1 Ln. 30-32, to detect ransomware attacks.
Tal in view of Nossik does not appear to explicitly teach but in related art:
determining whether a garbage collection has been executed (Kannan ¶ 298 teaches, if there is no imbalance, flow branches back to the action, in order to continue monitoring storage space available. (i.e., the garbage collector has run) If there is an imbalance, flow branches to the action. In the action, garbage collection is performed to rebalance storage space available. (i.e., the garbage collector has not run))
when the garbage collection has not performed after the ransomware attack; and (Kannan ¶ 298 teaches, if there is no imbalance, flow branches back to the action, in order to continue monitoring storage space available. (i.e., the garbage collector has run) If there is an imbalance, flow branches to the action. In the action, garbage collection is performed to rebalance storage space available. (i.e., the garbage collector has not run))
when the garbage collection has been performed after the ransomware attack. (Kannan ¶ 298 teaches, if there is no imbalance, flow branches back to the action, in order to continue monitoring storage space available. (i.e., the garbage collector has run) If there is an imbalance, flow branches to the action. In the action, garbage collection is performed to rebalance storage space available. (i.e., the garbage collector has not run))
It would have been obvious to one with ordinary skill the art, prior to the applicant's earliest effective filing date, to combine the teachings of Tal in view of Nossik with Kannan, to modify the recovering of data with parity checking with RAID strips of Tal with the automated detection and remediation of ransomware of Nossik with the raw data and garbage collector conditions of Kannan. The motivation to do so, Kannan ¶ 294, to correct an imbalance in the memory.
Regarding Claim(s) 15 Tal-Nossik-Kannan teaches:
The operation method of claim 14, wherein the determining comprises: (Tal-Nossik-Kannan teaches the parent limitation above.)
determining that the garbage collection has been performed, when a first victim page in the victim memory block, as indicated by the physical address history information, is in a free state; and (Kannan ¶ 298 teaches, if there is no imbalance, flow branches back to the action, in order to continue monitoring storage space available. (i.e., the garbage collector has run) If there is an imbalance, flow branches to the action. In the action, garbage collection is performed to rebalance storage space available. (i.e., the garbage collector has not run). In some embodiments, if the space usage of the entire storage system reaches a threshold, migration is stalled until the array is empty enough to proceed (i.e., free state).)
determining that the garbage collection has not been performed, when the first victim page is not in the free state. (Kannan ¶ 298 teaches, if there is no imbalance, flow branches back to the action, in order to continue monitoring storage space available. (i.e., the garbage collector has run) If there is an imbalance, flow branches to the action. In the action, garbage collection is performed to rebalance storage space available. (i.e., the garbage collector has not run))
The motive given in Claim 13 is equally applicable to the above claim.
Claim(s) 16-17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Tal-Nossik-Kannan as applied to claim 15 above, and further in view of Kim (US 2018/0059937 A1), hereinafter Kim.
Regarding Claim(s) 16 Tal-Nossik-Kannan teaches:
The operation method of claim 15, wherein the recovering the victim memory block by validating invalid data comprises: (Nossik-Tal-Kannan teaches the parent limitation above.)
Tal-Nossik-Kannan does not appear to explicitly teach but in related art:
invalidating a first mapping between a first decoy page included in the decoy memory block and a first logical address; and (Kim ¶ 98 teaches, In order to use the data programmed in the redundancy cell region 524, the address mapping unit 516 will invalidate the normal address ADDn of the error-detected data in the normal cell region 522 and validate the redundancy address ADDr of the data programmed in the redundancy cell region 524.)
validating a second mapping between the first victim page and the first logical address. (Kim¶ 98 teaches, in order to use the data programmed in the redundancy cell region 524, the address mapping unit 516 will invalidate the normal address ADDn of the error-detected data in the normal cell region 522 and validate the redundancy address ADDr of the data programmed in the redundancy cell region 524.)
It would have been obvious to one with ordinary skill the art, prior to the applicant's earliest effective filing date, to combine the teachings of Tal-Nossik-Kannan with Kim, to modify the recovering of data with parity checking with RAID strips of Tal with the automated detection and remediation of ransomware of Nossik with the raw data and garbage collector conditions of Kannan with the address mapping of Kim. The motivation to do so, Kim ¶ 98, to validate and invalidate memory address’.
Regarding Claim(s) 17 Tal-Nossik-Kannan teaches:
The operation method of claim 15, wherein the recovering the victim memory block by performing the recovery decoding comprises: (Tal-Nossik-Kannan teaches the parent limitation above.)
generating first recovery data by performing the recovery decoding based on a plurality of striping pages, which correspond to the first victim page, included in the first stripe; (Tal Col. 7 Ln. 5-15 teaches, RAID configurations, etc., managing system capacity including device allocations and/or release of capacity, performing operations for recovering from errors and failures. Col. 12 Ln. 50-55 teaches, the parity data for a given stripe is computed using an XOR function, wherein a given parity strip is computed by XORing the data of the log segments (data strips) of the given stripe. Col. 10 Ln. 1-6 teaches, the log segments 302 can be, e.g., 32 KB, 64 KB, 128 KB, 256 KB, etc., depending on the application. Assuming that each logical block of a given storage device (e.g., cluster of sectors on HDD, or page of SSD. (i.e., the log segments contain memory pages which when performed with the parity would equate to the striping pages.))
programming the first recovery data in the first victim page; (Tal Col. 7 Ln. 5-15 teaches, RAID configurations, etc., managing system capacity including device allocations and/or release of capacity, performing operations for recovering from errors and failures. Col. 12 Ln. 50-55 teaches, the parity data for a given stripe is computed using an XOR function, wherein a given parity strip is computed by XORing the data of the log segments (data strips) of the given stripe.)
invalidating a first mapping between a first decoy page included in the decoy memory block and a first logical address; and (Kim¶ 98 teaches, in order to use the data programmed in the redundancy cell region 524, the address mapping unit 516 will invalidate the normal address ADDn of the error-detected data in the normal cell region 522 and validate the redundancy address ADDr of the data programmed in the redundancy cell region 524.)
validating a second mapping between the first victim page and a second logical address. (Kim¶ 98 teaches, in order to use the data programmed in the redundancy cell region 524, the address mapping unit 516 will invalidate the normal address ADDn of the error-detected data in the normal cell region 522 and validate the redundancy address ADDr of the data programmed in the redundancy cell region 524.)
The motive given in Claim 16 is equally applicable to the above claim.
Claim(s) 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Nossik in view of Tal in further view of Kannan and Hansen (US 2021/0152595 A1), hereinafter Hansen.
Regarding Claim 18 Nossik teaches:
A storage device comprising:
a plurality of data memory blocks including a victim memory block; (Nossik Col. 1 Ln. 43-65 teaches, at least one trap object particularly configured for use in detection of a ransomware attack and not otherwise utilized for storage of operational data in the storage device. the trap object may comprise one or more specific storage blocks of the storage device with the one or more specific storage blocks being determined at least in part by the file system of the storage device. (i.e., memory block))
a decoy memory block configured to store decoy data generated based on first […] data stored in the victim memory block at a second time point after the first time point, wherein the first […] data is one of the plurality of […] data; and (Nossik Col. 1 Ln. 43-65 teaches, at least one trap object particularly configured for use in detection of a ransomware attack and not otherwise utilized for storage of operational data in the storage device. (i.e. decoy memory block) the trap object may comprise one or more specific storage blocks of the storage device with the one or more specific storage blocks being determined at least in part by the file system of the storage device. (i.e., memory block))
a memory controller configured to identify the victim memory block from among the plurality of data memory blocks; and (Nossik Col. 7 Ln. 20-31 teaches, The trap object activity monitor 124 is configured to monitor the trap objects 115 and other deployed trap objects of the storage device 105 in order to identify activity that may be associated with a ransomware attack. For example, the trap object activity monitor can identify the presence of write operations directed to a given trap object, as well as other types of activity relating to attempts to modify, delete or relocate the trap object. The trap object activity monitor 124 provides information relating to these and other types of identified activity to the ransomware detector 126 for further processing.)
Nossik does not appear to explicitly teach but in related art:
a first parity memory block configure to store first parity data generated based on a plurality of […] data respectively stored in the plurality of data memory blocks (Tal Col. 12 Ln. 50-60 teaches, the parity data for a given stripe is computed using an XOR function, wherein a given parity strip is computed by XORing the data of the log segments (data strips) of the given stripe.)
generate, in response to the victim memory block is erased at a third time point after the second time point, first recovery data corresponding to the first […] data, (Tal Col. 7 Ln. 5-15 teaches, RAID configurations, etc., managing system capacity including device allocations and/or release of capacity, performing operations for recovering from errors and failures.)
It would have been obvious to one with ordinary skill the art, prior to the applicant's earliest effective filing date, to combine the teachings of Nossik with Tal, to modify the recovering of data with parity checking with RAID strips of Tal with the automated detection and remediation of ransomware of Nossik. The motivation to do so, Tal Col. 12 Ln. 50-60, to perform parity on a given stripe.
Nossik in view of Tal does not appear to explicitly teach but in related art:
at a first time point when each of the plurality of data memory blocks is in a fully-occupied state; (Kannan ¶ 298 teaches, if there is no imbalance, flow branches back to the action, in order to continue monitoring storage space available. (i.e., memory was in free state) If there is an imbalance, flow branches to the action. In the action, garbage collection is performed to rebalance storage space available. (i.e., the garbage collector has not run))
raw data (Kannan ¶ 181 teaches, ingesting the data from an external source into the training system and storing the data in raw form)
It would have been obvious to one with ordinary skill the art, prior to the applicant's earliest effective filing date, to combine the teachings of Nossik in view of TAl with Kannan, to modify the recovering of data with parity checking with RAID strips of Tal with the automated detection and remediation of ransomware of Nossik with the raw data and garbage collector conditions of Kannan. The motivation to do so, Kannan ¶ 294, to correct an imbalance in the memory.
Nossik-Tal-Kannan does not appear to explicitly teach but in related art:
based on the first parity data and the plurality of […] data excluding the first data, at a fourth time point after the third time point. ( Hansen ¶233 teaches, the RMM platform ransomware monitor configuration data including an exclusion list of one or more files, drives, and volumes to exclude from monitoring for ransomware detection; and step b) further comprising the filewatcher handler ignoring each create, delete, update and rename file-event included in the exclusion list.)
It would have been obvious to one with ordinary skill the art, prior to the applicant's earliest effective filing date, to combine the teachings of Nossik-Tal-Kannan with Hansen, to modify the recovering of data with parity checking with RAID strips of Tal with the automated detection and remediation of ransomware of Nossik with the raw data and garbage collector conditions of Kannan with the select deletion of data of Hansen. The motivation to do so, Hansen ¶ 17, to detect a potential ransomware-encryption in a plurality of files.
Claim(s) 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Tal-Nossik-Kannan-Hansen as applied to claim 18 above, and further in view of Bhardwaj.
Regarding claim 20 Nossik-Tal-Kannan-Hansen teaches:
The storage device of claim 18, wherein: (Nossik-Tal-Kannan-Hansen teaches the parent claim above.)
Nossik-Tal-Kannan-Hansen does not appear to explicitly teach but in related art:
the plurality of data memory blocks and the first parity memory block are included in the same plane. (Bhardwaj ¶ 13 teaches, A LUN stripe is a collection of planes that are treated as one unit when writing, reading, or erasing data. Each plane in a LUN stripe can carry out the same operation, in parallel, of all of the other planes in the LUN stripe.)
It would have been obvious to one with ordinary skill the art, prior to the applicant's earliest effective filing date, to combine the teachings of Nossik-Tal-Kannan-Hansen with Bhardwaj, to modify the recovering of data with parity checking with RAID strips of Tal with the automated detection and remediation of ransomware of Nossik with the raw data and garbage collector conditions of Kannan with the select deletion of data of Hansenwith the planes of Bhardwaj. The motivation to do so constitutes applying a known technique of Planes to known devices and/or methods for ransomware detection in memory ready for improvement to yield predictable results of organized data that can be better protected and remediated.
Allowable Subject Matter
Claim 19 is objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 2019/0235973 A1 - AUTOMATED RANSOMWARE IDENTIFICATION AND RECOVERY
US 2019/0004972 A1 - MITIGATING ATTACKS ON KERNEL ADDRESS SPACE LAYOUT RANDOMIZATION
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 JACOB BENEDICT KNACKSTEDT whose telephone number is (703)756-5608. The examiner can normally be reached Monday-Friday 8:00 am - 5:00 pm.
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.
/J.B.K./Examiner, Art Unit 2408
/LINGLAN EDWARDS/Supervisory Patent Examiner, Art Unit 2408