データ通信装置、データ通信システム、データ通信方法およびプログラム
【課題】伝送帯域が保証されない通信網を利用したデータ通信の際に送信側の装置のバッファの空き容量の減少の原因を区別し、原因に応じた解決策を講じるデータ通信装置等を提供すること。
【解決手段】伝送帯域が保証されない通信網を利用したデータ通信を行うデータ通信システムであって、サーバ１は自装置のバッファの空き容量の減少の原因を判断し、該原因に応じた解決のための情報をクライアント２に送信する。
【解決手段】伝送帯域が保証されない通信網を利用したデータ通信を行うデータ通信システムであって、サーバ１は自装置のバッファの空き容量の減少の原因を判断し、該原因に応じた解決のための情報をクライアント２に送信する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、伝送帯域が保証されない通信網を利用したデータ通信技術に関する。
【背景技術】
【０００２】
動画像データの通信に関するリモートスクリーン方式等で、遠隔地にあるサーバ等の別の装置の画面に表示されるべき画像データをキャプチャしてユーザが自己で使用しているパーソナル・コンピュータ等のクライアント端末に送信してそのクライアント端末の画面に画像データを表示する場合がある。なお、サーバの画面をクライアント端末の画面上に表示し始めたときには、全画面の情報を送信するが、それ以降はサーバの画面の変化部分のみの情報をクライアント端末に送信し、クライアント端末では、変化部分のみを描画するようにすると、データ送信量と描画処理量が少なく済む。
【０００３】
上記の動画像データの通信を行う場合、例えば、無線通信等による伝送帯域が保証されない通信網を利用したデータ通信がなされると、送信側のサーバから受信側のクライアント端末へ単位時間当たりに送信可能なデータ量は時々刻々と変動する。
【０００４】
この伝送帯域の変動に対応するために、従来、伝送帯域の変動に応じて送信側のサーバが画像データのコマ落としを行うことで伝送データ量を調整することや、所定の回線速度測定サイトにアクセスしてダミーデータをダウンロードさせて一定期間の平均ビットレートを参照することなどがなされてきた。
【０００５】
しかし、一定期間の平均ビットレートを用いるのでは、送信可能なデータ量は時々刻々と変動するのでリアルタイム性に欠け、例えば、平均ビットレートの値は概ね問題なしであるが、ビットレートの振幅が時々刻々、リアルタイムで大幅に変動する場合には有効性は低下する。
【０００６】
関連技術として、伝送帯域が保証されない通信網を用いる場合において、画像符号化部は、入力画像の直交変換による符号化を行い、直交変換係数を係数バッファに記憶させる。送信データ量制御部は、送信バッファの空き容量をみて、通信網の伝送帯域が減少したと判断すると、係数バッファから符号化画像信号の低周波成分のみを読み出して送信し、画像信号量を削減する。画像受信側での復号画像は、欠如する高周波成分量に応じてぼやけた画像となるが、直交変換係数の低周波数成分を送信することで伝送帯域の減少によるコマ落ちを最小限に抑制するする技術が提案されている（例えば、特許文献１参照）。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開平１０−７９９３９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
しかしながら、上述の関連技術のように、送信側でバッファの空き容量のみを監視して、画像信号量を削減する制御を行うのでは、バッファの空き容量の減少（送信されるべきデータがボトルネックにより滞っている）の原因が、伝送帯域が変動して小さくなっていることに起因しているのか、それとも、送信側の装置からの動画像データのビットレートが高い（データ量が多い）ことに起因しているのか、区別できないという問題があった。すなわち、上記の原因の相違により、ユーザのとるべき解決手法も異なり、上記の原因の相違を峻別しない限り、適切な解決手法をユーザに提示することができない。
【０００９】
本発明は、以上のような課題を解決するためになされたもので、伝送帯域が保証されない通信網を利用したデータ通信の際に送信側の装置のバッファの空き容量の減少の原因を区別し、原因に応じた解決策を講じるデータ通信装置、データ通信システム、データ通信方法およびプログラムを提供することを目的とする。
【課題を解決するための手段】
【００１０】
本発明のデータ通信装置は、伝送帯域が保証されない通信網を利用したデータ通信の際に、自装置のバッファの空き容量の減少の原因を判断し、該原因に応じた解決のための情報をデータ受信側の装置に送信することを特徴とする。
【００１１】
また、本発明のデータ通信システムは、伝送帯域が保証されない通信網を利用したデータ通信を行うデータ通信システムであって、データ送信側の装置は自装置のバッファの空き容量の減少の原因を判断し、該原因に応じた解決のための情報をデータ受信側の装置に送信することを特徴とする。
【００１２】
また、本発明のデータ通信方法は、伝送帯域が保証されない通信網を利用したデータ通信の際に、データ送信側の装置が自装置のバッファの空き容量の減少の原因を判断するステップと、データ送信側の装置が前記原因に応じた解決のための情報をデータ受信側の装置に送信するステップとを有することを特徴とする。
【００１３】
また、本発明のプログラムは、伝送帯域が保証されない通信網を利用したデータ通信の際に、データ送信側のコンピュータに、
自コンピュータのバッファの空き容量の減少の原因を判断する処理と、該原因に応じた解決のための情報をデータ受信側の装置に送信する処理とを実行させることを特徴とする。
【発明の効果】
【００１４】
本発明によれば、伝送帯域が保証されない通信網を利用したデータ通信の際に送信側の装置のバッファの空き容量の減少の原因を区別し、原因に応じた解決策を講じることが可能となる。
【図面の簡単な説明】
【００１５】
【図１】本発明の実施の形態に係るデータ通信システムの構成を示す図である。
【図２】本発明の実施の形態に係るデータ通信システムの構成装置の機能ブロック図である。
【図３】本発明の実施の形態に係る処理動作を示すフローチャートである。
【図４】本発明の実施の形態に係る空き容量が少なくなっている原因を判断する処理動作を示すフローチャートである。
【図５】本発明の実施の形態に係るポイントによる重み付けを説明する図である。
【図６】本発明の実施の形態に係るバッファの空き容量が減少している状態を説明する図である。
【発明を実施するための形態】
【００１６】
以下、本発明の実施の形態について図面を参照して詳細に説明する。図１に示す本実施の形態におけるデータ通信システムは、サーバ１とクライアント２とが無線ネットワーク３０を介して接続されて構成されている。なお、無線ネットワーク３は、例示であり、有線その他の既知のネットワークを広く含む。
【００１７】
サーバ１は、グラフィックデータ処理により、複数の描画コマンドを生成するソフトウェアを実行する中央演算処理装置（以下、「ＣＰＵ」という）１０と、エンコーダ２０、ＮＩＣ３０、プログラム記憶部４０、メインメモリ５０、入力装置６０及び出力装置７０を備える情報処理装置であり、ＣＰＵ１０、エンコーダ２０、ＮＩＣ３０、プログラム記憶装置４０、メインメモリ５０、入力装置６０及び表示装置７０は、それぞれデータ転送等のためのバス８０を介して接続されている。
【００１８】
ＣＰＵ１０は、アプリケーションソフトウェア、アプリケーション・プログラム・インタフェース（ＡＰＩ）ミドルウェア等の各種ミドルウェア、及びデバイスドライバ等のソフトウェアを実行して、描画コマンドを生成する。
【００１９】
エンコーダ２０は、キャプチャした出力装置７０のデスクトップ画面等の画像データをエンコードしてデバイスドライバの配下のメインメモリ５０のグラフィックデータバッファ領域５０―１に出力する。
【００２０】
ＮＩＣ(Network Interface Card)３０は、無線ネットワーク３等のネットワークに接続するインターフェース機器である。
【００２１】
プログラム記憶部４０は、アプリケーションソフトウェア、ＡＰＩミドルウェア、デバイスドライバ等の、ＣＰＵ１０によって実行されるソフトウェアのプログラムコードを格納する。
【００２２】
メインメモリ５０は、グラフィックデータバッファ領域５０―１及びコマンドバッファ領域５０―２を有する。グラフィックデータバッファ領域５０―１は処理対象のグラフィックデータをＦＩＦＯ等によって格納する。コマンドバッファ領域５０―２は、描画コマンドを格納する。また、メインメモリ５０は、ＣＰＵ１０の処理により生成されるデータ等を一時的に保存する。
【００２３】
入力装置６０はユーザがデータ等を入力するキーボード、マウス等である。出力装置７０は、画像処理結果・出力画像等を外部送信可能なインタフェースや表示部としてのディスプレイやプリンタ等である。
【００２４】
アプリケーションソフトウェアは、入力装置６０から入力されたグラフィックデータを処理し、処理結果として得られるＡＰＩ関数コール（目的の描画を行うための指示）をＡＰＩミドルウェアに引き渡す。ＡＰＩミドルウェアはそのＡＰＩ関数コールを処理して、ハードウェアが実行可能な描画コマンドを生成する。デバイスドライバは、ＡＰＩミドルウェアによって生成された描画コマンドをコマンドバッファ領域５０―２にバッファリングした後、新たな処理を開始できるタイミングで、描画コマンドを用いて描画処理を行い、描画処理結果である画像描画用データ（例えばピクセルデータ）をフレームメモリ３０に格納し、その後出力装置７０から所定の出力がなされる。
【００２５】
クライアント２は、サーバ１から送信された、例えば、画像データ等のデータを受信して表示するパーソナル・コンピュータ、シンクライアント端末等の情報処理装置である。ＣＰＵ１１と、ＮＩＣ３１、プログラム記憶部４１、メインメモリ５１、入力装置６１及び出力装置７１を備える情報処理装置であり、ＣＰＵ１１、ＮＩＣ３１、プログラム記憶装置４１、メインメモリ５１、入力装置６１及び表示装置７１は、それぞれデータ転送等のためのバス８１を介して接続されている。基本的な構成要素はサーバ１と同様であるので重複する説明は省略する。
【００２６】
図２に、本実施の形態におけるサーバ１およびクライアント２の機能ブロック図を示す。
【００２７】
本実施の形態におけるサーバ１は、表示部１０１と、キャプチャ部１０２と、エンコード部１０３と、データ格納部１０４と、原因判断部１０５と、データ送信部１０６とを備えている。
【００２８】
表示部１０１は、映像等の動画像データを表示する機能を有している。データは画像データに限らず任意の種類のデータであってよい。なお、出力装置７０により実現されてよい。
【００２９】
キャプチャ部１０２は、画面のキャプチャであれば、デスクトップやアクティブ・ウインドウの画面を画像ファイルとして保存する機能を有している。なお、ＣＰＵ１０により実現されてよい。
【００３０】
エンコード部１０３は、キャプチャ部１０２がキャプチャした出力装置７０のデスクトップ画面等の画像データをエンコードしてデバイスドライバの配下のメインメモリ５０のグラフィックデータバッファ領域５０―１に出力する機能を有している。なお、エンコーダ２０により実現されてよい。
【００３１】
データ格納部１０４は、キャプチャ部１０２によりキャプチャした画像データをエンコード部１０３がエンコードしたデータを格納する機能を有している。なお、メインメモリ５０のグラフィックデータバッファ領域５０―１により実現されてよい。
【００３２】
原因判断部１０５は、メインメモリ５０のグラフィックデータバッファ領域５０―１にデータが格納され、空き容量が少なくなっている原因を判断する機能を有している。なお、ＣＰＵ１０により実現されてよい。具体的な判断手法については後述する。
【００３３】
データ送信部１０６は、クライアント２へ各種のデータを送信する機能を有している。なお、ＣＰＵ１０、アプリケーションソフトウェアおよびＮＩＣ３０により実現されてよい。
【００３４】
本実施の形態におけるクライアント２は、データ受信部２０１と、表示部２０２と、操作受付部２０３とを備えている。
【００３５】
データ受信部２０１は、サーバ１から各種のデータを受信する機能を有している。なお、ＮＩＣ３１により実現されてよい。
【００３６】
表示部２０２は、映像等の動画像データや文字データ等を表示する機能を有している。データは画像データに限らず任意の種類のデータであってよい。なお、出力装置７１により実現されてよい。
【００３７】
操作受付部２０３は、ユーザの種々の指令の入力操作を受け付ける機能を有している。なお、入力装置６１により実現されてよい。
【００３８】
以下、本実施の形態の動作について図面を参照して詳細に説明する。
図３のフローチャートを参照すると、まず、サーバ１の表示部１０１は、出力装置７０のデスクトップ画面等に映像等の動画像データを表示する（Ｓ３０１）。
【００３９】
次に、サーバ１のキャプチャ部１０２は、画面のキャプチャとして、デスクトップやアクティブ・ウインドウの画面を画像ファイルとして保存する（Ｓ３０２）。
【００４０】
次に、サーバ１のエンコード部１０３は、キャプチャ部１０２がキャプチャした画像データをエンコードしてデバイスドライバの配下のメインメモリ５０のグラフィックデータバッファ領域５０―１に出力する（Ｓ３０３）。
【００４１】
そして、サーバ１のデータ格納部１０４は、上記のエンコード部１０３がエンコードしたデータをグラフィックデータバッファ領域５０―１に格納する（Ｓ３０４）。
【００４２】
サーバ１の原因判断部１０５は、メインメモリ５０のグラフィックデータバッファ領域５０―１にデータが格納され、空き容量が少なくなっている原因を判断する（Ｓ３０５）。
以下、空き容量が少なくなっている原因を判断する具体的な判断手法について説明する。ここで、一旦、図３から離れ、図４のフローチャートを参照する。
【００４３】
図４を参照すると、サーバ１の原因判断部１０５は、サーバ１のデータ送信部１０６からクライアント２へ送信されている各種のデータのデータ量を取得し、「送信ビットレート」を算出する。また、原因判断部１０５は、メインメモリ５０のグラフィックデータバッファ領域５０―１の空き容量を取得し、「バッファ空き容量」を算出する。また、原因判断部１０５は、メインメモリ５０のグラフィックデータバッファ領域５０―１に含まれるフレーム数を取得し、「バッファ中フレーム数」を算出する（Ｓ４０１）。ここではボトルネックとならない伝送帯域を１秒間に２０フレーム送信することができるものとする。
【００４４】
サーバ１の原因判断部１０５は、例えば、図５に示すように、上記の「バッファ空き容量」および「バッファ中フレーム数」のそれぞれにポイントによる重み付けをしておき、両方のポイントの合計値が所定の閾値（例えば「２」）以上となった場合に、バッファの空き容量が減少している（送信されるべきデータがボトルネックにより滞っている）と判断する（Ｓ４０２、Ｓ４０３）。バッファの空き容量が減少している状態の一例を図６に示す。なお、他の手法として、ボトルネックとならない伝送帯域を１秒間に２０フレーム送信することができるものとすると、原因判断部１０５は、１秒間に送信されるフレーム数を監視し、所定の閾値（例えば、５フレーム）以下しか送信できていない場合に、バッファの空き容量が減少している（送信されるべきデータがボトルネックにより滞っている）と判断することであってもよい。
【００４５】
さらに、サーバ１の原因判断部１０５は、バッファの空き容量が減少していると判断した場合（Ｓ４０２／Ｙｅｓ）、バッファの空き容量が減少していると判断した時点の「送信ビットレート」を現在の回線の「限界通信速度」として取得する（Ｓ４０４）。なぜならデータ送信量が回線の限界値に達するとバッファの空き容量が急激に減少するので、バッファの空き容量が減少していると判断した時点の「送信ビットレート」は現在の回線の「限界通信速度」とほぼ等しいと考えてよいからである。また、原因判断部１０５は、バッファの空き容量が減少していると判断した場合（Ｓ４０２／Ｙｅｓ）、バッファの空き容量が減少していると判断した時点の「必要ビットレート」を算出する（Ｓ４０４）。「必要ビットレート」はメインメモリ５０のグラフィックデータバッファ領域５０―１に格納されているデータを所定のフレームレート（ここでは、例えば１秒間に２０フレーム表示可能とする）で送信しようとする場合に必要となるビットレートのことをいう。具体的には、「必要ビットレート」＝（バッファサイズ−「バッファ空き容量」）／「バッファ中フレーム数」により求められる。なお、「必要ビットレート」はエンコード時のビットレートによることとしてもよい。
【００４６】
サーバ１の原因判断部１０５は、「必要ビットレート」と「限界通信速度」とを比較して（Ｓ４０５）、所定の閾値に基づいて「必要ビットレート」＞＞「限界通信速度」（差が大きく）であり、「必要ビットレート」−「限界通信速度」が閾値以上である場合（Ｓ４０５／Ｙｅｓ）、バッファの空き容量の減少（送信されるべきデータがボトルネックにより滞っている）の原因が、伝送帯域そのものが変動して小さくなっているので、解決手法として、回線自体をより伝送帯域の大きい回線に切り替えることや、ユーザのクライアント２での作業内容を変更すること等の指示メッセージデータを生成する（Ｓ４０６）。回線の切り替えとは、例えば、携帯電話機等のデバイスを利用することであったり、また有線と無線とを切り替えることであったり、無線のアクセスポイントを変更するための位置移動等であってよい。また、ユーザのクライアント２での作業内容の変更とは、例えば、エクセル（登録商標）等による細かい画面表示がなされている場合、モザイク状にしか表示されなくても問題ないスライドショー形式等であれば作業を続行してもよいが、その他の場合にはエクセル（登録商標）等による作業を中止することである。
一方、サーバ１の原因判断部１０５は、「必要ビットレート」と「限界通信速度」とを比較して（Ｓ４０５）、所定の閾値に基づいて「必要ビットレート」＞「限界通信速度」（差が小さく）であり、「必要ビットレート」−「限界通信速度」が閾値未満である場合（Ｓ４０５／Ｎｏ）、バッファの空き容量の減少（送信されるべきデータがボトルネックにより滞っている）の原因が、サーバ１からの動画像データのビットレートが高い（データ量が多い）ことに起因しているので、解決手法として、送信される動画像データのパラメータを変更してビットレートを低くすること等の指示メッセージデータやパラメータのレベルを示すデータを生成する（Ｓ４０７）。パラメータの変更とは、エンコード時のパラメータによってデータ量を調整可能であるので、圧縮率を高く（画像は劣化）してデータ量を低減させたり、また、画面の解像度を小さくしてデータ量を低減させたり、また、音声データは送らないことでデータ量を低減させたりすることであってよい。また、フレーム自体を間引くことでデータ量を低減させることも可能である。
【００４７】
図３のフローチャートに戻り、サーバ１のデータ送信部１０６は、上記のステップＳ４０６やステップＳ４０７で生成した指示メッセージデータ等をクライアント２へ送信する（Ｓ３０６）。指示メッセージデータ等のデータ量は少ないため、バッファの空き容量が減少している（送信されるべきデータがボトルネックにより滞っている）と判断されている通信環境下でも通信に与える影響は極めて限定的であり特に問題としない。
【００４８】
クライアント２のデータ受信部２０１は、サーバ１のデータ送信部１０６から指示メッセージデータ等を受信し、クライアント２の表示部２０２は、指示メッセージデータ等を表示する（Ｓ３０７）。具体的には、上記のステップＳ４０６で生成した回線自体をより伝送帯域の大きい回線に切り替えることや、ユーザのクライアント２での作業内容を変更すること等の指示メッセージデータを文字で画面に表示したり、また、上記のステップＳ４０７で生成した送信される動画像データのパラメータを変更してビットレートを低くすること等の指示メッセージデータを文字で画面に表示すると共にパラメータのレベルを示す図形データ（例えばレベル１〜６）を画面に表示してユーザが選択可能とする。なお、表示することのみに限定されなく、音声等で出力されユーザに伝達されることであってもよい。
また、本ステップＳ３０７で、上記のステップＳ４０６において伝送帯域そのものが変動して小さくなっているので、解決手法として、回線自体をより伝送帯域の大きい回線に切り替えるべきと判断されているときに、クライアント２側で指示メッセージデータ等を表示することなく、クライアント２の所定の制御部により自動的に回線を切り替える処理がなされてもよい。
【００４９】
クライアント２の操作受付部２０３は、ユーザの種々の指令の入力操作を受け付ける（Ｓ３０８）。例えば、回線を切り替える入力操作や動画像データのパラメータを変更する入力操作である。クライアント２の所定の制御部により入力操作に応じた指令の処理がなされる。
【００５０】
なお、上述する各実施の形態は、本発明の好適な実施の形態であり、本発明の要旨を逸脱しない範囲内において種々変更実施が可能である。例えば、サーバ１およびクライアント２の機能を実現するためのプログラムを各装置に読込ませて実行することにより各装置の機能を実現する処理を行ってもよい。さらに、そのプログラムは、コンピュータ読み取り可能な記録媒体であるＣＤ−ＲＯＭまたは光磁気ディスクなどを介して、または伝送媒体であるインターネット、電話回線などを介して伝送波により他のコンピュータシステムに伝送されてもよい。
【符号の説明】
【００５１】
１ サーバ
２ クライアント
３ 無線ネットワーク
１０、１１ ＣＰＵ
２０ エンコーダ
３０、３１ ＮＩＣ
４０、４１ プログラム記憶部
５０、５１ メインメモリ
５０―１ グラフィックデータバッファ領域
５０―２ コマンドバッファ領域
６０、６１ 入力装置
７０、７１ 出力装置
８０、８１ バス
【技術分野】
【０００１】
本発明は、伝送帯域が保証されない通信網を利用したデータ通信技術に関する。
【背景技術】
【０００２】
動画像データの通信に関するリモートスクリーン方式等で、遠隔地にあるサーバ等の別の装置の画面に表示されるべき画像データをキャプチャしてユーザが自己で使用しているパーソナル・コンピュータ等のクライアント端末に送信してそのクライアント端末の画面に画像データを表示する場合がある。なお、サーバの画面をクライアント端末の画面上に表示し始めたときには、全画面の情報を送信するが、それ以降はサーバの画面の変化部分のみの情報をクライアント端末に送信し、クライアント端末では、変化部分のみを描画するようにすると、データ送信量と描画処理量が少なく済む。
【０００３】
上記の動画像データの通信を行う場合、例えば、無線通信等による伝送帯域が保証されない通信網を利用したデータ通信がなされると、送信側のサーバから受信側のクライアント端末へ単位時間当たりに送信可能なデータ量は時々刻々と変動する。
【０００４】
この伝送帯域の変動に対応するために、従来、伝送帯域の変動に応じて送信側のサーバが画像データのコマ落としを行うことで伝送データ量を調整することや、所定の回線速度測定サイトにアクセスしてダミーデータをダウンロードさせて一定期間の平均ビットレートを参照することなどがなされてきた。
【０００５】
しかし、一定期間の平均ビットレートを用いるのでは、送信可能なデータ量は時々刻々と変動するのでリアルタイム性に欠け、例えば、平均ビットレートの値は概ね問題なしであるが、ビットレートの振幅が時々刻々、リアルタイムで大幅に変動する場合には有効性は低下する。
【０００６】
関連技術として、伝送帯域が保証されない通信網を用いる場合において、画像符号化部は、入力画像の直交変換による符号化を行い、直交変換係数を係数バッファに記憶させる。送信データ量制御部は、送信バッファの空き容量をみて、通信網の伝送帯域が減少したと判断すると、係数バッファから符号化画像信号の低周波成分のみを読み出して送信し、画像信号量を削減する。画像受信側での復号画像は、欠如する高周波成分量に応じてぼやけた画像となるが、直交変換係数の低周波数成分を送信することで伝送帯域の減少によるコマ落ちを最小限に抑制するする技術が提案されている（例えば、特許文献１参照）。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開平１０−７９９３９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
しかしながら、上述の関連技術のように、送信側でバッファの空き容量のみを監視して、画像信号量を削減する制御を行うのでは、バッファの空き容量の減少（送信されるべきデータがボトルネックにより滞っている）の原因が、伝送帯域が変動して小さくなっていることに起因しているのか、それとも、送信側の装置からの動画像データのビットレートが高い（データ量が多い）ことに起因しているのか、区別できないという問題があった。すなわち、上記の原因の相違により、ユーザのとるべき解決手法も異なり、上記の原因の相違を峻別しない限り、適切な解決手法をユーザに提示することができない。
【０００９】
本発明は、以上のような課題を解決するためになされたもので、伝送帯域が保証されない通信網を利用したデータ通信の際に送信側の装置のバッファの空き容量の減少の原因を区別し、原因に応じた解決策を講じるデータ通信装置、データ通信システム、データ通信方法およびプログラムを提供することを目的とする。
【課題を解決するための手段】
【００１０】
本発明のデータ通信装置は、伝送帯域が保証されない通信網を利用したデータ通信の際に、自装置のバッファの空き容量の減少の原因を判断し、該原因に応じた解決のための情報をデータ受信側の装置に送信することを特徴とする。
【００１１】
また、本発明のデータ通信システムは、伝送帯域が保証されない通信網を利用したデータ通信を行うデータ通信システムであって、データ送信側の装置は自装置のバッファの空き容量の減少の原因を判断し、該原因に応じた解決のための情報をデータ受信側の装置に送信することを特徴とする。
【００１２】
また、本発明のデータ通信方法は、伝送帯域が保証されない通信網を利用したデータ通信の際に、データ送信側の装置が自装置のバッファの空き容量の減少の原因を判断するステップと、データ送信側の装置が前記原因に応じた解決のための情報をデータ受信側の装置に送信するステップとを有することを特徴とする。
【００１３】
また、本発明のプログラムは、伝送帯域が保証されない通信網を利用したデータ通信の際に、データ送信側のコンピュータに、
自コンピュータのバッファの空き容量の減少の原因を判断する処理と、該原因に応じた解決のための情報をデータ受信側の装置に送信する処理とを実行させることを特徴とする。
【発明の効果】
【００１４】
本発明によれば、伝送帯域が保証されない通信網を利用したデータ通信の際に送信側の装置のバッファの空き容量の減少の原因を区別し、原因に応じた解決策を講じることが可能となる。
【図面の簡単な説明】
【００１５】
【図１】本発明の実施の形態に係るデータ通信システムの構成を示す図である。
【図２】本発明の実施の形態に係るデータ通信システムの構成装置の機能ブロック図である。
【図３】本発明の実施の形態に係る処理動作を示すフローチャートである。
【図４】本発明の実施の形態に係る空き容量が少なくなっている原因を判断する処理動作を示すフローチャートである。
【図５】本発明の実施の形態に係るポイントによる重み付けを説明する図である。
【図６】本発明の実施の形態に係るバッファの空き容量が減少している状態を説明する図である。
【発明を実施するための形態】
【００１６】
以下、本発明の実施の形態について図面を参照して詳細に説明する。図１に示す本実施の形態におけるデータ通信システムは、サーバ１とクライアント２とが無線ネットワーク３０を介して接続されて構成されている。なお、無線ネットワーク３は、例示であり、有線その他の既知のネットワークを広く含む。
【００１７】
サーバ１は、グラフィックデータ処理により、複数の描画コマンドを生成するソフトウェアを実行する中央演算処理装置（以下、「ＣＰＵ」という）１０と、エンコーダ２０、ＮＩＣ３０、プログラム記憶部４０、メインメモリ５０、入力装置６０及び出力装置７０を備える情報処理装置であり、ＣＰＵ１０、エンコーダ２０、ＮＩＣ３０、プログラム記憶装置４０、メインメモリ５０、入力装置６０及び表示装置７０は、それぞれデータ転送等のためのバス８０を介して接続されている。
【００１８】
ＣＰＵ１０は、アプリケーションソフトウェア、アプリケーション・プログラム・インタフェース（ＡＰＩ）ミドルウェア等の各種ミドルウェア、及びデバイスドライバ等のソフトウェアを実行して、描画コマンドを生成する。
【００１９】
エンコーダ２０は、キャプチャした出力装置７０のデスクトップ画面等の画像データをエンコードしてデバイスドライバの配下のメインメモリ５０のグラフィックデータバッファ領域５０―１に出力する。
【００２０】
ＮＩＣ(Network Interface Card)３０は、無線ネットワーク３等のネットワークに接続するインターフェース機器である。
【００２１】
プログラム記憶部４０は、アプリケーションソフトウェア、ＡＰＩミドルウェア、デバイスドライバ等の、ＣＰＵ１０によって実行されるソフトウェアのプログラムコードを格納する。
【００２２】
メインメモリ５０は、グラフィックデータバッファ領域５０―１及びコマンドバッファ領域５０―２を有する。グラフィックデータバッファ領域５０―１は処理対象のグラフィックデータをＦＩＦＯ等によって格納する。コマンドバッファ領域５０―２は、描画コマンドを格納する。また、メインメモリ５０は、ＣＰＵ１０の処理により生成されるデータ等を一時的に保存する。
【００２３】
入力装置６０はユーザがデータ等を入力するキーボード、マウス等である。出力装置７０は、画像処理結果・出力画像等を外部送信可能なインタフェースや表示部としてのディスプレイやプリンタ等である。
【００２４】
アプリケーションソフトウェアは、入力装置６０から入力されたグラフィックデータを処理し、処理結果として得られるＡＰＩ関数コール（目的の描画を行うための指示）をＡＰＩミドルウェアに引き渡す。ＡＰＩミドルウェアはそのＡＰＩ関数コールを処理して、ハードウェアが実行可能な描画コマンドを生成する。デバイスドライバは、ＡＰＩミドルウェアによって生成された描画コマンドをコマンドバッファ領域５０―２にバッファリングした後、新たな処理を開始できるタイミングで、描画コマンドを用いて描画処理を行い、描画処理結果である画像描画用データ（例えばピクセルデータ）をフレームメモリ３０に格納し、その後出力装置７０から所定の出力がなされる。
【００２５】
クライアント２は、サーバ１から送信された、例えば、画像データ等のデータを受信して表示するパーソナル・コンピュータ、シンクライアント端末等の情報処理装置である。ＣＰＵ１１と、ＮＩＣ３１、プログラム記憶部４１、メインメモリ５１、入力装置６１及び出力装置７１を備える情報処理装置であり、ＣＰＵ１１、ＮＩＣ３１、プログラム記憶装置４１、メインメモリ５１、入力装置６１及び表示装置７１は、それぞれデータ転送等のためのバス８１を介して接続されている。基本的な構成要素はサーバ１と同様であるので重複する説明は省略する。
【００２６】
図２に、本実施の形態におけるサーバ１およびクライアント２の機能ブロック図を示す。
【００２７】
本実施の形態におけるサーバ１は、表示部１０１と、キャプチャ部１０２と、エンコード部１０３と、データ格納部１０４と、原因判断部１０５と、データ送信部１０６とを備えている。
【００２８】
表示部１０１は、映像等の動画像データを表示する機能を有している。データは画像データに限らず任意の種類のデータであってよい。なお、出力装置７０により実現されてよい。
【００２９】
キャプチャ部１０２は、画面のキャプチャであれば、デスクトップやアクティブ・ウインドウの画面を画像ファイルとして保存する機能を有している。なお、ＣＰＵ１０により実現されてよい。
【００３０】
エンコード部１０３は、キャプチャ部１０２がキャプチャした出力装置７０のデスクトップ画面等の画像データをエンコードしてデバイスドライバの配下のメインメモリ５０のグラフィックデータバッファ領域５０―１に出力する機能を有している。なお、エンコーダ２０により実現されてよい。
【００３１】
データ格納部１０４は、キャプチャ部１０２によりキャプチャした画像データをエンコード部１０３がエンコードしたデータを格納する機能を有している。なお、メインメモリ５０のグラフィックデータバッファ領域５０―１により実現されてよい。
【００３２】
原因判断部１０５は、メインメモリ５０のグラフィックデータバッファ領域５０―１にデータが格納され、空き容量が少なくなっている原因を判断する機能を有している。なお、ＣＰＵ１０により実現されてよい。具体的な判断手法については後述する。
【００３３】
データ送信部１０６は、クライアント２へ各種のデータを送信する機能を有している。なお、ＣＰＵ１０、アプリケーションソフトウェアおよびＮＩＣ３０により実現されてよい。
【００３４】
本実施の形態におけるクライアント２は、データ受信部２０１と、表示部２０２と、操作受付部２０３とを備えている。
【００３５】
データ受信部２０１は、サーバ１から各種のデータを受信する機能を有している。なお、ＮＩＣ３１により実現されてよい。
【００３６】
表示部２０２は、映像等の動画像データや文字データ等を表示する機能を有している。データは画像データに限らず任意の種類のデータであってよい。なお、出力装置７１により実現されてよい。
【００３７】
操作受付部２０３は、ユーザの種々の指令の入力操作を受け付ける機能を有している。なお、入力装置６１により実現されてよい。
【００３８】
以下、本実施の形態の動作について図面を参照して詳細に説明する。
図３のフローチャートを参照すると、まず、サーバ１の表示部１０１は、出力装置７０のデスクトップ画面等に映像等の動画像データを表示する（Ｓ３０１）。
【００３９】
次に、サーバ１のキャプチャ部１０２は、画面のキャプチャとして、デスクトップやアクティブ・ウインドウの画面を画像ファイルとして保存する（Ｓ３０２）。
【００４０】
次に、サーバ１のエンコード部１０３は、キャプチャ部１０２がキャプチャした画像データをエンコードしてデバイスドライバの配下のメインメモリ５０のグラフィックデータバッファ領域５０―１に出力する（Ｓ３０３）。
【００４１】
そして、サーバ１のデータ格納部１０４は、上記のエンコード部１０３がエンコードしたデータをグラフィックデータバッファ領域５０―１に格納する（Ｓ３０４）。
【００４２】
サーバ１の原因判断部１０５は、メインメモリ５０のグラフィックデータバッファ領域５０―１にデータが格納され、空き容量が少なくなっている原因を判断する（Ｓ３０５）。
以下、空き容量が少なくなっている原因を判断する具体的な判断手法について説明する。ここで、一旦、図３から離れ、図４のフローチャートを参照する。
【００４３】
図４を参照すると、サーバ１の原因判断部１０５は、サーバ１のデータ送信部１０６からクライアント２へ送信されている各種のデータのデータ量を取得し、「送信ビットレート」を算出する。また、原因判断部１０５は、メインメモリ５０のグラフィックデータバッファ領域５０―１の空き容量を取得し、「バッファ空き容量」を算出する。また、原因判断部１０５は、メインメモリ５０のグラフィックデータバッファ領域５０―１に含まれるフレーム数を取得し、「バッファ中フレーム数」を算出する（Ｓ４０１）。ここではボトルネックとならない伝送帯域を１秒間に２０フレーム送信することができるものとする。
【００４４】
サーバ１の原因判断部１０５は、例えば、図５に示すように、上記の「バッファ空き容量」および「バッファ中フレーム数」のそれぞれにポイントによる重み付けをしておき、両方のポイントの合計値が所定の閾値（例えば「２」）以上となった場合に、バッファの空き容量が減少している（送信されるべきデータがボトルネックにより滞っている）と判断する（Ｓ４０２、Ｓ４０３）。バッファの空き容量が減少している状態の一例を図６に示す。なお、他の手法として、ボトルネックとならない伝送帯域を１秒間に２０フレーム送信することができるものとすると、原因判断部１０５は、１秒間に送信されるフレーム数を監視し、所定の閾値（例えば、５フレーム）以下しか送信できていない場合に、バッファの空き容量が減少している（送信されるべきデータがボトルネックにより滞っている）と判断することであってもよい。
【００４５】
さらに、サーバ１の原因判断部１０５は、バッファの空き容量が減少していると判断した場合（Ｓ４０２／Ｙｅｓ）、バッファの空き容量が減少していると判断した時点の「送信ビットレート」を現在の回線の「限界通信速度」として取得する（Ｓ４０４）。なぜならデータ送信量が回線の限界値に達するとバッファの空き容量が急激に減少するので、バッファの空き容量が減少していると判断した時点の「送信ビットレート」は現在の回線の「限界通信速度」とほぼ等しいと考えてよいからである。また、原因判断部１０５は、バッファの空き容量が減少していると判断した場合（Ｓ４０２／Ｙｅｓ）、バッファの空き容量が減少していると判断した時点の「必要ビットレート」を算出する（Ｓ４０４）。「必要ビットレート」はメインメモリ５０のグラフィックデータバッファ領域５０―１に格納されているデータを所定のフレームレート（ここでは、例えば１秒間に２０フレーム表示可能とする）で送信しようとする場合に必要となるビットレートのことをいう。具体的には、「必要ビットレート」＝（バッファサイズ−「バッファ空き容量」）／「バッファ中フレーム数」により求められる。なお、「必要ビットレート」はエンコード時のビットレートによることとしてもよい。
【００４６】
サーバ１の原因判断部１０５は、「必要ビットレート」と「限界通信速度」とを比較して（Ｓ４０５）、所定の閾値に基づいて「必要ビットレート」＞＞「限界通信速度」（差が大きく）であり、「必要ビットレート」−「限界通信速度」が閾値以上である場合（Ｓ４０５／Ｙｅｓ）、バッファの空き容量の減少（送信されるべきデータがボトルネックにより滞っている）の原因が、伝送帯域そのものが変動して小さくなっているので、解決手法として、回線自体をより伝送帯域の大きい回線に切り替えることや、ユーザのクライアント２での作業内容を変更すること等の指示メッセージデータを生成する（Ｓ４０６）。回線の切り替えとは、例えば、携帯電話機等のデバイスを利用することであったり、また有線と無線とを切り替えることであったり、無線のアクセスポイントを変更するための位置移動等であってよい。また、ユーザのクライアント２での作業内容の変更とは、例えば、エクセル（登録商標）等による細かい画面表示がなされている場合、モザイク状にしか表示されなくても問題ないスライドショー形式等であれば作業を続行してもよいが、その他の場合にはエクセル（登録商標）等による作業を中止することである。
一方、サーバ１の原因判断部１０５は、「必要ビットレート」と「限界通信速度」とを比較して（Ｓ４０５）、所定の閾値に基づいて「必要ビットレート」＞「限界通信速度」（差が小さく）であり、「必要ビットレート」−「限界通信速度」が閾値未満である場合（Ｓ４０５／Ｎｏ）、バッファの空き容量の減少（送信されるべきデータがボトルネックにより滞っている）の原因が、サーバ１からの動画像データのビットレートが高い（データ量が多い）ことに起因しているので、解決手法として、送信される動画像データのパラメータを変更してビットレートを低くすること等の指示メッセージデータやパラメータのレベルを示すデータを生成する（Ｓ４０７）。パラメータの変更とは、エンコード時のパラメータによってデータ量を調整可能であるので、圧縮率を高く（画像は劣化）してデータ量を低減させたり、また、画面の解像度を小さくしてデータ量を低減させたり、また、音声データは送らないことでデータ量を低減させたりすることであってよい。また、フレーム自体を間引くことでデータ量を低減させることも可能である。
【００４７】
図３のフローチャートに戻り、サーバ１のデータ送信部１０６は、上記のステップＳ４０６やステップＳ４０７で生成した指示メッセージデータ等をクライアント２へ送信する（Ｓ３０６）。指示メッセージデータ等のデータ量は少ないため、バッファの空き容量が減少している（送信されるべきデータがボトルネックにより滞っている）と判断されている通信環境下でも通信に与える影響は極めて限定的であり特に問題としない。
【００４８】
クライアント２のデータ受信部２０１は、サーバ１のデータ送信部１０６から指示メッセージデータ等を受信し、クライアント２の表示部２０２は、指示メッセージデータ等を表示する（Ｓ３０７）。具体的には、上記のステップＳ４０６で生成した回線自体をより伝送帯域の大きい回線に切り替えることや、ユーザのクライアント２での作業内容を変更すること等の指示メッセージデータを文字で画面に表示したり、また、上記のステップＳ４０７で生成した送信される動画像データのパラメータを変更してビットレートを低くすること等の指示メッセージデータを文字で画面に表示すると共にパラメータのレベルを示す図形データ（例えばレベル１〜６）を画面に表示してユーザが選択可能とする。なお、表示することのみに限定されなく、音声等で出力されユーザに伝達されることであってもよい。
また、本ステップＳ３０７で、上記のステップＳ４０６において伝送帯域そのものが変動して小さくなっているので、解決手法として、回線自体をより伝送帯域の大きい回線に切り替えるべきと判断されているときに、クライアント２側で指示メッセージデータ等を表示することなく、クライアント２の所定の制御部により自動的に回線を切り替える処理がなされてもよい。
【００４９】
クライアント２の操作受付部２０３は、ユーザの種々の指令の入力操作を受け付ける（Ｓ３０８）。例えば、回線を切り替える入力操作や動画像データのパラメータを変更する入力操作である。クライアント２の所定の制御部により入力操作に応じた指令の処理がなされる。
【００５０】
なお、上述する各実施の形態は、本発明の好適な実施の形態であり、本発明の要旨を逸脱しない範囲内において種々変更実施が可能である。例えば、サーバ１およびクライアント２の機能を実現するためのプログラムを各装置に読込ませて実行することにより各装置の機能を実現する処理を行ってもよい。さらに、そのプログラムは、コンピュータ読み取り可能な記録媒体であるＣＤ−ＲＯＭまたは光磁気ディスクなどを介して、または伝送媒体であるインターネット、電話回線などを介して伝送波により他のコンピュータシステムに伝送されてもよい。
【符号の説明】
【００５１】
１ サーバ
２ クライアント
３ 無線ネットワーク
１０、１１ ＣＰＵ
２０ エンコーダ
３０、３１ ＮＩＣ
４０、４１ プログラム記憶部
５０、５１ メインメモリ
５０―１ グラフィックデータバッファ領域
５０―２ コマンドバッファ領域
６０、６１ 入力装置
７０、７１ 出力装置
８０、８１ バス
【特許請求の範囲】
【請求項１】
伝送帯域が保証されない通信網を利用したデータ通信の際に、自装置のバッファの空き容量の減少の原因を判断し、該原因に応じた解決のための情報をデータ受信側の装置に送信することを特徴とするデータ通信装置。
【請求項２】
前記バッファの空き容量が減少していると判断した時点の送信ビットレートを限界通信速度として取得し、
前記バッファの空き容量が減少していると判断した時点の、前記バッファに格納されているデータを所定のフレームレートで送信しようとする場合に必要となるビットレートを必要ビットレートとして算出し、
前記必要ビットレートと前記限界通信速度との差分が閾値以上であるか判断し、前記閾値以上である場合、前記バッファの空き容量の減少の原因が、前記伝送帯域そのものが変動して小さくなっていることに起因していると判断し、
一方、前記閾値未満である場合、前記バッファの空き容量の減少の原因が、自装置から前記データ受信側の装置に送信するデータのビットレートが高いことに起因していると判断することを特徴とする請求項１記載のデータ通信装置。
【請求項３】
前記バッファの空き容量の減少の原因が、前記伝送帯域そのものが変動して小さくなっていることに起因していると判断した場合、前記解決のための情報として、回線自体をより伝送帯域の大きい回線に切り替えること、および、ユーザの前記データ受信側の装置での作業内容を変更することの少なくともいずれかを含む指示メッセージデータを生成することを特徴とする請求項１または２記載のデータ通信装置。
【請求項４】
前記バッファの空き容量の減少の原因が、自装置から前記データ受信側の装置に送信するデータのビットレートが高いことに起因していると判断した場合、前記解決のための情報として、送信されるデータのパラメータを変更してビットレートを低くするための指示メッセージデータを生成することを特徴とする請求項１から３のいずれか１項に記載のデータ通信装置。
【請求項５】
前記バッファの空き容量および前記バッファに格納されているフレーム数のそれぞれにポイントによる重み付けをしておき、両方のポイントの合計値が所定の閾値以上となった場合に、前記バッファの空き容量が減少していると判断することを特徴とする請求項１から４のいずれか１項に記載のデータ通信装置。
【請求項６】
伝送帯域が保証されない通信網を利用したデータ通信を行うデータ通信システムであって、データ送信側の装置は自装置のバッファの空き容量の減少の原因を判断し、該原因に応じた解決のための情報をデータ受信側の装置に送信することを特徴とするデータ通信システム。
【請求項７】
前記データ送信側の装置は、前記バッファの空き容量が減少していると判断した時点の送信ビットレートを限界通信速度として取得し、
前記バッファの空き容量が減少していると判断した時点の、前記バッファに格納されているデータを所定のフレームレートで送信しようとする場合に必要となるビットレートを必要ビットレートとして算出し、
前記必要ビットレートと前記限界通信速度との差分が閾値以上であるか判断し、前記閾値以上である場合、前記バッファの空き容量の減少の原因が、前記伝送帯域そのものが変動して小さくなっていることに起因していると判断し、
一方、前記閾値未満である場合、前記バッファの空き容量の減少の原因が、自データ送信側の装置から前記データ受信側の装置に送信するデータのビットレートが高いことに起因していると判断することを特徴とする請求項６記載のデータ通信システム。
【請求項８】
前記データ送信側の装置は、前記バッファの空き容量の減少の原因が、前記伝送帯域そのものが変動して小さくなっていることに起因していると判断した場合、前記解決のための情報として、回線自体をより伝送帯域の大きい回線に切り替えること、および、ユーザの前記データ受信側の装置での作業内容を変更することの少なくともいずれかを含む指示メッセージデータを生成することを特徴とする請求項６または７記載のデータ通信システム。
【請求項９】
前記データ送信側の装置は、前記バッファの空き容量の減少の原因が、自データ送信側の装置から前記データ受信側の装置に送信するデータのビットレートが高いことに起因していると判断した場合、前記解決のための情報として、送信されるデータのパラメータを変更してビットレートを低くするための指示メッセージデータを生成することを特徴とする請求項６から８のいずれか１項に記載のデータ通信システム。
【請求項１０】
前記データ送信側の装置は、前記バッファの空き容量および前記バッファに格納されているフレーム数のそれぞれにポイントによる重み付けをしておき、両方のポイントの合計値が所定の閾値以上となった場合に、前記バッファの空き容量が減少していると判断することを特徴とする請求項６から９のいずれか１項に記載のデータ通信システム。
【請求項１１】
伝送帯域が保証されない通信網を利用したデータ通信の際に、データ送信側の装置が自装置のバッファの空き容量の減少の原因を判断するステップと、データ送信側の装置が前記原因に応じた解決のための情報をデータ受信側の装置に送信するステップとを有することを特徴とするデータ通信方法。
【請求項１２】
伝送帯域が保証されない通信網を利用したデータ通信の際に、データ送信側のコンピュータに、
自コンピュータのバッファの空き容量の減少の原因を判断する処理と、該原因に応じた解決のための情報をデータ受信側の装置に送信する処理とを実行させることを特徴とするプログラム。
【請求項１】
伝送帯域が保証されない通信網を利用したデータ通信の際に、自装置のバッファの空き容量の減少の原因を判断し、該原因に応じた解決のための情報をデータ受信側の装置に送信することを特徴とするデータ通信装置。
【請求項２】
前記バッファの空き容量が減少していると判断した時点の送信ビットレートを限界通信速度として取得し、
前記バッファの空き容量が減少していると判断した時点の、前記バッファに格納されているデータを所定のフレームレートで送信しようとする場合に必要となるビットレートを必要ビットレートとして算出し、
前記必要ビットレートと前記限界通信速度との差分が閾値以上であるか判断し、前記閾値以上である場合、前記バッファの空き容量の減少の原因が、前記伝送帯域そのものが変動して小さくなっていることに起因していると判断し、
一方、前記閾値未満である場合、前記バッファの空き容量の減少の原因が、自装置から前記データ受信側の装置に送信するデータのビットレートが高いことに起因していると判断することを特徴とする請求項１記載のデータ通信装置。
【請求項３】
前記バッファの空き容量の減少の原因が、前記伝送帯域そのものが変動して小さくなっていることに起因していると判断した場合、前記解決のための情報として、回線自体をより伝送帯域の大きい回線に切り替えること、および、ユーザの前記データ受信側の装置での作業内容を変更することの少なくともいずれかを含む指示メッセージデータを生成することを特徴とする請求項１または２記載のデータ通信装置。
【請求項４】
前記バッファの空き容量の減少の原因が、自装置から前記データ受信側の装置に送信するデータのビットレートが高いことに起因していると判断した場合、前記解決のための情報として、送信されるデータのパラメータを変更してビットレートを低くするための指示メッセージデータを生成することを特徴とする請求項１から３のいずれか１項に記載のデータ通信装置。
【請求項５】
前記バッファの空き容量および前記バッファに格納されているフレーム数のそれぞれにポイントによる重み付けをしておき、両方のポイントの合計値が所定の閾値以上となった場合に、前記バッファの空き容量が減少していると判断することを特徴とする請求項１から４のいずれか１項に記載のデータ通信装置。
【請求項６】
伝送帯域が保証されない通信網を利用したデータ通信を行うデータ通信システムであって、データ送信側の装置は自装置のバッファの空き容量の減少の原因を判断し、該原因に応じた解決のための情報をデータ受信側の装置に送信することを特徴とするデータ通信システム。
【請求項７】
前記データ送信側の装置は、前記バッファの空き容量が減少していると判断した時点の送信ビットレートを限界通信速度として取得し、
前記バッファの空き容量が減少していると判断した時点の、前記バッファに格納されているデータを所定のフレームレートで送信しようとする場合に必要となるビットレートを必要ビットレートとして算出し、
前記必要ビットレートと前記限界通信速度との差分が閾値以上であるか判断し、前記閾値以上である場合、前記バッファの空き容量の減少の原因が、前記伝送帯域そのものが変動して小さくなっていることに起因していると判断し、
一方、前記閾値未満である場合、前記バッファの空き容量の減少の原因が、自データ送信側の装置から前記データ受信側の装置に送信するデータのビットレートが高いことに起因していると判断することを特徴とする請求項６記載のデータ通信システム。
【請求項８】
前記データ送信側の装置は、前記バッファの空き容量の減少の原因が、前記伝送帯域そのものが変動して小さくなっていることに起因していると判断した場合、前記解決のための情報として、回線自体をより伝送帯域の大きい回線に切り替えること、および、ユーザの前記データ受信側の装置での作業内容を変更することの少なくともいずれかを含む指示メッセージデータを生成することを特徴とする請求項６または７記載のデータ通信システム。
【請求項９】
前記データ送信側の装置は、前記バッファの空き容量の減少の原因が、自データ送信側の装置から前記データ受信側の装置に送信するデータのビットレートが高いことに起因していると判断した場合、前記解決のための情報として、送信されるデータのパラメータを変更してビットレートを低くするための指示メッセージデータを生成することを特徴とする請求項６から８のいずれか１項に記載のデータ通信システム。
【請求項１０】
前記データ送信側の装置は、前記バッファの空き容量および前記バッファに格納されているフレーム数のそれぞれにポイントによる重み付けをしておき、両方のポイントの合計値が所定の閾値以上となった場合に、前記バッファの空き容量が減少していると判断することを特徴とする請求項６から９のいずれか１項に記載のデータ通信システム。
【請求項１１】
伝送帯域が保証されない通信網を利用したデータ通信の際に、データ送信側の装置が自装置のバッファの空き容量の減少の原因を判断するステップと、データ送信側の装置が前記原因に応じた解決のための情報をデータ受信側の装置に送信するステップとを有することを特徴とするデータ通信方法。
【請求項１２】
伝送帯域が保証されない通信網を利用したデータ通信の際に、データ送信側のコンピュータに、
自コンピュータのバッファの空き容量の減少の原因を判断する処理と、該原因に応じた解決のための情報をデータ受信側の装置に送信する処理とを実行させることを特徴とするプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図２】
【図３】
【図４】
【図５】
【図６】
【公開番号】特開２０１１−７７６７０（Ｐ２０１１−７７６７０Ａ）
【公開日】平成２３年４月１４日（２０１１．４．１４）
【国際特許分類】
【出願番号】特願２００９−２２４９７７（Ｐ２００９−２２４９７７）
【出願日】平成２１年９月２９日（２００９．９．２９）
【出願人】（３０２０６９９３０）ＮＥＣパーソナルプロダクツ株式会社 (738)
【Ｆターム（参考）】
【公開日】平成２３年４月１４日（２０１１．４．１４）
【国際特許分類】
【出願日】平成２１年９月２９日（２００９．９．２９）
【出願人】（３０２０６９９３０）ＮＥＣパーソナルプロダクツ株式会社 (738)
【Ｆターム（参考）】
[ Back to top ]