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 .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on November 18, 2024 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 15-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claims do not fall within at least one of the four categories of patent eligible subject matter because claim 15 recites “a computing device.” The filed specification states “computing device such as a desktop computer, a laptop computer, a handheld computer, a tablet computer, a personal digital assistant (PDA), a cellular telephone, a network appliance, a camera, a smart phone, an enhanced general packet radio service (EGPRS) mobile phone, a media player, a navigation device, an email device, a game console, or an appropriate combination of any two or more of these devices or other data processing devices” (see [0026], emphasis added). This allows the claim to encompass software per se, which is not a “process,” a “machine,” a “manufacture,” or a “composition of matter” as defined in 35 U.S.C. § 101. Examiner suggests amending claim 15 to include a processor.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Rajan et al. (US Publication No. 2019/0108248) in view of Prasad et al. (US Publication No. 2022/0207011).
As to claim 1, Rajan teaches a computer-implemented method for maintaining tenant-specific table indexes [custom indexes] in database systems executed in cloud computing environments (see e.g., [0012] for creating custom indexes being implemented in a system having an application server providing a front end for an on-demand database service capable of supporting multiple tenants), the method being executed by one or more processors and comprising:
receiving first metrics [run time and frequency of use] representative of execution of a first query within the database system [multi-tenant database], the first query being in a set of queries executed by a tenant within the database system (see e.g., [0087] for the queries being directed to a multi-tenant database, [0088] for queries submitted in production, that is queries submitted by users being monitored and if a particular query runs slowly, or has slow performance then it being flagged for later analysis, [0096] for the queries being captured before, during, or after execution, and [0097] for the query being analyzed to determine whether it is a candidate for a custom index, in one example, the query being a candidate if it runs slowly or if it times out, and additional criteria also being used such as whether the query uses a filter or whether the query is used frequently and applies to a large database. Metrics of a query executed upon a multi-tenant database are received, which include run time and frequency of use.);
determining, responsive to the first metrics, that the first query is to be processed for indexing of one or more columns (see e.g., [0050] for the multi-tenant data structure being defined having data fields in columns and rows for each of multiple tenants, each row including a data column for a tenant identifier, a first data field with a first data type being defined for a tenant, and a second data field with a second data type being defined for the tenant, and the index table being defined with a tenant identifier for the tenant, a copy of data from the first data field and the second data field, and a key to the corresponding rows of the multi-tenant data structure and [0097] for the query being analyzed to determine whether it is a candidate for a custom index, in one example, the query being a candidate if it runs slowly or if it times out, and additional criteria also being used such as whether the query uses a filter or whether the query is used frequently and applies to a large database. Based on run time and frequency of use, it is determined that the query is to be processed for indexing columns.);
providing a set of columns [first data field and second data field] for the first query (see e.g., [0050] for the multi-tenant data structure being defined having data fields in columns and rows for each of multiple tenants, each row including a data column for a tenant identifier, a first data field with a first data type being defined for a tenant, and a second data field with a second data type being defined for the tenant, and the index table being defined with a tenant identifier for the tenant, a copy of data from the first data field and the second data field, and a key to the corresponding rows of the multi-tenant data structure and [0097] for the query being analyzed to determine whether it is a candidate for a custom index. A custom index for the query is provided with a first data field and a second data field.); and
for each column in the set of columns, selectively updating a table index [index table] of the tenant within the database system to include an index on the column at least partially in response to a data type of the column (see e.g., [0050] for the multi-tenant data structure being defined having data fields in columns and rows for each of multiple tenants, each row including a data column for a tenant identifier, a first data field with a first data type being defined for a tenant, and a second data field with a second data type being defined for the tenant, and the index table being defined with a tenant identifier for the tenant, a copy of data from the first data field and the second data field, and a key to the corresponding rows of the multi-tenant data structure, [0057] for custom indexes being provided after they are generated to an Index Table 113 ,[0101] for the data types affected by the query being analyzed and this including the columns used by the captured query, where the columns indicate the data field or the nature of the data, and [0103] for a custom index being generated based on determined data types. The index table is updated to include an index on the first data field and the second data field at least partially in response to a data type of the first data field and the second data field.).
Rajan does not specifically disclose for each column in the set of columns, selectively updating a table index within the database system to include an index on the column at least partially in response to a function on the column within the query. However, Prasad teaches
for each column in the set of columns, selectively updating a table index [MIS] within the database system to include an index on the column at least partially in response to a function [MIN/MAX] on the column within the query (see e.g., [0044] for Metadata Index Subtable (MIS) and the MIS being a separate subtable maintained for a column-partitioned base table, wherein the MIS is used to store the metadata for each column partition, [0074] for identifying Columns for Creation of the MIS, [0077] for based upon query type, and [0078] for a MIN/MAX aggregate query 200 without any GROUP BY clauses, the underlying columns resulting in the creation of the MIS 500. The MIS within the database system is selectively updated to include each column at least partially in response to a MIN/MAX function on each column within the query.).
It would have been obvious to one of ordinary skill in the art prior to the effective filing date of the claimed invention to modify the index table of Rajan to for each column in the set of columns, selectively update a table index within the database system to include an index on the column at least partially in response to a function on the column within the query, as taught by Prasad, for the benefit of performing the query using only the index without accessing the base table (see e.g., Prasad, [0078]).
As to claim 2, the limitations of parent claim 1 have been discussed above. Rajan teaches
wherein selectively updating the table index of the tenant within the database system to include an index on the column is further in response to determining that the column is indexable using a list of columns [query table] (see e.g., [0057] for custom indexes being provided after they are generated to an Index Table 113, [0091] for Selectivity Tester 205 being used to compile a table 207 of custom index candidates, this table including an identifier for each query, the filters that the query uses and other information about the query, for example, the filter analyzer 203 determining the operators and data types for the query, these being included in the table, and in addition, bibliographic information about each query being included, such as the developer, the owner, the organization that uses it, etc., [0093] for the Custom Index Generator 111 of the system using the data in the table to make autonomous automatic decisions about generating a custom index. The query table includes custom index candidates, which includes columns. The Custom Index Generator determines indexable columns from the query table. These columns are added to the index table.).
As to claim 3, the limitations of parent claim 1 have been discussed above. Rajan teaches wherein determining, responsive to the first metrics, that the first query is to be processed for indexing of one or more columns comprises:
determining that the query has been executed at least a threshold number of times [frequency] in a time window [production] (see e.g., [0087] for the queries being directed to a multi-tenant database, [0088] for queries submitted in production, that is queries submitted by users being monitored and if a particular query runs slowly, or has slow performance then it being flagged for later analysis, [0096] for the queries being captured before, during, or after execution, and [0097] for the query being analyzed to determine whether it is a candidate for a custom index, in one example, the query being a candidate if it runs slowly or if it times out, and additional criteria also being used such as whether the query uses a filter or whether the query is used frequently and applies to a large database. Metrics of a query executed upon a multi-tenant database are received, which include run time and frequency of use. Based on frequency of use, it is determined that the query is to be processed for indexing columns.); and
determining that time cost [run time] of the query exceeds a threshold time cost (see e.g., [0087] for the queries being directed to a multi-tenant database, [0088] for queries submitted in production, that is queries submitted by users being monitored and if a particular query runs slowly, or has slow performance then it being flagged for later analysis, [0096] for the queries being captured before, during, or after execution, and [0097] for the query being analyzed to determine whether it is a candidate for a custom index, in one example, the query being a candidate if it runs slowly or if it times out, and additional criteria also being used such as whether the query uses a filter or whether the query is used frequently and applies to a large database. Metrics of a query executed upon a multi-tenant database are received, which include run time and frequency of use. Based on run time, it is determined that the query is to be processed for indexing columns.).
As to claim 4, the limitations of parent claim 1 have been discussed above. Rajan teaches
wherein the table index is initialized within the database system to include indexes on columns [standard fields] common to all tenants of the database system (see e.g., [0057] for custom indexes being provided after they are generated to an Index Table 113, [0065] for a custom index being created on standard fields, and [0141] for standard entity tables being provided for use by all tenants and for CRM database applications, such standard entities including tables for Account, Contact, Lead, and Opportunity data, each containing pre-defined fields. The index table is initialized to include indexes on standard fields, which are common to all tenants.).
As to claim 5, the limitations of parent claim 1 have been discussed above. Rajan teaches
receiving usage metrics [frequency of use] for a column having an index on the column for the tenant (see e.g., [0051] for performance being further enhanced and data storage reduced, by monitoring 112 the new custom indexes and after the indexes are created 110 a list being created to monitor 112 the created additional filter for frequency of use 114 or some other criteria and [0052] for in one example, a black tab page being used to store information about created indexes, this allowing reports to be run and other analytics to be performed, the indexes being scrutinized to check whether created indexes are being used, and a black tab page allowing for a check for how many indexes were created, how many times they are used, what the buffer gets were before the index was created, what the buffer gets were after the index was created, and more metrics); and
selectively deleting the index on the column responsive to the usage metrics (see e.g., [0051] for the created additional filter then being removed 116 if it is not used more frequently than a predefined number of times in a predefined duration of time and [0052] for the indexes being scrutinized to check whether created indexes are being used and providing an alert if they are not and in that case, the index being dropped.).
As to claim 6, the limitations of parent claims 1 and 5 have been discussed above. Rajan teaches
wherein the index on the column is deleted in response to the usage metrics indicating that the index on the column has not been used at least a threshold number of times [predefined number of times] within a time window [predefined duration of time] (see e.g., [0051] for performance being further enhanced and data storage reduced, by monitoring 112 the new custom indexes, after the indexes are created 110 a list being created to monitor 112 the created additional filter for frequency of use 114 or some other criteria, and the created additional filter then being removed 116 if it is not used more frequently than a predefined number of times in a predefined duration of time).
As to claim 7, the limitations of parent claim 1 have been discussed above. Rajan teaches
receiving second metrics [run time and frequency of use] representative of execution of a second query within the database system, the second query being in the set of queries executed by the tenant within the database system (see e.g., [0087] for the queries being directed to a multi-tenant database, [0088] for queries submitted in production, that is queries submitted by users being monitored and if a particular query runs slowly, or has slow performance then it being flagged for later analysis, [0096] for the queries being captured before, during, or after execution, and [0097] for the query being analyzed to determine whether it is a candidate for a custom index, in one example, the query being a candidate if it runs slowly or if it times out, and additional criteria also being used such as whether the query uses a filter or whether the query is used frequently and applies to a large database. Metrics of a query executed upon a multi-tenant database are received, which include run time and frequency of use.); and
determining, responsive to the second metrics, that the second query is not to be processed for indexing of one or more columns (see e.g., [0050] for the multi-tenant data structure being defined having data fields in columns and rows for each of multiple tenants, each row including a data column for a tenant identifier, a first data field with a first data type being defined for a tenant, and a second data field with a second data type being defined for the tenant, and the index table being defined with a tenant identifier for the tenant, a copy of data from the first data field and the second data field, and a key to the corresponding rows of the multi-tenant data structure and [0097] for the query being analyzed to determine whether it is a candidate for a custom index, in one example, the query being a candidate if it runs slowly or if it times out, and additional criteria also being used such as whether the query uses a filter or whether the query is used frequently and applies to a large database. Based on run time and frequency of use, it is determined that the query is not to be processed for indexing columns.).
As to claim 8, Rajan teaches a non-transitory computer-readable storage medium coupled to one or more processors and having instructions stored thereon which, when executed by the one or more processors (see e.g., [0131] for a computer program product embodiment includes a machine-readable storage medium (media) having instructions stored thereon/in which can be used to program a computer to perform any of the processes of the embodiments described herein), cause the one or more processors to perform operations for maintaining tenant-specific table indexes [custom indexes] in database systems executed in cloud computing environments (see e.g., [0012] for creating custom indexes being implemented in a system having an application server providing a front end for an on-demand database service capable of supporting multiple tenants), the operations comprising:
receiving first metrics [run time and frequency of use] representative of execution of a first query within the database system [multi-tenant database], the first query being in a set of queries executed by a tenant within the database system (see e.g., [0087] for the queries being directed to a multi-tenant database, [0088] for queries submitted in production, that is queries submitted by users being monitored and if a particular query runs slowly, or has slow performance then it being flagged for later analysis, [0096] for the queries being captured before, during, or after execution, and [0097] for the query being analyzed to determine whether it is a candidate for a custom index, in one example, the query being a candidate if it runs slowly or if it times out, and additional criteria also being used such as whether the query uses a filter or whether the query is used frequently and applies to a large database. Metrics of a query executed upon a multi-tenant database are received, which include run time and frequency of use.);
determining, responsive to the first metrics, that the first query is to be processed for indexing of one or more columns (see e.g., [0050] for the multi-tenant data structure being defined having data fields in columns and rows for each of multiple tenants, each row including a data column for a tenant identifier, a first data field with a first data type being defined for a tenant, and a second data field with a second data type being defined for the tenant, and the index table being defined with a tenant identifier for the tenant, a copy of data from the first data field and the second data field, and a key to the corresponding rows of the multi-tenant data structure and [0097] for the query being analyzed to determine whether it is a candidate for a custom index, in one example, the query being a candidate if it runs slowly or if it times out, and additional criteria also being used such as whether the query uses a filter or whether the query is used frequently and applies to a large database. Based on run time and frequency of use, it is determined that the query is to be processed for indexing columns.);
providing a set of columns [first data field and second data field] for the first query (see e.g., [0050] for the multi-tenant data structure being defined having data fields in columns and rows for each of multiple tenants, each row including a data column for a tenant identifier, a first data field with a first data type being defined for a tenant, and a second data field with a second data type being defined for the tenant, and the index table being defined with a tenant identifier for the tenant, a copy of data from the first data field and the second data field, and a key to the corresponding rows of the multi-tenant data structure and [0097] for the query being analyzed to determine whether it is a candidate for a custom index. A custom index for the query is provided with a first data field and a second data field.); and
for each column in the set of columns, selectively updating a table index [index table] of the tenant within the database system to include an index on the column at least partially in response to a data type of the column (see e.g., [0050] for the multi-tenant data structure being defined having data fields in columns and rows for each of multiple tenants, each row including a data column for a tenant identifier, a first data field with a first data type being defined for a tenant, and a second data field with a second data type being defined for the tenant, and the index table being defined with a tenant identifier for the tenant, a copy of data from the first data field and the second data field, and a key to the corresponding rows of the multi-tenant data structure, [0057] for custom indexes being provided after they are generated to an Index Table 113 ,[0101] for the data types affected by the query being analyzed and this including the columns used by the captured query, where the columns indicate the data field or the nature of the data, and [0103] for a custom index being generated based on determined data types. The index table is updated to include an index on the first data field and the second data field at least partially in response to a data type of the first data field and the second data field.).
Rajan does not specifically disclose for each column in the set of columns, selectively updating a table index within the database system to include an index on the column at least partially in response to a function on the column within the query. However, Prasad teaches
for each column in the set of columns, selectively updating a table index [MIS] within the database system to include an index on the column at least partially in response to a function [MIN/MAX] on the column within the query (see e.g., [0044] for Metadata Index Subtable (MIS) and the MIS being a separate subtable maintained for a column-partitioned base table, wherein the MIS is used to store the metadata for each column partition, [0074] for identifying Columns for Creation of the MIS, [0077] for based upon query type, and [0078] for a MIN/MAX aggregate query 200 without any GROUP BY clauses, the underlying columns resulting in the creation of the MIS 500. The MIS within the database system is selectively updated to include each column at least partially in response to a MIN/MAX function on each column within the query.).
It would have been obvious to one of ordinary skill in the art prior to the effective filing date of the claimed invention to modify the index table of Rajan to for each column in the set of columns, selectively update a table index within the database system to include an index on the column at least partially in response to a function on the column within the query, as taught by Prasad, for the benefit of performing the query using only the index without accessing the base table (see e.g., Prasad, [0078]).
As to claim 9, the limitations of parent claim 8 have been discussed above. Rajan teaches
wherein selectively updating the table index of the tenant within the database system to include an index on the column is further in response to determining that the column is indexable using a list of columns [query table] (see e.g., [0057] for custom indexes being provided after they are generated to an Index Table 113, [0091] for Selectivity Tester 205 being used to compile a table 207 of custom index candidates, this table including an identifier for each query, the filters that the query uses and other information about the query, for example, the filter analyzer 203 determining the operators and data types for the query, these being included in the table, and in addition, bibliographic information about each query being included, such as the developer, the owner, the organization that uses it, etc., [0093] for the Custom Index Generator 111 of the system using the data in the table to make autonomous automatic decisions about generating a custom index. The query table includes custom index candidates, which includes columns. The Custom Index Generator determines indexable columns from the query table. These columns are added to the index table.).
As to claim 10, the limitations of parent claim 8 have been discussed above. Rajan teaches wherein determining, responsive to the first metrics, that the first query is to be processed for indexing of one or more columns comprises:
determining that the query has been executed at least a threshold number of times [frequency] in a time window [production] (see e.g., [0087] for the queries being directed to a multi-tenant database, [0088] for queries submitted in production, that is queries submitted by users being monitored and if a particular query runs slowly, or has slow performance then it being flagged for later analysis, [0096] for the queries being captured before, during, or after execution, and [0097] for the query being analyzed to determine whether it is a candidate for a custom index, in one example, the query being a candidate if it runs slowly or if it times out, and additional criteria also being used such as whether the query uses a filter or whether the query is used frequently and applies to a large database. Metrics of a query executed upon a multi-tenant database are received, which include run time and frequency of use. Based on frequency of use, it is determined that the query is to be processed for indexing columns.); and
determining that time cost [run time] of the query exceeds a threshold time cost (see e.g., [0087] for the queries being directed to a multi-tenant database, [0088] for queries submitted in production, that is queries submitted by users being monitored and if a particular query runs slowly, or has slow performance then it being flagged for later analysis, [0096] for the queries being captured before, during, or after execution, and [0097] for the query being analyzed to determine whether it is a candidate for a custom index, in one example, the query being a candidate if it runs slowly or if it times out, and additional criteria also being used such as whether the query uses a filter or whether the query is used frequently and applies to a large database. Metrics of a query executed upon a multi-tenant database are received, which include run time and frequency of use. Based on run time, it is determined that the query is to be processed for indexing columns.).
As to claim 11, the limitations of parent claim 8 have been discussed above. Rajan teaches
wherein the table index is initialized within the database system to include indexes on columns [standard fields] common to all tenants of the database system (see e.g., [0057] for custom indexes being provided after they are generated to an Index Table 113, [0065] for a custom index being created on standard fields, and [0141] for standard entity tables being provided for use by all tenants and for CRM database applications, such standard entities including tables for Account, Contact, Lead, and Opportunity data, each containing pre-defined fields. The index table is initialized to include indexes on standard fields, which are common to all tenants.).
As to claim 12, the limitations of parent claim 8 have been discussed above. Rajan teaches
receiving usage metrics [frequency of use] for a column having an index on the column for the tenant (see e.g., [0051] for performance being further enhanced and data storage reduced, by monitoring 112 the new custom indexes and after the indexes are created 110 a list being created to monitor 112 the created additional filter for frequency of use 114 or some other criteria and [0052] for in one example, a black tab page being used to store information about created indexes, this allowing reports to be run and other analytics to be performed, the indexes being scrutinized to check whether created indexes are being used, and a black tab page allowing for a check for how many indexes were created, how many times they are used, what the buffer gets were before the index was created, what the buffer gets were after the index was created, and more metrics); and
selectively deleting the index on the column responsive to the usage metrics (see e.g., [0051] for the created additional filter then being removed 116 if it is not used more frequently than a predefined number of times in a predefined duration of time and [0052] for the indexes being scrutinized to check whether created indexes are being used and providing an alert if they are not and in that case, the index being dropped.).
As to claim 13, the limitations of parent claims 8 and 12 have been discussed above. Rajan teaches
wherein the index on the column is deleted in response to the usage metrics indicating that the index on the column has not been used at least a threshold number of times [predefined number of times] within a time window [predefined duration of time] (see e.g., [0051] for performance being further enhanced and data storage reduced, by monitoring 112 the new custom indexes, after the indexes are created 110 a list being created to monitor 112 the created additional filter for frequency of use 114 or some other criteria, and the created additional filter then being removed 116 if it is not used more frequently than a predefined number of times in a predefined duration of time).
As to claim 14, the limitations of parent claim 8 have been discussed above. Rajan teaches
receiving second metrics [run time and frequency of use] representative of execution of a second query within the database system, the second query being in the set of queries executed by the tenant within the database system (see e.g., [0087] for the queries being directed to a multi-tenant database, [0088] for queries submitted in production, that is queries submitted by users being monitored and if a particular query runs slowly, or has slow performance then it being flagged for later analysis, [0096] for the queries being captured before, during, or after execution, and [0097] for the query being analyzed to determine whether it is a candidate for a custom index, in one example, the query being a candidate if it runs slowly or if it times out, and additional criteria also being used such as whether the query uses a filter or whether the query is used frequently and applies to a large database. Metrics of a query executed upon a multi-tenant database are received, which include run time and frequency of use.); and
determining, responsive to the second metrics, that the second query is not to be processed for indexing of one or more columns (see e.g., [0050] for the multi-tenant data structure being defined having data fields in columns and rows for each of multiple tenants, each row including a data column for a tenant identifier, a first data field with a first data type being defined for a tenant, and a second data field with a second data type being defined for the tenant, and the index table being defined with a tenant identifier for the tenant, a copy of data from the first data field and the second data field, and a key to the corresponding rows of the multi-tenant data structure and [0097] for the query being analyzed to determine whether it is a candidate for a custom index, in one example, the query being a candidate if it runs slowly or if it times out, and additional criteria also being used such as whether the query uses a filter or whether the query is used frequently and applies to a large database. Based on run time and frequency of use, it is determined that the query is not to be processed for indexing columns.).
As to claim 15, Rajan teaches a system, comprising:
a computing device (see e.g., [0131] for system 616 (and additional instances of an MTS, where more than one is present) and all of their components being operator configurable using application(s) including computer code to run using a central processing unit such as processor system 617, which may include an Intel Pentium® processor or the like, and/or multiple processor units); and
a computer-readable storage device coupled to the computing device and having instructions stored thereon which, when executed by the computing device (see e.g., [0131] for a computer program product embodiment includes a machine-readable storage medium (media) having instructions stored thereon/in which can be used to program a computer to perform any of the processes of the embodiments described herein), cause the computing device to perform operations for maintaining tenant-specific table indexes [custom indexes] in database systems executed in cloud computing environments (see e.g., [0012] for creating custom indexes being implemented in a system having an application server providing a front end for an on-demand database service capable of supporting multiple tenants), the operations comprising:
receiving first metrics [run time and frequency of use] representative of execution of a first query within the database system [multi-tenant database], the first query being in a set of queries executed by a tenant within the database system (see e.g., [0087] for the queries being directed to a multi-tenant database, [0088] for queries submitted in production, that is queries submitted by users being monitored and if a particular query runs slowly, or has slow performance then it being flagged for later analysis, [0096] for the queries being captured before, during, or after execution, and [0097] for the query being analyzed to determine whether it is a candidate for a custom index, in one example, the query being a candidate if it runs slowly or if it times out, and additional criteria also being used such as whether the query uses a filter or whether the query is used frequently and applies to a large database. Metrics of a query executed upon a multi-tenant database are received, which include run time and frequency of use.);
determining, responsive to the first metrics, that the first query is to be processed for indexing of one or more columns (see e.g., [0050] for the multi-tenant data structure being defined having data fields in columns and rows for each of multiple tenants, each row including a data column for a tenant identifier, a first data field with a first data type being defined for a tenant, and a second data field with a second data type being defined for the tenant, and the index table being defined with a tenant identifier for the tenant, a copy of data from the first data field and the second data field, and a key to the corresponding rows of the multi-tenant data structure and [0097] for the query being analyzed to determine whether it is a candidate for a custom index, in one example, the query being a candidate if it runs slowly or if it times out, and additional criteria also being used such as whether the query uses a filter or whether the query is used frequently and applies to a large database. Based on run time and frequency of use, it is determined that the query is to be processed for indexing columns.);
providing a set of columns [first data field and second data field] for the first query (see e.g., [0050] for the multi-tenant data structure being defined having data fields in columns and rows for each of multiple tenants, each row including a data column for a tenant identifier, a first data field with a first data type being defined for a tenant, and a second data field with a second data type being defined for the tenant, and the index table being defined with a tenant identifier for the tenant, a copy of data from the first data field and the second data field, and a key to the corresponding rows of the multi-tenant data structure and [0097] for the query being analyzed to determine whether it is a candidate for a custom index. A custom index for the query is provided with a first data field and a second data field.); and
for each column in the set of columns, selectively updating a table index [index table] of the tenant within the database system to include an index on the column at least partially in response to a data type of the column (see e.g., [0050] for the multi-tenant data structure being defined having data fields in columns and rows for each of multiple tenants, each row including a data column for a tenant identifier, a first data field with a first data type being defined for a tenant, and a second data field with a second data type being defined for the tenant, and the index table being defined with a tenant identifier for the tenant, a copy of data from the first data field and the second data field, and a key to the corresponding rows of the multi-tenant data structure, [0057] for custom indexes being provided after they are generated to an Index Table 113 ,[0101] for the data types affected by the query being analyzed and this including the columns used by the captured query, where the columns indicate the data field or the nature of the data, and [0103] for a custom index being generated based on determined data types. The index table is updated to include an index on the first data field and the second data field at least partially in response to a data type of the first data field and the second data field.).
Rajan does not specifically disclose for each column in the set of columns, selectively updating a table index within the database system to include an index on the column at least partially in response to a function on the column within the query. However, Prasad teaches
for each column in the set of columns, selectively updating a table index [MIS] within the database system to include an index on the column at least partially in response to a function [MIN/MAX] on the column within the query (see e.g., [0044] for Metadata Index Subtable (MIS) and the MIS being a separate subtable maintained for a column-partitioned base table, wherein the MIS is used to store the metadata for each column partition, [0074] for identifying Columns for Creation of the MIS, [0077] for based upon query type, and [0078] for a MIN/MAX aggregate query 200 without any GROUP BY clauses, the underlying columns resulting in the creation of the MIS 500. The MIS within the database system is selectively updated to include each column at least partially in response to a MIN/MAX function on each column within the query.).
It would have been obvious to one of ordinary skill in the art prior to the effective filing date of the claimed invention to modify the index table of Rajan to for each column in the set of columns, selectively update a table index within the database system to include an index on the column at least partially in response to a function on the column within the query, as taught by Prasad, for the benefit of performing the query using only the index without accessing the base table (see e.g., Prasad, [0078]).
As to claim 16, the limitations of parent claim 15 have been discussed above. Rajan teaches
wherein selectively updating the table index of the tenant within the database system to include an index on the column is further in response to determining that the column is indexable using a list of columns [query table] (see e.g., [0057] for custom indexes being provided after they are generated to an Index Table 113, [0091] for Selectivity Tester 205 being used to compile a table 207 of custom index candidates, this table including an identifier for each query, the filters that the query uses and other information about the query, for example, the filter analyzer 203 determining the operators and data types for the query, these being included in the table, and in addition, bibliographic information about each query being included, such as the developer, the owner, the organization that uses it, etc., [0093] for the Custom Index Generator 111 of the system using the data in the table to make autonomous automatic decisions about generating a custom index. The query table includes custom index candidates, which includes columns. The Custom Index Generator determines indexable columns from the query table. These columns are added to the index table.).
As to claim 17, the limitations of parent claim 15 have been discussed above. Rajan teaches wherein determining, responsive to the first metrics, that the first query is to be processed for indexing of one or more columns comprises:
determining that the query has been executed at least a threshold number of times [frequency] in a time window [production] (see e.g., [0087] for the queries being directed to a multi-tenant database, [0088] for queries submitted in production, that is queries submitted by users being monitored and if a particular query runs slowly, or has slow performance then it being flagged for later analysis, [0096] for the queries being captured before, during, or after execution, and [0097] for the query being analyzed to determine whether it is a candidate for a custom index, in one example, the query being a candidate if it runs slowly or if it times out, and additional criteria also being used such as whether the query uses a filter or whether the query is used frequently and applies to a large database. Metrics of a query executed upon a multi-tenant database are received, which include run time and frequency of use. Based on frequency of use, it is determined that the query is to be processed for indexing columns.); and
determining that time cost [run time] of the query exceeds a threshold time cost (see e.g., [0087] for the queries being directed to a multi-tenant database, [0088] for queries submitted in production, that is queries submitted by users being monitored and if a particular query runs slowly, or has slow performance then it being flagged for later analysis, [0096] for the queries being captured before, during, or after execution, and [0097] for the query being analyzed to determine whether it is a candidate for a custom index, in one example, the query being a candidate if it runs slowly or if it times out, and additional criteria also being used such as whether the query uses a filter or whether the query is used frequently and applies to a large database. Metrics of a query executed upon a multi-tenant database are received, which include run time and frequency of use. Based on run time, it is determined that the query is to be processed for indexing columns.).
As to claim 18, the limitations of parent claim 15 have been discussed above. Rajan teaches
wherein the table index is initialized within the database system to include indexes on columns [standard fields] common to all tenants of the database system (see e.g., [0057] for custom indexes being provided after they are generated to an Index Table 113, [0065] for a custom index being created on standard fields, and [0141] for standard entity tables being provided for use by all tenants and for CRM database applications, such standard entities including tables for Account, Contact, Lead, and Opportunity data, each containing pre-defined fields. The index table is initialized to include indexes on standard fields, which are common to all tenants.).
As to claim 19, the limitations of parent claim 15 have been discussed above. Rajan teaches
receiving usage metrics [frequency of use] for a column having an index on the column for the tenant (see e.g., [0051] for performance being further enhanced and data storage reduced, by monitoring 112 the new custom indexes and after the indexes are created 110 a list being created to monitor 112 the created additional filter for frequency of use 114 or some other criteria and [0052] for in one example, a black tab page being used to store information about created indexes, this allowing reports to be run and other analytics to be performed, the indexes being scrutinized to check whether created indexes are being used, and a black tab page allowing for a check for how many indexes were created, how many times they are used, what the buffer gets were before the index was created, what the buffer gets were after the index was created, and more metrics); and
selectively deleting the index on the column responsive to the usage metrics (see e.g., [0051] for the created additional filter then being removed 116 if it is not used more frequently than a predefined number of times in a predefined duration of time and [0052] for the indexes being scrutinized to check whether created indexes are being used and providing an alert if they are not and in that case, the index being dropped.).
As to claim 20, the limitations of parent claims 15 and 19 have been discussed above. Rajan teaches
wherein the index on the column is deleted in response to the usage metrics indicating that the index on the column has not been used at least a threshold number of times [predefined number of times] within a time window [predefined duration of time] (see e.g., [0051] for performance being further enhanced and data storage reduced, by monitoring 112 the new custom indexes, after the indexes are created 110 a list being created to monitor 112 the created additional filter for frequency of use 114 or some other criteria, and the created additional filter then being removed 116 if it is not used more frequently than a predefined number of times in a predefined duration of time).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Sun et al. (US Publication No. 2014/0317093) for “facilitating dynamic creation of multi-column index tables and management of customer queries in an on-demand services environment in a multi-tenant environment” (see abstract).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DARA J GLASSER whose telephone number is (571)270-3666. The examiner can normally be reached Monday-Thursday, 10:00am-2:00pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Apu Mofiz can be reached at (571)272-4080. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
7-15-2026
/DARA J GLASSER/Examiner, Art Unit 2161
/APU M MOFIZ/Supervisory Patent Examiner, Art Unit 2161
Prosecution Insights