System and method for scalable tracking of media playback using blockchain

Abstract

To provide a reliable content identification method and a system for allowing anyone to register, identify and track creative works on the Internet.SOLUTION: A method for tracking media file playback comprises: receiving a request to upload a media file and metadata associated with the media file; uploading the media file and the metadata via a blockchain protocol; receiving a request to play the media file from a client device or a digital service provider (DSP) platform; validating the request to play the media file via the blockchain protocol; upon validating the request to play the media file, transmitting the media file for playback at the client device or the DSP platform; and tracking the number of times the media file is played via the blockchain protocol.SELECTED DRAWING: Figure 9

Description

Related Applications

[0001] This application claims the benefit of U.S. Patent Application No. 16 / 457,663 (Reference No. BTPPP001), entitled "System and Method for Scalable Media Playback Tracking Utilizing Blockchain," to Batey et al., filed June 28, 2019, which is incorporated herein by reference in its entirety for all purposes. [Technical Field]

[0002] FIELD OF THE DISCLOSURE This disclosure relates to tracking digital media, particularly streaming media. [Background technology]

[0003] The music industry generates an estimated $25 billion in revenue based on royalties. With the advent of the internet, streaming technology has made it easy for listeners to listen to almost any song they choose. Artists typically work with music labels to distribute their media and help them collect revenue based on royalties. These music labels distribute their media through various mediums, including streaming platforms and digital service providers (DSPs) such as Spotify and Apple.

[0004] While access to music has been facilitated by DSPs, tracking all streamed songs or the volume of plays of specific songs has become an increasingly difficult problem to solve. Consequently, 25% of activity on streaming platforms today is unlicensed. Furthermore, even for licensed activity, up to 15% of total annual royalties remain uncollected. DSPs claim they lack the necessary data and technology to help them understand whose claims are legitimate, or even how to locate specific parties. Furthermore, the lack of a reliable database covering all existing music rights only adds to the problem. Therefore, there is a need for reliable content identification technology that allows anyone to register, identify, and track creative works on the internet. Summary of the Invention

[0005] The following presents a simplified summary of the disclosure in order to provide a basic understanding of certain embodiments of the disclosure. This summary is not an extensive overview of the disclosure and does not identify key elements or delineate the scope of the disclosure. Its sole purpose is to present some concepts disclosed herein in a simplified form as a prelude to the more detailed description that is presented later.

[0006] Aspects of the present disclosure relate to systems and methods for tracking the playback of media files using blockchain. First, a request to upload a media file and metadata associated with the media file is received. Next, the media file and metadata are uploaded via a blockchain protocol. Next, a request to play the media file is received from one of a digital service provider (DSP) platform or an end user's device. The request to play the media file is validated via the blockchain protocol. Upon validating the request to play the media file, the media file is sent for playback on the client device or DSP platform. Finally, interactions with the media file are tracked via the blockchain protocol.

[0007] Additional advantages and novel features of these aspects will be set forth in part in the description that follows, and in part will become apparent to those skilled in the art upon examination of the description and practice of the disclosure. [Brief explanation of the drawings]

[0008] The present disclosure is best understood by referring to the following description in conjunction with the accompanying drawings, which set forth specific embodiments of the disclosure. In the following description, like parts are referred to throughout the specification and drawings by the same respective numerals. The figures are not necessarily drawn to scale, and certain figures may be shown in exaggerated or generalized form for clarity and conciseness. [Figure 1] FIG. 2 is an exemplary diagram of available user type relationships, data, and functions in the disclosed system, according to an embodiment of the present disclosure. [Figure 2] 10 illustrates an exemplary latency analysis from a song play request to providing fingerprinted content, according to an embodiment of the present disclosure. [Figure 3] 1 illustrates an exemplary diagram of sharding according to an embodiment of the present disclosure. [Figure 4]FIG. 1 is a diagram of an example of how the music industry may be combined according to an embodiment of the present disclosure. [Figure 5] FIG. 1 is a diagram of an example of a basic administrator role according to an embodiment of the present disclosure. [Figure 6] FIG. 2 is a diagram of an example of a basic data flow for an end user according to an embodiment of the present disclosure. [Figure 7] 1 is a diagram of an example media file playback tracking network according to an embodiment of the present disclosure. [Figure 8] 1 is a system diagram of an example system for tracking the playback of media files according to an implementation of the present disclosure. [Figure 9] 1 is a flowchart of a method for tracking the playback of a media file according to an embodiment of the present disclosure. [Figure 10] 1 illustrates an example computer system according to an embodiment of the present disclosure. [Figure 11] 1 illustrates an example of a linked list data structure according to an embodiment of the present disclosure. [Figure 12] 1 illustrates a conceptual example of a blockchain, according to an embodiment of the present disclosure. [Figure 13] 1 illustrates an example of Merkle generation of a portion of a platform dataset, according to an embodiment of the present disclosure. Detailed Description

[0009] Reference will now be made in detail to some specific examples of the present disclosure, including the best mode contemplated by the inventors for carrying out the disclosure. Examples of these specific embodiments are illustrated in the accompanying drawings. While the present disclosure will be described in conjunction with these specific embodiments, it will be understood that it is not intended to limit the disclosure to the described embodiments. On the contrary, it is intended to cover alternatives, modifications, and equivalents which may be included within the spirit and scope of the disclosure as defined by the appended claims.

[0010] For example, the techniques of this disclosure are described in the context of media file transmission, encryption, data storage, and media access verification. However, it should be noted that the techniques of this disclosure apply to a wide variety of network transactions, collaborative environments, data structures, and different types of data. In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present disclosure. Certain illustrative embodiments of the present disclosure may be practiced without some or all of these specific details. In other instances, well-known process operations have not been described in detail in order to avoid unnecessarily obscuring the present disclosure.

[0011] Various techniques and mechanisms of the present disclosure may be described in the singular for clarity. However, it should be noted that some embodiments include multiple iterations of a technique or multiple instantiations of a mechanism unless otherwise specified. For example, a system may use one processor in various contexts. However, it should be understood that a system may use multiple processors while remaining within the scope of the present disclosure unless otherwise specified. Furthermore, the techniques and mechanisms of the present disclosure may describe a relationship between two entities. It should be noted that a connection between two entities does not necessarily imply a direct, obstruction-free connection because various other entities may exist between the two entities. For example, a processor may be connected to a memory, but it will be understood that various bridges and controllers may exist between the processor and the memory. Thus, unless otherwise specified, a connection does not necessarily imply a direct, obstruction-free connection.

[0012] As used herein, the term "platform" refers to the platform systems and methods disclosed herein. Throughout this disclosure, the terms "platform" and "system" are used interchangeably. According to various embodiments, a blockchain music platform is provided. In some embodiments, a blockchain is defined as a decentralized, secure, and immutable digital ledger or database that keeps a permanent record of all transactions. In some embodiments, the blockchain ledger contains "smart contracts," which define the terms and costs of blockchain transactions. In some embodiments, smart contracts can be modified, but all previous versions remain on the blockchain. With a complete history of transactions and changes to smart contracts, blockchain technology is inherently more transparent and secure than current systems of closed contracts and databases.

[0013] In some embodiments, a blockchain music platform allows users to upload media files, e.g., songs, along with associated metadata to a server or database. In some embodiments, when a request to upload a song is received, a blockchain transaction for the song is created and stored on the blockchain. In some embodiments, data such as song details, content access details, and stakeholder interests, as well as hundreds of other potential metadata fields, are also stored on the blockchain. In some embodiments, to ensure that data is immutable and the network is secure, transactions on the blockchain need to be validated before they are finalized. In some embodiments, validation occurs only after at least two or more transaction validators (sealers), or authorized / trusted validating nodes, can validate the transaction.

[0014] In some embodiments, the system does not use tokens because the data storage needs are too great to practically support media streaming for a large number of users, however, in other embodiments tokens can be created and used in payment transactions.

[0015] In some embodiments, transactions are verified using the Proof of Authority (PoA) consensus algorithm. In other embodiments, transactions are verified using the Proof of Work (PoW) algorithm. However, according to various embodiments, PoA works better for the disclosed systems and methods for the following reasons. First, with PoA, only certain parties can verify transactions on the blockchain. The nodes authorized to seal blocks or verify transactions and who can identify the parties to which they belong are predefined, reducing the time required for verification. Second, PoA transactions can be finalized as soon as they are processed by the blockchain. This is because authorized sealers can cryptographically verify transactions. Therefore, blocks can be added to the blockchain in any order, as long as they are valid. Therefore, another consequence of PoA is that valid blocks are not rejected solely by the blockchain's mechanisms, resulting in the removal of "uncle blocks" or "orphaned blocks." Third, the transaction throughput of a PoA implementation is limited only by the hardware on which it runs. Thus, the disclosed system can accommodate millions of transactions per second. In contrast, for PoW implementations, transaction throughput is mostly limited by the difficulty of the proof-of-work required by the protocol. Finally, because the identities of nodes are known, PoA is not susceptible to Sybil attacks.

[0016] In some embodiments, the PoA consensus algorithm uses the following formula to determine which nodes are allowed to seal the next block: (Number of consecutive blocks addressed per sealer) = (floor(number of sealers / 2) + 1)

[0017] In other embodiments, transactions are verified and sealed by the first two available sealers to ensure rapid availability of content. In some embodiments, block proposals are not used. In such embodiments, when a song or media file is requested by a client device, a short buffer of the song or media file is immediately sent or streamed. However, the entire song or media file is not piped to the client device until the transaction is completed on the blockchain, typically within one second. In some embodiments, playback of a media file is not reported to an account until a predetermined amount of content has been played by the end user. Thus, if the end user does not consume the content for a predetermined time, playback initialization occurs and some content may be streamed to the end user, but the end user did not consume a sufficient amount of content, so a playback event is not sent to the blockchain.

[0018] According to various embodiments, billions of transactions can occur on the blockchain every hour. As a result, a large amount of data can be stored on the blockchain. Therefore, if every node were required to have the complete history of the blockchain, controlling storage costs might become impractical. Therefore, in some embodiments, various different, compatible versions of the blockchain client are created. In such embodiments, "lighter" clients would have the same functionality as regular blockchain clients. However, these clients do not need to include all of the past blockchain history to perform certain tasks, such as validating transactions. Thus, in some embodiments, light clients do not need to download a portion of the blockchain history. In some embodiments, a sealer only needs to download the header of the most recently sealed block to begin validating transactions. In some embodiments, a sealer is only responsible for verifying cryptographic signatures and does not require the history of events on the blockchain. For "heavy" clients, data on the blockchain is pruned using block headers as references. In some embodiments, lighter clients can hash data using a Merkle tree and store the root to reduce storage space requirements. However, in some embodiments, a party has the option to run a full node to have a copy of the entire blockchain. In some embodiments, a party can choose to keep blockchain data directly on the node or offload the data to a separate storage solution.

[0019] According to various embodiments, different parties involved in the platform will require different digital infrastructure. For example, DSPs and music labels may want to participate in securing the network using the platform's consensus protocol. However, different parties are free to create their own blockchain clients as long as they comply with the platform's consensus protocol specifications.

[0020] In some embodiments, a node can be implemented by a single computer. In some embodiments, a node can be implemented across an array of computers. The choice of architecture for implementing the nodes can include the use of load balancers or serverless technologies. The main requirement for each node is that it must represent an identity, possibly represented by one or more public keys registered to the participant's identity.

[0021] In some embodiments, the servers of the platform provide more services than simply participating in a network. In some instances, the servers are responsible for serving digital media content directly to listeners via a content delivery network (CDN). In such embodiments, the platform uses an anycast approach using nginx to a distributed set of content servers. In such embodiments, each time a file is served, it is also fingerprinted with a transaction hash or other identifying information.

[0022] In some implementations, DSPs will be required to modify their client-side applications. For example, a DSP may have a separate endpoint for each song on their platform. Therefore, the DSP will need to change the endpoint that currently serves the file to one that makes a request to the blockchain network. Once the request is validated, the CDN will pipe the complete song file to the user.

[0023] In some embodiments, to cryptographically verify that a user has performed a particular action, the blockchain protocol utilizes the Elliptic Curve Digital Signature Algorithm (ECDSA). In such embodiments, the end user must create a signature each time a request is sent. Therefore, the DSP must provide the listener (either on the client's device or using the DSP's own server) with a cryptographic key pair.

[0024] According to various embodiments, several methods for scaling are provided for the large number of transactions per second processed by the DSP. In some embodiments, a consortium blockchain is implemented instead of a public blockchain. When building a consortium blockchain, PoA is used. Transaction validators can quickly approve requests by staking their identity / reputation, and are constrained only by their own hardware and internet infrastructure.

[0025] In some embodiments, it is not feasible to use a single blockchain to record transactions that occur across the entire network. In some embodiments, the blockchain may be divided into geographic shards. For example, one shard may serve North America and another shard may serve London. In some embodiments, including other embodiments described in this disclosure, the blockchain may be divided by label-DSP relationships. For example, a shard may be between StreamCo and label A, and StreamCo may have another shard at label B. In such embodiments of relationship sharding, participants cannot access data from relationships to which they do not belong.

[0026] In some embodiments, each participant in the blockchain network is required to run a minimum number of nodes spread across the globe. Therefore, the platform's boot nodes use a routing algorithm to geographically group sealers. In some embodiments, when a shard is spawned from the main chain, it is periodically merchandized and a root hash is obtained and stored on the main chain. Periodically, or when a shard is closed, its history is added to the main chain. In some embodiments, in the unlikely event of a dispute on a shard, the most recent cryptographically provable data is used as the truth. In some embodiments, end users are assigned or not assigned from a geographic shard depending on the request made on the main or DSP-label related shard. In some embodiments, once a user is assigned to a particular shard, they cannot make requests on another shard within the same DSP-label related shard.

[0027] In some implementations, off-chain scaling can be incorporated into the protocol. For example, state channels, child chains, or sharding chains can all be used in the consensus protocol. The following example shows one way to incorporate off-chain scaling. In this example, the platform's sharding implementation uses main chain transactions to open relationships. Note that all media plays are counted, not just the final result of the state channel.

[0028] Example: Alice opens her music application to play music from a DSP. Alice is assigned to an appropriate geographic shard of the DSP (either existing or newly created, if resources are available). Alice can now stream any amount of media content without stressing the main chain. Each stream request is signed by Alice using her private key and can be verified by any sealing node using her public key.

[0029] Looking at the following use case for her music application, those skilled in the art can see how sharding improves performance: Alice requests to play a song by cryptographically signing the request. Before the platform CDN streams the music to Alice, the request is verified by at least two sealers. The call to the song's address is recorded on the shard's blockchain. The difference between this method and traditional blockchain calls is that the request is not immediately committed to the main chain. At arbitrary intervals during the song's runtime, a request is automatically made from the client in the shard to retrieve the next part of the song the user is listening to. The data is piped into chunks to track playback data. If there is a transaction not signed by Alice or if there is a dispute about the number of songs Alice played, the latest cryptographically provable data is sent to the main chain. The shard then continues or closes, and the main chain reallocates all active users in the shard. If Alice has not listened to music for an arbitrary set amount of time (defined when she joined the shard), she is unassigned from all shards.

[0030] In some embodiments, every song streamed from one of the platform's CDNs is stamped to allow the original streamer of the content to be identified. In some embodiments, the entire fingerprinting process is split into two main components: stamping (applying a fingerprint to the track) and scraping (finding the originally played track from the platform's CDN and identifying how the content was leaked). In some embodiments, the fingerprinting method must remain secret to ensure that malicious attackers cannot attempt to remove or distort the identifying fingerprint.

[0031] In some embodiments, minimal user data can be hidden within data being transmitted to a user by stamping the file using digital steganography. Each time a song is streamed or downloaded, an invisible "watermark" can be written to the file. Using digital signal processing, an algorithm can write or identify a portion of the digital content that is common to all files of that format. For example, all mp3 files have a point in the song that is lower in pitch than all other parts of the song. The common points in the songs can be added to create an encrypted digital fingerprint of the user.

[0032] In some implementations, the stamp recognition software extracts a digital fingerprint by using digital signal processing to deconvolve the original uploaded file from the file scraped from the web. If a digital fingerprint is found, it can be decoded and traced back to the user and playtime. In some implementations, scraping fingerprinted content can be broken down into three main steps: 1) building a web crawler for common piracy / streaming sites; 2) extracting and caching audio files. This step requires a custom solution for scraping each streaming / download site; and 3) running the cached audio against the stamp recognition software.

[0033] According to various embodiments, the disclosed systems and methods enable verification of media file catalogs, ownership, and payment details. In some embodiments, the system also enables payment generation and accounting. In some embodiments, the system also enables the correct amount to be deposited in the correct account. In some embodiments, the system provides fair, transparent, auditable, and near real-time payments to creators (artists), labels, and distribution platforms of musical works and sound recordings. Furthermore, in some embodiments, the system provides real-time compliance and audit mechanisms.

[0034] 1 shows an exemplary diagram of the relationships, data, and functions of several available user types in the disclosed system, according to an embodiment of the present disclosure. In some embodiments, based on the user's role, the user has different responsibilities for the disclosed platform. In FIG. 1, every user 106 can create their own cryptographic key pair for signing data and verifying signatures against given data and public keys.

[0035] In some embodiments, the label 102 is responsible for uploading song and album metadata to the platform. In some embodiments, the label can further approve songs in its catalog for distribution by the DSP. In some embodiments, a label administrator prepares a song or album for the platform by filling out the necessary metadata, uploading the song files, and assigning stakeholder shares. Upon receiving a valid upload request from the label account, the entry is broadcast to the blockchain. Once the artist is credited with the song, the artist has the option to approve the song, which makes it available to DSPs on the song's release date.

[0036] In some embodiments, uploaded songs are maintained on a media server and are only accessible by users who have made a cryptographically valid request to the blockchain to access the content. In some embodiments, an administrator can use a platform web product to view analytical data about song plays. In some embodiments, the administrator can categorize the data by request, allowing them to track how users are engaging with the content.

[0037] In some embodiments, once the artist 104 receives a contract offer from the label 102, the artist 104 may accept to be added to the label 102. In some embodiments, the artist 104 may not be assigned to a label. In such embodiments, the artist 104 may function as its own label on the platform. When the label 102 uploads a song, it is unconfirmed until the credited artist 104 approves the upload. The artist 104 may view play data for their own song via the platform, but is restricted from viewing that of their colleagues.

[0038] In some embodiments, the stakeholders 108 for each song are determined before it is finalized on the blockchain. In some embodiments, a percentage of the revenue for each song is allocated to the stakeholders 108. In some embodiments, the stakeholders 108 can view data about the songs in which they own a portion.

[0039] In some embodiments, end users 106 are given access to songs thanks to the DSP 110. Most DSPs 110 use a subscription model, allowing users 106 to listen to any song on the DSP's platform for a set period of time. In some embodiments, the proposed changes that existing DSPs need to make to their systems to take advantage of the platform's technology are minor.

[0040] In some embodiments, users 112 of the DSP's application should not perceive any difference when streaming songs. Instead, the DSP 110 that created the end user is responsible for managing the user's keys. It is up to the DSP whether they sign requests using their own server or client application.

[0041] In some embodiments, latency issues arise when nodes are not close enough together, meaning that the latency between two nodes increases as the distance between them increases. Leveraging geographic sharding of child chains reduces signal travel time. Figure 2 helps investigate latency in blockchain networks. Figure 2 illustrates an example latency analysis from a song play request to providing fingerprinted content, according to an embodiment of the present disclosure. The latency 200 can be divided into several steps, some of which are performed in parallel.

[0042] At 202, a song is requested for playback. In some embodiments, when an end user plays a song, the request is sent to two primary locations: the user's assigned blockchain shard and the CDN. At 204, a fingerprinted file is prepared. Steps 206 and 208 handle sealing the request. In some embodiments, the first two of three distinct parties for validating the request signal that the transaction is sealed. At 206, the request is validated by the first node. At 208, the request is validated by the second node. Not visualized here is a third node that is slower than the other two nodes, 206 and 208, in validating the incoming playback request. This slower node does not need to seal the playback request, although it may eventually attach a cryptographic signature to the playback event. At 210, the content is provided to the user. In some embodiments, the server pipes a digital media file to the user. As a result of the path outlined in Figure 2, the following expression can be written for a successful file response: t latency =max(t client CDN , t client Node1 , t client Node2 )+max(t prep file +t Node1 CDN , t Node2 CDN )+t serve file

[0043] In some embodiments, data privacy is important. According to various embodiments, there are two ways that DSPs and labels can prevent competitors from viewing analytics data: 1) multi-tier sharding, and 2) zero-knowledge proofs.

[0044] 3 shows an example diagram of multi-tier sharding according to an embodiment of the present disclosure. Figure 3 shows a main chain 302, relationship shards 304 and 308, and geographic shards 306 and 310. In some embodiments, each label-DSP relationship is grouped into its own shard 304 or 308.

[0045] In some embodiments, zero-knowledge proofs are also used to ensure data privacy. Zero-knowledge proofs allow network participants to cryptographically verify transactions without revealing the data within the transaction. In some embodiments, data written to the chain must use one-way encryption, which ensures that all data on the chain is readable only by parties who have the key to decrypt the data. In some embodiments, the decryption key for each participating shard is shared between the DSP and the label.

[0046] Although in some embodiments, platform ownership of the servers for the CDN requires minimal trust between the label and the DSP, alternative tracking methods are available. For example, the platform could create a software development kit (SDK) or library that runs on the DSP's application. In such an example, the primary purpose of the SDK is to provide the DSP with the appropriate encryption algorithms used to sign and verify transactions. In some embodiments, the DSP needs to provide periodic or triggered reports with playback event data and their associated signatures. In some embodiments, the platform deploys an audit system that ensures the system creates end-user accounts on the streaming platform and that playbacks are counted according to the protocol. In some embodiments, the benefits of using an SDK include the fact that the DSP is content to retain the content. In some embodiments, the disadvantages of this method include the fact that the DSP still controls the content on their servers and the label can only verify the numbers by conducting private audits of the DSP. In some embodiments, the platform would have to write plugin implementations for each of the DSP's interfaces (web, mobile app, desktop app).

[0047] In some embodiments, another alternative tracking method involves encrypted codecs. In such embodiments, the platform can create a custom file type to encrypt the file each time it is accessed. In some embodiments, the DSP can maintain the encrypted file on their own server. This encryption method can capture a signed request by the user to decrypt the file. In some embodiments, advantages of this method include the fact that offline interactions can be taken into account in an untrusted manner. In some embodiments, another advantage is the possibility of covertly stamping the user's data into the file at the decryption step. In some embodiments, yet another advantage includes the fact that the DSP is happy to retain the content. In some embodiments, disadvantages of this method include the fact that it requires talent to research and implement new standards. In some embodiments, another disadvantage includes the fact that there is still a vector for stealing the content of the file by accessing the cache of the device on which the content is being played. In some embodiments, yet another disadvantage is the fact that the DSP must implement the codec standard proposed by the platform.

[0048] Figures 4-10 are illustrated to provide more context to the music industry and the role that platforms (and the disclosed systems and methods) play in music licensing and streaming.

[0049] FIG. 4 illustrates a diagram 400 of an example of how the music industry is connected, according to an embodiment of the present disclosure. In FIG. 4, a composer 402 assigns copyright to a musical work to a publisher 404. The publisher 404 then grants a performance license to a performing rights organization (PRO) 428. The PRO 428 issues blanket licenses to radio / TV 424, stadiums 422, and DSPs 418. The publisher 404 also grants a reproduction license to a sheet music printer 406, a sub-publishing license to a foreign publisher 408, a synchronization license to a movie studio 410, and a mechanical license to a record company 412. In some embodiments, the mechanical license goes through the Harry Fox Agency 416. The record company 412 also receives assignment of sound recording copyright from a performer 420 and then provides sound exchange 414 with a DSP 418.

[0050] 5 illustrates an example diagram 500 of basic administrator roles according to an embodiment of the present disclosure. First, an admin dashboard 512 sends a song creation request 502 to a server 504. Next, the server 504 creates a contract 506 on a blockchain 508.

[0051] 6 shows a diagram 600 of an example of a basic data flow for an end user, according to an embodiment of the present disclosure. Diagram 600 begins with a client application 612 sending a song play request 602 to a platform CDN server 614, a blockchain 608, and a DSP authorization server 616. The DSP authorization server 616 then communicates 604 to the blockchain network 608 that the user is indeed authorized to access to the specified resource. The blockchain 608 then broadcasts to the client application 612 that play is ready to be initiated by the CDN 614. Finally, the platform CDN server 614 provides 610 the content to the user.

[0052] FIG. 7 shows a diagram 700 of an example media file playback tracking network according to an embodiment of the present disclosure. A DSP 702 sends a content request 704 to a blockchain network 706. The blockchain network 706 then validates the request 716. After the request is validated and deemed sealed, a CDN 720 provides the content 718 to the DSP 702 or the DSP's end user who made the original playback request. Validated transactions are archived in a data storage solution 710 for later inspection or auditing. Periodically, or upon specific events, a segment of blockchain data is extracted to its Merkle root hash 714, and the root hash is written to a third-party blockchain network 712. The mechanism for writing to an external blockchain is further described in FIG. 13.

[0053] FIG. 8 shows a system diagram of an example system 800 for exchanging information in a network environment, according to some implementations. System 800 includes various different hardware and / or software components in communication with one another. In the non-limiting example of FIG. 8 , system 800 includes at least one system server 804 and at least one client device 808. In some embodiments, system 800 includes at least one digital service provider (DSP) 880. In some embodiments, system 800 also includes a music label 882 and / or at least one artist 886. In some embodiments, music label 882 represents and uploads music from artist 886, although sometimes artist 886 does not have a record label, and therefore, in many cases, client device 808 uploads music directly to system server 804. System 800 enables system server 804 to assist in tracking songs being streamed at client 808 via DSP 880.

[0054] The system server 804 can communicate with other components of the system 800. This communication can be facilitated via a combination of networks and interfaces. The system server 804 can handle and process data requests and data transfers from the client devices 808 (in the case of a direct content delivery model) and the DSPs 880. Similarly, the system server 804 can return responses to the client devices 808 after the data requests have been processed. For example, the system server 804 can retrieve data from one or more databases, such as music labels 882 or artists 886. It can combine some or all of the data from the different databases and send the processed data to one or more client devices or DSPs.

[0055] The client device 808 and the DSP 880 may be computing devices capable of communicating with a server over one or more data networks. Examples of the client device 808 and the DSP 880 include desktop computers or portable electronic devices such as smartphones, tablets, laptops, wearable devices, optical head-mounted display (OHMD) devices, smart watches, and separate servers. The client device 808 and the DSP 880 include at least one browser onto which applications may be deployed.

[0056] Music labels 882 may be a database implemented in a relational or non-relational database management system, which in some embodiments may contain the contents of one or more client-related databases in a network environment.

[0057] Artists 886 may be individual artists not associated with a record / music label, or artists who are associated but have special needs not met by a music label. In some embodiments, communications with artists 886 may include edits, modifications, and / or tracked change information related to songs, albums, or any other streaming media associated with the artist.

[0058] FIG. 9 shows a flowchart of a method 900 for tracking the playback of a media file according to an embodiment of the present disclosure. The method 900 begins by receiving a request to upload a media file and metadata associated with the media file (902). Next, the media file and metadata associated with the media file are uploaded via a blockchain protocol (904). At 906, a request to play the media file is received from a client device or a digital service provider (DSP) platform. At 908, the request to play the media file is verified via the blockchain protocol. At 910, upon verifying the request to play the media file, the media file is transmitted or streamed for playback on the client device or DSP platform. However, to keep latency low, a small portion of the beginning of the media file may be streamed to the end user before the request is verified. Finally, the number of times the media file has been played to a predetermined length is tracked via the blockchain protocol (912).

[0059] In some embodiments, the blockchain protocol utilizes a proof-of-authority algorithm. In some embodiments, validating the request includes cryptographically verifying the request by two authorized sealers from a plurality of sealers. In some embodiments, the request to play a media file includes a request to the blockchain to access the content at a specified time. In some embodiments, requests to the blockchain can be finalized as soon as they hit the blockchain, thereby allowing them to be added to the blockchain in any order. In some embodiments, a short buffer of a media file is streamed immediately after receiving a request to play the media file, while the remainder of the media file is streamed only after the play request is validated. In some embodiments, different versions of the blockchain client can be used for different clients, assuming they follow platform protocol rules.

[0060] Various computing devices can implement the methods described herein. For example, a mobile device, a computer system, or the like can be used to access aspects of a network environment, either by a client, a music label, or a DSP. Referring to FIG. 10 , a specific example of a computer system that can be used to implement certain examples of the present disclosure is shown. For example, a computer system 1000 can be used to generate artificially rendered images according to various embodiments described above. Furthermore, the computer system 1000 shown here can represent a computing system on a mobile device. According to certain exemplary embodiments, the system 1000 suitable for implementing certain embodiments of the present disclosure includes a processor 1001, a memory 1003, an interface 1011, and a bus 1015 (e.g., a PCI bus). The interface 1011 can include separate input and output interfaces 1013 and 1015, or can be an integrated interface that supports both operations. When operating under the control of appropriate software or firmware, the processor 1001 is responsible for tasks such as optimization. Various specially configured devices can also be used in place of or in addition to the processor 1001. The complete implementation may also be done in custom hardware. The interface 1011 is typically configured to send and receive data packets or data segments over a network. Specific examples of interfaces that the device may support include an Ethernet interface, a Frame Relay interface, a Cable interface, a DSL interface, a Token Ring interface, etc.

[0061] Additionally, various very high speed interfaces may be provided, such as a Fast Ethernet interface, a Gigabit Ethernet interface, an ATM interface, an HSSI interface, a POS interface, an FDDI interface, etc. Generally, these interfaces may include ports suitable for communication with the appropriate media. In some instances, a separate processor may also be included, and in other instances, volatile RAM may also be included. The separate processor may control communication-intensive tasks such as packet switching, media control, and management.

[0062] According to certain example embodiments, system 1000 uses memory 1003 to store data and program instructions and to maintain a local side cache. The program instructions may, for example, control the operation of an operating system and / or one or more applications. The one or more memories may be configured to store received metadata and batch requested metadata.

[0063] This disclosure relates to tangible, machine-readable media containing program instructions, state information, etc. for performing various operations described herein, as such information and program instructions can be used to implement the systems / methods described herein. Examples of machine-readable media include hard disks, floppy disks, magnetic tape, and optical media such as CD-ROM disks and DVDs. These include magneto-optical media such as optical disks, and hardware devices specially configured to store and execute program instructions, such as read-only memory devices (ROM) and programmable read-only memory devices (PROM). Examples of program instructions include both machine code, such as produced by a compiler, and files containing higher-level code that a computer can execute using an interpreter.

[0064] FIG. 11 shows a linked list data structure 1100 represented by three data segments 1102, 1104, and 1106. Traditional blockchains are structured similarly to linked lists, with each segment of data referencing previously created segments of data. For example, data segment 1106 contains an arbitrary set of data. For data segment 1106 to be part of the overall data set, it contains a reference to the data segment that precedes it. In this case, data segment 1104 precedes data segment 1106, so data segment 1106 contains a reference to data segment 1104. In some embodiments, the first entry in the linked list, data segment 1102 of FIG. 11, does not have any references to other data segments.

[0065] Figure 12 shows a conceptual example of a blockchain 1200. Each block (1202, 1204, and 1206) contains a set of data within it. This data can be arbitrary, but is traditionally a list of transactions. Each block has a reference to its previous block, in a structure similar to the linked list of Figure 11. One of the distinguishing features of blockchain as a data structure is that each block contains cryptographic evidence that the data it holds has not been tampered with.

[0066] To ensure that historical data across the platform's network has not been tampered with, segments of data 1304 are periodically aggregated and Merkle-ized (1306). This root of the set of data is then written (1302) to a third-party blockchain, backed by a consensus algorithm such as proof-of-work or proof-of-stake. The motivation behind creating an audit point outside of the platform's blockchain 1308 is that attacks performed on the platform's blockchain are more expensive to execute because the third-party network 1302 must be attacked as well. For example, Figure 13 shows an example of marking a portion of the platform's dataset 1304. Given a set of data claimed to be from a particular segment of the platform's blockchain, authenticity can be concluded by marking the set of data and ensuring that it produces the same Merkle root as exists on the third-party blockchain 1302.

[0067] Although many of the components and processes are described in the singular for convenience, it will be understood by those skilled in the art that multiple components and iterative processes can also be used to implement the techniques of this disclosure.

[0068] While the present disclosure has been particularly shown and described with reference to particular embodiments thereof, it will be understood by those skilled in the art that changes in form and detail of the disclosed embodiments may be made without departing from the spirit or scope of this disclosure. Accordingly, the present disclosure is intended to be construed as including all modifications and equivalents that are within its true spirit and scope. The technical features described here are listed below. [Technical feature 1] In a system having a processor and a memory, the memory storing a set of instructions for causing a processor to perform a predetermined method; The predetermined method is receiving a request to upload a media file and metadata associated with the media file; uploading the media files and metadata via a blockchain protocol; receiving a request from a client device or a digital service provider (DSP) platform to play the media file; validating a request to play the media file via the blockchain protocol; upon verifying a request to play the media file, transferring the media file for playback on the client device or DSP platform; and tracking the number of times the media file has been played via the blockchain protocol. [Technical feature 2] 2. The system according to claim 1, wherein the blockchain protocol utilizes a proof-of-authority algorithm. [Technical feature 3] The system according to Technical Feature 1, wherein the step of verifying the request includes a cryptographic verification step by two approved sealers among the plurality of sealers. [Technical feature 4] The system of Technical Feature 1, wherein the request to play the media file includes a request to the blockchain to access the content at a specified time. [Technical feature 5] The system of Technical Feature 1, wherein requests to the blockchain can be completed as soon as the request hits the blockchain, thereby allowing it to be added in any order. [Technical feature 6] The system of Technical Feature 1, wherein a short buffer of the media file is streamed immediately after receiving a request to play the media file, and the remainder of the media file is streamed only after the request to play the media file is verified. [Technical feature 7] The system according to technical feature 1, wherein different versions of the blockchain client are generated for different clients. [Technical feature 8] receiving a request to upload a media file and metadata associated with the media file; uploading the media files and metadata via a blockchain protocol; receiving a request from a client device or a digital service provider (DSP) platform to play the media file; validating a request to play the media file via the blockchain protocol; upon verifying a request to play the media file, transferring the media file for playback on the client device or DSP platform; and tracking the number of times the media file has been played via the blockchain protocol. [Technical feature 9] 9. The method according to claim 8, wherein the blockchain protocol utilizes a proof-of-authority algorithm. [Technical feature 10] The method according to technical feature 8, wherein the step of verifying the request includes a cryptographic verification step by two approved sealers from the plurality of sealers. [Technical feature 11] The method of technical feature 8, wherein the request to play the media file includes a request to the blockchain to access the content at a specified time. [Technical feature 12] 9. The method of claim 8, wherein a request to the blockchain can be completed as soon as the request hits the blockchain, thereby allowing it to be added in any order. [Technical feature 13] The method of technical feature 8, wherein a short buffer of the media file is streamed immediately after receiving a request to play the media file, and the remainder of the media file is streamed only after the request to play the media file is verified. [Technical feature 14] The method according to technical feature 8, wherein different versions of the blockchain client are generated for different clients. [Technical feature 15] receiving a request to upload a media file and metadata associated with the media file; uploading the media files and metadata via a blockchain protocol; receiving a request from a client device or a digital service provider (DSP) platform to play the media file; validating a request to play the media file via the blockchain protocol; upon verifying a request to play the media file, transferring the media file for playback at the client device or DSP; and tracking the number of times the media file has been played via the blockchain protocol. [Technical feature 16] 16. The non-transitory computer-readable medium according to claim 15, wherein the blockchain protocol utilizes a proof-of-authority algorithm. [Technical feature 17] Feature 16. The non-transitory computer-readable medium of feature 15, wherein the step of verifying the request includes a cryptographic verification step by two approved sealers from the plurality of sealers. [Technical feature 18] A non-transitory computer-readable medium as described in Technical Feature 15, wherein the request to play the media file includes a request to the blockchain to access content at a specified time. [Technical feature 19] Feature 16. The non-transitory computer-readable medium of feature 15, wherein a request to the blockchain can be completed as soon as the request hits the blockchain, thereby allowing it to be added in any order. [Technical feature 20] Feature 16. The non-transitory computer-readable medium of feature 15, wherein a short buffer of the media file is streamed immediately after receiving a request to play the media file, and the remainder of the media file is streamed only after the request to play the media file is verified.

Claims

1. A method for tracking the number of times a media file is played, comprising: recording data regarding requests from client devices to play a media file using a plurality of sealers; and a processor tracking the number of times the client devices play the media file from the data regarding the requests from the client devices, selecting a sealer from the plurality of sealers according to a proof-of-authority consensus algorithm; receiving and validating requests from client devices to play media files by the plurality of sealers; and when the one sealer selected according to the proof-of-authority consensus algorithm is notified first and second by two sealers that the sealer has successfully verified the request from the client device to play the media file, the one sealer selected according to the proof-of-authority consensus algorithm inserts data related to the request from the client device to play the media file into a data block, and incorporates the data block containing the data related to the request from the client device to play the media file into a data block structure in which subsequent data blocks contain references to previous data blocks using a blockchain protocol.

2. A method for tracking the number of times a media file is played as described in claim 1, wherein the multiple sealers execute a request from a client device to play a media file by verifying the signature of the request with the private key of the client device.

Images