JP6562085B2 - 通信装置、通信システム、通信方法、および、通信プログラム - Google Patents

Description

本発明は、通信装置とその通信装置を用いた通信システム、通信方法に関する。

通信機器の普及により、様々なデバイスをネットワークに接続して通信するＩｏＴ（Internet of Things）が注目されており、様々なサービスを実現するシステムが考案されている。例えば、ネットワークに接続された様々なデバイスとアプリケーションサーバを通信させることにより、遠隔監視システムなどが実現されることもある。遠隔監視システムでは、例えば、監視対象を撮像可能な位置に設置されたカメラを含む通信装置等は、撮像により得られたデータを、適宜、アプリケーションサーバにアップロードする。すると、アプリケーションサーバは、撮像結果が得られていることを、ユーザが使用している電話端末、タブレット、コンピュータなどの通信機器に通知する。ユーザは、アプリケーションサーバからの通知があると、適宜、アプリケーションサーバにアクセスして、撮像結果を確認する。なお、アプリケーションサーバ等にアップロードされるデータは、撮像結果以外の任意のデータであり得る。また、ＩｏＴを用いたシステムは、遠隔監視システム以外の任意のシステムであっても良い。

ＩｏＴを用いたシステムで注目されている通信プロトコルとして、ＭＱＴＴ（Message Queue Telemetry Transport）がある。ＭＱＴＴは、ヘッダ長が短いため、ペイロード中のデータ量が少ない場合に行われる処理による機器への負担が軽く、大量の機器間での通信への適用に適している。

関連する技術として、サービスプロバイダネットワークとユーザデバイスとの間で送受信されるデータを中継するパブリッシュ／サブスクライブブローカを含むシステムが提案されている（例えば、特許文献１など）。また、低解像度のライブビュー画像データをＵＤＰ（User Datagram Protocol）で端末に送信し、静止画像の撮影指示を取得すると、指示に応じて撮影した高解像度の静止画像データを端末に送信するカメラも考案されている（例えば、特許文献２など）。高解像度の静止画像データの送信には、ＴＣＰ（Transmission Control Protocol）が使用される。さらに、ＳＩＰ（Session Initiation Protocol）を使用するファクシミリ装置が識別フレーズを作成し、画像データの送信側と受信側で識別フレーズを交換することで認証を行うデータ送信方法も提案されている（例えば、特許文献３など）。

特表２０１５−５００５２０号公報 特開２０１５−０９５７９９号公報 特開２００８−２６３４４０号公報

パブリッシュ／サブスクライブ型ではないプロトコルでサーバ側からデバイスへの制御メッセージを送信する場合、デバイスがサーバに接続されていないと、通信エラーが発生してしまう。しかし、デバイスとサーバの間で、データ通信に適した転送速度が得られる通信路を常時確保すると、データ通信が行われていないときには無駄に通信路が確保されることになり、効率が悪い。この問題は、ネットワークに接続されるデバイスの数が増えるとさらに深刻になる。一方、パブリッシュ／サブスクライブ型プロトコルは、容量の大きなデータの送信には向いていない。このため、パブリッシュ／サブスクライブ型プロトコルをデータ通信に用いると、かえって効率が悪くなってしまうこともある。また、関連する技術のいずれを適用しても、同様の問題により通信の効率化は困難である。

本発明は、１つの側面として、通信を効率化することを目的とする。

ある１つの態様にかかる通信装置は、受信部、制御部、通信部を備える。受信部は、第１のプロトコルを用いた第１のセッションの接続先から制御メッセージを受信する。制御部は、前記制御メッセージで指定された処理を行うと共に、前記処理に伴う通信処理を前記第１のプロトコルよりもヘッダ長の長い第２のプロトコルを用いて行う場合、前記第２のプロトコルを用いた通信の通信先との間で第２のセッションを確立する。通信部は、前記第１および第２のセッションを用いて通信する。前記制御部は、前記第２のプロトコルを用いた通信が終了すると、前記第２のセッションを終了する。前記通信部は、前記第１のセッションを介して、前記制御メッセージで指定された処理の結果を、前記通信先に通知する。

通信が効率化される。

実施形態にかかる通信の例を説明する図である。 通信装置の構成の例を説明する図である。 通信装置のハードウェア構成の例を説明する図である。 アプリケーションサーバの構成の例を説明する図である。 実施形態にかかる通信が適用されるシステムの例を説明する図である 登録情報テーブルの例を説明する図である。 管理情報テーブルの例を説明する図である。 データがサーバにアップロードされる場合の処理の例を説明するシーケンス図である。 制御メッセージを送信する際のサーバの処理の例を説明するフローチャートである。 ＭＱＴＴサーバでの処理の例を説明するフローチャートである。 通信装置での処理の例を説明するフローチャートである。 応答メッセージを受信した際のサーバの処理の例を説明するフローチャートである。 データがサーバからダウンロードされる場合の処理の例を説明するシーケンス図である。 通信装置でのダウンロード処理の例を説明するフローチャートである。

図１は、実施形態にかかる通信の例を説明する図である。図１に示す例では、ネットワークには、サーバ５ａ、通信装置１０ａ、通信装置２０が含まれているとする。

ケースＣ１は、シーケンスＳＥ１の開始時点での接続状況を示している。ケースＣ１では、サーバ５ａと通信装置１０ａの間に通信セッションＡ２が生成され、通信装置１０ａと通信装置２０の間に通信セッションＡ１が生成されている。通信セッションＡ１およびＡ２では、第１のプロトコル（プロトコルＡ）を用いた通信が行われるものとする。プロトコルＡは、ヘッダ長が比較的短く、ペイロード長が短い場合の処理負荷が比較的軽いプロトコルであるとする。また、通信セッションＡ１、Ａ２は、サーバ５ａと通信装置２０との間での制御情報の送受信に使用される制御メッセージを、プロトコルＡによって送受信する際に使用される。なお、プロトコルＡがパブリッシュ／サブスクライブ型のプロトコルである場合、通信装置１０ａは、ブローカとして動作しても良い。シーケンスＳＥ１では、通信装置１０ａはブローカとして動作する。

シーケンスＳＥ１は、サーバ５ａと通信装置２０の間の通信の例を示している。サーバ５ａは、通信装置２０宛てにプロトコルＡで生成した制御メッセージを、通信セッションＡ２を用いて通信装置１０ａに送信する（ステップＳ１）。通信装置１０ａは、受信した制御メッセージを、通信セッションＡ１を用いて通信装置２０に転送する（ステップＳ２）。

通信装置２０は、制御メッセージを受信すると、制御メッセージで要求されている処理を行う。ここで、制御メッセージで要求された処理は、プロトコルＢによる通信を伴う処理であるとする。例えば、プロトコルＢは、プロトコルＡよりもヘッダ長の長いプロトコルで、容量の大きなデータの転送に適したプロトコルであるとする。すると、通信装置２０は、制御メッセージで要求された処理を行うと共に、処理に起因して発生する通信に使用するために、プロトコルＢを用いる通信セッション（セッションＢ）をサーバ５ａとの間で確立する（ステップＳ３）。

ケースＣ２は、ステップＳ３の処理によってセッションＢが確立されたときの接続状況の例である。セッションＢが確立されている間も、セッションＡ１、Ａ２はプロトコルＡによる制御メッセージの送受信のために維持されている。なお、セッションＢは、サーバ５ａと通信装置２０の間のデータ通信に使用されるので、セッションＢの通信に使用される経路はデータ通信が適切に行われる程度の転送速度が得られる経路である。

セッションＢを確立すると、通信装置２０は、サーバ５ａとの間で、プロトコルＢを用いたデータの送受信を行う（ステップＳ４）。図１の例では、プロトコルＢを用いたデータの送受信は正常終了したとする。通信装置２０は、制御メッセージで要求された処理に起因したプロトコルＢによる通信が終了すると、サーバ５ａとの間のセッションＢを終了する。このため、制御メッセージで要求された処理に起因したプロトコルＢによる通信が終了すると、サーバ５ａと通信装置２０との間は、ケースＣ１に示すように、プロトコルＡでの通信に使用されるセッションのみが確立された状況に戻る。

通信装置２０は、処理の成功をサーバ５ａに通知するための処理成功通知を、セッションＡ１を介して、通信装置１０ａに送信する（ステップＳ５）。通信装置１０ａは、受信した処理成功通知を、セッションＡ２を介して、サーバ５ａに転送する（ステップＳ６）。ここで、ステップＳ５、Ｓ６で送受信される処理成功通知も制御メッセージの一種であるので、処理成功通知の送受信はプロトコルＡによって行われる。

図１を参照しながら説明したように、実施形態にかかる方法では、サーバ５ａと通信装置２０との間の制御メッセージの送受信にはセッションＡ１、Ａ２が使用される。ここで、制御メッセージ中のペイロード量はデータパケットに比べて少ない上、制御メッセージの送受信にはプロトコルＡが用いられる。このため、サーバ５ａと通信装置２０との間で制御メッセージの送受信のために常時接続を行っていても通信量が少ない。従って、セッションＡ１、Ａ２の通信に使用される通信経路を確保しても、ネットワークへの負荷は、データ通信用のセッションが常時接続される場合に比べて小さい。また、セッションＡ１、Ａ２を介して取得した制御メッセージによって、比較的大きなデータの送受信が要求されたなどの理由により、プロトコルＢを用いる通信処理が発生すると、プロトコルＢを用いた通信の間だけプロトコルＢ用のセッションＢが確立される。従って、実施形態にかかる方法を用いると、サーバと通信装置の間にデータ送受信用の経路を常時確保する場合に比べて、ネットワーク中の転送処理に使用されるネットワークリソースが効率的に使用される。また、プロトコルＢは、データ転送に適したプロトコルであるため、データ通信の効率が落ちることも防止できる。

なお、図１の例のように、サーバ５ａと通信装置２０の間のセッションＡ１、Ａ２を用いた制御メッセージの送受信を、ブローカとして動作する通信装置１０ａが中継すると、サーバ５ａと通信装置２０の間が常時接続されていなくても通信エラーが発生しない。このため、さらにシステムが効率化される。

＜装置構成＞
以下、実施形態にかかる通信方法が適用されるシステムが遠隔監視システムであり、通信装置２０が静止画像や動画像を撮像可能な装置である場合を例として説明する。なお、システムの種類や通信装置２０が行う処理の例は一例である。実施形態にかかるシステムは、遠隔監視システム以外のシステムにも適用されることがある。また、通信装置２０は、システム中のサーバからの要求により、撮像処理以外の処理を行うこともある。

図２は、通信装置２０の構成の例を説明する図である。通信装置２０は、通信部２１、制御部３０、記憶部４０、カメラ５０を備える。通信部２１は、受信部２２と送信部２３を有する。制御部３０は、判定部３１、接続制御部３２、アプリケーション処理部３３を有する。

受信部２２は、他の装置からパケットを受信する。送信部２３は、他の装置にパケットを送信する。受信部２２と送信部２３は、第１のプロトコルと第２のプロトコルのいずれが用いられたパケットも処理可能である。制御メッセージは第１のプロトコルで送受信されるものとする。また、第２のプロトコルは、第１のプロトコルと比較して、容量の大きなデータの通信に適したプロトコルであるとする。

判定部３１は、受信部２２を介して取得した制御メッセージを解析することにより、制御メッセージで要求された処理に伴って、第２のプロトコルを用いた通信処理が発生するかを判定する。判定部３１は、予め、第２のプロトコルを用いた通信処理が発生する処理の種類を記憶していても良い。この場合、判定部３１は、制御メッセージで要求された処理の種類と、記憶している情報を用いて判定処理を行う。また、判定部３１は、制御メッセージによって特定の情報要素が含められている場合に、制御メッセージで要求された処理により第２のプロトコルを用いた通信処理が発生すると判定しても良い。

接続制御部３２は、第２のプロトコルを用いた通信処理が発生する場合に、第２のプロトコルを用いた通信での通信先との間の接続処理を行う。さらに、第２のプロトコルを用いた通信処理が終了すると、第２のプロトコルを用いて通信先と通信するためのセッションやコネクションを終了する。アプリケーション処理部３３は、制御メッセージで要求された処理を行う。カメラ５０は、アプリケーション処理部３３によって制御され、通信装置２０での監視対象となっている監視対象や監視領域についての画像データを生成する。記憶部４０は、適宜、制御部３０での処理に使用されるデータを記憶する。

図３は、通信装置２０のハードウェア構成の例を説明する図である。通信装置２０は、プロセッサ１０１、メモリ１０２、バス１０５、撮像装置１０７、ネットワークインタフェース１０９を備える。通信装置２０は、さらに、入力装置１０３、出力装置１０４、記憶装置１０６の１つ以上を有していても良い。プロセッサ１０１は、Central Processing Unit（ＣＰＵ）を含む任意の処理回路であり、メモリ１０２や記憶装置１０６に記憶されたプログラムを実行することができる。プロセッサ１０１は制御部３０を実現する。メモリ１０２と記憶装置１０６は、記憶部４０として動作する。また、通信部２１は、ネットワークインタフェース１０９とプロセッサ１０１により実現される。バス１０５は、プロセッサ１０１、メモリ１０２、入力装置１０３、出力装置１０４、記憶装置１０６、撮像装置１０７、ネットワークインタフェース１０９を、相互にデータの出力や入力が可能になるように接続する。入力装置１０３は、キーボードやマウスなど、情報の入力に使用される任意の装置であり、出力装置１０４は、ディスプレイを含む表示デバイスなど、データの出力に使用される任意の装置である。撮像装置１０７は、カメラ５０として動作する。

図４は、アプリケーションサーバ５の構成の例を説明する図である。図１のサーバ５ａは、アプリケーションサーバ５の例である。アプリケーションサーバ５は、通信部６１、制御部６２、記憶部６５を備える。通信部６１は、通信装置２０などの他の装置との間での通信を行う。制御部６２は、アプリケーションサーバ５が提供するアプリケーションの処理を行う他、適宜、セッションの生成等の制御処理も行う。記憶部６５は、登録情報テーブル６６と管理情報テーブル６７を備える。登録情報テーブル６６には、アプリケーションサーバ５が提供するアプリケーションを使用するユーザの情報が登録される。管理情報テーブル６７には、ユーザから要求された処理を通信装置２０に要求する際や、処理結果をユーザの端末１５に通知する際に使用される管理情報が記録される。登録情報テーブル６６と管理情報テーブル６７の例は後述する。

アプリケーションサーバ５のハードウェア構成は、図３に示した通信装置２０のハードウェア構成と同様であるが、アプリケーションサーバ５は、撮像装置１０７を備えなくてもよい。すなわち、アプリケーションサーバ５は、プロセッサ１０１、メモリ１０２、バス１０５、ネットワークインタフェース１０９を備えており、オプションとして、入力装置１０３、出力装置１０４、記憶装置１０６の１つ以上を有していても良い。また、アプリケーションサーバ５にも撮像装置１０７が含まれていてもよい。

アプリケーションサーバ５において、プロセッサ１０１は制御部６２として動作し、メモリ１０２や記憶装置１０６は記憶部６５として動作する。さらに、通信部６１は、ネットワークインタフェース１０９とプロセッサ１０１によって実現される。

＜実施形態＞
以下の例では、第１のプロトコルがＭＱＴＴであり、第２のプロトコルがＨＴＴＰ（Hypertext Transfer Protocol）である場合を例として説明する。さらに、サーバ５ａは、遠隔監視システムのアプリケーションサーバ５であり、通信装置１０ａはＭＱＴＴサーバ１０であるとする。なお、通信で使用されるプロトコルは一例であり、実装に応じて使用されるプロトコルは変更され得る。すなわち、第１のプロトコルはＭＱＴＴに限定されず、また、第２のプロトコルもＨＴＴＰに限定されないものとする。例えば、第２のプロトコルとして、ＦＴＰ（File Transfer Protocol）が使用されても良い。また、遠隔監視システムで監視される監視対象も任意である。例えば、監視対象は、ユーザが世話をしているペット、高齢者などであってもよく、また、ユーザが状況を確認しようとする生産ラインの機械などであってもよい。

図５は、実施形態にかかる通信が適用されるシステムの例を説明する図である。なお、図５は、システムの一例であり、例えば、通信装置２０や端末１５の数は実装に応じて任意に変更され得る。

アプリケーションサーバ５とＭＱＴＴサーバ１０は、インターネット３に含まれている。また、インターネット３は３Ｇ−ＬＴＥ（3 Generation - Long Term Evolution）網７と接続されている。ユーザが使用する端末１５（１５ａ〜１５ｃ）は、３Ｇ−ＬＴＥ網７を介してインターネット３中のアプリケーションサーバ５と通信できる。なお、図５はシステムの一例であり、通信装置２０は、３Ｇ−ＬＴＥ網７を介さずにインターネット３だけを介してアプリケーションサーバ５と通信しても良い。図５の例では、端末１５ａはコンピュータ、端末１５ｂはタブレット、端末１５ｃは携帯電話端末であるが、端末１５はユーザがアプリケーションサーバ５にアクセスする際に使用可能な任意の装置である。通信装置２０（２０ａ〜２０ｃ）は、ＭＱＴＴサーバ１０に接続されており、各々の監視対象の近傍に設置されている。

以下、実施形態を、通信装置２０がデータをアップロードする場合の処理の例と、通信装置２０がデータをダウンロードする場合の処理の例に分けて説明する。

（１）通信装置２０がデータをアップロードする場合の処理の例
遠隔監視システムのユーザは、予め、遠隔監視システムの利用者としてのユーザ登録をするとともに、監視対象の近傍に通信装置２０を設置する。また、各ユーザによって監視対象の近傍に設置される通信装置２０には、各通信装置２０を一意に識別するための通信装置ＩＤが割り当てられている。一方、アプリケーションサーバ５は、遠隔監視システムを利用するユーザの情報を登録情報テーブル６６に登録している。

図６は、登録情報テーブル６６の例を説明する図である。登録情報テーブル６６では、各ユーザを識別するユーザＩＤに、通信装置ＩＤと端末ＩＤが対応付けて記録されている。通信装置ＩＤは、ユーザＩＤで識別されるユーザの監視対象の監視のために設置されている通信装置２０を識別する情報である。端末ＩＤは、ユーザＩＤで識別されるユーザがアプリケーションサーバ５にアクセスする際に使用する端末１５に割り当てられている識別子である。端末ＩＤは、ユーザの端末を一意に識別できる任意の情報が使用され得るので、例えば、端末１５が電話端末である場合は、電話番号が端末ＩＤとして使用されてもよい。図６の例では、ユーザＩＤ＝ユーザ１で識別されるユーザは、通信装置ＩＤ＝ｓｔ１の通信装置２０を監視対象の近傍に設置している。また、ユーザ１が使用している端末１５がアプリケーションサーバ５と通信する際には、端末のＩＤとして、ｐｈｏｎ１がアプリケーションサーバ５に通知される。同様に、ユーザＩＤ＝ユーザ２のユーザが使用する通信装置２０の通信装置ＩＤはｓｔ２であり、ユーザＩＤ＝ユーザ２のユーザが使用する端末１５の端末ＩＤはｓｕｍａｈｏ２である。

ユーザは、遠隔監視システムを用いて監視対象の情報を確認しようとする場合に、予め遠隔監視システムに登録している端末１５を用いて、アプリケーションサーバ５に処理要求を送信する。処理要求には、ユーザが要求する処理を特定する際に使用される情報の他、ユーザＩＤと端末ＩＤが含まれる。処理要求は、例えば、ユーザが端末１５中で動作している遠隔監視システムのアプリケーションで表示されているボタンを押下することによって自動生成されて、アプリケーションサーバ５に送信されてもよい。

アプリケーションサーバ５の通信部６１は、処理要求を受信する。制御部６２は、処理要求に含まれているユーザＩＤと端末ＩＤの組み合わせが登録情報テーブル６６に登録されているかを判定する。ユーザＩＤと端末ＩＤの組み合わせが登録情報テーブル６６に含まれている場合、制御部６２は、正規ユーザから制御が要求されていると判定し、管理情報テーブル６７を更新する。

図７は、管理情報テーブル６７の例を説明する図である。管理情報テーブル６７は、アプリケーションサーバ５から通信装置２０に送信する命令と、命令による処理結果の通知先を対応付ける。制御部６２は、正規ユーザから要求されている処理を通信装置２０に行わせるための命令を生成し、生成した命令に命令ＩＤを割り当てる。命令ＩＤは個々の命令を一意に識別する情報である。図７に示す管理情報テーブル６７は、通信装置２０への命令の各々について、命令ＩＤ、時刻、通信装置ＩＤ、アクセス先ＵＲＬ（Uniform Resource Locator）、ユーザＩＤ、端末ＩＤ、ファイル名、命令種別を対応付けている。時刻は命令ＩＤで識別される命令をアプリケーションサーバ５が取得した時刻である。通信装置ＩＤは、命令の要求先となる通信装置２０のＩＤであり、登録情報テーブル６６を用いて特定した通信装置２０に割り当てられている通信装置ＩＤである。アクセス先ＵＲＬは、通信装置２０に要求する命令によって通信装置２０に通信させるときのアクセス先である。アクセス先ＵＲＬは、通信装置２０にアップロードを要求する場合のアップロード先のＵＲＬでもよく、また、通信装置２０にダウンロードさせるファイルやデータの格納先であっても良い。ユーザＩＤは、命令送信の契機となった処理要求を送信した端末１５のユーザを識別するＩＤであり、端末ＩＤは、命令送信の契機となった処理要求を送信した端末１５を識別する情報である。ファイル名は、通信装置２０に処理を要求するファイルの名前である。通信装置２０にアップロードを要求する場合、通信装置２０で得られた処理結果のファイルのファイル名に使用される。一方、通信装置２０にダウンロードが要求される場合、ダウンロードされるファイルの名称が、管理情報テーブル６７でファイル名として記録されている。命令種別は、その命令の種類である。

なお、図７は管理情報テーブル６７の一例であり、実装に応じて管理情報テーブル６７中の情報要素や情報は変更され得る。例えば、命令ＩＤが命令の種別を表す情報と、同じ種類の命令の通し番号を合わせた文字列として決定される場合のように、命令の種別も命令ＩＤから特定できる場合、管理情報テーブル６７には命令種別が含まれていなくても良い。

図８は、データがサーバにアップロードされる場合の処理の例を説明するシーケンス図である。以下、ユーザＩＤ＝ユーザ１のユーザが端末１５を用いて、監視対象の写真の撮像を要求した場合を例として説明する。なお、図８は処理の一例であり、例えば、ステップＳ１６、Ｓ１７の順序が変更されるなど、実装に応じて処理の手順は変更され得る。

ステップＳ１１において、ユーザは端末１５からアプリケーションサーバ５に撮影命令を送る。撮影命令には、要求する処理の種別が撮影であることを示す情報、端末１５の端末ＩＤ、ユーザＩＤが含まれている。ここでは、ユーザＩＤ＝ユーザ１、端末ＩＤ＝ｐｈｏｎ１を含む撮影命令が送信されたとする。アプリケーションサーバ５の通信部６１は撮影命令を受信する。制御部６２は、撮影命令に含まれているユーザＩＤと端末ＩＤの組み合わせが登録情報テーブル６６に登録されているかを判定するとともに、命令の送信先の通信装置２０を特定する（ステップＳ１２）。登録情報テーブル６６（図６）には、ユーザＩＤ＝ユーザ１と端末ＩＤ＝ｐｈｏｎ１の組み合わせが含まれているので、制御部６２は、正規ユーザから制御が要求されていると判定する。さらに、登録情報テーブル６６には、ユーザＩＤ＝ユーザ１と端末ＩＤ＝ｐｈｏｎ１の組み合わせには、通信装置ＩＤ＝ｓｔ１が対応付けられている。

そこで、制御部６２は、通信装置ＩＤ＝ｓｔ１が割り当てられた通信装置２０に送信する命令の命令ＩＤを生成するとともに、管理情報テーブル６７を更新する（ステップＳ１３）。以下の説明では、制御部６２は、命令ＩＤ＝１００１−００１という命令ＩＤを生成したとする。また、撮影によって得られた画像ファイルを２０１５１０２３ａというファイル名でＵＲＬ１というＵＲＬで指定される領域に格納することを決定したとする。すると、制御部６２は、管理情報テーブル６７に、図７の１列目のエントリを記録する。

次に、制御部６２は、通信装置ＩＤ＝ｓｔ１が割り当てられた通信装置２０に通知する制御メッセージを、ＭＱＴＴプロトコルを用いて生成する。制御メッセージには、処理命令、処理の実行の際に使用される情報、命令ＩＤなどの情報が含まれる。ここでは、制御部６２は、以下の情報を含む制御メッセージを生成したとする。
命令の要求先：ｓｔ１
命令ＩＤ ：１００１−００１
格納先ＵＲＬ：ＵＲＬ１
ファイル名 ：２０１５１０２３ａ
命令種別 ：撮影
通信部６１は、制御メッセージの通知先の通信装置２０に対してＭＱＴＴメッセージを送信するＭＱＴＴサーバ１０に、制御メッセージを送信する（ステップＳ１４）。

ＭＱＴＴサーバ１０は、撮影命令を受信すると、ＭＱＴＴプロトコルに従って、通信装置２０に制御メッセージを転送する（ステップＳ１５）。図８の例では、ＭＱＴＴサーバ１０と通信装置２０の間には、ＭＱＴＴを用いたセッションが常時確立されているとする。また、ＭＱＴＴサーバ１０は、通信装置２０との間でセッションを確立すると、セッションＩＤと通信装置２０に設定された通信装置ＩＤを対応付けて記憶する。このため、ＭＱＴＴサーバ１０は、制御メッセージ中の命令の要求先として指定された通信装置ＩＤに対応付けられたセッションＩＤで識別されるセッションに制御メッセージを転送する。

通信装置２０の受信部２２は、制御メッセージをＭＱＴＴサーバ１０から受信すると、制御メッセージを判定部３１に出力する。判定部３１は、入力された制御メッセージを解析することにより、撮影が要求されていると判定し、アプリケーション処理部３３に撮影処理を要求するとともに、制御メッセージ中の情報もアプリケーション処理部３３に出力する。アプリケーション処理部３３は、判定部３１の要求に応じて、カメラ５０を用いた撮影処理を行って、アプリケーションサーバ５にアップロードするためのデータを生成する（ステップＳ１６）。このとき、アプリケーション処理部３３は、アップロードの対象となるファイルのファイル名を、制御メッセージで通知されたファイル名にする。このため、アプリケーション処理部３３の処理により、２０１５１０２３ａというファイル名の画像ファイルが生成される。

判定部３１は、制御メッセージで要求された処理に伴って、ＨＴＴＰプロトコルによる通信が発生するかを判定する。なお、判定部３１は、予め、ＨＴＴＰプロトコルによる通信が発生する処理の種類を記憶していてもよく、制御メッセージ中にＵＲＬの情報が含まれている場合に、ＨＴＴＰプロトコルによる通信が発生すると判定してもよい。図８の例では、判定部３１は、撮影命令によって撮影された画像データのアップロードに使用するプロトコルをＨＴＴＰプロトコルに決定したとする（ステップＳ１７）。

判定部３１は、接続制御部３２に対して、ＨＴＴＰプロトコルを用いた通信を行うために、ＨＴＴＰセッションの生成を要求する。このとき、判定部３１は、データのアップロード先のＵＲＬなどの情報を接続制御部３２に通知する。接続制御部３２は、判定部３１からの要求に応じて、アプリケーションサーバ５との間でＨＴＴＰセッションを確立するための処理を行う（ステップＳ１８）。なお、ＨＴＴＰセッションの確立のための処理は、通常のＨＴＴＰプロトコルによる通信の開始の際の処理と同様である。

通信装置２０とアプリケーションサーバ５の間にＨＴＴＰセッションが確立されると、送信部２３は、ステップＳ１６で生成された画像データを、ＨＴＴＰセッションを介して、アプリケーションサーバ５にアップロードする（ステップＳ１９）。アプリケーションサーバ５は、通信装置２０から受信したデータを、アップロード先として通信装置２０に通知したＵＲＬ（ＵＲＬ１）で指定される領域に格納する。

送信部２３は、アップロードが終了すると、送信の終了を接続制御部３２とアプリケーション処理部３３に通知する。すると、接続制御部３２は、通信装置２０とアプリケーションサーバ５の間のＨＴＴＰセッションを終了する（ステップＳ２０）。

一方、アプリケーション処理部３３は、処理結果を通知するための応答メッセージを生成する。ここで、アプリケーション処理部３３は、ＭＱＴＴプロトコルを用いて、応答メッセージを生成する。また、図８の例では、応答メッセージにより、アップロードの成功が通知されるものとする。また、メッセージの最終宛先がアプリケーションサーバ５であることを特定するための情報も、応答メッセージに含まれているとする。送信部２３は、生成された応答メッセージを、ＭＱＴＴプロトコルでの通信に使用するセッションを介して、ＭＱＴＴサーバ１０に送信する（ステップＳ２１）。ＭＱＴＴサーバ１０は、応答メッセージを受信すると、ＭＱＴＴプロトコルに従って、アプリケーションサーバ５に応答メッセージを転送する（ステップＳ２２）。なお、ＭＱＴＴサーバ１０は、アプリケーションサーバ５との間でセッションを確立すると、アプリケーションサーバ５の識別情報とセッションＩＤを対応付けて記憶しているとする。このため、ＭＱＴＴサーバ１０は、応答メッセージ中の通知先として指定されたアプリケーションサーバ５の識別情報に対応付けられたセッションＩＤで識別されるセッションに応答メッセージを転送する。

アプリケーションサーバ５の制御部６２は、通信部６１を介して応答メッセージを取得すると、管理情報テーブル６７を参照することにより、処理結果の通知先を特定する。制御部６２は、処理結果を撮影命令の送信元の端末１５に通知するためのメッセージを生成する。ここでは、制御部６２は、管理情報テーブル６７の１列目のエントリを用いて、端末ＩＤ＝ｐｈｏｎ１で識別される端末１５に対して、データ取得に成功したことを通知するデータ取得通知を生成する。通信部６１は、データ取得通知を端末１５に送信する（ステップＳ２３）。なお、データ取得通知には、撮像結果がＵＲＬ１に格納されていることを通知する情報も含まれている。

端末１５にデータ取得通知が届くと、端末１５中で動作しているアプリケーションにより、撮像結果が得られたことをユーザに通知するための処理が行われる。この処理では、ＵＲＬ１に撮像結果のファイルがアップロードされていることを通知するメッセージが、端末１５の画面に表示されてもよく、また、ポップ音などでユーザにデータ取得の完了が通知されても良い。ユーザは、データ取得の完了が通知されると、適宜、撮像結果を取得するための処理を、アプリケーションを用いて行う。

図９は、制御メッセージを送信する際のアプリケーションサーバ５の処理の例を説明するフローチャートである。通信部６１は、ユーザの端末からの命令を受信する（ステップＳ３１）。制御部６２は、登録情報テーブル６６を参照して正規のユーザからの命令を受信したことを確認すると、命令ＩＤを生成する（ステップＳ３２）。さらに、制御部６２は、管理情報テーブル６７を更新する（ステップＳ３３）。制御部６２は、命令の送信先の通信装置２０に宛てて、命令ＩＤを含む制御メッセージを生成する。通信部６１は、制御部６２で生成された制御メッセージをＭＱＴＴサーバ１０に送信する（ステップＳ３４）。

図１０は、ＭＱＴＴサーバ１０での処理の例を説明するフローチャートである。ＭＱＴＴサーバ１０は、アプリケーションサーバ５から制御メッセージを受信する（ステップＳ４１）。ＭＱＴＴサーバ１０は、制御メッセージの最終宛先の通信装置２０がＭＱＴＴサーバ１０に接続しているかを判定する（ステップＳ４２）。制御メッセージの最終宛先の通信装置２０がＭＱＴＴサーバ１０に接続していない場合、ＭＱＴＴサーバ１０は、再度、宛先の通信装置２０がＭＱＴＴサーバ１０に接続したかの判定に戻る（ステップＳ４２でＮｏ）。制御メッセージの最終宛先の通信装置２０がＭＱＴＴサーバ１０に接続している場合、ＭＱＴＴサーバ１０は、制御メッセージを、最終宛先の通信装置２０に転送する（ステップＳ４２でＹｅｓ、ステップＳ４３）。

なお、ＭＱＴＴサーバ１０が通信装置２０から応答メッセージを受信した場合でも、ＭＱＴＴサーバ１０で行われる処理は、制御メッセージの受信の際と同様である。すなわち、応答メッセージの最終宛先であるアプリケーションサーバ５とＭＱＴＴサーバ１０が接続している場合、受信した応答メッセージをアプリケーションサーバ５に送信する。アプリケーションサーバ５とＭＱＴＴサーバ１０が接続していない場合、ＭＱＴＴサーバ１０は、アプリケーションサーバ５との接続が確立すると、応答メッセージを送信する。

図１１は、通信装置２０での処理の例を説明するフローチャートである。図１１では、定数Ｎと変数ｎを用いる。定数Ｎは、ＨＴＴＰセッションでの通信に失敗したときに行われるリトライの回数の上限値である。変数ｎは、通信装置２０が行ったリトライ回数である。

通信装置２０の受信部２２は、ＭＱＴＴサーバ１０から制御メッセージを受信するとともに、リトライ回数ｎを０に設定する（ステップＳ５１）。判定部３１は、制御メッセージで命令された処理により、ＨＴＴＰ通信が発生するかを判定する（ステップＳ５２）。制御メッセージで命令された処理により、ＨＴＴＰ通信が発生しない場合、アプリケーション処理部３３は、要求された命令を特定するとともに、要求された処理を行う（ステップＳ５２でＮｏ、ステップＳ５３、Ｓ５４）。ステップＳ５４において、ＨＴＴＰ通信を伴わない処理を行う場合、アプリケーション処理部３３は、処理結果を通知するための応答メッセージを、ＭＱＴＴプロトコルを用いて生成する。応答メッセージには、ＭＱＴＴプロトコルで送信されるデータが含まれていてもよい。例えば、通信装置２０の動作状況やファームウェアのバージョン情報の送信が要求された場合、アプリケーション処理部３３は、これらの情報を含む応答メッセージを、ＭＱＴＴプロトコルを用いて生成できる。送信部２３は、生成された応答メッセージを、ＭＱＴＴプロトコルでの通信用のセッションを介して送信する（ステップＳ６８）。このため、応答メッセージは、ＭＱＴＴサーバ１０を介してアプリケーションサーバ５に送信されることになる。

一方、制御メッセージで命令された処理により、ＨＴＴＰ通信が発生する場合、判定部３１は、処理によって発生するＨＴＴＰ通信はアップロード（ＵＬ）とダウンロード（ＤＬ）のいずれであるかを判定する（ステップＳ５２でＹＥＳ、ステップＳ５５）。処理によって発生するＨＴＴＰ通信はアップロードである場合、アプリケーション処理部３３は、命令の種類を特定するとともに、格納先の情報を取得する（ステップＳ５５でＵＬ、ステップＳ５６）。ここで、格納先の情報の取得は、制御メッセージ中の情報から格納先の情報を抽出することによって行われる。さらに、ファイル名がアプリケーションサーバ５で決定されるシステムの場合、制御メッセージによってファイル名が通知されるので、アプリケーション処理部３３は、制御メッセージからファイル名を抽出する。アプリケーション処理部３３は、命令された処理を実行する（ステップＳ５７）。さらに、アプリケーション処理部３３は、命令された処理の実行によって得られたアップロードデータのファイル名を設定する（ステップＳ５８）。例えば、制御メッセージからファイル名を取得している場合、アプリケーション処理部３３は、取得済みのファイル名を使用する。接続制御部３２は、ＨＴＴＰセッションを生成する（ステップＳ５９）。送信部２３は、生成されたＨＴＴＰセッションを介して、データのアップロードを行う（ステップＳ６０）。接続制御部３２は、アップロードが正常終了したかを判定する（ステップＳ６１）。アップロードが正常終了した場合、接続制御部３２は、ＨＴＴＰセッションを終了する（ステップＳ６１でＹｅｓ、ステップＳ６２）。その後、アプリケーション処理部３３は、処理結果を通知するための応答メッセージを、ＭＱＴＴプロトコルを用いて生成する。送信部２３は、生成された応答メッセージを、ＭＱＴＴプロトコルでの通信用のセッションを介して送信する（ステップＳ６８）。

ステップＳ６１において、アップロードが正常終了していないと判定した場合、接続制御部３２は、リトライ回数ｎが定数Ｎを超えたかを判定する（ステップＳ６１でＮｏ、ステップＳ６３）。リトライ回数ｎが定数Ｎを超えていない場合、接続制御部３２はＨＴＴＰセッションを終了する（ステップＳ６３でＮｏ、ステップＳ６４）。接続制御部３２は、一定時間待機し、リトライ回数ｎを１つインクリメントしてからステップＳ５９に戻って、ＨＴＴＰセッションを再度確立する（ステップＳ６５、Ｓ６６）。

一方、リトライ回数ｎが定数Ｎを超えている場合、接続制御部３２はＨＴＴＰセッションを終了する（ステップＳ６３でＹｅｓ、ステップＳ６７）。すると、アプリケーション処理部３３は、処理結果を通知するための応答メッセージを、ＭＱＴＴプロトコルを用いて生成する。このときの応答メッセージには、アップロードの失敗を通知する情報が含められる。送信部２３は、生成された応答メッセージを、ＭＱＴＴプロトコルでの通信用のセッションを介して送信する（ステップＳ６８）。

ステップＳ５５において、ＨＴＴＰ通信はダウンロードであると判定された場合、ダウンロード処理が行われる（ステップＳ６９）。ダウンロード処理については、図１３、図１４を参照しながら詳しく説明する。

図１２は、応答メッセージを受信した際のサーバの処理の例を説明するフローチャートである。図１２は、アプリケーションサーバ５から端末１５へはｐｕｓｈ用サーバを介してアクセスするシステムの場合の処理の例であるが、システム中にｐｕｓｈ用サーバが含まれていなくてもよい。システム中にｐｕｓｈ用サーバが含まれない場合、図８などを参照しながら説明したように、アプリケーションサーバ５は、端末１５に直接、通知情報を通知する。

アプリケーションサーバ５の通信部６１は、ＭＱＴＴサーバ１０から応答メッセージを受信する（ステップＳ８１）。制御部６２は、応答メッセージ中の命令ＩＤと処理の結果を取得する（ステップＳ８２）。制御部６２は、管理情報テーブル６７を参照することにより、応答メッセージにより通知された処理結果をアプリケーションサーバ５に要求したユーザのユーザＩＤと、端末ＩＤを取得する（ステップＳ８３）。制御部６２は、処理結果を通知する通知情報を生成する。通信部６１は、ｐｕｓｈ用サーバに端末宛ての通知情報を端末ＩＤに対応付けて出力する（ステップＳ８４）。

（２）通信装置２０がデータをダウンロードする場合の処理の例
以下、アプリケーションサーバ５から通信装置２０に対して、アプリケーションサーバ５が格納しているデータのダウンロードを要求する場合を例として、データがダウンロードされる場合の処理の例を説明する。以下、ユーザからの指示によらず、アプリケーションサーバ５が通信装置２０にデータのダウンロードを要求する場合を例として説明するが、ユーザからの要求によりダウンロードが行われてもよい。なお、通信装置２０へのデータのダウンロードの要求は、通信装置２０で使用されるファームウェアのアップデートが発生した場合などに行われる。

図１３は、データがサーバからダウンロードされる場合の処理の例を説明するシーケンス図である。アプリケーションサーバ５の制御部６２は、ダウンロード命令の送信先となる通信装置２０を特定する（ステップＳ９１）。例えば、制御部６２は通信装置ＩＤ＝ｓｔ２が割り当てられた通信装置２０にダウンロードを要求することを決めたとする。すると、制御部６２は、送信する命令の命令ＩＤを生成するとともに、管理情報テーブル６７を更新する（ステップＳ９２）。制御部６２は、命令ＩＤ＝１００２−００２という命令ＩＤを生成したとする。また、ダウンロードの対象となるファイルは２０１５１０２３ｂというファイル名でＵＲＬ２というＵＲＬで指定される領域に格納されているとする。制御部６２は、命令ＩＤやダウンロードを要求するファイル名などの情報を管理情報テーブル６７に格納する。

次に、制御部６２は、通信装置ＩＤ＝ｓｔ２が割り当てられた通信装置２０に通知する制御メッセージを、ＭＱＴＴプロトコルを用いて生成する。例えば、制御部６２は、以下の情報を含む制御メッセージを生成したとする。
命令の要求先：ｓｔ２
命令ＩＤ ：１００２−００２
格納先ＵＲＬ：ＵＲＬ２
ファイル名 ：２０１５１０２３ｂ
命令種別 ：更新要求（ダウンロード命令）

通信部６１は、ＭＱＴＴサーバ１０に、通信装置２０宛ての制御メッセージを送信する（ステップＳ９３）。ＭＱＴＴサーバ１０は、制御メッセージを受信すると、通信装置２０に制御メッセージを転送する（ステップＳ９４）。

通信装置２０の受信部２２は、制御メッセージをＭＱＴＴサーバ１０から受信すると、制御メッセージを判定部３１に出力する。判定部３１は、入力された制御メッセージを解析することにより、ファームウェアの更新が要求されていると判定し、ダウンロードに使用するプロトコルをＨＴＴＰに決定する（ステップＳ９５）。

判定部３１は、判定結果を接続制御部３２とアプリケーション処理部３３に通知するとともに、制御メッセージ中の情報を通知する。接続制御部３２は、データのダウンロード先のＵＲＬなどの情報を用いて、アプリケーションサーバ５との間でＨＴＴＰセッションを確立するための処理を行う（ステップＳ９６）。なお、ＨＴＴＰセッションの確立のための処理は、通常のＨＴＴＰプロトコルによる通信の開始の際の処理と同様である。

通信装置２０とアプリケーションサーバ５の間にＨＴＴＰセッションが確立されると、アプリケーション処理部３３は、制御メッセージで指定されたファイル名のファイルを、ＨＴＴＰセッションを介して、ダウンロードするための処理を行う（ステップＳ９７）。アプリケーション処理部３３は、ダウンロードが終了すると、ダウンロードの終了を接続制御部３２に通知する。すると、接続制御部３２は、通信装置２０とアプリケーションサーバ５の間のＨＴＴＰセッションを終了する（ステップＳ９８）。

一方、アプリケーション処理部３３は、処理結果を通知するための応答メッセージを生成する。ここで、アプリケーション処理部３３は、ＭＱＴＴプロトコルを用いて、アプリケーションサーバ５宛ての応答メッセージを生成する。図１３の例では、応答メッセージにより、ダウンロードの成功が通知されるものとする。送信部２３は、生成された応答メッセージを、ＭＱＴＴプロトコルでの通信に使用するセッションを介して、ＭＱＴＴサーバ１０に送信する（ステップＳ９９）。ＭＱＴＴサーバ１０は、応答メッセージを受信すると、ＭＱＴＴプロトコルに従って、アプリケーションサーバ５に応答メッセージを転送する（ステップＳ１００）。

図１４は、通信装置でのダウンロード処理の例を説明するフローチャートである。図１４は、図１１のステップＳ６９で行われる処理を詳しく記載したフローチャートである。図１４においても、変数ｎはＨＴＴＰ通信のリトライ回数であり、定数Ｎはリトライ回数の上限値である。

まず、通信装置２０の判定部３１において、ＨＴＴＰプロトコルを用いたデータのダウンロードを要求する制御メッセージを受信したと判定されたとする（ステップＳ１１１）。接続制御部３２は、ＨＴＴＰセッションを生成する（ステップＳ１１２）。アプリケーション処理部３３は、受信部２２を用い、生成されたＨＴＴＰセッションを介して、制御メッセージで指定されたデータのダウンロードを行う（ステップＳ１１３）。アプリケーション処理部３３は、ダウンロードが正常終了したかを判定する（ステップＳ１１４）。ダウンロードが正常終了した場合、接続制御部３２は、ＨＴＴＰセッションを終了する（ステップＳ１１４でＹｅｓ、ステップＳ１１５）。その後、アプリケーション処理部３３は、処理結果を通知するための応答メッセージを、ＭＱＴＴプロトコルを用いて生成する。送信部２３は、生成された応答メッセージを、ＭＱＴＴプロトコルでの通信用のセッションを介して送信する（ステップＳ１２１）。

ステップＳ１１４において、ダウンロードが正常終了していないと判定された場合に行われるステップＳ１１６〜Ｓ１２０の処理は、図１１のステップＳ６３〜Ｓ６７の処理と同様である。ステップＳ１２０の処理後、ＭＱＴＴプロトコルを用いて、処理結果を通知するための応答メッセージがアプリケーションサーバ５に送信される（ステップＳ１２１）。

以上で説明したように、アプリケーションサーバ５の要求に応じた処理により通信装置２０がデータを送受信する場合、処理の要求や処理結果などの制御情報は第１のプロトコル（ＭＱＴＴ）で送受信される。一方、データは、データ通信に適した第２のプロトコル（ＨＴＴＰ）で送受信されるが、第２のプロトコルを用いた通信用のセッションは常時接続されておらず、データの送受信に使用される間だけ形成される。このため、無駄な通信路の確保が防止され、システムが効率化される。なお、アプリケーションサーバ５と通信装置２０の間で第１のプロトコルを用いた通信セッションの常時接続が行われていたとしても、第１のプロトコルは、ヘッダ長が短い上、制御情報などの少量のデータの送受信に使用される。このため、第１のプロトコルを用いた通信セッションの維持のために通信経路が維持されても、第２のプロトコルを用いたセッションが常時接続されている場合に比べて、通信システムが効率化される。

また、第１のプロトコルでは、ヘッダ長が短く、データ長の短いパケットが送受信されることから、第１のプロトコルでの通信セッションの維持がアプリケーションサーバ５等に及ぼす負荷は、第２のプロトコルの通信セッションの維持による負荷よりも小さい。このため、実施形態にかかるシステムでは、１つのアプリケーションサーバ５に多数の通信装置２０が接続される場合であっても、アプリケーションサーバ５にかかる負荷が小さいといえる。さらに、通信装置２０側からの処理結果の通知が第１のプロトコルで行われるので、アプリケーションサーバ５は、データのアップロードやダウンロードに対する処理の進行状況や完了時期のタイミングを特定するための処理を行わなくても良い。従って、実施形態にかかるシステムでは、アプリケーションサーバ５に対する負荷が軽減される。

さらに、第１のプロトコルがパブリッシュ／サブスクライブ型のプロトコルである場合、アプリケーションサーバ５と通信装置２０の間の通信の確立に失敗しても、通信装置２０宛のメッセージがＭＱＴＴサーバ１０で確保され、通信エラーが発生しない。このため、一時的に通信装置２０がネットワークに接続していないなどの理由から通信エラーが頻発することも防ぐことができる。

一方、第１のプロトコルを用いて、アプリケーションサーバ５と通信装置２０の間にＭＱＴＴサーバ１０を介した通信路が形成されている場合には、通信装置２０宛の制御メッセージは通信装置２０に到達するので、リアルタイムでの撮像処理などが可能である。換言すると、実施形態にかかるシステムでは、データの送受信に使用する第２のプロトコルでのセッションを生成する時間を限定してシステムを効率化しつつ、リアルタイムにデータを取得することができる。

＜その他＞
なお、実施形態は上記に限られるものではなく、様々に変形可能である。以下にその例をいくつか述べる。

アプリケーションサーバ５中に格納されたファイルなどのダウンロードの要求が、端末１５からの要求に起因して行われる場合も、制御メッセージの送信時のアプリケーションサーバ５の処理は図９を参照しながら説明した処理と同様である。また、アプリケーションサーバ５に応答メッセージが通知された場合にアプリケーションサーバ５が行う処理も図１２を参照しながら説明した処理と同様である。

例えば、以上の例では、ＭＱＴＴサーバ１０が転送先を特定する際に、制御メッセージ中の通信装置ＩＤやアプリケーションサーバ５を示す情報を用いると説明したが、ＭＱＴＴサーバ１０からの転送には他の方法が用いられても良い。すなわち、制御メッセージの最終宛先をＭＱＴＴサーバ１０で特定できる任意の情報が制御メッセージに含められても良く、ＭＱＴＴサーバ１０は適宜、制御メッセージ中の情報を用いて転送先を決定する。

以上の説明で図示したテーブルは一例であり、実装に応じて変更され得る。例えば、各テーブルに含まれている情報要素は、実装に応じて変更され得る。

さらに、以上の説明では、画像データが通信装置２０からアプリケーションサーバ５にアップロードされる場合を例として説明したが、アップロードされるデータは、画像データに限られず、動画、音声などを含む任意のデータである。また同様に、通信装置２０にダウンロードされるデータも、ファームウェアの更新情報に限られず、任意のデータがダウンロードの対象となり得る。

３ インターネット
５ アプリケーションサーバ
７ ３Ｇ−ＬＴＥ網
１０ ＭＱＴＴサーバ
１５ 端末
２０ 通信装置
２１、６１ 通信部
２２ 受信部
２３ 送信部
３０、６２ 制御部
３１ 判定部
３２ 接続制御部
３３ アプリケーション処理部
４０、６５ 記憶部
５０ カメラ
６６ 登録情報テーブル
６７ 管理情報テーブル
１０１ プロセッサ
１０２ メモリ
１０３ 入力装置
１０４ 出力装置
１０５ バス
１０６ 記憶装置
１０７ 撮像装置
１０９ ネットワークインタフェース

Claims (9)

1. 第１のプロトコルを用いた第１のセッションの接続先から制御メッセージを受信する受信部と、
   前記制御メッセージで指定された処理を行うと共に、前記処理に伴う通信処理を前記第１のプロトコルよりもヘッダ長の長い第２のプロトコルを用いて行う場合、前記第２のプロトコルを用いた通信の通信先との間で第２のセッションを確立する制御部と、
   前記第１および第２のセッションを用いて通信する通信部
   を備え、
   前記制御部は、前記第２のプロトコルを用いた通信が終了すると、前記第２のセッションを終了し、
   前記通信部は、前記第１のセッションを介して、前記制御メッセージで指定された処理の結果を、前記通信先に通知する
   ことを特徴とする通信装置。
2. 前記制御部は、前記制御メッセージにより前記通信先へのデータのアップロードが要求されている場合、
   前記データのアップロードに前記第２のプロトコルを使用することを決定し、
   前記制御メッセージから前記データのアップロード先の情報を取得し、
   前記通信部は、
   前記第２のセッションを介して、前記アップロード先に前記データを送信し、
   前記第１のセッションを介して、前記データのアップロードが成功したかを前記通信先に通知する情報を、前記接続先に送信する
   ことを特徴とする請求項１に記載の通信装置。
3. 監視対象を撮像する撮像装置をさらに備え、
   前記制御部は、前記制御メッセージにより前記監視対象を撮像した撮像データのアップロードが要求されると、前記撮像データを前記撮像装置から取得すると共に、前記撮像データを前記通信先に送信する際に前記第２のプロトコルを使用することを決定し、
   前記通信部は、
   前記第２のセッションを介して、前記アップロード先に前記撮像データを送信し、
   前記撮像データのアップロードが成功したかを前記通信先に通知する情報を、前記接続先に送信する
   ことを特徴とする請求項２に記載の通信装置。
4. 前記制御部は、前記制御メッセージにより前記通信先からのデータのダウンロードが要求されている場合、前記ダウンロードに前記第２のプロトコルを使用することを決定し、
   前記通信部は、
   前記通信先から、前記第２のセッションを介して、前記ダウンロードの対象のデータを受信し、
   前記第１のセッションを介して、前記ダウンロードが成功したかを前記通信先に通知する情報を、前記接続先に送信する
   ことを特徴とする請求項１〜３のいずれか１項に記載の通信装置。
5. 第１のプロトコルを用いた第１のセッションの接続先から制御メッセージを受信する通信装置と、
   前記通信装置に前記制御メッセージを送信するサーバ装置
   を備え、
   前記通信装置は、
   前記制御メッセージで指定された処理を行うと共に、前記処理に伴って前記サーバ装置との間で前記第１のプロトコルよりもヘッダ長の長い第２のプロトコルを用いた通信を行う場合、前記サーバ装置との間で第２のセッションを確立し、
   前記第２のプロトコルを用いた通信が終了すると、前記第２のセッションを終了し、
   前記第１のセッションを介して、前記制御メッセージで指定された処理の結果を、前記サーバ装置に通知する
   ことを特徴とする通信システム。
6. 前記サーバ装置にアクセスする端末をさらに備え、
   前記サーバ装置は、
   前記通信装置からのデータの取得を前記端末から要求されると、前記データの前記サーバ装置へのアップロードを要求する制御メッセージを生成し、
   前記制御メッセージを前記第１のプロトコルを用いて前記通信装置に向けて送信し、
   前記通信装置は、
   前記データのアップロードに前記第２のプロトコルを使用することを決定すると共に、前記第２のセッションを介して、前記サーバ装置に前記データを送信し、
   前記第１のセッションを介して、前記データのアップロードが成功したかを前記サーバ装置に通知する通知情報を、前記接続先に送信し、
   前記サーバ装置は、前記接続先を介して前記通知情報を取得すると、前記端末に前記データの取得結果を通知する
   ことを特徴とする請求項５に記載の通信システム。
7. 前記サーバ装置は、前記通信装置に前記サーバ装置からのデータのダウンロードを要求する他の制御メッセージを生成すると共に、前記他の制御メッセージを前記第１のプロトコルを用いて前記通信装置に向けて送信し、
   前記通信装置は、
   前記第２のセッションを介して、前記ダウンロードの対象のデータを受信し、
   前記第１のセッションを介して、前記ダウンロードが成功したかを前記サーバ装置に通知する情報を、前記接続先に送信し、
   前記サーバ装置は、前記接続先を介して前記ダウンロードが成功したかを通知する情報を取得する
   ことを特徴とする請求項５または６に記載の通信システム。
8. 第１のプロトコルを用いた第１のセッションの接続先から制御メッセージを受信し、
   前記制御メッセージで指定された処理を行い、
   前記処理に伴う通信処理を前記第１のプロトコルよりもヘッダ長の長い第２のプロトコルを用いて行う場合、前記第２のプロトコルを用いた通信の通信先との間で第２のセッションを確立し、
   前記第２のセッションを介して前記第２のプロトコルを用いた通信を行い、
   前記第２のプロトコルを用いた通信が終了すると、前記第２のセッションを終了し、
   前記第１のセッションを介して、前記制御メッセージで指定された処理の結果を、前記通信先に通知する
   処理を通信装置が行うことを特徴とする通信方法。
9. 第１のプロトコルを用いた第１のセッションの接続先から制御メッセージを受信し、
   前記制御メッセージで指定された処理を行い、
   前記処理に伴う通信処理を前記第１のプロトコルよりもヘッダ長の長い第２のプロトコルを用いて行う場合、前記第２のプロトコルを用いた通信の通信先との間で第２のセッションを確立し、
   前記第２のセッションを介して前記第２のプロトコルを用いた通信を行い、
   前記第２のプロトコルを用いた通信が終了すると、前記第２のセッションを終了し、
   前記第１のセッションを介して、前記制御メッセージで指定された処理の結果を、前記通信先に通知する
   処理を通信装置に行わせることを特徴とする通信プログラム。
   

Images