(57)【要約】【課題】  ＴＣＰとＵＤＰとを切り替えてデータ通信を行うデータ通信方式及び電子会議システムを提供する。【解決手段】  クライアント２は、サーバ１に対してＵＤＰで送信し（Ｓ１）、サーバ１は共有を許可すると、クライアント２へ許可を通知するパケットを送信すると共に、クライアント２のネットワークアドレスを記憶する（Ｓ２，Ｓ３）。クライアント２は、サーバのネットワークアドレスを記憶し、画面データを受信して表示する準備を整える（Ｓ４）。サーバからクライアントに対して初期画面データがＵＤＰで送信され（Ｓ５ａ）、サーバの共有画面領域に更新がある度に画面データがＵＤＰで送信される（Ｓ５ｂ，Ｓ５ｃ，Ｓ５ｄ）。画面共有を終了する場合は、クライアントから切断要求をＵＤＰでサーバに送信し（Ｓ７）、切断要求を受信したサーバは切断の確認をＵＤＰでクライアントへ送信すると共に、該クライアントへの送受信の設定を解除する（Ｓ８，Ｓ９）。一方、切断ＯＫを受信したクライアントはサーバへの送受信の設定を解除する（Ｓ１０）。【選択図】  図２
2005348262.tif 000002
【特許請求の範囲】
【請求項１】
サーバとして機能する情報機器と、
前記サーバのクライアントとして機能する情報機器を構成要素とし、
前記サーバは、その表示画面の少なくとも一部に関するデータを、前記クライアントにＩＰプロトコルを用いて通信を行うネットワークを介して送信する手段を有し、
前記クライアントは、前記サーバから受信した画面データを表示装置に表示することにより、前記サーバの表示画面を共有する手段を有するネットワークシステムにおけるデータ通信方式であって、
送信する画面領域のデータの種類または表示条件、クライアントとの通信環境、あるいはユーザが与える指示の何れかによって、前記サーバは前記画面データを送信する場合に、送信する画面データの少なくとも一部を、ＴＣＰパケットを用いて送信するか、もしくはＵＤＰパケットを用いて送信するかを切り替えて送信する手段を有することを特徴とするデータ通信方式。
【請求項２】
前記サーバは、ＵＤＰマルチキャストまたはＵＤＰブロードキャストパケットを用いて複数の前記クライアントに対して、画面データを同報通信方式で送信する手段を有することを特徴とする請求項１記載のデータ通信方式。
【請求項３】
前記サーバは、アプリケーションプログラム毎にＴＣＰパケットで画面データを送信するか、もしくはＵＤＰパケットで送信するかを登録する手段を有し、
ＴＣＰパケットで送信するよう登録されたアプリケーションプログラムの画面データはＴＣＰパケットで送信し、
ＵＤＰパケットで送信するよう登録されたアプリケーションプログアムの画面データは、ＵＤＰパケットで送信することを特徴する請求項１または２に記載のデータ通信方式。
【請求項４】
前記サーバは、アプリケーションプログラムのウィンドウが、最前面に表示されているか、否かを判定する手段を有し、
最前面に表示されたウィンドウの画面データを送信する場合はＴＣＰパケットで送信し、
最前面にないウィンドウ、またはデスクトップ画面の画面データは、ＵＤＰパケットで送信することを特徴する請求項１または２に記載のデータ通信方式。
【請求項５】
前記サーバは、アプリケーションプログラムのウィンドウ上に、アクティブであるか、否かを判定する手段を有し、
アクティブウィンドウの画面データを送信する場合はＴＣＰパケットで送信し、
非アクティブウィンドウ、またはデスクトップ画面の画面データは、ＵＤＰパケットで送信することを特徴する請求項１または２に記載のデータ通信方式。
【請求項６】
前記サーバは、起動中のアプリケーションプログラムに対し、ＴＣＰパケットで画面データを送信するか、もしくはＵＤＰパケットで送信するかをユーザが指示する手段を有し、
ＴＣＰパケットで送信するよう登録されたアプリケーションプログラムの画面データはＴＣＰパケットで送信し、
ＵＤＰパケットで送信するよう登録されたアプリケーションプログアムの画面データはＵＤＰパケットで送信することを特徴する請求項１または２に記載のデータ通信方式。
【請求項７】
前記サーバは、共有している画面領域のうち任意の領域に関して、ＴＣＰパケットで画面データを送信するか、もしくはＵＤＰパケットで送信するかをユーザが指示する手段を有し、
ＴＣＰパケットで送信するよう登録された画面領域の画面データはＴＣＰパケットで送信し、
ＵＤＰパケットで送信するよう登録された画面領域の画面データはＵＤＰパケットで送信することを特徴する請求項１または２に記載のデータ通信方式。
【請求項８】
前記サーバは、ユーザの指示により、画面データを送信するプロトコルを切り替える手段を有し、
ユーザがＴＣＰプロトコル送信するよう指示した場合はＴＣＰパケットで画面データを送信し、
ユーザがＵＤＰプロトコル送信するよう指示した場合はＵＤＰパケットで画面データを送信することを特徴する請求項１または２に記載のデータ通信方式。
【請求項９】
前記サーバは、接続クライアント数を管理する手段と、
接続クライアント数に応じて画面データの送信をＴＣＰプロトコルで行うか、もしくはＵＤＰプロトコルで送信するかを切り替える手段を有し、
前記接続クライアント数が所定の数より少ない場合は、ＴＣＰパケットで画面データを送信し、
前記接続クライアント数が所定の数より多い場合は、ＵＤＰパケットで画面データを送信することを特徴する請求項１または２に記載のデータ通信方式。
【請求項１０】
前記サーバは、接続クライアント数が有線ＬＡＮで接続されているか、もしくは途中で無線ＬＡＮを介して接続されているかを管理する手段を有し、
無線ＬＡＮを介して接続しているクライアントに対しては、ＴＣＰパケットで画面データを送信し、
有線ＬＡＮのみで接続されているクライアントに対しては、ＵＤＰパケットで画面データを送信することを特徴する請求項１または２に記載のデータ通信方式。
【請求項１１】
前記サーバは、接続クライアント数がＬＡＮで接続されているか、もしくはＷＡＮを介して接続されているかを管理する手段を有し、
ＷＡＮを介して接続しているクライアントに対しては、ＴＣＰパケットで画面データを送信し、
ＬＡＮで接続されているクライアントに対しては、ＵＤＰプロトコル送信するよう指示した場合は、ＵＤパケットで画面データを送信することを特徴する請求項１または２に記載のデータ通信方式。
【請求項１２】
前記サーバは、送信する画面データの残量、または画面データの送信レートを測定する手段を有し、
前記画面データ送信の残量または画面データの送信レートが所定の値より小さい場合は、ＴＣＰパケットで画面データを送信し、
前記画面データ送信の残量または画面データの送信レートが所定の値を超える場合は、ＵＤＰパケットで画面データを送信することを特徴する請求項１または２に記載のデータ通信方式。
【請求項１３】
前記サーバは、該サーバと接続クライアントとの間での、ネットワークの通信速度を測定する手段を有し、
前記通信速度が所定の値より小さい場合は、ＵＤＰパケットで画面データを送信し、
前記通信速度が所定の値を超える場合は、ＴＣＰパケットで画面データを送信することを特徴する請求項１または２に記載のデータ通信方式。
【請求項１４】
前記サーバは、該サーバと接続クライアントとの間で、１つのパケットで送信可能なデータ容量（ＭＴＵ）を測定する手段を有し、
前記ＭＴＵが所定の値より小さい場合は、ＵＤＰパケットで画面データを送信し、
前記ＭＴＵが所定の値を超える場合は、ＴＣＰパケットで画面データを送信することを特徴する請求項１または２に記載のデータ通信方式。
【請求項１５】
前記サーバは、該サーバと接続クライアントとの間での、ネットワークのＱｏＳを測定する手段を有し、
前記ＱｏＳが所定の値より小さい場合は、ＴＣＰパケットで画面データを送信し、
前記ＱｏＳが所定の値を超える場合は、ＵＤＰパケットで画面データを送信することを特徴する請求項１または２に記載のデータ通信方式。
【請求項１６】
前記サーバは、接続クライアントの優先権を管理する手段を有し、
優先権の与えられているクライアントに対しては、ＴＣＰパケットで画面データを送信し、
優先権が与えられていないクライアントに対しては、ＵＤＰパケットで画面データを送信することを特徴する請求項１または２に記載のデータ通信方式。
【請求項１７】
前記サーバは、クライアントからの入力イベントを受信し、受信した入力イベントをサーバに転送する手段と、
前記クライアントが一定時間内に入力イベントを前記サーバに送信したかを管理する手段とを有し、
一定時間内に入力イベントを前記サーバに送信したクライアントに対しては、ＴＣＰパケットで画面データを送信し、
一定時間内に入力イベントを前記サーバに送信していないクライアントに対しては、ＵＤＰパケットで画面データを送信することを特徴する請求項１または２に記載のデータ通信方式。
【請求項１８】
前記サーバは、画面データを送信する際、送信領域の画面データが文字データを含むものであるか否かを、ＯＳがフォント描画命令を行っている領域であるか否かによって判断する手段を有し、
文字データを含む領域の画面データはＴＣＰパケットで送信し、
文字データを含まない領域の画面データはＵＤＰパケットで送信することを特徴する請求項１または２に記載のデータ通信方式。
【請求項１９】
前記サーバは、該サーバのＣＰＵ負荷が所定の負荷量を超えているかどうかを判断する手段を有し、
ＣＰＵ負荷が所定の負荷量以下の場合は、ＴＣＰパケットで画面データを送信し、
ＣＰＵ負荷が所定の負荷量を超えている場合は、ＵＤＰパケットで画面データを送信することを特徴する請求項２記載のデータ通信方式。
【請求項２０】
サーバとして機能する情報機器と、
前記サーバのクライアントとして機能する情報機器を構成要素とし、
前記サーバは、その表示画面の少なくとも一部に関するデータを、前記クライアントにＩＰプロトコルを用いて通信を行うネットワークを介して送信する手段を有し、
前記クライアントは、前記サーバから受信した画面データを表示装置に表示することにより、前記サーバの表示画面を共有する手段を有するネットワークシステムにおけるデータ通信方式であって、
前記ネットワークシステムは、前記サーバから受信した画面データを前記クライアントへと中継する中継機器を含み、
前記中継機器は、前記サーバからＴＣＰパケットで受信した画面データをＵＤＰパケットで前記クライアントに送信する手段を有することを特徴とするデータ通信方式。
【請求項２１】
前記中継機器は、ＵＤＰマルチキャストまたはＵＤＰブロードキャストパケットを用いて、複数の前記クライアントに対して画面データを同報通信方式で送信する手段を有することを特徴とする請求項２０記載のデータ通信方式。
【請求項２２】
前記中継機器は、前記サーバから受信した画面データを記録し、再生する手段を有することを特徴とする請求項２０または２１に記載のデータ通信方式。
【請求項２３】
会議サーバとして機能する情報機器と、
前記会議サーバの会議クライアントとして機能する情報機器を構成要素とし、
前記会議サーバは、その表示画面の少なくとも一部に関するデータを、前記会議クライアントにＩＰプロトコルを用いて通信を行うネットワークを介して送信する手段を有し、
前記会議クライアントは、前記会議サーバから受信した画面データを表示装置に表示することにより、前記会議サーバの表示画面を共有する手段を有する電子会議システムであって、
送信する画面領域のデータの種類または表示条件、会議クライアントとの通信環境、あるいはユーザが与える指示の何れかによって、前記会議サーバは前記画面データを送信する場合に、送信する画面データの少なくとも一部を、ＴＣＰパケットを用いて送信するか、もしくはＵＤＰパケットを用いて送信するかを切り替えて送信する手段を有することを特徴とする電子会議システム。
【請求項２４】
会議サーバとして機能する情報機器と、
前記会議サーバの会議クライアントとして機能する情報機器を構成要素とし、
前記会議サーバは、その表示画面の少なくとも一部に関するデータを、前記会議クライアントにＩＰプロトコルを用いて通信を行うネットワークを介して送信する手段を有し、
前記会議クライアントは、前記会議サーバから受信した画面データを表示装置に表示することにより、前記サーバの表示画面を共有する手段を有する電子会議システムであって、
前記ネットワークは、前記会議サーバから受信した画面データを前記会議クライアントへと中継する会議中継機器を含み、
前記会議中継機器は、前記会議サーバからＴＣＰパケットで受信した画面データをＵＤＰパケットで前記会議クライアントに送信する手段を有することを特徴とする電子会議システム。
【請求項２５】
前記会議サーバは、接続する会議クライアントの優先権を管理する手段を有し、
優先権の与えられている会議クライアントに対しては、ＴＣＰパケットで画面データを送信し、
優先権が与えられていない会議クライアントに対しては、ＵＤＰパケットで画面データを送信することを特徴とする請求項２３または２４に記載の電子会議システム。
【請求項２６】
前記会議サーバは、前記会議クライアントからの入力イベントを受信し、受信した入力イベントを前記会議サーバに転送する手段と、
接続会議クライアントが一定時間内に入力イベントを前記サーバに送信したかを管理する手段を有し、
一定時間内に入力イベントを会議サーバに送信した会議クライアントに対しては、ＴＣＰパケットで画面データを送信し、
一定時間内に入力イベントを会議サーバに送信していないクライアントに対しては、ＵＤＰパケットで画面データを送信することを特徴する請求項２３または２４に記載の電子会議システム。
【請求項２７】
サーバとして機能する情報機器と、前記サーバのクライアントとして機能する情報機器を構成要素とするネットワークシステムにおけるデータ通信方法であって、
前記サーバにおいて、その表示画面の少なくとも一部に関するデータを、前記クライアントにＩＰプロトコルを用いて通信を行うネットワークを介して送信する工程と、
前記クライアントにおいて、前記サーバから受信した画面データを表示装置に表示することにより、前記サーバの表示画面を共有する工程とを有し、
送信する画面領域のデータの種類または表示条件、クライアントとの通信環境、あるいはユーザが与える指示の何れかによって、前記サーバは前記画面データを送信する場合に、送信する画面データの少なくとも一部を、ＴＣＰパケットを用いて送信するか、もしくはＵＤＰパケットを用いて送信するかを切り替えて送信する工程を有することを特徴とするデータ通信方法。
【請求項２８】
サーバとして機能する情報機器と、前記サーバのクライアントとして機能する情報機器と、前記サーバから受信した画面データを前記クライアントへと中継する中継機器とを構成要素とするネットワークシステムにおけるデータ通信方法であって、
前記サーバにおいて、その表示画面の少なくとも一部に関するデータを、前記クライアントにＩＰプロトコルを用いて通信を行うネットワークを介して送信する工程と、
前記クライアントにおいて、前記サーバから受信した画面データを表示装置に表示することにより、前記サーバの表示画面を共有する工程と、
前記中継機器において、前記サーバからＴＣＰパケットで受信した画面データをＵＤＰパケットで前記クライアントに送信する工程を有することを特徴とするデータ通信方法。
【請求項２９】
請求項２７または２８に記載のデータ通信方法をコンピュータに実行させるためのデータ通信プログラム。
【請求項３０】
請求項２９に記載のデータ通信プログラムを格納したコンピュータが読み取り可能な記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ある情報機器の表示している画面データを、他の情報機器が共有することが可能な、または、更に他の情報機器からの遠隔操作が可能であるサーバ／クライアント型のデータ通信方式に関する。また、前記通信方式を利用した電子会議システムに関する。また、データ通信方法、データ通信プログラム及び記憶媒体に関する。
【背景技術】
【０００２】
近年、コンピュータシステムの処理高速化やネットワークの高速化等により、遠方のユーザと会議を行う電子会議システムが普及し始めている。電子会議システムに用いるソフトウェアとして、以下にあげるものが流通している。
【０００３】
１．Microsoft NetMeeting
米国Microsoft社の販売するWindows（登録商標）系列の一部のＯＳに、標準で搭載されている電子会議アプリケーションで、サーバのデスクトップ画面全体や、もしくは指定したアプリケーションの画面をクライアントから閲覧する、あるいは遠隔操作することが可能となっている。
【０００４】
２．VNC（Virtual Network Computing）
米国ＡＴ＆Ｔ社の開発した画面共有ソフトであり、基本的にはサーバのデスクトップ画面全体を共有する。ＲＦＢ（Remote Frame Buffer）プロトコルと呼ばれるプロトコルを用いて、サーバの画面領域の更新部分をエンコードし、クライアントに送信している。このVNCを元に開発されたソフトには、指定したアプリケーションの画面領域のみを共有したり、サーバのデスクトップ画面のうち指定した矩形領域のみを共有することが出来るよう改良されたものがある。画面データのエンコード方式に強力な圧縮を掛けたものなども開発されている。このような改良がなされたものとしては、例えば、TightVNC，eSVNC，VDACC VNC等のソフトが知られている。
【０００５】
他にも、画面共有をメイン機能とするソフトウェアとしては、シマンテック社のPC Anywhereや、LapLink Gold、ＰＣのリモート管理ツールとして、Danware社のNetOp Remote Controlや、Radmin社のRemote Administratorなどがある。
また、画面共有機能を利用した教育用途のソフトウェアとして、Danware社のNetOp Schoolや、Cross Tech社開発の、リモコン倶楽部for Schoolがある。
【０００６】
３．MulticastVNC
前記VNCのJava（登録商標）上で動作するクライアントソフトウェアの改良版であり、サーバの画面データを、複数のクライアントに中継する機能を有する。これにより、１つのサーバに、大量のクライアントが接続することにより、画面更新速度が低下するのを低減することが可能となっている。
【０００７】
４．Windows RemoteDesktop
Microsoft社のＯＳの一つである、Windows Xp Professionalでは、RemoteDesktopという画面共有機能が備わっている。これも、同様にRemoteDesktopサーバの画面データをRemoteDesktopクライアントで受信し、閲覧したり、クライアントからの遠隔操作を可能にしている。しかし、単純に画面データを送信するだけなので、クライアント機器でWindows MediaPlayerなどのソフトウェアで、ビデオ映像を閲覧しようとすると、コマ落ちが発生するという問題が指摘されている。
【０００８】
また、特許文献１には、コネクションレス型ネットワークを介して接続された会議出席者と、ブリッジを有するコネクション型ネットワークを介して接続された会議出席者との間でテレコンファレンス（電気的通信手段による会議）を行うことが可能なテレコンファレンス装置に関する技術が開示されている。
【特許文献１】特開平１０−２５７０５３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００９】
しかしながら、画面データの送信は、いずれもデータストリーム型の通信方式であるＴＣＰパケットを使用している。ＴＣＰ／ＩＰ通信においては、通信の確実性が保証されるが、パケットを受信したことに対する返答を行う、つまりＡＣＫパケットを返す必要がある。
一方、データグラム型の通信方式であるＵＤＰ／ＩＰ通信においては、パケットの受信に対して、ＡＣＫを返す必要がない。これにより、通信の確実性は保証されないが、通信速度が向上する。また、ＵＤＰパケットのヘッダは６４ビットであるのに対し、ＴＣＰは１８２ビットあり、このヘッダのオーバーヘッドが通信速度の低下の原因になる場合もある。特に、電子会議システムのように、１つのサーバに対して、複数のクライアントが画面共有によって、サーバ上に表示された文書の閲覧を行ったり、文書をクライアントから遠隔編集する場合には、１クライアント毎にＴＣＰ接続を確立させる必要があり、通信速度の低下を招き、クライアントの画面更新が遅くなり、利用者がストレスを感じたり、誤った遠隔操作を行ってしまう可能性も高くなる。例えば、単一のサーバに対して、１０台以上のクライアントが接続した場合、既存のソフトウェアでは、画面更新速度が落ちて、実用に耐えられなくなってしまう。
【００１０】
これを解決するため、MulticastVNCのように、中継機器を挟んでやることも可能であるが、中継機器での処理による画面更新の遅れが生じるため、中継機器を介して接続されるクライアントは、その台数が増えれば、それだけ画面更新速度は低下する。
【００１１】
本発明は上記事情を鑑みてなされたものであり、必要に応じて、ＴＣＰとＵＤＰとを切り替えてデータ通信を行うデータ通信方式、電子会議システム、データ通信方法、データ通信プログラム、記憶媒体を提供することを目的とする。
【課題を解決するための手段】
【００１２】
前記課題を解決するために、請求項１記載の発明は、サーバとして機能する情報機器と、前記サーバのクライアントとして機能する情報機器を構成要素とし、前記サーバは、その表示画面の少なくとも一部に関するデータを、前記クライアントにＩＰプロトコルを用いて通信を行うネットワークを介して送信する手段を有し、前記クライアントは、前記サーバから受信した画面データを表示装置に表示することにより、前記サーバの表示画面を共有する手段を有するネットワークシステムにおけるデータ通信方式であって、送信する画面領域のデータの種類または表示条件、クライアントとの通信環境、あるいはユーザが与える指示の何れかによって、前記サーバは前記画面データを送信する場合に、送信する画面データの少なくとも一部を、ＴＣＰパケットを用いて送信するか、もしくはＵＤＰパケットを用いて送信するかを切り替えて送信する手段を有することを特徴とする。
【００１３】
請求項２記載の発明は、前記サーバは、ＵＤＰマルチキャストまたはＵＤＰブロードキャストパケットを用いて複数の前記クライアントに対して、画面データを同報通信方式で送信する手段を有することを特徴とする。
【００１４】
請求項３記載の発明は、前記サーバは、アプリケーションプログラム毎にＴＣＰパケットで画面データを送信するか、もしくはＵＤＰパケットで送信するかを登録する手段を有し、ＴＣＰパケットで送信するよう登録されたアプリケーションプログラムの画面データはＴＣＰパケットで送信し、ＵＤＰパケットで送信するよう登録されたアプリケーションプログアムの画面データは、ＵＤＰパケットで送信することを特徴する。
【００１５】
請求項４記載の発明は、前記サーバは、アプリケーションプログラムのウィンドウが、最前面に表示されているか、否かを判定する手段を有し、最前面に表示されたウィンドウの画面データを送信する場合はＴＣＰパケットで送信し、最前面にないウィンドウ、またはデスクトップ画面の画面データは、ＵＤＰパケットで送信することを特徴する。
【００１６】
請求項５記載の発明は、前記サーバは、アプリケーションプログラムのウィンドウ上に、アクティブであるか、否かを判定する手段を有し、アクティブウィンドウの画面データを送信する場合はＴＣＰパケットで送信し、非アクティブウィンドウ、またはデスクトップ画面の画面データは、ＵＤＰパケットで送信することを特徴する。
【００１７】
請求項６記載の発明は、前記サーバは、起動中のアプリケーションプログラムに対し、ＴＣＰパケットで画面データを送信するか、もしくはＵＤＰパケットで送信するかをユーザが指示する手段を有し、ＴＣＰパケットで送信するよう登録されたアプリケーションプログラムの画面データはＴＣＰパケットで送信し、ＵＤＰパケットで送信するよう登録されたアプリケーションプログアムの画面データはＵＤＰパケットで送信することを特徴する。
【００１８】
請求項７記載の発明は、前記サーバは、共有している画面領域のうち任意の領域に関して、ＴＣＰパケットで画面データを送信するか、もしくはＵＤＰパケットで送信するかをユーザが指示する手段を有し、ＴＣＰパケットで送信するよう登録された画面領域の画面データはＴＣＰパケットで送信し、ＵＤＰパケットで送信するよう登録された画面領域の画面データはＵＤＰパケットで送信することを特徴する。
【００１９】
請求項８記載の発明は、前記サーバは、ユーザの指示により、画面データを送信するプロトコルを切り替える手段を有し、ユーザがＴＣＰプロトコル送信するよう指示した場合はＴＣＰパケットで画面データを送信し、ユーザがＵＤＰプロトコル送信するよう指示した場合はＵＤＰパケットで画面データを送信することを特徴する。
【００２０】
請求項９記載の発明は、前記サーバは、接続クライアント数を管理する手段と、接続クライアント数に応じて画面データの送信をＴＣＰプロトコルで行うか、もしくはＵＤＰプロトコルで送信するかを切り替える手段を有し、前記接続クライアント数が所定の数より少ない場合は、ＴＣＰパケットで画面データを送信し、前記接続クライアント数が所定の数より多い場合は、ＵＤＰパケットで画面データを送信することを特徴する。
【００２１】
請求項１０記載の発明は、前記サーバは、接続クライアント数が有線ＬＡＮで接続されているか、もしくは途中で無線ＬＡＮを介して接続されているかを管理する手段を有し、無線ＬＡＮを介して接続しているクライアントに対しては、ＴＣＰパケットで画面データを送信し、有線ＬＡＮのみで接続されているクライアントに対しては、ＵＤＰパケットで画面データを送信することを特徴する。
【００２２】
請求項１１記載の発明は、前記サーバは、接続クライアント数がＬＡＮで接続されているか、もしくはＷＡＮを介して接続されているかを管理する手段を有し、ＷＡＮを介して接続しているクライアントに対しては、ＴＣＰパケットで画面データを送信し、ＬＡＮで接続されているクライアントに対しては、ＵＤＰプロトコル送信するよう指示した場合は、ＵＤパケットで画面データを送信することを特徴する。
【００２３】
請求項１２記載の発明は、前記サーバは、送信する画面データの残量、または画面データの送信レートを測定する手段を有し、前記画面データ送信の残量または画面データの送信レートが所定の値より小さい場合は、ＴＣＰパケットで画面データを送信し、前記画面データ送信の残量または画面データの送信レートが所定の値を超える場合は、ＵＤＰパケットで画面データを送信することを特徴する。
【００２４】
請求項１３記載の発明は、前記サーバは、該サーバと接続クライアントとの間での、ネットワークの通信速度を測定する手段を有し、前記通信速度が所定の値より小さい場合は、ＵＤＰパケットで画面データを送信し、前記通信速度が所定の値を超える場合は、ＴＣＰパケットで画面データを送信することを特徴する。
【００２５】
請求項１４記載の発明は、前記サーバは、該サーバと接続クライアントとの間で、１つのパケットで送信可能なデータ容量（ＭＴＵ）を測定する手段を有し、前記ＭＴＵが所定の値より小さい場合は、ＵＤＰパケットで画面データを送信し、前記ＭＴＵが所定の値を超える場合は、ＴＣＰパケットで画面データを送信することを特徴する。
【００２６】
請求項１５記載の発明は、前記サーバは、該サーバと接続クライアントとの間での、ネットワークのＱｏＳを測定する手段を有し、前記ＱｏＳが所定の値より小さい場合は、ＴＣＰパケットで画面データを送信し、前記ＱｏＳが所定の値を超える場合は、ＵＤＰパケットで画面データを送信することを特徴する。
【００２７】
請求項１６記載の発明は、前記サーバは、接続クライアントの優先権を管理する手段を有し、優先権の与えられているクライアントに対しては、ＴＣＰパケットで画面データを送信し、優先権が与えられていないクライアントに対しては、ＵＤＰパケットで画面データを送信することを特徴する。
【００２８】
請求項１７記載の発明は、前記サーバは、クライアントからの入力イベントを受信し、受信した入力イベントをサーバに転送する手段と、前記クライアントが一定時間内に入力イベントを前記サーバに送信したかを管理する手段とを有し、一定時間内に入力イベントを前記サーバに送信したクライアントに対しては、ＴＣＰパケットで画面データを送信し、一定時間内に入力イベントを前記サーバに送信していないクライアントに対しては、ＵＤＰパケットで画面データを送信することを特徴する。
【００２９】
請求項１８記載の発明は、前記サーバは、画面データを送信する際、送信領域の画面データが文字データを含むものであるか否かを、ＯＳがフォント描画命令を行っている領域であるか否かによって判断する手段を有し、文字データを含む領域の画面データはＴＣＰパケットで送信し、文字データを含まない領域の画面データはＵＤＰパケットで送信することを特徴する。
【００３０】
請求項１９記載の発明は、前記サーバは、該サーバのＣＰＵ負荷が所定の負荷量を超えているかどうかを判断する手段を有し、ＣＰＵ負荷が所定の負荷量以下の場合は、ＴＣＰパケットで画面データを送信し、ＣＰＵ負荷が所定の負荷量を超えている場合は、ＵＤＰパケットで画面データを送信することを特徴する。
【００３１】
請求項２０記載の発明は、サーバとして機能する情報機器と、前記サーバのクライアントとして機能する情報機器を構成要素とし、前記サーバは、その表示画面の少なくとも一部に関するデータを、前記クライアントにＩＰプロトコルを用いて通信を行うネットワークを介して送信する手段を有し、前記クライアントは、前記サーバから受信した画面データを表示装置に表示することにより、前記サーバの表示画面を共有する手段を有するネットワークシステムにおけるデータ通信方式であって、前記ネットワークシステムは、前記サーバから受信した画面データを前記クライアントへと中継する中継機器を含み、前記中継機器は、前記サーバからＴＣＰパケットで受信した画面データをＵＤＰパケットで前記クライアントに送信する手段を有することを特徴とする。
【００３２】
請求項２１記載の発明は、前記中継機器は、ＵＤＰマルチキャストまたはＵＤＰブロードキャストパケットを用いて、複数の前記クライアントに対して画面データを同報通信方式で送信する手段を有することを特徴とする。
【００３３】
請求項２２記載の発明は、前記中継機器は、前記サーバから受信した画面データを記録し、再生する手段を有することを特徴とする。
【００３４】
請求項２３記載の発明は、会議サーバとして機能する情報機器と、前記会議サーバの会議クライアントとして機能する情報機器を構成要素とし、前記会議サーバは、その表示画面の少なくとも一部に関するデータを、前記会議クライアントにＩＰプロトコルを用いて通信を行うネットワークを介して送信する手段を有し、前記会議クライアントは、前記会議サーバから受信した画面データを表示装置に表示することにより、前記会議サーバの表示画面を共有する手段を有する電子会議システムであって、送信する画面領域のデータの種類または表示条件、会議クライアントとの通信環境、あるいはユーザが与える指示の何れかによって、前記会議サーバは前記画面データを送信する場合に、送信する画面データの少なくとも一部を、ＴＣＰパケットを用いて送信するか、もしくはＵＤＰパケットを用いて送信するかを切り替えて送信する手段を有することを特徴とする。
【００３５】
請求項２４記載の発明は、会議サーバとして機能する情報機器と、前記会議サーバの会議クライアントとして機能する情報機器を構成要素とし、前記会議サーバは、その表示画面の少なくとも一部に関するデータを、前記会議クライアントにＩＰプロトコルを用いて通信を行うネットワークを介して送信する手段を有し、前記会議クライアントは、前記会議サーバから受信した画面データを表示装置に表示することにより、前記サーバの表示画面を共有する手段を有する電子会議システムであって、前記ネットワークは、前記会議サーバから受信した画面データを前記会議クライアントへと中継する会議中継機器を含み、前記会議中継機器は、前記会議サーバからＴＣＰパケットで受信した画面データをＵＤＰパケットで前記会議クライアントに送信する手段を有することを特徴とする。
【００３６】
請求項２５記載の発明は、前記会議サーバは、接続する会議クライアントの優先権を管理する手段を有し、優先権の与えられている会議クライアントに対しては、ＴＣＰパケットで画面データを送信し、優先権が与えられていない会議クライアントに対しては、ＵＤＰパケットで画面データを送信することを特徴とする。
【００３７】
請求項２６記載の発明は、前記会議サーバは、前記会議クライアントからの入力イベントを受信し、受信した入力イベントを前記会議サーバに転送する手段と、接続会議クライアントが一定時間内に入力イベントを前記サーバに送信したかを管理する手段を有し、一定時間内に入力イベントを会議サーバに送信した会議クライアントに対しては、ＴＣＰパケットで画面データを送信し、一定時間内に入力イベントを会議サーバに送信していないクライアントに対しては、ＵＤＰパケットで画面データを送信することを特徴する。
【００３８】
請求項２７記載の発明は、サーバとして機能する情報機器と、前記サーバのクライアントとして機能する情報機器を構成要素とするネットワークシステムにおけるデータ通信方法であって、前記サーバにおいて、その表示画面の少なくとも一部に関するデータを、前記クライアントにＩＰプロトコルを用いて通信を行うネットワークを介して送信する工程と、前記クライアントにおいて、前記サーバから受信した画面データを表示装置に表示することにより、前記サーバの表示画面を共有する工程とを有し、送信する画面領域のデータの種類または表示条件、クライアントとの通信環境、あるいはユーザが与える指示の何れかによって、前記サーバは前記画面データを送信する場合に、送信する画面データの少なくとも一部を、ＴＣＰパケットを用いて送信するか、もしくはＵＤＰパケットを用いて送信するかを切り替えて送信する工程を有することを特徴とする。
【００３９】
請求項２８記載の発明は、サーバとして機能する情報機器と、前記サーバのクライアントとして機能する情報機器と、前記サーバから受信した画面データを前記クライアントへと中継する中継機器とを構成要素とするネットワークシステムにおけるデータ通信方法であって、前記サーバにおいて、その表示画面の少なくとも一部に関するデータを、前記クライアントにＩＰプロトコルを用いて通信を行うネットワークを介して送信する工程と、前記クライアントにおいて、前記サーバから受信した画面データを表示装置に表示することにより、前記サーバの表示画面を共有する工程と、前記中継機器において、前記サーバからＴＣＰパケットで受信した画面データをＵＤＰパケットで前記クライアントに送信する工程を有することを特徴とする。
【００４０】
請求項２９記載のデータ通信プログラムは、請求項２７または２８に記載のデータ通信方法をコンピュータに実行させることを特徴とする。
【００４１】
請求項３０記載のコンピュータが読み取り可能な記憶媒体は、請求項２９記載のデータ通信プログラムを格納することを特徴とする。
【発明の効果】
【００４２】
本発明によれば、下記の実施例の説明から明らかなように、送信パケットに対して、パケットを正常に受信したことを応答するＡＣＫパケットを返信する必要のある、データストリーム型の通信方式であるＴＣＰパケットによる通信だけでなく、ＡＣＫの返信の必要がないため高速であるが、信頼性や、パケットの受信順序を保証しないデータグラム型の通信方式であるＵＤＰパケットを用いて、画面データの送信を行う、高速な画面共有を行う、画面共有サーバと画面共有クライアント間の通信が可能となる。
【発明を実施するための最良の形態】
【００４３】
以下に、添付図面を参照しながら、本発明の実施形態を説明する。
【実施例１】
【００４４】
図１は、本発明の一実施例であるデータ通信システムのネットワーク構成を示した概要図である。
データ通信システムは、サーバとして機能する情報処理装置（サーバ１）と、前記サーバ１のクライアントとして機能する情報処理装置（クライアント２ａ，２ｂ，・・・，２ｎ）が、ＩＰネットワーク１０を介して接続されている。ＩＰネットワークとして、例えば、ＩＥＥＥ８０２．３で定められているイーサネット（登録商標）ＬＡＮ等がある。
【００４５】
サーバ１は表示装置を有し、該表示装置に表示される表示内容の全体または一部を共有画面とし、ＩＰネットワーク１０に接続されたクライアント２に対して共有画面データを送信する。クライアント２では、該共有画面データを受信することにより、該クライアントの表示装置にサーバ１の共有画面を表示することができる。
画面を共有する方法は、従来の技術をそのまま利用することができるので、詳細な説明を省略する。概略としては、サーバのアプリケーションが該サーバの画面データの更新部分を検出し、画面の更新領域を一定のアルゴリズムにより分割、エンコードして、クライアントに送信する。受信したクライアントは、更新された領域の画面データをデコードして、共有画面のデータを更新するという方法による。
【００４６】
従来の発明においては、画面データの送信をＴＣＰパケットで送信するようになっている。ＴＣＰはコネクション型（ＣＯ型）のプロトコルであって、コネクションレス型（ＣＬ型）のＩＰにおけるＩＰパケットの損失をカバーすることが可能な、信頼性の高いプロトコルである。しかしながら、データの転送効率が低下するという問題がある。
一方、本発明では、画面データをＵＤＰパケットで送信する機能を備えている。ＵＤＰはＣＬ型のプロトコルであって、データの信頼性はＴＣＰに劣るものの、高速データ転送が可能であるという利点を有する。
【００４７】
図２は、ＵＤＰパケットのみを送信することにより画面共有を行う方式の処理フローを示した図である。
初期状態として、サーバ１は、ＵＤＰポートを開け、ＵＤＰ用のソケットでクライアントからの接続を待ち受けている状態にある。
クライアント２は、サーバ１に対して画面共有の要求を行うために、ＵＤＰパケットを用いて送信する（ステップＳ１）。パケットを受信したサーバは共有を許可すると、共有の要求を行ったクライアントへ許可を通知するパケットを送信すると共に、共有を許可したクライアントのネットワークアドレス（ＩＰアドレス）を記憶する（ステップＳ２，Ｓ３）。これにより、共有の要求を行ったクライアントに対して、ＵＤＰパケットで画面データを送信できるようになると共に、該クライアントからの入力イベントを受信して、リモート操作を可能な状態にする。
【００４８】
サーバ１からの許可を受信したクライアントは、サーバのネットワークアドレスを記憶し、サーバからの画面データを受信して表示する準備を整える（ステップＳ４）。
すなわち、ＵＤＰポートを開け、ＵＤＰ用のソケットでサーバ１からの通信パケットを待ち受ける。
【００４９】
なお、ステップＳ１，Ｓ２における一往復のＵＤＰパケットの通信で要求・許可を行うのではなく、認証を行ってもよい。
また、図では省略したが、ここでクライアントとサーバは、共有する画面の大きさやエンコードの方法について、相互の設定を調整する通信が含まれる場合もある。
【００５０】
次に、準備が整うと、サーバ１からクライアント２に対して初期画面データがＵＤＰで送信される（ステップＳ５ａ）。その後は、サーバ１の共有画面領域に更新がある度に、画面データがＵＤＰパケットで送信される（ステップＳ５ｂ，Ｓ５ｃ，Ｓ５ｄ）。
また、クライアントが遠隔操作を行った場合には、入力イベントがＵＤＰパケットでサーバに送信される（ステップＳ６）。
【００５１】
画面共有を終了する場合には、クライアントから切断要求をＵＤＰパケットでサーバに送信する（ステップＳ７）。切断要求を受信したサーバは、切断の確認をＵＤＰパケットでクライアントへ送信すると共に、該クライアントへの送受信の設定を解除する（ステップＳ８，Ｓ９）。一方、切断ＯＫを受信したクライアントは、サーバへの送受信の設定を解除する（ステップＳ１０）。
【００５２】
ここで、図２に示した通信方式の場合、サーバとクライアントは、ＵＤＰパケットでお互いに一方的にデータを送信しているので、いつ相手が画面共有アプリケーションを終了したのか、或いはネットワークエラーによって通信不能になっているのか、切断ＯＫのパケットが届いていない、等を検出することができない。
そこで、図３に示すアルゴリズムで相手の監視を行う。
【００５３】
接続を確立した場合、サーバ及びクライアントは、タイマーを用いて、所定の時間毎に、例えば１分毎に、相手の接続を確認するための確認パケットを送信する（ステップＳ１１，Ｓ１２）。
【００５４】
一方で、それと共に、相手からの何らかのパケットが受信されたかどうかを、タイマーを用いて監視する。
例えば、２分間のタイマーで確認を行う。
パケット受信の確認を行い（ステップＳ２１）、データまたは確認パケットを受信すると（ステップＳ２２／Ｙｅｓ）、タイマーをスタートさせる（ステップＳ２３）。２分以内に何らかのパケットを受信した場合（ステップＳ２４／Ｙｅｓ）は、タイマーを再スタートする（ステップＳ２３）。２分以内に受信しなかった場合（ステップＳ２４／Ｎｏ，Ｓ２５／Ｙｅｓ）は、相手が切断したと判断し、相手との送受信の設定を解除する（ステップＳ２６）。
【００５５】
本実施例では、ＵＤＰパケットによって送信しているので、画面データや入力イベント等のパケットがネットワーク上で損失する場合があり、その通信は送信先には反映されない。また、送信側でのパケットの送信順序と、送信先でのパケットの受信順序が異なる場合もある。
よって、本発明は、ＬＡＮ等の短距離ネットワークで、データ通信量の大きいネットワーク回線上でサーバとクライアントが接続されている場合や、画面データの確実性よりも共有画面が頻繁に更新されるような場合に用いることが好ましい。
【００５６】
図１では、サーバ１として、大画面表示装置を備えるデスクトップ型ＰＣ、或いはワークステーション等を用いている。また、クライアント２として、ラックトップ型ＰＣ（ノートＰＣ）を用いているが、必ずしもこのような構成に限定されない。
すなわち、本発明において、サーバとは、ネットワークにおいて共有される画面データを有するコンピュータであり、従って、大画面表示装置を備えていなくても、また、クライアントとしてデスクトップＰＣを用いても構わない。
【００５７】
また、ネットワークの具体的な実施例は、イーサネット（登録商標）有線ＬＡＮに限定されることはなく、無線ＬＡＮ、ＩｒＤＡ、Ａｐｐｌｅ  Ｔａｌｋ、ＩＳＤＮ、電話交換網、デジタル専用線、ＦＲ網、・・・等によって接続されている場合や、これらの組み合わせで接続されている場合でもよい。
【実施例２】
【００５８】
実施例２は、前記実施例１で説明した方式の変更例である。
図４は、サーバとクライアントの接続にＴＣＰ／ＩＰ接続を利用し、画面データ及び入力イベントの送信にＵＤＰパケットを利用する方式の処理フローを示した図である。
サーバ１とクライアント２は共に、ＴＣＰとＵＤＰの２つのソケットを用意する。
ＴＣＰパケットで接続すると（ステップＳ３１，Ｓ３２，Ｓ３３）、同じネットワークアドレスのＵＤＰソケットを用いて、画面データや入力イベントの送受信を行う（ステップＳ３４ａ〜ｄ，Ｓ３５）。
ＴＣＰ接続の切断の要求を行い、ＴＣＰ接続を切断すると、ＵＤＰソケットも終了し、画面データ及び入力イベントの待ち受けを終了する（ステップＳ３６，Ｓ３７，Ｓ３８）。ＴＣＰはコネクション型の通信プロトコルであるので、相手との接続の管理はＴＣＰ接続の接続管理に任せ、特にアプリケーション側（上位レイヤ）で監視の機能を実装する必要はない。
【実施例３】
【００５９】
実施例３は、前記実施例２の方式に、更にＵＤＰマルチキャスト或いはＵＤＰブロードキャストを適用した例であり、図５にその処理フローを示す。
また、表１はネットワーク構成におけるネットワークアドレスの一例である。
【００６０】
【表１】
2005348262.tif 000003
【００６１】
＜１．ブロードキャストの場合＞
サーバ１は、ＵＤＰソケットで、（133. 139. 100. 111）と（133. 139. 100. 222）からの入力イベントを待ち受けている。また、画面データをブロードキャストアドレス（255. 255. 255. 255）で同一サブネット内にブロードキャスト送信する。パケットはＵＤＰパケットを用いる。
クライアント２ａ，２ｂは、（133. 139. 100. 100）からの画面データのブロードキャストを待ち受けている。また、入力イベントを（133. 139. 100. 100）にＵＤＰユニキャストで送信する。
クライアントは、サーバからブロードキャストされた画面データを受信して、画面共有を行う。
【００６２】
＜２．マルチキャストの場合＞
サーバとクライアントの接続確立時に、サーバ１は、全てのクライアントにマルチキャストアドレスを通知する。
サーバ１は、マルチキャストがクライアントに届くように、マルチキャストの範囲を設定する。すなわち、ＴＴＬ（Time To Live）の値を適切に設定する。
【００６３】
サーバ１は、ＵＤＰソケットで、（133. 139. 100. 111）と（133. 139. 100. 222）からの入力イベントを待ち受けている。また、画面データをマルチキャストアドレス（233. 233. 233. 233）でマルチキャスト送信する。パケットはＵＤＰパケットを用いる。
クライアント２ａ，２ｂは、サーバ１から指定されたマルチキャストアドレス（233. 233. 233. 233）からの画面データを待ち受けている。また、入力イベントを（133. 139. 100. 100）にＵＤＰユニキャストで送信する。
【実施例４】
【００６４】
実施例４は、サーバのアプリケーションの種類によって、ＴＣＰとＵＤＰを切り替えて送信する方式例であり、図６は、サーバの画面表示例である。
サーバ１は、予めＴＣＰパケットで送信するように設定したアプリケーションの画面データ１１を送信する場合は、ＴＣＰパケットにより送信し、それ以外の画面領域（ＵＴＤ共有アプリケーション画面１２等）は、ＵＤＰパケットを用いて送信する。
【００６５】
例えば、アプリケーションとして、ワードプロセッサソフトであるＷｏｒｄｐｒｏｃと、表計算ソフトであるＭａｔｒｉｘｃａｌｃというソフトウェアのみをＴＣＰパケットで送信し、画面共有を行っているクライアント側で確実に画面を表示したい場合を考える。
画面共有サーバプログラムに、ＴＣＰパケットで送信したいアプリケーションの実行ファイルのパスを登録する。例えば、
C:\Program Files\Wordproc\Wordproc.exe
C:\Program Files\Matrixcalc\Matrixcalc.exe
を登録する。
【００６６】
図７は、サーバのアプリケーション毎にＴＣＰまたはＵＤＰの何れかで送信する方式について、そのアルゴリズムを示した図である。
サーバ１の表示画面に更新があった場合、画面共有プログラムは、一定のアルゴリズムにより領域を分割して、エンコードするが、ここで分割した画面領域が、登録されたアプリケーションのウィンドウ領域であるか否かを判断する（ステップＳ５１）。
登録されたアプリケーションのウィンドウ領域である場合（ステップＳ５２／Ｙｅｓ）は、エンコード後、ＴＣＰパケットで送信するよう指示する（ステップＳ５３）。一方、それ以外の領域である場合（ステップＳ５２／Ｎｏ）は、ＵＤＰパケットで送信するよう指示を出す（ステップＳ５４）。
【００６７】
図８は、そのような場合に、ＴＣＰパケットとＵＤＰパケットを切り替えて送信する方式について、処理フローを例示したものである。
実施例２で示した処理フローと同様に、ＴＣＰ／ＩＰで接続管理を行っており（ステップＳ６１〜Ｓ６３、及びＳ６８〜Ｓ７０）、必要に応じて画面データをＴＣＰパケットとＵＤＰパケットに切り替えて送信している（ステップＳ６４〜Ｓ６６）。
【実施例５】
【００６８】
実施例５は、サーバのウィンドウが最前面に位置するか否かによって、ＴＣＰとＵＤＰを切り替えて送信する方式の例であり、図９は、サーバの画面表示例である。
図９において、最前面ウィンドウ１３の画面データを送信する際には、ＴＣＰパケットを用いて送信し、それ以外の画面領域（背面ウィンドウ１４等）は、ＵＤＰパケットを用いて送信する。
【００６９】
図１０は、サーバのウィンドウが最前面に位置するか否かによって、ＴＣＰとＵＤＰを切り替えて送信する方式について、そのアルゴリズムを示した図である。
サーバ１の表示画面に更新があった場合、画面共有プログラムは、一定のアルゴリズムにより領域を分割して、エンコードするが、ここで、分割した画面領域が、最前面にあるウィンドウ領域であるか否かを判断する（ステップＳ７１）。
最前面にあるウィンドウ領域である場合（ステップＳ７２／Ｙｅｓ）は、エンコード後、ＴＣＰパケットで送信するよう指示する（ステップＳ７３）。一方、それ以外の領域の場合（ステップＳ７２／Ｎｏ）は、ＵＤＰパケットで送信するよう指示を出す（ステップＳ７４）。
【実施例６】
【００７０】
実施例６は、サーバのウィンドウがアクティブであるか否かによって、ＴＣＰとＵＤＰを切り替えて送信する方式の例であり、図１１は、サーバの画面表示例である。
例えば、デスクトップ領域をマウスでクリックした場合など、最前面にあるウィンドウが必ずしもアクティブウィンドウであるとは限らないが、非アクティブであっても、最前面にあればＴＣＰパケット送信するようにすることも、あるいは非アクティブの場合、最前面であってもＵＤＰパケットで送信するようにすることも可能である。
【００７１】
図１１において、アクティブウィンドウ１５の画面データを送信する際には、ＴＣＰパケットを用いて送信し、それ以外の画面領域（非アクティブウィンドウ１６ａ，１６ｂ等）は、ＵＤＰパケットを用いて送信する。
【００７２】
図１２は、サーバのウィンドウがアクティブであるか否かによって、ＴＣＰとＵＤＰを切り替えて送信する方式について、そのアルゴリズムを示した図である。
サーバ１の表示画面に更新があった場合、画面共有プログラムは、一定のアルゴリズムにより領域を分割して、エンコードするが、ここで分割した画面領域が、アクティブウィンドウ領域であるか否かを判断する（ステップＳ８１）。
分割した画面領域がアクティブウィンドウ領域である場合（ステップＳ８２／Ｙｅｓ）は、エンコード後、ＴＣＰパケットで送信するよう指示する（ステップＳ８３）。一方、それ以外の領域の場合（ステップＳ８２／Ｎｏ）は、ＵＤＰパケットで送信するよう指示を出す（ステップＳ８４）。
【実施例７】
【００７３】
実施例７は、サーバのウィンドウがユーザの指定した文書であるか否かによって、ＴＣＰとＵＤＰを切り替えて送信する方式の例であり、図１３は、サーバの画面表示例である。
図１３において、ユーザ指定文書ウィンドウ１７の画面データを送信する際には、ＴＣＰパケットを用いて送信し、それ以外の領域（非ユーザ指定文書ウィンドウ１８等）は、ＵＤＰパケットを用いて送信する。
【００７４】
図１４は、サーバのウィンドウがユーザの指定した文書であるか否かによって、ＴＣＰとＵＤＰを切り替えて送信する方式について、そのアルゴリズムを示した図である。
サーバ１の表示画面に更新があった場合、画面共有プログラムは、一定のアルゴリズムにより領域を分割して、エンコードするが、ここで分割した画面領域がユーザの指定した文書のウィンドウ領域であるか否かを判断する（ステップＳ９１）。
分割した画面領域がアクティブウィンドウ領域である場合（ステップＳ９２／Ｙｅｓ）は、エンコード後、ＴＣＰパケットで送信するよう指示する（ステップＳ９３）。一方、それ以外の領域の場合（ステップＳ９３／Ｎｏ）は、ＵＤＰパケットで送信するよう指示を出す（ステップＳ９４）。
【００７５】
例えば、ＴＣＰで送信するウィンドウを文書毎に管理し、文書のパスを画面共有プログラムに登録する。例えば、
c:\My Documents\統計\2003Jan.pdf
と登録する。すると、この文書を開くアプリケーション（例えばAcrobat Reader（登録商標））のウィンドウで、該文書を開いているウィンドウ領域の画面データはＴＣＰパケットで送信される。
【００７６】
実施例７の変更例として、文書毎ではなく、ウィンドウ単位で指定することも可能である。
例えば、
c:\My Documents\統計\2003Jan.pdf
という文書を開いているプログラムAcrobat Reader（登録商標）のウィンドウを指定する。例えば、画面共有プログラムで、ＴＣＰパケットで画面送信するウィンドウを選択する機能を設け、この機能を実行すると、実行後最初にマウスでクリックしたウィンドウをＴＣＰパケットで画面データを送信するよう登録し、登録機能を終了するようにする。
【実施例８】
【００７７】
実施例８は、サーバのウィンドウがユーザの指定した画面領域であるか否かによって、ＴＣＰとＵＤＰを切り替えて送信する方式の例であり、図１５は、サーバの画面表示例である。
図１５に示すように、ユーザ指定領域１９の画面データを送信する際には、ＴＣＰパケットを用いて送信し、それ以外の領域は、ＵＤＰパケットを用いて送信する。
【００７８】
図１６は、サーバのウィンドウがユーザの指定した画面領域であるか否かによって、ＴＣＰとＵＤＰを切り替えて送信する方式について、そのアルゴリズムを示した図である。
サーバ１の表示画面に更新があった場合、画面共有プログラムは、一定のアルゴリズムにより領域を分割して、エンコードするが、ここで分割した画面領域が、ユーザの指定した画面領域であるか否かを判断する（ステップＳ１０１）。
ユーザが指定した画面領域である場合（ステップＳ１０２／Ｙｅｓ）は、エンコード後、ＴＣＰパケットで送信するよう指示を出す（ステップＳ１０３）。一方、それ以外の領域の場合（ステップＳ１０２／Ｎｏ）は、ＵＤＰパケットで送信するよう指示を出す（ステップＳ１０４）。
【００７９】
実施例８の変更例を以下に示す。
画面共有プログラムで、ＴＣＰパケットで画面送信する画面領域を選択する機能を設け、この機能を実行すると、実行後最初にマウスでクリックしたウィンドウを左上頂点とし、マウスをクリックした状態のまま移動させ、マウスクリックを放した位置を、右下頂点とする矩形領域をＴＣＰパケットで画面データを送信するよう登録し、登録機能を終了するようにする。最初にクリックした座標と、最後に放した場所の座標を取得して登録する。例えば、（１００，２００）でクリックを開始し、（４００，７００）までドラッグして、マウスを放した場合、この両点を対角線上にある２頂点とする矩形領域をＴＣＰ送信領域とする。
【００８０】
また、実施例４〜８において、ＴＣＰパケットでの送信を、ＵＤＰパケットでの送信より優先して行うことも可能である。これにより、必要とする部分の画面データが早く確実にクライアントの画面に表示することが可能である。
【実施例９】
【００８１】
実施例９では、画面データの送信において、ＴＣＰパケットにするかＵＤＰパケットにするかをユーザが切り替える手段について説明する。
図１７は、通信プロトコルの切り替え指示を行う画面を例示した図であり、サーバの画面共有プログラムにＴＣＰ／ＵＤＰを選択、切り替えを指示する機能を設ける。
【００８２】
図１８は、通信プロトコルの切り替え動作のフローを示した図である。
このように、最初デフォルト設定では、ＴＣＰ接続を確立したクライアントに対しては、ＴＣＰパケットで画面データを送信するように設定されているとする（ステップＳ１１１）。図１７のような画面共有プログラムの通信手段切り替え機能により、ＵＤＰパケットで送信するよう指示された場合（ステップＳ１１２／Ｙｅｓ）は、画面データをＵＤＰパケットで送信する（ステップＳ１１３）。また、逆にＴＣＰパケットに戻すことも可能である（ステップＳ１１４／Ｙｅｓ，Ｓ１１１）。
例えば、サーバでビデオ映像を再生する場合や、アニメーション効果をふんだんに用いたプレゼンテーションのスライドショーを行う場合、画面データの送信量が多くなり、確実性よりも、速度が要求される場合などに、ＵＤＰパケットで送信するモードに切り替える。一方、文字ばかりのデータを共有する場合は、確実に表示されないと困るので、ＴＣＰパケットを利用するように切り替える。
【００８３】
また、実施例９の変更例として、サーバ側のプログラムから切り替えるのでなく、クライアント側からＴＣＰとＵＤＰの切り替えを要求するようにしてもよい。
【実施例１０】
【００８４】
実施例１０では、ユーザ毎にＴＣＰパケットまたはＵＤＰパケットを用いるかを選択する手段について説明する。
図１９は、ユーザ毎に通信プロトコルの切り替え指示を行う画面を例示した図であり、クライアント毎にＴＣＰを用いるか、ＵＤＰを用いるかを選択することが可能である。
画面共有サーバは、クライアントのＩＰアドレスまたは、ホスト名、あるいは画面共有プログラムでやり取りする任意の識別名（例えば利用者の名前）を用いて、各クライアント毎の設定を変更する機能を有する。現在接続しているクライアントに対して、ＴＣＰとＵＤＰのどちらを用いて、画面データを送信しているかを、管理し、表示すると共に、その設定を変更する機能を有する。
【００８５】
図１９では、チェックの入っている「亜伊  上男」と「嵯支  須世曾」の２人がＴＣＰで送信するクライアントとして設定されていて、チェックの入っていない「柿  久華子」がＵＤＰで送信するクライアントとして設定されている。
また、図１９に示すように、「全員ＴＣＰ」ボタンの押下により、全員、ＴＣＰパケットで送信することも、また、「全員ＵＤＰ」ボタンの押下により、全員、ＵＤＰパケットで送信することも可であり、ネットワークに参加しているクライアントが多数の場合には、このような手段も有効である。
【実施例１１】
【００８６】
実施例１１は、クライアントの接続台数によって、ＴＣＰとＵＤＰを切り替えて送信する方式の例であり、図２０は、そのアルゴリズムを示した図である。
サーバ１の画面共有プログラムは、ネットワーク上のクライアントの接続台数を監視している（ステップＳ１２１）。
接続台数が所定の台数を超えたことを検出した場合（ステップＳ１２２／Ｙｅｓ）は、画面データを送信するのに用いる通信方式を、ＴＣＰからＵＤＰに切り替える（ステップＳ１２４）。これにより、クライアントの台数が多い場合に、通信量が増えて各クライアントの画面表示にディレイが生じるのを低減する。
また、ＵＤＰでの通信を行っている場合に、ネットワークに接続されているクライアントの台数が、所定の台数以下である場合（ステップＳ１２２／Ｎｏ）は、通信方式をＵＤＰからＴＣＰに切り替える（ステップＳ１２３）。接続台数が少なく、ネットワークのデータ通信量が小さい場合には、信頼性の高いＴＣＰにより通信を行う。
【００８７】
また、実施例１１の変更例として、接続台数が所定の台数を超えた場合に、図１９で示したダイアログを表示し、ＵＤＰに切り替えるクライアントを指定してもよいし、全クライアントをＵＤＰに切り替えてもよい。
【実施例１２】
【００８８】
実施例１２は、クライアントの通信インターフェースによって、ＴＣＰとＵＤＰを切り替えて送信する方式の例であり、図２１は、そのアルゴリズムを示した図である。
サーバ１上の画面共有プログラムは、クライアントが有線ＬＡＮでネットワークに接続しているか、無線ＬＡＮを介して接続しているかを取得する機能を有する。
クライアントは、自身の通信インターフェースに関する情報を、ＯＳのシステム情報から取得することが可能である。クライアントの画面共有プログラムは、サーバ１に接続する際、この通信インターフェース情報を送信する。
一方、サーバ１は、クライアントから送られた通信インターフェースの情報から、それが無線ＬＡＮかどうかを判定する。例えば、インターフェースの名前、あるいは無線ＬＡＮであれば、ＩＥＥＥ８０２．１１のどの規格のものであるか等の情報から判断する。
【００８９】
図２１に示すように、クライアントからの接続を受け付けた場合、クライアントの通信インターフェース情報を取得し、有線ＬＡＮか無線ＬＡＮかを判断する（ステップＳ１３１）。有線ＬＡＮの場合（ステップＳ１３２／Ｎｏ）は、ＵＤＰパケットで画面データを送信するよう設定し（ステップＳ１３４）、一方で無線ＬＡＮの場合（ステップＳ１３２／Ｙｅｓ）は、ＴＣＰパケットで画面データを送信するよう設定する（ステップＳ１３３）。
【００９０】
また、実施例１２の変更例として、サーバ１自身が無線ＬＡＮインターフェースで通信している場合、デフォルト設定を、ＴＣＰパケットで画面データを送信するようにしてもよい。
また、ＴＣＰで送信するように設定するインターフェースの対象は、無線ＬＡＮだけでなく、ＩｒＤＡやＢｌｕｅｔｏｏｔｈ（登録商標）も含んで良い。
【００９１】
また、別の変更例として、サーバ１及びクライアントの画面共有プログラムに、お互いの通信インターフェースに関する情報のやり取りを行う機能を設け、サーバ１とクライアントの接続確立時に、この情報のやり取りを行うようにしてもよい。
クライアントが無線インターフェースを利用していることを判断すると、上記例のように、ＴＣＰパケットで画面データを送信する設定とし、有線ＬＡＮと判断した場合には、ＵＤＰパケットを利用する設定とする。
【実施例１３】
【００９２】
実施例１３は、クライアントの接続経路によって、ＴＣＰとＵＤＰを切り替えて送信する方式の例であり、図２２は、そのアルゴリズムを示した図である。
サーバ１上の画面共有プログラムは、クライアントとＬＡＮで接続しているか、ＷＡＮを介して接続しているかを取得する機能を有する。
【００９３】
クライアントがＬＡＮ接続であるか、ＷＡＮ接続であるかを判断するには、以下の方法がある。
（方法１）
クライアントは、自身の通信インターフェースに関する情報を、ＯＳのシステム情報から取得することが可能である。クライアントの画面共有プログラムは、はサーバ１に接続する際、この通信インターフェース情報を送信する。
一方、サーバ１は、クライアントから送られた通信インターフェースの情報から、第一の判断を行う。インターフェースがモデムであれば、ＷＡＮで接続していると判断する。
【００９４】
（方法２）
サーバ１自身のネットワーク情報とクライアントのＩＰアドレスを照合し、クライアントのＩＰアドレスがグローバルＩＰであれば、そのクライアントはＷＡＮから接続していると判断する。
【００９５】
（方法３）
クライアントに対して、ネットワークコマンドの１つであるｔｒａｃｅｒｏｕｔｅコマンドを使って、ルーティング情報を問い合わせる。そこで、ＬＡＮの外に出ていることを確認した場合、そのクライアントはＷＡＮから接続していると判断する。
【００９６】
図２２に示すように、クライアントからの接続を受け付けた場合、クライアントがＬＡＮ接続かＷＡＮ接続かを判断し（ステップＳ１４１）、ＬＡＮ接続の場合（ステップＳ１４２／Ｎｏ）は、ＵＤＰパケットで画面データを送信するよう設定する（ステップＳ１４４）。一方、ＷＡＮの場合（ステップＳ１４２／Ｙｅｓ）は、ＴＣＰパケットで画面データを送信するよう設定する（ステップＳ１４３）。
【実施例１４】
【００９７】
実施例１４は、送信すべきエンコードデータの残量によって、ＴＣＰとＵＤＰを切り替えて送信する方式の例であり、図２３は、そのアルゴリズムを示した図である。
サーバ１上の画面共有プログラムは、画面更新が行われた場合、更新領域をエンコードして送信するのに必要なデータ量を計測する手段を有する。画面共有プログラムのうち、更新領域をエンコードする部分から、この量を取得する（ステップＳ１５１）。
【００９８】
ある時点で、送信すべきエンコードデータ残量が、ある一定以上の場合は、ＵＤＰパケットで送信するようにする。例えば、残量が５００キロバイトを超えた場合に設定する。
図２３に示すように、更新量が所定の閾値を越えた場合（ステップＳ１５２／Ｙｅｓ）は、画面データを、ＵＤＰパケットで速度を優先して送信し（ステップＳ１５３）、そうでない場合（ステップＳ１５２／Ｎｏ）は、ＴＣＰパケットでクライアントの受信を確認しながら送信する（ステップＳ１５４）。
また、ＵＤＰ通信を行っている場合に、残量が閾値よりも少なくなった場合は、自動的にＴＣＰパケットでの送信に戻す。
【００９９】
実施例１４の変更例として、エンコード前の更新が必要なビットマップデータ量だけで判断してもよい。例えば、残量が１メガバイトを超えた場合に設定する。
【実施例１５】
【０１００】
実施例１５は、送信データレートによって、ＴＣＰとＵＤＰを切り替えて送信する方式の例であり、図２４は、そのアルゴリズムを示した図である。
サーバ１上の画面共有プログラムは、画面更新が行われた場合、単位時間当たり送信しているデータ送信レート（単位時間あたりの送信データ量）を計測する手段を有する。例えば、ＯＳのシステム情報の送信ビットレートから取得する（ステップＳ１６１）。
【０１０１】
データレートが所定の閾値よりも小さい場合（ステップＳ１６２／Ｙｅｓ）は、画面データを、ＵＤＰパケットで速度を優先して送信し（ステップＳ１６３）、そうでない場合（ステップＳ１６２／Ｎｏ）は、ＴＣＰパケットでクライアントの受信を確認しながら送信する（ステップＳ１６４）。
また、ＵＤＰ通信を行っている場合に、データレートが閾値よりも大きくなった場合は、自動的にＴＣＰパケットでの送信に戻す。
【実施例１６】
【０１０２】
実施例１６は、サーバとクライアントとの間の通信速度によって、ＴＣＰとＵＤＰを切り替えて送信する方式の例であり、図２５は、そのアルゴリズムを示した図である。
サーバ１及びクライアント上で起動する画面共有プログラムは、クライアントがサーバ１に接続した際、サーバ１とクライアントの間の通信速度を測定する。
サーバ１とクライアントの間の通信速度を測定を行う方法には、従来の測定方法を用いることができる。例えば、インターネット上のウェブサイトで行われているのと同様に、数メガバイトのデータを送信して、所要時間を測定する方法がある。
【０１０３】
図２５に示すように、クライアントからの接続を受け付けた場合、サーバ１は、サーバ１とクライアントの間の通信速度を測定し（ステップＳ１７１）、通信速度が所定の値以上の場合（ステップＳ１７２／Ｙｅｓ）は、ＴＣＰパケットで画面データを送信するよう設定し（ステップＳ１７３）、所定の値未満の場合（ステップＳ１７２／Ｎｏ）は、ＵＤＰパケットで画面データを送信するよう設定する（ステップＳ１７４）。
ここで、この判断の基準値は、例えば１メガバイト／秒（Ｍｂｐｓ）とすることができる。
【実施例１７】
【０１０４】
実施例１７は、サーバとクライアントとの間のＭＴＵによって、ＴＣＰとＵＤＰを切り替えて送信する方式の例であり、図２６は、そのアルゴリズムを示した図である。
サーバ１上で起動する画面共有プログラムは、クライアントがサーバ１に接続した際、サーバ１とクライアントの間のＭＴＵを測定する手段を有する。
サーバーとクライアントの間のＭＴＵを測定を行う方法には、従来の測定方法を用いることができる。例えば、ネットワークコマンドの１つであるｐｉｎｇコマンドを使って、断片化しない最大データ容量を調べる方法がある。
以下にその原理を示す。
【０１０５】
ping -f -l <パケットサイズ> <[相手先ホスト名]または[相手先IPアドレス]>
ただし、
-f・・・パケットの分割を禁止するオプション
-l・・・パケットのサイズを指定するオプション
【０１０６】
上記のようなｐｉｎｇコマンドを送信することにより、クライアントに対して、何バイトまでのパケットが分割されずに送信されるかを確認することができる。
【０１０７】
図２６に示すように、クライアントからの接続を受け付けた場合、サーバ１は、サーバとクライアントの間のＭＴＵを測定し（ステップＳ１８１）、ＭＴＵが所定の値以上の場合（ステップＳ１８２／Ｙｅｓ）は、ＴＣＰパケットで画面データを送信するよう設定し（ステップＳ１８３）、所定の値未満の場合（ステップＳ１８２／Ｎｏ）は、ＵＤＰパケットで画面データを送信するよう設定する（ステップＳ１８４）。
ここで、この判断の基準値は、例えば１メガバイトとすることができる。
【０１０８】
前記アルゴリズムにおいて、ＭＴＵが小さい場合は、１つのパケットで送れるデータ容量が小さいので、ＴＣＰのＡＣＫ返答を行っていると、通信効率が悪くなるので、ＵＤＰパケットで送信している。
【実施例１８】
【０１０９】
実施例１８は、サーバとクライアントとの間のＱｏＳによって、ＴＣＰとＵＤＰを切り替えて送信する方式の例であり、図２７は、そのアルゴリズムを示した図である。
サーバ１上で起動する画面共有プログラムは、クライアントがサーバ１に接続した際、ＱｏＳを測定し、帯域幅、最低保証速度、最大遅延時間、パケット間隔、ピーク速度、ネットワークの遅延やジッタ、パケットロス等を測定し、通信品質を評価する手段を有する。
【０１１０】
図２７に示すように、クライアントからの接続を受け付けた場合、サーバ１は、サーバとクライアントの間のＱｏＳを測定し（ステップＳ１９１）、通信品質が一定の基準を満たしている場合（ステップＳ１９２／Ｙｅｓ）は、ＵＤＰパケットで画面データを送信するよう設定し（ステップＳ１９４）、満たしていないと判断した場合（ステップＳ１９２／Ｎｏ）は、ＴＣＰパケットで画面データを送信するよう設定する（ステップＳ１９３）。
ただし、必ずしも、全てのパラメータを測定する必要はない。
【実施例１９】
【０１１１】
実施例１９は、クライアントの優先順位によって、ＴＣＰとＵＤＰを切り替えて送信する方式の例であり、図２８は、そのアルゴリズムを示した図である。
サーバ１上で起動する画面共有プログラムは、複数のクライアントが接続して、同時に画面を共有することが可能な画面共有システムにおいて、クライアントに優先順位を付ける機能を有する。
例えば、サーバ１の画面が更新された場合、まず、優先権の与えられたクライアントに対してＴＣＰパケットで確実に画面データを送信し（ステップＳ２０１，Ｓ２０２／Ｙｅｓ，Ｓ２０３）、優先権のないクライアントに対しては、その後ＵＤＰパケットで、受信確認なしで画面データを送信する（ステップＳ２０１，Ｓ２０２／Ｎｏ，Ｓ２０４）。
【実施例２０】
【０１１２】
実施例２０では、更に、優先権と、共有画面上での遠隔制御の制御権とを関連付けて登録する方法について説明している。
図２９に示すように、制御権を得ているクライアントのみ（クライアント「亜伊  上男(192. 168. 0. 2)」）が、遠隔操作が可能で、制御権を所持しているクライアントに対しては、所有していないクライアントよりも先に、ＴＣＰパケットで画面データを送信する。一方、制御権のないクライアントは、共有画面を閲覧するだけで、入力イベントはサーバに受け付けられない。また、制御権のないクライアントへの画面データ送信後に、ＵＤＰパケットで、受信確認なしで画面データを受信する。
【実施例２１】
【０１１３】
実施例２１では、複数のクライアントが接続して、同時に画面を共有し、遠隔操作することが可能な画面共有システムにおいて、遠隔操作中のクライアントに対して、画面データ送信優先度を高くする方法について説明している。
サーバ１は、クライアントが遠隔操作中であるかどうかを判断する機能を有する。
図３０に示すように、クライアントがリモート操作を行うと、サーバ１は、そのクライアントのリモート操作フラッグをＯＮにする（ステップＳ２１１）。そこでタイマーをスタートし（ステップＳ２１２）、一定時間内に、例えば、１分以内に、クライアントが操作を行ったかどうかで、クライアントが操作中であるかどうかを判断する。例えば、１分以内に何の入力イベントがない場合、サーバ１はそのクライアントが遠隔操作を行っていないと判断して（Ｓ２１３／Ｎｏ，Ｓ２１４／Ｙｅｓ）、リモート操作フラッグをＯＦＦにする（ステップＳ２１５）。
【０１１４】
また、画面データの更新があった場合、図３１に示すように、サーバ１はリモート操作フラッグのＯＮ／ＯＦＦを調べ（ステップＳ２２１）、フラッグがＯＮのクライアントに対しては、ＯＦＦのクライアントよりも先に、ＴＣＰパケットで画面データを送信する（ステップＳ２２２）。一方、フラッグＯＦＦのクライアントに対しては、ＯＮのクライアントへの画面データ送信後に、ＵＤＰパケットで、受信確認なしで画面データを送信する（ステップＳ２２３）。
これにより、操作を行っている人に対して、品質・速度を優先して、画面データを送信し、遠隔操作に不便を感じないようにすることが可能である。
【０１１５】
実施例２１の変更例として、例えば、実施例２０のように、制御権の管理を組み合わせることも可能である。その場合、制御権のない制御権のないクライアントに対しては、画面データは常にＵＤＰパケットで送信する。
【実施例２２】
【０１１６】
実施例２２は、共有画面データがフォントデータであるか画像データであるかによって、ＴＣＰとＵＤＰを切り替えて送信する方式の例であり、図３２は、そのアルゴリズムを示した図である。
画面の更新があった場合、先ず、文字が表示された部分の画像データを、ＴＣＰパケットで確実に送信し、その後、その他の領域の画像データをＵＤＰパケットで送信し、クライアントの画面で、文字の部分を読みやすくする。
【０１１７】
サーバ１上で起動する画面共有プログラムは、共有画面に更新があった場合、更新領域を分割して、エンコードし、クライアントにその画面データを送信するが、ここで、分割した画面領域にＯＳがフォント描画命令を出している箇所かどうかを判定し（ステップＳ２３１）、フォント描画命令を出している領域である場合（ステップＳ２３２／Ｙｅｓ）は、ＴＣＰパケットで画面データを送信する（ステップＳ２３３）。一方、フォント描画命令が出ていない部分については（ステップＳ２３２／Ｎｏ）、ＵＤＰパケットで画面データを送信する（ステップＳ２３４）。また、送信の順序としては、フォント描画部分を先に送信することが望ましい。
フォント描画命令の検出方法として、例えば、サーバ１上で起動する画面共有プログラムが、分割領域のＧＤＩ（Ｇｒａｐｈｉｃ  Ｄｅｖｉｃｅ  Ｉｎｔｅｒｆａｃｅ）命令を調べ、フォント描画命令が出ているか否かによって実行する方法がある。
【実施例２３】
【０１１８】
実施例２３は、ＣＰＵの負荷状況に応じて、ＴＣＰとＵＤＰを切り替えて送信する方式の例であり、図３３は、そのアルゴリズムを示した図である。
サーバ１上の画面共有プログラムは、画面更新が行われた場合に、ＣＰＵの負荷量を計測する手段を有する。例えば、ＯＳのシステム情報のＣＰＵ負荷情報から取得する。
【０１１９】
図３３に示すように、ＣＰＵの負荷量を計測し（ステップＳ２４１）、ＣＰＵの負荷量が所定の閾値を越えた場合（ステップＳ２４２／Ｙｅｓ）は、画面データをＵＤＰパケットで速度を優先して送信し（ステップＳ２４４）、そうでない場合（ステップＳ２４２／Ｎｏ）は、ＴＣＰパケットでクライアントの受信を確認しながら送信する（ステップＳ２４３）。また、ＣＰＵの負荷量が閾値よりも少なくなった場合は、自動的にＴＣＰパケットでの送信に戻す。
閾値の設定として、例えば、ＣＰＵ負荷が１秒間以上にわたって８０％を超えている場合は、ＵＤＰパケットに切り替えるようにする。
【０１２０】
ＣＰＵの負荷が大きいときは、それだけ画面更新量が多いため、更新部分の画面データのエンコードに時間が掛かっていることが多い。また、ＣＰＵ負荷が大きい場合、更新部分の画面データのエンコード処理が遅くなるため、通信処理部分のＣＰＵ負荷を小さくする、すなわち、通信速度を速くする必要がある。そのため、ＴＣＰパケットからＵＤＰパケットに切り替えることにより、ＣＰＵ負荷を減らすと共に、クライアントの画面表示の遅延を低減することが可能である。
【０１２１】
また、上記実施例１から２３を適宜組み合わせることにより、高速な画面共有システムが実現される。例えば、制御権のない閲覧のみのクライアントに対しては、無条件で、ＵＤＰマルチキャストによって、同報通信により画面データを送信し、制御権のあるクライアントに対しては、最前面にあるアクティブウィンドウの文字描画が部分のデータをＴＣＰパケットで優先的に送信し、それ以外の部分はＵＤＰパケットで送信する。
あるいは、有線ＬＡＮで接続しているクライアントに対しては、無条件でＵＤＰパケットで画面データを送信し、無線ＬＡＮで接続しているクライアントに対しては、指定したアプリケーションのみをＴＣＰパケットで優先的に送信し、それ以外の部分はＵＤＰパケットで送信するなどの組み合わせが可能である。
【実施例２４】
【０１２２】
実施例２４〜２７では、ネットワークに中継機器（プロキシ）を設けた場合について説明する。
図３４は、本発明の一実施例であるデータ通信システムのネットワーク構成を示した概要図である。
データ通信システムは、サーバとして機能する情報処理装置（サーバ１）と、前記サーバ１のクライアントとして機能する情報処理装置（クライアント２ａ，２ｂ，・・・，２ｎ）と、サーバ１及びクライアント２との間に中継機器３と、を含む形で構成される。サーバ１、クライアント２、中継器機３は、例えば、パーソナルコンピュータであり、これらが、例えば、ＩＥＥＥ８０２．３で定められているイーサネット（登録商標）ＬＡＮによるネットワークで接続されている。
【０１２３】
サーバ１は、自身の表示装置に表示されるＤｅｓｋｔｏｐ画面全体、または、そこに表示されている画面の一部を共有画面とし、共有画面データを接続しているクライアント２に送信することにより、受信したクライアントは、表示装置にサーバ１の共有画面を表示することができる。
本例では、サーバ１とクライアント２の間に、中継機器（以下、プロキシと省略する）が存在し、サーバ１から受信した画面データを受信し、プロキシに接続しているクライアントに画面データを転送する。これにより、サーバ１に多数のクライアントが接続した際の、サーバの負荷を低減し、通信効率を向上させることが可能である。
【０１２４】
また、実施例１の場合と同様に、クライアント２に表示された共有画面内において、該クライアントのマウスやキーボードなどの入力機器からのイベントを、サーバ１に送信することにより、クライアントからサーバの遠隔操作も可能であるが、これもプロキシを通して行ってもよいし、入力イベントはプロキシを介さず、直接サーバに送信するような通信方式を採用してもよい。
【０１２５】
以下に、その原理を説明する。
プロキシを用いた画面の共有方法は、ＭｕｌｔｉｃａｓｔＶＮＣやＶＮＣ  Ｐｒｏｘｙあるいは、ＶＮＣ  Ｒｅｆｌｅｃｔｏｒ等の従来技術をそのまま利用できるので、詳細は省略する。概略としては、サーバのアプリケーションが、サーバの画面データの更新部分を検出し、画面の更新領域を、一定のアルゴリズムにより分割して、エンコードして、プロキシに送信する。プロキシは、一種の画面共有クライアントとして起動する。プロキシはそれと共に、受信した画面データを接続しているクライアントに転送するサーバとしての機能を持ち、受信したクライアントは、更新された領域の画面データをデコードして、共有画面のデータを更新することにより、サーバの画面を表示することが可能となっている。
【０１２６】
図３５を用いて、プロキシを介して画面共有を行う方式の処理フローを説明する。
サーバ１とプロキシ３との接続管理、プロキシ３とクライアント２との接続管理は、実施例２と同様にＴＣＰの接続管理によって行っているものとする。すなわち、プロキシ３はサーバ１に対してＴＣＰによる接続要求を行い（ステップＳ３０１）、サーバ１が応答し、サーバ〜プロキシ間のＴＣＰ接続が確立する（ステップＳ３０２，Ｓ３０３）。また、クライアント２は、プロキシ３に対してＴＣＰによる接続要求を行い（ステップＳ３０４）、プロキシ３が応答し、クライアント〜プロキシ間のＴＣＰ接続が確立する（ステップＳ３０５，Ｓ３０６）。
プロキシ３は、サーバ１からＴＣＰパケットで受信確認を行いながら画面データを受信すると（ステップＳ３０７，Ｓ３０８）、その画面データを接続されたクライアントに対してＵＤＰパケットで画面データを送信する（ステップＳ３０９）。
【０１２７】
図３５の処理フローの変更例として、例えば、プロキシ３は、サーバ１からＵＤＰパケットで受信した画面データを、ＵＤＰパケットでクライアント２に転送してもよい。
また、例えば、サーバ１からＵＤＰパケットで受信した画面データを、ＴＣＰパケットでクライアント２に転送してもよい。
あるいは、サーバ１からＴＣＰパケットで受信した画面データを、ＴＣＰパケットでクライアント２に転送するという方法もある。
【０１２８】
また、図３４に示した構成の変更例として、例えば、図３６に示すように、クライアント２は必ずしもプロキシ３を通してサーバ１から画面データを受信する必要はなく、サーバ１に直接接続されているクライアント２ａ，２ｂ，・・・，２ｉと、プロキシを介して接続しているクライアント２ｊ，・・・，２ｎが混在していても構わない。この場合、遠隔操作を行う優先権のあるクライアントのみ、サーバ１に直接接続し、共有画面を閲覧するだけのクライアントはプロキシ３を介して接続することにより、通信効率を向上することが可能となる。
【実施例２５】
【０１２９】
実施例２５は、プロキシにてＵＤＰマルチキャストあるいはＵＤＰブロードキャストを適用した例であり、図３７にその処理フローを示す。また、表２はネットワーク構成におけるネットワークアドレスの一例である。
【０１３０】
【表２】
2005348262.tif 000004
【０１３１】
＜１．ブロードキャストの場合＞
サーバ１は、ＵＤＰソケットで、（133. 139. 100. 111）と（133. 139. 100. 222）からの入力イベントを待ち受けしている。また、画面データをブロードキャストアドレス（255. 255. 255. 255）で同一サブネット内にブロードキャスト送信する。
クライアント２ｊ，２ｎは、（133. 139. 100. 100）からの画面データのブロードキャストを待ち受けしている。また、入力イベントを（133. 139. 100. 100）にＵＤＰユニキャストで送信する。
サーバ１は、プロキシ３とＴＣＰ接続し、画面データをＴＣＰパケットで、プロキシ３のアドレス（133. 139. 100. 55）に送信している。一方、ＴＣＰソケットで、プロキシ３からの入力データを待ち受けている。
プロキシ３は、ＴＣＰソケットで、サーバ１のアドレス（133. 139. 100. 100）からの画面データを待ち受けしている。
【０１３２】
プロキシ３は、サーバ１からの画面データを受信すると、受信した画面データをブロードキャストアドレス（255. 255. 255. 255）で同一サブネット内にブロードキャスト送信する。パケットはＵＤＰパケットを用いる。
また、プロキシ３は、ＵＤＰソケットで、クライアントのアドレスである（133. 139. 100. 111）と（133. 139. 100. 222）からの入力イベントを待ち受けしている。
プロキシ３は、クライアントからの入力イベントを受信すると、ＴＣＰパケットで、サーバ１に入力イベントを転送する。
クライアント２ｊ，２ｎは、（133. 139. 100. 55）からの画面データのブロードキャストを待ち受けしている。また、入力イベントを（133. 139. 100. 55）にＵＤＰユニキャストで送信する。
クライアントは、プロキシ３からブロードキャストされた画面データを受信して、画面共有を行う。
【０１３３】
＜２．マルチキャストの場合＞
プロキシ３とクライアント２との接続確立時に、サーバ１は全てのクライアントにマルチキャストアドレスを通知する。
プロキシ３はマルチキャストがクライアントに届くように、マルチキャストの範囲を設定する。すなわち、ＴＴＬ（Ｔｉｍｅ Ｔｏ Ｌｉｖｅ）の値を適切に設定する。
サーバ１は、プロキシ３とＴＣＰ接続し、画面データをＴＣＰパケットで、プロキシ３のアドレス（133. 139. 100. 55）に送信している。一方、ＴＣＰソケットで、プロキシ３からの入力データを待ち受けている。
【０１３４】
プロキシ３は、ＴＣＰソケットで、サーバ１のアドレス（133. 139. 100. 100）からの画面データを待ち受けしている。
プロキシ３は、サーバ１からの画面データを受信すると、受信した画面データをマルチキャストキャストアドレス（233. 233. 233. 233）でマルチキャスト送信する。パケットはＵＤＰパケットを用いる。
また、プロキシ３は、ＵＤＰソケットで、クライアントのアドレスである（133. 139. 100. 111）と（133. 139. 100. 222）からの入力イベントを待ち受けしている。
プロキシ３は、クライアントからの入力イベントを受信すると、ＴＣＰパケットで、サーバ１に入力イベントを転送する。
【０１３５】
クライアント２ｊ，２ｎは、プロキシから指定されたマルチキャストキャストアドレス（233. 233. 233. 233）からの画面データを待ち受けしている。また、入力イベントを（133. 139. 100. 100）にＵＤＰユニキャストで送信する。
【実施例２６】
【０１３６】
実施例２６では、プロキシにおけるセッション記録及び再生機能について説明する。
プロキシ３は、サーバ１から受信した画面データを、ＴＣＰパケットでサーバ１が送信して来た順に、時間情報と共に、順次ファイルに追記していき、蓄積する。時間記録は例えば、記録開始時間を原点とする。
クライアント２は、プロキシ３に接続し、記録されたサーバ１の画面データの再生を要求すると、プロキシ３は、記録した画面データを、記録開始時間からの経過時間の指示に従い、順次クライアントにＵＤＰパケットで送信する。
図３８はその様子を示している。サーバ１とプロキシ３の接続が終了後に、クライアント２がプロキシ３に接続して、画面共有の様子を非同期で閲覧することが可能である。なお、再生中は、クライアント２は言うまでもなく閲覧することしかできず、プロキシ３はクライアント２からの入力イベントは受け付けない。
【０１３７】
また、プロキシ３がサーバ１からの画面データを記録中に、クライアント２がプロキシ３に接続し、プロキシ３とサーバ１が接続を開始してからの画面データを時間差付きで閲覧することも可能である。
【０１３８】
また、実施例２６の変更例として、プロキシに記録した画面データを早送りで再生する機能を有してもよい。
プロキシ３が記録時間データを元に、画面データをクライアント２に送信する際、経過時間を、例えば、記録された値の半分の値として送信間隔を早めることも可能である。
【実施例２７】
【０１３９】
実施例２７，２８では、実施例１〜２６で説明したデータ通信システムを応用した電子会議システムについて説明する。
例えば、図１で示したネットワーク構成において、サーバ１を会議サーバとし、クライアント２を参加者の利用する参加者端末とする電子会議システムを構築する。
会議サーバは、実施例３で説明したような、画面共有サーバ１のＵＤＰマルチキャストを利用した画面データ送信機能を備える。
会議サーバは、会議室内のネットワークにのみマルチキャストパケットが届くようにＴＴＬを設定する。
また、会議サーバは制御権の管理を行い、基本的に、制御権を持っていない参加者端末にはマルチキャストＵＤＰによって画面データを送信している。
一方、制御権を持っている参加者端末に画面データを送信する場合は、最前面にあるアクティブウィンドウの文字領域の画面データを優先的にＴＣＰパケットを用いて、制御権のある参加者端末で早く正確に表示できるよう送信する。文字領域以外のデータは、ＵＤＰパケットで、送信順序の優先度を下げて送信されるようになっている。
【実施例２８】
【０１４０】
また、例えば、図３６の機器構成で、サーバ１を会議サーバとし、クライアント２を参加者の利用する参加者端末とし、中継機器（プロキシ）３を画面データの録画・再生が可能で、かつマルチキャストＵＤＰパケットによる画面データの転送が可能である会議プロキシとする会議システムを構成する。
会議サーバは、直接接続している参加者端末にマルチキャストパケットが届くようにＴＴＬを設定する。会議プロキシは、プロキシに接続している参加者端末にマルチキャストパケットが届くようにＴＴＬを設定する。
【０１４１】
図３６のように、一部の参加者端末（２ａ，２ｂ，・・・，２ｉ）は会議室内に存在し、会議サーバに直接接続しており、会議サーバから直接マルチキャストＵＤＰパケットを受信する。一方、他の一部の参加者端末（２ｊ，・・・，２ｎ）は、他の会議室にあり、会議プロキシを介して接続しており、会議プロキシからのマルチキャストＵＤＰパケットを受信する。
【０１４２】
このように通信を管理することにより、ネットワークの通信効率が向上し、遠隔会議に利用した際、スムーズに画面共有が可能となる。
また、途中から会議に参加したい参加者は、プロキシに接続し、会議の初めから共有画面の画面データを再生し、適宜不要な部分を飛ばして再生したり、早送り再生をすることにより、会議の内容を追いかけ、リアルタイムに会議サーバの画面共有したくなったら、会議サーバに接続を切り替え、同期した共有画面を見たり、遠隔操作を行ったりしながら、会議に参加することが可能となる。
【０１４３】
（効果）
以上の説明から明らかなように、送信パケットに対して、パケットを正常に受信したことを応答するＡＣＫパケットを返信する必要のある、データストリーム型の通信方式であるＴＣＰパケットによる通信だけでなく、ＡＣＫの返信の必要がないため高速であるが、信頼性や、パケットの受信順序を保証しないデータグラム型の通信方式であるＵＤＰパケットを用いて、画面データの送信を行う、高速な画面共有を行う、画面共有サーバと画面共有クライアント間の通信が可能となる。
【０１４４】
また、ＵＤＰマルチキャスト，またはＵＤＰブロードキャストパケットで、画面データを同報パケットにより、一度に複数のクライアントに送信することにより、画面共有サーバーの画面データを複数のクライアントに対して、高速に送信する、ネットワーク利用効率の高い通信が可能となる。
【０１４５】
また、パケットタイプを手動または自動で動的に選択することにより、臨機応変に適したパケットタイプで画面データの通信を行うことにより、通信速度の効率を向上させることが可能となる。
また、クライアントの利用者が、画面共有によってサーバの画面データを共有する際に感じる、サーバとのタイムラグによって生じる感覚的不満を緩和することも可能となる。
また、あまり重要でない画面データや、ＴＣＰを用いて確実に送信するまでもない良好なネットワーククライアント環境のクライアントに対して、ＵＤＰパケットを利用して画面データを送信することにより、ＴＣＰパケットを利用する必要のあるクライアントの利用者が、あるいはＴＣＰパケットを用いて、確実に送信する必要のある画面データの転送速度を相対的に速くすることが可能となる。
【０１４６】
また、予め、アプリケーション毎に、そのアプリケーションの画面領域が更新されたとき、画面データをＴＣＰパケットで送信するか、ＵＤＰパケットで送信するかを指定する機能により、画面データの送信パケットの型を動的に選択して画面共有を行うことにより、クライアントに表示される共有された画面データが、アプリケーションの特性適したものとすることが可能となる。
また、ＴＣＰパケットで送信するよう登録されたアプリケーションの画面データの転送速度を相対的に速くすることが可能となる。
また、映像データ再生アプリケーションなどの、ＴＣＰパケットによる確実性よりも、画面更新速度を優先するアプリケーションの画面データをＵＤＰパケットにより送信し、クライアントの画面で、画面共有のコマ落ちを減少させることも可能となる。
【０１４７】
また、最前面にあるアプリケーションウィンドウをＴＣＰパケットで送信し、それ以外の背面のウィンドウまたはデスクトップ領域をＵＤＰパケットで送信することにより、その時点で重要なデータを表示していることの多い、最前面ウィンドウのデータを確実に送信し、それ以外のウィンドウ領域あるいはデスクトップ領域の、あまり重要でないデータは、確実性よりも、速度のみを優先して送信することにより、通信効率を向上することが可能となる。また、ＴＣＰパケットで送信するよう登録された最前面にあるウィンドウの画面データの転送速度を相対的に速くすることが可能となる。
【０１４８】
また、アクティブなアプリケーションウィンドウをＴＣＰパケットで送信し、それ以外の非アクティブウィンドウまたはデスクトップ領域をＵＤＰパケットで送信することにより、その時点で重要なデータを表示していることの多い、アクティブウィンドウのデータを確実に送信し、それ以外の非アクティブウィンドウ領域あるいはデスクトップ領域の、あまり重要でないデータは、確実性よりも速度のみを優先して送信することにより、通信効率を向上することが可能となる。また、ＴＣＰパケットで送信するよう登録されたアクティブウィンドウの画面データの転送速度を相対的に速くすることが可能となる。
【０１４９】
また、画面共有サーバで、アプリケーションによって表示する文書単位で、その文書を表示するアプリケーションの画面領域が更新されたとき、画面データをＴＣＰパケットで送信するか、ＵＤＰパケットで送信するかを指定する機能により、画面データの送信パケットの型を動的に選択して画面共有を行うことにより、クライアントに表示される共有された画面データが、アプリケーションの特性適したものとすることが可能となる。
また、文書の重要度により、確実性を優先するか、通信速度を優先するかを選択することが可能となり、通信効率を向上することが可能となる。
また、ＴＣＰパケットで送信するよう登録された文書を開いているアプリケーションウィンドウの画面データの転送速度を相対的に速くすることが可能となる。
【０１５０】
また、画面共有サーバで、デスクトップ領域の内、ある画面領域の画面データをＴＣＰパケットで送信するか、ＵＤＰパケットで送信するかを指定する機能により、確実に画面共有を行いたい領域は画面データをＴＣＰパケットで送信し、速度を優先する画面データが表示される画面領域の画面データはＵＤＰパケットで送信することにより、通信効率を向上することが可能となる。また、ＴＣＰパケットで送信するよう登録された領域の画面データの転送速度を相対的に速くすることが可能となる。
【０１５１】
また、ユーザの指示により、画面データをＴＣＰパケットで送信するか、ＵＤＰパケットで送信するかを切り替える手段を有することにより、ユーザが現在共有している画面データを送信するのに、異なるパケットタイプで通信した方がよいと判断した場合等に、パケットタイプで切り替えることを可能にすることにより、状況に応じて適した画面データ送信を行うことが可能な通信方式を提供することが可能となる。
【０１５２】
また、画面共有サーバが、自身に接続しているクライアント数が、ある台数より少ない場合は、ＴＣＰパケットで画面データを送信し、ある台数より多い場合は、ＵＤＰパケットで画面データを送信するよう、自動的に切り替える機能を有することにより、通信効率の高い画面共有を行う通信方式を提供することが可能となる。
【０１５３】
また、通信エラーが多く、通信品質の悪い無線通信手段を利用しているクライアントに対しては、自動的にＴＣＰパケットで画面データを送信することにより、データの確実性を保証するし、一方、通信エラーが少なく、通信品質の比較的高い有線通信手段のみでサーバと通信しているクライアントに対してはＵＤＰパケットで画面データを送信するよう選択し、速度及び通信効率を優先することが可能となる。
また、有線ＬＡＮで接続しているクライアントに対して、ＵＤＰパケットを使用して画面データを送信することにより、ＴＣＰパケットで送信するよう登録された無線ＬＡＮを介して接続しているクライアントへの画面データの転送速度を相対的に速くすることが可能となる。
【０１５４】
また、ＬＡＮで接続しているクライアントに対してはＵＤＰを、ＷＡＮによりＬＡＮの外部のネットワークから接続しているクライアントに対してはＴＣＰを選択し、ネットワーク環境に適した画面共有を行う通信方式を自動的に選択する通信を行うことが可能となる。また、ＬＡＮで接続されたクライアントに対して、ＵＤＰパケットを使用して画面データを送信することにより、ＴＣＰパケットで送信するよう登録されたＷＡＮを介して接続しているクライアントへの画面データの転送速度を相対的に速くすることが可能となる。
【０１５５】
また、画面共有サーバにおいて、送信すべき画面更新データ残量、または画面データの送信レートが一定値より多い場合、ＵＤＰパケットで送信し、少ない場合はＴＣＰパケットで確実に送信するよう自動的に切り替えることにより、クライアントの利用者のストレスが少ない画面共有システムにおける通信方式を提供することが可能となる。
【０１５６】
また、サーバ／クライアント間の通信速度が一定値より遅い場合、ＵＤＰパケットで送信し、高速である場合は、ＴＣＰパケットで確実に送信するよう自動的に切り替えることにより、ネットワーク環境に応じ、クライアントの利用者のストレスが少ない画面共有システムにおける通信を行うことが可能となる。また、通信速度の速いクライアントに対して、ＵＤＰパケットを使用して画面データを送信することにより、ＴＣＰパケットで送信するよう登録された通信速度の遅いクライアントへの画面データの転送速度を相対的に速くすることが可能となる。
【０１５７】
また、画面共有サーバがクライアントとの間のネットワークのＭＴＵを測定し、ＭＴＵが一定値より小さい場合、ＵＤＰパケットで送信し、大きい場合は、ＴＣＰパケットで確実に送信するよう自動的に切り替えることにより、ネットワーク環境に応じ、クライアントの利用者のストレスが少ない画面共有システムにおける通信を行うことが可能となる。
【０１５８】
また、画面共有サーバがクライアントとの間のＱｏＳを測定し、ＱｏＳが一定値より大きい場合にはＵＤＰパケットで送信し、小さい場合にはＴＣＰパケットで確実に送信するよう自動的に切り替えることにより、ネットワーク環境に応じ、クライアントの利用者のストレスが少ない画面共有システムにおける通信方式を行うことが可能となる。また、通信品質の良いクライアントに対して、ＵＤＰパケットを使用して画面データを送信することにより、ＴＣＰパケットで送信するよう登録された通信品質の悪いクライアントへの画面データの転送速度を相対的に速くすることが可能となる。
【０１５９】
また、クライアントの優先権に応じて、画面データの送信に用いるパケットのタイプをＴＣＰとＵＤＰで切り替える機能を有することにより、優先度の高いクライアントにはＴＣＰパケットにより確実に画面データを送信し、他の優先度の低いクライアントにはＵＤＰパケットで画面データを送信することにより、通信効率を向上することが可能となる。また、優先度の低いクライアントに対して、ＵＤＰパケットを使用して画面データを送信することにより、ＴＣＰパケットで送信するよう登録された優先度の高いクライアントへの画面データの転送速度を相対的に速くすることが可能となる。
【０１６０】
また、クライアントからのリモート操作を行っている途中であるかどうかを判断し、画面データの送信に用いるパケットのタイプをＴＣＰとＵＤＰで切り替えることにより、リモート操作中のクライアントには、ＴＣＰパケットにより、確実に画面データを送信し、リモート操作を行っていないクライアントには、ＵＤＰパケットで画面データを送信することにより、通信効率を向上することが可能となる。また、リモート操作を行っていないクライアントに対して、ＵＤＰパケットを使用して画面データを送信することにより、ＴＣＰパケットで送信するよう指示されたリモート操作を行っているクライアントへの画面データの転送速度を相対的に速くすることが可能となる。
【０１６１】
また、ＯＳがフォント描画命令を行っている領域であるか、そうでない領域であるかを判断し、画面データの送信に用いるパケットのタイプをＴＣＰとＵＤＰで切り替えることにより、確実性が要求される文字領域の画面データはＴＣＰパケットで送信し、それ以外の領域の画面データはＵＤＰパケットで送信することにより、文字部分を確実にクライアントで送信すると共に、通信速度を向上させ、相対的に文字部分の画面データの転送速度を向上させることが可能となる。また、文字以外のデータを描画する領域に対して、ＵＤＰパケットを使用して画面データを送信することにより、ＴＣＰパケットで送信するよう登録された文字領域の画面データの転送速度を相対的に速くすることが可能となる。
【０１６２】
また、画面共有サーバのＣＰＵ負荷に応じて、画面データの送信に用いるパケットのタイプをＴＣＰとＵＤＰで切り替えることにより、サーバの処理量が多い場合は、その処理により、画面更新データを生成し、送信する処理が遅くなることを考慮して、ＵＤＰパケットで画面データを送信することにより、サーバの負荷量が大きい場合の画面データの送信速度の低下を防止することが可能となる。
【０１６３】
また、中継情報機器が、画面共有サーバとクライアントの間に介在し、画面共有サーバからＴＣＰパケットで受信した画面データを、ＵＤＰパケットに変換して、クライアントに送信する機能により、多数のクライアントがサーバに直接接続した場合に生じるサーバの負荷を低減することが可能となる。また、ＵＤＰパケットで送信する機能を有することにより、画面データの転送速度を向上させることが可能となる。
【０１６４】
また、画面共有サーバからＴＣＰパケットで受信した画面データを、ＵＤＰマルチキャストまたはＵＤＰブロードキャストを利用した同報通信により、複数のクライアントが中継情報機器に接続した場合に、クライアント数の増加による、画面データの転送速度の低下を防ぐことが可能となる。
【０１６５】
また、更に、受信した画面共有データを記録することにより、非同期でサーバの画面の様子を閲覧することが可能となる。また、記録した画面データをＵＤＰパケットによって送信することにより、通信効率を向上させ、閲覧するクライアントに、不自然さを感じさせない高速な画面再生を実現することが可能となる。更に、マルチキャストまたはブロードキャストを利用した同報通信により、複数のクライアントに対して、クライアント数の増加による、画面再生速度の低下を防ぐことが可能となる。
【０１６６】
また、送信パケットに対して、パケットを正常に受信したことを応答するＡＣＫパケットを返信する必要のある、データストリーム型の通信方式であるＴＣＰパケットによる通信だけでなく、ＡＣＫの返信の必要がないため高速であるが、信頼性や、パケットの受信順序を保証しないデータグラム型の通信方式であるＵＤＰパケットを用いて、画面データの送信を行う、高速な画面共有を行うことが可能である電子会議システムを提供することが可能となる。
【０１６７】
また、中継機器（プロキシ）が、画面共有サーバとクライアントの間に介在し、画面共有サーバからＴＣＰパケットで受信した画面データを、ＵＤＰパケットに変換して、クライアントに送信することにより、多数のクライアントがサーバーに直接接続した場合に生じるサーバーの負荷を低減することが可能な電子会議システムを提供することが可能となる。
【図面の簡単な説明】
【０１６８】
【図１】本発明の一実施例であるデータ通信システムのネットワーク構成を示した概要図である。
【図２】ＵＤＰパケットのみを送信することにより画面共有を行う方式の処理フローを例示した図である。
【図３】ＵＤＰでの画面共有において、接続状態の監視のアルゴリズムを示した図である。
【図４】サーバとクライアントの接続にＴＣＰ／ＩＰ接続を利用し、画面データ及び入力イベントの送信にＵＤＰパケットを利用し、ユニキャストで通信を行う方式の処理フローを例示した図である。
【図５】サーバとクライアントの接続にＴＣＰ／ＩＰ接続を利用し、画面データ及び入力イベントの送信にＵＤＰパケットを利用し、ブロードキャスト或いはマルチキャストで同報通信を行う方式の処理フローを例示した図である。
【図６】サーバのアプリケーション毎にＴＣＰまたはＵＤＰの何れかで送信する方式について、サーバの表示画面を例示した図である。
【図７】サーバのアプリケーション毎にＴＣＰまたはＵＤＰの何れかで送信する方式について、アルゴリズムを示した図である。
【図８】サーバのアプリケーション毎にＴＣＰまたはＵＤＰの何れかで送信する方式について、その処理フローを例示した図である。
【図９】サーバのウィンドウが最前面に位置するか否かによって、ＴＣＰとＵＤＰを切り替えて送信する方式について、サーバの表示画面を例示した図である。
【図１０】サーバのウィンドウが最前面に位置するか否かによって、ＴＣＰとＵＤＰを切り替えて送信する方式について、アルゴリズムを示した図である。
【図１１】サーバのウィンドウがアクティブであるか否かによって、ＴＣＰとＵＤＰを切り替えて送信する方式について、サーバの表示画面を例示した図である。
【図１２】サーバのウィンドウがアクティブであるか否かによって、ＴＣＰとＵＤＰを切り替えて送信する方式について、アルゴリズムを示した図である。
【図１３】サーバのウィンドウがユーザの指定した文書であるか否かによって、ＴＣＰとＵＤＰを切り替えて送信する方式について、サーバの表示画面を例示した図である。
【図１４】サーバのウィンドウがユーザの指定した文書であるか否かによって、ＴＣＰとＵＤＰを切り替えて送信する方式について、アルゴリズムを示した図である。
【図１５】サーバのウィンドウがユーザの指定した画面領域であるか否かによって、ＴＣＰとＵＤＰを切り替えて送信する方式について、サーバの画面表示を例示した図である。
【図１６】サーバのウィンドウがユーザの指定した画面領域であるか否かによって、ＴＣＰとＵＤＰを切り替えて送信する方式について、アルゴリズムを示した図である。
【図１７】通信プロトコルの切り替え指示を行う画面を例示した図である。
【図１８】通信プロトコルの切り替え動作のフローを示した図である。
【図１９】ユーザ毎に通信プロトコルの切り替え指示を行う画面を例示した図である。
【図２０】クライアントの接続台数によって、ＴＣＰとＵＤＰを切り替えて送信する方式について、アルゴリズムを示した図である。
【図２１】クライアントの通信インターフェースによって、ＴＣＰとＵＤＰを切り替えて送信する方式について、アルゴリズムを示した図である。
【図２２】クライアントの接続経路によって、ＴＣＰとＵＤＰを切り替えて送信する方式について、アルゴリズムを示した図である。
【図２３】送信すべきエンコードデータの残量によって、ＴＣＰとＵＤＰを切り替えて送信する方式について、アルゴリズムを示した図である。
【図２４】送信データレートによって、ＴＣＰとＵＤＰを切り替えて送信する方式について、アルゴリズムを示した図である。
【図２５】サーバとクライアントとの間の通信速度によって、ＴＣＰとＵＤＰを切り替えて送信する方式について、アルゴリズムを示した図である。
【図２６】サーバとクライアントとの間のＭＴＵによって、ＴＣＰとＵＤＰを切り替えて送信する方式について、アルゴリズムを示した図である。
【図２７】サーバとクライアントとの間のＱｏＳによって、ＴＣＰとＵＤＰを切り替えて送信する方式について、アルゴリズムを示した図である。
【図２８】クライアントの優先順位によって、ＴＣＰとＵＤＰを切り替えて送信する方式について、アルゴリズムを示した図である。
【図２９】遠隔操作の制御権の設定を行う画面を例示した図である。
【図３０】リモート操作フラッグの設定について、そのアルゴリズムを示した図である。
【図３１】リモート操作フラッグのＯＮ／ＯＦＦによって、ＴＣＰとＵＤＰを切り替えて送信する方式について、アルゴリズムを示した図である。
【図３２】共有画面データがフォントデータであるか画像データであるかによって、ＴＣＰとＵＤＰを切り替えて送信する方式について、アルゴリズムを示した図である。
【図３３】ＣＰＵの負荷状況に応じて、ＴＣＰとＵＤＰを切り替えて送信する方式について、アルゴリズムを示した図である。
【図３４】本発明の一実施例であるデータ通信システムのネットワーク構成を示した概要図である（プロキシあり・その１）。
【図３５】プロキシを介して画面共有を行う方式の処理フローを例示した図である。
【図３６】本発明の一実施例であるデータ通信システムのネットワーク構成を示した概要図である（プロキシあり・その２）。
【図３７】プロキシにてＵＤＰマルチキャストあるいはＵＤＰブロードキャストを適用した方式について、処理フローを示した図である。
【図３８】プロキシにおける再生機能について、処理フローを示した図である。
【符号の説明】
【０１６９】
１    サーバ（画面共有サーバ）
２    クライアント
３    中継機器（プロキシ）
１０    ＩＰネットワーク
１１    ＴＣＰ共有アプリケーションウィンドウ
１２    ＵＤＰ共有アプリケーションウィンドウ
１３    最前面ウィンドウ
１４    背面ウィンドウ
１５    アクティブウィンドウ
１６    非アクティブウィンドウ
１７    ユーザ指定文書ウィンドウ
１８    非ユーザ指定文書ウィンドウ
【図１】
2005348262.tif 000005
【図２】
2005348262.tif 000006
【図３】
2005348262.tif 000007
【図４】
2005348262.tif 000008
【図５】
2005348262.tif 000009
【図６】
2005348262.tif 000010
【図７】
2005348262.tif 000011
【図８】
2005348262.tif 000012
【図９】
2005348262.tif 000013
【図１０】
2005348262.tif 000014
【図１１】
2005348262.tif 000015
【図１２】
2005348262.tif 000016
【図１３】
2005348262.tif 000017
【図１４】
2005348262.tif 000018
【図１５】
2005348262.tif 000019
【図１６】
2005348262.tif 000020
【図１７】
2005348262.tif 000021
【図１８】
2005348262.tif 000022
【図１９】
2005348262.tif 000023
【図２０】
2005348262.tif 000024
【図２１】
2005348262.tif 000025
【図２２】
2005348262.tif 000026
【図２３】
2005348262.tif 000027
【図２４】
2005348262.tif 000028
【図２５】
2005348262.tif 000029
【図２６】
2005348262.tif 000030
【図２７】
2005348262.tif 000031
【図２８】
2005348262.tif 000032
【図２９】
2005348262.tif 000033
【図３０】
2005348262.tif 000034
【図３１】
2005348262.tif 000035
【図３２】
2005348262.tif 000036
【図３３】
2005348262.tif 000037
【図３４】
2005348262.tif 000038
【図３５】
2005348262.tif 000039
【図３６】
2005348262.tif 000040
【図３７】
2005348262.tif 000041
【図３８】
2005348262.tif 000042