Multi-Actor and Cross-Environment Pipelines

Abstract

Embodiments relate to techniques for building, configuring, triggering and executing various types of multi-party pipelines, which access and / or use shielded assets that need to exist or execute in a data trustee environment. Typically, authorized participants can build on template data privacy pipelines and other shielded assets to create other pipelines. Building blocks (such as entitlements, cross-environment pipelines and / or shielded assets managed by various collaborative smart contracts) can be used to build more complex pipelines, which can include any number of data privacy pipelines, cross-environment pipelines, input data sets, calculation steps, output data sets, permissible queries, participants and / or management collaborative smart contracts. In this way, various types of multi-participant pipelines can be built, 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 data trustee environments.

Description

Background Art

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

[0002] Embodiments of the present disclosure relate to techniques for building, configuring, triggering, and executing various types of multi-participant pipelines that access and / or use shielded assets that need to exist or execute within a data trustee environment. Typically, access to shielded assets can be managed by a collaborative smart contract among multiple collaborators that specifies the configuration of a data privacy pipeline or some other shielded assets (e.g., computational steps, collaborative data sets, etc.). Data privacy pipelines and other shielded assets can be thought of as templates or patterns that can be triggered and written by authorized participants in a data trustee environment. The present disclosure describes how participants can build on such pipelines and other shielded assets to create other pipelines.

[0003] When a collaborative smart contract authorizes a participant to access and / or use a shielded asset such as a template data privacy pipeline (or some part thereof), the participant can use the shielded asset to build other more complex pipelines. This introduces many possible configurations and use cases described herein, such as rights, cross-environment pipelines, and multi-contract, multi-participant pipelines. For example, an authorized participant can grant another participant the right to use a specific shielded asset within a data trustee environment, which is subject to specific rights constraints and / or policy restrictions. With the granted rights, the beneficiary can use the shielded asset in its own pipeline, and when executed, the pipeline can access and use the shielded asset, and any specific rights constraints and / or policies can be enforced. In another example configuration, the cross-environment pipeline can include some pre-processing or post-processing, which occurs outside the data trustee environment, combined with a data privacy pipeline or some other shielded assets that need to exist or execute within the data trustee environment.

[0004] Rights, 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 managed by different collaborative smart contracts. In another example, different participants of a single collaborative smart contract can use shielded assets managed by the contract in their own pipelines. It should be understood that the various building blocks described herein can be used to build more complex pipelines, including any number of data privacy pipelines, cross-environment pipelines, input data sets, computation steps, output data sets, permissible queries, participants, and / or management collaborative smart contracts.

[0005] In this way, rights, cross-environment pipelines, and / or shielded assets managed by various collaborative smart contracts can be used to establish 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 the owner, or collaborative data shielded by the data trustee environment.

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

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

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

[0009] Figure 2 is a block diagram of an example constraint manager according to embodiments described herein;

[0010] Figure 3 is a block diagram of an example multi-participant pipeline according to embodiments described herein;

[0011] Figure 4 is a block diagram of an example entitlement and multi-participant pipeline according to embodiments described herein;

[0012] Figure 5A-5C is a block diagram of example entitlements for establishing a multi-contract, multi-participant pipeline according to embodiments described herein;

[0013] Figure 6 is a block diagram of an example cross-environment pipeline according to embodiments described herein;

[0014] Figure 7 is a block diagram of an example multi-contract, multi-participant pipeline according to embodiments described herein;

[0015] Figure 8-Figure 10 is a flow chart illustrating an example method for generating a data privacy pipeline according to embodiments described herein;

[0016] Fig.11 is an illustration of an example user interface for browsing collaborative smart contracts according to embodiments described herein;

[0017] Fig.12 is an illustration of an example user interface for naming a new collaborative smart contract according to embodiments described herein;

[0018] Fig.13 is a schematic diagram of an example user interface for specifying inputs to a data privacy pipeline associated with a collaborative smart contract according to embodiments described herein;

[0019] Fig.14 is a schematic diagram of another example user interface for specifying inputs to a data privacy pipeline associated with a collaborative smart contract according to embodiments described herein;

[0020] Figure 15A-15B is a schematic diagram of an example user interface for specifying an input scheme for an input data set associated with a collaborative smart contract according to embodiments described herein;

[0021] Figure 16A-16C is a schematic diagram of an example user interface for creating a new computation step in a data privacy pipeline associated with a collaborative smart contract according to embodiments described herein;

[0022] Figure 17A-17B is a schematic diagram of an example user interface for specifying input schemes for computation steps in a data privacy pipeline associated with a collaborative smart contract according to embodiments described herein;

[0023] Figures 18A-18C is a schematic diagram of an example user interface for specifying computations for computation steps in a data privacy pipeline associated with a collaborative smart contract according to embodiments described herein;

[0024] Figure 19A-19B is a schematic diagram of an example user interface for specifying output schemes for computation steps in a data privacy pipeline associated with a collaborative smart contract according to embodiments described herein;

[0025] Fig. 20 is a schematic diagram of an example user interface summarizing computation steps in a data privacy pipeline associated with a collaborative smart contract according to embodiments described herein;

[0026] Fig.21is a schematic diagram of an example user interface for specifying contract outputs associated with a collaborative smart contract according to embodiments described herein;

[0027] Figure 22A-22B is a schematic diagram of an example user interface for specifying an output data set from a data privacy pipeline associated with a collaborative smart contract according to embodiments described herein;

[0028] Figure 23A-23D is a schematic diagram of an example user interface for specifying permissible named queries associated with a collaborative smart contract according to embodiments described herein;

[0029] Fig.24A is a schematic diagram of an example user interface for specifying contract outputs associated with a collaborative smart contract according to embodiments described herein;

[0030] Fig. 24B is a schematic diagram of an example user interface for reviewing, approving, and deploying collaborative smart contracts according to embodiments described herein;

[0031] Figure 25A-Figure 25E is a schematic diagram of an example user interface for browsing and interacting with accessible resources according to embodiments described herein;

[0032] Fig.26 is a block diagram of an example collaborative intelligent environment according to embodiments described herein;

[0033] Fig. 27 is a block diagram of an example constrained query component according to embodiments described herein;

[0034] Fig.28A are examples of queries issued according to embodiments described herein;

[0035] Fig.28B is an example of a corresponding execution tree according to the embodiments described herein;

[0036] Fig.29A is an example of a constrained execution tree according to embodiments described herein;

[0037] Fig.29B is an example of a corresponding query according to embodiments described herein;

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

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

[0040] Overview

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

[0042] However, there are also many problems and barriers to sharing data. In fact, different industries differ in their ability and willingness to share data. Data privacy and confidentiality issues are fundamental to many industries such as healthcare and banking. In many cases, laws, regulations, and consumer requirements impose constraints on the ability to share data. In addition, the actions of observing, collecting, extracting, and analyzing data sets are often an expensive and labor-intensive task, and many people worry that sharing data will lose competitive advantage. Even if there is sufficient motivation to share data, the problem of controlling and accessing shared data is often a barrier to sharing. In fact, these barriers often hinder data sharing and the opportunities for progress that come with it. As such, data sharing technologies are needed to promote the development of collaborative intelligence while ensuring data privacy and promoting control and access to shared data.

[0043] Therefore, embodiments of the present disclosure relate to techniques for building, configuring, triggering, and executing various types of multi-participant pipelines (e.g., multi-tenant pipelines) that access and / or use shielded assets that need to exist or execute within a data trustee environment. As used herein, a data pipeline that needs to be executed within a data trustee environment is referred to as a data privacy pipeline. Typically, the configuration of a data privacy pipeline can be specified by one or more participants and managed by a collaborative smart contract. A data privacy pipeline can be considered a template or pattern that can be triggered and written by authorized participants. Previous applications describe how participants collaborate to establish a collaborative smart contract that specifies the 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 a data trustee environment) can build on top of such pipelines and other shielded assets to create other pipelines (e.g., multi-participant pipelines, such as multi-tenant pipelines). Typically, when a collaborative smart 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 establish other more complex pipelines. This introduces many possible configurations and use cases described in this article, such as cross-environment pipelines and multi-contract, multi-participant pipelines across data trustee environments.

[0044] When establishing a pipeline, participants can utilize a variety of techniques to access shielded assets that need to exist or execute within the data trustee environment. Typically, collaborative smart contracts can specify and parameterize access to any number of shielded assets, such as data sets, computational steps, pipelines, jobs, queries, audit events, etc. In addition, collaborative smart contracts can parameterize access control for specified participants on an element-by-element basis. Access control features can be customized for specific user accounts, user groups, or some other basis. In this way, a contract can selectively allow access and / or use of specific parts or even all contracts, pipelines, or some other shielded assets of a contract, pipeline, or some other shielded asset. Therefore, a collaborative smart contract can include access controls that allow specific participants to access shielded assets, and the data trustee environment can implement these access controls.

[0045] In some embodiments, a collaborative smart contract may allow a party or other authorized participant to grant another participant the right to use a specified shielded asset within a data trustee environment, subject to any specified rights constraints and / or policy restrictions. For example, a data contributor may want to provide access to its data (or some other shielded assets), but may not want to participate in the approval and enforcement of a complex pipeline that uses its data. In this case, a data contributor may grant a specific beneficiary the right to access and / or use its data, subject to specified rights constraints and / or policy restrictions. In an embodiment where rights grant permissions to shielded assets (managed by a collaborative smart contract between multiple parties), the identity of the beneficiary may, but not necessarily, be available to other parties to the contract. With the granted rights, the beneficiary can use the data in its own pipeline, subject to any rights constraints and / or policy restrictions specified by the data contributor. For example, a beneficiary can collaborate with others to establish a data privacy pipeline, and when executed, the data privacy pipeline can pull in data from the contributor, as well as any specified rights constraints and / or policies. In this case, data contributors do not need to be parties to the management of downstream collaborative smart contracts, nor do they need to participate in the construction of the downstream data privacy pipeline. Instead, rights constraints and / or policies can be enforced by the data trustee environment in relation to the access and / or use of data by beneficiaries. In the context of rights, specific rights constraints govern the use of the grantor's assets (e.g., datasets) when generating rights outputs (e.g., aggregated datasets), while specific rights policies govern the use of rights outputs (e.g., in downstream pipelines). Rights are therefore one possible building block of a data pipeline (such as a data privacy pipeline).

[0046] In some embodiments, the designation of a cross-environment pipeline may include some pre-processing or post-processing that occurs outside the data trustee environment, in conjunction with a data privacy pipeline or some other shielding assets that need to exist or execute within the data trustee environment. Typically, there may be many existing collaborative smart contracts and / or rights that specify different template data privacy pipelines and / or other shielding assets. Any participant who is granted access to and / or use of a specific template or other shielding asset may be subject to any applicable constraints or policies to establish a pipeline that uses shielding assets. Even if shielding assets may need to exist or execute in the data trustee environment, data pipelines may be built on shielding assets without requiring the rest of the data pipelines to exist or execute in the data trustee environment. Therefore, participants can create cross-environment pipelines across data trustee environments. For example, a tenant can create a cross-environment pipeline that uses shielding assets as components in the pipeline. Therefore, a tenant can create or write a cross-environment pipeline that may exist or execute in part in the data trustee environment. This pipeline can be said to span a data trustee environment and can be considered a multi-participant pipeline (or multi-tenant pipeline) because it relies on shielded assets managed by collaborative smart contracts with multiple participants (or tenants of the data trustee environment).

[0047] Rights, cross-environment pipelines and / or shielded assets managed by different collaborative smart contracts can be used to establish 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 managed by different collaborative smart contracts. In another example, different participants of a single collaborative smart contract can use shielded assets managed by the contract in their own pipelines. In some cases, different participants of a collaborative smart contract do not need to know that other participants exist. These are just a few examples of different types of multi-participant pipelines that can be established and triggered. It should be understood that more complex pipelines can be built using the various building blocks described herein, including any number of data privacy pipelines, cross-environment pipelines, input data sets, calculation steps, output data sets, permissible queries, participants and / or management collaborative smart contracts.

[0048] Therefore, the technology described herein facilitates the use of shielded assets to build, trigger and execute various types of multi-participant pipelines. Typically, the data trustee environment can authorize authorized participants (including rights beneficiaries) to use data privacy pipelines or some other shielded assets (e.g., computational steps, collaborative data sets, etc.) that need to exist or execute in the data trustee environment. Therefore, authorized participants can access and / or use data privacy pipelines (or other shielded assets) within the data trustee environment to establish some other pipelines configured to utilize the data privacy pipeline (or other shielded assets). For example, a tenant can create a cross-environment pipeline that uses shielded assets managed by a collaborative smart contract with multiple participants as a component in a pipeline that includes some pre-processing or post-processing that occurs outside the data trustee environment. Other types of multi-participant pipelines include multi-contract, multi-participant pipelines, which are configured to access and / or use shielded assets from multiple contracts, and different participants of a single collaborative smart contract use shielded assets managed by the contract in their own pipelines, as well as others.

[0049] In this way, rights, cross-environment pipelines, and / or shielded assets managed by various collaborative smart contracts can be used to establish 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 the owner, or collaborative data shielded by the data trustee environment.

[0050] Example multi-actor pipeline

[0051] Reference now Figure 1 , a block diagram of an example collaborative intelligence environment 100 suitable for implementing embodiments of the present invention is shown. In general, the collaborative intelligence environment 100 is suitable for the generation of collaborative intelligence, and in particular facilitates constraint computation and constraint querying. The collaborative intelligence environment 100 or a portion thereof (e.g., the data trustee environment 110) may, but need not, be implemented in a distributed computing environment, such as described below with respect to Fig.30 The distributed computing environment 3000 discussed. Any or all components of the collaborative intelligent environment 100 may be implemented as any type of computing device, or some portion thereof. For example, in one embodiment, each of the tenant devices 101a to 101n and the data consumer devices 103a to 103n may be a computing device, such as the one described below with reference to Fig.31The computing device 3100 described above. In addition, the data trustee environment 110 can be implemented using one or more such computing devices. In an embodiment, these devices can be any combination of personal computers (PCs), laptops, workstations, servers, mobile computing devices, PDAs, mobile phones, etc. The components of the collaborative intelligent environment 100 can communicate with each other via one or more networks, which can include, but are not limited to, one or more local area networks (LANs) and / or wide area networks (WANs). Such network environments are common in offices, enterprise-wide computer networks, intranets, and the Internet.

[0052] The collaborative intelligence environment 100 includes a data trustee environment 110 that is capable of extracting 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. In general, any number of tenants can input their data (e.g., data sets 105a to 105n) into the data trustee environment 110 and specify one or more constraints (e.g., from one of the tenant devices 101a to 101n). The data trustee environment 110 can extract collaborative data (e.g., collaborative data sets 107a to 107n, shielded collaborative data set 160) based on one or more constraints. Any number of data consumers (e.g., operating on one of the data consumer devices 103a to 103n) can issue queries to the shielded collaborative data set 160, and the data trustee environment 110 can extract collaborative intelligence from the shielded collaborative data set 160 subject to one or more constraints. In some cases, the 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 provides the original data (e.g., one or more of the data sets 105a through 105n) or owns the extracted collaboration data (e.g., masked collaboration data set 160). In some cases, the authorized data consumer may be another person or entity.

[0053] exist Figure 1In the illustrated embodiment, the data trustee environment 110 includes an interface 112, a constraint manager 115, a data privacy pipeline 120, and a constrained query component 170. At a high level, tenants and other specific contributors seeking to share data can interact with the interface 112 to specify the parameters of the contractual agreement for sharing and accessing data. Typically, the interface 112 can cause the presentation of a user interface that serves as a sandbox for parties to generate, contribute to, or otherwise configure a data privacy pipeline (such as the data privacy pipeline 120), which can serve as the basis for a contractual agreement between the parties. Various types of pipelines are possible and can include any number of pipeline inputs (e.g., input data sets), computational steps, and / or output data sets to be generated. The pipeline can be built on a shielded asset that needs to exist or operate in the data trustee environment 110 and allow participants to access and / or use it. 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 establish 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.).

[0054] The data privacy pipeline can be provided as a distributed computing or cloud computing service (cloud service) implemented in the data trustee environment 110 and can be written or de-written as needed. The constraint manager 115 can monitor and coordinate the use, generation, and access of collaborative data according to specified parameters specified for the protocol. The specified parameters and other characteristics of the protocol can be stored in a contract database (not depicted) accessible to the constraint manager 115. The constrained query component 170 can apply constrained queries to allow authorized data consumers (e.g., operating on one of the data consumer devices 103a to 103n) to query the collaborative data in the data trustee environment 110 according to the specified parameters (e.g., shielded collaborative data set 160). In general, the components of the data trustee environment 110 can correspond to Fig.26 Components of the data trustee environment 2610, which are described in more detail below.

[0055] In some embodiments, interface 112 may cause presentation of a graphical or other visual user interface including any arrangement and orientation of interactive elements capable of receiving input that specifies parameters for a data privacy pipeline and corresponding protocols for sharing data. The user interface may allow an authorized party to a contract or an authorized participant of a pipeline to select, compose, and arrange any number and combination of pipelines. For example, for a particular data privacy pipeline, the user interface may accept specification of pipeline inputs (e.g., input data sets), computational steps, and / or pipeline / contract outputs (e.g., output data sets including collaborative data to be generated by the data privacy pipeline, permissible named queries for the collaborative data, etc.). In some embodiments, interface 112 may be implemented as a web service that prompts a user on a client device to specify parameters through a series of related pages, screens, and / or other interface elements. Once a pipeline is constructed, interface 112 may allow an authorized participant to trigger the pipeline or use the pipeline as a template when establishing other pipelines. An example implementation of interface 112 may cause a user interface (in Figure 11-Figure 2 5 and described in detail below) on a client device. Although in some embodiments, the various user interfaces are described as graphical user interfaces, this need not be the case. Other examples of possible interfaces include programming interfaces, command line interfaces, menu-driven interfaces, form-based interfaces, natural language interfaces, gesture-driven interfaces, optical interfaces, tactile interfaces, and 3D interfaces, to name a few. In general, any suitable interface capable of implementing the functionality described herein is contemplated to be within the scope of the present disclosure.

[0056] In general, interface 112 may prompt contributors to a data privacy pipeline to specify various parameters of the pipeline or a corresponding protocol, and constraint manager 115 may store the parameters and coordinate deployment of the pipeline (and contract, if applicable). Figure 2 An example constraint manager 200 is illustrated, which may correspond to Figure 1 . For any given pipeline or corresponding collaborative smart contract, whether finalized or in development, the constraint manager 200 can store a set 210 of roles, an arrangement 220 of computation steps that form a data privacy pipeline, permissible named queries 230, and specified constraints 240. For example, the set 210 of roles can include specific references to data owners, authorized contributors, and authorized data consumers. Roles 210 can be applied element by element to different elements of computation steps 220 to parameterize access control on an element by element basis. For example, computation steps 220 can authorize data owners to provide input data sets into slots A and / or slots B, and can authorize contributors to provide computation scripts through slots N.

[0057] Typically, the specified computational steps may include a specified computational platform (e.g., Javascript, Kusto query language, SparkQL, Python, C# Linq), specified inputs to the computational steps, specified computations of the computational steps, specified output schemes, some combination thereof, or others. Figure 2 , computation steps 220 are illustrated using a selected example configuration of these elements, including slots for input A and input B, template fusion and map-reduce computations, slot N for custom computations, and a collection of undisclosed computations (illustrated using a padlock symbol). This configuration is intended to be exemplary only, and any suitable computation steps may be specified. These computation steps 220 may also be considered to be templates that may be used by authorized participants as shielded assets to create their own pipelines.

[0058] Figure 3 An example multi-participant pipeline according to certain embodiments is illustrated. In this example, three participants A, B, and C collaborate to establish a pipeline 300, which serves as the basis for a single contract agreement among the three participants. In this simple example, each participant contributes data, and the pipeline 300 is configured to fuse and perform some calculations on the data, and store the results in some queryable storage. Now consider that A does not care about specific calculations or different possible downstream queries, as long as certain specific constraints are met, such as aggregation constraints (for example, access is only allowed when at least N rows or different field values ​​are aggregated). In some embodiments, based on defined rights constraints (applied when using data) or rights policies (enforced on rights output), A can grant some other participants (such as B) the right to use A's data, rather than requiring A to collaborate on the entire pipeline 300, which may require A to review and sign on the entire pipeline.

[0059] Figure 4 Example rights according to certain embodiments are illustrated. In this example, A grants B the right 410 to use A's data (or some other shielded asset that needs to exist or execute in the data trustee environment). In granting the right, A may specify any number of rights constraints on B's use of A's assets to generate some rights output. Additionally or alternatively, A may specify any number of rights policies for downstream use of the rights output. Rights constraints and policies may implement any of the various types of constraints described herein, including, as non-limiting examples, data access constraints, data processing constraints, data aggregation constraints, and / or data cleansing constraints. In Figure 4In the illustrated example, rights 410 carry aggregate constraints 420. Thus, when B accesses and / or uses A's data in accordance with the rights, aggregate constraints 420 may be automatically applied to generate output rights 430. This is just one example, and any other constraints may be applied to the beneficiary's right to use a particular shielded asset. Furthermore, any type of shielded asset may be the subject of a rights grant, assuming the grantor has the appropriate permissions to grant the rights (e.g., an owner of data or scripts grants the right to use the owner's own data or scripts, a participant in a collaborative smart contract (where permissions in the contract allow participants to grant rights) grants the right to use a shielded asset, etc.).

[0060] Technically, rights can be implemented similarly to the way one or more collaborators can establish and configure a data privacy pipeline, as described in more detail below. Where an asset owner or one other actor with appropriate authority grants rights to a beneficiary, the owner can use an interface (e.g., Figure 1 The grantor of a right may create, configure, and deploy the right without any involvement of the beneficiary. In other embodiments, the grantor may grant permissions to the beneficiary to collaborate in creating and configuring the right (e.g., using parameterized access control on an element-by-element basis). In some embodiments, the beneficiary may initiate a request for a right, and the request may be routed to a potential grantor for approval and / or configuration.

[0061] Entitlements are one possible building block that can initiate different types of multi-actor pipelines. Similar to how a data privacy pipeline can be thought of as a template or pattern that can be triggered and initiated by authorized participants, granted rights can be thought of as a template or pattern that can be triggered and initiated by authorized beneficiaries. Thus, beneficiaries can build on granted rights, for example, by using the rights output when building and configuring a pipeline (such as a data privacy pipeline). Figure 4 In the illustrated example, B and C collaborate to build pipeline 440, which serves as the basis for the contractual agreement between the two participants. In building pipeline 440, B can use the output rights 430 from A as one of the inputs into the fusion operation to Figure 3400. The difference between pipeline 300 and pipeline 440 is that A no longer needs to participate in establishing, configuring, or approving pipeline 440. In this example, when an authorized participant of pipeline 440 (e.g., B or C) triggers the pipeline, A's data is accessed, aggregated 420, and output 430 into pipeline 440, which merges output 430 with B's data and C's data. In embodiments where rights 410 are used as the basis for a contractual agreement between A and B and pipeline 440 is used as the basis for a contractual agreement between B and C, the combination of rights 410 and pipeline 440 can be considered a multi-contract, multi-participant pipeline 400. The following discussion Figure 5C Another possible multi-contract, multi-participant pipeline 530 is depicted.

[0062] Figure 5A-5C Illustrated is the use of entitlements to build a multi-contract, multi-participant pipeline according to embodiments described herein. Figure 5A and 5B Example rights 510 and 520 are illustrated. While these are described as rights, they may additionally or alternatively be implemented as a data privacy pipeline, some portion thereof, or some other shielding asset. Figure 5A and Figure 5B In the illustrated example, A is the owner of the Fusion 1 script, and B is the owner of the Fusion 2 script. A can grant rights 510 to any beneficiary (indicated by an asterisk) to access and / or use the Fusion 1 script, and B can grant rights 520 to any beneficiary (indicated by an asterisk) to access and / or use the Fusion 2 script. Assume that C has been granted rights 510 and 520. Now, C can build its own pipeline 530 including the Fusion 1 script and the Fusion 2 script. Pipeline 530 is configured to first fuse C's data with A's data using A's Fusion 1 script, and then fuse the output with B's data using B's Fusion 2 script. When C triggers pipeline 530, 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 an embodiment where rights 510 is used as the basis for a contractual agreement between A and C, and rights 520 is used as the basis for a contractual agreement between B and C, pipeline 530 built by C using multiple contracts with multiple participants can be considered another example of a multi-contract, multi-participant pipeline.

[0063] In some embodiments, data pipelines that span multiple environments can be built and configured. Typically, once a participant is granted access to a shielded asset that needs to exist (e.g., a data set) or execute (e.g., a script) within a data trustee environment, the participant can build from that asset. Although the asset may be restricted to the data trustee environment, a data pipeline that relies on or otherwise uses the asset may include some pre-processing or post-processing steps that do not need to occur in the data trustee environment. Figure 6 An example cross-environment pipeline according to certain embodiments is illustrated. In this example, A and B have their own data pipelines 620 and 630, which are configured to feed data into the data privacy pipeline 610 (or some other shielded asset) that A and / or B have established and configured. For example, A's data pipeline 620 can be configured to perform some pre-processing by reading from a cloud storage device, performing a transformation, and filtering the results before feeding the filtered results into the data privacy pipeline 610. B's data pipeline 630 can be configured to read data from B's cloud storage device account, transform it, generate a report, and feed the report into the data privacy pipeline 610. In this example, the data privacy pipeline 610 can pull in A's filtered results and B's report, perform some agreed-upon calculations to extract insights (collaborative intelligence) without exposing each other's data, and the insights can be output back to A and B's data pipelines 620 and 630. In A's data pipeline 620, the insights are used to train a machine learning model. In B's data pipeline 630, insights are screened and used to generate reports. In this example, data privacy pipeline 610 is limited to the data trustee environment, while A's data pipeline 620 and B's data pipeline 630 span the data trustee environment. Therefore, data pipelines 620 and 630 can be considered cross-environment pipelines.

[0064] Typically, rights managed by different collaborating smart contracts (e.g., a template data privacy pipeline), cross-environment pipelines, and / or shielded assets can be used to build various types of multi-contract, multi-participant pipelines. Figure 7 An example multi-contract, multi-participant pipeline according to certain embodiments is illustrated. In this example, participants A, B, C, D, E, and F each have their own cross-environment data pipelines 705, 715, 720, 730, 740, and 750, respectively, and some participants also collaborate to build and configure various data privacy pipelines (or some other shielded assets). Such scenarios may occur in any number of industries. For example, participants A, B, C, D, E, and F may be hospitals and researchers who collaborate to try to determine cancer treatments. Some of the participants may want to contribute algorithms, and the rest may want to contribute medical data, and they all want to write pipelines to extract insights without exposing the underlying data or algorithms. To this end, certain combinations of participants can collaborate to build and configure data privacy pipelines.

[0065] exist Figure 7 , A, B, and C are participants in data privacy pipeline 710, which operates on data pipelines 705, 715, and 720 of A, B, and C and extracts collaborative intelligence. C and D are participants in data privacy pipeline 725, which operates on data pipelines 720 and 730 of C and D and extracts collaborative intelligence. D and E are participants in data privacy pipeline 735, which operates on data pipelines 730 and 740 of D and E and extracts collaborative intelligence. E and F are participants in data privacy pipeline 745, which operates on data pipelines 540 and 550 of E and F and extracts collaborative intelligence, and so on. These pipelines are combined to form a large multi-contract, multi-participant pipeline 700 that serves the combined business goals of the various participants. Although in this example, the participants are described as knowing each other, this is not necessarily the case. For example, A and B do not need to know that C is collaborating with D, C does not need to know that D is collaborating with E, and so on.

[0066] Another way to implement this type of pipeline is to have all participants A, B, C, D, E, and F collaborate to establish and configure a master data privacy pipeline that serves as the basis for a single contract between all participants. However, by breaking down the data flow into smaller, more discrete units, it becomes easier to reach consensus among fewer participants and manage smaller collaborative units. Therefore, multi-contract, multi-participant pipelines can encourage data sharing and the development of collaborative intelligence while ensuring data privacy and promoting control and access to shared data.

[0067] Example Flowchart

[0068] refer to Figure 8-Figure 10 , flow charts illustrating various methods related to the generation of a data privacy pipeline are provided. The methods may be performed using the collaborative intelligence environment described herein. In an embodiment, one or more computer storage media have computer executable instructions implemented thereon, which, when executed by one or more processors, may cause the one or more processors to perform the method in an autonomous upgrade system.

[0069] Now turn to Figure 8, a flow chart illustrating a method 800 for generating a data privacy pipeline is provided. Initially, at block 810, 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 the designation of: (i) inputs into the multi-participant pipeline, (ii) one or more computational steps of the multi-participant pipeline, (iii) a designated use of at least one shielding asset, the shielding asset being governed by a collaborative smart contract between one of the participating tenants and a non-participating tenant of the data trustee environment (not a participant of the multi-participant pipeline), the data trustee environment being configured to: restrict the at least one shielding asset to the data trustee environment based on the collaborative smart contract, and (iv) at least one of an output data set or a permissible permissible query. At block 820, upon being triggered by an authorized tenant of the plurality of participating tenants, the data trustee environment deploys the configuration of the multi-participant pipeline in the data trustee environment without exposing the at least one shielding asset.

[0070] Now turn to Fig. 9 , a flowchart illustrating a method 900 for generating a data privacy pipeline is provided. Initially, at box 910, 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 smart 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 smart contract between the participating tenant and a second tenant of the data trustee environment. In this example, the data trustee environment is configured to restrict the first shielded asset and the second shielded asset to the data trustee environment based on the first and second collaborative smart contracts, respectively. At box 920, a configuration of the data privacy pipeline is received from the participating tenant. In this example, the received configuration includes a designation of: (i) inputs into the data privacy pipeline, (ii) one or more computational steps of the data privacy pipeline; (iii) a designated use of the first shielded asset and the second shielded asset, and (iv) at least one of an output data set or a permissible query. Because the first shielded asset is managed by the first collaborating smart contract, and the second shielded asset is managed by the second collaborating smart contract, the data privacy pipeline can be considered a multi-contract pipeline because it utilizes shielded assets managed by multiple contracts. At block 930, once triggered by a participating tenant, the configuration of the data privacy pipeline is deployed in the data trustee environment without exposing the first shielded asset or the second shielded asset.

[0071] Now turn to Fig.10, a flowchart illustrating a method 1000 for generating a data privacy pipeline is provided. Initially, at block 1010, 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 smart contract between the first tenant and a second tenant of the data trustee environment. In this example, the data trustee environment is configured to restrict the shielded asset to within the data trustee environment based on the collaborative smart contract. At block 1020, the first tenant receives a configuration of the data privacy pipeline. In this example, the received configuration includes a designation of the use of the shielded asset, and includes a designation of 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 that triggers post-processing outside the data trustee environment. Because the data privacy pipeline can accept inputs based on pre-processing performed outside the data trustee environment, or accept outputs that trigger post-processing outside the data trustee environment, it can be considered as part of a cross-environment data pipeline across data trustee environments. At block 1030 , once triggered by the first tenant, the configuration of the data privacy pipeline is deployed in the data trustee environment without exposing the shielded assets.

[0072] Example sandbox interface for building a data privacy pipeline

[0073] Figure 11-Figure 2 5 illustrates various example user interfaces capable of receiving input for building and configuring a data privacy pipeline to generate collaborative data. Fig.11 is a diagram of an example user interface 1100 for browsing collaborative smart contracts. The user interface 1100 may be accessed through a portal of a distributed or cloud computing service such as More specifically, the collaborative smart service can be associated with an authorized tenant account, such that access to the collaborative smart service is granted through the tenant account. User interface 1100 is an example interface that allows a user to browse assets available to a tenant account, such as an existing collaborative smart contract for which the tenant account is an authorized participant. For example, banner 1110 may provide a resource menu 1120 that allows a user to browse existing contracts, accessible data sets (e.g., stored by a tenant account), accessible scripts (e.g., stored by a tenant account), pipelines (e.g., for which the tenant account is authorized), jobs (e.g., initiated, associated, or otherwise accessible by a tenant account), queries (e.g., initiated, associated, or otherwise accessible by a tenant account), audit events (e.g., operations related to one of the above resources initiated, associated, or otherwise accessible by a tenant account), and the like. In Fig.11In the example shown, available contracts are selected from resource menu 1120 for browsing, and user interface 1100 presents existing contracts 1130, which include an indication of the status of each contract. The presented contracts 1130 may be selectable for viewing and / or editing. User interface 1100 may include interactive element 1140 that accepts input indicating that a new contract should be created.

[0074] User interface 1100 provides an example interface for browsing collaborative smart contracts. Other interfaces corresponding to other resources are not depicted, but can be implemented using functions corresponding to the resources being browsed. For example, a user interface configured to browse available scripts can allow filtering by name, owner, and / or script type (e.g., computing platform, functional category, etc.). In another example, a user interface configured to browse available data sets can present information about data sets, or otherwise make information about data sets available (e.g., through clickable links or menus), such as name, identifier, owner, storage location, creation time, last read time, last write time, tags associated with data sets, and / or any other type of relevant information. Typically, a user interface configured to browse available resources can include functions that allow users to create, select, edit, delete, grant access rights, or otherwise manipulate the characteristics of a particular resource. An example implementation of this function is described in more detail below.

[0075] In some embodiments, when input indicating that a new contract should be created is received, the user interface may prompt for input specifying parameters of the new contract. Fig.12 1 is an illustration of an example user interface 1200 for naming a new collaborative smart contract. The user interface 1200 may include a contract menu 1202 presenting a representation of a new contract. For example, the contract menu 1202 may include a nested menu item 1204 representing the new contract. The nested menu item 1202 may be expanded to present selectable representations of elements of the new contract, such as inputs 1206, calculations 1208, and outputs 1210. In general, menu items in the contract menu 1202 may be similarly expandable, and selecting a menu item from the contract menu 1202 may prompt the user to enter or edit parameters corresponding to the selected menu item. For example, selecting the menu item 1204 representing the new contract may prompt input (e.g., via input field 1220) specifying the details of the new contract. In this example, the input includes a contract name (e.g., "Advertising Efficiency"), a brief description of the contract (e.g., "How is Advertising Performing"), and a textual description of the proposed terms of use. When the user is finished, selection of an interactive element (e.g., a next button 1230) may 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.

[0076] Fig.13 1300 is an illustration of an example user interface 1300 for specifying inputs to a data privacy pipeline associated with a collaborative smart contract. In user interface 1300, menu item 1204 has been renamed to reflect the specified name of the new contract (advertising efficiency). The selection of menu item 1206 for contract input may prompt the user to enter parameters for the input. For example, interactive element 1320 may allow the user to select an existing, accessible data set (e.g., stored by a tenant account). In another example, interactive element 1330 may allow the user to invite contributors 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 pop-up window 1350). In yet another example, interactive element 1340 may allow the user to connect a new input data set. For example, the selection of interactive element 1340 may cause the presentation of a directory of available data sets (e.g., local data sets available for upload, authorized data sets associated with participating contributor accounts, data sets associated with selected projects or contracts). Fig.14 An example user interface 1400 is depicted with a panel 1420 presenting a catalog 1430 of available data sets. Available data sets (e.g., impressions) can be selected and connected to associate the selected data set with an active contract (e.g., with a selected element in the contract menu 1202).

[0077] In some embodiments, an input scheme for inputting a data set may be specified. Figure 15A-15B Example user interfaces 1500a and 1500b for specifying an input scheme are illustrated. Fig.15A The user interface 1500a includes an input field 1520a that allows a user to define parameters of an input scheme for an input data set. For example, a specified input scheme may include an identification of a specific component of the input data set (e.g., a variable, array, vector, matrix, row, column, feature) and one or more corresponding attributes (e.g., name, data type, description, dimension). If the user is connecting a new input data set, the input field 1520a may allow the user to specify a specific part of the input data set to be connected (e.g., a specific column). If the user is specifying a placeholder data set, the input field 1520a may allow the user to specify an input scheme for an input data set to be provided at some point in the future. In some embodiments, a menu of available options (e.g., a drop-down menu 1530) may be limited to a set of detected or compatible values. In some embodiments, new features may be added to the set of input fields 1520a (e.g., by selecting an interactive element such as add feature 1540). Fig. 15BThe user interface 1500b of illustrative embodiments illustrates an example in which the input field 1520b is automatically populated (eg, detected from a connected input data set). These are just some examples, and other variations for specifying input schemes for input data sets are contemplated.

[0078] Figure 16A-16C 1600a, 1600b, and 1600c are illustrations of example user interfaces 1600a, 1600b, and 1600c for creating a new computation step in a data privacy pipeline associated with a collaborative smart contract. Typically, selection of an interactive element associated with a menu item in the contract menu 1202 (e.g., Fig.16A ), the user may be prompted to specify parameters for the associated new element (e.g., a new calculation step). For example, Fig.16A Panel 1620 may prompt the user to select a compatible or supported computing platform capable of performing the specified computing step. Panel 1630 may prompt the user to select parameters such as step name, step type, and step input. Fig. 16B An example new step called Fuse_1 is shown. Fig. 16B , the step type input field includes an interactive drop-down menu 1640 that accepts selection of one or more template calculations. Fig. 16C In the template fusion calculation, the step type has been selected. Fig. 16C , the step input field includes an interactive drop-down menu 1650 that accepts a selection of one or more calculation step inputs. For example, available calculation step inputs may include connection inputs 1660, calculation results 1670 (i.e., the output of an existing calculation step associated with the project or contract), and placeholder data sets 1680. Fig. 16C , the drop-down menu 1650 presents an indication that no calculation results are available (e.g., because in this example, Fuse_1 is the first calculation step for this particular contract). Fig. 16C In the illustrated example, the user has selected two inputs for the Fuse_1 computation step: one of the input data sets 1660 (i.e., Fig.14 1680 (ie, an indication defining an input schema for the placeholder dataset) and the input dataset 1680 (ie, an indication defining an input schema for the placeholder dataset) associatively connected. These and other variations for specifying inputs for a computation step may be implemented.

[0079] Continuing with this example, once the user selects a set of inputs for a computation step, the user may be prompted to specify an input scheme to use for the inputs. Figure 17A-17B1700a and 1700b are illustrations of example user interfaces 1700a and 1700b for specifying input schemes for calculation steps. Note that in the contract menu 1202, a nested menu item 1712 representing the Fuse_1 step has been added. As with other menu items in the contract menu 1202, the nested menu item 1712 can be expanded to present selectable representations of elements of the associated calculation step, such as input scheme 1714, calculation 1716, and output scheme 1718. Fig.17A In the user interface 1700a of , the menu item 1714 for the input scheme for the Fuse_1 calculation step is selected. The user interface 1700a presents an input scheme 1725 for the input data set 1720 (which may have been pre-specified or otherwise identified), and presents an input field 1740a for the input scheme for the placeholder data set 1730 (which can be filled in via the user interface 1700a). In some embodiments, new features can be added to the set of input fields 1740a for the input scheme (e.g., by selecting an interactive element such as add feature 1750). In some embodiments, the user interface 1700a may include an interactive element that allows the user to replace the selected input with another input. For example, a drop-down menu 1760a may allow the user to replace the placeholder data set 1730 with an available input data set or calculation result. Fig. 17B 1700b illustrates the selection of connecting input data set (impression) to replace placeholder data set 1730, and input field 1740b has been updated to reflect the input scheme of the input data set for selection.User interface 1700a and 1700b can also be considered as presenting the summary of the step input of specific calculation step.Usually, interactive elements (e.g., buttons, clickable links, clickable entries) can be provided for specific step input, which allows the user to rename the step input, remove the step input, cancel the association of the data set with the step input (i.e., convert the input of the placeholder data set), associate the data set with the step input (i.e., fill in the placeholder data set), edit the scheme for the step input, or otherwise manipulate the characteristic of the step input.

[0080] Now turn to Figures 18A-18C , Figures 18A-18C Example user interfaces 1800a, 1800b, and 1800c for specifying calculations for a calculation step are illustrated. Fig.18AIn user interface 1800a, menu item 1716 for calculation of Fuse_1 calculation step is selected. User interface 1800a includes interactive element 1820 that allows the user to select available calculations (e.g., via a drop-down menu), and includes interactive element 1825 that allows the user to create a new calculation. User interface 1800b illustrates an example in which the user selects to create a new calculation. In response to such a selection, a user interface such as user interface 1800b can be presented with a script editor and / or compiler for a specified calculation platform. Fig.18B The embodiment illustrated in includes a script editor, compiler, and interactive elements 1830 that allow a user to specify whether a specified calculation should be visible to others. Fig. 18C An example script 1840 is illustrated that may be provided.

[0081] Figure 19A-19B Example user interfaces 1900a and 1900b for specifying output schemes for calculation steps are illustrated. Fig.19A In user interface 1900a of FIG. 1700, menu item 1718 for an output scheme for a Fuse_1 computation step is selected, and input fields 1920a may be populated to specify parameters for the output scheme. User interface 1900b depicts an example output scheme 1920b that may be provided for the Fuse_1 step. User interfaces 1900a and 1900b may also be considered to present summaries of step outputs for a particular computation step (although Fig.19A and Fig.19B Only one step output is depicted in FIG. 1 ). Typically, an interactive element (e.g., a button, clickable link, clickable item) may be provided for a particular step output that allows a user to rename the step output, remove the step output, specifically point to the location of the step output, edit the scheme for the step output, or otherwise manipulate characteristics of the step output.

[0082] Fig. 20is an illustration of an example user interface 2000 summarizing the computation steps in a selected contract and / or associated data privacy pipeline. In user interface 2000a, menu item 1208 for computation steps in an advertising efficiency contract is selected. In this example, contract menu 1202 has been updated with menu items reflecting two completed computation steps: Fuse_1 (menu item 2012) and Aggregate (menu item 2014). In addition, table 2020 displays a summary of the computation 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 interactive element may be provided that links to a corresponding interface configured to edit the selected computation step (e.g., a button, selectable text such as the name of the computation step, a selectable entry such as a row in table 2020). Additionally or alternatively, an interactive element may be provided to delete the selected computation step (e.g., first prompt for confirmation), rename the computation step, change access permissions, or other manipulations.

[0083] Fig.21 An example user interface 2100 for specifying a contract output associated with a collaborative smart contract is illustrated. In the user interface 2100, a menu item 1210 for an output of an advertising efficiency contract is selected. In general, any type of output may be supported. Fig.21 In the illustrated embodiment, user interface 2100 includes interactive elements 2125 and 2135 that allow a user to enter parameters for a named query and for an output data set, respectively. Note that corresponding menu items 2120 and 2130 are nested under menu item 1210 for output of an advertising efficiency contract.

[0084] Figure 22A-22B Example user interfaces 2200a and 2200b for specifying an output data set to be generated by the data privacy pipeline are illustrated.In user interfaces 2200a and 2200b, menu item 2130 for an output data set for an advertising efficiency contract is selected. Fig.22A The user interface 2200a may include an overview 2240 of the specified output data set to be generated. In addition, the menu item 2130 may be expandable to display the currently specified output data set as a corresponding menu item in the contract menu 1202. As with other user interfaces described herein, the user interface 2200a may include interactive elements that allow the user to create a new contract element (here, a new output data set). In response, such as Fig. 22BThe user interface of user interface 2200b can prompt the user to specify parameters for new output data set. For example, user interface 2200b can prompt the user to specify calculation steps, according to which the corresponding calculation result should be used as output data set. In certain embodiments, user interface 2200b can prompt the user to specify the destination of output data set. In response, the directory 2255 (for example, via panel 2250) of available positions can be presented, and the desired position can be selected.

[0085] Figure 23A-23D Example user interfaces 2300a, 2300b, 2300c, and 2300d for specifying permissible named queries associated with a collaborative smart contract are illustrated. In these user interfaces, a menu item 2120 for permissible named queries for an advertising efficiency contract is selected. In general, the parameters that can be specified for a named query can be similar to the parameters that can be specified for a calculation of a calculation step. For example, user interface 2300a may include a query name field 2320, a field 2322 for specifying the output of a particular calculation step (on which the query can operate), an input field 2324 for specifying an input scheme, an interactive element 2326 for selecting an existing available script, and / or an interactive element 2328 for creating a new script 2328. Selecting interactive element 2328 to create a new script may cause presentation of a user interface, such as Fig. 23B A user interface 2300b is provided which accepts a selection of a programming language 2330 for a new script. Additionally or alternatively, a program such as Fig.23C A user interface of user interface 2300c may be presented to accept input of a script, such as script 2340. In some embodiments, user interface 2300c may include a script editor and compiler (eg, for a specified programming language). Fig.23D A summary 2350 of named queries associated with an advertising efficiency contract is illustrated. Note that corresponding menu items for the named queries in summary 2350 have been added to menu items 2120 in contract menu 1202. In general, interactive elements (e.g., buttons, clickable links, clickable items) may be provided for particular named queries that allow a user to rename the named query, remove the named query, view or edit the description of the named query, or otherwise manipulate the properties of the named query.

[0086] Fig.24A An example user interface 2400a summarizing contract outputs associated with a collaborative smart contract is illustrated. In the user interface 2400a, the menu item 1210 for outputs of the advertising efficiency contract is selected. The user interface 2400a includes a summary 2410 of the named queries associated with the contract, and includes a summary 2415 of the output data sets to be generated by deploying the data privacy pipeline associated with the contract.

[0087] Fig. 24B An example user interface 2400b for reviewing, approving and deploying collaborative smart contracts is illustrated. In the user interface 2400b, the menu item 1204 for the advertising efficiency contract is selected. In this example, the user interface 2400b may include a summary of the specified parameters of the contract, including a basic description 2420, authorized participants 2430, input data sets 2440, specified calculations 2450 and contract outputs 2460. In some embodiments, the user interface 2400b may include interactive elements (e.g., interactive elements 2435) that allow users to add participants and define access rights (e.g., roles) for new participants. The user interface 2400b may prompt each participant to approve the contract. In some embodiments, interactive elements (e.g., buttons) that allow participants to sign contracts, withdraw existing signatures or edit contract details (e.g., basic description 2420) may be provided. When all participants have approved, the user interface 2400b may prompt the user to deploy the contract and the corresponding data privacy pipeline (e.g., via interactive elements 2470).

[0088] Figure 25A-Figure 25E is an illustration of an example user interface for browsing and interacting with accessible resources, such as the Data Privacy Pipeline ( Fig.25A ),Operation( Fig.25B ), named queries( Fig.25C and Fig.25D ) and audit events ( Fig.25E ).

[0089] Fig.25A An example user interface 2500a for browsing and interacting with available pipelines (e.g., for which a tenant account is authorized) is illustrated. For example, a particular account may be authorized to trigger a pipeline based on corresponding permissions specified in an associated collaborative smart contract. The accessible pipelines may be presented with corresponding interactive elements (e.g., triggers 2510) that trigger a request to initiate a job defined by the pipeline. In some embodiments, when a triggered job succeeds, a tooltip indicating successful creation may be displayed. Conversely, when a triggered job fails, a tooltip indicating failure may be displayed.

[0090] Fig.25BAn example user interface 2500b for browsing and interacting with available jobs (e.g., collaborative smart jobs initiated, associated, or otherwise accessible by a tenant account) is illustrated. For example, a table 2520 of collaborative smart jobs (e.g., triggered pipeline jobs) can be presented together with information about the job, such as an identifier of the job, an identifier of the pipeline from which the job was created, the execution state of the job (e.g., running, suspended, successful, failed), the duration of the job from the moment it was started, etc. In some embodiments, the job can be presented together with associated interactive elements (e.g., buttons, clickable links, clickable entries) configured to perform available actions related to the job. For example, if the job is running, the available action can be an abort operation. If the job is successful, the available action can be a view result action. If the job fails, the available action can be a view error action. In some embodiments, the table 2520 can include associated interactive elements that are configured to filter the jobs being presented (e.g., by date, status, name, start time, duration). These and other changes are contemplated in the present disclosure.

[0091] Fig.25C and Fig.25D Example user interfaces 2500c and 2500d for browsing and interacting with available named queries (e.g., initiated, associated, or otherwise accessible by a tenant account) are illustrated. For example, a table 2530 of permissible named queries available to an account may be presented together with information about the named query, such as an identifier of the named query, a corresponding data set on which the named query is configured to operate, an identifier of the owner of the corresponding data set, and the like. In some embodiments, the named query may be presented together with an associated interactive element (e.g., a button, a clickable link, a clickable entry) configured to perform available actions associated with the named query, such as a run action element 2535, which may be configured to initiate a request to run the named query. In some embodiments, as a precursor to initiating a request to run the named query, one or more prompts for inputting the relevant parameters of the named query may be presented. For example, a user interface 2500d may be presented and may prompt a description of the named query, a selection of permissible configuration parameters (e.g., defined by an associated collaborative smart contract), and the like. In the embodiment illustrated in 2500d, a trigger button 2540 may initiate a named query and the results (eg, a results table 2545) may be presented.

[0092] Fig.25EAn example user interface 2500e is illustrated for browsing and interacting with available audit events (e.g., jobs, collaborative smart contract proposals, or other operations related to collaborative smart resources, initiated by, associated with, or otherwise accessible to a tenant account). For example, a table 2550 of audit events available to an account can be presented along with information about the audit event, such as the date and time of the event, the type of object operated on (e.g., job, proposal), the corresponding identifier of the object, the type of operation performed (e.g., start, abort, create), an identifier of the account that initiated the event or is otherwise associated with the event, etc. In some embodiments, the table 2550 may include associated interactive elements that are configured to filter the audit events presented (e.g., by date, object type, operation, associated account, description). These and other variations are contemplated in the present disclosure.

[0093] In this way, one or more user interfaces can guide collaborators to build and configure data privacy pipelines and corresponding contractual agreements for sharing data. Although the interfaces described herein have been described with specific configurations of interactive elements, these examples are not meant to be limiting. In general, any appropriate (multiple) interfaces that can facilitate multi-party collaboration, generation of data privacy pipelines, and / or specification of corresponding parameters are contemplated to be within the scope of the present disclosure.

[0094] Example Collaborative Intelligent Environment

[0095] Some embodiments of the present disclosure relate to a technology for deriving and extracting collaborative intelligence based on constraint calculation and constraint query. At a high level, a data trustee can operate a trustee environment, which is configured to extract collaborative intelligence to a tenant subject to configurable constraints without exposing the underlying raw data provided by the tenant or the collaborative data shielded by the trustee environment. As used herein, collaborative data refers to data extracted from shared input data (e.g., data from different users). The shared input data can come from any number of sources (e.g., different users) and can be processed to generate intermediate data, which itself can be processed to generate collaborative data. Collaborative data can include an exposed part that allows sharing and a restricted part that does not allow sharing. Although the restricted part of collaborative data cannot be shared, it can include an operable part that can be used to extract sharable collaborative intelligence. In some embodiments, collaborative intelligence can be extracted from exposed data and / or restricted data, and collaborative intelligence can be provided without disclosing restricted data. For example, configurable constraints can programmatically manage restrictions (e.g., allowing certain operations but not others) on certain underlying data (e.g., personally identifiable information, certain other sensitive information, or any other specifically designated information that is collected, stored, or used), and manage how the underlying data can and cannot be accessed, used, stored, or displayed (or variations thereof). In addition, configurable constraints can programmatically support collaborative intelligent operations on accessible data (e.g., extracting aggregate statistics) without displaying the individual data items being operated on.

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

[0097] Typically, a data privacy pipeline can accept data provided by one or more tenants. Initially, the data privacy pipeline can determine whether the input data is federated data based on a contract or other tenant agreement with one or more tenants. Data determined to be federated data can be ingested, and data determined not to be federated data can be discarded. In this regard, federated data refers to any shared data that is specifically designated for ingestion when generating collaborative data (e.g., c specifically designated or otherwise identified in a tenant agreement with one or more tenants). The ingested data can include data from multiple sources, so the data privacy pipeline can fuse data from multiple sources based on the calculations and constraints specified in the tenant agreement. For example, constrained data fusion can implement one or more constraints to combine ingested data in a variety of ways to form fused federated data, including using 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 the like.

[0098] In some embodiments, the data privacy pipeline can perform constrained computations to generate extracted federated data. Constrained computations can obtain data from a source (e.g., ingested data, fused federated data) and perform any number of specified computations (e.g., arithmetic operations, aggregation, summary, filtering, sorting, boundaries). A simple example of a constrained computation is a computation of the average age of each city, which is only performed on a city if the underlying data set contains entries for at least 5 people in the city. Additionally or alternatively, the data privacy pipeline can perform data cleansing to generate collaborative data that implements constraints on storage, access, accuracy, and the like. For example, data cleansing can implement constraints specified in a tenant agreement that specify whether collaborative data should be masked (e.g., stored in a trustee environment), whether collaborative data can be exported, whether exported collaborative data should be restricted (e.g., emails, credit card numbers, and portions thereof are not exported), and the like. In this way, the data privacy pipeline can generate collaborative data from data provided by one or more tenants and provide agreed access to the collaborative data without sharing the underlying raw data with all tenants.

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

[0100] For example, data access constraints may be specified to allow or disallow access (e.g., for specific users, accounts, organizations). In some embodiments, specific constraints may be generic so that the constraints apply to all potential data consumers (e.g., only allow access to average age, regardless of who the data consumer is). In some embodiments, specific constraints may be applied to specific users, accounts, organizations, etc. (e.g., do not allow group A to access salary data, but allow group B to access it). In general, a tenant may specify: constraints that define how tenant data is merged with a specific data set or portion thereof, constraints that limit the scheme of data read from the tenant's data (e.g., specify horizontal filtering to be applied to the tenant's data), constraints that limit the size of ingested data (e.g., specify storage limits, subsampling of tenant data, vertical filtering to be applied to the tenant's data), constraints that limit the scheme of collaborative data that can be output, constraints that define ownership of collaborative data, constraints that define whether collaborative data should be open, encrypted, or shielded (e.g., stored in a trustee environment), etc.

[0101] In some embodiments, various types of data processing constraints may be specified, such as constraints specifying what operations may be performed (e.g., permissible and restricted calculations, binary checks), constraints limiting comparison precision (e.g., for numeric data, geographic data, date, and time data), constraints limiting accumulation precision (e.g., for geographic data, numeric data, date, or time data), constraints limiting location boundary precision (e.g., limiting permissible geo-fence determination to a particular grid, minimum geographic division such as a neighborhood, county, city, state, or country, etc.), and other precision and / or data processing requirements.

[0102] Additionally or alternatively, one or more data aggregation constraints may be specified, such as constraints requiring a minimum amount of aggregation (e.g., at least N rows or distinct field values), constraints requiring that some statistical distribution condition be valid (e.g., a minimum standard deviation), constraints defining allowed aggregation functions (e.g., allowing minimum, maximum, average, but not percentiles), to name a few examples.

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

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

[0105] In some embodiments, the constraint manager can monitor and coordinate data flow, generation and access according to the specified constraints. For example, the constraint manager can communicate with various components (e.g., data privacy pipelines) in the trustee environment to implement constraints, which can be maintained in a contract database accessible to the constraint manager. In some embodiments, the component can issue a request to the constraint manager for the permission to execute a specific command, function call or other executable logic unit. The constraint manager can evaluate the request and grant or deny permissions. In some cases, permissions can be granted according to one or more conditions corresponding to one or more constraints in the constraint. As a non-limiting example, some possible conditions that can be implemented include: requiring operations to shift, filter or reshape data (e.g., the application of comparison constraints, such as only allowing merges with specific precision), requiring one or more executable unit logic (e.g., commands or operations) to be replaced by one or more constrained executable logic units (e.g., replacing average with constrained average), etc.

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

[0107] The enforcement of constraints (e.g., precision or aggregation constraints) on specific executable logic units (e.g., for a particular computation, requested operation) can result in any number of scenarios. In one example, a specific executable logic unit can be completely rejected. In another example, a specific executable logic unit can be allowed, but the results are filtered (e.g., no value is returned for a particular row or data entry). In yet another example, a specific executable logic unit can be allowed, but the results are changed (e.g., precision is reduced, the answer to a question is false). These and other variations can be implemented.

[0108] When constraints are applied to generate collaborative data, any combination of schemes, constraints and / or attribute metadata can be associated with collaborative data, intermediate data for reaching collaborative data, etc. Typically, constraints can be enforced across multiple steps and calculations. Thus, in some embodiments, the applicable and / or satisfied constraints of each step can be tracked and / or associated with the data generated by a given step. Taking aggregation constraints as an example, once the aggregation constraints are satisfied during a particular step, the subsequent steps no longer need to consider the constraint. In another example where different constraints are specified for different data sets to be merged, the merge operation may only need to apply stricter constraints. Typically, when data flows through the data privacy pipeline, the appropriate allocation or combination of constraints can be applied and / or tracked. Such tracking can help verify whether a particular constraint has been applied to a particular data. Therefore, when constraints are applied and data is generated, the corresponding scheme, applicable or satisfied constraints and / or attribute metadata indicating ownership or provider can be associated with a data set or a corresponding entry, row, field or other data element. In some embodiments, any intermediate data used to arrive at the collaborative data (e.g., ingested data, fused federated data, extracted federated data) may be deleted, and the collaborative data may be stored in the trustee environment and / or provided as output, depending on applicable constraints.

[0109] In some embodiments, constrained queries may be applied to allow data consumers to query collaborative data in a trustee environment subject to configurable constraints. At a high level, constrained queries may operate as a search engine that allows data consumers to access collaborative data or extract collaborative intelligence from collaborative data without exposing the underlying raw data provided by the tenant or collaborative data shielded by the trustee environment. In response to a query, constraints may be applied in a variety of ways, including reformatting the query before execution, applying constraints after executing the query, constraining eligible queries for execution, applying access constraints before execution, etc.

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

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

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

[0113] Thus, using the embodiments described herein, users may share data efficiently and effectively through data trustees that allow them to extract collaborative intelligence, while ensuring data privacy and providing configurable control and access to shared data.

[0114] Reference now Fig.26 , a block diagram of an example collaborative intelligence environment 2600 suitable for implementing embodiments of the present invention is shown. In general, the collaborative intelligence environment 2600 is suitable for generating collaborative intelligence, and is particularly useful for constraint computation and constraint querying. The collaborative intelligence environment 2600 or a portion thereof (e.g., the data trustee environment 2610) may, but need not, be implemented in a distributed computing environment (such as, for example, the following description of the collaborative intelligence environment 2600). Fig.30 Any or all components of the collaborative intelligent environment 2600 may be implemented as any type of computing device, or portions thereof. For example, in one embodiment, each of the tenant devices 2601a to 2601n and the data consumer devices 2603a to 2603n may be a computing device, such as, for example, as described below with reference to Fig.31The computing device 3100 described above. In addition, the data trustee environment 2610 can be implemented using one or more such computing devices. In an embodiment, these devices can be any combination of personal computers (PCs), laptops, workstations, servers, mobile computing devices, PDAs, mobile phones, etc. The components of the collaborative intelligent environment 2600 can communicate with each other via one or more networks, which can include but are not limited to one or more local area networks (LANs) and / or wide area networks (WANs). Such network environments are common in offices, enterprise-wide computer networks, intranets, and the Internet.

[0115] The collaborative intelligence environment 2600 includes a data trustee environment 2610 that can extract collaborative data and / or collaborative intelligence from raw data provided by a data owner or provider (e.g., a tenant) subject to configurable constraints without sharing the raw data. Typically, any number of tenants can input their data (e.g., data sets 2605a to 2605n) into the data trustee environment 2610 and specify one or more constraints (e.g., from one of the tenant devices 2601a to 2601n). The data trustee environment 2610 can extract collaborative data (e.g., collaborative data sets 2607a to 2607n, shielded collaborative data sets 2660) based on one or more constraints. Any number of data consumers (e.g., operating on one of the data consumer devices 2603a to 2603n) can issue queries to the shielded collaborative data set 2660, and subject to one or more constraints, the data trustee environment 2610 can extract collaborative intelligence from the shielded collaborative data set 2660. In some cases, the 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 provides the original data (e.g., one or more of the data sets 2605a through 2605n) or owns the extracted collaboration data (e.g., the masked collaboration data set 2660). In some cases, the authorized data consumer may be another person or entity.

[0116] exist Fig.26In the illustrated embodiment, the data trustee environment 2610 includes a constraint manager 2615. At a high level, tenants seeking to share data can provide one or more desired calculations and constraints (which can be embodied in a contractual agreement) to the constraint manager 2615 through a user interface of the data trustee environment 2610. The user interface can enable tenants to specify desired calculations and constraints that will control the use of their data in the data trustee environment 2610, including qualified data sources (e.g., one or more data sets in data sets 2605a to 2605n) and how their data can be processed or shared. Various types of constraints can be implemented, including data access constraints, data processing constraints, data aggregation constraints, data purification constraints, some combination thereof, or other. The specified calculations and constraints, as well as other features of the tenant agreement, can be stored in a contract database (not depicted) accessible to the constraint manager 2615.

[0117] exist Fig.26 In the illustrated embodiment, the data trustee environment 2610 includes a data privacy pipeline 2620. At a high level, the data privacy pipeline 2620 can accept data from one or more specified sources (e.g., one or more of the data sets 2605a to 2605n). Data can be ingested, fused, extracted and / or cleansed to generate collaborative data (e.g., one or more of the collaborative data sets 2607a to 2607n, shielded collaborative data set 2660) based on one or more specified calculations and / or constraints. The data privacy pipeline 2620 can be provided as a distributed computing or cloud computing service (cloud service) implemented in the data trustee environment 2610 and can be started and shut down as needed. In some embodiments, tenants who provide data to the data privacy pipeline 2620 cannot access the pipeline. Instead, the pipeline outputs collaborative data subject to applicable constraints. Depending on the specified constraints, the collaboration data may be output from the data trustee environment 2610 as one or more of the collaboration data sets 2607a through 2607n (e.g., because it has been cleansed according to the specified constraints) and / or may be masked (e.g., stored as masked collaboration data set 2660) within the data trustee environment 2610. As explained in more detail below, the collaboration data set 2660 may be queried to extract collaboration intelligence subject to the configurable constraints.

[0118] exist Fig.26In the illustrated embodiment, the data privacy pipeline 2620 includes an ingestion component 2625 (which generates ingested data 1830), a constrained fusion component 2635 (which generates fused joint data 2640), a constrained computation component 2645 (which generates extracted joint data 2650), and a cleansing component 2655 (which generates collaborative data sets 2607a to 2607n and collaborative data set 2660). Initially, one or more of the data sets 2605a to 2605 may be provided to the data privacy pipeline 2620 (e.g., via a user interface, a programming interface, or some other interface of the data trustee environment). The ingestion component 2625 may determine whether the input data or some portion thereof is joint data in accordance with a contract or other tenant agreement. For example, the input data or some portion thereof may be identified in some manner, and the ingestion component 2625 may communicate with the constraint manager 2615 to confirm whether the identified data is joint data according to the tenant agreement represented in the contract database. Data determined to be federated data may be stored as ingested data 2630, and data determined not to be federated data may be discarded.

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

[0120] Typically, the constrained computation component 2654 can perform constrained computations (e.g., on the ingested data 2630, the fused federated data 2640) to generate extracted federated data (e.g., extracted federated data 2650). The constrained computations can involve any number of specified computations (e.g., arithmetic operations, aggregations, summaries, filtering, sorting, boundaries). Typically, the constrained computation component 2645 can communicate with the constraint manager 2615 to obtain, verify, or request specified computations based on the tenant agreement represented in the contract database. As a simple example, many retailers may agree to expose average sales data, so the corresponding computations may involve averages. A simple example of a constrained computation is the computation of the average age of each city, and the computation is only performed on the city if the underlying data set contains entries for at least 5 people in the city. These are intended to be examples only, and any type of computation and / or constraint may be implemented.

[0121] In some embodiments, the cleansing component 2655 can perform data cleansing (e.g., on the exported federated data 2650) to generate collaborative data (e.g., one or more of the collaborative data sets 2607a to 2607n, the shielded collaborative data set 2660) in a manner that implements constraints on storage, access, accuracy, etc. For example, the cleansing component 2655 can communicate with the constraint manager 2615 to obtain, verify, or request a specified cleansing operation according to the tenant agreement represented in the contract database. In this way, the cleansing component 2655 can implement the constraints specified in the tenant agreement, which specifically refers to: whether the collaborative data should be shielded (e.g., stored as a shielded collaborative data set 2650 in the data trustee environment 2610), whether the collaborative data can be exported (e.g., as one or more of the collaborative data sets 2607a to 2607n), whether the extracted collaborative data should be restricted (e.g., emails, credit card numbers, portions thereof are not exported), some combination thereof, etc. In some embodiments, any or all intermediate data used to derive the collaborative data (e.g., ingested data, fused federated data, extracted federated data) can be deleted, e.g., associated with reducing authoring by the data privacy pipeline 2620. In this way, the data privacy pipeline 2620 can generate collaborative data from data provided by one or more tenants.

[0122] As described above, constraint manager 2615 can monitor and coordinate the use and generation of collaborative data subject to one or more specified constraints. Additionally or alternatively, constraint manager 2615 can monitor and coordinate access to collaborative data subject to constraints. Typically, constraint manager 2615 can communicate with various components in data trustee environment 2610 and / or data privacy pipeline 2610 to implement specified calculations and / or constraints, which can be maintained in a contract database accessible to constraint manager 2615. In some embodiments, a component can issue a request to constraint manager 2615 for the authority to execute a specific command, function call, or other executable logic unit. Constraint manager 2615 can evaluate requests and grant or deny permissions. In some cases, permissions can be granted according to one or more conditions corresponding to one or more constraints in a constraint. As non-limiting examples, some possible conditions that may be implemented include: requiring operations to shift, filter, or reshape data (e.g., the application of comparison constraints such as only allowing merges with a certain precision), requiring that one or more executable unit logic (e.g., commands or operations) be replaced by one or more constrained executable logic units (e.g., replacing an average with a constrained average), and the like.

[0123] In general, constraints may be checked, verified, or otherwise enforced at any time or step (e.g., associated with any component of the data privacy pipeline 2620, data trustee environment 2610). Thus, the corresponding functionality for enforcing constraints may be applied at any step or multiple steps. In some embodiments, the enforcement of certain constraints may be assigned to certain components of the data privacy pipeline 2620 (e.g., data access constraints are applied by the ingestion component 2625, processing and aggregation constraints are applied by the constrained fusion component 2635 and / or the constrained computation component 2645, and purification constraints are applied by the purification component 2655). In another example, a specific data access constraint (e.g., only passing data for patients participating in at least five different studies) may be applied by the constrained fusion component 2635. These are intended to be examples only, and any appropriate constraint enforcement mechanism may be implemented within the present disclosure.

[0124] In some embodiments, constraint manager 2615 can enforce constraints (e.g., precision or aggregation constraints) on specific executable logic units (e.g., for a specific calculation, requested operation) by communicating, indicating, or otherwise facilitating any number of treatments. In one example, constraint manager 2615 can completely reject a specific executable logic unit. In another example, constraint manager 2615 can allow a specific executable logic unit, but require the result to be screened (e.g., no return value for a specific row or data entry). In yet another example, constraint manager 2615 can allow a specific executable logic unit, but require the result to be changed (e.g., reduced precision, a false answer to a question). These and other changes can be implemented.

[0125] When constraints are applied to generate collaborative data (e.g., collaborative data sets 2607a to 2607n, shielded collaborative data set 2670), any combination of schemes, constraints and / or attribute metadata may be associated with collaborative data, intermediate data used to reach collaborative data (e.g., ingested data 2630, fused joint data 2640, extracted joint data 2650), or other. Typically, constraints can be enforced across multiple steps and calculations. Thus, in some embodiments, the applicable and / or satisfied constraints of each step can be tracked and / or associated with data generated by a given component of the data privacy pipeline 2620. Taking an aggregate constraint as an example, once an aggregate constraint is satisfied by a particular component of the data privacy pipeline 2620, the downstream component no longer needs to consider the constraint. In another example where different constraints have been specified for different data sets to be merged, the merge operation may only need to apply stricter constraints. Typically, when data flows through the data privacy pipeline 2620, the appropriate allocation or combination of constraints can be applied and / or tracked. Such tracking can help verify whether a particular constraint has been applied to a particular data. Thus, when constraints are applied and data is generated, corresponding schemes, applicable or satisfied constraints, and / or attribute metadata indicating data ownership or provider may be associated with a data set or a corresponding entry, row, field, or other data element. Typically, schemes, applicable or satisfied constraints, and / or attribute metadata may be generated based on a tenant agreement represented in a contract database (e.g., via communication with constraint manager 2615). In some embodiments, any or all intermediate data used to arrive at collaborative data (e.g., ingested data 2630, fused federated data 2640, extracted federated data 2650) may be deleted, and the collaborative data may be stored in the data trustee environment 2610 as a shielded collaborative data set 2660, and / or may be extracted as one or more of collaborative data sets 2607a to 2607n, depending on the applicable constraints.

[0126] In some embodiments, the data trustee environment 2610 includes a constrained query component 2670 that can apply constrained queries to allow a data consumer (e.g., operating on one of the data consumer devices 2603a-2603n) to query the collaborative data (e.g., the shielded collaborative data set 2660) in the data trustee environment 2610, subject to one or more specified constraints. At a high level, the constrained query component 2670 can operate as a search engine that allows data consumers to access or extract collaborative intelligence from the shielded collaborative data set 2660 without exposing the original data provided by the tenant (e.g., one or more of the data sets 2605a-2605n), the intermediate data used to generate the shielded collaborative data set 2660 (e.g., the ingested data 2630, the fused federated data 2640, the extracted federated data 2650), and / or the shielded collaborative data set 2660. In general, the constrained query component 2670 can communicate with the constraint manager 2615 to obtain, verify, or request specified operations in accordance with the tenant agreement represented in the contract database. In response to a query, constrained query component 2670 can facilitate enforcement of constraints in a variety of ways, including reformatting the query prior to execution, applying constraints after executing the query, constraining eligible queries for execution (e.g., allowing only a set of whitelisted queries), applying access constraints prior to execution, and the like.

[0127] Now turn to Fig. 27 , Fig. 27 is a block diagram of an example constrained query component 2700 according to embodiments described herein. The constrained query component 2700 may correspond to Fig.26 . At a high level, the constrained query component 2700 can operate as a search engine, enabling data consumers to query collaborative data and extract collaborative intelligence therefrom, subject to one or more constraints specified in the corresponding tenant agreement. As background, queries are typically not executable code. To execute a query, the query is typically converted into an execution tree, which serves as the basis for an executable execution plan. Typically, the constrained query component 2700 can enforce constraints or facilitate the enforcement of constraints by reformatting the execution tree corresponding to the received query to consider any applicable constraints prior to execution. In a simple example, a constraint may allow a query to compensate for data, but the results must be rounded. In this way, the query and / or its corresponding execution tree can be reformatted prior to execution so that any returned search results take into account the applicable constraints. In Fig. 27In the illustrated embodiment, constrained query component 2700 includes access constraint component 2720, query parser 2730, constraint query formatter 2740, conversion component 2750, and execution component 2760. This configuration is intended to be exemplary only, and other configurations having similar or different functionality may be implemented according to the present disclosure.

[0128] At a high level, the constrained query component 2700 can receive a query from a data consumer (e.g., Fig.26 The query 2710 is issued by one of the data consumer devices 2603a to 2603n of the data consumer device 2603a to 2603n, the query request is based on the collaborative data (e.g., Fig.26 Query 2710 may take any suitable form or query language and may include one or more request operations on the collaborative data. In some embodiments, query 2710 may specify or otherwise be associated with runtime information, such as information identifying the requesting data consumer issuing the query, information identifying the applicable tenant agreement, information identifying the target collaborative data to be operated on, and the like.

[0129] In some embodiments, access constraint component 2720 can use runtime information associated with query 2720 to trigger the lookup and enforcement of applicable data access constraints (e.g., via Fig.26 2710). For example, the access constraint component 2720 can verify the query 2710 relative to the corresponding constraint context, which includes applicable data access constraints and runtime information associated with the query 2710. Generally, the access constraint component 2720 can deny the request in the event that the data consumer is not authorized to access the collaborative data set, the target collaborative data within the collaborative data set (e.g., a specific data row), or the specific type of requested collaborative intelligence to be extracted. In this case, the access constraint component 2720 can return a notification to the issuing data consumer, notifying the data consumer that the requested query is denied. If the requested access is determined to be authorized and / or compliant with the applicable data access constraints, the query 2710 can be passed to the query parser 2730.

[0130] In general, query parser 2730 may parse query 2710 and generate a corresponding execution tree 2735. At a high level, execution tree 2735 includes a hierarchical arrangement of executable logic units that, when executed, implement query 2710. The executable logic units may include any suitable arrangement and combination of commands, operations, function calls, etc. Constraint query formatter 2740 may access applicable constraints (e.g., via Fig.262615) and can validate the executable logic units of execution tree 2735 against the constraints. In some embodiments, if one or more of the executable logic units are not allowed, query 2710 can be effectively reformatted by adding, removing and / or changing one or more executable logic units based on one or more constraints.

[0131] More specifically, the constraint query formatter 2740 can reformat the execution tree 2735 into a constrained execution tree 2745 by traversing the execution tree 2735 and replacing executable logic units that are inconsistent with a particular constraint with custom executable logic units that are consistent with the constraint. Additionally or alternatively, the constraint query formatter 2740 can add or remove one or more executable logic units to enforce constraints (e.g., precision constraints) on the output. In general, the constraint query formatter 2740 can verify the executable logic units of the execution tree 2735 against a corresponding constraint context, which includes applicable constraints and runtime information associated with the query 2710. This check can involve verification of constituent commands or operations, one or more constituent parameters, and / or consideration of other portions of the execution tree 2735, and can produce many possible results. For example, the executable logic unit may be allowed (e.g., the executable logic unit may be copied into constrained execution tree 2735), the executable logic unit may be prohibited (e.g., query 2710 may be completely prohibited), or the executable logic unit may be allowed but with changes (e.g., the corresponding constrained executable logic unit is copied into constrained execution tree 2735). These are intended to be examples only, and other variations are contemplated within the present disclosure.

[0132] Thus, constraint query formatter 2740 may evaluate each executable logic unit relative to the constraints, add or remove executable logic units, and / or replace one or more executable logic units that are inconsistent with the constraints with custom executable logic units that include and / or apply the constraints. Fig.26 The mapping may be one-to-one, one-to-many, or many-to-one, to access, retrieve, access, and / or maintain a mapping between executable logic units and custom executable logic units and / or executable logic units corresponding to one or more constraints (e.g., a list of rules).

[0133] In some embodiments, the received query may be associated with a target collaborative dataset (e.g., Fig.262760). Thus, the conversion component 2750 can convert the constrained execution tree 2745 from the first query language to the second query language. That is, the conversion component can convert the constrained execution tree 2745 into a converted constrained execution tree 2755. Any suitable query language (e.g., SQL, SparkQL, Kusto query language, C# Linq) can be implemented. In some embodiments, the constrained execution tree 2745 and / or the converted constrained execution tree 2755 can be executed to test for failure, and failure can result in rejection of a particular execution, a set of executable logic units, the entire query 2710, or others.

[0134] The resulting execution tree (e.g., constrained execution tree 2745 and / or transformed constrained execution tree 2755, as appropriate) can be passed to execution component 2760 for execution (e.g., execution of the corresponding execution plan). Typically, the execution operates to extract collaborative intelligence 2770 from the collaborative data. In some embodiments, collaborative intelligence 2770 is returned intact to the requesting data consumer. In some embodiments, additionally or alternatively, one or more constraints can be enforced on collaborative intelligence 2770 before transmission to the requesting data consumer.

[0135] As a non-limiting 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: a requirement of at least 20 unique customers per aggregation, aggregations must span at least 48 hours, cannot aggregate by user ID, cannot extract user ID, and round numeric results to the nearest two digits. Further assume that the tenant agreement allows the data consumer to extract the average amount spent per customer per week in each store. Fig.28A An example of a corresponding query in Structured Query Language (SQL) 2810 is illustrated. This query language is intended as an example only, and any suitable query structure may be implemented.

[0136] Query 2810 may be parsed and converted into a corresponding execution tree (e.g., via Fig. 27 's query parser 2730). Fig.28B The diagram shows Fig.28A2810. In general, in a query execution tree, each executable logic unit receives data from a previous executable logic unit and receives one or more parameters for transforming the data. When the execution tree 2820 is executed, the data is passed from the bottom to the top along the left branch of the execution tree 2820. As the data is passed, each executable logic unit applies one or more associated commands or operations. As will be appreciated by those skilled in the art, the execution tree 2820 includes a hierarchical arrangement of executable logic units that, if executed, will implement the query 2810.

[0137] To take into account applicable constraints, execution tree 2820 can be transformed into Fig.29A The constrained execution tree 2910 (e.g., by Fig. 27 Constraint query formatter 2740). Fig.28B The execution tree 2820 and Fig.29A The differences between constrained execution trees 2910 of are illustrated with boxes drawn around different elements. For example, constrained execution tree 2910 includes rounding operation 2915 that implements the above constraint, where a numeric result must be rounded to the nearest two digits. In another example, constrained execution tree 2910 includes filtering operation 2925 that implements the above constraint, where an aggregate must include data for at least 20 unique customers. This configuration of constrained execution tree 2910 is intended to be an example only, and any suitable configuration may be implemented. For purposes of illustration, Fig.29B An example of a corresponding query 2920 corresponding to the constrained execution tree 2910 is illustrated. It should be understood that the query 2920 includes additional elements not present in the query 2810, which are used to enforce the above-described example constraints. As will be understood by those skilled in the art, the constrained execution tree 2910 can be executed by traversing and executing the hierarchy of executable logic units of the tree from bottom to top along the left branch. In this way, the constrained execution tree 2910 can be executed to extract collaborative intelligence, and the collaborative intelligence can be returned to the requesting data consumer.

[0138] Sample distributed computing environment

[0139] Reference now Fig.30 , Fig.30 An example distributed computing environment 3000 is illustrated in which embodiments of the present disclosure may be employed. In particular, Fig.30The high-level architecture of an example cloud computing platform 3010 is shown, which can host a collaborative intelligent environment or a portion thereof (e.g., a data trustee environment). It should be understood that this arrangement and other arrangements described herein are set forth only as examples. For example, as described above, many of the elements described herein can be implemented as discrete or distributed components or combined with other components, and implemented in any appropriate combination and position. In addition to or in place of those arrangements and elements shown, other arrangements and elements (e.g., machines, interfaces, functions, commands, and groups of functions) can also be used.

[0140] The data center can support a distributed computing environment 2400, which includes a cloud computing platform 3010, a rack 3020, and nodes 3030 (e.g., computing devices, processing units, or blades) in the rack 3020. A collaborative intelligent environment and / or a data trustee environment can be implemented using a cloud computing platform 3010 that runs cloud services across different data centers and geographic regions. The cloud computing platform 3010 can implement a structure controller 3040 component for providing and managing resource allocation, deployment, upgrades, and management of cloud services. Typically, the cloud computing platform 3010 is used to store data or run service applications in a distributed manner. The cloud computing infrastructure 3010 in the data center can be configured to host and support the operation of endpoints of specific service applications. The cloud computing infrastructure 3010 can be a public cloud, a private cloud, or a dedicated cloud.

[0141] Node 3030 may be provided with a host 3050 (e.g., an operating system or runtime environment), which runs a defined software stack on node 3030. Node 3030 may also be configured to perform a specialized function (e.g., a computing node or a storage node) within cloud computing platform 3010. Node 3030 is allocated to run one or more parts of a tenant's service application. A tenant may refer to a customer utilizing the resources of cloud computing platform 3010. The service application components of cloud computing platform 3010 that support a specific tenant may be referred to as a tenant infrastructure or lease. The terms service application, application, or service are used interchangeably herein and generally refer to any software or software portion running on a data center, or an access storage device and computing device location within a data center.

[0142] When node 3030 supports more than one separate service application, node 3030 can be divided into virtual machines (e.g., virtual machine 3052 and virtual machine 3054). Physical machines can also run separate service applications concurrently. Virtual machines or physical machines can be configured as personalized computing environments supported by resources 3060 (e.g., hardware resources and software resources) in cloud computing platform 3010. It is expected that resources can be configured for specific service applications. In addition, each service application can be divided into functional parts so that each functional part can run on a separate virtual machine. In cloud computing platform 3010, multiple servers can be used to run service applications and perform data storage operations in a cluster. In particular, servers can perform data operations independently, but are disclosed as a single device called a cluster. Each server in a cluster can be implemented as a node.

[0143] The client device 3080 can be connected to the service application in the cloud computing platform 3010. The client device 3080 can be any type of computing device, for example, it can correspond to the reference Fig.30 The computing device 3000 described above. The client device 3080 may be configured to issue commands to the cloud computing platform 3010. In an embodiment, the client device 3080 may communicate with the service application through a virtual Internet Protocol (IP) and a load balancer or other means of directing communication requests to specific endpoints in the cloud computing platform 3010. The components of the cloud computing platform 3010 may communicate with each other over a network (not shown), which may include, but is not limited to, one or more local area networks (LANs) and / or wide area networks (WANs).

[0144] Example operating environment

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

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

[0147] refer to Fig.31 , computing device 3100 includes bus 3110 that directly or indirectly couples the following devices: memory 3112, one or more processors 3114, one or more presentation components 3116, input / output ports 3118, input / output components 3120, and an illustrative power supply 3122. Bus 3110 represents what may be one or more buses (such as an address bus, a data bus, or a combination thereof). For conceptual clarity, the lines are shown. Fig.31 , and other arrangements of the described components and / or component functions are also contemplated. For example, a presentation component such as a display device may be considered an I / O component. In addition, a processor has memory. We recognize that this is the nature of the art and reiterate that Fig.31 This is merely an illustration of an example computing device that can be used in conjunction with one or more embodiments of the present invention. No distinction is made between categories such as "workstation," "server," "laptop," "handheld device," etc., as all of these are in the same category. Fig.31 and may refer to a "computing device".

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

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

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

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

[0152] I / O ports 3118 allow computing device 3100 to be logically coupled to other devices including I / O components 3120, some of which may be built-in. Illustrative components include a microphone, joystick, game pad, satellite dish, scanner, printer, wireless devices, and the like.

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

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

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

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

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

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

[0159] For purposes of this disclosure, the word "including" has the same broad meaning as the word "comprising," and the word "access" includes "receiving," "referencing," or "retrieving." Additionally, the word "transmit" has the same broad meaning as the word "receiving" or "transmitting" implemented by a software or hardware-based bus, receiver, or transmitter using the communication media described herein. Additionally, unless otherwise indicated to the contrary, words such as "a" and "an" include the plural and singular. Thus, for example, where there are one or more features, the constraint of "feature" is satisfied. Likewise, the term "or" includes the conjunctive form, the disjunctive form, and both (thus, a or b includes a or b and a and b).

[0160] For the purpose of the above detailed discussion, embodiments of the present invention are described with reference to a distributed computing environment. However, the distributed computing environment described herein is merely exemplary. Components may be configured to perform novel aspects of the embodiments, where the term "configured for" may refer to "programmed to" use code to perform a specific task or implement a specific abstract data type. In addition, although embodiments of the present invention may generally refer to the collaborative intelligent environment and schematic diagrams described herein, it should be understood that the described techniques may be extended to other implementation contexts.

[0161] Embodiments of the present invention have been described with respect to particular embodiments, which are intended in all respects to be illustrative rather than restrictive. Alternative embodiments will become apparent to those of ordinary skill in the art to which the present invention pertains without departing from the scope of the present invention.

[0162] From the foregoing it will be seen that the present invention is one well adapted to attain all the intentions and objects set forth above, together with other obvious advantages and advantages inherent in its construction.

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

Claims

1. An apparatus for a data trustee environment, comprising: one or more hardware processors and a memory configured to provide computer program instructions to the one or more hardware processors; as well as an interface component configured to: receive, using the one or more hardware processors, from a group of participating tenants of the data trustee environment, a configuration of a multi-participant pipeline under development by the group, the configuration comprising specification of: (i) inputs into the multi-participant pipeline, (ii) one or more computational steps of the multi-participant pipeline, (iii) use by the multi-participant pipeline of at least one shielded asset that is not a participating tenant of the group, the data trustee environment being configured to restrict the use of the at least one shielded asset to within the data trustee environment, and (iv) at least one of a collaborative dataset or permitted queries on the collaborative dataset that may be derived by executing the one or more computational steps on the input, Wherein the data trustee environment is configured to, upon being triggered by one of the participating tenants who authorizes the participating tenants, deploy the configuration of the multi-participant pipeline in the data trustee environment based on the use of the at least one shielded asset to export the collaborative dataset without exposing the at least one shielded asset to any of the participating tenants.

2. The apparatus of claim 1, wherein the at least one shielded asset comprises a template data privacy pipeline, and wherein the configuration of the multi-participant pipeline is built upon the template data privacy pipeline. 3 . The apparatus of claim 1 , wherein the at least one shielded asset comprises at least one of a data set or a computation script owned by the non-participating tenant.

4. An apparatus according to claim 1, wherein the data trustee environment is configured to restrict the use of the at least one shielded asset by one of the participating tenants within the data trustee environment based on a collaborative smart contract, the collaborative smart contract includes the right granted by the non-participating tenant to the participating tenant to use the at least one shielded asset, the right being subject to a rights constraint or policy restriction, and wherein the data trustee environment is configured to: enforce the rights constraint or policy once the multi-participant pipeline is triggered by the authorized participating tenant.

5. The apparatus of claim 1, wherein the interface component is further configured to: accept an input that triggers the multi-participant pipeline, and based thereon, cause the data trustee environment to write the multi-participant pipeline.

6. The apparatus of claim 1, wherein the interface component comprises a network service of the data trustee environment and is configured to prompt the participating tenants to specify the configuration of the multi-participant pipeline.

7. The apparatus of claim 1, wherein the data trustee environment is configured to deploy the multi-participant pipeline as a cloud service.

8. One or more computer storage media storing computer usable instructions that, when used by one or more computing devices, cause the one or more computing devices to perform operations comprising: providing, by a data trustee environment, authorization to a participating tenant of the data trustee environment to use (i) a first shielded asset associated with a first collaborative smart 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 smart contract between the participating tenant and a second tenant of the data trustee environment, wherein the data trustee environment is configured to restrict use of the first shielded asset and the second shielded asset by the participating tenant to within the data trustee environment based on the first collaborative smart contract and the second collaborative smart contract, respectively; and receiving a configuration of a data privacy pipeline from the participating tenant, the configuration comprising specification of: (i) inputs into the data privacy pipeline, (ii) one or more computation steps of the data privacy pipeline, (iii) use of the data privacy pipeline by the first shielding asset and the second shielding asset, and (iv) at least one of a collaborative dataset or permitted queries on the collaborative dataset that is derivable by performing the one or more computation steps on the input, The data trustee environment is configured to, once triggered by the participating tenant, deploy the configuration of the data privacy pipeline in the data trustee environment based on the use of the first shielded asset and the second shielded asset to export the collaborative dataset without exposing the first shielded asset and the second shielded asset to the participating tenant.

9. The one or more computer storage media of claim 8, wherein the first shielding asset comprises a template data privacy pipeline, and wherein the configuration of the data privacy pipeline is built upon the template data privacy pipeline.

10. The one or more computer storage media of claim 8, wherein the first shielded asset comprises at least one of a data set or a computational script owned by the first tenant.

11. One or more computer storage media according to claim 8, wherein the first collaborative smart contract includes a right granted by the first tenant to the participating tenant to use the first shielded asset, the right being subject to a rights constraint or policy restriction, and wherein the data trustee environment is configured to enforce the rights constraint or policy once the data privacy pipeline is triggered by the participating tenant.

12. The one or more computer storage media of claim 8, wherein the data trustee environment is further configured to: accept input that triggers the data privacy pipeline, and based thereon, write the data privacy pipeline.

13. The one or more computer storage media of claim 8, wherein the data trustee environment comprises a network service configured to prompt the participating tenants to specify the configuration of the data privacy pipeline.

14. The one or more computer storage media of claim 8, wherein the data trustee environment is configured to deploy the data privacy pipeline as a cloud service.

15. A computer-implemented method comprising: providing, by a data trustee environment, authorization to a first tenant of the data trustee environment to use a shielded asset controlled by a second tenant of the data trustee environment, wherein the data trustee environment is configured to: restrict use of the shielded asset by the first tenant to within the data trustee environment; as well as receiving, from the first tenant, a configuration of a data privacy pipeline, the configuration including a specification of use of the shielded asset by the data privacy pipeline and including a specification of at least one of: (i) an input into the data privacy pipeline derived by pre-processing performed outside the data trustee environment, or (ii) an output derived by the data privacy pipeline and triggering post-processing outside the data trustee environment; The data trustee environment is configured to: once triggered by the first tenant, deploy the configuration of the data privacy pipeline in the data trustee environment based on the use of the shielded asset without exposing the shielded asset to the first tenant.

16. The method of claim 15, wherein the shielding asset comprises a template data privacy pipeline, and wherein the configuration of the data privacy pipeline is built upon the template data privacy pipeline.

17. A method according to claim 15, wherein the shielded asset is associated with a collaborative smart contract between the first tenant and the second tenant of the data trustee environment, and wherein the data trustee environment is configured to restrict the shielded asset within the data trustee environment based on the collaborative smart contract.

18. A method according to claim 17, wherein the collaborative smart contract includes a right granted by the second tenant to the first tenant to use the shielded asset, the right being subject to a rights constraint or policy restriction, and wherein the data trustee environment is configured to enforce the rights constraint or policy once the data privacy pipeline is triggered by the first tenant.

19. The method of claim 15, wherein the data trustee environment is further configured to: accept input that triggers the data privacy pipeline, and based thereon, write the data privacy pipeline.

20. The method of claim 15, wherein the data trustee environment comprises a web service configured to prompt the first tenant to specify the configuration of the data privacy pipeline.

Images