(57)【特許請求の範囲】
【請求項１】
少なくとも１つのネットワークに属するよう構成され、少なくとも１つのサーバから、該サーバにおいて複数のデータレートで利用可能であるストリーミングコンテンツを受信するよう構成される適応ストリーミングクライアントのためのバンド幅をリザーブする方法であって、
少なくとも１つのイベントが起こる場合に、前記クライアントによって要求されている前記ストリーミングコンテンツに関連した所定の目標データレートと、トランジェントマージンとに応じて、トランジェントバンド幅を前記クライアントのためにリザーブするステップ
を有する方法。
【請求項２】
前記トランジェントマージンは、次のパラメータ：
−  前記ネットワークのトータルの利用可能なバンド幅、
−  前記ストリーミングコンテンツに関連した前記所定の目標データレート、
−  前記ネットワークのバンド幅を共有している競合するストリーム、
−  前記ストリーミングコンテンツのプライオリティ、
−  前記適応ストリーミングクライアントの保守的な値
のうちの少なくとも１つに依存する、
請求項１に記載の方法。
【請求項３】
前記適応ストリーミングクライアントが保守的な値を使用するとして、前記トランジェントマージンは前記保守的な値よりも大きい、
請求項１又は２に記載の方法。
【請求項４】
前記トランジェントバンド幅は、前記目標データレートに前記保守的な値を加えたものよりも大きく、
前記目標データレートよりも高い少なくとも１つの他のデータレートが前記サーバで利用可能である場合に、前記トランジェントバンド幅は、前記より高いデータレートに前記適応ストリーミングクライアントの前記保守的な値を加えたものよりも小さい、
請求項３に記載の方法。
【請求項５】
前記目標データレートが前記サーバによって提供される最大データレートである場合に、前記トランジェントマージンは、前記ネットワークのトータルの利用可能なバンド幅と前記目標データレートとの間の差以下である、
請求項１乃至４のうちいずれか一項に記載の方法。
【請求項６】
前記トランジェントバンド幅は、前記クライアントのバッファの充填速度に依存するトランジェント期間の間、前記適応ストリーミングクライアントのためにリザーブされる、
請求項１乃至５のうちいずれか一項に記載の方法。
【請求項７】
前記トランジェントバンド幅は、前記クライアントのバッファの充填率に依存するトランジェント期間の間、前記適応ストリーミングクライアントのためにリザーブされる、
請求項１乃至６のうちいずれか一項に記載の方法。
【請求項８】
前記クライアントがデータの連続的なチャンクの形で前記ストリーミングコンテンツを受信するとして、前記トランジェント期間は、前記クライアントのバッファにおいて前記クライアントによってロードされるチャンクの数が、バッファ長に、経過時間の間に前記適応ストリーミングクライアントによって再生されると推測されるチャンクの数を加えたものを超える場合に、終了する、
請求項６又は７に記載の方法。
【請求項９】
前記クライアントがデータの連続的なチャンクの形で前記ストリーミングコンテンツを受信するとして、前記トランジェント期間は、チャンク要求周波数がチャンクの存続期間に等しい場合に終了する、
請求項６又は７に記載の方法。
【請求項１０】
前記イベントは、次のイベント群：
−  前記適応ストリーミングクライアントによる前記ストリーミングコンテンツの受信の開始、
−  ネットワーク条件の変化、
−  他のストリームの受信の停止
に属する、
請求項１乃至９のうちいずれか一項に記載の方法。
【請求項１１】
少なくとも１つのネットワークに属するよう構成され、少なくとも１つのサーバから、該サーバにおいて複数のデータレートで利用可能であるストリーミングコンテンツを受信するよう構成される適応ストリーミングクライアントのためのバンド幅をリザーブするデバイスであって、
−  前記クライアントによって要求されている少なくとも１つのストリーミングコンテンツを検出するよう構成されるストリーム識別部と、
−  少なくとも１つのイベントが起こる場合に、前記要求されているストリーミングコンテンツに関連した所定の目標データレートと、トランジェントマージンとに応じて、トランジェントバンド幅を前記クライアントのためにリザーブするよう構成されるバンド幅マネージャと
を有するデバイス。
【請求項１２】
次のイベント群：
−  前記適応ストリーミングクライアントによる前記ストリーミングコンテンツの受信の開始、
−  ネットワーク条件の変化、
−  他のストリームの受信の停止
に属する前記イベントを検出するよう構成される
請求項１１に記載のデバイス。
【請求項１３】
前記適応ストリーミングクライアントが保守的な値を使用するとして、前記トランジェントマージンは前記保守的な値よりも大きい、
請求項１１又は１２に記載のデバイス。
【請求項１４】
コンピュータによって実行される場合に、該コンピュータに、
請求項１乃至９のうちいずれか一項に記載の方法を実施させるコンピュータプログラム。
【請求項１５】
コンピュータによって実行される場合に、該コンピュータに、
請求項１乃至９のうちいずれか一項に記載の方法を実施させるコンピュータプログラムを記憶している非一時的なコンピュータ可読媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、概して、ビデオストリーミングコンテンツの分配に関係があり、特に、ビデオストリーミングコンテンツによって使用されるバンド幅を制御する方法に関係がある。
【背景技術】
【０００２】
本項は、以下で記載及び／又は請求される本発明の様々な態様に関係があり得る技術の様々な態様に読者を引き合わせることを目的としている。この議論は、本発明の様々な態様のより良い理解を助けるよう背景情報を読者に提供するのに有用であると信じられる。然るに、それらの記述は、先行技術の承認としてではなく、この観点において読まれるべきであることが理解されるべきである。
【０００３】
ＨＴＴＰ適応テクノロジは、インターネットにおいて度を超えたオーディオビジュアル配信の提供を可能にするよう様々な利害関係者によって押し進められている。斯様なテクノロジは、クライアント端末が小さい連続したセグメント（２、３秒の長さ）（いわゆるチャンク）の形でビデオを受信することを可能にする。夫々のセグメントは、ＨＴＴＰプロトコルを通じて要求され、種々の変形（いわゆる表現）において存在してよく、クライアント端末がネットワーク及びデバイス制約に適合する適切なビットレートをいつでも選択することを可能にする。
【０００４】
既に使用されているＨＴＴＰ適応ストリーミング（ＨＡＳ；HTTP  adaptive  streaming）プロトコルの中で最も有名なものは、アップル社のＨＴＴＰ・ライブ・ストリーミング（ＨＬＳ；HTTP  Live  streaming）、マイクロソフト社のシルバーライト・スムース・ストリーミング（ＳＳＳ；Sliverlight  Smooth  Streaming）、アドビ社のアドビ・ダイナミック・ストリーミング（ＡＤＳ；Adobe  Dynamic  Streaming）、及びＳＡ４グループ内の３ＧＰＰによって開発されたＨＰＰＴ経由動的適応ストリーミング（ＤＡＳＨ；Dynamic  Adaptive  Streaming  over  HTTP）である。それらのＨＴＴＰ適応ストリーミングのための既存の技術は、コンテンツのオプション（ビットレート、画像ディメンション、フレームレート、など）を記述するためのメタデータを提供するマニフェストファイルフォーマットにおいて、セグメントにおける、サポートされているコーデックにおける、及びコンテンツ保護技術におけるコンテンツの利用可能な表現の編成を変える。
【０００５】
特に、クライアント端末がオーディオ／ビデオコンテンツを再生したいと望む場合に、それは最初に、如何にしてこの特定のコンテンツが取得され得るのかを記述するマニフェストを入手すべきである。これは、ＵＲＬから何らかの‘ファイル’を入手することによって、ＨＴＴＰを通じて行われる。このマニフェストファイルは、コンテンツの利用可能な表現を（ビットレート及び他の特性に関して）リストアップするとともに、夫々の表現について、夫々の時間スライスについてコンテンツチャンクをロードすることを可能にするＵＲＬをリストアップする。ビデオ・オン・デマンド（ＶｏＤ；Video  on  Demand）に関し、Ａ／Ｖコンテンツの全体の記述が提供され、一方、ライブコンテンツ（例えば、ＴＶコンテンツ）に関し、記述は、短時間しかカバーせず、時間が過ぎる場合に新しい項目を発見するために周期的にリロードされる必要がある。
【０００６】
その機能性及びネットワーキング環境から得られる知識に応じて、クライアント端末は、１つの表現を（例えば、そのビットレートに基づき）選択し、コンテンツの第１のチャンクをロードする。それは、２、３のチャンクを、ネットワーク障害に即応することができるようにバッファリングする。次いで、Ａ／Ｖコンテンツは、夫々の受信されたチャンクから次々に再生される。同時に、クライアント端末は、受信レートを測定し、より高い又はより低いビットレートを選択すると決定してよい。斯様な場合に、それは、単に、他の表現に次のチャンクを要求する。あらゆるＨＴＴＰストリーミング技術は、クライアント端末が、所与のビットレートを有するチャンクから他のビットレートを有する次のチャンクへ移動しながら連続再生を続けることが可能であるようなものである。このようにして、ネットワーク上の競合するトラフィックが、Ａ／Ｖコンテンツが受信されるレートに変化をもたらす場合に、クライアント端末は、バッファ充填を安全なレベルに維持することを可能にするビットレートを有するチャンクを選択することによって、対処し適応することができる。実際に、クライアント端末は、レンダリングがマクロブロック又はピクチャフリーズを引き起こすデータの受信遅れに悩まないレベルにとどまりながら、エンドユーザに良好なビューイング品質を提供するよう最大級のビットレートに達しようと試みる。
【０００７】
特に、ＨＡＳプレイヤーは、サービスプロバイダアプリケーションから通常は利用可能にされ、ユーザによってダウンロードされ得る。適応ストリーミングプレイヤーは、次の３つの重要な機能を有する：
−  チャンク要求スケジューリング。２つの要求ストラテジーが一般的に実施される。プレイヤーバッファを形成するために最初に立ち上げフェーズの間に使用される即時ダウンロード、及び一定の再生バッファを保つために定常フェーズにおいて使用される周期ダウンロードである。“Improving  Fairness,  Efficiency,  and  Stability  in  HTTP-based  Adaptive  Video  Streaming  with  FESTIVE”，Junchen  Jiang  and  al.，CoNext  2012において記載されているように、プレイヤーの初期条件に応じて、周期ダウンロードは、他のストリームによるバンド幅に関してＨＡＳストリームが完了する場合にバンド幅割り当ての不公平を生じさせる次善の時間割り当てにつながることがある；
−  ビットレート選択。基本ストラテジーは、推定されるバンド幅よりも低い最も高い利用可能なビットレートを保守的に選択することである。選択アルゴリズムの保守主義は、推定されるバンド幅の値と許容されている最大要求ビットレートの値との間に持ち込まれたマージンに従って評価される。保守的な値は、パーセンテージにおいて表現されてよい；
−  バンド幅推定。バンド幅推定は、瞬時スループット（すなわち、ダウンロード時間によって分割されるダウンロードサイズ）に基づく。ほとんどの市販プレイヤーは、フィルタリング技術を用いて推定を改善する。現在の推定は、次いで、そのダイナミックを平滑化するよう最後の幾つかの観測にわたって平均化される。
【０００８】
これらのＨＡＳ技術は、前から存在する技術と比べた場合にまあまあ上手く働くことが証明されてきたが、最近の研究は、幾つかの特定の挑戦的な環境（すなわち、他のＨＡＳクライアントとの又は隘路での他のＴＣＰフローとの競合）の下で、ＨＡＳ実施は厳しい安定性、公平性及び効率の問題に苦しむことがあると指摘している。
【０００９】
特に、バンド幅を奪い合う２つのＨＡＳクライアントは予測不能な結果をもたらし、最終的にユーザエクスペリエンスを台無しにすることが観察されている。加えて、ＨＡＳ端末は、バンド幅が評価されず、その場合に潜在的に低く見積もられるＯＦＦ期間を生じさせるそれらの周期ダウンロードプロファイルのために、どん欲なＴＣＰフロー（例えば、バルク転送）と競合する場合にバンド幅のそれらの公平な共有を取り戻すことができない。そして、それらのＯＦＦ期間の間に、特に、他のＴＣＰフローは、バンド幅を横取りする機会をとらえることができる。
【００１０】
最後に、定常状態の間に、ＨＡＳクライアント端末は、所与の目標レート（例えば、２０％の保守的な値）を維持するよう所与のバンド幅保守主義を適用する。それにより、ＨＴＴＰストリーミングは、供給されているバンド幅の１００％を満たすことができず、バンド幅の不十分な利用を引き起こす。
【００１１】
その上、効率を評価するために収束も重要な基準であり、それは初期条件に依存することが本出願人によって観察されている。収束する時間は、現在は決定的でなく、長いことがある。このことは、貧しいユーザエクスペリエンス及び潜在的に次善のバンド幅利用を生じさせる。
【００１２】
本発明は、定義された目標レートへのストリーミングコンテンツの収束を少なくとも改善するために、上記の懸案事項の少なくとも幾つかを改善しようと試みる。
【先行技術文献】
【非特許文献】
【００１３】
【非特許文献１】“Improving  Fairness,  Efficiency,  and  Stability  in  HTTP-based  Adaptive  Video  Streaming  with  FESTIVE”，Junchen  Jiang  and  al.，CoNext  2012
【発明の概要】
【００１４】
本発明は、少なくとも１つのネットワークに属し、少なくとも１つのサーバから、該サーバにおいて１つよりも多いデータレートで利用可能であるストリーミングコンテンツを受信するよう構成される適応ストリーミングクライアントのためのバンド幅をリザーブする方法であって、
少なくとも１つのイベントが起こる場合に、前記クライアントによって要求されている前記ストリーミングコンテンツに関連した所定の目標データレートと、トランジェントマージンとに応じて、トランジェントバンド幅を前記クライアントのためにリザーブするステップ
を有する点が注目に値する方法と関係がある。
【００１５】
本発明のおかげで、適応ストリーミングクライアントの初期条件は、目標データレートへのその収束を改善するために、要求されているストリーミングコンテンツへ起動時に割り当てられているバンド幅を一時的に広げることによって、変更及び／又は影響を及ぼされ得る。収束し且つ安定性を得るための時間を短縮するために、本発明は、クライアントのトランジェント状態の間にトランジェントバンド幅を割り当てることを少なくとも提案する。本出願人は、ＨＡＳストリーミングコンテンツのためにリザーブされるハンド幅が大きければ大きいほど（例えば、所与の制限まで。）、収束はますます早いことを観測した。加えて、適応ストリーミングクライアントの収束がより早い場合に、安定性及び公平性は、適応ストリーミングセッションの全存続期間にわたって得られる。
【００１６】
好適な実施形態に従って、前記トランジェントマージンは、次のパラメータ：
−  前記ネットワークのトータルの利用可能なバンド幅、
−  前記ストリーミングコンテンツに関連した前記所定の目標データレート、
−  前記ネットワークのバンド幅を共有している競合するストリーム、
−  前記ストリーミングコンテンツのプライオリティ、
−  前記適応ストリーミングクライアントの保守的な値
のうちの少なくとも１つに依存する。
【００１７】
特に、前記適応ストリーミングクライアントが保守的な値を使用する場合に、前記トランジェントマージンは前記保守的な値よりも有利に大きい。
【００１８】
加えて、前記トランジェントバンド幅は、望ましくは、前記目標データレートに前記保守的な値を加えたものよりも大きくてよく、前記目標データレートよりも高い少なくとも１つの他のデータレートが前記サーバで利用可能である場合に、前記トランジェントバンド幅は、望ましくは、前記クライアントが前記より高いデータレートに切り替わらないようにするために、前記より高いデータレートに前記適応ストリーミングクライアントの前記保守的な値を加えたものよりも小さい。
【００１９】
本発明の他の態様では、前記目標データレートが前記サーバによって提供される最大データレートである場合に、前記トランジェントマージンは、前記ネットワークのトータルの利用可能なバンド幅と前記目標データレートとの間の差以下であってよい。
【００２０】
本発明の更なる態様では、前記トランジェントバンド幅は、前記クライアントのバッファの充填速度又は充填率（充填状態とも呼ばれる。）に依存するトランジェント期間の間、前記適応ストリーミングクライアントのためにリザーブされ得る。
【００２１】
特に、前記クライアントがデータの連続的なチャンクの形で前記ストリーミングコンテンツを受信するとして、前記トランジェント期間は、前記クライアントのバッファ満たされると、すなわち、例えば：
−  前記クライアントのバッファにおいて前記クライアントによってロードされるチャンクの数が、バッファ長に、前記適応ストリーミングクライアントによって再生されると推測されるチャンクの数を加えたものを超える場合に；又は
−  チャンク要求周波数がチャンクの存続期間に等しい場合に、
終了する。
【００２２】
更には、前記イベントは、次のイベント群：
−  前記適応ストリーミングクライアントによる前記ストリーミングコンテンツの受信の開始；
−  ネットワーク条件の（望ましくは、顕著な）変化；
−  他のストリームの受信の停止
に属する。
【００２３】
その上、本発明は、少なくとも１つのネットワークに属し、少なくとも１つのサーバから、該サーバにおいて１つよりも多いデータレートで利用可能であるストリーミングコンテンツを受信するよう構成される適応ストリーミングクライアントのためのバンド幅をリザーブするデバイスと関係がある。本発明に従って、当該デバイスは：
−  前記クライアントによって要求されている少なくとも１つのストリーミングコンテンツを検出するよう構成されるストリーム識別部と；
−  バンド幅マネージャであって：
・  前記クライアントによって要求されている前記ストリーミングコンテンツに関連した目標データレートを決定し；
・  少なくとも１つのイベントが起こる場合に、前記決定された目標データレート及びトランジェントマージンに応じて、トランジェントバンド幅を前記クライアントのためにリザーブする
よう構成される前記バンド幅マネージャと
を有する。
【００２４】
加えて、当該デバイスは、次のイベント群：
−  前記適応ストリーミングクライアントによる前記ストリーミングコンテンツの受信の開始、
−  ネットワーク条件の変化、
−  他のストリームの受信の停止
に属する前記イベントを検出するよう構成される。
【００２５】
更には、前記適応ストリーミングクライアントが保守的な値を使用するとして、前記トランジェントマージンは、望ましくは、前記保守的な値よりも大きい。
【００２６】
前記目標データレートよりも高い少なくとも１つの他の利用可能データレートが前記サーバで利用可能である場合に、前記トランジェントバンド幅は、望ましくは、前記クライアントが前記より高いデータレートへ切り替わらないようにするために、前記より高いデータレートに前記適応ストリーミングクライアントの前記保守的な値を加えたものよりも小さい。
【００２７】
当該デバイスは、例えば、ゲートウェイ又はルータであることができる。
【００２８】
本発明は、コンピュータによって読み出し可能な及び／又はプロセッサによって実行可能な媒体において記録される及び／又は通信ネットワークからダウンロード可能なコンピュータプログラム製品であって、上記の方法を実施するプログラムコード命令を有するコンピュータプログラム製品と更に関係がある。
【００２９】
加えて、本発明は、プロセッサによって実行されることが可能なコンピュータプログラム製品を記録している非一時的なコンピュータ可読媒体であって、上記の方法を実施するプログラムコード命令を含む非一時的なコンピュータ可読媒体とも関係がある。
【００３０】
開示される実施形態と適用範囲において相応である特定の態様は、以下で示される。それらの態様は、本発明がとり得る特定の形態の概要を読者に提供するために提示されているにすぎず、それらの態様は、本発明の適用範囲を制限するよう意図されないことが理解されるべきである。実際に、本発明は、以下で示されていない様々な態様を包含し得る。
【図面の簡単な説明】
【００３１】
本発明は、添付の図面を参照して、制限なしに、以下の実施形態及び実施例を用いて説明されてより良く理解されるであろう。
【図１】本発明が実施され得るクライアント−サーバ・ネットワークアーキテクチャの概略図である。
【図２】図１のネットワークアーキテクチャのクライアント端末の例のブロック図である。
【図３】本発明の好適な実施形態に従うゲートウェイの例のブロック図である。
【図４】好適な実施形態に従って、図３のゲートウェイによって実施するバンド幅リザベーション方法のステップを表すフローチャートである。  図２及び３において、提示されているブロックは、単に機能的なエンティティであって、必ずしも物理的に別個のエンティティに対応しない。すなわち、それらは、１つ以上のプロセッサを有する１つ以上の集積回路において実施されるか、又はソフトウェアやハードウェアの形で現れてよい。
【００３２】
可能な限り、同じ参照符号は、同じ又は同様の部分を参照するために図面を通して使用される。
【発明を実施するための形態】
【００３３】
本発明の図及び記載は、典型的なデジタルマルチメディアコンテンツ配信方法及びシステムにおいて見つけられる多くの他の要素を明りょうさのために無視しながら、本発明の明りょうな理解にとって適切な要素を表すために簡略化されていることが理解されるべきである。なお、そのような要素は当該技術においてよく知られているので、そのような要素の詳細な議論はここで与えられない。
【００３４】
好適な実施形態に従って、本発明は、ＨＴＴＰ適応ストリーミング（いわゆるＨＡＳ）プロトコルに関して表される。当然ながら、本発明はそのような特定の環境に制限されず、他の適応ストリーミングプロトコルが当然に考えられて実施され得る。
【００３５】
図１に表されているように、本発明が実施され得るクライアント−サーバ・ネットワークアーキテクチャは、例えば、２つのクライアント端末Ｃ１及びＣ２と、ゲートウェイＧＷと、１つ以上のＨＴＴＰサーバＳ（図１では、１つしか表されていない。）とを有する。明らかに、追加のクライアント端末が当該アーキテクチャにおいて存在してよい。
【００３６】
クライアント端末Ｃ１は、ローカルネットワークＮ１（ホームネットワーク又は企業ネットワークとして。）を通じてゲートウェイＧＷへ接続されているＨＴＴＰ適応ストリーミング（ＨＡＳ）クライアント端末であって、ブロードバンドネットワークＮ２（インターネットネットワークとして。）を通じてＨＴＴＰサーバＳへ接続したいと望む。ＨＡＳクライアント端末Ｃ１は、所与の保守的な値を提示する。ローカルネットワークＮ１は、ゲートウェイＧＷのおかげでブロードバンドネットワークＮ２へ接続される。
【００３７】
保守的な値は、推定されるバンド幅の値と選択されている要求されるビットレートとの間でクライアント端末によってとられた最小マージンであることができる。保守的な値は、推定されるバンド幅のパーセンテージにおいて表現されてよい。
【００３８】
ＨＴＴＰサーバＳは、１つ以上のＴＣＰ／ＩＰ接続にわたってＨＡＳプロトコルを用いて、クライアント要求時にチャンクをクライアント端末Ｃ１へストリーミングする。
【００３９】
図２において記載される好適な実施形態に従って、ＨＡＳクライアント端末Ｃ１は、少なくとも：
−  ローカルネットワークＮ１への接続１のＬＡＮ（Local  Area  Network）インターフェイス（例えば、Ｗｉ−Ｆｉ（登録商標）、Ｅｔｈｅｒｎｅｔ（登録商標）、などとして、有線及び／又は無線）；
−  ＨＴＴＰサーバＳと通信するためのプロトコルスタックを含む通信モジュール２。特に通信モジュール２は、当該技術においてよく知られているＴＣＰ／ＩＰスタックを有する。当然、それは、クライアント端末Ｃ１がＨＴＴＰサーバＳと通信することを可能にする如何なる他のタイプのネットワーク及び／又は通信手段であってもよい；
−  ＨＴＴＰサーバＳからＨＴＴＰストリーミングマルチメディアコンテンツを受信する適応ストリーミングモジュール３。それは、ネットワーク制約及びそれ自身の制約とより良く適合するビットレートでチャンクを絶えず選択する；
−  マルチメディアコンテンツを復号しレンダリングするよう構成されるビデオプレイヤー４；
−  クライアント端末Ｃ１の不揮発性メモリにおいて記憶されているアプリケーション及びプログラムを実行する１つ以上のプロセッサ５；
−  ＨＴＴＰサーバＳから受信されたチャンクを、ビデオプレイヤー４へのそれらの送信の前にバッファリングするよう構成されるバッファ６；
−  一般的なクライアント端末機能を実行するために当業者によく知られている様々なモジュール及び全ての手段を接続する内部バスＢ１
を有する。
【００４０】
好適な実施形態において、クライアント端末Ｃ１は、ポータブルメディアデバイス、携帯電話機、タブレット又はラップトップである。当然ながら、クライアント端末Ｃ１は、完全なビデオプレイヤーを有さずに、メディアコンテンツを逆多重化及び復号するもののような幾つかのサブエレメントしか有さなくてよく、そして、復号されたコンテンツをエンドユーザに表示する外部手段に依存してよい。この場合に、クライアント端末Ｃ１は、セットトップボックスのような、ＨＴＴＰ適応ストリーミング対応のビデオデコーダである。
【００４１】
その上、好適な実施形態のゲートウェイＧＷは、デジタル加入者回線（ＤＳＬ；Digital  Subscriber  Line）ゲートウェイであって、ＤＳＬテクノロジを通じたローカルネットワークＮ１へのインターネットブロードバンドアクセスを提供する。当然、ゲートウェイは、ケーブル、ファイバ又は無線のような如何なるタイプのブロードバンドゲートウェイであってもよい。
【００４２】
図３において示されるように、ゲートウェイＧＷは：
−  ローカルネットワークＮ１への接続７のＬＡＮインターフェイス（例えば、Ｗｉ−Ｆｉ、Ｅｔｈｅｒｎｅｔなどとして、有線及び／又は無線）；
−  ブロードバンドネットワークＮ２への接続８のブロードバンドインターフェイス（有線及び／又は無線）；及び
−  接続７及び８のインターフェイスを通じて通信するためのプロトコルスタックを有する通信モジュール９。特に、通信モジュールは、ＩＰスタックと記されるインターネットプロトコルスタックを有する；
−  マニフェストから取り出された情報（例えば、プレイリスト又はＸＭＬファイル）を記憶するよう特に構成されるメモリ１０；
−  ゲートウェイＧＷの不揮発性メモリにおいて記憶されているアプリケーション及びプログラムを実行する１つ以上のプロセッサ１５；
−  一般的な家庭用ゲートウェイ機能を実行するために当業者によく知られている様々なモジュール及びプロセッシング手段、ルーティング及びブリッジング手段並びに全ての手段を接続する内部バスＢ２
を有する。
【００４３】
上述されたように、適応ストリーミングにおけるマルチメディアコンテンツ（例えば、映画）を再生するために、クライアント端末Ｃ１は、最初に、要求されているマルチメディアコンテンツの利用可能な表現を（ビットレート及び解像度に関して）リストアップするマニフェストをサーバＳから入手する必要がある。このマニフェストは、前もって生成されて、ＨＴＴＰサーバＳで記憶されている。
【００４４】
更には、ゲートウェイＧＷは、ネットワーク条件の変化を識別するネットワーク監視ユニット１１と、ゲートウェイで受信されたストリームを解析するよう構成されるストリーム識別部１２とを更に有する。クライアント端末Ｃ１がサービス要求を発行するたびに、ストリーム識別部１２は、当該要求を識別し、サーバＳからクライアントＣ１へ返されたマニフェストをインターセプトすることによってサービス情報を収集し、それによって、サーバＳによって知らされた利用可能なビットレート及び関連するチャンクＵＲＬのような情報を解析し抽出する。マニフェストをインターセプトするよう、ストリーム識別部１２は、利用可能なストリーミング技術及び関連するプロトコルを承知している。夫々のプロトコルにおいて、それは、マニフェストを運ぶパケットのタイプを知っている。例えば、ストリーム識別部１２は、アップルのＨＴＴＰライブ・ストリーミング、マイクロソフトのスムース・ストリーミング、及びアドビのオープン・ソース・メディア・フレームワーク技術を承知している。当然、それは、他のストリーミング技術を認識するよう構成され得る。
【００４５】
ストリーム識別部１２は、ストリームがもはやゲートウェイＧＷで受信されない場合も識別する。制限されない実例となる例として、ストリームが所定の期間の間受信されない場合に、ストリーム識別部１２は、セッションが終わったと見なすことができ、そして、ゲートウェイＧＷのバンド幅マネージャ１３に通告することができる。バンド幅マネージャ１３は、以降で記載されるように然るべくトラフィック制御規則及びバンド幅リザベーションを変更することができる。
【００４６】
バンド幅マネージャ１３は、次いで、ストリーム識別部１２によって入手された情報を受けるよう構成される。特に、バンド幅マネージャ１３は、サービスが認められているかどうかを判定し、そのサービスに関して目標ビットレートを決定し、場合により、既に実行されている他のサービスのための目標を同時に変更する。バンド幅マネージャ１３は、ゲートウェイＧＷのブロードバンドインターフェイス８で利用可能な最大バンド幅の値を測定する。
【００４７】
特に、ＨＡＳクライアント端末Ｃ１がストリーミングコンテンツをサーバＳに要求する場合に、バンド幅マネージャ１３は、ストリーム識別部１２から受信された情報及び追加のパラメータ（例えば、利用可能なネットワークバンド幅、ストリームのプライオリティ、クライアント端末の保守的な値、など）に基づき目標ビットレートＲＴを決定した後に、要求されているストリーミングコンテンツに関連したトランジェントバンド幅ＢＷｔをリザーブし、次いで、ゲートウェイＧＷのスケジューラ１４を設定する。
【００４８】
スケジューラ１４は、ローカルネットワークＮ１におけるパケットの送信を管理するよう構成される。特に、夫々のＨＡＳストリームは、トランジェント期間Ｄｃの間のまさに１つのトランジェントバンド幅ＢＷｔと、ストリーム受信の終了までの１つの定常バンド幅ＢＷｓとを配分されている独立したキューを割り当てられる。
【００４９】
トランジェントバンド幅ＢＷｔは、トランジェント期間Ｄｃの間リザーブされ、決定された目標データレートＲＴ及びトランジェントマージンｍｔに依存する。特に、トランジェントバンド幅ＢＷｔは、以下のように、目標ビットレートＲＴにトランジェントマージンｍｔを加えたものに等しくてよい：
ＢＷｔ＝ＲＴ＋ｍｔ    なお、ｔ∈［Ｔｏ；Ｔｏ＋Ｄｃ］
上記の式において、ｔは時間であり、Ｔｏはストリーミングコンテンツの受信の開始を示す。
【００５０】
有利なことには、トランジェントマージンｍｔは、保守的な値Ｖｃよりも大きく（ｍｔ＞Ｖｃ）、それにより：
ＢＷｔ＞ＲＴ＋Ｖｃ    なお、ｔ∈［Ｔｏ；Ｔｏ＋Ｄｃ］
が成立する。
【００５１】
目標ビットレートＲＴよりも高い少なくとも１つの他のビットレート（ＲＴ＋１と記される。）が受信されたマニフェストにおいて挙げられており、サーバＳで利用可能である場合に、トランジェントバンド幅ＢＷｔは、より高いデータレートＲＴ＋１にＨＡＳクライアント端末Ｃ１の保守的な値Ｖｃを加えたものよりも小さい。それにより：
ＢＷｔ＜ＲＴ＋１＋Ｖｃ
が成立する。
【００５２】
他の実例となる例として、トランジェントバンド幅ＢＷｔは、次の関係によって求められてよい：
ＢＷｔ＝ＲＴ×１００／（１００−ｍｔ）  なお、ｔ∈［Ｔｏ；Ｔｏ＋Ｄｃ］
当然ながら、他の式がトランジェントバンド幅を決定するために使用されてよい。
【００５３】
トランジェントマージンｍｔは、次のパラメータのうちの１つ以上に基づくことができる：
−  ブロードバンドネットワークＮ２のトータルの利用可能なバンド幅ＢＷＴＯＴＡＬ；
−  ＨＡＳクライアント端末Ｃ１によって要求されるストリーミングコンテンツに関連した決定された目標データレートＲＴ；
−  ネットワークバンド幅を共有している競合するストリーム（例えば、第２のクライアント端末Ｃ２によって受信されるストリーム）；
−  ストリーミングコンテンツのプライオリティ；
−  適応ストリーミングクライアント端末Ｃ１の保守的な値。
【００５４】
特に、目標ビットレートＲＴがサーバによって提供される（マニフェストにおいてリストアップされる）最大ビットレートである場合に、トランジェントマージンｍｔは、トータルの利用可能なバンド幅ＢＷＴＯＴＡＬと目標ビットレートＲＴとの間の差に多くても等しい。それにより：
ｍｔ≦ＢＷＴＯＴＡＬ−ＲＴ
が成立する。
【００５５】
好適な実施形態において、バンド幅マネージャ１３は、ブロードバンドインターフェイス８で利用可能な最大バンド幅の値に基づき、バンド幅リザベーションを決定する。代替的に、ブロードバンドネットワークＮ２のブロードバンドインターフェイス８で利用可能な最大バンド幅の代わりに、バンド幅マネージャ１３は、ローカルネットワークＮ１のＬＡＮインターフェイスで利用可能な最大バンド幅を考慮してよい。それは、次いで、ローカルネットワークＮ１で利用可能な最大バンド幅の値に基づき、バンド幅リザベーションを決定する。これは、隘路がブロードバンドネットワークＮ２ではなくローカルネットワークＮ１にある場合に起こる。
【００５６】
ＨＡＳクライアント端末Ｃ１がその要求されているストリーミングコンテンツをサーバＳから受信し始める場合におけるバンド幅マネージャ１３によるトランジェント期間Ｄｃの間のトランジェントバンド幅ＢＷｔのリザベーションが記載されてきたが、斯様なトランジェントバンド幅のリザベーションは、バンド幅共有がネットワーク条件の大きな変化（特に、ＨＡＳクライアントＣ１のためのバンド幅部分の増大）又はＨＡＳクライアント端末Ｃ１に割り当てられているバンド幅部分の増大を生じさせる他のストリームの受信の中止により変更されるべき場合にも実行され得る。そのようなイベントは、対応するメッセージ（例えば、ゲートウェイＧＷによって送信される。）によって識別され、ＨＡＳクライアント端末Ｃ１のバンド幅の割増部分の一時的な許可をトリガして、それにより、定常状態へのその収束を加速させる。換言すると、そのようなイベントは、クライアント端末Ｃ１による関連するメッセージの受信時に検出される。
【００５７】
更には、トランジェント期間Ｄｃは、前もってバンド幅マネージャ１３によって設定され、例えば、固定値（例えば、数秒）に等しくてよい。それに反して、トランジェント期間Ｄｃは、前もって設定されなくてもよく、ＨＡＳクライアント端末Ｃ１のバッファ６の充填速度に依存してよい。特に、トランジェント期間Ｄｃは、クライアント端末Ｃ１のバッファ６におけるロードされたチャンクの数に依存することができ、例えば、ＨＡＳクライアント端末Ｃ１によって受信されるチャンクの数が、バッファ長に、経過時間の間に適応ストリーミングクライアントによって再生されると推測されるチャンクの数を加えたものを超える場合に、終了することができる。
【００５８】
バッファ充填期間Ｔｂは、次の関係によって近似され得ることが知られる：
Ｔｂ＝ＬＢ×ＲＴ／（ＢＷｔ−ＲＴ）
この式において：
−  ＬＢはバッファ長（単位秒）であり；
−  ＲＴは目標ビットレート（単位ｋｂｐｓ）であり；
−  ＢＷｔはリザーブされるトランジェントバンド幅（単位ｋｂｐｓ）である。
【００５９】
変形例において、トランジェント期間Ｄｃは、チャンク要求周波数が、少なくともおおよそ、チャンクの存続期間に等しくなるまで、保たれ得る（その場合に、バッファ６は満たされたと見なされる。）。
【００６０】
他の変形例において、又は補足として、トランジェント期間は、クライアント端末Ｃ１のバッファ６の充填率（又は状態）にも依存してよい（例えば、バッファの８０％）。
【００６１】
その上、本発明の更なる態様において、バンド幅マネージャ１３は、定常状態の間、トランジェント期間Ｄｃの終了後に、端末Ｃ１によって要求されているストリーミングコンテンツに関連する１つの定常バンド幅ＢＷｓを更にリザーブすることができる。
【００６２】
定常バンド幅ＢＷｓは、決定された目標データレートＲＴ及び定常マージンｍｓに等しい。定常マージンｍｓは、トランジェントマージンｍｔよりも小さい（ｍｓ＜ｍｔ）。例えば：
ＢＷｓ＝ＲＴ＋ｍｓ    なお、ｔ＞Ｔｏ＋Ｄｃ且つＢＷｓ＜ＢＷｔ。
特に、定常バンド幅ＢＷｓは、目標ビットレートＲＴに保守的な値Ｖｃを加えたものに少なくとも等しくてよい（定常マージンｍｓは、その場合に保守的な値Ｖｃに等しい。）。それにより：
ＢＷｓ≧ＲＴ＋Ｖｃ    なお、Ｔｏ＋Ｄｃ
が成立する。
【００６３】
他の例として、定常バンド幅ＢＷｓは、次の関係によって求められてよい：
ＢＷｓ＝ＲＴ×１００／（１００−ｍｓ）    なお、Ｔｏ＋Ｄｃ。
ＨＡＳストリーミングコンテンツのためのバンド幅リザベーション（トランジェントバンド幅ＢＷｔ、定常バンド幅ＢＷｓ）に関するバンド幅マネージャ１３の決定は、多数のパラメータ及びユーザ又はサービスプロバイダの好みに依存する。それらは、要求されるコンテンツ、ネットワーク、ネットワークのクライアント端末、等の特性によって与えられる、バンド幅マネージャによって強いられるアービトレーションスキームの組となる。
【００６４】
競合するストリーム（例えば、クライアント端末Ｃ１及びＣ２によって要求される。）の場合に、バンド幅マネージャ１３によるバンド幅リザベーションは、クライアント端末のタイプに依存することができる。例えば、テレビジョンセットのためのストリームは、ポータブルメディアプレイヤーのためのストリームよりも高いプライオリティを有することができる。代替的に、バンド幅リザベーションは、ローカルネットワークＮ１におけるクライアント端末Ｃ１、Ｃ２の位置や、ユーザの身元などにも基づくことができる。居間に位置するクライアント端末Ｃ１、Ｃ２は、寝室に位置するクライアント端末Ｃ１、Ｃ２よりも高いプライオリティを有してよい。望ましくは、ゲートウェイＧＷは、ストリーム間でプライオリティを調整することを可能にするユーザインターフェイス（図示せず。）を有する。ユーザインターフェイスでの入力は、例えば、デバイスのタイプ、その位置及びそのプライオリティであってよい。
【００６５】
本発明に従って、バンド幅マネージャ１３は、次いで、クライアント端末Ｃ１によって要求されるＨＡＳストリーミングコンテンツのために２つの別個の規則を定義する。第１の規則は、収束期間に対応する極めて短い期間（トランジェント期間Ｄｃとしても知られる。）に適用される。次いで、第２の規則は、ストリームの受信の終了まで適用される。収束期間は、ＨＡＳクライアント端末Ｃ１がトランジェント状態にあり、目標レートＲＴに達してそのバッファを満たそうと試みる期間に対応する。この収束期間の後、ＨＡＳクライアント端末Ｃ１は、ストリームの終了まで又はネットワーク条件が変化するまで同じレートを保ちながら定常状態にあるべきである。第１の規則は、ＨＡＳクライアント端末Ｃ１に対してバンド幅の余分の部分を一時的に許可し、それによって、定常状態へのその収束を加速させるとともに安定性を得る。本出願人は、リザーブされるバンド幅が大きければ大きいほど、目標ビットレートへの収束がますます早いことを観測した。
【００６６】
提案される発明は、所与のＨＡＳストリームと競合するストリームが膨大なＴＣＰダウンロード、進行性のダウンロードストリーム又は他のＨＡＳストリームである場合に適用され得る。
【００６７】
トランジェントマージン及び定常マージンは、上記のパラメータ（プライオリティ、ユーザ好み、競合するストリーム、など）に基づき実験により決定されることが理解されるべきである。
【００６８】
制限されない実例として、３０秒のバッファを用いたスムース・ストリーミングＨＡＳサービスに関して、次の典型的な値が選択され得る：
−  トランジェントマージン＝決定されるべき割り当てトランジェントバンド幅の４０％（例えば、ｔ∈［Ｔｏ；Ｔｏ＋Ｄｃ］について、式ＢＷｔ＝ＲＴ×１００／（１００−ｍｔ）においてｍｔ＝４０）；
−  定常マージン＝決定されるべき割り当て定常バンド幅の２０％（例えば、ｔ＞Ｔｏ＋Ｄｃについて、式ＢＷｓ＝ＲＴ×１００／（１００−ｍｓ）においてｍｓ＝２０）。
【００６９】
好適な実施形態に従って、図４に示されるように、ゲートウェイＧＷは、ＨＡＳクライアント端末Ｃ１のためのバンド幅をリザーブする方法を実施するよう構成される。方法は、次のステップを有する：
−  ゲートウェイＧＷでリザーブされるストリームを解析する（ステップＳ０）；
−  所与のイベント（例えば、クライアント端末Ｃ１によるＨＡＳストリーミングコンテンツの受信の開始、ネットワーク条件の大きな変化）を検出する（ステップＳ１）；
−  ＨＡＳクライアント端末Ｃ１によって要求されるストリーミングコンテンツに関連した目標データレートを決定する（ステップＳ２）；
−  少なくとも１つのイベントが検出される場合に、トランジェント期間Ｄｃの間はトランジェントバンド幅ＢＷｔを、ＨＡＳストリーミングコンテンツの終了までは定常バンド幅ＢＷｓをＨＡＳクライアント端末Ｃ１のためにリザーブする（ステップＳ３）。
【００７０】
好適な実施形態において、バンド幅リザベーションは、ゲートウェイＧＷで実行される。代替的に、それはまた、ローカルネットワークＮ１に位置してゲートウェイＧＷへ接続されているルータにおいて、又は外部ルータにおいて、又はブロードバンドネットワークＮ２に位置するキャッシュにおいて、実行されてよい。
【００７１】
図面におけるフローチャート及び／又はブロック図は、本発明の様々な実施形態に従うシステム、方法及びコンピュータプログラム製品の起こり得る実施の構成、動作及び機能性を説明する。これに関して、フローチャート又はブロック図における夫々のブロックは、モジュール、セグメント、又はコードの部分を表してよい。コードは、特定されている論理関数を実施するための１つ以上の実行可能命令を含む。幾つかの代替の実施において、ブロックにおいて表されている機能は、図に表されている順序を外れて起こってよいことも留意されるべきである。例えば、続けて示されている２つのブロックは、実際には略同時に実行されてよく、あるいは、ブロックは、逆の順序において時には実行されてよく、あるいは、ブロックは、関連する機能性に応じて別の順序において実行されてよい。ブロック図及び／又はフローチャート図の夫々のブロック、並びにブロック図及び／又はフローチャート図におけるブロックの組み合わせは、特定される機能又は動作を実行する専用のハードウェアに基づいたシステム、あるいは、専用のハードウェアとコンピュータ命令との組み合わせによって実施され得ることも知られる。明示的に記載されていないが、本実施形態は、如何なる組み合わせ又は部分的組み合わせにおいても用いられてよい。
【００７２】
当業者に明らかなように、本原理の態様は、システム、方法又はコンピュータ可読媒体として具現され得る。然るに、本原理の態様は、全体としてハードウェアの実施形態、全体としてソフトウェアの実施形態（ファームウェア、常駐ソフトウェア、マイクロコード、などを含む。）、又はここで“回路”、“モジュール”若しくは“システム”と一般的に呼ばれ得る、ソフトウェア及びハードウェア態様を組み合わせる実施形態の形をとることができる。更には、本原理の態様は、コンピュータ可読記憶媒体の形をとることができる。１つ以上のコンピュータ可読記憶媒体の如何なる組み合わせも利用されてよい。
【００７３】
コンピュータ可読記憶媒体は、１つ以上のコンピュータ可読媒体において具現され、コンピュータによって実行可能なコンピュータ可読プログラムコードを担持しているコンピュータ可読プログラム製品の形をとることができる。ここで使用されるコンピュータ可読記憶媒体は、情報を記憶する固有の機能及び情報の検索を提供する固有の機能を前提として、非一時的な記憶媒体と見なされる。コンピュータ可読記憶媒体は、例えば、電子、磁気、光学式、電磁気、赤外線、又は半導体のシステム、装置、又はデバイス、あるいはそれらのあらゆる適切な組み合わせであることができるが、それらに限られない。当然に、以下は、本原理が適用され得るコンピュータ可読記憶媒体のより具体的な例を与えるが、当業者によって容易に理解されるように、網羅的ではなく、単なる実例としての列挙である：可搬性のコンピュータディスケット、ハードディスク、ランダムアクセスメモリ（ＲＡＭ；random  access  memory）、読出専用メモリ（ＲＯＭ；read-only  memory）、消去可能なプログラム可能読出専用メモリ（ＥＰＲＯＭ（erasable  programmable  read-only  memory）又はフラッシュメモリ）、可搬性のコンパクトディスク型読出専用メモリ（ＣＤ−ＲＯＭ）、光記憶デバイス、磁気記憶デバイス、又はこれらのあらゆる適切な組み合わせ。  
上記の実施形態に加えて、以下の付記を開示する。
（付記１）
少なくとも１つのネットワークに属し、少なくとも１つのサーバから、該サーバにおいて１つよりも多いデータレートで利用可能であるストリーミングコンテンツを受信するよう構成される適応ストリーミングクライアントのためのバンド幅をリザーブする方法であって、
少なくとも１つのイベントが起こる場合に、前記クライアントによって要求されている前記ストリーミングコンテンツに関連した所定の目標データレートと、トランジェントマージンとに応じて、トランジェントバンド幅を前記クライアントのためにリザーブするステップ
を有する方法。
（付記２）
前記トランジェントマージンは、次のパラメータ：
−  前記ネットワークのトータルの利用可能なバンド幅、
−  前記ストリーミングコンテンツに関連した前記所定の目標データレート、
−  前記ネットワークのバンド幅を共有している競合するストリーム、
−  前記ストリーミングコンテンツのプライオリティ、
−  前記適応ストリーミングクライアントの保守的な値
のうちの少なくとも１つに依存する、
付記１に記載の方法。
（付記３）
前記適応ストリーミングクライアントが保守的な値を使用するとして、前記トランジェントマージンは前記保守的な値よりも大きい、
付記１又は２に記載の方法。
（付記４）
前記トランジェントバンド幅は、前記目標データレートに前記保守的な値を加えたものよりも大きく、
前記目標データレートよりも高い少なくとも１つの他のデータレートが前記サーバで利用可能である場合に、前記トランジェントバンド幅は、前記より高いデータレートに前記適応ストリーミングクライアントの前記保守的な値を加えたものよりも小さい、
付記３に記載の方法。
（付記５）
前記目標データレートが前記サーバによって提供される最大データレートである場合に、前記トランジェントマージンは、前記ネットワークのトータルの利用可能なバンド幅と前記目標データレートとの間の差以下である、
付記１乃至４のうちいずれか１つに記載の方法。
（付記６）
前記トランジェントバンド幅は、前記クライアントのバッファの充填速度に依存するトランジェント期間の間、前記適応ストリーミングクライアントのためにリザーブされる、
付記１乃至５のうちいずれか１つに記載の方法。
（付記７）
前記トランジェントバンド幅は、前記クライアントのバッファの充填率に依存するトランジェント期間の間、前記適応ストリーミングクライアントのためにリザーブされる、
付記１乃至６のうちいずれか１つに記載の方法。
（付記８）
前記クライアントがデータの連続的なチャンクの形で前記ストリーミングコンテンツを受信するとして、前記トランジェント期間は、前記クライアントのバッファにおいて前記クライアントによってロードされるチャンクの数が、バッファ長に、経過時間の間に前記適応ストリーミングクライアントによって再生されると推測されるチャンクの数を加えたものを超える場合に、終了する、
付記６又は７に記載の方法。
（付記９）
前記クライアントがデータの連続的なチャンクの形で前記ストリーミングコンテンツを受信するとして、前記トランジェント期間は、チャンク要求周波数がチャンクの存続期間に等しい場合に終了する、
付記６又は７に記載の方法。
（付記１０）
前記イベントは、次のイベント群：
−  前記適応ストリーミングクライアントによる前記ストリーミングコンテンツの受信の開始、
−  ネットワーク条件の変化、
−  他のストリームの受信の停止
に属する、
付記１乃至９のうちいずれか１つに記載の方法。
（付記１１）
少なくとも１つのネットワークに属し、少なくとも１つのサーバから、該サーバにおいて１つよりも多いデータレートで利用可能であるストリーミングコンテンツを受信するよう構成される適応ストリーミングクライアントのためのバンド幅をリザーブするデバイスであって、
−  前記クライアントによって要求されている少なくとも１つのストリーミングコンテンツを検出するよう構成されるストリーム識別部と、
−  少なくとも１つのイベントが起こる場合に、前記要求されているストリーミングコンテンツに関連した所定の目標データレートと、トランジェントマージンとに応じて、トランジェントバンド幅を前記クライアントのためにリザーブするよう構成されるバンド幅マネージャと
を有するデバイス。
（付記１２）
次のイベント群：
−  前記適応ストリーミングクライアントによる前記ストリーミングコンテンツの受信の開始、
−  ネットワーク条件の変化、
−  他のストリームの受信の停止
に属する前記イベントを検出するよう構成される
付記１１に記載のデバイス。
（付記１３）
前記適応ストリーミングクライアントが保守的な値を使用するとして、前記トランジェントマージンは前記保守的な値よりも大きい、
付記１１又は１２に記載のデバイス。
（付記１４）
コンピュータによって読み出し可能な及び／又はプロセッサによって実行可能な媒体において記録される及び／又は通信ネットワークからダウンロード可能なコンピュータプログラム製品であって、
付記１乃至９の少なくとも１つに記載の方法を実施するプログラムコード命令を有するコンピュータプログラム製品。
（付記１５）
プロセッサによって実行されることが可能なコンピュータプログラム製品を記録している非一時的なコンピュータ可読媒体であって、
付記１乃至９の少なくとも１つに記載の方法を実施するプログラムコード命令を含む非一時的なコンピュータ可読媒体。
【図１】
0006403768.tif 000002
【図２】
0006403768.tif 000003
【図３】
0006403768.tif 000004
【図４】
0006403768.tif 000005