JP2002328886A

JP2002328886A - 遠隔操作システム、遠隔操作方法、被操作装置、操作端末、プログラムおよび記憶媒体

Info

Publication number: JP2002328886A
Application number: JP2001132794A
Authority: JP
Inventors: Hisao Nakagawa; 久雄中川; Yoichi Kamei; 洋一亀井; Tadashi Yamakawa; 正山川
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2001-04-27
Filing date: 2001-04-27
Publication date: 2002-11-15

Abstract

(57)【要約】【課題】ファイアウォールの内部に被操作装置を設置
しても、操作端末からファイアウォールを越えて操作で
きる遠隔操作システムを提供する。【解決手段】遠隔操作システムでは、被操作装置１２
０の状態情報および操作端末１３０に入力された操作情
報を交換し、操作端末１３０から被操作装置１２０を操
作する際、被操作装置１２０は、操作端末１３０への通
信コネクションを発動し、被操作装置１２０の状態情報
を通知すると、操作端末１３０は、通知された状態情報
を表示するとともに、その受信応答を、即座に被操作装
置１２０に返す。また、被操作装置１２０は、操作端末
１３０への通信コネクションを発動し、操作情報を要求
すると、操作端末１３０は、所定時間だけ操作の入力を
待機し、操作が発生した場合、連続する操作を監視し、
複数の操作が発生した場合、複数の操作をまとめた操作
情報を被操作装置１２０に返す。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、操作端末を用いて
遠隔から機器を操作する遠隔操作システム、遠隔操作方
法、被操作装置、操作端末、プログラムおよび記憶媒体
に関する。

【０００２】

【従来の技術】従来、ネットワークを介して機器と操作
端末を結ぶ遠隔操作システムが知られている。このよう
な遠隔操作システムでは、ＬＡＮやインターネットの普
及と共に、計算機やネットワーク機器だけでなく、種々
の機器をネットワークに接続し、ネットワークを介して
情報を取得したり、制御することが普及しつつある。例
えば、遠隔地の温度計を読み取ったり、ビデオカメラの
雲台を制御することが挙げられる。

【０００３】このような遠隔操作システムは、操作対象
の機器と操作する機器との双方がネットワークに接続さ
れ、所定の通信プロトコルで通信することによって実現
される。

【０００４】しかし、操作対象機器と操作用機器とが通
信できない場合がある。多くの組織が自組織のＬＡＮを
インターネットに接続する場合、ファイアウォールと称
される通信の制限手段をその接続点に設けることが行わ
れている。この制限手段は、ＬＡＮをインターネット上
の悪意の利用者から守るためであるが、同時にＬＡＮ上
の正当な利用者のインターネット利用も妨げてしまう場
合もある。

【０００５】例えば、ファイアウォールの実現手段の１
つとして、ＬＡＮとインターネットとの間で特定の条
件、例えば、通信プロトコル、送信元、送信先を満たし
た通信パケットだけを通過させるように制限することが
広く行われている。

【０００６】また、サーバ／クライアントモデルとスト
リーム型通信プロトコル（ＴＣＰ／ＩＰ）の特性に基づ
き、ＬＡＮ内のクライアントが通信要求を発し、インタ
ーネット上のサーバを利用できるようにしているが、逆
にＬＡＮ上のサーバに対してインターネットから通信要
求を伝えることができないようにすることが一般的であ
る。

【０００７】したがって、ＬＡＮの一般利用者は、イン
ターネットからの通信要求を受けるサーバをＬＡＮ内に
置くことは、通常できない。

【０００８】さらに、ファイアウォールでは、ＬＡＮと
インターネットとの間で通信パケットをＯＳレベルで
（通信プロトコルスタックで）中継しないように制限す
ることも行われる。この場合、安全性は高まるが、イン
ターネットからＬＡＮ方向だけでなく、ＬＡＮからイン
ターネットへ出ていく通信パケットもファイアウォール
を通過できなくなる。

【０００９】そこで、アプリケーションレベルのプログ
ラムで通信パケット全体ではなく通信すべきデータのみ
を中継するようにし、必要なデータの通信を実現するこ
とが行われている。代表的な中継プログラムとして、Ｗ
ＷＷ（ＷｏｒｌｄＷｉｄｅＷｅｂ）のデータを中継す
るプロキシサーバが知られており、多くのファイアウォ
ール上でサービスが提供されている。しかし、全てのア
プリケーションプロトコルに対して中継プログラムが用
意されているわけではない。したがって、ＬＡＮの一般
利用者は全てのアプリケーションプロトコルを利用でき
るとは限らない。

【００１０】このように、ファイアウォールが機器間に
存在する場合、操作対象機器と操作機器との間の通信
は、一般に制約されることが多い。機器のネットワーク
の接続先が制限されたり、遠隔操作用の通信プロトコル
がファイアウォールを通過できなかったりすることがあ
る。これに対し、ファイアウォールの設定を変えること
で制約を取り除くことは可能であるが、ファイアウォー
ルの安全性を弱めるので、一般的に認められないことが
多い。

【００１１】また、ファイアウォール管理者への依頼事
務手続きが煩雑であったり、管理者が多忙で頻繁な変更
には応じられないという場合も多く、ファイアウォール
の設定を変えることは避けられている。

【００１２】そこで、独自の通信プロトコルを使用する
のではなく、ファイアウォールを通過できるように設定
されていることの多い、ＷＷＷの通信プロトコルである
ＨＴＴＰ（ＨｙｐｅｒＴｅｘｔＴｒａｎｓｆｅｒ
Ｐｒｏｔｏｃｏｌ）を用いる方法が提案されている。即
ち、独自のプロトコルをＨＴＴＰのメソッドやデータに
変換したり、独自のプロトコルを埋め込んでＨＴＴＰと
してファイアウォールを通過させ、独自プロトコルのコ
マンドやデータに再構成する。これは、機器操作に限ら
ず、音声や動画等の連続データのファイアウォール通過
にも広く用いられている。

【００１３】ところで、ＨＴＴＰは、前述したストリー
ム型通信プロトコル（ＴＣＰ／ＩＰ）上にサーバ／クラ
イアントモデルのアプリケーションプロトコルを構築し
たものであるが、クライアントからのリクエストとサー
バからのレスポンスの１往復の通信が基本となってい
る。

【００１４】当初のプロトコルでは、この１往復の通信
を１つのストリーム型通信コネクションに割り当ててお
り、１つのリクエスト毎にストリーム型コネクションを
確立する必要があり、そのオーバヘッドが大きかった。

【００１５】そこで、現在のプロトコルでは、持続的コ
ネクション（ｐｅｒｓｉｓｔｅｎｔｃｏｎｎｅｃｔｉｏ
ｎ）が規定され、１つの通信コネクションを複数往復分
のリクエスト・レスポンス交換に割り当てられるように
なっている。さらに、レスポンスが返る前に続けてリク
エストを送るパイプライン処理も規定されている。

【００１６】

【発明が解決しようとする課題】このように、ＨＴＴＰ
の通信の枠組みを利用することで、ファイアウォール内
部のＬＡＮに接続された操作用機器からインターネット
上の操作対象機器への通信・制御は可能になる。

【００１７】しかしながら、逆方向、つまりインターネ
ット上の操作用機器からＬＡＮに接続された操作対象機
器への通信・制御のための通信要求がファイアウォール
を通過できないという問題が依然として残っていた。

【００１８】これに対し、内部の機器から外部の機器に
向けて、一定間隔で継続して接続要求を行い、外部の機
器は接続を行う時だけ、これに応答する、いわゆるポー
リング方式を利用することが考えられる。ポーリング方
式は、例えば、ファクシミリ情報サービスにＦＡＸメッ
セージ受信を要求するといった場合に利用される。

【００１９】しかし、遠隔操作のような場合、ＦＡＸ受
信の場合と違い、即時応答性が重要となる。また、外部
からの操作は不定期であり、内部の機器側では、外部か
らの操作がいつ行われるかを予測できないことに加え、
複数の操作要求が行われることが予想されるので、頻繁
に接続要求を行う必要があった。

【００２０】したがって、ポーリング方式を用い、遠隔
操作のような即時応答性を重要視した通信を行う際、常
に通信トラフィックが発生し、かつそのうちの殆どが無
駄なトラフィックとなり得るという問題を抱えていた。

【００２１】さらに、この問題を解決する過程で、持続
的コネクションを用いて通信コネクション確立までの遅
延時間を減少させることが考えられるが、機器間のＨＴ
ＴＰデータを中継するプロキシサーバで設定される持続
的コネクションの切断タイムアウト時間が、利用者の機
器操作や機器の状態変化の間隔に比べて一般に短いの
で、操作や状態変化によって通信の必要が発生した時に
は、既に持続的コネクションが切断されており、持続的
コネクションの効果が得られない場合がある。

【００２２】持続的コネクションの効果を最大限に活か
すためには、タイムアウトにより切断されないようにダ
ミーの通信を行えばよいが、利用者の機器操作や機器の
状態変化の間隔が長い場合、ダミーの通信量が増加する
という問題があった。

【００２３】そこで、本発明は、ファイアウォールの内
部に操作対象機器（被操作装置）を設置しても、インタ
ーネットに接続された操作端末からファイアウォールを
越えて操作できる遠隔操作システム、遠隔操作方法、被
操作装置、操作端末、プログラムおよび記憶媒体を提供
することを目的とする。

【００２４】

【課題を解決するための手段】上記目的を達成するため
に、本発明の遠隔操作システムは、ネットワークを介し
て被操作装置および操作端末が接続され、前記操作端末
で作成された操作情報を用いて前記被操作装置を操作す
る遠隔操作システムであって、前記被操作装置は、前記
操作端末への通信を発動し、前記操作情報を前記操作端
末に要求する操作情報要求手段を備え、前記操作端末
は、前記発動された通信に応じ、所定時間だけ操作の発
生を待機し、該操作が発生した場合、連続する操作を監
視した後、前記要求された操作情報を前記被操作装置に
返す操作情報応答手段を備えたことを特徴とする。

【００２５】また、前記操作情報応答手段は、前記連続
する操作を監視した結果、複数の操作が発生した場合、
該複数の操作に相当する前記操作情報をまとめて返すこ
とを特徴とする。

【００２６】さらに、前記操作情報応答手段は、前記発
生した操作の優先度が所定値より高い場合、前記連続す
る操作を監視することなく、前記操作情報を返すことを
特徴とする。

【００２７】また、前記被操作装置は、前記操作情報の
要求とは別に、前記操作端末への通信を発動し、該被操
作装置の状態情報を前記操作端末に通知する状態情報通
知手段を備え、前記操作端末は、前記発動された通信に
応じ、待機することなく、前記通知された状態情報の応
答を前記被操作装置に返す状態情報通知応答手段を備え
たことを特徴とする。

【００２８】さらに、前記操作情報要求手段は、前記操
作端末への通信を発動して前記被操作装置の状態情報を
通知するとともに、該通信を用いてその応答としての前
記操作情報を要求し、前記操作情報応答手段は、前記通
知された状態情報の応答として、前記通信を用いて前記
要求された操作情報を返すことを特徴とする。

【００２９】本発明の遠隔操作方法は、操作端末で作成
された操作情報を用い、ネットワークを介して被操作装
置を操作する遠隔操作方法であって、前記被操作装置か
ら前記操作端末へ通信を発動し、前記操作情報を前記操
作端末に要求する操作情報要求工程と、前記発動された
通信に応じ、所定時間だけ操作の発生を待機し、該操作
が発生した場合、連続する操作を監視した後、前記操作
端末から前記要求された操作情報を前記被操作装置に返
す操作情報応答工程とを有することを特徴とする。

【００３０】また、前記操作情報応答工程では、前記連
続する操作を監視した結果、複数の操作が発生した場
合、該複数の操作に相当する前記操作情報をまとめて返
すことを特徴とする。

【００３１】さらに、前記操作情報応答手段は、前記発
生した操作の優先度が所定値より高い場合、前記連続す
る操作を監視することなく、前記操作情報を返すことを
特徴とする。

【００３２】本発明の被操作装置は、ネットワークに接
続された操作端末から操作される被操作装置であって、
前記操作端末への通信を発動し、状態情報を通知する状
態情報通知手段と、前記操作端末への通信を発動し、操
作情報を要求する操作情報要求手段とを備え、前記操作
端末は、前記被操作装置からの通信の発動に応じ、前記
通知された状態情報の応答を待機することなく返す一
方、前記要求された操作情報を所定時間待機し、該操作
が発生した場合、連続する操作を監視した後、該監視の
結果、複数の操作が発生した場合、該複数の操作に相当
する前記操作情報をまとめて返すことを特徴とする。

【００３３】本発明の操作端末は、ネットワークに接続
された被操作装置を操作する操作端末であって、前記被
操作装置からの通信の発動に応じ、前記被操作装置から
通知された状態情報の応答を待機することなく前記被操
作装置に返す状態情報通知応答手段と、前記被操作装置
からの通信コネクションの発動に応じ、前記被操作装置
から要求された操作情報を、所定時間待機し、該操作が
発生した場合、連続する操作を監視した後、該監視の結
果、複数の操作が発生した場合、該複数の操作に相当す
る前記操作情報をまとめて前記被操作装置に返す操作情
報応答手段とを備えたことを特徴とする。

【００３４】

【発明の実施の形態】本発明の遠隔操作システム、遠隔
操作方法、被操作装置、操作端末、プログラムおよび記
憶媒体の実施の形態について図面を参照しながら説明す
る。

【００３５】［第１の実施形態］図１は第１の実施形態
における遠隔操作システムの構成を示す図である。図に
おいて、１００はインターネットである。インターネッ
ト１００には、ファイアウォール１１１を介してＬＡＮ
１１０、および操作端末１３０が接続されている。ま
た、ＬＡＮ１１０には、被操作装置１２０が接続されて
いる。ファイアウォール１１１には、プロキシサーバ１
１２が導入されている。

【００３６】被操作装置１２０は、ＣＰＵ、メモリ（Ｒ
ＯＭ、ＲＡＭ）およびネットワークインタフェースを有
するパーソナルコンピュータ、ワークステーションなど
のコンピュータと同等の機能を有する装置であり、後述
する状態通知プログラム１４１、操作データ収集プログ
ラム１４２および制御プログラム１４３を有する。ま
た、被操作装置１２０には、操作対象機器として、ＯＮ
／ＯＦＦが操作される照明１２２、および開閉位置が操
作されるブラインド１２３が接続されている。

【００３７】コントローラ１２１は、制御プログラム１
４３からの制御指令に応じて、照明１２２の点灯・消灯
を制御したり、ブラインド１２３の上げ下げを制御する
とともに、照明１２２の点灯状態やブラインド１２３の
開閉位置などの状態情報を状態通知プログラム１４１に
回答する。

【００３８】操作端末１３０は、被操作装置１２０と同
様、ＣＰＵ、メモリ（ＲＯＭ、ＲＡＭ）およびネットワ
ークインタフェースを有するパーソナルコンピュータ、
ワークステーションなどのコンピュータと同等の機能を
有する装置であり、後述するＨＴＴＰサーバプログラム
１５１、操作表示ＣＧＩプログラム１５２、操作ＣＧＩ
プログラム１５３、操作表示ＧＵＩプログラム１５４を
有する。操作端末１３０には、表示装置１３１、および
マウスなどの操作入力装置１３２が接続されている。

【００３９】操作端末１３０上で動作するＨＴＴＰサー
バプログラム１５１は、ＨＴＴＰリクエストに対する応
答、ＣＧＩ（ＣｏｍｍｏｎＧａｔｅｗａｙＩｎｔｅ
ｒｆａｃｅ）プログラムの実行など、一般的なＷＷＷサ
ーバ機能を有するプログラムである。そして、操作端末
１３０は、いわゆるＷＷＷサーバのように振る舞う。

【００４０】一方、被操作装置１２０では、状態通知プ
ログラム１４１および操作データ収集プログラム１４２
がＨＴＴＰサーバプログラム１５１にアクセスすること
により、操作端末１３０に向けて状態通知および操作デ
ータ収集依頼が行われる。操作表示ＧＵＩプログラム１
５４は、被操作装置１２０から送られた装置の状態を表
示装置１３１に表示し、利用者の操作対象機器に対する
操作を操作入力装置１３２から受け取り、被操作装置１
２０に送るためのＧＵＩを実現する。

【００４１】上記構成を有する遠隔操作システムの動作
を示す。図２は遠隔操作システムの動作シーケンスを示
す図である。図においては、状態通知サイクル、操作伝
達サイクルの２本の通信コネクションを使用し、操作対
象機器の状態通知および操作端末１３０からの操作情報
の収集が行われる。

【００４２】状態通知サイクルでは、被操作装置１２０
上の状態通知プログラム１４１が操作端末１３０上の操
作表示ＣＧＩプログラム１５２をアクセスすることで、
状態通知が行われる。例えば、被操作装置１２０が状態
情報Ｓ０、Ｓ１を操作端末１３０に通知すると、操作端
末１３０側では、送られた状態情報を基に操作画面の表
示が行われる。

【００４３】一方、操作伝達サイクルでは、被操作装置
１２０上の操作データ収集プログラム１４２が操作端末
１３０上の操作ＣＧＩプログラム１５３をアクセスする
ことで、被操作装置１２０から操作端末１３０に操作伝
達要求が行われる。例えば、操作伝達Ｅ０、Ｅ１を収集
すると、被操作装置１２０側では、収集した操作伝達情
報を基に操作対象機器の操作が行われる。これらの状態
通知サイクルおよび操作伝達サイクルは並列に動作す
る。

【００４４】図３は操作伝達サイクルの動作シーケンス
を示す図である。同図（Ａ）に示すように、操作端末１
３０側で操作Ｅ０が発生した時、操作伝達を行うと、直
後の操作Ｅ１の伝達に遅延が生じる。そこで、本実施形
態では、同図（Ｂ）に示すように、操作端末１３０側で
操作Ｅ０が発生した時、続く操作を少しの時間だけ待
ち、その間に操作Ｅ１が発生した場合、操作伝達Ｅ０＋
１としてまとめて操作情報を送るようにする。

【００４５】［状態通知プログラム１４１］つぎに、被
操作装置１２０における状態通知サイクルを示す。図４
は状態通知プログラム１４１の処理手順を示すフローチ
ャートである。この処理は、被操作装置１２０内のＣＰ
Ｕ（図示せず）が同じく被操作装置１２０内のＲＯＭ
（図示せず）に記憶された状態通知プログラム１４１を
実行することによって行われる。

【００４６】まず、操作対象機器に状態変化があるまで
待つ（ステップＳ３０１）。この処理は、例えば、制御
プログラム１４３が、操作対象機器に状態変化があった
とき、共有メモリ上に確保された状態変化フラグ（図示
せず）をＯＮにしておき、状態通知プログラム１４１
が、このフラグを監視し、状態変化を検知した場合、状
態変化フラグをＯＦＦにする処理である。尚、共有メモ
リの代わりにファイルを共有してもよいし、通信ポート
を利用し、それぞれのプログラム間でプロセス間通信を
行うことで情報を共有してもよい。

【００４７】ステップＳ３０１で状態変化があった場
合、照明１２２の点灯状態およびブラインド１２３の開
閉位置の状態情報を収集する（ステップＳ３０２）。こ
の処理は、コントローラ１２１の状態を入力する制御プ
ログラム１４３に対して情報入力要求を行うことによっ
て実現される。尚、制御プログラム１４３は、操作対象
機器に状態変化があった際、その状態情報を格納するバ
ッファを設け、状態通知プログラム１４１がこのバッフ
ァを監視することによって実現してもよい。

【００４８】ＨＴＴＰのＰＯＳＴコマンドを用いて、状
態情報に応じた送信情報を作成する（ステップＳ３０
３）。例えば、照明１２２がＯＦＦの状態であり、ブラ
インド１２３が７０％の開閉位置であり、操作端末１３
０における操作表示ＣＧＩプログラム１５２のＵＲＬが
ＨＴＴＰ：／／ｆｏｏ．ｂａｒ．ｃｏ．ｊｐ／ｃｇｉ−
ｂｉｎ／ｎｅｗｓｔａｔｕｓである場合、以下のような
コマンドを作成する。「ＰＯＳＴＨＴＴＰ：／／ｆｏｏ．ｂａｒ．ｃｏ．ｊ
ｐ／ｃｇｉ−ｂｉｎ／ｎｅｗｓｔａｔｕｓＨＴＴＰ／
１．０Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ：２１￥ｒ￥ｎｌｉｇｈｔ＝ＯＦＦ￥ｒ￥ｎｂｌｉｎｄ＝７０￥ｒ￥ｎ」そして、通信回線を確保し（ステップＳ３０４）、作成
された情報を、操作端末１３０のＨＴＴＰサーバプログ
ラム１５１に向けて送信する（ステップＳ３０５）。こ
のように、ストリーム指向の接続で、ファイアウォール
で守られた内部のＬＡＮからインターネット上への機器
に接続要求を行う場合、ファイアウォールの通過を認め
るように設定されることが多いので、通信が可能にな
る。ＨＴＴＰサーバプログラム１５１は、この情報を受
け取り、操作表示ＣＧＩプログラム１５２を呼び出す。
操作表示ＣＧＩプログラム１５２は、受け取った状態情
報を基に、操作対象機器の操作画面の更新を要求し、直
ちに応答を返す。この詳細については後述する。

【００４９】状態通知プログラム１４１は、この応答が
受信されるまで所定時間待つ（ステップＳ３０６、Ｓ３
０８）。所定時間待っても応答がない場合、エラーフラ
グをＯＮにセットする（ステップＳ３０７）。エラーフ
ラグがＯＮにセットされた場合、あるいは所定時間内に
操作表示ＣＧＩプログラム１５２からの応答が受信され
た場合、回線をクローズする（ステップＳ３０９）。

【００５０】そして、エラーフラグがＯＮにセットされ
たか否かを判別し（ステップＳ３１０）、エラーフラグ
がＯＮにセットされている場合、このプログラムを終了
し、そうでない場合、ステップＳ３０１に戻って再び状
態変化を待つ。

【００５１】［操作表示ＣＧＩプログラム１５２］つぎ
に、状態通知サイクルにおける操作端末１３０の処理を
示す。予め操作端末１３０上で動作しているＨＴＴＰサ
ーバプログラム１５１に対し、ＵＲＬパスである「／ｃ
ｇｉ−ｂｉｎ／ｎｅｗｓｔａｔｕｓ」が要求された場
合、操作表示ＣＧＩプログラム１５２が実行されるよう
に設定しておく。このため、上記要求を被操作装置１２
０から受け取ると、操作表示ＣＧＩプログラム１５２が
起動する。

【００５２】図５は操作表示ＣＧＩプログラム１５２の
処理手順を示すフローチャートである。この処理は、操
作端末１３０内のＣＰＵ（図示せず）が同じく操作端末
１３０内のＲＯＭ（図示せず）に格納された操作表示Ｃ
ＧＩプログラム１５２を実行することによって行われ
る。

【００５３】まず、被操作装置１２０から送られた状態
情報を読み込み、その情報を共有メモリ領域に確保した
情報交換テーブル４０１の中の状態欄に書き込む（ステ
ップＳ４０１）。図６は情報交換テーブル４０１を示す
図である。本実施形態では、照明がＯＦＦであり、ブラ
インド開閉位置が７０％であるので、状態欄のｌｉｇｈ
ｔ欄に「ＯＦＦ」、状態欄のｂｌｉｎｄ欄に「７０」が
書き込まれる。

【００５４】情報交換テーブル４０１は、操作表示ＧＵ
Ｉプログラム１５４から読み書き可能であり、この操作
表示ＧＵＩプログラム１５４に対し、操作表示更新要求
を行うことで操作画面が更新される。尚、共有メモリの
代わりにファイルを共有してもよいし、通信ポートを利
用し、それぞれのプログラム間でプロセス間通信を行
い、情報の共有を行ってもよい。また、操作表示ＧＵＩ
プログラム１５４を利用する代わりに、操作表示ＣＧＩ
プログラム１５２に操作画面の表示・更新機能を持たせ
てもよい。

【００５５】そして、ＡＣＫ応答情報を作成し、標準出
力に出力する（ステップＳ４０２）。ＨＴＴＰサーバプ
ログラム１５１によって被操作装置１２０の状態通知プ
ログラム１４１に応答が返される。例えば、以下のよう
な応答情報を標準出力に出力する。「Ｃｏｎｔｅｎｔ−Ｔｙｐｅ：ａｐｐｌｉｃａｔｉｏ
ｎ／ｘ−ｎｅｗｓｔａｔｕｓ￥ｒ￥ｎｏｋ￥ｒ￥ｎ」この結果、ＨＴＴＰサーバプログラム１５１によって必
要な他の情報が付加され、この例では、次のような応答
が返される。「ＨＴＴＰ／１．０２００ＯＫＣｏｎｔｅｎｔ−Ｔｙｐｅ：ａｐｐｌｉｃａｔｉｏｎ
／ｘ−ｎｅｗｓｔａｔｕｓＣｏｎｔｅｎｔ−Ｌｅｎｇｔｈ：４￥ｒ￥ｎｏｋ￥ｒ￥ｎ」［操作データ収集プログラム１４２］つぎに、被操作装
置１２０における操作伝達サイクルの処理を示す。図７
は操作データ収集プログラム１４２の処理手順を示すフ
ローチャートである。この処理は、被操作装置１２０内
のＣＰＵ（図示せず）が同じく被操作装置１２０内のＲ
ＯＭ（図示せず）に記憶された操作データ収集プログラ
ム１４２を実行することによって行われる。

【００５６】まず、回線を確保する（ステップＳ５０
１）。操作端末１３０のＨＴＴＰサーバプログラム１５
１に向けて操作伝達要求コマンドを送信する（ステップ
Ｓ５０２）。例えば、操作端末１３０における操作ＣＧ
Ｉプログラム１５３のＵＲＬがＨＴＴＰ：／／ｆｏｏ．
ｂａｒ．ｃｏ．ｊｐ／ｃｇｉ−ｂｉｎ／ｇｅｔｏｐｅｒ
ａｔｉｏｎである場合、以下のようなコマンドを送信す
る。「ＰＯＳＴＨＴＴＰ：／／ｆｏｏ．ｂａｒ．ｃｏ．ｊ
ｐ／ｃｇｉ−ｂｉｎ／ｇｅｔｏｐｅｒａｔｉｏｎＨＴ
ＴＰ／１．０Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ：６￥ｒ￥ｎｎｏｎｅ￥ｒ￥ｎ」ＨＴＴＰサーバプログラム１５１は、この情報を受け取
り、操作ＣＧＩプログラム１５３を呼び出す。操作ＣＧ
Ｉプログラム１５３は、操作イベントを待ち、イベント
が発生した場合、操作情報を返送する。この詳細につい
ては後述する。

【００５７】操作データ収集プログラム１４２は、この
応答が受信されるまで所定時間待つ（ステップＳ５０
３、Ｓ５０５）。所定時間待っても応答がない場合、エ
ラーフラグをＯＮにセットし（ステップＳ５０４）、ス
テップＳ５０８の処理に移行する。

【００５８】一方、所定時間内に操作ＣＧＩプログラム
１５３からの応答が受信された場合、受信データをチェ
ックし、受信したデータが操作伝達であるか否かを判別
する（ステップＳ５０６）。受信したデータが操作伝達
である場合、操作情報を操作データキュー（図示せず）
に追加する（ステップＳ５０７）。例えば、照明１２２
をＯＮにし、ブラインド１２３の開閉位置を８０％にす
るように、操作端末側で指示された場合、以下のような
応答が受信される。「ＨＴＴＰ／１．０２００ＯＫＣｏｎｔｅｎｔ−Ｔｙｐｅ：ａｐｐｌｉｃａｔｉｏｎ
／ｘ−ｇｅｔｏｐｅｒａｔｉｏｎＣｏｎｔｅｎｔ−Ｌｅｎｇｔｈ：２０￥ｒ￥ｎｌｉｇｈｔ＝ＯＮ￥ｒ￥ｎｂｌｉｎｄ＝８０￥ｒ￥ｎ」被操作装置１２０では、制御プログラム１４３は、イベ
ントドリブンで動作し、操作データ収集プログラム１４
２により、操作データキューの情報が書き換えられた場
合、操作要求イベントを発生する。操作要求イベントの
発生が通知されると、本実施形態では、制御プログラム
１４３は、照明１２２の点灯、およびブラインド１２３
の開閉位置を８０％にする操作情報を、操作データキュ
ーから取り出し、コントローラ１２１を制御し、照明１
２２およびブラインド１２３を要求通りの状態に変更す
る。

【００５９】そして、操作データ収集プログラム１４２
は、回線をクローズする（ステップＳ５０８）。エラー
フラグがＯＮにセットされているか否かを判別し（ステ
ップＳ５０９）、エラーフラグがＯＮにセットされてい
る場合、このプログラムを終了し、そうでない場合、ス
テップＳ５０１に戻り、同様の処理を繰り返す。

【００６０】［操作ＣＧＩプログラム１５３］つぎに、
操作伝達サイクルにおける操作端末１３０の処理を示
す。状態通知サイクルと同様、予め操作端末１３０上で
動作しているＨＴＴＰサーバプログラム１５１に対し、
ＵＲＬパスである「／ｃｇｉ−ｂｉｎ／ｇｅｔｏｐｅｒ
ａｔｉｏｎ」が要求された場合、操作ＣＧＩプログラム
１５３が実行されるように設定しておく。このため、こ
のような要求を被操作装置１２０から受け取ると、操作
ＣＧＩプログラム１５３が起動する。

【００６１】図８は操作ＣＧＩプログラム１５３の処理
手順を示すフローチャートである。この処理は、操作端
末１３０内のＣＰＵ（図示せず）が同じく操作端末１３
０内のＲＯＭ（図示せず）に格納された操作ＣＧＩプロ
グラム１５３を実行することによって行われる。

【００６２】操作表示ＣＧＩプログラム１５２では、被
操作装置１２０側に向けて直ちに応答を返したが、操作
ＣＧＩプログラム１５３では、状態通知サイクルがＨＴ
ＴＰリクエストのタイムアウトによる回線の切断が生じ
ないような最大時間まで操作イベントを待つようにす
る。

【００６３】まず、所定時間が経過するか（ステップＳ
６０１）、あるいは操作が行われ、情報交換テーブル４
０１の要求欄が更新されるまで待つ（ステップＳ６０
２）。例えば、ＨＴＴＰリクエストのタイムアウト時間
から往復のネットワーク遅延時間を差し引いた時間より
短い時間だけ操作イベントを待つようにする。

【００６４】操作が検出された場合、更新された要求を
情報交換テーブル４０１の中の要求欄から読み取り、送
信データキュー（図示せず）に追加する（ステップＳ６
０３）。そして、連続する操作を所定の待機時間だけ待
つ（ステップＳ６０４）。例えば、待機時間として、ネ
ットワーク遅延時間に相当する時間だけ待つようにす
る。待機時間が終了した場合、送信データキューから古
い順に操作要求情報を読み取り（ステップＳ６０５）、
操作要求が複数ある場合、これをまとめる。

【００６５】例えば、最初に、照明１２２をＯＮにし、
ブラインド１２３を７０％にする操作が行われ、続い
て、ブラインド１２３を８０％に変更するという操作が
行われた場合、読み込んだ操作情報を照明１２２をＯＮ
にし、ブラインド１２３を８０％にするという情報にま
とめる。

【００６６】読み込んだ操作要求情報に応じた応答情報
を作成し、標準出力に出力する（ステップＳ６０６）。
ＨＴＴＰサーバプログラム１５１によって被操作装置１
２０上の操作データ収集プログラム１４２に応答を返す
（ステップＳ６０７）。例えば、以下のような応答情報
を標準出力に出力する。「Ｃｏｎｔｅｎｔ−Ｔｙｐｅ：ａｐｐｌｉｃａｔｉｏ
ｎ／ｘ−ｇｅｔｏｐｅｒａｔｉｏｎ￥ｒ￥ｎｌｉｇｈｔ＝ＯＮ￥ｒ￥ｎｂｌｉｎｄ＝８０￥ｒ￥ｎ」ＨＴＴＰサーバプログラム１５１によって必要な他の情
報が付加され、操作データ収集プログラム１４２の応答
情報で示したような情報が返される。

【００６７】一方、ステップＳ６０１で所定時間経過し
た場合、つまりユーザの操作がなかった場合、内容をｎ
ｏｎｅとして以下のような応答情報を標準出力に出力す
る。「Ｃｏｎｔｅｎｔ−Ｔｙｐｅ：ａｐｐｌｉｃａｔｉｏ
ｎ／ｘ−ｇｅｔｏｐｅｒａｔｉｏｎ￥ｒ￥ｎｎｏｎｅ￥ｒ￥ｎ」このような構成を有することにより、第１の実施形態で
は、ファイアウォールの内部に被操作装置１２０を設置
しても、インターネットに操作端末１３０を接続し、そ
こから対象機器を操作することが可能となる。

【００６８】また、状態通知の応答を直ぐに返し、次の
状態変化通知に備えると共に、操作伝達要求の場合、操
作イベントを待つようにすることで、操作があった場
合、直ぐに操作情報を通知することが可能となる。

【００６９】また、操作イベントが短い時間に連続して
発生した場合でも、効率良く操作情報を通知することが
できる。尚、本実施形態では、全ての操作について、連
続したイベントの検出を行ったが、操作に優先度を設
け、直ぐに反映されるべき優先度の高い操作について
は、続く操作を待たずに即応し、そうでない場合には、
まとめて送るようにしてもよい。この場合、操作に設け
られた優先度が所定値より高い場合、優先度の高い操作
であると判定するようにしてもよい。

【００７０】［第２の実施形態］前記第１の実施形態で
は、状態通知と操作伝達に専用の通信コネクションを設
けていたが、本発明はこれに限るわけではない。第２の
実施形態では、状態通知を行った同じ通信コネクション
上で操作イベントを待つ場合を示す。

【００７１】第２の実施形態の遠隔操作システムは、前
記第１の実施形態のシステム構成（図１参照）におい
て、状態通知プログラム１４１および操作データ収集プ
ログラム１４２を、１つの操作情報交換プログラム７４
１（図示せず）に置き換え、また操作表示ＣＧＩプログ
ラム１５２および操作ＣＧＩプログラム１５３を、１つ
の操作表示応答ＣＧＩプログラム７５２（図示せず）に
置き換えることにより実現される。尚、前記第１の実施
形態と同一の構成および処理については、同一の符号を
付すことにより、その説明を省略する。

【００７２】図９は第２の実施形態における動作シーケ
ンスを示す図である。状態通知および操作伝達を共用す
る２本の通信コネクションを使用し、操作対象機器の状
態通知および操作端末１３０からの操作情報の収集が行
われる。

【００７３】第２の実施形態では、１本の通信コネクシ
ョンでも状態通知および操作伝達を行うことができる点
が前記第１の実施形態と異なる。すなわち、前記第１の
実施形態と同様、被操作装置１２０で状態変化（例え
ば、Ｓ０）を検出すると、状態変化を待っている片側の
通信コネクションで操作端末１３０に向けて状態通知が
行われる。そして、操作端末１３０側で操作が行われる
のを待つ。操作イベントが検出されると、状態通知を行
った通信コネクションで操作情報が返送される。

【００７４】操作端末１３０側で操作Ｅ０が発生した
時、操作伝達を行ってしまうと、直後の操作Ｅ１があっ
た場合、操作情報の伝達に遅延が生じる。そこで、前記
第１の実施形態と同様、操作端末１３０側で操作Ｅ０が
発生した時、続く操作を少しだけ待ち、その間に操作Ｅ
１が発生した場合、操作伝達Ｅ０＋１として操作情報が
返送される。被操作装置１２０側では、操作情報を受け
取った後、どちらか一方のコネクションが状態変化待ち
である場合、今度は、状態変化がなくても、「状態変化
なし」という状態通知を行う。そして、収集した操作情
報を基に、操作対象機器の操作が行われる。

【００７５】状態通知を行った通信コネクションが操作
を待っている間、被操作装置１２０で新たな状態変化
（例えば、Ｓ１）を検出すると、新たに通信コネクショ
ンが生成され、状態通知が行われる。操作端末１３０側
では、新たな状態通知が到着すると、先に操作待ちを行
っている通信コネクション側で「操作なし」という操作
情報を返送し、後の通信コネクション側で引き続き操作
を待つ。「操作なし」を受け取った通信コネクション側
では、もう一方が操作伝達あるいは操作なしを受信する
まで状態変化を待つ。

【００７６】［操作情報交換プログラム７４１］つぎ
に、被操作装置１２０側の処理を示す。図１０および図
１１は操作情報交換プログラム７４１の処理手順を示す
フローチャートである。この処理は、被操作装置１２０
内のＣＰＵ（図示せず）が同じく被操作装置１２０内の
ＲＯＭ（図示せず）に記憶された操作情報交換プログラ
ム７４１を実行することによって行われる。

【００７７】操作情報交換プログラム７４１は、３つの
カウンタ（図示せず）を有する。図１２はカウンタテー
ブルを示す図である。第１のカウンタは、操作情報交換
プログラム７４１がＨＴＴＰサーバプログラム１５１か
らの応答を待っているＨＴＴＰリクエスト要求数を数え
るものであり、その初期値は値０である。このカウンタ
を要求カウンタと呼ぶ。

【００７８】第２のカウンタは、送信するＨＴＴＰリク
エストの順序を数えるものであり、リクエストデータ中
にその値が埋め込まれる。その初期値は値０である。こ
のカウンタを送信カウンタと呼ぶ。

【００７９】第３のカウンタは、受信したＨＴＴＰレス
ポンスの処理順序を数えるものであり、レスポンスデー
タの中にその値が埋め込まれている。その初期値は値０
である。このカウンタを受信カウンタと呼ぶ。

【００８０】本実施形態では、操作情報交換プログラム
７４１は、同時に２つのプロセスで実行され、並列動作
する。まず、共有メモリ領域に確保したカウンタテーブ
ル８０１から要求カウンタを読み込む（ステップＳ８０
１）。カウンタテーブル８０１には、要求カウンタ以外
に、後述する送信カウンタおよび受信カウンタの値がセ
ットされている。カウンタテーブル８０１の要求欄に
は、現在、状態通知を行って操作伝達待ちである通信コ
ネクションの数が設定されている。つまり、要求カウン
タが値０である場合、２つの操作情報交換プログラム７
４１は共に状態変化待ちの状態である。値１の場合、片
方が状態通知を行った後、操作待ち状態であることを示
す。尚、要求、送信、受信のそれぞれのカウンタを別々
に管理してもよく、また共有メモリの代わりにファイル
を共有してもよい。

【００８１】要求カウンタのチェックを行い（ステップ
Ｓ８０２）、要求カウンタが値１である場合、状態変化
が発生するまで待つ（ステップＳ８０３）。一方、要求
カウンタが値０である場合、あるいはステップＳ８０３
で状態変化があった場合、前記第１の実施形態と同様、
照明１２２の点灯状態およびブラインド１２３の開閉位
置の状態情報を収集し（ステップＳ８０４）、カウンタ
テーブル８０１から送信カウンタを読み込む（ステップ
Ｓ８０５）。

【００８２】そして、送信情報を作成する（ステップＳ
８０６）。カウンタテーブル８０１の送信欄には、状態
通知情報を送信した回数がセットされている。例えば、
送信カウンタの値が「１」である場合、以下のようなコ
マンドを作成する。「ＰＯＳＴＨＴＴＰ：／／ｆｏｏ．ｂａｒ．ｃｏ．ｊ
ｐ／ｃｇｉ−ｂｉｎ／ｎｅｗｓｔａｔｕｓＨＴＴＰ／
１．０Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ：３７￥ｒ￥ｎｓｅｎｄ＿ｃｏｕｎｔｅｒ＝１￥ｒ￥ｎｌｉｇｈｔ＝ＯＦＦ￥ｒ￥ｎｂｌｉｎｄ＝７０￥ｒ￥ｎ」そして、送信カウンタの値を１つ増やす（ステップＳ８
０７）。本実施形態では、カウンタテーブル８０１の送
信欄に値２を書き込む。通信回線を確保し（ステップＳ
８０８）、要求カウンタの値を１つ増やし（ステップＳ
８０９）、カウンタテーブルの要求欄に書き込む。

【００８３】尚、本実施形態では、２つの操作情報交換
プログラム７４１が並列動作しているので、ステップＳ
８０４〜ステップＳ８０７の処理を行う場合、情報交換
テーブル４０１、カウンタテーブル８０１をロックする
などの排他制御を行うことで、２重の情報収集、カウン
タの抜け、だぶりなどが発生しないようにしておく。ま
た、後述する応答受信の場合も、同様の排他制御を行
う。

【００８４】ステップＳ８０９の処理後、操作端末１３
０のＨＴＴＰサーバプログラム１５１に向けてこの情報
を送信する（ステップＳ８１０）。尚、要求カウンタの
初期値を値０にしておくことで、操作情報交換プログラ
ム７４１が最初に起動されたとき、状態変化を待たず
に、操作対象機器の初期状態を操作端末１０３に通知し
ておくことができる。

【００８５】ＨＴＴＰサーバプログラム１５１は、この
情報を受け取り、操作表示応答ＣＧＩプログラム７５２
を呼び出す。操作表示応答ＣＧＩプログラム７５２は、
受け取った情報を基に対象機器の操作画面を更新する。
この詳細については後述する。

【００８６】操作情報交換プログラム７４１は、操作表
示応答ＣＧＩプログラム７５２からの応答を受信するま
で所定時間待つ（ステップＳ８１１）。所定時間待って
も応答がない場合、エラーフラグをＯＮにセットし（ス
テップＳ８１２）、ステップＳ８１９の処理に移行す
る。

【００８７】一方、操作表示応答ＣＧＩプログラム７５
２からの応答を受信した場合、カウンタテーブル８０１
から受信カウンタを読み込み（ステップＳ８１４）、受
信カウンタのチェックを行う（ステップＳ８１５）。カ
ウンタテーブル８０１の受信欄には、既に受信したデー
タのカウンタ値、つまり次に処理すべきデータ番号より
値１少ない値がセットされている。ここで、受け取った
データ内に記述されているカウンタ番号が受信カウンタ
の値より値２以上大きい場合、データに抜けがあること
が分かるので、もう一方の通信コネクションでデータ受
信を行い、受信カウンタが更新されるまで待つ。

【００８８】一方、ステップＳ８１５でカウンタ番号の
値が正しい場合、受信データが操作要求情報であるか、
あるいは操作なし情報であるかを判別する（ステップＳ
８１６）。操作要求情報である場合、操作情報を操作デ
ータキュー（図示せず）に追加する（ステップＳ８１
７）。例えば、以下のような応答が受信される。「ＨＴＴＰ／１．０２００ＯＫＣｏｎｔｅｎｔ−Ｔｙｐｅ：ａｐｐｌｉｃａｔｉｏｎ
／ｘ−ｇｅｔｏｐｅｒａｔｉｏｎＣｏｎｔｅｎｔ−Ｌｅｎｇｔｈ：３９￥ｒ￥ｎｒｅｃｅｉｖｅ＿ｃｏｕｎｔｅｒ＝１￥ｒ￥ｎｌｉｇｈｔ＝ＯＮ￥ｒ￥ｎｂｌｉｎｄ＝８０￥ｒ￥ｎ」そして、受信カウンタの値を１つ増やす（ステップＳ８
１８）。本実施形態では、カウンタテーブル８０１の受
信欄に値１を書き込む。尚、ステップＳ８１６〜ステッ
プＳ８１８の処理を行う際、前述と同様、排他制御を行
うようにする。また、制御プログラム１４３の動作につ
いては、前記第１の実施形態と同様である。

【００８９】この後、操作情報交換プログラム７４１
は、回線をクローズし（ステップＳ８１９）、再度、要
求カウンタを読み出し（ステップＳ８２０）、要求カウ
ンタの値を１つ減らし、カウンタテーブル８０１の要求
欄を更新する（ステップＳ８２１）。そして、エラーフ
ラグがＯＮにセットされているか否かを判別し（ステッ
プＳ８２２）、エラーフラグがＯＮにセットされている
場合、この処理を終了し、そうでない場合、ステップＳ
８０１に戻って同様の処理を繰り返す。

【００９０】［操作表示応答ＣＧＩプログラム７５２］
つぎに、操作端末１３０側の処理を示す。前記第１の実
施形態と同様、予め操作端末１３０で動作しているＨＴ
ＴＰサーバプログラム１５１に対し、ＵＲＬパスである
「／ｃｇｉ−ｂｉｎ／ｎｅｗｓｔａｔｕｓ」が要求され
た場合、操作表示応答ＣＧＩプログラム７５２が実行さ
れるように設定しておく。このため、上記要求を被操作
装置１２０から受け取ると、操作表示応答ＣＧＩプログ
ラム７５２が起動する。

【００９１】本実施形態では、操作情報交換プログラム
７４１が並列動作するので、同時に２つの要求を受け取
る場合もある。このとき、操作表示応答プログラム７５
２はそれぞれの要求毎に起動して並列動作する。

【００９２】図１３および図１４は操作表示応答ＣＧＩ
プログラム７５２の処理手順を示すフローチャートであ
る。操作表示応答ＣＧＩプログラム７５２は、３つのカ
ウンタ（図示せず）を有する。

【００９３】第１のカウンタは、操作情報交換プログラ
ム７４１からのＨＴＴＰリクエストにより起動された操
作表示応答ＣＧＩプログラム７５２の実行プロセスを数
えるものであり、その初期値は値０である。このカウン
タを要求カウンタと呼ぶ。

【００９４】第２のカウンタは、受信した状態情報の順
序を数えるものであり、操作情報交換プログラム７４１
の送信カウンタと対を成す。その初期値は値０であり、
リクエストデータ中にその値が埋め込まれる。このカウ
ンタを受信カウンタと呼ぶ。

【００９５】第３のカウンタは、送信するＨＴＴＰレス
ポンスの処理順序を数えるものであり、操作情報交換プ
ログラム７４１の受信カウンタと対を成す。その初期値
は値０であり、レスポンスデータ中にその値が埋め込ま
れる。このカウンタを受信カウンタと呼ぶ。

【００９６】まず、共有メモリ領域に確保した前述した
カウンタテーブル８０１と同等のカウンタテーブル（図
示せず）から要求カウンタを読み込む（ステップＳ９０
１）。カウンタテーブルには、前述と同様、要求カウン
タ以外に、後述する送信カウンタおよび受信カウンタの
値がセットされている。カウンタテーブルの要求欄に
は、現在、実行中の操作表示応答ＣＧＩプログラム７５
２の数が設定されている。そして、要求カウンタの値を
１つ増やす（ステップＳ９０２）。

【００９７】受信カウンタを読み込み（ステップＳ９０
３）、被操作装置１２０から送られた状態情報の中のカ
ウンタ番号と受信カウンタの番号とから処理すべき状態
情報であるか否かを判別する（ステップＳ９０４）。カ
ウンタ番号が正しい場合、受信カウンタの値を１つ増や
す（ステップＳ９０５）。

【００９８】そして、前記第１の実施形態と同様、操作
表示ＧＵＩプログラム１５４に操作表示更新要求を行う
（ステップＳ９０６）。尚、ステップＳ９０５およびス
テップＳ９０６の処理を行う際、前述したような排他制
御を行い、これらの処理が終わるまで並列動作している
操作情報交換プログラムによる同じ処理ステップが行わ
れないようにする。また、操作表示ＧＵＩプログラムの
処理については、前記第１の実施形態と同様である。

【００９９】この後、所定時間が経過したか否かを判別
し（ステップＳ９０７）、所定時間経過している場合、
ステップＳ９１７の処理に移行する。一方、所定時間が
経過していない場合、要求カウンタをチェックし（ステ
ップＳ９０８）、要求カウンタが値２である場合、ステ
ップＳ９１７の処理に移行する。一方、要求カウンタが
値１である場合、操作イベントが検出されたか否かを判
別する（ステップＳ９０９）。操作イベントが検出され
ない場合、ステップＳ９０７の処理に戻り、操作イベン
トが検出された場合、ステップＳ９１０の処理に移行す
る。

【０１００】このように、所定時間が経過するまで要求
カウンタをチェックしながら、操作が行われ、前記第１
の実施形態と同様に情報交換テーブル（図示せず）の要
求欄が更新されるのを待つ。

【０１０１】ステップＳ９０９で操作イベントが検出さ
れると、更新された要求を、情報交換テーブルの中の要
求欄から読み取り、送信データキュー（図示せず）に追
加する（ステップＳ９１０）。尚、操作イベントがない
場合、「操作なし」として取り扱う。

【０１０２】そして、ステップＳ９０９と同様の操作検
出処理を行いながら、連続する操作を所定の待機時間だ
け待つ（ステップＳ９１２）。例えば、待機時間とし
て、ネットワーク遅延時間に相当する時間だけ待つよう
にする。待機時間が終了すると、送信データキューから
古い順に操作要求情報を読み取り（ステップＳ９１
３）、操作要求が複数ある場合、これをまとめる。

【０１０３】送信カウンタを読み込み（ステップＳ９１
４）、送信カウンタの値を１つ増やす（ステップＳ９１
５）。尚、ステップＳ９１０〜ステップＳ９１５の処理
を行う際、前述した排他制御を行うようにする。

【０１０４】読み込んだ操作情報に応じて応答情報を作
成し、標準出力に出力する（ステップＳ９１６）。ＨＴ
ＴＰサーバプログラム１５１によって被操作装置１２０
上の操作情報交換プログラム７４１に向けて応答を返す
（ステップＳ９２０）。例えば、以下のような応答情報
を標準出力に出力する。「Ｃｏｎｔｅｎｔ−Ｔｙｐｅ：ａｐｐｌｉｃａｔｉｏ
ｎ／ｘ−ｇｅｔｏｐｅｒａｔｉｏｎ￥ｒ￥ｎｒｅｃｉｅｖｅ＿ｃｏｕｎｔｅｒ＝１￥ｒ￥ｎｌｉｇｈｔ＝ＯＮ￥ｒ￥ｎｂｌｉｎｄ＝８０￥ｒ￥ｎ」一方、ステップＳ９０７で所定時間が経過した場合、つ
まりユーザの操作がなかった場合、あるいは、ステップ
Ｓ９０８で複数の操作待ち状態が検出された場合、ステ
ップＳ９１４、Ｓ９１５と同様のカウンタ処理を行い
（ステップＳ９１７、Ｓ９１８）、内容をｎｏｎｅとし
て以下のような応答情報（操作なし）を標準出力に出力
する（ステップＳ９１９）。「Ｃｏｎｔｅｎｔ−Ｔｙｐｅ：ａｐｐｌｉｃａｔｉｏ
ｎ／ｘ−ｇｅｔｏｐｅｒａｔｉｏｎ￥ｒ￥ｎｒｅｃｉｅｖｅ＿ｃｏｕｎｔｅｒ＝１￥ｒ￥ｎｎｏｎｅ￥ｒ￥ｎ」尚、ステップＳ９１７〜Ｓ９１９の処理を行う際、前述
した排他制御を行う。これにより、ＨＴＴＰサーバプロ
グラム１５１によって必要な他の情報が付加され、操作
情報交換プログラム７４１の応答情報で示したような情
報が返される。この後、要求カウンタの値を１つ減らす
（ステップＳ９２１）。

【０１０５】尚、本実施形態では、通信コネクションが
２本である場合を示したが、３本以上の通信コネクショ
ンを用いてもよい。その場合、図１０のステップＳ８０
２の要求カウンタチェックルーチンにおいて、要求数が
値０である場合、状態変化が無くても状態通知を行い、
要求数が値１である場合、状態変化を待ち、要求数が値
２である場合、どちらかの通信コネクションが切断され
るのを待つという処理を行うようにすればよい。例え
ば、利用する通信コネクションがｎ本であり、操作イベ
ントをｍ個（ｍ＜ｎ）のプロセスで待つ場合、要求数が
値０から値ｍ−１（ｍマイナス１）の場合、状態変化が
無くても状態通知を行い、要求数がｍからｎ−１（ｎマ
イナス１）の場合、状態変化を待ち、要求数がｎの場
合、いずれかの通信コネクションが切断されるのを待つ
ようにする。

【０１０６】同様に、図１３および図１４のステップＳ
９０８の要求カウンタチェックルーチンにおいて、要求
数が値１である場合、操作イベントを待ち、要求数が値
２である場合、操作待ちループを抜けるという処理を、
要求数が値１から値ｍ−１（ｍマイナス１）である場
合、操作イベントを待ち、要求数が値ｍである場合、操
作待ちループを抜けるようにする。

【０１０７】このような構成を有することにより、第２
の実施形態では、ファイアウォールの内部に被操作装置
１２０を設置しても、インターネットに操作端末１３０
を接続し、そこから対象機器を操作することが可能とな
る。

【０１０８】また、１本の通信コネクションだけでも、
状態通知および操作情報伝達を行うことができ、２本以
上の通信コネクションを利用する場合であっても、２本
目以降の通信コネクションは必要なときにしか使われな
いので、ネットワークの負荷を軽減することができる。

【０１０９】また、操作イベントが短い時間に連続して
発生した場合でも、効率良く操作情報を通知することが
可能である。尚、本実施形態では、全ての操作につい
て、連続したイベントの検出を行ったが、操作に優先度
を設け、直ぐに反映されるべき優先度の高い操作につい
ては、続く操作を待たずに即応し、そうでない場合に
は、まとめて送るようにしてもよい。

【０１１０】［第３の実施形態］前記第１の実施形態で
は、状態通知サイクルおよび操作伝達サイクルに、それ
ぞれ１本の通信コネクションを使用していたが、本発明
はこれに限るわけではない。第３の実施形態では、状態
通知サイクル、操作伝達サイクルのいずれか、または両
方に複数の通信コネクションを使用する場合を示す。こ
れにより、連続した状態変化または操作要求に迅速に対
応することが可能である。

【０１１１】第３の実施形態における遠隔操作システム
は、前記第１の実施形態のシステム構成において、状態
通知プログラム１４１を状態通知プログラム１０１４１
（図示せず）に、操作データ収集プログラム１４２を操
作データ収集プログラム１０１４２（図示せず）に、操
作表示ＣＧＩプログラム１５２を操作表示ＣＧＩプログ
ラム１０１５２（図示せず）に、操作ＣＧＩプログラム
１５３を操作ＣＧＩプログラム１０１５３（図示せず）
にそれぞれ変更することによって実現される。また、前
記第１の実施形態と同一の構成および処理については、
同一の符号を用いることにより、その説明を省略する。

【０１１２】［状態通知プログラム１０１４１］被操作
装置１２０における状態通知サイクルの処理を示す。図
１５は第３の実施形態における状態通知プログラム１０
１４１の処理手順を示すフローチャートである。この処
理は、被操作装置１２０内のＣＰＵ（図示せず）が同じ
く被操作装置１２０内のＲＯＭ（図示せず）に記憶され
た状態通知プログラム１０１４１を実行することによっ
て行われる。

【０１１３】第３の実施形態では、状態通知プログラム
１０１４１は、同時に２つ以上のプロセスで実行され、
並列動作する。状態通知プログラム１０１４１は、前記
第２の実施形態におけるステップＳ８０５、ステップＳ
８０７とそれぞれ同様の送信カウンタ読込処理（ステッ
プＳ３０２Ａ）、送信カウンタ加算処理（ステップＳ３
０３Ａ）が加わったことを除き、前記第１の実施形態に
おける状態通知プログラム１４１と同じである。また、
ステップＳ３０２〜ステップＳ３０３Ａの処理を行う
際、前記第２の実施形態で示した排他制御を行うように
する。

【０１１４】この結果、複数の状態通知プログラム１０
１４１が並列動作する場合においても、送信データにデ
ータ番号が付与されるので、操作端末１３０に到着した
際、順番が逆になっても、後述する操作表示ＣＧＩプロ
グラム１０１５２によって正しい順に処理を行うことが
可能となる。

【０１１５】［操作表示ＣＧＩプログラム１０１５２］
つぎに、状態通知サイクルにおける操作端末１３０の処
理を示す。前記第１の実施形態と同様、予め操作端末１
３０上で動作しているＨＴＴＰサーバプログラム１５１
に対し、ＵＲＬパスである「／ｃｇｉ−ｂｉｎ／ｎｅｗ
ｓｔａｔｕｓ」が要求された場合、操作表示ＣＧＩプロ
グラム１０１５２が実行されるように設定しておく。こ
のため、上記要求を被操作装置１２０から受け取ると、
操作表示ＣＧＩプログラム１０１５２が起動する。

【０１１６】図１６は操作表示ＣＧＩプログラム１０１
５２の処理手順を示すフローチャートである。この処理
は、操作端末１３０内のＣＰＵ（図示せず）が同じく操
作端末１３０内のＲＯＭ（図示せず）に格納された操作
表示ＣＧＩプログラム１０１５２を実行することによっ
て行われる。

【０１１７】本実施形態では、状態通知プログラム１０
１４１が並列動作するので、同時に２つ以上の要求を受
け取る場合もある。この場合、操作表示ＣＧＩプログラ
ム１０１５２がそれぞれの要求毎に起動し、並列動作す
る。

【０１１８】操作表示ＣＧＩプログラム１０１５２は、
前記第２の実施形態におけるステップＳ９０３と同様の
受信カウンタ読込み処理（ステップＳ４００Ａ）、ステ
ップＳ９０４と同様の受信カウンタチェック処理（ステ
ップＳ４００Ｂ）、ステップＳ９０５と同様の受信カウ
ンタ加算処理（ステップＳ４００Ｃ）が加わったことを
除き、前記第１の実施形態における操作表示ＣＧＩプロ
グラム１５２と同じである。

【０１１９】尚、ステップＳ４００ＣおよびステップＳ
４０１の処理を行う際、前述した排他制御を行い、これ
らの処理が終わるまで、並列動作している操作表示ＣＧ
Ｉプログラム１０１５２による同じ処理ステップが行わ
れないようにする。

【０１２０】この結果、複数の操作表示ＣＧＩプログラ
ム１０１５２が並列動作する場合でも、受信カウンタを
管理し、受信データに付与されたデータ番号を確認する
ことにより、正しい順に処理を行うことが可能となる。

【０１２１】［操作データ収集プログラム１０１４２］
つぎに、操作伝達サイクルにおける被操作装置１２０の
処理を示す。図１７は操作データ収集プログラム１０１
４２の処理手順を示すフローチャートである。この処理
は、被操作装置１２０内のＣＰＵ（図示せず）が同じく
被操作装置１２０内のＲＯＭ（図示せず）に記憶された
操作データ収集プログラム１０１４２を実行することに
よって行われる。

【０１２２】第３の実施形態では、操作データ収集プロ
グラム１０１４２は、同時に２つ以上のプロセスで実行
され、並列動作する。

【０１２３】操作データ収集プログラム１０１４２は、
前記第２の実施形態におけるステップＳ８１４と同様の
受信カウンタ読込み処理（ステップＳ５０５Ａ）、ステ
ップＳ８１５と同様の受信カウンタチェック処理（ステ
ップＳ５０５Ｂ）、ステップＳ８１８と同様の受信カウ
ンタ加算処理（ステップＳ５０７Ａ）が加わったことを
除き、前記第１の実施形態における操作データ収集プロ
グラム１４２と同じである。尚、ステップＳ５０６〜ス
テップＳ５０７Ａの処理を行う際、前記第２の実施形態
で示した排他制御を行うようにする。

【０１２４】この結果、複数の操作データ収集プログラ
ム１０１４２が並列動作する場合でも、受信カウンタを
管理し、受信データに付与されたデータ番号を確認する
ことにより、正しい順に処理を行うことが可能となる。

【０１２５】［操作ＣＧＩプログラム１０１５３］つぎ
に、操作端末１３０における操作伝達サイクルの処理を
示す。前記第１の実施形態と同様、予め操作端末１３０
上で動作しているＨＴＴＰサーバプログラム１５１に対
し、ＵＲＬパスである「／ｃｇｉ−ｂｉｎ／ｇｅｔｏｐ
ｅｒａｔｉｏｎ」が要求された場合、操作ＣＧＩプログ
ラム１０１５３が実行されるように設定しておく。この
ため、上記要求を被操作装置１２０から受け取ると、操
作ＣＧＩプログラム１０１５３が起動する。

【０１２６】図１８および図１９は操作ＣＧＩプログラ
ム１０１５３の処理手順を示すフローチャートである。
この処理は、操作端末１３０内のＣＰＵ（図示せず）が
同じく操作端末１３０内のＲＯＭ（図示せず）に格納さ
れた操作ＣＧＩプログラム１０１５３を実行することに
よって行われる。

【０１２７】本実施形態では、操作データ収集プログラ
ム１０１４２が並列動作するので、同時に２つ以上の要
求を受け取る場合もある。この場合、操作ＣＧＩプログ
ラム１０１５３がそれぞれの要求毎に起動し、並列動作
する。

【０１２８】操作ＣＧＩプログラム１０１５３は、第２
の実施形態におけるステップＳ９０１と同様の要求カウ
ンタ読込み処理（ステップＳ６００Ａ）、ステップＳ９
０２と同様の要求カウンタ加算処理（ステップＳ６００
Ｂ）、ステップＳ９０８と同様の要求カウンタチェック
処理（ステップＳ６０１Ａ）、ステップＳ９１１と同様
の操作イベント検出処理（ステップＳ６０３Ａ）、ステ
ップＳ９１４と同様の送信カウンタ読込み処理（ステッ
プＳ６０５Ａ、Ｓ６０１Ｂ）、ステップＳ９１５と同様
の送信カウンタ加算処理（ステップＳ６０５Ｂ、Ｓ６０
１Ｃ）、ステップＳ９１９と同様の応答情報作成処理
（ステップＳ６０１Ｄ）、ステップＳ９２１と同様の要
求カウンタ減算処理（ステップＳ６０７Ａ）が加わった
ことを除き、前記第１の実施形態における操作ＣＧＩプ
ログラム１５３と同じである。尚、この場合、ステップ
Ｓ６０３〜ステップＳ６０５Ｂ、およびステップＳ６０
１Ｂ〜Ｓ６０１Ｄの処理を行う際、第２の実施形態で示
した排他制御を行うようにする。

【０１２９】この結果、複数の操作ＣＧＩプログラム１
０１５３が並列に動作する場合でも、送信データにデー
タ番号が付与されるので、被操作装置１２０に到着した
際に順番が逆になっていても、前述の操作データ収集プ
ログラム１０１４２で正しい順に処理を行うことが可能
となる。

【０１３０】このような構成を有することにより、第３
の実施形態では、状態通知サイクル、操作伝達サイクル
のいずれか、または両方を複数の通信コネクションでも
利用することができ、これにより、状態変化や操作要求
が短い時間内に連続して発生するような場合でも、状態
通知や操作伝達が遅れないようにすることができる。

【０１３１】尚、本実施形態では、全ての操作につい
て、連続したイベントの検出を行ったが、操作に優先度
を設け、直ぐに反映されるべき優先度の高い操作につい
ては、続く操作を待たずに即応し、そうでない場合に
は、まとめて送るようにしてもよい。

【０１３２】［第４の実施形態］第４の実施形態は、前
記第２の実施形態と異なり、操作端末との通信を司る専
用のプログラムが被操作装置に置かれ、持続的通信コネ
クションを用いて処理を行うことを特徴する。

【０１３３】図２０は第４の実施形態における遠隔操作
システムの構成を示す図である。図において、１００〜
１３２、１４３、１５１、１５３の各部は前記第１の実
施形態と同一であるので、その説明を省略する。ここ
で、本実施形態のＨＴＴＰサーバプログラム１５１は、
持続的コネクションおよびパイプライン処理に対応し、
特にパイプライン処理では、ＨＴＴＰの規定にしたがっ
てリクエストの到着順にレスポンスを返すことを保証す
る機能を有する。

【０１３４】また、操作情報交換プログラム２０１は、
本実施形態に特有のものであり、前記第２の実施形態に
おける操作情報交換プログラム７４１の代りに、被操作
装置１２０に置かれて動作する。通信制御プログラム２
０２は、新たに被操作装置１２０に置かれて動作する。

【０１３５】一方、操作端末１３０側では、前記第２の
実施形態における操作表示応答ＣＧＩプログラム７５２
の代りに、本実施形態に特有の操作表示応答ＣＧＩプロ
グラム２１１が置かれて動作する。以下、操作情報交換
プログラム２０１、通信制御プログラム２０２および操
作表示応答ＣＧＩプログラム２１１を示す。

【０１３６】［通信制御プログラム２０２］通信制御プ
ログラム２０２は、操作情報交換プログラム２０１を子
プロセスとして起動・管理するとともに、操作端末１３
０上のＨＴＴＰサーバプログラム１５１との間で持続的
コネクションを確立・維持し、持続的コネクションにお
ける状態情報および操作情報の通信制御を司る。また、
通信制御プログラム２０２は、２種類のタイマ、そのタ
イムアウト値、１つのカウンタ、および２つの状態フラ
グを有する。

【０１３７】第１のタイマは、持続的コネクションのタ
イムアウトを防ぐために用いられ、ＨＴＴＰレスポンス
の受信から次のＨＴＴＰリクエストの発信までの時間を
計測する。そのタイムアウト値は、一般的なプロキシサ
ーバプログラムの持続的コネクションのタイムアウト時
間よりわずかに短く設定される。この第１のタイマは、
通信制御プログラム２０２に対して１つ割り当てられ
る。以下、このタイマを持続的コネクションタイムアウ
トタイマと呼ぶ。

【０１３８】第２のタイマは、ＨＴＴＰサーバプログラ
ム１５１、プロキシサーバプログラム１１２、ネットワ
ークのいずれかに障害が発生した際、通信制御プログラ
ム２０２が無限の待ち状態に陥らないようにするための
ものであり、ＨＴＴＰリクエストとして状態情報を送信
してからそのリクエストに対応するＨＴＴＰレスポンス
が返るまでの時間を計測する。そのタイムアウト値は、
一般のＨＴＴＰにおけるタイムアウト値と同等に設定さ
れており、固定である。ＨＴＴＰリクエスト１つに対
し、１つのタイマが割り当てられ、リクエストの送信と
ともに計測がスタートし、レスポンスの受信とともに計
測を終了し、割り当てが解放される。以下、このタイマ
をＨＴＴＰタイムアウトタイマと呼ぶ。

【０１３９】カウンタは、通信制御プログラム２０２が
ＨＴＴＰサーバプログラム１５１からの応答を待ってい
るＨＴＴＰリクエスト数を数えるものであり、その初期
値は値０である。以下、このカウンタを応答待ちカウン
タと呼ぶ。

【０１４０】２つの状態フラグは、プログラム間の共有
メモリ領域に確保されており、操作情報交換プログラム
２０１群との間でデータの送信要求および受信要求を伝
えるために使用される。初期値はともに値０である。以
下、それぞれ送信待ちフラグ、受信待ちフラグと呼ぶ。

【０１４１】図２１および図２２は通信制御プログラム
２０２の処理手順を示すフローチャートである。この処
理は、被操作装置１２０内のＣＰＵ（図示せず）が同じ
く被操作装置１２０内のＲＯＭ（図示せず）に記憶され
た通信制御プログラム２０２を実行することによって行
われる。

【０１４２】通信制御プログラム２０２は、起動する
と、自身の子プロセスとして操作情報交換プログラム２
０１を事前に設定された所定数起動する（ステップＳ１
５００）。ここでは、通信制御プログラム２０２がｎ個
起動する場合を示す（ｎは２以上の整数）。そして、操
作情報交換プログラム２０１群と自身との間にプロセス
間の通信路を確立する（ステップＳ１５１０）。

【０１４３】つぎに、ＨＴＴＰサーバプログラム１５１
との間に持続的コネクション（ｐｅｒｓｉｓｔｅｎｔ
ｃｏｎｎｅｃｔｉｏｎ）を確立する（ステップＳ１５２
０）。ここでは、利用するＨＴＴＰのバージョンに応じ
た方法により、持続的コネクションを確立する。

【０１４４】尚、この持続的コネクションは、ファイア
ウォール１１１上のプロキシサーバプログラム１１２と
の間で確立され、プロキシサーバプログラム１１２とＨ
ＴＴＰサーバプログラム１５１との間では、これとは独
立した持続的コネクションがプロキシサーバプログラム
１１２によって確立される。

【０１４５】この後、持続的コネクションタイムアウト
タイマをクリアする（ステップＳ１５３０）。

【０１４６】上記処理により、通信制御プログラム２０
２は初期設定を終え、これ以降、操作情報交換プログラ
ム２０１群とＨＴＴＰサーバ１５１との間でデータ交換
を行う。まず、操作情報交換プログラム２０１群からＨ
ＴＴＰサーバ１５１へのデータ送信要求が起こされてい
るか否かを調べる（ステップＳ１５４０）。このチェッ
クは、操作情報交換プログラム２０１の説明において詳
述するが、簡単に説明すると、送信待ちフラグの値を調
べ、この値が「０」でない場合、そのフラグの値が示す
プロセスＩＤを持つ子プロセスである操作情報交換プロ
グラム２０１が送信を要求していると判別する。

【０１４７】送信要求がなかった場合、持続的コネクシ
ョンタイムアウトタイマが所定タイムアウト時間に達し
ているか否かを判別する（ステップＳ１６３０）。所定
タイムアウト時間に達していた場合、持続的コネクショ
ンを維持するためにのみ、ダミーのＨＴＴＰリクエスト
を作成し、これをＨＴＴＰサーバ１５１に送信し（ステ
ップＳ１６４０）、そのレスポンスを受け取る（ステッ
プＳ１６５０）。そして、ステップＳ１５４０の処理に
戻る。

【０１４８】このリクエストは、操作端末１３０上のＨ
ＴＴＰサーバプログラム１５１が応答を返すものであれ
ば何でもよく、例えば、ＨＥＡＤＨＴＴＰ：／／ｆｏ
ｏ．ｂａｒ．ｃｏ．ｊｐ／ＨＴＴＰ／１．０のような
転送データ量が少ないものであることが望ましい。受け
取ったデータは不要であるので、破棄する。そして、レ
スポンスを受け取ると、ステップＳ１５３０の処理に戻
る。一方、ステップＳ１６３０で所定タイムアウト時間
に達していなかった場合、ステップＳ１５４０の処理に
戻る。

【０１４９】一方、ステップＳ１５４０で要求があった
場合、該当する子プロセスからプロセス間通信路を用い
て送信データを受け取り、これをＨＴＴＰサーバプログ
ラム１５１にＨＴＴＰリクエストとして持続的コネクシ
ョン上で転送する（ステップＳ１５５０）。応答待ちカ
ウンタをインクリメントする（ステップＳ１５６０）。

【０１５０】パイプライン処理機能を活かし、レスポン
スが返される前にデータ送信要求が起こされているか否
かを再度調べる（ステップＳ１５７０）。データ送信要
求があった場合、ステップＳ１５５０の処理に戻る。

【０１５１】一方、送信要求がなかった場合、ＨＴＴＰ
タイムアウトタイマのいずれかがタイムアウトしていな
いか否かを調べる（ステップＳ１５８０）。タイムアウ
トしていた場合、エラー処理を行い（ステップＳ１６６
０）、子プロセスである操作情報交換プログラム２０１
群を割り込み処理等で終了させ（ステップＳ１６７
０）、ＨＴＴＰサーバプログラム１５１との間の持続的
コネクションをクローズし（ステップＳ１６８０）、こ
の通信制御プログラム２０２の処理を終了する。

【０１５２】一方、ステップＳ１５８０でタイムアウト
していない場合、応答データがＨＴＴＰサーバ１５１か
ら送られてきているか否かを調べる（ステップＳ１５９
０）。応答データを受信していた場合、データの読み出
しを待っているプロセスを調べ、そのプロセスにデータ
を転送する（ステップＳ１６００）。この処理は、操作
情報交換プログラム２０１の説明の際に詳述するが、簡
単に説明すると、受信待ちフラグの値を調べ、このフラ
グの値が示すプロセスＩＤを持つ子プロセスである操作
情報交換プログラム２０１にデータを転送する。

【０１５３】応答待ちカウンタをデクリメントし（ステ
ップＳ１６１０）、カウンタの値が「０」になったか否
かを判別する（ステップＳ１６２０）。値０であった場
合、ＨＴＴＰリクエストが残っていないので、ステップ
Ｓ１５３０の処理に戻り、パイプライン処理を一旦、終
了する。一方、ステップＳ１６２０で値０でない場合、
引き続きパイプライン処理を行うために、ステップＳ１
５７０の処理に戻る。また、ステップＳ１５９０で応答
データが到着していなかった場合、ステップＳ１５７０
の処理に戻る。

【０１５４】［操作情報交換プログラム２０１］操作情
報交換プログラム２０１の処理は、通信制御プログラム
２０２との関連部分を除き、前記第２の実施形態におけ
る操作情報交換プログラム７４１と基本的的に同一であ
るので、操作情報交換プログラム７４１と同一のステッ
プ処理については、その説明を省略する。

【０１５５】操作情報交換プログラム２０１は、プログ
ラム間の共有メモリ領域に２つのカウンタ、２つのキュ
ーおよび２つの状態フラグを有する。

【０１５６】第１のカウンタは、同時に動作する操作情
報交換プログラム２０１間で共有されるものであり、状
態通知・操作伝達要求を行い、現在応答を待っている数
をカウントする。初期値は「０」である。以下、このカ
ウンタを要求カウンタと呼ぶ。

【０１５７】第２のカウンタも同時に動作する操作情報
交換プログラム２０１間で共有されるものであり、これ
までに状態通知を送信した回数をカウントする。初期値
は、操作表示応答ＣＧＩプログラム２１１の受信カウン
タの初期値と同じである。以下、このカウンタを送信カ
ウンタと呼ぶ。

【０１５８】第１のキューも同時に動作する操作情報交
換プログラム２０１間で共有されるものであり、状態変
化待ちを行っているプログラムのプロセスＩＤを格納す
る。初期値は空である。以下、このキューを状態変化待
ちキューと呼ぶ。

【０１５９】第２のキューは、制御プログラム１４３と
の間で共有されるものであり、操作情報データの受け渡
しに用いられる。以下、このキューを操作データキュー
と呼ぶ。

【０１６０】２つの状態フラグは、通信制御プログラム
２０２で示した送信待ちフラグおよび受信待ちフラグで
ある。

【０１６１】図２３および図２４は操作情報交換プログ
ラム２０１の処理手順を示すフローチャートである。こ
の処理は、被操作装置１２０内のＣＰＵ（図示せず）が
同じく被操作装置１２０内のＲＯＭ（図示せず）に記憶
された操作情報交換プログラム２０１を実行することに
よって行われる。

【０１６２】操作情報交換プログラム２０１は、通信制
御プログラム２０２によって所定数起動される。ここで
は、ｎ個起動される場合を示す。起動すると、まず、要
求カウンタの値を読み込む（ステップＳ２０００）。要
求カウンタの値ｉを判別する（ステップＳ２０１０）。

【０１６３】ここで、前記第２の実施形態で示したよう
に、操作イベントをｍ個のプログラムで待つ場合（ただ
し、ｍは１以上ｎ未満の整数）、要求カウンタの値ｉが
「０」から「ｍ−１」である場合、状態変化がなくとも
状態通知を行うために、ステップＳ２０５０の処理に移
行する。

【０１６４】一方、要求カウンタの値ｉが「ｎ」である
場合、いずれかの要求が戻るまで待つために、ステップ
Ｓ２０００の処理に戻る。また一方、要求カウンタの値
ｉが「ｍ」から「ｎ−１」である場合、状態変化を待つ
ために、自身のプロセスＩＤを状態変化待ちキューに入
れる（ステップＳ２０２０）。

【０１６５】そして、自身がキューの先頭に出るまで待
ち（ステップＳ２０３０）、先頭になった場合、状態変
化が起るまで待ち（ステップＳ２０４０）、状態変化が
起こった場合、状態変化待ちキューから自身のＩＤを抜
く（ステップＳ２０４５）。

【０１６６】排他制御を行うために、送信待ちフラグが
「０」になるのを待つ（ステップＳ２０５０）。操作情
報交換プログラム２０１は、自身のプロセスＩＤを送信
待ちフラグに入れて「０」以外の値とし、排他制御を実
現する（ステップＳ２０６０）。

【０１６７】排他制御に入った場合、前述したステップ
Ｓ８０４の処理と同様、状態情報を収集し（ステップＳ
２０７０）、前述したステップＳ８０５の処理と同様、
送信カウンタの値を読み込み（ステップＳ２０８０）、
前述したステップＳ８０６の処理と同様、送信情報を作
成する（ステップＳ２０９０）。

【０１６８】この後、要求カウンタおよび送信カウンタ
の値をそれぞれインクリメントし（ステップＳ２１０
０）、通信制御プログラム２０２に作成した送信情報を
渡してＨＴＴＰサーバプログラム１５１への送信を依頼
した後（ステップＳ２１１０）、送信待ちフラグを値０
に戻して排他制御を抜ける（ステップＳ２１２０）。

【０１６９】そして、ＨＴＴＰサーバプログラム１５１
からの応答データの受信に際しても排他制御を行う。同
様に、受信待ちフラグの値が「０」になるのを待つ（ス
テップＳ２１３０）。操作情報交換プログラム２０１
は、自身のプロセスＩＤを受信待ちフラグに入れて
「０」以外の値とし、排他制御を実現する（ステップＳ
２１４０）。

【０１７０】排他制御セクションでは、ＨＴＴＰサーバ
プログラム１５１からの応答データが通信制御プログラ
ム２０２から転送されてくるのを待つ（ステップＳ２１
５０）。尚、通信制御プログラム２０２が通信を行うコ
ネクションは１本だけであり、また、ＨＴＴＰサーバプ
ログラム１５１がリクエストの到着順にレスポンスを返
すので、受信データの順序が入れ替わって到着すること
はない。したがって、前記第２の実施形態における受信
カウンタ処理は不要である。また、タイムアウト処理も
通信制御プログラム２０２で行われるので、ここでは不
要である。

【０１７１】データを受信すると、前述したステップＳ
８１６と同様、内容が操作情報を伝達するものであるか
否かを判別する（ステップＳ２１６０）。操作情報であ
った場合、前述したステップＳ８１７と同様、操作デー
タキューに追加する（ステップＳ２１７０）。要求カウ
ンタをデクリメントし（ステップＳ２１８０）、受信待
ちフラグを「０」に戻して排他制御セクションを抜け
（ステップＳ２１９０）、ステップＳ２０００に戻り、
同様の処理を繰り返す。

【０１７２】尚、操作情報交換プログラム２０１は、親
プロセスである通信制御プログラム２０２からの割り込
み処理等により、任意の時点で後処理を行った後に終了
する。

【０１７３】［操作表示応答ＣＧＩプログラム２１１］
操作表示応答ＣＧＩプログラム２１１の処理は、前記第
２の実施形態における操作表示応答ＣＧＩプログラム７
５２と基本的に同じである。ただし、複数のプログラム
が並列動作するので、前記第２の実施形態で示したよう
に、ステップＳ９０８では、要求カウンタの値がｍ未満
である場合、操作イベントを待ち、ｍ以上である場合、
操作待ちループを抜けるようにする。さらに、ステップ
Ｓ９０９の操作イベント検出の前後では、操作情報交換
プログラム２０１の状態変化待ちキューと同様、順に操
作イベントを検出するようにする。

【０１７４】また、前述した通り、操作表示応答ＣＧＩ
プログラム２１１からの応答の順序が保たれるので、送
信カウンタ処理が不要である。したがって、送信カウン
タ処理であるステップＳ９１３、Ｓ９１４の処理を削除
し、ステップＳ９１５において送信情報に送信カウンタ
情報を付加する部分を除く。

【０１７５】このように、第４の実施形態では、ＨＴＴ
Ｐの持続的コネクションとパイプライン処理機能を活用
した、より少ない通信資源（通信コネクション）で（コ
ネクションを開く）遅延のない通信が実現され、遠隔操
作システムの通信性能が向上する。

【０１７６】また、通信を司るプログラムを分離独立さ
せることにより、操作情報交換プログラムや操作表示応
答ＣＧＩプログラムを容易に持続的コネクションやパイ
プライン処理に対応させることが可能になる。尚、通信
制御プログラムを独立させる形態は、前記第１の実施形
態に示す状態通知プログラムと操作データ収集プログラ
ムが分離された形態においても、容易に適用可能であ
る。

【０１７７】この場合、状態通知プログラムおよび操作
データ収集プログラムのそれぞれに対して通信制御プロ
グラムを用意し、それぞれの通信制御プログラムにおい
て通信を担わせる形態と、両プログラムに共通の通信制
御プログラムを１つ用意し、両プログラムの通信を担わ
せる形態のどちらも可能である。さらに後者の場合、共
通の通信制御プログラムが状態通知プログラムと操作デ
ータ収集プログラムのそれぞれに対して個別に通信コネ
クションを用意し、それぞれのデータを内部的に分離し
て通信することも可能である。このような各形態におい
て、通信制御プログラム内で持続的コネクションとパイ
プライン処理機能を利用できることは明らかである。

【０１７８】以上が本発明の実施の形態の説明である
が、本発明は、これら実施の形態の構成に限られるもの
ではなく、特許請求の範囲で示した機能、または実施の
形態の構成が持つ機能が達成できる構成であればどのよ
うなものであっても適用可能である。

【０１７９】例えば、上記各実施形態では、ファイアウ
ォールの形態として通過パケット制限および中継プログ
ラムによる形態を用いたが、本発明は、これに限らず、
適用可能である。例えば、ＬＡＮに接続される機器に対
し、ＬＡＮ内の専用のプライベートアドレスと呼ばれる
アドレスを付与し、これをインターネットで用いられる
グローバルなアドレスに変換するＮＡＴ（Ｎｅｔｗｏｒ
ｋＡｄｄｒｅｓｓＴｒａｎｓｌａｔｉｏｎ）機能をＬ
ＡＮとインターネットの接続点に設け、ＬＡＮから発せ
られた通信要求のみをアドレス変換して通信を可能に
し、インターネットから発せられた通信要求に対しては
アドレス変換をしないことで、ファイアウォール機能を
実現している場合にもそのまま適用可能である。

【０１８０】また、本発明は、前述した実施形態の機能
を実現するソフトウェアのプログラムコードを記憶した
記録媒体を用いて、システムあるいは装置にプログラム
を供給することによって達成される場合にも適用できる
ことはいうまでもない。この場合、記憶媒体から読み出
されたプログラムコード自体が本発明の新規な機能を実
現することになり、そのプログラム自体およびそのプロ
グラムを記憶した記憶媒体は本発明を構成することにな
る。

【０１８１】上記実施形態では、図４、図５、図７、図
８、図１０、図１１、図１３、図１４、図１５、図１
６、図１７、図１８、図１９、図２１、図２２、図２
３、図２４のフローチャートに示すプログラムコードは
記憶媒体であるＲＯＭに格納されている。プログラムコ
ードを供給する記憶媒体としては、ＲＯＭに限らず、例
えばフロッピー（登録商標）ディスク、ハードディス
ク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＤＶＤ、不揮発性のメモ
リカードなどを用いることができる。

【０１８２】

【発明の効果】本発明によれば、ファイアウォールの内
部に被操作装置を設置しても、インターネットに接続さ
れた操作端末からファイアウォールを越えて操作でき
る。また、操作の発生があった場合、連続する操作の発
生に備えるようにすることで、全体としての遅延時間を
抑え、通信のパフォーマンスを向上できる。

【図面の簡単な説明】

【図１】第１の実施形態における遠隔操作システムの構
成を示す図である。

【図２】遠隔操作システムの動作シーケンスを示す図で
ある。

【図３】操作伝達サイクルの動作シーケンスを示す図で
ある。

【図４】状態通知プログラム１４１の処理手順を示すフ
ローチャートである。

【図５】操作表示ＣＧＩプログラム１５２の処理手順を
示すフローチャートである。

【図６】情報交換テーブル４０１を示す図である。

【図７】操作データ収集プログラム１４２の処理手順を
示すフローチャートである。

【図８】操作ＣＧＩプログラム１５３の処理手順を示す
フローチャートである。

【図９】第２の実施形態における動作シーケンスを示す
図である。

【図１０】操作情報交換プログラム７４１の処理手順を
示すフローチャートである。

【図１１】図１０につづく操作情報交換プログラム７４
１の処理手順を示すフローチャートである。

【図１２】カウンタテーブルを示す図である。

【図１３】操作表示応答ＣＧＩプログラム７５２の処理
手順を示すフローチャートである。

【図１４】図１３につづく操作表示応答ＣＧＩプログラ
ム７５２の処理手順を示すフローチャートである。

【図１５】第３の実施形態における状態通知プログラム
１０１４１の処理手順を示すフローチャートである。

【図１６】操作表示ＣＧＩプログラム１０１５２の処理
手順を示すフローチャートである。

【図１７】操作データ収集プログラム１０１４２の処理
手順を示すフローチャートである。

【図１８】操作ＣＧＩプログラム１０１５３の処理手順
を示すフローチャートである。

【図１９】図１８につづく操作ＣＧＩプログラム１０１
５３の処理手順を示すフローチャートである。

【図２０】第４の実施形態における遠隔操作システムの
構成を示す図である。

【図２１】通信制御プログラム２０２の処理手順を示す
フローチャートである。

【図２２】図２１につづく通信制御プログラム２０２の
処理手順を示すフローチャートである。

【図２３】操作情報交換プログラム２０１の処理手順を
示すフローチャートである。

【図２４】図２３につづく操作情報交換プログラム２０
１の処理手順を示すフローチャートである。

【符号の説明】

１００インターネット１１０ＬＡＮ１１１ファイアウォール１１２プロキシサーバ１２０被操作装置１２１コントローラ１２２照明１２３ブラインド１３０操作端末１４１状態通知プログラム１４２操作データ収集プログラム１４３制御プログラム１５１ＨＴＴＰサーバプログラム１５２操作表示ＣＧＩプログラム１５３操作ＣＧＩプログラム１５４操作表示ＧＵＩプログラム２０１操作情報交換プログラム２１１操作表示応答ＣＧＩプログラム

フロントページの続き (72)発明者山川正東京都大田区下丸子３丁目30番２号キヤノン株式会社内Ｆターム(参考） 5B085 AC01 BA06 BG07 5B089 HA06 HA10 HB05 JA35 JB22 KA07 KB11 KC29 KC39 5K048 AA06 BA07 DC07 EB02 EB03 EB13 FB15 FC01 HA01 HA02

Claims

【特許請求の範囲】

【請求項１】ネットワークを介して被操作装置および
操作端末が接続され、前記操作端末で作成された操作情
報を用いて前記被操作装置を操作する遠隔操作システム
であって、前記被操作装置は、前記操作端末への通信を発動し、前
記操作情報を前記操作端末に要求する操作情報要求手段
を備え、前記操作端末は、前記発動された通信に応じ、所定時間
だけ操作の発生を待機し、該操作が発生した場合、連続
する操作を監視した後、前記要求された操作情報を前記
被操作装置に返す操作情報応答手段を備えたことを特徴
とする遠隔操作システム。
【請求項２】前記操作情報応答手段は、前記連続する
操作を監視した結果、複数の操作が発生した場合、該複
数の操作に相当する前記操作情報をまとめて返すことを
特徴とする請求項１記載の遠隔操作システム。
【請求項３】前記操作情報応答手段は、前記発生した
操作の優先度が所定値より高い場合、前記連続する操作
を監視することなく、前記操作情報を返すことを特徴と
する請求項１記載の遠隔操作システム。
【請求項４】前記被操作装置は、前記操作情報の要求
とは別に、前記操作端末への通信を発動し、該被操作装
置の状態情報を前記操作端末に通知する状態情報通知手
段を備え、前記操作端末は、前記発動された通信に応じ、待機する
ことなく、前記通知された状態情報の応答を前記被操作
装置に返す状態情報通知応答手段を備えたことを特徴と
する請求項１乃至３のいずれかに記載の遠隔操作システ
ム。
【請求項５】前記操作情報要求手段は、前記操作端末
への通信を発動して前記被操作装置の状態情報を通知す
るとともに、該通信を用いてその応答としての前記操作
情報を要求し、前記操作情報応答手段は、前記通知された状態情報の応
答として、前記通信を用いて前記要求された操作情報を
返すことを特徴とする請求項１乃至３のいずれかに記載
の遠隔操作システム。
【請求項６】前記被操作装置は、前記操作端末との通
信を制御する通信制御手段を独立に備え、前記操作情報要求手段は、前記通信制御手段を用いて前
記操作端末への通信を発動することを特徴とする請求項
１または４記載の遠隔操作システム。
【請求項７】前記被操作装置および前記操作端末間の
通信プロトコルとして、ＨＴＴＰプロトコルを使用する
ことを特徴とする請求項１記載の遠隔操作システム。
【請求項８】前記操作端末は、ＨＴＴＰサーバプログ
ラムを用いて、前記被操作装置からの情報を受信し、前
記状態情報通知応答手段および前記操作情報応答手段
を、前記ＨＴＴＰサーバプログラムから起動されるＣＧ
Ｉプログラムによって実現することを特徴とする請求項
７記載の遠隔操作システム。
【請求項９】前記操作情報応答手段は、前記所定時間
内に操作が発生しなかった場合、操作なしである旨の前
記操作情報を作成することを特徴とする請求項１記載の
遠隔操作システム。
【請求項１０】前記所定時間は、前記被操作装置およ
び前記操作端末間のネットワークあるいは通信プロトコ
ルによって規定される、データ送受信がない期間が持続
した際のコネクション切断タイムアウト時間より短い時
間に設定されることを特徴とする請求項９記載の遠隔操
作システム。
【請求項１１】前記状態情報通知手段、前記操作情報
要求手段、前記状態情報通知応答手段および前記操作情
報応答手段は、複数の通信を用いて並列に動作すること
を特徴とする請求項４記載の遠隔操作システム。
【請求項１２】前記操作情報要求手段または前記操作
情報応答手段が並列に動作している場合、前記操作が発
生するまで待機している前記操作情報応答手段の数を所
定数に制限し、該所定数を越える分の前記操作情報応答
手段は、前記操作なしである旨の前記操作情報を作成す
ることを特徴とする請求項９記載の遠隔操作システム。
【請求項１３】前記被操作装置および前記操作端末間
の通信コネクションとして、ＨＴＴＰ規定の持続的コネ
クションを使用することを特徴とする請求項７記載の遠
隔操作システム。
【請求項１４】ＨＴＴＰ規定のパイプライン処理を使
用することを特徴とする請求項１３記載の遠隔操作シス
テム。
【請求項１５】データ送受信がない期間が所定時間以
上継続した場合、データ送受信を行い、前記持続的コネ
クションを継続させることを特徴とする請求項１３また
は１４記載の遠隔操作システム。
【請求項１６】操作端末で作成された操作情報を用
い、ネットワークを介して被操作装置を操作する遠隔操
作方法であって、前記被操作装置から前記操作端末へ通信を発動し、前記
操作情報を前記操作端末に要求する操作情報要求工程
と、前記発動された通信に応じ、所定時間だけ操作の発生を
待機し、該操作が発生した場合、連続する操作を監視し
た後、前記操作端末から前記要求された操作情報を前記
被操作装置に返す操作情報応答工程とを有することを特
徴とする遠隔操作方法。
【請求項１７】前記操作情報応答工程では、前記連続
する操作を監視した結果、複数の操作が発生した場合、
該複数の操作に相当する前記操作情報をまとめて返すこ
とを特徴とする請求項１６記載の遠隔操作方法。
【請求項１８】前記操作情報応答手段は、前記発生し
た操作の優先度が所定値より高い場合、前記連続する操
作を監視することなく、前記操作情報を返すことを特徴
とする請求項１６記載の遠隔操作方法。
【請求項１９】前記操作情報の要求とは別に、前記操
作端末への通信を発動し、前記被操作装置の状態情報を
前記操作端末に通知する状態情報通知工程と、前記発動された通信に応じ、待機することなく、前記通
知された状態情報の応答を前記被操作装置に返す状態情
報通知応答工程とを有することを特徴とする請求項１６
乃至１８のいずれかに記載の遠隔操作方法。
【請求項２０】前記操作情報要求工程では、前記操作
端末への通信を発動して前記被操作装置の状態情報を通
知するとともに、該通信を用いてその応答としての前記
操作情報を要求し、前記操作情報応答工程では、前記通知された状態情報の
応答として、前記通信を用いて前記要求された操作情報
を返すことを特徴とする請求項１６乃至１８のいずれか
に記載の遠隔操作方法。
【請求項２１】前記操作情報要求工程では、独立に備
えられた通信制御手段を用いて前記操作端末への通信を
発動することを特徴とする請求項１６または１９記載の
遠隔操作方法。
【請求項２２】前記被操作装置および前記操作端末間
の通信プロトコルとして、ＨＴＴＰプロトコルを使用す
ることを特徴とする請求項１６記載の遠隔操作方法。
【請求項２３】前記操作端末は、ＨＴＴＰサーバプロ
グラムを用いて、前記被操作装置からの情報を受信し、
前記状態情報通知応答工程および前記操作情報応答工程
は、前記ＨＴＴＰサーバプログラムから起動されるＣＧ
Ｉプログラムによって実現されることを特徴とする請求
項２２記載の遠隔操作方法。
【請求項２４】前記操作情報応答工程では、前記所定
時間内に操作が発生しなかった場合、操作なしである旨
の前記操作情報を作成することを特徴とする請求項１６
記載の遠隔操作方法。
【請求項２５】前記所定時間は、前記被操作装置およ
び前記操作端末間のネットワークあるいは通信プロトコ
ルによって規定される、データ送受信がない期間が持続
した際のコネクション切断タイムアウト時間より短い時
間に設定されることを特徴とする請求項２４記載の遠隔
操作方法。
【請求項２６】前記状態情報通知工程、前記操作情報
要求工程、前記状態情報通知応答工程および前記操作情
報応答工程は、複数の通信を用いて並列に行われること
を特徴とする請求項１９記載の遠隔操作方法。
【請求項２７】前記操作情報要求工程または前記操作
情報応答工程が並列に行われる場合、前記操作が発生す
るまで待機している前記操作情報応答工程の数を所定数
に制限し、該所定数を越える分の前記操作情報応答工程
では、前記操作なしである旨の前記操作情報を作成する
ことを特徴とする請求項２４記載の遠隔操作方法。
【請求項２８】前記被操作装置および前記操作端末間
の通信コネクションとして、ＨＴＴＰ規定の持続的コネ
クションを使用することを特徴とする請求項２２記載の
遠隔操作方法。
【請求項２９】ＨＴＴＰ規定のパイプライン処理を使
用することを特徴とする請求項２８記載の遠隔操作方
法。
【請求項３０】データ送受信がない期間が所定時間以
上継続した場合、データ送受信を行い、前記持続的コネ
クションを継続させることを特徴とする請求項２８また
は２９記載の遠隔操作方法。
【請求項３１】ネットワークに接続された操作端末か
ら操作される被操作装置であって、前記操作端末への通信を発動し、状態情報を通知する状
態情報通知手段と、前記操作端末への通信を発動し、操作情報を要求する操
作情報要求手段とを備え、前記操作端末は、前記被操作装置からの通信の発動に応
じ、前記通知された状態情報の応答を待機することなく
返す一方、前記要求された操作情報を所定時間待機し、
該操作が発生した場合、連続する操作を監視した後、該
監視の結果、複数の操作が発生した場合、該複数の操作
に相当する前記操作情報をまとめて返すことを特徴とす
る被操作装置。
【請求項３２】ネットワークに接続された被操作装置
を操作する操作端末であって、前記被操作装置からの通信の発動に応じ、前記被操作装
置から通知された状態情報の応答を待機することなく前
記被操作装置に返す状態情報通知応答手段と、前記被操作装置からの通信コネクションの発動に応じ、
前記被操作装置から要求された操作情報を、所定時間待
機し、該操作が発生した場合、連続する操作を監視した
後、該監視の結果、複数の操作が発生した場合、該複数
の操作に相当する前記操作情報をまとめて前記被操作装
置に返す操作情報応答手段とを備えたことを特徴とする
操作端末。
【請求項３３】請求項１６乃至３０のいずれかに記載
の遠隔操作方法を実現するためのプログラムコードを保
持する記憶媒体。
【請求項３４】請求項１６乃至３０のいずれかに記載
の遠隔操作方法を実現するためのプログラムコードを有
するプログラム。