DETAILED ACTION
This communication is in response to the Applicant Arguments/Remarks filed on 12/23/2025. Claims 1-5, 7, 9-14, 16, 18-20 are pending in the application.
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 .
Response to Arguments
Applicant's arguments filed 12/23/2025 have been fully considered.
Regarding the argument on page 9 that the cited references “fails to teach a determination that the tree depth of a parse tree does not exceed a predetermined value that corresponds to a predetermined maximum tree depth, as presently claimed”, examiner respectfully disagrees.
Cseri teaches at para. 33: performs query optimization and compilation; para. 47: the job compiler parses a job into multiple discrete tasks; para. 142: query validation may be performed by the row-wise views manager using an SqlValidator tree visitor. The validation may run over a fully expanded tree; para. 70-72: the append-only type only finds rows that were appended to the table; para. 97: append-only change queries may be introduced to work around cases when this scaling does not hold for delta queries; para. 140, 178-179: the compiler phases used by the join views manager can include: (a) Parsing (SqlParser): turns query text into the parse tree representing query syntax; para. 179-182: parsing (SqlParser): turns query text into the parse tree representing query syntax. Query planning and takes the optimized query plan and produces an SDL program for XP to execute. Thus, the query planning took place on a completed parse tree or there is no another view defined by the query.
Paulley teaches at para. 39: a limit is imposed on the depth (a predetermined maximum tree depth) to which sub-expressions are normalized to avoid an explosion in the number of terms;
para. 95-96: a limit is imposed on the depth to which sub-expressions are fully normalized to avoid an explosion in the number of terms. As In lists are discovered, the number of elements in each such list are counted in order to determine whether or not the list is "expensive" and should not be converted. If the running total of elements counted exceeds the maximum allowable number of elements (for example, a total of more than 45 elements), the segment is deemed "expensive" and is not converted. Thus, the best query execution plan is cost effective and not over the depth limit/threshold.
Regarding the argument in relating to the newly amended limitation “transmitting the execution plan to execution engines including a row engine and a column engine for execution of the query, as presently claimed”, please see the new combination of references with columns and lines cited below.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-5, 7-14, 16-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Cseri et al. (US 20230092367) in view of McShane (US 20160098448) and further in view of Paulley et al. (US 20020143754).
As per claims 1, 10, 19, Cseri et al. (US 20230092367) teaches
a system, comprising: at least one processor; and at least one memory storing instructions, which when executed by the at least one processor, result in operations comprising: receiving a query, wherein the query defines multiple views (para. 80: provide or process streams on views in connection with the following three use cases: shared views, complex views, and view evolution; para. 112: create views is a SQL query to create views; para. 121: select from view…; para. 177: select/project views (the select views statement is equivalent to query views); para. 215: a computer-readable instructions for execution by one or more hardware components (e.g., one or more processors));
generating a parse tree based on the query (para. 134: handle the VIEW table kind in SqlParser::generateParseTreeCreateDDL; fig. 13; para. 179: parsing (SqlParser): turns query text into the parse tree representing query syntax);
preprocessing the query using the parse tree; traversing the parse tree to identify the multiple views (para. 135, 140-144: traverse the view and perform stream expansion on each leaf table. Because of the algebraic properties of row wise views, performing the current stream expansion on the interior of the view may be used as well; para. 179-181: (a) Parsing (SqlParser): turns query text into the parse tree representing query syntax. (b) Typechecking (SqlTypechecker):. Name resolution (SqlObjectNameResolver::resolve) resolves names in the parse tree into dictionary entities, checking permissions, and expanding views; para. 190: during parse tree optimizations, optimizations may be prevented from doing rewrites incompatible with the change view);
executing, for a current view of the multiple views, view unfolding to generate a view subtree; attaching the view subtree to the parse tree (para. 191: during parse tree translation, the change view may be transformed to have an additional QueryPlanNode that indicates that the subtree beneath it should be rewritten as a change query. A new class, QueryPlanNodeChanges, may be created, which contains the change type and frontiers to resolve. The change type can be MIN_DELTA, APPEND _ONLY, and INSERT_ONLY);
generating a view query compile tree; determining whether there is another view defined by the query (para. 33: performs query optimization and compilation; para. 47: the job compiler parses a job into multiple discrete tasks; para. 142: query validation may be performed by the row-wise views manager using an SqlValidator tree visitor. The validation may run over a fully expanded tree; para. 70-72: the append-only type only finds rows that were appended to the table; para. 97: append-only change queries may be introduced to work around cases when this scaling does not hold for delta queries; para. 140, 178-179: the compiler phases used by the join views manager can include: (a) Parsing (SqlParser): turns query text into the parse tree representing query syntax; para. 179-182: parsing (SqlParser): turns query text into the parse tree representing query syntax. Query planning and takes the optimized query plan and produces an SDL program for XP to execute. Thus, the query planning took place on a completed parse tree or there is no another view defined by the query.);
in response to determining that there is not another view defined by the query: traversing the parse tree; generating an execution plan (para. 48: generate query plans for executing received queries; para. 103-104: providing change sets on a view (e.g., a query) is similar to the incremental materialized view maintenance problem. In the case of MVs as the underlying data source(s) change, the materialized data set may be updated incrementally. In some aspects, this processing may be performed at the micro-partition level/depth to create a query plan which uses the data from the added/deleted partitions and merges it with the MV data to produce the updated data; para.142: query validation may be performed by the row-wise views manager using an SqlValidator tree visitor. The validation may run over a fully expanded tree. Thus, there is not another view left; para. 48: generate query plans for executing received queries; para. 179-182: parsing (SqlParser): turns query text into the parse tree representing query syntax. Query planning and takes the optimized query plan and produces an SDL program for XP to execute).
Cseri does not explicitly teach transmitting the execution plan to execution engines including a row engine and a column, and in response to determining that there is another view defined by the query.
McShane teaches in fig. 3: a database query is parsed and query portions/sub-queries are optimized with subset of alternative queries, transmitting to the execution engine(s) for querying the database; para. 13: identify common sub-expressions and derive more efficient execution plans; exploit the different capabilities of different calculation engines; para. 22: execution engine(s) 114 execute the replacement database query or queries on a dataset and provide a result. Execution engine(s) can be software applications that perform queries or portions of queries. Execution engine(s) can include OLAP engines, calculation engines, join engines, row engines, column engines; para. 37: the below query mixes ROW SEARCH (ROW engine) with two COLUMN SEARCHES on the COLUMN engine…
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Cseri to include a row engine and a column engine of McShane in order to take advantage of a row engine’s fast execution on transaction-heavy applications and a column engine’s rapid query performance for analytical tasks by reading only necessary columns.
Cseri and McShane do not explicitly teach determining whether the tree depth exceeds a predetermined value that corresponds to a predetermined maximum tree depth; in response to determining that the tree depth does not exceed the predetermined value, generating an execution plan, skipping calculation of the tree depth of the parse tree such that the calculation of the tree depth is performed only when there is not another view defined by the query.
Paulley teaches
determining whether the tree depth exceeds a predetermined value that corresponds to a predetermined maximum tree depth; in response to determining that the tree depth does not exceed the predetermined value, generating an execution plan (para. 39: a limit is imposed on the depth (a predetermined maximum tree depth) to which sub-expressions are normalized to avoid an explosion in the number of terms; para. 95-96: a limit is imposed on the depth to which sub-expressions are fully normalized to avoid an explosion in the number of terms. As In lists are discovered, the number of elements in each such list are counted in order to determine whether or not the list is "expensive" and should not be converted. If the running total of elements counted exceeds the maximum allowable number of elements (for example, a total of more than 45 elements), the segment is deemed "expensive" and is not converted. Thus, the best query execution plan is cost effective and not over the depth limit/threshold).
in response to determining that there is another view defined by the query, skipping calculation of the tree depth of the parse tree such that the calculation of the tree depth is performed only when there is not another view defined by the query (para. 95: the normalization phase of the present invention selectively examines each element of the SQL statement by carefully descending the logic/parsed tree of the query. Segments that are "expensive" to fully normalize are not fully normalized to avoid a combinatorial explosion of terms and the resulting impact on system performance. Effectively, a limit is imposed on the depth to which sub-expressions are fully normalized to avoid an explosion in the number of terms; fig. 3: the server receives a SQL statement. The parser parses said query into a parsed tree and the normalizer then processes the completed parsed tree. Therefore, as the parser has not done the parsing of the query statement (still there is another view defined by the query), the normalizer or compiler has not received the parse tree from the parser in order to compute the tree depth.)
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Cseri and McShane to include an imposed limit on the tree depth of Paulley in order to effectively avoid an explosion in the number of terms, processing costs, and or resources.
As per claims 2, 11, 20, Cseri et al. teaches
in response to determining that there is another view defined by the query: executing subsequent view unfolding to generate a subsequent view subtree; and attaching the subsequent view subtree to the parse tree (para. 191: during parse tree translation, the change view may be transformed to have an additional QueryPlanNode that indicates that the subtree beneath it should be rewritten as a change query. A new class, QueryPlanNodeChanges, may be created, which contains the change type and frontiers to resolve. The change type can be MIN_DELTA, APPEND _ONLY, and INSERT_ONLY).
As per claims 3, 12, Cseri et al. teaches
wherein the preprocessing comprises: semantic and syntactic checking of the query using the parse tree (para. 87: provide or process streams on views in connection with the above-listed use cases, the streams manager 128 may be configured with the following functionalities: intuitive semantics, unsurprising security, linear cost scaling, and easy operability; fig. 13: determine a syntax tree of the query based on a definition of the view).
As per claims 4, 13, Cseri et al. teaches
wherein determining whether there is another view defined by the query comprises determining whether the current view is a last view defined by the query (para. 47: the compute service manager 108 also includes a job compiler 212, a job optimizer 214, and a job executor 216. The job compiler 212 parses a job into multiple discrete tasks and generates the execution code for each of the multiple discrete tasks. The job optimizer 214 determines the best method to execute the multiple discrete tasks based on the data that needs to be processed. Thus, as views are created, all views are generated based on the query definition – See para. 112: create views is a SQL query to create views).
As per claims 5, 14, Cseri et al. teaches
in response to determining that there is another view defined by the query, performing view unfolding for a next view and attaching a view subtree for the next view to the parse tree (para. 191: during parse tree translation, the change view may be transformed to have an additional QueryPlanNode that indicates that the subtree beneath it should be rewritten as a change query. A new class, QueryPlanNodeChanges, may be created, which contains the change type and frontiers to resolve. The change type can be MIN_DELTA, APPEND _ONLY, and INSERT_ONLY).
As per claims 7, 16, Cseri et al. teaches outputting an error message at para. 100-101.
Cseri et al. does not teach said claims.
Paulley teaches
in response to determining that the tree depth exceeds a predetermined value (para. 39: examines each element of the SQL statement by carefully descending the logic tree of the query. The expression is examined in segments and for each segment a determination is made as to whether or not it is advantageous to convert that segment of the expression to CNF. Segments that are too "expensive" to fully convert are not fully normalized to avoid a combinatorial explosion of terms and the resulting impact on system performance. Effectively, a limit is imposed on the depth to which sub-expressions are normalized to avoid an explosion in the number of terms; para. 96).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Cseri to include an imposed limit on the tree depth of Paulley in order to effectively avoid an explosion in the number of terms, processing costs, and or resources).
Claim(s) 9, 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Cseri et al. (US 20230092367) in view of McShane (US 20160098448) and further in view of Paulley et al. (US 20020143754) and Adya et al. (US 20070226196).
As per claims 9, 18, Cseri et al. teaches
wherein the executing of the view unfolding is performed for each of the multiple views to generate a plurality of view subtrees corresponding to the multiple views, and wherein the attaching of the view subtree to the parse tree is performed for each of the plurality of view subtrees such that the parse tree is attached to each of the plurality of view subtrees (para. 48: a job scheduler and coordinator send received jobs to the appropriate services or systems for compilation, optimization, and dispatch to the execution platform, the virtual warehouse manager may generate query plans for executing received queries; para. 104: in the case of MVs as the underlying data source(s) change, the materialized data set may be updated incrementally. In some aspects, this processing may be performed at the micro-partition level to create a query plan which uses the data from the added/deleted partitions and merges it with the MV data to produce the updated data; para. 176-181: parsing (SqlParser): turns query text into the parse tree representing query syntax. Parse tree translation: translate SQL syntactic constructs into a uniform representation of operators accepting inputs and producing outputs. For example, a SELECT expression is split into nodes for scanning, selection, projection, joining, and aggregation; para. 191: (d) During parse tree translation, the change view may be transformed to have an additional Query
PlanNode that indicates that the subtree beneath it should be rewritten as a change query...APPEND_ONLY etc.; para. 194: the join views manager 230 is configured to perform change rewrites to push the QueryPlanNodeChanges node down through the plan tree until there are no more Changes nodes in the tree. Thus, performing the view unfolding for each of the multiple views.)
Even if Cseri, McShane, Paulley do not explicitly teach the limitation “unfolding”,
Adya teaches said limitation at para. 96: execution: update translation is done using a general mechanism that leverages materialized view maintenance, a robust database technology. Query translation uses view unfolding; para. 126-129.
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Cseri, McShane, Paulley to include the view unfolding of Adya in order to effectively improve performance by avoiding intermediate engine processing, thus, reduce the workload on the calculation engine.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Scherrer (US 20170255662) teaches at para. 79-80: execution plan, execution engine.
Ghazal et al. (20140181074) teaches at para. 25: global query optimizations (for steps of different iterations), where common components of multiple execution plans are isolated and executed only once to avoid redundant repetition, may not be possible with a technique using feedback at each iteration (full feedback) given that the execution plans may not be known up-front In view of the foregoing, improved techniques for generating plans for execution of recursive database queries are needed and would be very useful.
Lennon et al. (US 20040015783) teaches in the abstract: the existing query data typically includes one or more views of data; para. 12-13.
Hu et al. (US 20220050843) teaches at para. 2: query processing in a database management system (DBMS), and in particular to a DBMS that caches execution plans for a query based on its execution times to learn a relatively low-cost execution plan for the query.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 LINH BLACK whose telephone number is (571)272-4106. The examiner can normally be reached 9AM-5PM EST M-F.
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, Tony Mahmoudi can be reached on 571-272-4078. 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.
/LINH BLACK/Examiner, Art Unit 2163 4/20/2026
/TONY MAHMOUDI/Supervisory Patent Examiner, Art Unit 2163
Prosecution Insights