JP2004356922A - コンテンツ配信サーバ、及び端末装置 - Google Patents

Abstract

【課題】コンテンツ配信サービスを受信中に、通信路を切替えてサービスを継続する場合、セッション切替時に一時的な中断が発生する。また切替前と切替後の通信路の通信速度が大きく異なる場合には、同じサービスを継続できない場合がある。
【解決手段】クライアント端末に対し、同一内容であり、ビットレートが異なり、かつ時間同期がとれた２つのコンテンツ配信セッションを同時に確立し、クライアント端末で２つのセッションからのコンテンツデータの時刻情報を基にして、時間的に連続するようにセッションを切替える。
【選択図】 図１

Description

【０００１】
【発明の属する分野】
本発明は、複数の通信路による受信手段を備える通信端末装置、およびこの通信端末装置に対してコンテンツ配信サービスを提供する通信装置により構成されるコンテンツ配信システム及び端末装置に関する。
【０００２】
【従来の技術】
生活様式や勤労形態の多様化に伴い、携帯電話やＰＤＡ、ノートパソコンなどの移動端末により、いつでも、どこでもインターネットに接続して通信サービスを享受したいというニーズが高まってきている。近年のモバイル通信技術の進展により、現在は無線ＬＡＮやＷ−ＣＤＭＡ、ｃｄｍａ２０００、Ｂｌｕｅｔｏｏｔｈなど、複数の移動体通信網が利用可能である。移動端末は、各々の通信網に対応する通信アダプタを用いることで各々の通信網に接続が可能である。さらに一台の移動端末に複数の種類の通信アダプタを搭載することで、受信データの速度や、移動端末の通信状況などに応じて最適な通信網を選択したり、通信網を動的に切替えることが可能となっている。
移動端末が、サーバと接続してコンテンツ配信サービスを受けている際中に、動的に通信網を切替えてコンテンツ配信サービスを継続する場合には、コンテンツ配信サービスのセッション情報を、通信路に存在する中継装置やエージェントが常に保持しておき、切替後の通信網におけるコンテンツ配信サービスで、このセッション情報を用いて配信サービスを継続するのが一般的である。
ここでセッションとは、ある通信サービスを提供する送信装置と受信装置間の通信フロー、ならびにその通信サービスを提供するために送信装置と受信装置の双方において実行される一連のプロセスの集合を意味する。セッション情報とは、そのサービスを提供するセッションに関する総合的な情報であり、セッション情報としては例えば、サーバ／クライアント端末のＩＰアドレスとポート番号、通信プロトコル、セッション開始時刻、サービス経過時間、サービス名、使用アプリケーション名等が挙げられる。
上記のような、通信網切替時における配信サービスの継続のための方法として、ユーザが配信データの受信中に、セッション管理手段が端末からのリクエストに応じてセッション状態を切替えることで移動端末を切替えるものや（例えば、特許文献１参照）、セッション管理部からの要求に従ってプロキシ間で配信サービスのセッション情報を交換することで、移動端末の通信網の切替を柔軟に行う方法等が提案されている（例えば、特許文献２参照）。
【特許文献１】特開２００２−１７６４３２号公報
【特許文献２】特開２００２−６４５６２号公報
【発明が解決しようとする課題】
しかし上記従来の、通信網切替時における配信サービスの継続方法は、移動端末においてセッションを一時的に中断し、通信網を切替えた後、新たにセッションを再開するものである。このため映像など、受信データの継続性がサービス品質に大きく影響するような配信サービスでは、上記のようなセッションの一時中断によりユーザに対し不快感を与えるという問題があった。また通信網を切替える前と、切替える後とで通信網の通信速度等の特性が異なる場合、同じサービスを継続することが難しいという問題があった。
具体的には、上記特許文献１記載の技術は同一端末において一時中断なく配信サービスを提供することはできない。又、特許文献２記載の技術も移動端末においては、通信網を一方から他方へ切替えるまでの間の配信サービスの中断が発生してしまう。
本発明の目的は、上記の事情を鑑みてなされるものであり、移動端末における通信網切替時の配信サービスを、一時的に中断することなく継続する方法を提供することである。
【０００３】
【課題を解決するための手段】
上記目的を達成するため、本発明のコンテンツ配信システムにおける通信中継装置では、切替前の通信路におけるセッションと切替後の通信路におけるセッションを一時的に二つ同時に移動端末との間で確立することを特徴とする。
また本発明のコンテンツ配信システムにおける通信端末装置では、切替前と切替後の二つの通信路から受信するデータの経過時間情報に基づき、適切なタイミングでセッションを切替えることを特徴とする。
本特徴により、ユーザは配信サービスを一時的に中断することなく、新たな通信網において配信サービスを継続させることが可能となる。
【０００４】
【発明の実施の形態】
以下、図面を参照して本発明の実施形態について説明する。
図１〜図１９を参照して、本発明の実施形態１によるコンテンツ配信システムについて説明する。尚、以降のサーバ及び端末装置の処理はハード構成による実現方法の他、以降の処理を実行させるためのプログラムを読み込むこと、又はハードとソフトウェア処理の協調動作によっても実現可能であることはいうまでもない。
【０００５】
図２は、実施形態１によるコンテンツ配信システムの通信網の構成例を示す図である。同図の例では、コンテンツ配信サーバ１００と、中継サーバ１０２とはインターネット網２０２を介して接続されている。クライアント端末１１９は、基地局２０３との間で無線通信が可能であり、無線ＬＡＮ網２００と接続される。無線ＬＡＮ網２００は、インターネット網２０２と接続されており、クライアント端末１１９は無線ＬＡＮ網２０２を経由してインターネット網２０２と接続される。またクライアント端末１１９は、基地局２０４との間で無線通信が可能であり、１ｘＥＶ−ＤＯ（ｃｄｍａ２０００ １ｘ Ｅｖｏｌｕｔｉｏｎ Ｄａｔａ Ｏｎｌｙ）網２０１と接続される。１ｘＥＶ−ＤＯ網２０１は、インターネット網２０２と接続されており、クライアント端末１１９は１ｘＥＶ−ＤＯ網２０１を経由してインターネット網２０２と接続される。
【０００６】
図２の例では、クライアント端末１１９は、中継サーバ１０２を介してコンテンツ配信サーバ１００からコンテンツ配信サービスの提供を受ける。すなわちクライアント端末１１９は、コンテンツ配信サーバ１００に対するコンテンツ配信要求を中継サーバ１０２に対して送信し、中継サーバ１０２は受信したコンテンツ配信要求をコンテンツ配信サーバ１００へ転送する。コンテンツ配信サーバ１００は中継サーバ１０２からコンテンツ配信要求を受けると、中継サーバ１０２に対し要求されたコンテンツデータを配信する。中継サーバ１０２は配信サーバ１００から受信したコンテンツデータをクライアント端末１１９へ転送する。
以下では、無線ＬＡＮ網２００上で映像配信サービスセッションが確立された状態から、１ｘＥＶ−ＤＯ網２０１へ映像配信サービスセッションを切替える場合の、中継サーバ１０２、およびクライアント端末１１９の処理の詳細を説明する。
【０００７】
図１は中継サーバ１０２の構成を示す図である。サーバ間通信部１１０と１１１は、通信路＃１（１０１）を介してコンテンツ配信サーバ１００とのデータ送受信を行う部分である。キャッシュ１１２と１１３は、それぞれサーバ間通信部＃１（１１０）と、サーバ間通信部＃２（１１１）とが受信したコンテンツデータ１２０と１２１とを蓄積する部分である。コンテンツ送出部１１４は、キャッシュ＃１（１１２）とキャッシュ＃２（１１３）のいずれか、あるいは双方をそれぞれクライアント間通信部＃１（１１５）、およびクライアント間通信部＃２（１１６）へ渡す部分である。クライアント間通信部＃１（１１５）とクライアント間通信部＃２（１１６）は、それぞれ通信路＃２（１１７）と通信路＃３（１１８）を介してクライアント端末１１９とのコンテンツデータの送受信を行う部分である。セッション管理部１０３は、制御部１０４、セッション管理テーブル１０６、トラフィック監視部１０７、およびセッション切替判定部１０９から構成される。図１において、通信路＃１（１０１）は図２におけるインターネット網２０２、通信路＃２（１１７）は図２における無線ＬＡＮ網２００、通信路＃３（１１８）は図２における１ｘＥＶ−ＤＯ網２０１にそれぞれ相当する。
【０００８】
図６（Ａ）に、上述のセッション管理テーブル１０６の例を示す。同図におけるセッション管理テーブル１０６は、セッション情報と通信路情報、およびコンテンツセット情報とから構成される。セッション情報は、少なくともそのセッションで配信されているコンテンツＩＤ（コンテンツセット情報のＩＤに対応）と、キャッシュ情報、クライアント間通信情報とから構成される。キャッシュ情報は、上述のキャッシュ＃１（１１２）とキャッシュ＃２（１１３）に格納されるデータを管理するための情報であって、例えば、それぞれのキャッシュ内のコンテンツデータのコンテンツ時間範囲、キャッシュ内データサイズ、送信済みコンテンツデータのコンテンツ時間範囲などが含まれる。クライアント間通信情報はクライアント間の通信に関する情報であって、クライアント端末のＩＰアドレス、ポート番号等ユーザを識別できる情報、クライアント端末間の通信プロトコル情報、クライアント端末が受信した最新コンテンツ時刻、クライアント端末の受信スループットとその履歴情報などである。通信路情報は、クライアント端末１１９利用可能な全ての通信路に関する情報であり、例として、クライアントのＩＰアドレス、通信路のタイプや最大スループット、優先度、現在のスループット、及びその履歴情報などである。コンテンツセット情報は同一内容を持ち、コンテンツ属性の異なる複数のコンテンツの組を示す情報である。図４（Ｂ）に、コンテンツセット情報（ｈｔｔｐ：／／ｓｅｒｖｅｒ／ｃｏｎｔｅｎｔｓｅｔ．ｉｎｆｏ）の例４０２を示す。コンテンツセット情報例４０２では、ある同一の内容のコンテンツについて異なる属性情報を持つコンテンツファイルの複数の格納場所を示すＵＲＬ（“ｈｔｔｐ：／／ｓｅｒｖｅｒ／ｃｏｎｔｅｎｔ．ｍｐ４？ｂｒ＝５１２”、および“ｈｔｔｐ：／／ｓｅｒｖｅｒ／ｃｏｎｔｅｎｔ．ｍｐ４？ｂｒ＝２５６”）と、それぞれのＵＲＬで示されるコンテンツに関する属性情報４０３、４０４が記述されている。属性情報４０３、４０４にはそれぞれ、少なくとも通信速度や、端末がどの符号化方式をサポートするかに依存して、切り替えるコンテンツを選択するため、ファイルタイプ及び平均コンテンツレートに関する情報が含まれ、その他トータル時間、メディア情報が格納されている。メディア情報はメディアタイプによって識別され、各メディアタイプに対して独自の詳細情報が記述されている。図４の例では、メディアタイプが“Ｖｉｄｅｏ”である場合には、コーデックタイプ、平均レート、画像幅、画像高さ、フレームレートが記述されている。またメディアタイプが“Ａｕｄｉｏ”である場合には、コーデックタイプ、平均レート、チャネル数が記述されている。属性情報４０３、４０４で示されるコンテンツは、同じ内容に関するものであるが、データサイズの違い等からビットレートが異なる点が大きな特徴である。
【０００９】
図１５はクライアント端末１１９の構成を示す図である。中継サーバ間通信部１５０６と１５０７は、それぞれ通信路＃２（１１７）、通信路＃３（１１８）を介して中継サーバ１０２とのデータ送受信を行う部分である。分離部１５１２と１５１３は、それぞれ中継サーバ間通信部＃１（１５０６）と、中継サーバ間通信部＃２（１５０７）とが受信したコンテンツデータ（１２３、１２５）のヘッダ情報を解析し、メディアデータ（例えばビデオ・オーディオ符号化データ）（１５１４、１５１５）を抽出する部分である。デコードバッファ１５０８と１５０９は、それぞれ分離部＃１（１５１２）と、分離部＃２（１５１３）とが抽出したメディアデータ（１５１４、１５１５）を蓄積するバッファである。デコードバッファ切替部１５１０は、デコードバッファ＃１（１５０８）とデコードバッファ＃２（１５０９）内のいずれかのメディアデータ（１５１４、１５１５）をデコーダ１５１１へ渡すための切替を行う部分である。デコーダ１５１１はデコードバッファ切替部１５１０から渡されるメディアデータ１５１６をデコードする部分である。セッション管理部１５０１は、制御部１５０２、セッション管理テーブル１５０４、セッション切替判定部１５０５、およびトラフィック監視部１５２０から構成される。
【００１０】
図６（Ｂ）に、上述のセッション管理テーブル１５０４の例を示す。同図におけるセッション管理テーブル１５０４は、セッション情報と通信路情報、およびコンテンツセット情報とから構成される。セッション情報は、少なくともそのセッションで受信中のコンテンツＩＤ（コンテンツセット情報のＩＤに対応）と、デコードバッファ情報、受信情報、および通信路情報とから構成される。デコードバッファ情報は、上述のデコードバッファ＃１（１５０８）とデコードバッファ＃２（１５０９）内に格納されるメディアデータを管理するための情報であって、例えば、デコードバッファ内のメディアデータのコンテンツ時間範囲、デコードバッファ内データサイズ、ランダムアクセス位置（ＲＡＰ）時刻などである。受信情報はクライアント端末のデータ受信を管理する情報であり、例えば、中継サーバのＩＰアドレス、ポート番号、中継サーバ間の通信プロトコル情報、クライアント端末の受信スループットとその履歴情報などである。通信路情報、コンテンツセット情報は、上述のセッション管理テーブル１０６と同様である。
図３は、通信路＃２（１１７）上で映像配信サービスセッションを開始し、通信路＃３（１１８）へ通信路を切替えるまでの、クライアント端末１１９、中継サーバ１０２、およびコンテンツ配信サーバ１００の各々の処理を時間軸に沿って示した図である。同図で示す処理フローの概要は以下の通りである。
【００１１】
▲１▼クライアント端末１１９は通信路＃２（１１７）を経由して中継サーバ１０２へコンテンツ配信要求を送信し、コンテンツ配信サービスのセッションを確立する。コンテンツ配信サーバ１００は中継サーバ１０２を経由してクライアント端末１１９へコンテンツデータを配信する。
【００１２】
▲２▼クライアント端末１１９が移動し基地局２０３（図２）からの距離が離れることで、同基地局からの電波の受信状況が悪くなり、無線ＬＡＮ網２００、すなわち通信路＃２（１１７）からのデータ受信のスループットが低下する。このクライアント端末１１９間のスループット低下を中継サーバ１０２が検知すると、中継サーバ１０２はクライアント端末１１９への映像データの配信経路を、１ｘＥＶ−ＤＯ網２０１、すなわち通信路＃３（１１８）へ切替えることを決定する。
【００１３】
▲３▼中継サーバ１０２は通信路＃２（１１７）上で確立されていたコンテンツ配信セッションの情報を常に管理しておき、このセッション情報を参照して、通信路＃３（１１８）で新たなコンテンツ配信セッションを確立する。ただしこの新たな配信サービスセッションは、既に通信路＃２（１１７）で確立されている配信サービスセッションと時間的に同期がとれており、かつ同一の内容の映像コンテンツである（コンテンツのビットレートは異なっていてもよい）。
【００１４】
▲４▼クライアント端末１１９では、通信路＃２（１１７）と通信路＃３（１１８）との両方から受信されるコンテンツデータの経過時刻を調べ、両者が時間的に連続して映像が提示されるように、デコードするコンテンツデータを、通信路＃２（１１７）からのコンテンツデータから、通信路＃３（１１８）から受信したコンテンツデータへと切替える。
【００１５】
▲５▼中継サーバ１０２は、クライアント端末１１９において、上記▲４▼の切替が完了すると、通信路＃２（１１７）のコンテンツ配信セッションを終了する。
以下では図３を参照して、上述のフローにおける、配信サーバ１００、中継サーバ１０２、およびクライアント端末１１９の処理の詳細を説明する。
【００１６】
図３において、ユーザの指示等によりクライアント端末１１９においてコンテンツ配信要求イベントが発生すると（Ｓ３００）、クライアント端末１１９はコンテンツセット情報取得要求４０１を中継サーバ１０２に対して送信する（Ｓ３０１）。図４（Ａ）にコンテンツセット情報取得要求４０１のＵＲＬ例（“ｈｔｔｐ：／／ｓｅｒｖｅｒ／ｃｏｎｔｅｎｔｓｅｔ．ｉｎｆｏ”）を示す。中継サーバ１０２は、コンテンツセット情報取得要求４０１を配信サーバ１００へ転送する（Ｓ３０１）。配信サーバ１００はコンテンツセット情報取得要求４０１を受信すると、要求されたコンテンツセット情報４０２を中継サーバ１０２に対して送信する（Ｓ３０２）。
図３において中継サーバ１０２が、上に述べたようなコンテンツセット情報４０２を受信すると（Ｓ３０２）、中継サーバ１０２はこの情報をセッション管理テーブル１０６（図１）に格納する（Ｓ３０３）。その後中継サーバ１０２は、受信したコンテンツセット情報４０２をクライアント端末１１９へ送信する（Ｓ３０２）。クライアント端末１１９では、受信したコンテンツセット情報４０２を、クライアント端末１１９内のセッション管理テーブル１５０４に格納する。セッション管理テーブル１５０４の詳細は後述する。
次にクライアント端末１１９は、クライアント端末自身に関するクライアント情報５００を中継サーバ１０２に送信する（Ｓ３２０）。図５にクライアント情報５００の例を示す。同図の例ではクライアント情報Ｓ３２０として、通信路＃２（図１における１１７）に関する情報５０１、通信路＃３（図１における１１８）に関する情報５０２、および端末能力情報５０３が記述されている。通信路情報５０１、５０２では、通信路のタイプ、最大スループット、ＩＰアドレス、通信路の優先度（値が高いほど優先度が高いものとする）がそれぞれ記述されている。端末能力情報５０３では、端末が対応するコーデックタイプ、最大描画サイズ、ＣＰＵクロック、およびメモリ容量が記述されている。中継サーバ１０２は、クライアント情報５００を受信すると、これを前述のセッション管理テーブル１０６内に格納する（Ｓ３０４）。
【００１７】
クライアント端末１１９は、受信したコンテンツセット情報４０２の中から、例えばユーザの指示動作、あるいは端末が現在確立している通信路のスループット状況に基づいて一つのコンテンツのＵＲＬを選択し、コンテンツ配信要求を中継サーバ１０２へ送信する（Ｓ３０５）。中継サーバ１０２は、コンテンツ配信要求を受信すると（Ｓ３０６）、コンテンツ配信要求処理Ｓ３０８を実行する。コンテンツ配信要求処理Ｓ３０８における機能の概要は以下の二つである。すなわち、（１）クライアント端末１１９が要求したＵＲＬのコンテンツの他に、このコンテンツと同一の内容で、かつ異なる属性（例えばビットレートが異なる等）を持つ複数のコンテンツを配信サーバ１００から受信し続ける。（２）クライアント端末１１９に対しては要求されたコンテンツのみを配信する。
上述の（１）の機能は以下のフローにより実現される。コンテンツ配信処理Ｓ３０８において、制御部１０４は、受信したコンテンツ配信要求のＵＲＬと、セッション管理テーブル１０６（後述する）に格納されたコンテンツセット情報との照合を行うことで、コンテンツ配信要求で指定されたコンテンツの他に、このコンテンツと同一内容で、かつ異なる属性を持つコンテンツのＵＲＬを取得する。そして取得したそれぞれのＵＲＬについてコンテンツ配信要求を配信サーバ１００に対して送信する（Ｓ３０６、Ｓ３０７）。ただし本実施形態では、上述の（１）の機能において、クライアント端末１１９が指定したコンテンツＵＲＬ以外のコンテンツＵＲＬに対しては、必ずしも上記の配信要求を送信する必要はない。本説明においてはＳ３０６とＳ３０７を配信サーバ１００に対して送信するものと仮定する。
【００１８】
配信サーバ１００は、Ｓ３０６、Ｓ３０７の配信要求を受信すると、これらの要求に対応するコンテンツ配信応答を中継サーバ１０２に送信する（Ｓ３０６’、Ｓ３０７’）。中継サーバ１０２は、コンテンツ配信応答（Ｓ３０６’、Ｓ３０７’）を受信すると、クライアント端末１１９からのコンテンツ配信要求（Ｓ３０５）に対応するコンテンツ配信応答（図３の例ではＳ３０６’）を、コンテンツ配信応答（Ｓ３０５’）としてクライアント端末１１９へ送信する。その後配信サーバ１００は中継サーバ１０２に対し、コンテンツ配信要求（Ｓ３０６、Ｓ３０７）に対応したコンテンツデータ１２０、１２１の配信を開始する。中継サーバ１０２は、セッション管理プロセスＳ３１２を起動し、クライアント端末１１９からのコンテンツ配信要求（Ｓ３０５）に対応するコンテンツデータ（図３の例では１２０）をクライアント端末１１９へ送信する。図７に、配信サーバ１００から中継サーバ１０２へ配信されるコンテンツデータ１２０、１２１、及び中継サーバ１０２からクライアント端末へ配信されるコンテンツデータ１２３、１２５のフォーマットの例を示す。図７は、ＩＳＯ／ＩＥＣ１４４９６−１：ＡＭＤ６（通称ＭＰ４）で定められるファイルフォーマットを用いたコンテンツデータの構成図である。同図において、ｕｕｉｄ（７００）は、独自定義データを格納する場所であり、本実施形態では、ｕｕｉｄ（７００）にコンテンツ先頭からの経過時刻を指定する。このｕｕｉｄ内の情報により、コンテンツの途中からデータを配信する場合であっても、受信する側では、受信したコンテンツデータがコンテンツ全体のうち、どれだけ経過した時刻のものであるかの情報を取得することができる。ｕｕｉｄ（７００）は、コンテンツセット情報４０２で記述された複数コンテンツデータ間の時刻同期をとる目的で与えられる。図７において、ｍｏｏｖ（７０１）は先頭ヘッダ情報を格納する場所であり、ｍｄａｔ（７０２、７０４、７０６）はビデオやオーディオなどのメディアデータを格納する場所である。ｍｏｏｆ（７０３）は二つ目以降のヘッダ情報を格納する場所である。本実施形態においては、ｕｕｉｄ（７００）とｍｏｏｖ（７０１）とｍｄａｔ（７０２）をフラグメント＃１（７０７）、それ以降のｍｏｏｆとｍｄａｔの組をフラグメント＃２（７０８）、フラグメント＃３（７０９）とし、フラグメント毎にＴＣＰ／ＩＰ通信により送信するものとする。ただし本発明は、コンテンツの形式や通信プロトコルに依存するものではなく、ＭＰ４ファイル形式ではなく、例えばメディアデータをＲＴＰ（Ｒｅａｌｔｉｍｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）形式でパケット化し、ＵＤＰ／ＩＰ通信により送信することも可能である。ただしコンテンツセット情報Ｓ３０２で記述される複数コンテンツが配信されるときには、上述のｕｕｉｄ（７００）のように、現在送られている配信データがコンテンツにおいてどれだけ時間が経過しているかの情報が何らかの形で付加されている必要がある。
【００１９】
図３の、中継サーバ１０２におけるセッション管理プロセスＳ３１２の詳細を説明する。図８に示すようにセッション管理プロセスＳ３１２では、コンテンツ受信プロセス８００、コンテンツ送信プロセス８０１、クライアント情報管理プロセス８０２、および通信路監視プロセス８０３がそれぞれ独立して動作している。以下では、各プロセスの詳細を説明する。
【００２０】
図９を用いて、コンテンツ受信プロセス８００の詳細を説明する。同プロセスでは、図１におけるサーバ間通信部（１１０、１１１）はコンテンツ配信サーバ１００からのデータ受信処理を行う（Ｓ９０１）。次にサーバ間通信部（１１０、１１１）は受信データの有無を調べ（Ｓ９０２）、受信データの存在を確認すると、受信データをキャッシュ（図１中１１２、１１３）に格納する。そして図１における受信コンテンツ管理部１０５は、キャッシュ（１１２、１１３）に格納された最新の受信コンテンツ情報を解析する（Ｓ９０４）。
ステップＳ９０４における受信コンテンツ情報としては、受信したコンテンツの時間範囲と、受信したコンテンツの平均ビットレート等がある。これらの情報は、図７におけるｍｏｏｖ（７０１）（先頭フラグメントの場合）、またはｍｏｏｆ（７０３、７０５）（２番目以降のフラグメントの場合）内のヘッダ情報に格納されているタイムスタンプと、受信したデータのサイズとから取得できる。
セッション管理部１０３は、ステップＳ９０４において取得した受信コンテンツ情報を、セッション管理テーブル１０６に保持する（Ｓ９０５）。以上のような処理を、制御部１０４からのプロセス終了のメッセージが発生するまで繰り返す（Ｓ９０６）。
以上のように、コンテンツ受信プロセス８００では、受信したデータがキャッシュに格納されるとともに、セッション管理部１０３は受信データのコンテンツ内の経過時刻とデータサイズとを常時取得し、これらの情報をセッション管理テーブル１０６に格納する。
次に図１０を用いて、コンテンツ送信プロセス８０１の詳細を説明する。コンテンツ送信プロセス８０１は、図１におけるコンテンツ送出部１１４において実行される。ステップＳ１００１において、制御部１０４は、キャッシュ内に蓄積されている最も古い送信データのコンテンツ時刻、データサイズ、キャッシュ内のデータアドレス等をセッション管理テーブル１０６から取得し、これらの情報をコンテンツ送出部１１４へ渡す。送信データが存在する場合（Ｓ１００２）、コンテンツ送出部１１４は前述の送信データアドレスとデータサイズとを用いて、キャッシュ＃１（１１２）、又はキャッシュ＃２（１１３）からコンテンツデータを取得し（Ｓ１００３）し、取得したコンテンツデータをクライアント間通信部＃１（１１５）、又はクライアント間通信部＃２（１１６）へ渡す。クライアント間通信部＃１（１１５）、又はクライアント間通信部＃２（１１６）は、通信路＃２（１１７）、又は通信路＃３（１１８）を経由して、クライアント端末１１９へコンテンツデータ（１２３、又は１２５）を送信する（Ｓ１００４）。制御部１０４は、送信したコンテンツデータ（１２３、又は１２５）のコンテンツ時刻範囲と、平均ビットレートとの情報をセッション管理テーブル１０６に保存する（Ｓ１００５）。コンテンツ送信プロセス８０１は、以上のような処理を、制御部１０４からのプロセス終了のメッセージが発生するまで繰り返す（Ｓ１００６）。
【００２１】
以上のように、コンテンツ送信プロセス８０１では、制御部１０４はキャッシュ内に格納されたコンテンツデータ（１２３、又は１２５）を、受信時刻が古い順にクライアント端末１１９へ送信するとともに、セッション管理テーブル１０６における、送信済みコンテンツデータのコンテンツ時刻とデータサイズを逐次更新する。
【００２２】
次に図１３を用いて通信路監視プロセス８０３の詳細を説明する。通信路監視プロセス８０３は、現在クライアント端末１１９にコンテンツを配信している通信網（図３のフローでは通信路＃２（１１７）に相当する）以外の通信路（図３のフローでは通信路＃３（１１８）に相当する）のスループットを監視することで、切替後のスループットを予め把握しておき、現在の通信路から別の通信路へ切替えるときに送信するコンテンツを選択する目的で実行される。
図１３に示すように、通信路監視プロセス８０３において、ある通信路が確立されている場合（Ｓ１３０１）、中継サーバ１０２におけるトラフィック監視部１０７は、定期的にダミーデータをクライアント端末１１９に対して送信する（Ｓ１３０２）。クライアント端末１１９におけるトラフィック監視部１５２０はこのダミーデータを受信すると、受信したダミーデータに対するリポートを中継サーバ１０２に対し送信する（Ｓ１３０３）。このダミーデータリポートについては、１つのダミーデータパケット毎に送信されてもよいし、あるいは複数の受信ダミーデータにつき一つのリポートが送信されてもよい。また通信プロトコルによってもリポートの形態が異なる場合がある。例えばＴＣＰ／ＩＰのようなコネクション型の通信プロトコルでダミーデータが送信される場合には、クライアントは各々のＴＣＰパケットに対してＡＣＫメッセージを中継サーバ１０２に対して返答される。このためＡＣＫメッセージをリポートとすることで、中継サーバ１０２は各々のダミーデータのサイズと送信に要した時間とから、その通信路のスループットを容易に推測可能である。またＵＤＰ／ＩＰのようなコネクションレス型の通信プロトコルでダミーデータが送信される場合には、例えばＲＴＣＰ（ＲｅａｌＴｉｍｅ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）の形式のリポートを用いることができる。ＲＴＣＰのリポート形式により、複数のダミーデータパケットの受信状態に関する情報を中継サーバ１０２に対して定期的に送信する。ＲＴＣＰの詳細説明は省略する。
【００２３】
図１３のステップＳ１３０４では、中継サーバ１０２のトラフィック監視部１０７において、上述のステップＳ１３０３で受信したクライアントからのダミーデータリポートを基に、クライアント端末１１９におけるダミーデータの受信スループットを計算する。計算されたスループット値は、ステップＳ１３０５においてセッション管理テーブル１０６に記録される。またクライアント端末１１９のトラフィック監視部１５２０においても上述と同様に受信スループットを計算し、これをセッション管理テーブル１５０４に記録する。以上のような処理を、制御部１０４からのプロセス終了のメッセージが発生するまで繰り返す（Ｓ１３０６）。以上のような処理を、現在コンテンツを送信している通信路以外の通信路全てについて行い、現在の通信路以外の全ての通信路のスループットを常に監視しておく。
【００２４】
次に、図１１と図１２、および図２５を用いてクライアント情報管理プロセス８０２の詳細を説明する。クライアント情報管理プロセス８０２では、制御部１０４は、クライアント端末１１９における受信データの再生状況や、クライアント端末１１９と中継サーバ１０２間におけるデータ通信スループットの監視を行う。
【００２５】
図１１のクライアント管理プロセス８０２において、中継サーバ１０２はクライアント端末から送られる該端末のコンテンツの受信情報に関するクライアントリポート１２２を受信する（Ｓ１１００）。クライアント端末１１９は、クライアントリポート１２２を定期的に中継サーバ１０２へ送信する。図１２にクライアントリポート１２２の例を示す。図１２の例では、クライアントリポート１２２内は、端末の受信状況に関する情報であって、クライアントへのコンテンツ送信に十分なネットワーク速度が実現されているかどうかを推測できる情報である。▲１▼ある時間内に受信したコンテンツのコンテンツ時間、▲２▼デコードバッファの残り量、▲３▼ある区間内のパケットロス率の少なくとも何れか一つ、さらに現在のスループットを推測するため受信スループットの平均値が含まれる。具体的にはリポート区間の開始時刻ＲＳＳＣ、リポート区間の終了時刻ＲＥＳＣ、リポート区間内に受信したコンテンツデータの最古のコンテンツ時刻ＯＲＣＣ、リポート区間内に受信したコンテンツデータの最新のコンテンツ時刻ＬＲＣＣ、リポート区間内に受信したコンテンツデータサイズＲＢ、リポート区間内でコンテンツデータを受信していない時間の総和ＺＳＣ、リポート区間内の最後のコンテンツデータ受信時刻ＬＲＳＣ、デコードバッファの残りのコンテンツ時間ＤＲＣＣ、リポート区間内のパケット損失率ＰＬＲが含まれている。
【００２６】
図１１のステップＳ１１０１では、受信したクライアントリポート１２２内の情報を取得し、セッション管理テーブル１０６を更新する（Ｓ１１０２）。このときに更新されるセッション管理テーブル１０６内の情報は、クライアント端末１１９が受信したデータのコンテンツ時刻や、クライアント端末１１９における受信スループットである。図１２のクライアントリポート１２２の例では、クライアント端末１１９が受信したコンテンツデータのコンテンツ時刻は、前述のＯＲＳＣとＬＲＣＣから取得される。またリポート区間内の平均スループットＡＴＨＲは、図１２に示すようにＡＴＨＲ＝ＲＢ／（ＲＥＳＣ−ＲＳＳＣ−ＺＳＣ）で求められる。
【００２７】
次に図１１のステップＳ１１０２では、セッション切替判定部１０９は更新されたセッション管理テーブル１０６内の情報を用いて、通信路を切替えるか否かの判定処理を行う。図２５を用いて、切替判定処理Ｓ１１０２の詳細を説明する。切替判定処理Ｓ１１０２では、セッション切替判定部１０９は現在の通信路においてコンテンツ配信の継続が可能かどうかを判定する（Ｓ２５０１）。現通信路でコンテンツ配信が継続可能かどうかの判定条件としては、例えば以下のような条件が考えられる。
▲１▼リポート区間の時間長に相当するコンテンツ時間長のデータが受信されていない状態（すなわち（ＬＲＣＣ−ＯＲＣＣ）≦（ＲＥＳＣ−ＲＳＳＣ）×α（但しαは１未満の定数））、がＴ秒以上続く。
▲２▼クライアントにおけるデコードバッファの残りのコンテンツ時間ＤＲＣＣがある閾値β（秒）以下となる。
▲３▼パケット損失率ＰＬＲがある閾値γ％以上となる。
上記の▲１▼〜▲３▼の判定条件のいずれかに該当する場合、現在の通信路のスループットが、そのコンテンツデータを伝送するために必要なビットレートを下回っていると推測される。一方、上記▲１▼〜▲３▼のいずれにも該当しない場合には、現在の通信路でコンテンツ配信が継続可能と推測され、切替不要と判定する（Ｓ２５０４）。
上記の▲１▼〜▲３▼は通信プロトコルによって判定条件を使い分ける必要がある。例えば本実施形態のように、ＴＣＰ／ＩＰのようなコネクション型の通信プロトコルでデータが伝送されている場合には、パケットロス検出時にはロスしたパケットの再送が行われるため、▲３▼の条件は発生しないが、再送処理による遅延が発生するため▲１▼の条件による判定が有効となる。一方、ＵＤＰ／ＩＰのようなコネクションレス型の通信プロトコルでデータが伝送されている場合には再送処理が生じないため、▲１▼ではなく▲３▼の条件による判定が有効である。またＳ２５０１の判定処理においては、上記▲１▼〜▲３▼の他にクライアント端末における受信データのスループットの履歴情報を参照することで、現在の通信路のスループットが将来的に低下するかどうかについても予測し、将来的にコンテンツ配信の継続が可能かどうかを常にチェックする。例えば図２においてクライアント端末１１９が移動し基地局２０３からの距離が離れると、基地局２０３からの電波の受信状況が悪くなり、無線ＬＡＮ網２００からの映像データ受信スループットの低下が続く。このようなスループットの履歴を調べ、現在の通信路によるコンテンツ配信セッションの継続が可能かどうか、および他の通信路によるコンテンツ配信が可能かどうかを予測する。
【００２８】
上述の判定処理Ｓ２５０１において、現在の通信路でコンテンツ配信が継続不可能と推測された場合、セッション切替判定部１０９は他の通信路でコンテンツ配信を継続可能であるかどうかを判定する（Ｓ２５０２）。
Ｓ２５０２の判定処理では、前述の通信路監視プロセス８０３において更新されたセッション管理テーブル１０６内の通信路情報（図６（Ａ）参照）から、他の通信路の現在のスループット履歴情報を取得し、セッション管理テーブル１０６内のコンテンツセット情報（図６（Ａ）、および図４（Ｂ）参照）から、各コンテンツの平均ビットレート情報を参照し、他の通信路の現在のスループットで配信可能と推測されるコンテンツが存在するかどうかを調べる。他の通信路の現スループットで配信可能と推測されるコンテンツが存在する場合には、他の通信路でコンテンツ配信の継続が可能と判定し、切替要と判定する（Ｓ２５０３）。
以上に述べたように、図１１のＳ１１０２では、現在の通信路でコンテンツ配信の継続不能、かつ他の通信路でコンテンツ配信の継続が可能と判断された場合において、切替要と判定し、それ以外には切替不要と判定する。
上述のようにＳ１１０２において切替要と判定された場合には（Ｓ１１０３）、制御部１０４に対し、通信路の切替を要求する（Ｓ１１０４）。切替要求Ｓ１１０４では、切替後の通信路と新しく配信するコンテンツ（コンテンツセット情報４０２内のコンテンツＩＤで指定）を指定する。以上のような処理を、制御部１０４からのプロセス終了のメッセージが発生するまで繰り返す（Ｓ１１０５）。以上に述べたように、図３におけるセッション管理プロセスＳ３１２では、コンテンツ受信プロセス８００、コンテンツ送信プロセス８０１、クライアント情報管理プロセス８０２、および通信路監視プロセス８０３がそれぞれ独立して動作している。コンテンツ受信プロセス８００では、配信サーバ１００からのコンテンツの受信、および受信したコンテンツ情報の管理を行う。コンテンツ送信プロセス８０１では、クライアントへのコンテンツの送信、および送信したコンテンツ情報の管理を行う。クライアント情報管理プロセス８０２では、クライアント端末１１９間のスループットの計測、クライアント端末での再生情報の管理、通信路切替の判定などを行う。通信路監視プロセス８０３では、現在セッションが確立されている通信路以外の通信路のスループットを定期的に計測する。
次に図１６を用いて、図３のクライアント端末１１９におけるコンテンツ受信プロセスＳ３０９の詳細を説明する。
【００２９】
図１６において、中継サーバ間通信部（１５０６、又は１５０７）は、中継サーバ１０２からコンテンツデータ（１２３、又は１２５）を受信する（Ｓ１６０２）。中継サーバ間通信部（１５０６、又は１５０７）は、受信コンテンツデータ（１２３、又は１２５）の存在を確認すると（Ｓ１６０３）、このコンテンツデータを分離部（１５１２、又は１５１３）に渡す。分離部（１５１２、又は１５１３）は、受信コンテンツデータのヘッダ部（図７中のｍｏｏｖ又はｍｏｏｆ）を解析し、コンテンツ情報を取得するとともに、受信コンテンツデータ内のメディアデータ（１５１４、又は１５１５）を分離し（Ｓ１６０４）、このメディアデータをデコードバッファ（１５０８、又は１５０９）へ格納し（Ｓ１６０５）、取得したコンテンツ情報をセッション管理テーブル１５０４へ保持する（Ｓ１６０６）。コンテンツ受信プロセスＳ３０９は、上述の処理を繰り返して行い、制御部１５０２からのプロセス終了の指示があれば（Ｓ１６０７）、コンテンツ受信プロセスＳ３０９を終了する（Ｓ１６０８）。
【００３０】
次に図３における通信路切替決定イベントＳ３１３以降の処理の流れについて詳細を説明する。
図３におけるセッション切替決定イベントＳ３１３は以下に記す要因のいずれかによって発生する。（１）前述のクライアント情報管理プロセス８０２（図１１参照）における切替判定処理Ｓ１１０３によってセッション切替が決定され、ステップＳ１１０４において制御部１０４へセッション切替指示が発行される。（２）クライアント端末１１９において、ユーザの指示動作によってセッション切替が要求される。（３）クライアント端末１１９において、前述のクライアント情報管理プロセス８０２における切替判定処理Ｓ１１０３と同様な判定処理を行うことで通信路の切替を決定し、切替要求を中継サーバ１０２へ送信する。
すなわち、上述の（１）は中継サーバ１０２によって通信路切替が決定されるのに対し、上述の（２）と（３）は、クライアント端末１１９において通信路切替の決定が行われる。本発明の実施形態１では、通信路の切替の決定は、中継サーバ、クライアント端末、のどちらが行ってもよい。
セッション切替決定イベントＳ３１３が発生すると、中継サーバ１０２における制御部１０４はセッション切替プロセスＳ３２０を実行する。図１４を用いてセッション切替プロセスＳ３２０の詳細を説明する。
セッション切替プロセスＳ３２０は、セッション管理テーブル１０６から、切替後の通信路のスループットとコンテンツセット情報とを取得する。そして切替後の通信路スループット以下の最も大きい平均ビットレートであるコンテンツをコンテンツセット情報の中から探索することで、新しいセッションで配信するコンテンツを選択する。また現在のセッションにおいてクライアント端末１１９に送信済みである最新のコンテンツ時刻ＥＴＳを取得する（Ｓ１４０１）。
次にセッション切替プロセスＳ３２０では制御部１０４は、ステップＳ１４０１で選択したコンテンツが既に配信サーバ１００から受信済みであり、かつＳ１４０１で取得したコンテンツ時刻ＥＴＳの時刻に相当するコンテンツデータがキャッシュ（１１２、又は１１３）に存在するかどうかを調べ（Ｓ１４０２）、もしも存在していなければ、そのコンテンツデータの配信要求（コンテンツ時刻ＥＴＳからのデータを指定）を配信サーバ１００に対して送信した後、前述した配信要求処理Ｓ３０８を実行する。配信要求処理Ｓ３０８が完了すると、配信サーバ１００は、指定された時刻からのコンテンツを中継サーバに対して送信し続ける。制御部１０４は前述のコンテンツ受信プロセス８００を起動し、以降同プロセスにおいて配信サーバ１００からコンテンツを受信し続ける。
次にステップＳ１４０４において制御部１０４は、キャッシュ内データの送信開始の際にデータの修正が必要かどうかを判定し、修正が必要な場合にはデータ修正を実行する（Ｓ１４０５）。本実施形態では、配信されるコンテンツは前述のように、図７で示すＭＰ４ファイル形式となっている。従ってキャッシュ内にある、先頭以外のフラグメントがクライアント端末１１９に対して最初に送られるときには、その最初に送られるフラグメントのヘッダ部ｍｏｏｆ（７０３）をｍｏｏｖ（７０１）にフォーマット変換する必要がある。また先頭フラグメントのｕｕｉｄ内に、現フラグメントのコンテンツ時刻を記述する必要がある。以上に述べたように制御部１０４は、キャッシュ内にある、先頭以外のフラグメントを新たにセッション開始時にクライアント端末１１９へ最初に送信するときに、データの修正や追加が必要な場合には、その修正を行う。
【００３１】
図１４の上述のステップにより、クライアント端末１１９へ新たに配信するコンテンツの準備が整うと、中継サーバ１０２はクライアント端末１１９へセッション切替要求を送信し（図３のＳ３１４）、前述のコンテンツ送信プロセス８０１を起動し、新たなコンテンツのクライアント端末１１９への送信を開始する（１２５）。つまりこの時点で２以上の通信網が１の端末に対して接続されていることになる。
そしてクライアント端末１１９においてセッション切替（図３のＳ３１６）が完了して、不要なセッションが終了すると（Ｓ３１８）、クライアント端末１１９からセッション切替完了通知が中継サーバ１０２に送られる（図３のＳ３１７）。図１４で、中継サーバ１０２がセッション切替完了通知Ｓ３１７を受信すると（Ｓ１４０６）、中継サーバ１０２の制御部１０４はセッション切替プロセスＳ３２０を終了する（Ｓ１４０８）。
次に図１５と図１７を用いて、クライアント端末１１９におけるセッション切替プロセスＳ３１６の詳細を説明する。
セッション切替プロセスＳ３１６が実行される時点では、クライアント端末１１９では、図１５における通信路＃２（１１７）と通信路＃３（１１８）上で２つのコンテンツ配信セッションが同時に確立されており、各々の通信路からそれぞれコンテンツデータ１２３とコンテンツデータ１２５とが独立に受信され、このうちのコンテンツデータ１２３がクライアント端末１１９上でデコードされている。また中継サーバ１０２では、前述したセッション切替プロセスＳ３２０（図１４参照）において、クライアント端末１１９へ送信済みのコンテンツデータ１２３のコンテンツ時刻ＥＴＳを、コンテンツデータ１２５の送信開始コンテンツ時刻とするように処理している。このためクライアント端末１１９において独立に受信されるコンテンツデータ１２３と１２５とは、コンテンツ時刻が近い状態にある。
この状態で、セッション切替判定部１５０５はセッション切替時刻決定処理Ｓ１７０１を実行する（図１７参照）。セッション切替時刻決定処理Ｓ１７０１の詳細は後述するが、この処理によりセッションを切替える（すなわちデコードバッファを切替える）コンテンツ時刻ＳＴが決定される。
コンテンツデータ１２３のデコード時刻が前述の切替時刻ＳＴ未満の場合（Ｓ１７０２）、そのままコンテンツデータ１２３のデコードが実行され続ける。
コンテンツデータ１２３のデコード時刻が前述の切替時刻ＳＴ以上となった場合（Ｓ１７０２）、デコードバッファ切替部１５１０において、デコーダ１５１１のデコード対象となるデコードバッファを、デコードバッファ＃１（１５０８）から、デコードバッファ＃２（１５０９）へ切替える（Ｓ１７０３）。このデコードバッファの＃１から＃２への切替の指示は、中継サーバ１０２から受信したセッション切替要求（Ｓ３１４）によるものである。
次にセッション切替プロセスＳ３１６では、デコーダ１５１１の再設定を行う（Ｓ１７０４）。このデコーダ再設定処理としては、例えばビデオデコーダであれば、画像サイズ等のデコーダの初期化情報が新しいコンテンツデータ１２５に合わせて再設定される。
【００３２】
以上のデコードバッファ切替（Ｓ１７０３）、およびデコーダの再設定（Ｓ１７０４）が終了後、クライアント端末１１９は、中継サーバ１０２に対してセッション切替通知Ｓ３１７を送信し（Ｓ１７０５）、セッション切替プロセスＳ３１６を終了する（Ｓ１７０６）。尚、コンテンツ配信の終了決定権は通信プロトコルに依存する。ＴＣＰのように送信側が、相手が受信に成功したかを確認してから次データを送るプロトコルの場合には、片方が終了処理を行えば、自動的に他方でも通信が終了される。一方、ＵＤＰのように送信側が、相手の受信の是非にかかわらず送信し続けるプロトコルの場合には、双方とも終了処理を行う必要がある。
【００３３】
次に図１８と図１９を用いて、セッション切替プロセスＳ３１６における、セッション切替時刻決定処理Ｓ１７０１の詳細を説明する。
クライアント端末１１９上のセッション管理テーブル１５０４には、図６で示すように、デコードバッファ＃１（１５０８）とデコードバッファ＃２（１５０９）に格納されている受信コンテンツデータのコンテンツ時間範囲が記述され、常に更新されている。ここでデコードバッファ＃１内のコンテンツデータの最小コンテンツ時刻をＤＴＳ（１）、最大コンテンツ時刻をＤＴＥ（１）、デコードバッファ＃２内のコンテンツデータの最小コンテンツ時刻をＤＴＳ（２）、最大コンテンツ時刻をＤＴＥ（２）と記す。
セッション切替時刻決定処理Ｓ１７０１では、セッション管理テーブル１５０４から、最新のＤＴＳ（１）、ＤＴＥ（１）、ＤＴＳ（２）、ＤＴＥ（２）を取得する（Ｓ１８０１）。
そしてデコードバッファ＃２内のコンテンツデータの中で、ＤＴＳ（１）以上であり、かつランダムアクセス位置ＲＡＰであるコンテンツ時刻を探索する（Ｓ１８０２）。このようなＲＡＰがデコードバッファ＃２内に現れるまで、前述のステップＳ１８０１を繰り返す。
Ｓ１８０２の条件を満たすＲＡＰが探索されると、この時刻を前述のセッション切替時刻ＳＴに決定し（Ｓ１８０３）、セッション切替時刻決定処理Ｓ１７０１を終了する（Ｓ１８０４）。
【００３４】
図１９は、図１８で述べたセッション切替判定処理Ｓ１７０１をわかり易く示した模式図である。
図１９の▲１▼の状態では、デコードバッファ＃１内には、コンテンツ時刻が１６から２３までのメディアデータが格納されている。デコードバッファ＃２内にはメディアデータは存在しない。従って▲１▼の状態では、図１８のステップＳ１８０２において、該当するＲＡＰは存在せず、Ｓ１８０１が再び実行される。
そして図１９の▲２▼の状態では、デコードバッファ＃１内には、コンテンツ時刻が１８から２３までのメディアデータが格納されている。デコードバッファ＃２内には、コンテンツ時刻が２０から２２までのメディアデータが格納されているが、その中にＲＡＰが存在しない。このため、▲２▼の状態では、図１８のステップＳ１８０２において、該当するＲＡＰは存在せず、Ｓ１８０１が再び実行される。そして図１９の▲３▼の状態では、デコードバッファ＃１内には、コンテンツ時刻が２０から２４までのメディアデータが格納されている。デコードバッファ＃２内には、コンテンツ時刻が２０から２５までのメディアデータが格納されているが、その中に、ＤＴＳ（１）＝２０よりも大きいＲＡＰ＝２３が存在する。このため▲３▼の状態では、図１８のステップＳ１８０２において、該当するＲＡＰ＝２３が存在するため、Ｓ１８０３が実行され、セッション切替時刻＝２３と決定される。すなわちデコーダ１５１１では、コンテンツ時刻２３秒直前まではデコーダバッファ＃１内のメディアデータをデコードするが、２３秒目以降はデコードバッファ＃２内のメディアデータをデコードする。
【００３５】
図３において、以上で述べたようにセッション切替プロセスＳ３２０が起動し、クライアント端末１１９におけるセッション切替Ｓ３１６、及び不要セッションＳ３１８が完了し、中継サーバ１０２におけるセッション切替プロセスＳ３２０が終了した後は、既に起動している、前述のセッション管理プロセスＳ３１２による通常の配信状態に戻る。すなわち配信サーバ１００からのコンテンツ受信（Ｓ８００）とクライアント端末１１９へのコンテンツ送信（Ｓ８０１）、クライアント端末１１９の現在状況管理（Ｓ８０２）、および全通信路のスループット監視（Ｓ８０３）が継続して行われる状態となる。
上述のように、本発明の実施形態１によるマルチメディア通信システムでは、通信路の切替の際に、中継サーバとクライアント端末との間に、同一内容であり、かつビットレート等のコンテンツ属性が異なる二つのコンテンツの配信セッションを同時に確立する。そしてクライアント端末は、これらのセッションにおいて受信される二つのコンテンツデータのコンテンツ時刻を取得し、極力中断が発生しないようにタイミングを決めて切替を行う。従って、従来の通信網切替時における配信サービスの継続方法では一時的に配信サービスが中断されるのに対し、本実施形態ではこの一時的中断を極力少なくして、配信サービスを継続することが可能となる。また通信路の切替の際には、切替後の通信路に適したビットレートのコンテンツを配信するため、切替後の通信路のスループットが切替前の通信路のスループットと異なる場合であっても、同一の内容のコンテンツ配信サービスを継続することが可能である。
【００３６】
本発明の実施形態２は、実施形態１の変形例として、クライアント端末１１９が中継サーバ１０２の機能を備えるコンテンツ配信システムである。
図２０に、本発明の実施形態２によるクライアント端末２０００の構成を示す。サーバ間通信部２００６と２００７は、それぞれ通信路＃２（１１７）、通信路＃３（１１８）を介して配信サーバ１００とのデータ送受信を行う部分である。分離部２００８、２００９、デコードバッファ２０１０、２０１１、デコードバッファ切替部２０１２、デコーダ２０１３は実施形態１におけるクライアント端末１１９の構成（図１５）と同様である。セッション管理部２００１は、制御部２００２、セッション管理テーブル１５０４、セッション切替判定部２００４、およびトラフィック監視部２００５から構成される。
また図２１にクライアント端末２０００と配信サーバ１００の処理フローを示す。
【００３７】
図２１において、ユーザの指示等によりクライアント端末２０００においてコンテンツ配信要求イベントが発生すると（Ｓ２１０５）、クライアント端末２０００はコンテンツセット情報取得要求４０１を配信サーバ１００に対して送信する（Ｓ２１１０）。コンテンツセット情報取得要求４０１の例は、前述（図４）と同様である。配信サーバ１００はコンテンツセット情報取得要求４０１を受信すると、要求されたコンテンツセット情報４０２をクライアント端末２０００に対して送信する（Ｓ２１１１）。コンテンツセット情報の例は、前述（図４）と同様である。
【００３８】
図２１においてクライアント端末２０００が、上に述べたようなコンテンツセット情報４０２を受信すると（Ｓ２１１１）、クライアント端末２０００はこの情報をセッション管理テーブル１５０４に格納する（Ｓ２１１２）。クライアント端末２０００におけるセッション管理テーブル１５０４は、実施形態１のクライアント端末１１９におけるセッション管理テーブル１５０４と同様である。
図２１においてクライアント端末２０００は、受信したコンテンツセット情報４０２の中から、例えばユーザの指示動作、あるいは端末が現在確立している通信路のスループット状況に基づいて一つのコンテンツのＵＲＬを選択し、コンテンツ配信要求を配信サーバ１００へ送信する（Ｓ３０６）。配信サーバ１００は、コンテンツ配信要求を受信すると、コンテンツ配信要求応答をクライアント端末２０００へ送信する（Ｓ３０６’）。実施形態１のコンテンツ配信システムにおける図３のフローでは、前に述べたコンテンツ配信要求処理Ｓ３０８において複数のコンテンツ配信要求を配信サーバに送信したが、実施形態２においても実施形態１におけるＳ３０８同様に複数のコンテンツ配信を要求することが可能である。ただし図２１の例では、一つのコンテンツ配信要求Ｓ３０６のみを送信することとする。
【００３９】
その後配信サーバ１００はクライアント端末２０００に対し、コンテンツ配信要求（Ｓ３０６）に対応したコンテンツデータ＃１（１２３）の配信を開始する。クライアント端末２０００は、セッション管理プロセスＳ２１００を起動する。配信サーバ１００からクライアント端末へ配信されるコンテンツデータ１２３のフォーマット例は、実施形態１における図７と同様である。
図２２、および図２３を用いて、上述のクライアント端末２０００におけるセッション管理プロセスＳ２１００の詳細を説明する。図２２に示すようにセッション管理プロセスＳ２１００では、コンテンツ受信プロセス２２０１と、通信路監視プロセス２２０２がそれぞれ独立して動作している。以下では、各プロセスの詳細を説明する。
図２３を用いて、クライアント端末２０００におけるコンテンツ受信プロセスＳ２１００の詳細を説明する。同プロセスは、実施形態１におけるクライアント端末１１９のコンテンツ受信プロセスＳ３０９と、中継サーバ１０２におけるセッション切替判定処理Ｓ１１０２とを合わせた処理が行われる。
図２３において、サーバ間通信部（２００６、又は２００７）は、配信サーバ１００からコンテンツデータ（１２３、又は１２５）を受信する（Ｓ２３０１）。サーバ間通信部（２００６、又は２００７）は、受信コンテンツデータ（１２３、又は１２５）の存在を確認すると（Ｓ２３０２）、このコンテンツデータを分離部（２００８、又は２００９）に渡す。分離部（２００８、又は２００９）は、受信コンテンツデータのヘッダ部（図７中のｍｏｏｖ又はｍｏｏｆ）を解析し、コンテンツ情報を取得するとともに、受信コンテンツデータ内のメディアデータ（１５１４、又は１５１５）を分離し（Ｓ２３０２）、このメディアデータをデコードバッファ（２０１０、又は２０１１）へ格納し（Ｓ２３０３）、取得したコンテンツ情報をセッション管理テーブル１５０４へ保持する（Ｓ２３０４）。そしてＳ２３０５において、通信路切替の判定処理を行う。この通信路切替判定処理Ｓ２３０５は、実施形態１の中継サーバ１０２における通信路切替判定処理Ｓ１１０２と同様である。コンテンツ受信プロセス２２０１は、上述の処理を繰り返して行い、制御部２００２からのプロセス終了の指示があれば（Ｓ２３０６）、コンテンツ受信プロセス２２０１を終了する（Ｓ２３０７）。
【００４０】
図２２における通信路監視プロセス２２０２では、現在コンテンツ配信セッションを確立している通信路（図２１の例では通信路＃２）以外の通信路（図２１の例では通信路＃３）を経由して、配信サーバ１００から定期的にある特定のサイズのダミーデータを受信する。そしてこの受信スループットを測定し、セッション管理テーブル１５０４に記録することで、通信路＃３の現在のスループットとその履歴を常に監視しておく。この通信路監視プロセス２２０２は、実施形態１における通信路監視プロセス８０３と同様に、現在の通信路から別の通信路へ切替えるときに要求するコンテンツを選択する目的で実行される。
次に図２１における通信路切替決定イベントＳ３１３以降の処理の流れについて詳細を説明する。
【００４１】
図２１におけるセッション切替決定イベントＳ３１３は以下に記す要因のいずれかによって発生する。（１）クライアント端末２０００において、ユーザの指示動作によってセッション切替が要求される。（２）クライアント端末２０００において、前述のコンテンツ受信プロセス２２０１における切替判定処理Ｓ２３０５において通信路の切替が決定される。すなわち、上述の（１）と（２）とも、クライアント端末２０００において通信路切替の決定が行われる点で、実施形態２は実施形態１と異なる。
図２１においてセッション切替決定イベントＳ３１３が発生すると、クライアント端末２０００における制御部２００２はセッション切替プロセスＳ２１０１を実行する。セッション切替プロセスＳ２１０１は、実施形態１の中継サーバ１０２におけるセッション切替プロセスＳ３２０と、クライアント端末１１９におけるセッション切替プロセスＳ３１６とを合わせた機能が実行される。図２４を用いてセッション切替プロセスＳ２１０１の詳細を説明する。
セッション切替プロセスＳ２１０１は、セッション管理テーブル１５０４から、切替後の通信路のスループットとコンテンツセット情報とを取得する。そして切替後の通信路スループット以下の最も大きい平均ビットレートであるコンテンツをコンテンツセット情報の中から探索することで、新しいセッションで配信するコンテンツを選択する。また現在のセッションにおいてクライアント端末２０００で受信済みである最新のコンテンツ時刻ＥＴＳを取得する（Ｓ２４０１）。
次にセッション切替プロセスＳ２１０１では、ステップＳ２４０１で選択したコンテンツデータ（本説明ではコンテンツデータ＃２（１２５）が選択されたものとする）が既に配信サーバ１００から受信済みであり、かつＳ２４０１で取得したコンテンツ時刻ＥＴＳの時刻に相当するメディアデータ（１５１４、又は１５１５）がデコードバッファ（２０１０、又は２０１１）に存在するかどうかを調べ（Ｓ２４０２）、もしも存在していなければ、そのコンテンツデータ＃２の配信要求（コンテンツ時刻ＥＴＳからのデータを指定）を配信サーバ１００に対して送信（図２１におけるＳ３０７）した後、配信サーバ１００から配信要求応答を受信する（Ｓ３０７’）。その後、前述のコンテンツ受信プロセス（２２０１）が起動され、コンテンツデータ＃２（１２５）の受信を開始する。
次にセッション切替プロセスＳ２１０１では、セッション切替時刻決定処理Ｓ２４０３が実行され、セッションを切替えるコンテンツ時刻ＳＴが決定される。セッション切替時刻決定処理Ｓ２４０３の処理内容は、実施形態１のクライアント端末２０００におけるセッション切替時刻決定処理Ｓ１７０１（図１８）と同様である。
【００４２】
メディアデータ＃１（１５１４）のデコード時刻が前述の切替時刻ＳＴ未満の場合（Ｓ２４０５）、そのままメディアデータ＃１（１５１４）のデコードが実行され続ける。
メディアデータ＃１（１５１４）のデコード時刻が前述の切替時刻ＳＴ以上となった場合（Ｓ２４０５）、デコードバッファ切替部２０１２において、デコーダ２０１３のデコード対象となるデコードバッファを、デコードバッファ＃１（２０１０）から、デコードバッファ＃２（２０１１）へ切替える（Ｓ２４０６）。次にセッション切替プロセスＳ２１０１では、デコーダ２０１３の再設定を行う（Ｓ２４０７）。このデコーダ再設定処理Ｓ２４０７は、実施形態１におけるデコーダ再設定処理Ｓ１７０４と同様である。その後、セッション切替プロセスＳ２１０１を終了する（Ｓ２４０８）。
以上に述べたように、図２１においてセッション切替プロセスＳ２１０１が完了すると、クライアント端末２０００で切替前の不要な配信セッションが終了する（Ｓ２１１３）。その後は、前述のセッション管理プロセスＳ２１００による通常のコンテンツデータ＃２（１２５）の受信状態に戻る。
上述のように、本発明の実施形態２によるマルチメディア通信システムでは、通信路の切替の際に、クライアント端末と配信サーバの間に、同一内容であり、かつビットレート等のコンテンツ属性が異なる二つのコンテンツの配信セッションを同時に確立する。そしてクライアント端末は、これらのセッションにおいて受信される二つのコンテンツデータのコンテンツ時刻を取得し、極力中断が発生しないようにタイミングを決めて切替を行う。従って、従来の通信網切替時における配信サービスの継続方法では一時的に配信サービスが中断されるのに対し、本実施形態ではこの一時的中断を極力少なくして、配信サービスを継続することが可能となる。また通信路の切替の際には、切替後の通信路に適したビットレートのコンテンツを配信するため、切替後の通信路のスループットが切替前の通信路のスループットと異なる場合であっても、同一の内容のコンテンツ配信サービスを継続することが可能である。
尚、本願では図１の無線ＬＡＮとｅｖ―ＤＯの組み合わせを開示したが、Ｗ−ＣＤＭＡ網やＰＨＳ通信網など、他の携帯通信網にも本願は適用でき、無線ＬＡＮの代替としては、ＢｌｕｅｔｏｏｔｈやＵＷＢ（Ｕｌｔｒａ Ｗｉｄｅ Ｂａｎｄ）などが考えられる。
【００４３】
【発明の効果】
以上のように、本発明のコンテンツ配信システムによれば、通信の途中であっても、映像コンテンツなどのリアルタイム性の要求が高いコンテンツ配信サービスであっても、一時的に映像や音が中断することなく、通信網を切替えて、ユーザはコンテンツ配信サービスを継続的に受けることが可能である。
また本発明では、同一内容であり、かつ複数のビットレートであるコンテンツのＵＲＬに対して配信セッションを確立するので、それぞれの通信網における現在のスループットに応じたビットレートのコンテンツを適時選択することが可能である。このため本発明によれば、切替前と切替後の通信網のスループットが大きく異なるような場合であっても、切替後の通信網に応じたコンテンツ配信サービスを継続することが可能である。
以上に述べたように本発明によれば、特性が異なる複数の通信網や、通信速度の変動が激しい通信網においても、リアルタイム性の要求の高いコンテンツ配信サービスを、一時的な中断なく、継続的に提供することが可能である。従って現在広く普及している携帯端末を利用することで、ユーザに対して利便性の高いサービスを提供することが可能である。
【図面の簡単な説明】
【図１】本発明の実施形態１によるコンテンツ配信システムの中継サーバの構成例を示すブロック図。
【図２】本発明の実施形態１にコンテンツ配信システムのネットワーク構成例を示す図。
【図３】本発明の実施形態１によるコンテンツ配信システムの処理フローの例を示す図。
【図４】本発明の実施形態１によるコンテンツ配信システムのコンテンツセット要求、およびコンテンツセット情報の例を示す図。
【図５】本発明の実施形態１によるコンテンツ配信システムのクライアント情報の例を示す図。
【図６】本発明の実施形態１によるコンテンツ配信システムのクライアント端末と中継サーバにおけるセッション管理テーブルの例を示す図。
【図７】本発明の実施形態１によるコンテンツ配信システムにおける、コンテンツデータのフォーマットの例を示す図。
【図８】本発明の実施形態１によるコンテンツ配信システムにおける、中継サーバのセッション管理プロセスの構成例を示す図。
【図９】本発明の実施形態１によるコンテンツ配信システムにおける、中継サーバのコンテンツ受信プロセスの例を示すフローチャート。
【図１０】本発明の実施形態１によるコンテンツ配信システムにおける、中継サーバのコンテンツ送信プロセスの例を示すフローチャート。
【図１１】本発明の実施形態１によるコンテンツ配信システムにおける、中継サーバのクライアント情報管理プロセスの例を示すフローチャート。
【図１２】本発明の実施形態１によるコンテンツ配信システムにおける、クライアントリポートの例を示す図。
【図１３】本発明の実施形態１によるコンテンツ配信システムにおける、中継サーバの通信路監視プロセスの例を示すフローチャート。
【図１４】本発明の実施形態１によるコンテンツ配信システムにおける、中継サーバのセッション切替プロセスの例を示すフローチャート。
【図１５】本発明の実施形態１によるコンテンツ配信システムのクライアント端末の構成例を示すブロック図。
【図１６】本発明の実施形態１によるコンテンツ配信システムにおける、クライアント端末のコンテンツ受信プロセスの例を示すフローチャート。
【図１７】本発明の実施形態１によるコンテンツ配信システムにおける、クライアント端末のセッション切替プロセスの例を示すフローチャート。
【図１８】本発明の実施形態１によるコンテンツ配信システムにおける、クライアント端末のセッション切替時刻決定プロセスの例を示すフローチャート。
【図１９】本発明の実施形態１によるコンテンツ配信システムにおける、クライアント端末のセッション切替時刻決定プロセスの詳細な例を示す図。
【図２０】本発明の実施形態２によるコンテンツ配信システムのクライアント端末の構成例を示すブロック図。
【図２１】本発明の実施形態２によるコンテンツ配信システムの処理フローの例を示す図。
【図２２】本発明の実施形態２によるコンテンツ配信システムにおける、クライアント端末のセッション管理プロセスの構成例を示す図。
【図２３】本発明の実施形態２によるコンテンツ配信システムにおける、クライアント端末のコンテンツ受信プロセスの例を示すフローチャート。
【図２４】本発明の実施形態２によるコンテンツ配信システムにおける、クライアント端末のセッション切替プロセスの例を示すフローチャート。
【図２５】本発明の実施形態１によるコンテンツ配信システムにおける、中継サーバのクライアント情報管理プロセスにおける通信路切替判定処理の例を示すフローチャート。
【符号の説明】
１００・・・コンテンツ配信サーバ
１０１、１１７、１１８・・・通信路
１０２・・・中継サーバ
１０４・・・制御部（中継サーバ）
１０６・・・セッション管理テーブル（中継サーバ）
１０７・・・トラフィック監視部（中継サーバ）
１０９・・・セッション切替判定部（中継サーバ）
１１０、１１１・・・サーバ間通信部
１１２、１１３・・・キャッシュ
１１４・・・コンテンツ送出部
１１５、１１６・・・クライアント間通信部
１１９・・・クライアント端末
１２２、１２４・・・クライアントリポート
１２３、１２５・・・コンテンツデータ
４０２・・・コンテンツセット情報
５００・・・クライアント情報
８００・・・コンテンツ受信プロセス（中継サーバ）
８０１・・・コンテンツ送信プロセス（中継サーバ）
８０２・・・クライアント情報管理プロセス（中継サーバ）
８０３・・・通信路監視プロセス（中継サーバ）
１５０２・・・制御部（クライアント端末）
１５０４・・・セッション管理テーブル（クライアント端末）
１５０５・・・セッション切替判定部（クライアント端末）
１５２０・・・トラフィック監視部（クライアント端末）
１５０６、１５０７・・・中継サーバ間通信部
１５０８、１５０９・・・デコードバッファ
１５１０・・・デコードバッファ切替部
１５１１・・・デコーダ
１５１２、１５１３・・・分離部
１５１４、１５１５、１５１６・・・メディアデータ
Ｓ３１２・・・セッション管理プロセス（中継サーバ）
Ｓ３２０・・・セッション切替プロセス（中継サーバ）
Ｓ１７０１・・・セッション切替時刻判定プロセス（中継サーバ）。

Claims (13)

1. １のクライアント端末に２以上の通信路で接続されるサーバであって、上記クライアント端末からの情報を受け取る通信部と、
   上記通信路を介してのコンテンツ配信の開始・終了を制御するセッション管理部とを有し、
   上記セッション管理部は、上記２以上の通信網に同時にコンテンツを配信し、上記通信部を介して受信したクライアント端末からの上記２以上の通信網の切替完了通知に基づいて上記２以上の通信網の何れかを介してのコンテンツ配信の終了を制御することを特徴とするコンテンツ配信サーバ。
2. 上記セッション管理部は、上記通信部を介して受信した、上記端末からのコンテンツの受信状況に関する情報から端末の受信状況を監視するトラフィック監視部と、該トラフィック監視部からの情報に基づいて上記２以上の通信網へのコンテンツ配信の開始を決定するセッション切り替え判定部とを有することを特徴とする請求項１記載のコンテンツ配信サーバ。
3. 上記コンテンツの受信状況に関する情報は、前記端末において所定時間内に受信したコンテンツのコンテンツ時間、該端末のバッファのデータ残量、所定区間内のパケットロス率の少なくとも何れか１つを含むことを特徴とする請求項２記載のコンテンツ配信サーバ。
4. 上記セッション管理部は、上記受信部を介して上記端末からコンテンツの切り換え要求を受信し、該要求に基づいて上記２以上の通信網へのコンテンツの配信を開始することを特徴とする請求項１記載のコンテンツ配信サーバ。
5. 上記２以上のコンテンツは互いに同期づけのための属性付けがなされており、上記セッション管理部は、上記２通信路にコンテンツの際には上記属性情報に基づいて上記各通信網に配信されるコンテンツ間の同期をとることを特徴とする、請求項１乃至４の何れかに記載のコンテンツ配信サーバ。
6. 前記セッション管理部は、記録される前記コンテンツの属性情報を基に所定のコンテンツに関連づけられた該コンテンツとコンテンツレートが異なるコンテンツを接続されるサーバから取得することを特徴とする請求項１乃至５の何れかに記載のコンテンツ配信サーバ。
7. トラフィック監視部は、前記コンテンツの受信状況に関する情報作成のためダミーデータを、上記通信部を介して出力することを特徴とする請求項２又は３に記載のコンテンツ配信サーバ。
8. 接続されるコンテンツ配信サーバとの間に同時に２以上の通信網を張ることができる通信部と、
   上記２以上の通信網を管理するセッション制御部と、
   上記通信網から受信したコンテンツデータをデコードするデコーダと、
   前記セッション制御部は、
   コンテンツ受信している上記２以上の通信網の何れを利用するかを決定し、
   上記決定結果に基づいて上記何れかの通信網のコンテンツ受信を終了して、上記通信網の切替を行うことを特徴とする端末装置。
9. 前記セッション管理部は、前記２以上の通信網のスループットの情報に基づいて、前記通信網切替を前記配信サーバに対して要求することを特徴とする請求項８記載の端末装置。
10. 前記セッション管理部は、通信中の通信網のスループットの情報に基づいて、新たな通信網によるセッションの確立を前記配信サーバに対して要求し、上記２以上の通信網からのコンテンツ配信を受けることを特徴とする請求項８又は９に記載の端末装置。
11. 上記セッション管理部は、上記コンテンツを受信している２以上の通信網の現在受信しているコンテンツデータのコンテンツ時刻と現在デコードしているデコード時刻の情報管理するセッション管理テーブルを有し、上記通信網切り換えのコンテンツ再生の不連続時間を小さくすることを特徴とする請求項８乃至１０に記載の端末装置。
12. 上記セッション管理部は、
    前記配信サーバから送られるデータに基づき、上記各通信網について、端末において所定時間内に受信したコンテンツのコンテンツ時間、該端末のバッファのデータ残量、所定区間内のパケットロス率の少なくとも何れか１つを含む情報を上記配信サーバへ上記受信部を介して送信することを特徴とする請求項８乃至１１に記載の端末装置。
13. ユーザからの入力を受けつける入力部をさらに有し、
    該入力部を介してのユーザ指示に応じて現在通信中の通信網に加えて新たな通信網によるセッションを確立し、上記２以上の通信網からの受信を開始することを特徴とする請求項８乃至１２に記載の端末装置。

Images