(57)【要約】【課題】  搭載されているユーザーインターフェイスを用いて、閲覧者の使用感低下を解決し、ユーザービリティを向上させる。【解決手段】  ネットワーク上のカメラ装置１−３の制御の挙動に応じて、携帯電話クライアント１−４のバイブレータ駆動機能、イルミネーション機能、音声出力機能のいずれかを用いてカメラ制御者に対してカメラ状態変化を通知する。【選択図】  図１
2005151019.tif 000002
【特許請求の範囲】
【請求項１】
バイブレータ駆動手段、イルミネーション駆動手段、及び音声出力手段の少なくとも１つを備え、ネットワークを介して接続されるカメラを制御可能な携帯端末装置であって、
ネットワーク上のカメラ制御の挙動に応じて、前記バイブレータ駆動手段、前記イルミネーション手段、前記音声出力手段のいずれかを用いてカメラ制御者に対してカメラ状態変化を通知する通知手段を有することを特徴とする携帯端末装置。
【請求項２】
前記カメラは複数の携帯端末装置と接続されカメラ制御権を有する携帯端末装置により制御可能であり、
前記通知手段は、前記カメラ制御権の変化をカメラ制御者に通知する事を特徴とする請求項１に記載の携帯端末装置。
【請求項３】
前記カメラ制御権の状態変化を検知する検知手段をさらに有し、
前記通知手段は、前記検知手段の検知結果に応じて、前記カメラ制御権の変化をカメラ制御者に通知する事を特徴とする請求項２に記載の携帯端末装置。
【請求項４】
バイブレータ駆動手段、イルミネーション駆動手段、及び音声出力手段の少なくとも１つを備え、ネットワークを介して接続されるカメラを制御可能な携帯端末装置の制御方法であって、
ネットワーク上のカメラ制御の挙動に応じて、前記バイブレータ駆動手段、前記イルミネーション手段、前記音声出力手段のいずれかを用いてカメラ制御者に対してカメラ状態変化を通知することを特徴とする携帯端末装置の制御方法。
【請求項５】
バイブレータ駆動手段、イルミネーション駆動手段、及び音声出力手段の少なくとも１つを備え、ネットワークを介して接続されるカメラを制御可能な携帯端末装置の制御方法を実行するためのプログラムであって、
ネットワーク上のカメラ制御の挙動に応じて、前記バイブレータ駆動手段、前記イルミネーション手段、前記音声出力手段のいずれかを用いてカメラ制御者に対してカメラ状態変化を通知することを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、バイブレータ駆動手段、イルミネーション駆動手段、及び音声出力手段の少なくとも１つを備え、ネットワークを介して接続されるカメラを制御可能な携帯端末装置、携帯端末装置の制御方法、及びプログラムに関するものである。
【背景技術】
【０００２】
従来、アナログ線を前提とした監視カメラシステムが、銀行やコンビニエンスストア、スーパー、宝石店、消費者金融等のあらゆる業種の店内などに強盗や窃盗、万引き防止のために設置されている。しかし、近年このようなアナログ線を前提とした監視カメラシステムの画像情報の伝送にＴＣＰ／ＩＰなどのデジタル信号を前提とした遠隔カメラシステムが実用化されてきている。このようなカメラは、ＴＣＰ／ＩＰというグローバルなプロトコルを前提としたシステムである為、大域ネットワークとしてインターネット等の地球規模のデジタル回線網を用いる事が可能であり、遠隔地からの映像の閲覧を行う事も可能である。更にこれらのシステムを一般に開放する事によって放送的なライブ中継も可能であり、このような用途の目的でも実用化されて来ている。一般にこのようなカメラシステムをネットワークカメラとしている。
【０００３】
これらのネットワークカメラの中には、ただ遠隔地で映像を観察出来るだけでなく、カメラの雲台を制御する事によってパン・チルト・ズーム等のカメラ制御等も行う事が出来るシステムが実用化されている。
【０００４】
この種類のネットワークカメラは、多人数から同時に閲覧されると同時に多人数からカメラが制御される可能性がある。
【０００５】
映像は多人数が同時に見ることは可能であるが、カメラ制御に関しては、多人数が同時に制御すると制御の競合が発生する為、全員が意図したカメラ制御を実施する事が出来ない。そこで、一定の時間特定の１人に対してカメラ制御を許す権利を与え、その権利を交代で制御者に対して配布をするといったシステムが実用化されている。このシステムは、カメラ制御権という概念を導入し、カメラ制御権を特定の人にだけ割り当てる事で、カメラ制御を特定の一人だけに許し、正常なカメラ制御を行えるようにしたものである。カメラ制御を行いたい閲覧者は、カメラサーバに対してカメラ制御権を要求し、そのカメラ制御権を取得出来れば、一定の時間カメラを操作する事が可能になる。誰かが既にカメラ制御権を取得している場合は、そのカメラ制御権の要求をキューイングし、一定時間経過毎に、そのキューに従って、順番に制御権を割り振るといった仕組みを導入している。カメラ制御がそれぞれの閲覧者に一定時間ずつ割り当てられ、正常に多人数の閲覧者のカメラ制御を行えるようにしたシステムとなっている。
【０００６】
一方、近年、携帯電話等のモバイル機器は、ｉＭｏｄｅに代表されるようなＷＷＷ閲覧機能やメール送受信機能が備わって来ており，ＴＣＰ／ＩＰやＨＴＴＰなどのプロトコルの使用が可能になっている。その為、携帯電話でも映像やデジタル情報の送受信が可能になっている。これらを用いて、ネットワークカメラを携帯電話で閲覧操作するなどのシステムが実用化されてきている（特許文献１参照）。
【特許文献１】特開２００３−２９９０６９号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
近年の携帯電話は、従来にない多彩なユーザーインターフェイス装置が搭載されて来ている。例としては、携帯電話にバイブレータが搭載され、振動で通知を行う機能や、電話番号やＷｏｒｌｄＷｉｄｅＷｅｂや映像を見るためのディスプレイ以外にも、ＬＥＤなどの明かりを点滅させるイルミネーション機能などが搭載されている。
【０００８】
このように非常に機能が高くなってきた携帯電話であるが、これらの携帯電話等をネットワークカメラの閲覧用のクライアントとして用いた場合、通常のＰＣや高速なＬＡＮを用いた場合と比べて環境的に違いがあり問題点が存在する。
【０００９】
その一つとして、携帯電話は固定線接続などの高速なネットワーク接続網に比べると、比較的、低周波数帯な無線を用いる為、非常に回線スピードが遅くクライアントのリクエストに対するサーバのレスポンスが遅いなどの通信の遅延が発生する。
【００１０】
また、１つのカメラの操作を多人数で共有するため、閲覧者が非常に多数の場合、カメラの制御権を取得する場合に非常に待たされる可能性がある。これは、閲覧者の使用感を著しく低下させる原因ともなっていた。
【００１１】
特に、カメラ制御時に必要となるカメラ制御権の取得などの通知は、そのカメラ制御権取得を待つ閲覧者に待つ事を強いてしまう。これらの通知をバイブレータ等の携帯電話に搭載されている機能を用いて効率的に、閲覧者に対してその変化を通知することで、情報を表示するディスプレイを閲覧者が凝視して待つという動作から開放する事が可能になる。
【００１２】
本発明は、このような問題点を解決するために、搭載されているユーザーインターフェイスを用いて、閲覧者の使用感低下を解決し、ユーザービリティを向上させた携帯端末装置、携帯端末装置の制御方法、及びプログラム目的とする。
【課題を解決するための手段】
【００１３】
上記目的を達成するために、本発明の携帯端末装置は、バイブレータ駆動手段、イルミネーション駆動手段、及び音声出力手段の少なくとも１つを備え、ネットワークを介して接続されるカメラを制御可能な携帯端末装置であって、ネットワーク上のカメラ制御の挙動に応じて、前記バイブレータ駆動手段、前記イルミネーション手段、前記音声出力手段のいずれかを用いてカメラ制御者に対してカメラ状態変化を通知する通知手段を有することを特徴とする。
【００１４】
また、本発明の携帯端末装置の制御方法は、バイブレータ駆動手段、イルミネーション駆動手段、及び音声出力手段の少なくとも１つを備え、ネットワークを介して接続されるカメラを制御可能な携帯端末装置の制御方法であって、ネットワーク上のカメラ制御の挙動に応じて、前記バイブレータ駆動手段、前記イルミネーション手段、前記音声出力手段のいずれかを用いてカメラ制御者に対してカメラ状態変化を通知することを特徴とする。
【００１５】
また、本発明のプログラムは、バイブレータ駆動手段、イルミネーション駆動手段、及び音声出力手段の少なくとも１つを備え、ネットワークを介して接続されるカメラを制御可能な携帯端末装置の制御方法を実行するためのプログラムであって、ネットワーク上のカメラ制御の挙動に応じて、前記バイブレータ駆動手段、前記イルミネーション手段、前記音声出力手段のいずれかを用いてカメラ制御者に対してカメラ状態変化を通知することを特徴とする。
【発明の効果】
【００１６】
本発明によれば、カメラ制御権の状態の変化に応じて、携帯電話クライアントでカメラ制御権の状態変化について画像を凝視する以外の方法でカメラ制御者が認知する事が可能となり、カメラ制御権の取得を確認する為だけの為に、画像を凝視する必要がなくなり、カメラ制御者の利便性が向上する事が出来る。
【発明を実施するための最良の形態】
【００１７】
以下、図面を参照して本発明の実施の形態を説明する。
【００１８】
（第一の実施形態）
第１の実施形態では、ネットワークカメラサーバの挙動に対して、挙動のレスポンスの速さ（携帯電話クライアントに予め時間を設定しておく）に応じてクライアント側でサーバ側のレスポンス状態を判断して、バイブレータやイルミネーションの制御を行う事が特徴である。本実施形態について図面を基に説明する。
【００１９】
図１は、システム全体の構成を示している構成図である。本システムは全体として、雲台装置が接続されたカメラ装置１−３と、その映像装置の映像を携帯電話クライアントに転送する映像サーバ１−２と、雲台を制御するカメラ制御サーバ１−２と、それらの画像を受信表示し、かつ、カメラ制御を可能とするインターフェイスを提供する携帯電話クライアント１−４と、それをつなぐネットワーク網１−１から構成される。
【００２０】
ここで用いられているネットワーク１−１は、インターネットで使用されているＴＣＰ／ＩＰネットワーク網を用いている。このネットワークの構成は物理的な形態は、固定線であっても無線であっても構わない。ＴＣＰ／ＩＰ以外の論理プロトコル（ＩＰＸ／ＳＰＸや携帯電話の場合はそのプロバイダ固有のネットワークプロトコル）を用いても構わない。ネットワークは、非常に種類が多岐に渡る為、本実施形態では、ネットワークは抽象的デジタル信号通信ネットワーク網として以降扱う。
【００２１】
カメラ装置１−３は、映像を撮影する部分であるカメラ装置部と、そのカメラ装置部を各種方向に向ける雲台装置部から構成されている。この二つの装置は、カメラ制御サーバからの情報を受け、パン・チルト・ズーム等の動作を行う事が可能である。撮影された映像は、映像サーバに送られデジタルデータにキャプチャされ圧縮などの処理がされる。
【００２２】
１−２は、映像サーバ及びカメラ制御サーバを示している。映像サーバは、カメラ装置からの画像を入力ソースとして撮影映像をキャプチャして映像をデジタル化し、その画像データを圧縮する。そして、映像取得要求のある携帯電話クライアントに対して画像データを送出する。
【００２３】
カメラ制御サーバは、接続した携帯電話クライアントからのカメラ制御権取得要求やカメラ制御要求を受信する。そして、カメラ制御権という概念を導入し、特定の閲覧者にのみに対してカメラ制御を許可し、そのカメラ制御情報を雲台装置に通知する。
【００２４】
１−３と１−２で構成されるカメラ装置や雲台装置や映像サーバやカメラ制御サーバが、一つの装置として実用化されている例もあり、必ず物理的に分離する必要はない。又、映像撮影に関してもアナログ方式を用いず、全て完全にデジタル方式で処理する例もあるが、本実施形態ではどちらでも構わない。
【００２５】
１−４は携帯電話クライアントを示している。携帯電話は、中央演算処理装置などの通常のコンピュータを構成する装置で構成されており、ソフトウェアを動かすプラットフォームを提供する携帯電話も実用化されている。これらは、ｉアプリなどと呼ばれＪａｖａ（登録商標）などのプログラム言語の実行環境を提供するという形で実現している。これと同様の役目を行う事が可能であれば特にどのようなソフトウェア実行環境を用いても構わない。
【００２６】
また携帯電話クライアントは、ネットワーク網と通信が行う事が可能である。本実施形態ではＴＣＰ／ＩＰやその上位層プロトコルであるＨＴＴＰプロトコルを用いて実施しているが、同様の機能を果たすことが可能であれば、どのようなネットワークプロトコルを用いても構わない。
【００２７】
図２は、本実施形態で提案するシステムのユースケースを示している。２−１と２−２は、携帯電話クライアントを使用している閲覧者である画像受信者を示している。これらの要求はネットワークカメラシステムに対して映像の取得２−４及びカメラ制御の要求２−５とそれに伴うカメラ制御権の競合の解決２−５という３つのユースケースが発生する。
【００２８】
特に、カメラ制御の要求とカメラ制御権の競合は同時期に発生するためユースケース自体は依存の関係にある。その為、本実施形態では、特に２つのシナリオである映像の取得とカメラ制御の要求（カメラ制御権の競合）という２つのシナリオを解決するシステムを提供する。
【００２９】
図３は、図２で示される２つのシナリオにおける映像の取得に関してのコラボレーション図を示している。３−１及び３−２は、画像受信者を示している。これらの画像受信者は不定期に３−３で示される映像サーバに対して（１）映像の要求を行う。映像サーバはこれらの要求を受けて最新の画像データがないのであれば、３−４に示されるカメラ装置に対して（２）映像取得要求を行う。その後、映像サーバはカメラ装置の映像取得を行う（（３）映像取得）。更に、映像サーバは、キャプチャしたデジタル画像データを圧縮する（（４）映像画像の圧縮）。そして、この時点において映像の要求を行っている全ての携帯電話クライアントに対して画像データの送信を行う（（５）映像の配送）。この映像データを受信して、携帯電話クライアントは画面に（６）撮影した映像を表示する。このようなメッセージ通知やデータの送信手順によって、映像の取得というシナリオは達成する事が可能である。
【００３０】
図４は、図２で示される２つのシナリオにおける特にカメラ制御の要求（カメラ制御権の競合）に関してのコラボレーション図を示している。４−１及び４−２は、画像受信者（カメラ制御者）を示している。４−３はカメラ制御サーバを示している。そして、４−４は、そのカメラサーバに対して制御される雲台装置を示している。
【００３１】
カメラ制御の要求（カメラ制御権の競合）を解決するシナリオは、映像の取得というシナリオに比べて若干複雑である。取得される映像サーバの映像は、全ての携帯電話クライアントから同時に共有する事が可能であるのに対し、カメラ制御サーバで制御される雲台装置の操作は、同時に共有する事が出来ない為（排他的ネットワークリソース）である。その為、本実施形態ではカメラ制御権という概念を用いて解決している。ある瞬間におけるカメラ制御権の所有は、１つの携帯電話クライアントに限定される。
【００３２】
その為、（１）カメラ制御の要求が、携帯電話クライアントから発生した場合、カメラ制御サーバはその権利をカメラ制御権の早いもの順に（２）カメラ制御権の要求のキューイング処理を行う。そして、全てのカメラ制御権を要求した携帯電話クライアントに対して（３）カメラ制御権の返答を行う。この返答は最も早くカメラ制御権を要求した携帯電話クライアントに対しては、カメラ制御権の所有が成功したという通知を、それ以外の携帯電話クライアントには、カメラ制御権の所有が不成功に終わり、どの程度時間を待つかという情報の通知を携帯電話クライアントに（（４）カメラ制御権の通知）行う。
【００３３】
携帯電話クライアントは、カメラ制御権の返答によってバイブレータの制御やイルミネーションの制御などを行う事で、カメラ制御権の通知を行う。
【００３４】
カメラ制御権の取得が成功した携帯電話クライアントは、カメラ制御者のカメラ制御入力を受付け（（５）カメラ制御）、カメラ制御要求をカメラ制御サーバに対して行う（（６）カメラ制御情報送信）。
【００３５】
このカメラ制御情報は、カメラに対しての一般的な操作パラメータであるパン・チルト・ズームや絞り制御、利得制御、フィルター制御、プリセット制御、パイパー制御、デフロー制御などの情報を含むものである。そして、カメラ制御サーバは（７）カメラ制御情報の受信を行い、カメラ制御情報を元にして、雲台制御情報の作成し、雲台に対して（９）雲台制御信号送信を行い、最終的に目的の（１０）雲台制御を行う。このようなメッセージ通知やデータの送信手順によって、カメラ制御の要求（カメラ制御権の競合）というシナリオは達成する事が可能になる。
【００３６】
図５は、映像サーバ及び、カメラ制御サーバの内部構成図を示している。映像サーバ及びカメラ制御サーバは、５−２に示されるように、画像出力装置、入力装置、中央演算処理装置、主記憶装置、外部記憶装置、画像入力装置、外部機器信号送受信装置、ネットワークインターフェイスなどで構成されており、これらの装置類は、バスラインで結合されて構成されている。この構成は一般のコンピュータとあまり大きな差異は特にない。
【００３７】
外部装置としては、５−１で示される表示装置が画像出力装置に接続される。また、画像入力装置には、５−３で示されるカメラ装置が接続され、映像の入力が可能になっている。本実施形態では特にアナログ画像信号を前提としているが、これに限らずデジタル画像信号でも構わない。その場合は信号に合わせた画像入力装置に変更される。また、外部機器信号送受信装置とは、雲台装置５−３が接続されており、この接続によってカメラ全体の制御が可能である。本実施形態では一般にＲＳ２３２Ｃと呼ばれる信号線を用いている。しかし、同様の役目を果たす事が可能な任意のインターフェイスに置き換えても良い。
【００３８】
画像情報の送受信やカメラ制御情報の送受信は、ネットワークインターフェイスを用いて外部ＴＣＰ／ＩＰネットワーク網５−４と接続されることで、携帯電話クライアントとの通信を行う事が出来る。このネットワークは先に説明したように、どのようなデジタルネットワークを用いても構わない。映像サーバとカメラ制御サーバは、ハードウェア的構成に大きな差異がないために、同一のハードウェア上で、ソフトウェアを実行しても構わないし、別のハードウェア上に対してソフトウェアを構成しても構わない。
【００３９】
図６は、携帯電話クライアントの内部構成図を示している。携帯電話クライアントは、デジタル通信及びＷｏｒｌｄＷｉｄｅＷｅｂやＴＣＰ／ＩＰネットワーク網と通信が可能な通信機器であれば、ＰＤＡなどに置き換えても特に問題はない。
【００４０】
携帯電話クライアント６−２の構成も基本的には、通常のコンピュータと同様である。画像表示装置６−４、入力装置、中央演算処理装置、主記憶装置、バイブレータ駆動装置、イルミネーション制御装置６−３、無線情報送受信装置６−１などから構成されている。本実施形態で特徴的な部分は、携帯電話クライアントに、バイブレータ駆動装置及びイルミネーション制御装置を搭載している点である。このような装置を用いる事で、携帯電話をクライアントに用いたカメラ制御に関してユーザビリティを高めるユーザーインターフェイスを提供する事が出来る。
【００４１】
また、この携帯電話クライアントは、無線情報送受信装置を用いてＴＣＰ／ＩＰネットワーク網６−５に接続を行う事が出来る。このネットワーク接続は、携帯電話会社のネットワークを経由してインターネットなどに接続している場合が多く、直接接続している例は少ない。しかし、論理的構成においては直接接続しているとして扱っても構わないと思われ、本実施形態では、論理的接続をしているという前提で説明を行うものとする。これらのネットワークは、論理的なデジタルネットワーク接続であればＴＣＰ／ＩＰ以外のプロトコルであっても構わないし、固定線や無線など物理形態も問わない。
【００４２】
図７は、映像サーバ内部のソフトウェアのクラス構成図を示している。７−１，７−２，７−３，７−５，７−６は、映像サーバを構成するクラス及びインターフェイスである。全てのクラスは７−２で示されるインターフェイスを継承しており、クラス間の画像データ転送の為に使用される。
【００４３】
７−３は、クライアントクラスを示している。このクラスは、携帯電話クライアントを抽象化するクラスであり、携帯電話クライアントとの通信を行う。また、携帯電話クライアントからの要求は、このクラスからの通知という形で映像サーバ内でメッセージ通知が行われる。また、クライアントクラスは、携帯電話クライアントと１対１の関係でインスタント化される。その為、これらのオブジェクトを効率良くを管理する為に、データ配布クラスが用意されている。このクラスのインスタンスは、１つのみであり、全てのクライアントクラスが、データ配布クラスに登録されることによって、画像データをそれぞれのクライアントクラスに転送する事が可能になる。また、データ配布クラスは、クライアントクラスからの要求をまとめて受け取り、映像圧縮クラスに対して画像データの要求を行う。映像圧縮クラスは、更にその要求を映像取得クラスに行う。映像取得クラスは、カメラ装置７−１からの映像をキャプチャして撮影対象となる映像のデジタル画像データを作成する。この画像データは、映像圧縮クラスに通知される。映像圧縮クラスで、画像データの圧縮を行う。このデータ圧縮アルゴリズムは任意のアルゴリズムを用いる事が可能であり、本実施形態ではＪｐｅｇ形式を用いている。画像データの圧縮が行われた後に、圧縮された画像データは、データ配布クラスに通知され、画像の要求のあるクライアントクラスに対して画像データを通知する。このようなソフトウェアの構成によって映像サーバを動作させることが可能である。
【００４４】
図８は、映像サーバ内部のコラボレーション図を示している。更に映像サーバのオブジェクト図をも示しており、内部のオブジェクト構成を示すものである。８−３，８−４，８−５，８−６，８−７は、映像サーバを構成するオブジェクトを示している。これらのオブジェクトは、それぞれ図７で示されるクラスのインスタンス化されたオブジェクトを示している。
【００４５】
８−２の画像受信者の操作によって携帯電話クライアントは、映像サーバに対して（１）映像の要求を行う。この要求は映像サーバ内部で、携帯電話クライアントと１対１の関係でインスタンス化されたクライアントオブジェクトがそれぞれの要求を受け取る。クライアントオブジェクトは、その要求をデータ配布オブジェクトに（２）映像の要求の通知をする。これらの映像の要求は、データ配布オブジェクトが管理しており、最新更新画像の取得が必要であるとデータ配布オブジェクトが判断した場合、映像圧縮オブジェクトに対して、（３）映像の要求を行う。更に、映像圧縮オブジェクトは、映像取得オブジェクトに対して、（４）映像の要求を通知する。映像の要求の通知を受けた映像取得オブジェクトは、カメラ装置８−２に対して（５）映像取得初期化を行う。映像の取得の為の初期化が終わると、映像取得オブジェクトは実際に（６）映像の取得を行う。次に、映像取得オブジェクトはキャプチャした画像データを映像圧縮オブジェクトに通知を行う（７）。映像圧縮オブジェクトは、画像データを受け取ると、画像データを圧縮（８）を行い、圧縮された画像データをデータ配布オブジェクトに通知を行う（９）。次に、映像データの受信をしたデータ配布オブジェクトは、要求のあった各クライアントオブジェクトに対して映像データの通知を行い（１０）、最終的には、各クライアントオブジェクトが、圧縮された画像データをそれぞれの携帯電話クライアントに送信（１１）を行う。こうして、カメラ装置で得られた画像データは、携帯電話クライアント上で、表示が可能になる（１２）。このような内部構成によって、映像サーバの動作を実現する事が可能になる。
【００４６】
図９は、カメラ制御サーバ内部のソフトウェアのクラス構成図を示している。
【００４７】
９−１，９−５，９−６，９−７，９−８，９−３，９−９は、カメラ制御サーバを構成するクラス及びインターフェイスである。クライアントクラスは、携帯電話クライアントと１対１の関係でインスタンス化されるクラスである。その為、カメラ制御サーバ内では、携帯電話クライアントを抽象化しており、実際の携帯電話クライアントとの通信や携帯電話クライアントからの要求は、このクラスを通して行われる。
【００４８】
これらの通信の要求は、全てクライアントマネージャクラスによって管理される。クライアントマネージャクラスは、クライアントクラスからのカメラ制御権要求などを受信したり、クライアントクラスへのカメラ状態の変更などの通知に必要性などを判断して各クライアントクラスに対して情報の取りまとめやデータの配布を行う。
【００４９】
また、インターフェイスとして、カメラ制御権状態通知インターフェイス９−６とカメラ制御状態通知インターフェイス９−７が定義されている。これらのインターフェイスは、カメラ制御権クラス及びカメラ制御クラスが、クライアントマネージャクラスと通信をするために用いられるインターフェイスである。その為に、クライアントマネージャクラスはこのインターフェイスを継承している。クライアントマネージャクラスからまとめられたカメラ制御権の要求はカメラ制御の要求は、それぞれ、カメラ制御権クラスやカメラ制御クラスに対して通知される。
【００５０】
カメラ制御権クラスは、カメラ制御権を示すクラスである。その為、現在のカメラ制御権が、どのクライアントクラスにあるのか、カメラ制御権の有効期間や、カメラ制御権の要求者のリストなどを保持している。カメラ制御権は、時間によって所有者が変わるが、この基準となる時間経過は、タイマークラス９−９によってカメラ制御権クラスに通知されている。カメラ制御権の状態の変化は、カメラ制御権状態通知インターフェイスを通してクライアントマネージャに通知される。
【００５１】
カメラ制御クラスは、カメラ装置の雲台装置を制御するクラスである。その為、雲台装置の状態を、カメラ制御クラスは保持している。更に、クライアントマネージャからのカメラ制御の要求を受けて、実際に雲台装置に対してカメラ制御信号を送り、任意のカメラ制御を行う。また、雲台装置の状態の変化は、カメラ制御状態通知インターフェイスによってクライアントマネージャに通知される。これらのカメラ制御権クラス及びカメラ制御クラスの状態の変化は、クライアントマネージャが受信し、カメラ上来の変化は、各クライアントクラスに対して通知される。このようなソフトウェア構成によってカメラ制御サーバを動作させる事が可能である。
【００５２】
図１０は、カメラ制御サーバ内部のコラボレーション図を示している。
【００５３】
更にカメラ制御サーバのオブジェクト図をも示しており、内部のオブジェクト構成を示すものである。１０−１，１０−２，１０−５，１０−６，１０−７，１０−８は、カメラ制御サーバを構成するオブジェクトを示している。これらのオブジェクトは、それぞれ図９で示されるクラスのインスタンス化されたオブジェクトを示している。
【００５４】
カメラ制御サーバは、携帯電話クライアントからのカメラ制御権の要求（１）をクライアントオブジェクトが受信を行う。このカメラ制御権の要求は、クライアントマネージャに対して通知される（２）。各携帯電話クライアントの要求は、１つのクライアントマネージャオブジェクトに通知されることになる。そしてカメラ制御権要求は、クライアントマネージャオブジェクトからカメラ制御権オブジェクトに要求（３）する。カメラ制御権オブジェクトは、このクライアントマネージャオブジェクトからのカメラ制御権の要求をカメラ制御権オブジェクト内のキューにキューイングし、各クライアントオブジェクトからのカメラ制御権要求を整理して把握する。更に、タイマーオブジェクトからの時間経過（５）などからカメラ制御権の状態を決定する。カメラ制御権の状態は、唯一１人のカメラ操作可能なクライアントとそれ以外のカメラ制御権を待つクライアントの情報を保持すると同時に、それぞれがどの程度の時間、この状態が続くのかを保持する。このカメラ制御権の状態の変化は、クライアントマネージャに通知される（６）。これを受けたクライアントマネージャは、それぞれ対応するクライアントオブジェクトに対してカメラ制御権の状態の通知を行う（７）。更に、クライアントオブジェクトは、カメラ制御権の状態を携帯電話クライアントに対して送信（８）を行う。こうして、携帯電話クライアントは、カメラ制御権状態の表示（９）を行う事が可能になる。
【００５５】
カメラ制御権を保持した携帯電話クライアントは、カメラ制御を行う事が出来るため、カメラ制御者のカメラ制御を行われた場合は、カメラ制御情報をクライアントオブジェクトに対して送信を行う（９）。このカメラ制御情報は、クライアントオブジェクトからクライアントマネージャオブジェクトに通知（１０）され、更に、カメラ制御オブジェクトに通知（１１）される。そして、カメラ制御オブジェクトで、カメラ制御情報に基づいて雲台装置１０−９への制御信号を作成し、雲台装置へその信号の通知（１２）を行う。こうして、携帯電話クライアントからのカメラ制御情報は、雲台装置によって実行（１３）される。また、雲台装置の状態の変化は、逐一カメラ制御オブジェクトが監視しており、状態の変化を監視（１３）している。もし、雲台装置の状態の変化があれば、カメラ制御オブジェクトは、クライアントオブジェクトに対してカメラ制御状態の情報の通知（１３）を行う。この通知を受けたクライアントオブジェクトはその情報を各クライアントオブジェクトに通知（１４）を行い、最終的に携帯電話クライアントにカメラ制御状態の変化の情報が通知（１５）される。こうして、携帯電話クライアントで、カメラ制御状態を表示（１６）する事が可能になる。
【００５６】
図１１は、携帯電話クライアントのクラス図を示している。１１−１，１１−２，１１−３，１１−４，１１−１１，１１−１２，１１−２，１１−５，１１−６，１１−９はそれぞれ携帯電話クライアント内のクラスを示している。
【００５７】
カメラ画像表示クラスは、携帯電話クライアントの画像表示装置の状態を保持するクラスである。その為、カメラ画像表示クラスは、画像表示用のメソッドを持ち、映像サーバの画像の表示を行う事が可能である。キー入力クラスは、携帯電話クライアントの数字キーなどの入力を監視するクラスである。入力があると同時に、カメラ制御サーバクラス等にその内容が通知される。カメラ制御状態表示クラスは、雲台装置の状態を表示する為のクラスで、本実施形態では、パン・チルト・ズームなどの状態を表示するクラスである。カメラ制御権状態表示クラスは、携帯電話クライアントの画像表示装置にカメラ制御権の状態を表示するクラスである。
【００５８】
バイブレータ作動クラスは、携帯電話クライアント内のバイブレータ駆動装置を制御するクラスである。イルミネーション作動クラスは、携帯電話クライアント内のイルミネーション装置を制御するクラスである。カメラ制御権表示マネージャクラスは、カメラ制御権のＵＩを統一的に管理するクラスである。カメラ制御権の有無などを通知するのに、画像、バイブレータ、イルミネーション等を使用する為、これらを統括して管理するクラスである。タイマークラスは、携帯電話クライアント内での時間の経過を管理するクラスである。
【００５９】
映像サーバクラスは、実際に映像サーバと通信をすると同時に、映像サーバの状態を保持するクラスである。映像の要求メソッドや、映像の受信イベントなどを持っているクラスであり、実際に映像データを受信するとこのクラスからの通知として携帯電話クライアント内で動作する。カメラ制御サーバクラスは、実際にカメラ制御サーバと通信をすると同時に、カメラ制御サーバの状態を保持するクラスである。カメラ制御権の要求や通知、カメラ制御の要求や通知といったカメラ制御に関するメソッドとイベントを持っており、携帯電話クライアント内でのカメラ制御クラスとして動作する。携帯電話クライアントでは、このようなソフトウェア構成を用いて本実施形態を実現している。
【００６０】
図１２は、携帯電話クライアントのコラボレーション図を示している。また、この図は携帯電話クライアントのオブジェクト図も示している。１２−１０，１２−４，１２−３，１２−６，１２−７，１２−８，１２−９，１２−１０，１２−１１はそれぞれ、携帯電話クライアント内のオブジェクトを示しており、図１１で示される各クラスのインスタンスである。携帯電話クライアントは、映像系とカメラ制御系の２つが独立して動作している。
【００６１】
映像系は比較的単純な動作で、映像サーバオブジェクトが常に映像サーバに対して映像の要求（１）の送信をまず行う。これに対して映像サーバが最新の画像データを取得する事が出来ると、その画像データを映像サーバオブジェクトが受信（２）を行う。受信を行った後に、映像サーバオブジェクト内で映像データの伸張を行い、最終的にカメラ画像表示オブジェクトに対して画像の表示（３）を行う。このサイクルを何度も行う事で、動画像の表示を可能としている。
【００６２】
一方、カメラ制御に関しては、最初に、カメラ制御者１２−５がカメラ制御権の要求操作（１）を行う。この入力は、キー入力オブジェクトに通知されて更にカメラ制御御サーバオブジェクトに通知（２）され、カメラ制御サーバオブジェクトに通知される。カメラ制御サーバオブジェクトは、カメラ制御サーバに対してこのカメラ制御権要求の送信を行う。その後、カメラ制御サーバは、カメラ制御権の取得の内容に関して返答を送信（４）し、カメラ制御サーバオブジェクトがその情報を受信する。カメラ制御権に関しての情報は、カメラ制御権表示マネージャオブジェクトに通知（５）される。このオブジェクトは、タイマーオブジェクトからの時間の通知（６）に応じて、カメラ制御権の表示や挙動に関して制御を行う。この制御方式が、本提案における本実施形態の発明部分である。カメラ制御権取得までの時間の長さによってカメラ制御権表示オブジェクトやバイブレータ作動オブジェクト、イルミネーション作動オブジェクトなどを制御する（６）（７）（８）。カメラ制御権の取得が出来ると、カメラ制御に関してのＵＩが許可となり、カメラ制御者はカメラ制御を実際に指示するＵＩを操作する（１０）。その入力は、キー入力オブジェクトを通じてカメラ制御サーバオブジェクトに通知（１１）される。更にカメラ制御サーバオブジェクトは、カメラ制御サーバにそのカメラ制御の要求を送信（１２）し、実際にカメラ制御サーバが、雲台の制御を実行する。そのときの雲台の状態の変化は、カメラ制御サーバオブジェクトに通知（１３）される。更にカメラ制御情報は、カメラ制御状態表示オブジェクトに通知されることによって、画像にカメラ制御状態が表示される。こうして、携帯電話クライアント内でオブジェクトが動作することで、本実施形態が実行される。
【００６３】
図１３は、映像サーバの状態遷移を示している。映像サーバは、基本的に、１３−１，１３−２，１３−３，１３−４の４つの状態を保持する。初期化状態１３−１は、映像サーバの起動状態からの初期化状態を示している。映像サーバの初期化が成功すれば、画像取得状態１３−２に移行する。画像取得状態では、画像をキャプチャしている状態である。正常に画像をキャプチャすると、画像圧縮状態１３−３に移行する。
【００６４】
画像圧縮状態状態では、得られた映像データの圧縮を行っている状態である。画像の圧縮が正常に行われると、画像配信状態１３−４に移行する。この状態の移行は、クライアントの接続が全くない状態では、その後の映像の配信が無意味になるので、その場合は、画像取得状態に戻る。画像配信状態では、得られた画像データを実際に各クライアントに送信をしている。最新の画像データが各クライアントに送信が終了すれば、再び画像取得状態に戻り、以降、このような状態遷移を繰り返す。
【００６５】
図１４は、カメラ制御サーバの状態遷移を示している。この図では特に、カメラ制御サーバ内のクライアントオブジェクトの状態遷移とカメラ制御権オブジェクトの状態遷移を示している。クライアントオブジェクトは、１４−２，１４−３，１４−４の状態を保持する。１４−２はカメラ制御権なし状態を表している。この状態では、携帯電話クライアントからのカメラ制御権の要求もないし、携帯電話クライアントに対してカメラ制御権を割り当てていない状態をしめしている。カメラ操作者がカメラ制御権取得の操作の通信を受けると、カメラ制御権待ち状態となる。この状態は、カメラ制御権オブジェクトからのカメラ制御権の通知で、クライアントオブジェクトに対して制御権が割り当てられなかった場合になる。更に、ある程度の時間が経過したり、もしくは、カメラ制御権保持をしているクライアントが切断したりすると、カメラ制御権オブジェクトの状態が変わり、クライアントオブジェクトに対して制御権が割り当たると、カメラ制御可能状態になる。この状態では、カメラ制御が許可されている状態であり、携帯電話クライアントからのカメラ制御要求が有効になる。
【００６６】
更に、１４−５，１４−６，１４−７はカメラ制御権オブジェクトの状態遷移図を示している。
【００６７】
カメラ制御権は、カメラ制御権保持者なし状態から生成される。この状態では、どのクライアントオブジェクトからもカメラ制御権の要求がない状態である。この状態のときに、１つでもクライアントオブジェクトからのカメラ制御権要求があると、カメラ制御権保持者あり状態に移行する。この状態では、カメラ制御権を要求したクライアントオブジェクトからのカメラ制御のみを有効とする。この状態から、更に他のクライアントオブジェクトから、カメラ制御権の要求があると、カメラ制御権保持社あり＆カメラ制御権待ち者あり状態に移行をする。この状態では最初にカメラ制御権を保持しているものにのみのカメラ制御を有効として、それ以外のカメラ制御の全て禁止をする。また、カメラ制御権保持者あり状態や、カメラ制御権保持者あり＆カメラ制御権待ち者あり状態のときに、携帯電話クライアントが切断されたり、もしくは一定の時間が経過すると、それに合わせてカメラ制御権オブジェクトの状態が変化をする。このような状態遷移を持つことによって、カメラ制御権という概念を実現している。
【００６８】
図１５は、携帯電話クライアントの映像関連の状態遷移図を示している。
【００６９】
この状態を保持しているのは、携帯電話クライアント内の映像サーバオブジェクトである。実際の表示は、カメラ画像表示オブジェクトが行っている。
【００７０】
１５−１，１５−２，１５−３，１５−４はそれぞれ携帯電話クライアントの状態を示している。携帯電話クライアントは起動後、初期状態を保持する。この状態からサーバとの接続が成功すると映像サーバへの画像要求を送信すると同時に画像取得待ち状態となる。この状態において、映像サーバから画像データを受信すると、画像展開状態に移行する。更に画像データの展開に成功すると、それを画像に表示して、画像表示状態に移行する。そして、映像サーバへ再び画像要求を送信すると同時に、画像取得待ち状態に移行する。この後は、このサイクルを何度も繰り返す。このような状態遷移を繰り返しながら、映像サーバの画像を表示する事が可能になる。
【００７１】
図１６は、携帯電話クライアントのカメラ制御関連の状態遷移図を示している。１６−２，１６−３，１６−４，１６−６，１６−７，１６−５は、携帯電話クライアントの状態を示している。
【００７２】
携帯電話クライアントは起動後、カメラ制御権なし状態で起動する。その後、カメラ制御者からのカメラ制御権要求操作を受けて、カメラ制御サーバに対してカメラ制御権の要求を行と同時に、カメラ制御権待機状態に移行する。この状態でカメラ制御サーバからの制御権の通知を受けるわけであるが、カメラ制御権の取得時の時間経過によって次の状態変化が決定する。この状態変化の分岐が、本実施形態における発明点である。
【００７３】
あらかじめ、携帯電話クライアントに対して、閾値ｎを設定しておく。この閾値ｎは、カメラ制御者が設定をしてもいいしデフォルトでシステムに設定してあっても良い。制御権の要求を行ったカメラ制御権待機状態開始時間からカメラ制御サーバのカメラ制御権状態返答のタイミングによって状態変移先を変更する。もし、すぐカメラ制御権が取れた場合は、カメラ制御状態表示状態に移行し、すぐにカメラ制御可能状態に移行する。こうして、問題なくカメラ制御権を取得できた場合は、特に大きな反応を示さずに、カメラ制御可能状態に移行する。
【００７４】
もし、カメラ制御権がｎ秒後に取得が出来た場合、音、イルミネーション、バイブレータのどれかを選択して通知を行うカメラ制御権表示状態＆バイブレータ動作状態に移行する。このとき、音、イルミネーション、バイブレータの動作は、全てを同時に行ってもいいし、選択的に行っても構わない。その後、カメラ制御可能状態に移行して、カメラ制御を行う。もし、カメラ制御権が取れない場合は、音、イルミネーション、バイブレータのどれかを選択して通知を行うカメラ制御不取得表示＆イルミネーション動作状態に移行する。このとき、音、イルミネーション、バイブレータの動作は、全てを同時に行ってもいいし、選択的に行っても構わない。そして、カメラ制御権なし状態に移行する。
【００７５】
また、カメラ制御権状態表示＆梅雨レータ動作状態とカメラ制御権不取得＆バイブレータ動作状態でのバイレータの動作や、音、イルミネーションの動作は、パターンをそれぞれ別のものにする事が可能である。このように、カメラ制御サーバからの制御権取得の通知までにかかる時間によって、携帯電話クライアントでの挙動を変える事で、カメラ制御者の利便性を向上する事が可能である。
【００７６】
図１７は、映像配信関連に関するシーケンス図を示している。１７−１〜１７−３０は、それぞれ動作シーケンスの内容を示している。最初に画像受信者が、接続要求を携帯電話クライアントに行うと１７−２においてキー入力オブジェクトが検知し、この内容を映像サーバオブジェクトに伝える。１７−３１において映像サーバオブジェクトは接続を試みる。接続に失敗するとシーケンスは、１７−６で終了する。成功すると、１７−７において画像の要求を映像サーバに対して行う。
【００７７】
一方映像サーバ側は、１７−３によってクライアントオブジェクトを初期化してクライアント待ち状態となる。それと同時に、データ配布オブジェクト及び映像圧縮オブジェクト及び映像取得オブジェクトは初期化する。
【００７８】
１７−７における映像の要求をクライアントオブジェクトは受信をし、１７−８においてその内容を受信すると共に、データ配布オブジェクトに通知を行う。更にデータ配布オブジェクトは、映像圧縮オブジェクトの通知を行い１７−２１、最終的に映像取得オブジェクトに、携帯電話クライアントからの画像取得要求が通知される。この通知を受けて映像取得オブジェクトは、１７−２２においてカメラ装置の画像を取得し、その画像データを映像圧縮オブジェクトに通知を行う。映像圧縮オブジェクトは、１７−２７において画像データの圧縮を行い、圧縮されたデータをデータ配布オブジェクトに通知をする。画像データを受け取ったデータ配布オブジェクトは、各クライアントオブジェクトが最新の取得した画像データが必要かどうかを判断を行う。もし、画像データの要求が一切ないのであれば、１７−２０に戻り、再び最新のカメラ装置の画像の取得圧縮を行う。もし、画像データの配布を要求するクライアントオブジェクトがいるのであれば、１７−２６において映像データをクライアントオブジェクトに通知をする。クライアントオブジェクトはその通知を受けて、１７−２５において携帯電話クライアントに対して映像データの送信をする。携帯電話クライアントは、この画像データを１７−２４にて受信を行い、１７−２８で映像データのデコード、そして１７−２９で画像データをカメラ画像表示オブジェクトに通知し、１７−２３にて画像データの表示を行う。こうして映像サーバの画像の表示を行う事が可能となる。その後、１７−７に戻り、以降このサイクルを繰り返す事で画像データの受信を繰り返し行う事が可能になる。
【００７９】
図１８は、カメラ制御に関するシーケンス図を示している。１８−１〜１８−３２は、それぞれ動作シーケンスの内容を示している。最初にカメラ制御者が、接続要求を携帯電話クライアントに行うと、携帯電話クライアントのキー入力オブジェクトがその操作を認識する１８−１。そして、キー入力オブジェクトは、カメラ制御サーバオブジェクトに対してカメラ制御サーバへの接続を通知し、カメラ制御サーバオブジェクトは、１８−２でカメラ制御サーバへの接続を行う。
【００８０】
カメラ制御サーバは、クライアントオブジェクトでこの接続を検出する１８−３。カメラ制御サーバ内では、更にこれを受けてクライアントマネージャクラスに接続情報が通知され、現在カメラ制御サーバに接続をする接続をするクライアントの保持リストに登録がされる。接続の成功によって携帯電話クライアント内では、カメラ制御権要求入力を受け付ける状態となる１８−５。この状態からカメラ制御者からのカメラ制御権の要求操作があると、キー入力オブジェクトは、カメラ制御サーバオブジェクトに対してカメラの制御権取得の要請を送信する１８−１０。更にこのとき同時にカメラ制御権表示マネージャオブジェクトに対してもカメラ制御権の要求が通知される１８−９。
【００８１】
そして、カメラ制御権表示マネージャから現在のカメラ制御権の状態を、カメラ制御権表示オブジェクトに通知し表示を行う１８−８。１８−１０でカメラ制御権の要求は、カメラ制御サーバに送信され、クライアントオブジェクトがその要求を受信し、更にクライアントマネージャオブジェクトに通知される１８−１１。クライアントマネージャオブジェクトは、カメラ制御権オブジェクトに対してカメラ制御権の要求１８−１６と、カメラ制御オブジェクトに現在のカメラ状態取得するように通知を行う１８−１５。この際、カメラ制御権オブジェクトは、タイマーオブジェクトからのタイミングの通知１８−６を元にカメラ制御権の状態の所有者や順番待ちキューの待ち時間、カメラ制御権占有時間など状態を変化させており、その状態変化を１８−１６内でクライントマネージャオブジェクトに通知を行う。
【００８２】
こうして、クライアントマネージャオブジェクトは、カメラ制御権の状態とカメラ制御の状態を把握する事が出来る。この状態の変化を登録されているクライアントオブジェクトに対してそれぞれ必要な情報を提供し通知を行う１８−１７。この通知を受けたクライアントオブジェクトは、カメラ制御権状態とカメラ制御状態を携帯電話クライアントへ送信を行い、携帯電話クライアントのカメラ制御サーバオブジェクトが受信を行う１８−１８。この受信の内容は、カメラ制御状態表示オブジェクトとカメラ制御権状態オブジェクトに通知され、現在のカメラ制御権と雲台装置の状況が携帯電話クライアントに表示される。さらに、この際に、カメラ制御権表示マネージャにも送られる。
【００８３】
このときもし、カメラ制御権を持っているのならば、カメラ制御権の要求をカメラ制御者から許可かし、キー入力オブジェクトからの要求を受ける１８−２２。そのカメラ制御要求は、カメラ制御サーバオブジェクトによって送信され１８−２４、カメラ制御サーバのクライアントオブジェクト、クライアントマネージャオブジェクトを経て、カメラ制御オブジェクトに通知される１８−２４，１８−２５，１８−２６。この通知を受けたカメラ制御オブジェクトは、パン・チルト・ズーム等のカメラ操作を雲台装置に対して行う１８−２７。そして再び変更のあった、雲台装置の状態変化を１８−２８にてカメラクライアントマネージャに通知し、カメラ制御状態を携帯電話クライアントに送信を行う。このようにして、カメラ制御を行う事が実現出来る。
【００８４】
１８−２３にてもし、カメラ制御権が取得出来ない場合、１８−３０にてカメラ制御サーバからの制御権の通知待ちをして待機を行う。この間にカメラ制御権が取得出来たときに、予め携帯電話クライアントに設定してある閾値ｎ秒を越えない場合は、１８−３２に制御を移すが、もし、閾値ｎを越えている場合は、１８−３７へ制御を移し、バイブレータ作動制御オブジェクトにてバイブレータを動作させ、１８−３６でカメラ制御権の表示を行い、１８−２２に移る。
【００８５】
カメラ制御権が、取得出来ない場合でも１８−３３にてバイブレータを動作させて、１８−３２にてカメラ制御権の状態の表示を行う。このときバイブレータの動作は、イルミネーションを変わりに動作させても良いし、音によって通知をしてもよい。このようなシーケンスを用いて、携帯電話クライアントにおいて、カメラ制御権の通知を携帯電話クライアントの使用者であるカメラ制御者に対して効率的に行う事が可能となる。
【００８６】
図１９は、携帯電話クライアントのＧＵＩについて示した図である。１９−２，１９−４，１９−５，１９−６，１９−３，１９−７は、携帯電話クライアントのそれぞれの状態に関しての画像の変移を示している。
【００８７】
最初の状態は、（Ａ）状態であり、この状態において映像サーバの接続先に関して入力することが可能である。本実施形態では、選択方式で選ぶ事が可能であるが、アドレス等を入力する形でも構わない。入力が終了すると、（Ｂ）状態になる。この状態は、サーバへの接続を行っている状態である。接続に成功し、画像の取得が完了すると（Ｃ）状態となる。この状態では、映像サーバの映像は表示されるものの、制御権を取得していない状態である。この状態から、カメラ制御者が制御権の要求を行うと、（Ｄ）状態になる。（Ｄ）状態ではカメラの制御権をカメラ制御サーバから待っている状態である。もし、カメラ制御権が取得出来、カメラ制御可能になると、（Ｅ）状態になる。この状態では実際にカメラ制御が許可されることになる。もし、カメラ制御権の取得が出来ない場合は、（Ｆ）状態に移行する。この状態では、バイブレータや音、イルミネーションといったＵＩを用いて、カメラ制御権が取得できなかった事を通知している。このようなＵＩを実施する事で、カメラ制御権待ちに対するユーザーの利便性を向上する事が出来る。
【００８８】
以上に説明したように本実施形態において、ネットワークカメラサーバの挙動に対して挙動のレスポンスの速さ（携帯電話クライアントに予め時間を設定しておく）に応じてクライアント側でサーバ側のレスポンスを判断して、バイブレータやイルミネーションの制御を行う事が可能となり、カメラ制御者に対して効率的なカメラ制御権の挙動の変化を通知することが可能となる。
【００８９】
（第二の実施形態）
第一の実施形態のときと違いクライアント側で独自にサーバ側の挙動に対してのタイムアウトを設定してそのタイムアウトに関して、バイブレータ及びイルミネーション等でカメラ制御に関しての通知を行う。
【００９０】
図１８の１８−３９にて携帯電話クライアントにおいてもカメラ制御権までの取得時間を計測することによって第一の実施形態の場合は、この部分が、最初にカメラ制御権の要求を行う。
【００９１】
このカメラ制御権の要求に対するカメラサーバの返答が、すぐ制御権が取れた場合は、特に何も行わない。カメラ制御権が閾値ｎ秒後以内に取得が出来た場合は、音、光、バイブレータなどを用いてカメラ制御権の使用可能になった状態をカメラ制御者に通知行う。制御券を取得出来ない場合は、音、光、バイブレータなどを用いてカメラ制御権の取得が不可能になった状態をカメラ制御者に通知を行う、というロジックであったのに対して、
第二の実施形態では、最初にカメラ制御権の要求を行う。このカメラ制御権の要求に対するカメラサーバの返答が、すぐ制御権が取れた場合は、特に何も行わない。カメラ制御権が閾値ｎ秒後以内に取得が出来た場合は、音、光、バイブレータなどを用いてカメラ制御権の使用可能になった状態をカメラ制御者に通知行う。サーバの返答が閾値ｎ秒を越えてしまった場合及び、制御権を取得出来ない場合は、音、光、バイブレータなどを用いてカメラ制御権の取得が不可能になった状態をカメラ制御者に通知を行う。このときの時間経過を測定するカウンタは、第一の実施形態ではカメラ制御サーバからのカメラ制御権の状態変化の通知を元に行っていたのに対して第二の実施形態では、基本的にサーバの挙動をクライアント側で判断し、タイマーはクライアント側で持ち対応する。つまり携帯電話クライアント主導としてバイブレータ等の動作を判断する。
【００９２】
以上に説明したように、携帯電話クライアントを第二の実施形態のように変化させたとしても、カメラ制御者に対して効率的なカメラ制御権の挙動の変化を通知することが可能となる。
【図面の簡単な説明】
【００９３】
【図１】システム構成図
【図２】ユースケース図
【図３】システムコラボレション図（映像系）
【図４】システムコラボレション図（カメラ制御）
【図５】サーバ内部構成図
【図６】クライアント内部構成図
【図７】映像サーバクラス図
【図８】映像サーバコラボレーション図（クラス）
【図９】カメラ制御サーバクラス図
【図１０】カメラ制御サーバコラボレーション図（クラス）
【図１１】携帯電話クラス図
【図１２】携帯電話コラボレーション図（クラス）
【図１３】映像サーバ状態遷移図
【図１４】カメラ制御サーバ状態遷移図
【図１５】携帯電話状態遷移図（映像系）
【図１６】携帯電話状態遷移図（カメラ制御系）
【図１７】映像配送シーケンス図
【図１８】カメラ制御シーケンス図
【図１９】ＧＵＩ図（例）
【符号の説明】
【００９４】
１−１  ＴＣＰ／ＩＰネットワーク網
１−２  映像サーバ・カメラ制御サーバ
１−３  カメラ装置
１−４  携帯電話クライアント
【図１】
2005151019.tif 000003
【図２】
2005151019.tif 000004
【図３】
2005151019.tif 000005
【図４】
2005151019.tif 000006
【図５】
2005151019.tif 000007
【図６】
2005151019.tif 000008
【図７】
2005151019.tif 000009
【図８】
2005151019.tif 000010
【図９】
2005151019.tif 000011
【図１０】
2005151019.tif 000012
【図１１】
2005151019.tif 000013
【図１２】
2005151019.tif 000014
【図１３】
2005151019.tif 000015
【図１４】
2005151019.tif 000016
【図１５】
2005151019.tif 000017
【図１６】
2005151019.tif 000018
【図１７】
2005151019.tif 000019
【図１８】
2005151019.tif 000020
【図１９】
2005151019.tif 000021