(57)【特許請求の範囲】
【請求項１】
コンピュータネットワークを介して、所定の撮像手段で撮影されたライブイメージ情報を配信するサーバからの映像を、複数のクライアントに送信させるため、前記サーバとクライアントの間に介在する中継装置であって、
接続されている前記複数のクライアントに映像を分配する為に、前記サーバに対して少なくとも１つのコネクションを作成するコネクション作成手段と、
前記クライアントから映像の要求メッセージを受信するためのメッセージ受信手段と、
上記要求メッセージを解釈するためのメッセージ解釈手段と、
前記クライアントとのコネクションを管理するためのコネクション管理手段と、
前記メッセージ解釈手段で解釈された要求を、前記コネクション作成手段で作成されたコネクションを通じて前記サーバに送信する送信手段と、
前記サーバから受信した映像を格納するバッファと、
前記バッファに取得した映像データを、映像要求を行ったクライアントに分配するための映像分配手段とを有し、
前記映像分配手段は、前記複数のクライアントから略同時に複数の要求を受信した場合には、前記コネクション作成手段で作成された１つのコネクションで得られ、前記バッファに格納している同一の映像データを、前記複数のクライアントに分配するように制御することを特徴とする中継装置。
【請求項２】
前記略同時とは、映像取得要求の処理開始から終了までの経過時間内を示すことを特徴とする請求項第１項に記載の中継装置。
【請求項３】
コンピュータネットワークを介して、所定の撮像手段で撮影されたライブイメージ情報を配信するサーバからの映像を、複数のクライアントに送信させるため、前記サーバとクライアントの間に介在すると共に、バッファを有する中継装置の制御方法であって、
接続されている前記複数のクライアントに映像を分配する為に、前記サーバに対して少なくとも１つのコネクションを作成するコネクション作成工程と、
前記クライアントから映像の要求メッセージを受信するためのメッセージ受信工程と、
上記要求メッセージを解釈するためのメッセージ解釈工程と、
前記クライアントとのコネクションを管理するためのコネクション管理工程と、
前記メッセージ解釈工程で解釈された要求を、前記コネクション作成工程で作成されたコネクションを通じて前記サーバに送信する送信工程と、
該送信工程による送信によって取得した映像データを前記バッファに取得し、映像要求を行ったクライアントに分配するための映像分配工程とを備え、
前記映像分配工程は、前記複数のクライアントから略同時に複数の要求を受信した場合には、前記バッファに格納している同一の映像データを、前記複数のクライアントに分配するように制御することを特徴とする中継装置の制御方法。
【請求項４】
コンピュータが読み込み実行することで、コンピュータネットワークを介して、所定の撮像手段で撮影されたライブイメージ情報を配信するサーバからの映像を、複数のクライアントに送信させるため、前記サーバとクライアントの間に介在すると共に、バッファを有する中継装置として機能するコンピュータプログラムを格納する記憶媒体であって、
接続されている前記複数のクライアントに映像を分配する為に、前記サーバに対して少なくとも１つのコネクションを作成するコネクション作成手段と、
前記クライアントから映像の要求メッセージを受信するためのメッセージ受信手段と、
上記要求メッセージを解釈するためのメッセージ解釈手段と、
前記クライアントとのコネクションを管理するためのコネクション管理手段と、
前記メッセージ解釈手段で解釈された要求を、前記コネクション作成手段で作成されたコネクションを通じて前記サーバに送信する送信手段と、
該送信手段による送信によって取得した映像データを前記バッファに取得し、映像要求を行ったクライアントに分配するための映像分配手段とを備え、
前記影像分配手段は、前記複数のクライアントから略同時に複数の要求を受信した場合には、前記コネクション作成手段で作成された１つのコネクションで得られ、前記バッファに格納している同一の映像データを、前記複数のクライアントに分配する
として機能するコンピュータプログラムを格納することを特徴とする記憶媒体。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は中継装置及びその制御方法及び記憶媒体、詳しくはネットワーク上にあるサーバからクライアントに対して情報サービスを行わせる中継装置及びその制御方法及び記憶媒体に関するものである。
【０００２】
【従来の技術】
近年のインターネットおよびイントラネット環境の高速化・広帯域化に伴い、従来テキストデータのみを対象としていたネットワーク・アプリケーション（コンピュータネットワークをプラットフォームとするアプリケーションプログラムのこと）は、より複雑な構造をもち大容量を要求する映像・音声などのマルチメディアデータをあつかうようになってきている。
【０００３】
このような流れのなかで、本願出願人は、遠隔地に設置されたサーバプログラムが、ネットワークを介して利用者にビデオやビデオカメラの映像を静止画や動画の形で提供するというネットワークアプリケーションを提案してきた。
【０００４】
以下、上記のようなネットワークアプリケーションのことを、ここでは「映像配信システム」と呼ぶことにする。
【０００５】
一方、Ｎｅｓｃａｐｅ  Ｎａｖｉｇａｔｏｒ(米国Netscape社.)，Ｉｎｔｅｒｎｅｔ  Ｅｘｐｌｏｒｅｒ(米国Microsoft社)などのＷｏｒｌｄ  Ｗｉｄｅ  Ｗｅｂブラウザ（以下、Ｗｅｂブラウザ、或いは単にブラウザという）の普及により、従来の単なるコミュニケーションの手段としてＥ−ｍａｉｌ，ｎｅｗｓ，ｆｔｐなどにしか利用されなかったコンピュータネットワークは、情報収集、物品の購入共同作業などの、よりさまざまな活動の場として展開しつつある。
【０００６】
このような流れにおいてＷｅｂブラウザは、単なるマルチメディア情報表示ツールとして利用されるだけではなく、よりさまざまな利用形態に応えることのできる汎用的な統合ユーザインタフェースを提供するべく改良されつつある。現在のＨＴＭＬ，ＨＴＴＰ，ＪａｖａＳｃｒｉｐｔ，Ｊａｖａなどの導入および機能強化の急速な進行がこのことを示している。
【０００７】
【発明が解決しようとする課題】
さて、上記のようなＷｅｂブラウザの発展は、映像配信システムをもＷｅｂシステムに取り込み、Ｗｅｂブラウザから利用できるようにしたいという要望を生み出している。
【０００８】
しかし、これまで出願人が提案しているものは、映像配信システムは専用のクライアントアプリケーションプログラム（映像表示クライアントと呼ぶ）を利用するものであって、Ｗｅｂブラウザからその専用映像表示クライアントを起動するものであった。従って、Ｗｅｂブラウザと統合化されたものとは言えない。
【０００９】
また、Ｐｌｕｇ−ｉｎモジュールなどの技術を利用して、見かけ上Ｗｅｂブラウザに上記の映像表示クライアントを組み込むことも可能である。しかし、これも内部的には独立したプログラムであることにかわりはなく、Ｗｅｂブラウザが本来持つべきユーザインタフェースのデザインの自由度の高さを生かすことはできない。ホームページのデザイナーからみれば、映像クライアントのルック＆フィールやユーザインタフェースさえも自分の好みや目的にあわせてものに変更することができるべきであるが、この要求は満足されていない。
【００１０】
このような状況から、Ｊａｖａ（米国サンマイクロ社提供）あるいはＪａｖａＳｃｒｉｐｔなどのＷｅｂブラウザの拡張言語から利用可能な、あるいは、その言語を使用して作成することができるような、Ｗｅｂブラウザと統合化された映像表示クライアントの必要性が浮かび上がってくる。
【００１１】
しかしながら、上記の要求を演たすためには以下の問題を解決しなければならない。
【００１２】
１．通信形態の差異の吸収
２．実行効率低下の防止
３．映像配信形態の差異吸収
以下、これらにつき、説明する。
【００１３】
＜１．通信形態の差異の吸収＞
Ｗｅｂブラウザの基本動作は、Ｗｅｂサーバにファイル取得要求メッセージを送信し、そのリプライとして受け取ったデータを表示することであり、Ｗｅｂブラウザ（クライアント）側の要求と１：１に対応する形でデータが送られてくることが前提となっている。また、ＷｅｂブラウザはＷｅｂサーバへの要求ごとに通信路（コネクションとよぶ）を形成しなければならない。
【００１４】
これに対し、映像配信システムではサーバとクライアントは最初にコネクションを形成し、以降はサーバから一方的に映像情報が送信されてくるという方式で動作する。上記２つの通信形態にはこのような差異があるので、この差異を解消するために、一方の方式からもう一方の方式への仲介を行う手段が必要である。
【００１５】
＜２．実行効率低下の防止＞
専用の映像表示クライアントにくらべ、Ｗｅｂブラウザに映像表示クライアント（Ｗｅｂ版映像クライアント）を統合すると、映像表示機能やその他の実行効率が低下することが予想される。
【００１６】
なぜならば、専用クライアントはターゲットとするデータ構造や映像配信プロトコルに特化し専用の最適化を行うことが容易だが、Ｗｅｂ版クライアントはＷｅｂブラウザが提供する汎用のデータ処理機構とデータ表示機能を使用しなければならない。にもかかわらず、Ｗｅｂ版クライアントは専用クライアントにくらべダウンロードやインストール作業が不要など手軽に利用できるため、専用クライアントより多くのユーザに利用されることが予想される。性能が低いＷｅｂ版クライアントは映像配信システム全体の評価を落とすことになりかねない。このため、実行効率の低下を防止する手段の導入が要求される。
【００１７】
＜３．映像配信形態の差異吸収＞
Ｗｅｂ版映像クライアントに対する要請として上記１と２が満たされた上で、さらに、Ｗｅｂ版映像クライアントは特定の映像配信システムや映像配信方式から独立であることが望ましい。なぜならば、ＪａｖａやＪａｖａＳｃｒｉｐｔを用いたＷｅｂ版映像クライアントは、ビューワ部分（映像表示部分）がＷｅｂブラウザ上に共通ユーザインタフェースとして実現されるので、通常の画像データがＧＩＦ，ＪＰＥＧ等のデータ形式を意識することなく表示できるように、映像情報も映像を配信するサーバ（映像サーバ）の種類の違いを意識すること無くサービスを利用することができるべきである。この要求に応えるためには、さまざまな映像配信形態や方式の差異に対応する手段が必要となる。
【００１８】
【課題を解決するための手段】
本発明は上記課題に鑑みなされたものであり、上記の課題の全て或いは少なくとも１つを解決し、独自の通信形態でもって情報をサービスするサーバと、汎用ネットワーク上でのサービスを受けるクライアント間とを効率良く且つ簡単な構成で情報伝達を行わせることを可能にする中継装置及びその制御方法及び記憶媒体を提供しようとするものである。
【００１９】
この課題を解決するため、例えば本発明の中継装置は以下に示す構成を備える。すなわち、
コンピュータネットワークを介して、所定の撮像手段で撮影されたライブイメージ情報を配信するサーバからの映像を、複数のクライアントに送信させるため、前記サーバとクライアントの間に介在する中継装置であって、
接続されている前記複数のクライアントに映像を分配する為に、前記サーバに対して少なくとも１つのコネクションを作成するコネクション作成手段と、
前記クライアントから映像の要求メッセージを受信するためのメッセージ受信手段と、
上記要求メッセージを解釈するためのメッセージ解釈手段と、
前記クライアントとのコネクションを管理するためのコネクション管理手段と、
前記メッセージ解釈手段で解釈された要求を、前記コネクション作成手段で作成されたコネクションを通じて前記サーバに送信する送信手段と、
前記サーバから受信した映像を格納するバッファと、
前記バッファに取得した映像データを、映像要求を行ったクライアントに分配するための映像分配手段とを有し、
前記映像分配手段は、前記複数のクライアントから略同時に複数の要求を受信した場合には、前記コネクション作成手段で作成された１つのコネクションで得られ、前記バッファに格納している同一の映像データを、前記複数のクライアントに分配するように制御することを特徴とする。
【００２０】
【発明の実施の形態】
以下、添付図面に従って本発明に係る実施形態の一例を詳細に説明する。
【００２１】
先ず、詳細を説明する前に、本実施形態における概要を以下に説明する。
【００２２】
実施形態では、先に説明した３つの課題に対し以下の機能手段を備えることでこれを解決する。
【００２３】
−専用クライアントの機能を代理実行する手段
−上記代理実行手段を効率よく実行可能にする手段（効率化手段）
−複数種類の映像配信方式に対応するための配信方式切り替え・実行手段
上記各手段をより細分化して示せば、以下の通りとなる。
【００２４】
＜代理実行手段＞
他のプログラムからのメッセージを送受信するためのメッセージ送受信手段と、
上記メッセージを解釈するためのメッセージ解釈手段と、
クライアントとのコネクションを管理するためのコネクション管理手段を備える。
【００２５】
＜効率化手段＞
映像サーバから取得した映像データを、複数のクライアントに分配するための映像分配手段と、
映像サーバから得たサーバの状態などの各種情報を、複数のクライアントに分配するための情報分配手段を備える。
【００２６】
＜配信方式切り替え・実行手段＞
映像サーバに合わせて要求メッセージやリプライの方式を切り替えるための配信方式切り替え手段と、
映像サーバにあわせて要求メッセージやリプライを実行する配信方式実行手段とを備える。
【００２７】
以下、上記各手段を実現する例を説明する。
【００２８】
尚、実施形態では、各構成要素を映像サーバ、映像クライアントとは独立なサーバクライアントとして実装する例について説明する。この独立したサーバプログラム（サーバ装置上で動作するプログラム）をここでは「変換サーバ」と呼ぶ。
【００２９】
まず、変換サーバの動作概要を図２を用いて説明する。映像サーバ２０１〜２０３は、例えばパーソナルコンピュータ等の汎用装置上で動作するプログラムであり、その装置にはビデオ情報を蓄積した記憶装置やライブ映像を取得するためのビデオカメラが設置されている。そして、要求があれば映像情報をネットワーク２０７に配信する。また映像クライアント２０４〜２０６もパーソナルコンピュータ等の装置上で操作するものであり、ユーザによって起動されることでクライアントとして機能し、映像データを受信して表示することになる。
【００３０】
本願出願人がこれまで提案している映像配信システムでは、この映像サーバと映像クライアントがネットワーク２０７を介して通信を行うことによってサービスを行うものであった。たとえば映像クライアント２０４が映像サーバ２０１とコネクションを作成し映像取得要求メッセージを送信すると、映像サーバ２０１は映像クライアント２０４への映像データの送信を開始し、映像クライアント２０４では受信した映像データをディスプレイ等に表示する。
【００３１】
本実施形態ではさらに変換サーバ２０８をその間に設置する。変換サーバ２０８は映像サーバ２０１〜２０３からネットワーク２０７を経由して送信されてくる映像データをＨＴＴＰメッセージ（ＨＴＴＰについてはＲＦＣ１９４５に詳しい）に変換してからユーザが使用している映像クライアント２０４，２０５，２０６のいずれか、もしくは全部に送信する。
【００３２】
さて、変換サーバ２０８の導入により本実施形態の基本的な動作は次のようになる。
【００３３】
まず、映像クライアント２０４による映像取得要求は映像サーバ２０１ではなく変換サーバ２０８に対して送信される。この映像取得メッセージはＨＴＴＰメッセージの形式で送信されてくる。変換サーバ２０８はこのＨＴＴＰメッセージを映像サーバ２０１独自のメッセージ形式に変換する。変換された映像取得メッセージは映像サーバ２０１に転送され、映像サーバは要求に応じた処理を行う。たとえばＶＤＯＬｉｖｅなら映像ストリームを開始し、ＷｅｂＶｉｅｗ／Ｌｉｖｅｓｃｏｐｅ（キヤノン株式会社の商標、以下略）なら映像データを１フレーム分だけ送信する、などである。
【００３４】
映像サーバでの処理の結果はＭｏｔｉｏｎ  ＪＰＥＧやＭＰＥＧなどのデータ形式で変換サーバ２０８に送信されてくる。変換サーバ２０８は映像データをＨＴＴＰメッセージに変換して映像クライアント２０４に送り返す。ここでＨＴＴＰへの変換とは元のデータにデータの型，サイズ，日付などの情報を付加することにより行われる。
【００３５】
では、図１を用いて変換サーバの各構成要素について説明する。
【００３６】
図示では、３台のコンピュータ１０１，１０２，１０３が存在し、それぞれ変換サーバ、映像サーバ、映像クライアントがそれ上で動作している。これらのコンピュータ１０１，１０２，１０３はネットワーク１０４で接続されており相互にメッセージを送受信することが可能である。尚、図では映像クライアント及び映像サーバが１つだけしか書かれていないが、図２で示したように実際は複数の映像クライアント、映像サーバを組み合わせて運用することになるし、その数によって本願発明が限定されるものではない。
【００３７】
コンピュータ１０１にはハードディスク１０８等の二次記憶装置が設置されており、変換サーバのバイナリイメージを記録している。またコンピュータ１０１内部には変換サーバの処理を実際に行うＣＰＵ１０５と変換サーバ１０９の実行イメージ（プログラムコード及びそれに使用される各種データやテーブル等）を保持するメインメモリ１０７が存在し、これらはバス１０６で結合されている。
【００３８】
変換サーバ１０９は内部的に以下に列挙するソフトウェアモジュール群で構成されている。ただし、ここで言うソフトウェアモジュールとはＣやＣ＋＋などのプログラム言語で作成された一群のデータや手続き・関数の集まりのことを指す。ソフトウェアモジュールには他のソフトウェアモジュールと協調動作するためのインタフェースとなる関数ないし手続きが用意されている。ここではこの関数ないし手続きのことを「エントリポイント」と呼ぶ。ソフトウェアモジュールが他のモジュールを呼び出すためには、呼び出し対象となるモジュールのエントリポイントのメモリ上のアドレスをなんらかの方法で取得する必要がある。通常、エントリポイントのアドレス情報はコンパイルやリンク時に得ることができる。）
−メッセージ送受信部１１０
−メッセージ解釈部１１１
−クライアントセッション管理部１１２
−サーバ情報管理部１１３
【００３９】
さらに、変換サーバ１０９内には通信相手となる映像サーバの種類に対応した「対サーバ処理モジュール」１１４が存在する。図においては対サーバ処理モジュール１１４は１つしか書かれていないが、実際は複数の対サーバ処理モジュールを保持することが可能である。
【００４０】
対サーバ処理モジュール１１４は、通信相手である映像サーバ固有の通信方式やメッセージ形式に関する処理を行う。対サーバ処理モジュール１１４はさらに以下のサブ・モジュールから構成される。
−サーバセッション管理部１１５
−情報取得・分配部１１６
−映像取得・分配部１１７
−対サーバメッセージ送受信部１１８
以下、１１０から１１８までのモジュールおよびサブモジュールの概要を説明する。
【００４１】
［メッセージ送受信部１１０］
映像サーバ１０２および映像クライアント１０３からネットワーク１０４を介して送信されてくるメッセージを受信する手段を他のモジュールおよびサブモジュールに提供する。また逆に、返答（リプライ）メッセージなどのメッセージを映像サーバ１０２や映像クライアント１０３に送信する手段を他のモジュールおよびサブモジュールに提供する。
【００４２】
メッセージ送受信部の実現はｓｏｃｋｅｔ等を使用するＴＣＰ，ＵＤＰなどの一般的なプロセス間通信機構を利用することで可能である。ただし、映像サーバの種類によってはＲＴＰなど特殊な通信方式や通信プロトコルを必要とするものがある。このような映像サーバに対しては、対サーバ処理モジュール１１４内に専用の対サーバメッセージ送受信部１１８を追加し、こちらの機構を使用する。メッセージ送受信部１１０は映像クライアント１０３との通信や、特殊な通信方式を必要としない映像サーバとの通信に使用される。
【００４３】
ただし、現在のＷｅｂブラウザはＴＣＰ上のＨＴＴＰによる通信を基本としているが、将来的には異なる通信方式を採用する可能性もある。このような状況になった場合は、映像クライアントの種類に応じた「対クライアントメッセージ送受信部」を用意すればよい。対クライアントメッセージ送受信部の実現および制御方法には対サーバメッセージ送受信部と同じ方法を適用することができる。
【００４４】
［メッセージ解釈部１１１］
映像クライアントから送信されてきた各種メッセージ（以降では要求あるいは要求メッセージと呼ぶ）を解釈し、他のモジュールに処理を指示する。要求メッセージには要求の種類を識別するためのメッセージＩＤが付加されている。メッセージ解釈部１１１で解釈することのできるメッセージには以下のようなものがある。
−セッションの開始要求
−セッションの終了要求
−映像取得要求
−情報取得要求
各要求の詳細については後述する。
【００４５】
［クライアントセッション管理部１１２］
クライアントセッション管理部１１２は、先に説明した「通信形態の差異吸収」の手段を提供する。具体的には、一回ごとに切断されてしまう映像クライアント１０３とのコネクションと、サービス終了まで持続する映像サーバ１０２とのコネクションを対応づけるために、各映像クライアントと変換サーバ間の最初のコネクション形成時に、そのクライアントに一意なＩＤ番号を割り当てる。以降、映像クライアントが変換サーバ１０１に要求を送る時に、このＩＤ番号（コネクションＩＤとよぶ）を要求に付加することで、映像クライアントと変換サーバ間のコネクションは一回ごとに切断されてしまっても、映像データを送信する映像サーバとその映像データを受信する映像クライアントとの対応関係を維持することを可能にする。このコネクションＩＤは映像クライアント１０３と変換サーバ１０１間で持続する仮想的なコネクションとみなす事ができる。この仮想的なコネクションのことをセッションと呼ぶことにする。
【００４６】
上記の処理は、コネクションＩＤと対応する映像サーバとの対応関係を表などの形で管理することで容易に実現可能である。
【００４７】
［サーバ情報管理部１１３］
サーバ情報管理部１１３は対サーバ処理モジュール１１４へのエントリポイントの管理を行なうモジュールである。たとえば、映像クライアント１０３からのセッション開始要求に対し、その要求に付加される映像サーバの種類（タイプ）情報をキーとして、必要な対サーバ処理モジュールのエントリポイントを検索する。このようにして得られた対サーバ処理モジュールに制御が渡され、セッション開始処理などの実際の処理を実行する。
【００４８】
サーバ情報管理部１１３における上記の処理は、映像サーバの種類（タイプ）情報（例えばＷｅｂＶｉｅｗ／Ｌｉｖｅｓｃｏｐｅ  Ｖｅｒ１．１０などの文字列）をキーとし、対サーバ管理モジュールヘのエントリポイントを値とするテーブル（表）を用いて実現することが可能である。
【００４９】
また、動的リンク手段を提供するＯＳ上に変換サーバを実現した場合は、対サーバ処理モジュールを変換サーバとは別のファイルとして提供し、変換サーバの起動時に必要な対サーバ処理モジュールを自動的に読み込むようにすることも考えられる。この機能もサーバ情報管理部１１３が担当する。ただし、この処理は本発明において必須な処理ではない。本実施形態では、必要な対サーバ処理モジュールはあらかじめ変換サーバに組み込まれているものとして説明する。
【００５０】
［サーバセッション管理部１１５］
サーバセッション管理部１１５は映像クライアント１０３からのセッション開始要求および終了要求を変換サーバ１０９が受け取ったとき、映像取得の対象となる映像サーバ（図１では１０２）独自のセッション開始および終了要求メッセージを作成し、映像サーバとのセッション開始・終了処理を実行する。
【００５１】
ただし、サーバセッション管理部１１５は複数の映像クライアントから同一映像サーバに対してのセッション開始要求があっても、１つしか映像サーバとのコネクション（以降この映像サーバとのコネクションのことをサーバセッションと呼ぶ）を作成しない。このためサーバセッション管理部１１５はセッション開始要求を受け取ると、まず要求された映像サーバとのサーバセッションがすでに生成済みであるかを確認し、生成されていない場合のみ新たに映像サーバとのサーバセッションを作成する。
【００５２】
尚、複数のクライアントから１つの映像サーバに対する映像転送要求があった場合、本変換サーバがその仲介を行ない、映像サーバからの映像データをそれぞれのクライアントに対して送信することになる。
【００５３】
［映像取得・分配部１１７］
映像クライアント１０３からの映像取得要求を受け取ると，映像取得・分配部１１７は映像サーバ１０２独自の映像取得要求を発行し、最新の映像データを取得する。ただし、映像サーバが定期的に映像情報を送信してくるタイプのものならば、映像取得要求を発行することなく最新の映像データを取得する。
【００５４】
取得した映像データは映像取得・分配部１１７内の映像バッファに置かれる。この映像バッファ内に映像データを置く事により、「ほぼ同時」に変換サーバ１０９に到着した複数の映像クライアントからの映像取得要求に対しては、バッファ内の映像を返送することで、映像サーバとの通信回数を滅らして実行効率をアップすることが可能となる。
【００５５】
ここで、「ほぼ同時」の処理方法としては、
−一定時間内に到着した要求は同時とみなす
−映像取得要求の処理開始から終了までの経過時間内に到着してすべての要求を同時とみなす
などの方式がある。本実施形態で採用した方式については後述する。
【００５６】
［情報取得・分配部１１６］
本願出願人が提案している、これまでのカメラによる撮影された映像サービスを行なう映像サーバは、映像を取得するだけでなく映像サーバの状態やネットワーク１０４の状態に関する情報を取得するための手段を提供している。映像クライアントは必要な情報を取得するための情報取得要求を映像サーバに発行することによって情報を得ることができる。
【００５７】
また、映像サーバの種類によっては、サーバの状態を映像クライアントの要求がなくても自動的に通知する機能をもっているものがある。例えばＷｅｂＶｉｅｗ／Ｌｉｖｅｓｃｏｐｅでは遠隔地のビデオカメラの操作が可能なので、カメラの向きやズーム倍率が変化すると、その旨を自動的に全ての映像クライアントに通知する。このようなサーバ情報あるいは通知情報は、複数の映像クライアントに共通な情報なので、映像データと同様なバッファリングを行なう。
【００５８】
映像所得・分配部は映像サーバからのサーバ情報および通知情報の取得とバッファリングによる分配処理を行なう。特に、通知機能を持つ映像サーバに対しては、一度バッファにおかれた情報は、新たな変更が映像サーバから通知されるまで有効なので、その間に行なわれた映像クライアントからの情報問い合わせ処理は映像サーバに問い合わせる必要がなく非常に高速に実行することが可能である。
【００５９】
［対サーバメッセージ送受信部１１８］
前述したように特定のサーバ特有の送受信モジュールである。機能的にはサーバメッセージ送受信部１１０と同じである。また、専用の送受信モジュールを必要としない対サーバ処理モジュール１１４では対サーバメッセージ送受信部１１８は単にサーバメッセージ送受信部１１０の機能を呼び出すだけのモジュールとして実装される。
【００６０】
では次に、映像クライアント１０３と変換サーバ１０９間の通信プロトコルについて簡単に説明する。映像クライアント１０３は以下の要求を変換サーバ１０９に送信し、必要な処理を行わせることができる。
・セッション操作関連
OpenCameraServer
CloseCameraServer
・画像の取得
GetLiveImage
・情報の取得
GetNotice
GetVideoInfo
・カメラの操作
OperateCamera
GetCameraControl
GetCameraInfo
【００６１】
各要求はＨＴＴＰ１．０をベースとしており、以下のようなＵＲＬ(Universal Resource Locator)形式のデータから生成されるＧＥＴコマンドとして変換サーバに送信されてくる（ＨＴＴＰ１．０，ＵＲＬおよびＵＲＬからＧＥＴコマンドヘの変換についてはＲＦＣ１９４５に詳しい）。
【００６２】
本実施形態では、かならずしもＨＴＴＰを映像クライアントと変換サーバ間のプロトコルとして使用しなければならないわけではない。独自のメッセージ方式やプロトコルを用いてもよい。ただし、その場合、映像クライアントをＷｅｂビューワの標準的に用意している機構では実現できない可能性があるので注意が必要である。ＦＴＰやＳＭＴＰ等では上記の問題はないのでＨＴＴＰの代わりに使用する事ができる。この場合も、必要な処理は以下で説明する方式とまったく同じ方法で実現することが可能である。以下では、各要求の概要とＵＲＬでの書式および要求に対するリプライの形式を挙げておく。
【００６３】
・ＯｐｅｎＣａｍｅｒａＳｅｖｅｒ
［概要］映像サーバとのセッションを開始する。
［書式］
0003733218.tif 000002
映像サーバの情報が上記の情報（映像サーバのホスト名，ポート番号，映像サーバの種類）以外にも必要ならば、以下の形式で任意の情報を付加して良い。
＜付加情報の名前＞＝＜付加情報の値〉
−例−
cc_host＝＜カメラ制御サーバのホスト名＞
［リプライ］処理に成功するとコネクションＩＤが以下の形式で映像クライアントに返送される。
ＨＴＴＰ／１．０  ２００  ＯＫ
＜データの種類，日付，データのサイズなどの付加情報＞
connection_id＝＜コネクションＩＤ＞
【００６４】
・ＣｌｏｓｅＣａｍｅｒａＳｅｒｖｅｒ
［概要］映像サーバとのセッションを終了する。
［書式］
0003733218.tif 000003
［リプライ］処理に成功すると文字列“ＯＫ”が返される。
【００６５】
・ＧｅｔＬｉｖｅＩｍａｇｅ
［概要］映像の取得を要求する。
［書式］
0003733218.tif 000004
ｆｒａｍｅ＿ｃｏｕｎｔには１以上の整数を指定できる。クライアントは指定したフレーム数分の映像データを受け取ることができる。
【００６６】
［リプライ］ｆｒａｍｅ＿ｃｏｕｎｔで指定したフレーム分の映像データが返される。ただしフレーム数が１のときと２の時ではリプライの形式が多少異なる。これは、２枚以上の映像データを送信する場合は、Ｓｅｒｖｅｒｐｕｓｈ形式（詳しくはＲＦＣ１９４５）でデータを送信するためである。
【００６７】
Ａ．フレーム数１の場合
ＨＴＴＰ／１．０  ２００  ＯＫ
＜データの種類，日付，データのサイズなどの付加情報＞
＜映像情報＞
Ｂ．フレーム数２以上の場合
0003733218.tif 000005
【００６８】
・ＧｅｔＮｏｔｉｃｅ
［概要］映像サーバからの最新の通知内容を取得する。
［書式］
0003733218.tif 000006
［リプライ］サーバセッションの相手である映像サーバが自動的に通知メッセージを送信する機能を持っている場合のみ、以下の形式のリプライを得ることができる。
0003733218.tif 000007
たとえば、ＷｅｂＶｉｅｗ／Ｌｉｖｅｓｃｏｐｅでは、映像サーバからビデオカメラの向きの変更が通知されるので以下のようなリプライを得ることが可能である。
0003733218.tif 000008
このように得られる情報は映像サーバの種類によって異なる。
【００６９】
・ＧｅｔＶｉｄｅｏＩｎｆｏ
［概要］映像関連情報を取得する
［書式］
0003733218.tif 000009
［リプライ］映像サーバの種類により得られる情報の種類は異なるが以下の形式で情報が返されてくる。
0003733218.tif 000010
【００７１】
・ＧｅｔＣａｍｅｒａＩｎｆｏ
［概要］ビデオカメラ関連情報を取得する。
［書式］
0003733218.tif 000011
［リプライ］ビデオカメラを操作可能な映像サーバの場合のみ以下の形式のリプライを得ることができる。
0003733218.tif 000012
【００７２】
たとえば、ＷｅｂＶｉｅｗ／Ｌｉｖｅｓｃｏｐｅでは、映像サーバからビデオカメラの向きの変更が通知されるので以下のようなリプライを得ることができる。
【００７３】
0003733218.tif 000013
【００７４】
・ＧｅｔＣａｍｅｒａＣｏｎｔｒｏｌ
［概要］カメラの制御権を要求する。
［書式］
0003733218.tif 000014
［リプライ］ビデオカメラを操作可能な映像サーバの場合のみ文字列ＯＫを受け取ることができる。
【００７５】
・ＯｐｅｒａｔｅＣａｍｅｒａ
［概要］ビデオカメラの操作を要求する。
［書式］
0003733218.tif 000015
［リプライ］ビデオカメラを操作可能な映像サーバの場合のみ文字列ＯＫを受け取ることができる。
【００７６】
では、以下で上記の要求群による映像クライアントと変換サーバ間のセッションの開始から終了までの流れを説明する。映像クライアントと変換サーバ間のセッションの開始から終了までの流れは以下の５つのフェーズに分割することができる。
【００７７】
１．セッションの開始
２．映像の所得
３．情報の取得
４．カメラ操作
５．セッションの終了
ただし、４番目の「カメラ操作」はＷｅｂＶｉｅｗ／Ｌｉｖｅｓｃｏｐｅなどカメラ操作が可能な映像サーバとのセッションでのみ使用可能である。
【００７８】
１．セッションの開始
映像クライアントがＯｐｅｎＣａｍｅｒａＳｅｒｖｅｒ要求を変換サーバに送信することで映像サーバとのセッションが開始される。ＯｐｅｎＣａｍｅｒａＳｅｒｖｅｒの返答として、映像クライアントに割り当てられたコネクションＩＤが返されてくる。コネクションＩＤは以降の全ての要求に使用される。
【００７９】
２．映像の取得
映像クライアントがＧｅｔＬｉｖｅＩｍａｇｅ要求を変換サーバに送信することでリプライとして映像データを得る事ができる。
【００８０】
３．情報の取得
映像クライアントがＧｅｔＶｉｄｅｏＩｎｆｏ要求を変換サーバに送信することで、リプライとして映像のサイズやフレームレートなどの情報を取得することができる。
【００８１】
４．カメラ操作
カメラ操作は以下の手順で行なわれる。まず、映像クライアントがＧｅｔＣａｍｅｒａＣｏｎｔｒｏｌ要求でカメラの操作権を要求する。操作権を得る事ができたら、映像クライアントがＯｐｅｒａｔｅＣａｍｅｒａ要求を変換サーバに送り、カメラを操作することができる。
【００８２】
尚、操作権、すなわち、カメラのアングル（パン角、チルト角、ズーム倍率等）を変更できる権利を有するのは、１台のカメラ（映像サーバに複数カメラが接続されている場合もある）につき一人のクライアントのみであり、この権利の与え方は既に本願出願人がいくつか提案している。ここでは、最初に接続したクライアントに対して優先的に所定時間だけ操作権を与えるものとする。
【００８３】
５．セッションの終了
映像クライアントがＣｌｏｓｅＣａｍｅｒａＳｅｒｖｅｒ要求を変換サーバに送信すると、変換サーバはそのクライアントが利用していた映像サーバとのセッションを終了し、使用されていたコネクションＩＤを無効にする。映像クライアントが再び映像データを取得するためには、新たにＯｐｅｎＣａｍｅｒａＳｅｒｖｅｒ要求を発行してセッションを作成しなければならない。
【００８４】
では、次にこれら変換サーバの基本的な動作状況における、各構成要素の挙動について説明する。
【００８５】
１．セッションの開始
まずセッションの開始処理について動作概念図である図３と、その動作手順を示す図７のフローチャートを用いて説明する。
【００８６】
映像クライアント３０３によってセッション開始要求（ＯｐｅｎＣａｍｅｒａＳｅｒｖｅｒ，３１９）が送信され、メッセージ送受信部３１０によって受信されると（ステップＳ７０１）、受信された要求はメッセージ解釈部３１１に転送される（ステップＳ７０２）。メッセージ解釈部３１１は転送されたセッション開始要求３２０からメッセージＩＤを取り出す（ステップＳ７０３）。
【００８７】
本実施形態でのメッセージＩＤは要求からパラメータの部分を削除した要求名の部分である。セッション開始要求ではメッセージＩＤは“ＯｐｅｎＣａｍｅｒａＳｅｒｖｅｒ”という文字列となる。メッセージ解釈部３１１は、予めハードディスク等に記憶されているメッセージ群と、受信したメッセージ名とを照合し、どの要求が送信されてきたかを調べる。その結果、セッション開始要求ではなかった場合（ステップＳ７０４）、他の要求に対する処理が実行される（ステップＳ７０５）。
【００８８】
セッション開始要求であった場合（ステップＳ７０４）、セッション開始要求からパラメータとして付加されているサーバのタイプ、ホスト名、ポート番号を抽出する。ここで、特定の映像サーバ特有の付加情報が追加されている場合は、その部分もパラメータ名と値の対として抽出する（ステップＳ７０６）。
【００８９】
次にメッセージ解釈部３１１はクライアントセッション管理部３１２にセッション開始指示（３２１）を発行する（ステップＳ７０７）。セッション開始要求には先ほど抽出したパラメータも付加される。ここでセッション開始指示（３２１）の実体は、Ｃ＋＋などのオブジェクト指向言語におけるメッセージによって実現されているものとする。
【００９０】
クライアントセッション管理部３１２はセッション開始指示（３２１）を受け取ると、まず映像クライアント３０３のためにコネクションＩＤを割り当てる（ステップＳ７０８）。このコネクションＩＤには１以上の整数が使用され、割り当てごとにその値がインクリメントされる（一意に決定できるのであれば他の手法を採用しても構わない）。割り当てられたコネクションＩＤはメッセージ送受信部３１０を介して映像クライアントに送信される（ステップＳ７０９）。さらにクライアントセッション管理部３１２は、サーバ情報管理部３１３に対サーバ処理モジュール取得指示（３２２）を発行する（ステップＳ７１０）。
【００９１】
サーバ情報管理部３１３では、対サーバ処理モジュール取得指示（３２２）に付加されるサーバのタイプ情報をキーとして対サーバ処理モジュールを予め記憶装置に記憶されているテーブルから検索する（ステップＳ７１１）。検索の結果得られた対サーバ処理モジュールのエントリポイントは対サーバ処理モジュール取得指示のリプライ（３２３）としてクライアントセッション管理部３１２に通知される。
【００９２】
次にクライアントセッション管理部３１２は、得られた対サーバ処理モジュール３１４のエントリポイントを介してサーバセッション管理部３１５にサーバとのセッション作成指示（サーバセッション開始指示、３２４）を発行する。このサーバセッション作成指示（３２４）を受け取ったサーバセッション管理モジュール３１５は、指示（３２４）に付加されているホスト名とポート番号及びその他特有の付加情報を取り出し、これらの情報をキーとして内部の管理テーブルを検索して、すでにサーバとのセッションが作成済みか否かをチェックする。セッションがすでに作成済みならば（ステップＳ７１３）、サーバセッション管理モジュール３１５は、そのセッション（正確にはそのセッションをあらわすデータ構造）のアドレスをクライアントセッション管理部３１２に返送する。クライアントセッション管理部３１２は得られたセッション情報を、クライアントセッション管理部３２４内部の管理テーブルのコネクションＩＤをキーとするエントリに追加する（ステップＳ７１４）。
【００９３】
また、セッションが作成されていない場合（ステップＳ７１３）。サーバセッション管理部３１５は対サーバメッセージ送受信部３１６を利用して、映像サーバ３０２とのコネクションの生成と（ステップＳ７１５）、映像サーバ３０２へのセッション開始要求メッセージ（３２７）の送信などのサーバセッション開始処理を実行する（ステップＳ７１６）。映像サーバ３０２とのセッションが開始されると、そのセッションに関する情報（ｓｏｃｋｅｔなど映像サーバとの通信に必要な情報が主である）を集めてサーバセッション情報を作成し、クライアントセッション管理部３２４に送り返す。クライアントセッション管理部３１２は内部の管理テーブルのコネクションＩＤをキーとするエントリーに返送されてきたセッション情報を追加する（ステップＳ７１４）。
【００９４】
以上で、セッションの開始処理は完了である。
【００９５】
＜２．セッションの終了＞
次にセッションの終了処理について図４と図８を用いて説明する。
【００９６】
映像クライアント４０３によってセッション終了要求（ＣｌｏｓｅＣａｍｅｒａＳｅｒｖｅｒ、４１９）が発行され、メッセージ送受信部４１０によって受信されると（ステップＳ８０１）、受信された要求はメッセージ解釈部４１１に転送される（ステップＳ８０２）。メッセージ解釈部４１１は転送されたセッション終了要求（４２０）からメッセージＩＤを取り出す。メッセージ解釈部４１１はメッセージ名を各要求のメッセージ名と照合し、どの要求が送信されてきたかを調べる（ステップＳ８０３）。その結果、セッション開始要求ではなかった場合（ステップＳ８０４）、他の要求に対する処理が実行される（ステップＳ８０５）。
【００９７】
セッション終了要求であった場合（ステップＳ８０４）。セッション終了要求からパラメータとして付加されているコネクションＩＤを抽出する（ステップＳ８０６）。
【００９８】
次にメッセージ解釈部４１１はクライアントセッション管理部４１２にセッション終了指示（４２１）を発行する（ステップＳ８０７）、この指示（４２１）を受け取ったクライアントセッション管理部４１２は、コネクションＩＤをキーとして自身の管理テーブルからセッション情報を取り出す（ステップＳ８０８）。それから、そのエントリを管理テーブルから削除する（ステップＳ８０９）。
【００９９】
そして、ステップＳ８０８で取り出されたセッション情報を値としているコネクションＩＤのエントリがいくつ管理テーブルに登録されているかを調べる（ステップＳ８１０）。このチェックの方法としては、管理テーブルの値を全検索して同一セッション情報が登録されているエントリの個数をカウントしてもよいし、サーバセッション情報で参照カウントを管理するようにしておいてもよい。いずれの方法においても、削除されたコネクションＩＤ以外のエントリにセッション情報が参照されていた場合は（ステップＳ８１１）これ以上の処理は不要なので、映像クライアント（４０３）にメッセージ送受信部４１０を利用してセッション終了処理が完了したことを通知する（ステップＳ８１５）。
【０１００】
また、セッション情報が他の映像クライアントと共有されていない場合は（ステップＳ８１１）、サーバセッション終了指示（４２２）をサーバセッション管理部４１５に発行する（ステップＳ８１２）。サーバセッション管理部４１５は対メッセージ送受信部４１６を介して映像サーバ４０２にセッション終了要求（４２５）を送信するなどのサーバセッション終了処理を実行する（ステップＳ８１３）。最後に映像サーバ４０２とのコネクションを切断し、映像クライアント４０３に処理の終了を通知する（ステップＳ８１５）。
【０１０１】
以上で、セッションの柊了処理が完了する。
【０１０２】
＜３．映像の取得＞
次に映像取得処理について図５と図９を用いて説明する。
【０１０３】
映像クライアント５０３によって映像取得要求（ＧｅｔＬｉｖｅＩｍａｇｅ、５１９）が発行されメッセージ送受信部５１０によって受信されると（ステップＳ９０１）、受信された要求はメッセージ解釈部５１１に転送される（ステップＳ９０２）。メッセージ解釈部５１１は転送された映像取得要求（５１０）からメッセージＩＤを取り出す（ステップＳ９０３）。メッセージ解釈部５１１はメッセージ名を各要求のメッセージ名と照合し、どの要求が送信されてきたかをチェックする（ステップＳ９０３）。その結果、映像取得要求ではなかった場合（ステップＳ９０４）、他の要求に対する処理が実行される（ステップＳ９０５）。
【０１０４】
映像取得要求であった場合（ステップＳ９０４）。パラメータとして付加されているコネクションＩＤを取り出す（ステップＳ９０６）。次にメッセージ解釈部５１１はクライアントセッション管理部５１２に映像取得指示（５２１）を発行する（ステップＳ９０７）。この指示（５２１）を受け取ったクライアントセッション管理部５１２は、コネクションＩＤをキーとして管理テーブルからサーバセッション情報を取り出す（ステップＳ９０８）。さらにクライアントセッション管理部５１２は映像取得・分配部５１７に映像取得指示（５２２）を転送する。
【０１０５】
映像取得・分配部５１７ではまず、自身の管理する映像データのバッファを調べ最新の映像が保持されているかをチェックする。本実施形態では、このチェックを映像データにシーケンシャルな番号をつけることによって可能にしている。映像データをバッファに登録するごとにそのデータに番号をつける。また映像クライアントごとに参照した映像データの番号をクライアントセッション管理部５１２内の管理テーブルにセッション情報と一緒に管理しておく。クライアントが最後に参照したものより大きな番号のつけられた映像がバッファに登録されていれば、それは最新の映像であるとみなすことができる。
【０１０６】
バッファ内の映像のチェックの結果バッファの内容が最新のものであると判明した場合は（ステップＳ９１０）、メッセージ送受信部５１０を介して映像クライアント４０３にバッファ内の映像データを返送する（ステップＳ９１４）。また、バッファの中身が最新のものではなかった場合は（ステップＳ９１０）、対サーバメッセージ送受信部５１６を介して映像サーバ５０２に映像取得要求（４２５）を送る等の映像取得処理を実行する（ステップＳ９１１）。その結果最新映像を映像サーバ５０２から取得すると（ステップＳ９１２）、新しい映像データでバッファの内容を書き換え（ステップＳ９１３）、メッセージ送受信部５１０を介して映像クライアント４０３にバッファ内の映像データを返送する（ステップＳ９１４）。
【０１０７】
以上で、映像の取得処理が完了する。
【０１０８】
＜４．情報の取得＞
情報の取得処理は、図５で示した処理で映像取得・分配部が行なっている部分を情報取得・分配部が実行するように変更すればよい。映像データと同じく他の情報も情報取得・分配部内のバッファで最新の情報を管理することで映像サーバとの通信回数を削滅することが可能である。
【０１０９】
＜５．カメラ操作＞
カメラ操作も、変換サーバの内部的な処理においては、要求をおこなうと（カメラ操作要求を行なうと）カメラの状態をあらわす情報が結果として返されてくるという形式になっているので、情報の取得と同じ方式で扱う事が可能である。
【０１１０】
以上まとめると、本実施形態では変換サーバとして、
−映像クライアントおよび映像サーバからのメッセージ送受信部
−特定の映像サーバのための対サーバメッセージ送受信部
−映像クライアントとのコネクションを管理するためのクライアントセッション管理部
−映像サーバから映像データを取得し複数の映像クライアントに分配する映像取得・分配部
−映像サーバから各種情報を取得し、複数の映像クライアントに分配する情報取得・分配部
−映像サーバに合わせて要求メッセージやリプライの方法を切り替えるためのサーバ情報管理部
−実際に映像サーバに合わせた要求メッセージやリプライを実行するためのサーバセッション管理部
を提供した。
【０１１１】
本実施形態は、
−変換サーバと映像クライアント間のプロトコルにＨＴＴＰを利用する事により、ファイアウォール・システムによって保護されているネットワーク内の映像クライアントにも映像サービスを提供できるという効果が得られる。
【０１１２】
−変換サーバと映像クライアント間のプロトコルにＨＴＴＰのＧＥＴコマンドを利用する事により、映像クライアント側はＷｅｂブラウザを拡張することなく映像を取得し、表示することが可能である。
という特有の効果をもっている。
【０１１３】
＜第２の実施形態＞
ここでは、第２の実施形態として、上記実施形態（第１の実施形態）における代行手段群と効率化手段群を、切り替え手段群とは独立なサーバとして実現する形態について説明する。具体的には、第１の実施形態で同一サーバプログラム内におかれていた対サーバ処理モジュールを変換サーバとは独立なサーバプログラムとして実現する。このサーバ化された対サーバ処理モジュールのことを本第２の実施形態ではサブ変換サーバと呼ぶ。
【０１１４】
ではまず、本第２の実施形態の運用形態について図１０を用いて説明する。図１０においても図２と同様に映像サーバ１００１〜１００３および映像クライアント１００４〜１００６が設置されておりネットワーク１００７で結合されている。ただし、本第２の実施形態においては変換サーバ１００８〜１０１０が複数設置されており、さらにサブ変換サーバ１０１１〜１０１３も複数設置され、それぞれネットワーク１００７に接続されている。映像クライアント１００４〜１００６は映像サーバ１００８〜１０１０と通信を行ない、映像サーバ１００１〜１００３はサブ変換サーバ１０１１〜１０１３とセッションを形成する。
【０１１５】
本第２の実施形態では、変換サーバが複数設置されていてもサブ変換サーバは映像サーバの種類の数だけ設置されていればよい。たとえば映像サーバ１００１用のサブ変換サーバ１０１１が動作している場合、このサブ変換サーバ１０１１は複数の変換サーバ１００８〜１０１０によって共有され映像サーバ１０１１との通信に使用される。また、映像クライアントは運用されている変換サーバ１００８〜１０１０のどれを使用してもよい。ネットワーク１００７の状況等に合わせて最も都合のよい変換サーバを選択することが可能である。
【０１１６】
では、図６を用いて本第２の実施形態の各構成要素について説明する。図６においては図１にかかれていたＣＰＵやメインメモリが省略されているが、本実施形態も何らかのコンピュータ（勿論パーソナルコンピュータ等の汎用装置を含む）上で動作する以上、ＣＰＵ，メインメモリバス，ハードディスク等の二次記憶装置は備わっているものとして説明する。また、図６においても映像クライアント６０３と映像サーバ６０２が一つずつだけ書かれておりネットワーク６２０で結合されているが、これも図１と同様に実際は複数の映像クライアント，映像サーバがネットワーク６２０に接続される。
【０１１７】
本第２の実施形態の各要素は変換サーバ６０４とサブ変換サーバ６０５に別れている。これらのサーバもまた図１０で示したように同時に複数起動され得る。
【０１１８】
まず、変換サーバ６０４は以下のモジュール群から構成されている：
−メッセージ送受信部６０６
−メッセージ解釈部６０７
−クライアントセッション管理部６０８
−サーバ情報管理部６０９
−データベースインタフェース部６１０
上記のモジュールのうち６０６〜６０９は図１における同名のモジュールと同じ役割および動作を行なう。本第２の実施形態で追加されたデータベースインタフェース部６１０はデータベース管理システム６０１の機能を利用するためのリレーショナルデータベースである。ただしここではデータベースの種類は問わない。
【０１１９】
たとえばデータベース管理システム６０１としてオブジェクト指向データベースを用いても本第２の実施形態の実現は可能である。第１の実施形態におけるクライアントセッション管理部およびサーバ情報管理部はコネクションＩＤ等の管理を内部的なテーブルを用いて実現していた。これに対し、本第２の実施形態でのデータ管理および検索機能はデータベース管理システム６０１が提供する。
【０１２０】
また、第１の実施形態におけるサーバ管理部は対サーバ処理モジュールヘのエントリポイントを管理していたが、本第２の実施形態のサーバ管理部６０９はサブ変換サーバと通信を行なうために必要なホスト名，ポート番号，ｓｏｃｋｅｔなどの情報を管理する。
【０１２１】
次にサブ変換サーバ６０５について説明する。サブ変換サーバ６０５は以下のモジュール群から構成されている：
−メッセージ送受信部６１１
−サーバセッション管理部６１２
−対サーバメッセージ送受信部６１３
−情報取得・分配部６１４
−映像取得・分配部６１５
−データベースインタフェース部６１６
上記のモジュールのうち６１２〜６１５は図１における同名のモジュールと同じ役割および動作を行なう。またメッセージ送受信部６１１は主に変換サーバ６０４との通信に使用される。内部は変換サーバ６０４内のメッセージ送受信部６０６と同じものである。また、サブ変換サーバ６０５にもデータベースインタフェース部６１６が追加されており、映像取得・分配部や情報取得・分配部内のバッファの内容はデータベース管理システム６０１によって管理され複数のサブ変換サーバや変換サーバと共有することが可能である。
【０１２２】
以上のように本第２の実施形態における各構成要素は第１の実施形態と同じ機能をもっており動作もほぼ同じである。
【０１２３】
以下に本第２の実施形態の動作における第１の実施形態との相違点のみを列挙する。
【０１２４】
１．テーブルによって管理されていた情報がデータベースで管理され、データの登録，削除，検索はデータベースインタフェース部に指令を発行することで実行される。
【０１２５】
２．変換サーバ内で行なわれていた指示の一部が、ネットワークを介した要求メッセージの形でやり取りされる。
具体的には以下のものである。
【０１２６】
−図３におけるセッション生成指示（３２４）およびその返答
−図４におけるセッション終了指示（４２２）およびその返答
−図５における映像取得指示（５２２）およびその返答
【０１２７】
以上述べた様に本第２の実施形態では、変換サーバとして、
−映像クライアントおよび映像サーバからのメッセージ送受信部、
−特定の映像サーバのための対サーバメッセージ送受信部、
−映像クライアントとのコネクションを管理するためのクライアントセッション管理部、
−映像サーバに合わせて要求メッセージやリプライの方法を切り替えるためのサーバ情報管理部、
を提供し、さらにサブ変換サーバとして、
−映像サーバから映像データを取得し、複数の映像クライアントに分配する映像取得・分配部、
−映像サーバから各種情報を取得し複数の映像クライアントに分配する情報取得・分配部、
−実際に映像サーバに合わせた要求メッセージやリプライを実行するためのサーバセッション管理部、
を提供した。
【０１２８】
また、データベース管理モジュールを用いて上記の各モジュールを実現するために、
−データベースインタフェース部
を変換サーバとサブ変換サーバに追加した。
【０１２９】
本第２の実施形態は、
−変換サーバとサブ変換サーバに分割する事により、新たな方式の映像サーバが追加された場合も、その映像サーバに対応したサブ変換サーバを１つ動かすだけで、すべての変換サーバおよび映像クライアントから新しい映像サーバを利用する事が可能、
−データ管理にデータベース管理システムを利用する事により、各種情報や取得した映像を変換サーバ間およびサブ変換サーバ間で共有することができる。このことにより、ある変換サーバやサブ変換サーバにトラブルが発生しても、他のサーバが処理を代行することが可能、
という特有の効果をもっている。
【０１３０】
以上のように、本第１、第２の実施形態によれば、コンピュータネットワークを介して、遠隔地に設置されてるコンピュータに動画あるいは静止画映像をサービスする遠隔映像配信システムにおいて、
−他のプログラムからメッセージを送受信するためのメッセージ送受信手段
−上記メッセージを解釈するためのメッセージ解釈手段
−クライアントとのコネクションを管理するためのコネクション管理手段
−取得した映像データを複数のクライアントに分配するための映像分配手段
−取得した各種情報を複数のサーバに分配するための情報分配手段
−映像サーバにあわせて要求メッセージやリプライの方法を切り替えるための配信方式切り替え手段
−映像サーバにあわせて要求メッセージやリプライを実行する配信方式実行手段
を提供することにより、
−映像配信システムとＷｏｒｌｄ  Ｗｉｄｅ  Ｗｅｂシステムの通信形態の差異の吸収が可能、
−Ｗｅｂブラウザと映像クライアントの統合による実行効率の低下を防止することが可能、
−映像サーバごとの映像配信方式の差異を吸収し、汎用的な映像クライアントの実現が可能
という効果を得ることができる。
【０１３１】
尚、上記第１、第２の実施形態では、変換サーバ及びサブ変換サーバは、先に説明したようにネットワークに接続するためのハードウェアを必要とするものの、汎用の装置、例えばパーソナルコンピュータ上で動作するプログラムによって実現できるものである。
【０１３２】
従って、本発明の目的は、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読出し実行することによっても、達成されることは言うまでもない。
【０１３３】
この場合、記憶媒体から読出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。
【０１３４】
プログラムコードを供給するための記憶媒体としては、例えば、フロッピディスク，ハードディスク，光ディスク，光磁気ディスク，ＣＤ−ＲＯＭ，ＣＤ−Ｒ，磁気テープ，不揮発性のメモリカード，ＲＯＭなどを用いることができる。
【０１３５】
また、コンピュータが読出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）などが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０１３６】
さらに、記憶媒体から読出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０１３７】
また、本発明のストリーム情報サービスとはリアルタイム系情報サービス、例えば動作データ或いはオーディオデータであれば本発明を適用できる。
【０１３８】
【発明の効果】
以上説明したように本発明よれば、独自の通信形態でもって情報をサービスするサーバと、汎用ネットワーク上でのサービスを受けるクライアント間とを効率良く且つ簡単な構成で情報伝達を行なわせることが可能になる。
【０１３９】
【図面の簡単な説明】
【図１  】実施形態におけるシステムの構成図である。
【図２  】実施形態におけるシステムを構成する装置の接続関係を示す図である。
【図３  】実施形態におけるセッション開始処理の動作を説明するための図である。
【図４  】実施形態におけるセッション終了処理の動作を説明するための図である。
【図５  】実施形態における映像取得処理の動作を説明するための図である。
【図６  】第２の実施形態におけるシステム構成図である。
【図７  】実施形態におけるセッション開始処理の動作処理手順を示すフローチャートである。
【図８  】実施形態におけるセッション終了処理の動作処理手順を示すフローチャートである。
【図９  】実施形態における映像取得処理の動作処理手順を示すフローチャートである。
【図１  ０  】第２の実施形態におけるシステムを構成する装置の接続関係を示す図である。
【図１】
0003733218.tif 000016
【図２】
0003733218.tif 000017
【図３】
0003733218.tif 000018
【図４】
0003733218.tif 000019
【図５】
0003733218.tif 000020
【図６】
0003733218.tif 000021
【図７】
0003733218.tif 000022
【図８】
0003733218.tif 000023
【図９】
0003733218.tif 000024
【図１０】
0003733218.tif 000025