次に、発明を実施するための最良の形態� ��ついて図面を参照して詳細に説明する。

 図2は本発明の一実施形態の映像音声スト リーミング配信システムのブロック図である 。

 配信サーバ101は配信経路102を介して中継� ��置103に接続している。中継装置103は配信経� ��104を介して帯域制御装置105に接続している� ��帯域制御装置105は配信経路106を介して端末1 07に接続している。ザッピング先予測装置111� ��制御線110を介して中継装置103と接続し、ま� ��制御線112を介して帯域管理装置109と接続し� ��いる。帯域管理装置109は制御線108を介して� ��域制御装置105と接続している。

 図3は本実施形態の映像音声ストリーミン グ配信システムの動作を表すフローチャート である。

 配信サーバ101は、中継装置103に対して複� ��のストリームをマルチキャストで配信する( ステップ201)。この際の配信はマルチキャス� �に代えてユニキャストでもよい。また、中� �装置103は、他の配信サーバ(図示せず)からも 同時にストリームを受信してもよい。

 ユーザがリモコン等を用いてあるストリ� ��ムを選択すると、そのストリームを視聴希� ��ストリームとして、端末107より中継装置103� ��視聴希望ストリームを要求する(ステップ202 )。要求時にはストリームを識別する情報を� �与する。ストリームを識別する情報は、そ� �ストリームをチャンネルとして識別するチ� �ンネル番号、そのストリームを受信するた� �のURL(Uniform Resource Locator)やIPアドレスを用� �てもよい。

 中継装置103は、ザッピング先予測装置111� ��対して、端末107より受信した視聴希望スト� ��ームに必要な帯域幅の確保を要求する帯域� ��保要求を行う(ステップ203)。必要な帯域幅� �、中継装置103で受信している複数のストリ� �ムから、視聴希望ストリームに該当するス� �リームの平均レート等を用いてもよいし、� �らかじめストリーム情報が別途与えられて� �る場合には、その情報を参照して決定して� �よい。

 ザッピング先予測装置111は、受信した視� ��希望ストリームが、前回の帯域確保要求の� ��功時に記録した予測ストリームと同じもの� ��どうかを判定する(ステップ204)。

 ステップ204での判定の結果、同じであれ� ��、ザッピング先予測装置111は、帯域管理装� ��109に対して、前回予測時に確保したストリ� ��ムのうち今回視聴希望に該当しないストリ� ��ム分の帯域の解放要求と、端末107が現在ス� ��リーム受信に使用している帯域の解放要求� ��行う(ステップ205)。そしてザッピング先予� �装置111は、ユーザの嗜好情報によって、次� �ザッピングすることが予測されるストリー� �を新たな予測ストリームとしてその予測ス� �リームに必要な帯域の確保要求を行う(ステ� ��プ206)。ユーザの嗜好情報によるザッピング 先予測は以下のように行う。ザッピング先予 測装置111はユーザの視聴履歴や性別、年齢層 、およびキーワードを嗜好情報として保持す る。該キーワードとしては、タイトル、ジャ ンル、出演者名、脚本・監督名、番組情報中 の単語、インターネットを用いた通信販売の 購買履歴があり、ユーザがあらかじめザッピ ング先予測装置111に登録してもよいし、ザッ ピング先予測装置111が自動で蓄積してもよい 。また、それぞれの嗜好情報には重みを付け てもよい。該嗜好情報をもとに中継装置103で 受信している複数のストリームそれぞれに対 してユーザとの嗜好の合致度を算出し、合致 度が高いものをザッピング先の候補とする。 予測したザッピング先の候補数は、中継装置 103と端末107の間にある、配信経路104や106、帯 域制御装置105のスペックによって定めてもよ い。すなわち帯域幅にもともと余裕がない配 信経路設計の場合には予測したザッピング先 の候補を1つに限定し、余裕がある配信経路� �計の場合には予測したザッピング先の候補� �2や3に設定する等である。

 ステップ204での判定の結果、同じでなけ� ��ば、ザッピング先予測装置111は、帯域管理� ��置109に対して、前回予測時に確保した予測� ��トリーム分の帯域の解放要求と、現在端末1 07がストリーム受信に使用している帯域の解� ��要求を行う(ステップ207)。次に、ザッピン� �先予測装置111は、視聴希望ストリームに必� �な帯域の確保要求と、ユーザの嗜好情報に� �って次にザッピングすることが予測される� �トリームを新たな予測ストリームとしてそ� �予測ストリームに必要な帯域の帯域確保要� �を行う(ステップ208)。

 ステップ205からステップ208で行っている� ��帯域解放要求や各帯域確保要求の手順は一� ��であり、各要求を個別に順序立てて実施し� ��もよい。また、実施タイミングもそれぞれ� ��らしてよい。ステップ204での判定の結果が� ��じ場合、例えば、ステップ211で帯域確保要� ��の受付結果を中継装置103に通知した後に、� ��測に外れたストリームの帯域の解放要求と� ��たな予測ストリームの帯域の確保要求とを� ��ってもよいし、また端末107が現在受信して� ��るストリームの帯域の解放要求はステップ2 11の後やステップ212の後やステップ213の後や� ��末107が新たなストリームの受信に成功して� ��ら(図示せず)行ってもよい。ステップ204で� �判定の結果が同じでない場合も同様である� �

 帯域管理装置109は要求された帯域確保要� ��または帯域解放要求に応じて帯域制御装置1 05に帯域制御を指示する(ステップ209)。この� �、帯域確保要求や帯域解放要求に失敗した� �合にはステップ209では帯域制御装置105に対� �て何も指示しないことにしてもよい。また� �その場合には、ステップ210、ステップ211、� �テップ212、ステップ213では、視聴希望スト� �ームや新旧の予測ストリームに関して、端� �107からは要求がなかったように振る舞い、� �末107での現在の受信が途切れないようにし� �もよい。その場合でも要求が失敗したこと� �、ステップ210、ステップ211、ステップ212に� �いて通知し、端末107に対して失敗したこと� �伝わるようにしてもよい。

 帯域管理装置109は要求された帯域確保要� ��または帯域解放要求の受付結果をザッピン� ��先予測装置111に通知する(ステップ210)。

 ザッピング先予測装置111は、中継装置103� ��対して、視聴希望ストリームの帯域確保要� ��受付結果を通知する(ステップ211)。

 中継装置103は、端末107に対して、視聴希� ��ストリームの帯域確保要求受付結果を通知� ��る(ステップ212)。中継装置103は、ステップ21 1の受付結果が成功と通知された場合、要求� �れた視聴希望ストリームを端末107にユニキ� �ストで配信する(ステップ213)。この時、ユニ キャストに代えてマルチキャストで配信して もよい。この際のマルチキャストによる配信 は、他の端末(図示せず)が同時に中継装置103� ��接続されている場合に効果がある。すなわ� ��、配信経路104や配信経路106、帯域制御装置1 05の能力が複数の端末に対してそれぞれユニ� ��ャストするのに十分な帯域や性能のない場� ��に、複数の端末で同じ映像音声ストリーム� ��同時視聴する場合には、その同じ映像音声� ��トリームをマルチキャストで配信してもよ� ��。

 また、帯域管理装置109における帯域確保� ��に、帯域制御装置105に十分な空きリソース� ��無い場合には、予測映像音声ストリーム分� ��帯域については、仮想的なリソースに対す� ��帯域確保として処理するようにしてもよい� ��その場合、帯域制御装置105で実際に予測映� ��音声ストリームが次に視聴する映像音声ス� ��リームとして確定した段階で、実ストリー� ��として配信可能なように、帯域制御装置105� ��帯域管理装置109やザッピング先予測装置111� ��、実ストリームとして配信する接続を切り� ��える処理を含んでもよい。例えば、実スト� ��ームとして確定した際には、ザッピング先� ��測装置111から帯域管理装置109に確定を通知� ��、帯域管理装置109は帯域制御装置105に切り� ��え指示を行うようにしてもよい。

 なお、上記全ての処理を通じて、帯域確� ��、帯域解放の際には接続端末のフィルタリ� ��グ処理(アクセス制御)を伴ってもよい。例� �ば、帯域制御装置105にファイアウォール機� �を搭載する場合には、該当ストリームの帯� �確保を行う際に、そのストリームを受信す� �端末と送信する配信サーバ間との通信が可� �になるようにパケットフィルタリングを設� �してもよい。また、同様に、帯域解放の際� �は、そのストリームを受信する端末と送信� �る配信サーバ間との通信が不可能になるよ� �にパケットフィルタリングを設定してもよ� �。また、フィルタリング処理は帯域確保お� �び帯域解放の前に行われても、同時に行わ� �ても、後に行われてもよい。

 図4は図2の映像音声ストリーミング配信� �ステムの具体例のブロック図である。

 中継装置303は、マルチキャストを終端し� ��ニキャストに変換するマルチキャスト終端� ��ニット304と、次に選択されるストリームを� ��測するザッピング先予測ユニット310から構� ��される。マルチキャスト終端ユニット304と� ��ッピング先予測ユニット310はプログラムに� ��る実装を示しており、各プログラム間を接� ��する論理的な通信パス309によって通信する� ��IPTV配信サーバ301は、イントラネット302を介 してマルチキャスト終端ユニット304(中継装� �303内)と接続する。マルチキャスト終端ユニ� ��ト304はイントラネット305を介してルータ306� ��接続する。ルータ306は、パケット優先制御� ��能とアクセス制御機能を有するルータであ� ��、パケット優先制御機能は特定パケットの� ��域をコントロールする機能を有し、アクセ� ��制御機能はパケットを流してよいソースや� ��ィスティネーションを指定することが可能� ��ある。ルータ306は公衆電話回線(ADSL)を介し� ��IPTV受信端末308と接続する。リソース受付制 御サーバ312は、イントラネット313を介してル ータ306のパケット優先制御機能とアクセス制 御機能を制御する。また、イントラネット311 を介してザッピング先予測ユニット310(中継� �置303内)からルータ制御要求を受け付ける。

 図5は、IPTV受信端末308を操作するリモコ� �の一構成例である。

 リモコン401は電源ボタン402とチャンネル� ��送りボタン403とチャンネル順送りボタン404� ��ボリューム減少ボタン405とボリューム増加� ��タン406とチャンネル指定ボタン群407から構� ��される。

 チャンネル指定ボタン群407の各ボタンに� ��、IPTV配信サーバ301より配信されている複数 の映像音声ストリームA~Lまでが順に割り当て られている。すなわち、チャンネル1には映� �音声ストリームAが、チャンネル2には映像音 声ストリームBが、チャンネル3には映像音声� ��トリームCが、チャンネル4には映像音声ス� �リームDが、チャンネル5には映像音声ストリ ームEが、チャンネル6には映像音声ストリー� ��Fが、チャンネル7には映像音声ストリームG� ��、チャンネル8には映像音声ストリームHが� �チャンネル9には映像音声ストリームIが、チ ャンネル10には映像音声ストリームJが、チャ ンネル11には映像音声ストリームKが、チャン ネル12には映像音声ストリームLが、それぞれ 割り当てられている。

 チャンネル逆送りボタン403を操作すると� ��TVのチャンネルに相当する操作として、現� �視聴中の映像音声ストリームに対して隣接� �る、チャンネル番号の小さい映像音声スト� �ームを再生するよう要求する。すなわち、� �在映像音声ストリームCが視聴中である場合� ��チャンネル逆送りボタン403を押下すると、� ��像音声ストリームBが視聴される。この場合 、チャンネル指定ボタン群507のボタン「2」� �操作したのと同じ効果が得られる。

 チャンネル順送りボタン404を操作すると� ��TVのチャンネルに相当する操作として、現� �視聴中の映像音声ストリームに対して隣接� �る、チャンネル番号の大きい映像音声スト� �ームを再生するよう要求する。すなわち現� �映像音声ストリームCが視聴中である場合に� ��ャンネル順送りボタン404を押下すると、映� ��音声ストリームDが視聴される。この場合、 チャンネル指定ボタン群407のボタン「4」を� �作したのと同じ効果が得られる。

 次に、本具体例の動作について説明する。
IPTV配信サーバ301は、マルチキャスト終端ユ� �ット304に対して、12本の映像音声ストリーム A~L(図示せず)をマルチキャストで送信中であ� ��。また、ザッピング先予測ユニット310が保� ��している嗜好情報をもとに該映像音声スト� ��ームA~Lそれぞれに対してユーザとの嗜好の� ��致度を算出した結果、合致度の高い上位5ス トリームは高い順にA、B、C、D、Eであるもの� ��し、ザッピング先の候補数は2であることと する。そして、現在IPTV受信端末308で受信し� �いる映像音声ストリームは、映像音声スト� �ームDであるものとし、前回リモコン401操作� ��に映像音声ストリームAとBが予測され、AとB は帯域確保がなされた状態であることとする 。

 ユーザがリモコン401を操作し、チャンネ� ��指定ボタン群407のボタン「1」を押下すると 、IPTV受信端末308はマルチキャスト終端ユニ� �ト304に、視聴要求(映像音声ストリームA)を� �信する。マルチキャスト終端ユニット304は� �ッピング先予測ユニット310に前記視聴要求� �送信する。

 ザッピング先予測ユニット310では、前回� ��聴要求受付時に映像音声ストリームAを予測 映像音声ストリームとし、ルータ306を介した 配信に必要な帯域確保およびアクセス制御を 実施済みである。そこでザッピング先予測ユ ニット310では、再度嗜好の合致度の計算を行 い、次の予測映像音声ストリームとして映像 音声ストリームA以外でユーザの嗜好との合� �度が高い映像音声ストリームBとCを設定する 。次に、ザッピング先予測ユニット310は、映 像音声ストリームA、B、Cを配信するために必 要な帯域確保およびアクセス可能設定要求(� �像音声ストリームAとBは継続、Cは新規)と、� ��要となった映像音声ストリームDの帯域解放 およびアクセス不可能設定要求を行う。

 リソース受付制御サーバ312では、ザッピ� ��グ先予測ユニット310からの要求に従い、ル� ��タ306に、映像音声ストリームDの帯域解放お よびアクセス不可能設定要求を、映像音声ス トリームA、B、Cの帯域確保(映像音声ストリ� �ムAとBは継続、Cは新規)およびアクセス可能� ��定要求を行う。ここでは、この要求に対し� ��ルータ306から要求受付成功が返信されたも� ��とする。そこで、リソース受付制御サーバ3 12はザッピング先予測ユニット310に対して要� ��受付成功を送信する。

 ザッピング先予測ユニット310では、リソ� ��ス受付制御サーバ312からの要求受付成功を� ��信したため、リソース受付制御サーバ312に� ��求した新たな視聴中の映像音声ストリームA および映像音声ストリームA以外でユーザの� �好との合致度が高い映像音声ストリームBとC をそれぞれ確定し、マルチキャスト終端ユニ ット304に要求受付成功を送信する。

 マルチキャスト終端ユニット304は、ザッ� ��ング先予測ユニット310から返信された要求� ��付成功を受け、現在ルータ306を介してIPTV受 信端末308にユニキャストで送信している映像 音声ストリームDを停止し、替わりに映像音� �ストリームAを送信開始する。

 IPTV受信端末308は新たな映像音声ストリー ムAを受信開始し、再生する。

 上記具体例におけるザッピング先予測ユ� ��ット310は、中継装置303に代えてリソース受� ��制御サーバ312に含まれていてもよい。この� ��合、マルチキャスト終端ユニット304でIPTV受 信端末308からの前記視聴要求を受信した際に 、ザッピング先予測ユニット310(リソース受� �制御サーバ312内)に視聴要求を行なう。ザッ� ��ング先予測ユニット310は、前記具体例と同� ��にリソース受付制御サーバ312内にある帯域� ��アクセスの管理ユニット(図示せず)に前記� �体例における帯域確保要求およびアクセス� �定要求を行う。

 また、前記具体例においては、IPTV受信端 末が一つの場合について説明したが、複数の IPTV受信端末が中継装置303に同時に接続して� �てもよく、この場合のIPTV受信端末はIPTV受信 端末308と同様に動作するものとする。また、 ルータ306は前記の複数のIPTV受信端末の視聴� �求・応答や映像音声ストリームを同時に制� �できるようにしてもよい。

 また、IPTV配信サーバ301からマルチキャス トで送信される複数の映像音声ストリームを 複数の中継装置で同時に受信し、各中継装置 にはそれぞれ1つ以上のIPTV受信端末が接続し� ��いてもよい。この場合の各中継装置は中継� ��置303と同様に動作し、各IPTV受信端末はIPTV� �信端末308と同様に動作するものとする。

 また、中継装置303とIPTV受信端末308間の視 聴要求・応答や映像音声ストリームを一つの セッションとして捉えた場合、ルータ306は、 複数の中継装置、複数のIPTV受信端末で発生� �る複数のセッションを同時に制御できるよ� �になっていてもよい。

 また、ルータ306を複数設置し、それぞれ� ��1つ以上のセッションを制御する場合、その 複数設置されたルータを1台のリソース受付� �御サーバ312で制御してもよいし、複数台の� �ソース受付制御サーバで制御してもよい。� �の場合、前記の具体例におけるザッピング� �測ユニット310が、自身のセッションを制御� �るルータ306を管理するリソース受付制御サ� �バ312の特定方法を知っているものとする。� �ソース受付制御サーバ312の特定方法として� �、起動時設定ファイルで固定的にアドレス� �保持しておく方法等により実現してもよい� �また、ザッピング先予測ユニット310がリソ� �ス受付制御サーバ312内にある場合には、マ� �チキャスト終端ユニット304が、自身のセッ� �ョンを制御するルータ306を管理するリソー� �受付制御サーバ312内のザッピング先予測ユ� �ットの特定方法を知っているものとする。� �記ザッピング先予測ユニットの特定方法に� �いても、起動時設定ファイルで固定的にア� �レスを保持しておく方法等により実現して� �よい。

 また、IPTV配信サーバ301からマルチキャス ト終端ユニット304に配信される映像音声スト リームはマルチキャストに替えてユニキャス トで配信してもよい。

 また、中継装置303は複数のIPTV配信サーバ から同時に映像音声ストリームを受信し、そ れぞれの映像音声ストリームの中からIPTV受� �端末308から視聴要求のあった映像音声スト� �ームをIPTV受信端末308に送信してもよい。

 また、リソース受付制御サーバ312への前� ��帯域確保要求、前記帯域解放要求、前記ア� ��セス制御設定要求は、ザッピング先予測ユ� ��ット310に替えてマルチキャスト終端ユニッ� ��304が行ってもよい。この場合、ザッピング� ��予測ユニット310で予測映像音声ストリーム� ��設定した際に、その情報をマルチキャスト� ��端ユニット304に返信し、マルチキャスト終� ��ユニット304がその情報を利用して必要な帯� ��確保要求、帯域解放要求、アクセス制御設� ��要求をリソース受付制御サーバ312に対して� ��信し、その返答を受信するよう動作する。

 なお、ザッピング先予測ユニット310、リ� ��ース受付制御サーバ312の機能は、その機能� ��実現するためのプログラムを、コンピュー� ��読み取り可能な記録媒体に記録して、この� ��録媒体に記録されたプログラムをコンピュ� ��タに読み込ませ、実行するものであっても� ��い。コンピュータ読み取り可能な記録媒体� ��は、フレキシブルディスク、光磁気ディス� ��、CD-ROM等の記録媒体、コンピュータシステ� ��に内蔵されるハードディスク装置等の記憶� ��置を指す。さらに、コンピュータ読み取り� ��能な記録媒体は、インターネットを介して� ��ログラムを送信する場合のように、短時間� ��動的にプログラムを保持するもの(伝送媒体 もしくは伝送波)、その場合のサーバとなる� �ンピュータ内の揮発性メモリのように、一� �時間プログラムを保持しているものを含む� �

 本発明は、ストリーミングに仮想のチャ� ��ネルが与えられた際に、予測を元に、次に� ��ッピングして視聴される可能性のあるスト� ��ーム分の帯域確保とアクセス制御のみを、� ��ッピング操作に先行して行うことによって� ��ザッピング時のストリーム切り替え速度を� ��上させ、なおかつ実使用ネットワークリソ� ��スを最低限に抑える。

 以上本発明の好ましい実施形態を特定の� ��語を用いて説明したが、そのような記載は� ��示のみを目的としており、種々の変形およ� ��修正が以下の特許請求の範囲から外れるこ� ��なく可能であることが理解されるべきであ� ��。

 この出願は、2007年1月24日に出願された日 本出願特願2007-013741号を基礎とする優先権を� ��張し、その開示をここに取り込む。