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 .
Claims 4, 14 and 24 are canceled.
Claims 1-3, 5-13, 15-23 and 25-30 are presented for examination.
The claims and only the claims form the metes and bounds of the invention. “Office personnel are to give claims their broadest reasonable interpretation in light of the supporting disclosure. In re Morris, 127 F.3d 1048, 1054-55, 44 USPQ2d 1023, 1027-28 (Fed. Cir. 1997). Limitations appearing in the specification but not recited in the claim are not read into the claim. In re Prater, 415 F.2d 1393, 1404-05, 162 USPQ 541, 550-551 (CCPA 1969)” (MPEP p 2100-8, c 2, I 45-48; p 2100-9, c 1, l 1-4). The Examiner has full latitude to interpret each claim in the broadest reasonable sense. The Examiner will reference prior art using terminology familiar to one of ordinary skill in the art. Such an approach is broad in concept and can be either explicit or implicit in meaning.
Response to Arguments
Applicant’s remarks/amendment was filed on 28 October 2025.
Applicant’s arguments have been considered but they are not persuasive. However, the Examiner welcomes any suggestion(s) Applicants may have on moving prosecution forward. The Examiner’s contact information is in the Conclusion of this office action.
Applicant argues:
The cited portions of the applied references are not understood to teach or suggest all of the features of independent claim 1, particularly with respect to at least the features of "rewriting the pivot query to produce a rewritten pivot query, the rewriting utilizing object aggregation to aggregate data for the pivot column by creating an aggregation object with the pivot column as a key and aggregation result column as a value."
…
Amended claim 1 requires creating an aggregation object with a defined key-value structure where "the pivot column as a key and aggregation result column as a value, which is wholly absent from Bellamkonda's disclosure. While Bellamkonda describes various aggregation operations, these are performed within the context of staging table manipulations. For example, Bellamkonda's paragraph [0040] explains that "results of this aggregation operation are stored in a staging table of the second type 302," and paragraph [0043] describes that "the result set 124 can then be obtained
by a transpose operation performed on the staging table of the second type 302." Bellamkonda's approach requires multiple data transformation steps involving staging table storage and subsequent transpose operations, which is entirely different from the direct object aggregation with key-value structure specified in the manner recited in amended claim 1.
In response, the Examiner submits:
Amended Claim 1 recites “… creating an aggregation object with the pivot column as a key and aggregation result column as a value”. However, the claim does not recite “an aggregation object with a defined key-value structure”.
Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
Contrary to Applicant’s assertion above, Bellamkonda does disclose rewriting the pivot query to produce a rewritten pivot query (Bellamkonda: at least ¶¶0034 & 0045; “in response to receiving a pivoting query as described above, the database system internally converts the pivoting query to an equivalent query whose query plan, when executed, performs the steps in connection with a staging table 202 as described above”), the rewriting utilizing object aggregation to aggregate data for the pivot column (Bellamkonda: at least ¶0034; “the database system only evaluates one aggregate for each of the pivot values "Q1", "Q2", "Q3", and "Q4"”; ¶0017 also discloses ““the pivot column ("QTR")”) by creating an aggregation object with the pivot column as a key and aggregation result column as a value (Bellamkonda: at least ¶0017; “the pivot column ("QTR"); ¶¶0025-0026 & 0034 further disclose query “S3” with “QTR” and “Q1”, “Q2”, “Q3”, “Q4” where “Q1”, “Q2”, “Q3”, “Q4” are “pivot value columns” with “aggregated values derived from aggregating stored values”).
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-3, 5-13, 15-23 and 25-30 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 1, 11 and 21 recite “… determining the distinct pivot value for the pivot column at runtime by issuing the subquery and executing the issued subquery”.
While Claims 1, 11 and 21 recite “… specifying a distinct pivot value”, they do not recite “a distinct pivot value for the pivot column”.
Dependent claims 2-3 and 5-10 depend from Claim 1, and are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph for the same reason(s).
Dependent claims 12-13 and 15-20 depend from Claim 11, and are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph for the same reason(s).
Dependent claims 22-23 and 25-30 depend from Claim 21, and are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph for the same reason(s).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
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.
Claims 1-3, 5-7, 11-13, 15-17, 21-23 and 25-27 rejected under 35 U.S.C. 103 as being unpatentable over US Patent 6,298,342 by Graefe in view of US PGPUB 2014/0019842 by Montagna et al. (“Montagna”), and further in view of US PGPUB 2010/0017363 by Bellamkonda et al. (“Bellamkonda”).
As to Claim 1, Graefe teaches a method comprising: receiving a pivot query (Graefe: at least Col. 9 Lines 5-7; “Block 510 receives a query from a user at a client terminal 120, FIG. 1, or from some other source as described herein`”; Col. 13 Lines 2-3 further discloses “query 420”) specifying a pivot column (Graefe: at least Col. 8 Lines 24-26; “Pivot column 411, named Quarter in the input table 410 named Narrow, becomes four columns 431, 432, 433, and 434 in the output table 430”; Col. 9 Lines 7-10 further discloses “Step 520 identifies or selects which table 261 in database 260 is to serve as the input table of the operation. Step 521 identifies which column of the input table is to be the pivot column”) for dynamically determining a pivot value in a dynamic pivot operation, the dynamic pivot operation comprising specifying a distinct pivot value dynamically (Graefe: at least Col. 3 Lines 7-10; “"pivot" operation for transforming the rows (records) and columns (fields) of a table, as that term is defined in a relational database, so as to provide different perspectives into the data items in the table”; Col. 9 Lines 9-11 further discloses “Step 521 identifies which column of the input table is to be the pivot column, step 522 identifies from the pivot list which pivot-column values participate in the pivot” and Col. 12 Lines 34-36 further discloses “the pivot operation (but not unpivot) can support conventional SQL aggregation or grouping functions such as MIN, SUM, AVG, and even COUNT, for the value column at step 540”; note: “for” merely indicates purpose);
identifying, in the pivot query, a subquery indicating dynamic determination of the pivot value (Graefe: at least Col. 8 Lines 24-29; “pivot column 411, named Quarter in the input table 410 named Narrow, becomes four columns 431, 432, 433, and 434 in the output table 430. The names of these columns are the four distinct values, Spring, Summer, Fall, Winter, that appear as values in column 411, and that also appear in the value list following the keyword IN in 420”; note: IN (values) as subquery);
determining the distinct pivot value for the pivot column by issuing the subquery and executing the issued subquery (Graefe: at least Col. 8 Lines 24-29; “pivot column 411, named Quarter in the input table 410 named Narrow, becomes four columns 431, 432, 433, and 434 in the output table 430. The names of these columns are the four distinct values, Spring, Summer, Fall, Winter, that appear as values in column 411, and that also appear in the value list following the keyword IN in 420”; Col. 13 Lines 4-5 further disclose “… substitute a default query SELECT DISTINCT Quarter FROM Narrow”); and
performing, by at least one hardware processor, the dynamic pivot operation using the distinct pivot value for the pivot column (Graefe: at least Col. 8 Lines 26-28; “names of these columns are the four distinct values, Spring, Summer, Fall, Winter, that appear as values in column 411”; Col. 9 Lines 9-11 further discloses “Step 521 identifies which column of the input table is to be the pivot column, step 522 identifies from the pivot list which pivot-column values participate in the pivot”; Col. 12 Lines 34-36 further discloses “the pivot operation (but not unpivot) can support conventional SQL aggregation or grouping functions such as MIN, SUM, AVG, and even COUNT, for the value column at step 540”).
Graefe does not explicitly disclose, but Montagna discloses specifying a distinct pivot value dynamically at runtime (Montagna: at least ¶0018; “modification of a pivot table on the fly”; ¶¶0034, 0042 also disclose “in response to the movement of a field cell 220 to the column field region 208 or row field region 212, the pivot table 216 is updated at step 310” and “pivot table 216 is updated in response to the rearrangement of the one or more field cells 220. The pivot table 316 may be updated and displayed upon detection of the rearrangement of a field cell 220 or the swapping of two field cells 220”; ¶0052 further discloses “changes to the properties of metric field cell 220c may result in immediate updating of pivot table 216 (upon the change) or the pivot table may be updated after a user confirms the change (e.g., by pressing an "APPLY" button)”) and determining the distinct pivot value for the pivot column at runtime (Montagna: at least ¶0018; “modification of a pivot table on the fly”; ¶¶0034, 0042 also disclose “in response to the movement of a field cell 220 to the column field region 208 or row field region 212, the pivot table 216 is updated at step 310” and “pivot table 216 is updated in response to the rearrangement of the one or more field cells 220. The pivot table 316 may be updated and displayed upon detection of the rearrangement of a field cell 220 or the swapping of two field cells 220”; ¶0052 further discloses “changes to the properties of metric field cell 220c may result in immediate updating of pivot table 216 (upon the change) or the pivot table may be updated after a user confirms the change (e.g., by pressing an "APPLY" button)”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Montagna’s features of specifying a distinct pivot value dynamically at runtime (Montagna: at least ¶¶0018, 0034, 0042, 0052) and determining the distinct pivot value for the pivot column at runtime (Montagna: at least ¶¶0018, 0034, 0042, 0052) with Graefe’s method.
The suggestion/motivation for doing so would have been to “facilitate analysis of data from a data set, various data values from the data set may be compiled and presented in a table format, such as a pivot table” (Montagna: at least ¶0002) and “facilitate dynamic pivot table creation and modification” (Montagna: at least ¶0017).
Graefe and Montagna do not explicitly disclose, but Bellamkonda discloses rewriting the pivot query to produce a rewritten pivot query (Bellamkonda: at least ¶¶0034 & 0045; “in response to receiving a pivoting query as described above, the database system internally converts the pivoting query to an equivalent query whose query plan, when executed, performs the steps in connection with a staging table 202 as described above”), the rewriting utilizing object aggregation to aggregate data for the pivot column (Bellamkonda: at least ¶0034; “the database system only evaluates one aggregate for each of the pivot values "Q1", "Q2", "Q3", and "Q4"”; ¶0017 also discloses ““the pivot column ("QTR")”) by creating an aggregation object with the pivot column as a key and aggregation result column as a value (Bellamkonda: at least ¶0017; “the pivot column ("QTR"); ¶¶0025-0026 & 0034 further disclose query “S3” with “QTR” and “Q1”, “Q2”, “Q3”, “Q4” where “Q1”, “Q2”, “Q3”, “Q4” are “pivot value columns” with “aggregated values derived from aggregating stored values”); and performing, by at least one hardware processor, the dynamic pivot operation using the distinct pivot value for the pivot column by executing the rewritten pivot query utilizing the object aggregation (Bellamkonda: at least ¶0017; “the pivot column ("QTR"); ¶0034 further discloses “in response to receiving a pivoting query as described above, the database system internally converts the pivoting query to an equivalent query whose query plan, when executed, performs the steps in connection with a staging table 202 as described above” and “evaluates one aggregate for each of the pivot values”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Bellamkonda’s feature of rewriting the pivot query to produce a rewritten pivot query (Bellamkonda: at least ¶¶0034 & 0045), the rewriting utilizing object aggregation to aggregate data for the pivot column (Bellamkonda: at least ¶¶0017, 0034) by creating an aggregation object with the pivot column as a key and aggregation result column as a value (Bellamkonda: at least ¶¶0017, 0025-0026 & 0034); and performing, by at least one hardware processor, the dynamic pivot operation using the distinct pivot value for the pivot column by executing the rewritten pivot query utilizing the object aggregation (Bellamkonda: at least ¶¶0017, 0034) with the method disclosed by Graefe and Montagna.
The suggestion/motivation for doing so would have been to allow for “efficient evaluation of pivot operations” (Bellamkonda: at least ¶0013).
Claim 11 (a system claim) corresponds in scope to Claim 1, and is similarly rejected.
Claim 21 (a medium claim) corresponds in scope to Claim 1, and is similarly rejected.
As to Claim 2, Graefe, Montagna and Bellamkonda teach the method of claim 1, wherein performing of the dynamic pivot operation further comprises: sorting output pivot columns based on an order specified in the subquery (Graefe: at least Col. 8 Lines 26 & 57-59; “output table 430” and “table 430 is shown sorted by values of grouping columns Region and Year” where table 430 are output table; Col. 8 Lines 38-40 also discloses “an SQL clause of the form GROUP BY Region, Year. In this example, the effect of the pivot operation is to modify the perspective along which the data is viewed”).
Claim 12 (a system claim) corresponds in scope to Claim 2, and is similarly rejected.
Claim 22 (a medium claim) corresponds in scope to Claim 2, and is similarly rejected.
As to Claim 3, Graefe, Montagna and Bellamkonda teach the method of claim 1, wherein the subquery specifies an order for the pivot value (Graefe: at least Col. 8 Lines 27-28; “Pivot column 411” and “Spring, Summer, Fall, Winter, that appear as values in column 411”; Col. 8 Lines 57-59 further discloses “table 430 is shown sorted by values of grouping columns Region and Year” where table 430 are output table; Col. 8 Lines 38-40 also discloses “an SQL clause of the form GROUP BY Region, Year. In this example, the effect of the pivot operation is to modify the perspective along which the data is viewed”).
Claim 13 (a system claim) corresponds in scope to Claim 3, and is similarly rejected.
Claim 23 (a medium claim) corresponds in scope to Claim 3, and is similarly rejected.
As to Claim 5, Graefe, Montagna and Bellamkonda teach the method of claim 1, wherein rewriting the pivot query further comprises: aggregating the data for the pivot column into an object containing a key and a value (Bellamkonda: at least ¶¶0034-0035; “aggregate for each of the pivot values "Q1", "Q2", "Q3", and "Q4"” and “for example, the pivot column "QTR" has a value of "Q1", "Q2", "Q3", and "Q4". The lookup table may be set up as shown in TABLE 1”; ¶0040 further discloses “results of this aggregation operation are stored in a staging table”);
extracting the pivot value from the object to generate extracted pivot value (Bellamkonda: at least ¶0038; “staging table (of the second type) be used to populate pivot value columns (128 of FIG. 1) in a result set (128 of FIG. 1)”; ¶0043 also discloses “the result set 124 can then be obtained by a transpose operation performed on the staging table of the second type 302”); and populating output columns based on the extracted pivot value (Bellamkonda: at least ¶0028; “a staging table of a first type may be used to populate pivot value columns 128 in a result set 124 in accordance with an embodiment of the present invention”; ¶0044 further discloses “populate a cell of a pivot value column that corresponds to one of the possible values of the pivot columns. For example, the first row of the staging table of the second type 302 is used to populate a cell of the "Q1" pivot value column in the "Sales Pivoted" result set”).
Claim 15 (a system claim) corresponds in scope to Claim 5, and is similarly rejected.
Claim 25 (a medium claim) corresponds in scope to Claim 5, and is similarly rejected.
As to Claim 6, Graefe, Montagna and Bellamkonda teach the method of claim 5, wherein utilizing the object aggregation avoids individually aggregating the data for each potential pivot value (Bellamkonda: at least ¶0026; “values to be returned in the pivot value columns (128 of FIG. 1) in the result set (124 of FIG. 1) are aggregated values derived from aggregating stored values in the measure columns (116 of FIG. 1) of rows in the data table”).
Claim 16 (a system claim) corresponds in scope to Claim 6, and is similarly rejected.
Claim 26 (a medium claim) corresponds in scope to Claim 6, and is similarly rejected.
As to Claim 7, Graefe, Montagna and Bellamkonda teach the method of claim 1, wherein receiving the pivot query (Graefe: at least Col. 9 Lines 5-7; “Block 510 receives a query from a user at a client terminal 120, FIG. 1, or from some other source as described herein`”; Col. 13 Lines 2-3 further discloses “query 420”) specifying the pivot column (Graefe: at least Col. 8 Lines 24-26; “Pivot column 411, named Quarter in the input table 410 named Narrow, becomes four columns 431, 432, 433, and 434 in the output table 430”; Col. 9 Lines 7-10 further discloses “Step 520 identifies or selects which table 261 in database 260 is to serve as the input table of the operation. Step 521 identifies which column of the input table is to be the pivot column”) further comprises: receiving the pivot query to pivot a dataset (Graefe: at least Col. 8 Lines 47-50; “the pivot operation converts an input table having relatively many rows and relatively few columns into a result table having fewer rows and more columns”) based on values in the pivot column (Graefe: at least Col. 8 Lines 16-17; “elements in the pivot list appear as values in the pivot column”; Col. 9 Lines 10-11 further discloses “identifies from the pivot list which pivot-column values participate in the pivot”).
Claim 17 (a system claim) corresponds in scope to Claim 7, and is similarly rejected.
Claim 27 (a medium claim) corresponds in scope to Claim 7, and is similarly rejected.
Claims 8, 18 and 28 are rejected under 35 U.S.C. 103 as being unpatentable over US Patent 6,298,342 by Graefe in view of US PGPUB 2014/0019842 by Montagna et al. (“Montagna”), and further in view of US PGPUB 2010/0017363 by Bellamkonda et al. (“Bellamkonda”), and further in view of US PGPUB 2009/0063533 by Ting et al. (“Ting”).
As to Claim 8, Graefe, Montagna and Bellamkonda teach the method of claim 1, wherein receiving the pivot query further comprises: receiving a second pivot query (Graefe: at least Col. 4 Line 4; ”processing pivot and unpivot queries”; note: queries means at least first and second pivot queries) including at least one of input data, an aggregation metric, or a second pivot column (Graefe: at least Col. 9 Lines 9-11; “Step 521 identifies which column of the input table is to be the pivot column, step 522 identifies from the pivot list which pivot-column values participate in the pivot).
Graefe and Montagna do not explicitly disclose, but Bellamkonda discloses applying optimization rules to rewrite the pivot operator node using object aggregation and deterministic ordering techniques (Bellamkonda: at least ¶0034; “internally converts the pivoting query” and “the database system only evaluates one aggregate for each of the pivot values "Q1", "Q2", "Q3", and "Q4"”; ¶0017 also discloses ““the pivot column ("QTR")”) according to an optimized logical plan (Bellamkonda: at least ¶0034; “equivalent query may be expressed in a statement "S3" ” and “… converts the pivoting query to an equivalent query whose query plan, when executed, performs the steps in connection with a staging table 202 as described above”; ¶0050 further discloses “determine that the query execution plan "S3" has the lowest cost”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Bellamkonda’s feature of applying optimization rules to rewrite the pivot operator node using object aggregation and deterministic ordering techniques (Bellamkonda: at least ¶0034) according to an optimized logical plan (Bellamkonda: at least ¶¶0034, 0050) with the method disclosed by Graefe and Montagna.
The suggestion/motivation for doing so would have been to allow for “efficient evaluation of pivot operations” (Bellamkonda: at least ¶0013).
Graefe, Montagna and Bellamkonda do not explicitly disclose, but Ting discloses parsing the second pivot query into an abstract syntax tree representation (Ting: at least ¶0007; “A query tree may be generated, from the query, which describes the query in tree representation”) including a pivot operator node (Ting: at least ¶0088; “`pivoting` procedure described above is modified so that the procedure pivots at specific match nodes that correspond to matches to step nodes”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Ting’s feature of parsing the second pivot query into an abstract syntax tree representation (Ting: at least ¶0007) including a pivot operator node (Ting: at least ¶0088) with the method disclosed by Graefe, Montagna and Bellamkonda.
The suggestion/motivation for doing so would have been to perform “inter-document level filtering or return single extractions (e.g. a single set of results”) (Ting: at least ¶0008).
Claim 18 (a system claim) corresponds in scope to Claim 8, and is similarly rejected.
Claim 28 (a medium claim) corresponds in scope to Claim 8, and is similarly rejected.
Claims 9-10, 19-20 and 29-30 are rejected under 35 U.S.C. 103 as being unpatentable over US Patent 6,298,342 by Graefe in view of US PGPUB 2014/0019842 by Montagna et al. (“Montagna”), and further in view of US PGPUB 2010/0017363 by Bellamkonda et al. (“Bellamkonda”), and further in view of US PGPUB 2009/0063533 by Ting et al. (“Ting”), and further in view of US PGPUB 2009/0254916 by Bose et al. (“Bose”).
As to Claim 9, Graefe, Montagna, Bellamkonda and Ting teach the method of claim 8.
Graefe, Montagna, Bellamkonda and Ting do not explicitly disclose, but Bose discloses further comprising: converting the optimized logical plan into a physical distributed execution plan (Bose: at least ¶0054; “query plan segment can be distributed among the query sub-plans in the segment”) with shuffle stages for intermediate data exchange (Bose: at least ¶0144; “single node query plan is then converted to a parallel plan by introducing exchange operators at specific locations of the plan”; ¶¶0056-0057 also disclose “plurality of operators (e.g., project, aggregate, exchange, join, tablescan, and the like). The result of one operator can be fed to a subsequent operator” and “exchange operator can be used to denote the boundary between query sub-plans. So, in the example of FIG. 7, the query plan 700 can be divided into the sub-plans A-G”; note: subplans as shuffle stages that are intermediate); and
dispatching the physical distributed execution plan to worker nodes for parallel distributed execution (Bose: at least ¶¶0107, 0110; “allocation of computing resource nodes to the segments is performed (e.g., via the techniques in FIGS. 9 and 10 or any of the other examples herein). For example, two computing resources are allocated at a time” and “nodes are distributed among the sub-plans in respective segments”) across data partitions (Bose: at least ¶0151; “Ak can represent the total amount of data to be processed by the sub-plan k. tkj can be the time required to process the dataset Ak on machine j. tkj can be calculated as the summation of the processing time of the operators”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Bose’s features of converting the optimized logical plan into a physical distributed execution plan (Bose: at least ¶0054) with shuffle stages for intermediate data exchange (Bose: at least ¶¶0056-0057, 0144); and dispatching the physical distributed execution plan to worker nodes for parallel distributed execution (Bose: at least ¶¶0107, 0110) across data partitions (Bose: at least ¶0151) with the method disclosed by Graefe, Montagna, Bellamkonda and Ting.
The suggestion/motivation for doing so would have been to perform “efficient execution of bushy query plans in a grid environment” where “parallel processing will reduce the overall response time of the query” (Bose: at least Abstract).
Claim 19 (a system claim) corresponds in scope to Claim 9, and is similarly rejected.
Claim 29 (a medium claim) corresponds in scope to Claim 9, and is similarly rejected.
As to Claim 10, Graefe, Montagna, Bellamkonda, Ting and Bose teach the method of claim 9, further comprising: sorting final pivot results (Graefe: at least Col. 8 Lines 26 & 57-59; “output table 430” and “table 430 is shown sorted by values of grouping columns Region and Year” where table 430 are output table); and providing the final pivot results to a client application (Graefe: at least Col. 5 Lines 35-37, Col. 6 Lines 32-34; “search engine 241 processes queries and other requests from individual clients 210 upon tables 261 of a database 260” and “the output of step 350 is the result of the query, in the form of an output table returned to the source of the query”; Col. 8 Lines 23-24 also discloses “… produces output table 430”).
Graefe, Montagna, Bellamkonda and Ting do not explicitly disclose, but Bose discloses sending intermediate shuffle data between the worker nodes via a cluster resource manager (Bose: at least ¶0040; “computing resource allocator 330 accepts the query plan 310 as input and outputs an allocation 370 of computing resources to the query plan (e.g., to individual sub-plans of the query plan)”) in order to perform “efficient execution of bushy query plans in a grid environment” where “parallel processing will reduce the overall response time of the query” (Bose: at least Abstract).
Claim 20 (a system claim) corresponds in scope to Claim 10, and is similarly rejected.
Claim 30 (a medium claim) corresponds in scope to Claim 10, and is similarly rejected.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the Examiner should be directed to Huen Wong whose telephone number is (571) 270-3426. The examiner can normally be reached on Monday - Friday (10:30AM EST - 6:30PM EST). If attempts to reach the examiner by telephone are unsuccessful, the Examiner's supervisor, Charles Rones can be reached on (571) 272-4085. The fax phone number for the organization where this application or proceeding is assigned is (571) 273-8300 for regular communications and after final communications.
Information regarding the status of an application may be obtained from thePatent Application Information Retrieval (PAIR) system. Status information forpublished 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. Shouldyou have questions on access to the Private PAIR system, contact the ElectronicBusiness Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from aUSPTO Customer Service Representative or access to the automated informationsystem, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/H .W./
Examiner, AU 2168
05 February 2026
/CHARLES RONES/Supervisory Patent Examiner, Art Unit 2168