(57)【要約】    【課題】  ネットワーク上でのメッセージ転送に遅延が生じても、アンダーフローを防止してリアルタイム性に優れたデータ伝送を行うことができるデータ伝送装置を提供する。    【解決手段】  メッセージ処理部１０４が送信バッファ１０３を常に監視し、所定の閾値まで音声データが蓄積されたタイミングで、音声データを送信バッファ１０３から取得し、ＨＴＴＰリクエストの中に埋め込んでサーバ装置へ送信する。このとき、転送時間計測部１０５により時間計測を開始し、サーバ装置からレスポンスを受信するまでの時間を計測する。送信データ量決定部１０６は、この計測時間の統計処理を実施し、ＨＴＴＰメッセージの送受信にかかる時間の恒常的な変動傾向（一時的でない）を判断して、送信バッファ１０３の前記閾値を変更する。【選択図】      図１
2007005894.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを介して外部装置にデータをリアルタイムに伝送するデータ伝送装置において、
入力装置から入力されたデータを一時的に記憶するバッファリング手段と、
前記バッファリング手段に記憶したデータを含むリクエストメッセージを作成するリクエストメッセージ作成手段と、
前記作成されたリクエストメッセージを前記外部装置へ送信し、該外部装置から前記リクエストメッセージに対するレスポンスメッセージを受信するメッセージ送受信手段と、
前記リクエストメッセージの送信から前記レスポンスメッセージを受信するまでのメッセージ転送時間を計測する転送時間計測手段と、
前記転送時間計測手段で計測した前記メッセージ転送時間に基づいて、前記リクエストメッセージに含まれるデータのデータ量を決定するデータ量決定手段とを備えたことを特徴とするデータ伝送装置。
【請求項２】
前記データ量決定手段は、
前記転送時間計測手段によって該メッセージ転送時間が増加していると判断された場合は前記リクエストメッセージの１つに含まれるデータ量を増加し、該メッセージ転送時間が減少傾向にあると判断された場合には前記データ量を減少させることを特徴とする請求項１に記載のデータ伝送装置。
【請求項３】
前記メッセージ転送時間の増減が一時的、または増減の幅が小さい場合は、前記データ量を変更しないことを特徴とする請求項２に記載のデータ伝送装置。
【請求項４】
前記データ量決定手段によって指定されたデータ量のデータが前記バッファリング手段に記憶された場合に次のリクエストメッセージの送信処理を行うことを特徴とする請求項１乃至３のいずれかに記載のデータ伝送装置。
【請求項５】
ネットワークを介して外部装置にデータをリアルタイムに伝送するデータ伝送装置の制御方法において、
入力された連続データを一時的にバッファリング手段に記憶する工程と、
前記バッファリング手段に記憶したデータを含むリクエストメッセージを作成するリクエストメッセージ作成工程と、
前記リクエストメッセージを前記外部装置へ送信し、該外部装置から前記リクエストメッセージに対するレスポンスメッセージを受信するメッセージ送受信工程と、
前記リクエストメッセージの送信から前記レスポンスメッセージを受信するまでのメッセージ転送時間を計測する転送時間計測工程と、
前記転送時間計測工程で計測した前記メッセージ転送時間に基づいて、前記リクエストメッセージに含まれるデータのデータ量を決定するデータ量決定工程とを実行することを特徴とするデータ伝送装置の制御方法。
【請求項６】
ネットワークを介して外部装置にデータをリアルタイムに伝送するデータ伝送装置の制御方法を実行するための、コンピュータで読み取り可能な制御プログラムであって、
入力された連続データを一時的にバッファリング手段に記憶するステップと、
前記バッファリング手段に記憶した連続データを含むリクエストメッセージを作成するリクエストメッセージ作成ステップと、
前記リクエストメッセージを前記外部装置へ送信し、該外部装置から前記リクエストメッセージに対するレスポンスメッセージを受信するメッセージ送受信ステップと、
前記リクエストメッセージの送信から前記レスポンスメッセージを受信するまでのメッセージ転送時間を計測する転送時間計測ステップと、
前記転送時間計測ステップで計測した前記メッセージ転送時間に基づいて、前記リクエストメッセージに含まれるデータのデータ量を決定するデータ量決定ステップとを有することを特徴とする制御プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、インターネット等のネットワークを介して音声などの連続データを伝送するデータ伝送装置及びその制御方法、並びに前記制御方法を実現するための制御プログラムに関する。
【背景技術】
【０００２】
近年、ＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）ネットワークを利用したライブ配信システムやビデオ会議システム等、リアルタイム性が要求されるデータの配信システムが提案されている（例えば、特許文献１参照）。
【０００３】
一般に、リアルタイム（実時間）の音声通信を行う場合に、送信側は、音声通信による遅延量を小さくするため音声データを小さく区切って送信する。さらに、小さく区切った音声データを一定間隔で送信する必要がある。これは、受信側で後述するようなアンダーフローを起こさないようにするためである。受信側でアンダーフローが発生すると、再生時に音途切れやエコーなどが発生し、ユーザに不快感を与えることになる。
【０００４】
ＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）を用いて、クライアント装置からサーバ装置へリアルタイム性の高い音声通信を実施することを考える。まず、クライアント装置は、ＨＴＴＰリクエストに音声データを含めたＨＴＴＰメッセージをサーバ装置へ送信し、サーバ装置からレスポンスを受信する。このＨＴＴＰメッセージの送受信を繰り返すことにより、クライアント装置からサーバ装置へ連続した音声通信が可能になる。但し、上述したように、リアルタイム性の高い音声通信を行うためには、クライアント装置は、上記ＨＴＴＰメッセージの送受信処理をなるべく小さい単位で、且つ一定間隔で実施する必要がある。
【特許文献１】特開２００２−３３０４８９号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら、上記ＨＴＴＰメッセージの送受信処理において、実際のネットワーク環境では、装置もしくはネットワーク上の様々な遅延要因により、ＨＴＴＰメッセージの送受信単位を小さい単位で、且つ一定間隔で実施することは困難である。
【０００６】
具体的には、クライアント装置とサーバ装置間のネットワーク経路において、プロキシサーバ装置を経由する場合には、ＨＴＴＰメッセージを一時蓄積することで転送処理が数百ミリ秒程度遅れたり、ＨＴＴＰヘッダを書き換えてＨＴＴＰレスポンスの転送後にＨＴＴＰセッションを切断させたりすることがある。また、クライアント装置上でアンチウイルスソフトウェアが動作していると、プロキシサーバ装置使用時と同様の現象を引き起こす場合がある。その他、ネットワーク上でのパケット落ちなど、様々な原因により、ＨＴＴＰメッセージの送受信処理が滞る場合がある。
【０００７】
このような要因から、ＨＴＴＰメッセージの送受信処理が滞り、音声を再生する側のサーバ装置ではアンダーフローが起こって再生時の音途切れやエコーが発生し、ユーザに不快感を与えるという問題があった。
【０００８】
本発明は上記従来の問題点に鑑み、ネットワーク上でのメッセージ転送に遅延が生じても、アンダーフローを防止してリアルタイム性に優れたデータ伝送を行うことができるデータ伝送装置及びその制御方法、並びに制御プログラムを提供することを目的とする。
【課題を解決するための手段】
【０００９】
本発明は上記目的を達成するため、ネットワークを介して外部装置にデータをリアルタイムに伝送するデータ伝送装置において、入力装置から入力されたデータを一時的に記憶するバッファリング手段と、前記バッファリング手段に記憶したデータを含むリクエストメッセージを作成するリクエストメッセージ作成手段と、前記作成されたリクエストメッセージを前記外部装置へ送信し、該外部装置から前記リクエストメッセージに対するレスポンスメッセージを受信するメッセージ送受信手段と、前記リクエストメッセージの送信から前記レスポンスメッセージを受信するまでのメッセージ転送時間を計測する転送時間計測手段と、前記転送時間計測手段で計測した前記メッセージ転送時間に基づいて、前記リクエストメッセージに含まれるデータのデータ量を決定するデータ量決定手段とを備えたことを特徴とする。
【００１０】
また、本発明は、ネットワークを介して外部装置にデータをリアルタイムに伝送するデータ伝送装置の制御方法において、入力された連続データを一時的にバッファリング手段に記憶する工程と、前記バッファリング手段に記憶したデータを含むリクエストメッセージを作成するリクエストメッセージ作成工程と、前記リクエストメッセージを前記外部装置へ送信し、該外部装置から前記リクエストメッセージに対するレスポンスメッセージを受信するメッセージ送受信工程と、前記リクエストメッセージの送信から前記レスポンスメッセージを受信するまでのメッセージ転送時間を計測する転送時間計測工程と、前記転送時間計測工程で計測した前記メッセージ転送時間に基づいて、前記リクエストメッセージに含まれるデータのデータ量を決定するデータ量決定工程とを実行することを特徴とする。
【００１１】
また、本発明は、ネットワークを介して外部装置にデータをリアルタイムに伝送するデータ伝送装置の制御方法を実行するための、コンピュータで読み取り可能な制御プログラムであって、入力された連続データを一時的にバッファリング手段に記憶するステップと、前記バッファリング手段に記憶した連続データを含むリクエストメッセージを作成するリクエストメッセージ作成ステップと、前記リクエストメッセージを前記外部装置へ送信し、該外部装置から前記リクエストメッセージに対するレスポンスメッセージを受信するメッセージ送受信ステップと、前記リクエストメッセージの送信から前記レスポンスメッセージを受信するまでのメッセージ転送時間を計測する転送時間計測ステップと、前記転送時間計測ステップで計測した前記メッセージ転送時間に基づいて、前記リクエストメッセージに含まれるデータのデータ量を決定するデータ量決定ステップとを有することを特徴とする。
【発明の効果】
【００１２】
本発明によれば、ネットワーク上でのメッセージ転送に遅延が生じても、リクエストメッセージおよびレスポンスメッセージの送受信時間を利用することにより、アンダーフローを防止することができ、リアルタイム性に優れた品質の良いデータ伝送を行うことが可能になる。
【発明を実施するための最良の形態】
【００１３】
本発明のデータ伝送装置及びその制御方法、並びに制御プログラムの実施の形態について、図面を参照しながら説明する。
【００１４】
＜装置の構成＞
図１は、本発明のデータ伝送装置である音声通信装置を備えた音声伝送システムの要部機能を示すブロック図である。
【００１５】
この音声伝送システムは、音声入力装置１００から入力された音声データをクライアント装置１０１からネットワーク１０８を介してサーバ装置２００へリアルタイムに伝送するシステムである。クライアント装置１０１は、音声データ処理部１０２、送信バッファ１０３、メッセージ処理部１０４、転送時間計測部１０５、送信データ量決定部１０６、及びネットワーク処理部１０７等から構成されている。なお、図１に示す音声伝送システムは、通信端末装置として、クライアント装置１０１およびサーバ装置２００からなるが、クライアント装置どうしの構成でもサーバ装置どうしの構成でもよい。
【００１６】
音声データ処理部１０２は、音声入力装置１００から音声信号を受けてＡ／Ｄ変換処理と音声圧縮処理を行い、送信バッファ１０３は、圧縮された音声データを一時的格納する。メッセージ処理部１０４は、送信バッファ１０３に蓄積された音声データを含んだＨＴＴＰリクエストメッセージを作成する。
【００１７】
転送時間計測部１０５は、作成したＨＴＴＰリクエストを送信したときから、サーバ装置２００より返信されるＨＴＴＰレスポンスを受信するまでの時間（メッセージ転送時間）を計測し、送信データ量決定部１０６は、前記メッセージ転送時間の統計を取って、ＨＴＴＰリクエストに含める音声データ量を決定する。ネットワーク処理部１０７は、ＨＴＴＰリクエストやＨＴＴＰレスポンスを送受信する。
【００１８】
なお、音声入力装置１００はクライアント装置１０１内に存在する場合もあるが、音声伝送システムを構成する機能ブロックとして大きな違いはないため、本実施の形態では別装置として説明する。
【００１９】
一方、サーバ装置２００は、ネットワーク処理部２０１、受信バッファ２０２、メッセージ処理部２０３、及び音声データ処理部２０４を有している。ネットワーク処理部２０１は、ＨＴＴＰレスポンスやＨＴＴＰリクエストを送受信する。受信バッファ２０２は、
受信した音声データを蓄積し、メッセージ処理部２０３は、ＨＴＴＰレスポンスを作成する。音声データ処理部２０４は、音声データを順次伸長しつつＤ／Ａ変換する。
【００２０】
図２は、図１に示したクライアント装置１０１のハード構成の一例を示すブロック図である。
【００２１】
このクライアント装置１０１は、図１に示した音声データ処理部１０２及び送信バッファ１０３と、ＣＰＵ９０１と、ＲＯＭ９０２と、ＲＡＭ９０３と、入力装置コントローラ（ＫＢＣ）９０５と、ＣＲＴコントローラ（ＣＲＴＣ）９０６と、ディスクコントローラ（ＤＫＣ）９０７と、ネットワークインターフェースコントローラ９０８とが、システムバス９０４を介して互いに通信可能に接続された構成となっている。
【００２２】
ＣＰＵ９０１は、ＲＯＭ９０２或いはＨＤ９１１に記憶されたソフトウェアを実行することで、システムバス９０４に接続された各構成部を総括的に制御する。即ち、ＣＰＵ９０１は、所定の処理シーケンスに従った処理プログラムを、ＲＯＭ９０２或いはＨＤ９１１から読み出して実行することで、図１に示したメッセージ処理部１０４、転送時間計測部１０５、及び送信データ量決定部１０６に相当する各機能を実現すると共に、本実施の形態に係る動作（図３参照）を実現するための制御を行う。ＲＡＭ９０３は、ＣＰＵ９０１の主メモリ或いはワークエリア等として機能する。
【００２３】
入力装置コントローラ（ＫＢＣ）９０５は、入力装置であるマウス９０９ａ及びキーボード９０９ｂからの指示入力を制御し、ＣＲＴコントローラ（ＣＲＴＣ）９０６は、ＣＲＴディスプレイ（ＣＲＴ）９１０の表示を制御する。ディスクコントローラ（ＤＫＣ）９０７は、ハードディスク（ＨＤ）９１１に対するアクセス動作を制御し、ネットワークインターフェースコントローラ（ＮＩＣ、図１中のネットワーク処理部１０７に相当）９０８は、ネットワーク１０８との接続処理を行う。
【００２４】
＜本実施の形態に係る動作＞
次に、本実施の形態に係る動作について図３を参照して説明する。図３は、本実施の形態のクライアント装置１０１の動作を示すフローチャートである。
【００２５】
クライアント装置１０１よりサーバ装置２００への音声通信を開始する場合、まず、音声データ処理部１０２では、音声入力装置１００からリアルタイムに入力された音声信号をＡ／Ｄ変換し、さらに音声圧縮を施してから送信バッファ１０３に蓄積する（ステップＳ１１）。音声信号は連続して入力されてくるので、数ミリから数十ミリ秒程度の短期間で送信バッファ１０３に次々と蓄積される。
【００２６】
メッセージ処理部１０４は、送信バッファ１０３を常に監視し、送信バッファ１０３に所定の閾値（後述する）まで音声データが蓄積されると（ステップＳ１２）、その音声データを送信バッファ１０３から取得し（ステップＳ１３）、ＨＴＴＰリクエストの中に埋め込む（ステップＳ１４）。そして、メッセージ処理部１０４は、転送時間計測部１０５を通して、ネットワーク処理部１０７に対して、前記音声データが埋め込まれたＨＴＴＰリクエストの送信を指示する。このとき、転送時間計測部１０５は、タイマーによる時間計測を開始する（ステップＳ１５）。ネットワーク処理部１０７は、メッセージ処理部１０４から指示されたＨＴＴＰリクエストをネットワーク１０８を介して、サーバ装置２００へ送信する。
【００２７】
サーバ装置２００側では、ＨＴＴＰリクエストを受信すると、音声データを受信バッファ２０２に蓄積し、ＨＴＴＰレスポンスを作成する。そして、ネットワーク１０８を介して、クライアント装置１０１に返信する。その後、受信バッファ２０２に蓄積された音声データは、順次伸長がなされ、さらにＤ／Ａ変換が行われて音声出力装置２０５へ出力され、音声が再生される。
【００２８】
クライアント装置１０１では、ネットワーク処理部１０７がＨＴＴＰレスポンスを受信し、転送時間計測部１０５を通して、メッセージ処理部１０４に届ける。転送時間計測部１０５は、ＨＴＴＰレスポンスを確認すると、動作中のタイマーを停止し（ステップＳ１６）、ＨＴＴＰリクエストの送信からＨＴＴＰレスポンスの受信までにかかった時間（メッセージ転送時間）を算出して送信データ量決定部１０６に通知する（ステップＳ１７）。
【００２９】
送信データ量決定部１０６は、過去から現在までに計測されたメッセージ転送時間の統計処理を実施する。そして、今回計測したメッセージ転送時間と過去の計測時間を比較することによりＨＴＴＰリクエストの１つに含まれる送信データ量を決定する（ステップＳ１８）。具体的には、今回計測したメッセージ転送時間が過去の計測時間より長くなっていると判断すると、メッセージ処理部１０４に対して、監視している送信バッファ１０３に蓄積する送信データの容量の閾値を大きくし、一度に転送する送信データ量を増加させる指示を出す。また、今回計測したメッセージの転送時間が過去の計測時間より短くなっていると判断すると、メッセージ処理部１０４に対して監視している送信バッファ１０３に蓄積する送信データの容量の閾値を小さくし、一度に転送する送信データ容量を減少させる指示を出す。（ステップＳ２０）。
【００３０】
送信データ量決定部１０６が、メッセージ転送時間が過去の計測時間より長くなっている、または短くなっていると判断する方法としては、例えば、直近の１０秒間の平均計測時間がその前の１０秒間の平均計測時間の２倍になっている、或いは半分になっているといったように、恒常的な変動傾向を観察する方法がある。この場合、ネットワークの一時的な遅延検出によって、短時間の間に何度も閾値を変更しないようにする。短時間に何度も閾値を変更すると、サーバ装置２００で再生時の平均通信時間が揺らぎ、音途切れが発生しやすくなる。
【００３１】
また、送信データ量決定部１０６によって決定される送信バッファ１０３の最初の閾値（初期値）は、実際のネットワーク構成上の遅延要因を考慮して決定することが好ましい。例えば、ＨＴＴＰリクエストはプロキシサーバ装置を経由してサーバ装置２００へ送るのか、またはクライアント装置１０１上でアンチウイルスソフトを使用しているか、などのネットワーク構成上の遅延要因を調べ、これらを使用している場合は送信バッファ１０３の閾値を大きく、使用していない場合は送信バッファ１０３の閾値を小さく設定する。この時、実際の環境により、複数の閾値を使い分けると効果的である。
【００３２】
このようにして、通信するネットワーク構成に最適な初期値を送信バッファ１０３の閾値として使用することができる。さらに、過去からの計測時間の統計を取ることで動的に一度に音声データを送信データとして転送するデータ量を変更できるので、メッセージの送受信間隔が想定以上に時間がかかるネットワーク環境でも、最適な閾値でネットワーク通信することができる。また、音声通信を一旦終了しても、送信バッファ１０３の閾値を、通信対象のサーバ装置毎に保持しておき、次回の音声通信時の初期値として再利用することで、次回以降、最初から安定した音声通信が可能となる。
【００３３】
クライアント装置１０１側でＨＴＴＰレスポンスを受信した後、メッセージ処理部１０４は、送信バッファ１０３に蓄積されている音声データが再度閾値を超えたときに、次のＨＴＴＰリクエストのために送信バッファ１０３から音声データを取得し、この音声データを埋め込んだＨＴＴＰデータを作成して前記した手順でサーバ装置２００へ送信する。このとき、音声データが閾値を超えてもＨＴＴＰレスポンスを受信できていない場合、次のＨＴＴＰリクエストの送信処理は、ＨＴＴＰレスポンスの受信まで待ち合わせることになる。
【００３４】
＜受信バッファのバッファ蓄積量の推移＞
次に、図４（ａ），（ｂ），（ｃ）を参照して、サーバ装置２００における受信バッファ２０２のバッファ蓄積量の推移について説明する。図４（ａ），（ｂ），（ｃ）は、サーバ装置２００における受信バッファのバッファ蓄積量の推移を説明するための波形図である。
【００３５】
（Ａ）理想的な状態でのバッファ蓄積量の推移
ＨＴＴＰリクエストを送信してからＨＴＴＰレスポンスを受信するまでの時間であるメッセージ転送時間が、音声データが送信バッファ１０３の閾値を越えるまでに必要な時間より短い場合は、サーバ装置２００内における受信バッファ２０２のバッファ蓄積量は図４（ａ）に示すように推移していく。
【００３６】
図４（ａ）の例では、音声データを含んだＨＴＴＰリクエストを受信した時刻ｔ２００において、残存しているバッファ蓄積量ｂ２００がＨＴＴＰリクエストに含まれる音声データを取得することによりバッファ蓄積量ｂ２０１まで一時的に増加する。その後、次のＨＴＴＰリクエストを受信する時刻ｔ２０１まで音声再生していくことで徐々にバッファ蓄積量が減少していくことを表している。なお、本実施の形態では、前提として、ＨＴＴＰリクエストの受信の完了に応じてＨＴＴＰレスポンスをクライアント装置１０１に返信する処理が行われるものとする。そして、また次のＨＴＴＰリクエストを時刻ｔ２０２で受信し、受信バッファ２０２に蓄積し再生する、という処理を繰り返す。
【００３７】
図４（ａ）の例では、理想的な状態で通信していると仮定している。具体的には、サーバ装置２００が、ＨＴＴＰリクエストの受信の完了に応じてＨＴＴＰレスポンスをクライアント装置１０１に返信するため、クライアント装置１０１は遅滞なくＨＴＴＰレスポンスを受信することができる。このため、バッファ蓄積量の平均も一定であり、受信バッファ２０２に音声データがなくなるというアンダーフローを起こすことはない。
【００３８】
（Ｂ）本実施の形態を適用しない場合おけるバッファ蓄積量の推移
次に、本実施の形態を適用しない場合の、サーバ装置２００における受信バッファ２０２のバッファ蓄積量の推移について説明する。
【００３９】
ネットワーク経路上にプロキシサーバ装置を使用している、或いは特定のアンチウイルスソフトを使用している場合など、ネットワーク上の遅延要因により、クライアント装置１０１がＨＴＴＰリクエストを一定間隔で送信できない場合における、サーバ装置２００の受信バッファ２０２のバッファ蓄積量の推移を図４（ｂ）に示す。
【００４０】
サーバ装置２００は、時刻ｔ３００の時点でＨＴＴＰレスポンスを返している。しかしながら、クライアント装置１０１は、ネットワーク上の遅延により時刻ｔ３０１になってもＨＴＴＰレスポンスを受信することができない。このため、クライアント装置１０１は、当然次のＨＴＴＰリクエストを送信することはできない。
【００４１】
クライアント装置１０１は、理想的なＨＴＴＰリクエスト受信タイミングである時刻ｔ３０１においてＨＴＴＰリクエストを受信できていないため、サーバ装置２００の受信バッファ２０２の蓄積されていた音声データ量は時刻ｔ３０２の時点でゼロとなる。つまりアンダーフローが起きて、音声出力装置２０５では音途切れが発生してしまう。
【００４２】
その後、クライアント装置１０１はＨＴＴＰレスポンスの受信に応じて次のＨＴＴＰリクエストを送信するが、サーバ装置２００では時刻ｔ３０３にＨＴＴＰリクエストを受信することになる。この時、一時的にバッファ蓄積量が回復し音声再生が開始されるが、結局次のＨＴＴＰリクエストの到着にも時間がかかってしまうので、再度バッファアンダーフローが発生し、音声出力装置２０５からは連続した音として聞こえない状態となる。
【００４３】
（Ｃ）本実施の形態を適用した場合におけるバッファ蓄積量の推移
次に、図４（ｂ）の例と同じ条件の下で、本実施の形態を適用した場合のサーバ装置２００におけるバッファ蓄積量の推移を図４（ｃ）に示す。
【００４４】
遅延要因として、ネットワーク経路上にプロキシサーバ装置を使用している、或いは特定のアンチウイルスソフトを使用している場合で、且つクライアント装置１０１側において接続時の情報として前記遅延要因を知っている場合に、クライアント装置１０１は１つのＨＴＴＰリクエストに含める音声データ量を例えば図４（ｂ）の２倍に設定する。
【００４５】
その結果、サーバ装置２００の受信バッファ２０２は、時刻ｔ４００において２倍の音声データが増えてバッファ蓄積量ｂ４０１まで増加する。そのため、その後２倍のメッセージ間隔で次のＨＴＴＰリクエストを受信したとしても、バッファ蓄積量ｂ４００までしか減らないので、バッファアンダーフローの発生を防止することができる。
【００４６】
本実施の形態では、このように予め分かっているネットワーク構成への対応だけでなく、例えばＨＴＴＰメッセージが通過するネットワーク経路が途中で変更されたり、ネットワーク負荷が急に高くなったりする場合など、恒常的なネットワーク遅延が発生する場合でも、的確に対応することができる。即ち、前述したようにメッセージ転送時間を計測し統計を取ることで、そのネットワーク遅延を検出し、ＨＴＴＰメッセージと一緒に送信される音声データを大きくすることで、サーバ装置２００におけるバッファアンダーフローを防止することができる。
【００４７】
＜本実施の形態の利点＞
リアルタイム性が高い音声通信を行うために理想的には、クライアント装置１０１は、ＨＴＴＰメッセージの送受信処理をなるべく小さい単位で、且つ一定間隔で実施することが重要である。しかしながら、クライアント装置１０１とサーバ装置２００間のネットワーク経路において、ＨＴＴＰメッセージの送受信処理が滞ることがある。その要因としては、例えばプロキシサーバ装置を経由したり、クライアント装置１０１上でアンチウイルスソフトが動作していたりするなど、ネットワーク構成上の遅延によるものが、まず挙げられる。その他にも、ＨＴＴＰメッセージが通過するネットワーク経路が途中で変更された場合や、ネットワーク上でのパケット落ちやネットワーク負荷が急に高くなるなど、一時的なネットワーク環境による遅延が複雑に絡まりあってクライアント装置からは恒常的にネットワーク遅延が発生しているように見える場合もある。
【００４８】
このような場合では、クライアント装置１０１とサーバ装置２００間におけるＨＴＴＰメッセージの送受信（ＨＴＴＰリクエストに音声データを含めたＨＴＴＰメッセージをサーバ装置へ送信しサーバ装置からレスポンスを受信する）に悪影響が生ずる。即ち、前記ＨＴＴＰメッセージの送信からレスポンスを受信するまでの時間が送信データの間隔（１リクエストに含まれる音声データ量）よりも大きくなってくる。
【００４９】
このような傾向においては、本実施の形態では、一度に送るデータ量を増やして送信間隔を長くするように調整する。即ち、ＨＴＴＰリクエストに含める音声データ量を、その時点でのネットワーク構成／環境における恒常的なメッセージ送受信時間分以上のデータ量にする。具体的には、メッセージ処理部１０４が送信バッファ１０３を常に監視し、所定の閾値まで音声データが蓄積されたタイミングで、音声データを送信バッファ１０３から取得し、ＨＴＴＰリクエストの中に埋め込んでサーバ装置へ送信する。このとき、転送時間計測部１０５により時間計測を開始し、サーバ装置からレスポンスを受信するまでの時間を計測する。送信データ量決定部１０６は、この計測時間の統計処理を実施し、ＨＴＴＰメッセージの送受信にかかる時間の恒常的な変動傾向（一時的でない）を判断して、送信バッファ１０３の前記閾値を変更する。
【００５０】
このような本実施の形態の構成において、例えば、ＨＴＴＰリクエストをプロキシサーバ装置経由して送る、またはクライアント装置１０１上でアンチウイルスソフトを使用するなど、実際のネットワーク構成の遅延要因が予め分かっている場合には、前記送信バッファ１０３の閾値を、これらの遅延要因を考慮して決定する。これによって、通信するネットワーク構成に最適な初期値を閾値として使用することができる。さらに、予め分かっているネットワーク構成への対応だけでなく、上述したような恒常的なネットワーク遅延が発生しているようなネットワーク環境でも、過去からの計測時間の統計を取ることで動的に最適な閾値に変更することができる。
【００５１】
これにより、ＨＴＴＰリクエストに含める音声データ量を、使用するネットワーク環境に最適な単位に設定し、且つＨＴＴＰリクエストの送信間隔を一定にすることができるので、サーバ装置２００側でバッファアンダーフローが発生することを防ぐことができ、音途切れや不快なエコーを回避することが可能になる。
【００５２】
なお、本発明の目的は、実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）が記憶媒体に格納されたプログラムコードを読み出して実行することによっても達成される。
【００５３】
この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施の形態の機能を実現することになり、そのプログラムコード及び該プログラムコードを記憶した記憶媒体は本発明を構成することになる。
【００５４】
また、プログラムコードを供給するための記憶媒体としては、例えば、フロッピー（登録商標）ディスク、ハードディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ、ＤＶＤ−ＲＷ、ＤＶＤ＋ＲＷ、磁気テープ、不揮発性のメモリカード、ＲＯＭ等を用いることができる。または、プログラムコードをネットワークを介してダウンロードしてもよい。
【００５５】
また、コンピュータが読み出したプログラムコードを実行することにより、上記実施の形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれる。
【００５６】
更に、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれる。
【００５７】
この場合、上記プログラムは、該プログラムを記憶した記憶媒体から直接、またはインターネット、商用ネットワーク、もしくはローカルエリアネットワーク等に接続された不図示の他のコンピュータやデータベース等からダウンロードすることにより供給される。
【図面の簡単な説明】
【００５８】
【図１】音声伝送システムの要部機能を示すブロック図である。
【図２】クライアント装置のハード構成の一例を示すブロック図である。
【図３】実施の形態の動作を示すフローチャートである。
【図４】受信バッファのバッファ蓄積量の推移を示す波形図である。
【符号の説明】
【００５９】
１００  音声入力装置
１０１  クライアント装置
１０２  音声データ処理部
１０３  送信バッファ
１０４  メッセージ処理部
１０５  転送時間計測部
１０６  送信データ量決定部
１０７  ネットワーク処理部
１０８  ネットワーク
２０１  サーバ装置
２０２  受信バッファ
２０５  音声出力装置
９０１  ＣＰＵ
９０２  ＲＯＭ
【図１】
2007005894.tif 000003
【図２】
2007005894.tif 000004
【図３】
2007005894.tif 000005
【図４】
2007005894.tif 000006