JP4222561B2 - データ通信方式、電子会議システム、データ通信方法、データ通信プログラム及び記憶媒体 - Google Patents
データ通信方式、電子会議システム、データ通信方法、データ通信プログラム及び記憶媒体 Download PDFInfo
- Publication number
- JP4222561B2 JP4222561B2 JP2004167650A JP2004167650A JP4222561B2 JP 4222561 B2 JP4222561 B2 JP 4222561B2 JP 2004167650 A JP2004167650 A JP 2004167650A JP 2004167650 A JP2004167650 A JP 2004167650A JP 4222561 B2 JP4222561 B2 JP 4222561B2
- Authority
- JP
- Japan
- Prior art keywords
- client
- server
- screen
- packet
- udp
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Description
本発明は、ある情報機器の表示している画面データを、他の情報機器が共有することが可能な、または、更に他の情報機器からの遠隔操作が可能であるサーバ／クライアント型のデータ通信方式に関する。また、前記通信方式を利用した電子会議システムに関する。また、データ通信方法、データ通信プログラム及び記憶媒体に関する。
近年、コンピュータシステムの処理高速化やネットワークの高速化等により、遠方のユーザと会議を行う電子会議システムが普及し始めている。電子会議システムに用いるソフトウェアとして、以下にあげるものが流通している。
１．Microsoft NetMeeting
米国Microsoft社の販売するWindows（登録商標）系列の一部のＯＳに、標準で搭載されている電子会議アプリケーションで、サーバのデスクトップ画面全体や、もしくは指定したアプリケーションの画面をクライアントから閲覧する、あるいは遠隔操作することが可能となっている。
米国Microsoft社の販売するWindows（登録商標）系列の一部のＯＳに、標準で搭載されている電子会議アプリケーションで、サーバのデスクトップ画面全体や、もしくは指定したアプリケーションの画面をクライアントから閲覧する、あるいは遠隔操作することが可能となっている。
２．VNC（Virtual Network Computing）
米国ＡＴ＆Ｔ社の開発した画面共有ソフトであり、基本的にはサーバのデスクトップ画面全体を共有する。ＲＦＢ（Remote Frame Buffer）プロトコルと呼ばれるプロトコルを用いて、サーバの画面領域の更新部分をエンコードし、クライアントに送信している。このVNCを元に開発されたソフトには、指定したアプリケーションの画面領域のみを共有したり、サーバのデスクトップ画面のうち指定した矩形領域のみを共有することが出来るよう改良されたものがある。画面データのエンコード方式に強力な圧縮を掛けたものなども開発されている。このような改良がなされたものとしては、例えば、TightVNC，eSVNC，VDACC VNC等のソフトが知られている。
米国ＡＴ＆Ｔ社の開発した画面共有ソフトであり、基本的にはサーバのデスクトップ画面全体を共有する。ＲＦＢ（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がある。
また、画面共有機能を利用した教育用途のソフトウェアとして、Danware社のNetOp Schoolや、Cross Tech社開発の、リモコン倶楽部for Schoolがある。
３．MulticastVNC
前記VNCのJava（登録商標）上で動作するクライアントソフトウェアの改良版であり、サーバの画面データを、複数のクライアントに中継する機能を有する。これにより、１つのサーバに、大量のクライアントが接続することにより、画面更新速度が低下するのを低減することが可能となっている。
前記VNCのJava（登録商標）上で動作するクライアントソフトウェアの改良版であり、サーバの画面データを、複数のクライアントに中継する機能を有する。これにより、１つのサーバに、大量のクライアントが接続することにより、画面更新速度が低下するのを低減することが可能となっている。
４．Windows RemoteDesktop
Microsoft社のＯＳの一つである、Windows Xp Professionalでは、RemoteDesktopという画面共有機能が備わっている。これも、同様にRemoteDesktopサーバの画面データをRemoteDesktopクライアントで受信し、閲覧したり、クライアントからの遠隔操作を可能にしている。しかし、単純に画面データを送信するだけなので、クライアント機器でWindows MediaPlayerなどのソフトウェアで、ビデオ映像を閲覧しようとすると、コマ落ちが発生するという問題が指摘されている。
Microsoft社のＯＳの一つである、Windows Xp Professionalでは、RemoteDesktopという画面共有機能が備わっている。これも、同様にRemoteDesktopサーバの画面データをRemoteDesktopクライアントで受信し、閲覧したり、クライアントからの遠隔操作を可能にしている。しかし、単純に画面データを送信するだけなので、クライアント機器でWindows MediaPlayerなどのソフトウェアで、ビデオ映像を閲覧しようとすると、コマ落ちが発生するという問題が指摘されている。
また、特許文献１には、コネクションレス型ネットワークを介して接続された会議出席者と、ブリッジを有するコネクション型ネットワークを介して接続された会議出席者との間でテレコンファレンス（電気的通信手段による会議）を行うことが可能なテレコンファレンス装置に関する技術が開示されている。
特開平１０−２５７０５３号公報
しかしながら、画面データの送信は、いずれもデータストリーム型の通信方式であるＴＣＰパケットを使用している。ＴＣＰ／ＩＰ通信においては、通信の確実性が保証されるが、パケットを受信したことに対する返答を行う、つまりＡＣＫパケットを返す必要がある。
一方、データグラム型の通信方式であるＵＤＰ／ＩＰ通信においては、パケットの受信に対して、ＡＣＫを返す必要がない。これにより、通信の確実性は保証されないが、通信速度が向上する。また、ＵＤＰパケットのヘッダは６４ビットであるのに対し、ＴＣＰは１８２ビットあり、このヘッダのオーバーヘッドが通信速度の低下の原因になる場合もある。特に、電子会議システムのように、１つのサーバに対して、複数のクライアントが画面共有によって、サーバ上に表示された文書の閲覧を行ったり、文書をクライアントから遠隔編集する場合には、１クライアント毎にＴＣＰ接続を確立させる必要があり、通信速度の低下を招き、クライアントの画面更新が遅くなり、利用者がストレスを感じたり、誤った遠隔操作を行ってしまう可能性も高くなる。例えば、単一のサーバに対して、１０台以上のクライアントが接続した場合、既存のソフトウェアでは、画面更新速度が落ちて、実用に耐えられなくなってしまう。
一方、データグラム型の通信方式であるＵＤＰ／ＩＰ通信においては、パケットの受信に対して、ＡＣＫを返す必要がない。これにより、通信の確実性は保証されないが、通信速度が向上する。また、ＵＤＰパケットのヘッダは６４ビットであるのに対し、ＴＣＰは１８２ビットあり、このヘッダのオーバーヘッドが通信速度の低下の原因になる場合もある。特に、電子会議システムのように、１つのサーバに対して、複数のクライアントが画面共有によって、サーバ上に表示された文書の閲覧を行ったり、文書をクライアントから遠隔編集する場合には、１クライアント毎にＴＣＰ接続を確立させる必要があり、通信速度の低下を招き、クライアントの画面更新が遅くなり、利用者がストレスを感じたり、誤った遠隔操作を行ってしまう可能性も高くなる。例えば、単一のサーバに対して、１０台以上のクライアントが接続した場合、既存のソフトウェアでは、画面更新速度が落ちて、実用に耐えられなくなってしまう。
これを解決するため、MulticastVNCのように、中継機器を挟んでやることも可能であるが、中継機器での処理による画面更新の遅れが生じるため、中継機器を介して接続されるクライアントは、その台数が増えれば、それだけ画面更新速度は低下する。
本発明は上記事情を鑑みてなされたものであり、必要に応じて、ＴＣＰとＵＤＰとを切り替えてデータ通信を行うデータ通信方式、電子会議システム、データ通信方法、データ通信プログラム、記憶媒体を提供することを目的とする。
前記課題を解決するために、請求項１記載の発明は、サーバとして機能する情報機器と、前記サーバのクライアントとして機能する情報機器を構成要素とし、前記サーバは、その表示画面の少なくとも一部に関するデータを、前記クライアントにＩＰプロトコルを用いて通信を行うネットワークを介して送信する手段と、送信する画面領域のデータの種類または表示条件、クライアントとの通信環境、あるいはユーザが与える指示の何れかによって、前記サーバは前記画面データを送信する場合に、送信する画面データの少なくとも一部を、ＴＣＰパケットを用いて送信するか、もしくはＵＤＰパケットを用いて送信するかを切り替えて送信する手段とを有し、前記クライアントは、前記サーバから受信した画面データを表示装置に表示することにより、前記サーバの表示画面を共有する手段を有するネットワークシステムにおけるデータ通信方式であって、前記サーバは、接続クライアントの優先権および共有画面上での遠隔制御の制御権を管理する手段をさらに有し、前記優先権の与えられているクライアントに対しては、ＴＣＰパケットで画面データを送信し、前記優先権が与えられていないクライアントに対しては、前記優先権の与えられているクライアントに対するＴＣＰパケットの送信後に、ＵＤＰパケットで画面データを送信し、前記制御権を所持しているクライアントに対しては、ＴＣＰパケットで画面データを送信し、前記制御権のないクライアントクライアントに対しては、前記制御権の与えられているクライアントに対するＴＣＰパケットの送信後に、ＵＤＰパケットで画面データを送信することを特徴とする。
請求項２記載の発明は、前記サーバは、ＵＤＰマルチキャストまたはＵＤＰブロードキャストパケットを用いて複数の前記クライアントに対して、画面データを同報通信方式で送信する手段を有することを特徴とする。
請求項３記載の発明は、会議サーバとして機能する情報機器と、会議サーバの会議クライアントとして機能する情報機器を構成要素とし、会議サーバは、その表示画面の少なくとも一部に関するデータを、会議クライアントにＩＰプロトコルを用いて通信を行うネットワークを介して送信する手段と、送信する画面領域のデータの種類または表示条件、会議クライアントとの通信環境、あるいはユーザが与える指示の何れかによって、前記会議サーバは前記画面データを送信する場合に、送信する画面データの少なくとも一部を、ＴＣＰパケットを用いて送信するか、もしくはＵＤＰパケットを用いて送信するかを切り替えて送信する手段とを有し、前記会議クライアントは、前記会議サーバから受信した画面データを表示装置に表示することにより、前記会議サーバの表示画面を共有する手段を有する電子会議システムであって、前記サーバは、接続クライアントの優先権および共有画面上での遠隔制御の制御権を管理する手段を有し、前記優先権の与えられているクライアントに対しては、ＴＣＰパケットで画面データを送信し、前記優先権が与えられていないクライアントに対しては、前記優先権の与えられているクライアントに対するＴＣＰパケットの送信後に、ＵＤＰパケットで画面データを送信し、前記制御権を所持しているクライアントに対しては、ＴＣＰパケットで画面データを送信し、前記制御権のないクライアントクライアントに対しては、前記制御権の与えられているクライアントに対するＴＣＰパケットの送信後に、ＵＤＰパケットで画面データを送信することを特徴する。
請求項４記載の発明は、請求項３記載の電子会議システムにおいて、サーバは、ＵＤＰマルチキャストまたはＵＤＰブロードキャストパケットを用いて複数のクライアントに対して、画面データを同報通信方式で送信する手段を有することを特徴とする。
請求項５記載の発明は、サーバとして機能する情報機器と、サーバのクライアントとして機能する情報機器を構成要素とするネットワークシステムにおけるデータ通信方法であって、サーバにおいて、その表示画面の少なくとも一部に関するデータを、クライアントにＩＰプロトコルを用いて通信を行うネットワークを介して送信する工程と、クライアントにおいて、サーバから受信した画面データを表示装置に表示することにより、サーバの表示画面を共有する工程とを有し、送信する画面領域のデータの種類または表示条件、クライアントとの通信環境、あるいはユーザが与える指示の何れかによって、サーバは画面データを送信する場合に、送信する画面データの少なくとも一部を、ＴＣＰパケットを用いて送信するか、もしくはＵＤＰパケットを用いて送信するかを切り替えて送信する工程を有し、前記サーバは、自ら管理する接続クライアントの優先権および共有画面上での遠隔制御の制御権に応じて、前記優先権の与えられているクライアントに対しては、ＴＣＰパケットで画面データを送信し、前記優先権が与えられていないクライアントに対しては、前記優先権の与えられているクライアントに対するＴＣＰパケットの送信後に、ＵＤＰパケットで画面データを送信し、前記制御権を所持しているクライアントに対しては、ＴＣＰパケットで画面データを送信し、前記制御権のないクライアントクライアントに対しては、前記制御権の与えられているクライアントに対するＴＣＰパケットの送信後に、ＵＤＰパケットで画面データを送信することを特徴する。
請求項６記載の発明は、請求項５記載のデータ通信方法において、サーバは、ＵＤＰマルチキャストまたはＵＤＰブロードキャストパケットを用いて複数のクライアントに対して、画面データを同報通信方式で送信する手段を有することを特徴とする。
請求項７記載の発明は、請求項５または６に記載のデータ通信方法をコンピュータに実行させるためのデータ通信プログラムである。
請求項８記載の発明は、請求項５または６に記載のデータ通信方法をコンピュータに実行させるためのデータ通信プログラムを格納したコンピュータが読み取り可能な記憶媒体である。
本発明によれば、下記の実施例の説明から明らかなように、送信パケットに対して、パケットを正常に受信したことを応答するＡＣＫパケットを返信する必要のある、データストリーム型の通信方式であるＴＣＰパケットによる通信だけでなく、ＡＣＫの返信の必要がないため高速であるが、信頼性や、パケットの受信順序を保証しないデータグラム型の通信方式であるＵＤＰパケットを用いて、画面データの送信を行う、高速な画面共有を行う、画面共有サーバと画面共有クライアント間の通信が可能となる。
以下に、添付図面を参照しながら、本発明の実施形態を説明する。
図１は、本発明の一実施例であるデータ通信システムのネットワーク構成を示した概要図である。
データ通信システムは、サーバとして機能する情報処理装置（サーバ１）と、前記サーバ１のクライアントとして機能する情報処理装置（クライアント２ａ，２ｂ，・・・，２ｎ）が、ＩＰネットワーク１０を介して接続されている。ＩＰネットワークとして、例えば、ＩＥＥＥ８０２．３で定められているイーサネット（登録商標）ＬＡＮ等がある。
データ通信システムは、サーバとして機能する情報処理装置（サーバ１）と、前記サーバ１のクライアントとして機能する情報処理装置（クライアント２ａ，２ｂ，・・・，２ｎ）が、ＩＰネットワーク１０を介して接続されている。ＩＰネットワークとして、例えば、ＩＥＥＥ８０２．３で定められているイーサネット（登録商標）ＬＡＮ等がある。
サーバ１は表示装置を有し、該表示装置に表示される表示内容の全体または一部を共有画面とし、ＩＰネットワーク１０に接続されたクライアント２に対して共有画面データを送信する。クライアント２では、該共有画面データを受信することにより、該クライアントの表示装置にサーバ１の共有画面を表示することができる。
画面を共有する方法は、従来の技術をそのまま利用することができるので、詳細な説明を省略する。概略としては、サーバのアプリケーションが該サーバの画面データの更新部分を検出し、画面の更新領域を一定のアルゴリズムにより分割、エンコードして、クライアントに送信する。受信したクライアントは、更新された領域の画面データをデコードして、共有画面のデータを更新するという方法による。
画面を共有する方法は、従来の技術をそのまま利用することができるので、詳細な説明を省略する。概略としては、サーバのアプリケーションが該サーバの画面データの更新部分を検出し、画面の更新領域を一定のアルゴリズムにより分割、エンコードして、クライアントに送信する。受信したクライアントは、更新された領域の画面データをデコードして、共有画面のデータを更新するという方法による。
従来の発明においては、画面データの送信をＴＣＰパケットで送信するようになっている。ＴＣＰはコネクション型（ＣＯ型）のプロトコルであって、コネクションレス型（ＣＬ型）のＩＰにおけるＩＰパケットの損失をカバーすることが可能な、信頼性の高いプロトコルである。しかしながら、データの転送効率が低下するという問題がある。
一方、本発明では、画面データをＵＤＰパケットで送信する機能を備えている。ＵＤＰはＣＬ型のプロトコルであって、データの信頼性はＴＣＰに劣るものの、高速データ転送が可能であるという利点を有する。
一方、本発明では、画面データをＵＤＰパケットで送信する機能を備えている。ＵＤＰはＣＬ型のプロトコルであって、データの信頼性はＴＣＰに劣るものの、高速データ転送が可能であるという利点を有する。
図２は、ＵＤＰパケットのみを送信することにより画面共有を行う方式の処理フローを示した図である。
初期状態として、サーバ１は、ＵＤＰポートを開け、ＵＤＰ用のソケットでクライアントからの接続を待ち受けている状態にある。
クライアント２は、サーバ１に対して画面共有の要求を行うために、ＵＤＰパケットを用いて送信する（ステップＳ１）。パケットを受信したサーバは共有を許可すると、共有の要求を行ったクライアントへ許可を通知するパケットを送信すると共に、共有を許可したクライアントのネットワークアドレス（ＩＰアドレス）を記憶する（ステップＳ２，Ｓ３）。これにより、共有の要求を行ったクライアントに対して、ＵＤＰパケットで画面データを送信できるようになると共に、該クライアントからの入力イベントを受信して、リモート操作を可能な状態にする。
初期状態として、サーバ１は、ＵＤＰポートを開け、ＵＤＰ用のソケットでクライアントからの接続を待ち受けている状態にある。
クライアント２は、サーバ１に対して画面共有の要求を行うために、ＵＤＰパケットを用いて送信する（ステップＳ１）。パケットを受信したサーバは共有を許可すると、共有の要求を行ったクライアントへ許可を通知するパケットを送信すると共に、共有を許可したクライアントのネットワークアドレス（ＩＰアドレス）を記憶する（ステップＳ２，Ｓ３）。これにより、共有の要求を行ったクライアントに対して、ＵＤＰパケットで画面データを送信できるようになると共に、該クライアントからの入力イベントを受信して、リモート操作を可能な状態にする。
サーバ１からの許可を受信したクライアントは、サーバのネットワークアドレスを記憶し、サーバからの画面データを受信して表示する準備を整える（ステップＳ４）。
すなわち、ＵＤＰポートを開け、ＵＤＰ用のソケットでサーバ１からの通信パケットを待ち受ける。
すなわち、ＵＤＰポートを開け、ＵＤＰ用のソケットでサーバ１からの通信パケットを待ち受ける。
なお、ステップＳ１，Ｓ２における一往復のＵＤＰパケットの通信で要求・許可を行うのではなく、認証を行ってもよい。
また、図では省略したが、ここでクライアントとサーバは、共有する画面の大きさやエンコードの方法について、相互の設定を調整する通信が含まれる場合もある。
また、図では省略したが、ここでクライアントとサーバは、共有する画面の大きさやエンコードの方法について、相互の設定を調整する通信が含まれる場合もある。
次に、準備が整うと、サーバ１からクライアント２に対して初期画面データがＵＤＰで送信される（ステップＳ５ａ）。その後は、サーバ１の共有画面領域に更新がある度に、画面データがＵＤＰパケットで送信される（ステップＳ５ｂ，Ｓ５ｃ，Ｓ５ｄ）。
また、クライアントが遠隔操作を行った場合には、入力イベントがＵＤＰパケットでサーバに送信される（ステップＳ６）。
また、クライアントが遠隔操作を行った場合には、入力イベントがＵＤＰパケットでサーバに送信される（ステップＳ６）。
画面共有を終了する場合には、クライアントから切断要求をＵＤＰパケットでサーバに送信する（ステップＳ７）。切断要求を受信したサーバは、切断の確認をＵＤＰパケットでクライアントへ送信すると共に、該クライアントへの送受信の設定を解除する（ステップＳ８，Ｓ９）。一方、切断ＯＫを受信したクライアントは、サーバへの送受信の設定を解除する（ステップＳ１０）。
ここで、図２に示した通信方式の場合、サーバとクライアントは、ＵＤＰパケットでお互いに一方的にデータを送信しているので、いつ相手が画面共有アプリケーションを終了したのか、或いはネットワークエラーによって通信不能になっているのか、切断ＯＫのパケットが届いていない、等を検出することができない。
そこで、図３に示すアルゴリズムで相手の監視を行う。
そこで、図３に示すアルゴリズムで相手の監視を行う。
接続を確立した場合、サーバ及びクライアントは、タイマーを用いて、所定の時間毎に、例えば１分毎に、相手の接続を確認するための確認パケットを送信する（ステップＳ１１，Ｓ１２）。
一方で、それと共に、相手からの何らかのパケットが受信されたかどうかを、タイマーを用いて監視する。
例えば、２分間のタイマーで確認を行う。
パケット受信の確認を行い（ステップＳ２１）、データまたは確認パケットを受信すると（ステップＳ２２／Ｙｅｓ）、タイマーをスタートさせる（ステップＳ２３）。２分以内に何らかのパケットを受信した場合（ステップＳ２４／Ｙｅｓ）は、タイマーを再スタートする（ステップＳ２３）。２分以内に受信しなかった場合（ステップＳ２４／Ｎｏ，Ｓ２５／Ｙｅｓ）は、相手が切断したと判断し、相手との送受信の設定を解除する（ステップＳ２６）。
例えば、２分間のタイマーで確認を行う。
パケット受信の確認を行い（ステップＳ２１）、データまたは確認パケットを受信すると（ステップＳ２２／Ｙｅｓ）、タイマーをスタートさせる（ステップＳ２３）。２分以内に何らかのパケットを受信した場合（ステップＳ２４／Ｙｅｓ）は、タイマーを再スタートする（ステップＳ２３）。２分以内に受信しなかった場合（ステップＳ２４／Ｎｏ，Ｓ２５／Ｙｅｓ）は、相手が切断したと判断し、相手との送受信の設定を解除する（ステップＳ２６）。
本実施例では、ＵＤＰパケットによって送信しているので、画面データや入力イベント等のパケットがネットワーク上で損失する場合があり、その通信は送信先には反映されない。また、送信側でのパケットの送信順序と、送信先でのパケットの受信順序が異なる場合もある。
よって、本発明は、ＬＡＮ等の短距離ネットワークで、データ通信量の大きいネットワーク回線上でサーバとクライアントが接続されている場合や、画面データの確実性よりも共有画面が頻繁に更新されるような場合に用いることが好ましい。
よって、本発明は、ＬＡＮ等の短距離ネットワークで、データ通信量の大きいネットワーク回線上でサーバとクライアントが接続されている場合や、画面データの確実性よりも共有画面が頻繁に更新されるような場合に用いることが好ましい。
図１では、サーバ１として、大画面表示装置を備えるデスクトップ型ＰＣ、或いはワークステーション等を用いている。また、クライアント２として、ラックトップ型ＰＣ（ノートＰＣ）を用いているが、必ずしもこのような構成に限定されない。
すなわち、本発明において、サーバとは、ネットワークにおいて共有される画面データを有するコンピュータであり、従って、大画面表示装置を備えていなくても、また、クライアントとしてデスクトップＰＣを用いても構わない。
すなわち、本発明において、サーバとは、ネットワークにおいて共有される画面データを有するコンピュータであり、従って、大画面表示装置を備えていなくても、また、クライアントとしてデスクトップＰＣを用いても構わない。
また、ネットワークの具体的な実施例は、イーサネット（登録商標）有線ＬＡＮに限定されることはなく、無線ＬＡＮ、ＩｒＤＡ、Ａｐｐｌｅ Ｔａｌｋ、ＩＳＤＮ、電話交換網、デジタル専用線、ＦＲ網、・・・等によって接続されている場合や、これらの組み合わせで接続されている場合でもよい。
実施例２は、前記実施例１で説明した方式の変更例である。
図４は、サーバとクライアントの接続にＴＣＰ／ＩＰ接続を利用し、画面データ及び入力イベントの送信にＵＤＰパケットを利用する方式の処理フローを示した図である。
サーバ１とクライアント２は共に、ＴＣＰとＵＤＰの２つのソケットを用意する。
ＴＣＰパケットで接続すると（ステップＳ３１，Ｓ３２，Ｓ３３）、同じネットワークアドレスのＵＤＰソケットを用いて、画面データや入力イベントの送受信を行う（ステップＳ３４ａ〜ｄ，Ｓ３５）。
ＴＣＰ接続の切断の要求を行い、ＴＣＰ接続を切断すると、ＵＤＰソケットも終了し、画面データ及び入力イベントの待ち受けを終了する（ステップＳ３６，Ｓ３７，Ｓ３８）。ＴＣＰはコネクション型の通信プロトコルであるので、相手との接続の管理はＴＣＰ接続の接続管理に任せ、特にアプリケーション側（上位レイヤ）で監視の機能を実装する必要はない。
図４は、サーバとクライアントの接続にＴＣＰ／ＩＰ接続を利用し、画面データ及び入力イベントの送信にＵＤＰパケットを利用する方式の処理フローを示した図である。
サーバ１とクライアント２は共に、ＴＣＰとＵＤＰの２つのソケットを用意する。
ＴＣＰパケットで接続すると（ステップＳ３１，Ｓ３２，Ｓ３３）、同じネットワークアドレスのＵＤＰソケットを用いて、画面データや入力イベントの送受信を行う（ステップＳ３４ａ〜ｄ，Ｓ３５）。
ＴＣＰ接続の切断の要求を行い、ＴＣＰ接続を切断すると、ＵＤＰソケットも終了し、画面データ及び入力イベントの待ち受けを終了する（ステップＳ３６，Ｓ３７，Ｓ３８）。ＴＣＰはコネクション型の通信プロトコルであるので、相手との接続の管理はＴＣＰ接続の接続管理に任せ、特にアプリケーション側（上位レイヤ）で監視の機能を実装する必要はない。
実施例３は、前記実施例２の方式に、更にＵＤＰマルチキャスト或いはＵＤＰブロードキャストを適用した例であり、図５にその処理フローを示す。
また、表１はネットワーク構成におけるネットワークアドレスの一例である。
また、表１はネットワーク構成におけるネットワークアドレスの一例である。
＜１．ブロードキャストの場合＞
サーバ１は、ＵＤＰソケットで、（133. 139. 100. 111）と（133. 139. 100. 222）からの入力イベントを待ち受けている。また、画面データをブロードキャストアドレス（255. 255. 255. 255）で同一サブネット内にブロードキャスト送信する。パケットはＵＤＰパケットを用いる。
クライアント２ａ，２ｂは、（133. 139. 100. 100）からの画面データのブロードキャストを待ち受けている。また、入力イベントを（133. 139. 100. 100）にＵＤＰユニキャストで送信する。
クライアントは、サーバからブロードキャストされた画面データを受信して、画面共有を行う。
サーバ１は、ＵＤＰソケットで、（133. 139. 100. 111）と（133. 139. 100. 222）からの入力イベントを待ち受けている。また、画面データをブロードキャストアドレス（255. 255. 255. 255）で同一サブネット内にブロードキャスト送信する。パケットはＵＤＰパケットを用いる。
クライアント２ａ，２ｂは、（133. 139. 100. 100）からの画面データのブロードキャストを待ち受けている。また、入力イベントを（133. 139. 100. 100）にＵＤＰユニキャストで送信する。
クライアントは、サーバからブロードキャストされた画面データを受信して、画面共有を行う。
＜２．マルチキャストの場合＞
サーバとクライアントの接続確立時に、サーバ１は、全てのクライアントにマルチキャストアドレスを通知する。
サーバ１は、マルチキャストがクライアントに届くように、マルチキャストの範囲を設定する。すなわち、ＴＴＬ（Time To Live）の値を適切に設定する。
サーバとクライアントの接続確立時に、サーバ１は、全てのクライアントにマルチキャストアドレスを通知する。
サーバ１は、マルチキャストがクライアントに届くように、マルチキャストの範囲を設定する。すなわち、ＴＴＬ（Time To Live）の値を適切に設定する。
サーバ１は、ＵＤＰソケットで、（133. 139. 100. 111）と（133. 139. 100. 222）からの入力イベントを待ち受けている。また、画面データをマルチキャストアドレス（233. 233. 233. 233）でマルチキャスト送信する。パケットはＵＤＰパケットを用いる。
クライアント２ａ，２ｂは、サーバ１から指定されたマルチキャストアドレス（233. 233. 233. 233）からの画面データを待ち受けている。また、入力イベントを（133. 139. 100. 100）にＵＤＰユニキャストで送信する。
クライアント２ａ，２ｂは、サーバ１から指定されたマルチキャストアドレス（233. 233. 233. 233）からの画面データを待ち受けている。また、入力イベントを（133. 139. 100. 100）にＵＤＰユニキャストで送信する。
実施例４は、サーバのアプリケーションの種類によって、ＴＣＰとＵＤＰを切り替えて送信する方式例であり、図６は、サーバの画面表示例である。
サーバ１は、予めＴＣＰパケットで送信するように設定したアプリケーションの画面データ１１を送信する場合は、ＴＣＰパケットにより送信し、それ以外の画面領域（ＵＴＤ共有アプリケーション画面１２等）は、ＵＤＰパケットを用いて送信する。
サーバ１は、予めＴＣＰパケットで送信するように設定したアプリケーションの画面データ１１を送信する場合は、ＴＣＰパケットにより送信し、それ以外の画面領域（ＵＴＤ共有アプリケーション画面１２等）は、ＵＤＰパケットを用いて送信する。
例えば、アプリケーションとして、ワードプロセッサソフトであるＷｏｒｄｐｒｏｃと、表計算ソフトであるＭａｔｒｉｘｃａｌｃというソフトウェアのみをＴＣＰパケットで送信し、画面共有を行っているクライアント側で確実に画面を表示したい場合を考える。
画面共有サーバプログラムに、ＴＣＰパケットで送信したいアプリケーションの実行ファイルのパスを登録する。例えば、
C:\Program Files\Wordproc\Wordproc.exe
C:\Program Files\Matrixcalc\Matrixcalc.exe
を登録する。
画面共有サーバプログラムに、ＴＣＰパケットで送信したいアプリケーションの実行ファイルのパスを登録する。例えば、
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（登録商標））のウィンドウで、該文書を開いているウィンドウ領域の画面データはＴＣＰパケットで送信される。
実施例７の変更例として、文書毎ではなく、ウィンドウ単位で指定することも可能である。
例えば、
c:\My Documents\統計\2003Jan.pdf
という文書を開いているプログラムAcrobat Reader（登録商標）のウィンドウを指定する。例えば、画面共有プログラムで、ＴＣＰパケットで画面送信するウィンドウを選択する機能を設け、この機能を実行すると、実行後最初にマウスでクリックしたウィンドウをＴＣＰパケットで画面データを送信するよう登録し、登録機能を終了するようにする。
例えば、
c:\My Documents\統計\2003Jan.pdf
という文書を開いているプログラムAcrobat Reader（登録商標）のウィンドウを指定する。例えば、画面共有プログラムで、ＴＣＰパケットで画面送信するウィンドウを選択する機能を設け、この機能を実行すると、実行後最初にマウスでクリックしたウィンドウをＴＣＰパケットで画面データを送信するよう登録し、登録機能を終了するようにする。
実施例８は、サーバのウィンドウがユーザの指定した画面領域であるか否かによって、ＴＣＰとＵＤＰを切り替えて送信する方式の例であり、図１５は、サーバの画面表示例である。
図１５に示すように、ユーザ指定領域１９の画面データを送信する際には、ＴＣＰパケットを用いて送信し、それ以外の領域は、ＵＤＰパケットを用いて送信する。
図１５に示すように、ユーザ指定領域１９の画面データを送信する際には、ＴＣＰパケットを用いて送信し、それ以外の領域は、ＵＤＰパケットを用いて送信する。
図１６は、サーバのウィンドウがユーザの指定した画面領域であるか否かによって、ＴＣＰとＵＤＰを切り替えて送信する方式について、そのアルゴリズムを示した図である。
サーバ１の表示画面に更新があった場合、画面共有プログラムは、一定のアルゴリズムにより領域を分割して、エンコードするが、ここで分割した画面領域が、ユーザの指定した画面領域であるか否かを判断する（ステップＳ１０１）。
ユーザが指定した画面領域である場合（ステップＳ１０２／Ｙｅｓ）は、エンコード後、ＴＣＰパケットで送信するよう指示を出す（ステップＳ１０３）。一方、それ以外の領域の場合（ステップＳ１０２／Ｎｏ）は、ＵＤＰパケットで送信するよう指示を出す（ステップＳ１０４）。
サーバ１の表示画面に更新があった場合、画面共有プログラムは、一定のアルゴリズムにより領域を分割して、エンコードするが、ここで分割した画面領域が、ユーザの指定した画面領域であるか否かを判断する（ステップＳ１０１）。
ユーザが指定した画面領域である場合（ステップＳ１０２／Ｙｅｓ）は、エンコード後、ＴＣＰパケットで送信するよう指示を出す（ステップＳ１０３）。一方、それ以外の領域の場合（ステップＳ１０２／Ｎｏ）は、ＵＤＰパケットで送信するよう指示を出す（ステップＳ１０４）。
実施例８の変更例を以下に示す。
画面共有プログラムで、ＴＣＰパケットで画面送信する画面領域を選択する機能を設け、この機能を実行すると、実行後最初にマウスでクリックしたウィンドウを左上頂点とし、マウスをクリックした状態のまま移動させ、マウスクリックを放した位置を、右下頂点とする矩形領域をＴＣＰパケットで画面データを送信するよう登録し、登録機能を終了するようにする。最初にクリックした座標と、最後に放した場所の座標を取得して登録する。例えば、（１００，２００）でクリックを開始し、（４００，７００）までドラッグして、マウスを放した場合、この両点を対角線上にある２頂点とする矩形領域をＴＣＰ送信領域とする。
画面共有プログラムで、ＴＣＰパケットで画面送信する画面領域を選択する機能を設け、この機能を実行すると、実行後最初にマウスでクリックしたウィンドウを左上頂点とし、マウスをクリックした状態のまま移動させ、マウスクリックを放した位置を、右下頂点とする矩形領域をＴＣＰパケットで画面データを送信するよう登録し、登録機能を終了するようにする。最初にクリックした座標と、最後に放した場所の座標を取得して登録する。例えば、（１００，２００）でクリックを開始し、（４００，７００）までドラッグして、マウスを放した場合、この両点を対角線上にある２頂点とする矩形領域をＴＣＰ送信領域とする。
また、実施例４〜８において、ＴＣＰパケットでの送信を、ＵＤＰパケットでの送信より優先して行うことも可能である。これにより、必要とする部分の画面データが早く確実にクライアントの画面に表示することが可能である。
実施例９では、画面データの送信において、ＴＣＰパケットにするかＵＤＰパケットにするかをユーザが切り替える手段について説明する。
図１７は、通信プロトコルの切り替え指示を行う画面を例示した図であり、サーバの画面共有プログラムにＴＣＰ／ＵＤＰを選択、切り替えを指示する機能を設ける。
図１７は、通信プロトコルの切り替え指示を行う画面を例示した図であり、サーバの画面共有プログラムにＴＣＰ／ＵＤＰを選択、切り替えを指示する機能を設ける。
図１８は、通信プロトコルの切り替え動作のフローを示した図である。
このように、最初デフォルト設定では、ＴＣＰ接続を確立したクライアントに対しては、ＴＣＰパケットで画面データを送信するように設定されているとする（ステップＳ１１１）。図１７のような画面共有プログラムの通信手段切り替え機能により、ＵＤＰパケットで送信するよう指示された場合（ステップＳ１１２／Ｙｅｓ）は、画面データをＵＤＰパケットで送信する（ステップＳ１１３）。また、逆にＴＣＰパケットに戻すことも可能である（ステップＳ１１４／Ｙｅｓ，Ｓ１１１）。
例えば、サーバでビデオ映像を再生する場合や、アニメーション効果をふんだんに用いたプレゼンテーションのスライドショーを行う場合、画面データの送信量が多くなり、確実性よりも、速度が要求される場合などに、ＵＤＰパケットで送信するモードに切り替える。一方、文字ばかりのデータを共有する場合は、確実に表示されないと困るので、ＴＣＰパケットを利用するように切り替える。
このように、最初デフォルト設定では、ＴＣＰ接続を確立したクライアントに対しては、ＴＣＰパケットで画面データを送信するように設定されているとする（ステップＳ１１１）。図１７のような画面共有プログラムの通信手段切り替え機能により、ＵＤＰパケットで送信するよう指示された場合（ステップＳ１１２／Ｙｅｓ）は、画面データをＵＤＰパケットで送信する（ステップＳ１１３）。また、逆にＴＣＰパケットに戻すことも可能である（ステップＳ１１４／Ｙｅｓ，Ｓ１１１）。
例えば、サーバでビデオ映像を再生する場合や、アニメーション効果をふんだんに用いたプレゼンテーションのスライドショーを行う場合、画面データの送信量が多くなり、確実性よりも、速度が要求される場合などに、ＵＤＰパケットで送信するモードに切り替える。一方、文字ばかりのデータを共有する場合は、確実に表示されないと困るので、ＴＣＰパケットを利用するように切り替える。
また、実施例９の変更例として、サーバ側のプログラムから切り替えるのでなく、クライアント側からＴＣＰとＵＤＰの切り替えを要求するようにしてもよい。
実施例１０では、ユーザ毎にＴＣＰパケットまたはＵＤＰパケットを用いるかを選択する手段について説明する。
図１９は、ユーザ毎に通信プロトコルの切り替え指示を行う画面を例示した図であり、クライアント毎にＴＣＰを用いるか、ＵＤＰを用いるかを選択することが可能である。
画面共有サーバは、クライアントのＩＰアドレスまたは、ホスト名、あるいは画面共有プログラムでやり取りする任意の識別名（例えば利用者の名前）を用いて、各クライアント毎の設定を変更する機能を有する。現在接続しているクライアントに対して、ＴＣＰとＵＤＰのどちらを用いて、画面データを送信しているかを、管理し、表示すると共に、その設定を変更する機能を有する。
図１９は、ユーザ毎に通信プロトコルの切り替え指示を行う画面を例示した図であり、クライアント毎にＴＣＰを用いるか、ＵＤＰを用いるかを選択することが可能である。
画面共有サーバは、クライアントのＩＰアドレスまたは、ホスト名、あるいは画面共有プログラムでやり取りする任意の識別名（例えば利用者の名前）を用いて、各クライアント毎の設定を変更する機能を有する。現在接続しているクライアントに対して、ＴＣＰとＵＤＰのどちらを用いて、画面データを送信しているかを、管理し、表示すると共に、その設定を変更する機能を有する。
図１９では、チェックの入っている「亜伊 上男」と「嵯支 須世曾」の２人がＴＣＰで送信するクライアントとして設定されていて、チェックの入っていない「柿 久華子」がＵＤＰで送信するクライアントとして設定されている。
また、図１９に示すように、「全員ＴＣＰ」ボタンの押下により、全員、ＴＣＰパケットで送信することも、また、「全員ＵＤＰ」ボタンの押下により、全員、ＵＤＰパケットで送信することも可であり、ネットワークに参加しているクライアントが多数の場合には、このような手段も有効である。
また、図１９に示すように、「全員ＴＣＰ」ボタンの押下により、全員、ＴＣＰパケットで送信することも、また、「全員ＵＤＰ」ボタンの押下により、全員、ＵＤＰパケットで送信することも可であり、ネットワークに参加しているクライアントが多数の場合には、このような手段も有効である。
実施例１１は、クライアントの接続台数によって、ＴＣＰとＵＤＰを切り替えて送信する方式の例であり、図２０は、そのアルゴリズムを示した図である。
サーバ１の画面共有プログラムは、ネットワーク上のクライアントの接続台数を監視している（ステップＳ１２１）。
接続台数が所定の台数を超えたことを検出した場合（ステップＳ１２２／Ｙｅｓ）は、画面データを送信するのに用いる通信方式を、ＴＣＰからＵＤＰに切り替える（ステップＳ１２４）。これにより、クライアントの台数が多い場合に、通信量が増えて各クライアントの画面表示にディレイが生じるのを低減する。
また、ＵＤＰでの通信を行っている場合に、ネットワークに接続されているクライアントの台数が、所定の台数以下である場合（ステップＳ１２２／Ｎｏ）は、通信方式をＵＤＰからＴＣＰに切り替える（ステップＳ１２３）。接続台数が少なく、ネットワークのデータ通信量が小さい場合には、信頼性の高いＴＣＰにより通信を行う。
サーバ１の画面共有プログラムは、ネットワーク上のクライアントの接続台数を監視している（ステップＳ１２１）。
接続台数が所定の台数を超えたことを検出した場合（ステップＳ１２２／Ｙｅｓ）は、画面データを送信するのに用いる通信方式を、ＴＣＰからＵＤＰに切り替える（ステップＳ１２４）。これにより、クライアントの台数が多い場合に、通信量が増えて各クライアントの画面表示にディレイが生じるのを低減する。
また、ＵＤＰでの通信を行っている場合に、ネットワークに接続されているクライアントの台数が、所定の台数以下である場合（ステップＳ１２２／Ｎｏ）は、通信方式をＵＤＰからＴＣＰに切り替える（ステップＳ１２３）。接続台数が少なく、ネットワークのデータ通信量が小さい場合には、信頼性の高いＴＣＰにより通信を行う。
また、実施例１１の変更例として、接続台数が所定の台数を超えた場合に、図１９で示したダイアログを表示し、ＵＤＰに切り替えるクライアントを指定してもよいし、全クライアントをＵＤＰに切り替えてもよい。
実施例１２は、クライアントの通信インターフェースによって、ＴＣＰとＵＤＰを切り替えて送信する方式の例であり、図２１は、そのアルゴリズムを示した図である。
サーバ１上の画面共有プログラムは、クライアントが有線ＬＡＮでネットワークに接続しているか、無線ＬＡＮを介して接続しているかを取得する機能を有する。
クライアントは、自身の通信インターフェースに関する情報を、ＯＳのシステム情報から取得することが可能である。クライアントの画面共有プログラムは、サーバ１に接続する際、この通信インターフェース情報を送信する。
一方、サーバ１は、クライアントから送られた通信インターフェースの情報から、それが無線ＬＡＮかどうかを判定する。例えば、インターフェースの名前、あるいは無線ＬＡＮであれば、ＩＥＥＥ８０２．１１のどの規格のものであるか等の情報から判断する。
サーバ１上の画面共有プログラムは、クライアントが有線ＬＡＮでネットワークに接続しているか、無線ＬＡＮを介して接続しているかを取得する機能を有する。
クライアントは、自身の通信インターフェースに関する情報を、ＯＳのシステム情報から取得することが可能である。クライアントの画面共有プログラムは、サーバ１に接続する際、この通信インターフェース情報を送信する。
一方、サーバ１は、クライアントから送られた通信インターフェースの情報から、それが無線ＬＡＮかどうかを判定する。例えば、インターフェースの名前、あるいは無線ＬＡＮであれば、ＩＥＥＥ８０２．１１のどの規格のものであるか等の情報から判断する。
図２１に示すように、クライアントからの接続を受け付けた場合、クライアントの通信インターフェース情報を取得し、有線ＬＡＮか無線ＬＡＮかを判断する（ステップＳ１３１）。有線ＬＡＮの場合（ステップＳ１３２／Ｎｏ）は、ＵＤＰパケットで画面データを送信するよう設定し（ステップＳ１３４）、一方で無線ＬＡＮの場合（ステップＳ１３２／Ｙｅｓ）は、ＴＣＰパケットで画面データを送信するよう設定する（ステップＳ１３３）。
また、実施例１２の変更例として、サーバ１自身が無線ＬＡＮインターフェースで通信している場合、デフォルト設定を、ＴＣＰパケットで画面データを送信するようにしてもよい。
また、ＴＣＰで送信するように設定するインターフェースの対象は、無線ＬＡＮだけでなく、ＩｒＤＡやＢｌｕｅｔｏｏｔｈ（登録商標）も含んで良い。
また、ＴＣＰで送信するように設定するインターフェースの対象は、無線ＬＡＮだけでなく、ＩｒＤＡやＢｌｕｅｔｏｏｔｈ（登録商標）も含んで良い。
また、別の変更例として、サーバ１及びクライアントの画面共有プログラムに、お互いの通信インターフェースに関する情報のやり取りを行う機能を設け、サーバ１とクライアントの接続確立時に、この情報のやり取りを行うようにしてもよい。
クライアントが無線インターフェースを利用していることを判断すると、上記例のように、ＴＣＰパケットで画面データを送信する設定とし、有線ＬＡＮと判断した場合には、ＵＤＰパケットを利用する設定とする。
クライアントが無線インターフェースを利用していることを判断すると、上記例のように、ＴＣＰパケットで画面データを送信する設定とし、有線ＬＡＮと判断した場合には、ＵＤＰパケットを利用する設定とする。
実施例１３は、クライアントの接続経路によって、ＴＣＰとＵＤＰを切り替えて送信する方式の例であり、図２２は、そのアルゴリズムを示した図である。
サーバ１上の画面共有プログラムは、クライアントとＬＡＮで接続しているか、ＷＡＮを介して接続しているかを取得する機能を有する。
サーバ１上の画面共有プログラムは、クライアントとＬＡＮで接続しているか、ＷＡＮを介して接続しているかを取得する機能を有する。
クライアントがＬＡＮ接続であるか、ＷＡＮ接続であるかを判断するには、以下の方法がある。
（方法１）
クライアントは、自身の通信インターフェースに関する情報を、ＯＳのシステム情報から取得することが可能である。クライアントの画面共有プログラムは、はサーバ１に接続する際、この通信インターフェース情報を送信する。
一方、サーバ１は、クライアントから送られた通信インターフェースの情報から、第一の判断を行う。インターフェースがモデムであれば、ＷＡＮで接続していると判断する。
（方法１）
クライアントは、自身の通信インターフェースに関する情報を、ＯＳのシステム情報から取得することが可能である。クライアントの画面共有プログラムは、はサーバ１に接続する際、この通信インターフェース情報を送信する。
一方、サーバ１は、クライアントから送られた通信インターフェースの情報から、第一の判断を行う。インターフェースがモデムであれば、ＷＡＮで接続していると判断する。
（方法２）
サーバ１自身のネットワーク情報とクライアントのＩＰアドレスを照合し、クライアントのＩＰアドレスがグローバルＩＰであれば、そのクライアントはＷＡＮから接続していると判断する。
サーバ１自身のネットワーク情報とクライアントのＩＰアドレスを照合し、クライアントのＩＰアドレスがグローバルＩＰであれば、そのクライアントはＷＡＮから接続していると判断する。
（方法３）
クライアントに対して、ネットワークコマンドの１つであるｔｒａｃｅｒｏｕｔｅコマンドを使って、ルーティング情報を問い合わせる。そこで、ＬＡＮの外に出ていることを確認した場合、そのクライアントはＷＡＮから接続していると判断する。
クライアントに対して、ネットワークコマンドの１つであるｔｒａｃｅｒｏｕｔｅコマンドを使って、ルーティング情報を問い合わせる。そこで、ＬＡＮの外に出ていることを確認した場合、そのクライアントはＷＡＮから接続していると判断する。
図２２に示すように、クライアントからの接続を受け付けた場合、クライアントがＬＡＮ接続かＷＡＮ接続かを判断し（ステップＳ１４１）、ＬＡＮ接続の場合（ステップＳ１４２／Ｎｏ）は、ＵＤＰパケットで画面データを送信するよう設定する（ステップＳ１４４）。一方、ＷＡＮの場合（ステップＳ１４２／Ｙｅｓ）は、ＴＣＰパケットで画面データを送信するよう設定する（ステップＳ１４３）。
実施例１４は、送信すべきエンコードデータの残量によって、ＴＣＰとＵＤＰを切り替えて送信する方式の例であり、図２３は、そのアルゴリズムを示した図である。
サーバ１上の画面共有プログラムは、画面更新が行われた場合、更新領域をエンコードして送信するのに必要なデータ量を計測する手段を有する。画面共有プログラムのうち、更新領域をエンコードする部分から、この量を取得する（ステップＳ１５１）。
サーバ１上の画面共有プログラムは、画面更新が行われた場合、更新領域をエンコードして送信するのに必要なデータ量を計測する手段を有する。画面共有プログラムのうち、更新領域をエンコードする部分から、この量を取得する（ステップＳ１５１）。
ある時点で、送信すべきエンコードデータ残量が、ある一定以上の場合は、ＵＤＰパケットで送信するようにする。例えば、残量が５００キロバイトを超えた場合に設定する。
図２３に示すように、更新量が所定の閾値を越えた場合（ステップＳ１５２／Ｙｅｓ）は、画面データを、ＵＤＰパケットで速度を優先して送信し（ステップＳ１５３）、そうでない場合（ステップＳ１５２／Ｎｏ）は、ＴＣＰパケットでクライアントの受信を確認しながら送信する（ステップＳ１５４）。
また、ＵＤＰ通信を行っている場合に、残量が閾値よりも少なくなった場合は、自動的にＴＣＰパケットでの送信に戻す。
図２３に示すように、更新量が所定の閾値を越えた場合（ステップＳ１５２／Ｙｅｓ）は、画面データを、ＵＤＰパケットで速度を優先して送信し（ステップＳ１５３）、そうでない場合（ステップＳ１５２／Ｎｏ）は、ＴＣＰパケットでクライアントの受信を確認しながら送信する（ステップＳ１５４）。
また、ＵＤＰ通信を行っている場合に、残量が閾値よりも少なくなった場合は、自動的にＴＣＰパケットでの送信に戻す。
実施例１４の変更例として、エンコード前の更新が必要なビットマップデータ量だけで判断してもよい。例えば、残量が１メガバイトを超えた場合に設定する。
実施例１５は、送信データレートによって、ＴＣＰとＵＤＰを切り替えて送信する方式の例であり、図２４は、そのアルゴリズムを示した図である。
サーバ１上の画面共有プログラムは、画面更新が行われた場合、単位時間当たり送信しているデータ送信レート（単位時間あたりの送信データ量）を計測する手段を有する。例えば、ＯＳのシステム情報の送信ビットレートから取得する（ステップＳ１６１）。
サーバ１上の画面共有プログラムは、画面更新が行われた場合、単位時間当たり送信しているデータ送信レート（単位時間あたりの送信データ量）を計測する手段を有する。例えば、ＯＳのシステム情報の送信ビットレートから取得する（ステップＳ１６１）。
データレートが所定の閾値よりも小さい場合（ステップＳ１６２／Ｙｅｓ）は、画面データを、ＵＤＰパケットで速度を優先して送信し（ステップＳ１６３）、そうでない場合（ステップＳ１６２／Ｎｏ）は、ＴＣＰパケットでクライアントの受信を確認しながら送信する（ステップＳ１６４）。
また、ＵＤＰ通信を行っている場合に、データレートが閾値よりも大きくなった場合は、自動的にＴＣＰパケットでの送信に戻す。
また、ＵＤＰ通信を行っている場合に、データレートが閾値よりも大きくなった場合は、自動的にＴＣＰパケットでの送信に戻す。
実施例１６は、サーバとクライアントとの間の通信速度によって、ＴＣＰとＵＤＰを切り替えて送信する方式の例であり、図２５は、そのアルゴリズムを示した図である。
サーバ１及びクライアント上で起動する画面共有プログラムは、クライアントがサーバ１に接続した際、サーバ１とクライアントの間の通信速度を測定する。
サーバ１とクライアントの間の通信速度を測定を行う方法には、従来の測定方法を用いることができる。例えば、インターネット上のウェブサイトで行われているのと同様に、数メガバイトのデータを送信して、所要時間を測定する方法がある。
サーバ１及びクライアント上で起動する画面共有プログラムは、クライアントがサーバ１に接続した際、サーバ１とクライアントの間の通信速度を測定する。
サーバ１とクライアントの間の通信速度を測定を行う方法には、従来の測定方法を用いることができる。例えば、インターネット上のウェブサイトで行われているのと同様に、数メガバイトのデータを送信して、所要時間を測定する方法がある。
図２５に示すように、クライアントからの接続を受け付けた場合、サーバ１は、サーバ１とクライアントの間の通信速度を測定し（ステップＳ１７１）、通信速度が所定の値以上の場合（ステップＳ１７２／Ｙｅｓ）は、ＴＣＰパケットで画面データを送信するよう設定し（ステップＳ１７３）、所定の値未満の場合（ステップＳ１７２／Ｎｏ）は、ＵＤＰパケットで画面データを送信するよう設定する（ステップＳ１７４）。
ここで、この判断の基準値は、例えば１メガバイト／秒（Ｍｂｐｓ）とすることができる。
ここで、この判断の基準値は、例えば１メガバイト／秒（Ｍｂｐｓ）とすることができる。
実施例１７は、サーバとクライアントとの間のＭＴＵによって、ＴＣＰとＵＤＰを切り替えて送信する方式の例であり、図２６は、そのアルゴリズムを示した図である。
サーバ１上で起動する画面共有プログラムは、クライアントがサーバ１に接続した際、サーバ１とクライアントの間のＭＴＵを測定する手段を有する。
サーバーとクライアントの間のＭＴＵを測定を行う方法には、従来の測定方法を用いることができる。例えば、ネットワークコマンドの１つであるｐｉｎｇコマンドを使って、断片化しない最大データ容量を調べる方法がある。
以下にその原理を示す。
サーバ１上で起動する画面共有プログラムは、クライアントがサーバ１に接続した際、サーバ１とクライアントの間のＭＴＵを測定する手段を有する。
サーバーとクライアントの間のＭＴＵを測定を行う方法には、従来の測定方法を用いることができる。例えば、ネットワークコマンドの１つであるｐｉｎｇコマンドを使って、断片化しない最大データ容量を調べる方法がある。
以下にその原理を示す。
ping -f -l <パケットサイズ> <[相手先ホスト名]または[相手先IPアドレス]>
ただし、
-f・・・パケットの分割を禁止するオプション
-l・・・パケットのサイズを指定するオプション
ただし、
-f・・・パケットの分割を禁止するオプション
-l・・・パケットのサイズを指定するオプション
上記のようなｐｉｎｇコマンドを送信することにより、クライアントに対して、何バイトまでのパケットが分割されずに送信されるかを確認することができる。
図２６に示すように、クライアントからの接続を受け付けた場合、サーバ１は、サーバとクライアントの間のＭＴＵを測定し（ステップＳ１８１）、ＭＴＵが所定の値以上の場合（ステップＳ１８２／Ｙｅｓ）は、ＴＣＰパケットで画面データを送信するよう設定し（ステップＳ１８３）、所定の値未満の場合（ステップＳ１８２／Ｎｏ）は、ＵＤＰパケットで画面データを送信するよう設定する（ステップＳ１８４）。
ここで、この判断の基準値は、例えば１メガバイトとすることができる。
ここで、この判断の基準値は、例えば１メガバイトとすることができる。
前記アルゴリズムにおいて、ＭＴＵが小さい場合は、１つのパケットで送れるデータ容量が小さいので、ＴＣＰのＡＣＫ返答を行っていると、通信効率が悪くなるので、ＵＤＰパケットで送信している。
実施例１８は、サーバとクライアントとの間のＱｏＳによって、ＴＣＰとＵＤＰを切り替えて送信する方式の例であり、図２７は、そのアルゴリズムを示した図である。
サーバ１上で起動する画面共有プログラムは、クライアントがサーバ１に接続した際、ＱｏＳを測定し、帯域幅、最低保証速度、最大遅延時間、パケット間隔、ピーク速度、ネットワークの遅延やジッタ、パケットロス等を測定し、通信品質を評価する手段を有する。
サーバ１上で起動する画面共有プログラムは、クライアントがサーバ１に接続した際、ＱｏＳを測定し、帯域幅、最低保証速度、最大遅延時間、パケット間隔、ピーク速度、ネットワークの遅延やジッタ、パケットロス等を測定し、通信品質を評価する手段を有する。
図２７に示すように、クライアントからの接続を受け付けた場合、サーバ１は、サーバとクライアントの間のＱｏＳを測定し（ステップＳ１９１）、通信品質が一定の基準を満たしている場合（ステップＳ１９２／Ｙｅｓ）は、ＵＤＰパケットで画面データを送信するよう設定し（ステップＳ１９４）、満たしていないと判断した場合（ステップＳ１９２／Ｎｏ）は、ＴＣＰパケットで画面データを送信するよう設定する（ステップＳ１９３）。
ただし、必ずしも、全てのパラメータを測定する必要はない。
ただし、必ずしも、全てのパラメータを測定する必要はない。
実施例１９は、クライアントの優先順位によって、ＴＣＰとＵＤＰを切り替えて送信する方式の例であり、図２８は、そのアルゴリズムを示した図である。
サーバ１上で起動する画面共有プログラムは、複数のクライアントが接続して、同時に画面を共有することが可能な画面共有システムにおいて、クライアントに優先順位を付ける機能を有する。
例えば、サーバ１の画面が更新された場合、まず、優先権の与えられたクライアントに対してＴＣＰパケットで確実に画面データを送信し（ステップＳ２０１，Ｓ２０２／Ｙｅｓ，Ｓ２０３）、優先権のないクライアントに対しては、その後ＵＤＰパケットで、受信確認なしで画面データを送信する（ステップＳ２０１，Ｓ２０２／Ｎｏ，Ｓ２０４）。
サーバ１上で起動する画面共有プログラムは、複数のクライアントが接続して、同時に画面を共有することが可能な画面共有システムにおいて、クライアントに優先順位を付ける機能を有する。
例えば、サーバ１の画面が更新された場合、まず、優先権の与えられたクライアントに対してＴＣＰパケットで確実に画面データを送信し（ステップＳ２０１，Ｓ２０２／Ｙｅｓ，Ｓ２０３）、優先権のないクライアントに対しては、その後ＵＤＰパケットで、受信確認なしで画面データを送信する（ステップＳ２０１，Ｓ２０２／Ｎｏ，Ｓ２０４）。
実施例２０では、更に、優先権と、共有画面上での遠隔制御の制御権とを関連付けて登録する方法について説明している。
図２９に示すように、制御権を得ているクライアントのみ（クライアント「亜伊 上男(192. 168. 0. 2)」）が、遠隔操作が可能で、制御権を所持しているクライアントに対しては、所有していないクライアントよりも先に、ＴＣＰパケットで画面データを送信する。一方、制御権のないクライアントは、共有画面を閲覧するだけで、入力イベントはサーバに受け付けられない。また、制御権のないクライアントへの画面データ送信後に、ＵＤＰパケットで、受信確認なしで画面データを受信する。
図２９に示すように、制御権を得ているクライアントのみ（クライアント「亜伊 上男(192. 168. 0. 2)」）が、遠隔操作が可能で、制御権を所持しているクライアントに対しては、所有していないクライアントよりも先に、ＴＣＰパケットで画面データを送信する。一方、制御権のないクライアントは、共有画面を閲覧するだけで、入力イベントはサーバに受け付けられない。また、制御権のないクライアントへの画面データ送信後に、ＵＤＰパケットで、受信確認なしで画面データを受信する。
実施例２１では、複数のクライアントが接続して、同時に画面を共有し、遠隔操作することが可能な画面共有システムにおいて、遠隔操作中のクライアントに対して、画面データ送信優先度を高くする方法について説明している。
サーバ１は、クライアントが遠隔操作中であるかどうかを判断する機能を有する。
図３０に示すように、クライアントがリモート操作を行うと、サーバ１は、そのクライアントのリモート操作フラッグをＯＮにする（ステップＳ２１１）。そこでタイマーをスタートし（ステップＳ２１２）、一定時間内に、例えば、１分以内に、クライアントが操作を行ったかどうかで、クライアントが操作中であるかどうかを判断する。例えば、１分以内に何の入力イベントがない場合、サーバ１はそのクライアントが遠隔操作を行っていないと判断して（Ｓ２１３／Ｎｏ，Ｓ２１４／Ｙｅｓ）、リモート操作フラッグをＯＦＦにする（ステップＳ２１５）。
サーバ１は、クライアントが遠隔操作中であるかどうかを判断する機能を有する。
図３０に示すように、クライアントがリモート操作を行うと、サーバ１は、そのクライアントのリモート操作フラッグをＯＮにする（ステップＳ２１１）。そこでタイマーをスタートし（ステップＳ２１２）、一定時間内に、例えば、１分以内に、クライアントが操作を行ったかどうかで、クライアントが操作中であるかどうかを判断する。例えば、１分以内に何の入力イベントがない場合、サーバ１はそのクライアントが遠隔操作を行っていないと判断して（Ｓ２１３／Ｎｏ，Ｓ２１４／Ｙｅｓ）、リモート操作フラッグをＯＦＦにする（ステップＳ２１５）。
また、画面データの更新があった場合、図３１に示すように、サーバ１はリモート操作フラッグのＯＮ／ＯＦＦを調べ（ステップＳ２２１）、フラッグがＯＮのクライアントに対しては、ＯＦＦのクライアントよりも先に、ＴＣＰパケットで画面データを送信する（ステップＳ２２２）。一方、フラッグＯＦＦのクライアントに対しては、ＯＮのクライアントへの画面データ送信後に、ＵＤＰパケットで、受信確認なしで画面データを送信する（ステップＳ２２３）。
これにより、操作を行っている人に対して、品質・速度を優先して、画面データを送信し、遠隔操作に不便を感じないようにすることが可能である。
これにより、操作を行っている人に対して、品質・速度を優先して、画面データを送信し、遠隔操作に不便を感じないようにすることが可能である。
実施例２１の変更例として、例えば、実施例２０のように、制御権の管理を組み合わせることも可能である。その場合、制御権のない制御権のないクライアントに対しては、画面データは常にＵＤＰパケットで送信する。
実施例２２は、共有画面データがフォントデータであるか画像データであるかによって、ＴＣＰとＵＤＰを切り替えて送信する方式の例であり、図３２は、そのアルゴリズムを示した図である。
画面の更新があった場合、先ず、文字が表示された部分の画像データを、ＴＣＰパケットで確実に送信し、その後、その他の領域の画像データをＵＤＰパケットで送信し、クライアントの画面で、文字の部分を読みやすくする。
画面の更新があった場合、先ず、文字が表示された部分の画像データを、ＴＣＰパケットで確実に送信し、その後、その他の領域の画像データをＵＤＰパケットで送信し、クライアントの画面で、文字の部分を読みやすくする。
サーバ１上で起動する画面共有プログラムは、共有画面に更新があった場合、更新領域を分割して、エンコードし、クライアントにその画面データを送信するが、ここで、分割した画面領域にＯＳがフォント描画命令を出している箇所かどうかを判定し（ステップＳ２３１）、フォント描画命令を出している領域である場合（ステップＳ２３２／Ｙｅｓ）は、ＴＣＰパケットで画面データを送信する（ステップＳ２３３）。一方、フォント描画命令が出ていない部分については（ステップＳ２３２／Ｎｏ）、ＵＤＰパケットで画面データを送信する（ステップＳ２３４）。また、送信の順序としては、フォント描画部分を先に送信することが望ましい。
フォント描画命令の検出方法として、例えば、サーバ１上で起動する画面共有プログラムが、分割領域のＧＤＩ（Ｇｒａｐｈｉｃ Ｄｅｖｉｃｅ Ｉｎｔｅｒｆａｃｅ）命令を調べ、フォント描画命令が出ているか否かによって実行する方法がある。
フォント描画命令の検出方法として、例えば、サーバ１上で起動する画面共有プログラムが、分割領域のＧＤＩ（Ｇｒａｐｈｉｃ Ｄｅｖｉｃｅ Ｉｎｔｅｒｆａｃｅ）命令を調べ、フォント描画命令が出ているか否かによって実行する方法がある。
実施例２３は、ＣＰＵの負荷状況に応じて、ＴＣＰとＵＤＰを切り替えて送信する方式の例であり、図３３は、そのアルゴリズムを示した図である。
サーバ１上の画面共有プログラムは、画面更新が行われた場合に、ＣＰＵの負荷量を計測する手段を有する。例えば、ＯＳのシステム情報のＣＰＵ負荷情報から取得する。
サーバ１上の画面共有プログラムは、画面更新が行われた場合に、ＣＰＵの負荷量を計測する手段を有する。例えば、ＯＳのシステム情報のＣＰＵ負荷情報から取得する。
図３３に示すように、ＣＰＵの負荷量を計測し（ステップＳ２４１）、ＣＰＵの負荷量が所定の閾値を越えた場合（ステップＳ２４２／Ｙｅｓ）は、画面データをＵＤＰパケットで速度を優先して送信し（ステップＳ２４４）、そうでない場合（ステップＳ２４２／Ｎｏ）は、ＴＣＰパケットでクライアントの受信を確認しながら送信する（ステップＳ２４３）。また、ＣＰＵの負荷量が閾値よりも少なくなった場合は、自動的にＴＣＰパケットでの送信に戻す。
閾値の設定として、例えば、ＣＰＵ負荷が１秒間以上にわたって８０％を超えている場合は、ＵＤＰパケットに切り替えるようにする。
閾値の設定として、例えば、ＣＰＵ負荷が１秒間以上にわたって８０％を超えている場合は、ＵＤＰパケットに切り替えるようにする。
ＣＰＵの負荷が大きいときは、それだけ画面更新量が多いため、更新部分の画面データのエンコードに時間が掛かっていることが多い。また、ＣＰＵ負荷が大きい場合、更新部分の画面データのエンコード処理が遅くなるため、通信処理部分のＣＰＵ負荷を小さくする、すなわち、通信速度を速くする必要がある。そのため、ＴＣＰパケットからＵＤＰパケットに切り替えることにより、ＣＰＵ負荷を減らすと共に、クライアントの画面表示の遅延を低減することが可能である。
また、上記実施例１から２３を適宜組み合わせることにより、高速な画面共有システムが実現される。例えば、制御権のない閲覧のみのクライアントに対しては、無条件で、ＵＤＰマルチキャストによって、同報通信により画面データを送信し、制御権のあるクライアントに対しては、最前面にあるアクティブウィンドウの文字描画が部分のデータをＴＣＰパケットで優先的に送信し、それ以外の部分はＵＤＰパケットで送信する。
あるいは、有線ＬＡＮで接続しているクライアントに対しては、無条件でＵＤＰパケットで画面データを送信し、無線ＬＡＮで接続しているクライアントに対しては、指定したアプリケーションのみをＴＣＰパケットで優先的に送信し、それ以外の部分はＵＤＰパケットで送信するなどの組み合わせが可能である。
あるいは、有線ＬＡＮで接続しているクライアントに対しては、無条件でＵＤＰパケットで画面データを送信し、無線ＬＡＮで接続しているクライアントに対しては、指定したアプリケーションのみをＴＣＰパケットで優先的に送信し、それ以外の部分はＵＤＰパケットで送信するなどの組み合わせが可能である。
実施例２４〜２７では、ネットワークに中継機器（プロキシ）を設けた場合について説明する。
図３４は、本発明の一実施例であるデータ通信システムのネットワーク構成を示した概要図である。
データ通信システムは、サーバとして機能する情報処理装置（サーバ１）と、前記サーバ１のクライアントとして機能する情報処理装置（クライアント２ａ，２ｂ，・・・，２ｎ）と、サーバ１及びクライアント２との間に中継機器３と、を含む形で構成される。サーバ１、クライアント２、中継器機３は、例えば、パーソナルコンピュータであり、これらが、例えば、ＩＥＥＥ８０２．３で定められているイーサネット（登録商標）ＬＡＮによるネットワークで接続されている。
図３４は、本発明の一実施例であるデータ通信システムのネットワーク構成を示した概要図である。
データ通信システムは、サーバとして機能する情報処理装置（サーバ１）と、前記サーバ１のクライアントとして機能する情報処理装置（クライアント２ａ，２ｂ，・・・，２ｎ）と、サーバ１及びクライアント２との間に中継機器３と、を含む形で構成される。サーバ１、クライアント２、中継器機３は、例えば、パーソナルコンピュータであり、これらが、例えば、ＩＥＥＥ８０２．３で定められているイーサネット（登録商標）ＬＡＮによるネットワークで接続されている。
サーバ１は、自身の表示装置に表示されるＤｅｓｋｔｏｐ画面全体、または、そこに表示されている画面の一部を共有画面とし、共有画面データを接続しているクライアント２に送信することにより、受信したクライアントは、表示装置にサーバ１の共有画面を表示することができる。
本例では、サーバ１とクライアント２の間に、中継機器（以下、プロキシと省略する）が存在し、サーバ１から受信した画面データを受信し、プロキシに接続しているクライアントに画面データを転送する。これにより、サーバ１に多数のクライアントが接続した際の、サーバの負荷を低減し、通信効率を向上させることが可能である。
本例では、サーバ１とクライアント２の間に、中継機器（以下、プロキシと省略する）が存在し、サーバ１から受信した画面データを受信し、プロキシに接続しているクライアントに画面データを転送する。これにより、サーバ１に多数のクライアントが接続した際の、サーバの負荷を低減し、通信効率を向上させることが可能である。
また、実施例１の場合と同様に、クライアント２に表示された共有画面内において、該クライアントのマウスやキーボードなどの入力機器からのイベントを、サーバ１に送信することにより、クライアントからサーバの遠隔操作も可能であるが、これもプロキシを通して行ってもよいし、入力イベントはプロキシを介さず、直接サーバに送信するような通信方式を採用してもよい。
以下に、その原理を説明する。
プロキシを用いた画面の共有方法は、ＭｕｌｔｉｃａｓｔＶＮＣやＶＮＣ Ｐｒｏｘｙあるいは、ＶＮＣ Ｒｅｆｌｅｃｔｏｒ等の従来技術をそのまま利用できるので、詳細は省略する。概略としては、サーバのアプリケーションが、サーバの画面データの更新部分を検出し、画面の更新領域を、一定のアルゴリズムにより分割して、エンコードして、プロキシに送信する。プロキシは、一種の画面共有クライアントとして起動する。プロキシはそれと共に、受信した画面データを接続しているクライアントに転送するサーバとしての機能を持ち、受信したクライアントは、更新された領域の画面データをデコードして、共有画面のデータを更新することにより、サーバの画面を表示することが可能となっている。
プロキシを用いた画面の共有方法は、ＭｕｌｔｉｃａｓｔＶＮＣやＶＮＣ Ｐｒｏｘｙあるいは、ＶＮＣ Ｒｅｆｌｅｃｔｏｒ等の従来技術をそのまま利用できるので、詳細は省略する。概略としては、サーバのアプリケーションが、サーバの画面データの更新部分を検出し、画面の更新領域を、一定のアルゴリズムにより分割して、エンコードして、プロキシに送信する。プロキシは、一種の画面共有クライアントとして起動する。プロキシはそれと共に、受信した画面データを接続しているクライアントに転送するサーバとしての機能を持ち、受信したクライアントは、更新された領域の画面データをデコードして、共有画面のデータを更新することにより、サーバの画面を表示することが可能となっている。
図３５を用いて、プロキシを介して画面共有を行う方式の処理フローを説明する。
サーバ１とプロキシ３との接続管理、プロキシ３とクライアント２との接続管理は、実施例２と同様にＴＣＰの接続管理によって行っているものとする。すなわち、プロキシ３はサーバ１に対してＴＣＰによる接続要求を行い（ステップＳ３０１）、サーバ１が応答し、サーバ〜プロキシ間のＴＣＰ接続が確立する（ステップＳ３０２，Ｓ３０３）。また、クライアント２は、プロキシ３に対してＴＣＰによる接続要求を行い（ステップＳ３０４）、プロキシ３が応答し、クライアント〜プロキシ間のＴＣＰ接続が確立する（ステップＳ３０５，Ｓ３０６）。
プロキシ３は、サーバ１からＴＣＰパケットで受信確認を行いながら画面データを受信すると（ステップＳ３０７，Ｓ３０８）、その画面データを接続されたクライアントに対してＵＤＰパケットで画面データを送信する（ステップＳ３０９）。
サーバ１とプロキシ３との接続管理、プロキシ３とクライアント２との接続管理は、実施例２と同様にＴＣＰの接続管理によって行っているものとする。すなわち、プロキシ３はサーバ１に対してＴＣＰによる接続要求を行い（ステップＳ３０１）、サーバ１が応答し、サーバ〜プロキシ間のＴＣＰ接続が確立する（ステップＳ３０２，Ｓ３０３）。また、クライアント２は、プロキシ３に対してＴＣＰによる接続要求を行い（ステップＳ３０４）、プロキシ３が応答し、クライアント〜プロキシ間のＴＣＰ接続が確立する（ステップＳ３０５，Ｓ３０６）。
プロキシ３は、サーバ１からＴＣＰパケットで受信確認を行いながら画面データを受信すると（ステップＳ３０７，Ｓ３０８）、その画面データを接続されたクライアントに対してＵＤＰパケットで画面データを送信する（ステップＳ３０９）。
図３５の処理フローの変更例として、例えば、プロキシ３は、サーバ１からＵＤＰパケットで受信した画面データを、ＵＤＰパケットでクライアント２に転送してもよい。
また、例えば、サーバ１からＵＤＰパケットで受信した画面データを、ＴＣＰパケットでクライアント２に転送してもよい。
あるいは、サーバ１からＴＣＰパケットで受信した画面データを、ＴＣＰパケットでクライアント２に転送するという方法もある。
また、例えば、サーバ１からＵＤＰパケットで受信した画面データを、ＴＣＰパケットでクライアント２に転送してもよい。
あるいは、サーバ１からＴＣＰパケットで受信した画面データを、ＴＣＰパケットでクライアント２に転送するという方法もある。
また、図３４に示した構成の変更例として、例えば、図３６に示すように、クライアント２は必ずしもプロキシ３を通してサーバ１から画面データを受信する必要はなく、サーバ１に直接接続されているクライアント２ａ，２ｂ，・・・，２ｉと、プロキシを介して接続しているクライアント２ｊ，・・・，２ｎが混在していても構わない。この場合、遠隔操作を行う優先権のあるクライアントのみ、サーバ１に直接接続し、共有画面を閲覧するだけのクライアントはプロキシ３を介して接続することにより、通信効率を向上することが可能となる。
実施例２５は、プロキシにてＵＤＰマルチキャストあるいはＵＤＰブロードキャストを適用した例であり、図３７にその処理フローを示す。また、表２はネットワーク構成におけるネットワークアドレスの一例である。
＜１．ブロードキャストの場合＞
サーバ１は、ＵＤＰソケットで、（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）からの画面データを待ち受けしている。
サーバ１は、ＵＤＰソケットで、（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. 111）と（133. 139. 100. 222）からの入力イベントを待ち受けしている。
プロキシ３は、クライアントからの入力イベントを受信すると、ＴＣＰパケットで、サーバ１に入力イベントを転送する。
クライアント２ｊ，２ｎは、（133. 139. 100. 55）からの画面データのブロードキャストを待ち受けしている。また、入力イベントを（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. 111）と（133. 139. 100. 222）からの入力イベントを待ち受けしている。
プロキシ３は、クライアントからの入力イベントを受信すると、ＴＣＰパケットで、サーバ１に入力イベントを転送する。
クライアント２ｊ，２ｎは、プロキシから指定されたマルチキャストキャストアドレス（233. 233. 233. 233）からの画面データを待ち受けしている。また、入力イベントを（133. 139. 100. 100）にＵＤＰユニキャストで送信する。
実施例２６では、プロキシにおけるセッション記録及び再生機能について説明する。
プロキシ３は、サーバ１から受信した画面データを、ＴＣＰパケットでサーバ１が送信して来た順に、時間情報と共に、順次ファイルに追記していき、蓄積する。時間記録は例えば、記録開始時間を原点とする。
クライアント２は、プロキシ３に接続し、記録されたサーバ１の画面データの再生を要求すると、プロキシ３は、記録した画面データを、記録開始時間からの経過時間の指示に従い、順次クライアントにＵＤＰパケットで送信する。
図３８はその様子を示している。サーバ１とプロキシ３の接続が終了後に、クライアント２がプロキシ３に接続して、画面共有の様子を非同期で閲覧することが可能である。なお、再生中は、クライアント２は言うまでもなく閲覧することしかできず、プロキシ３はクライアント２からの入力イベントは受け付けない。
プロキシ３は、サーバ１から受信した画面データを、ＴＣＰパケットでサーバ１が送信して来た順に、時間情報と共に、順次ファイルに追記していき、蓄積する。時間記録は例えば、記録開始時間を原点とする。
クライアント２は、プロキシ３に接続し、記録されたサーバ１の画面データの再生を要求すると、プロキシ３は、記録した画面データを、記録開始時間からの経過時間の指示に従い、順次クライアントにＵＤＰパケットで送信する。
図３８はその様子を示している。サーバ１とプロキシ３の接続が終了後に、クライアント２がプロキシ３に接続して、画面共有の様子を非同期で閲覧することが可能である。なお、再生中は、クライアント２は言うまでもなく閲覧することしかできず、プロキシ３はクライアント２からの入力イベントは受け付けない。
また、プロキシ３がサーバ１からの画面データを記録中に、クライアント２がプロキシ３に接続し、プロキシ３とサーバ１が接続を開始してからの画面データを時間差付きで閲覧することも可能である。
また、実施例２６の変更例として、プロキシに記録した画面データを早送りで再生する機能を有してもよい。
プロキシ３が記録時間データを元に、画面データをクライアント２に送信する際、経過時間を、例えば、記録された値の半分の値として送信間隔を早めることも可能である。
プロキシ３が記録時間データを元に、画面データをクライアント２に送信する際、経過時間を、例えば、記録された値の半分の値として送信間隔を早めることも可能である。
実施例２７，２８では、実施例１〜２６で説明したデータ通信システムを応用した電子会議システムについて説明する。
例えば、図１で示したネットワーク構成において、サーバ１を会議サーバとし、クライアント２を参加者の利用する参加者端末とする電子会議システムを構築する。
会議サーバは、実施例３で説明したような、画面共有サーバ１のＵＤＰマルチキャストを利用した画面データ送信機能を備える。
会議サーバは、会議室内のネットワークにのみマルチキャストパケットが届くようにＴＴＬを設定する。
また、会議サーバは制御権の管理を行い、基本的に、制御権を持っていない参加者端末にはマルチキャストＵＤＰによって画面データを送信している。
一方、制御権を持っている参加者端末に画面データを送信する場合は、最前面にあるアクティブウィンドウの文字領域の画面データを優先的にＴＣＰパケットを用いて、制御権のある参加者端末で早く正確に表示できるよう送信する。文字領域以外のデータは、ＵＤＰパケットで、送信順序の優先度を下げて送信されるようになっている。
例えば、図１で示したネットワーク構成において、サーバ１を会議サーバとし、クライアント２を参加者の利用する参加者端末とする電子会議システムを構築する。
会議サーバは、実施例３で説明したような、画面共有サーバ１のＵＤＰマルチキャストを利用した画面データ送信機能を備える。
会議サーバは、会議室内のネットワークにのみマルチキャストパケットが届くようにＴＴＬを設定する。
また、会議サーバは制御権の管理を行い、基本的に、制御権を持っていない参加者端末にはマルチキャストＵＤＰによって画面データを送信している。
一方、制御権を持っている参加者端末に画面データを送信する場合は、最前面にあるアクティブウィンドウの文字領域の画面データを優先的にＴＣＰパケットを用いて、制御権のある参加者端末で早く正確に表示できるよう送信する。文字領域以外のデータは、ＵＤＰパケットで、送信順序の優先度を下げて送信されるようになっている。
また、例えば、図３６の機器構成で、サーバ１を会議サーバとし、クライアント２を参加者の利用する参加者端末とし、中継機器（プロキシ）３を画面データの録画・再生が可能で、かつマルチキャストＵＤＰパケットによる画面データの転送が可能である会議プロキシとする会議システムを構成する。
会議サーバは、直接接続している参加者端末にマルチキャストパケットが届くようにＴＴＬを設定する。会議プロキシは、プロキシに接続している参加者端末にマルチキャストパケットが届くようにＴＴＬを設定する。
会議サーバは、直接接続している参加者端末にマルチキャストパケットが届くようにＴＴＬを設定する。会議プロキシは、プロキシに接続している参加者端末にマルチキャストパケットが届くようにＴＴＬを設定する。
図３６のように、一部の参加者端末（２ａ，２ｂ，・・・，２ｉ）は会議室内に存在し、会議サーバに直接接続しており、会議サーバから直接マルチキャストＵＤＰパケットを受信する。一方、他の一部の参加者端末（２ｊ，・・・，２ｎ）は、他の会議室にあり、会議プロキシを介して接続しており、会議プロキシからのマルチキャストＵＤＰパケットを受信する。
このように通信を管理することにより、ネットワークの通信効率が向上し、遠隔会議に利用した際、スムーズに画面共有が可能となる。
また、途中から会議に参加したい参加者は、プロキシに接続し、会議の初めから共有画面の画面データを再生し、適宜不要な部分を飛ばして再生したり、早送り再生をすることにより、会議の内容を追いかけ、リアルタイムに会議サーバの画面共有したくなったら、会議サーバに接続を切り替え、同期した共有画面を見たり、遠隔操作を行ったりしながら、会議に参加することが可能となる。
また、途中から会議に参加したい参加者は、プロキシに接続し、会議の初めから共有画面の画面データを再生し、適宜不要な部分を飛ばして再生したり、早送り再生をすることにより、会議の内容を追いかけ、リアルタイムに会議サーバの画面共有したくなったら、会議サーバに接続を切り替え、同期した共有画面を見たり、遠隔操作を行ったりしながら、会議に参加することが可能となる。
（効果）
以上の説明から明らかなように、送信パケットに対して、パケットを正常に受信したことを応答するＡＣＫパケットを返信する必要のある、データストリーム型の通信方式であるＴＣＰパケットによる通信だけでなく、ＡＣＫの返信の必要がないため高速であるが、信頼性や、パケットの受信順序を保証しないデータグラム型の通信方式であるＵＤＰパケットを用いて、画面データの送信を行う、高速な画面共有を行う、画面共有サーバと画面共有クライアント間の通信が可能となる。
以上の説明から明らかなように、送信パケットに対して、パケットを正常に受信したことを応答するＡＣＫパケットを返信する必要のある、データストリーム型の通信方式であるＴＣＰパケットによる通信だけでなく、ＡＣＫの返信の必要がないため高速であるが、信頼性や、パケットの受信順序を保証しないデータグラム型の通信方式であるＵＤＰパケットを用いて、画面データの送信を行う、高速な画面共有を行う、画面共有サーバと画面共有クライアント間の通信が可能となる。
また、ＵＤＰマルチキャスト，またはＵＤＰブロードキャストパケットで、画面データを同報パケットにより、一度に複数のクライアントに送信することにより、画面共有サーバーの画面データを複数のクライアントに対して、高速に送信する、ネットワーク利用効率の高い通信が可能となる。
また、パケットタイプを手動または自動で動的に選択することにより、臨機応変に適したパケットタイプで画面データの通信を行うことにより、通信速度の効率を向上させることが可能となる。
また、クライアントの利用者が、画面共有によってサーバの画面データを共有する際に感じる、サーバとのタイムラグによって生じる感覚的不満を緩和することも可能となる。
また、あまり重要でない画面データや、ＴＣＰを用いて確実に送信するまでもない良好なネットワーククライアント環境のクライアントに対して、ＵＤＰパケットを利用して画面データを送信することにより、ＴＣＰパケットを利用する必要のあるクライアントの利用者が、あるいはＴＣＰパケットを用いて、確実に送信する必要のある画面データの転送速度を相対的に速くすることが可能となる。
また、クライアントの利用者が、画面共有によってサーバの画面データを共有する際に感じる、サーバとのタイムラグによって生じる感覚的不満を緩和することも可能となる。
また、あまり重要でない画面データや、ＴＣＰを用いて確実に送信するまでもない良好なネットワーククライアント環境のクライアントに対して、ＵＤＰパケットを利用して画面データを送信することにより、ＴＣＰパケットを利用する必要のあるクライアントの利用者が、あるいはＴＣＰパケットを用いて、確実に送信する必要のある画面データの転送速度を相対的に速くすることが可能となる。
また、予め、アプリケーション毎に、そのアプリケーションの画面領域が更新されたとき、画面データをＴＣＰパケットで送信するか、ＵＤＰパケットで送信するかを指定する機能により、画面データの送信パケットの型を動的に選択して画面共有を行うことにより、クライアントに表示される共有された画面データが、アプリケーションの特性適したものとすることが可能となる。
また、ＴＣＰパケットで送信するよう登録されたアプリケーションの画面データの転送速度を相対的に速くすることが可能となる。
また、映像データ再生アプリケーションなどの、ＴＣＰパケットによる確実性よりも、画面更新速度を優先するアプリケーションの画面データをＵＤＰパケットにより送信し、クライアントの画面で、画面共有のコマ落ちを減少させることも可能となる。
また、ＴＣＰパケットで送信するよう登録されたアプリケーションの画面データの転送速度を相対的に速くすることが可能となる。
また、映像データ再生アプリケーションなどの、ＴＣＰパケットによる確実性よりも、画面更新速度を優先するアプリケーションの画面データをＵＤＰパケットにより送信し、クライアントの画面で、画面共有のコマ落ちを減少させることも可能となる。
また、最前面にあるアプリケーションウィンドウをＴＣＰパケットで送信し、それ以外の背面のウィンドウまたはデスクトップ領域をＵＤＰパケットで送信することにより、その時点で重要なデータを表示していることの多い、最前面ウィンドウのデータを確実に送信し、それ以外のウィンドウ領域あるいはデスクトップ領域の、あまり重要でないデータは、確実性よりも、速度のみを優先して送信することにより、通信効率を向上することが可能となる。また、ＴＣＰパケットで送信するよう登録された最前面にあるウィンドウの画面データの転送速度を相対的に速くすることが可能となる。
また、アクティブなアプリケーションウィンドウをＴＣＰパケットで送信し、それ以外の非アクティブウィンドウまたはデスクトップ領域をＵＤＰパケットで送信することにより、その時点で重要なデータを表示していることの多い、アクティブウィンドウのデータを確実に送信し、それ以外の非アクティブウィンドウ領域あるいはデスクトップ領域の、あまり重要でないデータは、確実性よりも速度のみを優先して送信することにより、通信効率を向上することが可能となる。また、ＴＣＰパケットで送信するよう登録されたアクティブウィンドウの画面データの転送速度を相対的に速くすることが可能となる。
また、画面共有サーバで、アプリケーションによって表示する文書単位で、その文書を表示するアプリケーションの画面領域が更新されたとき、画面データをＴＣＰパケットで送信するか、ＵＤＰパケットで送信するかを指定する機能により、画面データの送信パケットの型を動的に選択して画面共有を行うことにより、クライアントに表示される共有された画面データが、アプリケーションの特性適したものとすることが可能となる。
また、文書の重要度により、確実性を優先するか、通信速度を優先するかを選択することが可能となり、通信効率を向上することが可能となる。
また、ＴＣＰパケットで送信するよう登録された文書を開いているアプリケーションウィンドウの画面データの転送速度を相対的に速くすることが可能となる。
また、文書の重要度により、確実性を優先するか、通信速度を優先するかを選択することが可能となり、通信効率を向上することが可能となる。
また、ＴＣＰパケットで送信するよう登録された文書を開いているアプリケーションウィンドウの画面データの転送速度を相対的に速くすることが可能となる。
また、画面共有サーバで、デスクトップ領域の内、ある画面領域の画面データをＴＣＰパケットで送信するか、ＵＤＰパケットで送信するかを指定する機能により、確実に画面共有を行いたい領域は画面データをＴＣＰパケットで送信し、速度を優先する画面データが表示される画面領域の画面データはＵＤＰパケットで送信することにより、通信効率を向上することが可能となる。また、ＴＣＰパケットで送信するよう登録された領域の画面データの転送速度を相対的に速くすることが可能となる。
また、ユーザの指示により、画面データをＴＣＰパケットで送信するか、ＵＤＰパケットで送信するかを切り替える手段を有することにより、ユーザが現在共有している画面データを送信するのに、異なるパケットタイプで通信した方がよいと判断した場合等に、パケットタイプで切り替えることを可能にすることにより、状況に応じて適した画面データ送信を行うことが可能な通信方式を提供することが可能となる。
また、画面共有サーバが、自身に接続しているクライアント数が、ある台数より少ない場合は、ＴＣＰパケットで画面データを送信し、ある台数より多い場合は、ＵＤＰパケットで画面データを送信するよう、自動的に切り替える機能を有することにより、通信効率の高い画面共有を行う通信方式を提供することが可能となる。
また、通信エラーが多く、通信品質の悪い無線通信手段を利用しているクライアントに対しては、自動的にＴＣＰパケットで画面データを送信することにより、データの確実性を保証するし、一方、通信エラーが少なく、通信品質の比較的高い有線通信手段のみでサーバと通信しているクライアントに対してはＵＤＰパケットで画面データを送信するよう選択し、速度及び通信効率を優先することが可能となる。
また、有線ＬＡＮで接続しているクライアントに対して、ＵＤＰパケットを使用して画面データを送信することにより、ＴＣＰパケットで送信するよう登録された無線ＬＡＮを介して接続しているクライアントへの画面データの転送速度を相対的に速くすることが可能となる。
また、有線ＬＡＮで接続しているクライアントに対して、ＵＤＰパケットを使用して画面データを送信することにより、ＴＣＰパケットで送信するよう登録された無線ＬＡＮを介して接続しているクライアントへの画面データの転送速度を相対的に速くすることが可能となる。
また、ＬＡＮで接続しているクライアントに対してはＵＤＰを、ＷＡＮによりＬＡＮの外部のネットワークから接続しているクライアントに対してはＴＣＰを選択し、ネットワーク環境に適した画面共有を行う通信方式を自動的に選択する通信を行うことが可能となる。また、ＬＡＮで接続されたクライアントに対して、ＵＤＰパケットを使用して画面データを送信することにより、ＴＣＰパケットで送信するよう登録されたＷＡＮを介して接続しているクライアントへの画面データの転送速度を相対的に速くすることが可能となる。
また、画面共有サーバにおいて、送信すべき画面更新データ残量、または画面データの送信レートが一定値より多い場合、ＵＤＰパケットで送信し、少ない場合はＴＣＰパケットで確実に送信するよう自動的に切り替えることにより、クライアントの利用者のストレスが少ない画面共有システムにおける通信方式を提供することが可能となる。
また、サーバ／クライアント間の通信速度が一定値より遅い場合、ＵＤＰパケットで送信し、高速である場合は、ＴＣＰパケットで確実に送信するよう自動的に切り替えることにより、ネットワーク環境に応じ、クライアントの利用者のストレスが少ない画面共有システムにおける通信を行うことが可能となる。また、通信速度の速いクライアントに対して、ＵＤＰパケットを使用して画面データを送信することにより、ＴＣＰパケットで送信するよう登録された通信速度の遅いクライアントへの画面データの転送速度を相対的に速くすることが可能となる。
また、画面共有サーバがクライアントとの間のネットワークのＭＴＵを測定し、ＭＴＵが一定値より小さい場合、ＵＤＰパケットで送信し、大きい場合は、ＴＣＰパケットで確実に送信するよう自動的に切り替えることにより、ネットワーク環境に応じ、クライアントの利用者のストレスが少ない画面共有システムにおける通信を行うことが可能となる。
また、画面共有サーバがクライアントとの間のＱｏＳを測定し、ＱｏＳが一定値より大きい場合にはＵＤＰパケットで送信し、小さい場合にはＴＣＰパケットで確実に送信するよう自動的に切り替えることにより、ネットワーク環境に応じ、クライアントの利用者のストレスが少ない画面共有システムにおける通信方式を行うことが可能となる。また、通信品質の良いクライアントに対して、ＵＤＰパケットを使用して画面データを送信することにより、ＴＣＰパケットで送信するよう登録された通信品質の悪いクライアントへの画面データの転送速度を相対的に速くすることが可能となる。
また、クライアントの優先権に応じて、画面データの送信に用いるパケットのタイプをＴＣＰとＵＤＰで切り替える機能を有することにより、優先度の高いクライアントにはＴＣＰパケットにより確実に画面データを送信し、他の優先度の低いクライアントにはＵＤＰパケットで画面データを送信することにより、通信効率を向上することが可能となる。また、優先度の低いクライアントに対して、ＵＤＰパケットを使用して画面データを送信することにより、ＴＣＰパケットで送信するよう登録された優先度の高いクライアントへの画面データの転送速度を相対的に速くすることが可能となる。
また、クライアントからのリモート操作を行っている途中であるかどうかを判断し、画面データの送信に用いるパケットのタイプをＴＣＰとＵＤＰで切り替えることにより、リモート操作中のクライアントには、ＴＣＰパケットにより、確実に画面データを送信し、リモート操作を行っていないクライアントには、ＵＤＰパケットで画面データを送信することにより、通信効率を向上することが可能となる。また、リモート操作を行っていないクライアントに対して、ＵＤＰパケットを使用して画面データを送信することにより、ＴＣＰパケットで送信するよう指示されたリモート操作を行っているクライアントへの画面データの転送速度を相対的に速くすることが可能となる。
また、ＯＳがフォント描画命令を行っている領域であるか、そうでない領域であるかを判断し、画面データの送信に用いるパケットのタイプをＴＣＰとＵＤＰで切り替えることにより、確実性が要求される文字領域の画面データはＴＣＰパケットで送信し、それ以外の領域の画面データはＵＤＰパケットで送信することにより、文字部分を確実にクライアントで送信すると共に、通信速度を向上させ、相対的に文字部分の画面データの転送速度を向上させることが可能となる。また、文字以外のデータを描画する領域に対して、ＵＤＰパケットを使用して画面データを送信することにより、ＴＣＰパケットで送信するよう登録された文字領域の画面データの転送速度を相対的に速くすることが可能となる。
また、画面共有サーバのＣＰＵ負荷に応じて、画面データの送信に用いるパケットのタイプをＴＣＰとＵＤＰで切り替えることにより、サーバの処理量が多い場合は、その処理により、画面更新データを生成し、送信する処理が遅くなることを考慮して、ＵＤＰパケットで画面データを送信することにより、サーバの負荷量が大きい場合の画面データの送信速度の低下を防止することが可能となる。
また、中継情報機器が、画面共有サーバとクライアントの間に介在し、画面共有サーバからＴＣＰパケットで受信した画面データを、ＵＤＰパケットに変換して、クライアントに送信する機能により、多数のクライアントがサーバに直接接続した場合に生じるサーバの負荷を低減することが可能となる。また、ＵＤＰパケットで送信する機能を有することにより、画面データの転送速度を向上させることが可能となる。
また、画面共有サーバからＴＣＰパケットで受信した画面データを、ＵＤＰマルチキャストまたはＵＤＰブロードキャストを利用した同報通信により、複数のクライアントが中継情報機器に接続した場合に、クライアント数の増加による、画面データの転送速度の低下を防ぐことが可能となる。
また、更に、受信した画面共有データを記録することにより、非同期でサーバの画面の様子を閲覧することが可能となる。また、記録した画面データをＵＤＰパケットによって送信することにより、通信効率を向上させ、閲覧するクライアントに、不自然さを感じさせない高速な画面再生を実現することが可能となる。更に、マルチキャストまたはブロードキャストを利用した同報通信により、複数のクライアントに対して、クライアント数の増加による、画面再生速度の低下を防ぐことが可能となる。
また、送信パケットに対して、パケットを正常に受信したことを応答するＡＣＫパケットを返信する必要のある、データストリーム型の通信方式であるＴＣＰパケットによる通信だけでなく、ＡＣＫの返信の必要がないため高速であるが、信頼性や、パケットの受信順序を保証しないデータグラム型の通信方式であるＵＤＰパケットを用いて、画面データの送信を行う、高速な画面共有を行うことが可能である電子会議システムを提供することが可能となる。
また、中継機器（プロキシ）が、画面共有サーバとクライアントの間に介在し、画面共有サーバからＴＣＰパケットで受信した画面データを、ＵＤＰパケットに変換して、クライアントに送信することにより、多数のクライアントがサーバーに直接接続した場合に生じるサーバーの負荷を低減することが可能な電子会議システムを提供することが可能となる。
１ サーバ（画面共有サーバ）
２ クライアント
３ 中継機器（プロキシ）
１０ ＩＰネットワーク
１１ ＴＣＰ共有アプリケーションウィンドウ
１２ ＵＤＰ共有アプリケーションウィンドウ
１３ 最前面ウィンドウ
１４ 背面ウィンドウ
１５ アクティブウィンドウ
１６ 非アクティブウィンドウ
１７ ユーザ指定文書ウィンドウ
１８ 非ユーザ指定文書ウィンドウ
２ クライアント
３ 中継機器（プロキシ）
１０ ＩＰネットワーク
１１ ＴＣＰ共有アプリケーションウィンドウ
１２ ＵＤＰ共有アプリケーションウィンドウ
１３ 最前面ウィンドウ
１４ 背面ウィンドウ
１５ アクティブウィンドウ
１６ 非アクティブウィンドウ
１７ ユーザ指定文書ウィンドウ
１８ 非ユーザ指定文書ウィンドウ
Claims (8)
- サーバとして機能する情報機器と、
前記サーバのクライアントとして機能する情報機器を構成要素とし、
前記サーバは、その表示画面の少なくとも一部に関するデータを、前記クライアントにＩＰプロトコルを用いて通信を行うネットワークを介して送信する手段と、送信する画面領域のデータの種類または表示条件、クライアントとの通信環境、あるいはユーザが与える指示の何れかによって、前記サーバは前記画面データを送信する場合に、送信する画面データの少なくとも一部を、ＴＣＰパケットを用いて送信するか、もしくはＵＤＰパケットを用いて送信するかを切り替えて送信する手段とを有し、
前記クライアントは、前記サーバから受信した画面データを表示装置に表示することにより、前記サーバの表示画面を共有する手段を有するネットワークシステムにおけるデータ通信方式であって、
前記サーバは、接続クライアントの優先権および共有画面上での遠隔制御の制御権を管理する手段をさらに有し、
前記優先権の与えられているクライアントに対しては、ＴＣＰパケットで画面データを送信し、
前記優先権が与えられていないクライアントに対しては、前記優先権の与えられているクライアントに対するＴＣＰパケットの送信後に、ＵＤＰパケットで画面データを送信し、
前記制御権を所持しているクライアントに対しては、ＴＣＰパケットで画面データを送信し、
前記制御権のないクライアントクライアントに対しては、前記制御権の与えられているクライアントに対するＴＣＰパケットの送信後に、ＵＤＰパケットで画面データを送信することを特徴するデータ通信方式。 - 前記サーバは、ＵＤＰマルチキャストまたはＵＤＰブロードキャストパケットを用いて複数の前記クライアントに対して、画面データを同報通信方式で送信する手段を有することを特徴とする請求項１記載のデータ通信方式。
- 会議サーバとして機能する情報機器と、
前記会議サーバの会議クライアントとして機能する情報機器を構成要素とし、
前記会議サーバは、その表示画面の少なくとも一部に関するデータを、前記会議クライアントにＩＰプロトコルを用いて通信を行うネットワークを介して送信する手段と、送信する画面領域のデータの種類または表示条件、会議クライアントとの通信環境、あるいはユーザが与える指示の何れかによって、前記会議サーバは前記画面データを送信する場合に、送信する画面データの少なくとも一部を、ＴＣＰパケットを用いて送信するか、もしくはＵＤＰパケットを用いて送信するかを切り替えて送信する手段とを有し、
前記会議クライアントは、前記会議サーバから受信した画面データを表示装置に表示することにより、前記会議サーバの表示画面を共有する手段を有する電子会議システムであって、
前記サーバは、接続クライアントの優先権および共有画面上での遠隔制御の制御権を管理する手段を有し、
前記優先権の与えられているクライアントに対しては、ＴＣＰパケットで画面データを送信し、
前記優先権が与えられていないクライアントに対しては、前記優先権の与えられているクライアントに対するＴＣＰパケットの送信後に、ＵＤＰパケットで画面データを送信し、
前記制御権を所持しているクライアントに対しては、ＴＣＰパケットで画面データを送信し、
前記制御権のないクライアントクライアントに対しては、前記制御権の与えられているクライアントに対するＴＣＰパケットの送信後に、ＵＤＰパケットで画面データを送信することを特徴する電子会議システム。 - 前記サーバは、ＵＤＰマルチキャストまたはＵＤＰブロードキャストパケットを用いて複数の前記クライアントに対して、画面データを同報通信方式で送信する手段を有することを特徴とする請求項３記載の電子会議システム。
- サーバとして機能する情報機器と、前記サーバのクライアントとして機能する情報機器を構成要素とするネットワークシステムにおけるデータ通信方法であって、
前記サーバにおいて、その表示画面の少なくとも一部に関するデータを、前記クライアントにＩＰプロトコルを用いて通信を行うネットワークを介して送信する工程と、
前記クライアントにおいて、前記サーバから受信した画面データを表示装置に表示することにより、前記サーバの表示画面を共有する工程とを有し、
送信する画面領域のデータの種類または表示条件、クライアントとの通信環境、あるいはユーザが与える指示の何れかによって、前記サーバは前記画面データを送信する場合に、送信する画面データの少なくとも一部を、ＴＣＰパケットを用いて送信するか、もしくはＵＤＰパケットを用いて送信するかを切り替えて送信する工程を有し、
前記サーバは、自ら管理する接続クライアントの優先権および共有画面上での遠隔制御の制御権に応じて、
前記優先権の与えられているクライアントに対しては、ＴＣＰパケットで画面データを送信し、
前記優先権が与えられていないクライアントに対しては、前記優先権の与えられているクライアントに対するＴＣＰパケットの送信後に、ＵＤＰパケットで画面データを送信し、
前記制御権を所持しているクライアントに対しては、ＴＣＰパケットで画面データを送信し、
前記制御権のないクライアントクライアントに対しては、前記制御権の与えられているクライアントに対するＴＣＰパケットの送信後に、ＵＤＰパケットで画面データを送信することを特徴するデータ通信方法。 - 前記サーバは、ＵＤＰマルチキャストまたはＵＤＰブロードキャストパケットを用いて複数の前記クライアントに対して、画面データを同報通信方式で送信する手段を有することを特徴とする請求項５記載のデータ通信方法。
- 請求項５または６に記載のデータ通信方法をコンピュータに実行させるためのデータ通信プログラム。
- 請求項５または６に記載のデータ通信方法をコンピュータに実行させるためのデータ通信プログラムを格納したコンピュータが読み取り可能な記憶媒体。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2004167650A JP4222561B2 (ja) | 2004-06-04 | 2004-06-04 | データ通信方式、電子会議システム、データ通信方法、データ通信プログラム及び記憶媒体 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2004167650A JP4222561B2 (ja) | 2004-06-04 | 2004-06-04 | データ通信方式、電子会議システム、データ通信方法、データ通信プログラム及び記憶媒体 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2005348262A JP2005348262A (ja) | 2005-12-15 |
| JP4222561B2 true JP4222561B2 (ja) | 2009-02-12 |
Family
ID=35500185
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2004167650A Expired - Fee Related JP4222561B2 (ja) | 2004-06-04 | 2004-06-04 | データ通信方式、電子会議システム、データ通信方法、データ通信プログラム及び記憶媒体 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4222561B2 (ja) |
Families Citing this family (38)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8387099B2 (en) | 2002-12-10 | 2013-02-26 | Ol2, Inc. | System for acceleration of web page delivery |
| US8495678B2 (en) | 2002-12-10 | 2013-07-23 | Ol2, Inc. | System for reporting recorded video preceding system failures |
| US8840475B2 (en) | 2002-12-10 | 2014-09-23 | Ol2, Inc. | Method for user session transitioning among streaming interactive video servers |
| US8893207B2 (en) * | 2002-12-10 | 2014-11-18 | Ol2, Inc. | System and method for compressing streaming interactive video |
| US8661496B2 (en) | 2002-12-10 | 2014-02-25 | Ol2, Inc. | System for combining a plurality of views of real-time streaming interactive video |
| US9003461B2 (en) * | 2002-12-10 | 2015-04-07 | Ol2, Inc. | Streaming interactive video integrated with recorded video segments |
| US9032465B2 (en) * | 2002-12-10 | 2015-05-12 | Ol2, Inc. | Method for multicasting views of real-time streaming interactive video |
| US20090118019A1 (en) | 2002-12-10 | 2009-05-07 | Onlive, Inc. | System for streaming databases serving real-time applications used through streaming interactive video |
| US8549574B2 (en) * | 2002-12-10 | 2013-10-01 | Ol2, Inc. | Method of combining linear content and interactive content compressed together as streaming interactive video |
| US9108107B2 (en) | 2002-12-10 | 2015-08-18 | Sony Computer Entertainment America Llc | Hosting and broadcasting virtual events using streaming interactive video |
| US8949922B2 (en) | 2002-12-10 | 2015-02-03 | Ol2, Inc. | System for collaborative conferencing using streaming interactive video |
| US8468575B2 (en) | 2002-12-10 | 2013-06-18 | Ol2, Inc. | System for recursive recombination of streaming interactive video |
| US8832772B2 (en) * | 2002-12-10 | 2014-09-09 | Ol2, Inc. | System for combining recorded application state with application streaming interactive video output |
| JP4754416B2 (ja) * | 2006-06-26 | 2011-08-24 | 株式会社トヨタＩｔ開発センター | 無線通信装置、無線通信方法およびプログラム |
| US8472885B2 (en) | 2006-10-17 | 2013-06-25 | Pioneer Corporation | Information presenting apparatus, information presenting method, and the like, for performing communication with a plurality of devices |
| JP5130891B2 (ja) * | 2007-12-10 | 2013-01-30 | 富士通株式会社 | データ送信装置及びデータ送信方法 |
| JP2010034758A (ja) | 2008-07-28 | 2010-02-12 | Funai Electric Co Ltd | 無線通信システム、無線機器、サーバ |
| DE112008004245B4 (de) | 2008-12-25 | 2016-12-01 | Mitsubishi Electric Corporation | Kommunikationsverwaltungsvorrichtung, Kommunikationsvorrichtung und Kommunikationsverfahren |
| JP4599447B2 (ja) | 2009-03-18 | 2010-12-15 | 株式会社東芝 | 電話システム、サーバおよび端末デバイス |
| JP5582282B2 (ja) * | 2009-04-24 | 2014-09-03 | 日本電気株式会社 | サーバ端末、画像処理システム、画像処理方法およびプログラム |
| WO2012056783A1 (ja) * | 2010-10-25 | 2012-05-03 | 日本電気株式会社 | コンテンツ共有システム、携帯端末、プロトコル切換方法およびプログラム |
| JP2011035939A (ja) * | 2010-10-29 | 2011-02-17 | Toshiba Corp | 無線通信装置及び無線通信方法 |
| WO2012114371A1 (ja) * | 2011-02-23 | 2012-08-30 | 株式会社日立製作所 | メッセージ送信装置及びメッセージ送信方法 |
| JP5732374B2 (ja) * | 2011-11-14 | 2015-06-10 | 西日本電信電話株式会社 | 情報処理システムおよび情報処理方法 |
| US20130151624A1 (en) | 2011-12-12 | 2013-06-13 | International Business Machines Corporation | Context-Sensitive Collaboration Channels |
| US9852432B2 (en) | 2011-12-12 | 2017-12-26 | International Business Machines Corporation | Customizing a presentation based on preferences of an audience |
| US9588652B2 (en) | 2011-12-12 | 2017-03-07 | International Business Machines Corporation | Providing feedback for screen sharing |
| US9124657B2 (en) | 2011-12-14 | 2015-09-01 | International Business Machines Corporation | Dynamic screen sharing for optimal performance |
| US9141264B2 (en) | 2011-12-14 | 2015-09-22 | International Business Machines Corporation | Variable refresh rates for portions of shared screens |
| JP5726720B2 (ja) * | 2011-12-19 | 2015-06-03 | 日本電信電話株式会社 | Ｗｅｂ情報取得方法および先読み代理サーバ |
| JP5613710B2 (ja) * | 2012-03-21 | 2014-10-29 | 株式会社東芝 | サーバ端末、画面転送システムおよび画面転送方法 |
| WO2014043420A1 (en) * | 2012-09-12 | 2014-03-20 | Trudeau, Matthew | Transmission latency leveling apparatuses, methods and systems |
| CA2919966A1 (en) * | 2013-08-06 | 2015-02-12 | Ricoh Company, Ltd. | Information processing apparatus and determination result providing method |
| KR101769133B1 (ko) * | 2015-11-30 | 2017-08-17 | 엘아이지넥스원 주식회사 | Tcp/ udp를 적응적으로 선택하는 전자기기 및 이의 패킷 송수신 방법 |
| JP6344370B2 (ja) * | 2015-11-30 | 2018-06-20 | ブラザー工業株式会社 | 通信システム、サーバ装置、クライアント装置、及びプログラム |
| WO2019172943A1 (en) | 2018-03-08 | 2019-09-12 | Google Llc | Mitigation of client device latency in rendering of remotely generated automated assistant content |
| JP2019191962A (ja) * | 2018-04-25 | 2019-10-31 | 富士通株式会社 | 画面送信プログラム、画面送信方法及び画面送受信システム |
| JP6873441B2 (ja) * | 2019-09-13 | 2021-05-19 | 株式会社 ゼネテック | 情報送信システム、情報送信方法、情報送信プログラム、サーバー、及び携帯端末 |
-
2004
- 2004-06-04 JP JP2004167650A patent/JP4222561B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2005348262A (ja) | 2005-12-15 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4222561B2 (ja) | データ通信方式、電子会議システム、データ通信方法、データ通信プログラム及び記憶媒体 | |
| US20190028673A1 (en) | Video messaging | |
| JP4467220B2 (ja) | 音声インスタント・メッセージング | |
| US8732236B2 (en) | Managing network communications between network nodes and stream transport protocol | |
| CN100587681C (zh) | 用于在相互通信的用户之间传递图像的系统和方法 | |
| TWI385967B (zh) | 智慧型交換器管理模組系統與方法 | |
| KR101596530B1 (ko) | 원격 세션에서의 멀티미디어 동작을 관리하는 시스템 및 방법 | |
| US7340531B2 (en) | Apparatus and method for data transfer | |
| JP4425577B2 (ja) | データを提示する方法 | |
| US8793384B2 (en) | Recovery of disconnected channels over a reliable protocol | |
| US20110087915A1 (en) | Hybrid reliable streaming protocol for peer-to-peer multicasting | |
| JP2014503141A (ja) | リモートパーティ間の通信のサードパーティ開始 | |
| US8068514B2 (en) | Efficient bandwidth utilization when streaming data over multiple network interfaces | |
| WO2023000894A1 (zh) | 一种数据传输方法、装置、服务器、存储介质及程序产品 | |
| US20110271002A1 (en) | Initializing network streaming over multiple physical interfaces | |
| EP1395000B1 (en) | A method of transmitting data streams dependent on the monitored state of the client application buffer | |
| US7349664B2 (en) | Communication system and method thereof | |
| CN114363351A (zh) | 一种代理连接抑制方法、网络架构及代理服务器 | |
| JP2005301913A (ja) | 通信システム及び情報処理端末、並びに通信方法 | |
| McKinley et al. | Composable proxy services to support collaboration on the mobile internet | |
| JP2007207013A (ja) | 情報処理装置、情報共有プログラム | |
| CN113411228B (zh) | 一种网络状况的确定方法及服务器 | |
| EP1575236A1 (en) | Connectivity confirmation method for network storage device and host computer | |
| JPH11249978A (ja) | データ転送方法および装置 | |
| Burleigh et al. | NASA ION (Interplanetary Overlay Network) Developer Course Materials |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20060925 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20080808 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080819 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20081020 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20081111 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20081114 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111128 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111128 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121128 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131128 Year of fee payment: 5 |
|
| LAPS | Cancellation because of no payment of annual fees |