(57)【要約】  アダプティブストリーミングのためのセグメントの保全性および信頼性のためのシステムおよび方法の実施形態を提供する。実施形態において、方法はデータ処理システムにおいてメディアストリームのセグメントを受信するステップと、データ処理システムを用いてセグメントのダイジェストまたはデータ処理システムを決定するステップと、データ処理システムを用いて、ダイジェスト/デジタル署名を正しいダイジェストまたは正しいデジタル署名と比較してセグメントが改変されているかどうかを判定するステップと含む。
2015519814.tif 000002
【特許請求の範囲】
【請求項１】
アダプティブストリーミングのためのセグメントの保全性および信頼性を検証するための方法であって、
データ処理システムにおいてメディアストリームのセグメントを受信するステップと、
前記データ処理システムを用いて、前記セグメントに関するダイジェストまたはデジタル署名を決定するステップと、
前記データ処理システムを用いて、前記ダイジェストまたは前記デジタル署名を正しいダイジェストまたは正しいデジタル署名と比較して、前記セグメントが改変されているかどうかを判定するステップとを含む、方法。
【請求項２】
前記正しいダイジェストまたはデジタル署名がサーバから受信される、請求項1に記載の方法。
【請求項３】
サーバが、前記メディアストリームを備える複数のセグメントのそれぞれについて前記正しいダイジェストまたは前記正しいデジタル署名のデータストアを維持する、請求項2に記載の方法。
【請求項４】
前記ダイジェストが暗号ハッシュである、請求項1に記載の方法。
【請求項５】
前記デジタル署名がメッセージ認証コードである、請求項1に記載の方法。
【請求項６】
セグメントの改変が、前記メディアストリーム中の他のセグメントに対する前記セグメントの時間順序の変更を含む、請求項1に記載の方法。
【請求項７】
前記ダイジェストが前記正しいダイジェストに一致しないかまたは前記デジタル署名が前記正しいデジタル署名に一致しないときに前記セグメントを拒絶するステップをさらに含む、請求項1に記載の方法。
【請求項８】
アダプティブストリーミングのためのセグメントの保全性および信頼性を検証するように構成されたネットワークコンポーネントであって、
プロセッサと、
前記プロセッサによって実行するためのプログラミングを記憶するコンピュータ可読記憶媒体とを備え、前記プログラミングが、
メディアストリームのセグメントを受信するための命令と、
前記セグメントに関するダイジェストまたはデジタル署名を決定するための命令と、
前記ダイジェストまたはデジタル署名を正しいダイジェストまたは正しいデジタル署名と比較して、前記セグメントが改変されているかどうかを判定するための命令と、を含む、ネットワークコンポーネント。
【請求項９】
前記正しいダイジェストまたは前記正しいデジタル署名がサーバから受信される、請求項8に記載のネットワークコンポーネント。
【請求項１０】
前記サーバが、前記メディアストリームを備える複数のセグメントのそれぞれについて前記正しいダイジェストまたは前記正しいデジタル署名のデータストアを維持する、請求項9に記載のネットワークコンポーネント。
【請求項１１】
前記ダイジェストがメッセージ認証コードを含む、請求項8に記載のネットワークコンポーネント。
【請求項１２】
前記ダイジェストが暗号ハッシュを含む、請求項8に記載のネットワークコンポーネント。
【請求項１３】
セグメントの改変が前記メディアストリーム中の他のセグメントに対する前記セグメントの時間順序の変更を含む、請求項8に記載のネットワークコンポーネント。
【請求項１４】
前記プログラミングが、前記ダイジェストが前記正しいダイジェストに一致しないかまたは前記デジタル署名が前記正しいデジタル署名に一致しないときに前記セグメントを拒絶するための命令を更に含む、請求項8に記載のネットワークコンポーネント。
【請求項１５】
アダプティブストリーミングのためのセグメントの保全性および信頼性を検証するための方法であって、
ユーザ機器(UE)においてメディアストリームのセグメントを受信するステップであって、前記メディアストリームがハイパーテキスト転送プロトコルによる動的アダプティブストリーミング(DASH)のストリームの複数のセグメントを含む、受信するステップと、
前記UEを用いて、前記メディアストリームの前記セグメントに関するダイジェストまたはデジタル署名を決定するステップと、
前記UEを用いて、前記ダイジェストまたは前記デジタル署名を正しいダイジェストまたは正しいデジタル署名と比較するステップと、
前記UEを用いて、前記セグメントが改変されているかどうかを判定するステップと、を含む方法。
【請求項１６】
前記正しいダイジェストまたは正しいデジタル署名が信頼できるソースから受信される、請求項15に記載の方法。
【請求項１７】
前記ダイジェストがメッセージ認証コードを含む、請求項15に記載の方法。
【請求項１８】
前記ダイジェストが暗号ハッシュを含む、請求項15に記載の方法。
【請求項１９】
前記暗号ハッシュがセキュアハッシュアルゴリズム(SHA)でありかつ前記SHAがSHA-256またはSHA-512を含む、請求項18に記載の方法。
【請求項２０】
前記セグメントが改変されたかどうかを判定するステップが前記メディアストリーム中の他のセグメントに対する前記セグメントの時間順序の変更を判定するステップを含む、請求項15に記載の方法。
【請求項２１】
アダプティブストリーミングのためのセグメントの保全性および信頼性を検証するように構成されたユーザ機器であって、
プロセッサと、
前記プロセッサによって実行するためのプログラミングを記憶するコンピュータ可読記憶媒体と、を備え、前記プログラミングが、
メディアストリームのセグメントを受信するステップであって、前記メディアストリームがハイパーテキスト転送プロトコルによる動的アダプティブストリーミング(DASH)のストリームの複数のセグメントを含む、受信するための命令と、
前記メディアストリームの前記セグメントに関するダイジェストまたはデジタル署名を決定するための命令と、
前記ダイジェストまたはデジタル署名を正しいダイジェストまたは正しいデジタル署名と比較するための命令と、
前記セグメントが改変されているかどうかを判定するための命令と、を備える、ユーザ機器。
【請求項２２】
前記正しいダイジェストまたは正しいデジタル署名が信頼できるソースから受信される、請求項21に記載のユーザ機器。
【請求項２３】
前記ダイジェストがメッセージ認証コードを含む、請求項21に記載のユーザ機器。
【請求項２４】
前記ダイジェストが暗号ハッシュを含む、請求項21に記載のユーザ機器。
【請求項２５】
前記セグメントが改変されたかどうかを判定するステップが、前記メディアストリーム中の他のセグメントに対して前記セグメントの時間順序の変更を判定するステップを含む、請求項21に記載のユーザ機器。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願の相互参照
本出願は、参照によってその全体が再現されているかのように本明細書に組み込まれている、2012年4月25日に出願された「System and Method for Segment Integrity and Authenticity for Adaptive Streaming」と題する米国特許仮出願第61/638,332号の利益を主張する。
【０００２】
本発明はメディアストリームのためのシステムおよび方法に関し、具体的な実施形態においては、アダプティブストリーミングのための、セグメントの保全性および信頼性のためのシステムおよび方法に関する。
【背景技術】
【０００３】
マルチプルシステムオペレータ(MSO: multiple system operator)所有のネットワークのウォールドガーデンにおいて、重要なセキュリティの課題は不正アクセスおよび高価値コンテンツの再生の防止であった。オープンネットワークおよびインターネット配信への移行に伴い、オペレータはもはや、自身の配信ネットワークに対してエンドツーエンドで完全に制御することができない。このことは、コンテンツへの不正アクセスを提供しないもののサービスの妨害とクライアントデバイスへの不正アクセスを可能にする、いくつかの新しい攻撃につながる。
【０００４】
メディアのセグメントおよびそれらの記述(たとえばメディアプレゼンテーション記述(MPD: media presentation description))はそれらの配信ネットワーク全体にわたって様々な場所に記憶される-すなわち、それらは商用のコンテンツ配信ネットワーク(CDN: content delivery network)のノードでキャッシュされ、次いでより消費者に近い場合によっては別のCDNのノードにキャッシュされ、次いでサービスプロバイダのヘッドエンドでキャッシュされ得る。実際には、ノード間の配信チャネル上での改ざんの可能性が存在することに加えて、これらのノードのいくつかは悪意のものである可能性がある。
【０００５】
第1に、MPDはこの連鎖における何らかの悪意のあるエンティティによって変更され、したがってあるストリーミングセッションの全体を完全にハイジャックする可能性がある。このことにはMPD配信のハイパーテキスト転送プロトコルセキュア(HTTPS)のセキュアな方法および/またはエクステンシブルマークアップ言語(XML)署名を使用することによって対処できる。全体的に、この考察では、クライアントが正しいMPDを有しこれは改ざんされておらず、一方、悪意のあるエンティティがMPDへアクセスできネットワークにも完全にアクセスできると仮定する。
【０００６】
3つの主要な攻撃のタイプ、すなわちセグメントの置換、並べ替え、および改変が考えられる。セグメントを提供するサービスの完全な否定(たとえば、セグメントの代わりに404を返すこと)も常に可能であるが、これは可能なダウンロード場所を複数提供しかつ/または2つ以上のCDNを利用しさえすれば対処できる。
【０００７】
単純なコンテンツ置換または並べ替えは3つの場合、すなわち、要求されたセグメントが暗号化されていないとき、置換されようとしているセグメントが連続しており暗号化されておりかつ同じ暗号期間内にあるとき、または意図がセグメントを再生可能な別のセグメントで置き換えることではなく提示を妨害することであるときに可能である。
【０００８】
攻撃の例は、広告のスキップ(広告は動画からの次のセグメントで置換される)、およびサービスの劣化(高品質のセグメントを低品質のセグメントで置換する)である。
【０００９】
一般に最も脆弱なビジネスモデルは、広告支援を受けたデジタル権管理(DRM:digital rights management)の無いコンテンツが提供される場合であり、これはかなり重要なモデルであると見込まれている。同じ脅威がコンテンツが暗号化されずに送信される公共のチャンネル(米国のC-SPANなど)にも広く及ぶ。
【００１０】
セグメントの改変は暗号化されていない状態において、および部分的なビットストリーム暗号化を使用しているコンテンツにおいて、常に可能である。後者の場合、暗号化されたバイトは暗号化されていないヘッダ内で信号送信されるので、たとえば、実際の保護されているエレメンタリストリームは暗号化されていない何らかの任意のコンテンツと置換可能である。部分的に暗号化されたストリームがクライアントの挙動を改変する暗号化されていない命令を搬送する場合、これらはクライアントの挙動を改変する目的で使用され得る。完全なセグメント暗号化の場合、セグメントの改変はセグメントを再生不可能にし、場合によってはデコーダのリセットを引き起こすことになる。
【００１１】
(暗号化されたコンテンツと暗号化されていない他のコンテンツの簡単な置換以外の)そのような攻撃の例は、クライアントをある期間から早く離れさせるように、ISO-FFセグメントに「lmsg」の烙印を加えるものである。別の興味深い誘導は、新しいMPDのユニバーサルリソースロケータ(URL: universal resource locator)を含む、暗号化されずに渡されるメッセージがある場合であろう(ただしそのような機能は現在では標準化されていない)。このURLを悪意のあるものに置き換えるのは雑作もないことである。
【００１２】
悪意のあるエンティティはまた、ネットワーク内のトランススクランブリング(たとえば再暗号化)が使用される場合、コンテンツを暗号化および復号するために使用されるキーにアクセスできる可能性がある。このように、コンテンツの置き換えは暗号化されたコンテンツに対しても可能である。
【００１３】
メディア以外のセグメントへの同様の攻撃もまた可能である。初期化セグメントおよびビットストリーム切替セグメントの場合、改変によりコンテンツ全体が完全にまたは部分的に再生不可能となり、一方改変されたインデックスファイルは少なくともトリックモード機能を不安定化させる可能性がある。
【００１４】
たとえばファイル破壊による、単純なセグメントの改変もあり得る。このようにして発見され得る別の単純なエラーは、正しくない復号キーの使用である。
【００１５】
上記の検討はセグメントのみについて記載しているが、完全なセグメントがまったく配信されず、ビットストリーム切替がサブセグメントレベルで行われることもあり得る。
【発明の概要】
【課題を解決するための手段】
【００１６】
ある実施形態によれば、アダプティブストリーミングのための、セグメントの保全性および信頼性を検証するための方法は、データ処理システムにおいてメディアストリームのセグメントを受信するステップと、データ処理システムを用いてセグメントに関するダイジェストまたはデジタル署名を決定するステップと、データ処理システムを用いてダイジェストまたはデジタル署名を正しいダイジェストまたは正しいデジタル署名と比較してセグメントが改変されているかどうかを判定するステップとを含む。
【００１７】
別の実施形態によれば、アダプティブストリーミングのための、セグメントの保全性および信頼性を検証するように構成されたネットワークコンポーネントは、プロセッサと、プロセッサによって実行するためのプログラミングを記憶するコンピュータ可読記憶媒体とを含み、プログラミングは、メディアストリームのセグメントを受信するための命令、セグメントに関するダイジェストまたはデジタル署名を決定するための命令、およびダイジェストまたはデジタル署名を正しいダイジェストまたは正しいデジタル署名と比較してセグメントが改変されているかどうかを判定するための命令を含む。
【００１８】
別の実施形態によれば、アダプティブストリーミングのための、セグメントの保全性および信頼性を検証するための方法は、ユーザ機器(UE)においてメディアストリームのセグメントを受信するステップであって、メディアストリームがハイパーテキスト転送プロトコルによる動的アダプティブストリーミング(DASH)のストリームの複数のセグメントを含む受信するステップと、UEを用いてメディアストリームのセグメントに関するダイジェストまたはデジタル署名を決定するステップと、UEを用いてダイジェストまたはデジタル署名を正しいダイジェストまたは正しいデジタル署名と比較するステップと、UEを用いてセグメントが改変されているかどうかを判定するステップと、を含む。
【００１９】
本発明、およびその利点をより完全に理解するため、ここで添付の図面と併せて解釈される以下の説明を参照する。
【図面の簡単な説明】
【００２０】
【図１】アダプティブストリーミングのための、データの通信ならびにセグメントの保全性および信頼性の維持のためのシステムの実施形態を例示する図である。
【図２】セグメントの適合セットを例示する図である。
【図３】セグメントによって形成されるストリームの例を例示する図である。
【図４】動的アダプティブストリーミングのためのアーキテクチャを例示する図である。
【図５】適合セットに関するハッシュ値のコードブックを例示する図である。
【図６】ハッシュ値のベクトル形態を例示する図である。
【図７Ａ】セグメントの広告挿入/置換を例示する図である。
【図７Ｂ】セグメントの広告挿入/置換を例示する図である。
【図８Ａ】セグメント置換によるコンテンツの改変を例示する図である。
【図８Ｂ】セグメント置換によるコンテンツの改変を例示する図である。
【図９】ダイジェストの生成を例示する図である。
【図１０Ａ】リプリゼンテーションに関する組み合わされたダイジェストを例示する図である。
【図１０Ｂ】リプリゼンテーションに関する組み合わされたダイジェストを例示する図である。
【図１０Ｃ】リプリゼンテーションに関する組み合わされたダイジェストを例示する図である。
【図１１Ａ】組み合わされたダイジェストにおける取り出されたセグメントに関するダイジェストの位置を見つけることを例示する図である。
【図１１Ｂ】組み合わされたダイジェストにおける取り出されたセグメントに関するダイジェストの位置を見つけることを例示する図である。
【図１１Ｃ】組み合わされたダイジェストにおける取り出されたセグメントに関するダイジェストの位置を見つけることを例示する図である。
【図１１Ｄ】組み合わされたダイジェストにおける取り出されたセグメントに関するダイジェストの位置を見つけることを例示する図である。
【図１２】取り出されたセグメントに関する局所的なダイジェスト/署名を例示する図である。
【図１３】アダプティブストリーミングのための、セグメントの保全性および信頼性を検証するための方法の実施形態のフローチャートである。
【図１４】様々な実施形態を実装するのに使用され得る処理システムの図である。
【発明を実施するための形態】
【００２１】
現時点で好ましい実施形態の作製および使用は以下で詳細に検討される。しかし、本発明は、多種多様な特定の状況において具体化できる、多くの適用可能な進歩性のある概念を提供し得ることを諒解すべきである。検討される特定の実施形態は単に本発明を作製し利用するための特定の方法を例示するに過ぎず、本発明の範囲を限定することはない。
【００２２】
従来から、メディアコンテンツは不正アクセスから保護されていた。インターネットストリーミングの場合、メディアコンテンツの改ざんに関連するさらなる脅威が現れている。実施形態は、ハイパーテキスト転送プロトコル（ＨＴＴＹ）（ＤＡＳＨ）による動的アダプティブストリーミングを用いてストリームされたメディアコンテンツの保全性および信頼性を検証する方法を提案する。
【００２３】
実施形態はアダプティブストリーミングのセグメントの保全性および信頼性を検証するためにダイジェストを使用する。実施形態はアダプティブストリーミングのセグメントの保全性および信頼性を検証するためにデジタル署名を使用する。実施形態は署名およびダイジェストを要求する。実施形態はストリームされたコンテンツの保全性および信頼性を検証する。実施形態はネットワーク内での悪意のあるコンテンツ操作を防止するかまたは低減する。実施形態は、ケーブル/IPTV/電気通信/モバイル/ワイヤレス/インターネットの動画ストリーミング、CDN、DASHなどのような領域において、広告支援を受けた非DRMのアダプティブストリーミングおよびセキュアなアダプティブストリーミングなどに適用可能である。
【００２４】
図1は、アダプティブストリーミングのための、データの通信ならびにセグメントの保全性および信頼性の維持のためのシステム100の実施形態を例示する。システム100は、クライアント102、メディアソースサーバ104、認証サーバ106、悪意のあるサーバ108、およびネットワーク110を含み得る。ネットワーク110は、スイッチ、ルータ、通信チャネル、およびネットワーク110のある部分からネットワーク110の別の部分にデータを送信するように構成された他のデバイスを含み得る。ネットワーク110は有線またはワイヤレスの送信手段を含み得る。クライアント102、メディアソースサーバ104、認証サーバ106、および悪意のあるサーバ108はネットワーク110に接続され、ネットワーク110を介してデータの送信および受信を行うように構成される。クライアントは、たとえば、パーソナルコンピュータ、ラップトップコンピュータ、タブレットコンピュータ、スマートフォン、携帯情報端末などを含む、任意のタイプのユーザ機器(UE)であってよい。
【００２５】
悪意のあるサーバ108は、メディアストリームのセグメントのメディアソースサーバ104からクライアント102への伝送路内に存在し得るサーバである。悪意のあるサーバ108はメディアストリームの1つまたは複数のセグメントの改変または置換を試みる。たとえば、悪意のあるサーバ108は、異なる広告の1つまたは複数のセグメントを置換し得、またはクライアント102を感染させるためもしくはクライアント102から個人情報を得るために、メディアのセグメント内にウイルスもしくはマルウェアを含み得る。
【００２６】
メディアソースサーバ104は、メディアを記憶しメディアストリームをネットワーク110を介してクライアント102に送信するように構成される。メディアストリームはメディアストリームのセグメントを含み得る。メディアのタイプには動画および音声を含み得る。メディアストリームのセグメントのそれぞれは、クライアント102がデジタル署名を決定または計算できる情報で符号化され得る。デジタル署名はダイジェストまたはメッセージ認証コード含み得る。メディアソースサーバ104は各セグメントのための正しいデジタル署名を認証サーバ106に送信し得、認証サーバ106はメディアストリームの各セグメントのための正しいデジタル署名のデータストアを維持し得る。認証サーバ106は、クライアント102からの要求に応じてクライアント102に正しいデジタル署名を提供する、信頼できる認証サーバまたは信頼できるソースである。クライアント102は、各セグメントのデジタル署名を決定するかまたは計算し、決定されたデジタル署名を認証サーバ106から受信された正しいデジタル署名と比較するように構成される。2つのデジタル署名が一致する場合、そのセグメントは改変されていない。しかし、2つのデジタル署名が一致しない場合、クライアント102はそのセグメントが改変されていると判定し、そのセグメントを廃棄しかつ/またはメディアソースサーバ104に改変されたセグメントを再送するように要求することができる。セグメントの改変は、あるセグメントの異なるセグメントとの置換、メディアストリーム内で他のセグメントに対して時間におけるセグメントの時間的配置を並べ替えること、および/またはセグメントの一部もしくは全ての改変を含み得る。セグメントの改変は、クライアント102を損なうかまたはクライアント上に記憶されている秘密のユーザ情報を漏らす可能性のある悪意のあるコンテンツの挿入を含み得る。
【００２７】
MPDおよびメディアのセグメントはいずれも、たとえば動的な広告の挿入を行うために正当に変更される必要があり得る。一般に連鎖の中で唯一の信頼できる要素は、元のコンテンツ提供者または元のコンテンツ提供者によって明確に信頼されているエンティティである。一般に、この問題に対応するための4つの選択肢がある。
(1)  信頼できるエンティティに、クライアントにセグメントのダイジェストをセキュアなチャネルを介して帯域外で提供させる。
(2)  外部から提供されたキーを使用して、帯域内で(メディア内もしくはインデックスセグメント内で)または帯域外で(たとえば、HTTPを使用して)、MACを搬送する。
(3)  認証された暗号化を使用する、ただしこのことは新しい相互運用不能なDRMを作り出し、完全なセグメント、MPEG-2 CA、またはCENC暗号化を使用して符号化されたコンテンツとの互換性を保持しない。
(4)  全てのセグメントのトラフィックに対してHTTPSを使用する、ただしこの選択肢はシステム全体のスケーラビリティを著しく低減する。
【００２８】
以下で検討する実施形態は、帯域外で伝送されるデジタルのダイジェストおよび署名を利用して、上の選択肢1および選択肢2の実装形態を提供する。
【００２９】
ダイジェストに関して、たとえばLinux(登録商標)のディストリビュータおよびファイル共有コミュニティは、悪意のあるエンティティがネットワークに害を与えようと、または単にウイルスに感染したファイルを注入しようとしているときに、いくつかの問題に直面している。これらの場合、攻撃は暗号ハッシュまたはダイジェストを使用して雑作なく対処でき、たとえばUbuntuディストリビューションは、猜疑心の程度の異なるダウンローダのために、MD5、セキュアハッシュアルゴリズム(SHA:secure hash algorithm)-1、SHA-256、およびSHA-512を提供する。
【００３０】
クライアントがダイジェストを受信することを望む場合に信頼できるエンティティへのセキュアなチャネル(たとえばTLS)が利用可能である場合には、信頼性および保全性の問題は、ダイジェストの使用により解決される。すなわち、n番目のセグメントS(n)およびダイジェストs=SHA(S(n))を提供できる信頼できるエンティティを与えられれば、クライアントはSHA(S`)≠sである場合のS(n)を表す任意の無効なセグメントS`を拒絶することが可能である。
【００３１】
例示の実装形態として、MPDは下のものに類似の構文を有するSupplementaryProperty記述子を含む。
<SupplementalProperty schemeIdUri="urn:mpeg:dash:sea:auth:2013">
<sea:ContentAuthenticity
authSchemeIdUri="urn:mpeg:dash:sea:sha256"
authUrlTemplate ="https://verify.example.com?base=$base$&amp;range=$first$-$last$" />
</SupplementalProperty>
【００３２】
セキュアなチャネルだけが使用可能な場合、またはキャッシュフレンドリである必要がある場合、ある信頼のレベルを提供するためにデジタル署名を使用できる。信頼できるエンティティから公開キーが与えられれば、メッセージを確認するためにキー付きのハッシュメッセージ認証コード(HMAC:hash message authentication code)を使用できる。この場合、信頼性および保全性の両方が保証され、一方公開キーおよび署名は共に暗号化されずに伝送される。同じ手法がXML署名を使用してMPD自体についても取られる。
【００３３】
例として、MPDは下のものに類似の構文を有するSupplementaryProperty記述子を含む。
<!-- SHA-256 digests is available for all (sub)segments -->
<SupplementalProperty schemeIdUri="urn:mpeg:dash:sea:auth:2013">
<sea:ContentAuthenticity 
authSchemeIdUri="urn:mpeg:dash:sea:sha256"
authUrlTemplate= "https://verify.example.com?base=$base$&amp;range=$first$-$last$" />
</SupplementalProperty>
【００３４】
実施形態は、信頼できるエンティティからセグメントのダイジェスト値を要求するための追加のURLのテンプレートを追加する。もしあれば、元のコンテンツ提供者によって暗号化に先立って、暗号化されていないセグメントに対してダイジェスト値が計算され、その結果、セグメントが暗号化される場合には、(正しくない復号セグメントをもたらす結果となる)誤った復号キーの使用が検出されることになり、暗号化キーはダイジェストから完全に切り離されることになる。
【００３５】
SHA-1は廃止が予定されているので、使用可能な2つのハッシュ機能はSHA-256およびSHA-512である。SHA-256は、32ビットのマシン(これらはモバイルデバイスにおいて使用されているものの大多数である)上で必要とする計算量がより少なく、したがってSHA-256はこれらのマシンにおいてより有用である。
【００３６】
HMACは同じフレームワーク内でサポート可能であるが、唯一の重要な変更は公開キーを受信することである。
【００３７】
実施形態において、上記のコンテンツ認証フレームワークをサポートするために以下の構文および意味が使用可能である。
【００３８】
【表１】
2015519814.tif 000003
【００３９】
URLの導出のために、ダイジェストおよび署名のURLは以下のように構築される。所与のメディア、初期化、インデックス、もしくはビットストリーム切替セグメント、またはサブセグメントに関する、完全なURLが構築される。ISO/IEC 23009-1 Annex Eにおけるものと同じ置換変数を、ダイジェストまたは署名のURLテンプレートを構築するために使用できる。ダイジェストが使用される場合、httpsを使用して要求すべきである。
【００４０】
【表２】
2015519814.tif 000004
【００４１】
ISO/IEC 23009-1 Annex Eと異なり、バイト範囲が使用されない場合、変数$first$および$last$のデフォルト値が存在する。セグメントまたはサブセグメントに対応しないバイト範囲要求は要求されず、サーバはそれを無視することができる。
【００４２】
正の数nおよびmに対して、セグメントSを(コンテンツのブロックとしての)ビットのシーケンスとし、リプリゼンテーションR=[S(1),S(2),…,S(n)]をセグメントのシーケンスとし、適合セットA=[R(1),R(2),…,R(m)]をリプリゼンテーションのリストとする。簡潔さのために、i=1,…,mおよびj=1,…,nに対して、i番目のリプリゼンテーション内のj番目のセグメントであるA[i][j]はまた、S(i,j)としても表される。視覚的には、適合セットAは、セグメントの適合セットを例示する図表200である図2に示すように、セグメントのm×n行列として扱うことができる。
【００４３】
Aによって定義される(セグメントの)ストリームは、n個のセグメント[S(i1,1), S(i2,2),…,S(im,n)](ただしk=1,2,…,nに対して1≦ik≦m)のシーケンスである。ストリームは、ik=x(ただし、全てのk=1,2,…,mに対して1≦x≦m)の場合には非適合的といわれ≦≦る。この場合、非適合的なストリームは適合セットA内のリプリゼンテーションの内のただ1つである。ストリームは非適合的ではない場合は適合的といわれる。ストリームは全てのk=1,…,n-1に対して差|ik-ik+1|≦1である場合に、スムースであるといわれる。図3は、シールドされたセグメントによって形成されたストリームの例を例示する図表300である。
【００４４】
一般的な設定では、動的アダプティブストリーミングのためのサーバクライアントシステムのアーキテクチャは、コンテンツのセグメントを伝送するためのCDN(content delivery network、コンテンツ配信ネットワーク)機能を提供するためのいくつかのノードがサーバとクライアントとの間に置かれている、マルチソース−マルチシンクの図表として描くことが可能である。適合セットA内のセグメントは最初はサーバ上で利用可能であるが、各サーバは必ずしも全てのセグメントを有さなくてもよく、任意のセグメントが2つ以上のサーバ上で利用可能であってよい。
【００４５】
図4は、動的アダプティブストリーミングのためのアーキテクチャを例示する図表400である。各クライアントがストリーム内の連続順に従って一時に1つだけ任意のストリームのセグメントを受信する場合、このアーキテクチャのシステムはストリーミングのシステムであり、したがってクライアントはセグメントの受信後すぐに、より後のセグメントの受信を待つことなく、それらを時間進行的に再生できる。ストリーミングのシステムにおいては、任意のクライアントが常時ストリームのプレフィクス[S(i1,1),S(i2,2),…,S(ik,k)]を受信する。
【００４６】
各クライアントが非リプリゼンテーションのストリームを受信することができる場合、ストリーミングのシステムは動的適合のシステムである。
【００４７】
セグメントは、システムが利用するセグメント伝送プロトコル(たとえば、httpまたはリアルタイム伝送プロトコル(rtp: real-time transport protocol))に応じて、サーバによってクライアントにプッシュする、またはクライアントによってサーバからプルすることができる。
【００４８】
実施形態では、クライアントによって受信されるセグメントが、全体としてのストリームの保全性に対するいかなる改ざんもなく有効な(かつ場合によっては意図した)ストリームを形成するだけでなく、サーバ上で元々利用可能であったと同様にそれぞれが個々に真正でもあることを、確実にすることが望ましい。
【００４９】
ストリームの信頼性および保全性に対するいくつかの一般的な攻撃は、
(1)  セグメントS(i,j)のコンテンツの改変、
(2)  1つもしくは複数のセグメントS(ij,j)、S(ij+1,j+1)、…、S(ik,k)の除去またはスキップ、ここでj<kである、
(3)  適合セットA内にない別のセグメントTとのセグメントS(i,j)の置換、および
(4)  適合セットA内にある別のセグメントS(p,q)とのセグメントS(i,j)の置換(並べ替えまたは再利用)である。
【００５０】
これらの種類の攻撃はサーバとクライアントとの間の配信チャネル上およびCDNノード上で発生し得る。
【００５１】
デジタルセキュリティの文献では、デジタルビットのシーケンスの保全性を保護するためにハッシュ機能が一般に使用される。このことは、受信されたセグメントもしくは受信されたストリームとそのオリジナルとの間の直接の比較またはチェックの実行が、実際には実行不可能であるかまたは非常に非効率的であるという理由による。代わりに、比較またはチェックは、セグメントのハッシュ値を事前に計算し、受信後そのセグメントが同じハッシュ値を有するかどうかを検査することによって行われる。
【００５２】
(セグメントのシーケンスである)ストリームの構造の性質に起因して、ストリームの保全性はセグメントのレベルならびにセグメントのシーケンスのレベルで提供され得る。
【００５３】
ストリーミングのシステムにおいては、保全性保護のための最も簡単で端的な解決法は、受信された全てのセグメントのハッシュ値を計算することである。すなわち、受信されたセグメントをビットの連結されたより長いシーケンスと見なし、以下が各k=1,…,nに対して成立するかをチェックする。
H([S(i1,1)|S(i2,2)|…|S(ik,k)])=hSk.
【００５４】
このことが重複する計算を過度に多く含み、過度に多くの(n×mn)個のハッシュ値hSkを事前に計算する必要があることは明らかであり、その理由は、mn個のあり得る数のストリームが存在することになり、各ストリームがn個のプレフィクスを有するからである。
【００５５】
ストリーム構造を利用する改善されたバージョンは、各セグメントの保全性をチェックし、その後ストリーム内のセグメントのシーケンスの保全性をチェックすることである。このことにより、以下のようになる。
H(S(i1,1))=hi1,1,H(S(i2,2))=hi2,2,…,H(S(ik,k))=hik,kおよび
H([hi1,1|hi2,2|…|hik,k])=hSk
【００５６】
これにもかかわらず、hSkをチェックするための(n×mn)回の多くの計算が依然として存在する。
【００５７】
動的アダプティブストリーミングのシステムが、セグメントS(i,j)に対応しているハッシュ値hi,jを確実に提供できる信頼できる(第三)者を有する場合には、受信されたセグメントの保全性をチェックすることは単に下のように縮小することができる。
H(S(i1,1))=hi1,1, H(S(i2,2))=hi2,2,…, H(S(ik,k))=hik,k
【００５８】
これは計算に関して最も効率的なものである。このことは、このシステムが必要とするのは、m×n個のハッシュ値のためのm×n回の事前計算、およびクライアントがセグメントを遅滞なく受信しつつストリームの保全性のチェックが漸次実施されるときのこのチェックのためのm回の計算のみであるという理由による。
【００５９】
しかしこれらのハッシュ値の提供のためにこの信頼できる関係者に独立して接触または通信できるという仮定は、実際には現実的でない場合があり、その理由は、このことがクライアントとこの信頼できる関係者との間の余分な通信トランザクションを導入することになるからである。このことは他のオフラインおよびサイドラインの解決法につながる。
【００６０】
オフラインの解決法およびサイドラインの解決法は、セグメントを受信するためのチャネルとは場合によって異なるチャネルを介して、事前計算されたハッシュ値を(それらが利用可能となるように)それらの全体においてまたはいくつかのバッチの形式でのいずれかでクライアントに提供することに依拠し、このためクライアントはいくつかのオンラインサーバからハッシュ値を要求して受信する必要がない。
【００６１】
全てのセグメントがクライアントがそれらの受信を開始する前に利用可能である(ビデオオンデマンド(VOD:video on demand)の場合におけるような)場合、全ての個々のセグメントS(i,j)のハッシュ値hi,jを事前に計算し、1回の通信において、続く図表におけるように描かれる「コードブック」としてクライアントに配信することが可能である(ここでも、場合によってはクライアントがセグメントを得るチャネルとは異なるチャネルを介する)。図5は、適合セットAに関するハッシュ値のコードブックを例示する図表500である。
【００６２】
この場合、クライアントは最初にこの「コードブック」の保全性をチェックし、次いでそれをオンラインの場合のように使用して以下をチェックする必要がある。
H(S(i1,1))=hi1,1, H(S(i2,2))=hi2,2,…, H(S(ik,k))=hik,k
【００６３】
多くの場合、全てのセグメントがクライアントがそれらを受信する時間にはるかに先行して使用可能であるわけではない。さらに、クライアントがストリームのセグメントをそのネットワーク状態およびリソース可用性にしたがって動的な様式で受信することを選択する場合があるので、クライアントがどのストリームを受信することになるかは事前決定されていない。これらの状況では、ハッシュ値はそれらのセグメントが利用可能になったときにだけ計算されてクライアントに提供されることになる。
【００６４】
単純なライブ配信の場合、クライアントがセグメントS(ik,k)を受信するとき、(Aのk番目の列における)全てのセグメントS(i,k)、i=1,2,…,m、が利用可能である。この状況では、これらのセグメントのハッシュ値を事前に計算し、それらをクライアントに「ベクトル」形態[h1,k,h2,k,…,hm,k]で配信することが可能になる。図6はハッシュ値のベクトル形態を例示する図表600である。
【００６５】
このように、任意のkに対して、クライアントはこのk番目の「ベクトル」の保全性を最初にチェックし、次いで使用して以下をチェックする必要がある。
H(S(ik,k))=hik, k
【００６６】
時には、クライアントがセグメントS(ik,k)を受信するとき、(Aのk番目の列における)全てのセグメントS(i,k)、i=1,2,…,m、が利用可能であるかどうかが知られていない。さらに悪いことには、クライアントによって受信されているセグメントS(i1,1),S(i2,2),…,S(ik,k)を除いては、(Aの1からk-1の列における)全てのセグメントが利用可能であるかどうかが知られていない場合がある。
【００６７】
これらの「均一でない」場合に対処するため、インデックス付きリストの手法を取ることができる。これは、いくつかのセグメントS(i,k)が利用可能になるとき、
hi,k=H(S(i,k))
を全ての利用可能なセグメントS(i,k)に対して事前に計算し、クライアントに送るインデックス付きリスト{(i,k,hi,k)}を用意することを必要とする。クライアント側では、クライアントは、セグメントS(ik,k)の受信時に、受信されたリスト内にエントリー(ik,k,hik,k)が存在するかどうかをチェックすることができ、存在する場合には、以下であるかどうかをチェックすることができる。
H(S(ik,k))=hik,k
【００６８】
「均一でない」場合に対処するための別の手法は、連鎖に基づくものである。この手法は、いくつかのセグメントS(i,k)が利用可能になるとき、全てのこれらの利用可能なセグメントS(i,k)に対するハッシュ値
hik=H(S(i,k))
だけではなく、利用可能な任意の2つの「隣接する」セグメントのハッシュ値
gi,k,j=H(hi,k|hj,k-1)
も計算することを必要とする。
【００６９】
この後、一方がセグメントのハッシュ値{hi,k}用、他方が「隣接する」セグメント{gi,k,j}のハッシュ値用である、2つのインデックス付けされていないリストが用意され、クライアントに配信される。クライアント側では、クライアントは、セグメントS(ik,k)の受信時に、それ自体のハッシュ値
h=H(S(ik,k))
を計算し、それがセグメントのハッシュ値に関する受信されたリスト{hi,k}内にあるかどうかをチェックすることができる。ある場合、クライアントは2つの「隣接する」セグメントS(ik-1,k-1)およびS(ik,k)のハッシュ値
g=H(hik,k|hik-1,k-1)
をさらに計算し、gが「隣接する」セグメント{gi,k,j}のハッシュ値に関する受信されたリスト{gi,k,j}内にあるかどうかをチェックする。いずれのチェックも有効であれば、受信されたセグメントS(ik, k)に対する保全性のチェックは満足のいくものである。
【００７０】
一般に、「均一でない」ライブ配信の場合に対する手法はいずれも、「均一な」ライブ配信の場合に適用可能である。たとえば、インデックス付きリストの手法は、「均一な」ライブ配信の場合に対する「ベクトル」の手法と同等であり、その理由は、インデックス付きリスト{(i,k,hi,k)}がi=1,2,…,mに対する全ての(i,k,hi,k)含み、ベクトル[h1,k,h2,k,…,hm,k]の別のリプリゼンテーションになることになるからである。
【００７１】
連鎖に基づく手法は、「均一な」ライブ配信の場合に対して採用されると以下のようになる。k=1に対して、セグメントのハッシュ値に関するインデックス付けされていないリスト{hi,1|i=1,…,m}がただ1つだけ用意される。任意のk>1に対して、2つのインデックス付けされていないリスト{hi,k|i=1,…,m}および{gi,k,j|i,j=1,…,m}が用意される。適合セットA全体に関して全体的に、このことはm×n回のハッシュ値計算、および連続するセグメントの全てのペアリングついて、追加のm2×(n-1)回のハッシュ値の計算を結果としてもたらす。
【００７２】
「均一な」ライブ配信の場合に関してスムースなストリーミングのシステムに連鎖に基づく手法を適用するとき、この手法はm×n回のハッシュ値計算、および連続するセグメントのハッシュ値ペアリングの追加の{2×2+(m-2)×3}×(n-1)回の計算を必要とするので、その複雑さは適合セットAの大きさの線形順序O(m×n)へと低減することができる。
【００７３】
デジタルセキュリティの文献では一般に、デジタルビットのシーケンスの信頼性を提供するためにハッシュ機能および信頼できる関係者によるデジタル署名が一緒に使用される。
【００７４】
セグメントのコンテンツは、たとえばビジネス上の目的または悪意のある攻撃など、何らかの理由で意図的に改変される可能性がある。図7Aは、広告の挿入を例示する図表700であり、図7Bはコンテンツの置換(部分的であり得る)を例示する図表702である。
【００７５】
DASHにおいては、同じコンテンツの符号化バージョンが複数存在し、挿入/置換の可能性が大きくなる。図8Aは、リプリゼンテーションにおけるセグメント置換によるコンテンツの改変を（全体又は部分置換）例示する図表800である。これはいずれの中間ノードにおいても発生し得る。
【００７６】
DASHの場合、時間-リプリゼンテーションの2次元空間において、いくつかのセグメントに関して部分的な置換が存在し得る。また、その入れ替え経路は事前には知られておらず、異なる組み合わせが可能である。このことは組み合わせ問題となり得、その可能性はリプリゼンテーションの数およびセグメントの数とともに指数関数的に高まる。図8Bは入れ替え経路を例示する図表802である。一般に、エンティティは、セグメントが与えられた場合、それが改変されているかどうか、それが元のセット内にあるかどうか、およびその時間順序が変更されているかどうかを、可能な限り最低限の演算および重複性で全て判断できるべきである。
【００７７】
動的セグメントのシーケンスのための認証は、各セグメントのための署名/ダイジェストを生成すること、およびその署名/ダイジェストを特定の順序で結合してメッセージ(組み合わされた署名/ダイジェスト)を形成することを含む。セグメントに関して、そのリプリゼンテーションおよび時間位置を用いて、その対応する署名/ダイジェストがメッセージから抽出される。ダイジェストは、セグメントが何らかの点(セグメント自体または時間順序)において改変されているかどうかを判定するために、そのセグメントに関する局所的に生成されたダイジェストと比較される。
【００７８】
図9は、ダイジェストの生成を例示する図表900である。Si,jはリプリゼンテーションiからのj番目のセグメントを表す。Di,jはセグメントSi,jのダイジェストを表し、Si,jの特性を反映している。Bとして表されるダイジェストDi,jのビットの最低数は、nとして表されるリプリゼンテーションの数によって決定でき、すなわち、B=2n+dであり、ここでdは、ダイジェスト空間がセグメントをn個のリプリゼンテーションから区別するのに充分な大きさであることを確実にするために、0より大きい整数である。
【００７９】
ダイジェスト/署名が固定長であり、それらが特定の順序で結合されて、たとえば、リプリゼンテーション(図10A)、時間で整列させたリプリゼンテーションからのセグメントの組(図10B)、またはリプリゼンテーションのセット(図10C)に関する、結合されたダイジェストを形成すると仮定する。組み合わせは時間-リプリゼンテーション空間において異なる順序であってよく、すなわち、図10A〜図10Cに例示するように、最初が時間で次にリプリゼンテーション、または最初がリプリゼンテーションで次に時間であってよい。
【００８０】
図10Aは、各リプリゼンテーションに関する組み合わされたダイジェストを例示する図表1000である。各リプリゼンテーションはその組み合わされたダイジェストに関するURLを割り当てられ、n個のリプリゼンテーションに対し、n個のURLが存在する。セグメントはリプリゼンテーションにわたって整列させる必要はなく、i≠jである場合、niはnj,に等しくならない場合がある。
【００８１】
図10Bは、各リプリゼンテーションに関する全てのリプリゼンテーションからのj番目のセグメントに関する組み合わされたダイジェスト1002を例示する図表1002である。リプリゼンテーションからのセグメントの組のそれぞれはその組み合わされたダイジェストに関するURLを割り当てられ、その利用可能時間はセグメントの利用可能時間と同じである。組み合わせがリプリゼンテーションの順序に沿っている図10Aとはごくわずかに異なるが、図10Bは、入れ替えが容易なようにセグメントが通常はリプリゼンテーションに沿って時間整列され、同時に開始するセグメントが同時にまたはほぼ同時に利用可能であり、それらのダイジェスト/署名も同時にまたはほぼ同時に利用可能である、ライブ配信の場合に対して有利である。
【００８２】
図10Cは、リプリゼンテーションセットに関する組み合わされたダイジェスト1004を例示する図表1004である。組み合わされたダイジェストに関してURLがn個のリプリゼンテーションを有するリプリゼンテーションセットに割り当てられ、このことは最初に時間順序で次いでリプリゼンテーションの順序で(図10Cに示すように)、または最初にリプリゼンテーションの順序で次いで時間順序で(図示せず)あり得る。セグメントはリプリゼンテーションにわたって整列させる必要はなく、i≠jである場合、niはnj,に等しくならない場合がある。
【００８３】
図11A〜図11Dは、取り出されたセグメントに関して、そのインデックスiおよびjを用いて、組み合わされたダイジェストからそのダイジェストの位置を見つけることが可能であることを例示する、図表1100、図表1102、図表1104、図表1106である。図11Dは、セグメントがリプリゼンテーションにわたって時間整列された(各リプリゼンテーションが同数のセグメントを含む)簡略化した場合であることに留意されたい。
【００８４】
図12は、取り出されたセグメントに関する局所的なダイジェスト/署名を生成することを例示する図表1200である。比較したとき、S'i,j=Si,jであれば、認証は合格である。そうでなければ、認証は不合格である。
【００８５】
実施形態は組み合わされたダイジェストに関するURLを割り当てる。組み合わされたダイジェストに関するURLはそのダイジェストをどこで取り出すべきかを信号送信するためにMPDによって運ばれる。クライアントは組み合わされたダイジェストを取り出す。クライアントは特定のセグメントに関するダイジェストを抽出する。クライアントは抽出されたダイジェストをセグメントに関する局所的に生成されたダイジェストと比較し、結論を下す。
【００８６】
動的セグメントのシーケンスのための認証のための方法の実施形態は、各セグメントに関する署名/ダイジェストを生成すること、および署名/ダイジェストを特定の順序で結合してメッセージ(組み合わされた署名/ダイジェスト)を形成することを含む。セグメントに関して、そのリプリゼンテーションおよび時間位置を用いて、その対応する部分の署名/ダイジェストがメッセージから抽出される。メッセージは、セグメントが何らかの点(セットまたは時間順序)において改変されているかどうかを判定するために、セグメントに関する局所的に生成されたメッセージと比較される。この方法はサーバ/ストレージ/クライアントのシステム上で実装されてよい。
【００８７】
軽度の部分的な暗号化のための方法の実施形態は、各セグメントに関する署名/ダイジェスト生成すること、および署名/ダイジェストを特定の順序(時間-リプリゼンテーション)で結合して組み合わされた署名/ダイジェストを形成することを含む。方法は、Aと名付けられた取り出されたセグメントに関する署名/ダイジェストを生成することを含む。リプリゼンテーションおよびセグメントの時間場所とともに、方法は、Bと名付けられた組み合わされた署名/ダイジェストからの対応する部分を抽出するためのマスクを生成することを含む。方法はAとBとを比較してセグメントが改変されているか否かを判定する。
【００８８】
システム/クライアントの方法において、第1の関係者はセグメントセットに関するメッセージ(セグメントの2次元情報)を生成する。第2の関係者はメッセージを使用して、取り出されたセグメントが改変されているか否かを判定する(セット、時間順序の両方が変更されるわけではない)。
【００８９】
実施形態は必要とされる通信がより少なくなるように動的シーケンスを認証する(各セグメントに関してではない)。ケース(a)ではN個の組み合わされたダイジェスト/署名がフェッチされ、一方ケース(b)では単一の組み合わされたダイジェスト/署名がフェッチされる。実施形態は計算量のより少ない動的シーケンスを認証する。実施形態は、メディアコンテンツが改変されているかどうか、セグメントが改変されているかどうか、または時間順序が変更されているかどうかの検出を可能にする、改善されたセキュリティを提供する。
【００９０】
図13は、アダプティブストリーミングのための、セグメントの保全性および信頼性を検証するための方法1300の実施形態のフローチャートである。方法1300は、クライアントがメディアストリームのセグメントを受信するブロック1302で開始する。ブロック1304で、クライアントはメディアストリームのデジタル署名を決定する。ブロック1306で、クライアントは信頼できるソースから受信されたセグメントに関する正しいデジタル署名を受信する。ブロック1308で、クライアントは決定されたデジタル署名を正しいデジタル署名と比較し、ブロック1310で2つのデジタル署名が同じかどうか判定する。ブロック1310で、2つのデジタル署名が同じであるとき、方法1300はブロック1312に進み、そこでクライアントはセグメントが真正であることを判定し、セグメントの処理を適切に継続し、その後、方法1300は終了してよい。ブロック1310でクライアントが2つのデジタル署名が同じでないと判定した場合は、方法1300はブロック1314に進み、そこでクライアントはセグメントが改変されていると判定する。方法1300は次いでブロック1316に進み、そこでクライアントはセグメントを廃棄しメディアソースサーバにセグメントを再送するように要求でき、その後、方法1300は終了してよい。
【００９１】
図14は、本明細書に開示されたデバイスおよび方法を実装するために使用できる処理システム1400のブロック図である。特定のデバイスは示された全ての構成要素を利用しても、または構成要素のサブセットのみを利用してもよく、統合のレベルはデバイスによって異なってよい。さらに、デバイスは、複数の処理ユニット、プロセッサ、メモリ、送信機、受信機などのような、構成要素の複数の例を含んでよい。処理システム1400は、スピーカ、マイクロフォン、マウス、タッチスクリーン、キーパッド、キーボード、プリンタ、ディスプレイなどの、1つまたは複数の入力/出力デバイスを備えた処理ユニット1401を含んでよい。処理ユニットは、バス1414に接続された中央処理ユニット(CPU)1402、メモリ1408、マスストレージデバイス1404、ビデオアダプタ1410、およびI/Oインターフェース1412を含んでよい。
【００９２】
バス1414は、メモリバスもしくはメモリコントローラ、周辺バス、またはビデオバスなどを含む、任意のタイプのいくつかのバスアーキテクチャの内の1つまたは複数であってよい。CPU1402は任意のタイプの電子データプロセッサを含んでよい。メモリ1408は、静的ランダムアクセスメモリ(SRAM)、動的ランダムアクセスメモリ(DRAM)、シンクロナスDRAM(SDRAM)、読取専用メモリ(ROM)、またはそれらの組み合わせなどのような、任意のタイプのシステムメモリを含んでよい。実施形態において、メモリ1408はブートアップで使用するためのROM、ならびにプログラムおよびプログラムの実行中に使用するためのデータストレージのためのDRAMを含んでよい。
【００９３】
マスストレージデバイス1404は、データ、プログラム、および他の情報を記憶するように、かつそのデータ、プログラム、および他の情報をバス1414を介してアクセス可能とするように構成された、任意のタイプのストレージデバイスを含んでよい。マスストレージデバイス1404は、たとえば、ソリッドステートドライブ、ハードディスク、磁気ディスクドライブ、もしくは光学ディスクドライブなどの内の1つまたは複数を含んでよい。
【００９４】
ビデオアダプタ1410およびI/Oインターフェース1412は、外部入出力デバイスを処理ユニット1401に結合するためのインターフェースを提供する。例示したように、出力デバイスの例には、ビデオアダプタ1410に結合されたディスプレイ1416、およびI/Oインターフェース1412に結合されたマウス/キーボード/プリンタ1418を含む。他のデバイスが処理ユニット1401に結合されてもよく、また追加のまたはより少ないインターフェースカードが利用されてもよい。たとえば、ユニバーサルシリアルバス(USB)のようなシリアルインターフェース(図示せず)を使用してプリンタにインターフェースを提供してもよい。
【００９５】
処理ユニット1401は、イーサネット(登録商標)ケーブルなどのような有線リンク、および/またはアクセスノードもしくは異なるネットワーク1420へのワイヤレスリンクを含み得る、1つまたは複数のネットワークインターフェース1406も含む。ネットワークインターフェース1406は処理ユニット1401がネットワーク1420を介して遠隔のユニットと通信することを可能にする。たとえば、ネットワークインターフェース1406は、1つまたは複数の送信機/送信アンテナおよび1つまたは複数の受信機/受信アンテナを介して、ワイヤレス通信を提供してもよい。実施形態では、処理ユニット1401は、データ処理のために、および他の処理ユニット、インターネット、もしくは遠隔のストレージ設備などの遠隔のデバイスとの通信のために、ローカルエリアネットワークまたはワイドエリアネットワークに結合される。
【００９６】
説明は詳細に記載されているが、添付の特許請求の範囲に定義されている本開示の精神および範囲から逸脱することなく、様々な変更、置き換えおよび修正を行い得ることが理解されるべきである。さらに、本開示から、既存のまたは今後開発される、プロセス、機械、製造、物質の組成、手段、方法、もしくはステップが、本明細書に記載の対応する実施形態と実質的に同じ機能を実行し得る、または実質的に同じ結果を達成し得ることを、当業者は容易に諒解すると考えられるので、本開示の範囲は本明細書に記載の特定の実施形態に限定されることは意図していない。したがって、添付の特許請求の範囲は、その範囲内にそのようなプロセス、機械、製造、物質の組成、手段、方法、またはステップ含むことを意図している。
【符号の説明】
【００９７】
100  システム
102  クライアント
104  メディアソースサーバ
106  認証サーバ
108  悪意のあるサーバ
110  ネットワーク
300  図表
400  図表
500  図表
600  図表
700  図表
702  図表
800  図表
802  図表
900  図表
1000  図表
1002  図表
1004  図表
1100  図表
1102  図表
1104  図表
1106  図表
1200  図表
1300  方法
1302  ブロック
1304  ブロック
1306  ブロック
1308  ブロック
1310  ブロック
1312  ブロック
1314  ブロック
1316  ブロック
1400  処理システム
1401  処理ユニット
1414  バス
1402  中央処理ユニット(CPU)
1404  マスストレージデバイス
1408  メモリ
1410  ビデオアダプタ
1412  I/Oインターフェース
1414  バス
【図１】
2015519814.tif 000005
【図２】
2015519814.tif 000006
【図３】
2015519814.tif 000007
【図４】
2015519814.tif 000008
【図５】
2015519814.tif 000009
【図６】
2015519814.tif 000010
【図７Ａ】
2015519814.tif 000011
【図７Ｂ】
2015519814.tif 000012
【図８Ａ】
2015519814.tif 000013
【図８Ｂ】
2015519814.tif 000014
【図９】
2015519814.tif 000015
【図１０Ａ】
2015519814.tif 000016
【図１０Ｂ】
2015519814.tif 000017
【図１０Ｃ】
2015519814.tif 000018
【図１１Ａ】
2015519814.tif 000019
【図１１Ｂ】
2015519814.tif 000020
【図１１Ｃ】
2015519814.tif 000021
【図１１Ｄ】
2015519814.tif 000022
【図１２】
2015519814.tif 000023
【図１３】
2015519814.tif 000024
【図１４】
2015519814.tif 000025
【国際調査報告】
2015519814.tif 000026