Differentially private iterative query system with standard SQL interface and bounded user contribution

Abstract

A system receives a raw SQL query and automatically transforms it into a differentially private SQL query with user contribution bounded by reservoir sampling. The system highlights what must be changed in the proposed SQL query in order for it to be transformed into a differentially private SQL query as an aid to the user. The resulting SQL query is human readable and understandable, allowing sophisticated users to see / edit the transformed SQL query in certain embodiments. The system also guides a sophisticated user by suggesting the correct query components for such users to insert on their own. The system further provides practical analytics using SQL within a rigorous privacy framework applied automatically in the background.

Description

DIFFERENTIALLY PRIVATE ITERATIVE QUERY SYSTEM WITH STANDARDSQL I NTERFACE AND BOUNDED USER CONTRI BUTIONCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority to US provisional patent application serial number 63 / 670,616, filed on July 12, 2024. Such application is incorporated by reference as if fully set forth herein.BACKGROUN D OF TH E INVENTION

[0002] Differential privacy is a framework for protecting individual privacy in statistical databases and data analysis. It provides a mathematically rigorous way to quantify and limit the amount of information that can be inferred about any single individual from the results of data queries or analyses of data pertaining to a group of individuals.

[0003] Differential privacy introduces carefully calibrated random noise into query results or statistical outputs. This noise masks the contributions of individual data points, making it difficult to determine whether any specific person's data was included in the analysis. The key principle is that the probability of obtaining a particular result should be similar whether an individual's data is included or not.

[0004] The strength of privacy protection within a differential privacy system is controlled by a parameter epsilon (e), often called the "privacy budget." Lower values of epsilon provide stronger privacy guarantees but reduce the accuracy of results. This allows data custodians to make informed trade-offs between privacy and utility. Differential privacy also has the advantage of being composable, meaning the privacy loss from multiple queries may be tracked and bounded.

[0005] The delta (6) value in differential privacy represents the probability that the privacy guarantee might not hold. It allows for a small chance of a privacy breach beyond what is accounted for by epsilon, and thereby complements the more-commonly discussed epsilon value. Typically, 6 is chosen to be very small, often smaller than 1 / n where n is the number of records in the dataset. Delta is particularly useful for mechanisms that cannot achieve pure E- differential privacy. Like epsilon, delta values accumulate across multiple queries, affecting the overall privacy budget. Delta essentially provides a way to deal with edge cases or low-probability events that might otherwise make it impossible to achieve meaningful utility while maintaining strict differential privacy.

[0006] SQL, or Structured Query Language, is a standardized programming language designed for managing and manipulating relational databases. It provides a set of commands that allow users to create, read, update, and delete data within database tables. Its primary strength lies in its ability to efficiently handle structured data and perform complex queries across multiple tables. SQL's syntax is relatively intuitive, using English-like statements that describe the desired operations on the data. This makes it accessible to both beginner programmers and experienced database administrators. While there are several dialects of SQL used by different database management systems, the core principles and most common commands remain consistent across platforms.

[0007] Using SQL for differentially private queries has the potential to combine the power of relational database querying with privacy-preserving techniques. This approach allows organizations to extract valuable insights from sensitive data while protecting individual privacy. One of the potential challenges, however, is SQL expressiveness, which makes it impossible to turn every correct SQL query into a differentially private one.

[0008] To implement differentially private SQL queries, one could use specialized database systems or privacy-enhancing layers that sit between the analyst and the raw data. Such systems would modify standard SQL queries to incorporate noise addition and other privacy mechanisms. The original SQL query is transformed to include privacy-preserving operations. Based on the sensitivity and desired privacy level (epsilon), appropriate noise is added to the query results. The system monitors cumulative privacy loss across multiple queries.

[0009] Challenges in such a system as just described could include balancing query accuracy with privacy guarantees, handling complex queries efficiently, and managing the privacy budget over time. Some existing systems attempting to provide SQL-like queries with the application of differential privacy require considerable sophistication and knowledge on the part of the person performing these queries, and thus are not appropriate for most SQL users. This severely limits the utility of differentially private SQL query techniques. Other systems lack ease of readability or simplicity for the user, or are limited in their functionality.

[0010] User contribution bounding is an important concept in differential privacy when dealing with datasets where individual users can contribute multiple records or have disproportionate influence on query results. The goal is to limit the impact any single user can have on theoutcome of a query or analysis, thereby enhancing privacy protection. This may be achieved in various ways. One approach is to set a maximum limit on how much data or how many records a single user can contribute to a dataset or query result.

[0011] Reservoir sampling is the selection of a random sample of a given number of items from a stream of data of unknown size, with each item having an equal probability of being selected. In the context of differential privacy, reservoir sampling is used to limit user contributions by choosing up to a preset number of contributions. It allows for bounding the sensitivity of the aggregate measures, using less noise and thus improving the utility of the results.

[0012] The inventors hereof have recognized that a method and system that automatically transforms traditional user-generated SQL queries into differentially private SQL queries with user contribution bounding would be desirable as it would expand the potential use of differential privacy to non-experts. Essentially anyone familiar with SQL could perform these types of queries while maintaining strict differential privacy. Likewise, the inventors hereof have recognized that a method and system that would allow more sophisticated users to see and edit a transformation of a SQL query to a differentially private form, or that would suggest to such a user the correct query components, would improve the performance of differentially private searches for such sophisticated users as well.

[0013] Any references mentioned in this background are not admitted to be prior art with respect to the invention claimed herein.SUMMARY OF THE INVENTION

[0014] The present invention is directed to a system and method that receives a raw SQL query and automatically transforms it into a differentially private SQL query with user contribution bounded by reservoir sampling. The system and method may also, in certain embodiments, highlight what must be changed in the proposed SQL query in order for it to be transformed into a differentially private SQL query as an aid to the user.

[0015] The resulting SQL query is human readable and understandable, allowing sophisticated users to see / edit the transformed SQL query in certain embodiments. In certain embodiments the invention uses an iterative approach, where the author gets feedback on their regular SQL query from the validator with hints on how to write the query to benefit from automatic translation to a DP query. With this guidance, the user authoring a query will acquire skill at formulating SQL queries that can be made differentially private. Once such a user understandsthe applicable rules, such user will in time be able to create SQL queries that are differentially private with no warnings from the validator.

[0016] In certain embodiments, the system may also guide a sophisticated user by suggesting the correct query components for such users to insert on their own.

[0017] In certain embodiments, the system may also allow for easy but practical analytics using SQL within a rigorous privacy framework applied automatically in the background.

[0018] It may be seen that, according to certain embodiments of the invention, automatic transformation of any SQL query to one with differential privacy applied allows for privacy- compliant data analysis by analysts not familiar with the concepts of privacy (and in particular differential privacy). This opens up many datasets to analysis, which otherwise would have been unavailable due to privacy compliance concerns. Thus the invention in such embodiments allows for seamless, privacy-first data collaboration in many environments.

[0019] These and other features, objects and advantages of the present invention will become better understood from a consideration of the following detailed description of the preferred embodiments and appended claims in conjunction with the drawings as described following:BRIEF DESCRIPTION OF DRAWINGS

[0020] Fig. 1 is an architectural overview of an automatic differentially private query system according to an embodiment of the present invention.

[0021] Fig. 2 is a detailed view of the DP-SQL-ENGINE component of the system of Fig. 1 according to an embodiment of the present invention.

[0022] Fig. 3 is a diagram of particular equipment used to implement portions of the compute environment to implement the system of Fig. 1 according to an embodiment of the present invention.

[0023] Fig. 4 is a diagram illustrating the iterative SQL authoring flow according to an embodiment of the present invention.DETAILED DESCRIPTION OF THE INVENTION

[0024] Before the present invention is described in further detail, it should be understood that the invention is not limited to the particular embodiments described, and that the terms used in describing the particular embodiments are for the purpose of describing those particular embodiments only, and are not intended to be limiting, since the scope of the present invention will be limited only by the claims.

[0025] Referring now to Fig. 1, an overview of a system according to an embodiment of the present invention may be described. There are essentially three actors that engage with the system. The first is the differential privacy (DP) policy setter 10, who is the person who decides what the privacy budget will be for a particular use case. This person is responsible for determining the epsilon and delta values that will apply to use of the data. The second actor is the query author 12, who is the person performing queries against the data in order to generate results. The third actor is the query consumer 14, who is the person who desires to use the results of the queries generated by the query author 12.

[0026] Before any query is performed, the DP policy setter 10 creates a privacy policy 18 for the data, which includes a value for epsilon and, if applicable, a value for delta. The system writes the privacy policy to a data catalog 20. The system then converts this policy into metadata 34 that will be used for further processing. This metadata 34 may include privacy subject(s), column bounds for searches, and the aforementioned epsilon and delta values.

[0027] The query author then presents the system with a query 22, which in certain embodiments is composed as a standard SQL query. This query 22 is presented to the DP-SQL- ENGINE 24, the function of which is to apply differential privacy to the SQL query 22. Its internal processing will be described in more detail below with respect to Fig. 2. The result of DP-SQL- ENGINE 24 processing is a SQL query 28 with differential privacy having been applied.

[0028] The now differentially private SQL query 28 is then fed to the SQL processor 32 in order for the query to actually be run against a data set of interest. Another set of input 26 to the SQL processor includes the various parameters to be used in the search itself. These parameters include the necessary differentially private methods (examples will be provided below), preset bounds on the data domain, and the quantiles into which data is to be divided and to which the differentially private methods may be applied.

[0029] At the end of the process, the SQL processor 32 releases the results 30 of the query.The results 30 may be provided both to the query author 12 and the query consumer 14. It may be noted that in an alternative embodiment, the query author 12 and the query consumer 14 may be the same person. In this case, the results may be released to only a single person performing both roles in the system.

[0030] Referring now to Fig. 2, the operation of the DP-SQL-ENGINE 24 component of the system may be more specifically described in a particular embodiment of the present invention.The raw SQL query 22 is passed to two processing components, the parser 36 and the validator42.

[0031] The purpose of the validator 42 is to validate that the query 22 is a valid query against the relevant data set and which may be transformed into a differentially private SQL query 28. If the SQL query 22 is not validated, then the system provides guidance on how to change the input query 22 for it to be eligible for differential privacy processing, as more fully described below with reference to Fig. 4. The processing then ends after this information is returned from the validator 42. Depending upon the particular configuration, the validator 42 may also allow permissioned persons (e.g., sophisticated users) to override its warnings and allow for the transformation to proceed, at the actor's responsibility.

[0032] The parser component 36 parses the SQL query 22 into its constituent components for application of differential privacy, and passes those components to the DP-model component 38.

[0033] The DP-model component 38 is used by the generator component 40 to produce a new query 28 from the raw SQL query 22. This new SQL query 28 is semantically equivalent to the original input query 22 but is also differentially private. It applied the bounded user contribution method to make it applicable to real-life use cases, as well as explainable and readable to sophisticated users. Differentially private SQL with bounded user contribution is explained in greater detail in Wilson, Royce J. et al., "Differentially Private SQL with Bounded User Contribution," arXiv:1909.01917v3 (November 25, 2019); such paper is incorporated by reference as if fully set forth herein.

[0034] With reference now to Fig. 4, the iterative process for assisting a user with SQL authoring may be described in iterative SQL authoring flow 44. In the initial step of this process, a raw SQL query 22 is entered by a user, query author 12. The system then validates whether the SQL query 22 may be one that can be modified into a differentially private query 28, as explained above. This process takes place at the validator portion 42 of the DP-SQL-ENGINE 24.

[0035] If the SQL query 22 cannot be transformed into one that is differentially private, then an error is returned, optionally with hints provided to the human user query author 12 about ways in which the raw SQL query 22 may be modified so that it is one that may be made differentially private. This step not only results in SQL queries that may be run in a system requiring differential privacy, but also provides an educational element to the user so that the user may better understand how to formulate differentially private queries in the future.

[0036] Once an SQL query 22 is entered that can be transformed into one that is differentially private, that query is modified to provide differential privacy as explained more fully above to produce differentially private query 28.

[0037] In general, the structure of a differentially private query 28 with bounded construction in an embodiment of the invention is as follows. First, the system computes the contribution bonds and column domain bonds for the query 22. Then the system clamps the measurecolumns. Reservoir sampling is achieved by bound contributions to partition-buckets and bound contributions across buckets. Small buckets are dropped (using the tau threshold T, which in differential privacy represents a predefined upper bound on privacy loss), and then noise is applied with sensitives derived from the bounds and aggregation-functions.

[0038] Before proceeding with a particular method for use in an embodiment, the following definitions will apply. The privacysubject column is a column on one or multiple datasets that identifies a subject of privacy protection (such as a user_id). CORE_SQL is a common table expression (CTE) or the main query that: has a privacysubject column available (i.e., it doesn't necessarily have to be selected, just present in the dataset); defines grouping by a number of dimensions; defines measure aggregate functions (such as SUM) which are applied on measure columns; any row is owned by only a single privacysubject; any other CTE / query based on it cannot access the privacysubject column, just the dimensions and measures; can have any filter condition; and can depend on multiple other CTEs with the customer's custom logic.

[0039] Now a particular method for transforming an SQL query according to an embodiment may be described as follows. The basic flow of the algorithm is to extract a SQL flat relation CTE with a privacy subset column, dimensions, and measure columns, and wrap it up in CTEs conforming to the bounded user contribution SQL. In case any issues are encountered, a descriptive error message is provided to allow the operator to fix the query.

[0040] First, the existing CORE_SQL CTE is found. If none exists, then the system attempts to extract CORE_SQL CTE from the main query (See "basic queries" below). If there are, on the other hand, multiple candidates, then the processing is split into a workflow consisting of multiple separate CORE_SQLs (see "complex queries" below). Otherwise, the system will throw a descriptive error message allowing the user to correct the input SQL query.

[0041] Next, the system validates feasibility (e.g., should it raise an error if there is a shared ownership of rows by privacysubjects). The system then extracts the measures (columns being aggregated), dimensions (aggregation buckets), and applies a filter function.

[0042] The system then prepares a BASE_SQL from the CORE_SQL with the filter function and an aggregation removed (see example in "basic queries"). The bounds are computed for privacy subject contribution and measure columns, if required. It is important to calculate the bounds on unfiltered datasets, which is why BASE SQL does not contain filters. Then the system computes the required privacy parameters (e.g., epsilonPerMeasure). Finally, the system generates the differential privacy version of the query having a structure as shown in the form below:1 WITH2 ...., - ANY CUSTOMER LOGIC IN MULTIPLE CTEs that the BASE_SQL depends on3 BASE_SQL AS ..., - CORE_SQL stripped of filter and aggregation4 MAX_CONTRIBUTIONS AS ..., -- calculated using the approximate contribution DP algorithm or defined in metadata5 PRIVACY_PARAMS AS ..., -- this will depend on the count of measures6 BOUNDS AS ..., - bounds are best calculated on 'unfiltered' data to fully represent the domain or defined in metadata7 CONTRIB_BOUNDED_SQL AS ..., - reservoir sampling used to bound contributions8 CLAMPED_SQL AS ..., -- relevant columns are clamped to bounds9 AGGREGATED_SQL AS ... - measures are aggregated here as per original requirements10 PRIVATE_SQL AS ..., - showing just the entries above the TAU threshold11 POST_PROCESSED_SQL AS ... -- any expressions on private aggregates, ordering, etc.12 select * from POST_PROCESSED_SQL

[0043] It would be desirable to transform a single SQL input into a single differentially private SQL output query. This would allow for sending just a single differentially private SQL query to a database SQL engine and leave any intermediary storage and optimizations to happen deep down at the database layer. In order to be able to process a given SQL input query into a single differentially private SQL output query, the system must be able to parameterize the approximate bounds algorithm with the epsilon and contribution bounds. Unfortunately, some SQL engines e.g., Apache Spark do not allow for parameterizing the approximate boundsimplementation based purely on user defined aggregate functions (UDAFs), which would be the most natural approach.

[0044] As a result of these limitations, embodiments of the invention were developed to use both user defined functions (UDFs) and UDAFs, where the runtime parameters are required only by the Spark UDFs. Spark UDAFs are run parameterless. The embodiment as described herein works by using a Spark UDAF called APPROX_BOUNDS2PREP to gather the basic histograms, and uses a Spark UDF APPROX_BOUNDS2 to apply the differentially private part of the approximate bounds method. The UDF can be parameterized with the right epsilon and contribution bound, as requested.

[0045] The following UDAF provides an illustrative example of this functionality:1 / ** This implementation of approximate bounds works-around the Spark limitation, where UDAFs cannot easily accept run-time parameters.2 *3 * The solution:4 * - first runs a UDAF to collect the column_summary - this can be done without any privacy parameters5 * - then run the UDF with the column_summary and the relevant privacy parameters (passed at runtime!)6 *7 * Example (for epsilon = 0.5 and maxcontributions = 1):8 * ' "select APPROX_BOUNDS2(APPROX_BOUNDS2PREP(value).serialized, 0.5, 1) from global_temp. items"' g *10 * NOTE:11 * APPROX_BOUNDS2PREP is a function to be called internally, it must not be accessible to users, as it returns an aggregation of the data without noise applied12 * / 13 trait ApproximateBounds2UDAF {14 ...

[0046] A query might not include the CORE_SQL CTE. An example follows:1 Select CUSTOM ER_STATUS as CUSTOMER_STATUS,PRODUCT_CATEGORY as PRODUCT_CATEGORY,sum(PRICE) as SALES2 from @CRM usrs3 inner join ©Transaction trn on usrs.EMAIL_SHA256 = trn.EMAIL_SHA2564 group by 1,2In this case the system could extract the CORE_SQL as a CTE and run the method. Below is a version that is compatible with the method (privacy subject is EMAIL SHA256):1 WITH CORE_SQL AS (2 select CUSTOM ER_STAT US, PRODUCT_CATEGORY, trn.PRICE, usrs.EMAIL_SHA2563 from CRM usrs4 inner join Transaction trn on usrs.EMAIL_SHA256 = trn.EMAIL_SHA2565 )6 Select CUSTOM ER_STATUS, PRODUCT_CATEGORY, sum(PRICE) as SALES7 FROM CORE_SQL8 group by 1, 29 order by 1, 2

[0047] A query might include multiple aggregated subqueries and the system can use workflows (flows) to process them by splitting into multiple steps, where each is handled by the differential privacy method. Several different types of example queries are shown below and suggest how a user can create a workflow out of them (the creation of flows may be automated or one may generate one possibly long SQL that calculates each step as a CTE). Type examples follow:

[0048] Type 1 (multiple independent differential privacy subqueries)1 WITH2 A AS (SELECT dimensionl, dimension2, sum(value) as suml from X),3 B AS (SELECT dimensionl, dimensions, sum(other_value) as sum2 from Y)4 SELECT5 dimension!, sum(suml + sum2)6 FROM A join B on dimension!

[0049] Another, more complex example is a query where differential privacy is required at multiple levels.

[0050] Type 2 (multiple independent differential privacy queries with a partially aggregated dependent)1 WITH2 A AS (SELECT USERJD, SUM(VALUEl) AS SUMI FROM X),3 B AS (SELECT COUNT(USERJD) AS COUNT, SUM(SUMl), DIMI FROM A JOIN Y ON USERJD GROUP BY DIMI),4 C AS (SELECT SUM(SUMl), DIMI FROM A JOIN Z ON USERJD GROUP BY DIM 1)5 SELECT ... FROM B JOIN C67 -- sketch of dependencies:8 A(pa-DP)9 / \10 B(DP) C(DP)11 \ / 12 DNote that A is partially aggregated, as it returns userjd but it also contains the SUM(value) which should have differential privacy noise applied. This may be called a partially aggregated differential privacy subquery (pa-DP) and should allow it to be calculated as part of a flow, making sure that the proper differential privacy mechanisms should be applied before the flow produces its outputs. This query can be processed as part of the following flow:Question 1: A partially aggregated with differential privacy noise (pa-DP)Question 2 and Question 3: differential privacy queries B and C that depend upon A's results and add their own noise to any additional aggregationsQuestion 4: a regular query (non-DP) that is simply combining the results of Q2 and Q3 outputs

[0051] To allow for separating user roles in the final analytical workflow it might be useful to use a three-step-DP workflow rather than a single query. The three-step-DP structure divides the query into three parts. The following table shows the mapping between the CTEs that the differential privacy method produces and the three-step-DP. three-step-DP A single Query Differential Privacy Method1. partial aggregation BASE_SQL and the parent custom user CTEs2. privacy application All the other CTEs3. post processing POST_PROCESSED_SQL

[0052] It may be noted that extensive aggregation in step one of the three-step-DP might hurt utility. This is because when pre-aggregate values are calculated into a new aggregated column, the values of that column might be more extreme (e.g., the SUM(impressions) column would have a larger bound than the impressions column), which will in turn impact the sensitivity of the column and cause more noise to be added. This is the reason why the differential privacy algorithm depends on the row-level values. Nevertheless, partially aggregated data can be treated as just row-level non-aggregated data (e.g., with column SUM(impressions) replacing the column impressions), hence the relation in the first level of the above table.

[0053] In an embodiment, tau should not be used as a part of post-processing. Note that the mapping suggests placing the tau application in the middle step: privacy application. Technically it might be moved to the last step, post-processing, but that would mean that the privacy control (which is a tau application) leaks into the user-domain of post-processing, where the user might misuse it (e.g., ignore it or not apply it correctly).

[0054] The methods described herein may in various embodiments be implemented by any combination of hardware and software. For example, in one embodiment, the methods may be implemented by a computer system (e.g., a computer system as in Fig. 3) or a collection of computer systems, each of which includes one or more hardware processors executing program instructions stored on a computer-readable physical storage medium coupled to the hardware processors, within the provider environment 10 and the customer environment 14. The program instructions may implement the functionality described herein (e.g., the functionality of various hardware servers and other components that implement the network-based cloud and non-cloud computing resources described herein). The various methods as illustrated in the figures and described herein represent example implementations. The order of any method may be changed, and various elements may be added, modified, or omitted.

[0055] Fig. 3 is a block diagram illustrating an example computer hardware system, according to various embodiments. Computer system 140 may implement a hardware portion of a cloud computing system as forming parts of the various implementations of the present invention. Computer system 140 may be any of various types of hardware devices, including, but not limited to, a commodity server, personal computer system, desktop computer, laptop or notebook computer, mainframe computer system, handheld computer, workstation, network computer, a consumer device, application server, physical storage device, telephone, mobile telephone, or in general any type of computing node, compute node, compute device, and / or hardware computing device.

[0056] Computer system 140 includes one or more hardware processors 140a, 141b... Mln (any of which may include multiple processing cores, which may be single or multi-threaded) coupled to a physical system memory 142 via an input / output (I / O) interface 144. Computer system 140 further may include a network interface 146 coupled to I / O interface 144. In various embodiments, computer system 140 may be a single processor system including one hardware processor 141a, or a multiprocessor system including multiple hardware processors 141a, 141b... Mln as illustrated in Fig. 3. Processors 141a, etc. may be any suitable processors capable of executing computing instructions. For example, in various embodiments, processors 141a, etc. may be general-purpose or embedded processors implementing any of a variety of instruction set architectures. In multiprocessor systems, each of processors 141a, etc. may commonly, but not necessarily, implement the same instruction set. The computer system 140 also includes one or more hardware network communication devices (e.g., network interface 146) for communicating with other systems and / or components over a communications network, such as a local area network, wide area network, or the Internet. For example, a client application executing on system 140 may use network interface 146 to communicate with a server application executing on a single hardware server or on a cluster of hardware servers that implement one or more of the components of the systems described herein in a cloud computing environment as implemented in various sub-systems. In another example, an instance of a server application executing on computer system 140 may use network interface 146 to communicate with other instances of an application that may be implemented on other computer systems.

[0057] In the illustrated embodiment, computer system 140 also includes one or more physical persistent storage devices 148 and / or one or more I / O devices 150. In various embodiments,persistent storage devices 148 may correspond to disk drives, tape drives, solid-state memory or drives, other mass storage devices, or any other persistent storage devices. Computer system 140 (or a distributed application or operating system operating thereon) may store instructions and / or data in persistent storage devices 148, as desired, and may retrieve the stored instructions and / or data as needed. For example, in some embodiments, computer system 140 may implement one or more nodes of a control plane or control system, and persistent storage 148 may include the solid-state drives (SSDs) attached to that server node. Multiple computer systems 140 may share the same persistent storage devices 148 or may share a pool of persistent storage devices, with the devices in the pool representing the same or different storage technologies, including such technologies as described above.

[0058] Computer system 140 includes one or more physical system memories 142 that may store code / instructions 143 and data 145 accessible by processor(s) 141a, etc. The system memories 142 may include multiple levels of memory and memory caches in a system designed to swap information in memories based on access speed, for example. The interleaving and swapping may extend to persistent storage devices 148 in a virtual memory implementation, where memory space is mapped onto the persistent storage devices 148. The technologies used to implement the system memories 142 may include, by way of example, static randomaccess memory (RAM), dynamic RAM, read-only memory (ROM), non-volatile memory, solid- state memory, or flash-type memory. As with persistent storage devices 148, multiple computer systems 140 may share the same system memory systems 142 or may share a pool of system memories 142. System memory or memory systems 142 may contain program instructions 143 that are executable by processor(s) 141a, etc. to implement the routines described herein.

[0059] In various embodiments, program instructions 143 may be encoded in binary, Assembly language, any interpreted language such as Java, compiled languages such as C / C++, or in any combination thereof; the particular languages given here are only examples. In some embodiments, program instructions 143 may implement multiple separate clients, server nodes, and / or other components.

[0060] In some implementations, program instructions 143 may include instructions executable to implement an operating system (not shown), which may be any of various operating systems, such as UNIX, LINUX, Solaris™, MacOS™, or Microsoft Windows™. Any or all of program instructions 143 may be provided as a computer program product, or software, that may includea non-transitory computer-readable storage medium having stored thereon instructions, which may be used to program a computer system (or other electronic devices) to perform a process according to various implementations. A non-transitory computer-readable storage medium may include any mechanism for storing information in a form (e.g., software or processing application) readable by a machine (e.g., a physical computer). Generally speaking, a non- transitory computer-accessible medium may include computer-readable storage media or memory media such as magnetic or optical media, e.g., disk or DVD / CD-ROM, coupled to or in communication with computer system 140 via I / O interface 144. A non-transitory computer- readable storage medium may also include any volatile or non-volatile media such as RAM or ROM that may be included in some embodiments of computer system 140 as system memory 142 or another type of memory. In other implementations, program instructions may be communicated using optical, acoustical or other form of propagated signals (e.g., carrier waves, infrared signals, digital signals, etc.) conveyed via a communication medium such as a network and / or a wired or wireless link, such as may be implemented via network interface 606. Network interface 146 may be used to interface with other devices 142, which may include other computer systems or any type of external electronic device.

[0061] In some embodiments, system memory 142 may include data store 145, as described herein. In general, system memory 142 and persistent storage 148 may be accessible on other devices 142 through a network and may store data blocks, replicas of data blocks, metadata associated with data blocks, and / or their state, database configuration information, and / or any other information usable in implementing the routines described herein.

[0062] In one embodiment, I / O interface 144 may coordinate I / O traffic between processors 141a, etc., system memory 142, and any peripheral devices in the system, including through network interface 146 or other peripheral interfaces. In some embodiments, I / O interface 144 may perform any necessary protocol, timing or other data transformations to convert data signals from one component (e.g., system memory 142) into a format suitable for use by another component (e.g., processors 141a, etc.). In some embodiments, I / O interface 144 may include support for devices attached through various types of peripheral buses, such as a variant of the Peripheral Component Interconnect (PCI) bus standard or the Universal Serial Bus (USB) standard, as examples. Also, in some embodiments, some or all of the functionality of I / O interface 144, such as an interface to system memory 142, may be incorporated directly into processor(s) 141a, etc.

[0063] Network interface 146 may allow data to be exchanged between computer system 140 and other devices attached to a network, such as other computer systems (which may implement one or more storage system server nodes, primary nodes, read-only node nodes, and / or clients of the database systems described herein), for example. In addition, I / O interface 144 may allow communication between computer system 140 and various I / O devices 150 and / or remote storage 148. Input / output devices 150 may, in some embodiments, include one or more display terminals, keyboards, keypads, touchpads, scanning devices, voice or optical recognition devices, or any other devices suitable for entering or retrieving data by one or more computer systems 140. These may connect directly to a particular computer system 140 or generally connect to multiple computer systems 140 in a cloud computing environment, grid computing environment, or other system involving multiple computer systems 140. Multiple input / output devices 150 may be present in communication with computer system 140 or may be distributed on various nodes of a distributed system that includes computer system 140. In some embodiments, similar input / output devices may be separate from computer system 140 and may interact with one or more nodes of a distributed system that includes computer system 140 through a wired or wireless connection, such as over network interface 146. Network interface 146 may commonly support one or more wireless networking protocols (e.g., Wi- Fi / IEEE 802.11, or another wireless networking standard). Network interface 146 may support communication via any suitable wired or wireless general data networks, such as other types of Ethernet networks, for example. Additionally, network interface 146 may support communication via telecommunications / telephony networks such as analog voice networks or digital fiber communications networks, via storage area networks such as Fibre Channel SANs, or via any other suitable type of network and / or protocol. In various embodiments, computer system 140 may include more, fewer, or different components than those illustrated in Fig. 3 (e.g., displays, video cards, audio cards, peripheral devices, or an Ethernet interface).

[0064] Any of the distributed system embodiments described herein, or any of their components, may be implemented as one or more network-based services in the cloud computing environment. For example, a read-write node and / or read-only nodes within the database tier of a hardware database system may present database services and / or other types of physical data storage services that employ the distributed storage systems described herein to clients as network-based services. In some embodiments, a network-based service may be implemented by a software and / or hardware system designed to support interoperablemachine-to-machine interaction over a network. A web service may have an interface described in a machine-processable format. Other systems may interact with the network-based service in a manner prescribed by the description of the network-based service's interface. For example, the network-based service may define various operations that other systems may invoke, and may define a particular application programming interface (API) to which other systems may be expected to conform when requesting the various operations.

[0065] In various embodiments, a network-based service may be requested or invoked through the use of a message that includes parameters and / or data associated with the network-based services request. Such a message may be formatted according to a particular markup language such as Extensible Markup Language (XML), and / or may be encapsulated using a protocol. To perform a network-based services request, a network-based services client may assemble a message including the request and convey the message to an addressable endpoint (e.g., a Uniform Resource Locator (URL)) corresponding to the web service, using an Internet-based application layer transfer protocol such as Hypertext Transfer Protocol (HTTP).

[0066] Unless otherwise stated, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs. Although any methods and materials similar or equivalent to those described herein can also be used in the practice or testing of the present invention, a limited number of the exemplary methods and materials are described herein. It will be apparent to those skilled in the art that many more modifications are possible without departing from the inventive concepts herein.

[0067] All terms used herein should be interpreted in the broadest possible manner consistent with the context. When a grouping is used herein, all individual members of the group and all combinations and sub-combinations possible of the group are intended to be individually included. When a range is stated herein, the range is intended to include all sub-ranges within the range, as well as all individual points within the range. When "about," "approximately," or like terms are used herein, they are intended to include amounts, measurements, or the like that do not depart significantly from the expressly stated amount, measurement, or the like, such that the stated purpose of the apparatus or process is not lost. All references cited herein are hereby incorporated by reference to the extent that there is no inconsistency with the disclosure of this specification.

[0068] The present invention has been described with reference to certain preferred and alternative embodiments that are intended to be exemplary only and not limiting to the full scope of the present invention, which is limited only by the claims presented herein.

Claims

Claims1. A computerized system for transforming SQL queries into differentially private SQL queries, comprising: a processor; a memory coupled to the processor, the memory storing instructions that, when executed by the processor, cause the system to: receive a raw SQL query from a user; validate whether the raw SQL query can be transformed into a differentially private SQL query; if the raw SQL query cannot be transformed, provide guidance to the user on modifying the raw SQL query; if the raw SQL query can be transformed, parse the raw SQL query into constituent components; apply a differential privacy model to the parsed components; generate a new SQL query that is semantically equivalent to the raw SQL query and is differentially private; and output the new SQL query.

2. The system of claim 1, wherein the instructions further cause the system to apply a bounded user contribution algorithm to the new SQL query.

3. The system of claim 1, wherein the instructions further cause the system to highlight changes required in the raw SQL query for transformation into a differentially private SQL query.

4. The system of claim 1, wherein the instructions further cause the system to suggest query components to the user for insertion into the raw SQL query.

5. The system of claim 1, wherein the instructions further cause the system to: receive a privacy policy from a differential privacy policy setter; convert the privacy policy into metadata; anduse the metadata in generating the new SQL query.

6. The system of claim 5, wherein the metadata comprises privacy subjects, column bounds for searches, and epsilon and delta values.

7. The system of claim 1, wherein the instructions further cause the system to process the new SQL query against a data set of interest using a SQL processor.

8. The system of claim 7, wherein processing the new SQL query comprises applying differentially private algorithms comprising approximate bounds and quantiles.

9. The system of claim 1, wherein the new SQL query is human-readable and understandable.

10. The system of claim 1, wherein the instructions further cause the system to allow a permissioned user to override validation warnings and proceed with transformation of the raw SQL query.

11. A method for transforming SQL queries into differentially private SQL queries, comprising: receiving a raw SQL query from a user; validating whether the raw SQL query can be transformed into a differentially private SQL query; if the raw SQL query cannot be transformed into a differentially private SQL query, providing guidance to the user on modifying the raw SQL query; if the raw SQL query can be transformed: parsing the raw SQL query into constituent components; applying a differential privacy model to the parsed components; generating a new SQL query that is semantically equivalent to the raw SQL query and is differentially private; and outputting the new SQL query.

12. The method of claim 11, further comprising the step of applying a bounded user contribution algorithm to the new SQL query.

13. The method of claim 11, further comprising the step of highlighting changes required in the raw SQL query for transformation into a differentially private SQL query.

14. The method of claim 11, further comprising the step of suggesting query components to the user for insertion into the raw SQL query.

15. The method of claim 11, further comprising: receiving a privacy policy from a differential privacy policy setter; converting the privacy policy into metadata; and using the metadata in generating the new SQL query.

16. The method of claim 15, wherein the metadata comprises privacy subjects, column bounds for searches, and epsilon and delta values.

17. The method of claim 11, further comprising the step of processing the new SQL query against a data set of interest using a SQL processor.

18. The method of claim 17, wherein processing the new SQL query comprises the steps of applying differentially private algorithms, approximate bounds, and quantiles.

19. The method of claim 11, wherein the new SQL query is human-readable and understandable.

20. The method of claim 11, further comprising the step of allowing a permissioned user to override validation warnings and proceed with transformation of the raw SQL query.

Images