JPWO2007039942A1 - 端末装置及びサーバ装置及び指令装置 - Google Patents

Abstract

ファイアウォール等の設定を変更することなく、安全かつ確実に、サーバ装置から端末装置へのアクセスを可能にする。端末装置１００は、サーバ装置２００に対し、端末装置１００が実行すべきコマンド（実行指令）があるか否かを問い合わせる指令問い合わせ７１１，７１２を、ＨＴＴＰリクエストの形式で送信する（Ｓ１２）。サーバ装置２００は、端末装置１００に対し、端末装置１００が実行すべきコマンドがある場合にはそのコマンドを含むリプライデータ７２１，７２２（指令回答）を、ＨＴＴＰリクエストに対するＨＴＴＰレスポンスの形式で送信する（Ｓ２６、Ｓ２９）。端末装置１００は、リプライデータ７２１，７２２にコマンドが含まれている場合に、そのコマンドを実行する。

Description

本発明は、ゲートウェイ装置を介してインターネットに接続したＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）に接続した装置（端末装置）に対して、インターネットに接続した装置（サーバ装置）からアクセスする技術に関する。

ゲートウェイ装置を介して、インターネットに接続したＬＡＮに接続した装置（端末装置）に対して、インターネットに接続した装置（サーバ装置）からアクセスをするには様々な制限がある。

例えば、端末装置がグローバルＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）アドレスを持たず、ローカルＩＰアドレスしか持たない場合、ゲートウェイ装置（ルータ）が、ＮＡＴ（Ｎｅｔｗｏｒｋ Ａｄｄｒｅｓｓ Ｔｒａｎｓｌａｔｉｏｎ）機能やＮＡＰＴ（Ｎｅｔｗｏｒｋ Ａｄｄｒｅｓｓ Ｐｏｒｔ Ｔｒａｎｓｌａｔｉｏｎ）機能を用いて、ＩＰアドレスやポート番号の変換を行う技術がある。
ＮＡＴ機能やＮＡＰＴ機能により、端末装置のＩＰアドレスやポート番号の変換を行う場合、端末装置からのリクエストによって、サーバ装置は、端末装置のＩＰアドレスやポート番号を知る。したがって、サーバ装置側から、能動的に端末装置にアクセスすることは困難である。
この課題を解決するための技術として、例えば、特許文献１がある。

また、セキュリティ上の観点から、ゲートウェイ装置が、サーバ装置から端末装置へのアクセスを制限する技術（いわゆるファイアウォール）がある。
ファイアウォール技術には、様々なものがあるが、端末装置からサーバ装置へのアクセス及びそれに対するサーバ装置からの応答は許可し、それ以外のサーバ装置から端末装置へのアクセスは制限するという方式が、広く行われている。
特開２００４−１２０５４７号公報

特許文献１に記載の技術は、サーバ装置から端末装置へのアクセスにＵＤＰ（Ｕｓｅｒ
Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）を用いている。
しかし、ＵＤＰには、通信開始等の手続がないので、端末装置とサーバ装置とのどちらから通信を始めたのか判別することは難しい。
したがって、ファイアウォール技術において、ＵＤＰによる通信を一律に制限する場合があり、特許文献１の技術を利用するには、ファイアウォールの設定を直す必要があるという課題がある。また設定変更の結果、セキュリティが低下する場合があるという課題がある。

本発明は、例えば、上記のような課題を解決するためになされたものであり、ファイアウォールの設定を変更するなどの複雑な手続をせず、したがって、セキュリティを低下させずに、サーバ装置から端末装置へのアクセスを可能とすることを目的とする。

本発明に係る端末装置は、
ネットワークを介してサーバ装置と通信する通信装置と、実行指令を実行する実行装置とを有する端末装置において、
上記実行指令の有無を問い合わせる指令問い合わせを、ＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ
Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）リクエストの形式で、上記通信装置を用いて上記サーバ装置に対して送信する問い合わせ送信部と、
上記問い合わせ送信部が送信した指令問い合わせに対する回答を、指令回答として、上記指令問い合わせであるＨＴＴＰリクエストに対するＨＴＴＰレスポンスの形式で、上記通信装置を用いて上記サーバ装置から受信する回答受信部と、
上記回答受信部が受信した指令回答が、実行指令ありを示す内容である場合に、上記実行装置を用いて実行指令を実行する指令実行部と、
を有することを特徴とする。

上記端末装置は、更に、
上記指令実行部が実行指令を実行した結果を、実行結果として、ＨＴＴＰリクエストの形式で、上記通信装置を用いて上記サーバ装置に対して送信する結果送信部を有し、
上記回答受信部は、更に、
上記実行装置が実行すべき他の実行指令の有無を、指令回答として、上記結果送信部が送信した実行結果であるＨＴＴＰリクエストに対するＨＴＴＰレスポンスの形式で、上記通信装置を用いて上記サーバ装置から受信する
ことを特徴とする。

上記指令実行部は、
上記回答受信部が受信した指令回答に実行指令が含まれる場合に、上記指令回答に含まれる実行指令を、上記実行装置を用いて実行する
ことを特徴とする。

上記通信装置は、更に、ネットワークを介して指令装置と通信し、
上記端末装置は、更に、
上記回答受信部が受信した指令回答が、実行指令ありを示す内容である場合に、実行指令の送信を要求する指令送信要求を、ＨＴＴＰリクエストの形式で、上記通信装置を用いて上記指令装置に対して送信する要求送信部と、
上記要求送信部が送信した指令送信要求に対する回答として、上記実行指令を、上記指令送信要求であるＨＴＴＰリクエストに対するＨＴＴＰレスポンスの形式で、上記通信装置を用いて上記指令装置から受信する指令受信部と、
を有し、
上記指令実行部は、上記指令受信部が受信した実行指令を、上記実行装置を用いて実行する
ことを特徴とする。

上記端末装置は、更に、
上記指令実行部が実行指令を実行した結果を、実行結果として、ＨＴＴＰリクエストの形式で、上記通信装置を用いて上記指令装置に対して送信する結果送信部を有し、
上記指令受信部は、更に、
上記実行装置が実行すべき他の実行指令を、上記結果送信部が送信した実行結果であるＨＴＴＰリクエストに対するＨＴＴＰレスポンスの形式で、上記通信装置を用いて上記指令装置から受信する
ことを特徴とする。

上記問い合わせ送信部は、更に、
上記回答受信部が受信した指令回答が、実行指令なしを示す内容である場合に、上記指令問い合わせを、上記通信装置を用いて上記サーバ装置に対して送信する
ことを特徴とする。

本発明に係るサーバ装置は、
ネットワークを介して端末装置と通信する通信装置を有するサーバ装置において、
上記端末装置に実行させる実行指令の有無を問い合わせる指令問い合わせを、ＨＴＴＰリクエストの形式で、上記通信装置を用いて上記端末装置から受信する問い合わせ受信部と、
上記問い合わせ受信部が受信した指令問い合わせに対する回答を、指令回答として、上記指令問い合わせであるＨＴＴＰリクエストに対するＨＴＴＰレスポンスの形式で、上記通信装置を用いて上記端末装置に対して送信する回答送信部と、
を有することを特徴とする。

上記サーバ装置は、更に、
上記端末装置が実行指令を実行した結果を、実行結果として、ＨＴＴＰリクエストの形式で、上記通信装置を用いて上記端末装置から受信する結果受信部を有し、
上記回答送信部は、更に、
上記端末装置に実行させる他の実行指令の有無を、指令回答として、上記実行結果であるＨＴＴＰリクエストに対するＨＴＴＰレスポンスの形式で、上記通信装置を用いて上記端末装置に対して送信する
ことを特徴とする。

上記回答送信部は、
上記端末装置に実行させる実行指令がある場合に、上記実行指令を含む指令回答を、上記通信装置を用いて上記端末装置に対して送信する
ことを特徴とする。

上記サーバ装置は、更に、
上記端末装置に実行させる実行指令を通知する通知装置から、上記実行指令を受信する通知受信部を有し、
上記回答送信部は、
上記通知受信部が実行指令を通知装置から受信した場合に、実行指令ありを示す内容の指令回答を、上記通信装置を用いて上記端末装置に対して送信し、
所定の時間待っても、上記通知受信部が実行指令を通知装置から受信しなかった場合に、実行指令なしを示す内容の指令回答を、上記通信装置を用いて上記端末装置に対して送信する
ことを特徴とする。

上記サーバ装置は、更に、
上記端末装置に実行させる実行指令があることを通知する指令装置から、上記実行指令があることの通知を取得する存在取得部を有し、
上記回答送信部は、
上記存在取得部が、実行指令があることの通知を指令装置から取得した場合に、実行指令ありを示す内容の指令回答を、上記通信装置を用いて上記端末装置に対して送信し、
所定の時間待っても、上記存在取得部が、実行指令があることの通知を指令装置から受信しなかった場合に、実行指令なしを示す内容の指令回答を、上記通信装置を用いて上記端末装置に対して送信する
ことを特徴とする。

本発明にかかる指令装置は、
ネットワークを介して端末装置と通信する通信装置を有する指令装置において、
上記端末装置に実行させる実行指令の送信を要求する指令送信要求を、ＨＴＴＰリクエストの形式で、上記通信装置を用いて上記端末装置から受信する要求受信部と、
上記要求受信部が受信した指令送信要求に対する回答として、上記実行指令を、上記指令送信要求であるＨＴＴＰリクエストに対するＨＴＴＰレスポンスの形式で、上記通信装置を用いて上記端末装置に対して送信する指令送信部と、
を有することを特徴とする。

上記指令装置は、更に、
上記端末装置が実行指令を実行した結果を、実行結果として、ＨＴＴＰリクエストの形式で、上記通信装置を用いて上記端末装置から受信する結果受信部を有し、
上記指令送信部は、更に、
上記端末装置に実行させる他の実行指令を、上記実行結果であるＨＴＴＰリクエストに対するＨＴＴＰレスポンスの形式で、上記通信装置を用いて上記端末装置に対して送信する
ことを特徴とする。

上記指令装置は、更に、
上記端末装置に実行させる実行指令を通知する通知装置から、上記実行指令を受信する通知受信部と、
上記通知受信部が実行指令を受信した場合に、実行指令の有無を上記端末装置に知らせるサーバ装置に対して、実行指令があることを通知する存在通知部と、
を有することを特徴とする。

本発明によれば、例えば、端末装置からサーバ装置に対するＨＴＴＰリクエストに対するＨＴＴＰレスポンスという形式で、サーバ装置から端末装置に対するアクセスが送信されるので、途中に介在するファイアウォール等の設定を変更することなく、サーバ装置から端末装置へのアクセスが可能になるという効果を奏する。

実施の形態１．
実施の形態１を、図１〜図８を用いて説明する。
図１は、この実施の形態における遠隔操作システム６００の全体構成の一例を示すシステム構成図である。
遠隔操作システム６００は、端末装置１００、ルータ装置５００（ゲートウェイ装置）、サーバ装置２００、アプリケーション装置３００（通知装置の一例）を有する。

ルータ装置５００、サーバ装置２００、アプリケーション装置３００は、インターネット４００に接続しており、相互に通信することができる。
端末装置１００は、ＬＡＮ４５０を介してルータ装置５００に接続しており、ルータ装置５００を経由することにより、インターネット４００に接続し、インターネットに接続した装置（例えば、サーバ装置２００）と通信することができる。

ルータ装置５００は、ファイアウォール機能を有している。
ルータ装置５００は、端末装置１００からインターネット側の装置（例えば、サーバ装置２００）に対する通信を許可する。また、それに対する応答として、インターネット側の装置から端末装置１００への通信も許可する。しかし、端末装置１００からの通信に対する応答でない通信は、禁止する。
したがって、端末装置１００からサーバ装置２００へのアクセスは可能であるが、サーバ装置２００から端末装置１００へのアクセスは許可しない。

また、ルータ装置５００は、ＮＡＰＴ機能を有している。
ルータ装置５００は、ＬＡＮ４５０内でのみ有効な端末装置１００のローカルＩＰアドレスを、ＮＡＰＴ機能によって変換し、インターネット側の装置と接続する。

アプリケーション装置３００は、端末装置１００に実行させたい指令（実行指令）を入力する。アプリケーション装置３００は、インターネット４００を介してサーバ装置２００にアクセスし、入力した実行指令を送信する。
サーバ装置２００は、ルータ装置５００を経由して端末装置１００にアクセスし、アプリケーション装置３００から受信した実行指令を、端末装置１００に送信する。
端末装置１００は、実行指令を実行し、ルータ装置５００を経由してインターネット４００を介し、サーバ装置２００に、実行結果を送信する。
サーバ装置２００は、端末装置１００から実行結果を受信する。
アプリケーション装置３００は、インターネット４００を介してサーバ装置２００にアクセスし、サーバ装置２００が受信した実行結果を取得する。

図２は、この実施の形態における端末装置１００のハードウェア構成の一例を示すハードウェア構成図である。
図３は、この実施の形態におけるサーバ装置２００、アプリケーション装置３００のハードウェア構成の一例を示すハードウェア構成図である。
図４は、この実施の形態におけるルータ装置５００のハードウェア構成の一例を示すハードウェア構成図である。

端末装置１００、サーバ装置２００、アプリケーション装置３００、ルータ装置５００は、ＣＰＵ９０１（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ：中央処理装置）、表示装置９０２（例えば、ＣＲＴ（Ｃａｔｈｏｄ Ｒａｙ Ｔｕｂｅ）装置やＬＣＤ（Ｌｉｑｕｉｄ Ｃｒｉｓｔａｌ Ｄｉｓｐｌａｙ）装置など）、入力装置９０３（例えば、キーボードなど）、記憶装置９０４（例えば、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）などの内部記憶装置や、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）装置、ＳＤ（Ｓｅｃｕｒｅｄ Ｄｉｇｉｔａｌ）メモリなどの外部記憶装置）、ネットワークインターフェース装置９０５，９０６を有する。

ＣＰＵ９０１は、記憶装置９０４が記憶したプログラムを実行することにより、以下説明する各機能ブロックを実現する。
表示装置９０２は、ＣＰＵ９０１が実行したプログラムの実行結果等を表示する。
入力装置９０３は、ＣＰＵ９０１に対する指令を入力する。
記憶装置９０４は、ＣＰＵ９０１が実行するプログラムのほか、実行結果のデータなどを記憶する。
ネットワークインターフェース装置９０５は、インターネット４００に接続し、インターネット４００に接続した他の装置との間の通信を行う。
ネットワークインターフェース装置９０６は、ＬＡＮ４５０に接続し、ＬＡＮ４５０に接続した他の装置との間の通信を行う。

端末装置１００は、更に、実行装置９１０を有する。
実行装置９１０は、アプリケーション装置３００からの実行指令に基づいて、様々な機能を実際に実行する装置である。
なお、端末装置１００は、物理的に１つの装置である必要はない。例えば、実行装置９１０と、その他の装置とがＬＡＮ４５０や赤外線通信などの独自のネットワークを介して接続していてもよい。その場合、ＬＡＮ４５０などを介して接続した実行装置９１０を含めたシステム全体が、以下説明する端末装置１００として機能するものであれば、ここにいう「端末装置」に含まれる。

図５は、この実施の形態における端末装置１００、サーバ装置２００、アプリケーション装置３００の機能ブロックの構成の一例を示すブロック構成図である。
なお、図５では、ルータ装置５００、ＬＡＮ４５０、インターネット４００は省略されている。

端末装置１００は、サーバアクセス部１１０、端末制御部１２０（問い合わせ送信部兼結果送信部の一例）、リプライデータ解析部１３０（回答受信部の一例）、コマンド実行部１４０（指令実行部の一例）を有する。

サーバアクセス部１１０は、ネットワークインターフェース装置９０６を用いて、サーバ装置２００と通信する。通信のプロトコルには、ＨＴＴＰを用いる。

なお、この実施の形態では、ＨＴＴＰを用いることとしているが、通信のプロトコルは、ＨＴＴＰに限らず、ＨＴＴＰＳ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ ｏｖｅｒ Ｓｅｃｕｒｅ Ｓｏｃｋｅｔｓ Ｌａｙｅｒ）など通常のゲートウェイ装置、ファイアウォールやプロキシで通過が許可されているプロトコルであれば、他のプロトコルを用いてもよい。
以下の説明において、「ＨＴＴＰリクエスト」という用語を使った場合には、ＨＴＴＰ以外のプロトコルを用いた場合において、ＨＴＴＰプロトコルにおけるＨＴＴＰリクエストに相当するメッセージを含むものとする。また、「ＨＴＴＰレスポンス」という用語を使った場合には、ＨＴＴＰ以外のプロトコルを用いた場合において、ＨＴＴＰプロトコルにおけるＨＴＴＰレスポンスに相当するメッセージを含むものとする。

端末制御部１２０は、サーバ装置２００に、端末装置１００に対する実行指令があるか否かを問い合わせる指令問い合わせを生成し、サーバ装置２００に対して、サーバアクセス部１１０に送信させる。また、コマンド実行部１４０が実行指令を実行した結果を取得し、コマンド実行結果として、サーバ装置２００に対して、サーバアクセス部１１０に送信させる。

リプライデータ解析部１３０は、サーバアクセス部１１０がサーバ装置２００から受信したデータ（リプライデータ）を解析する。リプライデータ解析部１３０は、リプライデータに実行指令が含まれているか否かを判断し、含まれている場合は、コマンド実行部１４０に実行指令を通知する。含まれていない場合は、その旨、端末制御部１２０に通知する。

コマンド実行部１４０は、リプライデータ解析部１３０から通知を受けた実行指令を、実行装置９１０を用いて、実行する。

サーバ装置２００は、端末アクセス受信部２１０、サーバ制御部２２０（回答送信部の一例）、アクセスデータ解析部２３０（問い合わせ受信部兼結果受信部の一例）、アプリケーションアクセス受信部２４０（通知受信部の一例）を有する。

端末アクセス部２１０は、ネットワークインターフェース装置９０５を用いて、端末装置１００と通信する。通信のプロトコルには、ＨＴＴＰ（またはＨＴＴＰＳなど）を用いる。

サーバ制御部２２０は、端末装置１００からの指令問い合わせに対する回答（指令回答）を生成し、端末装置１００に対して、端末アクセス受信部２１０に送信させる。また、端末装置１００が実行指令を実行した結果（実行結果）を、アクセスデータ解析部２３０から取得し、アプリケーション装置３００に対して、アプリケーションアクセス受信部２４０に送信させる。

アクセスデータ解析部２３０は、端末アクセス受信部２１０が端末装置１００から受信したデータ（端末アクセスデータ）や、アプリケーションアクセス受信部２４０がアプリケーション装置３００から受信したデータ（アプリケーションアクセスデータ）を解析し、解析結果をサーバ制御部２２０に通知する。

アプリケーションアクセス受信部２４０は、ネットワークインターフェース装置９０５を用いて、アプリケーション装置３００と通信する。アプリケーション装置３００からコマンド（指令通知）を受信し、アプリケーション装置３００に対して、コマンド実行結果（実行結果）を送信する。

アプリケーション装置３００は、アプリケーションシステム３１０、指令入力部３２０、結果表示部３３０を有する。

アプリケーションシステム３１０は、ネットワークインターフェース装置９０５を用いて、サーバ装置２００と通信する。

指令入力部３２０は、入力装置９０３を用いて、端末装置１００に対する実行指令を入力する。入力した実行指令は、アプリケーションシステム３１０が、サーバ装置２００に対して送信する。

結果表示部３３０は、表示装置９０２を用いて、端末装置１００が実行指令を実行した結果を表示する。表示する実行結果は、アプリケーションシステム３１０がサーバ装置２００から受信する。

次に、端末装置１００の動作について説明する。
図６は、この実施の形態における端末装置１００の処理の流れの一例を示すフローチャート図である。

Ｓ１１において、端末制御部１２０は、指令問い合わせを生成する。指令問い合わせは、サーバ装置２００に、端末装置１００に対する実行指令があるか否かを問い合わせるものである。

Ｓ１２において、サーバアクセス部１１０は、端末制御部１２０が生成した指令問い合わせをサーバ装置２００に対して送信する。
このとき、通信プロトコルにはＨＴＴＰ（またはＨＴＴＰＳなど）を用いる。例えば、端末装置１００に対する指令回答を格納したファイル名を指定した「ＧＥＴ」メソッドの形式で、指令問い合わせを送信する。

Ｓ１３において、サーバアクセス部１１０は、Ｓ１２で送信した指令問い合わせに対する回答（リプライデータ）を受信する。
このときの通信プロトコルも、ＨＴＴＰ（またはＨＴＴＰＳなど）である。例えば、Ｓ１２で送信した「ＧＥＴ」メソッドに対するＨＴＴＰレスポンスとして、指令回答を格納したファイルの内容を転送するという形式で、リプライデータを受信する。

Ｓ１４において、リプライデータ解析部１３０は、リプライデータ（指令回答）にコマンド（実行指令）があるかどうかを解析する。すなわち、リプライデータを解析し、コマンドが含まれているかどうかを判断する。

Ｓ１５において、リプライデータ解析部１３０の解析結果に基づいて、処理を分岐する。リプライデータにコマンドが含まれていない場合には、端末制御部１２０によりＳ１１へ戻る。リプライデータにコマンドが含まれている場合には、Ｓ１６へ進む。

Ｓ１６において、リプライデータ解析部１３０が、リプライデータに含まれているコマンドを、コマンド実行部１４０に渡す。コマンド実行部１４０は、渡されたコマンドを、実行装置９１０を用いて実行する。

Ｓ１７において、コマンド実行部１４０がコマンドを実行した結果を、端末制御部１２０が取得し、コマンド実行結果とする。コマンド実行結果は、サーバアクセス部１１０に渡す。

Ｓ１８において、サーバアクセス部１１０は、端末制御部１２０が取得したコマンド実行結果を受け取り、そのデータを付加してサーバ装置２００に送信する。
このときの通信プロトコルも、ＨＴＴＰ（またはＨＴＴＰＳなど）を用いる。例えば、コマンド実行結果を「ＧＥＴ」メソッドのパラメータとして送信する。あるいは、「ＰＯＳＴ」メソッドを用いてもよい。

その後、Ｓ１３へ進み、サーバアクセス部１１０が、Ｓ１８で送信したコマンド実行結果である「ＧＥＴ」メソッドに対するＨＴＴＰレスポンスとして、リプライデータを受信し、以上の処理を繰り返す。

このように、コマンド実行結果に対するレスポンスも、指令問い合わせに対するレスポンスと同等に扱う。これにより、指令問い合わせの送信を１回省略することができ、通信のトラフィックを削減できるという効果を奏する。

なお、Ｓ１３において、通信障害などにより、リプライデータを受信できなかった場合には、Ｓ１１に戻り、指令問い合わせを再送するものとする。

次に、サーバ装置２００の動作について説明する。
図７は、この実施の形態におけるサーバ装置２００の処理の流れの一例を示すフローチャート図である。

Ｓ２１において、端末アクセス受信部２１０は、端末装置１００からの指令問い合わせ（ＨＴＴＰリクエスト）を受信する。

Ｓ２２において、アプリケーションアクセス受信部２４０は、アプリケーション装置３００から指令通知を受信したかどうかを判断する。受信した場合には、Ｓ２７へ進む。受信していない場合には、Ｓ２３へ進む。

Ｓ２３において、サーバ制御部２２０は、端末装置１００からのＨＴＴＰリクエスト（指令問い合わせ）を端末アクセス受信部２１０が受信してからの経過時間を測定し、所定の時間が経過したかを判断する。

Ｓ２４において、サーバ制御部２２０の判断結果に基づいて、処理を分岐する。所定の時間が経過する前である場合には、Ｓ２２へ戻り、アプリケーション装置３００からのアクセスを受けるのを待つ。所定の時間が経過した場合には、Ｓ２５へ進む。

Ｓ２５において、所定の時間が経過しても、アプリケーション装置３００からのアクセスがない場合には、端末装置１００に実行させるべき実行指令がないと、サーバ制御部２２０が判断する。サーバ制御部２２０は、実行指令を含まないリプライデータ（指令回答）を生成する。この実施の形態では、リプライデータに実行指令が含まれない場合には、端末装置１００が実行すべき実行指令がないことを意味する。

Ｓ２６において、端末アクセス受信部２１０は、サーバ制御部２２０が生成したリプライデータを、端末装置１００に対して送信する。このとき、リプライデータは、端末装置１００からのＨＴＴＰリクエスト（指令問い合わせ）に対する応答（ＨＴＴＰレスポンス）として、送信する。
以上の処理が終わったら、Ｓ２１に戻り、端末装置１００からの次のアクセスを待つ。

Ｓ２７において、アクセスデータ解析部２３０は、アプリケーションアクセス受信部２４０が受信したアプリケーションアクセス（指令通知）を解析し、そのなかに含まれる実行指令を取得する。アクセスデータ解析部２３０は、取得した実行指令を、サーバ制御部２２０に渡す。

Ｓ２８において、サーバ制御部２２０は、アクセスデータ解析部２３０から受け取った実行指令を含むリプライデータを生成する。

Ｓ２９において、端末アクセス受信部２１０は、サーバ制御部２２０が生成したリプライデータを、ＨＴＴＰリクエスト（指令問い合わせ）に対するＨＴＴＰレスポンスとして、端末装置１００に送信する。

Ｓ３０において、端末アクセス受信部２１０は、端末装置１００からのコマンド実行結果（ＨＴＴＰリクエスト）を受信する。

Ｓ３１において、アクセスデータ解析部２３０は、端末アクセス受信部２１０が受信したコマンド実行結果を取得し、アプリケーションアクセス受信部２４０が、アプリケーション装置３００に対して送信する。

以上の処理が終わったら、Ｓ２２に戻り、アプリケーション装置３００からのアクセスを待つ。

次に、遠隔操作システム６００の全体の動作について説明する。
図８は、この実施の形態において、端末装置１００、サーバ装置２００、アプリケーション装置３００の間でやり取りされるメッセージの一例を示すシーケンス図である。

端末装置１００とサーバ装置２００との間でやり取りされるメッセージは、ルータ装置５００を通過する。ルータ装置５００はファイアウォール機能を有しており、許可されたメッセージしか通さない。

端末装置１００は、指令問い合わせ７１１をＨＴＴＰリクエストとして、サーバ装置２００に送信する（Ｓ１２）。

端末装置１００のサーバアクセス部１１０は、指令問い合わせ７１１の送信にあたり、サーバ装置２００との間のＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）セッションを開始する。
ルータ装置５００は、このＴＣＰセッションを開始したのが端末装置１００であることを判別する。ルータ装置５００は、このＴＣＰセッションにおける通信は、端末装置１００からのアクセス及びそれに対する応答であると判断し、通信を許可する。

ルータ装置５００は、指令問い合わせ７１１を受信し、サーバ装置２００に転送する。サーバ装置２００は、指令問い合わせ７１１を受信する（Ｓ２１）。

サーバ装置２００は、所定の時間待ってもアプリケーション装置３００からのアクセスがないので、端末装置１００に対して、コマンド（実行指令）を含まないリプライデータ７２１（指令回答）を送信する（Ｓ２６）。
リプライデータ７２１は、端末装置１００が開始したＴＣＰセッションにおけるＨＴＴＰレスポンスとして送信される。

なお、サーバ装置２００が指令問い合わせ７１１を受信してからリプライデータ７２１を送信するまでの待ち時間は、ルータ装置５００等が無通信状態と判断し、ＴＣＰセッションを終了してしまうことを防ぐため、無通信状態と判断する時間よりも短い時間となるように設定する。

ルータ装置５００は、リプライデータ７２１を受信し、このＴＣＰセッションを開始したのが端末装置１００であるから、リプライデータ７２１を端末装置１００に転送する。

なお、この例では、ルータ装置５００のファイアウォール機能は、ＴＣＰセッションを開始した装置に基づいて、通信を転送するか否かを判断しているが、ルータ装置５００が更に通信の内容を調べて、転送するか否かを判断するファイアウォールもある。
その場合であっても、サーバ装置２００から端末装置１００へのリプライデータ７２１は、端末装置１００が送信したＨＴＴＰリクエストに対するＨＴＴＰレスポンスの形式を取っているので、通常のホームページに対するアクセスにおける通信とまったく同じである。通常の設定であれば、ホームページの閲覧は許可する設定となっているはずであるから、ルータ装置５００は、リプライデータ７２１の送信を禁止せず、端末装置１００に対して転送する。

端末装置１００は、リプライデータ７２１を受信する（Ｓ１３）。リプライデータ７２１はコマンドを含んでいないので、端末装置１００は、すぐに、次の指令問い合わせ７１２をＨＴＴＰリクエストとして、サーバ装置２００に対して送信する（Ｓ１２）。
このとき、指令問い合わせ７１１送信時に開始したＴＣＰセッションを維持しておき、同じセッションで、指令問い合わせ７１２を送信する。

ルータ装置５００は、指令問い合わせ７１２を受信し、この通信を許可して、サーバ装置２００に転送する。

サーバ装置２００は、指令問い合わせ７１２を受信する（Ｓ２１）。

一方、アプリケーション装置３００は、指令入力部３２０がコマンド（実行指令）を入力装置９０３を用いて入力する。入力したコマンドを、アプリケーションシステム３１０が、アプリケーションアクセス７３１（指令通知）として、サーバ装置２００に対して送信する。

サーバ装置２００は、アプリケーションアクセス７３１を受信する（Ｓ２２）。この受信は、指令問い合わせ７１２の受信から所定時間の経過前なので、サーバ装置２００は、すぐに、リプライデータ７２２（コマンドあり）を、端末装置１００に対して、ＨＴＴＰレスポンスとして送信する（Ｓ２９）。

なお、所定時間経過後に、サーバ装置２００がアプリケーションアクセスを受信した場合には、次の指令問い合わせを端末装置１００から受信するのを待ち、すぐに、それに対するリプライデータを送信するものとする。

リプライデータ７２２は、アプリケーションアクセス７３１に含まれていたコマンドを含んでいる。

ルータ装置５００は、リプライデータ７２２を受信し、この通信を許可して、端末装置１００に転送する。

端末装置１００は、リプライデータ７２２を受信する（Ｓ１３）。リプライデータ７２２は、コマンドを含んでいるので、端末装置１００は、そのコマンドを実行する（Ｓ１６）。

端末装置１００は、コマンド実行の結果を、サーバ装置２００に対して、コマンド実行結果７９３として、ＨＴＴＰリクエストの形式で送信する（Ｓ１８）。

なお、コマンドの実行に時間がかかる場合には、ＴＣＰセッションの終了を防ぐため、コマンド実行が終わるのを待たず、指令問い合わせを送信することとしてもよい。

ルータ装置５００は、コマンド実行結果７９３を受信し、この通信を許可して、サーバ装置２００に転送する。

サーバ装置２００は、コマンド実行結果７９３を受信する（Ｓ３０）。サーバ装置２００は、受信したコマンド実行結果を、アプリケーションリプライ７４１として、アプリケーション装置３００に対して送信する（Ｓ３１）。

アプリケーション装置３００は、アプリケーションリプライ７４１を受信する。アプリケーション装置３００の結果表示部３３０は、アプリケーションリプライ７４１に含まれるコマンド実行結果を、表示装置９０２を用いて表示する。

サーバ装置２００は、コマンド実行結果７９３受信から所定時間経過するまで待ち、アプリケーション装置３００からのアクセスがないので、コマンドを含まないリプライデータ７２３を、端末装置１００に対して、ＨＴＴＰレスポンスとして送信する。

このように、端末装置１００とサーバ装置２００との間の通信はすべて、端末装置１００からサーバ装置２００へのＨＴＴＰ（あるいはＨＴＴＰＳなど）アクセス（リクエスト）およびそのリプライ（レスポンス）で実現する。
これにより、端末装置１００とサーバ装置２００との間に介在する装置（例えば、ルータ装置５００）の設定（例えば、ファイアウォールや、ＮＡＰＴ、Ｗｅｂ（ウェブ）プロキシなど）に関わらず、通信が可能であるという効果を奏する。

したがって、この通信をするために、ファイアウォール等の設定を変更する必要がなく、面倒な作業が必要ないだけでなく、セキュリティを高く保つことができるという効果を奏する。

この通信により、サーバ装置２００から端末装置１００に対して、制御コマンドを渡すことができるので、サーバ装置２００から端末装置１００を制御することが可能となる。

また、端末装置１００が、指令回答を受信してから、次の指令問い合わせを送信するまでの時間が十分短ければ、サーバ装置２００と常時接続しているのとほぼ同じである。したがって、端末装置１００に対する制御の時間遅延はほとんどなく、即時の制御が可能である。

このように、端末装置１００からサーバ装置２００に対してＨＴＴＰあるいはＨＴＴＰＳアクセスし、一定期間の間接続した状態にしておき、一旦リプライを返す。その後、すぐに端末装置１００からサーバ装置２００に対して再びアクセスする。これにより、常時接続しているのと同じ効果をもたらしている。本当に常時接続した場合には、途中のルータ装置５００等が無通信状態と判断して自動的にＴＣＰセッションを切断する場合があるが、この実施の形態では、そのような事態は発生しない。また、無通信状態による自動的セッション切断を防ぐために、定期的な通信（ＫｅｅｐＡｌｉｖｅ：キープアライブ）を行う必要もない。

また、端末装置１００とサーバ装置２００との間の通信を、ＴＣＰにより行うので、ＵＤＰを用いる場合と比較して、安全、確実となり、信頼性が高まるという効果を奏する。

ＵＤＰを用いる場合と異なり、通信エラー処理などの複雑な処理をする必要がないので、アプリケーションレベルでの処理が簡略化できる。

ＴＣＰセッション確立には、ネゴシエーションが必要なので、ＵＤＰによる通信よりも、負荷が高く、リソースを消費する。
しかし、この実施の形態では、ＴＣＰセッションの確立動作は、最初に一度だけ行えばよく、その後の通信は、最初に確立したＴＣＰセッションにより行う。したがって、ＴＣＰを用いることにより生じるリソースの消費を最小限に抑えることができるという効果を奏する。

実施の形態２．
実施の形態２を、図９〜図１２を用いて説明する。
この実施の形態における遠隔操作システム６００の全体構成、端末装置１００、サーバ装置２００、アプリケーション装置３００（通知装置の一例）、ルータ装置５００のハードウェア構成は、実施の形態１で説明したものと同様なので、ここでは説明を省略する。

図９は、この実施の形態における端末装置１００、サーバ装置２００、アプリケーション装置３００の機能ブロックの構成の一例を示すブロック構成図である。

端末装置１００は、サーバアクセス事前部１１５、端末制御部１２０（問い合わせ送信部の一例）、要求データ解析部１３５（回答受信部の一例）、サーバ通信部１１６（要求送信部兼指令受信部兼結果送信部の一例）、コマンド実行部１４０（指令実行部の一例）を有する。
このうち、コマンド実行部１４０は、実施の形態１で説明したものと同様なので、ここでは説明を省略する。

サーバアクセス事前部１１５は、ネットワークインターフェース装置９０６を用いて、サーバ装置２００の端末アクセス事前部２１５と通信する。通信のプロトコルには、ＨＴＴＰ（またはＨＴＴＰＳなど）を用いる。

端末制御部１２０は、サーバ装置２００に、端末装置１００に対する実行指令があるか否かを問い合わせる指令問い合わせを生成し、サーバ装置２００の端末アクセス事前部２１５に対して、サーバアクセス事前部１１５に送信させる。

要求データ解析部１３５は、サーバアクセス事前部１１５がサーバ装置２００の端末アクセス事前部２１５から受信したデータ（要求データ）を解析する。要求データ解析部１３５は、要求データに、接続要求が含まれているか否かを判断し、含まれている場合には、サーバ通信部１１６に接続要求を通知する。含まれていない場合は、その旨、端末制御部１２０に通知する。

サーバ通信部１１６は、ネットワークインターフェース装置９０６を用いて、サーバ装置２００の端末通信部２１６と通信する。通信のプロトコルには、ＨＴＴＰ（またはＨＴＴＰＳなど）を用いる。
サーバ通信部１１６は、要求データ解析部１３５から接続要求の通知を受けた場合に、サーバ装置２００の端末通信部２１６に対して、指令送信要求を送信する。
サーバ通信部１１６は、更に、サーバ装置２００の端末通信部２１６が、指令送信要求に対する応答として送信したコマンド（実行指令）を受信する。
サーバ通信部１１６は、受信したコマンドをコマンド実行部１４０に通知する。
サーバ通信部１１６は、コマンド実行部１４０が、通知したコマンドを実行した結果を取得し、コマンド実行結果（実行結果）として、サーバ装置２００の端末通信部２１６に対して送信する。

サーバ装置２００は、端末アクセス事前部２１５（問い合わせ受信部の一例）、サーバ制御部２２０（存在取得部兼回答送信部の一例）、端末通信部２１６（要求受信部兼指令送信部兼結果受信部の一例）、アプリケーションアクセス受信部２４０（通知受信部兼存在通知部の一例）を有する。

端末アクセス事前部２１５は、ネットワークインターフェース装置９０５を用いて、端末装置１００のサーバアクセス事前部１１５と通信する。通信のプロトコルには、ＨＴＴＰ（またはＨＴＴＰＳなど）を用いる。

サーバ制御部２２０は、端末装置１００からの指令問い合わせに対する回答（指令回答）を生成し、端末装置１００のサーバアクセス事前部１１５に対して、端末アクセス事前部２１５に送信させる。

端末通信部２１６は、ネットワークインターフェース装置９０５を用いて、端末装置１００のサーバ通信部１１６と通信する。通信のプロトコルには、ＨＴＴＰ（またはＨＴＴＰＳなど）を用いる。
端末通信部２１６は、端末装置１００のサーバ通信部１１６が送信した指令送信要求を受信する。
端末通信部２１６は、指令送信要求を受信した場合に、端末装置１００のサーバ通信部１１６に対して、コマンド（実行指令）を送信する。
端末通信部２１６は、端末装置１００がコマンドを実行した結果を、コマンド実行結果（実行結果）として、端末装置１００のサーバ通信部１１６から受信する。

アプリケーションアクセス受信部２４０は、ネットワークインターフェース装置９０５を用いて、アプリケーション装置３００と通信する。アプリケーション装置３００からコマンド（指令通知）を受信し、アプリケーション装置３００に対して、コマンド実行結果（実行結果）を送信する。

アプリケーション装置３００は、実施の形態１で説明したものと同様なので、ここでは説明を省略する。

次に、端末装置１００の動作について説明する。
図１０は、この実施の形態における端末装置１００の処理の流れの一例を示すフローチャート図である。

Ｓ４１において、端末制御部１２０は、指令問い合わせを生成する。

Ｓ４２において、サーバアクセス事前部１１５は、端末制御部１２０が生成した指令問い合わせをサーバ装置２００の端末アクセス事前部２１５に対して送信する。このとき、通信プロトコルはＨＴＴＰ（またはＨＴＴＰＳなど）を用い、ＨＴＴＰリクエスト（例えば、「ＧＥＴ」メソッド）として送信する。

Ｓ４３において、サーバアクセス事前部１１５は、Ｓ４２で送信した指令問い合わせに対する回答（要求データ）を受信する。このときの通信プロトコルもＨＴＴＰであり、例えば、Ｓ１２で送信した「ＧＥＴ」メソッドに対するＨＴＴＰレスポンスとして、要求データを受信する。

Ｓ４４において、要求データ解析部１３５が、要求データ（指令回答）に接続要求があるかどうかを解析する。接続要求がある場合には、端末装置１００が実行すべきコマンド（実行指令）が、サーバ装置２００にあることを意味している。

Ｓ４５において、要求データ解析部１３５の解析結果に基づいて、処理を分岐する。
要求データに接続要求が含まれていない場合には、Ｓ４１に戻り、次の指令問い合わせを送信する。
要求データに接続要求が含まれている場合には、Ｓ４６へ進む。

Ｓ４６において、サーバ通信部１１６は、要求データ解析部１３５からの通知を受けて、サーバ装置２００にあるコマンドの送信を要求する指令送信要求を生成し、サーバ装置２００の端末通信部２１６に対して、ＨＴＴＰリクエスト（例えば、「ＧＥＴ」メソッド）として送信する。

Ｓ４７において、サーバ通信部１１６は、Ｓ４６で送信した指令送信要求に対する回答として、コマンド（実行指令）を受信する。例えば、Ｓ４６で送信した「ＧＥＴ」メソッドに対するＨＴＴＰレスポンスとして、受信する。

Ｓ４８において、コマンド実行部１４０は、サーバ通信部１１６からコマンドを受け取り、受け取ったコマンドを実行する。

Ｓ４９において、コマンド実行部１４０がコマンドを実行した結果を、サーバ通信部１１６が取得し、コマンド実行結果とする。サーバ通信部１１６は、取得したコマンド実行結果を、サーバ装置２００の端末通信部２１６に対して、ＨＴＴＰリクエストとして送信する。

Ｓ５０において、サーバ通信部１１６が、Ｓ４９で送信したＨＴＴＰリクエストに対するＨＴＴＰレスポンスを、所定時間内に受信したかを判断する。
所定時間内にＨＴＴＰレスポンスを受信した場合には、そのなかに次のコマンドが含まれているので、Ｓ４７に戻り、次のコマンドを処理する。
所定時間内にＨＴＴＰレスポンスを受信しなかった場合には、続けて実行すべきコマンドはないので、Ｓ４１に戻る。

なお、所定時間経過前に、コマンド終了を意味するＨＴＴＰレスポンスを受信し、サーバ通信部１１６がそのことを判別して、Ｓ４１に戻ることとしてもよい。

次に、サーバ装置２００の動作について説明する。
図１１は、この実施の形態におけるサーバ装置２００（端末アクセス事前部２１５・サーバ制御部２２０）の処理の流れの一例を示すフローチャート図である。

Ｓ６１において、端末アクセス事前部２１５は、端末装置１００からの指令問い合わせ（ＨＴＴＰリクエスト）を受信する。

Ｓ６２において、サーバ制御部２２０は、アプリケーションアクセス受信部２４０から、端末装置１００に実行させるべきコマンドがあるという通知（存在通知）を受けたか否かを判断する。存在通知を受けた場合には、Ｓ６７へ進む。存在通知を受けていない場合には、Ｓ６３へ進む。

Ｓ６７において、サーバ制御部２２０は、端末装置１００に対して、端末通信部２１６へのアクセスを要求する接続要求を含む要求データを生成する。その後、Ｓ６６へ進む。

Ｓ６３において、サーバ制御部２２０は、端末装置１００からのＨＴＴＰリクエスト（指令問い合わせ）を端末アクセス事前部２１５が受信してからの経過時間を測定し、所定の時間が経過したかを判断する。

Ｓ６４において、サーバ制御部２２０の判断結果に基づいて、処理を分岐する。所定の時間が経過する前である場合には、Ｓ６２へ戻り、アプリケーションアクセス受信部２４０からの通知を受けるのを待つ。所定の時間が経過した場合には、Ｓ６５へ進む。

Ｓ６５において、サーバ制御部２２０は、端末装置１００に対して、端末通信部２１６へのアクセスを要求する接続要求を含まない（すなわち、アクセスを要求しない）要求データを生成する。

Ｓ６６において、端末アクセス事前部２１５は、Ｓ６５またはＳ６７でサーバ制御部２２０が生成した要求データを、端末装置１００のサーバアクセス事前部１１５に対して、ＨＴＴＰレスポンスとして送信する。以上の処理が終わったら、Ｓ６１へ戻り、次の指令問い合わせを待つ。

図１２は、この実施の形態におけるサーバ装置２００（端末通信部２１６・アプリケーションアクセス受信部２４０）の処理の流れの一例を示すフローチャート図である。

Ｓ７１において、アプリケーションアクセス受信部２４０は、アプリケーション装置３００から、端末装置１００が実行すべきコマンド（実行指令）を含む指令通知を受信する。

Ｓ７２において、アプリケーションアクセス受信部２４０は、端末装置１００が実行すべきコマンドがあることを、サーバ制御部２２０に通知する（存在通知）。

Ｓ７３において、端末通信部２１６は、端末装置１００のサーバ通信部１１６からの指令送信要求（ＨＴＴＰリクエスト）を受信する。

Ｓ７４において、アプリケーションアクセス受信部２４０は、受信した指令通知に含まれるコマンドを取得する。

Ｓ７５において、端末通信部２１６は、アプリケーションアクセス受信部２４０が取得したコマンドを、端末装置１００のサーバ通信部１１６に対して、ＨＴＴＰレスポンスとして送信する。

Ｓ７６において、端末通信部２１６は、送信したコマンドを端末装置１００が実行した結果を、コマンド実行結果として、端末装置１００のサーバ通信部１１６から受信する。

Ｓ７７において、アプリケーションアクセス受信部２４０は、端末通信部２１６が受信したコマンド実行結果を、アプリケーション装置３００に対して送信する。

Ｓ７８において、アプリケーションアクセス受信部２４０は、アプリケーション装置３００からの指令通知を受信したか否かを判断する。受信した場合には、Ｓ７４へ進み、受信したコマンドを端末装置１００に送信する。受信しなかった場合には、Ｓ７９へ進む。

Ｓ７９において、アプリケーションアクセス受信部２４０は、端末通信部２１６がＨＴＴＰリクエスト（コマンド実行結果）を受信してからの経過時間を測定し、所定の時間が経過したかを判断する。

Ｓ８０において、アプリケーションアクセス受信部２４０の判断結果に基づいて、処理を分岐する。所定の時間が経過する前である場合には、Ｓ７８へ戻り、アプリケーション装置３００からのアクセスを受けるのを待つ。所定の時間が経過した場合には、Ｓ７１に戻り、アプリケーション装置３００からのアクセスを受けるのを待つ。

端末装置１００とサーバ装置２００との間の通信は、サーバアクセス事前部１１５と端末アクセス事前部２１５との間の通信と、サーバ通信部１１６と端末通信部２１６との間の通信との２種類がある。２種類の通信は、どちらもＨＴＴＰプロトコル（またはＨＴＴＰＳなど）を用いる。

サーバアクセス事前部１１５と端末アクセス事前部２１５との間の通信は、通信開始時にＴＣＰセッションを確立し、その後、定期的に指令問い合わせ・指令回答をやり取りすることにより、セッションを維持する。

一方、サーバ通信部１１６と端末通信部２１６との間の通信は、頻度が低いので、ＴＣＰセッション確立後、タイムアウトによって切断した場合には、必要となったときに、再接続する。あるいは、コマンド終了時に、明示的に切断してもよい。また、ＴＣＰセッション切断を指令するコマンドにより、切断することとしてもよい。

このように、端末装置１００とサーバ装置２００との間の通信を、サーバアクセス事前部１１５と端末アクセス事前部２１５との間の通信と、サーバ通信部１１６と端末通信部２１６との間の通信とに分けて行う。例えば、端末アクセス事前部２１５が使用するポート番号と端末通信部２１６が使用するポート番号とを異なるポート番号とすることにより、両者の通信を区別する。あるいは、２つのＩＰアドレスを使い分けることにより、両者の通信を区別してもよい。

端末アクセス事前部２１５は、指令問い合わせ・指令応答を担当する。指令問い合わせ・指令応答は、端末装置１００が実行すべきコマンドがない場合でも、定常的にやり取りされるものなので、１回あたりの処理は軽いが、数が多い。特に、１つのサーバ装置２００が受け持つ端末装置１００が多数ある場合には、指令問い合わせ・指令応答の数は、膨大となる。

一方、端末通信部２１６は、指令送信要求・実行指令・実行結果を担当する。指令送信要求・実行指令・実行結果は、端末装置１００が実行すべき実行指令がある場合にのみ、やり取りされるものなので、数は少ないが、１回あたりの処理が重い。

この２種類の通信を区別することにより、サーバ装置２００が受信するメッセージの大多数を占める指令問い合わせを受信した際に、それが指令問い合わせであることを判別する処理を省くことができる。これにより削減できる負荷はわずかであるが、指令問い合わせの数が膨大なので、全体として大幅な負荷の削減ができるという効果を奏する。

実施の形態３．
実施の形態３を、図１３〜図１５を用いて説明する。
図１３は、この実施の形態における遠隔操作システム６００の全体構成の一例を示すシステム構成図である。
遠隔操作システム６００は、端末装置１００、ルータ装置５００、サーバ装置２００、指令装置２５０、アプリケーション装置３００（通知装置の一例）を有する。

端末装置１００、ルータ装置５００、サーバ装置２００、アプリケーション装置３００のハードウェア構成は、実施の形態１で説明したものと同様であるので、ここでは説明を省略する。
指令装置２５０のハードウェア構成は、サーバ装置２００と同様である。

図１４は、この実施の形態における端末装置１００、サーバ装置２００、指令装置２５０、アプリケーション装置３００の機能ブロックの構成の一例を示すブロック構成図である。
端末装置１００、アプリケーション装置３００は、実施の形態２で説明したものと同様であるので、ここでは説明を省略する。

サーバ装置２００は、端末アクセス事前部２１５、サーバ制御部２２０を有する。
指令装置２５０は、端末通信部２１６、アプリケーションアクセス受信部２４０を有する。
端末アクセス事前部２１５、サーバ制御部２２０、端末通信部２１６、アプリケーションアクセス受信部２４０は、実施の形態２で説明したサーバ装置２００の機能ブロックと同様なので、ここでは説明を省略する。

この実施の形態は、実施の形態２のサーバ装置２００を、２つの装置（サーバ装置２００、指令装置２５０）に分けたものである。

図１５は、この実施の形態において、端末装置１００、サーバ装置２００、指令装置２５０、アプリケーション装置３００の間でやり取りするメッセージの一例を示すシーケンス図である。

端末装置１００は、指令問い合わせ７１１を、サーバ装置２００に送信する（Ｓ４２）。
サーバ装置２００は、指令問い合わせ７１１を受信する（Ｓ６１）。

一方、アプリケーション装置３００は、指令入力部３２０がコマンド（実行指令）を入力装置９０３を用いて入力する。入力したコマンドを、アプリケーションシステム３１０が、アプリケーションアクセス７３１（指令通知）として、指令装置２５０に対して送信する。

指令装置２５０は、アプリケーションアクセス７３１を受信する（Ｓ７１）。
指令装置２５０は、端末装置１００が実行すべきコマンドがあることを知らせる存在通知７７１を、サーバ装置２００に対して送信する（Ｓ７２）。

サーバ装置２００は、存在通知７７１を受信する（Ｓ６２）。指令問い合わせ７１１受信から所定時間経過前に受信したので、サーバ装置２００は、要求データ７５１（コマンドあり）を、端末装置１００に対して送信する（Ｓ６６）。

なお、指令装置２５０が複数ある場合には、要求データ７５１に、端末装置１００が実行すべきコマンドを有する指令装置２５０を示す情報（例えば、ＩＰアドレス）を含めることにより、端末装置１００がどの指令装置２５０にアクセスすべきかを指定することとしてもよい。

端末装置１００は、要求データ７５１（指令回答）を受信する（Ｓ４３）。
端末装置１００は、要求データ７５１を解析し、コマンドありなので、指令送信要求７６１を、指令装置２５０に対して送信する（Ｓ４６）。

指令装置２５０は、指令送信要求７６１を受信する（Ｓ７３）。
指令装置２５０は、コマンド７８１（実行指令）を、端末装置１００に対して送信する（Ｓ７５）。

端末装置１００は、コマンド７８１を受信する（Ｓ４７）。
端末装置１００は、コマンド７８１を実行する（Ｓ４８）。
端末装置１００は、コマンド７８１を実行した結果を、コマンド実行結果７９２（実行結果）として、指令装置２５０に対して送信する（Ｓ５０）。

指令装置２５０は、コマンド実行結果７９２を受信する（Ｓ７６）。
指令装置２５０は、受信したコマンド実行結果７９２を、アプリケーションリプライ７４１として、アプリケーション装置３００に対して送信する。

アプリケーション装置３００は、アプリケーションリプライ７４１を受信する。受信したアプリケーションリプライ７４１からコマンド実行結果を取得し、結果表示部３３０が、表示装置９０２を用いて表示する。

ここで、アプリケーション装置３００では、実行結果を見た利用者が、次のコマンドを入力したものとする。

指令入力部３２０がコマンドを入力し、アプリケーションシステム３１０が、アプリケーションアクセス７３２（指令通知）として、指令装置２５０に対して送信する。

指令装置２５０は、アプリケーションアクセス７３２を受信する（Ｓ７８）。コマンド実行結果７９２受信から所定時間経過前に受信したので、指令装置２５０は、コマンド実行結果７９２（ＨＴＴＰリクエスト）に対するＨＴＴＰレスポンスとして、コマンド７８２を、端末装置１００に対して送信する（Ｓ７５）。

端末装置１００とサーバ装置２００との間の通信、あるいは、端末装置１００と指令装置２５０との間の通信は、すべて端末装置１００からのＨＴＴＰリクエストから始まるＨＴＴＰプロトコルによって行われる。したがって、途中に介在するルータ装置５００等のファイアウォール、ＮＡＰＴ、Ｗｅｂプロキシなどにかかわらず、通信が可能である。

この実施の形態では、サーバ装置２００は、端末装置１００が実行すべき実行指令があるか否かを回答する動作に特化する。指令問い合わせ・指令回答は、端末装置１００が実行すべき実行指令がない場合でも、定常的にやり取りされるものなので、１回あたりの処理は軽いが、数が多い。特に、１つのサーバ装置２００が受け持つ端末装置１００が多数ある場合には、指令問い合わせ・指令応答の数は、膨大となる。

しかし、単位時間あたりの指令問い合わせ・指令応答の数は、指令問い合わせを受信してから指令応答を送信するまでの待ち時間と、サーバ装置２００が受け持つ端末装置１００の数とによって定まる一定数である。したがって、指令問い合わせ・指令応答の処理に必要な処理能力は、一定の定常負荷である。

したがって、サーバ装置２００の処理能力に、トラフィックの輻輳を考慮した余力を持たせる必要がない。これにより、遠隔操作システム６００全体の運用コストを削減できるという効果を奏する。

一方、指令装置２５０は、指令送信要求・実行指令・実行結果の送受信に特化する。これらの通信は、端末装置１００が実行すべき実行指令がある場合にのみ発生するので、数としては少ない。
しかし、アプリケーション装置から指令装置を経由して端末装置に実際に接続してコマンド送付などを実施するので、コマンド送付処理の負荷等により、１回あたりの処理は非常に重い。
また、いつ発生するか予測できないので、トラフィックの輻輳を考慮して、処理能力に余力を持たせる必要がある。

サーバ装置２００と指令装置２５０とを分けることにより、負荷が分散するだけでなく、トラフィックの輻輳により、指令装置２５０が過負荷となった場合でも、サーバ装置２００には影響が出ないので、実行すべき実行指令がない端末装置１００の動作には影響しないという効果を奏する。

また、サーバ装置２００が端末装置１００に送信する指令回答が、指令装置２５０を示す情報（ＩＰアドレスなど）を含む接続要求となっているので、複数の指令装置２５０を用意しておけば、端末装置１００が接続する先を、負荷が軽い指令装置２５０に振り分けることができる（なお、その場合は、アプリケーション装置３００側も、リダイレクション等の処理が必要となる）。

これにより、負荷を分散し、特定の指令装置２５０へ負荷が集中することを防ぐことができるので、指令装置２５０に持たせる処理能力の余力は、少なくてすむ。したがって、遠隔操作システム６００全体の運用コストを削減できるという効果を奏する。

このように、接続要求の処理を行うサーバ装置２００と、実際のデータ通信を行う指令装置２５０とを分けることにより、サーバ装置２００は、端末装置１００のサポート台数に応じた負荷設計をすればよい。また、指令装置２５０は、同時に操作する端末装置１００の台数に応じた負荷設計が可能である。一般的にサポート台数に比べ、操作台数は極めて少ないため、実施の形態１におけるサーバ装置２００の処理能力よりも、この実施の形態のサーバ装置２００の処理能力と指令装置２５０の処理能力の合計のほうが、より少ない処理能力で、同レベルのサービスが可能な遠隔操作システム６００を構築することができる。

端末装置１００とアプリケーション装置３００との間の通信セッションの確立を準備するプロセスでは、端末装置１００からサーバ装置２００へのＨＴＴＰポーリングを実施する。
端末装置１００とアプリケーション装置３００との間の通信セッションを維持管理するプロセスでは、アプリケーション装置３００から、サーバ装置を経由して、端末装置へのＨＴＴＰリクエストの送受信を処理する。このとき、セッション維持管理プロセスは、一種のプロキシの働きをする。
このように、セッション確立準備プロセスと、セッション維持管理プロセスとを、１：Ｎで処理することにより、多数の通信セッションを維持管理した場合であっても、少ないリソースで処理ができる。

以上説明した端末装置、サーバ装置、指令装置、遠隔操作システムは、以下の特徴をもつ。

端末装置は、
（ａ）サーバに対して、端末制御部より得た０個以上のデータを付加してＨＴＴＰあるいはＨＴＴＰＳアクセスし、そのリプライを受信し、そのデータをリプライデータ解析部に渡すサーバアクセス部、
（ｂ）サーバアクセス部から渡されたリプライのデータを解析し、データ内容がコマンドであればコマンド実行部にわたし、コマンドがなければ、なにも処理せずに、端末制御部に制御を渡すリプライデータ解析部、
（ｃ）リプライデータ解析部から受けたコマンドを実行し、そのコマンド実行結果を端末制御部に渡すコマンド実行部、
（ｄ）コマンド実行部から渡されたコマンド実行結果データがあれば、そのデータをサーバアクセス部の付加データとして渡し、リプライデータ解析部から制御を受ければ、サーバアクセス部へは付加データを渡さずに制御を渡すことを繰り返し実行する端末制御部、を有することを特徴とする。

サーバ装置は、
（ａ）端末装置から０個以上のデータが付加されたＨＴＴＰあるいはＨＴＴＰＳアクセスを受けてアクセスデータ解析部に渡し、また、そのリプライとして、サーバ制御部から得たデータを返す端末アクセス受信部、
（ｂ）他のアプリケーションシステムから、端末装置を操作するコマンドデータが付加されたアクセスを受け、その受けた情報をアクセスデータ解析部に渡し、また、サーバ制御部から受けたデータを前述のリプライとしてアプリケーションシステムに返すアプリケーションアクセス受信部、
（ｃ）端末アクセス受信部からアクセスを受けた後、一定時間以内にアプリケーション受信部からのアクセスがある場合は、そのアクセスで得た情報をサーバ制御部に渡し、一定時間以内にアプリケーション受信部からのアクセスがない場合には、何も処理せずに制御をサーバ制御部に渡すアクセスデータ解析部、
（ｄ）アクセスデータ解析部から０個以上のコマンドデータを受けて端末アクセス受信部にデータを渡し、アクセスデータ解析部から得たコマンド実行結果をアプリケーションシステムに返すことを繰り返すサーバ制御部、
を有することを特徴とする。

セッション管理装置（遠隔操作システム）は、上記端末装置と上記サーバ装置とを備えることを特徴とする。

端末装置は、
（ａ）端末制御部による指示に従い、サーバに対して、ＨＴＴＰあるいはＨＴＴＰＳアクセスし、そのリプライを受信し、そのデータをリプライデータ解析手段に渡すサーバアクセス事前部、
（ｂ）サーバアクセス事前部から渡されたリプライのデータを解析し、データ内容が接続要求の場合、サーバ通信部に通知し、接続要求でなければ、端末制御部にその旨を通知する、要求データ解析部、
（ｃ）要求データ解析部からの通知を受けて、サーバにアクセスして、コマンドを受け、その受けたコマンドをコマンド実行部に渡し、また、その受けたコマンドの実行結果を、サーバにアクセスして渡すサーバ通信部、
（ｄ）サーバ通信部から受けたコマンドを実行し、そのコマンド実行結果をサーバ通信部に渡すコマンド実行部、
（ｅ）要求データ解析部から、接続要求が無い旨の情報を得て、サーバアクセス事前部の実行を繰り返し実行する端末制御部、
を有することを特徴とする。

サーバ装置は、
（ａ）端末装置からＨＴＴＰあるいはＨＴＴＰＳアクセスを受け、サーバ制御部からの接続要求があればそのリプライとして接続要求のデータをのせ、なければ、なにもデータを載せずにリプライとして返す端末アクセス事前部、
（ｂ）他のアプリケーションシステムから、端末装置を操作するコマンドデータが付加されたアクセスを受け、それを接続情報としてサーバ制御部にわたし、またその受けた情報を端末通信部に渡し、また、端末通信部から受けたデータを前述のリプライとしてアプリケーションシステムに返すアプリケーションアクセス受信部、
（ｃ）端末からアクセスを受け、そのアクセスにデータがあれば、それをアプリケーションアクセス受信部に渡し、また、そのリプライにアプリケーションアクセス受信部から得たデータを渡す端末通信部、
（ｄ）アプリケーションアクセス受信部からの接続要求を受け、端末アクセス事前部に渡すサーバ制御部、
を有することを特徴とする。

セッション管理装置（遠隔操作システム）は、上記端末装置と上記サーバ装置とを備えることを特徴とする。

サーバ装置は、
（ａ）端末装置からＨＴＴＰあるいはＨＴＴＰＳアクセスを受け、サーバ制御部からの接続要求があればそのリプライとして接続要求のデータをのせ、なければ、なにもデータを載せずにリプライとして返す端末アクセス事前部、
（ｂ）他のアプリケーションシステムから、端末装置を操作するコマンドデータが付加されたアクセスを受け、それを接続情報としてサーバ制御部にわたし、またその受けた情報を端末通信部に渡し、また、端末通信部から受けたデータを前述のリプライとしてアプリケーションシステムに返すアプリケーションアクセス受信部、
を有することを特徴とする。

上記サーバ装置と異なるサーバ装置（指令装置）は、
（ｃ）端末からアクセスを受け、そのアクセスにデータがあれば、それをアプリケーションアクセス受信部に渡し、また、そのリプライにアプリケーションアクセス受信部から得たデータを渡す端末通信部、
（ｄ）アプリケーションアクセス受信部からの接続要求を受け、端末アクセス事前部に渡すサーバ制御部、
を有することを特徴とする。

セッション管理装置（遠隔操作システム）は、上記端末装置と、上記サーバ装置と、上記サーバ装置と異なるサーバ装置（指令装置）とを備えることを特徴とする。

端末装置は、
ネットワーク障害などで端末装置とサーバ装置との間の接続が切れた場合にも、再度サーバアクセス部により、再接続を行うことを特徴とする。

これにより、Ｗｅｂアクセスが可能な環境であれば、既に設定されているセキュリティを保持し、ルータの設定などの変更も不要でインターネット側のサーバ装置からＬＡＮ側の端末装置への即時のアクセスが可能となる。

なお、実行装置は、端末装置に内在している必要はなく、端末装置からＬＡＮや独自のネットワーク等で接続した形式でもよい。
例えば、冷熱機器システムにおいては、実行装置としての冷熱機器（例えば、エアコンの室内機や室外機）と、それらを統合的に管理制御する冷熱機器コントローラ（端末制御装置）とが、別々の装置として存在する場合がある。
この場合、冷熱機器コントローラ（端末制御装置）は独自のネットワークで各冷熱機器（実行装置）と接続し、冷熱機器コントローラ（端末制御装置）は、ＬＡＮ等にてルータ装置を経由してインターネット上のサーバ装置に接続する。

この例において、冷熱機器（実行装置）と冷熱機器コントローラ（端末制御装置）とを含めた冷熱機器システム全体が、この明細書における「端末装置」に該当する。
また、実行装置を内在しない１つの端末制御装置に複数の実行装置が接続した形態の端末装置であってもよい。
同様に、給湯器システム、床暖房システム、照明システム、エレベータシステム、オール電化システム、セキュリティシステム、監視カメラシステムあるいはＦＡシステムなどの各機器（実行装置）と各制御コントローラ（端末制御装置）も同様の関係であれば、システム全体として、この明細書における「端末装置」に該当する。

実施の形態１における遠隔操作システム６００の全体構成の一例を示すシステム構成図。 実施の形態１における端末装置１００のハードウェア構成の一例を示すハードウェア構成図。 実施の形態１におけるサーバ装置２００、アプリケーション装置３００のハードウェア構成の一例を示すハードウェア構成図。 実施の形態１におけるルータ装置５００のハードウェア構成の一例を示すハードウェア構成図。 実施の形態１における端末装置１００、サーバ装置２００、アプリケーション装置３００の機能ブロックの構成の一例を示すブロック構成図。 実施の形態１における端末装置１００の処理の流れの一例を示すフローチャート図。 実施の形態１におけるサーバ装置２００の処理の流れの一例を示すフローチャート図。 実施の形態１において、端末装置１００、サーバ装置２００、アプリケーション装置３００の間でやり取りされるメッセージの一例を示すシーケンス図。 実施の形態２における端末装置１００、サーバ装置２００、アプリケーション装置３００の機能ブロックの構成の一例を示すブロック構成図。 実施の形態２における端末装置１００の処理の流れの一例を示すフローチャート図。 実施の形態２におけるサーバ装置２００（端末アクセス事前部２１５・サーバ制御部２２０）の処理の流れの一例を示すフローチャート図。 実施の形態２におけるサーバ装置２００（端末通信部２１６・アプリケーションアクセス受信部２４０）の処理の流れの一例を示すフローチャート図。 実施の形態３における遠隔操作システム６００の全体構成の一例を示すシステム構成図。 実施の形態３における端末装置１００、サーバ装置２００、指令装置２５０、アプリケーション装置３００の機能ブロックの構成の一例を示すブロック構成図。 実施の形態３において、端末装置１００、サーバ装置２００、指令装置２５０、アプリケーション装置３００の間でやり取りするメッセージの一例を示すシーケンス図。

符号の説明

１００ 端末装置、１１０ サーバアクセス部、１１５ サーバアクセス事前部、１１６ サーバ通信部、１２０ 端末制御部、１３０ リプライデータ解析部、１４０ コマンド実行部、２００ サーバ装置、２１０ 端末アクセス受信部、２１５ 端末アクセス事前部、２１６ 端末通信部、２２０ サーバ制御部、２３０ アクセスデータ解析部、２４０ アプリケーションアクセス受信部、３００ アプリケーション装置、３１０ アプリケーションシステム、３２０ 指令入力部、３３０ 結果表示部、４００ インターネット、５００ ルータ装置、７１１〜７１２ 指令問い合わせ、７２１〜７２３ リプライデータ、７３１〜７３２ アプリケーションアクセス、７４１ アプリケーションリプライ、７５１ 要求データ、７６１ 指令送信要求、７７１ 存在通知、７８１〜７８２ コマンド、７９２〜７９３ コマンド実行結果、９０１ ＣＰＵ、９０２ 表示装置、９０３ 入力装置、９０４ 記憶装置、９０５，９０６ ネットワークインターフェース装置、９１０ 実行装置。

Claims (14)

1. ネットワークを介してサーバ装置と通信する通信装置と、実行指令を実行する実行装置とを有する端末装置において、
   上記実行指令の有無を問い合わせる指令問い合わせを、ＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ
   Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）リクエストの形式で、上記通信装置を用いて上記サーバ装置に対して送信する問い合わせ送信部と、
   上記問い合わせ送信部が送信した指令問い合わせに対する回答を、指令回答として、上記指令問い合わせであるＨＴＴＰリクエストに対するＨＴＴＰレスポンスの形式で、上記通信装置を用いて上記サーバ装置から受信する回答受信部と、
   上記回答受信部が受信した指令回答が、実行指令ありを示す内容である場合に、上記実行装置を用いて実行指令を実行する指令実行部と、
   を有することを特徴とする端末装置。
2. 上記端末装置は、更に、
   上記指令実行部が実行指令を実行した結果を、実行結果として、ＨＴＴＰリクエストの形式で、上記通信装置を用いて上記サーバ装置に対して送信する結果送信部を有し、
   上記回答受信部は、更に、
   上記実行装置が実行すべき他の実行指令の有無を、指令回答として、上記結果送信部が送信した実行結果であるＨＴＴＰリクエストに対するＨＴＴＰレスポンスの形式で、上記通信装置を用いて上記サーバ装置から受信する
   ことを特徴とする請求項１に記載の端末装置。
3. 上記指令実行部は、
   上記回答受信部が受信した指令回答に実行指令が含まれる場合に、上記指令回答に含まれる実行指令を、上記実行装置を用いて実行する
   ことを特徴とする請求項１に記載の端末装置。
4. 上記通信装置は、更に、ネットワークを介して指令装置と通信し、
   上記端末装置は、更に、
   上記回答受信部が受信した指令回答が、実行指令ありを示す内容である場合に、実行指令の送信を要求する指令送信要求を、ＨＴＴＰリクエストの形式で、上記通信装置を用いて上記指令装置に対して送信する要求送信部と、
   上記要求送信部が送信した指令送信要求に対する回答として、上記実行指令を、上記指令送信要求であるＨＴＴＰリクエストに対するＨＴＴＰレスポンスの形式で、上記通信装置を用いて上記指令装置から受信する指令受信部と、
   を有し、
   上記指令実行部は、上記指令受信部が受信した実行指令を、上記実行装置を用いて実行する
   ことを特徴とする請求項１に記載の端末装置。
5. 上記端末装置は、更に、
   上記指令実行部が実行指令を実行した結果を、実行結果として、ＨＴＴＰリクエストの形式で、上記通信装置を用いて上記指令装置に対して送信する結果送信部を有し、
   上記指令受信部は、更に、
   上記実行装置が実行すべき他の実行指令を、上記結果送信部が送信した実行結果であるＨＴＴＰリクエストに対するＨＴＴＰレスポンスの形式で、上記通信装置を用いて上記指令装置から受信する
   ことを特徴とする請求項４に記載の端末装置。
6. 上記問い合わせ送信部は、更に、
   上記回答受信部が受信した指令回答が、実行指令なしを示す内容である場合に、上記指令問い合わせを、上記通信装置を用いて上記サーバ装置に対して送信する
   ことを特徴とする請求項１に記載の端末装置。
7. ネットワークを介して端末装置と通信する通信装置を有するサーバ装置において、
   上記端末装置に実行させる実行指令の有無を問い合わせる指令問い合わせを、ＨＴＴＰリクエストの形式で、上記通信装置を用いて上記端末装置から受信する問い合わせ受信部と、
   上記問い合わせ受信部が受信した指令問い合わせに対する回答を、指令回答として、上記指令問い合わせであるＨＴＴＰリクエストに対するＨＴＴＰレスポンスの形式で、上記通信装置を用いて上記端末装置に対して送信する回答送信部と、
   を有することを特徴とするサーバ装置。
8. 上記サーバ装置は、更に、
   上記端末装置が実行指令を実行した結果を、実行結果として、ＨＴＴＰリクエストの形式で、上記通信装置を用いて上記端末装置から受信する結果受信部を有し、
   上記回答送信部は、更に、
   上記端末装置に実行させる他の実行指令の有無を、指令回答として、上記実行結果であるＨＴＴＰリクエストに対するＨＴＴＰレスポンスの形式で、上記通信装置を用いて上記端末装置に対して送信する
   ことを特徴とする請求項７に記載のサーバ装置。
9. 上記回答送信部は、
   上記端末装置に実行させる実行指令がある場合に、上記実行指令を含む指令回答を、上記通信装置を用いて上記端末装置に対して送信する
   ことを特徴とする請求項７に記載のサーバ装置。
10. 上記サーバ装置は、更に、
    上記端末装置に実行させる実行指令を通知する通知装置から、上記実行指令を受信する通知受信部を有し、
    上記回答送信部は、
    上記通知受信部が実行指令を通知装置から受信した場合に、実行指令ありを示す内容の指令回答を、上記通信装置を用いて上記端末装置に対して送信し、
    所定の時間待っても、上記通知受信部が実行指令を通知装置から受信しなかった場合に、実行指令なしを示す内容の指令回答を、上記通信装置を用いて上記端末装置に対して送信する
    ことを特徴とする請求項７に記載のサーバ装置。
11. 上記サーバ装置は、更に、
    上記端末装置に実行させる実行指令があることを通知する指令装置から、上記実行指令があることの通知を取得する存在取得部を有し、
    上記回答送信部は、
    上記存在取得部が、実行指令があることの通知を指令装置から取得した場合に、実行指令ありを示す内容の指令回答を、上記通信装置を用いて上記端末装置に対して送信し、
    所定の時間待っても、上記存在取得部が、実行指令があることの通知を指令装置から受信しなかった場合に、実行指令なしを示す内容の指令回答を、上記通信装置を用いて上記端末装置に対して送信する
    ことを特徴とする請求項７に記載のサーバ装置。
12. ネットワークを介して端末装置と通信する通信装置を有する指令装置において、
    上記端末装置に実行させる実行指令の送信を要求する指令送信要求を、ＨＴＴＰリクエストの形式で、上記通信装置を用いて上記端末装置から受信する要求受信部と、
    上記要求受信部が受信した指令送信要求に対する回答として、上記実行指令を、上記指令送信要求であるＨＴＴＰリクエストに対するＨＴＴＰレスポンスの形式で、上記通信装置を用いて上記端末装置に対して送信する指令送信部と、
    を有することを特徴とする指令装置。
13. 上記指令装置は、更に、
    上記端末装置が実行指令を実行した結果を、実行結果として、ＨＴＴＰリクエストの形式で、上記通信装置を用いて上記端末装置から受信する結果受信部を有し、
    上記指令送信部は、更に、
    上記端末装置に実行させる他の実行指令を、上記実行結果であるＨＴＴＰリクエストに対するＨＴＴＰレスポンスの形式で、上記通信装置を用いて上記端末装置に対して送信する
    ことを特徴とする請求項１２に記載の指令装置。
14. 上記指令装置は、更に、
    上記端末装置に実行させる実行指令を通知する通知装置から、上記実行指令を受信する通知受信部と、
    上記通知受信部が実行指令を受信した場合に、実行指令の有無を上記端末装置に知らせるサーバ装置に対して、実行指令があることを通知する存在通知部と、
    を有することを特徴とする請求項１２に記載の指令装置。

Images