(57)【要約】【課題】ネットワークへの負担を軽減した状態で、ストリーミング画像の配信を行うことが可能な画像配信システムを提供する。【解決手段】ネットワーク３を介してストリーミング画像を送信するビデオ配信サーバと、ネットワーク３を介して受信した画像を転送する中継機能を有する、複数のクライアント（２Ａ〜２Ｄ）と、クライアントからの問い合わせに対し、ストリーミング配信のツリー構造の情報に基づいて、ビデオ配信サーバ又はクライアントの中から、画像送信に適したものを選択して、その情報を返信する拡張ＤＮＳサーバと、を備え、拡張ＤＮＳサーバから返信された情報がビデオ配信サーバの情報であった場合には、問い合わせを行ったクライアントはビデオ配信サーバか画像を直接受信し、返信された情報がクライアントの情報であった場合には、そのクライアントから画像を転送してもらう。【選択図】図１
2009071538.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークに接続され、該ネットワークを介してストリーミング画像を送信する第１サーバと、
前記ネットワークに接続され、該ネットワークを介して受信したストリーミング画像を転送する中継機能を有する、複数のクライアントと、
前記ネットワークに接続され、前記クライアントからの問い合わせに対し、前記ネットワークにおけるストリーミング配信のツリー構造の情報に基づいて、前記第１サーバ又は前記ストリーミング画像を現に受信しているクライアントの中から、前記問い合わせを行ったクライアントに対する前記ストリーミング画像の送信に適したものを選択して、その情報を返信する第２サーバと、を備え、
前記問い合わせを行ったクライアントは、
前記第２サーバから返信された情報が、前記第１サーバの情報であった場合には、前記第１サーバから前記ストリーミング画像を直接受信し、前記第２サーバから返信された情報が、前記複数のクライアントのいずれかの情報であった場合には、そのクライアントから前記ストリーミング画像を受信することを特徴とする画像配信システム。
【請求項２】
前記第１サーバ及び前記第２サーバは、同一のネットワークセグメント上に配置されていることを特徴とする請求項１に記載の画像配信システム。
【請求項３】
前記ストリーミング配信のツリー構造の情報は、前記第１又は第２サーバにより収集されることを特徴とする請求項１又は２に記載の画像配信システム。
【請求項４】
前記第１又は第２サーバは、前記第１サーバと前記ストリーミング画像を受信しているクライアントとの間の通信状況に関する情報を取得するとともに、前記クライアント間の接続状態に関する情報を取得して、各情報に基づいて、前記ストリーミング配信のツリー構造の情報を収集することを特徴とする請求項３に記載の画像配信システム。
【請求項５】
前記クライアント間の接続状態に関する情報は、ツリー構造のリーフノードであるクライアントから前記第１又は第２サーバ側に向けて、クライアント情報を順次送信し、前記送信途中で、他のクライアントを経由する場合には、当該他のクライアントは、前記クライアント情報に自己のクライアント情報を付加して、前記第１又は第２サーバ側に送信することを特徴とする請求項４に記載の画像配信システム。
【請求項６】
前記ストリーミング配信のツリー構造の情報が変動して、前記問い合わせを行ったクライアントに対して前記ストリーミング画像を送信するのに適したサーバ又はクライアントが変更された場合に、
前記第１サーバは、前記問い合わせを行ったクライアントに対して、前記ストリーミング画像の受信先を変更させることを特徴とする請求項３〜５のいずれか一項に記載の画像配信システム。
【請求項７】
前記問い合わせを行ったクライアントに対して前記ストリーミング画像を送信するのに適したサーバ又はクライアントが変更された場合に、
前記第１サーバは、前記問い合わせを行ったクライアントに対して、前記第２サーバに対する再問い合わせを実行させることを特徴とする請求項６に記載の画像配信システム。
【請求項８】
前記問い合わせを行ったクライアントに対して前記ストリーミング画像を送信するのに適したサーバ又はクライアントが変更された場合に、
前記第１サーバは、前記問い合わせを行ったクライアントに対して、新たな接続先を指定して、再接続させることを特徴とする請求項６に記載の画像配信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は画像配信システムに関し、特に複数のクライアントに対してストリーミング画像を配信する画像配信システムに関する。
【背景技術】
【０００２】
従来より、ビデオカメラ及びプロジェクタが接続されているサーバ（例えばコンピュータ）と、ネットワークを介して当該サーバに接続される遠隔地のクライアント（例えばコンピュータ）とを備え、サーバ側に存在する診断対象物を、クライアント側で診断する遠隔診断システムが知られている（例えば、特許文献１参照）。
【０００３】
この遠隔診断システムでは、サーバは、サーバに接続されているビデオカメラにより撮影される対象物の撮影画像（例えば、ストリーミング画像）を、ネットワークを介してクライアントに送信するものであり、クライアントは、表示装置の表示画面に立体物を含む撮影画像を表示し、当該表示画面上にアノテーション画像（線、図形、文字）などが書き込まれると、当該アノテーション画像をネットワークを介してサーバに送信するものである。また、サーバは受信したアノテーション画像をプロジェクタに送信し、プロジェクタは受信したアノテーション画像を対象物を含む投影領域の適切な位置（これは、クライアントが、撮影画像の範囲内でアノテーション画像を書き込んだ位置に対応する）に投影する。
【０００４】
このような遠隔診断システムでは、例えば、サーバから配信される画像（ストリーミング画像）をユーザがクライアントを介して観察し、各クライアントのユーザ間でコミュニケーションを図るという運用が想定されている。しかるに、同時に接続しようとするクライアントが増えれば増えるほど回線に負担がかかるため、安定的な通信を行えなくなるという問題がある。
【０００５】
このような問題を解決するための技術として、最近では、複数のノードへデータを配信する際に、同一経路上でのデータ配信を集約してネットワークへの負荷を分散するもの（マルチキャスト）や、インターネット上において、複数のサーバを分散して配置しておき、ネットワーク識別子(FQDN:Fully Qualified Domain Name)からネットワーク識別番号(ＩＰアドレス)を検索する際に、クライアントのＩＰアドレスに基づいてクライアントを近隣のサーバに誘導するものや、同一のＩＰアドレスのサーバをインターネット上に複数配置し、近隣のネットワークへサーバへの経路情報を伝播することで、クライアントを最短のサーバへ誘導するもの（BGP（Border Gateway Protocol） Anycast技術）、などの技術が出現している
【０００６】
【特許文献１】特開２００５−３３７５６号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
しかしながら、上記遠隔診断システムに、マルチキャストを採用する場合、全ての機器（ルータなど）をマルチキャストに対応させておく必要があるため、マルチキャストに対応する機器を用意するためにコスト高を招くおそれがある。また、複数のサーバを分散して配置する方法においても、インターネット上に複数のサーバを用意する必要があるため、コスト高を招くおそれがある。また、BGP Anycast技術は、インターネットのように大規模なTCP/IPネットワークにおいて経路情報を交換するためのプロトコルであるBGPによって運用されているネットワーク環境では適用できるが、現段階でのイントラネットではBGPによる運用がなされていないため、例えば、上記遠隔診断システムのネットワークがイントラネットである場合に、当該技術を遠隔診断システムに適用するのは困難であるものと考えられる。
【０００８】
また、ＣＤＮ（Contents Delivery Network）を用いたり（例えば、特開２００３−１５２７８５号公報参照）、Ｐ２Ｐ（Peer to Peer）を用いたりすることも考えられるが、これらの方法は、ストリーミング画像のリアルタイム配信にはあまり適していないため、上記のように、各クライアント間でリアルタイムに配信される画像を見ながらコミュニケーションを図る遠隔診断システムに、これらの技術を適用するのは難しいと考えられる。
【０００９】
そこで本発明は上記の課題に鑑みてなされたものであり、ネットワークへの負担を軽減した状態で、ストリーミング画像の配信を行うことが可能な画像配信システムを提供することを目的とする。
【課題を解決するための手段】
【００１０】
上記課題を解決するために、本発明は、ネットワークに接続され、該ネットワークを介してストリーミング画像を送信する第１サーバと、前記ネットワークに接続され、該ネットワークを介して受信したストリーミング画像を転送する中継機能を有する、複数のクライアントと、前記ネットワークに接続され、前記クライアントからの問い合わせに対し、前記ストリーミング配信のツリー構造の情報に基づいて、前記第１サーバ又は前記ストリーミング画像を現に受信しているクライアントの中から、前記問い合わせを行ったクライアントに対する前記ストリーミング画像の送信に適したものを選択して、その情報を返信する第２サーバと、を備え、前記問い合わせを行ったクライアントは、前記第２サーバから返信された情報が、前記第１サーバの情報であった場合には、前記第１サーバから前記ストリーミング画像を直接受信し、前記第２サーバから返信された情報が、前記複数のクライアントのいずれかの情報であった場合には、そのクライアントから前記ストリーミング画像を受信することを特徴とする画像配信システムである。
【００１１】
これによれば、クライアントから第２サーバに対する問い合わせが行われると、第２サーバは、ストリーミング配信のツリー構造の情報に基づいて、第１サーバ又は現にストリーミング画像を受信しているクライアントの中から、問い合わせを行ったクライアントに対するストリーミング画像の送信に適したものを選択して、その情報を返信することから、問い合わせを行ったクライアントを、配信のためのツリー構造に基づく適切な中継先（クライアント）に接続させることができる。これにより、ネットワークへの負担を軽減した状態で、ストリーミング画像の配信を行うことが可能となる。
【００１２】
この場合において、前記第１サーバ及び前記第２サーバは、同一のネットワークセグメント上に配置されていることとすることができる。
【００１３】
また、前記ストリーミング配信のツリー構造の情報は、前記第１又は第２サーバにより収集されることとすることができる。この場合、前記第１又は第２サーバは、前記第１サーバと前記ストリーミング画像を受信しているクライアントとの間の通信状況に関する情報を取得するとともに、前記クライアント間の接続状態に関する情報を取得して、各情報に基づいて、前記ストリーミング配信のツリー構造の情報を収集することとすることができる。また、前記クライアント間の接続状態に関する情報は、ツリー構造のリーフノードであるクライアントから前記第１又は第２サーバ側に向けて、クライアント情報を順次送信し、前記送信途中で、他のクライアントを経由する場合には、当該他のクライアントは、前記クライアント情報に自己のクライアント情報を付加して、前記第１又は第２サーバ側に送信することとすることができる。
【００１４】
ストリーミング配信のツリー構造の情報を、第１又は第２サーバにより収集する本発明の画像配信システムでは、前記ストリーミング配信のツリー構造の情報が変動して、前記問い合わせを行ったクライアントに対して前記ストリーミング画像を送信するのに適したサーバ又はクライアントが変更された場合に、前記第１サーバは、前記問い合わせを行ったクライアントに対して、前記ストリーミング画像の受信先を変更させることとすることができる。かかる場合には、新たなクライアントが追加されるなどしてツリー構造が変動しても、そのツリー構造に合わせた適切な受信先を設定することが可能となる。
【００１５】
この場合において、前記問い合わせを行ったクライアントに対して前記ストリーミング画像を送信するのに適したサーバ又はクライアントが変更された場合に、前記第１サーバは、前記問い合わせを行ったクライアントに対して、前記第２サーバに対する再問い合わせを実行させることとすることができる。かかる場合には、画像送信に適したサーバ又はクライアントが変更された場合に、クライアントに再問い合わせを行わせることとすることで、常時適切なサーバ又はクライアントから、ストリーミング画像を受信することが可能となる。また、前記問い合わせを行ったクライアントに対して前記ストリーミング画像を送信するのに適したサーバ又はクライアントが変更された場合に、前記第１サーバは、前記問い合わせを行ったクライアントに対して、新たな接続先を指定して、再接続させることとすることができる。かかる場合には、第１サーバは、新たな接続先を指定して、クライアントに再接続させるため、クライアントは、第２サーバに問い合わせを行うこと無く、ストリーミング画像の送信に適したサーバ又はクライアントに再接続することが可能となる。
【発明の効果】
【００１６】
本発明によれば、ネットワークへの負担を軽減した状態で、ストリーミング画像の配信を行うことが可能な画像配信システムを提供することができる。
【発明を実施するための最良の形態】
【００１７】
以下、本発明の一実施形態について図１〜図１５（ｂ）に基づいて詳細に説明する。図１には、本実施形態の遠隔診断システム１００の構成が概略的に示されている。
【００１８】
図１の遠隔診断システム１００は、ビデオ配信サーバ１Ａから配信されるストリーミング画像（診断対象物を撮影した動画）を、複数のクライアント（２Ａ〜２Ｄ）を介して、複数のユーザが同時に観察しながら、診断対象物の診断を行うためのシステムである。この遠隔診断システム１００は、ネットワーク（イントラネット）３を有しており、このネットワーク３に、ビデオ配信サーバ１Ａと、拡張ＤＮＳサーバ１Ｂと、複数のクライアント２Ａ〜２Ｄと、が接続されている。
【００１９】
ビデオ配信サーバ１Ａは、クライアントに対して同一のビデオコンテンツ（診断対象物をビデオカメラ４２（図２（ａ）参照）で撮影したストリーミング画像）を提供するサーバである。このビデオ配信サーバ１Ａは、当該サーバ１Ａにネットワークを介して接続されているクライアントのアドレス情報（クライアントリスト）を、拡張ＤＮＳサーバ１Ｂとの間で定期的に交換するとともに、クライアントとの接続が切断された場合には、その切断情報を拡張ＤＮＳサーバ１Ｂに通知する。また、ビデオ配信サーバ１Ａは、各クライアントとの接続状況を定期的に取得し、拡張ＤＮＳサーバ１Ｂに対して送信したり、既にストリーミング画像を受信しているクライアントから送られてくる経路情報を定期的に収集したりする。なお、ビデオ配信サーバ１Ａには、診断対象物に対して、アノテーション（図形等）を投影することが可能なプロジェクタ（投影装置）が接続されていても良い。
【００２０】
拡張ＤＮＳサーバ１Ｂは、ビデオ配信サーバ１Ａへの負荷を軽減するために設計された専用のＤＮＳサーバであり、ビデオ配信サーバ１Ａと同一のネットワークセグメント（ツリー構造の最上流）上に配置されている。拡張ＤＮＳサーバ１Ｂは、クライアントから問い合わせを受けると、既にストリーミング画像を受信しているクライアントが存在するか否か、及びそのクライアントが問い合わせを行ったクライアントの近傍に位置するか否かを判断して、各判断がいずれも肯定されるような場合には、問い合わせを行ったクライアントに対して、近傍に位置するクライアントの情報（ＩＰアドレス）を返信する。また、各判断のいずれかが否定される場合には、問い合わせを行ったクライアントに対して、ビデオ配信サーバ１Ａの情報（ＩＰアドレス）を返信する。また、拡張ＤＮＳサーバ１Ｂは、ビデオ配信サーバ１Ａとの間で、前述した各クライアントの接続状況（クライアントリスト）、及び切断状況のやり取りを行う。
【００２１】
複数のクライアント２Ａ〜２Ｄは、ストリーミング画像を受信し、ディスプレイ４４（図２（ｃ）参照）の画面上に表示するものである。これら各クライアント（２Ａ〜２Ｄ）は、いわゆる中継機能を有している。すなわち、近傍に同一のストリーミング画像の視聴を希望するクライアントがあれば、そのクライアントに対して、受信中のストリーミング画像を転送することが可能である。
【００２２】
次に、ビデオ配信サーバ１Ａ、拡張ＤＮＳサーバ１Ｂ、クライアント２Ａ〜２Ｄの機能構成について、図２（ａ）〜図２（ｃ）に基づいて説明する。
【００２３】
ビデオ配信サーバ１Ａは、図２（ａ）に示されるように、ビデオ送信部１０と、情報交換通知部１２と、経路探索部１４と、近傍探索部１６と、ＲＡＭ等から構成される記憶部１８と、ビデオ配信サーバ１Ａの構成各部を統括的に制御する制御部２０と、を備えている。
【００２４】
ビデオ送信部１０は、外部から接続されたビデオカメラ４２を介して、ストリーミング画像を生成し、そのストリーミング画像（画像データ）をクライアント（２Ａ〜２Ｄ）に対して送信する。情報交換通知部１２は、ビデオ配信サーバ１Ａに接続されている全クライアントの情報（ＩＰアドレス）を拡張ＤＮＳサーバ１Ｂ（情報交換通知部２２）に定期的に通知したり、クライアントとの間の接続を切断した段階で、拡張ＤＮＳサーバ１Ｂ（情報交換通知部２２）に対して、切断したクライアントの情報（ＩＰアドレス）を通知したりする。経路探索部１４は、既に接続している各クライアント（２Ａ〜２Ｄ）へping/tracerouteプログラムを実行し、各クライアント（２Ａ〜２Ｄ）との間の経路情報（例えばｈｏｐ数）やＲＴＴ（Round Trip Time）を定期的に収集する。近傍探索部１６は、クライアントから送信されてくるツリー判断情報に基づいてツリー情報を生成する。
【００２５】
拡張ＤＮＳサーバ１Ｂは、図２（ｂ）に示されるように、情報交換通知部２２と、アドレス情報応答部２４と、ＲＡＭ等から構成される記憶部２６と、拡張ＤＮＳサーバ１Ｂの構成各部を統括的に制御する制御部３０と、を備えている。
【００２６】
情報交換通知部２２は、ビデオ配信サーバ１Ａに接続されている全クライアント（２Ａ〜２Ｄ）の情報（ＩＰアドレス）を定期的に受信したり、クライアント（２Ａ〜２Ｄ）とビデオ配信サーバ１Ａとの間の接続が切断された場合に、当該クライアント（２Ａ〜２Ｄ）の情報（ＩＰアドレス）を受信したりする。アドレス情報応答部２４は、クライアントからの問い合わせに対して、クライアントの近傍に中継が可能なクライアントが存在するか否かを判断して応答したり、ビデオ配信サーバ１Ａからの経路情報に基づいて、最適な接続先のＩＰアドレスを応答したりする。
【００２７】
クライアント２Ａ〜２Ｄのそれぞれは、図２（ｃ）に示されるように、情報交換通知部３２と、ストリーミング中継部３４と、ＲＡＭ等から構成される記憶部３６と、クライアントの構成各部を統括的に制御する制御部４０と、を備えている。
【００２８】
情報交換通知部３２は、ビデオ配信サーバ１Ａから再接続要求を受信したり、この再接続要求に基づいて、拡張ＤＮＳサーバ１Ｂに対して、問い合わせを行ったり、ビデオ配信サーバ１Ａに対してツリー判断情報を送信したりする。
【００２９】
ストリーミング中継部３４は、ストリーミング画像（画像データ）を受信して、そのストリーミング画像を、ストリーミング中継部３４に接続されたディスプレイ４４上に表示する。また、近傍のクライアントからストリーミング画像の転送要求を受けたときには、そのクライアントに対し、ストリーミング中継部３４からストリーミング画像を送信（転送）する。
【００３０】
次に、上記のように構成される遠隔診断システム１００の処理について、図３（ａ）〜図１５（ｂ）に基づいて説明する。以下においては、遠隔診断システム１００の処理について、＜接続開始処理＞、＜配信開始処理＞、＜ツリー情報評価処理＞、＜再接続要求処理＞、＜接続終了処理＞に分けて、順に説明するものとする。
【００３１】
＜接続開始処理＞
図３（ａ）には、クライアントにおける接続開始処理がフローチャートにて示されている。また、図３（ｂ）には、拡張ＤＮＳサーバ１Ｂにおける、ビデオ配信サーバ１Ａへの応答処理がフローチャートにて示されている。
【００３２】
これら図３（ａ）、図３（ｂ）のフローチャートでは、まず、図３（ａ）のステップＳ１０において、あるクライアントが、拡張ＤＮＳサーバ１Ｂに対して問い合わせを行うと、次のステップＳ１２では、拡張ＤＮＳサーバ１Ｂからの応答を受信するまで待機する。これに対し、拡張ＤＮＳサーバ１Ｂ側では、図３（ｂ）のステップＳ２０においては、クライアントからの問い合わせを受信したか否かを判断し、図３（ａ）のステップＳ１０において、クライアントから問い合わせが行われた段階で、ここでの判断が肯定され、ステップＳ２２に移行する。そして、ステップＳ２２では、クライアント情報を探索し（これについては後述する）、ステップＳ２４において、問い合わせを行ったクライアントに対して、接続先とすべきサーバ又はクライアントに関する情報（応答情報）を送信する。
【００３３】
このようにして、拡張ＤＮＳサーバ１Ｂから送信された応答情報をクライアントが受信すると、図３（ａ）のステップＳ１２の判断が肯定され、ステップＳ１４に移行し、このステップＳ１４において応答情報を記憶部３６に記憶する。そして、次のステップＳ１６では、応答情報（接続先のＩＰアドレス）に基づいて、接続先（サーバ又はクライアント）に対して、ビデオ配信要求を通知する。
【００３４】
ここで、上記処理（図３（ａ）、図３（ｂ）の処理）の具体例について、図４（ａ）〜図５（ｂ）に基づいて、説明する。
【００３５】
まず、図４（ａ）の点線矢印（１）に示されるように、クライアント２Ａが、拡張ＤＮＳサーバ１Ｂに問い合わせを行ったものとする（図３（ａ）のステップＳ１０）。この問い合わせを受信した拡張ＤＮＳサーバ１Ｂは、クライアント情報を探索するが、（図３（ｂ）のステップＳ２２）、ここでは、ビデオ配信サーバ１Ａに接続されているクライアントが１つも無いので、クライアント２Ａに対して、ビデオ配信サーバ１Ａの情報（ＩＰアドレス）を送信する（図４（ａ）の点線矢印（２）参照）。この情報を受信したクライアント２Ａでは、その情報を記憶部３６に記憶するとともに（図３（ａ）のステップＳ１４）、その情報（ビデオ配信サーバ１ＡのＩＰアドレス）に基づいて、ビデオ配信サーバ１Ａに対して、ビデオ配信要求を通知することにより、ビデオ配信サーバ１Ａとクライアント２Ａとの間が接続される（図４(ａ)の点線両矢印（３）参照）。
【００３６】
また、同様に、図４（ｂ）の点線矢印（４）に示されるように、クライアント２Ｄが、拡張ＤＮＳサーバ１Ｂに問い合わせを行った場合（ステップＳ１０）、拡張ＤＮＳサーバ１Ｂは、クライアント情報を探索する（ステップＳ２２）。ここでは、ビデオ配信サーバ１Ａに接続されているクライアントとしてクライアント２Ａがあるが、クライアント２Ａとビデオ配信サーバ１Ａとでは、ビデオ配信サーバ１Ａの方が、クライアント２Ｄから近い位置に存在している。したがって、拡張ＤＮＳサーバ１Ｂは、クライアント２Ｄに対して、ビデオ配信サーバ１Ａの情報（ＩＰアドレス）を送信する（図４（ｂ）の点線矢印（５）参照）。この情報を受信したクライアント２Ｄでは、その情報を記憶部３６に記憶するとともに（ステップＳ１４）、その情報（ビデオ配信サーバ１ＡのＩＰアドレス）に基づいて、ビデオ配信サーバ１Ａに対して、ビデオ配信要求を通知することにより、ビデオ配信サーバ１Ａとクライアント２Ｄとの間が接続される（図４（ｂ）の点線両矢印（６）参照）。
【００３７】
また、図５（ａ）の点線矢印（７）に示されるように、クライアント２Ｂが拡張ＤＮＳサーバ１Ｂに問い合わせを行った場合（ステップＳ１０）、拡張ＤＮＳサーバ１Ｂは、クライアント情報を探索する（ステップＳ２２）が、ここでは、クライアント２Ａがクライアント２Ｂに近接しているので、拡張ＤＮＳサーバ１Ｂは、クライアント２Ｂに対して、クライアント２Ａの情報（ＩＰアドレス）を送信する（図５（ａ）の点線矢印（８）参照）。この情報を受信したクライアント２Ｂでは、その情報を記憶部３６に記憶するとともに（ステップＳ１４）、その情報（クライアント２ＡのＩＰアドレス）に基づいて、クライアント２Ａに対して、ビデオ配信要求（転送要求）を通知することにより、クライアント２Ａとクライアント２Ｂとの間が接続される（図５（ａ）の点線両矢印（９）参照）。
【００３８】
更に、図５（ｂ）の点線矢印（１０）に示されるように、クライアント２Ｃが拡張ＤＮＳサーバ１Ｂに問い合わせを行った場合（ステップＳ１０）、拡張ＤＮＳサーバ１Ｂは、クライアント情報を探索する（ステップＳ２２）が、ここでは、ビデオ配信サーバ１Ａが最も近いので、拡張ＤＮＳサーバ１Ｂは、クライアント２Ｂに対して、ビデオ配信サーバ１Ａの情報（ＩＰアドレス）を送信する（図５（ｂ）の点線矢印（１１）参照）。この情報を受信したクライアント２Ｃでは、その情報を記憶部３６に記憶するとともに（ステップＳ１４）、その情報（ビデオ配信サーバ１ＡのＩＰアドレス）に基づいて、ビデオ配信サーバ１Ａに対して、ビデオ配信要求を通知することにより、ビデオ配信サーバ１Ａとクライアント２Ｃとの間が接続される（図５（ｂ）の点線両矢印（１２）参照）。
【００３９】
以上のようにして、問い合わせを行ったクライアントと、ビデオ配信サーバ１Ａ又は他のクライアントとが接続されるようになっている。
【００４０】
＜配信開始処理＞
次に、図３（ａ）のステップＳ１６において、クライアントからサーバ又は別のクライアントに対してビデオ配信（転送）要求が出された際に行われる、ビデオ（ストリーミング画像）の配信開始動作について、図６（ａ）、図６（ｂ）に沿って説明する。
【００４１】
まず、ビデオ配信要求がビデオ配信サーバ１Ａに出された場合の、ビデオ配信サーバ１Ａの処理について図６（ａ）に基づいて説明する。まず、ビデオ配信サーバ１Ａは、図６（ａ）のステップＳ３０において、ビデオ配信要求を受信したか否かを判断する。ここでの判断が肯定された場合には、次のステップＳ３２に移行して、ビデオ配信要求を送信してきたクライアントの情報（ＩＰアドレスなど）を、記憶部１８内に記憶されているクライアントリストに追加する。そして、次のステップＳ３４では、ビデオ配信サーバ１Ａからクライアントに対して、ストリーミング画像の配信を開始する。その後は、ステップＳ３０において、次のビデオ配信要求を受信するまで、待機する。
【００４２】
次に、あるクライアント（例えば、クライアント２Ｂとする）から、別のクライアント（例えば、クライアント２Ａとする）にビデオ配信要求が出された場合の、クライアント２Ａの処理について、図６（ｂ）に基づいて説明する。この図６（ｂ）のステップＳ４０では、クライアント２Ａがクライアント２Ｂから送信されたビデオ配信要求を受信したか否かを判断する。ここでの判断が肯定された場合には、次のステップＳ４２に移行して、ビデオ配信要求を行ったクライアントの情報（ＩＰアドレスなど）を、ビデオ配信サーバ１Ａに送信する（この場合、クライアント２Ａの情報交換通知部３２と、ビデオ配信サーバ１Ａの情報交換通知部１２との間でクライアント情報がやり取りされる）。そして、ビデオ配信サーバ１Ａでは、記憶部１８内に記憶されているクライアントリストに、ビデオ配信要求を行ったクライアント２Ｂを追加する。次いで、ステップＳ４４では、接続先のクライアント２Ａからクライアント２Ｂに対してストリーミング画像の転送を開始する。その後は、ステップＳ４０において、次のビデオ配信要求を受信するまで、待機する。
【００４３】
＜ツリー情報評価処理＞
次に、ビデオ配信サーバ１Ａにおいて行われる、前述した図３（ｂ）のステップＳ２２（クライアント情報の探索処理）で用いられるツリー情報の評価処理について、図７〜図１０に基づいて説明する。まず、図７のステップＳ５０では、経路探索サブルーチンが実行される。この経路探索サブルーチンでは、図８（ａ）に示されるように、まず、ステップＳ６０において、接続中の全クライアント（記憶部１８に記憶されているクライアントリストに掲載されている全クライアント）の情報を取得する。
【００４４】
次いで、ステップＳ６２では、経路探索が終了したか否かを判断するが、ここでの判断が否定されると、次のステップＳ６４において、あるクライアント（例えば、クライアント２Ａ）の経路探索を開始する。この場合の探索は、例えば、ping/tracerouteプログラムを実行して、あるクライアント（２Ａ）に対して実際にパケットを送信することにより行われる。この探索が終了すると、次のステップＳ６６において、探索結果を記憶した後、ステップＳ６２に戻る。その後は、ステップＳ６２→Ｓ６４→Ｓ６６の処理・判断を繰り返し、全クライアントに対する探索が終了することにより、ステップＳ６２の判断が否定されると、図７のステップＳ５２に移行する。
【００４５】
図７のステップＳ５２では、近傍探索サブルーチンを実行する。この近傍探索サブルーチンでは、まず、図８（ｂ）のステップＳ７０において、クライアントからツリー判断情報を取得したか否かを判断する。ここでのツリー判断情報の取得は、図９に示されるフローチャートに沿って行われる。なお、この図９のフローチャートは、接続されているクライアント（ここでは、図１０に示されるように、クライアント２Ａ〜２Ｄが接続されているものとする）において、同時並行的に実行される。
【００４６】
まず、クライアント２Ａの処理について説明する。クライアント２Ａでは、図９のステップＳ８０においてクライアント２Ａがリーフノードか否かを判断する。ここでは、クライアント２Ａは、図１０に示されるように、ネットワーク３の末端に位置しているので、判断が肯定され、ステップＳ８２に移行し、ツリー判断情報を生成する。この場合のツリー判断情報としては、例えば、リーフノードのクライアント２Ａの下には、クライアントが接続されていないことを意味する「２Ａ（emp）」が生成されるものとする。次いで、図９のステップＳ８８では、クライアント２Ａは、上流のクライアント（ここでは、図１０に示されるクライアント２Ｃ）にツリー判断情報「２Ａ（emp）」を送信して、図９の処理を終了する。なお、クライアント２Ｂに関しても、図９のステップＳ８０の判断が肯定されるので、クライアント２Ａと同様、ステップＳ８２において、ツリー判断情報（ここでは、クライアント２Ｂの下にクライアントが接続されていないことを意味する「２Ｂ（emp）」）を生成し、ステップＳ８８において、上流のクライアント（ここでは、図１０に示されるクライアント２Ｃ）にツリー判断情報を送信して、図９の処理を終了する。
【００４７】
次にクライアント２Ｃの処理について説明する。クライアント２Ｃでは、上記と同様にして、図９のステップＳ８０の判断を行うが、クライアント２Ｃは、リーフノードではないので、ここでの判断は否定される。次いで、ステップＳ８４では、クライアント２Ｃが下流のクライアントからツリー判断情報を受信するまで待機する。そして、前述のように、クライアント２Ａ，２Ｂから送信されたツリー判断情報を受信した段階で、次のステップＳ８６に移行して、受信したツリー判断情報に自己のクライアント情報を追加する。ここでは、クライアント２Ｃは、「２Ａ（emp）」と「２Ｂ（emp）」のツリー判断情報を受信しているので、図１０に示されるように、それらのクライアントが下流に存在することを意味する「２Ｃ（２Ａ、２Ｂ）」というツリー判断情報を生成する。その後は、ステップＳ８８において、ステップＳ８６において生成されたツリー判断情報を上流側（ここでは、ビデオ配信サーバ１Ａ）に送信して、図９の処理を終了する。
【００４８】
なお、クライアント２Ｄについては、リーフノードであるので、前述したクライアント２Ａ，２Ｂと同様のツリー判断情報「２Ｄ（emp）」を生成し、その情報を上流側（ここでは、ビデオ配信サーバ１Ａ）に送信する。
【００４９】
図８（ｂ）に戻り、ステップＳ７０において、上述のようにして、ビデオ配信サーバ１Ａがツリー判断情報を取得すると、次のステップＳ７２に移行して、図８（ａ）のステップＳ６６において記憶部１８に記憶された探索結果を読み出し、この探索結果と、ツリー判断情報とを照合する。
【００５０】
次いで、ステップＳ７６において、照合結果を記憶部１８に記憶した後、図７のステップＳ５４に移行する。
【００５１】
図７のステップＳ５４では、図８（ｂ）のステップＳ７４の照合結果を評価する。例えば、探索結果から、あるクライアントとビデオ配信サーバ１Ａとの間には、中継クライアントが存在しているにもかかわらず、そのクライアントが、ビデオ配信サーバ１Ａから直接ストリーミング画像を受信していたりしないかどうかなどを判断する。
【００５２】
＜再接続要求処理＞
次に、ビデオ配信サーバ１Ａにおいて不定期で行われる、再接続要求処理について、図１１のフローチャートに沿って説明する。この再接続要求処理は、ビデオ配信サーバ１Ａにおいて、各クライアントが適切に接続されているかを判断し、接続が適切で無い場合に、そのクライアントに対して再接続を実行させるための処理である。なお、ここでは、図５（ｂ）に示されるように、クライアント２Ａ、２Ｃ、２Ｄがビデオ配信サーバ１Ａに接続され、クライアント２Ｂがクライアント２Ａに接続されているものとする。
【００５３】
まず、図１１のステップＳ９０では、ビデオ配信サーバ１Ａが、記憶部１８からストリーミング配信のツリー情報を読み出す。次いで、ビデオ配信サーバ１Ａは、ステップＳ９２において、現時点におけるツリーの評価を、前述したステップＳ５４（図７参照）と同様にして、実行する。そして、次のステップＳ９４では、各クライアントの近傍に、中継先となりうる新たなクライアントが発見されたか否かを判断する。この場合、図５（ｂ）に示されるように、クライアント２Ａと、ビデオ配信サーバ１Ａとの間に、クライアント２Ｃが存在するにもかかわらず、クライアント２Ａがビデオ配信サーバ１Ａに直接接続されていることから、クライアント２Ａにとってクライアント２Ｃは新たな中継先となりうるクライアントである。
【００５４】
したがって、ステップＳ９４の判断が肯定されると、次のステップＳ９６に移行し、クライアント２Ａに対して、近傍クライアント２Ｃへの再接続を要求する。この状態が、図１２（ａ）において、点線矢印（１３）にて示されている。なお、本実施形態では、ビデオ配信サーバ１Ａからクライアント２Ａに対して、クライアント２ＣのＩＰアドレスを送ることは無いものとする。
【００５５】
これに対し、クライアント２Ａでは、図１３のステップＳ１０２において、ビデオ配信サーバ１Ａから再接続要求を受信したか否かを判断し、ここでの判断が肯定されると、次のステップＳ１０４に移行する。このステップＳ１０４では、拡張ＤＮＳサーバ１Ｂに対して、再接続先であるクライアントの情報（ＩＰアドレス）を、拡張ＤＮＳサーバ１Ｂに対して問い合わせる。この状態が、図１２（ａ）において、点線矢印（１４）にて示されている。そして、次のステップＳ１０６において、クライアント情報を、拡張ＤＮＳサーバ１Ｂから受信したか否かを判断し、ここでの判断が肯定されると、ステップＳ１０８において、現在接続中のサーバ又はクライアント（ここでは、ビデオ配信サーバ１Ａ）に対して、切断を通知した後、次のステップＳ１１０に移行する。なお、クライアント２Ａが、再接続先のクライアント情報を拡張ＤＮＳサーバ１Ｂから受信している状態が、図１２（ａ）において、点線矢印（１５）にて示されている。
【００５６】
そして、クライアント２Ａが、次のステップＳ１１０において、受信した再接続先クライアント２Ｃの情報（ＩＰアドレス）に基づいて、クライアント２Ｃと接続されることにより、クライアント２Ｃからクライアント２Ａに対して、ストリーミング画像が転送されることになる（図１２（ｂ）の点線矢印（１６）参照）。
【００５７】
なお、上記においては、ビデオ配信サーバ１Ａからは、クライアント２Ａに対して、再接続先のクライアント２Ｃの情報（ＩＰアドレス）を送信しない場合を前提に説明したが、これに限らず、ビデオ配信サーバ１Ａからクライアント２Ａに対してクライアント２Ｃの情報（ＩＰアドレス）を送信することとしても良い。この場合、図１４（ａ）に示されるように、クライアント２ＡがステップＳ１１２において、クライアント２Ｃへの再接続要求を受信した場合には、次のステップＳ１１４において、現在接続中のサーバ又はクライアント（ここでは、ビデオ配信サーバ１Ａ）に対して切断を通知し、次のステップＳ１１６において、ステップＳ１１２で受信したクライアント情報（ＩＰアドレス）に基づいて、再接続先のクライアントに接続を切り替える。このようにしても、図１３の場合と同様の処理結果を得ることが可能である。
【００５８】
また、ビデオ配信サーバ１Ａが再接続要求を出さずに、クライアント２Ａが自主的に再接続を行うか否かを判断するようにしても良い。具体的には、図１４（ｂ）に示されるように、まず、クライアント２Ａが、ツリー情報の問い合わせをビデオ配信サーバ１Ａに対して行い、ツリー情報を取得する（ステップＳ１２０）。そして、そのツリー情報の中から、近傍に位置するクライアントを探索する（ステップＳ１２２）。次いで、クライアント２Ａは、近傍クライアントを発見したか否かを判断するが（ステップＳ１２４）、ここでの判断が肯定された場合（近傍クライアントが発見された場合）には、現在接続中のサーバ又はクライアント（ここでは、ビデオ配信サーバ１Ａ）に対して切断を通知し（ステップＳ１２６）、近傍クライアントに接続しなおす（ステップＳ１２８）。なお、近傍クライアントが発見されなかった場合は、ステップＳ１２４の判断が否定されるので、再接続を実行すること無く、図１４（ｂ）の全処理を終了する。なお、この図１４（ｂ）の処理については、前述した図１３の処理と同時並行的に実行する（すなわち、再接続の判断を、ビデオ配信サーバ１Ａ側及びクライアント側の両方で行う）こととしても良い。
【００５９】
＜接続終了処理＞
次に、クライアントにおいて、ストリーミング画像の視聴が終了した場合における、接続終了処理について、図１５（ａ）、図１５（ｂ）に基づいて説明する。
【００６０】
まず、クライアントでは、図１５（ａ）のステップＳ１３０において、中継を行っているか否か、すなわち、他のクライアントに対してストリーミング画像を転送しているか否かを判断する。ここで、例えば、判断主体がクライアント２Ａである場合には、クライアント２Ｂに対してストリーミング画像を転送しているので、判断は肯定される。また、例えば、判断主体がクライアント２Ｂである場合には、他のクライアントに転送をしていないので判断は否定される。
【００６１】
ここでの判断が肯定された場合には、ステップＳ１３２に移行して、中継先のクライアント（ストリーミング画像を転送している先のクライアント）に対して、接続を終了する旨を通知し、ステップＳ１３０に戻る。
【００６２】
その後、ステップＳ１３２において通知を受けたクライアントと、通知を送信したクライアントとの間の接続が切断された段階で、ステップＳ１３０の判断は否定され、ステップＳ１３４に移行する。また、初めから中継を行っていなかった場合にも、ステップＳ１３４に移行する。そして、ステップＳ１３４において、クライアント（他のクライアントに画像を中継（転送）していないクライアント）から、ビデオ配信サーバ１Ａに対してビデオ配信停止を通知した段階で、図１５（ａ）の処理が終了する。
【００６３】
これに対し、ビデオ配信サーバ１Ａでは、図１５（ｂ）のステップＳ１４０において、図１５（ａ）のステップＳ１３４の通知を受信したか否かを判断し、ここでの判断が肯定されると、次のステップＳ１４２において、記憶部１８に記憶されているクライアントリストからそのクライアントの情報を削除する。次いで、ステップＳ１４４において、そのクライアントに対するストリーミング画像の送信を停止する。その後は、ビデオ配信サーバ１Ａの電源がオフされるまで、ステップＳ１４０→Ｓ１４２→Ｓ１４４の処理・判断が繰り返される。
【００６４】
以上、詳細に説明したように、本実施形態によると、クライアント（２Ａ〜２Ｄ）から拡張ＤＮＳサーバ１Ｂに対する問い合わせが行われると、拡張ＤＮＳサーバ１Ｂは、ネットワーク３の配信のためのツリー構造の情報に基づいて、ビデオ配信サーバ１Ａ又は現にストリーミング画像を受信しているクライアントの中から、問い合わせを行ったクライアントに対するストリーミング画像の送信に適したものを選択して、その情報を返信する。したがって、本実施形態によると、問い合わせを行ったクライアントを、ツリー構造に基づく適切な中継先（クライアント）に接続させることができる。これにより、例えば、図５（ｂ）に示されるように、ストリーミング画像を受信しているクライアントが４台ある場合でも、ビデオ配信サーバ１Ａから直接画像を受信するクライアントの数を３台にすることができる。このように、ネットワークへの負担が軽減された状態で、ストリーミング画像の配信を行うことができるようになる。
【００６５】
また、本実施形態によると、新たなクライアントが追加されるなどして配信のためのツリー構造が変動しても、そのツリー構造に合わせた適切な受信先を設定することができる。例えば、クライアント２Ａが、ビデオ配信サーバ１Ａに接続され（図４（ａ）参照）、その後に、クライアント２Ｃがビデオ配信サーバ１Ａに接続された場合（図５（ｂ）参照）、クライアント２Ａが、ビデオ配信サーバ１Ａからの再接続要求を受けて、クライアント２Ｃに再接続するようになっているので、例えば、図１２（ｂ）に示されるように、ストリーミング画像を受信しているクライアントが４台ある場合でも、ビデオ配信サーバ１Ａから直接画像を受信するクライアントの数を２台のみにすることができる（すなわち、図５（ｂ）の状態と比較して、ビデオ配信サーバ１Ａから直接画像を受信しているクライアントを１台減少させることができる）。このように、ビデオ配信サーバ１Ａでは、定期的又は不定期で、ツリー構造の変動を監視し、その変動に応じた再接続要求をクライアントに対して出すこととしているので、ネットワークへの負担が極力軽減された状態で、各クライアントへのストリーミング画像の配信を行うことが可能である。
【００６６】
なお、上記実施形態では、ビデオ配信サーバ１Ａと、拡張ＤＮＳサーバ１Ｂとを別々の装置で構成することとしたが、これに限らず、１つのサーバに、ビデオ配信サーバ１Ａ及び拡張ＤＮＳサーバ１Ｂと同一の機能を持たせることとしても良い。
【００６７】
なお、上記実施形態では、経路探索部１４及び近傍探索部１６が、ビデオ配信サーバ１Ａ内に設けられた場合について説明したが、これに限られるものではなく、経路探索部１４及び近傍探索部１６の少なくとも一方が、拡張ＤＮＳサーバ１Ｂ内に設けられても良い。
【００６８】
上述した実施例は本発明の好適な実施の例である。但し、これに限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変形実施可能である。
【図面の簡単な説明】
【００６９】
【図１】一実施形態に係る遠隔診断システムを概略的に示す図である。
【図２】ビデオ配信サーバ、拡張ＤＮＳサーバ、及びクライアントの機能構成を示すブロック図である。
【図３】クライアントの接続開始処理と、拡張ＤＮＳサーバの問い合わせ処理とを示すフローチャートである。
【図４】図３（ａ）、図３（ｂ）の処理の具体例を示す図（その１）である。
【図５】図３（ａ）、図３（ｂ）の処理の具体例を示す図（その２）である。
【図６】ビデオ配信サーバによる配信開始処理、及びクライアントによる転送開始処理を示すフローチャートである。
【図７】ビデオ配信サーバによるツリー評価処理を示すフローチャートである。
【図８】図７の経路探索サブルーチン、及び近傍探索サブルーチンを示すフローチャートである。
【図９】クライアントによるツリー情報送信処理を示すフローチャートである。
【図１０】図９の処理の具体例を示す図である。
【図１１】ビデオ配信サーバによる再接続要求処理を示すフローチャートである。
【図１２】再接続処理の具体例を示す図である。
【図１３】クライアントによる再接続処理を示す図である。
【図１４】再接続処理の変形例を示す図である。
【図１５】クライアントによる接続終了処理、及びビデオ配信サーバによる配信停止処理を示すフローチャートである。
【符号の説明】
【００７０】
１Ａ  ビデオ配信サーバ
１Ｂ  拡張ＤＮＳサーバ
２Ａ〜２Ｄ  クライアント
３  ネットワーク
１００  遠隔診断システム
【図１】
2009071538.tif 000003
【図２】
2009071538.tif 000004
【図３】
2009071538.tif 000005
【図４】
2009071538.tif 000006
【図５】
2009071538.tif 000007
【図６】
2009071538.tif 000008
【図７】
2009071538.tif 000009
【図８】
2009071538.tif 000010
【図９】
2009071538.tif 000011
【図１０】
2009071538.tif 000012
【図１１】
2009071538.tif 000013
【図１２】
2009071538.tif 000014
【図１３】
2009071538.tif 000015
【図１４】
2009071538.tif 000016
【図１５】
2009071538.tif 000017