JP7308493B2 - ブロックチェーンを使用してメディア再生を連続的に追跡するためのシステムおよび方法 - Google Patents

Description

関連出願

この出願は、２０２０年６月２４日に出願されたＡｓｓａｄｉｐｏｕｒ等による「ブロックチェーンを利用してメディア再生を連続的に追跡するシステムおよび方法」という名称の米国特許出願第１６／９１１，２９７号（参照番号ＢＴＰＰＰ００１）の利益を主張し、参照によりその全体をすべての目的のためにここに組み込む。

本開示は、デジタルメディア、特にストリーミングメディアの追跡に関する。

音楽産業は、ロイヤルティに基づいて推定２５０億ドルの収入を生み出す。インターネットの出現により、ストリーミングテクノロジーにより、リスナーは選択したほぼすべての曲を簡単に聴くことができる。アーティストは、通常、音楽レーベルと協力してメディアを配布し、ロイヤルティに基づいて収益を集めるのを支援する。これらの音楽レーベルは、ストリーミングプラットフォームや、ＳｐｏｔｉｆｙやＡｐｐｌｅなどのデジタルサービスプロバイダー（ＤＳＰ）など、さまざまなメディアを通じてメディアを配信される。

曲へのアクセスはＤＳＰによって容易にされてきたけれども、ストリーミングされたすべての曲または特定の曲の再生量を追跡することは、解決するのがますます困難な問題になっている。したがって、今日のストリーミングプラットフォームでのアクティビティの２５％はライセンスがない。さらに、認可されたアクティビティであっても、年間総ロイヤルティの最大１５％が未徴収のままである。ＤＳＰは、誰の主張が正当であるのか、あるいは特定の当事者を見つける方法さえも理解するのに役立つ必要なデータおよびテクノロジーが不足していると主張している。さらに、既存のすべての音楽の権利をカバーする信頼できるデータベースの欠如は、問題を追加するだけである。さらに、問題は音楽だけでなく、ビデオ、ポッドキャスト、ライブ放送など、種々の種類のストリーミングメディアにある。したがって、誰でもインターネット上で創造的な作品を登録、識別、追跡できる、信頼性の高いコンテンツ識別技術が必要である。

以下は、本開示の特定の実施例の基本的な理解を提供するために、本開示の簡略化された概要を提示する。この概要は、本開示の広範な要旨ではなく、本開示の重要な要素を特定したり、本開示の範囲を説明したりするものではない。その唯一の目的は、後で提示されるより詳細な説明の前置きとして、ここに開示されるいくつかの概念を簡略化された形で提示することである。

本開示の側面は、ブロックチェーンを使用してメディアファイルの再生を追跡するためのシステムおよび方法に関する。メモリは、方法を実行するための命令を含む。この方法は、最初にプラットフォームストリームからトランザクションデータを受信することから始まる。トランザクションデータは、エンドユーザーからのメディアファイルの再生要求に対応している。次に、トランザクションデータが検証される（ｖｅｒｉｆｙ）。次に、検証されたトランザクションデータは暗号署名を使用して署名される。次に、トランザクションデータが有効なブロックチェーントランザクションに対応するかどうかが判断される。トランザクションデータが有効なブロックチェーントランザクションに対応している場合、有効なブロックチェーントランザクションがブロックチェーンに記録される。最後に、トランザクションデータおよび暗号署名が１つ以上の検証（ｖａｌｉｄａｔｉｏｎ）ノードに送信される。

本開示の他の側面において、システムが提供される。システムは、プロセッサおよびメモリを含む。メモリは、方法を実行するための命令を含む。この方法は、最初にプラットフォームストリームからトランザクションデータを受信することから始まる。トランザクションデータは、エンドユーザーから最初の検証ノードへのメディアファイルの再生要求に対応する。次に、トランザクションデータが検証される。次に、検証されたトランザクションデータが署名され、暗号化署名が生成される。これにより、トランザクションが有効なブロックチェーントランザクションとして検証される。次に、有効なブロックチェーントランザクションがブロックチェーンに記録される。最後に、トランザクションデータと暗号署名が１つ以上の検証ノードに送信される。

本開示のさらに他の側面において、ブロックチェーンベースのプラットフォームを介してメディアファイルの再生を追跡するための方法が提供される。この方法は、最初にプラットフォームストリームからトランザクションデータを受信することから始まる。トランザクションデータは、エンドユーザーからのメディアファイルの再生要求に対応している。次に、トランザクションデータが検証される。次に、検証されたトランザクションデータは暗号署名を使用して署名される。次に、トランザクションデータが有効なブロックチェーントランザクションに対応するかどうかが判断される。トランザクションデータが有効なブロックチェーントランザクションに対応している場合、有効なブロックチェーントランザクションがブロックチェーンに記録される。最後に、トランザクションデータと暗号署名が１つ以上の検証ノードに送信される。

これらの側面の追加の利点および新規な特徴は、部分的には以下の説明に記載され、部分的には、当技術分野の当業者が以下の説明を検討し、開示内容を実施して学習することにより、明らかになる。

本開示は、本開示の具体的な実施例を説明する、以下の説明を添付の図面と併せて参照することによって最もよく理解される。以下の説明では、同様の部品が明細書および図面全体でそれぞれ同じ番号で参照される。図は必ずしも一定の縮尺で描かれているわけではなく、所定の図は、明確さと簡潔さのために誇張または一般化された形式で示されている場合がある。
本開示の実施例に従う、開示されたシステムにおける利用可能なユーザータイプの関係、データ、および機能の例示的な図である。 本開示の実施例に従う、歌の再生要求からフィンガープリントされたコンテンツを提供するまでの例示的な待ち時間分析を示す。 本開示の実施例に従う、シャーディングの例示的な図を示す。 本開示の実施例に従って、音楽産業がどのように結合されるかの一例の図である。 本開示の実施例に従う、基本的な管理者の役割の一例の図である。 本開示の実施例に従う、エンドユーザーの基本的なデータフローの一例の図である。 本開示の実施例に従う、メディアファイル再生追跡ネットワークの一例の図である。 本開示の実施に従う、メディアファイルの再生を追跡するためのシステムの一例のシステム図である。 本開示の実施例に従う、メディアファイルの再生を追跡するための方法のフローチャートである。 本開示の実施例に従う、コンピュータシステムの一例を示す。 本開示の実施例に従う、連結リストデータ構造の一例を示す。 本開示の実施例による、ブロックチェーンの概念的な例を示す。 本開示の実施例による、プラットフォームデータセットの一部のマークル化の例を示す。 本開示の実施例に従う、トランザクションのデータフローの他の例を示す。 本開示の実施例に従う、例示的な非ＣＤＮプラットフォームアーキテクチャのフローチャートを示す。 本開示の実施例に従う、例示的な非ＣＤＮプラットフォームアーキテクチャの他のフローチャートを示す。 本開示の実施例に従う、ローカル永続性を使用してメディアファイル再生を連続的に追跡するための方法のフローチャートを示す。 本開示の実施例に従う、ローカル永続性を使用してメディアファイル再生を連続的に追跡するための方法のフローチャートを示す。 本開示の実施例に従う、バッファ近似を使用する連続追跡のための方法のフローチャートを示す。 本開示の実施例に従う、バッファ近似を使用する連続追跡のための方法のフローチャートを示す。 本開示の実施例に従う、ユーザーインターラクションを使用する連続追跡のための方法のフローチャートを示す。 本開示の実施例に従う、コンピュータシステムの一例を示す。 本開示の実施例に従う、リンクリストデータ構造の一例を示す。 本開示の実施例に従う、ブロックチェーンの概念的な例を示す。 本開示の実施例に従う、プラットフォームデータセットの一部のマークル化の例を示す。

詳細な説明

ここで、本開示を実施するために発明者によって企図された最良のモードを含む、本開示のいくつかの特定の例を詳細に参照する。これらの特定の実施例の例は、添付の図面に示されている。本開示は、これらの特定の実施例と併せて説明されているが、本開示を説明された実施例に限定することを意図するものではないことが理解されよう。それどころか、それは、添付の特許請求の範囲によって定義される開示の精神および範囲内に含まれ得る代替物、修正、および均等物をカバーすることを意図している。

例えば、本開示の技術は、メディアファイルの追跡要求、メディアファイル送信、暗号化、データストレージ、およびメディアアクセス検証（ｖａｌｉｄａｔｉｏｎ）の文脈で説明される。しかしながら、本開示の技術は、多種多様なネットワークトランザクション、協調的環境、データ構造、および異なるタイプのデータに適用されることに留意されたい。以下の説明では、本開示の完全な理解を提供するために、多くの特定の詳細が示されている。本開示の特定の例示的な実施例は、これらの特定の詳細の一部または全部なしで実施することができる。他の例では、本開示を不必要に曖昧にしないために、周知のプロセス操作は詳細に説明されていない。

本開示の様々な技術およびメカニズムは、明確にするために単数形で説明されることがある。しかしながら、いくつかの実施例は、特に断りのない限り、技術の複数の反復またはメカニズムの複数のインスタンス化を含むことに留意されたい。たとえば、システムはさまざまな文脈で１つのプロセッサを使用する。しかしながら、特に断りのない限り、システムは、本開示の範囲内にとどまりながら、複数のプロセッサを使用できることが理解されよう。さらに、本開示の技術およびメカニズムは、２つのエンティティ間の関係を説明する場合がある。他のさまざまなエンティティが２つのエンティティ間に存在する可能性があるため、２つのエンティティ間の接続は、必ずしも直接の障害のない接続を意味するわけではないことに注意されたい。例えば、プロセッサはメモリに接続され得るが、様々なブリッジおよびコントローラがプロセッサとメモリとの間に存在し得ることが理解されるであろう。したがって、特に明記されていない限り、接続は必ずしも直接の障害のない接続を意味するわけではない。

ここで使用される場合、「プラットフォーム」という用語は、本明細書で開示されるプラットフォームシステムおよび方法を指す。本開示を通して、「プラットフォーム」および「システム」という用語は交換可能に使用される。様々な実施例によれば、ブロックチェーン音楽プラットフォームが提供される。いくつかの実施例において、ブロックチェーンは、すべてのトランザクションの永続的な記録を保持する、分散化された、安全で、変更不可能なデジタル台帳またはデータベースとして定義される。いくつかの実施形例において、ブロックチェーン台帳には「スマートコントラクト」があり、これはブロックチェーントランザクションの条件とコストを規定している。いくつかの実施例において、スマートコントラクトを修正することができるけれども、以前のすべてのバージョンはブロックチェーン上にとどまる。トランザクションの完全な履歴とスマートコントラクトの変更により、ブロックチェーンテクノロジーは、クローズドコントラクトとデータベースの現在のシステムよりも本質的に透過的で安全である。

ここで使用される場合、「シーラー」および「バリデーションノード」という用語は交換可能に使用され、トランザクションをブロックチェーンに追加する前にトランザクションを検証（ｖａｌｉｄａｔｅ）するために使用される任意の数の登録済みまたは信頼できるノードを指す。バリデーションノードの例としては、ＤＳＰ、プラットフォーム、レーベル、ディストリビューターなどがある。

いくつかの実施例において、ブロックチェーン音楽プラットフォームは、ユーザーが、メディアファイル、例えば、曲に関連するメタデータとともに、メディアファイルをサーバーまたはデータベースにアップロードすることを可能にする。いくつかの実施例において、曲をアップロードする要求が受信されると、曲のブロックチェーントランザクションが作成され、ブロックチェーンに保存される。いくつかの実施例において、曲の詳細、コンテンツアクセスの詳細、および利害関係者の利害関係などのデータ、ならびに他の何百もの潜在的なメタデータフィールドもブロックチェーンに保存される。いくつかの実施例において、データが不変であり、ネットワークが安全であることを保証するために、ブロックチェーン上のトランザクションは、ファイナライズされる前に検証される必要がある。いくつかの実施例において、検証（ｖａｌｉｄａｔｉｏｎ）は、少なくとも２つ以上のトランザクションバリデーター（シーラー）、または許可された／信頼された検証ノード（ｖａｌｉｄａｔｉｏｎ ｎｏｄｅ）がトランザクションを検証できる後にのみ発生する。

いくつかの実施例において、ブロックチェーン音楽プラットフォームは、ユーザーがメディアファイルに関連付けられたメタデータをサーバーまたはデータベースに送信することを可能にする。いくつかの実施例において、曲のデータをアップロードする要求が受信されると、曲のブロックチェーントランザクションが作成され、ブロックチェーンに保存される。いくつかの実施例において、曲の詳細、コンテンツアクセスの詳細、および利害関係者の利害関係などのデータ、ならびに他の何百もの潜在的なメタデータフィールドもブロックチェーンに保存される。いくつかの実施例において、データが不変であり、ネットワークが安全であることを保証するために、ブロックチェーン上のトランザクションは、ファイナライズされる前に検証される必要がある。いくつかの実施例において、検証は、少なくとも２つ以上のトランザクションバリデーター（シーラー）、または許可された／信頼されたバリデーションノードがトランザクションを検証できる後にのみ発生する。いくつかの実施例において、トランザクションが有効であると見なすのに、バリデーターによる１つの署名のみが必要である。

いくつかの実施例において、データストレージの必要性は、多数のユーザーのメディアストリーミングを実際にサポートするために大きいので、システムはトークンを使用しない。しかしながら、他の実施例において、トークンを作成して、支払い処理に使用することができる。

いくつかの実施例において、トランザクションは、プルーフ・オブ・オーソリティ（Ｐｒｏｏｆ ｏｆ Ａｕｔｈｏｒｉｔｙ：ＰｏＡ）コンセンサスアルゴリズムを使用して検証される。他の実施例において、トランザクションは、プルーフ・オブ・ワーク（Ｐｒｏｏｆ ｏｆ Ｗｏｒｋ：ＰｏＷ）アルゴリズムを使用して検証される。しかしながら、様々な実施例に従って、ＰｏＡは、以下の理由で開示されたシステムおよび方法に対してよりよく機能する。まず、ＰｏＡでは、特定の関係者のみがブロックチェーン上のトランザクションを検証できる。ブロックのシールまたはトランザクションの検証を許可され、それらが属するパーティを識別することができるノードは事前定義されているため、検証に必要な時間を短縮できる。第２に、ＰｏＡのトランザクションは、ブロックチェーンによって処理されるとすぐにファイナライズできる。これは、承認されたシーラーがトランザクションを暗号で検証できるためである。したがって、ブロックは、有効である限り、任意の順序でブロックチェーンに追加できる。したがって、ＰｏＡの別の結果は、ブロックチェーンのメカニズムだけで有効なブロックが拒否されないため、「アンクルブロック」または「孤立ブロック」が削除されることである。第３に、ＰｏＡ実装のトランザクションスループットは、実行するハードウェアによってのみ制限される。したがって、開示されたシステムは、毎秒数百万のトランザクションに対応することができる。対照的に、ＰｏＷ実装の場合、トランザクションスループットは、プロトコルで必要な作業証明の難しさによってほとんど制限されてしまう。最後に、ノードのＩＤがわかっているため、ＰｏＡはシビル・アタック（Ｓｙｂｉｌ ａｔｔａｃｋ）の影響を受けない。

いくつかの実施例において、ＰｏＡコンセンサスアルゴリズムは、以下の式を使用して、どのノードが次のブロックをシールすることを許可されるかを決定する。
（シーラーあたり対処される連続ブロックの数）＝（ｆｌｏｏｒ（シーラー数／２）＋１）

他の実施例において、コンテンツの迅速な利用可能性を確実にするために、トランザクションは、最初の２つの利用可能なシーラーによって検証および封印される。いくつかの実施例において、ブロック提案は使用されない。そのような実施例においては、歌またはメディアファイルがクライアントデバイスによって要求されると、歌またはメディアファイルの短いバッファが即座に送信またはストリーミングされる。ただし、トランザクションがブロックチェーンで完了するまで、通常は１秒以内に、曲全体またはメディアファイルがクライアントデバイスにパイプされない。いくつかの実施例において、メディアファイルの再生は、所定量のコンテンツがエンドユーザーによって再生されるまで、アカウント報告されない。したがって、エンドユーザーが所定の時間コンテンツを消費しない場合、再生の初期化が行われ、一部のコンテンツがエンドユーザーにストリーミングされる可能性があるけれども、エンドユーザーは十分な長さのコンテンツを消費しないので、再生イベントはブロックチェーンに送信されない。

種々の実施例によれば、数十億のトランザクションを１時間ごとにブロックチェーンに対して行うことができる。その結果、大量のデータがブロックチェーンに保存できる。したがって、すべてのノードがブロックチェーンの完全な履歴を持つ必要がある場合、ストレージコストを制御することは非現実的になるかもしれない。したがって、いくつかの実施例において、ブロックチェーンクライアントの様々な異なる互換性のあるバージョンが作成される。このような実施例において、「より軽い」クライアントは、通常のブロックチェーンクライアントと同じ機能を有するであろう。ただし、これらのクライアントは、トランザクションの検証などの特定のタスクを実行するための、過去のブロックチェーン履歴のすべてを含む必要はない。したがって、いくつかの実施例において、ライトクライアントは、ブロックチェーン履歴の一部をダウンロードする必要はない。いくつかの実施例において、シーラーは、トランザクションの検証を開始するために、封印された最新のブロックのヘッダーをダウンロードするだけでよい。いくつかの実施例において、シーラーは、暗号署名の検証のみを任務とし、ブロックチェーンのイベントの履歴を必要としない。「重い」クライアントの場合、ブロックチェーン上のデータは、ブロックヘッダーを参照として使用してプルーニング（枝刈り）される。いくつかの実施例において、より軽いクライアントは、マークルツリー（Ｍｅｒｋｌｅツリー）を使用してデータをハッシュし、ルートを格納して、必要なストレージスペースを減らすことができる。しかしながら、いくつかの実施例において、当事者は、ブロックチェーン全体のコピーを有するために完全なノードを実行するオプションを有する。いくつかの実施例において、当事者は、ブロックチェーンデータをノード上に直接保持するか、またはデータを別個のストレージソリューションにオフロードするかを選択することができる。

種々の実施例によれば、プラットフォームに関与する種々の当事者は、種々のデジタルインフラストラクチャを必要とするであろう。たとえば、ＤＳＰと音楽レーベルは、プラットフォームのコンセンサスプロトコルを使用してネットワークを保護することに参加したい場合がある。ただし、プラットフォームのコンセンサスプロトコル仕様に準拠している限り、さまざまな関係者が独自のブロックチェーンクライアントを自由に作成できる。

いくつかの実施例において、ノードは、単一のコンピュータによって実行できる。いくつかの実施例において、ノードは、コンピュータのアレイ全体で実行することができる。ノードを実行するためのアーキテクチャの選択には、ロードバランサーの使用、グループのスケーリング、およびｉ／またはサーバーレステクノロジーが含まれて良い。各ノードの主な要件は、おそらく参加者のＩＤに対して登録された１つまたは複数の公開鍵によって表されることにより、１つのＩＤを表す必要があることである。

いくつかの実施例において、プラットフォームのサーバーは、単にネットワークに参加しているだけではなく、より多くのサービスを提供する。いくつかの実例において、サーバーは、コンテンツ配信ネットワーク（ＣＤＮ）を介してリスナーに直接デジタルメディアコンテンツを提供する責任がある。このような実施形例において、プラットフォームは、コンテンツサーバーの分散セットに対してｎｇｉｎｘを使用したエニーキャスト手法を使用する。そのような実施例において、ファイルが提供されるたびに、それは、また、トランザクションハッシュまたは他の識別情報でフィンガープリントされる。他の実施例において、プラットフォームのサーバーは、プロトコルおよび追跡サービスを提供するけれども、コンテンツを直接配信しない。

いくつかの実施例において、ＤＳＰは、それらのクライアント側アプリケーションを変更するために必要とされるであろう。たとえば、ＤＳＰには、プラットフォーム上の曲ごとに個別のエンドポイントがある可能性がある。したがって、いくつかの実施例において、ＤＳＰは、現在ファイルを提供しているエンドポイントを、ブロックチェーンネットワークに要求を行うエンドポイントに変更する必要がある。リクエストが検証されると、ＣＤＮによって完全な曲ファイルがユーザーにパイプされる。

いくつかの実施例において、ユーザーが特定のアクションを行ったことを暗号的に検証するために、ブロックチェーンプロトコルは、非対称暗号、例えば、楕円曲線デジタル署名アルゴリズム（ＥＣＤＳＡ）を利用する。このような実施例において、エンドユーザーは、要求が送信されるたびに署名を作成する必要がある。したがって、ＤＳＰは、リスナーに（クライアントのデバイス上で、またはＤＳＰ自体のサーバーを使用して）暗号化キーペアを提供する必要がある。

種々の実施例によれば、ＤＳＰによって処理される１秒あたりの大量のトランザクションのために、スケーリングのためのいくつかの方法が提供される。いくつかの実施例において、パブリックブロックチェーンの代わりにコンソーシアムブロックチェーンが実装される。コンソーシアムのブロックチェーンを構築するときは、ＰｏＡが使用される。トランザクション検証者は、ＩＤ／レピュテーションを賭けることにより、要求を迅速に承認でき、独自のハードウェアとインターネットインフラストラクチャによってのみ制約される。

いくつかの実施例において、ネットワーク全体で発生するトランザクションを記録するために単一のブロックチェーンを使用することは実行可能ではない。いくつかの実施例において、ブロックチェーンは地理的シャードに分割することができる。たとえば、あるシャードが北米を担当し、別のシャードがロンドンを担当する場合がある。本開示に記載されている他の実施例を含むいくつかの実施例において、ブロックチェーンは、レーベルとＤＳＰの関係によって分割することができる。たとえば、シャードはＳｔｒｅａｍＣｏとレーベルＡの間にあり、ＳｔｒｅａｍＣｏにはレーベルＢの別のシャードがある。関係シャーディングのこのような実施例において、参加者は自分が属していない関係からのデータにアクセスできない。

いくつかの実施例において、ブロックチェーンネットワークの各参加者は、世界中に広がる最小数のノードを実行する必要がある。したがって、プラットフォームのブートノードは、ルーティングアルゴリズムを使用してシーラーを地理的にグループ化する。いくつかの実施例において、シャードがメインチェーンからスポーンされると、それは定期的にマークル化され、ルートハッシュが取得されてメインチェーンに格納される。定期的に、またはシャードが閉じられると、その履歴がメインチェーンに追加される。いくつかの実施例において、シャードでの紛争のありそうもないケースでは、最新の暗号的に証明可能なデータが真実として使用される。いくつかの実施例において、エンドユーザーは、メインまたはＤＳＰ－レーベル関係シャードで行われた要求によって、地理的シャードから割り当てられ、または割り当てられない。いくつかの実施例において、ユーザーが特定のシャードに割り当てられると、それらは、同じＤＳＰ－レーベル関係シャード内の別のシャードで要求を行うことができない。

いくつかの実施例において、オフチェーンスケーリングをプロトコルに組み込むことができる。たとえば、ステートチャネル、子チェーン、またはシャーディングチェーンはすべてコンセンサスプロトコルで使用できる。次の例は、オフチェーンスケーリングを組み込むための１つの方法を示す。この例では、プラットフォームのシャーディング実装はメインチェーントランザクションを使用して関係を開く。ステートチャネルの最終的な結果だけでなく、すべてのメディア再生がカウントされることに注意されたい。

ＣＤＮの例：アリスは、ＤＳＰから音楽を再生するために彼女の音楽アプリケーションを開く。アリスは、ＤＳＰの適切な地理的シャードに割り当てられます（リソースが利用可能な場合は、既存または新規に作成されます）。アリスは、今、メインチェーンにストレスをかけることなく、任意の量のメディアコンテンツをストリーミングできる。各ストリームリクエストは、アリスが秘密鍵を使用して署名し、公開鍵を使用して任意のシーリングノードで検証できる。

彼女の音楽アプリケーションの以下の使用例を見ると、当業者は、シャーディングがどのようにパフォーマンスを改善するかを見ることができる：アリスは、要求に暗号的に署名することによって曲を再生することを要求する。プラットフォームＣＤＮが音楽をアリスにストリーミングする前に、リクエストは少なくとも２つのシーラーによって検証される。曲のアドレスへの呼び出しは、シャードのブロックチェーンに記録される。この方法と従来のブロックチェーンの呼び出しとの違いは、リクエストがすぐにメインチェーンにコミットされないことである。曲の実行時に任意の間隔で、シャード内のクライアントから、ユーザーが聴いている曲の次の部分を取得するように要求が自動的に行われる。データは、再生データを追跡するためにチャンクにパイプされる。アリスが署名していないトランザクションがある場合、またはアリスが再生した曲の数について異議がある場合は、暗号で証明可能な最新のデータがメインチェーンに送信される。次に、シャードは続行し、または、閉じ、メインチェーンはシャード内のすべてのアクティブユーザーを再割り当てする。アリスが任意に設定された時間（シャードに参加したときに定義された）音楽を聴いていない場合、彼女はすべてのシャードから割り当てられていない。

いくつかの実施例において、プラットフォームのＣＤＮの１つからストリーミングされたすべての曲がスタンプされ、コンテンツの元のストリーマーを識別できるようになる。いくつかの実施例において、フィンガープリントプロセス全体が２つの主要なコンポーネントに分割される。すなわち、スタンプ（トラックにフィンガープリントを適用する）およびスクレイピング（プラットフォームのＣＤＮから最初に再生されたトラックを見つけ、コンテンツがどのようにリークしたかを識別する）である。いくつかの実施例において、悪意のある攻撃者が識別指紋を削除または歪曲しようとしないことを保証するために、指紋認証方法は秘密のままでなければならない。

アリスに関する先の例はＣＤＮアーキテクチャを含むけれども、再生要求およびそれに関連するカウントのブロックチェーン記録を伴うプロトコルは、非ＣＤＮアーキテクチャにも適用される。トランザクション要求は、コンテンツの配信がＤＳＰによって提供され、プロトコルを実装するプラットフォーム（サードパーティのプレイカウントレコードキーパーおよび監査人）を介して直接提供されないことを除いて、先の例と同様の方法で検証および記録できる。非ＣＤＮシステムでは、バリデーター（またはシーラー）がトランザクションを確認すると、エンドユーザーの公開鍵に対してトランザクションデータを検証することで、トランザクション内のデータの暗号化の有効性を確認できる。この検証ステップが通過すると、トランザクションデータはバリデーターによって署名され、結果の署名は関連するトランザクションＩＤとともにプラットフォームに書き戻される。署名はトランザクションごとに集約され、長期ストレージソリューションに保存される。すべてのバリデーターは、ストリームから直接読み取ることができる。その結果、同じネットワーククラスター内のバリデーターは、トランザクションＩＤを介してデータをトランザクションに関連付けることにより、特定の各トランザクションに関連付けられている同じ署名のセットをキャプチャすることができる。

いくつかの実施例において、すべてのノード／バリデーターは、ストリームのためのＡＰＩエンドポイント（例えば、ＵＲＬ）を有する。いくつかの実施例において、ストリームはサーバーに似ているけれども、トランザクションが任意の時間ストリーム内にとどまることができるという違いがある。

いくつかの実施例において、再生要求は、最初にエンドユーザーによって形成される。要求の形式は、プロトコルで定められたルールに従う必要がある。次に、リクエストを作成したエンドユーザーがリクエストに署名するため、リクエストの発信元を後で確認できる。署名されたリクエストとそれに付随するデータは、プロトコルで設定された形式でプラットフォームのストリームに送信される。たとえば、再生要求の最初の受信ノードがＤＳＰであった場合、ＤＳＰはその後、検証および署名された要求をプラットフォームやレーベルに送信できる。プラットフォームやレーベルがリクエストを確認して署名した後、確認され署名されたリクエストがＤＳＰに送信される。２つのバリデーターがリクエストに署名すると、トランザクションがブロックチェーンに追加される。いくつかの実施例において、単一のトランザクションがブロックチェーン内のブロックを構成することができる。他の実施例において、ブロックは多くのトランザクションを構成することができる。

いくつかの実施例において、各バリデーターは、いつでもブロックチェーンのそれら自身のコピーにトランザクションを格納するオプションを有する。他の実施例において、バリデーターは、それらのブロックチェーンを他のバリデーターと同期させる。

いくつかの実施例において、新しいＤＳＰ／レーベル関係が形成されるときに、子チェーンが生成される。いくつかの実施例において、各ＤＳＰは、主チェーンからの独自の分岐子チェーンを有する。ただし、親チェーンと子チェーンで生データを維持すると、計算量が多くなる可能性がある。したがって、いくつかの実施例において、生データのマークル化されたルートノードが親チェーンを上って伝播される間、生データは子チェーン上にとどまる。

いくつかの実施例において、データがストリーム内に存在するので、プラットフォーム上のバリデーターによって暗号的に検証することができる。リクエストが検証されるたびに、トランザクションデータはバリデーターによって署名される。署名は、リクエストデータのＩＤを参照してストリームに書き戻される。

各バリデーターは、他のバリデーターの署名をキャプチャし、それらをそれら自身の元帳に保持することができる。これは、元のトランザクションが将来特定のバリデーターによって検証されたことを示すために行われる。

データフローの実装に応じて、エンドユーザーは、要求をストリームに直接書き込む代わりに、要求をバリデーターに直接渡すことができる。有効な場合、リクエストはバリデーターによって署名される。この時点で、トランザクションは、元の要求データと２つの署名を具備し、署名のうち、１つはエンドユーザーからのもので、もう１つは最初のバリデーターからのものである。その後、ストリームに書き込まれる。データがストリームに存在するようになったので、プラットフォーム上のバリデーターによって暗号で検証できる。ストリームにリクエストを書き込んだ元のバリデーターは、ストリームを通過する新しいバリデーターをキャプチャできる。リクエストが検証されるたびに、トランザクションデータはバリデーターによって署名される。署名は、リクエストデータのＩＤを参照してストリームに書き戻される。

いくつかの実施例において、最初の要求は、以下の場合に有効であると見なされる。すなわち、１）データのフォーマットが、プラットフォームによって確立されたプロトコルに従っている。２）データには、暗号化署名とエンドユーザー公開鍵が付属していることである。いくつかの実施例において、エンドユーザーは、プロトコルとは異なるフォーマットを要求に使用することができる。そのような実施例において、ＤＳＰまたは第１の受信ノードは、それがストリームに送信される前に、プラットフォームプロトコルと整列するようにフォーマットを再構成することができる。

いくつかの実施例において、ストリームの出力において、バリデーターは、署名されていない要求、および他のバリデーターによって署名された可能性があるがそれ自体は署名していない要求をｋ監視する。ストリームに書き込まれたリクエストを検証するために、バリデーターは、実際のリクエストデータ、リクエストを作成したエンドユーザーの公開鍵、暗号化署名の３つの主要なデータを探す。

添付された公開鍵を使用して要求データに対して署名を検証できる場合、要求データはエンドユーザーから発信されたものであることが検証される。バリデーターによって検証されると、バリデーターは要求データに署名し、ストリームに書き戻す。ストリームに書き戻されたデータは、リクエストＩＤとバリデーターの署名で構成され、トランザクションが有効であることを示す。

先に説明したように、いくつかの実施例において、要求は、ストリームに直接書き込まれる代わりに、バリデーターに渡されて良く、バリデーターは、それを別のバリデーターに直接送信するか、または配信のためにストリーム自体に送信する。これで、リクエストがストリームに入るときに、２つ以上の署名を持つことができる。１つは最初にリクエストを行ったエンドユーザーに属し、１つ以上はリクエストを検証して署名したバリデーターに属する。ストリームに到達する前にリクエストに署名したバリデーターは、ストリームを監視して、他のバリデーターによって作成されたリクエストの署名を取得できる。

いくつかの実施例において、デジタルステガノグラフィを使用してファイルをスタンプすることによって、最小限のユーザーデータを、ユーザーに送信されているデータ内に隠すことができる。曲がストリーミングまたはダウンロードされるたびに、非表示の「透かし」をファイルに書き込むことができる。アルゴリズムは、デジタル信号処理を使用して、その形式のすべてのファイルに共通するデジタルコンテンツの一部を書き込んだり識別したりできる。たとえば、すべてのｍｐ３ファイルには、曲の他のすべての部分よりも低いピッチのポイントが曲内にある。曲の共通点に、ユーザーの暗号化されたデジタル指紋を追加できる。

いくつかの実施例において、スタンプ認識ソフトウェアは、デジタル信号処理を使用して、ウェブから削り取られたファイルからアップロードされた元のファイルをデコンボリューションすることによって、デジタル指紋を抽出する。デジタル指紋が見つかった場合、それを復号化して、ユーザーとプレイ時間までさかのぼることができる。いくつかの実施例において、指紋付けされたコンテンツのスクレイピングは、３つの主要なステップに分解することができる。すなわち、１）一般的な海賊版／ストリーミングサイト用のウェブクローラーを構築する。２）オーディオファイルを抽出してキャッシュする。このステップでは、ストリーミング／ダウンロードサイトごとにスクレイピングするためのカスタムソリューションが必要である。３）スタンプ認識ソフトウェアに対してキャッシュされたオーディオを実行する。

種々の実施例によれば、開示されたシステムおよび方法は、メディアファイルのカタログ、所有権、および支払いの詳細の検証を可能にする。いくつかの実施例において、システムは、また、支払いの発生および会計処理を可能にする。いくつかの実施例において、システムは、また、正しい口座に正しい金額を預けることを可能にする。いくつかの実施例において、システムは、音楽作品および録音物の作成者（アーティスト）、レーベル、および配信プラットフォームに対して、公平で、透明で、監査可能で、ほぼリアルタイムの支払いを実現する。さらに、いくつかの実施例において、システムは、リアルタイムのコンプライアンスおよび監査メカニズムを提供する。

図１は、本開示の実施例に従い、ここで開示されたシステムにおけるいくつかの利用可能なユーザータイプの関係、データ、および機能の例示的な図を示す。いくつかの実施例において、ユーザーの役割に基づいて、ユーザーは、開示されたプラットフォームに対して異なる責任を負う。図１において、すべてのユーザー１０６は、データに署名し、所与のデータおよび公開鍵に対して署名を検証するための独自の暗号鍵ペアを作成することができる。

いくつかの実施例において、レーベル１０２は、歌およびアルバムメタデータをプラットフォームにアップロードすることを担当する。いくつかの実施例において、レーベルは、ＤＳＰによって配布されるカタログ内の曲をさらに承認することができる。いくつかの実施例において、レーベル管理者は、必要なメタデータを記入し、歌ファイルをアップロードし、利害関係者の共有を割り当てることによって、プラットフォーム用の歌またはアルバムを準備する。レーベルアカウントから有効なアップロードリクエストを受信すると、エントリがブロックチェーンにブロードキャストされる。アーティストが曲にクレジットされたことに応じて、アーティストは曲を承認するオプションを利用できるようになっている。これにより、曲のリリース日にＤＳＰで利用できるようになる。

いくつかの実施例において、アップロードされた曲はメディアサーバー上に保持され、コンテンツにアクセスするためにブロックチェーンに暗号的に有効な要求を行ったユーザーによってのみアクセスすることができる。いくつかの実施例において、管理者は、プラットフォームウェブ製品を使用して、曲の再生に関する分析データを表示することができる。いくつかの実施例において、管理者は、要求ごとにデータを分類することができ、ユーザーがコンテンツにどのように関与しているかを追跡できるようにする。

いくつかの実施例において、アーティスト１０４がレーベル１０２との契約オファーを取得すると、アーティスト１０４は、レーベル１０２への追加を受け入れることができる。いくつかの実施例において、アーティスト１０４は、レーベルに割り当てられない場合がある。そのような実施例においては、アーティスト１０４は、プラットフォーム上で独自のレーベルとして機能することができる。レーベル１０２が曲をアップロードするとき、クレジットされたアーティスト１０４がアップロードを承認するまで、それは未確認である。アーティスト１０４は、プラットフォームを介して自分の曲の再生データを表示できるけれども、同僚のデータを表示することは制限されている。

いくつかの実施例において、各曲の利害関係者１０８は、ブロックチェーン上で確定される前に決定される。いくつかの実施例において、各曲の収益のパーセンテージが利害関係者１０８に割り当てられる。いくつかの実施例において、利害関係者１０８は、彼らが一部を所有する歌に関するデータを見ることができる。

いくつかの実施例において、ＤＳＰ１１０のおかげで、エンドユーザー１０６は、歌へのアクセスを与えられる。ほとんどのＤＳＰ１１０はサブスクリプションモデルを使用するので、ユーザー１０６が、設定された期間、ＤＳＰのプラットフォーム上の任意の曲を聞くことを可能にする機能がある。いくつかの実施例において、プラットフォームのテクノロジーを活用するために既存のＤＳＰがシステムに対して行う必要がある提案された変更は軽微である。

いくつかの実施例において、ＤＳＰのアプリケーションのユーザー１１２は、曲をストリーミングするときにいかなる違いも知覚してはならない。代わりに、エンドユーザーを作成したＤＳＰ１１０が、ユーザーのキーの管理を担当する。ＤＳＰが独自のサーバーまたはクライアントアプリケーションを使用して要求に署名するかどうかは、ＤＳＰ次第である。

いくつかの実施例において、待ち時間の問題は、ノードが十分に接近していない場合に発生し、これは、２つのノード間の距離が増加するにつれて２つのノード間の待ち時間が増加することを意味する。子チェーンの地理的シャーディングを活用することにより、信号の移動時間が短縮される。図２は、ブロックチェーンネットワークの遅延を調査するのに役立つ。図２は、本開示の実施例に従う、歌の再生要求からフィンガープリントされたコンテンツを提供するまでの例示的な待ち時間分析を示す。レイテンシー２００はいくつかのステップに分割でき、その一部は並行して実行される。

２０２において、歌が再生のために要求される。いくつかの実施例において、エンドユーザーが曲を再生するとき、要求は２つの主要な場所に送信される。すなわち、ユーザーに割り当てられたブロックチェーンシャードおよびＣＤＮである。２０４において、フィンガープリントされたファイルが準備される。ステップ２０６および２０８は、要求の封印を扱う。いくつかの実施例において、要求を検証するための３つの別個の当事者のうちの最初の２つは、トランザクションが封印されていることを合図する。２０６において、要求は最初のノードによって検証される。２０８において、要求は２番目のノードによって検証される。ここで視覚化されていないのは、着信再生要求を検証する際に、他の２つのノード、２０６および２０８よりも遅い第３のノードである。この遅いノードは、最終的には暗号署名を再生イベントに添付できるけれども、この再生要求を封印する必要はない。２１０において、コンテンツがユーザーに提供される。いくつかの実施例において、サーバーは、デジタルメディアファイルをユーザーにパイプで送る。図２に概説された経路の結果として。ファイル応答を成功させるための次の式を書くことができます。
ｔ_{ｌａｔｅｎｃｙ}＝ｍａｘ（ｔ_{ｃｌｉｅｎｔ ＣＤＮ}、ｔ_{ｃｌｉｅｎｔ Ｎｏｄｅ１}、ｔ_{ｃｌｉｅｎｔ Ｎｏｄｅ２}）＋ｍａｘ（ｔ_{ｐｒｅｐ ｆｉｌｅ} ＋ｔ_{Ｎｏｄｅ１ ＣＤＮ}、ｔ_{Ｎｏｄｅ２ ＣＤＮ}）＋ｔ_{ｓｅｒｖｅ ｆｉｌｅ}

いくつかの実施例において、データのプライバシーが重要である。種々の実施例によれば、ＤＳＰおよびレーベルが、競合他社が分析データを表示できないようにするための２つの方法がある。すなわち、１）多層シャーディング、および、２）ゼロ知識証明である。

図３は、本開示の実施例に従う、多層シャーディングの例示的な図を示す。図３は、メインチェーン３０２、関係シャード３０４および３０８、ならびに地理的シャード３０６および３１０を示している。いくつかの実施例において、各レーベル－ＤＳＰ関係は、それ自体のシャード３０４または３０８にグループ化される。

いくつかの実施例において、ゼロ知識証明も、また、データのプライバシーを確保するために使用される。ゼロ知識証明により、ネットワーク参加者は、トランザクション内のデータを明らかにすることなく、トランザクションを暗号的に検証できる。いくつかの実施例において、チェーンに書き込まれるデータは、一方向の暗号化を使用する必要がある。これにより、チェーン上のすべてのデータは、データを復号化するためのキーを持っている当事者のみが読み取り可能になる。いくつかの実施例において、各関係シャードの復号鍵は、ＤＳＰとレーベルの間で共有される。

いくつかの実施例において、プラットフォームがＣＤＮのためのサーバーを所有することは、レーベルとＤＳＰとの間の最小の信頼を必要とするけれども、利用可能な代替の追跡方法が存在する。たとえば、プラットフォームは、ＤＳＰのアプリケーションで実行するソフトウェア開発キット（ＳＤＫ）またはライブラリを作成できる。このような例では、ＳＤＫの主な目的は、トランザクションの署名と検証に使用される適切な暗号化アルゴリズムをＤＳＰに提供することである。いくつかの実施例において、ＤＳＰは、再生イベントデータおよびそれらに関連する署名とともに、定期的に、または、特定のトリガーによってレポートを提供する必要がある。いくつかの実施例において、プラットフォームは、システムがストリーミングプラットフォーム上にエンドユーザーアカウントを作成し、再生がプロトコルに従ってカウントされていることを保証する監査システムを配置する。いくつかの実施例において、ＳＤＫを使用することの利点は、ＤＳＰがコンテンツを保持することができて満足するという事実を含む。いくつかの実施例において、この方法の欠点は、ＤＳＰが依然としてそれらのサーバー上のコンテンツを制御し、レーベルがＤＳＰの秘密監査を行うことによってのみ数値を検証できるという事実を含む。いくつかの実施例において、プラットフォームは、ＤＳＰのインターフェース（ウェブ、モバイルアプリ、デスクトップアプリ）のそれぞれのためのプラグインの実装を書かなければならないであろう。

いくつかの実施例において、別の代替追跡方法は、暗号化されたコーデックを含む。そのような実施例においては、プラットフォームは、ファイルがアクセスされるたびにファイルを暗号化するためのカスタムファイルタイプを作成することができる。いくつかの実施例において、ＤＳＰは、暗号化されたファイルをそれら自身のサーバー上に保持することができる。この暗号化方式では、ファイルを復号化するために、ユーザーによる署名付きの要求を取り込むことができる。いくつかの実施例において、この方法の利点には、オフラインのインターラクションをこの方法で信頼できない形で考慮に入れることができるという事実が含まれる。いくつかの実施例において、別の利点は、復号化ステップでユーザーのデータをファイルに密かにスタンプする可能性であるということである。いくつかの実施例において、さらに別の利点には、ＤＳＰがコンテンツを保持することができて満足しているという事実が含まれる。いくつかの実施例において、この方法の欠点には、新しい標準を研究および実装するための才能が必要であるという事実が含まれる。いくつかの実施例において、別の欠点は、コンテンツが再生されているデバイスのキャッシュにアクセスすることによってファイルのコンテンツを盗むためのベクトルがまだあるという事実を含む。いくつかの実施例において、さらに別の欠点は、ＤＳＰがプラットフォームが提唱するコーデック標準を実装しなければならないという事実である。

図４～１０は、音楽業界に対するより多くの背景と、音楽のライセンス供与およびストリーミングにおいてプラットフォーム（および開示されたシステムと方法）が果たす役割とについて、説明するために図説される。

図４は、本開示の実施例に従う、音楽産業がどのように連結されているかについての一例である図４００を示す。図４において、作曲家４０２は、音楽作品の著作権を出版社４０４に譲渡する。次の出版社４０４は、演奏権団体（ＰＲＯ）４２８に演奏ライセンスを付与します。ＰＲＯ４２８は、ラジオ／ＴＶ４２４、スタジアム４２２、ＤＳＰ４１８に包括的ライセンスを発行します。出版社４０４、出版社４０４は、また、シートミュージックプリンター４０６に複製ライセンス、外国の出版社４０８にサブパブリッシングライセンス、映画スタジオ４１０に同期ライセンス、およびレコード会社４１２に機械的ライセンスを与える。いくつかの実施例において、機械的ライセンスはハリーフォックスエージェンシー４１６を通る。レコード会社４１２は、また、実演者（パフォーマー）４２０から録音著作権の譲渡を受け、その後、ＤＳＰ４１８とのサウンド交換４１４を提供する。

図５は、本開示の実施例に従う、基本的な管理者の役割の一例の図５００を示す。最初に、管理ダッシュボード５１２は、曲作成要求５０２をサーバー５０４に送信する。次に、サーバー５０４は、ブロックチェーン５０８上に契約５０６を作成する。

図６は、本開示の実施例に従う、エンドユーザーの基本的なデータフローの一例の図６００を示す。図６００は、クライアントアプリケーション６１２が楽曲再生要求６０２をプラットフォームＣＤＮサーバー６１４、ブロックチェーン６０８、およびＤＳＰ認証サーバー６１６に送信することから始まる。次に、ＤＳＰ認証サーバー６１６は、ユーザーが実際にアクセスを許可されるブロックチェーンネットワーク６０８に通信して（６０４）、指定されたリソースにアクセスする。次に、ブロックチェーン６０８は、プレイがＣＤＮ６１４によって初期化される準備ができていることをクライアントアプリケーション６１２にブロードキャストする。最後に、プラットフォームＣＤＮサーバー６１４は、コンテンツをユーザー６１０に提供する。

図７は、本開示の実施例に従う、メディアファイル再生追跡ネットワークの一例の図７００を示す。ＤＳＰ７０２は、コンテンツ要求７０４をブロックチェーンネットワーク７０６に送信する。次に、ブロックチェーンネットワーク７０６は、要求７１６を検証する。要求が検証され、封印されたと見なされた後、ＣＤＮ７２０は、コンテンツ７１８をＤＳＰ７０２またはオリジナルの再生リクエストを作成したＤＳＰのエンドユーザーに提供する。検証されたトランザクションは、後で検査または監査するためにデータストレージソリューション７１０にアーカイブされる。定期的に、または、特定のイベント時に、ブロックチェーンデータのセグメントがそのマークルルートハッシュ７１４に抽出され、そのルートハッシュが第三者ブロックチェーンネットワーク７１２に書き込まれる。外部ブロックチェーンに書き込むためのメカニズムは、図１３においてさらに説明される。

図８は、いくつかの実装例に従う、ネットワーク環境内で情報を交換するためのシステム８００の例のシステム図を示している。システム８００は、互いに通信している様々な異なるハードウェアおよび／またはソフトウェアコンポーネントを含む。図８の非限定的な例において、システム８００は、少なくとも１つのシステムサーバー８０４、少なくとも１つのクライアントデバイス８０８を含む。いくつかの実施例において、システム８００は、少なくとも１つのデジタルサービスプロバイダ（ＤＳＰ）８８０を含む。いくつかの実施例において、システム８００はまた、音楽レーベル８８２、および／または少なくとも１人のアーティスト８８６を含む。いくつかの実施例において、音楽レーベル８８２は、アーティスト８８６からの音楽を表し、アップロードするけれども、時には、アーティスト８８６は、レコードレーベルを持たず、したがって、多くの場合、クライアントデバイス８０８は、音楽をシステムサーバー８０４に直接アップロードする。システム８００は、システムサーバー８０４が、ＤＳＰ８８０を介してクライアント８０８でストリーミングされている曲を追跡するのを支援することを可能にする。

システムサーバー８０４は、システム８００の他の構成要素と通信することができる。この通信は、ネットワークおよびインターフェースの組み合わせを介して促進されて良い。システムサーバー８０４は、クライアントデバイス８０８（直接コンテンツ配信モデルの場合）およびＤＳＰ８８０からのデータ要求およびデータ転送を取り扱いおよび処理することができる。同様に、システムサーバー８０４は、データ要求が処理された後にクライアントデバイス８０８に応答を返すことができる。例えば、システムサーバー８０４は、音楽レーベル８８２またはアーティスト８８６などの１つまたは複数のデータベースからデータを取得することができる。それは、異なるデータベースからのデータの一部またはすべてを組み合わせ、処理されたデータを１つまたは複数のクライアントデバイスまたはＤＳＰに送信することができる。

クライアントデバイス８０８およびＤＳＰ８８０は、１つまたは複数のデータネットワークを介してサーバーと通信することができるコンピューティングデバイスであって良い。クライアントデバイス８０８およびＤＳＰ８８０の例には、デスクトップコンピュータまたはスマートフォン、タブレット、ラップトップ、ウェアラブルデバイス、光学ヘッドマウントディスプレイ（ＯＨＭＤ）デバイス、スマートウォッチ、別個のサーバーなどの携帯型電子デバイスが含まれる。クライアントデバイス８０８およびＤＳＰ８８０は、アプリケーションが展開され得る少なくとも１つのブラウザを含む。

音楽レーベル８８２は、リレーショナルまたは非リレーショナルデータベース管理システムに実装されたデータベースであって良い。いくつかの実施例において、このデータベースは、ネットワーク環境内の１つまたは複数のクライアント関連データベースの内容を含んで良い。

アーティスト８８６は、レコード／音楽レーベルに関連付けられていない個々のアーティスト、または関連付けられているけれども、音楽レーベルによって満たされない特別な必要性を有するアーティストであって良い。いくつかの実施例において、アーティスト８８６との通信は、アーティストに関連する歌、アルバム、または任意の他のストリーミングメディアに関連する編集、修正、および／または追跡された変更情報を含むことができる。

図９は、本開示の実施例に従う、ＣＤＮアーキテクチャを利用するメディアファイルの再生を追跡するための方法９００のフローチャートを示す。方法９００は、メディアファイルおよびメディアファイルに関連付けられたメタデータをアップロードする要求を受信する（９０２）ことから始まる。次に、メディアファイルおよびメディアファイルに関連付けられたメタデータが、ブロックチェーンプロトコルを介してアップロードされる（９０４）。９０６において、クライアントデバイスまたはデジタルサービスプロバイダ（ＤＳＰ）プラットフォームからメディアファイルを再生する要求が受信される。９０８において、メディアファイルを再生する要求は、ブロックチェーンプロトコルを介して検証される。９１０において、メディアファイルを再生する要求を検証すると、メディアファイルは、クライアントデバイスまたはＤＳＰプラットフォームで再生するために送信またはストリーミングされる。ただし、待ち時間を低く抑えるために、リクエストが検証される前に、メディアファイルの先頭のごく一部がエンドユーザーにストリーミングされる可能性がある。最後に、メディアファイルが所定の長さまで再生された回数がブロックチェーンプロトコルを介して追跡される（９１２）。

いくつかの実施例において、ブロックチェーンプロトコルは、権限証明アルゴリズムを利用する。いくつかの実施例において、要求を検証することは、複数のシーラーからの１または複数の許可されたシーラー（バリデーションノード）による要求を暗号的に検証することを含む。いくつかの実施例において、メディアファイルを再生する要求は、指定された時間にコンテンツにアクセスするためのブロックチェーンへの要求を含む。いくつかの実施例において、ブロックチェーンへの要求は、それらがブロックチェーンにヒットするとすぐにファイナライズすることができ、それにより、任意の順序でブロックチェーンに追加することができる。いくつかの実施例において、メディアファイルの短いバッファは、メディアファイルを再生する要求を受信した後即座にストリーミングされるけれども、メディアファイルの残りは、再生要求が検証された後にのみストリーミングされる。いくつかの実施例において、ブロックチェーンクライアントの異なるバージョンは、それらがプラットフォームプロトコル規則に従うと仮定して、異なるクライアントに使用することができる。

図１０は、本開示の実施例に従う、非ＣＤＮアーキテクチャを使用してメディアファイル再生を追跡するための方法１０００のフローチャートを示す。方法１０００は、プラットフォームストリームからトランザクションデータを受信すること（１００２）から始まる。いくつかの実施例において、ストリームは、時間の経過とともに利用可能になる一連のデータ要素である。ストリームは、トランザクション要求の取り込みポイントとして機能し、トランザクション要求を関係者に出力する。いくつかの実施例において、関連するストリームは、任意の数の登録済みまたは信頼できる検証ノート、例えば、ＤＳＰ、プラットフォーム、レーベル、またはディストリビューターであって良い。いくつかの実施例において、検証ノード（ｖａｌｉｄａｔｉｏｎ ｎｏｄｅ、「有効化ノード」ともいう）は、信頼されるようになるために、事前に登録プロセスを経なければならない。いくつかの実施例において、エンドユーザーデバイスは、トランザクションデータを作成して署名し、次にそのデータをプラットフォームストリームに送信する。トランザクションデータは、エンドユーザーからのメディアファイルの再生要求に対応している。いくつかの実施例において、トランザクションデータは、エンドユーザーに対応する暗号署名を含む。これは、最初のリクエストがエンドユーザーからのものであることを確認するためである。

次に、トランザクションデータが検証される（１００４）。いくつかの実施例において、トランザクションデータの検証には、以下の検証が含まれる。すなわち、１）トランザクションデータのフォーマットがプラットフォームによって確立されたプロトコルに従っているかどうか、および２）トランザクションデータが、エンドユーザーに対応する公開鍵で検証できるエンドユーザーの暗号署名を含むかどうか、である。１００６において、暗号署名を使用して検証されたトランザクションデータが、署名される。いくつかの実施例において、署名者は、受信検証ノードである。つまり、トランザクションリクエストが検証されると、受信側の検証ノードが独自の暗号署名を追加する。

１００８において、トランザクションデータが有効なブロックチェーントランザクションに対応するかどうかが決定される。いくつかの実施例において、ブロックチェーントランザクションは、それが少なくとも２つの検証ノード／シーラーによって署名されている場合に有効であると見なされる。トランザクションデータが有効なブロックチェーントランザクションに対応している場合、有効なブロックチェーントランザクションがブロックチェーンに記録される。いくつかの実施例において、ステップ１００６で受信検証ノードによって追加されたばかりの署名は、トランザクションを有効であるとみなすために必要な第２の署名であって良い。いくつかの実施例において、ブロックチェーンは、プラットフォームのブロックチェーンまたはプラットフォームのブロックチェーンのコピーである。いくつかの実施例において、ブロックチェーンは、プルーフオブワークアルゴリズムを利用する。

最後に、トランザクションデータおよび暗号署名は、１つまたは複数の検証ノードに送信される（１０１０）。いくつかの実施例において、トランザクションデータおよび暗号署名は、ストリームに再送信される。受信ノードがプラットフォームの場合、他の検証ノードはＤＳＰ、レーベル、またはディストリビューターである可能性がある。受信ノードがＤＳＰの場合、他の検証ノードはプラットフォーム、レーベル、またはディストリビューターである可能性がある。いくつかの実施例において、特にステップ１００２で受信されたトランザクションデータが２つ未満の検証ノード署名を含む場合、トランザクションデータおよび新しい署名を他のノードに送信することは、検証プロトコルを伝播する。

図１１は、本開示の実施例に従う、メディアファイル再生を追跡するための例示的な非ＣＤＮプラットフォームアーキテクチャを示す。エンドユーザー１１０２は、再生要求を作成し、ＤＳＰ１１０４に送信する。要求を検証および有効化した後、ＤＳＰ１１０４は、コンテンツをエンドユーザー１１０２にストリーミングする。曲の再生要求のカウントは、ＤＳＰ１１０４によってストリームに送信され、次に、検証ノード１１０６のネットワークに要求を送信する。検証ノード１１０６のネットワークは、プラットフォーム１１１０を含み、プラットフォーム１１１０は、要求カウントを受信し、次に、要求カウントをレーベル１１１２に伝播し、ＤＳＰ１１０４に戻す。要求は検証され、生のキャプチャされたデータ１１１４としてデータベースに別個に格納される。いくつかの実施例において、生のキャプチャされたデータは、プラットフォームのアーカイバによって、ストレージ、例えば、構造化クエリ言語（ＳＱＬ）データベースに書き込まれる。いくつかの実施例において、この生のキャプチャされたデータは、別個のＡＰＩ１１１６を照会することによって、許可された関係者に利用可能にされる。いくつかの実施例において、プラットフォーム１１１０に格納されたブロックチェーン上のデータは、マークルルートと呼ばれる一見ランダムな文字列にマークル化される。次に、これらのマークルルートは、外部のプルーフオブワークブロックチェーンなどのサードパーティ／パブリック外部ブロックチェーン１１１８にコミットされる。これにより、外部のサードパーティブロックチェーンのハッシュパワーが増加すると、ブロックチェーンの整合性の改ざんに関連するコストが増加するため、セキュリティの追加ポイントが提供される。

図１２は、本開示の実施例に従う、トランザクション構造の例を示している。トランザクション１２０２は、要求データ１２０６、エンドユーザー署名１２０８、および場合によっては１つまたは複数の検証ノード署名１２１０、１２１２、または１２１４を含むデータ構造である。いくつかの実施例において、要求データ１２０６は、要求ＩＤ１２０４を含み、これはトランザクション自体に固有の識別子である。たとえば、サンプル要求ＩＤ １２０４は、エンドユーザーの公開鍵をトランザクションの日時と連結することで生成できる。いくつかの実施例において、要求データ１２０６は、曲を再生するための要求に関する情報を含む。例えば、要求データ１２０６は、曲のタイトル、曲が再生された時間、誰が曲を要求したか、および／または曲の再生の持続時間に関する情報を含んで良い。いくつかの実施例において、エンドユーザー署名１２０８は、エンドユーザーを一意に識別する公開鍵と秘密鍵のペアを含む。いくつかの実施例において、対の公開鍵と秘密鍵は数学的関係を共有する。いくつかの実施例において、検証ノードの署名も同じである。図１２は、検証ノードを「パーティＡ」、「パーティＢ」、および「パーティＺ」として示しているけれども、パーティは、ＤＳＰ、プラットフォーム、ラベル、およびディストリビューターのいずれかを指し示すものであって良い。

図１３は、本開示の実施例に従う、トランザクションのデータフロー１３００の例を示している。データフロー１３００は、エンドユーザーによって作成されるトランザクションデータ（１３０２）から始まる。次に、データはエンドユーザーによって署名される（１３０４）。いくつかの実施例において、署名は、エンドユーザーを一意に識別する暗号署名である。次に、データおよびユーザー署名がストリーム１３０６に送信される。いくつかの実施例において、ストリームは、エンドユーザーおよび検証ノードからのアクセスポイントを備えた単一のストリームであって良い。いくつかの実施例において、ストリームは、各検証ノードに固有である。いくつかの実施例において、ストリームは、異なるノードからの異なるストリームの階層であって良い。データおよびユーザー署名がストリーム１３０６にヒットした後、データおよびユーザー署名は、複数の検証ノード（パートＡ…パーティＺ）に送信される。次に、ノードはデータとエンドユーザーの署名を検証する（１３１０、１３０８）。検証後、ノードはデータ自体に署名する（１３１４、１３１６）。次に、データとノードの署名がストリームに送信される（１３１８、１３２０）。いくつかの実施例において、ノードは、オプションで、他のバリデーターによってトランザクションに添付された他の署名を収集することができる（１３２２、１３２４）。

図１４は、本開示の実施例に従う、トランザクションのデータフロー１４００の他の例を示している。データフロー１４００は、エンドユーザーによって作成されるトランザクションデータから始まる（１４０２）。次に、データはエンドユーザーによって署名される（１４０６）。いくつかの実施例において、署名は、エンドユーザーを一意に識別する暗号署名である。次に、データおよびユーザー署名が特定の検証ノードであるパーティＡに送信される（１４０８）。いくつかの実施例において、パーティＡはＤＳＰである。次に、パーティＡは、データとエンドユーザーの署名を読み取って検証する（１４１０）。データとエンドユーザーの署名を確認した後、パーティＡは独自の暗号化署名を使用してデータに署名する（１４１２）。次に、データ、エンドユーザーの署名、およびパーティＡの署名がストリームに送信される（１４１４）。いくつかの実施例において、ストリームは、エンドユーザーおよび検証ノードからのアクセスポイントを備えた単一のストリームであって良い。いくつかの実施例において、ストリームは、各検証ノードに固有である。いくつかの実施例において、ストリームは、異なるノードからの異なるストリームの階層であって良い。データ、ユーザー署名、およびパーティＡの署名がストリーム１４１４にヒットした後、データ、ユーザー署名、およびパーティＡの署名が複数の検証ノード（パートＢ…パーティＺ）に送信される。次に、ノードはデータとエンドユーザーの署名を検証する（１４１６、１４１８）。検証後、ノードはデータ自体に署名する（１４２０、１４２２）。次に、データとノードの署名がストリームに送信される（１４２４、１４２６）。いくつかの実施例においては、ノードは、オプションで、他のバリデーターによってトランザクションに添付された他の署名を収集することができる（１４２８、１４３０）。

図１５は、本開示の実施例に従う、例示的な非ＣＤＮプラットフォームアーキテクチャ１５００のフローチャートを示す。着信要求１５０１は、エンドユーザーによって作成され、エンドユーザーによって署名され、次いで、ストリーム１５０２に送信される。いくつかの実施例において、要求１５０１は、曲を再生するための要求である。次に、ストリーム１５０２は、バリデーターＡ（１５０４）、バリデーターＢ（１５０６）、およびバリデーターＣ（１５０８）に要求を渡し、これが、プラットフォームのプロトコルに従って検証される。各バリデーターがリクエストを確認して署名すると、ストリームに再送信される。いくつかの実施例において、２つの異なるバリデーターが要求に署名すると、それは有効であると見なされ、次いで、要求は、別個のデータベースに格納されるためにプラットフォームアーカイバ１５１０に送信される。

図１６は、本開示の実施例に従う、例示的な非ＣＤＮプラットフォームアーキテクチャ１６００の他のフローチャートを示している。着信要求１６０１は、エンドユーザーによって作成され、エンドユーザーによって署名され、次いで、バリデーターＡ（１６０４）に送信される。いくつかの実施例において、要求１６０１は、曲を再生するための要求である。バリデーターＡはリクエストを検証し、リクエストに署名した後、リクエストをストリーム１６０２に送信する。ストリーム１６０２は、バリデーターＢ（１６０６）とバリデーターＣ（１６０８）にリクエストを渡し、これはプラットフォームのプロトコルに従って検証される。各バリデーターがリクエストを確認して署名すると、ストリームに再送信される。いくつかの実施例において、２つの異なるバリデーターが要求に署名すると、それは有効であると見なされ、次いで、要求は、別個のデータベースに格納されるためにプラットフォームアーカイバ１６１０に送信される。

先に説明した種々の実施例は、単一の再生カウントを正確に追跡することを指す。一部のロイヤルティ契約では、権利所有者への支払いは、特定のファイルが消費者に提供される回数に左右されるため、これは重要である。ただし、特定の状況では、単一の嗄声カウントを追跡するだけでは不十分な場合がある。たとえば、一部のロイヤルティ契約では、曲の支払いは、少なくとも閾値期間中に再生されているメディアファイルに依存する。単純な実施形態において、これは単純なバイナリ測定で解決することができる。すなわち、以下のとおりである。メディアファイルがストリーミングされた秒数は、指定されたしきい値を超えましたか？たとえば、いくつかの実施例において、コンテンツが少なくとも３０秒間ストリーミングまたは聴取された後にのみ、再生がカウントされる。これは、北米で音楽ストリーミングの使用量を測定するために使用される主な方法である。

いくつかの実施例において、メディアファイルのどのセグメントが閲覧および／または聴取されたかを知ることが重要である。そのような実施例において、広告はしばしばメディアコンテンツ内に埋め込まれる。ほとんどのオーバーザトップ（ＯＴＴ）メディア、ケーブルＴＶ、衛星ＴＶ、インターネットＴＶ、またはビデオストリーミングプラットフォームの場合、エンドユーザーが広告またはコンテンツの再生を表示した回数に基づいて、権利所有者への支払いが発生する。各広告ビューには、広告ビューと見なされるために表示する必要のある広告の量に関する独自の閾値があって良い。したがって、具体的な実施例において、特定の再生期間の閾値が満たされることを保証するため、または再生がカウントされる前に特定のメディアセグメントが再生されることを保証するために、ストリーミングまたはメディアファイルの再生を継続的に追跡できることが重要であろう。

種々の実施例によれば、離散的な再生をカウントするために、カウント機能は１回実行される必要がある。いくつかの実施例において、連続ストリーミングを追跡する場合、利用可能な複数のオプションがあり、それらのいくつかを組み合わせることができる。

いくつかの実施例において、再生されたメディアファイルの一部は、ユーザーデバイスにローカルに保存される。このように、曲の再生が完了するまで、カウント機能は実行されない。この方法の利点の１つは、関数呼び出しをカウントする頻度が減ることである。ただし、この方法では、データのカウントをリアルタイムで実行することはできない。

図１７Ａ～１７Ｂは、本開示の実施形例に従う、ローカル永続性を使用してメディアファイル再生を連続的に追跡するための方法１７００および１７５０のフローチャートを示す。

１７０２で、アプリケーションを介してメディアファイルまたはメディアストリームを再生するためのユーザーが開始した要求が、ユーザーデバイスで受信される。いくつかの実施例において、これは、ユーザーがストリーミングアプリケーションを開き、ユーザーデバイス上でメディアファイル、例えば、メディアファイルＡの再生を開始するときに発生する可能性がある。

１７０４において、エントリは、メディアファイルまたはメディアストリームを再生するためのユーザーが開始した要求に対応するローカルＲＡＭまたはローカルディスクに記録される。いくつかの実施例において、ユーザーがメディアファイルの再生を開始したときにエントリが作成される。いくつかの実施例において、エントリは、メディアファイルの名前、メディアファイルの権利所有者の名前、および／またはメディアファイルを識別するのを支援することができる任意の他のタイプのメタデータを含んで良い。さらに、いくつかの実施例において、再生を開始したユーザーは、自分の秘密鍵を使用して、再生開始の詳細に署名し、その署名をトランザクションの他の詳細とともにローカルに保存する。

１７０６において、メディアファイルまたはメディアストリームの現在の再生位置は、所定の間隔でローカルラムまたはローカルディスクに記録される。たとえば、Ｘ秒ごとに、ユーザーのストリームの現在の位置がＲＡＭまたはディスクに記録される。いくつかの実施例において、これらの間隔で、ユーザーの秘密鍵を使用して、ローカルに保存されているデータに署名する。いくつかの実施例において、ユーザーが次のメディアファイル、例えば、メディアファイルＢへとスキップする場合、メディアファイルＢが再生を開始したことを示す別のエントリがデバイス上に作成される。いくつかの実施例において、メディアファイルＡが開始されてストリーミングされたときと同じ詳細が記録される。

１７０８において、エントリおよび記録された再生位置は、ブロックチェーン上で記録するためにプラットフォームストリームに送信される。これは、現在ローカルにネットワークストレージまたはブロックチェーンに保存されているデータを永続化するために、データをプラットフォームストリームに通信する必要があるためである。いくつかの実施例において、データは、以下の条件の１つまたは複数が満たされた場合にのみプラットフォームストリームに送信される。すなわち、１）ネットワーク接続が利用可能になる、２）アプリケーションとのユーザー対話が受信される、３）所定の時間プラットフォームストリームへの前回のネットワーク送信以降に経過し、４）ローカルＲＡＭまたはローカルディスクに保存されているデータの所定のしきい値に達した場合である。いくつかの実施例において、アプリケーションとのユーザー対話は、再生する新しいメディアファイルの選択、メディアファイルの停止、メディアファイルの一時停止、新しい位置へのシーク、早送りまたは巻き戻し、または再生を押すことを含む。

いくつかの実施例において、データがプラットフォームストリームに送信されるとき、ユーザーの公開鍵がデータセットに追加され（１７１０）、それを使用して、他のエンティティによる要求の発信元を検証することができる。いくつかの実施例において、この公開鍵は、ユーザーの署名を生成するために使用される秘密鍵を検証することによって、発信元を検証する。いくつかの実施例において、これは、不正なプレイカウントを防ぐために重要である。

いくつかの実施例において、データがローカルに永続化されるとき、各要求は秘密鍵で署名される。他の実施例において、データは、プラットフォームストリームに送信される直前にのみ署名されるため、署名の頻度が減少する。このような実施例において、データは、ユーザーの秘密鍵によって署名される前に統合することができる。署名は、プラットフォームストリームに送信される前に、リクエストに１回だけ追加される。

図１７Ｂは、方法１７５０を示しており、これは、データがプラットフォームストリームを介してプラットフォームサーバーに送信された後に何が起こるかの例を説明している。いくつかの実施例において、方法１７５０は、上記の方法１０００と同様である。いくつかの実施例において、方法１７５０は、エンドユーザーデバイスおよびプラットフォームサーバーで実行される統合された方法として、方法１７０００と組み合わせて良い。

１７５２において、プラットフォームストリームからのトランザクションデータが受信される。いくつかの実施例において、トランザクションデータは、エンドユーザーからのメディアファイルを再生するための要求に対応する。いくつかの実施例において、トランザクションデータは、方法１７００でプラットフォームストリームに送信されるエントリおよび記録された再生位置と同様に、所定の間隔でのメディアファイルまたはメディアストリームの記録された再生位置を含む。

１７５４において、トランザクションデータが検証される。いくつかの実施例において、トランザクションの検証は、エンドユーザーに関連付けられた公開鍵を使用すること（１７５６）を含み、トランザクションデータの出所を検証するためにトランザクションデータに追加される。いくつかの実施例において、トランザクションデータの検証は、方法１０００のステップ１００４でトランザクションデータを検証するために使用されるすべてのステップを含む。

１７５８において、検証されたトランザクションデータは署名され、プラットフォームサーバーに関連付けられた暗号署名を生成する。１７６０において、検証されたトランザクションデータがブロックチェーンに記録される。いくつかの実施例において、トランザクションデータは、方法１０００のステップ１００６および１００８のように、トランザクションデータが有効なブロックチェーントランザクションであると決定された場合にのみ記録される。１７６２において、トランザクションデータおよび暗号署名は、メソッド１０００のステップ１０１０のように、１つまたは複数の検証ノードに送信される。

図１７Ａ～１７Ｂは、局所持続性を使用する連続追跡の方法を説明している。いくつかの実施例において、ファイルのどのセグメントが消費されたかを継続的に追跡する第２の方法は、サーバーからエンドユーザーにバッファリングされたものを測定することである。この方法は、メディアファイルがＣＤＮから直接配信されるシステムで特に役立つ。このような場合、コンテンツをユーザーに送信しているサーバーは、ユーザーが実際にストリーミングしているセグメントを測定できるデバイスである。この方法の欠点は、一部のバッファリングされたコンテンツが実際にはエンドユーザーによって再生されない可能性があることである。

図１８Ａ～１８Ｂは、バッファ近似を使用する連続追跡の方法を説明している。方法１８００はユーザーデバイスで起こり、方法１８５０はプラットフォームまたはコンテンツ配信サーバーで起こる。１８０２において、アプリケーションを介してメディアファイルまたはメディアストリームを再生するためのユーザーが開始した要求が、エンドユーザーデバイスで受信される。いくつかの実施例において、これは、ユーザーがユーザーデバイス上でストリーミングアプリケーションを開き、ファイル、例えば、メディアファイルＡのストリーミングを開始したいときに発生する。１８０４において、メディアファイルまたはメディアストリームの参照データが生成される。１８０６において、ユーザーの秘密鍵は、ユーザー署名を使用して参照データに署名するために使用される。いくつかの実施例において、このユーザー署名は、メディアファイルの一意の識別子であって良い。１８０８でにおいて、参照データ、ユーザー署名、およびユーザーに関連付けられた公開鍵がプラットフォームストリームに送信され、ブロックチェーンに記録される。

ここでサーバー側に切り替えると、方法１８５０は、バッファ近似を使用する連続追跡におけるプラットフォームまたはコンテンツ配信サーバーの役割を説明する。１８５２において、署名されたユーザーが開始した、メディアのストリーミング、またはアプリケーションを介したメディアファイルまたはメディアストリームの再生要求がユーザーデバイスから受信される。いくつかの実施例において、この署名されたユーザー開始要求は、ステップ１８０８で送信された、参照データ、ユーザー署名、およびユーザーに関連付けられた公開鍵を含む。１８５４において、メディアファイルまたはメディアストリームは、ユーザーデバイスへの送信を開始する。１８５６において、サーバーは、メディアファイルまたはメディアストリームのどのセグメントがブロックチェーン上のユーザーデバイスにバッファリングされたかを記録する。いくつかの実施例において、セグメントを記録することは、上述のように、トランザクションデータを検証し、トランザクションが有効なブロックチェーントランザクションを構成するかどうかを決定することを含む。

ユーザーデバイスに戻ると、１８１０において、ユーザーは、プラットフォームストリームからメディアファイルまたはメディアストリームのセグメントを受信し、バッファリングする。いくつかの実施例において、ユーザーがより多くのセグメントを特に要求せず、また別のユーザーインターラクションイベントをサーバーに発行しない場合、ユーザーデバイスは、メディアファイルまたはメディアストリームがストリーミングを終了させるまで、メディアファイルまたはメディアストリームのセグメントを受信し、バッファリングし続ける。そのような実施例において、その間ずっと、サーバーがユーザーインターラクションイベントを受信しない場合、サーバーはセグメントをユーザーデバイスに送信し続け、ブロックチェーンにバッファリングされたコンテンツのセグメントを記録する。ここで使用される場合、「コンテンツ」および「メディアファイル」または「メディアストリーム」は交換可能に使用される。いくつかの実施例において、送信されたすべてのコンテンツが記録されている限り、送信および記録の順序は重要ではない。いくつかの実施例において、サーバーからコンテンツを送信することは、送信バッファも含む。そのような実施例において、実際に送信されたセグメントではなく、サーバー側でバッファリングされたセグメントを記録することもオプションである。

いくつかの実施例において、ユーザーデバイスがセグメントのバッファリングを終了すると、ユーザーデバイスは、バッファリングのために送信されるコンテンツの追加のセグメントを自動的に要求する。いくつかの実施例において、ユーザーは、追加のセグメントを能動的／手動で要求しなければならない。いくつかの実施例において、ユーザーが手動または自動のいずれかでより多くのコンテンツをバッファリングすることを要求するときはいつでも、ユーザーのデバイスは、コンテンツのどの部分をストリーミングする必要があるかを指定しなければならない。したがって、１８１２において、プラットフォームストリームからのメディアファイルまたはメディアストリームの追加のセグメントの送信のための要求データが生成される。いくつかの実施例において、要求データは、メディアファイルまたはメディアストリームのどの部分が送信されるかを正確に指定する。いくつかの実施例において、ユーザーの秘密鍵は、追加のセグメントの要求に署名するために再び使用される。１８１４において、追加のセグメントの送信、および、ブロックチェーンへの記録のために、要求データ、ユーザー署名、およびユーザーの公開鍵がサーバーに伝達される。

最後に、サーバー側に戻ると、１８５８において、サーバーは、追加のセグメントを再生するための追加の要求を受信する。いくつかの実施例において、追加の要求は、要求データ、ユーザー署名、およびステップ１８１４で送信されるユーザーの公開鍵を含む。ステップ１８５４および１８５６と同様に、サーバーは、要求された追加のセグメントを送信し（１８６０）、ブロックチェーン上のユーザーデバイスにバッファリングされているすべてのセグメントを記録する（１８６２）。

図１７Ａ～１８Ｂは、連続追跡のための２つの方法を説明している。いくつかの実施例において、エンドユーザーによって再生されるセグメントを継続的に追跡するさらに他の方法は、メディアファイルのどの部分がユーザーデバイス上で現在再生されているかを絶えずポーリングまたはサンプリングすることである。この方法では、ユーザーデバイスまたはプラットフォームサーバー、あるいはサードパーティのデバイスでさえ、ブロックチェーンに記録するためにストリームを定期的にサンプリングできる。ユーザーデバイスまたはサードパーティデバイスがストリームをサンプリングする場合、いずれかのデバイスが各サンプルをオンザフライで送信するか、各デバイスがサンプルをローカルに永続化して後でプラットフォームサーバーに送信することができる。プラットフォームサーバーがサンプリングを行う場合、サンプルが有効なブロックチェーントランザクションであれば、サンプルをブロックチェーンに直接記録できる。サンプリングの欠点の１つは、ストリームを継続的にポーリングまたはサンプリングする必要があることである。その結果、ポーリングの頻度が高くなると、測定精度が向上する。

いくつかの実施例において、連続追跡のためのさらに他の方法は、すべてのユーザーインターラクションを記録することに依存している。そのような実施例において、メディア消費の状態が既知の状態である場合、メディアファイルのどの部分が表示されたかのおおよその尺度として、ユーザーのすべてのインターラクションを（リモートまたはローカルで）記録することができる。例えば、図１９は、記録されたユーザーのインターラクションを使用して連続的に追跡するための方法１９００を説明している。

１９０２において、アプリケーションを介して第１のメディアファイルまたはメディアストリームの第１の個別部分を再生するための署名されたユーザー開始要求が、ユーザーデバイスから受信される。例えば、いくつかの実施例において、ユーザーは、ストリーミングアプリケーションを開き、メディアファイル、例えば、メディアファイルＡのストリーミングを開始したいので、ユーザーは、アプリケーションで再生を押す。いくつかの実施例において、ユーザーの秘密鍵は、「再生」の開始を署名するために使用される。

１９０４において、第１のメディアファイルまたはメディアストリームの第１の個別の部分は、ユーザーデバイスへの送信を開始する。１９０６において、ユーザーデバイスへの最初のメディアファイルまたはメディアストリームの最初の個別部分の送信の開始イベントがブロックチェーンに記録される。

１９０８において、署名されたユーザーインターラクションイベントがユーザーデバイスから受信された場合、署名されたユーザーインターラクションイベント、および署名されたユーザーインターラクションイベントの時点での第１のメディアファイルまたはメディアストリームの第１の離散的部分の現在の再生位置が、ブロックチェーンに記録される。たとえば、ファイルのストリーミングを数秒行った後、ユーザーはメディアファイルＡの途中までシークする。シークイベントの直前のユーザーの位置がシークイベントとともに記録される。いくつかの実施例において、シークイベントが記録されるときに、ユーザーの秘密鍵がインターラクションに署名するために使用される。

いくつかの実施例において、ファイル終了イベントは、ユーザーインターラクションイベントを受信する前に、第１のメディアファイルまたはメディアストリームの第１の個別部分がストリーミングを終了した場合、ブロックチェーンに記録される（１９１０）。つまり、ユーザーはストリーミングアプリケーションをこれ以上操作せずに、ストリームを終了させることができる。いくつかの実施例において、ユーザーが自動再生をオンにしている場合、メディアファイルＡが終了した後にメディアファイルＢがストリーミングを開始する。このような実施例において、「再生」イベントは、ユーザーがメディアファイルＡで行ったように、ユーザーが再生を打ったかのように開始される。メディアファイルＢに関連付けられた再生イベントとメディアファイルＡに関連付けられた再生イベントとの主な違い（ファイルのコンテンツとメタデータが異なることを除いて）は、前のファイルのユーザーのストリーミング位置はメディアファイルＢの再生イベントに含まれまるけれども、メディアファイルＡには含まれないという点である。この場合、メディアファイルＡに対して記録されたストリーム位置は、メディアファイルＡの期間と同じになる。

１９１２において、第２のメディアファイルまたはメディアストリームの第２の離散部分がユーザーデバイスに送信される場合、第２のメディアファイルまたはメディアストリームの第２の離散部分の開始イベントをブロックチェーンに記録する。つまり、ユーザーがストリーミングアプリケーションを介したコンテンツのストリーミングを停止した場合、「停止」イベントが作成される。次に、停止イベントが開始される直前のメディアファイルＢでのユーザーの位置が記録され、停止イベントに追加される。いくつかの実施例において、ユーザーの秘密鍵は、インターラクションに署名するために使用される。

いくつかの実施例において、各イベントの署名およびユーザーの公開鍵を含む、これらのインターラクションイベントに関連するデータは、デバイス上にローカルに格納され、断続的にアップロードされることができ、または、またはそれらが発生したときにプラットフォームストリームに送信されて良い。

種々のコンピューティングデバイスが、ここで説明された方法を実装することができる。たとえば、モバイルデバイス、コンピュータシステムなどは、クライアント、音楽レーベル、またはＤＳＰのいずれかによってネットワーク環境の側面にアクセスするために使用できる。図２０を参照すると、本開示の特定の例を実施するために使用することができるコンピュータシステムの特定の例が示される。例えば、コンピュータシステム２０００を使用して、上記の様々な実施例による人工的にレンダリングされた画像を生成することができる。さらに、ここに示されるコンピュータシステム２０００は、モバイルデバイス上のコンピューティングシステムを表すことができる。特定の例示的な実施例によれば、本開示の特定の実施例を実施するのに適したシステム２０００は、プロセッサ２００１、メモリ２００３、インターフェース２０１１、およびバス２０１５（例えば、ＰＣＩバス）を含む。インターフェース２０１１は、別個の入力インターフェース２０１３および出力インターフェース２０１５を含んで良く、または、両方の動作をサポートする統合インターフェースであって良い。適切なソフトウェアまたはファームウェアの制御下で動作する場合、プロセッサ２００１は、最適化などのタスクを担当する。プロセッサ２００１の代わりに、またはプロセッサ２００１に加えて、様々な特別に構成されたデバイスを使用することもできる。完全な実装は、カスタムハードウェアで行うこともできる。インターフェース２０１１は、通常、ネットワークを介してデータパケットまたはデータセグメントを送受信するように構成される。デバイスがサポートするインターフェースの特定の例には、イーサネットインターフェース、フレームリレーインターフェース、ケーブルインターフェース、ＤＳＬインターフェース、トークンリングインターフェースなどが含まれる。

さらに、高速イーサネットインターフェース、ギガビットイーサネットインターフェース、ＡＴＭインターフェース、ＨＳＳＩインターフェース、ＰＯＳインターフェース、ＦＤＤＩインターフェースなどのような様々な非常に高速なインターフェースが提供されて良い。一般に、これらのインターフェースには、適切なメディアとの通信に適したポートが含まれている場合がある。いくつかの例では、独立したプロセッサや、他のいくつかの例では、揮発性ＲＡＭも含まれて良い。独立したプロセッサは、パケット交換、メディア制御、管理などの通信集約型タスクを制御して良い。

特定の例示的な実施例によれば、システム２０００は、メモリ２００３を使用して、データおよびプログラム命令を格納し、ローカルサイドキャッシュを維持する。プログラム命令は、例えば、オペレーティングシステムおよび／または１つまたは複数のアプリケーションの動作を制御することができる。１つまたは複数のメモリは、受信したメタデータとバッチ要求されたメタデータを格納するように構成されて良い。

そのような情報およびプログラム命令は、本明細書に記載のシステム／方法を実装するために使用できるので、本開示は、本明細書に記載の様々な操作を実行するためのプログラム命令、状態情報などを含む有形の機械可読媒体に関する。機械可読メディアの例は、ハードディスク、フロッピーディスク、磁気テープ、ＣＤ－ＲＯＭディスクやＤＶＤなどの光学メディアが含まれる。光ディスクなどの磁気光学媒体、および読み取り専用メモリデバイス（ＲＯＭ）やプログラム可能な読み取り専用メモリデバイス（ＰＲＯＭ）などのプログラム命令を格納および実行するように特別に構成されたハードウェアデバイスを含む。プログラム命令の例には、コンパイラーによって生成されるようなマシンコードと、コンピュータがインタープリターを使用して実行できる高レベルのコードを含むファイルの両方が含まれる。

図２１は、３つのデータセグメント２１０２、２１０４、および２１０６で表されるリンクリストデータ構造２１００を示す。従来のブロックチェーンは、データの各セグメントが以前に作成されたデータのセグメントを参照するように、リンクリストと同様に構造化される。例えば、データセグメント２１０６は、任意のデータのセットを含む。データセグメント２１０６がデータセット全体の一部になるために、それは、その前にあるデータセグメントへの参照を含む。この場合、データセグメント２１０４はデータセグメント２１０６の前に来るので、データセグメント２１０６はデータセグメント２１０４への参照を含む。いくつかの実施例において、リンクされたリストへの最初のエントリ、図２１のデータセグメント２１０２は、他のデータセグメントへの参照を持たない。

図２２は、ブロックチェーン２２００の概念的な例を示している。各ブロック（２２０２、２２０４、および２２０６）は、その中にデータのセットを含む。このデータは任意に設定できるけれども、伝統的にはトランザクションのリストである。図１１のリンクリストと同様の構成において、各ブロックは、その前のブロックへの参照を有する。データ構造としてのブロックチェーンの際立った特徴の１つは、各ブロックに保持されているデータが改ざんされていないことを示す暗号化された証拠が含まれていることである。

プラットフォームのネットワーク全体の履歴データが改ざんされていないことを保証するために、データのセグメントが定期的に集約され、「マークルルート」と呼ばれる一見ランダムな文字列にマークル化される。図２３は、このマークル化プロセス２３００の例を示している。図２３に示されるように、プラットフォームブロックチェーン２３０８上のデータ２３０４のセグメントは、集約され、マークルルート２３０６にマークル化される。次に、データセットのこれらのマークルルートは、プルーフオブワークまたはプルーフオブステークなどの任意のコンセンサスアルゴリズムによって裏付けられる可能性があるサードパーティブロックチェーン２３０２に書き込まれる。これは、セキュリティの補足ポイントまたは監査ポイントとして機能する。プラットフォームのブロックチェーン２３０８の外側にある監査ポイントを作成する背後にある動機は、サードパーティのネットワーク２３０２も攻撃する必要があるため、プラットフォームのブロックチェーンで実行される攻撃は実行するのに費用がかかるためである。例えば、図２３は、プラットフォームのデータセット２３０４の一部のマークル化の例を示す。プラットフォームのブロックチェーンの特定のセグメントからのものであると主張されるデータのセットが与えられると、データのセットをマークル化し、サードパーティのブロックチェーン２３０２に存在するのと同じマークルルートが生成されることを確かめて、真実性を結論付けることができる。

構成要素およびプロセスの多くは、便宜上、単数で説明されているけれども、複数の構成要素および反復プロセスも、また、本開示の技術を実施するために使用できることが当業者によって理解されるであろう。

本開示は、その特定の実施例を参照して特に示され、説明されてきたけれども、開示された実施例の形態および詳細の変更は、この開示の精神または範囲から逸脱することなく行われ得ることが当業者によって理解されるであろう。したがって、本開示は、その真の精神および範囲内にあるすべての変形および均等物を含むと解釈されることが意図されている。

Claims (20)

1. ブロックチェーンベースのプラットフォームを介してメディアファイルまたはメディアストリームの再生を継続的に追跡するためのシステムであって、
   プロセッサと、
   メモリであって、上記プロセッサに方法を実行させるための命令を格納する上記メモリとを有する、上記システムにおいて、
   上記方法は、
   アプリケーションを介してメディアファイルまたはメディアストリームを再生するためのユーザー始動要求を受信するステップと、
   上記メディアファイルまたは上記メディアストリームを再生するための上記ユーザー始動要求に対応するエントリをローカルＲＡＭまたはローカルディスクに記録するステップと、
   所定の間隔で、上記メディアファイルまたは上記メディアストリームの現在の再生位置をローカルＲＡＭまたは上記ローカルディスクに記録するステップと、
   ネットワーク接続が利用可能になる、
   上記アプリケーションとのユーザーインターラクションが受信される、
   プラットフォームストリームへの前回のネットワーク送信から所定の時間が経過した、および、
   ローカルＲＡＭまたは上記ローカルディスクに保存されているデータの予め定められた閾値が到達された、
   という条件のうちの１または複数が満たされたときに、上記エントリおよび記録された再生位置を上記プラットフォームストリームに送信して、ブロックチェーンに記録するステップとを有し、
   上記エントリおよび上記記録された再生位置を上記プラットフォームストリームに送信するステップは、上記エントリおよび上記記録された再生位置のオリジンを確認するためにユーザーに関連付けられた公開鍵を送信することを含むことを特徴とするシステム。
2. 上記エントリが、メディアファイルまたはメディアストリームの名称、権利所有者名、およびメ上記ディアファイルまたは上記メディアストリームに関連付けられたメタデータのうちの１つまたは複数を含む請求項１に記載のシステム。
3. 新しいメディアファイルまたは新しいメディアストリームを再生する要求がユーザーによって開始されるときはいつでも、新しいエントリがローカルＲＡＭまたは上記ローカルディスクに記録される請求項１に記載のシステム。
4. ユーザーインターラクションは、新しいメディアファイルまたはメディアストリームを再生するための要求、上記メディアファイルまたは上記メディアストリームの再生を一時停止するための要求、上記メディアファイルまたは上記メディアストリームの生成を停止するための要求、および上記メディアファイルまたは上記メディアストリームにおいて新しい位置へスキップするための要求のうちの１つまたは複数を含む請求項１記載のシステム。
5. 上記エントリは、上記ユーザーに関連付けられた秘密鍵によって生成されたユーザー署名で署名される請求項１に記載のシステム。
6. 上記ユーザー署名は、上記エントリとともにローカルに格納される請求項５に記載のシステム。
7. 上記エントリがローカルに永続化されるとき、または上記エントリが上記プラットフォームストリームに送信される直前のいずれかに、上記エントリが署名される請求項５に記載のシステム。
8. ブロックチェーンベースのプラットフォームを介してメディアファイルまたはメディアストリームの再生を継続的に追跡するためのシステムであって、
   プロセッサと、
   メモリであって、上記プロセッサに方法を実行させるための命令を格納する上記メモリとを有する、上記システムにおいて、
   上記方法は、
   プラットフォームストリームからトランザクションデータを受信する受信ステップであって、上記トランザクションデータはエンドユーザーからのメディアファイルまたはメディアストリームを再生する要求に対応し、上記トランザクションデータは、所定の間隔で記録された上記メディアファイルまたは上記メディアストリームの再生位置を含む、上記受信ステップと、
   上記トランザクションデータを検証する検証ステップであって、当該トランザクションデータの検証は、上記エンドユーザーに関連付けられた公開鍵を使用することを含み、上記公開鍵は、上記トランザクションデータの出所を検証するために上記トランザクションデータに追加される、上記検証ステップと、
   暗号署名を使用して当該検証されたトランザクションデータに署名するステップと、
   上記検証されたトランザクションデータをブロックチェーンに記録するステップと、
   上記検証されたトランザクションデータおよび上記暗号署名を１つ以上の検証ノードに送信するステップとを有することを特徴とするシステム。
9. 上記トランザクションデータは、上記エンドユーザーに対応する暗号署名を含む請求項８に記載のシステム。
10. 上記検証されたトランザクションデータが有効なブロックチェーントランザクションであると決定された場合にのみ、当該検証されたトランザクションデータが上記ブロックチェーンに記録される請求項８に記載のシステム。
11. 当該トランザクションデータを検証することは、１）上記トランザクションデータのフォーマットが上記プラットフォームによって確立されたプロトコルに従っているかどうか、および２）上記トランザクションデータが、上記エンドユーザーに対応する上記公開鍵によって検証可能な上記エンドユーザーの暗号署名を含むかどうかを、検証することを含む請求項８に記載のシステム。
12. 上記検証されたトランザクションデータが上記ブロックチェーンに記録された後、当該記録されたブロックチェーントランザクションデータは、第三者がカスタムプラットフォームアプリケーションプログラミングインターフェース（ＡＰＩ）を介して当該データにアクセスできるように、データベースに別個にストアされる請求項８に記載のシステム。
13. 上記トランザクションデータは、メディアファイルまたはメディアストリームの名称、権利所有者名、および上記メディアファイルまたは上記メディアストリームに関連付けられたメタデータのうちの１つまたは複数を含む請求項８記載のシステム。
14. 上記トランザクションデータは、記録された再生位置とともに上記エンドユーザーデバイス上でローカルに永続化されたエントリを含み、上記エントリは、上記エンドユーザーからの上記メディアファイルまたは上記メディアストリームを再生するための上記要求に対応する請求項８に記載のシステム。
15. ブロックチェーンベースのプラットフォームを介してメディアファイルまたはメディアストリームの再生を継続的に追跡するためのシステムにおいて、
    ユーザーデバイスであって、
    アプリケーションを介してメディアファイルまたはメディアストリームを再生するためのユーザー始動要求を受信し、
    上記メディアファイルまたは上記メディアストリームを再生するための上記ユーザー始動要求に対応するエントリをローカルＲＡＭまたはローカルディスクに記録し、
    所定の間隔で、上記メディアファイルまたは上記メディアストリームの現在の再生位置を、ローカルＲＡＭまたは上記ローカルディスクに記録し、
    ネットワーク接続が利用可能になる、
    上記アプリケーションとのユーザーインターラクションが受信される、
    プ ラットフォームストリームへの前回のネットワーク送信から所定の時間が経過した、および、
    ローカルＲＡＭまたは上記ローカルディスクに保存されているデータの予め定められた閾値が到達された、
    という条件のうちの１または複数が満たされたときに、上記エントリおよび記録された再生位置を上記プラットフォームストリームに送信して、ブロックチェーンに記録しするように構成され、
    上記エントリおよび上記記録された再生位置を上記プラットフォームストリームに送信するステップは、上記エントリおよび上記記録された再生位置のオリジンを確認するためにユーザーに関連付けられた公開鍵を送信することを含む上記ユーザーデバイスと、
    プラットフォームサーバーであって、
    上 記プラットフォームストリームから、トランザクションデータであって、上記エントリおよび上記記録された再生位置を含む上記トランザクションデータを受信し、
    上記トランザクションデータの検証であって、当該トランザクションデータの検証は、上記ユーザーに関連付けられた公開鍵を使用して上記トランザクションデータの発信元を検証することを含む、上記上記トランザクションデータの検証を実行し、
    暗号署名を使用して上記検証されたトランザクションデータに署名し、
    上記検証されたトランザクションデータをブロックチェーンに記録し、かつ、
    上記検証されたトランザクションデータおよび上記暗号署名を１つ以上の検証ノードに送信するように構成された、上記プラットフォームサーバーとを有することを特徴とするシステム。
16. 上記トランザクションデータは、上記ユーザーに対応する暗号署名を含む、請求項１５に記載のシステム。
17. 上記検証されたトランザクションデータが有効なブロックチェーントランザクションであると決定された場合にのみ、上記検証されたトランザクションデータが上記ブロックチェーンに記録される請求項１５に記載のシステム。
18. 当該トランザクションデータを検証することは、１）上記トランザクションデータのフォーマットが上記プラットフォームによって確立されたプロトコルに従っているかどうか、および２）上記トランザクションデータが、上記エンドユーザーに対応する上記公開鍵によって検証可能な上記エンドユーザーの暗号署名を含むかどうかを、検証することを含む請求項１５に記載のシステム。
19. 上記エントリが、メディアファイルまたはメディアストリーム名、権利所有者名、およびメディアファイルまたはメディアストリームに関連付けられたメタデータのうちの１つまたは複数を含む、請求項１５に記載のシステム。
20. ユーザーインターラクションは、新しいメディアファイルまたはメディアストリームを再生するための要求、上記メディアファイルまたは上記メディアストリームの再生を一時停止するための要求、上記メディアファイルまたは上記メディアストリームの生成を停止するための要求、および上記メディアファイルまたは上記メディアストリームにおいて新しい位置へスキップするための要求のうちの１つまたは複数を含む請求項１５記載のシステム。

Images