"メディアプレゼンテーション記述情報を得るための方法であって、クライアントが、サーバ上の第1のメディアプレゼンテーション記述MPD内の変更に関連する情報を取得するステップと、前記クライアントが、前記変更に関連する情報によって、前記クライアント上の第2のMPDを更新するステップとを含む、方法。前記サーバは、ハイパーテキスト転送プロトコルHTTP規格1.1以降に準拠する標準的ウェブサーバである、請求項1に記載の方法。前記変更に関連する情報は、前記変更に関連する情報と、前記変更に関連する情報によって行なわれるアクションを指定するコマンドと、前記第2のMPD内の前記コマンドが適用されるべき場所を記述する式とのうちの少なくとも1つを含む、デルタファイル内に記憶される、請求項1に記載の方法。前記式は、XPath式である、請求項3に記載の方法。前記クライアントは、前記第1のMPDと関連付けられたセッション開始後、前記第1のMPD全体を取得し、前記第1のMPD全体を取得後、周期的間隔において、前記デルタファイルを取得する、請求項3に記載の方法。複数のデルタファイルは、前記クライアントに利用可能であって、前記複数のデルタファイルはそれぞれ、前記変更に関連する異なる情報量を含有し、前記クライアントは、前記複数のデルタファイルのうちの1つ以上を選択する、請求項3に記載の方法。シーケンスまたはバージョン番号は、前記複数のデルタファイルのうちのいずれを選択すべきかを判定するために使用される、請求項6に記載の方法。前記クライアントが、前記デルタファイルの取得に失敗する、または前記デルタファイル内にエラーを識別すると、前記クライアントは、前記第1のMPD全体を取得し、その後、前記デルタファイルを取得する、請求項3に記載の方法。前記変更に関連する情報は、前記第1のMPD内の拡張マークアップ言語XMLタグ内に記憶され、前記クライアントは、前記クライアントが、前記第2のMPDの更新を所望すると、前記タグの要素のみ読み出す、請求項1に記載の方法。前記XML構成アクセスプロトコルXCAPに準拠する識別子は、前記変更に関連する情報と関連付けられ、XCAPベースのメッセージは、前記クライアントへの前記変更に関連する情報にアクセスするために使用される、請求項1に記載の方法。前記クライアントは、前記変更に関連する情報が、前記サーバによって、前記クライアントにプッシュされるのに応じて、前記変更に関連する情報を受信する、請求項1に記載の方法。前記クライアントは、前記変更に関連する情報を受信するようにサブスクライブし、前記変更に関連する情報が利用可能になると、通知される、請求項1に記載の方法。前記第1のMPDは、前記第1のMPDが、前記第1のMPD全体を前記クライアントに提供することなく、前記第1のMPDの更新を前記クライアントに提供するステップをサポートすることを示す、インジケータを含む、請求項1に記載の方法。前記インジケータは、前記変更に関連する情報を提供するためのデルタファイルの使用と、前記変更に関連する情報にアクセスするためのXCAPメッセージの使用と、前記変更に関連する情報を提供するための前記サーバからのプシュの使用と、前記変更に関連する情報にアクセスするためのサブスクリプション/通知モデルの使用とのうちの少なくとも1つを示す、請求項13に記載の方法。クライアントが、サーバ上の第1のメディアプレゼンテーション記述MPD内の変更に関連する情報を取得するように構成され、前記クライアントが、前記変更に関連する情報によって、前記クライアント上の第2のMPDを更新するように構成される、プロセッサを含む、クライアント。前記サーバは、ハイパーテキスト転送プロトコルHTTP規格1.1以降に準拠する標準的ウェブサーバである、請求項15に記載のクライアント。前記変更に関連する情報は、前記変更に関連する情報と、前記変更に関連する情報によって行なわれるアクションを指定するコマンドと、前記第2のMPD内の前記コマンドが適用されるべき場所を記述する式とのうちの少なくとも1つを含む、デルタファイル内に記憶される、請求項15に記載のクライアント。前記式は、XPath式である、請求項17に記載のクライアント。前記クライアントは、前記第1のMPDと関連付けられたセッション開始後、前記第1のMPD全体を取得し、前記第1のMPD全体を取得後、周期的間隔において、前記デルタファイルを取得する、請求項17に記載のクライアント。複数のデルタファイルは、前記クライアントに利用可能であって、前記複数のデルタファイルはそれぞれ、前記変更に関連する異なる情報量を含有し、前記クライアントは、前記複数のデルタファイルのうちの1つを選択する、請求項17に記載のクライアント。シーケンスまたはバージョン番号は、前記複数のデルタファイルのうちのいずれを選択すべきかを判定するために使用される、請求項20に記載のクライアント。前記クライアントが、前記デルタファイルの取得に失敗する、または前記デルタファイル内にエラーを識別すると、前記クライアントは、前記第1のMPD全体を取得し、その後、前記デルタファイルを取得する、請求項17に記載のクライアント。前記変更に関連する情報は、前記第1のMPD内の拡張マークアップ言語XMLタグ内に記憶され、前記クライアントは、前記クライアントが、前記第2のMPDの更新を所望すると、前記タグの要素のみ読み出す、請求項15に記載のクライアント。前記XML構成アクセスプロトコルXCAPに準拠する識別子は、前記変更に関連する情報と関連付けられ、XCAPベースのメッセージは、前記クライアントへの前記変更に関連する情報にアクセスするために使用される、請求項15に記載のクライアント。前記クライアントは、前記変更に関連する情報が、前記サーバによって、前記クライアントにプッシュされるのに応じて、前記変更に関連する情報を受信する、請求項15に記載のクライアント。前記クライアントは、前記変更に関連する情報を受信するようにサブスクライブし、前記変更に関連する情報が利用可能になると、通知される、請求項15に記載のクライアント。前記第1のMPDは、前記第1のMPDが、前記第1のMPD全体を前記クライアントに提供することなく、前記第1のMPDの更新を前記クライアントに提供するステップをサポートすることを示す、インジケータを含む、請求項15に記載のクライアント。前記インジケータは、前記変更に関連する情報を提供するためのデルタファイルの使用と、前記変更に関連する情報にアクセスするためのXCAPメッセージの使用と、前記変更に関連する情報を提供するための前記サーバからのプシュの使用と、前記変更に関連する情報にアクセスするためのサブスクリプション/通知モデルの使用とのうちの少なくとも1つを示す、請求項27に記載のクライアント。本開示のより完全な理解のために、次に、同一参照番号は、同一部品を表す、付随の図面および発明を実施するための形態と併せて、以下の簡単な説明を参照する。最初に、本開示の1つ以上の実施形態の例証的実装が、以下に提供されるが、開示されるシステムおよび/または方法は、現在既知または既存であるかを問わず、任意の数の技法を使用して、実装されてもよいことを理解されたい。本開示は、本明細書に例証および説明される例示的設計ならびに実装を含む、以下に例証される例証的実装、図面、および技法にいかようにも限定されるべきではなく、添付の請求項の範囲とともに、均等物のその全範囲内で修正されてもよい。図1は、適応HTTPストリーミングのための典型的システムアーキテクチャを例証する。コンテンツ準備相110では、メディアプレゼンテーションが、HTTPストリーミングのために準備される。コンテンツは、次いで、HTTPストリーミングサーバ120上、および/または可能性として、HTTPキャッシュ130内に記憶される。HTTPストリーミングクライアント140は、HTTPGET要求または類似メッセージを使用して、サーバ120またはキャッシュ130から、メディアプレゼンテーションをダウンロードする場合がある。メディアプレゼンテーションは、3GPP仕様において、メディアプレゼンテーション記述MPDと呼ばれる、拡張マークアップ言語XML文書において記述される場合がある。MPDは、クライアントに、ビットレート、コーデック、画面解像度、および言語等、メディアコンテンツがエンコードされる、フォーマットを知らせる、メタデータを含有する。そのようなパラメータの各異なる組み合わせは、コンテンツの表現と称することができ、複数の異なる表現が、同一コンテンツを記述してもよい。これによって、クライアントは、可能性として、その画面解像度、現在のチャネル帯域幅、現在のチャネル受信条件、ユーザの言語選好、および他のパラメータに基づいて、特定の表現を選択可能となる。ライブストリーミングが使用されない場合、プレゼンテーション全体を記述するMPDは、クライアントに提供される場合があり、クライアントは、プレゼンテーションを通して、MPD内でメタデータを使用する場合がある。しかしながら、ライブストリーミングの場合、メタデータは、未だ既知ではない場合があるため、ストリーミングの開始に先立って、メディアストリーム全体に関するメタデータを提供することは可能でなくてもよい。また、ストリーミングセッションに関連するパラメータは、セッションの過程の間、変化してもよい。例えば、クライアントは、受信不良地域に移動し、データレートが、減速し得る。そのような場合、クライアントは、より低いビットレートを伴う表現に切り替える必要があり得る。別の実施例では、クライアントデバイスは、ストリーミングされたコンテンツの表示を肖像画から風景モードに切り替えるように選択してもよく、その場合、異なる表現が要求され得る。これらの理由から、クライアントに、プレゼンテーション全体を記述するMPDを提供することが不可能であり得る。そのような場合、メディアプレゼンテーションは、セグメントに分割されてもよく、MPDの一部は、各セグメントを記述してもよい。すなわち、HTTPストリーミングの場合、メディアは、ライブコンテンツの再生出力が、ライブエンコーディングにあまり遅れをとらないように、かつクライアントが、前述のように、チャネル条件または他の要因に従って、適応的にエンコーディングする、異なるコンテンツに切り替えることができるように、1回に1つのセグメント、メディアがダウンロードされてもよい。セグメントは、MPDにおけるUrlXML要素内の情報とともにアドレス可能である。Url要素は、セグメントのURLを含有し、HTTPGET要求の範囲ヘッダと併用され得る、範囲属性によって制限されてもよい。コンテンツの新しいセグメントは、10秒毎等、定期的間隔において、追加されてもよく、対応する新しい情報は、コンテンツの各新しいセグメントが追加されるのに伴って、MPDに追加されてもよい。したがって、MPDのサイズは、コンテンツのストリーミングが進行するのに伴って、成長してもよい。例示的MPDは、図2に例証されており、exampleMPD.xmlと称することができる。例示的MPDの複数の部分210はそれぞれ、メディアプレゼンテーションのセグメントを記述する。図中の空間を節約するために、2つのそのような部分210のみ示されるが、実際のMPDでは、多数のそのような部分が、存在してもよい。本実施例では、合計30分のコンテンツに対して、10分の持続時間の3つの周期が存在すると仮定することができる。各周期は、3つの異なるエンコーディングまたは表現を含有し、各表現は、10秒の持続時間のセグメントを含有する。したがって、周期内の各表現に対して、60個のセグメント、合計540個の異なるセグメントが存在する。exampleMPD.xmlのファイルサイズは、52キロバイトである。ライブメディアプレゼンテーションに対して、サーバ上のMPDは、新しいセグメントが追加される度に更新され、例えば、10秒毎である。本実施例では、3つのみの異なるコンテンツエンコーディングまたは表現が、周期内に提供されると仮定される。他の場合、サーバは、多数の異なる解像度、複数の異なるビットレート、複数の言語等を含有し得る。したがって、実施例の3つの異なるエンコーディングの代わりに、遥かに多数の表現が、利用可能であり得る。また、例示的MPDでは、30分のみのコンテンツが記述される。別のMPDは、例えば、3時間以上の長さである、スポーツイベントを記述する場合がある。第2の実施例では、15の表現および2.5時間のコンテンツが、MPDに記述されると仮定される場合がある。3つの表現および30分のコンテンツの第1の実施例と比較して、サーバ上に記憶されるMPDのサイズは、25によって乗算されているすなわち、コンテンツの持続時間の5倍によって乗算される表現の数の5倍。したがって、第2の実施例では、約1.3メガバイトのデータ52キロバイト×25のMPDが、サーバ上に記憶され、10秒毎に、提供および/または取得される必要があるであろう。そのような大きなファイルを、恐らく、数百のクライアントに、高頻度で提供および/または取得することは、大量の帯域幅を消費し得る。このように大量の帯域幅消費に対する可能性として考えられる解決策の1つは、圧縮アプリケーションによって、MPDを圧縮するものであり得る。しかしながら、ライブストリーミングの場合、クライアントは、典型的には、エンコードされた最新のセグメントの場所を見つけるために、MPDを約10秒毎にダウンロードし、MPDは、ストリーミングされたコンテンツに追加される、各新しいセグメントに伴って成長する。MPDの圧縮は、成長するMPDの問題を適切に解決しない。さらに、セグメント毎にMPDを圧縮および解凍するリソースコストは、有意となり得る。MPD内の情報の大部分は、MPDが更新される時、不変のままである。例えば、新しいセグメントが、周期内に追加される度に、Url要素のみ、各表現に追加される。例えば、図2のMPDでは、最大540個の異なるUrl要素が存在し、10秒毎に、3つのみ、追加されている。MPD内の他の情報は、典型的には、同一のままである。ある実施形態では、クライアントは、MPD情報の最後のダウンロード以降に実際に変更された情報のみダウンロードする。これは、図3に例証されており、サーバ120は、サーバ120から利用可能なメディアプレゼンテーションを記述する、MPD310を含む。クライアント140はまた、MPD320を含み、クライアントのMPD320は、クライアント140が、メディアプレゼンテーションに関して最新情報を有するように、サーバのMPD310と同期されるはずである。MPDの最後の更新以降に変更された情報を含む、デルタファイル330が、作成される恐らく、コンテンツプロバイダによって。クライアント140は、新しいセグメントが追加される度に、MPD全体をダウンロードするのではなく、新しいセグメントが、プレゼンテーションに追加される度に、デルタファイル330をダウンロードすることができる。すなわち、いったん、クライアント140が、MPD310全体をダウンロードすると、クライアント140は、デルタファイル330が更新される度に、単に、デルタファイル330をダウンロードすることができる。ある実施形態では、サーバ120は、HTTP1.1以降に準拠する標準的ウェブサーバである。すなわち、サーバ120は、XMLConfigurationAccessProtocolXCAP機能性またはSessionInitiationProtocolSIP機能性等の能力を有していない。XMLPathLanguageXPathは、XML文書の部分を定義するために、WorldWideWebConsortiumW3Cによって定義される言語である。RFC5261は、パッチのための要素スキーマタイプまたはXPathセレクタを使用するXML文書への変更を記述する。RFC5261に定義されるパッチは、<add>、<replace>、および<remove>である。これらは、要素または属性への変更を記述するために使用することができる。これらの要素スキーマタイプは、XMLデルタファイルXML文書への変更を記述する、XMLファイルを記述する、XMLスキーマにおいて使用することができる。したがって、ある実施形態では、MPDへの最新の更新に変更を有するもののみ、クライアントに記述することが可能である。同調したばかりのクライアントは、依然として、完全MPDをダウンロードし得る。しかしながら、他のクライアントは、デルタファイルのみダウンロードし、最新更新後に変更されたものを見つけ得る。MPD自体は、MPDが、可能性として、更新され得る、頻度を示す、最小更新持続時間を含有することができる。したがって、MPDが、10秒毎に更新される場合、クライアントは、最初に同調時、完全MPDをダウンロードし、その後、デルタファイルのみダウンロードするであろう。いくつかのタイプのデルタファイルを作成することが可能である。他の実施形態では、XPath以外の言語が、MPD内のポイントを識別するために使用され得る。以下は、239K帯域幅を伴う、Period3の表現内のURL要素が付加される、要素を示す、XPath式の実施例である。したがって、最後のセグメントに対するUrl要素が、本MPDに対して追加された後、これは、例えば、以下のような構文を伴う、RFC5261のパッチ動作を使用して、記述され得る。本実施例では、デルタは、3つの部分から成る。MPDへの変更が、追加されものから成るという事実は、<add>要素によって示される。sel属性は、要素が追加されるべき場所を示す。言い換えると、sel属性の値は、MPDにおいて、要素が追加されるべき場所を示す、XPath式である。この場合、SegmentInfoの最後の子ノードとして追加される。追加された要素は、<add>要素内のテキストである。したがって、実施例として、MPDに行なわれた変更は、以下の3つのデルタ式によって記述され得る。代替として、別の実施例として、MPDに行なわれた変更は、以下のXML言語によって記述され得る。この場合、sel属性は、XPath式を含有し、<add>要素内のテキストは、MPDに追加された要素を含有する。前述の第2の実施例は、総サイズ362バイトを有する。したがって、各クライアントが、図2の実施例におけるように、10秒毎に、約52キロバイトのものをダウンロードまたは受信する必要がある代わりに、ここでは、各クライアントは、362バイトのみダウンロードまたは受信する必要がある。これは、1/100未満のサイズであって、したがって、遥かに帯域幅効率的である。これは、同様に、クライアントが、10秒毎に、圧縮および解凍する必要がないことによって、計算リソースを節約し得る。デルタファイルの場所は、クライアントが、MPDの場所を判定するのと同一方法によって、クライアントによって取得され得る。代替として、デルタファイルの場所は、MPD内で参照され得る。1つのデルタファイルまたは複数の連続的に番号が付与されたデルタファイルが存在し得る。ある実施形態では、MPDは、MPDが、デルタファイルの使用をサポートすることを示す、インジケータを含むことができる。すなわち、デルタファイルを利用するために、クライアントは、デルタファイルが利用可能であることを把握する必要があり得る。クライアントは、MPD内のインジケータによって、本事実を認知する場合がある。例えば、MPD内の要素は、デルタファイルが、MPDへの更新を記述するために使用されていることを示す場合がある。要素の属性は、記憶されているデルタファイルの数、デルタファイル名、デルタファイルが更新される頻度、および/または他の情報を示す場合がある。他の実施形態では、インジケータは、更新が、後述のように、ある他の形態において利用可能であることを示す場合がある。クライアントは、デルタ更新を逸失していないことを把握する種々の手段を有する。MPDは、MPDが、可能性として、更新され得る頻度を示す、最小更新持続時間を含有することができる。MPDに記述される最小更新持続時間が存在する場合、クライアントは、MPDが、持続時間より頻繁に更新されていないことを把握し、クライアントは、持続時間より高い頻度でデルタファイルを検索する必要がない。したがって、MPDが、10秒毎に更新される場合、クライアントは、最初に同調時、完成MPDをダウンロードし、その後、10秒毎に、デルタファイルのみダウンロードするであろう。クライアントが、10秒毎に、デルタファイルのダウンロードを継続する場合、クライアントは、デルタファイルを逸失していないことを保証することができる。代替として、MPDが更新されるのと同時に、デルタファイルをクライアントに対してサーバ上で利用可能にすることができる。クライアントが、minimumUpdatePeriodの頻度において更新する場合、デルタファイル更新を逸失しないと把握する。また、デルタファイルの以前のバージョンは、クライアントが、最小更新頻度において、デルタファイルを要求する必要がないように記憶することができる。例えば、デルタファイルは、ファイル名delta.xmlを有することができる。delta.xmlの以前のバージョンは、delta1.xmlに記憶することができ、delta1.xmlの以前のバージョンは、delta2.xmlに記憶することができる。delta.xmlしたがって、delta1.xmlおよびdelta2.xmlは、クライアントが、あるバージョンを逸失しているかどうか把握することができるように、シーケンス番号を含有する。したがって、クライアントが、minimumUpdatePeriodの2倍、データファイルをダウンロードする場合、MPDへの3つ以上の異なる更新が存在しないことを確実であり得るが、0、1、または2更新が存在するかどうか確実に把握することはできない。デルタファイル内のシーケンスは、本指標を提供する。代替として、別の実施形態では、デルタファイルは、連続的に番号が付与されたファイル名が与えられ得、クライアントは、シーケンス内の番号を逸失していないことを確認し得る。例えば、クライアントが、10秒毎に同調する必要なくまたは、いかなる最小更新持続時間が発生する場合でも、デルタファイルの概念を利用するために複数のデルタファイルが作成され得る。例えば、最小更新が、10秒で発生する場合、delta_10が、MPDの直前のバージョンと比較して、MPDの最新バージョンに変更を有するものを指定する、デルタファイルであり得、delta_20は、MPDの2つの最新バージョンに変更を有するものを指定する、デルタファイルであり得る等となる。クライアントが、10秒毎に更新されたデルタファイルを所望する場合、クライアントは、delta_10ファイルをダウンロードし得、クライアントが、20秒毎に更新されたデルタファイルを所望する場合、クライアントは、delta_20ファイルをダウンロードし得る等となる。また、クライアントが、delta_10ファイルを逸失したことを認知する場合、例えば、クライアントは、delta_20ファイルをダウンロードし、サーバ上のMPDと同期したままとなり得る。デルタファイルの標準的命名規則が使用され得る、またはファイル名は、MPDに置かれ得る。別の代替実施形態では、デルタファイルは、異なるバージョン番号、バージョン名、またはデルタファイルが表す複数の更新のうち、どの更新であるかを示す、シーケンス番号が与えられる場合がある。この場合、デルタファイルは、必ずしも、周期的に作成される必要はないであろう。例えば、デルタファイルは、オリジナルMPDへの第1の改訂に対するrevision1、revision1以降の全更新を含む改訂に対するrevision2、revision2以降の全更新を含む改訂に対するrevision3等、名称が与えられる場合がある。改訂は、必ずしも、MPDによって記述されるコンテンツが更新される間隔に対応する、間隔で生成されないであろう。すなわち、コンテンツの新しいセグメントが、10秒毎に追加される場合、デルタファイルは、ある他の周期的間隔で作成される場合がある、または任意の定期的周期性を伴わずに作成される場合がある。クライアントが、そのMPDを更新することを所望する場合、クライアントは、単に、ダウンロードした最新のデルタファイルの改訂番号より大きい改訂番号を伴う、全デルタファイルをダウンロードし得る。クライアントは、任意の定期的周波数によって、デルタファイルをダウンロードする必要はないであろう。ある実施形態では、クライアントが、任意の理由から、デルタファイルの取得に失敗する場合、クライアントは、再び、MPD全体をダウンロードし得る。その後、クライアントは、デルタファイルのみのダウンロードを再開する場合がある。AddElementおよびDeleteElementコマンドは、MPDに追加またはそこから削除されたセグメント記述等、最も一般的デルタを記述することができるが、多くの他のコマンドも可能である。例えば、AddSibling、AddChild、AddParent、DeleteSiblingDeleteChild、DeleteParent、AddAttribute、ReplaceAttribute、RemoveAttribute等である。デルタファイルを有する代替として、クライアントが、部分的GETまたは類似メッセージを使用して、MPDの一部のみダウンロードし得るように、<delta>タグが、MPDの上部または下部の近傍に置かれ得る。すなわち、MPDの最後の更新以降、MPDに変更を有する情報は、deltaタグの開閉間に置かれ得る。クライアントは、次いで、デルタタグ内の情報のみ読み出し、MPDの残りは無視し得る。HTTP適応ストリーミングは、現在、クライアント制御され、前述のように、サーバは、標準的ウェブサーバである。しかしながら、将来的に、サーバは、付加的機能性を含んでもよい。したがって、ある実施形態では、クライアントは、最初に、MPDをダウンロードし、次いで、クライアントが、更新のために、サーバをチェックする代わりに、デルタファイルの形態またはある他の形態における更新が、サーバによって、クライアントにプッシュされ得る。サーバが付加的機能性を有する、別の実施形態では、クライアントが、デルタアプローチおよびMPDにアクセスするためのXPathの組み合わせを使用する代わりに、XCAPが、クライアントにMPDを提供するために使用され得る。この場合、デルタファイルは、準備される必要がないであろう。代わりに、予測可能または既知の識別子またはシーケンス番号が、MPD内のメタデータの各セグメントに与えられ得る。クライアントは、直接、XCAP対応サーバ上のMPDファイルにアクセスし、クライアントがダウンロードした最新要素に続く、MPD内の要素にポイントするためにXCAPGETを使用し得る。クライアントは、、次いで、そのポイントから開始する要素の指定された番号を読み出し得る。XML文書にアクセスするためのXCAP機構は、RFC4825に説明されている。代替として、サーバは、XCAPベースのメッセージを使用して、MPD更新をクライアントにプッシュし得る。サーバが付加的機能性を有する、別の代替では、サブスクリプション/通知モデルが、クライアントに、MPDへの変更を通知するために使用され得る。すなわち、クライアントは、MPDへの変更を通知されるようにサブクライブし得、サーバは、クライアントに、変更が生じると、任意の変更を通知し得る。サブスクリプション/通知モデルは、SIP:SUBSCRIBE/SIP:NOTIFYを使用して、またはHTTPに基づく、SIPの代替機構である、XDCPXMLDocumentCommandProtocolを使用して、実装することができる。これらの機構は両方とも、OMAXDMXMLDocumentManagement2.1Enabler仕様に説明されている。これらの機構をサポートするために、MPD用のApplicationUsageは、XDMServer内にMPDファイルをホストすることが要求される。そして、XDMClinetは、ApplicationUsageにおいて指定されるように、MPDファイルへのアクセスおよびそのサブスクライブを可能にするために、UEUserEquipment上に実装される必要がある。サーバが付加的機能性を有する、これらの代替のいずれにおいても、インジケータが、MPDへの更新の使用をサポートすることを示すために、MPDに含まれ得る。すなわち、デルタファイルのサポートを示す、前述のインジケータ同様に、インジケータは、サーバが、MPD更新をクライアントにプッシュする能力、XCAPを使用して、MPD更新をクライアントに提供する能力、サブスクリプション/通知モデルを使用して、クライアントにMPD更新を通知する能力、またはMPD更新をクライアントに提供するための他の能力を有することを示し得る。クライアントは、次いで、インジケータを解釈し、MPD全体を受信することなく、MPDの更新を受信するための適切なアクションを行なう適切な機能性を有し得る。図4aおよび4bは、前述のデルタファイルのために使用される場合がある、デルタスキーマの実施例を例証する。図5は、メディアプレゼンテーション記述情報を取得するための方法500の実施形態を例証する。ブロック510では、クライアントは、サーバ上の第1のMPD内の変更に関連する情報を取得する。ブロック520では、クライアントは、変更に関連する情報によって、クライアント上の第2のMPDを更新する。要するに、要素は、デルタファイルのサポートを示すために、MPDに追加することができる。MPDに追加される要素名は、deltaである場合がある。要素deltaは、正の整数値をとる、numberOfStoredDeltasと命名された属性を含有することができる。デルタファイル名は、delta.xmlである場合があり、その以前のバージョンは、delta1.xmlである場合がある。delta1.xmlの以前のバージョンは、delta2.xml等である場合がある。したがって、属性numberOfStoreddeltasの値が、3である場合、クライアントは、filesdelta.xml、delta1.xml、およびdelta2.xmlが、サーバ上に存在することを把握する。また、図4におけるスキーマは、デルタファイルのために使用され得る。任意の<add>、<replace>、または<remove>要素におけるsel属性の値は、有効XPath式であることができる。スキーマは、使用されるべきXPathのバージョンを示す、属性xpathVersionを含有する。デフォルト値は、1.0である。別のバージョンのXPathが使用される場合、xpathVersion属性の値を介して示され得る。クライアントが、デルタファイルのダウンロードに応じて、sel属性におけるXPath式にエラーを見つける場合、MPD全体をダウンロードすることができる。前述のクライアント、サーバ、および他の構成要素は、前述のアクションに関連する命令を実行可能な処理構成要素を含む場合がある。図6は、本明細書に開示される1つ以上の実施形態を実装するために好適な処理構成要素1310を含む、システム1300の実施例を例証する。プロセッサ1310中央処理ユニットまたはCPUと称され得るに加え、システム1300は、ネットワーク接続デバイス1320、ランダムアクセスメモリRAM1330、読取専用メモリROM1340、二次記憶装置1350、および入力/出力I/Oデバイス1360を含む場合がある。これらの構成要素は、バス1370を介して、相互に通信する場合がある。ある場合には、これらの構成要素のうちのいくつかは、存在しなくてもよく、あるいは相互または図示されない他の構成可能と種々の組み合わせにおいて、組み合わせられてもよい。これらの構成要素は、単一物理的エンティティまたは2つ以上の物理的エンティティ内に位置する場合がある。プロセッサ1310によって行なわれるように本明細書に説明される任意のアクションは、プロセッサ1310単独によって、あるいはデジタル信号プロセッサDSP1380等、図面に図示される、または図示されない1つ以上の構成要素と併せて、プロセッサ1310によって、行なわれる場合がある。DSP1380は、別個の構成要素として示されるが、DSP1380は、プロセッサ1310に組み込まれる場合がある。プロセッサ1310は、ネットワーク接続デバイス1320、RAM1330、ROM1340、または二次記憶装置1350ハードディスク、フロッピー登録商標ディスク、または光ディスク等の種々のディスクベースのシステムを含む場合があるからアクセスする場合がある、命令、コード、コンピュータプログラム、あるいはスクリプトを実行する。1つのみのCPU1310が示されるが、複数のプロセッサが、存在してもよい。したがって、命令は、プロセッサによって実行されるように論じられ得るが、命令は、同時に、連続的に、または別様に、1つまたは複数のプロセッサによって、実行されてもよい。プロセッサ1310は、1つ以上のCPUチップとして、実装されてもよい。ネットワーク接続デバイス1320は、モデム、モデム群、Ethernet登録商標デバイス、ユニバーサルシリアルバスUSBインターフェースデバイス、シリアルインターフェース、トークンリングデバイス、光ファイバ分散データインターフェースFDDIデバイス、無線ローカルエリアネットワークWLANデバイス、符号分割多重アクセスCDMAデバイス等の無線送受信機デバイス、モバイル通信のためのグローバルシステムGSM登録商標無線送受信機デバイス、ワールドワイドインターオペラビリティフォーマイクロウェーブアクセスWiMAXデバイス、および/またネットワークに接続するための他の周知のデバイスの形態をとってもよい。これらのネットワーク接続デバイス1320によって、プロセッサ1310が、インターネットまたは1つ以上の電気通信ネットワーク、あるいはプロセッサ1310が情報を受信する場合がある、またはプロセッサ1310が情報を出力する場合がある、他のネットワークと通信可能になってもよい。ネットワーク接続デバイス1320はまた、データを無線で伝送および/または受信可能な1つ以上の送受信機構成要素1325を含む場合がある。RAM1330は、揮発性データを記憶し、かつ恐らくは、プロセッサ1310によって実行される命令を記憶するために使用される場合がある。ROM1340は、典型的には、二次記憶装置1350のメモリ容量より小さいメモリ容量を有する、不揮発性メモリデバイスである。ROM1340は、命令と、恐らくは、命令の実行の間に読み取られるデータを記憶するために使用される場合がある。RAM1330およびROM1340両方へのアクセスは、典型的には、二次記憶装置1350より高速である。二次記憶装置1350は、典型的には、1つ以上のディスクドライブまたはテープドライブから成り、データの不揮発性記憶のため、またはRAM1330が、全作業データを保持するために十分に大きくない場合、超過データ記憶デバイスとして、使用される場合がある。二次記憶装置1350は、そのようなプログラムが、実行のために選択されると、RAM1330にロードされる、プログラムを記憶するために使用されてもよい。I/Oデバイス1360は、液晶ディスプレイLCD、タッチスクリーンディスプレイ、キーボード、キーパッド、スイッチ、ダイヤル、マウス、トラックボール、音声認識装置、カードリーダ、紙テープ読取機、プリンタ、ビデオモニタ、または他の周知の入力/出力デバイスを含んでもよい。また、送受信機1325は、ネットワーク接続デバイス1320の構成要素である代わりに、またはそれに加え、I/Oデバイス1360の構成可能であると見なされる場合がある。ある実施形態では、メディアプレゼンテーション記述情報を得るための方法が、提供される。方法は、クライアントが、サーバ上の第1のMPD内の変更に関連する情報を取得するステップを含む。方法はさらに、クライアントが、変更に関連する情報によって、クライアント上の第2のMPDを更新するステップを含む。別の実施形態では、クライアントが、提供される。クライアントは、クライアントが、サーバ上の第1のMPD内の変更に関連する情報を取得するように構成され、クライアントが、変更に関連する情報によって、クライアント上の第2のMPDを更新するように構成される、プロセッサを含む。以下は、あらゆる目的のために、参照することによって本明細書に組み込まれる。3GPPTechnicalSpecificationTS26.2343GPPTS26.244,ISO/IEC14496-12,InternetEngineeringTaskForceIETFRequestforCommentsRFC5874、およびIETFRFC5261。いくつかの実施形態が、本開示に提供されたが、開示されるシステムおよび方法は、本開示の範囲から逸脱することなく、多くの他の具体的形態において具現化されてもよいことを理解されたい。本実施例は、制限ではなく、例証として見なされるべきであって、その意図は、本明細書に与えられる詳細に限定されない。例えば、種々の要素または構成要素は、別のシステムに組み合わせられる、または統合されてもよく、あるいはある特徴は、省略される、または実装されなくてもよい。また、離散または別個として、種々の実施形態に説明および例証された技法、システム、サブシステムおよび方法は、本開示の範囲から逸脱することなく、他のシステム、モジュール、技法、または方法と組み合わせられる、あるいは統合されてもよい。連結される、または直接連結される、または相互に通信するように図示あるいは論じられる他のアイテムは、電気的に、機械的に、または別様にかを問わず、いくつかのインターフェース、デバイス、または中間構成要素を通して、間接的に連結される、あるいは通信してもよい。変更、代用、および改変の他の実施例は、当業者によって解明され、本明細書に開示される精神および範囲から逸脱することなく、行なわれ得る。"