(57)【特許請求の範囲】
【請求項１】
動画像または音声を再生するためのマルチメディアデータをストリーミング配信するストリーミングサーバが設けられたストリーミング配信システムにおける管理サーバであって、
トラフィックが多いことが原因でユーザの端末装置と前記ストリーミングサーバとの接続ができない場合に、当該端末装置から送信される、当該接続の要求を、取得する要求取得手段と、
前記ストリーミングサーバの現在のトラフィックを示すトラフィック情報を取得するトラフィック情報取得手段と、
前記トラフィック情報に基づいて前記接続が可能であるか否かを判別する判別手段と、
前記判別手段によって前記接続が可能であると判別された場合に前記端末装置に対して当該接続が可能になった旨の通知を行う通知手段と、
を有してなることを特徴とするストリーミング配信システムにおける管理サーバ。
【請求項２】
前記トラフィック情報取得手段は、所定の時間が経過するごとに前記トラフィック情報を取得し、
前記判別手段は、前記トラフィック情報取得手段によって前記トラフィック情報が取得されるごとに前記接続が可能であるか否かを判別する、
請求項１記載のストリーミング配信システムにおける管理サーバ。
【請求項３】
前記通知手段によって前記通知が行われる際に前記接続のための帯域を確保する帯域確保手段、を有する、
請求項１または請求項２記載のストリーミング配信システムにおける管理サーバ。
【請求項４】
前記帯域確保手段は、前記帯域を確保するために、予約のない他の端末装置と前記ストリーミングサーバとの第二の接続を制限する、
請求項３記載のストリーミング配信システムにおける管理サーバ。
【請求項５】
前記通知手段は、前記通知を、前記接続が可能になった旨を示す電子メールを前記ユーザの電子メールアドレスに宛てて送信することによって、行う、
請求項１ないし請求項４のいずれかに記載のストリーミング配信システムにおける管理サーバ。
【請求項６】
動画像または音声を再生するためのマルチメディアデータをストリーミング配信するストリーミングサーバが設けられたストリーミング配信システムの管理方法であって、
前記ストリーミング配信システムに管理サーバを設けておき、
前記管理サーバに、
トラフィックが多いことが原因でユーザの端末装置と前記ストリーミングサーバとの接続ができない場合に、当該端末装置から送信される、当該接続の要求を、取得する第一の処理を、実行させ、
前記ストリーミングサーバの現在のトラフィックを示すトラフィック情報を取得する第二の処理を実行させ、
前記トラフィック情報に基づいて前記接続が可能であるか否かを判別する第三の処理を実行させ、
前記接続が可能であると判別された場合に前記端末装置に対して当該接続が可能になった旨の通知を行う第四の処理を実行させる、
ことを特徴とするストリーミング配信システムの管理方法。
【請求項７】
所定の時間が経過するごとに前記管理サーバに前記第二の処理を実行させ、
前記トラフィック情報が取得されるごとに前記管理サーバに前記第三の処理を実行させる、
請求項６記載のストリーミング配信システムの管理方法。
【請求項８】
前記管理サーバに、
前記通知を行う際に前記接続のための帯域を確保する第五の処理を実行させる、
請求項６または請求項７記載のストリーミング配信システムの管理方法。
【請求項９】
動画像または音声を再生するためのマルチメディアデータをストリーミング配信するストリーミングサーバが設けられたストリーミング配信システムにおける管理サーバに用いられるコンピュータプログラムであって、
前記管理サーバに、
トラフィックが多いことが原因でユーザの端末装置と前記ストリーミングサーバとの接続ができない場合に、当該端末装置から送信される、当該接続の要求を、取得する第一の処理を、実行させ、
前記ストリーミングサーバの現在のトラフィックを示すトラフィック情報を取得する第二の処理を実行させ、
前記トラフィック情報に基づいて前記接続が可能であるか否かを判別する第三の処理を実行させ、
前記接続が可能であると判別された場合に前記端末装置に対して当該接続が可能になった旨の通知を行う第四の処理を実行させる、
ことを特徴とするコンピュータプログラム。
【請求項１０】
所定の時間が経過するごとに前記管理サーバに前記第二の処理を実行させ、
前記トラフィック情報が取得されるごとに前記管理サーバに前記第三の処理を実行させる、
請求項９記載のコンピュータプログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、ストリーミング配信によってマルチメディアコンテンツをユーザに配信するストリーミング配信システムに用いられる管理サーバに関する。
【０００２】
【従来の技術】
従来より、コンサートまたはスポーツなどの番組（マルチメディアコンテンツ）をストリーミング配信によってユーザにライブ中継する技術が提案されている。ユーザは、インターネットなどを介してパソコンなどの端末装置をストリーミングサーバに接続し、様々なジャンルの番組をリアルタイムに楽しむことができる。一般に、このような配信の形態を「ライブ配信」という。ライブ配信は、ニュースまたはスポーツなどの番組のように新しさが要求されるものを配信するのに適している。
【０００３】
また、ストリーミングサーバに様々な番組のためのマルチメディアデータを用意しておき、ユーザからの要求に応じて番組をストリーミング配信する技術が提案されている。一般に、このような配信の形態を「ビデオオンデマンド」という。ビデオオンデマンドによると、ユーザは、いつでも好きな番組を楽しむことができる。つまり、ビデオオンデマンドは、映画またはドラマなどの番組に適している。
【０００４】
このように、ライブ配信およびビデオオンデマンドの両形態は、番組の種類などに応じて使い分けられている。
【０００５】
【発明が解決しようとする課題】
しかし、ライブ配信の場合は、ユーザは、配信時間（放送時間）に必ず端末装置３の前にいなければならないので、時間的な拘束を受けてしまう。また、用事があるときは番組を観ることができないし、観られなかった番組がビデオオンデマンドにより配信されるとは限らない。
【０００６】
端末装置を家庭用のビデオデッキなどに接続しビデオテープに録画する方法が考えられるが、ストリーミング配信を気軽に楽しみたいユーザにとっては、必ずしもよい方法であるとはいえない。なぜなら、パソコンなどの端末装置にはビデオ端子が設けられていない場合がほとんどであり、実際に端末装置をビデオデッキに接続するのは難しいからである。また、ビデオデッキや接続用のデバイスなどを購入するための新たな費用が掛かってしまう。
【０００７】
また、ストリーミング配信は、ライブ配信またはビデオオンデマンドのいずれの形態であるかに関わらず、通信量が膨大でありかつストリーミングサーバの処理の負担が大きい。したがって、ストリーミングサーバへのアクセスが集中すると、すぐに通信回線が混雑してしまい、またはストリーミングサーバの処理に遅れが生じてしまう。このような原因により、ストリーミングサーバから番組の配信を受けようとしても、ストリーミングサーバに接続ができない場合やデータがなかなか送信されて来ない場合などがある。
【０００８】
また、従来はＩＳＰ（Internet Service Provider）または放送局などの情報配信の専門業者がストリーミング配信を行っていたが、近年は専門業者以外の企業、商店、または個人などの者が事務所、店舗、または自宅などにストリーミングサーバを設置し、ストリーミング配信を行うようになってきている。しかし、これらの者は、専門業者のような高性能のシステムを有しないし、高速度の通信回線を有しない。したがって、これらの者にとって、通信回線の混雑による処理の遅延などの問題は一層深刻となる。
【０００９】
本発明は、このような問題点に鑑み、ユーザがライブ中継の番組を所望するときに観ることができるようにすることを目的とする。また、ストリーミング配信を円滑することを目的とする。
【００１０】
【課題を解決するための最良の形態】
本発明の一形態に係るストリーミング配信システムにおける管理サーバは、動画像または音声を再生するためのマルチメディアデータをストリーミング配信するストリーミングサーバが設けられたストリーミング配信システムにおける管理サーバであって、トラフィックが多いことが原因でユーザの端末装置と前記ストリーミングサーバとの接続ができない場合に、当該端末装置から送信される、当該接続の要求を、取得する要求取得手段と、前記ストリーミングサーバの現在のトラフィックを示すトラフィック情報を取得するトラフィック情報取得手段と、前記トラフィック情報に基づいて前記接続が可能であるか否かを判別する判別手段と、前記判別手段によって前記接続が可能であると判別された場合に前記端末装置に対して当該接続が可能になった旨の通知を行う通知手段と、を有してなる。
【００１１】
好ましくは、前記トラフィック情報取得手段は、所定の時間が経過するごとに前記トラフィック情報を取得し、前記判別手段は、前記トラフィック情報取得手段によって前記トラフィック情報が取得されるごとに前記接続が可能であるか否かを判別する。
【００１２】
または、前記通知手段によって前記通知が行われる際に前記接続のための帯域を確保する帯域確保手段、を有する。
【００１３】
または、前記帯域確保手段は、前記帯域を確保するために、予約のない他の端末装置と前記ストリーミングサーバとの第二の接続を制限する。
【００１４】
前記通知手段は、前記通知を、前記接続が可能になった旨を示す電子メールを前記ユーザの電子メールアドレスに宛てて送信することによって、行う。
【００１５】
本発明の一形態に係るストリーミング配信システムの管理方法は、動画像または音声を再生するためのマルチメディアデータをストリーミング配信するストリーミングサーバが設けられたストリーミング配信システムの管理方法であって、前記ストリーミング配信システムに管理サーバを設けておき、前記管理サーバに、トラフィックが多いことが原因でユーザの端末装置と前記ストリーミングサーバとの接続ができない場合に、当該端末装置から送信される、当該接続の要求を、取得する第一の処理を、実行させ、前記ストリーミングサーバの現在のトラフィックを示すトラフィック情報を取得する第二の処理を実行させ、前記トラフィック情報に基づいて前記接続が可能であるか否かを判別する第三の処理を実行させ、前記接続が可能であると判別された場合に前記端末装置に対して当該接続が可能になった旨の通知を行う第四の処理を実行させる。
【００１６】
【発明の実施の形態】
〔第一の実施形態〕
図１は本発明に係るストリーミング配信システム１の構成の例を示す図、図２はデータ配信サーバ２Ｌのハードウェア構成の例を示す図、図３は管理サーバ１０のハードウェア構成の例を示す図、図４は管理サーバ１０の機能的構成の例を説明する図、図５は予約フォーム画面ＨＧ１の例を示す図、図６は確認画面ＨＧ２の例を示す図、図７は管理サーバ１０の処理の流れの例を説明するフローチャートである。
【００１７】
図１に示すように、本発明に係るストリーミング配信システム１は、管理サーバ１０、データ配信サーバ２、端末装置３、および通信回線５などによって構成される。ストリーミング配信システム１の各装置は、通信回線５を介して互いに接続可能である。通信回線５として、インターネット、公衆回線、または専用線などが用いられる。データ配信サーバ２および管理サーバ１０は、ＩＳＰ（Internet Service Provider）、ＡＳＰ（Application Service Provider）、テレビ局、ラジオ局、またはケーブルテレビ局など情報発信の専門業者に設置されている。
【００１８】
このストリーミング配信システム１によると、ユーザは、自分の端末装置３からデータ配信サーバ２にアクセスし、データ配信サーバ２からストリーミング配信（送信）されるデータを受信し、音声または動画像（映像）などによる種々の情報（いわゆるマルチメディアコンテンツ）を視聴することができる。マルチメディアコンテンツとして、例えば、映画、ドラマ、ドキュメント、アニメーションマンガ、スポーツ、演劇、コンサート、またはニュースなど様々な種類のものがユーザに配信され提供されている。以下、ユーザに配信されるこれらのマルチメディアコンテンツを「番組」と記載することがある。なお、これらのマルチメディアコンテンツ（番組）を作成し提供するのは、情報発信の専門業者に限られない。例えば、商店または個人などが、データ配信サーバ２を事務所または自宅などに設置し、マルチメディアコンテンツを作成し提供する場合もある。
【００１９】
番組のデータの配信形態として、ビデオカメラで撮影された映像などを直ちに配信する「ライブ配信」と、マルチメディアファイルとして記憶されているものをユーザからの要求に応じて配信する「ビデオオンデマンド（ＶｏＤ）配信」の２種類がある。以下、ライブ配信を行うデータ配信サーバ２を「データ配信サーバ２Ｌ」と記載し、ＶｏＤ配信を行うデータ配信サーバ２を「データ配信サーバ２Ｖ」と記載することがある。
【００２０】
また、ユーザは、ライブ配信されるマルチメディアコンテンツを管理サーバ１０に一旦記録しておき、後からこの番組を視聴することができる。以下、このようにライブ配信された番組のデータを記録することを「録画」と記載することがある。
【００２１】
端末装置３は、通信回線５に接続するためのインタフェースを有し、映像または音声を再生するためのストリーミングアプリケーション、Ｗｅｂブラウザ（ＷＷＷブラウザ）、および電子メールアプリケーションなどがインストールされている。端末装置３として、パーソナルコンピュータ、ＰＤＡ（Personal Digital Assistant）、または携帯電話端末などが用いられる。ストリーミングアプリケーションとして、マイクロソフト社のＷｉｎｄｏｗｓ  Ｍｅｄｉａ  Ｐｌａｙｅｒ（商標）またはリアルネットワークス社のＲｅａｌ  Ｐｌａｙｅｒ（登録商標）などが用いられる。
【００２２】
データ配信サーバ２Ｌは、図２に示すように、ＣＰＵ２ａ、ＲＡＭ２ｂ、ＲＯＭ２ｃ、磁気記憶装置２ｄ、ビデオ入力インタフェース２ｅ、および音声入力インタフェース２ｆなどによって構成される。データ配信サーバ２Ｌには、ビデオ入力インタフェース２ｅおよび音声入力インタフェース２ｆを介してストリーミング配信するためのマルチメディアデータが入力される。ＩＥＥＥ１３９４または通信インタフェースなどのインタフェースを介してマルチメディアデータを入力してもよい。磁気記憶装置２ｄには、ＯＳ（オペレーティングシステム）、ストリーミングサーバ用アプリケーション、および種々のプログラムおよびデータが記憶されている。これらのプログラム（アプリケーション）およびデータは必要に応じてＲＡＭ２ｂにロードされ、ＣＰＵ２ａによってプログラムが実行される。ストリーミングサーバ用アプリケーションとして、マイクロソフト社のＷｉｎｄｏｗｓ  Ｍｅｄｉａ  Ｓｅｒｖｅｒ（商標）またはリアルネットワークス社のＲｅａｌ  Ｓｅｒｖｅｒ（登録商標）などが用いられる。
【００２３】
データ配信サーバ２Ｌには、同時に複数の番組を配信することができるものがある。つまり、１台の装置の中に仮想的に複数のストリーミングサーバが構成されているものがある。データ配信サーバ２Ｖの構成については、第二の実施形態で説明する。
【００２４】
このような構成により、データ配信サーバ２Ｌは、マルチメディアコンテンツ（番組）をストリーミング配信するストリーミングサーバとして機能する。すなわち、ライブ撮影によって得られるマルチメディアデータに対してストリーミングサーバ用アプリケーションを実行し、番組を再生するためのデータをパケットにして端末装置３に次々に送信する。このとき、端末装置３は、パケットを受信しながら番組をリアルタイム再生する。
【００２５】
管理サーバ１０は、図３に示すように、ＣＰＵ１０ａ、ＲＡＭ１０ｂ、ＲＯＭ１０ｃ、磁気記憶装置１０ｄ、および各種インタフェースなどによって構成される。磁気記憶装置１０ｄには、ＯＳ（オペレーティングシステム）、ＷＷＷ（Ｗｅｂ）サーバ用プログラム、データ配信サーバ２（ストリーミングサーバ）の管理用プログラム、ストリーミングサーバ用アプリケーション、および種々のプログラムおよびデータが記憶されている。
【００２６】
このような構成により、管理サーバ１０は、図４に示すように、配信予定受信部１０１、予定一覧生成部１０２、予定一覧送信部１０３、録画予約受付部１０４、データ受信部１０５、録画データ送信部１０６、配信予定記憶部１Ｄ１、録画データ記憶部１Ｄ２、および予約録画情報記憶部１Ｄ３などの機能が実現される。これらの構成によって、各データ配信サーバ２から配信される番組の管理、ユーザから予約するように要求された番組の録画、および録画した番組の送信などの処理を行う。
【００２７】
配信予定受信部１０１は、番組の配信の予定すなわちタイムテーブルを示す配信予定情報７１を各データ配信サーバ２Ｌから受信する。受信された配信予定情報７１は、配信予定記憶部１Ｄ１に記憶される。
【００２８】
予定一覧生成部１０２は、これらの配信予定情報７１に基づいて、各データ配信サーバ２Ｌから配信される番組の一覧表を有する画面を表示するための番組一覧情報７３を生成する。番組一覧情報７３は、ＨＴＭＬ（Hypertext Markup Language）またはＸＭＬ（Extensible Markup Language）などの言語で記述される。または、ＪＡＶＡ（登録商標）などのアプリケーションプログラムなどで構成されてもよい。後に説明する各画面を表示するための画面情報も同様である。
【００２９】
番組一覧情報７３の生成は、いずれかのデータ配信サーバ２Ｌの番組の配信予定に変更があった場合、一定時間（例えば半日）が経過したとき、または端末装置３から要求されたときなどに生成される。
【００３０】
予定一覧送信部１０３は、生成された番組一覧情報７３を端末装置３に送信する。すると、端末装置３には、図５に示すような予約フォーム画面ＨＧ１が表示される。予約フォーム画面ＨＧ１の中の番組一覧表ＬＳ１は、各データ配信サーバ２Ｌから配信される番組の予定を示している。「１ｃｈ」、「２ｃｈ」などのチャンネル名は、データ配信サーバ２Ｌごとに適当に割り振られている。１台のデータ配信サーバ２Ｌが複数の番組を同時に配信する場合は、その数に応じてチャンネル名が割り振られる。時計アイコンＡＮ１は、現在の時刻を示している。ユーザは、番組一覧表ＬＳ１を参照し、視聴したい番組のタイトルをクリックする。すると、端末装置３は、その番組を配信しているデータ配信サーバ２Ｌにアクセスし、ストリーミング配信されるデータを受信しながら映像または音声をリアルタイムに再生する。例えば、「国際ニュース」をクリックすると、ライブ配信されている国際ニュースの番組が再生される。
【００３１】
また、ユーザは、番組一覧表ＬＳ１に示される番組を指定して録画の予約を行うことができる。録画の予約は、次のような手順で行われる。まず、ユーザは、所望する番組を番組一覧表ＬＳ１の中から見つけてクリックする。すると、テキストボックスＴＸ１１には、ＵＲＬ（Uniform Resource Locator）が表示される。このＵＲＬは、予約録画の対象である番組の番組名（タイトル）およびその番組を配信するデータ配信サーバ２Ｌのサーバ名を示している。例えば、図５のＵＲＬのうち「スポーツニュース」は番組名を示し、「ｓｅｒｖｅｒ１」はサーバ名を示している。
【００３２】
テキストボックスＴＸ１２には、その番組が配信される予定の時間帯が表示される。ユーザは、番組の一部分だけを視聴したい場合は、テキストボックスＴＸ１２に示される時間帯を変更することができる。なお、１つのデータ配信サーバ２Ｌに１つのチャンネルしか与えられていない場合は、サーバ名および時間帯の２つを指定すればよい。この２つの情報だけで録画したい番組が特定されるからである。
【００３３】
録画したい番組および録画する時間帯が決まった後、ユーザは、予約録画ボタンＢＮ１１をクリックする。すると、端末装置３は、テキストボックスＴＸ１１、ＴＸ１２の内容および予約を行ったユーザのユーザ名などが予約録画情報７４として管理サーバ１０に送信される。
【００３４】
図４に戻って、端末装置３から送信された予約録画情報７４は、録画予約受付部１０４によって受信され、予約録画情報記憶部１Ｄ３に記憶される。以上により、録画の予約が完了する。
【００３５】
データ受信部１０５は、予約録画情報記憶部１Ｄ３に記憶されている予約録画情報７４に基づいてデータ配信サーバ２Ｌから番組を受信し、予約を行ったユーザと対応付けてその番組のマルチメディアデータを録画データ記憶部１Ｄ２に記憶する。例えば、図５の予約フォーム画面ＨＧ１で予約された予約録画情報７４の場合は、２１時になる数十秒前にデータ配信サーバ２Ｌ１にアクセスする。２１時ちょうどになったときから、データ配信サーバ２Ｌ１からストリーミング配信されるデータを録画データ記憶部１Ｄ２に記録し始める。データの記録は、２２時になるまで続けられる。そして、受信したデータの一群をユーザと対応付けて保存する。
【００３６】
このように、データ配信サーバ２Ｌからライブ配信される番組をユーザの希望の時間帯に応じて編集し、そのユーザ個人のものとして記録し保存しておくことができる。以下、録画データ記憶部１Ｄ２に記録された番組のデータを「番組録画データ８０」と記載する。
【００３７】
次に、録画した番組を視聴する場合の処理について説明する。所定の操作を行うと、端末装置３には、図６に示す確認画面ＨＧ２が表示される。ユーザは、予約した番組の一覧を確認することができる。つまり、確認画面ＨＧ２は、ユーザが予約をした番組のインデックスの役割を果たしている。確認画面ＨＧ２の中の「未」はその番組がまだ録画されていないことを示し、「済」は録画済みであることを示している。端末装置３が管理サーバ１０から録画の完了の通知を受けると、その番組の「未」の表示は「済」に更新される。
【００３８】
ユーザは、視聴したい番組に対応する再生ボタンＢＮ２１をクリックする。すると、図４の録画データ送信部１０６は、クリックされた再生ボタンＢＮ２１に対応する番組録画データ８０を録画データ記憶部１Ｄ２から抽出し、ストリーミング配信を開始する。このようにして、ユーザは、管理サーバ１０に録画しておいた番組をいつでも好きなときに視聴することができる。
【００３９】
なお、各番組録画データ８０にその番組のカテゴリを示すカテゴリ情報を付けておいてもよい。この場合は、図６の確認画面ＨＧ２の各再生ボタンＢＮ２１は、カテゴリごとにグループ化されて配置される。
【００４０】
次に、第一の実施形態における管理サーバ１０の処理の流れを、図７に示すフローチャートを参照して説明する。図７に示すように、管理サーバ１０は、配信予定の番組の一覧表を端末装置３に配布する（＃１１）。一覧表は、配信の予定に変更があったときなどに生成され、配布される。
【００４１】
図５に示す予約フォーム画面ＨＧ１において入力された予約録画情報７４を端末装置３から取得し、番組の記録（録画）の予約を受け付ける（＃１２）。予約録画情報７４に示される時間帯に近づくと、番組を配信するデータ配信サーバ２に接続し、ストリーミング配信されるデータの受信を開始する（＃１３）。そして、予約録画情報７４に示される時間帯の分のデータを、番組録画データ８０として記録し保存する（＃１４）。
【００４２】
ユーザから再生の指令を受けると（図６参照）、指令された番組録画データ８０を録画データ記憶部１Ｄ２から抽出し、そのユーザの端末装置３にストリーミング配信する（＃１５）。
【００４３】
本実施形態によると、ストリーミング配信される番組を管理サーバ１０に記録しておくことができるので、ユーザは、ライブ中継の番組であっても自分の好きなときに番組を観ることができる。また、時間帯を指定し、番組の一部分のみを記録することができる。
【００４４】
本実施形態では端末装置３において図５に示すように番組名とサーバ名とを指定したが、番組名だけを指定するように構成してもよい。この場合は、管理サーバ１０は、端末装置３において指定された番組名を配信予定記憶部１Ｄ１に記憶されている各データ配信サーバ２Ｌの配信予定情報７１と照らし合わすことによって、その番組を配信する予定があるデータ配信サーバ２Ｌを判別する。そして、上に述べたデータ受信部１０５などによる処理を行い、番組録画データ８０を生成する。
【００４５】
家庭用ビデオの録画予約に用いられるＧコード（ジェムスタコード）のように、番組ごとにその配信元および時間帯を識別する識別情報を発行し、端末装置３に送信してもよい。これにより、ユーザは、日常使用している家庭用ビデオと同じような感覚で録画の予約を行うことができる。
【００４６】
一定期間経過しても再生の指令がない場合は、番組録画データ８０を削除してもよいか否かをユーザに問い合わせるようにしてもよい。
〔第二の実施形態〕
図８はデータ配信サーバ２Ｖのハードウェア構成の例を示す図、図９は管理サーバ１０Ｂの機能的構成の例を説明する図、図１０はトラフィック一覧画面ＨＧ６の例を示す図、図１１は接続予約画面ＨＧ７の例を示す図、図１２は管理サーバ１０Ｂの処理の流れの例を説明するフローチャートである。
【００４７】
第一の実施形態のストリーミング配信システム１は、ライブ配信されるマルチメディアコンテンツ（番組）を管理サーバ１０に記録（録画）しておき、ユーザの好きなときに視聴するためのシステムであった。本実施形態のストリーミング配信システム１Ｂは、データ配信サーバ２（ストリーミングサーバ）へのアクセスの集中などが原因でマルチメディアコンテンツの配信が受けられない場合に、そのデータ配信サーバ２の使用の予約を行うためのシステムである。
【００４８】
予約の方法は２種類ある。第一の予約方法は、使用を希望するデータ配信サーバ２および時間帯の指定を受け付け、そのユーザの端末装置３とそのデータ配信サーバ２との接続を確保するために、指定された時間帯付近における他のユーザの端末装置３とそのデータ配信サーバ２との接続を制限する方法である。第二の予約方法は、データ配信サーバ２のみの指定を受け付け、そのデータ配信サーバ２の通信の混雑が解消したらその旨をユーザに知らせる方法である。
【００４９】
ストリーミング配信システム１Ｂは、図１に示す第一の実施形態のストリーミング配信システム１と同様に構成される。すなわち、ストリーミング配信システム１Ｂにはライブ配信を行うデータ配信サーバ２ＬとＶｏＤ配信を行うデータ配信サーバ２Ｖとが設けられており、ユーザはこれらのデータ配信サーバ２から種々の番組の提供を得ることができる。
【００５０】
管理サーバ１０Ｂのハードウェア構成は、図３に示す管理サーバ１０のハードウェア構成と同様である。ただし、磁気記憶装置１０ｄには、ストリーミング管理用アプリケーションおよびストリーミングサーバ用アプリケーションの代わりに、データ配信サーバ２の通信を制御するプログラム、メール送信プログラム、および課金用プログラムなどがインストールされている。
【００５１】
データ配信サーバ２Ｖは、図８に示すように構成される。ただし、磁気記憶装置２ｄには、ＯＳおよびストリーミングサーバ用アプリケーションのほか、ＶｏＤ配信するためのマルチメディアファイルＭＦＬなどが記憶されている。
【００５２】
このような構成により、管理サーバ１０Ｂは、図９に示すように、トラフィック監視部１２１、トラフィック一覧生成部１２２、トラフィック一覧送信部１２３、第一の接続予約受付部１２４、接続制御部１２５、コンテンツ情報送信部１２６、課金処理部１２７、第二の接続予約受付部１３１、接続可否判別部１３２、接続可能通知部１３３、トラフィック情報記憶部１Ｄ６、および接続予約記憶部１Ｄ７などの機能が実現される。
【００５３】
トラフィック監視部１２１は、各データ配信サーバ２の現在の通信の混雑の状態すなわちトラフィックを監視する。例えば、データ配信サーバ２において送受信されるデータ量を監視する。または、現在データ配信サーバ２に接続されている端末装置３の数を監視し、トラフィックを推測してもよい。監視の結果は、データ配信サーバ２ごとにトラフィック情報７６としてトラフィック情報記憶部１Ｄ６に記憶される。
【００５４】
トラフィック一覧生成部１２２は、各データ配信サーバ２のトラフィック情報７６に基づいてトラフィック一覧情報７７を生成する。生成されたトラフィック一覧情報７７は、トラフィック一覧送信部１２３によって端末装置３に送信される。
【００５５】
トラフィック一覧情報７７を受信した端末装置３には、図１０に示すようなトラフィック一覧画面ＨＧ６が表示される。例えば、トラフィック一覧画面ＨＧ６の中の「８０／１００Ｍｂｐｓ」という情報は、ストリーミングサーバＡ（データ配信サーバ２Ｌ１）のトラフィックの状況を示している。すなわち、分母の値は、そのストリーミングサーバが１秒当たりに通信可能な最大データ量すなわち最高通信速度を示している。分子の値は、そのストリーミングサーバで現在行われている通信の１秒当たりのデータ量を示している。データ量の単位は、メガビットである。
【００５６】
または、トラフィックの状況を「８０／１００本」のように示してもよい。すなわち、それぞれの端末装置３との接続ごとに１Ｍｂｐｓ分ずつ通信回線を割り当てる。１Ｍｂｐｓ分の通信回線を１つのチャンネルと仮想する。すると、ストリーミングサーバＡは１００本の通信回線（チャンネル）を有していることになり、「８０／１００本」という表示はそのうちの８０本が使用中であることを示すことになる。
【００５７】
ストリーミングサーバＣのトラフィックの表示は「１００／１００Ｍｂｐｓ」である。したがって、ストリーミングサーバＣの通信回線は混雑しており、これ以上多くの端末装置３をストリーミングサーバＣに接続することができないことが分かる。このような場合は、「混雑中！」などの警告メッセージを表示し、ユーザに分かりやすくする。ユーザは、混雑しているストリーミングサーバ（データ配信サーバ２）に接続したい場合は、管理サーバ１０Ｂに対して予約を依頼しなければならない。予約は、次のような手順で行われる。
【００５８】
まず、予約の対象のデータ配信サーバ２に対応する選択ボタンＢＮ６１をクリックする。すると、図１１に示すような接続予約画面ＨＧ７が表示される。テキストボックスＴＸ７１に使用帯域を入力し、テキストボックスＴＸ７２に使用する時間帯を入力する。本実施形態において、「使用帯域」とは、そのユーザの端末装置３とデータ配信サーバ２とが接続した際に確保される通信速度の範囲を意味する。図１１の場合は、ユーザは、０〜１Ｍｂｐｓの範囲の通信速度を確保するように要求している。そして、ユーザが予約ボタンＢＮ７１をクリックすると、テキストボックスＴＸ７１、７２に入力された内容、予約対象のサーバ名、およびユーザ名などが第一の予約情報７８として管理サーバ１０Ｂに送信される。
【００５９】
図９に戻って、端末装置３から送信された第一の予約情報７８は、第一の接続予約受付部１２４によって受け付けられ、接続予約記憶部１Ｄ７に記憶される。なお、使用帯域は、一人のユーザが通信を独占しないようにするために所定の値に固定しておくのが望ましい。または、所定の値以下しか指定できないように制限しておいてもよい。
【００６０】
接続制御部１２５は、第一の予約情報７８およびトラフィック情報７６に基づいてデータ配信サーバ２と端末装置３との接続の制御を行う。係る制御は、例えば、次のような手順で行われる。
【００６１】
例えば、データ配信サーバ２Ｖ１と各端末装置３との接続の制御を行う場合は、まず、接続予約記憶部１Ｄ７の中からデータ配信サーバ２Ｖ１に対応する第一の予約情報７８を抽出する。同時に、データ配信サーバ２Ｖ１のトラフィック情報７６を取得する。これにより、データ配信サーバ２Ｖ１の予約の状況および現在のトラフィックの状況が分かる。
【００６２】
抽出された第一の予約情報７８の時間帯（図１１のテキストボックスＴＸ７２に入力された時間帯）およびトラフィック情報７６に示される混雑の具合に基づいて、これからの混雑の具合を予測する。例えば、現在の時刻が２０時３０分であり、図１１に示す内容と同じ予約（使用帯域＝１Ｍｂｐｓ、時間帯＝２１：００〜２２：００を指定した予約）が１０件あり、現在のトラフィックの状況が８０／１００Ｍｂｐｓであるとする。
【００６３】
この場合は、現在のトラフィックの状況より、あと２０Ｍｂｐｓ分の端末装置３の接続が可能であることが分かる。しかし、１Ｍｂｐｓの予約が１０件あるので、現在のトラフィックの状況のまま時間が経過すると、２１時前後には、予約をした端末装置３とデータ配信サーバ２Ｖ１との通信が順次開始されるので、トラフィックの状況が９０／１００Ｍｂｐｓであると予測できる。
【００６４】
そこで、接続制御部１２５は、データ配信サーバ２Ｖ１に対して、９０Ｍｂｐｓになるまではすべての端末装置３からの接続の要求を受け付けてもよいが、９０Ｍｂｐｓを超えた場合は予約を行った端末装置３以外からの接続は拒否するように指令する。このようにして、予約を行った端末装置３とデータ配信サーバ２Ｖ１との接続のための通信回線を確保することができる。
【００６５】
なお、現在接続中の各端末装置３の接続時間などに基づいて接続を終了する端末装置３の台数を予測し、この予測結果をデータ配信サーバ２のトラフィックの状況の予測に用いてもよい。その他、種々の公知の手法を用いて接続の制御を行ってもよい。
【００６６】
コンテンツ情報送信部１２６は、図４に示す第一の実施形態の管理サーバ１０における配信予定受信部１０１、配信予定記憶部１Ｄ１、予定一覧生成部１０２、および予定一覧送信部１０３などと同様の処理を行う。つまり、ライブ配信の番組一覧表（図５参照）およびＶｏＤ配信可能なマルチメディアコンテンツの一覧表を生成し、端末装置３に送信する。
【００６７】
課金処理部１２７は、第一の接続予約受付部１２４によって接続の予約が受け付けられたときに、指定された時間帯および使用帯域（図１１参照）に基づいて予約手数料を徴収するための処理を行う。例えば、クレジットカード会社または銀行などのシステムに接続し、課金の処理を行う。請求書を発行し、ユーザに送付するようにしてもよい。
【００６８】
次に、第二の予約方法について説明する。図１１に示す接続予約画面ＨＧ７において空き通知ボタンＢＮ７２がクリックされると、予約の対象のストリーミングサーバ（データ配信サーバ２）のサーバ名が第二の予約情報７９として管理サーバ１０Ｂに送信される。第二の予約方法では、使用帯域および時間帯を指定する必要はない。
【００６９】
図９に示す第二の接続予約受付部１３１によって第二の予約情報７９が受け付けられると、接続可否判別部１３２は、第二の予約情報７９に示されるデータ配信サーバ２のトラフィック情報７６を参照し、データ配信サーバ２の混雑が解消したか否かを判別する。混雑が解消していないと判別した場合は、所定の時間（例えば１分）が経過した後、最新のトラフィック情報７６を取得し直し、再度判別を行う。
【００７０】
接続可否判別部１３２によって混雑が解消したと判別された場合は、接続可能通知部１３３は、予約を行ったユーザに対して混雑が解消した旨の通知を行う。例えば、ユーザの電子メールアドレスに電子メールを送信することによって通知を行う。電子メールアドレスは、端末装置３に設定されたものに限らず、ユーザの携帯電話に設定されたものを用いてもよい。これにより、ユーザは、データ配信サーバ２への接続を何度もリトライする必要がなくなるので、混雑が解消するまで自由に過ごすことができる。
【００７１】
このとき、接続制御部１２５によって、予約を行ったユーザの端末装置３とデータ配信サーバ２との接続を確保しておいてもよい。この場合は、課金処理部１２７によって課金処理を行う。電子メールによる通知だけを行う場合は、課金処理は行わなくてもよい。
【００７２】
次に、第二の実施形態における管理サーバ１０Ｂの処理の流れを、図１２に示すフローチャートを参照して説明する。図１２に示すように、管理サーバ１０Ｂは、各データ配信サーバ２のトラフィックの状況を示すトラフィックの一覧（図１０参照）を端末装置３に配布する（＃２１）。トラフィックの状況は常に変化しているので、トラフィック一覧表は頻繁に更新され、端末装置３に配布される。
【００７３】
端末装置３とデータ配信サーバ２との接続の予約情報を受け付ける（＃２２）。受け付けた予約情報が第一の予約情報７８である場合は（＃２３でＹｅｓ）、課金の処理を行い（＃２４）、指定された時間帯にユーザの端末装置３がデータ配信サーバ２に接続できるように、各端末装置３とデータ配信サーバ２との接続の制御を行う（＃２５）。すなわち、予約のない端末装置３とデータ配信サーバ２との接続を制限し予約のある端末装置３とデータ配信サーバ２との接続のための通信回線を確保するように、データ配信サーバ２に対して指令する。
【００７４】
予約情報にデータ配信サーバ２を使用する時間帯を示す情報が含まれていない場合は（＃２３でＮｏ）、そのデータ配信サーバ２の混雑が解消されるまでトラフィックを監視する（＃２６）。混雑が解消されたと判別された場合は（＃２６でＹｅｓ）、データ配信サーバ２への接続が可能になった旨の電子メールをユーザに送信する（＃２７）。
【００７５】
本実施形態によると、現在管理されているストリーミングサーバの使用状況がグラフィカルに表示される。よって、ユーザは、各ストリーミングサーバの混雑を一目で確認することができるので、番組を快適に観ることができるのか、または今はストリーミングサーバへの避けたほうがよいのか、という選択を簡単に行うことができる。
【００７６】
ストリーミングサーバが混雑している場合は、ユーザは予約を行い、自分の端末装置とストリーミングサーバとの接続を確保することができる。これにより、ストリーミング配信を円滑にすることができる。また、トラフィックの混雑が解消した旨をユーザに通知するので、接続のリトライの繰り返しなどの無駄な通信をなくし、ストリーミング配信を円滑にすることができる。
【００７７】
図１に示すように、データ配信サーバ２および管理サーバ１０、１０Ｂとしてそれぞれ別々のサーバ機を用いたが、１台のサーバ機によってデータ配信サーバ２および管理サーバ１０の処理を行うように構成してもよい。または、管理サーバ１０、１０Ｂを複数台のサーバ機で構成してもよい。
【００７８】
その他、ストリーミング配信システム１、管理サーバ１０、１０Ｂ、データ配信サーバ２、端末装置３の全体または各部の構成、表示画面、処理内容、処理順序などは、本発明の趣旨に沿って適宜変更することができる。
【００７９】
【発明の効果】
本発明によると、ストリーミング配信を円滑にすることができる。
【図面の簡単な説明】
【図１】本発明に係るストリーミング配信システムの構成の例を示す図である。
【図２】データ配信サーバのハードウェア構成の例を示す図である。
【図３】管理サーバのハードウェア構成の例を示す図である。
【図４】管理サーバの機能的構成の例を説明する図である。
【図５】予約フォーム画面の例を示す図である。
【図６】確認画面の例を示す図である。
【図７】管理サーバの処理の流れの例を説明するフローチャートである。
【図８】データ配信サーバのハードウェア構成の例を示す図である。
【図９】管理サーバの機能的構成の例を説明する図である。
【図１０】トラフィック一覧画面の例を示す図である。
【図１１】接続予約画面の例を示す図である。
【図１２】管理サーバの処理の流れの例を説明するフローチャートである。
【符号の説明】
１、１Ｂ  ストリーミング配信システム
１０、１０Ｂ  管理サーバ
２  データ配信サーバ（ストリーミングサーバ）
１０２  予定一覧生成部（一覧情報生成手段）
１０４  録画予約受付部（指定情報取得手段）
１０５  データ受信部（データ受信手段）
１０６  録画データ送信部（データ送信手段）
１Ｄ１  配信予定記憶部１Ｄ１（予定情報記憶手段）
１Ｄ２  録画データ記憶部（番組データ保存手段）
１２１  トラフィック監視部（トラフィック情報取得手段）
１２２  トラフィック一覧生成部（トラフィック一覧生成手段）
１２４  第一の接続予約受付部（予約受付手段）
１２５  接続制御部（接続制御手段、予測情報生成手段）
１３１  第二の接続予約受付部（要求取得手段）
１３２  接続可否判別部（判別手段）
１３３  接続可能通知部（通知手段）
７４  予約録画情報（サーバ指定情報、時間帯指定情報、番組指定情報）
７６  トラフィック情報
７８  第一の予約情報（サーバ指定情報、時間帯指定情報）
７９  第二の予約情報
【図１】
0004338357.tif 000002
【図２】
0004338357.tif 000003
【図３】
0004338357.tif 000004
【図４】
0004338357.tif 000005
【図５】
0004338357.tif 000006
【図６】
0004338357.tif 000007
【図７】
0004338357.tif 000008
【図８】
0004338357.tif 000009
【図９】
0004338357.tif 000010
【図１０】
0004338357.tif 000011
【図１１】
0004338357.tif 000012
【図１２】
0004338357.tif 000013