DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This Office action is issued in response to application, 19/318,553, filed on 9/4/2025.
Claim(s) 1-22 is/are pending.
Priority
Acknowledgment is made of applicant’s claim for priority to non-provisional application, 18/648,342, filed on 4/27/2024, which claims priority to non-provisional application, 16/267,608, filed on 2/5/2019, issued as U.S. 11,977,545, which claims priority to provisional application, 62/745,787, filed on 10/18/2018.
Specification
The lengthy specification has not been checked to the extent necessary to determine the presence of all possible minor errors. Applicant’s cooperation is requested in correcting any errors of which applicant may become aware in the specification.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claim(s) 1-22 is/are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claim(s) 1-20 of copending Application No. 19/318,663 (reference application). Although the claims at issue are not identical, they are not patentably distinct from each other because they contain similar subject matter. That is, all of the limitations of the ‘663 application are contained in the instant application.
This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
Instant Application
Application: 19/318,663
1. A data input sub-system of a parallelized database system, wherein the data input sub- system comprises:
processing core resources of pluralities of processing core resources of pluralities of computing nodes of pluralities of computing devices of a computing device cluster of a plurality of computing device clusters, wherein physical data blocks of a first memory device of a first processing core resource of the processing core resources correspond to a first set of logical data block addresses, wherein the first set of logical data block addresses includes a first set of fixed size data fields, and wherein a first logical data block address of the first set of logical data block addresses includes a first subset of fixed size data fields of the first set of fixed size data fields, wherein the processing core resources are operably coupled to:
obtain divisions of data slabs of respective sub-segments of respective segments of respective segment groups of respective partitions of a dataset, wherein the respective sub- segments have been divided along columnar lines to produce the divisions of data slabs, wherein the dataset includes a plurality of rows of columnar data, wherein the columnar data includes a plurality of columns of data, and wherein a data slab of the data slabs corresponds to a column of data of the plurality of column of data, wherein a first data slab of a first division of data slabs of the divisions of data slabs is mapped to at least a portion of the first set of logical data block addresses, wherein the at least the portion of the first set of logical data block addresses includes at least a portion of the first set of fixed size data fields;
compress the divisions of data slabs to produce divisions of compressed data slabs, wherein the first data slab is compressed to produce a first compressed data slab, wherein the first compressed data slab includes first compressed data and first compression information, wherein the first compressed data slab is mapped to a reduced amount of fixed size data fields of the at least the portion of the first set of fixed size data fields; and
store a respective division of compressed data slabs of the divisions of compressed data slabs.
2. The data input sub-system of claim 1, wherein the divisions of data slabs are divisions of sorted data slabs, wherein the respective sub-segments are sorted by a respective key column to produce respective sorted sub-segments, and wherein the respective sorted sub-segments are divided along columnar lines to produce the divisions of sorted data slabs.
3. The data input sub-system of claim 1 further comprises:
wherein a second data slab of the first division of data slabs is mapped to a second at least a portion of the first set of logical data block addresses, wherein the second at least the portion of the first set of logical data block addresses includes a second at least a portion of the first set of fixed size data fields.
4. The data input sub-system of claim 3 further comprises:
wherein the second data slab is compressed to produce a second compressed data slab, wherein the second compressed data slab includes second compressed data and second compression information, wherein the second compressed data slab is mapped to a reduced amount of fixed size data fields of the second at least the portion of the first set of fixed size data fields.
5. The data input sub-system of claim 3 further comprises:
wherein the first data slab and the second data slab of the first division of data slabs is compressed to produce the first compressed data slab, wherein the first compressed data slab includes combined first and second compressed data and combined first and second compression information.
6. The data input sub-system of claim 1, wherein the first compression information comprises details regarding a compression scheme used to compress the first data slab.
7. The data input sub-system of claim 1, wherein the first compression information is positioned before the first compressed data in the first compressed data slab.
8. The data input sub-system of claim 1, wherein the first compression information is positioned after the first compressed data in the first compressed data slab.
9. The data input sub-system of claim 1, wherein the processing core resources are further operable to:
include footer information in one or more respective available fixed size data fields positioned at an end of a respective logical data block address of a respective set of logical data block addresses.
10. The data input sub-system of claim 9, wherein the processing core resources are further operable to:
include the footer information in one or more respective fixed size data fields positioned after the respective logical data block address of the respective set of logical data block addresses.
11. The data input sub-system of claim 10, wherein the footer information comprises one or more of a portion of raw uncompressed data;
compression scheme information for compressed data mapped to the respective logical data block address;
identity of the compressed data mapped to the respective logical data block address;
a count of compressed data blocks mapped to the respective logical data block address, wherein the first data slab includes a set of data blocks, and wherein the first compression data includes a set of compressed data blocks;
size of a compressed data slab mapped to the respective logical data block address;
size of corresponding compression information of a corresponding compressed data slab mapped to the respective logical data block address; and
a number of entries in the corresponding compression information.
12. Same as 1.
13. Same as 2.
14. Same as 3.
15. Same as 4.
16. Same as 5.
17. Same as 6.
18. Same as 7.
19. Same as 8.
20. Same as 9.
21. Same as 10.
22. Same as 11.
1. A data input sub-system of a parallelized database system, wherein the data input sub-system comprises:
processing core resources of pluralities of processing core resources of pluralities of computing nodes of pluralities of computing devices of a computing device cluster of a plurality of computing device clusters are operably coupled to:
obtain divisions of data slabs of respective sub-segments of respective segments of respective segment groups of respective partitions of a dataset, wherein the respective sub-segments have been divided along columnar lines to produce the divisions of data slabs, wherein the dataset includes a plurality of rows of columnar data, wherein columnar data includes a plurality of columns of data, and wherein a data slab of the data slabs corresponds to a column of data of the plurality of column of data;
compress the divisions of data slabs using a null elimination compression scheme to produce divisions of compressed data slabs, wherein a first data slab of a first division of data slabs of the divisions of data slabs is compressed using the null elimination compression scheme to produce a first compressed data slab, wherein the first compressed data slab includes first compressed data and first compression information; and
store a respective division of compressed data slabs of the divisions of compressed data slabs.
2. The data input sub-system of claim 1, wherein the divisions of data slabs are divisions of sorted data slabs, wherein the respective sub-segments are sorted by a respective key column to produce respective sorted sub-segments, and wherein the respective sorted sub-segments are divided along columnar lines to produce the divisions of sorted data slabs.
3. The data input sub-system of claim 1, wherein the processing core resources are further operable to:
determine to compress the divisions of data slabs using the null elimination compression scheme by identifying a threshold amount of null data values interspersed between not-null data values of data of the divisions of data slabs.
4. The data input sub-system of claim 1, wherein the processing core resources are operable to compress the divisions of data slabs using the null elimination compression scheme by:
for a data slab of the divisions of data slabs:
assigning a first data flag to not-null data values of data of the data slab;
assigning a second data flag to null data values of the data; and
eliminating the null data values from the data slab to produce a compressed data slab, wherein compressed data of the compressed data slab includes not-null data values of the data slab, and compression information of the compressed data slab includes an ordered list of first and second data flags that were assigned to data values of the data slab.
5. The data input sub-system of claim 1, wherein the processing core resources are operable to compress the divisions of data slabs using the null elimination compression scheme by:
for a data slab of the divisions of data slabs:
assigning position numbers to data values of data of the data slab; and
eliminating null data values from the divisions of data slabs to produce a compressed data slab, wherein compressed data of the compressed data slab includes not-null data values of the data slab, and compression information of the compressed data slab includes a list of position numbers corresponding to the not-null data values.
6. The data input sub-system of claim 1 further comprises:
wherein physical data blocks of a first memory device of a first processing core resource of the processing core resources correspond to a first set of logical data block addresses, wherein the first set of logical data block addresses includes a first set of fixed size data fields, and wherein a first logical data block address of the first set of logical data block addresses includes a first subset of fixed size data fields of the first set of fixed size data fields;
wherein the first data slab is mapped to at least a portion of the first set of logical data block addresses, wherein the at least the portion of the first set of logical data block addresses includes at least a portion of the first set of fixed size data fields; and
wherein the first compressed data slab is mapped to a reduced amount of fixed size data fields of the at least the portion of the first set of fixed size data fields.
7. The data input sub-system of claim 6 further comprises:
wherein a second data slab of the first division of data slabs is mapped to a second at least a portion of the first set of logical data block addresses, wherein the second at least the portion of the first set of logical data block addresses includes a second at least a portion of the first set of fixed size data fields.
8. The data input sub-system of claim 7 further comprises:
wherein the second data slab is compressed using the null elimination compression scheme to produce a second compressed data slab, wherein the second compressed data slab includes second compressed data and second compression information, wherein the second compressed data slab is mapped to a reduced amount of fixed size data fields of the second at least the portion of the first set of fixed size data fields.
9. The data input sub-system of claim 8, wherein the processing core resources are further operable to:
include footer information in one or more respective fixed size data fields positioned after respective logical data block address of respective set of logical data block addresses.
10. The data input sub-system of claim 9, wherein the footer information comprises one or more of:
a portion of raw uncompressed data;
null elimination compression scheme information for compressed data mapped to the respective logical data block address;
identity of the compressed data mapped to the respective logical data block address;
a count of compressed data blocks mapped to the respective logical data block address, wherein the first data slab includes a set of data blocks, and wherein the first compression data includes a set of compressed data blocks;
size of a compressed data slab mapped to the respective logical data block address;
size of compression information of a corresponding compressed data slab mapped to the respective logical data block address; and
a number of entries in the corresponding compression information.
11. Same as 1.
12. Same as 2.
13. Same as 3.
14. Same as 4.
15. Same as 5.
16. Same as 6.
17. Same as 7.
18. Same as 8.
19. Same as 9.
20. Same as 10.
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-22 is/are rejected under 35 U.S.C. 103 as being unpatentable over Gupta et al., US 11,567,972 B1 (hereinafter “Gupta”) in view of Winn, US 2014/0325177 A1 (hereinafter “Winn”).
Claims 1 and 12
Gupta discloses a data input sub-system of a parallelized database system (Gupta, Fig. 2, see database system depicted; and Gupta, Col. 16, lines 32-42, see parallelize the workload to process queries), wherein the data input sub-system comprises:
processing core resources of pluralities of processing core resources of pluralities of computing nodes of pluralities of computing devices of a computing device cluster of a plurality of computing device clusters (Gupta, Col. 9, line 56-Col. 10, line 10, see the storage cluster for a data storage service like a data warehouse service … . As illustrated in this example, a storage cluster 300 may include a leader node 320 [i.e., corresponds to the “processing core resources … of a computing device cluster”] and storage nodes 330, 340, and 350 [i.e., “pluralities of computing nodes of pluralities of computing devices”], which may communicate with each other over an interconnect 360. Leader node 320 may maintain slab mapping information 325 for executing queries on storage cluster 300. For instance, slab mapping information may be used to identify which storage nodes may store a storage slab; and Gupta, Col. 10, line 50-Col. 11, line 3, see storage cluster 300 [i.e., corresponds to “processing core resources … of a computing device cluster”] may also include storage nodes, such as storage nodes 330, 340, and 350 [i.e., “pluralities of computing nodes of pluralities of computing devices”]. These one or more storage nodes (sometimes referred to as compute nodes), may for example, be implemented on servers or other computing devices, such as those described below with regard to computer system 2000 in FIG. 11, and each may include individual query processing “slices” defined, for example, for each core of a server's multi-core processor. Storage nodes may perform processing of database operations, such as queries, based on instructions sent to storage nodes 330, 340, and 350 from leader node 320; and Gupta, Fig. 3, see leader node 320 [i.e., corresponds to “processing core resources … of a computing device cluster”] and storage nodes 330, 340 … 350 [i.e., “pluralities of computing nodes of pluralities of computing devices”]), wherein physical data blocks of a first memory device of a first processing core resource of the processing core resources (Gupta, Col. 9, lines 13-28, see block-based storage; Gupta, Col. 11, lines 17-38, see each of compute nodes includes metadata for the blocks stored on the node. In at least some 25 embodiments this block metadata may be aggregated together into a superblock data structure, which is a data structure (e.g., an array of data) whose entries store information (e.g., metadata about each of the storage slabs and data blocks stored on that node (i.e., one entry per data block); and Gupta, Col. 18, line 58-Col. 19, line 12, see system memory 2020) includes a first set of fixed size data fields (See Gupta, Col. 4, lines 3-20 below), and includes a first subset of fixed size data fields of the first set of fixed size data fields (Gupta, Col. 4, lines 3-20, see allowing for variably sized storage slabs may keep slab storage overhead efficient (as storage locations, such as storage nodes, may store a storage slab and any ancestors of the storage at the same storage location). Variably sized storage slabs may also allow for incremental size changes to the number of storage locations [i.e., see the ability to change the size of storage slabs, which means there is the ability to set a fixed size for data fields], such as the number of storage nodes in a storage cluster, to be as efficient as possible), wherein the processing core resources are operably coupled to:
obtain divisions of data slabs of respective sub-segments of respective segments of respective segment groups of respective partitions of a dataset (Gupta, Col. 3, lines 18-48, see when storage slab 102a became full, then storage slabs 102b, 102c, 102d through 102e may be created. The ranges of distribution values assigned to the nodes of the tree may be divided, split, or otherwise determined resulting in a disjointed partition of the range of the parent node (e.g., slab 102a). For example, storage slab 102b has a range 104b including distribution values A through F, storage slab 102c has a range 104c including distribution values G through L, storage slab 102d has a range 104d including distribution values M through S, and storage slab 102e has a range 104e including distribution values T through Z [i.e., see the value ranges of the data slab are divided into different partitioned datasets, which correspond to the “respective segments of respective segment groups of respective partitions of a dataset”]. When a storage slab in this second level of storage slabs in the tree becomes full, then an additional level of storage slabs may be created for the full storage slab (e.g., storage slabs 102f, 102g, 102h through 102i) and the distribution value ranges may be split again (e.g., range 106f, including values A through Az, range 106g, including values B through C, range 106h, including values D through Dz, and range 106i, including values E through F) [i.e., see the value ranges of the divided data slab are divided into additional partitioned datasets, which correspond to the “respective sub-segments of respective segments of respective segment groups of respective partitions of a dataset”]), wherein the respective sub-segments have been divided along columnar lines to produce the divisions of data slabs (Gupta, Col. 2, line 61-Col. 3, line 17, see data, such as a table of items (e.g., rows including different field values for different columns), may be stored in storage slabs. Rows or other items of a table may be grouped into collections stored in a storage slab, like items 104 stored in storage slab 102. Slabs 102 may be treated as an atomic unit for mapping items 104 to storage locations; and Gupta, Col. 3, line 56-Col. 4, line 2, see a distribution scheme for assigning items to storage slabs may be implemented in many ways. For example, in at least some embodiments, a hash function may be applied to a specified value for each item (e.g., a specified column) that generates a hash value based on the column [i.e., corresponds to being “divided along columnar lines”]. The item may then be placed into the slab that is mapped to a range of hash values that includes the hash value. Various other types of distribution schemes, such as range partitioning or wrap-around range partitioning based on one or a composite of field (e.g., column) values may be implemented), wherein the dataset includes a plurality of rows of columnar data (Gupta, Col. 2, line 61-Col. 3, line 17, see rows or other items of a table may be grouped into collections stored in a storage slab, like items 104 stored in storage slab 102. Slabs 102 may be treated as an atomic unit for mapping items 104 to storage locations), wherein the columnar data includes a plurality of columns of data (Gupta, Col. 2, line 61-Col. 3, line 17, see data, such as a table of items (e.g., rows including different field values for different columns), may be stored in storage slabs), and wherein a data slab of the data slabs corresponds to a column of data of the plurality of column of data (Gupta, Col. 3, line 56-Col. 4, line 2, see a distribution scheme for assigning items to storage slabs may be implemented in many ways. For example, in at least some embodiments, a hash function may be applied to a specified value for each item (e.g., a specified column) that generates a hash value based on the column. The item may then be placed into the slab that is mapped to a range of hash values that includes the hash value), wherein a first data slab of a first division of data slabs of the divisions of data slabs is mapped (Gupta, Col. 3, line 56-Col. 4, line 2, see a distribution scheme for assigning items to storage slabs may be implemented in many ways. For example, in at least some embodiments, a hash function may be applied to a specified value for each item (e.g., a specified column) that generates a hash value based on the column. The item may then be placed into the slab that is mapped to a range of hash values that includes the hash value. Various other types of distribution schemes, such as range partitioning [i.e., corresponds to “mapping”] or wrap-around range partitioning based on one or a composite of field (e.g., column) values may be implemented) wherein includes at least a portion of the first set of fixed size data fields (Gupta, Col. 3, line 56-Col. 4, line 2, see a distribution scheme for assigning items to storage slabs may be implemented in many ways. For example, in at least some embodiments, a hash function may be applied to a specified value for each item (e.g., a specified column) that generates a hash value based on the column. The item may then be placed into the slab that is mapped to a range of hash values that includes the hash value. Various other types of distribution schemes, such as range partitioning or wrap-around range partitioning based on one or a composite of field (e.g., column) [i.e., values are assigned based on the field, which has a fixed size] values may be implemented);
compress the divisions of data slabs to produce divisions of compressed data slabs, wherein the first data slab is compressed to produce a first compressed data slab, wherein the first compressed data slab includes first compressed data and first compression information (Gupta, Col. 9, line 56-Col. 10, line 10, see storage slabs; and Gupta, Col. 7, line 43-Col. 8, line 16, see the disk requirements may be further reduced using compression methods that are matched to the columnar storage data type. For example, since each block contains uniform data (i.e., column field values that are all of the same data type), disk storage and retrieval requirements may be further reduced by applying a compression method that is best suited to the particular column data type. … When queries are received, mapping information, such as may be maintained in a superblock as discussed below may be utilized to locate the data values likely stored in data blocks of the columnar relational database table [i.e., corresponds to the “first compression information”], which may be used to determine data blocks that do not need to be read when responding to a query), wherein the first compressed data slab is mapped to a reduced amount of fixed size data fields of the at least the portion of the first set of fixed size data fields (Gupta, Col. 7, line 43-Col. 8, line 16, see applying a compression method that is best suited to the particular column data type. In some embodiments, the savings in space for storing data blocks containing only field values of a single column on disk may translate into savings in space when retrieving and then storing that data in system memory (e.g., when analyzing or otherwise processing the retrieved data) [i.e., see, in the example, data is divided into data of only a single column, which is less than data divided over multiple columns]); and
store a respective division of compressed data slabs of the divisions of compressed data slabs (Gupta, Fig. 8, see 820 “Identify a storage slab based on distribution value(s) determined for the item(s) according to a distribution scheme for the table assigning ranges of distribution values to storage slabs mapped to different nodes of a tree” and 832 “Add item(s) to the identified storage slab”).
Gupta does not appear to explicitly disclose wherein physical data blocks correspond to a first set of logical data block addresses;
mapped to at least a portion of the first set of logical data block addresses.
Winn discloses wherein physical data blocks correspond to a first set of logical data block addresses (Winn, [0027], see memory made of blocks and where a memory address can refer to either a block’s physical address or logical address);
mapped to at least a portion of the first set of logical data block addresses (Winn, [0039], see memory allocation request; and Winn, [0040], see setting the memory block [i.e., which includes setting the logical data block address] for the memory allocation request).
Gupta and Winn are analogous art because they are from the same field of endeavor of storing and retrieving data.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention, having the teachings of Gupta and Winn before him/her, to modify the storage of Gupta to include the addressing of Winn because it would improve performance.
The suggestion/motivation for doing so would have been to be able to efficiently use memory, see Winn, [0006].
Therefore, it would have been obvious to combine Winn with Gupta to obtain the invention as specified in the instant claim(s).
Claim(s) 12 recite(s) similar limitations to claim 1 and is/are rejected under the same rationale.
With respect to claim 12, Gupta discloses a computer readable memory device comprises:
a first memory section (Gupta, Col. 18, line 58-Col. 19, line 12, see system memory 2020);
a second memory section (Gupta, Col. 18, line 58-Col. 19, line 12, see system memory 2020); and
a third memory section (Gupta, Col. 18, line 58-Col. 19, line 12, see system memory 2020).
Claims 2 and 13
With respect to claims 2 and 13, the combination of Gupta and Winn discloses wherein the divisions of data slabs are divisions of sorted data slabs, wherein the respective sub-segments are sorted by a respective key column to produce respective sorted sub-segments (Gupta, Fig. 5, see sorted items 510 in slab 500 [i.e., data in slabs are sorted]; and Gupta, Col. 15, lines 23-46, see keys are hashed for distribution), and wherein the respective sorted sub-segments are divided along columnar lines to produce the divisions of sorted data slabs (Gupta, Col. 2, line 61-Col. 3, line 17, see data, such as a table of items (e.g., rows including different field values for different columns), may be stored in storage slabs. Rows or other items of a table may be grouped into collections stored in a storage slab, like items 104 stored in storage slab 102. Slabs 102 may be treated as an atomic unit for mapping items 104 to storage locations; and Gupta, Col. 3, line 56-Col. 4, line 2, see a distribution scheme for assigning items to storage slabs may be implemented in many ways. For example, in at least some embodiments, a hash function may be applied to a specified value for each item (e.g., a specified column) that generates a hash value based on the column [i.e., corresponds to being “divided along columnar lines”]. The item may then be placed into the slab that is mapped to a range of hash values that includes the hash value. Various other types of distribution schemes, such as range partitioning or wrap-around range partitioning based on one or a composite of field (e.g., column) values may be implemented).
Claims 3 and 14
With respect to claims 3 and 14, the combination of Gupta and Winn discloses further comprises:
wherein a second data slab of the first division of data slabs is mapped to a second at least a portion of the first set of logical data block addresses (Gupta, Col. 2, line 61-Col. 3, line 17, see data stored in slabs; and Winn, [0039], see memory allocation request; and Winn, [0040], see setting the memory block [i.e., which includes setting the logical data block address] for the memory allocation request), wherein the second at least the portion of the first set of logical data block addresses includes a second at least a portion of the first set of fixed size data fields (Winn, [0027], see memory made of blocks including a list of fixed sized blocks including fields and where a memory address can refer to either a block’s physical address or logical address).
Claims 4 and 15
With respect to claims 4 and 15, the combination of Gupta and Winn discloses further comprises:
wherein the second data slab is compressed to produce a second compressed data slab, wherein the second compressed data slab includes second compressed data and second compression information (Gupta, Col. 9, line 56-Col. 10, line 10, see storage slabs; and Gupta, Col. 7, line 43-Col. 8, line 16, see compressing columnar storage including mapping formation to locate the data values stored in the data blocks [i.e., corresponds to the “second compression information”]), wherein the second compressed data slab is mapped to a reduced amount of fixed size data fields of the second at least the portion of the first set of fixed size data fields (Gupta, Col. 7, line 43-Col. 8, line 16, see applying a compression method that is best suited to the particular column data type. In some embodiments, the savings in space for storing data blocks containing only field values of a single column on disk may translate into savings in space when retrieving and then storing that data in system memory (e.g., when analyzing or otherwise processing the retrieved data) [i.e., see, in the example, data is divided into data of only a single column, which is less than data divided over multiple columns]).
Claims 5 and 16
With respect to claims 5 and 16, the combination of Gupta and Winn discloses further comprises:
wherein the first data slab and the second data slab of the first division of data slabs is compressed to produce the first compressed data slab, wherein the first compressed data slab includes combined first and second compressed data and combined first and second compression information (Gupta, Col. 9, line 56-Col. 10, line 10, see storage slabs; and Gupta, Col. 7, line 43-Col. 8, line 16, see compressing columnar storage including mapping formation to locate the data values stored in the data blocks [i.e., corresponds to the “compression information”]; and Gupta, Fig. 1, see items 104a in slab 102a is distributed among slabs 102b, 102c, 102d … 102e [i.e., see the slab divided out into smaller slabs]).
Claims 6 and 17
With respect to claims 6 and 17, the combination of Gupta and Winn discloses wherein the first compression information comprises details regarding a compression scheme used to compress the first data slab (Gupta, Col. 7, line 43-Col. 8, line 16, see the compression method).
Claims 7 and 18
With respect to claims 7 and 18, the combination of Gupta and Winn discloses wherein the first compression information is positioned before the first compressed data in the first compressed data slab (Gupta, Col. 7, line 43-Col. 8, line 16, see the mapping information [i.e., corresponds to the “compression information”]; and Winn, [0006], see header fields [i.e., information presented ahead of other data]).
Claims 8 and 19
With respect to claims 8 and 19, the combination of Gupta and Winn discloses wherein the first compression information is positioned after the first compressed data in the first compressed data slab (Gupta, Col. 7, line 43-Col. 8, line 16, see the mapping information [i.e., corresponds to the “compression information”]; and Winn, Fig. 1B, see metadata stored after the data block 130 in data structure 140).
Claims 9 and 20
With respect to claims 9 and 20, the combination of Gupta and Winn discloses wherein the processing core resources are further operable to:
include footer information in one or more respective available fixed size data fields positioned at an end of a respective logical data block address of a respective set of logical data block addresses (Gupta, Col. 4, lines 3-20, see allowing for variably sized storage slabs may keep slab storage overhead efficient (as storage locations, such as storage nodes, may store a storage slab and any ancestors of the storage at the same storage location). Variably sized storage slabs may also allow for incremental size changes to the number of storage locations [i.e., see the ability to change the size of storage slabs, which means there is the ability to set a fixed size for data fields], such as the number of storage nodes in a storage cluster, to be as efficient as possible; and Gupta, Col. 7, line 43-Col. 8, line 16, see the mapping information [i.e., corresponds to the “compression information”]; and Winn, Fig. 1B, see metadata stored after the data block 130 in data structure 140).
Claims 10 and 21
With respect to claims 10 and 21, the combination of Gupta and Winn discloses wherein the processing core resources are further operable to:
include the footer information in one or more respective fixed size data fields positioned after the respective logical data block address of the respective set of logical data block addresses (Gupta, Col. 4, lines 3-20, see allowing for variably sized storage slabs may keep slab storage overhead efficient (as storage locations, such as storage nodes, may store a storage slab and any ancestors of the storage at the same storage location). Variably sized storage slabs may also allow for incremental size changes to the number of storage locations [i.e., see the ability to change the size of storage slabs, which means there is the ability to set a fixed size for data fields], such as the number of storage nodes in a storage cluster, to be as efficient as possible; Gupta, Col. 7, line 43-Col. 8, line 16, see the mapping information [i.e., corresponds to the “compression information”]; and Winn, Fig. 1B, see metadata stored after the data block 130 in data structure 140).
Claims 11 and 22
With respect to claims 11 and 22, the combination of Gupta and Winn discloses wherein the footer information comprises one or more of a portion of raw uncompressed data;
compression scheme information for compressed data mapped to the respective logical data block address;
identity of the compressed data mapped to the respective logical data block address (Gupta, Col. 7, line 43-Col. 8, line 16, see the compressing data; and Gupta, Col. 4, lines 41-50, see mapping information identifies the storage locations of storage slabs in a data store [i.e., where there must be some identification/link between the storage location and what is stored there]);
a count of compressed data blocks mapped to the respective logical data block address, wherein the first data slab includes a set of data blocks, and wherein the first compression data includes a set of compressed data blocks;
size of a compressed data slab mapped to the respective logical data block address;
size of corresponding compression information of a corresponding compressed data slab mapped to the respective logical data block address; and
a number of entries in the corresponding compression information (Winn, [0023], see a fixed size list [i.e., one knows how many entries]; and Gupta, Col. 7, line 43-Col. 8, line 16, see the compressing data).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
– Bronnikov, 2020/0019343 for a durable low latency system architecture;
– Barsness et al., 2008/0059408 for managing execution of a query against selected data partitions of a partitioned database;
– Naidu et al., 2013/0124466 for a data processing service;
– Shivarudraiah et al., 2016/0092545 for generating partition-based splits in a massively parallel or distributed database environment;
– Bequet et al., 2020/0026732 for many tasks computing with a distributed file system;
– Arnold et al., 2026/0003867 for null elimination data slab compression scheme of a parallelized database system;
– Moog, 7536398 for online organization of data sets;
– Arnold et al., JP 2017-505936 for hosting an in-memory database; and
– Gupta et al., AU 2013347798 for streaming restore of a database from a backup.
Point of Contact
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HUBERT G CHEUNG whose telephone number is (571) 270-1396. The examiner can normally be reached M-R 8:00A-5:00P EST; alt. F 8:00A-4:00P EST.
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, Apu Mofiz can be reached at (571) 272-4080. 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.
HUBERT G. CHEUNG
Assistant Examiner
Art Unit 2161
Examiner: Hubert Cheung
/Hubert Cheung/Assistant Examiner, Art Unit 2161Date: July 21, 2026
/APU M MOFIZ/Supervisory Patent Examiner, Art Unit 2161
Prosecution Insights