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 .
Remarks
In response to communications sent December 17, 2025, claim(s) 2-7, 11-17, and 21-27 is/are pending in this application; of these claim(s) 2, 12, and 26 is/are in independent form. Claim(s) 8-10 and 18-20 is/are cancelled.
Terminal Disclaimer
The terminal disclaimer filed on December 17, 2025 disclaiming the terminal portion of any patent granted on this application which would extend beyond the expiration date of U.S. Patent No. 11,531,775 has been reviewed and is accepted. The terminal disclaimer has been recorded.
Response to Arguments
Applicant's arguments filed December 17, 2025 have been fully considered but they are not persuasive. The additional elements are mapped as follows: Stillman Col 17 lines 53- Col 18 line 5: multiple recalculations of security labels occur according to key relationships in a relational database and triggers; updated security labels are responsive to a trigger.
Applicant’s arguments, see page 10 line 25 to page 11 line 2, filed December 17, 2025, with respect to the non-statutory double patenting rejection have been fully considered and are persuasive. The rejection of claims 2-21 has been withdrawn.
Claim Analysis - 35 USC § 101
A rejection regarding judicial exceptions to matter eligibility is not made because the claims recite an improvement to the functioning of the computer itself by using security labels to control access to database cells.
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) 2-21 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 7,725,501 B1 (“Stillman”) in view of US 2008/0010233 A1 (“Sack”).
As to claim 2 Stillman teaches a method including:
automatically determining a first component of a security label (Stillman column 16 lines 4-7: determining the “Unclassified” label for the “Programmer” record) for a first record in a table (Stillman, column 16 lines 4-7: row label values for the “Employees” table) of a database having multiple tables (Stillman, Column 15 lines 17-24: databases with multiple tables including “Employees,” “Projects,” and “Assignments”), including:
identifying a component of a security label for a second record (Stillman column 16 lines 11-15: identifying the label “Secret” for the record “Stealth Fighter”) related to the first record according to a first foreign key relationship (Stillman column 16 lines 4-15: performing a join in a relational database involving parent rows and child rows; col 14 lines 8-15 provide evidence that the row-labeling in a relational database, which generally involve foreign key relationships), in which the component of the security label for the second record comprises a value in a field of the second record (Stillman column 16 lines 11-15: the “Secret” label is in a field of the row of the record “Stealth Fighter” is in; see Column 15 lines 33-43); and
assigning a value for the first component of the security label for the first record based on the identified component of the security label for the second record (Stillman Col 16 lines 11-30: combining the “Unclassified” label with the “Secret” label from the record “Stealth Fighter” to create an updated label for the “Programmer” record);
combining the first component of the security label for the first record with a second component of the security label for the first record [[ (Stillman Col 16 lines 11-15: as step, the “Unclassified” label and the “Secret” label are summed into a single security label having both elements);
storing the security label for the first record in one or more fields of the first record (Stillman Col 16 lines 16-17: storing the row label in the record) wherein the security label is for managing access to the data stored in the fields of the first record (this element is an intended result in a method claim and does not have patentable weight as would a positively recited step; see the last sentence of MPEP § 2111.04(I) );
determining that a modification to the first record affects the first foreign key relationship relating the second record to the first record, including determining that the modification to the first record causes the first record to relate to a different record (Stillman Col 17 lines 53- Col 18 line 5: multiple recalculations of security labels occur according to key relationships in a relational database and triggers); and
updating the value for the first component of the security label for the first record based on a component of a security label for the different record (Stillman Col 17 lines 53- Col 18 line 5: updated security labels are responsive to a trigger).
However, Stillman does not teach the full limitation: combining the first component of the security label for the first record with a second component of the security label for the first record into a single element that includes the first component and the second component to form the security label for the first record.
Nevertheless, Sack teaches: combining the first component of the security label for the first record with a second component of the security label for the first record into a single element that includes the first component and the second component to form the security label for the first record (Sack Para [0011]: the values for the individual security labels for the objects are combined according to a union operation according to a form of a merge label that is illustrated in Figure 19 as a concatenation into a derived parent label according to the HIU algorithm).
Sack also teaches the intended use of “wherein the security label is for managing access to the data stored in the fields of the first record” (Sack Para [0008]: receiving a request to allow access to data in a database that is associated with the security label, and the user being associated with another security label of the database session; denying access by the user to a database based on the label of a database object and the security label of the database session).
Stillman and Sack are in the same field of databases. Therefore, 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 Stillman to include the teachings of Sack because Sack teaches the intended use noted above for managing access using concatenated security labels (See Sack Para [0008]).
As to claim 3, Stillman in view of Sack teaches the method of claim 2, including determining the second component of the security label for the first record based on an attribute of the first record (Stillman Col 16 lines 16-30: the “Secret” component of the record is based on relative clearance level attributes and which label is more restrictive).
As to claim 4, Stillman in view of Sack teaches the method of claim 2, including determining the second component of the security label for the first record based on an attribute of the table of the database (Stillman Col 15 lines 17-60: attributes of tables matter because they affect table joins and table-level security levels).
As to claim 5, Stillman in view of Sack teaches the method of claim 2, including determining the second component of the security label for the first record based on a component of a security label for a third record related to the first record by a second foreign key relationship (Stillman Col 15 lines 17-60: three records, “John Smith,” “Stealth Fighter,” and “Programmer” are linked together according to a foreign key relationship).
As to claim 6, Stillman in view of Sack teaches the method of claim 2, in which combining the first component of the security label for the first record with the second component of the security label for the first record includes concatenating the first component of the security label for the first record and the second component of the security label for the first record (Stillman Col 38 lines 9-17 suggest that summing of text are text operations and not numerical operations; a textual sum would be a concatenation).
As to claim 7, Stillman in view of Sack teaches the method of claim 2, including:
identifying a component of a security label for each of multiple second records each related to the first record according to a respective foreign key relationship (Stillman Col 17 lines 53- Col 18 line 5: multiple updates to security labels occur according to key relationships in a relational database); and
assigning the value for the first component of the security label for the first record based on a value for the identified component of the security label for each of the second records (Stillman Col 17 lines 53- Col 18 line 5: assigning the updated security labels to the records).
As to claim 11, Stillman in view of Sack teaches the method of claim 2, including automatically determining the first component of the security label for a particular first record when the first record is received for storage in the database (Stillman Col 16 lines 31-40: insertions trigger updates to security labels).
As to claim 12, Stillman teaches a non-transitory computer readable medium storing instructions for causing one or more processors to perform operations including:
automatically determining a first component of a security label (Stillman column 16 lines 4-7: determining the “Unclassified” label for the “Programmer” record) for a first record in a table (Stillman, column 16 lines 4-7: row label values for the “Employees” table) of a database having multiple tables (Stillman, Column 15 lines 17-24: databases with multiple tables including “Employees,” “Projects,” and “Assignments”), including:
identifying a component of a security label for a second record (Stillman column 16 lines 11-15: identifying the label “Secret” for the record “Stealth Fighter”) related to the first record according to a first foreign key relationship (Stillman column 16 lines 4-15: performing a join in a relational database involving parent rows and child rows; col 14 lines 8-15 provide evidence that the row-labeling in a relational database, which generally involve foreign key relationships), in which the component of the security label for the second record comprises a value in a field of the second record (Stillman column 16 lines 11-15: the “Secret” label is in a field of the row of the record “Stealth Fighter” is in; see Column 15 lines 33-43); and
assigning a value for the first component of the security label for the first record based on the identified component of the security label for the second record (Stillman Col 16 lines 11-30: combining the “Unclassified” label with the “Secret” label from the record “Stealth Fighter” to create an updated label for the “Programmer” record);
combining the first component of the security label for the first record with a second component of the security label for the first record [[ (Stillman Col 16 lines 11-15: as step, the “Unclassified” label and the “Secret” label are summed into a single security label having both elements);
determining that a modification to the first record affects the first foreign key relationship relating the second record to the first record, including determining that the modification to the first record causes the first record to relate to a different record (Stillman Col 17 lines 53- Col 18 line 5: multiple recalculations of security labels occur according to key relationships in a relational database and triggers); and
updating the value for the first component of the security label for the first record based on a component of a security label for the different record (Stillman Col 17 lines 53- Col 18 line 5: updated security labels are responsive to a trigger).
storing the security label for the first record in one or more fields of the first record (Stillman Col 16 lines 16-17: storing the row label in the record) wherein the security label is for managing access to the data stored in the fields of the first record (this element is an intended purpose that does not alter the structure of the non-transitory computer readable medium).
However, Stillman does not teach the full limitation: combining the first component of the security label for the first record with a second component of the security label for the first record into a single element that includes the first component and the second component to form the security label for the first record.
Nevertheless, Sack teaches: combining the first component of the security label for the first record with a second component of the security label for the first record into a single element that includes the first component and the second component to form the security label for the first record (Sack Para [0011]: the values for the individual security labels for the objects are combined according to a union operation according to a form of a merge label that is illustrated in Figure 19 as a concatenation into a derived parent label according to the HIU algorithm).
Sack also teaches the intended purpose of “wherein the security label is for managing access to the data stored in the fields of the first record” (Sack Para [0008]: receiving a request to allow access to data in a database that is associated with the security label, and the user being associated with another security label of the database session; denying access by the user to a database based on the label of a database object and the security label of the database session).
Stillman and Sack are in the same field of databases. Therefore, 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 Stillman to include the teachings of Sack because Sack teaches the intended use noted above for managing access using concatenated security labels (See Sack Para [0008]).
As to claim 13, Stillman in view of Sack teaches the non-transitory computer readable medium of claim 12, in which the operations include determining the second component of the security label for the first record based on an attribute of the first record (Stillman Col 16 lines 16-30: the “Secret” component of the record is based on relative clearance level attributes and which label is more restrictive).
As to claim 14, Stillman in view of Sack teaches the non-transitory computer readable medium of claim 12, in which the operations include determining the second component of the security label for the first record based on an attribute of the table of the database (Stillman Col 15 lines 17-60: attributes of tables matter because they affect table joins and table-level security levels).
As to claim 15, Stillman in view of Sack teaches the non-transitory computer readable medium of claim 12, in which the operations include determining the second component of the security label for the first record based on a component of a security label for a third record related to the first record by a second foreign key relationship (Stillman Col 15 lines 17-60: three records, “John Smith,” “Stealth Fighter,” and “Programmer” are linked together according to a foreign key relationship).
As to claim 16, Stillman in view of Sack teaches the non-transitory computer readable medium of claim 12, in which combining the first component of the security label for the first record with the second component of the security label for the first record includes concatenating the first component of the security label for the first record and the second component of the security label for the first record (Stillman Col 38 lines 9-17 suggest that summing of text are text operations and not numerical operations; a textual sum would be a concatenation).
As to claim 17, Stillman in view of Sack teaches the non-transitory computer readable medium of claim 12, in which the operations include:
identifying a component of a security label for each of multiple second records each related to the first record according to a respective foreign key relationship (Stillman Col 17 lines 53- Col 18 line 5: multiple updates to security labels occur according to key relationships in a relational database); and
assigning the value for the first component of the security label for the first record based on a value for the identified component of the security label for each of the second records (Stillman Col 17 lines 53- Col 18 line 5: assigning the updated security labels to the records).
As to claim 21, Stillman in view of Sack teaches the non-transitory computer readable medium of claim 12, in which the operations include automatically determining the first component of the security label for a particular first record when the first record is received for storage in the database (Stillman Col 16 lines 31-40: insertions trigger updates to security labels).
As to claim 22, Stillman in view of Sack teaches the method of claim 2, including:
determining that the modification to the first record causes one or more downstream records to relate to the first record by respective foreign key relationships (Stillman Col 17 lines 53- Col 18 line 5: multiple updates to security labels occur according to key relationships in a relational database); and
updating a value for a component of a security label for each identified downstream record based on one or both of the first component of the security label for the first record and the second component of the security label for the first record (Stillman Col 17 lines 53- Col 18 line 5: assigning the updated security labels to the records).
As to claim 23, Stillman in view of Sack teaches the method of claim 2, wherein the stored security label is for facilitating an audit of the database (Sack Para [0097]: Fine-Grained Access control for row-level auditing).
As to claim 24, Stillman in view of Sack teaches the non-transitory computer readable medium of claim 12, in which the operations include:
determining that the modification to the first record causes one or more downstream records to relate to the first record by respective foreign key relationships (Stillman Col 17 lines 53- Col 18 line 5: multiple updates to security labels occur according to key relationships in a relational database); and
updating a value for a component of a security label for each of the one or more downstream records based on one or both of the first component of the security label for the first record and the second component of the security label for the first record (Stillman Col 17 lines 53- Col 18 line 5: assigning the updated security labels to the records).
As to claim 25, Stillman in view of Sack teaches the non-transitory computer readable medium of claim 12, wherein the stored security label is for facilitating an audit of the database (Sack Para [0097]: Fine-Grained Access control for row-level auditing).
As to claim 26, Stillman teaches a computing system including one or more processors coupled to a memory, the one or more processors and memory configured to perform operations including:
automatically determining a first component of a security label (Stillman column 16 lines 4-7: determining the “Unclassified” label for the “Programmer” record) for a first record in a table (Stillman, column 16 lines 4-7: row label values for the “Employees” table) of a database having multiple tables (Stillman, Column 15 lines 17-24: databases with multiple tables including “Employees,” “Projects,” and “Assignments”), including:
identifying a component of a security label for a second record (Stillman column 16 lines 11-15: identifying the label “Secret” for the record “Stealth Fighter”) related to the first record according to a first foreign key relationship (Stillman column 16 lines 4-15: performing a join in a relational database involving parent rows and child rows; col 14 lines 8-15 provide evidence that the row-labeling in a relational database, which generally involve foreign key relationships), in which the component of the security label for the second record comprises a value in a field of the second record (Stillman column 16 lines 11-15: the “Secret” label is in a field of the row of the record “Stealth Fighter” is in; see Column 15 lines 33-43); and
assigning a value for the first component of the security label for the first record based on the identified component of the security label for the second record (Stillman Col 16 lines 11-30: combining the “Unclassified” label with the “Secret” label from the record “Stealth Fighter” to create an updated label for the “Programmer” record);
combining the first component of the security label for the first record with a second component of the security label for the first record [[ (Stillman Col 16 lines 11-15: as step, the “Unclassified” label and the “Secret” label are summed into a single security label having both elements);
storing the security label for the first record in one or more fields of the first record (Stillman Col 16 lines 16-17: storing the row label in the record), wherein the security label is for managing access to the data stored in the fields of the first record (this element is an intended result in a method claim and does not have patentable weight as would a positively recited step; see the last sentence of MPEP § 2111.04(I) );
determining that a modification to the first record affects the first foreign key relationship relating the second record to the first record, including determining that the modification to the first record causes the first record to relate to a different record (Stillman Col 17 lines 53- Col 18 line 5: multiple recalculations of security labels occur according to key relationships in a relational database and triggers); and
updating the value for the first component of the security label for the first record based on a component of a security label for the different record (Stillman Col 17 lines 53- Col 18 line 5: updated security labels are responsive to a trigger).
However, Stillman does not teach the full limitation: combining the first component of the security label for the first record with a second component of the security label for the first record into a single element that includes the first component and the second component to form the security label for the first record.
Nevertheless, Sack teaches: combining the first component of the security label for the first record with a second component of the security label for the first record into a single element that includes the first component and the second component to form the security label for the first record (Sack Para [0011]: the values for the individual security labels for the objects are combined according to a union operation according to a form of a merge label that is illustrated in Figure 19 as a concatenation into a derived parent label according to the HIU algorithm).
Sack also teaches the intended use of “wherein the security label is for managing access to the data stored in the fields of the first record” (Sack Para [0008]: receiving a request to allow access to data in a database that is associated with the security label, and the user being associated with another security label of the database session; denying access by the user to a database based on the label of a database object and the security label of the database session).
Stillman and Sack are in the same field of databases. Therefore, 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 Stillman to include the teachings of Sack because Sack teaches the intended use noted above for managing access using concatenated security labels (See Sack Para [0008]).
As to claim 27, Stillman in view of Sack teaches the computing system of claim 26, in which the operations include:
determining that the modification to the first record causes one or more downstream records to relate to the first record by respective foreign key relationships (Stillman Col 17 lines 53- Col 18 line 5: multiple updates to security labels occur according to key relationships in a relational database); and
updating a value for a component of a security label for each identified downstream record based on one or both of the first component of the security label for the first record and the second component of the security label for the first record (Stillman Col 17 lines 53- Col 18 line 5: assigning the updated security labels to the records).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US-20100180339-A1 pertinence: concatenated security tokens
US-7127448-B1 pertinence: audits regarding row access in a relational database
US-20030191768-A1 pertinence: access control table
US-6757680-B1 pertinence: inheriting access control rules
US-20090050695-A1 pertinence: element 200 is a security label that is concatenated
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 Jesse P Frumkin whose telephone number is (571)270-1849. The examiner can normally be reached Monday - Saturday, 10-5 ET.
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, Olivia Wise can be reached at (571) 272-2249. 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.
/JESSE P FRUMKIN/Primary Examiner, Art Unit 1685 February 10, 2026