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 .
This office action is in response to the claimed amendment filed on April 07, 2026, in which claims 1-17 are presented further examination.
Response to Arguments
Applicant’s arguments filed on April 07, 2026, with respect to claims 1-17 have been fully considered and are persuasive. The 35 USC 102 rejection set forth in the last office action has been withdrawn.
Applicant’s arguments with respect to claims 1-17 have been considered but are moot in view of a new ground of rejection necessitated by amendment.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 13 recites the limitation "said query" and “the query”. There is insufficient antecedent basis for this limitation in the claim.
Claims 14-17 are also rejected for incorporating the deficiency of their respective base claim by dependency.
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-17 are rejected under 35 U.S.C. 103 as being unpatentable over Henein US 2019/0188409 in view Banks et al., (hereinafter “Banks”) US 20080033960 A1.
As to claim 1, Henein discloses a data management system including:
a processor, said processor coupled to a network a processor, said processor coupled to a network (see [0042], computer 402 includes a processor 405. Although illustrated as a single processor 405 in FIG. 4, two or more processors may be used according to particular needs, configurations, or particular implementations of the computer 402. Generally, the processor 405 executes instructions and manipulates data to perform the operations of the computer 402. In some cases, the processor 405 can include a data processing apparatus, wherein par. [0037], computer 402 can serve as a client, network component, a server, a database or other persistency, and/or any other component of the system 400. In some implementations, one or more components of the computer 402 may be configured to operate within a cloud-computing-based environment);
a data store coupled to the processor, said data store including a plurality of personally identifiable data fields (see par [0020], the data record is divided into multiple data entries. Each data entry includes a respective portion of the PII. For example, the data record can include the first name, the last name, the SSN, the phone number, the home address, and the email address of the person. The PII can be divided into multiple data entries: the first data entry includes the first name of the person, the second data entry includes the last name of the person, the third data entry includes the SSN of the person, the fourth, the fifth, and the sixth data entries include the phone number, the home address, and the email address of the person, respectively);
a memory device coupled to the processor, said memory device encoded with non-transitory processor-readable instructions directing the processor to perform a method including (see par. [0046], in tangibly embodied computer software or firmware, in computer hardware, including the structures disclosed in this specification and their structural equivalents, or in combinations of one or more of them. Implementations of the subject matter described in this specification can be implemented as one or more computer programs, i.e., one or more modules of computer program instructions encoded on a tangible, non-transitory computer-storage medium for execution by, or to control the operation of, data processing apparatus. Alternatively or in addition, the program instructions can be encoded on an artificially generated propagated signal, e.g., a machine-generated electrical, optical, or electromagnetic signal that is generated to encode information for transmission to suitable receiver apparatus for execution by a data processing apparatus. The computer-storage medium can be a machine-readable storage device, a machine-readable storage substrate, a random or serial access memory device, or a combination of one or more of them);
receiving a command (see pars. [0014] and [0019], where a data record including PII for a person is received. The data record can be received by user inputs from a terminal, for example, in a data entry operation. The data record can also be received from a file, for example, by parsing an input file that includes PII for many people. The data record can also be received over a wireline or a wireless network. In some cases, the data record can be received in a request to store the PII, or overwrite the existing PII for the person) (Note, "extension instruction" is simply a task, program, or additional commands in a computer's instruction set, Henein discloses “or interface function” as an extension instruction, wherein [0039], the computer 402 can receive requests over network 450 from a client application (e.g., executing on another computer 402) and respond to the received requests by processing the said requests in an appropriate software application. In addition, requests may also be sent to the computer 402 from internal users (e.g., from a command console or by another appropriate access method), external or third parties, other automated applications, as well as any other appropriate entities, individuals, systems, or computers); and
returning a result in response to the extension instruction, wherein the result includes an indica of operations on the PII in response to the extension instruction (see par. [0014], represents an application, a set of applications, software, software modules, hardware, or any combination thereof that can be configured to receive and respond to database queries. For example, the interface function 110 can receive a request to read, write, or delete the PII of a person. The interface function 110 can send the request to the DML 120, receive PII from the DML 120, and send the PII to the entity that sends the request), and (par. [0021], for each data entry, a database location is selected to store the respective portion of the PII. In some implementations, the database can be organized into multiple tables, each tables can have multiple cells that are organized in a row-by-column structure. Each database location can be a cell in the table. FIG. 5 illustrates the structure of an example database 500, according to an implementation. As illustrated, the database 500 includes tables 510 and 520. Each table includes multiple rows and columns. In some cases, a table ID can be assigned to each table, a row ID can be assigned to each row, and a column ID can be assigned to each column. Thus, each database location (cell) can be addressed by the combination of table ID, row ID, and column ID. In the illustrated example, cell 512, the database location storing the data “John,” can be addressed by “table ID=510, row ID=1001, column ID=2001.” Cell 522, the database location storing the data “first street,” can be addressed by “table ID=520, row ID=1001, column ID=2001.” The database 500 can have more than two tables and each table can have more rows and columns than illustrated, wherein [0039], the computer 402 can receive requests over network 450 from a client application (e.g., executing on another computer 402) and respond to the received requests by processing the said requests in an appropriate software application. In addition, requests may also be sent to the computer 402 from internal users (e.g., from a command console or by another appropriate access method), external or third parties, other automated applications, as well as any other appropriate entities, individuals, systems, or computers).
However, Henein does not explicitly disclose the claimed “said command including at least one privacy enhancing extension instruction, said at least one privacy enhancing extension instruction operative to operate exclusively on PII”.
On the other hand, Banks discloses the claimed “said command including at least one privacy enhancing extension instruction, said at least one privacy enhancing extension instruction operative to operate exclusively on PII” (see [0020], providing automated encryption support for column data is described that comprises: a parser that supports Structured Query Language (SQL) extensions for creating and managing column encryption keys, and for creating and managing database tables with encrypted column data; and an execution unit, operating in response to SQL statements parsed by the parser, for creating a particular column encryption key, for creating a database table having particular column data encrypted with the particular column encryption key, for specifying a default value to be provided in response to requests for the particular column data from a user without decryption permission; and for automatically decrypting the particular column data for use by a subsequent database operation that requests the particular column data that has been encrypted from a user with decrypt permission on the particular column data, and which provides the default value in response to a subsequent database operation requesting the particular column data from a user without decrypt permission;
[0081] SQL statements or simply "queries" must be parsed to determine an access plan (also known as "execution plan" or "query plan") to satisfy a given query. In operation, the SQL statements received from the client(s) 310 (via network 320) are processed by the engine 360 of the database server system 340. The engine 360 itself comprises a parser 361, a normalizer 363, a compiler 365, an execution unit 369, and an access methods 370. Specifically, the SQL statements are passed to the parser 361 which converts the statements into a query tree--a binary tree data structure which represents the components of the query in a format selected for the convenience of the system. In this regard, the parser 361 employs conventional parsing methodology (e.g., recursive descent parsing);
[0103] FIG. 3B is a block diagram showing specific enhancements to the system of FIG. 3A for providing automated encryption and decryption of column data through SQL Extensions. In the currently preferred embodiment, the encryption functionality is implemented by incorporating the following additions. The parser 361 is modified in order to understand the extensions (so that the new syntax is correctly understood), as represented by SQL Extensions 381. The protection module (not separately shown) is also modified to optionally remove from the PCR list the IPCR that forces DECRYPT permission checks during execution and to instead build the decrypt permission checking into an instruction in the query plan. The protection module adds the PCR list during normalization of the query;
[0243] FIGS. 6A-C are high-level flowcharts illustrating the method steps of the present invention that pertain to inserting data in a table having encrypted columns. At the outset, the insert query tree created by the parser is given to the normalizer. As illustrated by FIG. 6A, the normalizer proceeds as follows. At step 601, the parser receives an INSERT statement from the user and creates an INSERT query tree. At step 602, the normalizer walks the query tree and uses syscolumns to set up bits for the values for the columns which are encrypted. Encrypted columns are normalized using their external types. At step 603, the normalizer traverses the tree, looking for the encryption bit and gets the keyid and keydbid for the column from syscolumns. For encrypted columns, the normalizer adds an encrypt built-in node above the value. Now, at step 604, a tree-based structure is filled with key information from sysencryptkeys. This internal structure is used later for compilation of the query execution plan).
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Henein to include at least one privacy enhancing extension instruction, said at least one privacy enhancing extension instruction operative to operate exclusively on PII, in order to provide encryption support in an automated manner without requiring changes to applications, thereby providing protection of data privacy from a power of a system administrator or database application.
As to claim 2, the combination of Henein and Banks discloses the invention as claimed. In addition, Henein discloses the claimed wherein the PH is sundered data stored separately from the data store (see par. [0021], for each data entry, a database location is selected to store the respective portion of the PII. In some implementations, the database can be organized into multiple tables, each tables can have multiple cells that are organized in a row-by-column structure. Each database location can be a cell in the table. FIG. 5 illustrates the structure of an example database 500, according to an implementation. As illustrated, the database 500 includes tables 510 and 520. Each table includes multiple rows and columns. In some cases, a table ID can be assigned to each table, a row ID can be assigned to each row, and a column ID can be assigned to each column. Thus, each database location (cell) can be addressed by the combination of table ID, row ID, and column ID. In the illustrated example, cell 512, the database location storing the data “John,” can be addressed by “table ID=510, row ID=1001, column ID=2001.” Cell 522, the database location storing the data “first street,” can be addressed by “table ID=520, row ID=1001, column ID=2001.” The database 500 can have more than two tables and each table can have more rows and columns than illustrated).
As to claim 3, the combination of Henein and Banks discloses the invention as claimed. In addition, Henein discloses the claimed wherein each data field is associated with a property directing operations on the PII (see [0022], break the linkage between different portions of PII for the same person, database cells in different database tables, different database rows, different database columns, or a combination thereof, are selected for each data entry. For example, the data record includes PII for a person named “John Deer” that lives at “123 second street.” The data record is divided into four data entries, each holding a portion of the PII. The first data entry includes the first name “John,” the second data entry includes the last name “Deer,” the third data entry includes the street number “123,” and the fourth data entry includes the street name “second street.” Cells in different tables and different rows are selected to store these data entries. As illustrated, the first name and the last name are stored in different rows. The street number and the street name are stored in different rows. The name (first or last name) and the address (number or name) are stored in different tables. In some implementations, these four entries can be stored in four different tables and in four different rows so that their linkages are further severed. While the columns are maintained in a readable fashion, for example, column 2001 of the table 510 stores first names, column 2002 of the table 510 stores last names, each row of information does not correspond to the same person and therefore the information in the tables is no longer identifiable. In some implementations, the linkage between the columns can be further broken. For example, both the cell 512 and the cell 522 can be used to store first names. In some implementations, the rows and columns can be interchanged. For example, row 1001 of the table 510 can store first names, row 1002 can store last names).
As to claim 4, the combination of Henein and Banks discloses the invention as claimed. In addition, Henein discloses the claimed wherein the property directing operations on PII includes an operation to redact of portion of the PII from the data store and store that portion external to the data store (see [0022], break the linkage between different portions of PII for the same person, database cells in different database tables, different database rows, different database columns, or a combination thereof, are selected for each data entry. For example, the data record includes PII for a person named “John Deer” that lives at “123 second street.” The data record is divided into four data entries, each holding a portion of the PII. The first data entry includes the first name “John,” the second data entry includes the last name “Deer,” the third data entry includes the street number “123,” and the fourth data entry includes the street name “second street.” Cells in different tables and different rows are selected to store these data entries. As illustrated, the first name and the last name are stored in different rows. The street number and the street name are stored in different rows. The name (first or last name) and the address (number or name) are stored in different tables. In some implementations, these four entries can be stored in four different tables and in four different rows so that their linkages are further severed. While the columns are maintained in a readable fashion, for example, column 2001 of the table 510 stores first names, column 2002 of the table 510 stores last names, each row of information does not correspond to the same person and therefore the information in the tables is no longer identifiable. In some implementations, the linkage between the columns can be further broken. For example, both the cell 512 and the cell 522 can be used to store first names. In some implementations, the rows and columns can be interchanged. For example, row 1001 of the table 510 can store first names, row 1002 can store last names).
As to claim 5, the combination of Henein and Banks discloses the invention as claimed. In addition, Henein discloses the claimed wherein the redacted data is obfuscated by sundering actual data and replacing the actual data with false, but realistic looking information (see par. [0025], a cell bag can be maintained. The cell bag can include the cells that have not been assigned to store any data entries. Each cell can be identified by its table ID, row ID, and column ID. If the request is to write PII for a new person, during the selection process, the hashing functions can be configured to output the unassigned cells in the cell bag. Once a cell is assigned, the cell is removed from the cell bag. If a request is received to delete a data record, the cells for data entries of the data record are deposited into the cell bag. The content of the database cells to be deleted can be discarded or kept).
As to claim 6, Henein discloses a data management system including:
a processor, said processor coupled to a network (see [0042], computer 402 includes a processor 405. Although illustrated as a single processor 405 in FIG. 4, two or more processors may be used according to particular needs, configurations, or particular implementations of the computer 402. Generally, the processor 405 executes instructions and manipulates data to perform the operations of the computer 402. In some cases, the processor 405 can include a data processing apparatus, wherein par. [0037], computer 402 can serve as a client, network component, a server, a database or other persistency, and/or any other component of the system 400. In some implementations, one or more components of the computer 402 may be configured to operate within a cloud-computing-based environment);
a data store coupled to the processor, said data store including a plurality of data fields (see par [0020], the data record is divided into multiple data entries. Each data entry includes a respective portion of the PII. For example, the data record can include the first name, the last name, the SSN, the phone number, the home address, and the email address of the person. The PII can be divided into multiple data entries: the first data entry includes the first name of the person, the second data entry includes the last name of the person, the third data entry includes the SSN of the person, the fourth, the fifth, and the sixth data entries include the phone number, the home address, and the email address of the person, respectively);
a memory device coupled to the processor, said memory device encoded with non-transitory processor-readable instructions directing the processor to perform a method including (see par. [0046], in tangibly embodied computer software or firmware, in computer hardware, including the structures disclosed in this specification and their structural equivalents, or in combinations of one or more of them. Implementations of the subject matter described in this specification can be implemented as one or more computer programs, i.e., one or more modules of computer program instructions encoded on a tangible, non-transitory computer-storage medium for execution by, or to control the operation of, data processing apparatus. Alternatively or in addition, the program instructions can be encoded on an artificially generated propagated signal, e.g., a machine-generated electrical, optical, or electromagnetic signal that is generated to encode information for transmission to suitable receiver apparatus for execution by a data processing apparatus. The computer-storage medium can be a machine-readable storage device, a machine-readable storage substrate, a random or serial access memory device, or a combination of one or more of them);
receiving, over the network, a command (see pars. [0014] and [0019], where a data record including PII for a person is received. The data record can be received by user inputs from a terminal, for example, in a data entry operation. The data record can also be received from a file, for example, by parsing an input file that includes PII for many people. The data record can also be received over a wireline or a wireless network. In some cases, the data record can be received in a request to store the PII, or overwrite the existing PII for the person) (Note, "extension instruction" is simply a task, program, or additional commands in a computer's instruction set, Henein discloses “or interface function” as an extension instruction);
receiving a parameter, said parameter indicative of operations on PII (see pars. [0014] and [0019], where a data record including PII for a person is received. The data record can be received by user inputs from a terminal, for example, in a data entry operation. The data record can also be received from a file, for example, by parsing an input file that includes PII for many people. The data record can also be received over a wireline or a wireless network. In some cases, the data record can be received in a request to store the PII, or overwrite the existing PII for the person) (Note, "extension instruction" is simply a task, program, or additional commands in a computer's instruction set, Henein discloses “or interface function” as an extension instruction, wherein [0039], the computer 402 can receive requests over network 450 from a client application (e.g., executing on another computer 402) and respond to the received requests by processing the said requests in an appropriate software application. In addition, requests may also be sent to the computer 402 from internal users (e.g., from a command console or by another appropriate access method), external or third parties, other automated applications, as well as any other appropriate entities, individuals, systems, or computers), and
returning a result, wherein the result includes PII in response to the parameter (see par. [0014], represents an application, a set of applications, software, software modules, hardware, or any combination thereof that can be configured to receive and respond to database queries. For example, the interface function 110 can receive a request to read, write, or delete the PII of a person. The interface function 110 can send the request to the DML 120, receive PII from the DML 120, and send the PII to the entity that sends the request), and (par. [0021], for each data entry, a database location is selected to store the respective portion of the PII. In some implementations, the database can be organized into multiple tables, each tables can have multiple cells that are organized in a row-by-column structure. Each database location can be a cell in the table. FIG. 5 illustrates the structure of an example database 500, according to an implementation. As illustrated, the database 500 includes tables 510 and 520. Each table includes multiple rows and columns. In some cases, a table ID can be assigned to each table, a row ID can be assigned to each row, and a column ID can be assigned to each column. Thus, each database location (cell) can be addressed by the combination of table ID, row ID, and column ID. In the illustrated example, cell 512, the database location storing the data “John,” can be addressed by “table ID=510, row ID=1001, column ID=2001.” Cell 522, the database location storing the data “first street,” can be addressed by “table ID=520, row ID=1001, column ID=2001.” The database 500 can have more than two tables and each table can have more rows and columns than illustrated, wherein [0039], the computer 402 can receive requests over network 450 from a client application (e.g., executing on another computer 402) and respond to the received requests by processing the said requests in an appropriate software application. In addition, requests may also be sent to the computer 402 from internal users (e.g., from a command console or by another appropriate access method), external or third parties, other automated applications, as well as any other appropriate entities, individuals, systems, or computers).
However, Henein does not explicitly disclose the claimed “said command including at least one extension instruction, said at least one extension instruction operative to operate on personal identifiable data (PII)”.
On the other hand, Banks discloses the claimed “said command including at least one extension instruction, said at least one extension instruction operative to operate on personal identifiable data (PII)” (see [0020], providing automated encryption support for column data is described that comprises: a parser that supports Structured Query Language (SQL) extensions for creating and managing column encryption keys, and for creating and managing database tables with encrypted column data; and an execution unit, operating in response to SQL statements parsed by the parser, for creating a particular column encryption key, for creating a database table having particular column data encrypted with the particular column encryption key, for specifying a default value to be provided in response to requests for the particular column data from a user without decryption permission; and for automatically decrypting the particular column data for use by a subsequent database operation that requests the particular column data that has been encrypted from a user with decrypt permission on the particular column data, and which provides the default value in response to a subsequent database operation requesting the particular column data from a user without decrypt permission;
[0081] SQL statements or simply "queries" must be parsed to determine an access plan (also known as "execution plan" or "query plan") to satisfy a given query. In operation, the SQL statements received from the client(s) 310 (via network 320) are processed by the engine 360 of the database server system 340. The engine 360 itself comprises a parser 361, a normalizer 363, a compiler 365, an execution unit 369, and an access methods 370. Specifically, the SQL statements are passed to the parser 361 which converts the statements into a query tree--a binary tree data structure which represents the components of the query in a format selected for the convenience of the system. In this regard, the parser 361 employs conventional parsing methodology (e.g., recursive descent parsing);
[0103] FIG. 3B is a block diagram showing specific enhancements to the system of FIG. 3A for providing automated encryption and decryption of column data through SQL Extensions. In the currently preferred embodiment, the encryption functionality is implemented by incorporating the following additions. The parser 361 is modified in order to understand the extensions (so that the new syntax is correctly understood), as represented by SQL Extensions 381. The protection module (not separately shown) is also modified to optionally remove from the PCR list the IPCR that forces DECRYPT permission checks during execution and to instead build the decrypt permission checking into an instruction in the query plan. The protection module adds the PCR list during normalization of the query;
[0243] FIGS. 6A-C are high-level flowcharts illustrating the method steps of the present invention that pertain to inserting data in a table having encrypted columns. At the outset, the insert query tree created by the parser is given to the normalizer. As illustrated by FIG. 6A, the normalizer proceeds as follows. At step 601, the parser receives an INSERT statement from the user and creates an INSERT query tree. At step 602, the normalizer walks the query tree and uses syscolumns to set up bits for the values for the columns which are encrypted. Encrypted columns are normalized using their external types. At step 603, the normalizer traverses the tree, looking for the encryption bit and gets the keyid and keydbid for the column from syscolumns. For encrypted columns, the normalizer adds an encrypt built-in node above the value. Now, at step 604, a tree-based structure is filled with key information from sysencryptkeys. This internal structure is used later for compilation of the query execution plan).
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Henein to include at least one privacy enhancing extension instruction, said at least one privacy enhancing extension instruction operative to operate exclusively on PII, in order to provide encryption support in an automated manner without requiring changes to applications, thereby providing protection of data privacy from a power of a system administrator or database application.
As to claim 7, the combination of Henein and Banks discloses the invention as claimed. In addition, Henein discloses the claimed wherein the PII is sundered data (see par. [0019], a data record including PII for a person is received. The data record can be received by user inputs from a terminal, for example, in a data entry operation. The data record can also be received from a file, for example, by parsing an input file that includes PII for many people. The data record can also be received over a wireline or a wireless network. In some cases, the data record can be received in a request to store the PII, or overwrite the existing PII for the person, wherein [0020], the data record is divided into multiple data entries. Each data entry includes a respective portion of the PII. For example, the data record can include the first name, the last name, the SSN, the phone number, the home address, and the email address of the person. The PII can be divided into multiple data entries: the first data entry includes the first name of the person, the second data entry includes the last name of the person, the third data entry includes the SSN of the person, the fourth, the fifth, and the sixth data entries include the phone number, the home address, and the email address of the person, respectively).
As to claim 8, the combination of Henein and Banks discloses the invention as claimed. In addition, Henein discloses the claimed wherein sundered PII data is stored separately from the data store (see [0021], for each data entry, a database location is selected to store the respective portion of the PII. In some implementations, the database can be organized into multiple tables, each tables can have multiple cells that are organized in a row-by-column structure. Each database location can be a cell in the table. FIG. 5 illustrates the structure of an example database 500, according to an implementation. As illustrated, the database 500 includes tables 510 and 520. Each table includes multiple rows and columns. In some cases, a table ID can be assigned to each table, a row ID can be assigned to each row, and a column ID can be assigned to each column. Thus, each database location (cell) can be addressed by the combination of table ID, row ID, and column ID. In the illustrated example, cell 512, the database location storing the data “John,” can be addressed by “table ID=510, row ID=1001, column ID=2001.” Cell 522, the database location storing the data “first street,” can be addressed by “table ID=520, row ID=1001, column ID=2001.” The database 500 can have more than two tables and each table can have more rows and columns than illustrated).
As to claim 9, the combination of Henein and Banks discloses the invention as claimed. In addition, Henein discloses the claimed wherein each data field is associated with a property directing operations on PII (see par. [021], for each data entry, a database location is selected to store the respective portion of the PII. In some implementations, the database can be organized into multiple tables, each tables can have multiple cells that are organized in a row-by-column structure. Each database location can be a cell in the table. FIG. 5 illustrates the structure of an example database 500, according to an implementation. As illustrated, the database 500 includes tables 510 and 520. Each table includes multiple rows and columns. In some cases, a table ID can be assigned to each table, a row ID can be assigned to each row, and a column ID can be assigned to each column. Thus, each database location (cell) can be addressed by the combination of table ID, row ID, and column ID. In the illustrated example, cell 512, the database location storing the data “John,” can be addressed by “table ID=510, row ID=1001, column ID=2001.” Cell 522, the database location storing the data “first street,” can be addressed by “table ID=520, row ID=1001, column ID=2001.” The database 500 can have more than two tables and each table can have more rows and columns than illustrated).
As to claim 10, the combination of Henein and Banks discloses the invention as claimed. In addition, Henein discloses the claimed wherein the property directing operations on PII includes an operation to redact the data from the data store and store it external to the data store (see [0019], data record can also be received from a file, for example, by parsing an input file that includes PII for many people. The data record can also be received over a wireline or a wireless network. In some cases, the data record can be received in a request to store the PII, or overwrite the existing PII for the person).
As to claim 11, the combination of Henein and Banks discloses the invention as claimed. In addition, Henein discloses the claimed wherein the property directing operations on PII includes an operation to conditionally retrieve the data from the data store in response to a user authorization (see par. [0023], the selection can be performed based on a user ID associated with the data record. Each data record for a person can be assigned with a user ID. In one example, the user ID can be a random number that is generated using a pseudo-random number generator. Alternatively or in combination, the user ID can be generated based on one or more portion of the PII in the data record, for example, the SSN, the birthday, the name, or a combination thereof. In one example, the user ID can be generated by adding, appending, or otherwise combining the SSN and birthday. In another example, the user ID can be generated by converting letters in the name into hexadecimal numbers. In some cases, for example if the user ID is generated randomly, an association between the user ID and some information of the PII, e.g., name, SSN, or birthday, can be stored in a table at the DML 120.)
As to claim 12, the combination of Henein and Banks discloses the invention as claimed. In addition, Henein discloses the claimed wherein the parameter includes either a directive to redact PII or a directive to retrieve is conditionally (see par. [0019], data record can also be received from a file, for example, by parsing an input file that includes PII for many people. The data record can also be received over a wireline or a wireless network. In some cases, the data record can be received in a request to store the PII, or overwrite the existing PII for the person or see par. [0023], the selection can be performed based on a user ID associated with the data record. Each data record for a person can be assigned with a user ID. In one example, the user ID can be a random number that is generated using a pseudo-random number generator. Alternatively or in combination, the user ID can be generated based on one or more portion of the PII in the data record, for example, the SSN, the birthday, the name, or a combination thereof. In one example, the user ID can be generated by adding, appending, or otherwise combining the SSN and birthday. In another example, the user ID can be generated by converting letters in the name into hexadecimal numbers. In some cases, for example if the user ID is generated randomly, an association between the user ID and some information of the PII, e.g., name, SSN, or birthday, can be stored in a table at the DML 120.)
As to claim 13, Henein discloses a method for data security in a database system including:
defining a plurality of query language extensions for creating and managing personal identifiable information (PII) sundering (see [0020], the data record is divided into multiple data entries. Each data entry includes a respective portion of the PII. For example, the data record can include the first name, the last name, the SSN, the phone number, the home address, and the email address of the person. The PII can be divided into multiple data entries: the first data entry includes the first name of the person, the second data entry includes the last name of the person, the third data entry includes the SSN of the person, the fourth, the fifth, and the sixth data entries include the phone number, the home address, and the email address of the person, respectively);
receiving a query including at least one of said query language extensions; parsing the query language extension to determine an operation associated with PII (see pars. [0014] and [0019], where a data record including PII for a person is received. The data record can be received by user inputs from a terminal, for example, in a data entry operation. The data record can also be received from a file, for example, by parsing an input file that includes PII for many people. The data record can also be received over a wireline or a wireless network. In some cases, the data record can be received in a request to store the PII, or overwrite the existing PII for the person) (Note, "extension instruction" is simply a task, program, or additional commands in a computer's instruction set, Henein discloses “or interface function” as an extension instruction, wherein [0039], the computer 402 can receive requests over network 450 from a client application (e.g., executing on another computer 402) and respond to the received requests by processing the said requests in an appropriate software application. In addition, requests may also be sent to the computer 402 from internal users (e.g., from a command console or by another appropriate access method), external or third parties, other automated applications, as well as any other appropriate entities, individuals, systems, or computers);
executing the operation, and returning an indicia of the operation result (see par. [0014], represents an application, a set of applications, software, software modules, hardware, or any combination thereof that can be configured to receive and respond to database queries. For example, the interface function 110 can receive a request to read, write, or delete the PII of a person. The interface function 110 can send the request to the DML 120, receive PII from the DML 120, and send the PII to the entity that sends the request), and (par. [0021], for each data entry, a database location is selected to store the respective portion of the PII. In some implementations, the database can be organized into multiple tables, each tables can have multiple cells that are organized in a row-by-column structure. Each database location can be a cell in the table. FIG. 5 illustrates the structure of an example database 500, according to an implementation. As illustrated, the database 500 includes tables 510 and 520. Each table includes multiple rows and columns. In some cases, a table ID can be assigned to each table, a row ID can be assigned to each row, and a column ID can be assigned to each column. Thus, each database location (cell) can be addressed by the combination of table ID, row ID, and column ID. In the illustrated example, cell 512, the database location storing the data “John,” can be addressed by “table ID=510, row ID=1001, column ID=2001.” Cell 522, the database location storing the data “first street,” can be addressed by “table ID=520, row ID=1001, column ID=2001.” The database 500 can have more than two tables and each table can have more rows and columns than illustrated, wherein [0039], the computer 402 can receive requests over network 450 from a client application (e.g., executing on another computer 402) and respond to the received requests by processing the said requests in an appropriate software application. In addition, requests may also be sent to the computer 402 from internal users (e.g., from a command console or by another appropriate access method), external or third parties, other automated applications, as well as any other appropriate entities, individuals, systems, or computers).
However, Henein does not explicitly disclose the claimed “receiving a command including at least one of said query language extensions; parsing the query language extension to determine an operation associated with PII”.
On the other hand, Banks discloses the claimed “receiving a command including at least one of said query language extensions; parsing the query language extension to determine an operation associated with PII” (see [0020], providing automated encryption support for column data is described that comprises: a parser that supports Structured Query Language (SQL) extensions for creating and managing column encryption keys, and for creating and managing database tables with encrypted column data; and an execution unit, operating in response to SQL statements parsed by the parser, for creating a particular column encryption key, for creating a database table having particular column data encrypted with the particular column encryption key, for specifying a default value to be provided in response to requests for the particular column data from a user without decryption permission; and for automatically decrypting the particular column data for use by a subsequent database operation that requests the particular column data that has been encrypted from a user with decrypt permission on the particular column data, and which provides the default value in response to a subsequent database operation requesting the particular column data from a user without decrypt permission;
[0081] SQL statements or simply "queries" must be parsed to determine an access plan (also known as "execution plan" or "query plan") to satisfy a given query. In operation, the SQL statements received from the client(s) 310 (via network 320) are processed by the engine 360 of the database server system 340. The engine 360 itself comprises a parser 361, a normalizer 363, a compiler 365, an execution unit 369, and an access methods 370. Specifically, the SQL statements are passed to the parser 361 which converts the statements into a query tree--a binary tree data structure which represents the components of the query in a format selected for the convenience of the system. In this regard, the parser 361 employs conventional parsing methodology (e.g., recursive descent parsing);
[0103] FIG. 3B is a block diagram showing specific enhancements to the system of FIG. 3A for providing automated encryption and decryption of column data through SQL Extensions. In the currently preferred embodiment, the encryption functionality is implemented by incorporating the following additions. The parser 361 is modified in order to understand the extensions (so that the new syntax is correctly understood), as represented by SQL Extensions 381. The protection module (not separately shown) is also modified to optionally remove from the PCR list the IPCR that forces DECRYPT permission checks during execution and to instead build the decrypt permission checking into an instruction in the query plan. The protection module adds the PCR list during normalization of the query;
[0243] FIGS. 6A-C are high-level flowcharts illustrating the method steps of the present invention that pertain to inserting data in a table having encrypted columns. At the outset, the insert query tree created by the parser is given to the normalizer. As illustrated by FIG. 6A, the normalizer proceeds as follows. At step 601, the parser receives an INSERT statement from the user and creates an INSERT query tree. At step 602, the normalizer walks the query tree and uses syscolumns to set up bits for the values for the columns which are encrypted. Encrypted columns are normalized using their external types. At step 603, the normalizer traverses the tree, looking for the encryption bit and gets the keyid and keydbid for the column from syscolumns. For encrypted columns, the normalizer adds an encrypt built-in node above the value. Now, at step 604, a tree-based structure is filled with key information from sysencryptkeys. This internal structure is used later for compilation of the query execution plan).
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Henein to receiving a command including at least one of said query language extensions; parsing the query language extension to determine an operation associated with PII, in order to provide encryption support in an automated manner without requiring changes to applications, thereby providing protection of data privacy from a power of a system administrator or database application.
As to claim 14, the combination of Henein and Banks discloses the invention as claimed. In addition, Henein discloses the claimed wherein the sundering includes replacing actual data with false data (see [0019], data record can be received by user inputs from a terminal, for example, in a data entry operation. The data record can also be received from a file, for example, by parsing an input file that includes PII for many people. The data record can also be received over a wireline or a wireless network. In some cases, the data record can be received in a request to store the PII, or overwrite the existing PII for the person.)
As to claim 15, the combination of Henein and Banks discloses the invention as claimed. In addition, Henein discloses the claimed wherein said query extensions are operable to perform at least one of returning a result with actual data instead of false data, or associating a field in the database with a sundering function (see par. [0020], the data record is divided into multiple data entries. Each data entry includes a respective portion of the PII. For example, the data record can include the first name, the last name, the SSN, the phone number, the home address, and the email address of the person. The PII can be divided into multiple data entries: the first data entry includes the first name of the person, the second data entry includes the last name of the person, the third data entry includes the SSN of the person, the fourth, the fifth, and the sixth data entries include the phone number, the home address, and the email address of the person, respectively).
As to claim 16, the combination of Henein and Banks discloses the invention as claimed. In addition, Henein discloses the claimed wherein the query extension operates to create a data table for PII and a data table for non-personal identifiable information (see par. [0021], for each data entry, a database location is selected to store the respective portion of the PII. In some implementations, the database can be organized into multiple tables, each tables can have multiple cells that are organized in a row-by-column structure. Each database location can be a cell in the table. FIG. 5 illustrates the structure of an example database 500, according to an implementation. As illustrated, the database 500 includes tables 510 and 520. Each table includes multiple rows and columns. In some cases, a table ID can be assigned to each table, a row ID can be assigned to each row, and a column ID can be assigned to each column. Thus, each database location (cell) can be addressed by the combination of table ID, row ID, and column ID. In the illustrated example, cell 512, the database location storing the data “John,” can be addressed by “table ID=510, row ID=1001, column ID=2001.” Cell 522, the database location storing the data “first street,” can be addressed by “table ID=520, row ID=1001, column ID=2001.” The database 500 can have more than two tables and each table can have more rows and columns than illustrated.)
As to claim 17, the combination of Henein and Banks discloses the invention as claimed. In addition, Henein discloses the claimed wherein the query extension operates to select PII or non PII for the operational result (see par. [0021], for each data entry, a database location is selected to store the respective portion of the PII. In some implementations, the database can be organized into multiple tables, each tables can have multiple cells that are organized in a row-by-column structure. Each database location can be a cell in the table. FIG. 5 illustrates the structure of an example database 500, according to an implementation. As illustrated, the database 500 includes tables 510 and 520. Each table includes multiple rows and columns. In some cases, a table ID can be assigned to each table, a row ID can be assigned to each row, and a column ID can be assigned to each column. Thus, each database location (cell) can be addressed by the combination of table ID, row ID, and column ID. In the illustrated example, cell 512, the database location storing the data “John,” can be addressed by “table ID=510, row ID=1001, column ID=2001.” Cell 522, the database location storing the data “first street,” can be addressed by “table ID=520, row ID=1001, column ID=2001.” The database 500 can have more than two tables and each table can have more rows and columns than illustrated).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 20060053112 (involved in providing SQL extensions for automated encryption and decryption of column data is described. In one embodiment, for example, in a database system, a method is described for providing automated encryption support for column data, the method comprises steps of: defining Structured Query Language (SQL) extensions for creating and managing column encryption keys, and for creating and managing database tables with encrypted column data; receiving an SQL statement specifying creation of a particular column encryption key; receiving an SQL statement specifying creation of a database table having particular column data encrypted with the particular column encryption key; and in response to a subsequent database operation that requires the particular column data that has been encrypted, automatically decrypting the particular column data for use by the database operation).
US 20190114438 (involved in receiving an encryption request to perform encryption process on a set of records stored at a database server. The set of records is partitioned into a set of record groups based on default group size. Encryption process on a first record group of the set of record groups is performed based on the encryption request. Access to the first record group is restricted during the encryption process of the first record group. The access to the first record group is restored based upon completion of the encryption process of the first record group. An encryption status associated with the first record group is transmitted to a user interface).
US 20140136577 (involved in identifying objects in a database accessed by a statement using a processor of a computer. Determination is made that one of the objects among identified objects contains sensitive information by checking an indicator for the object. Security policies associated with the object are identified. Identified security policies for the object are implemented to delete sensitive information. The indicator is set to indicate that the object contains sensitive information when the indicator is in a database catalog in response to storing the object in the database).
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 JEAN M CORRIELUS whose telephone number is (571)272-4032. The examiner can normally be reached Monday-Friday 6:30a-10p(Midflex).
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, Ann J Lo can be reached at (571)272-9767. 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.
/JEAN M CORRIELUS/Primary Examiner, Art Unit 2159 June 4, 2026
Prosecution Insights