JP5658820B2 - Ｈｔｔｐストリーミングのためのメディアプレゼンテーション記述デルタファイル - Google Patents

Description

３^ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ（３ＧＰＰ）は、ＨＴＴＰストリーミングとして知られる特徴を開発しており、それによって、携帯電話、携帯情報端末、ハンドヘルドまたはラップトップコンピュータ、デスクトップコンピュータ、セットトップボックス、ネットワーク機器、および類似デバイスは、ハイパーテキスト転送プロトコル（ＨＴＴＰ）を介して、ストリーミングメディアコンテンツを受信することができる。ＨＴＴＰストリーミングデータを受信することができる、任意のデバイスは、本明細書では、クライアントと称されるであろう。ＨＴＴＰを介して、そのようなクライアントデバイスに提供される場合がある、コンテンツは、ストリーミングビデオ、ストリーミングオーディオ、および他のマルチメディアコンテンツを含むことができる。ある場合には、コンテンツは、準備され、次いで、ＨＴＴＰを介して、後のストリーミングのために、標準的ウェブサーバ上に記憶される。他の場合には、ライブまたはほぼライブのストリーミングが、使用される場合があり、それによって、コンテンツは、コンテンツ作成時またはほぼその時に、ウェブサーバ上に置かれる。いずれの場合も、クライアントは、標準的ウェブブラウジング技術を使用して、任意の所望の時間に、ストリーミングされたコンテンツを受信することができる。

本開示のより完全な理解のために、次に、同一参照番号は、同一部品を表す、付随の図面および発明を実施するための形態と併せて、以下の簡単な説明を参照する。

最初に、本開示の１つ以上の実施形態の例証的実装が、以下に提供されるが、開示されるシステムおよび／または方法は、現在既知または既存であるかを問わ ず、任意の数の技法を使用して、実装されてもよいことを理解されたい。本開示は、本明細書に例証および説明される例示的設計ならびに実装を含む、以下に例証される例証的実装、図面、および技法にいかようにも限定されるべきではなく、添付の請求項の範囲とともに、均等物のその全範囲内で修正されてもよい。
本発明は、例えば、以下を提供する。
（項目１）
メディアプレゼンテーション記述情報を得るための方法であって、
クライアントが、サーバ上の第１のメディアプレゼンテーション記述（ＭＰＤ）内の変更に関連する情報を取得するステップと、
上記クライアントが、上記変更に関連する情報によって、上記クライアント上の第２のＭＰＤを更新するステップと
を含む、方法。
（項目２）
上記サーバは、ハイパーテキスト転送プロトコル（ＨＴＴＰ）規格１．１以降に準拠する標準的ウェブサーバである、項目１に記載の方法。
（項目３）
上記変更に関連する情報は、
上記変更に関連する情報と、
上記変更に関連する情報によって行なわれるアクションを指定するコマンドと、
上記第２のＭＰＤ内の上記コマンドが適用されるべき場所を記述する式と
のうちの少なくとも１つを含む、デルタファイル内に記憶される、項目１に記載の方法。
（項目４）
上記式は、ＸＰａｔｈ式である、項目３に記載の方法。
（項目５）
上記クライアントは、上記第１のＭＰＤと関連付けられたセッション開始後、上記第１のＭＰＤ全体を取得し、上記第１のＭＰＤ全体を取得後、周期的間隔において、上記デルタファイルを取得する、項目３に記載の方法。
（項目６）
複数のデルタファイルは、上記クライアントに利用可能であって、上記複数のデルタファイルはそれぞれ、上記変更に関連する異なる情報量を含有し、上記クライアントは、上記複数のデルタファイルのうちの１つ以上を選択する、項目３に記載の方法。
（項目７）
シーケンスまたはバージョン番号は、上記複数のデルタファイルのうちのいずれを選択すべきかを判定するために使用される、項目６に記載の方法。
（項目８）
上記クライアントが、上記デルタファイルの取得に失敗する、または上記デルタファイル内にエラーを識別すると、上記クライアントは、上記第１のＭＰＤ全体を取得し、その後、上記デルタファイルを取得する、項目３に記載の方法。
（項目９）
上記変更に関連する情報は、上記第１のＭＰＤ内の拡張マークアップ言語（ＸＭＬ）タグ内に記憶され、上記クライアントは、上記クライアントが、上記第２のＭＰＤの更新を所望すると、上記タグの要素のみ読み出す、項目１に記載の方法。
（項目１０）
上記ＸＭＬ構成アクセスプロトコル（ＸＣＡＰ）に準拠する識別子は、上記変更に関連する情報と関連付けられ、ＸＣＡＰベースのメッセージは、上記クライアントへの上記変更に関連する情報にアクセスするために使用される、項目１に記載の方法。
（項目１１）
上記クライアントは、上記変更に関連する情報が、上記サーバによって、上記クライアントにプッシュされるのに応じて、上記変更に関連する情報を受信する、項目１に記載の方法。
（項目１２）
上記クライアントは、上記変更に関連する情報を受信するようにサブスクライブし、上記変更に関連する情報が利用可能になると、通知される、項目１に記載の方法。
（項目１３）
上記第１のＭＰＤは、上記第１のＭＰＤが、上記第１のＭＰＤ全体を上記クライアントに提供することなく、上記第１のＭＰＤの更新を上記クライアントに提供するステップをサポートすることを示す、インジケータを含む、項目１に記載の方法。
（項目１４）
上記インジケータは、
上記変更に関連する情報を提供するためのデルタファイルの使用と、
上記変更に関連する情報にアクセスするためのＸＣＡＰメッセージの使用と、
上記変更に関連する情報を提供するための上記サーバからのプシュの使用と、
上記変更に関連する情報にアクセスするためのサブスクリプション／通知モデルの使用と
のうちの少なくとも１つを示す、項目１３に記載の方法。
（項目１５）
クライアントが、サーバ上の第１のメディアプレゼンテーション記述（ＭＰＤ）内の変更に関連する情報を取得するように構成され、上記クライアントが、上記変更に関連する情報によって、上記クライアント上の第２のＭＰＤを更新するように構成される、プロセッサを含む、クライアント。
（項目１６）
上記サーバは、ハイパーテキスト転送プロトコル（ＨＴＴＰ）規格１．１以降に準拠する標準的ウェブサーバである、項目１５に記載のクライアント。
（項目１７）
上記変更に関連する情報は、
上記変更に関連する情報と、
上記変更に関連する情報によって行なわれるアクションを指定するコマンドと、
上記第２のＭＰＤ内の上記コマンドが適用されるべき場所を記述する式と
のうちの少なくとも１つを含む、デルタファイル内に記憶される、項目１５に記載のクライアント。
（項目１８）
上記式は、ＸＰａｔｈ式である、項目１７に記載のクライアント。
（項目１９）
上記クライアントは、上記第１のＭＰＤと関連付けられたセッション開始後、上記第１のＭＰＤ全体を取得し、上記第１のＭＰＤ全体を取得後、周期的間隔において、上記デルタファイルを取得する、項目１７に記載のクライアント。
（項目２０）
複数のデルタファイルは、上記クライアントに利用可能であって、上記複数のデルタファイルはそれぞれ、上記変更に関連する異なる情報量を含有し、上記クライアントは、上記複数のデルタファイルのうちの１つを選択する、項目１７に記載のクライアント。
（項目２１）
シーケンスまたはバージョン番号は、上記複数のデルタファイルのうちのいずれを選択すべきかを判定するために使用される、項目２０に記載のクライアント。
（項目２２）
上記クライアントが、上記デルタファイルの取得に失敗する、または上記デルタファイル内にエラーを識別すると、上記クライアントは、上記第１のＭＰＤ全体を取得し、その後、上記デルタファイルを取得する、項目１７に記載のクライアント。
（項目２３）
上記変更に関連する情報は、上記第１のＭＰＤ内の拡張マークアップ言語（ＸＭＬ）タグ内に記憶され、上記クライアントは、上記クライアントが、上記第２のＭＰＤの更新を所望すると、上記タグの要素のみ読み出す、項目１５に記載のクライアント。
（項目２４）
上記ＸＭＬ構成アクセスプロトコル（ＸＣＡＰ）に準拠する識別子は、上記変更に関連する情報と関連付けられ、ＸＣＡＰベースのメッセージは、上記クライアントへの上記変更に関連する情報にアクセスするために使用される、項目１５に記載のクライアント。
（項目２５）
上記クライアントは、上記変更に関連する情報が、上記サーバによって、上記クライアントにプッシュされるのに応じて、上記変更に関連する情報を受信する、項目１５に記載のクライアント。
（項目２６）
上記クライアントは、上記変更に関連する情報を受信するようにサブスクライブし、上記変更に関連する情報が利用可能になると、通知される、項目１５に記載のクライアント。
（項目２７）
上記第１のＭＰＤは、上記第１のＭＰＤが、上記第１のＭＰＤ全体を上記クライアントに提供することなく、上記第１のＭＰＤの更新を上記クライアントに提供するステップをサポートすることを示す、インジケータを含む、項目１５に記載のクライアント。
（項目２８）
上記インジケータは、
上記変更に関連する情報を提供するためのデルタファイルの使用と、
上記変更に関連する情報にアクセスするためのＸＣＡＰメッセージの使用と、
上記変更に関連する情報を提供するための上記サーバからのプシュの使用と、
上記変更に関連する情報にアクセスするためのサブスクリプション／通知モデルの使用と
のうちの少なくとも１つを示す、項目２７に記載のクライアント。

図１は、適応ＨＴＴＰストリーミングのためのシステムアーキテクチャである。 図２は、本開示のある実施形態による、メディアプレゼンテーション記述文書の実施例である。 図３は、本開示のある実施形態による、適応ＨＴＴＰストリーミングのためのシステムアーキテクチャである。 図４ａおよび４ｂは、本開示のある実施形態による、デルタスキーマを例証する。 図４ａおよび４ｂは、本開示のある実施形態による、デルタスキーマを例証する。 図５は、本開示のある実施形態による、メディアプレゼンテーション記述情報を得るための方法を例証する、流れ図である。 図６は、本開示のいくつかの実施形態を実装するために好適なプロセッサおよび関連構成要素を例証する。

図１は、適応ＨＴＴＰストリーミングのための典型的システムアーキテクチャを例証する。コンテンツ準備相１１０では、メディアプレゼンテーションが、ＨＴＴＰストリーミングのために準備される。コンテンツは、次いで、ＨＴＴＰストリーミングサーバ１２０上、および／または可能性として、ＨＴＴＰキャッシュ１３０内に記憶される。ＨＴＴＰストリーミングクライアント１４０は、ＨＴＴＰＧＥＴ要求または類似メッセージを使用して、サーバ１２０またはキャッシュ１３０から、メディアプレゼンテーションをダウンロードする場合がある。

メディアプレゼンテーションは、３ＧＰＰ仕様において、メディアプレゼンテーション記述（ＭＰＤ）と呼ばれる、拡張マークアップ言語（ＸＭＬ）文書において記述される場合がある。ＭＰＤは、クライアントに、ビットレート、コーデック、画面解像度、および言語等、メディアコンテンツがエンコードされる、フォーマットを知らせる、メタデータを含有する。そのようなパラメータの各異なる組み合わせは、コンテンツの表現と称することができ、複数の異なる表現が、同一コンテンツを記述してもよい。これによって、クライアントは、可能性として、その画面解像度、現在のチャネル帯域幅、現在のチャネル受信条件、ユーザの言語選好、および他のパラメータに基づいて、特定の表現を選択可能となる。

ライブストリーミングが使用されない場合、プレゼンテーション全体を記述するＭＰＤは、クライアントに提供される場合があり、クライアントは、プレゼンテーションを通して、ＭＰＤ内でメタデータを使用する場合がある。しかしながら、ライブストリーミングの場合、メタデータは、未だ既知ではない場合があるため、ストリーミングの開始に先立って、メディアストリーム全体に関するメタデータを提供することは可能でなくてもよい。また、ストリーミングセッションに関連するパラメータは、セッションの過程の間、変化してもよい。例えば、クライアントは、受信不良地域に移動し、データレートが、減速し得る。そのような場合、クライアントは、より低いビットレートを伴う表現に切り替える必要があり得る。別の実施例では、クライアントデバイスは、ストリーミングされたコンテンツの表示を肖像画から風景モードに切り替えるように選択してもよく、その場合、異なる表現が要求され得る。

これらの理由から、クライアントに、プレゼンテーション全体を記述するＭＰＤを提供することが不可能であり得る。そのような場合、メディアプレゼンテーションは、セグメントに分割されてもよく、ＭＰＤの一部は、各セグメントを記述してもよい。すなわち、ＨＴＴＰストリーミングの場合、メディアは、ライブコンテンツの再生出力が、ライブエンコーディングにあまり遅れをとらないように、かつクライアントが、前述のように、チャネル条件または他の要因に従って、適応的にエンコーディングする、異なるコンテンツに切り替えることができるように、１回に１つのセグメント、メディアがダウンロードされてもよい。

セグメントは、ＭＰＤにおける「Ｕｒｌ」ＸＭＬ要素内の情報とともにアドレス可能である。「Ｕｒｌ」要素は、セグメントのＵＲＬを含有し、ＨＴＴＰＧＥＴ要求の範囲ヘッダと併用され得る、「範囲」属性によって制限されてもよい。コンテンツの新しいセグメントは、１０秒毎等、定期的間隔において、追加されてもよく、対応する新しい情報は、コンテンツの各新しいセグメントが追加されるのに伴って、ＭＰＤに追加されてもよい。したがって、ＭＰＤのサイズは、コンテンツのストリーミングが進行するのに伴って、成長してもよい。

例示的ＭＰＤは、図２に例証されており、「ｅｘａｍｐｌｅＭＰＤ．ｘｍｌ」と称することができる。例示的ＭＰＤの複数の部分２１０はそれぞれ、メディアプレゼンテーションのセグメントを記述する。図中の空間を節約するために、２つのそのような部分２１０のみ示されるが、実際のＭＰＤでは、多数のそのような部分が、存在してもよい。本実施例では、合計３０分のコンテンツに対して、１０分の持続時間の３つの周期が存在すると仮定することができる。各周期は、３つの異なるエンコーディングまたは表現を含有し、各表現は、１０秒の持続時間のセグメントを含有する。したがって、周期内の各表現に対して、６０個のセグメント、合計５４０個の異なるセグメントが存在する。ｅｘａｍｐｌｅＭＰＤ．ｘｍｌのファイルサイズは、５２キロバイトである。ライブメディアプレゼンテーションに対して、サーバ上のＭＰＤは、新しいセグメントが追加される度に更新され、例えば、１０秒毎である。

本実施例では、３つのみの異なるコンテンツエンコーディングまたは表現が、周期内に提供されると仮定される。他の場合、サーバは、多数の異なる解像度、複数の異なるビットレート、複数の言語等を含有し得る。したがって、実施例の３つの異なるエンコーディングの代わりに、遥かに多数の表現が、利用可能であり得る。また、例示的ＭＰＤでは、３０分のみのコンテンツが記述される。別のＭＰＤは、例えば、３時間以上の長さである、スポーツイベントを記述する場合がある。

第２の実施例では、１５の表現および２．５時間のコンテンツが、ＭＰＤに記述されると仮定される場合がある。３つの表現および３０分のコンテンツの第１の実施例と比較して、サーバ上に記憶されるＭＰＤのサイズは、２５によって乗算されている（すなわち、コンテンツの持続時間の５倍によって乗算される表現の数の５倍）。したがって、第２の実施例では、約１．３メガバイトのデータ（５２キロバイト×２５）のＭＰＤが、サーバ上に記憶され、１０秒毎に、提供および／または取得される必要があるであろう。そのような大きなファイルを、恐らく、数百のクライアントに、高頻度で提供および／または取得することは、大量の帯域幅を消費し得る。

このように大量の帯域幅消費に対する可能性として考えられる解決策の１つは、圧縮アプリケーションによって、ＭＰＤを圧縮するものであり得る。しかしながら、ライブストリーミングの場合、クライアントは、典型的には、エンコードされた最新のセグメントの場所を見つけるために、ＭＰＤを約１０秒毎にダウンロードし、ＭＰＤは、ストリーミングされたコンテンツに追加される、各新しいセグメントに伴って成長する。ＭＰＤの圧縮は、成長するＭＰＤの問題を適切に解決しない。さらに、セグメント毎にＭＰＤを圧縮および解凍するリソースコストは、有意となり得る。

ＭＰＤ内の情報の大部分は、ＭＰＤが更新される時、不変のままである。例えば、新しいセグメントが、周期内に追加される度に、「Ｕｒｌ」要素のみ、各表現に追加される。例えば、図２のＭＰＤでは、最大５４０個の異なる「Ｕｒｌ」要素が存在し、１０秒毎に、３つのみ、追加されている。ＭＰＤ内の他の情報は、典型的には、同一のままである。

ある実施形態では、クライアントは、ＭＰＤ情報の最後のダウンロード以降に実際に変更された情報のみダウンロードする。これは、図３に例証されており、サーバ１２０は、サーバ１２０から利用可能なメディアプレゼンテーションを記述する、ＭＰＤ３１０を含む。クライアント１４０はまた、ＭＰＤ３２０を含み、クライアントのＭＰＤ３２０は、クライアント１４０が、メディアプレゼンテーションに関して最新情報を有するように、サーバのＭＰＤ３１０と同期されるはずである。ＭＰＤの最後の更新以降に変更された情報を含む、デルタファイル３３０が、作成される（恐らく、コンテンツプロバイダによって）。クライアント１４０は、新しいセグメントが追加される度に、ＭＰＤ全体をダウンロードするのではなく、新しいセグメントが、プレゼンテーションに追加される度に、デルタファイル３３０をダウンロードすることができる。すなわち、いったん、クライアント１４０が、ＭＰＤ３１０全体をダウンロードすると、クライアント１４０は、デルタファイル３３０が更新される度に、単に、デルタファイル３３０をダウンロードすることができる。

ある実施形態では、サーバ１２０は、ＨＴＴＰ１．１以降に準拠する標準的ウェブサーバである。すなわち、サーバ１２０は、ＸＭＬ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ（ＸＣＡＰ）機能性またはＳｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＳＩＰ）機能性等の能力を有していない。

ＸＭＬ Ｐａｔｈ Ｌａｎｇｕａｇｅ（ＸＰａｔｈ）は、ＸＭＬ文書の部分を定義するために、Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ Ｃｏｎｓｏｒｔｉｕｍ（Ｗ３Ｃ）によって定義される言語である。ＲＦＣ５２６１は、「パッチ」のための要素スキーマタイプまたはＸＰａｔｈセレクタを使用するＸＭＬ文書への変更を記述する。ＲＦＣ５２６１に定義される「パッチ」は、＜ａｄｄ＞、＜ｒｅｐｌａｃｅ＞、および＜ｒｅｍｏｖｅ＞である。これらは、要素または属性への変更を記述するために使用することができる。これらの要素スキーマタイプは、ＸＭＬ「デルタファイル」（ＸＭＬ文書への変更を記述する、ＸＭＬファイル）を記述する、ＸＭＬスキーマにおいて使用することができる。したがって、ある実施形態では、ＭＰＤへの最新の更新に変更を有するもののみ、クライアントに記述することが可能である。同調したばかりのクライアントは、依然として、完全ＭＰＤをダウンロードし得る。しかしながら、他のクライアントは、デルタファイルのみダウンロードし、最新更新後に変更されたものを見つけ得る。ＭＰＤ自体は、ＭＰＤが、可能性として、更新され得る、頻度を示す、「最小更新」持続時間を含有することができる。したがって、ＭＰＤが、１０秒毎に更新される場合、クライアントは、最初に同調時、完全ＭＰＤをダウンロードし、その後、デルタファイルのみダウンロードするであろう。いくつかのタイプのデルタファイルを作成することが可能である。他の実施形態では、ＸＰａｔｈ以外の言語が、ＭＰＤ内のポイントを識別するために使用され得る。

以下は、２３９Ｋ帯域幅を伴う、Ｐｅｒｉｏｄ３の表現内のＵＲＬ要素が付加される、要素を示す、ＸＰａｔｈ式の実施例である。

したがって、最後のセグメントに対する「Ｕｒｌ」要素が、本ＭＰＤに対して追加された後、これは、例えば、以下のような構文を伴う、ＲＦＣ５２６１のパッチ動作を使用して、記述され得る。

本実施例では、「デルタ」は、３つの部分から成る。ＭＰＤへの変更が、追加されものから成るという事実は、＜ａｄｄ＞要素によって示される。「ｓｅｌ」属性は、要素が追加されるべき場所を示す。言い換えると、「ｓｅｌ」属性の値は、ＭＰＤにおいて、要素が追加されるべき場所を示す、ＸＰａｔｈ式である。この場合、ＳｅｇｍｅｎｔＩｎｆｏの最後の子ノードとして追加される。追加された要素は、＜ａｄｄ＞要素内のテキストである。したがって、実施例として、ＭＰＤに行なわれた変更は、以下の３つのデルタ式によって記述され得る。

代替として、別の実施例として、ＭＰＤに行なわれた変更は、以下のＸＭＬ言語によって記述され得る。

この場合、「ｓｅｌ」属性は、ＸＰａｔｈ式を含有し、＜ａｄｄ＞要素内のテキストは、ＭＰＤに追加された要素を含有する。

前述の第２の実施例は、総サイズ３６２バイトを有する。したがって、各クライアントが、図２の実施例におけるように、１０秒毎に、約５２キロバイトのものをダウンロードまたは受信する必要がある代わりに、ここでは、各クライアントは、３６２バイトのみダウンロードまたは受信する必要がある。これは、１／１００未満のサイズであって、したがって、遥かに帯域幅効率的である。これは、同様に、クライアントが、１０秒毎に、圧縮および解凍する必要がないことによって、計算リソースを節約し得る。

デルタファイルの場所は、クライアントが、ＭＰＤの場所を判定するのと同一方法によって、クライアントによって取得され得る。代替として、デルタファイルの場所は、ＭＰＤ内で参照され得る。１つのデルタファイルまたは複数の連続的に番号が付与されたデルタファイルが存在し得る。

ある実施形態では、ＭＰＤは、ＭＰＤが、デルタファイルの使用をサポートすることを示す、インジケータを含むことができる。すなわち、デルタファイルを利用するために、クライアントは、デルタファイルが利用可能であることを把握する必要があり得る。クライアントは、ＭＰＤ内のインジケータによって、本事実を認知する場合がある。例えば、ＭＰＤ内の要素は、デルタファイルが、ＭＰＤへの更新を記述するために使用されていることを示す場合がある。要素の属性は、記憶されているデルタファイルの数、デルタファイル名、デルタファイルが更新される頻度、および／または他の情報を示す場合がある。他の実施形態では、インジケータは、更新が、後述のように、ある他の形態において利用可能であることを示す場合がある。

クライアントは、デルタ更新を逸失していないことを把握する種々の手段を有する。ＭＰＤは、ＭＰＤが、可能性として、更新され得る頻度を示す、「最小更新」持続時間を含有することができる。ＭＰＤに記述される最小更新持続時間が存在する場合、クライアントは、ＭＰＤが、持続時間より頻繁に更新されていないことを把握し、クライアントは、持続時間より高い頻度でデルタファイルを検索する必要がない。したがって、ＭＰＤが、１０秒毎に更新される場合、クライアントは、最初に同調時、完成ＭＰＤをダウンロードし、その後、１０秒毎に、デルタファイルのみダウンロードするであろう。クライアントが、１０秒毎に、デルタファイルのダウンロードを継続する場合、クライアントは、デルタファイルを逸失していないことを保証することができる。

代替として、ＭＰＤが更新されるのと同時に、デルタファイルをクライアントに対してサーバ上で利用可能にすることができる。クライアントが、ｍｉｎｉｍｕｍＵｐｄａｔｅＰｅｒｉｏｄの頻度において更新する場合、デルタファイル更新を逸失しないと把握する。また、デルタファイルの以前のバージョンは、クライアントが、最小更新頻度において、デルタファイルを要求する必要がないように記憶することができる。例えば、デルタファイルは、ファイル名ｄｅｌｔａ．ｘｍｌを有することができる。ｄｅｌｔａ．ｘｍｌの以前のバージョンは、ｄｅｌｔａ-１．ｘｍｌに記憶することができ、ｄｅｌｔａ-１．ｘｍｌの以前のバージョンは、ｄｅｌｔａ-２．ｘｍｌに記憶することができる。ｄｅｌｔａ．ｘｍｌ（したがって、ｄｅｌｔａ-１．ｘｍｌおよびｄｅｌｔａ-２．ｘｍｌ）は、クライアントが、あるバージョンを逸失しているかどうか把握することができるように、シーケンス番号を含有する。したがって、クライアントが、ｍｉｎｉｍｕｍＵｐｄａｔｅＰｅｒｉｏｄの２倍、データファイルをダウンロードする場合、ＭＰＤへの３つ以上の異なる更新が存在しないことを確実であり得るが、０、１、または２更新が存在するかどうか確実に把握することはできない。デルタファイル内のシーケンスは、本指標を提供する。

代替として、別の実施形態では、デルタファイルは、連続的に番号が付与されたファイル名が与えられ得、クライアントは、シーケンス内の番号を逸失していないことを確認し得る。例えば、クライアントが、１０秒毎に同調する必要なく（または、いかなる最小更新持続時間が発生する場合でも）、デルタファイルの概念を利用するために複数のデルタファイルが作成され得る。例えば、最小更新が、１０秒で発生する場合、「ｄｅｌｔａ＿１０」が、ＭＰＤの直前のバージョンと比較して、ＭＰＤの最新バージョンに変更を有するものを指定する、デルタファイルであり得、「ｄｅｌｔａ＿２０」は、ＭＰＤの２つの最新バージョンに変更を有するものを指定する、デルタファイルであり得る等となる。クライアントが、１０秒毎に更新されたデルタファイルを所望する場合、クライアントは、ｄｅｌｔａ＿１０ファイルをダウンロードし得、クライアントが、２０秒毎に更新されたデルタファイルを所望する場合、クライアントは、ｄｅｌｔａ＿２０ファイルをダウンロードし得る等となる。また、クライアントが、ｄｅｌｔａ＿１０ファイルを逸失したことを認知する場合、例えば、クライアントは、ｄｅｌｔａ＿２０ファイルをダウンロードし、サーバ上のＭＰＤと同期したままとなり得る。デルタファイルの標準的命名規則が使用され得る、またはファイル名は、ＭＰＤに置かれ得る。

別の代替実施形態では、デルタファイルは、異なるバージョン番号、バージョン名、またはデルタファイルが表す複数の更新のうち、どの更新であるかを示す、シーケンス番号が与えられる場合がある。この場合、デルタファイルは、必ずしも、周期的に作成される必要はないであろう。例えば、デルタファイルは、オリジナルＭＰＤへの第１の改訂に対する「ｒｅｖｉｓｉｏｎ１」、「ｒｅｖｉｓｉｏｎ１」以降の全更新を含む改訂に対する「ｒｅｖｉｓｉｏｎ２」、「ｒｅｖｉｓｉｏｎ２」以降の全更新を含む改訂に対する「ｒｅｖｉｓｉｏｎ３」等、名称が与えられる場合がある。改訂は、必ずしも、ＭＰＤによって記述されるコンテンツが更新される間隔に対応する、間隔で生成されないであろう。すなわち、コンテンツの新しいセグメントが、１０秒毎に追加される場合、デルタファイルは、ある他の周期的間隔で作成される場合がある、または任意の定期的周期性を伴わずに作成される場合がある。クライアントが、そのＭＰＤを更新することを所望する場合、クライアントは、単に、ダウンロードした最新のデルタファイルの改訂番号より大きい改訂番号を伴う、全デルタファイルをダウンロードし得る。クライアントは、任意の定期的周波数によって、デルタファイルをダウンロードする必要はないであろう。

ある実施形態では、クライアントが、任意の理由から、デルタファイルの取得に失敗する場合、クライアントは、再び、ＭＰＤ全体をダウンロードし得る。その後、クライアントは、デルタファイルのみのダウンロードを再開する場合がある。

ＡｄｄＥｌｅｍｅｎｔおよびＤｅｌｅｔｅＥｌｅｍｅｎｔコマンドは、ＭＰＤに追加またはそこから削除されたセグメント記述等、最も一般的デルタを記述することができるが、多くの他のコマンドも可能である。例えば、ＡｄｄＳｉｂｌｉｎｇ、ＡｄｄＣｈｉｌｄ、ＡｄｄＰａｒｅｎｔ、ＤｅｌｅｔｅＳｉｂｌｉｎｇＤｅｌｅｔｅＣｈｉｌｄ、ＤｅｌｅｔｅＰａｒｅｎｔ、ＡｄｄＡｔｔｒｉｂｕｔｅ、ＲｅｐｌａｃｅＡｔｔｒｉｂｕｔｅ、ＲｅｍｏｖｅＡｔｔｒｉｂｕｔｅ等である。

デルタファイルを有する代替として、クライアントが、部分的ＧＥＴまたは類似メッセージを使用して、ＭＰＤの一部のみダウンロードし得るように、＜ｄｅｌｔａ＞タグが、ＭＰＤの上部または下部の近傍に置かれ得る。すなわち、ＭＰＤの最後の更新以降、ＭＰＤに変更を有する情報は、ｄｅｌｔａタグの開閉間に置かれ得る。クライアントは、次いで、デルタタグ内の情報のみ読み出し、ＭＰＤの残りは無視し得る。

ＨＴＴＰ適応ストリーミングは、現在、クライアント制御され、前述のように、サーバは、標準的ウェブサーバである。しかしながら、将来的に、サーバは、付加的機能性を含んでもよい。したがって、ある実施形態では、クライアントは、最初に、ＭＰＤをダウンロードし、次いで、クライアントが、更新のために、サーバをチェックする代わりに、デルタファイルの形態またはある他の形態における更新が、サーバによって、クライアントにプッシュされ得る。

サーバが付加的機能性を有する、別の実施形態では、クライアントが、「デルタ」アプローチおよびＭＰＤにアクセスするためのＸＰａｔｈの組み合わせを使用する代わりに、ＸＣＡＰが、クライアントにＭＰＤを提供するために使用され得る。この場合、デルタファイルは、準備される必要がないであろう。代わりに、予測可能または既知の識別子またはシーケンス番号が、ＭＰＤ内のメタデータの各セグメントに与えられ得る。クライアントは、直接、ＸＣＡＰ対応サーバ上のＭＰＤファイルにアクセスし、クライアントがダウンロードした最新要素に続く、ＭＰＤ内の要素にポイントするためにＸＣＡＰＧＥＴを使用し得る。クライアントは、、次いで、そのポイントから開始する要素の指定された番号を読み出し得る。ＸＭＬ文書にアクセスするためのＸＣＡＰ機構は、ＲＦＣ４８２５に説明されている。代替として、サーバは、ＸＣＡＰベースのメッセージを使用して、ＭＰＤ更新をクライアントにプッシュし得る。

サーバが付加的機能性を有する、別の代替では、サブスクリプション／通知モデルが、クライアントに、ＭＰＤへの変更を通知するために使用され得る。すなわち、クライアントは、ＭＰＤへの変更を通知されるようにサブクライブし得、サーバは、クライアントに、変更が生じると、任意の変更を通知し得る。サブスクリプション／通知モデルは、ＳＩＰ：ＳＵＢＳＣＲＩＢＥ／ＳＩＰ：ＮＯＴＩＦＹを使用して、またはＨＴＴＰに基づく、ＳＩＰの代替機構である、ＸＤＣＰ（ＸＭＬ Ｄｏｃｕｍｅｎｔ Ｃｏｍｍａｎｄ Ｐｒｏｔｏｃｏｌ）を使用して、実装することができる。これらの機構は両方とも、ＯＭＡＸＤＭ（ＸＭＬ Ｄｏｃｕｍｅｎｔ Ｍａｎａｇｅｍｅｎｔ）２．１Ｅｎａｂｌｅｒ仕様に説明されている。これらの機構をサポートするために、ＭＰＤ用のＡｐｐｌｉｃａｔｉｏｎ Ｕｓａｇｅは、ＸＤＭＳｅｒｖｅｒ内にＭＰＤファイルをホストすることが要求される。そして、ＸＤＭ Ｃｌｉｎｅｔは、Ａｐｐｌｉｃａｔｉｏｎ Ｕｓａｇｅにおいて指定されるように、ＭＰＤファイルへのアクセスおよびそのサブスクライブを可能にするために、ＵＥ（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）上に実装される必要がある。

サーバが付加的機能性を有する、これらの代替のいずれにおいても、インジケータが、ＭＰＤへの更新の使用をサポートすることを示すために、ＭＰＤに含まれ得る。すなわち、デルタファイルのサポートを示す、前述のインジケータ同様に、インジケータは、サーバが、ＭＰＤ更新をクライアントにプッシュする能力、ＸＣＡＰを使用して、ＭＰＤ更新をクライアントに提供する能力、サブスクリプション／通知モデルを使用して、クライアントにＭＰＤ更新を通知する能力、またはＭＰＤ更新をクライアントに提供するための他の能力を有することを示し得る。クライアントは、次いで、インジケータを解釈し、ＭＰＤ全体を受信することなく、ＭＰＤの更新を受信するための適切なアクションを行なう適切な機能性を有し得る。

図４ａおよび４ｂは、前述のデルタファイルのために使用される場合がある、デルタスキーマの実施例を例証する。

図５は、メディアプレゼンテーション記述情報を取得するための方法５００の実施形態を例証する。ブロック５１０では、クライアントは、サーバ上の第１のＭＰＤ内の変更に関連する情報を取得する。ブロック５２０では、クライアントは、変更に関連する情報によって、クライアント上の第２のＭＰＤを更新する。

要するに、要素は、デルタファイルのサポートを示すために、ＭＰＤに追加することができる。ＭＰＤに追加される要素名は、「ｄｅｌｔａ」である場合がある。要素「ｄｅｌｔａ」は、正の整数値をとる、「ｎｕｍｂｅｒＯｆＳｔｏｒｅｄＤｅｌｔａｓ」と命名された属性を含有することができる。デルタファイル名は、「ｄｅｌｔａ．ｘｍｌ」である場合があり、その以前のバージョンは、「ｄｅｌｔａ-１．ｘｍｌ」である場合がある。「ｄｅｌｔａ-１．ｘｍｌ」の以前のバージョンは、「ｄｅｌｔａ-２．ｘｍｌ」等である場合がある。したがって、属性「ｎｕｍｂｅｒＯｆＳｔｏｒｅｄｄｅｌｔａｓ」の値が、「３」である場合、クライアントは、ｆｉｌｅｓｄｅｌｔａ．ｘｍｌ、ｄｅｌｔａ-１．ｘｍｌ、およびｄｅｌｔａ-２．ｘｍｌが、サーバ上に存在することを把握する。

また、図４におけるスキーマは、デルタファイルのために使用され得る。任意の＜ａｄｄ＞、＜ｒｅｐｌａｃｅ＞、または＜ｒｅｍｏｖｅ＞要素における「ｓｅｌ」属性の値は、有効ＸＰａｔｈ式であることができる。スキーマは、使用されるべきＸＰａｔｈのバージョンを示す、属性「ｘｐａｔｈＶｅｒｓｉｏｎ」を含有する。デフォルト値は、「１．０」である。別のバージョンのＸＰａｔｈが使用される場合、「ｘｐａｔｈＶｅｒｓｉｏｎ」属性の値を介して示され得る。クライアントが、デルタファイルのダウンロードに応じて、「ｓｅｌ」属性におけるＸＰａｔｈ式にエラーを見つける場合、ＭＰＤ全体をダウンロードすることができる。

前述のクライアント、サーバ、および他の構成要素は、前述のアクションに関連する命令を実行可能な処理構成要素を含む場合がある。図６は、本明細書に開示される１つ以上の実施形態を実装するために好適な処理構成要素１３１０を含む、システム１３００の実施例を例証する。プロセッサ１３１０（中央処理ユニットまたはＣＰＵと称され得る）に加え、システム１３００は、ネットワーク接続デバイス１３２０、ランダムアクセスメモリ（ＲＡＭ）１３３０、読取専用メモリ（ＲＯＭ）１３４０、二次記憶装置１３５０、および入力／出力（Ｉ／Ｏ）デバイス１３６０を含む場合がある。これらの構成要素は、バス１３７０を介して、相互に通信する場合がある。ある場合には、これらの構成要素のうちのいくつかは、存在しなくてもよく、あるいは相互または図示されない他の構成可能と種々の組み合わせにおいて、組み合わせられてもよい。これらの構成要素は、単一物理的エンティティまたは２つ以上の物理的エンティティ内に位置する場合がある。プロセッサ１３１０によって行なわれるように本明細書に説明される任意のアクションは、プロセッサ１３１０単独によって、あるいはデジタル信号プロセッサ（ＤＳＰ）１３８０等、図面に図示される、または図示されない１つ以上の構成要素と併せて、プロセッサ１３１０によって、行なわれる場合がある。ＤＳＰ１３８０は、別個の構成要素として示されるが、ＤＳＰ１３８０は、プロセッサ１３１０に組み込まれる場合がある。

プロセッサ１３１０は、ネットワーク接続デバイス１３２０、ＲＡＭ１３３０、ＲＯＭ１３４０、または二次記憶装置１３５０（ハードディスク、フロッピー（登録商標）ディスク、または光ディスク等の種々のディスクベースのシステムを含む場合がある）からアクセスする場合がある、命令、コード、コンピュータプログラム、あるいはスクリプトを実行する。１つのみのＣＰＵ１３１０が示されるが、複数のプロセッサが、存在してもよい。したがって、命令は、プロセッサによって実行されるように論じられ得るが、命令は、同時に、連続的に、または別様に、１つまたは複数のプロセッサによって、実行されてもよい。プロセッサ１３１０は、１つ以上のＣＰＵチップとして、実装されてもよい。

ネットワーク接続デバイス１３２０は、モデム、モデム群、Ｅｔｈｅｒｎｅｔ（登録商標）デバイス、ユニバーサルシリアルバス（ＵＳＢ）インターフェースデバイス、シリアルインターフェース、トークンリングデバイス、光ファイバ分散データインターフェース（ＦＤＤＩ）デバイス、無線ローカルエリアネットワーク（ＷＬＡＮ）デバイス、符号分割多重アクセス（ＣＤＭＡ）デバイス等の無線送受信機デバイス、モバイル通信のためのグローバルシステム（ＧＳＭ（登録商標））無線送受信機デバイス、ワールドワイド・インターオペラビリティ・フォー・マイクロウェーブ・アクセス（ＷｉＭＡＸ）デバイス、および／またネットワークに接続するための他の周知のデバイスの形態をとってもよい。これらのネットワーク接続デバイス１３２０によって、プロセッサ１３１０が、インターネットまたは１つ以上の電気通信ネットワーク、あるいはプロセッサ１３１０が情報を受信する場合がある、またはプロセッサ１３１０が情報を出力する場合がある、他のネットワークと通信可能になってもよい。ネットワーク接続デバイス１３２０はまた、データを無線で伝送および／または受信可能な１つ以上の送受信機構成要素１３２５を含む場合がある。

ＲＡＭ１３３０は、揮発性データを記憶し、かつ恐らくは、プロセッサ１３１０によって実行される命令を記憶するために使用される場合がある。ＲＯＭ１３４０は、典型的には、二次記憶装置１３５０のメモリ容量より小さいメモリ容量を有する、不揮発性メモリデバイスである。ＲＯＭ１３４０は、命令と、恐らくは、命令の実行の間に読み取られるデータを記憶するために使用される場合がある。ＲＡＭ１３３０およびＲＯＭ１３４０両方へのアクセスは、典型的には、二次記憶装置１３５０より高速である。二次記憶装置１３５０は、典型的には、１つ以上のディスクドライブまたはテープドライブから成り、データの不揮発性記憶のため、またはＲＡＭ１３３０が、全作業データを保持するために十分に大きくない場合、超過データ記憶デバイスとして、使用される場合がある。二次記憶装置１３５０は、そのようなプログラムが、実行のために選択されると、ＲＡＭ１３３０にロードされる、プログラムを記憶するために使用されてもよい。

Ｉ／Ｏデバイス１３６０は、液晶ディスプレイ（ＬＣＤ）、タッチスクリーンディスプレイ、キーボード、キーパッド、スイッチ、ダイヤル、マウス、トラックボール、音声認識装置、カードリーダ、紙テープ読取機、プリンタ、ビデオモニタ、または他の周知の入力／出力デバイスを含んでもよい。また、送受信機１３２５は、ネットワーク接続デバイス１３２０の構成要素である代わりに、またはそれに加え、Ｉ／Ｏデバイス１３６０の構成可能であると見なされる場合がある。

ある実施形態では、メディアプレゼンテーション記述情報を得るための方法が、提供される。方法は、クライアントが、サーバ上の第１のＭＰＤ内の変更に関連する情報を取得するステップを含む。方法はさらに、クライアントが、変更に関連する情報によって、クライアント上の第２のＭＰＤを更新するステップを含む。

別の実施形態では、クライアントが、提供される。クライアントは、クライアントが、サーバ上の第１のＭＰＤ内の変更に関連する情報を取得するように構成され、クライアントが、変更に関連する情報によって、クライアント上の第２のＭＰＤを更新するように構成される、プロセッサを含む。

以下は、あらゆる目的のために、参照することによって本明細書に組み込まれる。
３ＧＰＰ Ｔｅｃｈｎｉｃａｌ Ｓｐｅｃｉｆｉｃａｔｉｏｎ（ＴＳ）２６．２３４,３ＧＰＰ ＴＳ ２６．２４４，ＩＳＯ／ＩＥＣ １４４９６−１２，Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ（ＩＥＴＦ）Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔｓ（ＲＦＣ）５８７４、およびＩＥＴＦ ＲＦＣ ５２６１。

いくつかの実施形態が、本開示に提供されたが、開示されるシステムおよび方法は、本開示の範囲から逸脱することなく、多くの他の具体的形態において具現化されてもよいことを理解されたい。本実施例は、制限ではなく、例証として見なされるべきであって、その意図は、本明細書に与えられる詳細に限定されない。例えば、種々の要素または構成要素は、別のシステムに組み合わせられる、または統合されてもよく、あるいはある特徴は、省略される、または実装されなくてもよい。

また、離散または別個として、種々の実施形態に説明および例証された技法、システム、サブシステムおよび方法は、本開示の範囲から逸脱することなく、他のシステム、モジュール、技法、または方法と組み合わせられる、あるいは統合されてもよい。連結される、または直接連結される、または相互に通信するように図示あるいは論じられる他のアイテムは、電気的に、機械的に、または別様にかを問わず、いくつかのインターフェース、デバイス、または中間構成要素を通して、間接的に連結される、あるいは通信してもよい。変更、代用、および改変の他の実施例は、当業者によって解明され、本明細書に開示される精神および範囲から逸脱することなく、行なわれ得る。

Claims (36)

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. 前記要素は、前記ＭＰＤデルタファイルが利用可能であるか否かを示す属性を含む、請求項１９に記載の方法。
26. 第２のＭＰＤの要求を受信することをさらに含む、請求項１９に記載の方法。
27. 前記ネットワークデバイスは、前記サーバを含む、請求項１９に記載の方法。
28. プロセッサを含むネットワークデバイスであって、
    前記プロセッサは、
    サーバによる、ＭＰＤデルタファイルのサポートを示す要素を含むメディアプレゼンテーション記述（ＭＰＤ）を伝送することと、
    前記ＭＰＤへの変更を含むＭＰＤデルタファイルの要求を受信することと
    を行うように構成され、
    前記要求は、前記ＭＰＤ内の前記要素に基づいて、前記ＭＰＤデルタファイルを要求するクライアントからのものである、ネットワークデバイス。
29. 前記サーバは、ハイパーテキスト転送プロトコル（ＨＴＴＰ）規格に準拠する、請求項２８に記載のネットワークデバイス。
30. 前記プロセッサは、変更コマンドおよび前記変更コマンドが適用される場所を前記ＭＰＤデルタファイル内に含むようにさらに構成される、請求項２８に記載のネットワークデバイス。
31. 前記変更コマンドは、
    追加コマンド、
    削除コマンド、または
    置換コマンド
    のうちの１つを含む、請求項３０に記載のネットワークデバイス。
32. 前記プロセッサは、前記要素内の前記ＭＰＤデルタファイルを識別する属性を含むようにさらに構成される、請求項２８に記載のネットワークデバイス。
33. 前記プロセッサは、前記要素内の前記ＭＰＤデルタファイルと関連付けられた持続時間を示す属性を含むようにさらに構成される、請求項２８に記載のネットワークデバイス。
34. 前記プロセッサは、前記ＭＰＤデルタファイルが利用可能であるか否かを示す属性を前記要素内に含むようにさらに構成される、請求項２８に記載のネットワークデバイス。
35. 前記プロセッサは、第２のＭＰＤの要求を受信するようにさらに構成される、請求項２８に記載のネットワークデバイス。
36. 前記ネットワークデバイスは、前記サーバを含む、請求項２８に記載のネットワークデバイス。

Images