Collaborative intelligence constraint query and constraint calculation

Abstract

The present invention discloses a technique for constrained querying, allowing a data consumer to query collaborative data subject to configurable constraints in a trustee environment to derive collaborative intelligence without exposing the underlying raw data provided by the tenant or the collaborative data shielded by the trustee environment. Constraints can be applied in response to queries in a variety of ways, including reformatting the query before execution, applying constraints after query execution, constraining query execution that meets the conditions, applying access constraints before execution, and the like. In order to reformat a query subject to constraints, the query can be parsed into an execution tree, and the execution tree can be reformatted into a constrained execution tree by replacing executable logic units that are inconsistent with specific constraints with custom executable logic units that are consistent with the constraints. The constrained execution tree can be converted into the language used by the trustee environment and forwarded for execution.

Description

Background Art

[0001] Business and technology are increasingly dependent on data. Many types of data can be observed, collected, derived, and analyzed to gain insights that inspire scientific and technological advances. In many cases, valuable intelligence can be derived from data sets, and useful products and services can be developed based on that intelligence. This type of intelligence can help advance industries such as banking, education, government, healthcare, manufacturing, retail, and nearly any other industry. However, in many cases, the data sets owned or available to a particular data owner are incomplete or limited in some fundamental way. Information sharing is one way to bridge the gaps in data sets, and sharing data has become an increasingly common practice. There are many benefits to sharing data. However, there are also many concerns and barriers. Summary of the invention

[0002] Embodiments of the present disclosure relate to techniques for deriving collaborative intelligence based on constraint computation and query. At a high level, a data trustee can operate a trustee environment that derives collaborative intelligence subject to configurable constraints without sharing raw data. The trustee environment can include a data privacy pipeline through which data can be ingested, fused, derived, and cleansed to generate collaborative data without compromising data privacy. Collaborative data can be stored and queried to provide collaborative intelligence subject to configurable constraints. In some embodiments, the data privacy pipeline is provided as a distributed computing or cloud computing service (cloud service) implemented in the trustee environment and can be spun up and spun down as needed.

[0003] In order to enable constraint calculation and query, the constraint manager can monitor and coordinate the use and generation of constrained collaborative data in the trustee environment. As used herein, collaborative data refers to data that has been derived from shared input data (e.g., data from different users). The shared input data can come from any number of sources (e.g., different users) and can be processed to generate intermediate data, which itself can be processed to generate collaborative data. Collaborative data can include exposed parts that are allowed to be shared and restricted parts that are not allowed to be shared. Although the restricted part of collaborative data may not be shared, it can include an operable part that can be used to derive collaborative intelligence that can be shared. In some embodiments, collaborative intelligence can be derived from exposed data and / or restricted data, and collaborative intelligence can be provided without exposing restricted data.

[0004] A user interface may be provided to enable tenants (e.g., customers, businesses, users) to specify the desired calculations and constraints for using and accessing their data in a trustee environment, including eligible data sources and how their data may be processed or shared. Any number of various types of constraints may be implemented, including data access constraints, data processing constraints, data aggregation constraints, and data purification constraints, to name a few. A constraint manager may communicate with various components in a trustee environment to implement constraints. For example, a request to execute an executable logic unit (such as a command or function call) may be issued to a constraint manager, which may grant or deny permission. Permission may be granted based on one or more conditions for implementing constraints, such as requiring the replacement of a specific executable logic unit with a constrained executable logic unit. When constraints are applied to generate collaborative data and intermediate data, any combination of patterns, constraints, and / or attribute metadata may be associated with the data. Therefore, a constraint manager may coordinate constraint calculations in a trustee environment.

[0005] In some embodiments, constraint queries can be applied to allow data consumers associated with a trustee environment to query collaborative data subject to constraints in the trustee environment. Constraint queries can allow data consumers to access collaborative data or derive collaborative intelligence while enforcing constraints to prevent exposure of specified data (data that has been identified for enforcing specific constraints). Constraints can be applied in response to queries in a variety of ways, including reformatting queries before execution, applying constraints after executing queries, constraining eligible query execution, applying access constraints before execution, and the like. In order to reformat constrained queries, queries can be parsed into an execution tree that includes a hierarchical arrangement of executable logic units that implement the query when executed. The execution tree can be reformatted into a constrained execution tree by replacing executable logic units that are inconsistent with specific constraints with custom executable logic units that are consistent with the constraints. The constrained execution tree can be converted into the language used by the trustee environment and forwarded for execution.

[0006] This Summary is provided to introduce a selection of concepts in a simplified form that are further described in the Detailed Description below. This Summary is neither intended to identify key features or essential features of the claimed subject matter nor is it intended to be used alone as an aid in determining the scope of the claimed subject matter. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] The present invention is described in detail below with reference to the accompanying drawings, in which:

[0008] Figure 1 is a block diagram of an example collaborative intelligent environment according to embodiments described herein;

[0009] Figure 2is a block diagram of an example constrained query component according to embodiments described herein;

[0010] Figure 3A is an example of a query issued according to embodiments described herein, and Figure 3B is an example of the corresponding execution tree;

[0011] Figure 4A is an example of a constrained execution tree according to embodiments described herein, and Figure 4B is an example of a corresponding query;

[0012] Figure 5 is a flowchart illustrating an example method of generating collaborative data according to embodiments described herein;

[0013] Figure 6 is a flowchart illustrating an example method of generating collaborative data according to embodiments described herein;

[0014] Figure 7 is a flow chart illustrating an example method of providing constrained computing for collaborative data in a data trustee environment according to embodiments described herein;

[0015] Figure 8 is a flow chart illustrating an example method of providing constrained access to collaborative data in a data trustee environment according to embodiments described herein;

[0016] Fig. 9 is a flowchart illustrating an example method for constraining a query according to embodiments described herein;

[0017] Fig.10 is a flow chart illustrating an example method for constrained querying according to embodiments described herein;

[0018] Fig.11 is a block diagram of an example computing environment suitable for implementing the embodiments described herein; and

[0019] Fig.12 is a block diagram of an example computing environment suitable for implementing the embodiments described herein. DETAILED DESCRIPTION

[0020] Overview

[0021] Sharing data has many benefits. For example, sharing data often results in more complete data sets, encourages collaborative efforts, and produces better intelligence (e.g., understanding or knowledge of events or situations, or information, relationships, and facts about different types of entities). Researchers benefit from more available data. Further, sharing can stimulate interest in research and can incentivize the production of higher data quality. In general, sharing can lead to synergies and efficiencies in research and development.

[0022] However, there are still many concerns and obstacles to sharing data. As a practical matter, the ability and willingness to share data vary from industry to industry. Data privacy and confidentiality issues are fundamental to many industries, such as healthcare and banking. In many cases, laws, regulations, and consumer demands limit the ability to share data. In addition, the actions of observing, collecting, deriving, and analyzing data sets are often expensive and labor-intensive, and many people worry that sharing data will lose competitive advantage. Even if there is sufficient motivation to share data, control and access issues of shared data are often barriers to sharing. In fact, barriers often hinder data sharing and the opportunities for progress that come with it. Therefore, data sharing technologies are needed to promote the development of collaborative intelligence while ensuring data privacy and facilitating control and access to shared data.

[0023] Therefore, embodiments of the present disclosure relate to technologies for deriving collaborative intelligence based on constraint calculations and constraint queries. At a high level, a data trustee can operate a trustee environment that is configured to derive collaborative intelligence for a tenant that is subject to configurable constraints without exposing the underlying raw data provided by the tenant or the collaborative data shielded by the trustee environment. As used herein, collaborative data refers to data that has been derived from shared input data (e.g., data from different users). The shared input data can come from any number of sources (e.g., different users) and can be processed to generate intermediate data, which itself can be processed to generate collaborative data. Collaborative data may include an exposed portion that is allowed to be shared and a restricted portion that is not allowed to be shared. Although the restricted portion of collaborative data may not be shared, it may include an operable portion that can be used to derive collaborative intelligence that can be shared. In some embodiments, collaborative intelligence can be derived from exposed data and / or restricted data, and collaborative intelligence can be provided without exposing restricted data. For example, configurable constraints can programmatically manage restrictions (e.g., allowing certain operations but not others) on certain underlying data (e.g., personally identifiable information, certain other sensitive information, or any other specified information that is collected, stored, or used) and how these underlying data can and cannot be accessed, used, stored, or displayed (or variations thereof). Further, configurable constraints can programmatically support collaborative intelligent operations on accessible data (e.g., deriving aggregate statistics) without displaying the individual data items being operated on.

[0024] By relying on trustee computing to perform data processing, tenants can derive collaborative intelligence from each other's data without compromising data privacy. To achieve this, the trustee environment may include one or more data privacy pipelines through which data can be ingested, fused, derived and / or purified to generate collaborative data. The data privacy pipeline may be provided as a distributed computing or cloud computing service (cloud service) implemented in the trustee environment and can be started and shut down as needed. In some embodiments, the tenant who provides data to the data privacy pipeline cannot access the pipeline. Instead, the pipeline outputs collaborative data subject to constraints provided by one or more tenants. Depending on the specified constraints, the collaborative data can be output from the trustee environment (for example, because it has been purified according to the specified constraints) and / or can be stored in the trustee environment and shielded by the trustee environment. Shielded collaborative data can be queried to derive collaborative intelligence subject to configurable constraints (for example, without exposing shielded collaborative data).

[0025] In general, a data privacy pipeline can accept data provided by one or more tenants. Initially, the data privacy pipeline can determine whether the input data is federated data based on a contract or other tenant agreement with one or more tenants. Data determined to be federated data can be ingested, and data determined not to be federated data can be discarded. In this regard, federated data refers to any shared data (e.g., c specified or otherwise identified in a tenant agreement with one or more tenants) that is specified to be ingested when generating collaborative data. The ingested data may include data from multiple sources, so the data privacy pipeline may fuse data from multiple sources based on the calculations and constraints specified in the tenant agreement. For example, constrained data fusion may implement one or more constraints to combine the ingested data to form fused federated data in any number of ways, including using one or more join operations (e.g., left, right, inner, outer, reverse), custom joins (e.g., via imperative scripts), data appends, normalization operations, some combination of the foregoing, and the like.

[0026] In some embodiments, the data privacy pipeline can perform constrained calculations to generate derived federated data. Constrained calculations can obtain data from a source (e.g., ingested data, fused federated data) and perform any number of specified calculations (e.g., arithmetic operations, aggregation, summary, filtering, sorting, delimiting). A simple example of a constrained calculation is to calculate the average age per city, where the calculation is performed for the city only if the underlying data set includes entries for at least five people in the city. Additionally or alternatively, the data privacy pipeline can perform data cleansing to generate collaborative data that implements constraints on storage, access, accuracy, and the like. For example, data cleansing can implement constraints specified in a tenant agreement that specify whether collaborative data should be shielded (e.g., stored in a trustee environment), whether collaborative data can be exported, whether the exported collaborative data should be restricted (e.g., not exporting emails, credit card numbers, portions of the foregoing items), and the like. Like this, the data privacy pipeline can generate collaborative data from data provided by one or more tenants and provide agreed access to the collaborative data without sharing the underlying raw data with all tenants.

[0027] In some embodiments, the use and generation of collaborative data in a trustee environment subject to configurable constraints may be monitored and coordinated to enable constrained computation and querying. At a high level, constraints may be provided through a user interface to enable tenants (e.g., customers, businesses, users) to specify desired computations and constraints on the use and access of their data in a trustee environment, including eligible data sources and how their data may be processed or shared. Any number of various types of constraints may be implemented, including data access constraints, data processing constraints, data aggregation constraints, and data cleansing constraints.

[0028] For example, data access constraints may be specified to allow or prohibit access (e.g., for specific users, accounts, organizations). In some embodiments, the specified constraints may be universal, such that the constraints apply to all potential data consumers (e.g., only access to the average age is allowed regardless of the data consumer). In some embodiments, the specified constraints may apply to specified users, accounts, organizations, etc. (e.g., group A is not allowed to access salary data, but group B is allowed to access salary data). In general, tenants may specify the following constraints: constraints that limit how the tenant's data may be merged with a specified data set or portion thereof, constraints that limit the mode of reading data from the tenant's data (e.g., specifying horizontal filtering to be applied to the tenant's data), constraints that limit the size of the ingested data (e.g., specifying storage limits, subsampling of the tenant's data, vertical filtering to be applied to the tenant's data), constraints that limit the mode of collaborative data that may be output, constraints that limit ownership of collaborative data, constraints that limit whether collaborative data should be open, encrypted, or shielded (e.g., stored in a trustee environment), and the like.

[0029] In some embodiments, various types of data processing constraints can be specified, such as constraints that specify which operations can be performed (e.g., allowable and restricted calculations, binary checks), constraints that limit comparison precision (e.g., for numeric data, geographic data, date and time data), constraints that limit accumulation precision (e.g., for geographic data, numeric data, date or time data), constraints that limit location boundary precision (e.g., limiting allowable geo-fence determination to a specific grid, a minimum geographic partition such as a field, county, city, state or country, etc.), and other precision and / or data processing requirements.

[0030] Additionally or alternatively, one or more data aggregation constraints may be specified, such as a constraint requiring a minimum amount of aggregation (e.g., at least N rows or distinct field values), a constraint requiring certain statistical distribution conditions to be valid (e.g., a minimum standard deviation), a constraint limiting the allowed aggregation functions (e.g., allowing min, max, average, but not percentiles), to name a few.

[0031] In some embodiments, one or more data cleansing constraints can be specified, such as a constraint requiring cleansing of personally identifiable information (e.g., removing email, name, ID, credit card number), a constraint requiring reduced precision cleansing (e.g., reducing numeric, date and time, and / or geographic precision), a constraint requiring cleansing of values ​​from specific fields (which may require tracking transformations applied in the data privacy pipeline), a constraint requiring custom cleansing (e.g., requiring execution of one or more custom and / or third-party cleansing scripts), a constraint requiring data masking (e.g., outputting certain data, such as phone numbers, credit cards, dates, but masking portions of the number), and the like.

[0032] Additionally or alternatively, for the constraints listed above, one or more constraints may be specified that limit the number of queries and / or data accesses that are permissible per unit of time (e.g., minutes, hours, days). Such constraints may operate to reduce the risk of brute force attempts to reverse engineer shielded data by asking a slightly different set of questions within a relatively small time window. In general, one or more custom constraints may be specified, such as constraints that require a certain specified property to match certain specified criteria. These and other types of constraints are contemplated within the present disclosure.

[0033] In some embodiments, the constraint manager can monitor and coordinate data flows, generation and access subject to specified constraints. For example, the constraint manager can communicate with various components in the trustee environment (e.g., data privacy pipeline) to implement constraints, which can be maintained in a contract database accessible to the constraint manager. In some embodiments, a component can issue a request to the constraint manager to obtain permission to execute a specific command, function call or other executable logic unit. The constraint manager can evaluate the request and grant or deny permission. In some cases, permission can be granted subject to one or more conditions corresponding to one or more constraints in the constraint. As a non-limiting example, some possible conditions that can be implemented include operations requiring shifting, filtering or reshaping data (e.g., the application of comparison constraints, such as only allowing mergers with a certain precision), requiring one or more executable logic units to be replaced with one or more constrained executable logic units (e.g., commands or operations) (e.g., replacing the average value with a constrained average value), etc.

[0034] In general, constraints can be checked, verified, or otherwise enforced at any time or step (e.g., in association with any part of the data privacy pipeline, constrained queries). Therefore, the corresponding functionality of enforcing constraints can be applied at any step or multiple steps. In some embodiments, the enforcement of certain constraints can be assigned to certain parts of the data privacy pipeline (e.g., applying data access constraints during ingestion, applying processing and aggregation constraints during data fusion and / or constrained computation, and applying cleansing constraints during data cleansing). In another example, specific data access constraints can be applied during data fusion (e.g., only passing data for patients participating in at least five different studies). These are merely examples, and any suitable constraint enforcement system can be implemented within the present disclosure.

[0035] Enforcing constraints (e.g., precision or aggregation constraints) on a particular executable logic unit (e.g., for a specified calculation, a requested operation) can result in any number of scenarios. In one example, a particular executable logic unit can be completely rejected. In another example, a particular executable logic unit can be allowed, but the results are filtered (e.g., no value is returned for a particular row or data entry). In yet another example, a particular executable logic unit can be allowed, but the results will be changed (e.g., precision is reduced, questions are answered with errors). These and other variations can be implemented.

[0036] When constraints are applied to generate collaborative data, any combination of patterns, constraints and / or attribute metadata can be associated with collaborative data, intermediate data or other data for obtaining collaborative data. In general, constraints can be enforced across multiple steps and calculations. Like this, in some embodiments, the constraints applicable and / or satisfied for each step can be tracked and / or associated with the data generated by a given step. Taking aggregation constraints as an example, once the aggregation constraints have been fulfilled in a specific step, the subsequent steps no longer need to consider the constraints. In another example where different constraints have been specified for different data sets to be merged, the merge operation may only need to apply stricter constraints. In general, when data flows through the data privacy pipeline, appropriate constraint allocation or combination can be applied and / or tracked. This tracking can facilitate verification of whether specific constraints have been applied to specific data. Therefore, when constraints are applied and data are generated, corresponding patterns, applicable or satisfied constraints, and / or attribute metadata indicating ownership or willingness can be associated with data sets or corresponding entries, rows, fields or other elements of data. In some embodiments, depending on applicable constraints, any intermediate data used to derive the collaborative data (e.g., ingested data, fused joint data, derived joint data) may be deleted, and the collaborative data may be stored in the trustee environment and / or provided as output.

[0037] In some embodiments, constrained queries can be applied to allow data consumers to query collaborative data subject to configurable constraints in a trustee environment. At a high level, constrained queries can operate as a search engine that allows data consumers to access collaborative data or derive collaborative intelligence from it without exposing the underlying raw data provided by the tenant or collaborative data shielded by the trustee environment. Constraints can be applied in response to queries in any number of ways, including reformatting the query before execution, applying constraints after query execution, constraining query execution that meets the conditions, applying access constraints before execution, and the like.

[0038] As a non-limiting example, an issued query may be validated against a specified aggregate constraint by ensuring that the query contains at least one aggregate element and ensuring that the aggregate element(s) are consistent with the aggregate constraint. In another example, an execution plan corresponding to the issued query may be executed, and the results may be validated against the aggregate constraint and / or aggregate element(s) of the query (e.g., confirming that the results correspond to the requested number of different rows, fields, statistical distributions). In some embodiments, constraints may be enforced on corresponding elements of the query by modifying the element based on the constraint (e.g., to limit the corresponding number of different rows, fields, statistical distributions), by executing the modified element before other elements of the query, some combination of the foregoing, and the like.

[0039] As background, a query is not usually an executable code. In order to execute a query, it is usually converted into an executable execution plan. In some embodiments, in order to enforce constraints on a received query, the query can be parsed into a corresponding execution tree, which includes a hierarchical arrangement of executable logic units that implements the query when executed. Applicable constraints can be accessed, and the executable logic units can be verified for the constraints. In some embodiments, if one or more executable logic units are not allowed, the query can be effectively reformatted by changing one or more executable logic units in the executable logic units based on one or more constraints. More specifically, the execution tree corresponding to the query can be reformatted into a constrained execution tree by traversing the execution tree and replacing the executable logic units inconsistent with the specific constraints with custom executable logic units consistent with the constraints. Additionally or alternatively, one or more executable logic units can be added to the constrained execution tree to enforce constraints (e.g., precision constraints) on the output. These are merely examples, and any suitable technology for generating a constrained execution tree can be implemented.

[0040] In general, the executable logic unit of the execution tree can be verified for the corresponding constraint context, which includes applicable access constraints and runtime information, such as information identifying the data consumer of the request that issued the query, information identifying the applicable tenant agreement, information identifying the target collaborative data to be operated on, etc. The verification of the executable logic unit may involve the verification of the constituent commands or operations, the verification of one or more constituent parameters, and / or the consideration of other parts of the execution tree. The verification of the executable logic unit can produce multiple possible results. For example, the executable logic unit may be allowed (for example, the executable logic unit may be copied to the constrained execution tree), the executable logic unit may not be allowed (for example, the query may not be allowed at all), or the executable logic unit may be allowed but with changes (for example, the corresponding constrained executable logic unit is copied to the constrained execution tree). In some embodiments, the generated constrained execution tree is converted into the language used by the trustee environment. The generated execution tree can be executed (for example, by traversing and executing the hierarchy of the executable logic units of the tree), and the result can be returned to the requested data consumer.

[0041] As such, using the implementations described herein, users can efficiently and effectively share data through a data trustee that allows them to derive collaborative intelligence while ensuring data privacy and providing configurable control and access to shared data.

[0042] Example Collaborative Intelligence Environment

[0043] Now refer to Figure 1 , a block diagram of an example collaborative intelligence environment 100 suitable for implementing embodiments of the present invention is shown. In general, the collaborative intelligence environment 100 is suitable for generating collaborative intelligence and, among other things, facilitating constraint computation and constraint querying. The collaborative intelligence environment 100 or portions thereof (e.g., the data trustee environment 110) may, but need not, be hosted in a distributed computing environment (such as described below with respect to Fig.11 Any or all of the components of the collaborative intelligent environment 100 may be implemented as any type of computing device or some portion thereof. For example, in one embodiment, the tenant devices 101a to 101n and the data consumer devices 103a to 103n may each be a computing device, such as the following reference Fig.12The computing device 1200 described. Further, the data trustee environment 110 can be implemented using one or more such computing devices. In embodiments, these devices can be any combination of personal computers (PCs), laptops, workstations, servers, mobile computing devices, PDAs, cellular phones, etc. The components of the collaborative intelligent environment 100 can communicate with each other via one or more networks, which can include but are not limited to one or more local area networks (LANs) and / or wide area networks (WANs). Such networking environments are common in offices, enterprise-wide computer networks, intranets, and the Internet.

[0044] The collaborative intelligent environment 100 includes a data trustee environment 110, which is capable of deriving collaborative data and / or collaborative intelligence from raw data subject to configurable constraints provided by a data owner or provider (e.g., a tenant) without sharing the raw data. In general, any number of tenants can input their data (e.g., data sets 105a to 105n) into the data trustee environment 110 and specify one or more constraints (e.g., from one of the tenant devices 101a to 101n). The data trustee environment 110 can derive collaborative data (e.g., collaborative data sets 107a to 107n, shielded collaborative data set 160) based on one or more constraints. Any number of data consumers (e.g., one of the operating data consumer devices 103a to 103n) can issue queries to the shielded collaborative data set 160, and the data trustee environment 110 can derive collaborative intelligence subject to one or more constraints from the shielded collaborative data set 160. In some cases, the authorized data consumer (e.g., as may be defined by one or more of the constraints) may be the same individual or entity that owns or provides the original data (e.g., one or more data sets 105a-105n) or owns the derived collaborative data (e.g., masked collaborative data set 160). In some cases, the authorized data consumer may be some other individual or entity.

[0045] exist Figure 1In the embodiment shown in , the data trustee environment 110 includes a constraint manager 115. At a high level, a tenant seeking to share data can provide one or more desired calculations and constraints (which can be embodied in a contractual agreement) to the constraint manager 115 through a user interface of the data trustee environment 110. The user interface enables the tenant to specify the desired calculations and constraints that will control the use of the tenant's data in the data trustee environment 110, including eligible data sources (e.g., one or more data sets 105a to 105n) and how the tenant's data can be processed or shared. Various types of constraints can be implemented, including data access constraints, data processing constraints, data aggregation constraints, data cleansing constraints, some combination thereof, and the like. The specified calculations and constraints and other features of the tenant agreement can be stored in a contract database (not shown) accessible to the constraint manager 115.

[0046] exist Figure 1 In the embodiment shown in , the data trustee environment 110 includes a data privacy pipeline 120. At a high level, the data privacy pipeline 120 can accept data from one or more specified sources (e.g., one or more data sets 105a to 105n). Based on one or more specified calculations and / or constraints, the data can be ingested, fused, derived, and / or cleansed to generate collaborative data (e.g., one or more of the collaborative data sets 107a to 107n, the masked collaborative data set 160). The data privacy pipeline 120 can be provided as a distributed computing or cloud computing service (cloud service) implemented in the trustee environment 110, and can be started and shut down as needed. In some embodiments, the tenant who provides data into the data privacy pipeline 120 cannot access the pipeline. Instead, the pipeline outputs collaborative data subject to applicable constraints. Depending on the specified constraints, the collaborative data may be output from the data trustee environment 110 as one or more collaborative data sets 107a to 107n (e.g., because it has been cleansed according to the specified constraints) and / or may be masked (e.g., stored as a masked collaborative data set 160) in the data trustee environment 110. As explained in more detail below, the collaborative data set 160 may be queried to derive collaborative intelligence subject to configurable constraints.

[0047] exist Figure 1In the embodiment shown in , the data privacy pipeline 120 includes an ingestion component 125 (producing ingested data 130), a constrained fusion component 135 (producing fused joint data 140), a constrained computation component 145 (producing derived joint data 150), and a cleansing component 155 (producing collaborative data sets 107a to 107n and 160). Initially, one or more data sets 105a to 105 may be provided to the data privacy pipeline 120 (e.g., through a user interface, a programming interface, or some other interface of the data trustee environment). The ingestion component 125 may determine whether the input data or a portion thereof is joint data based on a contract or other tenant agreement. For example, the input data or a portion thereof may be identified in some manner, and the ingestion component 125 may communicate with the constraint manager 115 to confirm whether the identified data is joint data based on the tenant agreement represented in the contract database. Data determined to be joint data may be stored as the ingested data 130, and data determined not to be joint data may be discarded.

[0048] The ingested data may include data from multiple sources, so the constrained fusion component 135 can fuse the ingested data from multiple sources according to the calculations and constraints specified in the tenant agreement. For example, the constrained fusion component 135 can communicate with the constraint manager 115 to obtain, verify, or request a specified fusion operation according to the tenant agreement represented in the contract database. As a non-limiting example, the constrained fusion component 135 can implement one or more constraints to combine the ingested data (e.g., ingested data 130) to form fused joint data (e.g., fused joint data 140) in any number of ways, including using one or more join operations (e.g., left, right, inner, outer, reverse), custom joins (e.g., via imperative scripts), data appends, normalization operations, some combination thereof, and the like.

[0049] In general, the constrained computation component 145 can perform constrained computations (e.g., on the ingested data 130, the fused joint data 140) to generate derived joint data (e.g., derived joint data 150). The constrained computations can include any number of specified computations (e.g., arithmetic operations, aggregations, summaries, filtering, sorting, delimiting). In general, the constrained computation component 145 can communicate with the constraint manager 115 to obtain, verify, or request specified computations based on the tenant agreement represented in the contract database. As a simple example, multiple retailers may agree to expose average sales data, so the corresponding computations can include averaging. A simple example of a constrained computation is to calculate the average age per city, where the computation is performed on the city only if the underlying data set includes entries for at least five people in the city. These are merely examples, and any type of computation and / or constraints can be implemented.

[0050] In some embodiments, the cleansing component 155 can perform data cleansing (e.g., on the derived federated data 150) to generate collaborative data (e.g., one or more of the collaborative data sets 107a to 107n, the masked collaborative data set 160) in a manner that implements constraints for storage, access, accuracy, etc. For example, the cleansing component 155 can communicate with the constraint manager 115 to obtain, verify, or request a specified cleansing operation in accordance with the tenant agreement represented in the contract database. As such, the cleansing component 155 can implement the constraints specified in the tenant agreement, which specify whether the collaborative data should be masked (e.g., stored in the data trustee environment 110 as the masked collaborative data set 160), whether the collaborative data can be exported (e.g., as one or more of the collaborative data sets 107a to 107n), whether the exported collaborative data should be restricted (e.g., not exporting emails, credit card numbers, portions of the foregoing), some combination of the foregoing, etc. In some embodiments, any or all of the intermediate data used to derive the collaborative data (e.g., ingested data, fused federated data, derived federated data) can be deleted, for example, in association with shutting down the data privacy pipeline 120. As such, the data privacy pipeline 120 may generate collaborative data from data provided by one or more tenants.

[0051] As described above, the constraint manager 115 can monitor and coordinate the use and generation of collaborative data subject to one or more specified constraints. Additionally or alternatively, the constraint manager 115 can monitor and coordinate access to collaborative data subject to constraints. In general, the constraint manager 115 can communicate with various components in the data trustee environment 110 and / or the data privacy pipeline 120 to implement specified calculations and / or constraints, which can be maintained in a contract database accessible to the constraint manager 115. In some embodiments, a component can issue a request to the constraint manager 115 to obtain permission to execute a specific command, function call, or other executable logic unit. The constraint manager 115 can evaluate the request and grant or deny permission. In some cases, permission may be granted subject to one or more conditions corresponding to one or more constraints in the constraint. As non-limiting examples, some possible conditions that may be implemented include operations requiring shifting, filtering, or reshaping of data (e.g., the application of comparison constraints, such as only allowing merges with a certain precision), requiring the replacement of one or more executable logic units (e.g., commands or operations) with one or more constrained executable logic units (e.g., replacing an average with a constrained average), and the like.

[0052] In general, constraints may be checked, verified, or otherwise enforced at any time or step (e.g., in association with any component of the data privacy pipeline 120, the data trustee environment 110). Thus, the corresponding functionality for enforcing constraints may be applied at any step or multiple steps. In some embodiments, the enforcement of certain constraints may be assigned to certain components of the data privacy pipeline 120 (e.g., the ingestion component 125 applies data access constraints, the constrained fusion component 135 and / or the constrained computation component 145 applies processing and aggregation constraints, and the cleansing component 155 applies cleansing constraints). In another example, specific data access constraints (e.g., only passing data for patients participating in at least five different studies) may be applied by the constrained fusion component 135. These are merely examples, and any suitable constraint enforcement regime may be implemented within the present disclosure.

[0053] In some embodiments, by communicating, indicating, or otherwise facilitating any number of treatments, the constraint manager 115 can enforce constraints (e.g., precision or aggregation constraints) on specific executable logic units (e.g., for specified calculations, requested operations). In one example, the constraint manager 115 can completely reject a specific executable logic unit. In another example, the constraint manager 115 can allow a specific executable logic unit, but require filtering the results (e.g., not returning a value for a specific row or data entry). In yet another example, the constraint manager 115 can allow a specific executable logic unit, but require changing the results (e.g., reduced precision, questions are answered as having errors). These and other variations can be implemented.

[0054] When constraints are applied to generate collaborative data (e.g., collaborative data sets 107a to 107n, masked collaborative data set 160), any combination of patterns, constraints, and / or attribute metadata may be associated with collaborative data, intermediate data used to obtain collaborative data (e.g., ingested data 130, fused joint data 140, derived joint data 150), etc. In general, constraints may be enforced across multiple steps and calculations. As such, in some embodiments, the constraints applicable and / or satisfied for each step may be tracked and / or associated with the data generated by a given component of the data privacy pipeline 120. Taking an aggregation constraint as an example, once a particular component of the data privacy pipeline 120 fulfills an aggregation constraint, downstream components no longer need to consider the constraint. In another example where different constraints have been specified for different data sets to be merged, the merge operation may only require the application of a more stringent constraint. In general, as data flows through the data privacy pipeline 120, appropriate constraint assignments or combinations may be applied and / or tracked. Such tracking may facilitate verification of whether a particular constraint has been applied to a particular data. Thus, when constraints are applied and data is generated, corresponding schemas, applicable or satisfied constraints, and / or attribute metadata indicating ownership or intent of the data may be associated with the data set or corresponding entries, rows, fields, or other elements of the data. In general, applicable or satisfied constraints and / or attribute metadata may be generated based on a tenant agreement represented in a contract database (e.g., by communicating with a constraint manager 115). In some embodiments, depending on applicable constraints, any or all intermediate data used to obtain collaborative data (e.g., ingested data 130, fused federated data 140, derived federated data 150) may be deleted, and the collaborative data may be stored in the data trustee environment 110 as a masked collaborative data set 160 and / or output as one or more collaborative data sets 107a to 107n.

[0055] In some embodiments, the data trustee environment 110 includes a constrained query component 170 that can apply constrained queries to allow a data consumer (e.g., operating one of the data consumer devices 103a to 103n) to query collaborative data (e.g., masked collaborative data set 160) in the data trustee environment 110 subject to one or more specified constraints. At a high level, the constrained query component 170 can operate as a search engine that allows a data consumer to access or derive collaborative intelligence from the masked collaborative data set 160 without exposing the original data (e.g., one or more data sets 105a to 105n) provided by the tenant, the intermediate data used to generate the masked collaborative data set 160 (e.g., the ingested data 10, the fused federated data 140, the derived federated data 150), and / or the masked collaborative data set 160. In general, the constrained query component 170 can communicate with the constraint manager 115 to obtain, verify, or request specified operations in accordance with the tenant agreement represented in the contract database. The constrained query component 170 can facilitate the enforcement of constraints in response to queries in a variety of ways, including reformatting the query before execution, applying constraints after query execution, constraining eligible query execution (e.g., only allowing a set of whitelisted queries), applying access constraints before execution, and the like.

[0056] Now turn to Figure 2 , Figure 2 is a block diagram of an example constrained query component 200 according to embodiments described herein. The constrained query component 200 may be used with Figure 1 . At a high level, the constrained query component 200 can operate as a search engine, enabling data consumers to query collaborative data and derive collaborative intelligence therefrom, subject to one or more constraints specified in the corresponding tenant agreement. As background, queries are typically not executable code. In order to execute a query, the query is typically converted into an execution tree, which serves as the basis for an executable execution plan. In general, the constrained query component 200 can enforce constraints or facilitate constraint enforcement by reformatting the execution tree corresponding to the received query to account for any applicable constraints before execution. In a simple example, a constraint may allow a query on compensating data, but the results must be rounded. As such, before execution, the query and / or its corresponding execution tree can be reformatted so that any returned search results account for applicable constraints. Figure 1 In the embodiment shown in , constrained query component 200 includes access constraint component 220, query parser 230, constraint query formatter 240, conversion component 250, and execution component 260. This configuration is merely an example, and other configurations having similar or different functionality may be implemented according to the present disclosure.

[0057] At a high level, the constrained query component 200 can receive a data consumer (e.g., an operator) Figure 1 The query 210 is issued by one of the data consuming devices 103a to 103n, the query request is based on the collaborative data (eg Figure 1 Query 210 may take any suitable form or query language and may include one or more requested operations on collaborative data. In some embodiments, query 210 may specify or otherwise be associated with runtime information, such as information identifying a data consumer that issued the query, information identifying an applicable tenant agreement, information identifying target collaborative data to be operated on, and the like.

[0058] In some embodiments, access constraint component 220 may use runtime information associated with query 210 to trigger the lookup and enforcement of applicable data access constraints (e.g., via a query associated with query 210). Figure 1 15). For example, the access constraint component 220 can verify the query 210 against the corresponding constraint context, which includes applicable data access constraints and runtime information associated with the query 210. Generally speaking, in a scenario where the data consumer is not authorized to access the collaborative data set, the target collaborative data within the collaborative data set (e.g., data of a particular row), or the requested collaborative intelligence of a particular type to be derived, the access constraint component 220 can deny the request. In this case, the access constraint component 220 can return a notification to the issuing data consumer, notifying the data consumer that the requested query is denied. If the requested access is determined to be authorized and / or consistent with the applicable data access constraints, the query 210 can be passed to the query parser 230.

[0059] In general, query parser 230 may parse query 210 and generate a corresponding execution tree 235. At a high level, execution tree 235 includes a hierarchical arrangement of executable logic units that, when executed, implement query 210. The executable logic units may include any suitable arrangement and combination of commands, operations, function calls, etc. Constraint query formatter 240 may access applicable constraints (e.g., via a query with Figure 1 15) and can validate the executable logic units of execution tree 235 against the constraints. In some embodiments, if one or more of the executable logic units are not allowed, one or more executable logic units can be added, removed, and / or altered based on the one or more constraints to effectively reformat query 210.

[0060] More specifically, the constraint query formatter 240 may reformat the execution tree 235 into a constrained execution tree 245 by traversing the execution tree 235 and replacing executable logic units that are inconsistent with a particular constraint with custom executable logic units that are consistent with the constraint. Additionally or alternatively, the constraint query formatter 240 may add or remove one or more executable logic units to enforce constraints (such as precision constraints) on the output. In general, the constraint query formatter 240 may verify the executable logic units of the execution tree 235 against a corresponding constraint context, which includes applicable constraints and runtime information associated with the query 210. Such checking may involve verification of constituent commands or operations, verification of one or more constituent parameters, and / or consideration of other portions of the execution tree 235, and may produce many possible results. For example, an executable logic unit may be allowed (e.g., the executable logic unit may be copied into constrained execution tree 245), an executable logic unit may not be allowed (e.g., query 210 may not be allowed at all), or an executable logic unit may be allowed but with changes (e.g., copying the corresponding constrained executable logic unit into constrained execution tree 245). These are merely examples, and other variations are contemplated within the present disclosure.

[0061] As such, constraint query formatter 240 may evaluate each executable logic unit against the constraints, add or remove executable logic units, and / or replace one or more executable logic units that are inconsistent with the constraints with custom executable logic units that incorporate and / or apply the constraints. The mapping between executable logic units and custom executable logic units and / or executable logic units corresponding to one or more constraints (e.g., rule lists) may be retrieved, accessed, and / or maintained in any suitable manner (e.g., stored locally, via a database associated with a query query, or otherwise). Figure 1 The mapping may be one-to-one, one-to-many, or many-to-one.

[0062] In some embodiments, the received query may not be a query using the target collaborative dataset (e.g. Figure 1245) is a query language used by the query operator 210 to query the query 210. In this way, the conversion component 250 can convert the constrained execution tree 245 from the first query language to the second query language. That is, the conversion component can convert the constrained execution tree 245 into a converted constrained execution tree 255. Any suitable query language can be implemented (e.g., SQL, SparkQL, Kusto query language, C# Linq). In some embodiments, the constrained execution tree 245 and / or the converted constrained execution tree 255 can be executed to test for failure, and failure may cause a rejection of a particular execution, a set of executable logic units, the entire query 210, etc.

[0063] The resulting execution tree (e.g., constrained execution tree 245 and / or transformed constrained execution tree 255, as appropriate) can be passed to execution component 260 for execution (e.g., execution of the corresponding execution plan). Generally, such execution operates to derive collaborative intelligence 270 from the collaborative data. In some embodiments, collaborative intelligence 270 is returned to the requesting data consumer as is. In some embodiments, one or more constraints can be additionally or alternatively enforced on collaborative intelligence 270 prior to transmission to the requesting data consumer.

[0064] As a non-limiting example, assume that multiple retailers have agreed to expose sales data that includes some sensitive customer information that should not be exposed pursuant to a particular tenant agreement. In this example, the tenant agreement specifies multiple constraints, including a requirement for at least 20 unique customers per aggregation, that aggregations must span at least 48 hours, that aggregations cannot be performed by userid, that userids are not exported, and that numerical results are rounded to the nearest two digits. Also assume that the tenant agreement allows the data consumer to derive the average amount of money spent by each customer per week at each store. Figure 3A An example of a corresponding query in Structured Query Language (SQL) 310 is illustrated. This query language is by way of example only, and any suitable query structure may be implemented.

[0065] Query 310 may be parsed and converted into a corresponding execution tree (e.g., by Figure 2 Query parser 230). Figure 3B The diagram shows Figure 3A310. In general, in the query execution tree, each executable logic unit can receive data from the previous executable logic unit and one or more parameters for transforming the data. When the execution tree 320 is executed, the data is passed from the bottom to the top along the left branch of the execution tree 320. As the data is passed, each executable logic unit applies one or more associated commands or operations. As will be appreciated by those skilled in the art, the execution tree 320 includes a hierarchical arrangement of executable logic units that, when executed, will implement the query 310.

[0066] To take into account applicable constraints, the execution tree 320 may be transformed into Figure 4A The constrained execution tree 410 (e.g., by Figure 2 Constraint query formatter 240). Figure 3B The execution tree 320 and Figure 4A The differences between the constrained execution trees 410 are illustrated by the boxes drawn around the different elements. For example, the constrained execution tree 410 includes a rounding operation 415 that implements the above constraint, where the numeric result must be rounded to the nearest two digits. In another example, the constrained execution tree 410 includes a filtering operation 425 that implements the above constraint, where the aggregation must include data for at least 20 unique customers. This configuration of the constrained execution tree 410 is merely an example, and any suitable configuration may be implemented. For purposes of illustration, Figure 4B An example of a corresponding query 420 corresponding to the constrained execution tree 410 is illustrated. As will be appreciated, query 420 includes additional elements not present in query 310 that are used to enforce the above-described example constraints. Constrained execution tree 410 can be executed by traversing and executing the hierarchy of executable logic units of the tree from bottom to top along the left branch, as will be appreciated by one of ordinary skill in the art. As such, constrained execution tree 410 can be executed to derive collaborative intelligence, and the collaborative intelligence can be returned to the requesting data consumer.

[0067] Example Flowchart

[0068] Reference Figures 5 to 10 , a flow chart is provided illustrating various methods related to the generation of collaborative intelligence. The methods may be performed using the collaborative intelligence environment described herein. In an embodiment, one or more computer storage media having computer executable instructions embodied thereon, when executed by one or more processors, may cause the one or more processors to perform the method in an automatic upgrade system.

[0069] Now turn to Figure 5 , Figure 5A flow chart illustrating a method 500 for generating collaborative data is provided. Initially, at box 510, data from multiple input data sets provided by multiple tenants is ingested based on a tenant agreement between the multiple tenants to generate multiple sets of ingested data. At box 520, the multiple sets of ingested data are fused based on the tenant agreement to generate fused joint data. At box 530, at least one constrained computation is performed on the fused joint data based on the tenant agreement to generate derived joint data. At box 540, at least one cleansing operation is performed on the derived joint data based on the tenant agreement to generate collaborative data. The collaborative data includes an exposable portion derived from the input data set that is allowed to be shared and a restricted portion derived from the input data set that is not allowed to be shared.

[0070] Now turn to Figure 6 , Figure 6 A flow chart illustrating a method 600 for generating collaborative data is provided. Initially, at block 610, multiple sets of data are fused based on at least one specified calculation or constraint to generate fused joint data. At block 620, at least one constrained calculation is performed on the fused joint data based on at least one specified calculation or constraint to generate derived joint data. At block 630, at least one cleansing operation is performed on the derived joint data based on at least one specified calculation or constraint to generate collaborative data. The collaborative data includes exposed portions derived from multiple data sets that are allowed to be shared and restricted portions derived from multiple data sets that are not allowed to be shared. At block 640, access to the exposed portions of the collaborative data is provided based on at least one specified calculation or constraint.

[0071] Now turn to Figure 7 , Figure 7 A flowchart illustrating a method 700 for providing constrained computing for collaborative data in a data trustee environment is provided. Initially, at box 710, a request is received for permission to execute a requested executable logic unit associated with generating collaborative data from multiple input data sets provided by multiple tenants in a data trustee environment. At box 720, in response to receiving the request, at least one constraint associated with the collaborative data is accessed. At box 730, the request is resolved based on the at least one constraint, so that the collaborative data can be generated. The collaborative data includes an exposable portion that is allowed to be shared and a restricted portion that is not allowed to be shared. The data trustee environment is configured to provide multiple tenants with access to the exposable portion of the collaborative data without exposing the restricted portion.

[0072] Now turn to Figure 8 , Figure 8A flow chart is provided that illustrates a method 800 for providing constrained access to collaborative data in a data trustee environment. Initially, at box 810, a request is received for permission to execute a requested executable logic unit that is associated with access to collaborative data. The collaborative data is based on multiple input data sets provided by multiple tenants. The collaborative data includes an exposable portion that is derived from the multiple input data sets and is allowed to be shared. The collaborative data includes a restricted portion that is derived from the multiple input data sets and is not allowed to be shared. At box 820, in response to receiving the request, at least one constraint associated with the collaborative data is accessed. At box 830, access to the collaborative data is enabled by decomposing the request based on the at least one constraint.

[0073] Now turn to Fig. 9 , Fig. 9 A flow chart illustrating a constraint query method 900 is provided. Initially, in box 910, a query is received from a data consumer to generate collaborative intelligence from masked collaborative data. The masked collaborative data is generated from multiple input data sets provided by multiple tenants. The masked collaborative data includes an exposable portion that is allowed to be shared and a restricted portion that is not allowed to be shared. In box 920, a request is issued for permission to execute at least one executable logic unit corresponding to the query. In box 930, a response to the request for decomposition based on one or more constraints specified in a tenant agreement between multiple tenants is received. In box 940, collaborative intelligence is generated from the masked collaborative data based on the query and the response to the decomposition request.

[0074] Now turn to Fig.10 , Fig.10 A flow chart illustrating a constrained query method 1000 is provided. Initially, in box 1010, a query for masked collaborative data stored in a data trustee environment is received from a data consumer. The masked collaborative data is generated from multiple input data sets provided by multiple tenants. The masked collaborative data includes an exposeable portion derived from the multiple input data sets and allowed to be shared and a restricted portion derived from the input data sets and not allowed to be shared. In box 1020, the query is parsed into an execution tree. In box 1030, a constrained execution tree is generated based on the execution tree and one or more constraints specified in a tenant agreement between multiple tenants. In box 1040, collaborative intelligence is generated from the masked collaborative data based on the constrained execution tree.

[0075] Sample distributed computing environment

[0076] Now refer to Fig.11 , Fig.11 An example distributed computing environment 1100 is illustrated in which implementations of the present disclosure may be employed. Specifically, Fig.11 A high-level architecture of an example cloud computing platform 1110 is shown, which can host a collaborative intelligent environment or a portion thereof (e.g., a data trustee environment). It should be understood that this and other arrangements described herein are illustrated by way of example only. For example, as described above, many of the elements described herein can be implemented as discrete or distributed components or in combination with other components and in any suitable combination and position. Other arrangements and elements (e.g., machines, interfaces, functions, commands, and functional groupings) may be used in addition to or in place of the arrangements and elements shown.

[0077] The data center can support a distributed computing environment 1100, including a cloud computing platform 1110, a rack 1120, and a node 1130 (e.g., a computing device, a processing unit, or a blade) in the rack 1120. The collaborative intelligent environment and / or the data trustee environment can be implemented with a cloud computing platform 1110 that runs cloud services across different data centers and geographic regions. The cloud computing platform 1110 can implement a structure controller 1140 component for provisioning and managing resource allocation, deployment, upgrades, and management of cloud services. Typically, the cloud computing platform 1110 is used to store data or run service applications in a distributed manner. The cloud computing infrastructure 1110 in the data center can be configured to host and support the operation of endpoints of specific service applications. The cloud computing infrastructure 1110 can be a public cloud, a private cloud, or a dedicated cloud.

[0078] The node 1130 may be provided with a host 1150 (e.g., an operating system or runtime environment) on which a defined software stack is run. The node 1130 may also be configured to perform specialized functionality (e.g., a computing node or a storage node) within the cloud computing platform 1110. The node 1130 is allocated to run one or more parts of a tenant's service application. A tenant may refer to a customer utilizing the resources of the cloud computing platform 1110. The service application components of the cloud computing platform 1110 that support a particular tenant may be referred to as a tenant infrastructure or lease. The terms service application, application, or service are used interchangeably herein and are broadly any software or part of software that runs on top of a data center or accesses storage and computing device locations within a data center.

[0079] When more than one individual service application is supported by node 1130, node 1130 can be divided into virtual machines (e.g., virtual machine 1152 and virtual machine 1154). Physical machines can also run individual service applications at the same time. Virtual machines or physical machines can be configured as personalized computing environments, supported by resources 1160 (e.g., hardware resources and software resources) in cloud computing platform 1110. Considering that resources can be configured for specific service applications. Further, each service application can be divided into functional parts so that each functional part can run on a separate virtual machine. In cloud computing platform 1110, multiple servers can be used in a cluster to run service applications and perform data storage operations. Specifically, servers can perform data operations independently, but are exposed as a single device called a cluster. Each server in a cluster can be implemented as a node.

[0080] The client device 1180 can be linked to the service application in the cloud computing platform 1110. The client device 1180 can be any type of computing device, for example, Fig.11 The computing device 1100 described corresponds to the client device 1180. The client device 1180 can be configured to issue commands to the cloud computing platform 1110. In an embodiment, the client device 1180 can communicate with the service application through a virtual Internet Protocol (IP) and a load balancer or other component that directs communication requests to a designated endpoint in the cloud computing platform 1110. The components of the cloud computing platform 1110 can communicate with each other through a network (not shown), which can include, but is not limited to, one or more local area networks (LANs) and / or wide area networks (WANs).

[0081] Example operating environment

[0082] Having briefly described an overview of embodiments of the present invention, an example operating environment in which embodiments of the present invention may be implemented is described below in order to provide a general context for various aspects of the present invention. Fig.12 , an example operating environment for implementing embodiments of the invention is shown and generally designated as computing device 1200. The computing device 1200 is only one example of a suitable computing environment and is not intended to suggest any limitation as to the scope of use or functionality of the invention. Neither should the computing device 1200 be interpreted as having any dependency or requirement relating to any one or combination of components illustrated.

[0083] The present invention may be described in the general context of computer code or computer usable instructions, including computer executable instructions (such as program modules), which may be executed by a computer or other machine, such as a personal data assistant or other handheld device. In general, program modules, including routines, programs, objects, components, data structures, etc., refer to code that performs a particular task or implements a particular abstract data type. The present invention may be practiced in a variety of system configurations, including handheld devices, consumer electronics, general-purpose computers, more specialized computing devices, etc. The present invention may also be practiced in a distributed computing environment in which tasks are performed by remote processing devices that are linked through a communications network.

[0084] Reference Fig.12 , computing device 1200 includes bus 1210, which directly or indirectly couples the following devices: memory 1212, one or more processors 1214, one or more presentation components 1216, input / output ports 1218, input / output components 1220, and an illustrative power supply 1222. Bus 1210 represents a bus that can be one or more buses (such as an address bus, a data bus, or a combination thereof). For conceptual clarity, Fig.12 Each of the boxes is represented by lines, and other arrangements of the components and / or component functionality described are also contemplated. For example, we can consider a presentation component (such as a display device) to be an I / O component. Similarly, a processor has memory. We recognize that this is the nature of the art, and reiterate that Fig.12 The figures are merely illustrative of example computing devices that may be used in conjunction with one or more embodiments of the present invention. No distinction is made between categories such as "workstation," "server," "laptop," "handheld device," etc., as all of these are in the same category. Fig.12 within the scope of and reference to a “computing device” is contemplated.

[0085] The computing device 1200 typically includes a variety of computer-readable media. The computer-readable media can be any available media that can be accessed by the computing device 1200, and includes volatile and non-volatile media, removable and non-removable media. By way of example, and not limitation, computer-readable media can include computer storage media and communication media.

[0086] Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information (such as computer readable instructions, data structures, program modules or other data). Computer storage media include but are not limited to RAM, ROM, EEPROM, flash memory or other storage technology, CD-ROM, digital versatile disk (DVD) or other optical disk storage devices, magnetic cassettes, magnetic tape, magnetic disk storage devices or other magnetic storage devices, or any other medium that can be used to store the desired information and can be accessed by the computing device 1200. Computer storage media does not include the signal itself.

[0087] Communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal (such as a carrier wave or other transport mechanism), and includes any information delivery media. The term "modulated data signal" refers to a signal that has one or more of its characteristics or is set or changed in a manner with respect to encoding information in the signal. By way of example, and not limitation, communication media include wired media (such as a wired network or a direct wired connection) and wireless media (such as acoustic, RF, infrared and other wireless media). Combinations of any of the above should also be included within the scope of computer readable media.

[0088] Memory 1212 includes computer storage media in the form of volatile and / or non-volatile memory. Memory may be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid-state memory, hard drives, optical drives, and the like. Computing device 1200 includes one or more processors that read data from various entities such as memory 612 or I / O components 1220. Presentation component(s) 1216 present data indications to a user or other device. Exemplary presentation components include display devices, speakers, printing components, vibration components, and the like.

[0089] I / O ports 1218 allow computing device 1200 to be logically coupled to other devices, including I / O components 1220, some of which are built-in. Illustrative components include a microphone, joystick, game pad, satellite dish, scanner, printer, wireless device, etc.

[0090] With reference to the collaborative intelligent environment described herein, the embodiments described herein support constraint computation and / or constraint query. The components of the collaborative intelligent environment may be integrated components, including a hardware architecture and a software framework that support constraint computation and / or constraint query functionality within the collaborative intelligent system. The hardware architecture refers to the physical components and their interrelationships, and the software framework refers to software that provides functionality that can be implemented with hardware embodied on a device.

[0091] End-to-end software-based systems can operate within system components to operate computer hardware to provide system functionality. At a low level, a hardware processor executes instructions selected from a machine language (also referred to as machine code or native machine) instruction set for a given processor. The processor recognizes native machine instructions and performs corresponding low-level functions, such as functions related to logic, control, and memory operations. Low-level software written in machine code can provide more complex functionality for higher-level software. As used herein, computer executable instructions include any software, including low-level software written in machine code, high-level software (such as application software), and any combination thereof. In this regard, system components can manage resources and provide services for system functionality. Any other variations and combinations thereof are considered together with embodiments of the present invention.

[0092] By way of example, the collaborative intelligent system may include an API library including specifications for routines, data structures, object classes, and variables that may support interaction between the hardware architecture of the device and the software framework of the system intelligent system. These APIs include configuration specifications for the collaborative intelligent system so that different components therein may communicate with each other in the system intelligent system, as described herein.

[0093] The various components used herein have been identified, and it should be understood that in order to achieve the desired functionality within the scope of the present disclosure, any number of components and arrangements can be adopted. For example, for conceptual clarity, the components in the embodiment shown in the figure are shown with lines. Other arrangements of these and other components can also be realized. For example, although some components are described as single components, many elements in the elements described herein can be implemented as discrete or distributed components or in combination with other components, or in any suitable combination and position. Some elements can be omitted completely. In addition, the various functions described in this article as being performed by one or more entities can be performed by hardware, firmware and / or software, as described below. For example, various functions can be performed by a processor, which executes instructions stored in a memory. Therefore, in addition to or instead of the arrangements and elements shown, other arrangements and elements (such as machines, interfaces, functions, commands and functional groups) can be used.

[0094] The embodiments described in the following paragraphs may be combined with one or more of the specifically described alternatives. Specifically, the claimed embodiments may include references to more than one other embodiments in the alternatives. The claimed embodiments may specify additional limitations of the claimed subject matter.

[0095] To satisfy statutory requirements, the subject matter of the embodiments of the present invention is described herein with specificity. However, the description itself is not intended to limit the scope of this patent. Rather, the inventors have contemplated that the claimed subject matter may also be embodied in other ways, to include different steps or combinations of steps similar to those described herein, in conjunction with other present or future technologies. Furthermore, although the terms "step" and / or "box" may be used herein to refer to different elements of the method employed, these terms should not be interpreted as implying any particular order among or between the various steps disclosed herein, unless and except when the order of the individual steps is explicitly described.

[0096] For purposes of this disclosure, the word "including" has the same broad meaning as the word "comprising," and the word "access" includes "receiving," "referencing," or "retrieving." Further, the word "communicating" has the same broad meaning as the word "receiving" or "sending" supported by a software or hardware-based bus, receiver, or transmitter using the communication media described herein. In addition, words such as "a" and "an" include both the plural and the singular unless otherwise indicated. Thus, for example, when one or more features are present, the constraint of "feature" is satisfied. Similarly, the term "or" includes conjunctions, transitional conjunctions, and both (thus a or b includes: either a or b, and a and b).

[0097] For the purposes of the above detailed discussion, embodiments of the present invention are described with reference to a distributed computing environment. However, the distributed computing environment described herein is merely exemplary. Components may be configured to perform novel aspects of the embodiments, where the term "configured to" may refer to "programmed to" perform a specific task or implement a specific abstract data type using code. Further, while embodiments of the present invention may generally refer to a system intelligence environment and the schematics described herein, it is to be understood that the described techniques may be extended to other implementation contexts.

[0098] The embodiments of the present invention have been described with respect to specific embodiments, which are intended in all respects to be illustrative rather than restrictive. Alternative embodiments will become apparent to those skilled in the art to which the present invention pertains without departing from its scope.

[0099] From the above it will be seen that this invention is well adapted to attain all ends and purposes above described together with other advantages which are obvious and inherent to the structure.

[0100] It will be understood that certain features and subcombinations are of utility and may be employed without reference to other features or subcombinations. This is contemplated by and within the scope of the claims.

Claims

1. A data trustee environment, include: one or more hardware processors and a memory configured to provide computer program instructions to the one or more hardware processors; A constrained query component is configured to use the one or more hardware processors to: receiving, from a data consumer, a query for masked collaborative data stored in the data trustee environment, the masked collaborative data being generated in the data trustee environment from a plurality of input data sets provided by a plurality of tenants, wherein the data trustee environment is configured to prevent exposure of at least a restricted portion of the masked collaborative data to any tenant of the plurality of tenants and the data consumer based on a representation of a tenant agreement between the plurality of tenants stored in the data trustee environment; converting an execution tree representing the query into a constrained execution tree, the constrained execution tree implementing at least one of the one or more constraints specified in the tenant agreement; as well as Collaborative intelligence is generated from the masked collaborative data based on the constrained query tree.

2. The data trustee environment of claim 1, wherein the constrained query component is configured to reformat the query to comply with the one or more constraints prior to execution.

3. The data trustee environment of claim 1, wherein execution of the query generates a result, and wherein the constrained query component is configured to apply a particular constraint of the one or more constraints to the result after the query is executed. 4 . The data trustee environment of claim 1 , wherein the constrained query component is configured to constrain queries that meet execution conditions to a set of whitelist queries.

5. The data trustee environment of claim 1, wherein the constrained query component is configured to apply one or more access constraints specified in the tenant agreement based on runtime information associated with the query before executing the query.

6. The data trustee environment of claim 1, wherein the constrained query component is configured to: parse the query into the execution tree before converting the execution tree into the constrained query tree.

7. The data trustee environment of claim 1, wherein the constrained query component is configured to convert from a first query language associated with the query to a second query language associated with the masked collaborative data.

8. One or more computer storage media storing computer usable instructions that, when used by one or more computing devices, cause the one or more computing devices to perform operations, include: receiving a query from a data consumer to generate collaborative intelligence from masked collaborative data generated from a plurality of input data sets provided by a plurality of tenants, wherein the masked collaborative data at least includes a restricted portion that is not allowed to be shared with any tenant of the tenants or the data consumer based on a tenant agreement between the plurality of tenants; issuing a request for permission to execute an executable logic unit representing an execution tree of the query; receiving a response that decomposes the request based on one or more constraints specified in the tenant agreement; as well as The collaborative intelligence is generated from the masked collaborative data based on the query and decomposing the response to the request.

9. The one or more computer storage media of claim 8, wherein generating the collaborative intelligence comprises applying a set of the one or more constraints subsequent to execution of the query.

10. The one or more computer storage media of claim 8, wherein the query is part of a qualified whitelist query for the masked data, the qualified whitelist query being specified in the tenant agreement.

11. The one or more computer storage media of claim 8, wherein the operations further include: Prior to execution of the query, constraints specified in the tenant agreement are accessed by validating the query against a corresponding constraint context, the constraint context including runtime information associated with the query.

12. The one or more computer storage media of claim 8, wherein generating the collaborative intelligence include: A constrained execution tree is generated that is consistent with the one or more constraints, wherein generating the constrained execution tree is based on a mapping between executable logic units and custom executable logic units corresponding to the one or more constraints.

13. The one or more computer storage media of claim 8, wherein the collaborative intelligence is generated based on decomposing the response to the request. include: Executing a constrained execution tree that adds at least one operation to the execution tree, the at least one operation implementing a constraint of the one or more constraints specified in the tenant agreement.

14. A method for constraining a query, include: receiving, from a data consumer, a query for masked collaborative data stored in a data trustee environment, the masked collaborative data being generated from a plurality of input data sets provided by a plurality of tenants, wherein the data trustee environment is configured to prevent exposure of at least a restricted portion of the masked collaborative data to any tenant of the plurality of tenants and the data consumer based on a representation of a tenant agreement between the plurality of tenants stored in the data trustee environment; Parsing the query into an execution tree; converting the execution tree into a constrained execution tree, the constrained execution tree implementing one or more constraints specified in the tenant agreement; as well as Collaborative intelligence is generated from the masked collaborative data based on the constrained execution tree.

15. The method of claim 14, further comprising validating the query against a corresponding constraint context, the constraint context comprising applicable data access constraints specified in the tenant agreement and runtime information associated with the query.

16. The method of claim 14, wherein the execution tree is converted into the constrained execution tree include: The executable logic units of the execution tree are traversed, and an executable logic unit among the executable logic units that is inconsistent with the one or more constraints is replaced with a different executable logic unit that is consistent with the one or more constraints.

17. The method of claim 14, wherein converting the execution tree into the constrained execution tree include: One or more executable logic units that are inconsistent with the one or more constraints are replaced with custom executable logic units that enforce the one or more constraints.

18. The method of claim 14, wherein converting the execution tree into the constrained execution tree is based on a mapping between executable logic units and custom executable logic units corresponding to the one or more constraints.

19. The method according to claim 14, further comprising: include: Prior to generating the constrained execution tree, one or more access constraints specified in the tenant agreement are applied to the query.

20. The method of claim 14, wherein converting the execution tree into the constrained execution tree include: A request is issued for permission to execute an executable logic unit of the execution tree.

Images