(57)【特許請求の範囲】
【請求項１】
少なくとも１つの相互接続ネットワークを通して、サーバデバイスとクライアントデバイスの間でストリーミングメディア転送を開始する方法であって、
データストリームの初期部分を、複数のネットワークリソースを経由してサーバデバイスからクライアントデバイスへ選択的に転送し、
複数のネットワークリソースの一部を経由する、サーバデバイスからクライアントデバイスへの保証サービス品質経路を確立し、
データストリームの後続部分を、保証サービス品質経路を利用してサーバデバイスからクライアントデバイスへ選択的に転送する
ことを特徴とする方法。
【請求項２】
請求項１に記載の方法において、データストリームの初期部分をサーバデバイスからクライアントデバイスへ選択的に転送する処理は、サーバデバイスからクライアントデバイスへの保証サービス品質経路を確立している間に、少なくとも部分的に行われることを特徴とする方法。
【請求項３】
請求項１に記載の方法において、データストリームの初期部分をサーバデバイスからクライアントデバイスへ選択的に転送する処理は、サーバデバイスからクライアントデバイスへの保証サービス品質経路の確立が完了するまで行われることを特徴とする方法。
【請求項４】
請求項１に記載の方法において、データストリームの初期部分をサーバデバイスからクライアントデバイスへ選択的に転送する処理では、第１のプロトコルを使用してデータコネクションを確立し、保証サービス品質経路を確立する処理では、第２のプロトコルを使用して保証フロー指定を確立することを特徴とする方法。
【請求項５】
請求項４に記載の方法において、第１のプロトコルはリアルタイムストリーミングプロトコル（Ｒｅａｌ−Ｔｉｍｅ  Ｓｔｒｅａｍｉｎｇ  Ｐｒｏｔｏｃｏｌ    ＲＴＳＰ）を含むことを特徴とする方法。
【請求項６】
請求項４に記載の方法において、第２のプロトコルはリソース予約プロトコル（Ｒｅｓｏｕｒｃｅ  Ｒｅｓｅｒｖａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ    ＲＳＶＰ）を含むことを特徴とする方法。
【請求項７】
請求項１に記載の方法において、データストリームの初期部分は、複数のネットワークリソース上を第１レベルのサービス品質で転送され、データストリームの後続部分は、保証サービス品質経路上を第１レベルのサービス品質よりも高い、第２レベルのサービス品質で転送されることを特徴とする方法。
【請求項８】
少なくとも１つの相互接続ネットワークを通して、サーバデバイスとクライアントデバイスの間でストリーミングデータ転送を開始するステップを実行するコンピュータ実行可能命令を格納しているコンピュータ読取可能媒体であって、前記ステップは、
データストリームの初期部分を、複数のネットワークリソースを経由してサーバデバイスからクライアントデバイスへ選択的に転送するステップと、
複数のネットワークリソースの一部を経由する、サーバデバイスからクライアントデバイスへの保証サービス品質経路を確立するステップと、
データストリームの後続部分を、保証サービス品質経路を利用してサーバデバイスからクライアントデバイスへ選択的に転送するステップと
を含むことを特徴とするコンピュータ読取可能媒体。
【請求項９】
請求項８に記載のコンピュータ読取可能媒体において、データストリームの初期部分をサーバデバイスからクライアントデバイスへ選択的に転送するステップは、サーバデバイスからクライアントデバイスへの保証サービス品質経路を確立している間に、少なくとも部分的に行われることを特徴とするコンピュータ読取可能媒体。
【請求項１０】
請求項８に記載のコンピュータ読取可能媒体において、データストリームの初期部分をサーバデバイスからクライアントデバイスへ選択的に転送するステップは、サーバデバイスからクライアントデバイスへの保証サービス品質経路の確立が完了するまで行われることを特徴とするコンピュータ読取可能媒体。
【請求項１１】
請求項８に記載のコンピュータ読取可能媒体において、データストリームの初期部分をサーバデバイスからクライアントデバイスへ選択的に転送するステップでは、第１のプロトコルを使用してデータコネクションを確立し、保証サービス品質経路を確立するステップでは、第２のプロトコルを使用して保証フロー指定を確立することを特徴とするコンピュータ読取可能媒体。
【請求項１２】
請求項１１に記載のコンピュータ読取可能媒体において、第１のプロトコルはリアルタイムストリーミングプロトコル（Ｒｅａｌ−Ｔｉｍｅ  Ｓｔｒｅａｍｉｎｇ  Ｐｒｏｔｏｃｏｌ    ＲＴＳＰ）を含むことを特徴とするコンピュータ読取可能媒体。
【請求項１３】
請求項１１に記載のコンピュータ読取可能媒体において、第２のプロトコルはリソース予約プロトコル（Ｒｅｓｏｕｒｃｅ  Ｒｅｓｅｒｖａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ    ＲＳＶＰ）を含むことを特徴とするコンピュータ読取可能媒体。
【請求項１４】
請求項８に記載のコンピュータ読取可能媒体において、データストリームの初期部分は、複数のネットワークリソース上を第１レベルのサービス品質で転送され、データストリームの後続部分は、保証経路上を第１レベルのサービス品質よりも高い、第２レベルのサービス品質で転送されることを特徴とするコンピュータ読取可能媒体。
【請求項１５】
少なくとも１つの相互接続ネットワークを通して、クライアントデバイスへのストリーミングメディア転送を開始する上で使用するのに適しているサーバデバイスであって、該サーバデバイスは、
データストリームの少なくとも一部を収めているメモリと、
動作可能にメモリに結合されたロジックとを備え、
該ロジックは、
データストリームの初期部分をメモリからクライアントデバイスへ選択的に出力し、
クライアントデバイスへの保証サービス品質経路の確立をサポートし、
データストリームの後続部分を、保証サービス品質経路上をクライアントデバイスへ選択的に出力する
ように構成可能であることを特徴とするサーバデバイス。
【請求項１６】
請求項１５に記載のサーバデバイスにおいて、ロジックは、さらに、クライアントデバイスへの初期データストリームの転送と、保証サービス品質経路の確立を同時に行うように構成可能であることを特徴とするサーバデバイス。
【請求項１７】
請求項１５に記載のサーバデバイスにおいて、ロジックは、さらに、クライアントデバイスへの保証サービス品質経路の確立が完了するまで初期データストリームをクライアントデバイスへ転送するように構成可能であることを特徴とするサーバデバイス。
【請求項１８】
請求項１５に記載のサーバデバイスにおいて、ロジックは、さらに、第１のプロトコルを使用してデータコネクションを確立し、第２のプロトコルを使用して保証フロー指定を確立するように構成可能であることを特徴とするサーバデバイス。
【請求項１９】
請求項１８に記載のサーバデバイスにおいて、第１のプロトコルはリアルタイムストリーミングプロトコル（Ｒｅａｌ−Ｔｉｍｅ  Ｓｔｒｅａｍｉｎｇ  Ｐｒｏｔｏｃｏｌ    ＲＴＳＰ）を含むことを特徴とするサーバデバイス。
【請求項２０】
請求項１８に記載のサーバデバイスにおいて、第２のプロトコルはリソース予約プロトコル（Ｒｅｓｏｕｒｃｅ  Ｒｅｓｅｒｖａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ    ＲＳＶＰ）を含むことを特徴とするサーバデバイス。
【請求項２１】
請求項１５に記載のサーバデバイスにおいて、ロジックは、データストリームの初期部分を、複数のネットワークリソース上を第１レベルのサービス品質で転送し、データストリームの後続部分を、保証サービス品質経路上を第１レベルのサービス品質よりも高い、第２レベルのサービス品質で転送するように構成可能であることを特徴とするサーバデバイス。
【請求項２２】
少なくとも１つの相互接続ネットワークを通して、サーバデバイスからのデータストリーミング転送を開始するのに使用に適したクライアントデバイスであって、該クライアントデバイスは、
データストリームの少なくとも一部を収めておくのに適したメモリと、
動作可能にメモリに結合されたロジックとを備え、
該ロジックは、
サーバデバイスからデータストリームの初期部分を選択的に受信し、
サーバデバイスからの保証サービス品質経路の確立をサポートし、
データストリームの後続部分を、保証サービス品質経路を利用してサーバデバイスから選択的に受信する
ように構成可能であることを特徴とするクライアントデバイス。
【請求項２３】
請求項２２に記載のクライアントデバイスにおいて、ロジックは、さらに、クライアントデバイスからの初期データストリームの受信と、保証サービス品質経路の確立を同時に行うように構成可能であることを特徴とするクライアントデバイス。
【請求項２４】
請求項２２に記載のクライアントデバイスにおいて、ロジックは、さらに、クライアントデバイスへの保証サービス品質経路の確立が完了するまで初期データストリームをクライアントデバイスから受信するように構成可能であることを特徴とするクライアントデバイス。
【請求項２５】
請求項２２に記載のクライアントデバイスにおいて、ロジックは、さらに、第１のプロトコルを使用してデータコネクションを確立し、第２のプロトコルを使用して保証フロー指定を確立するように構成可能であることを特徴とするクライアントデバイス。
【請求項２６】
請求項２５に記載のクライアントデバイスにおいて、第１のプロトコルはリアルタイムストリーミングプロトコル（Ｒｅａｌ−Ｔｉｍｅ  Ｓｔｒｅａｍｉｎｇ  Ｐｒｏｔｏｃｏｌ    ＲＴＳＰ）を含むことを特徴とするクライアントデバイス。
【請求項２７】
請求項２５に記載のクライアントデバイスにおいて、第２のプロトコルはリソース予約プロトコル（Ｒｅｓｏｕｒｃｅ  Ｒｅｓｅｒｖａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ    ＲＳＶＰ）を含むことを特徴とするクライアントデバイス。
【請求項２８】
請求項２２に記載のクライアントデバイスにおいて、ロジックは、データストリームの初期部分を第１レベルのサービス品質で受信し、データストリームの後続部分を、第１レベルのサービス品質よりも高い、第２レベルのサービス品質で受信するように構成可能であることを特徴とするクライアントデバイス。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明はコンピュータおよびコンピュータネットワークに関し、さらに具体的には、エンドユーザのためにメディアストリーミング体験を大幅に向上し、ＱｏＳ（Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ：サービス品質）フィーチャに対するサポートを提供する方法と構成に関する。
【０００２】
【従来の技術】
コンピュータおよびデータコミュニケーションネットワークはますます高速化している。この種の高速デバイスと構成が広く使用されている目的の１つは、１種または２種以上のメディアに関連するデータストリームを提供することである。例えば、インターネット（ｔｈｅ  Ｉｎｔｅｒｎｅｔ）の多くのユーザは、ビデオデータおよび／またはオーディオデータを、他のコンピュータまたはサーバから選択的にダウンロードまたは「ストリーム化（ｓｔｒｅａｍｉｎｇ）」している。メディアデータを符号化（ｅｎｃｏｄｅ：エンコード）・ストリーム化し、そのあとでストリーム化メディアを受信し、ユーザのためにプレイ（再生）するためのアプリケーションが利用可能になっている。従って、ユーザは、コンピュータネットワークを利用して、符号化／ストリーム化ニュースプログラムを見たり、リアルタイムの投資情報を受信したり、符号化／ストリーム化ラジオショウを聴くことが可能になっている。
【０００３】
残念ながら、ユーザは、種々の理由で、メディアデータのストリーミングに望ましくない中断が起こる事態を、しばしば体験することがある。例えば、ネットワークが瞬時に輻輳することがあるため、ストリーミングデータの一部が失われることが起こっている。この不確実性の多くは、ストリーム化データを、受信側コンピュータまたは類似デバイスに適切にバッファリングしておくことで解決することができる。この問題を解決する、もう１つの方法は、介在するネットワークリソースを通過するデータ経路（ｄａｔａ  ｐａｔｈ）を専用化するか、あるいは他の方法で保証することである。これらの種々リソースは、ストリーミングデータに対して一定レベルのサービス、つまり、ＱｏＳ（Ｑｕａｌｉｔｙ  ｏｆＳｅｒｖｉｃｅ：サービス品質）を保証するように構成することができる。これは、マルチパーティカンファレンシング（ｍｕｌｔｉｐｌｅ  ｐａｒｔｙ  ｃｏｎｆｅｒｅｎｃｉｎｇ）アプリケーションなどのように、ツーウェイ（双方向）コミュニケーション（ｔｗｏ−ｗａｙ  ｃｏｍｍｕｎｉｃａｔｉｏｎ）を必要とするアプリケーションをサポートするために行われているのが普通である。
【０００４】
ストリーム化メディアデータの受信時に起こる中断のほかに、ユーザは、種々のサポートソフトウェアおよびハードウェアシステムが、メディアデータのストリーム化のためのセットアップを行い、メディアデータをストリーム化／バファッリングすることを開始するために必要な、該当情報をやりとりしている間に、初期セッションスタートアップレイテンシ（ｌａｔｅｎｃｙ）または遅延を体験することがよく起こっている。
【０００５】
【発明が解決しようとする課題】
ストリーミングメディアに関連する上記および他の問題は、全体的エンドユーザ体験を低下させる傾向がある。その結果、スタートアップレイテンシを実効的に低減し、ＱｏＳ機能をサポートする、改良方法と構成が要望されている。
【０００６】
【課題を解決するための手段】
本発明のいくつかの形態によれば、例えば、リアルタイムストリーミングプロトコル（Ｒｅａｌ−Ｔｉｍｅ  Ｓｔｒｅａｍｉｎｇ  Ｐｒｏｔｏｃｏｌ    ＲＴＳＰ）やリソース（資源）予約プロトコル（Ｒｅｓｏｕｒｃｅ  Ｒｅｓｅｒｖａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ    ＲＳＶＰ）のように、それぞれがメディアストリーミングとＱｏＳ（Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ：サービス品質）をサポートしているプロトコルを、スタートアップレイテンシを大幅に低減化するのと同時に、エンドユーザによる全体的ビューイング体験を向上するような形で統合化している改良方法と構成が提供されている。
【０００７】
例えば、いくつかの実装では、方法と構成は、おそらくはＱｏＳが低下している初期に、可能な限り速やかにメディアのストリーミングを開始し、その間に、より望ましいまたは該当するＱｏＳ機能を同時にセットアップすることを基本としている。方法と構成は、さらに、種々のネットワーク輻輳問題などに対応して、ストリーミングメディアをダイナミックにおよび／または選択的に修正するようにインテリジェントに実現することが可能になっている。従って、既存ストリーミングオペレーション期間に異なる／ダイナミックＱｏＳ機能をセットアップすることが可能であり、新しいＱｏＳ機能のセットアップが完了した時点で、ストリーミングオペレーションを、それに応じて修正することが可能になっている。種々の方法と構成によれば、ユーザの体験を著しく混乱させることなく、かかる機能が得られる。
【０００８】
本発明の種々方法と構成の理解を容易にするために、以下では、添付図面を参照して詳しく説明されている。
【０００９】
【発明の実施の形態】
図１は、選択的ＱｏＳ（Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ：サービス品質）機能を備えた少なくとも１つの相互接続ネットワークを通して、少なくとも１つのサーバデバイス１０２から少なくとも１つのクライアントデバイス１０４へのメディアストリーミングをサポートするように構成可能である例示クライアント・サーバ構成１００を示すブロック図である。
【００１０】
この単純な構成に示すように、ネットワーク１０６は、サーバデバイス１０２とクライアントデバイス１０４が、１つまたは２つ以上のルータ１０８または類似デバイスを経由してツーウェイコミュニケーションを行うことを可能にしている。この構成では、例えば、ネットワーク１０６はパケット交換ネットワーク（ｐａｃｋｅｔ  ｓｗｉｔｃｈｅｄ  ｎｅｔｗｏｒｋ）にすることが可能であり、このネットワークは伝送制御プロトコル／インターネットプロトコル（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ    ＴＣＰ／ＩＰ）を使用して、サーバデバイス１０２とクライアントデバイス１０４間の情報が、相応にアドレス指定され、ルータ１０８を経由して配送されるパケットに入れて転送されるように構成されている。紛失／破損パケットに対する再送サービスも用意されている。上記および他の周知プロトコルと手法は、通信し合う上記パーティ間に特定のサービスを提供することが可能になっている。
【００１１】
次に、図２を参照して説明する。図２は、サーバデバイス１０２としても、クライアントデバイス１０４としても使用するのに適している、例示コンピューティングシステム２００を示すブロック図である。コンピューティングシステム２００は、この例では、パーソナルコンピュータ（ｐｅｒｓｏｎａｌ  ｃｏｍｐｕｔｅｒ    ＰＣ）の形態になっているが、他の例では、コンピューティングシステムは、専用サーバ（ｄｅｄｉｃａｔｅｄ  ｓｅｒｖｅｒ）、特殊目的デバイス（ｓｐｅｃｉａｌ−ｐｕｒｐｏｓｅ  ｄｅｖｉｃｅ）、機器（ａｐｐｌｉａｎｃｅ）、ハンドヘルド（ｈａｎｄｈｅｌｄ）コンピューティングデバイス、セルラ電話デバイス（ｃｅｌｌｕｌａｒ  ｔｅｌｅｐｈｏｎｅ  ｄｅｖｉｃｅ）、ページャデバイス（ｐａｇｅｒ  ｄｅｖｉｃｅ）などの形態にすることが可能である。
【００１２】
図示のように、コンピューティングシステム２００は、処理ユニット２２１、システムメモリ２２２、およびシステムバス２２３を含んでいる。システムバス２２３は、システムメモリ２２２と処理ユニット２２１を含む種々のシステムコンポ−メントを１つにリンクしている。システムバス２２３は、数種タイプのバス構造のいずれかにすることが可能であり、その中には、さまざまなバスアーキテクチャのいずれかを採用するメモリバスまたはメモリコントローラ、ペリフェラル（周辺）バス、およびローカルバスが含まれている。システムメモリ２２２の代表例としては、リードオンリメモリ（ｒｅａｄ  ｏｎｌｙ  ｍｅｍｏｒｙ  ＲＯＭ）２２４とランダムアクセスメモリ（ｒａｎｄｏｍ  ａｃｃｅｓｓ  ｍｅｍｏｒｙ    ＲＡＭ）２２５がある。基本入出力システム（ｂａｓｉｃ  ｉｎｐｕｔ／ｏｕｔｐｕｔ  ｓｙｓｔｅｍ    ＢＩＯＳ）２２６は、スタートアップ時のときのように、コンピューティングシステム２００内のエレメント間の情報転送を支援する基本ルーチンから構成され、ＲＯＭ  ２２４に格納されている。コンピューティングシステム２２０は、さらに、ハードディスク（図示せず）との間で読み書きするハードディスクドライブ２２７、取り外し可能磁気ディスク２２９との間で読み書きする磁気ディスクドライブ２２８、およびＣＤ−ＲＯＭや他の光メディアのような他の取り外し可能光ディスク２３１との間で読み書きする光ディスクドライブ２３０を含んでいる。ハードディスクドライブ２２７、磁気ディスクドライブ２２８、および光ディスクドライブ２３０は、それぞれ、ハードディスクドライブインタフェース２３２、磁気ディスクドライブインタフェース２３３、および光ディスクドライブインタフェース２３４を介してシステムバス２２３に接続されている。これらのドライブおよびそれぞれに関連するコンピュータ読取可能媒体は不揮発性ストレージとして、コンピューティングシステム２００のためにコンピュータ読取可能命令、データ構造、コンピュータプログラムおよび他のデータを格納している。
【００１３】
いくつかのコンピュータプログラムは、ハードディスク、磁気ディスク２２９、光ディスク２３１、ＲＯＭ  ２２４またはＲＡＭ  ２２５に格納しておくことが可能であり、その中には、オペレーティングシステム２３５、１つまたは２つ以上のアプリケーションプログラム２３６、他のプログラム２３７、およびプログラムデータ２３８が含まれている。
【００１４】
ユーザは、キーボード２４０やポインティングデバイス２４２（マウスなど）といった、種々の入力デバイスを通してコマンドと情報を、コンピューティングシステム２２０に入力することができる。本発明にとって特に意義があるのは、リアルタイムデータ２５６を取り込んだり、他の方法で出力したりする機能を備えたカメラ／マイクロホン２２５や他の類似メディアデバイスも、入力デバイスとしてコンピューティングシステム２２０に装備できることである。リアルタイムデータ２５６は、該当インタフェース２５７を介してコンピューティングシステム２００に入力することができる。このインタフェース２５７はシステムバス２２３に接続できるので、リアルタイムデータ２５６をＲＡＭ  ２２５や他のデータストレージデバイスのどれかに格納しておくことも、他の方法で処理することも可能になっている。
【００１５】
図示のように、モニタ２４７や他のタイプのディスプレイデバイスも、ビデオアダプタ２４８などの、インタフェースを介してシステムバス２２３に接続されている。モニタのほかに、コンピューティングシステム２００は、スピーカ、プリンタなどの、他のペリフェラル（周辺）出力デバイス（図示せず）を装備することも可能である。
【００１６】
コンピューティングシステム２００は、リモートコンピュータ２４９などの、１つまたは２つ以上のリモートコンピュータとの論理コネクションを使用するネットワーキング環境で動作することができる。リモートコンピュータ２４９は、別のパーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイスまたは他の共通ネットワークノードにすることが可能であり、図２にはメモリストレージデバイス２５０だけが示されているが、コンピューティングシステム２００に関連して上述したエレメントの多くまたは全部を実装しているのが代表的である。
【００１７】
図２に示す論理コネクションとしては、ローカルエリアネットワーク（ｌｏｃａｌ  ａｒｅａ  ｎｅｔｗｏｒｋ    ＬＡＮ）２５１と広域ネットワーク（ｗｉｄｅ  ａｒｅａ  ｎｅｔｗｏｒｋ    ＷＡＮ）２５２がある。この種のネットワーキング環境は、オフィス、企業内（ｅｎｔｅｒｐｒｉｓｅ−ｗｉｄｅ）コンピュータネットワーク、イントラネット（Ｉｎｔｒａｎｅｔｓ）およびインターネット（ｔｈｅ  Ｉｎｔｅｒｎｅｔ）で普及している。
【００１８】
ＬＡＮネットワーキング環境で使用されるときは、コンピューティングシステム２００は、ネットワークインタフェースやアダプタ２５３を通してローカルネットワーク２５１に接続されている。ＷＡＮネットワーキング環境で使用されるときは、コンピューティングシステム２００は、インターネットのような、広域ネットワーク２５２上のコミュニケーションを確立するためのモデム２５４や他の手段を装備しているのが代表的である。モデム２５４は内蔵型と外付け型があり、どちらも、シリアルポートインタフェース２４６を介してシステムバス２２３に接続されている。
【００１９】
ネットワーキング環境では、コンピューティングシステム２００に関連して示されているコンピュータプログラムまたはその一部は、リモートメモリストレージデバイスに格納しておくことができる。なお、以上から理解されるように、図示のネットワークコネクションは単なる例示であり、コンピュータ間のコミュニケーションリンクを確立する他の手段を使用することも可能である。
【００２０】
以下では、ストリーミングメディアセッションの向上を可能にする、本発明のいくつかの形態を中心に説明することにする。
【００２１】
ストリーミングメディアセッションを確立し、それを維持するためには、ネットワーク１０６内のサーバデバイス１０２、クライアントデバイス１０４、および適用可能なデバイス（もしあれば）は、該当する通信プロトコルが実装されている必要がある。
【００２２】
本明細書のこのセクションでは、本発明のいくつかの形態が説明され、そこでは、周知の通信プロトコルとシステムを利用する方法と構成が例示されているが、これらは単なる一例にすぎない。当業者ならば理解されるように、本明細書に示されている方法と構成は、上記および／または他の公知または将来のプロトコルや類似プロトコルを使用する実装に容易に適応可能である。
【００２３】
以上のことを念頭に置くと、インターネットや他の類似ネットワークを経由するストリーミングメディアデータ用に現在計画されているものとして、以下に示すように３つの関係プロトコルがある。
【００２４】
最初のプロトコルはＲｅＳｅｒＶａｔｉｏｎプロトコル（ＲＳＶＰ）であり、これは、ネットワークリソースを直接に制御する下位層プロトコルを取り扱う、ネットワーク制御プロトコルである。そのために、ＲＳＶＰは、特定のＱｏＳに合致するために要求されるネットワーク１０６のリソースを予約する機能を備えている。しかし、ＲＳＶＰは、自身ではどのデータも配送しない。その代わりに、データ配送は、ＴＣＰ／ＩＰ、ユーザデータグラムプロトコル（Ｕｓｅｒ  Ｄａｔａｇｒａｍ  Ｐｒｏｔｏｃｏｌ    ＵＤＰ）、リアルタイムトランスポートプロトコル（Ｒｅａｌ−Ｔｉｍｅ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ    ＲＴＰ）などの、別のプロトコルによって行われている。
【００２５】
ＲＴＰは、リアルタイムデータをトランスポートすることを目的としたトランスポート層プロトコルである。従って、ＲＴＰは、エンドツーエンド配送サービス、タイムスタンピング、シーケンス番号付け（ｓｅｑｕｅｎｃｅ  ｎｕｍｂｅｒｉｎｇ）、などの機能を備えている。特定のＱｏＳを提供するために、ＲＴＰはＲＶＳＰを利用してリソース予約を行うことが可能になっている。追加のデータ品質と参加者管理は、ＲＴＰの制御部分である、リアルタイム制御プロトコル（Ｒｅａｌ−Ｔｉｍｅ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ    ＲＴＣＰ）から得ることが可能になっている。
【００２６】
構成１００に関連して関心のある、第３のプロトコルはリアルタイムストリーミングプロトコル（ＲＴＳＰ）であり、これは、サーバデバイス１０２からクライアントデバイス１０４へのストリーミングメディアの配送を開始し、指示するアプリケーション層制御プロトコルである。ＲＴＳＰが「ネットワークＶＣＲリモート制御プロトコル」にたとえられているのは、このプロトコルによると、クライアントデバイスのアプリケーション／ユーザは、プレイ、ポーズ（休止）、巻き戻し、高速前送り（ｆａｓｔ  ｆｏｒｗａｒｄ）、などの機能を得ることができるからである（ストリーム化されるタイプのメディアに適用されたとき）。実際のデータ配送は別に行われ、ＲＴＰによって行われることが多い。
【００２７】
エンドユーザの体験を良好化するためには、例えば、エンコーダ、プレイヤなどのストリーミングメディアアプリケーションは、ストリーミングメディアセッション期間に、エンドツーエンドネットワーキングリソースを予約しておくことが要求される。ネットワーキングリソースは、ストリーム化されるメディアプロファイル（ｍｅｄｉａ  ｐｒｏｆｉｌｅ）をサポートするために利用できる、十分なバンド幅を確保しておくために必要になるものである。
【００２８】
従って、上述したように、ＲＳＶＰや他の類似プロトコルは、トラフィックプロファイルに基づいて所要バンド幅を予約するために採用することができ、ＲＴＰや他の類似プロトコルは、予約されたネットワークリソースを利用してストリーミングメディアをトランスポートするために採用することができ、ＲＴＳＰや他の類似プロトコルは、ストリーミングメディアに対して制御を行うことによって、エンドユーザの体験を良好化するために採用することができる。
【００２９】
ストリーミングメディアアプリケーションおよびそのアプリケーションの基礎となっているプロトコルスタックに直面している難題の１つは、ストリーミングメディアセッションを開始するコマンドに続く短時間の間に、エンドユーザに納得のいく高品質のメディアデータを提供する必要があることである。
【００３０】
以上のことを念頭に置いて、図３は、ＲＴＳＰとＲＴＰを使用して（つまり、ＱｏＳが用意されていない）メディアストリーミングセッションを確立するときに起こる、ある種のコントロールベース遅延の例を示す例示時間系列（ｔｉｍｅ−ｌｉｎｅ）グラフである。同図において、時刻ｔ０に、エンドユーザ（クライアントデバイス１０４）はストリーミングメディアセッションを開始する。時刻ｔ０から時刻ｔ１までに、サーバデバイス１０２は、必要に応じてクライアントデバイス１０４およびルータ１０８と通信して、セッションを開始する。時刻ｔ１から時刻ｔ２までに、メディアデータはストリーム化され、サーバデバイス１０２から１つまたは２つ以上のルータ１０８を経由してクライアントデバイス１０４に送られ、そこでメディアデータはバッファに置かれることになる。時刻ｔ２に、十分なデータがバッファリングされると、エンドユーザに対するストリーム化メディアデータのプレイが開始される。
【００３１】
この種のストリーミングメディアセッションの一例として、インターネット上を、ワールドワイドウェブ（Ｗｏｒｌｄ  Ｗｉｄｅ  Ｗｅｂ    ＷＷＷ）を通してビデオデータおよび／またはオーディオデータをストリーム化することがある。エンドユーザ、特に、低バンド幅のネットワークリソースを通して通信しているエンドユーザが、ストリーミングメディアセッションを開始してから、プレイされるメディアを見たり、聴いたりするまでに数秒間待たされることは、普通のことである。この待ち、つまり、セッションスタートセットアップレイテンシは、エンドユーザの体験を大幅に低減させる傾向がある。さらに、いったん確立されたストリーミングメディアセッションは、保証（ｇｕａｒａｎｔｅｅｄ）ＱｏＳが関連付けられていないのが通常である（例えば、ベストエフォート（ｂｅｓｔ−ｅｆｆｏｒｔ）で送信されている）。
【００３２】
図４に示す時間系列グラフは、本発明のいくつかの実施形態による、例示ストリーミングメディアセッションに関連して起こる類似の遅延を示しているが、そこでは、ＲＳＶＰで設定されている保証ＱｏＳがさらに含まれている。同図において、時刻ｔ０に、エンドユーザ（クライアントデバイス１０４）はストリーミングメディアセッションを開始する。時刻ｔ０から時刻ｔ１までに、サーバデバイス１０２は、必要に応じて（例えば、ＲＴＳＰおよびＲＴＰを使用して）、クライアントデバイス１０４およびルータ１０８と通信してセッションを開始する。時刻ｔ１から時刻ｔ２までに、サーバデバイス１０２は、さらに、必要に応じて（例えば、ＲＳＶＰを使用して）、クライアントデバイス１０４およびルータ１０８と通信して適用可能なネットワークリソースを予約する。時刻ｔ２に、メディアデータは、必要とするＱｏＳと共にストリーム化され、サーバデバイス１０２から予約ネットワーク経路（例えば、選択されたルータ１０８）を経由してクライアントデバイス１０４に送られ、そこでメディアデータは、エンドユーザのために即時にプレイされることになる。
【００３３】
従って、図４に示すように、エンドユーザが体験する総ＱｏＳは改善されているが、それでもなお、エンドユーザは、メディアとＱｏＳサービスがセットアップされるまで待たされることになっている。ある種の構成では、このような遅延（待ち）があると、ストリーミングメディアセッションおよび／または通信されるメディアの効果性が低下することになる。従って、セッションスタートアップレイテンシを低減することが、一層に望まれている。
【００３４】
次に、図５を参照して説明すると、図は、図１のクライアント・サーバ構成が、本発明の別の実施形態に従って例示メディアストリーミング環境を確立するときの様子を時間系列グラフ３００で示したものである。
【００３５】
図示のように、メディアセットアップ遅延期間３０２は、ＱｏＳセットアップ遅延期間３０４にオーバラップしている。その結果、エンドユーザが体験するセッションスタートアップレイテンシは最小限化され、さもなければ大幅に低減化されることが可能になっている。
【００３６】
前例に戻って説明すると、ある種の例示実施形態では、メディアセットアップ期間３０２には、クライアントデバイス１０４とサーバデバイス１０２がＲＴＳＰコマンド／メッセージをやりとりすることが含まれており、これらは、ストリーミングメディアを開始し、さもなければ制御するために必要になるものである。ＱｏＳセットアップ期間３０４には、保証ＱｏＳコネクションを確立するために必要になる、ＲＳＶＰコマンド／メッセージをやりとりすることが含まれている。
【００３７】
セットアップ期間３０２と３０４がいつ終了するか（つまり、完了するか）に関しては、変動する可能性があることから、ストリーミングメディアをプレイするために選択できるオプションがいくつか用意されている。
【００３８】
従って、例えば、セットアップ期間３０２と３０４が共に同時に終了する場合、あるいはＱｏＳセット期間３０２がメディアセットアップ期間３０２の終了前に完了する場合には、メディアデータは、メディアセットアップ期間３０２の完了時にストリーム化して、ＲＳＶＰ交渉経路（ＲＳＶＰ  ｎｅｇｏｔｉａｔｅｄ  ｐａｔｈ）を利用して保証ＱｏＳで送ることができる。
【００３９】
これに反して、メディアセットアップ期間３０２がＱｏＳセットアップ期間３０４の完了前に終了する場合には、メディアデータは、（１）ＲＳＶＰ交渉経路が準備状態（ｒｅａｄｙ）になるまで（つまり、ＱｏＳセットアップ期間３０４の終了時に）ストリーム化して非ＲＳＶＰ経路を利用して送ることができるが、そのためには、ストリーム化メディアデータの一部をクライアントデバイス１０４側のバッファに置いてから、エンドユーザのためにプレイする必要がある。または、（２）ＲＳＶＰ交渉経路が準備状態になるまで待たせておくこともできる。
【００４０】
このようなオプションが与えられていれば、ある種のアプリケーションは、おそらくは、優先（ｐｒｅｆｅｒｒｅｄ）ＱｏＳフォーマットになっていなくても、ストリーム化メディアを可能な限り早くプレイさせるかどうか、あるいはストリーム化メディアのプレイを、それが優先ＱｏＳフォーマットになるまで（例えば、十分な高品質になるまで、ＲＳＶＰ交渉経路で受信されるまで、といったように）待たせるかを、エンドユーザおよび／またはサーバアドミニストレータ（管理者）に選択させるように構成することも可能である。その結果、エンドユーザは、ストリーム化メディアセッションの開始時に、異なる遅延および／またはプレイされるメディア品質を体験することになる。
【００４１】
例として、エンドユーザは、可能な限り早くストリーム化ビデオデータを受信／プレイすることを選択したが、最終的には、保証ＱｏＳを望んでいると想定する。さらに、ネットワーク輻輳または他の類似原因の結果として、メディアセットアップ期間３０２の終了からＱｏＳセットアップ期間３０４の終了までに、約５秒間の待ちが生じたものと想定する。従って、この想定の下では、ビデオデータは、従来の「ベストエフォート（ｂｅｓｔ  ｅｆｆｏｒｔ）」コミュニケーションを使用してネットワーク１０６上でストリーミングを開始し、クライアントデバイス１０４側で瞬時に累積／バッファリングされたあとで（例えば、約２秒間を要したあとで）、エンドユーザのためにプレイされることになる。従って、若干待たされた後で、エンドユーザは、ストリーミングビデオの最初の３秒間を、そのとき望まれていた低品質で体験することになる。しかし、ＱｏＳセットアップ遅延期間３０４が終了し、ＲＳＶＰ交渉経路が確立されると、ストリーミングビデオは望みの品質になることになる。
【００４２】
上記の例では、セットアップ遅延期間３０２と３０４は、基本的にオーバラップしている。しかし、実装されるプロトコルに応じて、セットアップ遅延期間３０２と３０４を結合すると、エンドユーザが体験する遅延をさらに低減することが可能になる。
【００４３】
以下では、ＲＳＶＰシグナリングの概要を要約して説明する。上述したように、ＲＳＶＰは、専ら、標準化ＱｏＳ情報とパラメータを促進し、伝達することを目的としたネットワーキングプロトコルである。ＲＳＶＰは、汎用（業界定義の）ＱｏＳパラメータを、エンドノード（これも含む）からＲＳＶＰセッションメンバ間のホップ経路に置かれている各ＱｏＳ認識（ａｗａｒｅ）ネットワークデバイスへ伝達して行く。つまり、ＲＳＶＰによると、エンドユーザとネットワークデバイスは相互に連絡して、ＱｏＳパラメータとネットワークの使用許可を交渉することができる。
【００４４】
ＲＳＶＰは、種々のトポロジとメディアのネットワークを通してリソース予約要求を伝達することを目的としているので、エンドユーザのＱｏＳ要求は、データ経路上をすべてのＲＳＶＰ認識ネットワークデバイスへ伝播されて行き、ＲＳＶＰで使用許可された（ＲＳＶＰ−ｅｎａｂｌｅｄ）リソースのすべてからリソースが、すべてのネットワークレベルで予約できるようにしている。これは、ネットワーク１０６を望みのサービスレベルに合致させることに役立っている。
【００４５】
ＲＳＶＰは、エンドからエンドへネットワーク１０６を通るフローを確立することによってネットワークリソースを予約する。フローは、基本的には、１つまたは２つ以上の送信側、１つまたは２つ以上の受信側、およびある種のＱｏＳに関連するネットワーク経路である。ある種のＱｏＳを必要とするデータを送信しようとする送信側ホストは、ＱｏＳサービスプロバイダを経由して、”ＰＡＴＨ”メッセージを目的の受信側に向かってブロードキャストする。これらの経路（ｐａｔｈ）メッセージは、送信されるデータに必要なバンド幅と関係パラメータを記述しており、経路上を伝播されて行く。
【００４６】
この特定データに関心を持っている受信側ホストは、”ＲＥＳＶ”  メッセージを送信側に向かって、逆方向にネットワークに送り込むことによって、フロー（およびネットワーク経路）のためのリソースを予約する。これが行われると、ＲＳＶＰ機能をもつ（ＲＳＶＰ−ｃａｐａｂｌｅ）中間ノードは、バンド幅容量とポリシに基づいて、申し込まれた予約を受け付けて、リソースをコミットするかどうかを判断する。肯定の判断が行われると、リソースはコミットされ、ＲＥＳＶメッセージはソースからデスティネーションへの経路上の直前ホップへ伝播されて行く。
【００４７】
ＲＳＶＰプロトコルの心臓部は、ＰＡＴＨメッセージとＲＥＳＶメッセージのやりとりである。ＰＡＴＨメッセージは、トラフィックのＱｏＳパラメータ、送信側のアドレス、およびトラフィックのデスティネーションを記述している。ＲＥＳＶメッセージは、受信されるトラフィックのＱｏＳパラメータとトラフィックのソースを記述しており、送信側に向かって送信される。
【００４８】
ＲＥＳＶメッセージを受信すると、ＱｏＳデータフローが開始する。代表例として、ＱｏＳサービスプロバイダは、アプリケーションに代わって、ＰＡＴＨメッセージとＲＥＳＶメッセージを構築し、周期的に更新する。マルチキャスト（ｍｕｌｔｉｃａｓｔ）伝送を制御するアプリケーションのような、送信側アプリケーションは、ベストエフォートで送信を即時に開始するように構成することも可能であり、そのあと、この構成は、ＲＥＳＶメッセージの受信時にＱｏＳにアップグレードさせることができる。
【００４９】
次に、図６のイベント系列（ｅｖｅｎｔ−ｌｉｎｅ）グラフに示され、図７の関連テーブルに要約されている例示結合メッセージフローを参照して説明することにする。
【００５０】
この例では、ＲＳＶＰで使用許可されたストリーミングメディアセッションは、クライアントデバイス１０４とサーバデバイス１０２の間に、それぞれ実線の矢印と破線の矢印で示されているＲＴＳＰメッセージとＲＳＶＰメッセージのシーケンスによってセットアップされる。曲線の矢印は、種々メッセージがイベントに依存することを示している。
【００５１】
クライアントデバイス１０４は、セットアップされるメディアストリームごとに１つのＲＴＳＰ  ＳＥＴＵＰコマンドをサーバデバイス１０２に送信することによって、セッションセットアップを開始する。最後のＳＥＴＵＰコマンドを送信したあと、クライアントデバイス１０４は、ＲＴＳＰ  ＳＥＴ＿ＰＡＲＡＭＥＴＥＲコマンドを送信し、これによりＲＳＶＰシグナリングが開始される。ＳＥＴ＿ＰＡＲＡＭＥＴＥＲコマンドを受信すると、サーバデバイス１０２は、ＲＳＶＰ  ＰＡＴＨメッセージを送出する。ＳＥＴ＿ＰＡＲＡＭＥＴＥＲコマンドを送信したあと、クライアントデバイス１０４は先に進んで、ＲＴＳＰ  ＰＬＡＹコマンドを送出し、サーバデバイス１０２は、このＰＬＡＹコマンドを受信すると、データの送信を開始する。
【００５２】
ＰＡＴＨメッセージを受信すると、クライアントデバイス１０４はＲＳＶＰ  ＲＥＳＶメッセージをサーバデバイス１０２に送信し、サーバデバイス１０２はそのメッセージに対して、ＲＳＶＰ  ＲＥＳＶ  ＣＯＮＦメッセージで応答する。サーバデバイス１０２から出力されたメディアデータは、ＲＥＳＶメッセージが受信されるまでベストエフォートで送信される。ＲＥＳＶメッセージが受信されると、ストリーミングメディアデータフローは、保証ＱｏＳに変更される。
【００５３】
図７に示すテーブルには、類似のプロセスが示されている。なお、ここで注意すべきことは、リストされたステップはその実行順序が異なる場合があり、および／またはステップの一部は、他の実装／ケースでは、プロセスから除かれる場合があることである。テーブルにおいて、方向欄の”Ｃ”はクライアントデバイス１０４を表し、”Ｓ”はサーバデバイス１０２を表し、ポインタ（矢印）があるときは、情報が流れる方向を示し、ポインタがないときは、そこに示されたデバイス内でアクションが行われることを示している。
【００５４】
備考欄に示されているように、クライアントデバイス１０４は、サーバデバイス１０２からＰＡＴＨメッセージを受信したとき、利用可能なネットワークバンド幅でＦＤ＿ＱＯＳ通知を受信することができる。利用可能なバンド幅が、サーバデバイス１０２が要求するバンド幅以下であるときは、クライアントデバイス１０４は、予約なしでセッションを継続することも、要求を中止することもできる。
【００５５】
ＬＡＮや他の類似環境では、ネットワークバンド幅は、ストリーミングメディアが要求する以上に大幅に大きくなっているのが代表的であるので、セッションセットアップレイテンシをさらに低減するために、サーバデバイス１０２は、クライアントデバイス側のスタートアップバッファが一杯になるまで、最初は実際のストリームレートよりも高いレートでデータをストリーム化するように構成することができる。そのようにすると、クライアントデバイス１０４は、ストリーム化メディアデータのプレイバックを、通常の場合よりも早めに開始することが可能になる。例えば、別の信頼性のある（ＴＣＰ）コネクションを使用すると、初期高速スタート（ｉｎｉｔｉａｌ  ｆａｓｔ  ｓｔａｒｔ）関連のメディアデータをサーバデバイス１０２からクライアントデバイス１０４へ送信することが可能になる。
【００５６】
このような高速ストリーミングケースでは、例えば、クライアントデバイス１０４は、クライアントが要求できる、メディアストリームデータの最高バンド幅に相当するバンド幅を予約することが可能になる。サーバ伝送とＲＳＶＰ予約のやりとりは、サーバ側のデータ伝送も高速ビットレートで行われることを除けば、通常のメディアストリーミングケースで上述したのと同じように行われる。
【００５７】
以上のようにして、要求された高速ストリームは、例えば、現在のＲＳＶＰ予約が要求されたバンド幅をサポートするのに十分でない場合に、リアルタイムバンド幅よりも大きいバンド幅を使用してベストエフォートでストリーム化されることがサポートされている。このようにＲＳＶＰ予約が完了するまでストリームをベストエフォートで送信するという振る舞いが許されるのは、エンコーダ／サーバ構成が「ＲＳＶＰ予約が失敗したときベストエフォートで配送を行う」（例えば、「可能な限り早くプレイする」）設定状態を禁止していなかった場合である。そうでなければ、サーバデバイス１０２は、ＲＳＶＰ予約が再確立され、再交渉されるのを待ってからデータ送信プロセスを再開することになる。
【００５８】
上述した種々の手法は、進行中のストリーミングメディアセッションに関連するコミュニケーションの変更をダイナミックに行うこともサポートしている。従って、例えば、ＲＳＶＰまたは他の類似プロトコルシグナリングは、ストリーミングメディアに関連するＱｏＳを、ネットワーク１０６からの利用可能性／輻輳情報に基づいて低下および／または上昇させるために使用することができる。
【００５９】
例えば、ネットワーク状態に起因して、プログラムの中でストリームを低バンド幅ストリームにスイッチする必要が起こった場合には、初期予約は未変更のままにされ、サーバデバイス１０２側に置かれたトラフィックシェ−ピング（ｔｒａｆｆｉｃ  ｓｈａｐｉｎｇ）または類似機能は、新バンド幅に変更される。バンド幅が初期予約よりも大でない限り、サーバデバイス１０２は、以後のＲＳＶＰシグナリングを必要とすることなく、トラフィックシェ−ピングを異なるバンド幅に構成することができる。
【００６０】
現在の交渉値より高い値にストリームバンド幅をスイッチする必要が起こったときは、サーバデバイス１０２は、ベストエフォートモードでメディアデータを送信することを開始し、その間にＲＳＶＰストリームフローの交渉がパラレルに行われる。このようにＲＳＶＰ予約が完了するまでストリームをベストエフォートで送信するという振る舞いが許されるのは、エンコーダ／サーバ構成が「ＲＳＶＰ予約が失敗したときベストエフォート配送を行う」設定状態を禁止していなかった場合である。そうでなければ、サーバデバイス１０２は、ＲＳＶＰ予約が再確立され、再交渉されるのを待ってからデータを高レートで送信することになる。
【００６１】
サーバ側プレイリスト（ｐｌａｙ  ｌｉｓｔ）にもサポートが用意されているので、サーバデバイス１０２は、同じデータセッション上で複数のメディアストリームを次々にストリーム化することが可能になっている。同様に、クライアント側プレイリストを使用すると、クライアントデバイス１０４は、シングルプレイセッションで異なるメディアストリームを次々にプレイすることが可能になっている。
【００６２】
プレイリストの中の異なるストリームは、必要とするバンド幅が異なっていることがある。その結果、新しいストリームごとに予約を変更する必要が起こる場合がある。このスイッチをシームレス（ｓｅａｍｌｅｓｓ）にするために、ＲＳＶＰ予約の変更は、例えば、可能である限り、実際のストリームスイッチよりも約１０秒前に行うことができる。
【００６３】
従って、プレイリスト内の次のアイテムに要求されるバンド幅が現在の交渉値より低ければ、トラフィックシェ−ピングはサーバ側で行われ、データはフローのためのＲＳＶＰ予約を再交渉しなくても、送信されることになる。プレイリスト内の次のアイテムに要求されるバンド幅が現在の交渉値より高ければ、メディアデータは、ＲＳＶＰ予約が完了するまでベストエフォートで送信されることになる。パラレル交渉は、ＲＳＶＰコネクションに続けて、予約が成功した時点でＲＳＶＰフローへスイッチすることによって行うことができる。
【００６４】
このようにＲＳＶＰ予約が完了するまでストリームをベストエフォートで送信するという振る舞いが許されるのは、エンコーダ／サーバ構成が「ＲＳＶＰ予約が失敗したときベストエフォート配送を行う」設定状態を禁止していなかった場合である。そうでなければ、サーバデバイス１０２は、ＲＳＶＰ予約が再確立され、再交渉されるのを待ってから、プレイリスト内の次のアイテムに対するデータ送信プロセスが再開されることになる。
【００６５】
新ストリームの予約は、例えば、旧ストリームが終了する約１０秒前に開始される。これが行われるのは、サーバデバイス１０２が新ストリームに対するＳＥＴＵＰを受信したときである。新ストリームの予約が行われると、旧ストリームの予約は無視される。
【００６６】
サーバデバイス１０２は、セッションレスマルチキャストセッション（ｓｅｓｓｉｏｎ  ｌｅｓｓ  ｍｕｌｔｉｃａｓｔ  ｓｅｓｓｉｏｎｓ）の場合には、デフォルトでＰＡＴＨメッセージを送出することもできる（これはサービスプロバイダが行うのがデフォルトになっている）。クライアントデバイス１０４は、マルチキャストアドレスとポート番号情報を含んでいるアナウンスメント情報を取り出したあと、サーバデバイス１０２にＲＳＶＰ  ＲＥＳＶメッセージを送出して、トラフィックプロファイルのためのネットワーキングリソースとホストリソースを要求することができる。そのあと、サーバ・クライアント間のストリーミングメディアセッションは、上述したユニキャストのケースと同じように進行して行く。これらの種々手法は、マルチメディアストリーミング期間に、ＲＴＳＰまたは他の類似プロトコルベースセッションのフルマルチキャスト（ｆｕｌｌ−ｍｕｌｔｉｃａｓｔ）をサポートするのにも適している。
【００６７】
以上、本発明の種々方法と構成の好適実施形態のいくつかを、添付図面を参照して詳細に説明してきたが、本発明は上述してきた例示実施形態に限定されるものではなく、請求項に明確化されている本発明の精神から逸脱しない限り、種々態様に再構成し、変更し、置換することが可能である。
【図面の簡単な説明】
【図１】選択的ＱｏＳ（Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ）機能を備えた相互接続ネットワークを通して、サーバデバイスからクライアントデバイスへのメディアストリーミングをサポートするように構成可能である、例示クライアント・サーバ構成を示すブロック図である。
【図２】図１の構成においてサーバデバイスとしても、クライアントデバイスとしても使用するのに適している、例示コンピューティングシステムを示すブロック図である。
【図３】図３は、図１の構成において公知の通信プロトコルを使用してメディアストリーミングセッションを確立するときに起こる、ある種のコントロールベース遅延を、図例で示す時間系列グラフである。
【図４】図４は、図１の構成において公知の通信プロトコルを使用してメディアストリーミングセッションを確立するときに起こる、ある種のコントロールベース遅延を、図例で示す時間系列グラフである。
【図５】本発明のいくつかの実施形態に従って、図１の構成で例示手法を使用してメディアストリーミングセッションを確立するときに起こる、ある種のコントロールベース遅延を、図例で示す時間系列グラフである。
【図６】図１のクライアント・サーバ構成が、本発明のいくつかの実施形態に従って、例示メディアストリーミングセッションを確立する様子を、図例で示すイベント系列グラフである。
【図７】図６のイベント系列グラフに関連するプロセステーブルを示す図である。
【符号の説明】
１００  構成
１０２  サーバデバイス
１０４  クライアントデバイス
１０６  ネットワーク
１０８  ルータ
【図１】
0003819751.tif 000002
【図２】
0003819751.tif 000003
【図３】
0003819751.tif 000004
【図４】
0003819751.tif 000005
【図５】
0003819751.tif 000006
【図６】
0003819751.tif 000007
【図７】
0003819751.tif 000008