DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Information Disclosure Statement
The information disclosure statements (IDS) submitted on December 20, 2024, May 16, 2025, and November 7, 2025 have been considered by examiner. As for the KR OA issued by the Korean Patent Office on March 25, 2025 cited in the IDS filed May 16, 2025, Examiner has considered the KR OA in view of the “Notice of Preliminary Rejection” in the English language provided by applicant on May 16, 2025.
Furthermore, applicant submitted a European Search Report on November 7, 2025. The European Search Report was submitted with the IDS submitted on November 7, 2025, but has not been listed/cited in the IDS. Examiner has added the European Search Report to the PTO-892 form, therefore, the references in the European Search Report have been considered by examiner. Although cited in the PTO-892 form, Examiner has not provided a copy of the European Search Report, as applicant has already provided a copy.
Applicant is advised that the date of any re-submission of any item of information contained in this information disclosure statement or the submission of any missing element(s) will be the date of submission for purposes of determining compliance with the requirements based on the time of filing the statement, including all certification requirements for statements under 37 CFR 1.97(e). See MPEP § 609.05(a).
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-2, 9, 11-14 and 16 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Armangau et al. (Hereinafter Armangau, U.S. Publication No. 2020/0241763).
Regarding claim 1, Armangau teaches:
A memory device, comprising:
a memory array comprising compressed zones comprising a first compressed zone comprising slots of a first slot size and a second compressed zone comprising slots of a second slot size (See [0002] “a data storage system may receive host data into cache as uncompressed blocks, compress the blocks, and aggregate the compressed blocks into segments. The storage system may then flush the segments to persistent structures on disk. In some arrangements, each segment includes multiple slots,” See [0023] “The file system 160 stores a segment 168, which may be composed of multiple contiguous blocks, i.e., blocks having consecutive FSBNs. A typical size of segment 168 may be 8 blocks, which works out to 64 kB for an 8-kB block size. However, the number of blocks in a segment 168 may vary. In the example shown, segment 168 stores compressed extents for a file 164a. The file 164a is designated by an inode (index node) 164. The segment 168 includes multiple extents of compressed data, which are stored in respective slots 142a through 1421. A “slot” as used herein is a region of continuous storage space within a segment.” See [0023] “Slot sizes are variable based on the size of the compressed extents they store. For ease of addressing, slots 142 may be sector-aligned, meaning that the size of each slot is an integer multiple of a sector.” Memory segments that may store compressed blocks/extents correspond to the claimed compressed zones.); and
a controller configured to compress a first data element received from a processing block (See [0007] “The computer program product stores instructions which, when executed on control circuitry of a data storage system, cause the data storage system to perform a method of managing storage of compressed data, such as the method described above.” See [0028] “For each block, or some subset thereof, compressor 138 compresses the block and slot allocator 140 allocates a slot 142 for storing the compressed block 146.” See [0028] “the hosts 110 issue I/O requests 112 to the data storage system 116.” See [0028] “The buffer 134 arranges incoming data from the I/O requests 112 W into batches 136, with each batch including multiple block-sized increments of data, referred to herein as ‘blocks,’”), and store the compressed first data element in a first slot of the slots of the first compressed zone based on a data size of the compressed first data element (See [0028] “For each block, or some subset thereof, compressor 138 compresses the block and slot allocator 140 allocates a slot 142 for storing the compressed block 146.” See [0023] “Slot sizes are variable based on the size of the compressed extents they store. For ease of addressing, slots 142 may be sector-aligned, meaning that the size of each slot is an integer multiple of a sector.” See [0063] “the file system 160 checks whether the new compressed block fits within slot 142a. As luck would have it, the new compressed block 146a2 does fit” See [0063] “After replacing the old compressed block 146a with the new compressed block 146a2,” See [0032] “the SP 120 first attempts to place the new compressed block into the same slot 142 where the previous version of data at the same address is stored. If the new compressed block fits into the existing slot 142, then the write can be completed simply by updating the data in the existing slot to reflect the new content.” See [0082] “Pausing the allocation policy stops enforcement of SS.sub.mIN when allocating new slots 142, such that slots are allocated based on the sizes of the compressed blocks and headers,”).
Regarding claim 2, Armangau teaches:
The memory device of claim 1, wherein the first slot size is greater than the data size of the compressed first data element (See [0063] “the file system 160 checks whether the new compressed block fits within slot 142a. As luck would have it, the new compressed block 146a2 does fit” See [0063] “After replacing the old compressed block 146a with the new compressed block 146a2,” See [0032] “the SP 120 first attempts to place the new compressed block into the same slot 142 where the previous version of data at the same address is stored. If the new compressed block fits into the existing slot 142, then the write can be completed simply by updating the data in the existing slot to reflect the new content”), and is less than or equal to slot sizes of other compressed zones of the compressed zones (See [0002] “Slot sizes may be sector-aligned, with each slot being an increment of one sector (512 Bytes). Thus, the size of each slot is typically the size of the compressed block plus the size of the header, rounded up to the next sector. For example, an 8-kB (kilobyte) block might compress down to 1.8 kB, for which the storage system allocates a 2-kB slot. Another 8-kB block might compress down to only 5.6 kB, for which the storage system allocates a 6-kB slot.” See [0023] “Slot sizes are variable based on the size of the compressed extents they store. For ease of addressing, slots 142 may be sector-aligned, meaning that the size of each slot is an integer multiple of a sector.” See [0033] “If the new compressed block does not fit into the existing slot, however, then an overwrite-in-place will not be possible. Instead, the SP 120 will have to find some other slot into which to place the new compressed block or it will have to allocate a new slot big enough to accommodate the new compressed block.”).
Regarding claim 9, Armangau teaches:
The memory device of claim 1, wherein the controller is configured to: in response to the memory array being determined to lack slots of the first slot size, allocate the first slot size to an unspecified compressed zone of the memory array with an unspecified slot size (See [0033] “If the new compressed block does not fit into the existing slot, however, then an overwrite-in-place will not be possible. Instead, the SP 120 will have to find some other slot into which to place the new compressed block or it will have to allocate a new slot big enough to accommodate the new compressed block. In either case, metadata updates will be needed, as the address of the data no longer maps to the same location in the file system 160 (e.g., FSBN).” See [0072] “The overwrite is performed in place if the new compressed block fits into the addressed slot 142, in the manner described in connection with FIG. 3 for compressed block 146a2. Otherwise, the SP 120 finds some other location into which to place the compressed block, such as in some other slot or in a newly allocated slot.” An unspecified slot (and thus unspecified size) in an unspecified segment may be found to store the compressed data block if the compressed data block is too large to fit into the specified slot.)
Regarding claim 11, Armangau teaches:
The memory device of claim 1, wherein the first slot comprises: a surplus space other than a space in which the compressed first data element is stored (See [0029] “As shown, the slot 142 includes space for a header 144 and space for the compressed block 146 itself. In accordance with improvements hereof, the slot 142 also includes space for a margin 148. The margin 148 provides additional space, which may not be required for a current write, but which might be needed in the future to store overwrites for which less compression is achieved.” See [0034]. See [0062] “the slot allocator 140 (FIG. 1) has provided margin 148a within slot 142a. For example, compressed block 146a might be smaller than most, such that margin 148a was required to meet the minimum slot size, SS.sub.MIN. From the standpoint of the current data, margin 148a appears to be wasted space. However, the additional space that it provides allows for substantial savings later, if a larger overwrite should occur.”).
Regarding claim 12, Armangau teaches:
The memory device of claim 1, wherein the second slot size is greater than the first slot size,
wherein the controller is configured to:
repack compressed data elements stored in the slots of the first compressed zone and store them in slots of the second compressed zone (See [0023] “Slot sizes are variable based on the size of the compressed extents they store. For ease of addressing, slots 142 may be sector-aligned, meaning that the size of each slot is an integer multiple of a sector.” See [0033] “If the new compressed block does not fit into the existing slot, however, then an overwrite-in-place will not be possible. Instead, the SP 120 will have to find some other slot into which to place the new compressed block or it will have to allocate a new slot big enough to accommodate the new compressed block.” See [0072] “The overwrite is performed in place if the new compressed block fits into the addressed slot 142, in the manner described in connection with FIG. 3 for compressed block 146a2. Otherwise, the SP 120 finds some other location into which to place the compressed block, such as in some other slot or in a newly allocated slot.”).
Claim 13 is rejected for the same reasons as claim 1. Claim 14 is rejected for the same reasons as claim 2. Claim 16 is rejected for the same reasons as claim 9.
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.
Claims 3-7, 10, 15, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Armangau in view of Chandrasekaran et al. (Hereinafter Chandrasekaran, U.S. Publication No. 2004/0054858).
Regarding claim 3, Chandrasekaran teaches:
The memory device of claim 1, wherein the first compressed zone comprises:
a first compressed subzone and a first uncompressed subzone (See Figure 1, which teaches a first compressed subzone 6 and a first uncompressed subzone 4. See [0018] “In the example of FIG. 1, a first set 4 of storage units are configured with a relatively larger size to store uncompressed data portions. A second set 6 of storage units are configured with a relatively smaller size to store compressed data portions.” See [0030] “FIG. 2 illustrates a first approach for implementing compression according to an embodiment of the invention, in which both the set 100a of uncompressed storage units and the set 100b of compressed storage units are committed apriori and consumed by the system from the file system.” See [0037] “FIG. 5 illustrates a modification to the approach of FIG. 2, in which multiple sizes of compressed blocks are employed. In particular, shown is a first set 500b of compressed blocks and a second set 500c of even smaller compressed blocks, in addition to the set 500a of uncompressed blocks.”),
wherein the slots of the first compressed zone are located in the first compressed subzone (See [0030] “For each logical database block in the file, there is an allotted slot for the block in its compressed format in set 100b and for the block in the uncompressed format in set 100a.” See [0031] “In the example of FIG. 2, it can be seen that each allocated slot in uncompressed set 100a includes an equivalent allocated slot in compressed set 100b.” See [0033] “the data is compressed (306) and the compressed data portion is stored into its allocated slot in the set of compressed data blocks (308).”).
It 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 to combine the over-allocating storage space method for compressed data of Armangau with the data compression and in-place update method of Chandrasekaran to reduce the runtime I/O demands on the disk subsystem (See [0017] of Chandrasekaran and permit in-line updates and insertions of compressed data, thus increasing storage management flexibility when performing changes to compressed data without changing the compression scheme (See [0020] of Chandrasekaran).
Regarding claim 4, Chandrasekaran teaches:
The memory device of claim 3, wherein the first compressed subzone is formed from a memory address at one end of the first compressed zone (See Figure 1, in which set 4 and set 6 are contiguous and correspond to the first compressed zone, and set 6 is the first compressed subzone at one end of the first compressed zone. See Figure 2, in which set 100a and set 100b are contiguous and correspond to the first compressed zone, and set 100b is the first compressed subzone at one end of the first compressed zone. See [0032] “the set 100b of compressed blocks is first allocated and then the set 100a of uncompressed blocks is contiguously and immediately allocated from the end of the compressed set 100b.” See [0032] “The offset of a given logical block in the uncompressed set 100a can be similarly computed using the block sequence number and uncompressed block size, starting from the end of the space reserved for the compressed blocks which is number of logical blocks in the file multiplied by the compressed block size.” See claim 9 of Chandrasekaran “The process of claim 1 in which the compressed storage units and the uncompressed storage units are contiguously allocated.”), and
the first uncompressed subzone is formed from a memory address at the other end of the first compressed zone (See Figure 1, in which set 4 and set 6 are contiguous and correspond to the first compressed zone, and set 4 is the first uncompressed subzone at the other end of the first compressed zone. See Figure 2, in which set 100a and set 100b are contiguous and correspond to the first compressed zone, and set 100a is the first uncompressed subzone at the other end of the first compressed zone. See [0032] “the set 100b of compressed blocks is first allocated and then the set 100a of uncompressed blocks is contiguously and immediately allocated from the end of the compressed set 100b.” See [0032] “The offset of a given logical block in the uncompressed set 100a can be similarly computed using the block sequence number and uncompressed block size, starting from the end of the space reserved for the compressed blocks which is number of logical blocks in the file multiplied by the compressed block size.” See claim 9 of Chandrasekaran “The process of claim 1 in which the compressed storage units and the uncompressed storage units are contiguously allocated.”).
Regarding claim 5, Armangau teaches:
in response to a data size of the compressed new first data element being greater than the first slot size, store the compressed new first data element in the first uncompressed subzone of the first compressed zone (See [0033] “If the new compressed block does not fit into the existing slot, however, then an overwrite-in-place will not be possible. Instead, the SP 120 will have to find some other slot into which to place the new compressed block or it will have to allocate a new slot big enough to accommodate the new compressed block.” See [0072] “The overwrite is performed in place if the new compressed block fits into the addressed slot 142, in the manner described in connection with FIG. 3 for compressed block 146a2. Otherwise, the SP 120 finds some other location into which to place the compressed block, such as in some other slot or in a newly allocated slot.” A newly allocated slot that does not contain compressed data, and is therefore an uncompressed slot, is used to store the compressed data block if the compressed data block is too large to fit into a specified slot.).
Armangau does not explicitly disclose what Chandrasekaran teaches:
The memory device of claim 3, wherein the controller is configured to:
decompress the compressed first data element stored in the first slot of the first compressed subzone based on a request from the processing block (See Figure 4 element 402 “Receive request for store data”. See Figure 4 element 408 “Decompress data” See claim 28 of Chandrasekaran “receiving a request to retrieve at least a portion of a discrete data item from a storage system,” See claim 28 of Chandrasekaran ”uncompressing the one or more requested granular data portions retrieved from the one or more compressed storage units”);
transmit the decompressed first data element to the processing block (See Figure 4 element 410 “Return data” See [0034] “Once the data has been suitably identified and retrieved, it is thereafter returned to the requesting entity (410).”);
in response to the decompressed first data element being changed by the processing block to a new first data element, compress the new first data element (See [0043] “When an uncompressed logical block becomes compressible after an update to the database block, the block can be stored back in the compressed block location.” See claim 28 of Chandrasekaran ”uncompressing the one or more requested granular data portions retrieved from the one or more compressed storage units”); and
It 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 to combine the over-allocating storage space method for compressed data of Armangau with the data compression and in-place update method of Chandrasekaran to reduce the runtime I/O demands on the disk subsystem (See [0017] of Chandrasekaran and permit in-line updates and insertions of compressed data, thus increasing storage management flexibility when performing changes to compressed data without changing the compression scheme (See [0020] of Chandrasekaran).
Regarding claim 6, Armangau teaches:
in response to a data size of the compressed another new first data element being less than the first slot size, store the compressed another new first data element in one of the slots of the first compressed subzone (See [0063] “the file system 160 checks whether the new compressed block fits within slot 142a. As luck would have it, the new compressed block 146a2 does fit” See [0063] “After replacing the old compressed block 146a with the new compressed block 146a2,” See [0032] “the SP 120 first attempts to place the new compressed block into the same slot 142 where the previous version of data at the same address is stored. If the new compressed block fits into the existing slot 142, then the write can be completed simply by updating the data in the existing slot to reflect the new content”).
Armangau does not explicitly disclose what Chandrasekaran teaches:
The memory device of claim 5, wherein the controller is configured to:
decompress the compressed new first data element stored in the first uncompressed subzone based on a request from the processing block (See Figure 4 element 402 “Receive request for store data”. See Figure 4 element 408 “Decompress data”);
transmit the decompressed new first data element to the processing block (See Figure 4 element 410 “Return data” See [0034] “Once the data has been suitably identified and retrieved, it is thereafter returned to the requesting entity (410).”);
in response to the new first data element being changed by the processing block to another new first data element, compress the another new first data element (See [0043] “When an uncompressed logical block becomes compressible after an update to the database block, the block can be stored back in the compressed block location.” See claim 28 of Chandrasekaran ”uncompressing the one or more requested granular data portions retrieved from the one or more compressed storage units”); and
Regarding claim 7, Armangau teaches:
The memory device of claim 3, wherein a memory address translation between a virtual memory address and a physical memory address is performed using at least one of metadata and an index table (See Figure 2 and Figure 3. See [0011] “FIGS. 2 and 3 are block diagrams showing example metadata structures” See [0004] “In addition, allocating a new slot requires making metadata changes for mapping to the new slot.” See [0023] “In the example shown, segment 168 stores compressed extents for a file 164a. The file 164a is designated by an inode (index node) 164. The segment 168 includes multiple extents of compressed data, which are stored in respective slots 142a through 1421.” See [0024] “Inode 164 also stores pointers to data blocks and/or to indirect blocks (IB s) 165, which themselves are blocks that store arrays of pointers to data of the file 164a.” See [0024] “Such leaf IBs may include pointers to other mapping metadata, such as Virtual Block Maps (VBMs) 166.” See [0026] “the data storage system 116 maps physical offsets into the LUN 170 to corresponding logical addresses into the file 164a.” See [0027] “For addressing compressed blocks, file system metadata maps logical blocks to corresponding slots 142, which reside within segments 168 in the physical address space 162”), wherein the metadata indicates a storage location of the first data element based on an identifier of the first compressed subzone and an identifier of the first uncompressed subzone (See Figure 2 and Figure 3. See [0027] “Each file within file system 160 has its own logical address range, with different logical addresses corresponding to different offsets into the respective file. Each logical address of file 164a represents a respective block of stored data, which may be compressed or uncompressed. For addressing compressed blocks, file system metadata maps logical blocks to corresponding slots 142, which reside within segments 168 in the physical address space 162.” See [0023] “In the example shown, segment 168 stores compressed extents for a file 164a. The file 164a is designated by an inode (index node) 164. The segment 168 includes multiple extents of compressed data, which are stored in respective slots 142a through 1421.” See [0030] “the file system 160 establishes and/or updates mapping metadata (e.g., inode, IBs, VBM, etc.) as needed for locating the compressed blocks 146 based on logical address.” See [0024] “Inode 164 also stores pointers to data blocks and/or to indirect blocks (IB s) 165, which themselves are blocks that store arrays of pointers to data of the file 164a.”), and the index table indicates the storage location of the first data element based on indices of the compressed zones, indices of the slots of the first compressed subzone, and indices of portions of the first uncompressed subzone (See Figure 2 and Figure 3. See [0011] “FIGS. 2 and 3 are block diagrams showing example metadata structures” See [0003] “In such arrangements, each slot corresponds to a respective address, such as a particular offset range within a LUN (Logical UNit) or a particular range within a file. Each slot holds a block's worth of data, which would be exactly one block in size if decompressed. System metadata arranges slots within segments and supports mapping of addresses to respective slots.” See [0023] “In the example shown, segment 168 stores compressed extents for a file 164a. The file 164a is designated by an inode (index node) 164. The segment 168 includes multiple extents of compressed data, which are stored in respective slots 142a through 1421.” See [0024] “Inode 164 also stores pointers to data blocks and/or to indirect blocks (IB s) 165, which themselves are blocks that store arrays of pointers to data of the file 164a.” See [0027] “Each logical address of file 164a represents a respective block of stored data, which may be compressed or uncompressed.” See [0030] “the file system 160 establishes and/or updates mapping metadata (e.g., inode, IBs, VBM, etc.) as needed for locating the compressed blocks 146 based on logical address.”). ).
Regarding claim 10, Chandrasekaran teaches:
The memory device of claim 1, wherein the controller is configured to:
before compressing a second data element received from the processing block, predict a compressibility of the second data element (See [0033] “A determination is made at 304 whether the compressed form of the data fits into a compressed block. This determination can be made by actually compressing the data and identifying the resulting compressed data size, or by estimation based upon observable characteristics of the data.” See [0045] “A determination is made at 704 whether the compressed form of the data fits into a compressed block. This determination can be made by actually compressing the data and identifying the resulting compressed data size, or by estimation based upon observable characteristics of the data.”); and
in response to the predicted compressibility being less than a utility threshold, store the second data element uncompressed, in a second uncompressed subzone of the second compressed zone (See [0033] “If the data is not compressible into the desired compressed size, then the data is stored into its corresponding slot in the set of uncompressed data blocks (310).” See [0046] “If the data is not compressible into the desired compressed size, then an identification is made of the location where the next uncompressed block can be allocated (710).” See [0046] “The uncompressed block is thereafter allocated and the data is stored into that uncompressed block (712).”).
Claim 15 is rejected for the same reasons as claim 3. Claim 17 is rejected for the same reasons as claim 10.
Claims 8 is rejected under 35 U.S.C. 103 as being unpatentable over Armangau and Chandrasekaran in view of Tremaine (U.S. Publication No. 2004/0030847).
Regarding claim 8, Tremaine teaches:
The memory device of claim 7, wherein the controller is configured to:
in response to the first data element being of a zero data type comprising only zeros, record the first data element in the index table as an identification code corresponding to the zero data type (See [0014] “The sector translation table contains compression attributes of the data blocks including a zero attribute indicating a data block of all zeros.” See [0035] “When any transfer cycle for a given data block is not zero, then the data block is a non-zero data block, otherwise the data block is a "zero" case and can be stored immediately as a specially encoded STT entry.”), without compressing or storing the first data element (See Abstract “All zero data blocks are detected to avoid standard compression/decompression overhead.” See [0016] “All non-zero data blocks are stored in the uncompressed format (bypassing the compressor,) when sufficient free memory exists.” See [0035] “All non-zero data blocks are stored in the uncompressed format (bypassing the compressor,) when sufficient free memory exists” See [0044] “Data blocks that are detected to contain all zeros skip compression at step 511”).
It 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 to combine the over-allocating storage space method for compressed data of Armangau and the data compression and in-place update method of Chandrasekaran with the zero data block compression management technique of Tremaine to avoid standard compression/decompression overhead (latency and bandwidth) when detecting "all zeros" case of data block patterns, thus permitting parallel operations on “all zeros” data blocks and other blocks (See Abstract and [0035] of Tremaine.).
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 18-20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Chandrasekaran.
Regarding claim 18, Chandrasekaran teaches:
A memory device comprising:
a controller (See processor 1407 depicted in Figure 10); and
a memory array comprising a zone including a compressed subzone having first slots of a same size and an uncompressed subzone comprising second slots of a same size (See Figure 1, which teaches a first compressed subzone 6 and a first uncompressed subzone 4. See [0030] “FIG. 2 illustrates a first approach for implementing compression according to an embodiment of the invention, in which both the set 100a of uncompressed storage units and the set 100b of compressed storage units are committed apriori and consumed by the system from the file system.” See [0030] “For each logical database block in the file, there is an allotted slot for the block in its compressed format in set 100b and for the block in the uncompressed format in set 100a.” See [0031] “In the example of FIG. 2, it can be seen that each allocated slot in uncompressed set 100a includes an equivalent allocated slot in compressed set 100b.” See Figure 2 in view of [0031], in which each allocated slot in uncompressed set 100a has a same size and each allocated slot in compressed set 100b has a same size.),
wherein the controller is configured to determine whether received data is compressible,
when it is determined that the received data is compressible, the controller is configured to compress the received data into compressed data and store the compressed data in one of the first slots (See [0033] “If the data is compressible into the required compressed size, then the data is compressed (306) and the compressed data portion is stored into its allocated slot in the set of compressed data blocks (308).” See [0045] “If the data is compressible into the required compressed size, then the data is compressed (706) and the compressed data portion is stored into its allocated slot in the set of compressed data blocks (708).”), and
when it is determined that the received data is not compressible, the controller is configured to store the received data in one of the second slots (See [0033] “If the data is not compressible into the desired compressed size, then the data is stored into its corresponding slot in the set of uncompressed data blocks (310).” See [0046] “If the data is not compressible into the desired compressed size, then an identification is made of the location where the next uncompressed block can be allocated (710).” See [0046] “The uncompressed block is thereafter allocated and the data is stored into that uncompressed block (712).”).
Regarding claim 19, Chandrasekaran teaches:
The memory device of claim 18, wherein the controller maintains metadata indicating whether the received data is stored in the compressed subzone or the uncompressed subzone (See [0037] “A flag or indicator is placed associated with each compressed block to identify whether compressed data is being stored in that compressed block.” See [0041] “compressed block 608a is also associated with a pointer 612 that points to the location of its corresponding uncompressed block 608b that has been allocated to store its associated data.” See [0053] “a first level hash is accomplished by scanning the specific directory block that is associated with a particular logical block. By accessing the directory block, a rapid determination can be made of whether a given logical block is compressed or uncompressed by scanning the directory block associated with the portion of file 900 that includes the logical block, i.e., by determining if information exists in the directory block about that logical block. If the logical block does not appear on directory list, then it can be assumed that the logical block is stored in compressed form, and a straight offset within the set of compressed blocks 903 can be made to retrieve the compressed data. If, however, the logical block appears in the directory list, then the address of the uncompressed block for that logical block is identified and followed to retrieve the stored uncompressed data” See [0059] “To retrieve data for a given logical block, a first level hash comprises accessing the directory block to determine whether the data for the logical block is compressed, as well as the possible location of that data.” See Figure 1, Figure 2 and Figure 5, in which the metadata may refer to the location/slot in which the compressed and/or uncompressed data is stored.).
Regarding claim 20, Chandrasekaran teaches:
The memory device of claim 18, wherein the controller maintains an index table indicating which of the first slots the compressed data is located when the received data is compressed and which of the second slots the received data is located when the received data is not compressed (See [0030] “For each logical database block in the file, there is an allotted slot for the block in its compressed format in set 100b and for the block in the uncompressed format in set 100a.” See [0053] “a first level hash is accomplished by scanning the specific directory block that is associated with a particular logical block. By accessing the directory block, a rapid determination can be made of whether a given logical block is compressed or uncompressed by scanning the directory block associated with the portion of file 900 that includes the logical block, i.e., by determining if information exists in the directory block about that logical block. If the logical block does not appear on directory list, then it can be assumed that the logical block is stored in compressed form, and a straight offset within the set of compressed blocks 903 can be made to retrieve the compressed data. If, however, the logical block appears in the directory list, then the address of the uncompressed block for that logical block is identified and followed to retrieve the stored uncompressed data.” A hash is computed and a directory is searched to determine the logical block location of compressed and uncompressed data, which determines the associated slot location.).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL L WESTBROOK whose telephone number is (571)270-5028. The examiner can normally be reached Mon-Fri 9am-5pm.
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, Reginald Bragdon can be reached at (571) 272-4204. 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.
/MICHAEL L WESTBROOK/Examiner, Art Unit 2139
/REGINALD G BRAGDON/Supervisory Patent Examiner, Art Unit 2139