Jump to content

Patent Application 18817669 - TABLE SCAN PREDICATE WITH INTEGRATED SEMI-JOIN - Rejection

From WikiPatents

Patent Application 18817669 - TABLE SCAN PREDICATE WITH INTEGRATED SEMI-JOIN

Title: TABLE SCAN PREDICATE WITH INTEGRATED SEMI-JOIN FILTER

Application Information

  • Invention Title: TABLE SCAN PREDICATE WITH INTEGRATED SEMI-JOIN FILTER
  • Application Number: 18817669
  • Submission Date: 2025-05-20T00:00:00.000Z
  • Effective Filing Date: 2024-08-28T00:00:00.000Z
  • Filing Date: 2024-08-28T00:00:00.000Z
  • Examiner Employee Number: 82564
  • Art Unit: 2166
  • Tech Center: 2100

Rejection Summary

  • 102 Rejections: 1
  • 103 Rejections: 2

Cited Patents

No patents were cited in this rejection.

Office Action Text


    Notice of Pre-AIA  or AIA  Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .

DETAILED ACTION

1.	The pending claims 21-40 are presented for examination.

Double Patenting
2.	Claims 21-40 are rejected on the ground of nonstatutory obviousness-type double patenting as being unpatentable over claims 1-20 of Mayr et al (US Patent 12099490 B2, hereinafter “Mayr”).  Although the conflicting claims are not identical, they are not patentably distinct from each other because the inventions are obvious variants.
3.	The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees.   A nonstatutory obviousness-type double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); and  In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on a nonstatutory double patenting ground provided the reference application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA  as explained in MPEP § 2159.  See MPEP §§ 706.02(l)(1) - 706.02(l)(3) for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b). 
Effective January 1, 1994, a registered attorney or agent of record may sign a terminal disclaimer. A terminal disclaimer signed by the assignee must fully comply with 37 CFR 3.73(b).
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/forms/. The filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to http://www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.

Claim Rejections - 35 USC § 101
4.	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.

5.	Claims 21-40 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The analysis below of the claims’ subject matter eligibility follows the guidance set forth in MPEP 2106 which has incorporated the 2019 PEG.
Regarding to claim 31,
Step 1 Analysis: Claim 31 is directed to a method, which is directed to a process, one of the statutory categories.
Step 2A Prong One Analysis:
Claim 31 recites: A method comprising:
 “receiving a query including at least a join operator, a first predicate, and a second predicate”. This element reads on a person performs a query including a join operator, a first predicate and a second predicate which could be considered a mental process of an observation or evaluation. 
“transforming the second predicate into a dynamic predicate for execution of the query”. This element reads on a person transforms the second predicate into a dynamic predicate which could be considered a mental process of an observation or evaluation. 
“applying the dynamic predicate to at least first data”. This element reads on a person applies the dynamic predicate to data which could be considered a mental process of an observation or evaluation. 
“executing the query by at least the applying of the dynamic predicate to at least the first data”. This element reads on a person executes the query which could be considered a mental process of an observation or evaluation. 
Overall, the limitations directed to query data and the various mental process limitations in the context of this claim encompasses limitations that are not only considered to be directed to limitations that could be practically performed in the human mind (including observations and preform an evaluation, judgment, and opinion) aided by the use of pen and paper. If the claim limitations, under their broadest reasonable interpretations, cover performance of the limitation in the mind but for the recitation of generic computer components, then they fall within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
Step 2A Prong Two Analysis: In Step 2A Prong 2, we are directed to Identify whether there are any additional elements recited in the claim beyond the judicial exception(s), and evaluate those additional elements to determine whether they integrate the exception into a practical application of the exception.
In particular, the claim only recites the additional elements of “by a database management system.”
Regarding the database management system,
The database management system for receiving, transforming, applying and executing in all steps is recited at a high level of generality, i.e., as a system performing a generic computer function of processing data (receiving, transforming, applying and executing).  This generic system limitation is no more than mere instructions to apply the exception using a generic computer component. Accordingly, this additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea.
 The additional element “a database management system” is simply applying the abstract idea, and there is nothing done with results.  Accordingly, this additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea, and does not provide any improvement in computer technology (see MPEP2106.05(a)).  
Therefore, the additional element does not integrate the judicial exception into a practical application.
Step 2B Analysis: In Step 2B, we are directed to Identify whether there are any additional elements recited in the claim beyond the judicial exception(s), and evaluate those additional elements to determine whether the additional elements, taken individually and in combination, result in the claim as a whole amounting to significantly more than the judicial exception.
As discussed above with respect to integration of the abstract idea into a practical application, The additional element “a database management system” is simply applying the abstract idea, and there is nothing done with results. 
Accordingly, this additional element, taken individually and in combination, do not result in the claim as a whole amounting to significantly more than the judicial exception. The claim is not patent eligible.

Regarding claim 32, 
Step 1 Analysis: Claim 32 is directed to a method, which is directed to a process, one of the statutory categories.
Step 2A Prong One Analysis:
Claim 32 is dependent on claim 31, which as indicated in the analysis above, is directed to an abstract idea without significantly more.
Claim 32 recites “wherein the second predicate includes an expression associated with a first table." That is, the claim recites the second predicate includes an expression associated with a first table. The above-noted limitation of claim 32, as drafted, is a process that, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
Step 2A Prong Two Analysis: This judicial exception is not integrated into a practical application.
Step 2B Analysis: The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception.

Regarding claim 33, 
Step 1 Analysis: Claim 33 is directed to a method, which is directed to a process, one of the statutory categories.
Step 2A Prong One Analysis:
Claim 33 is dependent on claims 31 & 32, which as indicated in the analysis above, is directed to an abstract idea without significantly more.
Claim 33 recites “the second predicate includes a reference to a column associated with second data from a second table, and wherein the join operator references the first data from the first table and the second data from the second table." That is, the claim recites the second predicate includes a reference to a column associated with second data from a second table, and wherein the join operator references the first data from the first table and the second data from the second table. The above-noted limitation of claim 33, as drafted, is a process that, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
Step 2A Prong Two Analysis: This judicial exception is not integrated into a practical application.
Step 2B Analysis: The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception.

Regarding claim 34, 
Step 1 Analysis: Claim 34 is directed to a method, which is directed to a process, one of the statutory categories.
Step 2A Prong One Analysis:
Claim 34 is dependent on claim 31, which as indicated in the analysis above, is directed to an abstract idea without significantly more.
Claim 34 recites “implementing a semi-join reduction technique using the dynamic predicate." That is, the claim recites implementing a semi-join reduction technique using the dynamic predicate. The above-noted limitation of claim 34, as drafted, is a process that, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
Step 2A Prong Two Analysis: This judicial exception is not integrated into a practical application.
Step 2B Analysis: The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception.

Regarding claim 35, 
Step 1 Analysis: Claim 35 is directed to a method, which is directed to a process, one of the statutory categories.
Step 2A Prong One Analysis:
Claim 35 is dependent on claims 31 & 34, which as indicated in the analysis above, is directed to an abstract idea without significantly more.
Claim 35 recites “the semi-join reduction technique comprises a transformation to include a semi-join and a shared sub plan." That is, the claim recites the semi-join reduction technique comprises a transformation to include a semi-join and a shared sub plan. The above-noted limitation of claim 35, as drafted, is a process that, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
Step 2A Prong Two Analysis: This judicial exception is not integrated into a practical application.
Step 2B Analysis: The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception.

Regarding claim 36, 
Step 1 Analysis: Claim 36 is directed to a method, which is directed to a process, one of the statutory categories.
Step 2A Prong One Analysis:
Claim 36 is dependent on claims 31 and 35, which as indicated in the analysis above, is directed to an abstract idea without significantly more.
Claim 36 recites “the shared sub plan includes a build side and a probe side of a query plan." That is, the claim recites the shared sub plan includes a build side and a probe side of a query plan. The above-noted limitation of claim 36, as drafted, is a process that, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
Step 2A Prong Two Analysis: This judicial exception is not integrated into a practical application.
Step 2B Analysis: The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception.

Regarding claim 37, 
Step 1 Analysis: Claim 37 is directed to a method, which is directed to a process, one of the statutory categories.
Step 2A Prong One Analysis:
Claim 37 is dependent on claims 31 & 34-36, which as indicated in the analysis above, is directed to an abstract idea without significantly more.
Claim 37 recites “the build side includes one or more auxiliary structures to facilitate matching of rows between a first table and a second table on the probe side." That is, the claim recites the build side includes one or more auxiliary structures to facilitate matching of rows between a first table and a second table on the probe side. The above-noted limitation of claim 37, as drafted, is a process that, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
Step 2A Prong Two Analysis: This judicial exception is not integrated into a practical application.
Step 2B Analysis: The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception.
Accordingly, this additional element, taken individually and in combination, does not result in the claim as a whole amounting to significantly more than the judicial exception. The claim is not patent eligible.

Regarding claim 38, 
Step 1 Analysis: Claim 38 is directed to a method, which is directed to a process, one of the statutory categories.
Step 2A Prong One Analysis:
Claim 38 is dependent on claim 31, which as indicated in the analysis above, is directed to an abstract idea without significantly more.
Claim 38 recites “injecting the dynamic predicate into a table scan using a conjunction." That is, the claim recites injecting the dynamic predicate into a table scan using a conjunction. The above-noted limitation of claim 38, as drafted, is a process that, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
Step 2A Prong Two Analysis: This judicial exception is not integrated into a practical application.
Step 2B Analysis: The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception.

Regarding claim 39, 
Step 1 Analysis: Claim 39 is directed to a method, which is directed to a process, one of the statutory categories.
Step 2A Prong One Analysis:
Claim 39 is dependent on claim 31, which as indicated in the analysis above, is directed to an abstract idea without significantly more.
Claim 39 recites “the join operator references the first data from a first table and second data from a second table, wherein the first predicate is used during a table scan of the second table." That is, the claim recites the join operator references the first data from a first table and second data from a second table, wherein the first predicate is used during a table scan of the second table. The above-noted limitation of claim 39, as drafted, is a process that, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
Step 2A Prong Two Analysis: This judicial exception is not integrated into a practical application.
Step 2B Analysis: The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception.

Claims 21-30 are rejected under 35 U.S.C. 101 with the same rational of claims 31-39.
Claim 40 is rejected under 35 U.S.C. 101 with the same rational of claim 31.

Claim Rejections - 35 USC § 102
6.	The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.

7.	Claims 21-24, 29-34 and 39-40 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Ahmed et al (U.S. Patent 10726010 B2 hereinafter, “Ahmed”).
8.	With respect to claim 21,
	Ahmed discloses a system, comprising:
	at least one data processor; and 
	at least one memory including instructions which when executed by the at least one processor cause operations comprising:
	receiving a query including at least a join operator, a first predicate, and a second predicate (Ahmed col. 4 line 61 – col. 5 line 43, col. 12 lines 12-22, col. 12 lines 12-22 e.g. [col. 4 line 61 – col. 5 line 43, col. 12 lines 12-22] (7) For example, the particular predicate condition may specify a SQL EXISTS or NOT EXISTS operator and a sub-query of the EXISTS or NOT EXISTS operator. The subquery references data object(s) such as column(s) of table(s), view(s), or snapshot(s), and the referenced data object(s) may include object(s)that occur or are initially referenced outside of the subquery. In other words, the initial representation represents an initial query that may contain a correlated EXISTS-equivalent predicate. (8) The query processor generates a transformed representation of a given query. The transformed query includes, instead of the particular predicate condition, a join operator that references the data object(s) that were previously referenced in the sub-query. For example, the join operator may be a semi-join or an anti-join that references the data object(s) that were previously referenced in the sub-query. The semi-join operator as represented in the transformed representation may be referred to as a generalized disjunctive semi-join (“GDSJ”) because the transformed representation, when executed, causes the predicate condition(s) to be applied separately from the semi-join operation. (60) A query optimizer may choose from among different available join methods to carry out a join operation. As described herein, some join methods are not available to some query formulations. (61) In a nested loops join method, a join operation is evaluated on a row-by row basis. In other words, during a join of T1 and T2, for each row of T1, the execution engine would scan T2 to determine whether T2 satisfies a join condition for that row. [col. 12 lines 12-22] Join Methods (60) A query optimizer may choose from among different available join methods to carry out a join operation. As described herein, some join methods are not available to some query formulations. (61) In a nested loops join method, a join operation is evaluated on a row-by row basis. In other words, during a join of T1 and T2, for each row of T1, the execution engine would scan T2 to determine whether T2 satisfies a join condition for that row);
	transforming the second predicate into a dynamic predicate for execution of the query (Ahmed col. 5 lines 13-29 e.g. semi/anti join - referring to the instant applicant’s specification [0010] “[0010] In some variations, the dynamic predicate is implemented as a semi-join reduction to reduce a number of rows in at least the second table for use in the scanning of the second table.”;(8) The query processor generates a transformed representation of a given query. The transformed query includes, instead of the particular predicate condition, a join operator that references the data object(s) that were previously referenced in the sub-query. For example, the join operator may be a semi-join or an anti-join that references the data object(s) that were previously referenced in the sub-query. The semi-join operator as represented in the transformed representation may be referred to as a generalized disjunctive semi-join (“GDSJ”) because the transformed representation, when executed, causes the predicate condition(s) to be applied separately from the semi-join operation); 
	applying the dynamic predicate to at least first data (Ahmed col. 6 lines 46-65 e.g. (15) In one embodiment, a query execution engine receives a query representation that marks a table with predicate(s) using a flag or some other stored indication. For example, the marking may indicate that the predicate(s) are marked disjunctive predicates should be used to filter rows from a base table before performing a join operation on the base table. The query representation joins the table using a join operation such as a semi-join or anti-join. The query execution engine executes the query representation by applying, based on the flag or other stored indication, the predicate(s) separately from the join operation that joins the table. For example, the query execution engine may call a function that determines whether or not the table has been marked with disjunctive predicate(s). If the disjunctive predicate(s) evaluate to TRUE for certain row(s) of base table(s) of the join operation, then those rows may be excluded from the join operation because the predicate(s) are marked disjunctive predicate(s) that have already been satisfied. In response to executing the query representation, the query execution engine may return result(s) to a client.); and
	executing the query by at least the applying of the dynamic predicate to at least the first data (Ahmed col. 4 line 61 – col. 5 line 43, col. 12 lines 12-22).
9.	With respect to claim 22,
	Ahmed discloses wherein the second predicate includes an expression associated with a first table (Ahmed col. 4 line 61 – col. 5 line 43, col. 12 lines 12-22 e.g. (7) For example, the particular predicate condition may specify a SQL EXISTS or NOT EXISTS operator and a sub-query of the EXISTS or NOT EXISTS operator. The subquery references data object(s) such as column(s) of table(s), view(s), or snapshot(s), and the referenced data object(s) may include object(s)that occur or are initially referenced outside of the subquery. In other words, the initial representation represents an initial query that may contain a correlated EXISTS-equivalent predicate. (8) The query processor generates a transformed representation of a given query. The transformed query includes, instead of the particular predicate condition, a join operator that references the data object(s) that were previously referenced in the sub-query. (60) A query optimizer may choose from among different available join methods to carry out a join operation. As described herein, some join methods are not available to some query formulations. (61) In a nested loops join method, a join operation is evaluated on a row-by row basis. In other words, during a join of T1 and T2, for each row of T1, the execution engine would scan T2 to determine whether T2 satisfies a join condition for that row.).
10.	With respect to claim 23,
	Ahmed discloses wherein the second predicate includes a reference to a column associated with second data from a second table, and wherein the join operator references the first data from the first table and the second data from the second table (Ahmed col. 4 line 61 – col. 5 line 43, col. 12 lines 12-22 e.g. (7) For example, the particular predicate condition may specify a SQL EXISTS or NOT EXISTS operator and a sub-query of the EXISTS or NOT EXISTS operator. The subquery references data object(s) such as column(s) of table(s), view(s), or snapshot(s), and the referenced data object(s) may include object(s)that occur or are initially referenced outside of the subquery. In other words, the initial representation represents an initial query that may contain a correlated EXISTS-equivalent predicate. (8) The query processor generates a transformed representation of a given query. The transformed query includes, instead of the particular predicate condition, a join operator that references the data object(s) that were previously referenced in the sub-query. (60) A query optimizer may choose from among different available join methods to carry out a join operation. As described herein, some join methods are not available to some query formulations. (61) In a nested loops join method, a join operation is evaluated on a row-by row basis. In other words, during a join of T1 and T2, for each row of T1, the execution engine would scan T2 to determine whether T2 satisfies a join condition for that row.).
11.	With respect to claim 24,
	Ahmed discloses wherein the operations further comprise implementing a semi-join reduction technique using the dynamic predicate (Ahmed col. 5 lines 13-29 e.g. semi/anti join - referring to the instant applicant’s specification [0010] “[0010] In some variations, the dynamic predicate is implemented as a semi-join reduction to reduce a number of rows in at least the second table for use in the scanning of the second table.”;(8) The query processor generates a transformed representation of a given query. The transformed query includes, instead of the particular predicate condition, a join operator that references the data object(s) that were previously referenced in the sub-query. For example, the join operator may be a semi-join or an anti-join that references the data object(s) that were previously referenced in the sub-query. The semi-join operator as represented in the transformed representation may be referred to as a generalized disjunctive semi-join (“GDSJ”) because the transformed representation, when executed, causes the predicate condition(s) to be applied separately from the semi-join operation).
12.	With respect to claim 29,
Ahmed discloses wherein the join operator references the first data from a first table and second data from a second table, and wherein the first predicate is used during a table scan of the second table (Ahmed col. 4 line 61 – col. 5 line 43, col. 12 lines 12-22 e.g. (8) The query processor generates a transformed representation of a given query. The transformed query includes, instead of the particular predicate condition, a join operator that references the data object(s) that were previously referenced in the sub-query. For example, the join operator may be a semi-join or an anti-join that references the data object(s) that were previously referenced in the sub-query. The semi-join operator as represented in the transformed representation may be referred to as a generalized disjunctive semi-join (“GDSJ”) because the transformed representation, when executed, causes the predicate condition(s) to be applied separately from the semi-join operation. (60) A query optimizer may choose from among different available join methods to carry out a join operation. As described herein, some join methods are not available to some query formulations. (61) In a nested loops join method, a join operation is evaluated on a row-by row basis. In other words, during a join of T1 and T2, for each row of T1, the execution engine would scan T2 to determine whether T2 satisfies a join condition for that row.).
13.	With respect to claim 30,
	Ahmed discloses herein the first predicate is used to determine which rows in a first table and a second table are relevant to execution of the query (Ahmed col. 4 line 61 – col. 5 line 43, col. 12 lines 12-22, col. 12 lines 12-22 e.g. [col. 4 line 61 – col. 5 line 43, col. 12 lines 12-22] (7) For example, the particular predicate condition may specify a SQL EXISTS or NOT EXISTS operator and a sub-query of the EXISTS or NOT EXISTS operator. The subquery references data object(s) such as column(s) of table(s), view(s), or snapshot(s), and the referenced data object(s) may include object(s)that occur or are initially referenced outside of the subquery. In other words, the initial representation represents an initial query that may contain a correlated EXISTS-equivalent predicate. (8) The query processor generates a transformed representation of a given query. The transformed query includes, instead of the particular predicate condition, a join operator that references the data object(s) that were previously referenced in the sub-query. For example, the join operator may be a semi-join or an anti-join that references the data object(s) that were previously referenced in the sub-query. The semi-join operator as represented in the transformed representation may be referred to as a generalized disjunctive semi-join (“GDSJ”) because the transformed representation, when executed, causes the predicate condition(s) to be applied separately from the semi-join operation. (60) A query optimizer may choose from among different available join methods to carry out a join operation. As described herein, some join methods are not available to some query formulations. (61) In a nested loops join method, a join operation is evaluated on a row-by row basis. In other words, during a join of T1 and T2, for each row of T1, the execution engine would scan T2 to determine whether T2 satisfies a join condition for that row. [col. 12 lines 12-22] Join Methods (60) A query optimizer may choose from among different available join methods to carry out a join operation. As described herein, some join methods are not available to some query formulations. (61) In a nested loops join method, a join operation is evaluated on a row-by row basis. In other words, during a join of T1 and T2, for each row of T1, the execution engine would scan T2 to determine whether T2 satisfies a join condition for that row).
14.	Claims 31-34 and 39 are same as claims 21-24 and 29 and are rejected for the same reasons as applied hereinabove.
15.	Claim 40 is same as claim 21 and is rejected for the same reasons as applied hereinabove.

Claim Rejections - 35 USC § 103
16.	In the event the determination of the status of the application as subject to AIA  35 U.S.C. 102 and 103 (or as subject to pre-AIA  35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.  
17.	This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary.  Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
18.	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.

19.	The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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.
20.	Claims 25, 28, 35 and 38 are rejected under 35 U.S.C. 103 as being unpatentable over Ahmed in view of PASUPULETI et al (U.S. 20230117461 A1 hereinafter, “PASUPULETI”).
21.	With respect to claim 25,
Although Ahmed substantially teaches the claimed invention, Ahmed does not explicitly indicate wherein the semi-join reduction technique comprises a transformation to include a semi-join and a shared sub plan.
PASUPULETI teaches the limitations by stating wherein the semi-join reduction technique comprises a transformation to include a semi-join and a shared sub plan (PASUPULETI [0036], [0043] e.g. [0036] A “transformation” is a specific technique or set of techniques used by the database optimizer to rewrite the query/query portion to asemantically equivalent query or query portion to improve query performance (e.g., where semantically equivalence in the database context corresponds to the production of the same query result set). There are multiple types of transformations that may be used in a database system. The following is a non-exclusive list of example transformations: (c) “Predicate Pushing”, where the optimizer “pushes” the relevant predicates from the containing query block into the view query block, e.g., where for views that are not merged, this technique improves the subplan of the unmerged view because the database can use the pushed-in predicates to access indexes or to use as filters; (d) (g) “In-Memory Aggregation”, where aggregation is performed while scanning to optimize query blocks, e.g., involving aggregation and joins from a single large table to multiple small tables, such as in a typical star query, where the transformation uses KEY VECTOR and VECTOR GROUP BY operations, since these operations use efficient in-memory arrays for joins and aggregation and are especially effective when the underlying tables are in-memory columnar tables; [0043] When query 302 is compiled, a cost-based query optimizer may apply a number of logical transformations in an attempt to arrive at an equivalent but more efficient query form. Such transformations are applied in a specific order. For example, in query 302, view ‘v’ can be merged into its outer query block while the subquery specified in ‘v’ can be unnested converting it into a semi-join).
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the invention, in view of the teachings of Ahmed and PASUPULETI, to efficiently addresses errors that may be encountered during compilation of database statements (PASUPULETI [0005]). 
22.	With respect to claim 28,
	PASUPULETI discloses wherein the operations further comprise injecting the dynamic predicate into a table scan using a conjunction (PASUPULETI [0036], [0043] e.g. [0036] A “transformation” is a specific technique or set of techniques used by the database optimizer to rewrite the query/query portion to asemantically equivalent query or query portion to improve query performance (e.g., where semantically equivalence in the database context corresponds to the production of the same query result set). There are multiple types of transformations that may be used in a database system. The following is a non-exclusive list of example transformations: (c) “Predicate Pushing”, where the optimizer “pushes” the relevant predicates from the containing query block into the view query block, e.g., where for views that are not merged, this technique improves the subplan of the unmerged view because the database can use the pushed-in predicates to access indexes or to use as filters; (d) (g) “In-Memory Aggregation”, where aggregation is performed while scanning to optimize query blocks, e.g., involving aggregation and joins from a single large table to multiple small tables, such as in a typical star query, where the transformation uses KEY VECTOR and VECTOR GROUP BY operations, since these operations use efficient in-memory arrays for joins and aggregation and are especially effective when the underlying tables are in-memory columnar tables; [0043] When query 302 is compiled, a cost-based query optimizer may apply a number of logical transformations in an attempt to arrive at an equivalent but more efficient query form. Such transformations are applied in a specific order. For example, in query 302, view ‘v’ can be merged into its outer query block while the subquery specified in ‘v’ can be unnested converting it into a semi-join.).
23.	Claim 35 and 38 are same as claims 25 and 28 and are rejected for the same reasons as applied hereinabove.

24.	Claims 26-27 and 36-37 are rejected under 35 U.S.C. 103 as being unpatentable over Ahmed in view of PASUPULETI, and further in view of HEIMEL et al (U.S. 20210397619 A1 hereinafter, “HEIMEL”).
25.	With respect to claim 26,
Although Ahmed and PASUPULETI combination substantially teaches the claimed invention, they do not explicitly indicate wherein the shared sub plan includes a build side and a probe side of a query plan.
HEIMEL teaches the limitations by stating wherein the shared sub plan includes a build side and a probe side of a query plan (HEIMEL [0023] – [0026], [0041], [0090], [0171] – [0173], [0177], [0184], [0194], [0204] e.g. [0024] Join pruning is a conventional pruning technique used for processing join queries. With join pruning, a data structure (e.g., a range bloom filter) representing a synopsis of values from the build side table is sent to a probe-side scan operator, and micro-partitions are pruned using per-partition metadata that includes the minimum and maximum value per column and micro-partition before the micro-partitions are scanned. [0026] In the specific example of a join query to combine rows from two tables, the system can collect the set of values for the query predicate during a join build phase in which a hash table is created in which rows from a first table (also referred to as the “build side table”) are stored using the join attribute(s) as the hash key. The collected values are used in conjunction with a pruning index associated with a second table (also referred to as the “probe side table”) to identify the reduced scan set micro-partitions. The system performs the join probe phase using the reduced scan set of micro-partitions. [0090] The processing of the query can include executing a query plan compiled by the compute service manager 108. In some embodiments (e.g., where values for query predicates are known prior to query runtime), the query plan may indicate the reduced scan set to scan. In some embodiments, values for one or more query predicates are unknown prior to query runtime, and only upon determining these values at runtime can the pruning index be used to prune the scan set. Consistent with these embodiments, the pruning of the scan set (operation 830) can also be performed at runtime as part of executing the query plan compiled by the compute service manager 108. Further details regarding processing of queries where values for one or more query predicates are unknown prior to runtime are discussed below. [0171] At runtime, the execution platform 110 performs a join build phase (operation 1310) in response to receiving the join query. During the join build phase, the execution platform 110 builds a hash table where rows from the build side table (e.g., the smaller of the two tables) are stored using the join attribute(s) as a hash key. In building the hash table, the execution platform 110 collects a set of build side values (e.g., the values to be matched against the probe side table) for the join predicate. [0177] As shown, if the pruning index for the probe side table does not exist or if the execution platform 110 decides not to use the pruning index based on the cost function (e.g., if the number of values in the set of build side values does not satisfy the constraint, and/or if the number of micro-partitions in the probe side table does not satisfy the constraint), the method 1300 moves to operation 1340 where the execution platform 110 uses an alternative pruning methodology such as join pruning.).
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the invention, in view of the teachings of Ahmed, PASUPULETI and HEIMEL, to efficiently addresses errors that may be encountered during compilation of database statements (PASUPULETI [0005]). 
26.	With respect to claim 27,
	PASUPULETI discloses wherein the build side includes one or more auxiliary structures to facilitate matching of rows between a first table and a second table on the probe side (PASUPULETI [0043] e.g. [0043] When query 302 is compiled, a cost-based query optimizer may apply a number of logical transformations in an attempt to arrive at an equivalent but more efficient query form. Such transformations are applied in a specific order. For example, in query 302, view ‘v’ can be merged into its outer query block while the subquery specified in ‘v’ can be unnested converting it into a semi-join.).
27.	Claims 36-37 are same as claims 26-27 and are rejected for the same reasons as applied hereinabove.

Conclusion
The prior art made of record, listed on form PTO-892, and not relied upon, if any, is considered pertinent to applicant's disclosure.
28.	The examiner requests, in response to this office action, support be shown for language added to any original claims on amendment and any new claims. That is, indicate support for newly added claim language by specifically pointing to page(s) and line no(s) in the specification and/or drawing figure(s). This will assist the examiner in prosecuting the application.
29.	When responding to this office action, Applicant is advised to clearly point out the patentable novelty which he or she thinks the claims present, in view of the state of the art disclosed by the reference cited or the objections made. He or she must also show how the amendments avoid such references or objections See 37 CFR 1.111(c).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SyLing Yen whose telephone number is 571-270-1306.  The examiner can normally be reached on .
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Sanjiv Shah can be reached at 571-272-4098.  The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system.  Status information for published applications may be obtained from either Private PAIR or Public PAIR.  Status information for unpublished applications is available through Private PAIR only.  For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.



/SYLING YEN/Primary Examiner, Art Unit 2166                                                                                                                                                                                                        
May 16, 2025


Retrieved from "https://wikipatents.org/index.php?title=Patent_Application_18817669_-_TABLE_SCAN_PREDICATE_WITH_INTEGRATED_SEMI-JOIN_-_Rejection&oldid=623954"
Cookies help us deliver our services. By using our services, you agree to our use of cookies.