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 .
Introductory Remarks
In response to communications filed on 7 July 2026, claims 1, 8, and 15 are amended per Applicant's request. Claims 3, 10, and 17 are cancelled. No claims were withdrawn. No new claims were added. Therefore, claims 1-2, 4-9, 11-16, and 18-20 are presently pending in the application, of which claims 1, 8, and 15 are presented in independent form.
The previously raised 103 rejection of the pending claims is withdrawn in view of the amendments to the claims. A new ground(s) of rejection has been issued.
Response to Arguments
Applicant’s arguments filed 7 July 2026 with respect to the rejection of the claims under 35 U.S.C. 103 have been fully considered but are not persuasive.
Applicant argues that Zhou does not disclose that the pruning predicate is removed “based on evaluating the respective predicate filter operation on top of each of the one or more table scan operations within the secure object boundary from the second plan…” (see Remarks, p. 9). However, secondary reference Lee shows pushing filter operations on top of table scans. Thus, Zhou combined with Lee, in which a filter operation, such as Zhou’s pruning predicate filter operation, prior to the table scan, discloses the combination of the independent claims’ limitations.
Applicant argues that Yuen does not disclose the claimed limitations. However, the combination of Yuen, Lee, and Zhou were found to disclose the combination of the claimed elements. See the new ground(s) of rejection below for further detail.
Claim Objections
Claims 1, 8, and 15 are objected to because of the following informalities: there is a missing semicolon and newline for the newly added claim language “pushing down the first pruning predicate filter operation within the secure object boundary onto one or more table scan operations; [<newline><tab>] converting the first pruning predicate filter operation into a respective pruning predicate filter operation on top of each of the one or more table scan operations”. Appropriate correction is required.
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.
Claims 1-2, 5-9, 12-16, and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Yuen et al. (“Yuen”) (US 2023/0169121 A1), in view of Lee et al. (“Lee”) (US 2020/0042737 A1), in further view of Zhou et al. (“Zhou”) (US 2017/0017684 A1).
Regarding claim 1: Yuen teaches A system comprising:
at least one hardware processor; and at least one memory storing instructions that, when executed by the at least one hardware processor, cause the at least one hardware processor to perform operations comprising (Yuen, [0042-0043], where the disclosed system may be implemented as a computer device that includes a processor 510 and memory 520, the memory being a computer-readable medium, and the processor 510 can process instructions for execution within the computing device including instructions stored in the memory 520):
providing a secure object of a source table of a provider account to one or more consumer accounts in a network-based data system, the secure object limiting access to a subset of data in the source table (Yuen, [0026], where the data store 150 allows scalable use of the storage resources by one or more clients (e.g., the user device 10). See Yuen, [0028], where the filter extractor 200 determines whether a security filter 212 (i.e., a row-level security filter) restricts the user 12 (or a user account or user device 10) associated with the database query 20 from accessing (i.e., reading or writing) one or more rows of the queried database 158. This indicates that the system “provides secure object”—(i.e., secure row)—“of the source table to one or more consumer accounts”.
See Yuen, [0026], where the database query optimizer system 100 includes a remote system 140 having scalable/elastic resources 142 including one or more storage resources 144, with a data store 150 overlain on the storage resources 146 to allow scalable use of the storage resources a data store 150 configured to store rows within one or more databases or tables (i.e., “a source table of a provider account”));
receiving a command from the one or more consumer accounts (Yuen, [0027], where the remote system 140 receives a database query 20 (i.e., a request) from a user device 10 (or user account; see Yuen, [0028]) associated with a respective user, the database query includes one or more user filters to conditionally return one or more data blocks stored at the queried databases 158);
generating a first plan to execute the command using the secure object, the first plan including a secure object boundary on a subset of operations defining the secure object (Yuen, [0025], where the query optimizer enforces row level security filters by splitting or dividing the user filters into a “safe” user filter set and an “unsafe” user filter set. See Yuen, [0028-0030] with respect to details as to how the plan was generated, which results in the security filter being logically ANDed with the user filters to further restrict the rows of the queried database that can be returned to the user);
[writing] the first plan to provide a first operation that was outside the secure object boundary to within the secure object boundary … (Yuen, [0036], where the filter executor places at least one safe user filter 212U earlier in the filter execution order 172 than the security filter 212S (i.e., “inserting the non-error producing filter property within the secure object boundary as the first operation”). That is, the filter executor 170 may execute the user filters 212U and the security filter 212S in any order as long as the security filter 212S executes prior to the unsafe user filters 212UU), the modifying comprising:
splitting a filter operation outside of the secure object boundary in the first plan into one or more error-producing filter property and one or more non-error producing filtering property (Yuen, [0025], where the query optimizer splits or divides the user filters into a “safe” user filter set (i.e., “non-error producing filtering property”) and an “unsafe” user filter set (i.e., “error-producing filter property”), where safe user filters cannot result in an error that leaks information while unsafe user filters may result in an error that leaks information); and
inserting the non-error producing filter property within the secure object boundary as the first operation in the second plan; extracting a … predicate from the filter operation outside the secure object boundary; adding a first … predicate filter operation based on the extracted … predicate to within the secure object boundary (Yuen, [0025], where the query optimizer ensures that the row level security filter (i.e., which establishes the claimed “secure object boundary”)1 executes prior to the unsafe user filters, but freely optimizes the queries using the safe user filters. See Yuen, [0036], where the filter executor places at least one safe user filter 212U earlier in the filter execution order 172 than the security filter 212S (i.e., “inserting the non-error producing filter property within the secure object boundary as the first operation”). That is, the filter executor 170 may execute the user filters 212U and the security filter 212S in any order as long as the security filter 212S executes prior to the unsafe user filters 212UU. See also Yuen, [0029-0033], where the database query requests all rows that include values for certain columns, and thus only rows 152 where all three user filters 212Ua-c evaluate to true should be returned. The security filter 212S is then logically ANDed with the user filters 212Ua-c to further restrict the rows, e.g., based on the columns. Thus in this manner, the system “extract[s] a…predicate from the filter operation”, and “add[s] a first…predicate filter operation based on the extracted…predicate to within the secure object boundary”, where the combination of the security filter and the user filters, placed before the unsafe user filters, represents the “secure object boundary” (see Yuen, [0036] above)); … and
executing the second plan to generate results of the command (Yuen, [0037], where the filter executor executes, using the filter execution order, each of the filters (i.e., the security filter, the safe user filters, and the unsafe user filters) to retrieve one or more rows for the user. The query optimizer 160 may return the retrieved rows 152 to the user 12).
Yuen does not appear to explicitly teach [modifying the first plan] to generate a second plan; [inserting the filter property as the first operation in the] second [plan]; pushing down the first pruning predicate filter operation within the secure object boundary onto one or more table scan operations[;] converting the first pruning predicate filter operation into a respective pruning predicate filter operation on top of each of the one or more table scan operations; during a compilation phase, performing a pruning predicate filter operation on the source table to eliminate one or more partitions from the source table, the performing the pruning predicate filter operation comprising evaluating the respective pruning predicate filter operation on top of each of the one or more table scan operations within the secure object boundary; in response to performing the pruning predicate filter operation and prior to a query execution phase, removing the pruning predicate based on evaluating the respective predicate filter operation on top of each of the one or more table scan operations within the secure object boundary from the second plan such that the pruning predicate filter operation is not evaluated during execution of the second plan; [and executing the] second [plan].
Lee teaches [modifying the first plan] to generate a second plan; [inserting the filter property as the first operation in the] second [plan] (Lee, [0064], where secure view processing is implemented through rewrites of the query plan tree during optimization (i.e., the “rewrite” implying that a first plan is modified to generate a rewritten, i.e., second plan). The query plan tree rewrites are implemented such that no expression not stemming from a secure view can be pushed down below the view boundaries. See also Lee, [0090], where the secure view component 912 may rewrite the query plan tree during optimization, e.g., during filter pullup and/or filter pushdown);
pushing down the first … predicate filter operation within the secure object boundary onto one or more table scan operations[;] converting the first … predicate filter operation into a respective … predicate filter operation on top of each of the one or more table scan operations (Lee, [0065-0067], where secure views are optimized, including allowing transformations to expressions that can be pushed through a secure view boundary if they are deemed safe (known to produce no errors and contains no user-defined functions). When using a secure view, filters pushed back down through the join may result in filters being pushed to both sides of the join, i.e., on top of table scans (see, e.g., Lee, [FIGs. 11-19], where filters are always shown on top of table scans). See Yuen above with respect to the “predicate filter operation”); [and]
[executing the] second [plan] (Lee, [0085], where database requests, queries, or statements are processed, and a response to the request is returned to the user. See Yuen above with regards to the “execution” of the plan).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined the teachings of Yuen and Lee (hereinafter “Yuen as modified”) by substituting Yuen’s query optimization with Lee’s query rewrites (i.e., such that Yuen’s query optimization occurs as part of Lee’s rewrites), as Lee discloses in [0090] that the rewriting of the query plan may occur during optimization. Therefore, one of ordinary skill in the art would have been motivated to modify Yuen as such (i.e., including Lee’s query rewrites) with the motivation of greater efficiency (i.e., faster query execution due to reduced data processing and disk I/O).
Furthermore, it would have been obvious to one of ordinary skill in the art to have applied the filter to both sides of the table joins with the motivation of decreasing the size of the tables being joined, thereby improving the speed of joining the tables (i.e., smaller tables means faster speed for searching/scanning and joining).
Yuen as modified does not appear to explicitly teach that the filter pertains to pruning predicate filters; during a compilation phase, performing a pruning predicate filter operation on the source table to eliminate one or more partitions from the source table, the performing the pruning predicate filter operation comprising evaluating the respective pruning predicate filter operation on top of each of the one or more table scan operations within the secure object boundary; in response to performing the pruning predicate filter operation and prior to a query execution phase, removing the pruning predicate based on evaluating the respective predicate filter operation on top of each of the one or more table scan operations within the secure object boundary from the second plan such that the pruning predicate filter operation is not evaluated during execution of the second plan.
Zhou teaches that the filter pertains to pruning predicate filters; during a compilation phase, performing a pruning predicate filter operation on the source table to eliminate one or more partitions from the source table, the performing the pruning predicate filter operation comprising evaluating the respective pruning predicate filter operation on top of each of the one or more table scan operations within the secure object boundary; in response to performing the pruning predicate filter operation and prior to a query execution phase, removing the pruning predicate based on evaluating the respective predicate filter operation on top of each of the one or more table scan operations within the secure object boundary from the second plan such that the pruning predicate filter operation is not evaluated during execution of the second plan (Zhou, [0019], [0049], and [0061-0062], where the system computes predicate push down and partition pruning, where a predicate is evaluated on critical points ranges to qualify or disqualify them, and a reduced predicate on a qualified critical point range may be generated. The qualified critical point ranges are compared and matched to range partitions of data stored in the distributed system to qualify the range partitions. The partition-specific reduced predicates are processed against the data in the qualified range partitions to obtain a query result, resulting in efficiently and precisely generated “pruned” partitions, partition-specific push down predicates on range-partitioned data sets from arbitrarily complex logic predicates in a query.
See also, e.g., Zhou, [0003], where the system performs these steps prior to the query being executed, in which the system subsequently processes the reduced predicate against the data in the qualified data partitions to obtain query results (i.e., “during a compilation phase” and “prior to a query execution phase”). See Lee, [0064] and [0090] above with respect to the “second plan”.
Recall from Lee, [FIGs. 11-19] above, where filters on always shown on top of table scans (i.e., “evaluating the respective predicate filter operation on top of … one or more table scan operations within the secure object boundary”), and that the filters may be pushed to both sides of the join (i.e., “on top of each of the one or more table scan operations”). Thus, when combined with Zhou, in which Lee had pushed the filter predicates on top of each of the tables in the table join, this will result in evaluating the respective predicate filter operations prior to the table scan operations in accordance with Lee’s query plan rewrite).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined the teachings of Yuen as modified and Zhou (hereinafter “Yuen as modified”) with the motivation of efficiently and precisely computing predicate push down and partition pruning, which speeds up the query generation plan (i.e., instead of utilizing all partitions including ones that are not utilized/necessary within the query, the system limits the query generation plan to the subset of relevant partitions in an efficient manner), while also removing any attempts to operate on the pruned partitions (thereby conserving resources, and speeding up processing).
Regarding claim 2: Yuen as modified teaches The system of claim 1, the operations further comprising:
pushing down the first operation below a join operation in the second plan (Lee, [0064], where secure view processing is implemented through rewrites of the query plan tree during optimization (i.e., the rewrite implicitly resulting in a “second plan” as claimed), where no expression not stemming from a secure view can be pushed down below the view boundaries, which may be implemented by generating a new type of projection operator, e.g., secure-projection operator (i.e., note that “projection” corresponds to the claimed “join operation”)).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined the teachings of Yuen as modified and Lee with the motivation of avoiding leaks, i.e., only allowing expressions to be pushed through a secure view boundary if the expression is deemed safe (Lee, [0091]).
Regarding claim 5: Yuen as modified teaches The system of claim 1, the operations further comprising:
converting an outer join within the secure object boundary to an inner join within the secure object boundary based on moving a null filtering operation to within the secure object boundary (Lee, [0068], where the outer join to inner join conversion includes a filter predicate appearing immediately above a join, wherein the filter predicate filters out nulls from the null-extended side of the outer join. If a secure view includes an outer join, and a user filter filters out nulls, then the filter may not be pushed all the way to the join if it is not a safe-to-push filter).
Regarding claim 6: Yuen as modified teaches The system of claim 1, the operations further comprising:
splitting a filter operation outside of the secure object boundary in the first plan into an unsecure filter operation and secure filter operation (Yuen, [0025], where the query optimizer splits or divides the user filters into a “safe” user filter set (i.e., “secure filter operation”) and an “unsafe” user filter set (i.e., “unsecure filter operation”), where safe user filters cannot result in an error that leaks information while unsafe user filters may result in an error that leaks information); and
inserting the secure filter operation within the secure object boundary as the first operation in the second plan (Yuen, [0025], where the query optimizer ensures that the row level security filter (i.e., which establishes the claimed “secure object boundary”)2 executes prior to the unsafe user filters, but freely optimizes the queries using the safe user filters. See Yuen, [0036], where the filter executor places at least one safe user filter 212U earlier in the filter execution order 172 than the security filter 212S (i.e., “inserting the non-error producing filter property within the secure object boundary as the first operation”). That is, the filter executor 170 may execute the user filters 212U and the security filter 212S in any order as long as the security filter 212S executes prior to the unsafe user filters 212UU).
Regarding claim 7: Yuen as modified teaches The system of claim 6, the operations further comprising:
pushing down the first operation below a join operation in the second plan (Lee, [0064], where secure view processing is implemented through rewrites of the query plan tree during optimization (i.e., the rewrite implicitly resulting in a “second plan” as claimed), where no expression not stemming from a secure view can be pushed down below the view boundaries, which may be implemented by generating a new type of projection operator, e.g., secure-projection operator (i.e., note that “projection” corresponds to the claimed “join operation”)).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined the teachings of Yuen and Lee with the motivation of avoiding leaks, i.e., only allowing expressions to be pushed through a secure view boundary if the expression is deemed safe (Lee, [0091]).
Regarding claim 8: Claim 8 recites substantially the same claim limitations as claim 1, and is rejected for the same reasons.
Regarding claim 9: Claim 9 recites substantially the same claim limitations as claim 2, and is rejected for the same reasons.
Regarding claim 12: Claim 12 recites substantially the same claim limitations as claim 5, and is rejected for the same reasons.
Regarding claim 13: Claim 13 recites substantially the same claim limitations as claim 6, and is rejected for the same reasons.
Regarding claim 14: Claim 14 recites substantially the same claim limitations as claim 7, and is rejected for the same reasons.
Regarding claim 15: Claim 15 recites substantially the same claim limitations as claim 1, and is rejected for the same reasons.
Regarding claim 16: Claim 16 recites substantially the same claim limitations as claim 2, and is rejected for the same reasons.
Regarding claim 19: Claim 19 recites substantially the same claim limitations as claim 5, and is rejected for the same reasons.
Regarding claim 20: Claim 20 recites substantially the same claim limitations as claim 6, and is rejected for the same reasons.
Claims 4, 11, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Yuen et al. (“Yuen”) (US 2023/0169121 A1), in view of Lee et al. (“Lee”) (US 2020/0042737 A1), in further view of Zhou et al. (“Zhou”) (US 2017/0017684 A1), in further view of Dutta et al. (“Dutta”) (US 2005/0177570 A1).
Regarding claim 4: Yuen as modified teaches The system of claim 1, but does not appear to explicitly teach the operations further comprising: moving a predicate pull up from within the secure object boundary to outside the secure object boundary.
Dutta teaches moving a predicate pull up from within the secure object boundary to outside the secure object boundary (Dutta, [0058], where the optimizer 210 pulls non-security expressions above (i.e., “outside”) security expressions (i.e., “secure object boundary”) after ensuring that unsafe expressions cannot be utilized to return data prior to executing security expressions).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined the teachings of Yuen as modified and Dutta with the motivation of improving performance and mitigating data leaks (Dutta, [0009]).
Regarding claim 11: Claim 11 recites substantially the same claim limitations as claim 4, and is rejected for the same reasons.
Regarding claim 18: Claim 18 recites substantially the same claim limitations as claim 4, and is rejected for the same reasons.
Conclusion
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 IRENE BAKER whose telephone number is (408)918-7601. The examiner can normally be reached M-F 8-5PM PT.
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, Boris Gorney can be reached at (571) 270-5626. 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.
/IRENE BAKER/Primary Examiner, Art Unit 2154
10 October 2026
1 See Yuen, [0020], where security filter restricts database queries from a particular user to only a single “region” (i.e., boundary) associated with the particular user such that the particular user cannot return data from other regions.
2 See Yuen, [0020], where security filter restricts database queries from a particular user to only a single “region” (i.e., boundary) associated with the particular user such that the particular user cannot return data from other regions.
Prosecution Insights