JPWO2006030679A1 - 通信端末 - Google Patents

Abstract

通信端末はＣＰＵ（２８）を含む。ＣＰＵ（２８）は、ルータ（１６）に向けて繰り返し応答を要求する要求信号のサーバ（１４）への送信依頼を発行する。すると、ルータ（１６）によってサーバ（１４）に要求信号が送信され、かつ受信ポートが一時的に開放される。サーバ（１４）からは、要求信号に応答して応答信号が繰り返し返送される。応答信号には、要求信号の受信から返送までの待ち時間を示す時間情報が添付される。受信ポートが開放されている間に返送された応答信号はルータ（１６）を通って通信端末に達するが、閉鎖後に返送された応答信号はルータ（１６）で破棄される。ＣＰＵ（２８）は、最後に受信された応答信号に添付の時間情報が示す時間を発行周期（Ｔ）として、ルータ（１６）に向けて送信依頼を繰り返し発行する。

Description

この発明は、通信端末に関し、特にたとえば、送信依頼が発行されたとき依頼に従う送信処理を行いかつ受信ポートを一時的に開放するルータと接続される、通信端末に関する。

従来この種の通信端末は一般に、応答を要求する要求信号の外部サーバへの送信を依頼する送信依頼をルータに向けて発行する。すると、ルータによって要求信号が外部サーバに送信され、かつ受信ポートが一時的に開放される。外部サーバからは、応答信号が返送される。通信端末は、外部サーバから返送された応答信号を、開放された受信ポートを通して受信する。
従来技術によれば、外部サーバが応答信号にコマンドを含めて返送することによって、通信端末は、外部サーバからのコマンドを受け付けることができる。
しかしながら、従来技術では、受信ポートが開放されている期間だけしかコマンドを受け付けることができない。送信依頼を頻繁に発行すれば、受信ポートが継続的に開放された状態を作り出すことができるものの、通信回線への負荷が大きくなる。
発明の概要
それゆえに、この発明の主たる目的は、新規な通信端末を提供することである。
この発明に他の目的は、通信回線への負荷を最小限に抑えながら、受信ポートが継続的に開放された状態を作り出すことができる、通信端末を提供することである。
請求項１の発明に従う通信端末は、送信依頼が発行されたとき依頼に従う送信処理を行いかつ受信ポートを一時的に開放するルータと接続される通信端末であって、次のものを備える：繰り返し応答を要求する要求信号の外部サーバへの送信を依頼する送信依頼をルータに向けて発行する第１発行手段；第１発行手段によって発行された送信依頼に対する外部サーバからの応答信号を受信ポートを通して受信する受信手段；および受信手段の受信結果に基づいて送信依頼の発行周期を決定する決定手段。
第１発行手段は、繰り返し応答を要求する要求信号の外部サーバへの送信を依頼する送信依頼をルータに向けて発行する。かかる送信依頼が発行されると、ルータによって、繰り返し応答を要求する要求信号が外部サーバに送信され、かつ受信ポートが一時的に開放される。外部サーバからは、応答信号が繰り返し返送される。返送された応答信号は、開放された受信ポートを通って受信手段により受信される。
第１発行手段が送信依頼を発行したとき開放された受信ポートは、一定期間が経過すると閉鎖される。受信ポートが閉鎖されると、以降、受信手段は応答信号を受信しなくなるので、受信手段による受信結果に基づいて、送信依頼が発行されたときルータが受信ポートを開放させる期間（ポート開放期間）を知ることができ、ひいては送信依頼の最適な発行周期を決定することができる。
決定手段は、かかる受信手段の受信結果に基づいて、送信依頼の発行周期を決定する。こうして決定される周期、つまりポート開放期間を超えない最も長い周期、換言すればポート開放期間に等しいかまたはそれよりもわずかに短い周期で第１発行手段が送信依頼を発行すれば、通信回線への負荷を最小限に抑えながら、受信ポートが継続的に開放された状態を作り出すことができる。
請求項２の発明に従う通信端末は、請求項１に従属し、応答信号は依頼受信時刻から応答送信時刻までの時間を示す時間情報を含み、決定手段は受信手段によって最後に受信された応答信号に含まれる時間情報に基づいて発行周期を決定する。
最後に受信された応答信号に含まれる時間情報は、ポート開放期間を超えない最長時間、つまりポート開放期間に等しいかそれよりもわずかに短い時間を示す。このため、最後に受信された応答信号に含まれる時間情報を参照することによって、簡単かつ適切に発行周期を決定することができる。
請求項３の発明に従う通信端末は、請求項１に従属し、繰り返し応答の停止を要求する要求信号の外部サーバへの送信を依頼する送信依頼を決定手段による決定の後にルータに向けて発行する第２発行手段をさらに備える。
決定手段による決定が行われた後、第２発行手段が送信依頼を発行する。するとルータから、繰り返し応答の停止を要求する要求信号が外部サーバに送信され、外部サーバによる応答信号の繰り返し返送が停止される。
発行周期決定後は応答信号の繰り返し返送が停止されるので、応答信号による通信回線への負荷を軽減することができる。
請求項４の発明に従う通信端末は、請求項１に従属し、外部サーバとの間の通信路が切断されたとき第１発行手段の発行動作を停止させる停止手段をさらに備える。
第１発行手段の発行動作は、外部サーバと通信端末との間の通信路が切断されたとき、停止手段によって停止される。これにより、受信ポートが継続的に開放された状態は解消される。こうして、外部サーバとの通信を終えた後に受信ポートを閉鎖することで、不正アクセスを防止することができる。
請求項５の発明に従う通信端末は、送信依頼が発行されたとき依頼に従う送信処理を行いかつ受信ポートを一時的に開放するルータと接続される通信端末であって、次のものを備える：互いに異なるタイミングでの応答を要求する要求信号の外部サーバへの送信を依頼する送信依頼をルータに向けて繰り返し発行する第１発行手段；第１発行手段によって発行された送信依頼に対する外部サーバからの応答信号を受信ポートを通して受信する受信手段；および受信手段の受信結果に基づいて送信依頼の発行周期を決定する決定手段。
第１発行手段は、互いに異なるタイミングでの応答を要求する要求信号の外部サーバへの送信を依頼する送信依頼をルータに向けて繰り返し発行する。第１発行手段が送信依頼を発行する度に、ルータによって、互いに異なるタイミングでの応答を要求する要求信号が外部サーバに送信され、かつ受信ポートが一時的に開放される。外部サーバからは、第１発行手段によって送信依頼が発行される度に、応答信号が互いに異なるタイミングで返送される。
第１発行手段が送信依頼を発行したとき開放された受信ポートは、一定期間が経過すると閉鎖される。互いに異なるタイミングで返送される応答信号のうち、受信ポートの閉鎖よりも遅いタイミングで返送された応答信号は、受信手段によって受信されない。このため、受信手段による受信結果に基づいて、送信依頼が発行されたときルータが受信ポートを開放させる期間（ポート開放期間）を知ることができ、ひいては送信依頼の最適な発行周期を決定することができる。
決定手段は、かかる受信手段の受信結果に基づいて、送信依頼の発行周期を決定する。こうして決定される周期、つまりポート開放期間を超えない最も長い周期、換言すればポート開放期間に等しいかまたはそれよりもわずかに短い周期で第１発行手段が送信依頼を発行すれば、通信回線への負荷を最小限に抑えながら、受信ポートが継続的に開放された状態を作り出すことができる。
請求項６の発明に従う通信端末は、請求項５に従属し、要求信号によって要求される応答タイミングを延長方向および短縮方向のいずれか一方に向けて更新する更新手段をさらに備える。
更新手段は、要求信号によって要求される応答タイミングを延長方向および短縮方向のいずれか一方に向けて更新する。これにより、繰り返し発行される送信依頼に対する応答タイミングは、早まる方向および遅れる方向のどちらかに単調に変化する。
請求項７の発明に従う通信端末は、請求項６に従属し、更新手段による更新方向は延長方向であり、決定手段は受信手段によって最後に受信された応答信号に基づいて発行周期を決定する。
送信依頼が発行される度に、送信依頼に対する応答タイミングが段々遅れていく。このため受信手段は、ある時点までは応答信号を繰り返し受信しているが、ある時点を過ぎると応答信号を受信しなくなる。最後に受信される応答信号の応答タイミングは、ポート開放期間を超えない最長時間を示すので、最後に受信された応答信号に基づいて適切に発行周期を決定することができる。
請求項８の発明に従う通信端末は、請求項７に従属し、受信手段によって応答信号が受信されない状態が所定時間継続したとき更新手段の更新幅を縮小する縮小手段をさらに備える。
送信依頼の発行周期を決定する精度が向上し、その結果、通信回線への負荷を最小限に抑えることができる。
請求項９の発明に従う通信端末は、請求項６に従属し、更新手段による更新方向は短縮方向であり、決定手段は受信手段によって最初に受信された応答信号に基づいて発行周期を決定する。
送信依頼が発行される度に、送信依頼に対する応答タイミングが段々早まっていく。このため受信手段は、ある時点までは応答信号を受信しないが、ある時点を過ぎると応答信号を繰り返し受信するようになる。最初に受信される応答信号の応答タイミングは、ポート開放期間を超えない最長時間を示すので、最初に受信された応答信号に基づいて適切に発行周期を決定することができる。
請求項１０の発明に従う通信端末は、請求項９に従属し、受信手段によって応答信号が最初に受信されたとき更新手段の更新幅を縮小する縮小手段をさらに備える。
送信依頼の発行周期を決定する精度が向上し、その結果、通信回線への負荷を最小限に抑えることができる。
請求項１１の発明に従う通信端末は、請求項５に従属し、応答信号は依頼受信時刻から応答送信時刻までの時間を示す時間情報を含み、決定手段は時間情報に基づいて発行周期を決定する。
応答信号に含まれる時間情報は、依頼受信時刻から応答送信時刻までの時間、つまり応答タイミングを示す。このため、受信された応答信号に含まれる時間情報を参照することによって、簡単に発行周期を決定することができる。
請求項１２の発明に従う通信端末は、請求項５に従属し、応答停止を要求する要求信号の外部サーバへの送信を依頼する送信依頼を決定手段による決定の後にルータに向けて発行する第２発行手段をさらに備える。
決定手段による決定が行われた後、第２発行手段が送信依頼を発行する。するとルータから、応答の停止を要求する要求信号が外部サーバに送信され、外部サーバによる応答信号の返送が停止される。
発行周期決定後は応答信号の返送が停止されるので、応答信号による通信回線への負荷を軽減することができる。
請求項１３の発明に従う通信端末は、請求項５に従属し、外部サーバとの間の通信路が切断されたとき第１発行手段の発行動作を停止させる停止手段をさらに備える。
第１発行手段の発行動作は、外部サーバとの通信端末との間の通信路が切断されたとき、停止手段によって停止される。これにより、受信ポートが継続的に開放された状態は解消される。こうして、外部サーバとの通信を終えた後に受信ポートを閉鎖することで、不正アクセスを防止することができる。
請求項１４の発明に従う制御プログラムは、送信依頼が発行されたとき依頼に従う送信処理を行いかつ受信ポートを一時的に開放するルータと接続される通信端末のプロセサによって実行される制御プログラムであって、次のものを備える：繰り返し応答を要求する要求信号の外部サーバへの送信を依頼する送信依頼をルータに向けて発行する第１発行ステップ；第１発行ステップによって発行された送信依頼に対する外部サーバからの応答信号を受信ポートを通して受信する受信ステップ；および受信ステップの受信結果に基づいて送信依頼の発行周期を決定する決定ステップ。
請求項１５の発明に従う制御プログラムは、送信依頼が発行されたとき依頼に従う送信処理を行いかつ受信ポートを一時的に開放するルータと接続される通信端末のプロセサによって実行される制御プログラムであって、次のものを備える：互いに異なるタイミングでの応答を要求する要求信号の外部サーバへの送信を依頼する送信依頼をルータに向けて繰り返し発行する第１発行ステップ；第１発行ステップによって発行された送信依頼に対する外部サーバからの応答信号を受信ポートを通して受信する受信ステップ；および受信ステップの受信結果に基づいて送信依頼の発行周期を決定する決定ステップ。
この発明によれば、ルータに最適な周期、つまり送信依頼が発行されたときルータが受信ポートを開放させる期間（ポート開放期間）を超えない最も長い周期で、ルータに向けて送信依頼を繰り返し発行するので、通信回線への負荷を最小限に抑えながら、受信ポートが継続的に開放された状態を作り出すことができる。
この発明の上述の目的，その他の目的，特徴および利点は、図面を参照して行う以下の実施例の詳細な説明から一層明らかとなろう。

図１はこの発明の一実施例の構成を示すブロック図であり；
図２（Ａ）はルータがＵＰｎＰに対応している場合に行われる通信処理の一部を示すシーケンス図であり；
図２（Ｂ）はルータがＵＰｎＰに対応している場合に用いられるポート通知パケットの構成を示す図解図であり、
図２（Ｃ）はルータがＵＰｎＰに対応している場合に行われる通信処理の他の一部を示すシーケンス図であり；
図３（Ａ）はルータがＵＰｎＰに対応していない場合に行われる通信処理の一部を示すシーケンス図であり；
図３（Ｂ）はルータがＵＰｎＰに対応していない場合に行われる通信処理の他の一部を示すシーケンス図であり；
図３（Ｃ）はルータがＵＰｎＰに対応していない場合に用いられるポート通知パケットの構成を示す図解図であり；
図４はクライアントＣＰＵの動作の一部を示すフロー図であり；
図５はクライアントＣＰＵの動作の他の一部を示すフロー図であり；
図６はクライアントＣＰＵの動作のその他の一部を示すフロー図であり；
図７はクライアントＣＰＵの動作のさらにその他の一部を示すフロー図であり；
図８はクライアントＣＰＵの動作の他の一部を示すフロー図であり；
図９はサーバＣＰＵの動作の一部を示すフロー図であり；
図１０はサーバＣＰＵの動作の他の一部を示すフロー図であり；
図１１は他の実施例においてルータがＵＰｎＰに対応していない場合に行われる通信処理の一部を示すシーケンス図であり；
図１２は図１１実施例におけるクライアントＣＰＵの動作の一部を示すフロー図であり；
図１３は図１１実施例におけるサーバＣＰＵの動作の一部を示すフロー図であり；
図１４はその他の実施例におけるクライアントＣＰＵの動作の一部を示すフロー図であり；
図１５は図１４実施例におけるサーバＣＰＵの動作の一部を示すフロー図であり；
図１６はさらにその他の実施例においてルータがＵＰｎＰに対応していない場合に行われる通信処理の一部を示すシーケンス図であり；
図１７は図１６実施例におけるクライアントＣＰＵの動作の一部を示すフロー図であり；
図１８は別の実施例においてルータがＵＰｎＰに対応していない場合に行われる通信処理の一部を示すシーケンス図であり；
図１９は図１８実施例におけるクライアントＣＰＵの動作の一部を示すフロー図であり；
図２０は図１８実施例におけるクライアントＣＰＵの動作の他の一部を示すフロー図であり；
図２１はまた別の実施例においてルータがＵＰｎＰに対応していない場合に行われる通信処理の一部を示すシーケンス図であり；
図２２は図２１実施例におけるクライアントＣＰＵの動作の一部を示すフロー図であり；そして
図２３は図２１実施例におけるクライアントＣＰＵの動作の他の一部を示すフロー図である。

図１を参照して、この実施例の監視カメラシステム１０は、Ｗｅｂカメラ１２を含む。Ｗｅｂカメラ１２は、ルータ１６およびＤＳＬモデム１８を介してインターネット２０に接続される。インターネット２０にはサーバ１４が接続されており、Ｗｅｂカメラ１２は、このサーバ１４を通して、インターネット２０に接続された端末たとえば携帯電話２２からの操作を受け付ける。具体的な操作としては、たとえば撮像ユニット２４およびカメラ処理回路２６を通して感度，ズーム倍率などを調節したり、図示しない駆動ユニットを介してＷｅｂカメラ１２の向きを制御したりする操作が挙げられる。
なお、ルータ１６には、Ｗｅｂカメラ１２だけでなく、必要に応じて他の情報家電，ＰＣなどが接続される。こうしてＷｅｂカメラ１２，他の情報家電，ＰＣなどがルータ１６を介して互いに接続された結果、１つのＬＡＮが構成される。ルータ１６は、ただ１つのグローバルＩＰアドレスを持ち、ＬＡＮを構成する１つ１つの機器にはプライベートＩＰアドレスを割り当てる。そして、ＬＡＮ側の機器がインターネット２０側の機器と通信するとき、ＬＡＮ側で用いられるプライベートＩＰアドレスおよび送信元ポート番号と、インターネット側で用いられるグローバルＩＰアドレスおよびレスポンス待ちポート番号とを互いに変換するアドレス／ポート変換処理を実行する。
ルータ１６としては、ＵＰｎＰ（Ｕｎｉｖｅｒｓａｌ Ｐｌｕｇ ＆ Ｐｌａｙ）プロトコルに対応したタイプと非対応タイプとの２種類が用いられる。Ｗｅｂカメラ１２は、サーバ１４と協働して、まず自分に接続されたルータ１６のタイプに適した制御方式を選択し、そして選択された制御方式に従って携帯電話２２からの操作を受け付ける。なお、ルータ１６がＵＰｎＰ対応タイプか否かは、ＵＰｎＰが採用するディスカバリ機能たとえばＳＳＤＰ（Ｓｉｍｐｌｅ Ｓｅｒｖｉｃｅ Ｄｉｓｃｏｖｅｒｙ Ｐｒｏｔｏｃｏｌ）を利用することにより判別できる。
制御方式の選択を含む初期設定は、具体的には、次のようにして行われる。すなわち、Ｗｅｂカメラ１２は、電源が投入されたとき、ルータ１６がＵＰｎＰ対応型か否かを判別するために、まずルータ１６にＳＳＤＰに基づくＭ−ＳＥＡＲＣＨパケットを送信する。図２（Ａ）には、ルータ１６がＵＰｎＰ対応型である場合の初期設定の手順が示され、図３（Ａ）には、ルータ１６がＵＰｎＰ非対応型である場合の初期設定の手順が示されている。
まず図２（Ａ）を参照して、ルータ１６がＵＰｎＰ対応型の場合、ルータ１６は、Ｗｅｂカメラ１２（クライアント）からのＭ−ＳＥＡＲＣＨパケットに応じ、Ｗｅｂカメラ１２に２００ＯＫパケットを返送する。２００ＯＫパケットを受信したＷｅｂカメラ１２は次に、ルータ１６にグローバルＩＰアドレスを要求する。ルータ１６は、Ｗｅｂカメラ１２の要求に応じ、Ｗｅｂカメラ１２にグローバルＩＰアドレスを通知する。
こうしてグローバルＩＰアドレスを取得したＷｅｂカメラ１２は次に、特定ポートを開放するようルータ１６に要求する。ルータ１６は、Ｗｅｂカメラ１２の要求に応じ、特定ポートを開放する。この後、特定ポート宛に送られてきたパケットは、ルータ１６により全てＷｅｂカメラ１２に転送される。
続いてＷｅｂカメラ１２は、サーバ１４に向けてＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）に従うポート通知パケットを送信する。ルータ１６がＵＰｎＰ対応型であるときＷｅｂカメラ１２（クライアント）がルータ１６に送信するポート通知パケットの構成が図２（Ｂ）に示されている。図２（Ｂ）を参照して、ポート通知パケットのデータ領域には、ルータ１６によって開放された特定ポートのポート番号が記述される。なお、データ領域には、認証のための機器ＩＤなどが必要に応じてさらに記述される。
ヘッダ領域には、他のパケットと同じように、プライベートＩＰアドレスおよび送信元ポート番号が記述される。ヘッダ領域内のプライベートＩＰアドレスおよび送信元ポート番号は、ルータ１６を通過するときグローバルＩＰアドレスおよびレスポンス待ちポート番号に変換される。
サーバ１４は、Ｗｅｂカメラ１２からのポート通知パケットを受信し、受信されたポート通知パケットのデータ領域から特定ポート番号を抽出し、かつ同じポート通知パケットのヘッダ領域からグローバルＩＰアドレスを抽出する。そして、抽出されたアドレスおよび抽出されたポート番号によって特定される宛先にレスポンスパケットを送信する一方、抽出されたアドレスおよび抽出されたポート番号をＲＡＭ３６に保持する。送信されたレスポンスパケットは、ルータ１６によってＷｅｂカメラ１２へと転送される。ＲＡＭ３６に保持されたアドレスおよびポート番号は、後にＷｅｂカメラ１２へコマンドを送信するとき参照される。なお、ＲＡＭ３６内のデータたとえばアドレス，ポート番号，コマンド等は、ＨＤＤ４４によってバックアップされる（以下同様）。
次に図３（Ａ）を参照して、ルータ１６がＵＰｎＰ非対応型の場合、ルータ１６は、Ｗｅｂカメラ１２からＭ−ＳＥＡＲＣＨパケットが送られてきても何も応答しない。Ｗｅｂカメラ１２は、Ｍ−ＳＥＡＲＣＨパケットを送信しても２００ＯＫパケットが返送されてこないため、ルータ１６がＵＰｎＰ非対応型であると判断し、最適送信間隔（Ｔ）を求めるための処理に移る。
最適送信間隔算出処理では、まずクライアントつまりＷｅｂカメラ１２がＵＤＰに従うテスト開始パケットをサーバ１４に送信する。
送信されたテスト開始パケットは、ルータ１６によってアドレス／ポート変換処理を施され、アドレス／ポート変換処理を施されたパケットがサーバ１４によって受信される。このときルータ１６では、レスポンス待ちポートが開放され、また、送信元アドレスつまりＷｅｂカメラ１２のプライベートＩＰアドレスと、変換前後のポート番号つまり送信元ポート番号およびレスポンス待ちポート番号とがテーブルに記録される。テスト開始パケットに応じて開放されたレスポンス待ちポートは、所定期間たとえば１５秒が経過すると閉じられる。
サーバ１４は、テスト開始パケットを受信してから所定時間たとえば２秒後にレスポンスパケットをクライアントに送信する。レスポンスパケットには、テスト開始パケットの受信からの経過時間を示す時間情報つまり“２秒”が記述される。
２秒後に送信されたレスポンスパケットは、ルータ１６において、上記テーブルに基づくアドレス／ポート変換処理を施され、アドレス／ポート変換処理を施されたパケットがＷｅｂカメラ１２によって受信される。Ｗｅｂカメラ１２は、受信されたレスポンスパケットから時間情報“２秒”を抽出し、抽出された時間情報“２秒”をレジスタ“Ｔ”に記録する。
サーバ１４はさらに、テスト開始パケットを受信してから４秒後，６秒後，…にもレスポンスパケットをクライアントに送信する。レスポンスパケットには、経過時間“４秒”，“６秒”，…が記述される。
４秒後，６秒後，…に送信されたレスポンスパケットもまた、ルータ１６において同様のアドレス／ポート変換処理を施され、変換処理を施されたパケットがＷｅｂカメラ１２によって受信される。Ｗｅｂカメラ１２は、受信されたレスポンスパケットから時間情報“４秒”，“６秒”…を抽出し、抽出された時間情報“４秒”，“６秒”…をレジスタ“Ｔ”に前の値を上書きしながら記録する。従って、レジスタ“Ｔ”には常に、直近に受信されたレスポンパケットから抽出された時間情報が保持されることとなる。
そして、ｔ秒後に送信されたレスポンスパケットがＷｅｂカメラ１２によって受信され、この直後にレスポンス待ちポートが閉じられたとする。以降のレスポンスパケットつまり（ｔ＋２）秒後，（ｔ＋４）秒後，…に送信されたレスポンスパケットは、いずれもルータ１６において破棄され、Ｗｅｂカメラ１２には到達しない。
Ｗｅｂカメラ１２は、前回の受信から５秒経過しても次のレスポンスパケットが受信されないので、テスト終了パケットを送信する。サーバ１４は、テスト終了パケットを受け、レスポンスパケットの送信を終了する。この結果、Ｗｅｂカメラ１２のレジスタ“Ｔ”には“ｔ秒”が残され、従って“ｔ秒”が最適送信間隔Ｔとなる。
このような初期設定が完了した後、Ｗｅｂカメラ１２は、サーバ１４を通して、端末つまり携帯電話２２からのコマンドを受け付け、かつコマンドの実行結果を携帯電話２２に返す。図２（Ｃ）には、ルータ１６がＵＰｎＰ対応型である場合のコマンドおよび実行結果の転送手順が示され、図３（Ｂ）には、ルータ１６がＵＰｎＰ非対応型である場合のコマンドおよび実行結果の転送手順が示されている。
まず図２（Ｃ）を参照して、ＵＰｎＰ対応型であるルータ１６では、先の初期設定によって特定ポートが開放されている。携帯電話２２から送信されたコマンドは、サーバ１４によって受信される。サーバ１４は、受信されたコマンドをＲＡＭ３６に保持する一方、“コマンド有り”通知パケットをＲＡＭ３６に保持されたアドレスおよびポート番号によって特定される宛先に送信する。
サーバ１４から送信された“コマンド有り”通知パケットは、ルータ１６によって受信される。ルータ１６は、受信された“コマンド有り”通知パケットをＷｅｂカメラ１２に転送する。
Ｗｅｂカメラ１２は、ルータ１６によって転送された“コマンド有り”通知パケットを受信し、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）に従うコマンド要求パケットを送信する。送信されたコマンド要求パケットは、サーバ１４によって受信され、応じてサーバ１４は、ＲＡＭ３６に保持されたコマンドをクライアント宛に送信する。送信されたコマンドは、ルータ１６によって所定のポートで受信され、ルータ１６は、受信されたコマンドをＷｅｂカメラ１２に転送する。
Ｗｅｂカメラ１２は、ルータ１６によって転送されたコマンドを受信し、受信されたコマンドを実行し、そして実行結果をＴＣＰに従って送信する。送信された実行結果は、サーバ１４によって受信され、サーバ１４は、受信された実行結果を携帯電話２２に転送する。転送された実行結果は、携帯電話２２によって受信され、携帯電話２２は、受信された実行結果をＬＣＤモニタ（図示せず）に表示する。
次に図３（Ｂ）を参照して、ルータ１６がＵＰｎＰ非対応型であるため、クライアントつまりＷｅｂカメラ１２は、初期設定で算出された最適送信間隔（Ｔ）で周期的にポート通知パケットを送信する。この結果、ルータ１６では、レスポンス待ちポートが常時開放された状態となる。
ルータ１６がＵＰｎＰ非対応型であるときＷｅｂカメラ１２（クライアント）がルータ１６に送信するポート通知パケットの構成が図３（Ｃ）に示されている。図３（Ｃ）を参照して、ポート通知パケットのデータ領域には、無意のポート番号“０”が記述され、ヘッダ領域には、プライベートＩＰアドレスおよび送信元ポート番号が記述される。ヘッダ領域内のプライベートＩＰアドレスおよび送信元ポート番号は、ルータ１６を通過するときグローバルＩＰアドレスおよびレスポンス待ちポート番号に変換される。
サーバ１４は、Ｗｅｂカメラ１２からのポート通知パケットを受信し、受信されたポート通知パケットのヘッダ領域からグローバルＩＰアドレスおよびレスポンス待ちポート番号を抽出する。そして、抽出されたアドレスおよびポート番号をＲＡＭ３６に保持する。
携帯電話２２から送信されたコマンドは、サーバ１４によって受信される。サーバ１４は、受信されたコマンドをＲＡＭ３６に保持する一方、ＵＤＰに従う“コマンド有り”通知パケットをＲＡＭ３６に保持されたアドレスおよびポート番号によって特定される宛先に送信する。サーバ１４から送信された“コマンド有り”通知パケットは、ルータ１６によってレスポンス待ちポートで受信され、ルータ１６は、受信された“コマンド有り”通知パケットをＷｅｂカメラ１２に転送する。
Ｗｅｂカメラ１２は、ルータ１６によって転送された“コマンド有り”通知パケットを受信し、ＴＣＰに従うコマンド要求パケットを送信する。送信されたコマンド要求パケットは、サーバ１４によって所定のポートで受信され、サーバ１４は、ＲＡＭ３６に保持されたコマンドをＴＣＰに従ってクライアント宛に送信する。送信されたコマンドは、ルータ１６によって所定のポートで受信され、ルータ１６は、受信されたコマンドをＷｅｂカメラ１２に転送する。
Ｗｅｂカメラ１２は、ルータ１６によって転送されたコマンドを受信し、受信されたコマンドを実行し、そして実行結果をＴＣＰに従って送信する。送信された実行結果は、サーバ１４によって受信され、サーバ１４は、受信された実行結果を携帯電話２２に転送する。転送された実行結果は、携帯電話２２によって受信され、携帯電話２２は、受信された実行結果をＬＣＤモニタに表示する。
クライアントつまりＷｅｂカメラ１２のＣＰＵ２８は、電源等投入時、図４に示されたタイプ判別タスクを実行する。そしてタイプ判別タスク終了後、μＩＴＲＯＮのようなマルチタスクＯＳの制御下で、図５および図６に示されたメインタスクと、図７に示されたポート通知パケット送信タスクと、図８に示されたコマンド実行タスクとを並列的に処理する。なお、これらのフロー図に対応する制御プログラムは、フラッシュメモリ３０に格納される。
図４を参照して、タイプ判別タスクでは、まずステップＳ１でルータ１６がＵＰｎＰ対応型か否かを判別し、判別結果が否定的であればステップＳ３に移る。ステップＳ３では、制御方式を“タイプ２”に設定する。その後、本タスクは終了される。
ここで、ステップＳ１の判別は、たとえば次のようにして行うことができる。ルータ１６にＳＳＤＰに基づくＭ−ＳＥＡＲＣＨパケットを送信し、ルータ１６から２００ＯＫパケットが返送されてくればＵＰｎＰ対応型であると判別する。一方、２００ＯＫパケットが返送されてこなければ、ＵＰｎＰ非対応型であると判別する。
ステップＳ１の判別結果が肯定的であればステップＳ５に移り、ネットワークコントローラ３４を介してルータ１６にインターネット２０側へアクセスするためのＩＰアドレス（ＷＡＮ側アドレス）を要求する。ステップＳ７では、グローバルＩＰアドレスが受信されたか否かを判別する。判別結果が否定的つまりプライベートＩＰアドレスが受信されれば、ステップＳ９で制御方式を“タイプ２”に設定する。その後、本タスクは終了される。
グローバルＩＰアドレスが受信されると、ステップＳ７からステップＳ１１に移り、特定ポートの開放をルータ１６に要求する。次のステップＳ１３では、ＵＤＰに従うポート通知パケットをサーバ１４に送信する。ポート通知パケットには、ルータ１６に開放を要求した特定ポートのポート番号がデータ領域に記述される（図２（Ｂ）参照）。その後ステップＳ１５およびＳ１７のループに入る。
ステップＳ１５ではレスポンスパケットが受信されたか否かを判別し、ステップＳ１７では所定時間たとえば５秒が経過したか否かを判別する。ポート通知パケットの送信から５秒以内にレスポンスパケットが受信されれば、ステップＳ１５でＹＥＳと判別され、ステップ１９に移る。ステップＳ１９では、制御方式を“タイプ１”に設定する。そして、本タスクは終了される。
５秒が経過してもレスポンスパケットが受信されなければ、ステップＳ１７でＹＥＳと判別され、ステップＳ２１に移る。ステップＳ２１では、先に開放された特定ポートの閉鎖をルータ１６に要求する。ステップＳ２３では、制御方式を“タイプ２”に設定する。そして、本タスクは終了される。
このように、ルータ１６がＵＰｎＰに対応していなければ、制御方式としてタイプ２が直ちに選択される。一方、ルータ１６がＵＰｎＰに対応している場合には、ルータ１６からグローバルＩＰアドレスを取得でき、かつポート通知パケットを送信してから所定時間内にレスポンスパケットを受信できた場合に限り、制御方式として“タイプ１”が選択される。ルータ１６からグローバルＩＰアドレスを取得できなければ、制御方式として“タイプ２”が選択される。また、たとえグローバルＩＰアドレスを取得できても、所定時間内にレスポンスパケットを受信できなければ、外部サーバ１４が通知されたアドレスおよびポート番号宛に応答パケットを返送していないか、もしくはルータ１６において特定ポートが開放されていないと判断され、制御方式は“タイプ２”となる。
図５を参照して、メインタスクでは、まずステップＳ３１で初期処理を行う。初期処理では、ポート通知パケットを送信する際の最適送信間隔（Ｔ）が算出される。なお、最適送信間隔（Ｔ）算出処理の詳細については後述する。
次のステップＳ３３では、遠隔操作モードに入った否かを判別する。遠隔操作モードに入ると、ステップＳ３３からステップＳ３５に移って、制御方式が“タイプ２”に設定されているか否かを判別する。この判別結果が肯定的であれば、ステップＳ３７でポート通知パケット送信タスク（後述）を起動し、そしてステップ３９に移る。ステップＳ３５の判別結果が否定的つまり制御方式が“タイプ１”に設定されていれば、直ちにステップＳ３９に移る。
ステップＳ３９では、コマンド実行タスク（後述）を起動する。次のステップＳ４１では、遠隔操作モードを脱した否かを判別する。具体的には、端末２２とＷｅｂカメラ１２の間のＴＣＰコネクションが切断されたとき、遠隔操作モードを脱したと判別する。遠隔操作モードを脱すると、ステップＳ４２で制御方式が“タイプ２”に設定されているか否かを判別する。この判別結果が肯定的であれば、ステップＳ４３でポート通知パケット送信タスクを終了し、その後ステップＳ４５に移る。ポート通知パケット送信タスクの終了に伴い、レスポンス待ちポートが継続的に開放された状態は解消される。こうして、遠隔操作を終えた後にレスポンス待ちポートを閉鎖することで、不正アクセスを防止することができる。
ステップＳ４２の判別結果が否定的つまり制御方式が“タイプ１”であれば、ステップＳ４４で特定ポートの閉鎖をルータ１６に要求し、その後ステップＳ４５に移る。こうして、遠隔操作を終えた後に特定ポートを閉鎖することで、不正アクセスを防止することができる。
ステップＳ４５では、コマンド実行タスクを終了する。その後、ステップＳ３３に戻る。
上記ステップＳ３１の最適間隔（Ｔ）算出処理は、図６のサブルーチンに従って実行される。図６を参照して、ステップＳ５１では、ＵＤＰに従うテスト開始パケットをサーバ１４宛に送信する。ステップＳ５３では、タイマをリセットおよびスタートし、その後、ステップＳ５５およびＳ５７のループに入る。ステップＳ５５では、レスポンスパケットが受信されたか否かを判別し、ステップＳ５７では、所定時間たとえば５秒が経過したか否かを判別する。
５秒以内にレスポンスパケットが受信されれば、ステップＳ５５でＹＥＳと判別され、ステップＳ５９に移る。ステップＳ５９では、受信されたレスポンスパケットから時間情報（ｔ）を抽出し、ステップＳ６１では、抽出された時間情報（ｔ）をレジスタ“Ｔ”にセットする。その後、ステップＳ５３に戻る。
５秒が経過してもレスポンスパケットが受信されなければ、ステップＳ５７でＹＥＳと判別され、ステップＳ６３に移る。ステップＳ６３では、ＵＤＰに従うテスト終了パケットをサーバ１４宛に送信し、その後、上位層のルーチンに復帰する。
図７を参照して、ポート通知パケット送信タスクでは、まずステップＳ７１でポート通知パケット（図３（Ｃ）参照）をサーバ１４宛に送信し、ステップＳ７３でタイマをリセットおよびスタートする。ステップＳ７５では、最適送信間隔（Ｔ）が経過したか否かを判別し、判別結果が肯定的になると、ステップＳ７１に戻る。
図８を参照して、コマンド実行タスクでは、まずステップＳ８１で、“コマンド有り”通知パケットが受信されたか否かを判別する。ステップＳ８３では、ＴＣＰに従うコマンド要求パケットをサーバ１４宛に送信する。ステップＳ８５では、コマンドが受信されたか否かを判別し、コマンドが受信されるとステップＳ８７に移る。ステップＳ８７では、受信されたコマンドを実行し、ステップ８９では、実行結果をＴＣＰに従ってサーバ１４宛に送信する。その後、ステップＳ８１に戻る。
サーバ１４のＣＰＵ４２は、μＩＴＲＯＮのようなマルチタスクＯＳの制御下で、図９に示されたＵＤＰパケット処理タスクと、図１０に示されたメインタスクとを並列的に処理する。なお、これらのフロー図に対応する制御プログラムは、ＲＯＭ３８に格納される。
図９を参照して、ＵＤＰパケット処理タスクでは、まずステップＳ１０１およびＳ１０３のループに入る。ステップＳ１０１では、ポート通知パケットが受信されたか否かを判別し、ステップＳ１０３では、テスト開始パケットが受信されたか否かを判別する。ポート通知パケットが受信されると、ステップＳ１０１でＹＥＳと判別し、ステップＳ１０５に移る。ステップＳ１０５では、受信されたポート通知パケットのデータ領域に有意の情報が記述されているか否かを判別する。ステップＳ１０５の判別結果が肯定的であれば、ステップＳ１０７に移る。たとえば、図２（Ｂ）に示すポート通知パケットが受信されたとき、ステップＳ１０５の判別結果は肯定的となる。
ステップＳ１０７では、受信されたポート通知パケットのデータ領域からポート番号を抽出し、かつ同じポート通知パケットのヘッダ領域からアドレスを抽出する。そして、抽出されたポート番号つまり特定ポートの番号と、抽出されたアドレスつまりグローバルＩＰアドレスとをＲＡＭ３６に保持する。次のステップＳ１０９では、レスポンスパケットをＲＡＭ３６に保持されたアドレスおよびポート番号によって特定される宛先に送信し、その後ステップＳ１０１およびＳ１０３のループに戻る。
ステップＳ１０５の判別結果が否定的であれば、ステップＳ１１１に移る。たとえば、図３（Ｃ）に示すポート通知パケットが受信されたとき、ステップＳ１０５の判別結果は否定的となる。ステップＳ１１１では、受信されたポート通知パケットのヘッダ領域からアドレスおよびポート番号を抽出する。そして、抽出されたポート番号つまりレスポンス待ちポートの番号と、抽出されたアドレスつまりグローバルＩＰアドレスとをＲＡＭ３６に保持する。その後、ステップＳ１０１およびＳ１０３のループに戻る。
テスト開始パケットが受信されると、ステップＳ１０３でＹＥＳと判別し、ステップＳ１１３に移る。ステップＳ１１３では、時間情報（ｔ）を初期化する。具体的には、変数ｔに“０”をセットする。そして、ステップＳ１１５でタイマをリセットおよびスタートし、ステップＳ１１７およびＳ１１９のループに入る。ステップＳ１１７では、テスト開始パケット（前回のテストパケット）の受信から一定時間たとえば２秒が経過したか否かをタイマによって判別し、ステップＳ１１９では、テスト終了パケットが受信されたか否かを判別する。
テスト開始パケット（前回のテストパケット）の受信から２秒が経過すると、まずステップＳ１２１で変数ｔに“２”を加算し、次にステップＳ１２３でレスポンスパケットに変数ｔの値を埋め込み、そしてステップＳ１２５でレスポンスパケットをＵＤＰに従ってクライアント宛に送信する。その後、ステップＳ１１５に戻る。
テスト終了パケットが受信されると、ステップＳ１０１およびＳ１０３のループに戻る。
図１０を参照して、メインタスクでは、まずステップＳ１３１で、端末つまり携帯電話２２からのコマンドが受信されたか否かを判別する。コマンドが受信されるとステップＳ１３３に移って、ＵＤＰに従う“コマンド有り”通知パケットをＲＡＭ３６に保持されたアドレスおよびポート番号によって特定される宛先に送信する。ここでＲＡＭ３６に保持されているポート番号は、特定ポートおよびレスポンス待ちポートのいずれかの番号である。
次のステップＳ１３５では、コマンド要求パケットが受信されたか否かを判別し、コマンド要求パケットが受信されるとステップＳ１３７に移って、先に受信されＲＡＭ３６に保持されたコマンドを、同じくＲＡＭ３６に保持されたアドレスおよびポート番号によって特定される宛先に送信する。その次のステップＳ１３９では、実行結果が受信されたか否かを判別し、実行結果が受信されるとステップＳ１４１に移って、受信された実行結果を携帯電話２２宛に転送する。その後、ステップＳ１３１に戻る。
以上から明らかなように、この実施例では、ルータ１６として、ＵＰｎＰプロトコルに対応したタイプおよび非対応タイプのどちらか一方が用いられる。コマンドは、かかるルータ１６を通して外部サーバ１４から送信される。
ルータ１６がＵＰｎＰ対応タイプのときは、Ｗｅｂカメラ１２は、ルータ１６に向けてポート開放要求を発行する。これによって、特定ポートが開放される。次にＷｅｂカメラ１２は、開放された特定ポートの識別子を含む宛先情報の外部サーバ１４への送信をルータ１６に要求する。宛先情報（図２（Ｂ）参照）は、ルータ１６によって外部サーバ１４に送信される。外部サーバ１４は、宛先情報に含まれる識別子に基づいて、コマンドを特定ポートに送信する。
ルータ１６がＵＰｎＰ非対応タイプのときは、Ｗｅｂカメラ１２は、ルータ１６に向けて情報送信要求を繰り返し発行する。発行される情報送信要求は、任意のポートの識別子を含む宛先情報の外部サーバ１４への送信要求である。ルータ１６は、情報送信要求が発行される毎に、宛先情報（図３（Ｃ）参照）を外部サーバ１４へ送信し、かつ任意のポート（レスポンス待ちポート）を一時的に開放する。外部サーバ１４は、宛先情報に含まれる識別子に基づいて、コマンドをレスポンス待ちポートに出力する。
このように、Ｗｅｂカメラ１２は、ルータ１６がＵＰｎＰ対応タイプのときは、特定ポートの開放と、開放された特定ポートの識別子を含む宛先情報のサーバ１４への送信とをルータに要求する。一方、ルータ１６がＵＰｎＰ非対応タイプのときは、ルータ１６に向けて情報送信要求を繰り返し発行することによって、レスポンス待ちポートが継続的に開放された状態を作り出し、かつ開放されたレスポンス待ちポートの識別子を含む宛先情報をサーバ１４に通知する。このため、ルータ１６のタイプに関係なく、サーバ１４から任意のタイミングでコマンドを受け付けることができる。
加えて、Ｗｅｂカメラ１２は、ルータ１６がＵＰｎＰ非対応タイプのとき、ルータ１６に向けて、繰り返し返送を要求するテストパケットのサーバ１４への送信依頼を発行する。応じてルータ１６は、サーバ１４にテストパケットを送信し、かつレスポンス待ちポートを一時的に開放する。サーバ１４は、テストパケットに応答してレスポンスパケットを繰り返し返送する。その際サーバ１４は、返送するレスポンスパケットにテストパケットの受信から返送までの待ち時間を示す時間情報を添付する。
Ｗｅｂカメラ１２は、外部サーバ１４から繰り返し返送されるレスポンスパケットを開放されたレスポンス待ちポートを通して受信する。レスポンス待ちポートが閉鎖されると、レスポンスパケットを受信することができなくなる。そこで、最後に受信されたレスポンスパケットに添付の時間情報の示す時間を送信要求の発行周期（＝最適送信周期Ｔ）とする。
Ｗｅｂカメラ１２は、こうして決定される周期、つまりルータ１６が送信依頼に応じてレスポンス待ちポートを開放させる期間（ポート開放期間）を超えない最も長い周期、換言すればポート開放期間に等しいかまたはそれよりもわずかに短い周期で、ルータ１６に向けて送信依頼を繰り返し発行する。これにより、インターネット２０やＬＡＮなどの通信回線への負荷を最小限に抑えながら、レスポンス待ちポートが継続的に開放された状態を作り出すことができる。
なお、この実施例では、サーバ１４側がレスポンスパケットに時間情報を添付し、Ｗｅｂカメラ１２は、最後に受信されたレスポンスパケットに添付の時間情報が示す時間を情報送信要求の発行周期としたが、代わりに、Ｗｅｂカメラ１２自身がテストパケットを送信してからレスポンスパケットを受信するまでの経過時間を計測し、最後に受信されたレスポンスパケットに対応する計測結果を情報送信要求の発行周期としてもよい。
次に、他の実施例を説明する。この実施例もまた、監視カメラシステムに関する。この実施例の監視カメラシステムは、前述の実施例の監視カメラシステムと同様に構成される。この実施例の監視カメラシステムの動作は、最適送信間隔（Ｔ）を算出する処理を除き、前述の実施例のそれと同様である。よって、この実施例にも、図１，図２（Ａ），図２（Ｂ），図３（Ｂ），図４，図５，図７，図８および図１０を援用し、重複する説明を省略する。
以下、最適送信間隔算出処理について、図１１〜図１３により詳細に説明する。なお、図１１は図３（Ａ）と対応し、図１２は図６と対応し、図１３は図９と対応する。
まず図１１を参照して、ルータ１６がＵＰｎＰ非対応型の場合、ルータ１６は、Ｗｅｂカメラ１２からのＭ−ＳＥＡＲＣＨパケットに応答しない。Ｍ−ＳＥＡＲＣＨパケットを送信しても２００ＯＫパケットが返送されてこないため、Ｗｅｂカメラ１２は、制御方式としてタイプ２を選択し、最適送信間隔（Ｔ）を求めるための処理に移る。
最適送信間隔算出処理では、まずクライアントつまりＷｅｂカメラ１２がＵＤＰに従うテスト開始パケットをサーバ１４に送信する。送信されたテスト開始パケットは、ルータ１６によってアドレス／ポート変換処理を施され、アドレス／ポート変換処理を施されたパケットがサーバ１４によって受信される。このときルータ１６では、レスポンス待ちポートが開放され、また、送信元アドレスつまりＷｅｂカメラ１２のプライベートＩＰアドレスと、変換前後のポート番号つまり送信元ポート番号およびレスポンス待ちポート番号とがテーブルに記録される。テスト開始パケットに応じて開放されたレスポンス待ちポートは、所定期間たとえば１５秒が経過すると閉じられる。
サーバ１４は、テスト開始パケットを受信してからたとえば６０秒後にＵＤＰに従うレスポンスパケットをクライアントに送信する。レスポンスパケットには、テスト開始パケットの受信からの経過時間を示す時間情報つまり“６０秒”が記述される。
このとき既にレスポンス待ちポートは閉じられており、このため、６０秒後に送信されたレスポンスパケットは、ルータ１６において破棄され、Ｗｅｂカメラ１２は、レスポンスパケットを受信することができない。
そこでＷｅｂカメラ１２は、テスト開始パケットの送信から所定時間たとえば６５秒が経過したとき、最初のテストパケットをサーバ１４に送信する。送信されたテストパケットは、ルータ１６によってアドレス／ポート変換処理を施され、アドレス／ポート変換処理を施されたパケットがサーバ１４によって受信される。このときルータ１６では、レスポンス待ちポートが再び開放され、また、プライベートＩＰアドレスと送信元ポート番号およびレスポンス待ちポート番号とがテーブルに記録される。テストパケットに応じて開放されたレスポンス待ちポートは、たとえば１５秒が経過すると閉じられる。
サーバ１４は、テストパケットを受信してから５０秒後にレスポンスパケットをクライアントに送信する。レスポンスパケットには、テスト開始パケットの受信からの経過時間を示す時間情報つまり“５０秒”が記述される。
このとき既にレスポンス待ちポートは閉じられており、このため、５０秒後に送信されたレスポンスパケットは、ルータ１６において破棄され、Ｗｅｂカメラ１２は、レスポンスパケットを受信することができない。
そこでＷｅｂカメラ１２は、前回のテストパケットの送信から６５秒が経過したとき、次のテストパケットをサーバ１４に送信する。送信されたテストパケットは、ルータ１６で上記と同様の処理を施された後、サーバ１４によって受信される。サーバ１４は、テストパケットを受信してから４０秒後にレスポンスパケット“４０秒”をクライアントに送信する。
しかし、このときも既にレスポンス待ちポートは閉じられており、このため、レスポンスパケット“４０秒”は、ルータ１６において破棄され、Ｗｅｂカメラ１２は、レスポンスパケットを受信することができない。
そこでＷｅｂカメラ１２はさらに、前回のテストパケットの送信から６５秒が経過したとき、その次のテストパケットをサーバ１４に送信する。つまり、Ｗｅｂカメラ１２は、レスポンスパケットを受信できない期間、６５秒毎にテストパケットを送信する。
こうして６５秒毎に送られてくるテストパケットに応じ、サーバ１４は、応答までの待ち時間を毎回１０秒ずつ短縮しながら、つまり受信から３０秒後，２０秒後，…に、レスポンスパケット“３０秒”，レスポンスパケット“２０秒”，…を送信する。
このため、応答までの待ち時間（これをｓ秒とする）がポート開放時間を下回った時点で、Ｗｅｂカメラ１２は、レスポンスパケットを受信することができる。Ｗｅｂカメラ１２は、受信されたレスポンスパケットから時間情報“ｓ秒”を抽出し、抽出された時間情報“ｓ秒”をレジスタ“Ｔ”に記録する。たとえばレスポンス待ちポートの開放時間が１５秒である場合、レスポンスパケット“１０秒”がＷｅｂカメラ１２に到達し、レジスタ“Ｔ”に“１０秒”が記録される。
かくしてレジスタ“Ｔ”に時間情報“ｓ秒”が記録されると、Ｗｅｂカメラ１２は、テスト終了パケットを送信し、このテスト終了パケットを受信したサーバ１４では、最適送信間隔算出に関わる処理が終了される。
図５のステップＳ３１に示された最適間隔（Ｔ）算出処理は、図１２のサブルーチンに従って実行される。図１２を参照して、ステップＳ１５１では、ＵＤＰに従うテスト開始パケットをサーバ宛に送信する。ステップＳ１５３では、タイマをリセットおよびスタートし、その後、ステップＳ１５５およびＳ１５７のループに入る。ステップＳ１５５では、レスポンスパケットが受信されたか否かを判別し、ステップＳ１５７では、所定時間たとえば６５秒が経過したか否かを判別する。
６５秒以内にレスポンスパケットが受信されれば、ステップＳ１５５でＹＥＳと判別され、ステップＳ１５９に移る。ステップＳ１５９では、受信されたレスポンスパケットから時間情報（ｓ）を抽出し、ステップＳ１６１では、抽出された時間情報（ｓ）をレジスタ“Ｔ”にセットする。そしてステップＳ１６３で、ＵＤＰに従うテスト終了パケットをサーバ１４宛に送信し、その後、上位層のルーチンに復帰する。
６５秒が経過してもレスポンスパケットが受信されなければ、ステップＳ１５７でＹＥＳと判別され、ステップＳ１６５に移る。ステップＳ１６５では、テストパケットをサーバ１４宛に送信し、その後、ステップＳ１５３に戻る。
図１３を参照して、ステップＳ１７１〜Ｓ１８１は、図９に示されたステップＳ１０１〜Ｓ１１１と同じ処理であり、説明を省略する。テスト開始パケットが受信されると、ステップＳ１７３でＹＥＳと判別し、ステップＳ１８３に移る。ステップＳ１８３では、時間情報（ｓ）を初期化する。具体的には、変数ｓに“６０”をセットする。そして、ステップＳ１８５でタイマをリセットおよびスタートし、ステップＳ１８７およびＳ１８９のループに入る。ステップＳ１８７では、テスト開始パケットの受信からｓ秒が経過したか否かをタイマによって判別し、ステップＳ１８９では、テスト終了パケットが受信されたか否かを判別する。
テスト開始パケットの受信からｓ秒が経過すると、まずステップＳ１９１でレスポンスパケットに変数ｓの値を埋め込み、次にステップＳ１９３でレスポンスパケットをＵＤＰに従ってクライアント宛に送信し、そしてステップＳ１９５で変数ｓから“１０”を減算する。その後、ステップＳ１８５に戻る。
テスト開始パケットの受信からｓ秒以内にテスト終了パケットが受信されると、ステップＳ１７１およびＳ１７３のループに戻る。
以上から明らかなように、この実施例では、前述の実施例と同様、Ｗｅｂカメラ１２は、ルータ１６のタイプに関係なく、サーバ１４から任意のタイミングでコマンドを受け付けることができる。
加えて、Ｗｅｂカメラ１２は、ルータ１６がＵＰｎＰ非対応タイプのとき、応答タイミングを短縮方向に毎回更新しながらの応答を要求するテストパケットをルータ１６を通してサーバ１４に繰り返し返送する。換言すれば、Ｗｅｂカメラ１２がルータ１６に向けてテストパケットのサーバ１４への送信依頼を繰り返し発行し、１つ１つの送信依頼に応じてルータ１６がサーバ１４にテストパケットを送信する。すると、ルータ１６においてレスポンス待ちポートが一時的に開放され、サーバ１４は、テストパケットに応答してレスポンスパケットを返送する。応答タイミングは、テストパケットを受信する度に段々早められる。その際サーバ１４は、返送するレスポンスパケットにテストパケットの受信から返送までの待ち時間を示す時間情報を添付する。
当初、レスポンスパケットはレスポンス待ちポートが閉鎖されるよりも遅いタイミングで返送されるため、Ｗｅｂカメラ１２はレスポンスパケットを受信することができない。応答タイミングがレスポンス待ちポートの閉鎖よりも早いタイミングにまで短縮されると、Ｗｅｂカメラ１２はレスポンスパケットを受信できるようになる。そこで、最初に受信されたレスポンスパケットに添付の時間情報の示す時間を送信要求の発行周期（＝最適送信周期Ｔ）とする。
Ｗｅｂカメラ１２は、こうして決定される周期、つまりルータ１６が送信依頼に応じてレスポンス待ちポートを開放させる期間（ポート開放期間）を超えない最も長い周期、換言すればポート開放期間に等しいかまたはそれよりもわずかに短い周期で、ルータ１６に向けて送信依頼を繰り返し発行する。これにより、インターネット２０やＬＡＮなどの通信回線への負荷を最小限に抑えながら、レスポンス待ちポートが継続的に開放された状態を作り出すことができる。
なお、この実施例では、サーバ１４側がレスポンスパケットに時間情報を添付し、Ｗｅｂカメラ１２は、最初に受信されたレスポンスパケットに添付の時間情報が示す時間を情報送信要求の発行周期としたが、代わりに、Ｗｅｂカメラ１２自身がテストパケットを最後に送信してからレスポンスパケットを最初に受信するまでの経過時間を計測し、計測結果を情報送信要求の発行周期としてもよい。
次に、その他の実施例を説明する。前述の図１１〜図１３実施例では、レスポンスパケットの返送タイミングはサーバ１４が決定した（ステップＳ１８３およびＳ１９５を参照）が、この実施例では、クライアント側（Ｗｅｂカメラ１２）がこれを決定する。
この実施例におけるクライアント側の最適送信間隔（Ｔ）算出処理を図１４に示し、また、この実施例におけるサーバ１４のＵＤＰパケット処理タスクを図１５に示す。クライアント・サーバ間で行われる通信処理自体は前実施例と同様であり、図１１を援用する。
まず図１１を参照して、クライアント側からサーバ１４に送信されるテストパケットには、クライアント側で決定された返送タイミング（ｓ＝６０秒，５０秒，…，ｓ＋１０秒，ｓ秒）を示す時間情報が含められる。サーバ１４は、テストパケットに含まれる時間情報に従うタイミングでレスポンスパケットを返送する。レスポンスパケットには、テストパケットの受信から返送までの経過時間を示す時間情報、つまりテストパケットに含まれるものと同じ時間情報（６０秒，５０秒，…，ｓ＋１０秒，ｓ秒）が記述される。ただし、この実施例では、クライアント側で返送タイミングを決定しているので、サーバ１４がレスポンスパケットに時間情報を記述する処理は省略してもよい。
図１４のクライアントによる最適間隔算出処理は、図１２のそれにおいて、ステップＳ１５０およびＳ１６４をさらに含んでいる。図１５のサーバ１４によるＵＤＰパケット処理タスクは、図１３のそれにおいて、ステップＳ１７９およびＳ１９１が削除されている。図１４に追加されたステップＳ１５０およびＳ１６４は、図１３から削除されたステップＳ１７９およびＳ１９１に対応する。
図１４を参照して、まずステップＳ１５０で時間情報（ｓ）を初期化する。具体的には、変数ｓに“６０”をセットする。次のステップＳ１５１では、時間情報（ｓ）を含むテスト開始パケットを送信する。続くステップＳ１５３〜Ｓ１５７は、図１２のステップＳ１５３〜Ｓ１５７と同様であり、説明を省略する。ステップＳ１５７の判別結果がＹＥＳであれば、ステップＳ１６４で変数ｓから“１０”を減算し、次のステップ１６５では、時間情報（ｓ）を含むテスト開始パケットを送信する。
図１５を参照して、ステップＳ１７１〜Ｓ１８１は、図１３のステップＳ１７１〜Ｓ１８１と同様であり、説明を省略する。ステップＳ１７３の判別結果がＹＥＳであれば、ステップＳ１８５に移って、タイマをリセットおよびスタートする。続くステップＳ１８７〜Ｓ１９３は、図１３のステップＳ１８７〜Ｓ１９３と同様であり、説明を省略する。そして、ステップＳ１９３の実行後、ステップＳ１８５に戻る。
この実施例によれば、前述の図１１〜図１３実施例と同様の効果に加え、次のような効果が得られる。すなわち、クライアント側がレスポンスパケットの返送タイミングを指定するので、クライアント数が多い場合特に、サーバ１４の処理負荷を軽減することができる。
なお、この実施例では、レスポンスパケットの応答タイミングを短縮方向に変化させた（ステップＳ１６４を参照）が、延長方向に変化させてもよい。以下、レスポンスパケットの応答タイミングを延長方向に変化させる実施例を図１６および図１７により説明する。
図１６を参照して、クライアント側（Ｗｅｂカメラ１２）からサーバ１４に送信されるテストパケットには、クライアント側で決定された返送タイミング（ｓ＝５秒，１５秒，…，ｓ秒，ｓ＋１０秒）を示す時間情報が含められる。サーバ１４は、テストパケットに含まれる時間情報に従うタイミングでレスポンスパケットを返送する。レスポンスパケットには、テストパケットの受信から返送までの経過時間を示す時間情報つまりテストパケットに含まれるものと同じ時間情報（５秒，１５秒，…，ｓ秒，ｓ＋１０秒）が記述される。なお、この実施例では、クライアント側が返送タイミングを決定しているので、サーバ１４がレスポンスパケットに時間情報を記述する処理は省略してもよい。
返送までも待ち時間がポート開放時間を上回った時点で、Ｗｅｂカメラ１２は、レスポンスパケットを受信することができなくなる。このため、Ｗｅｂカメラ１２のレジスタＴには、最後に受信されたレスポンスパケットから抽出された時間情報“ｓ秒”が保持されることとなる。
Ｗｅｂカメラ１２のＣＰＵ２８は、図１７に示す手順に従って最適送信間隔（Ｔ）を算出する。図１７を参照して、まずステップＳ２０１で時間情報（ｓ）を初期化する。具体的には、変数ｓに“５”をセットする。次のステップＳ２０３では、時間情報（ｓ）を含むテスト開始パケットを送信する。ステップＳ２０５〜Ｓ２１３は、図１４のステップＳ１５３〜Ｓ１５９と同様であり、説明を省略する。
ステップＳ２１５では、変数ｓに“１０”を加算し、次のステップＳ２１７では、時間情報（ｓ）を含むテスト開始パケットを送信する。その後、ステップＳ２０５に戻る。
ステップＳ２０９でＹＥＳと判別されると、ステップＳ２１９に移り、テスト終了パケットをサーバ１４宛に送信する。その後、上位層のルーチンに復帰する。
この実施例によれば、前述の図１１〜図１３実施例と同様の効果に加え、次のような効果が得られる。すなわち、クライアント側がレスポンスパケットの返送タイミングを指定するので、クライアント数が多い場合特に、サーバ１４の処理負荷を軽減することができる。
なお、この実施例ではクライアント側（Ｗｅｂカメラ１２）がレスポンスパケットの返送タイミングを決定したが、レスポンスパケットの返送タイミングは、サーバ１４で決定することも可能である。返送タイミングの決定をサーバ１４で行う場合、図１７に示される最適送信間隔算出処理からは、ステップＳ２０１およびＳ２１５が削除される。一方、図１５に示されるサーバ１４のＵＤＰパケット処理タスクには、削除されたステップＳ２０１に対応するステップ（Ｓ１８３ａ；図示せず）がステップＳ１７３の直後に追加され、かつ削除されたステップＳ２１５に対応するステップ（Ｓ１９５ａ；図示せず）がステップＳ１９３の直後に追加される。
また、この実施例では、応答タイミングを一定幅（＝１０）で延長方向に更新していき、最後に受信されたレスポンスパケットに記述されている時間情報（ｓ）を最適送信間隔（Ｔ）に決定したが、レスポンスパケットの未着状態が所定時間継続したとき、応答タイミングの更新幅を当初の半分（＝５）に縮小する方法もある。以下、レスポンスパケットの未着状態が所定時間継続したときに応答タイミングの更新幅を縮小する実施例を図１８〜図２０により説明する。
図１８を参照して、クライアントは、レスポンスパケット“ｓ＋１０秒”の未着を受け、時間情報“ｓ＋５秒”を含むテストパケットを送信する。これに対するレスポンスパケット“ｓ＋５秒”を受信すれば、このレスポンスパケットから抽出された時間情報“ｓ＋５秒”が、Ｗｅｂカメラ１２のレジスタＴに記録される。レスポンスパケット“ｓ＋５秒”を受信しなければ、先に受信されたレスポンスパケットから抽出された時間情報“ｓ秒”がレジスタＴに保持されたままとなる。
なお、上記のレスポンスパケット“ｓ＋５秒”が未着の場合、更新幅をさらに縮小した時間情報、たとえば更新幅を当初の４分の１（＝２．５）に縮小した時間情報を含むテストパケットをさらに送信してもよい。
クライアント（Ｗｅｂカメラ１２のＣＰＵ２８）は、図１９および図２０に示す手順で最適送信間隔（Ｔ）を算出する。図１９を参照して、ステップＳ２０１〜Ｓ２１９は、図１７のステップＳ２０１〜Ｓ２１９と同様なので、説明を省略する。ステップＳ２０９でＹＥＳと判別されると、ステップＳ２１８ａに移り、変数ｓに“５”を加算する。ステップＳ２１８ｂでは、時間情報（ｓ）を含むテストパケットをサーバ１４宛に送信する。ステップＳ２１８ｃでは、タイマをリセットおよびスタートし、その後、ステップＳ２１８ｄおよびＳ２１８ｅのループに入る。
図２０を参照して、ステップＳ２１８ｄでは、レスポンスパケットが受信されたか否かを判別し、ステップＳ２１８ｅでは、所定時間たとえば６５秒が経過したか否かを判別する。
６５秒以内にレスポンスパケットが受信されれば、ステップＳ２１８ｄでＹＥＳと判別され、ステップＳ２１８ｆに移る。ステップＳ２１８ｆでは、受信されたレスポンスパケットから時間情報（ｓ）を抽出し、ステップＳ２１８ｇでは、抽出された時間情報（ｓ）をレジスタ“Ｔ”にセットする。そして、ステップＳ２１９に進む。
６５秒が経過してもレスポンスパケットが受信されなければ、ステップＳ２１８ｅでＹＥＳと判別され、ステップＳ２１９に移る。ステップＳ２１９では、テスト終了パケットをサーバ１４宛に送信し、その後、上位層のルーチンに復帰する。
この実施例によれば、レスポンスパケットの未着状態が所定時間継続したときに、応答タイミングの更新幅を縮小したテストパケットを送信することによって、最適送信間隔の算出精度を向上させることができる。
これに関連して、図１１〜図１３実施例ならびに図１４および図１５実施例においては、応答タイミングを一定幅（＝１０）で短縮方向に更新していき、最初に受信されたレスポンスパケットに記述されている時間情報（ｓ）を最適送信間隔（Ｔ）に決定したが、レスポンスパケットが最初に受信されたときに、応答タイミングの更新幅を当初の半分（＝５）に縮小する方法もある。以下、レスポンスパケットが最初に受信されたときに応答タイミングの更新幅を縮小する実施例を図２１〜図２３により説明する。
図２１を参照して、クライアントは、レスポンスパケット“ｓ秒”の到着を受け、時間情報“ｓ＋５秒”を含むテストパケットを送信する。これに対するレスポンスパケット“ｓ＋５秒”を受信すれば、このレスポンスパケットから抽出された時間情報“ｓ＋５秒”がレジスタＴに記録される。レスポンスパケット“ｓ＋５秒”を受信しなければ、先に受信されたレスポンスパケットから抽出された時間情報“ｓ秒”がレジスタＴに保持されたままとなる。
なお、上記のレスポンスパケット“ｓ＋５秒”が受信された場合、更新幅をさらに縮小した時間情報、たとえば更新幅を当初の４分の１（＝２．５）に縮小した時間情報を含むテストパケットをさらに送信してもよい。
クライアント（Ｗｅｂカメラ１２のＣＰＵ２８）は、図２２および図２３に示す手順で最適送信間隔（Ｔ）を算出する。図２２を参照して、ステップＳ１５０〜Ｓ１６１は、図１４のステップＳ１５０〜Ｓ１６１と同様なので、説明を省略する。ステップＳ１６１に続くステップＳ１６２ａでは、変数ｓから“５”を減算する。ステップＳ１６２ｂでは、時間情報（ｓ）を含むテストパケットをサーバ１４宛に送信する。ステップＳ１６２ｃでは、タイマをリセットおよびスタートし、その後、ステップＳ１６２ｄおよびＳ１６２ｅのループに入る。
図２３を参照して、ステップＳ１６２ｄでは、レスポンスパケットが受信されたか否かを判別し、ステップＳ１６２ｅでは、所定時間たとえば６５秒が経過したか否かを判別する。
６５秒以内にレスポンスパケットが受信されれば、ステップＳ１６２ｄでＹＥＳと判別され、ステップＳ１６２ｆに移る。ステップＳ１６２ｆでは、受信されたレスポンスパケットから時間情報（ｓ）を抽出し、ステップＳ１６２ｇでは、抽出された時間情報（ｓ）をレジスタ“Ｔ”にセットする。そして、ステップＳ１６３に進む。
６５秒が経過してもレスポンスパケットが受信されなければ、ステップＳ１６２ｅでＹＥＳと判別され、ステップＳ１６３に移る。ステップＳ１６３では、テスト終了パケットをサーバ１４宛に送信し、その後、上位層のルーチンに復帰する。
この実施例によれば、レスポンスパケットが最初に受信されたときに、応答タイミングの更新幅を縮小したテストパケットを送信することによって、最適送信間隔の算出精度を向上させることができる。
以上では、Ｗｅｂカメラ１２およびサーバ１４からなる監視カメラシステム１０について説明したが、この発明は、外部サーバと外部サーバからルータを通して通知されるコマンドに従う処理を実行するコマンド処理装置とからなるあらゆる処理システムに適用することができる。
この発明が詳細に説明され図示されたが、それは単なる図解および一例として用いたものであり、限定であると解されるべきではないことは明らかであり、この発明の精神および範囲は添付された特許請求の範囲の文言によってのみ限定される。

Claims (15)

1. 送信依頼が発行されたとき依頼に従う送信処理を行いかつ受信ポートを一時的に開放するルータと接続される通信端末であって、次のものを備える：
   繰り返し応答を要求する要求信号の外部サーバへの送信を依頼する送信依頼を前記ルータに向けて発行する第１発行手段；
   前記第１発行手段によって発行された送信依頼に対する前記外部サーバからの応答信号を前記受信ポートを通して受信する受信手段；および
   前記受信手段の受信結果に基づいて送信依頼の発行周期を決定する決定手段。
2. 請求項１に従属する通信端末であって、前記応答信号は依頼受信時刻から応答送信時刻までの時間を示す時間情報を含み、前記決定手段は前記受信手段によって最後に受信された応答信号に含まれる時間情報に基づいて前記発行周期を決定する。
3. 請求項１に従属する通信端末であって、繰り返し応答の停止を要求する要求信号の前記外部サーバへの送信を依頼する送信依頼を前記決定手段による決定の後に前記ルータに向けて発行する第２発行手段をさらに備える。
4. 請求項１に従属する通信端末であって、前記外部サーバとの間の通信路が切断されたとき前記第１発行手段の発行動作を停止させる停止手段をさらに備える。
5. 送信依頼が発行されたとき依頼に従う送信処理を行いかつ受信ポートを一時的に開放するルータと接続される通信端末であって、次のものを備える：
   互いに異なるタイミングでの応答を要求する要求信号の外部サーバへの送信を依頼する送信依頼を前記ルータに向けて繰り返し発行する第１発行手段；
   前記第１発行手段によって発行された送信依頼に対する前記外部サーバからの応答信号を前記受信ポートを通して受信する受信手段；および
   前記受信手段の受信結果に基づいて送信依頼の発行周期を決定する決定手段。
6. 請求項５に従属する通信端末であって、前記要求信号によって要求される応答タイミングを延長方向および短縮方向のいずれか一方に向けて更新する更新手段をさらに備える。
7. 請求項６に従属する通信端末であって、前記更新手段による更新方向は前記延長方向であり、前記決定手段は前記受信手段によって最後に受信された応答信号に基づいて前記発行周期を決定する。
8. 請求項７に従属する通信端末であって、前記受信手段によって応答信号が受信されない状態が所定時間継続したとき前記更新手段の更新幅を縮小する縮小手段をさらに備える。
9. 請求項６に従属する通信端末であって、前記更新手段による更新方向は前記短縮方向であり、前記決定手段は前記受信手段によって最初に受信された応答信号に基づいて前記発行周期を決定する。
10. 請求項９に従属する通信端末であって、前記受信手段によって応答信号が最初に受信されたとき前記更新手段の更新幅を縮小する縮小手段をさらに備える。
11. 請求項５に従属する通信端末であって、前記応答信号は依頼受信時刻から応答送信時刻までの時間を示す時間情報を含み、前記決定手段は前記時間情報に基づいて前記発行周期を決定する。
12. 請求項５に従属する通信端末であって、応答停止を要求する要求信号の前記外部サーバへの送信を依頼する送信依頼を前記決定手段による決定の後に前記ルータに向けて発行する第２発行手段をさらに備える。
13. 請求項５に従属する通信端末であって、前記外部サーバとの間の通信路が切断されたとき前記第１発行手段の発行動作を停止させる停止手段をさらに備える。
14. 送信依頼が発行されたとき依頼に従う送信処理を行いかつ受信ポートを一時的に開放するルータと接続される通信端末のプロセサによって実行される制御プログラムであって、次のものを備える：
    繰り返し応答を要求する要求信号の外部サーバへの送信を依頼する送信依頼を前記ルータに向けて発行する第１発行ステップ；
    前記第１発行ステップによって発行された送信依頼に対する前記外部サーバからの応答信号を前記受信ポートを通して受信する受信ステップ；および
    前記受信ステップの受信結果に基づいて送信依頼の発行周期を決定する決定ステップ。
15. 送信依頼が発行されたとき依頼に従う送信処理を行いかつ受信ポートを一時的に開放するルータと接続される通信端末のプロセサによって実行される制御プログラムであって、次のものを備える：
    互いに異なるタイミングでの応答を要求する要求信号の外部サーバへの送信を依頼する送信依頼を前記ルータに向けて繰り返し発行する第１発行ステップ；
    前記第１発行ステップによって発行された送信依頼に対する前記外部サーバからの応答信号を前記受信ポートを通して受信する受信ステップ；および
    前記受信ステップの受信結果に基づいて送信依頼の発行周期を決定する決定ステップ。

Images