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 11/19/2025 has been entered.
Claim Rejections - 35 USC § 103
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.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 30-32, 38-39, 41-43, and 49-51 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kothuri et al. (U.S. Patent No.: US 6470344 B1) hereinafter Kothuri, in view of Li et al. (U.S. Publication No.: US 20210406321 A1) hereinafter Li.
As to claim 30:
A database system comprises: a parallelized data input sub-system including pluralities of loader nodes of pluralities of computing devices of a plurality of computing device clusters, wherein a first computing device cluster of the plurality of computing device clusters includes a first plurality of computing devices of the pluralities of computing devices, wherein a first computing device of the first plurality of computing devices includes a first plurality of loader nodes of the pluralities of loader nodes, wherein a first set of loader nodes of the pluralities of loader nodes is operable to: ingest a dataset [Column 3 Lines 40-43 teach the capacity of a node may be specified as a fanout characteristic of the index or may be determined by a parameter of a suitable physical storage device (e.g., the capacity of a disk page). Column 3 Lines 60-67 teaches a first object or table in a database is configured to store information concerning the index (e.g., its dimensionality, fanout) and possibly an identifier (e.g., an address or storage location, a unique node identity) of a root node of the index. A second object or table is configured to store a record or row for each node of the index. The multi-dimensional data items may be stored in one or more objects or tables, in the same or a different database. Column 20 Lines 31-32 teach parallel processing environment multiple child nodes may be considered at once. Note: A parallel processing environment that includes storage nodes (parallelized database system) for storing a plurality of objects or tables (object storage system), wherein the plurality of objects/tables includes the claimed first dataset and first set of nodes reads on the claims.]; generate a set of dataset objects for storing the dataset [Column 3 Lines 32-36 teach a set of multi-dimensional/multi-attribute data items is indexed by recursively clustering the data items into smaller collections until each cluster can be stored (i.e., indexed) in a single leaf node of a hierarchical (e.g., tree-structured) index. Column 3 Lines 51-55 teach after leaf nodes are constructed for clusters of data items, intermediate nodes and, finally, a root node may be constructed to complete the index. Each higher-level node is designed to encompass or contain its children nodes.], wherein first data of the dataset is stored in a first object data field of a first dataset object of the set of dataset objects [Column 3 Lines 32-36 teach a set of multi-dimensional/multi-attribute data items is indexed by recursively clustering the data items into smaller collections until each cluster can be stored (i.e., indexed) in a single leaf node of a hierarchical (e.g., tree-structured) index. Column 10 Lines 48-51 teaches in state 210 an INDEX table is constructed to store the nodes of the new index and is configured to include one or more of the fields described above, and possibly other fields as well.]; generate index data for the dataset based on storage location and data characteristics of the dataset [Column 3 Lines 32-36 teach a set of multi-dimensional/multi-attribute data items is indexed by recursively clustering the data items into smaller collections until each cluster can be stored (i.e., indexed) in a single leaf node of a hierarchical (e.g., tree-structured) index. Column 3 Lines 40-43 teach the capacity of a node may be specified as a fanout characteristic of the index or may be determined by a parameter of a suitable physical storage device (e.g., the capacity of a disk page). Column 3 Lines 51-55 teach after leaf nodes are constructed for clusters of data items, intermediate nodes and, finally, a root node may be constructed to complete the index. Each higher-level node is designed to encompass or contain its children nodes.];
a set of store and compute nodes of a store and compute sub-system of the database system for storage therein [Column 3 Lines 32-36 teach a set of multi-dimensional/multi-attribute data items is indexed by recursively clustering the data items into smaller collections until each cluster can be stored (i.e., indexed) in a single leaf node of a hierarchical (e.g., tree-structured) index. Column 3 Lines 51-55 teach after leaf nodes are constructed for clusters of data items, intermediate nodes and, finally, a root node may be constructed to complete the index. Each higher-level node is designed to encompass or contain its children nodes. Column 7 Lines 63-66 teaches an R-tree suitable for storage in a database management system in a present embodiment of the invention consists of a root node and any number of leaf nodes, which may be connected to the root through a suitable quantity of intermediate nodes.]
Kothuri discloses some of the limitations as set forth in claims 30 but does not appear to expressly disclose determine whether an existing index object is available and suitable for storing the index data, when the existing index object is not suitable or available: generate a new index object, store the index data within a second object data field of the new index object; and provide the set of dataset objects and the new index object to storage.
Li discloses:
determine whether an existing index object is available and suitable for storing the index data [Paragraph 0033 teaches if data in ANN index is lost or the ANN index replicas become unavailable, a full new ANN index can be rebuilt from the vectors in master table.]; and
when the existing index object is not suitable or available: generate a new index object [Paragraph 0033 teaches if data in ANN index is lost or the ANN index replicas become unavailable, a full new ANN index can be rebuilt from the vectors in master table.];
store the index data within a second object data field of the new index object; and provide the set of dataset objects and the new index object to storage [Paragraph 0026 teaches the ANN index creation module 168 may utilize one or more ANN algorithms, such as SPTAG or HSW. The index may be stored in the index storage 180.]
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to combine the teaching of the cited references and modify the invention as taught by Kothuri, by incorporating determining whether an index object is unavailable and rebuilding a new index object for storage, as taught by Li (see Paragraph 0026 and 0033) because both publications are directed to database management; incorporating determining whether an index object is unavailable and rebuilding a new index object for storage improves performance, achieves ease, and/or reducing cost of implementation (see Li Paragraph 0087).
Claim 41 recite similar limitations as in claim 30. Therefore claim 41 is rejected for the same reasons as set forth above. See claim 30 for analysis.
As to claim 31:
Kothuri and Li discloses all of the limitations as set forth in claims 30.
Kothuri also discloses:
The database system of claim 30, wherein the at least one store and compute node is operable to store the index data in a third object data field of the existing index object and at least one store and compute node of the store and compute sub-system [Column 3 Lines 32-36 teach a set of multi-dimensional/multi-attribute data items is indexed by recursively clustering the data items into smaller collections until each cluster can be stored (i.e., indexed) in a single leaf node of a hierarchical (e.g., tree-structured) index. Column 3 Lines 51-55 teach after leaf nodes are constructed for clusters of data items, intermediate nodes and, finally, a root node may be constructed to complete the index. Each higher-level node is designed to encompass or contain its children nodes. Column 7 Lines 63-66 teaches an R-tree suitable for storage in a database management system in a present embodiment of the invention consists of a root node and any number of leaf nodes, which may be connected to the root through a suitable quantity of intermediate nodes. Column 10 Lines 48-51 teaches in state 210 an INDEX table is constructed to store the nodes of the new index and is configured to include one or more of the fields described above, and possibly other fields as well. Note: Tree data storage data structure that includes a data structure object of an index wherein the index a plurality of fields that includes a third field reads on the claims.]
Kothuri and Li discloses all of the limitations as set forth in claims 30.
Li also discloses:
wherein the first set of loader nodes is further operable to: when the existing index object is suitable and available for storing the index data: provide the set of dataset objects and the index data to storage [Paragraph 0038 teaches the Index-0 may be marked as read only such that the Index-0 408 may be available to be searched against (e.g., vector searching) but new vectors cannot be added. That is, the Index-0 408 may be utilized for searching but cannot be updated. The Index-0 408 may be stored to disk as D-0 420.]
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to combine the teaching of the cited references and modify the invention as taught by Kothuri, by incorporating determining whether an index object is available and storing that index object, as taught by Li (see Paragraph 0026 and 0033) because both publications are directed to database management; incorporating determining whether an index object is available and storing that index object improves performance, achieves ease, and/or reducing cost of implementation (see Li Paragraph 0087).
Claim 42 recite similar limitations as in claim 31. Therefore claim 42 is rejected for the same reasons as set forth above. See claim 42 for analysis.
As to claim 32:
Kothuri and Li discloses all of the limitations as set forth in claims 30.
Kothuri also discloses:
The database system of claim 30, wherein the first set of loader nodes is operable to determine whether the existing index object is available and suitable for storing the index data by: providing the data characteristics to the store and compute sub-system [Column 3 Lines 40-43 teach the capacity of a node may be specified as a fanout characteristic of the index or may be determined by a parameter of a suitable physical storage device (e.g., the capacity of a disk page).]; and
Kothuri and Li discloses all of the limitations as set forth in claims 30.
Li also discloses:
receiving an indication from storage that the existing index object is available and suitable for storing the index data [Paragraph 0038 teaches the Index-0 may be marked as read only such that the Index-0 408 may be available to be searched against (e.g., vector searching) but new vectors cannot be added. That is, the Index-0 408 may be utilized for searching but cannot be updated. The Index-0 408 may be stored to disk as D-0 420. A second index Index-1 416 may be created and marked as read and write.]
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to combine the teaching of the cited references and modify the invention as taught by Kothuri, by incorporating determining whether an index object is available, marking (indication), and storing that index object, as taught by Li (see Paragraph 0026 and 0033) because both publications are directed to database management; incorporating determining whether an index object is available and storing that index object improves performance, achieves ease, and/or reducing cost of implementation (see Li Paragraph 0087).
Claim 43 recite similar limitations as in claim 32. Therefore claim 43 is rejected for the same reasons as set forth above. See claim 32 for analysis.
As to claim 38:
Kothuri discloses:
The database system of claim 30, wherein the first data of the dataset comprises: one or more data segments; or one or more data partitions [Column 3 Lines 32-36 teach a set of multi-dimensional/multi-attribute data items is indexed by recursively clustering the data items into smaller collections until each cluster can be stored (i.e., indexed) in a single leaf node of a hierarchical (e.g., tree-structured) index.]
Claim 49 recite similar limitations as in claim 38. Therefore claim 49 is rejected for the same reasons as set forth above. See claim 38 for analysis.
As to claim 39:
Kothuri discloses:
The database system of claim 30, wherein the first set of loader nodes is further operable to: ingest a second dataset [Column 3 Lines 40-43 teach the capacity of a node may be specified as a fanout characteristic of the index or may be determined by a parameter of a suitable physical storage device (e.g., the capacity of a disk page). Column 3 Lines 60-67 teaches a first object or table in a database is configured to store information concerning the index (e.g., its dimensionality, fanout) and possibly an identifier (e.g., an address or storage location, a unique node identity) of a root node of the index. A second object or table is configured to store a record or row for each node of the index. The multi-dimensional data items may be stored in one or more objects or tables, in the same or a different database. Column 20 Lines 31-32 teach parallel processing environment multiple child nodes may be considered at once. Note: A parallel processing environment that includes storage nodes (parallelized database system) for storing a plurality of objects or tables (object storage system), wherein the plurality of objects/tables includes the claimed first dataset and first set of nodes reads on the claims.]; generate a second set of dataset objects for storing the second dataset [Column 3 Lines 32-36 teach a set of multi-dimensional/multi-attribute data items is indexed by recursively clustering the data items into smaller collections until each cluster can be stored (i.e., indexed) in a single leaf node of a hierarchical (e.g., tree-structured) index. Column 3 Lines 51-55 teach after leaf nodes are constructed for clusters of data items, intermediate nodes and, finally, a root node may be constructed to complete the index. Each higher-level node is designed to encompass or contain its children nodes.], wherein second data of the second dataset is stored in a third object data field of a second dataset object of the second set of dataset objects [Column 3 Lines 32-36 teach a set of multi-dimensional/multi-attribute data items is indexed by recursively clustering the data items into smaller collections until each cluster can be stored (i.e., indexed) in a single leaf node of a hierarchical (e.g., tree-structured) index. Column 10 Lines 48-51 teaches in state 210 an INDEX table is constructed to store the nodes of the new index and is configured to include one or more of the fields described above, and possibly other fields as well.]; generate second index data for the second dataset based on second storage location and second data characteristics of the second dataset [Column 3 Lines 32-36 teach a set of multi-dimensional/multi-attribute data items is indexed by recursively clustering the data items into smaller collections until each cluster can be stored (i.e., indexed) in a single leaf node of a hierarchical (e.g., tree-structured) index. Column 3 Lines 40-43 teach the capacity of a node may be specified as a fanout characteristic of the index or may be determined by a parameter of a suitable physical storage device (e.g., the capacity of a disk page). Column 3 Lines 51-55 teach after leaf nodes are constructed for clusters of data items, intermediate nodes and, finally, a root node may be constructed to complete the index. Each higher-level node is designed to encompass or contain its children nodes.];
Kothuri discloses some of the limitations as set forth in claims 1 but does not appear to expressly disclose determine whether a second existing index object is available and suitable for storing the second index data; and when the second existing index object is not suitable or available: generate a second index object for storing the second index data; store the second index data within a fourth object data field of the second index object; and provide the second set of dataset objects and the second index object to a second set of store and compute nodes of the database system for storage therein.
Li discloses:
determine whether a second existing index object is available and suitable for storing the second index data [Paragraph 0033 teaches if data in ANN index is lost or the ANN index replicas become unavailable, a full new ANN index can be rebuilt from the vectors in master table.]; and when the second existing index object is not suitable or available: generate a second index object for storing the second index data [Paragraph 0033 teaches if data in ANN index is lost or the ANN index replicas become unavailable, a full new ANN index can be rebuilt from the vectors in master table.]; store the second index data within a fourth object data field of the second index object; and provide the second set of dataset objects and the second index object to a second set of store and compute nodes of the database system for storage therein [Paragraph 0026 teaches the ANN index creation module 168 may utilize one or more ANN algorithms, such as SPTAG or HSW. The index may be stored in the index storage 180.]
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to combine the teaching of the cited references and modify the invention as taught by Kothuri, by incorporating determining whether an index object is unavailable and rebuilding a new index object for storage, as taught by Li (see Paragraph 0026 and 0033) because both publications are directed to database management; incorporating determining whether an index object is unavailable and rebuilding a new index object for storage improves performance, achieves ease, and/or reducing cost of implementation (see Li Paragraph 0087).
Claim 50 recite similar limitations as in claim 39. Therefore claim 50 is rejected for the same reasons as set forth above. See claim 39 for analysis.
Claim(s) 40 and 51 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kothuri et al. (U.S. Patent No.: US 6470344 B1) hereinafter Kothuri, in view of Li et al. (U.S. Publication No.: US 20210406321 A1) hereinafter Li, and further in view of Einkauf (U.S. Publication No.: US 20160323377 A1) hereinafter Einkauf.
As to claim 40:
Kothuri and Li discloses some of the limitations as set forth in claims 1 but does not appear to expressly disclose wherein the data characteristics of the dataset comprise one or more of: one or more values of one or more fields of the set of dataset objects; fields of set of the dataset objects; dataset schema; dataset object configuration data; dataset identifier; index structure information; dataset format; dataset datatype; dataset size; dataset metadata; dataset usage rules; and dataset access restrictions.
Einkauf discloses:
The database system of claim 30, wherein the data characteristics of the dataset comprise one or more of: dataset metadata [Paragraph 0130 teaches the stored objects may include object data and/or metadata.] one or more values of one or more fields of the set of dataset objects; fields of set of the dataset objects; dataset schema; dataset object configuration data; dataset identifier; index structure information; dataset format; dataset datatype; dataset size; dataset metadata; dataset usage rules; and dataset access restrictions
Claim 51 recite similar limitations as in claim 40. Therefore claim 51 is rejected for the same reasons as set forth above. See claim 40 for analysis.
Claim(s) 33 and 44 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kothuri et al. (U.S. Patent No.: US 6470344 B1) hereinafter Kothuri, in view of Li et al. (U.S. Publication No.: US 20210406321 A1) hereinafter Li, and further in view of Lightstone et al. (U.S. Patent No.: US 7028022 B1) hereinafter Lightstone.
As to claim 33:
Kothuri and Li discloses all of the limitations as set forth in claims 30 and 32.
Kothuri also discloses:
The database system of claim 32 further comprises: wherein the store and compute sub-system includes pluralities of store and compute nodes of second pluralities of computing devices of a second plurality of computing device clusters, wherein a second computing device cluster of the second plurality of computing device clusters includes a second plurality of computing devices of the second pluralities of computing devices, wherein a second computing device of the second plurality of computing devices includes a first plurality of store and compute nodes of the pluralities of store and compute nodes, wherein store and compute nodes of the pluralities of store and compute nodes [Column 3 Lines 40-43 teach the capacity of a node may be specified as a fanout characteristic of the index or may be determined by a parameter of a suitable physical storage device (e.g., the capacity of a disk page). Column 3 Lines 60-67 teaches a first object or table in a database is configured to store information concerning the index (e.g., its dimensionality, fanout) and possibly an identifier (e.g., an address or storage location, a unique node identity) of a root node of the index. A second object or table is configured to store a record or row for each node of the index. The multi-dimensional data items may be stored in one or more objects or tables, in the same or a different database. Column 20 Lines 31-32 teach parallel processing environment multiple child nodes may be considered at once. Note: A parallel processing environment that includes storage nodes (parallelized database system) for storing a plurality of objects or tables (object storage system), wherein the plurality of objects/tables includes the claimed first dataset and first set of nodes reads on the claims.] are operable to:
Kothuri and Li discloses all of the limitations as set forth in claims 30, 32, and some of 33 but does not appear to expressly disclose obtain the data characteristics; compare the data characteristics with stored data characteristics indicated in stored index objects of the store and compute sub-system; and when at least some of the data characteristics compare favorably with the stored data characteristics: determining a stored index object including the stored data characteristics having the favorable comparison as suitable for storing the index data, designating the stored index object as the existing index object; generating the indication, wherein the indication includes a location of the existing index object; and providing the indication to the first set of loader nodes.
Lightstone discloses:
obtain the data characteristics; compare the data characteristics with stored data characteristics indicated in stored index objects of the store and compute sub-system; and when at least some of the data characteristics compare favorably with the stored data characteristics: determining a stored index object including the stored data characteristics having the favorable comparison as suitable for storing the index data [Column 6 Lines 46-52 teaches a simple implementation of function F(S.sub.i) has parameters reflecting characteristics of an index 22, and compares these to a set of index characteristics at roll forward completion time which have been maintained in meta-data 16. In the specific implementation for the DB2 Universal Database, the preferred embodiment stores the number of index key operations as meta-data inside the index object meta-index.]; designating the stored index object as the existing index object; generating the indication, wherein the indication includes a location of the existing index object; and providing the indication to the first set of loader nodes [Column 7 Lines 44-52 teaches the heuristic determination function F(S.sub.i) is intended to predict which of the two methods is more efficient, given a particular combination of existing database, update data, database subsystem and environment. Once the appropriate values for the function are set for a given database subsystem and environment, it is intended that the same function F(S.sub.i) will be appropriate for different table and index combinations in different database definitions. Column 9 Lines 20-27 teaches the above table values for the function F(S.sub.i) were arrived at by taking test data and manually constructing indexes to determine the thresholds for the different heights of trees, such a process need not be carried out by a user. Once the location of the test data is indicated to the system of the preferred embodiment, it is possible for the system to run the tests to come up with the appropriate threshold values as part of the system set up.]
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to combine the teaching of the cited references and modify the invention as taught by Kothuri and Li, by incorporating comparing index values associated with characteristics and storing index objects after the comparison and providing indication as to the location, as taught by Lightstone (see Column 7 Lines 44-52 and Column 9 Lines 20-27) because the three publications are directed to database management; incorporating comparing index values associated with characteristics and storing index objects after the comparison and providing indication as to the location provides improved system for indexing data (see Lightstone Column 40 Lines 40-41).
Claim 44 recite similar limitations as in claim 33. Therefore claim 44 is rejected for the same reasons as set forth above. See claim 33 for analysis.
Claim(s) 34 and 45 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kothuri et al. (U.S. Patent No.: US 6470344 B1) hereinafter Kothuri, in view of Li et al. (U.S. Publication No.: US 20210406321 A1) hereinafter Li, and further in view of Wu (U.S. Publication No.: US 20180020069 A1) hereinafter Wu.
As to claim 34:
Kothuri and Li discloses all of the limitations as set forth in claim 30 but does not appear to expressly disclose wherein the set of store and compute nodes is operable to: determine shared characteristics between the data characteristics of the dataset and stored data characteristics of previously stored datasets, wherein the stored data characteristics are indicated in one or more stored index objects of the store and compute sub-system and send at least a portion of the index data for storage in the one or more stored index objects based on the shared characteristics.
Wu discloses:
The database system of claim 30, wherein the set of store and compute nodes is operable to: determine shared characteristics between the data characteristics of the dataset and stored data characteristics of previously stored datasets, wherein the stored data characteristics are indicated in one or more stored index objects of the store and compute sub-system [Paragraph 0028 teaches the client may then search in the first mapping relationship table consisting of mapping relations between the statistical characteristic information and the index values that is established by the client for the index value that matches the acquired statistical characteristic information, and send the index value thus found to the cloud server.]; and send at least a portion of the index data for storage in the one or more stored index objects based on the shared characteristics [Paragraph 0028 teaches the client may then search in the first mapping relationship table consisting of mapping relations between the statistical characteristic information and the index values that is established by the client for the index value that matches the acquired statistical characteristic information, and send the index value thus found to the cloud server. Note: Determining matching characteristics between data sets and sending the index data based on the determined matching to storage reads on the claims.]
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to combine the teaching of the cited references and modify the invention as taught by Kothuri and Li, by incorporating determining matching characteristics between data sets and sending the index data based on the determined matching to storage, as taught by Wu (see Paragraph 0028) because the three publications are directed to database management; incorporating determining matching characteristics between data sets and sending the index data based on the determined matching to storage provides reduced data traffic data throughput (see Wu Paragraph 0068).
Claim 45 recite similar limitations as in claim 34. Therefore claim 45 is rejected for the same reasons as set forth above. See claim 34 for analysis.
Claim(s) 35 and 46 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kothuri et al. (U.S. Patent No.: US 6470344 B1) hereinafter Kothuri, in view of Li et al. (U.S. Publication No.: US 20210406321 A1) hereinafter Li, in view of Wu (U.S. Publication No.: US 20180020069 A1) hereinafter Wu, and further in view of Grosset et al. (U.S. Publication No.: US 20080133568 A1) hereinafter Grosset.
As to claim 35:
Kothuri, Li, and Wu discloses all of the limitations as set forth in claim 30 but does not appear to expressly disclose wherein the set of store and compute nodes is operable to update the index object based on one or more of: related index data from other index objects; incoming dataset characteristics; and an index parameter change
Grossett discloses:
The database system of claim 34, wherein the set of store and compute nodes is operable to update the index object based on one or more of: related index data from other index objects; [Paragraph 0033 teaches the query engine follows relations from the identified items to identify instances of items specified in the result tree. When the query engine finishes performing the query, the query engine has constructed a result tree for each of the identified instances of the item at the root of the request tree. Each of the result trees has a structure that resembles the structure of the request tree. Paragraph 0043 teaches database query engine 62 may then apply the queries to the associative database to obtain result trees containing the items identified by the queries. Results module 64 may then derive index values and measure values from the result trees. After deriving index values and measure values, results module 64 uses the derived index values and data values to build the multidimensional dataset. Node: Loading query results in into result trees that includes indices, wherein the cited plurality of trees reasonably includes a third set of nodes of the plurality of nodes and the results are interpreted to be the second plurality of objects used to update the cited index values (plurality of index object) reads on the claims.] incoming dataset characteristics; and an index parameter change
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to combine the teaching of the cited references and modify the invention as taught by Kothuri, Li, and Wu, by incorporating loading query results in into result trees that includes indices (set of nodes), wherein the cited plurality of trees reasonably includes a third set of nodes of the plurality of nodes, as taught by Grosset (see Paragraph 0033 and 0034) because the four applications are directed to database management; incorporating loading query results in into result trees that includes indices (set of nodes), wherein the cited plurality of trees reasonably includes a third set of nodes of the plurality of nodes offers several advantages over conventional relational databases (see Grosset Paragraph 0048).
Claim 46 recite similar limitations as in claim 35. Therefore claim 46 is rejected for the same reasons as set forth above. See claim 35 for analysis.
Claim(s) 36 and 47 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kothuri et al. (U.S. Patent No.: US 6470344 B1) hereinafter Kothuri, in view of Li et al. (U.S. Publication No.: US 20210406321 A1) hereinafter Li, in view of Wu (U.S. Publication No.: US 20180020069 A1) hereinafter Wu, in view of Grosset et al. (U.S. Publication No.: US 20080133568 A1) hereinafter Grosset, and further in view of Einkauf (U.S. Publication No.: US 20160323377 A1) hereinafter Einkauf
As to claim 36:
Kothuri, Li, Wu, and Grosset discloses all of the limitations as set forth in claim 30, 34, and 35 but does not appear to expressly disclose wherein the set of store and compute nodes is operable to update the index object by one or more of: aggregating received index data with the index data; appending the received index data with the index data; and deleting a portion of the index data.
Einkauf discloses
The database system of claim 35, wherein the set of store and compute nodes is operable to update the index object by one or more of: and deleting a portion of the index data [Paragraph 0130 teaches the stored objects may include object data and/or metadata. For example, each object may include a data object portion, and a metadata portion. In some embodiments, every object may be contained in a bucket, and every object may be addressable using a combination of a bucket identifier and one or more identifiers of the object itself (e.g., a user key or a combination or a user key and a version identifier). Paragraph 0137 teaches the storage systems described herein may include support for the following storage related tasks: creating buckets, storing and retrieving data in buckets (e.g., using a unique key, which may be assigned by the developer of the data or owner of the bucket), deleting data, and/or listing stored objects.] aggregating received index data with the index data; appending the received index data with the index data;
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to combine the teaching of the cited references and modify the invention as taught by Kothuri, Li, Wu, and Grosset, by incorporating objects that include data, metadata, unique identifier associated with a policy (globally unique identifier), wherein the updates includes deleting, as taught by Einkauf (see Paragraph 0130 and 0137) because the four publications are directed to database management; incorporating objects that include data, metadata, unique identifier associated with a policy (globally unique identifier), wherein the updates includes deleting may have advantages, including, but not limited to, the ability to store very large data sets, high throughput, reliability and high availability due to features such as data replication, and flexibility (see Einkauf Paragraph 0146).
Claim 47 recite similar limitations as in claim 36. Therefore claim 47 is rejected for the same reasons as set forth above. See claim 36 for analysis.
Claim(s) 37 and 48 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kothuri et al. (U.S. Patent No.: US 6470344 B1) hereinafter Kothuri, in view of Li et al. (U.S. Publication No.: US 20210406321 A1) hereinafter Li, and further in view of Das et al. (U.S. Publication No.: US 20090030883 A1) hereinafter Das.
As to claim 37:
Kothuri and Li discloses all of the limitations as set forth in claim 30.
Kothuri also discloses:
The database system of claim 30 further comprises: a query and response sub-system including pluralities of computing nodes of second pluralities of computing devices of a second plurality of computing device clusters, wherein a second computing device cluster of the second plurality of computing device clusters includes a second plurality of computing devices of the second pluralities of computing devices, wherein a second computing device of the second plurality of computing devices includes a first plurality of computing nodes of the pluralities of computing nodes [Column 3 Lines 40-43 teach the capacity of a node may be specified as a fanout characteristic of the index or may be determined by a parameter of a suitable physical storage device (e.g., the capacity of a disk page). Column 3 Lines 60-67 teaches a first object or table in a database is configured to store information concerning the index (e.g., its dimensionality, fanout) and possibly an identifier (e.g., an address or storage location, a unique node identity) of a root node of the index. A second object or table is configured to store a record or row for each node of the index. The multi-dimensional data items may be stored in one or more objects or tables, in the same or a different database. Column 11 Lines 42-43 teaches a multi-dimensional data index may allow all desired data to be retrieved in a single query. Column 20 Lines 31-32 teach parallel processing environment multiple child nodes may be considered at once. Note: A parallel processing environment that includes storage nodes (parallelized database system) for storing a plurality of objects or tables (object storage system), wherein the plurality of objects/tables includes the claimed first dataset and first set of nodes reads on the claims.],:
Kothuri and Li discloses all of the limitations as set forth in claim 30 but does not appear to expressly disclose a query and response sub-system including pluralities of computing nodes of second pluralities of computing devices of a second plurality of computing device clusters, wherein a second computing device cluster of the second plurality of computing device clusters includes a second plurality of computing devices of the second pluralities of computing devices, wherein a second computing device of the second plurality of computing devices includes a first plurality of computing nodes of the pluralities of computing nodes, wherein a set of computing nodes of the pluralities of computing nodes is operable to: obtain a query regarding data of the dataset, wherein the query includes a plurality of sets of code terms; parse the query to determine a set of input/output (IO) code terms of the plurality of sets of code terms, wherein the set of IO code terms is related to data access and data access optimization; and generate an index IO pipeline element of an IO pipeline for executing at least a portion of the set of IO code terms on the data of the dataset, wherein the index IO pipeline element is operable to: access the index object; identify rows of the data, via the index object, that are relevant to the at least the portion of the set of IO code terms to produce a filtered row list; and provide the filtered row list to other elements of the IO pipeline.
Das discloses:
wherein a set of computing nodes of the pluralities of computing nodes is operable to obtain a query regarding data of the dataset, wherein the query includes a plurality of sets of code terms; parse the query to determine a set of input/output (IO) code terms of the plurality of sets of code terms, wherein the set of IO code terms is related to data access and data access optimization [Paragraph 0049 teaches the query optimizer of the database server would recognize when a filtering predicate and an ORDER BY clause of a database query (that references the "DOC" table) can be evaluated by the user-defined index "DOCIDX". Paragraph 0051 teaches after the function of the "DOCIDX" index evaluates the query against the index entries, the function returns to the database server a set of row identifiers. The returned set of row identifiers identifies those rows of table "DOC" which satisfy both the query predicate that specifies the "CONTAINS" operator and the query predicate "pub_date between `Jan. 1, 2007` and `Dec. 31, 2007`". In addition, the returned set of row identifiers is sorted according to the "pub_date" as specified in the ORDER BY clause of query "Q1". The database server then generates the result set of rows for query "Q1" by retrieving the rows identified by the returned set of row identifiers in the order specified therein.]; and generate an index IO pipeline element of an IO pipeline for executing at least a portion of the set of IO code terms on the data of the dataset, wherein the index IO pipeline element is operable to: access the index object [Paragraph 0051 teaches after the function of the "DOCIDX" index evaluates the query against the index entries, the function returns to the database server a set of row identifiers. The returned set of row identifiers identifies those rows of table "DOC" which satisfy both the query predicate that specifies the "CONTAINS" operator and the query predicate "pub_date between `Jan. 1, 2007` and `Dec. 31, 2007`". In addition, the returned set of row identifiers is sorted according to the "pub_date" as specified in the ORDER BY clause of query "Q1". The database server then generates the result set of rows for query "Q1" by retrieving the rows identified by the returned set of row identifiers in the order specified therein.]; identify rows of the data, via the index object, that are relevant to the at least the portion of the set of IO code terms to produce a filtered row list [Paragraph 0034 teaches when invoked, the functions scan (or otherwise use) index entries 114 to determine a set of row identifiers that identify a set of rows in accordance with the function arguments. (A row identifier is a reference value that uniquely identifies a particular row in a particular table and indicates the location of the row within the storage space allocated to the table.) For example, when the function arguments specify one or more conditions that need to be evaluated according to a particular auxiliary property, the invoked functions would determine the set of row identifiers that identify those rows which satisfy the one or more conditions. Paragraph 0050 teaches evaluating query "Q1" according to this execution plan would involve the database server or a component thereof invoking a function of the "DOCIDX" index; when invoked the function: evaluates the query predicate that specifies the "CONTAINS" operator; evaluates the condition specified in the query predicate "pub_date between `Jan. 1, 2007` and `Dec. 31, 2007`" by filtering out the index entries which correspond to data rows in which the value in the "pub_date" column is not within the values of "Jan, 1, 2007" and "Dec. 31, 2007"; and evaluates the ORDER BY clause ("order by pub_date") of query "Q1" by sorting the index entries according to the values of the "pub_date" column in the corresponding data rows.]; and
provide the filtered row list to other elements of the IO pipeline [Paragraph 0034 teaches evaluates the condition specified in the query predicate "pub_date between `Jan. 1, 2007` and `Dec. 31, 2007`" by filtering out the index entries which correspond to data rows in which the value in the "pub_date" column is not within the values of "Jan, 1, 2007" and "Dec. 31, 2007"; and evaluates the ORDER BY clause ("order by pub_date") of query "Q1" by sorting the index entries according to the values of the "pub_date" column in the corresponding data rows. Paragraph 0051 teaches after the function of the "DOCIDX" index evaluates the query against the index entries, the function returns to the database server a set of row identifiers. The returned set of row identifiers identifies those rows of table "DOC" which satisfy both the query predicate that specifies the "CONTAINS" operator and the query predicate "pub_date between `Jan. 1, 2007` and `Dec. 31, 2007`". In addition, the returned set of row identifiers is sorted according to the "pub_date" as specified in the ORDER BY clause of query "Q1". The database server then generates the result set of rows for query "Q1" by retrieving the rows identified by the returned set of row identifiers in the order specified therein.]
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to combine the teaching of the cited references and modify the invention as taught by Kothuri and Li, by incorporating receiving a query with parameters for filtering rows of requested data, as taught by Das (see Paragraph 0034 and 0051) because the three publications are directed to database management; incorporating receiving a query with parameters for filtering rows of requested data provides the desired functionality and returns the appropriate results (see Das Paragraph 0016).
Claim 48 recite similar limitations as in claim 37. Therefore claim 48 is rejected for the same reasons as set forth above. See claim 37 for analysis.
Response to Arguments
Applicant’s arguments with respect to 35 USC § 103 rejections directed to claims 30-51 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to EARL LEVI ELIAS whose telephone number is (571)272-9762. The examiner can normally be reached Monday - Friday (IFP).
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, Sherief Badawi can be reached at 571-272-9782. 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.
/EARL LEVI ELIAS/Examiner, Art Unit 2169
/SHERIEF BADAWI/Supervisory Patent Examiner, Art Unit 2169
Prosecution Insights