Consortium Blockchain Smart Contracts for Musical Rights Governance in a Collective Management Organizations (CMOs) Use Case

Abstract

Private and permissioned blockchains are conceptualized and mostly assembled for fulfilling corporations’ demands and needs in the context of their own premises. This paper presents a complete and sophisticated end-to-end permissioned blockchain application for governance and management of musical rights endorsed by smart contract development. In a music industry use case, this disclosed solution monitors and regulates conflicting musical rights of diverse entities under a popular permissioned distributed ledger technology network. The proposed implementation couples various and distinct business domains across the music industry organizations and non-profit blockchain associations.

1. Introduction

The music industry struggles from some deeply ingrained pains linked to copyrights management and royalty allocation that have only been reinforced by the digital revolution and the emergence of the streaming era. There have been several failed attempts to come up with ways to address it. The most prominent was the Global Repertoire Database (GRD), a collaborative project by a diverse group of organizations, including large music labels, software firms, collective management organizations (CMOs) and multinational unions; the GRD was disbanded in 2014 following four years of growth and conflict, leaving behind a debt of $13.7 million [1]. One of the main reasons for the problematic management of music work copyrights is the number of stakeholders involved as well as the unorganized and ununified way of communication between them [2]. As depicted in a simplified manner in Figure 1, there are many connections between the stakeholders, which can easily produce different copyrights and royalty distribution documents, making the process of tracking and validating the correct copyright data extremely hard for the CMO.

Given the nature of the ecosystem as well as the complete digitalization of the music work creation and distribution, music industry solutions for copyrights management and royalty distribution have shifted to modern solutions. One of the most promising technologies to tackle these issues is blockchain [3]. Key concepts of blockchain such as transparency, decentralization and immutability can provide a more robust and accessible system for all the parties involved. In this paper, a blockchain framework for musical rights management and governance is presented.

This framework aims to streamline the whole process of music rights management, from the declaration of ownership of copyright to the immediate dissemination of up-to-date information to all stakeholders, including a mechanism to settle conflicts between registered stakeholders on a blockchain-powered network that provides unparalleled improvements to organizational processes:

• Transparency: any interested party can be part of the system and check the status of their assets.
• Trust: nobody can tamper with the statements.
• Traceability: ability to check the claims that an asset has received over time.
• Decentralization: no single entity owns the database; crowd-sourced contribution.
• Conflict resolution: confluence in a single view of aggregated assets that allows conflict detection at early stages.
• Efficiency: disintermediation in an interoperable solution that shares the information across all stakeholders and integrates with their back offices.

The decentralized music rights management framework is an effort to create a system that is designed and developed to enfold and also encapsulate key features of blockchain technology. Main functionalities of this framework are the creation, update and more importantly identification of conflicts in musical rights. It is important to mention that in this framework all the intelligence (program blocks) that identifies conflict and stores and updates the music rights, are strategically placed inside the blockchain through the usage of smart contracts (Figure 2). The reason behind this approach is to create a truly decentralized system that can be accessed by different stakeholders and their applications, creating a unified system that handles the chaotic nature of music rights. The distributed application (as depicted in Figure 2) is the access point to the blockchain that visually depicts all the information stored in the blockchain and allows stakeholders to handle their claim. Music claim services are the middleware which allow the distributed app to connect with the blockchain as well as with the database that contains all the metadata of the music work.

2. Related Work

Over the last few years, blockchain technology has attracted much attention as the basis of cryptocurrencies such as Bitcoin [4], but going far beyond that, it has the ability to become the new engine of growth in the digital economy, boosting the development of applications in a wide range of areas, both financial and non-financial [5]. In fact, the music industry is not an exception to this trend. In 2016 music business analyst, Stuart Dredge [6], declared that the year’s “buzz-panel of choice for any music conference is Blockchain technology,” while Lube et al. [7] stated that blockchain technology could save the music industry billions. Organizations such as Berklee’s Open Music Initiative [8] have managed to bring together almost every party in the music industry to explain the reason for exploring and getting involved with that technology [9]. Actually, the discussion whether blockchains have the full potential to radically transform the whole music supply chain towards a more distributed business model, has already started [10]. To this end, considerable research effort has been spent to investigate the usage of blockchain as a proper way to deal with critical issues related to the music industry, such as copyrights management. Keeping in mind their key characteristics, blockchains seem to be the ideal technology to assist CMOs to provide their services. Having their repositories implemented on a distributed ledger along with the creation of adequate, well-written, verified and audited smart contracts, CMOs will be able to better automate and standardize the execution of most of the copyright-related transactions, ranging from the authorization of using protected works to quick compensation to the concerned members [11].

In general, blockchain technology has been recently adopted in order to develop mechanisms for digital rights management (DRM). DRM refers to the realization of system solutions that rely on information security technology, to ensure legitimate usage of digital media content, while protecting the income of producers and owners of this content [12]. Given the features of decentralization, non-tampering, and scalability, blockchain is capable of solving a variety of existing problems related to digital copyright registration protection, which plays a major role in ensuring the rights of the original producers [13]. Xu et al. [14] proposed a DRM scheme which uses a consensus mechanism to complete copyright confirmation in real time, smart contracts to implement transactions, as well as digital signatures and hash chains to guarantee the reliability of these transactions. However, free consumption and excessive spreading without rights protection would hurt the content providers’ benefits and might cause business loss. To solve this problem, Ma et al. [15] developed a blockchain-based scheme for DRM, which supports the principle that the right content serves the right users in the right way, providing trusted and high-level credible content protection and conditional traceability of violations of the content service. In a DRM system based on blockchain, latency is also an issue, since users are facing significant delays when trying to consume media content allowed by such kinds of mechanisms. A way to address this problem is to customize the proof-of-work (PoW) algorithm of Bitcoin, properly adjusting the average interval time between the adding of new blocks [16]. Apart from technical limitations and constraints, the adoption of blockchain technology for the copyrights domain might also cause legal implications, mainly related to where the digital content itself is stored; it could be stored either on-chain, alongside metadata about ownership and transactions, or off-chain [17].

More specifically, when it comes to the music industry, various blockchain-based implementations of copyrights management can be found in the literature, which intend to improve the accuracy and availability of copyright data and consequently to make music careers more sustainable [18]. BMCProtector, for instance, uses Ethereum blockchain to protect music copyright and ensure income rights for the media content owners, also dealing with piracy issues via encryption and watermarking techniques. Through blockchain technology, musicians can easily authorize and manage their music copyright on a public ledger. The lack of intermediaries within the dissemination process enables the rights holders to receive a greater share of royalty payments automatically and immediately [19]. Furthermore, Gomaa [20] presents a digital currency on a permissioned blockchain network to enable the secure sharing and tracking of the digital content. The author suggests a DRM system to monetize, track and control online content across platforms. The goal of this system is to lower the barriers of entry for musicians, to achieve reconciliation for royalty payments between all the members of the music ecosystem (content owners, distributors and consumers) and to keep control of the content after dissemination, taking full advantage of the current advances in blockchain and cryptocurrencies technology. Moreover, Chen et al. [21] exploit the core characteristics of blockchain technology, attempting to deal with existing problems like unclear ownership and uneven distribution of music copyrights, whereas Ouyang et al. [22] have implemented a copyrights management platform that wants to solve, among other things, the issue of music plagiarism with the help of blockchain. On the other hand, Ito et al. [23] highlight that researchers and developers should put emphasis not only on the aforementioned technical features of blockchain, but also on the proper incentive design, in order for this technology to be used in the implementation of intellectual property management systems.

Towards that direction, the present article describes the implementation of an end-to-end blockchain-based framework for musical rights governance, supporting the mission of CMOs. The proposed solution includes the identification of possible conflicts caused by multiple copyright claims regarding the same music asset, while its incentive monetary mechanism tries to prevent the abusive behavior related to claims submission and thus to minimize those conflicts.

3. Alastria Blockchain Platform

Blockchain technology is positioned on the cutting edge of the technology spectrum, resulting in the creation of different types of blockchain platforms and frameworks [24]. Nevertheless, not all of these platforms can address the needs of all the use cases. As depicted in the image below (Figure 3), there are different blockchain technologies with different perspectives, especially in the subject of trust. Public blockchains have no control on who is joining the network and everything is fully transparent. This may be ideal for cryptocurrencies, but given the nature of the music industry rights management, an amount of decentralization is needed for a specific group of stakeholders. Enterprise solutions might be very trustful, but the needed decentralization for the stakeholders cannot be achieved. For these reasons the most ideal solution is placed in the middle. Permissioned private blockchains can have the needed security, trust and privacy features without compromising the needed decentralization.

The blockchain framework used in the context of the proposed framework was a Quorum blockchain deployed in the Alastria network [26]. Quorum blockchain is essentially an Ethereum network with an extra security layer [27]. This security layer can provide the needed privacy and security features in order to manage how the music stakeholders can access and operate in the blockchain. All the operations remain transparent and can be approved by the consortium by broadcasting only the hash of these transactions. Moreover this security layer can also monitor and dictate which consortium members can access and alter the smart contracts. It is important that the Alastria node provides an operational blockchain framework, which enables the testing, deployment and implementation of the aforementioned framework in a fully running blockchain network. The current implementation of Quorum in Alastria uses the Istanbul byzantine fault tolerance (IBFT) consensus algorithm, which is a variant of practical byzantine fault tolerance (PBFT) [28]. For a public-permissioned network like Alastria, IBFT seems much better suited than the current algorithms used in public-permissionless networks like PoW or even proof-of-stake (PoS). The efficiency and transaction throughput that can be achieved are much greater than with those required in public networks. In addition, transaction finality can be deterministic which is a requirement for facilitating legal commercial transactions. This higher efficiency and throughput in IBFT is achieved by using a reduced set of validator nodes, which are the ones running the consensus algorithm. These nodes are the only ones in the network that decide the blocks in the ledger and which transactions are included and in which order. The rest of the network (regular nodes), receive the blocks created by the validator nodes and apply them to the blockchain (of course, after executing and validating the transactions included in the block).

4. Application Implementation

4.1. Development Foundation

In this section, the fundamentals of the business hierarchy and the developed application modules are described in order to form a comprehensive and clear understanding of the participating entities and components. The current section is brief and it serves mainly for completeness and coherence of the whole paper.

In this decentralized application, there exist three kinds of users: Super Admins, Admins and Users. Super Admins are staff from the participant CMOs, while Admins and Users are staff from the Members affiliated to those CMOs. In the following schema (Figure 4), a clear diagram demonstrates the user hierarchy inside the application.

Inside the application, every collective management organization (CMO) can add new Members (e.g., an affiliated music rights company) through its Super Admin profile, while new participants can request to become Admins of an existing Member (to be approved by a Super Admin of its CMO or an Admin of its Member) or regular Users (to be approved by an Admin of its Member). Furthermore, the CMO has full view of Member activities through the Super Admins accounts and is able to act and make significant changes, as explained later in Section 4.3, while a Member has the ability to create, update and delete music asset claims through the appropriate Admin and User profiles. Special focus is devoted to the back-end structure and implementation of the music asset claims. A music asset claim is submitted on-chain through the dedicated smart contract and it essentially consists of the rights data which is defined by the time span, territory, rights industry type and share percentage. Ultimately, the full Solidity structure and its purpose is analyzed in Conflicting Rights Governance, Section 4.3.

4.2. Technical Architectural View

This section clarifies the complete technical architectural components connection and integration in a single system. The presented application combines, in a nutshell, an Alastria node which is part of the titular blockchain network, an external NoSQL database where the music asset data is read from through the dedicated API service, namely the Bloomen API, and the core application which associates and blends everything together.

In Figure 5, the core application, named as the Decentralized Rights Management App, is visualized together with its interaction components. The Alastria node, as explained in Section 3, allows the simple, concise and decent communication of the application with the smart contracts deployed in the Alastria blockchain. The application uses the dedicated API in order to fetch any music asset data from an external NoSQL type of database (MongoDB), when creating a new claim. Further, when users exploit the API, they are able to create claims only for the music assets included in the collections of the repertoire database they are allowed to access. The latter feature is also configured on-chain in the context of the CMOs, specifically allowing their Members to only see certain collections from the external database.

The Bloomen REST API provides RESTful services that are responsible for the efficient integration of the application layer with the blockchain. This REST API makes available to the application layer all required blockchain and off-chain functionalities, providing the Bloomen blockchain platform end-users a smooth UX experience.

The technology stack and the architecture of the Bloomen platform is depicted in Figure 6. As seen in this, the backend is split in two parts; the off-chain part and the on-chain part.

The off-chain part consists of the data storage layer controlled by a Node.js application, built with the Express.js web framework, which also exposes a RESTful API. MongoDB as an object storage, used mainly for storing the non-blockchain data, while the Apache Solr server is used as a full-text search engine. Everything in this part is hosted in Heroku PaaS on top of Amazon Web Services and, as a repository for binary files, the Amazon S3 cloud storage is being used.

The on-chain part of the backend includes the blockchain infrastructure, which is based on a Quorum instance and is running inside the Alastria ecosystem. A set of smart contracts is installed on the blockchain, written in Solidity. The communication with the blockchain is implemented in javascript with the web3.js library.

A façade layer is responsible for synchronizing the calls between the off-chain and on-chain parts of the backend. It also exposes a RESTful API to be consumed by any pilot application using the Bloomen platform, starting with the musical rights governance use case.

Regarding security, a powerful authentication mechanism has been designed and implemented by using JSON Web Token (JWT) tokens on every call, letting all transactions be stateless. Following the RESTful principles, we do not store a session for the client applications. Instead, we exchange on every request a server-signed JWT token, which is normally preserved in the browser’s local storage and is passed inside the authorisation header of the HTTP request. With the JWT token, the server side can authenticate the sender of a request and can ensure that the request is valid and authorized.

The innovation of conflicting copyright claim detection through the developed, deployed and maintained smart contracts is the pinnacle of the paper; a description of the innovation reasoning and analysis follows.

4.3. Conflicting Rights Governance

As declared in the previous sections, the conflicting musical rights governance and management happens on-chain with Solidity smart contracts leverage and control. In this section, the conflicting copyrights governance is introduced, defined and described. It constitutes the greatest portion of the application’s business intelligence, while it is developed and executed through the appropriate methods triggered inside these smart contracts.

In the context of organizing, detecting and resolving conflicting rights of contradictory assets claims, the presented solution provides a special and innovative approach. In particular, all blockchain submitted music rights claims are organized in a dedicated smart contract that defines the necessary methods that are requested to be applied on on-chain claims when called by the implemented application. This smart contract, namely Claims, illustrates every claim of a music asset in a Solidity structure (“struct Claim”) of distinct attributes, as depicted in Figure 7.

Naturally, a claim includes its status, which is either marked as claimed (where there is no disagreement on the rights declaration when compared to any other claims of the same asset) or conflict (where one or more claims declare overlapping fields in the claim declaration, and rights disagreement occurs).

Diving deeper, the claim data field, named claimData, is stored as a string pair array (NameValue type), and includes the main rights areas in which claims could be conflicted. Namely, the most common and significant rights features constitute the rights percentage split, the start and end dates of the rights, the rights territories of validity and the rights type (Figure 8). Considering that submitted assets with the same international standard code are referencing the same musical asset, both sound recording and musical works types of assets are studied here; the International Standard Recording Code (ISRC) is used for the sound recording type of musical asset and the International Standard Musical Work Code (ISWC) is used for the musical work type of musical asset.

In addition, other logistics details exist in the claim Solidity structure, such as the creation and last change dates, claim type (either sound recording or musical work), its claiming Member and its identification (unique claim id) that is regularly used on-chain to separate claims from one another. Specifically it includes creation date, claim id, claim data, claim type, user member, claim status, last change date and max split. Each one has a specific role, with some of them having major ones, when considering the whole workflow perspective of the conflicting rights governance and its procedures that are completed by respective smart contract methods.

The management and governance of the conflicting copyrights claims that were submitted to the blockchain occur mainly when calling the private method “checkClaimStatus”. This method is able to call the private mapping where the claims reside inside the smart contract. These privacy features mainly mean that the methods and mappings cannot be accessed by any other smart contract or the application directly.

The private method “checkClaimStatus” is an implemented algorithm in Solidity that receives the information of a new claim and ensures its interaction with all the relevant formerly submitted blockchain claims. In particular, if there is a new conflict, then the status of one or more claims will be updated inside this method, by accessing and modifying the dedicated claims mapping, whereas if the new claim cancels conflicting rights, then the corresponding claim status information that needs amendment is updated.

As mentioned earlier, since a claim’s data field consists of a name-value array of string couples where multiple claim information is matched with their respective value (e.g. ISRC or ISWC, start date, end date etc.), there needs to be a way inside Solidity to successfully and efficiently handle this data structure. For that reason and because the aforementioned type of structure was a necessary decision for the implementation to support in the future any type of music or other data, the Solidity RLPReader library is used. The “checkClaimStatus” method extensively uses this Ethereum RLP decoder library (RLPReader) in order to translate the imputed claim data information in an internal data structure appropriate for conversions in desired data types such as bytes, string, uint; though a further deep dive into the details of the RLPReader library is out of the scope of the paper.

Afterwards, the “checkClaimStatus” smart contract method uses the private mapping of claims to detect firstly the claims that have the same international standard code (ISRC or ISWC). For each of them, it compares their data with the input claim data and determines if between the two there is date overlap, use types overlap or right types (sound recording or musical works, respectively) and territory overlap. If there exists such an overlap, then the method executes a special code part in the smart contract which is dedicated for overlapping claims. In general, the user can try to perform create, update and delete operations on a new or existing claim when this method is called privately inside the Claims contract.

Overlapping claims management is fundamentally relevant with the max split field of a claim (uint16 maxSplit, Figure 7). In principle, a claim’s max split field indicates exactly the total sum of its own percentage split plus the percentage splits of all the claims with which it overlaps, as displayed in the diagram below (Figure 9).

If a max split of a claim is greater than 100, then the status of the claim is marked as a conflict. Otherwise, it is marked as claimed. When a pair of overlapping claims is detected, then the max split of both claims is recalculated on-chain and their corresponding statuses are updated accordingly. For instance, in Figure 10, it is made clear that two claims (Claim 2 and Claim 3) may have overlap, but their max split may not always exceed 100.

In parallel with the “checkClaimStatus” method’s max split percentage handling, the user’s claim inbox is updated accordingly through the corresponding Solidity smart contract. When new claim conflicts arrive, they are added to the user’s inbox, and when already conflicting claims are turned into claimed ones, then they are withdrawn from the inbox. These operations are executed with simplicity through the elegant interoperability of the Claims contract with the Users contract (see Section 4.4), while the first one calls the corresponding methods of the second one in order to configure the user inbox when necessary.

Conclusively, the on-chain conflicting copyrights governance of the presented application leverages the immutability and privacy protection of the permissioned blockchain in order to create a secure system where CMOs and their Members can unquestionably exchange musical rights information and store claim data under the guarantee and preservation of such a system. The whole schema can benefit and can certainly be applied to other use cases in wider and broader industries. The core evaluations of the entire system are explored in Section 5. In this paper, the presented conflicting rights governance precedes the monetary incentive mechanism, which will be analyzed in the following section.

4.4. Monetary Incentive Mechanism

In the context of a valuable application from a business standpoint, an incentive mechanism of monetary nature was built and is now described in this section. Eventually, for any user to be naturally and reasonably motivated to use the platform with rationality and accuracy, the incentive mechanism offers such a luxury in a simple structure. As analyzed in the following paragraphs, any user can create and submit all the appropriate transactions for the mechanism’s regular functionality and completion of procedures through a specific smart contract that is developed and fully related to execution of all user operations types.

In general, the Solidity smart contract that is dedicated for user account handling and management across the whole system is named “Users”. Within this smart contract, every user is represented on-chain and can submit all that is permitted by the system transactions, in consideration of their type, which is either Super Admin, Admin or User. For instance, an Admin of a Member can create a new claim by submitting a new transaction or they can delete an existing one.

The monetary incentive mechanism introduces a simple way of dealing with any kind of user initiated claim transaction by defining a user token balance. When a user tries to submit a new transaction and he/she simultaneously has enough balance, then the transaction is submitted and it costs the user exactly the transaction price amount, which is then subtracted from their total tokens. Any claim transaction for creation, update or deletion has a certain transaction price cost. In this framework, the already legally and transparently accepted users are incentivized to carefully make use of their account when managing claims.

Furthermore, the token balance property is only set for the Admin and User types of users. In this application version, no user balance is set out for Super Admins since the Super Admin type of user is not eligible to submit claim related transactions. Super Admins, as CMOs’ main users, incorporate an important role in the entire scenario as they are able to regulate the claim submission power of their Members, as explained below.

In order to increase the overall value and significance and create a complete and concise system, the mechanism determines that each Member company is allowed only to use a certain amount of tokens. This amount is elegantly distributed across its existing and new users. When a Member exhausts its token balance, then its CMO is able to increment it through a Super Admin user. Mainly, the Super Admins (as CMO representatives) are qualified to adjust the token balance of a Member in order to provide transactional value to its plethora of users.

The main purpose of the incentive mechanism’s construction and cohesion is ultimately to minimize mistaken user actions or claim submission application abuse. For instance, accidental claim deletion or unwise claim creations and updates are prevented. In a broader scope, unnecessary network congestion is avoided while overall transactional value and user experience is increased and enhanced. Finally, CMOs, as being top of the business hierarchy, are judicious and sensible in this kind of topic and create a worthy overall system value.

4.5. Source Code

The application’s complete source code can be found in GitHub with the appropriate installation instructions:

https://github.com/bloomenio/bloomen-decentralized-rights-management-v2.

5. Evaluation of Music Rights Framework

In this section, the entire reasoning of the framework is specified and afterwards the results of a batch claim upload assessment are outlined.

State-of-the-art music industry copyrights management applications and platforms approach the copyrights governance process with centralized systems that offer distributed replication database servers for fault tolerance and high availability. Thus, each stakeholder business actor utilizes their own database, whereas it is possible that a small number of distinct actors operate under the same technological components. However, the entire music industry stakeholder ecosystem (Figure 1) utterly suffers from diversity, considering the technologies applied to storing, retrieving and processing data. The dissimilar database systems endorse different ways of organizing information, i.e. data format, database type, and query syntax. In this context, data sharing between the stakeholder business actors usually constitutes a challenging procedure while it is one of the main reasons for the GRD’s failure constitutes the number of different sources from which data would arrive [1]. The music rights framework resolves this diversity problem by exploiting blockchain infrastructure. The presented framework provides a single network inside which all information is securely stored and shared among the selected actors that are approved to participate. As already stated, this framework, through its dedicated smart contracts deployed in the quorum-based permissioned blockchain network, offers data transparency, traceability and decentralization along with participant trust and claim conflict resolution in an efficient system. Moreover, data immutability is guaranteed through blockchain immutable transactions, while centralized storage risks of data protection and cyber-security attacks are eliminated. It is important to clarify in the current use case that the perception that the blockchain ledger is presented as a database replacement is only valid in the context of storing relatively small amounts of data on a Solidity structure. Each claim is represented mostly by its metadata (Figure 7), using an accepted data amount to store on-chain. Blockchain is not suitable for depositing larger files, such as e.g. multimedia ones. Ultimately, the music industry ecosystem functioning under the proposed framework would provide its stakeholder business actors a privately shared and secure network inside which music copyright governance, from assessment of ownership to royalty distribution and copyright validation, would occur with ease, data availability and protection and privacy. In the rest of the section, the analysis results of a batch claim upload experiment are reported.

In order to test how the system is going to react under a demanding load, batch files were created in a CSV format; the files contained a series of claims in order to be processed by the system and then to be stored on the blockchain. The batch files varied in sizes (from 100 claims to 10,000 claims) in order to examine the responsiveness of the systems for different rates of claim creation. For the evaluations two graphs are presented, the first one (Figure 11) depicts the time needed in seconds to process the different sized batch files, while the second graph (Figure 12) depicts the average time needed by the system to process a claim.

Given the fact that there are limitations in the block creation containing the transactions (claims), and the claims are processed in a serial way, the time needed to process the claims is relatively good. Although the system needs roughly 10 hours to process 10,000 claims, which is not an extreme claim load in the music industry, the system enables the identification of conflicts in less than a day, which is a huge improvement given the current landscape. In a production version of the system the claims can be stored in batches and not linearly; such an approach is used in production blockchains such as Bitcoin and Ethereum which handle millions of transactions per day.

It is also important to mention that the average time needed to process a claim remained stable (around 3.7 s) in all the runs with the different work loads (number of claims). This indicates stability in the system and no underlying bottlenecks. In this graph (Figure 12) a spike can be identified in the small batch files (3.9 s); this spike is produced due to latency in the initialization of the communication with the blockchain. This latency is smoothed out when the number of claims increases.

6. Conclusions

The current study presents a complete and effective application for copyrights management that relies on quorum permissioned blockchain. In the music industry, where diverse roles and actors have to coordinate their efforts for identifying and managing copyrights and conflicting situations on music assets rights, blockchains can be an effective solution, as these can offer an untampered ledger of claims that can be sustained without the need of a third party entity. The proposed implementation couples various and distinct business domains across the music industry organizations and non-profit blockchain associations. The current work presented in this paper successfully combines blockchain and smart contracts with rights management, in order to introduce a novel decentralized framework that contributes to the solution of the specific issue faced by the music industry actors and the CMOs in particular. Exploiting fundamental blockchain principles such as transparency, trust, traceability and decentralization, an effective approach to solve existing issues faced by CMOs is presented. The proposed solution utilizes a permissioned private Quorum blockchain deployed in the Alastria network, that interacts with other dedicated created APIs, tools, components and traditional database solutions, and comprises a single system based on a decentralized architecture. Using its features, we presented the efficiency of smart contracts to model and resolve conflicts in the music rights domain. The specific solution has been piloted and validated in the frame of the Bloomen project.

7. Future Work

Regarding future extensions of our proposed system, we are currently working on designing an extension of our approach enabling automatic resolution of rights. In this direction, we are examining the potential of the application to store rights using a decentralized approach based on IPFS, enabling smart contracts to read rights from IPFS when filling a new claim, and using blockchain to decide which of the conflicting claims are legitimate and which violate rights. The addition of more features is examined, such as the adjustment of rights according to the underlying blockchain technology and support of more elaborate informing mechanisms for the end user of the system, who will be able to better trace the different steps of flow of the conflict resolution. Moreover, it is left for future research work to enrich the smart contracts with additional features to optimally interact with external data sources (containing media items and metadata) and algorithms for music asset identification so as to have an overall solution for monitoring the use of the specific music items in the various distribution channels and geographical regions, so as to further extend the capabilities of such tools for the CMOs.