Integration of anonymized, member-driven cloud-based groups and content delivery services to collect individual information about content interaction without compromising identity of group members

Abstract

Techniques are described through which a group of individuals and / or other entities may interface with a data cloud blockchain network and / or a cloud-based platform for common sharing of data in a secure, controlled manner. Decentralized groups connected to a data cloud network may be registered and ranked in a searchable directory. An entity interested in accessing data associated with a group may browse a directory, execute a smart contract within a blockchain, and track online content interactions of the group in a manner that does not compromise anonymity of individual group members. Data usage and performance metrics may be tracked over the blockchain network using a data cloud service, and the metrics may be written to a distributed ledger within the blockchain network. Smart contracts and chain codes within the network may initiate blockchain transactions based on performance metrics and / or other aspects associated with accessing information about the group.

Description

[0001] Incorporation by Reference; Disclaimer

[0002] The following applications are hereby incorporated by reference: U.S. Non-Provisional Patent Application No. 18 / 159,013, filed January 24, 2023; U.S. Provisional Patent Application No. 63 / 392,055, filed July 25, 2022. Applicants hereby revoke any disclaimer of claim scope in the parent application(s) or its prosecution history, and suggest that the claims in the application may be broader than any claim in the parent application(s).

[0003] This application is related to application Ser. No. 16 / 835,169, entitled “DISTRIBUTED AND BLOCKCHAIN-BASEDLEDGERS FOR DATA CLOUD SERVICES,” which is hereby incorporated by reference herein. Technical Field

[0004] The present disclosure relates to distributed computing systems and architectures. In particular, the present disclosure relates to the integration of anonymized, member-driven cloud-based groups and content delivery services. Background Art

[0005] A cloud-based data management platform includes networked computing resources for collecting and managing data transactions between multiple entities. Applications and content delivery services can use data from the platform to enhance various data-driven functions. For example, a cloud-based data management platform can also provide or enhance actionable insights for consumer applications by running big data, machine learning, and / or other artificial intelligence (AI) analysis on the data managed by the platform. These insights can be used to perform targeted actions, such as selecting audience segments and rendering content in a more efficient and effective manner.

[0006] Data privacy, data integrity, and system scalability can be concerns among participants in cloud-based data management platforms. Data providers and consumers may not inherently trust other participants within a cloud system. Data breaches and unauthorized use of data collections can expose data providers and data consumers to a variety of risks, including legal liability, exposure of confidential information to unauthorized entities, data corruption, and loss of revenue. In addition, inaccurate or low-quality data can limit or impair the performance of consumer applications, resulting in ineffective or inefficient resource utilization. Large systems may link thousands or more entities, increasing the risk of losing sensitive data.

[0007] The approaches described in this section are approaches that could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, 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. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] The embodiments are illustrated in the figures of the accompanying drawings by way of example and not limitation. It should be noted that reference to "one" or "an" embodiment in the present disclosure is not necessarily the same embodiment, and they mean at least one. In the drawings:

[0009] Figure 1 illustrates an example set of cloud-based groups integrated into a data cloud network according to some embodiments;

[0010] Figure 2 illustrates an example set of operations for providing a content delivery service provider with access to data associated with a group in accordance with some embodiments;

[0011] Figure 3 An example data cloud blockchain system supporting decentralized groups according to some embodiments is illustrated;

[0012] Figure 4 illustrates an example set of operations for managing transaction flow within a blockchain network according to some embodiments;

[0013] Figure 5 illustrates an example set of operations for registering a decentralized group with a blockchain network according to some embodiments;

[0014] Figure 6 illustrates an example set of operations for searching a data set provided by a decentralized group and performing a blockchain transaction in accordance with some embodiments;

[0015] Figure 7 illustrates an example set of operations for reconciling transactions on a main blockchain and a sidechain associated with a DAO, according to some embodiments; and

[0016] Figure 8 A block diagram illustrating a computer system according to some embodiments is shown. DETAILED DESCRIPTION

[0017] In the following description, for the purpose of explanation, many specific details are set forth in order to provide a thorough understanding. One or more embodiments may be implemented without these specific details. Features described in one embodiment may be combined with features described in different embodiments. In some examples, well-known structures and devices are described with reference to block diagram form to avoid unnecessary confusion of the present invention.

[0018] 1. General Overview

[0019] 2. Integration of cloud-based groups and data cloud services

[0020] 3. Member-driven strategies and protocols

[0021] 4. Group Opacity

[0022] 5. Distributed ledgers and permissioned blockchains

[0023] 6. Book transaction management

[0024] 7. Smart contracts for sharing identifiers and other data

[0025] 8. Data Usage and Performance-Based Smart Contracts

[0026] 9. Ledger-based deletion tracking and privacy control

[0027] 10. Smart contracts that automatically modify shared data sets

[0028] 11. Computer Networks and Cloud Networks

[0029] 12. Hardware Overview

[0030] 13. Other Matters; Extension

[0031] 1. General Overview

[0032] Techniques are described for integrating anonymized, member-driven cloud-based groups and content delivery services within a sharing platform. These techniques allow a content delivery service to collect individual information about content interactions associated with a group without compromising the identities of group members. Members of a group can benefit from sharing content interactions and / or other anonymized group information with a content delivery service, either at an individual level or at a group level, without having to worry about sensitive information of individual group members being inadvertently exposed.

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

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

[0035] In some embodiments, the data cloud platform provides services through which external entities can 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 collection of content provided to group members, statistics about how many members in the group interact with the content, information about the group's sentiment toward the content, and / or other information about how the group interacts 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.

[0036] In some embodiments, the data cloud platform includes a search interface through which an entity can identify cloud-based groups to interact with. 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 has been identified, an entity can submit a request to collect group-level information and / or otherwise access group-level data. Group members can vote on whether to accept proposals from external entities and / or set terms for approving interactions. Additionally or alternatively, members can pre-approve the conditions under which external entities can access group-level data. By pre-defining and approving the conditions that external entities must meet to interact with the group, members do not need to vote every time an external entity submits a request to access group data. Requests can be automatically approved or rejected based on whether the pre-approved conditions are met.

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

[0038] In some embodiments, cloud-based groups, content service providers, and / or other entities interface with the data cloud blockchain network to share data in a secure, controlled manner. Cloud-based groups can create smart contracts that control access to data shared by the group, establish conditions for joining the group, enforce group governance models (including voting rights) to regulate changes / actions taken by the group, and / or affect other transactions within the blockchain network. Cloud-based groups connected to the data cloud blockchain network can be registered and listed in a searchable directory. The directory can also include information about registered groups (e.g., group attributes) and / or a high-level description of the data being shared by the group. Advertisers and / or other entities interested in accessing shared data can browse the directory, execute smart contracts within the blockchain to access data shared by one or more registered groups, and collect / use data (e.g., for online activities, social relationship management services, and / or other applications). Data privacy can be maintained by using hash identifiers or other data objects that are only useful in the data cloud blockchain environment. Data cloud services can be used to track data usage and performance metrics on the blockchain network, and metrics can be written to distributed ledgers within the blockchain network. Smart contracts / chaincodes within the network may include reconciliation transactions to compensate the group and / or its individual members based on usage and / or performance metrics associated with shared data. Blockchain tokens and / or cryptocurrencies may be used to compensate the group and / or individual group members. Separate smart contracts may manage blockchain transactions between individual members of a decentralized group and the decentralized group as a unit within the blockchain network.

[0039] One or more embodiments described in the specification and / or recited in the claims may not be included in this general summary.

[0040] 2. Integration of cloud-based groups and data cloud services

[0041] Figure 1 An example set of cloud-based groups integrated into a data cloud network according to some embodiments is illustrated. Figure 1 As shown in FIG. 1 , system 100 includes a cloud-based group 102, a data cloud platform 112, and a content service provider 122. In one or more embodiments, system 100 may include Figure 1 More or fewer components may be used than shown. Figure 1 The components shown in may be local or remote from each other. Figure 1 The components shown in the can be implemented in software and / or hardware. Each component can be distributed on multiple applications and / or machines. In some cases, multiple components can be combined into one application and / or machine. The operation described with respect to one component can be performed by another component instead.

[0042] 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. Example cloud-based groups may include Groups, Group / Server, 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 log in to a private group.

[0043] Once connected to a private group, the cloud service may allow the user to perform operations that are only permitted to verified and authenticated group members. For example, a user may communicate with one or more other members of the group using Voice over Internet Protocol (VoIP), instant messaging, Short Message Service (SMS), and video calls through private chats with other members or the entire group. Additionally or alternatively, the user may perform other operations, including voting and other group governance tasks as further discussed herein. One or more functions may be specific to the cloud platform through which the group is formed.

[0044] In some embodiments, cloud-based groups 102 are associated with governance policies and protocols 104, anonymized group data 106, private member data 108, and cloud APIs 110. Governance policies and protocols 104 define rules and procedures for managing the group, which may include member-driven rules and procedures that enable group members to self-govern. For example, governance policies and protocols 104 may define voting protocols by which members can vote to interact with external parties and / or perform other group-level operations. Members may also vote on whether to interact with other group-based operations, such as admitting new members to the group, sharing group-level data with external entities, and managing blockchain transactions within the blockchain network that are private to the group.

[0045] Anonymized group data 106 includes data identifying the attributes of a cloud-based group, such as group name, group interests, and other shared member attributes. For example, a private group may be dedicated to discussing a specific topic of interest to a member, such as a sports team, a profession, or an activity. Additionally or alternatively, group-level data 106 may include information about the interaction of group members with group-level online content. Examples may include total impressions representing the total count or percentage of members viewed or providing content in a cloud-based group, click-through rates representing the total count or percentage of members who click on content when rendering content in a client application in a cloud-based group, ratings representing the average group rating of content, and sentiments representing whether the entire group's view on content is positive or negative. However, the group-level information defined and collected may vary from implementation to implementation.

[0046] The anonymized group data 106 does not include private member data 108, such as personal identification information of individual members of the group, member social media names, SMS numbers, private group messages, and other content that is limited to group members. Group messages and other content shared by one group member with other members in the group can be protected by an authenticated cloud service. In particular, the cloud service only allows authenticated members of the cloud-based group to view such private data. For example, group messages can be encrypted so that access is limited to group members who hold encryption keys for decrypting private data. Members who log in to a cloud-based account can use a client application to access and use encryption keys to view private communications. Therefore, external entities can be prevented from accessing and viewing private member data 108 because they cannot access encryption keys owned by members of the cloud-based group.

[0047] The cloud API 110 may provide an interface through which the cloud-based group 102 communicates with the data cloud platform 112 and / or the content service provider 122. In some embodiments, the cloud API 110 provides an interface through which group members can register with the data cloud platform 112, receive trade proposals from the content service provider 122, send acceptance or rejection of trade proposals, and / or provide anonymized group data to the data cloud platform 112 and / or the content service provider 122. The cloud API 110 may conform to the architecture of a RESTful API and may operate on HTTP requests that call functions for interacting with the group. However, the API may conform to other architectural styles, depending on the particular implementation.

[0048] The data cloud platform 112 includes services for facilitating digital negotiations and transactions between the cloud-based group 102 and the content service provider 122. In some embodiments, the services include content delivery services 114, tracking and analysis services 116, transaction services 118, and query services 120. The services may correspond to web services or processes running on one or more servers. As previously described, the components of the system 100 (including services) may be combined, omitted, or otherwise varied from implementation to implementation.

[0049] In some embodiments, content delivery service 114 provides target content to client applications (such as web browsers, mobile applications, and set-top boxes). Content delivery service 114 can monitor web traffic on one or more sites and extract information about cloud-based groups to which users of web page visitors or mobile applications belong. For example, a server running a cloud-based service can generate HTTP cookies to verify that a user logs into a cloud-based group (such as a specific social media private channel) and information about cloud-based groups. HTTP cookies can include group identifiers and / or other anonymized group-level data. When a user visits a website or visits a mobile application page, a second server running content delivery service 114 can access HTTP cookies from a client-side application to identify anonymized group information associated with a cloud-based group to which the user belongs. Content delivery service 114 can determine whether anonymized group identifiers match identifiers of audience segments defined for a specific content set. If the group identifiers match, then the second server can transfer content to the client-side application, and the client-side application can render content within the page of the client-side application. If the group identifiers do not match, then the second server can avoid transmitting 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. In addition, resources used to generate and provide content can be used more efficiently and effectively, avoiding wasting resources on users who may not be interested in a particular set of content. Operating on cookie data also allows the web server to deliver content to a web browser or mobile application hundreds or even thousands of times per second with minimal latency.

[0050] Tracking and analysis service 116 can collect / update anonymized group data for cloud-based groups and run analysis on the data. For example, tracking and analysis service 116 can track the number of times that content delivery service 114 provides a specific content item to members of a cloud-based group. Tracking and analysis service 116 can maintain a counter for content items that increments whenever a group identifier extracted from an HTTP cookie matches a cloud-based group and renders content. Additionally or alternatively, tracking and analysis service 116 can track and update other metrics and anonymized group information. As previously described, metrics can include click-through rates, user ratings, sentiment, and / or other information about how users interact with content.

[0051] Tracking and analysis service 116 can apply machine learning, big data analysis and / or other technologies to analyze data and provide insights to optimize content delivery services. For example, tracking and analysis service 116 can analyze the context of web pages and mobile applications to determine whether to provide content in a given context. Even if members of a cloud-based group visit a particular web page or use a mobile application, the contextual intelligence engine can determine that content should not be provided in a given context. For example, a website or mobile application may be associated with a controversial topic, and the service can block the provision of content to protect the brand safety of the content provider. The contextual intelligence engine may include one or more models trained using a machine learning algorithm to learn contextual patterns that allow content to be provided and contextual patterns that do not allow content to be provided. Additionally or alternatively, tracking and analysis service 116 can provide other analyses, such as sentiment analysis, to measure the sentiment of a cloud-based group relative to a particular set of content and an estimated measurement of the effectiveness of an activity relative to different cloud-based groups.

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

[0053] In some embodiments, the transaction service 118 manages digital negotiations 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 may enter into a digital negotiation that allows the content service provider 122 to track content interactions of members of the cloud-based group. The digital negotiation may correspond to a smart contract, as described in further detail below. In other embodiments, the digital negotiation may be an electronically recorded digital contract or negotiation that complies with a negotiation protocol, the format of which may vary depending on the implementation. The transaction service 118 may register and enforce the digital negotiation.

[0054] In some embodiments, when the transaction service 118 receives a new digital negotiation, the transaction service 118 verifies the negotiation (e.g., using digital signatures of the cloud-based group and the content service provider). If successfully verified, the transaction service 118 can manage and enforce the negotiation. For example, if the negotiation allows the content service provider to collect information about 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 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 considerations from the content service provider to the cloud-based group based on the tracked content interactions based on the terms set forth in the digital negotiation. In other embodiments, the negotiation can be enforced by members of the data cloud blockchain, as discussed in further detail below.

[0055] In some embodiments, the query service 120 manages a registry of cloud-based groups and provides a search function to identify groups that a content provider is interested in. The registry can include cloud-based groups that are explicitly requested to be registered with the data cloud platform 112. Additionally or alternatively, the registry can include cloud-based groups found by the data cloud platform 112, such as by crawling the cloud service's website to identify private groups.

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

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

[0058] Interface described herein (comprising search interface 124) can render user interface elements and receive input via user interface elements.The example of interface comprises graphical user interface (GUI), command line interface (CLI), tactile interface and voice command interface.Example user interface element comprises check box, radio button, drop-down list, list box, button, switch button, text field, date and time selector, command line, slider, page and form.For example, search interface 124 can comprise the text box for inputting the text of specified keywords, and these keywords can match with group based on group name and / or other attributes.Additionally or alternatively, search interface 124 can present other user interface elements for specifying query standard and / or filtering group.

[0059] The transaction proposal interface 126 provides an interface through which a content service provider 122 can submit a proposed digital negotiation to a cloud-based group 102. For example, the transaction proposal interface 126 can allow a content service provider 122 to submit a request to collect anonymized group data for a group and specify a consideration for allowing access. The proposed consideration can be a fixed rate, based on the collected performance metrics, and / or subject to other conditions defined within the proposed digital negotiation. If the transaction proposal is accepted, then the transaction service 118, peer nodes within the blockchain network, and / or other system components can enforce the terms and conditions defined in the digital negotiation.

[0060] The content editor 128 provides an interface through which the content service provider 122 can create and / or submit content data 130 to provide services 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 within a client-side application. The content service provider can upload the 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 provide the content to the client-side application using the uploaded content and code if the conditions for providing the content are met (such as if the group identifier within the HTTP cookie matches the group identifier of the cloud-based group selected by the content service provider).

[0061] 3. Member-driven strategies and protocols

[0062] In some embodiments, the digital negotiation is subject to member-driven policies and agreements. If the proposed transaction / digital negotiation satisfies the member-driven policies and agreements, then the proposed negotiation may be accepted and enforced within the system 100. Otherwise, the negotiation may be rejected, in which case the content service provider is blocked from accessing anonymized group data, including tracking content interactions at the group level.

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

[0064] Additionally or alternatively, member-driven policies may define conditions for automatically accepting proposals. For example, member-driven policies may be defined to reject proposals from external entities that are controversial or otherwise inconsistent with group goals. As another example, a member-driven policy may accept a proposal only if the payment for access to anonymized group data exceeds a threshold. The prerequisites for accepting a proposal may be voted on or otherwise set according to group governance policies, rules, or heuristics. Thus, policies and protocols may vary from group to group.

[0065] Member-driven policies and agreements can govern other aspects of the group. For example, policies and agreements can define rules for who can join the group. Entities that do not meet a set of criteria may be prohibited from joining a private group. Additionally or alternatively, members can vote on whether an individual can join the group. As another example, policies and agreements can define how the consideration received by the group is distributed among the group members. The consideration can be evenly distributed, based on individual members' contributions to the group, based on member seniority, or according to other rules / policies set by the group. As can be appreciated from the above examples, member-driven policies and agreements can provide a degree of control and self-governance through which members can influence group-level operations.

[0066] As previously mentioned, an external entity, such as content service provider 122 , may submit a request to interact with cloud-based group 102 . Figure 2 An example set of operations for providing a content delivery service provider with access to data associated with a group according to some embodiments is illustrated. One or more of the steps may be omitted, repeated, and / or performed in a different order. Thus, Figure 2 The specific arrangement of steps shown in should not be construed as limiting the scope of the embodiments.

[0067] 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 digital negotiation offer for tracking content interactions. The negotiation may specify conditions for tracking content interactions, such as a time range during which interactions may be tracked, a website for which content interactions may be tracked, group-level data that may be collected, and / or other terms of service. Additionally or alternatively, the digital negotiation offer may specify a consideration for accessing the data, as previously discussed.

[0068] In some embodiments, the trade proposal is published to one or more cloud-based groups. The content service provider may select cloud-based groups based on individual groups, or may publish the proposal to all groups that meet a set of query criteria. For example, the proposal may be published only to groups with attributes that match the attributes specified in the query. Once published, the group may vote on the proposal according to a voting protocol specific to the group. Based on the group governance model associated with the group, the voting protocol for the same published proposal may be different for different groups. Additionally or alternatively, the group may establish predefined rules, conditions, and / or heuristics for accepting published proposals, as discussed previously.

[0069] The data cloud platform 112 determines whether the request is accepted by the group (operation 204). The cloud-based group can transmit the results of the voting or automatic proposal analysis to the data cloud platform 112. If rejected, the process ends and the content service provider is blocked from collecting or tracking group-level data.

[0070] If the proposal is accepted, the data cloud platform 112 tracks content interactions at the online group level without compromising the anonymity of individual members (operation 206). As part of the negotiation, the cloud-based service provider can provide a group identifier that can be used to track content-level interactions in an anonymized manner. The data cloud platform 112 can 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 interaction to determine whether the identifier matches. If a match is detected, the data cloud platform 112 can update the group data. The data cloud platform 112 can also track the type of interaction, which may affect how the group data is updated. For example, if the user only views the content, the data cloud platform 112 can increment the impression count value. If the user clicks on the content, the data cloud platform 112 can update the click-through rate. Additionally or alternatively, the data cloud platform 112 can update the average group rating and / or sentiment based on how group members react to the content.

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

[0072] 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 interaction map of groups to content service providers. The interaction map can identify how various group attributes affect interaction with content provided by advertisers or other entities. The map can highlight which group attributes are more positively correlated with high-level interactions and / or which attributes are most negatively correlated.

[0073] The data cloud platform 112 can use these insights to use machine learning to train and adjust models that recommend or select group segments for content collections. For example, when a new content collection is created, a feature vector can be generated based on a set of features associated with the content, which can be extracted from the content data and / or metadata. The feature vector can be fed through a model, such as performing a forward pass through a neural network model, to generate an output indicating the predicted effectiveness of the content relative to 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. The content delivery service 114 can configure the server based on the recommended or selected group segments to render content only to members of the selected group segments.

[0074] 4. Group Opacity

[0075] When a proposal is published to and accepted by a cloud-based group, various aspects of the group, including private member data 108, remain opaque to the external entity that published the proposal. For example, even if the negotiation is accepted, individual member names, group names, email addresses, and / or other personally identifiable information (PII) are not provided to external entities. Cookies generated by cloud-based services may contain only an anonymized group identifier so that private data cannot be linked to the group identifier. In other cases, the data cloud platform 112 can be configured to collect only anonymized group identifiers from cookies, or the client-side application can be configured to allow cookies to contain only anonymized group information.

[0076] Although private member data 108 is not transparent to external entities, other members of the same cloud-based group may have access to the data. 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 participate in the group, but may be maintained private behind an authenticated cloud service to prevent non-members from gaining access.

[0077] Other aspects of the cloud-based group may also remain opaque to external entities. For example, the digital negotiation may not provide access to view internal group communications, how individual members vote on proposals, how consideration is 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 so, collecting anonymized group data 106 based on the accepted digital negotiation.

[0078] In other embodiments, identification information of one or more representative group members may be exposed to external entities. Proposals and / or negotiations may be directed to representative group members without compromising the anonymity of other group members or the security of other private group data.

[0079] When tracking content interactions, the system 100 maintains the anonymity of individual group members. However, individual group members may voluntarily disclose private information to external entities in some cases. 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 can guide the user to a website associated with the content service provider. When on the website, such as during an online transaction to purchase an item through the website, the user can voluntarily submit personal identification information to the content service provider. Prior to this, even when tracking the user's online interactions, the user's anonymity can be maintained. In addition, even if the user can voluntarily disclose information, other members of the group remain anonymous because the private member data 108 will not be exposed to external entities.

[0080] In some embodiments, the system 100 includes one or more servers that operate on cookie data provided by a browser and / or other applications executed on a client device. As mentioned above, HTTP cookies can be generated by a server when a user visits a website. Cookies 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 a user's computer may include one or more data blocks that may 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 a cloud-based group may store a cookie including a hashed group identifier on the user's computing device. The server may generate a 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 relative to other groups belonging to the same cloud service. The server may store other group-level information within the cookie, such as interests associated with the cloud-based group (e.g., is the group dedicated to a particular topic, sports team, etc.), group demographic information (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 last post to the group, etc.). Additionally or alternatively, the cookie may store individual information about the user, such as a machine identifier (e.g., the host name 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 websites, etc.).

[0081] When monitoring the web traffic of the site, the server can extract the cookie stored on the visitor's computing device and search the group-level data from the matching group identifier and / or other group-level data. If a match is detected, the server can provide the content to the client-side application so that the content is rendered within the web page or application page visible to the user.

[0082] In some embodiments, the rendered content includes an embedded hyperlink that is selectable by the user. For example, the user can click on the rendered content with a mouse or select the content using a touch screen, which will activate the hyperlink to redirect the user to a new web page or application page. The new page can be rendered in a new tab or window, or can replace the page the user is currently viewing when selected.

[0083] In some embodiments, when the user selects a page, system 100 regards this selection as implicit acceptance to tracking and / or otherwise accessing individual information about the user. When a hyperlink is selected, the client-side application can be redirected to connect to a server controlled by a content service provider. Before selecting the hyperlink, the server is not connected to the client-side application, and any individual information about the user cannot be collected. However, when the user is redirected, the server associated with the activated hyperlink may collect cookie data from the user's computing device. In other cases, the server may prompt the user via the client-side application before storing and / or accessing any cookie data, such as presenting a pop-up window in the browser, to obtain the explicit consent of accessing individual data. If the user rejects this prompt, the server can provide a page without storing or accessing cookie data so.

[0084] If the user agrees to allow the server to access the 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 information can be mapped to a member's pre-existing user profile explicitly or probabilistically. If the information extracted from different cookies can be clearly mapped to the same user, a clear match can be determined. For example, the information may include matching machine IDs, email addresses, IP addresses, etc. In other cases, if a clear match is not detected, a model can be used to estimate the probability. A partial match (e.g., a matching machine ID) may increase the likelihood of a match, but it cannot guarantee that the visitor is the same user corresponding to the profile, because different users may use the same machine, or the machine information may not be available. If there is no pre-existing profile for the user, the server can create a new profile for the user.

[0085] In some embodiments, the server of 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 that the member has performed online. For example, this information can be used to determine the user's most frequently visited sites, online purchasing behavior, and the cloud-based groups to which the user belongs. The server can use this information to perform targeted advertising, messaging, services, and / or user interface element rendering within the client-side application. For example, the site can display the user's previously expressed interest in different cookies in the user profile of the same or probabilistic links stored in the data cloud platform 112 via different sites linked to the same key information but from different cookie managers provided by the platform.

[0086] Additionally or alternatively, the data cloud platform 112 can host a virtualized browser in a virtual machine that makes requests on behalf of the entire cloud-based group through the virtual browser. For example, when a user activates a hyperlink by clicking or otherwise selecting rendered content, an instance of the virtual browser can intercept the redirection and make a request to the associated server. Therefore, the request can be made from a machine provided by the data cloud platform rather than an individual user's machine. Therefore, if the server attempts to access cookie data, it will not be able to access the cookies stored on the user's machine, thereby maintaining the anonymity of individuals and groups. The virtual web browser can then act as an intermediary to provide website content to members of the cloud-based group.

[0087] In the above example, before any interaction with the provided content occurs, individual member data remains opaque to the content service provider. In particular, before the user selects content or otherwise activates a hyperlink, the individual data of the member of the cloud-based group (which may be stored in a cookie) will not be disclosed to the server controlled by the content service provider or accessed by it. In response to interaction, the individual information of the member having activated the hyperlink may become accessible. In other cases, additional protective measures may be taken to protect the anonymity of the member, such as prompting the member whether to allow the server to access the cookie data stored on the user's machine or use a virtual browser executed on a virtual machine, as discussed above. Therefore, even after interacting with the content, the anonymity of the member can also be maintained until receiving explicit consent or the user explicitly submits information, such as by online purchase. If the user does not explicitly agree or submit personal information, the member can continue to browse without revealing any individual data. However, in this scenario, the content service provider can be granted access to anonymized group-level data to maintain the opacity of group membership.

[0088] 5. Integration using distributed ledgers and permissioned blockchains

[0089] The technology described herein can be implemented by one or more blockchain networks. Blockchain services refer to network services, such as platform as a service (PaaS) or other cloud services, for maintaining distributed ledgers based on blockchains. Distributed ledgers can include a collection of blocks linked by cryptographic values ​​that maintain a consensus of facts and a history of ledger updates. Distributed ledgers can be replicated, shared, and / or synchronized between multiple peer nodes within a blockchain network.

[0090] Blockchain allows entities (internal and external) that do not fully trust each other to agree on updates submitted to a shared ledger using a peer-to-peer protocol rather than a centralized third-party system that maintains the system independently. Each member of the blockchain can have a copy of the shared ledger, which includes a record of transactions that have occurred on the platform. The distributed ledger is not owned by a specific entity, and updates to the ledger may be blocked unless they comply with the agreed-upon peer-to-peer protocol. In addition, the cryptographic links between the blocks of the ledger can make the transaction records written to the ledger immutable and tamper-proof.

[0091] In some embodiments, the technology described herein is implemented in a permissioned blockchain. A permissioned blockchain is a blockchain in which membership is limited to a set of allowed participants. Permission may be granted by one or more founding members of the blockchain network, or may be granted according to a governance model. For example, if a group or institution wishes to join a permissioned blockchain, other institutional members may vote, or a board of directors may decide whether to grant permission. As another example, permission for an institution may be limited to those institutions that have been certified by a recognized certification agent. Other governance models may 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 may be limited and the rules within the blockchain network may be updated faster. Permissioned blockchains can further improve overall data quality by preventing entities that may provide inaccurate, false, stolen, or otherwise compromised data from joining. However, one or more embodiments described herein may also be implemented within a public blockchain network.

[0092] In some embodiments, the data cloud blockchain includes various participants or members, which may have different roles defined by the peer-to-peer protocol and / or enforced in the smart contract / chain code deployed within the blockchain network. Example participants may include (one or more) data provider members, (one or more) data consumer members, (one or more) content provider members, (one or more) application platform members, (one or more) data analysis members and / or decentralized autonomous organization (DAO) members. DAO members may include the cloud-based groups described above. The details of each data transaction between blockchain members can be recorded on a shared ledger. Immutable and tamper-proof records can be used to identify and track which data sets have been accessed, which (some) sources provide data, which (some) consumers access data, which application platforms use data, and in which activities / contexts data is used. The above details can be stored without including the data payload from the exchanged data sets to prevent sensitive data from being stored in the shared ledger.

[0093] In some embodiments, the blockchain service generates and maintains accounts for members who have been granted permission to join the blockchain network. Member accounts may include credentials for accessing a cryptographically tamper-proof ledger. Members may initiate transaction proposals that invoke smart contracts to read and / or write to the shared ledger, subject to restrictions as further described herein.

[0094] 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 a blockchain and can be called to read and write application data from / to a shared ledger, apply validation logic to allow / reject transactions, and / or trigger application events. For example, a data consumer can submit a proposed transaction to access data that matches a specified set of criteria. In response, a set of nodes within a blockchain network can call one or more smart contracts to identify data sets that match specified criteria, verify that the consumer has met the requirements for accessing the data set (predefined or determined at runtime), and, if approved, submit the transaction record to the ledger. Smart contracts can be associated with peer-to-peer endorsement and verification policies. If the necessary peers do not endorse or verify the transaction proposal, the transaction can be aborted. Aborted transactions are not submitted to the shared ledger.

[0095] Figure 3 An example data cloud blockchain system supporting decentralized groups according to some embodiments is illustrated. Figure 3 As shown in FIG. 3 , system 300 includes data provider node 302a, data consumer node 302b, data cloud node 302c, platform node 302d, decentralized autonomous organization (DAO) node 302e, blockchain platform 312, and smart contract layer 324. In one or more embodiments, system 300 may include Figure 3 More or fewer components may be used than shown. Figure 3 The components shown in may be local or remote from each other. Figure 3 The components shown in the can be implemented in software and / or hardware. Each component can be distributed on multiple applications and / or machines. In some cases, multiple components can be combined into one application and / or machine. The operation described with respect to one component can be performed by another component instead.

[0096] The data provider node 302a is an operational network entity corresponding to a member of the blockchain that supplies data. The data provider node 302 stores a copy of the shared ledger (ledger copy 304a) and has a client application 306a for interacting with the blockchain service. In some embodiments, the client application 306a calls an application programming interface (API) set and / or a software development kit (SDK) to interact with the chain code and use events. For example, the client application 306a can call the chain code to specify which data sets are available for sharing, the conditions for accessing the data sets, and restrictions on when / where the data can be used.

[0097] The data consumer node 302b also stores a copy of the ledger (ledger copy 304b) and includes a client application 306b for interacting with the blockchain service. In some embodiments, the chain code that can be called by the client application 306b is tailored for the role of the data consumer and is different from the chain code accessible by the client application 306a. For example, data consumers and providers can be restricted to initiating different types of transactions within the blockchain. Restrictions can be enforced based on membership credentials (such as public key-private key pairing). In other embodiments, member nodes can be allowed to act as data providers and data consumers within the blockchain at the same time. In this case, member nodes can be allowed to use the same credentials to initiate transaction proposals, both for supplying data and for consuming data.

[0098] The data cloud node 302c stores a copy of the shared ledger (ledger copy 304c). The data cloud node 302c also provides an analysis service 308, which can run analysis on the data sets that have been consumed and / or are about to be consumed. In some embodiments, the analysis service 308 can call a smart contract to read performance metrics and / or write performance metrics to the distributed ledger.

[0099] The platform node 302d stores a copy of the shared ledger (ledger copy 304d) and further provides platform services 310. In some embodiments, the platform service 310 includes an activity delivery platform service. For example, the platform service may include logic for inserting an activity message within one or more pages of a website. The platform service may format the activity message (e.g., via HTML, cascading style sheets, etc.) to conform to the look and feel of the web page. As another example, the platform service may provide applications such as forecasting tools, baseline tools, anomaly detection tools, or other data analysis tools that consume data to provide automated analysis outputs. The analysis output may trigger one or more automated actions and / or be consumed by other applications within the blockchain, which may also apply further analysis and / or trigger application-specific actions.

[0100] 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:

[0101] An interface for creating DAO nodes;

[0102] An organizational template for building a DAO;

[0103] 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 are not part of the DAO);

[0104] Application programming interfaces (APIs) and / or smart contracts for voting;

[0105] Token creation, distribution and management services; and / or

[0106] API and / or other transaction APIs for reconciliation and / or other transactions with the Data Cloud blockchain network

[0107] Or smart contracts.

[0108] In some embodiments, blockchain members may belong to one or more blockchain channels. In this context, a channel refers to a subnet within a blockchain network, with isolated ledgers and authorized groups of blockchain members / nodes. Transactions performed on a particular channel may be limited to accessing the ledger on that channel, but members belonging to different channels may perform independent transactions on each channel. Thus, while each node depicts only one ledger, a blockchain node may store copies of multiple ledgers (e.g., one ledger for each channel to which the node belongs). Furthermore, the number and type of blockchain nodes may vary depending on the particular implementation.

[0109] The blockchain platform 312 includes a collection of nodes and services for managing a distributed ledger. The blockchain platform may generally include a membership service 314, a list 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 in which only invited entities (e.g., cloud-based groups, content service providers) can join a permissioned blockchain network (and / or its subnets / channels) and retain a copy of the distributed ledger.

[0110] 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 revoking 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 an isolated distributed ledger for a corresponding subset of members of the entire blockchain. Members can be granted cryptographic keys to access corresponding ledgers and / or smart contracts deployed to the blockchain channel.

[0111] 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 a new member is added, a digital certificate can be generated to confirm the identity of the member within the blockchain network. Founding members can consist of a subset of members on the blockchain network, or can be third-party members that do not participate in transactions on the blockchain network.

[0112] 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 a DAO may request to join the blockchain network, undergo a verification / authentication process, and / or register as a member of the blockchain network. The membership service 314 may define and / or enforce standards 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 standard set from joining the licensed blockchain network. For DAOs that meet the standard set and are properly authenticated, the membership service 314 may establish a new node within the data cloud blockchain to grant access to the DAO to access / update / generate distributed ledgers, smart contracts, blockchain transactions, and / or other blockchain services.

[0113] The list service 315 generates a searchable registry of DAOs that are part of the data cloud blockchain network. When a new DAO joins the data blockchain network, the list 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 may be removed from the registry.

[0114] The sorting service 316 is a collection of one or more nodes used to create new blocks based on transactions sent by members of the blockchain network. The sorting service 316 may include a single sorting process or a cluster of processes. The sorting service 316 may verify proposed transactions and sort transactions into blocks.

[0115] Block 318 is a data object used to store a factual consensus of a shared ledger. Blocks can be added to the chain when updates occur, such as when a member writes new data (e.g., a transaction record between a data consumer and a data provider) to the ledger. Each block within the blockchain contains a cryptographic hash of the previous block that links the blocks together. Blocks may also include a timestamp indicating when the block was generated, the current state of the ledger, and / or transaction data identifying 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-proof nature of the shared ledger. Changing the data within one block may require recalculating the cryptographic hash value for each subsequent block in the chain. The consensus protocol between peer nodes can prevent such tampering.

[0116] Peer nodes 320 are operational entities on the blockchain network that are responsible for maintaining copies of the ledger, running smart contracts, and submitting transactions. Peer nodes 320 may include one or more of data provider nodes 302a, data consumer nodes 302b, data cloud nodes 302c, and platform nodes 302d. Blockchain members may have one or more peer nodes on the blockchain network.

[0117] In some embodiments, peer nodes are implemented on one or more digital devices. The term "digital device" generally refers to any hardware device including a processor. A digital device may refer to a physical device that executes an application or a virtual machine. Examples of digital devices include computers, tablet computers, laptop computers, desktop computers, netbooks, servers, web servers, network policy servers, proxy servers, general machines, special function hardware devices, hardware routers, hardware switches, hardware firewalls, hardware firewalls, hardware network address translators (NATs), hardware load balancers, mainframes, televisions, content receivers, set-top boxes, printers, mobile phones, smart phones, personal digital assistants ("PDAs"), wireless receivers and / or transmitters, base stations, communication management equipment, routers, switches, controllers, access points, and / or client devices.

[0118] 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 out-of-sync peers. In some embodiments, the state includes state information about the data exchanged through the blockchain. For example, the state can include, but is not limited to, one or more of the following attributes:

[0119] Purchased data: Indicates whether the data has been purchased by other members of the blockchain network;

[0120] Used data: Indicates whether the data has been used by other members of the blockchain network, such as in online campaigns in campaign management software;

[0121] • Activity Message Seen: Indicates whether an online activity message using data was viewed, clicked on, or otherwise seen via a client application such as a web browser;

[0122] Content interaction statistics: capturing impressions and / or other statistics related to interactions between group members using the client application and content provided to the client application;

[0123] Identity used in x context: identifies the context in which the data is used;

[0124] Consent status over time: Tracking the consent status of individual users or DAOs, which may change over time or vary based on the types of vendors and marketers using the data; and

[0125] Audit Status: Tracks the audit status of transactions associated with the data.

[0126] Note that the above properties can be tracked in a state database and / or distributed ledger without storing the data payloads exchanged between different blockchain members. Thus, an immutable and tamper-proof record of how and when data is used can be created without compromising data privacy.

[0127] The smart contract layer 324 includes blockchain programs that can be called by blockchain nodes to read and write application data from / to the ledger, apply verification logic, and / or trigger application events. Chaincodes can be installed / instantiated on one or more blockchain channels. However, the same chaincode may run in different contexts specific to a channel. For example, the endorsement required to execute a smart contract may vary from one blockchain channel to another.

[0128] The blockchain may include various smart contracts that define transaction logic for different types of transactions. In some embodiments, the blockchain program defines transaction logic for various types of transactions, including:

[0129] A DAO-specific chaincode 326 registered for a specific DAO and used to execute DAO-specific blockchain transactions within the Data Cloud blockchain network;

[0130] Matching chaincode 328, used to match available data sets and / or DAO nodes according to criteria;

[0131] A performance-based chaincode 330 for executing blockchain transactions based on performance metrics associated with usage of a dataset provided by the DAO;

[0132] Reconciliation chaincode 332 is used to reconcile transactions within the blockchain.

[0133] Additionally or alternatively, the smart contract layer 324 may include other blockchain programs, including:

[0134] Option-based chaincodes for handling options placed on datasets provided by DAOs or data provider nodes;

[0135] The delete chaincode is used to handle requests to delete sensitive information or opt out of information sharing;

[0136] Impression chaincode, used to reconcile transactions based on the measured impression metrics of the dataset;

[0137] State change chaincodes, which are used to update and / or otherwise modify data within the state database 322;

[0138] Payment chaincode, which is used to process payments for access to data within the blockchain;

[0139] A revenue chaincode to track revenue from data usage and initiate revenue-based transactions within the blockchain.

[0140] The example smart contract functionality is described in further detail in the following sections.

[0141] Additional embodiments and / or examples related to computer networks are described below in Section 11 entitled “Computer Networks and Cloud Networks”.

[0142] 6. Book transaction management

[0143] As mentioned earlier, peer nodes can be configured to manage transactions within the blockchain, including reading and writing to the shared ledger. For example, peer nodes can endorse, verify, sort, and / or commit transaction records that meet specified policies. Transaction records can be used to restrict and track data exchanges between blockchain members.

[0144] Figure 4 An example set of operations for managing transaction flows within a blockchain network according to some embodiments is illustrated. One or more of the steps may be omitted, repeated, and / or performed in a different order. Thus, Figure 4 The specific arrangement of steps shown in should not be construed as limiting the scope of the embodiments.

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

[0146] 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 key-private key pairing. For example, the data consumer node 302b may provide a public key to a peer node 320 that is part of the same blockchain channel. The data consumer node 302 may digitally sign the request using the private key, which may be verified by the peer node 320 using the provided public key.

[0147] 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 time.

[0148] 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 can digitally sign the chaincode result using a private key.

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

[0150] If the transaction is not successfully endorsed (eg, endorsement policy requirements are not satisfied), then the transaction is aborted (operation 412).

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

[0152] The sorting service 316 verifies the signature / endorsement submitted by the data consumer node 302b and sorts the submitted transactions into blocks (operation 416). The manner in which blocks are sorted may vary from implementation to implementation (e.g., the sorting may be based on timestamps, Byzantine fault tolerance, etc.).

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

[0154] The submitting peer determines whether the transaction is verified (operation 420). In some embodiments, each submitting peer verifies the signature, determines whether the endorsement policy is satisfied, and compares the value of the key / variable read at endorsement time with the current value for modification.

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

[0156] Otherwise, the transaction is submitted to the distributed ledger (operation 422). The updated ledger can be replicated among all members of the blockchain channel. Note that invalid / aborted transactions can still be written to the ledger; however, the transaction's submission flag can be used to indicate that the transaction has been submitted or failed.

[0157] 7. Use Data Cloud Blockchain for decentralized group creation and registration

[0158] According to some embodiments, decentralized autonomous organizations (DAOs) and / or other cloud-based groups can register and join the Data Cloud blockchain. DAOs provide decentralization because groups are not constrained by the structure or hierarchy of other organizations (including other DAOs and institutional members) within the blockchain network. DAOs can operate through decentralized control structures and voting, which may vary from one DAO node to another. The 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 operates and operates within the Data Cloud blockchain.

[0159] A DAO may be associated with a sidechain, which is a separate blockchain that runs independently of the Data Cloud blockchain. For example, a sidechain may have a separate consensus protocol (including a voting protocol), distributed ledger, and blockchain parameters. Sidechains can be connected to the Data Cloud blockchain to transfer digital assets between different blockchain networks. The Data Cloud blockchain may be referred to as a "master" or "parent" blockchain. Transfer mechanisms and protocols (such as two-way hooks) can be used to allow assets to be exchanged between the main blockchain network and the sidechain network that is connected or "hooked" to the Data Cloud blockchain. A DAO that successfully registers to the Data Cloud blockchain during the registration process can be hooked to the main blockchain network during the period.

[0160] Figure 5An example set of operations for registering a decentralized group with a blockchain network according to some embodiments is illustrated. One or more of the steps may be omitted, repeated, and / or performed in a different order. Thus, Figure 5 The specific arrangement of steps shown in should not be construed as limiting the scope of the embodiments.

[0161] refer to Figure 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 consensus protocol established by the main blockchain network. The consensus protocol may specify rules and conditions for accepting or rejecting registration requests (registration criteria).

[0162] In response to receiving the request, the process determines whether registration criteria have been met to register the DAO with the blockchain network (operation 504). As previously described, the registration criteria may include rules and conditions for registration, which may be defined by a consensus protocol associated with the master data cloud blockchain. In some cases, the initiator of the request may be prompted to enter additional information to determine whether the registration criteria and / or verification group are met. Additionally or alternatively, adding 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 before it is registered.

[0163] If the set registration parameters / criteria have not been met, then the request may be denied (operation 506). As a result, the DAO may be prohibited from accessing and connecting / hooking to the main Data Cloud blockchain network. Subsequent requests may be blocked or ignored.

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

[0165] 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 the DAO members, and / or a description of the types of datasets / smart contracts provided 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.

[0166] 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 dock the two blockchain networks.

[0167] As mentioned previously, the organization and structure of a DAO may vary. Groups of individuals may establish new DAOs and restrict membership in the DAO based on a set of criteria. For example, a DAO may be limited to individuals who live within a threshold distance of a particular location, individuals who are older / younger than a threshold age, individuals who are alumni of a particular educational institution, individuals who are current members of a particular group / organization, etc. In other cases, a DAO may be open to any interested party. Therefore, the criteria for limiting which individuals or entities can join the DAO may vary from group to group.

[0168] Additionally or alternatively, the DAO may differ in other ways. For example, the DAO may specify an upper limit on the total number of members that can join, define a different voting protocol (e.g., majority wins, weighted voting based on group seniority, etc.), and define a different smart contract / blockchain that governs / enforces the rules of the sidechain network.

[0169] In some embodiments, an institution that is a member of a blockchain can establish a new DAO node that can be connected to a blockchain. An institution can provide incentives or prompt individuals to join a DAO based on online behavior, attributes, and / or other parameters. For example, an institution can prompt all users who click on a specific hyperlink, leave a positive impression on a social media site, or exhibit other common online behaviors to join a specific DAO. The prompt can be displayed via a web page, application page, or other GUI interface. The prompt may include a hyperlink and / or other interface that, when selected, registers the user as a member of the DAO. The prompt may include information about voting rights, incentives (e.g., payments for data sharing / pooling), and / or other data about the DAO. As another example, an institution may prompt former, current, and / or potential customers to join an existing DAO (or create a new DAO) to receive tokens or loyalty points through the DAO.

[0170] Users who join the DAO can choose to leave the DAO at any time. If the DAO votes to leave the blockchain network (according to the sidechain voting protocol), then the DAO may also be removed from the registry / data cloud blockchain. In other cases, other members of the main blockchain can vote to expel the DAO (according to the main blockchain voting protocol).

[0171] A DAO may define different roles for members of the DAO and associated sidechains. For example, a custodian account may be a role that receives cryptocurrency and / or other tokens from members of the main Data Cloud blockchain. The cryptocurrency and / or tokens in the custodian account may 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 may have higher weighted voting rights than non-founding members. Additionally or alternatively, a DAO may define other roles that may differ between different DAOs.

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

[0173] 8.DAO and Data Matching Blockchain Transactions

[0174] In some embodiments, the list service 315 provides a searchable directory of registered / available DAOs. Members of the data cloud blockchain network (such as data provider nodes 302a) can search the registry to identify DAOs and / or data sets that match the search criteria set. The list service allows blockchain members to bid or otherwise sign smart contracts for data sets provided by decentralized groups. Blockchain members can search for data sets and DAO groups of interest and execute one or more smart contracts with DAO nodes to access data. The DAO group can vote to accept or reject the proposed smart contract / bid based on a voting protocol specific to the DAO. Additionally or alternatively, the DAO can define a pre-existing smart contract that specifies the conditions for accessing the data provided by the DAO node. Other blockchain members can analyze and execute pre-existing smart contracts after identifying the DAO and the corresponding data set of interest.

[0175] Figure 6An example set of operations for searching a data set provided by a decentralized group and performing a blockchain transaction according to some embodiments is illustrated. One or more of the steps may be omitted, repeated, and / or performed in a different order. Thus, Figure 6 The specific arrangement of steps shown in should not be construed as limiting the scope of the embodiments.

[0176] refer to Figure 6 , a member of the data cloud blockchain network submits a query to search for a DAO that matches a set of criteria (operation 602). For example, the data provider node 302 may search the registry for DAOs whose average members are within a certain age range, live in a certain geographic location, are alumni of a certain institution, have participated in certain sporting events, have a number of members exceeding a threshold, or meet other sets of criteria.

[0177] In response to receiving the query, the process searches the 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 matching.

[0178] In some embodiments, the process presents query results that identify one or more DAOs and / or one or more associated data sets that match the query criteria (operation 606). For example, the query results may include a list of DAOs that may be ranked based on a strength metric / estimate of the match, which may be based on the number of keyword matches, filters, and / or other rating criteria. The DAOs may be presented on a web page or other GUI to allow the requesting entity to quickly view and scroll through the available DAOs. The GUI may also display or allow the user to drill down into the results to view more information about the DAO, such as the kind of data provided by the DAO (such as intent, demographics, etc.), the payment method / price for accessing the data set, the composition of the DAO (e.g., age, demographics, etc.), the performance of the data set for similar data consumers (e.g., impressions, click-through rate, cost per thousand, conversion rate, etc.).

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

[0180] The peer node then initiates one or more blockchain transactions based on the one or more smart contracts (operation 610). For example, Figure 2 The transaction flow shown in can be implemented based on the smart contract called and the associated endorsement policy to determine whether the transaction should be submitted. If the transaction fails or cannot be verified, the transaction can be aborted. As previously described, a failed transaction is not submitted to the blockchain, but its details may still be written with a flag indicating that it has failed. If the transaction is successfully endorsed and verified, the peer node submits the transaction to a shared ledger, which is distributed / copied to the members of the blockchain channel. The shared ledger may include various details about the data exchanged. For example, the shared ledger may reflect the identity of the DAO and the data consumer node, the conditions associated with accessing / using the data set (if any), the time limit associated with accessing the data set (if any), and / or other transaction details. As further described below, the distributed ledger may update the data usage metrics periodically or in response to certain events that trigger additional blockchain transactions. Transaction details belonging to the same block (including performance metrics, if any) can be hashed. The hash can be stored in subsequent blocks to provide a cryptographic link between different blocks written to the ledger.

[0181] The smart contract may further trigger data exchange between (one or more) data providers and consumers and / or platform nodes. For example, data may be provided from a DAO node to an activity delivery platform. The data may include hashed identifiers, such as password hashes of emails, web cookie identifiers, and / or other information associated with members of the DAO. The activity delivery platform may then monitor web page visits by visitors that match the user's hashed identifier via embedded script tags. The use of hashed identifiers allows the data to be anonymized. Data consumer nodes may be prevented from directly accessing hashed identifiers to protect the user's data and data privacy. Thus, usage may be limited to the activity delivery platform, which may then customize / render the web page in a manner tailored for the identified user.

[0182] 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 the execution of smart contracts. For example, anonymized group behavior data may be provided to the node, such as how many percentage of DAO members have a positive impression of sports teams, how many percentages have purchased electric cars in the past three years, and so on. The platform node and / or application may use this information to tailor online activities, generate automated social media posts, train machine learning models, and / or perform other application-specific functions. As another example, the data provided may be used to identify information about DAO visitors who are accessing a web page, thereby customizing the web page in a manner that is determined to be most likely to be relevant to the user. Therefore, the content, visual elements, and the way to render the web page may vary from user to user. In yet another example, a machine learning (ML) service may rely on quality training data to train an accurate model. An entity that wishes to train a machine learning service may not have access to quality data. The raw data may be obtained by the DAO on the blockchain network and may be transformed by the ML application for training and evaluating the ML model.

[0183] If access is time-constrained, then the ledger may be updated (e.g., a new transaction may be initiated) and access to the dataset may be terminated. In some embodiments, the dataset (e.g., hashed user ids, etc.) may be provided directly to platform members rather than data buyers. This may allow the platform to perform functions on the dataset without revealing the dataset to the data buyer. In other cases, the data buyer may still have access to the data that existed before access was cut off. The dataset may evolve continuously / periodically, which may degrade the quality of the old dataset over time.

[0184] Smart contracts can define transaction logic for handling data exchange between blockchain members (including DAOs). For example, a smart contract can define conditions / criteria for exchanging data sets. DAOs can vote to define and change the conditions for access to data and the data provided on the main data cloud blockchain. Example conditions can include:

[0185] The consideration required to access the dataset obtained through the DAO (e.g., purchase price

[0186] / remittance, acceptable information transactions, consent and data use rights, etc.);

[0187] Restrictions on how long a dataset can be accessed (e.g., a dataset can be accessed within a specified time window or until a certain date); and

[0188] Restrictions on how the dataset can be used (e.g., the dataset can only be used on certain applications / platform nodes in the blockchain).

[0189] 9. Reconciliation and Sidechain Smart Contracts

[0190] In some embodiments, data consumers may provide compensation and / or other forms of consideration to the DAO for use of a data set. Consideration, such as cryptocurrency, tokens, loyalty points, and / or other digital blockchain assets, may be provided in advance for access to a data set. Additionally or alternatively, the consideration may be contingent and / or vary based on the performance of the data set. For example, the amount of the consideration may increase as a performance metric improves (e.g., higher number of clicks, positive impressions, etc.). As another example, the consideration may depend on whether the data meets certain performance thresholds, which may vary depending on the specific application consuming the data.

[0191] In some embodiments, the reconciliation transaction includes multiple layers of smart contracts / chaincodes. At the top level, the Data Cloud blockchain can execute a reconciliation transaction as defined by one or more associated smart contracts to transfer assets to a DAO node, such as a DAO escrow account. The sidechain associated with the DAO can define one or more smart contracts to reconcile payments to escrow accounts with individual members of the DAO. (Individual members of the DAO can be individual persons / entities or another DAO. In the latter case, the DAO can be associated with another sidechain that is linked to the DAO's sidechain through its own smart contracts and distributed ledgers. Therefore, the hierarchy can run multiple levels / layers deep from the parent Data Cloud blockchain network).

[0192] Smart contracts can implement arbitrary logic to reconcile transactions. In addition, the logic may be different between the main blockchain network and different DAO sidechain networks. For example, a blockchain program on the main data cloud blockchain can initiate a reconciliation transaction to distribute assets to one or more DAOs based on performance metrics extracted by analysis services 308 and / or platform services 310. Then, a second smart contract executed in the sidechain can distribute assets (e.g., sidechain tokens, cryptocurrencies, loyalty points, etc.) based on the contributions, seniority, and / or other attributes unique to the DAO of each member. The distribution agreement can be voted on and agreed upon by the members of the DAO. In other cases, the distribution agreement can be established by the founding members of the DAO.

[0193] When a peer node is running a smart contract, the peer node can read the performance metrics of a dataset from the distributed ledger. The performance metrics may affect the runtime behavior of the smart contract. For example, a smart contract may execute a transaction on a dataset only if the performance metric is above a threshold or may match the highest performing dataset in a particular category. As another example, a dataset may be dynamically priced based on its performance metric - the consideration required to access the dataset may be adjusted continuously or periodically. The price of a dataset may increase as the performance metric improves, or decrease as the performance metric decreases.

[0194] Figure 7 An example set of operations for reconciling transactions on a main blockchain and a sidechain associated with a DAO according to some embodiments is illustrated. One or more of the steps may be omitted, repeated, and / or performed in a different order. Thus, Figure 7 The specific arrangement of steps shown in should not be construed as limiting the scope of the embodiments.

[0195] refer to Figure 7 , which tracks the usage of the data set provided by the DAO (operation 702). In some embodiments, the analysis service 308 collects performance metrics from websites or applications that use the data set. For example, a script tag may be included in the code used to load / render the activity message. The script tag may contain macros that are parsed to report various performance metrics. Example performance metrics may include, but are not limited to, impression counts (e.g., counts of the number of times the data set is used to load and render the activity message on a web page), measurements of how many rendered activity messages are seen / visible through a browser / client application (e.g., a percentage value between 0-100, click-through rates of hyperlinks contained in activity messages, likes / active interactions with activity messages, overall effectiveness scores of activity messages, cost metrics, measurements of data accuracy, etc. The performance metrics may be written by the blockchain program to a distributed ledger on the main data cloud blockchain. Thus, the performance metrics may become part of a block, the contents of which are linked to one or more other blocks in the ledger via a cryptographic hash function.

[0196] In some embodiments, the process initiates a reconciliation transaction within the master data cloud blockchain to transfer one or more assets to the DAO node based on the usage of the data set (operation 704). The transaction details can be written to a distributed ledger on the master data cloud blockchain. As previously described, the reconciliation transaction can also determine how much assets to transfer to the DAO escrow account based on performance metrics.

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

[0198] 10. Computer Networks and Cloud Networks

[0199] In some embodiments, a computer network provides connections between a collection of nodes. The nodes can be local and / or remote from each other. The nodes are connected by a set of links. Examples of links include coaxial cables, unshielded twisted cables, copper cables, optical fibers, and virtual links.

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

[0201] A computer network may be a physical network, comprising physical nodes connected by physical links. A physical node is any digital device. A physical node may be a function-specific hardware device, 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 execute various virtual machines and / or applications that execute corresponding functions. A physical link is a physical medium that connects two or more physical nodes. Examples of links include coaxial cables, unshielded twisted cables, copper cables, and optical fibers.

[0202] A computer network may be an overlay network. An overlay network is a logical network implemented on top of another network (such as a physical network). Each node in the overlay network corresponds to a corresponding node in the underlying network. Therefore, each node in the overlay network is associated with both an overlay address (addressing the overlay node) and an underlying address (addressing the underlying node that implements the overlay node). An overlay node may be a digital device and / or a software process (such as a virtual machine, an application instance, or a thread). The link connecting the overlay nodes is implemented as a tunnel through the underlying network. The overlay nodes at either end of the tunnel treat the underlying multi-hop path between them as a single logical link. Tunneling is performed by encapsulation and decapsulation.

[0203] In some embodiments, the client can be located locally and / or remote from the computer network. The client can access the computer network through other computer networks, such as a private network or the Internet. The client can transmit the request to the computer network using a communication protocol, such as a hypertext transfer protocol (HTTP). The request is transmitted through an interface such as a client interface, such as a web browser, a program interface, or an application programming interface (API).

[0204] In some embodiments, a computer network provides a connection between a client and network resources. Network resources include hardware and / or software configured to execute a server process. Examples of network resources include processors, data storage devices, virtual machines, containers, and / or software applications. Network resources are shared between multiple clients. Clients request computing services from a computer network independently of each other. Network resources are dynamically allocated to requests and / or clients on demand. The network resources allocated to each request and / or client can be expanded or reduced based on, for example, (a) computing services requested by a specific client, (b) aggregate computing services requested by a specific tenant, and / or (c) the requested aggregate computing services of the computer network. Such a computer network may be referred to as a "cloud network."

[0205] In some embodiments, a service provider provides a cloud network to one or more end users. A cloud network can implement various service models, including but not limited to software as a service (SaaS), platform as a service (PaaS), and infrastructure as a service (IaaS). In SaaS, a service provider provides the end user with the ability to use the service provider's applications being executed on network resources. In PaaS, a service provider provides the end user with the ability to deploy customized applications on network resources. Customized applications can be created using programming languages, libraries, services, and tools supported by the service provider. In IaaS, a service provider provides the end user with the ability to supply processing, storage, network, and other basic computing resources provided by network resources. Any arbitrary application, including an operating system, can be deployed on network resources.

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

[0207] In some embodiments, the tenants of a multi-tenant computer network are independent of each other. For example, the business or operation of one tenant can be separated from the business or operation of another tenant. Different tenants may have different network requirements for the computer network. Examples of network requirements include processing speed, data storage capacity, security requirements, performance requirements, throughput requirements, latency requirements, elasticity requirements, quality of service (QoS) requirements, tenant isolation and / or consistency. The same computer network may need to implement different network requirements required by different tenants.

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

[0209] In some embodiments, each tenant is associated with a tenant ID. Each network resource of the multi-tenant computer network is marked with a tenant ID. Only when the tenant and the specific network resource are associated with the same tenant ID, the tenant is allowed to access the specific network resource.

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

[0211] As an example, each database implemented by a multi-tenant computer network can be marked with a tenant ID. Only the tenant associated with the corresponding tenant ID can access the data of a particular database. As another example, each entry in a database implemented by a multi-tenant computer network can be marked with a tenant ID. Only the tenant associated with the corresponding tenant ID can access the data of a particular entry. However, a database can be shared by multiple tenants.

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

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

[0214] 11. Hardware Overview

[0215] According to one embodiment, the technology described herein is implemented by one or more special-purpose computing devices. The special-purpose computing device can be hard-wired to perform the present technology, or can include a digital electronic device that is permanently programmed to perform the present technology, such as one or more application-specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), or network processing units (NPUs), or can include one or more general-purpose hardware processors that are programmed to perform the present technology according to program instructions in firmware, memory, other storage devices, or combinations. Such special-purpose computing devices can also combine customized hard-wired logic, ASICs, FPGAs, or NPUs with customized programming to implement the present technology. The special-purpose computing device can be a desktop computer system, a portable computer system, a handheld device, a networking device, or any other device that combines hard-wiring and / or program logic to implement the technology.

[0216] For example, Figure 8 800 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.

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

[0218] Computer system 800 also 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 or optical disk, is provided and coupled to bus 802 for storing information and instructions.

[0219] The computer system 800 may be coupled via the bus 802 to a display 812, such as a cathode ray tube (CRT) or light emitting diode (LED) monitor, for displaying information to a computer user. An input device 814, which may include alphanumeric and other keys, is coupled to the bus 802 for communicating information and command selections to the 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 direction information and command selections to the processor 804 and for controlling cursor movement on the display 812. The 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), to allow the device to specify a position in a plane.

[0220] The computer system 800 may implement the techniques described herein using custom hardwired logic, one or more ASICs or FPGAs, firmware, and / or program logic that, in combination with the computer system, makes the computer system 800 a special purpose machine or programs the computer system 800 to be a special purpose machine. According to one embodiment, the techniques herein are performed by the computer system 800 in response to the processor 804 executing one or more sequences of one or more instructions contained in the main memory 806. These instructions may be read into the main memory 806 from another storage medium, such as the storage device 810. Execution of the sequences of instructions contained in the main memory 806 causes the 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.

[0221] 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 particular manner. Such storage media may 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, tapes or any other magnetic data storage media, CD-ROMs, any other optical data storage media, any physical media with hole patterns, RAM, PROM and EPROM, FLASH-EPROM, NVRAM, any other memory chip or cassette, content addressable memory (CAM) and ternary content addressable memory (TCAM).

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

[0223] Various forms of media may be involved in carrying one or more sequences of one or more instructions to the processor 804 for execution. For example, the instructions may initially be carried on a disk or solid-state drive of a remote computer. The remote computer can load the instructions into its dynamic memory and send the instructions using a modem over a network line such as a telephone line, fiber optic cable, or coaxial cable. A modem local to the 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 the bus 802. The bus 802 carries the data to the main memory 806, from which the processor 804 retrieves and executes the instructions. The instructions received by the main memory 806 may optionally be stored on the storage device 810 before or after execution by the processor 804.

[0224] Computer system 800 also includes a communication interface 818 coupled to bus 802. Communication interface 818 provides bidirectional data communication coupled to network link 820, wherein network link 820 is connected to local network 822. For example, communication interface 818 can be an integrated services digital network (ISDN) card, a cable modem, a satellite modem, or a modem that provides data communication connection to a telephone line of a corresponding type. As another example, communication interface 818 can be a LAN card that provides data communication connection to a compatible local area network (LAN). Wireless links can also be implemented. In any such implementation, communication interface 818 sends and receives electrical signals, electromagnetic signals, or optical signals that carry digital data streams representing various types of information.

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

[0226] 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, server 830 can transmit the requested code for an application program through Internet 828, ISP 826, local network 822, and communication interface 818.

[0227] 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.

[0228] 12. Other Matters; Extension

[0229] Embodiments are directed to a system having one or more devices including a hardware processor and configured to perform any of the operations described herein and / or in any of the following claims.

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

[0231] According to one or more embodiments, any combination of the features and functions described herein may be used. In the foregoing description, embodiments have been described with reference to many specific details that vary depending on the implementation. Therefore, the description and drawings should be considered illustrative rather than restrictive. The sole and exclusive indicator of the scope of the present invention and what the applicant intends to be the scope of the present invention is the literal and equivalent range of the set of claims issued from this application, in the specific form in which such claims are issued, including any subsequent corrections.

Claims

1. A method comprising: receiving a request from an entity to track interactions between members of a cloud-based group and online content; wherein the entity is not part of a cloud-based group; determining, by at least one server, whether the request is accepted by the cloud-based group based at least in part on a selection on behalf of a member of the cloud-based group to accept or decline the request, wherein the selection does not reveal 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 any interactions between members of the cloud-based group and the online content; updating the data set based at least in part on the detected interactions between members of the cloud-based group and the online content; as well as Wherein the data set identifies one or more attributes of detected interactions between members of the cloud-based group and online content.

2. The method of claim 1, wherein the entity does not have access to private group communications of the cloud-based group; wherein the data set does not identify or provide access to private group communications.

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

4. The method of claim 1, wherein the request comprises a digital negotiation proposal specifying consideration for tracking interactions between the cloud-based group and the online content; the method further comprising: The digital negotiation proposal is announced to one or more groups that meet a set of criteria.

5. The method of claim 4, wherein the digital negotiation offer specifies a proposed consideration for tracking interactions between the cloud-based group and the online content.

6. The method of claim 4, wherein the digital negotiation is a smart contract enforced and executed within a blockchain network.

7. The method of claim 1, further comprising: In response to accepting the request, providing access to the anonymized group identifier; The anonymized group identifier is used to monitor and detect interactions with online content.

8. The method of claim 1, further comprising: One or more reconciliation operations are performed based on the data set.

9. The method of claim 8, wherein the reconciliation operation comprises initiating a first transaction to compensate the cloud-based group, wherein in response to the first transaction, the cloud-based group performs one or more additional transactions to compensate individual members of the group based at least in part on a policy agreed upon by members of the cloud-based group.

10. A method comprising: determining, by a blockchain network, whether a group connected to the blockchain network has approved the smart contract; wherein the smart contract grants members of the blockchain network access to anonymized group data; wherein the member of the blockchain network is not part of the group; In response to determining that the group has approved the smart contract, one or more blockchain transactions are executed, the one or more blockchain transactions including at least a first blockchain transaction that updates at least one block of a distributed ledger in a blockchain network based at least in part on access to the anonymized group data and the smart contract.

11. The method of claim 1 , further comprising: Registering the group with a directory service accessible to members of the blockchain network; Members of the blockchain network use a directory service to submit smart contract proposals to one or more groups.

12. A non-transitory computer readable medium comprising instructions which, when executed by one or more hardware processors, cause the operations recited in any one of claims 1-11 to be performed.

13. A system comprising a hardware processor and configured to perform the operations as claimed in any one of claims 1-11.

14. A system comprising means for performing the operations as recited in any one of claims 1-11.

Images