Detailed Action
Response to Arguments
Applicant’s arguments filed April 27, 2026 have been fully considered. After further consideration, a new ground(s) of rejection is presented due to Applicant’s amended claim language.
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 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.
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 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.
Claims 1, 3 – 11, and 13 – 20 are rejected under 35 U.S.C. 103 as being unpatentable over Durvasula (US Pub. No. 2020/0065521 A1) in view of Gupta (US Pub. No. 2023/0080686 A1) Khurana (US Pub. No. 2021/0141920 A1) in view of Sinkar (US Pub. No. 2022/0318273 A1) in view of Raju (US Pub. No. 20210124842 A1).
Per claim 1, Durvasula (US Pub. No. 2020/0065521 A1) is relied upon to teach a computer system (see Durvasula Figure 3 block 200) for masking personally identifiable information data, the computer system comprising: one or more processors (see Durvasula Figure 3 block 202); and non-transitory computer-readable storage media encoding instructions which, when executed by (see Durvasula Figure 3 block 206 and para 0034 – 0036) the one or more processors (see Durvasula Figure 3 block 202), causes the computer system to (see Durvasula para 0035): identify (reads on identify which columns contain PII, see Durvasula para 0007, 0019, 0038, 0046, 0050 – 0051 and claim 1. The Examiner asserts one cannot transform/remove/anonymize PII columns without first identifying those PII columns) one or more columns (reads on the system operates on PII columns, see Durvasula para 0019, 0038, 0046 and 0050) within a database application (reads on a database server/repository, see Durvasula para 0007 and claim 1) that contain the personally identifiable information data (reads on personally identifiable information/PII, see Durvasula para 0007, 0019, 0025 and claim 1); register (reads on the columns are included in the configuration files/request, see Durvasula para 0038, 0046. The Examiner asserts including a column in a configuration file is the same as registering that column because both mean adding the column to a structured list with associated metadata) the one or more columns (reads on the system operates on PII columns, see Durvasula para 0019, 0038, 0046 and 0050) in a configuration table (reads on the combination of configuration files that are data structures that store which columns to process, how to process them, and anonymization parameters, and repository configuration request which contains the schema/structure, see Durvasula Abstract, para 0038, 0046 and claim 1); generate (reads on create an anonymized data repository clone based on the anonymized data schema, see Durvasula Abstract, para 0020 and 0048) one or more database view (reads on views/repository clones, see Durvasula Abstract and para 0038) definitions (reads on anonymized data schema which is the definition of the structure, see Durvasula Abstract and claim 1), wherein the one or more database view definitions include instructions to replace (reads on data transformations that transform/replace, see Durvasula para 0042) the personally identifiable information data (reads on personally identifiable information/PII, see Durvasula para 0007, 0019, 0025 and claim 1) within the one or more columns (reads on the system operates on PII columns, see Durvasula para 0019, 0038, 0046 and 0050) with at least one of null values (The Examiner construes this to be at least implied by the prior art’s disclosure of replaced with a single special character, see Durvasula para 0042. The Examiner asserts one of ordinary skill in the art would know that null is a special character in computing, representing the absence of a value) or anonymized data (reads on anonymous/anonymized data and data masking where values are changed, see Durvasula para 0007, 0020, 0030, 0042 and 0043) to create one or more compliant views (reads on anonymized repository clone/views that may be compliant with a variety of privacy regulations, see Durvasula para 0025 and 0052 and Figure 7 and claim 1); generate (reads on creating an anonymized data repository clone, see Durvasula claim 1) the one or more compliant views (reads on anonymized repository clone/views that may be compliant with a variety of privacy regulations, see Durvasula para 0025 and 0052 and Figure 7 and claim 1), wherein the one or more compliant views dynamically present the personally identifiable information data in modified form from underlying database tables without duplicating storage of the personally identifiable information data (reads on by using tables and views as the unit of anonymization and cloning. Durvasula supports embodiments where the clone is implemented as anonymized tables or views over the same physical database rather than on a different physical server, such that anonymized fields or tables are co-located with the original data in the same physical database but separated logically via tables, views, and dataset definitions, see Durvasula para 0020, 0031, 0038, 0042 and 0044); and extract test data from the one or more compliant views (reads on extract and clone data via an anonymization clone process from the dataset, see Durvasula para 0044) for loading into a user acceptance testing object (reads on loading anonymized data into target datasets 310 and 312, see Durvasula para 0044). The prior art of record is silent on explicitly stating automatically identify, using machine learning techniques including pattern recognition trained from past instances of the personally identifiable information data; database view; generate one or more database view definitions; extract test data for loading into a user acceptance testing object.
Gupta (US Pub. No. 2023/0080686 A1) is relied upon to teach
automatically identify (reads on "Described herein are method and systems for automated PII sensitivity detection for data tables, data columns, and their metadata within a database," see Gupta para 0004. The cited passage teaches automated detection operating at the database-column level, which is precisely the "automatically identify ... one or more columns ... that contain the personally identifiable information data" the claim recites, in agreement with the spec's PII identification module operating on columns), using machine learning techniques including pattern recognition (reads on "The first layer builds a machine learning model, which learns the level of PII sensitivity from the patterns and diversity of the column name and metadata," see Gupta para 0005. The cited passage discloses a machine learning model that learns from patterns, i.e., pattern recognition, establishing the "machine learning techniques including pattern recognition" element, and the layered model that "finds matches of existing and available PII data with the new or unknown/unclassified column data" reads on training "from past instances of the personally identifiable information data") trained from past instances of the personally identifiable information data, one or more columns within a database application that contain the personally identifiable information data (reads on "executing, by a processor using a vector comprising a numerical representation of the metadata, a first artificial intelligence model to generate a first score corresponding to a first likelihood of the column including personally identifiable information," see Gupta para 0007. The cited passage confirms the AI model consumes historical metadata vectors to score column PII likelihood, which is the trained-from-past-instances character of the claimed ML identification); register the one or more columns (reads on "the analytics server 141 may change a data record within the database 130 that designates the column as including PII," see Gupta para 0041. The cited passage teaches recording, in a persistent data record, a designation that a specific column contains PII, which reads on registering the identified column, in agreement with the spec's registration of identified columns into a configuration table) in a configuration table (reads on "the analytics server may designate the column as PII within the database by changing a data record within the database," see Gupta para 0054. The cited passage confirms the designation is stored in a database data record that governs downstream masking/display, functioning as the configuration record the claim's "configuration table" is directed to).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify Durvasula's anonymized-data-repository framework by incorporating Gupta's automated PII-column detection framework so that the system more reliably identifies which database columns contain PII before those columns are subjected to anonymization operations. One or more of the underpinning rationale(s), as discussed in KSR see MPEP 2141 Rationale A and Rationale C, support this conclusion because the proposed combination applies known privacy-protection elements according to known methods to yield predictable results and uses a known technique to improve a similar database-privacy system in the same way. Durvasula expressly teaches that cloud repositories contain PII and that the disclosed techniques transform such PII into anonymized data. For example, Durvasula states: para 0005 - "Within the context of cloud computing solutions for data repositories, users may be asked to deal with ever increasing amounts of data, e.g., including certain Personally Identifiable Information (PII) stored in the data repositories." Durvasula further states: para 0007 - "the techniques described herein may include data transformations that transform the Personally Identifiable Information (PII) in a non-anonymized data repository into information that no longer identifies the individual or entity and saves the transformed information in the anonymized data repository clone or instance." Durvasula also expressly discloses: para 0020 - "one-way data transformations may include data masking and/or data morphing" and para 0042 - "In data masking, the format of data remains mostly the same; but the data values are changed." Durvasula further contemplates that the anonymization may be implemented in a manner that does not require duplication of the original storage on a different physical server. In particular, Durvasula states: para 0031 - "the non-anonymized data 106 may reside in one database (physical and/or virtual database) and then be converted to anonymized data 108 and stored in a second different database (physical and/or virtual database) and/or also stored in the first database." Durvasula also explains: para 0038 - "The configuration files A 304 and B 306 may include tables, views (e.g., SQL-based views), columns, rows, and the like, to anonymize via the techniques described herein." Durvasula further describes: para 0044 - "the user may use the GUI and/or the configuration files A 304, B 306 to extract and clone data via an anonymization clone process 308 from the dataset 302 into datasets 310 and 312 as anonymized data 108A and 108B." By using tables and views as the unit of anonymization and cloning, Durvasula supports embodiments where the clone is implemented as anonymized tables or views over the same physical database rather than on a different physical server, such that anonymized fields or tables are co-located with the original data in the same physical database but separated logically via tables, views, and dataset definitions. Gupta expressly teaches a database-level framework for identifying PII-bearing columns and then masking those columns. For example, Gupta states: para 0004 - "there is a desire for an electronic system to identify PII at a database level and customize the presentation of the identified PII, such that PII is not presented inappropriately." Gupta further states: para 0005 - "The methods and systems described herein provide a PH sensitivity detection framework having multiple layers for preventing a potential breach of PH." Most directly, Gupta recites: claim 1 / para 0007-"in response to determining that the third score indicates that the column includes personally identifiable information, masking, by the processor, the column data." Accordingly, it would have been obvious to one of ordinary skill in the art to have applied Gupta's known database-level PH-identification and masking trigger to the PH-bearing columns within Durvasula's anonymization workflow, so that the columns identified by Gupta as containing PH would be the columns selected for Durvasula's disclosed one-way anonymization operations, including data masking and/or data morphing, when creating the anonymized repository clone. A person of ordinary skill in the art would have recognized that Durvasula already provides the anonymization back-end for transforming repository PII into anonymized output, while Gupta provides a known and express front-end mechanism for determining which database columns contain PH and should therefore be masked. This would have been particularly suitable in Durvasula's expressly contemplated implementation in which anonymization is defined over "tables" and "views" and the anonymized data may be stored "also ... in the first database," because Gupta's column-level masking naturally supplies the field-selection and masking trigger for those same view- or table-based anonymized datasets without requiring relocation of the underlying database records. The combination would have yielded the predictable result of improved selection and anonymization of PII-bearing columns in the same enterprise-database privacy context addressed by both references, without changing the basic operation of either reference. The motivation to combine arises from the shared problem addressed by both references-preventing exposure of sensitive PII in database environments-and from Gupta's express teaching of an automated column-level detection framework that would have predictably improved Durvasula's process for selecting which fields should undergo anonymization. Durvasula is expressly concerned with anonymizing repository data containing PII, while Gupta is expressly concerned with identifying PII at the database-column level and masking that data so it is not presented inappropriately. Thus, a person of ordinary skill in the art would have had reason to combine the references under MPEP 2141 Rationale A (combining prior art elements according to known methods to yield predictable results) and Rationale C (use of a known technique to improve similar devices in the same way).
Khurana (US Pub. No. 2021/0141920 A1) is relied upon to teach
a computer system (see Khurana Figure 8 and para 0058 and 0062) for masking (reads on shading the column, see Khurana para 0052) personally identifiable information data (reads on the exemplary credit card, userid and address data, see Khurana para 0052), the computer system comprising: one or more processors (see Khurana para 0062); and non-transitory computer-readable storage media encoding instructions which (see Khurana para 0062), when executed by the one or more processors (see Khurana para 0062), causes the computer system to (see Khurana para 0062): identify one or more columns (reads on identify the exemplary userid column, see Khurana para 0009, 0052 and Figure 6) within a database application that contain (reads on the dataset/catalog object, see Khurana para 0009, 0028, 0035 and Figure 3 and 6) the personally identifiable information data (reads on the exemplary credit card, userid and address data, see Khurana para 0052); generate one or more database view definitions (reads on view definitions that contain checks for access controls, see Khurana para 00028 – 0029), wherein the one or more database view definitions include instructions to replace the personally identifiable information data within the one or more columns with at least one of null values or anonymized data (reads on the single view can anonymize columns, filter out rows and redact content down to the single-cell level, see Khurana para 0028 – 0030) to create one or more compliant views (reads on the dynamic view that anonymizes or filters data from specific rows, columns, cells or other regions of a data source, see Khurana para 0028 – 0030 and Figure 6 and Figure 3 block 303); generate the one or more compliant views (reads on respond to the user with the dynamic view, to view anonymized data, see Khurana para 0028 – 0030, 0058 and Figure 3 block 304 and Figure 6) wherein the one or more compliant views dynamically present the personally identifiable information data in modified form (reads on "Dynamic view 600 is a view in which data can be dynamically enabled or disabled according to a user's access settings. In some examples, dynamic view 600 anonymizes columns, filters out rows, and redacts data in individual cells based on what a user is allowed to access," see Khurana para 0053. The cited passage discloses a dynamic view that anonymizes/redacts column data at presentation time, which reads on compliant views that "dynamically present the personally identifiable information data in modified form") from underlying database tables without duplicating storage of the personally identifiable information data (reads on "data is always read from the same catalog object, not a different view according to the user, and the need to maintain many views is eliminated. The present technology allows administrators to create a single view that can anonymize columns, filter out rows, and redact content down to the single-cell level while requiring minimal or no performance overhead," see Khurana para 0028. Reading "always ... from the same catalog object" and eliminating duplicate views reads directly on presenting from the "underlying database tables without duplicating storage," in agreement with the spec’s "without physical duplication”.
.
Abstract
Various embodiments of the present technology generally relate to management of big data storage and data access control systems. In some embodiments, a data access system provides a user with an anonymized version of a dynamic view for a dataset. The system, in some implementations, supports data anonymization and filtering within a single view created for a dataset and eliminates the need to create separate views of a dataset for each access level. Embodiments herein include methods, apparatuses, and computer-readable media for enforcing access control policies within a multiple application and multiple storage system environment. In some implementations, a data access system receives a request to access a dataset from a user environment and subsequently identifies the user to a database. The database may respond to the request with controls for the user and the system may respond to the user environment with an anonymized representation of the dataset.
[0009] In some embodiments, identifying the at least one access control policy comprises identifying a user associated with the user request and determining access controls for the user based the user and information stored in an access control database. The method may further comprise enabling one or more allowed elements of the dataset in the dynamic view based on the at least one access control policy. In some embodiments, disabling the one or more elements of the dataset in the dynamic view comprises anonymizing one or more columns of the dataset in the dynamic view based on the at least one access control policy, filtering one or more rows of the dataset in the dynamic view based on the at least one access control policy, or redacting one or more unallowed elements of the dataset in the dynamic view based on the at least one access control policy such that original content of the one or more unallowed elements cannot be identified in the dynamic view. In some embodiments, responding to the user request with the dynamic view comprises displaying the dynamic view in a user interface associated with the user request.
[0028] Thus, embodiments herein include a data access module for dynamic views that support data anonymization and filtering without the need to create different views for each access level. The dynamic views feature simplifies and/or solves many issues for analyst users in a data access system. In some implementations, data is always read from the same catalog object, not a different view according to the user, and the need to maintain many views is eliminated. The present technology allows administrators to create a single view that can anonymize columns, filter out rows, and redact content down to the single-cell level while requiring minimal or no performance overhead.
[0029] The dynamic view engine described herein may, in some embodiments, be implemented within a built-in module (i.e., a builtin) or a similar module in a data access platform. The builtin, similar to other Structured Query Language (SQL) builtins to allow view definitions (or SQL queries), contains checks for access controls. The builtin, therefore, can be resolved entirely at planning time and require no runtime overhead. Each case may be consolidated into a single view capable of providing dynamic access to content. The builtin may be implemented within a data access platform to control which users have access to which content within the single view. The dynamic view may anonymize or filter data from specific, rows, columns, cells, or other regions of a data source.
[0030] In some examples, a DBA may issue grants on the base table for all end users, and all end users access the base table through the single view. However, the base table within the single view may exclude some data based on user permissions, access level, user type, and similar restrictions. In this manner, when a user attempts to access the base table, columns, rows, cells, and other information can be shown or anonymized (enabled or disabled) according to what the user is allowed to access.
[0035] In operation, data access system 101 may perform access-based dynamic view processes for datasets, specifically scoped to eliminate the need to create a separate view for every access level. Data access system 101 receives a dataset access request from a user environment and retrieves access controls based on the user request from a dataset. Upon receiving access controls for the user, data access system 101 enables and/or disables components of the dataset within a dynamic view and provides the anonymized view to the user environment.
[0042] In step 304, the dynamic view of the dataset is displayed wherein the one or more disabled elements are hidden in the dynamic view. Enabled elements may be shown through a user environment similar to that described in reference to FIG. 2, in some examples. In the present example, data is excluded from the dynamic view using anonymization. Anonymization may be used to protect disabled data by tokenizing data, encrypting data, irreversibly altering data, or similar anonymization tactics. In alternative embodiments, data may be filtered, obfuscated, pseudonymized, redacted, masked, substituted, reversibly altered, hidden, blurred, removed, or disabled from viewing in a similar manner not included herein for purposes of brevity.
[0051] FIG. 6 illustrates an example of a data table that is dynamically anonymized or filtered within dynamic view 600 according to embodiments of the present technology described herein. Table 601 includes data associated with transactions of active users and is titled “TRANSACTIONS_ACTIVE_USERS.” Table 601 includes columns labeled transaction number (txnid), last_active_time, address, stock keeping unit (sku), userid, price, and credit card. The view of table 601 in the example of FIG. 6 may be provided to a user through a user interface based on predetermined access controls for the user. Access controls for the user may be accessed or determined using similar methods to those described in reference to FIG. 2, FIG. 3, and FIG. 4.
[0052] Table 601 may be presented to a user in the dynamic view. The user of the present example has access to transaction data for all but two users in table 601. Furthermore, the user of the present example has access to txnid, last_active_time, address, sku, price, and credit card. However, the user of the present example does not have access to the userid of any transactions in the base table. The user also does not have access to the first twelve digits of the credit card number associated with each transaction. Although the user can see the title of the userid column, each of the cells is removed from the user's view by shading the column. The columns and rows that are dynamically left out from table 601 are all filtered from the table using shading. However, the credit card column provides an example of how data can be filtered in a different manner. Similarly, the address column of table 601 demonstrates an additional way in which data may be filtered in dynamic view 600 according to the access level of a user. In the present example, the address column only shows the state for each transaction and leaves out the rest of the address. The address data may be presented in this manner for all users or may only be presented in this manner for users of certain access levels.
[0053] Table 601 is derived from a base table and provided within the same view that would be provided for any user of any access level. Dynamic view 600 is a view in which data can be dynamically enabled or disabled according to a user's access settings. In some examples, dynamic view 600 anonymizes columns, filters out rows, and redacts data in individual cells based on what a user is allowed to access. Dynamic view 600 may enable all columns, rows, and cells for users with unrestricted access.
[0058] A data access system such as data access system 101, data access service 201, and application service 430, may use an access table such as access table 701 to determine what elements to enable and/or disable in a dynamic view. A data access system may subsequently, in some examples, generate an anonymized view to display in a user environment. Data in an anonymized view may be filtered, anonymized, masked, redacted, or otherwise modified from an original table. User environment may be user environment 205, user environment 206, user interface 410 and native application 420, or a similar user environment in communication with a data access system.
[0062] Referring still to FIG. 8, processing system 803 may comprise a micro-processor and other circuitry that retrieves and executes software 806 from memory device 805. Processing system 803 may be implemented within a single processing device but may also be distributed across multiple processing devices or sub-systems that cooperate in executing program instructions. Examples of processing system 803 include general purpose central processing units, graphical processing units, application specific processors, and logic devices, as well as any other type of processing devices, combinations, or variations thereof.
4. The method of claim 1, wherein disabling the one or more elements of the dataset in the dynamic view comprises anonymizing one or more columns of the dataset in the dynamic view based on the at least one access control policy.
PNG
media_image1.png
692
746
media_image1.png
Greyscale
Before the effective filing date of the invention it would have been obvious to one of ordinary skill in the art to modify the anonymized data repository instances using one-way data transformations teachings of the prior art of record (see Durvasula para 0006 and 0044) by integrating the dynamic views that present modified data from underlying tables based on access policies without storing data teachings of Khurana (see Khurana para 0008 – 0009) to realize the instant limitation. One or more of the underpinning rational(s), as discussed in KSR see MPEP § 2141, are used to support this conclusion of obviousness. Accordingly, one of ordinary skill in the art would have recognized that applying the known dynamic view methodology of Khurana with the one-way transformation techniques of the prior art of record would have yielded the predictable result of eliminating the storage inefficiencies inherent in snapshot-based masking approaches and resulted in an improved system because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such features into similar systems. The motivation to combine the references is applied to all claims below this heading.
Sinkar (US Pub. No. 2022/0318273 A1) is relied upon to teach
register the one or more columns (reads on stores data attributes in the metadata repository, see Sinkar para 0005, 0032, 0063 and 0069 – 0070. The Examiner construes the data attributes to the be the same as the one or more columns) in a configuration table (reads on metadata repository, see Sinkar para 0005, 0032, 0063 and 0069 – 0070).
[0005] Disclosed herein are systems and methods for automated data governance. Consistent with the disclosed embodiments, a system is provided for automated data governance. The system includes a plurality of data environments, a metadata repository storing a plurality of data attributes and a plurality of classification requirements, and a policy repository. The system includes one or more processors and memory in communication with the one or more processors and storing instructions that, when executed by the one or more processors, cause the system to perform one or more steps of a method for providing automated data governance. The system may receive a first dataset and a first policy ID, i.e. a context (e.g., data environment) in which the system is being invoked, from a first data environment. The first dataset may include a first dataset ID. The system may transmit the first dataset ID and the first policy ID to the metadata repository. The system may receive an indication from the metadata repository that the first dataset contains at least one data attribute and at least one first associated classification requirement. The system may transmit the at least one first classification requirement to the policy repository. The system may receive a first classification code associated with the at least one first classification requirement from the policy repository. In response to receiving the first classification code, the system may modify the first dataset by transmitting instructions to the first data environment to execute the first classification code.
[0032] Metadata repository 112 may include a repository of data attributes and classification requirements associated with datasets that may be utilized by data environment(s) 116. Metadata repository may include a computer system configured to receive communications from classification management device 118 via, for example, API calls, or any other type or format of electronic communication. Information stored in metadata repository 112 may be accessed (e.g., retrieved, updated, and added to) via local network 114 (and/or network 106) by one or more devices (e.g., classification management device 118 and/or data environment(s) 116) of system 100. According to some embodiments, metadata repository 112 may store a plurality of different attributes associated with datasets stored in data environment(s) 116 including a dataset ID, which may be a number that uniquely identifies each dataset in system 100. Metadata repository 112 may additionally store a plurality of data attributes and a plurality of classification requirements for each dataset stored in the system. Data attributes may include a classification associated with the type of information found in a respective dataset. For example, data attributes may represent what kind of data is stored in a particular dataset, such as Payment card industry data, non-public information, human identifiable data, health industry (e.g., HIPAA) data, and general/unclassified data. Data attributes may also include a classification of each data entry in the dataset. For example, each entry in a given dataset may be classified as one of an account ID, an account identifier, a plastic number, a PAN number, a plastic account number, a social security number, etc. Metadata repository 112 may also include data indicative of which data attributes may include a classification requirement, as described in the paragraph below. Additionally, metadata repository may include audit information, such as a date when a particular record was created in metadata repository 112, a creation ID indicating a user that created the record in metadata repository 112, an update date which indicates the last time a record was updated in metadata repository 112, and an update ID which represents the identity of a user that last updated the entry in metadata repository 112.
[0063] FIG. 4 is a flow diagram 400 illustrating examples of methods for modifying a dataset to conform to an updated classification requirement, in accordance with certain embodiments of the disclosed technology. As shown in FIG. 4, in step 410 of method 400 the system (e.g., classification management device 118) may receive an indication from a metadata repository (e.g., metadata repository 110) that a first data attribute has been updated with a first classification requirement. For example, the first data attribute may be for HIPAA compliant data. A new government regulation for HIPAA data may have passed, which requires data masking for any HIPAA data in a production (e.g., public) data environment, and data tokenization for any data environment that is used internally by an organization (e.g., a quality assurance data environment). Accordingly, the metadata repository may be updated to include data masking as the classification requirement for datasets having the respective data attribute and a policy ID associated with a production data environment, and data tokenization as the classification requirement for datasets having the respective data attribute and a policy ID associated with a quality assurance data environment. In another example, a new government regulation may pass that requires a previously unprotected data attribute to be reclassified to a protected data attribute that requires tokenization. For example, the new regulation may reclassify a passport number as requiring the application of a data governance policy, when previously no data governance policy was set in place. Accordingly, the metadata repository may be updated with a new classification requirement for the data attribute for each possible policy ID (e.g., depending on what kind of data environment the data attribute is stored on). Because the classification code does not change, only metadata repository need be updated to include the data attributes (e.g., passport number) affected by the new regulation, and the standardized code arguments stored in the policy repository may be unchanged.
[0069] FIG. 5 is a flow diagram 500 illustrating another exemplary method for modifying a dataset to conform to a classification requirement, in accordance with certain embodiments of the disclosed technology. As shown in FIG. 5, in step 510 of method 500 the system (e.g., classification management device 118) may receive a request to publish a first dataset having a first dataset ID to a data environment associated with a first policy ID. For example, the first dataset may be received by the system from a third-party database (e.g., third-party database 122). According to some embodiments, the dataset having the first dataset ID may be copied to a public-facing data environment or a data environment closed to just the organization (e.g., organization 108), and depending on which data environment the dataset is placed on will have a different associated policy ID. Based on the target data environment, and the contents of the first dataset, the system may query the metadata repository to identify at least one data attribute and an associated classification requirement for the first dataset in step 520. As discussed with respect to FIG. 3 and FIG. 4, the data attribute may be associated with a data type present in the dataset, and the classification requirement for each data entry may be based on the data type present in the dataset as well as the data environment that the dataset is to be copied to (e.g., public-facing data environment vs. data environment open only to organization 108).
[0070] After receiving the at least one data attribute and an associated classification requirement, the system (e.g., classification management device 118) may query the policy repository for the relevant classification code in step 530. For example, the classification requirement may be for data tokenization for data entries having data attributes related to HIPAA data, SSN data entries, credit card numbers, etc. when the data environment is a private data environment accessible only to members of organization 108. Conversely, the classification requirement may be for data masking when the data environment is a public-facing data environment.
[0078] In step 780, the system (e.g., classification management device 118) may transmit instructions to the first data environment to execute the classification code. Accordingly, each identified missing data attribute will automatically have standardized code arguments applied to conform with the classification requirements for each specific data attribute based on the policy ID associated with the dataset (e.g., based on what type of data environment the respective dataset is stored on). In step 790, the system (e.g., classification management device 118) may update metadata repository 112 with the missing data attributes. Accordingly, the entries in policy repository 110 may be used to update metadata repository 112 with the missing data attributes.
Before the effective filing date of the invention it would have been obvious to one of ordinary skill in the art to modify the dynamic anonymized views with one-way data transformations teachings of the prior art of record (see Durvasula para 0006 and 0044 and Khurana 0008 – 0009) by integrating the automated discovery of data attributes, metadata repositories, and policy repositories that automatically identify and classify data requiring protection teachings of Sinkar (see Sinkar para 0005, 0006 and 0097 – 0103) to realize the instant limitation. One or more of the underpinning rational(s), as discussed in KSR see MPEP § 2141, are used to support this conclusion of obviousness. Accordingly, one of ordinary skill in the art would have recognized that applying the known automated governance discovery framework of Sinkar to the view generation and transformation system of the prior art of record would have yielded the predictable results of eliminating manual configuration overhead and ensure continuous compliance as data schemas evolve and resulted in an improved system because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such features into similar systems. The motivation to combine the references is applied to all claims below this heading.
Raju (US Pub. No. 20210124842 A1) is relied upon to teach extract (reads once the data is sanitized and validated place the data in a second secure staging location, see Raju para 0007) test data (reads on sanitized data, see Raju para 0007 and 0055) from the one or more compliant views (reads on second secure staging area containing sanitized data, see Raju para 0007 and 0055) for loading into (reads on load into the non-production applications, see Raju para 0055) a user acceptance testing object (reads on the non-production applications such as exemplary testing and development applications, see Raju para 0007 and 0055).
[0007] Embodiments of the present invention address the above needs and/or achieve other advantages by presenting systems, methods, computer program product and/or the like that provide for an online data hub/portal that allows for users to perform on-demand and/or scheduled extraction of data from disparate production applications into a secure staging location that triggers identification of Non-Public Information (NPI), sanitization of the identified NPI and validation of the data. Validation of the data not only insures that the NPI has been identified and sanitized but also that all relationships between data elements in downstream and upstream applications are kept intact. Once sanitized and validated, the data hub/portal places the data in a second secure staging location from which the sanitized data is loaded, otherwise referred to as “seeding”, into the non-production environment (e.g., testing and development applications or the like).
[0054] At the first secure staging area 412, the instructions 410 are configured to identify 440 data elements 220 of the copied production data 210 that include Non-Public Information (NPI) 442. As previously discussed, the NPI may be any information that the entity in control of the data hub/portal deems to be confidential or otherwise requires exclusion for the non-production environment. The instructions 410 are further configured to sanitize 450, otherwise referred to as “scrubbing”, the data elements 220 containing identifying NPI 442 by replacing the NPI 442 with fictitious values 452 (i.e., values/entries that are fake or do not otherwise indicate data/values that could be perceived to be real). In specific embodiments of the invention, instructions 410 are further configured to validate 460 the sanitized data. Validation includes validating NPI sanitization 462 (i.e., insuring that all of the NPI in the data set has been identified and removed) and data element relationship integrity 474 (i.e., insuring that all data elements in the data set, post NPI sanitization, maintain their upstream and downstream relationships with other tables, applications and the like).
[0055] In response to completion of the processing at the first secure staging area 412, the instructions 410 are configured to copy 470 the sanitized data 310 to a second secure staging area 414. In specific embodiments of the invention, the copying 470 of the sanitized data 310 to the secure staging area 414 triggers generation and initiation of communication of notification to one or more entities that indicates that the data has arrived at the second secure staging area 414 and is ready to be loaded/seeded into one or more of the plurality of non-production applications. The instructions 410 are configured to receive 480 a second user request 482 for a load/seed job 484. The second user request 482 includes second parameters 486 defining the criteria for loading the sanitized applications 310 (e.g., which of the non-production applications the data should be loaded to), as well as, the occurrences of loading the sanitized data from the second secure staging location to a plurality of the non-production applications (i.e., the load job is a one-time only occurrence or is configured to occur on regularly scheduled basis (e.g., daily, weekly or the like). In response to receiving the second user request 482, the instructions 410 are configured to load 490 the sanitized data 310 into one or more of the non-production applications 300.
Before the effective filing date of the invention it would have been obvious to one of ordinary skill in the art to modify the automated discovery, transformation and dynamic view generation teachings of the prior art of record (see Durvasula para 0006 and 0044 and Khurana 0008 – 0009 and Sinkar para 0005, 0006 and 0097 – 0103) by integrating the infrastructure for extracting production data, identifying and sanitizing sensitive elements, validating integrity, and loading sanitized data into testing environments teachings of Raju (see Raju para 0007, 0042 and 0054 – 0055) to realize the instant limitation. One or more of the underpinning rational(s), as discussed in KSR see MPEP § 2141, are used to support this conclusion of obviousness. Accordingly, one of ordinary skill in the art would have recognized that integrating validation workflow of Raju to the system of the prior art of record would have yielded the predictable results of operationalizing dynamically masked data for non-production testing environments with necessary validation safeguards because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such features into similar systems. The resulting system identifies, transforms and presents masked data in a system that triggers identification of Non-public information/PII, sanitization of the identified PII and validation of the data through to loading into testing and development applications. The motivation to combine the references is applied to all claims below this heading.
Per claim 3, the prior art of record further suggests wherein the configuration table (reads on the combination of metadata repository, see Sinkar para 0005, 0032, 0063 and 0069 – 0070 and configuration files that are data structures that store tables, views, columns, rows, which columns to process, how to process them, and anonymization parameters, and repository configuration request which contains the schema/structure, see Durvasula Abstract, para 0038, 0046 and claim 1) includes metadata about each (see Sinkar para 0032, 0060 and 0063) of the one or more columns (reads on the system operates on PII columns, see Durvasula para 0019, 0038, 0046 and 0050), including a data type (reads on what kind of data is stored, see Sinkar para 0032), a sensitivity level (reads on a sensitive attribute/l-diversity value/k-anonymity value, see Durvasula para 0019, 0039, 0040 and 0046), and a masking rule (reads on the combination of data indicative of data masking as the classification requirement, see Sinkar para 0033 and 0063 and request may also include data transformations to apply such as data masking, data morphing, data grouping and so on, see Durvasula para 0042, 0043 and 0046. The Examiner construes a data transformation to be the same as a masking rule because they both are a specification/rule/instruction of how to mask/transform the data and they are functionally identical).
Per claim 4, the prior art of record further suggests wherein the one or more compliant views are generated by (reads on respond to the user with the dynamic view, see Khurana para 0028 – 0030 and Figure 3 block 304 and Figure 6) a data anonymization module that employs at least one of tokenization, data scrambling, or synthetic data generation (reads on a data anonymization module that supports tokenization and generating an anonymized view that may be filtered, anonymized, masked, redacted or otherwise modified from an original table, see Khurana para 0038, 0042, 0058, 0072 and 0075).
Per claim 5, the prior art of record further suggests validate an integrity (reads on validates the data element integrity to insure data maintains upstream and downstream relationships, see Raju para 0054) and accuracy of (reads on validating NPI sanitization to insure all of the NPI has been identified and removed, see Raju para 0054) the one or more compliant views before generation in (reads on the integrity and accuracy occurring during the first secure staging area before the compliant view is finalized/data is present in the second secure staging area, see Raju para 0054 – 0055) a production/non-production environment (The Examiner construes a production environment to include. The Examiner asserts the first staging area of Raju is where sanitization validation occurs and this area is architecturally upstream of the non-production environment and the 2nd staging area where the compliant view/sanitized data is generated and validated, see Raju Figure 3 and associated text).
Per claim 6, the prior art of record further suggests, wherein extracting data includes (reads on copying data includes first transmitting instructions to the second data environment to ensure the proper data masking occurs, see Sinkar para 0058, 0074 and 0097) applying a filter or transformation (reads on the combination of instructions to the second data environment to ensure the proper data masking occurs, see Sinkar para 0058 and 0074 and sanitizing by replacing the NPI/PII with fictious values, see Raju para 0054) to the test data (reads on the combination of the dataset that is copied to the second data environment, see Sinkar para 0074 and 0097 and sanitized data, see Raju para 0007 and 0055) extracted from (reads once the data is sanitized and validated place the data in a second secure staging location, see Raju para 0007) the one or more compliant views (reads on the combination of the second secure staging area containing sanitized data, see Raju para 0007 and 0055 and dynamic view of Khurana para 0029 – 0030 and anonymized repository clone/views that may be compliant with a variety of privacy regulations, see Durvasula para 0025 and 0052 and Figure 7 and claim 1) to aid in ensuring that no personally identifiable information is inadvertently included in the user acceptance testing object (reads on to ensure the proper data masking occurs, see Sinkar para 0058, 0074 and 0097).
Per claim 7, the prior art of record further suggests enable the computer system to create an audit log of operations related to (reads on generate a report indicative of changes implemented on a given dataset in a respective data environment which may include a change log for policies being applied based on the classification requirement, see Sinkar para 0023, 0033, 0070 and 0074) masking of (reads on classification requirements including tokenization and masking, see Sinkar para 0033, 0070 and 0074) the personally identifiable information data (reads on the exemplary HIPAA data, SSN data entries and credit card numbers, see Sinkar para 0070 and 0074).
Per claim 8, the prior art of record further suggests instructions to update the one or more database view definitions (reads on view definitions that contain checks for access controls, see Khurana para 00028 – 0029) in response to a change (reads on modifying what is seen based on new policy due to new government regulations, see Sinkar para 0032, 0063 and Khurana Figure 3 blocks 303 and 304) in a data structure of the database application or privacy requirements (reads on an exemplary new government regulation for HIPAA data, see Sinkar para 0063) in the configuration table (reads on metadata repository, see Sinkar para 0005, 0032, 0063 and 0069 – 0070).
Per claim 9, the prior art of record further suggests wherein the user acceptance testing object (reads on the non-production applications such as exemplary testing and development applications, see Raju para 0007 and 0055) is part of a larger integrated development environment used for software development and testing (reads on non-production environment/development and testing environment, see Raju para 0007), and the computer system includes instructions for integrating the user acceptance testing object directly into development workflows (reads on the automated seeding of the sanitized data into the testing applications, see Raju para 0007, 0050 and 0055).
Per claim 10, the prior art of record further suggests further comprising instructions for periodically refreshing (reads on loading the sanitized data on a regularly scheduled basis into one or more non-production applications, see Raju para 0055) the test data (reads on sanitized data, see Raju para 0007 and 0055) from the one or more compliant views (reads on the combination of dynamic view that anonymizes or filters data from specific rows, columns, cells or other regions of a data source, see Khurana para 0028 – 0030 and Figure 6 and Figure 3 block 303 and second secure staging area containing sanitized data, see Raju para 0007 and 0055 and anonymized repository clone/views that may be compliant with a variety of privacy regulations, see Durvasula para 0025 and 0052 and Figure 7 and claim 1) in the user acceptance testing object (reads on the non-production applications such as exemplary testing and development applications, see Raju para 0007 and 0055).
Claims 11,13 – 20 are analyzed with respect to claims 1,3 – 10 respectively.
Conclusion
Applicant’s amendment necessitates a new ground(s) of rejection. 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 extension fee 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 date of this final action.
Contact
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Brian Shaw whose telephone number is (571)270-5191. The examiner can normally be reached on Mon-Thurs from 6:00 AM-3:30 PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jeff Nickerson can be reached on (469) 295-9235. The fax phone number for the organization where this application or proceeding is assigned is 703-872-9306.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/BRIAN F SHAW/
Primary Examiner, Art Unit 2432
Prosecution Insights