JP7061121B2 - 配信性能を改善するためのリソースセグメント化 - Google Patents

Description

ライブストリーミングにおいて使用されるメディアセグメントのようなリソースをセグメント化するための実施形態が開示される。

現行のストリーミング手法

ライブおよびビデオオンデマンドに適応するビットレートストリーミングのための現行の手法は、主として、ハイパーテキスト転送プロトコル（ＨＴＴＰ）に依拠する（例えば、［ＨＴＴＰ］を参照されたい）。これらの手法において、クライアント（Ｕｓｅｒ Ａｇｅｎｔ（ユーザエージェント）またはＵＡとしても参照される）は、各々がメディアサンプル（すなわち、オーディオサンプルおよび／またはビデオサンプル）を包含する複数のメディアセグメントを抽出するために、ＨＴＴＰを使用することができる。これらのメディアセグメントは、クライアントがメディアセグメントをパースし、メディアサンプルを復号し、最終的にはメディアをクライアントのユーザに向けて再生することを可能にする、一定のフォーマット（例えば、ＩＳＯＢＭＦＦ）に従う。すなわち、メディアセグメントを抽出した後、クライアントは、メディアセグメントのコンテンツをパースし、ユーザ向けにレンダリングすることが可能である。

これらの現行の手法の下では、そのようなメディアセグメントの内在的に異なる表現（例えば、異なった符号化品質の異なる表現）を含む、個々のメディアセグメントの所在に関する情報を提供するより上位の層が存在する。以下の２つの支配的なソリューションが使用される。（１）ＨＴＴＰライブストリーミング（ＨＬＳ）（例えば、［ＨＬＳ］参照）および（２）ＨＴＴＰ上の動的適応ストリーミング（Ｄｙｎａｍｉｃ ａｄａｐｔｉｖｅ ｓｔｒｅａｍｉｎｇ ｏｖｅｒ ＨＴＴＰ）（ＤＡＳＨ）（例えば、［ＤＡＳＨ］参照）。これらのソリューションは両方とも、種々のメディアセグメントおよびそれらのメディアセグメントのビットレートを記述するマニフェストファイルを使用し、結果、ストリーミングクライアントは、いずれのメディアセグメントを抽出するべきかを判定することができる。いくつかの異なるメディアセグメントフォーマットが存在するが、ＨＬＳとＤＡＳＨは両方とも、ＩＳＯベースメディアファイルフォーマット（ＩＳＯＢＭＦＦ）をサポートしている（例えば、［ＩＳＯＢＭＦＦ］参照）。

メディアセグメントフォーマット

ＩＳＯＢＭＦＦは、柔軟なメディアコンテナファイルフォーマットである。ＩＳＯＢＭＦＦは、ボックスと呼ばれる構造から構成される。ボックスは、識別子および長さフィールドを含むことができ、ボックスが何を包含しているかを規定するメタデータを含むことができる。ボックスは、他のタイプの１つまたは複数のボックスを包含することができる。一定のタイプのメディアまたは使用事例のためのもののような、特定のフォーマットは、汎用のＩＳＯＢＭＦＦ構造に追加の制約を課す（例えば、メディアファイルに対する要件を規定する、ファイルが包含しなければならないボックスのタイプを指定する）場合がある。ＤＡＳＨは、Ｉｎｉｔｉａｌｉｚａｔｉｏｎ Ｓｅｇｍｅｎｔ（初期化セグメント）およびＭｅｄｉａ Ｓｅｇｍｅｎｔ（メディアセグメント）のような、ＩＳＯＢＭＦＦファイルフォーマットを使用して、いくつかのタイプのセグメントを規定する。Ｉｎｉｔｉａｌｉｚａｔｉｏｎ Ｓｅｇｍｅｎｔは、Ｍｅｄｉａ Ｓｅｇｍｅｎｔを復号するのに必要な情報を包含することができる。ただし、Ｍｅｄｉａ Ｓｅｇｍｅｎｔのみがメディアサンプルを包含する。各Ｍｅｄｉａ Ｓｅｇｍｅｎｔは、ｍｏｏｆボックスおよびｍｄａｔボックスを包含する。

ＭＯＯＦボックスは、トラックランボックス（Ｔｒａｃｋ Ｒｕｎ Ｂｏｘ）（ｔｒｕｎ）を包含するトラックフラグメント（ｔｒａｆ）ボックスを包含する。ｔｒｕｎボックスは、ｍｄａｔボックスの内部に記憶されているメディアサンブルの連続的なセットを記録する。そのため、各メディアサンプルについて、少なくともそのサンプルのデータサイズ、およびメディアサンプルの持続時間が提供される。これによって、メディアサンプルが、ｍｄａｔボックスの内部に連続して記憶されることが可能になる。ｍｏｏｆボックスは、ｍｄａｔボックスの前に記憶される。

作業負荷の分散

ＨＴＴＰの帯域外（ＯＯＢ）コンテンツ符号化メカニズムに関して、進行中の研究が存在する（例えば、［ＯＯＢ］を参照されたい）。このＯＯＢメカニズムは、サーバが、ＨＴＴＰレスポンスボディのサービングを別の信頼ドメインにリダイレクトすることを可能にする。このメカニズムは例えば、すべての個々のＨＴＴＰ要求がトランスポート層セキュリティ（ＴＬＳ）接続の文脈において行われるときに、同一オリジンポリシに違反することなく、良好なプライバシ特性を有し、より柔軟なコンテンツ配布を可能にする、コンテンツ配布ネットワーク（ＣＤＮ）ノード、エッジサーバまたはサードパーティキャッシュ／プロキシへのセキュアなリダイレクトのために使用することができる。

ＨＴＴＰ代替サービス（例えば、［ａｌｔ－ｓｅｒｖｉｃｅｓ］参照）は、要求に対する応答を他のネットワークロケーション、および、場合によっては他の配信プロトコルにリダイレクトするための別の方法である。ＨＴＴＰ代替サービスを使用して、リソースのアイデンティティがリソースの位置から分離される。しかしながら、このリダイレクトは、リダイレクト元全体に適用され、個々のリソースレベルで実施することはできない。

リソース検証

ＨＴＴＰの文脈において、要求を受けているリソース（例えば、要求を受けているメディアセグメント）のボディのインテグリティを保護および検証するためのいくつかの異なるメカニズムが開発されている。１つの提案は、レスポンスボディのシグネチャである（例えば、［ＣＯＮＴＥＮＴＳＩＧ］参照）。別の手法は、コンテンツ符号化としてのメッセージ本文の機密性およびインテグリティ検証を可能にする、高度暗号化標準（ＡＥＳ：Ａｄｖａｎｃｅｄ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ）ガロアカウンタモード（ＧＣＭ）、すなわちＡＥＳ ＧＣＭの適用である（例えば、［ａｅｓｇｃｍ］参照）。別の提案は、固定サイズレコードを使用したインテグリティ検証を提供するマークルインテグリティコンテンツ符号化（Ｍｅｒｋｌｅ Ｉｎｔｅｇｒｉｔｙ Ｃｏｎｔｅｎｔ Ｅｎｃｏｄｉｎｇ）、すなわちＭＩＣＥである（例えば、［ＭＩＣＥ］参照）。ＭＩＣＥによって、各レコードを、到来するときに検証することができ、以前のレコードが検証されていること、または、検証を実施するエンティティにとってそのレコードに対する正当なハッシュが分かっていることを所与として、受信手段側での漸進的な検証が可能になる。

先行技術文献
[0014] [CONTENTSIG] Thomson, M., "Content-Signature Header Field for HTTP", draft-thomson-http-content-signature-00 (work in progress), July 2015.
[0015] [MICE] Thomson, M., “Merkle Integrity Content Encoding”, draft-thomson-http-mice-01 (work in progress), June 2016.
[0016] [OOB] J. Reschke, and S. Loreto, “‘Out-Of-Band’ Content Coding for HTTP”, draft-reschke-http-oob-encoding-08 (work in progress), September 2016.
[0017] [RFC6454], A. Barth, “The Web Origin Concept”, RFC 6454, December 2011.
[0018] [HLS] R. Pantos, and W. May, “HTTP Live Streaming”, draft-pantos-http-live-streaming-20 (work in progress), September 2016.
[0019] [DASH] “Information technology -- Dynamic adaptive streaming over HTTP (DASH) -- Part 1: Media presentation description and segment formats”, ISO/IEC 23009-1:2014, May 2014.
[0020] [HTTP] R. Fielding, J. Reschke, “Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing”, IETF RFC 7230, June 2014.
[0021] [ISOBMFF] “Information technology - Coding of audio-visual objects - Part 12: ISO base media file format”, ISO/IEC 14496-12, July 2012.
[0022] [aesgcm] M. Thomson, “Encrypted Content-Encoding for HTTP”, IETF draft-ietf-httpbis-encryption-encoding-03 (work in progress), October 2016.
[0023] [alt-services] M. Nottingham, et al, “HTTP Alternative Services”, IETF RFC 7838, April 2016.
[0024] [S4-141201] 3GPP TSG-SA4 #81, “MI-EMO: Guidelines for out of order sending of movie fragments”, http://www.3gpp.org/ftp/tsg_sa/wg4_codec/TSGS4_81/Docs/S4-141201.zip, August 2014.

既存のソリューションによる問題

ライブストリーミングを配信するための１つの一般的な方法は、ＩＳＯベースメディアファイルフォーマット（ＩＳＯ ＢＭＦＦ）を用いるＤＡＳＨを使用することである。ＩＳＯ ＢＭＦＦメディアセグメントフォーマットは、ｍｏｏｆボックス（すなわち、対応するｍｄａｔボックス内に含まれるメディアサンプルのメタデータ（例えば、長さおよび位置）を包含するボックス）がｍｄａｔボックスに先行することを指定する。この要件は、符号化手段が対応するメディアサンプルの符号化を完了する前に、符号化手段がｍｏｏｆ全体を生成することを防止する。それゆえ、この要件によって遅延が導入される。遅延は、Ｔ_{ｓｏｕｒｃｅ＿ｔｏ＿ｐｌａｙｂａｃｋ}（符号化手段がメディアセグメントのメディアサンプルの生成を開始するときから、クライアントが再生を開始することができるときまでの遅延）として測定することができる。この遅延は、メディアセグメントがどれだけ早く観賞のために利用可能になるかに影響を与えるため、ユーザにとって重要である。Ｔ_{ｓｏｕｒｃｅ＿ｔｏ＿ｐｌａｙｂａｃｋ}はさらに、Ｔ_{ｓｏｕｒｃｅ＿ｔｏ＿ｒｅｃｅｐｔｉｏｎ}（符号化手段がメディアセグメントの符号化を開始するときから、符号化手段がメディアセグメントを受信エンティティに提供することができるときまでの遅延）とＴ_{ｒｅｃｅｐｔｉｏｎ＿ｔｏ＿ｐｌａｙｂａｃｋ}（受信エンティティが最初にメディアセグメントの受信を開始するときから、再生を開始することができるときまでの遅延）との合計として測定することができる。それゆえ、メディアサンプルの長さおよび位置が、データ部分よりも前にファイルフォーマット内に書き込まれる必要があることによって（例えば、すべてのメディアサンプルが生成されるまで、ｍｏｏｆは完了され得ない）、Ｔ_{ｓｏｕｒｃｅ＿ｔｏ＿ｒｅｃｅｐｔｉｏｎ}が増大するため、Ｔ_{ｓｏｕｒｃｅ＿ｔｏ＿ｐｌａｙｂａｃｋ}が増大する。この遅延は、メディアセグメントの長さ（典型的には約２～１０秒）とともに増大する。

この遅延に対処するための、すなわち、上記で言及した遅延を最小限に抑えるための１つの既知の手法は、特定のメディアセグメントに複数のＩＳＯＢＭＦＦ「動画フラグメント」を作成することである。すなわち、ｍｏｏｆ／ｍｄａｔボックス対のシーケンスを含むメディアセグメントを作成することである。例えば、メディアセグメントは、第１の動画フラグメント（すなわち、第１のｍｏｏｆボックスおよびその後の第１のｍｄａｔボックス）および第２の動画フラグメント（すなわち、第２のｍｏｏｆボックスおよびその後の第２のｍｄａｔボックス）を包含することができる。これによって、動画フラグメントが作成されたときに直ちに動画フラグメントを伝送することが可能になる。遅延はフラグメントの長さに依存するため、これによって、遅延を低減することができ、この手法は、各々の長さがより小さい、より多くのフラグメントを作成する。しかしながら、遅延の低減に加えて、この手法はまた、オーバヘッドを増大させる。さらに、この手法は、追加のランダムアクセスポイント（規格に従って、セグメント内のいかなる以前のデータに依拠することもなく復号および連続再生を開始することができるポイントとして規定される）を作成する。ランダムアクセスポイントの頻度は符号化の効率に悪影響を与える（例えば、ビデオ符号化について、この手法はＩフレームの数を準最適にする場合がある）ため、この手法はまた、ビデオ符号化に影響を与える可能性もある。

上述した手法にはまた、追加の問題もある。例えば、この手法にはさらに、リソース（例えば、メディアセグメント）のインテグリティの検証が必要であるときには、ランダムアクセスが許容されないという問題がある。インテグリティメカニズムの特性に起因して、制約のないランダムアクセスは可能ではない。にもかかわらず、上述した手法は、リソースの開始を除いて、リソース内のいかなるランダムアクセスポイントも許容しない。追加のランダムアクセスポイントを提供することによって、ライブストリームに後から参加することを可能にすること、または、より大きいビデオシーケンス内で探索すること、または、メディアセグメント内の特定のランダムアクセスポイントにアクセスすることなどの利点が提供される。

帯域外（ＯＯＢ）符号化、特にＨＴＴＰリソース抽出とともに上述した手法を利用するときに、さらなる問題が生じる。例えば、ＡＥＳ ＧＣＭを検証に使用する場合、上述した手法は、リソースのインテグリティを検証するために、リソース全体が抽出されることを必要とする。このリソース全体の抽出は、受信クライアントがコンテンツをプレイアウトすることができるまでのコンテンツ取り込みの間の最短時間、すなわち、符号化とクライアント再生との間の時間（すなわち、Ｔ_{ｓｏｕｒｃｅ＿ｔｏ＿ｐｌａｙｂａｃｋ}）に影響を与える。取り込み（符号化）側において、コンテンツは、インテグリティ検証ハッシュを算出することができるようになるまでに完全に取り込まれることを要求する。これは、そのようなハッシュが、リソース全体にわたって計算されるためである。その後、受信手段（復号）側において、送信されるように意図されたものによって何を受信したかを検証しているクライアントは、最初に、インテグリティハッシュが算出されたすべてのコンテンツ、すなわち、リソース全体を受信しなければならない。

ＡＥＳ ＧＣＭに加えて、別の既知の手法は、マークルインテグリティコンテンツ符号化（ＭＩＣＥ）である。しかしながら、たとえＭＩＣＥが使用される場合であっても、依然として欠点がある。ＭＩＣＥは、各ブロックが配信を完了したときに、受信手段がリソースの漸進的な検証をブロックごとに実施することを可能にするため（ブロックはリソースよりも小さい単位である）、ＡＥＳ ＧＣＭによるいくつかの問題に部分的に対処する。したがって、上記で言及したクライアント側遅延は、リソース全体のサイズではなく、使用されるブロックサイズ、および、ブロックの、基礎となるコンテンツ構造との位置整合に依存する。しかしながら、このＭＩＣＥ手法は、インテグリティ保護を算出し、ハッシュチェーンをコンテンツに追加するときに、符号化手段がリソースの最後の部分を有することを依然として必要とするため、ＭＩＣＥは、上記で言及したサーバ側遅延には対処しない。

既知のインテグリティ検証メカニズムは、動的に生成されるコンテンツでは有効に作用しない。これは、そのようなメカニズムが、符号化手段が検証されるべきリソース全体を知ることを必要とする傾向にあるためである。データが単一のサーバまたは信頼ドメインによって送信されているとき、チャンク転送符号化とともにＴＬＳまたはＳＳＬを使用することができ、トランスポートレベルにおいてデータを検証することが可能であり得るが、そのソリューションは、帯域外サーバからのリソースのインテグリティ検証に依存するＯＯＢのような配信モデルのように、複数のドメインが情報を送出しているときには実践可能ではない。

例示的な提案される実施形態の簡潔な概要

本出願は、リソース（例えば、メディアセグメントのようなメディアリソース、または、通常、ＨＴＴＰのような汎用のファイル転送プロトコルを使用してフェッチまたはプッシュされるリソースのような他のリソース）を複数のフラグメントにセグメント化するための柔軟な手法を記載する。そのような手法を利用することによって、クライアント側でリソースを利用することができるようになるまでの遅延が低減される。ライブＤＡＳＨストリーミングによって使用されるもののような、ビデオストリーミングのＩＳＯＢＭＦＦメディアセグメントに特異的な、柔軟なセグメント化手法を適用する一定の実施形態が提供される。これらの実施形態は、記載されている柔軟なセグメント化を使用することによって、クライアント側での再生を開始することができるようになるまでにサーバ側で利用可能になるメディアサンプル間の遅延（すなわち、Ｔ_{ｓｏｕｒｃｅ＿ｔｏ＿ｐｌａｙｂａｃｋ}）を大幅に低減することができる。１つの実施形態において、この低減は、リソースの部分が抽出される順序を変化させることが可能であるとともに（例えば、抽出順序は論理的順序とは異なる場合がある）、取り込まれているメディアサンプルによって作成されるときにリソースの部分の漸進的フェッチまたはプッシュを可能にすることができる、本明細書において提案されているファイルセグメント化メカニズムを使用することによって達成される。提案されているリソースセグメント化メカニズムはまた、受信手段（クライアント側）が既知のソリューションが有効化するよりも早い段階においてリソースフラグメントを利用することを可能にするためのメタデータをも提供する。

本出願の別の態様は、柔軟なセグメント化によって提供される特性および利益を維持しながら、全リソースおよびリソースフラグメントのインテグリティを保証することに関する。例えば、記載されている手法は、リソースフラグメントの個々のチャンクの漸進的インテグリティ検証を可能にする。漸進的に生成されることになるリソースについて、個々のチャンクまたはチャンクのグループ（インテグリティブロック）にわたるハッシュが、漸進的検証を可能にする。各インテグリティブロックに対する個々のハッシュに対してシグネチャを使用することによって、ハッシュが信頼できること、すなわち、ハッシュが信頼できるエンティティによって生成されていることが保証される。適切なインテグリティ保護を含むセグメント化ソリューションはまた、例えば、帯域外符号化またはＨＴＴＰにおける代替的なサービスを使用するときに作成されるもののような、種々の信頼ドメインからのリソースセグメントの抽出に対処することも可能である。ソリューションはまた、複数の信頼およびセキュリティのコンテキストの使用を完全にサポートするために、個々のリソースセグメントの機密性保護のための、独立したもしくは異なるキー、またはさらには独立したもしくは異なる保護メカニズムをもサポートする。

１つの態様において、サーバによって実施される方法が提供される。方法は、サーバが、第１のフラグメントおよび第２のフラグメントを含むフラグメントの順序付けされたセットを含む、メディアセグメントのセグメント化マップを生成することを含む。方法はまた、サーバが、セグメント化マップをクライアントに提供することをも含む。セグメント化マップは、第１のフラグメントと関連付けられる第１のフラグメントメタデータと、第２のフラグメントと関連付けられる第２のフラグメントメタデータと、第１のフラグメントが第２のフラグメントの前に順序付けされていることを指示する情報を含む、セット内のフラグメントの順序付けを識別する順序付け情報とを含む。第１のフラグメントメタデータは、１）第１のフラグメントへのアクセスに使用するための第１のフラグメント識別子と、２）以下のもの、すなわち、２ａ）サーバから配信されるべき第１のフラグメントの利用可能性がセットの１つもしくは複数の他のフラグメントに依存することを指示する、第１のフラグメントの第１の依存性情報と、２ｂ）第１のフラグメントの長さ、メディアセグメント内の第１のフラグメントの開始位置、およびメディアセグメント内の第１のフラグメントの終端位置のうちの１つもしくは複数を含む第１の位置情報、ならびに２ｃ）第１のフラグメントのインテグリティの検証に使用するための第１のフラグメントレベルセキュリティ情報のうちの１つまたは複数とを備える。第２のフラグメントメタデータは、第２のフラグメントへのアクセスに使用するための第２のフラグメント識別子を含む。

いくつかの実施形態において、第１のフラグメントメタデータは、第１の依存性情報、第１の位置情報、および第１のフラグメントレベルセキュリティ情報を含む。

いくつかの実施形態において、第１のフラグメントメタデータは、第１のフラグメントレベルセキュリティ情報を含み、フラグメントレベルセキュリティ情報は、サーバによって、第１のフラグメントおよび第１のフラグメントの一部のうちの少なくとも一方のハッシュを生成するために使用されるハッシュ情報を含む。

いくつかの実施形態において、第２のフラグメントメタデータは、サーバから配信されるべき第２のフラグメントの利用可能性がセットの１つもしくは複数の他のフラグメントに依存することを指示する、第２のフラグメントの第２の依存性情報と、第２のフラグメントの長さ、メディアセグメント内の第２のフラグメントの開始位置、およびメディアセグメント内の第２のフラグメントの終端位置のうちの１つもしくは複数を含む第２の位置情報、ならびに、第２のフラグメントのインテグリティの検証に使用するための第２のフラグメントレベルセキュリティ情報のうちの１つまたは複数とを含む。

いくつかの実施形態において、第１のフラグメントメタデータは、第１のフラグメントに対応する優先度値をさらに含む。

いくつかの実施形態において、第１のフラグメントメタデータは、符号化識別子をさらに含む。

いくつかの実施形態において、第１のフラグメント識別子は、第１のフラグメントを識別する統一資源識別子（ＵＲＩ）を含む。

いくつかの実施形態において、第１のフラグメントメタデータは、メディアセグメントのタイプと関連付けられるアプリケーションレベルヒントをさらに含み、アプリケーションレベルヒントは、クライアントが、他の複数のフラグメントの各々を受信する前に第１のフラグメントを利用することを可能にする。

いくつかの実施形態において、第１の依存性情報は、サイズ依存性情報を含み、サイズ依存性情報は、第１のフラグメントのサイズが判定される可能性がある前に生成されなければならない０個以上の他のフラグメントを指示する。

いくつかの実施形態において、第１の依存性情報は、コンテンツ依存性情報を含み、コンテンツ依存性情報は、第１のフラグメントのコンテンツが判定される可能性がある前に生成されなければならない０個以上の他のフラグメントを指示する。

いくつかの実施形態において、順序付け情報は、各フラグメントメタデータと関連付けられるシーケンス識別子を含む。

いくつかの実施形態において、順序付け情報は、複数のフラグメントメタデータを記憶するデータ構造内に内在する。

いくつかの実施形態において、セグメントマップは、メディアセグメントのメディアタイプ、リソースレベルインテグリティ情報、メディアセグメントの統一資源位置指定子（ＵＲＬ）、および、クライアントがセグメント化マップを更新することが推奨される場合を指示する更新ヒントのうちの１つまたは複数を含むメディアセグメントメタデータをさらに含み、更新ヒントは、期限切れ時間およびコンテンツ依存性属性のうちの１つまたは複数を含む。

いくつかの実施形態において、方法はまた、クライアントから、メディアセグメントを求める要求を受信することと、メディアセグメントを求める要求に応答して、クライアントに、セグメント化マップを送信することとをも含む。

いくつかの実施形態において、方法はまた、クライアントから、第１のフラグメントを求める要求を受信することと、第１のフラグメントを求める要求を受信することに応答して、クライアントに、第１のフラグメントを送信することとをも含む。

いくつかの実施形態において、方法はまた、新たな情報に基づいてセグメント化マップを更新することであって、新たな情報は、複数のフラグメントのうちの１つの長さ、複数のフラグメントのうちの１つの開始位置、および複数のフラグメントのうちの１つの終端位置のうちの１つまたは複数を含む、更新することと、クライアントに更新されているセグメント化マップを送信することとをも含む。

別の態様において、クライアントによって実施される方法が提供される。方法は、クライアントが、サーバによって伝送されるセグメント化マップを受信することを含み、セグメント化マップは、複数のメディアセグメントを含むメディアストリームの第１のメディアセグメントのためのものであり、複数のメディアセグメントは、第１のメディアセグメントおよび第２のメディアセグメントを含み、第１のメディアセグメントは、フラグメントの順序付けされたセットを含み、フラグメントの順序付けされたセットは、第１のフラグメントおよび第２のフラグメントを含む。方法はまた、クライアントが、セグメント化マップを処理することをも含む。セグメント化マップは、第１のフラグメントと関連付けられる第１のフラグメントメタデータと、第２のフラグメントと関連付けられる第２のフラグメントメタデータと、第１のフラグメントが第２のフラグメントの前に順序付けされていることを指示する情報を含む、セット内のフラグメントの順序付けを識別する順序付け情報とを含む。第１のフラグメントメタデータは、１）第１のフラグメントへのアクセスに使用するための第１のフラグメント識別子と、２）以下のもの、すなわち、２ａ）サーバから配信されるべき第１のフラグメントの利用可能性がセットの１つもしくは複数の他のフラグメントに依存することを指示する、第１のフラグメントの第１の依存性情報と、２ｂ）第１のフラグメントの長さ、第１のメディアセグメント内の第１のフラグメントの開始位置、および第１のメディアセグメント内の第１のフラグメントの終端位置のうちの１つもしくは複数を含む第１の位置情報、ならびに２ｃ）第１のフラグメントのインテグリティの検証に使用するための第１のフラグメントレベルセキュリティ情報のうちの１つまたは複数とを含む。第２のフラグメントメタデータは、第２のフラグメントへのアクセスに使用するための第２のフラグメント識別子を含む。

他の実施形態および態様が下記に記載される。

利点

柔軟なセグメント化メカニズムは、いくつかの方法で配信を改善するために使用することができる。例えば、受信クライアントによってリソースの関連するフラグメントを消費することができるようになるまでの遅延を低減することができる。別の例は、この手法が、受信クライアントの近くのエッジサーバまたはキャッシュの使用を十分にサポートし、そのようなエッジサーバまたはキャッシュ内でリソースフラグメントが利用可能になることを可能にし、ユーザが、より近いまたは他の様態で最適なプロバイダから任意のフラグメントを取得することを可能にし、一方で、他のフラグメントを、それらのフラグメントが利用可能である他のインスタンスから抽出することができることである。この結果として、配信性能が改善される。また別の例は、リソースフラグメント記憶において冗長性を提供し、これをユーザに指示することである。また別の利点は、場合によっては異なるソースから複数のフラグメントを同時に抽出または受信することが可能であることであり、この結果として、配信性能を改善し、符号化過程をより高速にすることができる。

さらに、本出願において記載されているセグメント化メカニズムは、メディアセグメントのインテリジェントなセグメント化によって、コンテンツ取り込みからＤＡＳＨおよびＨＬＳのようなライブストリーミングメカニズムのプレイアウトまでの遅延（Ｔ_{ｓｏｕｒｃｅ＿ｔｏ＿ｐｌａｙｂａｃｋ}）を大幅に改善するために使用することができる。このインテリジェントなセグメント化は、符号化メディアサンプルがパケタイザによってセグメントに追加されるときに、個々のフラグメントのクライアントへの漸進的な配信を可能にする。これはまた、伝送を開始することが可能になる前に、ＩＳＯＢＭＦＦファイル内の動画フラグメントを完全なものにする際の遅延を除去するか、または、少なくとも低減する。

さらに、本出願において記載されているセグメント化メカニズムは、例えば、リソース検証および／または機密性などの、セキュリティモデルを改善するために使用することができる。例えば、記載されているセキュリティモデルは、複数のプロバイダから抽出することができる複数のフラグメントにリソースをセグメント化するときに、特に有利である。本出願において記載されているセキュリティモデルは、複数のフラグメントにリソースをセグメント化するときの用途の必要性に適した種々のインテグリティメカニズムの柔軟な使用を可能にする。例えば、ライブビデオストリーミングの事例について、柔軟なレコードサイズを取り扱う、鍵付きのまたはシグネチャベースのインテグリティメカニズムが有利である。そのようなメカニズムは、個々のチャンクがインテグリティを保護されることを可能にし、配信されるデータが、直ちに正当であると検証され、追加の遅延なしに消費されることを可能にする。

例示的な実施形態によるシステムを示す図である。 一実施形態による方法を示す図である。 一実施形態による方法を示す図である。 一実施形態による方法を示す図である。 一実施形態による方法を示す図である。 一実施形態による方法を示す図である。 一実施形態による方法を示す図である。 一実施形態による方法を示す図である。 本発明の例示的な実施形態によるクライアント－サーバ対話を示す図である。 本発明の例示的な実施形態によるクライアント－サーバ対話を示す図である。 本発明の例示的な実施形態による例示的なシーケンスを示す図である。 本発明の例示的な実施形態によるＩＳＯＢＭＦＦメディアセグメントの例示的なフラグメント化を示す図である。 いくつかの実施形態による装置のブロック図である。

本明細書において使用される場合、「１つの（ａ）」は、別途指示しない限り、「１つまたは複数の」を意味するように解釈されるべきである。

本出願は、リソース（例えば、ＨＴＴＰ、ＦＬＵＴＥ、またはＦＣＡＳＴのようなファイル配信プロトコルを使用してサーバからクライアントに配信されるように意図されているリソース）をセグメント化するための例示的な実施形態を記載している。実施形態は、セグメント化リソースのフォーマット、リソースセグメント化を実施するための方法およびデバイス、ならびに／または、セグメント化リソースを受信／伝送するための方法およびデバイスに関する。

セグメント化のための例示的なソリューションは、クライアントに、所与のリソースのセグメント化マップを提供することに基づく。いくつかの実施形態において、クライアントは、具体的には、セグメント化マップまたは所与のリソースをサーバから要求してもよい。図１に示すように、クライアント１０２は、サーバ１０４と通信している。いくつかの実施形態において、サーバ１０４は、従来のサーバであってもよく、他の実施形態においては、ピアツーピアネットワーク内のピアクライアントであってもよい。

所与のリソースは、配信または用途の必要性に適した任意の数のフラグメントにセグメント化される。セグメント化マップは、個々のフラグメントに関するより多くの情報が決定されるときに、所与のリソースについて更新することができる。すなわち、セグメント化マップは、リソースの個々のフラグメントに関する完全な情報を有する前に（すなわち、リソースが完全に指定される前に）作成され得る。

例示的な実施形態によれば、セグメント化マップは、以下の記載される特徴の何らかの組み合わせを有する。

セグメント化マップは、個々のフラグメントを組み立てる順序を、明示的に（例えば、インデックスまたはシーケンス識別子によって）または黙示的に（例えば、セグメント化マップの全部または一部を実装するデータ構造によって課される順序によって）のいずれかで指示する。

各フラグメントは、セグメント化マップが作成される（セグメント化マップになされる任意の更新を含む）時点において既知または未知のいずれかの長さを有する。したがって、各フラグメントについて、セグメント化マップは、マップが作成される時点において長さが分かっている場合に、フラグメントの長さ（例えば、ビット単位）を指示することができる。長さが分からない場合、ファイル配信プロトコルは、例えば、ＨＴＴＰチャンク化を使用することによって、または、フラグメントがサーバによってクライアントに完全に配信されたときに接続を閉じることによって、フラグメントの最終的な長さを指示することが可能でなければならない。

各フラグメントは、セグメント化マップ作成の時点において、リソース全体に対する既知または未知のいずれかの位置（例えば、オフセット）を有する。したがって、各フラグメントについて、セグメント化マップは、フラグメントのオフセットを指示することができる。位置が分からない場合、クライアントまたは復号手段は、セグメント化マップを受信した後に（例えば、先行するフラグメントの終端部の位置が判定されたときに、または、所与のフラグメントの位置を含む更新されたセグメント化マップを受信することによって）位置を判定することができる。フラグメントの位置を知らないことの１つの欠点は、そのことによって、追加の移動またはコピー動作がもたらされる場合があることである（ただし、後述するように、メモリの制約されたクライアントは、セグメント化マップ内で提供される依存性情報に基づいて、そのような移動またはコピーを最小限に抑えるためにフラグメントの抽出を順序付けることができる）。

各フラグメントは、例えば、ＨＴＴＰ ＵＲＬなどのファイル抽出プロトコル、または、ＵＲＬとそのＵＲＬに対するオフセットとの組み合わせによって使用されることになる、フラグメント自体の識別子（例えば、位置指定子、名前など）を有する。したがって、各フラグメントについて、セグメント化マップは、フラグメントの識別子を指示することができる。これによって、個々のフラグメントをそれ自体のリソースとして抽出するためにＯＯＢのようなメカニズムを使用するか、または、様々な理由で複数の異なるサーバを使用する柔軟性が可能になる。抽出領域における、または、コンテンツ処理の理由でのいずれかの負荷平衡が、負荷分散に起因する性能改善をもたらすことができる。各フラグメントに位置指定子を使用することによって、また、ＵＲＬレベルでの、または、代替サービスのようなメカニズムを使用した、別の配信または抽出プロトコルへのリダイレクトも可能になる（例えば、［ａｌｔ－ｓｅｒｖｉｃｅｓ］参照）。

各フラグメントは、機密性およびインテグリティ検証のための個々のセキュリティメカニズムを有する可能性がある。したがって、各フラグメントについて、セグメント化マップは、フラグメントと関連付けられるセキュリティ動作を実施するために要求される情報を含むことができる。この情報は、フラグメントのデータに対するハッシュであってもよく、または、いずれの証明書もしくは鍵がハッシュもしくはシグネチャを生成するために使用されているかを指示してもよい。

各フラグメントについて、セグメント化マップは、最適な性能のためにフラグメントをいずれの順序において抽出するべきかをクライアントに指示する抽出ヒントまたは依存性情報を含むことができる。１つのそのような最適化は、配信が完了するまでの遅延を最小限に抑えることである。別のヒントは、特定のフラグメントが、１つまたはいくつかの他のフラグメントがすでに配信に成功した後に配信されるべきであることを指示し得る。

各フラグメントについて、セグメント化マップは、受信クライアントが、リソース全体ではなく、完全に配信される前にまたは独力でフラグメントを利用することを可能にする、リソースメディアタイプと関連付けられるアプリケーションレベルヒントを含むことができる。

セグメント化マップはまた、リソースレベル特性をも有することができる。例えば、セグメント化マップの更新が適切な時点で行われることを保証するために、セグメント化マップは、配信および再組み立て過程における特定のステップに達したときに、更新されたセグメント化マップが要求され得るというヒントを含むことができる。

ここで図１を参照すると、クライアント１０２は、サーバ１０４と通信することができる。本明細書において使用される場合、「サーバ」は、サービスを提供する単一のコンピュータまたはサービスを提供する複数のコンピュータから成るセットであってもよく、コンピュータのセットは同じ場所にあってもよく（例えば、コンピュータのクラスタ）、または、地理的に散在していてもよい。クライアント１０２は、受信手段２０２と復号手段２０４とを備えることができる。受信手段２０２は、クライアント１０２が、サーバ１０４からデータを受信することを可能にする回路を含む（例えば、ＲＦ受信手段またはＥｔｈｅｒｎｅｔインターフェースのような、有線または無線リンク）。復号手段２０４は、様々なメディアファイルフォーマットを復号するように動作可能である。サーバ１０４は、ソースフィード３０２と、符号化手段３０４と、パケタイザ３０６と、セグメンタ３０８とを備えることができる。ソースフィード３０２は、ライブデータのようなメディアデータが（例えば、ケーブルフィード、衛星フィード、または他のソースから）生成されているときに、メディアデータを、または、すでに生成されており、サーバ１０４もしくは他の場所に記憶されているデータをサーバ１０４に提供することができる。符号化手段３０４は、例えば、Ｈ．２６４またはＭＰＥＧ－４アドバンスドビデオコーディング（ＡＶＣ）を使用して、ソースフィード３０２から受信されるメディアデータを様々なメディアサンプルに符号化するように動作可能である。パケタイザ３０６は、メディアサンプルを取り、それらのメディアサンプルを、ＨＴＴＰのようなパケットベースのプロトコルを介して送信するのに適したパケット化フォーマットにするように動作可能である（例えば、パケタイザ３０６は、例えば、メディアサンプルを包含するｍｄａｔボックスを有するメディアセグメントを作成することによって、メディアサンプルをＩＳＯベースメディアファイルフォーマットにすることができる）。セグメンタ３０８は、パケット化メディアを取り、そのパケット化メディアをセグメント化フォーマットにするか、または、パケット化メディアをセグメント化フォーマットにおいて配信する（例えば、セグメント化マップに従ってパケット化メディアを配信する）ように動作可能である。

図２は、セグメント化マップを生成および受信するための、例示的な実施形態による方法を図解する。いくつかの実施形態において、方法は、第１のフラグメントおよび第２のフラグメントを含むフラグメントの順序付けされたセットを含む、メディアセグメントのセグメント化マップを生成することを含む（ステップ２０２ａ）。一実施形態において、サーバ１０４が、セグメント化マップを生成するステップを実施する。いくつかの実施形態において、方法は、第１のフラグメントおよび第２のフラグメントを含むフラグメントの順序付けされたセットを含む、メディアセグメントのセグメント化マップを受信することを含む（ステップ２０２ｂ）。一実施形態において、クライアント１０２が、セグメント化マップを受信するステップを実施する。

図３は、動的に生成されるメディアストリームを配信（または受信）するための例示的な実施形態を図解する。例えば、いくつかの実施形態において、動的に生成されるメディアストリームは、ライブテレビフィードのような、ライブデータソースを表す。いくつかの実施形態において、方法は、ＨＴＴＰを使用して、インターネットを介して行うことができ、クライアント１０２とサーバ１０４の両方が、インターネット対応デバイスであってもよい。１つの実施形態によれば、動的に生成されるメディアストリームをクライアントに配信するための方法であって、メディアストリームは、第１のメディアセグメントおよび第２のメディアセグメントを含む複数のメディアセグメントを含む、方法が提供される。方法は、クライアントから、マニフェストファイルを求める要求を受信することを含む（ステップ３０２）。いくつかの実施形態において、マニフェストファイルは、クライアントが、メディアセグメントを求める要求を生成することを可能にするための情報を含む。方法は、マニフェストファイルを求める要求の受信に応答して、クライアントに、マニフェストファイルを送信することをさらに含む（ステップ３０４）。方法は、マニフェストファイルをクライアントに送った後に、クライアントから、第１のメディアセグメントを識別する要求を受信することをさらに含む（ステップ３０６）。いくつかの実施形態において、第１のメディアセグメントを識別する要求は、クライアントによって、クライアントがマニフェストファイルを処理する結果として伝送されたものである。いくつかの実施形態において、サーバが、完全なメディアセグメントをクライアントに提供することが可能になる前に（例えば、サーバはｍｏｏｆおよびｍｄａｔボックスの生成を完了していない）、要求がクライアントによって伝送される。

方法は、第１のメディアセグメントを識別する要求に応答して、クライアントに、第１のメディアセグメントのセグメント化マップを送信することをさらに含む（ステップ３０８）。いくつかの実施形態において、第１のメディアセグメントは、第１のフラグメント（例えば、ｍｏｏｆボックス）および第２のフラグメント（例えば、ｍｄａｔボックス）を含むフラグメントの順序付けされたセットを含み、セグメント化マップは、サーバから第１のフラグメントを抽出するのに使用するための第１のフラグメント識別子を含む第１のフラグメントメタデータと、サーバから第２のフラグメントを抽出するのに使用するための第２のフラグメント識別子を含む第２のフラグメントメタデータと、第１のフラグメントが第２のフラグメントの前に順序付けされていることを指示する情報を含む、フラグメントのセット内のフラグメントの順序付けを識別する順序付け情報とを含む。

図４は、動的に生成されるメディアストリームを受信するための例示的な実施形態を図解し、メディアストリームは、第１のメディアセグメントおよび第２のメディアセグメントを含む複数のメディアセグメントを含む。方法は、サーバに、マニフェストファイルを求める要求を送信することを含む（ステップ４０２）。いくつかの実施形態において、マニフェストファイルは、クライアントが、メディアセグメントを求める要求を生成することを可能にするための情報を含む。方法は、マニフェストファイルを受信することをさらに含む（ステップ４０４）。方法は、受信されているマニフェストファイルを処理することをさらに含む（ステップ４０６）。方法は、マニフェストファイルを処理した後に、サーバに、第１のメディアセグメントを識別する要求を送信することをさらに含む（ステップ４０８）。方法は、第１のメディアセグメントを識別する要求が送信されたことに応答して、第１のメディアセグメントのセグメント化マップを受信することをさらに含む（ステップ４１０）。いくつかの実施形態において、第１のメディアセグメントは、第１のフラグメントおよび第２のフラグメントを含むフラグメントの順序付けされたセットを含み、セグメント化マップは、第１のサーバから第１のフラグメントを抽出するのに使用するための第１のフラグメント識別子を含む第１のフラグメントメタデータと、サーバから第２のフラグメントを抽出するのに使用するための第２のフラグメント識別子を含む第２のフラグメントメタデータと、第１のフラグメントが第２のフラグメントの前に順序付けされていることを指示する情報を含む、フラグメントのセット内のフラグメントの順序付けを識別する順序付け情報とを含む。方法は、サーバに、第１のフラグメントを求める要求を送信することをさらに含む（ステップ４１２）。方法は、第１のフラグメントを受信することをさらに含む（ステップ４１４）。

図５は、動的に生成されるメディアストリームを配信するための追加の例示的な実施形態を図解する。例えば、いくつかの実施形態において、クライアント１０２は、第１のメディアセグメントを求める要求（または任意の他の要求）内に、クライアントがセグメント化モードをサポートしていることの指標を含めることができる。いくつかの実施形態において、動的に生成されるメディアストリームをクライアントに配信するための方法は、指標に少なくとも部分的に基づいて、メディアセグメントを配信するためにセグメント化モードを使用することを決定することをさらに含む（ステップ５０２）。例えば、クライアントがセグメント化モードをサポートしない場合、サーバ１０４は、セグメント化モードを使用しなくてもよく、それゆえ、セグメント化マップをクライアントに送信されない。いくつかの実施形態において、メディアセグメントを配信するためにセグメント化モードを使用することの決定は、第１のメディアセグメントが完全に生成されたか否かにさらに依存する。例えば、第１のメディアセグメントが完全に生成されている場合、サーバ１０４は、第１のメディアセグメントを配信するために、従来のファイルストリーミング技法を使用することができる。他方、第１のメディアセグメントが完全に生成されていない場合、サーバ１０４は、第１のメディアセグメントを配信するために、セグメント化モードを使用することを決定することができる。

本発明の実施形態は、配信の準備ができるように、ソースから受信されるメディアを処理または準備するための複数の方法をサポートする。例えば、いくつかの実施形態において、方法は、メディアストリームを動的に生成するソースから第１のメディアセグメントの一部を受信することをさらに含むことができる（ステップ５０４）。一実施形態において、第１のメディアセグメントの上記部分は、ソースフィード３０２を介して受信される。いくつかの実施形態において、第１のメディアセグメントの上記部分は、メディアサンプルおよびメディアアプリケーションデータユニット（ＡＤＵ）のうちの少なくとも１つに対応する（例えば、第１のメディアセグメントの上記部分は、メディアフレーム（すなわち、オーディオフレームおよび／またはビデオフレーム）を包含し得る）。いくつかの実施形態において、受信される第１のメディアセグメントの上記部分は、例えば、Ｈ．２６４またはＭＰＥＧ－４アドバンスドビデオコーディング（ＡＶＣ）のようなオーディオまたはビデオフォーマットにおいて符号化される。他の実施形態において、方法は、第１のメディアセグメントを符号化することをさらに含むことができる（ステップ５０６）。例えば、符号化は、第１のメディアセグメントの上記部分を、Ｈ．２６４またはＭＰＥＧ－４アドバンスドビデオコーディング（ＡＶＣ）のようなオーディオまたはビデオフォーマットに変換することができる。一実施形態において、符号化手段３０４がこのステップを実施する。方法は、フォーマットに従って第１のメディアセグメントの上記部分をパケット化することをさらに含むことができる（ステップ５０８）。例えば、フォーマットは、ＩＳＯベースメディアファイルフォーマット（ＩＳＯＢＭＦＦ）であってもよい。一実施形態において、パケタイザ３０６がこのステップを実施する。方法は、第１のメディアセグメントをセグメント化し、第１のメディアセグメントのセグメント化マップを生成することをさらに含むことができる（ステップ５１０）。例えば、セグメント化マップは、本出願において開示されている例示的なセグメント化マップの１つまたは複数の特性を有することができる。一実施形態において、セグメンタ３０８がこのステップを実施する。いくつかの実施形態において、第１のメディアセグメントのセグメント化マップの生成は、上記フォーマットにおける第１のメディアセグメントのパケット化部分に基づく。

いくつかの実施形態において、方法は、新たな情報に基づいてセグメント化マップを更新し、更新されているマップをクライアントに送信することをさらに含む（ステップ５１２）。例えば、セグメント化マップを最初に作成する時点において、一定の情報（メディアセグメント内の個々のフラグメントの長さまたは位置情報など）が分からない場合がある。メディアセグメントまたはメディアセグメント内の特定のフラグメントの符号化およびパケット化が完了すると、サーバ１０４は、その時点の新たな情報（例えば、長さまたは位置情報）によってセグメント化マップを更新することができる。方法は、クライアントから、第１のフラグメントを識別する要求を受信すること（ステップ５１４）と、第１のフラグメントを識別する要求を受信することに応答して、クライアントに、第１のフラグメントを送信すること（例えば、第１のフラグメントは、ＨＴＴＰチャンク化を使用してクライアントに送信することができる）（ステップ５１６）とをさらに含むことができる。

図６は、動的に生成されるメディアストリームを受信するための追加の例示的な実施形態を図解する。いくつかの実施形態において、動的に生成されるメディアストリームを受信するための方法は、サーバに、第２のフラグメントを求める要求を送信することをさらに含むことができる（ステップ６０２）。方法は、クライアントによって、第１のフラグメントと同時に第２のフラグメントを受信することをさらに含むことができる（ステップ６０４）。いくつかの実施形態において、クライアントは、クライアントがメディアセグメントのすべてのフラグメントを受信するまで、フラグメントを求める要求を送信することと、対応するフラグメントを受信することとを継続することができる。方法は、第１のフラグメントを復号し、再生することをさらに含むことができる（ステップ６０６）。いくつかの実施形態において、第１のフラグメントを復号し、再生することは、クライアントが第１のメディアセグメントの第３のフラグメントを受信する前に行われる。方法は、第１のフラグメントを検証することをさらに含むことができる（ステップ６０８）。方法は、第１のメディアセグメントを検証することをさらに含むことができる（ステップ６１０）。いくつかの実施形態において、第１のフラグメントを復号し、再生することは、第１のフラグメントを検証した後で、かつ、第１のメディアセグメントを検証する前に行われる。

本発明の実施形態は、複数の異なる配信メカニズムに適用可能である。例えば、いくつかの実施形態において、クライアントは、サーバからのデータ（例えば、メディアセグメントのフラグメントを含む）を能動的に要求、または、引き出すことができる。他の実施形態において、クライアントは受動的であってもよく、いくつかの他のエンティティがクライアントに対するデータ（例えば、メディアセグメントのフラグメントを含む）をプッシュしてもよい。

図７は、メディアストリームを配信するための例示的な実施形態を図解する。１つの実施形態によれば、メディアセグメントをクライアントに配信するための方法が提供される。方法は、フラグメントのシーケンスにセグメント化されているメディアセグメントのセグメント化マップを生成することを含む（ステップ７０８）。方法は、セグメント化マップをクライアントに送信することをさらに含む（ステップ７１０）。いくつかの実施形態において、方法は、サーバによって、メディアセグメントを受信することをさらに含むことができる（ステップ７０２）。例えば、サーバは、ソースフィード３０２を介してメディアセグメントを受信し、符号化手段３０４、パケタイザ３０６、およびセグメンタ３０８のうちの１つまたは複数にセグメントを渡すことができる。方法は、メディアセグメントを、第１のフラグメントおよび第２のフラグメントを含むフラグメントのシーケンスにセグメント化することをさらに含むことができる（ステップ７０４）。例えば、そのようなセグメント化は、セグメンタ３０８によって行うことができる。方法は、クライアントから、メディアセグメントを求める第１の要求を受信することをさらに含むことができる（ステップ７０６）。方法は、クライアントから、第１のフラグメントを求める第２の要求を受信することをさらに含むことができる（ステップ７１２）。方法は、クライアントに、第１のフラグメントを送信することをさらに含むことができる（ステップ７１４）。方法は、新たな情報に基づいてセグメント化マップを更新し、更新されているマップをクライアントに送信することをさらに含むことができる（ステップ７１６）。例えば、いくつかの実施形態において、新たな情報は、複数のフラグメントのうちの１つの長さ、メディアセグメント内の当該フラグメントの開始位置、および、メディアセグメント内の当該フラグメントの終端位置のうちの１つまたは複数を含む。いくつかの実施形態において、セグメント化マップを更新することおよび更新されているマップをクライアントへ送信することの一方または両方は、クライアントが更新されているセグメント化マップを要求するのに応答して実施されてもよい。いくつかの実施形態において、サーバは、クライアントに、セカンダリサーバ（例えば、異なる信頼ドメイン内の帯域外サーバ）からフラグメントを要求するように指示してもよい。いくつかの実施形態において、セグメント化マップは、特定のフラグメントについてクライアントをセカンダリサーバへと誘導する情報を含む。

図８は、メディアセグメントを復号するための、例示的な実施形態による方法を図解する。方法は、クライアントによって、メディアセグメントを求める要求を送信することを含む（ステップ８０２）。方法は、クライアントによって、フラグメントのシーケンスにセグメント化されているメディアセグメントのセグメント化マップを受信することをさらに含む（ステップ８０４）。いくつかの実施形態において、方法は、クライアントによって、第１のフラグメントを受信することをさらに含むことができる（ステップ８０６）。方法は、クライアントによって、第１のフラグメントを受信することをさらに含むことができる（ステップ８０８）。方法は、クライアントによって、第１のフラグメントを再生することをさらに含むことができる（ステップ８１０）。方法は、第１のフラグメントのインテグリティを検証することをさらに含むことができる（ステップ８１２）。方法は、メディアセグメントのインテグリティを検証することをさらに含むことができる（ステップ８１４）。方法は、更新されているセグメント化マップを受信することをさらに含むことができる（ステップ８１６）。いくつかの実施形態において、他の複数のフラグメントの各々について、方法は、そのようなフラグメントを要求すること、受信すること、および再生することをさらに含むことができる。いくつかの実施形態において、メディアセグメントの任意のフラグメントを再生する前に、クライアントは、最初に、そのようなフラグメントのインテグリティを検証し、クライアントがそのようなフラグメントのインテグリティを肯定的に検証した場合にのみ、そのようなフラグメントを再生する。いくつかの実施形態において、クライアントは、フラグメントのシーケンスに対応する論理的順序付けとは異なる順序において、フラグメントを求める要求を順序付けしてもよい。いくつかの実施形態において、フラグメントを求める要求が行われる順序は、少なくとも部分的に、各フラグメントに関するサイズ依存性およびコンテンツ依存性情報のような、依存性情報に依存する。いくつかの実施形態において、クライアントは、異なるフラグメントを求める要求を並列に行うことができる。いくつかの実施形態において、フラグメントは、複数の異なるサーバから受信されてもよく、いくつかの実施形態において、フラグメントを求める要求は、複数の異なるサーバに送信されてもよい。

ここで図９を参照すると、クライアント１０２は、要求仲介手段９０２と通信することもできる。要求仲介手段９０２は、クライアント１０２の一部であってもよく（例えば、クライアント１０２は、クライアント１０２の要求仲介手段構成要素と通信する、ビデオプレーヤのようなアプリを実行することができる）、または、要求仲介手段９０２は、クライアント１０２の近くに配置されてもよく、または、サーバ１０４の一部であってもよく、または、サーバ１０４の近くに配置されてもよく、または、クライアント１０２もしくはサーバ１０４のいずれかから分離して独立していてもよい。セグメント化マップをサーバ１０４から受信した後、クライアント１０２（例えば、アプリ）は、様々なメディアフラグメントを求める一連の要求を送信することができる。セグメント化マップは、いくつかのフラグメントが他のフラグメントに対する依存性を有することを指示することができる。これは、例えば、１つのフラグメントが抽出され得る前に、別のフラグメントがまず抽出されなければならないことを意味し得る。要求仲介手段９０２の役割は、この依存性情報を取り扱うことである。したがって、クライアント１０２（例えば、アプリ）は、フラグメント要求を仲介手段９０２に送信することができ、仲介手段９０２は、その後、セグメント化マップ内に含まれる依存性情報に基づいて、適切な時点において、要求をサーバ１０４に転送することができる。これは、例えば、仲介手段９０２が直ちに要求をサーバ１０４に転送することを意味し得るか（例えば、依存性がない場合）、条件が満たされる（例えば、何らかの依存性が解決される）まで、仲介手段９０２が要求をハングまたはブロックさせることを意味し得る。要求仲介手段９０２はまた、仲介手段がフラグメント優先度または他のフラグメントメタデータに基づいて要求を仲介することを可能にするための論理をも包含することができる。

ここで図１０を参照すると、クライアント１０２は、複数のセカンダリサーバ１００２と通信することもできる。したがって、サーバ１０４からすべてのメディアフラグメントを受信するのではなく、クライアント１０２は、複数の異なるセカンダリサーバ１００２のうちの１つまたは複数から１つまたは複数のフラグメントを受信することができる。いくつかの実施形態によれば、クライアント１０２は、最初に、サーバ１０４からフラグメントを要求するが、要求はその後、セカンダリサーバ１００２のうちの１つにリダイレクトされる。いくつかの実施形態によれば、クライアント１０２は、最初に、例えば、セグメント化マップ内に包含される情報に基づいて、セカンダリサーバ１００２のうちの１つから直接的にフラグメントを要求する（例えば、フラグメント位置指定子が、セカンダリサーバを指すことができる）。いくつかの実施形態によれば、要求仲介手段９０２は、セカンダリサーバのうちの１つに要求を誘導する。例えば、要求仲介手段９０２は、負荷平衡手段として作用することができ、他のサーバに送信される要求の量および利用可能な帯域幅のような複数の要因に基づいて、または、地理的考慮事項に基づいて、セカンダリサーバに要求を誘導する決定を行うことができる。

サーバ１０４、および、セカンダリサーバ１００２のうちの１つまたは複数は、異なる信頼ドメイン（例えば、図１０に示す３つの信頼ドメイン１００４、１００６、１００８のうちの１つ）の中に存在することが可能である。このことは、同一オリジンポリシを暗示し得、そのリソースにアクセスする前にリソースのインテグリティを検証することを所望するクライアントがあるという含意を有する。本発明の実施形態は、これを完全にサポートし、クライアントが、下記により十分に説明するように、複数の異なる信頼ドメインにわたってインテグリティを検証することを可能にする。

（単純にするために）図面には完全には示されていないが、いくつかの実施形態において、クライアント１０２、サーバ１０４、要求仲介手段９０２、およびセカンダリサーバ１００２の各々は、互いに通信することが可能である（例えば、サーバ１０４は、セカンダリサーバ１００２の各々と通信することができ、逆も可能である）。サーバ１０４の責務は、１つまたは複数のセカンダリサーバ１００２の間で分散させることができることにも留意されたい。これは、例えば、メディアリソースを符号化するサーバ、セグメント化マップを生成するサーバ、クライアント要求を仲介するサーバ、メディアリソースフラグメントをクライアントにサービスする１つまたは複数のサーバが、各々、異なるサーバであってもよいことを意味する。

機密性およびインテグリティソリューション

セグメント化マップは、機密性およびインテグリティメカニズムが採用されるか否かにかかわらず、利点を提供する。しかしながら、そのようなメカニズムが採用される場合、セグメント化マップは、現行の技術水準にまさる追加の利点を提供する。

典型的には、リソース全体のインテグリティは、複数の方法で判定することができる。最も基本的な方法は、リソースがクライアント内で完全に受信されたときに、リソースを検証することである。そのようなソリューションの最も基本的なものは、単純にリソース全体に対するハッシュ値を計算し、リソースについて信頼できるドメインからの安全確保された配信を仮定して、セグメント化マップ内にそのハッシュ値を含めることである。ＨＴＴＰのためのコンテンツ－シグネチャヘッダフィールド（Ｃｏｎｔｅｎｔ－Ｓｉｇｎａｔｕｒｅ Ｈｅａｄｅｒ Ｆｉｅｌｄ ｆｏｒ ＨＴＴＰ）（例えば、［ＣＯＮＴＥＮＴＳＩＧ］参照）またはマークルインテグリティコンテンツ符号化（例えば、［ＭＩＣＥ］参照）のような、このためのいくつかのソリューションが存在する。しかしながら、クライアントが漸進的に消費することを所望し得るリソースのセグメント化にこれらの手法を使用することには、明確なマイナス面がある。クライアントまたはアプリケーションは、そのような手法のために、検証されていないデータを使用することを回避することを所望する場合にはリソース全体が配信されるまで待たなければならない。無論、検証されていないデータを使用することが許容可能であれば、代替形態は、データを消費し、その後、後にリソースが検証に失敗した場合にはユーザに警告するか、または、他の様態で取り扱うことである。この手法は、検証されておらず、それゆえ信頼できないデータに依存するため、危険であり、推奨できない可能性がある。

検証についてのそのような手法による別の問題は、リソース全体の検証が、リソースが正当に検証されないことを指示する場合に、クライアントが、いずれのフラグメントによって検証が失敗させられたかを判定することができないことである。この問題を解決するために、個々のリソースフラグメントは、それら自体のインテグリティ検証情報を必要とする。これは、各フラグメントを配信プロトコルレベルにおいてそれ自体のリソースとして処理し、セグメント化マップに、インテグリティ検証メカニズムと関連付けられる任意のパラメータとともに、各フラグメントに使用されるインテグリティ検証メカニズムを指示させることによって、達成することができる。

リソースフラグメントを漸進的に消費するときに検証を可能にするために、リソースフラグメントの適切なチャンクが配信されるときに、当該チャンクに対してインテグリティソリューションが提供される必要がある。そのようなソリューションは好ましくは、各チャンク内で提供されるデータの量が固定レコードサイズと整合しないときにブロック問題を回避するために、レコードサイズに関して柔軟であるべきである。ビデオのようなメディアストリームについて、単一のメディアサンプル（例えば、符号化ビデオフレーム）が、保護するのに適したチャンクである。ＭＩＣＥは、準備されているデータにとって、および、リソースセグメントの配信を開始する前に全ＤＡＳＨセグメントが利用可能である場合に（すなわち、メディアストリームが動的に生成されない場合に）有用であり得る。固定レコードサイズ（ＭＩＣＥによって課される）は、その設定では、各配信チャンク内で全レコードを配信することによって対処され得る。

しかしながら、ライブまたは動的に生成されるコンテンツについて、特定のチャンクの伝送を準備する時点において次のメディアサンプルが利用可能でない場合、上記の手法は良好に機能しない。代わりに、別の手法は、個々のチャンク（メディアセグメント全体の代わりに）をハッシュし、各レコードに結果もたらされるハッシュを含めることである。ハッシュに対するシグネチャ、または鍵付きハッシュを使用したシグネチャの両方を使用して、ハッシュを、セグメント化マップの提供者によって信頼されるソースに由来するものとして、クライアント内で検証可能にすることができる。このソリューションは、インテグリティメカニズムおよびデータを保護するためのその構造に起因するいかなる大幅な遅延を加えることを回避する。

データインテグリティ（そのデータが信頼できるか）は、セキュリティの１つの重要な態様である。別の態様は、機密性（データを認可されていないパーティから秘匿されたままにすること）である。

本発明の実施形態は、リソースの送達が複数のエンティティ（例えば、エッジサーバまたはユーザに近いキャッシュ）にわたって分散されることを可能にする。しかし、所与のメディアリソースの複数の異なるフラグメントを作り出し、配信する可能性があり得る複数のエンティティを有することによって、機密性に関していくらかの複雑性が提示される。セキュリティの理由から、異なるエンティティはセキュリティコンテキストを共有することができない。したがって、セグメント化マップは、鍵のような、リソースフラグメント特有のセキュリティコンテキスト情報を指示する必要があり得る。

漸進的に消費されるリソースフラグメントの機密性の別の態様は、フラグメントをその開始点から解読することができるとともに、チャンクレベルにおけるデータを解読することができることを保証することである。これによって、場合によっては、暗号化アルゴリズムがチャンク境界において解読を実施することができることを保証するために、暗号化層パディングが必要になり得る。

異なる信頼ドメインの利用

個々のリソースフラグメントに汎用の位置指定子を利用することによって、特定のリソースフラグメントを任意のロケーションから抽出することが可能であり得る。すなわち、１つのフラグメントの抽出点が、別のフラグメントの抽出点に依存しないことが可能である。したがって、異なるフラグメントを異なる信頼ドメイン（例えば、場合によっては異なるドメイン名システム（ＤＮＳ）名を有する異なるホスト）から抽出することができる。リソースセグメントはまた、リソースフラグメントのメインドメインが、そのドメインの順番において、フラグメントのコンテンツを抽出することができる１つまたは複数の二次リソースを指すことを可能にする、ＯＯＢコンテンツ符号化を使用して提供することもできる。

これら２つのソリューションは、複数のＯＯＢ二次リソースを有する結合セグメント化マップに統合することが可能であり得、または、２つのソリューションを、適切な組み合わせにおいて相次いで適用することができる。

任意のリソースロケーションを指すための、セグメント化マップとＯＯＢ符号化ソリューションの両方によって生み出される可能性は、様々な含意を有する。例えば、ＨＴＴＰにおいて、この可能性は、同一オリジンポリシ（例えば、［ＲＦＣ６４５４］参照）に影響を与え得、リソース全体のドメイン（メインドメイン）の制御外のリソースの装荷を可能にする。この結果を回避するために、適切なセキュリティモデルを適用することができる。１つの可能性は、メインドメイン（すなわち、セグメント化マップを提供する）が、二次ドメインから抽出されるセグメントのインテグリティを検証する方法を提供すること、すなわち、二次ドメインから抽出されるものがメインドメインに従って意図されるものに一致することである。これは、セグメント化マップ内にフラグメントのハッシュを含めることによって最も容易に実現される。別の可能性（メインドメインが二次ドメインを信頼することに基づく）は、メインドメインが二次ドメインにおいて有する信頼をメインドメインが指示するための何らかの方法を有することである。例えば、メインドメインは、セグメント化マップ内で、二次ドメインがリソースフラグメントのインテグリティを証明するためにいずれの鍵または証明書を使用することになるかを指示することによって、信頼を指示する。

セグメント化マップの例示的な実施形態

上述した特性のほとんどまたはすべてを満たすセグメント化マップの多くの異なる形態およびフォーマットが存在する。ＨＴＴＰ１．１とともに使用することができるセグメント化マップの１つの可能性のある実施形態を、下記に提供する。

この例において、クライアントは、ＨＴＴＰ１．１を使用して位置指定子（例えば、ＵＲＬ）「ｈｔｔｐｓ：／／ｅｘａｍｐｌｅ．ｏｒｇ／ｘｙｚ／ｓｅｇ－２－１４．ｍｐ４」においてリソース（この例ではフラグメント化されたＭＰＥＧ－４（ｍｐ４）メディアセグメント）を要求する。クライアントは、セグメント化メカニズムをサポートしていることを指示するために、「セグメント化されている」と呼ばれるコンテンツ符号化をサポートしていることを指示する。サーバもまた、応答においてセグメント化メカニズムをサポートおよび利用する。応答は、セグメント化コンテンツ符号化の使用の指示を含み、本文は、フラグメントを記述するＪＳＯＮ符号化セグメント化マップを含む。この事例において、第１の要求が、リソース全体が構築される前に到来する。

ＨＴＴＰ要求は以下のとおりである。
ＧＥＴ ／ｘｙｚ／ｓｅｇ－２－１４．ｍｐ４ ＨＴＴＰ／１．１
Ｈｏｓｔ： ｅｘａｍｐｌｅ．ｏｒｇ
Ａｃｃｅｐｔ－Ｅｎｃｏｄｉｎｇ： ｇｚｉｐ， ｓｅｇｍｅｎｔｅｄ
ＨＴＴＰ／１．１ ２００ ＯＫ
Ｄａｔｅ：Ｔｈｕ， ２４ Ｏｃｔｏｂｅｒ ２０１６ １６：５４：００ ＧＭＴ
Ｃｏｎｔｅｎｔ－Ｔｙｐｅ： ａｐｐｌｉｃａｔｉｏｎ／ｊｓｏｎ
Ｃａｃｈｅ－Ｃｏｎｔｒｏｌ： ｍａｘ－ａｇｅ＝１０， ｐｕｂｌｉｃ
Ｅｘｐｉｒｅｓ：Ｔｈｕ， ２４ Ｏｃｔｏｂｅｒ ２０１６ １６：５４：０３ ＧＭＴ
Ｃｏｎｔｅｎｔ－Ｅｎｃｏｄｉｎｇ： ｓｅｇｍｅｎｔｅｄ
Ｃｏｎｔｅｎｔ－Ｌｅｎｇｔｈ：ＸＹＺ
Ｖａｒｙ：Ａｃｃｅｐｔ－Ｅｎｃｏｄｉｎｇ

例示的なセグメント化マップを含む、ＨＴＴＰ要求に対する応答は、以下のとおりである。
“Ｒｅｓｏｕｒｃｅ”：“ｈｔｔｐｓ：／／ｅｘａｍｐｌｅ．ｏｒｇ／ｘｙｚ／ｓｅｇ－２－１４．ｍｐ４”，
“Ｃｏｎｔｅｎｔ－Ｔｙｐｅ”：“ｖｉｄｅｏ／ｍｐ４”
“Ｃｒｙｐｔｏ－Ｋｅｙ”：｛ｋｅｙｉｄ＝“ａ１”； ａｅｓｇｃｍ＝“ｃｓＰＪＥＸＢＹＡ５Ｕ－Ｔａｌ９ＥｄＪｉ－ｗ”｝
“Ｕｐｄａｔｅ－Ｈｉｎｔ”：｛“Ｃｏｎｔｅｎｔ－Ｄｅｐｅｎｄｅｎｃｙ”：｛［４］｝， “Ｅｘｐｉｒｅｓ”：“Ｔｈｕ， ２４ Ｏｃｔｏｂｅｒ ２０１６ １６：５４：０３ ＧＭＴ”｝
“Ｆｒａｇｍｅｎｔｓ”：｛
［
｛
“Ｆｒａｇｍｅｎｔ”：“１”，
“ＦＬ”：“ｈｔｔｐｓ：／／ｅｘａｍｐｌｅ．ｏｒｇ／ｘｙｚ／ｓｅｇ－２－１４．ｍｐ４．ｆｒａｇ１”， “ｈｔｔｐｓ：／／ｂａｃｋｕｐ．ｅｘａｍｐｌｅ．ｏｒｇ／ｘｙｚ／ｓｅｇ－２－１４．ｍｐ４．ｆｒａｇ１”
“Ｏｆｆｓｅｔ”：“０－４９３／４９４”，
“Ｓｉｚｅ－Ｄｅｐｅｎｄｅｎｃｙ”：｛｝，
“Ｃｏｎｔｅｎｔ－Ｄｅｐｅｎｄｅｎｃｙ”：｛｝，
“Ｐｒｉｏｒｉｔｙ”：“３”，
“ａｔｔｒｉｂｕｔｅｓ”：
｛
“Ｃｏｎｔｅｎｔ－Ｅｎｃｏｄｉｎｇ”：“ａｅｓｇｃｍ”
“Ｅｎｃｒｙｐｔｉｏｎ”：｛ｋｅｙｉｄ＝“ａ１”； ｓａｌｔ＝“Ｌｂ５０ｃＸｄＥＺｂＭＡｐＰｚＶＡｚＡＸＢＯ”｝
｝
｝，
｛
“Ｆｒａｇｍｅｎｔ”：２，
“ＦＬ”：“ｈｔｔｐｓ：／／ｅｘａｍｐｌｅ．ｏｒｇ／ｘｙｚ／ｓｅｇ－２－１４．ｍｐ４．ｆｒａｇ２”， “ｈｔｔｐｓ：／／ｂａｃｋｕｐ．ｅｘａｍｐｌｅ．ｏｒｇ／ｘｙｚ／ｓｅｇ－２－１４．ｍｐ４．ｆｒａｇ２”
“Ｏｆｆｓｅｔ”：“４９４－／”，
“Ｓｉｚｅ－Ｄｅｐｅｎｄｅｎｃｙ”：｛｝，
“Ｃｏｎｔｅｎｔ－Ｄｅｐｅｎｄｅｎｃｙ”：｛｝，
“Ｐｒｉｏｒｉｔｙ”：“１”，
“ａｔｔｒｉｂｕｔｅｓ”：
｛
“Ｃｏｎｔｅｎｔ－Ｅｎｃｏｄｉｎｇ”：“ａｅｓｇｃｍ”，
“Ｔｒａｎｓｆｅｒ－Ｅｎｃｏｄｉｎｇ”：“ｃｈｕｎｋｅｄ”，
“Ｅｎｃｒｙｐｔｉｏｎ”：｛ｋｅｙｉｄ＝“ａ１”； ｓａｌｔ＝“ｍＧｌｙＮｇｋｓｑＥＬｂＳｑｒＡＢ０９Ｌｓｇ”｝，
“Ｔｙｐｅ－Ｓｐｅｃｉｆｉｃ”：“ｍｏｏｆ”
｝
｝，
｛
“Ｆｒａｇｍｅｎｔ”：“３”，
“ＦＬ”：“ｈｔｔｐｓ：／／ｅｘａｍｐｌｅ．ｏｒｇ／ｘｙｚ／ｓｅｇ－２－１４．ｍｐ４．ｆｒａｇ３”， “ｈｔｔｐｓ：／／ｂａｃｋｕｐ．ｅｘａｍｐｌｅ．ｏｒｇ／ｘｙｚ／ｓｅｇ－２－１４．ｍｐ４．ｆｒａｇ３”
“Ｏｆｆｓｅｔ”：“－／１２”，
“Ｓｉｚｅ－Ｄｅｐｅｎｄｅｎｃｙ”：｛［“１”， “２”］｝
“Ｃｏｎｔｅｎｔ－Ｄｅｐｅｎｄｅｎｃｙ”：｛［“４”］｝，
“Ｐｒｉｏｒｉｔｙ”：“１”，
“ａｔｔｒｉｂｕｔｅｓ”：
｛
“Ｃｏｎｔｅｎｔ－Ｅｎｃｏｄｉｎｇ”：“ａｅｓｇｃｍ”
“Ｅｎｃｒｙｐｔｉｏｎ”：｛ｋｅｙｉｄ＝“ａ１”； ｓａｌｔ＝“３ｈＶＪ０ＧｅｕＯｚ１ｅｐｃｋＤ３ＩｓＩＯａ”｝
｝
｝，
｛
“Ｆｒａｇｍｅｎｔ”：“４”，
“ＦＬ”：“ｈｔｔｐｓ：／／ｅｘａｍｐｌｅ．ｏｒｇ／ｘｙｚ／ｓｅｇ－２－１４．ｍｐ４．ｆｒａｇ４”， “ｈｔｔｐｓ：／／ｂａｃｋｕｐ．ｅｘａｍｐｌｅ．ｏｒｇ／ｘｙｚ／ｓｅｇ－２－１４．ｍｐ４．ｆｒａｇ４”
“Ｏｆｆｓｅｔ”：“－／”，
“Ｓｉｚｅ－Ｄｅｐｅｎｄｅｎｃｙ”：｛［“３”］｝
“Ｃｏｎｔｅｎｔ－Ｄｅｐｅｎｄｅｎｃｙ”：｛｝，
“Ｐｒｉｏｒｉｔｙ”：“１”，
“ａｔｔｒｉｂｕｔｅｓ”：
｛
“Ｃｏｎｔｅｎｔ－Ｅｎｃｏｄｉｎｇ”：“ａｅｓｇｃｍ”，
“Ｔｒａｎｓｆｅｒ－Ｅｎｃｏｄｉｎｇ”：“ｃｈｕｎｋｅｄ”，
“Ｅｎｃｒｙｐｔｉｏｎ”：｛ｋｅｙｉｄ＝“ａ１”； ｓａｌｔ＝“ｈｙｎｈｐｎＨｕｊＳＱＢｂ６４ｓｗｂＱｇｌｆ”｝，
“Ｔｙｐｅ－Ｓｐｅｃｉｆｉｃ”：“ｍｄａｔ－ｓａｍｐｌｅｓ”
｝
｝
］｝

セグメント化マップは、リソースレベル特性によって開始する。リソースレベル特性は、セグメント化マップによって記述されるリソースの実際のメディアタイプを含む（“Ｃｏｎｔｅｎｔ－Ｔｙｐｅ”（コンテンツタイプ））。これはまた、リソース全体に対するハッシュのような、リソースレベルインテグリティメカニズムを含めることができる場所でもある。しかしながら、リソースはまだ完全には構築されていないため、その場所はこの例では可能ではない。しかしながら、複数の異なるリソースフラグメントを暗号化するために使用される暗号鍵が、“Ｃｒｙｐｔｏ－Ｋｅｙ”（暗号鍵）パラメータに含まれる。リソースＵＲＬ全体は、ちょうど、ＨＴＴＰ要求のコンテキスト外でセグメント化マップを取り扱うことを可能にするように含まれている。

セグメント化マップはまた、“Ｕｐｄａｔｅ－Ｈｉｎｔ”（更新ヒント）属性をも含む。この属性は、より完全な情報のためにセグメント化マップを更新することが推奨されるときを指示する。この事例においては、更新が“４”として識別されているフラグメントのコンテンツ利用可能性に依存するという意味を有する、Ｃｏｎｔｅｎｔ－Ｄｅｐｅｎｄｅｎｃｙ（コンテンツ依存性）属性が存在する。後に説明するように、この属性は、リソースコンテンツがサーバ側で分かっているとき、このセグメント化マップは、オープン範囲なしで（すなわち、開始位置および終端位置に既知の値がある）構築することができることを指示する。しかしながら、Ｃｏｎｔｅｎｔ－Ｄｅｐｅｎｄｅｎｃｙ属性は、セグメント化マップが更新され得るときを決定するためのデータを要求することを必要とする。この手法は、更新されたマップを要求する前にフラグメントが処理されることを必要とするため、別の相補的な手法は、より時間に基づいたヒントを使用することである。この例は、サーバがセグメント化マップを生成した３秒後にセグメント化マップを更新すべきであることを指示するための、ＨＴＴＰ Ｅｘｐｉｒｅｓ（ＨＴＴＰ期限切れ）ヘッダを含む。この事例において、３秒は、この時間までにリソース全体が構築されているであろうという知識に基づいて指示される。Ｅｘｐｉｒｅｓヘッダはまた、“Ｕｐｄａｔｅ－Ｈｉｎｔ”属性内のパラメータとしても含まれる。

リソースレベル属性の後に、フラグメントの順序付けされたシーケンスを記述するアレイが続く。この例において、リソース（メディアセグメント）は、論理的に４つのフラグメント、すなわち、メディアセグメントのｓｔｙｐボックスに対応する第１のフラグメント、メディアセグメントのｍｏｏｆボックスに対応する第２のフラグメント、ｍｄａｔボックスのヘッダ部分に対応する第３のフラグメント、および、ｍｄａｔボックスのペイロード部分（すなわち、メディアサンプル）に対応する第４のフラグメントにセグメント化される。

用語に関する注記：セグメント化マップは、実際のリソースデータを含む意味においては「フラグメント」を含まず、代わりに、セグメント化マップは、実際のリソースデータを得る方法に関する情報を含む、各リソースフラグメントと関連付けられるメタデータを含む。したがって、セグメント化マップ内の「第１のフラグメント」と記載されている場合、これは第１のフラグメントのメタデータ、または、セグメント化マップ内に記憶されている、第１のフラグメントと関連付けられる情報を意味する。

ここで、アレイ内の第１のフラグメント（すなわち、第１のフラグメントのメタデータ）を説明する。第１のフラグメント内の第１のメタデータ情報は、“Ｆｒａｇｍｅｎｔ”（フラグメント）パラメータ内で与えられ、“１”の値を有する、フラグメントの識別子である。この情報の後に、このフラグメントのフラグメントロケーション、すなわち、フラグメントがそれ自体のリソースとしてどこで要求され得るかについての１つまたは複数のＵＲＬのセットを提供する“ＦＬ”パラメータが続く。“Ｏｆｆｓｅｔ”（オフセット）パラメータは、リソース全体へのフラグメントのオフセット（またはリソース全体内の位置）、および、分かっている場合はフラグメントの長さを提供する。フォーマットは“ｓｔａｒｔ－ｅｎｄ／ｌｅｎｇｔｈ”（開始－終端／長さ）である。オフセットパラメータのこれらの値部分のいずれか、すなわち、開始位置、終端位置、または長さは分からない（したがって、提供されない）場合がある。この第１のフラグメントは、リソース全体の始まり（ｓｔａｒｔ＝０）にあり、既知の長さ（ｌｅｎｇｔｈ＝４９４）を有する。この例では、値“０－４９３／４９４”が、開始バイト、終端バイト、およびバイト単位の長さを提供する。

第１のフラグメントの次のパラメータは、“Ｓｉｚｅ－Ｄｅｐｅｎｄｅｎｃｙ”（サイズ依存性）および“Ｃｏｎｔｅｎｔ－Ｄｅｐｅｎｄｅｎｃｙ”である。これらのパラメータは、フラグメントの識別子をリストすることによって、他のフラグメントに対してどのような依存性が存在するかを表現することができる。サイズ依存性パラメータは、所与のフラグメントの開始位置を判定するために、クライアントがいずれの他のフラグメントのサイズ情報（開始および終端位置、長さ）を要求するかを識別する、フラグメント識別子のセットである。コンテンツ依存性パラメータは、所与のフラグメントを受信するために、クライアントがいずれの他のフラグメントを要求するかを識別する、フラグメント識別子のセットである。この事例において、これら両方の依存性パラメータは、空設定を含む。それゆえ、これらのパラメータは、ＨＴＴＰ応答において除外され得るが、ここでは説明の目的で含まれている。優先度パラメータは、他のフラグメントに対する関係においてこのフラグメントを要求する上での相対優先度を指示し、この例では、数が低いほどより重要となり、または、優先度がより高くなる。この情報の可能性のある使用事例は、下記にさらに説明する。

依然として第１のフラグメントのメタデータを考えると、優先度パラメータの後に、それ自体のリソースとしてのフラグメントに関係付けられる属性のセットが続く。すなわち、パラメータは、フラグメントを取得するときに使用することができる。この事例においては“ａｅｓｇｃｍ”のコンテンツ符号化が指示される。ＡＥＳ ＧＣＭ（例えば、［ａｅｓｇｃｍ］を参照）は、フラグメント全体にわたる暗号化およびインテグリティ保護メカニズムである。このコンテンツ符号化を利用するフラグメントは、フラグメント開始から終端まで暗号ブロックごとに連続して解読することができるが、インテグリティ検証は、フラグメント全体が配信されたときにのみ実施することができる。このメカニズムは、鍵およびソルトを付され、鍵は、機密性保護をロック解除するための方法であり、また、インテグリティがフラグメントに対して保持されたことを確信させるための方法でもある。本例において、実際の鍵ＩＤは、すべてのリソースフラグメントにわたって共通である（また、Ｃｒｙｐｔｏ－Ｋｅｙパラメータに含まれるリソースレベル鍵ＩＤ値と同じである）。しかしながら、この例の各フラグメントは、２つのフラグメントに対して同じ暗号が使用されることを防止するために、個々のソルト付き値を有する。これは、“Ｅｎｃｒｙｐｔｉｏｎ”（暗号化）パラメータによって提供される。このパラメータは、第１のフラグメントのメタデータを完結させる。

第２のフラグメントは同様であるが、そのパラメータにいくらかの差異があり、追加のパラメータを説明する。最初に、フラグメントＩＤが“２”であり、このフラグメントのＵＲＬも第２のフラグメントを指している（すなわち、ＵＲＬが第１のフラグメントのものと異なる）。フラグメントのオフセットが開始位置を提供しているが、長さが分からず、したがって終端位置が分からない。優先度は１に設定されており、このリソース全体内で最も優先度の高いフラグメントである。属性は、“Ｔｒａｎｓｆｅｒ－Ｅｎｃｏｄｉｎｇ”：”ｃｈｕｎｋｅｄ”を含む。これは、ＨＴＴＰチャンク化メカニズムを使用してこのフラグメントを配信することができることを指示する。これは、例えば、データがサーバ側で生成されるときに（例えば、メディアサンプルおよびそれらのメタデータが生成されるときに）、そのフラグメントについてデータを漸進的に配信するために使用することができる。“Ｔｙｐｅ－Ｓｐｅｃｉｆｉｃ”： “ｍｏｏｆ”パラメータおよびデータは、リソース全体のメディアタイプ「ｖｉｄｅｏ／ｍｐ４」のコンテキストにおいて解釈されるべきである。例えば、“ｍｏｏｆ”は、このフラグメントがｍｏｏｆボックスを包含していることを指示し得る。

第３のフラグメント（ｉｄ＝“３”）は、この例においては、既知の長さ（ｌｅｎｇｔｈ＝１２バイト）を有するが、（クライアントが第２のフラグメントの構築を完了するか、または、更新されているセグメント化マップを受信するまで）長さが分からない第２のフラグメントの後に来ているため、開始または終端オフセットは分からない。他のフラグメントに対するこのフラグメントの依存性は、“Ｓｉｚｅ－Ｄｅｐｅｎｄｅｎｃｙ”： ｛［“１”， “２”］｝ ａｎｄ “Ｃｏｎｔｅｎｔ－Ｄｅｐｅｎｄｅｎｃｙ”：｛［“４”］｝を使用して表現されている。ここで、サイズ依存性は、フラグメント１および２のサイズが分かっているときに、このフラグメントのサイズおよびロケーションが与えられる（すなわち、クライアントが知る）ことを意味する。Ｃｏｎｔｅｎｔ－Ｄｅｐｅｎｄｅｎｃｙは、ここでは、このフラグメントのコンテンツがフラグメント４内にあるものに依存することを指示する。この場合、これは、フラグメント３が、フラグメント４内にあるデータの長さフィールドを包含するヘッダを表すためである。そのため、フラグメント３は、フラグメント４の生成が完了するまで抽出することができない。これは、そのときまでフラグメント３自体を生成することができないためである。指示されているように、このフラグメントは最上位の優先度、すなわち、優先度１を有する。

第４のフラグメント（ｉｄ＝“４”）は、第２のフラグメントと類似の特性を有する。しかしながら、先行するフラグメントのサイズが分からないことに起因して、セグメント化マップが生成される時点においては、このフラグメントの実際のオフセットは分からない。このフラグメントの優先度は“１”であり、他のフラグメントに対するコンテンツ依存性はない。しかしながら、フラグメント４のサイズおよびオフセットはフラグメント３に依存する。コンテンツタイプ特有のヒント“Ｔｙｐｅ－Ｓｐｅｃｉｆｉｃ”： “ｍｄａｔ－ｓａｍｐｌｅｓ”は、このフラグメント４がｍｄａｔボックスのサンプルの開始において開始することを指示する。このヒントは、メディアタイプにアウェアなクライアントが、チャンク化ＨＴＴＰ転送によって配信されているときにデータの消費を開始することを可能にする。

上記で指示したように、この例において、各フラグメントのメタデータは、その順序を順列で指示する（すなわち、識別子１、２、３、および４）フラグメント識別子を含む。加えて、フラグメント（すなわち、複数のフラグメントメタデータ）はアレイにおいて記憶され、アレイは、この例では、順序付けされたデータ構造であり、アレイは、フラグメントに順序を課すことができる。この例において、両方の順序（データ構造によって暗示される順序と、フラグメント識別子によって指示される順序）は一致している。

上述したセグメント化マップを所与として、クライアントは、フラグメントを要求するための適切な順序を判定することができる。例えば、記憶容量に制約がなく、追加のコピーに伴う問題がないクライアントについて（例えば、クライアントがフラグメントの中間抽出およびその後のフラグメントの組み立てを実施することを所望している）、１つの可能な抽出戦略は、フラグメント２（コンテンツ依存性がなく、優先度が１である）を要求し、並行してフラグメント４（同じく依存性がなく、優先度が１である）を要求し、並行してフラグメント１（同じく依存性がないが、優先度はより低く、３である）を要求することである。この場合、フラグメント３は放置される。フラグメント３はコンテンツ依存性（フラグメント４に対する）を有するが、遅延を最小限に維持するために、クライアントは、フラグメント４が完全に生成されるまでこの要求が保留されることを期待して、先行して、このフラグメントを求める要求を別に行うことができる。

ここで図１１を参照すると、上記の要求の完了の可能なシナリオが描写されている。Ｔ０の時点において、セグメント化マップがクライアントによって処理されており、クライアントは、上述したように要求を行う。個々の要求が適切なサーバによって処理されると直ちに、フラグメント１、２、および４（各々コンテンツ依存性を有しない）の配信が開始する。フラグメント１はより低い優先度を有するが、この例では、そのサイズが制限されていることに起因して、最初に（時点Ｔ１において）完了する。フラグメント２および４（それらのＴｒａｎｓｆｅｒ－Ｅｎｃｏｄｉｎｇ値による）は、チャンク化配信を使用している。この事例においては、メディアデータおよびメディアサンプルのチャンクが、バーによって描写されているように、周期的に搬送される。時点Ｔ２において、サーバ（または複数のサーバ）がフラグメント２および４のデータの生成を完了しており、Ｔ２のわずか後に、それらのデータの配信が完了することになり、チャンク化転送メカニズムがそれらのデータの配信の完了を指示することになる。この例によれば、フラグメント３を求める要求は、そのフラグメントのコンテンツ依存性によって、Ｔ０からＴ３まで保留されている。時点Ｔ２において、フラグメント３のデータ（この例では、ｍｄａｔボックスの長さを識別する長さ情報）が生成されており、その配信を開始することができる。フラグメント３の配信は、時点Ｔ３において完了する。時点Ｔ３において、クライアントは、フラグメントを組み立ててＩＳＯ ＢＭＦＦメディアセグメントにすることができる。

上記で指示したように、要求の順序は、記憶容量に制約がなく、追加のコピーに伴う問題がないクライアントに対応する。しかしながら、例えば、コピーを回避し、記憶要件を最小限に抑えることを所望する受信手段など、制約のある受信手段の場合、受信手段は、フラグメントの位置が分かるようにフラグメントを要求し得る順序を決定するためのサイズ依存性メタデータを使用することになり得る。この事例において、クライアントは、最初にフラグメント１および２のみを要求することになる。これは、フラグメント１および２がサイズ依存性を有せず、すなわち、フラグメント１が既知のサイズを有し、リソースファイルの始まりにおいて開始するためである。フラグメント２は、フラグメント１の直後に開始するが、その長さは最初は分からない。したがって、受信手段は、共通の連続したファイルに受信するときに、データを書き込むことが可能になる。フラグメント２が配信されると、フラグメント３および４は既知のサイズを有することになる。したがって、クライアントはその後、フラグメント３および４を並行して要求することができる。サイズおよび連続したファイルへのオフセットが分かることによって、受信時に直接的に、データを正確な位置に書き込むことができる。

ＤＡＳＨライブメディアセグメントに使用される別の例示的な実施形態

本出願において記載されているセグメント化ソリューションの実施形態は、メディア配信サーバにおけるコンテンツ取り込み開始から、クライアントにおいて再生が開始されるまでの遅延（Ｔ_{ｓｏｕｒｃｅ＿ｔｏ＿ｐｌａｙｂａｃｋ}）を低減するために使用することができる。最初に、符号化手段が、ストリーミング配信に適したフォーマット（例えば、Ｈ．２６４）において、符号化メディアコンテンツを、個々のフレームレベル、または、ピクチャ群（ＧＯＰ）毎など、何らかのより粗いレベルのいずれかにおいて生成する。ここから、符号化メディアを、ＨＴＴＰのようなパケットベースのプロトコルを介して配信するためのフォーマットにするために（例えば、符号化メディアはｍｐ４またはＩＳＯＢＭＦＦフォーマットにされる）、符号化メディアがパケット化されるか、または、パケタイザもしくはファイルフォーマット構築手段に通される。

ここで、ＩＳＯＢＭＦＦファイルによるＤＡＳＨライブメディアストリーミングを使用する例を説明する。

この例における各メディアセグメントについて、セグメントは３秒の長さを有し、ＩＳＯＢＭＦＦフォーマットにおいて提供されると仮定する。ファイル構築手段は、この場合はセグメントタイプボックス（ｓｔｙｐ）によって開始する初期構造を作成する。この構造は、メディアセグメントのブランドおよびメディア初期化セグメント内で使用されるファイルタイプに基づいて構築することができる。ＤＡＳＨに従ってセグメント化されるＩＳＯＢＭＦＦファイルについて、個々のセグメントは、サンプルのロケーションに関する情報を提供するために、動画フラグメント（ｍｏｏｆ）ボックスを使用する。ここでの課題は、ｍｏｏｆボックス内の情報の一部が個々のサンプルに依存することである。そのような依存性の一例は、ｍｏｏｆボックスの一部である、トラックフラグメントボックス（ｔｒａｆ）の一部である、トラックフラグメントランボックス（ｔｒｕｎ）である。ｔｒｕｎは、ｍｄａｔの内部に記憶されている各サンプルについて、このサンプルが配置されている場所に対するオフセットを含む。したがって、オフセットは、対応するサンプルがｍｄａｔに追加された後（すなわち、オフセットが最初に分かるとき）にのみ、ｔｒｕｎ内のサンプルエントリに書き込むことができる。依存性の別の例として、所与のボックスの全長は、すべてのボックスまたはサンプルがそのボックスに書き込まれるまで分からないため、ボックスの長さフィールドが問題になり得る。ボックスがファイルの終端まで延在する場合、長さに０の値を指定することが可能であり、これは、ボックスの長さがファイルの終端まで続くことを意味する。しかしながら、ｍｄａｔボックスは通常、ｍｏｏｆに後続しなければならないため、ｍｏｏｆの長さは典型的には０として指定され得ない。

本出願において開示されているリソースセグメント化の実施形態は、ＩＳＯＢＭＦＦのＤＡＳＨ仕様の使用に従ってフォーマット化されたメディアセグメントに適用することができる。そうすることによって、遅延を低減することができ、メディアサンプルデータが利用可能になるときに、ＨＴＴＰチャンク化配信または他のプッシュ配信を可能にすることができる。

ここで図１２を参照すると、ＤＡＳＨメディアセグメントリソースのセグメント化は以下のように進行することができる。第１のリソースフラグメント１２１０は、最初に生成され得る情報を有する、ファイルの開始を包含することができる。このフラグメント１２１０は、すべてのサンプルが生成される前に知られるすべての初期ボックス１２０４を包含する。次のリソースフラグメント１２１２は、ｍｏｏｆボックス１２０６を包含することができる。［Ｓ４－１４１２０１］に記載されているように、すべてのサンプルが生成される前に、ｍｏｏｆボックス１２０６が（ｍｏｏｆボックス内に包含されるボックスとともに）占める余地空間の量を推定することが可能である。そのような推定は、何らかの予約空間を含み得る。したがって、全長を推定することができ、必要なサンプルが追加された後に何らかの残りの空間が存在する場合、この空間を、空きボックスを使用して空きとしてマークすることができる（この事例において、空きボックスは、ＩＳＯＢＭＦＦ仕様に準拠するために必要とされる）。ここでサイズが過小評価されると、セグメントのフォーマットが不良または不満足な結果となり、サイズが過大評価されると、空間が無駄になる結果となることが留意される。したがって、過大評価することがより好ましい。推定は、例えば、既知のまたは推定されるフレームレートおよび持続時間に基づくことができ、これによって、サンプル数が分かるかまたは推定される。第３のリソースフラグメント１２１４は、ｍｄａｔボックス１２０８を包含することができる。このボックス１２０８のサイズは、すべてのサンプルが生成されるまで分からないが、ボックスはファイルの終端まで延在することになる。したがって、０の長さフィールド値を使用することが可能である。第３のリソースフラグメント１２１４はほとんど、ｍｄａｔボックス１２０８のデータ部分、すなわち、メディアサンプルのデータを含む。ここで、リソースセグメントの初期オフセットが分かる（フラグメント３オフセット＝１５６２）が、ボックスの終端に対応するオフセットは分からない。したがって、終端オフセットは開放端として指示される。

ここで、クライアントは、第１のリソースフラグメントを抽出することから開始することができる。その抽出の後、クライアントは、第２のフラグメント（ｔｒｕｎボックスのコンテンツを有する）および第３のフラグメント（ｍｄａｔボックスのコンテンツを有する）を抽出することができ、個々のリソースフラグメントのＨＴＴＰチャンク化によって、２つの独立したＨＴＴＰリソース要求を使用して、これら２つのフラグメントの配信を始めることができる。ＨＴＴＰチャンク化は、例えば、個々のメディアサンプルなどのデータの適切なチャンクを、符号化を完了するときに配信するために使用され、対応するサンプルは、完了されるときに、ｔｒｕｎボックス内で延在する。メディアセグメントに属するすべてのサンプルがｍｄａｔボックスに書き込まれると、ＨＴＴＰチャンク化を使用してチャンク化配信の終端を指示することによって、フラグメントが閉じられる。ｍｏｏｆフラグメントはまた、ｔｒｕｎボックスの最後の部分を書き込むことによっても完了され、存在する場合、残りの空間は空きボックスによって消費される（結果、フラグメントのバイトカウントが所定の長さまで上げられる）。これによって、メディアセグメントの配信が完了する。

セグメントマップはまた、必要に応じて、リソースフラグメントの開始が何かを受信クライアントに指示するためのヒントをも包含することができる。例えば、セグメント化マップは、１つのフラグメントがｍｄａｔボックスの開始である（ここでは、フラグメント３）ことを指示し得、これによって、クライアントが、ｈｔｔｐチャンク化によって配信されるようにするときに、メディアサンプルを消費することが可能になる。

上記の例は、ｍｏｏｆボックスのコンテンツが書き込まれることになるリソースセグメント、および、特にｔｒｕｎボックスの推定され、予め割り当てられる空間を使用する。代替的な実施形態は、このボックスが要求する空間の量を推定せず、代わりに、リソースセグメントの長さが開始時に分からないことを指示し、その後、ＨＴＴＰチャンク化を使用して、リソースセグメント全体が配信されるとき、すなわち、ＩＳＯＢＭＦＦセグメントファイル内に含まれるように意図されているすべてのサンプルが含まれるときを指示し、すべてのデータの最終的な位置が分かる。これが行われるとき、最終的なｔｒｕｎが書き込まれ、ｍｏｏｆボックスの終端が決定されると、ＨＴＴＰチャンク化が、空のチャンクを配信して、これが終端であることを指示する。しかしながら、この事例においてｍｏｏｆボックスの長さを正確に指示するために、ｍｏｏｆボックスの開始（長さフィールドを含む）は別個のフラグメントに置く必要があり、結果、ｍｏｏｆボックスの長さが決定した後に、この別個のフラグメントが配信され得る。

この手法（すなわち、ｍｏｏｆボックスが必要とする空間の量を推定しない）には、必要な空間が誤って推定される危険性が回避され、任意の未使用空間が無駄になることも回避されるという利点がある。しかしながら、最後のリソースが将来の使用のために記憶されることになる場合、最後に組み立てられるリソースの１つの連続したバイトストリームとしてそのリソースフラグメントを組み立てるために、通常、追加のコピー動作が必要とされる。しかし、使用事例によっては、これは最も重要な使用法ではなく、代わりに、依然としてＩＳＯＢＭＦＦのライブプロファイルに後続するものとしてフォーマット化されるが、データに対する可能な最も早期のアクセスが、主要な使用法である。

比較例

ここで、比較例が提供される。サーバ（サーバ１０４など）が、２つのクライアントにサーブしており、第１のクライアントは、本開示の実施形態に従ってセグメント化マップを受信および処理することが可能なクライアント（クライアント１０２など）（「スマートクライアント」と呼ばれる）であり、第２のクライアントは、本開示の実施形態に従ってセグメント化マップを受信および処理することが可能でない従来のクライアント（「ダムクライアント（ｄｕｍｂ ｃｌｉｅｎｔ）」または「従来のクライアント」と呼ばれる）である。

サーバは、ライブストリーミングメディアイベント（例えば、夕方のＴＶニュース番組）へのアクセスを提供している。サーバは、イベントが進行中であるときに、ソースフィードを連続的に受信している。サーバは、総継続時間、ソースフィードの品質、予測視聴率などのような、ソースフィードに関する情報をごくわずかしか知らない場合があり、代替的に、そのような情報は事前に完全に決定することができ、または、サーバは、そのような物事の推定値（例えば、番組の典型的な開始および終了時刻、および入来するフィードの典型的な品質）のいずれを形成すべきかに関する何らかの情報を有することができる。いずれにせよ、サーバは、ライブストリーミングメディアイベントのマニフェストファイルを準備する。このファイルは、イベントを、典型的には個々に２秒と１０秒との間の継続時間の複数のセグメント、またはメディアリソースに分解する。マニフェストファイルは、クライアントが特定のセグメントまたはメディアリソースにいつアクセスすべきかに関するヒントを包含することができる。例えば、サーバは、時点ｔ０において第１のリソースの受信を始めること、および、リソースを処理するのに（例えば、クライアントに配信する準備ができるようにリソースを符号化およびパケット化するのに）Ａ秒かかることを知るまたは推定することができる。

従来のクライアントは、サーバがリソースを処理し、配信の準備ができるまで、個々のメディアリソースを受信し始めることが可能でないため、マニフェストファイルに従うことになる。それゆえ、従来のクライアントは、時点ｔ１（ｔ１＝ｔ０＋Ａ）においてまたは時点ｔ１の後に第１のメディアリソースを要求する。したがって、従来のクライアントの遅延Ｔ_{ｓｏｕｒｃｅ＿ｔｏ＿ｒｅｃｅｐｔｉｏｎ}はＡである。Ａの典型的な値は、２秒と１０秒との間であり得る。

さらに、従来のクライアントは、再生を始める前にリソース全体を受信および処理する必要があり、これにＢ秒かかる。したがって、従来のクライアントは、時点ｔ２（ｔ２＝ｔ１＋Ｂ＝ｔ０＋Ａ＋Ｂ）まで再生を始めることができず、そのため、従来のクライアントの遅延Ｔ_{ｓｏｕｒｃｅ＿ｔｏ＿ｒｅｃｅｐｔｉｏｎ}はＢである。この結果として、遅延Ｔ_{ｓｏｕｒｃｅ＿ｔｏ＿ｐｌａｙｂａｃｋ}＝Ａ＋Ｂとなる。

他方、セグメント化マップを受信および処理することが可能なクライアントであるスマートクライアントは、サーバが第１のメディアリソースを完全に処理する前に、第１のメディアリソースを要求することが可能である。サーバがセグメント化マップを生成し、メディアリソースの部分をクライアントに提供し始めるのに、Ｃ秒しかかからないであろう。したがって、スマートクライアントは、時点ｔ１’（ｔ１’＝ｔ０＋Ｃ）においてまたは時点ｔ１’の後に第１のメディアリソースを要求する。したがって、スマートクライアントの遅延Ｔ_{ｓｏｕｒｃｅ＿ｔｏ＿ｒｅｃｅｐｔｉｏｎ}はＣである。Ｃの典型的な値は、約２００ｍｓであり得る。この時間は、セグメント化マップを形成するための時間と、セグメント化マップを配信し、その後、クライアントにフラグメントを請求させ、その後、フラグメントの配信を開始することを可能にするためのさらなる往復とから構成される。

さらに、スマートクライアントは、セグメント全体を受信する前に、再生を始めることが可能である。例えば、上述したように、アプリケーションレベルヒントが、例えば、Ｄ秒の受信以内に、クライアントが再生を始めることを可能にすることができる。したがって、スマートクライアントは、時点ｔ２’（ｔ２’＝ｔ１’＋Ｃ＝ｔ０＋Ｃ＋Ｄ）において再生を始めることができ、そのため、スマートクライアントの遅延Ｔ_{ｓｏｕｒｃｅ＿ｔｏ＿ｒｅｃｅｐｔｉｏｎ}はＤである。この結果として、遅延Ｔ_{ｓｏｕｒｃｅ＿ｔｏ＿ｐｌａｙｂａｃｋ}＝Ｃ＋Ｄとなる。本例において、ＭＯＯＦは相対的に小さい（数ｋｂ）ため、差Ｂ－Ｄは、この例においては、数ミリ秒程度である。

この例によれば、遅延Ｔ_{ｓｏｕｒｃｅ＿ｔｏ＿ｒｅｃｅｐｔｉｏｎ}は、約２～１０秒から約２００ミリ秒まで、または約９０％～９８％低減することができる。遅延Ｔ_{ｒｅｃｅｐｔｉｏｎ＿ｔｏ＿ｐｌａｙｂａｃｋ}は、数ミリ秒だけ低減することができる。全体的に、この結果として、ソース取り込みから再生までの遅延が大幅に低減される。

この例から明らかであるように、リソースセグメントが、クライアントによる消費に利用可能になる時点は、クライアントがセグメント化モードをサポートしているか否かに応じて大幅に異なる。いくつかの実施形態において、セグメント化モードをサポートしているスマートクライアントは、マニフェストファイル内で提供される利用可能性ヒントを無視するか、または、適切に修正することを決定することができる。いくつかの実施形態において、サーバは、１つのマニフェストファイルを従来のクライアントに提供し、異なるマニフェストファイル（改訂された利用可能性ヒントを有する）をスマートクライアントに提供することができる。

図１３は、いくつかの実施形態による、クライアント１０２またはサーバ１０４のいずれかを実装するために使用することができる装置１３００のブロック図である。図１３に示すように、装置は、１つまたは複数のプロセッサ１３５５（例えば、汎用マイクロプロセッサ、および／または、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）などのような１つもしくは複数の他のプロセッサ）を含むことができるデータ処理システム（ＤＰＳ）１３０２と、他の装置との通信に使用するための、アンテナまたは通信ポートに結合することができる送信手段１３０５および受信手段１３０６と、１つもしくは複数の不揮発性記憶デバイス（例えば、フラッシュメモリ、ハードディスク、光ディスクなど）および／または１つもしくは複数の揮発性記憶デバイス（例えば、揮発性ランダムアクセスメモリ（ＲＡＭ））を含むことができるローカル記憶ユニット（「データ記憶システム」としても知られる）１３１２とを備えることができる。ＤＰＳ１３０２がプログラム可能マイクロプロセッサを含む実施形態において、コンピュータプログラム製品（ＣＰＰ）１３４１を提供することができる。ＣＰＰ１３４１は、コンピュータ可読命令（ＣＲＩ）１３４４を含むコンピュータプログラム（ＣＰ）１３４３を記憶しているコンピュータ可読媒体（ＣＲＭ）１３４２を含む。ＣＲＭ１３４２は、限定ではないが、磁気媒体（例えば、ハードディスク）、光媒体（例えば、ＤＶＤ）、メモリデバイス（例えば、フラッシュメモリ、揮発性ＲＡＭ）などのような、非一時的コンピュータ可読媒体であってもよい。いくつかの実施形態において、コンピュータプログラム１３４３のＣＲＩ１３４４は、データ処理システム１３０２によって実行されると、ＣＲＩが、装置に、本明細書において記載されているステップ（例えば、流れ図を参照しながら上述したステップ）を実施させるように設定される。他の実施形態において、装置は、コードを必要とすることなく、本明細書において記載されているステップを実施するように設定されてもよい。すなわち、例えば、データ処理システム１３０２は、１つまたは複数のＡＳＩＣのみから構成されてもよい。したがって、本明細書において記載されている実施形態の特徴は、ハードウェアおよび／またはソフトウェアにおいて実装されてもよい。

本開示の様々な実施形態が本明細書において説明されているが（添付文書を含む）、それらは例としてのみ提示されており、限定ではないことが理解されるべきである。したがって、本開示の広がりおよび範囲は、上述されている例示的な実施形態のいずれによっても限定されるべきではない。その上、本明細書において別途指示しない限り、または、文脈によって別途明確に否定されない限り、すべての可能な変形における上述した要素の任意の組み合わせが、本開示によって網羅される。

加えて、上述されており、図面において図解されている処理は、一連のステップとして示されているが、これは、説明の目的でのみ行われている。したがって、いくつかのステップが追加されてもよく、いくつかのステップが省略されてもよく、ステップの順序が再編成されてもよく、いくつかのステップは並行して実施されてもよいことが企図されている。
本発明は以下に記載する態様を含む。
（態様１）
サーバ（１０４）が、第１のフラグメント（１２１０）および第２のフラグメント（１２１２）を含むフラグメントの順序付けされたセット（１２１０、１２１２、１２１４）を含む、メディアセグメントのセグメント化マップを生成することと、
前記サーバ（１０４）が、前記セグメント化マップをクライアント（１０２）に提供することと
を含む方法であって、
前記セグメント化マップは、
前記第１のフラグメント（１２１０）と関連付けられる第１のフラグメントメタデータと、
前記第２のフラグメント（１２１２）と関連付けられる第２のフラグメントメタデータと、
前記第１のフラグメント（１２１０）が前記第２のフラグメント（１２１２）の前に順序付けされていることを指示する情報を含む、前記セット（１２１０、１２１２、１２１４）内のフラグメントの順序付けを識別する順序付け情報と
を含み、
前記第１のフラグメントメタデータは、１）前記第１のフラグメント（１２１０）へのアクセスに使用するための第１のフラグメント識別子と、２）以下のもの、すなわち、
２ａ）前記サーバ（１０４）から配信されるべき前記第１のフラグメント（１２１０）の利用可能性が前記セット（１２１０、１２１２、１２１４）の１つもしくは複数の他のフラグメントに依存することを指示する、前記第１のフラグメント（１２１０）の第１の依存性情報、
２ｂ）前記第１のフラグメント（１２１０）の長さ、前記メディアセグメント内の前記第１のフラグメント（１２１０）の開始位置、および前記メディアセグメント内の前記第１のフラグメント（１２１０）の終端位置のうちの１つもしくは複数を含む第１の位置情報、ならびに
２ｃ）前記第１のフラグメント（１２１０）のインテグリティの検証に使用するための第１のフラグメントレベルセキュリティ情報のうちの１つまたは複数と
を含み、
前記第２のフラグメントメタデータは、前記第２のフラグメント（１２１２）へのアクセスに使用するための第２のフラグメント識別子を含む、方法。
（態様２）
前記第１のフラグメントメタデータは、前記第１の依存性情報、前記第１の位置情報、および前記第１のフラグメントレベルセキュリティ情報を含む、態様１に記載の方法。
（態様３）
前記第１のフラグメントメタデータは、前記第１のフラグメントレベルセキュリティ情報を含み、
前記フラグメントレベルセキュリティ情報は、前記サーバ（１０４）によって、前記第１のフラグメント（１２１０）および前記第１のフラグメント（１２１０）の一部のうちの少なくとも一方のハッシュを生成するために使用されるハッシュ情報を含む、態様１または２に記載の方法。
（態様４）
前記第２のフラグメントメタデータは、
前記サーバ（１０４）から配信されるべき前記第２のフラグメント（１２１２）の利用可能性が前記セット（１２１０、１２１２、１２１４）の１つもしくは複数の他のフラグメントに依存することを指示する、前記第２のフラグメント（１２１２）の第２の依存性情報と、
前記第２のフラグメント（１２１２）の長さ、前記メディアセグメント内の前記第２のフラグメント（１２１２）の開始位置、および前記メディアセグメント内の前記第２のフラグメント（１２１２）の終端位置のうちの１つもしくは複数を含む第２の位置情報と、
前記第２のフラグメント（１２１２）のインテグリティの検証に使用するための第２のフラグメントレベルセキュリティ情報と
のうちの１つまたは複数をさらに含む、態様１から３のいずれか一項に記載の方法。
（態様５）
前記第１のフラグメントメタデータは、前記第１のフラグメント（１２１０）に対応する優先度値をさらに含む、態様１から４のいずれか一項に記載の方法。
（態様６）
前記第１のフラグメントメタデータは、符号化識別子をさらに含む、態様１から５のいずれか一項に記載の方法。
（態様７）
前記第１のフラグメント識別子は、前記第１のフラグメント（１２１０）を識別する統一資源識別子（ＵＲＩ）を含む、態様１から６のいずれか一項に記載の方法。
（態様８）
前記第１のフラグメントメタデータは、前記メディアセグメントのタイプと関連付けられるアプリケーションレベルヒントをさらに含み、
前記アプリケーションレベルヒントは、クライアント（１０２）が、他の複数のフラグメント（１２１０、１２１２、１２１４）の各々を受信する前に前記第１のフラグメント（１２１０）を利用することを可能にする、態様１から７のいずれか一項に記載の方法。
（態様９）
前記第１の依存性情報は、サイズ依存性情報を含み、
前記サイズ依存性情報は、前記第１のフラグメント（１２１０）のサイズが判定される可能性がある前に生成されなければならない０個以上の他のフラグメント（１２１０、１２１２、１２１４）を指示する、態様１から８のいずれか一項に記載の方法。
（態様１０）
前記第１の依存性情報は、コンテンツ依存性情報を含み、
前記コンテンツ依存性情報は、前記第１のフラグメント（１２１０）のコンテンツが生成される可能性がある前に生成されなければならない０個以上の他のフラグメント（１２１０、１２１２、１２１４）を指示する、態様１から８のいずれか一項に記載の方法。
（態様１１）
前記順序付け情報は、各フラグメントメタデータと関連付けられるシーケンス識別子を含む、態様１から１０のいずれか一項に記載の方法。
（態様１２）
前記順序付け情報は、前記複数のフラグメントメタデータを記憶するデータ構造内に内在する、態様１から１０のいずれか一項に記載の方法。
（態様１３）
前記セグメントマップは、
前記メディアセグメントのメディアタイプ、
リソースレベルインテグリティ情報、
前記メディアセグメントの統一資源位置指定子（ＵＲＬ）、および
前記クライアント（１０２）が前記セグメント化マップを更新することが推奨される場合を指示する更新ヒントであって、前記更新ヒントは、期限切れ時間およびコンテンツ依存性属性のうちの１つまたは複数を含む、更新ヒント
のうちの１つまたは複数を含むメディアセグメントメタデータをさらに含む、態様１から１２のいずれか一項に記載の方法。
（態様１４）
前記クライアント（１０２）から、前記メディアセグメントを求める要求を受信することと、
前記メディアセグメントを求める前記要求に応答して、前記クライアント（１０２）に、前記セグメント化マップを送信することと
をさらに含む、態様１から１３のいずれか一項に記載の方法。
（態様１５）
前記クライアント（１０２）から、前記第１のフラグメント（１２１０）を求める要求を受信することと、
前記第１のフラグメント（１２１０）を求める前記要求を受信することに応答して、前記クライアント（１０２）に、前記第１のフラグメント（１２１０）を送信することと
をさらに含む、態様１４に記載の方法。
（態様１６）
新たな情報に基づいて前記セグメント化マップを更新することであって、前記新たな情報は、前記複数のフラグメント（１２１０、１２１２、１２１４）のうちの１つの長さ、前記複数のフラグメント（１２１０、１２１２、１２１４）のうちの１つの開始位置、および前記複数のフラグメント（１２１０、１２１２、１２１４）のうちの１つの終端位置のうちの１つまたは複数を含む、更新することと、
前記クライアント（１０２）に前記更新されているセグメント化マップを送信することと
をさらに含む、態様１から１５のいずれか一項に記載の方法。
（態様１７）
態様１から１６のいずれか一項に記載の方法を実施するように設定されている、サーバ（１０４）。
（態様１８）
サーバ（１０４）であって、
メモリを備えるデータ記憶システム（１３１２）と、
プロセッサ（１３５５）を備えるデータ処理システム（１３０２）と
を備え、
前記サーバ（１０４）は、態様１から１６のいずれか一項に記載の方法を実施するように設定されている、サーバ（１０４）。
（態様１９）
クライアント（１０２）が、サーバ（１０４）によって伝送されるセグメント化マップを受信することであって、前記セグメント化マップは、複数のメディアセグメントを含むメディアストリームの第１のメディアセグメントのためのものであり、前記複数のメディアセグメントは、第１のメディアセグメントおよび第２のメディアセグメントを含み、前記第１のメディアセグメントは、フラグメントの順序付けされたセット（１２１０、１２１２、１２１４）を含み、前記フラグメントの順序付けされたセット（１２１０、１２１２、１２１４）は、第１のフラグメント（１２１０）および第２のフラグメント（１２１２）を含む、受信することと、
前記クライアント（１０２）が、前記セグメント化マップを処理することと
を含む方法であって、
前記セグメント化マップは、
前記第１のフラグメント（１２１０）と関連付けられる第１のフラグメントメタデータと、
前記第２のフラグメント（１２１２）と関連付けられる第２のフラグメントメタデータと、
前記第１のフラグメント（１２１０）が前記第２のフラグメント（１２１２）の前に順序付けされていることを指示する情報を含む、前記セット（１２１０、１２１２、１２１４）内のフラグメントの順序付けを識別する順序付け情報と
を含み、
前記第１のフラグメントメタデータは、１）前記第１のフラグメント（１２１０）へのアクセスに使用するための第１のフラグメント識別子と、２）以下のもの、すなわち、
２ａ）前記サーバ（１０４）から配信されるべき前記第１のフラグメント（１２１０）の利用可能性が前記セット（１２１０、１２１２、１２１４）の１つもしくは複数の他のフラグメントに依存することを指示する、前記第１のフラグメント（１２１０）の第１の依存性情報、
２ｂ）前記第１のフラグメント（１２１０）の長さ、前記第１のメディアセグメント内の前記第１のフラグメント（１２１０）の開始位置、および前記第１のメディアセグメント内の前記第１のフラグメント（１２１０）の終端位置のうちの１つもしくは複数を含む第１の位置情報、ならびに
２ｃ）前記第１のフラグメント（１２１０）のインテグリティの検証に使用するための第１のフラグメントレベルセキュリティ情報のうちの１つまたは複数と
を含み、
前記第２のフラグメントメタデータは、前記第２のフラグメント（１２１２）へのアクセスに使用するための第２のフラグメント識別子を含む、方法。
（態様２０）
前記サーバ（１０４）によって伝送される前記セグメント化マップを受信する前に、前記クライアント（１０２）が、前記サーバ（１０４）に、前記第１のメディアセグメントを求める要求を伝送することをさらに含む、態様１９に記載の方法。
（態様２１）
前記サーバ（１０４）によって伝送される前記セグメント化マップを受信する前に、マニフェストファイルを受信することであって、前記マニフェストファイルは、前記クライアント（１０２）が、前記第１のメディアセグメントを求める前記要求を送信することを可能にするための情報を含む、受信することと、
前記受信されているマニフェストファイルを処理することと
をさらに含み、
前記クライアント（１０２）は、前記マニフェストファイルを処理した後に、前記サーバ（１０４）に、前記第１のメディアセグメントを求める前記要求を伝送する、態様２０に記載の方法。
（態様２２）
前記第１のメディアセグメントを求める前記要求は、前記クライアント（１０２）がセグメント化モードをサポートしていることを指示する指標を含む、態様２０または２１に記載の方法。
（態様２３）
前記第１のフラグメント（１２１０）を受信することと、
前記第１のフラグメント（１２１０）を再生することと
をさらに含む、態様１９から２２のいずれか一項に記載の方法。
（態様２４）
前記第１のフラグメント（１２１０）を再生する前記ステップは、前記クライアント（１０２）が、前記フラグメントの順序付けされたセット（１２１０、１２１２、１２１４）に含まれる前記フラグメントをすべて受信する前に行われる、態様２３に記載の方法。
（態様２５）
前記第１のフラグメント（１２１０）のインテグリティを検証することをさらに含む、態様２３または２４に記載の方法。
（態様２６）
前記第１のフラグメント（１２１０）が前記第２のフラグメント（１２１２）に依存することを指示するフラグメント依存性情報に基づいて、前記クライアント（１０２）が、前記第１のフラグメント（１２１０）を求める要求を伝送する前に、前記第２のフラグメント（１２１２）を求める要求を伝送する、態様１９から２５のいずれか一項に記載の方法。
（態様２７）
態様１９から２６のいずれか一項に記載の方法を実施するように設定されている、クライアント（１０２）。
（態様２８）
クライアント（１０２）であって、
メモリを備えるデータ記憶システム（１３１２）と、
プロセッサ（１３５５）を備えるデータ処理システム（１３０２）と
を備え、
前記クライアント（１０２）は、態様１９から２６のいずれか一項に記載の方法を実施するように設定されている、クライアント（１０２）。
（態様２９）
データ処理システム（１３０２）によって実行されると、前記データ処理システム（１３０２）に、態様１から１６および態様１９から２６のいずれか一項に記載の方法を実施させる命令（１３４４）を含む、コンピュータプログラム（１３４３）。
（態様３０）
態様２９に記載のコンピュータプログラム（１３４３）を備える非一時的コンピュータ可読媒体（１３４２）を備える、コンピュータプログラム製品（１３４１）。

Claims (25)

1. サーバ（１０４）が、クライアント（１０２）から、メディアセグメントを求める要求を受信することと、
   前記サーバ（１０４）が、第１のフラグメント（１２１０）および第２のフラグメント（１２１２）を含むフラグメントの順序付けされたセット（１２１０、１２１２、１２１４）を含む、前記メディアセグメントのセグメント化マップを生成することと、
   前記サーバ（１０４）が、前記メディアセグメントを求める前記要求であって、前記クライアント（１０２）がセグメント化モードをサポートしていることを指示する指標を含む前記要求に応答して、前記セグメント化マップを前記クライアント（１０２）に提供することと
   を含む方法であって、
   前記セグメント化マップは、
   前記第１のフラグメント（１２１０）と関連付けられる第１のフラグメントメタデータと、
   前記第２のフラグメント（１２１２）と関連付けられる第２のフラグメントメタデータと、
   前記第１のフラグメント（１２１０）が前記第２のフラグメント（１２１２）の前に順序付けされていることを指示する情報を含む、前記セット（１２１０、１２１２、１２１４）内のフラグメントの順序付けを識別する順序付け情報と
   を含み、
   前記第１のフラグメントメタデータは、１）前記第１のフラグメント（１２１０）へのアクセスに使用するための第１のフラグメント識別子と、２）以下のもの、すなわち、
   ２ａ）前記サーバ（１０４）から配信されるべき前記第１のフラグメント（１２１０）の利用可能性が前記セット（１２１０、１２１２、１２１４）の１つもしくは複数の他のフラグメントに依存することを指示する、前記第１のフラグメント（１２１０）の第１の依存性情報、
   ２ｂ）前記第１のフラグメント（１２１０）の長さ、前記メディアセグメント内の前記第１のフラグメント（１２１０）の開始位置、および前記メディアセグメント内の前記第１のフラグメント（１２１０）の終端位置のうちの１つもしくは複数を含む第１の位置情報、ならびに
   ２ｃ）前記第１のフラグメント（１２１０）のインテグリティの検証に使用するための第１のフラグメントレベルセキュリティ情報のうちの１つまたは複数と
   を含み、
   前記第２のフラグメントメタデータは、前記第２のフラグメント（１２１２）へのアクセスに使用するための第２のフラグメント識別子を含む、方法。
2. 前記第１のフラグメントメタデータは、前記第１の依存性情報、前記第１の位置情報、および前記第１のフラグメントレベルセキュリティ情報を含む、請求項１に記載の方法。
3. 前記第１のフラグメントメタデータは、前記第１のフラグメントレベルセキュリティ情報を含み、
   前記第１のフラグメントレベルセキュリティ情報は、前記サーバ（１０４）によって、前記第１のフラグメント（１２１０）および前記第１のフラグメント（１２１０）の一部のうちの少なくとも一方のハッシュを生成するために使用されるハッシュ情報を含む、請求項１または２に記載の方法。
4. 前記第２のフラグメントメタデータは、
   前記サーバ（１０４）から配信されるべき前記第２のフラグメント（１２１２）の利用可能性が前記セット（１２１０、１２１２、１２１４）の１つもしくは複数の他のフラグメントに依存することを指示する、前記第２のフラグメント（１２１２）の第２の依存性情報と、
   前記第２のフラグメント（１２１２）の長さ、前記メディアセグメント内の前記第２のフラグメント（１２１２）の開始位置、および前記メディアセグメント内の前記第２のフラグメント（１２１２）の終端位置のうちの１つもしくは複数を含む第２の位置情報と、
   前記第２のフラグメント（１２１２）のインテグリティの検証に使用するための第２のフラグメントレベルセキュリティ情報と
   のうちの１つまたは複数をさらに含む、請求項１から３のいずれか一項に記載の方法。
5. 前記第１のフラグメントメタデータは、前記第１のフラグメント（１２１０）に対応する優先度値をさらに含む、請求項１から４のいずれか一項に記載の方法。
6. 前記第１のフラグメントメタデータは、符号化識別子をさらに含む、請求項１から５のいずれか一項に記載の方法。
7. 前記第１のフラグメント識別子は、前記第１のフラグメント（１２１０）を識別する統一資源識別子（ＵＲＩ）を含む、請求項１から６のいずれか一項に記載の方法。
8. 前記第１のフラグメントメタデータは、前記メディアセグメントのタイプと関連付けられるアプリケーションレベルヒントをさらに含み、
   前記アプリケーションレベルヒントは、クライアント（１０２）が、他の複数のフラグメント（１２１０、１２１２、１２１４）の各々を受信する前に前記第１のフラグメント（１２１０）を利用することを可能にする、請求項１から７のいずれか一項に記載の方法。
9. 前記第１の依存性情報は、サイズ依存性情報を含み、
   前記サイズ依存性情報は、前記第１のフラグメント（１２１０）のサイズが判定される可能性がある前に生成されなければならない０個以上の他のフラグメント（１２１０、１２１２、１２１４）を指示する、請求項１から８のいずれか一項に記載の方法。
10. 前記第１の依存性情報は、コンテンツ依存性情報を含み、
    前記コンテンツ依存性情報は、前記第１のフラグメント（１２１０）のコンテンツが生成される可能性がある前に生成されなければならない０個以上の他のフラグメント（１２１０、１２１２、１２１４）を指示する、請求項１から８のいずれか一項に記載の方法。
11. 前記順序付け情報は、各フラグメントメタデータと関連付けられるシーケンス識別子を含む、請求項１から１０のいずれか一項に記載の方法。
12. 前記順序付け情報は、複数のフラグメントメタデータを記憶するデータ構造内に内在する、請求項１から１０のいずれか一項に記載の方法。
13. 前記セグメント化マップは、
    前記メディアセグメントのメディアタイプ、
    リソースレベルインテグリティ情報、
    前記メディアセグメントの統一資源位置指定子（ＵＲＬ）、および
    前記クライアント（１０２）が前記セグメント化マップを更新することが推奨される場合を指示する更新ヒントであって、前記更新ヒントは、期限切れ時間およびコンテンツ依存性属性のうちの１つまたは複数を含む、更新ヒント
    のうちの１つまたは複数を含むメディアセグメントメタデータをさらに含む、請求項１から１２のいずれか一項に記載の方法。
14. 前記クライアント（１０２）から、前記第１のフラグメント（１２１０）を求める要求を受信することと、
    前記第１のフラグメント（１２１０）を求める前記要求を受信することに応答して、前記クライアント（１０２）に、前記第１のフラグメント（１２１０）を送信することと
    をさらに含む、請求項１に記載の方法。
15. 新たな情報に基づいて前記セグメント化マップを更新することであって、前記新たな情報は、前記複数のフラグメント（１２１０、１２１２、１２１４）のうちの１つの長さ、前記複数のフラグメント（１２１０、１２１２、１２１４）のうちの１つの開始位置、および前記複数のフラグメント（１２１０、１２１２、１２１４）のうちの１つの終端位置のうちの１つまたは複数を含む、更新することと、
    前記クライアント（１０２）に、更新された前記セグメント化マップを送信することと
    をさらに含む、請求項１から１４のいずれか一項に記載の方法。
16. サーバ（１０４）であって、
    メモリを備えるデータ記憶システム（１３１２）と、
    プロセッサ（１３５５）を備えるデータ処理システム（１３０２）と
    を備え、
    前記サーバ（１０４）は、請求項１から１５のいずれか一項に記載の方法を実施するように設定されている、サーバ（１０４）。
17. クライアント（１０２）が、サーバ（１０４）に、第１のメディアセグメントを求める要求であって、前記クライアント（１０２）がセグメント化モードをサポートしていることを指示する指標を含む要求を伝送することと、
    前記サーバ（１０４）に、前記第１のメディアセグメントを求める前記要求を伝送したのちに、前記クライアント（１０２）が、前記サーバ（１０４）によって伝送されるセグメント化マップを受信することであって、前記セグメント化マップは、複数のメディアセグメントを含むメディアストリームの前記第１のメディアセグメントのためのものであり、前記複数のメディアセグメントは、前記第１のメディアセグメントおよび第２のメディアセグメントを含み、前記第１のメディアセグメントは、フラグメントの順序付けされたセット（１２１０、１２１２、１２１４）を含み、前記フラグメントの順序付けされたセット（１２１０、１２１２、１２１４）は、第１のフラグメント（１２１０）および第２のフラグメント（１２１２）を含む、受信することと、
    前記クライアント（１０２）が、前記セグメント化マップを処理することと
    を含む方法であって、
    前記セグメント化マップは、
    前記第１のフラグメント（１２１０）と関連付けられる第１のフラグメントメタデータと、
    前記第２のフラグメント（１２１２）と関連付けられる第２のフラグメントメタデータと、
    前記第１のフラグメント（１２１０）が前記第２のフラグメント（１２１２）の前に順序付けされていることを指示する情報を含む、前記セット（１２１０、１２１２、１２１４）内のフラグメントの順序付けを識別する順序付け情報と
    を含み、
    前記第１のフラグメントメタデータは、１）前記第１のフラグメント（１２１０）へのアクセスに使用するための第１のフラグメント識別子と、２）以下のもの、すなわち、
    ２ａ）前記サーバ（１０４）から配信されるべき前記第１のフラグメント（１２１０）の利用可能性が前記セット（１２１０、１２１２、１２１４）の１つもしくは複数の他のフラグメントに依存することを指示する、前記第１のフラグメント（１２１０）の第１の依存性情報、
    ２ｂ）前記第１のフラグメント（１２１０）の長さ、前記第１のメディアセグメント内の前記第１のフラグメント（１２１０）の開始位置、および前記第１のメディアセグメント内の前記第１のフラグメント（１２１０）の終端位置のうちの１つもしくは複数を含む第１の位置情報、ならびに
    ２ｃ）前記第１のフラグメント（１２１０）のインテグリティの検証に使用するための第１のフラグメントレベルセキュリティ情報のうちの１つまたは複数と
    を含み、
    前記第２のフラグメントメタデータは、前記第２のフラグメント（１２１２）へのアクセスに使用するための第２のフラグメント識別子を含む、方法。
18. 前記サーバ（１０４）によって伝送される前記セグメント化マップを受信する前に、マニフェストファイルを受信することであって、前記マニフェストファイルは、前記クライアント（１０２）が、前記第１のメディアセグメントを求める前記要求を送信することを可能にするための情報を含む、受信することと、
    前記受信されたマニフェストファイルを処理することと
    をさらに含み、
    前記クライアント（１０２）は、前記マニフェストファイルを処理した後に、前記サーバ（１０４）に、前記第１のメディアセグメントを求める前記要求を伝送する、請求項１７に記載の方法。
19. 前記第１のフラグメント（１２１０）を受信することと、
    前記第１のフラグメント（１２１０）を再生することと
    をさらに含む、請求項１７または１８に記載の方法。
20. 前記第１のフラグメント（１２１０）を再生するステップは、前記クライアント（１０２）が、前記フラグメントの順序付けされたセット（１２１０、１２１２、１２１４）に含まれる前記フラグメントをすべて受信する前に行われる、請求項１９に記載の方法。
21. 前記第１のフラグメント（１２１０）のインテグリティを検証することをさらに含む、請求項１９または２０に記載の方法。
22. 前記第１のフラグメント（１２１０）が前記第２のフラグメント（１２１２）に依存することを指示するフラグメント依存性情報に基づいて、前記クライアント（１０２）が、前記第１のフラグメント（１２１０）を求める要求を伝送する前に、前記第２のフラグメント（１２１２）を求める要求を伝送する、請求項１７から２１のいずれか一項に記載の方法。
23. クライアント（１０２）であって、
    メモリを備えるデータ記憶システム（１３１２）と、
    プロセッサ（１３５５）を備えるデータ処理システム（１３０２）と
    を備え、
    前記クライアント（１０２）は、請求項１７から２２のいずれか一項に記載の方法を実施するように設定されている、クライアント（１０２）。
24. データ処理システム（１３０２）によって実行されると、前記データ処理システム（１３０２）に、請求項１から１５および請求項１７から２２のいずれか一項に記載の方法を実施させる命令（１３４４）を含む、コンピュータプログラム（１３４３）。
25. 請求項２４に記載のコンピュータプログラム（１３４３）を備える非一時的コンピュータ可読媒体（１３４２）。
    

Images