DETAILED ACTION
Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
2. A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on February 11, 2026 has been entered.
Response to Amendment
3. This Office Action is in response to the applicant request for continued examination filed on February 11, 2026.
4. Claims 1-20 are pending. Claims 1, 11, and 18 are in independent form.5. Claims 1, 11, and 18 are amended.
Response to Arguments
6. Applicant’s arguments, see “The Rejections of Claims Under § 103” filed on January 13, 2026, have been carefully considered. Applicant’s arguments is based on the newly added limitation and Ghosh’s teaching. Now examiner withdraw the Ghosh reference and applied a new reference to teach the newly added limitation.
Claim Rejections - 35 USC § 103
7. In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
8. 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.
9. The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
10. Claims 1-2, 5-7, 10-12, and 15-20 are rejected under 35 U.S.C. 103 as being unpatentable over Das et al. U.S. 2016/0350347 A1 (hereinafter Das) in view of Huang et al. U.S. Patent 10,979,520 B2 (hereinafter Huang) further in view of Halterman et al. U.S. 2018/0203899 A1 (hereinafter Halterman).
Regarding claim 1, Das discloses a system comprising: a memory that stores instructions (Das [0162] e.g., “ Computer system 700 also includes a main memory 706… storing information and instructions”, see also [Figure 7, element 706]); and one or more processors configured by the instructions to perform operations (Das [0162] e.g., “processor 704, …to perform the operations”, see also [Figure 7, element 704]) comprising: accessing a first operation for a table of a database, the first operation for the table comprising a filter on a first column of the table (Das [0024] e.g., “A database server receives a query with a predicate. Each condition of the predicate may be evaluated against corresponding in-memory columnar units (CUs)”, see also [0048] e.g., “The estimator component computes predicate selectivities (which help determine the resulting cardinalities of scans, joins, and aggregations)”, see also [0063] e.g., “a>5 and b=7 and c<=10” the predicate tree includes leaf nodes that are filter predicates on Columns A and B of the table. Theses collectively teach accessing a database operation (e.g., query scan) involving a filter on a specific column), [the table being stored in a plurality of micro-partitions, a first micro-partition of the plurality of micro-partitions of the table being compressed according to a first compression algorithm and a second micro-partition of the plurality of micro-partitions of the table being compressed according to a second compression algorithm]; receiving a query comprising multiple filters comprising the filter (Das [0062] e.g., “SELECT a, b, c, d, FROM Table200 WHERE”. A query include WHERE clause predicate multiple conditions. See also [0063] e.g., “a>5 and b=7 and c<=10”. The predicate tree includes filter predicates on columns A and B. See also [0070]-[0075] shows a complex expression involving multiple conditions such as (a=3 AND c >-5 AND d < = 10 AND b > 20). Thus, the system receives a query with multiple filters); determining a type of filtering operation associated with the filter (Das [0025] e.g., “… predicates of a query that can be evaluated directly … are identified during query compilation … Predicates in the query that cannot be pushed-down to the in-memory scan can be evaluated as usual”. Das distinguishes among: simple predicates, complex predicates, pushable predicates, and non-pushable predicates. This is very close to: “determining a type of filtering operation associated with the filter); and in response to selecting to apply the filter by the central server, transmitting a request for unfiltered data from the database and applying the filter to the unfiltered data received from the database, the request excluding the filter (Das [0025] e.g., “Predicates in the query that cannot be pushed-down to the in-memory scan can be evaluated as usual” see also [0026] e.g., “There are certain types of complex predicates that cannot be pushed down directly to the in-memory scan… The implied predicate is then pushed-down to the in-memory scan. ... even though the query predicate itself cannot be pushed down to the in-memory scan”. Das expressly teaches a predicate may not be pushed down, the database scan proceeds without evaluating that predicate, and the predicate remains for later evaluation. If a predicate is not pushed down, a) the lower-level database scan does not evaluate that predicate, b) data is returned form the scan, c) the retained predicate is evaluated later by the execution engine. Thus, the lower-level request effectively excludes the retained predicate). Das does not explicitly disclose: the table being stored in a plurality of micro-partitions, a first micro-partition of the plurality of micro-partitions of the table being compressed according to a first compression algorithm and a second micro-partition of the plurality of micro-partitions of the table being compressed according to a second compression algorithm; selecting whether to apply the filter within the database or by central server based on the type of filtering operation associated with the filter, the type of filtering operation determining whether the filter is applied within the database or by the central server, the selecting whether to apply the filter being performed on a filter-by-filter basis for each of the multiple filters, a first filter being applied by the database and a second filter being applied by the central server. Huang discloses: the table being stored in a plurality of micro-partitions (Huang [col. 19, lines 50 – col. 20, lines 4] e.g., “In a distributed database system, the “class information table” is divided into two different parts separately stored in a first DN and a second DN. … The “student information table” may be divided into two different parts separately stored in the first DN and the second DN”. Huang teaches dividing a table into multiple portions distrusted across storage nodes. See also [col. 5, lines 55-61] e.g., “when determining that the data type of the parameters of the column is a data type that supports a dictionary compression algorithm”. These sections involving partition storage (i.e., micro-partitions), use of different compression algorithms per column or partition (e.g., RLE and dictionary) and dynamic selection of compression algorithm based on content/type)) a first micro-partition of the plurality of micro-partitions of the table being compressed according to a first compression algorithm (Huang [col. 20, lines 35-45] e.g., “ The first DN determines a first compression algorithm corresponding to the “class information table stored in the first DN” … The first DN compresses the first data using the first compression algorithm…”. This supports first DN stores a first portion of the table and first compression algorithm applied to that portion), and a second micro-partition of the plurality of micro-partitions of the table being compressed according to a second compression algorithm (Huang [col. 21, lines 10-31] e.g., “The second DN receives the query command sent by the CN. The second DN determines second data: a “class information table stored in the second DN” … The second DN compresses, using the second compression algorithm”. This supports Second DN stores a second portion of the table and Second compression algorithm applied to that portion. See also [Abstract] e.g., “…the DN determines, according to a data type of the parameters of the column and the distribution rule of the parameters in the column, a compression algorithm corresponding to the column”, and see [col. 24, lines 1-8, e.g., ““when determining that the data type …supports an RLE compression algorithm … determine that the compression algorithm corresponding to the column is the dictionary compression algorithm”. This supports that different portions/columns may use different compression techniques and compression is selected according to characteristics of the data).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the functionality of data transmission method and apparatus taught by Huang, in the techniques for evaluating query predicated during in-memory table scans, taught by Das, to yield predictable result through flexible node=level data handling, the system can transmit data to either a data node (DN) or a central node (CN), depending on processing requirements, thereby facilitation efficient data transmission across needs in a distributed database. The combined teachings of Das and Huang does not explicitly disclose: selecting whether to apply the filter within the database or by central server based on the type of filtering operation associated with the filter, the type of filtering operation determining whether the filter is applied within the database or by the central server, the selecting whether to apply the filter being performed on a filter-by-filter basis for each of the multiple filters, a first filter being applied by the database and a second filter being applied by the central server. Halterman discloses selecting whether to apply the filter within the database or by central server based on the type of filtering operation associated with the filter (Halterman [0020] e.g., “The EPO system determines whether each data source supports the target feature and thus whether an expression with the target feature can be pushed down to the data source”, see also [0023] e.g., “If, however, a data source does not support a target feature, the EPO system generates a query without the expression … The federation engine then generates, from the initial query results, query results based on evaluation of the expression”. Thus, Halterman teaches determining whether a filtering expression/operator is evaluated at the data source (database) or by the federation engine (central server) based on the target feature/operator associated with the filter), the type of filtering operation determining whether the filter is applied within the database or by the central server (Halterman [0056] e.g., “When the data source supports the operator of the expression … [the system] generates a query for the data source that includes the converted expression so that the expression can be evaluated at the data source” and “When the data source does not support the operator of the expression, the method generates a query … that does not include the expression so that the expression is not evaluated at the data source” further, “… for each of the plurality of data sources that supports the operator of the expression … [the system] evaluates the expression on the received query results” Accordingly, the operator/filter type is used to determine whether filtering occurs at the database or at the federation engine), the selecting whether to apply the filter being performed on a filter-by-filter basis for each of the multiple filters (Halterman [0039] e.g., “… data source B does not support the greater-than operator. As a result, the EPO system only pushes down project expressions and a join expression to data source B. The filter expression … was not pushed down” and “… the greater-than operator needs to be evaluated by the EPO system for data source B, but not for data source A”. see also [0060] e.g., “When the data source supports a target feature … [the system] submits … a query with the expression…”. Thus, individual expression/operators are separately evaluated and selectively pushed down or retained for federation-engine processing), a first filter being applied by the database and a second filter being applied by the central server (Halterman [0023] e.g., “If, … a data source does not support a target feature, the EPO system generates a query without the expression” and “The federation engine then generates, from the initial query results, query results based on evaluation of the expression”. See also [0039] e.g., “The filter expression … was not pushed down, and the row-level expression thus needs to be evaluated by the federation engine against the initial query results returned by data source B” while for another data source “… the EPO system for data source B, but not for data source A”. Thus, Halterman teaches one filtering expression being evaluated at a data source/database and another filtering expression being evaluated at the federation engine/central server);
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the expression pushdown optimization system taught by Halterman, in the combined teachings of Das and Huang, to yield predictable result of enabling increasing pushing down of expressions and reducing computational and communication resources needed to process a target query. The method enables reducing amount of data that needs to be extracted and transmitted from resources.
Claims 11 and 18 incorporates substantively all the limitations of claim 1 in a machine-storage medium (Das [0165] e.g., “…storage medium…”, see also [Figure 7, element 710]), and a method (Das [0048] e.g., “..operation method…”) and rejected under the rationale.
Regarding claim 2, the proposed combination of Das, Huang, and Halterman teaches the system of claim 1, the operations comprising:
decompressing, in the first micro-partition, the first column of the table excluding decompressing other columns of the table in the first micro-partition ((Das [0103] e.g., “In some cases, the CU may need to be decompressed in order to evaluate the condition of the predicate against the data items in the CU…The data items are decompressed, and the condition is then applied to each data item in CU c1” and “For this particular example, the compression technique could be using an order-preserving dictionary, in which case no decompression is needed. However, the example is illustrative of decompression”. This implies evaluating each data item after decompression and selectively keeping only those matching the predicate – i.e., row responsive to the filter. See also [0024] e.g., “Each CU has storage index …compared with single column conditions …then data items from the related CUs may be filtered from further scanning…pushing the predicate down to the scan”. This teaches that filtering is applied before decompressing and column-level conditions determine what gets scanned and decompressed)); and
decompressing, based on the filter on the first column, rows of the first micro-partition of the table that contains data responsive to the filter excluding decompressing other rows of the first micro-partition of the table that contains data not responsive to the filter (Das [0024] e.g., “Each CU has storage index …compared with single column conditions …then data items from the related CUs may be filtered from further scanning…pushing the predicate down to the scan”. This teaches that filtering is applied before decompressing and column-level conditions determine what gets scanned and decompressed).
Regarding claim 5, the proposed combination of Das, Huang, and Halterman teaches the system of claim 1, wherein the filter comprises a value for the first column, wherein a first set of columns of the first micro-partition is compressed according to the first compression algorithm and a second set of columns of the first micro-partition is compressed according to a third compression algorithm (Huang [col. 22, lines 48-55] e.g., “The determining unit is configured to…determine, according to a data type of the parameters of the column and the distribution rule of the parameters in the column, a compression algorithm corresponding to the column. The compression unit is configured to compress the column using the compression algorithm”. This shows that different columns may be compressed using different algorithms based on their content and structure).
Regarding claim 6, the proposed combination of Das, Huang, and Halterman teaches the system of claim 1, the operations comprising:
accessing a compressed value for each entry in the first micro-partition for the first column (Huang [col. 22, lines 48-55] e.g., “The determining unit is configured to…determine, according to a data type of the parameters of the column and the distribution rule of the parameters in the column, a compression algorithm corresponding to the column. The compression unit is configured to compress the column using the compression algorithm”. This shows that different columns may be compressed using different algorithms based on their content and structure);
accessing a dictionary that maps compressed values to uncompressed values (Huang [col. 23, lines 25-31] e.g., “determine that the compression algorithm corresponding to the column is the dictionary compression algorithm”); and
using the dictionary, determining an uncompressed value for each compressed value of the entries in the first micro-partition (Huang [col. 15, lines 26-32] e.g., “Accordingly, when determining that the data type of the parameters of the column is a data type that supports the dictionary compression algorithm and determining that the distribution rule of the column is that values of the parameters of the column are the multiple keywords, the DN determines that the compression algorithm corresponding to the column is the dictionary compression algorithm”). The motivation for the proposed combination is maintained.
Regarding claim 7, the proposed combination of Das, Huang, and Halterman teaches the system of claim 1, wherein the operations further comprise:
aggregating entries in the table to create a first aggregated data structure comprising aggregated entries (Huang [col. 19, lines 5-11] e.g., “gathering is performed according to the values of parameters “age” in the third column…the multiple-row data whose value is the same in the third column is arranged together. That is, a group by (group by) query plan type is used to query data. The “group by” means gathering all data”. This describes aggregation data entries by the “age” column values to create and aggregated structure (Table 4) where rows wit same age values are grouped together. See also [col. 18, Table 4]); transferring the aggregated entries from the first aggregated data structure to a second aggregating data structure (Huang [Abstract] e.g., “…he DN compresses the column using the compression algorithm; and the DN sends a compressed column to a target node”, see also [col. 20, lines 41-43] e.g., “The first DN compresses the first data using the first compression algorithm and sends compressed first data to the second DN. The first DN further sends to the second DN”. This corresponds to transferring aggregated (and compressed) entries to another data structure or node that stores or processes the aggregated data further); and clearing the aggregated entries in the first aggregated data structure before resuming aggregating the entries (Huang [col. 2, lines 15-20] e.g., “ because the DN compresses the column using the determined compression algorithm and then sends a compressed column to a target node, overheads for data transmission between nodes are reduced and network load is lightened by transmitting compressed data”. This implies the DN completes one aggregation/compression cycle and sends the data before starting a new cycle, which inherently requires clearing or resetting the aggregated data so that the DN can aggregate fresh data without mixing with old data).
Regarding claim 10, the proposed combination of Das, Huang, and Halterman teaches the system of claim 1, wherein the operations further comprise:
decompressing a first column in the second micro-partition excluding decompressing other columns of the table in the second micro-partition (Das [0054] e.g., “For in-memory scans, IMCUs are decompressed, scanned CU by CU …Some predicates may be evaluated at the in-memory scan, instead of at the query execution engine, because these predicates can be applied directly on the compressed formats”. The in-memory scan processes each CU (i.e., each column chunk) individually-only those columns whose CUs are needed for the predicate or query are decompressed);
decompressing, based on the filter on the first column, rows of the second micro-partition containing data responsive to the filter excluding decompressing other rows of the second micro-partition containing data not responsive to the filter (Das [0025] e.g., “predicates of a query that can be evaluated directly on IMCUs without having to first decompress the IMCU data are identified…then pushed-down to the in-memory scan…decompressing and stitching IMCU data is avoided”. This shows the system can avoid decompressing parts of the data-implying that only portions needed for filter evaluation (and subsequent row assembly) are decompressed. See also [0103] e.g., “In some cases, the CU may need to be decompressed in order to evaluate the condition…The data items are decompressed, and the condition is then applied”); and
combining the decompressed rows of the micro-partition with the decompressed rows of the second micro-partition for provision in response to the operation for the table (Das [0105] e.g., “The data items from CU a1, b1, and d1 that are in the same rows as the data items that meet the condition for c1 are decompressed, and these data items are stitched…Once the rows are stitched, the entire complex predicate may be evaluated”. This teaches that decompressed data from different column units (CUs) is stitched into rows based on the filter match).
Regarding claim 12, the proposed combination of Das, Huang, and Halterman teaches the machine-storage medium of claim 11, wherein the operations further comprise:
decompressing, in the first micro-partition, the first column of the table excluding decompressing other columns of the table in the first micro-partition (Das [0103] e.g., “In some cases, the CU may need to be decompressed in order to evaluate the condition of the predicate against the data items in the CU…The data items are decompressed, and the condition is then applied to each data item in CU c1” and “For this particular example, the compression technique could be using an order-preserving dictionary, in which case no decompression is needed. However, the example is illustrative of decompression”. This implies evaluating each data item after decompression and selectively keeping only those matching the predicate – i.e., row responsive to the filter. See also (Das [0024] e.g., “Each CU has storage index …compared with single column conditions …then data items from the related CUs may be filtered from further scanning…pushing the predicate down to the scan”. This teaches that filtering is applied before decompressing and column-level conditions determine what gets scanned and decompressed)); and
decompressing, based on the filter on the first column, rows of the first micro-partition of the table that contains data responsive to the filter excluding decompressing other rows of the first micro-partition of the table that contains data not responsive to the filter (Das [0105] e.g., “The data items from CU a1, b1, and d1 that are in the same rows as the data items that meet the condition for c1 are decompressed…Once the rows are stitched, the entire complex predicate may be evaluated….In this example, R6 is the only row that needs to be stitched together because all other rows have been filtered”. Filtering is applied to column c1 (the predicate column). Only the rows (e.g., R6) that match the filter (On c1) cause decompression of other column values (a1, b1, d1). Non-matching rows are not decompressed. This is a direct teaching of row-level decompression based on a filter condition. See also [0054] e.g., “in-memory scans, IMCUs are decompressed, scanned CU by CU…Some predicates may be evaluated at the in-memory scan…These predicates are “pushed down” to the scan operation”. This paragraph explains that filter predicates are evaluated early (“pushed down”), often on compressed data).
Regarding claim 15, the proposed combination of Das, Huang, and Halterman teaches the machine-storage medium of claim 11, wherein the filter comprises a value for the first column, wherein a first set of columns of the first micro-partition is compressed according to the first compression algorithm and a second set of columns of the first micro-partition is compressed according to a third compression algorithm (Huang [col. 22, lines 48-55] e.g., “The determining unit is configured to…determine, according to a data type of the parameters of the column and the distribution rule of the parameters in the column, a compression algorithm corresponding to the column. The compression unit is configured to compress the column using the compression algorithm”. This shows that different columns may be compressed using different algorithms based on their content and structure).
Regarding claim 16, the proposed combination of Das, Huang, and Halterman teaches the machine-storage medium of claim 15, the operations comprising:
accessing a compressed value for each entry in the first micro-partition for the first column (Das [0042] e.g., “Different compression levels are suitable for different use cases. For example, compression techniques have been developed that are specifically optimized for DML performance. Other compression techniques are optimized for query performance. Yet other techniques are optimized for space capacity. Examples of different encoding schemes used, include, but are not necessarily limited to, dictionary encoding, run-length encoding (RLE) Huffman coding, and delta coding”);
accessing a dictionary that maps compressed values to uncompressed values (Huang [col. 23, lines 25-31] e.g., “determine that the compression algorithm corresponding to the column is the dictionary compression algorithm”); and
using the dictionary, determining an uncompressed value for each compressed value of the entries in the first micro-partition (Huang [col. 15, lines 26-32] e.g., “Accordingly, when determining that the data type of the parameters of the column is a data type that supports the dictionary compression algorithm and determining that the distribution rule of the column is that values of the parameters of the column are the multiple keywords, the DN determines that the compression algorithm corresponding to the column is the dictionary compression algorithm”). The motivation for the proposed combination is maintained.
Regarding claim 17, the proposed combination of Das, Huang, and Halterman teaches the machine-storage medium of claim 11, wherein the operations further comprise:
providing, in response to the operation for the table, a compressed value for the first column for each entry in decompressed rows of the first micro-partition (Huang [col. 21, lines 49-61] e.g., “…the DN compresses the column using the compression algorithm; and the DN sends a compressed column to a target node… overheads for data transmission between nodes are reduced and network load is lightened by transmitting compressed data”. This supports sending or returning compressed columns values in response to operations (e.g., a table query), even while other data may processed or decompressed).
Regarding claim 19, the proposed combination of Das, Huang, and Halterman teaches a method of claim 18, wherein each micro-partition of the plurality of micro-partitions is a file on a file system (Das [0036] e.g., “partitions and sub-partitions of a partitioned table are organized into IMCUs independently of each other, and an IMCU does not span multiple partitions. A single partition or sub-partition can, however, have multiple IMCUs”).
Regarding claim 20, the proposed combination of Das, Huang, and Halterman teaches a method of claim 18, further comprising:
decompressing, in the first micro-partition, the first column of the table excluding decompressing other columns of the table in the first micro-partition (Das [0054] e.g., “For in-memory scans, IMCUs are decompressed, scanned CU by CU …Some predicates may be evaluated at the in-memory scan, instead of at the query execution engine, because these predicates can be applied directly on the compressed formats”. The in-memory scan processes each CU (i.e., each column chunk) individually-only those columns whose CUs are needed for the predicate or query are decompressed); and
decompressing, based on the filter on the first column, rows of the first micro-partition of the table that contains data responsive to the filter excluding decompressing other rows of the first micro-partition of the table that contains data not responsive to the filter (Das [0025] e.g., “predicates of a query that can be evaluated directly on IMCUs without having to first decompress the IMCU data are identified…then pushed-down to the in-memory scan…decompressing and stitching IMCU data is avoided”. This shows the system can avoid decompressing parts of the data-implying that only portions needed for filter evaluation (and subsequent row assembly) are decompressed. See also [0103] e.g., “In some cases, the CU may need to be decompressed in order to evaluate the condition…The data items are decompressed, and the condition is then applied”).
11. Claims 3-4 and 13-14 are rejected under 35 U.S.C. 103 as being unpatentable over Das et al. U.S. 2016/0350347 A1 (hereinafter Das) in view of Huang et al. U.S. Patent 10,979,520 B2 (hereinafter Huang) further in view of Halterman et al. US20180203899 A1 (hereinafter Halterman) as applied to claims 1-2, 5-7, 10- 12, and 15-20 above, and further in view of Weinstein et al. US20150371631A1 (hereinafter Weinstein).
Regarding claim 3, the proposed combination of Das, Huang, and Halterman teaches a system of claim 2, the operations comprising:
providing, in response to the first operation for the table, the decompressed rows of the first micro-partition (Das [0105] e.g., “The data items from CU a1, b1, and d1 that are in the same rows as the data items that meet the condition for c1 are decompressed, and these data items are stitched…Once the rows are stitched, the entire complex predicate may be evaluated against the filtered rows”. This teaches that first micro-partition rows satisfying the filter are decompressed, stitched, and provided to the query engine);
accessing a second operation for the table, the second operation comprising determining a second computation result on the first column of the table (Das [0054] e.g., “Query execution …IMCUs are decompressed, scanned CU by CU…rows are served to the query execution engine…Some predicates may be evaluated at the in-memory scan… The query optimizer identifies predicates that may be pushed down … rather than by the execution engine”. After the scan/predicate step, the engine proceeds to perform further operation – aggregation, computation, etc);
computing, for a first entry in the rows of the first micro-partition, a first computation result on a first value of the first column of the first entry (Das [0054] e.g., “…rows are served to the query execution engine… rather than by the execution engine”. The query execution engine performs per-row computations (e.g., evaluation, aggregation) on values from the first column. This is equivalent to “computing .. a first computation result on a first value”).; and
Das, Huang, and Halterman teach decompressing the first computation result for the first entry in conjunction with a first compressed value for the first entry. Das, Huang, and Halterman teach decompressing selected data from columnar or micro-partitioned storage format, performing computation on decompressed values, and optimally filtering or evaluation predicated. However, the combined teaching of Das, Huang, and Halterman do not expressly disclose storing computation results along with compressed data at an entry (row)-level granularity.
Weinstein discloses storing the first computation result for the first entry in conjunction with a first compressed value for the first entry (0071] e.g., “The computing system then stores the probability scores produced by the acoustic model for a particular set of compressed values, in association with the index value for the particular set of compressed values. As a result, the cache stores scores generated for different sets of compressed values”, see also [0021] e.g., “Speech recognition scores may be pre-computed for a variety of potential inputs to a model, and the speech recognition scores may be stored in the cache”. These paragraphs discuss computation result, that probability score/acoustic model score, compressed value, that compressed speech features / compressed values, and storing the score is association with compressed value).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the caching speech recognition scores taught by Weinstein, in the combined teachings Das, Huang, and Halterman to yield predictable result of enables using servers to determine the transcriptions more quickly or accurately. The combined teaching allowing a client device to independently receive audio, determine speech features and compressed values, look up scores in the cache and determine the transcription without assistance of the server and without providing speech data over a network.compress and store individual computation results for performance and storage efficiency.
Regarding claim 4, the proposed combination of Das, Huang, Halterman, and Weinstein teaches a system of claim 3, the operations comprising:
based on a second compressed value for a second entry of the table being identical to the first compressed value for the first entry, storing the first computation result as the second computation result instead of computing the second computation result using the second compressed value for the second entry (Weinstein [0071] e.g., “The computing system then stores the probability scores produced by the acoustic model for a particular set of compressed values”. This gives compressed value(s), computed result (probability score), and storage of the result associated with the compressed value. See also [0007] e.g., “Selecting the acoustic model score for the received one or more values includes selecting an acoustic model score previously generated for a set of values that matches the received one or more values”. This shows previously generated values, which is equivalent to first compressed value., received values match, which is equivalent to second compressed value identical to first compressed value, previously generated score, which is equivalent to first computation result, and selected score, which is equivalent to reused as second computational result. See also [0003] e.g., “A speech recognition module can use scores from the cache… instead of evaluating a speech recognition model to generate speech recognition scores”. This directly maps to “instead of computing the second computational result”) wherein each micro-partition of the plurality of micro-partitions is a file on a file system , wherein the first micro-partition is compressed using dictionary compression (Das [0042] e.g., “… dictionary encoding”. See also [col. 3, lines 28-34] e.g., “… the compression algorithm corresponding to the column is the dictionary compression algorithm”) and the second micro-partition is compressed using run-length encoding (Das [0042] e.g., “… run-length encoding (RLE)”, see also (Huang [col. 13, lines 17-19] e.g., “The ColCompressMode includes an RLE compression algorithm…”).
Regarding claim 13, the proposed combination of Das, Huang, Halterman, and Weinstein teaches a machine-storage medium of claim 12, wherein decompressing first column comprises:
providing, in response to the first operation for the table, the decompressed rows of the first micro-partition (Das [0105] e.g., “The data items from CU a1, b1, and d1 that are in the same rows as the data items that meet the condition for c1 are decompressed, and these data items are stitched…Once the rows are stitched, the entire complex predicate may be evaluated against the filtered rows”. This teaches that first micro-partition rows satisfying the filter are decompressed, stitched, and provided to the query engine);
accessing a second operation for the table, the second operation comprising determining a second computation result on the first column of the table (Das [0054] e.g., “Query execution …IMCUs are decompressed, scanned CU by CU…rows are served to the query execution engine…Some predicates may be evaluated at the in-memory scan… The query optimizer identifies predicates that may be pushed down … rather than by the execution engine”. After the scan/predicate step, the engine proceeds to perform further operation – aggregation, computation, etc);
computing, for a first entry in the rows of the first micro-partition, a first computation result on a first value of the first column of the first entry (Das [0054] e.g., “…rows are served to the query execution engine… rather than by the execution engine”. The query execution engine performs per-row computations (e.g., evaluation, aggregation) on values from the first column. This is equivalent to “computing .. a first computation result on a first value”); and
storing the first computation result for the first entry in conjunction with a first compressed value for the first entry (0071] e.g., “The computing system then stores the probability scores produced by the acoustic model for a particular set of compressed values, in association with the index value for the particular set of compressed values. As a result, the cache stores scores generated for different sets of compressed values”, see also [0021] e.g., “Speech recognition scores may be pre-computed for a variety of potential inputs to a model, and the speech recognition scores may be stored in the cache”. These paragraphs discuss computation result, that probability score/acoustic model score, compressed value, that compressed speech features / compressed values, and storing the score is association with compressed value). The motivation for the proposed combination is maintained.
Regarding claim 14, Das, Huang, Halterman, and Weinstein teaches a machine-storage medium of claim 13, wherein the operations further comprise:
based on a second compressed value for a second entry of the table being identical to the first compressed value for the first entry, storing the first computation result as the second computation result instead of computing the second computation result using the second compressed value for the second entry (Weinstein [0071] e.g., “The computing system then stores the probability scores produced by the acoustic model for a particular set of compressed values”. This gives compressed value(s), computed result (probability score), and storage of the result associated with the compressed value. See also [0007] e.g., “Selecting the acoustic model score for the received one or more values includes selecting an acoustic model score previously generated for a set of values that matches the received one or more values”. This shows previously generated values, which is equivalent to first compressed value., received values match, which is equivalent to second compressed value identical to first compressed value, previously generated score, which is equivalent to first computation result, and selected score, which is equivalent to reused as second computational result. See also [0003] e.g., “A speech recognition module can use scores from the cache… instead of evaluating a speech recognition model to generate speech recognition scores”. This directly maps to “instead of computing the second computational result”) wherein each micro-partition of the plurality of micro-partitions is a file on a file system , wherein the first micro-partition is compressed using dictionary compression (Das [0042] e.g., “… dictionary encoding”. See also [col. 3, lines 28-34] e.g., “… the compression algorithm corresponding to the column is the dictionary compression algorithm”) and the second micro-partition is compressed using run-length encoding (Das [0042] e.g., “… run-length encoding (RLE)”, see also (Huang [col. 13, lines 17-19] e.g., “The ColCompressMode includes an RLE compression algorithm…”). The motivation for the proposed combination is maintained.
Allowable Subject Matter
12. Claim 8 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.
13. The claimed steps describe a concrete and technical approach to data management. Initially, data entries are aggregated into a first in-memory structure. Once a predetermined threshold is reached—based on the number of entries or other defined conditions—the system transfers the aggregated entries to a second structure. After the transfer, the first structure is cleared, allowing aggregation to resume without interruption.14. The prior art of record, Das et al. U.S. 2016/0350347 A1 (hereinafter Das) in view of Huang et al. U.S. Patent 10,979,520 B2 (hereinafter Huang) further in view of Halterman et al. US20180203899 A1 (hereinafter Halterman) further in view of Weinstein et al. US20150371631A1 (hereinafter Weinstein) fails to explicitly teach “building an initial aggregation buffer”, “threshold-triggering flushing to a second structure”, “resetting the initial buffer”, and “continuation of aggregation” the limitations featured:
15. Claim 9 is dependent from claim 8 and similarly objected.
Conclusion
16. Any inquiry concerning this communication or earlier communications from the examiner should be directed to BERHANU MITIKU whose telephone number is (571)270-1983. The examiner can normally be reached Monday – Friday 8:30 AM – 4: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, Ajay Bhatia can be reached at 571-272-3906. 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.
/BERHANU MITIKU/Examiner, Art Unit 2156
/AJAY M BHATIA/Supervisory Patent Examiner, Art Unit 2156
Prosecution Insights