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 .
Response to Arguments
Rejection under 35 U.S.C. § 102(a)(1) and 35 U.S.C. § 103
Applicant’s arguments filed on 2/3/2026, directed at the amended claims submitted on 2/3/2026 were considered, but are moot in view of new rejections made below in response to the latest amendments by applicant.
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.
Claims 1-3, 9, 11-13 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Murthy (US 2007/0276835), and further in view of Dutta (US 7,661,141).
Regarding claims 1, 11 and 20, Murthy teaches A computer-implemented method comprising:
detecting a first query targeting a first database object (see [0006]: “when a database system receives a query from a user”);
responsive to determining that a first row level security policy is defined for the first database object (see [0005]: “A finer grained approach may base access privileges at the row level. One such approach associates an Access Control List ("ACL") at the row-level and uses query rewrite to control access using the row-level association of the ACL. An ACL contains one or more access control entries. Each access control entry grants a set of privileges (e.g. read, write, etc) to a principal, such as a user, user group, or a user role. By associating an ACL with a row, a security policy may be specified at the level of a row.”):
dynamically generating a first filter predicate string based on the first row level security policy (see [0006]: “Under this approach, when a database system receives a query from a user, it rewrites the query (at least logically) to use ACLs to control what may be accessed by the query. Rewriting a query in a way that uses ACLs to control what operations are performed to execute the query, such accessing or modifying particular rows, is referred to herein as an access control rewrite, or simply rewrite.” And see [0007]: “In an access control rewrite, the query may be rewritten by appending a predicate that invokes an access control function or operator, to determine whether a user may perform a particular operation on a row. The access control function is implemented to determine whether one or more conditions or criteria, referred to herein as access control conditions, are met. If the access control conditions are met, the user has the necessary privilege to perform the required operation on a particular row, and the access control function returns a result indicating so. The following query QB illustrates an access control rewrite and use of an access control function.
TABLE-US-00001 QB
select * from Emp where Salary > 1000;
is implicitly rewritten to
TABLE-US-00002 QB'Func
select * from Emp where Salary > 1000 AND CHECK_ACL(aclid, "read") = 1.” And see [0009]: “The predicate that includes the CHECK_ACL function is evaluated using functional evaluation. In functional evaluation, each row of a set of rows is examined to determine whether a row satisfies a particular condition. In this case, the CHECK_ACL predicate (i.e. predicate containing the CHECK_ACL function) is evaluated for each row.”);
generating a first query result set during execution of the first query plan (see [0007]: “The following query QB illustrates an access control rewrite and use of an access control function.
TABLE-US-00001 QB
select * from Emp where Salary > 1000;
is implicitly rewritten to
TABLE-US-00002 QB'Func
select * from Emp where Salary > 1000 AND CHECK_ACL(aclid, "read") = 1.” And see [0011] In the current example, for purposes of illustration, table Emp has 1 million rows. The ACLs are set up such that the user issuing query QB has permission to access only 20 rows. There are 100,000 employees matching the Salary predicate, i.e. having Salary>1000 evaluate to true. To compute the query QB'Func, a database system accesses 100,000 rows (perhaps using an index).” The Examiner interprets the database system accessing 100,000 rows matching the Salary predicate, i.e. having Salary>1000 evaluate to true as generating a first query result set during execution of the first query plan.); and
applying the first filter predicate to the first query result set (emphasis added to show the difference between the reference and the claim) (see [0011]: “In the current example, for purposes of illustration, table Emp has 1 million rows. The ACLs are set up such that the user issuing query QB has permission to access only 20 rows. There are 100,000 employees matching the Salary predicate, i.e. having Salary>1000 evaluate to true. To compute the query QB'Func, a database system accesses 100,000 rows (perhaps using an index), applies CHECK_ACL function to all of them, but eliminates all but 20 rows from the result.” The Examiner interprets eliminating “all but 20 rows from the result” as applying the first filter predicate to the first query result set).
Murthy differs from claims 1, 11 and 20 in that it fails to teach converting the first filter predicate string into a first query optimizer predicate that is inserted into a query optimizer tree such that the first filter predicate string is applied to one or more nodes of the query optimizer tree; injecting the first query optimizer predicate into a first query plan.
In the same field of endeavor, Dutta discloses converting the first filter predicate string into a first query optimizer predicate that is inserted into a query optimizer tree such that the first filter predicate string is applied to one or more nodes of the query optimizer tree (see col. 8, line 57-col. 9, line 22: “It is to be appreciated that a security expression for data in the database 430 can be created by the owner or manager of the data and linked to one or more users. This link can be established as an outcome of a direct grant to the user or indirectly to the user through a grant to one or more user roles, servers, groups, etc. By way of example, the a table can be defined as: Emp(id int, salary float), wherein Emp is the table name, id is a variable of type integer and salary is a variable of type float. An expression for the table can be created through an SQL Create expression. For example, the following can be executed to create an expression for this table: CREATE EXPRESSION SalLimit ON Emp AS (salary<X), wherein SalLimit is the expression name, salary is the field to test, and X (e.g., 100000) is a variable that determines whether the row data satisfies the security expression. … The SalLimit security expression can be linked to a user through the following grant expression syntax: GRANT SELECT(where SalLimit) ON Emp TO User1, wherein User1 is a user granted permission to data in the rows of the table that satisfy SalLimit. Such statement can imply that User1 is allowed to see the rows in the Emp table that satisfy the SalLimit expression.” The Examiner interprets the SalLimit security expression (salary<X) as the first filter predicate string. And see col. 9, line 62-col. 10, line 8 and Fig. 2: “The optimizer 210 can move expressions, including security expressions, within the received query in order to optimize performance. In general, security expressions are tagged in order to discriminate between security expressions and non-security expressions and predicate rules are utilized to define the scope of how to incorporate security expressions within a query. The predicate rules allow the optimizer 210 to pull non-security expressions above security expressions or push non-security expressions below security expressions only after ensuring that unsafe expressions cannot be utilized to return data prior to executing security expressions. Typically, logical operations commonly are deemed "safe," and the optimizer 210 can order such operations above or below security expressions.” The Examiner interprets the security expression moved by the optimizer 210 that corresponds to the SalLimit security expression (salary<X) (the first filter predicate string) as a first query optimizer predicate. Dutta inherently teach converting the first filter predicate string into a first query optimizer predicate because otherwise the security expression moved by the optimizer 210 that corresponds to the SalLimit security expression (salary<X) cannot be obtained by the optimizer 210. The Examiner interprets the optimizer 210 pushing non-security expressions below security expressions taught in col. 9, line 62-col. 10, line 8 as the first filter predicate string is applied to one or more nodes of the query optimizer tree. And see col. 4, lines 28-36: “The security expressions can be variously augmented to a query in order to arrange the predicates of the query to optimize performance and mitigate security leaks. In addition, the security expressions can be aggregated such that satisfying (e.g., returning "true") the aggregate provides access to a row(s) of data, while not satisfying (e.g., returning "false") the aggregate restricts access to a row(s) of data.”);
injecting the first query optimizer predicate into a first query plan (see col. 9, line 62-col. 10, line 8 and Fig. 2: “The optimizer 210 can move expressions, including security expressions, within the received query in order to optimize performance. In general, security expressions are tagged in order to discriminate between security expressions and non-security expressions and predicate rules are utilized to define the scope of how to incorporate security expressions within a query. The predicate rules allow the optimizer 210 to pull non-security expressions above security expressions or push non-security expressions below security expressions only after ensuring that unsafe expressions cannot be utilized to return data prior to executing security expressions. Typically, logical operations commonly are deemed "safe," and the optimizer 210 can order such operations above or below security expressions.” And see col. 6, lines 11-18: “With both static and dynamic analysis, if no safety violations are found, the ordering in which expressions are arranged can be determined by the optimizer 210 to improve performance. However, if a safety violation is detected, the query can be aborted or run in "safe" mode, wherein security expressions are evaluated prior to running non-security expressions. Tagging security predicates specially in the query, allows for such execution plans.” The Examiner interprets the execution plan taught in col. 6, line 18 as a first query plan. Because Dutta discloses the optimizer 210 determining the ordering in which security expressions (the first query optimizer predicate) are arranged relative to non-security expressions in execution plans (a first query plan) in col. 6, lines 11-18, Dutta teaches injecting the first query optimizer predicate into a first query plan).
Both Murthy ([0005]) and Dutta (Col. 4, line 24) teach a row level security policy. Murthy discloses applying filtering to a query result set ([0011]). Dutta teaches the following: “The predicate rules allow the optimizer 210 to … push non-security expressions below security expressions only after ensuring that unsafe expressions cannot be utilized to return data prior to executing security expressions. Typically, logical operations commonly are deemed "safe," and the optimizer 210 can order such operations … below security expressions” (see col. 9, line 62-col. 10, line 8 and Fig. 2). Since both Murthy and Dutta disclose pushing non-security expressions below security expressions, before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to apply the technique of converting the first filter predicate string into a first query optimizer predicate that is inserted into a query optimizer tree such that the first filter predicate string is applied to one or more nodes of the query optimizer tree and injecting the first query optimizer predicate into a first query plan as taught by Dutta, to improve the method of Murthy for the predictable result of finding a query plan with optimal performance and efficiency. When such a modification is made, Murthy modified in view of Dutta would disclose applying the first query optimizer predicate to the first query result set, as recited by claims 1, 11 and 20.
Regarding claims 2 and 12, Murthy further discloses dynamically generating the first filter predicate string by invoking a condition provider procedure (see [0007]: “In an access control rewrite, the query may be rewritten by appending a predicate that invokes an access control function or operator, to determine whether a user may perform a particular operation on a row. The access control function is implemented to determine whether one or more conditions or criteria, referred to herein as access control conditions, are met. If the access control conditions are met, the user has the necessary privilege to perform the required operation on a particular row, and the access control function returns a result indicating so. The following query QB illustrates an access control rewrite and use of an access control function.
TABLE-US-00001 QB
select * from Emp where Salary > 1000;
is implicitly rewritten to
TABLE-US-00002 QB'Func
select * from Emp where Salary > 1000 AND CHECK_ACL(aclid, "read") = 1.” The Examiner interprets the procedure that rewrites the query “select * from Emp where Salary > 1000” into “select * from Emp where Salary > 1000 AND CHECK_ACL(aclid, "read") = 1” as a condition provider procedure.).
Regarding claims 3 and 13, Murthy further teaches wherein applying the first query optimizer predicate to the first query result set comprises creating a second query result set which is a truncated version of the first query result set (see [0011]: “In the current example, for purposes of illustration, table Emp has 1 million rows. The ACLs are set up such that the user issuing query QB has permission to access only 20 rows. There are 100,000 employees matching the Salary predicate, i.e. having Salary>1000 evaluate to true. To compute the query QB'Func, a database system accesses 100,000 rows (perhaps using an index), applies CHECK_ACL function to all of them, but eliminates all but 20 rows from the result.”).
Regarding claim 9, Murthy fails to teach wherein a first row level security protection flag is saved in object metadata associated with the first database object.
In the same field of endeavor, Dutta discloses wherein a first row level security protection flag is saved in object metadata associated with the first database object (see col. 16, lines 17-20: “In order to allow for row level security, the table has to first be marked as such. This can be done using the ROW_SECURITY flag in the CREATE/ALTER TABLE syntax (e.g., ALTER TABLE SET ROW_SECURITY=ON).”).
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to improve Murthy by letting a first row level security protection flag be saved in object metadata associated with the first database object, as taught by Dutta. It would have been obvious because Dutta states the following: “In order to allow for row level security, the table has to first be marked as such. This can be done using the ROW_SECURITY flag” (see col. 16, lines 17-20).
Claims 4, 5, 14 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Murthy (US 2007/0276835), further in view of Dutta (US 7,661,141), and further in view of Avanes (US 2023/0022027).
Regarding claims 4 and 14, Murthy modified in view of Dutta fails to teach wherein the first row level security policy is defined by a first user.
In the same field of endeavor, Avanes discloses that the first row level security policy is defined by a first user (see Abstract: “Row-level security (RLS) may provide fine-grained access control based on flexible, user-defined access policies to databases, tables, objects, and other data structures.” And see [0052]: “one user (e.g., a policy administrator) may define an RLS policy and that same user may attach that RLS policy to one or more tables.”).
Both Avanes and Murthy modified in view of Dutta teach row-level security. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to let the first row level security policy of Murthy modified in view of Dutta be defined by a first user as taught by Avanes. It would have been obvious because doing so predictably achieves the commonly understood benefit of making access policies to databases and tables flexible and user-defined.
Regarding claims 5 and 15, Murthy teaches wherein the second query result set is specific to a second user that caused the first query to be generated (see [0022]: “Column PRIVILEGE contains privilege data, which is data that defines one or more privileges. A privilege is a right or power granted or enjoyed by a principal. Examples of privileges include (1) access privileges, such as a right to read or access records, rows, files, XML documents, or a subset of fields or attributes in multiple tables or objects”).
Claims 6-8, and 16-18 are rejected under 35 U.S.C. 103 as being unpatentable over Murthy (US 2007/0276835), further in view of Dutta (US 7,661,141), and further in view of Official Notice 1.
Regarding claims 6 and 16, Murthy modified in view of Dutta fails to teach detecting creation of a second database object to be protected by a second row level security policy different from the first row level security policy.
The Examiner takes Official Notice 1 that it is a well-known technique to detect creation of a second database object to be protected by a second row level security policy different from the first row level security policy.
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to improve the method of Murthy modified in view of Dutta by adding the step of detecting creation of a second database object to be protected by a second row level security policy different from the first row level security policy taught by Official Notice 1. It would have been obvious because doing so predictably achieves the commonly understood benefit of ensuring the security of the second database object using a fine grained row level security policy.
Regarding claims 7 and 17, Murthy teaches wherein the first row level security policy binds the first database object and a condition provider procedure (emphasis added to show the difference between the reference and the claim) (see [0007]: “In an access control rewrite, the query may be rewritten by appending a predicate that invokes an access control function or operator, to determine whether a user may perform a particular operation on a row. The access control function is implemented to determine whether one or more conditions or criteria, referred to herein as access control conditions, are met. If the access control conditions are met, the user has the necessary privilege to perform the required operation on a particular row, and the access control function returns a result indicating so. The following query QB illustrates an access control rewrite and use of an access control function.
TABLE-US-00001 QB
select * from Emp where Salary > 1000;
is implicitly rewritten to
TABLE-US-00002 QB'Func
select * from Emp where Salary > 1000 AND CHECK_ACL(aclid, "read") = 1.” The Examiner interprets the procedure that rewrites the query “select * from Emp where Salary > 1000” into “select * from Emp where Salary > 1000 AND CHECK_ACL(aclid, "read") = 1” as a condition provider procedure.).
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to substitute the first row level security policy and the first database object of Murthy modified in view of Dutta with the second row level security policy and the second database object of Official Notice 1, respectively. It would have been obvious because doing so predictably achieves the result of ensuring the security of the second database object using a fine grained row level security policy.
Regarding claims 8 and 18, Murthy teaches dynamically generating a first filter predicate string by invoking the condition provider procedure in response to detecting a first query targeting the first database object (emphasis added to show the difference between the reference and the claim) (see [0007]: “In an access control rewrite, the query may be rewritten by appending a predicate that invokes an access control function or operator, to determine whether a user may perform a particular operation on a row. The access control function is implemented to determine whether one or more conditions or criteria, referred to herein as access control conditions, are met. If the access control conditions are met, the user has the necessary privilege to perform the required operation on a particular row, and the access control function returns a result indicating so. The following query QB illustrates an access control rewrite and use of an access control function.
TABLE-US-00001 QB
select * from Emp where Salary > 1000;
is implicitly rewritten to
TABLE-US-00002 QB'Func
select * from Emp where Salary > 1000 AND CHECK_ACL(aclid, "read") = 1.” The Examiner interprets the procedure that rewrites the query “select * from Emp where Salary > 1000” into “select * from Emp where Salary > 1000 AND CHECK_ACL(aclid, "read") = 1” as a condition provider procedure.).
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to substitute the first filter predicate string, the first query and the first database object of Murthy modified in view of Dutta with the second filter predicate string, the second query and the second database object of Official Notice 1, respectively. It would have been obvious because doing so predictably achieves the result of ensuring the security of the second database object using a fine grained row level security policy.
Claims 10 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Murthy (US 2007/0276835), further in view of Dutta (US 7,661,141), and further in view of Official Notice 2.
Regarding claims 10 and 19, Murthy modified in view of Dutta fails to teach detecting a second query; generating the query optimizer tree based on the second query; traversing the query optimizer tree to collect any view nodes that are protected by row level security policies; for each collected view node: retrieving metadata of a corresponding row level security policy for the collected view node; invoking a condition provider procedure to dynamically generate a filter predicate string from a permission table for a current user; converting the filter predicate string to a query optimizer predicate; and injecting the query optimizer predicate into the collected view node in the query optimizer tree.
The Examiner takes Official Notice 2 that it is a well-known technique to detect a second query; to generate a query optimizer tree based on the second query; to traverse the query optimizer tree to collect any view nodes that are protected by row level security policies; for each collected view node: to retrieve metadata of a corresponding row level security policy for the collected view node; to invoke a condition provider procedure to dynamically generate a filter predicate string from a permission table for a current user; to convert the filter predicate string to a query optimizer predicate; and to inject the query optimizer predicate into the collected view node in the query optimizer tree.
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to improve the method of Murthy modified in view of Dutta by adding the steps of detecting a second query; generating the query optimizer tree based on the second query; traversing the query optimizer tree to collect any view nodes that are protected by row level security policies; for each collected view node: retrieving metadata of a corresponding row level security policy for the collected view node; invoking a condition provider procedure to dynamically generate a filter predicate string from a permission table for a current user; converting the filter predicate string to a query optimizer predicate; and injecting the query optimizer predicate into the collected view node in the query optimizer tree, which are taught by Official Notice 2. It would have been obvious because a person of ordinary skill has good reason to pursue the known options within his or her technical grasp.
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 ZHIMEI ZHU whose telephone number is (571)270-7990. The examiner can normally be reached 10am-6pm Monday-Friday.
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, Farid Homayounmehr can be reached at 571-272-3739. 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.
/ZHIMEI ZHU/Examiner, Art Unit 2495