Integrating anonymized member-driven cloud-based groups with a content delivery service that collects individual information about content interactions without compromising the identities of group members

Abstract

Techniques are described that allow groups of individuals and / or other entities to interface with a data cloud blockchain network and / or cloud-based platform to collectively share data in a secure and controlled manner. Distributed groups connected to the data cloud network can register and be listed in a searchable directory. Entities interested in accessing data associated with the group can browse the directory and execute smart contracts in the blockchain to track the group's online content interactions in a manner that preserves the anonymity of individual group members. Data usage and performance metrics can be tracked in the blockchain network using a data cloud service, and the metrics can be written to a distributed ledger in the blockchain network. Smart contracts and chaincode in the network can initiate blockchain transactions based on performance metrics and / or other aspects associated with accessing information about the group.

Description

[Technical Field]

[0001] Incorporation by Reference; Disclaimer U.S. Non-Provisional Patent Application No. 18 / 159,013, filed January 24, 2023, and U.S. Provisional Patent Application No. 63 / 392,055, filed July 25, 2022, are incorporated herein by reference. Applicant hereby withdraws any disclaimer of the scope of the claims in the parent application or its prosecution history, and reports that the claims in this application may be broader than the claims in the parent application.

[0002] This application is related to U.S. Patent Application No. 16 / 835,169, entitled "DISTRIBUTED AND BLOCKCHAIN-BASED LEDGERS FOR DATA CLOUD SERVICES," which is incorporated herein by reference.

[0003] Technical Field This disclosure relates to distributed computing systems and architectures, and more particularly to integrating anonymized, member-driven, cloud-based groups with content distribution services. [Background technology]

[0004] background Cloud-based data management platforms include networked computing resources for collecting and managing data transactions between multiple entities. Application and content delivery services can leverage data from the platform to improve various data-driven functions. For example, cloud-based data management platforms can also provide or improve actionable insights for consumer applications by performing big data, machine learning, and / or other artificial intelligence (AI) analytics on data managed by the platform. Insights can be used to perform targeted actions, such as selecting audience segments and rendering content in a more efficient and effective manner.

[0005] Data privacy, data integrity, and system scalability may be concerns among participants in a cloud-based data management platform. Data providers and consumers may inherently distrust other parties in the cloud system. Data breaches and unauthorized use of datasets may expose data providers and data consumers to various risks, including legal liability, exposure of confidential information to unauthorized entities, data corruption, and revenue loss. Furthermore, inaccurate or low-quality data may limit or harm the performance of consumer applications, leading to ineffective and inefficient resource utilization. Large-scale systems may link thousands or more entities, risking the loss of sensitive data.

[0006] The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Thus, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.

[0007] Embodiments are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings. It should be noted that references to "one" or "an" embodiment in this disclosure do not necessarily refer to the same embodiment, but rather mean at least one. [Brief explanation of the drawings]

[0008] [Figure 1] FIG. 1 illustrates an exemplary set of cloud-based groups integrated into a data cloud network, according to some embodiments. [Figure 2] FIG. 1 illustrates an exemplary set of operations for providing access to data associated with a group having a content delivery service provider, according to some embodiments. [Figure 3] FIG. 1 illustrates an exemplary data cloud blockchain system with support for distributed groups, according to some embodiments. [Figure 4] FIG. 1 illustrates an example set of operations for managing transaction flow within a blockchain network, according to some embodiments. [Figure 5] FIG. 1 illustrates an example set of operations for registering a distributed group into a blockchain network, according to some embodiments. [Figure 6] FIG. 1 illustrates an example set of operations for searching a dataset provided by a distributed group and executing a blockchain transaction, according to some embodiments. [Figure 7] FIG. 1 illustrates an exemplary set of operations for reconciling transactions in a main blockchain and a sidechain associated with a DAO, according to some embodiments. [Figure 8] FIG. 1 illustrates a block diagram of a computer system according to some embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0009] Detailed Description In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding. One or more embodiments may be practiced without these specific details. Features described in one embodiment may be combined with features described in a different embodiment. In some instances, well-known structures and devices are described with reference to block diagram form in order to avoid unnecessarily obscuring the present invention.

[0010] 1.Overview 2. Integration with cloud-based groups and data cloud services 3. Member-Driven Policies and Protocols 4. Group Opacity 5. Distributed Ledgers and Permissioned Blockchains 6. Ledger Transaction Management 7. Smart contracts for sharing identifiers and other data 8. Data Usage and Performance-Based Smart Contracts 9. Ledger-based deletion tracking and privacy controls 10. Smart contracts for automatically modifying shared datasets 11. Computer Networks and Cloud Networks 12. Hardware Overview 13. Miscellaneous; Extensions 1.Overview

[0003] Techniques are described for integrating anonymized, member-driven, cloud-based groups and content distribution services within a sharing platform. The techniques enable the content distribution service to collect individual information about content interactions associated with a group without compromising the identities of group members. Members of the group, individually and at the group level, can benefit from sharing content interactions and / or other anonymized group information with the content distribution service without concern that sensitive information of individual group members may be accidentally leaked.

[0011] In some embodiments, a cloud-based group is associated with member-driven policies and / or protocols for interacting with entities external to the group. For example, a cloud-based group may establish conditions for joining the group, define a group governance model including voting rights for coordinating changes / actions made by the group, and / or create / publish application programming interfaces (APIs) and / or code that control access to data shared by the group. Thus, member-driven policies and protocols may provide individual members with the ability to influence the conditions under which external entities are permitted to collect and / or otherwise access information about members of the group.

[0012] If an entity outside the group meets the conditions for accessing data associated with the group, access can be granted in a manner that does not reveal the identities of individual group members. For example, the data cloud platform can track content interactions at the group level using a group identifier shared by members of the group and that does not reveal individual member identifiers. Individual group members may choose to reveal their identities on an individual basis and work directly with content delivery service providers. However, the platform can prevent content delivery service providers from identifying the identities of individual group members without the implicit or explicit consent of the individual group members.

[0013] In some embodiments, the data cloud platform provides a service that allows external entities to collect group-level information that is anonymized at the individual level. For example, a content delivery service provider can determine group-level impression counts for a set of content served to members of a group, statistics about how many group members interacted with the content, information about group sentiment toward the content, and / or other information about how the group interacted with the content. The data cloud platform can track content interactions at the group level without exposing individual group member identifiers, personally identifiable information (PII), or other data that is private at the individual member level.

[0014] In some embodiments, the data cloud platform includes a search interface through which an entity can identify cloud-based groups with which to collaborate. For example, an entity can browse a directory or submit a query for groups that meet a set of criteria. Once a set of one or more target groups is identified, the entity can submit a request to collect group-level information and / or otherwise access group-level data. Members of the group can vote on whether to accept a proposal from an external entity and / or set terms for approving the collaboration. Additionally or alternatively, members can pre-approve conditions under which an external entity can access group-level data. By pre-defining and approving conditions that an external entity must meet to collaborate with the group, members do not need to vote each time an external entity submits a request to access the group's data. Requests can be automatically approved or denied based on whether the pre-approved conditions are met.

[0015] In some embodiments, the data cloud platform can trigger one or more transactions based on the tracked content interactions of a cloud-based group. For example, a transaction may be performed to transfer digital tokens, coupons, currency, and / or other incentives from an entity accessing the data to the group. Additionally or alternatively, the data cloud platform can trigger other transactions, which may include blockchain transactions, as further described herein. The consideration for accessing the group's data may be voted on or otherwise determined based on the group's governance policies and protocols. Thus, the transactions executed by the data cloud platform may vary on a case-by-case basis.

[0016] In some embodiments, cloud-based groups, content service providers, and / or other entities interface with a Data Cloud Blockchain network to collectively share data in a secure and controlled manner. Cloud-based groups can create smart contracts to control access to data shared by the group, establish terms for joining the group, implement a group governance model including voting rights to coordinate changes / actions made by the group, and / or influence other transactions within the blockchain network. Cloud-based groups connected to the Data Cloud Blockchain network can register and be listed in a searchable directory. The directory can further include information about registered groups (e.g., group attributes) and / or high-level descriptions of the data shared by the group. Advertisers and / or other entities interested in accessing the shared data can browse the directory and execute smart contracts in the blockchain to access data shared by one or more registered groups and collect / use the data (e.g., for online campaigns, social relationship management services, and / or other applications). Data privacy can be maintained through the use of hashed identifiers or other data objects useful only in the Data Cloud Blockchain environment. Data usage and performance metrics can be tracked in a blockchain network using a data cloud service, and the metrics can be written to a distributed ledger within the blockchain network. Smart contracts / chaincode within the network can include reconciliation transactions in which groups and / or their individual members are compensated based on usage and / or performance metrics associated with the shared data. Blockchain tokens and / or cryptocurrencies can be used to compensate groups and / or individual group members.Separate smart contracts can govern blockchain transactions between individual members of a decentralized group and the decentralized group as a unit within a blockchain network.

[0017] One or more embodiments described and / or claimed herein may not be included in this General Summary section.

[0018] 2. Integration with cloud-based groups and data cloud services FIG. 1 illustrates an exemplary set of cloud-based groups integrated into a data cloud network, according to some embodiments. As shown in FIG. 1, system 100 includes cloud-based groups 102, a data cloud platform 112, and a content service provider 122. In one or more embodiments, system 100 may include more or fewer components than those shown in FIG. 1. The components shown in FIG. 1 may be local or remote from one another. The components shown in FIG. 1 may be implemented in software and / or hardware. Each component may be distributed across multiple applications and / or machines. In some cases, multiple components may be combined into a single application and / or machine. Operations described with respect to one component may instead be performed by another component.

[0019] Cloud-based groups 102 represent private groups established using one or more cloud services. Different groups can be established using the same cloud platform and / or different cloud platforms. Exemplary cloud-based groups can include Facebook® groups, Discord® groups / servers, Slack® channels, and private groups established through other social media platforms. Users can connect to the cloud service using a client application, such as a browser or mobile application, to join and sign in to private groups.

[0020] Once connected to a private group, the cloud service can allow users to perform operations permitted only by verified and authenticated group members. For example, users can communicate with one or more other members of the group using voice over Internet Protocol (VoIP), instant messaging, short message service (SMS), and video calling through private chats with other members or the group as a whole. Additionally or alternatively, users can perform other operations, including voting and other group management, as discussed further herein. One or more of the functions can be specific to the cloud platform on which the group is formed.

[0021] In some embodiments, cloud-based group 102 is associated with management policies and protocols 104, anonymized group data 106, private member data 108, and a cloud API 110. Management policies and protocols 104 define rules and procedures for managing the group, which may include member-driven rules and procedures that enable self-management of group members. For example, management policies and protocols 104 may define a voting protocol by which members can vote to collaborate with external parties and / or perform other group-level actions. Members can further vote on whether to engage in other group-based actions, such as admitting new members into the group, sharing group-level data with external entities, and managing blockchain transactions within a blockchain network private to the group.

[0022] Anonymized group data 106 includes data identifying attributes of a cloud-based group, such as the group name, group interests, and other shared member attributes. For example, a private group may be dedicated to discussing a particular topic, such as a sports team, a profession, or an activity in which members are interested. Additionally or alternatively, group-level data 106 may include information about group member interactions with online content at the group level. Examples may include total impressions, representing the total count or percentage of members in the cloud-based group who viewed or were served content; click-through rate, representing the total count or percentage of members in the cloud-based group who clicked on the content when rendered in a client application; a rating, representing the average group rating of the content; and sentiment, representing whether the group as a whole viewed the content positively or negatively. However, the group-level information defined and collected may vary from implementation to implementation.

[0023] The anonymized group data 106 does not include private member data 108, such as personally identifying information of individual members of the group, member social media handles, SMS numbers, private group messages, and other content restricted to members of the group. Group messages and other content shared by one group member with other members of the group can be protected by an authenticated cloud service. In particular, the cloud service allows only authenticated members of the cloud-based group to view such private data. For example, group messages can be encrypted, restricting access to only members of the group who possess the encryption key to decrypt the private data. Members who sign in to a cloud-based account can access and use the encryption key to view private communications using a client application. Thus, external entities can be prevented from accessing and viewing the private member data 108 because they do not have access to encryption keys owned by members of the cloud-based group.

[0024] The cloud API 110 can provide an interface through which the cloud-based group 102 communicates with the data cloud platform 112 and / or the content service providers 122. In some embodiments, the cloud API 110 provides an interface through which group members can register with the data cloud platform 112, receive transaction proposals from the content service providers 122, submit acceptances or rejections of transaction proposals, and / or provide anonymized group data to the data cloud platform 112 and / or the content service providers 122. The cloud API 110 can follow a RESTful API architecture and operate upon HTTP requests that invoke functions for interacting with the group. However, the API can follow other structural styles depending on the particular implementation.

[0025] The data cloud platform 112 includes services for facilitating digitized agreements and transactions between cloud-based groups 102 and content service providers 122. In some embodiments, the services include a content delivery service 114, a tracking and analytics service 116, a transaction service 118, and a query service 120. The services may correspond to web services or processes running on one or more servers. As noted above, the components comprising the services of the system 100 may be combined, omitted, or otherwise varied from implementation to implementation.

[0026] In some embodiments, the content delivery service 114 serves targeted content to client applications, such as web browsers, mobile applications, and set-top boxes. The content delivery service 114 can monitor web traffic at one or more sites and extract information about the cloud-based groups to which a web page visitor or mobile application user belongs. For example, a server running the cloud-based service can generate an HTTP cookie that authenticates a user as logged into a cloud-based group, such as a particular social media private channel, and information about the cloud-based group. The HTTP cookie can include a group identifier and / or other anonymized group-level data. A second server running the content delivery service 114 can access the HTTP cookie from a client-side application when the user visits a website or accesses a mobile application page to identify anonymized group information associated with the cloud-based group to which the user belongs. The content delivery service 114 can determine whether the anonymized group identifier matches an identifier of an audience segment defined for a particular set of content. If the group identifiers match, the second server can send the content to the client-side application, which can render the content within the client-side application's page. If the group identifiers do not match, the second server can refrain from sending the content. Thus, the second server can operate on the anonymized group information to selectively render content, thereby optimizing the user's browsing experience without compromising the user's anonymity. Furthermore, resources used to generate and serve content can be used more efficiently and effectively, avoiding wasting resources on users who are unlikely to be interested in a particular set of content.It also operates on cookie data, allowing web servers to deliver content to web browsers or mobile applications hundreds, or even thousands, of times per second with minimal latency.

[0027] The tracking and analytics service 116 can collect / update anonymized group data for cloud-based groups and perform analytics on the data. For example, the tracking and analytics service 116 can track how many times a particular content item is served to members of a cloud-based group by the content delivery service 114. The tracking and analytics service 116 can maintain a content item counter that is incremented each time a group identifier extracted from an HTTP cookie is matched for a cloud-based group and the content is rendered. Additionally or alternatively, the tracking and analytics service 116 can track and update other metrics and anonymized group information. As described above, metrics can include click-through rates, user ratings, sentiment, and / or other information regarding how users interact with content.

[0028] The tracking and analytics service 116 can apply machine learning, big data analytics, and / or other techniques for analyzing data to analyze the data and provide insights for optimizing the content delivery service. For example, the tracking and analytics service 116 can analyze the context of web pages and mobile applications to determine whether to serve content in a given context. Even if members of a cloud-based group visit a particular web page or use a mobile application, the context intelligence engine can determine that the content should not be served in a given context. For example, a website or mobile application may be associated with a controversial subject, and the service can prevent the content from being served to protect the content provider's brand safety. The context intelligence engine can include one or more models trained using machine learning algorithms to learn patterns of contexts in which content is and is not allowed to be served. Additionally or alternatively, the tracking and analytics service 116 may provide other analyses, such as sentiment analysis to measure the sentiment of a cloud-based group toward a particular set of content and estimated measures of campaign effectiveness for different cloud-based groups.

[0029] As described above, analytics can use machine learning to generate estimates or predictions given a set of data. A machine learning algorithm is an algorithm that can iterate using a set of training data to learn a target model f that best maps a set of input variables to output variables. The training data includes a dataset and associated labels. The dataset is associated with input variables for the target model f. The associated labels are associated with output variables of the target model f. The training data can be updated, for example, based on feedback regarding the accuracy of the current target model f. The updated training data is fed back to the machine learning algorithm, which then updates the target model f.

[0030] In some embodiments, the transaction service 118 manages digitized agreements and / or other transactions between the cloud-based group 102 and the content service provider 122. For example, the cloud-based group 102 and the content service provider 122 can enter into a digitized agreement that allows the content service provider 122 to track content interactions of members of the cloud-based group. As described in further detail below, the digitized agreement can correspond to a smart contract. In other embodiments, the digitized agreement can be an electronically recorded digital contract or agreement that follows an agreement protocol, the format of which can vary from implementation to implementation. The transaction service 118 can register and enforce the digitized agreement.

[0031] In some embodiments, when the transaction service 118 receives a new digitized agreement, the transaction service 118 verifies the agreement (e.g., using the digital signatures of the cloud-based group and the content service provider). If the verification is successful, the transaction service 118 can manage and enforce the agreement. For example, if the agreement allows the content service provider to collect information about the group-level content interactions of the cloud-based group, the transaction service 118 can configure other services of the data cloud platform 112 to collect information about the members of the cloud-based group and provide the information to the content service provider. The transaction service 118 can transfer digital tokens, coupons, payments, and / or other consideration from the content service provider to the cloud-based group based on the tracked content interactions according to the terms set forth in the digitized agreement. In other embodiments, the agreement can be enforced through members of the data cloud blockchain, as discussed in more detail below.

[0032] In some embodiments, the query service 120 manages a registry of cloud-based groups and provides content providers with a search capability to identify groups of interest. The registry can include cloud-based groups that have explicitly requested to be registered with the data cloud platform 112. Additionally or alternatively, the registry can include cloud-based groups discovered by the data cloud platform 112, such as by crawling the cloud service's website, to identify private groups.

[0033] The query service 120 can build a registry that includes an entry for each registered group. The query service 120 can populate the group's entry with information about the group. For example, the registry entry can include a group identifier that uniquely identifies the group, the cloud platform on which the group is formed, and group attributes that identify common characteristics of the group members. The query service 120 can process queries submitted by content service providers 122 to identify groups that meet the query criteria.

[0034] The content service provider 122 can submit queries to the data cloud platform 112 using the search interface 124. For example, the content service provider 122 can submit a request to identify groups that are dedicated to a particular topic and / or have other group attributes. In response, the query service 120 can search the registry for groups that match the specified criteria.

[0035] The interfaces described herein, including the search interface 124, can render user interface elements and receive input via user interface elements. Examples of interfaces include graphical user interfaces (GUIs), command line interfaces (CLIs), tactile interfaces, and voice command interfaces. Exemplary user interface elements include check boxes, radio buttons, drop-down lists, list boxes, buttons, toggles, text fields, date and time selectors, command lines, sliders, pages, and forms. For example, the search interface 124 can include a text box for entering text specifying keywords that can be matched to groups based on the group name and / or other attributes. Additionally or alternatively, the search interface 124 may present other user interface elements for specifying query criteria and / or filtering groups.

[0036] The transaction proposal interface 126 provides an interface through which the content service provider 122 can submit a proposed digitized agreement to the cloud-based group 102. For example, the transaction proposal interface 126 can enable the content service provider 122 to submit a request to collect anonymized group data about the group and specify a price for granting access. The proposed price may be a flat rate, based on collected performance metrics, and / or may be subject to other conditions defined in the proposed digitized agreement. If the transaction proposal is accepted, the terms and conditions defined in the digitized agreement can be enforced by the transaction service 118, peer nodes in the blockchain network, and / or other system components.

[0037] The content editor 128 provides an interface through which the content service provider 122 can create and / or submit content data 130 for serving via the content delivery service 114. For example, the content editor 128 can provide an interface for submitting images, videos, hyperlinks, and / or other multimedia content in a format that a web server can use to render in a client-side application. The content service provider can upload content and any associated code to the data cloud platform. The data cloud platform can use one or more servers to monitor online interactions and, when a content serving condition is met, such as when a group identifier in an HTTP cookie matches the group identifier of a cloud-based group selected by the content service provider, use the uploaded content and code to serve the content to the client-side application.

[0038] 3. Member-Driven Policies and Protocols In some embodiments, the digitized agreement follows member-driven policies and protocols. If the proposed transaction / digitized agreement satisfies the member-driven policies and protocols, the proposed agreement can be accepted and implemented within system 100. If not, the agreement can be rejected, in which case the content service provider will be prevented from accessing anonymized group data, including tracking group-level content interactions.

[0039] In some embodiments, the member-driven policies and protocols define a voting protocol for accepting a proposal. For example, the voting protocol can be defined such that a proposal is accepted if a majority of members vote to accept it. As another example, a proposal can be accepted only if all members of the group accept it. In yet another example, member votes may be weighted differently and / or some members may not have the right to vote, depending on group policy. A proposal can be accepted if the weighted votes exceed a threshold.

[0040] Additionally or alternatively, the member-driven policy may define conditions for automatically accepting proposals. For example, the member-driven policy can be defined to reject proposals from external entities that are contrary to or otherwise incompatible with the group's objectives. In another example, the member-driven policy can accept proposals only if the payment for accessing anonymized group data exceeds a threshold. Preconditions for accepting a proposal can be voted on or set accordingly based on group management policies, rules, or heuristics. Thus, policies and protocols can vary from group to group.

[0041] Member-driven policies and protocols can govern other aspects of the group. For example, policies and protocols can define rules regarding who can join a group. Entities that do not meet a set of criteria can be barred from joining a private group. Additionally or alternatively, members can vote on whether an individual can join the group. In another example, policies and protocols can define how compensation received by a group is distributed among the group's members. Compensation can be distributed evenly, based on individual member contributions to the group, based on the member's seniority, or according to other rules / policies set by the group. As can be seen from the above examples, member-driven policies and protocols can provide a level of control and self-management by which members can influence group-level behavior.

[0042] As described above, an external entity, such as a content service provider 122, can submit a request to collaborate with a cloud-based group 102. Figure 2 shows an example set of operations for providing access to data associated with a group with a content delivery service provider, according to some embodiments. One or more of the steps may be omitted, repeated, and / or performed in a different order. Thus, the particular arrangement of steps shown in Figure 2 should not be considered limiting the scope of the embodiments.

[0043] The data cloud platform 112 receives a request to track content interactions at a group level (operation 202). In some embodiments, the request may include a digitized agreement proposal for tracking the content interactions. The agreement may specify terms for tracking the content interactions, such as time frames over which interactions may be tracked, websites over which content interactions may be tracked, group-level data that may be collected, and / or other terms of service. Additionally or alternatively, as discussed above, the digitized agreement proposal may specify a fee for accessing the data.

[0044] In some embodiments, the transaction proposal is advertised to one or more cloud-based groups. The cloud-based groups may be selected by the content service provider on an individual group basis, or the proposal may be advertised to all groups that meet a set of query criteria. For example, the proposal may be advertised only to groups with attributes that match attributes specified in the query. Once advertised, the groups may vote for the proposal according to a group-specific voting protocol. The voting protocol may vary from group to group for the same advertised proposal based on a group management model associated with the group. Additionally or alternatively, the group may establish predetermined rules, conditions, and / or heuristics for accepting the advertised proposal, as discussed above.

[0045] The data cloud platform 112 determines whether the request is accepted by the group (operation 204). The cloud-based group can send voting results or automated proposed analysis to the data cloud platform 112. If the denial is rejected, the process ends and the content service provider is prevented from collecting or tracking group-level data.

[0046] If the proposal is accepted, the data cloud platform 112 tracks online group-level content interactions without compromising the anonymity of individual members (operation 206). As part of the agreement, the cloud-based service provider may provide a group identifier that can be used to track content-level interactions in an anonymized manner. The data cloud platform 112 may store the group identifier, monitor traffic on one or more sites, and compare the group identifier with data collected by the server from HTTP cookies during content interactions to determine whether the identifiers match. If a match is detected, the data cloud platform 112 may update the group data. The data cloud platform 112 may further track types of interactions that may affect how the group data is updated. For example, if a user simply views content, the data cloud platform 112 may increment an impression count value. If a user clicks on content, the data cloud platform 112 may update a click-through rate. Additionally or alternatively, the data cloud platform 112 may update an average group rating and / or sentiment based on how group members respond to the content.

[0047] The data cloud platform 112 executes one or more transactions based on the group-level content interactions and the transaction terms accepted by the group (operation 208). For example, as discussed further herein, the data cloud platform 112 may execute one or more blockchain transactions. Additionally or alternatively, the data cloud platform 112 may execute other transactions to transfer compensation to the data cloud group. The amount of compensation may be a fixed, predetermined amount or may vary based on terms set in a contract. For example, the amount of compensation may be greater the higher the impression count, click-through rate, and / or other performance metrics.

[0048] The tracked content-level interactions can be used to provide insights to content service providers and other entities. For example, the data cloud platform 112 can generate an association mapping of groups to content service providers. The association mapping can identify how various group attributes affect association with content provided by advertisers or other entities. The mapping can highlight which group attributes were more positively correlated with high levels of association and / or which attributes were most negatively correlated.

[0049] The data cloud platform 112 can use the insights to train and tune models that use machine learning to recommend or select group segments for a set of content. For example, when a new set of content is created, a feature vector can be generated based on a set of features associated with the content, which can be extracted from content data and / or metadata. The feature vector can be fed through a model, such as by performing a forward pass through a neural network model, to generate an output indicating the predicted effectiveness of the content for various groups. Based on the model output, the data cloud platform 112 can recommend or select one or more groups with the highest predicted effectiveness scores. Based on the recommended or selected group segments, the content delivery service 114 can configure its servers to render content only to members of the selected group segments.

[0050] 4. Group Opacity When a proposal is advertised and accepted by a cloud-based group, various aspects of the group, including private member data 108, are kept opaque to the external entity advertising the proposal. For example, individual member names, group handles, email addresses, and / or other personally identifying information (PII) are not provided to the external entity, even if the agreement is accepted. Cookies generated by the cloud-based service may contain only anonymized group identifiers, so that private data cannot be linked to the group identifier. In other cases, the data cloud platform 112 may be configured to collect only anonymized group identifiers from cookies, or client-side applications may be configured to allow cookies to contain only anonymized group information.

[0051] Although private member data 108 is opaque to external entities, the data may be accessible to other members of the same cloud-based group. For example, other members of the group may know individual member usernames, email addresses, SMS numbers, and / or other data. Such information may be provided to allow users to join the group, but may remain private behind an authenticated cloud service to prevent non-members from accessing it.

[0052] Other aspects of cloud-based groups can also remain opaque to external entities. For example, digitized agreements may not provide access to view internal group communications, how individual members voted on proposals, how consideration was distributed to group members, and other private group operations. In some embodiments, external entities are limited to receiving an indication of whether a proposal was accepted, and, if accepted, collecting anonymized group data 106 for each accepted digitized agreement.

[0053] In other embodiments, the identity of one or more representative group members may be made public to external entities, and proposals and / or negotiations may be directed to the representative group member without compromising the anonymity of other group members or the security of other private group data.

[0054] When tracking content interactions, the system 100 maintains the anonymity of individual group members. However, individual group members may voluntarily reveal private information to external entities in some circumstances. For example, an individual group member may click on an image or video with an embedded hyperlink created by a content service provider. The embedded hyperlink may direct the user to a website associated with the content service provider. While on the website, such as during an online transaction to purchase an item through the website, the user may voluntarily submit personally identifiable information to the content service provider. Up until that point, the user's anonymity can be maintained even while the user's interactions are tracked online. Furthermore, despite the user's voluntarily revealing information, other members of the group remain anonymous because the private member data 108 is not disclosed to external entities.

[0055] In some embodiments, system 100 includes one or more servers that operate on cookie data provided by a browser and / or other applications running on a client device. As described above, an HTTP cookie can be generated by a server while a user is visiting a website. The cookie can be stored on a visitor's computing device by a web browser or other client-side application used to access the website. Each HTTP cookie stored on the user's computing device can include one or more blocks of data, which can include group-level information about the visitor and / or individual information about the visitor. For example, when a user logs into a cloud-based group, a server associated with the cloud-based group can store a cookie on the user's computing device that includes a hashed group identifier. The server can generate the hashed group identifier by applying a hash function to an identifier (e.g., a group name, number, or other unique alphanumeric text string) that uniquely identifies the group from other groups belonging to the same cloud service. The server may store other group-level information in the cookie, such as interests associated with the cloud-based group (e.g., a group is dedicated to a particular topic, sports team, etc.), group demographics (e.g., age distribution, gender distribution, education level, average income, etc.), group size, and / or group activity level (e.g., average rate of new posts to the group, timestamp of the most recent group post, etc.). Additionally or alternatively, the cookie may store individual information about the user, such as a machine identifier (e.g., the hostname and IP address of the machine used to access the website), the user's email address, location information about the user (e.g., the city and zip code associated with the IP address used to access the website), and online behavior associated with the user (e.g., online purchases, most frequently visited sites, etc.).

[0056] When monitoring the site's web traffic, the server can extract cookies stored on the visitor's computing device and search for group-level data with matching group identifiers and / or other group-level data. If a match is found, the server can serve the content to the client-side application so that the content is rendered within a web or application page visible to the user.

[0057] In some embodiments, the rendered content includes embedded hyperlinks that can be selected by the user. For example, a user can click on the rendered content with a mouse or select the content with a touch screen, thereby activating a hyperlink that redirects the user to a new web or application page. The new page can be rendered in a new tab or window, or can replace the page currently being viewed by the user upon selection.

[0058] In some embodiments, when a user selects a page, system 100 treats this selection as an implicit acceptance to track and / or otherwise access individual information about the user. When a hyperlink is selected, the client-side application may be redirected to connect with a server under the control of the content service provider. Prior to selecting the hyperlink, the server is not connected to the client-side application and does not have the ability to collect individual information about the user. However, once the user is redirected, the server associated with the activated hyperlink may collect cookie data from the user's computing device. In another example, the server may prompt the user via the client-side application, such as by presenting a pop-up window in a browser, to obtain explicit consent to access the individual data before storing and / or accessing any cookie data. If the user declines the prompt, the server may serve the page without storing or accessing the cookie data.

[0059] If the user agrees to allow the server to access their cookie data, the server can read one or more cookies stored on the user's machine. The accessed cookies may have been generated by one or more other servers based on other websites visited by the user. The accessed cookie data may reveal machine IDs, IP addresses, email addresses, and / or other key information about the user. Individual pieces of information may be mapped explicitly or probabilistically to the member's existing user profile. An explicit match may be determined when information extracted from different cookies can be unambiguously mapped to the same user. For example, the information may include matching machine IDs, email addresses, IP addresses, etc. In other examples, a model may be used to estimate the probability when an explicit match is not found. A partial match (e.g., matching machine IDs) may increase the likelihood of a match but may not guarantee that the visitor is the same user corresponding to the profile, as different users may use the same machine or machine information may not be available. If no existing profile for the user exists, the server may create a new profile for the user.

[0060] In some embodiments, a server at the site associated with the hyperlink, or a server from another site, can use the key information extracted from the cookie data to access information about other activities the member performed online. For example, this information can be used to identify which sites a user visits most frequently, their online purchasing behavior, and the cloud-based groups to which the user belongs. The server can use this information to provide targeted advertising, messaging, services, and / or user interface element rendering within client-side applications. For example, a site can show products in which a user has previously expressed interest via different sites linked to the same key information but from different cookies stored in the data cloud platform 112 in the same or probabilistically linked user profiles via different cookie managers provided by the platform.

[0061] Additionally or alternatively, the data cloud platform 112 may host a virtualized browser in a virtual machine that issues requests on behalf of the cloud-based group as a whole through the virtual browser. For example, when a user activates a hyperlink by clicking or otherwise selecting rendered content, a virtual browser instance may intercept the redirect and issue a request to the associated server. This allows requests to be issued from a machine that is served by the data cloud platform rather than an individual user's machine. As a result, if a server attempts to access cookie data, the server does not have access to the cookies stored on the user's machine, thereby preserving individual and group anonymity. The virtual web browser can then act as an intermediary to serve website content to members of the cloud-based group.

[0062] In the above example, individual membership data remains opaque to the content service provider before interaction with the served content occurs. In particular, personal data of members of a cloud-based group, which may be stored in cookies, is not revealed to or accessed by a server controlled by the content service provider before a user selects content or otherwise activates a hyperlink. In response to the interaction, personal information of the member who activated the hyperlink may be made accessible. In other cases, as discussed above, additional safeguards may be implemented to protect the member's anonymity, such as prompting the member as to whether to allow the server to access cookie data stored on the user's machine or using a virtual browser running on a virtual machine. Thus, a member's anonymity may be maintained even after interacting with the content until explicit consent is received or the user explicitly submits information, such as through an online purchase. If a user does not explicitly consent or submit personal information, the member can continue browsing without revealing any personal data. However, in such a scenario, the content service provider may be given access to anonymized group-level data that maintains the opacity of group membership.

[0063] 5. Integration with distributed ledgers and permissioned blockchains The techniques described herein can be implemented by one or more blockchain networks. A blockchain service refers to a network service, such as a Platform as a Service (PaaS) or other cloud service, for maintaining a blockchain-based distributed ledger. A distributed ledger can include a set of blocks linked through cryptographic values that maintain consensus on facts and a history of ledger updates. A distributed ledger can be replicated, shared, and / or synchronized across multiple peer nodes in a blockchain network.

[0064] Blockchain allows entities (internal and external) that do not fully trust each other to agree on updates submitted to a shared ledger by using a peer-to-peer protocol rather than a centralized third-party system that independently maintains the system. Each member of the blockchain can have a copy of the shared ledger that contains a record of transactions made on the platform. A distributed ledger is not owned by one specific entity, and updates to the ledger can be blocked unless they follow the agreed-upon peer-to-peer protocol. Furthermore, cryptographic links between blocks in the ledger can make the record of transactions written to the ledger immutable and tamper-resistant.

[0065] In some embodiments, the techniques described herein are implemented in a permissioned blockchain. A permissioned blockchain is one in which membership is restricted to a set of authorized participants. Permission can be granted by one or more founding members of the blockchain network or according to an administrative model. For example, if a group or institution wishes to join a permissioned blockchain, other constituent members can vote, or a board of directors can decide whether to grant permission. As another example, permissions for institutions can be limited to those granted by authorized authorized agents. Other administrative models can also be used, depending on the specific implementation. Permissioned blockchains are generally more efficient than public blockchains because the number of nodes on the platform can be limited and rules within the blockchain network can be updated more quickly. Permissioned blockchains can further improve overall data quality by preventing entities from participating that are likely to provide inaccurate, erroneous, stolen, or otherwise compromised data. However, one or more embodiments described herein can also be implemented within a public blockchain network.

[0066] In some embodiments, a data cloud blockchain includes various participants or members that can have different roles defined by a peer-to-peer protocol and / or implemented in smart contracts / chaincodes deployed within the blockchain network. Exemplary participants can include data provider members, data consumer members, content provider members, application platform members, data analytics members, and / or decentralized autonomous organization (DAO) members. DAO members can include the cloud-based groups described above. Details of each data transaction between blockchain members can be recorded in a shared ledger. Immutable, tamper-resistant records can be used to identify and track which datasets were accessed, which sources provided the data, which consumers accessed the data, which application platforms used the data, and in what campaigns / contexts the data was used. These details can be stored without including the data payload from the exchanged datasets, preventing sensitive data from being stored in the shared ledger.

[0067] In some embodiments, the blockchain service creates and maintains accounts for members authorized to participate in the blockchain network. Member accounts can include entitlements for accessing the cryptographically-based, tamper-resistant ledger. As further described herein, members can initiate transaction proposals to read and / or write to the constrained shared ledger, which invokes smart contracts.

[0068] In some embodiments, transactions between members on a blockchain are governed and / or executed by smart contracts, also known as chaincodes. Smart contracts are programs that run within the blockchain and can be invoked to read and write applications to the shared ledger, apply validation logic to allow / reject transactions, and / or trigger application events. For example, a data consumer submits a proposed transaction to access data that matches a specified set of criteria. In response, a set of nodes in the blockchain network can invoke one or more smart contracts to identify datasets that match the specified criteria, verify whether the consumer has met the requirements (predefined or determined at runtime) to access the dataset, and, if approved, commit the transaction record to the ledger. Smart contracts can be associated with peer-to-peer endorsement and validation policies. If the required peers do not endorse or validate the transaction proposal, the transaction can be aborted. Aborted transactions are not committed to the shared ledger.

[0069] FIG. 3 illustrates an exemplary data cloud blockchain system with support for distributed groups, according to some embodiments. As shown in FIG. 3, system 300 includes a data provider node 302a, a data consumer node 302b, a data cloud node 302c, a platform node 302d, a decentralized autonomous organization (DAO) node 302e, a blockchain platform 312, and a smart contract layer 324. In one or more embodiments, system 300 may include more or fewer components than those shown in FIG. 3. The components shown in FIG. 3 may be local or remote from one another. The components shown in FIG. 3 may be implemented in software and / or hardware. Each component may be distributed across multiple applications and / or machines. In some cases, multiple components may be combined into a single application and / or machine. Operations described with respect to one component may instead be performed by another component.

[0070] Data provider node 302a is an operating network entity corresponding to a member of the blockchain that supplies data. Data provider node 302 stores a copy of the shared ledger (ledger copy 304a) and has a client application 306a for interfacing with blockchain services. In some embodiments, client application 306a invokes a set of application programming interfaces (APIs) or software development kits (SDKs) to interact with chaincode and consume events. For example, client application 306a can invoke chaincode to specify what datasets are available for sharing, conditions for accessing the datasets, and constraints on when / where the data can be used.

[0071] Data consumer node 302b also stores a copy of the shared ledger (ledger copy 304b) and includes client application 306b for interfacing with the blockchain service. In some embodiments, the chaincode that can be invoked through client application 306b is tailored to the data consumer role and is different from the chaincode accessible through client application 306a. For example, data consumers and providers may be restricted from initiating different types of transactions within the blockchain. Restrictions may be enforced based on membership credentials, such as public-private key pairs. In other embodiments, a member node may be authorized to act as both a data provider and a data consumer within the blockchain. In this case, the member node may be authorized to initiate transaction proposals for both supplying and consuming data using the same credentials.

[0072] Data cloud node 302c stores a copy of the shared ledger (ledger copy 304c). Data cloud node 302c further provides an analytical service 308 that can perform analytics on datasets that have been consumed and / or are to be consumed. In some embodiments, analytical service 308 can invoke smart contracts that read and / or write performance metrics to the distributed ledger.

[0073] Platform node 302d stores a copy of the shared ledger (ledger copy 304d) and further provides platform services 310. In some embodiments, platform services 310 include campaign delivery platform services. For example, the platform services may include logic for inserting campaign messages into one or more pages of a website. The platform services may format the campaign messages (e.g., via HTML, cascading sheets, etc.) to conform to the look and feel of the webpage. As another example, the platform services may provide applications such as forecasting tools, baselining tools, anomaly detection tools, or other data analysis tools that consume data to provide autonomous analysis outputs. The analysis outputs may trigger one or more autonomous actions and / or be consumed by other applications in the blockchain that may also apply further analysis and / or trigger application-specific actions.

[0074] DAO node 302e stores a copy of the shared ledger (ledger copy 304e) and further provides group services and contracts 311. In some embodiments, group services and contracts 311 provide: Interface for creating DAO nodes, · An organizational template for structuring the DAO, Smart contract templates for defining smart contracts between members of the DAO and / or between the DAO and non-members (e.g., other members of the Data Cloud blockchain network that do not belong to the DAO); Application Programming Interfaces (APIs) and / or smart contracts for voting; Token creation, distribution, and management services; and / or APIs and / or smart contracts for reconciliation and / or other transactions with the Data Cloud Blockchain Network.

[0075] In some embodiments, a blockchain member can belong to one or more blockchain channels. A channel in this context refers to a subnet within a blockchain network with a separate ledger and an authenticated group of blockchain members / nodes. Transactions performed on a particular channel may be restricted to accessing the ledger on that channel, but members belonging to different channels may perform independent transactions on each channel. Thus, while only one ledger is shown per node, a blockchain node may store copies of multiple ledgers (e.g., one for each channel to which the node belongs). Furthermore, the number and type of blockchains can vary depending on the particular implementation.

[0076] The blockchain platform 312 includes a set of nodes and services for managing the distributed ledger. The blockchain platform may generally include a membership service 314, a listing service 315, an ordering service 316, a block 318, a peer node 320, and a state database 322. The blockchain platform 312 may provide a closed ecosystem where only invited entities (e.g., cloud-based groups, content service providers) can join the permissioned blockchain network (and / or its subnets / channels) and maintain a copy of the distributed ledger.

[0077] According to some embodiments, the membership service 314 is configured to manage roles and access policies for members of the blockchain network. For example, the membership service 314 can handle adding, verifying, and canceling memberships within the blockchain network. As another example, the membership service 314 can define access policies for different user roles. For example, the membership service 314 can assign members to different blockchain channels, where each blockchain channel maintains a separate distributed ledger for a corresponding subset of members across the blockchain. Members can be provided with cryptographic keys to access the corresponding ledgers and / or smart contracts deployed to the blockchain channels.

[0078] In some embodiments, the membership service 314 can define and enforce different access policies for founding members and participant members. For example, founding members can determine which participant members can join the blockchain network. When new members are added, digital certificates can be generated to verify the member's identity within the blockchain network. Founding members may consist of a subset of members in the blockchain network, or may be third-party members that do not participate in transactions in the blockchain network.

[0079] In some embodiments, the membership service 314 manages the creation and / or registration of DAOs within the Data Cloud blockchain network. The membership service 314 may provide an interface through which DAOs can request to join the blockchain network, undergo verification / authentication procedures, and / or register as members of the blockchain network. The membership service 314 may define and / or enforce criteria for joining the Data Cloud blockchain network. The membership service 314 may reject registration requests and / or otherwise prevent DAOs that do not meet the set of criteria from participating in the permissioned blockchain network. For DAOs that meet the set of criteria and are properly authenticated, the membership service 314 may establish new nodes within the Data Cloud blockchain to provide them with access to access / update / create distributed ledgers, smart contracts, blockchain transactions, and / or other blockchain services.

[0080] The listing service 315 creates a searchable registry of DAOs that are part of the data cloud blockchain network. As new DAOs join the data blockchain network, the listing service 315 updates the registry with information about the new DAO, such as the DAO name, unique identifier, group description, and / or other group attributes. DAOs that leave the data blockchain network can be removed from the registry.

[0081] The ordering service 316 is a set of one or more nodes that creates new blocks from transactions submitted by members of the blockchain network. The ordering service 316 can include a single ordering process or a cluster of processes. The ordering service 316 can validate proposed transactions and arrange the transactions into blocks.

[0082] Blocks 318 are data objects used to store consensus on facts for the shared ledger. Blocks can be added to the chain when updates occur, such as when a member writes new data (e.g., a record of a transaction between a data consumer and a data provider) to the ledger. Each block in the blockchain contains a cryptographic hash of the previous block that links the blocks together. Blocks can further include a timestamp indicating when the block was created, the current state of the ledger, and / or transaction data that identifies the transaction (e.g., a write operation) that resulted in the current state of the ledger. The cryptographic links between blocks in the blockchain enhance the tamper-resistant properties of the shared ledger. Changing the data in one block may require recalculating the cryptographic hash value of each subsequent block in the chain. A consensus protocol between peer nodes can thwart such tampering.

[0083] Peer nodes 320 are entities operating on the blockchain network that are responsible for maintaining copies of the ledger, executing smart contracts, and committing transactions. Peer nodes 320 can include one or more of data provider nodes 302 a, data consumer nodes 302 b, data cloud nodes 302 c, and platform nodes 302 d. A blockchain member can have one or more peer nodes on the blockchain network.

[0084] In some embodiments, the peer nodes are implemented in one or more digital devices. The term "digital device" generally refers to any hardware device that includes a processor. A digital device may refer to a physical device or a virtual machine that runs an application. Examples of digital devices include computers, tablets, laptops, desktops, netbooks, servers, web servers, network policy servers, proxy servers, general-purpose machines, special-function hardware devices, hardware routers, hardware switches, hardware firewalls, hardware network address translators (NATs), hardware load balancers, mainframes, televisions, content receivers, set-top boxes, printers, mobile handsets, smartphones, personal digital assistants (PDAs), wireless receivers and / or transmitters, base stations, communication managers, routers, switches, controllers, access points, and / or client devices.

[0085] The state database 322 tracks the current state of one or more distributed ledgers. The state database 322 can be used to detect offline peers and update blocks to unsynchronized peers. In some embodiments, the state includes state information about data being exchanged through the blockchain. For example, the state can include, but is not limited to, one or more of the following attributes: Purchased Data: Indicates whether the data has been purchased by another member of the blockchain network; Usage Data: Indicates whether the data has been used by another member of the blockchain network, such as in an online campaign via campaign management software; Campaign Messages Viewed: Indicates whether an online campaign message using data was viewed, clicked on, or otherwise viewed via a client application such as a web browser; Content interaction statistics: capturing impressions and / or other statistics related to interactions between group members with the client application and content served to the client application; Identity used in context: identifies the context in which the data was used; Track consensus state over a period of time, individual user or DAO consensus, which may change over time or fluctuate based on the types of providers and marketers using the data; · Audit Status: Tracks the audit status of the transactions associated with the data. Note that the above attributes can be tracked in a state database and / or distributed ledger without storing the data payload exchanged between different blockchain members, thus creating an immutable, tamper-resistant record of how and when data is used without compromising data privacy.

[0086] The smart contract layer 324 contains blockchain programs that can be invoked by blockchain nodes to read and write application data from and to the ledger, apply validation logic, and / or trigger application events. Chaincode can be installed and / or instantiated on one or more blockchain channels. However, the same chaincode can execute in different channel-specific contexts. For example, the endorsements required to execute a smart contract may vary from blockchain channel to blockchain channel.

[0087] A blockchain can include various smart contracts that define transaction logic for different types of transactions. In some embodiments, a blockchain program defines transaction logic for various types of transactions, including: ·DAO-specific chaincode 326 registered for a particular DAO for executing DAO-specific blockchain transactions within the Data Cloud blockchain network; · a matching chaincode 328 for matching available datasets and / or DAO nodes against the criteria; performance-based chaincode 330 for executing blockchain transactions based on performance metrics associated with the use of a dataset made available by the DAO; · Reconcile chaincode 332 for reconciling transactions within the blockchain.

[0088] Additionally or alternatively, the smart contract layer 324 may include other blockchain programs, including: Option-based chaincode to handle options placed on datasets made available by DAOs or data provider nodes; Deletion chaincode to handle requests to delete sensitive information or opt out of information sharing; impression chaincode for reconciling transactions based on measured impression metrics for the dataset; · state change chaincode for updating and / or otherwise modifying data in the state database 322; Payment chaincode for processing payments for data access within the blockchain; Revenue chaincode for tracking revenue from data usage and initiating revenue-based transactions within the blockchain. Exemplary smart contract functionality is described in further detail in the following sections.

[0089] Further embodiments and / or examples relating to computer networks are described below in Section 11 entitled "Computer Networks and Cloud Networks."

[0090] 6. Ledger Transaction Management As described above, peer nodes can be configured to manage transactions within a blockchain, including reads and writes to a shared ledger. For example, peer nodes can endorse, verify, order, and / or commit transaction records that meet specified policies. Transaction records can be used to limit and track the exchange of data between blockchain members.

[0091] 4 illustrates an exemplary set of operations for managing transaction flow within a blockchain network, according to some embodiments. One or more of the steps may be omitted, repeated, and / or performed in a different order. Thus, the particular arrangement of steps illustrated in FIG. 4 should not be considered limiting the scope of the embodiments.

[0092] The transaction flow includes data consumer node 302b sending a digitally signed transaction proposal request to one or more peer nodes (operation 402). In this example, the data consumer node initiates the request, but depending on the particular implementation, other blockchain members can initiate transactions. Furthermore, the types of transactions that can be initiated in the blockchain can vary depending on the member's role (e.g., consumer-initiated transactions, provider-initiated transactions, platform-initiated transactions, etc.).

[0093] One or more of the peer nodes 320 receive the transaction proposal and verify the digital signature (operation 404). In some embodiments, the digital signature is verified using a public-private key pair. For example, data consumer node 302b may provide a public key to a peer node 320 that is part of the same blockchain channel. Data consumer node 302b may digitally sign the request using its private key, which may be verified by peer node 320 using the provided public key.

[0094] Once verified, one or more peer nodes simulate the requested transaction by executing the requested chaincode (operation 406). In some embodiments, simulating the transaction includes generating a chaincode result (e.g., a read-write set of a distributed ledger). The result is not committed to the ledger at this point.

[0095] One or more peer nodes then digitally sign the chaincode result and return the result to the data consumer node 302b (operation 408). Each peer node may digitally sign the chaincode result using its private key.

[0096] The data consumer node 302b receives results from one or more endorsing peer nodes and determines whether it successfully endorsed the proposed transaction (operation 410). In some embodiments, this operation includes verifying the signature of each endorsing peer, checking to see if the results from different peers match, and verifying that endorsement policy requirements established for the chaincode (or chaincode channel) have been met.

[0097] If the transaction is not successfully endorsed (eg, endorsement policy requirements were not met), the transaction is aborted (operation 412).

[0098] Otherwise, data consumer node 302b submits the endorsed transaction to the ordering service 316 to proceed with committing the proposed transaction (operation 414). In some embodiments, the submitted transaction includes the results (e.g., read-write sets) and signatures from each endorsing peer.

[0099] The ordering service 316 verifies the signatures / endorsements submitted by the data consumer node 302b and arranges the submitted transactions into blocks (operation 416). The manner in which the blocks are ordered may vary from implementation to implementation (e.g., ordering may be based on timestamps, Byzantine fault tolerance, etc.).

[0100] The ordering service then submits the new block to one or more of the peer nodes 320 to commit the transaction (operation 418). The committing peers may be the same or a different set of peer nodes as the endorsing peers.

[0101] The committing peers determine whether the transaction is verified (operation 420). In some embodiments, each committing peer verifies the signature, determines whether the endorsement policy is satisfied, and compares the values of the keys / variables read at the time of endorsement with the current mutation values.

[0102] If the transaction cannot be verified (e.g., invalid signature, endorsement, or change in key value), the transaction is aborted (operation 412).

[0103] Otherwise, the transaction is committed to the distributed ledger (operation 422). The updated ledger can be replicated across all members of the blockchain channel. Note that invalid / aborted transactions can still be written to the ledger, but a commit flag on the transaction can be used to indicate whether the transaction was committed or failed.

[0104] 7. Decentralized group creation and registration on the Data Cloud Blockchain According to some embodiments, decentralized autonomous organizations (DAOs) and / or other cloud-based groups can register and participate in the data blockchain. A DAO provides decentralization in the sense that the group is not limited by the structure or hierarchy of other organizations in the blockchain network, including other DAOs and institutional members. A DAO can be run through a decentralized control structure and voting, which can vary among different DAO nodes. A DAO can control which individuals are eligible to join the DAO, the smart contract / blockchain that governs the DAO, the voting protocol by which changes to the DAO are approved, and / or other parameters that control how the DAO runs and operates within the data cloud blockchain.

[0105] A DAO can be associated with a sidechain, which is a separate blockchain that runs independently of the Data Cloud blockchain. For example, the sidechain can have a separate consensus protocol (including a voting protocol), distributed ledger, and blockchain parameters. The sidechain can connect to the Data Cloud blockchain to transfer digital assets between different blockchain networks. The Data Cloud blockchain can be referred to as the "main" or "parent" blockchain. Transfer mechanisms and protocols, such as a two-way peg, can be used to enable the exchange of assets between the main blockchain network and a sidechain network connected or "pegged" to the Data Cloud blockchain. DAOs that successfully register with the Data Cloud blockchain during the registration process can be pegged to the main blockchain network.

[0106] 5 illustrates an exemplary set of operations for registering a distributed group in a blockchain network, according to some embodiments. One or more of the steps may be omitted, repeated, and / or performed in a different order. Thus, the particular arrangement of steps illustrated in FIG. 5 should not be considered limiting the scope of the embodiments.

[0107] 5, the process includes receiving a request to register a new DAO with the data cloud blockchain network (operation 502). The request may be processed according to a consent protocol established by the main blockchain network. The consent protocol may dictate the rules and conditions under which the registration request is accepted or rejected (registration criteria).

[0108] In response to receiving the request, the process determines whether registration criteria have been met to register the DAO on the blockchain network (operation 504). As described above, the registration criteria may include rules and conditions for registration, which may be defined by a consent protocol associated with the main data cloud blockchain. In some cases, the initiator of the request may be prompted to enter further information to determine whether the registration criteria have been met and / or to authenticate the group. Additionally or alternatively, the addition of a new DAO may require a threshold number of existing members (or a threshold number of members with a particular role, such as institutional members) to vote to approve the new DAO or endorse the DAO prior to registration.

[0109] If the configured registration parameters / criteria are not met, the request may be rejected (operation 506). As a result, the DAO may be prohibited from accessing and connecting / pegging to the main data cloud blockchain network. Subsequent requests may be blocked or ignored.

[0110] If the registration criteria are met, the process receives / extracts information about the DAO for registration (operation 508). The information may include the name of the DAO, a description of the DAO (a description of the group's purpose or membership), statistics about the DAO (e.g., total number of current members, average / median age of the group, average income of the group, geographic scope of the group, etc.), and / or a description of data made available by the group (e.g., what type of data has been made available to the DAO, such as location data, purchasing behavior, preferences, browsing behavior, etc.). Additionally or alternatively, the process may receive smart contract and / or blockchain parameters associated with the DAO, such as chaincode for accessing data from the DAO and chaincode for reconciling transactions with the DAO.

[0111] In some embodiments, the process adds the DAO information to a searchable registry (operation 510). For example, the registry may store the DAO name and / or other unique identifier, a description of the DAO, statistics about DAO members, and / or a description of the types of datasets / smart contracts made available by the DAO. As described further below, the registry may be queried to search for DAO groups, datasets, and / or smart contracts that meet a set of query criteria.

[0112] In some embodiments, the process connects the DAO's sidechain to the main data cloud blockchain (operation 512). The connection mechanism may establish a two-way peg or entangle the sidechain with the main blockchain network. Additionally or alternatively, other connection mechanisms may be implemented to interface the two blockchain networks.

[0113] As noted above, the organization and structure of a DAO can vary. A group of individuals can establish a new DAO and restrict membership in the DAO based on a set of criteria. For example, a DAO may be restricted to individuals who live within a threshold distance of a particular location, who are older or younger than a threshold age, who are graduates of a particular educational institution, who are current members of a particular group or organization, etc. In other cases, a DAO may be open to any interested party. Thus, the criteria for restricting which individuals or entities can join the DAO can vary from group to group.

[0114] Additionally or alternatively, a DAO may vary in other respects, for example, a DAO may specify a cap limiting the total number of members who can join, define different voting protocols (e.g., majority vote, weighted voting based on length of tenure in the group, etc.), and define different smart contracts / blockchains that govern / enforce the rules of the sidechain network.

[0115] In some embodiments, an institution that is a member of a blockchain can establish a new DAO node that can connect to the blockchain. The institution can offer incentives or prompt individuals to join the DAO based on online behavior, attributes, and / or other parameters. For example, the institution can prompt all users who clicked a particular hyperlink, left a positive impression on a social media site, or exhibited other common online behavior to join a particular DAO. The prompt can be displayed via a web page, application page, or other GUI interface. The prompt can include a hyperlink and / or other interface that, when selected, registers the user as a member of the DAO. The prompt can include information about voting rights, incentives (e.g., payment for data sharing / pooling), and / or other data related to the DAO. As another example, the institution can prompt previous, current, and / or future consumers to join an existing DAO (or create a new DAO) and receive tokens or loyalty points through the DAO.

[0116] Users who participate in a DAO can opt out of the DAO at any time. A DAO can also be removed from the Registry / Data Cloud blockchain if they vote (according to the sidechain voting protocol) for the DAO to leave the blockchain network. In other instances, other members of the main blockchain can vote (according to the main blockchain voting protocol) to expel the DAO.

[0117] A DAO can define different roles for members of the DAO and associated sidechains. For example, an escrow account can be responsible for receiving cryptocurrency and / or other tokens from members of the main data cloud blockchain. The cryptocurrency and / or tokens in the escrow account can then be distributed to other members of the DAO based on the DAO smart contract / chaincode / sidechain program. As another example, founding members of a DAO can have more weighted voting power than non-founding members. Additionally or alternatively, DAOs can define other roles that can vary between different DAOs.

[0118] In some embodiments, the Data Cloud Blockchain can provide interfaces, organization templates, smart contract templates, voting API / chaincode templates that facilitate the creation of DAOs on the Data Cloud's blockchain network, and API / chaincode templates for reconciling with the network for payments and incentives. For example, a user can browse different organization templates that can define different possible structures and voting protocols for a DAO. A user can select a template, populate the template with custom information (e.g., DAO name, description, etc.), and / or customize one or more aspects of the template (e.g., voting logic, block parameters, etc.).

[0119] 8. DAO and Data Integrity Blockchain Transactions In some embodiments, the listing service 315 provides a searchable directory of registered / available DAOs. Members of the data cloud blockchain network, such as data provider node 302a, can search the registry to identify DAOs and / or datasets that match a set of search criteria. The listing service allows blockchain members to bid or otherwise enter into smart contracts for datasets made available through decentralized groups. Blockchain members can search for datasets and DAO groups of interest and execute one or more smart contracts with DAO nodes to access the data. DAO groups can vote to accept or reject proposed smart contracts / bids based on a DAO-specific voting protocol. Additionally or alternatively, DAOs can define existing smart contracts that specify the conditions for accessing data made available by DAO nodes. Other blockchain members can analyze and execute existing smart contracts upon identifying DAOs and corresponding datasets of interest.

[0120] 6 illustrates an exemplary set of operations for searching a dataset provided by a distributed group and executing a blockchain transaction, according to some embodiments. One or more of the steps may be omitted, repeated, and / or performed in a different order. Thus, the particular arrangement of steps illustrated in FIG. 6 should not be considered limiting the scope of the embodiments.

[0121] 6, a member of the data cloud blockchain network submits a search query for DAOs that match a set of criteria (operation 602). For example, data provider node 302 may search the registry for DAOs whose average members are within a certain age range, live within a particular geographic location, are alumni of a particular institution, attend a particular sporting event, have a number of members above a threshold, or meet some other set of criteria.

[0122] In response to receiving the query, the process searches a directory of available DAOs for groups and data sets that match the query criteria (operation 604). The process may use keyword matching and / or other algorithms to search the directory / registry data. For example, the process may scan, parse, tokenize, and analyze DAO descriptions, attributes, group statistics, and / or other DAO data for matches.

[0123] In some embodiments, the process presents query results that identify one or more DAOs and / or one or more associated datasets that match the query criteria (operation 606). For example, the query results may include a list of DAOs, which may be ranked ordered based on a strength measure / estimate of the match, or may be based on the number of keyword matches, filters, and / or other ranking criteria. The DAOs may be presented on a web page or other GUI to allow a requesting entity to quickly browse and scroll through the available DAOs. The GUI may further display or allow the user to drill down the results to view additional information about the DAO, such as the type of data made available by the DAO (intent, demographic data, etc.), payment methods / prices for accessing the dataset, the composition of the DAO (e.g., age, demographics, etc.), and the performance of the dataset for similar data consumers (e.g., impressions, click-through rate, cost per thousand people, conversion rate, etc.).

[0124] In some embodiments, the process receives a request to execute one or more smart contracts with one or more of the DAO nodes identified by the search results (operation 608). In some embodiments, the smart contract may be an existing one that defines existing terms and conditions for accessing the DAO dataset. Additionally or alternatively, data consumers may bid on the dataset and propose new smart contracts. The blockchain network (main or side chain) may send a notification to DAO members of the new smart contract. Members may vote to accept or reject the smart contract. The outcome may be determined based on the DAO's voting protocol / rules. Access may then be granted or denied to the requesting node based on the voting outcome.

[0125] The peer node then initiates one or more blockchain transactions based on one or more smart contracts (operation 610). For example, the transaction flow shown in FIG. 2 can be implemented to determine whether the transaction should be committed based on the invoked smart contract and associated endorsement policy. If the transaction fails or cannot be validated, the transaction can be aborted. As described above, a failed transaction is not committed to the blockchain but may still be detailed with a flag indicating failure. If the transaction is successfully endorsed and validated, the peer node commits the transaction to a shared ledger, which is distributed / replicated to members of the blockchain network. The shared ledger can include various details about the exchanged data. For example, the shared ledger can reflect the identities of the DAO and data consumer nodes, conditions associated with accessing / using the dataset (if any), time limits associated with accessing the dataset (if any), and / or other transaction details. As described further below, the distributed ledger can be updated with data usage metrics periodically or in response to certain events that trigger additional blockchain transactions. Transaction details (including performance metrics, if any) belonging to the same block can be hashed, and the hash can be stored in subsequent blocks to provide a cryptographic link between different blocks written to the ledger.

[0126] The smart contract can further trigger the exchange of data between the data provider and the consumer and / or platform node. For example, data can be provided from a DAO node to a campaign delivery platform. The data can include hashed identifiers, such as cryptographic hashes of emails, web cookie identifiers, and / or other information associated with members of the DAO. The campaign delivery platform can then monitor web page accesses of visitors matching the user's hashed identifier through embedded script tags. The use of hashed identifiers allows the data to be anonymized. Data consumer nodes can be prevented from directly accessing the hashed identifiers to protect user data and data privacy. Thus, usage can be restricted to the campaign delivery platform, which can then customize / render web pages in a manner tailored to the identified user.

[0127] Additionally or alternatively, other types of data may be provided to platform nodes, data consumer nodes, and / or other nodes in the blockchain network in response to smart contract execution. For example, anonymized group behavior data, such as what percentage of DAO members have positive impressions of a sports team or what percentage have purchased an electric car in the past three years, may be provided to a node. The information can be consumed by platform nodes and / or applications to tailor online campaigns, generate automated social media posts, train machine learning models, and / or perform other application-specific functions. As another example, the provided data can be used to identify information about DAO visitors accessing a web page to customize the web page in a manner determined to be most likely relevant to the user. Thus, the content, visual elements, and the manner in which the web page is rendered can vary for each user. In yet another example, a machine learning (ML) service can rely on quality training data to train an accurate model. An entity wishing to train a machine learning service may not have access to quality data. The raw data can be obtained through DAOs on the blockchain network and transformed by ML applications for training and evaluating ML models.

[0128] If access is time-sensitive, the ledger can be updated (e.g., a new transaction can be initiated) and access to the dataset can be terminated. In some embodiments, the dataset (e.g., hashed user IDs, etc.) may be provided directly to platform members rather than to data buyers. This can allow the platform to perform functions on the dataset without revealing the dataset to data buyers. In other cases, data buyers can still have access to the data as it existed before access was cut off. Datasets can continuously / cyclically evolve, causing the quality of older datasets to decrease over time.

[0129] Smart contracts can define transaction logic for handling the exchange of data between members of the blockchain, including DAOs. For example, smart contracts can define the conditions / criteria under which data sets are exchanged. DAOs can vote to define and change the conditions for accessing data and the data they make available on the main Data Cloud blockchain. Example conditions can include: The consideration required to access the datasets available through the DAO (e.g., purchase price / transfer, acceptable trade of information, content and data usage rights, etc.); Constraints on how long a dataset can be accessed (e.g., the dataset can be accessed over a specified time window or until a particular date), and Constraints on how the dataset can be used (e.g., the dataset can only be used by certain application / platform nodes in the blockchain).

[0130] 9. Reconcile and Sidechain Smart Contracts In some embodiments, data consumers may provide compensation and / or other forms of consideration to the DAO for use of the dataset. Compensation, such as cryptocurrency, tokens, loyalty points, and / or other digital blockchain assets, may be provided upfront for access to the dataset. Additionally or alternatively, compensation may be conditional and / or may vary based on the performance of the dataset. For example, the amount of compensation may increase with higher performance metrics (e.g., a greater number of click-throughs, positive impressions, etc.). As another example, compensation may be conditional upon the data reaching a certain performance threshold, which may vary depending on the particular application consuming the data.

[0131] In some embodiments, a reconcile transaction involves multiple layers of smart contracts / chaincode. At the top layer, the Data Cloud Blockchain can execute a reconcile transaction defined through one or more associated smart contracts to transfer assets to a DAO node, such as a DAO escrow account. A sidechain associated with a DAO can define one or more smart contracts for reconciling payments to the escrow account with individual members of the DAO. (The individual members of a DAO can be individual people / entities or another DAO. In the latter case, the DAO can be associated with another sidechain that is pegged to the DAO's sidechain with its own smart contract and distributed ledger. Thus, the hierarchy can run multiple levels / layers deep from the parent Data Cloud Blockchain network.)

[0132] The smart contract can implement any logic for reconciling transactions. Furthermore, the logic can vary between the main blockchain network and different DAO sidechain networks. For example, a blockchain program in the main data cloud blockchain can initiate a reconciliation transaction to distribute assets to one or more DAOs based on performance metrics extracted by the analytics service 308 and / or platform service 310. A second smart contract running on the sidechain can then distribute assets (e.g., sidechain tokens, cryptocurrency, loyalty points, etc.) based on the contributions of various members, length of tenure, and / or other attributes specific to the DAO. The decentralized protocol can be voted on and agreed upon by the members of the DAO. In another example, the decentralized protocol can be established by the founding members of the DAO.

[0133] When a peer node is executing a smart contract, it can retrieve performance metrics for the dataset from the distributed ledger. The performance metrics can affect the runtime behavior of the smart contract. For example, a smart contract can execute a transaction on a dataset only if the performance metric exceeds a threshold, or can match against the best-performing dataset in a particular category. In another example, a dataset can be dynamically priced based on the performance metric, i.e., the price required to access the dataset can be adjusted continuously or periodically. The price of the dataset can increase as a function of a higher performance metric or decrease with a decreasing performance metric.

[0134] 7 illustrates an exemplary set of operations for reconciling transactions in a main blockchain and a sidechain associated with a DAO, according to some embodiments. One or more of the steps may be omitted, repeated, and / or performed in a different order. Thus, the particular arrangement of steps illustrated in FIG. 7 should not be considered limiting on the scope of the embodiments.

[0135] Referring to FIG. 7 , the process tracks the use of a dataset provided by the DAO (operation 702). In some embodiments, the analytics service 308 collects performance metrics from websites or applications in which the dataset is used. For example, script tags can be included in the code for loading / rendering campaign messages. The script tags can include macros that resolve to report various performance metrics. Exemplary performance metrics can include, but are not limited to, impression counts (e.g., counts of the number of times a dataset is used to load and render a campaign message on a web page), measurements of how much of the rendered campaign message is in view / visible through a browser / client application (e.g., a percentage value between 0 and 100, click-through rates for hyperlinks included in the campaign message, likes / positive interactions with the campaign message, an overall effectiveness score for the campaign message, a cost measure, a data accuracy measure, etc.). The performance metrics can be written by a blockchain program to a distributed ledger on the main cloud blockchain. As such, the performance metrics become part of a block, the contents of which are linked to one or more other blocks in the ledger by a cryptographic hash function.

[0136] In some embodiments, the process initiates a reconcile transaction in the main data cloud blockchain to transfer one or more assets to the DAO based on the data set usage (operation 704). Details of the transaction can be written to a distributed ledger on the main data cloud blockchain. As described above, the reconcile transaction can further determine how much to transfer to the DAO escrow account based on performance metrics.

[0137] The process further initiates a second reconcile transaction within the sidechain associated with the DAO to split (or otherwise distribute) assets among members of the sidechain and the associated DAO (operation 706). The distributed assets can be the same type of asset or different types of assets. For example, cryptocurrency tokens can be transferred to an escrow account in the DAO. The second reconcile transaction can then split and distribute the cryptocurrency tokens or distribute other types of tokens or assets (e.g., loyalty points, etc.).

[0138] 10. Computer Networks and Cloud Networks In some embodiments, a computer network provides connectivity between a set of nodes. These nodes may be local and / or remote from one another. The nodes are connected by a set of links. Examples of links include coaxial cable, unshielded twisted cable, copper cable, optical fiber, and virtual links.

[0139] A subset of nodes implements computer networks. Examples of such nodes include switches, routers, firewalls, and network address translators (NATs). Another subset of nodes uses computer networks. Such nodes (also called "hosts") can run client processes and / or server processes. A client process makes a request for a computing service (such as running a particular application and / or storing a particular amount of data). A server process responds by performing the requested service and / or returning corresponding data.

[0140] A computer network may be a physical network including physical nodes connected by physical links. A physical node is any digital device. A physical node may be a hardware device with a specific function, such as a hardware switch, a hardware router, a hardware firewall, and a hardware NAT. Additionally or alternatively, a physical node may be a general-purpose machine configured to run various virtual machines and / or applications that perform their respective functions. A physical link is a physical medium connecting two or more physical nodes. Examples of links include coaxial cable, unshielded twisted cable, copper cable, and optical fiber.

[0141] A computer network may be an overlay network. An overlay network is a logical network implemented on top of another network (e.g., a physical network). Each node in the overlay network corresponds to a respective node in the underlying network. Thus, each node in the overlay network is associated with both an overlay address (for addressing the overlay node) and an underlay address (for addressing the underlay node that implements the overlay node). An overlay node may be a digital device and / or a software process (e.g., a virtual machine, an application instance, or a thread). Links connecting overlay nodes are implemented as tunnels through the underlying network. Overlay nodes at both ends of the tunnel treat the underlying multi-hop path between the overlay nodes as a single logical link. Tunneling is performed through encapsulation and decapsulation.

[0142] In some embodiments, a client may be local and / or remote to a computer network. A client may access a computer network through a private network or another computer network, such as the Internet. A client may communicate a request to the computer network using a communication protocol, such as the Hypertext Transfer Protocol (HTTP). The request is communicated through an interface, such as a client interface (e.g., a web browser), a program interface, or an application programming interface (API).

[0143] In some embodiments, a computer network provides connectivity between clients and network resources. The network resources include hardware and / or software configured to run server processes. Examples of network resources include processors, data storage devices, virtual machines, containers, and / or software applications. The network resources are shared among multiple clients. The clients request computing services from the computer network independently of each other. The network resources are dynamically allocated to requests and / or clients on an on-demand basis. The network resources allocated to each request and / or client may be scaled up or down based on, for example, (a) the computing services requested by a particular client, (b) the aggregated computing services requested by a particular tenant, and / or (c) the aggregated computing services requested from the computer network. Such a computer network may also be referred to as a "cloud network."

[0144] In some embodiments, a service provider offers a cloud network to one or more end users. Various service models can be implemented by the cloud network, including, but not limited to, Software-as-a-Service (SaaS), Platform-as-a-Service (PaaS), and Infrastructure-as-a-Service (IaaS). In SaaS, the service provider offers end users the ability to use the service provider's applications running on the network resources. In PaaS, the service provider offers end users the ability to deploy custom applications on the network resources. The custom applications can be created using programming languages, libraries, services, and tools supported by the service provider. In IaaS, the service provider offers end users the ability to provision the processing, storage, network, and other basic computing resources provided by the network resources. Any application, including an operating system, can be deployed on the network resources.

[0145] In some embodiments, a computer network can implement various deployment models, including, but not limited to, private clouds, public clouds, and hybrid clouds. In a private cloud, network resources are provisioned for exclusive use by a specific group of one or more entities (the term "entity" as used herein refers to a business, organization, person, or other entity). The network resources may be local and / or remote to the premises of the specific group of entities. In a public cloud, cloud resources are provisioned for multiple entities (also referred to as "tenants" or "customers") that are independent of one another. The computer network and its network resources are accessed by clients corresponding to different tenants. Such a computer network may be referred to as a "multi-tenant computer network." Several tenants may use the same specific network resources at different times and / or at the same time. The network resources may be local and / or remote to the tenant's premises. In a hybrid cloud, the computer network includes a private cloud and a public cloud. An interface between the private cloud and the public cloud enables data and application portability. Data stored in the private cloud and data stored in the public cloud may be exchanged through the interface. Applications implemented in a private cloud and applications implemented in a public cloud may have dependencies on each other, and calls from applications in a private cloud to applications in a public cloud (and vice versa) may be made through an interface.

[0146] In some embodiments, tenants of a multi-tenant computer network are independent of one another. For example, the business or operations of one tenant may be separate from the business or operations of another tenant. Different tenants may require different network requirements from the computer network. Examples of network requirements include processing speed, data storage, security requirements, performance requirements, throughput requirements, latency requirements, resilience requirements, quality of service (QoS) requirements, tenant isolation, and / or consistency. The same computer network may be required to implement the different network requirements required by different tenants.

[0147] In some embodiments, tenant isolation is implemented in a multi-tenant computer network to ensure that applications and / or data of different tenants are not shared with each other. Various tenant isolation approaches may be used.

[0148] In some embodiments, each tenant is associated with a tenant ID. Each network resource in a multi-tenant computer network is tagged with a tenant ID. A tenant is granted access to a particular network resource only if the tenant and the particular network resource are associated with the same tenant ID.

[0149] In some embodiments, each tenant is associated with a tenant ID. Each application implemented by the computer network is tagged with a tenant ID. Additionally or alternatively, each data structure and / or dataset stored by the computer network is tagged with a tenant ID. A tenant is granted access to a particular application, data structure, and / or dataset only if the tenant and the particular application, data structure, and / or dataset are associated with the same tenant ID.

[0150] As one example, each database implemented by a multi-tenant computer network may be tagged with a tenant ID. Only the tenant associated with the corresponding tenant ID may access the data in a particular database. As another example, each entry in a database implemented by a multi-tenant computer network may be tagged with a tenant ID. Only the tenant associated with the corresponding tenant ID may access the data in a particular entry. However, a database may be shared by multiple tenants.

[0151] In some embodiments, the subscription list indicates which tenants have authorization to access which applications. For each application, a list of tenant IDs of tenants authorized to access the application is stored. A tenant is granted access to a particular application only if the tenant ID of the tenant is included in the subscription list corresponding to the particular application.

[0152] In some embodiments, network resources (such as digital devices, virtual machines, application instances, and threads) corresponding to different tenants are separated into tenant-specific overlay networks maintained by a multi-tenant computer network. As an example, packets from any source device in a tenant overlay network can be sent only to other devices within the same tenant overlay network. To prohibit any transmission from a source device on a tenant overlay network to a device in another tenant overlay network, an encapsulation tunnel is used. Specifically, a packet received from a source device is encapsulated within an outer packet. The outer packet is sent from a first encapsulation tunnel endpoint (communicating with the source device in the tenant overlay network) to a second encapsulation tunnel endpoint (communicating with a destination device in the tenant overlay network). The second encapsulation tunnel endpoint decapsulates the outer packet to obtain the original packet sent by the source device. The original packet is sent from the second encapsulation tunnel endpoint to a destination device in the same particular overlay network.

[0153] 11. Hardware Overview According to one embodiment, the techniques described herein are implemented by one or more special-purpose computing devices. These special-purpose computing devices may be hardwired to execute these techniques, or may include digital electronic devices such as one or more application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or network processing units (NPUs) permanently programmed to execute these techniques, or may include one or more general-purpose hardware processors programmed to execute these techniques according to program instructions in firmware, memory, other storage, or a combination thereof. Such special-purpose computing devices may also combine custom hardwired logic, ASICs, FPGAs, or NPUs with custom programming to perform these techniques. The special-purpose computing devices may be desktop computer systems, portable computer systems, handheld devices, networking devices, or any other devices incorporating hardwired logic and / or program logic to implement these techniques.

[0154] 8 is a block diagram illustrating a computer system 800 upon which some embodiments may be implemented. Computer system 800 includes a bus 802 or other communication mechanism for communicating information, and a hardware processor 804 coupled with bus 802 for processing information. Hardware processor 804 may be, for example, a general-purpose microprocessor.

[0155] Computer system 800 also includes a main memory 806, such as a random access memory (RAM) or other dynamic storage device, coupled to bus 802 for storing information and instructions executed by processor 804. Main memory 806 may also be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor 804. Such instructions, when stored on a non-transitory storage medium accessible to processor 804, render computer system 800 a special-purpose machine customized to perform the operations specified in the instructions.

[0156] Computer system 800 further includes a read only memory (ROM) 808 or other static storage device coupled to bus 802 for storing static information and instructions for processor 804. A storage device 810, such as a magnetic disk or optical disk, is provided and coupled to bus 802 for storing information and instructions.

[0157] Computer system 800 may be coupled via bus 802 to a display 812, such as a cathode ray tube (CRT) or light emitting diode (LED), for displaying information to a computer user. An input device 814, including alphanumeric and other keys, is coupled to bus 802 for communicating information and command selections to processor 804. Another type of user input device is a cursor control 816, such as a mouse, trackball, touch screen, or cursor direction keys, for communicating directional information and command selections to processor 804 and for controlling cursor movement on display 812. Input device 814 typically has two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), which allows the device to specify a position in a plane.

[0158] Computer system 800 may implement the techniques described herein using customized hardwired logic, one or more ASICs or FPGAs, firmware, and / or program logic that combine with the computer system to make or program computer system 800 to be a special-purpose machine. According to one embodiment, the techniques described herein are performed by computer system 800 in response to processor 804 executing one or more sequences of one or more instructions contained in main memory 806. Such instructions may be read into main memory 806 from another storage medium, such as storage device 810. Execution of the sequences of instructions contained in main memory 806 causes processor 804 to perform the process steps described herein. In alternative embodiments, hardwired circuitry may be used in place of or in combination with software instructions.

[0159] The term "storage medium," as used herein, refers to any non-transitory medium that stores data and / or instructions that cause a machine to operate in a specific manner. Such storage media can include non-volatile media and / or volatile media. Non-volatile media include, for example, optical or magnetic disks, such as storage device 810. Volatile media include dynamic memory, such as main memory 806. Common forms of storage media include, for example, floppy disks, flexible disks, hard disks, solid-state drives, magnetic tape, or any other magnetic data storage medium, CD-ROMs, any other optical data storage medium, any physical medium with a pattern of holes, RAM, PROM, EPROM, FLASH-EPROM, NVRAM, any other memory chip or cartridge, content-addressable memory (CAM), and ternary content-addressable memory (TCAM).

[0160] Storage media are distinct from but may be used in conjunction with transmission media. Transmission media involves transferring information between storage media. For example, transmission media include coaxial cables, copper wire and fiber optics, including the wires that comprise bus 802. Transmission media can also take the form of acoustic or light waves, such as those generated during radio wave and infrared data communications.

[0161] Various forms of media may be involved in carrying one or more sequences of one or more instructions to processor 804 for execution. For example, the instructions may initially be carried on a magnetic disk or solid state drive of a remote computer. The remote computer may load the instructions into its dynamic memory and transmit the instructions using a modem over a network line, such as a telephone line, fiber optic cable, or coaxial cable. A modem local to computer system 800 can receive the data on the network line and use an infrared transmitter to convert the data to an infrared signal. An infrared detector can receive the data carried in the infrared signal and appropriate circuitry can place the data on bus 802. Bus 802 carries the data to main memory 806, from which processor 804 retrieves and executes the instructions. The instructions received by main memory 806 may optionally be stored on storage device 810 either before or after execution by processor 804.

[0162] Computer system 800 also includes a communication interface 818 coupled to bus 802. The communication interface 818 provides a two-way data communication coupling to a network link 820 that is connected to a local network 822. For example, communication interface 818 may be an Integrated Services Digital Network (ISDN) card, cable modem, satellite modem, or modem to provide a data communication connection to a corresponding type of telephone line. As another example, communication interface 818 may be a local area network (LAN) card to provide a data communication connection to a compatible LAN. A wireless link may also be implemented. In any such implementation, communication interface 818 sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of information.

[0163] Network link 820 typically provides data communication through one or more networks to other data devices. For example, network link 820 may provide a connection through local network 822 to a host computer 824 or to data equipment operated by an Internet Service Provider (ISP) 826. ISP 826 in turn provides data communication services through the worldwide packet data communication network now commonly referred to as the "Internet" 828. Local network 822 and Internet 828 both use electrical, electromagnetic or optical signals that carry digital data streams. The signals through the various networks and the signals on network link 820 and through communication interface 818, which carry the digital data to and from computer system 800, are exemplary forms of transmission media.

[0164] Computer system 800 can send messages and receive data, including program code, through the network(s), network link 820 and communication interface 818. In the Internet example, a server 830 might transmit a requested code for an application program through Internet 828, ISP 826, local network 822 and communication interface 818.

[0165] The received code may be executed by processor 804 as it is received, and / or stored in storage device 810, or other non-volatile storage for later execution.

[0166] 12. Miscellaneous; Extensions Embodiments are directed to systems that include one or more devices that include a hardware processor and are configured to perform any of the operations described herein and / or recited in any of the appended claims.

[0167] In some embodiments, a non-transitory computer-readable storage medium comprises instructions that, when executed by one or more hardware processors, cause any of the operations described herein and / or recited in any of the claims.

[0168] Any combination of the features and functions described herein may be used in accordance with one or more embodiments. In the foregoing specification, embodiments have been described with reference to numerous specific details that may vary from implementation to implementation. Accordingly, the specification and accompanying drawings should be considered in an illustrative rather than a restrictive sense. The sole and exclusive indication of the scope of the present invention and what the applicants intend to be the scope of the present invention is the literal and equivalent scope of the set of claims issuing from this application, in the specific form derived from such claims, including any subsequent amendments.

Claims

1. receiving a request from an entity to track interactions between members of the cloud-based group and online content; the entity is not part of the cloud-based group; at least one server determining whether the request is accepted by the cloud-based group based at least in part on a selection to accept or reject the request on behalf of members of the cloud-based group, the selection not revealing individual identities of the members of the cloud-based group to the at least one server; in response to determining that the request has been accepted, monitoring online content interactions on one or more sites for interactions between members of the cloud-based group and the online content, wherein individual identities of members of the cloud-based group are not revealed to the at least one server prior to interactions between the members of the cloud-based group and the online content; updating a set of data based at least in part on detected interactions between members of the cloud-based group and the online content; the set of data identifying one or more attributes of the detected interactions between members of the cloud-based group and the online content; The method, wherein the entity does not have access to private group communications of the cloud-based group, and the set of data does not provide the entity with access to the private group communications before or after the request is accepted.

2. The method of claim 1 , wherein the selection is based on votes of at least a subset of the members of the group, and the set of data does not identify how individual members voted in the vote.

3. 3. The method of claim 1 or 2, wherein the request includes a digitized proposed agreement specifying compensation for tracking interactions between the cloud-based group and the online content, the method further including advertising the digitized proposed agreement to one or more groups that meet a set of criteria.

4. The method of claim 3 , wherein the digitized proposed agreement specifies a proposed compensation for tracking the interaction between the cloud-based group and the online content.

5. 4. The method of claim 3, wherein the digitized agreement is a smart contract implemented and executed within a blockchain network.

6. 3. The method of claim 1 or 2, further comprising providing access to an anonymized group identifier in response to receiving the request, the anonymized group identifier being used to monitor and detect interactions with the online content.

7. The method of claim 1 or 2, further comprising performing one or more reconcile operations based on the set of data.

8. 8. The method of claim 7, wherein the reconcile operation includes initiating a first transaction to compensate the cloud-based group, and in response to the first transaction, the cloud-based group executes one or more additional transactions to compensate individual members of the group based at least in part on policies agreed upon by members of the cloud-based group.

9. A program storing instructions that, when executed by one or more processors, receiving a request from an entity to track interactions between members of the cloud-based group and online content; the entity is not part of the cloud-based group; causing at least one server to determine whether the request is accepted by the cloud-based group based at least in part on a selection to accept or reject the request on behalf of members of the cloud-based group, the selection not revealing individual identities of the members of the cloud-based group to the at least one server; in response to determining that the request is accepted, monitoring online content interactions on one or more sites for interactions between members of the cloud-based group and the online content, wherein individual identities of members of the cloud-based group are not revealed to the at least one server prior to interactions between the members of the cloud-based group and the online content; updating a set of data based at least in part on detected interactions between members of the cloud-based group and the online content; the set of data identifying one or more attributes of the detected interactions between members of the cloud-based group and the online content; The entity does not have access to private group communications of the cloud-based group, and the set of data does not provide the entity with access to the private group communications before or after the request is accepted.

10. 10. The program of claim 9, wherein the selection is based on votes of at least a subset of the members of the group, and the set of data does not identify how individual members voted in the vote.

11. 11. The program of claim 9 or 10, wherein the request includes a digitized proposed agreement specifying compensation for tracking interactions between the cloud-based group and the online content, and the instructions further include advertising the digitized proposed agreement to one or more groups that meet a set of criteria.

12. The program of claim 11 , wherein the digitized proposed agreement specifies a proposed compensation for tracking the interaction between the cloud-based group and the online content.

13. 12. The program of claim 11, wherein the digitized agreement is a smart contract implemented and executed within a blockchain network.

14. 11. The program of claim 9 or 10, further comprising providing access to an anonymized group identifier in response to receiving the request, the anonymized group identifier being used to monitor and detect interactions with the online content.

15. The program of claim 9 or 10, further comprising performing one or more reconcile operations based on the set of data.

16. 16. The program of claim 15, wherein the reconcile operation includes initiating a first transaction to compensate the cloud-based group, and in response to the first transaction, the cloud-based group executes one or more additional transactions to compensate individual members of the group based at least in part on policies agreed upon by members of the cloud-based group.

17. registering the plurality of groups in a directory service accessible by members of the blockchain network; advertising the smart contract to at least a subset of one or more of the plurality of groups registered in the directory service; determining whether a group connected to the blockchain network has approved the smart contract; the smart contract grants members of the blockchain network access to anonymized group data; the member of the blockchain network is not part of the group; responsive to determining that the group has approved the smart contract, executing one or more blockchain transactions including at least a first blockchain transaction that updates at least one block of a distributed ledger in the blockchain network based at least in part on the anonymized group data and access to the smart contract.

18. 20. The method of claim 17, wherein determining whether the group connected to the blockchain network has approved the smart contract comprises determining a result of a vote of a set of blockchain users included in the group.

19. 19. The method of claim 17 or 18, wherein the group is a decentralized autonomous organization (DAO) associated with a sidechain network that runs independently from the blockchain network.

20. 20. The method of claim 19, wherein the member is not granted access to the sidechain network.

21. One or more non-transitory machine-readable programs storing instructions that, when executed by one or more processors, registering the plurality of groups in a directory service accessible by members of the blockchain network; advertising the smart contract to at least a subset of one or more of the plurality of groups registered in the directory service; the blockchain network determining whether a group connected to the blockchain network has approved the smart contract; the smart contract grants members of the blockchain network access to anonymized group data; the member of the blockchain network is not part of the group; responsive to determining that the group has approved the smart contract, executing one or more blockchain transactions including at least a first blockchain transaction that updates at least one block of a distributed ledger in the blockchain network based at least in part on the anonymized group data and access to the smart contract.

22. 22. The program of claim 21, wherein determining whether the group connected to the blockchain network has approved the smart contract comprises determining a result of a vote of a set of blockchain users included in the group.

23. 23. The program of claim 21 or 22, wherein the group is a decentralized autonomous organization (DAO) associated with a sidechain network that runs independently from the blockchain network.

24. 24. The program of claim 23, wherein the member is not granted access to the sidechain network.

Images