(57)【特許請求の範囲】
【請求項１】
インターネットを介した静止画又は動画の撮像要求のそれぞれ対応して撮像対象を画像信号に変換する撮像手段のパン、チルト、ズームのいずれかの駆動を制御する制御手段と、
前記撮像要求が静止画の要求であれば、前記撮像手段により変換されたリアルタイムの画像信号を静止画データとしてインターネットに対応した第１のプロトコルで送出する第１送出手段と、
前記撮像要求が動画の要求であれば、前記撮像手段により変換されたリアルタイムの画像信号を動画データとして前記第１のプロトコルとは異なり、かつインターネットに対応した第２のプロトコルで送出する第２送出手段とを有し、
前記第１送出手段は、当該要求に応じた前記制御手段による前記撮像手段の駆動制御が完了した後で撮影し、当該撮像された画像を送出し、
前記第２送出手段は、当該要求に応じた前記制御手段による前記撮像手段の駆動制御の途中の動画データをも送出する
ことを特徴とするサーバ。
【請求項２】
前記第１のプロトコルはＨＴＴＰであることを特徴とする請求項１記載のサーバ。
【請求項３】
前記第１のプロトコルは、ファイル転送プロトコルであることを特徴とする請求項１記載のサーバ。
【請求項４】
前記第１のプロトコルは、マルチキャストに対応したプロトコルであることを特徴とする請求項１記載のサーバ。
【請求項５】
前記第１のプロトコルは前記ＨＴＴＰに前記制御手段による前記撮像手段の駆動を制御する制御信号を含ませたプロトコルであることを特徴とする請求項２記載のサーバ。
【請求項６】
前記第２のプロトコルは、映像配送プロトコルと、前記制御手段による前記撮像手段の駆動を制御するカメラ制御プロトコルとを含むことを特徴とする請求項１記載のサーバ。
【請求項７】
前記第１のプロトコルと前記第２のプロトコルとでは、前記制御手段の応答特性をそれぞれに対応して異ならしめたことを特徴とする請求項１記載のサーバ。
【請求項８】
前記第２送出手段は、
送出先との間でのトラフィックの混雑の度合を検出手段と、
該検出手段で検出された混雑の度合に応じて、前記撮像手段で連続して撮像されるフレームのうち、次に送出すべきフレームを決定し、決定したフレームをモーションＪＰＥＧで圧縮する手段とを含む
ことを特徴とする請求項１に記載のサーバ。
【請求項９】
インターネットを介した静止画又は動画の撮像要求のそれぞれに対応して対象画像を画像信号に変換する撮像手段のパン、チルト、ズームのいずれかの駆動を制御する制御ステップと、
前記撮像要求が静止画の要求であれば、前記撮像手段により変換されたリアルタイムの画像信号を静止画データとしてインターネットに対応した第１のプロトコルで送出する第１送出ステップと、
前記撮像要求が動画の要求であれば、前記撮像手段により変換されたリアルタイムの画像信号を動画データとして前記第１のプロトコルとは異なり、かつインターネットに対応した第２のプロトコルで送出する第２送出ステップとを有し、
前記第１送出ステップは、当該要求に応じた前記制御ステップによる前記撮像手段の駆動制御が完了した後で撮影し、当該撮像された画像を送出し、
前記第２送出ステップは、当該要求に応じた前記制御ステップによる前記撮像手段の駆動制御の途中の動画データをも送出する
ことを特徴とするサーバの制御方法。
【請求項１０】
静止画又は動画の撮像要求のそれぞれに対応して、対象画像を画像信号に変換する撮像手段のパン、チルト、ズームのいずれかの駆動を制御する制御手段と、
前記撮像要求が静止画の要求であれば、前記撮像手段により変換されたリアルタイムの画像信号を静止画データとしてインターネットに対応した第１のプロトコルで送出する第１送出手段と、
前記撮像要求が動画の要求であれば、前記撮像手段により変換されたリアルタイムの画像信号を動画データとして前記第１のプロトコルとは異なり、かつインターネットに対応した第２のプロトコルで送出する第２送出手段とを有し、
前記第１の送出手段と前記第２送出手段とでは、前記制御手段による前記駆動の速度をそれぞれに対応して異ならしめたことを特徴とするサーバ。
【請求項１１】
第２の送出手段に基づく前記制御手段による駆動速度のほうが、前記第１送出手段に基づく駆動動作より低速であることを特徴とする請求項１０に記載のサーバ。
【請求項１２】
前記第２送出手段は、
送出先との間でのトラフィックの混雑の度合を検出手段と、
該検出手段で検出された混雑の度合に応じて、前記撮像手段で連続して撮像されるフレームのうち、次に送出すべきフレームを決定し、決定したフレームをモーションＪＰＥＧで圧縮する手段とを含む
ことを特徴とする請求項１０または１１に記載のサーバ。
【請求項１３】
静止画又は動画の撮像要求のそれぞれに応じて、対象画像を画像信号に変換する撮像手段のパン、チルト、ズームのいずれかの駆動を制御する制御ステップと、
前記撮像要求が静止画の要求であれば、前記撮像手段により変換されたリアルタイムの画像信号を静止画データとしてインターネットに対応した第１のプロトコルで送出する第１送出ステップと、
前記撮像要求が動画の要求であれば、前記撮像手段により変換されたリアルタイムの画像信号を動画データとして前記第１のプロトコルとは異なり、かつインターネットに対応した第２のプロトコルで送出する第２送出ステップとを有し、
前記第１送出ステップと前記第２送出ステップとでは、前記制御ステップによる駆動速度をそれぞれに対応して異ならしめたすることを特徴とするサーバの制御方法。
【請求項１４】
第２の送出ステップに基づく前記制御ステップによる駆動速度のほうが、前記第１送出ステップに基づく駆動速度が遅いことを特徴とする請求項１３に記載のサーバの制御方法。
【請求項１５】
前記第２送出ステップは、
送出先との間でのトラフィックの混雑の度合を検出ステップと、
該検出ステップで検出された混雑の度合に応じて、前記撮像手段で連続して撮像されるフレームのうち、次に送出すべきフレームを決定し、決定したフレームをモーションＪＰＥＧで圧縮するステップとを含む
ことを特徴とする請求項１３または１４に記載のサーバの制御方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明はインターネットに対応するサーバ及びその制御方法に関する。
【０００２】
【従来の技術】
カメラを遠隔から制御（たとえばパン、チルト、ズーム等）するシステムが一般に知られている。
【０００３】
このようなシステムでは、ネットワークを介して行うにしても、カメラの制御を司っている装置と、クライアント側の装置との間では、独自の仕様（プロトコルや制御情報）に基づくものを採用しており、決して汎用性があるものではない。
【０００４】
【発明が解決しようとする課題】
ところが、近年、インターネットが急速に普及しつつあり、これを介して遠隔にあるカメラで撮影された映像を鑑賞したい、という要求が高まってきている。
【０００５】
そして、同時に、カメラで撮影された映像を順次転送してもらうことで、遠隔で撮影しているリアルタイムの映像を鑑賞することも望まれてもいる。
【０００６】
これが実現できれば、たとえば自宅等に居ながらにして、地方の観光地の映像をリアルタイムに見ることができるようになり、場合によっては諸外国の映像をも見ることができるようになる。
【０００７】
しかしながら、インターネットにおいて用いられるデータの伝送プロトコルは、ファイル転送プロトコルの一種であり、一枚の画像の伝送が終了すると通信が終了してしまうものであった。
【０００８】
従って、かかるファイル転送プロトコルの方式では、ビデオカメラ等の撮像手段から得られる動画像を伝送するには、該撮像手段の動作制御という点で必ずしも適していなかった。
【０００９】
【課題を解決するための手段】
本発明はかかる点に鑑み、撮像手段で得られたリアルタイム画像をインターネットを介して良好に送信できるサーバ及びその制御方法を提供することを目的とする。
【００１０】
この課題を解決するため、たとえば本発明のサーバは以下のような構成を備える。すなわち。
【００１１】
インターネットを介した静止画又は動画の撮像要求のそれぞれ対応して撮像対象を画像信号に変換する撮像手段のパン、チルト、ズームのいずれかの駆動を制御する制御手段と、
前記撮像要求が静止画の要求であれば、前記撮像手段により変換されたリアルタイムの画像信号を静止画データとしてインターネットに対応した第１のプロトコルで送出する第１送出手段と、
前記撮像要求が動画の要求であれば、前記撮像手段により変換されたリアルタイムの画像信号を動画データとして前記第１のプロトコルとは異なり、かつインターネットに対応した第２のプロトコルで送出する第２送出手段とを有し、
前記第１送出手段は、当該要求に応じた前記制御手段による前記撮像手段の駆動制御が完了した後で撮影し、当該撮像された画像を送出し、
前記第２送出手段は、当該要求に応じた前記制御手段による前記撮像手段の駆動制御の途中の動画データをも送出する。
【００１２】
【発明の実施の形態】
以下、添付図面に従って本発明に係る実施形態の一例を詳細に説明する。
【００１３】
なお、発明の特徴は以下に続く実施形態中の特に図１６のソフトウェアの構成に特に開示される。
【００１４】
図１は実施形態のカメラ制御装置のブロック構成図を示している。図示において１００１がカメラ制御装置であって、たとえばパーソナルコンピュータをベースにしている。１００３はカメラ制御装置１００１の制御対象であるビデオカメラ（以下、単にカメラという）であり、制御内容は撮影条件としてのズームは勿論、パン及びチルト、露出等である。この為、カメラ１００３は不図示の雲台を有している。カメラ１００３とカメラ制御装置１００１とは、たとえばパーソナルコンピュータが通常備えているＲＳ２３２Ｃインターフェースで接続されている。
【００１５】
さて、カメラ制御装置１００１には以下の構成を備えている。
【００１６】
１０１７はカメラ１００３を上記インターフェースを介して各種制御信号を出力するカメラ制御手段１０１７、１０１８はカメラ１００３の撮影映像を画像キャプチャ装置などで入力する映像入力手段、１０１１はネットワークアダプタ等で本装置と他の装置とが情報交換を行うための通信インターフェース手段であり、これらの資源に加え、コンピュータのＣＰＵや記憶装置や補助記憶装置などの各資源を利用したプログラムおよびメモリデータとして実現される、コマンド解釈手段１０１２、受付コード生成手段１０１３、時限手段１０１５、画像記憶手段１０１９、そして予約登録手段１０１４を備える。
【００１７】
外部装置１００２は、たとえば、ＷＷＷサーバやＷＷＷブラウザであり、これらの間は、ＨＴＴＰプロトコルで通信を行う。すなわち、ＷＷＷブラウザからは、文書データやイメージデータの格納先であるＷＷＷサーバに対して、対象とするデータの格納先が示されたＵＲＬに従ってその情報を提示する。ＷＷＷサーバは、これに応えて、対応する文書データやイメージデータをＷＷＷブラウザに返答する。
【００１８】
本実施形態では、通信インターフェース１０１１は、ＷＷＷサーバで実現されている方式を用いる。すなわち、ＨＴＴＰプロトコルで通信を行い、本実施形態の制御装置１００１は、映像データの応用では、あたかもＷＷＷサーバのようにふるまう。これは、ＷＷＷサーバの通信方法を本制御装置でも用いれば実現できる。
【００１９】
一般にＷＷＷ文書中にイメージデータを貼り込む時には、以下のような記述が用いられる。
【００２０】
<img src="http://www.foo.co.jp/image001.gif">
この意味は、www.foo.co.jpというＷＷＷサーバのimage001.gifというファイルに格納されたイメージデータの転送を要求することを示しており、ブラウザの画面にその転送されてきた画像の表示が行われることになる。
【００２１】
本実施形態では、このような仕様をそのまま活用しつつ、遠隔でカメラを制御しようとするものである。
【００２２】
すなわち、本実施形態では、上記のファイル名に相当する部分の文字列を、コマンドとして解釈するのである。要するに、カメラアングルを指定するパン、チルト、ズーム等は、それぞれ英字の「P」、「T」、「Z」で表わし、その後に、それぞれの制御量を数字で表す。
【００２３】
たとえば、パン角度は-５０度から５０度、チルト角度は、-２０度から２０度、ズームは１から８の８段階を選べるようなカメラがあるとする。この場合において、たとえば、パン角度を２０度、チルトを５度、２倍ズームで撮影し、gif形式の画像データとして貼り込みたい場合は、以下のように記述する。なお、本カメラ制御装置のネットワークアドレスは、cam.foo.co.jpであるとする。
<img src="http://www.foo.co.jp/P20T5Z2.gif">
以上のような、ＨＴＭＬ文書記述があった場合、ＷＷＷブラウザのサーバーである外部装置１００２は、カメラ制御装置１００１に対して上記のＨＴＭＬ記述の文字列を出力し、画像データの要求を行う。
【００２４】
通信インターフェース手段１０１１を介して、カメラ制御装置１００１にこの要求が入ると、コマンド解釈手段１０１２が起動され、要求の解釈（上記ＨＴＭＬ文字列）とそれに対する応答の処理が開始される。
【００２５】
その処理例は図２のフローチャートに示す通りである。
【００２６】
まず、ステップＳ１０１で、ファイル名として記述されたコマンドを解釈する。すなわち要求の先頭が「P」であれば撮影コマンドと認識し、ステップＳ１０２に進む。
【００２７】
ここでは、カメラ制御手段１０１７を介し、指定されたパン、チルト、ズームの各値でカメラ１００３を操作し(ステップＳ１０２)、撮影された画像を指定された方法の画像フォーマットに変換し、通信インターフェース手段１０１１を介して要求元の外部装置１００２に返答する。外部装置１００２は、この画像データを記憶し、それを本来の発信元に転送することになる。
【００２８】
このとき、通信インターフェース手段１０１１では、ＨＴＴＰプロトコルを用いるため、画像フォーマットに応じた内容種別情報やステータス情報等が先頭に付加される。そして、本処理を終了する。
【００２９】
これにより、ＨＴＭＬ文書に、あたかもＷＷＷサーバのファイルに格納されたイメージデータのように撮影された映像が貼り込まれて表示されるようになる。また、ステップＳ１０１における条件判断で、要求の先頭が「R」であれば撮影日時の予約コマンドと認識され、ステップＳ１０４の条件判断を介し、ステップＳ１０５に進む。
【００３０】
予約コマンドは、英字「R」で始まり、年、月、日、時、分をそれぞれ整数で表し、それらをピリオドで区切ったものが続く。そして、その後に撮影条件であるパン・チルト・ズームの指示が続き、最後には、画像フォーマットを表す名称を付ける。なお、撮影条件がない場合には、その撮影日時時点でのカメラアングルが採用されることになる。
【００３１】
たとえば、１９９６年７月６日１３時１５分にパン角２５度、チルト角０度で３倍ズームの映像をgifフォーマットで撮影予約したい場合には、以下のように記述する。すなわち、
<img src="http://ＷＷＷ.foo.co.jp/R1996.7.6.13.15.P25T0Z3.gif">
以上のような、予約コマンドが指定された場合、ステップＳ１０５では、受付コード生成手段１０１３より、ユニークな識別番号を受付コードとして受け取る。たとえば、生成要求ごとに＋１されるカウンターとして実現してもいいし、要求された年月日の時刻を表す数値によって実現してもよい。
【００３２】
そして、この受付コードと予約時刻と撮影条件と画像フォーマットの情報を予約登録手段１０１４が有する不図示の記憶装置に登録し(ステップＳ１０６)、受付コード（受け付けた旨を報知するコード）を通信インターフェース手段１０１１を介して要求元の外部装置１００２、ひいては本来のエンドユーザに向けて返答する(ステップＳ１０７)。
【００３３】
なおこの時も、返答内容が受付コードであることを示すために内容種別情報やステータス情報等が先頭に付加される。そして、本処理を終了する。
【００３４】
単純にこのような撮影予約を含んだＨＴＭＬ文書を作成して、それを、一般のＷＷＷブラウザで表示しようとした場合には、画像データの代わりに受付コードが帰ってくるだけなので、結局のところは画像は表示されない。
【００３５】
しかしながら、ＷＷＷサーバのＣＧＩプログラム等によって、カメラ制御装置１００１に対して、撮影予約をＷＷＷブラウザと同様の方法で行い、受付コードが得られた後、後述する画像取り出しコマンドでその受付コードを指定したイメージデータ記述を含んだＨＴＭＬ文書を生成するれば、この生成された文書をＷＷＷブラウザで表示すると、予約したとおりに撮影が行われ、その画像データが表示されるようになる。
【００３６】
つまり、カメラ制御装置１００１は、予約登録手段１０１４に登録された予約時間になると、登録されたカメラアングルでカメラ１００３を制御し、その撮影を行ない、それを画像記憶手段１０１９に適当な名前、たとえば予約番号をファイル名とし、指定された形式で記憶する。この後、外部装置１００２から取り出しコマンドが送られてくると、その取り出しコマンドに適合する画像データを画像記録手段１０１９から読出し、それを外部装置１００２（エンドユーザの端末に相当する）に、指定された形式で転送されることになる。
【００３７】
なお、取り出しコマンドは、英字「G」で始まり、受付コードが続き、最後には、画像フォーマットを表す名称を付ける。
【００３８】
ここの受付コードは、予約を行ったときに外部装置１００２に返答されるものである。たとえば「１２５４３」が受付コードとして返された時、撮影予約した画像を撮影後に取り出す時には、以下のような記述を用いる。すなわち、
<img src="http://www.foo.co.jp/G12543.gif">
である。
【００３９】
予約登録手段１０１４内の記憶装置には、たとえば、図３のような、表（テーブル）の形式で各種情報が格納される。なお、ここでは予約登録手段１０１４自身が備える記憶装置を例にしたが、たとえばカメラ制御装置１００１の画像記憶手段１０１９を活用しても構わないし、記憶手段はいかなるものであっても良い。
【００４０】
なお、取り出しコマンドの最後に付加されている画像形成を意味する文字列（この場合には「gif」であるが、原則的に予約したときと同じにする必要がある。ただし、異なる場合には、カメラ制御装置が、画像記憶手段１０１９に予約番号で格納されている画像を、新たに指示された形式に変換し転送するようにしてもよい。
【００４１】
説明が戻るが、図３は、上記の予約例の場合で、受付コードが「１２５４３」であったときの状態を示している。すなわち、まず、撮影日時情報、受け付けコード、撮影条件、画像形式（画像フォーマット）である。
【００４２】
また、画像記憶手段１０１９は、たとえば、図４のような、形式で管理されている。ここでは受け付けコード（予約コードに対応し、ファイル名と同様の意味である）、画像形式、そして実際の画像データが格納される。なお、画像記憶手段１０１９はいかなる形式の記憶装置でもよいが、容量的に十分なものが望まれる。具体的には、ハードディスク装置や光磁気ディスク装置等である。
【００４３】
上記の通りであるが、実際に取り出しコマンドを受信した場合の処理手順を以下に説明する。
【００４４】
ステップＳ１０１における条件判断で、要求の先頭が「G」であると、次いでステップＳ１０４に進み、ここでの判断も否になるので、ステップＳ１０８に進むことになる。ここでは画像取り出しコマンドであると認識することになるから、ステップＳ１０９に進み、取り出しコマンドに含まれる予約コードに基づいて、画像記憶手段１０１９に保存されるデータを検索する。
【００４５】
そして、画像取り出しコマンドとして記述された受付コードと同じ値で格納されているかどうかを判断し(ステップＳ１１０)、登録されているならば、その画像データを取り出し、通信インターフェース手段１０１１を介して要求元の外部装置１００２に向けて転送する。
【００４６】
このときも、通信インターフェース手段１０１１では、ＨＴＴＰプロトコルを用いるため、画像フォーマットに応じた内容種別情報やステータス情報等が先頭に付加される(ステップＳ１１１)。
【００４７】
そして、ステップＳ１１２で、いま取り出した画像データが格納されている画像記憶手段１０１９の欄を消去する。そして、本処理を終了する。
【００４８】
また、ステップＳ１１０で、指定された受付コードに対応する画像データが格納されていないと判断したら、対象画像が未撮影、或いは既に転送されて消去されていることになるのでエラー情報を通信インターフェース手段１０１１を介して要求元の外部装置１００２に返答し、本処理を終了する。
【００４９】
また、ステップＳ１０８で、外部装置１００２よりの要求の先頭が「G」でもない場合は、未定義コマンドであるというエラー情報を通信インターフェース手段１０１１を介して要求元の外部装置１００２に返答し、本処理を終了する。
【００５０】
以上のようにして、外部装置１００２と本発明の制御装置１００１との情報交換が行われる。
【００５１】
次に、予約登録手段１０１４に登録された予約データに基づき、カメラ制御と撮影と撮影結果の格納を行う時限手段１０１５について説明する。
【００５２】
時限手段１０１５においては、一定時間間隔、たとえば１分おきに、時限プログラムが起動される。これは、コンピュータのタイマーを利用したりすれば実現できる。
【００５３】
時限プログラムの動作を、図５のフローチャートを用いて説明する。
【００５４】
まず、現在時刻を制御装置１００１のタイマーから読み出し(ステップＳ２０１)、ステップＳ２０２に進む。
【００５５】
ステップＳ２０２では、予約登録手段１０１４から順に一欄づつ登録された予約項目を取り出す。ステップＳ２０３で、すべて取り出し終ったと判断できたら本処理を終了し、予約項目が取り出せたなら、ステップＳ２０４に進み、対象の予約項目における設定時刻が、現在時刻より未来であるか否かを判定し、現在時刻が設定された時刻に至っていないと判断したら、ステップＳ２０２以降の処理を繰り返す。
【００５６】
さて、現在時刻が設定時刻以上になっていると判断した場合には、ステップＳ２０５に進み、取り出した予約項目の撮影条件に従って、カメラ制御手段１０１７を介しカメラ１００３を制御し、撮影を行う。そして、撮影された画像を予約項目で指定された方法の画像フォーマットに変換し、この画像データを受付コードと画像フォーマット情報とともに画像記憶手段１０１９に格納する(ステップＳ２０６)。
【００５７】
続いて、現在取り出した、予約項目を予約登録手段１０１４から消去し(ステップＳ２０７)、ステップＳ２０２に戻って処理を繰り返す。
【００５８】
以上のようにすることで、予約通りの撮影が行われ、その結果が保管され、後に、画像取り出しコマンドが外部装置１００２から要求されると、この画像データが返答されることになる。
【００５９】
以上のように、実施形態におけるカメラ制御装置をＷＷＷシステムのネットワークに接続し、実施形態のカメラ制御装置のアドレスにカメラの撮影条件の記述を加えたURLをイメージデータのソースとして記述するだけで、簡単に遠隔のカメラを操作したライブ画像をＷＷＷ文書中に貼り込むことが可能になる。なお、これだけを実現する場合には、受付コード手段１０１３、時限手段１０１５、画像記憶手段１０１９、予約登録手段１０１４のそれぞれは、不要であり、コマンド解釈手段１０１２のステップＳ１０４以降のステップは不要である。
【００６０】
また、時限手段１０１５、画像記憶手段１０１９、予約登録手段１０１４を設けたことにより、ＷＷＷサーバのＣＧＩプログラムなどを利用すれば、カメラ撮影の予約を行い、その結果を後刻ＷＷＷページに取り込んで表示を行うことが可能になる。特に、ネットワークが混雑するような時間帯に遠隔のカメラで撮影しようとしても、画像の転送に時間がかかり、思うように画像データを収集できないが、本実施形態によれば、その時間帯でそれぞれ特定のカメラアングルで必要な時刻分だけあらかじめ予約を行っておき、夜間等、ネットワークがすいた時に、蓄積された画像データを取り出して利用することができるようになる。
【００６１】
特に、同一カメラアングルで、短い間隔で複数枚の画像を撮影することが、ネットワークの伝送容量の大きさに関わらず可能となる大きな効果が得られる。
【００６２】
もちろん、ここでは、外部装置１００２とのインターフェースをＨＴＴＰプロトコルとして説明したが、どういう通信インターフェースを用いても構わない。
【００６３】
なお、本実施形態では、予約に対する撮影データを同定するために受付コードを用いたが、受付コード発生手段を用いずに、画像要求する外部装置１００２（エンドユーザ側）側で、ユニークな要求番号を生成し、予約コマンドの一部として要求を行い、制御装置では外部装置１００２と要求番号との組みにより、対象となる画像データを同定する方法を用いてもよい。
【００６４】
また、上記の予約コードを発信元に通知する際、パスワードを発行し通知し、次回、取り出す際には予約コードと共にパスワードを付けて初めて転送できるようにしてもよい。少なくとも、このようにすると、第３者がたまたま同じ予約番号を付して転送要求を発したために、そのファイルが削除されてしまう、という問題は回避できる。
【００６５】
また、予約時刻は分単位としたが、秒単位やミリ秒単位まで拡張しても構わない。
【００６６】
また、画像フォーマットは、gifを例に挙げたが、JPEGをjpgというファイルエクステンションで表現し、どちらかを切り替えられるようにしてもよい。
【００６７】
また、ファイル名をコマンドとみなしたが、URLのパラメータ記述を利用してもよい。
【００６８】
たとえば、パン、チルト、ズーム、画像フォーマットをそれぞれ、２５度、５度、２倍、gifとしたとき、以下のように記述するようにしてもよい。
【００６９】
<img src="http://cam.foo.co.jp/cameraimage?P=20,T=5,Z=2,F=gif">
また、本制御装置にＷＷＷサーバを同時に実装してもよい。その場合には、
たとえば、ＷＷＷサーバのCGIプログラムとしてコマンド解釈手段１０１２のプログラムにcamctl.exeなる名称をつけ、以下のような記述を行うことで、実現できる。
【００７０】
<img src="http://cam.foo.co.jp/cgi-bin/camctl.exe?P=20,T=5,Z=2,F=gif">
更にまた、上記実施形態では、一度予約した画像の転送が完了すると、その画像データ（ファイル）を削除したが、場合によってはこの時点で削除しなくてもよい。
【００７１】
つまり、実際に撮影し、ファイルとして保存してから適当な時間は保管しておき、その時間を経過した場合には転送した、しないに拘わらず削除するのである。このようにすると、少なくとも複数のエンドユーザが同じ画像を見る機会を得ることができるようになる。
【００７２】
また、場合によってはパスワードを付与し、そのパスワードに合致する場合にのみ転送するようにしてもよい。
【００７３】
＜第２の実施形態＞
上記実施形態（第１の実施形態）では、一度に一画像しかカメラ撮影予約ができなかった。
【００７４】
本実施形態においては、予約コマンドを「+」で副数個結合してできたファイル名に画像フォーマットを表すファイルエクステンションを付加して、一度に複数の時刻やカメラアングルの予約を可能にさせようとするものである。
【００７５】
たとえば、１９９６年７月６日１３時１５分と３０分と４５分にパン角２５度チルト角０度で３倍ズームで撮影し、３枚の画像をgifフォーマットで後に取り出す場合には、以下のように記述する。
【００７６】
<img src="http://www.foo.co.jp/R1996.7.6.13.15P25T0Z3+R1996.7.6.13.30P25T0Z3+R1996.7.6.13.45P25T0Z3.gif">
ここで、本明細書では、「"」と「"」とで囲まれている文字列が２行以上にまたがって表示されているかもしれないが、実際の記述は、改行を含まない、一行で記述する。
【００７７】
なお、日時や時間が同じであったり、カメラアングルが同じである場合は、それらを省略可能としてもよい。その場合は、上記と同じ予約を以下のように記述できる。
【００７８】
<img src="http://www.foo.co.jp/R1996.7.6.13.15P25T0Z3+R....30+R....45.gif">
なお、この記述でピリオドが連続する部分は、各ピリオドで挟まれる数字は一番最初に設定した数字と同じであることを示している。これにより、同じ日付等であれば情報量を少なくすることが可能になる。
【００７９】
さて、本第２の実施形態の基本構成は、第１実施形態と以下の変更点を除き実質的に同じ構成で実現できる。
【００８０】
すなわちコマンド解釈手段１０１２における手順プログラムの、ステップＳ１０６、ステップＳ１１１、ステップＳ１１２をそれぞれ上記「+」で示された形式に従って処理するようにする。
【００８１】
なお、これに伴い、図３の予約テーブルにおける受け付けコードを、たとえば“12543-1”、“12543-2”、“12543-3”等のようにし、画像を記憶する際にもこれらの予約コードに従って格納する。そして、取り出しコマンドが来た場合には共通部分の予約コード（この場合には“12543”）を探し出し、ハイフンの後の数字の順序に従って画像データをあらためて、複数枚の画像データが含まれるひとつの画像データとしてフォーマットし直し通信インターフェース手段１０１１を介して要求元の外部装置１００２に返答する。
【００８２】
このときも、通信インターフェース手段１０１１では、ＨＴＴＰプロトコルを用いるため、画像フォーマットに応じた内容種別情報やステータス情報等が先頭に付加される。
【００８３】
そして、変更後のステップＳ１１２では、取り出した複数の画像データに関して、それぞれに対応する画像記憶手段１０１９の欄を消去する。
【００８４】
以上のように構成することにより、一度に多くの予約ができ、それらを複数枚の画像からなるひとつの画像データとしてまとめて取り扱うことが可能になり、それぞれの画像データごとに対応する複数の受付コードを管理する手間が省ける。
【００８５】
また、植物の成長記録等、間欠写真撮影などに適用すると、複数枚の撮影画像がひとつの画像データに納まる疑似動画として取り扱うことも可能になる。
【００８６】
また、その他の応用としては、第１の実施形態と同様にしても良いのは勿論である。
【００８７】
＜第３の実施形態＞
上記第２の実施形態では、同一のカメラアングルで同一時間間隔で間欠撮影する場合にも、撮影する数だけ予約コマンドを連結して指定しなければならなかった。
【００８８】
そこで、本第３の実施形態においては、予約コマンドの時刻指定の直後に、終了時刻と間欠時間を付加し、その後にカメラアングル等の撮影条件や画像フォーマットを指定することで、設定する情報量を削減する。ここでは、終了時刻は英字「t」に続く時刻で指定し、間欠時間は英字「e」に続く分単位の時間で指定する例を説明する。
【００８９】
たとえば、１９９６年７月６日１３時１５分と３０分と４５分にパン角２５度チルト角０度で３倍ズームで撮影し、３枚の画像をgifフォーマットで後に取り出す場合には、以下のように記述する。
【００９０】
<img src="http://www.foo.co.jp/R1996.7.6.13.15t1996.7.6.13.45e15P25T0Z3.gif">
ここで、本明細書では、「"」と「"」とで囲まれている文字列が２行以上にまたがって表示されているかもしれないが、実際の記述は、改行を含まない、一行で記述する。
【００９１】
もちろん、この場合も終了時刻の日時や時間が同じであった場合は、先に説明したように省略可能としてもよい。その場合は、上記と同じ予約を以下のように記述できる。
【００９２】
<img src="http://www.foo.co.jp/R1996.7.6.13.15t....45e15P25T0Z3.gif">
本第３の実施形態の基本構成は、第１実施形態と以下の変更点を除き実質的に同じ構成で実現できる。
【００９３】
すなわちコマンド解釈手段１０１２が実行するプログラムのステップＳ１０６、ステップＳ１１１、ステップＳ１１２をそれぞれ、上記仕様に合うように変更する。また、同時に時限手段１０１５におけるステップＳ２０７も上記仕様に合うように変更する。
【００９４】
また、この場合における、予約登録手段１０１４に登録されるテーブル形式は図６のようになる。
【００９５】
すなわち、図３のレコードに新たに、撮影の終了時刻及びその間欠時間を付加することになる。
【００９６】
一方、コマンド解析手段１０１２は、ステップＳ１０６では、要求された予約コマンドが、終了時刻と間欠時刻を持つ形であったら、予約時刻を撮影時刻として、終了時刻、間欠時間、受付コード、撮影条件、画像フォーマットとともに、予約登録手段１０１４に登録する。
【００９７】
また、要求された予約コマンドが単純な予約であり、終了時刻と間欠時刻を持たなかったら、終了時刻は撮影時刻と同じにし、間欠時刻は１に設定する。
【００９８】
ステップＳ１１１では、同じ予約コードで登録されている複数の画像データを取り出し、あらためて、複数枚の画像データが含まれるひとつの画像データとしてフォーマットし直し、通信インターフェース手段１０１１を介して要求元の外部装置１００２に返答すれば良い。
【００９９】
このときも、通信インターフェース手段１０１１では、ＨＴＴＰプロトコルを用いるため、画像フォーマットに応じた内容種別情報やステータス情報等が先頭に付加される。
【０１００】
また、ステップＳ１１２では、取り出した複数の画像データに関して、それぞれに対応する画像記憶手段１０１９の欄を消去することになるのは理解できよう。
【０１０１】
一方、時限手段１０１５は、ステップＳ２０７で、取り出した予約項目の間欠時間を撮影時刻に加えた情報で、登録された予約情報を更新し、撮影時刻が終了時刻より未来になった場合に、この項目を、予約登録手段２０１４から消去するようにする。
【０１０２】
以上のように構成することで、間欠写真が短いコマンドで、簡単に取れるようになる。
【０１０３】
特に、長期間に渡って間欠写真を取る場合、第２の実施形態のような方法だと、コマンドが非常に長くなり、実質的には実現できなくなる場合が多いが、本第３の実施形態によれば、画像データを蓄積する記憶装置の記憶量さえ充分に用意すれば実現できるようになる。
【０１０４】
＜第４の実施形態＞
上記第３の実施形態では、間欠撮影した結果を複数枚の静止画データとして取り出す形態を取ったが、本第４の実施形態では、動画データとして取り出す形態も付加する例を説明する。
【０１０５】
動画データとして取り出す時には、ファイルエクステンションをmpgにする。たとえば、以下のように記述する。
【０１０６】
<img src="http://www.foo.co.jp/R1996.7.6.13.15t....45e15P25T0Z3.mpg">
本第４の実施形態の基本構成を図７に示す。図示の如く、本第４の実施形態では、上記第１の実施形態と以下の変更点を除き実質的に同じ構成を有する。
【０１０７】
すなわちＭＰＥＧ１圧縮装置等の動画像圧縮手段２０２１が追加され、ファイルエクステンション“mpg”を解釈できるコマンド解釈手段４０１２を有する点である。
【０１０８】
この場合のプログラムのステップＳ１１１では、画像フォーマット指定がjpgやgif等の静止画フォーマットであれば、同じ予約コードで登録されている複数の画像データを取り出し、あらためて、複数枚の画像データが含まれるひとつの画像データとしてフォーマットし直し、通信インターフェース手段１０１１を介して要求元の外部装置１００２に返答する。
【０１０９】
また、画像フォーマットが「mpg」と指定されていたら、同じ予約コードで登録されている複数の画像データを取り出しそれぞれの画像を復元し、動画像圧縮手段２０２１に引渡して圧縮をかけ、その結果の動画像データを通信インターフェース手段１０１１を介して要求元の外部装置１００２に返答する。
【０１１０】
このときも、通信インターフェース手段１０１１では、ＨＴＴＰプロトコルを用いるため、画像フォーマットに応じた内容種別情報やステータス情報等が先頭に付加される。
【０１１１】
以上のように構成することにより、画像フレーム間の関連を用いた圧縮が行われ、特に、余り変化のない間欠写真などでは、大幅な画像データ圧縮が行われるため、後に画像データを取り出す時の通信量を削減でき、通信時間を大幅に短縮することが可能になる。
【０１１２】
＜第５の実施形態＞
第３の実施形態では、撮影するカメラアングルは同一のものであったが、本第５の本実施形態においては、予約コマンドの時刻指定の直前に、制御変数の定義を付加し、その後に時刻指定、その後にカメラアングル等の撮影条件や画像フォーマットを指定した繰り返し撮影が出来るようにする。
【０１１３】
制御変数の定義は、「$(」＋「定義本体」＋「)」の形式を採用する。ここで、定義本体には２つの書き方を定める。１つは初期値と終値、増分を指定するもので、増分が正か負かに依って更に２つの書き方に分かれる。また別の書式は制御変数のとる値を全て書き下す書き方である。すなわち、
$(<制御変数>=初期値,upto終値,up増分)
$(<制御変数>=初期値,downto終値,down増分)
または
$(<制御変数>=値１,値２,値３,値４,...値n)
である。
【０１１４】
ここで<制御変数>は英文字１文字以上からなる文字列で、制御変数の識別子である。
【０１１５】
制御変数の参照は、「$(」＋参照本体＋「)」とする。参照本体は制御変数を含む４則演算式である。
【０１１６】
たとえば、１９９６年７月６日１３時１５分に、
パン角２５度チルト角０度で３倍ズーム、
パン角３０度チルト角０度で３倍ズーム、
パン角３５度チルト角０度で３倍ズーム、
で撮影（パン角が５度ずつ変化させて撮影）し、３枚の画像をgifフォーマットで後に取り出す場合には、以下のように記述する。
【０１１７】
"http://www.foo.co.jp/R$(pan=25,upto35,up5)1996.7.6.13.15P$(pan)T0Z3.gif"
又は、
"http://www.foo.co.jp/R$(pan=0,upto10,up5)1996.7.6.13.15P$(pan+25)T0Z3.gif"
又は
"http://www.foo.co.jp/R$(pan=35,downto25,down5)1996.7.6.13.15P$(pan)T0Z3.gif"
又は
"http://www.foo.co.jp/R$(pan=25,30,35)1996.7.6.13.15P$(pan)T0Z3.gif"
ここで、本明細書では、「"」と「"」とで囲まれている文字列が２行以上にまたがって表示されているかもしれないが、実際の記述は、改行を含まない、一行で記述する。
【０１１８】
本第５の実施形態の基本構成は、基本的に第２の実施形態と同様であるが、コマンド解釈手段１０１２の処理プログラムにおけるステップＳ１０６は、図８に示すようになる。なお、「R」の次の文字が$である場合、これは制御変数の定義であるので、第５実施形態の予約コマンドとなる。
【０１１９】
まず、ステップＳ５０１で「$(」で始まり「)」で終る１つの制御変数定義を取得し、ステップＳ５０２で全ての定義を取り出したかを検査する。
【０１２０】
制御変数定義を全て取り出した後、ステップＳ５０３で制御変数を初期化する。
【０１２１】
ステップＳ５０４でコマンドの残りの部分をスキャンし「$(」で始まり「)」で終る制御変数参照を検索し、検索された制御変数値で、先に初期化された該当する変数を置き換える。こうして、検索された制御変数の個数分の置き換えが完了すると、処理はステップＳ５０６に進み、上記処理で得た文字列を、先に述べた繰り返し撮影の予約コマンドとして解析し、ステップＳ１０５で生成された予約コードと画像フォーマット情報は同じにし、それぞれの予約コマンドで指定された予約時刻と撮影条件を、複数の予約として予約登録手段１０１４に登録する。
【０１２２】
そして、ステップＳ５０７で次の段階になるよう、繰り返しによる制御変数を更新し、ステップＳ５０８で全制御変数が終了値になったと判断するまで、ステップＳ５０４以降の処理を繰り返す。
【０１２３】
以上のようにすることで、カメラアングルを変化させた間欠写真画像が短いコマンドで、簡単に得ることができるようになる。
【０１２４】
また、説明では制御変数の定義を１つだけ使ったが、この定義は複数書くことができる。その場合定義は入れ子になるものとする。
【０１２５】
なお、本第５の実施形態では、繰り返し構文の導入について説明したが、同様にして、条件判断構文や変数定義、変数代入や四則演算などの構文を導入することもできる。
【０１２６】
すなわち、コマンド解釈手段をプログラムインタプリタとして実現し、ＵＲＬの内容をプログラムとしてみなして保持し、解釈実行させるようにできる。
【０１２７】
このようにすると、複雑なカメラ制御等も自動的に実行できるようになる。
【０１２８】
＜第６の実施形態＞
第５の実施形態では、撮影するカメラアングルの指定は全て同じＵＲＬに記述しなくてはならなかった。
【０１２９】
そこで、本第６の実施形態においては、予約コマンドの一部をマクロライブラリとして別に登録しておくことができるようにする。
【０１３０】
ここでは、時刻指定と撮影条件を記述したデータを外部装置（ネットワーク上の適当なサーバー）に格納しておく例で説明する。
【０１３１】
説明のためたとえば、１９９６年７月６日１３時０分から以下のカメラアングルに１分毎に順に変化させ撮影を行うことを想定する。
パン角２５度チルト角０度で３倍ズーム(1996年7月6日13時0分)
パン角３０度チルト角０度で３倍ズーム(1996年7月6日13時1分)
パン角３５度チルト角０度で３倍ズーム(1996年7月6日13時2分)
パン角３５度チルト角１度で４倍ズーム(1996年7月6日13時3分)
パン角３５度チルト角２度で４倍ズーム(1996年7月6日13時4分)
パン角３５度チルト角３度で５倍ズーム(1996年7月6日13時5分)
パン角３５度チルト角４度で５倍ズーム(1996年7月6日13時6分)
パン角３５度チルト角５度で６倍ズーム(1996年7月6日13時7分)
パン角３５度チルト角５度で７倍ズーム(1996年7月6日13時8分)
パン角３５度チルト角５度で８倍ズーム(1996年7月6日13時9分)
これを指示するコマンドが格納されたファイルを、第２の外部装置に、
http://www.bar.co.jp/camcon-a.ctl
として格納しておく。つまり、この第２の外部装置のアドレスはwww.bar.co.jpである。
【０１３２】
この場合のファイルの内容は、たとえば、以下のようになる。
【０１３３】
R199６.7.6.13.0P25T0Z3+R1996.7.6.13.1P30T0Z3+R1996.7.6.13.2P35T0Z3+R1996.7.6.13.3P35T1Z4+R1996.7.6.13.4P35T2Z4+R1996.7.6.13.5P35T3Z5+R1996.7.6.13.6P35T4Z5+R1996.7.6.13.7P35T5Z6+R1996.7.6.13.8P35T5Z7+R1996.7.6.13.9P35T5Z8.gif
これを利用するためカメラ制御装置に与えるコマンドは、「%23(」で始まり、URLが引続き、「)」で終る形式にする。上記の場合には、そのコマンドファイルのアドレスを知らせることが必要になるので、以下の通りになる。
【０１３４】
"http://www.foo.co.jp/%23(httpd%3A//www.bar.co.jp/camcon-a.ctl)"
本実施形態の基本構成は図9に示す通りになる。なお、第５実施形態と比較すると、コマンド解釈手段６０１２が上記コマンドを解釈できるようになった点と、第２の外部装置（コマンド文字列を有するファイルを記憶保持しているサーバ）と接続状態にある点である。
【０１３５】
コマンド解釈手段６０１２の動作を図１０のフローチャートに従って説明する。
【０１３６】
ステップＳ６２１で、ファイル名として記述されたコマンドを解釈する。
【０１３７】
要求の先頭が「%23」であれば外部参照コマンドと認識し、ステップＳ６２２に進む。
【０１３８】
このステップＳ６２２では、「(」と「)」にはさまれた部分を、コマンドが記述されて格納されたファイルの指定のＵＲＬとみなし、このＵＲＬにしたがってファイル転送要求を発する。上記の例では「www.bar.co.jp」にファイルが格納されているわけであるから、図１０における第２の外部装置１００４に要求を発することになる。
【０１３９】
そして、ステップＳ６２３で、返答を待つ。この結果、上記のような、長い予約コマンドが返される。ここで解釈した外部参照コマンドをこれに置き換えるようにして展開し、以降のコマンド解釈に適用できるようにする(ステップＳ６２４)。この後ステップＳ１０１に進むことになる。
【０１４０】
なお、ステップＳ６２１で、外部参照コマンドではなかった場合も、ステップＳ１０１に進むことになる。これ以降は、第１の実施形態での説明に準じたものであるので、その説明は省略する。
【０１４１】
また、第１の実施形態だけでなく、第２〜第５の実施形態にもそれぞれ適用できるのも勿論である。
【０１４２】
以上のように構成することで、複雑な時間予約やカメラアングルを複雑に変化させた間欠写真が短いコマンドで、簡単に取れるようになる。
【０１４３】
特に、第６の実施形態に従えば、インターネット上に複数のカメラ制御装置（つまり、複数のカメラ）があって、同じ撮影状態での画像を鑑賞する分には、１つのサーバーに撮影手順のコマンドを記述したファイルを格納しておけば、それを活用することが可能になる。
【０１４４】
たとえば、カメラ制御装置が諸外国のいたる所に設置しているような場合であっても、それぞれを自分流の撮影条件で鑑賞することは勿論、第３者が登録した撮影条件に従って鑑賞することも可能になる。
【０１４５】
また、第６の実施形態では、カメラ制御装置とカメラ制御用ファイルを記憶している外部装置を異なる装置のように説明したが、この２つの装置が同じであってもよい。その場合、URLは以下のように書ける。
"http://www.foo.co.jp/%23(httpd%3A//www.foo.co.jp/camcon-a.ctl)"
又は、ＵＲＬが同じである場合に限って、
"http://www.foo.co.jp/%23(camcon-a.ctl)"
もちろん、最初に要求をかける外部装置にコマンドが格納されているならば、そのアドレスを用いればよい。その時は、第二の外部装置は不要である。
【０１４６】
＜第７の実施形態＞
上記第１〜第６の実施形態では、撮影した映像データはすべて一旦ファイルとして格納されたものを転送する例であった。特に、第５の実施形態では動画も、結局のところファイルとして転送するものであった。
【０１４７】
そこで、本第７の実施形態では、リアルタイムに撮影している映像データを転送することで、クライアントに対してリアルタイム動画（そのカメラがその時点で撮影している生の映像）をサービスする例を説明する。
【０１４８】
説明を簡単にするため、ビデオカメラは１／６０秒単位に映像を取り込む能力を有するものとし、それを順次転送する場合を説明する。
【０１４９】
ここで問題になるのは、例えばインターネットでリアルタイムの動画映像を転送し、表示するためには、その通信回線のトラフィックの影響を無視できないという点である。
【０１５０】
なぜなら、リアルタイムの撮影映像の場合、例えば、カメラで１秒間に６０枚のフレームを撮影できたとしても、トラフィックの混雑によっては実際に転送できるフレーム数が変動してしまうからである。つまり、本来、１／６０秒の間隔で映像を転送すべきところが、ある箇所では１／３０秒になったりして、撮影された映像を単純に転送していたのでは、もはやリアルタイムの映像としての価値がなくなることを意味する。勿論、本来、等時間間隔に撮影した映像が、等間隔に要求元に転送されないわけであるから、結果的に再生し表示される画像も不自然になる。
【０１５１】
そこで、本第７の実施形態では、カメラ制御装置は、動画要求元に動画をリアルタイムに転送する際、トラフィックの影響（回線の混雑の度合）を検出し、その検出された内容に応じて撮影映像を転送する。
【０１５２】
この検出の具体的な手段としては、１フレーム分の画像データを転送要求元に転送すると、その転送要求元からアクノリッジが返送されてくるので、この転送を開始してからアクノリッジが返送されてくるまでの時間を計り、これによって現在のトラフィック状態を検出するものとした。なお、１フレーム分の画像データの量は転送する直前では判明しているから、そのデータ量とアクノリッジの応答時間によって、決定しても良い。また、場合によっては、適当なサイズ（既知）のダミーファイルを転送し、そのアクノリッジを受けるまでの時間を測ってもよい。
【０１５３】
そして、この検出結果が、次のタイミングで映像を転送する際のトラフィックの状態と実質的に同じとなっているももと予想し、それによって映像転送を制御する。
【０１５４】
ここで、カメラが１／６０秒で映像を取り込める性能を有しているものとし、取り込まれたフレームをＦ１、Ｆ２…Ｆｎと定義する。フレームＦ１を転送してから、転送要求元からのアクノリッジが返送される時間がたとえば１／３０秒要したとする。この場合、先に転送した次のフレームＦ２の転送を行ってしまうと、もはやその後に転送しようとする映像のリアルタイム性が失われることになるので、そのフレームＦ２の代わりに、フレームＦ３の転送を行う。そして、このフレームＦ３を転送した場合においてもそのアクノリッジが返送されるまでの時間を計時し、次のフレーム転送の制御に役立てる。
【０１５５】
以上のように制御すると、少なくとも要求元には、回線の混雑の度合が少ない場合には、実質的にカメラの撮影の能力を最大限に発揮したリアルタイム動画を鑑賞できるし、回線が混雑した場合であっても、表示される映像のリアルタイム性は維持できるようになる。
【０１５６】
なお、回線の状態によっては、上記のとおり、スキップするフレームがあるわけであるから、フレーム間の差分の符号化を含むＭＰＥＧは採用できないので、本第７の実施形態ではフレーム毎に符号化するモーションＪＰＥＧを採用する。
【０１５７】
また、符号化された１フレームの情報量は、一律に固定サイズにはならないので、厳密には１フレーム毎の転送にかかる時間は、フレーム毎に多少変動するがその変動幅は適度な範囲内であることを確認しているので、実害はない。
【０１５８】
以下、本第７の実施形態の動作処理内容を図１１〜図１４のフローチャート及び図１５のカメラ制御装置のブロック図にしたがって説明する。
【０１５９】
図１５において、１０１１はカメラ制御装置（カメラサーバ）のＷＷＷインタフェースであり、ＨＴＴＰプロトコルにしたがってＨＴＭＬで記述されたデータを解釈し、動作する。８００１は装置全体の制御を司っているシステム制御手段であり、主として静止画制御手段８００２と動画制御手段８００３、カメラ制御手段１０１７を制御する。また、システム制御手段８００１には、カメラ１００３の動作状態（パン、チルト、ズーム等の状態）を記憶するためのカメラ状態記憶手段を備えている。
【０１６０】
図１１は、第７の実施形態におけるシステム制御手段８００１の動作処理手順を示している。なお、同フローチャートは、既に撮影した映像を動画として要求もとである外部装置８０５０に映像情報を転送している場合の処理を示している。
【０１６１】
まず、ステップＳ１１０１で、外部装置からの要求かどうかを判定する。外部装置からの要求ではないと判定した場合には、ステップＳ１１０２に進み、通信状態を監視し、トラフィックが多いかどうかを判定する（先に説明したようにアクノリッジの返送されるまでの時間で検出し、その時間で判定する）。トラフィックの混雑が所定以上であると判定した場合には、ステップＳ１１０４に進み、トラフィックの混雑の状態に応じて、動画のデータ量を減らすように動画制御手段８００３に指示する。そして、同様に、カメラ制御手段１０１７に対して、トラフィックの混雑の状態に応じた動作レスポンスになるよう指示する。
【０１６２】
たとえば、トラフィックが大きければカメラの動作レスポンスを落とすように指示が与えられる。
【０１６３】
カメラ制御手段１０１７は、この指示を受けると、カメラ１００３のパン、チルト、及びズームの駆動速度を落とすよう制御する。すなわち、与えられたパン角、チルト角、ズーム比率の変更の指示に対して応答速度が低くなるように制御する。この理由は、たとえば撮影している最中に、先の各実施形態で説明した形式の要求を受信してパン等を行うと、トラフィックが混雑していて時間間隔の大きい映像を転送することになるので、一気にアングルの変わった映像を転送してしまうからである。この点、上記のようにカメラ制御手段１０１７がカメラ１００３のパン、チルト及びズームの動作速度を落とすと、スムースが映像、すなわち、パン中であれば、そのパンの過程の映像が転送されることになる。
【０１６４】
ステップＳ１１０６に処理が進むと、動画制御手段８００３は、画像入力手段１０１８で順次得られる各フレーム分の画像データのうち、指示された単位時間当たりのデータ量にすべく、入力したフレームの取捨選択を行ない、選択したフレームの画像データを動画圧縮手段８０２０に出力し、要求元である外部装置８０５０に転送する。なお、トラフィックが混雑していないと判定した場合には、ステップＳ１１０４の処理は行わないので、得られた映像を順次動画圧縮手段８０２０に出力し、圧縮及び転送を行わせる。
【０１６５】
さて、ステップＳ１１０１で、外部装置８０５０とは異なる外部装置８０４０からの要求があったと判断した場合には、処理はステップＳ１１０７に進む。つまり、カメラ１００３で撮影してそれを順次転送することで動画として外部装置８０５０に転送している最中に、他の外部装置からの要求があった場合である。
【０１６６】
ステップＳ１１０７では、その要求が静止画要求であるか否かを判定する。静止画要求ではないと判定した場合には、ステップＳ１１０８に進み、対応する処理を行う。たとえば、動画要求であると判定した場合には、外部装置８０５０への映像データと同じものを外部装置８０４０に転送を行わせる。
【０１６７】
また、静止画要求であると判定した場合には、ステップＳ１１０９に進み、静止画制御手段を駆動し、ステップＳ１１１０で通信インターフェースを介して外部装置８０４０にカメラ１００３で撮影した映像を静止画として転送する。
【０１６８】
ここで、ステップＳ１１０９の詳細を図１２のフローチャートに従って説明する。同フローチャートは、静止画制御手段８００２の動作内容である。
【０１６９】
静止画の場合その品位は、動画の１フレームより高くする必要がある。そこで、本第７の実施形態では、動作として転送中にこのような要求があった場合には、カメラ制御手段１０１７を介して静止画撮影用に、カメラ１００３がパン中であればそれを一時的に停止させると共に、その停止する以前の状態をカメラ状態記憶手段８００２に格納させ、静止画として撮影し、転送する。そして、この転送が復帰させる。
【０１７０】
具体的には、ステップＳ１２０１でカメラ制御手段１０１７に静止画要求を出し、ステップＳ１２０２でカメラ制御を行わせる。そして、ステップＳ１２０３で、カメラ制御手段１０１７からの静止画撮影可能状態になったことを示す通知を待つ。
【０１７１】
この通知を受けると、処理はステップＳ１２０４に進み、動画制御手段に８００３対して静止画圧縮要求を出し（詳細は後述）、得られた映像像を静止画圧縮手段８０１０に出力するよう指示する。
【０１７２】
そして、ステップＳ１２０５に進み、静止画圧縮手段８０１０から圧縮された静止画データを受取り、ステップＳ１２０６でシステム制御手段８００１に渡し、待機状態になる。
【０１７３】
次に、上記ステップＳ１２０２の動作処理内容を、図１３のフローチャートに従って説明する。同処理はカメラ制御手段のものである。
【０１７４】
まず、ステップＳ１３０１で静止画要求であるかどうかを判定する。静止画要求ではないと判断した場合には、それ以前の状態でカメラを制御する。
【０１７５】
一方、静止画要求であると判断した場合には、ステップＳ１３０２に進み、現在、接続している外部装置（動画要求元）に対し、一時制御できない旨を通知する。これを受けて、要求元では、そのブラウザ等の表示画面にその旨のメッセージ等を表示することになる。そして、ステップＳ１３０３で現在のカメラ状態をカメラ状態記憶手段に保存する。
【０１７６】
ステップＳ１３０４では、設定された静止画用のカメラ１００３を設定されたパラメータで制御し、この制御が完了した後、完了通知を静止画制御手段に通知する。
【０１７７】
この後、ステップＳ１３０６に進んで、静止画の取り込み処理が行われていることを確認し、カメラ状態記憶手段８００２から以前の状態を読み出して、ステップＳ１３０７で以前の状態（動画の取り込みであったなら、その状態）に復帰させる。
【０１７８】
そして、ステップＳ１３０８に進んで、制御権が一時的になくなった外部装置があれば（上記例では外部装置８０５０）に対して、制御権が復帰したことを通知し、ステップＳ１３０９でカメラの制御を継続する。
【０１７９】
次に、図１１におけるステップＳ１１０６、及び図１２におけるステップＳ１２０４における静止画要求を受けた場合の動画制御手段８００３の内容を図１４のフローチャートに従って説明する。
【０１８０】
まず、ステップＳ１４０１において、静止画要求があったか否かを判断する。静止画要求ではないと判断した場合には、動画のデータ量を減らすのかどうかを判断し、データ量を減らすよう指示されている場合には、ステップＳ１４０５に進んで、動画圧縮手段８０２０に単位時間当たりのデータ量を減らすべく、指示する。そして、ステップＳ１４０６に進んで、動画圧縮手段８０２０に映像を送り、動画を要求元（外部装置８０５０）に転送させる。
【０１８１】
一方、ステップＳ１４０１で、静止画要求を受けたと判定した場合には、ステップＳ１４０２に進んで、映像を静止画圧縮手段８０１０に送り、ステップＳ１４０３に進んで、静止画として圧縮させ、要求元（外部装置８０４０）にてんそうを行わせる。
【０１８２】
以上の結果、本第７の実施形態に従えば、カメラで撮影されたリアルタイムの映像を、動画として転送する際に、回線の混み具合に応じてデータ量を減らすことになるので、少なくとも要求もとに届く映像は、そのリアルタイム性が失われることがなくなる。また、カメラをパンやチルト、或いはズーム中等、アングルにかかる状態が変化しつつあり、尚且つ、回線が混雑している場合には、そのカメラのアングルの変動制御を遅くすることで、要求元に対しては違和感のない、自然な動画として再生させることが可能になる。
【０１８３】
なお、上記第７の実施形態では、データ量を減らす手段として、フレーム単位の映像を間引くことで行ったが、たとえば、文字通り１フレーム当たりの情報量を減らすことで対処してもよい。この場合には、抜けフレームが存在しない状態でも転送しても良いので、ＭＰＥＧ形式で符号化することが可能になる。つまり、フレーム間符号化が採用できる。データ量を落とすには、たとえば、ＭＰＥＧにおける直交変換した後の、高周波成分領域を“０”でマスクすれば、発生する符号量は低くできる。つまり、このマスクする大きさを、回線の混雑の度合に応じて調整してやれば良い。なお、当然のことであるが、マスクする領域を大きくすると、画質は劣化する方向になるが、リアルタイムな動画を転送できるようになる。
【０１８４】
また、上記第７の実施形態に従えば、１つのカメラを静止画カメラ、動画カメラの両方として活用でき、しかも、それが実質的に同時に機能させることができるようになる。
【０１８５】
図１６は、上記カメラ制御装置及び外部装置（クライアント）のハード及びソフトウェアの構成概念図を示している。
【０１８６】
図示の如く、カメラサーバ（カメラ制御装置）には、そのハードウェアとして、パーソナルコンピュータ等の情報処理装置（図示のＰＣ）をはじめ、カメラで撮影された映像を圧縮するための画像圧縮ハード、ネットワークインタフェース、及びカメラのアングル等の状態を指示するためのシリアルインタフェースで構成される。
【０１８７】
同様に映像要求元、つまり、クライアント装置（上記実施形態における外部装置）は、ネットワークインタフェースを有する情報処理装置で構成される。
【０１８８】
ソフトウェアとして、それぞれのハードウェア（特にＰＣ）上で動作するＯＳがある。クライアント装置には、そのハードウェアによって、Ｗｉｎ３２（米国マイクロソフト社が提供しているＯＳ）、マックＯＳ（米国アップル社が提供しているＯＳ）、Ｓｏｌａｒｉｓ（米国ＳＵＮ社が提供しているＳＰＡＲＫで動作するＯＳ）等、様々なＯＳを使用可能としている。また、カメラ制御装置側では、たとえばＷｉｎ３２とした。
【０１８９】
上記ＯＳ上で、上記第７の実施形態における各手段に相当する処理を実行することになるが、たとえば、カメラ制御装置上で動作するプログラムには、クライアントとの論理的な通信を行うためのＷＷＷインタフェース（物理的な通信はネットワークインタフェースで行う）と、その動作環境を提供する静止画配送部を有する。また。静止画配送部に映像データを送出するための映像圧縮配送部と実際の画像圧縮プログラムであるVideo for Windows（Ｗｉｎ３２における標準的な動画処理用プログラム）やＪＰＥＧプログラムがＯＳに乗っている。また、クライアントからカメラ制御プロトコル形式で受け取ったカメラ制御パラメータに従ってカメラの駆動を行うカメラ制御部とカメラのハードウェアに直結したパラメータに翻訳するＶＣ−Ｃ１ドライバがＯＳに乗っている。
【０１９０】
次に、本実施形態の動作について図面を用いて説明する。
【０１９１】
本実施形態においては、ＷＷＷインタフェースを有するサーバとクライアントとの間の画像データの伝送を説明する。
【０１９２】
かかる実施形態においては、カメラサーバ、クライアントそれぞれに静止画配送受のための構成と動画送受のための構成が設けられている。静止画送受のためには、ＨＴＴＰプロトコルと呼ばれるインターネットに対応している方法にて静止画を１つのファイルとして転送される。動画送受のためには、ＨＴＴＰプロトコルとは異なるプロトコルで転送される。
【０１９３】
ＨＴＴＰプロトコルにおいては、静止画が１つの画像ファイルとしてＷＷＷブラウザからの要求に従ってカメラサーバからクライアントへ転送され、転送が完了するとカメラサーバとクライアントとの間のデータ転送は断たれる。
【０１９４】
また、雲台付きビデオカメラの制御情報、具体的には、たとえばパン、チルト、ズーム等の制御情報はＨＴＴＰプロトコルによってカメラサーバに伝達される。
【０１９５】
また、動画送受の際には、該動画の構成する多数の静止画が連続して、換言すれば、中断することなくカメラサーバからクライアントへ転送される。かかる場合には、前述のビデオカメラの制御情報はＨＴＴＰプロトコルであはなく、図１６に示すカメラ制御プロトコルで動作する。
【０１９６】
因に、ＶＣ−Ｃ１ドライバで実際にカメラのパン等の制御データが構築されるが、それはＯＳを介してシリアルインタフェース上に出力することで行われることになる。
【０１９７】
一方、クライアント装置側では、カメラ制御装置からの映像や文字等を表示するためのＷＷＷブラウザと、カメラ制御装置に対してカメラ制御パラメータを送信したり、カメラ制御装置からの動画データを受信するための動画ヘルパ／プラグインが上記ＯＳ上で動作することになる。
【０１９８】
なお、上記第７の実施形態における静止画を転送するプロトコルとしては、ＨＴＴＰ、ファイル転送プロトコル、マルチキャストに対応したプロトコルを用いる。また、この際のプロトコルは前記ＨＴＴＰに前記撮像手段を制御する制御信号を含ませたプロトコルを用いている。
【０１９９】
また、動画転送用のプロトコルは、映像配送プロトコルとカメラ制御プロトコルとを含むでいる。すなわち、静止画転送と動画転送とでは、その制御手段の応答特性をそれぞれに対応して異ならしめている。
【０２００】
また、上記実施形態では特に説明しなかったが、一度に複数箇所からカメラ制御件獲得要求があった場合には、その中のいずれか１つに制御権を与えることになる。制御権を与えるのは、制御権のキューに格納された先頭のユーザにするものとするが、特定のユーザ等の場合には優先的に制御権を与えるようにしても良いであろう。
【０２０１】
しかし、この制御権に関しては、本願発明に直接は関係がないので、これ以上の説明は省略する。
【０２０２】
尚、本発明は、複数の機器から構成されるシステムに適用しても、１つの機器からなる装置に適用しても良い。
【０２０３】
また、本発明の目的は、上述した各実施形態のサーバ及び端末の機能を実現するソフトウェアのプログラムコードを記憶した記憶媒体を、システム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読出して実行することによっても、達成されることは言うまでのもない。
【０２０４】
この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。
【０２０５】
プログラムコードを供給するための記憶媒体としては、例えばフロッピーディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭ等を用いることができる。
【０２０６】
また、コンピュータが読出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳなどが実際の処理の一部または全部を行ない、その処理によって実施形態の機能が実現される場合も含まれることは言うまでもない。
【０２０７】
更に、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された拡張機能ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行ない、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０２０８】
【発明の効果】
以上説明したように本発明によれば、撮像手段で得られたリアルタイムの静止画及び動画像をインターネットを介して良好に送信できるようになる。
【０２１３】
【図面の簡単な説明】
【図１】実施形態におけるカメラ制御装置のブロック構成図である。
【図２】実施形態のコマンド解釈手段の動作処理手順を示すフローチャートである。
【図３】実施形態における予約登録手段で登録されるデータ形式の一例を示す図である。
【図４】実施形態の画像記憶手段の記憶されたデータの管理形式の一例を示す図である。
【図５】実施形態における時限手段の動作処理手順を示すフローチャートである。
【図６】第３の実施形態における予約登録手段で登録されるデータ形式の一例を示す図である。
【図７】第４の実施形態におけるカメラ制御装置のブロック構成図である。
【図８】第５の実施形態の予約登録の処理手順を示すフローチャートである。
【図９】第６の実施形態におけるカメラ制御装置のブロック構成図である。
【図１０】第６の実施形態の制御変数置き換え処理のフローチャートである。
【図１１】第７の実施形態におけるシステム制御手段の動作内容を説明するためのフローチャートである。
【図１２】第７の実施形態における静止画制御手段の動作内容を説明するためのフローチャートである。
【図１３】第７の実施形態におけるカメラ制御手段の動作内容を説明するためのフローチャートである。
【図１４】第７の実施形態における動画制御手段の動作内容を説明するためのフローチャートである。
【図１５】第７の実施形態におけるカメラ制御装置のブロック構成図である。
【図１６】第７の実施形態におけるカメラ制御装置とクライアントのハードウェア及びソフトウェアの関係を示す図である。
【図１】
0003862321.tif 000002
【図２】
0003862321.tif 000003
【図３】
0003862321.tif 000004
【図４】
0003862321.tif 000005
【図５】
0003862321.tif 000006
【図６】
0003862321.tif 000007
【図７】
0003862321.tif 000008
【図８】
0003862321.tif 000009
【図９】
0003862321.tif 000010
【図１０】
0003862321.tif 000011
【図１１】
0003862321.tif 000012
【図１２】
0003862321.tif 000013
【図１３】
0003862321.tif 000014
【図１４】
0003862321.tif 000015
【図１５】
0003862321.tif 000016
【図１６】
0003862321.tif 000017