(57)【要約】【課題】特別な装置を用いることなく、サーバとクライアントとの間の通信回線への負担を極力抑制し、安定した撮影画像データの取得を行うことが可能なデータ取得方法を提供する。【解決手段】同一サブネット２０のうちで、サーバ１に対する接続要求を最初に行ったクライアント２1は、サーバ１から経路制御モジュールを取得するとともに、サーバ１から撮影画像データを直接取得する。これに対し、同一サブネット２０のうちで、サーバ１に対して２番目以降に接続要求を行ったクライアント２nは、サーバ１から接続代行クライアント情報を取得し、その接続代行クライアント情報に基づいて、経路制御モジュールを実行したクライアント２1から撮影画像データを取得する。【選択図】図５
2009060252.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークに接続されたサーバにて収集された撮影画像データを、前記ネットワークに接続された複数のクライアントで取得するデータ取得方法であって、
前記複数のクライアントの少なくとも一部で構成されるクライアント群のうちで、前記サーバに対する接続要求を最初に行った特定クライアントが、前記サーバから経路制御モジュールを取得する第１ステップと、
前記クライアント群を構成するクライアントのうちで、前記サーバに対する接続要求を行った前記特定クライアント以外の非特定クライアントが、前記サーバから前記特定クライアントに関する情報を取得する第２ステップと、
前記特定クライアントが前記サーバから前記撮影画像データを取得する第３ステップと、
前記非特定クライアントが、前記情報に基づいて、前記経路制御モジュールを実行した特定クライアントから前記撮影画像データを取得する第４ステップと、を含むデータ取得方法。
【請求項２】
前記クライアント群の範囲は、クライアント間の通信環境に応じて設定されることを特徴とする請求項１に記載のデータ取得方法。
【請求項３】
前記クライアント群は、同一のサブネットに含まれる複数のクライアントにより構成されていることを特徴とする請求項２に記載のデータ取得方法。
【請求項４】
前記クライアント群は、複数のサブネットに含まれる複数のクライアントにより構成されていることを特徴とする請求項２に記載のデータ取得方法。
【請求項５】
前記複数のクライアントは、前記経路制御モジュールを取得可能な第１の種類のクライアント、及び前記経路制御モジュールを取得不可能な第２の種類のクライアントに分けられており、
前記第１ステップでは、前記クライアント群のうちで最初に接続要求を行ったクライアントが、前記第２の種類のクライアントであった場合に、前記接続要求が無かったものとして、取り扱うことを特徴とする請求項１〜４のいずれか一項に記載のデータ取得方法。
【請求項６】
前記クライアント群が複数ある場合に、
前記第２ステップでは、前記複数のクライアント群のいずれかに属する非特定クライアントが、前記複数のクライアント群のそれぞれに属する特定クライアントの情報を取得し、
前記第４ステップでは、前記非特定クライアントが、前記複数のクライアント群のそれぞれに属する特定クライアントのうちで、前記非特定クライアントとの間の接続状況が最も良好な特定クライアントから、前記撮影画像データを取得することを特徴とする請求項１〜５のいずれか一項に記載のデータ取得方法。
【請求項７】
ネットワークに接続されたサーバにて収集された撮影画像データを、前記ネットワークに接続された複数のクライアントで取得するデータ取得方法であって、
前記複数のクライアントの少なくとも一部で構成されるクライアント群のうち、前記サーバに対する接続要求を最初に行った特定クライアントの有する経路制御モジュールの動作が、前記サーバにより許容される第１ステップと、
前記クライアント群を構成するクライアントのうちで、前記サーバに対する接続要求を行った前記特定クライアント以外の非特定クライアントが、前記サーバから前記特定クライアントに関する情報を取得する第２ステップと、
前記特定クライアントが前記サーバから前記撮影画像データを取得する第３ステップと、
前記非特定クライアントが、前記情報に基づいて、前記経路制御モジュールを実行した前記特定クライアントから前記撮影画像データを取得する第４ステップと、を含むデータ取得方法。
【請求項８】
ネットワークに接続されたサーバにて収集された撮影画像データを、前記ネットワークに接続された複数のクライアントで取得するデータ取得方法であって、
前記複数のクライアントのうち、前記サーバに対する接続要求を行った接続要求クライアントが、前記サーバから、前記サーバとの間でデータのやり取りを行っているクライアントのリストを取得する第１ステップと、
前記接続要求クライアントと前記サーバとの間の通信状況、及び前記接続要求クライアントと前記リストに掲載されているクライアントとの間の通信状況を取得し、前記接続要求クライアントとの間の通信状況が最も良好なサーバ又はクライアントを特定する第２ステップと、
前記接続要求クライアントが、前記特定されたサーバ又はクライアントから前記撮影画像データを取得する第３ステップと、を含むデータ取得方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はデータ取得方法に関し、特にネットワークに接続されたサーバにて収集された撮影画像データを、前記ネットワークに接続された複数のクライアントで取得するデータ取得方法に関する。
【背景技術】
【０００２】
従来より、ビデオカメラ及びプロジェクタが接続されているサーバ（例えばコンピュータ）と、ネットワークを介して当該サーバに接続される遠隔地のクライアント（例えばコンピュータ）とを備え、サーバ側に存在する診断対象物を、クライアント側で診断する遠隔診断システムが知られている（例えば、特許文献１参照）。
【０００３】
この遠隔診断システムでは、サーバは、サーバに接続されているビデオカメラにより撮影される対象物の撮影画像を、ネットワークを介してクライアントに送信するものであり、クライアントは、表示装置の表示画面に立体物を含む撮影画像を表示し、当該表示画面上にアノテーション画像（線、図形、文字）などが書き込まれると、当該アノテーション画像をネットワークを介してサーバに送信するものである。また、サーバは受信したアノテーション画像をプロジェクタに送信し、プロジェクタは受信したアノテーション画像を対象物を含む投影領域の適切な位置（これは、クライアントが、撮影画像の範囲内でアノテーション画像を書き込んだ位置に対応する）に投影する。
【０００４】
このような遠隔診断システムでは、例えば、サーバから配信される画像をユーザがクライアントを介して観察し、各クライアントのユーザ間でコミュニケーションを図るという運用が想定されている。しかるに、同時に接続しようとするクライアントが増えれば増えるほど回線に負担がかかるため、安定的な通信を行えなくなるという問題がある。特に、サーバが海外に配置された場合などにおいては、サーバからインターネットへ接続する接続回線が貧弱である場合もあることから、この問題がより一層顕在化するおそれがある。これに対し、最近においては、配信サーバを地理的に分散配置することで、回線の負荷分散を図るという技術が提案されている（例えば、特許文献２参照）。また、クライアント側からサーバ側に画像送信のリクエストが出されたときに、サーバ側プロキシが当該リクエストに対するレスポンスのフィンガープリント（ハッシュ値）を計算し、その値をクライアントに送信するとともに、クライアント側では、そのハッシュ値から対応するレスポンスを検索して取得するという技術も提案されている（例えば特許文献３参照）。
【０００５】
【特許文献１】特開２００５−３３７５６号公報
【特許文献２】特開２００３−２２３３７８号公報
【特許文献３】特開２００３−１０８４５５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかしながら、上記特許文献２及び特許文献３においては、配信サーバを地理的に隔離するなどの作業が必要になったり、あるいは、プロキシやキャッシュサーバなどの特別な設備が必要となったりするため、遠隔診断システムの運用までに費用と手間を要してしまう。
【０００７】
そこで本発明は上記の課題に鑑みてなされたものであり、特別な装置を用いることなく、サーバとクライアント群との間の通信回線への負担を極力抑制し、安定した撮影画像データの取得を行うことが可能なデータ取得方法を提供することを目的とする。
【課題を解決するための手段】
【０００８】
上記課題を解決するために、本発明の第１のデータ取得方法は、ネットワークに接続されたサーバにて収集された撮影画像データを、前記ネットワークに接続された複数のクライアントで取得するための方法であり、前記複数のクライアントの少なくとも一部で構成されるクライアント群のうちで、前記サーバに対する接続要求を最初に行った特定クライアントが、前記サーバから経路制御モジュールを取得する第１ステップと、前記クライアント群を構成するクライアントのうちで、前記サーバに対する接続要求を行った前記特定クライアント以外の非特定クライアントが、前記サーバから前記特定クライアントに関する情報を取得する第２ステップと、前記特定クライアントが前記サーバから前記撮影画像データを取得する第３ステップと、前記非特定クライアントが、前記情報に基づいて、前記経路制御モジュールを実行した前記特定クライアントから前記撮影画像データを取得する第４ステップと、を含むことを特徴とする。
【０００９】
これによれば、クライアント群のうちで、サーバに対する接続要求を最初に行ったクライアント（特定クライアント）は、サーバから直接撮影画像データを取得するとともに、サーバから取得した経路制御モジュールを実行することで、いわゆる接続代行クライアントとして機能し、クライアント群のうちで、サーバに対する接続要求を２番目以降に行ったクライアント（非特定クライアント）は、サーバから特定クライアントに関する情報を取得し、撮影画像データを特定クライアントから取得する。このようにすることで、プロキシやキャッシュサーバなどの特別な装置を用いることなく、サーバとクライアント群との間の通信を、サーバ・特定クライアント間の通信のみとすることができるので、サーバとクライアント群の間の通信回線への負担を極力抑制し、安定した撮影画像データの取得を実現することが可能となる。
【００１０】
この場合において、前記クライアント群の範囲は、クライアント間の通信環境に応じて設定されることとすることができる。かかる場合には、サブネットなどのネットワーク構成などにとらわれること無く、クライアント群の範囲を設定することで、効率的な撮影画像データの取得を実現することができる。
【００１１】
この場合において、前記クライアント群は、同一のサブネットに含まれる複数のクライアントにより構成されていることとしても良いし、前記クライアント群は、複数のサブネットに含まれる複数のクライアントにより構成されていることとしても良い。
【００１２】
本発明の第１のデータ取得方法では、前記複数のクライアントは、前記経路制御モジュールを取得可能な第１の種類のクライアント、及び前記経路制御モジュールを取得不可能な第２の種類のクライアントに分けられており、前記第１ステップでは、前記クライアント群のうちで最初に接続要求を行ったクライアントが、前記第２の種類のクライアントであった場合に、前記接続要求が無かったものとして、取り扱うこととすることができる。かかる場合には、通信環境が比較的悪いなど、接続代行クライアントに不適なクライアントが、接続代行クライアントとなるのを防止することができるので、各クライアントによる撮影画像データの取得を、より安定した状態で行うことが可能となる。
【００１３】
また、本発明の第１のデータ取得方法では、前記クライアント群が複数ある場合に、前記第２ステップでは、前記複数のクライアント群のいずれかに属する非特定クライアントが、前記複数のクライアント群のそれぞれに属する特定クライアントの情報を取得し、前記第４ステップでは、前記非特定クライアントが、前記複数のクライアント群のそれぞれに属する特定クライアントのうちで、前記非特定クライアントとの間の接続状況が最も良好な特定クライアントから、前記撮影画像データを取得することとすることができる。かかる場合には、非特定クライアントは、複数のクライアント群に属する特定クライアントのうちから、最も効率的に通信を行うことが可能な特定クライアントを選択して、その特定クライアントから撮影画像データを取得することができるので、より安定した撮影画像データの取得を実現することが可能となる。
【００１４】
本発明の第２のデータ取得方法は、ネットワークに接続されたサーバにて収集された撮影画像データを、前記ネットワークに接続された複数のクライアントで取得する方法であり、前記複数のクライアントの少なくとも一部で構成されるクライアント群のうち、前記サーバに対する接続要求を最初に行った特定クライアントの有する経路制御モジュールの動作が、前記サーバにより許容される第１ステップと、前記クライアント群を構成するクライアントのうちで、前記サーバに対する接続要求を行った前記特定クライアント以外の非特定クライアントが、前記サーバから前記特定クライアントに関する情報を取得する第２ステップと、前記特定クライアントが前記サーバから前記撮影画像データを取得する第３ステップと、前記非特定クライアントが、前記情報に基づいて、前記経路制御モジュールを実行した前記特定クライアントから前記撮影画像データを取得する第４ステップと、を含むことを特徴とする。
【００１５】
これによれば、クライアント群のうちで、サーバに対する接続要求を最初に行ったクライアント（特定クライアント）は、サーバから直接撮影画像データを取得するとともに、サーバによって動作が許容された経路制御モジュールを実行することで、いわゆる接続代行クライアントとして機能し、クライアント群のうちで、サーバに対する接続要求を２番目以降に行ったクライアント（非特定クライアント）は、サーバから特定クライアントに関する情報を取得し、撮影画像データを特定クライアントから取得する。このようにすることで、プロキシやキャッシュサーバなどの特別な装置を用いることなく、サーバとクライアント群との間の通信を、サーバ・特定クライアント間の通信のみとすることができるので、サーバとクライアント群の間の通信回線への負担を極力抑制し、安定した撮影画像データの取得を実現することが可能となる。
【００１６】
本発明の第３のデータ取得方法は、ネットワークに接続されたサーバにて収集された撮影画像データを、前記ネットワークに接続された複数のクライアントで取得する方法であり、前記複数のクライアントのうち、前記サーバに対する接続要求を行った接続要求クライアントが、前記サーバから、前記サーバとの間でデータのやり取りを行っているクライアントのリストを取得する第１ステップと、前記接続要求クライアントと前記サーバとの間の通信状況、及び前記接続要求クライアントと前記リストに掲載されているクライアントとの間の通信状況を取得し、前記接続要求クライアントとの間の通信状況が最も良好なサーバ又はクライアントを特定する第２ステップと、前記接続要求クライアントが、前記特定されたサーバ又はクライアントから前記撮影画像データを取得する第３ステップと、を含むことを特徴とする。
【００１７】
これによれば、接続要求クライアントが、サーバから、クライアントのリストを取得し、リストに掲載されているクライアントとの間の通信状況、及びサーバとの間の通信状況のうち、最も通信状況が良好なところから撮影画像データを取得するので、プロキシやキャッシュサーバなどの特別な装置を用いることなく、撮影画像データの取得を安定して行うことが可能となる。
【発明の効果】
【００１８】
本発明によれば、特別な装置を用いることなく、サーバとクライアント群との間の通信回線への負担を極力抑制し、安定した撮影画像データの取得を行うことが可能なデータ取得方法を提供することができる。
【発明を実施するための最良の形態】
【００１９】
以下、本発明の一実施形態について図１〜図７（ｂ）に基づいて詳細に説明する。
【００２０】
図１には、本実施形態の遠隔診断システム１００の構成が概略的に示されている。
【００２１】
図１の遠隔診断システム１００は、海外生産拠点に配置された、パーソナルコンピュータ（ＰＣ）１（以下、「サーバ１」と呼ぶ）を含むサーバシステム１０と、国内開発拠点に配置された、複数のクライアント２1、２2、…２nを含むサブネット２０と、国内関連会社内に配置された、複数のクライアント１２1、１２2、…１２nを含むサブネット３０と、を備えている。これらサーバシステム１０、サブネット２０、及びサブネット３０のそれぞれは、インターネット３に接続されている。
【００２２】
サーバシステム１０のサーバ１には、プロジェクタ４、ビデオカメラ５、及び拡大用カメラ６がそれぞれ接続されている。
【００２３】
プロジェクタ４は、サーバ１からの制御コマンドに基づいて、診断対象物７に対して、ハーフミラー８を介して単なる光線を照射したり、アノテーション画像（注釈画像）等を投影したりする。なお、アノテーション画像は、線、文字、記号、図形、色、フォント（書体）等のあらゆる態様の画像を含む。
【００２４】
ビデオカメラ５は、診断対象物７の反射画像をハーフミラー８を介して撮影し、撮影画像（俯瞰画像）をサーバ１に向けて出力する。拡大用カメラ６は、診断対象物７の一部を拡大した状態で撮影することが可能なパン・チルト・ズーム機能付きのビデオカメラであり、撮影した画像（拡大画像）をサーバ１に出力する。
【００２５】
サブネット２０の複数のクライアント２1、２2、…２nは、イントラネット２３に接続されている。また、サブネット３０の複数のクライアント１２1、１２2、…１２nは、イントラネット２３’に接続されている。これらクライアントそれぞれには、ディスプレイ（不図示）や、マウスなどの入力インタフェース（不図示）が接続されており、ディスプレイには、ビデオカメラ５で撮影された画像（以下、「俯瞰画像」とも呼ぶ）や、拡大用カメラ６で撮影された画像（以下、「拡大画像」とも呼ぶ）が表示される。
【００２６】
また、ユーザが、クライアントそれぞれに接続された入力インタフェースを介して、診断対象物７の画像上に図形等を記載すると、当該図形の情報がクライアントからサーバ１に出力されるようになっている。サーバ１では、当該図形の情報をプロジェクタ４の座標の情報に変換し、プロジェクタ４に出力する。プロジェクタ４は、当該変換された図形の情報に基づいて診断対象物７上に当該図形が投影する。
【００２７】
また、ユーザが、入力インタフェースを介して、俯瞰画像上の一部の領域を選択すると、その選択情報は、クライアントからサーバ１に向けて出力される。サーバ１では、当該選択情報に基づいて、拡大用カメラ６を制御して、選択された領域に該当する部分を撮影（接写）する。
【００２８】
次に、サーバ１の機能構成について、図２（ａ）に基づいて説明する。サーバ１は、図２（ａ）に示されるように、画像入力部４１と、経路制御モジュール格納部４２と、クライアント情報格納部４３と、画像出力部４４と、通信制御部４５と、制御部４６と、操作処理部４７とを備えている。
【００２９】
画像入力部４１は、ビデオカメラ５及び拡大用カメラ６から入力される画像信号をデジタルデータ化する。経路制御モジュール格納部４２は、クライアントに送信する経路制御モジュールを格納する。クライアント情報格納部４３は、サーバ１に接続中のクライアントの情報、又はサーバ１に過去に接続したクライアントの情報（例えば、ＩＰアドレスなど）を蓄積する。画像出力部４４は、操作処理部４７の指示に従って、プロジェクタ４を制御してアノテーション（図形）等を診断対象物７に描画する。通信制御部４５は、画像入力部４１でデジタルデータ化された画像データを圧縮処理して送信したり、クライアント側から送信されるカメラ操作情報を受信したりする。制御部４６は、サーバ１全体の動作を統括的に制御する。操作処理部４７は、通信制御部４５を介して、クライアント側のユーザからの指示や、サーバ１の近傍にいるユーザからの指示を受け、その操作指示を、制御部４６に通知する。
【００３０】
次に、各クライアントの機能構成について、図２（ｂ）に基づいて説明する。各クライアントは、図２（ｂ）に示されるように、画像表示部５１と、経路制御モジュール記憶部５２と、操作入力部５３と、通信制御部５４と、経路制御モジュール実行部５５と、操作処理部５６とを備えている。
【００３１】
画像表示部５１は、サーバ１から送信されてきた画像を、ディスプレイ（不図示）上に表示する。経路制御モジュール記憶部５２は、サーバ１から送信される経路制御モジュールを格納する。操作入力部５３は、ユーザにより入力インタフェース（不図示）を介して入力される操作情報を受け取るとともに、その操作情報を通信制御部５４に通知する。通信制御部５４は、サーバ１から送信されてくる画像データを受信したり、操作入力部５３から送られてくるユーザの操作情報をサーバ１側（操作処理部４７（図２（ａ）参照））に送信したりする。経路制御モジュール実行部５５は、経路制御モジュール記憶部５２に、経路制御モジュールが格納されている場合に、その経路制御モジュールを実行することにより、当該クライアントを接続代行クライアントとして機能させるものである。操作処理部５６は、操作入力部５３により受け取られた操作情報を処理して、通信制御部５４に対して出力する。
【００３２】
次に、本実施形態の遠隔診断システム１００における処理について、図３、図４のフローチャート及び図５（ａ）〜図７（ｂ）に基づいて説明する。なお、図３は、サーバ１の処理を示すフローチャートであり、図４は、クライアントが画像データの受信を開始するまでの処理を示すフローチャートである。
【００３３】
まず、サーバ１の処理について、図３のフローチャートに沿って説明する。なお、図３の処理は、基本的にはサーバ１の制御部４６による処理であるので、特に必要な場合を除き、処理の主体についての記載を省略するものとする。
【００３４】
まず、サーバ１では、図３のステップＳ１０において、クライアントのいずれかから接続要求があったか否かを判断する。この場合、例えば、図５（ａ）に示されるように、クライアント２1から接続要求があった段階で、ステップＳ１０の判断が肯定され、ステップＳ１２に移行する。なお、サーバ１では、クライアントから接続要求があった段階で、そのクライアント２1の情報（ＩＰアドレスなど）をクライアント情報格納部４３に格納しておく。
【００３５】
次のステップＳ１２では、サーバ１に、既に接続されているクライアントがあるか否かを判断する。ここでの判断が否定されると、ステップＳ１４に移行する。次のステップＳ１４では、接続要求元のクライアント（図５（ａ）では、クライアント２1）が経路制御モジュールを有しているか否かを判断する。ここでの判断が否定された場合には、ステップＳ１６において、経路制御モジュールを、経路制御モジュール格納部４２から取り出して、接続要求元のクライアントに送信し、その後、ステップＳ１８に移行する。なお、ステップＳ１４における判断が肯定された場合、すなわち、接続要求元のクライアントが経路制御モジュールを有していた場合には、ステップＳ１６を経ることなく、ステップＳ１８に移行する。
【００３６】
次のステップＳ１８では、ビデオカメラ５や拡大用カメラ６で撮影された画像を画像入力部４１でデジタルデータにし、そのデータの、通信制御部４５から、経路制御モジュールを有するクライアント（クライアント２1）に向けた送信を開始する。
【００３７】
その後、ステップＳ２４では、全処理が終了したか否かを判断するが、ここでの判断が否定されると、ステップＳ１０に戻る。
【００３８】
次いで、ステップＳ１０では、別のクライアント（例えば、図５（ｂ）に示されるサブネット２０内のクライアント２n）から、接続要求があったか否かを判断し、ここでの判断が肯定されると、ステップＳ１２に移行する。このステップＳ１２では、既にサーバ１に接続されているクライアントがあるか否かを判断するが、ここでは、既にサーバ１にクライアント２1が接続されているので、判断は肯定され、ステップＳ２０に移行する。
【００３９】
次のステップＳ２０では、接続済みのクライアントが同一サブネット上に存在するか否かを判断する。ここでは、クライアント２nとクライアント２1とは、同一のサブネット２０上に存在していることから、判断は肯定され、次のステップＳ２２に移行する。
【００４０】
次のステップＳ２２では、接続代行クライアント情報（同一サブネット上で、どのクライアントが、経路制御モジュールを有しているかを示す情報）を、クライアント情報格納部４３から読み出して、接続要求元のクライアント２nに送信する。
【００４１】
サーバ１では、その後も上記フローチャートを繰り返す。例えば、図６（ａ）に示されるように、サブネット３０内のクライアント１２nからの接続要求があった場合には、クライアント１２n（サブネット３０内のクライアントのうち、最初に接続要求をしたクライアント）に対して、経路制御モジュールを送信する(ステップＳ１６)。また、その後、図６（ｂ）に示されるように、サブネット３０内のクライアント１２1からの接続要求があった場合には、クライアント１２1に対して、接続代行クライアント情報を送信する。
【００４２】
このようにして、図３のフローチャートが繰り返された後、ステップＳ２４における判断が肯定された段階で、図３の全処理を終了する。
【００４３】
次に、各クライアントの処理について、図４のフローチャートに沿って説明する。まず、図５（ａ）における、クライアント２1の処理について、説明する。
【００４４】
まず、図４のステップＳ３０において、クライアント２1が、サーバ１に対して接続要求を出すと、次のステップＳ３２では、クライアント２1が経路制御モジュールを有しているか、すなわち、クライアント２1の経路制御モジュール記憶部５２内に経路制御モジュールが格納されているか否かを判断する。この段階では、まだクライアント２1は、経路制御モジュールを有していないので、判断は否定され、次のステップＳ３４に移行して、経路制御モジュールが送られてきたか否かを判断する。このステップＳ３４において、サーバ１からクライアント２1に対して、経路制御モジュールが送られてきた場合（前述した図３のステップＳ１６）には、ここでの判断が肯定され、ステップＳ３６に移行する。なお、ステップＳ３２において、クライアント２1が、既に経路制御モジュールを有していたような場合には、ステップＳ３４を経ることなく、ステップＳ３６に移行する。
【００４５】
次のステップＳ３６では、経路制御モジュール実行部５５が、経路制御モジュール記憶部５２内に格納されている経路制御モジュールを実行し、クライアント２1を制御代行クライアント化する。ここで、「制御代行クライアント化」とは、クライアント２1に、プロキシ（proxy）としての機能を持たせることを意味し、制御代行クライアント化したクライアント２1は、サーバ１から直接取得した撮影画像データを、他のクライアントに対して転送することができるようになる。なお、このように制御代行クライアント化したクライアントを、以下においては、単に「制御代行クライアント」とも呼ぶものとする。
【００４６】
次いで、ステップＳ３８では、サーバ１から送信開始された撮影画像データ（前述した図３のステップＳ１８で送信開始されたデータ）の受信を開始する。この状態が、図７（ａ）において、矢印Ａにて示されている。
【００４７】
その後は、ステップＳ４０において、他のクライアントからの接続要求があるまで待機する（なお、これ以降の処理（ステップＳ４２）については後述する）。
【００４８】
次に、図５（ａ）における、クライアント２nの処理について、図４に沿って説明する。
【００４９】
クライアント２nは、図４のステップＳ３０において、サーバ１に対して接続要求を出すと、次のステップＳ３２において、経路制御モジュールを有しているか否か、すなわち、経路制御モジュール記憶部５２内に経路制御モジュールが格納されているか否かを判断する。この場合、クライアント２nは、経路制御モジュールを有していないので、ここでの判断は否定され、次のステップＳ３４に移行して、サーバ１から経路制御モジュールが送られてきたか否かを判断する。この場合、クライアント２nはサブネット２０に含まれており、かつ、同一のサブネット２０に含まれるクライアント２1が既にサーバ１に接続されていることから、経路制御モジュールは送られてこない（図３のステップＳ１２、Ｓ２０参照）。したがって、このステップＳ３４における判断は否定され、次のステップＳ４４に移行する。
【００５０】
次のステップＳ４４では、サーバ１からクライアント２1に対して接続代行クライアント情報が送られてきたか否かを判断する。この場合、前述した図３のステップＳ２２においてサーバ１から送信された接続代行クライアント情報を、クライアント２1が受信した段階で、ステップＳ４４の判断が肯定され、ステップＳ４６に移行する。
【００５１】
次のステップＳ４６では、クライアント２nが、接続代行クライアント情報に基づいて、接続代行クライアント（クライアント２1）を特定し、その接続代行クライアント２1に対して、接続要求を出す。
【００５２】
一方、ステップＳ４０で待機中であった接続代行クライアント２1では、クライアント２nからの接続要求により、ステップＳ４０における判断が肯定されるので、ステップＳ４２に移行して、接続要求元のクライアント（クライアント２n）に対して、サーバ１から受信した撮影画像データの転送を行う。
【００５３】
これに対し、クライアント２nは、ステップＳ４６の接続要求の後、ステップＳ４８において、接続代行クライアント２1から転送されてくる撮影画像データの受信を開始する。この状態が、図７（ａ）において、矢印Ｂにて示されている。
【００５４】
その後は、各クライアントにおいて、画像受信の終了処理が行われるまで、画像受信を継続する。
【００５５】
なお、ステップＳ４４の判断が否定される場合、すなわち、サーバ１から接続代行クライアント情報が送られてこない場合には、通信エラーなどの何らかのエラーが発生していると考えられるので、ステップＳ５０において、クライアントに接続されているディスプレイ（不図示）等にエラーを表示した後、図４の処理を終了する。
【００５６】
なお、図６（ａ）、図６（ｂ）の場合も、上述した図５(ａ)、図５（ｂ）と同様の処理が実行されることにより、図７（ｂ）に示されるように、サーバ１とクライアント１２n間では、矢印Ｃで示されるような撮影画像データの送信が行われ、クライアント１２nとクライアント１２1との間では、矢印Ｄで示されるような撮影画像データの送信（転送）が行われる。
【００５７】
各クライアントでは、上記のようにして、受信した撮影画像データに基づく画像を、画像表示部５１を介して、ディスプレイ（不図示）に表示する。そして、各クライアントのユーザは、ディスプレイに表示された撮影画像（診断対象物７の画像）に基づいて、診断対象物７についてディスカッションを行ったり、診断対象物７上にアノテーション（図形など）を記入したりして、診断対象物７の遠隔診断を実行する。
【００５８】
以上、詳細に説明したように、本第１の実施形態によると、サブネット２０（又は３０）のうちで、サーバ１に対する接続要求を最初に行ったクライアント２1（又は１２n）は、サーバ１から直接、撮影画像データを取得するとともに、サーバ１から取得した経路制御モジュールを実行することで、接続代行クライアントとして機能し、サブネット２０（又は３０）のうちで、サーバ１に対する接続要求を２番目以降に行ったクライアント２n（又は１２1）は、サーバ１から接続代行クライアント情報を取得し、その情報に基づいて、撮影画像データを接続代行クライアント２1（又は１２n）から取得する。このようにすることで、プロキシやキャッシュサーバなどの特別な装置を用いることなく、サーバ１とサブネット２０（又は３０）との間の通信を、サーバ１と接続代行クライアント２1（又は１２n）間の通信のみとすることができるので、サーバ１とサブネット２０（又は３０）の間の通信回線への負担を極力抑制し、安定した撮影画像データの取得を実現することができる。
【００５９】
特に、本第１の実施形態のように、サーバ１が海外にあるような場合には、サーバ１とインターネット３との間の回線が貧弱である場合があるが、このような場合であっても、本実施形態では、サーバ１とインターネット３との間で通信されるデータ量を極力少なくすることができるので、安定した撮影画像データの配信を行うことが可能である。
【００６０】
なお、上記第１の実施形態では、サブネット２０、３０単位で、接続代行クライアントを設定する場合について説明したが、これに限られるものではなく、例えば、サブネット２０及びサブネット３０を含む全てのクライアントのうち、最初にサーバ１に対して接続要求を出したクライアントのみを接続代行クライアントに設定することとしても良い。また、サブネット２０、３０にとらわれることなく、クライアント群を複数構成し、それら複数のクライアント群の中で、最初にサーバ１に対して接続要求を出したクライアントを接続代行クライアントに設定することとしても良い。
【００６１】
なお、上記第１の実施形態では、接続要求を出したクライアントが、そのクライアントが属するサブネット内に存在する接続代行クライアントに対してのみデータ転送を要求できる、というシーケンスを採用した場合について説明したが、これに限られるものではなく、例えば、サブネット３０内のクライアントが、サブネット２０内の接続代行クライアントに対して接続要求を出すことができるようなシーケンスを採用することとしても良い。例えば、サブネット３０内のクライアントが接続要求を出す場合に、サブネット２０内の接続代行クライアントに接続されているクライアント数と、サブネット３０内の接続代行クライアントに接続されているクライアント数とを比較して、サブネット２０内の接続代行クライアントの方が少なければ、サブネット２０内の接続代行クライアントに対して接続要求を出すことができるというようなシーケンスを採用することができる。また、クライアントが接続要求を出した段階で既に存在する複数の接続代行クライアントの中から、サーバ１との通信状況が最も良好な接続代行クライアントを選択し、その接続代行クライアントに対して、接続要求を出すようなシーケンスを採用しても良い。
【００６２】
なお、上記第１の実施形態では、最初にサーバ１に対して接続要求を出したクライアントが、必ず接続代行クライアントに設定されるようなシーケンスについて説明したが、これに限られるものではなく、例えば、接続代行クライアントとなりうるだけの通信環境を有するクライアントを、予め、候補クライアント（第１の種類のクライアント）に設定しておき、最初に接続要求を出したクライアントが候補クライアントでない場合（第２の種類のクライアントである場合）には、そのクライアントの接続要求が無かったものとして取り扱う（すなわち、そのクライアントを接続代行クライアントにしない）ようなシーケンスを採用することも可能である。
【００６３】
なお、上記第１の実施形態では、セキュリティの向上のため、サーバ１からクライアントに対して、経路制御モジュールを暗号化等して送信するようにしても良い。また、接続要求を行う際や、経路制御モジュールを受け取る際などにおいて、クライアント側のユーザに対してパスワード等の入力を促すようなシーケンスを採用することとしても良い。
【００６４】
なお、上記第１の実施形態では、最初に接続要求を出したクライアントに対して、接続制御モジュールを送信する場合について説明したが、これに限らず、例えば、全てのクライアントの経路制御モジュール記憶部５２に、予め、実行制限が付与された接続制御モジュールを格納しておき、最初に接続要求を出したクライアントの接続制御モジュールについてのみ、サーバ１が、その実行制限を解除するようにしても良い。このようにしても、上記実施形態と同様の効果を得ることができるとともに、サーバ１からクライアントに対して、接続制御モジュール自体を送信しなくても良くなるので、通信回線への負荷を極力抑制することができる。
【００６５】
《第２の実施形態》
次に、本発明の第２の実施形態について、図８〜図１３に沿って説明する。本第２の実施形態は、装置構成については、第１の実施形態と同一であるが、サーバ１で収集された撮影画像データの、各クライアントにおける取得方法が異なっている。したがって、以下においては、この点につき詳細に説明するものとする。
【００６６】
まず、サーバに対して接続要求を出すクライアントの処理について、図８〜図１１のフローチャートに沿って説明する。なお、説明の前提として、サーバ１には既にいくつかのクライアントが接続されているものとする。
【００６７】
まず、図８のステップＳ１１０において、あるクライアント（ここでは、図１のクライアント２1とする）が、サーバ１に対して接続要求を出すと、次のステップＳ１１２において、設定処理サブルーチンを実行する。
【００６８】
この設定処理サブルーチンでは、図９に示されるように、まず、ステップＳ１３０、Ｓ１３２において、その接続が初めての接続であるか否か及び接続の再設定の必要があるか否かを判断する。これらの判断のうち少なくとも一方が肯定されるような場合には、ステップＳ１３４に移行する。また、これらの判断のうちいずれも否定されるような場合には、設定処理を実行する必要が無いので、図９の処理を終了して、図８のステップＳ１２０に移行する。
【００６９】
ここでは、初回の接続であるので、ステップＳ１３０の判断が肯定され、ステップＳ１３４に移行し、サーバ１から、クライアントリスト（現在サーバ１に接続している全クライアントのリスト）を取得する。
【００７０】
次いで、ステップＳ１３６では、サーバ１との通信状態を測定する。この場合における通信状態の測定の指標としては、例えば、ＲＴＴ（Round Trip Time（往復遅延時間））や、ｈｏｐ数（通過するルータの数）などを用いることが可能である。
【００７１】
次いで、ステップＳ１３８では、クライアントリストに基づいて、クライアントリストに載っている全クライアントとの通信状態を、ステップＳ１３６と同一の指標に基づいて測定する。
【００７２】
次いで、ステップＳ１３９では、通信状態が最も良好な装置（サーバ又はクライアント）を選択する（ここでは、通信状態が最も良好な装置が、クライアント２nであったものとする）。
【００７３】
次いで、ステップＳ１４０では、クライアント２1からクライアント２nに対して送信する何らかのコマンド（例えば、データ転送要求コマンドや、カメラ操作コマンドなど）が入力されたかを否かを判断する。ここでの判断が肯定されると、ステップＳ１４１に移行し、そのコマンドがデータ転送要求コマンドであったか否かを判断する。ここでの判断が否定された場合には、図８のステップＳ１２０に移行するが、肯定された場合には、次のステップＳ１４２に移行する。
【００７４】
次のステップＳ１４２では、ステップＳ１３９で通信状態が最も良好であると判断された装置（クライアント２n）に対して、データ転送要求を出す。なお、本第２の実施形態では、データ転送要求を行う際には、サーバ１との通信状態に関するデータを付与して要求を行うものとする。
【００７５】
次いで、ステップＳ１４４では、データ転送要求を受信したクライアント２nから、データ転送を認可する旨の通知を受信したか否かを判断する。
【００７６】
ここで、データ転送要求を受信したクライアント２nにおいて、データ転送を認可する旨の通知を出すか、データ転送を拒否する旨の通知を出すかについての判断手法につき、図１０のフローチャートに沿って説明する。
【００７７】
まず、データ転送要求を受信したクライアント２nは、図１０のステップＳ１６０において、クライアント２nに既に接続されているクライアント（転送クライアント）の数が所定数以上か否かを判断する。ここでの判断が肯定された場合には、ステップＳ１７２に移行して、データ転送を拒否する旨の信号をクライアント２1に送出し、図１０の処理を終了する。
【００７８】
一方、ステップＳ１６０における判断が否定された場合（転送クライアントの数が所定数以下である場合）には、ステップＳ１６２に移行して、クライアント２nが、サーバ１に対して直接接続しているか否かを判断する。ここでの判断が否定された場合（すなわち、いずれかのクライアントからデータを転送してもらっている場合）には、ステップＳ１６４に移行して、クライアント２1に対して認可信号を送出した後、図１０の処理を終了する。
【００７９】
一方、ステップＳ１６２における判断が肯定された場合には、ステップＳ１６８に移行して、クライアント２1とサーバ１との間の通信状態と、自己（クライアント２n）とサーバ１との間の通信状態と、を比較して、前者の方が良好であるか否かを判断する。ここでの判断が否定された場合（すなわち、クライアント２nとサーバ１との間の通信状態のほうが良好な場合）には、ステップＳ１６４に移行して、クライアント２1に対して許可信号を送出した後、図１０の処理を終了する。これに対し、ステップＳ１６８の判断が肯定された場合（すなわち、クライアント２1とサーバ１との間の通信状態の方が良好な場合）には、ステップＳ１７０で、データ転送先交換要求をクライアント２1に対して送出した後、図１０の処理を終了する。
【００８０】
図９のステップＳ１４４の説明に戻り、クライアント２nにおいて、前述した判断が行われた結果、データ転送認可信号が送出された場合には、ステップＳ１４４の判断が肯定され、ステップＳ１４６に移行する。次いで、ステップＳ１４６では、そのクライアント２nを、「接続先クライアント」として設定した後、図８のステップＳ１２０に移行する。
【００８１】
これに対し、ステップＳ１４４の判断が否定された場合には、ステップＳ１４８に移行して、接続先クライアントの交換を行うか否かを判断する（図１０のステップＳ１７０において、データ転送先交換要求が出されたか否かを判断する）。ここでの判断が否定された場合には、ステップＳ１５０に移行して、接続先をサーバ１に設定して、図８のステップＳ１２０に移行する。
【００８２】
これに対し、ステップＳ１４８の判断が肯定された場合には、ステップＳ１５２に移行して、クライアントリストから、先ほどデータ転送要求をした装置（クライアント）を削除する。そして、ステップＳ１５４において、クライアントリストが空か否かを判断するが、ここでの判断が肯定された場合（クライアントリストが空であった場合）には、接続不能と設定し（例えば、接続先を強制的にサーバに設定し）、その後、図８のステップＳ１２０に移行する。一方、ステップＳ１５４の判断が否定された場合、すなわち、クライアントリストに他のクライアントが載っている場合には、ステップＳ１３９に戻り、クライアントリストに載っているクライアント及びサーバから、通信状態が最も良好な装置を選択し、その装置に対してデータ転送要求を行う（ステップＳ１４２）。なお、これ以降の処理については、上記と同様にして実行される。
【００８３】
図８に戻り、クライアント２1においてコマンドが入力されると（ステップＳ１２０）、そのコマンド入力を受けて、画像描画処理を実行し（ステップＳ１２２）、データ転送先のクライアント２nに対してコマンドを送出する（ステップＳ１２４）。そして、ステップＳ１２６において、終了か否かを判断するが、ここでの判断が否定された場合には、再度ステップＳ１１２に戻り、以降の処理を実行する。そして、ステップＳ１２６における判断が肯定された段階で、ステップＳ１２８（終了処理サブルーチン）に移行する。
【００８４】
この終了処理サブルーチンでは、図１１のステップＳ１７４において、クライアント２1に、データを転送するクライアントが接続されているか否かを判断する。ここでの判断が肯定されると、その接続されているクライアントに対して終了信号を送信する(ステップＳ１７６)とともに、接続先（クライアント２n）に終了信号を送信して(ステップＳ１７８)、全工程を終了する。これに対し、接続されているクライアントが無い場合には、接続先（クライアント２n）にのみ終了信号を送信して(ステップＳ１７８)、全工程を終了する。
【００８５】
次に、図１２のフローチャートに沿って、クライアント２nにおけるデータ転送プロセスについて、簡単に説明する。
【００８６】
まず、クライアント２nは、ステップＳ１８０において、クライアント２1からのメッセージ（指示）を受けるまで待機し、メッセージがあった段階で、ステップＳ１８２に移行し、そのメッセージが画像要求か否かを判断する。ここでの判断が肯定された場合には、ステップＳ１８４において、クライアント２1のキャッシュに記憶されている画像をクライアント２nに配信（転送）して、ステップＳ１８０に戻る。
【００８７】
一方、ステップＳ１８２の判断が否定された場合には、ステップＳ１８６に移行して、メッセージが、ビデオカメラ５や拡大用カメラ６のカメラ操作、プロジェクタ４を介したアノテーション（図形）の描画動作などのコマンドをサーバ１に送信するための、コマンド転送要求であったか否かを判断する。ここでの判断が肯定された場合には、ステップＳ１８８において、コマンドをサーバ１に転送し、ステップＳ１８０に戻る。一方、ここでの判断が否定された場合には、ステップＳ１９０に移行する。
【００８８】
次のステップＳ１９０では、メッセージが切断要求であるか否かを判断する。ここでの判断が肯定された場合には、図１２の処理（データ転送プロセス）を終了する。また、ここでの判断が否定された場合には、ステップＳ１９２において、転送クライアントが存在するか否かを判断する。ここでの判断が肯定された場合には、ステップＳ１８０に戻り、否定された場合には、図１２の処理（データ転送プロセス）を終了する。
【００８９】
次に、上述した各クライアントの処理と並行して行われる、サーバ１の処理について、図１３のフローチャートに沿って説明する。
【００９０】
サーバ１では、まず、ステップＳ２００において、クライアント側からのメッセージを受信するまで待機し、メッセージを受信した段階で、ステップＳ２０２に移行し、そのメッセージが接続要求であるか否かを判断する。ここでの判断が肯定された場合には、ステップＳ２０４において、その接続要求メッセージを送信してきたクライアント（本実施形態では、クライアント２1）に対して、クライアントリストを送信するとともに、ステップＳ２０６において、クライアントリストに、クライアント２1を追加する更新を行って、ステップＳ２１４に移行する。
【００９１】
これに対し、ステップＳ２０２の判断が否定された場合には、ステップＳ２０８において、メッセージが切断要求メッセージであったか否かを判断する。ここでの判断が肯定された場合には、ステップＳ２０６において、その切断要求メッセージを送信してきたクライアントをクライアントリストから削除する更新を行って、ステップＳ２１４に移行する。
【００９２】
一方、ステップＳ２０８の判断が否定された場合には、ステップＳ２１０に移行して、クライアントからのコマンドの受領を行い、ステップＳ２１２では、受領したコマンドに応じた、画像投射処理を実行する。
【００９３】
その後は、ステップＳ２１４における終了判断が肯定されるまで、上記と同様の処理（ステップＳ２００〜ステップＳ２１４）を繰り返す。
【００９４】
以上、詳細に説明したように、本第２の実施形態によると、接続要求を出したクライアント２1が、サーバ１から、クライアントリストを取得し、当該リストに掲載されている全クライアントとの間の通信状況、及びサーバとの間の通信状況のうち、最も通信状況が良好なところから撮影画像データを取得する（転送してもらう）こととしているので、プロキシやキャッシュサーバなどの特別な装置を用いることなく、撮影画像データの取得を安定して行うことができる。
【００９５】
また、本第２の実施形態では、データ転送要求を受けたクライアント２nが、自己の通信状況に応じて、データ転送を認可する信号を送出したり、拒否する信号を送出したり、データ転送先の交換要求を出したりし（図１０参照）、それらに基づいて、クライアント２1が、接続先のクライアントを決定するので、クライアント２1と、クライアント２nとの間の通信状況のみで接続先のクライアントを決定するような場合と比較して、接続先のクライアントの状況を考慮した適切な決定を行うことができる。
【００９６】
なお、上記第２の実施形態では、ステップＳ１６０（図１０参照）における判断を、クライアント２nに既に接続されているクライアント数が所定数を越えているか否かに基づいて行うこととしているが、これとともに又はこれに代えて、クライアント２nにおけるＣＰＵの負荷が所定の閾値を超えているか否かにより、判断することとしても良い。
【００９７】
また、上記第２の実施形態では、例えば、サーバ１に、ある一定数以上のクライアントが直接接続した場合において、それらクライアントの少なくとも一部に対して、サーバ１から、直接接続を禁止する信号を送信するようなシーケンスを採用することとしても良い。この禁止信号を受信したクライアントは、サーバ１に対して、再度接続要求を出すことにより、図８等の処理を再度やり直すようにすることが可能である。
【００９８】
また、ステップＳ１７８（図１１参照）において、クライアント２nから送信される終了信号をクライアント２1が受信した場合（クライアント２nがサーバ１との接続を切断した場合）にも、上記と同様、クライアント２1は、サーバ１に対して、再度接続要求を出すことにより、図８等の処理を再度やり直すようにすることが可能である。
【００９９】
また、各クライアントでは、適当なタイミングで、サーバ１に対して接続要求を出すことにより、接続先のクライアントの変更（ネットワーク再構築）を所定間隔で実行するようにしても良い。
【０１００】
なお、上記各実施形態では、２つのサブネット（２０，３０）が設けられた場合について説明したが、これに限らず、サブネットが３つ以上あっても良い。また、ネットワーク構成は、図１のネットワーク構成に限られるものではなく、種々の構成を採用することが可能である。例えば、上記各実施形態では、サーバ１が海外、サブネット２０，３０が国内に配置された場合について説明したが、これに限らず、サーバ１を国内に配置するなどの構成を採用しても良い。
【０１０１】
上述した各実施形態は本発明の好適な実施の例である。但し、これに限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変形実施可能である。
【図面の簡単な説明】
【０１０２】
【図１】第１の実施形態に係る遠隔診断システムの概略構成を示す図である。
【図２】サーバ及びクライアントの機能構成を示すブロック図である。
【図３】第１の実施形態のサーバの処理を示すフローチャートである。
【図４】第１の実施形態のサーバの処理を示すフローチャートである。
【図５】図３、図４の処理を具体的に説明するための図（その１）である。
【図６】図３、図４の処理を具体的に説明するための図（その２）である。
【図７】図３、図４の処理を具体的に説明するための図（その３）である。
【図８】第２の実施形態のクライアントの処理を示すフローチャートである。
【図９】図８のステップＳ１１２の具体的な処理を示すフローチャートである。
【図１０】図９のステップＳ１４４の前提となるクライアントの処理・判断を示すフローチャートである。
【図１１】図８のステップＳ１２８の具体的な処理を示すフローチャートである。
【図１２】接続先となるクライアント２nによるデータ転送プロセスの具体的な処理を示すフローチャートである。
【図１３】第２の実施形態のサーバの処理を示すフローチャートである。
【符号の説明】
【０１０３】
１  サーバ
２1〜２n  クライアント
３  インターネット
１２1〜１２n  クライアント
２０  サブネット
２３  イントラネット
２３’  イントラネット
３０  サブネット
１００  遠隔診断システム
【図１】
2009060252.tif 000003
【図２】
2009060252.tif 000004
【図３】
2009060252.tif 000005
【図４】
2009060252.tif 000006
【図５】
2009060252.tif 000007
【図６】
2009060252.tif 000008
【図７】
2009060252.tif 000009
【図８】
2009060252.tif 000010
【図９】
2009060252.tif 000011
【図１０】
2009060252.tif 000012
【図１１】
2009060252.tif 000013
【図１２】
2009060252.tif 000014
【図１３】
2009060252.tif 000015