(57)【要約】  【構成】  Ｗｅｂカメラ１２は、ルータ１６がＵＰｎＰに適合するか否かを判別し、判別結果が肯定的であるとき、ルータ１６に向けてポート開放要求を発行する。これにより特定ポートが開放される。次いで、特定ポートの識別子を含む宛先情報のサーバ１４への送信を要求する。宛先情報はルータ１６によってサーバ１４に送信され、サーバ１４は宛先情報に含まれる識別子に基づいてコマンドを特定ポートに送信する。判別結果が否定的であるとき、Ｗｅｂカメラ１２は、情報送信要求を繰り返し発行する。発行の度にルータ１６によって任意のポート（応答待ちポート）の識別子を含む宛先情報がサーバ１４へ送信され、かつ応答待ちポートが一時的に開放される。サーバ１４は、宛先情報に含まれる識別子に基づいてコマンドを応答待ちポートに出力する。  【効果】  ルータ１６のタイプに関係なく任意のタイミングでサーバ１４からコマンドを受け付けることができる。【選択図】  図１
2006086954.tif 000002
【特許請求の範囲】
【請求項１】
ポート開放要求に応答して特定ポートを継続的に開放する第１方式および情報送信要求に応答して情報送信を行いかつ任意のポートを一時的に開放する第２方式のうち少なくとも前記第２方式に適合するルータを通して外部サーバから送信されるコマンドに従う処理を実行するコマンド処理装置において、
前記ルータが前記第１方式に適合するか否かを判別する判別手段、
前記判別手段の判別結果が肯定的であるとき前記ルータに向けて前記ポート開放要求を発行する第１発行手段、
前記ポート開放要求によって開放された前記特定ポートの識別子を含む宛先情報の前記外部サーバへの送信を前記ルータに要求する送信要求手段、および
前記判別手段の判別結果が否定的であるとき前記ルータに向けて前記情報送信要求を繰り返し発行する第２発行手段を備え、
前記第２発行手段によって発行される前記情報送信要求は前記任意のポートの識別子を含む宛先情報の前記外部サーバへの送信要求であることを特徴とする、コマンド処理装置。
【請求項２】
前記第１方式はＵＰｎＰプロトコルに従う方式であり、
前記判別手段は前記ルータが前記ＵＰｎＰプロトコルに対応しているか否かを判別するプロトコル判別手段を含み、
前記第２発行手段は前記プロトコル判別手段の判別結果が否定的であるとき発行処理を行う、請求項１記載のコマンド処理装置。
【請求項３】
前記プロトコル判別手段は前記ＵＰｎＰプロトコルが採用するディスカバリ機能を利用して判別処理を行う、請求項２記載のコマンド処理装置。
【請求項４】
前記判別手段は、前記プロトコル判別手段の判別結果が肯定的であるときグローバルＩＰアドレスの取得を試みる試行手段、および前記試行手段による試行が成功したか否かを判別する成功判別手段をさらに含み、
前記第２発行手段は前記成功判別手段の判別結果が否定的であるとき発行処理を行う、請求項２または３記載のコマンド処理装置。
【請求項５】
繰り返し応答を要求する要求信号の前記外部サーバへの送信を依頼する送信依頼を前記ルータに向けて発行する第３発行手段、
前記第３発行手段によって発行された送信依頼に対する前記外部サーバからの応答信号を前記任意のポートを通して受信する受信手段、および
前記受信手段の受信結果に基づいて前記第２発行手段の発行周期を決定する決定手段をさらに備える、請求項１ないし４のいずれかに記載のコマンド処理装置。
【請求項６】
互いに異なるタイミングでの応答を要求する要求信号の前記外部サーバへの送信を依頼する送信依頼を前記ルータに向けて繰り返し発行する第３発行手段、
前記第３発行手段によって発行された送信依頼に対する前記外部サーバからの応答信号を前記任意のポートを通して受信する受信手段、および
前記受信手段の受信結果に基づいて前記第２発行手段の発行周期を決定する決定手段をさらに備える、請求項１ないし４のいずれかに記載のコマンド処理装置。
【請求項７】
ポート開放要求に応答して特定ポートを継続的に開放する第１方式および情報送信要求に応答して情報送信を行いかつ任意のポートを一時的に開放する第２方式のうち少なくとも前記第２方式に適合するルータを通して外部サーバから送信されるコマンドに従う処理を実行するコマンド処理装置のプロセサによって実行される制御プログラムであって、
前記ルータが前記第１方式に適合するか否かを判別する判別ステップ、
前記判別ステップの判別結果が肯定的であるとき前記ルータに向けて前記ポート開放要求を発行する第１発行ステップ、
前記ポート開放要求によって開放された前記特定ポートの識別子を含む宛先情報の前記外部サーバへの送信を前記ルータに要求する送信要求ステップ、および
前記判別ステップの判別結果が否定的であるとき前記ルータに向けて前記情報送信要求を繰り返し発行する第２発行ステップを備え、
前記第２発行ステップによって発行される前記情報送信要求は前記任意のポートの識別子を含む宛先情報の前記外部サーバへの送信要求であることを特徴とする、制御プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、コマンド処理装置に関し、特にたとえば、外部サーバからルータを通して送信されるコマンドに従う処理を実行する、コマンド処理装置に関する。
【背景技術】
【０００２】
従来この種のコマンド処理装置としては、次の２つが知られている。第１の従来技術は、ルータに向けて特定ポートの開放を要求するポート開放要求を発行し、かつ特定ポートの識別子を含む宛先情報の外部サーバへの送信を要求する送信要求を発行する。すると、ルータによって特定ポートが継続的に開放され、かつ宛先情報が外部サーバに送信される。外部サーバからは、宛先情報に含まれる識別子に基づいて、任意のタイミングでコマンドが特定ポートに送信される。
【０００３】
第２の従来技術は、ルータに向けて、任意のポート（以下「応答待ちポート」と呼ぶ）の識別子を含む宛先情報の外部サーバへの送信を要求する情報送信要求を発行する。すると、ルータによって、宛先情報が外部サーバに送信され、かつ応答待ちポートが一時的に開放される。外部サーバからは、宛先情報に含まれる識別子に基づいて、コマンドが応答待ちポートに送信される。
【０００４】
従来のルータは、非特許文献１に開示されている。
【非特許文献１】エーアイムック  ブロードバンドルーターのすべて〔エーアイ出版，２００２年６月１１日発行〕
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら、第１の従来技術では、ルータがポート開放要求に応答して特定ポートを継続的に開放する方式に対応したタイプでなければ、外部サーバからコマンドを受け付けることができない。一方、第２の従来技術では、応答待ちポートが開放されている期間だけしか、外部サーバからコマンドを受け付けることができない。
【０００６】
それゆえに、この発明の主たる目的は、ルータが採用する方式に関係なく任意のタイミングで外部サーバからコマンドを受け付けることができる、コマンド処理装置を提供することである。
【課題を解決するための手段】
【０００７】
請求項１の発明に従うコマンド処理装置は、ポート開放要求に応答して特定ポートを継続的に開放する第１方式および情報送信要求に応答して情報送信を行いかつ任意のポートを一時的に開放する第２方式のうち少なくとも第２方式に適合するルータを通して外部サーバから送信されるコマンドに従う処理を実行するコマンド処理装置において、ルータが第１方式に適合するか否かを判別する判別手段、判別手段の判別結果が肯定的であるときルータに向けてポート開放要求を発行する第１発行手段、ポート開放要求によって開放された特定ポートの識別子を含む宛先情報の外部サーバへの送信をルータに要求する送信要求手段、および判別手段の判別結果が否定的であるときルータに向けて情報送信要求を繰り返し発行する第２発行手段を備え、第２発行手段によって発行される情報送信要求は任意のポートの識別子を含む宛先情報の外部サーバへの送信要求であることを特徴とする。
【０００８】
ルータは、ポート開放要求に応答して特定ポートを継続的に開放する第１方式、および情報送信要求に応答して情報送信を行いかつ任意のポートを一時的に開放する第２方式のうち少なくとも第２方式を採用する。コマンドは、ルータを通して外部サーバから送信される。
【０００９】
判別手段は、ルータが第１方式に適合するか否かを判別する。判別手段の判別結果が肯定的であるときは、第１発行手段がルータに向けてポート開放要求を発行する。これによって、特定ポートが開放される。送信要求手段は、開放された特定ポートの識別子を含む宛先情報の外部サーバへの送信をルータに要求する。宛先情報は、ルータによって外部サーバに送信される。外部サーバは、宛先情報に含まれる識別子に基づいて、コマンドを特定ポートに送信する。
【００１０】
判別手段の判別結果が否定的であるときは、第２発行手段がルータに向けて情報送信要求を繰り返し発行する。発行される情報送信要求は、任意のポートの識別子を含む宛先情報の外部サーバへの送信要求である。ルータは、情報送信要求が発行される毎に、宛先情報を外部サーバへ送信し、かつ任意のポートを一時的に開放する。外部サーバは、宛先情報に含まれる識別子に基づいて、コマンドを任意のポートに出力する。
【００１１】
請求項２の発明に従うコマンド処理装置は、請求項１に従属し、第１方式はＵＰｎＰ（Universal Plug & Play）プロトコルに従う方式であり、判別手段はルータがＵＰｎＰプロトコルに対応しているか否かを判別するプロトコル判別手段を含み、第２発行手段はプロトコル判別手段の判別結果が否定的であるとき発行処理を行う。
【００１２】
第１方式は、ＵＰｎＰプロトコルに従う。プロトコル判別手段は、ルータがＵＰｎＰプロトコルに対応しているか否かを判別する。第２発行手段の発行処理は、プロトコル判別手段の判別結果が否定的であるとき行われる。
【００１３】
ルータがＵＰｎＰプロトコルに対応していなければ、ルータに向けて情報送信要求が繰り返し発行され、その結果、任意のポートが継続的に開放された状態となる。
【００１４】
請求項３の発明に従うコマンド処理装置は、請求項２に従属し、プロトコル判別手段はＵＰｎＰプロトコルが採用するディスカバリ機能を利用して判別処理を行う。
【００１５】
請求項４の発明に従うコマンド処理装置は、請求項２または３に従属し、判別手段は、プロトコル判別手段の判別結果が肯定的であるときグローバルＩＰアドレスの取得を試みる試行手段、および試行手段による試行が成功したか否かを判別する成功判別手段をさらに含み、第２発行手段は成功判別手段の判別結果が否定的であるとき発行処理を行う。
【００１６】
試行手段は、プロトコル判別手段の判別結果が肯定的であるときグローバルＩＰアドレスの取得を試みる。成功判別手段は、試行手段による試行が成功したか否かを判別する。第２発行手段の発行処理は、成功判別手段の判別結果が否定的であるとき行われる。
【００１７】
ルータがＵＰｎＰプロトコルに対応していても、ルータからグローバルＩＰアドレスを取得することができなければ、ルータに向けて情報送信要求が繰り返し発行され、その結果、任意のポートが継続的に開放された状態となる。
【００１８】
請求項５の発明に従うコマンド処理装置は、請求項１ないし４のいずれかに従属し、繰り返し応答を要求する要求信号の外部サーバへの送信を依頼する送信依頼をルータに向けて発行する第３発行手段、第３発行手段によって発行された送信依頼に対する外部サーバからの応答信号を任意のポートを通して受信する受信手段、および受信手段の受信結果に基づいて第２発行手段の発行周期を決定する決定手段をさらに備える。
【００１９】
第３発行手段は、繰り返し応答を要求する要求信号の外部サーバへの送信を依頼する送信依頼をルータに向けて発行する。かかる送信依頼が発行されると、ルータによって、繰り返し応答を要求する要求信号が外部サーバに送信され、かつ任意のポートが一時的に開放される。外部サーバからは、応答信号が繰り返し返送される。返送された応答信号は、開放された任意のポートを通って受信手段により受信される。
【００２０】
第３発行手段が送信依頼を発行したとき開放された任意のポートは、一定期間が経過すると閉鎖される。任意のポートが閉鎖されると、以降、受信手段は応答信号を受信しなくなるので、受信手段による受信結果に基づいて、送信依頼が発行されたときルータが任意のポートを開放させる期間（ポート開放期間）を知ることができ、ひいては第２発行手段の最適な発行周期を決定することができる。
【００２１】
決定手段は、かかる受信手段の受信結果に基づいて、第２発行手段の発行周期を決定する。こうして決定される周期、つまりポート開放期間を超えない最も長い周期、換言すればポート開放期間に等しいかまたはそれよりもわずかに短い周期で第２発行手段が送信依頼を発行すれば、通信回線への負荷を最小限に抑えながら、任意のポートが継続的に開放された状態を作り出すことができる。
【００２２】
請求項６の発明に従うコマンド処理装置は、請求項１ないし４のいずれかに従属し、互いに異なるタイミングでの応答を要求する要求信号の外部サーバへの送信を依頼する送信依頼をルータに向けて繰り返し発行する第３発行手段、第３発行手段によって発行された送信依頼に対する外部サーバからの応答信号を任意のポートを通して受信する受信手段、および受信手段の受信結果に基づいて第２発行手段の発行周期を決定する決定手段をさらに備える。
【００２３】
第３発行手段は、互いに異なるタイミングでの応答を要求する要求信号の外部サーバへの送信を依頼する送信依頼をルータに向けて繰り返し発行する。第３発行手段が送信依頼を発行する度に、ルータによって、互いに異なるタイミングでの応答を要求する要求信号が外部サーバに送信され、かつ任意のポートが一時的に開放される。外部サーバからは、第３発行手段によって送信依頼が発行される度に、応答信号が互いに異なるタイミングで返送される。
【００２４】
第３発行手段が送信依頼を発行したとき開放された任意のポートは、一定期間が経過すると閉鎖される。互いに異なるタイミングで返送される応答信号のうち、任意のポートの閉鎖よりも遅いタイミングで返送された応答信号は、受信手段によって受信されない。このため、受信手段による受信結果に基づいて、送信依頼が発行されたときルータが任意のポートを開放させる期間（ポート開放期間）を知ることができ、ひいては第２発行手段の最適な発行周期を決定することができる。
【００２５】
決定手段は、かかる受信手段の受信結果に基づいて、第２発行手段の発行周期を決定する。こうして決定される周期、つまりポート開放期間を超えない最も長い周期、換言すればポート開放期間に等しいかまたはそれよりもわずかに短い周期で第２発行手段が送信依頼を発行すれば、通信回線への負荷を最小限に抑えながら、任意のポートが継続的に開放された状態を作り出すことができる。
【００２６】
請求項７の発明に従う制御プログラムは、ポート開放要求に応答して特定ポートを継続的に開放する第１方式および情報送信要求に応答して情報送信を行いかつ任意のポートを一時的に開放する第２方式のうち少なくとも第２方式に適合するルータを通して外部サーバから送信されるコマンドに従う処理を実行するコマンド処理装置のプロセサによって実行される制御プログラムであって、ルータが第１方式に適合するか否かを判別する判別ステップ、判別ステップの判別結果が肯定的であるときルータに向けてポート開放要求を発行する第１発行ステップ、ポート開放要求によって開放された特定ポートの識別子を含む宛先情報の外部サーバへの送信をルータに要求する送信要求ステップ、および判別ステップの判別結果が否定的であるときルータに向けて情報送信要求を繰り返し発行する第２発行ステップを備え、第２発行ステップによって発行される情報送信要求は任意のポートの識別子を含む宛先情報の外部サーバへの送信要求であることを特徴とする。
【発明の効果】
【００２７】
この発明によれば、ルータが第１方式を採用するときはルータによって特定ポートが継続的に開放されると共に特定ポートの識別子を含む宛先情報が外部サーバに通知され、ルータが第２方式を採用するときはルータによって任意のポート（応答待ちポート）が継続的に開放されると共に応答待ちポートの識別子を含む宛先情報が外部サーバに通知されるので、ルータが採用する方式に関係なく任意のタイミングで外部サーバからコマンドを受け付けることができる。
【００２８】
この発明の上述の目的，その他の目的，特徴および利点は、図面を参照して行う以下の実施例の詳細な説明から一層明らかとなろう。
【発明を実施するための最良の形態】
【００２９】
図１を参照して、この実施例の監視カメラシステム１０は、Ｗｅｂカメラ１２を含む。Ｗｅｂカメラ１２は、ルータ１６およびＤＳＬモデム１８を介してインターネット２０に接続される。インターネット２０にはサーバ１４が接続されており、Ｗｅｂカメラ１２は、このサーバ１４を通して、インターネット２０に接続された端末たとえば携帯電話２２からの操作を受け付ける。具体的な操作としては、たとえば撮像ユニット２４およびカメラ処理回路２６を通して感度，ズーム倍率などを調節したり、図示しない駆動ユニットを介してＷｅｂカメラ１２の向きを制御したりする操作が挙げられる。
【００３０】
なお、ルータ１６には、Ｗｅｂカメラ１２だけでなく、必要に応じて他の情報家電，ＰＣなどが接続される。こうしてＷｅｂカメラ１２，他の情報家電，ＰＣなどがルータ１６を介して互いに接続された結果、１つのＬＡＮが構成される。ルータ１６は、ただ１つのグローバルＩＰアドレスを持ち、ＬＡＮを構成する１つ１つの機器にはプライベートＩＰアドレスを割り当てる。そして、ＬＡＮ側の機器がインターネット２０側の機器と通信するとき、ＬＡＮ側で用いられるプライベートＩＰアドレスおよび送信元ポート番号と、インターネット側で用いられるグローバルＩＰアドレスおよびレスポンス待ちポート番号とを互いに変換するアドレス／ポート変換処理を実行する。
【００３１】
ルータ１６としては、ＵＰｎＰ（Universal Plug & Play）プロトコルに対応したタイプと非対応タイプとの２種類が用いられる。Ｗｅｂカメラ１２は、サーバ１４と協働して、まず自分に接続されたルータ１６のタイプに適した制御方式を選択し、そして選択された制御方式に従って携帯電話２２からの操作を受け付ける。なお、ルータ１６がＵＰｎＰ対応タイプか否かは、ＵＰｎＰが採用するディスカバリ機能たとえばＳＳＤＰ（Simple Service Discovery Protocol）を利用することにより判別できる。
【００３２】
制御方式の選択を含む初期設定は、具体的には、次のようにして行われる。すなわち、Ｗｅｂカメラ１２は、電源が投入されたとき、ルータ１６がＵＰｎＰ対応型か否かを判別するために、まずルータ１６にＳＳＤＰに基づくＭ−ＳＥＡＲＣＨパケットを送信する。図２（Ａ）には、ルータ１６がＵＰｎＰ対応型である場合の初期設定の手順が示され、図３（Ａ）には、ルータ１６がＵＰｎＰ非対応型である場合の初期設定の手順が示されている。
【００３３】
まず図２（Ａ）を参照して、ルータ１６がＵＰｎＰ対応型の場合、ルータ１６は、Ｗｅｂカメラ１２（クライアント）からのＭ−ＳＥＡＲＣＨパケットに応じ、Ｗｅｂカメラ１２に２００ＯＫパケットを返送する。２００ＯＫパケットを受信したＷｅｂカメラ１２は次に、ルータ１６にグローバルＩＰアドレスを要求する。ルータ１６は、Ｗｅｂカメラ１２の要求に応じ、Ｗｅｂカメラ１２にグローバルＩＰアドレスを通知する。
【００３４】
こうしてグローバルＩＰアドレスを取得したＷｅｂカメラ１２は次に、特定ポートを開放するようルータ１６に要求する。ルータ１６は、Ｗｅｂカメラ１２の要求に応じ、特定ポートを開放する。この後、特定ポート宛に送られてきたパケットは、ルータ１６により全てＷｅｂカメラ１２に転送される。
【００３５】
続いてＷｅｂカメラ１２は、サーバ１４に向けてＵＤＰ（User Datagram Protocol）に従うポート通知パケットを送信する。ルータ１６がＵＰｎＰ対応型であるときＷｅｂカメラ１２（クライアント）がルータ１６に送信するポート通知パケットの構成が図２（Ｂ）に示されている。図２（Ｂ）を参照して、ポート通知パケットのデータ領域には、ルータ１６によって開放された特定ポートのポート番号が記述される。なお、データ領域には、認証のための機器ＩＤなどが必要に応じてさらに記述される。
【００３６】
ヘッダ領域には、他のパケットと同じように、プライベートＩＰアドレスおよび送信元ポート番号が記述される。ヘッダ領域内のプライベートＩＰアドレスおよび送信元ポート番号は、ルータ１６を通過するときグローバルＩＰアドレスおよびレスポンス待ちポート番号に変換される。
【００３７】
サーバ１４は、Ｗｅｂカメラ１２からのポート通知パケットを受信し、受信されたポート通知パケットのデータ領域から特定ポート番号を抽出し、かつ同じポート通知パケットのヘッダ領域からグローバルＩＰアドレスを抽出する。そして、抽出されたアドレスおよび抽出されたポート番号によって特定される宛先にレスポンスパケットを送信する一方、抽出されたアドレスおよび抽出されたポート番号をＲＡＭ３６に保持する。送信されたレスポンスパケットは、ルータ１６によってＷｅｂカメラ１２へと転送される。ＲＡＭ３６に保持されたアドレスおよびポート番号は、後にＷｅｂカメラ１２へコマンドを送信するとき参照される。なお、ＲＡＭ３６内のデータたとえばアドレス，ポート番号，コマンド等は、ＨＤＤ４４によってバックアップされる（以下同様）。
【００３８】
次に図３（Ａ）を参照して、ルータ１６がＵＰｎＰ非対応型の場合、ルータ１６は、Ｗｅｂカメラ１２からＭ−ＳＥＡＲＣＨパケットが送られてきても何も応答しない。Ｗｅｂカメラ１２は、Ｍ−ＳＥＡＲＣＨパケットを送信しても２００ＯＫパケットが返送されてこないため、ルータ１６がＵＰｎＰ非対応型であると判断し、最適送信間隔（Ｔ）を求めるための処理に移る。
【００３９】
最適送信間隔算出処理では、まずクライアントつまりＷｅｂカメラ１２がＵＤＰに従うテスト開始パケットをサーバ１４に送信する。
【００４０】
送信されたテスト開始パケットは、ルータ１６によってアドレス／ポート変換処理を施され、アドレス／ポート変換処理を施されたパケットがサーバ１４によって受信される。このときルータ１６では、レスポンス待ちポートが開放され、また、送信元アドレスつまりＷｅｂカメラ１２のプライベートＩＰアドレスと、変換前後のポート番号つまり送信元ポート番号およびレスポンス待ちポート番号とがテーブルに記録される。テスト開始パケットに応じて開放されたレスポンス待ちポートは、所定期間たとえば１５秒が経過すると閉じられる。
【００４１】
サーバ１４は、テスト開始パケットを受信してから所定時間たとえば２秒後にレスポンスパケットをクライアントに送信する。レスポンスパケットには、テスト開始パケットの受信からの経過時間を示す時間情報つまり“２秒”が記述される。
【００４２】
２秒後に送信されたレスポンスパケットは、ルータ１６において、上記テーブルに基づくアドレス／ポート変換処理を施され、アドレス／ポート変換処理を施されたパケットがＷｅｂカメラ１２によって受信される。Ｗｅｂカメラ１２は、受信されたレスポンスパケットから時間情報“２秒”を抽出し、抽出された時間情報“２秒”をレジスタ“Ｔ”に記録する。
【００４３】
サーバ１４はさらに、テスト開始パケットを受信してから４秒後，６秒後，…にもレスポンスパケットをクライアントに送信する。レスポンスパケットには、経過時間“４秒”，“６秒”，…が記述される。
【００４４】
４秒後，６秒後，…に送信されたレスポンスパケットもまた、ルータ１６において同様のアドレス／ポート変換処理を施され、変換処理を施されたパケットがＷｅｂカメラ１２によって受信される。Ｗｅｂカメラ１２は、受信されたレスポンスパケットから時間情報“４秒”，“６秒”…を抽出し、抽出された時間情報“４秒”，“６秒”…をレジスタ“Ｔ”に前の値を上書きしながら記録する。従って、レジスタ“Ｔ”には常に、直近に受信されたレスポンパケットから抽出された時間情報が保持されることとなる。
【００４５】
そして、ｔ秒後に送信されたレスポンスパケットがＷｅｂカメラ１２によって受信され、この直後にレスポンス待ちポートが閉じられたとする。以降のレスポンスパケットつまり（ｔ+２）秒後，（ｔ+４）秒後，…に送信されたレスポンスパケットは、いずれもルータ１６において破棄され、Ｗｅｂカメラ１２には到達しない。
【００４６】
Ｗｅｂカメラ１２は、前回の受信から５秒経過しても次のレスポンスパケットが受信されないので、テスト終了パケットを送信する。サーバ１４は、テスト終了パケットを受け、レスポンスパケットの送信を終了する。この結果、Ｗｅｂカメラ１２のレジスタ“Ｔ”には“ｔ秒”が残され、従って“ｔ秒”が最適送信間隔Ｔとなる。
【００４７】
このような初期設定が完了した後、Ｗｅｂカメラ１２は、サーバ１４を通して、端末つまり携帯電話２２からのコマンドを受け付け、かつコマンドの実行結果を携帯電話２２に返す。図２（Ｃ）には、ルータ１６がＵＰｎＰ対応型である場合のコマンドおよび実行結果の転送手順が示され、図３（Ｂ）には、ルータ１６がＵＰｎＰ非対応型である場合のコマンドおよび実行結果の転送手順が示されている。
【００４８】
まず図２（Ｃ）を参照して、ＵＰｎＰ対応型であるルータ１６では、先の初期設定によって特定ポートが開放されている。携帯電話２２から送信されたコマンドは、サーバ１４によって受信される。サーバ１４は、受信されたコマンドをＲＡＭ３６に保持する一方、“コマンド有り”通知パケットをＲＡＭ３６に保持されたアドレスおよびポート番号によって特定される宛先に送信する。
【００４９】
サーバ１４から送信された“コマンド有り”通知パケットは、ルータ１６によって受信される。ルータ１６は、受信された“コマンド有り”通知パケットをＷｅｂカメラ１２に転送する。
【００５０】
Ｗｅｂカメラ１２は、ルータ１６によって転送された“コマンド有り”通知パケットを受信し、ＴＣＰ（Transmission Control Protocol）に従うコマンド要求パケットを送信する。送信されたコマンド要求パケットは、サーバ１４によって受信され、応じてサーバ１４は、ＲＡＭ３６に保持されたコマンドをクライアント宛に送信する。送信されたコマンドは、ルータ１６によって所定のポートで受信され、ルータ１６は、受信されたコマンドをＷｅｂカメラ１２に転送する。
【００５１】
Ｗｅｂカメラ１２は、ルータ１６によって転送されたコマンドを受信し、受信されたコマンドを実行し、そして実行結果をＴＣＰに従って送信する。送信された実行結果は、サーバ１４によって受信され、サーバ１４は、受信された実行結果を携帯電話２２に転送する。転送された実行結果は、携帯電話２２によって受信され、携帯電話２２は、受信された実行結果をＬＣＤモニタ（図示せず）に表示する。
【００５２】
次に図３（Ｂ）を参照して、ルータ１６がＵＰｎＰ非対応型であるため、クライアントつまりＷｅｂカメラ１２は、初期設定で算出された最適送信間隔（Ｔ）で周期的にポート通知パケットを送信する。この結果、ルータ１６では、レスポンス待ちポートが常時開放された状態となる。
【００５３】
ルータ１６がＵＰｎＰ非対応型であるときＷｅｂカメラ１２（クライアント）がルータ１６に送信するポート通知パケットの構成が図３（Ｃ）に示されている。図３（Ｃ）を参照して、ポート通知パケットのデータ領域には、無意のポート番号“０”が記述され、ヘッダ領域には、プライベートＩＰアドレスおよび送信元ポート番号が記述される。ヘッダ領域内のプライベートＩＰアドレスおよび送信元ポート番号は、ルータ１６を通過するときグローバルＩＰアドレスおよびレスポンス待ちポート番号に変換される。
【００５４】
サーバ１４は、Ｗｅｂカメラ１２からのポート通知パケットを受信し、受信されたポート通知パケットのヘッダ領域からグローバルＩＰアドレスおよびレスポンス待ちポート番号を抽出する。そして、抽出されたアドレスおよびポート番号をＲＡＭ３６に保持する。
【００５５】
携帯電話２２から送信されたコマンドは、サーバ１４によって受信される。サーバ１４は、受信されたコマンドをＲＡＭ３６に保持する一方、ＵＤＰに従う“コマンド有り”通知パケットをＲＡＭ３６に保持されたアドレスおよびポート番号によって特定される宛先に送信する。サーバ１４から送信された“コマンド有り”通知パケットは、ルータ１６によってレスポンス待ちポートで受信され、ルータ１６は、受信された“コマンド有り”通知パケットをＷｅｂカメラ１２に転送する。
【００５６】
Ｗｅｂカメラ１２は、ルータ１６によって転送された“コマンド有り”通知パケットを受信し、ＴＣＰに従うコマンド要求パケットを送信する。送信されたコマンド要求パケットは、サーバ１４によって所定のポートで受信され、サーバ１４は、ＲＡＭ３６に保持されたコマンドをＴＣＰに従ってクライアント宛に送信する。送信されたコマンドは、ルータ１６によって所定のポートで受信され、ルータ１６は、受信されたコマンドをＷｅｂカメラ１２に転送する。
【００５７】
Ｗｅｂカメラ１２は、ルータ１６によって転送されたコマンドを受信し、受信されたコマンドを実行し、そして実行結果をＴＣＰに従って送信する。送信された実行結果は、サーバ１４によって受信され、サーバ１４は、受信された実行結果を携帯電話２２に転送する。転送された実行結果は、携帯電話２２によって受信され、携帯電話２２は、受信された実行結果をＬＣＤモニタに表示する。
【００５８】
クライアントつまりＷｅｂカメラ１２のＣＰＵ２８は、電源等投入時、図４に示されたタイプ判別タスクを実行する。そしてタイプ判別タスク終了後、μＩＴＲＯＮのようなマルチタスクＯＳの制御下で、図５および図６に示されたメインタスクと、図７に示されたポート通知パケット送信タスクと、図８に示されたコマンド実行タスクとを並列的に処理する。なお、これらのフロー図に対応する制御プログラムは、フラッシュメモリ３０に格納される。
【００５９】
図４を参照して、タイプ判別タスクでは、まずステップＳ１でルータ１６がＵＰｎＰ対応型か否かを判別し、判別結果が否定的であればステップＳ３に移る。ステップＳ３では、制御方式を“タイプ２”に設定する。その後、本タスクは終了される。
【００６０】
ここで、ステップＳ１の判別は、たとえば次のようにして行うことができる。ルータ１６にＳＳＤＰに基づくＭ−ＳＥＡＲＣＨパケットを送信し、ルータ１６から２００ＯＫパケットが返送されてくればＵＰｎＰ対応型であると判別する。一方、２００ＯＫパケットが返送されてこなければ、ＵＰｎＰ非対応型であると判別する。
【００６１】
ステップＳ１の判別結果が肯定的であればステップＳ５に移り、ネットワークコントローラ３４を介してルータ１６にインターネット２０側へアクセスするためのＩＰアドレス（ＷＡＮ側アドレス）を要求する。ステップＳ７では、グローバルＩＰアドレスが受信されたか否かを判別する。判別結果が否定的つまりプライベートＩＰアドレスが受信されれば、ステップＳ９で制御方式を“タイプ２”に設定する。その後、本タスクは終了される。
【００６２】
グローバルＩＰアドレスが受信されると、ステップＳ７からステップＳ１１に移り、特定ポートの開放をルータ１６に要求する。次のステップＳ１３では、ＵＤＰに従うポート通知パケットをサーバ１４に送信する。ポート通知パケットには、ルータ１６に開放を要求した特定ポートのポート番号がデータ領域に記述される（図２（Ｂ）参照）。その後ステップＳ１５およびＳ１７のループに入る。
【００６３】
ステップＳ１５ではレスポンスパケットが受信されたか否かを判別し、ステップＳ１７では所定時間たとえば５秒が経過したか否かを判別する。ポート通知パケットの送信から５秒以内にレスポンスパケットが受信されれば、ステップＳ１５でＹＥＳと判別され、ステップ１９に移る。ステップＳ１９では、制御方式を“タイプ１”に設定する。そして、本タスクは終了される。
【００６４】
５秒が経過してもレスポンスパケットが受信されなければ、ステップＳ１７でＹＥＳと判別され、ステップＳ２１に移る。ステップＳ２１では、先に開放された特定ポートの閉鎖をルータ１６に要求する。ステップＳ２３では、制御方式を“タイプ２”に設定する。そして、本タスクは終了される。
【００６５】
このように、ルータ１６がＵＰｎＰに対応していなければ、制御方式としてタイプ２が直ちに選択される。一方、ルータ１６がＵＰｎＰに対応している場合には、ルータ１６からグローバルＩＰアドレスを取得でき、かつポート通知パケットを送信してから所定時間内にレスポンスパケットを受信できた場合に限り、制御方式として“タイプ１”が選択される。ルータ１６からグローバルＩＰアドレスを取得できなければ、制御方式として“タイプ２”が選択される。また、たとえグローバルＩＰアドレスを取得できても、所定時間内にレスポンスパケットを受信できなければ、外部サーバ１４が通知されたアドレスおよびポート番号宛に応答パケットを返送していないか、もしくはルータ１６において特定ポートが開放されていないと判断され、制御方式は“タイプ２”となる。
【００６６】
図５を参照して、メインタスクでは、まずステップＳ３１で初期処理を行う。初期処理では、ポート通知パケットを送信する際の最適送信間隔（Ｔ）が算出される。なお、最適送信間隔（Ｔ）算出処理の詳細については後述する。
【００６７】
次のステップＳ３３では、遠隔操作モードに入った否かを判別する。遠隔操作モードに入ると、ステップＳ３３からステップＳ３５に移って、制御方式が“タイプ２”に設定されているか否かを判別する。この判別結果が肯定的であれば、ステップＳ３７でポート通知パケット送信タスク（後述）を起動し、そしてステップ３９に移る。ステップＳ３５の判別結果が否定的つまり制御方式が“タイプ１”に設定されていれば、直ちにステップＳ３９に移る。
【００６８】
ステップＳ３９では、コマンド実行タスク（後述）を起動する。次のステップＳ４１では、遠隔操作モードを脱した否かを判別する。遠隔操作モードを脱すると、ステップＳ４１からステップＳ４３に移り、ポート通知パケット送信タスクを終了する。さらにステップＳ４５でコマンド実行タスクを終了し、その後ステップＳ３３に戻る。
【００６９】
上記ステップＳ３１の最適間隔（Ｔ）算出処理は、図６のサブルーチンに従って実行される。図６を参照して、ステップＳ５１では、ＵＤＰに従うテスト開始パケットをサーバ１４宛に送信する。ステップＳ５３では、タイマをリセットおよびスタートし、その後、ステップＳ５５およびＳ５７のループに入る。ステップＳ５５では、レスポンスパケットが受信されたか否かを判別し、ステップＳ５７では、所定時間たとえば５秒が経過したか否かを判別する。
【００７０】
５秒以内にレスポンスパケットが受信されれば、ステップＳ５５でＹＥＳと判別され、ステップＳ５９に移る。ステップＳ５９では、受信されたレスポンスパケットから時間情報（ｔ）を抽出し、ステップＳ６１では、抽出された時間情報（ｔ）をレジスタ“Ｔ”にセットする。その後、ステップＳ５３に戻る。
【００７１】
５秒が経過してもレスポンスパケットが受信されなければ、ステップＳ５７でＹＥＳと判別され、ステップＳ６３に移る。ステップＳ６３では、ＵＤＰに従うテスト終了パケットをサーバ１４宛に送信し、その後、上位層のルーチンに復帰する。
【００７２】
図７を参照して、ポート通知パケット送信タスクでは、まずステップＳ７１でポート通知パケット（図３（Ｃ）参照）をサーバ１４宛に送信し、ステップＳ７３でタイマをリセットおよびスタートする。ステップＳ７５では、最適送信間隔（Ｔ）が経過したか否かを判別し、判別結果が肯定的になると、ステップＳ７１に戻る。
【００７３】
図８を参照して、コマンド実行タスクでは、まずステップＳ８１で、“コマンド有り”通知パケットが受信されたか否かを判別する。ステップＳ８３では、ＴＣＰに従うコマンド要求パケットをサーバ１４宛に送信する。ステップＳ８５では、コマンドが受信されたか否かを判別し、コマンドが受信されるとステップＳ８７に移る。ステップＳ８７では、受信されたコマンドを実行し、ステップ８９では、実行結果をＴＣＰに従ってサーバ１４宛に送信する。その後、ステップＳ８１に戻る。
【００７４】
サーバ１４のＣＰＵ４２は、μＩＴＲＯＮのようなマルチタスクＯＳの制御下で、図９に示されたＵＤＰパケット処理タスクと、図１０に示されたメインタスクとを並列的に処理する。なお、これらのフロー図に対応する制御プログラムは、ＲＯＭ３８に格納される。
【００７５】
図９を参照して、ＵＤＰパケット処理タスクでは、まずステップＳ１０１およびＳ１０３のループに入る。ステップＳ１０１では、ポート通知パケットが受信されたか否かを判別し、ステップＳ１０３では、テスト開始パケットが受信されたか否かを判別する。ポート通知パケットが受信されると、ステップＳ１０１でＹＥＳと判別し、ステップＳ１０５に移る。ステップＳ１０５では、受信されたポート通知パケットのデータ領域に有意の情報が記述されているか否かを判別する。ステップＳ１０５の判別結果が肯定的であれば、ステップＳ１０７に移る。たとえば、図２（Ｂ）に示すポート通知パケットが受信されたとき、ステップＳ１０５の判別結果は肯定的となる。
【００７６】
ステップＳ１０７では、受信されたポート通知パケットのデータ領域からポート番号を抽出し、かつ同じポート通知パケットのヘッダ領域からアドレスを抽出する。そして、抽出されたポート番号つまり特定ポートの番号と、抽出されたアドレスつまりグローバルＩＰアドレスとをＲＡＭ３６に保持する。次のステップＳ１０９では、レスポンスパケットをＲＡＭ３６に保持されたアドレスおよびポート番号によって特定される宛先に送信し、その後ステップＳ１０１およびＳ１０３のループに戻る。
【００７７】
ステップＳ１０５の判別結果が否定的であれば、ステップＳ１１１に移る。たとえば、図３（Ｃ）に示すポート通知パケットが受信されたとき、ステップＳ１０５の判別結果は否定的となる。ステップＳ１１１では、受信されたポート通知パケットのヘッダ領域からアドレスおよびポート番号を抽出する。そして、抽出されたポート番号つまりレスポンス待ちポートの番号と、抽出されたアドレスつまりグローバルＩＰアドレスとをＲＡＭ３６に保持する。その後、ステップＳ１０１およびＳ１０３のループに戻る。
【００７８】
テスト開始パケットが受信されると、ステップＳ１０３でＹＥＳと判別し、ステップＳ１１３に移る。ステップＳ１１３では、時間情報（ｔ）を初期化する。具体的には、変数ｔに“０”をセットする。そして、ステップＳ１１５でタイマをリセットおよびスタートし、ステップＳ１１７およびＳ１１９のループに入る。ステップＳ１１７では、テスト開始パケット（前回のテストパケット）の受信から一定時間たとえば２秒が経過したか否かをタイマによって判別し、ステップＳ１１９では、テスト終了パケットが受信されたか否かを判別する。
【００７９】
テスト開始パケット（前回のテストパケット）の受信から２秒が経過すると、まずステップＳ１２１で変数ｔに“２”を加算し、次にステップＳ１２３でレスポンスパケットに変数ｔの値を埋め込み、そしてステップＳ１２５でレスポンスパケットをＵＤＰに従ってクライアント宛に送信する。その後、ステップＳ１１５に戻る。
【００８０】
テスト終了パケットが受信されると、ステップＳ１０１およびＳ１０３のループに戻る。
【００８１】
図１０を参照して、メインタスクでは、まずステップＳ１３１で、端末つまり携帯電話２２からのコマンドが受信されたか否かを判別する。コマンドが受信されるとステップＳ１３３に移って、ＵＤＰに従う“コマンド有り”通知パケットをＲＡＭ３６に保持されたアドレスおよびポート番号によって特定される宛先に送信する。ここでＲＡＭ３６に保持されているポート番号は、特定ポートおよびレスポンス待ちポートのいずれかの番号である。
【００８２】
次のステップＳ１３５では、コマンド要求パケットが受信されたか否かを判別し、コマンド要求パケットが受信されるとステップＳ１３７に移って、先に受信されＲＡＭ３６に保持されたコマンドを、同じくＲＡＭ３６に保持されたアドレスおよびポート番号によって特定される宛先に送信する。その次のステップＳ１３９では、実行結果が受信されたか否かを判別し、実行結果が受信されるとステップＳ１４１に移って、受信された実行結果を携帯電話２２宛に転送する。その後、ステップＳ１３１に戻る。
【００８３】
以上から明らかなように、この実施例では、ルータ１６として、ＵＰｎＰプロトコルに対応したタイプおよび非対応タイプのどちらか一方が用いられる。コマンドは、かかるルータ１６を通して外部サーバ１４から送信される。
【００８４】
ルータ１６がＵＰｎＰ対応タイプのときは、Ｗｅｂカメラ１２は、ルータ１６に向けてポート開放要求を発行する。これによって、特定ポートが開放される。次にＷｅｂカメラ１２は、開放された特定ポートの識別子を含む宛先情報の外部サーバ１４への送信をルータ１６に要求する。宛先情報（図２（Ｂ）参照）は、ルータ１６によって外部サーバ１４に送信される。外部サーバ１４は、宛先情報に含まれる識別子に基づいて、コマンドを特定ポートに送信する。
【００８５】
ルータ１６がＵＰｎＰ非対応タイプのときは、Ｗｅｂカメラ１２は、ルータ１６に向けて情報送信要求を繰り返し発行する。発行される情報送信要求は、任意のポートの識別子を含む宛先情報の外部サーバ１４への送信要求である。ルータ１６は、情報送信要求が発行される毎に、宛先情報（図３（Ｃ）参照）を外部サーバ１４へ送信し、かつ任意のポート（レスポンス待ちポート）を一時的に開放する。外部サーバ１４は、宛先情報に含まれる識別子に基づいて、コマンドをレスポンス待ちポートに出力する。
【００８６】
このように、Ｗｅｂカメラ１２は、ルータ１６がＵＰｎＰ対応タイプのときは、特定ポートの開放と、開放された特定ポートの識別子を含む宛先情報のサーバ１４への送信とをルータに要求する。一方、ルータ１６がＵＰｎＰ非対応タイプのときは、ルータ１６に向けて情報送信要求を繰り返し発行することによって、レスポンス待ちポートが継続的に開放された状態を作り出し、かつ開放されたレスポンス待ちポートの識別子を含む宛先情報をサーバ１４に通知する。このため、ルータ１６のタイプに関係なく、サーバ１４から任意のタイミングでコマンドを受け付けることができる。
【００８７】
加えて、Ｗｅｂカメラ１２は、ルータ１６がＵＰｎＰ非対応タイプのとき、ルータ１６に向けて、繰り返し返送を要求するテストパケットのサーバ１４への送信依頼を発行する。応じてルータ１６は、サーバ１４にテストパケットを送信し、かつレスポンス待ちポートを一時的に開放する。サーバ１４は、テストパケットに応答してレスポンスパケットを繰り返し返送する。その際サーバ１４は、返送するレスポンスパケットにテストパケットの受信から返送までの待ち時間を示す時間情報を添付する。
【００８８】
Ｗｅｂカメラ１２は、外部サーバ１４から繰り返し返送されるレスポンスパケットを開放されたレスポンス待ちポートを通して受信する。レスポンス待ちポートが閉鎖されると、レスポンスパケットを受信することができなくなる。そこで、最後に受信されたレスポンスパケットに添付の時間情報の示す時間を送信要求の発行周期（＝最適送信周期Ｔ）とする。
【００８９】
Ｗｅｂカメラ１２は、こうして決定される周期、つまりルータ１６が送信依頼に応じてレスポンス待ちポートを開放させる期間（ポート開放期間）を超えない最も長い周期、換言すればポート開放期間に等しいかまたはそれよりもわずかに短い周期で、ルータ１６に向けて送信依頼を繰り返し発行する。これにより、インターネット２０やＬＡＮなどの通信回線への負荷を最小限に抑えながら、レスポンス待ちポートが継続的に開放された状態を作り出すことができる。
【００９０】
なお、この実施例では、サーバ１４側がレスポンスパケットに時間情報を添付し、Ｗｅｂカメラ１２は、最後に受信されたレスポンスパケットに添付の時間情報が示す時間を情報送信要求の発行周期としたが、代わりに、Ｗｅｂカメラ１２自身がテストパケットを送信してからレスポンスパケットを受信するまでの経過時間を計測し、最後に受信されたレスポンスパケットに対応する計測結果を情報送信要求の発行周期としてもよい。
【００９１】
次に、他の実施例を説明する。この実施例もまた、監視カメラシステムに関する。この実施例の監視カメラシステムは、前述の実施例の監視カメラシステムと同様に構成される。この実施例の監視カメラシステムの動作は、最適送信間隔（Ｔ）を算出する処理を除き、前述の実施例のそれと同様である。よって、この実施例にも、図１，図２（Ａ），図２（Ｂ），図３（Ｂ），図４，図５，図７，図８および図１０を援用し、重複する説明を省略する。
【００９２】
以下、最適送信間隔算出処理について、図１１〜図１３により詳細に説明する。なお、図１１は図３（Ａ）と対応し、図１２は図６と対応し、図１３は図９と対応する。
【００９３】
まず図１１を参照して、ルータ１６がＵＰｎＰ非対応型の場合、ルータ１６は、Ｗｅｂカメラ１２からのＭ−ＳＥＡＲＣＨパケットに応答しない。Ｍ−ＳＥＡＲＣＨパケットを送信しても２００ＯＫパケットが返送されてこないため、Ｗｅｂカメラ１２は、制御方式としてタイプ２を選択し、最適送信間隔（Ｔ）を求めるための処理に移る。
【００９４】
最適送信間隔算出処理では、まずクライアントつまりＷｅｂカメラ１２がＵＤＰに従うテスト開始パケットをサーバ１４に送信する。送信されたテスト開始パケットは、ルータ１６によってアドレス／ポート変換処理を施され、アドレス／ポート変換処理を施されたパケットがサーバ１４によって受信される。このときルータ１６では、レスポンス待ちポートが開放され、また、送信元アドレスつまりＷｅｂカメラ１２のプライベートＩＰアドレスと、変換前後のポート番号つまり送信元ポート番号およびレスポンス待ちポート番号とがテーブルに記録される。テスト開始パケットに応じて開放されたレスポンス待ちポートは、所定期間たとえば１５秒が経過すると閉じられる。
【００９５】
サーバ１４は、テスト開始パケットを受信してからたとえば６０秒後にＵＤＰに従うレスポンスパケットをクライアントに送信する。レスポンスパケットには、テスト開始パケットの受信からの経過時間を示す時間情報つまり“６０秒”が記述される。
【００９６】
このとき既にレスポンス待ちポートは閉じられており、このため、６０秒後に送信されたレスポンスパケットは、ルータ１６において破棄され、Ｗｅｂカメラ１２は、レスポンスパケットを受信することができない。
【００９７】
そこでＷｅｂカメラ１２は、テスト開始パケットの送信から所定時間たとえば６５秒が経過したとき、最初のテストパケットをサーバ１４に送信する。送信されたテストパケットは、ルータ１６によってアドレス／ポート変換処理を施され、アドレス／ポート変換処理を施されたパケットがサーバ１４によって受信される。このときルータ１６では、レスポンス待ちポートが再び開放され、また、プライベートＩＰアドレスと送信元ポート番号およびレスポンス待ちポート番号とがテーブルに記録される。テストパケットに応じて開放されたレスポンス待ちポートは、たとえば１５秒が経過すると閉じられる。
【００９８】
サーバ１４は、テストパケットを受信してから５０秒後にレスポンスパケットをクライアントに送信する。レスポンスパケットには、テスト開始パケットの受信からの経過時間を示す時間情報つまり“５０秒”が記述される。
【００９９】
このとき既にレスポンス待ちポートは閉じられており、このため、５０秒後に送信されたレスポンスパケットは、ルータ１６において破棄され、Ｗｅｂカメラ１２は、レスポンスパケットを受信することができない。
【０１００】
そこでＷｅｂカメラ１２は、前回のテストパケットの送信から６５秒が経過したとき、次のテストパケットをサーバ１４に送信する。送信されたテストパケットは、ルータ１６で上記と同様の処理を施された後、サーバ１４によって受信される。サーバ１４は、テストパケットを受信してから４０秒後にレスポンスパケット“４０秒”をクライアントに送信する。
【０１０１】
しかし、このときも既にレスポンス待ちポートは閉じられており、このため、レスポンスパケット“４０秒”は、ルータ１６において破棄され、Ｗｅｂカメラ１２は、レスポンスパケットを受信することができない。
【０１０２】
そこでＷｅｂカメラ１２はさらに、前回のテストパケットの送信から６５秒が経過したとき、その次のテストパケットをサーバ１４に送信する。つまり、Ｗｅｂカメラ１２は、レスポンスパケットを受信できない期間、６５秒毎にテストパケットを送信する。
【０１０３】
こうして６５秒毎に送られてくるテストパケットに応じ、サーバ１４は、応答までの待ち時間を毎回１０秒ずつ短縮しながら、つまり受信から３０秒後，２０秒後，…に、レスポンスパケット“３０秒”，レスポンスパケット“２０秒”，…を送信する。
【０１０４】
このため、応答までの待ち時間（これをｓ秒とする）がポート開放時間を下回った時点で、Ｗｅｂカメラ１２は、レスポンスパケットを受信することができる。Ｗｅｂカメラ１２は、受信されたレスポンスパケットから時間情報“ｓ秒”を抽出し、抽出された時間情報“ｓ秒”をレジスタ“Ｔ”に記録する。たとえばレスポンス待ちポートの開放時間が１５秒である場合、レスポンスパケット“１０秒”がＷｅｂカメラ１２に到達し、レジスタ“Ｔ”に“１０秒”が記録される。
【０１０５】
かくしてレジスタ“Ｔ”に時間情報“ｓ秒”が記録されると、Ｗｅｂカメラ１２は、テスト終了パケットを送信し、このテスト終了パケットを受信したサーバ１４では、最適送信間隔算出に関わる処理が終了される。
【０１０６】
図５のステップＳ３１に示された最適間隔（Ｔ）算出処理は、図１２のサブルーチンに従って実行される。図１２を参照して、ステップＳ１５１では、ＵＤＰに従うテスト開始パケットをサーバ宛に送信する。ステップＳ１５３では、タイマをリセットおよびスタートし、その後、ステップＳ１５５およびＳ１５７のループに入る。ステップＳ１５５では、レスポンスパケットが受信されたか否かを判別し、ステップＳ１５７では、所定時間たとえば６５秒が経過したか否かを判別する。
【０１０７】
６５秒以内にレスポンスパケットが受信されれば、ステップＳ１５５でＹＥＳと判別され、ステップＳ１５９に移る。ステップＳ１５９では、受信されたレスポンスパケットから時間情報（ｓ）を抽出し、ステップＳ１６１では、抽出された時間情報（ｓ）をレジスタ“Ｔ”にセットする。そしてステップＳ１６３で、ＵＤＰに従うテスト終了パケットをサーバ１４宛に送信し、その後、上位層のルーチンに復帰する。
【０１０８】
６５秒が経過してもレスポンスパケットが受信されなければ、ステップＳ１５７でＹＥＳと判別され、ステップＳ１６５に移る。ステップＳ１６５では、テストパケットをサーバ１４宛に送信し、その後、ステップＳ１５３に戻る。
【０１０９】
図１３を参照して、ステップＳ１７１〜Ｓ１８１は、図９に示されたステップＳ１０１〜Ｓ１１１と同じ処理であり、説明を省略する。テスト開始パケットが受信されると、ステップＳ１７３でＹＥＳと判別し、ステップＳ１８３に移る。ステップＳ１８３では、時間情報（ｓ）を初期化する。具体的には、変数ｓに“６０”をセットする。そして、ステップＳ１８５でタイマをリセットおよびスタートし、ステップＳ１８７およびＳ１８９のループに入る。ステップＳ１８７では、テスト開始パケットの受信からｓ秒が経過したか否かをタイマによって判別し、ステップＳ１８９では、テスト終了パケットが受信されたか否かを判別する。
【０１１０】
テスト開始パケットの受信からｓ秒が経過すると、まずステップＳ１９１でレスポンスパケットに変数ｓの値を埋め込み、次にステップＳ１９３でレスポンスパケットをＵＤＰに従ってクライアント宛に送信し、そしてステップＳ１９５で変数ｓから“１０”を減算する。その後、ステップＳ１８５に戻る。
【０１１１】
テスト開始パケットの受信からｓ秒以内にテスト終了パケットが受信されると、ステップＳ１７１およびＳ１７３のループに戻る。
【０１１２】
以上から明らかなように、この実施例では、前述の実施例と同様、Ｗｅｂカメラ１２は、ルータ１６のタイプに関係なく、サーバ１４から任意のタイミングでコマンドを受け付けることができる。
【０１１３】
加えて、Ｗｅｂカメラ１２は、ルータ１６がＵＰｎＰ非対応タイプのとき、応答タイミングを短縮方向に毎回更新しながらの応答を要求するテストパケットをルータ１６を通してサーバ１４に繰り返し返送する。換言すれば、Ｗｅｂカメラ１２がルータ１６に向けてテストパケットのサーバ１４への送信依頼を繰り返し発行し、１つ１つの送信依頼に応じてルータ１６がサーバ１４にテストパケットを送信する。すると、ルータ１６においてレスポンス待ちポートが一時的に開放され、サーバ１４は、テストパケットに応答してレスポンスパケットを返送する。応答タイミングは、テストパケットを受信する度に段々早められる。その際サーバ１４は、返送するレスポンスパケットにテストパケットの受信から返送までの待ち時間を示す時間情報を添付する。
【０１１４】
当初、レスポンスパケットはレスポンス待ちポートが閉鎖されるよりも遅いタイミングで返送されるため、Ｗｅｂカメラ１２はレスポンスパケットを受信することができない。応答タイミングがレスポンス待ちポートの閉鎖よりも早いタイミングにまで短縮されると、Ｗｅｂカメラ１２はレスポンスパケットを受信できるようになる。そこで、最初に受信されたレスポンスパケットに添付の時間情報の示す時間を送信要求の発行周期（＝最適送信周期Ｔ）とする。
【０１１５】
Ｗｅｂカメラ１２は、こうして決定される周期、つまりルータ１６が送信依頼に応じてレスポンス待ちポートを開放させる期間（ポート開放期間）を超えない最も長い周期、換言すればポート開放期間に等しいかまたはそれよりもわずかに短い周期で、ルータ１６に向けて送信依頼を繰り返し発行する。これにより、インターネット２０やＬＡＮなどの通信回線への負荷を最小限に抑えながら、レスポンス待ちポートが継続的に開放された状態を作り出すことができる。
【０１１６】
なお、この実施例では、サーバ１４側がレスポンスパケットに時間情報を添付し、Ｗｅｂカメラ１２は、最初に受信されたレスポンスパケットに添付の時間情報が示す時間を情報送信要求の発行周期としたが、代わりに、Ｗｅｂカメラ１２自身がテストパケットを最後に送信してからレスポンスパケットを最初に受信するまでの経過時間を計測し、計測結果を情報送信要求の発行周期としてもよい。
【０１１７】
次に、その他の実施例を説明する。前述の図１１〜図１３実施例では、レスポンスパケットの返送タイミングはサーバ１４が決定した（ステップＳ１８３およびＳ１９５を参照）が、この実施例では、クライアント側（Ｗｅｂカメラ１２）がこれを決定する。
【０１１８】
この実施例におけるクライアント側の最適送信間隔（Ｔ）算出処理を図１４に示し、また、この実施例におけるサーバ１４のＵＤＰパケット処理タスクを図１５に示す。クライアント・サーバ間で行われる通信処理自体は前実施例と同様であり、図１１を援用する。
【０１１９】
まず図１１を参照して、クライアント側からサーバ１４に送信されるテストパケットには、クライアント側で決定された返送タイミング（ｓ＝６０秒，５０秒，…，ｓ+１０秒，ｓ秒）を示す時間情報が含められる。サーバ１４は、テストパケットに含まれる時間情報に従うタイミングでレスポンスパケットを返送する。レスポンスパケットには、テストパケットの受信から返送までの経過時間を示す時間情報、つまりテストパケットに含まれるものと同じ時間情報（６０秒，５０秒，…，ｓ+１０秒，ｓ秒）が記述される。ただし、この実施例では、クライアント側で返送タイミングを決定しているので、サーバ１４がレスポンスパケットに時間情報を記述する処理は省略してもよい。
【０１２０】
図１４のクライアントによる最適間隔算出処理は、図１２のそれにおいて、ステップＳ１５０およびＳ１６４をさらに含んでいる。図１５のサーバ１４によるＵＤＰパケット処理タスクは、図１３のそれにおいて、ステップＳ１７９およびＳ１９１が削除されている。図１４に追加されたステップＳ１５０およびＳ１６４は、図１３から削除されたステップＳ１７９およびＳ１９１に対応する。
【０１２１】
図１４を参照して、まずステップＳ１５０で時間情報（ｓ）を初期化する。具体的には、変数ｓに“６０”をセットする。次のステップＳ１５１では、時間情報（ｓ）を含むテスト開始パケットを送信する。続くステップＳ１５３〜Ｓ１５７は、図１２のステップＳ１５３〜Ｓ１５７と同様であり、説明を省略する。ステップＳ１５７の判別結果がＹＥＳであれば、ステップＳ１６４で変数ｓから“１０”を減算し、次のステップ１６５では、時間情報（ｓ）を含むテスト開始パケットを送信する。
【０１２２】
図１５を参照して、ステップＳ１７１〜Ｓ１８１は、図１３のステップＳ１７１〜Ｓ１８１と同様であり、説明を省略する。ステップＳ１７３の判別結果がＹＥＳであれば、ステップＳ１８５に移って、タイマをリセットおよびスタートする。続くステップＳ１８７〜Ｓ１９３は、図１３のステップＳ１８７〜Ｓ１９３と同様であり、説明を省略する。そして、ステップＳ１９３の実行後、ステップＳ１８５に戻る。
【０１２３】
この実施例によれば、前述の図１１〜図１３実施例と同様の効果に加え、次のような効果が得られる。すなわち、クライアント側がレスポンスパケットの返送タイミングを指定するので、クライアント数が多い場合特に、サーバ１４の処理負荷を軽減することができる。
【０１２４】
なお、この実施例では、レスポンスパケットの応答タイミングを短縮方向に変化させた（ステップＳ１６４を参照）が、延長方向に変化させてもよい。以下、レスポンスパケットの応答タイミングを延長方向に変化させる実施例を図１６および図１７により説明する。
【０１２５】
図１６を参照して、クライアント側（Ｗｅｂカメラ１２）からサーバ１４に送信されるテストパケットには、クライアント側で決定された返送タイミング（ｓ＝５秒，１５秒，…，ｓ秒，ｓ＋１０秒）を示す時間情報が含められる。サーバ１４は、テストパケットに含まれる時間情報に従うタイミングでレスポンスパケットを返送する。レスポンスパケットには、テストパケットの受信から返送までの経過時間を示す時間情報つまりテストパケットに含まれるものと同じ時間情報（５秒，１５秒，…，ｓ秒，ｓ＋１０秒）が記述される。なお、この実施例では、クライアント側が返送タイミングを決定しているので、サーバ１４がレスポンスパケットに時間情報を記述する処理は省略してもよい。
【０１２６】
返送までも待ち時間がポート開放時間を上回った時点で、Ｗｅｂカメラ１２は、レスポンスパケットを受信することができなくなる。このため、Ｗｅｂカメラ１２のレジスタＴには、最後に受信されたレスポンスパケットから抽出された時間情報“ｓ秒”が保持されることとなる。
【０１２７】
Ｗｅｂカメラ１２のＣＰＵ２８は、図１７に示す手順に従って最適送信間隔（Ｔ）を算出する。図１７を参照して、まずステップＳ２０１で時間情報（ｓ）を初期化する。具体的には、変数ｓに“５”をセットする。次のステップＳ２０３では、時間情報（ｓ）を含むテスト開始パケットを送信する。ステップＳ２０５〜Ｓ２１３は、図１４のステップＳ１５３〜Ｓ１５９と同様であり、説明を省略する。
【０１２８】
ステップＳ２１５では、変数ｓに“１０”を加算し、次のステップＳ２１７では、時間情報（ｓ）を含むテスト開始パケットを送信する。その後、ステップＳ２０５に戻る。
【０１２９】
ステップＳ２０９でＹＥＳと判別されると、ステップＳ２１９に移り、テスト終了パケットをサーバ１４宛に送信する。その後、上位層のルーチンに復帰する。
【０１３０】
この実施例によれば、前述の図１１〜図１３実施例と同様の効果に加え、次のような効果が得られる。すなわち、クライアント側がレスポンスパケットの返送タイミングを指定するので、クライアント数が多い場合特に、サーバ１４の処理負荷を軽減することができる。
【０１３１】
なお、この実施例ではクライアント側（Ｗｅｂカメラ１２）がレスポンスパケットの返送タイミングを決定したが、レスポンスパケットの返送タイミングは、サーバ１４で決定することも可能である。返送タイミングの決定をサーバ１４で行う場合、図１７に示される最適送信間隔算出処理からは、ステップＳ２０１およびＳ２１５が削除される。一方、図１５に示されるサーバ１４のＵＤＰパケット処理タスクには、削除されたステップＳ２０１に対応するステップ（Ｓ１８３ａ；図示せず）がステップＳ１７３の直後に追加され、かつ削除されたステップＳ２１５に対応するステップ（Ｓ１９５ａ；図示せず）がステップＳ１９３の直後に追加される。
【０１３２】
また、この実施例では、応答タイミングを一定幅（＝１０）で延長方向に更新していき、最後に受信されたレスポンスパケットに記述されている時間情報（ｓ）を最適送信間隔（Ｔ）に決定したが、レスポンスパケットの未着状態が所定時間継続したとき、応答タイミングの更新幅を当初の半分（＝５）に縮小する方法もある。以下、レスポンスパケットの未着状態が所定時間継続したときに応答タイミングの更新幅を縮小する実施例を図１８〜図２０により説明する。
【０１３３】
図１８を参照して、クライアントは、レスポンスパケット“ｓ+１０秒”の未着を受け、時間情報“ｓ＋５秒”を含むテストパケットを送信する。これに対するレスポンスパケット“ｓ＋５秒”を受信すれば、このレスポンスパケットから抽出された時間情報“ｓ＋５秒”が、Ｗｅｂカメラ１２のレジスタＴに記録される。レスポンスパケット“ｓ＋５秒”を受信しなければ、先に受信されたレスポンスパケットから抽出された時間情報“ｓ秒”がレジスタＴに保持されたままとなる。
【０１３４】
なお、上記のレスポンスパケット“ｓ＋５秒”が未着の場合、更新幅をさらに縮小した時間情報、たとえば更新幅を当初の４分の１（＝２．５）に縮小した時間情報を含むテストパケットをさらに送信してもよい。
【０１３５】
クライアント（Ｗｅｂカメラ１２のＣＰＵ２８）は、図１９および図２０に示す手順で最適送信間隔（Ｔ）を算出する。図１９を参照して、ステップＳ２０１〜Ｓ２１９は、図１７のステップＳ２０１〜Ｓ２１９と同様なので、説明を省略する。ステップＳ２０９でＹＥＳと判別されると、ステップＳ２１８ａに移り、変数ｓに“５”を加算する。ステップＳ２１８ｂでは、時間情報（ｓ）を含むテストパケットをサーバ１４宛に送信する。ステップＳ２１８ｃでは、タイマをリセットおよびスタートし、その後、ステップＳ２１８ｄおよびＳ２１８ｅのループに入る。
【０１３６】
図２０を参照して、ステップＳ２１８ｄでは、レスポンスパケットが受信されたか否かを判別し、ステップＳ２１８ｅでは、所定時間たとえば６５秒が経過したか否かを判別する。
【０１３７】
６５秒以内にレスポンスパケットが受信されれば、ステップＳ２１８ｄでＹＥＳと判別され、ステップＳ２１８ｆに移る。ステップＳ２１８ｆでは、受信されたレスポンスパケットから時間情報（ｓ）を抽出し、ステップＳ２１８ｇでは、抽出された時間情報（ｓ）をレジスタ“Ｔ”にセットする。そして、ステップＳ２１９に進む。
【０１３８】
６５秒が経過してもレスポンスパケットが受信されなければ、ステップＳ２１８ｅでＹＥＳと判別され、ステップＳ２１９に移る。ステップＳ２１９では、テスト終了パケットをサーバ１４宛に送信し、その後、上位層のルーチンに復帰する。
【０１３９】
この実施例によれば、レスポンスパケットの未着状態が所定時間継続したときに、応答タイミングの更新幅を縮小したテストパケットを送信することによって、最適送信間隔の算出精度を向上させることができる。
【０１４０】
これに関連して、図１１〜図１３実施例ならびに図１４および図１５実施例においては、応答タイミングを一定幅（＝１０）で短縮方向に更新していき、最初に受信されたレスポンスパケットに記述されている時間情報（ｓ）を最適送信間隔（Ｔ）に決定したが、レスポンスパケットが最初に受信されたときに、応答タイミングの更新幅を当初の半分（＝５）に縮小する方法もある。以下、レスポンスパケットが最初に受信されたときに応答タイミングの更新幅を縮小する実施例を図２１〜図２３により説明する。
【０１４１】
図２１を参照して、クライアントは、レスポンスパケット“ｓ秒”の到着を受け、時間情報“ｓ＋５秒”を含むテストパケットを送信する。これに対するレスポンスパケット“ｓ＋５秒”を受信すれば、このレスポンスパケットから抽出された時間情報“ｓ＋５秒”がレジスタＴに記録される。レスポンスパケット“ｓ＋５秒”を受信しなければ、先に受信されたレスポンスパケットから抽出された時間情報“ｓ秒”がレジスタＴに保持されたままとなる。
【０１４２】
なお、上記のレスポンスパケット“ｓ＋５秒”が受信された場合、更新幅をさらに縮小した時間情報、たとえば更新幅を当初の４分の１（＝２．５）に縮小した時間情報を含むテストパケットをさらに送信してもよい。
【０１４３】
クライアント（Ｗｅｂカメラ１２のＣＰＵ２８）は、図２２および図２３に示す手順で最適送信間隔（Ｔ）を算出する。図２２を参照して、ステップＳ１５０〜Ｓ１６１は、図１４のステップＳ１５０〜Ｓ１６１と同様なので、説明を省略する。ステップＳ１６１に続くステップＳ１６２ａでは、変数ｓから“５”を減算する。ステップＳ１６２ｂでは、時間情報（ｓ）を含むテストパケットをサーバ１４宛に送信する。ステップＳ１６２ｃでは、タイマをリセットおよびスタートし、その後、ステップＳ１６２ｄおよびＳ１６２ｅのループに入る。
【０１４４】
図２３を参照して、ステップＳ１６２ｄでは、レスポンスパケットが受信されたか否かを判別し、ステップＳ１６２ｅでは、所定時間たとえば６５秒が経過したか否かを判別する。
【０１４５】
６５秒以内にレスポンスパケットが受信されれば、ステップＳ１６２ｄでＹＥＳと判別され、ステップＳ１６２ｆに移る。ステップＳ１６２ｆでは、受信されたレスポンスパケットから時間情報（ｓ）を抽出し、ステップＳ１６２ｇでは、抽出された時間情報（ｓ）をレジスタ“Ｔ”にセットする。そして、ステップＳ１６３に進む。
【０１４６】
６５秒が経過してもレスポンスパケットが受信されなければ、ステップＳ１６２ｅでＹＥＳと判別され、ステップＳ１６３に移る。ステップＳ１６３では、テスト終了パケットをサーバ１４宛に送信し、その後、上位層のルーチンに復帰する。
【０１４７】
この実施例によれば、レスポンスパケットが最初に受信されたときに、応答タイミングの更新幅を縮小したテストパケットを送信することによって、最適送信間隔の算出精度を向上させることができる。
【０１４８】
以上では、Ｗｅｂカメラ１２およびサーバ１４からなる監視カメラシステム１０について説明したが、この発明は、外部サーバと外部サーバからルータを通して通知されるコマンドに従う処理を実行するコマンド処理装置とからなるあらゆる処理システムに適用することができる。
【図面の簡単な説明】
【０１４９】
【図１】この発明の一実施例の構成を示すブロック図である。
【図２】（Ａ）はルータがＵＰｎＰに対応している場合に行われる通信処理の一部を示すシーケンス図であり、（Ｂ）はルータがＵＰｎＰに対応している場合に用いられるポート通知パケットの構成を示す図解図であり、（Ｃ）はルータがＵＰｎＰに対応している場合に行われる通信処理の他の一部を示すシーケンス図である。
【図３】（Ａ）はルータがＵＰｎＰに対応していない場合に行われる通信処理の一部を示すシーケンス図であり、（Ｂ）はルータがＵＰｎＰに対応していない場合に行われる通信処理の他の一部を示すシーケンス図であり、（Ｃ）はルータがＵＰｎＰに対応していない場合に用いられるポート通知パケットの構成を示す図解図である。
【図４】クライアントＣＰＵの動作の一部を示すフロー図である。
【図５】クライアントＣＰＵの動作の他の一部を示すフロー図である。
【図６】クライアントＣＰＵの動作のその他の一部を示すフロー図である。
【図７】クライアントＣＰＵの動作のさらにその他の一部を示すフロー図である。
【図８】クライアントＣＰＵの動作の他の一部を示すフロー図である。
【図９】サーバＣＰＵの動作の一部を示すフロー図である。
【図１０】サーバＣＰＵの動作の他の一部を示すフロー図である。
【図１１】他の実施例においてルータがＵＰｎＰに対応していない場合に行われる通信処理の一部を示すシーケンス図である。
【図１２】図１１実施例におけるクライアントＣＰＵの動作の一部を示すフロー図である。
【図１３】図１１実施例におけるサーバＣＰＵの動作の一部を示すフロー図である。
【図１４】その他の実施例におけるクライアントＣＰＵの動作の一部を示すフロー図である。
【図１５】図１４実施例におけるサーバＣＰＵの動作の一部を示すフロー図である。
【図１６】さらにその他の実施例においてルータがＵＰｎＰに対応していない場合に行われる通信処理の一部を示すシーケンス図である。
【図１７】図１６実施例におけるクライアントＣＰＵの動作の一部を示すフロー図である。
【図１８】別の実施例においてルータがＵＰｎＰに対応していない場合に行われる通信処理の一部を示すシーケンス図である。
【図１９】図１８実施例におけるクライアントＣＰＵの動作の一部を示すフロー図である。
【図２０】図１８実施例におけるクライアントＣＰＵの動作の他の一部を示すフロー図である。
【図２１】また別の実施例においてルータがＵＰｎＰに対応していない場合に行われる通信処理の一部を示すシーケンス図である。
【図２２】図２１実施例におけるクライアントＣＰＵの動作の一部を示すフロー図である。
【図２３】図２１実施例におけるクライアントＣＰＵの動作の他の一部を示すフロー図である。
【符号の説明】
【０１５０】
１０…監視カメラシステム
１２…Ｗｅｂカメラ（クライアント）
１４…サーバ
１６…ルータ
２０…インターネット
２２…携帯電話（端末）
２８，４２…ＣＰＵ
３４，４０…ネットワークコントローラ
【図１】
2006086954.tif 000003
【図２】
2006086954.tif 000004
【図３】
2006086954.tif 000005
【図４】
2006086954.tif 000006
【図５】
2006086954.tif 000007
【図６】
2006086954.tif 000008
【図７】
2006086954.tif 000009
【図８】
2006086954.tif 000010
【図９】
2006086954.tif 000011
【図１０】
2006086954.tif 000012
【図１１】
2006086954.tif 000013
【図１２】
2006086954.tif 000014
【図１３】
2006086954.tif 000015
【図１４】
2006086954.tif 000016
【図１５】
2006086954.tif 000017
【図１６】
2006086954.tif 000018
【図１７】
2006086954.tif 000019
【図１８】
2006086954.tif 000020
【図１９】
2006086954.tif 000021
【図２０】
2006086954.tif 000022
【図２１】
2006086954.tif 000023
【図２２】
2006086954.tif 000024
【図２３】
2006086954.tif 000025