Distributed and blockchain-based ledger for data cloud services

Abstract

This document relates to distributed and blockchain-based ledgers for data cloud services. Techniques for managing transactions between data consumers and data providers using a blockchain are described herein.

Description

[0001] This application is a divisional application of the invention patent application filed on November 16, 2020, entitled "Distributed and Blockchain-Based Ledger for Data Cloud Services" with application number 202080100280.7. Technical Field

[0002] This disclosure relates to distributed computing systems and architectures. In particular, this disclosure relates to managing distributed ledgers for members of a permissioned blockchain network to enhance data transactions. Background Technology

[0003] Cloud-based data management platforms include networked computing resources for managing data transactions between data providers and data consumers. In this context, data consumers can include computing applications connected to or otherwise integrated with the cloud-based data management platform. Consumer applications can leverage data from the platform to enhance various data-driven functionalities. For example, applications can select and / or trigger automated actions with the highest probability of success inferred from data. Cloud-based data management platforms can also provide or enhance actionable insights for consumer applications by running big data, machine learning, and / or other artificial intelligence (AI) analytics on target datasets.

[0004] Data privacy, data integrity, and system scalability are likely to be key concerns for 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 datasets can expose data providers and consumers to various risks, including legal liability, exposure of confidential information to unauthorized entities, data corruption, and lost revenue. Furthermore, inaccurate or low-quality data can limit or impair the performance of consumer applications, leading to inefficient resource utilization. Large systems may link thousands or more entities, increasing the risk of losing sensitive data.

[0005] The methods described in this section are methods that can be pursued, but are not necessarily methods that have been previously conceived or pursued. Therefore, unless otherwise stated, no method described in this section should be assumed to be prior art simply because it is included in this section. Attached Figure Description

[0006] The embodiments are illustrated by way of example rather than limitation in the accompanying drawings. It should be noted that references to "a" or "an" embodiment in this disclosure do not necessarily refer to the same embodiment; they mean at least one. In the drawings: Figure 1 The illustration shows an example system for managing data transactions between different participants within a blockchain network, according to some embodiments; Figure 2 The illustration shows a set of example operations for managing transaction flows within a blockchain network, according to some embodiments. Figure 3 The illustration shows a set of example operations for initiating and managing transactions between data consumers and data providers through a blockchain network, according to some embodiments. Figure 4 The illustration shows a set of example operations for executing transactions on a blockchain network via performance-based smart contracts, according to some embodiments. Figure 5 The diagram illustrates a set of example operations used to execute transactions on a blockchain network to modify a dataset based on standards and / or privacy constraints provided by blockchain members; and Figure 6 A block diagram illustrating a computer system according to one or more embodiments is shown. Detailed Implementation

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

[0008] 1. General Overview

[0009] 2. Distributed ledgers and permissioned blockchains

[0010] 3. Ledger Transaction Management

[0011] 4. Smart contracts that share identifiers and other data

[0012] 5. Data usage and performance-based smart contracts

[0013] 6. Ledger-based deletion tracking and privacy controls

[0014] 7. Automatically modify smart contracts that share datasets.

[0015] 8. Computer networks and cloud networks

[0016] 9. Hardware Overview

[0017] 10. Other matters; extension

[0018] 1. General Overview

[0019] This article describes the technologies used to manage transactions between data consumers and data providers using blockchain. In this context, blockchain encompasses a set of technologies distinct from traditional databases. A blockchain includes a system for maintaining a ledger distributed across multiple blockchain members or participants. The distributed ledger stores consensus facts and the history of ledger updates. The ledger can include a continuously growing list of records, batched in blocks, which are linked sequentially and protected using cryptographic signatures.

[0020] Blockchain allows entities (internal and external) that do not fully trust each other to agree on updates submitted to a shared ledger using peer-to-peer protocols 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 records of transactions that have occurred on the platform. The distributed ledger does not belong to any particular entity, and updates to the ledger can be blocked unless agreed-upon peer-to-peer protocols are followed. Furthermore, cryptographic links between blocks in the ledger make the transactions written to the ledger immutable and tamper-proof.

[0021] In some embodiments, the techniques described herein are implemented in a permissioned blockchain. A permissioned blockchain is a blockchain in which membership is limited to a set of permitted participants. 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 more quickly. Permissioned blockchains can further improve overall data quality by preventing entities that may provide inaccurate, false, stolen, or otherwise compromised data from joining.

[0022] In some embodiments, a permissioned blockchain includes one or more data provider members, one or more data consumer members, one or more application platform members, and / or one or more data analytics members. Details of each data transaction between blockchain members can be recorded on a shared ledger. This immutable and tamper-proof record can be used to identify and track which datasets were accessed, which sources(s) provided the data, which consumers(s) accessed the data, which application platforms used the data, and in which activities / contexts the data was used. These details can be stored, excluding the data payload from the exchanged datasets, to prevent sensitive data from being stored in the shared ledger.

[0023] In some embodiments, transactions between members on a blockchain are managed and / or executed by smart contracts (also known as chaincode). Smart contracts are programs that run within the blockchain and can be invoked to read and write application data to / from the shared ledger, apply verification logic to allow / deny 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 the blockchain network can invoke one or more smart contracts to identify datasets that match the specified criteria, verify whether the consumer meets the requirements for accessing the dataset (predefined or determined at runtime), and, if approved, commit the transaction record to the ledger. Smart contracts can be associated with peer-to-peer endorsement and verification policies. If the necessary peer does not endorse or verify the proposed transaction, the transaction can be aborted. Aborted transactions are not committed to the shared ledger.

[0024] A blockchain can include various smart contracts that define transaction logic for different types of transactions. In some embodiments, a blockchain includes smart contracts for collaborative matching and sharing of data. Collaborative data sharing can help verify and enhance data. For example, an entity as a blockchain member may have user identifiers of visitors to a website operated by that entity. Multiple such entities can contribute their curated user identifiers to be matched against generic identifiers provided by cloud services or other blockchain participants. Matched identifiers can be shared on each member's copy of the ledger, and the use of identifiers can be tracked on the blockchain. The use of the pool can be managed by smart contracts between blockchain members. For example, smart contracts can determine the duration for which matched identifiers can be used, where (e.g., which applications / platforms) the identifiers can be used, and how the identifiers can be used. Smart contracts can be invoked to match user identifiers against one or more other members of the blockchain. Smart contracts can also allow the integration of matched datasets into applications without exposing sensitive data (e.g., provided first-party identifiers) to other members of the blockchain.

[0025] In some embodiments, the blockchain includes smart contracts that integrate data usage and / or performance metrics into blockchain transactions. For example, a smart contract may execute one or more blockchain transactions if and only if the peer-to-peer data usage set and / or performance criteria are met. Data usage and / or performance criteria can be used to define future option contracts on the dataset. For example, a future option contract regarding an audience dataset may be executed if and only if one or more performance metric thresholds (e.g., display verification measurement, content views, click-through rate, etc.) are met. The performance metrics of the audience dataset may be monitored by a service / platform, which may also be a member of the blockchain.

[0026] As another example, smart contracts can be invoked to reconcile transactions within the ledger based on performance metrics such as verification measures. Transactions on the blockchain can be initiated to compensate data and / or platform providers based on performance metrics. If a performance metric fails to meet a threshold, the transaction can be reversed or otherwise modified, such as by initiating a refund transaction to address low data quality issues. When a transaction is reversed, the record of the initial transaction can remain in an immutable block of the ledger. Refund transactions can be written to the same or different blocks.

[0027] In some embodiments, smart contracts can be invoked and / or associated with endorsement policies to prevent the use of certain sensitive information. For example, one or more peer nodes within the network may endorse a user who has opted out of sharing information with other entities only if the transaction does not contain sensitive information such as a user identifier. The shared ledger can track data deletion requests as part of an immutable record. During the endorsement process, peer nodes can compare the proposed transaction with the data deletion request and block the transaction if it includes information about a user who has opted out of information sharing.

[0028] In some embodiments, a smart contract may be invoked to modify a dataset shared on a blockchain network. For example, the smart contract may contain criteria for grouping, separating, editing, and / or otherwise modifying the dataset based on standards specified by one or more blockchain members and / or privacy constraints. When a proposed blockchain transaction is submitted to access the dataset, the smart contract may be executed to automatically modify the dataset according to the standards and / or privacy constraints before delivering the dataset to consuming blockchain members.

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

[0030] 2. Distributed ledgers and permissioned blockchains

[0031] In some embodiments, the technologies described herein are implemented as blockchain services. A blockchain service refers to a network service used to maintain a blockchain-based distributed ledger, such as Platform as a Service (PaaS) or other cloud services. As previously described, a distributed ledger may include a set of blocks linked by cryptographic values ​​that maintain consensus on facts and the history of ledger updates. The distributed ledger can be replicated, shared, and / or synchronized among multiple peer nodes within a blockchain network.

[0032] As previously mentioned, blockchain services can be permissioned blockchains, whereby access to the blockchain network is limited to permitted data providers, data consumers, application platforms, analytics service providers, and / or other entities. Permissions can be granted by one or more founding members of the blockchain network or according to a governance model. For example, if an organization wishes to join a permissioned blockchain, other institutional members can vote, or the board of directors can decide whether to grant a permission. As another example, permissions for an organization can be limited to those certified by accredited certification agents. Other governance models may also be used depending on the specific implementation.

[0033] 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 based, 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.

[0034] Figure 1 The illustration depicts an example system for managing data transactions between different participants within a blockchain network, according to some embodiments. Figure 1 As shown, system 100 includes a data provider node 102a, a data consumer node 102b, a data cloud node 102c, a platform node 102d, a blockchain platform 112, and a smart contract layer 124. In one or more embodiments, system 100 may include a data provider node 102a, a data consumer node 102b, a data cloud node 102c, a platform node 102d, a blockchain platform 112, and a smart contract layer 124. Figure 1 The components shown may have more or fewer components. Figure 1 The components shown can be local or remote to each other. Figure 1 The components shown can be implemented using software and / or hardware. Each component can be distributed across multiple applications and / or machines. In some cases, multiple components can be combined into a single application and / or machine. An operation described with respect to one component can be performed alternatively by another component.

[0035] Data provider node 102a is an operational network entity corresponding to a blockchain member supplying data. Data provider node 102a stores a copy of the shared ledger (ledger copy 104a) and has a client application 106a for interacting with the blockchain service. In some embodiments, client application 106a invokes a set of application programming interfaces (APIs) and / or a software development kit (SDK) to interact with chaincode and use events. For example, client application 106a may invoke chaincode to specify which datasets are available for sharing, the conditions for accessing the datasets, and restrictions on when and where the data can be used.

[0036] Data consumer node 102b also stores a copy of the ledger (ledger copy 104b) and includes a client application 106b for interacting with the blockchain service. In some embodiments, the chaincode invoked through client application 106b may be tailored to the data consumer role and differ from the chaincode accessible through client application 106a. For example, data consumers and providers may be restricted to initiating different types of transactions within the blockchain. This restriction may be enforced based on membership credentials such as public-private key pairings. In other embodiments, member nodes may be allowed to act as both data providers and data consumers within the blockchain simultaneously. In this case, member nodes may be allowed to use the same credentials to initiate transaction proposals, both for providing and consuming data.

[0037] Data cloud node 102c stores a copy of the shared ledger (ledger copy 104c). Data cloud node 102c also provides an analytics service 108, which can run analyses on consumed and / or to-be-consumed datasets. In some embodiments, analytics service 108 can invoke smart contracts to read performance metrics and / or write performance metrics to the distributed ledger.

[0038] Additionally or alternatively, analytics service 108 may invoke one or more smart contracts based on data usage and / or performance metrics. Examples include, but are not limited to, option contracts and reconciliation contracts, which are described in more detail in Part 5, entitled “Data Usage and Performance-Based Contracts.”

[0039] Additionally or alternatively, data cloud node 102c may invoke smart contracts to enforce privacy constraints and / or automatically modify the dataset, as provided by other blockchain members. Example smart contracts for enforcing privacy constraints and performing data modifications are described in Part 6, titled "Ledger-Based Deletion Tracking," and Part 7, titled "Smart Contracts for Automatically Modifying Shared Datasets."

[0040] Platform node 102d stores a copy of the shared ledger (ledger copy 104d) and further provides platform service 110. In some embodiments, platform service 110 includes an activity delivery platform service. For example, the platform service may include logic for inserting activity messages within one or more pages of a website. The platform service may format the activity messages (e.g., via HTML, cascading style sheets, etc.) to conform to the look and feel of the webpage. As another example, the platform service may provide applications, such as predictive tools, baseline tools, anomaly detection tools, or other data analytics tools that consume data to provide automated analytical output. The analytical 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.

[0041] 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, having isolated ledgers and authorized groups of blockchain members / nodes. Transactions executed on a particular channel may be limited to accessing the ledger on that channel, but members belonging to different channels can execute independent transactions on each channel. Therefore, while each node depicts only one ledger, a blockchain node can store multiple copies of the ledger (e.g., one ledger per channel to which the node belongs). Furthermore, the number and type of blockchain nodes may vary depending on the specific implementation.

[0042] Blockchain platform 112 includes a set of nodes and services for managing the distributed ledger. A blockchain platform typically includes membership service 114, ordering service 116, blocks 118, peer nodes 120, and a state database 122. Blockchain platform 112 can provide a closed ecosystem where only invited entities can join a permissioned blockchain network (and / or subnets / its channels) and retain a copy of the distributed ledger.

[0043] According to some embodiments, membership service 114 is configured to manage the roles and access policies of blockchain network members. For example, membership service 114 can handle the addition, verification, and cancellation of memberships within the blockchain network. As another example, membership service 114 can define access policies for different user roles. For instance, membership service 114 can assign members to different blockchain channels, where each blockchain channel maintains an isolated distributed ledger for the corresponding subset of members across the entire blockchain. Members can be granted cryptographic keys to access the corresponding ledger and / or smart contracts deployed to the blockchain channel.

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

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

[0046] Block 118 is a data object used to store the factual consensus of the shared ledger. Blocks can be added to the chain when updates occur, such as when members write new data (e.g., transaction records between data consumers and data providers) to the ledger. Each block within the blockchain contains a cryptographic hash of the previous block that links the blockchain 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 that led to the current state of the ledger (e.g., a write operation). The cryptographic linking of blocks in the blockchain enhances the tamper-proof nature of the shared ledger. Changing data within a block might require recalculating the cryptographic hash value for every subsequent block in the chain. The consensus protocol between peer nodes prevents such tampering.

[0047] Peer node 120 is an operational entity on the blockchain network, responsible for maintaining copies of the ledger, running smart contracts, and submitting transactions. Peer node 120 may include one or more of the following: data provider node 102a, data consumer node 102b, data cloud node 102c, and platform node 102d. Blockchain members may have one or more peer nodes on the blockchain network.

[0048] In some embodiments, peer nodes are implemented on one or more digital devices. The term "digital device" generally refers to any hardware device that includes a processor. A digital device can refer to a physical device that executes an application or virtual machine. Examples of digital devices include computers, tablets, laptops, desktops, netbooks, servers, web servers, network policy servers, proxy servers, general-purpose machines, feature-specific hardware devices, hardware routers, hardware switches, hardware firewalls, hardware network address translation (NAT), hardware load balancers, mainframes, televisions, content receivers, set-top boxes, printers, mobile phones, smartphones, personal digital assistants ("PDAs"), wireless receivers and / or transmitters, base stations, communications management equipment, routers, switches, controllers, access points, and / or client devices.

[0049] State database 122 tracks the current state of one or more distributed ledgers. State database 122 can be used to detect offline peers and update blocks to out-of-sync peers. In some embodiments, the state includes state information about data exchanged via the blockchain. For example, the state may include, but is not limited to, one or more of the following attributes: Purchased data: Indicates whether the data has been purchased by other members of the blockchain network; Data already used: Indicates whether the data has been used by other members of the blockchain network, such as in online activities of event management software; Viewed activity messages: Indicate whether online activity messages about data usage have been viewed, clicked, or otherwise seen via client applications such as web browsers; Identity used in the x context: Identifying the context in which the data is used; Consent status over a period of time: Tracking user consent status, which may change over time or vary depending on the type of data provider and marketer; and Audit Status: Tracks the audit status of transactions associated with the data.

[0050] It is important to note that the aforementioned attributes can be tracked in a state database and / or distributed ledger without storing the data payload exchanged between different blockchain members. Therefore, immutable and tamper-proof records of how and when data is used can be created without compromising data privacy.

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

[0052] In some embodiments, the blockchain program defines transaction logic for various types of transactions, including but not limited to: Data matching transaction 126 includes chaincode used to match the available dataset with criteria; Option-based transactions 128 include chaincode for processing options placed on a dataset; Delete transaction 130, including chaincode for processing requests to delete sensitive information or opt out of information sharing; The demonstration verifies transaction 132, including chaincode for reconciling transactions using measurement metrics based on the dataset; State change chaincodes are used to update and / or otherwise modify data within state database 122; Payment chaincode is used to process payments for accessing data within the blockchain; Reconciliation chaincode, used for transactions within the reconciliation blockchain; and Revenue Chaincode is used to track revenue from data usage and initiate revenue-based transactions within the blockchain.

[0053] The example smart contract functionality will be described in further detail in the following sections.

[0054] Additional embodiments and / or examples related to computer networks are described in Part 6, which is titled “Computer Networks and Cloud Networks”.

[0055] 3. Ledger Transaction Management

[0056] As mentioned earlier, peer nodes can be configured to manage transactions within the blockchain, including reading from and writing to the shared ledger. For example, peer nodes can endorse, validate, sort, and / or submit transaction records that meet defined policies. Transaction records can be used to restrict and track data exchange between blockchain members.

[0057] Figure 2 The illustration depicts a set of example operations for managing transaction flows within a blockchain network, according to some embodiments. One or more steps in the process may be omitted, repeated, and / or performed in a different order. Therefore, Figure 2 The specific arrangement of the steps shown should not be construed as limiting the scope of the embodiments.

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

[0059] One or more of the peer nodes 120 receive a transaction proposal and verify its digital signature (operation 204). In some embodiments, a public-private key pairing is used to verify the digital signature. For example, data consumer node 102b may provide its public key to peer node 120, which is part of the same blockchain channel. Data consumer node 102b may use its private key to digitally sign the request, which can then be verified by peer node 120 using the provided public key.

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

[0061] One or more peer nodes then digitally sign the chaincode result and return the result to data consumer node 102b (operation 208). Each peer node can digitally sign the chaincode result using its private key.

[0062] Data consumer node 102b receives results from one or more endorsing peer nodes and determines whether the proposed transaction has been successfully endorsed (operation 210). 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 met.

[0063] If a transaction is not successfully endorsed (e.g., the endorsement strategy requirements are not met), then the transaction is aborted (Operation 212).

[0064] Otherwise, data consumer node 102b submits the endorsed transaction to the ordering service 116 to continue submitting the proposed transaction (operation 214). In some embodiments, the submitted transaction includes results (e.g., read-write sets) and signatures from each endorsing peer.

[0065] The sorting service 116 verifies the signature / endorsement submitted by the data consumer node 102b and sorts the submitted transactions into blocks (operation 216). The way blocks are sorted may vary from implementation to implementation (e.g., sorting may be based on timestamps, Byzantine fault tolerance, etc.).

[0066] The sorting service then submits the new block to one or more of the 120 peer nodes to commit the transaction (operation 218). The submitting peer can be the same or a different set of peer nodes as the endorsing peer.

[0067] The submitting peer determines whether the transaction has been verified (operation 220). In some embodiments, each submitting peer verifies the signature, determines whether the endorsement policy is met, and compares the value of the key / variable read at the time of endorsement with the current value to make changes.

[0068] If a transaction cannot be verified (e.g., invalid signature, endorsement, or change of key value), then the transaction is aborted (Operation 212).

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

[0070] 4. Smart contracts used for sharing identifiers and other data

[0071] In some embodiments, a smart contract can define transaction logic for processing data exchange between blockchain members. For example, a smart contract can define conditions / criteria for exchanging datasets. These conditions may include, but are not limited to: Considerations required for accessing the dataset (e.g., purchase price / remittance, acceptable information transactions, consent and data usage rights, etc.); Limitations on how long a dataset can be accessed (e.g., a dataset can be accessed within a specified time window or until a specific date); and Restrictions on how the dataset can be used (e.g., the dataset can only be used on certain application / platform nodes in the blockchain).

[0072] In some embodiments, smart contracts include chaincode for managing transactions as part of an automated activity management system. Data providers may include applications configured to collect user information. For example, an application may extract HTTP cookies from visited websites, crawl web pages to extract targeted information, track information generated through the use of online services, etc. Data providers may allow consumers of the blockchain network to access the collected data based on conditions defined in the smart contract. Consumers may initiate transactions to search for and access data that meets a specified set of criteria (e.g., within a threshold price range, from a specified subset of providers, for users matching a specified profile). Data consumers may also initiate transactions with platform members to use the provided data as part of online activities. For example, the provided data may be used to identify information about visitors to a webpage in order to customize the webpage in a way that is determined to be most relevant to the user. Therefore, the content, visual elements, and manner in which the webpage is rendered may differ from one user to another.

[0073] Additionally or alternatively, the consumed data can be used in other applications. For example, machine learning (ML) services may rely on high-quality training data to train and improve the accuracy of their models. Entities wishing to train machine learning services may not have access to high-quality data. The raw data can be obtained through a blockchain network and then transformed by the ML application for training and evaluating ML models.

[0074] Additionally or alternatively, smart contracts can manage collaborative data-sharing arrangements. For example, different data providers may possess incomplete sets of information about a set of users. Data providers can submit first-party identifiers to a data cloud service for matching against third-party / centralized identifiers. If two or more data providers match the same third-party identifier, that third-party identifier can be shared / written to the distributed ledger. The data cloud service can perform the matching process with visibility restrictions, allowing information about the matching users to be shared without compromising / leaking the first-party identifier. For example, the data cloud service can be configured so that only matching third-party identifiers are allowed access by human users or external network nodes. Therefore, access to first-party identifiers submitted by other members of the blockchain can be prevented for individuals and external applications.

[0075] Figure 3 The illustration depicts a set of example operations for initiating and managing transactions between data consumers and data providers via a blockchain network, according to some embodiments. One or more steps in the process may be omitted, repeated, and / or performed in a different order. Therefore, Figure 3 The specific arrangement of the steps shown should not be construed as limiting the scope of the embodiments.

[0076] refer to Figure 3 Blockchain members submit standard transactions (Operation 302) that include identifiers and / or matching data content. For example, a data consumer might request an identifier and / or other user information for a user matching a profile. As another example, a blockchain member might submit a request for training data with a specified set of attributes, or submit an incomplete dataset to share with other members who may provide additional information about the dataset. In yet another example, a blockchain member might provide a first-party identifier for collaborative data sharing, as described above.

[0077] In response to receiving a transaction proposal, one or more peer nodes initiate a transaction, thereby executing chaincode to match the identifier and / or criteria with the corresponding dataset (Operation 304).

[0078] The peer node then determines whether the transaction proposal has been endorsed and verified (Operation 306). For example, Figure 2 The transaction process described can be implemented based on the invoked smart contract and the associated endorsement strategy to determine whether a transaction should be submitted.

[0079] If a transaction fails or cannot be verified, it is then aborted (Operation 308). As mentioned earlier, failed transactions are not committed to the blockchain, but may still have a flag indicating their failure written into their details.

[0080] If a transaction is successfully endorsed and verified, the peer node commits the transaction to a shared ledger, which is then distributed / replicated to members of the blockchain channel (Operation 310). The shared ledger can include various details about the exchanged data. For example, Table 1 below depicts a sample set of transaction records that can be written to blocks on the blockchain.

[0081]

[0082] Table 1: Example Transaction Records

[0083] The records described above include performance metrics for the dataset (display, cost, category identifier of the dataset provided, identifiers of one or more data providers supplying the dataset, attribute information indicating the data portion supplied by each provider, consumer identifiers of entities accessing the data, and expiration dates for data access). These records are given as examples. Stored transaction attributes may vary depending on the specific implementation. Other attributes may include, but are not limited to, any of the attributes listed above regarding the state database, such as the application context using the data and the audit status of the data. Furthermore, attributes / attribute values ​​of records belonging to the same block can be hashed, as previously described. Hashes can be stored in subsequent blocks to provide cryptographic links between different blocks written to the ledger.

[0084] Smart contracts can also trigger data exchanges between data providers (one or more) and consumers and / or platform nodes (Operation 312). For example, data can be provided to an event delivery platform. The event delivery platform can then monitor webpage visits by visitors matching user identifiers via embedded script tags. The event delivery platform can then customize / render webpages in a way that is tailored to the identified users.

[0085] Smart contracts can also allow time-limited data access (Operation 314). If access is time-limited, one or more blockchain nodes can continue to monitor the transaction until the time limit expires.

[0086] Once the time limit has expired, the ledger can be updated (e.g., a new transaction can be initiated) to end access to the dataset (Operation 316). In some embodiments, the dataset (e.g., user IDs, etc.) can be provided directly to platform members instead of the data buyer. This allows the platform to perform functions on the dataset without revealing it 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 can degrade the quality of older datasets over time.

[0087] 5. Data usage and performance-based smart contracts

[0088] In some embodiments, smart contracts execute blockchain transactions based on data usage and / or performance metrics. As previously described, analytics service 108 can capture performance metrics associated with the use of datasets available through the blockchain. Analytics service 108 can periodically initiate transactions to write performance metrics into the distributed ledger.

[0089] In some embodiments, analytics service 108 collects performance metrics from websites or applications that use the dataset. For example, script tags may be included in code used to load / render campaign messages. Script tags may contain macros that parse to report various performance metrics. Example performance metrics may include, but are not limited to, impression counts (e.g., a count of the number of times the dataset is used to load and render campaign messages on a webpage), measures of how many rendered campaign messages are seen / visible through browsers / client applications (e.g., percentage values ​​between 0 and 100, click-through rates of hyperlinks included in the campaign message, likes / positive interactions with the campaign message, overall effectiveness score of the campaign message, cost metrics, data accuracy measures, etc.).

[0090] While peer nodes are running smart contracts, they can read performance metrics of datasets from the distributed ledger. These performance metrics can influence the runtime behavior of smart contracts. For example, a smart contract may only execute a transaction on a dataset if the performance metric is above a threshold or likely matches the highest-performing dataset in a particular category. As another example, datasets can be dynamically priced based on their performance metrics—the considerations required to access the dataset can be adjusted continuously or periodically. The price of a dataset may increase as the performance metric improves or decrease as the performance metric declines.

[0091] Additionally or alternatively, smart contracts can consider the context in which the dataset is used. The criteria for accessing the dataset may differ from one context to another. For example, a smart contract might deny access to the dataset to an online activity that directly competes with the data provider, or require a higher price to use the dataset in that context than in other, non-competitive contexts. As another example, a smart contract could offer discounts for educational or non-commercial activities (or other applications) that use the dataset.

[0092] As an add-on or alternative to option-based contracts, performance metrics can be integrated with smart contracts for transaction reconciliation. For example, a smart contract can automatically initiate transactions within the blockchain to pay a fee for using a dataset based on a performance metric—the more impressions counted and / or the higher the quality of impressions obtained by using a provided set of user identifiers, the higher the fee. As another example, if a performance metric falls below a threshold, a transaction can be initiated to issue a full or partial refund to the consumer from platform nodes and / or providers. Thus, data providers are incentivized to supply clean and accurate data to the blockchain, and platform providers are incentivized to use the data in the most effective way for consumers.

[0093] Figure 4 The illustration depicts a set of example operations for executing analytics-based transactions on a blockchain network, according to some embodiments. One or more steps may be omitted, repeated, and / or performed in a different order. Therefore, Figure 4 The specific arrangement of the steps shown should not be construed as limiting the scope of the embodiments.

[0094] refer to Figure 4 A set of performance metrics that tracks the use of one or more datasets within an application is written to the ledger (Operation 402). For example, data cloud node 102c can periodically write performance metrics to a blockchain channel dedicated to tracking performance data on available datasets. As previously mentioned, performance metrics may include metrics about audience datasets such as those viewed or interacted with online activities through web browsers or mobile applications.

[0095] In some embodiments, peer nodes use performance metrics to determine whether to reconcile any pending transactions (Operation 404). For example, if a performance metric does not meet a threshold (e.g., one or more display metrics of the audience dataset provided via script tags do not meet the smart contract's requirements), then the transaction is marked for reconciliation. This step can be completed during smart contract runtime and / or in response to the detection of a new write to the performance metric. During the runtime of one smart contract, a peer node can invoke another smart contract to query the performance metric written to the ledger on another blockchain channel.

[0096] If a transaction needs to be reconciled based on a performance metric, a reconciliation process is initiated on the blockchain, and the distributed ledger is updated accordingly (operation 406). In some embodiments, transaction records may be updated to include the performance metric that triggered the reconciliation. For example, a remittance transaction on the blockchain may be triggered between the data buyer and the data provider for every 100 positive impressions obtained using the dataset. In other embodiments, if the performance metric does not meet a threshold (e.g., has little or no positive impact on online activity), the platform and / or the data provider may issue a refund to the data buyer.

[0097] In some embodiments, transaction reconciliation can be performed based on attribute metrics. For example, a combined dataset obtained from multiple providers can be accessed by a data consumer and used for online activities. Data providers can receive compensation based on the data they provide, the performance of their data relative to data from other providers, and / or other metrics.

[0098] Additionally or alternatively, the process may include determining whether any option-based smart contracts have been defined and satisfied (Operation 408). For example, as previously mentioned, a future option contract may be defined with reference to a target audience dataset. The future option contract may define one or more performance thresholds, such as the minimum number of positive impressions, minimum click-through rate, minimum audience engagement for online activities, maximum cost per impression, etc.

[0099] If the option criteria are met, the transaction can be executed / submitted to the blockchain. (Operation 410)

[0100] 6. Ledger-based deletion tracking and privacy controls

[0101] In some embodiments, the blockchain channel includes a ledger for tracking data deletion requests. Deletion requests may include user requests to opt out of allowing blockchain members to use or share their information. The ledger can serve as an immutable audit trail to track information about which users submitted requests and when they were submitted.

[0102] In some embodiments, the identity resolution chain is responsible for formatting deletion requests and writing them to the blockchain. Data provider nodes can forward exit requests to the identity resolution service. The identity resolution chain can match the data provider's first-party identifier with a centralized third-party identifier (e.g., a BlueKai identifier) ​​and write these identifiers to the blockchain.

[0103] During the endorsement process, peer nodes can compare the proposed transaction with the data deletion request and block the transaction if it includes information about users who have opted out of information sharing. For example, a peer node can be an endorser, and it can reject a proposed transaction if its endorsement involves the use of sensitive data of users who have opted out of information sharing.

[0104] Additionally or alternatively, blockchain channels can implement other privacy controls. In some embodiments, a blockchain network can enforce constraints on how data buyers view / use datasets. For example, a blockchain network can block access to certain portions of an audience dataset containing sensitive information, such as personally identifiable information, personal health information, or credit card numbers.

[0105] As another example, blockchain networks can restrict access to information in ways that prevent visibility into audience datasets. For instance, when purchasing an audience dataset, the data buyer might not be able to access the dataset in a manner that allows data visibility. The audience dataset can be provided to platform nodes for use in executing online campaigns. The data buyer can view data usage and performance metrics associated with the audience dataset. However, the data buyer can be prevented from viewing detailed information about individual audience members within the audience dataset.

[0106] 7. Smart contracts for automatically modifying shared datasets

[0107] In some embodiments, a smart contract may trigger automatic modifications to a dataset based on criteria and / or privacy constraints specified by members. Modifications triggered by a smart contract can control how datasets available through the blockchain network are accessed, protect sensitive information from unauthorized access, and / or ensure compliance with privacy laws.

[0108] In some embodiments, blockchain members can define rules or logic to control how their shared datasets are modified (if possible) and the conditions that trigger such modifications. For example, a data provider might have an audience dataset containing thousands of records, each including contact information (e.g., HTTP cookie identifiers, email addresses, etc.) of a potential audience member for an online messaging campaign. The data provider can specify rules, including (a) whether to allow the dataset to be broken down into discrete subsets and / or joined to other datasets; and (b) conditions under which the dataset may be broken down into subsets and / or joined to other datasets. In some cases, a data provider might allow consumers to purchase subsets of records at a lower price or restrict access to subsets of audience member attributes. In other cases, a data provider might allow or block the dataset from being linked to datasets from other data provider members. As can be appreciated, rules and conditions can vary and can be customized by blockchain members. Based on the submitted rules / conditions, the blockchain platform can generate smart contract chaincode to control modifications to the dataset.

[0109] Additionally or alternatively, smart contracts may include chaincode that triggers the application of one or more privacy filters to protect sensitive data. Once triggered, the privacy filters can perform data masking and / or editing operations on the dataset to obfuscate or remove privacy information. For example, individual names within a collection of records can be removed or replaced with anonymous identifiers or dummy data. Techniques for generating anonymous, private identifiers and using identifiers to associate anonymous information with sensitive information in an unidentifiable manner are described in U.S. Application No. 14 / 941,047, which is previously incorporated by reference.

[0110] Figure 5The diagram illustrates a set of example operations for executing transactions on a blockchain network to modify a dataset based on standards and / or privacy constraints provided by blockchain members. One or more steps in the process may be omitted, repeated, and / or performed in a different order. Therefore, Figure 5 The specific arrangement of the steps shown should not be construed as limiting the scope of the embodiments.

[0111] This process includes receiving proposed blockchain transactions to use or otherwise access the dataset (Operation 502). Transactions may include identifiers and / or matching criteria as described above that match the dataset.

[0112] In response to the request, the peer node identifies one or more smart contracts that control modifications to the dataset (Operation 504). In some embodiments, registration or other mapping information may be maintained in a table, such that smart contracts are mapped to datasets. Depending on the specific implementation, smart contracts may be registered and applied to a single dataset or a group of datasets. The peer node may search the mapping data to determine which smart contracts have been mapped to matching datasets.

[0113] The peer node also uses each of one or more identified smart contracts to execute the associated chaincode to trigger modifications to the dataset (Operation 506). As previously described, modifications may include applying privacy filters, removing data, editing data, and / or linking data.

[0114] The peer node further determines whether to submit the transaction for the modified dataset (Operation 508). As mentioned earlier, the peer node can determine whether to submit the transaction based on whether it has been successfully endorsed and verified within the blockchain network.

[0115] If a transaction is successfully verified, the modified dataset is committed to the distributed ledger (Operation 510). The ledger can include details about how the dataset was modified. For example, the ledger can specify how many records were removed from the dataset and / or instructions for applying privacy filters.

[0116] If a transaction is not successfully verified, the transaction on the modified dataset is aborted (Operation 512).

[0117] 8. Computer networks and cloud networks

[0118] In one or more embodiments, a computer network provides connectivity between a set of nodes. Nodes may be local to each other and / or geographically distant. Nodes are connected by a set of links. Examples of links include coaxial cable, unshielded twisted pair, copper cable, fiber optic cable, and virtual links.

[0119] A subset of nodes implements a computer network. Examples of such nodes include switches, routers, firewalls, and Network Address Translation (NAT). Another subset of nodes uses a computer network. Such nodes (also called "hosts") can execute client processes and / or server processes. Client processes make requests for computing services, such as the execution of a specific application and / or the storage of a specific amount of data. Server processes respond by performing the requested service and / or returning the corresponding data.

[0120] A computer network can be a physical network, including physical nodes connected by physical links. A physical node is any digital device. A physical node can be a function-specific hardware device, such as a hardware switch, hardware router, hardware firewall, and hardware NAT. Additionally or alternatively, a physical node can be a general-purpose machine configured to run various virtual machines and / or applications performing corresponding functions. A physical link is the physical medium connecting two or more physical nodes. Examples of links include coaxial cable, unshielded stranded cable, copper cable, and fiber optic cable.

[0121] Computer networks can be overlay networks. An overlay network is a logical network implemented on top of another network (such as a physical network). Each node in an overlay network corresponds to a corresponding node in the underlying network. Therefore, each node in an overlay network is associated with both an overlay address (addressing to the overlay node) and an underlying address (addressing the underlying node that implements the overlay node). Overlay nodes can be digital devices and / or software processes (such as virtual machines, application instances, or threads). The links connecting overlay nodes are implemented as tunnels through the underlying network. Overlay nodes at either end of the tunnel treat the underlying multi-hop path between them as a single logical link. Tunneling is performed through encapsulation and decapsulation.

[0122] In this embodiment, the client may be located locally on the computer network and / or remotely on the computer network. The client may access the computer network via other computer networks, such as a private network or the Internet. The client may use a communication protocol, such as Hypertext Transfer Protocol (HTTP), to transmit requests to the computer network. Requests may be transmitted through interfaces such as client interfaces (such as web browsers), program interfaces, or application programming interfaces (APIs).

[0123] In this embodiment, a computer network provides connectivity between clients and network resources. Network resources include hardware and / or software configured to execute server processes. Examples of network resources include processors, data storage devices, virtual machines, containers, and / or software applications. Network resources are shared among multiple clients. Clients independently request computing services from the computer network. Network resources are dynamically allocated to requesting and / or clients on demand. The network resources allocated to each requesting and / or client can be scaled up or down based on, for example, (a) computing services requested by a specific client, (b) aggregated computing services requested by a specific tenant, and / or (c) the requested aggregated computing services of the computer network. Such a computer network may be referred to as a "cloud network."

[0124] In this embodiment, the service provider offers a cloud network to one or more end users. The 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, the service provider offers end users the ability to use applications running on the service provider's network resources. In PaaS, the service provider offers end users the ability to deploy custom applications to network resources. Custom applications can be created using programming languages, libraries, services, and tools supported by the service provider. In IaaS, the service provider offers end users the ability to provision processing, storage, networking, and other basic computing resources provided by the network resources. Any application, including operating systems, can be deployed on the network resources.

[0125] In embodiments, computer networks can implement various deployment models, including but not limited to private clouds, public clouds, and hybrid clouds. In a private cloud, network resources are provisioned to a specific group of entities for exclusive use (as used herein, "entity" refers to a business, organization, individual, or other entity). Network resources can be local to or remote from the premises of the specific group of entities. In a public cloud, cloud resources are provisioned to multiple entities (also referred to as "tenants" or "customers") that are independent of each other. The 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 or remote from the tenant's premises. In a hybrid cloud, the computer network includes both private and public clouds. The interface between the private and public clouds allows for the portability of data and applications. Data stored in the private cloud and data stored in the public cloud can be exchanged through the interface. Applications implemented in the private cloud and applications implemented in the public cloud may be interdependent. You can execute calls from a private cloud to an application on a public cloud (or vice versa) through an interface.

[0126] In this embodiment, the tenants of a multi-tenant computer network are independent of each other. For example, one tenant's business or operations may be separate from those 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, resilience requirements, quality of service (QoS) requirements, tenant isolation, and / or consistency. The same computer network may need to meet the different network requirements demanded by different tenants.

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

[0128] In this embodiment, each tenant is associated with a tenant ID. Each network resource in a multi-tenant computer network is tagged with a tenant ID. A tenant is only allowed access to a specific network resource if the tenant and the specific network resource are associated with the same tenant ID.

[0129] In this embodiment, each tenant is associated with a tenant ID. Each application implemented by the computer network is tagged with a tenant ID. Additionally or alternatively, each data structure and / or dataset stored by the computer network is tagged with a tenant ID. A tenant is allowed access to a specific application, data structure, and / or dataset only if the tenant and the specific application, data structure, and / or dataset are associated with the same tenant ID.

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

[0131] In this embodiment, the subscription list indicates which tenants are authorized to access which applications. For each application, a list of tenant IDs of tenants authorized to access that application is stored. A tenant is only allowed to access a specific application if its tenant ID is included in the subscription list corresponding to that specific application.

[0132] In this embodiment, network resources (such as digital devices, virtual machines, application instances, and threads) corresponding to different tenants are isolated to tenant-specific overlay networks maintained by a multi-tenant computer network. As an example, data packets from any source device within a tenant overlay network can be sent only to other devices within the same tenant overlay network. Encapsulation tunnels are used to prevent any transmission from a source device on one tenant overlay network to devices in other tenant overlay networks. Specifically, data packets received from the source device are encapsulated within an outer data packet. The outer data packet is sent from a first encapsulation tunnel endpoint (communicating with the source device in the tenant overlay network) to a second encapsulation tunnel endpoint (communicating with the destination device in the 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 then sent from the second encapsulation tunnel endpoint to the destination device within the same specific overlay network.

[0133] 9. Hardware Overview

[0134] According to one embodiment, the techniques described herein are implemented by one or more dedicated computing devices. The dedicated computing device may be hardwired to execute the techniques, or may include digital electronic devices permanently programmed to execute the techniques, such as one or more application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or network processing units (NPUs), or may include one or more general-purpose hardware processors programmed to execute the techniques according to program instructions in firmware, memory, other storage devices, or combinations thereof. Such a dedicated computing device may also implement the techniques by combining custom hardwired logic, ASICs, FPGAs, or NPUs with custom programming. The dedicated computing device may be a desktop computer system, a portable computer system, a handheld device, a networking device, or any other device that combines hardwired and / or program logic to implement the techniques.

[0135] For example, Figure 6 This is a block diagram illustrating a computer system 600 on which embodiments of the present invention may be implemented. The computer system 600 includes a bus 602 or other communication mechanism for transmitting information and a hardware processor 604 coupled to the bus 602 for processing information. The hardware processor 604 may be, for example, a general-purpose microprocessor.

[0136] Computer system 600 also includes main memory 606, such as random access memory (RAM) or other dynamic storage devices, coupled to bus 602 for storing information and instructions to be executed by processor 604. Main memory 606 may also be used to store temporary variables or other intermediate information during the execution of instructions to be executed by processor 604. When such instructions are stored in non-transitory storage media accessible to processor 604, such instructions make computer system 600 a dedicated machine customized to perform the operations specified in the instructions.

[0137] The computer system 600 also includes a read-only memory (ROM) 608 or other static storage device coupled to the bus 602 for storing static information and instructions of the processor 604. A storage device 610, such as a disk or optical disk, is provided and coupled to the bus 602 for storing information and instructions.

[0138] Computer system 600 may be coupled via bus 602 to a display 612, such as a cathode ray tube (CRT) or light-emitting diode (LED) monitor, for displaying information to a computer user. An input device 614, which may include alphanumeric keys and other keys, may be coupled to bus 602 to transmit information and command selections to processor 604. Another type of user input device is a cursor control 616, such as a mouse, trackball, touchscreen, or cursor arrow keys, for transmitting directional information and command selections to processor 604 and for controlling cursor movement on display 612. Input device 614 typically has two degrees of freedom on 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.

[0139] Computer system 600 may implement the techniques described herein using custom hard-wired logic, one or more ASICs or FPGAs, firmware, and / or program logic, which, in combination with the computer system, enable computer system 600 to become a special-purpose machine or to program computer system 600 as a special-purpose machine. According to one embodiment, the techniques herein are executed by computer system 600 in response to processor 604 executing one or more sequences of one or more instructions contained in main memory 606. These instructions may be read into main memory 606 from another storage medium, such as storage device 610. Execution of the sequence of instructions contained in main memory 606 causes processor 604 to perform the processing steps described herein. In alternative embodiments, hard-wired circuitry may be used instead of software instructions or in combination with software instructions.

[0140] As used herein, the term "storage medium" refers to any non-transitory medium that stores data and / or instructions that enable a machine to operate in a particular manner. Such storage media can include non-volatile media and / or volatile media. Non-volatile media include, for example, optical discs or magnetic disks, such as storage device 610. Volatile media include dynamic memory, such as main memory 606. Common forms of storage media include, for example, floppy disks, flexible disks, hard disks, solid-state drives, magnetic tape or any other magnetic data storage media, CD-ROMs, any other optical data storage media, any physical media with a perforated pattern, RAM, PROMs and EPROMs, FLASH-EPROMs, NVRAMs, any other memory chips or cassette tapes, content-addressable memory (CAM), and tri-state content-addressable memory (TCAM).

[0141] Storage media differ from transmission media but can be used in conjunction with them. Transmission media participate in the transfer of information between storage media. For example, transmission media include coaxial cables, copper wires, and optical fibers, including wires containing bus 602. Transmission media can also take the form of sound waves or light waves, such as those generated during radio wave and infrared data communication.

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

[0143] Computer system 600 also includes a communication interface 618 coupled to bus 602. Communication interface 618 provides bidirectional data communication coupled to network link 620, which is connected to local network 622. For example, communication interface 618 may be an Integrated Services Digital Network (ISDN) card, a cable modem, a satellite modem, or a modem providing data communication connectivity to a corresponding type of telephone line. As another example, communication interface 618 may be a LAN card providing data communication connectivity to a compatible local area network (LAN). A wireless link may also be implemented. In any such implementation, communication interface 618 transmits and receives electrical, electromagnetic, or optical signals carrying streams of digital data representing various types of information.

[0144] Network link 620 typically provides data communication to other data devices via one or more networks. For example, network link 620 may provide a connection to host computer 624 or to data devices operated by Internet Service Provider (ISP) 626 via local network 622. ISP 626, in turn, provides data communication services via a global packet data communication network now commonly referred to as the "Internet" 628. Both local network 622 and Internet 628 use electrical, electromagnetic, or optical signals that carry digital data streams. Signals through various networks, as well as signals on network link 620 and through communication interface 618, are example forms of transmission media that carry digital data to or from computer system 600.

[0145] Computer system 600 can send messages and receive data, including program code, through one or more networks, network links 620, and communication interfaces 618. In the Internet example, server 630 can transmit requested code for the application through the Internet 628, ISP 626, local network 622, and communication interface 618.

[0146] The received code can be executed by processor 604 when it is received, and / or stored in storage device 610 or other non-volatile storage device for later execution.

[0147] 10. Other matters; extension

[0148] The embodiments are directed to a system having one or more devices, which include a hardware processor and are configured to perform any of the operations described herein and / or any of the following claims.

[0149] In an embodiment, the non-transitory computer-readable storage medium includes instructions that, when executed by one or more hardware processors, cause to perform any of the operations described herein and / or any of the claims.

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

Claims

1. A non-transitory computer-readable medium storing one or more instructions, which, when executed by one or more hardware processors, cause: Identify a set of one or more performance metrics associated with the use of a dataset by one or more applications, wherein the performance metrics indicate how the use of the dataset by the one or more applications is performed relative to the context in which the dataset is used; The smart contracts used to update the distributed ledger within the blockchain network are identified, at least in part, based on one or more performance metrics associated with the use of the dataset. Determine whether one or more performance metrics associated with the use of the dataset meet at least one threshold performance value associated with the smart contract; and In response to determining that one or more performance metrics associated with the use of the dataset meet the at least one threshold performance value, a smart contract is executed to update the distributed ledger within the blockchain network, based at least in part on the one or more performance metrics associated with the use of the dataset by the one or more applications.

2. The medium as described in claim 1, wherein, The at least one threshold performance value is the minimum threshold performance metric used to execute a smart contract.

3. The medium as described in claim 1, wherein, Updating the distributed ledger involves coordinating transactions within the blockchain network based at least in part on one or more performance metrics associated with the use of the dataset.

4. The medium as described in claim 1, wherein, Executing smart contracts to update the distributed ledger generates immutable records of one or more performance metrics within the blockchain network.

5. The medium as described in claim 1, wherein, Executing a smart contract includes executing blockchain transactions based on one or more performance metrics associated with the use of the dataset.

6. The medium as claimed in claim 1, wherein, The one or more performance metrics are collected using script tags embedded in the code used to render at least a portion of the webpage.

7. The medium according to claim 1, wherein the blockchain network connects multiple nodes, including data provider nodes, data consumer nodes, data cloud nodes, and platform nodes.

8. The medium of claim 7, wherein the data cloud node writes one or more performance metrics associated with the use of the dataset into a blockchain channel within the blockchain network based on at least one use of the dataset by the data consumer node through the platform node; wherein the dataset can be accessed and used by the data provider node.

9. The medium as claimed in claim 1, wherein, The set of one or more performance metrics includes an effectiveness score based on the use of the dataset within the one or more applications.

10. The medium as claimed in claim 1, wherein, The set of one or more performance metrics includes the click-through rate of hyperlinks.

11. The medium as claimed in claim 1, wherein, The set of one or more performance metrics includes measurements of data accuracy.

12. A method comprising Identify a set of one or more performance metrics associated with the use of a dataset by one or more applications, wherein the performance metrics indicate how the use of the dataset by one or more applications is performed relative to the context in which the dataset is used; The smart contracts used to update the distributed ledger within the blockchain network are identified, at least in part, based on one or more performance metrics associated with the use of the dataset. Determine whether one or more performance metrics associated with the use of the dataset meet at least one threshold performance value associated with the smart contract; and In response to determining that one or more performance metrics associated with the use of the dataset meet the at least one threshold performance value, a smart contract is executed to update the distributed ledger within the blockchain network, based at least in part on the one or more performance metrics associated with the use of the dataset by the one or more applications.

13. The method of claim 12, wherein, The at least one threshold performance value is the minimum threshold performance metric used to execute a smart contract.

14. The method of claim 12, wherein updating the distributed ledger includes coordinating transactions within the blockchain network based at least in part on one or more performance metrics associated with the use of the dataset.

15. The method of claim 12, wherein the smart contract is executed to update the distributed ledger within the blockchain network an immutable record of the one or more performance metrics.

16. The method of claim 12, wherein, Executing a smart contract includes executing blockchain transactions based on one or more performance metrics associated with the use of the dataset.

17. The method of claim 12, wherein, The one or more performance metrics are collected using script tags embedded in the code used to render at least a portion of the webpage.

18. The method of claim 12, wherein the blockchain network connects multiple nodes, including data provider nodes, data consumer nodes, data cloud nodes, and platform nodes.

19. The method of claim 18, wherein the data cloud node writes one or more performance metrics associated with the use of the dataset into a blockchain channel within the blockchain network based on at least one use of the dataset by the data consumer node through the platform node; wherein the dataset can be accessed and used by the data provider node.

20. A system comprising: One or more hardware processors; and A non-transitory computer-readable medium storing one or more instructions, which, when executed by the one or more hardware processors, cause: Identify a set of one or more performance metrics associated with the use of a dataset by one or more applications, wherein the performance metrics indicate how the use of the dataset by the one or more applications is performed relative to the context in which the dataset is used; The smart contracts used to update the distributed ledger within the blockchain network are identified, at least in part, based on one or more performance metrics associated with the use of the dataset. Determine whether one or more performance metrics associated with the use of the dataset meet at least one threshold performance value associated with the smart contract; and In response to determining that one or more performance metrics associated with the use of the dataset meet the at least one threshold performance value, a smart contract is executed to update the distributed ledger within the blockchain network, based at least in part on the one or more performance metrics associated with the use of the dataset by the one or more applications.

Images