Embodiments are directed to techniques for constructing, configuring, triggering, and executing various types of multi-party pipelines that access and/or use a shielded asset required to exist or execute within a data trustee environment. Generally, authorized participants can build upon template data privacy pipelines and other shielded assets to create other pipelines. Building blocks such as entitlements, cross-environment pipelines, and/or shielded assets governed by various collaborative intelligence contracts can be used to construct more complicated pipelines that may include any number of data privacy pipelines, cross-environment pipelines, input datasets, computational steps, output datasets, permissible queries, participants, and/or governing collaborative intelligence contracts. As such, various types of multi-participant pipelines can be constructed, configured, triggered, and executed to generate collaborative intelligence, without exposing shielded assets, underlying raw data or algorithms provided by owners, or collaborative data shielded by the data trustee environment.

BACKGROUND

Businesses and technologies increasingly rely on data. Many types of data can be observed, collected, derived, and analyzed for insights that inspire progress in science and technology. In many cases, valuable intelligence can be derived from datasets, 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, health care, manufacturing, retail, and practically any other industry. However, in many cases, the datasets owned or available to a particular data owner are incomplete or limited in some fundamental way. Information sharing is one way to bridge gaps in datasets, and sharing data has become an increasingly common practice. There are many benefits from sharing data. However, there are also many concerns and obstacles.

SUMMARY

Embodiments of the present disclosure are directed to techniques for constructing, configuring, triggering, and executing various types of multi-participant pipelines that access and/or use a shielded asset that is required to exist or execute within a data trustee environment. Generally, access to a shielded asset may be governed by a collaborative intelligence contract among multiple collaborators specifying a configuration of a data privacy pipeline or some other shielded asset (e.g., computational steps, collaborative dataset, etc.). Data privacy pipelines and other shielded assets can be thought of as templates or patterns that can be triggered and spun up in the data trustee environment by an authorized participant. The present disclosure describes how participants can build upon such pipelines and other shielded assets to create other pipelines.

When a collaborative intelligence contract authorizes a participant to access and/or use a shielded asset such as a template data privacy pipeline (or some portion thereof), the participant can use the shielded asset to build other, more complex pipelines. This introduces a number of possible configurations and use cases described herein, such as entitlements, cross-environment pipelines, and multi-contract, multi-participant pipelines. For example, an authorized participant may grant an entitlement for another participant to use a particular shielded asset within a data trustee environment, subject to any designated entitlement constraints and/or policies. With the granted entitlement, the beneficiary can then use the shielded asset in its own pipelines, and the pipelines, when executed, can access and use the shielded asset and enforce any designated entitlement constraints and/or policies. In another example configuration, a cross-environment pipeline may include some pre or post-processing that occurs outside of the data trustee environment, in combination with a data privacy pipeline or some other shielded asset required to exist or execute within the data trustee environment.

Entitlements, cross-environment pipelines, and/or various shielded assets can be used to build various types of multi-participant pipelines. For example, a single cross-environment pipeline can use multiple shielded assets governed by different collaborative intelligence contracts. In another example, different participants to a single collaborative intelligence contract can use shielded assets governed by the contract in their own pipelines. As will be appreciated, the various building blocks described herein can be used to construct more complicated pipelines, including any number of data privacy pipelines, cross-environment pipelines, input datasets, computational steps, output datasets, permissible queries, participants, and/or governing collaborative intelligence contracts.

As such, entitlements, cross-environment pipelines, and/or shielded assets governed by various collaborative intelligence contracts can be used to build various types of multi-participant pipelines. These multi-participant pipelines can be triggered and executed within the data trustee environment to generate collaborative intelligence, without exposing shielded assets, underlying raw data or algorithms provided by owners, or collaborative data shielded by the data trustee environment.

DETAILED DESCRIPTION

Overview

There are many benefits from sharing data. For example, sharing data often leads to more complete datasets, encourages collaborative efforts, and produces better intelligence (e.g., understanding or knowledge of an event or circumstance, or information, relationships, and facts about different types of entities). Researchers benefit from more data being available. Further, sharing can stimulate interest in research and can incentivize the production of higher data quality. Generally, sharing can result in synergies and efficiencies in research and development.

However, there are also many concerns and obstacles to sharing data. As a practical matter, different industries vary in ability and willingness to share data. Issues with data privacy and confidentiality are fundamental to many industries such as health care and banking. In many cases, laws, regulations, and consumer demands place restrictions on the ability to share data. Furthermore, the act of observing, collecting, deriving, and analyzing datasets is often an expensive and labor-intensive exercise, and many have concerns that sharing data would give away a competitive advantage. Even when there is sufficient motivation to share data, issues with control and access to shared data are often an obstacle to sharing. In effect, the obstacles often prevent data sharing and the opportunities for progress that come with it. As such, there is a need for data sharing techniques that facilitate development of collaborative intelligence while ensuring data privacy and facilitating control and access to shared data.

Accordingly, embodiments of the present disclosure are directed to techniques for constructing, configuring, triggering, and executing various types of multi-participant pipelines (e.g., multi-tenant pipelines) that access and/or use a shielded asset that is required to exist or execute within a data trustee environment. As used herein, a data pipeline that is required to execute within the data trustee environment is called a data privacy pipeline. Generally, a configuration of a data privacy pipeline can be specified by one or more participants and governed by a collaborative intelligence contract. A data privacy pipeline can be thought of as a template or a pattern that can be triggered and spun up by an authorized participant. Prior applications described how participants can collaborate to build a collaborative intelligence contract that specifies a configuration of a data privacy pipeline. This is an example of a single-contract, multi-participant pipeline. The present disclosure describes how participants (e.g., tenants of the data trustee environment) can build upon such pipelines and other shielded assets to create other pipelines (e.g., multi-participant pipelines, such as multi-tenant pipelines). Generally, when a collaborative intelligence contract authorizes a participant (e.g., a tenant) to access and/or use a shielded asset such as a template data privacy pipeline (or some portion thereof), the participant can use the shielded asset to build other, more complex pipelines. This introduces a number of possible configurations and use cases described herein, such as cross-environment pipelines that cross a data trustee environment and multi-contract, multi-participant pipelines.

When building a pipeline, a participant can utilize a number of techniques to access a shielded asset required to exist or execute in a data trustee environment. Generally, a collaborative intelligence contract may designate and parameterize access to any number of shielded assets, such as datasets, computational steps, pipelines, jobs, queries, audit events, and the like. Further, a collaborative intelligence contract may parameterize access control for designated participants on an element-by-element basis. Access control properties may be tailored to a particular user account, user group, or some other basis. As such, a contract can selectively permit access to and/or use of specific portions or even the entirety of a contact, pipeline, or some other shielded asset. Thus, a collaborative intelligence contract may include access controls that allow a designated participant to access a shielded asset, and a data trustee environment may implement those access controls.

In some embodiments, a collaborative intelligence contract may allow a party or other authorized participant to grant an entitlement for another participant to use a designated shielded asset within a data trustee environment, subject to any designated entitlement constraints and/or policies. For example, a data contributor may want to provide access to its data (or some other shielded asset), but may not want to be involved in the approval and enforcement of complex pipelines that use its data. In this case, the data contributor can grant an entitlement to a particular beneficiary to access and/or use its data, subject to designated entitlement constraints and/or policies. In embodiments where an entitlement grants permission for a shielded asset governed by a collaborative intelligence contract among multiple parties, the identity of the beneficiary may, but need not, be made available to other parties to the contract. With the granted entitlement, the beneficiary can then use this data in its own pipelines, subject to any entitlement constraints and/or policies designated by the data contributor. For example, the beneficiary can collaborate with others to build a data privacy pipeline, and the data privacy pipeline, when executed, can pull in the data from the contributor, along with any designated entitlement constraints and/or policies. In this case, the data contributor need not be a party to a governing downstream collaborative intelligence contract, nor participate in the construction of this downstream data privacy pipeline. Rather, the entitlement constraints and/or policies can be enforced by the data trustee environment in connection with the beneficiary's access and/or use of the data. In the context of entitlements, a designated entitlement constraint governs the use of the grantor's asset (e.g., a dataset) in generating an entitlement output (e.g., an aggregated dataset), while a designated entitlement policy governs the use of the entitlement output (e.g., in a downstream pipeline). Thus, entitlements are one possible building block for data pipelines, such as data privacy pipelines.

In some embodiments, a specification of a cross-environment pipeline may include some pre or post-processing that occurs outside of the data trustee environment, in combination with a data privacy pipeline or some other shielded asset required to exist or execute within the data trustee environment. Generally, there may be many existing collaborative intelligence contracts and/or entitlements specifying different template data privacy pipelines and/or other shielded assets. Any participant that is granted permission to access and/or use a particular template or other shielded asset can build a pipeline that uses the shielded asset, subject to any applicable constraints or polices. Even though a shielded asset may be required to exist or execute in a data trustee environment, a data pipeline can be built on top of the shielded asset without the rest of the data pipeline existing or executing in the data trustee environment. Thus, participants can create cross-environment pipelines that cross the data trustee environment. For example, a tenant can create a cross-environment pipeline that uses a shielded asset as a component in the pipeline. Thus, the tenant can create or spin up a cross-environment pipeline that may exist or execute partially in the data trustee environment. This kind of pipeline can be said to cross the data trustee environment, and can be considered a type of multi-participant pipeline (or multi-tenant pipeline) because it relies on a shielded asset governed by a collaborative intelligence contract with multiple participants (or tenants of the data trustee environment).

Entitlements, cross-environment pipelines, and/or shielded assets governed by different collaborative intelligence contracts can be used to build various types of multi-contract, multi-participant pipelines (or multi-contract, multi-tenant pipelines). For example, a single cross-environment pipeline can use multiple shielded assets governed by different collaborative intelligence contracts. In another example, different participants to a single collaborative intelligence contract can use shielded assets governed by the contract in their own pipelines. In some cases, the different participants to a collaborative intelligence contract need not know the other participants exist. These are just a few examples of different types of multi-participant pipelines that can be built and triggered. As will be appreciated, the various building blocks described herein can be used to construct more complicated pipelines, including any number of data privacy pipelines, cross-environment pipelines, input datasets, computational steps, output datasets, permissible queries, participants, and/or governing collaborative intelligence contracts.

Accordingly, the techniques described herein facilitate the use of shielded assets to build, trigger, and execute various types of multi-participant pipelines. Generally, a data trustee environment can authorize an authorized participant (including an entitlement beneficiary) to use a data privacy pipeline or some other shielded asset (e.g., computational steps, collaborative dataset, etc.) that is required to exist or execute in a data trustee environment. Thus, an authorized participant can access and/or use the data privacy pipeline (or other shielded asset) within the data trustee environment to build some other pipeline configured to make use of it. For example, a tenant can create a cross-environment pipeline that uses a shielded asset governed by a collaborative intelligence contract with multiple participants as a component in a pipeline that includes some pre or post-processing that occurs outside of the data trustee environment. Other types of multi-participant pipelines include multi-contract, multi-participant pipelines configured to access and/or use shielded assets from multiple contracts, different participants to a single collaborative intelligence contract using a shielded asset governed by the contract in their own pipelines, and others.

As such, entitlements, cross-environment pipelines, and/or shielded assets governed by various collaborative intelligence contracts can be used to build various types of multi-participant pipelines. These multi-participant pipelines can be triggered and executed within the data trustee environment to generate collaborative intelligence, without exposing shielded assets, underlying raw data or algorithms provided by owners, or collaborative data shielded by the data trustee environment.

Referring now toFIG. 1, a block diagram of example collaborative intelligence environment100suitable for use in implementing embodiments of the invention is shown. Generally, collaborative intelligence environment100is suitable for generation of collaborative intelligence, and, among other things, facilitates constraint computing and constraint querying. Collaborative intelligence environment100or a portion thereof (e.g., data trustee environment110) may, but need not, be implemented in a distributed computing environment such as distributed computing environment3000, discussed below with respect toFIG. 30. Any or all of the components of collaborative intelligence environment100can be implemented as any kind of computing device, or some portion thereof. For example, in an embodiment, tenant devices101athrough101nand data consumer devices103athrough103ncan each be a computing device such as computing device3100, as described below with reference toFIG. 31. Further, data trustee environment110may be implemented using one or more such computing devices. In embodiments, these devices can be any combination of a personal computer (PC), a laptop computer, a workstation, a server, a mobile computing device, a PDA, a cell phone, or the like. The components of collaborative intelligence environment100may communicate with each other via one or more networks, which may include, without limitation, one or more local area networks (LANs) and/or wide area networks (WANs). Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets, and the Internet.

Collaborative intelligence environment100includes data trustee environment110that is capable of deriving collaborative data and/or collaborative intelligence from raw data provided by data owners or providers (e.g., tenants) subject to configurable constraints, without sharing the raw data. Generally, any number of tenants can input their data (e.g., datasets105athrough105n) into data trustee environment110and designate one or more constraints (e.g., from one of tenant devices101athrough101n). Data trustee environment110can derive collaborative data (e.g., collaborative datasets107athrough107n, shielded collaborative dataset160) based on the one or more constraints. Any number of data consumers (e.g., operating one of data consumer devices103athrough103n) may issue queries on shielded collaborative dataset160, and data trustee environment110may derive collaborative intelligence from shielded collaborative dataset160, subject to the one or more constraints. In some cases, an authorized data consumer (e.g., which may be defined by one or more of the constraints) may be the same person or entity that owns or provided raw data (e.g., one or more of datasets105athrough105n) or owns the derived collaborative data (e.g., shielded collaborative dataset160). In some cases, an authorized data consumer may be some other person or entity.

In the embodiment illustrated inFIG. 1, data trustee environment110includes interface112, constraint manager115, data privacy pipeline120, and constrained querying component170. At a high level, tenants that seek to share data and other designated contributors can interact with interface112to specify parameters for a contractual agreement to share and access data. Generally, interface112can cause presentation of a user interface that serves as a sandbox for one or more participants to generate, contribute to, or otherwise configure a data privacy pipeline (such as data privacy pipeline120), which can serve as the basis for a contractual agreement among the participants. Various types of pipelines are possible and may include any number of pipeline inputs (e.g., input datasets), computational steps, and/or output datasets to be generated. Pipelines may be built on top of shielded assets that are required to exist or operate in the data trustee environment110and that a participant is permitted to access and/or use. For example, and as explained in more detail below, a participant authorized to access or use a particular data privacy pipeline (e.g., by way of a first contractual agreement) can build another pipeline that includes the data privacy pipeline (e.g., a cross-environment pipeline, another data privacy pipeline governed by a second contractual agreement among multiple participants, etc.).

A data privacy pipeline can be provided as a distributed computing or cloud computing service (cloud service) implemented in the data trustee environment110, and can be spun up and spun down as needed. Constraint manager115can monitor and orchestrate the use of, generation of, and access to collaborative data subject to the specified specify parameters for the agreement. The specified parameters and other features of the agreement may be stored in a contact database (not depicted) accessible to constraint manager115. Constrained querying component170can apply constraint querying to allow authorized data consumers (e.g., operating one of data consumer devices103athrough103n) to query collaborative data (e.g., shielded collaborative dataset160) in data trustee environment110subject to the specified parameters. Generally, the components of data trustee environment110may correspond to the components of data trustee environment2610ofFIG. 26, which is described in more detail below.

In some embodiments, interface112can cause a presentation of a graphical or other visual user interface that includes any arrangement and orientation of interaction elements capable of receiving inputs that specify parameters for a data privacy pipeline and a corresponding agreement to share data. The user interface may allow authorized parties to a contract or authorized participants for a pipeline to select, compose, and arrange any number and combination of pipelines. For a particular data privacy pipeline, for example, the user interface may accept a specification of pipeline inputs (e.g., input datasets), computational steps, and/or pipeline/contract outputs (e.g., output datasets comprising collaborative data to be generated by a data privacy pipeline, permissible named queries on collaborative data, and the like). In some embodiments, interface112can be implemented as a web service that prompts users on client devices to specify parameters through a series of related pages, screens, and/or other interface elements. Once a pipeline is built, interface112can allow an authorized participant to trigger the pipeline, or use the pipeline as a template when building other pipelines. An example implementation of interface112may cause presentation, on a client device, of one or more of the user interfaces depicted inFIGS. 11-25and described in more detail below. Although in some embodiments, various user interfaces are described as being a graphical user interface, this need not be the case. Other examples of possible interfaces includes programmatic interfaces, command line interfaces, menu-driven interfaces, form-based interfaces, natural language interfaces, gesture-driven interfaces, optical interfaces, haptic interfaces, and 3D interfaces, to name a few. Generally, any suitable interface capable of implementing the functionality described herein is contemplated within the scope of the present disclosure.

Generally, interface112can prompt contributors to a data privacy pipeline to specify various parameters for the pipeline or the corresponding agreement, and constraint manager115can store the parameters and orchestrate deploying the pipeline (and contract, if applicable).FIG. 2illustrates an example constraint manager200, which may correspond to constraint manager115ofFIG. 1. For any given pipeline or corresponding collaborative intelligence contract, whether finalized or under development, constraint manager200may store a set of roles210, an arrangement of computational steps220that form a data privacy pipeline, permissible named queries230, and specified constraints240. For example, the set of roles210may include a designation of data owners, authorized contributors, and authorized data consumers. The roles210may be applied on an element-by-element basis to different elements of computational steps220in order to parameterize access control on an element-by-element basis. For example, computational steps220may authorize data owners to provide an input dataset into slots A and/or B, and may authorize a contributor to provide a computational script through slot N.

Generally, a specified computation step may include a specified computation platform (e.g., Javascript, Kusto Query Language, SparkQL, Python, C# Linq), a specified input to the computational step, a specified computation for the computational step, a specified output schema, some combination thereof, or otherwise. InFIG. 2, computational steps220are illustrated with an example configuration of a selection of these elements, including slots for inputs A and B, template fuse and map reduce computations, slot N for a custom computation, and a set of unexposed computations (illustrated with a padlock symbol). This configuration is meant merely as an example, and any suitable computational step may be specified. These computational steps220can also be thought of as templates that can be used as shielded assets by authorized participants to create pipelines of their own.

FIG. 3illustrates an example multi-participant pipeline, in accordance with certain embodiments. In this example, three participants A, B, and C collaborate to build pipeline300, which serves as a basis for a single contractual agreement among the three participants. In this simple example, each participant contributes data, and pipeline300is configured to fuse and perform some computation over the data, and store the result in some queryable storable. Now consider the possibility that A does not care about the particular computation or the different possible downstream queries, as long as some particular constraint is satisfied, such as an aggregation constraint (e.g., allow access only when aggregating at least N rows or distinct field values). Rather than requiring A to collaborate on an entire pipeline300, which may require A to review and sign off on the entire pipeline, in some embodiments, A can grant some other participant such as B an entitlement to use A's data, subject to a defined entitlement constraint (applied when the data is used) or entitlement policy (enforced on the entitlement output).

FIG. 4illustrates an example entitlement, in accordance with certain embodiments. In this example, A grants B an entitlement410to use A's data (or some other shielded asset required to exist or execute in a data trustee environment). In granting the entitlement, A can specify any number of entitlement constraints on B's use of A's asset to generate some entitlement output. Additionally or alternatively, A can specify any number of entitlement policies on downstream uses of the entitlement output. Entitlement constraints and policies can implement any of the various types of constraints described here, including by way of nonlimiting example data access constraints, data processing constraints, data aggregation constraints, and/or data sanitation constraints. In the example illustrated inFIG. 4, the entitlement410carries with it an aggregation constraint420. As such, when B accesses and/or uses A's data pursuant to the entitlement, the aggregation constraint420can be automatically applied to generate output entitlement430. This is just an example, and any other constraint may be applied to a beneficiary's entitlement to use a designated shielded asset. Furthermore, any type of shielded asset may be the subject of an entitlement grant, assuming the grantor has the proper permission to grant the entitlement (e.g., an owner of data or a script granting an entitlement to use the owner's own data or script, a participant to a collaborative intelligence contract granting an entitlement to use a shielded asset where permissions in the contract allow the participant to grant the entitlement, etc.).

Technologically, an entitlement can be implemented similar to the way one or more collaborators can build and configure a data privacy pipeline, as described in more detail below. In the case where an asset owner or some other participant with the proper permission grants an entitlement to a beneficiary, the owner can use an interface (e.g., interface112ofFIG. 1) to designate an asset, a beneficiary, and any entitlement constraints or policies. In some embodiments, the grantor of an entitlement may build, configure, and deploy the entitlement without any participation from the beneficiary. In other embodiments, the grantor may grant permission to the beneficiary to collaborate to build and configure the entitlement (e.g., using parameterized access control on an element-by-element basis). In some embodiments, the beneficiary may initiate a request for an entitlement, and the request can be routed to the potential grantor for approval and/or configuration.

Entitlements are one possible building block that can enable different kinds of multi-participant pipelines. Similar to the way a data privacy pipeline can be thought of as template or a pattern that can be triggered and spun up by an authorized participant, a granted entitlement can be thought of as a template or a pattern that can be triggered and spun up by an authorized beneficiary. Thus, a beneficiary can build upon a granted entitlement, for example, by using the entitlement output when building and configuring a pipeline such as a data privacy pipeline. In the example illustrated inFIG. 4, B and C collaborate to build pipeline440, which serves as a basis for a contractual agreement among the two participants. When building pipeline440, B can use the output entitlement430from A as one of the inputs into the fuse operation to operate on similar data as in the implementation of pipeline300ofFIG. 3. The difference between pipeline300and pipeline440is that A no longer needs to participate in building, configuring, or approving pipeline440. In this example, when an authorized participant to pipeline440(e.g., B or C) triggers the pipeline, A's data is accessed, aggregated420, and output430into pipeline440, which fuses the output430with B's and C's data. In embodiments where entitlement410serves as the basis for a contractual agreement between A and B, and pipeline440serves as the basis of a contractual agreement between B and C, the combination of the entitlement410with pipeline440can be thought of as a multi-contract, multi-participant pipeline400.FIG. 5Cdiscussed below depicts another possible multi-contract, multi-participant pipeline530.

FIGS. 5A-5Cillustrate the use of entitlements to build a multi-contract, multi-participant pipeline, in accordance with embodiments described herein.FIGS. 5A and 5Billustrate example entitlements510and520. Although these are described as entitlements, they can additionally or alternatively be implemented as data privacy pipelines, some portion thereof, or some other shielded asset. In the example illustrated inFIGS. 5A and 5B, A is the owner of the fuse1script, and B is the owner of the fuse2script. A can grant an entitlement510to any beneficiary (indicated as an asterisk) to access and/or use the fuse1script, and B can grant an entitlement520to any beneficiary (indicated as an asterisk) to access and/or use the fuse2script. Assume C has been granted the entitlements510and520. Now, C can build its own pipeline530that includes both fuse1and fuse2script. Pipeline530is configured to first fuse C's data with A's data using A's fuse1script, then fuse the output with B's data using B's fuse2script. When C triggers pipeline530, A's data and B's data are accessed, A's data is fused with C's data, and the output is fused with B's data. In embodiments where entitlement510serves as the basis for a contractual agreement between A and C, and entitlement520serves as the basis for a contractual agreement between B and C, the pipeline530constructed by C using multiple contracts with multiple participants can be thought of as another example of a multi-contract, multi-participant pipeline.

In some embodiments, a data pipeline that spans multiple environments may be built and configured. Generally, once a participant is granted access to a shielded asset that is required to exist (e.g., datasets) or execute (e.g., scripts) within a data trustee environment, the participant may build off that asset. Although that asset may be restricted to the data trustee environment, a data pipeline that relies on or otherwise uses the asset may include some pre or post-processing steps that need not occur in the data trustee environment.FIG. 6illustrates an example cross-environment pipeline, in accordance with certain embodiments. In this example, A and B have their own data pipelines620and630that are configured to feed data into a data privacy pipeline610(or some other shielded asset) that A and/or B have built and configured. For example, A's data pipeline620may be configured to perform some pre-processing by reading from cloud storage, performing a transformation, and filtering the results before feeding the filtered results into the data privacy pipeline610. B's data pipeline630may be configured to read data from B's cloud storage account, transform it, generate a report, and feed the report into data privacy pipeline610. In this example, data privacy pipeline610can pull in A's filtered results and B's report, perform some agreed upon computation to derive an insight (collaborative intelligence) without exposing each other's data, and the insight can be output back into A's and B's data pipelines620and630. In A's data pipeline620, the insight is used to train a machine learning model. In B's data pipeline630, the insight is filtered and used to generate a report. In this example, data privacy pipeline610is restricted to a data trustee environment, while A's data pipeline620and B's data pipeline630cross the data trustee environment. Data pipelines620and630can therefore be considered cross-environment pipelines.

Generally, entitlements, cross-environment pipelines, and/or shielded assets governed by different collaborative intelligence contracts (e.g., template data privacy pipelines) can be used to build various types of multi-contract, multi-participant pipelines.FIG. 7illustrates an example multi-contract, multi-participant pipeline, in accordance with certain embodiments. In this example, participants A, B, C, D, E, and F each have their own cross-environment data pipelines705,715,720,730,740, and750, respectively, and certain participants have also collaborated to build and configure various data privacy pipelines (or some other shielded asset). A scenario like this could occur in any number of industries. For example, participants A, B, C, D, E, and F could be hospitals and researchers collaborating to try to identify a treatment for cancer. Some of the participants may want to contribute algorithms, the rest may want to contribute medical data, and they all want to spin up a pipeline to derive insights without exposing the underlying data or algorithms. To accomplish this, certain combinations of participants can collaborate to build and configure data privacy pipelines.

InFIG. 7, A, B, and C are participants to data privacy pipeline710, which operates on and derives collaborative intelligence for A's, B's, and C's data pipelines705,715, and720. C and D are participants to data privacy pipeline725, which operates on and derives collaborative intelligence for C's and D's data pipelines720and730. D and E are participants to data privacy pipeline735, which operates on and derives collaborative intelligence for D's and E's data pipelines730and740. E and F are participants to data privacy pipeline745, which operates on and derives collaborative intelligence for E's and F's data pipelines540and550, and so on. In combination, these pipelines form one large multi-contract, multi-participant pipeline700that serves the combined business goals of the various participants. Although in this example, the participants are described as knowing each other, this need not be the case. For example, A and B need not know that C is collaborating with D, C need not know that D is collaborating with E, and so on.

Another way to implement this type of pipeline is for all participants A, B, C, D, E, and F to collaborate to build and configure one master data privacy pipeline that serves as the basis for a single contract among all the participants. However, by breaking down the data flow into smaller, more discrete units, it becomes easier to facilitate agreements among fewer participants and governing smaller units of collaboration. Thus, multi-contract, multi-participant pipelines can encourage data sharing and development of collaborative intelligence, while ensuring data privacy and facilitating control and access to shared data.

Example Flow Diagrams

With reference toFIGS. 8-10, flow diagrams are provided illustrating various methods relating to generation of a data privacy pipeline. The methods can be performed using the collaborative intelligence environment described herein. In embodiments, one or more computer storage media having computer-executable instructions embodied thereon can, when executed by one or more processors, cause the one or more processors to perform the methods in the autonomous upgrade system.

Turning now toFIG. 8, a flow diagram is provided that illustrates a method800for generating a data privacy pipeline. Initially at block810, a configuration of a multi-participant pipeline is received from a plurality of participating tenants of a data trustee environment. In this example, the received configuration includes a specification of (i) an input into the multi-participant pipeline, (ii) one or more computational steps of the multi-participant pipeline, (iii) a specified use of at least one shielded asset governed by a collaborative intelligence contract between one of the participating tenants and a non-participating tenant of the data trustee environment that is not a participant to the multi-participant pipeline, the data trustee environment configured to limit the at least one shielded asset to within the data trustee environment based on the collaborative intelligence contract, and (iv) at least one of an output dataset or a permissible query. At block820, the data trustee environment deploys the configuration of the multi-participant pipeline in the data trustee environment, without exposing the at least one shielded asset, upon being triggered by an authorized one of the plurality of participating tenants.

Turning now toFIG. 9, a flow diagram is provided that illustrates a method900for generating a data privacy pipeline. Initially at block910, authorization is provided, by a data trustee environment to a participating tenant of the data trustee environment, to use (i) a first shielded asset associated with a first collaborative intelligence contract between the participating tenant and a first tenant of the data trustee environment, and (ii) a second shielded asset associated with a second collaborative intelligence contract between the participating tenant and a second tenant of the data trustee environment. In this example, the data trustee environment is configured to limit the first and second shielded assets to within the data trustee environment based on the first and second collaborative intelligence contracts, respectively. At block920, a configuration of a data privacy pipeline is received from the participating tenant. In this example, the received configuration comprises a specification of (i) an input into the data privacy pipeline, (ii) one or more computational steps of the data privacy pipeline; (iii) a specified use of the first and second shielded assets, and (iv) at least one of an output dataset or a permissible query. Because the first shielded asset is governed by the first collaborative intelligence contract, and the second shielded asset is governed by the second collaborative intelligence contract, the data privacy pipeline can be considered a multi-contract pipeline because it makes use of shielded assets governed by multiple contracts. At block930, the configuration of the data privacy pipeline is deployed in the data trustee environment, without exposing the first or second shielded assets, upon being triggered by the participating tenant.

Turning now toFIG. 10, a flow diagram is provided that illustrates a method1000for generating a data privacy pipeline. Initially at block1010, authorization is provided, by a data trustee environment to a first tenant of the data trustee environment, to use a shielded asset associated with a collaborative intelligence contract between the first tenant and a second tenant of the data trustee environment. In this example, the data trustee environment is configured to limit the shielded asset to within the data trustee environment based on the collaborative intelligence contract. At block1020, a configuration of a data privacy pipeline is received the first tenant. In this example, the received configuration comprises a specification of a use of the shielded asset, and at least one of (i) an input into the data privacy pipeline based on pre-processing performed outside the data trustee environment, or (ii) an output of the data privacy pipeline triggering post-processing outside of the data trustee environment. Because the data privacy pipeline can accept an input based on pre-processing performed outside the data trustee environment or on output triggering post-processing outside of the data trustee environment, it can be thought of as part of a cross-environment data pipeline that crosses the data trustee environment. At block1030, the configuration of the data privacy pipeline is deployed in the data trustee environment, without exposing the shielded asset, upon being triggered by the first tenant.

Example Sandbox Interface for Building a Data Privacy Pipeline

FIGS. 11-25illustrate a variety of example user interfaces capable of receiving inputs for constructing and configuring a data privacy pipeline to generate collaborative data.FIG. 11is an illustration of an example user interface1100for browsing collaborative intelligence contracts. User interface1100may be accessible through a portal of a distributed or cloud computing service, such as AZURE®, by Microsoft Corporation of Redmond, Wash. More specifically, a collaborative intelligence service may be associated with an authorized tenant account, thereby granting access to the collaborative intelligence service through the tenant account. User interface1100is an example interface that allows a user to browse assets that are available to the tenant account, such as existing collaborative intelligence contracts for which the tenant account is an authorized participant. For example, banner1110may provide a resources menu1120that allows a user to browse existing contracts, accessible datasets (e.g., stored by the tenant account), accessible scripts (e.g., stored by the tenant account), pipelines (e.g., for which the tenant account is authorized), jobs (e.g., initiated by, associated with, or otherwise accessible by a tenant account), queries (e.g., initiated by, associated with, or otherwise accessible by a tenant account), audit events (e.g., operations relevant to one of the foregoing resources that were initiated by, associated with, or otherwise accessible by a tenant account), and the like. In the example illustrated inFIG. 11, available contracts are selected for browsing from resources menu1120, and user interface1100presents existing contracts1130, including an indication of the status of each contract. The presented contracts1130may be selectable for viewing and/or editing. User interface1100may include an interaction element1140that accepts an input indicating a new contract should be created.

User interface1100provides an example interface for browsing collaborative intelligence contracts. Other interfaces corresponding to other resources are not depicted, but may be implemented with functionality corresponding to a resource being browsed. For example, a user interface configured to browse available scripts may allow filtering by name, owner, and/or script type (e.g., computational platform, category of functionality, and the like). In another example, a user interface configured to browse available datasets may present or otherwise make available (e.g., by clickable link or menu) information about the dataset, such as name, identifier, owner, storage location, creation time, last read time, last write time, tags associated with the dataset, and/or any other type of relevant information. Generally, a user interface configured to browse an available resource may include functionality that allows a user to create, select, edit, delete, grant access to, or otherwise manipulate properties of a particular resource. Example implementations of such functionality are described in more detail below.

In some embodiments, when an input indicating a new contract should be created is received, a user interface may prompt for inputs that specify parameters of the new contract. For example,FIG. 12is an illustration of an example user interface1200for naming a new collaborative intelligence contract. User interface1200may include a contract menu1202that presents a representation of the new contract. For example, contract menu1202may include a nested menu item1204representing the new contract. The nested menu item1202may be expanded to present selectable representations of the elements of the new contract, such as inputs1206, computations1208, and outputs1210. Generally, menu items from contract menu1202may be similarly expandable, and selecting a menu item from contract menu1202may prompt a user to enter or edit parameters corresponding to the selected menu item. For example, selecting menu item1204representing the new contract can prompt for inputs (e.g., via input fields1220) specifying details for the new contract. In this example, the inputs include contract name (e.g., “Advertising efficiency”), a brief description of the contract (e.g., “how well ads work”), and a textual description of the proposed terms of use. When the user is finished, selection of an interaction element (e.g., next button1230) can navigate the user to a subsequent screen. Similar or other navigational interaction elements may be presented to navigate through a series of related pages, screens, and/or other interface elements.

FIG. 13is an illustration of an example user interface1300for specifying inputs to a data privacy pipeline associated with a collaborative intelligence contract. In user interface1300, menu item1204has been renamed to reflect the specified name of the new contract (Advertise efficiency). Selection of menu item1206for the contract inputs may prompt the user to enter parameters for the inputs. For example, interaction element1320can allow a user to select an existing, accessible dataset (e.g., stored by the tenant account). In another example, interaction element1330can allow a user to invite a contributor to the contract or otherwise associate an account with the contract (e.g., by specifying an email address or some other indication of a particular account in popup window1350). In yet another example, interaction element1340can allow a user to connect a new input dataset. For example, selection of interaction element1340can cause a presentation of a directory of available datasets (e.g., local datasets available for upload, authorized datasets associated with a participating contributor account, datasets associated with a selected project or contract).FIG. 14depicts an example user interface1400with a panel1420that presents a directory1430of available datasets. An available dataset (e.g., Impressions) can be selected and connected, to associate the selected dataset with an active contract (e.g., associated with a selected element in contract menu1202).

In some embodiments, an input schema for an input dataset may be specified.FIGS. 15A-Billustrate example user interfaces1500aand1500bfor specifying an input schema. User interface1500aofFIG. 15Aincludes input fields1520athat allow a user to define parameters of an input schema for an input dataset. For example, a specified input schema may include an identification of a particular component of an input dataset (e.g., variable, array, vector, matrix, row, column, property) and one or more corresponding attributes (e.g., name, data type, description, dimensionality). If a user is connecting a new input dataset, input fields1520amay allow the user to specify particular portions of the input dataset to connect (e.g., designated columns). If a user is specifying a placeholder dataset, input fields1520amay allow the user to specify an input schema for an input dataset to be provided at some point in the future. In some embodiments, a menu of available options (e.g., dropdown menu1530) may be limited to a set of detected or compatible values. In some embodiments, new properties can be added to the set of input fields1520a(e.g., by selecting an interaction element such as add property1540). User interface1500bofFIG. 15Billustrates an example in which input fields1520bare automatically populated (e.g., detected from a connected input dataset). These are just a few examples, and other variations for specifying an input schema for an input dataset are contemplated.

FIGS. 16A-Care illustrations of example user interfaces1600a,1600b, and1600cfor creating a new computational step in a data privacy pipeline associated with a collaborative intelligence contract. Generally, selection of an interaction element associated with a menu item in contract menu1202(e.g., the plus sign next to the computations menu item1208in contract menu1202inFIG. 16A) can prompt a user to specify parameters for an associated new element (e.g., a new computational step). For example, panel1620ofFIG. 16Acan prompt a user to select a compatible or supported computation platform capable of executing a specified computation step. Panel1630can prompt a user to select parameters such as step name, step type, and step inputs.FIG. 16Billustrates an example new step called Fuse_1. InFIG. 16B, the step type input field includes an interactive dropdown menu1640that accepts a selection of one or more template computations. InFIG. 16C, a template fuse computation has been selected for the step type. Also inFIG. 16C, the step inputs field includes an interactive dropdown menu1650that accepts a selection of one or more computational step inputs. For example, available computational step inputs may include connected inputs1660, computational results1670(i.e., an output of an existing computational step associated with the project or contract), and placeholder datasets1680. InFIG. 16C, dropdown menu1650presents an indication that there are no computational results available (e.g., because, in this example, Fuse_1is the first computational step for this particular contract). In the example illustrated byFIG. 16C, the user has selected two inputs to the Fuse_1computational step: one of the input datasets1660(i.e., the input dataset that was connected in association withFIG. 14) and a placeholder dataset1680(i.e., an indication to define an input schema for a placeholder dataset). These and other variations for specifying inputs to a computational step may be implemented.

Continuing with the present example, once the user selects a set of inputs to the computational step, the user can be prompted to specify an input schema for the inputs.FIGS. 17A-Bare illustrations of example user interfaces1700aand1700bfor specifying an input schema for a computational step. Note that in contract menu1202, nested menu item1712has been added representing the Fuse_1step. As with other menu items in contract menu1202, nested menu item1712may be expanded to present selectable representations of the elements of the associated computational step, such as input schema1714, computation1716, and output schema1718. In user interface1700aofFIG. 17A, menu item1714for the input schema to the Fuse_1computational step is selected. User interface1700apresents an input schema1725for input dataset1720(which may have been previously specified or otherwise identified) and input fields1740afor the input schema for placeholder dataset1730(which may be filled out via user interface1700a). In some embodiments, new properties can be added to the set of input fields1740afor the input schema (e.g., by selecting an interaction element such as add property1750). In some embodiments, user interface1700amay include an interaction element that allows a user to replace a selected input with another one. For example, dropdown menu1760amay allow a user to replace placeholder dataset1730with an available input dataset or a computational result. User interface1700bofFIG. 17Billustrates a selection of a connected input dataset (Impressions) to replace placeholder dataset1730, and input fields1740bhave been updated to reflect the input schema for the selected input dataset. User interfaces1700aand1700bcan also be thought of as presenting a summary of the step inputs for a particular computational step. Generally, interaction elements (e.g., a button, clickable link, clickable entry) may be provided for a particular step input that allows a user to rename the step input, remove the step input, unassociate a dataset with the step input (i.e., convert the input to a placeholder dataset), associate a dataset with the step input (i.e., populate a placeholder dataset), edit a schema for the step input, or otherwise manipulate properties of the step input.

Turning now toFIGS. 18A-C,FIGS. 18A-Cillustrate example user interfaces1800a,1800b, and1800cfor specifying a computation for a computational step. In user interface1800aofFIG. 18A, menu item1716for the computation to the Fuse_1computational step is selected. User interface1800aincludes an interaction element1820that allows a user to select an available computation (e.g., via a dropdown menu) and an interaction element1825that allows a user to create a new one. User interface1800billustrates an example in which a user selects to create a new computation. In response to such a selection, a user interface such as user interface1800bmay be presented with a script editor and/or a compiler for a specified computational platform. The embodiment illustrated inFIG. 18Bincludes a script editor, a compiler, and an interaction element1830that allows a user to specify whether the specified computation should be visible to others.FIG. 18Cillustrates an example script1840that may be provided.

FIGS. 19A-Billustrate example user interfaces1900aand1900bfor specifying an output schema for a computational step. In user interface1900aofFIG. 19A, menu item1718for the output schema to the Fuse_1computational step is selected, and input fields1920amay be populated to specify parameters for the output schema. User interface1900bdepicts an example output schema1920bthat may be provided for the Fuse_1step. User interfaces1900aand1900bcan also be thought of as presenting a summary of the step outputs for a particular computational step (although only one step output is depicted inFIGS. 19A and 19B). Generally, interaction elements (e.g., a button, clickable link, clickable entry) may be provided for a particular step output that allows a user to rename the step output, remove the step output, designate a location to export the step output, edit a schema for the step output, or otherwise manipulate properties of the step output.

FIG. 20is an illustration of an example user interface2000summarizing computation steps in a selected contract and/or an associated data privacy pipeline. In user interface2000a, menu item1208for the computational steps in the Advertise efficiency contract is selected. In this example, contract menu1202has been updated with menu items reflecting two completed computational steps: Fuse_1(menu item2012) and Aggregate (menu item2014). Furthermore, table2020displays a summary of the computational steps for the contract, including an indication of the computation platform, an indication of the owner of the step, and/or an indication of the visibility of the step. In some embodiments, an interaction element may be provided that links to a corresponding interface configured to edit a selected computational step (e.g., a button, selectable text such as the name of the computational step, a selectable entry such as a row in table2020). Additionally or alternatively, an interaction element may be provided that deletes a selected computational step (e.g., prompting for confirmation first), renames a computational step, changes access rights, or other manipulations.

FIG. 21illustrates an example user interface2100for specifying contract outputs associated with a collaborative intelligence contract. In user interface2100, menu item1210for the outputs of the Advertise efficiency contract is selected. Generally, any type of output may be supported. In the embodiment illustrated inFIG. 21, user interface2100include interaction elements2125and2135that allow a user to enter parameters for named queries and output datasets, respectively. Note that corresponding menu items2120and2130are nested underneath the menu item1210for the outputs of the Advertise efficiency contract.

FIGS. 22A-Billustrate example user interfaces2200aand2200bfor specifying output datasets to be generated by a data privacy pipeline. In user interfaces2200aand2200b, menu item2130for the outputs datasets for the Advertise efficiency contract is selected. User interface2200aofFIG. 22Amay include a summary2240of the specified output datasets to be generated. Further, menu item2130may be expandable to display the currently specified output datasets as corresponding menu items in contract menu1202. As with other user interfaces described here, user interface2200amay include an interaction element that allows a user to create a new contract element, here a new output dataset. In response, a user interface such as user interface2200bofFIG. 22Bmay prompt the user to specify parameters for the new output dataset. For example, user interface2200bmay prompt the user to specify a computational step from which a corresponding computational result should be used as an output dataset. In some embodiments, user interface2200bmay prompt the user to specify a destination for the output dataset. In response, a directory2255of available locations may be presented (e.g., via panel2250), and a desired location can be selected.

FIGS. 23A-Dillustrate example user interfaces2300a,2300b,2300c, and2300dfor specifying permissible named queries associated with a collaborative intelligence contract. In these user interfaces, menu item2120for permissible named queries for the Advertise efficiency contract is selected. Generally, parameters that may be specified for a named query may be similar to the parameters that may be specified for a computation for a computational step. For example, user interface2300amay include a query name field2320, a field2322for specifying the output of a particular computational step on which the query may operate, input fields2324for specifying an input schema, an interaction element2326for selecting an existing available script, and/or an interaction element2328for creating a new script2328. Selection of interaction element2328to create a new script may cause presentation of a user interface such as user interface2300bofFIG. 23Bthat accepts a selection of a programming language2330for the new script. Additionally or alternatively, a user interface such as user interface2300cofFIG. 23Cmay be presented to accept an input of a script such as script2340. In some embodiments, user interface2300cmay include a script editor and a compiler (e.g., for a specified programming language).FIG. 23Dillustrates a summary2350of the named queries associated with the Advertise efficiency contract. Note that corresponding menu items for the named queries in summary2350have been added to menu item2120in the contract menu1202. Generally, interaction elements (e.g., a button, clickable link, clickable entry) may be provided for a particular named query that allows a user to rename the named query, remove the named query, view or edit a description of the named query, or otherwise manipulate properties of the named query.

FIG. 24Aillustrates an example user interface2400a summarizing contract outputs associated with a collaborative intelligence contract. In user interface2400a, menu item1210for the outputs to the Advertise efficiency contract is selected. User interface2400aincludes summary2410of the named queries associated with the contract and summary2415of the output datasets to be generated by deploying the data privacy pipeline associated with the contract.

FIG. 24Billustrates an example user interface2400bfor reviewing approvals and deploying a collaborative intelligence contract. In user interface2400b, menu item1204for the Advertise efficiency contract is selected. In this example, user interface2400bmay include a summary of the specified parameters for the contract, including a basic description2420, authorized participants2430, input datasets2440, specified computations2450, and contract outputs2460. In some embodiments, user interface2400bmay include an interaction element (e.g., interaction element2435) that allows a user to add a participant and define access rights (e.g., a role) for the new participant. User interface2400bmay prompt each participant to approve the contract. In some embodiments, interaction elements (e.g., buttons) can be provided that allow a participant to sign a contract, revoke an existing signature, or edit contract details (e.g., basic description2420). When all participants have approved, user interface2400bmay prompt a user to deploy the contract and corresponding data privacy pipeline (e.g., via interaction element2470).

FIGS. 25A-25Eare illustrations of example user interfaces for browsing and interacting with accessible resources, such as data privacy pipelines (FIG. 25A), jobs (FIG. 25B), named queries (FIGS. 25C and 25D), and audit events (FIG. 25E).

FIG. 25Aillustrates an example user interface2500afor browsing and interacting with available pipelines (e.g., for which a tenant account is authorized). For example, a particular account may be authorized to trigger a pipeline based on a corresponding permission specified in an associated collaborative intelligence contract. An accessible pipeline may be presented with a corresponding interaction element (e.g., trigger2510) that triggers a request to initiate a job defined by the pipeline. In some embodiments, when a triggered job succeeds, a tool tip may be shown indicating the successful creation. Conversely, when a triggered job fails, a tool tip may be shown indicating the failure.

FIG. 25Billustrates an example user interface2500bfor browsing and interacting with available jobs (e.g., collaborative intelligence jobs initiated by, associated with, or otherwise accessible by a tenant account). For example, a table2520of collaborative intelligence jobs (e.g., triggered pipeline jobs) may be presented along with information about the jobs, such as an identifier for a job, an identifier for the pipeline a job was created from, the execution status of a job (e.g., running, aborted, succeeded, failed), duration of the job from the moment it was started, and the like. In some embodiments, a job may be presented with an associated interaction element (e.g., button, clickable link, clickable entry) configured to perform an available action related to the job. For example, if a job is running, an available action may be an abort action. If a job has succeeded, an available action may be a view results action. If a job has failed, an available action may be a view errors action. In some embodiments, table2520may include associated interaction elements configured to filter the jobs being presented (e.g., by date, status, name, start time, duration). These and other variations are contemplated within the present disclosure.

FIGS. 25C and 25Dillustrate example user interfaces2500cand2500dfor browsing and interacting with available named queries (e.g., initiated by, associated with, or otherwise accessible by a tenant account). For example, a table2530of permissible named queries available to the account may be presented along with information about the named queries, such as an identifier for the named query, a corresponding dataset on which the named query is configured to operate, an identifier for an owner of the corresponding dataset, and the like. In some embodiments, a named query may be presented with an associated interaction element (e.g., button, clickable link, clickable entry) configured to perform an available action related to the named query, such as run action element2535, which may be configured to initiate a request to run a named query. In some embodiments, as a precursor to initiating a request to run a named query, one or more prompts for entry of relevant parameters for the named query can be presented. For example, user interface2500dmay be presented and may prompt for a description for the named query, a selection of permissible configurable parameters (e.g., defined by an associated collaborative intelligence contract), and the like. In the embodiment illustrated in2500d, trigger button2540may initiate the named query, and results (e.g., results table2545) may be presented.

FIG. 25Eillustrates an example user interface2500efor browsing and interacting with available audit events (e.g., jobs, collaborative intelligence contract proposals, or other operations relevant to a collaborative intelligence resource that were initiated by, associated with, or otherwise accessible by a tenant account). For example, a table2550of audit events available to the account may be presented along with information about the audit events, such as date and time for an event, a type of object operated on (e.g., job, proposal), a corresponding identifier for the object, a type of performed operation (e.g., started, aborted, created), an identifier for an account that initiated or is otherwise associated with the event, and the like. In some embodiments, table2550may include associated interaction elements configured to filter the audit events being presented (e.g., by date, object type, operation, associated account, description). These and other variations are contemplated within the present disclosure.

In this manner, one or more user interfaces can guide collaborators to build and configure a data privacy pipeline and a corresponding contractual agreement to share data. Although the interfaces described herein have been described with a certain configuration of interaction elements, these examples are not meant to be limiting. Generally, any suitable interface(s) capable of facilitating multi-party collaboration, generation of a data privacy pipeline, and/or specification of corresponding parameters is contemplated within the scope of the present disclosure.

Example Collaborative Intelligence Environment

Some embodiments of the present disclosure are directed to techniques for deriving collaborative intelligence based on constraint computing and constraint querying. At a high level, a data trustee can operate a trustee environment configured to derive collaborative intelligence for tenants subject to configurable constraints, without exposing underlying raw data provided by the tenants or 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). 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 exposable portion that is allowed to be shared and a restricted portion that is not allowed to be shared. Although the restricted portion of the collaborative data may not be shared, it may include an operable portion that may be used to derive collaborative intelligence that may be shared. In some embodiments, collaborative intelligence may be derived from exposable data and/or restricted data, and the collaborative intelligence may be provided without exposing the restricted data. For example, configurable constraints may programmatically manage limitations (e.g., allowing some operations, but not others) on certain underlying data (e.g., personally identifiable information, some other sensitive information, or any other designated information that is collected, stored, or used) and how the underlying data can and cannot be accessed, used, stored, or displayed (or variations thereof). Further, the configurable constraints may programmatically support collaborative intelligence operations on accessible data (e.g., deriving aggregate statistics), without displaying the individual data entries that were operated on.

By relying on trustee computing to perform data processing, tenants can derive collaborative intelligence from each other's data without compromising data privacy. To accomplish this, the trustee environment can include one or more data privacy pipelines through which data can be ingested, fused, derived, and/or sanitized to generate collaborative data. A data privacy pipeline can be 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. In some embodiments, tenants providing data into a data privacy pipeline cannot access the pipeline. Instead, the pipeline outputs collaborative data subject to constraints provided by one or more of the tenants. Depending on the designated constraints, the collaborative data can be output from the trustee environment (e.g., because it has been sanitized according to specified constraints) and/or may be stored in, and shielded by, the trustee environment. Shielded collaborative data can be queried to derive collaborative intelligence subject to the configurable constraints (e.g., without exposing the shielded collaborative data).

Generally, a data privacy pipeline can accept data provided by one or more tenants. Initially, the data privacy pipeline may determine whether input data is joint data pursuant to a contract or other tenant agreement with one or more tenants. Data that is determined to be joint data can be ingested, and data that is determined not to be joint data can be dropped. In this regard, joint data refers to any shared data that is designated for ingestion in generating collaborative data (e.g., a c designated or otherwise identified in a tenant agreement with one more tenants). Ingested data can include data from multiple sources, so the data privacy pipeline may fuse data from multiple sources according to computations and constraints specified in the tenant agreement. For example, constrained data fusion can implement one or more constraints to combine ingested data to form fused joint data in any number of ways, including the use of one or more join operations (e.g., left, right, inner, outer, anti), custom joins (e.g., via imperative scripts), data appends, normalization operations, some combination thereof, and others.

In some embodiments, a data privacy pipeline can perform constrained computations to generate derived joint data. Constrained computing can take data from one source (e.g., ingested data, fused joint data) and perform any number of specified computations (e.g., arithmetic operations, aggregation, summarization, filtering, sorting, bounding). A simple example of a constraint computation is a calculation of average age per city, where the computation is only to be performed for a city if the underlying dataset includes entries for at least five people in the city. Additionally or alternatively, a data privacy pipeline can perform data sanitation to generate collaborative data that implements constraints for storage, access, precision, and the like. For example, data sanitation can implement constraints specified in the tenant agreement designating whether collaborative data should be shielded (e.g., stored in the trustee environment), whether collaborative data can be exported, whether exported collaborative data should be restricted (e.g., do not export email, credit card numbers, portions thereof), and the like. As such, a data privacy pipeline can generate collaborative data from data provided by one or more tenants, and provide agreed-upon access to the collaborative data without sharing the underlying raw data with all the tenants.

In some embodiments, to enable constraint computing and querying, the use and generation of collaborative data in a trustee environment can be monitored and orchestrated subject to configurable constraints. At a high level, constraints can be provided through a user interface to enable tenants (e.g., customers, businesses, users) to specify desired computations and constraints on the use of and access to their data in the 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 sanitation constraints.

For example, data access constraints can be specified to allow or forbid access (e.g., to a specific user, account, organization). In some embodiments, designated constraints can be universal such that the constraints apply to all potential data consumers (e.g., only allow access to average age no matter the data consumer). In some embodiments, a designated constraint can be applied to a designated user, account, organization, and the like (e.g., do not allow group A to access salary data, but allow group B to access it). Generally, a tenant may specify constraints defining how the tenant's data can be merged with designated datasets or portions thereof, constraints limiting the schema of data being read from the tenant's data (e.g., specifying horizontal filtering to be applied to a tenant's data), constraints limiting the size of ingested data (e.g., specifying storage limitations, sub-sampling of the tenant's data, vertical filtering to be applied to a tenant's data), constraints limiting the schema of collaborative data that can be output, constraints defining ownership of collaborative data, constraints defining whether collaborative data should be open, encrypted, or shielded (e.g., stored in the trustee environment), and the like.

In some embodiments, various types of data processing constraints may be designated, such as constraints designating what operations can be performed (e.g., allowable and restricted computations, binary checks), constraints limiting a comparison precision (e.g., for numeric data, geographic data, date and time data), constraints limiting an accumulation precision (e.g., for geographical data, numerical data, date or time data), constraints limiting location bounding precision (e.g., limiting allowable geofencing determinations to specific grids, minimum geographic divisions such as neighborhood, county, city, state, or country, and the like), and other precision and/or data processing requirements.

Additionally or alternatively, one or more data aggregation constraints can be specified, such as constraints requiring a minimum aggregation amount (e.g., at least N rows or distinct field values), constraints requiring some statistical distribution condition to be valid (e.g., minimum standard deviation), constraints defining allowed aggregation functions (e.g., allow min, max, average, but not percentiles), to name a few examples.

In some embodiments, one or more data sanitation constraints can be specified, such as constraints requiring sanitation of personally identifiable information (e.g., remove e-mails, names, IDs, credit card numbers), constraints requiring lower precision sanitation (e.g., lower the numeric, data and time, and/or geographical precision), constraints requiring sanitization of values coming from specific fields (which may entail tracking transformations applied in a data privacy pipeline), constraints requiring custom sanitations (e.g., requiring execution of one or more custom and/or third party sanitation scripts), constraints requiring data masking (e.g., output certain data such as phone numbers, credit cards, dates, but mask a portion of the number), and the like.

Additionally or alternatively to the constraints listed above, one or more constraints can be specified limiting a number of allowable queries and/or data accesses per unit time (e.g., minute, hour, day). Such a constraint can operate to reduce the risk of brute-force attempts to reverse engineer shielded data by asking a set of slightly different questions within a relatively small time window. In general, one or more custom constraints can be specified such as a constraint requiring that some designated property match some designated criteria. These and other types of constraints are contemplated within the present disclosure.

In some embodiments, a constraint manager can monitor and orchestrate data flow, generation, and access, subject to the designated constraints. For example, the constraint manager can communicate with various components in the trustee environment (e.g., a data privacy pipeline) to implement the constraints, which may be maintained in a contract database accessible to the constraint manager. In some embodiments, components can issue requests to the constraint manager for permission to execute a particular command, function call, or other executable unit of logic. The constraint manager 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 of the constraints. By way of nonlimiting example, some possible conditions that can be implemented include requiring operations that shift, filter, or reshape data (e.g., application of comparison constraints such as only allowing a merge with certain precision), requiring substitution of one or more executable units of logic (e.g., commands or operations) with one or more constrained executable units of logic (e.g., replace average with constrained average), and the like.

Generally, a constraint can be checked, validated, or otherwise enforced at any time or step (e.g., in association with any portion of a data privacy pipeline, constrained querying). Accordingly, corresponding functionality enforcing a constraint can be applied at any step, or multiple steps. In some embodiments, enforcement of certain constraints can be allocated to certain portions of a data privacy pipeline (e.g., data access constraints get applied during ingestion, processing and aggregation constraints get applied during data fusion and/or constrained computation, sanitation constraints get applied during data sanitation). In another example, a particular data access constraint (e.g., only pass data for patients who participated in at least five different studies) may be applied during data fusion. These are meant merely as examples, and any suitable constraint enforcement regime may be implemented within the present disclosure.

Enforcement of a constraint (e.g., precision or aggregation constraints) on a particular executable unit of logic (e.g., for a designated computation, a requested operation) can result in any number of scenarios. In one example, a particular executable unit of logic can be rejected entirely. In another example, a particular executable unit of logic can be allowed, but the result is filtered (e.g., no value is returned for a particular row or entry of data). In yet another example, a particular executable unit of logic can be allowed, but the result is changed (e.g., precision reduced, a question is answered with false). These and other variations may be implemented.

As constraints are applied to generate collaborative data, any combination of schema, constraints, and/or attribution metadata can be associated with the collaborative data, intermediate data used to arrive at the collaborative data, or otherwise. Generally, constraints can be enforced across multiple steps and computations. As such, in some embodiments, applicable and/or satisfied constraints for each step can be tracked and/or associated with data produced by a given step. Taking aggregation constraints as an example, once an aggregation constraint has been fulfilled during a particular step, subsequent steps no longer need to consider this constraint. In another example where different constraints have been specified for different datasets to be merged, a merging operation may only need to apply the stricter constraint. Generally, an appropriate allocation or combination of constraints can be applied and/or tracked as data flows through a data privacy pipeline. This tracking can facilitate validating whether a particular constraint has been applied to particular data. Accordingly, as constraints are applied and data is generated, corresponding schema, applicable or satisfied constraints, and/or attribution metadata indicating ownership or providence can be associated with a dataset, or a corresponding entry, row, field, or other element of data. In some embodiments, any intermediate data used in arriving at collaborative data (e.g., ingested data, fused joint data, derived joint data) may be deleted, and collaborative data may be stored in the trustee environment and/or provided as an output, depending on an applicable constraint.

In some embodiments, constraint querying can be applied to allow data consumers to query collaborative data in a trustee environment subject to configurable constraints. At a high level, constraint querying can operate as a search engine that allows data consumers to access or derive collaborative intelligence from collaborative data without exposing underlying raw data provided by the tenants or collaborative data shielded by the trustee environment. Constraints can be applied in response to a query in any number of ways, including reformatting a query prior to execution, applying constraints after executing a query, constraining eligible queries for execution, applying access constraints prior to execution, and others.

By way of nonlimiting example, an issued query can be validated against a specified aggregation constraint by ensuring that the query contains at least one aggregation element and ensuring that the aggregation element(s) are consistent the aggregation constraint. In another example, an execution plan corresponding to the issued query can be executed, and the results can be validated against the aggregation constraint and/or the aggregation element(s) of the query (e.g., confirming the results correspond to a requested number of distinct rows, fields, statistical distribution). In some embodiments, a constraint can be enforced on a corresponding element of a query by modifying the element based on the constraint (e.g., to limit a corresponding number of distinct rows, fields, statistical distribution), by executing the modified element prior to the other elements of the query, some combination thereof, or otherwise.

By way of background, queries are generally not executable code. In order to execute a query, it is normally converted into an execution plan that is executable. In some embodiments, in order to enforce constraints on a received query, the query can be parsed into a corresponding execution tree comprising a hierarchical arrangement of executable units of logic that, when executed, implement the query. Applicable constraints can be accessed, and the executable units of logic can be validated against the constraints. In some embodiments, if one or more of the executable units of logic is not allowed, the query can effectively be reformatted by altering one or more of the executable units of logic 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 executable units of logic inconsistent with a particular constraint with custom executable units of logic that are consistent with the constraint. Additionally or alternatively, one or more executable units of logic may be added to the constrained execution tree to enforce constraints (e.g., precision constraints) on the output. These are simply meant as examples, and any suitable technique for generating a constrained execution tree can be implemented.

Generally, an executable unit of logic of an execution tree can be validated against a corresponding constraint context comprising an applicable accessed constraint and runtime information such as information identifying the requesting data consumer issuing the query, information identifying an applicable tenant agreement, information identifying target collaborative data on which to operate, and the like. Validation of an executable unit of logic can involve validation of a constituent command or operation, one or more constituent parameters, and/or consideration of other parts of the execution tree. Validation of an executable unit of logic can result in a number of possible results. For example, an executable unit of logic can be allowed (e.g., the executable unit of logic can be copied into a constrained execution tree), an executable unit of logic can be disallowed (e.g., the query can be disallowed in its entirety), or an executable unit of logic can be allowed but with changes (e.g., copying a corresponding constrained executable unit of logic into the constrained execution tree). In some embodiments, the resulting constrained execution tree is translated into a language used by the trustee environment. The resulting execution tree can be executed (e.g., by traversing and executing the hierarchy of executable units of logic of the tree), and the results can be returned to the requesting data consumer.

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

Referring now toFIG. 26, a block diagram of example collaborative intelligence environment2600suitable for use in implementing embodiments of the invention is shown. Generally, collaborative intelligence environment2600is suitable for generation of collaborative intelligence, and, among other things, facilitates constraint computing and constraint querying. Collaborative intelligence environment2600or a portion thereof (e.g., data trustee environment2610) may, but need not, be implemented in a distributed computing environment such as distributed computing environment3000, discussed below with respect toFIG. 30. Any or all of the components of collaborative intelligence environment2600can be implemented as any kind of computing device, or some portion thereof. For example, in an embodiment, tenant devices2601athrough2601nand data consumer devices2603athrough2603ncan each be a computing device such as computing device3100, as described below with reference toFIG. 31. Further, data trustee environment2610may be implemented using one or more such computing devices. In embodiments, these devices can be any combination of a personal computer (PC), a laptop computer, a workstation, a server, a mobile computing device, a PDA, a cell phone, or the like. The components of collaborative intelligence environment2600may communicate with each other via one or more networks, which may include, without limitation, one or more local area networks (LANs) and/or wide area networks (WANs). Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets, and the Internet.

Collaborative intelligence environment2600includes data trustee environment2610that is capable of deriving collaborative data and/or collaborative intelligence from raw data provided by data owners or providers (e.g., tenants) subject to configurable constraints, without sharing the raw data. Generally, any number of tenants can input their data (e.g., datasets2605athrough2605n) into data trustee environment2610and designate one or more constraints (e.g., from one of tenant devices2601athrough2601n). Data trustee environment2610can derive collaborative data (e.g., collaborative datasets2607athrough2607n, shielded collaborative dataset2660) based on the one or more constraints. Any number of data consumers (e.g., operating one of data consumer devices2603athrough2603n) may issue queries on shielded collaborative dataset2660, and data trustee environment2610may derive collaborative intelligence from shielded collaborative dataset2660, subject to the one or more constraints. In some cases, an authorized data consumer (e.g., which may be defined by one or more of the constraints) may be the same person or entity that owns or provided raw data (e.g., one or more of datasets2605athrough2605n) or owns the derived collaborative data (e.g., shielded collaborative dataset2660). In some cases, an authorized data consumer may be some other person or entity.

In the embodiment illustrated inFIG. 26, data trustee environment2610includes constraint manager2615. At a high level, tenants that seek to share data can provide one or more desired computations and constraints (which may be embodied in a contractual agreement) to constraint manager2615through a user interface of data trustee environment2610. The user interface can enable tenants to specify the desired computations and constraints that will control the use of their data in data trustee environment2610, including eligible data sources (e.g., one or more of datasets2605athrough2605n) and how their data may be processed or shared. Various types of constraints may be implemented, including data access constraints, data processing constraints, data aggregation constraints, data sanitation constraints, some combination thereof, or others. The specified computations and constraints, and other features of a tenant agreement, may be stored in a contact database (not depicted) accessible to constraint manager2615.

In the embodiment illustrated inFIG. 26, data trustee environment2610includes data privacy pipeline2620. At a high level, data privacy pipeline2620can accept data from one or more specified sources (e.g., one or more of datasets2605athrough2605n). The data can be ingested, fused, derived, and/or sanitized to generate collaborative data (e.g., one or more of collaborative datasets2607athrough2607n, shielded collaborative dataset2660) based on one or more specified computations and/or constraints. The data privacy pipeline2620can be provided as a distributed computing or cloud computing service (cloud service) implemented in data trustee environment2610, and can be spun up and spun down as needed. In some embodiments, tenants providing data into data privacy pipeline2620cannot access the pipeline. Instead, the pipeline outputs collaborative data subject to applicable constraints. Depending on the designated constraints, the collaborative data can be output from data trustee environment2610as one or more of collaborate datasets2607athrough2607n(e.g., because it has been sanitized according to specified constraints) and/or may be shielded (e.g., stored as shielded collaborative dataset2660) in data trustee environment2610. As explained in more detail below, collaborative dataset2660can be queried to derive collaborative intelligence subject to the configurable constraints.

In the embodiment illustrated inFIG. 26, data privacy pipeline2620includes ingestion component2625(which produces ingested data1830), constrained fusion component2635(which produces fused joint data2640), constrained computation component2645(which produces derived joint data2650), and sanitation component2655(which produces collaborative datasets2607athrough2607nand2660). Initially, one or more of datasets2605athrough2605may be provided to data privacy pipeline2620(e.g., through a user interface, a programming interface, or some other interface of data trustee environment). Ingestion component2625can determine whether input data or some portion thereof, is joint data pursuant to a contract or other tenant agreement. For example, input data or some portion thereof may be identified in some way, and ingestion component2625can communicate with constraint manager2615to confirm whether the identified data is joint data pursuant to a tenant agreement represented in the contract database. Data determined to be joint data can be stored as ingested data2630, and data determined not to be joint data can be dropped.

Ingested data can include data from multiple sources, so constrained fusion component2635may fuse ingested data from multiple sources according to computations and constraints specified in a tenant agreement. For example, constrained fusion component2635can communicate with constraint manager2615to obtain, validate, or request a specified fusion operation pursuant to a tenant agreement represented in the contract database. By way of nonlimiting example, constrained fusion component2635can implement one or more constraints to combine ingested data (e.g., ingested data2630) to form fused joint data (e.g., fused joint data3640) in any number of ways, including the use of one or more join operations (e.g., left, right, inner, outer, anti), custom joins (e.g., via imperative scripts), data appends, normalization operations, some combination thereof, and others.

Generally, constrained computation component2654can perform constrained computations (e.g., on ingested data2630, fused joint data2640) to generate derived joint data (e.g., derived joint data2650). Constrained computing can involve any number of specified computations (e.g., arithmetic operations, aggregation, summarization, filtering, sorting, bounding). Generally, constrained computation component2645can communicate with constraint manager2615to obtain, validate, or request a specified computation pursuant to a tenant agreement represented in the contract database. By way of a simple example, a number of retailers may agree to expose average sales data, so a corresponding computation may involve averaging. A simple example of a constraint computation is a calculation of average age per city, where the computation is only to be performed for a city if the underlying dataset includes entries for at least five people in the city. These are meant simply as examples, and any type of computation and/or constraint can be implemented.

In some embodiments, sanitation component2655can perform data sanitation (e.g., on derived joint data2650) to generate collaborative data (e.g., one or more of collaborative datasets2607athrough2607n, shielded collaborative dataset2660) in a manner that implements constraints for storage, access, precision, and the like. For example, sanitation component2655can communicate with constraint manager2615to obtain, validate, or request a specified sanitation operation pursuant to a tenant agreement represented in the contract database. As such, sanitation component2655can implement a constraint specified in a tenant agreement that designates whether collaborative data should be shielded (e.g., stored as shielded collaborative dataset2650in data trustee environment2610), whether collaborative data can be exported (e.g., as one or more of collaborative datasets2607athrough2607n), whether exported collaborative data should be restricted (e.g., do not export email, credit card numbers, portions thereof), some combination thereof, and the like. In some embodiments, any or all intermediate data used in arriving at collaborative data (e.g., ingested data, fused joint data, derived joint data) may be deleted, for example, in association with spinning down data privacy pipeline2620. As such, data privacy pipeline2620can generate collaborative data from data provided by one or more tenants.

As explained above, constraint manager2615can monitor and orchestrate the use and generation of collaborative data subject to one or more specified constraints. Additionally or alternatively, constraint manager2615can monitor and orchestrate access to collaborative data subject to the constraints. Generally, constraint manager2615can communicate with various components in data trustee environment2610and/or data privacy pipeline2610to implement specified computations and/or constraints, which may be maintained in a contract database accessible to constraint manager2615. In some embodiments, components can issue requests to constraint manager2615for permission to execute a particular command, function call, or other executable unit of logic. Constraint manager2615can 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 of the constraints. By way of nonlimiting example, some possible conditions that can be implemented include requiring operations that shift, filter, or reshape data (e.g., application of comparison constraints such as only allowing a merge with certain precision), requiring substitution of one or more executable units of logic (e.g., commands or operations) with one or more constrained executable units of logic (e.g., replace average with constrained average), and the like.

Generally, a constraint can be checked, validated, or otherwise enforced at any time or step (e.g., in association with any component of data privacy pipeline2620, data trustee environment2610). Accordingly, corresponding functionality enforcing a constraint can be applied at any step, or multiple steps. In some embodiments, enforcement of certain constraints can be allocated to certain components of data privacy pipeline2620(e.g., data access constraints get applied by ingestion component2625, processing and aggregation constraints get applied by constrained fusion component2635and/or constrained computation component2645, sanitation constraints get applied by sanitation component2655). In another example, a particular data access constraint (e.g., only pass data for patients who participated in at least five different studies) may be applied by constrained fusion component2635. These are meant merely as examples, and any suitable constraint enforcement regime may be implemented within the present disclosure.

In some embodiments, constraint manager2615can enforce a constraint (e.g., precision or aggregation constraints) on a particular executable unit of logic (e.g., for a designated computation, a requested operation) by communicating, indicating, or otherwise facilitating any number of dispositions. In one example, constraint manager2615can reject a particular executable unit of logic entirely. In another example, constraint manager2615can allow a particular executable unit of logic, but require the result to be filtered (e.g., no value is returned for a particular row or entry of data). In yet another example, constraint manager2615can allow a particular executable unit of logic, but require the result to be changed (e.g., precision reduced, a question is answered with false). These and other variations may be implemented.

As constraints are applied to generate collaborative data (e.g., collaborative datasets2607athrough2607n, shielded collaborative dataset2670), any combination of schema, constraints, and/or attribution metadata can be associated with the collaborative data, intermediate data used to arrive at the collaborative data (e.g., ingested data2630, fused joint data2640, derived joint data2650), or otherwise. Generally, constraints can be enforced across multiple steps and computations. As such, in some embodiments, applicable and/or satisfied constraints for each step can be tracked and/or associated with data produced by a given component of data privacy pipeline2620. Taking aggregation constraints as an example, once an aggregation constraint has been fulfilled by a particular component of data privacy pipeline2620, downstream components no longer need to consider this constraint. In another example where different constraints have been specified for different datasets to be merged, a merging operation may only need to apply the stricter constraint. Generally, an appropriate allocation or combination of constraints can be applied and/or tracked as data flows through data privacy pipeline2620. This tracking can facilitate validating whether a particular constraint has been applied to particular data. Accordingly, as constraints are applied and data is generated, corresponding schema, applicable or satisfied constraints, and/or attribution metadata indicating ownership or providence of the data can be associated with a dataset, or a corresponding entry, row, field, or other element of data. Generally, the schema, applicable or satisfied constraints, and/or attribution metadata can be generated pursuant to a tenant agreement represented in the contract database (e.g., via communication with constraint manager2615). In some embodiments, any or all intermediate data used in arriving at collaborative data (e.g., ingested data2630, fused joint data2640, derived joint data2650) may be deleted, and collaborative data may be stored in data trustee environment2610as shielded collaborative dataset2660and/or exported as one or more of collaborative datasets2607athrough2607n, depending on an applicable constraint.

In some embodiments, data trustee environment2610includes constrained querying component2670, which can apply constraint querying to allow data consumers (e.g., operating one of data consumer devices2603athrough2603n) to query collaborative data (e.g., shielded collaborative dataset2660) in data trustee environment2610subject to one or more specified constraint. At a high level, constrained querying component2670can operate as a search engine that allows data consumers to access or derive collaborative intelligence from shielded collaborative dataset2660, without exposing raw data provided by a tenant (e.g., one or more of datasets2605athrough2605n), intermediate data used to generate the shielded collaborative dataset2660(e.g., ingested data2630, fused joint data2640, derived joint data2650), and/or shielded collaborative dataset2660. Generally, constrained querying component2670can communicate with constraint manager2615to obtain, validate, or request a specified operation pursuant to a tenant agreement represented in the contract database. Constrained querying component2670can facilitate enforcement of constraints in response to a query in any number of ways, including reformatting a query prior to execution, applying constraints after executing a query, constraining eligible queries for execution (e.g., only permit a set of whitelisted queries), applying access constraints prior to execution, and others.

Turning now toFIG. 27,FIG. 27is a block diagram of an example constrained querying component2700, in accordance with embodiments described herein. Constrained querying component2700may correspond with constrained querying component2670ofFIG. 26. At a high level, constrained querying component2700can operate as a search engine, enabling data consumers to query collaborative data and derive collaborative intelligence therefrom, subject to one or more constraints designated in a corresponding tenant agreement. By way of background, queries are generally not executable code. In order to execute a query, the query is normally converted into an execution tree, which serves as the basis for an execution plan that is executable. Generally, constrained querying component2700can enforce constraints, or facilitate the enforcement of constraints, by reformatting an execution tree corresponding to a received query to account for any applicable constraints prior to execution. In a simple example, a constraint may permit queries on compensation data, but the result has to be rounded. As such, the query and/or its corresponding execution tree can be reformatted prior to execution, such that any returned search results account for applicable constraints. In the embodiment illustrated inFIG. 27, constrained querying component2700includes access constraint component2720, query parser2730, constraint query formatter2740, translation component2750, and execution component2760. This configuration is meant merely as an example, and other configurations with similar or different functionality may be implemented in accordance with the present disclosure.

At a high level, constrained querying component2700may receive query2710issued by a data consumer (e.g., operating one of data consumer devices2603athrough2603nofFIG. 26) requesting collaborative intelligence based on collaborative data (e.g., shielded collaborative dataset2660ofFIG. 26). Query2710may take any suitable form or query language, and may comprise one or more requested operations on collaborative data. In some embodiments, query2710may specify or otherwise be associated with runtime information, such as information identifying the requesting data consumer issuing the query, information identifying an applicable tenant agreement, information identifying target collaborative data on which to operate, and the like.

In some embodiments, access constraint component2720can use the runtime information associated with query2720to trigger a lookup and enforcement of an applicable data access constraint (e.g., via communication with constraint manager2615ofFIG. 26). For example, access constraint component2720can validate query2710against a corresponding constraint context comprising an applicable data access constraint and the runtime information associated with query2710. Generally, in scenarios where a data consumer is not authorized to access a collaborative dataset, target collaborative data within a collaborative dataset (e.g., a particular row of data), a particular type of requested collaborative intelligence to be derived, access constraint component2720can deny the request. In this case, access constraint component2720may return a notification to the issuing data consumer informing the data consumer that the requested query was denied. If the requested access is determined to be authorized and/or consistent with an applicable data access constraint, query2710can be passed to query parser2730.

Generally, query parser2730can parse query2710and generate a corresponding execution tree2735. At a high level, execution tree2735comprises a hierarchical arrangement of executable units of logic that, when executed, implement query2710. The executable units of logic can include any suitable arrangement and combination of commands, operations, function calls, and the like. Constraint query formatter2740can access applicable constraints (e.g., via communication with constraint manager2615ofFIG. 26) and can validate the executable units of logic of execution tree2735against the constraints. In some embodiments, if one or more of the executable units of logic is not allowed, query2710can effectively be reformatted by adding, removing, and/or altering one or more executable units of logic based on one or more constraints.

More specifically, constraint query formatter2740can reformat execution tree2735into constrained execution tree2745by traversing execution tree2735and replacing executable units of logic inconsistent with a particular constraint with custom executable units of logic that are consistent with the constraint. Additionally or alternatively, constraint query formatter2740can add or remove one or more executable units of logic to enforce constraints (e.g., precision constraints) on the output. Generally, constraint query formatter2740can validate an executable unit of logic of execution tree2735against a corresponding constraint context comprising an applicable constraint and the runtime information associated with query2710. This check can involve validation of a constituent command or operation, one or more constituent parameters, and/or consideration of other parts of execution tree2735, and can result in a number of possible results. For example, an executable unit of logic can be allowed (e.g., the executable unit of logic can be copied into constrained execution tree2735), an executable unit of logic can be disallowed (e.g., query2710can be disallowed in its entirety), or an executable unit of logic can be allowed but with changes (e.g., copying a corresponding constrained executable unit of logic into constrained execution tree2745). These are meant simply as examples, and other variations are contemplated within the present disclosure.

As such, constraint query formatter2740can evaluate each executable unit of logic against the constraints, add or remove executable units of logic, and/or replace one or more executable units of logic inconsistent with a constraint with a custom executable unit of logic that incorporates and/or applies the constraint. Mappings between executable units of logic and custom executable units of logic and/or executable units of logic corresponding to one or more constraints (e.g., a list of rules) can be retrieved, accessed, and/or maintained in any suitable manner (e.g., stored locally, accessed via communication with constraint manager2615ofFIG. 26, some combination thereof, or otherwise). Mappings can be one-to-one, one-to-many, or many-to-one.

In some embodiments, a received query may not be in the same query language used by the target collaborative dataset (e.g., shielded collaborative dataset2660ofFIG. 26). As such, translation component2750can translate constrained execution tree2745from a first query language to a second query language. That is, translation component can translate constrained execution tree2745into translated constrained execution tree2755. Any suitable query language may be implemented (e.g., SQL, SparkQL, Kusto Query Language, C# Linq). In some embodiments, constrained execution tree2745and/or translated constrained execution tree2755can be executed to test for failure, and a failure may result in rejection of a particular execution, a set of executable units of logic, the entire query2710, or otherwise.

A resulting execution tree (e.g., constrained execution tree2745and/or translated constrained execution tree2755, as the case may be) can be passed to execution component2760for execution (e.g., execution of a corresponding execution plan). Generally, this execution operates to derive collaborative intelligence2770from collaborative data. In some embodiments, collaborative intelligence2770is returned to the requesting data consumer as is. In some embodiments, one or more constraints may additionally or alternatively be enforced on collaborative intelligence2770prior to transmission to the requesting data consumer.

By way of nonlimiting example, assume that pursuant to a particular tenant agreement, a number of retailers have agreed to expose sales data that includes some sensitive customer information that should not be exposed. In this example, the tenant agreement specifies a number of constraints, including requirements of at least 20 unique customers per aggregation, aggregations must span at least 48 hours, no aggregation by userid, no export of userid, and round numeric results to the nearest two digits. Assume further that the tenant agreement allows a data consumer to derive the average amount of money spent by each customer in each store each week.FIG. 28Aillustrates an example of a corresponding query2810in Structured Query Language (SQL). This query language is meant merely as an example, and any suitable query structure may be implemented.

Query2810may be parsed and converted into a corresponding execution tree (e.g., by query parser2730ofFIG. 27).FIG. 28Billustrates a simplified representation of an example execution tree2820that corresponds with query2810ofFIG. 28A. Generally, in a query execution tree, each executable unit of logic receives data from a previous executable unit of logic and one or more parameters for transforming the data. When executing execution tree2820, data gets passed along the left branch of execution tree2820, from the bottom to the top. As the data gets passed, each executable unit of logic applies one or more associated commands or operations. As will be appreciated by those of ordinary skill in the art, execution tree2820comprises a hierarchical arrangement of executable units of logic that, if executed, would implement query2810.

To account for applicable constraints, execution tree2820can be converted into constrained execution tree2910ofFIG. 29A(e.g., by constraint query formatter2740ofFIG. 27). Differences between execution tree2820ofFIG. 28Band constrained execution tree2910ofFIG. 29Aare illustrated with boxes drawn around the different elements. For example, constrained execution tree2910includes a rounding operation2915that implements the constraint described above in which numeric results must be rounded to the nearest two digits. In another example, constrained execution tree2910includes a filtering operation2925that implements the constraint described above in which aggregations must include data for at least 20 unique customers. This configuration for constrained execution tree2910is simply meant as an example, and any suitable configuration may be implemented.FIG. 29Billustrates an example of a corresponding query2920that corresponds with constrained execution tree2910, for illustration purposes. As will be appreciated, query2920includes additional elements not present in query2810that serve to enforce the example constraints described above. Constrained execution tree2910can be executed by traversing and executing the hierarchy of executable units of logic of the tree along the left branch, from bottom to top, as will be appreciated by those of ordinary skill in the art. As such, constrained execution tree2910can be executed to derive collaborative intelligence, and the collaborative intelligence can be returned to a requesting data consumer.

Example Distributed Computing Environment

Referring now toFIG. 30,FIG. 30illustrates an example distributed computing environment3000in which implementations of the present disclosure may be employed. In particular,FIG. 30shows a high level architecture of an example cloud computing platform3010that can host a collaborative intelligence environment, or a portion thereof (e.g., a data trustee environment). It should be understood that this and other arrangements described herein are set forth only as examples. For example, as described above, many of the elements described herein may be implemented as discrete or distributed components or in conjunction with other components, and in any suitable combination and location. Other arrangements and elements (e.g., machines, interfaces, functions, orders, and groupings of functions) can be used in addition to or instead of those shown.

Data centers can support distributed computing environment2400that includes cloud computing platform3010, rack3020, and node3030(e.g., computing devices, processing units, or blades) in rack3020. The collaborative intelligence environment and/or data trustee environment can be implemented with cloud computing platform3010that runs cloud services across different data centers and geographic regions. Cloud computing platform3010can implement fabric controller3040component for provisioning and managing resource allocation, deployment, upgrade, and management of cloud services. Typically, cloud computing platform3010acts to store data or run service applications in a distributed manner. Cloud computing infrastructure3010in a data center can be configured to host and support operation of endpoints of a particular service application. Cloud computing infrastructure3010may be a public cloud, a private cloud, or a dedicated cloud.

Node3030can be provisioned with host3050(e.g., operating system or runtime environment) running a defined software stack on node3030. Node3030can also be configured to perform specialized functionality (e.g., compute nodes or storage nodes) within cloud computing platform3010. Node3030is allocated to run one or more portions of a service application of a tenant. A tenant can refer to a customer utilizing resources of cloud computing platform3010. Service application components of cloud computing platform3010that support a particular tenant can be referred to as a tenant infrastructure or tenancy. The terms service application, application, or service are used interchangeably herein and broadly refer to any software, or portions of software, that run on top of, or access storage and compute device locations within, a datacenter.

When more than one separate service application is being supported by nodes3030, nodes3030may be partitioned into virtual machines (e.g., virtual machine3052and virtual machine3054). Physical machines can also concurrently run separate service applications. The virtual machines or physical machines can be configured as individualized computing environments that are supported by resources3060(e.g., hardware resources and software resources) in cloud computing platform3010. It is contemplated that resources can be configured for specific service applications. Further, each service application may be divided into functional portions such that each functional portion is able to run on a separate virtual machine. In cloud computing platform3010, multiple servers may be used to run service applications and perform data storage operations in a cluster. In particular, the servers may perform data operations independently but exposed as a single device referred to as a cluster. Each server in the cluster can be implemented as a node.

Client device3080may be linked to a service application in cloud computing platform3010. Client device3080may be any type of computing device, which may correspond to computing device3000described with reference toFIG. 30, for example. Client device3080can be configured to issue commands to cloud computing platform3010. In embodiments, client device3080may communicate with service applications through a virtual Internet Protocol (IP) and load balancer or other means that direct communication requests to designated endpoints in cloud computing platform3010. The components of cloud computing platform3010may communicate with each other over a network (not shown), which may include, without limitation, one or more local area networks (LANs) and/or wide area networks (WANs).

Example Operating Environment

With reference toFIG. 31, computing device3100includes bus3110that directly or indirectly couples the following devices: memory3112, one or more processors3114, one or more presentation components3116, input/output ports3118, input/output components3120, and illustrative power supply3122. Bus3110represents what may be one or more buses (such as an address bus, data bus, or combination thereof). The various blocks ofFIG. 31are shown with lines for the sake of conceptual clarity, and other arrangements of the described components and/or component functionality are also contemplated. For example, one may consider a presentation component such as a display device to be an I/O component. Also, processors have memory. We recognize that such is the nature of the art, and reiterate that the diagram ofFIG. 31is merely illustrative of an example computing device that can be used in connection with one or more embodiments of the present invention. Distinction is not made between such categories as “workstation,” “server,” “laptop,” “hand-held device,” etc., as all are contemplated within the scope ofFIG. 31and reference to “computing device.”

I/O ports3118allow computing device3100to be logically coupled to other devices including I/O components3120, some of which may be built in. Illustrative components include a microphone, joystick, game pad, satellite dish, scanner, printer, wireless device, etc.

With reference to the collaborative intelligence environment described herein, embodiments described herein support constraint computing and/or constraint querying. The components of the collaborative intelligence environment can be integrated components that include a hardware architecture and a software framework that support constraint computing and/or constraint querying functionality within a collaborative intelligence system. The hardware architecture refers to physical components and interrelationships thereof, and the software framework refers to software providing functionality that can be implemented with hardware embodied on a device.

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

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