JP2023504633A - オーディオおよび／またはビデオコンテンツをプレーヤーに配信するための方法 - Google Patents

Abstract

ローカルエリアネットワークは、ローカルエリアネットワーク内のプレーヤーを備えた端末がオーディオおよび／またはビデオコンテンツを受信できるようにするために、複数のコンテンツ配信ネットワークＣＤＮ受信機デバイスを備える。開示される方法は、ＣＤＮ受信機デバイスから容量情報を取得すること、容量情報に従って、オーディオおよび／またはビデオコンテンツをプレーヤーに配信するセッションのために少なくとも１つのＣＤＮ受信機デバイスを選択すること、を含み、セッションが終了すると、選択された少なくとも１つのＣＤＮ受信機デバイスは、所定の持続時間の間、可能性がある次のセッションのために処理リソースを所定の位置に保持し、所定の持続時間の満了前に別のセッションが開始すると、処理リソースは、所定の位置に保持し、新しいセッションに使用される。また、所定の持続時間の満了後に別のセッションが開始すると、更新された容量情報に従って、少なくとも１つのＣＤＮ受信機デバイスの再選択が、実行される。【選択図】図１

Description

本発明は、一般に、オーディオおよび／またはビデオコンテンツをプレーヤーに配信することに関する。より具体的には、本発明は、プレーヤーが、オーディオおよび／またはビデオコンテンツを受信し得る複数のデバイス間の負荷分散を管理することに関する。

関連技術
それは、単一のローカルエリアネットワークからのオーディオおよび／またはビデオコンテンツを消費するためのプレーヤーをそれぞれ含む端末によって複数のデバイスが接触されるオーディオおよび／またはビデオコンテンツ配信システムと見なされる。例えば、オーディオおよび／またはビデオコンテンツ配信システムは、オーディオおよび／またはビデオコンテンツが受信され得る複数のセットトップボックスを含み得、当該セットトップボックスは、端末と同じローカルエリアネットワークに接続される。その場合、ユーザーが、自分の端末でオーディオおよび／またはビデオコンテンツを再生することを望む場合、ユーザーは、オーディオおよび／またはビデオコンテンツを取得するためにローカルエリアネットワークのセットトップボックスのどれか１つを選択するために、自分の端末を操作しなければならない。

しかしながら、複数のそのようなセットトップボックスが同じローカルエリアネットワーク内に提供される場合、その意図は、多数の同時端末をサポートできるように、増大した、オーディオおよび／またはビデオコンテンツ配信容量を提供することである。したがって、適切な負荷分散管理がないと、一部のセットトップボックスは、過負荷になる可能性がある一方、他のセットトップボックスは、十分に活用されない可能性がある。実際、セットトップボックスの選択は各ユーザーによって実行されるので、すべてのセットトップボックスを介して利用可能にされないオーディオおよび／またはビデオコンテンツは到達不能である多くの状況が発生する可能性があり、なぜならば、当該オーディオおよび／またはビデオコンテンツを提供できるセットトップボックスは、すでに他のユーザーで過負荷になっているからである。さらに、ユーザーが第１のプログラム（ライブのオーディオおよび／またはビデオコンテンツ）から第２のプログラムにザッピングするとき、その間に他のユーザーが、ユーザーが第１のプログラムを再生していたセットトップボックスに接続した場合、ユーザーは、別のセットトップボックスに切り替えなければならない場合がある。すべてのこれらの状況、およびセットトップボックス間の不適切な負荷分散または負荷分散の欠如に関連する他の状況は、ユーザー体感品質（ＱｏＥ）に悪影響を及ぼす。

したがって、先行技術の前述の欠点を克服することが望ましい。

そのために、ローカルエリアネットワーク内のプレーヤーにオーディオおよび／またはビデオコンテンツを配信するための方法であって、ローカルエリアネットワークが、複数のコンテンツ配信ネットワークＣＤＮ受信機デバイスを備え、ＣＤＮ受信機デバイスが、少なくとも１つのプロバイダネットワークを介してセグメントの形態でオーディオおよび／またはビデオコンテンツを受信し、ＣＤＮ受信機デバイスが、ローカルエリアネットワーク内のプレーヤーを備えた端末がオーディオおよび／またはビデオコンテンツを受信することを可能にするために、オーディオおよび／またはビデオコンテンツの受信されたセグメントをローカルエリアネットワーク内に転送し、方法が、ＣＤＮ受信機デバイスから容量情報を取得することであって、容量情報が、ＣＤＮ受信機デバイスの総容量と比較した、実際に使用されている処理リソースの表示である、取得すること、容量情報に従って、オーディオおよび／またはビデオコンテンツをプレーヤーに配信するための少なくとも１つのＣＤＮ受信機デバイスを選択すること、オーディオおよび／またはビデオコンテンツをプレーヤーに配信するためのセッションが開始および終了することを検出すること、を含み、オーディオおよび／またはビデオコンテンツを、選択された少なくとも１つのＣＤＮ受信機デバイスからプレーヤーに配信するためのセッションが終了すると、選択された少なくとも１つのＣＤＮ受信機デバイスが、所定の持続時間の間、同じまたは別のオーディオおよび／またはビデオコンテンツをプレーヤーに配信するための可能性のある次のセッションのために、処理リソースを所定の位置に保持し、別のオーディオおよび／またはビデオコンテンツをプレーヤーに配信するための別のセッションが、所定の持続時間の満了前に開始すると、同じまたは別のオーディオおよび／またはビデオコンテンツが、処理リソースを使用して、選択された少なくとも１つのＣＤＮ受信機デバイスによってプレーヤーに配信され、所定の位置に保持し、同じまたは別のオーディオおよび／またはビデオコンテンツをプレーヤーに配信するための別のセッションが、所定の持続時間の満了後に開始すると、更新された容量情報に従って、少なくとも１つのＣＤＮ受信機デバイスの再選択が実行されて、別のオーディオおよび／またはビデオコンテンツをプレーヤーへ配信する、方法、が提案される。したがって、可能性のある次のセッションのために、処理リソースを所定の位置に保持することにより、新しいセッションごとに各ＣＤＮ受信機デバイスに尋ねることなく達成された中のスムーズな負荷分散。そうすることで、オーディオおよび／またはビデオコンテンツを再生（消費）するための起動時間が、特に、ユーザーが、あるライブのオーディオおよび／またはビデオコンテンツから別のライブのオーディオおよび／またはビデオコンテンツにザッピングする場合に、短縮される。

特定の実施形態によれば、オーディオおよび／またはビデオコンテンツは、アダプティブビットレートＡＢＲを可能にするために、様々な表現でＣＤＮ受信機に利用可能にされる。したがって、オーディオおよび／ビデオコンテンツの品質は、プレーヤーへの送信条件に応じて適合される。

特定の実施形態によれば、選択された少なくとも１つのＣＤＮ受信機デバイスは、オーディオおよび／またはビデオコンテンツのマニフェストファイルを取得するための要求を受信したときに、オーディオおよび／またはビデオコンテンツをプレーヤーに配信するためのセッションが開始することを検出する。

特定の実施形態によれば、選択された少なくとも１つのＣＤＮ受信機デバイスは、セッションが開始することを示すメッセージを受信したときに、オーディオおよび／またはビデオコンテンツをプレーヤーに配信するためのセッションが開始することを検出する。

特定の実施形態によれば、選択された少なくとも１つのＣＤＮ受信機デバイスは、プレーヤーへのオーディオおよび／またはビデオコンテンツの配信に関する要求が、所定の持続時間の間、選択された少なくとも１つのＣＤＮ受信機デバイスによって受信されなかったことを検出したとき、オーディオおよび／またはビデオコンテンツをプレーヤーへ配信するためのセッションが終了することを検出する。

特定の実施形態によれば、オーディオおよび／またはビデオコンテンツは、マルチキャスト形態でＣＤＮ受信機に利用可能にされ、ＣＤＮ受信機デバイスは、少なくとも１つのプロバイダネットワークを介してマルチキャスト形態で受信されたセグメントをユニキャスト形態に変換するデマルチキャスタである。

特定の実施形態によれば、各ＣＤＮ受信機デバイスは、その容量情報を、消費されるオーディオおよび／またはビデオコンテンツが、問題のＣＤＮ受信機デバイスを介して利用可能にされるかどうかをチェックするための要求に応答するのと同時に、送信する。

特定の実施形態によれば、消費されるオーディオおよび／またはビデオコンテンツが、問題のＣＤＮ受信機デバイスを介して利用可能にされるかどうかをチェックするための要求に応答して、少なくとも１つのＣＤＮ受信機デバイスによって送信される容量情報が、変化したとき、方法は、更新された容量情報を取得するために、各他のＣＤＮ受信機デバイスに容量情報を要求することをさらに含む。

特定の実施形態によれば、ＣＤＮ受信機デバイスから容量情報を取得すること、およびオーディオおよび／またはビデオコンテンツをプレーヤーに配信するための少なくとも１つのＣＤＮ受信機デバイスを、容量情報に従って選択することは、プレーヤーに関連付けられたアプリケーションによって実行される。

特定の実施形態によれば、ＣＤＮ受信機デバイスから容量情報を取得すること、およびオーディオおよび／またはビデオコンテンツをプレーヤーに配信するための少なくとも１つのＣＤＮ受信機デバイスを、容量情報に従って選択することは、消費されるオーディオおよび／またはビデオコンテンツが、問題のＣＤＮ受信機デバイスを介して利用可能にされるかどうかを、プレーヤーに関連付けられたアプリケーションが要求する１つのＣＤＮ受信機によって実行される。

特定の実施形態によれば、セッションが、オーディオおよび／またはビデオコンテンツを複数の選択されたＣＤＮ受信機デバイスからプレーヤーに配信することを暗示する場合、プレーヤーは、オーディオおよび／またはビデオコンテンツのセグメントを受信するためのプロキシデバイスと通信し、プロキシデバイスは、オーディオおよび／またはビデオコンテンツをプレーヤーに配信するための負荷分散を管理しながら、オーディオおよび／またはビデオコンテンツのセグメントを取得するための複数の選択されたＣＤＮ受信機デバイスと通信する。

特定の実施形態によれば、プロキシデバイスが、オーディオおよび／またはビデオコンテンツのマニフェストファイルを取得するための要求をプレーヤーから受信すると、プロキシデバイスは、オーディオおよび／またはビデオコンテンツのマニフェストファイルを取得するための１つのそのような要求を、複数の選択されたＣＤＮ受信機デバイスのうちの各選択されたＣＤＮ受信機デバイスに送信する。

ローカルエリアネットワーク内のプレーヤーにオーディオおよび／またはビデオコンテンツを配信するために構成されたオーディオおよび／またはビデオコンテンツ配信システムであって、ローカルエリアネットワークが、オーディオおよび／またはビデオコンテンツ配信システムの複数のコンテンツ配信ネットワークＣＤＮ受信機デバイスを備え、ＣＤＮ受信機デバイスが、少なくとも１つのプロバイダネットワークを介してセグメントの形態でオーディオおよび／またはビデオコンテンツを受信し、ＣＤＮ受信機デバイスが、ローカルエリアネットワーク内のプレーヤーを備えた端末がオーディオおよび／またはビデオコンテンツを受信することを可能にするために、オーディオおよび／またはビデオコンテンツの受信されたセグメントをローカルエリアネットワーク内に転送し、オーディオおよび／またはビデオコンテンツ配信システムが、ＣＤＮ受信機デバイスから容量情報を取得するための手段であって、容量情報が、ＣＤＮ受信機デバイスの総容量と比較した、実際に使用されている処理リソースの表示である、手段と、容量情報に従って、オーディオおよび／またはビデオコンテンツをプレーヤーに配信するための少なくとも１つのＣＤＮ受信機デバイスを選択するための手段と、オーディオおよび／またはビデオコンテンツをプレーヤーに配信するためのセッションが開始および終了することを検出するための手段と、を備える、オーディオおよび／またはビデオコンテンツ配信システム、がさらに提案される。オーディオおよび／またはビデオコンテンツ配信システムは、以下、オーディオおよび／またはビデオコンテンツを、選択された少なくとも１つのＣＤＮ受信機デバイスからプレーヤーに配信するためのセッションが終了すると、選択された少なくとも１つのＣＤＮ受信機デバイスが、所定の持続時間の間、同じまたは別のオーディオおよび／またはビデオコンテンツをプレーヤーに配信するための可能性のある次のセッションのために、処理リソースを所定の位置に保持し、別のオーディオおよび／またはビデオコンテンツをプレーヤーに配信するための別のセッションが、所定の持続時間の満了前に開始すると、同じまたは別のオーディオおよび／またはビデオコンテンツが、処理リソースを使用して、選択された少なくとも１つのＣＤＮ受信機デバイスによってプレーヤーに配信され、所定の位置に保持し、同じまたは別のオーディオおよび／またはビデオコンテンツをプレーヤーに配信するための別のセッションが、所定の持続時間の満了後に開始すると、更新された容量情報に従って、少なくとも１つのＣＤＮ受信機デバイスの再選択が実行されて、別のオーディオおよび／またはビデオコンテンツをプレーヤーへ配信するように、さらに構成されている。

本発明の特徴は、少なくとも１つの実施形態の以下の説明を読むことからより明確に明らかになり、説明は、添付の図面を参照して作成されている。

本発明が実装され得るオーディオおよび／またはビデオコンテンツ配信システムを概略的に表す。 オーディオおよび／またはビデオコンテンツ配信システムの範囲内で使用可能なデバイスのハードウェアアーキテクチャの例を概略的に表す。 デマルチキャスタ容量情報を取得するための第１の実施形態による、オーディオおよび／またはビデオコンテンツ配信システムで発生する交換を概略的に表す。 オーディオおよび／またはビデオコンテンツを配信するための第１の実施形態による、オーディオおよび／またはビデオコンテンツ配信システムで発生する交換を概略的に表す。 オーディオおよび／またはビデオコンテンツを配信するための第２の実施形態による、オーディオおよび／またはビデオコンテンツ配信システムで発生する交換を概略的に表す。 オーディオおよび／またはビデオコンテンツを配信するための第３の実施形態による、オーディオおよび／またはビデオコンテンツ配信システムで発生する交換を概略的に表す。 デマルチキャスタ容量情報を取得するための第２の実施形態による、オーディオおよび／またはビデオコンテンツ配信システムで発生する交換を概略的に表す。 オーディオおよび／またはビデオコンテンツを配信するための第４の実施形態による、オーディオおよび／またはビデオコンテンツ配信システムで発生する交換を概略的に表す。 オーディオおよび／またはビデオコンテンツを配信するための第５の実施形態による、オーディオおよび／またはビデオコンテンツ配信システムで発生する交換を概略的に表す。 オーディオおよび／またはビデオコンテンツを配信するための第６の実施形態による、オーディオおよび／またはビデオコンテンツ配信システムで発生する交換を概略的に表す。 オーディオおよび／またはビデオコンテンツを配信するための第７の実施形態による、オーディオおよび／またはビデオコンテンツ配信システムで発生する交換を共同して概略的に表す。 同上。

少なくとも１つの実施形態の詳細な説明
図１は、オーディオおよび／またはビデオコンテンツ配信システム１００を概略的に表す。オーディオおよび／またはビデオコンテンツ配信システム１００は、少なくとも１つのプロバイダネットワークＰＮ１０２を介して、オーディオおよび／またはビデオコンテンツを配信するように構成されたコンテンツ配信サーバ機器ＣＤＥ１６０を備える。コンテンツ配信サーバ機器ＣＤＥ１６０は、オーディオおよび／またはビデオコンテンツを、好ましくはマルチキャスト方式またはブロードキャスト方式で、例えば、衛星放送通信を使用して配信するように構成される。以下、オーディオおよび／またはビデオコンテンツがマルチキャスト方式で配信されることを例示的に検討する（ブロードキャスト送信は、マルチキャスト送信の特定のケースである）。コンテンツ配信サーバ機器ＣＤＥ１６０は、一変形例では、プロバイダネットワークＰＮ１０２の送信方向機能に従って、ユニキャスト方式でオーディオおよび／またはビデオコンテンツを配信するように構成され得る。

特定の一実施形態では、コンテンツ配信サーバ機器ＣＤＥ１６０は、エンコーダデバイスＥＮＣ１６３と、パッケージャデバイスＰＣＫＧ１６２と、トランスキャスタデバイスＴＣＡＳＴ１６１とを備える。エンコーダデバイスＥＮＣ１６３は、少なくとも１つのオーディオおよび／またはビデオフォーマットに従って、オーディオおよび／またはビデオコンテンツを符号化するように構成される。

好ましくは、エンコーダデバイスＥＮＣ１６３は、アダプティブビットレート（ＡＢＲ）ストリーミングの実装を可能にするために、オーディオおよび／またはビデオコンテンツを様々なビットレートで符号化する。アダプティブビットレートが実装されている場合、マニフェストファイル（または使用されているアダプティブビットレートテクノロジによっては、プレイリストファイル）は、使用可能にされた様々な表現を記述する。

パッケージャデバイスＰＣＫＧ１６２は、エンコーダデバイスＥＮＣ１６３によって符号化されたオーディオおよび／またはビデオコンテンツを、セグメントの形態でパッケージ化および供給するように構成されている。オーディオおよび／またはビデオコンテンツの複数の表現が利用可能な場合（アダプティブビットレートの場合）、オーディオおよび／またはビデオコンテンツの同じ部分に対応するセグメントが、好ましくはメディアファイルのセットとして、整列される（同じ持続時間、同じ開始フレームコンテンツ）。トランスキャスタデバイスＴＣＡＳＴ１６１は、セグメントを、トランスポートプロトコルを使用して、例えば、問題のオーディオおよび／またはビデオコンテンツの表現ごとに１つのＩＰ（インターネットプロトコル）マルチキャストストリームの形態で、プロバイダネットワークＰＮ１０２を介して送信するように構成されている。プロバイダネットワークＰＮ１０２が、双方向通信ネットワークであるか、または双方向ネットワークと組み合わされた単方向ネットワークである場合、コンテンツ配信サーバ機器ＣＤＥ１６０は、セグメントが受信時に欠落した、またはプロバイダネットワークＰＮ１０２を介して失われた、もしくは破損した場合に、修復のために、オンデマンドでセグメントを、ユニキャスト方式で提供するように構成されたユニキャストサーバデバイスを含み得る。

オーディオおよび／またはビデオコンテンツ配信システム１００は、それぞれのデマルチキャスタデバイスを埋め込んだゲートウェイをさらに備える。デマルチキャスタデバイスは、トランスキャスタデバイスＴＣＡＳＴ１６１によって使用されるトランスポートプロトコルから、プロバイダネットワークＰＮ１０２を介してマルチキャストまたはブロードキャスト方式で送信されたオーディオおよび／またはビデオコンテンツのセグメントを抽出するように構成される。

同じ位置に複数のゲートウェイを配置して、その位置でのオーディオおよび／またはビデオコンテンツ配信機能を消費し、そのようにして、その位置でのオーディオおよび／またはビデオコンテンツ配信ニーズの実現を分担することができる。例えば、一部のホテル、大学、または商店は、単一のゲートウェイが提供できるよりも多くのオーディオおよび／またはビデオコンテンツ配信機能を必要とし得る。その状況が、図１に示されている。３つのゲートウェイＧＷ１１４１、ＧＷ２１４２、ＧＷ３１４３は、これら３つのゲートウェイＧＷ１１４１、ＧＷ２１４２、ＧＷ３１４３すべてが同じローカルエリアネットワークＬＡＮ１０１に接続されるように、同じ位置に配置されている。例えば、ゲートウェイＧＷ１１４１、ＧＷ２１４２、ＧＷ３１４３は、スタックされる。したがって、ローカルエリアネットワークＬＡＮ１０１に接続された端末Ｔ１１１１、Ｔ２１１２は、コンテンツ配信サーバ機器ＣＤＥ１６０によって提供されるオーディオおよび／またはビデオコンテンツを、３つのゲートウェイＧＷ１１４１、ＧＷ２１４２、ＧＷ３１４３のどれか１つを介して受信し得る。より具体的には、ゲートウェイＧＷ１１４１、ＧＷ２１４２、ＧＷ３１４３は、それぞれ、デマルチキャスタデバイスＤＭ１１５１、ＤＭ２１５２、ＤＭ３１５３を含む。デマルチキャスタデバイスＤＭ１１５１、ＤＭ２１５２、ＤＭ３１５３は、トランスキャスタデバイスＴＣＡＳＴ１６１によって使用されるトランスポートプロトコルから、プロバイダネットワークＰＮ１０２を介して送信されるオーディオおよび／またはビデオコンテンツのセグメントを抽出するように、かつオーディオおよび／またはビデオコンテンツのセグメントを、ローカルエリアネットワークＬＡＮ１０１に接続された端末へさらに送信するように、構成される。デマルチキャスタデバイスＤＭ１１５１、ＤＭ２１５２、ＤＭ３１５３は、ローカルエリアネットワークＬＡＮ１０１に接続された端末と、ユニキャスト形態で通信する。したがって、デマルチキャスタデバイスＤＭ１１５１、ＤＭ２１５２、ＤＭ３１５３は、プロバイダネットワークＰＮ１０２を介して受信されたマルチキャストまたはブロードキャストデータを、ローカルエリアネットワークＬＡＮ１０１に接続された端末にアドレス指定されたユニキャストデータに変換するように構成される。すでに述べたように、セグメントが、受信時に欠落した、またはプロバイダネットワークＰＮ１０２を介して失われた、もしくは破損した場合、デマルチキャスタデバイスＤＭ１１５１、ＤＭ２１５２、ＤＭ３１５３は、コンテンツ配信サーバ機器ＣＤＥ１６０のユニキャストサーバデバイスに問題のセグメントを要求し、次いで、ユニキャストサーバデバイスから受信されたセグメントデータを、ローカルエリアネットワークＬＡＮ１０１上でのさらなる送信のために、マルチキャストデータに挿入することができる。

端子Ｔ１１１１、Ｔ２１１２は、それぞれ、プレーヤーＰＬ１１２１、ＰＬ２１２２を備える。端子Ｔ１１１１、Ｔ２１１２は、それぞれ、アプリケーションＡＰＰ１１３１、ＡＰＰ２１３２をさらに備える。アプリケーションＡＰＰ１１３１、ＡＰＰ２１３２は、典型的には、プレーヤーＰＬ１１２１、ＰＬ２１２２の外部にあり、それにより、ローカルエリアネットワークＬＡＮ１０１内の複数のデマルチキャスタデバイスの存在を認識しないサードパーティのプレーヤーを使用することが可能になる。アプリケーションＡＰＰ１１３１、ＡＰＰ２１３２は、一変形例では、プレーヤーＰＬ１１２１、ＰＬ２１２２に統合され得る。

プレーヤーＰＬ１１２１、ＰＬ２１２２は、プレーヤーＰＬ１１２１、ＰＬ２１２２によって消費されるオーディオおよび／またはビデオコンテンツを符号化するために、エンコーダデバイスＥＮＣ１６３によって使用される符号化フォーマットに従って符号化されたセグメントを復号するように構成される。プレーヤーＰＬ１１２１、ＰＬ２１２２は、それぞれアプリケーションＡＰＰ１１３１、ＡＰＰ２１３２を介してユニキャスト形態で、端末Ｔ１１１１、Ｔ２１１２によってそれぞれ受信されたオーディオおよび／またはビデオコンテンツを消費する（例えば、再生する、記録する）ように構成される。以下に詳述するように、アプリケーションＡＰＰ１１３１、ＡＰＰ２１３２は、プレーヤーＰＬ１１２１、ＰＬ２１２２によってそれぞれ消費されることを意図して受信されたオーディオおよび／またはビデオコンテンツデータを、オーディオおよび／またはビデオコンテンツデータが、プレーヤーＰＬ１１２１、ＰＬ２１２２に適合した形態であるように整形する。アプリケーションＡＰＰ１１３１、ＡＰＰ２１３２の各々は、デマルチキャスタデバイスＤＭ１１５１、ＤＭ２１５２、ＤＭ３１５３、もしくはマルチパス送信の場合はプロキシデバイスのうちのいずれか１つと通信するように、かつそこからオーディオおよび／またはビデオコンテンツを、好ましくはＨＴＴＰ（ハイパーテキストトランスポートプロトコル）を使用して受信するように構成され、プレーヤーＰＬ１１２１、ＰＬ２１２２は、例えば、ＨＡＳ（「ＨＴＴＰアダプティブストリーミング」）スキームに準拠するコンテンツを消費するように構成される。したがって、端末Ｔ１１１１、Ｔ２１１２は、オーディオおよび／またはビデオコンテンツを、マルチキャストおよびブロードキャスト形態のいずれにおいても受信することができない。プレーヤーＰＬ１１２１、ＰＬ２１２２は、オーディオおよび／またはビデオコンテンツ配信システム１００のインフラストラクチャに依存しない。

図１は、すべてのデマルチキャスタデバイスＤＭ１１５１、ＤＭ２１５２、ＤＭ３１５３が、同じコンテンツ配信サーバ機器ＣＤＥ１６０からオーディオおよび／またはビデオコンテンツを受信するように構成されて示されているが、デマルチキャスタデバイスＤＭ１１５１、ＤＭ２１５２、ＤＭ３１５３は、別個のそれぞれのコンテンツ配信サーバ機器からオーディオおよび／またはビデオコンテンツを受信するように構成されてもよいことに留意されたい。

様々な実施形態で以下に詳述されるように、オーディオおよび／またはビデオコンテンツをプレーヤーＰＬ１１２１、ＰＬ２１２２に配信することは、
－デマルチキャスタデバイスＤＭ１１５１、ＤＭ２１５２、ＤＭ３１５３から容量情報を取得すること、
－容量情報に従って、オーディオおよび／またはビデオコンテンツをプレーヤーに配信するために、デマルチキャスタデバイスＤＭ１１５１、ＤＭ２１５２、ＤＭ３１５３の中から少なくとも１つのデマルチキャスタデバイスを選択すること、を含み、
－オーディオおよび／またはビデオコンテンツを、選択された少なくとも１つのデマルチキャスタデバイスからプレーヤーに配信するためのセッションが終了すると、選択された少なくとも１つのデマルチキャスタデバイスが、所定の時間の間、同じまたは別のオーディオおよび／またはビデオコンテンツをプレーヤーに配信するための可能性のある次のセッションのために、処理リソースを所定の位置に保持し、
－同じまたは別のオーディオおよび／またはビデオコンテンツをプレーヤーに配信するための別のセッションが、所定の時間の満了前に開始すると、別のオーディオおよび／またはビデオコンテンツが、処理リソースを使用して、選択された少なくとも１つのデマルチキャスタデバイスによってプレーヤーに配信され、所定の位置に保持し、
－同じまたは別のオーディオおよび／またはビデオコンテンツをプレーヤーに配信するための別のセッションが、所定の時間の満了後に開始すると、更新された容量情報に従って、少なくとも１つのデマルチキャスタデバイスの再選択が実行されて、別のオーディオおよび／またはビデオコンテンツをプレーヤーへ配信する。

そうすることにより、プレーヤーが、オーディオおよび／またはビデオコンテンツセグメントを取得するために、できる限り頻繁に、同じデマルチキャスタデバイスにリンクされる。これにより、新しいセッションごとに各デマルチキャスタデバイスに問い合わせることなく、スムーズな負荷分散が可能になる。これにより、新しいセッションを開始するための待ち時間が低減され、特にエンドユーザーが、あるライブのオーディオおよび／ビデオコンテンツから別のライブのオーディオおよび／ビデオコンテンツにザッピングするときに、ユーザー体感品質（ＱｏＥ）が向上する。

図２は、オーディオおよび／またはビデオコンテンツ配信システムの範囲内で使用可能なハードウェアアーキテクチャの例を概略的に表す。ハードウェアアーキテクチャの例は、ゲートウェイＧＷ１１４１、ＧＷ２１４２、ＧＷ３１４３、および／または端末Ｔ１１１１、Ｔ２１１２、および／またはサーバ機器ＣＤＥ１６０の一部であり得る。ハードウェアアーキテクチャの例は、通信デバイス２００の一部であると、一般的に、考えてみよう。

示されるアーキテクチャによれば、通信デバイス２００は、通信バス２１０によって相互接続された以下の構成要素、すなわち、プロセッサ、マイクロプロセッサ、マイクロコントローラ、またはＣＰＵ（中央処理装置）２０１と、ＲＡＭ（ランダムアクセスメモリ）２０２と、ＥＥＰＲＯＭ（電気的に消去可能なプログラム可能なＲＯＭ）などのＲＯＭ（読み取り専用メモリ）２０３、例えば、フラッシュメモリと、ＨＤＤ（ハードディスクドライブ）２０４、またはＳＤ（セキュアデジタル）カードリーダーなどの記憶媒体に記憶された情報を読み取るように適合された任意の他のデバイスと、少なくとも１つの通信インターフェース２０５と、を備える。

ＣＰＵ２０１は、ＲＯＭ２０３から、またはＨＤＤ２０４もしくはＳＤカードなどの外部メモリからＲＡＭ２０２にロードされた命令を実行することができる。通信デバイス２００の電源がオンになった後、ＣＰＵ２０１は、ＲＡＭ２０２から命令を読み取り、これらの命令を実行することができる。命令は、本明細書で説明されるように、問題の通信デバイスによって実行されるステップをＣＰＵ２０１に実行させる１つのコンピュータプログラムを形成する。

したがって、本明細書に記載のステップ、動作、およびアルゴリズムは、ＰＣ、ＤＳＰ（デジタルシグナルプロセッサ）またはマイクロコントローラなどのプログラム可能なコンピューティングマシンによる一連の命令またはプログラムの実行によって、ソフトウェア形態で実装されるか、そうでなければ、ＦＰＧＡ（フィールドプログラマブルゲートアレイ）もしくはＡＳＩＣ（特定用途向け集積回路）などのマシンまたは専用構成要素によって、ハードウェア形態で実装され得る。一般的に言えば、通信デバイス２００は、問題の通信デバイス２００に関して本明細書で説明されるステップ、動作、およびアルゴリズムを実装するために適合および構成された電子回路を備える。

図３は、デマルチキャスタデバイスの容量情報を取得するための第１の実施形態による、オーディオおよび／またはビデオコンテンツ配信システム１００で発生する交換を概略的に表す。

ステップ３０１において、アプリケーションＡＰＰ１１３１、デマルチキャスタデバイスＤＭ１１５１、デマルチキャスタデバイスＤＭ２１５２、およびデマルチキャスタデバイスＤＭ３１５３が、発見手順（ＤＳＣＶＲとラベル付けされている）を実行する。ローカルエリアネットワークＬＡＮ１０１内に存在する場合、端末Ｔ２１１２などの他の端末も、（端末Ｔ２１１２のアプリケーションＡＰＰ２１３２を介して）発見手順に関与する。発見手順中、関係する通信デバイスは、それらのそれぞれの機能をエクスポートする。より具体的には、デマルチキャスタデバイスＤＭ１１５１、デマルチキャスタデバイスＤＭ２１５２、およびデマルチキャスタデバイスＤＭ３１５３は、ローカルエリアネットワークＬＡＮ１０１内の自分たちの存在をアナウンスし、それらのそれぞれのデマルチキャスタ機能をアナウンスする。発見手順は、例えば、ＵＰｎＰ（規範文書ＩＳＯ／ＩＥＣ２９３４１によって定義された「ユニバーサルプラグアンドプレイ」）プロトコルでも使用されるようなＳＳＤＰ（「シンプルサービス発見プロトコル」）プロトコルなどのＳＤＰ（「サービス発見プロトコル」）プロトコル、またはＡｐｐｌｅのＢｏｎｊｏｕｒなどのテクノロジーＺｅｒｏｃｏｎｆを使用する。

ステップ３０２において、アプリケーションＡＰＰ１１３１は、要求ＲＥＱ＿ＣＡＰをデマルチキャスタデバイスＤＭ１１５１に送信する。要求ＲＥＱ＿ＣＡＰは、要求ＲＥＱ＿ＣＡＰがアドレス指定される通信デバイスのオーディオおよび／またはビデオ処理リソースに関する実際の容量に関する情報を要求するメッセージである。そのような容量情報は、より具体的には、問題の通信デバイス（デマルチキャスタデバイス）の総容量と比較した、実際に使用されている処理リソースの表示である。

ステップ３０３において、デマルチキャスタデバイスＤＭ１１５１は、ステップ３０２でアプリケーションＡＰＰ１１３１によって送信された要求ＲＥＱ＿ＣＡＰに対する応答ＲＳＰ＿ＣＡＰを送信し、応答ＲＳＰ＿ＣＡＰは、要求ＲＥＱ＿ＣＡＰによって要求された容量情報を含む。応答ＲＳＰ＿ＣＡＰは、例えば、以下の容量情報、すなわち、実際の負荷（ＬＤ、パーセンテージ）、実際の同時セッション数（ＮＢ＿ＳＥＳＳ）、許容可能な同時セッションの最大数（ＭＡＸ＿ＳＥＳＳ）、および任意選択で実際の平均出力ビットレートならびに最大許容可能出力ビットレートを含む。

ステップ３０４において、アプリケーションＡＰＰ１１３１は、要求ＲＥＱ＿ＣＡＰをデマルチキャスタデバイスＤＭ２１５２に同じように送信し、ステップ３０５において、デマルチキャスタデバイスＤＭ２１５２は、ステップ３０４でアプリケーションＡＰＰ１１３１によって送信された要求ＲＥＱ＿ＣＡＰに対する応答ＲＳＰ＿ＣＡＰを送信する。

ステップ３０６において、アプリケーションＡＰＰ１１３１は、要求ＲＥＱ＿ＣＡＰをデマルチキャスタデバイスＤＭ３１５３に同じように送信し、ステップ３０７において、デマルチキャスタデバイスＤＭ３１５３は、ステップ３０４でアプリケーションＡＰＰ１１３１によって送信された要求ＲＥＱ＿ＣＡＰに対する応答ＲＳＰ＿ＣＡＰを送信する。

アプリケーションＡＰＰ１１３１が、一旦ローカルエリアネットワークＬＡＮ１０１内に存在するすべてのデマルチキャスタデバイスの容量情報を収集すると、アプリケーションＡＰＰ１１３１は、デマルチキャスタデバイスを、それらの容量情報に従って順序付けし、ステップ３０８において、容量情報が、ローカルエリアネットワークＬＡＮ１０１内に存在するデマルチキャスタデバイスの中で最も高い残存容量を示すデマルチキャスタデバイスを、オーディオおよび／またはビデオコンテンツ配信システム１００へのデフォルトのエントリポイントとして選択する。

容量情報に従った順序付けは、以下のように、各デマルチキャスタデバイスを容量スコアＣＳに関連付けるための以下のルールを適用することによって行われ得、デマルチキャスタデバイスは、次に、容量スコアＣＳの降順で順序付けされる。
Ｉｆ （ＮＢ＿ＳＥＳＳ ＜ ＭＡＸ＿ＳＥＳＳ）
ＣＳ ＝ １ － （（ＮＢ＿ＳＥＳＳ ／ ＭＡＸ＿ＳＥＳＳ） ＊ ＬＤ／１００
Ｅｌｓｅ
ＣＳ ＝ ０
他のルールを使用して、容量情報からそのような容量スコアＣＳを決定し、その結果、デマルチキャスタデバイスを、それらの実際の負荷または残存容量に従って順序付けしてもよい。

ステップ３０２～３０８は、アプリケーションＡＰＰ１１３１によって、ローカルエリアネットワークＬＡＮ１０１内に存在するデマルチキャスタデバイスの容量をチェックし、かつオーディオおよび／またはビデオコンテンツ配信システム１００へのデフォルトのエントリポイントを選択するプロセスＡＰＰ＿ＣＣ３００を共同して形成する。典型的には、アプリケーションＡＰＰ１１３１は、ローカルエリアネットワークＬＡＮ１０１内に存在するデマルチキャスタデバイスの順序付きリストＬを保持し、最も高い残存容量を示すデマルチキャスタデバイスが、容量スコアＣＳを決定するために使用されるルールに応じて、順序付きリストの最上部または最下部に現れる。同様のプロセスが、ローカルエリアネットワークＬＡＮ１０１内に存在するデマルチキャスタデバイスの容量をチェックするために、アプリケーションＡＰＰ２１３２によって実行される。以下、ローカルエリアネットワークＬＡＮ１０１内に存在するデマルチキャスタデバイスによって提供される容量情報を考慮して、デマルチキャスタデバイスＤＭ２１５２が、プロセスＡＰＰ＿ＣＣ３００の最良の候補である、と例示的に考えてみよう。

図４は、オーディオおよび／またはビデオコンテンツを配信するための第１の実施形態による、オーディオおよび／またはビデオコンテンツ配信システム１００で発生する交換を概略的に表す。

ステップ４００において、アプリケーションＡＰＰ１１３１、デマルチキャスタデバイスＤＭ１１５１、デマルチキャスタデバイスＤＭ２１５２、およびデマルチキャスタデバイスＤＭ３１５３が、ステップ３０１に関してすでに説明したように、発見手順を実行する。

ステップ４０１において、アプリケーションＡＰＰ１１３１は、図３に関して上記で詳述したように、プロセスＡＰＰ＿ＣＣを実行する。したがって、アプリケーションＡＰＰ１１３１は、容量情報に従って、ローカルエリアネットワークＬＡＮ１０１内に存在するデマルチキャスタデバイスの順序付きリストＬを保持する。

ステップ４０２において、アプリケーションＡＰＰ１１３１は、消費されるオーディオおよび／またはビデオコンテンツを選択する（本明細書では、プロセスＣ＿ＳＥＬと呼ばれる）。例えば、ユーザーは、端末Ｔ１１１１のグラフィカルユーザーインターフェース（ＧＵＩ）を介して、オーディオおよび／またはビデオコンテンツを選択する。

次に、ステップ４０３において、アプリケーションＡＰＰ１１３１は、消費されるオーディオおよび／またはビデオコンテンツが、アプリケーションＡＰＰ１１３１によって保持される順序付きリストＬに従って、例示的に最も高い残存容量を示すデマルチキャスタデバイスであるデマルチキャスタデバイスＤＭ２１５２を介して利用可能にされるかどうかをチェックする。そうするために、アプリケーションＡＰＰ１１３１は、要求ＲＥＱ＿ＣＨＫをデマルチキャスタデバイスＤＭ２１５２に送信する。要求ＲＥＱ＿ＣＨＫは、選択されたオーディオおよび／またはビデオコンテンツを表す情報を含み、かつデマルチキャスタデバイスＤＭ２１５２が、オーディオおよび／またはビデオコンテンツを端末Ｔ１１１１に提供できることの確認を要求するメッセージである。

各デマルチキャスタデバイスは、プロバイダネットワークＰＮ１０２を介して、各デマルチキャスタデバイスに利用可能にされたオーディオおよび／またはビデオコンテンツのリストを格納する。問題のデマルチキャスタデバイスは、例えば、専用のブロードキャストもしくはマルチキャストチャネルを介して、または所定の構成サーバに問い合わせることによって、その問題のデマルチキャスタデバイスに利用可能にされたオーディオおよび／またはビデオコンテンツのリストを取得する。

ステップ４０４において、デマルチキャスタデバイスＤＭ２１５２は、ステップ４０３でアプリケーションＡＰＰ１１３１によって送信された要求ＲＥＱ＿ＣＨＫに対する応答ＲＳＰ＿ＣＨＫを送信する。応答ＲＳＰ＿ＣＨＫは、デマルチキャスタデバイスＤＭ２１５２が、選択されたオーディオおよび／またはビデオコンテンツを端末Ｔ１１１１に配信できない場合のエラーコード、またはさもなければ確認コードのいずれかを含む。デマルチキャスタデバイスＤＭ２１５２は、選択されたオーディオおよび／またはビデオコンテンツが、デマルチキャスタデバイスＤＭ２１５２によるアクセス可能でない場合、またはデマルチキャスタデバイスＤＭ２１５２が、（ステップ４０１のプロセスＡＰＰ＿ＣＣの実行以降）処理リソースを使い果たした場合、選択されたオーディオおよび／またはビデオコンテンツを配信できない場合がある。デマルチキャスタデバイスＤＭ２１５２が、選択されたオーディオおよび／またはビデオコンテンツを配信することができず、かつ応答ＲＳＰ＿ＣＨＫが、対応するエラーコードを含む、と例示的に考えてみよう。

その場合、アプリケーションＡＰＰ１１３１は、消費されるオーディオおよび／またはビデオコンテンツが、順序付きリストＬ内で次に現れるデマルチキャスタデバイスを介して利用可能にされるかどうかをチェックする。デマルチキャスタデバイスＤＭ３１５３が、順序付けリストＬ内の次の項目に対応する、と例示的に考えてみよう。したがって、ステップ４０５において、アプリケーションＡＰＰ１１３１は、要求ＲＥＱ＿ＣＨＫをデマルチキャスタデバイスＤＭ３１５３に送信することによって、消費されるオーディオおよび／またはビデオコンテンツが、デマルチキャスタデバイスＤＭ３１５３を介して利用可能にされるかどうかをチェックする。ステップ４０６において、デマルチキャスタデバイスＤＭ３１５３は、ステップ４０５でアプリケーションＡＰＰ１１３１によって送信された要求ＲＥＱ＿ＣＨＫに対する応答ＲＳＰ＿ＣＨＫを送信する。デマルチキャスタデバイスＤＭ３１５３が、選択されたオーディオおよび／またはビデオコンテンツを配信することができ、かつ応答ＲＳＰ＿ＣＨＫが、対応する確認コードを含む、と例示的に考えてみよう。

ステップ４０７において、アプリケーションＡＰＰ１１３１は、選択されたオーディオおよび／またはビデオコンテンツを消費するために、プレーヤーＰＬ１１２１を起動する。そうするために、アプリケーションＡＰＰ１１３１は、プレーヤーＰＬ１１２１に、デマルチキャスタデバイスＤＭ３１５３の識別子（例えば、デマルチキャスタデバイスＤＭ３１５３のＩＰアドレス）と、選択されたオーディオ／またはビデオコンテンツを表す情報（例えば、選択されたオーディオおよび／またはビデオコンテンツ、または好ましくは、それを表すマニフェストファイルを指すＵＲＬパス）とを含むメッセージＬＡＵＮＣＨを送信する。

使用するアダプティブビットレートテクノロジによっては、マニフェストファイルが、同等にプレイリストファイルと命名される場合があることに留意されたい。それは、問題のオーディオおよび／またはビデオコンテンツが、コンテンツ配信サーバ機器ＣＤＥ１６０によって利用可能にされる様々な表現の記述を提供する。

ステップ４０８において、プレーヤーＰＬ１１２１は、（ＬＡＵＮＣＨメッセージの内容に従って）要求ＲＥＱ＿ＭをデマルチキャスタデバイスＤＭ３１５３に送信する。要求ＲＥＱ＿Ｍは、選択されたオーディオおよび／またはビデオコンテンツのマニフェストファイルを受信することを要求するユニキャストメッセージである。したがって、要求ＲＥＱ＿Ｍは、選択されたオーディオおよび／またはビデオコンテンツを表す情報（例えば、ＬＡＵＮＣＨメッセージ内に提供される、マニフェストファイルを指すＵＲＬパス）を含む。

ステップ４０９において、デマルチキャスタデバイスＤＭ３１５３は、要求されたマニフェストファイルを送信することによって、選択されたオーディオおよび／またはビデオコンテンツの利用可能性をプレーヤーＰＬ１１２１に対して確認する。要求ＲＥＱ＿Ｍを受信し、それに応答すると、デマルチキャスタデバイスＤＭ３１５３の内部で、セッションの開始の記録がトリガーされる（ステップ４１０）。アダプティブビットレートが実装されていない場合、マニフェストファイルは存在しない。したがって、一変形例では、デマルチキャスタデバイスＤＭ３１５３は、アプリケーションＡＰＰ１１３１から専用メッセージを受信すると、セッションの開始を検出する。別の変形例では、デマルチキャスタデバイスＤＭ３１５３は、問題のオーディオおよび／またはビデオコンテンツについてのプレーヤーＰＬ１１２１からの（以下に詳述されるように）（シーケンスにおける）第１の要求ＲＥＱ＿Ｃを受信すると、セッションの開始を検出する。

ステップ４１１において、プレーヤーＰＬ１１２１は、要求ＲＥＱ＿ＣをデマルチキャスタデバイスＤＭ３１５３に送信する。要求ＲＥＱ＿Ｃは、選択されたオーディオおよび／またはビデオコンテンツの少なくとも１つのセグメントを受信することを要求するユニキャストメッセージである。したがって、要求ＲＥＱ＿Ｃは、選択されたオーディオおよび／またはビデオコンテンツを表す情報（例えば、選択されたオーディオおよび／またはビデオコンテンツを指すＵＲＬパス）を含む。例えば、要求ＲＥＱ＿Ｃは、ＨＴＴＰ Ｇｅｔメッセージであり、ステップ４０９の間に取得されたマニフェストファイル内にアドバタイズされたもののうちの少なくとも１つのセグメントが要求される表現（品質）を示すパラメータをさらに含む。ステップ４１２において、デマルチキャスタデバイスＤＭ３１５３は、ステップ４１１でプレーヤーＰＬ１１２１によって送信された要求ＲＥＱ＿Ｃに対する応答ＲＳＰ＿Ｃを送信し、応答ＲＳＰ＿Ｃは、オーディオおよび／またはビデオコンテンツの少なくとも１つのセグメントを含む。そうすると、プレーヤーＰＬ１１２１は、受信された少なくとも１つのセグメントを消費し得る。ステップ４１１および４１２は、プレーヤーＰＬ１１２１が、選択されたオーディオおよび／またはビデオコンテンツの少なくとも１つの後続のセグメントをさらに受信することを可能にするために、繰り返され得る。

ステップ４０８～４１２は、選択されたオーディオおよび／またはビデオコンテンツを配信するプロセスＣ＿ＲＥＴ４１００を共同して形成する。

プレーヤーＰＬ１１２１によって送信される問題のオーディオおよび／またはビデオコンテンツに関連する要求ＲＥＱ＿Ｃに応答できるようにするために、デマルチキャスタデバイスＤＭ３１５３は、例えば、オーディオおよび／またはビデオコンテンツのセグメントが送信される（ここでは、オーディオおよび／またはビデオコンテンツはライブコンテンツであると考える）プロバイダネットワークＰＮ１０２上のマルチキャストストリームに加わることによって、コンテンツ配信サーバ機器ＣＤＥ１６０からオーディオおよび／またはビデオコンテンツのセグメントを取得する。

ステップ４１３において、アプリケーションＡＰＰ１１３１は、プレーヤーＰＬ１１２１が、セッションを終了したことを検出する。これは、プレーヤーＰＬ１２１が、アプリケーションＡＰＰ１１３１に、オーディオおよび／またはビデオコンテンツの消費が終了したことを（例えばメッセージＳＴＯＰによって）通知するによって行われ得る。

ステップ４１４において、アプリケーションＡＰＰ１１３１は、デマルチキャスタデバイスＤＭ３１５３に、オーディオおよび／またはビデオコンテンツの消費が終了したことを（例えば、メッセージＳＴＯＰによって）通知する。アプリケーションＡＰＰ１１３１からデマルチキャスタデバイスＤＭ３１５３への通知のない変形例では、デマルチキャスタデバイスＤＭ３１５３は、問題のオーディオおよび／またはビデオコンテンツに関するプレーヤーＰＬ１１２１からの要求（ＲＥＱ＿ＭまたはＲＥＱ＿Ｃのいずれか）の最後の送信から所定の時間ＰＴ１が経過したときに、オーディオおよび／またはビデオコンテンツをプレーヤーＰＬ１１２１に配信するためのセッションが終了したことを検出し得る。これにより、デマルチキャスタデバイスＤＭ３１５３の内部で、セッションの停止の記録がトリガーされる（ステップ４１５）。

セッションの終了にもかかわらず、デマルチキャスタデバイスＤＭ３１５３は、オーディオおよび／またはビデオコンテンツをプレーヤーＰＬ１１２１に配信するための可能性のある次のセッションのために、処理リソースを所定の位置に保持する。問題の処理リソースは、所定の時間ＰＴ２の間、所定の位置に保持される。オーディオおよび／またはビデオコンテンツをプレーヤーＰＬ１１２１に配信するために、後続のセッションが、所定の時間ＰＴ２内に開始されない場合、デマルチキャスタデバイスＤＭ３１５３は、問題の処理リソースを解放する。所定の時間ＰＴ２は、固定または構成可能であり得る。そうすることにより、特に少なくとも１人のユーザーが、あるライブプログラムから別のライブプログラムにザッピングし、それにより連続した短いセッションが発生する場合、ローカルエリアネットワークＬＡＮ１０１内に存在するデマルチキャスタデバイス間の負荷分散を効率的に管理することが可能になる。

したがって、所定の時間ＰＴ２の満了前に新しいセッションが開始されることを考慮して、アプリケーションＡＰＰ１１３１は、ステップ４１６において、消費される同じまたは別のオーディオおよび／またはビデオコンテンツを選択する（プロセスＣ＿ＳＥＬ）。例えば、ユーザーは、端末Ｔ１１１１のグラフィカルユーザーインターフェース（ＧＵＩ）を介して、同じまたは別のオーディオおよび／またはビデオコンテンツを選択する。

アプリケーションＡＰＰ１１３１は、消費される新たに選択されたオーディオおよび／またはビデオコンテンツが、前のセッション中使用されたデマルチキャスタデバイス、つまりデマルチキャスタデバイスＤＭ３１５３を介して利用可能にされるかどうかをチェックする。したがって、ステップ４１７において、アプリケーションＡＰＰ１１３１は、新たに選択されたオーディオおよび／またはビデオコンテンツを表す情報を含み、かつ新たに選択されたオーディオおよび／またはビデオコンテンツが利用可能にされることの確認を要求する要求ＲＥＱ＿ＣＨＫをデマルチキャスタデバイスＤＭ３１５３に送信することによって、新たに選択されたオーディオおよび／またはビデオコンテンツが、デマルチキャスタデバイスＤＭ３１５３を介して利用可能にされるかどうかをチェックする。ステップ４１８において、デマルチキャスタデバイスＤＭ３１５３は、ステップ４１７でアプリケーションＡＰＰ１１３１によって送信された要求ＲＥＱ＿ＣＨＫに対する応答ＲＳＰ＿ＣＨＫを送信する。デマルチキャスタデバイスＤＭ３１５３が、新たに選択されたオーディオおよび／またはビデオコンテンツを配信することができ、かつ応答ＲＳＰ＿ＣＨＫが、対応する確認コードを含む、と例示的に考えてみよう。

ステップ４１９において、アプリケーションＡＰＰ１１３１は、新たに選択されたオーディオおよび／またはビデオコンテンツを消費するために、プレーヤーＰＬ１１２１を再起動する。そうするために、アプリケーションＡＰＰ１１３１は、プレーヤーＰＬ１１２１に、デマルチキャスタデバイスＤＭ３１５３の識別子（例えば、デマルチキャスタデバイスＤＭ３１５３のＩＰアドレス）と、新たに選択されたオーディオ／またはビデオコンテンツを表す情報（例えば、新たに選択されたオーディオおよび／またはビデオコンテンツ、または好ましくは、それを表すマニフェストファイルを指すＵＲＬパス）とを含むメッセージＬＡＵＮＣＨを送信する。次に、ステップ４２０において、新たに選択されたオーディオおよび／またはビデオコンテンツを配信するために、プロセスＣ＿ＲＥＴが繰り返される。プロセスＣ＿ＲＥＴ４１００で説明したのと同じように、デマルチキャスタデバイスＤＭ３１５３は、要求ＲＥＱ＿Ｍを受信し、それに応答すると、新しいセッションの開始の記録を実行する。一変形例では、デマルチキャスタデバイスＤＭ３１５３は、アプリケーションＡＰＰ１１３１から専用メッセージを受信すると、新しいセッションの開始を検出する。別の変形例では、デマルチキャスタデバイスＤＭ３１５３は、問題のオーディオおよび／またはビデオコンテンツについてのプレーヤーＰＬ１１２１からの（シーケンスにおける）第１の要求ＲＥＱ＿Ｃを受信すると、新しいセッションの開始を検出する。

アプリケーションＡＰＰ１１３１によって新しいセッションが開始される一方で、前のセッションの終了から所定の時間ＰＴ２が満了した場合、新しいセッションのための処理リソースの利用可能性は、デマルチキャスタデバイスＤＭ３１５３によって保証され得ない。したがって、アプリケーションＡＰＰ１１３１は、順序付きリストＬの更新されたバージョン（更新された容量情報）を使用することによって、ローカルエリアネットワークＬＡＮ１０１内に存在するデマルチキャスタデバイスの中からデマルチキャスタを再び選択しなければならない。

プロセスＡＰＰ＿ＣＣを使用して、ローカルエリアネットワークＬＡＮ１０１内に存在するデマルチキャスタデバイスに問い合わせることは、それらの実際の能力情報の最も正確なビューを維持するために、アプリケーションＡＰＰ１１３１によって定期的に行われ得る。アプリケーションＡＰＰ１１３１は、プロセスＡＰＰ＿ＣＣが、ローカルエリアネットワークＬＡＮ１０１内に存在する少なくとも１つのデマルチキャスタデバイスの容量情報が変化したことを明らかにしたときに、順序付きリストＬを更新する。

図５は、オーディオおよび／またはビデオコンテンツを配信するための第２の実施形態による、オーディオおよび／またはビデオコンテンツ配信システムで発生する交換を概略的に表す。第２の実施形態では、デマルチキャスタデバイスから容量情報を取得することは、デマルチキャスタデバイスの前にオーディオおよび／またはビデオコンテンツの利用可能性をチェックすることと同時に実行される。したがって、メッセージ交換に関連するオーバーヘッドが、制限される。

ステップ５００において、アプリケーションＡＰＰ１１３１、デマルチキャスタデバイスＤＭ１１５１、デマルチキャスタデバイスＤＭ２１５２、およびデマルチキャスタデバイスＤＭ３１５３が、ステップ３０１に関してすでに説明したように、発見手順を実行する。

ステップ５０１において、アプリケーションＡＰＰ１１３１は、消費されるオーディオおよび／またはビデオコンテンツを選択する（プロセスＣ＿ＳＥＬ）。

次に、アプリケーションＡＰＰ１１３１は、要求ＲＥＱ＿ＣＨＫを使用して、消費されるオーディオおよび／またはビデオコンテンツが、デマルチキャスタデバイスＤＭ１１５１、ＤＭ２１５２、ＤＭ３１５３のうちのいずれかを介して利用可能にされるかどうかをチェックする。オーディオおよび／またはビデオコンテンツを配信するためのこの第２の実施形態では、アプリケーションＡＰＰ１１３１によって問い合わせられた各デマルチキャスタデバイスは、応答ＲＳＰ＿ＣＨＫで、対応する要求ＲＥＱ＿ＣＨＫに応答し、応答ＲＳＰ＿ＣＨＫは、問題のデマルチキャスタデバイスに関する容量情報も含む。

したがって、ステップ５０２において、アプリケーションＡＰＰ１１３１は、要求ＲＥＱ＿ＣＨＫをデマルチキャスタデバイスＤＭ１１５１に送信する。要求ＲＥＱ＿ＣＨＫは、選択されたオーディオおよび／またはビデオコンテンツを表す情報を含み、かつデマルチキャスタデバイスＤＭ１１５１が、オーディオおよび／またはビデオコンテンツを端末Ｔ１１１１に提供できることの確認を要求するメッセージである。図４に関してすでに説明したように、各デマルチキャスタデバイスは、プロバイダネットワークＰＮ１０２を介して、各デマルチキャスタデバイスに利用可能にされたオーディオおよび／またはビデオコンテンツのリストを格納する。

次に、ステップ５０３において、デマルチキャスタデバイスＤＭ１１５１は、ステップ５０２でアプリケーションＡＰＰ１１３１によって送信された要求ＲＥＱ＿ＣＨＫに対する応答ＲＳＰ＿ＣＨＫを送信する。エラーコードまたは確認コードを含むことに加えて、応答ＲＳＰ＿ＣＨＫは、（図３に関してすでに検討されたように）デマルチキャスタデバイスＤＭ１１５１に関連する容量情報をさらに含む。エラーコードまたは確認コードを含むことに加えて、応答ＲＳＰ＿ＣＨＫは、デマルチキャスタデバイスＤＭ１１５１に関連する容量情報をさらに含む。デマルチキャスタデバイスＤＭ１１５１が、選択されたオーディオおよび／またはビデオコンテンツを配信することができ、かつ応答ＲＳＰ＿ＣＨＫが、対応する確認コードを含む、と例示的に考えてみよう。

ステップ５０４において、アプリケーションＡＰＰ１１３１はまた、選択されたオーディオおよび／またはビデオコンテンツに対する要求ＲＥＱ＿ＣＨＫをデマルチキャスタデバイスＤＭ２１５２に送信する。次に、ステップ５０５において、デマルチキャスタデバイスＤＭ２１５２は、ステップ５０４でアプリケーションＡＰＰ１１３１によって送信された要求ＲＥＱ＿ＣＨＫに対する応答ＲＳＰ＿ＣＨＫを送信する。エラーコードまたは確認コードを含むことに加えて、応答ＲＳＰ＿ＣＨＫは、デマルチキャスタデバイスＤＭ２１５２に関連する容量情報をさらに含む。デマルチキャスタデバイスＤＭ２１５２が、選択されたオーディオおよび／またはビデオコンテンツを配信することができず、かつ応答ＲＳＰ＿ＣＨＫが、対応するエラーコードを含む、と例示的に考えてみよう。

ステップ５０６において、アプリケーションＡＰＰ１１３１はまた、選択されたオーディオおよび／またはビデオコンテンツに対する要求ＲＥＱ＿ＣＨＫをデマルチキャスタデバイスＤＭ３１５３に送信する。次に、ステップ５０７において、デマルチキャスタデバイスＤＭ３１５３は、ステップ５０６でアプリケーションＡＰＰ１１３１によって送信された要求ＲＥＱ＿ＣＨＫに対する応答ＲＳＰ＿ＣＨＫを送信する。エラーコードまたは確認コードを含むことに加えて、応答ＲＳＰ＿ＣＨＫは、デマルチキャスタデバイスＤＭ３１５３に関連する容量情報をさらに含む。デマルチキャスタデバイスＤＭ２１５２が、選択されたオーディオおよび／またはビデオコンテンツを配信することができず、かつ応答ＲＳＰ＿ＣＨＫが、対応するエラーコードを含む、と例示的に考えてみよう。

アプリケーションＡＰＰ１１３１が、一旦ローカルエリアネットワークＬＡＮ１０１内に存在するすべてのデマルチキャスタデバイスの容量情報を収集すると、アプリケーションＡＰＰ１１３１は、図３に関してすでに述べた順序付きリストＬを構築するために、デマルチキャスタデバイスを、それらの容量情報に従って順序付けする。アプリケーションＡＰＰ１１３１は、ローカルエリアネットワークＬＡＮ１０１内に存在するデマルチキャスタデバイスの中で最も高い容量を示し、かつ問題のオーディオおよび／またはビデオコンテンツを配信できるデマルチキャスタデバイスを選択する。アプリケーションＡＰＰ１１３１が、一致して、デマルチキャスタデバイスＤＭ３１５３を選択する、と例示的に考えてみよう。

ステップ５０８において、アプリケーションＡＰＰ１１３１は、選択されたオーディオおよび／またはビデオコンテンツを消費するために、プレーヤーＰＬ１１２１を起動する。そうするために、アプリケーションＡＰＰ１１３１は、プレーヤーＰＬ１１２１に、デマルチキャスタデバイスＤＭ３１５３の識別子（例えば、デマルチキャスタデバイスＤＭ３１５３のＩＰアドレス）と、選択されたオーディオ／またはビデオコンテンツを表す情報（例えば、選択されたオーディオおよび／またはビデオコンテンツ、または好ましくは、それを表すマニフェストファイルを指すＵＲＬパス）とを含むメッセージＬＡＵＮＣＨを送信する。

次に、（図４に関して詳述されたように）プロセスＣ＿ＲＥＴ５０９が、選択されたオーディオおよび／またはビデオコンテンツを端末Ｔ１１１１に配信するために、プレーヤーＰＬ１１２１と、デマルチキャスタデバイスＤＭ３１５３との間で実行される。プロセスＣ＿ＲＥＴ４１００で説明したのと同じように、デマルチキャスタデバイスＤＭ３１５３は、要求ＲＥＱ＿Ｍを受信し、それに応答すると、セッションの開始の記録を実行する。アダプティブビットレートが実装されていない場合、マニフェストファイルは存在しない。したがって、一変形例では、デマルチキャスタデバイスＤＭ３１５３は、アプリケーションＡＰＰ１１３１から専用メッセージを受信すると、セッションの開始を検出する。別の変形例では、デマルチキャスタデバイスＤＭ３１５３は、問題のオーディオおよび／またはビデオコンテンツについてのプレーヤーＰＬ１１２１からの（シーケンスにおける）第１の要求ＲＥＱ＿Ｃを受信すると、セッションの開始を検出する。

ステップ５１０において、アプリケーションＡＰＰ１１３１は、プレーヤーＰＬ１１２１が、セッションを終了したことを検出する。これは、プレーヤーＰＬ１１２１が、アプリケーションＡＰＰ１１３１に、オーディオおよび／またはビデオコンテンツの消費が終了したことを（例えばメッセージＳＴＯＰによって）通知するによって行われ得る。

ステップ５１１において、アプリケーションＡＰＰ１１３１は、デマルチキャスタデバイスＤＭ３１５３に、オーディオおよび／またはビデオコンテンツの消費が終了したことを（例えば、メッセージＳＴＯＰによって）通知する。アプリケーションＡＰＰ１１３１から通知のない変形例では、デマルチキャスタデバイスＤＭ３１５３は、プロセスＣ＿ＲＥＴ５０９での要求（ＲＥＱ＿ＭまたはＲＥＱ＿Ｃのいずれか）の最新の送信から所定の時間ＰＴ１が経過したときに、オーディオおよび／またはビデオコンテンツをプレーヤーＰＬ１１２１に配信するためのセッションが終了したことを検出し得る。これにより、デマルチキャスタデバイスＤＭ３１５３の内部で、セッションの停止の記録がトリガーされる（ステップ５１２）。

セッションの終了にもかかわらず、デマルチキャスタデバイスＤＭ３１５３は、所定の時間ＰＴ２の間、オーディオおよび／またはビデオコンテンツをプレーヤーＰＬ１１２１に配信するための可能性のある次のセッションのために、処理リソースを所定の位置に保持する。オーディオおよび／またはビデオコンテンツをプレーヤーＰＬ１１２１に配信するために、後続のセッションが、所定の時間ＰＴ２内に開始されない場合、デマルチキャスタデバイスＤＭ３１５３は、問題の処理リソースを解放する。

したがって、所定の時間ＰＴ２の満了前に新しいセッションが開始されることを考慮して、アプリケーションＡＰＰ１１３１は、ステップ５１３において、消費される同じまたは別のオーディオおよび／またはビデオコンテンツを選択する（プロセスＣ＿ＳＥＬ）。

アプリケーションＡＰＰ１１３１は、消費される新たに選択されたオーディオおよび／またはビデオコンテンツが、前のセッション中使用されたデマルチキャスタデバイス、つまりデマルチキャスタデバイスＤＭ３１５３を介して利用可能にされるかどうかをチェックする。したがって、ステップ５１４において、アプリケーションＡＰＰ１１３１は、新たに選択されたオーディオおよび／またはビデオコンテンツを表す情報を含み、かつ新たに選択されたオーディオおよび／またはビデオコンテンツが利用可能にされることの確認を要求する要求ＲＥＱ＿ＣＨＫをデマルチキャスタデバイスＤＭ３１５３に送信することによって、新たに選択されたオーディオおよび／またはビデオコンテンツが、デマルチキャスタデバイスＤＭ３１５３を介して利用可能にされるかどうかをチェックする。ステップ５１５において、デマルチキャスタデバイスＤＭ３１５３は、ステップ５１４でアプリケーションＡＰＰ１１３１によって送信された要求ＲＥＱ＿ＣＨＫに対する応答ＲＳＰ＿ＣＨＫを送信し、応答ＲＳＰ＿ＣＨＫは、デマルチキャスタデバイスＤＭ３１５３に関連する容量情報を含む。新たに選択されたオーディオおよび／またはビデオコンテンツが、デマルチキャスタデバイスＤＭ３１５３を介して利用可能でない場合、アプリケーションＡＰＰ１１３１は、どのデマルチキャスタデバイスを介して、問題のオーディオおよび／またはビデオコンテンツが配信され得るかを決定するために、要求ＲＥＱ＿ＣＨＫを、ローカルエリアネットワークＬＡＮ１０１内に存在する他のデマルチキャスタデバイスに送信する。応答ＲＳＰ＿ＣＨＫは容量情報を含んでいるため、アプリケーションＡＰＰ１１３１は、それから順序付きリストＬを更新し、かつ問題のオーディオおよび／またはビデオコンテンツを配信できるどのデマルチキャスタデバイスが、他のデマルチキャスタデバイスの中で最も高い容量を有するかをさらに決定し得る。デマルチキャスタデバイスＤＭ３１５３が、新たに選択されたオーディオおよび／またはビデオコンテンツを配信することができ、かつ応答ＲＳＰ＿ＣＨＫが、対応する確認コードを含む、と例示的に考えてみよう。

ステップ５１６において、アプリケーションＡＰＰ１１３１は、新たに選択されたオーディオおよび／またはビデオコンテンツを消費するために、プレーヤーＰＬ１１２１を再起動する。そうするために、アプリケーションＡＰＰ１１３１は、プレーヤーＰＬ１１２１に、デマルチキャスタデバイスＤＭ３１５３の識別子（例えば、デマルチキャスタデバイスＤＭ３１５３のＩＰアドレス）と、新たに選択されたオーディオ／またはビデオコンテンツを表す情報（例えば、新たに選択されたオーディオおよび／またはビデオコンテンツ、または好ましくは、それを表すマニフェストファイルを指すＵＲＬパス）とを含むメッセージＬＡＵＮＣＨを送信する。次に、ステップ５１７において、新たに選択されたオーディオおよび／またはビデオコンテンツを配信するために、プロセスＣ＿ＲＥＴが繰り返される。プロセスＣ＿ＲＥＴ４１００で説明したのと同じように、デマルチキャスタデバイスＤＭ３１５３は、要求ＲＥＱ＿Ｍを受信し、それに応答すると、新しいセッションの開始の記録を実行する。一変形例では、デマルチキャスタデバイスＤＭ３１５３は、アプリケーションＡＰＰ１１３１から専用メッセージを受信すると、新しいセッションの開始を検出する。別の変形例では、デマルチキャスタデバイスＤＭ３１５３は、問題のオーディオおよび／またはビデオコンテンツについてのプレーヤーＰＬ１１２１からの（シーケンスにおける）第１の要求ＲＥＱ＿Ｃを受信すると、新しいセッションの開始を検出する。

アプリケーションＡＰＰ１１３１によって新しいセッションが開始される一方で、前のセッションの終了から所定の時間ＰＴ２が満了した場合、新しいセッションのための処理リソースの利用可能性は、デマルチキャスタデバイスＤＭ３１５３によって保証され得ない。したがって、アプリケーションＡＰＰ１１３１は、順序付きリストＬの更新されたバージョンを使用することによって、ローカルエリアネットワークＬＡＮ１０１内に存在するデマルチキャスタデバイスの中からデマルチキャスタを再び選択しなければならない。

図６は、オーディオおよび／またはビデオコンテンツを配信するための第３の実施形態による、オーディオおよび／またはビデオコンテンツ配信システムで発生する交換を概略的に表す。この第３の実施形態は、図４および図５に関して詳述された前述の第１および第２の実施形態の組み合わせである。そのように進めることで、ローカルエリアネットワークＬＡＮ１０１内に存在するデマルチキャスタデバイス間の負荷分散は、妥当な量のオーバーヘッドで、可能な限り安定したままである。

ステップ６００において、アプリケーションＡＰＰ１１３１、デマルチキャスタデバイスＤＭ１１５１、デマルチキャスタデバイスＤＭ２１５２、およびデマルチキャスタデバイスＤＭ３１５３が、ステップ３０１に関してすでに説明したように、発見手順を実行する。

ステップ６０１において、アプリケーションＡＰＰ１１３１は、図３に関して上記で詳述したように、プロセスＡＰＰ＿ＣＣを実行する。したがって、アプリケーションＡＰＰ１１３１は、容量情報に従って、ローカルエリアネットワークＬＡＮ１０１内に存在するデマルチキャスタデバイスの順序付きリストＬを保持する。

ステップ６０２において、アプリケーションＡＰＰ１１３１は、消費されるオーディオおよび／またはビデオコンテンツを選択する（プロセスＣ＿ＳＥＬ）。

次に、ステップ６０３において、アプリケーションＡＰＰ１１３１は、消費されるオーディオおよび／またはビデオコンテンツが、アプリケーションＡＰＰ１１３１によって保持される順序付きリストＬに従って、例示的に最も高い残存容量を示すデマルチキャスタデバイスであるデマルチキャスタデバイスＤＭ２１５２を介して利用可能にされるかどうかをチェックする。そうするために、アプリケーションＡＰＰ１１３１は、要求ＲＥＱ＿ＣＨＫをデマルチキャスタデバイスＤＭ２１５２に送信する。要求ＲＥＱ＿ＣＨＫは、選択されたオーディオおよび／またはビデオコンテンツを表す情報を含み、かつデマルチキャスタデバイスＤＭ２１５２が、オーディオおよび／またはビデオコンテンツを端末Ｔ１１１１に提供できることの確認を要求するメッセージである。前述のように、各デマルチキャスタデバイスは、プロバイダネットワークＰＮ１０２を介して、各デマルチキャスタデバイスに利用可能にされたオーディオおよび／またはビデオコンテンツのリストを格納する。

ステップ６０４において、デマルチキャスタデバイスＤＭ２１５２は、ステップ６０３でアプリケーションＡＰＰ１１３１によって送信された要求ＲＥＱ＿ＣＨＫに対する応答ＲＳＰ＿ＣＨＫを送信する。応答ＲＳＰ＿ＣＨＫは、デマルチキャスタデバイスＤＭ２１５２が、選択されたオーディオおよび／またはビデオコンテンツを端末Ｔ１１１１に配信できない場合のエラーコード、またはさもなければ確認コードのいずれかを含む。エラーコードまたは確認コードを含むことに加えて、応答ＲＳＰ＿ＣＨＫは、デマルチキャスタデバイスＤＭ２１５２に関連する容量情報をさらに含む。デマルチキャスタデバイスＤＭ２１５２が、選択されたオーディオおよび／またはビデオコンテンツを配信することができず、かつ応答ＲＳＰ＿ＣＨＫが、対応するエラーコードを含む、と例示的に考えてみ、さらに、プロセスＡＰＰ＿ＣＣ６０１の実行以降、デマルチキャスタデバイスＤＭ２１５２に関連する容量情報が変化していない、と例示的に考えてみよう。

その場合、アプリケーションＡＰＰ１１３１は、消費されるオーディオおよび／またはビデオコンテンツが、順序付きリストＬ内で次に現れるデマルチキャスタデバイスを介して利用可能にされるかどうかをチェックする。デマルチキャスタデバイスＤＭ３１５３が、順序付けリストＬ内の次の項目に対応する、と例示的に考えてみよう。したがって、ステップ６０５において、アプリケーションＡＰＰ１１３１は、要求ＲＥＱ＿ＣＨＫをデマルチキャスタデバイスＤＭ３１５３に送信することによって、消費されるオーディオおよび／またはビデオコンテンツが、デマルチキャスタデバイスＤＭ３１５３を介して利用可能にされるかどうかをチェックする。ステップ６０６において、デマルチキャスタデバイスＤＭ３１５３は、ステップ６０５でアプリケーションＡＰＰ１１３１によって送信された要求ＲＥＱ＿ＣＨＫに対する応答ＲＳＰ＿ＣＨＫを送信する。エラーコードまたは確認コードを含むことに加えて、応答ＲＳＰ＿ＣＨＫは、デマルチキャスタデバイスＤＭ３１５３に関連する容量情報をさらに含む。デマルチキャスタデバイスＤＭ３１５３が、選択されたオーディオおよび／またはビデオコンテンツを配信することができ、かつ応答ＲＳＰ＿ＣＨＫが、対応する確認コードを含む、と例示的に考えてみ、さらに、プロセスＡＰＰ＿ＣＣ６０１の実行以降、デマルチキャスタデバイスＤＭ３１５３に関連する容量情報が変化していない、と例示的に考えてみよう。

ステップ６０７において、アプリケーションＡＰＰ１１３１は、選択されたオーディオおよび／またはビデオコンテンツを消費するために、プレーヤーＰＬ１１２１を起動する。そうするために、アプリケーションＡＰＰ１１３１は、プレーヤーＰＬ１１２１に、デマルチキャスタデバイスＤＭ３１５３の識別子（例えば、デマルチキャスタデバイスＤＭ３１５３のＩＰアドレス）と、選択されたオーディオ／またはビデオコンテンツを表す情報（例えば、選択されたオーディオおよび／またはビデオコンテンツ、または好ましくは、それを表すマニフェストファイルを指すＵＲＬパス）とを含むメッセージＬＡＵＮＣＨを送信する。

次に、（図４に関して詳述されたように）プロセスＣ＿ＲＥＴ６０８が、選択されたオーディオおよび／またはビデオコンテンツを端末Ｔ１１１１に配信するために、プレーヤーＰＬ１１２１と、デマルチキャスタデバイスＤＭ３１５３との間で実行される。プロセスＣ＿ＲＥＴ４１００で説明したのと同じように、デマルチキャスタデバイスＤＭ３１５３は、要求ＲＥＱ＿Ｍを受信し、それに応答すると、セッションの開始の記録を実行する。アダプティブビットレートが実装されていない場合、マニフェストファイルは存在しない。したがって、一変形例では、デマルチキャスタデバイスＤＭ３１５３は、アプリケーションＡＰＰ１１３１から専用メッセージを受信すると、セッションの開始を検出する。別の変形例では、デマルチキャスタデバイスＤＭ３１５３は、問題のオーディオおよび／またはビデオコンテンツについてのプレーヤーＰＬ１１２１からの（シーケンスにおける）第１の要求ＲＥＱ＿Ｃを受信すると、セッションの開始を検出する。

さらに、一旦プロセスＣ＿ＲＥＴ６０８が開始されると（例えば、所定の時間ＰＴ３が経過した後）、アプリケーションＡＰＰ１１３１は、プロセスＣ＿ＲＥＴ６０８のセッションの設定を考慮するために、デマルチキャスタデバイスＤＭ３１５３に関連する容量情報を更新する。そうするために、要求ＲＥＱ＿ＣＡＰおよび対応する応答ＲＳＰ＿ＣＡＰに基づく交換が、使用され得る（図６には示されていない）。

ステップ６０９において、アプリケーションＡＰＰ１１３１は、プレーヤーＰＬ１１２１が、セッションを終了したことを検出する。これは、プレーヤーＰＬ１２１が、アプリケーションＡＰＰ１１３１に、オーディオおよび／またはビデオコンテンツの消費が終了したことを（例えばメッセージＳＴＯＰによって）通知するによって行われ得る。

ステップ６１０において、アプリケーションＡＰＰ１１３１は、デマルチキャスタデバイスＤＭ３１５３に、オーディオおよび／またはビデオコンテンツの消費が終了したことを（例えば、メッセージＳＴＯＰによって）通知する。アプリケーションＡＰＰ１１３１からデマルチキャスタデバイスＤＭ３１５３への通知のない変形例では、デマルチキャスタデバイスＤＭ３１５３は、プロセスＣ＿ＲＥＴ６０８での要求（ＲＥＱ＿ＭまたはＲＥＱ＿Ｃのいずれか）の最新の送信から所定の時間ＰＴ１が経過したときに、オーディオおよび／またはビデオコンテンツをプレーヤーＰＬ１１２１に配信するためのセッションが終了したことを検出し得る。これにより、デマルチキャスタデバイスＤＭ３１５３の内部で、セッションの停止の記録がトリガーされる（ステップ６１１）。

セッションの終了にもかかわらず、デマルチキャスタデバイスＤＭ３１５３は、オーディオおよび／またはビデオコンテンツをプレーヤーＰＬ１１２１に配信するための可能性のある次のセッションのために、処理リソースを所定の位置に保持する。問題の処理リソースが、所定の時間ＰＴ２の間、所定の位置に保持される。オーディオおよび／またはビデオコンテンツをプレーヤーＰＬ１１２１に配信するために、後続のセッションが、所定の時間ＰＴ２内に開始されない場合、デマルチキャスタデバイスＤＭ３１５３は、問題の処理リソースを解放する。アプリケーションＡＰＰ１１３１によって新しいセッションが開始される一方で、前のセッションの終了から所定の時間ＰＴ２が満了した場合、新しいセッションのための処理リソースの利用可能性は、デマルチキャスタデバイスＤＭ３１５３によって保証され得ない。したがって、アプリケーションＡＰＰ１１３１は、順序付きリストＬの更新されたバージョンを使用することによって、ローカルエリアネットワークＬＡＮ１０１内に存在するデマルチキャスタデバイスの中からデマルチキャスタを再び選択しなければならない。

したがって、所定の時間ＰＴ２の満了前に新しいセッションが開始されることを考慮して、アプリケーションＡＰＰ１１３１は、ステップ６１２において、消費される同じまたは別のオーディオおよび／またはビデオコンテンツを選択する（プロセスＣ＿ＳＥＬ）。

アプリケーションＡＰＰ１１３１は、消費される新たに選択されたオーディオおよび／またはビデオコンテンツが、前のセッション中使用されたデマルチキャスタデバイス、つまりデマルチキャスタデバイスＤＭ３１５３を介して利用可能にされるかどうかをチェックする。したがって、ステップ６１３において、アプリケーションＡＰＰ１１３１は、新たに選択されたオーディオおよび／またはビデオコンテンツを表す情報を含み、かつ新たに選択されたオーディオおよび／またはビデオコンテンツが利用可能にされることの確認を要求する要求ＲＥＱ＿ＣＨＫをデマルチキャスタデバイスＤＭ３１５３送信することによって、新たに選択されたオーディオおよび／またはビデオコンテンツが、デマルチキャスタデバイスＤＭ３１５３を介して利用可能にされるかどうかをチェックする。ステップ６１４において、デマルチキャスタデバイスＤＭ３１５３は、ステップ６１３でアプリケーションＡＰＰ１１３１によって送信された要求ＲＥＱ＿ＣＨＫに対する応答ＲＳＰ＿ＣＨＫを送信する。エラーコードまたは確認コードを含むことに加えて、応答ＲＳＰ＿ＣＨＫは、デマルチキャスタデバイスＤＭ３１５３に関連する容量情報をさらに含む。デマルチキャスタデバイスＤＭ３１５３が、新たに選択されたオーディオおよび／またはビデオコンテンツを配信することができ、かつ応答ＲＳＰ＿ＣＨＫが、対応する確認コードを含む、と例示的に考えてみよう。また一方で、容量情報が、以前にデマルチキャスタデバイスＤＭ３１５３によって送信され、順序付きリストＬの現在のバージョンを構築または更新するために使用された容量情報とは異なると、さらに例示的に考えてみよう。

したがって、ステップ６１５において、アプリケーションＡＰＰ１１３１は、デマルチキャスタデバイスＤＭ３１５３によって送信された応答ＲＳＰ＿ＣＨＫに含まれる容量情報が、デマルチキャスタデバイスＤＭ３１５３によって以前に送信され、順序付きリストＬの現在のバージョンを構築または更新するために使用された容量情報と比較して、容量変化を示すかどうかをチェックする。容量変化がある場合、アプリケーションＡＰＰ１１３１は、ローカルエリアネットワークＬＡＮ１０１内に存在する他のデマルチキャスタデバイスに、それらのそれぞれの容量を更新するために、問い合わせる。

したがって、ステップ６１６において、アプリケーションＡＰＰ１１３１は、要求ＲＥＱ＿ＣＡＰをデマルチキャスタデバイスＤＭ１１５１に送信する。ステップ６１７において、デマルチキャスタデバイスＤＭ１１５１は、ステップ６１６でアプリケーションＡＰＰ１１３１によって送信された要求ＲＥＱ＿ＣＡＰに対する応答ＲＳＰ＿ＣＡＰを送信し、応答ＲＳＰ＿ＣＡＰは、要求ＲＥＱ＿ＣＡＰによって要求された容量情報を含む。要求ＲＥＱ＿ＣＡＰは、要求ＲＥＱ＿ＣＨＫが容量情報の取得のみに関係するので、要求ＲＥＱ＿ＣＨＫよりも処理が高速であるに対し、要求ＲＥＱ＿ＣＨＫは、場合によっては容量情報の取得に加えて、利用可能なオーディオおよび／またはビデオコンテンツのリストを解析することを暗示することに留意されたい。

ステップ６１８において、アプリケーションＡＰＰ１１３１は、要求ＲＥＱ＿ＣＡＰをデマルチキャスタデバイスＤＭ２１５２に同じように送信する。ステップ６１９において、デマルチキャスタデバイスＤＭ２１５２は、ステップ６１８でアプリケーションＡＰＰ１１３１によって送信された要求ＲＥＱ＿ＣＡＰに対する応答ＲＳＰ＿ＣＡＰを送信する。

アプリケーションＡＰＰ１１３１が、一旦ローカルエリアネットワークＬＡＮ１０１内に存在するすべてのデマルチキャスタデバイスの容量情報を収集すると、アプリケーションＡＰＰ１１３１は、順序付きリストＬを更新するために、デマルチキャスタデバイスを、それらの容量情報に従って順序付けする。アプリケーションＡＰＰ１１３１は、ステップ６２０において、容量情報が、ローカルエリアネットワークＬＡＮ１０１内に存在するデマルチキャスタデバイスの中で最も高い残存容量を示すデマルチキャスタデバイスを、オーディオおよび／またはビデオコンテンツ配信システム１００へのデフォルトのエントリポイントとして選択する。デマルチキャスタデバイスＤＭ２１５２が、順序付きリストＬの中で最も高い容量を示す、と例示的に考えてみよう。

そうすると、アプリケーションＡＰＰ１１３１は、新たに選択されたオーディオおよび／またはビデオコンテンツが、デマルチキャスタデバイスＤＭ２１５２を介して利用可能にされるかどうかをチェックする。そうするために、アプリケーションＡＰＰ１１３１は、ステップ６２１で、新たに選択されたオーディオおよび／またはビデオコンテンツを表す情報を含み、かつ新たに選択されたオーディオおよび／またはビデオコンテンツが利用可能にされることの確認を要求する要求ＲＥＱ＿ＣＨＫをデマルチキャスタデバイスＤＭ２１５２に送信する。

ステップ６２２において、デマルチキャスタデバイスＤＭ２１５２は、ステップ６２１でアプリケーションＡＰＰ１１３１によって送信された要求ＲＥＱ＿ＣＨＫに対する応答ＲＳＰ＿ＣＨＫを送信する。応答ＲＳＰ＿ＣＨＫは、デマルチキャスタデバイスＤＭ２１５２が、新たに選択されたオーディオおよび／またはビデオコンテンツを端末Ｔ１１１１に配信できない場合のエラーコード、またはさもなければ確認コードのいずれかを含む。エラーコードまたは確認コードを含むことに加えて、応答ＲＳＰ＿ＣＨＫは、デマルチキャスタデバイスＤＭ２１５２に関連する容量情報をさらに含む。デマルチキャスタデバイスＤＭ２１５２が、新たに選択されたオーディオおよび／またはビデオコンテンツを配信することができ、かつ応答ＲＳＰ＿ＣＨＫが、対応する確認コードを含む、と例示的に考えてみよう。

ステップ６２３において、アプリケーションＡＰＰ１１３１は、新たに選択されたオーディオおよび／またはビデオコンテンツを消費するために、プレーヤーＰＬ１１２１を再起動する。そうするために、アプリケーションＡＰＰ１１３１は、プレーヤーＰＬ１１２１に、デマルチキャスタデバイスＤＭ２１５２の識別子（例えば、デマルチキャスタデバイスＤＭ２１５２のＩＰアドレス）と、新たに選択されたオーディオ／またはビデオコンテンツを表す情報（例えば、新たに選択されたオーディオおよび／またはビデオコンテンツ、または好ましくは、それを表すマニフェストファイルを指すＵＲＬパス）とを含むメッセージＬＡＵＮＣＨを送信する。次に、ステップ６２４において、プロセスＣ＿ＲＥＴが、新たに選択されたオーディオおよび／またはビデオコンテンツを配信するために、プレーヤーＰＬ１１２１と、デマルチキャスタデバイスＤＭ２１５２との間で実行される。プロセスＣ＿ＲＥＴ４１００で説明したのと同じように、デマルチキャスタデバイスＤＭ３１５３は、要求ＲＥＱ＿Ｍを受信し、それに応答すると、新しいセッションの開始の記録を実行する。一変形例では、デマルチキャスタデバイスＤＭ３１５３は、アプリケーションＡＰＰ１１３１から専用メッセージを受信すると、新しいセッションの開始を検出する。別の変形例では、デマルチキャスタデバイスＤＭ３１５３は、問題のオーディオおよび／またはビデオコンテンツについてのプレーヤーＰＬ１１２１からの（シーケンスにおける）第１の要求ＲＥＱ＿Ｃを受信すると、新しいセッションの開始を検出する。

図７は、デマルチキャスタ容量情報を取得するための第２の実施形態による、オーディオおよび／またはビデオコンテンツ配信システムで発生する交換を概略的に表す。図３と比較すると、容量情報は、ここでは、アプリケーションによって収集されるのではなく、デマルチキャスタデバイスによって収集される。デマルチキャスタデバイスＤＭ２１５２が、容量情報を収集する、と例示的にしよう。容量情報を収集することは、ローカルエリアネットワークＬＡＮ１０１内に存在する任意のおよびすべてのデマルチキャスタデバイスによって実行され得る。

ステップ７０１において、アプリケーションＡＰＰ１１３１、デマルチキャスタデバイスＤＭ１１５１、デマルチキャスタデバイスＤＭ２１５２、およびデマルチキャスタデバイスＤＭ３１５３が、発見手順（ＤＳＣＶＲとラベル付けされている）を実行する。ローカルエリアネットワークＬＡＮ１０１内に存在する場合、端末Ｔ２１１２などの他の端末も、（端末Ｔ２１１２のアプリケーションＡＰＰ２１３２を介して）発見手順に関与する。発見手順は、すでに説明したように適用される。

ステップ７０２において、デマルチキャスタデバイスＤＭ２１５２は、要求ＲＥＱ＿ＣＡＰをデマルチキャスタデバイスＤＭ３１５３に送信し、ステップ７０３において、デマルチキャスタデバイスＤＭ３１５３は、ステップ７０２でデマルチキャスタデバイスＤＭ２１５２によって送信された要求ＲＥＱ＿ＣＡＰに対する応答ＲＳＰ＿ＣＡＰを送信し、応答ＲＳＰ＿ＣＡＰは、要求ＲＥＱ＿ＣＡＰによって要求された容量情報を含む。

ステップ７０４において、デマルチキャスタデバイスＤＭ２１５２は、要求ＲＥＱ＿ＣＡＰをデマルチキャスタデバイスＤＭ１１５１に同じように送信し、ステップ７０５において、デマルチキャスタデバイスＤＭ１１５１は、ステップ７０４でデマルチキャスタデバイスＤＭ２１５２によって送信された要求ＲＥＱ＿ＣＡＰに対する応答ＲＳＰ＿ＣＡＰを送信する。

デマルチキャスタデバイスＤＭ２１５２は、自身の容量情報をさらに内部的に取得する。

デマルチキャスタデバイスＤＭ２１５２が、一旦ローカルエリアネットワークＬＡＮ１０１内に存在するすべてのデマルチキャスタデバイスの容量情報を収集すると、デマルチキャスタデバイスＤＭ２１５２は、デマルチキャスタデバイスを、それらの容量情報に従って順序付けし、ステップ７０６において、容量情報が、ローカルエリアネットワークＬＡＮ１０１内に存在するデマルチキャスタデバイスの中で最も高い残存容量を示すデマルチキャスタデバイスを、オーディオおよび／またはビデオコンテンツ配信システム１００へのデフォルトのエントリポイントとして選択する。容量情報に従って順序付けすることは、図３に関してすでに説明したように行われ得る。

ステップ７０２～７０６は、デマルチキャスタデバイスＤＭ２１５２によって、ローカルエリアネットワークＬＡＮ１０１内に存在するデマルチキャスタデバイスの容量をチェックし、かつオーディオおよび／またはビデオコンテンツ配信システム１００へのデフォルトのエントリポイントを選択するプロセスＤＭ＿ＣＣ７００を共同して形成する。

図８は、オーディオおよび／またはビデオコンテンツを配信するための第４の実施形態による、オーディオおよび／またはビデオコンテンツ配信システムで発生する交換を概略的に表す。この第４の実施形態の範囲内で、アプリケーションＡＰＰ１１３１は、デマルチキャスタデバイスＤＭ２１５２に依存して、オーディオおよび／またはビデオコンテンツを受信するための適切なデマルチキャスタデバイスを選択する。アプリケーションＡＰＰ１１３１が依存するデマルチキャスタデバイスは、端末Ｔ１１１１のメモリにハードコーディングされ得る。アプリケーションＡＰＰ１１３１が依存するデマルチキャスタデバイスは、所定のルールを適用することにより、発見手順に従って、アプリケーションＡＰＰ１１３１によって選択され得る。

ステップ８００において、アプリケーションＡＰＰ１１３１、デマルチキャスタデバイスＤＭ１１５１、デマルチキャスタデバイスＤＭ２１５２、およびデマルチキャスタデバイスＤＭ３１５３が、ステップ３０１に関してすでに説明したように、発見手順を実行する。

ステップ８０１において、デマルチキャスタデバイスＤＭ２１５２は、図７に関して上記で詳述したように、プロセスＤＭ＿ＣＣを実行する。したがって、デマルチキャスタデバイスＤＭ２１５２は、容量情報に従って、ローカルエリアネットワークＬＡＮ１０１内に存在するデマルチキャスタデバイスの順序付きリストＬを保持する。好ましくは、アプリケーションＡＰＰ１１３１がどのデマルチキャスタデバイスに依存するかを、デマルチキャスタデバイスが知らない状況に対処するために、ローカルエリアネットワークＬＡＮ１０１に存在するすべてのデマルチキャスタデバイスが、プロセスＤＭ＿ＣＣを実行し、それら自身のバージョンの順序付きリストＬを保持する。

ステップ８０２において、アプリケーションＡＰＰ１１３１は、消費されるオーディオおよび／またはビデオコンテンツを選択する（プロセスＣ＿ＳＥＬ）。

次に、ステップ８０３において、アプリケーションＡＰＰ１１３１は、消費されるオーディオおよび／またはビデオコンテンツが利用可能にされるかどうかを、デマルチキャスタデバイスＤＭ２１５２に尋ねる。そうするために、アプリケーションＡＰＰ１１３１は、要求ＲＥＱ＿ＣＨＫをデマルチキャスタデバイスＤＭ２１５２に送信する。その結果、デマルチキャスタデバイスＤＭ２１５２は、デマルチキャスタデバイスＤＭ２１５２によって保持される順序付きリストＬに従って、どのデマルチキャスタデバイスが、最も高い残存容量を示すかを決定する。デマルチキャスタデバイスＤＭ３１５３が、順序付きリストＬに従って最も高い容量を示す、と例示的に考えてみよう。

そうすると、デマルチキャスタデバイスＤＭ２１５２は、ステップ８０４において、要求ＲＥＱ＿ＣＨＫをデマルチキャスタデバイスＤＭ３１５３に送信する。要求ＲＥＱ＿ＣＨＫは、選択されたオーディオおよび／またはビデオコンテンツを表す情報を含み、かつデマルチキャスタデバイスＤＭ３１５３が、オーディオおよび／またはビデオコンテンツを端末Ｔ１１１１に提供できることの確認を要求するメッセージである。すでに述べたように、各デマルチキャスタデバイスは、プロバイダネットワークＰＮ１０２を介して、各デマルチキャスタデバイスに利用可能にされたオーディオおよび／またはビデオコンテンツのリストを格納する。ステップ８０５において、デマルチキャスタデバイスＤＭ３１５３は、ステップ８０４でデマルチキャスタデバイスＤＭ２１５２によって送信された要求ＲＥＱ＿ＣＨＫに対する応答ＲＳＰ＿ＣＨＫを送信する。応答ＲＳＰ＿ＣＨＫは、デマルチキャスタデバイスＤＭ３１５３が、選択されたオーディオおよび／またはビデオコンテンツを端末Ｔ１１１１に配信できない場合のエラーコード、またはさもなければ確認コードのいずれかを含む。デマルチキャスタデバイスＤＭ３１５３が、選択されたオーディオおよび／またはビデオコンテンツを配信することができ、かつ応答ＲＳＰ＿ＣＨＫが、対応する確認コードを含む、と例示的に考えてみよう。

ステップ８０６において、デマルチキャスタデバイスＤＭ２１５２は、ステップ８０３でアプリケーションＡＰＰ１１３１によって送信された要求ＲＥＱ＿ＣＨＫに対する応答ＲＳＰ＿ＣＨＫをアプリケーションＡＰＰ１１３１に送信する。応答ＲＳＰ＿ＣＨＫは、デマルチキャスタデバイスＤＭ３１５３が、選択されたオーディオおよび／またはビデオコンテンツを配信できることを示し、かつ対応する確認コードを含む。

ステップ８０７において、アプリケーションＡＰＰ１１３１は、選択されたオーディオおよび／またはビデオコンテンツを消費するために、プレーヤーＰＬ１１２１を起動する。そうするために、アプリケーションＡＰＰ１１３１は、プレーヤーＰＬ１１２１に、デマルチキャスタデバイスＤＭ３１５３の識別子（例えば、デマルチキャスタデバイスＤＭ３１５３のＩＰアドレス）と、選択されたオーディオ／またはビデオコンテンツを表す情報（例えば、選択されたオーディオおよび／またはビデオコンテンツ、または好ましくは、それを表すマニフェストファイルを指すＵＲＬパス）とを含むメッセージＬＡＵＮＣＨを送信する。

次に、（図４に関して詳述されたように）プロセスＣ＿ＲＥＴ８０８が、選択されたオーディオおよび／またはビデオコンテンツを端末Ｔ１１１１に配信するために、プレーヤーＰＬ１１２１と、デマルチキャスタデバイスＤＭ３１５３との間で実行される。プロセスＣ＿ＲＥＴ４１００で説明したのと同じように、デマルチキャスタデバイスＤＭ３１５３は、要求ＲＥＱ＿Ｍを受信し、それに応答すると、セッションの開始の記録を実行する。アダプティブビットレートが実装されていない場合、マニフェストファイルは存在しない。したがって、一変形例では、デマルチキャスタデバイスＤＭ３１５３は、アプリケーションＡＰＰ１１３１から専用メッセージを受信すると、セッションの開始を検出する。別の変形例では、デマルチキャスタデバイスＤＭ３１５３は、問題のオーディオおよび／またはビデオコンテンツについてのプレーヤーＰＬ１１２１からの（シーケンスにおける）第１の要求ＲＥＱ＿Ｃを受信すると、セッションの開始を検出する。

ステップ８０９において、アプリケーションＡＰＰ１１３１は、プレーヤーＰＬ１１２１が、セッションを終了したことを検出する。これは、プレーヤーＰＬ１２１が、アプリケーションＡＰＰ１１３１に、オーディオおよび／またはビデオコンテンツの消費が終了したことを（例えばメッセージＳＴＯＰによって）通知するによって行われ得る。

ステップ８１０において、アプリケーションＡＰＰ１１３１は、マルチキャスタデバイスＤＭ３１５３に、オーディオおよび／またはビデオコンテンツの消費が終了したことを（例えば、メッセージＳＴＯＰによって）通知する。アプリケーションＡＰＰ１１３１からデマルチキャスタデバイスＤＭ３１５３への通知のない変形例では、デマルチキャスタデバイスＤＭ３１５３は、プロセスＣ＿ＲＥＴ８０８でのプレーヤーＰＬ１１２１からの要求（ＲＥＱ＿ＭまたはＲＥＱ＿Ｃのいずれか）の最新の送信から所定の時間ＰＴ１が経過したときに、オーディオおよび／またはビデオコンテンツをプレーヤーＰＬ１１２１に配信するためのセッションが終了したことを検出し得る。これにより、デマルチキャスタデバイスＤＭ３１５３の内部で、セッションの停止の記録がトリガーされる（ステップ８１１）。

セッションの終了にもかかわらず、デマルチキャスタデバイスＤＭ３１５３は、オーディオおよび／またはビデオコンテンツをプレーヤーＰＬ１１２１に配信するための可能性のある次のセッションのために、処理リソースを所定の位置に保持する。問題の処理リソースが、所定の時間ＰＴ２の間、所定の位置に保持される。オーディオおよび／またはビデオコンテンツをプレーヤーＰＬ１１２１に配信するために、後続のセッションが、所定の時間ＰＴ２内に開始されない場合、デマルチキャスタデバイスＤＭ３１５３は、問題の処理リソースを解放する。

したがって、所定の時間ＰＴ２の満了前に新しいセッションが開始されることを考慮して、アプリケーションＡＰＰ１１３１は、ステップ８１２において、消費される同じまたは別のオーディオおよび／またはビデオコンテンツを選択する（プロセスＣ＿ＳＥＬ）。

次に、アプリケーションＡＰＰ１１３１は、デマルチキャスタデバイスＤＭ２１５２に、新たに選択されたオーディオおよび／またはビデオコンテンツが利用可能にされるかどうかを尋ねる。そうするために、ステップ８１３において、アプリケーションＡＰＰ１１３１は、新たに選択されたオーディオおよび／またはビデオコンテンツを表す情報を含み、かつ新たに選択されたオーディオおよび／またはビデオコンテンツが利用可能にされることの確認を要求する要求ＲＥＱ＿ＣＨＫをデマルチキャスタデバイスＤＭ２１５２に送信する。その結果、デマルチキャスタデバイスＤＭ２１５２は、消費される新たに選択されたオーディオおよび／またはビデオコンテンツが、端末Ｔ１１１１のための前のセッション中使用されたデマルチキャスタデバイス、つまりデマルチキャスタデバイスＤＭ３１５３を介して利用可能にされるかどうかをチェックする。したがって、ステップ８１４において、デマルチキャスタデバイスＤＭ２１５２は、要求ＲＥＱ＿ＣＨＫをデマルチキャスタデバイスＤＭ３１５３に送信することによって、新たに選択されたオーディオおよび／またはビデオコンテンツが、デマルチキャスタデバイスＤＭ３１５３を介して利用可能にされるかどうかをチェックする。ステップ８１５において、デマルチキャスタデバイスＤＭ３１５３は、ステップ８１４でデマルチキャスタデバイスＤＭ２１５２によって送信された要求ＲＥＱ＿ＣＨＫに対する応答ＲＳＰ＿ＣＨＫを送信する。デマルチキャスタデバイスＤＭ３１５３が、新たに選択されたオーディオおよび／またはビデオコンテンツを配信することができ、かつ応答ＲＳＰ＿ＣＨＫが、対応する確認コードを含む、と例示的に考えてみよう。

ステップ８１６において、デマルチキャスタデバイスＤＭ２１５２は、ステップ８１３でアプリケーションＡＰＰ１１３１によって送信された要求ＲＥＱ＿ＣＨＫに対する応答ＲＳＰ＿ＣＨＫをアプリケーションＡＰＰ１１３１に送信する。応答ＲＳＰ＿ＣＨＫは、デマルチキャスタデバイスＤＭ３１５３が、選択されたオーディオおよび／またはビデオコンテンツを配信できることを示し、かつ対応する確認コードを含む。

ステップ８１７において、アプリケーションＡＰＰ１１３１は、新たに選択されたオーディオおよび／またはビデオコンテンツを消費するために、プレーヤーＰＬ１１２１を再起動する。そうするために、アプリケーションＡＰＰ１１３１は、プレーヤーＰＬ１１２１に、デマルチキャスタデバイスＤＭ３１５３の識別子（例えば、デマルチキャスタデバイスＤＭ３１５３のＩＰアドレス）と、新たに選択されたオーディオ／またはビデオコンテンツを表す情報（例えば、新たに選択されたオーディオおよび／またはビデオコンテンツ、または好ましくは、それを表すマニフェストファイルを指すＵＲＬパス）とを含むメッセージＬＡＵＮＣＨを送信する。次に、ステップ８１８において、新たに選択されたオーディオおよび／またはビデオコンテンツを配信するために、プロセスＣ＿ＲＥＴが繰り返される。プロセスＣ＿ＲＥＴ４１００で説明したのと同じように、デマルチキャスタデバイスＤＭ３１５３は、要求ＲＥＱ＿Ｍを受信し、それに応答すると、新しいセッションの開始の記録を実行する。一変形例では、デマルチキャスタデバイスＤＭ３１５３は、アプリケーションＡＰＰ１１３１から専用メッセージを受信すると、新しいセッションの開始を検出する。別の変形例では、デマルチキャスタデバイスＤＭ３１５３は、問題のオーディオおよび／またはビデオコンテンツについてのプレーヤーＰＬ１１２１からの（以下に詳述されるように）（シーケンスにおける）第１の要求ＲＥＱ＿Ｃを受信すると、セッションの開始を検出する。

アプリケーションＡＰＰ１１３１によって新しいセッションが開始される一方で、前のセッションの終了から所定の時間ＰＴ２が満了した場合、新しいセッションのための処理リソースの利用可能性は、デマルチキャスタデバイスＤＭ３１５３によって保証され得ない。したがって、デマルチキャスタデバイスＤＭ２１５２は、順序付きリストＬの更新されたバージョンを使用することによって、ローカルエリアネットワークＬＡＮ１０１内に存在するデマルチキャスタデバイスの中からデマルチキャスタを再び選択しなければならない。

プロセスＤＭ＿ＣＣを使用して、ローカルエリアネットワークＬＡＮ１０１内に存在するデマルチキャスタデバイスに問い合わせることは、それらの実際の能力情報の最も正確なビューを維持するために、問題のデマルチキャスタによって定期的に行われ得る。問題のデマルチキャスタは、プロセスＤＭ＿ＣＣが、ローカルエリアネットワークＬＡＮ１０１内に存在する少なくとも１つのデマルチキャスタデバイスの容量情報が変化したことを明らかにしたときに、順序付きリストＬを更新する。

図９は、オーディオおよび／またはビデオコンテンツを配信するための第５の実施形態による、オーディオおよび／またはビデオコンテンツ配信システムで発生する交換を概略的に表す。この第５の実施形態の範囲内で、アプリケーションＡＰＰ１１３１は、デマルチキャスタデバイスＤＭ２１５２に依存して、オーディオおよび／またはビデオコンテンツを受信するための適切なデマルチキャスタデバイスを選択する。さらに、第５の実施形態では、デマルチキャスタデバイスから容量情報を取得することは、デマルチキャスタデバイスの前にオーディオおよび／またはビデオコンテンツの利用可能性をチェックすることと同時に実行される。したがって、メッセージ交換に関連するオーバーヘッドが、制限される。

ステップ９００において、アプリケーションＡＰＰ１１３１、デマルチキャスタデバイスＤＭ１１５１、デマルチキャスタデバイスＤＭ２１５２、およびデマルチキャスタデバイスＤＭ３１５３が、ステップ３０１に関してすでに説明したように、発見手順を実行する。

ステップ９０１において、アプリケーションＡＰＰ１１３１は、消費されるオーディオおよび／またはビデオコンテンツを選択する（プロセスＣ＿ＳＥＬ）。

次に、ステップ９０２において、アプリケーションＡＰＰ１１３１は、消費されるオーディオおよび／またはビデオコンテンツが利用可能にされるかどうかを、デマルチキャスタデバイスＤＭ２１５２に尋ねる。そうするために、アプリケーションＡＰＰ１１３１は、選択されたオーディオおよび／またはビデオコンテンツを表す情報を含み、かつ選択されたオーディオおよび／またはビデオコンテンツが利用可能にされることの確認を要求する要求ＲＥＱ＿ＣＨＫをデマルチキャスタデバイスＤＭ２１５２に送信する。

オーディオおよび／またはビデオコンテンツを配信するためのこの第５の実施形態では、あるデマルチキャスタデバイスによって別のデマルチキャスタデバイスに送信される要求ＲＥＱ＿ＣＨＫに対する各応答ＲＳＰ＿ＣＨＫは、以下に詳述するように、問題のデマルチキャスタデバイスに関する容量情報を含む。

したがって、ステップ９０３において、デマルチキャスタデバイスＤＭ２１５２は、選択されたオーディオおよび／またはビデオコンテンツを表す情報を含み、かつ選択されたオーディオおよび／またはビデオコンテンツが利用可能にされることの確認を要求する要求ＲＥＱ＿ＣＨＫをデマルチキャスタデバイスＤＭ１１５１に送信する。すでに説明したように、各デマルチキャスタデバイスは、プロバイダネットワークＰＮ１０２を介して、各デマルチキャスタデバイスに利用可能にされたオーディオおよび／またはビデオコンテンツのリストを格納する。

次に、ステップ９０４において、デマルチキャスタデバイスＤＭ１１５１は、ステップ９０３でデマルチキャスタデバイスＤＭ２１５２によって送信された要求ＲＥＱ＿ＣＨＫに対する応答ＲＳＰ＿ＣＨＫを送信する。エラーコードまたは確認コードを含むことに加えて、応答ＲＳＰ＿ＣＨＫは、（図７に関してすでに検討されたように）デマルチキャスタデバイスＤＭ１１５１に関連する容量情報をさらに含む。デマルチキャスタデバイスＤＭ１１５１が、選択されたオーディオおよび／またはビデオコンテンツを配信することができ、かつ応答ＲＳＰ＿ＣＨＫが、対応する確認コードを含む、と例示的に考えてみよう。

ステップ９０５において、デマルチキャスタデバイスＤＭ２１５２はまた、選択されたオーディオおよび／またはビデオコンテンツに対する要求ＲＥＱ＿ＣＨＫをデマルチキャスタデバイスＤＭ３１５３に送信する。次に、ステップ９０６において、デマルチキャスタデバイスＤＭ３１５３は、ステップ９０５でデマルチキャスタデバイスＤＭ２１５２によって送信された要求ＲＥＱ＿ＣＨＫに対する応答ＲＳＰ＿ＣＨＫを送信する。エラーコードまたは確認コードを含むことに加えて、応答ＲＳＰ＿ＣＨＫは、デマルチキャスタデバイスＤＭ３１５３に関連する容量情報をさらに含む。デマルチキャスタデバイスＤＭ３１５３が、選択されたオーディオおよび／またはビデオコンテンツを配信することができ、かつ応答ＲＳＰ＿ＣＨＫが、対応する確認コードを含む、と例示的に考えてみよう。

デマルチキャスタデバイスＤＭ２１５２は、自身の容量情報をさらに内部的に取得する。

デマルチキャスタデバイスＤＭ２１５２が、一旦ローカルエリアネットワークＬＡＮ１０１内に存在するすべてのデマルチキャスタデバイスの容量情報を収集すると、デマルチキャスタデバイスＤＭ２１５２は、図３に関してすでに述べた順序付きリストＬを構築するために、デマルチキャスタデバイスを、それらの容量情報に従って順序付けする。デマルチキャスタデバイスＤＭ２１５２は、ローカルエリアネットワークＬＡＮ１０１内に存在するデマルチキャスタデバイスの中で最も高い容量を示し、かつ問題のオーディオおよび／またはビデオコンテンツを配信できるデマルチキャスタデバイスを選択する。デマルチキャスタデバイスＤＭ２１５２が、一致して、デマルチキャスタデバイスＤＭ３１５３を選択する、と例示的に考えてみよう。

そうすると、ステップ９０７において、デマルチキャスタデバイスＤＭ２１５２は、ステップ９０２でアプリケーションＡＰＰ１１３１によって送信された要求ＲＥＱ＿ＣＨＫに対する応答ＲＳＰ＿ＣＨＫをアプリケーションＡＰＰ１１３１に送信する。応答ＲＳＰ＿ＣＨＫは、デマルチキャスタデバイスＤＭ３１５３が、選択されたオーディオおよび／またはビデオコンテンツを配信できることを示し、かつ対応する確認コードを含む。アプリケーションＡＰＰ１１３１は、オーディオおよび／またはビデオコンテンツを配信するための適切なデマルチキャスタデバイスを選択するために、デマルチキャスタデバイスＤＭ２１５２に依存するので、この応答ＲＳＰ＿ＣＨＫに容量情報を含める必要はない。

ステップ９０８において、アプリケーションＡＰＰ１１３１は、選択されたオーディオおよび／またはビデオコンテンツを消費するために、プレーヤーＰＬ１１２１を起動する。そうするために、アプリケーションＡＰＰ１１３１は、プレーヤーＰＬ１１２１に、デマルチキャスタデバイスＤＭ３１５３の識別子（例えば、デマルチキャスタデバイスＤＭ３１５３のＩＰアドレス）と、選択されたオーディオ／またはビデオコンテンツを表す情報（例えば、選択されたオーディオおよび／またはビデオコンテンツ、または好ましくは、それを表すマニフェストファイルを指すＵＲＬパス）とを含むメッセージＬＡＵＮＣＨを送信する。

次に、（図４に関して詳述されたように）プロセスＣ＿ＲＥＴ９０９が、選択されたオーディオおよび／またはビデオコンテンツを端末Ｔ１１１１に配信するために、プレーヤーＰＬ１１２１と、デマルチキャスタデバイスＤＭ３１５３との間で実行される。プロセスＣ＿ＲＥＴ４１００で説明したのと同じように、デマルチキャスタデバイスＤＭ３１５３は、要求ＲＥＱ＿Ｍを受信し、それに応答すると、セッションの開始の記録を実行する。アダプティブビットレートが実装されていない場合、マニフェストファイルは存在しない。したがって、一変形例では、デマルチキャスタデバイスＤＭ３１５３は、アプリケーションＡＰＰ１１３１から専用メッセージを受信すると、セッションの開始を検出する。別の変形例では、デマルチキャスタデバイスＤＭ３１５３は、問題のオーディオおよび／またはビデオコンテンツについてのプレーヤーＰＬ１１２１からの（シーケンスにおける）第１の要求ＲＥＱ＿Ｃを受信すると、セッションの開始を検出する。

ステップ９１０において、アプリケーションＡＰＰ１１３１は、プレーヤーＰＬ１１２１が、セッションを終了したことを検出する。これは、プレーヤーＰＬ１１２１が、アプリケーションＡＰＰ１１３１に、オーディオおよび／またはビデオコンテンツの消費が終了したことを（例えばメッセージＳＴＯＰによって）通知するによって行われ得る。

ステップ９１１において、アプリケーションＡＰＰ１１３１は、デマルチキャスタデバイスＤＭ３１５３に、オーディオおよび／またはビデオコンテンツの消費が終了したことを（例えば、メッセージＳＴＯＰによって）通知する。アプリケーションＡＰＰ１１３１からの通知のない変形例では、デマルチキャスタデバイスＤＭ３１５３は、プロセスＣ＿ＲＥＴ９０９での要求（ＲＥＱ＿ＭまたはＲＥＱ＿Ｃのいずれか）の最新の送信から所定の時間ＰＴ１が経過したときに、オーディオおよび／またはビデオコンテンツをプレーヤーＰＬ１１２１に配信するためのセッションが終了したことを検出し得る。これにより、デマルチキャスタデバイスＤＭ３１５３の内部で、セッションの停止の記録がトリガーされる（ステップ９１２）。

セッションの終了にもかかわらず、デマルチキャスタデバイスＤＭ３１５３は、所定の時間ＰＴ２の間、オーディオおよび／またはビデオコンテンツをプレーヤーＰＬ１１２１に配信するための可能性のある次のセッションのために、処理リソースを所定の位置に保持する。オーディオおよび／またはビデオコンテンツをプレーヤーＰＬ１１２１に配信するために、後続のセッションが、所定の時間ＰＴ２内に開始されない場合、デマルチキャスタデバイスＤＭ３１５３は、問題の処理リソースを解放する。

したがって、所定の時間ＰＴ２の満了前に新しいセッションが開始されることを考慮して、アプリケーションＡＰＰ１１３１は、ステップ９１３において、消費される同じまたは別のオーディオおよび／またはビデオコンテンツを選択する（プロセスＣ＿ＳＥＬ）。

次に、アプリケーションＡＰＰ１１３１は、デマルチキャスタデバイスＤＭ２１５２に、新たに選択されたオーディオおよび／またはビデオコンテンツが利用可能にされるかどうかを尋ねる。そうするために、ステップ９１４において、アプリケーションＡＰＰ１１３１は、新たに選択されたオーディオおよび／またはビデオコンテンツを表す情報を含み、かつ新たに選択されたオーディオおよび／またはビデオコンテンツが利用可能にされることの確認を要求する要求ＲＥＱ＿ＣＨＫをデマルチキャスタデバイスＤＭ２１５２に送信する。その結果、デマルチキャスタデバイスＤＭ２１５２は、消費される新たに選択されたオーディオおよび／またはビデオコンテンツが、端末Ｔ１１１１のための前のセッション中使用されたデマルチキャスタデバイス、つまりデマルチキャスタデバイスＤＭ３１５３を介して利用可能にされるかどうかをチェックする。したがって、ステップ９１５において、デマルチキャスタデバイスＤＭ２１５２は、要求ＲＥＱ＿ＣＨＫをデマルチキャスタデバイスＤＭ３１５３に送信することによって、新たに選択されたオーディオおよび／またはビデオコンテンツが、デマルチキャスタデバイスＤＭ３１５３を介して利用可能にされるかどうかをチェックする。ステップ９１６において、デマルチキャスタデバイスＤＭ３１５３は、ステップ９１５でデマルチキャスタデバイスＤＭ２１５２によって送信された要求ＲＥＱ＿ＣＨＫに対する応答ＲＳＰ＿ＣＨＫを送信する。エラーコードまたは確認コードを含むことに加えて、応答ＲＳＰ＿ＣＨＫは、デマルチキャスタデバイスＤＭ３１５３に関連する容量情報をさらに含む。デマルチキャスタデバイスＤＭ３１５３が、選択されたオーディオおよび／またはビデオコンテンツを配信することができ、かつ応答ＲＳＰ＿ＣＨＫが、対応する確認コードを含む、と例示的に考えてみよう。

ステップ９１７において、デマルチキャスタデバイスＤＭ２１５２は、ステップ９１４でアプリケーションＡＰＰ１１３１によって送信された要求ＲＥＱ＿ＣＨＫに対する応答ＲＳＰ＿ＣＨＫをアプリケーションＡＰＰ１１３１に送信する。応答ＲＳＰ＿ＣＨＫは、デマルチキャスタデバイスＤＭ３１５３が、選択されたオーディオおよび／またはビデオコンテンツを配信できることを示し、かつ対応する確認コードを含む。

ステップ９１８において、アプリケーションＡＰＰ１１３１は、新たに選択されたオーディオおよび／またはビデオコンテンツを消費するために、プレーヤーＰＬ１１２１を再起動する。そうするために、アプリケーションＡＰＰ１１３１は、プレーヤーＰＬ１１２１に、デマルチキャスタデバイスＤＭ３１５３の識別子（例えば、デマルチキャスタデバイスＤＭ３１５３のＩＰアドレス）と、新たに選択されたオーディオ／またはビデオコンテンツを表す情報（例えば、新たに選択されたオーディオおよび／またはビデオコンテンツ、または好ましくは、それを表すマニフェストファイルを指すＵＲＬパス）とを含むメッセージＬＡＵＮＣＨを送信する。次に、ステップ９１７において、新たに選択されたオーディオおよび／またはビデオコンテンツを配信するために、プロセスＣ＿ＲＥＴが繰り返される。プロセスＣ＿ＲＥＴ４１００で説明したのと同じように、デマルチキャスタデバイスＤＭ３１５３は、要求ＲＥＱ＿Ｍを受信し、それに応答すると、新しいセッションの開始の記録を実行する。一変形例では、デマルチキャスタデバイスＤＭ３１５３は、アプリケーションＡＰＰ１１３１から専用メッセージを受信すると、新しいセッションの開始を検出する。別の変形例では、デマルチキャスタデバイスＤＭ３１５３は、問題のオーディオおよび／またはビデオコンテンツについてのプレーヤーＰＬ１１２１からの（シーケンスにおける）第１の要求ＲＥＱ＿Ｃを受信すると、新しいセッションの開始を検出する。

アプリケーションＡＰＰ１１３１によって新しいセッションが開始される一方で、前のセッションの終了から所定の時間ＰＴ２が満了した場合、新しいセッションのための処理リソースの利用可能性は、デマルチキャスタデバイスＤＭ３１５３によって保証され得ない。したがって、デマルチキャスタデバイスＤＭ２１５２は、順序付きリストＬの更新されたバージョンを使用することによって、ローカルエリアネットワークＬＡＮ１０１内に存在するデマルチキャスタデバイスの中からデマルチキャスタを再び選択しなければならない。

図１０は、オーディオおよび／またはビデオコンテンツを配信するための第６の実施形態による、オーディオおよび／またはビデオコンテンツ配信システムで発生する交換を概略的に表す。この第６の実施形態の範囲内で、アプリケーションＡＰＰ１１３１は、デマルチキャスタデバイスＤＭ２１５２に依存して、オーディオおよび／またはビデオコンテンツを受信するための適切なデマルチキャスタデバイスを選択する。さらに、この第６の実施形態は、図８および図９に関して詳述した前述の第４および第５の実施形態の組み合わせである。そのように進めることで、ローカルエリアネットワークＬＡＮ１０１内に存在するデマルチキャスタデバイス間の負荷分散は、妥当な量のオーバーヘッドで、可能な限り安定したままである。

ステップ１０００において、アプリケーションＡＰＰ１１３１、デマルチキャスタデバイスＤＭ１１５１、デマルチキャスタデバイスＤＭ２１５２、およびデマルチキャスタデバイスＤＭ３１５３が、ステップ３０１に関してすでに説明したように、発見手順を実行する。

ステップ１００１において、デマルチキャスタデバイスＤＭ２１５２は、図７に関して上記で詳述したように、プロセスＤＭ＿ＣＣを実行する。したがって、デマルチキャスタデバイスＤＭ２１５２は、容量情報に従って、ローカルエリアネットワークＬＡＮ１０１内に存在するデマルチキャスタデバイスの順序付きリストＬを保持する。好ましくは、アプリケーションＡＰＰ１１３１がどのデマルチキャスタデバイスに依存するかを、デマルチキャスタデバイスが知らない状況に対処するために、ローカルエリアネットワークＬＡＮ１０１に存在するすべてのデマルチキャスタデバイスが、プロセスＤＭ＿ＣＣを実行し、それら自身のバージョンの順序付きリストＬを保持する。

ステップ１００２において、アプリケーションＡＰＰ１１３１は、消費されるオーディオおよび／またはビデオコンテンツを選択する（プロセスＣ＿ＳＥＬ）。

次に、ステップ１００３において、アプリケーションＡＰＰ１１３１は、消費されるオーディオおよび／またはビデオコンテンツが利用可能にされるかどうかを、デマルチキャスタデバイスＤＭ２１５２に尋ねる。そうするために、アプリケーションＡＰＰ１１３１は、要求ＲＥＱ＿ＣＨＫをデマルチキャスタデバイスＤＭ２１５２に送信する。その結果、デマルチキャスタデバイスＤＭ２１５２は、デマルチキャスタデバイスＤＭ２１５２によって保持される順序付きリストＬに従って、どのデマルチキャスタデバイスが、最も高い残存容量を示すかを決定する。デマルチキャスタデバイスＤＭ３１５３が、順序付きリストＬに従って最も高い容量を示す、と例示的に考えてみよう。

そうすると、デマルチキャスタデバイスＤＭ２１５２は、ステップ１００４において、要求ＲＥＱ＿ＣＨＫをデマルチキャスタデバイスＤＭ３１５３に送信する。要求ＲＥＱ＿ＣＨＫは、選択されたオーディオおよび／またはビデオコンテンツを表す情報を含み、かつデマルチキャスタデバイスＤＭ３１５３が、オーディオおよび／またはビデオコンテンツを端末Ｔ１１１１に提供できることの確認を要求するメッセージである。すでに述べたように、各デマルチキャスタデバイスは、プロバイダネットワークＰＮ１０２を介して、各デマルチキャスタデバイスに利用可能にされたオーディオおよび／またはビデオコンテンツのリストを格納する。ステップ１００５において、デマルチキャスタデバイスＤＭ３１５３は、ステップ１００４でデマルチキャスタデバイスＤＭ２１５２によって送信された要求ＲＥＱ＿ＣＨＫに対する応答ＲＳＰ＿ＣＨＫを送信する。応答ＲＳＰ＿ＣＨＫは、デマルチキャスタデバイスＤＭ３１５３が、選択されたオーディオおよび／またはビデオコンテンツを端末Ｔ１１１１に配信できない場合のエラーコード、またはさもなければ確認コードのいずれかを含む。応答ＲＳＰ＿ＣＨＫは、デマルチキャスタデバイスＤＭ３１５３に関連する容量情報をさらに含む。デマルチキャスタデバイスＤＭ３１５３が、選択されたオーディオおよび／またはビデオコンテンツを配信することができ、かつ応答ＲＳＰ＿ＣＨＫが、対応する確認コードを含む、と例示的に考えてみ、さらに、プロセスＤＭ＿ＣＣ１００１の実行以降、デマルチキャスタデバイスＤＭ３１５３に関連する容量情報が変化していない、と例示的に考えてみよう。

ステップ１００６において、デマルチキャスタデバイスＤＭ２１５２は、ステップ１００３でアプリケーションＡＰＰ１１３１によって送信された要求ＲＥＱ＿ＣＨＫに対する応答ＲＳＰ＿ＣＨＫをアプリケーションＡＰＰ１１３１に送信する。応答ＲＳＰ＿ＣＨＫは、デマルチキャスタデバイスＤＭ３１５３が、選択されたオーディオおよび／またはビデオコンテンツを配信できることを示し、かつ対応する確認コードを含む。アプリケーションＡＰＰ１１３１は、オーディオおよび／またはビデオコンテンツを配信するための適切なデマルチキャスタデバイスを選択するために、デマルチキャスタデバイスＤＭ２１５２に依存するので、この応答ＲＳＰ＿ＣＨＫに容量情報を含める必要はない。

ステップ１００７において、アプリケーションＡＰＰ１１３１は、選択されたオーディオおよび／またはビデオコンテンツを消費するために、プレーヤーＰＬ１１２１を起動する。そうするために、アプリケーションＡＰＰ１１３１は、プレーヤーＰＬ１１２１に、デマルチキャスタデバイスＤＭ３１５３の識別子（例えば、デマルチキャスタデバイスＤＭ３１５３のＩＰアドレス）と、選択されたオーディオ／またはビデオコンテンツを表す情報（例えば、選択されたオーディオおよび／またはビデオコンテンツ、または好ましくは、それを表すマニフェストファイルを指すＵＲＬパス）とを含むメッセージＬＡＵＮＣＨを送信する。

次に、（図４に関して詳述されたように）プロセスＣ＿ＲＥＴ１００８が、選択されたオーディオおよび／またはビデオコンテンツを端末Ｔ１１１１に配信するために、プレーヤーＰＬ１１２１と、デマルチキャスタデバイスＤＭ３１５３との間で実行される。プロセスＣ＿ＲＥＴ４１００で説明したのと同じように、デマルチキャスタデバイスＤＭ３１５３は、要求ＲＥＱ＿Ｍを受信し、それに応答すると、セッションの開始の記録を実行する。アダプティブビットレートが実装されていない場合、マニフェストファイルは存在しない。したがって、一変形例では、デマルチキャスタデバイスＤＭ３１５３は、アプリケーションＡＰＰ１１３１から専用メッセージを受信すると、セッションの開始を検出する。別の変形例では、デマルチキャスタデバイスＤＭ３１５３は、問題のオーディオおよび／またはビデオコンテンツについてのプレーヤーＰＬ１１２１からの（シーケンスにおける）第１の要求ＲＥＱ＿Ｃを受信すると、セッションの開始を検出する。

さらに、一旦プロセスＣ＿ＲＥＴ１００８が開始されると（例えば、所定の時間ＰＴ３が経過した後）、デマルチキャスタデバイスＤＭ２１５２は、プロセスＣ＿ＲＥＴ１００８のセッションの設定を考慮するために、デマルチキャスタデバイスＤＭ３１５３に関連する容量情報を更新する。要求ＲＥＱ＿ＣＡＰおよび対応する応答ＲＳＰ＿ＣＡＰに基づく交換を使用して、これを行うことができる（図１０には示されていない）。

ステップ１００９において、アプリケーションＡＰＰ１１３１は、プレーヤーＰＬ１１２１が、セッションを終了したことを検出する。これは、プレーヤーＰＬ１１２１が、アプリケーションＡＰＰ１１３１に、オーディオおよび／またはビデオコンテンツの消費が終了したことを（例えばメッセージＳＴＯＰによって）通知するによって行われ得る。

ステップ１０１０において、アプリケーションＡＰＰ１１３１は、デマルチキャスタデバイスＤＭ３１５３に、オーディオおよび／またはビデオコンテンツの消費が終了したことを（例えば、メッセージＳＴＯＰによって）通知する。アプリケーションＡＰＰ１１３１からの通知のない変形例では、デマルチキャスタデバイスＤＭ３１５３は、プロセスＣ＿ＲＥＴ１００８での要求（ＲＥＱ＿ＭまたはＲＥＱ＿Ｃのいずれか）の最新の送信から所定の時間ＰＴ１が経過したときに、オーディオおよび／またはビデオコンテンツをプレーヤーＰＬ１１２１に配信するためのセッションが終了したことを検出し得る。これにより、デマルチキャスタデバイスＤＭ３１５３の内部で、セッションの停止の記録がトリガーされる（ステップ１０１１）。

セッションの終了にもかかわらず、デマルチキャスタデバイスＤＭ３１５３は、オーディオおよび／またはビデオコンテンツをプレーヤーＰＬ１１２１に配信するための可能性のある次のセッションのために、処理リソースを所定の位置に保持する。問題の処理リソースが、所定の時間ＰＴ２の間、所定の位置に保持される。オーディオおよび／またはビデオコンテンツをプレーヤーＰＬ１１２１に配信するために、後続のセッションが、所定の時間ＰＴ２内に開始されない場合、デマルチキャスタデバイスＤＭ３１５３は、問題の処理リソースを解放する。アプリケーションＡＰＰ１１３１によって新しいセッションが開始される一方で、前のセッションの終了から所定の時間ＰＴ２が満了した場合、新しいセッションのための処理リソースの利用可能性は、デマルチキャスタデバイスＤＭ３１５３によって保証され得ない。したがって、デマルチキャスタデバイスＤＭ２１５２は、順序付きリストＬの更新されたバージョンを使用することによって、ローカルエリアネットワークＬＡＮ１０１内に存在するデマルチキャスタデバイスの中からデマルチキャスタを再び選択しなければならない。

したがって、所定の時間ＰＴ２の満了前に新しいセッションが開始されることを考慮して、アプリケーションＡＰＰ１１３１は、ステップ１０１２において、消費される同じまたは別のオーディオおよび／またはビデオコンテンツを選択する（プロセスＣ＿ＳＥＬ）。

次に、アプリケーションＡＰＰ１１３１は、デマルチキャスタデバイスＤＭ２１５２に、新たに選択されたオーディオおよび／またはビデオコンテンツが利用可能にされるかどうかを尋ねる。そうするために、ステップ１０１３において、アプリケーションＡＰＰ１１３１は、新たに選択されたオーディオおよび／またはビデオコンテンツを表す情報を含み、かつ新たに選択されたオーディオおよび／またはビデオコンテンツが利用可能にされることの確認を要求する要求ＲＥＱ＿ＣＨＫをデマルチキャスタデバイスＤＭ２１５２に送信する。その結果、デマルチキャスタデバイスＤＭ２１５２は、消費される新たに選択されたオーディオおよび／またはビデオコンテンツが、端末Ｔ１１１１のための前のセッション中使用されたデマルチキャスタデバイス、つまりデマルチキャスタデバイスＤＭ３１５３を介して利用可能にされるかどうかをチェックする。したがって、ステップ１０１４において、デマルチキャスタデバイスＤＭ２１５２は、要求ＲＥＱ＿ＣＨＫをデマルチキャスタデバイスＤＭ３１５３に送信することによって、新たに選択されたオーディオおよび／またはビデオコンテンツが、デマルチキャスタデバイスＤＭ３１５３を介して利用可能にされるかどうかをチェックする。ステップ１０１５において、デマルチキャスタデバイスＤＭ３１５３は、ステップ１０１４でデマルチキャスタデバイスＤＭ２１５２によって送信された要求ＲＥＱ＿ＣＨＫに対する応答ＲＳＰ＿ＣＨＫを送信する。応答ＲＳＰ＿ＣＨＫは、デマルチキャスタデバイスＤＭ３１５３に関連する容量情報をさらに含む。デマルチキャスタデバイスＤＭ３１５３が、選択されたオーディオおよび／またはビデオコンテンツを配信することができ、かつ応答ＲＳＰ＿ＣＨＫが、対応する確認コードを含む、と例示的に考えてみるが、プロセスＣ＿ＲＥＴ１００８の実行以降、デマルチキャスタデバイスＤＭ３１５３に関連する容量情報が変化した、とさらに例示的に考えてみよう。

したがって、ステップ１０１６において、デマルチキャスタデバイスＤＭ２１５２は、デマルチキャスタデバイスＤＭ３１５３によって送信された応答ＲＳＰ＿ＣＨＫに含まれる容量情報が、デマルチキャスタデバイスＤＭ３１５３によって以前に送信され、順序付きリストＬの現在のバージョンを構築または更新するために使用された容量情報と比較して、容量変化を示すかどうかをチェックする。容量変化がある場合、デマルチキャスタデバイスＤＭ２１５２は、ローカルエリアネットワークＬＡＮ１０１内に存在する他のデマルチキャスタデバイスに、それらのそれぞれの容量を更新するために、問い合わせる。

したがって、ステップ１０１７において、デマルチキャスタデバイスＤＭ２１５２は、要求ＲＥＱ＿ＣＡＰをデマルチキャスタデバイスＤＭ１１５１に送信する。ステップ１０１８において、デマルチキャスタデバイスＤＭ１１５１は、ステップ１０１７でデマルチキャスタデバイスＤＭ２１５２によって送信された要求ＲＥＱ＿ＣＡＰに対する応答ＲＳＰ＿ＣＡＰを送信し、応答ＲＳＰ＿ＣＡＰは、要求ＲＥＱ＿ＣＡＰによって要求された容量情報を含む。

デマルチキャスタデバイスＤＭ２１５２が、一旦ローカルエリアネットワークＬＡＮ１０１内に存在するすべてのデマルチキャスタデバイスの容量情報を収集すると、デマルチキャスタデバイスＤＭ２１５２は、順序付きリストＬを更新するために、デマルチキャスタデバイスを、それらの容量情報に従って順序付けする。デマルチキャスタデバイスＤＭ２１５２は、ステップ１０１９において、容量情報が、ローカルエリアネットワークＬＡＮ１０１内に存在するデマルチキャスタデバイスの中で最も高い残存容量を示すデマルチキャスタデバイスを、オーディオおよび／またはビデオコンテンツ配信システム１００へのデフォルトのエントリポイントとして選択する。選択されたデマルチキャスタデバイスが、デマルチキャスタデバイスＤＭ２１５２でない場合、デマルチキャスタデバイスＤＭ２１５２は、図６に関してすでに説明したように、新たに選択されたオーディオおよび／またはビデオコンテンツが、要求ＲＥＱ＿ＣＨＫの結果選択されたデマルチキャスタデバイスを介して利用可能にされるかどうかをチェックする。そうでない場合、デマルチキャスタデバイスＤＭ２１５２は、順序付きリストＬ内の次のデマルチキャスタデバイスを考慮する。デマルチキャスタデバイスＤＭ２１５２が、順序付きリストＬ内で最も高い容量を示す、と例示的に考え、さらに、デマルチキャスタデバイスＤＭ２１５２が、新たに選択されたオーディオおよび／またはビデオコンテンツを配信できる、と例示的に考えてみよう。

そうすると、ステップ１０２０において、デマルチキャスタデバイスＤＭ２１５２は、ステップ１０１３でアプリケーションＡＰＰ１１３１によって送信された要求ＲＥＱ＿ＣＨＫに対する応答ＲＳＰ＿ＣＨＫをアプリケーションＡＰＰ１１３１に送信する。応答ＲＳＰ＿ＣＨＫは、デマルチキャスタデバイスＤＭ２１５２が、選択されたオーディオおよび／またはビデオコンテンツを配信できることを示し、かつ対応する確認コードを含む。アプリケーションＡＰＰ１１３１は、オーディオおよび／またはビデオコンテンツを配信するための適切なデマルチキャスタデバイスを選択するために、デマルチキャスタデバイスＤＭ２１５２に依存するので、この応答ＲＳＰ＿ＣＨＫに容量情報を含める必要はない。

ステップ１０２１において、アプリケーションＡＰＰ１１３１は、新たに選択されたオーディオおよび／またはビデオコンテンツを消費するために、プレーヤーＰＬ１１２１を再起動する。そうするために、アプリケーションＡＰＰ１１３１は、プレーヤーＰＬ１１２１に、デマルチキャスタデバイスＤＭ２１５２の識別子（例えば、デマルチキャスタデバイスＤＭ２１５２のＩＰアドレス）と、新たに選択されたオーディオ／またはビデオコンテンツを表す情報（例えば、新たに選択されたオーディオおよび／またはビデオコンテンツ、または好ましくは、それを表すマニフェストファイルを指すＵＲＬパス）とを含むメッセージＬＡＵＮＣＨを送信する。次に、ステップ１０２２において、プロセスＣ＿ＲＥＴが、新たに選択されたオーディオおよび／またはビデオコンテンツを配信するために、プレーヤーＰＬ１１２１と、デマルチキャスタデバイスＤＭ２１５２との間で実行される。プロセスＣ＿ＲＥＴ４１００で説明したのと同じように、デマルチキャスタデバイスＤＭ２１５２は、要求ＲＥＱ＿Ｍを受信し、それに応答すると、新しいセッションの開始の記録を実行する。一変形例では、デマルチキャスタデバイスＤＭ３１５３は、アプリケーションＡＰＰ１１３１から専用メッセージを受信すると、新しいセッションの開始を検出する。別の変形例では、デマルチキャスタデバイスＤＭ３１５３は、問題のオーディオおよび／またはビデオコンテンツについてのプレーヤーＰＬ１１２１からの（シーケンスにおける）第１の要求ＲＥＱ＿Ｃを受信すると、新しいセッションの開始を検出する。

図１１Ａおよび図１１Ｂは、オーディオおよび／またはビデオコンテンツを配信するための第７の実施形態による、オーディオおよび／またはビデオコンテンツ配信システムで発生する交換を共同して概略的に表す。この第７の実施形態では、マルチパスが考慮され、これは、消費されるオーディオおよび／またはビデオコンテンツが、複数のデマルチキャスタデバイスを介して取得されることを意味する。この第７の実施形態の範囲内で、アプリケーションＡＰＰ１１３１は、デマルチキャスタデバイスＤＭ２１５２に依存して、オーディオおよび／またはビデオコンテンツを受信するための適切なデマルチキャスタデバイスを選択する。

マルチパス配信を実装するために、ローカルエリアネットワークＬＡＮ１０１は、プロキシデバイスＰＸＹ１１００をさらに含む。プロキシデバイスＰＸＹ１１００は、端末Ｔ１１１１とは、およびデマルチキャスタデバイスＤＭ１１５１、ＤＭ２１５２、ＤＭ３１５３のうちのいずれか１つとは異なるデバイスであり得る。プロキシデバイスＰＸＹ１１００は、一変形例では、端末Ｔ１１１１内に含まれ得る。プロキシデバイスＰＸＹ１１００は、別の変形例では、デマルチキャスタデバイスＤＭ１１５１、ＤＭ２１５２、ＤＭ３１５３のうちの１つに含まれ得る。

ステップ１１０１において、アプリケーションＡＰＰ１１３１、デマルチキャスタデバイスＤＭ１１５１、デマルチキャスタデバイスＤＭ２１５２、およびデマルチキャスタデバイスＤＭ３１５３が、ステップ３０１に関してすでに説明したように、発見手順を実行する。プロキシデバイスＰＸＹ１１００は、ローカルエリアネットワークＬＡＮ１０１内での自身の存在をアナウンスするために、発見手順に関与し得る。

ステップ１１０２において、アプリケーションＡＰＰ１１３１は、消費されるオーディオおよび／またはビデオコンテンツを選択する（プロセスＣ＿ＳＥＬ）。

次に、ステップ１１０３において、アプリケーションＡＰＰ１１３１は、消費されるオーディオおよび／またはビデオコンテンツが利用可能にされるかどうかを、デマルチキャスタデバイスＤＭ２１５２に尋ねる。そうするために、アプリケーションＡＰＰ１１３１は、選択されたオーディオおよび／またはビデオコンテンツを表す情報を含み、かつ選択されたオーディオおよび／またはビデオコンテンツが利用可能にされることの確認を要求する要求ＲＥＱ＿ＣＨＫをデマルチキャスタデバイスＤＭ２１５２に送信する。

オーディオおよび／またはビデオコンテンツを配信するためのこの第７の実施形態では（図９の第５の実施形態のように）、あるデマルチキャスタデバイスによって別のデマルチキャスタデバイスに送信される要求ＲＥＱ＿ＣＨＫに対する各応答ＲＳＰ＿ＣＨＫは、以下に詳述するように、問題のデマルチキャスタデバイスに関する容量情報を含む。

したがって、ステップ１１０４において、デマルチキャスタデバイスＤＭ２１５２は、選択されたオーディオおよび／またはビデオコンテンツを表す情報を含み、かつ選択されたオーディオおよび／またはビデオコンテンツが利用可能にされることの確認を要求する要求ＲＥＱ＿ＣＨＫをデマルチキャスタデバイスＤＭ１１５１に送信する。すでに説明したように、各デマルチキャスタデバイスは、プロバイダネットワークＰＮ１０２を介して、各デマルチキャスタデバイスに利用可能にされたオーディオおよび／またはビデオコンテンツのリストを格納する。

次に、ステップ１１０５において、デマルチキャスタデバイスＤＭ１１５１は、ステップ１１０４でデマルチキャスタデバイスＤＭ２１５２によって送信された要求ＲＥＱ＿ＣＨＫに対する応答ＲＳＰ＿ＣＨＫを送信する。エラーコードまたは確認コードを含むことに加えて、応答ＲＳＰ＿ＣＨＫは、（図７に関してすでに検討されたように）デマルチキャスタデバイスＤＭ１１５１に関連する容量情報をさらに含む。デマルチキャスタデバイスＤＭ１１５１が、選択されたオーディオおよび／またはビデオコンテンツを配信することができ、かつ応答ＲＳＰ＿ＣＨＫが、対応する確認コードを含む、と例示的に考えてみよう。

ステップ１１０６において、デマルチキャスタデバイスＤＭ２１５２はまた、選択されたオーディオおよび／またはビデオコンテンツに対する要求ＲＥＱ＿ＣＨＫをデマルチキャスタデバイスＤＭ３１５３に送信する。次に、ステップ１１０７において、デマルチキャスタデバイスＤＭ３１５３は、ステップ１１０６でデマルチキャスタデバイスＤＭ２１５２によって送信された要求ＲＥＱ＿ＣＨＫに対する応答ＲＳＰ＿ＣＨＫを送信する。エラーコードまたは確認コードを含むことに加えて、応答ＲＳＰ＿ＣＨＫは、デマルチキャスタデバイスＤＭ３１５３に関連する容量情報をさらに含む。デマルチキャスタデバイスＤＭ３１５３が、選択されたオーディオおよび／またはビデオコンテンツを配信することができ、かつ応答ＲＳＰ＿ＣＨＫが、対応する確認コードを含む、と例示的に考えてみよう。

デマルチキャスタデバイスＤＭ２１５２は、自身の容量情報をさらに内部的に取得する。

デマルチキャスタデバイスＤＭ２１５２が、一旦ローカルエリアネットワークＬＡＮ１０１内に存在するすべてのデマルチキャスタデバイスの容量情報を収集すると、デマルチキャスタデバイスＤＭ２１５２は、図３に関してすでに述べた順序付きリストＬを構築するために、デマルチキャスタデバイスを、それらの容量情報に従って順序付けする。

デマルチキャスタデバイスＤＭ２１５２は、ローカルエリアネットワークＬＡＮ１０１内に存在するデマルチキャスタデバイスの中で最も高い容量を示し、かつ問題のオーディオおよび／またはビデオコンテンツを配信できる、所定の数Ｎ（Ｎ＞１）のデマルチキャスタデバイスを選択する。Ｎ＝２であり、かつデマルチキャスタデバイスＤＭ２１５２が、一致して、デマルチキャスタデバイスＤＭ２１５２と、デマルチキャスタデバイスＤＭ３１５３とを選択する、と例示的に考えてみよう。

そうすると、ステップ１１０８において、デマルチキャスタデバイスＤＭ２１５２は、ステップ１１０３でアプリケーションＡＰＰ１１３１によって送信された要求ＲＥＱ＿ＣＨＫに対する応答ＲＳＰ＿ＣＨＫをアプリケーションＡＰＰ１１３１に送信する。応答ＲＳＰ＿ＣＨＫは、デマルチキャスタデバイスＤＭ２１５２およびデマルチキャスタデバイスＤＭ３１５３が、選択されたオーディオおよび／またはビデオコンテンツを配信できることを示し、かつ応答ＲＳＰ＿ＣＨＫは、対応する確認コードを含む。アプリケーションＡＰＰ１１３１は、オーディオおよび／またはビデオコンテンツを配信するための適切なデマルチキャスタデバイスを選択するために、デマルチキャスタデバイスＤＭ２１５２に依存するので、この応答ＲＳＰ＿ＣＨＫに容量情報を含める必要はない。

アプリケーションＡＰＰ１１３１がマルチパス対応でない場合、アプリケーションＡＰＰ１１３１は、応答ＲＳＰ＿ＣＨＫで最初に引用されたデマルチキャスタデバイスのみを考慮し、応答ＲＳＰ＿ＣＨＫに含まれている他のすべてのデマルチキャスタデバイスに関連する情報を撤回することに留意されたい。

ステップ１１０９において、アプリケーションＡＰＰ１１３１は、選択されたオーディオおよび／またはビデオコンテンツを消費するために、プレーヤーＰＬ１１２１を起動する。そうするために、アプリケーションＡＰＰ１１３１は、プレーヤーＰＬ１１２１に、プロキシデバイスＰＸＹ１１００の識別子（例えば、プロキシデバイスＰＸＹ１１００のＩＰアドレス）と、選択されたオーディオ／またはビデオコンテンツを表す情報（例えば、選択されたオーディオおよび／またはビデオコンテンツ、または好ましくは、それを表すマニフェストファイルを指すＵＲＬパス）とを含むメッセージＬＡＵＮＣＨを送信する。メッセージＬＡＵＮＣＨは、選択されたオーディオおよび／またはビデオコンテンツのマルチパス配信のために使用される各デマルチキャスタデバイスの識別子（例えば、問題のデマルチキャスタのＩＰアドレス）を（例えば、インラインパラメータとして）さらに含む。したがって、この例では、デマルチキャスタデバイスＤＭ２１５２の、およびデマルチキャスタデバイスＤＭ３１５３の識別子（例えば、それらのＩＰアドレス）は、ステップ１１０９のメッセージＬＡＵＮＣＨ内に、例えば、インラインパラメータとして提供される。

次に、プレーヤーＰＬ１１２１は、問題のオーディオおよび／またはビデオコンテンツのセグメントを受信するためにプロキシデバイスＰＸＹ１１００と通信し、プロキシデバイスＰＸＹ１１００は、デマルチキャスタデバイスＤＭ２１５２およびデマルチキャスタデバイスＤＭ３１５３を用いたマルチパス配信を（プレーヤーＰＬ１１２１２の観点から）透明に管理する。

したがって、ステップ１１１１において、プレーヤーＰＬ１１２１は、選択されたオーディオおよび／またはビデオコンテンツのマニフェストファイルを、応答して、取得するために、（ＬＡＵＮＣＨメッセージのコンテンツに従って）要求ＲＥＱ＿ＭをプロキシデバイスＰＸＹ１１００に送信する。したがって、要求ＲＥＱ＿Ｍは、選択されたオーディオおよび／またはビデオコンテンツを表す情報（例えば、ＬＡＵＮＣＨメッセージ内に提供される、マニフェストファイルを指すＵＲＬパス）を含む。次に、ステップ１１１２において、プロキシデバイスＰＸＹ１１００は、そのような要求ＲＥＱ＿ＭをデマルチキャスタデバイスＤＭ２１５２に送信し、ステップ１１１３において、そのような要求ＲＥＱ＿ＭをデマルチキャスタデバイスＤＭ３１５３に送信する。その結果、ステップ１１１４において、デマルチキャスタデバイスＤＭ２１５２は、要求されたマニフェストファイルを送信することによって、プロキシデバイスＰＸＹ１１００に対し、選択されたオーディオおよび／またはビデオコンテンツの利用可能性を確認する。また、ステップ１１１６において、デマルチキャスタデバイスＤＭ３１５３は、要求されたマニフェストファイルを送信することによって、プロキシデバイスＰＸＹ１１００に対し、選択されたオーディオおよび／またはビデオコンテンツの利用可能性を確認する。次に、ステップ１１１８において、プロキシデバイスＰＸＹ１１００は、要求されたマニフェストファイルを送信することによって、プレーヤーＰＬ１１２１に対し、選択されたオーディオおよび／またはビデオコンテンツの利用可能性を確認する。要求ＲＥＱ＿Ｍを受信して、それに応答すると、デマルチキャスタデバイスＤＭ２１５２（ステップ１１１５）およびデマルチキャスタデバイスＤＭ３１５３（ステップ１１１７）の内部で、セッションの開始の記録がトリガーされる。ここで、要求ＲＥＱ＿Ｍを受信して、それに応答することを使用して、セッションの開始が検出されるため、プロキシデバイスＰＸＹ１１００は、問題のオーディオおよび／またはビデオコンテンツのセグメントを受信するために使用されるデマルチキャスタデバイスのうちの各デマルチキャスタデバイスにマニフェストファイルを要求する必要があることに留意されたい。アダプティブビットレートが実装されていない場合、マニフェストファイルは存在しない。したがって、一変形例では、デマルチキャスタデバイスＤＭ２１５２およびデマルチキャスタデバイスＤＭ３１５３は、プロキシデバイスＰＸＹ１１００から専用メッセージを受信すると、セッションの開始を検出する。別の変形例では、デマルチキャスタデバイスＤＭ３１５３は、問題のオーディオおよび／またはビデオコンテンツに対するプロキシデバイスＰＸＹ１１００からの（以下に詳述されるように）（シーケンスにおける）第１の要求ＲＥＱ＿Ｃを受信すると、セッションの開始を検出する。

ステップ１１１１～１１１８は、選択されたオーディオおよび／またはビデオコンテンツのマニフェストファイルを取得するプロセスＭＭ＿ＲＥＴ１１１０を共同して形成する。

次に、ステップ１１２１において、プレーヤーＰＬ１１２１は、要求ＲＥＱ＿ＣをプロキシデバイスＰＸＹ１１００に送信する。要求ＲＥＱ＿Ｃは、選択されたオーディオおよび／またはビデオコンテンツの少なくとも１つのセグメントを受信することを要求するユニキャストメッセージである。したがって、要求ＲＥＱ＿Ｃは、選択されたオーディオおよび／またはビデオコンテンツを表す情報（例えば、選択されたオーディオおよび／またはビデオコンテンツを指すＵＲＬパス）を含む。例えば、要求ＲＥＱ＿Ｃは、ＨＴＴＰ Ｇｅｔメッセージであり、少なくとも１つのセグメントがどの表現（品質）で要求されているかを示すパラメータをさらに含む。要求ＲＥＱ＿Ｃは、ステップ１１０９のメッセージＬＡＵＮＣＨ内にアプリケーションＡＰＰ１１３１によって提供された追加のパラメータ（例えば、インラインパラメータ）、つまり、デマルチキャスタデバイスＤＭ２１５２の、およびデマルチキャスタデバイスＤＭ３１５３の識別子をさらに含む。したがって、プロキシデバイスＰＸＹ１１００は、ステップ１１２１でプレーヤーＰＬ１１２１によって送信された要求ＲＥＱ＿Ｃから、どのデマルチキャスタデバイスが、マルチパス配信のために使用されるべきかを知る。

その結果、ステップ１１２２において、プロキシデバイスＰＸＹ１１００は、要求ＲＥＱ＿ＣをデマルチキャスタデバイスＤＭ２１５２に、またはステップ１１２３において、デマルチキャスタデバイスＤＭ３１５３に、送信する。要求ＲＥＱ＿Ｃは、プレーヤーＰＬ１２１によって要求される、選択されたオーディオおよび／またはビデオコンテンツの少なくとも１つのセグメントを受信することを要求するユニキャストメッセージである。したがって、プロキシデバイスＰＸＹ１１００によって送信される要求ＲＥＱ＿Ｃは、選択されたオーディオおよび／またはビデオコンテンツを表す情報（例えば、選択されたオーディオおよび／またはビデオコンテンツを指すＵＲＬパス）を含む。プロキシデバイスＰＸＹ１１００は、デマルチキャスタデバイスＤＭ２１５２およびデマルチキャスタデバイスＤＭ３１５３のうちのどのデマルチキャスタデバイスに、要求ＲＥＱ＿Ｃが送信されなければならないかを、所定の負荷分散ルールに従って、選択する。例えば、負荷分散ルールは、ラウンドロビンタイプのものであり得る。ステップ１１２４において、ステップ１１２２で送信された要求ＲＥＱ＿Ｃに応答して、デマルチキャスタデバイスＤＭ２１５２は、オーディオおよび／またはビデオコンテンツの少なくとも１つのセグメントを含む応答ＲＳＰ＿Ｃを送信する。ステップ１１２５において、ステップ１１２３で送信された要求ＲＥＱ＿Ｃに応答して、デマルチキャスタデバイスＤＭ３１５３は、オーディオおよび／またはビデオコンテンツの少なくとも１つのセグメントを含む応答ＲＳＰ＿Ｃを送信する。

次に、ステップ１１２６において、プロキシデバイスＰＸＹ１１００は、ステップ１１２１でプレーヤーＰＬ１１２１によって送信された要求ＲＥＱ＿Ｃに応答して、応答ＲＳＰ＿ＣをプレーヤーＰＬ１１２１に送信する。応答ＲＳＰ＿Ｃは、ステップ１１２４でデマルチキャスタデバイスＤＭ２１５２から受信されたか、またはステップ１１２５でデマルチキャスタデバイスＤＭ３１５３から受信されたかのいずれかのオーディオおよび／またはビデオコンテンツの少なくとも１つのセグメントを含む。したがって、プレーヤーＰＬ１１２１は、受信された少なくとも１つのセグメントを消費し得る。ステップ１１２１～１１２６は、プレーヤーＰＬ１１２１が、選択されたオーディオおよび／またはビデオコンテンツの少なくとも１つの後続のセグメントをさらに受信することを可能にするために、繰り返され得る。

ステップ１１２１～１１２６は、選択されたオーディオおよび／またはビデオコンテンツを配信するプロセスＭＣ＿ＲＥＴ１１２０を共同して形成する。

ここで（考慮事項を理解するためのプロセスＭＣ＿ＲＥＴ１１２０も登場する）図１１Ｂに移ると、アプリケーションＡＰＰ１３１１は、ステップ１１３０において、プレーヤーＰＬ１１２１がセッションを終了したことを検出する。これは、プレーヤーＰＬ１１２１が、アプリケーションＡＰＰ１１３１に、オーディオおよび／またはビデオコンテンツの消費が終了したことを（例えばメッセージＳＴＯＰによって）通知するによって行われ得る。

ステップ１１３１において、アプリケーションＡＰＰ１１３１は、オーディオおよび／またはビデオコンテンツの消費が終了したことを（例えば、メッセージＳＴＯＰによって）デマルチキャスタデバイスＤＭ２１５２に通知し、ステップ１１３３において、アプリケーションＡＰＰ１１３１は、オーディオおよび／またはビデオコンテンツの消費が終了したことを（例えば、メッセージＳＴＯＰによって）デマルチキャスタデバイスＤＭ３１５３に通知する。アプリケーションＡＰＰ１１３１からの通知のない変形例では、デマルチキャスタデバイスＤＭ２１５２およびデマルチキャスタデバイスＤＭ３１５３は、プロセスＭＣ＿ＲＥＴ１１２０での要求（ＲＥＱ＿ＭまたはＲＥＱ＿Ｃのいずれか）の最新の送信から所定の時間ＰＴ１が経過したときに、オーディオおよび／またはビデオコンテンツを、プロキシデバイスＰＸＹ１１００を介してプレーヤーＰＬ１１２１に配信するためのセッションが終了したことを検出し得る。これにより、デマルチキャスタデバイスＤＭ２１５２の内部で（ステップ１１３２）、およびデマルチキャスタデバイスＤＭ３１５３の内部で（ステップ１１３４）、セッションの停止の記録がトリガーされる。

セッションの終了にもかかわらず、デマルチキャスタデバイスＤＭ２１５２およびデマルチキャスタデバイスＤＭ３１５３は、オーディオおよび／またはビデオコンテンツを、プロキシデバイスＰＸＹ１１００を介してプレーヤーＰＬ１１２１に配信するための可能性のある次のセッションのために、処理リソースを所定の位置に保持する。問題の処理リソースが、所定の時間ＰＴ２の間、所定の位置に保持される。オーディオおよび／またはビデオコンテンツを、プロキシＰＸＹ１１００を介してプレーヤーＰＬ１１２１に配信するために、後続のセッションが、所定の時間ＰＴ２内に開始されない場合、デマルチキャスタデバイスＤＭ２１５２およびデマルチキャスタデバイスＤＭ３１５３は、問題の処理リソースを解放する。新しいセッションが開始される一方で、前のセッションの終了から所定の時間ＰＴ２が満了した場合、新しいセッションのための処理リソースの利用可能性は、デマルチキャスタデバイスＤＭ２１５２およびデマルチキャスタデバイスＤＭ３１５３によって保証され得ない。次に、順序付きリストＬの更新されたバージョンを使用して、マルチパス配信のためのデマルチキャスタの新たな選択が実行されなければならないであろう。

したがって、所定の時間ＰＴ２の満了前に新しいセッションが開始されることを考慮して、アプリケーションＡＰＰ１１３１は、ステップ１１３５において、消費される同じまたは別のオーディオおよび／またはビデオコンテンツを選択する（プロセスＣ＿ＳＥＬ）。

次に、ステップ１１３６において、アプリケーションＡＰＰ１１３１は、消費される新たに選択されたオーディオおよび／またはビデオコンテンツが利用可能にされるかどうかを、デマルチキャスタデバイスＤＭ２１５２に尋ねる。そうするために、アプリケーションＡＰＰ１１３１は、新たに選択されたオーディオおよび／またはビデオコンテンツを表す情報を含み、かつ新たに選択されたオーディオおよび／またはビデオコンテンツが利用可能にされることの確認を要求する要求ＲＥＱ＿ＣＨＫをデマルチキャスタデバイスＤＭ２１５２に送信する。

したがって、ステップ１１３７において、デマルチキャスタデバイスＤＭ２１５２は、新たに選択されたオーディオおよび／またはビデオコンテンツを表す情報を含み、かつ新たに選択されたオーディオおよび／またはビデオコンテンツが利用可能にされることの確認を要求する要求ＲＥＱ＿ＣＨＫをデマルチキャスタデバイスＤＭ３１５３に送信する。デマルチキャスタデバイスＤＭ２１５２は、プロキシデバイスＰＸＹ１１００を介したプレーヤーＰＬ１１２１での前のセッションのためのマルチパス配信で、デマルチキャスタデバイスＤＭ３１５３が暗示されているため、要求ＲＥＱ＿ＣＨＫをデマルチキャスタデバイスＤＭ３１５３に送信する。

次に、ステップ１１３８において、デマルチキャスタデバイスＤＭ３１５３は、ステップ１１３７でデマルチキャスタデバイスＤＭ２１５２によって送信された要求ＲＥＱ＿ＣＨＫに対する応答ＲＳＰ＿ＣＨＫを送信する。エラーコードまたは確認コードを含むことに加えて、応答ＲＳＰ＿ＣＨＫは、（図７に関してすでに検討されたように）デマルチキャスタデバイスＤＭ３１５３に関連する容量情報をさらに含む。デマルチキャスタデバイスＤＭ３１５３が、新たに選択されたオーディオおよび／またはビデオコンテンツを配信することができ、かつ応答ＲＳＰ＿ＣＨＫが、対応する確認コードを含む、と例示的に考えてみよう。

デマルチキャスタデバイスＤＭ２１５２もまた、プロキシデバイスＰＸＹ１１００を介したプレーヤーＰＬ１１２１での前のセッションのためのマルチパス配信で暗示されているため、デマルチキャスタデバイスＤＭ２１５２は、デマルチキャスタデバイスＤＭ２１５２が、新たに選択されたオーディオおよび／またはビデオコンテンツを配信できるかどうかを、内部的にチェックする。デマルチキャスタデバイスＤＭ２１５２もまた、新たに選択されたオーディオおよび／またはビデオコンテンツを配信できる、と例示的に考えてみよう。

そうすると、ステップ１１３９において、デマルチキャスタデバイスＤＭ２１５２は、ステップ１１３６でアプリケーションＡＰＰ１１３１によって送信された要求ＲＥＱ＿ＣＨＫに対する応答ＲＳＰ＿ＣＨＫをアプリケーションＡＰＰ１１３１に送信する。応答ＲＳＰ＿ＣＨＫは、デマルチキャスタデバイスＤＭ２１５２およびデマルチキャスタデバイスＤＭ３１５３が、新たに選択されたオーディオおよび／またはビデオコンテンツを配信できることを示し、応答ＲＳＰ＿ＣＨＫは、対応する確認コードを含む。アプリケーションＡＰＰ１１３１は、オーディオおよび／またはビデオコンテンツを配信するための適切なデマルチキャスタデバイスを選択するために、デマルチキャスタデバイスＤＭ２１５２に依存するので、この応答ＲＳＰ＿ＣＨＫに容量情報を含める必要はない。

ステップ１１４０において、アプリケーションＡＰＰ１１３１は、新たに選択されたオーディオおよび／またはビデオコンテンツを消費するために、プレーヤーＰＬ１１２１を再起動する。そうするために、アプリケーションＡＰＰ１１３１は、プレーヤーＰＬ１１２１に、プロキシデバイスＰＸＹ１１００の識別子（例えば、プロキシデバイスＰＸＹ１１００のＩＰアドレス）と、新たに選択されたオーディオおよび／またはビデオコンテンツを表す情報（例えば、新たに選択されたオーディオおよび／またはビデオコンテンツ、または好ましくは、それを表すマニフェストファイルを指すＵＲＬパス）と、さらなるパラメータとして、選択されたオーディオ／またはビデオコンテンツのマルチパス配信のために使用される各デマルチキャスタデバイスの識別子（例えば、問題のデマルチキャスタのＩＰアドレス）とを含むメッセージＬＡＵＮＣＨを送信する。この例では、さらなるパラメータは、デマルチキャスタデバイスＤＭ２１５２の、およびデマルチキャスタデバイスＤＭ３１５３の識別子（例えば、それらのＩＰアドレス）である。次に、ステップ１１４１において、プロセスＭＭ＿ＲＥＴおよびＭＣ＿ＲＥＴが、新たに選択されたオーディオおよび／またはビデオコンテンツを配信するために、プレーヤーＰＬ１１２１、プロキシデバイスＰＸＹ１１００、デマルチキャスタデバイスＤＭ２１５２、およびデマルチキャスタデバイスＤＭ３１５３の間で実行される。プロセスＭＭ＿ＲＥＴ１１１０で説明したのと同じように、デマルチキャスタデバイスＤＭ２１５２およびデマルチキャスタデバイスＤＭ３１５３は、それぞれ要求ＲＥＱ＿Ｍを受信し、それに応答すると、新しいセッションの開始の記録を実行する。一変形例では、デマルチキャスタデバイスＤＭ２１５２およびデマルチキャスタデバイスＤＭ３１５３は、プロキシデバイスＰＸＹ１１００から専用メッセージを受信すると、セッションの開始を検出する。別の変形例では、デマルチキャスタデバイスＤＭ３１５３は、問題のオーディオおよび／またはビデオコンテンツについてのプロキシデバイスＰＸＹ１１００からの（シーケンスにおける）第１の要求ＲＥＱ＿Ｃを受信すると、新しいセッションの開始を検出する。

特定の一実施形態では、いくつかのプレーヤーが、プロキシデバイスＰＸＹ１１００のサポートを使用する可能性があることを考慮して、プロキシデバイスＰＸＹ１１００は、デマルチキャスタデバイスＤＭ２１５２に、およびデマルチキャスタデバイスＤＭ３１５３に送信される自身のメッセージにおいて、そのメッセージが、プレーヤーＰＬ１１２１に代わって（例えば、端末Ｔ１１１１のＩＰアドレスを使用して）、セッションに関係すること示すことができる。例えば、ＨＴＴＰメッセージの「転送」フィールドは、そのような目的に使用され得る。したがって、デマルチキャスタデバイスＤＭ２１５２およびデマルチキャスタデバイスＤＭ３１５３は、これこれのものが開始または終了するプレーヤーのアイデンティティを認識する。

図１１Ａおよび図１１Ｂのマルチパスの実施形態は、図４、図５、図６、図８、図９、および図１０に関して上述したような最新の容量情報を取得するための実施形態と組み合わされ得る。

図１１Ａおよび図１１Ｂの説明は、プレーヤー（例えば、プレーヤーＰＬ１１２１）と、プロキシデバイスＰＸＹ１１００との間で交換されるメッセージに依存する。プロキシデバイスＰＸＹ１１００およびプレーヤーが同じ端末（例えば、端末Ｔ１１１１）内に位置する場合、メッセージはＡＰＩ（アプリケーションプログラミングインターフェイス）呼び出しの形態をとり得る。

さらに、図１１Ａおよび図１１Ｂの説明は、プレーヤー（例えば、プレーヤーＰＬ１１２１）に関連付けられたアプリケーション（例えば、アプリケーションＡＰＰ１１３１）と、プロキシデバイスＰＸＹ１１００との間で交換されるメッセージに依存する。問題のアプリケーションおよびプロキシデバイスＰＸＹ１１００が同じ端末（例えば、端末Ｔ１１１１）内に位置する場合、メッセージはＡＰＩ呼び出しの形態をとり得る。

より一般的には、前述の詳細な説明は、プレーヤー（例えば、プレーヤーＰＬ１１２１）と、関連付けられたアプリケーション（例えば、アプリケーションＡＰＰ１１３１）との間で交換されるメッセージに依存する。アプリケーションおよびプレーヤーが同じ端末（端末Ｔ１１１１）内に位置する場合、メッセージは、ＡＰＩ呼び出しの形態をとり得る。

すでに示したように、前述の詳細な説明は、オーディオおよび／またはビデオコンテンツが、マルチキャスト方式で配信されることを例示的に考慮して提示されている（ブロードキャスト送信は、マルチキャスト送信の特定のケースである）。ただし、ユニキャスト送信は、一変形例では、コンテンツ配信サーバ機器ＣＤＥ１６０で使用され得る。したがって、一般的に言えば、デマルチキャスタデバイスは、オーディオおよび／またはビデオコンテンツのセグメントをローカルエリアネットワークＬＡＮ１０１に転送することより、少なくとも１つのプロバイダネットワークＰＮ１０２を介して、コンテンツ配信サーバ機器ＣＤＥ１６０によって配信されるオーディオおよび／またはビデオコンテンツを、ローカルエリアネットワークＬＡＮ１０１内の端末デバイスが受信することを可能にするコンテンツ配信ネットワーク（ＣＤＮ）受信機デバイスである。

Claims (13)

1. ローカルエリアネットワーク内のプレーヤーにオーディオおよび／またはビデオコンテンツを配信するための方法であって、前記ローカルエリアネットワークが、複数のコンテンツ配信ネットワークＣＤＮ受信機デバイスを備え、前記ＣＤＮ受信機デバイスが、少なくとも１つのプロバイダネットワークを介してセグメントの形態でオーディオおよび／またはビデオコンテンツを受信し、前記ＣＤＮ受信機デバイスが、前記ローカルエリアネットワーク内のプレーヤーを備えた端末が前記オーディオおよび／またはビデオコンテンツを受信することを可能にするために、前記オーディオおよび／またはビデオコンテンツの前記受信されたセグメントを前記ローカルエリアネットワーク内に転送し、前記方法が、
   －前記ＣＤＮ受信機デバイスから容量情報を取得することであって、前記容量情報が、前記ＣＤＮ受信機デバイスの総容量と比較した、実際に使用されている処理リソースの表示である、取得すること、
   －前記容量情報に従って、オーディオおよび／またはビデオコンテンツを前記プレーヤーに配信するための少なくとも１つのＣＤＮ受信機デバイスを選択すること、
   －前記オーディオおよび／またはビデオコンテンツを前記プレーヤーに配信するためのセッションが開始および終了することを検出すること、を含み、
   －前記オーディオおよび／またはビデオコンテンツを、前記選択された少なくとも１つのＣＤＮ受信機デバイスから前記プレーヤーに配信するための前記セッションが終了すると、前記選択された少なくとも１つのＣＤＮ受信機デバイスが、所定の持続時間の間、同じまたは別のオーディオおよび／またはビデオコンテンツを前記プレーヤーに配信するための可能性のある次のセッションのために、処理リソースを所定の位置に保持し、
   －別のオーディオおよび／またはビデオコンテンツを前記プレーヤーに配信するための別のセッションが、前記所定の持続時間の満了前に開始すると、前記同じまたは別のオーディオおよび／またはビデオコンテンツが、前記処理リソースを使用して、前記選択された少なくとも１つのＣＤＮ受信機デバイスによって前記プレーヤーに配信され、所定の位置に保持し、
   －前記同じまたは別のオーディオおよび／またはビデオコンテンツを前記プレーヤーに配信するための別のセッションが、前記所定の持続時間の満了後に開始すると、更新された容量情報に従って、少なくとも１つのＣＤＮ受信機デバイスの再選択が実行されて、前記別のオーディオおよび／またはビデオコンテンツを前記プレーヤーへ配信する、方法。
2. 前記オーディオおよび／または前記ビデオコンテンツが、アダプティブビットレートＡＢＲを可能にするために、様々な表現で前記ＣＤＮ受信機に利用可能にされる、請求項１に記載の方法。
3. 前記選択された少なくとも１つのＣＤＮ受信機デバイスが、前記オーディオおよび／またはビデオコンテンツのマニフェストファイルを取得するための要求を受信したときに、前記オーディオおよび／またはビデオコンテンツを前記プレーヤーに配信するための前記セッションが開始することを検出する、請求項２に記載の方法。
4. 前記選択された少なくとも１つのＣＤＮ受信機デバイスが、前記セッションが開始することを示すメッセージを受信したときに、前記オーディオおよび／またはビデオコンテンツを前記プレーヤーに配信するための前記セッションが開始することを検出する、請求項１に記載の方法。
5. 前記選択された少なくとも１つのＣＤＮ受信機デバイスは、前記プレーヤーへの前記オーディオおよび／またはビデオコンテンツの前記配信に関する要求が、所定の持続時間の間、前記選択された少なくとも１つのＣＤＮ受信機デバイスによって受信されなかったことを検出するとき、前記オーディオおよび／またはビデオコンテンツを前記プレーヤーへ配信するための前記セッションが終了することを検出する、請求項１～４のいずれか一項に記載の方法。
6. 前記オーディオおよび／またはビデオコンテンツが、マルチキャスト形態で前記ＣＤＮ受信機に利用可能にされ、前記ＣＤＮ受信機デバイスが、前記少なくとも１つのプロバイダネットワークを介してマルチキャスト形態で受信された前記セグメントをユニキャスト形態に変換するデマルチキャスタである、請求項１～５のいずれか一項に記載の方法。
7. 各ＣＤＮ受信機デバイスが、その容量情報を、消費される前記オーディオおよび／またはビデオコンテンツが、問題の前記ＣＤＮ受信機デバイスを介して利用可能にされるかどうかをチェックするための要求に応答するのと同時に、送信する、請求項１～６のいずれか一項に記載の方法。
8. 消費される前記オーディオおよび／またはビデオコンテンツが、問題の前記ＣＤＮ受信機デバイスを介して利用可能にされるかどうかをチェックするための要求に応答して、少なくとも１つのＣＤＮ受信機デバイスによって送信される前記容量情報が、変化したとき、前記方法が、更新された容量情報を取得するために、各他のＣＤＮ受信機デバイスに容量情報を要求することをさらに含む、請求項７に記載の方法。
9. 前記ＣＤＮ受信機デバイスから容量情報を取得すること、および前記オーディオおよび／またはビデオコンテンツを前記プレーヤーに配信するための前記少なくとも１つのＣＤＮ受信機デバイスを、前記容量情報に従って選択することが、前記プレーヤーに関連付けられたアプリケーションによって実行される、請求項１～８のいずれか一項に記載の方法。
10. 前記ＣＤＮ受信機デバイスから容量情報を取得すること、および前記オーディオおよび／またはビデオコンテンツを前記プレーヤーに配信するための前記少なくとも１つのＣＤＮ受信機デバイスを、前記容量情報に従って選択することが、消費される前記オーディオおよび／またはビデオコンテンツが問題の前記ＣＤＮ受信機デバイスを介して利用可能にされるかどうかを、前記プレーヤーに関連付けられたアプリケーションが要求する１つのＣＤＮ受信機によって実行される、請求項１～８のいずれか一項に記載の方法。
11. 前記セッションが、前記オーディオおよび／またはビデオコンテンツを複数の選択されたＣＤＮ受信機デバイスから前記プレーヤーに配信することを暗示する場合、前記プレーヤーが、前記オーディオおよび／またはビデオコンテンツの前記セグメントを受信するためのプロキシデバイスと通信し、前記プロキシデバイスが、前記オーディオおよび／またはビデオコンテンツを前記プレーヤーに配信するための負荷分散を管理しながら、前記オーディオおよび／またはビデオコンテンツの前記セグメントを取得するための前記複数の選択されたＣＤＮ受信機デバイスと通信する、請求項１～１０のいずれか一項に記載の方法。
12. 前記プロキシデバイスが、前記オーディオおよび／またはビデオコンテンツのマニフェストファイルを取得するための要求を前記プレーヤーから受信すると、前記プロキシデバイスが、前記オーディオおよび／またはビデオコンテンツのマニフェストファイルを取得するための１つのそのような要求を、前記複数の選択されたＣＤＮ受信機デバイスのうちの各選択されたＣＤＮ受信機デバイスに送信する、請求項１１に記載の方法。
13. ローカルエリアネットワーク内のプレーヤーにオーディオおよび／またはビデオコンテンツを配信するために構成されたオーディオおよび／またはビデオコンテンツ配信システムであって、前記ローカルエリアネットワークが、前記オーディオおよび／またはビデオコンテンツ配信システムの複数のコンテンツ配信ネットワークＣＤＮ受信機デバイスを備え、前記ＣＤＮ受信機デバイスが、少なくとも１つのプロバイダネットワークを介してセグメントの形態でオーディオおよび／またはビデオコンテンツを受信し、前記ＣＤＮ受信機デバイスが、前記ローカルエリアネットワーク内のプレーヤーを備えた端末が前記オーディオおよび／またはビデオコンテンツを受信することを可能にするために、前記オーディオおよび／またはビデオコンテンツの前記受信されたセグメントを前記ローカルエリアネットワーク内に転送し、前記オーディオおよび／またはビデオコンテンツ配信システムが、
    －前記ＣＤＮ受信機デバイスから容量情報を取得するための手段であって、前記容量情報が、前記ＣＤＮ受信機デバイスの総容量と比較した、実際に使用されている処理リソースの表示である、手段、
    －前記容量情報に従って、オーディオおよび／またはビデオコンテンツを前記プレーヤーに配信するための少なくとも１つのＣＤＮ受信機デバイスを選択するための手段、
    －前記オーディオおよび／またはビデオコンテンツを前記プレーヤーに配信するためのセッションが、開始および終了することを検出するための手段、を備え、
    前記オーディオおよび／またはビデオコンテンツ配信システムが、以下、
    －前記オーディオおよび／またはビデオコンテンツを、前記選択された少なくとも１つのＣＤＮ受信機デバイスから前記プレーヤーに配信するための前記セッションが終了すると、前記選択された少なくとも１つのＣＤＮ受信機デバイスが、所定の持続時間の間、同じまたは別のオーディオおよび／またはビデオコンテンツを前記プレーヤーに配信するための可能性のある次のセッションのために、処理リソースを所定の位置に保持し、
    －別のオーディオおよび／またはビデオコンテンツを前記プレーヤーに配信するための別のセッションが、前記所定の持続時間の満了前に開始すると、前記同じまたは別のオーディオおよび／またはビデオコンテンツが、前記処理リソースを使用して、前記選択された少なくとも１つのＣＤＮ受信機デバイスによって前記プレーヤーに配信され、所定の位置に保持し、
    －前記同じまたは別のオーディオおよび／またはビデオコンテンツを前記プレーヤーに配信するための別のセッションが、前記所定の持続時間の満了後に開始すると、更新された容量情報に従って、少なくとも１つのＣＤＮ受信機デバイスの再選択が実行されて、前記別のオーディオおよび／またはビデオコンテンツを前記プレーヤーへ配信するようにさらに構成されている、オーディオおよび／またはビデオコンテンツ配信システム。

Images