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 .
Continued Examination Under 37 CFR 1.114
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 14 November 2025 has been entered.
Introductory Remarks
In response to communications filed on 14 November 2025, claims 1, 11, and 20 are amended per Applicant's request. No claims were cancelled. No claims were withdrawn. No new claims were added. Therefore, claims 1-20 are presently pending in the application, of which claims 1, 11, and 20 are presented in independent form.
The previously raised non-statutory double rejection of the pending claims is maintained.
The previously raised 103 rejection of the pending claims is withdrawn in view of the amendments to the claims. A new ground(s) of rejection has been issued.
Response to Arguments
Applicant’s arguments filed 14 November 2025 with respect to the non-statutory double patenting rejection of the claims (see Remarks, p. 6) have been fully considered. No terminal disclaimer has been filed by Applicant, nor have the claims been sufficiently amended to overcome the non-statutory double patenting rejection. Therefore, the non-statutory double patenting rejection of the pending claims has been maintained.
Applicant’s arguments filed 14 November 2025 with respect to the rejection of the claims under 35 U.S.C. 103 (see Remarks, p. 7-11) have been fully considered but are not persuasive.
Applicant argues that the amended feature that the hybrid table “lacks table-level locking” is a limitation “directly contradicting the table-level locking mechanisms that Kumar, Shankar, and IBR-Shankar require for their operation…” (see Remarks, p. 6-9) is unpersuasive. The claims pertain to building an index for a hybrid table, where the hybrid table lacks table-level locking. Shankar explicitly discloses in, e.g., [0039], that “an index is built online without using any blocking locks. In this way, DML activity on the table may be unaffected while a CREATE INDEX statement is processed”.
Given that the claims pertain to building an index, the relevant aspect with respect to the hybrid table lacking table-level locks is with respect to the index. There are no other additional limitations in the claim in which the lack of table-level locks is relevant, as all limitations pertain solely to index building. The same can be said for the dependent claims. Therefore, because Kumar (incorporating by reference Shankar) pertain to building an index without using any blocking locks, as it is within the context of the claimed invention, therefore Kumar’s disclosure does not contradict the claimed limitations.
(Furthermore, this separately raises a 112(b) indefiniteness issue, as it is unclear whether the lack of table-level locks pertains to all transactions, or solely to the index building, as the claims’ focus is only on index building and not on other transactions that may be occurring).
Applicant further argues that “None of the cited references disclose the above-discussed dual-storage architecture [in which table data is stored in a distributed data store and table metadata is stored in a metadata database separate from the distributed data store” (see Remarks, p. 9-10). However, although the references do not explicitly disclose such a limitation, one of ordinary skill in the art would have found it obvious to have modified the prior art reference(s) to arrive at the claimed invention for at least the reason set forth in the 103 rejection below (which has been modified to conform to the newly amended claim language).
Applicant is recommended to consider amending the claim language to, e.g., incorporate these newly added claim limitations more particularly into how at least some or multiple of the steps particularly utilize those particular limitations to make these limitations more significant with respect to the prior art, and therefore potentially distinguish from the prior art.
However, Applicant’s arguments are not persuasive for at least the reasons set forth above, and because such claimed limitations are obvious in view of the prior art, for at least the reasons set forth in the 103 rejection below and as explained above.
Double Patenting
Claims 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-18 of U.S. Patent No. 12,093,248 B1. Although the claims at issue are not identical, they are not patentably distinct from each other (see the table below for comparison of the two claims, where italicized and bolded text refers to matching claim language).
Claims 1-20 of the present application 18/790,664
Claims 1-18 of U.S. Patent No. 12,093,248 B1
1. A system comprising:
at least one hardware processor; and
a memory storing instructions that cause the at least one hardware processor to perform operations comprising:
initiating an online index building process of an index of a hybrid table, the hybrid table lacking table-level locking and having table data stored in a distributed data store and table metadata stored in a metadata database separate from the distributed data store;
including, <continued below>
in the index, a new index record for each record from the hybrid table;
validating the index, the validating comprising:
retrieving a first metadata version of the hybrid table from a metadata database;
retrieving a second metadata version of the hybrid table from a distributed data store;
comparing the first metadata version with the second metadata version; and
determining that the second metadata version is less than or equal to the first metadata version; and
in response to successfully validating the index, indicating in a particular entry of the index that validation of the index has succeeded.
1. A system comprising:
at least one hardware processor; and
a memory storing instructions that cause the at least one hardware processor to perform operations comprising:
receiving a statement to initiate an online index building process of an index of a hybrid table from a set of hybrid tables, the set of hybrid tables being stored in a distributed data store provided by a networked database system;1
initiating the online index building process of the index in response to receiving the statement;2
determining, during the online index building process, that the index can be generated;
performing, during the online index building process, a write operation to store an index record indicating an initial status of the online index building process, the index record being stored in a metadata database provided by the networked database system, the metadata database being different than the distributed data store;
performing, during the online index building process, a statement fencing process;
performing a back-filling process of the index, the back-filling process including, in the index, a new index record for each record from the hybrid table;
validating the index, the validating comprising:
retrieving, by a compute service manager, a first metadata version of the hybrid table from the metadata database;
sending, by the compute service manager, the first metadata version of the hybrid table to an execution node;
retrieving, by the execution node, a second metadata version of the hybrid table from the distributed data store;
comparing, by the execution node, the first metadata version with the second metadata version; and
determining, by the execution node, that the second metadata version is less than or equal to the first metadata version; and
in response to successfully validating the index, indicating in a particular entry of the index that validation of the index has succeeded.
2. The system of claim 1, wherein the operations further comprise:
prior to initiating the online index building process, receiving a statement to initiate the online index building process of the index of the hybrid table from a set of hybrid tables, the set of hybrid tables being stored in a distributed data store provided by a networked database system.
(See claim 1 above that is underlined, bolded, and italicized)
3. The system of claim 2, wherein the statement comprises a particular statement to create an index.
2. The system of claim 1, wherein the statement comprises a particular statement to create an index.
4. The system of claim 2, wherein the statement comprises a particular statement to alter a table with a constraint.
3. The system of claim 1, wherein the statement comprises a particular statement to alter a table with a constraint.
5. The system of claim 4, wherein the constraint comprises that a set of values of a key is unique within the table.
4. The system of claim 3, wherein the constraint comprises that a set of values of a key is unique within the table.
6. The system of claim 4, wherein the constraint comprises a foreign key referencing a primary key or unique key of a second table, the second table being different than the table.
5. The system of claim 3, wherein the constraint comprises a foreign key referencing a primary key or unique key of a second table, the second table being different than the table.
7. The system of claim 1, wherein the operations further comprise:
determining that a second index with a same name as the index does not exist; and
determining that another index is not currently being generated.
6. The system of claim 1, wherein determining that the index can be generated comprises:
determining that a second index with a same name as the index does not exist; and
determining that another index is not currently being generated.
8. The system of claim 1, wherein the operations further comprise:
updating a table persistence object corresponding to a table in the metadata database, the updating blocking other data definition language (DDL) operations that modify the table while the online index building process is occurring.
7. The system of claim 1, wherein performing the write operation to store the index record comprises:
updating a table persistence object corresponding to a table in the metadata database, the updating blocking other data definition language (DDL) operations that modify the table while the online index building process is occurring.
9. The system of claim 1, wherein the operations further comprise:
performing a scan of the index to check uniqueness or referential integrity validity of each index record, wherein a scanner thread is initiated that goes over the index and verifies the uniqueness or referential integrity validity of each index record in the index.
8. The system of claim 1, wherein the operations further comprise:
performing a scan of the index to check uniqueness or referential integrity validity of each index record, wherein a scanner thread is initiated that goes over the index and verifies the uniqueness or referential integrity validity of each index record in the index.
10. The system of claim 9, wherein the operations further comprise:
scanning, by an execution node worker, a set of active transactions, each active transaction targeting a same table, the same table corresponding to the hybrid table; and
determining, by the execution node worker, that each active transaction from the set of active transactions has completed.
9. The system of claim 8, wherein the statement fencing process comprises:
scanning, by the execution node worker, a set of active transactions, each active transaction targeting a same table, the same table corresponding to the hybrid table; and
determining, by the execution node worker, that each active transaction from the set of active transactions has completed.
10-18. (Same as claims 1-8, but directed to a method. See claims 1-8 above)
10-17. (Same as claims 1-8, but directed to a method. See claims 1-8 above)
19. (Same as claim 9 above, but directed to a method. See claim 9 above)
(See claim 9 above)
20. (Same as claim 1 above, but directed to a non-transitory computer-storage medium. See claim 1 above)
18. (Same as claim 1 above, but directed to a non-transitory computer-storage medium. See claim 1 above)
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 §§ 706.02(I)(1) – 706.02(I)(3) for applications not subject to examination under the firs inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The filing date of the application will determine what form 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/process/file/efs/guidance/eTD-info-I.jsp.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Independent Claims 1, 11, and 20 recite “the hybrid table lacking table-level locking”. It is unclear whether this is with respect to all possible operations on the tables, e.g., other transactions that may be occurring, or simply with respect to the index building process. However, none of the claimed limitations mention the existence of other possible operations/transactions; however, the Specification is ambiguous with respect to the scope of “lacking table-level locking”, and Applicant’s Remarks filed on 14 November 20253 appear to indicate that table-level locking is beyond simply the index-building process. Yet the entirety of the claims are solely about the index-building process. Therefore, the metes and bounds of such a claim limitation cannot be ascertained.
The dependent claims are rejected for at least by virtue of their dependency on their respective independent claims, and for failing to cure the deficiencies of their respective independent claims.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-5, 11-15, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Kumar et al. (“Kumar”) (US 2015/0278275 A1, incorporating by reference Shankar et al. (“Shankar”) (US 2009/0037366 A1 at [0001]) and Shankar et al. (“IBR-Shankar”) (US 2009/0037417 A1)), in view of Baude et al. ("Baude") (US 2012/0330964 A1), in further view of Muniswamy Reddy et al. (“Reddy”) (US 11,327,937 B1).
Regarding claim 1: Kumar teaches A system comprising:
at least one hardware processor; and a memory storing instructions that cause the at least one hardware processor to perform operations comprising (Shankar, [0071], where the disclosed system for implementing the disclosed steps may include a main memory 506 for storing instructions to be executed by processor 504):
initiating an online index building process of an index of a … table, the … table lacking table-level locking (Shankar, [0032], where at T1, a CREATE INDEX statement is issued, e.g., by a database administrator. See Shankar, [0028], where the index is built from one or more tables (i.e., “index of a…table”). See Shankar, [0032-0037] and [FIG. 2A], where the CREATE INDEX statement issued at time T1 results in (between time T3 and T4) building an index based on the state of the table reflected in the snapshot. See Shankar, [0039], where an index is built online without using any blocking locks (i.e., “[without] table-level locking”.
Thus, although Kumar (incorporating by reference Shankar) does not appear to explicitly state that the table “lacks” table-level locking, Kumar (incorporating by reference Shankar) has equivalent operating characteristics as the claimed invention, which is that there is no table-locking involved, which has the shared advantage of reducing processing time. Therefore, one of ordinary skill in the art would have found it obvious to have applied Kumar (incorporating by reference Shankar) to the claimed table that “lacks” table-level locking with predictable results, which is that table-locking is not performed, with the motivation of not including characteristics that are not necessary by the index-building step) …; [and]
including, in the index, a new index record for each record from the … table (Shankar, [0032], where to be relevant, the index should be continuously updated to reflect the current state of the underlying table. Thus, the journal table is used to record the changes made by DML statements while the index is being built. See Shankar, [0066-0068], where at time T3, an index is finally built as of the state of the table reflected in the snapshot, i.e., at time T2 (i.e., “including, in the index, a new index record for each record from the…table”). At T3, the journal table may include changes from multiple DML statements that may need to be used to update the index. The time period between T3 and T4 corresponds to the cooperation phase. DML statements that execute after T3 and also before T4 perform cooperation. The steps for building the index at Shankar, [FIG. 4A] and [0061-0068] (i.e., “including, in the index, a new index record for each record from the…table”) are repeated for each subsequently executed DML statement until the journal table is fully “drained” (i.e., empty) of DML statements at T4).
Although Kumar does not appear to explicitly state that the table is a “hybrid” table as claimed, because the claimed processes may be implemented regardless of whether a “table” (as disclosed by Kumar) or a “hybrid table” (as claimed) is involved, one of ordinary skill in the art would have found it obvious to modify Kumar such that a hybrid table is operated upon. Because the claimed “hybrid table” is a type of “table”, the disclosed steps are not changed by the fact that a “hybrid” table is operated upon (versus a generic table). One of ordinary skill in the art would have been motivated to do so in order to avoid impacting overall user experience (Kumar, [0015]), regardless of the specific type of underlying table being operated upon.
Kumar does not appear to explicitly teach [the table] having table data stored in a distributed data store and table metadata stored in a metadata database separate from the distributed data store; validating the index, the validating comprising: retrieving a first metadata version of the hybrid table from the metadata database; retrieving a second metadata version of the hybrid table from the distributed data store; comparing the first metadata version with the second metadata version; and determining that the second metadata version is less than or equal to the first metadata version; and in response to successfully validating the index, indicating in a particular entry of the index that validation of the index has succeeded.
Baude teaches validating the index, the validating comprising: retrieving a first metadata version of the hybrid table from the metadata database; retrieving a second metadata version of the hybrid table from the distributed data store; comparing the first metadata version with the second metadata version; and determining that the second metadata version is less than or equal to the first metadata version (Baude, [0035], where the index creator sends indexes created on the secondary server and the captured timestamp to the primary server, and reconciles the indexes with the current state of the database tables by comparing the received captured timestamp to timestamps on the current database log of the primary server. See Kumar above with regards to the “hybrid” table.
Although Baude does not appear to explicitly state whether the timestamps (i.e., corresponding to the claimed “metadata versions”) are greater/less than or equal to one another, one of ordinary skill in the art would have found it obvious to modify Baude’s comparisons to explicitly determine relative relationships, i.e., whether it is greater/less than or equal to one another, with the motivation of ascertaining whether the timestamp value is up-to-date, i.e., for index reconciliation purposes).
Although Baude does not appear to explicitly state that the primary and secondary servers correspond to the claimed “metadata database” and “distributed data store”, respectively, and by extension the claimed limitation “[the table] having table data stored in a distributed data store and table metadata stored in a metadata database separate from the distributed data store”, both Baude and the claimed invention pertain to the comparison of data versions drawn from two data sources. One of ordinary skill in the art would have found it obvious, therefore, to modify Baude’s disclosure to involve a distributed data store and separate metadata database, as claimed, with predictably equivalent operating characteristics, with the motivation of separating different types of data in different locations, which reduces storage requirements for a particular location, as well as potentially reducing search/retrieval time (e.g., storage in the same location can become complex; however, it is not necessary to store metadata information with table data, and thus does not necessitate having to store them in the same location).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined the teachings of Kumar as modified and Baude (hereinafter “Kumar as modified”) with the motivation of ensuring an up-to-date index (i.e., that it represents a current state of the database) to allow optimizing functions to be available immediately so that the improved index(es) can be included in access plan determinations (Baude, [0035-0036]).
Kumar as modified does not appear to explicitly teach in response to successfully validating the index, indicating in a particular entry of the index that validation of the index has succeeded.
Reddy teaches in response to successfully validating the index, indicating in a particular entry of the index that validation of the index has succeeded (Reddy, [FIG. 6] at item 660 and [18:15-27], where after the secondary index has been completed, the system indicates that creation of the secondary index is complete.
Note that it would have been obvious to one of ordinary skill in the art to have modified Reddy by expanding the index completion to include Baude’s index validation step (and thus indicating that validation has succeeded) with the motivation of providing an indication of the progress of various index-related processing steps so that responsive actions may be taken if appropriate (Reddy, [3:54-67])).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined the teachings of Kumar and Reddy (hereinafter “Kumar as modified”) with the motivation of providing indications of secondary index creation progress so that performance changes can be made to increase (or decrease) the rate at which the secondary index is created (Reddy, [3:1-5]).
Regarding claim 2: Kumar as modified teaches The system of claim 1, wherein the operations further comprise:
prior to initiating the online index building process, receiving a statement to initiate the online index building process of the index of the hybrid table from a set of hybrid tables (Shankar, [0032], where at T1, a CREATE INDEX statement is issued, e.g., by a database administrator. See Shankar, [0028], where the index is built from one or more tables (i.e., “index of a…table from a set of tables”)), the set of hybrid tables being stored in a distributed data store provided by a networked database system (Reddy, [16:32-41], where a table may be maintained in a distributed fashion across multiple partitions in a distributed data store, where the distributed data store may be a network-based storage service (see Reddy, [12:10-27], and [Claim 19]). See Kumar above with regards to the “hybrid” table).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined the teachings of Kumar as modified and Reddy with the motivation of (1) distributing load/access operations by partitioning tables (which may be faster and more efficient to perform data retrieval operations); and (2) storing indexes and tables separately with the motivation of provisioning throughput capacity (Reddy, [17:3-25])
Regarding claim 3: Kumar as modified teaches The system of claim 2, wherein the statement comprises a particular statement to create an index (Shankar, [0032], where at T1, a CREATE INDEX statement is issued, e.g., by a database administrator).
Regarding claim 4: Kumar as modified teaches The system of claim 2, wherein the statement comprises a particular statement to alter a table with a constraint (Shankar, [0008], where DDL statements include an ALTER command, and define a table or index. See IBR-Shankar, [0025-0026], where DDL statements include a database statement that updates a constraint, implying that tables may have constraints. The role of a constraint limits values stored in a database object, e.g., a UNIQUE constraint prohibits multiple rows of a table from having the same value in the same column or combination of columns).
Regarding claim 5: Kumar as modified teaches The system of claim 4, wherein the constraint comprises that a set of values of a key is unique within the table (IBR-Shankar, [0025-0026], where DDL statements include a database statement that updates a constraint, implying that tables may have constraints. The role of a constraint limits values stored in a database object, e.g., a UNIQUE constraint prohibits multiple rows of a table from having the same value in the same column or combination of columns).
Although Kumar as modified does not appear to explicitly state that the column with a constraint corresponds to a “key” as claimed, one of ordinary skill in the art would have recognized that a key is a type of column, and thus Kumar’s constraint on the column would have been performed the same regardless of the specific data involved, i.e., a key, or some other data. Therefore, one of ordinary skill in the art would have found it obvious to have modified Kumar to include placing constraints on keys for predictably equivalent operating characteristics—which is to ensure data integrity by restricting the type/format/uniqueness of certain data values for certain columns.
Regarding claim 11: Claim 11 recites substantially the same claim limitations as claim 1, and is rejected for the same reasons.
Regarding claim 12: Claim 12 recites substantially the same claim limitations as claim 2, and is rejected for the same reasons.
Regarding claim 13: Claim 13 recites substantially the same claim limitations as claim 3, and is rejected for the same reasons.
Regarding claim 14: Claim 14 recites substantially the same claim limitations as claim 4, and is rejected for the same reasons.
Regarding claim 15: Claim 15 recites substantially the same claim limitations as claim 5, and is rejected for the same reasons.
Regarding claim 20: Claim 20 recites substantially the same claim limitations as claim 1, and is rejected for the same reasons.
Note that Kumar teaches A non-transitory computer-storage medium comprising instructions that, when executed by one or more processors of a machine, configure the machine to perform operations comprising [the claimed steps] (Shankar, [0071-0074], where the disclosed system for implementing the disclosed steps may include a main memory 506 for storing instructions to be executed by processor 504. Such instructions may be read into main memory 506 from another machine-readable medium, including non-volatile media (i.e., “non-transitory computer-readable storage medium comprising instructions”)).
Claims 6 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Kumar et al. (“Kumar”) (US 2015/0278275 A1, incorporating by reference Shankar et al. (“Shankar”) (US 2009/0037366 A1 at [0001]) and Shankar et al. (“IBR-Shankar”) (US 2009/0037417 A1)), in view of Baude et al. ("Baude") (US 2012/0330964 A1), in further view of Muniswamy Reddy et al. (“Reddy”) (US 11,327,937 B1), in further view of Sallakonda et al. (“Sallakonda”) (US 2010/0228764 A1).
Regarding claim 6: Kumar as modified teaches The system of claim 4, but does not appear to explicitly teach wherein the constraint comprises a foreign key referencing a primary key or unique key of a second table, the second table being different than the table.
Sallakonda teaches wherein the constraint comprises a foreign key referencing a primary key or unique key of a second table, the second table being different than the table (Sallakonda, [0006], where constraints associated with a database system may restrict the uniqueness of the data values stored in specific columns in the database system. With respect to foreign keys, the data values stored in a foreign key column of a table are to be restricted to the specific data values stored in the primary key column in another table, which is unique (Sallakonda, [0063]). Such a constraint is referred to as a foreign key constraint).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined the teachings of Kumar as modified and Sallakonda with the motivation of restricting the type/format/uniqueness of data values stored in specific columns in the database system (Sallakonda, [0006]), thereby maintaining database integrity.
Regarding claim 16: Claim 16 recites substantially the same claim limitations as claim 6, and is rejected for the same reasons.
Claims 7 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Kumar et al. (“Kumar”) (US 2015/0278275 A1, incorporating by reference Shankar et al. (“Shankar”) (US 2009/0037366 A1 at [0001]) and Shankar et al. (“IBR-Shankar”) (US 2009/0037417 A1)), in view of Baude et al. ("Baude") (US 2012/0330964 A1), in further view of Muniswamy Reddy et al. (“Reddy”) (US 11,327,937 B1), in further view of Guay et al. (“Guay”) (US 7,272,589 B1).
Regarding claim 7: Kumar as modified teaches The system of claim 1, wherein the operations further comprise:
determining that another index is not currently being generated (Shankar, [0012], where a CREATE INDEX statement waits for any DML statements that currently hold locks on individual rows of the table to complete before the CREATE INDEX statement begins. Once the table lock is acquired, any DML statements that require a lock on individual rows of the same table must wait until the CREATE INDEX statement completes. See also Shankar, [0031], where multiple DML statements are blocked while a CREATE INDEX statement is executed).
Kumar as modified does not appear to explicitly teach determining that a second index with a same name as the index does not exist.
Guay teaches determining that a second index with a same name as the index does not exist (Guay, [5:47-49], where a current index set analysis is performed on the current index set, i.e., the set of indexes which have already been created for the database. A proposed index set merges the current index set to form a “proposed index solution”.
Although Guay only discloses merging the proposed index set with the current index set, it would have been obvious to modify Guay to explicitly include such a comparison step during the merging process with the motivation of avoiding creating duplicate indexes, which will create possible inconsistencies in indexing (e.g., updating one of the two duplicate indexes, resulting in different sets of search results) resulting in reduced integrity, or create exact duplicates that result in the system pulling the same set of search results multiple times4, leading to inefficiencies).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined the teachings of Kumar as modified and Guay with the motivation of building an effective index for significant performance improvements in data retrieval (Guay, [1:6-11]).
Regarding claim 17: Claim 17 recites substantially the same claim limitations as claim 7, and is rejected for the same reasons.
Claims 8 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Kumar et al. (“Kumar”) (US 2015/0278275 A1, incorporating by reference Shankar et al. (“Shankar”) (US 2009/0037366 A1 at [0001]) and Shankar et al. (“IBR-Shankar”) (US 2009/0037417 A1)), in view of Baude et al. ("Baude") (US 2012/0330964 A1), in further view of Muniswamy Reddy et al. (“Reddy”) (US 11,327,937 B1), in further view of Shadmon et al. (“Shadmon”) (US 2015/0052104 A1).
Regarding claim 8: Kumar as modified teaches The system of claim 1, but does not appear to explicitly teach wherein the operations further comprise: updating a table persistence object corresponding to a table in the metadata database, the updating blocking other data definition language (DDL) operations that modify the table while the online index building process is occurring.
Shadmon teaches updating a table persistence object corresponding to a table in the metadata database, the updating blocking other data definition language (DDL) operations that modify the table while the online index building process is occurring (Shadmon, [0044], where resources that may be requested to be locked include tables; examples of types of locks that may be requested are write locks and exclusive locks (i.e., “operations that modify the table”). See Shadmon, [0046-0047], where a grant of a particular lock is maintained as an internal structure of a distributed lock manager, both of which show the details of the resource, the type of lock, etc.). These data structures (i.e., “object…corresponding to a table”) are used to evaluate new lock requests for the same resource. See, e.g., Shadmon, [0015], where a write lock may prevent other processes from adding or using the same resource at the same time (i.e., “blocking other operations that modify the table while [another] process is occurring”.
See Shankar, [0037], where a CREATE INDEX statement acquires a lock on the table to prevent any further DML statements (or DDL statements; see Shankar, [0034]) from affecting the table while the index is built (i.e., “blocking other data definition language (DDL) operations that modify the table while the online index building process is occurring”)).
Although Shadmon does not appear to explicitly state that the object pertains to a “table persistence object” corresponding to a table in a “metadata database”, as claimed, the claimed invention does not distinguish from the prior art because both the claimed invention and Shadmon disclose recording data for indicating what table is being modified, with a lock being on the entire table. Therefore, one of ordinary skill in the art would have found it obvious to modify Shadmon to more broadly include a table persistence object corresponding to a table in a metadata database, as claimed, with predictably equivalent operating characteristics—which is that tables having write locks are recorded and prevent other threads/processes from operating on them.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined the teachings of Kumar as modified and Shadmon by modifying Shankar’s disclosure of locking to explicitly include Shadmon’s locking mechanisms with the motivation of ensuring a manner of recording locks so that other processes do not improperly modify the object being locked (i.e., thereby maintaining data integrity).
Regarding claim 18: Claim 18 recites substantially the same claim limitations as claim 8, and is rejected for the same reasons.
Claims 9-10 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Kumar et al. (“Kumar”) (US 2015/0278275 A1, incorporating by reference Shankar et al. (“Shankar”) (US 2009/0037366 A1 at [0001]) and Shankar et al. (“IBR-Shankar”) (US 2009/0037417 A1)), in view of Baude et al. ("Baude") (US 2012/0330964 A1), in further view of Muniswamy Reddy et al. (“Reddy”) (US 11,327,937 B1), in further view of Guay et al. (“Guay”) (US 7,272,589 B1), in further view of Jovanovic et al. (“Jovanovic”) (US 2016/0378822 A1).
Regarding claim 9: Kumar as modified teaches The system of claim 1, but does not appear to explicitly teach wherein the operations further comprise: performing a scan of the index to check uniqueness or referential integrity validity of each index record, wherein a scanner thread is initiated that goes over the index and verifies the uniqueness or referential integrity validity of each index record in the index.
Guay teaches performing a scan of the index to check uniqueness or referential integrity validity of each index record (Guay, [12:28-40], where the solution refiner 16 eliminates any index(es) which do not enforce an integrity constraint, and whose columns are not the prefix of another index which is being used, e.g., where Idx3 cannot be eliminated because its columns are the same as some of Idx1’s columns (i.e., “referential integrity”). Because the solution refiner 16 eliminates “any” indexes within the index solution not conforming to certain requirements, this implies that the solution refiner 16 “scanned” the index, as claimed).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined the teachings of Kumar as modified and Guay (hereinafter “Kumar as modified”) with the motivation of ensuring that indexes are valid in order to achieve the advantages that indexes confer, i.e., performance improvements in data retrieval (i.e., indexes that have referential integrity issues, e.g., referencing data that has been deleted, would result in wasted processing resources/time).
Kumar as modified does not appear to explicitly teach wherein a scanner thread is initiated that goes over the index and verifies the uniqueness or referential integrity validity of each index record in the index.
Jovanovic teaches wherein a scanner thread is initiated that goes over the index and verifies the uniqueness or referential integrity validity of each index record in the index (Jovanovic, [0023], where the described components, modules, engines, and services, e.g., the validation of a created index as seen in Jovanovic, [FIGs. 8-9] and [0056-0062], may be implemented as objects or processes that execute on the computing system, e.g., as separate threads).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined the teachings of Kumar as modified and Jovanovic (hereinafter “Kumar as modified”). Guay discloses in [FIG. 1] that the index solution refiner 16 may exist in memory 216. Therefore, one of ordinary skill in the art would have found it obvious to modify Kumar as modified (i.e., Guay), to include processes executing on the computing system, e.g., as separate threads as disclosed by Jovanovic, with the motivation of enabling multiple processes to occur at once, i.e., parallel processing, resulting in potentially faster processing.5
Regarding claim 10: Kumar as modified teaches The system of claim 9, wherein the operations further comprise:
scanning, by an execution node worker, a set of active transactions, each active transaction targeting a same table, the same table corresponding to the hybrid table; and determining, by the execution node worker, that each active transaction from the set of active transactions has completed (Kumar, [0035-0039], where the DDL transaction “waits” for one or more transactions that were pending at a particular time to commit. “Waiting” involves analyzing transaction data that stores data about committed transactions, or may only include information about pending transactions. The DDL transaction will “wait” until all pending transactions that began before the timestamp have committed. If the transaction data indicates that no transaction that involves the database object is currently pending, then the system proceeds to executing the DDL statement at block 260. See Kumar, [0031], where the database object may include a table.
See Kumar, [0028], where the disclosed process 200 (which includes the steps disclosed by Kumar, [0035-0039] cited above) may be performed by a database server process (i.e., “execution node worker”) that is executing within a database management system).
Although Kumar does not appear to explicitly state that the table is a “hybrid” table as claimed, because the claimed processes may be implemented regardless of whether a “table” (as disclosed by Kumar) or a “hybrid table” (as claimed) is involved, one of ordinary skill in the art would have found it obvious to modify Kumar such that a hybrid table is operated upon. Because the claimed “hybrid table” is a type of “table”, the disclosed steps are not changed by the fact that a “hybrid” table is operated upon (versus a generic table). One of ordinary skill in the art would have been motivated to do so in order to avoid impacting overall user experience (Kumar, [0015]), regardless of the specific type of underlying table being operated upon.
Regarding claim 19: Claim 19 recites substantially the same claim limitations as claim 9, and is rejected for the same reasons.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to IRENE BAKER whose telephone number is (408)918-7601. The examiner can normally be reached M-F 8-5PM PT.
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, NEVEEN ABEL-JALIL can be reached at (571)270-0474. 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.
/IRENE BAKER/Primary Examiner, Art Unit 2152
23 November 2025
1 See claim 2 below for further detail
2 For underlined portion, see claim 2 below for further detail
3 See Remarks, pages 8-9 with respect to the 103 rejections of the claims. See also the “Response to Arguments” section above, which addressed this argument.
4 e.g., if the index “Idx1”, this will retrieve Doc1, Doc2, and Doc3, this means that Idx1 appearing X number of times will result in Doc1-3 being retrieved X times as well.
5 Nyland et al. US Patent Publication No. 2009/0240895 A1 at [0004] (“A typical parallel processing subsystem is capable of very high performance using a relatively large number of small, parallel execution threads on dedicated programmable hardware processing units. The specialized design of such parallel processing subsystems usually allows these subsystems to efficiently perform certain tasks…using a high volume of concurrent computational and memory operations. Each thread typically performs a portion of the overall task that the parallel processing subsystem is configured to perform and accesses specific memory addresses”).