(57)【要約】【課題】ＱｏＳが保証されたストリーミングにおいて、ザッピング時のストリーム切り替え速度を向上させ、実使用ネットワークリソースは最低限に抑える。【解決手段】中継手段１０３は、ザッピング先予測手段１１１に対して、端末１０７より受信した視聴希望ストリームに必要な帯域幅の確保を要求する帯域確保要求を行う。ザッピング先予測手段１１１は、受信した視聴希望ストリームが、前回の要求成功時に記録した予測ストリームと同じものかどうかを判定し、同じであれば、帯域管理手段１０９に対して、前回予測時に確保したストリームのうち今回視聴希望に該当しないストリーム分の帯域解放要求と、端末１０７が現在ストリーム受信に使用している帯域の帯域解放要求と、ユーザの嗜好情報によって次にザッピングすることが予測されるストリームを新たな予測ストリームとしてその予測ストリームに必要な帯域の帯域確保要求を行う。【選択図】図１
2008182426.tif 000002
【特許請求の範囲】
【請求項１】
配信サーバと端末とを含む、映像音声ストリームの配信システムにおいて、
前記端末が受信中もしくは受信選択がされた映像音声ストリームの次に受信選択される映像音声ストリームを予測するザッピング先予測ステップと、
前記端末が受信中もしくは受信選択がされた映像音声ストリームに加え、前記ザッピング先予測ステップによって予測された映像音声ストリームの配信に必要なリソースのみ、もしくはフィルタリング設定のみ、もしくはその両方のみを、前記ユーザによる次の映像音声ストリームの選択が行われる前にあらかじめ確保するリソース確保ステップと
を備え、
前記予測された映像音声ストリームについては、次のザッピング時に選択された映像音声ストリームに一致するまでは前記端末に配信しないこと
を特徴とする、映像音声ストリームのリソース確保方法。
【請求項２】
前記ザッピング先予測ステップは、ユーザの嗜好情報によって、次にザッピングすることが予測される映像音声ストリームを次に受信選択される映像音声ストリームとして予測する、請求項１に記載の、映像音声ストリームのリソース確保方法。
【請求項３】
配信サーバと端末とを含む、映像音声ストリームの配信システムにおいて、
中継手段から、前記端末より受信した視聴希望ストリームに必要な帯域幅の確保を要求する帯域確保要求を受け取ると、前記視聴希望ストリームが、前回の要求成功時に記録した予測ストリームと同じものかどうかを判定するステップと、
前記判定の結果、同じであれば、帯域管理手段に対して、前回予測時に確保したストリームのうち今回視聴希望に該当しないストリーム分の帯域解放要求と、前記端末が現在ストリーム受信に使用している帯域の帯域解放要求と、次にザッピングすることが予測されるストリームを新たな予測ストリームとしてその予測ストリームに必要な帯域の帯域確保要求を行うステップと、
前記判定の結果、同じでなければ、前記帯域管理手段に対して、前回予測時に確保した予測ストリーム分の帯域解放要求と、現在前記端末がストリーム受信に使用している帯域の帯域解放要求と、前記視聴希望ストリームに必要な帯域確保要求と、次にザッピングすることが予測されるストリームを新たな予測ストリームとしてその予測ストリームに必要な帯域の帯域確保要求を行うステップと、
前記帯域管理手段から、前記視聴希望ストリームの帯域確保要求受付結果を受け取り、前記中継手段に通知するステップと、
を有する、映像音声ストリームのリソース確保方法。
【請求項４】
配信サーバと端末とを含む、映像音声ストリームの配信システムにおいて、
前記端末が受信中もしくは受信選択がされた映像音声ストリームの次に受信選択される映像音声ストリームを予測するザッピング先予測手段
を備え、
前記予測された映像音声ストリームについては、次のザッピング時に選択された映像音声ストリームに一致するまでは前記端末に配信しないこと
を特徴とする、映像音声ストリームの中継装置。
【請求項５】
前記ザッピング先予測ステップは、ユーザの嗜好情報によって、次にザッピングすることが予測される映像音声ストリームを次に受信選択される映像音声ストリームとして予測する、請求項４に記載の、映像音声ストリームの中継装置。
【請求項６】
配信サーバと端末とを含む、映像音声ストリームの配信システムにおいて、
前記端末が受信中もしくは受信選択がされた映像音声ストリームの次に受信選択される映像音声ストリームを予測するザッピング先予測手段
を備え、
前記予測された映像音声ストリームについては、次のザッピング時に選択された映像音声ストリームに一致するまでは前記端末に配信しないこと
を特徴とする、リソース管理装置。
【請求項７】
前記ザッピング先予測ステップは、ユーザの嗜好情報によって、次にザッピングすることが予測される映像音声ストリームを次に受信選択される映像音声ストリームとして予測する、請求項５に記載のリソース管理装置。
【請求項８】
配信サーバと端末とを含む、映像音声ストリームの配信システムにおいて、
該端末が受信中もしくは受信選択がされた映像音声ストリームの次に受信選択される映像音声ストリームを予測するザッピング先予測手段と、
前記端末が受信中もしくは受信選択がされた映像音声ストリームに加え、前記ザッピング先予測手段によって予測された映像音声ストリームの配信に必要なリソースのみ、もしくはフィルタリング設定のみ、もしくはその両方のみを、前記ユーザによる次の映像音声ストリームの選択が行われる前にあらかじめ確保するリソース確保手段
を備え、
前記予測された映像音声ストリームについては、次のザッピング時に選択された映像音声ストリームに一致するまでは前記端末に配信しないこと
を特徴とする、映像音声ストリームの配信システム。
【請求項９】
前記ザッピング先予測手段は、ユーザの嗜好情報によって、次にザッピングすることが予測される映像音声ストリームを次に受信選択される映像音声ストリームとして予測する、請求項８に記載の、映像音声ストリームの配信システム。
【請求項１０】
請求項１から３のいずれかに記載の映像音声ストリームのリソース確保方法をコンピュータで実行するためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、映像音声ストリーミング配信システムに関し、特に映像音声ストリームの配信に必要なリソース確保方法に関する。
【背景技術】
【０００２】
従来、一般的にユニキャストによる映像音声ストリーミングを実現するシステムにおいて、各ストリームをＴＶのチャネルと捉えて放送型のサービスを実現するには、各ストリームを伝送するための経路上の帯域確保やフィルタリング設定（アクセス制御）は、ザッピング（ＴＶにおけるユーザのリモコン操作によるチャンネル選択の意）を行う際に都度行われていた。
【０００３】
例えば、マルチキャストによって実現されるＩＰＴＶサービスを考えた場合、コアネットワークの帯域は全チャンネルを一度に配信するに足る容量を備えるが、端末と収容局の間の帯域は現在の一般的なサービスでは１００Ｍｂｐステップ以下であり、１本のストリームの消費帯域が６Ｍｂｐステップとして、最大でも１６本しかマルチキャストで端末に届けることはできない。現在普及しているＡＤＳＬ（Ａｓｙｍｍｅｔｒｉｃ  Ｄｉｇｉｔａｌ  Ｓｕｂｓｃｒｉｂｅｒ  Ｌｉｎｅ）方式による実効性能は１０Ｍｂｐステップ前後のものも多く、ストリーム２本を同時に配信ことも困難な場合がある。したがって、このような帯域のミスマッチに対応するためには、収容局内において、端末が視聴選択したストリームのみをユニキャストで端末に届けるようなシステムが現実的である。
【特許文献１】特開２００３−１４３５８７号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
従来技術における問題点は、ある映像音声ストリームを視聴中に、別の映像音声ストリームに切り替えるザッピング視聴の際に、映像音声ストリームを切り替える時間がかかり、ＴＶのようなザッピング性能が出ないことにある。特に、ＱｏＳ（Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ）が保証された映像音声ストリーミングにおいては、ベストエフォートな映像音声ストリーミングに対して、さらに旧視聴映像音声ストリームの帯域解放と新視聴映像音声ストリームの帯域確保の動作が余計にかかり、ザッピング性能がさらに悪化する可能性がある。
【０００５】
図５は、前記従来技術による映像音声ストリーム配信システムの構成例を示す図である。
【０００６】
配信サーバ５０１から、配信経路５０２を経由して中継手段５０３に対してマルチキャストで複数の映像音声ストリームを配信する。端末５０７は、番組情報（図示せず）より視聴したい映像音声ストリームの配信要求を配信経路５０６、帯域制御手段５０５、配信経路５０４を経由して中継手段５０３に伝達する。中継手段５０３は、要求された前記ストリームの帯域情報（図示せず）に従って配信に必要な帯域要求を、制御線５１０を経由して帯域管理手段５０９に対して行う。帯域管理手段５０９は、その要求された帯域を確保可能であれば、制御線５０８を介して帯域制御手段５０５に対してその帯域確保を指示するとともに、制御線５１０を経由して中継手段５０３に帯域確保可能の旨を伝達する。中継手段５０３は、端末５０７からの要求による映像音声ストリームを、配信経路５０４、帯域制御手段５０５、配信経路５０６を経由して端末５０７に対してユニキャストで配信する。
【０００７】
このような構成を採用したシステムは特許文献１に記載されている。特許文献１では、ザッピングの際の高速化を図るため、配信サーバから配信されるマルチキャストでの複数映像音声ストリームのいくつかを次に選択対象となるストリームとして予測し、マルチキャストポイントでフィルタリングしてあらかじめ端末に配信しておき、上位アプリケーションからザッピング指示を受けると、もし予測が当たっていれば、端末内で既に受信している複数の映像音声ストリームから該当映像音声ストリームを選択し再生する。
【０００８】
しかし、特許文献１に記載の方法では、ユーザが視聴している映像音声ストリームに加え、予測された映像音声ストリームについても、マルチキャストポイントと端末間で実際に映像音声ストリームとして流れてしまうため、前記のようにＡＤＳＬを用いる等してマルチキャストポイントと端末間のネットワークリソースが十分にない場合や複数の端末が同じマルチキャストポイントから映像音声ストリームを受信している場合に、ネットワークリソースが枯渇しやすい。例えば、ネットワークのスループットが１０Ｍｂｐステップしかない回線に、６Ｍｂｐステップのストリームは１本しか通らないため、この方法によるザッピングの高速化は実現できない。
【０００９】
本発明の目的は、ＱｏＳが保証されたストリーミングにおいて、ザッピング時のストリーム切り替え速度を向上させ、なおかつ実使用ネットワークリソースは最低限に抑えるリソース確保方法、映像音声ストリームの中継装置、リソース管理装置、映像音声ストリーミング配信システム、およびリソース確保プログラムを提供することにある。
【課題を解決するための手段】
【００１０】
本発明の、映像音声ストリームのリソース確保方法は、
端末が受信中もしくは受信選択がされた映像音声ストリームの次に受信選択される映像音声ストリームを予測するザッピング先予測ステップと、
前記端末が受信中もしくは受信選択がされた映像音声ストリームに加え、前記ザッピング先予測ステップによって予測された映像音声ストリームの配信に必要なリソースのみ、もしくはフィルタリング設定のみ、もしくはその両方のみを、前記ユーザによる次の映像音声ストリームの選択が行われる前にあらかじめ確保するリソース確保ステップと
を備え、
前記予測された映像音声ストリームについては、次のザッピング時に選択された映像音声ストリームに一致するまでは前記端末に配信しないこと
を特徴とする。
【００１１】
本発明は、ストリーミングに仮想のチャンネルが与えられた際に、予測を元に、次にザッピングして視聴される可能性のあるストリーム分の帯域確保とアクセス制御のみを、ザッピング操作に先行して行うことによって、ザッピング時のストリーム切り替え速度を向上させ、なおかつ実使用ネットワークリソースは最低限に抑える。
【発明の効果】
【００１２】
本発明によれば、ユーザがザッピング操作を行う前に既に次の新しいストリーム視聴に必要な帯域確保やアクセス制御が完了しているため、新しいストリーム視聴のための帯域確保の時間短縮が図れ、またユーザがザッピング操作を行う前に既に次の新しいストリーム視聴に必要な帯域確保が可能かどうかを判定済みのため、ザッピング操作時にはザッピングできるかどうかを速やかにユーザに通知できる。
【発明を実施するための最良の形態】
【００１３】
次に、発明を実施するための最良の形態について図面を参照して詳細に説明する。
【００１４】
図１は本発明の一実施形態の映像音声ストリーミング配信システムのブロック図である。
【００１５】
配信サーバ１０１は配信経路１０２を介して中継手段１０３に接続している。中継手段１０３は配信経路１０４を介して帯域制御手段１０５に接続している。帯域制御手段１０５は配信経路１０６を介して端末１０７に接続している。ザッピング先予測手段１１１は制御線１１０を介して中継手段１０３と接続し、また制御線１１２を介して帯域管理手段１０９と接続している。帯域管理手段１０９は制御線１０８を介して帯域制御手段１０５と接続している。
【００１６】
図２は本実施形態の映像音声ストリーミング配信システムの動作を表すフローチャートである。
【００１７】
配信サーバ１０１は、中継手段１０３に対して複数のストリームをマルチキャストで配信する（ステップ２０２）。この際の配信はマルチキャストに代えてユニキャストでもよい。また、中継手段１０３は、他の配信サーバ（図示せず）からも同時にストリームを受信してもよい。
【００１８】
ユーザがリモコン等を用いてあるストリームを選択すると、そのストリームを視聴希望ストリームとして、端末１０７より中継手段１０３に視聴希望ストリームを要求する（ステップ２０３）。要求時にはストリームを識別する情報を付与する。ストリームを識別する情報は、そのストリームをチャンネルとして識別するチャンネル番号を用いたり、そのストリームを受信するためのＵＲＬ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ）やＩＰアドレスを用いてもよい。
【００１９】
中継手段１０３は、ザッピング先予測手段１１１に対して、端末１０７より受信した視聴希望ストリームに必要な帯域幅の確保を要求する帯域確保要求を行う（ステップ２０４）。必要な帯域幅は、中継手段１０３で受信している複数のストリームから、視聴希望ストリームに該当するストリームの平均レート等を用いてもよいし、あらかじめストリーム情報が別途与えられている場合には、その情報を参照して決定してもよい。ザッピング先予測手段１１１は、受信した視聴希望ストリームが、前回の要求成功時に記録した予測ストリームと同じものかどうかを判定する（ステップ２０５）。
【００２０】
ステップ２０５での判定の結果、同じであれば、ザッピング先予測手段１１１は、帯域管理手段１０９に対して、前回予測時に確保したストリームのうち今回視聴希望に該当しないストリーム分の帯域解放要求と、端末１０７が現在ストリーム受信に使用している帯域の帯域解放要求と、ユーザの嗜好情報によって、次にザッピングすることが予測されるストリームを新たな予測ストリームとしてその予測ストリームに必要な帯域の帯域確保要求を行う（ステップ２０６）。ユーザの嗜好情報によるザッピング先予測は以下のように行う。ザッピング先予測手段１１１はユーザの視聴履歴や性別、年齢層、およびキーワードを嗜好情報として保持する。該キーワードとしては、タイトル、ジャンル、出演者名、脚本・監督名、番組情報中の単語、インターネットを用いた通信販売の購買履歴があり、ユーザがあらかじめザッピング先予測手段１１１に登録してもよいし、ザッピング先予測手段１１１が自動で蓄積してもよい。また、それぞれの嗜好情報には重みを付けてもよい。該嗜好情報をもとに中継手段１０３で受信している複数のストリームそれぞれに対してユーザとの嗜好の合致度を算出し、合致度が高いものをザッピング先の候補とする。予測したザッピング先の候補数は、中継手段１０３と端末１０７の間にある、配信経路１０４や１０６、帯域制御手段１０５のスペックによって定めてもよい。すなわち帯域幅にもともと余裕がない配信経路設計の場合には予測したザッピング先の候補を１つに限定し、余裕がある配信経路設計の場合には予測したザッピング先の候補を２や３に設定する等である。
【００２１】
ステップ２０５での判定の結果、同じでなければ、ザッピング先予測手段１１１は、帯域管理手段１０９に対して、前回予測時に確保した予測ストリーム分の帯域解放要求と、現在端末１０７がストリーム受信に使用している帯域の帯域解放要求と、視聴希望ストリームに必要な帯域確保要求と、ユーザの嗜好情報によって次にザッピングすることが予測されるストリームを新たな予測ストリームとしてその予測ストリームに必要な帯域の帯域確保要求を行う（ステップ２０７）。
【００２２】
ステップ２０６およびステップ２０７で同時に行っている各帯域解放要求や各帯域確保要求は手順の一例であり、各要求を個別に順序立てて実施してもよい。また、実施タイミングもそれぞれずらしてよい。例えば、ステップ２０６の例では、ステップ２１０で受付結果を中継手段１０３に通知した後に、予測に外れたストリームの帯域解放要求と新たな予測ストリームの帯域確保要求とを行ってもよいし、また端末１０７が現在受信しているストリームの帯域解放要求はステップ２１０の後やステップ２１１の後やステップ２１２の後や端末１０７が新たなストリームの受信に成功してから（図示せず）行ってもよい。ステップ２０７についても同様である。
【００２３】
帯域管理手段１０９は要求された帯域確保要求または帯域解放要求に応じて帯域制御手段１０５に帯域制御を指示する（ステップ２０８）。この時、帯域確保要求や帯域解放要求に失敗した場合にはステップ２０８では帯域制御手段１０５に対して何も指示しないことにしてもよい。またその場合には、ステップ２０９、ステップ２１０、ステップ２１１、ステップ２１２では、視聴希望ストリームや新旧の予測ストリームに関して、端末１０７からは要求がなかったように振る舞い、端末１０７での現在の受信が途切れないようにしてもよい。その場合でも要求が失敗したことは、ステップ２０９、ステップ２１０、ステップ２１１において通知し、端末１０７に対して失敗したことが伝わるようにしてもよい。
ザッピング先予測手段１１１は、中継手段１０３に対して、視聴希望ストリームの帯域確保要求受付結果を通知する（ステップ２１０）。
【００２４】
中継手段１０３は、端末１０７に対して、視聴希望ストリームの帯域確保要求受付結果を通知する（ステップ２１１）。中継手段１０３は、ステップ２１０の受付結果が成功と通知された場合、要求された視聴希望ストリームを端末１０７にユニキャストで配信する（ステップ２１２）。この時、ユニキャストに代えてマルチキャストで配信してもよい。この際のマルチキャストによる配信は、他の端末（図示せず）が同時に中継手段１０３と接続されている場合に効果がある。すなわち、配信経路１０４や配信経路１０６、帯域制御手段１０５の能力が複数の端末に対してそれぞれユニキャストするのに十分な帯域や性能のない場合に、複数の端末で同じ映像音声ストリームを同時視聴する場合には、その同じ映像音声ストリームをマルチキャストで配信してもよい。
【００２５】
また、帯域管理手段１０９における帯域確保時に、帯域制御手段１０５に十分な空きリソースが無い場合には、予測映像音声ストリーム分の帯域については、仮想的なリソースに対する帯域確保として処理するようにしてもよい。その場合、帯域制御手段１０５で実際に予測映像音声ストリームが次に視聴する映像音声ストリームとして確定した段階で、実ストリームとして配信可能なように、帯域制御手段１０５や帯域管理手段１０９やザッピング先予測手段１１１で、実ストリームとして配信する接続を切り替える処理を含んでもよい。例えば、実ストリームとして確定した際には、ザッピング先予測手段１１１から帯域管理手段１０９に確定を通知し、帯域管理手段１０９は帯域制御手段１０５に切り替え指示を行うようにしてもよい。
【００２６】
なお、上記全てのフローを通じて、帯域確保、帯域解放の際には接続端末のフィルタリング処理（アクセス制御）を伴ってもよい。例えば、帯域制御手段１０５にファイアウォール機能を搭載する場合には、該当ストリームの帯域確保を行う際に、そのストリームを受信する端末と送信する配信サーバ間との通信が可能になるようにパケットフィルタリングを設定してもよい。また、同様に、帯域解放の際には、そのストリームを受信する端末と送信する配信サーバ間との通信が不可能になるようにパケットフィルタリングを設定してもよい。また、フィルタリング処理は帯域確保および帯域解放の前に行われても、同時に行われても、後に行われてもよい。
【００２７】
図３は図２の映像音声ストリーミング配信システムの具体例のブロック図である。
【００２８】
中継装置３０３は、マルチキャストを終端しユニキャストに変換するマルチキャスト終端ユニット３０４と、次に選択されるストリームを予測するザッピング先予測ユニット３１０から構成される。マルチキャスト終端ユニット３０４とザッピング先予測ユニット３１０はプログラムによる実装を示しており、各プログラム間を接続する論理的な通信パス３０９によって通信する。ＩＰＴＶ配信サーバ３０１は、イントラネット３０２を介してマルチキャスト終端ユニット３０４（中継装置３０３内）と接続する。マルチキャスト終端ユニット３０４はイントラネット３０５を介してルータ３０６と接続する。ルータ３０６は、パケット優先制御機能とアクセス制御機能を有するルータであり、パケット優先制御機能は特定パケットの帯域をコントロールする機能を、アクセス制御機能はパケットを流してよいソースやディスティネーションを指定することが可能である。ルータ３０６は公衆電話回線（ＡＤＳＬ）を介してＩＰＴＶ受信端末３０８と接続する。リソース受付制御サーバ３１２は、イントラネット３１３を介してルータ３０６のパケット優先制御機能とアクセス制御機能を制御する。また、イントラネット３１１を介してザッピング先予測ユニット３１０（中継装置３０３内）からルータ制御要求を受け付ける。
【００２９】
図４は、ＩＰＴＶ受信端末３０８を操作するリモコンの一構成例である。
【００３０】
リモコン４０１は電源ボタン４０２とチャンネル逆送りボタン４０３とチャンネル順送りボタン４０４とボリューム減少ボタン４０５とボリューム増加ボタン４０６とチャンネル指定ボタン群４０７から構成される。
【００３１】
チャンネル指定ボタン群４０７の各ボタンには、ＩＰＴＶ配信サーバ３０１より配信されている複数の映像音声ストリームＡ〜Ｌまでが順に割り当てられている。すなわち、チャンネル１には映像音声ストリームＡが、チャンネル２には映像音声ストリームＢが、チャンネル３には映像音声ストリームＣが、チャンネル４には映像音声ストリームＤが、チャンネル５には映像音声ストリームＥが、チャンネル６には映像音声ストリームＦが、チャンネル７には映像音声ストリームＧが、チャンネル８には映像音声ストリームＨが、チャンネル９には映像音声ストリームＩが、チャンネル１０には映像音声ストリームＪが、チャンネル１１には映像音声ストリームＫが、チャンネル１２には映像音声ストリームＬが、それぞれ割り当てられている。
【００３２】
チャンネル逆送りボタン４０３を操作すると、ＴＶのチャンネルに相当する操作として、現在視聴中の映像音声ストリームに対して隣接する、チャンネル番号の小さい映像音声ストリームを再生するよう要求する。すなわち、現在映像音声ストリームＣが視聴中である場合にチャンネル逆送りボタン４０３を押下すると、映像音声ストリームＢが視聴される。この場合、チャンネル指定ボタン群５０７のボタン「２」を操作したのと同じ効果が得られる。
【００３３】
チャンネル順送りボタン４０４を操作すると、ＴＶのチャンネルに相当する操作として、現在視聴中の映像音声ストリームに対して隣接する、チャンネル番号の大きい映像音声ストリームを再生するよう要求する。すなわち現在映像音声ストリームＣが視聴中である場合にチャンネル順送りボタン４０４を押下すると、映像音声ストリームＤが視聴される。この場合、チャンネル指定ボタン群４０７のボタン「４」を操作したのと同じ効果が得られる。
【００３４】
次に、本具体例の動作について説明する。
ＩＰＴＶ配信サーバ３０１は、マルチキャスト終端ユニット３０４に対して、１２本の映像音声ストリームＡ〜Ｌ（図示せず）をマルチキャストで送信中である。また、ザッピング先予測ユニット３１０が保持している嗜好情報をもとに該映像音声ストリームＡ〜Ｌそれぞれに対してユーザとの嗜好の合致度を算出した結果、合致度の高い上位５ストリームは高い順にＡ、Ｂ、Ｃ、Ｄ、Ｅであるものとし、ザッピング先の候補数は２であることとする。そして、現在ＩＰＴＶ受信端末３０８で受信している映像音声ストリームは、映像音声ストリームＤであるものとし、前回リモコン４０１操作時に映像音声ストリームＡとＢが予測され、ＡとＢは帯域確保がなされた状態であることとする。
【００３５】
ユーザがリモコン４０１を操作し、チャンネル指定ボタン群４０７のボタン「１」を押下すると、ＩＰＴＶ受信端末３０８はマルチキャスト終端ユニット３０４に、視聴要求（映像音声ストリームＡ）を送信する。マルチキャスト終端ユニット３０４はザッピング先予測ユニット３１０に前記視聴要求を送信する。
【００３６】
ザッピング先予測ユニット３１０では、前回視聴要求受付時に映像音声ストリームＡを予測映像音声ストリームとし、ルータ３０６を介した配信に必要な帯域確保およびアクセス制御を実施済みである。そこでザッピング先予測ユニット３１０では、再度嗜好の合致度の計算を行い、次の予測映像音声ストリームとして映像音声ストリームＡ以外でユーザの嗜好との合致度が高い映像音声ストリームＢとＣを設定する。次に、ザッピング先予測ユニット３１０は、映像音声ストリームＡ、Ｂ、Ｃを配信するために必要な帯域確保およびアクセス可能設定要求（映像音声ストリームＡとＢは継続、Ｃは新規）と、不要となった映像音声ストリームＤの帯域解放およびアクセス不可能設定要求を行う。
【００３７】
リソース受付制御サーバ３１２では、ザッピング先予測ユニット３１０からの要求に従い、ルータ３０６に、映像音声ストリームＤの帯域解放およびアクセス不可能設定要求を、映像音声ストリームＡ、Ｂ、Ｃの帯域確保（映像音声ストリームＡとＢは継続、Ｃは新規）およびアクセス可能設定要求を行う。ここでは、この要求に対してルータ３０６から要求受付成功が返信されたものとする。そこで、リソース受付制御サーバ３１２はザッピング先予測ユニット３１０に対して要求受付成功を送信する。
【００３８】
ザッピング先予測ユニット３１０では、リソース受付制御サーバ３１２からの要求受付成功を受信したため、リソース受付制御サーバ３１２に要求した新たな視聴中の映像音声ストリームＡおよび映像音声ストリームＡ以外でユーザの嗜好との合致度が高い映像音声ストリームＢとＣをそれぞれ確定し、マルチキャスト終端ユニット３０４に要求受付成功を送信する。
【００３９】
マルチキャスト終端ユニット３０４は、ザッピング先予測ユニット３１０から返信された要求受付成功を受け、現在ルータ３０６を介してＩＰＴＶ受信端末３０８にユニキャストで送信している映像音声ストリームＤを停止し、替わりに映像音声ストリームＡを送信開始する。
【００４０】
ＩＰＴＶ受信端末３０８は新たな映像音声ストリームＡを受信開始し、再生する。
【００４１】
上記具体例におけるザッピング先予測ユニット３１０は、中継装置３０３に替えてリソース受付制御サーバ３１２に含まれていてもよい。この場合、マルチキャスト終端ユニット３０４でＩＰＴＶ受信端末３０８からの前記視聴要求を受信した際に、ザッピング先予測ユニット３１０（リソース受付制御サーバ３１２内）に視聴要求を行なう。ザッピング先予測ユニット３１０は、前記具体例と同様にリソース受付制御サーバ３１２内にある帯域やアクセスの管理ユニット（図示せず）に前記具体例における帯域確保要求およびアクセス設定要求を行う。
【００４２】
また、前記具体例においては、ＩＰＴＶ受信端末が一つの場合について説明したが、複数のＩＰＴＶ受信端末が中継装置３０３に同時に接続していてもよく、この場合のＩＰＴＶ受信端末はＩＰＴＶ受信端末３０８と同様に動作するものとする。また、ルータ３０６は前記の複数のＩＰＴＶ受信端末の視聴要求・応答や映像音声ストリームを同時に制御できるようにしてもよい。
【００４３】
また、ＩＰＴＶ配信サーバ３０１からマルチキャストで送信される複数の映像音声ストリームを複数の中継装置で同時に受信し、各中継装置にはそれぞれ１つ以上のＩＰＴＶ受信端末が接続していてもよい。この場合の各中継装置は中継装置３０３と同様に動作し、各ＩＰＴＶ受信端末はＩＰＴＶ受信端末３０８と同様に動作するものとする。
【００４４】
また、中継装置３０３とＩＰＴＶ受信端末３０８間の視聴要求・応答や映像音声ストリームを一つのセッションとして捉えた場合、ルータ３０６は、複数の中継装置、複数のＩＰＴＶ受信端末で発生する複数のセッションを同時に制御できるようになっていてもよい。
また、ルータ３０６を複数設置し、それぞれが１つ以上のセッションを制御する場合、その複数設置されたルータを１台のリソース受付制御サーバ３１２で制御してもよいし、複数台のリソース受付制御サーバで制御してもよい。この場合、前記の具体例におけるザッピング予測ユニット３１０が、自身のセッションを制御するルータ３０６を管理するリソース受付制御サーバ３１２の特定方法を知っているものとする。リソース受付制御サーバ３１２の特定方法としては、起動時設定ファイルで固定的にアドレスを保持しておく方法等により実現してもよい。また、ザッピング先予測ユニット３１０がリソース受付制御サーバ３１２内にある場合には、マルチキャスト終端ユニット３０４が、自身のセッションを制御するルータ３０６を管理するリソース受付制御サーバ３１２内のザッピング先予測ユニットの特定方法を知っているものとする。前記ザッピング先予測ユニットの特定方法についても、起動時設定ファイルで固定的にアドレスを保持しておく方法等により実現してもよい。
【００４５】
また、ＩＰＴＶ配信サーバ３０１からマルチキャスト終端ユニット３０４に配信される映像音声ストリームはマルチキャストに替えてユニキャストで配信してもよい。
【００４６】
また、中継装置３０３は複数のＩＰＴＶ配信サーバから同時に映像音声ストリームを受信し、それぞれの映像音声ストリームの中からＩＰＴＶ受信端末３０８から視聴要求のあった映像音声ストリームをＩＰＴＶ受信端末３０８に送信してもよい。
【００４７】
また、リソース受付制御サーバ３１２への前記帯域確保要求、前記帯域解放要求、前記アクセス制御設定要求は、ザッピング先予測ユニット３１０に替えてマルチキャスト終端ユニット３０４が行ってもよい。この場合、ザッピング先予測ユニット３１０で予測映像音声ストリームを設定した際に、その情報をマルチキャスト終端ユニット３０４に返信し、マルチキャスト終端ユニット３０４がその情報を利用して必要な帯域確保要求、帯域解放要求、アクセス制御設定要求をリソース受付制御サーバ３１２に対して送信し、その返答を受信するよう動作する。
【００４８】
なお、ザッピング先予測ユニット３１０、リソース受付制御サーバ３１２の機能は、その機能を実現するためのプログラムを、コンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータに読み込ませ、実行するものであってもよい。コンピュータ読み取り可能な記録媒体とは、フレキシブルディスク、光磁気ディスク、ＣＤ−ＲＯＭ等の記録媒体、コンピュータシステムに内蔵されるハードディスク装置等の記憶装置を指す。さらに、コンピュータ読み取り可能な記録媒体は、インターネットを介してプログラムを送信する場合のように、短時間、動的にプログラムを保持するもの（伝送媒体もしくは伝送波）、その場合のサーバとなるコンピュータ内の揮発性メモリのように、一定時間プログラムを保持しているものを含む。
【産業上の利用可能性】
【００４９】
本発明によれば、配信サーバと端末とから構成される映像音声ストリームの配信システムに適用できる。
【図面の簡単な説明】
【００５０】
【図１】本発明の一実施形態による映像音声ストリーミング配信システムのブロック図である。
【図２】図２の映像音声ストリーミング配信システムの動作を示すフローチャートである。
【図３】図２の映像音声ストリーミング配信システムの具体例のブロック図である。
【図４】ＩＰＴＶ受信端末３０８をユーザが操作するためのリモコンのユーザインタフェースを示す図である。
【図５】従来技術による映像音声ストリーミング配信システムのブロック図である。
【符号の説明】
【００５１】
１０１  配信サーバ
１０２  配信経路
１０３  中継手段
１０４  配信経路
１０５  帯域制御手段
１０６  配信経路
１０７  端末
１０８  制御線
１０９  帯域管理手段
１１０  制御線
１１１  ザッピング先予測手段
１１２  制御線
２０１−２１１  ステップ
３０１  ＩＰＴＶ配信サーバ
３０２  イントラネット
３０３  中継装置
３０４  マルチキャスト終端ユニット
３０５  イントラネット
３０６  ルータ
３０７  公衆電話回線
３０８  ＩＰＴＶ受信端末
３０９  論理的な通信パス
３１０  ザッピング先予測ユニット
３１１  イントラネット
３１２  リソース受付制御サーバ
３１３  イントラネット
４０１  リモコン
４０２  電源ボタン
４０３  チャンネル逆送りボタン
４０４  チャンネル順送りボタン
４０５  ボリューム減少ボタン
４０６  ボリューム増加ボタン
４０７  チャンネル指定ボタン群
【図１】
2008182426.tif 000003
【図２】
2008182426.tif 000004
【図３】
2008182426.tif 000005
【図４】
2008182426.tif 000006
【図５】
2008182426.tif 000007