データ配信装置及び画像配信装置
【課題】本発明は、異常が発生したとき使用可能なプロトコルを判別でき、各サーバに異常を伝えることができるデータ配信装置及び画像配信装置を提供することを目的とする。
【解決手段】本発明のデータ配信装置は、ＩＰネットワークに接続されて複数の所定のサーバと通信できると共に、通信端末に対してデータの配信をすることができる通信部１２と、通信上及び／またはシステム上異常が発生したことを検知する異常検知手段１４と、異常検知手段１４が異常を検知したとき、サーバに対し該サーバが通信に使用するプロトコルでの通信が異常か正常か確認するための通知を順次行うと共に、正常な通信ができるプロトコルのサーバに対して異常を通知する異常時通信手段１５とを備えたことを特徴とする。
【解決手段】本発明のデータ配信装置は、ＩＰネットワークに接続されて複数の所定のサーバと通信できると共に、通信端末に対してデータの配信をすることができる通信部１２と、通信上及び／またはシステム上異常が発生したことを検知する異常検知手段１４と、異常検知手段１４が異常を検知したとき、サーバに対し該サーバが通信に使用するプロトコルでの通信が異常か正常か確認するための通知を順次行うと共に、正常な通信ができるプロトコルのサーバに対して異常を通知する異常時通信手段１５とを備えたことを特徴とする。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、異常が発生したとき使用可能なプロトコルを判別でき、各サーバに異常を伝えることができるデータ配信装置、とくに画像を配信する画像配信装置に関する。
【背景技術】
【０００２】
近年、インターネットやイントラネット等のＩＰネットワークに接続されて、自分の異常状態を相手に通知する電子機器が提案されている（例えば、特許文献１）。この特許文献１の電子機器は、電子黒板や複写機、ファクシミリ装置、プリンタ、コンピュータ、デジタルカメラ等であり、自分の異常を検知する異常検知部と、検知した異常内容に対応した異常診断情報を取得する診断情報取得部と、この診断情報を予め設定された通知相手へ電子メールで通知する自己異常通知部が設けられている。
【０００３】
この特許文献１の電子機器は、異常が発生したとき、ユーザに異常診断情報を電子メールで通知し、注意を喚起する。異常診断情報としては、例えば、紙送り機構、読取機構、印刷機構、クリーニング機構等に関する異常の種類、状況の詳細、発生日時等が通知される。しかし、特許文献１の電子機器による通知は電子メールに依存しているため、メール機能自体に異常が発生したときは電子機器の異常がまったく分らないものであった。
【０００４】
また、最近多数の通信端末からＩＰネットワークを介してアクセスすると、データを配信するデータ配信装置、例えば画像配信装置や音楽データ等の配信装置、中でもカメラ部を搭載したネットワークカメラが広く普及してきている。ネットワークカメラは、ＩＰネットワークを介して通信端末のＷｅｂブラウザがＷｅｂサーバであるネットワークカメラとプロトコルＨＴＴＰで通信するもので、撮影した画像、場合によっては音声も各通信端末に送信する。同時に、ネットワークカメラは、プロトコルＳＭＴＰ、ＰＯＰを使って、画像等を添付した電子メール等をメールサーバとの間で送受信し、さらにこれにより他の通信端末との間で電子メール等を送受信する。
【０００５】
従来、このようなネットワークカメラは、プロトコル処理中に異常（以下、通信異常）が発生した場合、ＷｅｂブラウザからネットワークカメラにＨＴＴＰでアクセスし、ネットワークステータス画面を確認するしか異常発生を知る術がなかった。そして、ＨＴＴＰ自体に異常が発生している場合はネットワークステータス画面へのアクセスそのものが不可能になるため、カメラ内部で何が起こっているのかまったく分らなかった。
【０００６】
図６は従来のネットワークステータス画面の説明図である。図６において、１０１はネットワークで通信可能なはずのプロトコル、１０２は接続要求して成功したか失敗したかの成功／失敗、１０３は接続要求して成功または失敗した回数である。図６ではＳＭＴＰとＰＯＰの２つのプロトコルが表示され、いずれもメールサーバに１０回接続要求して１０回とも成功しており、異常がない正常な状態を示している。なお、異常か正常かはこの画面情報を取得したユーザによって、この画面情報により失敗回数の割合で判断されていた。そして、ＨＴＴＰのプロトコルでの成功、失敗は、ネットワークステータス画面の取得の有無の結果そのものであるから、何回も接続要求してみてその結果を反映するネットワークステータス画面には表示できない。
【０００７】
ところで、ＷｅｂブラウザからＩＰネットワークのネットワークカメラにアクセスするときは、通常ＤＮＳ（Ｄｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ）サーバによってＵＲＬ等に対応するＩＰアドレスを取得して、ＩＰパケットを送信する。しかし、プロトコルＩＰｖ４の下ではＩＰアドレスは枯渇している状況にあり、ＤＨＣＰ（Ｄｙｎａｍｉｃ Ｈｏ
ｓｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）サーバによって限られたＩＰアドレスを時間制限付で割り当てることが行われている。このとき、ＤＮＳサーバは動的に変化するＩＰアドレスに対応できないため、この場合、ＤＤＮＳ（Ｄｙｎａｍｉｃ Ｄｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ）サーバが使用される。このように通信端末はＩＰネットワーク接続環境下においてはほぼ例外なくＤＮＳサーバ、ＤＤＮＳサーバに接続可能に設定される。
【特許文献１】特開２００３−１５８５９９号公報
【発明の開示】
【発明が解決しようとする課題】
【０００８】
以上説明したように特許文献１の電子機器は、異常発生の通知を電子メールに依存しているため、メール機能に異常が発生したときは電子機器の状態がまったく分らないものとなる。
【０００９】
これはネットワークカメラにおいても同様であり、通信異常が発生した場合はネットワークステータス画面を確認するしか方法がなく、画像を通信するＨＴＴＰ自体に異常が発生している場合は、この方法すらできず、カメラの状態をまったく把握できなくなってしまうものであった。
【００１０】
このように、従来の異常発生の確認は、ユーザフレンドリーなものとはいえないだけでなく、フェールセーフ上問題があり、訳の分らないままネットワークカメラ等のデータ配信装置から配信を受けられないという問題があった。
【００１１】
ところでネットワークカメラ等のデータ配信装置は、プロトコルＦＴＰを用いてデータファイルをＦＴＰサーバに転送し、また、プロトコルＮＴＰを用いてタイムサーバから時間データの取得も行う。従って、これらのプロトコル処理上で通信異常が発生した場合にも、異常が分るデータ配信装置が望まれる。また、異常は通信上だけでなく、システム上も発生する。自己診断によりシステム異常と判断される場合に、異常を確実に通知できるデータ配信装置が望まれる。
【００１２】
そこで本発明は、異常が発生したとき使用可能なプロトコルを判別でき、各サーバに異常を伝えることができるデータ配信装置及び画像配信装置を提供することを目的とする。
【課題を解決するための手段】
【００１３】
上記課題を解決するために本発明のデータ配信装置は、ＩＰネットワークに接続されて複数の所定のサーバと通信できると共に、通信端末に対してデータの配信をすることができる通信部と、通信上及び／またはシステム上異常が発生したことを検知する異常検知手段と、異常検知手段が異常を検知したとき、サーバに対し該サーバが通信に使用するプロトコルでの通信が異常か正常か確認するための通知を順次行うと共に、正常な通信ができるプロトコルのサーバに対して異常を通知する異常時通信手段とを備えたことを特徴とする。
【発明の効果】
【００１４】
本発明のデータ配信装置によれば、異常が発生したとき使用可能なプロトコルを判別でき、各サーバに異常を伝えることができ、フェールセーフに適ったデータ配信装置及び画像配信装置を提供できる。
【発明を実施するための最良の形態】
【００１５】
上記課題を解決するために本発明の第１の発明は、ＩＰネットワークに接続されて複数の所定のサーバと通信できると共に、通信端末に対してデータの配信をすることができる
通信部と、通信上及び／またはシステム上異常が発生したことを検知する異常検知手段と、異常検知手段が異常を検知したとき、サーバに対し該サーバが通信に使用するプロトコルでの通信が異常か正常か確認するための通知を順次行うと共に、正常な通信ができるプロトコルのサーバに対して異常を通知する異常時通信手段とを備えたことを特徴とするデータ配信装置であり、異常が発生したとき使用可能なプロトコルを判別でき、各サーバに異常を伝えることができる。
【００１６】
本発明の第２の発明は、第１の発明に従属する発明であって、データの配信に使用するプロトコルが第１のプロトコルの場合、異常時通信手段が、通信が異常か正常か確認するための通知を第１以外の少なくとも第２のプロトコルで通信するサーバに送信する特徴とするデータ配信装置であり、データ配信のための第１のプロトコルでなく、第１以外の少なくとも第２のプロトコルで異常を確認するので、通信異常の場合にも正常の可能性が高く、確実に各サーバに異常を伝えることができる。
【００１７】
本発明の第３の発明は、第２の発明に従属する発明であって、異常時通信手段が、通信が異常か正常か確認するための通知を第１以外の少なくとも第２のプロトコルで通信するサーバに送信した後、通信が異常か正常か確認するための通知を第１のプロトコルで通信するサーバに送信する特徴とするデータ配信装置であり、データ配信のための第１のプロトコルでなく、初めに第１以外の少なくとも第２のプロトコルで異常を確認するので、通信異常の場合にも正常の可能性が高く、確実に各サーバに異常を伝えることができ、次に第１のプロトコルの異常発生も確認することができる。
【００１８】
本発明の第４の発明は、第１の発明に従属する発明であって、データの配信に使用するプロトコルがＨＴＴＰ、サーバの１つがＤＤＮＳサーバのとき、異常時通信手段が、通信が異常か正常か確認するための通知を少なくともＤＤＮＳサーバに行うと共に、正常な通信ができればＤＤＮＳサーバに異常を通知することを特徴とするデータ配信装置であり、ＤＤＮＳサーバに異常を伝えておけば、クライアントがその後無駄なアクセスをすることがない。
【００１９】
本発明の第５の発明は、画像を撮影するカメラ部と、画像信号を圧縮する圧縮部と、ＩＰネットワークに接続されて複数のサーバと通信できると共に、通信端末に対して圧縮部で圧縮されたデータを配信できる通信部を備えた画像配信装置であって、通信上及び／またはシステム上異常が発生したことを検知する異常検知手段と、異常検知手段が異常を検知したとき、サーバに対し該サーバが通信に使用するプロトコルでの通信が異常か正常か確認するための通知を順次行うと共に、正常な通信ができるプロトコルのサーバに対して異常を通知する異常時通信手段とを備えたことを特徴とする画像配信装置であり、異常が発生したとき使用可能なプロトコルを判別でき、各サーバに異常を伝えることができる。
【００２０】
本発明の第６の発明は、第５の発明に従属する発明であって、データの配信に使用するプロトコルが第１のプロトコルの場合、異常時通信手段が、通信が異常か正常か確認するための通知を第２のプロトコルで通信するサーバに送信する特徴とする画像配信装置であり、画像データ配信のための第１のプロトコルでなく、第２のプロトコルで異常を確認するので、通信異常の場合にも正常の可能性が高く、確実に各サーバに異常を伝えることができる。
【００２１】
本発明の第７の発明は、第６の発明に従属する発明であって、異常時通信手段が、通信が異常か正常か確認するための通知を第２のプロトコルで通信するサーバに送信した後、通信が異常か正常か確認するための通知を第１のプロトコルで通信するサーバに送信する特徴とする画像配信装置であり、画像データ配信のための第１のプロトコルでなく、まず第２のプロトコルで異常を確認するので、通信異常の場合にも正常の可能性が高く、確実
に各サーバに異常を伝えることができ、次に第１のプロトコルの異常発生も確認することができる。
【００２２】
本発明の第８の発明は、第６または７の発明の画像配信装置において、通信が異常か正常か確認するための通知を第２のプロトコルで通信するサーバに送信するのに代えて、通信が異常か正常か確認するための通知を第２のプロトコルで通信するサーバに送信すると共に、さらに第３のプロトコルで通信するサーバに送信する特徴とする画像配信装置であり、さらに確実に各サーバに異常を伝えることができる。
【００２３】
本発明の第９の発明は、第６または７の発明に従属する発明であって、第１のプロトコルがＨＴＴＰ、第２のプロトコルがＳＭＴＰであることを特徴とする画像配信装置であり、異常が発生したとき、まずプロトコルＳＭＴＰでの通信が行えるか否かを判別するので、クライアントに異常発生を通知することができ、正常な可能性が高く、確認される頻度も非常に高い。
【００２４】
本発明の第１０の発明は、第８の発明に従属する発明であって、第１のプロトコルがＨＴＴＰ、第２のプロトコルがＳＭＴＰ、第３のプロトコルがＦＴＰであることを特徴とする画像配信装置であり、さらにプロトコルＦＴＰでの通信が行えるか否かを判別するので、正常な可能性が高い。
【００２５】
本発明の第１１の発明は、第６の発明に従属する発明であって、データの配信に使用するプロトコルがＨＴＴＰ、サーバの１つがＤＤＮＳサーバのとき、異常時通信手段が、通信が異常か正常か確認するための通知を少なくともＤＤＮＳサーバに行うと共に、正常な通信ができればＤＤＮＳサーバに異常を通知することを特徴とする画像配信装置であり、ＤＤＮＳサーバに異常を伝えておけば、クライアントがその後無駄なアクセスをすることがない。
【実施例】
【００２６】
（実施例１）
本発明の実施例１におけるデータ配信装置について説明する。実施例１のデータ配信装置はネットワークカメラである。図１は本発明の実施例１におけるデータ配信システムの構成図、図２は本発明の実施例１におけるデータ配信装置の構成図、図３は本発明の実施例１における各サーバの構成図、図４は本発明の実施例１におけるネットワークステータス画面の説明図、図５は本発明の実施例１における異常処理部の処理のフローチャートである。
【００２７】
図１において、１はインターネットやイントラネット等のＴＣＰ／ＵＤＰ、ＩＰで通信するＩＰネットワーク、２は画像データ等を配信する画像サーバであるネットワークカメラ（本発明のデータ配信装置）、３はＤＮＳサーバ、４はプロトコルＩＰｖ４の下で必要なＤＤＮＳサーバ、５はプロトコルＩＰｖ４の下で必要なＤＨＣＰサーバ、６はＤＮＳサーバ３やＤＤＮＳサーバ４を使ってＵＲＬ等をＩＰアドレスに変換しＩＰネットワーク１を介してネットワークカメラ２にアクセスすることができる通信端末である。なお、図１はプロトコルＩＰｖ４の接続環境を示したもので、ＩＰｖ６の下ではＤＨＣＰサーバ５は必要なくなる。
【００２８】
なお、実施例１においては、データ配信装置としてネットワークカメラ２を説明するが、ネットワークカメラ２に限られるものではない。ネットワークカメラ２とは別の、蓄積した画像データを配信する画像配信装置や、音楽等のデータを配信する音声データ配信装置であってもよいことはいうまでもない。
【００２９】
７はネットワークカメラ２の管理者の設定したメールアドレスにＤＤＮＳサーバ２から電子メールを送信可能なＳＭＴＰサーバ、８はネットワークカメラ２のメールアドレスに電子メールを送信可能なＰＯＰサーバ、９はプロトコルＦＴＰを用いてネットワークカメラ２から受信したデータファイルを転送するＦＴＰサーバ、１０はプロトコルＮＴＰを用いてネットワークカメラ２が時間データを取得するタイムサーバである。
【００３０】
次にネットワークカメラ２の構成について説明する。図２において、１１はハードウェアとしてのＣＰＵがメインメモリに読み込まれたプログラムを実行して各機能を実現する機能実現手段としての制御部、１２はネットワークカメラ２がＩＰネットワーク１等を介して通信を行う通信部である。
【００３１】
通信部１２には以下のようなプロトコルで通信する複数の通信部が設けられている。１２ａはプロトコルＨＴＴＰでＤＮＳサーバ３やＤＤＮＳサーバ４、通信端末６等と通信できるＨＴＴＰ通信部、１２ｂはプロトコルＳＭＴＰで電子メールを送信するＳＭＴＰ通信部、１２ｃはプロトコルＰＯＰで電子メールを受信するＰＯＰ通信部、１２ｄはプロトコルＦＴＰを用いてデータファイルをＦＴＰサーバ９に送信するＦＴＰ通信部、１２ｅはプロトコルＮＴＰを用いてタイムサーバ１０から時間データを取得するＮＴＰ通信部である。なお、ＨＴＴＰ通信部１２ａは、ＤＮＳサーバ３やＤＤＮＳサーバ４に対してクライアントとして機能するが、通信端末６等に対しては画像サーバとして機能する。そして、使用可能なプロトコルが他にあれば、さらに別の通信部を搭載すればよく、通信部は上記通信部に限られない。
【００３２】
続いて、１３は制御部１１に設けられた異常検知時の処理を行う異常処理部、１４は異常処理部１３に設けられ、ネットワークカメラ２に異常が発生したことを検知する異常検知手段、１４ａは使用可能なプロトコルを判定するためのアクセス（異常か正常かを確認するための複数回の接続要求を行う処理）の成功、失敗の回数をカウントするカウンタ、１５は異常検知手段１３が異常を検知したときとき異常か正常かの確認のための通知を行い、各サーバに異常を通知する機能実現手段としての異常時通信手段である。
【００３３】
なお、実施例１で説明する異常検知手段１３が検知する異常は、通信異常（通信エラー）であるが、異常はネットワークカメラ２自体のシステム異常であってもよい。例えば、後述のカメラ部１８、画像信号圧縮手段１９、撮像手段駆動部２０等にシステム異常があることを自己診断して検知し、異常時通信手段１５が使用可能なプロトコルを判定して、このプロトコルを使用するサーバにシステム異常を通知すればよい。
【００３４】
このように実施例１における異常の通知は、通信上及び／またはシステム上異常が発生したとき送信される異常情報を含んだ通信上及び／またはシステム上の装置状態情報（以下、異常情報を含んだ通信／システム状態情報）である。
【００３５】
１６はプログラム等を記憶する記憶部、１６ａは記憶部１６に設けられた通信／システム状態情報を記憶する異常情報用格納部、１６ｂはネットワークカメラ２の管理者が設定した異常情報を含んだ通信／システム状態情報の通知を行うべき相手のメールアドレス若しくはＳＭＴＰサーバ７のアドレス情報、ＦＴＰサーバ９とＤＤＮＳサーバ４、あるいはＤＮＳサーバ３のアドレス情報を格納したアドレス情報部である。
【００３６】
１７はＩＰネットワーク１に接続するための回線インターフェース、１８はＣＣＤ等の撮像手段（図示しない）を備えて画像を撮影して画像信号を出力するカメラ部、１９は画像信号をＪＰＥＧ、ＭＰＥＧ等の形式に圧縮して出力する画像信号圧縮手段（本発明の圧縮部）である。２０は撮像手段の制御を行う撮像手段駆動部である。
【００３７】
続いて、各サーバの構成について説明する。図３において、２１は各サーバの制御部、２２はＩＰネットワーク１等を介して通信を行う通信部、２２ａは各サーバのサーバ処理部である。サーバ処理部２２ａは、ＤＤＮＳサーバ４、ＳＭＴＰサーバ７、ＦＴＰサーバ９、タイムサーバ１０等のそれぞれにおいて、クライアントからの要求を受信すると、それぞれの処理を行って送信する。例えば、ＤＤＮＳサーバ４のサーバ処理部２２ａは、通信端末６等のＷｅｂブラウザからＵＲＬ等でアクセスされると対応するＩＰアドレスを通知し、ＳＭＴＰサーバ７のサーバ処理部２２ａは電子メールを指定された宛先のメールアドレスに送信し、ＦＴＰサーバ９のサーバ処理部２２ａは画像データを転送し、タイムサーバ１０のサーバ処理部２２ａは時間データをクライアントであるネットワークカメラ２に通知する。
【００３８】
２３は各サーバにおいて制御部２１内に設けられ異常処理を行う異常処理部、２４はネットワークカメラ２から通知された異常情報を含んだ通信／システム状態情報を保存する異常情報保存手段、２５は通信端末６等のクライアントからアクセスされたとき異常を通知するため異常情報を含んだ通信／システム状態情報を送信する異常通知手段である。２６は各サーバのプログラム等を記憶する記憶部、２６ａは記憶部２６に設けられた異常情報を含んだ通信／システム状態情報を記憶する異常情報格納部、２７はＩＰネットワーク１に接続するための回線インターフェースである。
【００３９】
次に、実施例１のネットワークカメラ２の異常処理部１３で行われる異常処理について説明する。異常検知手段１４は、ネットワークカメラ２に通信エラー、通常ＨＴＴＰエラーが発生したことを検知すると、異常時通信手段１５はＳＭＴＰ通信部１２ｂ、ＰＯＰ通信部１２ｃによってＳＭＴＰサーバ７、ＰＯＰサーバ８に接続要求を送信させ、ＳＭＴＰサーバ７から「２５０」、ＰＯＰサーバ８から「ＯＫ」等の応答が返ってきたときを成功とし、応答が所定時間内に返ってこなかったとき失敗と判断する。１回のアクセスだけでは異常か否かを判定するのは正確でないため、異常時通信手段１５は接続要求を複数回行わせ、例えば、１０回接続要求を通知して５回失敗したような場合、プロトコルＳＭＴＰ、ＰＯＰを使っての通信に異常が発生していると判断する。
【００４０】
同様に、異常検知手段１４がネットワークカメラ２に通信エラーが発生したことを検知すると、異常時通信手段１５はＦＴＰ通信部１２ｄ、ＮＴＰ通信部１２ｅによってＦＴＰサーバ９、タイムサーバ１０に接続要求を送信させ、ＦＴＰサーバ９から応答が、またタイムサーバ１０から時間データが返ってきたとき成功とし、これらが所定時間内に返ってこなかったとき失敗と判断する。異常時通信手段１５はこの処理を複数回行わせ、失敗の比率が所定レベルを越えた場合、プロトコルＦＴＰ、ＮＴＰでの通信に異常が発生していると判断するものである。
【００４１】
また、異常検知手段１４がネットワークカメラ２に通信エラーが発生したことを検知した場合も、異常時通信手段１５はＨＴＴＰ通信部１２ａによってＤＤＮＳサーバ４に接続要求を送信させ、ＤＤＮＳサーバ４から「２００ ＯＫ」の応答が返ってきたときを成功とし、応答が所定時間内に返ってこなかったとき失敗と判断する。異常時通信手段１５はこの処理を複数回ＨＴＴＰ通信部１２ａに行わせ、失敗の比率が所定レベルを越えた場合、プロトコルＨＴＴＰでの通信に異常が発生していると判断する。
【００４２】
図４はこのようにして行われた実施例１の通信／システム状態情報を表示したネットワークステータス画面である。図４において、２８はネットワークで通信可能なプロトコル、２９は接続要求して成功したか失敗したかの成功／失敗、３０は接続要求して成功または失敗した回数、３１は異常か正常かの判定である。図４に示したように、プロトコルＦＴＰ以外は１０回のアクセスがすべて成功しているのに対して、プロトコルＦＴＰにおいては８回失敗して２回成功している。成功と失敗の判定基準はいろいろ設定可能であるが
、仮に失敗の比率５０％以上の判定基準だとすると、１０回中８回失敗しているため異常と判断できるから、異常処理部１３はプロトコルＦＴＰを異常とし、失敗のない他のプロトコルを正常として、この通信／システム状態情報を異常情報用格納部１６ａに記憶している。なお、通信／システム状態情報は、異常情報用格納部１６ａに異常情報を含んだ場合も、含まない場合も記憶される。
【００４３】
図４に示したようなＦＴＰの通信異常がある場合は、この後、異常時通信手段１５が異常情報用格納部１６ａから異常情報を含んだ通信／システム状態情報を取り出して、これをＦＴＰ以外の正常なプロトコルを使って、ＨＴＴＰ通信部１２ａ、ＳＭＴＰ通信部１２ｂからＤＤＮＳサーバ４、ＳＭＴＰサーバ７に送信する。
【００４４】
この異常情報を含んだ通信／システム状態情報を受信した各サーバの異常処理部２３は、異常情報保存手段２４が異常情報格納部２６ａにこれを格納する。その後、通信端末６のようなクライアントから各サーバがアクセスされたとき、異常通知手段２５は異常情報を含んだ通信／システム状態情報を異常情報格納部２６ａから取り出し、クライアントに通知する。
【００４５】
例えば、通信端末６等からネットワークカメラ２のＩＰアドレスを取得するためにＤＤＮＳサーバ４ＵＲＬ等でアクセスすると、異常情報を含んだ通信／システム状態情報がＨＴＴＰで通知される。実施例１ではＷｅｂブラウザで表示できるようにＨＴＭＬ等のネットワークステータス画面生成情報が通信端末６等に通知される。ＦＴＰサーバ９もＦＴＰの通信エラーがないときはＦＴＰでこの情報が通知される。なお、ＳＭＴＰサーバ７は、通信端末６等からのアクセスを待つのではなく、異常情報を含んだ通信／システム状態情報を受信するとメールアドレス宛に転送するか、あるいはこの通知を受けたとき記憶部２６に格納されたメールアドレスを参照し、このメールアドレス宛に通信／システム状態情報を添付して送信する。
【００４６】
そこで、実施例１における異常処理部の処理について図５に基づいて説明する。プロトコルＰＯＰ、ＮＴＰは異常を通知する手段としては利用が難しいので、プロトコルＳＭＴＰ、ＦＴＰ、ＨＴＴＰ使って通知する場合である。図５において、異常検知手段１４がネットワークカメラ２の異常、例えばＨＴＴＰによる画像の通信エラーの発生を検知すると（ｓｔｅｐ１）、異常時通信手段１５はＳＭＴＰサーバ７に接続要求を通知し、成功と失敗の回数をカウントして、プロトコルＳＭＴＰでの通信が異常か正常に行えるかを判定する（ｓｔｅｐ２）。
【００４７】
ｓｔｅｐ２において、プロトコルＳＭＴＰでの通信が正常の場合、他のプロトコルで通信の異常か正常かを判断するものがあるかチェックし（ｓｔｅｐ３）、無い場合はそのまま終了する。ｓｔｅｐ２において異常があった場合と、ｓｔｅｐ３でさらに他のプロトコルで異常か正常かを判断する場合は、異常時通信手段１５はＦＴＰサーバ９に接続要求を通知し、成功と失敗の回数をカウントして、プロトコルＦＴＰでの通信が異常か正常に行えるかを判定する（ｓｔｅｐ４）。
【００４８】
ｓｔｅｐ４において、プロトコルＦＴＰでの通信が正常の場合、他のプロトコルで通信の異常か正常かを判断するものがあるかチェックし（ｓｔｅｐ５）、無い場合はそのまま終了する。ｓｔｅｐ４において異常があった場合と、ｓｔｅｐ５で他のプロトコルで異常か正常かを判断する場合は、異常時通信手段１５はＤＤＮＳサーバ４に接続要求を通知し、成功と失敗の回数をカウントして、プロトコルＨＴＴＰでの通信が異常か正常に行えるかを判定する（ｓｔｅｐ６）。
【００４９】
ｓｔｅｐ６において、プロトコルＨＴＴＰでの通信が正常の場合は終了し、異常な場合
は正常なプロトコルがあるか否かをチェックする（ｓｔｅｐ７）。正常なプロトコルが無い場合はそのまま終了し、正常なプロトコルがある場合はその正常なプロトコルのすべて若しくは一部で異常情報を含んだ通信／システム状態情報を該当するプロトコルのサーバに通知して（ｓｔｅｐ８）、終了する。
【００５０】
なお、ｓｔｅｐ２、４、６でプロトコルＳＭＴＰ、ＦＴＰ、ＨＴＴＰでの通信に異常が起こっているか否かを判定したが、その他のプロトコルを判定する場合は、同様な判定を繰返せばよい。
【００５１】
このように本発明の実施例１のネットワークカメラは、異常が発生したとき複数のプロトコルで順次各サーバに接続要求するので、使用可能なプロトコルが判別できる。そして従来は分らなかった常時使用（データ配信）するプロトコルＨＴＴＰの異常発生も確認することができ、すべてのプロトコルが異常でない限りは各サーバに異常を伝えることが可能になり、フェールセーフに適ったネットワークカメラを提供できる。
【００５２】
また、実施例１のネットワークカメラは、異常が発生したとき、まずプロトコルＳＭＴＰでの通信ができるか否かを判別するので、通知を行うべき相手のメールアドレス宛に異常発生を通知することができる。異常が通信上のエラーの場合は、データ配信するＨＴＴＰエラーの可能性が高く、このときＳＭＴＰは正常な可能性が高い上に、電子メールなら相手が着信を頻繁にチェックする可能性も高くなる。
【００５３】
次に、プロトコルＦＴＰでの通信が行えるか否かを判別するが、同様にデータ配信を行うＨＴＴＰでないため、正常な可能性が高い。さらに最後にＤＤＮＳサーバとの間でプロトコルＨＴＴＰでの通信が使えるか否かを判別するが、既に他の正常なプロトコルで通知ができている場合が多く、ＨＴＴＰでの通知に対する期待も軽くなっており、ＤＤＮＳサーバと通信ができればエラーの原因がネットワークカメラ側にはなかったことが分るし、できなければネットワークカメラに原因が在ることが分る。また、これによってＤＤＮＳサーバに異常を伝えておけば、データ配信を受けるためアクセスしたユーザがその後無駄なアクセスをすることがない。
【００５４】
実施例１においては、各サーバに異常情報を含んだ通信／システム状態情報を、異常を伝える情報として通知し、アクセスされたときユーザにこれを通知するので、どのサーバが正常で、そのサーバが異常かを直ちに判別することができる。
【産業上の利用可能性】
【００５５】
本発明は、複数のプロトコルで通信可能なデータ配信装置に適用できる。
【図面の簡単な説明】
【００５６】
【図１】本発明の実施例１におけるデータ配信システムの構成図
【図２】本発明の実施例１におけるデータ配信装置の構成図
【図３】本発明の実施例１における各サーバの構成図
【図４】本発明の実施例１におけるネットワークステータス画面の説明図
【図５】本発明の実施例１における異常処理部の処理のフローチャート
【図６】従来のネットワークステータス画面の説明図
【符号の説明】
【００５７】
１ ＩＰネットワーク
２ ネットワークカメラ
３ ＤＮＳサーバ
４ ＤＤＮＳサーバ
５ ＤＨＣＰサーバ
６ 通信端末
７ ＳＭＴＰサーバ
８ ＰＯＰサーバ
９ ＦＴＰサーバ
１０ タイムサーバ
１１ 制御部
１２ 通信部
１２ａ ＨＴＴＰ通信部
１２ｂ ＳＭＴＰ通信部
１２ｃ ＰＯＰ通信部
１２ｄ ＦＴＰ通信部
１２ｅ ＮＴＰ通信部
１３ 異常処理部
１４ 異常検知手段
１４ａ カウンタ
１５ 異常時通信手段
１６ 記憶部
１６ａ 異常情報用格納部
１６ｂ アドレス情報部
１７ 回線インターフェース
１８ カメラ部
１９ 画像信号圧縮手段
２０ 撮像手段駆動部
２１ 制御部
２２ 通信部
２２ａ サーバ処理部
２３ 異常処理部
２４ 異常情報保存手段
２５ 異常通知手段
２６ 記憶部
２６ａ 異常情報格納部
２７ 回線インターフェース
２８，１０１ プロトコル
２９，１０２ 成功／失敗
３０，１０３ 回数
３１ 判定
【技術分野】
【０００１】
本発明は、異常が発生したとき使用可能なプロトコルを判別でき、各サーバに異常を伝えることができるデータ配信装置、とくに画像を配信する画像配信装置に関する。
【背景技術】
【０００２】
近年、インターネットやイントラネット等のＩＰネットワークに接続されて、自分の異常状態を相手に通知する電子機器が提案されている（例えば、特許文献１）。この特許文献１の電子機器は、電子黒板や複写機、ファクシミリ装置、プリンタ、コンピュータ、デジタルカメラ等であり、自分の異常を検知する異常検知部と、検知した異常内容に対応した異常診断情報を取得する診断情報取得部と、この診断情報を予め設定された通知相手へ電子メールで通知する自己異常通知部が設けられている。
【０００３】
この特許文献１の電子機器は、異常が発生したとき、ユーザに異常診断情報を電子メールで通知し、注意を喚起する。異常診断情報としては、例えば、紙送り機構、読取機構、印刷機構、クリーニング機構等に関する異常の種類、状況の詳細、発生日時等が通知される。しかし、特許文献１の電子機器による通知は電子メールに依存しているため、メール機能自体に異常が発生したときは電子機器の異常がまったく分らないものであった。
【０００４】
また、最近多数の通信端末からＩＰネットワークを介してアクセスすると、データを配信するデータ配信装置、例えば画像配信装置や音楽データ等の配信装置、中でもカメラ部を搭載したネットワークカメラが広く普及してきている。ネットワークカメラは、ＩＰネットワークを介して通信端末のＷｅｂブラウザがＷｅｂサーバであるネットワークカメラとプロトコルＨＴＴＰで通信するもので、撮影した画像、場合によっては音声も各通信端末に送信する。同時に、ネットワークカメラは、プロトコルＳＭＴＰ、ＰＯＰを使って、画像等を添付した電子メール等をメールサーバとの間で送受信し、さらにこれにより他の通信端末との間で電子メール等を送受信する。
【０００５】
従来、このようなネットワークカメラは、プロトコル処理中に異常（以下、通信異常）が発生した場合、ＷｅｂブラウザからネットワークカメラにＨＴＴＰでアクセスし、ネットワークステータス画面を確認するしか異常発生を知る術がなかった。そして、ＨＴＴＰ自体に異常が発生している場合はネットワークステータス画面へのアクセスそのものが不可能になるため、カメラ内部で何が起こっているのかまったく分らなかった。
【０００６】
図６は従来のネットワークステータス画面の説明図である。図６において、１０１はネットワークで通信可能なはずのプロトコル、１０２は接続要求して成功したか失敗したかの成功／失敗、１０３は接続要求して成功または失敗した回数である。図６ではＳＭＴＰとＰＯＰの２つのプロトコルが表示され、いずれもメールサーバに１０回接続要求して１０回とも成功しており、異常がない正常な状態を示している。なお、異常か正常かはこの画面情報を取得したユーザによって、この画面情報により失敗回数の割合で判断されていた。そして、ＨＴＴＰのプロトコルでの成功、失敗は、ネットワークステータス画面の取得の有無の結果そのものであるから、何回も接続要求してみてその結果を反映するネットワークステータス画面には表示できない。
【０００７】
ところで、ＷｅｂブラウザからＩＰネットワークのネットワークカメラにアクセスするときは、通常ＤＮＳ（Ｄｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ）サーバによってＵＲＬ等に対応するＩＰアドレスを取得して、ＩＰパケットを送信する。しかし、プロトコルＩＰｖ４の下ではＩＰアドレスは枯渇している状況にあり、ＤＨＣＰ（Ｄｙｎａｍｉｃ Ｈｏ
ｓｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）サーバによって限られたＩＰアドレスを時間制限付で割り当てることが行われている。このとき、ＤＮＳサーバは動的に変化するＩＰアドレスに対応できないため、この場合、ＤＤＮＳ（Ｄｙｎａｍｉｃ Ｄｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ）サーバが使用される。このように通信端末はＩＰネットワーク接続環境下においてはほぼ例外なくＤＮＳサーバ、ＤＤＮＳサーバに接続可能に設定される。
【特許文献１】特開２００３−１５８５９９号公報
【発明の開示】
【発明が解決しようとする課題】
【０００８】
以上説明したように特許文献１の電子機器は、異常発生の通知を電子メールに依存しているため、メール機能に異常が発生したときは電子機器の状態がまったく分らないものとなる。
【０００９】
これはネットワークカメラにおいても同様であり、通信異常が発生した場合はネットワークステータス画面を確認するしか方法がなく、画像を通信するＨＴＴＰ自体に異常が発生している場合は、この方法すらできず、カメラの状態をまったく把握できなくなってしまうものであった。
【００１０】
このように、従来の異常発生の確認は、ユーザフレンドリーなものとはいえないだけでなく、フェールセーフ上問題があり、訳の分らないままネットワークカメラ等のデータ配信装置から配信を受けられないという問題があった。
【００１１】
ところでネットワークカメラ等のデータ配信装置は、プロトコルＦＴＰを用いてデータファイルをＦＴＰサーバに転送し、また、プロトコルＮＴＰを用いてタイムサーバから時間データの取得も行う。従って、これらのプロトコル処理上で通信異常が発生した場合にも、異常が分るデータ配信装置が望まれる。また、異常は通信上だけでなく、システム上も発生する。自己診断によりシステム異常と判断される場合に、異常を確実に通知できるデータ配信装置が望まれる。
【００１２】
そこで本発明は、異常が発生したとき使用可能なプロトコルを判別でき、各サーバに異常を伝えることができるデータ配信装置及び画像配信装置を提供することを目的とする。
【課題を解決するための手段】
【００１３】
上記課題を解決するために本発明のデータ配信装置は、ＩＰネットワークに接続されて複数の所定のサーバと通信できると共に、通信端末に対してデータの配信をすることができる通信部と、通信上及び／またはシステム上異常が発生したことを検知する異常検知手段と、異常検知手段が異常を検知したとき、サーバに対し該サーバが通信に使用するプロトコルでの通信が異常か正常か確認するための通知を順次行うと共に、正常な通信ができるプロトコルのサーバに対して異常を通知する異常時通信手段とを備えたことを特徴とする。
【発明の効果】
【００１４】
本発明のデータ配信装置によれば、異常が発生したとき使用可能なプロトコルを判別でき、各サーバに異常を伝えることができ、フェールセーフに適ったデータ配信装置及び画像配信装置を提供できる。
【発明を実施するための最良の形態】
【００１５】
上記課題を解決するために本発明の第１の発明は、ＩＰネットワークに接続されて複数の所定のサーバと通信できると共に、通信端末に対してデータの配信をすることができる
通信部と、通信上及び／またはシステム上異常が発生したことを検知する異常検知手段と、異常検知手段が異常を検知したとき、サーバに対し該サーバが通信に使用するプロトコルでの通信が異常か正常か確認するための通知を順次行うと共に、正常な通信ができるプロトコルのサーバに対して異常を通知する異常時通信手段とを備えたことを特徴とするデータ配信装置であり、異常が発生したとき使用可能なプロトコルを判別でき、各サーバに異常を伝えることができる。
【００１６】
本発明の第２の発明は、第１の発明に従属する発明であって、データの配信に使用するプロトコルが第１のプロトコルの場合、異常時通信手段が、通信が異常か正常か確認するための通知を第１以外の少なくとも第２のプロトコルで通信するサーバに送信する特徴とするデータ配信装置であり、データ配信のための第１のプロトコルでなく、第１以外の少なくとも第２のプロトコルで異常を確認するので、通信異常の場合にも正常の可能性が高く、確実に各サーバに異常を伝えることができる。
【００１７】
本発明の第３の発明は、第２の発明に従属する発明であって、異常時通信手段が、通信が異常か正常か確認するための通知を第１以外の少なくとも第２のプロトコルで通信するサーバに送信した後、通信が異常か正常か確認するための通知を第１のプロトコルで通信するサーバに送信する特徴とするデータ配信装置であり、データ配信のための第１のプロトコルでなく、初めに第１以外の少なくとも第２のプロトコルで異常を確認するので、通信異常の場合にも正常の可能性が高く、確実に各サーバに異常を伝えることができ、次に第１のプロトコルの異常発生も確認することができる。
【００１８】
本発明の第４の発明は、第１の発明に従属する発明であって、データの配信に使用するプロトコルがＨＴＴＰ、サーバの１つがＤＤＮＳサーバのとき、異常時通信手段が、通信が異常か正常か確認するための通知を少なくともＤＤＮＳサーバに行うと共に、正常な通信ができればＤＤＮＳサーバに異常を通知することを特徴とするデータ配信装置であり、ＤＤＮＳサーバに異常を伝えておけば、クライアントがその後無駄なアクセスをすることがない。
【００１９】
本発明の第５の発明は、画像を撮影するカメラ部と、画像信号を圧縮する圧縮部と、ＩＰネットワークに接続されて複数のサーバと通信できると共に、通信端末に対して圧縮部で圧縮されたデータを配信できる通信部を備えた画像配信装置であって、通信上及び／またはシステム上異常が発生したことを検知する異常検知手段と、異常検知手段が異常を検知したとき、サーバに対し該サーバが通信に使用するプロトコルでの通信が異常か正常か確認するための通知を順次行うと共に、正常な通信ができるプロトコルのサーバに対して異常を通知する異常時通信手段とを備えたことを特徴とする画像配信装置であり、異常が発生したとき使用可能なプロトコルを判別でき、各サーバに異常を伝えることができる。
【００２０】
本発明の第６の発明は、第５の発明に従属する発明であって、データの配信に使用するプロトコルが第１のプロトコルの場合、異常時通信手段が、通信が異常か正常か確認するための通知を第２のプロトコルで通信するサーバに送信する特徴とする画像配信装置であり、画像データ配信のための第１のプロトコルでなく、第２のプロトコルで異常を確認するので、通信異常の場合にも正常の可能性が高く、確実に各サーバに異常を伝えることができる。
【００２１】
本発明の第７の発明は、第６の発明に従属する発明であって、異常時通信手段が、通信が異常か正常か確認するための通知を第２のプロトコルで通信するサーバに送信した後、通信が異常か正常か確認するための通知を第１のプロトコルで通信するサーバに送信する特徴とする画像配信装置であり、画像データ配信のための第１のプロトコルでなく、まず第２のプロトコルで異常を確認するので、通信異常の場合にも正常の可能性が高く、確実
に各サーバに異常を伝えることができ、次に第１のプロトコルの異常発生も確認することができる。
【００２２】
本発明の第８の発明は、第６または７の発明の画像配信装置において、通信が異常か正常か確認するための通知を第２のプロトコルで通信するサーバに送信するのに代えて、通信が異常か正常か確認するための通知を第２のプロトコルで通信するサーバに送信すると共に、さらに第３のプロトコルで通信するサーバに送信する特徴とする画像配信装置であり、さらに確実に各サーバに異常を伝えることができる。
【００２３】
本発明の第９の発明は、第６または７の発明に従属する発明であって、第１のプロトコルがＨＴＴＰ、第２のプロトコルがＳＭＴＰであることを特徴とする画像配信装置であり、異常が発生したとき、まずプロトコルＳＭＴＰでの通信が行えるか否かを判別するので、クライアントに異常発生を通知することができ、正常な可能性が高く、確認される頻度も非常に高い。
【００２４】
本発明の第１０の発明は、第８の発明に従属する発明であって、第１のプロトコルがＨＴＴＰ、第２のプロトコルがＳＭＴＰ、第３のプロトコルがＦＴＰであることを特徴とする画像配信装置であり、さらにプロトコルＦＴＰでの通信が行えるか否かを判別するので、正常な可能性が高い。
【００２５】
本発明の第１１の発明は、第６の発明に従属する発明であって、データの配信に使用するプロトコルがＨＴＴＰ、サーバの１つがＤＤＮＳサーバのとき、異常時通信手段が、通信が異常か正常か確認するための通知を少なくともＤＤＮＳサーバに行うと共に、正常な通信ができればＤＤＮＳサーバに異常を通知することを特徴とする画像配信装置であり、ＤＤＮＳサーバに異常を伝えておけば、クライアントがその後無駄なアクセスをすることがない。
【実施例】
【００２６】
（実施例１）
本発明の実施例１におけるデータ配信装置について説明する。実施例１のデータ配信装置はネットワークカメラである。図１は本発明の実施例１におけるデータ配信システムの構成図、図２は本発明の実施例１におけるデータ配信装置の構成図、図３は本発明の実施例１における各サーバの構成図、図４は本発明の実施例１におけるネットワークステータス画面の説明図、図５は本発明の実施例１における異常処理部の処理のフローチャートである。
【００２７】
図１において、１はインターネットやイントラネット等のＴＣＰ／ＵＤＰ、ＩＰで通信するＩＰネットワーク、２は画像データ等を配信する画像サーバであるネットワークカメラ（本発明のデータ配信装置）、３はＤＮＳサーバ、４はプロトコルＩＰｖ４の下で必要なＤＤＮＳサーバ、５はプロトコルＩＰｖ４の下で必要なＤＨＣＰサーバ、６はＤＮＳサーバ３やＤＤＮＳサーバ４を使ってＵＲＬ等をＩＰアドレスに変換しＩＰネットワーク１を介してネットワークカメラ２にアクセスすることができる通信端末である。なお、図１はプロトコルＩＰｖ４の接続環境を示したもので、ＩＰｖ６の下ではＤＨＣＰサーバ５は必要なくなる。
【００２８】
なお、実施例１においては、データ配信装置としてネットワークカメラ２を説明するが、ネットワークカメラ２に限られるものではない。ネットワークカメラ２とは別の、蓄積した画像データを配信する画像配信装置や、音楽等のデータを配信する音声データ配信装置であってもよいことはいうまでもない。
【００２９】
７はネットワークカメラ２の管理者の設定したメールアドレスにＤＤＮＳサーバ２から電子メールを送信可能なＳＭＴＰサーバ、８はネットワークカメラ２のメールアドレスに電子メールを送信可能なＰＯＰサーバ、９はプロトコルＦＴＰを用いてネットワークカメラ２から受信したデータファイルを転送するＦＴＰサーバ、１０はプロトコルＮＴＰを用いてネットワークカメラ２が時間データを取得するタイムサーバである。
【００３０】
次にネットワークカメラ２の構成について説明する。図２において、１１はハードウェアとしてのＣＰＵがメインメモリに読み込まれたプログラムを実行して各機能を実現する機能実現手段としての制御部、１２はネットワークカメラ２がＩＰネットワーク１等を介して通信を行う通信部である。
【００３１】
通信部１２には以下のようなプロトコルで通信する複数の通信部が設けられている。１２ａはプロトコルＨＴＴＰでＤＮＳサーバ３やＤＤＮＳサーバ４、通信端末６等と通信できるＨＴＴＰ通信部、１２ｂはプロトコルＳＭＴＰで電子メールを送信するＳＭＴＰ通信部、１２ｃはプロトコルＰＯＰで電子メールを受信するＰＯＰ通信部、１２ｄはプロトコルＦＴＰを用いてデータファイルをＦＴＰサーバ９に送信するＦＴＰ通信部、１２ｅはプロトコルＮＴＰを用いてタイムサーバ１０から時間データを取得するＮＴＰ通信部である。なお、ＨＴＴＰ通信部１２ａは、ＤＮＳサーバ３やＤＤＮＳサーバ４に対してクライアントとして機能するが、通信端末６等に対しては画像サーバとして機能する。そして、使用可能なプロトコルが他にあれば、さらに別の通信部を搭載すればよく、通信部は上記通信部に限られない。
【００３２】
続いて、１３は制御部１１に設けられた異常検知時の処理を行う異常処理部、１４は異常処理部１３に設けられ、ネットワークカメラ２に異常が発生したことを検知する異常検知手段、１４ａは使用可能なプロトコルを判定するためのアクセス（異常か正常かを確認するための複数回の接続要求を行う処理）の成功、失敗の回数をカウントするカウンタ、１５は異常検知手段１３が異常を検知したときとき異常か正常かの確認のための通知を行い、各サーバに異常を通知する機能実現手段としての異常時通信手段である。
【００３３】
なお、実施例１で説明する異常検知手段１３が検知する異常は、通信異常（通信エラー）であるが、異常はネットワークカメラ２自体のシステム異常であってもよい。例えば、後述のカメラ部１８、画像信号圧縮手段１９、撮像手段駆動部２０等にシステム異常があることを自己診断して検知し、異常時通信手段１５が使用可能なプロトコルを判定して、このプロトコルを使用するサーバにシステム異常を通知すればよい。
【００３４】
このように実施例１における異常の通知は、通信上及び／またはシステム上異常が発生したとき送信される異常情報を含んだ通信上及び／またはシステム上の装置状態情報（以下、異常情報を含んだ通信／システム状態情報）である。
【００３５】
１６はプログラム等を記憶する記憶部、１６ａは記憶部１６に設けられた通信／システム状態情報を記憶する異常情報用格納部、１６ｂはネットワークカメラ２の管理者が設定した異常情報を含んだ通信／システム状態情報の通知を行うべき相手のメールアドレス若しくはＳＭＴＰサーバ７のアドレス情報、ＦＴＰサーバ９とＤＤＮＳサーバ４、あるいはＤＮＳサーバ３のアドレス情報を格納したアドレス情報部である。
【００３６】
１７はＩＰネットワーク１に接続するための回線インターフェース、１８はＣＣＤ等の撮像手段（図示しない）を備えて画像を撮影して画像信号を出力するカメラ部、１９は画像信号をＪＰＥＧ、ＭＰＥＧ等の形式に圧縮して出力する画像信号圧縮手段（本発明の圧縮部）である。２０は撮像手段の制御を行う撮像手段駆動部である。
【００３７】
続いて、各サーバの構成について説明する。図３において、２１は各サーバの制御部、２２はＩＰネットワーク１等を介して通信を行う通信部、２２ａは各サーバのサーバ処理部である。サーバ処理部２２ａは、ＤＤＮＳサーバ４、ＳＭＴＰサーバ７、ＦＴＰサーバ９、タイムサーバ１０等のそれぞれにおいて、クライアントからの要求を受信すると、それぞれの処理を行って送信する。例えば、ＤＤＮＳサーバ４のサーバ処理部２２ａは、通信端末６等のＷｅｂブラウザからＵＲＬ等でアクセスされると対応するＩＰアドレスを通知し、ＳＭＴＰサーバ７のサーバ処理部２２ａは電子メールを指定された宛先のメールアドレスに送信し、ＦＴＰサーバ９のサーバ処理部２２ａは画像データを転送し、タイムサーバ１０のサーバ処理部２２ａは時間データをクライアントであるネットワークカメラ２に通知する。
【００３８】
２３は各サーバにおいて制御部２１内に設けられ異常処理を行う異常処理部、２４はネットワークカメラ２から通知された異常情報を含んだ通信／システム状態情報を保存する異常情報保存手段、２５は通信端末６等のクライアントからアクセスされたとき異常を通知するため異常情報を含んだ通信／システム状態情報を送信する異常通知手段である。２６は各サーバのプログラム等を記憶する記憶部、２６ａは記憶部２６に設けられた異常情報を含んだ通信／システム状態情報を記憶する異常情報格納部、２７はＩＰネットワーク１に接続するための回線インターフェースである。
【００３９】
次に、実施例１のネットワークカメラ２の異常処理部１３で行われる異常処理について説明する。異常検知手段１４は、ネットワークカメラ２に通信エラー、通常ＨＴＴＰエラーが発生したことを検知すると、異常時通信手段１５はＳＭＴＰ通信部１２ｂ、ＰＯＰ通信部１２ｃによってＳＭＴＰサーバ７、ＰＯＰサーバ８に接続要求を送信させ、ＳＭＴＰサーバ７から「２５０」、ＰＯＰサーバ８から「ＯＫ」等の応答が返ってきたときを成功とし、応答が所定時間内に返ってこなかったとき失敗と判断する。１回のアクセスだけでは異常か否かを判定するのは正確でないため、異常時通信手段１５は接続要求を複数回行わせ、例えば、１０回接続要求を通知して５回失敗したような場合、プロトコルＳＭＴＰ、ＰＯＰを使っての通信に異常が発生していると判断する。
【００４０】
同様に、異常検知手段１４がネットワークカメラ２に通信エラーが発生したことを検知すると、異常時通信手段１５はＦＴＰ通信部１２ｄ、ＮＴＰ通信部１２ｅによってＦＴＰサーバ９、タイムサーバ１０に接続要求を送信させ、ＦＴＰサーバ９から応答が、またタイムサーバ１０から時間データが返ってきたとき成功とし、これらが所定時間内に返ってこなかったとき失敗と判断する。異常時通信手段１５はこの処理を複数回行わせ、失敗の比率が所定レベルを越えた場合、プロトコルＦＴＰ、ＮＴＰでの通信に異常が発生していると判断するものである。
【００４１】
また、異常検知手段１４がネットワークカメラ２に通信エラーが発生したことを検知した場合も、異常時通信手段１５はＨＴＴＰ通信部１２ａによってＤＤＮＳサーバ４に接続要求を送信させ、ＤＤＮＳサーバ４から「２００ ＯＫ」の応答が返ってきたときを成功とし、応答が所定時間内に返ってこなかったとき失敗と判断する。異常時通信手段１５はこの処理を複数回ＨＴＴＰ通信部１２ａに行わせ、失敗の比率が所定レベルを越えた場合、プロトコルＨＴＴＰでの通信に異常が発生していると判断する。
【００４２】
図４はこのようにして行われた実施例１の通信／システム状態情報を表示したネットワークステータス画面である。図４において、２８はネットワークで通信可能なプロトコル、２９は接続要求して成功したか失敗したかの成功／失敗、３０は接続要求して成功または失敗した回数、３１は異常か正常かの判定である。図４に示したように、プロトコルＦＴＰ以外は１０回のアクセスがすべて成功しているのに対して、プロトコルＦＴＰにおいては８回失敗して２回成功している。成功と失敗の判定基準はいろいろ設定可能であるが
、仮に失敗の比率５０％以上の判定基準だとすると、１０回中８回失敗しているため異常と判断できるから、異常処理部１３はプロトコルＦＴＰを異常とし、失敗のない他のプロトコルを正常として、この通信／システム状態情報を異常情報用格納部１６ａに記憶している。なお、通信／システム状態情報は、異常情報用格納部１６ａに異常情報を含んだ場合も、含まない場合も記憶される。
【００４３】
図４に示したようなＦＴＰの通信異常がある場合は、この後、異常時通信手段１５が異常情報用格納部１６ａから異常情報を含んだ通信／システム状態情報を取り出して、これをＦＴＰ以外の正常なプロトコルを使って、ＨＴＴＰ通信部１２ａ、ＳＭＴＰ通信部１２ｂからＤＤＮＳサーバ４、ＳＭＴＰサーバ７に送信する。
【００４４】
この異常情報を含んだ通信／システム状態情報を受信した各サーバの異常処理部２３は、異常情報保存手段２４が異常情報格納部２６ａにこれを格納する。その後、通信端末６のようなクライアントから各サーバがアクセスされたとき、異常通知手段２５は異常情報を含んだ通信／システム状態情報を異常情報格納部２６ａから取り出し、クライアントに通知する。
【００４５】
例えば、通信端末６等からネットワークカメラ２のＩＰアドレスを取得するためにＤＤＮＳサーバ４ＵＲＬ等でアクセスすると、異常情報を含んだ通信／システム状態情報がＨＴＴＰで通知される。実施例１ではＷｅｂブラウザで表示できるようにＨＴＭＬ等のネットワークステータス画面生成情報が通信端末６等に通知される。ＦＴＰサーバ９もＦＴＰの通信エラーがないときはＦＴＰでこの情報が通知される。なお、ＳＭＴＰサーバ７は、通信端末６等からのアクセスを待つのではなく、異常情報を含んだ通信／システム状態情報を受信するとメールアドレス宛に転送するか、あるいはこの通知を受けたとき記憶部２６に格納されたメールアドレスを参照し、このメールアドレス宛に通信／システム状態情報を添付して送信する。
【００４６】
そこで、実施例１における異常処理部の処理について図５に基づいて説明する。プロトコルＰＯＰ、ＮＴＰは異常を通知する手段としては利用が難しいので、プロトコルＳＭＴＰ、ＦＴＰ、ＨＴＴＰ使って通知する場合である。図５において、異常検知手段１４がネットワークカメラ２の異常、例えばＨＴＴＰによる画像の通信エラーの発生を検知すると（ｓｔｅｐ１）、異常時通信手段１５はＳＭＴＰサーバ７に接続要求を通知し、成功と失敗の回数をカウントして、プロトコルＳＭＴＰでの通信が異常か正常に行えるかを判定する（ｓｔｅｐ２）。
【００４７】
ｓｔｅｐ２において、プロトコルＳＭＴＰでの通信が正常の場合、他のプロトコルで通信の異常か正常かを判断するものがあるかチェックし（ｓｔｅｐ３）、無い場合はそのまま終了する。ｓｔｅｐ２において異常があった場合と、ｓｔｅｐ３でさらに他のプロトコルで異常か正常かを判断する場合は、異常時通信手段１５はＦＴＰサーバ９に接続要求を通知し、成功と失敗の回数をカウントして、プロトコルＦＴＰでの通信が異常か正常に行えるかを判定する（ｓｔｅｐ４）。
【００４８】
ｓｔｅｐ４において、プロトコルＦＴＰでの通信が正常の場合、他のプロトコルで通信の異常か正常かを判断するものがあるかチェックし（ｓｔｅｐ５）、無い場合はそのまま終了する。ｓｔｅｐ４において異常があった場合と、ｓｔｅｐ５で他のプロトコルで異常か正常かを判断する場合は、異常時通信手段１５はＤＤＮＳサーバ４に接続要求を通知し、成功と失敗の回数をカウントして、プロトコルＨＴＴＰでの通信が異常か正常に行えるかを判定する（ｓｔｅｐ６）。
【００４９】
ｓｔｅｐ６において、プロトコルＨＴＴＰでの通信が正常の場合は終了し、異常な場合
は正常なプロトコルがあるか否かをチェックする（ｓｔｅｐ７）。正常なプロトコルが無い場合はそのまま終了し、正常なプロトコルがある場合はその正常なプロトコルのすべて若しくは一部で異常情報を含んだ通信／システム状態情報を該当するプロトコルのサーバに通知して（ｓｔｅｐ８）、終了する。
【００５０】
なお、ｓｔｅｐ２、４、６でプロトコルＳＭＴＰ、ＦＴＰ、ＨＴＴＰでの通信に異常が起こっているか否かを判定したが、その他のプロトコルを判定する場合は、同様な判定を繰返せばよい。
【００５１】
このように本発明の実施例１のネットワークカメラは、異常が発生したとき複数のプロトコルで順次各サーバに接続要求するので、使用可能なプロトコルが判別できる。そして従来は分らなかった常時使用（データ配信）するプロトコルＨＴＴＰの異常発生も確認することができ、すべてのプロトコルが異常でない限りは各サーバに異常を伝えることが可能になり、フェールセーフに適ったネットワークカメラを提供できる。
【００５２】
また、実施例１のネットワークカメラは、異常が発生したとき、まずプロトコルＳＭＴＰでの通信ができるか否かを判別するので、通知を行うべき相手のメールアドレス宛に異常発生を通知することができる。異常が通信上のエラーの場合は、データ配信するＨＴＴＰエラーの可能性が高く、このときＳＭＴＰは正常な可能性が高い上に、電子メールなら相手が着信を頻繁にチェックする可能性も高くなる。
【００５３】
次に、プロトコルＦＴＰでの通信が行えるか否かを判別するが、同様にデータ配信を行うＨＴＴＰでないため、正常な可能性が高い。さらに最後にＤＤＮＳサーバとの間でプロトコルＨＴＴＰでの通信が使えるか否かを判別するが、既に他の正常なプロトコルで通知ができている場合が多く、ＨＴＴＰでの通知に対する期待も軽くなっており、ＤＤＮＳサーバと通信ができればエラーの原因がネットワークカメラ側にはなかったことが分るし、できなければネットワークカメラに原因が在ることが分る。また、これによってＤＤＮＳサーバに異常を伝えておけば、データ配信を受けるためアクセスしたユーザがその後無駄なアクセスをすることがない。
【００５４】
実施例１においては、各サーバに異常情報を含んだ通信／システム状態情報を、異常を伝える情報として通知し、アクセスされたときユーザにこれを通知するので、どのサーバが正常で、そのサーバが異常かを直ちに判別することができる。
【産業上の利用可能性】
【００５５】
本発明は、複数のプロトコルで通信可能なデータ配信装置に適用できる。
【図面の簡単な説明】
【００５６】
【図１】本発明の実施例１におけるデータ配信システムの構成図
【図２】本発明の実施例１におけるデータ配信装置の構成図
【図３】本発明の実施例１における各サーバの構成図
【図４】本発明の実施例１におけるネットワークステータス画面の説明図
【図５】本発明の実施例１における異常処理部の処理のフローチャート
【図６】従来のネットワークステータス画面の説明図
【符号の説明】
【００５７】
１ ＩＰネットワーク
２ ネットワークカメラ
３ ＤＮＳサーバ
４ ＤＤＮＳサーバ
５ ＤＨＣＰサーバ
６ 通信端末
７ ＳＭＴＰサーバ
８ ＰＯＰサーバ
９ ＦＴＰサーバ
１０ タイムサーバ
１１ 制御部
１２ 通信部
１２ａ ＨＴＴＰ通信部
１２ｂ ＳＭＴＰ通信部
１２ｃ ＰＯＰ通信部
１２ｄ ＦＴＰ通信部
１２ｅ ＮＴＰ通信部
１３ 異常処理部
１４ 異常検知手段
１４ａ カウンタ
１５ 異常時通信手段
１６ 記憶部
１６ａ 異常情報用格納部
１６ｂ アドレス情報部
１７ 回線インターフェース
１８ カメラ部
１９ 画像信号圧縮手段
２０ 撮像手段駆動部
２１ 制御部
２２ 通信部
２２ａ サーバ処理部
２３ 異常処理部
２４ 異常情報保存手段
２５ 異常通知手段
２６ 記憶部
２６ａ 異常情報格納部
２７ 回線インターフェース
２８，１０１ プロトコル
２９，１０２ 成功／失敗
３０，１０３ 回数
３１ 判定
【特許請求の範囲】
【請求項１】
ＩＰネットワークに接続されて複数の所定のサーバと通信できると共に、通信端末に対してデータの配信をすることができる通信部と、通信上及び／またはシステム上異常が発生したことを検知する異常検知手段と、前記異常検知手段が異常を検知したとき、前記サーバに対し該サーバが通信に使用するプロトコルでの通信が異常か正常か確認するための通知を順次行うと共に、正常な通信ができるプロトコルのサーバに対して異常を通知する異常時通信手段とを備えたことを特徴とするデータ配信装置。
【請求項２】
前記データの配信に使用するプロトコルが第１のプロトコルの場合、前記異常時通信手段が、前記通信が異常か正常か確認するための通知を前記第１以外の少なくとも第２のプロトコルで通信するサーバに送信する特徴とする請求項１記載のデータ配信装置。
【請求項３】
前記異常時通信手段が、前記通信が異常か正常か確認するための通知を前記第１以外の少なくとも前記第２のプロトコルで通信するサーバに送信した後、前記通信が異常か正常か確認するための通知を前記第１のプロトコルで通信するサーバに送信する特徴とする請求項２記載のデータ配信装置。
【請求項４】
前記データの配信に使用するプロトコルがＨＴＴＰ、前記サーバの１つがＤＤＮＳサーバのとき、前記異常時通信手段が、前記通信が異常か正常か確認するための通知を少なくとも前記ＤＤＮＳサーバに行うと共に、正常な通信ができれば前記ＤＤＮＳサーバに異常を通知することを特徴とする請求項１記載のデータ配信装置。
【請求項５】
画像を撮影するカメラ部と、画像信号を圧縮する圧縮部と、ＩＰネットワークに接続されて複数の所定のサーバと通信できると共に、通信端末に対して前記圧縮部で圧縮されたデータを配信できる通信部を備えた画像配信装置であって、通信上及び／またはシステム上異常が発生したことを検知する異常検知手段と、前記異常検知手段が異常を検知したとき、前記サーバに対し該サーバが通信に使用するプロトコルでの通信が異常か正常か確認するための通知を順次行うと共に、正常な通信ができるプロトコルのサーバに対して異常を通知する異常時通信手段とを備えたことを特徴とする画像配信装置。
【請求項６】
前記データの配信に使用するプロトコルが第１のプロトコルの場合、前記異常時通信手段が、前記通信が異常か正常か確認するための通知を第２のプロトコルで通信するサーバに送信する特徴とする請求項５記載の画像配信装置。
【請求項７】
前記異常時通信手段が、前記通信が異常か正常か確認するための通知を前記第２のプロトコルで通信するサーバに送信した後、前記通信が異常か正常か確認するための通知を前記第１のプロトコルで通信するサーバに送信する特徴とする請求項６記載の画像配信装置。
【請求項８】
請求項６または７の画像配信装置において、前記通信が異常か正常か確認するための通知を第２のプロトコルで通信するサーバに送信するのに代えて、前記通信が異常か正常か確認するための通知を第２のプロトコルで通信するサーバに送信すると共に、さらに第３のプロトコルで通信するサーバに送信する特徴とする画像配信装置。
【請求項９】
前記第１のプロトコルがＨＴＴＰ、前記第２のプロトコルがＳＭＴＰであることを特徴とする請求項６または７記載の画像配信装置。
【請求項１０】
前記第１のプロトコルがＨＴＴＰ、前記第２のプロトコルがＳＭＴＰ、前記第３のプロトコルがＦＴＰであることを特徴とする請求項８記載の画像配信装置。
【請求項１１】
前記データの配信に使用するプロトコルがＨＴＴＰ、前記サーバの１つがＤＤＮＳサーバのとき、前記異常時通信手段が、前記通信が異常か正常か確認するための通知を少なくとも前記ＤＤＮＳサーバに行うと共に、プロトコルが正常であれば前記ＤＤＮＳサーバに異常を通知することを特徴とする請求項６記載の画像配信装置。
【請求項１】
ＩＰネットワークに接続されて複数の所定のサーバと通信できると共に、通信端末に対してデータの配信をすることができる通信部と、通信上及び／またはシステム上異常が発生したことを検知する異常検知手段と、前記異常検知手段が異常を検知したとき、前記サーバに対し該サーバが通信に使用するプロトコルでの通信が異常か正常か確認するための通知を順次行うと共に、正常な通信ができるプロトコルのサーバに対して異常を通知する異常時通信手段とを備えたことを特徴とするデータ配信装置。
【請求項２】
前記データの配信に使用するプロトコルが第１のプロトコルの場合、前記異常時通信手段が、前記通信が異常か正常か確認するための通知を前記第１以外の少なくとも第２のプロトコルで通信するサーバに送信する特徴とする請求項１記載のデータ配信装置。
【請求項３】
前記異常時通信手段が、前記通信が異常か正常か確認するための通知を前記第１以外の少なくとも前記第２のプロトコルで通信するサーバに送信した後、前記通信が異常か正常か確認するための通知を前記第１のプロトコルで通信するサーバに送信する特徴とする請求項２記載のデータ配信装置。
【請求項４】
前記データの配信に使用するプロトコルがＨＴＴＰ、前記サーバの１つがＤＤＮＳサーバのとき、前記異常時通信手段が、前記通信が異常か正常か確認するための通知を少なくとも前記ＤＤＮＳサーバに行うと共に、正常な通信ができれば前記ＤＤＮＳサーバに異常を通知することを特徴とする請求項１記載のデータ配信装置。
【請求項５】
画像を撮影するカメラ部と、画像信号を圧縮する圧縮部と、ＩＰネットワークに接続されて複数の所定のサーバと通信できると共に、通信端末に対して前記圧縮部で圧縮されたデータを配信できる通信部を備えた画像配信装置であって、通信上及び／またはシステム上異常が発生したことを検知する異常検知手段と、前記異常検知手段が異常を検知したとき、前記サーバに対し該サーバが通信に使用するプロトコルでの通信が異常か正常か確認するための通知を順次行うと共に、正常な通信ができるプロトコルのサーバに対して異常を通知する異常時通信手段とを備えたことを特徴とする画像配信装置。
【請求項６】
前記データの配信に使用するプロトコルが第１のプロトコルの場合、前記異常時通信手段が、前記通信が異常か正常か確認するための通知を第２のプロトコルで通信するサーバに送信する特徴とする請求項５記載の画像配信装置。
【請求項７】
前記異常時通信手段が、前記通信が異常か正常か確認するための通知を前記第２のプロトコルで通信するサーバに送信した後、前記通信が異常か正常か確認するための通知を前記第１のプロトコルで通信するサーバに送信する特徴とする請求項６記載の画像配信装置。
【請求項８】
請求項６または７の画像配信装置において、前記通信が異常か正常か確認するための通知を第２のプロトコルで通信するサーバに送信するのに代えて、前記通信が異常か正常か確認するための通知を第２のプロトコルで通信するサーバに送信すると共に、さらに第３のプロトコルで通信するサーバに送信する特徴とする画像配信装置。
【請求項９】
前記第１のプロトコルがＨＴＴＰ、前記第２のプロトコルがＳＭＴＰであることを特徴とする請求項６または７記載の画像配信装置。
【請求項１０】
前記第１のプロトコルがＨＴＴＰ、前記第２のプロトコルがＳＭＴＰ、前記第３のプロトコルがＦＴＰであることを特徴とする請求項８記載の画像配信装置。
【請求項１１】
前記データの配信に使用するプロトコルがＨＴＴＰ、前記サーバの１つがＤＤＮＳサーバのとき、前記異常時通信手段が、前記通信が異常か正常か確認するための通知を少なくとも前記ＤＤＮＳサーバに行うと共に、プロトコルが正常であれば前記ＤＤＮＳサーバに異常を通知することを特徴とする請求項６記載の画像配信装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図２】
【図３】
【図４】
【図５】
【図６】
【公開番号】特開２００７−１４８８５２（Ｐ２００７−１４８８５２Ａ）
【公開日】平成１９年６月１４日（２００７．６．１４）
【国際特許分類】
【出願番号】特願２００５−３４３２７１（Ｐ２００５−３４３２７１）
【出願日】平成１７年１１月２９日（２００５．１１．２９）
【出願人】（０００００５８２１）松下電器産業株式会社 (73,050)
【Ｆターム（参考）】
【公開日】平成１９年６月１４日（２００７．６．１４）
【国際特許分類】
【出願日】平成１７年１１月２９日（２００５．１１．２９）
【出願人】（０００００５８２１）松下電器産業株式会社 (73,050)
【Ｆターム（参考）】
[ Back to top ]