JP7032970B2 - 通信システム、通信モジュール、サーバ、制御方法、及び制御プログラム - Google Patents

Description

本開示は、通信システム、通信モジュール、サーバ、制御方法、及び制御プログラムに関する。

従来、測定装置によって測定したデータを、サーバに収集する通信システムが知られている。例えば、特許文献１は、測定装置が測定したデータを、端末によってサーバに送信するシステムを開示している。

特開２０１４－２０９３１１号公報

従来の通信システムにおいては、例えばモノのインターネット（Internet of Things（ＩｏＴ））技術の普及などに伴い、利便性のさらなる向上が求められている。

本開示の目的は、利便性の高い通信システム、通信モジュール、サーバ、制御方法、及び制御プログラムを提供することにある。

一実施形態に係る通信システムは、通信モジュールと、サーバと、を含む。
前記通信システムは、前記通信モジュールから前記サーバに送信する要求のリソースが規定されていない規格に準拠する。
前記通信モジュールは、当該通信モジュールにおけるソフトウェアを更新する際、前記サーバによって監視を要求されたリソースにおける変化を示す通知を当該サーバに送信する。
前記サーバは、前記通知の受信に基づいて、前記ソフトウェアの更新に関連する処理を実行する。

一実施形態に係る通信モジュールは、サーバに送信する要求のリソースが規定されていない規格に準拠している。
前記通信モジュールは、前記通信モジュールにおけるソフトウェアを更新する際、前記サーバによって監視を要求されたリソースにおける変化を示す通知を、当該サーバに送信する。

一実施形態に係るサーバは、通信モジュールから送信される要求のリソースが規定されていない規格に準拠している。
前記サーバは、前記通信モジュールにおいてソフトウェアが更新される際に、前記サーバによって監視を要求されたリソースにおける変化を示す通知を前記通信モジュールから受信すると、当該通知の受信に基づいて、前記ソフトウェアの更新に関連する処理を実行する。

一実施形態に係る制御方法は、サーバに送信する要求のリソースが規定されていない規格に準拠した通信モジュールの制御方法である。
前記通信モジュールの制御方法は、前記通信モジュールにおけるソフトウェアを更新する際、前記サーバによって監視を要求されたリソースにおける変化を示す通知を、当該サーバに送信するステップを含む。

一実施形態に係る制御方法は、通信モジュールから送信される要求のリソースが規定されていない規格に準拠したサーバの制御方法である。
前記サーバの制御方法は、
前記通信モジュールにおいてソフトウェアが更新される際に、前記サーバによって監視を要求されたリソースにおける変化を示す通知を前記通信モジュールから受信するステップと、
前記通知の受信に基づいて、前記ソフトウェアの更新に関連する処理を実行するステップと、
を含む。

一実施形態に係る通信モジュールの制御プログラムは、
サーバに送信する要求のリソースが規定されていない規格に準拠した通信モジュールを制御するコンピュータに、
前記通信モジュールにおけるソフトウェアを更新する際、前記サーバによって監視を要求されたリソースにおける変化を示す通知を、当該サーバに送信するステップを実行させる。

一実施形態に係るサーバの制御プログラムは、通信モジュールから送信される要求のリソースが規定されていない規格に準拠したサーバを制御するコンピュータに、以下のステップを実行させる。
（１）前記通信モジュールにおいてソフトウェアが更新される際に、前記サーバによって監視を要求されたリソースにおける変化を示す通知を前記通信モジュールから受信するステップ
（２）前記通知の受信に基づいて、前記ソフトウェアの更新に関連する処理を実行するステップ

本開示の一実施形態によれば、利便性の高い通信システム、通信モジュール、サーバ、制御方法、及び制御プログラムを提供することができる。

一実施形態に係る通信システムを概略的に示す機能ブロック図である。 ＬｗＭ２Ｍの規格に準拠したシステムにおけるＦＯＴＡの例を説明する図である。 既存システムにおけるＦＯＴＡの例を説明する図である。 一実施形態に係る通信システムにおけるＦＯＴＡの例を説明する図である。

近年、ＩｏＴに対する関心の高まりに伴い、機器間の通信（Machine to Machine（Ｍ２Ｍ））に関する技術の開発が進められている。また、ＩｏＴ／Ｍ２Ｍにおいて活用が期待されている技術として、省電力で広域エリアを対象とした、ＬＰＷＡ（Low Power Wide Area）と呼ばれる無線通信方式がある。そして、例えばＬＰＷＡにおけるような通信に好適な規格として、Open Mobile Alliance（ＯＭＡ）によるOMA Lightweight M2M（ＬｗＭ２Ｍ）が提案されている。
（参考ＵＲＬ http://openmobilealliance.org/iot/lightweight-m2m-lwm2m）

ＬｗＭ２Ｍは、ＩｏＴ／Ｍ２Ｍにおけるデバイス管理等のためにＯＭＡにより標準化されている規格である。ＬｗＭ２Ｍが想定している対象機器は、リソースに制限のあるものが多い。このため、ＬｗＭ２Ｍは、軽量かつコンパクトなリソースデータモデルを採用している。また、ＬｗＭ２Ｍは、様々なアプリケーションの要件に適合できるように、拡張性も備えている。ＬｗＭ２Ｍは、管理対象リソースを「オブジェクト（Objects）」という単位でまとめて管理し、フラットなデータ構造を採用している。ＬｗＭ２Ｍの仕様については、“Lightweight Machine to Machine Technical Specification, Approved Version 1.0 - 08 Feb 2017”（以下、「仕様書」と略記する）等に詳細に記述されている。

一方、例えばスマートフォンなどの通信デバイスのファームウェアを、無線で配信する技術（Firmware On-The-Air（ＦＯＴＡ））も知られている。ＦＯＴＡによれば、例えばパーソナルコンピュータ（ＰＣ）などがなくても、スマートフォンなどの通信デバイス単体でファームウェアが更新可能になる。現在、ＦＯＴＡを実現する無線網として、３Ｇ、ＬＴＥ、及びＷｉＦｉなどを挙げることができる。

例えば、ＦＯＴＡなどの、ソフトウェアを無線で配信及び／又は更新する技術を、ＬｗＭ２Ｍのような規格に準拠した通信システムにおいても実現することができれば、例えばＩｏＴデバイスのユーザにとって、また例えばＩｏＴデバイスの供給業者にとっても、著しく利便性を高めることができる。

以下、ＬｗＭ２Ｍのような規格に準拠した通信システムにおいて、ＦＯＴＡを実現する通信システムについて説明する。

図１は、一実施形態に係る通信システム１を概略的に示す機能ブロック図である。

図１に示すように、一実施形態に係る通信システム１は、少なくとも１つの通信モジュール１０と、サーバ２０と、を含んで構成される。一実施形態に係る通信システム１は、例えばＬｗＭ２Ｍのような規格に準拠した通信システムとしてよい。通信システム１は、上記仕様書及びその改訂版等に記述されるＬｗＭ２Ｍの仕様に準拠し得る。図１に示す通信システム１は、通信モジュール１０Ａ、通信モジュール１０Ｂ、及び通信モジュール１０Ｃの３つの通信モジュールを含んで構成されている。しかしながら、一実施形態に係る通信システム１は、例えば通信モジュール１０Ａのように、少なくとも１つの通信モジュールを含んで構成されてよい。通信モジュール１０Ａ、通信モジュール１０Ｂ、及び通信モジュール１０Ｃは、それぞれ同様の構成としてもよいし、異なる構成としてもよい。以下、通信モジュール１０Ａ、通信モジュール１０Ｂ、及び通信モジュール１０Ｃをそれぞれ区別しない場合、単に「通信モジュール１０」と総称する。

一実施形態に係る通信モジュール１０は、無線通信をはじめとする各種の機能を実現することができる。通信モジュール１０は、ＬＰＷＡ（Low Power Wide Area）技術に基づく通信を実現してよい。通信モジュール１０は、ＬＴＥ（Long Term Evolution）等の種々の通信方式による通信を実現してよい。以下、通信モジュール１０は、ＩＴＵ－Ｔ(International Telecommunication Union Telecommunication Standardization Sector)において通信方式が標準化されたモデムを含むものとして説明する。通信モジュール１０は、例えばＩｏＴモジュールとしてよい。通信モジュール１０は、アンテナを介して、外部機器と無線通信してよい。

一実施形態に係る通信モジュール１０は、例えばＩｏＴユニットに内蔵されてもよい。ここで、通信モジュール１０を含むＩｏＴユニットは、例えば各種の情報を検出する少なくとも１つのセンサを備えてもよい。この場合、ＩｏＴユニットは、当該センサが検出した情報を、通信モジュール１０によって、例えばサーバ２０のような外部機器に送信することができる。

図１に示すように、通信モジュール１０は、通信部１１と、制御部１２と、記憶部１３とを備える。

通信部１１は、一般的な無線通信において、信号の送受信の機能を実現する各種の部品とすることができる。例えば、通信部１１は、例えばサーバ２０などの外部機器と信号の送受信を行うアンテナを含んでよい。また、通信部１１は、一般的なＲＦ(radio frequency)部などを少なくとも含む部品で構成することができる。通信部１１は、典型的には、ベースバンド部において処理された信号を変調してから、アンテナを経て送信することができる。また、通信部１１は、例えばアンテナを経て受信した信号を復調してベースバンド部に受け渡すことができる。通信部１１は、例えば、ＲＦＩＣ（Radio Frequency Integrated Circuit）、パワーアンプ、フィルタ、スイッチ素子等の少なくとも一部を含んでよい。

制御部１２は、種々の機能を実行するための制御及び処理能力を提供するために、例えばＣＰＵ(Central Processing Unit)のような、少なくとも１つのプロセッサを含む。プロセッサは、単一の集積回路として実現されてよい。集積回路は、ＩＣ（Integrated Circuit）ともいう。プロセッサは、複数の通信可能に接続された集積回路及びディスクリート回路として実現されてよい。プロセッサは、他の種々の既知の技術に基づいて実現されてよい。一実施形態において、制御部１２は、ＬｗＭ２Ｍの規格に準拠したクライアント端末における動作を行ってよい。

記憶部１３は、半導体メモリ又は磁気メモリ等で構成されてよい。記憶部１３は、各種情報及び制御部１２で実行されるプログラム等を記憶する。記憶部１３は、制御部１２のワークメモリとして機能してよい。また、記憶部１３は、制御部１２に含まれてもよい。一実施形態において、記憶部１３は、ＬｗＭ２Ｍの規格に準拠したクライアント端末における動作に必要な各種情報を記憶してよい。

上述ように、通信モジュール１０がＩｏＴユニットに内蔵される場合、制御部１２には、少なくとも１つのセンサが接続されてよい。この場合、制御部１２に接続されるセンサは、外部環境の情報を取得するために、例えば、気圧センサ、温度センサ、湿度センサ、及び照度センサなどの少なくとも１つを含んでよい。このようなセンサは、センサ自身の位置、動き、及び姿勢の少なくとも１つに関する情報を取得するために、例えば、加速度センサ、角速度センサ、及び地磁気センサの少なくとも１つを含んでよい。角速度センサは、センサが設けられている機器等の角速度を検出し得る。加速度センサは、センサが設けられている機器等に生じている加速度を検出し得る。地磁気センサは、地磁気の向きを検出し得る。センサは、位置センサを含んでよい。位置センサは、ＲＦＩＤ（Radio Frequency Identifier）、ＩＥＥＥ８０２．１１、Ｂｌｕｅｔｏｏｔｈ（登録商標）等の近距離無線通信の電波等の検出結果に基づいて、センサが設けられている機器等の位置情報を検出してよい。このように、センサは、通信モジュール１０を含むＩｏＴユニットの状況に関する情報を検出してよい。また、センサは、ＩｏＴ機器に使用されるセンサを少なくとも１つ含んでよい。

一実施形態において、上述のセンサに含まれるのは、加速度センサ、角速度センサ、及び地磁気センサに限定されない。一実施形態において、センサは、例えば、通信モジュール１０を含むＩｏＴユニットの周囲の温度を検出する温度センサとしてもよい。また、センサは、例えば、通信モジュール１０を含むＩｏＴユニットの周囲の湿度を検出する湿度センサとしてもよい。また、センサは、例えば、通信モジュール１０を含むＩｏＴユニットの所定部位における光の照度を検出する照度センサとしてもよい。一実施形態において、センサは、前述したセンサ以外の他のセンサを含んでもよい。また、センサは、通信モジュール１０を含むＩｏＴユニットに内蔵されるものに限定されず、通信モジュール１０を含むＩｏＴユニットに接続される外部機器に備えられてもよい。この場合、外部機器に備えられるセンサは、外部端子を介して、通信モジュール１０の制御部１２に接続されてよい。

また、通信モジュール１０は、ＧＮＳＳ（Global Navigation Satellite System）技術等に基づいて、通信モジュール１０の位置情報を取得してよい。つまり、通信モジュール１０は、通信モジュール１０を含むＩｏＴユニットの位置情報を取得可能であってよい。ＧＮＳＳ技術は、例えばＧＰＳ（Global Positioning System）、ＧＬＯＮＡＳＳ、Ｇａｌｉｌｅｏ、及び準天頂衛星（ＱＺＳＳ）等のいずれか衛星測位システムを含んでよい。通信モジュール１０の位置情報は、緯度、経度、及び高度の少なくともいずれかの情報を含んでよい。通信モジュール１０は、通信モジュール１０以外の他の構成部によって、通信モジュール１０を含むＩｏＴユニットの位置に関する情報を取得してよい。例えば、通信モジュール１０を含むＩｏＴユニットは、ＧＰＳモジュールなどの位置情報所得デバイスを、センサとして内蔵してよい。また、通信モジュール１０は、通信モジュール１０を含むＩｏＴユニットの位置に関する情報を取得する装置に搭載可能であってもよい。例えば、ＧＰＳモジュールなどの位置情報所得デバイスが、外部機器として、制御部１２に接続されてもよい。この場合、外部機器としての位置情報所得デバイスは、外部端子を介して、制御部１２に接続されてよい。

このように、制御部１２は、センサの検出結果、又は、通信モジュール１０の位置情報等を、通信モジュール１０を介して例えばサーバ２０のような外部機器に送信してよい。

一実施形態に係るサーバ２０は、無線通信をはじめとする各種の機能を実現することができる。サーバ２０は、ＬＰＷＡ（Low Power Wide Area）技術に基づく通信を実現してよい。サーバ２０は、ＬＴＥ（Long Term Evolution）等の種々の通信方式による通信を実現してよい。以下、サーバ２０は、ＩＴＵ－Ｔ(International Telecommunication Union Telecommunication Standardization Sector)において通信方式が標準化されたモデムを含むものとして説明する。サーバ２０は、例えばＩｏＴモジュールと無線通信を行うサーバとしてよい。サーバ２０は、アンテナを介して、通信モジュール１０のようなクライアント端末と無線通信してよい。

図１に示すように、サーバ２０は、通信部２１と、制御部２２と、記憶部２３とを備える。

通信部２１は、一般的な無線通信において、信号の送受信の機能を実現する各種の部品とすることができる。例えば、通信部２１は、例えば通信モジュール１０などのクライアント端末と信号の送受信を行うアンテナを含んでよい。また、通信部２１は、一般的なＲＦ(radio frequency)部などを少なくとも含む部品で構成することができる。通信部２１は、典型的には、ベースバンド部において処理された信号を変調してから、アンテナを経て送信することができる。また、通信部２１は、例えばアンテナを経て受信した信号を復調してベースバンド部に受け渡すことができる。通信部２１は、例えば、ＲＦＩＣ（Radio Frequency Integrated Circuit）、パワーアンプ、フィルタ、スイッチ素子等の少なくとも一部を含んでよい。

制御部２２は、種々の機能を実行するための制御及び処理能力を提供するために、例えばＣＰＵ(Central Processing Unit)のような、少なくとも１つのプロセッサを含む。プロセッサは、単一の集積回路として実現されてよい。集積回路は、ＩＣ（Integrated Circuit）ともいう。プロセッサは、複数の通信可能に接続された集積回路及びディスクリート回路として実現されてよい。プロセッサは、他の種々の既知の技術に基づいて実現されてよい。一実施形態において、制御部２２は、ＬｗＭ２Ｍの規格に準拠したサーバにおける動作を行ってよい。

記憶部２３は、半導体メモリ又は磁気メモリ等で構成されてよい。記憶部２３は、各種情報及び制御部２２で実行されるプログラム等を記憶する。記憶部２３は、制御部２２のワークメモリとして機能してよい。また、記憶部２３は、制御部２２に含まれてもよい。記憶部２３は、サーバ２０に接続される外部ストレージとしてもよい。また、記憶部２３は、サーバ２０と通信部２１を経て通信する他のサーバの記憶部としてもよい。一実施形態において、記憶部２３は、ＬｗＭ２Ｍの規格に準拠したサーバにおける動作に必要な各種情報を記憶してよい。

次に、一実施形態に係る通信システム１の動作を説明する。

まず、一実施形態に係る通信システム１の動作を説明するために、ＬｗＭ２Ｍのような規格において想定されるＦＯＴＡについて説明する。ここで、一実施形態に係る通信システム１において行われるＦＯＴＡは、通信モジュール１０のファームウェアを、サーバ２０から無線で配信する（Firmware On-The-Air）ことを意味する。通信モジュール１０は、ＦＯＴＡによってサーバ２０から無線で配信されたファームウェアをダウンロードして、ファームウェアの更新を行うことができる。

ＬｗＭ２Ｍにおいては、サーバ２０からクライアントデバイスである通信モジュール１０に対して発信される各種の要求が規定されている。すなわち、ＬｗＭ２Ｍにおいては、サーバ２０が主導して、通信モジュール１０を制御することができる。一方、ＬｗＭ２Ｍにおいては、通信モジュール１０からサーバ２０に対して送信される要求は規定されていない。すなわち、ＬｗＭ２Ｍにおいては、通信モジュール１０の主導により、サーバ２０を制御する動作については、規定されていない。このため、ＦＯＴＡを行う際には、サーバ２０が主導することが想定される。

図２は、ＬｗＭ２Ｍの規格に準拠した通信システムにおけるＦＯＴＡの例を説明する図である。図２は、通信システム１において、通信モジュール１０とサーバ２０との間のやりとりを説明するシーケンス図である。以下、図２を参照して、ＬｗＭ２Ｍの規格に準拠した通信システム１におけるＦＯＴＡの例を説明する。

図２に示すように、通信システム１において、サーバ２０は、ＦＯＴＡを開始する。図２に示す動作が開始する時点において、サーバ２０は、通信モジュール１０のファームウェアのバージョン情報などを把握しており、通信モジュール１０のファームウェアのアップデートが必要であると判断しているものとする。

以下の説明において、通信モジュール１０が行う各種の動作は、通信モジュール１０の制御部１２が、対応する通信モジュール１０の各機能部を制御することにより行う。特に、通信モジュール１０が各種情報を送受信する動作は、通信モジュール１０の制御部１２が、通信部１１を制御することにより行う。例えば、通信モジュール１０の制御部１２は、記憶部１３に記憶された情報又はセンサによって検出された情報を、通信部１１からサーバ２０などに送信するように制御を行ってよい。また、例えば、通信モジュール１０の制御部１２は、通信部１１によってサーバ２０などから受信した情報を、記憶部１３に記憶するように制御を行ってよい。

同様に、以下の説明において、サーバ２０が行う各種の動作は、サーバ２０の制御部２２が、対応するサーバ２０の各機能部を制御することにより行う。特に、サーバ２０が各種情報を送受信する動作は、サーバ２０の制御部２２が、通信部２１を制御することにより行う。例えば、サーバ２０の制御部２２は、記憶部２３に記憶された情報などを、通信部２１から通信モジュール１０などに送信するように制御を行ってよい。また、例えば、サーバ２０の制御部２２は、通信部２１によって通信モジュール１０などから受信した情報を、記憶部２３に記憶するように制御を行ってよい。

図２に示すように、ＦＯＴＡが開始されると、サーバ２０は、通信モジュール１０に対して、ファームウェアの差分ファイルのダウンロードを開始するよう要求する（図２に示す（１））。（１）に示す差分ファイルのダウンロードの開始要求に続いて、サーバ２０は、通信モジュール１０にファームウェアの差分ファイルを送信し、通信モジュール１０は、サーバ２０からファームウェアの差分ファイルを受信する。すなわち、通信モジュール１０は、サーバ２０から、ファームウェアの差分ファイルをダウンロードする（図２に示す（２））。（２）においては、ファームウェアの１つ以上の差分ファイルがダウンロードされてもよい。（２）に示す差分ファイルのダウンロードが全て行われたら、通信モジュール１０は、差分ファイルのダウンロードが完了した旨をサーバ２０に通知する（図２に示す（３））。以上の動作によって、通信システム１の通信モジュール１０におけるファームウェアのダウンロード処理が完了する。

（３）に示す差分ファイルのダウンロードが完了したら、サーバ２０は、通信モジュール１０に対して、ファームウェアの更新を開始する要求する（図２に示す（４））。（４）に示す更新の要求に応じて、通信モジュール１０は、ファームウェアの更新処理を行う（図２に示す（５））。（５）に示すファームウェアの更新処理が行われたら、通信モジュール１０は、ファームウェアの更新が完了した旨をサーバ２０に通知する（図２に示す（６））。以上の動作によって、通信システム１の通信モジュール１０におけるファームウェアの更新処理が完了する。

以上説明したように、サーバ２０の主導によれば、ＬｗＭ２Ｍの規格に準拠した通信システムにおいてもＦＯＴＡを行うことができる。しかしながら、上述のように、ＬｗＭ２Ｍにおいては、通信モジュール１０からサーバ２０に対して送信される要求が規定されていない。このため、ＬｗＭ２Ｍの規格に準拠した通信システム１において、通信モジュール１０側の動作をトリガとしてＦＯＴＡを行うことはできない。

これに対し、ＬｗＭ２Ｍ以外の規格に準拠した通信システム１において、通信モジュール１０からサーバ２０に対して送信される要求が規定されていれば、通信モジュール１０側の動作をトリガとしてＦＯＴＡを行うことができる。以下、そのような場合について説明する。

図３は、ＬｗＭ２Ｍ以外の規格に準拠した通信システムにおけるＦＯＴＡの例を説明する図である。図３は、図２と同様に、通信システム１において、通信モジュール１０とサーバ２０との間のやりとりを説明するシーケンス図である。以下、図３を参照して、ＬｗＭ２Ｍ以外の規格におけるＦＯＴＡの例を説明する。ＬｗＭ２Ｍ以外の規格とは、例えば、ＦＵＭＯ（Firmware Update Management Object）などとしてよい。ＦＵＭＯは、無線経由（Over-the-air（ＯＴＡ））でファームウェアの更新を可能にするＯＭＡのデバイス管理仕様である。ＦＵＭＯの仕様については、ＯＭＡによる“Firmware Update Management Object Architecture, Approved Version 1.0 - 09 Feb 2007”などに記載されている。図３に示す通信システムにおいては、通信モジュール１０からサーバ２０に対して送信される要求が規定されているものとする。

図３に示す動作が開始すると、まず、通信モジュール１０は、ＦＯＴＡを開始する（図３に示す（１））。これにより、通信モジュール１０は、サーバ２０から任意のタイミングでファームウェアをダウンロードすることができる。

（１）に示すＦＯＴＡが開始されると、通信モジュール１０は、ファームウェアの差分ファイルの有無の確認を、サーバ２０に要求する（図３に示す（２））。（２）に示す確認要求に応じて、サーバ２０は、通信モジュール１０のファームウェアのバージョン情報を、通信モジュール１０に問い合わせる（図３に示す（３））。（３）に示す問合せに応じて、通信モジュール１０は、通信モジュール１０のファームウェアのバージョン情報を、サーバ２０に通知する（図３に示す（４））。

（４）に示すバージョン情報の通知に基づいて、サーバ２０は、通信モジュール１０のファームウェアの更新が必要であるか否かを判定する。例えば、通信モジュール１０から通知されたファームウェアのバージョン情報が、最新のファームウェアを示すものであれば、サーバ２０は、通信モジュール１０のファームウェアの更新は必要ないと判定する。この場合、サーバ２０は、ダウンロードすべきファームウェアの差分ファイルがないことを、通信モジュール１０に通知する（図３に示す（５））。そして、通信モジュール１０は、ファームウェアのダウンロードを行わず、ファームウェアの更新処理も行わずに、図３に示す動作を終了してよい。

一方、（４）に示すバージョン情報の通知から、例えば通信モジュール１０のファームウェアが最新でないと示された場合、サーバ２０は、通信モジュール１０のファームウェアの更新は必要であると判定する。この場合、サーバ２０は、ダウンロードすべきファームウェアの差分ファイルがある旨を、通信モジュール１０に通知する（図３に示す（５））。

（５）に示す差分ファイルがある旨を通知されると、通信モジュール１０は、ファームウェアの差分ファイルのダウンロードを、サーバ２０に要求する（図３に示す（６））。（６）に示す差分ファイルのダウンロードの要求に応じて、サーバ２０は、通信モジュール１０にファームウェアの差分ファイルの送信を開始し、通信モジュール１０は、サーバ２０からファームウェアの差分ファイルの受信を開始する。すなわち、通信モジュール１０は、サーバ２０から、ファームウェアの差分ファイルのダウンロードを開始する（図３に示す（７））。

（７）においてダウンロードが開始されると、サーバ２０から通信モジュール１０にファームウェアの差分ファイルがダウンロードされる（図３に示す（８）～（９））。（８）～（９）においては、ファームウェアの１つ以上の差分ファイルがダウンロードされてもよい。（８）～（９）に示す差分ファイルのダウンロードが全て行われたら、通信モジュール１０は、差分ファイルのダウンロードが完了した旨を、サーバ２０に通知する（図３に示す（１０））。

（１０）においてダウンロードの完了が通知されると、サーバ２０は、ファームウェアの更新の開始を、通信モジュール１０に要求する（図３に示す（１１））。（１１）に示す更新開始の要求に応じて、通信モジュール１０は、ファームウェアの更新を行う（図３に示す（１２））。（１２）に示す更新が完了すると、通信モジュール１０は、ＦＯＴＡが完了した旨を、サーバ２０に通知する（図３に示す（１３））。（１３）においてＦＯＴＡ完了の旨を通知してから、通信モジュール１０は、自装置のＦＯＴＡを完了する（図３に示す（１４））。

なお、図３の（１）に示したＦＯＴＡの開始は、例えば通信モジュール１０の制御部１２が発するトリガに基づいてもよい。また、図３の（１）におけるＦＯＴＡの開始は、通信モジュール１０を含むＩｏＴユニットが発するトリガに基づいてもよいし、通信モジュール１０に接続される他の機能部が発するトリガに基づいてもよい。

また、図３の（１４）の後、通信モジュール１０の制御部１２は、例えば通信モジュール１０に接続される他の機能部にＦＯＴＡ中でないことを示すために、ＤＭ＿ＩＮＤ信号をＬｏｗにしてもよい。

以上説明したように、ＬｗＭ２Ｍ以外の例えばＦＵＭＯのような規格に準拠した通信システムにおいて、クライアントである通信モジュール１０の主導で、ＦＯＴＡを行うことも想定できる。しかしながら、上述のように、ＬｗＭ２Ｍにおいては、通信モジュール１０からサーバ２０に対して送信される要求が規定されていない。このため、ＬｗＭ２Ｍの規格に準拠した通信システム１においては、図３に示したような、通信モジュール１０側の動作をトリガとしてＦＯＴＡを行うことはできない。

具体的には、例えば図３の（２）に示したファームウェアの差分ファイルの有無の確認を、通信モジュール１０からサーバ２０に要求するようなコマンドは、ＬｗＭ２Ｍにおいて規定されていない。また、例えば図３の（６）に示した差分ファイルのダウンロードを、通信モジュール１０からサーバ２０に要求するようなコマンドも、ＬｗＭ２Ｍにおいて規定されていない。さらに、例えば図３の（１３）に示したＦＯＴＡが完了した旨を、通信モジュール１０からサーバ２０に通知するようなコマンドも、ＬｗＭ２Ｍにおいて規定されていない。したがって、通常のＬｗＭ２Ｍのような規格に準拠したシステムにおいては、図３に示したような動作に従って、通信モジュール１０側の動作をトリガとしてＦＯＴＡを行うことはできない。

通信モジュール１０において、ファームウェアのアップデートを行った後、リセット処理又は再起動などが必要になることもある。このため、例えば通信モジュール１０の動作中に再起動が実行されると、実行中の処理が中断されるなどの不都合も想定される。通信モジュール１０にとって好適なタイミングで、通信モジュール１０側からのトリガによってファームウェアのダウンロード及び／又はアップデートを行うことができれば、通信システムの利便性を高めることができる。

そこで、一実施形態に係る通信システム１は、ＬｗＭ２Ｍのような規格に準拠していても、通信モジュール１０側の動作をトリガとしてＦＯＴＡを行うことを可能にする。

上述したように、ＬｗＭ２Ｍの仕様は、仕様書に詳細に記述されている。また、ＬｗＭ２Ｍのイネーブラのプロトコルスタックなども、上記仕様書に記載されている。ＬｗＭ２Ｍの情報報告(Information Reporting)のインタフェースにおいては、仕様書の5.5 Information Reporting Interfaceに規定されている。仕様書によれば、ダウンリンクの動作として規定された監視(Observe)及び監視取消(Cancel Observation)と、アップリンクの動作として規定された通知(Notify)とが規定されている。また、ＬｗＭ２Ｍのサーバ及びＬｗＭ２Ｍのクライアントは、このインタフェースの全ての動作をサポートしなければならない旨が、仕様書において規定されている。

仕様書によれば、ＬｗＭ２Ｍにおいては、クライアントからサーバに「要求」を送信することは規定されていない。しかしながら、ＬｗＭ２Ｍにおいて、クライアントからサーバにNotifyのような「通知」を行うことはできる。そこで、一実施形態において、サーバ２０は、通信モジュール１０に対して所定のリソースの監視を要求し、当該監視を要求されたリソースに変化があった場合、当該変化を示す通知がサーバ２０に送信されるようにする。なお、サーバ２０が通信モジュール１０に対して所定のリソースの監視を要求するとは、「サーバ２０が通信モジュール１０の所定のリソースを監視する」と読み替えることもできる。サーバ２０は、通信モジュール１０の所定のリソースを監視し、当該監視の対象となるリソースに変化があった場合、当該変化を示す通知が通信モジュール１０からサーバ２０に送信されるようにしてよい。ここで、「リソース」とは、ＬｗＭ２Ｍの規格の仕様で規定されるものであってよい。また、リソースは、任意の値が持つ定義であって、通信モジュール１０（クライアント）とサーバ２０が認識可能な定義である、ということもできる。

このような動作を実現するために、通信システム１において、監視を要求するための所定のリソースを用意する。ここで、用意すべき所定のリソースは、新規リソースであってもよいし、既存リソースのうち空きリソースであってもよいし、既存リソースを規定しなおしてもよい。サーバ２０と通信モジュール１０との間で対応付けされているリソースであれば、任意のリソースを採用してよい。そして、サーバ２０は、当該所定のリソースが通信モジュール１０において監視されるように要求する(Observe)。

このような状況において、通信モジュール１０は、ファームウェアを更新する際に、監視が要求されているリソースの値を変更する。ＬｗＭ２Ｍにおいては、このようにリソースの値が変更されると、当該リソースにおける変化を示す通知が、クライアント端末からサーバに送信される(Notify)。したがって、サーバ２０においては、このような通知を受信したタイミングで、ファームウェアの更新に関連する処理を実行することができる。

図４は、一実施形態に係る通信システム１において通信モジュール１０側の動作をトリガとして行うＦＯＴＡの例を説明する図である。以下、図４を参照して、通信モジュール１０側の動作をトリガとしたＦＯＴＡについて説明する。

図４に示す通信システム１において、通信モジュール１０は、例えば、３ＧＰＰ（3rd Generation Partnership Project）のＲｅｌｅａｓｅ１３仕様等に含まれる機能を有してもよい。３ＧＰＰのＲｅｌｅａｓｅ１３仕様は、ＵＥ（User Equipment）カテゴリＭ１でサポートされる機能と、ＮＢ－ＩｏＴ（Narrow Band IoT）カテゴリでサポートされる機能とを含む。以下、３ＧＰＰで規定された通信機能の一部について説明する。

［ＤＲＸ］
３ＧＰＰのＲｅｌｅａｓｅ８から、通信装置による通信を省電力化する技術として、ＤＲＸ(Discontinuous Reception)と呼ばれる間欠受信が規定された。以下、このような間欠受信(Discontinuous Reception)を、適宜、「ＤＲＸ」と略記する。ＤＲＸは、間欠的に信号を受信することにより、受信していない期間はＲＦ(Radio Frequency)機能部を停止させてスリープ状態とすることにより、消費電力を抑える技術である。ＤＲＸの動作は、ＲＲＣ(Radio Resource Control)のアイドル状態(RRC_IDLE)及びＲＲＣの接続状態(RRC_CONNECTED)において、下り制御チャネル(ＰＤＣＣＨ：Physical Downlink Shared Channel)の信号を間欠的に受信する際に適用される。ＤＲＸサイクルは、最大２．５６秒と規定されている。ＤＲＸについては、３ＧＰＰにおいて詳細に規定されているため、より詳細な説明は省略する。

一実施形態において、通信モジュール１０は、３ＧＰＰの仕様で規定されているＤＲＸ技術に基づいて、アンテナから電波を送受信してよい。以下の説明において、ＤＲＸ技術は、後述のｅＤＲＸ（extended DRX）技術を含んでもよい。一実施形態において、ＤＲＸ技術は、通信モジュール１０に間欠的に電波を受信させることによって、通信モジュール１０の消費電力を低減しうる技術である。通信モジュール１０は、ＤＲＸ技術に基づいて電波を送受信する場合、所定期間にわたって電波の送受信を停止することによって、間欠的な電波の送受信を実現しうる。通信モジュール１０がＤＲＸを開始し、ＤＲＸを終了するまでの期間は、ＤＲＸ期間ともいう。以下、ＤＲＸ技術に基づいて電波の送受信を停止する所定期間は、適宜、ＤＲＸにおけるスリープ期間ともいう。

［ｅＤＲＸ］
また、３ＧＰＰのＲｅｌｅａｓｅ１３から、ＤＲＸサイクルをさらに延長するため、信号の間欠受信の期間を大幅に延長した、拡張間欠受信(extended DRX)が規定された。以下、このような拡張間欠受信(extended DRX)を、適宜、ｅＤＲＸと略記する。ｅＤＲＸでは、バッテリの省電力化を向上させるために、スリープ状態の延長を実現している。RRC_CONNECTEDにおいては、最大のｅＤＲＸサイクルとして、１０．２４秒（ＬＴＥ）を設定することができる。また、RRC_IDLEにおいては、最大のｅＤＲＸサイクルとして、カテゴリＭ１の場合は４３．９６分（ｅＭＴＣ）、ＮＢ－ＩｏＴの場合は２．９１時間（ＮＢ－ＩｏＴ）を設定することができる。ｅＤＲＸについても、３ＧＰＰにおいて詳細に規定されているため、より詳細な説明は省略する。以下の説明において、ｅＤＲＸについて、適宜、単にＤＲＸと総称することがある。また、ｅＤＲＸ技術に基づいて電波の送受信を停止する所定期間は、適宜、ｅＤＲＸにおけるスリープ期間ともいう。

［ＰＳＭ］
さらに、３ＧＰＰにおいて、従来のアイドル状態及び接続状態の他に、省電力モード(Power Saving Mode)が規定された。以下、このような省電力モード(Power Saving Mode)を、適宜、ＰＳＭと略記する。ＰＳＭは、ネットワーク上への登録を維持しつつ、端末が一定時間擬似的に電源オフと同じ状態に遷移する動作である。このＰＳＭにおいては、通信装置は基地局からのページングも受信しないスリープ状態にあるため、ネットワークからは見えなくなるが、データ送信はいつでも可能とすることができる。３ＧＰＰのＲｅｌｅａｓｅ１２で定められたＣａｔ１のＰＳＭでは、１日１回、１ＫＢ程度のデータを送ると想定した場合、単３電池２本で１０年以上利用可能としている。ＰＳＭについても、３ＧＰＰにおいて詳細に規定されているため、より詳細な説明は省略する。

図４に示すように、一実施形態に係る通信システム１においては、通信モジュール１０からＦＯＴＡのトリガを発するために、サーバ２０は、差分ファイル有無確認用のリソースを監視するように、通信モジュール１０に要求する(Observe)。このような動作を行うために、通信システム１において、予め差分ファイル有無確認用のリソース(CheckUpdate)を追加する。そして、サーバ２０は、当該リソースの監視を通信モジュール１０に要求する（図４に示す（１））。

（１）においてリソースの監視が要求された後、通信モジュール１０は、任意のタイミングでＦＯＴＡをトリガすることができる。そこで、例えば通信モジュール１０に接続される他の機能部が、ＦＯＴＡ開始のＡＴコマンドであるＡＴ＋ＫＦＯＴＡを発することにより、ＦＯＴＡを開始してもよい。また、例えば通信モジュール１０のユーザによる入力に基づいて、ＦＯＴＡを開始してもよい。以下、通信モジュール１０が、任意の方法により、通信モジュール１０における任意のタイミングで、ＦＯＴＡを開始するものとして説明する（図４に示す（２））。

（２）においてＦＯＴＡが開始されると、通信モジュール１０は、例えば上述したｅＤＲＸ（ＤＲＸ）及び／又はＰＳＭを停止してもよい（図４に示す（３））。ここで、通信システム１がｅＤＲＸ（ＤＲＸ）及び／又はＰＳＭに対応していない場合、（３）に示す動作は行わなくてもよい。また、通信システム１がｅＤＲＸ（ＤＲＸ）及び／又はＰＳＭに対応している場合であっても、（３）に示す動作を省略してもよい。

（２）に示すようにＦＯＴＡが開始されたら、又は（３）に示すようにｅＤＲＸ（ＤＲＸ）及び／又はＰＳＭが停止されたら、通信モジュール１０は、監視を要求されたリソースの値としてTRUEを設定する（図４に示す（４））。

また、（３）動作の後（（３）の動作を行わない場合は（２）の動作の後）、例えば通信モジュール１０に接続される他の機能部にＦＯＴＡ中であることを示すために、通信モジュール１０の制御部１２は、ＤＭ＿ＩＮＤ信号をＨｉｇｈにしてもよい。

（４）においてリソースの値が設定されると、通信モジュール１０は、CheckUpdateのリソースの値がTRUEに変化した旨を、サーバ２０に通知する（図４に示す（５））。上述のように、ＬｗＭ２Ｍの仕様により、（４）においてリソースの値が変更されると、当該リソースにおける変化を示す旨が、クライアント端末からサーバに送信される(Notify)。

（５）において通知がされると、サーバ２０は、図３の（３）で説明したのと同様に、通信モジュール１０のファームウェアのバージョン情報を問い合わせる（図４に示す（６））。この場合、図４の（６）に示すように、サーバ２０は、通信モジュール１０のFirmware Versionのリソースの値を例えばReadコマンドを発することにより読み出してもよい。（６）に示すバージョンの問合せに応じて、通信モジュール１０は、通信モジュール１０のファームウェアのバージョン情報(Version)を、サーバ２０に通知する（図４に示す（７））。

（７）に示すようにバージョン情報を受信すると、サーバ２０は、図４の（８）に示すように、差分ファイル有無確認用のリソース(CheckUpdate)の監視を取り消す(Cancel Observation)ように、通信モジュール１０に要求する。（１）において監視を要求したリソースの監視を（８）において取り消すことで、その後も通信モジュール１０からNotifyのような通知がサーバ２０に繰り返し送信されることを防ぐことができる。なお、サーバ２０がリソースの監視を取り消すように、通信モジュール１０に要求する、とは「サーバ２０が通信モジュール１０のリソースの監視を取り止める」と読み替えることもできる。

（８）においてリソースの監視が取り消されたら、サーバ２０は、ダウンロード開始用のリソースを監視するように、通信モジュール１０に要求する(Observe)。このような動作を行うために、通信システム１において予めダウンロード開始用のリソース(StartDownload)を追加する。そして、サーバ２０は、当該リソースの監視を通信モジュール１０に要求する（図４に示す（９））。（９）に示すようにリソースの監視が要求された後、通信モジュール１０は、任意のタイミングでファームウェアのダウンロードをトリガすることができる。

（９）においてリソースの監視が要求されたら、サーバ２０は、結果確認用のリソース(CheckUpdateResult)に対して、例えばWriteコマンドを発することにより、差分ファイルの有無の確認結果を、通信モジュール１０に通知する（図４に示す（１０））。（１０）において差分ファイルがない旨の結果を受信したら、通信モジュール１０は、ファームウェアのダウンロードを行わず、ファームウェアの更新処理も行わずに、図４に示す動作を終了してよい。

一方、（１０）において差分ファイルがある旨の結果を受信したら、通信モジュール１０は、監視を要求されたリソースの値としてTRUEを設定する（図４に示す（１１））。（１１）においてリソースの値が設定されると、通信モジュール１０は、StartDownloadのリソースの値がTRUEに変化した旨を、サーバ２０に通知(Notify)する（図４に示す（１２））。

（１２）においてサーバ２０に通知がされたら、サーバ２０は、図４の（１３）に示すように、ダウンロード開始用のリソース(StartDownload)の監視を取り消す(Cancel Observation)ように、通信モジュール１０に要求する。（９）において監視を要求したリソースの監視を（１３）において取り消すことで、その後も通信モジュール１０からNotifyのような通知がサーバ２０に繰り返し送信されることを防ぐことができる。

（１３）においてリソースの監視が取り消されたら、サーバ２０は、アップデート結果通知用のリソースを監視するように、通信モジュール１０に要求する(Observe)。このような動作を行うために、通信システム１において予めアップデート結果通知用のリソース(UpdateResult)を追加する。そして、サーバ２０は、当該リソースの監視を通信モジュール１０に要求する（図４に示す（１４））。

（１４）においてリソースの監視が要求されたら、サーバ２０は、差分ファイルのパス指定用のリソース(Package/PackageURI)に対して、例えばWriteコマンドを発することにより、差分ファイルのパスを、通信モジュール１０に通知する（図４に示す（１５））。

（１５）において差分ファイルのパスが通知されたら、サーバ２０から通信モジュール１０にファームウェアの差分ファイルがダウンロードされる（図４に示す（１６）～（１７））。（１６）～（１７）においては、ファームウェアの１つ以上の差分ファイルがダウンロードされてもよい。（１６）～（１７）に示す差分ファイルのダウンロードが全て行われたら、通信モジュール１０は、差分ファイルのダウンロードが完了した旨を、サーバ２０に通知する（図４に示す（１８））。

（１８）においてダウンロードの完了が通知されると、通信モジュール１０は、ファームウェアの更新を行う（図４に示す（１９））。（１９）に示す更新が完了すると、通信モジュール１０は、監視を要求されたリソースの値として更新の「結果」を設定する（図４に示す（２０））。（２０）においてリソースの値が設定されると、通信モジュール１０は、UpdateResultのリソースの値が更新の「結果」に変化した旨を、サーバ２０に通知(Notify)する（図４に示す（２１））。

（２１）において通知を行うと、通信モジュール１０は、自装置のＦＯＴＡを完了する（図４に示す（２２））。（２２）に示す動作の後、通信モジュール１０は、（３）において停止したｅＤＲＸ（ＤＲＸ）及び／又はＰＳＭを再開してもよい（図４に示す（２３））。ｅＤＲＸ（ＤＲＸ）及び／又はＰＳＭを再開した場合、通信モジュール１０は、その後の電力の消費を低減することができる。

また、（２３）動作の後（（２３）の動作を行わない場合は（２２）の動作の後）、例えば通信モジュール１０に接続される他の機能部にＦＯＴＡ中でないことを示すために、通信モジュール１０の制御部１２は、ＤＭ＿ＩＮＤ信号をＬｏｗにしてもよい。

図４の（２）におけるＦＯＴＡの開始は、例えば通信モジュール１０に接続される他の機能部が発するＡＴコマンドに基づいてもよい。以下、例えば通信モジュール１０に接続される他の機能部が発するＡＴコマンドによってＦＯＴＡを開始する場合について説明する。

図４の（２）におけるＦＯＴＡの開始をＡＴコマンドによって行う場合、例えば通信モジュール１０に接続される他の機能部が、ＦＯＴＡ開始のＡＴコマンドであるＡＴ＋ＫＦＯＴＡを発してもよい。そして、通信モジュール１０の制御部１２は、ＦＯＴＡ開始のＡＴコマンドであるＡＴ＋ＫＦＯＴＡに応じて、図４の（２）においてＦＯＴＡを開始してもよい。また、このようにしてＦＯＴＡを開始した場合、例えば通信モジュール１０に接続される他の機能部にＦＯＴＡ中であることを示すために、通信モジュール１０の制御部１２は、ＤＭ＿ＩＮＤ信号をＨｉｇｈにしてもよい。

そして、図４の（１５）において差分ファイルのパスが通知された際、通信モジュール１０の制御部１２は、例えば通信モジュール１０に接続される他の機能部に対して、非請求リザルトのＡＴコマンドである＋ＦＯＴＡ：ＤＬＳＴＡＲＴを発してもよい。これは、通信モジュール１０に接続される他の機能部に対して、差分ファイルのダウンロードを開始したことを通知するための非請求リザルトである。

また、図４の（１６）～（１７）に示す差分ファイルのダウンロードが行われた際、通信モジュール１０の制御部１２は、例えば通信モジュール１０に接続される他の機能部に対して、非請求リザルトのＡＴコマンドである＋ＦＯＴＡ：ＤＬＯＫを発してもよい。これは、通信モジュール１０に接続される他の機能部に対して、差分ファイルのダウンロードが正常に完了したことを通知するための非請求リザルトである。

また、図４の（１９）において更新処理が開始される前に、通信モジュール１０の制御部１２は、例えば通信モジュール１０に接続される他の機能部に対して、非請求リザルトのＡＴコマンドである＋ＦＯＴＡ：ＵＰＳＴＡＲＴを発してもよい。これは、通信モジュール１０に接続される他の機能部に対して、ファームウェアの更新処理が開始したことを通知するための非請求リザルトである。

また、（１９）において更新処理が行われた後、通信モジュール１０の制御部１２は、通信モジュール１０のリセット処理を行ってもよい。この場合、通信モジュール１０の制御部１２は、（１９）に示す更新処理の後でリセット処理の前に、通信モジュール１０に接続される他の機能部に対して、ＤＭ＿ＩＮＤ信号を一度Ｌｏｗにしてもよい。また、通信モジュール１０の制御部１２は、リセット処理の後で、通信モジュール１０に接続される他の機能部に対して、ＤＭ＿ＩＮＤ信号を再びＨｉｇｈにしてもよい。

その後、通信モジュール１０の制御部１２は、例えば通信モジュール１０に接続される他の機能部に対して、非請求リザルトのＡＴコマンドである＋ＦＯＴＡ：ＵＰＯＫを発してもよい。これは、通信モジュール１０に接続される他の機能部に対して、ファームウェアの更新処理が正常に終了したことを通知するための非請求リザルトである。

また、図４の（２１）において通知が行われた後、通信モジュール１０の制御部１２は、例えば通信モジュール１０に接続される他の機能部に対して、非請求リザルトのＡＴコマンドである＋ＦＯＴＡ：ＯＫを発してもよい。これは、通信モジュール１０に接続される他の機能部に対して、ＦＯＴＡの一連の処理が正常に終了したことを通知するための非請求リザルトである。

このように、一実施形態に係る通信システム１は、少なくとも１つの通信モジュール１０と、サーバ２０と、を含む。また、一実施形態に係る通信システム１は、通信モジュール１０からサーバ２０に送信する要求のリソースが規定されていない規格に準拠する。特に、このような規格は、通信モジュール１０からサーバ２０に送信する要求であってソフトウェアの更新の要求のリソースが規定されていない規格としてもよい。一実施形態に係る通信システム１において、通信モジュール１０は、当該通信モジュール１０におけるソフトウェアを更新する際、サーバ２０によって監視を要求されたリソースにおける変化を示す通知をサーバ２０に送信する。また、一実施形態に係る通信システム１において、サーバ２０は、サーバ２０によって監視を要求されたリソースにおける変化を示す通知の受信に基づいて、ソフトウェアの更新に関連する処理を実行する。

以上説明したように、一実施形態に係る通信システム１によれば、通信モジュール１０にとって好適なタイミングで、通信モジュール１０側からのトリガによってファームウェア等のソフトウェアのダウンロード及び／又はアップデートを行うことができる。このため、一実施形態に係る通信システム１によれば、例えば通信モジュール１０の動作中に再起動が実行されて実行中の処理が中断されるなどの不都合は生じなくなる。したがって、一実施形態に係る通信システム１によれば、通信システムの利便性を高めることができる。

また、一実施形態に係る通信システム１において、通信モジュール１０は、例えば例えばＡＴコマンドのような所定のコマンドに基づいて、通信モジュール１０におけるソフトウェアの更新を開始してもよい。特に、通信モジュール１０は、例えば通信モジュール１０に接続された電子機器から入力される所定のコマンド（例えばＡＴコマンド）に基づいて、通信モジュール１０におけるソフトウェアの更新を開始してもよい。

このような通信システム１によれば、通信モジュール１０のユーザの所望するタイミングで、又は通信モジュール１０に接続された電子機器のユーザの所望するタイミングで、通信モジュール１０におけるソフトウェアの更新を開始することができる。このため、一実施形態に係る通信システム１によれば、通信システムの利便性を高めることができる。

また、一実施形態に係る通信システム１において、サーバ２０は、リソースにおける変化を示す通知を受信する前に、リソースにおける変化を通信モジュール１０が監視するように要求してもよい。

このような通信システム１によれば、例えばＬｗＭ２Ｍのような規格に準拠していても、通信モジュール１０側の動作をトリガとしてソフトウェアの更新を開始することができる。このため、一実施形態に係る通信システム１によれば、通信システムの利便性を高めることができる。

また、一実施形態に係る通信システム１において、通信モジュール１０は、ソフトウェアの更新の要否を確認するためのリソースにおける変化を示す通知をサーバ２０に送信してもよい。また、サーバ２０は、このような通知の受信に基づいて、ソフトウェアの更新の要否の確認に関連する処理を実行してもよい。また、一実施形態に係る通信システム１において、通信モジュール１０は、ソフトウェアの更新に関連するプログラムをサーバ２０からダウンロードするためのリソースにおける変化を示す通知を当該サーバに送信してもよい。この場合、サーバ２０は、このような通知の受信に基づいて、プログラムを通信モジュール１０に送信する処理を実行してもよい。また、一実施形態に係る通信システム１において、通信モジュール１０は、通信モジュール１０におけるソフトウェアの更新の結果を通知するためのリソースを利用して、その結果を前記サーバに送信してもよい。

このような通信システム１によれば、例えばＬｗＭ２Ｍのような規格に準拠していても、サーバ２０は、通信モジュール１０側の動作をトリガとして、ソフトウェアの更新に関連する処理を実行することができる。このため、一実施形態に係る通信システム１によれば、通信システムの利便性を高めることができる。

また、一実施形態に係る通信システム１において、サーバ２０は、リソースにおける変化を示す通知を受信した後、リソースにおける変化の通信モジュール１０による監視を取り消すように要求してもよい。

このような通信システム１によれば、通信モジュール１０からサーバ２０が要求した監視に応じた通知をサーバ２０が受信した後、このような通知が繰り返し送信されることを防ぐことができる。このため、一実施形態に係る通信システム１によれば、通信システムの利便性を高めることができる。

また、一実施形態に係る通信システム１において、通信モジュール１０は、ソフトウェアを更新する際、通信モジュール１０による間欠受信（ＤＲＸ）を停止してもよい。また、一実施形態に係る通信システム１において、通信モジュール１０は、ソフトウェアを更新する際、通信モジュール１０による通信の省電力モード（ＰＳＭ）を停止してもよい。

このような通信システム１によれば、ソフトウェアを更新する際には適切に通信が行われるようにしつつ、ソフトウェアを更新しない際には通信モジュール１０の消費電力を低減することができる。このため、一実施形態に係る通信システム１によれば、通信システムの利便性を高めることができる。上述の実施形態においては、ＬｗＭ２Ｍのような規格に準拠した通信システムにおいて、ＦＯＴＡを実現する例を主に説明してきたが、一実施形態は、このような態様に限定されない。ソフトウェア全般の無線による配信及び当該ソフトウェアに基づく更新を実現する技術（On-The-Air（ＯＴＡ））において、上述の実施形態を適用できる。

本開示を諸図面及び実施例に基づき説明してきたが、当業者であれば本開示に基づき種々の変形又は修正を行うことが容易であることに注意されたい。従って、これらの変形又は修正は本開示の範囲に含まれることに留意されたい。例えば、各機能部に含まれる機能などは論理的に矛盾しないように再配置可能である。複数の機能部等は、１つに組み合わせられたり、分割されたりしてよい。上述した本開示に係る各実施形態は、それぞれ説明した各実施形態に忠実に実施することに限定されるものではなく、適宜、各特徴を組み合わせたり、一部を省略したりして実施されうる。

例えば、上述した実施形態は、通信モジュール１０及びサーバ２０を含む通信システム１としての実施に限定されない。例えば、上述した実施形態は、通信システム１のようなシステムに含まれる通信モジュールとして実施してもよいし、通信システム１のようなシステムに含まれるサーバとして実施してもよい。また、例えば、上述した実施形態は、通信モジュール１０のような通信モジュールの制御方法として実施してもよいし、サーバ２０のようなサーバの制御方法として実施してもよい。さらに、例えば、上述した実施形態は、通信モジュール１０のような通信モジュールの制御プログラムとして実施してもよいし、サーバ２０のようなサーバの制御プログラムとして実施してもよい。

１ 通信システム装置
１０ 通信モジュール
１１ 通信部
１２ 制御部
１３ 記憶部
２０ サーバ
２１ 通信部
２２ 制御部
２３ 記憶部

Claims (15)

1. 通信モジュールと、サーバと、を含む通信システムであって、
   前記通信システムは、前記通信モジュールから前記サーバに送信する要求のリソースが規定されていない規格に準拠し、
   前記通信モジュールは、当該通信モジュールにおけるソフトウェアを更新する際、前記サーバによって監視を要求されたリソースの値を変更した後に、前記リソースにおける変化を示す通知を当該サーバに送信し、
   前記サーバは、前記通知の受信に基づいて、前記ソフトウェアの更新に関連する処理を実行する、
   通信システム。
2. 前記通信モジュールは、所定のコマンドに基づいて、前記通信モジュールにおけるソフトウェアの更新を開始する、請求項１に記載の通信システム。
3. 前記通信モジュールは、電子機器から入力される所定のコマンドに基づいて、前記通信モジュールにおけるソフトウェアの更新を開始する、請求項２に記載の通信システム。
4. 前記リソースは、前記ソフトウェアの更新の要否を確認するためのリソースを含み、
   前記処理は、前記ソフトウェアの更新の要否の確認に関連する処理を含む、
   請求項１から３のいずれかに記載の通信システム。
5. 前記リソースは、前記ソフトウェアの更新に関連するプログラムが前記通信モジュールによって前記サーバからダウンロードされるためのリソースを含み、
   前記処理は、前記ソフトウェアの更新に関連するプログラムを前記通信モジュールに送信する処理を含む、
   請求項１から３のいずれかに記載の通信システム。
6. 前記通信モジュールは、前記通信モジュールにおける前記ソフトウェアの更新の結果を通知するためのリソースを利用して、当該結果を前記サーバに送信する、請求項１から５のいずれかに記載の通信システム。
7. 前記サーバは、前記通知を受信する前に、前記リソースにおける変化を前記通信モジュールが監視するように要求する、請求項１から６のいずれかに記載の通信システム。
8. 前記サーバは、前記通知を受信した後、前記リソースにおける変化の前記通信モジュールによる監視を取り消すように要求する、請求項１から７のいずれかに記載の通信システム。
9. 前記通信モジュールは、当該通信モジュールにおけるソフトウェアを更新する際、前記通信モジュールによる間欠受信（ＤＲＸ）及び前記通信モジュールによる通信の省電力モード（ＰＳＭ）の少なくとも一方を停止する、請求項１から８のいずれかに記載の通信システム。
10. サーバに送信する要求のリソースが規定されていない規格に準拠した通信モジュールであって、
    前記通信モジュールにおけるソフトウェアを更新する際、前記サーバによって監視を要求されたリソースの値を変更した後に、前記リソースにおける変化を示す通知を、当該サーバに送信する、通信モジュール。
11. 請求項１に記載の通信システムにおいて用いられるサーバ。
12. サーバに送信する要求のリソースが規定されていない規格に準拠した通信モジュールの制御方法であって、
    前記通信モジュールにおけるソフトウェアを更新する際、前記サーバによって監視を要求されたリソースの値を変更した後に、前記リソースにおける変化を示す通知を、当該サーバに送信するステップを含む、通信モジュールの制御方法。
13. 通信モジュールから送信される要求のリソースが規定されていない規格に準拠したサーバの制御方法であって、
    前記通信モジュールにおいてソフトウェアが更新される際に、前記サーバによって監視を要求されたリソースにおける変化を示す通知を前記通信モジュールから受信するステップと、
    前記通知の受信に基づいて、前記ソフトウェアの更新に関連する処理を実行するステップと、
    を含む、請求項１に記載の通信システムにおいて用いられるサーバの制御方法。
14. サーバに送信する要求のリソースが規定されていない規格に準拠した通信モジュールを制御するコンピュータに、
    前記通信モジュールにおけるソフトウェアを更新する際、前記サーバによって監視を要求されたリソースの値を変更した後に、前記リソースにおける変化を示す通知を、当該サーバに送信するステップを実行させる、通信モジュールの制御プログラム。
15. 通信モジュールから送信される要求のリソースが規定されていない規格に準拠したサーバを制御するコンピュータに、
    前記通信モジュールにおいてソフトウェアが更新される際に、前記サーバによって監視を要求されたリソースにおける変化を示す通知を前記通信モジュールから受信するステップと、
    前記通知の受信に基づいて、前記ソフトウェアの更新に関連する処理を実行するステップと、
    を実行させる、請求項１に記載の通信システムにおいて用いられるサーバの制御プログラム。

Images