特開 2024-131806 警報器及び警報システム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024131806

(43)【公開日】2024-09-30

(54)【発明の名称】警報器及び警報システム

(51)【国際特許分類】

   G08B 17/00 20060101AFI20240920BHJP

   G08B 23/00 20060101ALI20240920BHJP

【ＦＩ】

G08B17/00 C

G08B23/00 530

【審査請求】有

【請求項の数】10

【出願形態】ＯＬ

(21)【出願番号】P 2023042275

(22)【出願日】2023-03-16

(11)【特許番号】

(45)【特許公報発行日】2023-12-13

(71)【出願人】

【識別番号】000190301

【氏名又は名称】新コスモス電機株式会社

(74)【代理人】

【識別番号】110001896

【氏名又は名称】弁理士法人朝日奈特許事務所

(72)【発明者】

【氏名】齋藤 和也

【テーマコード（参考）】

5C087

5G405

【Ｆターム（参考）】

5C087AA02

5C087AA03

5C087AA32

5C087DD04

5C087EE20

5C087FF01

5C087FF02

5C087FF04

5C087GG84

5G405AA10

5G405CA60

(57)【要約】

【課題】新たな制御方式を適宜取り入れることができ、且つ、警報器が有する警報機能などの各機能の停止期間の低減が可能な警報器及び警報システムを提供する。
【解決手段】実施形態の警報器１００は、周囲環境の監視結果に基づく報知、及び外部機器との交信を、内蔵するソフトウェアＳＷに含まれる命令に従って行う。警報器１００は、外部機器Ｅとの間で警報器１００の情報について所定周期で定期通信を行うように構成されており、ソフトウェアＳＷは、警報器１００の使用開始後にアップデートが可能なように内蔵されており、アップデートは、複数回の定期通信を通じて外部機器Ｅから分割して送られるアップデート用の更新データを用いて実行される。
【選択図】図１

【特許請求の範囲】

【請求項1】

周囲環境の監視結果に基づく報知、及び外部機器との交信を、内蔵するソフトウェアに含まれる命令に従って行う警報器であって、
前記警報器は、前記外部機器との間で前記警報器の情報について所定周期で定期通信を行うように構成されており、
前記ソフトウェアは、前記警報器の使用開始後にアップデートが可能なように内蔵されており、
前記アップデートが、複数回の前記定期通信を通じて前記外部機器から分割して送られる前記アップデート用の更新データを用いて実行される、警報器。

【請求項2】

周囲環境の監視結果に基づく報知を、内蔵するソフトウェアに含まれる命令に従って行う警報器と、
前記警報器との間で通信による情報交換を行う制御装置と、
を含む警報システムであって、
前記警報器は、前記制御装置との間で前記警報器の情報について所定周期で定期通信を行うように構成されており、
前記ソフトウェアは、前記警報器の使用開始後にアップデートが可能なように内蔵されており、
前記制御装置は、前記アップデート用の更新データを分割して複数回の前記定期通信を通じて前記警報器に送信し、
前記警報器は、分割して送られる前記更新データを用いて前記アップデートを実行するように構成されている、警報システム。

【請求項3】

前記警報器は、前記監視結果に基づく警報の発報時に前記外部機器に前記警報の発報を報せる通知を行うように構成されており、
前記アップデートが、さらに、前記通知に対する応答信号に含まれる分割された前記更新データを用いて実行される、請求項１記載の警報器。

【請求項4】

前記警報器は、前記監視結果に基づく警報の発報時に前記制御装置に前記警報の発報を報せる通知を行うように構成されており、
前記制御装置は、分割された前記更新データの少なくとも一部を、前記通知に対する応答信号の空き領域に格納して前記警報器に送信する、請求項２記載の警報システム。

【請求項5】

前記定期通信において前記警報器へのデータの伝送単位を構成する複数の領域のうちの前記更新データが送信されないときに無効データが格納される領域に格納されて送られる前記更新データを用いて前記アップデートが実行される、請求項１若しくは３記載の警報器、又は、請求項２若しくは４記載の警報システム。

【請求項6】

前記警報器は、前記監視結果に基づく警報の発報中には前記アップデートを実行しないように構成されている、請求項１若しくは３記載の警報器、又は、請求項２若しくは４記載の警報システム。

【請求項7】

前記警報器は、分割された前記更新データの全てを受け取ると、前記アップデートを開始するように構成されている、請求項１若しくは３記載の警報器、又は、請求項２若しくは４記載の警報システム。

【請求項8】

前記警報器は、前記定期通信において前記警報器へのデータの伝送単位に含まれる符号に基づいて、分割された前記更新データの全てを受け取ったことを認識するように構成されている、請求項１若しくは３記載の警報器、又は、請求項２若しくは４記載の警報システム。

【請求項9】

前記警報器は、前記ソフトウェアが内蔵されている記憶領域と、前記更新データが記憶される記憶領域とを備えている、請求項１若しくは３記載の警報器、又は、請求項２若しくは４記載の警報システム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、周囲環境を監視する警報器及び警報システムに関する。

【背景技術】

【0002】

従来、工場や住宅における火災やガス漏れなどを検知して警報を発する警報器には、温度や、各種のガスの存在などを検知するセンサなどの感知手段と、その検知結果に基づいて異常の有無を判断するマイコンなどの制御手段と、制御手段の判断結果に基づいて光や音声などを警報として発する報知手段などが備えられている。このような警報器において制御手段のマイコンなどは、ＲＯＭなどの記憶手段に格納されたプログラムに従って感知手段や報知手段を制御して、周囲環境を監視すると共に異常検知時に警報を発するように構成されている。

【0003】

例えば、特許文献１には、複数の警報器が無線通信で警報情報を共有することにより連動して警報を発する警報システムにおいて、制御回路が実行するプログラムを、第１記憶部に格納したプログラムと第２記憶部に格納したプログラムとの間で切り替えることによって、親局としての機能と子局としての機能とを切り替えることが開示されている。

【先行技術文献】

【特許文献】

【0004】

【特許文献1】特開２０１９－１７９３２９号公報

【発明の概要】

【発明が解決しようとする課題】

【0005】

火災の発生やガスの存在などを検知して警報を発する警報器の分野では、警報器が使用される国や自治体が定める法規に適合するための要件、例えば感知性能に関する規定や、異常と判断すべき温度やガスの濃度の基準などが変更されることがある。また、前述の特許文献１のように警報器は外部機器と通信回線で接続して使用されることがある。そしてこのような警報器を含む、通信機能を有する機器が準拠する通信プロトコルにおいては、新たな通信技術の開発やインフラストラクチャーの発展に呼応して、及び／又は、日々出現する新手のハッキング技術に対抗すべく、絶えずバージョンアップが重ねられている。

【0006】

そのため、警報器、特に通信機能を有する警報器には、例えば法規の変更や技術の伸展に追随すべく、また、警報器に対する新たな脅威から警報器の機能を保護すべく、警報器の使用開始後においても警報器の制御方式を記述したソフトウェアを適宜アップデートすることが求められる。そして、そのような制御用ソフトウェアが適宜アップデートされない場合は、例えば法規の改正に対応できず、警報器自体が動作可能であるにも関わらずその警報器を実質的に使用できなくなったり、通信のセキュリティを脅かす悪意のある技術の脅威に警報器が晒されたりすることにもなり得る。

【0007】

しかしながら、制御用ソフトウェアのアップデート中に警報機能が影響を受けるような構成の場合、例えば、アップデートデータのボリューム次第で、警報機能が長時間制限されることも起こり得る。そのような場合、周囲環境が異常な状態にあることの報知が遅れてしまってユーザーを危険に晒してしまう可能性がある。また、長時間の警報機能の停止は、前述したような警報器に対して定められる法規に違反してしまうことも考えられる。

【0008】

本発明は、上記問題に鑑みてなされたもので、新たな制御方式を適宜取り入れることができ、しかも、警報器が有する警報機能などの各機能の停止期間を少なくすることができる警報器及び警報システムを提供することを目的とする。

【課題を解決するための手段】

【0009】

本発明の警報器は、周囲環境の監視結果に基づく報知、及び外部機器との交信を、内蔵するソフトウェアに含まれる命令に従って行う警報器であって、警報器は、外部機器との間で警報器の情報について所定周期で定期通信を行うように構成されており、ソフトウェアは、警報器の使用開始後にアップデートが可能なように内蔵されており、アップデートが、複数回の定期通信を通じて外部機器から分割して送られるアップデート用の更新データを用いて実行される。

【0010】

本発明の警報システムは、周囲環境の監視結果に基づく報知を、内蔵するソフトウェアに含まれる命令に従って行う警報器と、警報器との間で通信による情報交換を行う制御装置と、を含む警報システムであって、警報器は、制御装置との間で警報器の情報について所定周期で定期通信を行うように構成されており、ソフトウェアは、警報器の使用開始後にアップデートが可能なように内蔵されており、制御装置は、アップデート用の更新データを分割して複数回の定期通信を通じて警報器に送信し、警報器は、分割して送られる更新データを用いてアップデートを実行するように構成されている。

【0011】

本発明の警報器は、監視結果に基づく警報の発報時に外部機器に警報の発報を報せる通知を行うように構成されており、アップデートが、さらに、通知に対する応答信号に含まれる分割された更新データを用いて実行されてもよい。

【0012】

本発明の警報システムにおいて、警報器は、監視結果に基づく警報の発報時に制御装置に警報の発報を報せる通知を行うように構成されており、制御装置は、分割された更新データの少なくとも一部を、通知に対する応答信号の空き領域に格納して警報器に送信してもよい。

【0013】

本発明の警報システムにおいて、定期通信において警報器へのデータの伝送単位を構成する複数の領域のうちの更新データが送信されないときに無効データが格納される領域に格納されて送られる更新データを用いてアップデートが実行されてもよい。

【0014】

本発明の警報器又は警報システムにおいて、警報器は、監視結果に基づく警報の発報中にはアップデートを実行しないように構成されていてもよい。

【0015】

本発明の警報器又は警報システムにおいて、警報器は、分割された更新データの全てを受け取ると、アップデートを開始するように構成されていてもよい。

【0016】

本発明の警報器又は警報システムにおいて、警報器は、定期通信において警報器へのデータの伝送単位に含まれる符号に基づいて、分割された更新データの全てを受け取ったことを認識するように構成されていてもよい。

【0017】

本発明の警報器又は警報システムにおいて、警報器は、ソフトウェアが内蔵されている記憶領域と、更新データが記憶される記憶領域とを備えていてもよい。

【発明の効果】

【0018】

本発明によれば、新たな制御方式を適宜取り入れることができ、しかも、警報器が有する警報機能などの各機能の停止期間を少なくし得ることがある。

【図面の簡単な説明】

【0019】

【図1】本発明の一実施形態の警報器の一例の概略を示すブロック図である。

【図2】一実施形態の警報器の記憶領域の構成及び記憶内容の一例を示す模式図である。

【図3】一実施形態の警報器と外部機器との間のデータ伝送単位のデータ構造例を示す図である。

【図4】一実施形態の警報器の動作の一例を示すフローチャートである。

【図5】一実施形態の警報器におけるアップデートの要求方法の例を示す模式図である。

【図6】一実施形態の警報器におけるアップデートの優先度と電池残量に応じた実行の判断との対応の一例を示す図である。

【図7】本発明の一実施形態の警報器の他の例の概略を示すブロック図である。

【図8】一実施形態の警報器の動作の他の例を示すフローチャートである。

【図9】一実施形態の警報器の変形例の概略を示すブロック図である。

【図10】本発明の一実施形態の警報システムの一例を示すブロック図である。

【発明を実施するための形態】

【0020】

以下、添付図面を参照しながら、本発明の一実施形態に係る警報器及び一実施形態に係る警報システムを説明する。但し、以下に説明される実施形態及び添付の図面は、本発明に係る警報器又は警報システムの一例を示しているに過ぎない。本発明に係る警報器及び警報システムの構成及び作用は、以下に説明される実施形態及び添付の図面に例示される構成及び作用に限定されない。

【0021】

＜一実施形態の警報器の基本構成及び作用＞
図１には、本発明の一実施形態の警報器１００の主要な構成要素がブロック図で示されている。一実施形態の警報器１００は、例えば、住居や工場などに設置されたり、使用者に携帯されたりして、警報器１００の周囲の環境を監視する。そして、警報器１００は、周囲の環境が特定の状態にある場合にはそれを検知して、例えば、警報を発したり、信号を送ったりして、周囲環境が特定の状態、例えば人体や物的資産に危害が及び得る異常な状態にあることを周囲の人や所定の機器に報せる。特定の状態としては、火災の発生、ガス漏れ、一酸化炭素の充満、煙の充満、過剰な温湿度、などが例示されるが、警報器１００が検知する特定の状態は、これらに限定されない。

【0022】

警報器１００は、図１に示されるように、制御部１０と、通信部２０と、制御部１０及び通信部２０が要する電力を供給する電源部３と、例えば警報器１００のユーザーなどに操作される被操作部５と、を備えている。制御部１０は、周囲環境を監視して監視結果に基づいて報知する報知機能を制御する。すなわち制御部１０は、警報器１００が有する本質的な機能である、周囲環境の監視から監視結果に基づく例えば警報の発報といった報知までの機能を制御する。通信部２０は、信号の送信及び受信のような警報器１００と外部機器Ｅとの間の交信を含む、警報器１００の通信機能を制御する。

【0023】

通信部２０は、無線回線Ｃ１又は有線回線Ｃ２を介して外部機器Ｅとの間で直接送受信を行ってもよく、無線回線Ｃ１又は有線回線Ｃ２で接続された、例えばインターネットやローカルエリアネットワーク（ＬＡＮ）などのネットワークＮを介して外部機器Ｅとの間で送受信を行ってもよい。外部機器Ｅとしては、警報器１００以外の同種、又は検知対象の異なる警報器が例示される。外部機器Ｅは、警報器１００の動作を監視若しくは制御する、及び／又は、警報器１００での検知結果若しくは警報発報経過を収集して統計処理若しくは解析するサーバーのような情報処理装置であってもよい。しかし、外部機器Ｅはこれらに限定されない。

【0024】

本実施形態の警報器１００では、通信部２０は、通常の監視の実行中、電源部３の状態（例えば、後述するように、電源部３が電池である場合における電池残量若しくは電池切れなど）、故障中、及び、警報発報中などの警報器１００の状態を所定周期で外部機器Ｅに送る通信（定期通信）を行うように構成されている。定期通信を行うことによって、外部機器Ｅから適時に適切な制御を受け得ることがある。所定周期は、警報器１００の検知対象や使用場所などによって適宜選択される。所定周期は、例えば数分程度であってもよく、数時間、あるいは数日程度であってもよい。

【0025】

電源部３は、制御部１０及び通信部２０を含む、警報器１００の内部の各構成要素に電力を供給する。電源部３は、例えば、商用電源（図示せず）から供給される電力を各構成要素に供給する。その場合、電源部３は、例えば、商用電源から供給される交流電力を所望の電圧の直流電力に変換するインバータや、警報器１００内の構成要素に印加される電源電圧を安定化させる電圧レギュレータなどによって構成され得る。電源部３は、商用電源からの電力ではなく、例えばリチウム一次電池、乾電池などの一次電池やバッテリなどの二次電池からの直流電力を警報器１００内の各構成要素に供給してもよい。すなわち、警報器１００は、電池式の警報器であってもよく、特に再充電不能な一次電池の電力で駆動する警報器であってもよい。

【0026】

本実施形態の警報器１００は、ソフトウェアＳＷを内蔵していて、ソフトウェアＳＷに含まれる命令に従って、前述した、周囲環境の監視、監視結果に基づく報知、及び外部機器Ｅとの交信を行う。図１の例において警報器１００が内蔵するソフトウェアＳＷは、制御部１０及び通信部２０それぞれを構成する処理装置１が有する記憶手段１１に格納されている。処理装置１は、制御部１０による報知機能の制御、及び通信部２０による外部機器Ｅとの間の通信の制御を具体的に担う半導体装置からなる。なお、本実施形態において警報器１００は、処理装置１が実行するソフトウェアＳＷを格納するＲＯＭなどの記憶手段（図示せず）を、処理装置１とは別に備えていてもよい。

【0027】

本実施形態の警報器１００では、ソフトウェアＳＷは、警報器１００の使用開始後に、要求に応じたソフトウェアＳＷのアップデートが可能なように内蔵されている。警報器１００が従う命令を含むソフトウェアＳＷのアップデートが警報器１００の使用開始後にも可能なので、例えば、適合すべき法規の変更や、外部機器Ｅとの通信に用いる通信規格の変更などに応じて、ソフトウェアＳＷをアップデートして、警報器１００を適切に動作させることができる。

【0028】

また、本実施形態の警報器１００において制御部１０は、周囲環境の異常の検知に応じて警報を発すると共に、警報発報中であることを外部機器Ｅに報せる通知を行うように構成されている。そのため、警報器１００の周囲だけでなく、警報を広範に届けることができる。例えば、遠方のユーザーや、その関係者にも警報器１００の周囲が特定の異常な環境にあることを報せることができる。従って、異常状態の解消に向けた迅速な措置を促すことができ、損害の発生や被害の拡大を防止できることがある。

【0029】

さらに、本実施形態の警報器１００は、前述したように、定期的に警報器１００の状態を外部機器Ｅに送信する定期通信を行うように構成されている。ここで、幾つかの通信規格では、送信側から送られる、通信パケットのようなデータの伝送単位ごとに、受信側から応答信号を返信するように規定されている。そこで、本実施形態では、ソフトウェアＳＷのアップデートがある場合には、データの伝送単位ごとに、ソフトウェアＳＷのアップデート用の更新データが、定期通信における外部機器Ｅからの応答信号に含めて送られる。１度のアップデートに必要な更新データは、複数の定期通信に渡って分割して送られる。そして、ソフトウェアＳＷのアップデートが、そのように複数回の定期通信を通じて送られる更新データを用いて実行される。

【0030】

なお、本明細書において、「ソフトウェアＳＷのアップデート」は、ソフトウェアＳＷのフルアップデートであっても、部分アップデートであってもよい。また、定期通信における外部機器Ｅからの応答信号に含められるソフトウェアＳＷのアップデート用の更新データは、更新データのうちの一部であってもよく、残りの更新データは、定期通信における外部機器Ｅからの応答信号以外の通信（例えば、更新データ送信専用の通信）によって送られてもよい。

【0031】

警報器１００は、制御用ソフトウェアのアップデート中に警報機能が影響を受けるような構成となることがある。その場合、アップデートデータのボリューム次第で、警報機能が長時間制限されることも起こり得る。例えば、図１に示される警報器１００のように、制御部１０と通信部２０とが処理装置１を共用する場合、処理装置１は、アップデート用の更新データの受信中の受信処理によって、警報機能を制限されることがあり得る。本実施形態の警報器１００では、前述のように、アップデート用の更新データが、定期通信における外部機器Ｅからの応答信号に含めて送られる。そのため、新たな制御方式を適宜取り入れることができ、しかも、警報器が有する警報機能などの各機能の停止期間を少なくすることができる。さらに、定期通信を利用することで、アップデート用の更新データを効率良く送受することができる。

【0032】

上記の通り警報器１００では、ソフトウェアＳＷに含まれる命令に従って、周囲環境の監視結果に基づく報知、及び外部機器Ｅとの交信が行われる。従って、ソフトウェアＳＷのアップデートは、報知機能に関するアップデートと通信機能に関するアップデートとの両方を含み得る。しかし、報知機能に関するアップデートは警報器１００の本質的機能のアップデートになるため、例えばアップデート用データの不備などによる万一の不具合を避けるべく、警報器１００において実施可能なソフトウェアＳＷのアップデートから報知機能に関するアップデートが除外されていてもよい。すなわち、ソフトウェアＳＷのアップデートは、報知機能に影響し難いと考えられる、通信機能に関するアップデートであってもよい。「通信機能に関するアップデート」及び「報知機能に関するアップデート」については、後に例示と共に詳述される。

【0033】

＜制御部の構成＞
本実施形態の警報器の構成及び作用が、以下にさらに詳細に説明される。図１の例において制御部１０は、検知部１２と、報知部１３と、前述した処理装置１及びその周辺回路（図示せず）と、を備えている。処理装置１は、制御部１０と通信部２０との間で共有されている。

【0034】

検知部１２は、主に、警報器１００の周囲の監視対象領域の物理現象を監視して監視データを出力する各種のセンサから構成される。各種のセンサは、たとえば、一酸化炭素ガス（ＣＯ）、メタンガス（ＣＨ₄）又はプロパンガス（Ｃ₃Ｈ₈）を検知する各種ガスセンサ、サーミスタなどからなる温度センサ、湿度センサ、煙センサ、又は臭気センサなどであってよい。検知部１２は、これらセンサの１つ又は複数で構成され得る。例えば、各種のガスセンサによってガス漏れが検知される場合、警報器１００はガス警報器であり得、温度センサ及び煙センサなどによって火災の発生が検知される場合、警報器１００は火災警報器であり得る。

【0035】

報知部１３は、例えば、発光ダイオード、ディスプレイ、ブザー及び／又はスピーカーなどの、警報器１００のユーザーなどへの報知手段により構成され、光の放射、鳴動、及び／又は音響を発することにより警報を発する。また、報知部１３は、警報を発する以外にも、警報器１００の状態や、警報を発するに至らない監視領域の環境に関する情報をユーザーなどに伝えるために動作してもよい。

【0036】

処理装置１は、マイコンやＡＳＩＣなどの半導体装置からなり、内蔵されたプログラムに従って動作する。なお、警報器１００が処理装置１と別にＲＯＭなどの記憶装置（図示せず）を備える場合は、処理装置１は、この外部の記憶装置に格納されたプログラムに従って動作してもよい。処理装置１は、好ましくは、演算機能、比較機能、記憶機能などを有している。制御部１０において処理装置１は、検知部１２及び報知部１３の動作を含む、警報器１００の報知機能に関する動作を全体的に制御する。例えば処理装置１は、検知部１２から得られる検知データが示す、一酸化炭素やガスの濃度、周囲の温度、及び、煙の濃度などが、所定の閾値を超えているか否かを判断する。そして、温度や濃度などが閾値を超えている場合には、例えばその超過の程度に応じて決定した態様で報知部１３に報知を実行させる。

【0037】

図１の例の処理装置１は、処理装置１での処理に必要な任意の情報を記憶する記憶手段１１を備えている。記憶手段１１は、処理装置１に組み込まれた、ＲＯＭ、ＰＲＯＭ（プログラマブルＲＯＭ）、ＲＡＭ、フラッシュメモリ、及び各種のレジスタなどのメモリ空間であり得る。記憶手段１１には、例えば、警報発報の判断基準であって検知部１２の検知データと比較される閾値、この閾値と検知データとの比較結果に対応付けられた報知部１３での報知態様、電池式の場合の電池の残量に関する所定の閾値、及び、通信部２０の状態に関する情報、などが記憶される。図１の例では、記憶手段１１を構成し得るメモリ、例えばＥＰＲＯＭ（イレーサブルＰＲＯＭ）に、警報器１００が従う命令を記述したプログラムを含むソフトウェアＳＷが格納されている。

【0038】

＜通信部の構成＞
通信部２０は、前述した制御部１０との間で共有する処理装置１及びその周辺回路（図示せず）と、送受信部２２とを備えている。送受信部２２は、無線通信又は有線通信によって外部機器Ｅとの間で信号を送受する。送受信部２２は、外部機器Ｅと警報器１００との間で電気信号を送受するように構成された、集積回路装置や個々の部品からなる電気回路などのハードウェア（例えば、ＡＳＩＣなどからなる通信制御ＩＣ又はモデムＩＣ、及びその周辺回路など）により構成される。送受信部２２によって、送受信信号の変換、増幅、変調／復調、並びに外部機器Ｅとの間のリンクの設定などが行われる。

【0039】

通信部２０において処理装置１は、警報器１００の動作中に送受信部２２で行われる、警報器１００と外部機器Ｅとの間での交信に必要な動作を全体的に制御する。例えば、処理装置１は、警報器１００における周囲環境の監視結果に基づいて実行される報知に関する情報を外部機器Ｅに送る動作を制御してもよい。この「報知に関する情報」は、警報器１００において監視結果に基づいて実行される報知に関するものであれば、特に限定されない。例えば、「報知に関する情報」は、検知部１２で得られる逐次若しくは継続的な検知データ、周囲環境が特定の状態にあると判断する閾値（警報発報基準）、警報の発報履歴、及び、警報器１００の状態（例えば正常状態で通常の監視実行中、電池式の場合の電池残量若しくは電池切れ、故障中、及び、警報発報中など）、などであり得る。処理装置１は、さらに、上記「報知に関する情報」以外の情報を外部機器Ｅに送る動作を制御してもよく、警報器１００の制御に関する情報などの任意の情報を外部機器Ｅから受け取る動作を制御してもよい。

【0040】

図１の例において処理装置１は計時手段２１を含んでいる。計時手段２１は、例えば、特定の時点からの経過時間をカウントする。計時手段２１は、例えば処理装置１を構成するマイコンなどの半導体装置に構成されたカウンタやタイマであり得る。計時手段２１は、例えば、通信部２０が行う前述した「定期通信」において、最後に警報器１００の状態が送られてからの経過時間をカウントする。

【0041】

被操作部５は、例えば、警報器１００のユーザーや管理者などによる操作が可能なように警報器１００に設けられている。被操作部５に対して、種々の所定の動作の実行を警報器１００に指示する各種の手動操作が行われる。被操作部５に対して、ソフトウェアＳＷのアップデートを要求する手動操作が行われてもよい。また、被操作部５に対して、ソフトウェアＳＷのアップデート以外の所定の動作を指示する操作（以下「第１操作」とも称する）が行われてもよい。被操作部５は、このようなソフトウェアＳＷのアップデートを要求する操作及び／又はアップデート以外の動作を指示する第１操作を受け得る。その場合、被操作部５に対する操作による指示は、電気信号などによって処理装置１に伝えられ、処理装置１で、被操作部５への操作によって指示された動作が実行される。例えば、ソフトウェアＳＷのアップデートが要求されたなら、アップデートが実行され得る。

【0042】

被操作部５としては、警報器１００に外部から視認及び接触可能に設けられた各種のスイッチが例示される。被操作部５として用いられるスイッチとしては、押し釦スイッチやトグルスイッチなどが例示されるが、これらに限定されない。また、被操作部５は、タッチパネルやキーパッドのような入力装置であってもよい。

【0043】

被操作部５として用いられるスイッチは、操作中のみ押し込まれて、操作が終了すると自動復帰するタクタイルスイッチが好ましいことがある。被操作部５がタクタイルスイッチで構成されている場合、押し込まれる時間の長さの違いによって、２種類以上の動作がそれぞれ指示されてもよい。例えば、押し込まれる時間が２秒未満の押し込み操作は、警報器１００の自主点検の要求と認識され、２秒以上５秒未満の押し込み操作は、発報中の警報の停止指示と認識され、５秒以上の押し込み操作は、ソフトウェアＳＷのアップデートの要求と認識されてもよい。

【0044】

＜ソフトウェアのアップデート＞
ソフトウェアＳＷは、記憶手段１１として備えられるＥＰＲＯＭ、好ましくは、ＥＥＰＲＯＭ（エレクトリカリー・イレーサブルＰＲＯＭ）やフラッシュメモリなどに格納されている。ＥＥＰＲＯＭ及びフラッシュメモリなどでは、例えば高電圧の印加などによって、既に記憶されている内容を書き換えることができる。例えばこのように、ＥＥＰＲＯＭやフラッシュメモリなどで構成される書き換え可能な記憶領域にソフトウェアＳＷを格納することによって、警報器１００の使用開始後であっても、ソフトウェアＳＷのアップデートの実行が可能となる。例えば、処理装置１が備えるＣＰＵ（図示せず）の制御の下で、記憶手段１１として備えられているフラッシュメモリ（又は処理装置１の外部の記憶装置）などの記憶内容が書き換えられ、その結果、ソフトウェアＳＷがアップデートされる。

【0045】

ソフトウェアＳＷは、処理装置１が行う動作に関する命令が記述された制御プログラムなどのソフトウェアを含み得る。ソフトウェアＳＷは、処理装置１のメモリ（例えばＥＥＰＲＯＭやフラッシュメモリで構成される記憶手段１１）に書き込まれている、処理装置１に関するファームウェアであってもよい。警報器１００の使用開始後にもアップデート可能なソフトウェアＳＷが処理装置１に関するファームウェアであると、例えば、法規の変更や通信規格の改定などによって処理装置１による基本的な制御方式の変更が求められる場合でも、その変更に容易に対応することができる。

【0046】

特に、警報器を含む各種機器間の通信において準拠される通信規格は、セキュリティ要件などに関して適宜改定されている。また通信規格は、新たに開発される通信技術を取り入れるべく改定されることもある。警報器１００には、アップデートが可能なようにソフトウェアＳＷが内蔵されているので、前述したように、適合すべき法規の変更や、外部機器Ｅとの通信に用いる通信規格の変更などに応じたアップデートの実行によって、制御方式などを適切に更新することができ、警報器１００を適切に動作させることができる。

【0047】

前述したように外部機器Ｅとの間で無線での交信も可能な通信部２０を含む警報器１００では、ソフトウェアＳＷのアップデートは、外部機器Ｅと通信部２０との無線通信に基づいて行われてもよい。すなわち、ソフトウェアＳＷのアップデートは、所謂「ＯＴＡ（Over-The-Air）アップデート」であってもよく、前述したようにソフトウェアＳＷがファームウェアである場合は、「ファームウェアＯＴＡ」であってもよい。その場合、例えば、遠隔地からでもソフトウェアＳＷをアップデートすることができる。

【0048】

なお、ソフトウェアＳＷのアップデートは、無線通信に依らずに行われてもよい。すなわち、アップデート後のソフトウェアＳＷは、警報器１００に接続された物理的な回線を通じて供給されてもよく、ＵＳＢメモリなどの記憶媒体を介して供給されてもよい。

【0049】

＜ソフトウェアを格納する記憶領域の構成＞
図２には、処理装置１が有する記憶領域、例えば記憶手段１１（図１参照）としてソフトウェアＳＷを格納すべく備えられる、例えばＥＥＰＲＯＭやフラッシュメモリなどのメモリの記憶領域４の構成及び記憶内容の一例が模式的に示されている。図２の例において、Ａ－００００番地からＡ－ｎｎｎｎ番地までのアドレスに、命令１～命令ｎで構成されるソフトウェアＳＷが格納されている。一例として、ソフトウェアＳＷのアップデートが行われる際には、アップデート後のソフトウェアＳＷが含むべき一連の命令が、Ａ－００００番地から順に、アップデート後のソフトウェアＳＷのサイズに対応する任意の番地までの領域に上書きされる。

【0050】

図２の例の記憶領域４は、Ａ－０００１番地からＡ－ＦＦＦＦ番地までの第１記憶領域Ａ１と共に、Ｂ－００００番地からＢ－ＦＦＦＦ番地までの第２記憶領域Ａ２を有している。従って、ソフトウェアＳＷのアップデートでは、アップデート後のソフトウェアＳＷが含むべき一連の命令が、第１記憶領域Ａ１に上書きされずに、第２記憶領域Ａ２に格納されてもよい。このようにアップデート後のソフトウェアＳＷが含むべき命令を格納することによって、処理装置１をアップデート前のソフトウェアＳＷに従って動作させながら、アップデート後のソフトウェアＳＷを、記憶手段１１として備えられるフラッシュメモリなどの記憶領域に書き込むことができる。そして、処理装置１によって次に実行されるべき命令が格納されている記憶手段１１のアドレスを保存するプログラムカウンタが、第２記憶領域Ａ２内の適切なアドレスに設定される。このようにして、報知機能が機能しない期間を全く生じさせずに、ソフトウェアＳＷのアップデートを行えることがある。

【0051】

＜更新データの供給態様＞
前述のように、本実施形態の警報器１００では、通信部２０は、通常の監視の実行中、電池式の場合の電池残量若しくは電池切れ、故障中、及び、警報発報中などの警報器１００の状態を所定周期で外部機器Ｅに送る通信（定期通信）を行うように構成されている。ここで、図３に示されるように、警報器１００から外部機器Ｅに警報器１００の状態などを送る際に準拠する通信規格では、通信パケットなどの伝送単位のデータ長が固定長として定められていることがある。そのような通信規格の下で警報器１００の状態が外部機器Ｅに送信される場合、例えば外部機器Ｅを示す宛先などの制御情報を含むヘッダＨ１と、ペイロードＰ１とで構成される固定長のパケットＰｓが送信される。ペイロードＰ１に実際の送信対象のデータである警報器１００の状態を示すデータが格納される。

【0052】

パケットＰｓを受け取った外部機器Ｅは、特に警報器１００に送るデータが無くても、準拠する通信規格の規定に従って固定長のパケットＰａ（応答パケット）を警報器１００に送信する。単なる応答用のパケットＰａは、準拠する通信規格に従って、警報器１００を示す宛先を含むヘッダＨ２と、パケットＰａの固定長を満たすペイロードＰ２とで構成される。単なる応答用のパケットＰａの場合、ペイロードＰ２には、例えば“０”のみ又は“１”のみのヌル（無効）データが格納される。そこで、本実施形態の警報器１００において、ソフトウェアＳＷのアップデートが予定されている場合には、このペイロードＰ２に更新データが格納されて警報器１００に送信される。このように通常の応答パケットでは有効活用されていないデータ格納領域を利用することで、更新データのためだけのデータ送信を行う場合と比べて、効率良く更新データを警報器１００に供給することができる。

【0053】

警報器１００は、定期通信において、警報器１００へのデータの伝送単位に含まれる符号に基づいて、分割された更新データの全てを受け取ったことを認識するように構成されていてもよい。その場合、パケットＰａのペイロードＰ２に格納された分割された更新データが全ての更新データのうちのいずれの更新データに該当するかを示す識別ビットＨ２０がパケットＰａの一部に格納された状態で、外部機器Ｅから応答用のパケットＰａが送信されてもよい。そうすることで、警報器１００が更新データの全てを受け取ると、自律的にソフトウェアＳＷのアップデートを開始することができる。なお、図３の例では、識別ビットＨ２は、パケットＰａのヘッダＨ２に格納されているが、パケットＰａのペイロードＰ２に格納されていてもよい。

【0054】

識別ビットＨ２０の形態として、例えば、更新データの分割数がｍである場合、外部機器Ｅから最初に送信される分割された更新データから昇順（１からｍまでの順）に番号を付し、付された番号にそれぞれ対応する数値データを識別ビットＨ２０に格納した状態で、応答用のパケットＰａが送信されることが例示される。その場合、外部機器Ｅは、更新データの送信前又は送信中に、更新データの分割数がいくつであるかを示す数値データが警報器１００に送信されてもよい。そうすることで、警報器１００は、更新データの全てを受け取る前に、受信すべき更新データがいくつであるかを認識するので、更新データの全てを受け取ると、自律的にソフトウェアＳＷのアップデートを遅滞なく開始することができる。なお、外部機器Ｅから最後に送信される分割された更新データにのみ、識別ビットＨ２０として所定のデータ（例えば、「１」）を格納し、その他の分割された更新データには、所定のデータを格納していない状態（例えば、「０」）で、応答用のパケットＰａが送信されてもよい。

【0055】

なお、警報器１００において、前述したように警報の発報が外部機器Ｅに通知される場合、その通知に対する応答信号にアップデート用の更新データが含められてもよい。この場合も、更新データのためだけのデータ送信を行う場合と比べて、効率良く更新データを警報器１００に供給することができる。

【0056】

また、警報器１００は、分割して受け取る更新データを、アップデートの実行まで、警報器１００内の記憶手段１１（図１参照）などの記憶領域に保管してもよい。その場合、図２に示されるように、アップデート前のソフトウェアＳＷが格納されている領域（例えば第１記憶領域Ａ１）と異なる領域（例えば第２記憶領域Ａ２）に、順次受け取る更新データが格納されてもよい。そうすることで、警報器１００は、アップデート前のソフトウェアＳＷに従って動作しながら、すなわち報知機能を停止させることなく、随時送られてくる更新データを受け取ることができる。

【0057】

＜アップデートの処理フロー＞
図４を参照して、本実施形態の警報器における通信部に関するソフトウェアのアップデートに関する処理が説明される。図４には、一例として、図１の警報器１００における、ソフトウェアＳＷのアップデートを含む動作を示すフローチャートが示されている。なお、図４では、更新データが全て受け取られると、警報発報中でなければアップデートが実行され、警報発報中である場合には、警報が発報されなくなるまでアップデートは実行されないが例示されるが、処理フローはこれに限定されない。

【0058】

図４のステップＳ１において、周囲環境の監視が開始されると、計時手段２１（図１参照）を構成するカウンタなどがリセットされ（ステップＳ２）、時間のカウントが開始される。そして、所定の時間が経過していない場合（ステップＳ３で“Ｎ”）は、ループＬ１で所定の時間が経過するまで、計時手段２１の時間がカウントアップされる（ステップＳ４）。所定の時間が経過すると（ステップＳ３で“Ｙ”）、定期通信として警報器１００の状態が外部機器Ｅ（図１参照）に送信され（ステップＳ３１）、計時手段２１のカウント値がリセットされる（ステップＳ３２）。

【0059】

その後、定期通信における外部機器Ｅからの応答信号が受信され（ステップＳ３３）、ソフトウェアＳＷのアップデート用の更新データのうち、応答信号に含まれる分割された更新データが取得される（ステップＳ３４）。例えば、取得された分割された更新データは、記憶領域４の第２記憶領域Ａ２（図２）に格納される。そして、更新データが全て受け取られていない場合は（ステップＳ５で“Ｎ”）、ループＬ２で更新データを全て受け取るまで、一連のステップＳ３、Ｓ３１～Ｓ３４が繰り返される。

【0060】

更新データが全て受け取られると（ステップＳ５で“Ｙ”）、警報発報中でなければ（ステップＳ６で“Ｙ”）、アップデートが実行される（ステップＳ７）。一方、警報発報中である場合には（ステップＳ６で“Ｎ”）、警報が発報されなくなるまで、アップデートは実行されない（ループＬ３）。そうすることで、異常発生において、アップデートの実行により警報が発報されない事態が回避される。アップデートの実行（ステップＳ７）が完了した後に、アップデートが完了したことが外部機器Ｅに通知され（ステップＳ８）、ループＬ４で制御がステップＳ３に戻される。

【0061】

周囲環境の監視中に、異常状態Ａｂが発生すると、警報器１００（図１参照）において警報が発せられる（ステップＳ２１）とともに、外部機器Ｅに警報発報中であることが通知される（ステップＳ２２）。前述したように、警報器１００からの警報の発報を報せる通知に対して、外部機器Ｅは、通知に対する応答信号の空き領域に分割された更新データを格納して警報器に送信してもよい。そうすることで、外部機器Ｅからの通知に対する応答信号の受信（ステップＳ３３）によって、分割された更新データが取得される（ステップＳ３４）。その場合、所定の時間が経過したときの定期信号の応答信号による更新データの取得と同様に、更新データが全て受け取られているか否かが判断され（ステップＳ５）、更新データが全て受け取られた場合（ステップＳ５で“Ｙ”）には、警報が発報されなくなった後（ループＬ３）、アップデートが実行される（ステップＳ７）。

【0062】

＜アップデートの要求態様＞
図４の例において、ソフトウェアＳＷのアップデートは、複数の応答信号に分割して送られるソフトウェアＳＷのアップデート用の更新データの全てを受け取ったことをもって自律的に行われている。しかし、本実施形態の警報器１００において、ソフトウェアＳＷのアップデートの要求には、任意の方法が適用され得る。図５には、アップデートの要求の他の幾つかの例として、家屋の室内に設置された警報器１００へのアップデートの要求方法が模式的に示されている。アップデートの要求は、例えば、被操作部５に触れるような直接的な所定の操作Ｍ１によって行われてもよい。また、警報器１００の付属リモコンのような専用端末や、アプリケーションプログラムによって専用端末化されたスマートフォンなどの各種の汎用携帯端末から近距離通信によってアップデートが要求されてもよい（以下では、専用端末と専用端末化された汎用携帯端末は「専用端末類」と総称され、図５には符号「Ｐｎ」を添えて示されている）。また、外部機器Ｅや、遠方のスマートフォンなどの端末Ｐｒから、ネットワークＮや通信事業者の基地局Ｂを介して送られる信号によってアップデートが要求されてもよい。

【0063】

しかし、警報器１００に用意されたアップデートの要求方法の全てが有効であることが、必ずしも好ましくない場合もある。例えば、アップデートの要求者が警報器１００の周囲環境を把握可能な状況にいると考えられる要求方法による要求は受け付けられるが、それ以外の要求方法による要求は受け付けられない方が好ましいこともある。例えば、警報が発報されるほどの状況ではないが、その状況に近付いている状況にあるにも拘わらず、その状況を認識し得ない要求者からのアップデートの要求を受け入れるのは、適正な警報発報の妨げになる場合もあるからである。

【0064】

そのため、アップデートの要求方法が、要求されるアップデートの種類ごとに、予め特定の方法に決められていてもよい。例えば、アップデートの「種類」のうち「第１種」のアップデートの要求は多くの方法（例えば用意された要求方法の全て）で可能である一方、「第１種」以外の「第２種」のアップデートは、警報器１００に実際に受け付けられる要求方法が制限されてもよい。例えば、第２種のアップデートの要求は、被操作部５に触れるような直接的な所定の操作Ｍ１や、警報器１００の近傍の専用端末類Ｐｎからの近距離通信による要求などに制限されてもよい。すなわちその場合には、外部機器Ｅや遠方の端末Ｐｒからの、ネットワークＮや基地局Ｂなどを経由した信号によるアップデートの要求は受け付けられない。一方、第１種のアップデートについては、第２種のアップデートの要求が受け付けられる方法に加えて、警報器１００の自律的なアップデートや、外部機器Ｅや遠方の端末Ｐｒからの、ネットワークＮや基地局Ｂなどを経由した信号によるものでも受け付けられてもよい。或いは、第１種のアップデートは、警報器１００の自律的なアップロードや、外部機器Ｅや遠方の端末Ｐｒからの信号による要求に限定され、被操作部５に触れるような直接的な所定の操作Ｍ１や、警報器１００の近傍の専用端末類Ｐｎからの近距離通信による要求が受け付けられなくてもよい。

【0065】

このように、要求されるアップデートの種類に応じて、警報器１００に対して行われる所定の指示操作に基づいてアップデートを実行するか、外部機器Ｅからの信号の受信に基づいてアップデートを実行するように構成されていてもよい。そのようにアップデートの種類に応じて、警報器１００が受け付ける要求方法を区別することによって、例えば、必要性の高いアップデートの適宜の実行を担保しつつ、アップデートによる警報器１００の警報発報機能の低下リスクを軽減し得ることがある。また、アップデートの要求元として適した要求元からのアップデートの要求に絞って、要求されたアップデートを実行することができる。

【0066】

上記の「警報器１００に対して行われる所定の指示操作」は、前述した被操作部５に触れるような直接的な所定の操作Ｍ１や、警報器１００の近傍の専用端末類Ｐｎへのアップデートを指示する操作であり得る。操作Ｍ１は、アップデートを要求すべく被操作部５に対して直接行われる手動操作、すなわち前述した「第１操作」以外の操作であり得る。

【0067】

専用端末類Ｐｎへの操作による指示は、前述したように、例えば近距離通信によって警報器１００に伝えられる。この近距離通信としては、Ｂｌｕｅｔｏｏｔｈ（登録商標）、Ｗｉ－Ｆｉ（登録商標）、又はＺｉｇＢｅｅ（登録商標）などの近距離無線通信、及び、ＩｒＤＡなどの光無線通信、さらに、ＬｏＲａＷＡＮ（登録商標）などのネットワークプロトコルを用いた警報器１００の近傍からの通信が例示されるが、専用端末類Ｐｎが用いる近距離通信はこれらに限定されない。しかし、「警報器に対して行われる所定の指示操作」に基づくアップデートの要求信号は、アップデートの要求者に直接手動操作される専用端末類Ｐｎのような被操作主体から警報器１００に直接伝わる信号に限られる。すなわち、「所定の指示操作」には、警報器１００に直接伝わらないアップデートの要求信号の送信を被操作主体に指示する操作は含まれない。従って、ネットワークＮ及び／又は基地局Ｂを介して警報器１００に伝わるようなアップデートの要求信号の送信を端末Ｐｒや外部機器Ｅに指示する操作も「所定の指示操作」に含まれない。

【0068】

なお、警報器１００の「近傍」は、警報器１００から数ｍ以内の範囲、及び／又は、警報器１００が視認可能な範囲内であり得る。このような範囲内にいるアップデートの要求者は、警報器１００の周囲の状況の認識が可能と考えられるからである。近距離通信が警報器１００と専用端末類Ｐｎとの通信に用いられる場合は、警報器１００の「近傍」は、さらに、上記の例のような各種の近距離無線通信や光無線通信における警報器１００からの通信圏内である。

【0069】

ここで上記のアップデートの「種類」は、一例として、アップデートの重要性や緊急性の程度を意味し得る。例えば、重要性や緊急性の高いアップデートが第１種のアップデートに含まれ、「第１種」以外のアップデートが第２種のアップデートに含まれてもよい。

【0070】

また、アップデートの「種類」は、アップデートの対象となる警報器１００の機能によって区分されてもよい。例えば、警報器１００の報知機能に関するアップデート（又は制御部１０に関するアップデート）が第１種のアップデート及び第２種のアップデートの一方に含まれ、通信部２０に関するアップデート（第１アップデート）が、その他方に含まれてもよい。一例として、制御部１０に関するアップデートの要求は「警報器に対して行われる所定の指示操作」に基づいて実行されてもよい。報知機能を制御する制御部１０に関するアップデートの実行を、警報器１００の周囲環境を把握し得る警報器１００の近傍のユーザーによる要求に基づいて実行することができる。また、通信部２０に関するアップデート（第１アップデート）は「外部機器からの信号の受信」に基づいて実行されてもよい。外部機器Ｅにおいて、通信制御方式の変更があった場合において、その外部機器Ｅからの要求に基づいて、通信に関するアップデートを実行することができる。

【0071】

一例として「報知機能に関するアップデート」は、検知部１２（図１参照）による周囲環境の監視動作、特定の状態にあることを報知すべきか否かの判断、如何なる態様で報知を行うかの判断、及び、報知部１３（図１参照）による音や光などによる報知動作、などの制御に関するアップデートであり得る。より具体的には、幾つかの例として、検知部１２の動作時期や感度の変更、特定の状態と判断する閾値（警報発報基準）の変更、特定の状態と判断される監視結果と報知態様との対応付けの変更、報知機能に関するプログラムのバグの修正、消費電力を低減する新たな制御手順への変更、及び、報知手段である光の強度や音声の音量若しくは発話内容の変更、などが含まれる。さらに、制御部１０による検知部１２及び報知部１３の自主点検項目、及び／又は、検知部１２を構成する各センサについて適宜行われる補正のアルゴリズムの変更なども「報知機能に関するアップデート」に含まれる。

【0072】

「通信部２０に関するアップデート」は、通信部２０によって制御される通信に関わるアップデートである。より具体的には、幾つかの例として、外部機器Ｅとの通信に適用する通信規格の改定に伴う、セキュリティ確保に関する仕様の変更や、通信リンクの設定及び開放の手順の変更、変調方式の変更、誤り検出時の再送回数の変更、通信部２０において構築されたセキュリティスタックのバージョンアップや、定期通信の頻度の変更、通信に関するプログラムのバグの修正、などが含まれ得る。

【0073】

＜アップデートの制限＞
警報器１００は、前述した要求方法自体が受け容れ可能な要求方法であっても、要求されるアップデートを現に実行するか否かを、上記に例示されるようなアップデートの内容に基づいて判断するように構成されていてもよい。例えば、周囲環境が警報を発する状況に近付いている場合には、警報発報に至っても外部機器Ｅに通知されない状態となるアップデートを開始しないことが好ましいことがある。従って、例えば警報器１００が警報を発報すべき状態よりも異常度が低い状態に対応する閾値（予備閾値）をさらに有していてもよい。加えて、アップデートの具体的な内容ごとにアップデート実行の優先度が設定されてよい。そして、検知対象であるガスの濃度や温度などの検出値が予備閾値を超えると、例えば通信セキュリティの確保に関する仕様の変更や致命的なバグの修正といった優先度の高い内容のアップデートだけが実行されてもよい。その他のアップデートは、検知対象の検出値が予備閾値以下の場合に実行されてもよい。

【0074】

前述したように警報器１００は、電池の電力で稼働する電池式の警報器であってもよい。アップデートの実行中は、アップデートが実行されていない時より多くの電力が消費されることがある。そのため、本実施形態の警報器が電池式の警報器である場合、要求されるソフトウェアＳＷのアップデートを実行するか否かを、電池の残量に基づいて判断するように構成されていてもよい。例えば電池の残量が所定の閾値以下であると、警報器１００のユーザーや外部機器Ｅなどからアップデートの要求があってもアップデートは実行されない。そうすることで、アップデートによる電池残量のさらなる低下を防いで、警報器１００が電池の残量不足によって機能不全に陥ることを防ぐことができる。すなわち、周囲環境の監視から監視結果に基づく報知までの警報器１００の本質的機能が発揮される状態を、より長く維持させることができる。

【0075】

特に警報器には、前述したように検知部１２（図１参照）を構成する各種のセンサが備えられ、各種センサには固有の寿命を有するものが存在する。そのため、電池式の警報器は、センサの寿命が尽きるまでの間電池残量が維持されるように電気的に設計され、構造面や仕様面では電池の交換や再充電ができないように設計されることがある。従って、設計思想通りにセンサの寿命まで電池残量が維持されるように、ある程度電池残量が低下してからは、より多くの電力を警報器１００に消費させるアップデートの実行を控えることが好ましいことがある。

【0076】

なお、このように電池残量によってアップデートの実行が判断される場合、警報器１００には、好ましくは、電池残量計ＩＣなどと称される電子部品のような電池残量計測手段（図示せず）が備えられる。

【0077】

電池の残量に基づいてアップデートの実行を判断するように構成される場合、本実施形態の警報器１００は、さらに、前述したようなアップデートの内容にも応じて、要求されるアップデートを実行するか否かを判断するように構成されてもよい。この場合も、アップデートの具体的な内容ごとにアップデート実行の優先度が設定され得る。例えば、所定の閾値を超える電池残量が保持されている場合に、要求されるアップデートが、その内容の如何を問わず実行されるのではなく、例えば、通信セキュリティの確保に関する仕様の変更や致命的なバグの修正といった優先度の高い内容のアップデートだけが実行されてもよい。そして、その他のアップデートは、さらに多くの電池残量が保持されている場合に実行されてもよい。

【0078】

従って、実施形態の警報器１００は、アップデートを実行するか否かの判断基準となる複数の電池残量の閾値を有していてもよい。そして、アップデート要求時の電池残量と各閾値との大小関係及び現に要求されるアップデートの優先度に応じて、要求されるアップデートを実行するか否かが判断されてもよい。例えば、アップデート要求時の電池残量が特定の閾値の範囲内にある場合、一定以上の優先度を有するアップデートが実行され、優先度の低いアップデートが保留又は却下されてもよい。

【0079】

図６には、アップデートの優先度及び電池残量に応じたアップデートの実行の判断の一例が示されている。図６に示される表の各列（縦方向）には、電池残量ｅと三つの閾値Ｔ１～Ｔ３（Ｔ１＜Ｔ２＜Ｔ３）との大小関係が示されている。そして各行には、第１優先から第３優先（優先度高：第１優先＞第２優先＞第３優先：優先度低）それぞれを有するアップデートが実行されるか否かが「Ｙ」（実行）又は「Ｎ」（非実行）で示されている。例えば、電池残量ｅが、最も小さい閾値Ｔ１以下である場合は、電池の延命が優先されていずれのアップデートも実行されない。しかし、電池残量ｅが閾値Ｔ１よりも大きく閾値Ｔ２以下であれば第１優先アップデートが実行され、電池残量ｅが閾値Ｔ２よりも大きく閾値Ｔ３以下であると、さらに第２優先アップデートも実行される。そして、電池残量ｅが閾値Ｔ３よりも大きければ、全てのアップデートが実行される。なお、警報器１００は、特定の優先度のアップデートが実行されない場合、その特定の優先度より低い優先度のアップデート要求を付けないように構成されていてもよい。

【0080】

優先度の高いアップデートは、例えば、前述した、通信セキュリティの確保に関する仕様の変更や、報知機能や通信を高度に損なわせる致命的なバグの修正の他、警報発報基準の変更、セキュリティスタックのバージョンアップなどであり得る。電池寿命を延ばして、警報器１００をセンサの保証期間満了まで稼働させるという観点では、消費電力低減のためのアップデートも高い優先度を有し得る。一方、優先度の低いアップデートとしては、報知態様の変更、自主点検項目の変更や定期通信の頻度の変更などが例示される。しかし、如何なるアップデートが高い又は低い優先度を有するかは、警報器１００の設置環境や警報器１００の仕様などに応じて任意に決定され得る。

【0081】

＜一実施形態の警報器の他の例＞
図７には、一実施形態の警報器の他の例である警報器１０１の主要な構成要素がブロック図で示されている。警報器１０１は、制御部１０と通信部２０とが、図１の例の処理装置１のような処理装置を共有していない点で、図１に示される警報器１００と異なっている。図７において、図１の例の警報器１００の構成要素と同様の構成要素については、図１に付された符号と同じ符号が付されるか省略され、その構成要素に関する繰り返しとなる説明は省略される。

【0082】

警報器１０１では、制御部１０は第１処理装置１ａを含んでいる。第１処理装置１ａは、周囲環境を監視して監視結果に基づく報知を行う報知機能を制御する半導体装置によって構成されている。通信部２０は第２処理装置２ａを含んでいる。第２処理装置２ａは、警報器１０１と外部機器Ｅとの間の通信を制御する半導体装置によって構成されている。制御部１０と通信部２０とは、好ましくは互いに相手方との間で信号の送受が可能なように接続されている。警報器１０１において制御部１０は、周囲環境の異常の検知に応じて警報を発すると共に、警報発報中であることを通信部２０を介して外部機器Ｅに通知するように構成されている。従って、周囲環境が異常な状態にあることを警報器１０１の遠方にいるユーザーにも報せることができる。

【0083】

第１処理装置１ａ及び第２処理装置２ａは、マイコンやＡＳＩＣなどの半導体装置からなり、図１の例の処理装置１と同様に演算機能、比較機能、及び記憶機能などを有している。第１処理装置１ａは、周囲環境を監視する警報器１０１の報知機能を全体的に制御する。第２処理装置２ａは、送受信部２２で行われる外部機器Ｅとの交信に必要な動作を全体的に制御する。第２処理装置２ａは、特定の時間からの経過時間をカウントするカウンタなどで構成される計時手段２ｃを備えている。図６の例の通信部２０も、計時手段２ｃを用いて、図１の警報器１００について前述した「定期通信」を行う。定期通信のために経過時間をカウントする計時手段は第１処理装置１ａに備えられていてもよい。

【0084】

第１処理装置１ａは、記憶手段１ｂにソフトウェアＳＷ１を内蔵していてソフトウェアＳＷ１に含まれる命令に従って動作する。第２処理装置２ａは、第２処理装置２ａにソフトウェアＳＷ２を内蔵していてソフトウェアＳＷ２に含まれる命令に従って動作する。警報器１０１においても、ソフトウェアＳＷ１及びソフトウェアＳＷ２は、警報器１０１の使用開始後にアップデートが可能なように内蔵されており、図１の警報器１００について説明されたアップデートと同様の方法でアップデートされ得る。第１処理装置１ａ及び第２処理装置２ａを含む警報器１０１では、ソフトウェアＳＷ１のアップデートは、第２処理装置２ａが制御する通信機能に影響し難く、ソフトウェアＳＷ２のアップデートは、第１処理装置１ａが制御する報知機能に影響し難い。

【0085】

このように、制御部１０及び通信部２０それぞれがソフトウェアＳＷ１、ＳＷ２を第１処理装置１ａ、第２処理装置２ａそれぞれに内蔵しているので、ソフトウェアＳＷ１のアップデート時には、通信部２０は外部機器Ｅとの通信などが可能な状態を維持することができる。また、ソフトウェアＳＷ２のアップデート時には、制御部１０は報知機能を維持することができる。一方、ソフトウェアＳＷ２のアップデート中は、外部機器Ｅとの交信が不能になることがある。そのため、警報器１０１において制御部１０は、通信部２０に関するアップデート、すなわちソフトウェアＳＷ２のアップデートの実行中に周囲環境の異常を検知すると、警報発報についての外部機器Ｅへの通知は行なわずに警報を発するように構成されている。例えば警報器１０１の報知部１３を用いた警報が発せられる。

【0086】

従って、外部機器Ｅに警報の発報は知らされないものの、少なくとも警報器１０１の近傍のユーザーには、ソフトウェアＳＷ２のアップデート中であっても、異常状態の発生を報せることができる。換言すると、警報器１０１の近傍のユーザーまで、異常の発生が知らされない危険な状態に置くことなくソフトウェアＳＷ２のアップデートを適宜に行うことができる。

【0087】

また、警報器１０１は、このようにソフトウェアＳＷ２のアップデート中は警報発報中であることを外部機器Ｅに通知できないので、例えば制御部１０は、ソフトウェアＳＷ２のアップデートが始まる前に、警報発報の通知が不能になることを外部機器Ｅに通知するように構成されていてもよい。遠方のユーザーなどに、警報が発せられても通知されない状況にいることを了知させることができる。加えて、アップデートの終了後には、警報の発報が通知される通常の状況に復帰したことを報せるように制御部１０が構成されていてもよい。

【0088】

なお、ソフトウェアＳＷ１のアップデート時には、報知機能そのものが影響を受ける可能性がある。そのため、制御部１０は、ソフトウェアＳＷ１のアップデートの開始前に、周囲環境の監視から警報の発報までの一連の機能が停止状態となることを外部機器Ｅに通知し、その終了後には通常の報知機能が復旧したことを通知するように構成されていてもよい。

【0089】

或いは、警報器１０１では、警報器１０１の使用開始後のソフトウェアＳＷ１のアップデートができないように構成されていてもよい。すなわち、ソフトウェアＳＷ１のアップデートが、前述した「報知機能に関するアップデート」に該当し、ソフトウェアＳＷ２のアップデートが「通信機能に関するアップデート」に該当する。従って、警報器１０１では、ソフトウェアＳＷ２のアップデートが可能である一方、ソフトウェアＳＷ１のアップデートが不能なように構成されていてもよい。

【0090】

図８には、図７の例の警報器１０１における、ソフトウェアＳＷ１、ＳＷ２のアップデートを含む動作の一例を示すフローチャートが示されている。なお、図８に示される各ステップのうち、図４に示されるステップと同様の動作や処理を行うステップについては、図４と同じ符号（ステップＳ１～Ｓ５、Ｓ２１～Ｓ２２、Ｓ３１～Ｓ３４）が付され、繰り返しとなる説明は、適宜省略される。

【0091】

図７の例の警報器１０１では、図８に示されるように、更新データが全て受け取られた場合（ステップＳ５で“Ｙ”）に、アップデートが通信部２０に関するソフトウェアＳＷ２（図７参照）のアップデートであると、警報の発報が外部機器Ｅに知らされない状態となることが外部機器Ｅに通知される（ステップＳ７１）。また、アップデートが制御部１０に関するソフトウェアＳＷ１（図７参照）のアップデートであると、警報の発報自体ができない状態となることが、外部機器Ｅに通知される（ステップＳ７１）。その後、アップデートが開始され（ステップＳ７２）、異常状態Ａｂ０の発生がなければ、アップデートの終了（ステップＳ７３）後、アップデートが終了したことが外部機器Ｅに通知される（ステップＳ８）。

【0092】

一方、通信部２０に関するソフトウェアＳＷ２のアップデートの開始（ステップＳ７２）後に、異常状態Ａｂ０が発生すると、警報器１０１において警報が発せられる（ステップＳ２１０）。アップデート実行中は、警報発報だけが行われ、外部機器Ｅには、警報の発報が知らされない。

【0093】

また、警報器１０１において制御部１０は、通信部２０に関するアップデートの実行中に発する警報と、何のアップデートも実行していないときに発する警報の発報態様を異ならせるように構成されていてもよい。そうすることで、外部機器Ｅに警報発報が通知されていないことを、警報器１０１の近傍のユーザーに報せることができる。例えば、警報発報時に発するメッセージが、アップデート実行中と非実行中とで変えられてもよい。例えば、アップデート非実行中であるステップＳ２１で発せられる警報の態様（第１態様）は、「ガス漏れ（又は火事）です。外部の○〇に通知しています」などのメッセージであり得る。一方、アップデート実行中であるステップＳ２１０で発せられる警報の態様（第２態様）は、「ガス漏れ（又は火事）です。外部の○〇には通知されていないのでご注意ください」などのメッセージであり得る。そうすることで、警報器１００の近傍のユーザーなどに、外部に警報の発報が知らされていないことを、より明確に伝えることができる。さらに、制御部１０は、アップデート実行中と非実行中とで、発報した警報の停止に必要な操作を変えるように構成されていてもよい。こうすることでも、外部機器Ｅに警報発報が通知されていないことを、警報器１０１の近傍のユーザーに報せることができる。

【0094】

また、制御部１０は、警報の発報前に開始された通信部２０に関するソフトウェアＳＷ２のアップデートが警報発報中に終了すると、警報を発報中であることを外部機器Ｅに報せるように構成されていてもよい。さらに、制御部１０は、通信部２０に関するソフトウェアＳＷ２のアップデートの実行中に発した警報がそのアップデートの終了前に停止された場合、そのアップデートの終了後に、そのアップデート中に警報を発したことを外部機器Ｅに報せるように構成されていてもよい。

【0095】

また、制御部１０は、警報の発報中に、警報を停止させる所定の停止操作（例えば、被操作部５（図６参照）がタクタイルスイッチで構成されている場合、被操作部５への２秒以上５秒未満の押し込み操作）後に警報器に対して行われる所定の指示操作（例えば、押し込まれる時間が５秒以上の押し込み操作）による要求に基づいてアップデートが可能であってもよい。その場合、制御部１０は、所定の指示操作以外の方法で要求されるアップデートの実行を保留するように構成されていてもよい。

【0096】

＜一実施形態の警報器の変形例＞
図９には、一実施形態の警報器の変形例である警報器１０２の主要な構成要素がブロック図で示されている。図９において、図１の例の警報器１００の構成要素又は図６の例の警報器１０１の構成要素と同様の構成要素については、図１又は図７に付された符号と同じ符号が付されるか省略され、その構成要素に関する繰り返しとなる説明は省略される。警報器１０２は、処理装置１の内部が、制御部１０を担う部分（第１処理部１α）と通信部２０を担う部分（第２処理部１β）とに区分されている点で、図１に示される警報器１００と異なっている。

【0097】

警報器１０２の処理装置１では、図９に示される記憶手段１ｂ、記憶手段２ｂ、及び計時手段２ｃのように処理装置１を構成するＣＰＵやメモリなどの各ハードウェア資源が、報知機能を担う第１処理部１α及び通信機能を担う第２処理部１βのいずれかに割り当てられている。図９に示される記憶手段１ｂ、記憶手段２ｂ、及び計時手段２ｃは、それぞれ、図７の例の記憶手段１ｂ、記憶手段２ｂ、及び計時手段２ｃと同様の機能を有している。そして、図９の例において、記憶手段１ｂは、第１処理部１αに属し、記憶手段２ｂ及び計時手段２ｃは、第２処理部１βに属している。記憶手段１ｂには、報知機能に関する命令を含むソフトウェアＳＷ１が内蔵されており、記憶手段２ｂには、通信機能に関する命令を含むソフトウェアＳＷ２が内蔵されている。

【0098】

警報器１０２の処理装置１では、メモリなどの各ハードウェア資源単位で、第１処理部１α又は第２処理部１βに割り当てられるのではなく、ハードウェア資源それぞれの内部が、報知機能を担う部分と通信機能を担う部分とに仕切られていてもよい。例えば、各記憶手段の記憶領域が、ソフトウェアＳＷ１のような報知機能に関する情報を記憶する領域と、ソフトウェアＳＷ２のような通信機能に関する情報を記憶する領域とに仕切られていてもよい。また、各記憶手段内の各種のレジスタ領域が、報知機能に関わる情報の記憶領域と通信機能に関わる情報の記憶領域とに分けられていてもよい。また、処理装置１を構成する複数の入出力ポートが、報知機能を担うポートと通信機能を担うポートとに分けられていてもよい。

【0099】

なお、処理装置１は、さらに報知機能及び通信機能以外の機能を担っていてもよく、また、報知機能及び通信機能それぞれの機能がさらに細分化されていてもよい。すなわち処理装置１は、３つ以上の機能を有していてもよく、それぞれに割り当てられた機能を担う三つ以上の部分に区分されていてもよい。そして処理装置１内のメモリなどの各ハードウェア資源が、３つ以上の部分のいずれか１以上に割り当てられてもよく、各資源の内部が、３つ以上の機能のいずれか担う部分毎に仕切られていてもよい。

【0100】

さらに、警報器１０２において処理装置１は、ＣＰＵに複数のコアを有するマルチコアタイプのマイコンであってもよく、複数のコアの一つが報知機能に宛てがわれ、他の一つが通信機能に宛てがわれてもよい。そのようにして、処理装置１の内部が、制御部１０を担う部分と通信部２０を担う部分とに区分されていてもよい。なお、図５の例のような記憶領域４内の特定の記憶領域へのアップデート後のソフトウェアＳＷの書き込みや、アップデート後のソフトウェアＳＷへの切り替えは、一例において、警報器１００のハードウェアを管理するオペレーティングシステム（ＯＳ）によって制御される。その場合、ソフトウェアＳＷは、このＯＳ上で動作するアプリケーションプログラムであってもよい。そして、アップデート前のソフトウェアＳＷの実行中に、アップデート後のソフトウェアＳＷが記憶領域４内の空き領域に書き込まれ、ソフトウェアＳＷが実行されていない間に、アップデート後のソフトウェアＳＷに切り替えられてもよい。

【0101】

図９の警報器１０２は、このように、図１の警報器１００と同様に単一の処理装置１を備えているが、その内部が制御部１０を担う部分と通信部２０を担う部分とに区分されている。そのため、警報器１０２においても、図７の警報器１０１について述べたように、ソフトウェアＳＷ１のアップデートは通信機能に影響し難く、ソフトウェアＳＷ２のアップデートは報知機能に影響し難いと考えられる。しかも、制御部１０及び通信部２０のいずれも処理装置１で主に構成されているので、制御部１０と通信部２０とを跨ぐような処理が高速に行われると考えられる。

【0102】

＜一実施形態の警報システム＞
つぎに、本発明の一実施形態の警報システムについて説明する。図１０には、一実施形態の警報システムの一例である警報システム２００がブロック図で示されている。図１０に示されるように、警報システム２００は、警報器２１０と、警報器２１０との間で通信による情報交換を行う制御装置２２０と、を備えている。警報器２１０は、図１～図９を参照して説明された一実施形態の警報器（例えば警報器１００や警報器１０１）であり得る。制御装置２２０は、警報器２１０の動作を警報システム２００のユーザーの指示に従って、及び／又は制御装置２２０に内蔵された制御プログラムに従って、制御する。制御装置２２０は、さらに、警報器２１０での検知結果若しくは警報発報経過を収集して統計処理若しくは解析してもよい。制御装置２２０としては、警報器２１０を監視及び制御する上位装置として機能するサーバーのような情報処理装置が例示される。図１、図７、及び図９に示される外部機器Ｅのいずれかが警報システム２００の制御装置２２０であってもよい。制御装置２２０は、演算機能、比較機能、記憶機能などを有する処理装置２２１を含んでいる。処理装置２２１は、図１の警報器１００が含む処理装置１と同様に、例えば、マイコンやＡＳＩＣなどの半導体装置からなり、内蔵されたプログラムに従って動作し得る。

【0103】

警報システム２００において警報器２１０は、警報器２１０の使用開始後にアップデートが可能なソフトウェアを内蔵している。また、制御装置２２０との間で警報器２１０の情報について所定周期で定期通信Ｒｃを行うように構成されている。警報器２１０から制御装置２２０への定期通信Ｒｃ１は、例えば、前述のように、通常の監視の実行中、電池式の場合の電池残量若しくは電池切れ、故障中、及び、警報発報中などの警報器２１０の状態を含んでいる。また、制御装置２２０から警報器２１０への定期通信Ｒｃ２は、例えば、前述のように、定期通信Ｒｃ１の受領時に、定期通信Ｒｃ１への応答パケットから構成されている。そして、ソフトウェアのアップデートが予定されている場合には、警報器２１０から制御装置２２０への定期通信Ｒｃ２では、応答パケットに更新データが格納されている。

【0104】

なお、警報器２１０において、警報の発報が制御装置２２０に通知される場合、その通知に対する応答信号にアップデート用の更新データが含められてもよい。この場合も、更新データのためだけのデータ送信を行う場合と比べて、効率良く更新データを警報器２１０に供給することができる。

【0105】

警報システム２００において制御装置２２０は、更新データのボリュームに基づいて、ソフトウェアのアップデート用の更新データを定期通信Ｒｃ２で分割して送信するか、定期通信Ｒｃ２以外の通信（例えば、更新データ送信専用の通信）否かを判断してもよい。例えば、更新データのボリュームが所定量以上である場合には、定期通信Ｒｃ２以外（例えば、更新データ送信専用の通信）で更新データを送信し、更新データのボリュームが所定量未満である場合は、更新データの全てを定期通信Ｒｃ２で分割して送信してもよい。

【0106】

警報器２１０が電池式であって、警報器２１０が電池残量の情報を含む定期通信Ｒｃ１を制御装置２２０に送信する場合、制御装置２２０は、警報器２１０からの電池残量の情報に基づいて、ソフトウェアのアップデート用の更新データを警報器２１０に送信するか否かを判断してもよい。その場合、制御装置２２０は、警報器２１０の電池の残量が所定の閾値以下となると、更新データを警報器２１０に送信しなくてもよい。また、制御装置２２０は、前述のように、アップデート実行の優先度に基づいて、更新データを警報器２１０に定期通信Ｒｃ２で分割して送信するか否かを判断してもよい。その場合、制御装置２２０は、検知対象であるガスの濃度や温度などの検出値が予備閾値を超えると、例えば通信セキュリティの確保に関する仕様の変更や致命的なバグの修正といった優先度の高い内容のアップデートの更新データだけを定期通信Ｒｃ２で分割して送信してもよい。

【0107】

警報システム２００において制御装置２２０は、更新データのボリューム及び／又はアップデート実行の優先度に基づいて、更新データの一部を定期通信Ｒｃ２で分割して送信し、残りの更新データを定期通信Ｒｃ２以外の通信で送信してもよい。そうすることで、更新データのボリュームが所定量以上である場合に、定期通信Ｒｃ２及び定期通信Ｒｃ２以外の通信の併用によって、更新データが警報器２１０に迅速に送信されるとともに、警報器２１０が有する警報機能などの各機能の停止期間を少なくすることができる。また、優先度の高い内容のアップデートを迅速に実行することができる。

【0108】

なお、今回開示された実施形態は、すべての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は、上記した実施形態の説明ではなく特許請求の範囲によって示され、さらに特許請求の範囲と均等の意味及び範囲内でのすべての変更（変形例）が含まれる。

【0109】

また、上記実施形態では、説明の便宜上、実施形態の警報器の処理動作を処理フローに沿って順番に処理を行うフロー駆動型のフローチャートを用いて説明したが、本発明はこれに限られない。本発明では、警報器の処理動作を、イベント単位で処理を実行するイベント駆動型（イベントドリブン型）の処理により行ってもよい。この場合、完全なイベント駆動型で行ってもよいし、イベント駆動及びフロー駆動を組み合わせて行ってもよい。

【符号の説明】

【0110】

１００、１０１、１０２、２１０ 警報器
２００ 警報システム
１０ 制御部
１１ 記憶手段
２０ 通信部
２２０ 制御装置
３ 電源部
５ 被操作部
Ｅ 外部機器
Ｒｃ 定期通信
ＳＷ、ＳＷ１、ＳＷ２ ソフトウェア

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【手続補正書】

【提出日】2023-08-22

【手続補正1】

【補正対象書類名】特許請求の範囲

【補正対象項目名】全文

【補正方法】変更

【補正の内容】

【特許請求の範囲】

【請求項1】

周囲環境の監視結果に基づく報知、及び外部機器との交信を、内蔵するソフトウェアに含まれる命令に従って行う警報器であって、
前記警報器は、前記外部機器との間で前記警報器の状態を所定周期で前記外部機器に送る定期通信を行うように構成されており、
前記ソフトウェアは、前記警報器の使用開始後にアップデートが可能なように内蔵されており、
前記アップデートが、複数回の前記定期通信を通じて前記外部機器から分割して送られる前記アップデート用の更新データを用いて実行される、警報器。

【請求項2】

周囲環境の監視結果に基づく報知を、内蔵するソフトウェアに含まれる命令に従って行う警報器と、
前記警報器との間で通信による情報交換を行う制御装置と、
を含む警報システムであって、
前記警報器は、前記制御装置との間で前記警報器の状態を所定周期で前記制御装置に送る定期通信を行うように構成されており、
前記ソフトウェアは、前記警報器の使用開始後にアップデートが可能なように内蔵されており、
前記制御装置は、前記アップデート用の更新データを分割して複数回の前記定期通信を通じて前記警報器に送信し、
前記警報器は、分割して送られる前記更新データを用いて前記アップデートを実行するように構成されている、警報システム。

【請求項3】

前記警報器は、前記監視結果に基づく警報の発報時に前記外部機器に前記警報の発報を報せる通知を行うように構成されており、
前記アップデートが、さらに、前記通知に対する応答信号に含まれる分割された前記更新データを用いて実行される、請求項１記載の警報器。

【請求項4】

前記警報器は、前記監視結果に基づく警報の発報時に前記制御装置に前記警報の発報を報せる通知を行うように構成されており、
前記制御装置は、分割された前記更新データの少なくとも一部を、前記通知に対する応答信号の空き領域に格納して前記警報器に送信する、請求項２記載の警報システム。

【請求項5】

前記定期通信において前記警報器へのデータの伝送単位を構成する複数の領域のうちの前記更新データが送信されないときに無効データが格納される領域に格納されて送られる前記更新データを用いて前記アップデートが実行される、請求項１若しくは３記載の警報器、又は、請求項２若しくは４記載の警報システム。

【請求項6】

前記警報器は、前記監視結果に基づく警報の発報中には前記アップデートを実行しないように構成されている、請求項１若しくは３記載の警報器、又は、請求項２若しくは４記載の警報システム。

【請求項7】

前記警報器は、分割された前記更新データの全てを受け取ると、前記アップデートを開始するように構成されている、請求項１若しくは３記載の警報器、又は、請求項２若しくは４記載の警報システム。

【請求項8】

前記警報器は、前記定期通信において前記警報器へのデータの伝送単位に含まれる符号に基づいて、分割された前記更新データの全てを受け取ったことを認識するように構成されている、請求項１若しくは３記載の警報器、又は、請求項２若しくは４記載の警報システム。

【請求項9】

前記アップデートが、前記定期通信における前記警報器から前記外部機器への通信ごとに前記外部機器から返信される応答信号に含めて送られる前記更新データを用いて実行される、請求項１又は３記載の警報器。

【請求項10】

前記制御装置は、分割した前記更新データを、前記定期通信において前記警報器から前記制御装置への通信ごとに前記制御装置から返信する応答信号に含めて前記警報器に送信する、請求項２又は４記載の警報システム。