(57)【要約】【課題】動画コラボレーション利用時における輻輳の発生時に、全ユーザに対するサービスの停止を行うことなく継続的にサービスを提供することができる輻輳制御方法、輻輳制御システム、及び、輻輳制御プログラムの提供。【解決手段】動画のコンテンツを配信するサーバ２００と、動画を再生し、当該動画に対応する音声データをサーバ２００に送信するユーザ端末３９０とがネットワーク１００を介して接続する輻輳制御システム１において、サーバ２００が、サーバ２００内の輻輳発生箇所の輻輳の発生確率を示す輻輳度情報を取得し、取得した発生確率が所定の閾値以上と判定した場合、ユーザ端末３９０から新規に受信するサービス要求のうち、輻輳発生箇所に対するサービス要求の受け入れを制限し、他のサービス要求を受け入れる。【選択図】図１
2009266093.tif 000002
【特許請求の範囲】
【請求項１】
動画を記憶する記憶手段を備え、当該動画を配信するサーバと、当該動画を再生し、当該動画に対応する音声データを前記サーバに送信する端末とがネットワークを介して接続する輻輳制御システムにおける輻輳制御方法であって、
前記サーバが、
当該サーバ内における輻輳発生箇所の輻輳の発生確率Ｘ（０≦Ｘ≦１００）を示す輻輳度情報を取得する輻輳度情報取得過程と、
取得した前記輻輳度情報の発生確率Ｘと、所定の閾値Ｘ１（０＜Ｘ１≦１００）とを比較し、前記発生確率Ｘが前記閾値Ｘ１以上と判定した場合、前記端末から新規に受信するサービス要求のうち、当該輻輳発生箇所に対するサービス要求の受け入れを制限し、他のサービス要求を受け入れる輻輳制御過程と
を有することを特徴とする輻輳制御方法。
【請求項２】
動画を記憶する記憶手段を備え、当該動画を配信するサーバと、当該動画を再生し、当該動画に対応する音声データを前記サーバに送信する端末とがネットワークを介して接続する輻輳制御システムであって、
前記サーバは、
当該サーバ内における輻輳発生箇所の輻輳の発生確率Ｘ（０≦Ｘ≦１００）を示す輻輳度情報を取得する輻輳度情報取得手段と、
前記輻輳度情報取得手段が取得する前記輻輳度情報の発生確率Ｘと、所定の閾値Ｘ１（０＜Ｘ１≦１００）とを比較し、前記発生確率Ｘが前記閾値Ｘ１以上と判定した場合、前記端末から新規に受信するサービス要求のうち、当該輻輳発生箇所に対するサービス要求の受け入れを制限し、他のサービス要求を受け入れる輻輳制御手段と
を備えることを特徴とする輻輳制御システム。
【請求項３】
前記サーバ内の前記輻輳発生箇所は、複数箇所であり、
前記サーバは、
複数の前記輻輳発生箇所ごとの複数の前記輻輳度情報取得手段を備え、
前記輻輳制御手段は、前記輻輳発生箇所ごとに、前記輻輳度情報取得手段から取得する前記発生確率Ｘと、前記輻輳発生箇所ごとの複数の閾値Ｘ１のうち、当該輻輳発生箇所に対応する閾値Ｘ１とを比較し、当該発生確率Ｘが当該閾値Ｘ１以上と判定した場合、前記端末から新規に受信するサービス要求のうち、当該輻輳発生箇所に対するサービス要求の受け入れを制限し、他のサービス要求を受け入れる
ことを特徴とする請求項２に記載の輻輳制御システム。
【請求項４】
前記サーバの前記輻輳発生箇所は、
前記サーバが備える通信手段であり、
前記輻輳度情報取得手段は、
所定時間あたりに前記通信手段が送信可能なデータ送信量に対する当該通信手段の所定時間あたりに送信したデータ送信量の割合を算出し、算出した値を前記発生確率Ｘとして輻輳度情報を取得する
ことを特徴とする請求項２又は３のいずれかに記載の輻輳制御システム。
【請求項５】
前記サーバの前記輻輳発生箇所は、
前記サーバが備える通信手段であり、
前記輻輳度情報取得手段は、
所定時間あたりに前記通信手段が受信可能なデータ受信量に対する当該通信手段の所定時間あたりに受信したデータ受信量の割合を算出し、算出した値を前記発生確率Ｘとして輻輳度情報を取得する
ことを特徴とする請求項２から４のいずれかに記載の輻輳制御システム。
【請求項６】
前記サーバの前記輻輳発生箇所は、
前記サーバが備える記憶手段へのアクセスであり、
前記輻輳度情報取得手段は、
所定時間あたりに前記記憶手段が受信可能なデータ受信量に対する当該記憶手段の当該所定時間あたりに発生したアクセス数の割合を算出し、算出した値を前記発生確率Ｘとして輻輳度情報を取得する
ことを特徴とする請求項２から５のいずれかに記載の輻輳制御システム。
【請求項７】
前記サーバの前記輻輳発生箇所は、
前記サーバが備えるＣＰＵであり、
前記輻輳度情報取得手段は、
前記ＣＰＵのＣＰＵ使用率を示す情報を前記発生確率Ｘとして輻輳度情報を取得し、
前記輻輳制御手段は、
前記輻輳度情報取得手段から取得する輻輳度情報のＣＰＵ使用率である前記発生確率Ｘと、前記閾値Ｘ１とを比較し、当該発生確率Ｘが当該閾値Ｘ１以上と判定した場合、前記端末から新規に受信するサービス要求の受け入れを制限する
ことを特徴とする請求項２から６のいずれかに記載の輻輳制御システム。
【請求項８】
前記輻輳制御手段は、
前記輻輳度情報取得手段から取得する輻輳度情報の前記発生確率Ｘと前記閾値Ｘ１とを比較し、前記発生確率Ｘが前記閾値Ｘ１以上と判定した場合、当該発生確率Ｘと所定の閾値Ｘ２（０＜Ｘ１＜Ｘ２≦１００）とを比較し、
前記発生確率Ｘが前記閾値Ｘ２以上と判定した場合、前記端末から新規に受信するサービス要求のうち、当該輻輳発生箇所に対するサービス要求の受け入れを全て拒否し、
前記発生確率Ｘが前記閾値Ｘ１以上、かつ、前記閾値Ｘ２未満であると判定した場合、当該輻輳発生箇所に対するサービス要求の受け入れを制限し、他のサービス要求を受け入れる輻輳制御手段と
を備えることを特徴とする請求項２から７のいずれかに記載の輻輳制御システム。
【請求項９】
前記輻輳制御手段によるサービス要求の受け入れの制限は、
制限対象となるサービス要求の送信元、又は、サービス要求対象のファイルのファイルサイズに応じて異なる確率で要求を拒否することにより制限処理を行う
ことを特徴とする請求項２から８のいずれかに記載の輻輳制御システム。
【請求項１０】
前記端末は、
前記サーバから配信される前記動画のファイルを受信し、当該動画のファイルに対する音声データを前記サーバに送信する通信手段と、
前記通信手段が受信する前記動画のファイルを一次的に記憶するダウンロード用バッファ手段と、
前記通信手段が送信する前記音声データのファイルを一次的に記憶するアップロード用バッファ手段と、
輻輳制御手段とを備え、
当該輻輳制御手段は、予め定められる所定の周期ごとにダウンロード用バッファのメモリ使用量を示す情報を取得し、
当該ダウンロード用バッファ手段のメモリ使用量が零の場合、前記動画のファイルの再生処理を中止させ、前記音声データのエンコード処理を中止させ、
当該ダウンロード用バッファ手段のメモリ使用量が零ではない場合、当該動画の再生処理と、前記音声データのエンコード処理とを再開、又は、継続させ、
予め定められる所定の周期ごとにアップロード用バッファ手段のメモリ空き容量を示す情報を取得し、当該アップロード用バッファ手段のメモリ空き容量が零の場合、前記動画の再生処理と、前記音声データのエンコードとを中止させ、
当該アップロード用バッファ手段のメモリ空き容量が零ではない場合、当該動画の再生処理と、前記音声データのエンコード処理とを再開、又は、継続させる
ことを特徴とする請求項２から９のいずれかに記載の輻輳制御システム。
【請求項１１】
動画を記憶する記憶手段を備え、当該動画を配信するサーバと、当該動画を再生し、当該動画に対応する音声データを前記サーバに送信する端末とがネットワークを介して接続する輻輳制御システムにおける前記サーバに用いられるコンピュータを、
当該サーバ内における輻輳発生箇所の輻輳の発生確率Ｘ（０≦Ｘ≦１００）を示す輻輳度情報を取得する輻輳度情報取得手段、
前記輻輳度情報取得手段が取得する前記輻輳度情報の発生確率Ｘと、所定の閾値Ｘ１（０＜Ｘ１≦１００）とを比較し、前記発生確率Ｘが前記閾値Ｘ１以上と判定した場合、前記端末から新規に受信するサービス要求のうち、当該輻輳発生箇所に対するサービス要求の受け入れを制限し、他のサービス要求を受け入れる輻輳制御手段
として機能させることを特徴とする輻輳制御プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークを介した複数のユーザ間の動画ファイルの再生における音声データの共有時における輻輳を制御する輻輳制御方法、輻輳制御システム、及び、輻輳制御プログラムに関する。
【背景技術】
【０００２】
近年、ネットワークを介して共有する動画ファイルを視聴する際、複数のユーザによって同一の動画ファイルの時間軸に合わせてチャット等の文字コミュニケーションを行う技術がある（例えば、非特許文献１、非特許文献２）。
【非特許文献１】ウィキペディア，[online]，[平成２０年３月１１日]、インターネット<URL:http://ja.wikipedia.org/wiki/YouTube>
【非特許文献２】ウィキペディア，[online]，[平成２０年３月１１日]、インターネット<URL:http://ja.wikipedia.org/wiki/ニコニコ動画>
【発明の開示】
【発明が解決しようとする課題】
【０００３】
しかしながら、これらの動画コラボレーション実施時に、ネットワーク及び各種装置の輻輳が発生した場合、一部の動画ファイルへのアクセス集中など、サービス全体の一部分が輻輳の発生要因であっても、サービス全体が停止してしまう場合があるという問題がある。
【０００４】
本発明は、このような事情を考慮し、上記の問題を解決すべくなされたもので、その目的は、動画コラボレーション利用時における輻輳の発生時に、全ユーザに対するサービスの停止を行うことなく継続的にサービスを提供することができる輻輳制御方法、輻輳制御システム、及び、輻輳制御プログラムを提供することにある。
【課題を解決するための手段】
【０００５】
上記問題を解決するために、本発明の輻輳制御方法は、動画を記憶する記憶手段を備え、当該動画を配信するサーバと、当該動画を再生し、当該動画に対応する音声データをサーバに送信する端末とがネットワークを介して接続する輻輳制御システムにおける輻輳制御方法であって、サーバが、当該サーバ内における輻輳発生箇所の輻輳の発生確率Ｘ（０≦Ｘ≦１００）を示す輻輳度情報を取得し、取得した輻輳度情報の発生確率Ｘと、所定の閾値Ｘ１（０＜Ｘ１≦１００）とを比較し、発生確率Ｘが閾値Ｘ１以上と判定した場合、端末から新規に受信するサービス要求のうち、当該輻輳発生箇所に対するサービス要求の受け入れを制限し、他のサービス要求を受け入れることを特徴とする輻輳制御方法である。
【０００６】
本発明の輻輳制御システムは、動画を記憶する記憶手段を備え、当該動画を配信するサーバと、当該動画を再生し、当該動画に対応する音声データをサーバに送信する端末とがネットワークを介して接続する輻輳制御システムであって、サーバが、当該サーバ内における輻輳発生箇所の輻輳の発生確率Ｘ（０≦Ｘ≦１００）を示す輻輳度情報を取得する輻輳度情報取得手段と、輻輳度情報取得手段が取得する輻輳度情報の発生確率Ｘと、所定の閾値Ｘ１（０＜Ｘ１≦１００）とを比較し、発生確率Ｘが閾値Ｘ１以上と判定した場合、端末から新規に受信するサービス要求のうち、当該輻輳発生箇所に対するサービス要求の受け入れを制限し、他のサービス要求を受け入れる輻輳制御手段とを備えることを特徴とする輻輳制御システムである。
【０００７】
また、本発明の輻輳制御システムは、サーバ内の輻輳発生箇所が、複数箇所であり、サーバが、複数の輻輳発生箇所ごとの複数の輻輳度情報取得手段を備え、輻輳制御手段が、輻輳発生箇所ごとに、輻輳度情報取得手段から取得する発生確率Ｘと、輻輳発生箇所ごとの複数の閾値Ｘ１のうち、当該輻輳発生箇所に対応する閾値Ｘ１とを比較し、当該発生確率Ｘが当該閾値Ｘ１以上と判定した場合、端末から新規に受信するサービス要求のうち、当該輻輳発生箇所に対するサービス要求の受け入れを制限し、他のサービス要求を受け入れることを特徴とする。
【０００８】
また、本発明の輻輳制御システムは、サーバの輻輳発生箇所が、サーバが備える通信手段であり、輻輳度情報取得手段が、所定時間あたりに通信手段が送信可能なデータ送信量に対する当該通信手段の所定時間あたりに送信したデータ送信量の割合を算出し、算出した値を発生確率Ｘとして輻輳度情報を取得することを特徴とする。
【０００９】
また、本発明の輻輳制御システムは、サーバの輻輳発生箇所が、サーバが備える通信手段であり、輻輳度情報取得手段が、所定時間あたりに通信手段が受信可能なデータ受信量に対する当該通信手段の所定時間あたりに受信したデータ受信量の割合を算出し、算出した値を発生確率Ｘとして輻輳度情報を取得することを特徴とする。
【００１０】
また、本発明の輻輳制御システムは、サーバの輻輳発生箇所が、サーバが備える記憶手段へのアクセスであり、輻輳度情報取得手段が、所定時間あたりに記憶手段が受信可能なデータ受信量に対する当該記憶手段の当該所定時間あたりに発生したアクセス数の割合を算出し、算出した値を発生確率Ｘとして輻輳度情報を取得することを特徴とする。
【００１１】
また、本発明の輻輳制御システムは、サーバの輻輳発生箇所が、サーバが備えるＣＰＵであり、輻輳度情報取得手段が、ＣＰＵのＣＰＵ使用率を示す情報を発生確率Ｘとして輻輳度情報を取得し、輻輳制御手段が、輻輳度情報取得手段から取得する輻輳度情報のＣＰＵ使用率である発生確率Ｘと、閾値Ｘ１とを比較し、当該発生確率Ｘが当該閾値Ｘ１以上と判定した場合、端末から新規に受信するサービス要求の受け入れを制限することを特徴とする。
【００１２】
また、本発明の輻輳制御システムは、輻輳制御手段が、輻輳度情報取得手段から取得する輻輳度情報の発生確率Ｘと閾値Ｘ１とを比較し、発生確率Ｘが閾値Ｘ１以上と判定した場合、当該発生確率Ｘと所定の閾値Ｘ２（０＜Ｘ１＜Ｘ２≦１００）とを比較し、発生確率Ｘが閾値Ｘ２以上と判定した場合、端末から新規に受信するサービス要求のうち、当該輻輳発生箇所に対するサービス要求の受け入れを全て拒否し、発生確率Ｘが閾値Ｘ１以上、かつ、閾値Ｘ２未満であると判定した場合、当該輻輳発生箇所に対するサービス要求の受け入れを制限し、他のサービス要求を受け入れる輻輳制御手段とを備えることを特徴とする。
【００１３】
また、本発明の輻輳制御システムは、輻輳制御手段によるサービス要求の受け入れの制限が、制限対象となるサービス要求の送信元、又は、サービス要求対象のファイルのファイルサイズに応じて異なる確率で要求を拒否することにより制限処理を行うことを特徴とする。
【００１４】
また、本発明の輻輳制御システムは、端末が、サーバから配信される動画のファイルを受信し、当該動画のファイルに対する音声データをサーバに送信する通信手段と、通信手段が受信する動画のファイルを一次的に記憶するダウンロード用バッファ手段と、通信手段が送信する音声データのファイルを一次的に記憶するアップロード用バッファ手段と、輻輳制御手段とを備え、当該輻輳制御手段が、予め定められる所定の周期ごとにダウンロード用バッファのメモリ使用量を示す情報を取得し、当該ダウンロード用バッファ手段のメモリ使用量が零の場合、動画のファイルの再生処理を中止させ、音声データのエンコード処理を中止させ、当該ダウンロード用バッファ手段のメモリ使用量が零ではない場合、当該動画の再生処理と、音声データのエンコード処理とを再開、又は、継続させ、予め定められる所定の周期ごとにアップロード用バッファ手段のメモリ空き容量を示す情報を取得し、当該アップロード用バッファ手段のメモリ空き容量が零の場合、動画の再生処理と、音声データのエンコードとを中止させ、当該アップロード用バッファ手段のメモリ空き容量が零ではない場合、当該動画の再生処理と、音声データのエンコード処理とを再開、又は、継続させることを特徴とする。
【００１５】
また、本発明は、輻輳制御プログラムであって、動画を記憶する記憶手段を備え、当該動画を配信するサーバと、当該動画を再生し、当該動画に対応する音声データをサーバに送信する端末とがネットワークを介して接続する輻輳制御システムにおけるサーバに用いられるコンピュータを、当該サーバ内における輻輳発生箇所の輻輳の発生確率Ｘ（０≦Ｘ≦１００）を示す輻輳度情報を取得する輻輳度情報取得手段、輻輳度情報取得手段が取得する輻輳度情報の発生確率Ｘと、所定の閾値Ｘ１（０＜Ｘ１≦１００）とを比較し、発生確率Ｘが閾値Ｘ１以上と判定した場合、端末から新規に受信するサービス要求のうち、当該輻輳発生箇所に対するサービス要求の受け入れを制限し、他のサービス要求を受け入れる輻輳制御手段として機能させることを特徴とする輻輳制御プログラムである。
【発明の効果】
【００１６】
本発明によれば、動画を配信するサーバと、当該動画を再生し、当該動画に対応する音声データをサーバに送信する端末とがネットワークを介して接続する輻輳制御システムにおいて、サーバが、サーバ内の輻輳発生箇所の輻輳の発生確率を示す輻輳度情報を取得し、取得した発生確率が所定の閾値以上と判定した場合、端末から新規に受信するサービス要求のうち、輻輳発生箇所に対するサービス要求の受け入れを制限し、他のサービス要求を受け入れるようにした。
これにより、サービスを提供するサーバにおいて、輻輳の発生時に、全サービス要求に対する拒否、すなわち、全ユーザに対するサービス停止ではなく、輻輳発生箇所にかかわる新たな要求の一部に対してサービス停止を行うことができ、他のサービスの提供を中断することなく、継続的にサービスを提供することが可能になるという効果がある。
【００１７】
また、この発明によれば、サーバ内の輻輳発生箇所が複数箇所の場合に、サーバが、輻輳発生箇所ごとに、輻輳の発生確率が所定の閾値以上と判定すると、端末から新規に受信するサービス要求のうち、当該輻輳発生箇所に対するサービス要求の受け入れを制限し、他のサービス要求を受け入れるようにした。
これにより、輻輳発生箇所ごとに、輻輳発生箇所に対するサービス要求の受け入れの制限を行うことができ、他のサービス要求を不要に制限することなく輻輳制御処理を行い、サーバが継続してサービスを提供することが可能になるという効果がある。
【発明を実施するための最良の形態】
【００１８】
本発明は、動画ファイルの再生にあわせて、音声を吹き込み、または、吹き込んだ音声を再生し、ネットワークユーザ間でコラボレーションを行うことができる動画コラボレーションに関する。ここで、まず、本発明において前提とする動画コラボレーションの概念について、テレビ放映の視聴とコンサートの鑑賞との比較を用い、説明する。
テレビ放映の視聴は、テレビ局からの配信される放映内容（コンテンツ）を受像し、受像した動画や音声をテレビが再生することにより、エンドユーザがコンテンツを視聴し、楽しむものである。このとき、エンドユーザは、コンテンツを鑑賞するのみであり、コンテンツの鑑賞によってエンドユーザ自らが発する音声や動作を、同じコンテンツを他の場所で同時に視聴している他のエンドユーザに伝えることはできない。
【００１９】
一方、コンサートの鑑賞においては、例えばライブコンサートなど、コンテンツの視聴者（客）は、コンテンツ提供者（演奏者）によるコンテンツの視聴を楽しむだけではなく、コンテンツ提供者とコンテンツの視聴者とが一体となって、コンテンツを楽しむという共有感が提供されている。
したがって、コンサートのコンテンツをテレビにおいて視聴する場合、エンドユーザに対して、コンサート内容について鑑賞する手段が提供されるが、実際のコンサート会場でコンテンツの視聴者に提供される共有感までは提供されないこととなる。
【００２０】
本発明は、複数のユーザが発する音声をコンテンツごとに共有させることにより、例えば、コンサート会場において提供されるような共有感をコンテンツを視聴するエンドユーザに提供する場合において生じる輻輳の制御に関する。以下、本発明における上述のコンテンツに対する音声の共有を動画コラボレーション、又は、音声の共有として説明する。
【００２１】
以下、本発明の一実施形態による輻輳制御システム１を図面を参照して説明する。
図１は、本実施形態による輻輳制御システム１の接続構成を示す概略図である。輻輳制御システム１は、ネットワーク１００を介して接続される動画再生／音声取込装置としてのユーザ端末３９０、及び、動画や、音声などによるコンテンツの配信サービスを提供するサーバ２００とからなる。ネットワーク１００は、電話網、ＩＰ（Internet Protocol）網、インターネットなどの公衆網や、ＬＡＮ（Local Area Network）、専用線などの私設網からなる。
【００２２】
同図において、ユーザ端末３９０は、例えば、パーソナルコンピュータ、ＰＤＡ（Personal Digital Assistants：情報携帯端末）、携帯電話などのコンピュータ端末であり、ブラウザ３００を備え、ネットワーク１００を介してサーバ２００からダウンロード（受信）するコンテンツの再生や、コンテンツ再生時のユーザ４００からの音声入力を受け付け、受け付けた音声をサーバ２００にアップロード（送信）する。
輻輳制御システム１において、輻輳が発生する箇所は以下に示すように、大きく分けてサーバ２００における第１輻輳発生箇所と、ブラウザ３００における第２輻輳発生箇所との２箇所がある。
【００２３】
次に、各装置の内部構成とともに、第１輻輳発生箇所と、第２輻輳発生箇所との詳細について説明する。
図２は、サーバ２００の構成を示すブロック図である。サーバ２００は、通信部２０と、輻輳制御部２１と、ＣＰＵ（Central Processing Unit）２２と、ＤＢ（データベース）２３と、ＣＰＵ使用率チェック機能部２４と、送信ファイルサイズチェック機能部２５と、受信ファイルサイズチェック機能部２６と、ＤＢアクセス負荷チェック機能部２７とを備え、ユーザ端末３９０から受信するコンテンツに関する送受信要求などのサービス要求信号に応じて、動画や、音声のコンテンツの送受信を行う。
【００２４】
サーバ２００において、第１輻輳発生箇所は、通信部２０とＣＰＵ２２とＤＢ２３との３箇所となる。すなわち、通信部２０が送信／受信可能なデータ量を超えてサービス要求信号が集中した場合ａ、ＣＰＵ２２における計算処理能力を超えてサービス要求信号が集中した場合ｂ、ＤＢ２３が対応可能なアクセス量を超えてデータへの読み出し／書き込み要求が集中した場合ｃである。
【００２５】
サーバ２００において、通信部２０は、ネットワーク１００に接続され、ネットワーク１００を介して通信を行う。
輻輳制御部２１は、通信部２０のデータ送信量情報とデータ受信量情報と、ＣＰＵ２２のＣＰＵ使用率情報と、ＤＢ２３へのアクセス負荷量情報とに基づき、通信部２０が受信するサービス要求信号を受け入れるか、拒否するかの判定処理を行う。輻輳制御部２１は、サービス要求信号を受け入れることと判定した場合、ＣＰＵ２２に受信したサービス要求信号を出力し、サービス要求信号を拒否することと判定した場合、拒否することを示す通知を通信部２０からサービス要求信号の送信元へ送信させる。
【００２６】
ＤＢ２３は、動画や、音声などのデータであるコンテンツを、コンテンツごとの識別情報とともに記憶する。ここで、音声のコンテンツとは、ＤＢ２３が記憶するいずれかの動画のコンテンツの視聴の際にユーザによって発せられた音声のデータであり、当該動画のコンテンツの識別情報と、ユーザの発声時の当該動画の再生タイミングを示す情報とが対応付けられた音声コンテンツである。
【００２７】
ＣＰＵ２２は、入力されるサービス要求信号に応じて、コンテンツの読み出し、書き込みなどのＤＢ２３へのアクセス処理を行う。また、ＣＰＵ２２は、動画のコンテンツの読み出し要求に対し、当該動画コンテンツに対応付けられる全ての音声コンテンツについても、動画のコンテンツの識別情報を検索キーとしてＤＢ２３から読み出す。
ＣＰＵ使用率チェック機能部２４は、予め定められる所定の周期ごとにＣＰＵ２２の使用率値を示す値ｘを取得し、取得した使用率ｘをＣＰＵ使用率情報として輻輳制御部２１に出力する。ＣＰＵ使用率チェック機能部２４は、例えば、ＵＭＩＸ（登録商標）における「top」コマンドなどのシステム状況情報を取得するコマンドを用いることでもよいし、ＣＰＵ使用率情報を取得するいずれの方法でも適用可能である。
【００２８】
送信ファイルサイズチェック機能部２５は、予め定められる所定の周期ごとの通信部２０が送信する通信量を示すデータ送信量を示す情報を取得し、取得した送信量情報を輻輳制御部２１に出力する。ここでは、データ送信量情報とは、通信部２０において上記所定の周期あたりに送信可能なデータ量に対する実際に送信したデータ量の割合を百分率（パーセンテージ）で示した値ｙとして説明する。したがって、「ｙ＝１００×（（１周期の間で実際に送信したデータ量）／（１周期の間で通信部２０が送信可能なデータ量））」である。
【００２９】
受信ファイルサイズチェック機能部２６は、予め定められる所定の周期ごとの通信部２０が受信する通信量を示すデータ受信量を示す情報を取得し、取得した受信量情報を輻輳制御部２１に出力する。ここでは、データ受信量情報とは、通信部２０において上記所定の周期あたりに受信可能なデータ量に対する実際に受信したデータ量の割合を百分率（パーセンテージ）で示した値ｚとして説明する。したがって、「ｚ＝１００×（（１周期の間で実際に受信したデータ量）／（１周期の間で通信部２０が受信可能なデータ量））」である。
【００３０】
ＤＢアクセス負荷チェック機能部２７は、予め定められる所定の周期ごとのＤＢ２３に対するデータアクセス負荷量を示す情報を取得し、取得したＤＢアクセス負荷量情報を輻輳制御部２１に出力する。ここでは、ＤＢアクセス負荷量情報とは、ＤＢ２３において上記所定の周期あたりに読み出し／書き込み可能なアクセス量に対する実際のアクセス量の割合を百分率（パーセンテージ）で示した値ｗとして説明する。したがって、「ｗ＝１００×（（１周期の間の実際のアクセス量）／（１周期の間でＤＢ２３が読み出し／書き込み可能なアクセス量））」である。
【００３１】
図３は、ユーザ端末３９０が備えるブラウザ３００の構成を示すブロック図である。ブラウザ３００は、通信部３０と、動画再生機能部３１と、輻輳制御部３２と、ダウンロード用バッファ３５と、アップロード用バッファ３６と、バッファチェック機能部３７と、音声取込機能部３８と、音声エンコード機能部３９とを備え、ネットワーク１００を介してサーバ２００から受信する動画のコンテンツを再生したり、当該再生時におけるユーザ４００による音声データを取りこみ、取り込んだ音声データをサーバ２００に送信したりする。
【００３２】
ブラウザ３００の第２輻輳発生箇所は、ダウンロード用バッファ３５と、アップロード用バッファ３６との２箇所である。すなわち、ダウンロード用バッファ３５に再生対象の動画のコンテンツが一定量記憶されていない場合、当該コンテンツのデータが一定量ダウンロードされるまで、動画再生機能部３１は、動画のコンテンツを再生することができない。また、送信待ちの音声データによってアップロード用バッファ３６のメモリの空き容量がない場合、音声エンコード機能部３９は、音声のエンコードを行うことができない。
【００３３】
ブラウザ３００において、通信部３０は、ネットワーク１００に接続され、通信を行う。動画再生機能部３１は、ユーザ端末３９０が備える図示しないディスプレイなどの画像データの出力部と、スピーカーなどの音声出力部とにより、通信部３０が受信する動画のコンテンツの再生処理を行う。
輻輳制御部３２は、ダウンロード用バッファ３５と、アップロード用バッファ３６とのメモリ使用量に応じて、動画の再生や、音声の取りこみ処理の一時停止、処理再開などの各部の制御を行う。
【００３４】
ダウンロード用バッファ３５は、通信部３０が受信する動画のコンテンツを一時的に記憶する。アップロード用バッファ３６は、通信部３０に送信するユーザ４００による音声データを一時的に記憶する。
バッファチェック機能部３７は、ダウンロード用バッファ３５と、アップロード用バッファ３６とのメモリ使用量を示す情報を予め定められる所定の周期ごとに取得し、取得したメモリ使用量に関する情報を輻輳制御部３２に出力する。
【００３５】
音声取込機能部３８は、例えばマイクなどの音声入力装置であり、ユーザ４００によって発せられる音声入力を受け付け、受け付けた音声を音声エンコード機能部３９に出力する。
音声エンコード機能部３９は、音声取込機能部３８から入力される音声を符号化（エンコード）し、動画再生機能部３１が再生する動画のコンテンツの識別情報と、当該動画再生時における音声入力のタイミングを示す情報とを対応付けた音声データをアップロード用バッファ３６に記憶させ、通信部３０を介してサーバ２００に送信する。
【００３６】
次に、本発明の一実施形態による輻輳制御システム１のサーバ２００における輻輳制御処理について、ＣＰＵ２２と、通信部２０と、ＤＢ２３とのそれぞれに関する輻輳制御処理についてその動作の流れを説明する。
図４は、ＣＰＵ２２のＣＰＵ使用率ｘに基づく輻輳制御処理の流れを示すフローチャートである。サーバ２００において、ＣＰＵ使用率チェック機能部２４は、予め定められる所定の周期ごとにＣＰＵ２２のＣＰＵ使用率ｘの値を取得し、取得したＣＰＵ使用率ｘをＣＰＵ使用率情報として輻輳制御部２１に出力する（ステップＳ１）。
【００３７】
輻輳制御部２１は、ＣＰＵ使用率ｘと、第１閾値ｘ１とを比較し、ＣＰＵ使用率ｘが第１閾値ｘ１以上か否かを判定する（ステップＳ２）。輻輳制御部２１は、ＣＰＵ使用率ｘが第１閾値ｘ１以上ではない、すなわち、ＣＰＵ使用率ｘが第１閾値ｘ１未満（ｘ＜ｘ１）であると判定した場合、ＣＰＵ２２における計算量に余裕があることと判定し、通信部２０が新規に受信するサービス要求信号を全てＣＰＵ２２に出力する（ステップＳ３）。
【００３８】
また、ステップＳ２において、輻輳制御部２１は、ＣＰＵ使用率ｘが第１閾値ｘ１以上で（ｘ１≦ｘ）であると判定した場合、ＣＰＵ使用率ｘと、第２閾値ｘ１（ただし、ｘ１＜ｘ２）とを比較し、ＣＰＵ使用率ｘが第２閾値ｘ１以上か否かを判定する（ステップＳ４）。
【００３９】
輻輳制御部２１は、ＣＰＵ使用率ｘが第２閾値ｘ２以上（ｘ２≦ｘ）であることと判定した場合、ＣＰＵ２２の計算量が処理限界に近づいていることと判定し、通信部２０が新規に受信する全てのサービス要求信号に対し、要求を拒否することを示す要求拒否信号を応答信号としてサービス要求信号の送信元に対し、通信部２０に送信させる（ステップＳ５）。
【００４０】
また、輻輳制御部２１は、ＣＰＵ使用率ｘが第２閾値ｘ２以上ではない、すなわち、ＣＰＵ使用率ｘが第１閾値ｘ１以上であり、かつ、第２閾値ｘ２未満（ｘ１≦ｘ＜ｘ２）であると判定した場合、ＣＰＵ２２における計算量が増加しつつあることと判定し、通信部２０が新規に受信するサービス要求信号に対し、予め定める所定の確率ｌパーセント（ただし、０＜ｌ＜１００）のサービス要求信号について、拒否することを通知する信号を通信部２０に送信させ、他のサービス要求信号をＣＰＵ２２に出力する（ステップＳ６）。
【００４１】
この輻輳制御部２１によるサービス要求信号の拒否／受け入れの処理例について、例えば、サーバ２００の動画のコンテンツの視聴について、予めユーザ登録された会員にのみコンテンツを提供するサービスである場合を例に説明する。
サーバ２００のサービスに登録されている会員を、例えば、入会時期に基づき、直近１ヶ月の間に入会した会員からなるＡ群と、それ以外の会員からなるＢ群との２つのグループに分けておく。ここで、Ａ群の人数は、Ｂ群の人数より少ないこととする。
【００４２】
会員全体の人数に対するＡ群の人数の割合をａ％、会員全体の人数に対するＢ群の人数の割合をｂ％とすると（ａ＋ｂ＝１００）、輻輳制御部２１は、Ａ群、Ｂ群から新規に受信するサービス要求信号に対して、それぞれ以下に示す確率で拒否通知信号を通信部２０に送信させる。
Ａ群に対する拒否確率ｌａ＝ｌ×（ａ÷１００）
Ｂ群に対する拒否確率ｌｂ＝ｌ×（ｂ÷１００）
ｌ＝ｌａ＋ｌｂ
【００４３】
ここで、「Ａ群の人数＜Ｂ群の人数」となることから、「０＜ａ＜ｂ」となるため、「ｌａ＜ｌｂ」となる。したがって、Ｂ群に対し、Ａ群の会員の拒否確率を低く設定することができ、サーバ２００は、Ａ群の会員からのサービス要求信号を優先させる輻輳制御が可能になるという効果がある。
【００４４】
また、輻輳制御部２１は、予め定める所定の第１閾値ｘ１、第２閾値ｘ２に基づき、ＣＰＵ２２の処理量に基づき新規のサービス要求信号の受け入れを制限することにより、ＣＰＵ２２の処理量を超えたサービス要求信号を受信した場合であっても、サービス提供を停止することなく、サーバ２００において既に受け入れているサービス要求信号に対応する処理を継続することが可能になる。
【００４５】
さらに、一定時間新規のサービス要求信号の受け付けを拒否する間に、既に受け入れているサービス要求信号の未完了の処理を継続して処理させることで、ＣＰＵ使用率ｘは第２閾値ｘ２以下となるため、サーバ２００は、新規に受信するサービス要求信号の一部、又は、全てに対して、要求の受け入れを再開することが可能になるという効果がある。
【００４６】
次に、サーバ２００からユーザ端末３９０への送信量に基づく輻輳制御処理について説明する。図５は、通信部２０のデータ送信量ｙに基づく輻輳制御処理の流れを示すフローチャートである。サーバ２００において、送信ファイルサイズチェック機能部２５は、予め定められる所定の周期ごとの通信部２０の合計データ送信量となるデータ送信量ｙの値を取得し、取得したデータ送信量ｙをデータ送信量情報として輻輳制御部２１に出力する（ステップＳ１１）。
【００４７】
輻輳制御部２１は、データ送信量ｙと、第１閾値ｙ１とを比較し、データ送信量ｙが第１閾値ｙ１以上か否かを判定する（ステップＳ１２）。輻輳制御部２１は、データ送信量ｙが第１閾値ｙ１以上ではない、すなわち、データ送信量ｙが第１閾値ｙ１未満（ｙ＜ｙ１）であると判定した場合、通信部２０におけるデータ送信量に余裕があることと判定し、通信部２０が新規に受信するサービス要求信号のうち、コンテンツの送信を要求するファイル送信要求信号を全てＣＰＵ２２に出力する（ステップＳ１３）。
【００４８】
また、ステップＳ１２において、輻輳制御部２１は、データ送信量ｙが第１閾値ｙ１以上で（ｙ１≦ｙ）であると判定した場合、データ送信量ｙと、第２閾値ｙ１（ただし、ｙ１＜ｙ２）とを比較し、データ送信量ｙが第２閾値ｙ１以上か否かを判定する（ステップＳ１４）。
【００４９】
輻輳制御部２１は、データ送信量ｙが第２閾値ｙ２以上（ｙ２≦ｙ）であることと判定した場合、通信部２０のデータ送信量が処理限界に近づいていることと判定し、通信部２０が新規に受信するサービス要求信号のうち、全てのファイル送信要求信号に対し、要求を拒否することを示す要求拒否信号を応答信号としてサービス要求信号の送信元に対し、通信部２０に送信させる（ステップＳ１５）。
【００５０】
また、輻輳制御部２１は、データ送信量ｙが第２閾値ｙ２以上ではない、すなわち、データ送信量ｙが第１閾値ｙ１以上であり、かつ、第２閾値ｙ２未満（ｙ１≦ｙ＜ｙ２）であると判定した場合、通信部２０におけるデータ送信量が増加しつつあることと判定し、通信部２０が新規に受信するサービス要求信号のうち、ファイル送信要求信号に対し、予め定める所定の確率ｍパーセント（ただし、０＜ｍ＜１００）のファイル送信要求信号について、拒否することを通知する信号を通信部２０に送信させ、他のファイル送信要求信号をＣＰＵ２２に出力する（ステップＳ１６）。
【００５１】
これにより、通信部２０におけるデータ送信に関する輻輳が発生した場合であっても、輻輳制御部２１が新規のファイル送信要求信号の受け入れを制限することとなるため、通信部２０が受信する、例えば、ファイル受信要求信号などの、ファイル送信要求信号ではないサービス要求信号に対して、サーバ２００はサービス提供停止することなく、継続してサービス提供することが可能になるという効果がある。
【００５２】
ステップＳ１６における輻輳制御部２１によるサービス要求信号の拒否／受け入れの処理例について、例えば、送信対象となるファイル（コンテンツ）のファイルサイズに基づき、判定する場合を例に説明する。
サーバ２００のＤＢ２３が記憶するコンテンツを、ファイルサイズに基づき、コンテンツあたりのファイルサイズが小さいコンテンツからなるＡ群と、それ以外のコンテンツからなるＢ群との２つのグループに分けておく。ここで、Ａ群の合計ファイルサイズは、Ｂ群の合計ファイルサイズより小さいこととする。
【００５３】
ＤＢ２３が記憶するコンテンツ全体の合計ファイルサイズに対するＡ群の合計ファイルサイズの割合をａ％、コンテンツ全体の合計ファイルサイズに対するＢ群の合計ファイルサイズの割合をｂ％とすると（ａ＋ｂ＝１００）、以下の手順により、輻輳制御部２１は、輻輳制御処理を実行する。
【００５４】
輻輳制御部２１は、新規に受信するファイル送信要求信号に対して、当該ファイル送信要求に含まれるコンテンツ識別情報を検索キーとしてＤＢ２３から送信対象のコンテンツのファイルサイズ情報を読み出す。輻輳制御部２１は、読み出したファイルサイズ情報に基づき、送信対象のコンテンツがＡ群、Ｂ群いずれのコンテンツであるかを判定し、判定結果に応じて、それぞれ以下に示す確率で拒否通知信号を通信部２０に送信させる。
Ａ群に対する拒否確率ｍａ＝ｍ×（ａ÷１００）
Ｂ群に対する拒否確率ｍｂ＝ｍ×（ｂ÷１００）
ｍ＝ｍａ＋ｍｂ
【００５５】
ここで、「Ａ群の合計ファイルサイズ＜Ｂ群の合計ファイルサイズ」であることから、「０＜ａ＜ｂ」となるため、「ｍａ＜ｍｂ」となる。したがって、Ｂ群に対し、Ａ群のファイル（コンテンツ）に対する送信要求の拒否確率を低く設定することができ、サーバ２００は、Ａ群のファイルに対するファイル送信要求信号を優先させる輻輳制御が可能になるという効果がある。ここで、Ｂ群に含まれるコンテンツは、ＤＢ２３が記憶するコンテンツのうち、比較的ファイルサイズが大きいコンテンツであるため、ファイルサイズが大きいコンテンツに関するファイル送信要求に対して、Ａ群に関するファイル送信要求に比して受け入れを抑制することとなるため、サーバ２００は、効率的に輻輳制御を行うことが可能になるという効果がある。
【００５６】
また、輻輳制御部２１は、予め定める所定の第１閾値ｙ１、第２閾値ｙ２に基づき、通信部２０のデータ送信量に基づき新規のファイル送信要求信号の受け入れを制限することにより、通信部２０において可能なデータ送信量を超えたファイル送信要求信号を受信した場合であっても、サービス提供処理を停止することなく、サーバ２００において既に受け入れているファイル送信要求信号に対応する処理を継続することが可能になる。さらに、一定時間新規のファイル送信要求信号の受け付けを拒否する間に、既に受け入れているファイル送信要求信号の未完了の処理を継続して処理させることで、データ送信量ｙは第２閾値ｙ２以下となるため、サーバ２００は、新規に受信するファイル送信要求信号の一部、又は、全てに対して、要求の受け入れを再開させることが可能になるという効果がある。
【００５７】
なお、Ａ群の合計ファイルサイズとＢ群の合計ファイルサイズとの比率とを、例えば、「Ａ群の合計ファイルサイズ：Ｂ群の合計ファイルサイズ＝２：３」など、予め所定に定めておき、輻輳制御部２１は、２４時間後となどの所定周期ごとに、ＤＢ２３の全てのコンテンツのファイルサイズ情報を読み出し、上記の予め所定に定めた合計ファイルサイズ比率に基づき、Ａ群とＢ群とを識別するファイルサイズの閾値を決定することでもよい。
【００５８】
次に、サーバ２００からユーザ端末３９０への受信量に基づく輻輳制御処理について説明する。図６は、通信部２０のデータ受信量ｚに基づく輻輳制御処理の流れを示すフローチャートである。サーバ２００において、受信ファイルサイズチェック機能部２６は、予め定められる所定の周期ごとの通信部２０の合計データ受信量となるデータ受信量ｚの値を取得し、取得したデータ受信量ｚをデータ受信量情報として輻輳制御部２１に出力する（ステップＳ２１）。
【００５９】
輻輳制御部２１は、データ受信量ｚと、第１閾値ｚ１とを比較し、データ受信量ｚが第１閾値ｚ１以上か否かを判定する（ステップＳ２２）。輻輳制御部２１は、データ受信量ｚが第１閾値ｚ１以上ではない、すなわち、データ受信量ｚが第１閾値ｚ１未満（ｚ＜ｚ１）であると判定した場合、通信部２０におけるデータ受信量に余裕があることと判定し、通信部２０が新規に受信するサービス要求信号のうち、音声データの受信を要求するファイル受信要求信号を全てＣＰＵ２２に出力する（ステップＳ２３）。
【００６０】
また、ステップＳ２２において、輻輳制御部２１は、データ受信量ｚが第１閾値ｚ１以上で（ｚ１≦ｚ）であると判定した場合、データ受信量ｚと、第２閾値ｚ１（ただし、ｚ１＜ｚ２）とを比較し、データ受信量ｚが第２閾値ｚ１以上か否かを判定する（ステップＳ２４）。
【００６１】
輻輳制御部２１は、データ受信量ｚが第２閾値ｚ２以上（ｚ２≦ｚ）であることと判定した場合、通信部２０のデータ受信量が処理限界に近づいていることと判定し、通信部２０が新規に受信するサービス要求信号のうち、全てのファイル受信要求信号に対し、要求を拒否することを示す要求拒否信号を応答信号としてサービス要求信号の受信元に対し、通信部２０に送信させる（ステップＳ２５）。
【００６２】
また、輻輳制御部２１は、データ受信量ｚが第２閾値ｚ２以上ではない、すなわち、データ受信量ｚが第１閾値ｚ１以上であり、かつ、第２閾値ｚ２未満（ｚ１≦ｚ＜ｚ２）であると判定した場合、通信部２０におけるデータ受信量が増加しつつあることと判定し、通信部２０が新規に受信するサービス要求信号のうち、ファイル受信要求信号に対し、予め定める所定の確率ｎパーセント（ただし、０＜ｎ＜１００）のファイル受信要求信号について、拒否することを通知する信号を通信部２０に送信させ、他のファイル受信要求信号をＣＰＵ２２に出力する（ステップＳ２６）。
【００６３】
これにより、通信部２０におけるデータ受信に関する輻輳が発生した場合であっても、輻輳制御部２１が新規のファイル受信要求信号の受け入れを制限することとなるため、通信部２０が受信する、例えば、ファイル送信要求信号などの、ファイル受信要求信号ではないサービス要求信号に対して、サーバ２００はサービス提供停止することなく、継続してサービス提供することが可能になるという効果がある。
【００６４】
次に、ステップＳ２６における輻輳制御部２１によるサービス要求信号の拒否／受け入れの処理例について、例えば、受信対象となるファイル（コンテンツ）のファイルサイズに基づき、判定する場合を例に説明する。
例えば直近の１０周期分など、所定の期間において、通信部２０が受信するファイル受信要求信号の履歴を輻輳制御部２１が記憶しておき、当該ファイル受信要求信号に含まれる音声データのファイルサイズ情報の履歴に基づき、これらのファイルサイズに基づき、１音声データあたりのファイルサイズが小さいファイルサイズ情報からなるＡ群と、それ以外のファイルサイズ情報からなるＢ群との２つのグループに分けておく。ここで、Ａ群の合計ファイルサイズは、Ｂ群の合計ファイルサイズより小さいこととする。
【００６５】
輻輳制御部２１が記憶するファイル受信要求信号の履歴に基づき、Ａ群の合計ファイルサイズの割合をａ％、Ｂ群の合計ファイルサイズの割合をｂ％とすると（ａ＋ｂ＝１００）、以下の手順により、輻輳制御部２１は、輻輳制御処理を実行する。
輻輳制御部２１は、新規に受信するファイル受信要求信号に対して、当該ファイル受信要求に含まれるファイルサイズ情報に基づき、受信対象の音声データがＡ群、Ｂ群いずれの音声データであるかを判定し、判定結果に応じて、それぞれ以下に示す確率で拒否通知信号を通信部２０に送信させる。
Ａ群に対する拒否確率ｎａ＝ｎ×（ａ÷１００）
Ｂ群に対する拒否確率ｎｂ＝ｎ×（ｂ÷１００）
ｎ＝ｎａ＋ｎｂ
【００６６】
ここで、「Ａ群の合計ファイルサイズ＜Ｂ群の合計ファイルサイズ」であることから、「０＜ａ＜ｂ」となるため、「ｎａ＜ｎｂ」となる。したがって、Ｂ群に対し、Ａ群の音声データに対する受信要求の拒否確率を低く設定することができ、サーバ２００は、Ａ群の音声データに対するファイル受信要求信号を優先させる輻輳制御が可能になるという効果がある。ここで、Ｂ群に含まれる音声データは、直近の所定期間の間に通信部２０が受信するファイル受信要求信号のうち、比較的ファイルサイズが大きい音声データであるため、ファイルサイズが大きい音声データに関するファイル受信要求に対して、Ａ群に関するファイル受信要求に比して受け入れを抑制することとなるため、サーバ２００は、効率的に輻輳制御を行うことが可能になるという効果がある。
【００６７】
また、輻輳制御部２１は、予め定める所定の第１閾値ｚ１、第２閾値ｚ２に基づき、通信部２０のデータ受信量に基づき新規のファイル受信要求信号の受け入れを制限することにより、通信部２０において可能なデータ受信量を超えたファイル受信要求信号を受信した場合であっても、サービス提供処理を停止することなく、サーバ２００において既に受け入れているファイル受信要求信号に対応する処理を継続することが可能になる。
【００６８】
さらに、一定時間新規のファイル受信要求信号の受け付けを拒否する間に、既に受け入れているファイル受信要求信号の未完了の処理を継続して処理させることで、データ受信量ｚは第２閾値ｚ２以下となるため、サーバ２００は、新規に受信するファイル受信要求信号の一部、又は、全てに対して、要求の受け入れを再開させることが可能になるという効果がある。
【００６９】
なお、Ａ群の合計ファイルサイズとＢ群の合計ファイルサイズとの比率とを、例えば、「Ａ群の合計ファイルサイズ：Ｂ群の合計ファイルサイズ＝２：３」など、予め所定に定めておくこととしてもよいし、ＤＢ２３が記憶する音声データのコンテンツのファイルサイズに基づき、Ａ群とＢ群とを識別するファイルサイズの閾値を決定することでもよい。
【００７０】
次に、ＤＢ２３へのアクセス負荷量に基づく輻輳制御処理について説明する。図７は、ＤＢ２３のアクセス負荷量ｗに基づく輻輳制御処理の流れを示すフローチャートである。
サーバ２００において、ＤＢアクセス負荷チェック機能部２７は、予め定められる所定の周期ごとのＤＢ２３への合計アクセス負荷量となるアクセス負荷量ｗの値を取得し、取得したアクセス負荷量ｗをアクセス負荷量情報として輻輳制御部２１に出力する（ステップＳ３１）。
【００７１】
輻輳制御部２１は、アクセス負荷量ｗと、第１閾値ｗ１とを比較し、アクセス負荷量ｗが第１閾値ｗ１以上か否かを判定する（ステップＳ３２）。輻輳制御部２１は、アクセス負荷量ｗが第１閾値ｗ１以上ではない、すなわち、アクセス負荷量ｗが第１閾値ｗ１未満（ｗ＜ｗ１）であると判定した場合、ＤＢ２３におけるアクセス負荷量に余裕があることと判定し、通信部２０が新規に受信するサービス要求信号のうち、ＤＢ２３のアクセスを伴うサービス要求信号を全てＣＰＵ２２に出力する（ステップＳ３３）。
【００７２】
また、ステップＳ３２において、輻輳制御部２１は、アクセス負荷量ｗが第１閾値ｗ１以上で（ｗ１≦ｗ）であると判定した場合、アクセス負荷量ｗと、第２閾値ｗ１（ただし、ｗ１＜ｗ２）とを比較し、アクセス負荷量ｗが第２閾値ｗ１以上か否かを判定する（ステップＳ３４）。
【００７３】
輻輳制御部２１は、アクセス負荷量ｗが第２閾値ｗ２以上（ｗ２≦ｗ）であることと判定した場合、ＤＢ２３のアクセス負荷量が処理限界に近づいていることと判定し、通信部２０が新規に受信するサービス要求信号のうち、ＤＢ２３へのアクセスを伴う全てのサービス要求信号に対し、要求を拒否することを示す要求拒否信号を応答信号としてサービス要求信号の受信元に対し、通信部２０に送信させる（ステップＳ３５）。
【００７４】
また、輻輳制御部２１は、アクセス負荷量ｗが第２閾値ｗ２以上ではない、すなわち、アクセス負荷量ｗが第１閾値ｗ１以上であり、かつ、第２閾値ｗ２未満（ｗ１≦ｗ＜ｗ２）であると判定した場合、ＤＢ２３におけるアクセス負荷量が増加しつつあることと判定し、通信部２０が新規に受信するサービス要求信号のうち、ＤＢ２３へのアクセスを伴うサービス要求信号に対し、予め定める所定の確率ｋパーセント（ただし、０＜ｋ＜１００）のサービス要求信号について、拒否することを通知する信号を通信部２０に送信させ、他のＤＢ２３へのアクセスを伴うサービス要求信号をＣＰＵ２２に出力する（ステップＳ３６）。
【００７５】
これにより、ＤＢ２３におけるアクセス負荷量に関する輻輳が発生した場合であっても、輻輳制御部２１が新規のＤＢ２３へのアクセスを伴うサービス要求信号の受け入れを制限することとなるため、通信部２０が受信する、例えば、ユーザ認証要求や、新規ユーザ登録要求などの、コンテンツを記憶するＤＢ２３へのアクセスを伴うサービス要求信号ではないサービス要求信号に対して、サーバ２００はサービス提供停止することなく、継続してサービス提供することが可能になるという効果がある。
【００７６】
次に、ステップＳ３６における輻輳制御部２１によるサービス要求信号の拒否／受け入れの処理例について、例えば、読み出し／書き込み対象となるファイル（コンテンツ）のファイルサイズに基づき、判定する場合を例に説明する。
サーバ２００のＤＢ２３が記憶するコンテンツを、ファイルサイズに基づき、コンテンツあたりのファイルサイズが小さいコンテンツからなるＡ群と、それ以外のコンテンツからなるＢ群との２つのグループに分けておく。ここで、Ａ群の合計ファイルサイズは、Ｂ群の合計ファイルサイズより小さいこととする。
【００７７】
ＤＢ２３が記憶するコンテンツ全体の合計ファイルサイズに対するＡ群の合計ファイルサイズの割合をａ％、コンテンツ全体の合計ファイルサイズに対するＢ群の合計ファイルサイズの割合をｂ％とすると（ａ＋ｂ＝１００）、以下の手順により、輻輳制御部２１は、輻輳制御処理を実行する。
【００７８】
輻輳制御部２１は、新規に受信するＤＢ２３へのアクセスを伴うサービス要求信号に対して、ファイル送信要求信号に関しては、コンテンツ識別情報を検索キーとしてＤＢ２３から送信対象のコンテンツのファイルサイズ情報を読み出し、ファイル受信要求信号に関しては、当該ファイル受信要求信号に含まれるファイルサイズ情報を抽出する。輻輳制御部２１は、このファイルサイズ情報に基づき、読み出し／書き込み対象のコンテンツがＡ群、Ｂ群いずれのコンテンツであるかを判定し、判定結果に応じて、それぞれ以下に示す確率で拒否通知信号を通信部２０に送信させる。
Ａ群に対する拒否確率ｋａ＝ｋ×（ａ÷１００）
Ｂ群に対する拒否確率ｋｂ＝ｋ×（ｂ÷１００）
ｋ＝ｋａ＋ｋｂ
【００７９】
ここで、「Ａ群の合計ファイルサイズ＜Ｂ群の合計ファイルサイズ」であることから、「０＜ａ＜ｂ」となるため、「ｋａ＜ｋｂ」となる。したがって、Ｂ群に対し、Ａ群の音声データに対する受信要求の拒否確率を低く設定することができ、サーバ２００は、Ａ群のデータに関するサービス要求信号を優先させる輻輳制御が可能になるという効果がある。ここで、Ｂ群に含まれるコンテンツは、比較的ファイルサイズが大きいデータであるため、ファイルサイズが大きいデータに関するＤＢ２３へのアクセスを伴うサービス要求に対して、Ａ群に関するサービス要求に比して受け入れを抑制することとなるため、サーバ２００は、効率的に輻輳制御を行うことが可能になるという効果がある。
【００８０】
また、輻輳制御部２１は、予め定める所定の第１閾値ｗ１、第２閾値ｗ２に基づき、ＤＢ２３のアクセス負荷量に基づき新規のサービス要求信号の受け入れを制限することにより、ＤＢ２３において対応可能なアクセス負荷量を超えたサービス要求信号を受信した場合であっても、サーバ２００全体のサービス提供処理を停止することなく、サーバ２００において既に受け入れているＤＢ２３へのアクセスを伴うサービス要求信号に対応する処理を継続することが可能になる。
【００８１】
さらに、一定時間新規のＤＢ２３へのアクセスを伴うサービス要求信号の受け付けを拒否する間に、既に受け入れているサービス要求信号の未完了の処理を継続して処理させることで、アクセス負荷量ｗは第２閾値ｗ２以下となるため、サーバ２００は、新規に受信するＤＢ２３へのアクセスを伴うサービス要求信号の一部、又は、全てに対して、要求の受け入れを再開させることが可能になるという効果がある。
【００８２】
なお、Ａ群の合計ファイルサイズとＢ群の合計ファイルサイズとの比率とを、例えば、「Ａ群の合計ファイルサイズ：Ｂ群の合計ファイルサイズ＝２：３」など、予め所定に定めておくこととしてもよい。また、輻輳制御部２１は、ＤＢ２３が記憶する音声データのコンテンツのファイルサイズに基づき、Ａ群とＢ群とを識別するファイルサイズの閾値を決定することでもよい。また、輻輳制御部２１は、例えば、直近１０周期分など、所定の期間のＤＢ２３へのアクセス履歴を記憶しておき、このアクセス履歴に基づき、アクセス対象のファイルサイズ情報に基づき、ファイルサイズの閾値を決定することでもよい。
【００８３】
次に、輻輳制御システム１におけるサーバ２００とブラウザ３００とのファイル送受信処理の全体の流れについて説明する。図８は、サーバ２００とブラウザ３００との間の動画コンテンツの送受信時における動作の流れを示す図である。
ブラウザ３００は、ユーザ４００からの入力操作に基づき、ネットワーク１００を介して動画コンテンツの識別情報を含むファイル送信要求信号をサービス要求信号としてサーバ２００に送信する（ステップＳ４１）。
【００８４】
図４〜図７に示したように、サーバ２００の輻輳制御部２１は、受信したサービス要求信号の受け入れ、又は、拒否を判定する（ステップＳ４２）。サービス要求信号を受け入れることと判定した場合、輻輳制御部２１は、通信部２０を介して要求を受け入れることを通知する信号をブラウザ３００に送信し、当該サービス要求信号をＣＰＵ２２に出力する（ステップＳ４３）。ＣＰＵ２２は、入力されたサービス要求信号のコンテンツの識別情報を検索キーとしてＤＢ２３から動画のコンテンツを読み出し、読み出した動画コンテンツを通信部２０を介してブラウザ３００に送信する（ステップＳ４４）。
【００８５】
また、ステップＳ４２において、サービス要求信号を拒否することと判定した場合、輻輳制御部２１は、要求を拒否することを通知する信号を通信部２０を介してブラウザ３００に送信する（ステップＳ４５）。
ブラウザ３００は、サービス要求信号に対する応答が、受け入れを通知する応答であるか、拒否を通知する応答であるかを判定し（ステップＳ４６）、拒否を通知する応答である場合、動画コンテンツの再生にかかわる処理を終了する（ステップＳ４７）。
ブラウザ３００は、サービス要求信号に対する応答が受け入れを通知する応答である場合、サーバ２００からの受信待機状態に遷移する（ステップＳ４８）。
【００８６】
ブラウザ３００において、動画再生機能部３１は、サーバ２００から動画のコンテンツを受信すると、当該コンテンツの再生処理を実行する（ステップＳ４９）。
音声エンコード機能部３９は、ユーザからの音声エンコード開始要求が入力されると、音声取込機能部３８から入力される音声を随時符号化し、符号化した音声データをアップロード用バッファ３６に記憶させる（ステップＳ５０）。また、音声エンコード機能部３９は、符号化した音声データの受信を要求するファイル受信要求信号を、当該音声データのファイルサイズ情報とともにサービス要求信号として通信部３０を介してサーバ２００に送信する（ステップＳ５１）。
【００８７】
サーバ２００の輻輳制御部２１は、受信したサービス要求信号の受け入れ、又は、拒否を判定する（ステップＳ５２）。サービス要求信号を受け入れることと判定した場合、輻輳制御部２１は、通信部２０を介して要求を受け入れることを通知する信号をブラウザ３００に送信する（ステップＳ５３）。また、サービス要求信号を拒否することと判定した場合、輻輳制御部２１は、要求を拒否することを通知する信号を通信部２０を介してブラウザ３００に送信する（ステップＳ５４）。
【００８８】
ブラウザ３００において、サービス要求信号に対し、サーバ２００から要求を拒否することを示す信号を受信した場合、音声データの送信処理と、動画のコンテンツの再生処理とを中断し、要求を受け入れることを示す信号を受信した場合、アップロード用バッファ３６が記憶する符号化した音声データをサーバ２００に送信する（ステップＳ５５、Ｓ５６）。
【００８９】
次に、ブラウザ３００における輻輳制御処理の流れについて、図面を用いて説明する。図９は、ブラウザ３００において、ファイルのダウンロードに関する輻輳制御処理と、ファイルのアップロードに関する輻輳制御処理との処理の流れを示すフローチャートである。図９（ａ）は、ダウンロードに関する輻輳制御処理の流れを示す。ブラウザ３００において、バッファチェック機能部３７は、予め定められる所定の周期ごとにダウンロード用バッファ３５のメモリ使用量の値を取得し、取得したメモリ使用量をダウンロードメモリ使用量情報として輻輳制御部３２に出力する（ステップＳ７１）。
【００９０】
輻輳制御部３２は、バッファチェック機能部３７から入力されるダウンロード用バッファ３５のメモリ使用量の情報に基づき、ダウンロード用バッファ３５のメモリ使用量が零（ゼロ）であるか否かを判定する（ステップＳ７２）。輻輳制御部３２は、ダウンロード用バッファ３５のメモリ使用量が零ではない、すなわち、ダウンロード用バッファ３５に動画コンテンツのデータが記憶されている場合、輻輳制御部３２は、動画再生機能部３１に動画の再生処理の継続要求、又は、再開要求を出力する（ステップＳ７３）。
【００９１】
輻輳制御部３２は、ダウンロード用バッファ３５のメモリ使用量が零であることと判定した場合、動画再生機能部３１に対し、動画再生処理の一時停止要求を出力し、音声エンコード機能部３９にエンコード処理の一時停止要求を出力し、ステップＳ７１に戻る（ステップＳ７４）。
【００９２】
図９（ｂ）は、アップロードに関する輻輳制御処理の流れを示す。ブラウザ３００において、バッファチェック機能部３７は、予め定められる所定の周期ごとにアップロード用バッファ３６のメモリ使用量を取得し、取得したメモリ使用量をメモリ使用量情報として輻輳制御部３２に出力する（ステップＳ８１）。
【００９３】
輻輳制御部３２は、バッファチェック機能部３７から入力されるアップロード用バッファ３６のメモリ使用量に基づき、アップロード用バッファ３６のメモリの空き容量が零であるか否かを判定する（ステップＳ８２）。輻輳制御部３２は、アップロード用バッファ３６のメモリの空き容量が零ではない、すなわち、アップロード用バッファ３６に、音声データをさらに記憶可能である場合、輻輳制御部３２は、動画再生機能部３１に動画の再生処理の継続要求、又は、再開要求を出力する（ステップＳ８３）。
【００９４】
輻輳制御部３２は、アップロード用バッファ３６のメモリ空き容量が零でであることと判定した場合、動画再生機能部３１に対し、動画再生処理の一時停止要求を出力し、音声エンコード機能部３９にエンコード処理の一時停止要求を出力し、ステップＳ８１に戻る（ステップＳ８４）。
【００９５】
次に、ブラウザ３００とサーバ２００との間におけるファイルの送受信の際、ダウンロード用バッファ３５とアップロード用バッファ３６とがファイルを記憶するタイミングについて、図面を参照して説明する。
図１０は、ブラウザ３００とサーバ２００との間におけるファイルの送受信時のサーバ２００とダウンロード用バッファ３５とアップロード用バッファ３６と動画再生機能部３１と音声エンコード機能部３９との動作の流れを示す図である。
【００９６】
図８のステップＳ４１と同様に、ユーザ入力に基づき、動画再生機能部３１がサーバ２００にファイル受信要求信号を送信すると（ステップＳ９１）、当該要求に基づきサーバ２００から送信されるコンテンツは（ステップＳ９２）、ダウンロード用バッファ３５に一時的に記憶される（ステップＳ９３）。輻輳制御部３２は、バッファチェック機能部３７からのメモリ使用量情報に基づき、ダウンロード用バッファ３５のメモリ使用量が零ではないことと判定すると、動画再生機能部３１に動画再生要求を出力する。動画再生機能部３１は、入力される動画再生要求に基づき、ダウンロード用バッファ３５からコンテンツを読み出し（ステップＳ９４）、読み出したコンテンツの再生処理を実行する（ステップＳ９５）。
【００９７】
図８のステップＳ４８と同様に、ユーザから入力される音声エンコード開始要求に基づき（ステップＳ９６）、音声エンコード機能部３９は、音声取込機能部３８が取り込む音声のエンコード処理を実行する（ステップＳ９７）。音声エンコード機能部３９は、エンコードした符号化された音声データを随時アップロード用バッファ３６に書き込む（ステップＳ９８）。
【００９８】
音声エンコード機能部３９は、ユーザから入力される音声エンコード終了要求に基づき、エンコード処理を終了し、通信部３０を介してアップロード用バッファ３６が記憶する音声データのファイルサイズ情報とともにファイル受信要求信号をサーバ２００に送信する（ステップＳ９９）。サーバ２００から、ファイル受信要求信号を受け入れることを示す信号を受信すると（ステップＳ１００）、音声エンコード機能部３９は、アップロード用バッファ３６が記憶する符号化された音声データをサーバ２００に送信する（ステップＳ１０１）。
【００９９】
なお、上述したファイル受信要求信号に含まれるファイルサイズ情報は、以下の式に基づき音声エンコード機能部３９が算出することとしてもよい。
【０１００】
音声データのファイルサイズ＝（音声録音時間×音声エンコードビットレート）＋固定値
【０１０１】
ここで、固定値は、例えば、ヘッダ情報や、当該音声データが対応する動画のコンテンツの再生タイミングの情報などによる予め所定に定まる情報のデータ量である。
また、サーバ２００における送信対象のコンテンツのファイルサイズは、ＤＢ２３が記憶するコンテンツのファイルサイズに基づき、以下の式に基づき、輻輳制御部２１が算出することとしてもよい。
【０１０２】
送信対象のコンテンツのファイルサイズ＝動画のファイルサイズ＋固定値
【０１０３】
ここで、固定値は、例えば、ヘッダ情報などのデータ量である。
【０１０４】
上述の実施形態によれば、サーバ２００は、輻輳の発生箇所となる発生要因以外のサービス要求信号を受け入れて、一部のユーザに対するサービスの提供を継続することができ、また、サーバ２００におけるサービス全体の処理停止を伴うことなく輻輳制御処理を行い、輻輳を抑制することが可能になるという効果がある。
【０１０５】
なお、上述の輻輳制御部２１におけるサービス要求処理の拒否の手順は、Ａ群とＢ群との２つのグループに異なる割合でサービス要求の受け入れを拒否することとしたが、これに限らず、例えば、３つ以上のグループに異なる割合でサービス要求の受け入れを拒否することとしてもよいし、全てのサービス要求信号に対し、一律所定の割合でサービス要求の受け入れを拒否することとしてもよい。
また、拒否確率ｌと拒否確率ｍと拒否確率ｎと拒否確率ｋとは、互いに異なる確率でもよいし、同一の確率であってもよい。
【０１０６】
また、輻輳制御部２１における第１閾値ｘ１、第２閾値ｘ２、第１閾値ｙ１、第２閾値ｙ２、第１閾値ｚ１、第２閾値ｚ２、第１閾値ｗ１、第２閾値ｗ２は、それぞれ、輻輳制御部２１が予め固定値として記憶していることとしてもよいし、サーバ２００におけるＤＢ２３へのアクセス負荷量の履歴、ＣＰＵ使用率の履歴、送受信データ量の履歴などに応じて、輻輳制御部２１が随時変更することとしてもよい。
また、輻輳制御部２１における閾値は、第１閾値と第２閾値との２つとして説明したが、これに限られず、３以上の閾値を用いて、ＣＰＵ使用率、送受信データ量、ＤＢ２３へのアクセス負荷量の増加に応じて、拒否確率を上げることとしてもよい。
【０１０７】
また、図４のステップＳ６において異なる確率で新規サービス要求を拒否する際、ユーザの入会時期に基づきＡ群とＢ群とに分けることとしたが、これに限られず、有料会員、無料会員などの会員種別ごと、会員のアクセス頻度ごとなど、いずれの方法でグループ分けを行うこととしてもよい。また同様に、図５のステップＳ１６、図６のステップＳ２６において、Ａ群とＢ群とをサービス要求にかかわるファイルサイズ情報に基づき、グループ分けを行うこととして説明したが、これに限られず、通信部２０のデータ送受信履歴におけるファイルサイズごとのアクセス頻度に基づき、アクセス頻度が高いファイルサイズ群と、アクセス頻度が低いファイルサイズ群との２つのグループに分けることや、アクセス頻度の高い動画コンテンツに対する要求と、アクセス頻度が低い動画コンテンツに対する要求との２グループに分けることなど、いずれの方法でグループ分けを行う事としてもよい。
【０１０８】
このアクセス頻度に基づき、グループ分けを実施し、アクセス頻度が高いグループに対して、サービス要求信号に対し高い拒否確率とすることにより、アクセス頻度が低いグループに比して、輻輳の発生に関わるアクセス頻度が高いグループのサービス要求信号に対し、より厳しい受け入れ制限処理をサーバ２００が行うことができ、輻輳の発生に大きく関わらないサービス要求へに対する輻輳制御処理の影響を抑制することが可能になるという効果がある。
【０１０９】
なお、本発明に記載のサーバが備える記憶手段は、ＤＢ２３に対応する。また、本発明に記載の動画は、動画のコンテンツに対応し、本発明に記載の端末は、ユーザ端末３９０に対応し、本発明に記載の輻輳発生箇所は、通信部２０、ＣＰＵ２２、ＤＢ２３に対応し、本発明に記載の輻輳度情報は、ＣＰＵ使用率情報、データ送信量情報、データ受信量情報、アクセス負荷量情報に対応し、本発明に記載の輻輳の発生確率Ｘは、ＣＰＵ使用率ｘ、データ送信量ｙ、データ受信量ｚ、アクセス負荷量ｗに対応し、本発明に記載の所定の閾値Ｘ１は、第１閾値ｘ１、ｙ１、ｚ１、ｗ１に対応し、本発明に記載の所定の閾値Ｘ２は、第２閾値ｘ２、ｙ２、ｚ２、ｗ２に対応する。
【０１１０】
なお、上述のサーバ２００、及び、ユーザ端末３９０は、内部にコンピュータシステムを有している。そして、サーバ２００の通信部２０、輻輳制御部２１、ＣＰＵ２２、ＣＰＵ使用率チェック機能部２４、送信ファイルサイズチェック機能部２５、受信ファイルサイズチェック機能部２６、ＤＢアクセス負荷チェック機能部２７、ユーザ端末３９０におけるブラウザ３００の通信部３０、動画再生機能部３１、輻輳制御部３２、ダウンロード用バッファ３５、アップロード用バッファ３６、バッファチェック機能部３７、音声取込機能部３８、並びに、音声エンコード機能部３９の動作の過程は、プログラムの形式でコンピュータ読み取り可能な記録媒体に記憶されており、このプログラムをコンピュータシステムが読み出して実行することによって、上記処理が行われる。ここでいう「コンピュータシステム」とは、ＣＰＵ及び各種メモリやＯＳ、周辺機器等のハードウェアを含むものである。
また、「コンピュータシステム」は、ＷＷＷシステムを利用している場合であれば、ホームページ提供環境（あるいは表示環境）も含むものとする。
【０１１１】
また、図４、図５、図６、図７、図８、図９、図１０に示す各ステップを実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、また、図２に示すサーバ２００の機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、また、図３に示すブラウザ３００の機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することにより、動画コラボレーションにおける輻輳の制御処理を行ってもよい。
また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、フラッシュメモリ等の書き込み可能な不揮発性メモリ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。
【０１１２】
さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムが送信された場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリ（例えばＤＲＡＭ（Dynamic Random Access Memory））のように、一定時間プログラムを保持しているものも含むものとする。
また、上記プログラムは、このプログラムを記憶装置等に格納したコンピュータシステムから、伝送媒体を介して、あるいは、伝送媒体中の伝送波により他のコンピュータシステムに伝送されてもよい。ここで、プログラムを伝送する「伝送媒体」は、インターネット等のネットワーク（通信網）や電話回線等の通信回線（通信線）のように情報を伝送する機能を有する媒体のことをいう。
また、上記プログラムは、前述した機能の一部を実現するためのものであっても良い。さらに、前述した機能をコンピュータシステムに既に記録されているプログラムとの組合せで実現できるもの、いわゆる差分ファイル（差分プログラム）であっても良い。
【図面の簡単な説明】
【０１１３】
【図１】本発明の一実施形態による輻輳制御システム１の全体構成を示す図である。
【図２】同実施形態におけるサーバ２００の内部構成を示すブロック図である。
【図３】同実施形態におけるブラウザ３００の内部構成を示すブロック図である。
【図４】同実施形態におけるＣＰＵ２２の使用率に基づく輻輳制御処理の動作フローを示す図である。
【図５】同実施形態における通信部２０のデータ送信量に基づく輻輳制御処理の動作を示すフローである。
【図６】同実施形態における通信部２０のデータ受信量に基づく輻輳制御処理の動作フローを示す図である。
【図７】同実施形態におけるＤＢ２３へのアクセス負荷量に基づく輻輳制御処理の動作フローを示す図である。
【図８】同実施形態におけるサーバ２００とブラウザ３００との間のファイル送受信の動作の流れを示す図である。
【図９】ブラウザ３００における輻輳制御処理の動作フローを示す図である。
【図１０】ブラウザ３００におけるダウンロード用バッファ３５とアップロード用バッファ３６のデータの流れを示すフローチャートである。
【符号の説明】
【０１１４】
１  輻輳制御システム
２０  通信部
２１  輻輳制御部
２２  ＣＰＵ
２３  ＤＢ
２４  ＣＰＵ使用率チェック機能部
２５  送信ファイルサイズチェック機能部
２６  受信ファイルサイズチェック機能部
２７  ＤＢアクセス負荷チェック機能部
３０  通信部
３１  動画再生機能部
３２  輻輳制御部
３５  ダウンロード用バッファ
３６  アップロード用バッファ
３７  バッファチェック機能部
３８  音声取込機能部
３９  音声エンコード機能部
１００  ネットワーク
２００  サーバ
３００  ブラウザ
３９０  ユーザ端末
４００  ユーザ
【図１】
2009266093.tif 000003
【図２】
2009266093.tif 000004
【図３】
2009266093.tif 000005
【図４】
2009266093.tif 000006
【図５】
2009266093.tif 000007
【図６】
2009266093.tif 000008
【図７】
2009266093.tif 000009
【図８】
2009266093.tif 000010
【図９】
2009266093.tif 000011
【図１０】
2009266093.tif 000012