JP7308494B2

JP7308494B2 - ブロックチェーンを使用してメディア再生を拡張可能に追跡するためのシステムおよび方法

Info

Publication number: JP7308494B2
Application number: JP2021506580A
Authority: JP
Inventors: アサデポ、ポーリア; ベイティ、アンドリュー
Original assignee: Beatdapp Software Inc
Current assignee: Beatdapp Software Inc
Priority date: 2019-08-30
Filing date: 2020-07-24
Publication date: 2023-07-14
Anticipated expiration: 2040-07-24
Also published as: US11095457B2; US20210064584A1; EP3841755A4; CA3107819C; CA3107819A1; JP2022545586A; MX2021001759A; EP3841755A1; WO2021040930A1

Description

関連出願

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

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

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

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

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

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

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

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

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

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

詳細な説明

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

本開示は、その特定の実施例を参照して特に示され、説明されてきたけれども、開示された実施例の形態および詳細の変更は、この開示の精神または範囲から逸脱することなく行われ得ることが当業者によって理解されるであろう。したがって、本開示は、その真の精神および範囲内にあるすべての変形および均等物を含むと解釈されることが意図されている。
以下、ここで説明した技術的特徴を列挙する。
［技術的特徴１］
プロセッサと、
メモリであって、方法を実行させるためのインストラクションを記憶する、上記メモリとを有するシステムにおいて、
上記方法は、
メディアファイルを再生するための要求を、クライアント装置またはデジタルサービスプロバイダ（ＤＳＰ）プラットフォームから受信するステップと、
上記メディアファイルを再生するための要求をブロックチェーンプロトコルを介して有効化するステップと、
上記メディアファイルを再生するための要求を有効化するときに、上記メディアファイルを再生するための要求を有効なブロックチェーントランザクションとしてブロックチェーンに記録するステップと、
上記メディアファイルが再生された回数を上記ブロックチェーンプロトコルを介してトラッキングするステップとを有することを特徴とするシステム。
［技術的特徴２］
上記ブロックチェーンプロトコルはオーソリティアルゴリズムの証明を利用する技術的特徴１記載のシステム。
［技術的特徴３］
上記要求を検証するステップは、複数のシーラからの２つの承認されたシーラによる暗号手法での検証ステップを含む技術的特徴１記載のシステム。
［技術的特徴４］
上記メディアファイルを再生するための要求は、特定された時間においてコンテンツをアクセスするための上記ブロックチェーンに対する要求を含む技術的特徴１記載のシステム。
［技術的特徴５］
上記ブロックチェーンに対する要求は、当該要求が上記ブロックチェーンにヒットし、これにより、任意の順序で追加されることを可能にすると、ただちに完結可能になる技術的特徴１記載のシステム。
［技術的特徴６］
上記メディアファイルのショートバッファが、上記メディアファイルを再生するための要求の受信の後に即座にメディアサーバからストリーミング配信され、上記メディアファイルの残りが、上記再生要求が検証された後に初めてストリーミング配信される技術的特徴１記載のシステム。
［技術的特徴７］
上記ブロックチェーンの異なるバージョンが異なるクライアント用に生成される技術的特徴１記載のシステム。
［技術的特徴８］
メディアファイルを再生するための要求を、クライアント装置またはデジタルサービスプロバイダ（ＤＳＰ）プラットフォームから受信するステップと、
上記メディアファイルを再生するための要求をブロックチェーンプロトコルを介して有効化するステップと、
上記メディアファイルを再生するための要求を有効化するときに、上記メディアファイルを再生するための要求を有効なブロックチェーントランザクションとしてブロックチェーンに記録するステップと、
上記メディアファイルが再生された回数を上記ブロックチェーンプロトコルを介してトラッキングするステップとを有することを特徴とする方法。
［技術的特徴９］
上記ブロックチェーンプロトコルはオーソリティアルゴリズムの証明を利用する技術的特徴８記載の方法。
［技術的特徴１０］
上記要求を検証するステップは、複数のシーラからの２つの承認されたシーラによる暗号手法での検証ステップを含む技術的特徴８記載の方法。
［技術的特徴１１］
上記メディアファイルを再生する要求は、特定された時間においてコンテンツをアクセスするための上記ブロックチェーンに対する要求を含む技術的特徴８記載の方法。
［技術的特徴１２］
上記ブロックチェーンに対する要求は、当該要求が上記ブロックチェーンにヒットし、これにより、任意の順序で追加されることを可能にすると、ただちに完結可能になる技術的特徴８記載の方法。
［技術的特徴１３］
上記メディアファイルのショートバッファが、上記メディアファイルを再生するための要求の受信ののち即座にメディアサーバからストリーミング配信され、上記メディアファイルの残りが、上記再生要求が検証された後に初めてストリーミング配信される技術的特徴８記載の方法。
［技術的特徴１４］
上記ブロックチェーンの異なるバージョンが異なるクライアント用に生成される技術的特徴８記載の方法。
［技術的特徴１５］
メディアファイルを再生するための要求を、クライアント装置またはデジタルサービスプロバイダ（ＤＳＰ）プラットフォームから受信するステップと、
上記メディアファイルを再生するための要求をブロックチェーンプロトコルを介して有効化するステップと、
上記メディアファイルを再生するための要求を有効化するときに、上記メディアファイルを再生するための要求を有効なブロックチェーントランザクションとしてブロックチェーンに記録するステップと、
上記メディアファイルが再生された回数を上記ブロックチェーンプロトコルを介してトラッキングするステップとを有する方法を実行するための命令を記憶することを特徴とする非一時的なコンピュータ可読媒体。
［技術的特徴１６］
上記ブロックチェーンプロトコルはオーソリティアルゴリズムの証明を利用する技術的特徴１５記載の非一時的なコンピュータ可読媒体。
［技術的特徴１７］
上記要求を検証するステップは、複数のシーラからの２つの承認されたシーラによる暗号手法での検証ステップを含む技術的特徴１５記載の非一時的なコンピュータ可読媒体。
［技術的特徴１８］
上記メディアファイルを再生する要求は、特定された時間においてコンテンツをアクセスするための上記ブロックチェーンに対する要求を含む技術的特徴１５記載の非一時的なコンピュータ可読媒体。
［技術的特徴１９］
上記ブロックチェーンに対する要求は、当該要求が上記ブロックチェーンにヒットし、これにより、任意の順序で追加されることを可能にすると、ただちに完結可能になる技術的特徴１５記載の非一時的なコンピュータ可読媒体。
［技術的特徴２０］
上記ブロックチェーンの異なるバージョンが異なるクライアント用に生成される技術的特徴１５記載の非一時的なコンピュータ可読媒体。

Claims

ブロックチェーンベースのプラットフォームを介してメディアファイルの再生を追跡するためのシステムであって、プロセッサと、上記プロセッサに所定の方法を実行させる命令を格納するメモリとを有するメディア要求追跡サーバーを有する、上記システムにおいて、
上記所定の方法は、
再生要求に対応するトランザクションデータをプラットフォームストリームから受信する受信ステップであって、上記プラットフォームストリームは、上記メディア要求追跡サーバーとは別のプラットフォームストリーミングサーバーに対応し、上記トランザクションデータは、エンドユーザーから上記プラットフォームストリーミングサーバーに対する、エンドユーザー装置においてメディアファイルを再生する要求に対応し、上記要求が許可された場合、上記プラットフォームストリーミングサーバーは上記メディアファイルを上記エンドユーザーに直接送信する、上記受信ステップと、
上記トランザクションデータを検証するステップと、
暗号署名を使用して検証済みの上記トランザクションデータに署名するステップと、
ブロックチェーントランザクションを有効化するステップとを有し、
上記ブロックチェーントランザクションを有効化するステップは、１）３つの有効化ノードのうちの最初の有効化ノードが、上記トランザクションデータに遭遇して上記トランザクションデータを有効化したことを証明するために、当該最初の有効化ノードの秘密鍵を使用して上記トランザクションデータに署名すること、２）署名された上記要求を、上記３つの有効化ノードのうちの２番目の有効化ノードに渡して、上記２番目の有効化ノードが当該２番目の有効化ノードの秘密鍵を用いて上記トランザクションデータに署名すること、および３）上記３つの有効化ノードのうちの３番目の有効化ノードに上記トランザクションデータを確定化させ、上記最初の有効化ノードの署名および上記２番目の有効化ノードの署名とともにブロックチェーンに送ることを含み、少なくとも２つの有効化ノードからの上記再生要求に関連付けられた検証署名が存在するまで、上記再生要求は、再生カウントに追加される有効な再生要求と判定されないことを特徴とするシステム。
上記トランザクションデータは、上記エンドユーザーに対応する暗号署名を含む、請求項１に記載のシステム。
上記トランザクションデータが有効なブロックチェーントランザクションに対応するかどうかを決定することは、上記トランザクションデータが、許可されたまたは登録された有効化ノードからの２つの暗号署名を含むことを検証することを含む、請求項１に記載のシステム。
上記トランザクションデータを検証するステップは、１）上記トランザクションデータのフォーマットが上記プラットフォームによって確立されたプロトコルに従うかどうか、および２）上記トランザクションデータが、上記エンドユーザーに対応する公開鍵で検証可能なエンドユーザーの暗号署名を含むかどうかを検証することを含む、請求項１に記載のシステム。
サードパーティがカスタムプラットフォームアプリケーションプログラミングインターフェース（ＡＰＩ）を介してデータにアクセスできるように、有効なブロックチェーントランザクションがデータベースに別々に保存される、請求項１に記載のシステム。
有効なブロックチェーントランザクションが定期的にマークル化され、それによってマークルルートが生成される、請求項１に記載のシステム。
上記マークルルートは、セキュリティの補助ポイントとして外部のサードパーティのブロックチェーンに確定化される、請求項６に記載のシステム。
ブロックチェーンベースのプラットフォームを介してメディアファイルの再生を追跡するためのシステムであって、プロセッサと、上記プロセッサに所定の方法を実行させる命令を格納するメモリとを有するメディア要求追跡サーバーを有する、上記システムにおいて、
上記所定の方法は、
再生要求に対応するトランザクションデータをプラットフォームストリームから受信する受信ステップであって、上記プラットフォームストリームは、上記メディア要求追跡サーバーとは別のプラットフォームストリーミングサーバーに対応し、上記トランザクションデータは、エンドユーザーから最初の有効化ノードに対する、エンドユーザー装置においてメディアファイルを再生する要求に対応し、上記要求が許可された場合、上記プラットフォームストリーミングサーバーは上記メディアファイルを上記エンドユーザーに直接送信する、上記受信ステップと、
上記トランザクションデータを検証するステップと、
暗号署名を使用して検証済みの上記トランザクションデータに署名するステップと、
ブロックチェーントランザクションを有効化するステップとを有し、
上記ブロックチェーントランザクションを有効化するステップは、１）３つの有効化ノードのうちの最初の有効化ノードが、上記トランザクションデータに遭遇して上記トランザクションデータを有効化したことを証明するために、当該最初の有効化ノードの秘密鍵を使用して上記トランザクションデータに署名すること、２）署名された上記要求を、上記３つの有効化ノードのうちの２番目の有効化ノードに渡して、上記２番目の有効化ノードが当該２番目の有効化ノードの秘密鍵を用いて上記トランザクションデータに署名すること、および３）上記３つの有効化ノードのうちの３番目の有効化ノードに上記トランザクションデータを確定化させ、上記最初の有効化ノードの署名および上記２番目の有効化ノードの署名とともにブロックチェーンに送ることを含み、少なくとも２つの有効化ノードからの上記再生要求に関連付けられた検証署名が存在するまで、上記再生要求は、再生カウントに追加される有効な再生要求と判定されないことを特徴とするシステム。
上記トランザクションデータは、上記エンドユーザーに対応する暗号署名を含む、請求項８に記載のシステム。
上記トランザクションデータは、上記最初の有効化ノードから上記プラットフォームストリームに渡される、請求項８に記載のシステム。
上記トランザクションデータを検証するステップは、１）上記トランザクションデータのフォーマットが上記プラットフォームによって確立されたプロトコルに従うかどうか、および２）上記トランザクションデータが、上記エンドユーザーに対応する公開鍵で検証可能なエンドユーザーの暗号署名を含むかどうかを検証することを含む、請求項８に記載のシステム。
サードパーティがカスタムプラットフォームアプリケーションプログラミングインターフェース（ＡＰＩ）を介してデータにアクセスできるように、有効なブロックチェーントランザクションがデータベースに別々に保存される、請求項８に記載のシステム。
有効なブロックチェーントランザクションが定期的にマークル化され、それによってマークルルートが生成される、請求項８に記載のシステム。
上記マークルルートは、セキュリティの補助ポイントとして外部のサードパーティのブロックチェーンに確定化される、請求項１３に記載のシステム。
ブロックチェーンベースのプラットフォームを介してメディアファイルの再生を追跡するための方法において、
メディア要求追跡サーバーにおいて再生要求に対応するトランザクションデータをプラットフォームストリームから受信する受信ステップであって、上記プラットフォームストリームは、上記メディア要求追跡サーバーとは別のプラットフォームストリーミングサーバーに対応し、上記トランザクションデータは、エンドユーザーから上記プラットフォームストリーミングサーバーに対する、エンドユーザー装置においてメディアファイルを再生する要求に対応し、上記要求が許可された場合、上記プラットフォームストリーミングサーバーは上記メディアファイルを上記エンドユーザーに直接送信する、上記受信ステップと、
上記トランザクションデータを検証するステップと、
暗号署名を使用して検証済みの上記トランザクションデータに署名するステップと、
ブロックチェーントランザクションを有効化するステップとを有し、
上記ブロックチェーントランザクションを有効化するステップは、１）３つの有効化ノードのうちの最初の有効化ノードが、上記トランザクションデータに遭遇して上記トランザクションデータを有効化したことを証明するために、当該最初の有効化ノードの秘密鍵を使用して上記トランザクションデータに署名すること、２）署名された上記要求を、上記３つの有効化ノードのうちの２番目の有効化ノードに渡して、上記２番目の有効化ノードが当該２番目の有効化ノードの秘密鍵を用いて上記トランザクションデータに署名すること、および３）上記３つの有効化ノードのうちの３番目の有効化ノードに上記トランザクションデータを確定化させ、上記最初の有効化ノードの署名および上記２番目の有効化ノードの署名とともにブロックチェーンに送ることを含み、少なくとも２つの有効化ノードからの上記再生要求に関連付けられた検証署名が存在するまで、上記再生要求は、再生カウントに追加される有効な再生要求と判定されないことを特徴とする方法。
上記トランザクションデータは、上記エンドユーザーに対応する暗号署名を含む、請求項１５に記載の方法。
上記トランザクションデータが有効なブロックチェーントランザクションに対応するかどうかを決定するステップは、上記トランザクションデータが、許可されたまたは登録された有効化ノードからの２つの暗号署名を含むことを検証することを含む、請求項１５に記載の方法。
上記トランザクションデータを検証するステップは、１）上記トランザクションデータのフォーマットが上記プラットフォームによって確立されたプロトコルに従うかどうか、および２）上記トランザクションデータが、上記エンドユーザーに対応する公開鍵で検証可能なエンドユーザーの暗号署名を含むかどうかを検証することを含む、請求項１５に記載の方法。
サードパーティがカスタムプラットフォームアプリケーションプログラミングインターフェース（ＡＰＩ）を介してデータにアクセスできるように、有効なブロックチェーントランザクションがデータベースに別々に保存される、請求項１５に記載の方法。
有効なブロックチェーントランザクションが定期的にマークル化され、それによってマークルルートが生成される、請求項１５に記載の方法。