Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
DETAILED ACTION
Claims 1-20 are present in this application. Claims 1-20 are pending in this office
action.
This office action is NON-FINAL.
Drawings
The Drawings filed on 08/25/25 are acceptable for examination purposes.
Specification
The Specification filed on 08/25/25 is acceptable for examination purposes.
Claim Interpretation
Claims 17-20, Examiner is interpreting “A computer-storage medium” in light of
Specification [00360]. Specification [00360] states that, …” The terms "machine-storage media," "computer- storage media," and "device-storage media" specifically exclude carrier waves, modulated data signals”.
Information Disclosure Statement
The information disclosure statements (IDS) filed on 08/25/25, 04/09/26 and 07/30/26 have been considered by the Examiner and made of record in the application file.
Claim Rejections 35 U.S.C. §103
6. 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 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.
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.
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:
Claims 1-3, 5-11 and 13-20 are rejected under 35 U.S.C. § 103 as being un patentable over He et al. (US 2011/0270871 A1) in view of Parker (US Patent No. 6, 457, 014 B1).
Regarding claim 1, He teaches a system comprising:
at least one hardware processor, (See He paragraph [0006], a processor); and
at least one memory storing instructions that cause the at least one hardware processor to perform operations comprising, (See He paragraph [0082], The processor 1305 is a hardware device for executing software, particularly that stored in memory 1310…for executing software instructions):
generating, for each row in an Iceberg source table, (See He paragraph [0027], an iceberg query only aggregates a few attributes on a table containing a large number attributes), of the Iceberg source table to identify changes at a row level, (See He paragraph [0025], a tuple-scan based scheme often makes performance of iceberg queries unsatisfactory, especially when the table is big but the returned iceberg result set is very small); and
updating a dynamic table associated with the Iceberg source table based on the identified changes, (See He paragraph [0043], generate iceberg results nor contribute to dynamic pruning. For example, if a table has 100,000 tuples, its attribute A has 10,000 unique values, and attribute B has 10,000 unique values. Thus, there are 10,000 bitmap vectors for A and 10,000 for B. In the worst case, the total number of pairwise AND operations is 10,000.times.10,000=100,000,000, which is 1,000 times larger than the number of tuples).
He does not explicitly disclose a row identifier derived from immutable metadata associated with a physical storage location of the row, ( and a position of the row within the physical storage location, generating, for each of a first version and a second version of the Iceberg source table, a set of the row identifiers by computing the row identifier for each row present in the respective version, comparing the sets of the row identifiers between the first version and the second version.
However, Parker teaches a row identifier derived from immutable metadata associated with a physical storage location of the row, (See Parker Col. 5 lines 16-19, determining the location of data fields in rows that correspond to columns of data is based upon the fixed and variable column definitions retrieved at step 202), and a position of the row within the physical storage location, (See Parker Col. 5 lines 16-19, determining the location of the index key column data in the row of data is applied to the row of data); generating, for each of a first version and a second version of the Iceberg source table, (See Parker Col. 4 lines 34-39, generate table data whenever a table is recovered…table data storage device 108 to previous backup versions), a set of the row identifiers by computing the row identifier for each row present in the respective version, (See Parker Col. 5 lines 24-34, table analysis may be initiated when an existing index of a table has been corrupted or when the table data has been corrupted requiring verification of a backup version of the table data…for determining the location of the index key column data in the row of data is applied to the row of data); comparing the sets of the row identifiers between the first version and the second version, (See Parker Col. 4 lines 38-43, backup table data on table data storage device 108 to previous backup versions, and then to verify that the previous backup versions have not been corrupted…performing this verification is to compare index data from the backup table with the most recent index data).
It would have been obvious to one with ordinary skill in the art before the
effective filing date of the claimed invention was made to modify a row identifier derived from immutable metadata associated with a physical storage location of the row, ( and a position of the row within the physical storage location, generating, for each of a first version and a second version of the Iceberg source table, a set of the row identifiers by computing the row identifier for each row present in the respective version, comparing the sets of the row identifiers between the first version and the second version of Parker in order to allow a user to readily determine relevant groups of data, or to readily determine whether certain classes of data contain other subclasses of data.
Claims 9 and 17 recite the same limitations as claim 1 above. Therefore, claims
9 and 17 are rejected based on the same reasoning.
Regarding claim 2, He taught the system according to claim 1 as described above. He further teaches wherein the physical storage location comprises a file associated with the Iceberg source table or a partition within the file, (See He paragraph [0027], an iceberg query only aggregates a few attributes on a table containing a large number attributes. As such, the query processor still has to read through all the columns in the table), and the operations further comprising: determining the immutable metadata based on at least one of: a file name of the file, a file path associated with the file, a partition identifier of the partition, a table identifier of the Iceberg source table, and the position of the row, (See He paragraph [0004], processing the iceberg query using a bitmap index having a plurality of bitmap vectors in a database…according to respective positions of the bitmap vectors in the subset of the plurality of bitmap vectors).
Claims 10 and 18 recite the same limitations as claim 2 above. Therefore, claims
10 and 18 are rejected based on the same reasoning.
Regarding claim 3, He taught the system according to claim 2 as described above. He further teaches wherein the generating of the row identifier comprises: concatenating at least one of the file name or the file path with the position of the row to obtain a concatenated value; (See He paragraph [0004], processing the iceberg query using a bitmap index having a plurality of bitmap vectors in a database…according to respective positions of the bitmap vectors in the subset of the plurality of bitmap vectors), and
applying a hash function to the concatenated value to generate the row identifier, (See He paragraph [0063], the icebergPQ algorithm is denoted as PQ, the icebergDP algorithm is denoted as Pruning, the row oriented database is denoted as RowDB, MonetDB is denoted as MonetDB, and the baseline algorithm is denoted as Baseline. The experiments generate large synthetic data according to five parameters).
Claims 11 and 19 recite the same limitations as claim 3 above. Therefore, claims
11 and 19 are rejected based on the same reasoning.
Regarding claim 5, He taught the system according to claim 1 as described above. He further teaches the operations further comprising:
performing a merge-on-read update to parse delta files of one or more base files of the Iceberg source table to detect changes to the one or more base files, (See He paragraph [0030], The vector alignment algorithm can be on the priority queue structure and further optimization strategies, tracking pointers and global filter vectors. By combining dynamic pruning and vector alignment, the exemplary embodiments described herein greatly improve the performance of iceberg query processing as compared to tuple-scan based techniques).
Claim 13 recites the same limitations as claim 5 above. Therefore, claim
13 is rejected based on the same reasoning.
Regarding claim 6, He taught the system according to claim 5 as described above. He further teaches the operations further comprising:
reconstructing a current state of each row of the Iceberg source table by applying the changes to the one or more base files, (See He paragraph [0025], computing iceberg queries for large data. Current off-the-shelf relational database systems); and
determining the changes at the row level based on the current state of each row of the Iceberg source table, (See He paragraph [0030], The vector alignment algorithm can be on the priority queue structure and further optimization strategies, tracking pointers and global filter vectors. By combining dynamic pruning and vector alignment, the exemplary embodiments described herein greatly improve the performance of iceberg query processing as compared to tuple-scan based techniques).
Claim 14 recites the same limitations as claim 6 above. Therefore, claim
14 is rejected based on the same reasoning.
Regarding claim 7, He taught the system according to claim 1 as described above. He further teaches the operations further comprising:
storing a mapping of the row identifiers to row data of the Iceberg source table, (See He paragraph [0027], tuples are stored according to rows. As such, in typical warehouse applications, an iceberg query only aggregates a few attributes on a table containing a large number attributes); and
performing a refresh of the dynamic table based on the mapping, (generate iceberg results nor contribute to dynamic pruning. For example, if a table has 100,000 tuples, its attribute A has 10,000 unique values).
Claim 15 recites the same limitations as claim 7 above. Therefore, claim
15 is rejected based on the same reasoning.
Regarding claim 8, He taught the system according to claim 7 as described above. He further teaches the operations further comprising: updating the mapping of the row identifiers to row data in response to changes detected between versions of the Iceberg source table, ((See He paragraph [0030], The vector alignment algorithm can be on the priority queue structure and further optimization strategies, tracking pointers and global filter vectors. By combining dynamic pruning and vector alignment, the exemplary embodiments described herein greatly improve the performance of iceberg query processing as compared to tuple-scan based techniques).
Claim 16 recites the same limitations as claim 8 above. Therefore, claim
18 is rejected based on the same reasoning.
Regarding claim 20, He taught the computer-storage medium according to claim 17 as described above. He further the operations further comprising:
performing a merge-on-read update to parse delta files of one or more base files of the Iceberg source table to detect changes to the one or more base files, (See He paragraph [0030], The vector alignment algorithm can be on the priority queue structure and further optimization strategies, tracking pointers and global filter vectors. By combining dynamic pruning and vector alignment, the exemplary embodiments described herein greatly improve the performance of iceberg query processing as compared to tuple-scan based techniques).
reconstructing a current state of each row of the Iceberg source table by applying the changes to the one or more base files, (See He paragraph [0025], computing iceberg queries for large data. Current off-the-shelf relational database systems); and
determining the changes at the row level based on the current state of each row of the Iceberg source table, (See He paragraph [0030], The vector alignment algorithm can be on the priority queue structure and further optimization strategies, tracking pointers and global filter vectors. By combining dynamic pruning and vector alignment, the exemplary embodiments described herein greatly improve the performance of iceberg query processing as compared to tuple-scan based techniques).
Claims 4 and 12 are rejected under 35 U.S.C. § 103 as being un patentable over He et al. (US 2011/0270871 A1) in view of Parker (US Patent No. 6, 457, 014 B1) and further in view of Yamada (US 2018/0373775 A1).
Regarding claim 4, He taught the system according to claim 1 as described above.
He does not explicitly disclose the operations further comprising: performing a copy-on-write update process on the Iceberg source table to detect newly added or removed files, and determining the changes at the row level based on presence or absence of row identifiers in the newly added or removed files.
However, Yamada teaches the operations further comprising: performing a copy-on-write update process on the Iceberg source table to detect newly added or removed files, (See Yamada paragraph [0013], the shadow copy of each table included in the table-based write set in the lower-level master node is configured only from newly added rows); and determining the changes at the row level based on presence or absence of row identifiers in the newly added or removed files (See Yamada paragraph [0014], managing a database, wherein the shadow copy of the integrated write set in the lower-level master node is configured only from newly added rows).
It would have been obvious to one with ordinary skill in the art before the
effective filing date of the claimed invention was made to modify the operations further comprising: performing a copy-on-write update process on the Iceberg source table to detect newly added or removed files, and determining the changes at the row level based on presence or absence of row identifiers in the newly added or removed files of Yamada in order to reliably and efficiently update the database between the nodes even in cases where a plurality of tables of the lower-level master node are updated.
Claim 12 recites the same limitations as claim 4 above. Therefore, claim
12 is rejected based on the same reasoning.
Conclusions/Points of Contacts
The prior art made of record and not relied upon is considered pertinent to
applicant’s disclosure. See form PTO-892.
LABBATE et al. (US 2025/0209056 A1), Apache Iceberg “is an open table format for huge analytic datasets. Iceberg adds tables to compute engines [ . . . ] using a high-performance table format that works just like a SQL table.” The Iceberg table format “is designed to manage a large, slow-changing collection of files in a distributed file system or key-value store as a table”.
Nadeau et al. (US 2023/0098227 A1) For table formats such as Apache Iceberg Nessie needs to track both the pointer to the Iceberg “Table Metadata” which is tracked as “global-state” and the Iceberg snapshot-ID which is tracked per Nessie-named-reference. For Nessie-commits, which are atomic, this means that Nessie has to update both the global-state and the on-reference-state for the Iceberg table.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MULUEMEBET GURMU whose telephone number is (571)270-7095. The examiner can normally be reached M-F 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, Tony Mahmoudi can be reached at 5712724078. 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.
/MULUEMEBET GURMU/Primary Examiner, Art Unit 2163
Prosecution Insights