(57)【要約】【課題】  通信ネットワークを介して多数のＩｏＴ機器のファームウェアを更新するに際し、ファームウェア更新時の不具合の影響がすべてのＩｏＴ機器に一括して及んでしまうリスクを効果的に軽減できるファームウェア更新システムを提供する。【解決手段】  ファームウェアの更新処理を、複数のＩｏＴ機器を区分する複数のグループ間にて互いに異なるタイミングにて実行する。そして、ウェア更新処理に失敗したグループが発生した場合は、ファームウェア未更新の残余のグループに対するファームウェア更新処理の実行を制限する。つまり、複数（多数）のＩｏＴ機器に対するファームウェアの更新が一括して実施されるのではなく、グループごとに異なるタイミングにて逐次実行される。そして、更新ファイルに不具合が含まれている等の要因により、あるグループでファームウェアの更新に失敗した場合は、以降のグループに対してファームウェア更新処理の実行が制限される。【選択図】  図１
2020154634.tif 000002
【特許請求の範囲】
【請求項１】
複数のＩｏＴ機器のそれぞれに実装されているファームウェアを、通信ネットワークを介して新しいバージョンのファームウェアに更新するファームウェア更新処理を行なう更新処理部と、
前記ファームウェアの更新処理を前記更新処理部に対し、前記複数のＩｏＴ機器を区分する複数のグループ間にて互いに異なるタイミングにて実行させる更新制御部と、
複数の前記グループに対する前記ファームウェア更新処理を逐次実行する過程において、前記ファームウェア更新処理に失敗したグループが発生した場合に、前記更新制御部に対し、ファームウェア未更新の残余の前記グループに対する前記ファームウェア更新処理の実行を制限する指令を行なう更新制限指令部と、
を備えたことを特徴とするファームウェア更新システム。
【請求項２】
前記更新制御部は、１つの前記グループに属する前記ＩｏＴ機器に対する前記ファームウェア更新処理が完了していることを条件として、次のグループに対する前記ファームウェア更新処理を前記更新処理部に開始させるものである請求項１記載のファームウェア更新システム。
【請求項３】
前記ファームウェア更新処理の前記グループごとの開始時刻を示す実行スケジュールを設定するスケジュール設定部を備え、前記更新制御部は、前記実行スケジュールに従い各前記グループの前記ファームウェア更新処理を前記更新処理部に実行させるものである請求項１又は請求項２に記載のファームウェア更新システム。
【請求項４】
前記ファームウェア更新処理の実行にかかる複数の前記グループ間での優先順位を設定する優先順位設定部を備え、
前記スケジュール設定部は、前記優先順位が上位に設定されている前記グループの前記ファームウェア更新処理が、前記優先順位がそれよりも下位に設定されているグループよりも先に実行されるように前記実行スケジュールを設定するものである請求項３記載のファームウェア更新システム。
【請求項５】
機器属性の異なる前記ＩｏＴ機器が互いに異なる前記グループに所属するように、複数の前記ＩｏＴ機器に対する前記グループの区分設定を行なうグループ設定部を備える請求項１ないし請求項４のいずれか１項に記載のファームウェア更新システム。
【請求項６】
前記グループ設定部は、前記機器属性が同一の複数の前記ＩｏＴ機器が、各々２以上のＩｏＴ機器を含む複数のグループに区分されるように前記区分設定を行なう請求項５記載のファームウェア更新システム。
【請求項７】
前記グループ設定部は、機器属性が同一であって形式が互いに異なる前記ＩｏＴ機器が互いに異なる前記グループに所属するように、前記区分設定を行なうものである請求項６記載のファームウェア更新システム。
【請求項８】
前記更新制限指令部は前記更新制御部に対し、前記ファームウェア更新処理に失敗した前記グループが発生した場合に、前記ファームウェア未更新の残余の前記グループの少なくとも一部について、前記ファームウェア更新処理の実行を中止する指令を行なうものである請求項１ないし請求項７のいずれか１項に記載のファームウェア更新システム。
【請求項９】
複数の前記ＩｏＴ機器に対する前記ファームウェア更新処理の進捗率を、それらＩｏＴ機器を区分する前記グループを単位とした更新完了実績に基づいて算出する進捗率算出部を備え、
前記更新制限指令部は、前記ファームウェア更新処理に失敗した前記グループが発生した時点での前記進捗率に基づいて、残余の前記グループに対する前記ファームウェア更新処理の制限内容を決定するものである請求項１ないし請求項８のいずれか１項に記載のファームウェア更新システム。
【請求項１０】
複数のＩｏＴ機器のそれぞれに実装されているファームウェアを、通信ネットワークを介して新しいバージョンのファームウェアに更新するに際し、前記ファームウェアの更新処理を、前記複数のＩｏＴ機器を区分する複数のグループ間にて互いに異なるタイミングにて実行するとともに、複数の前記グループに対する前記ファームウェア更新処理を逐次実行する過程において、前記ファームウェアの更新処理に失敗したグループが発生した場合に、ファームウェア未更新の残余の前記グループに対する前記ファームウェア更新処理の実行を制限することを特徴とするファームウェア更新方法。
【請求項１１】
コンピュータを、
複数のＩｏＴ機器のそれぞれに実装されているファームウェアを、通信ネットワークを介して新しいバージョンのファームウェアに更新するファームウェア更新処理を行なう更新処理部と、
前記ファームウェアの更新処理を前記更新処理部に対し、前記複数のＩｏＴ機器を区分する複数のグループ間にて互いに異なるタイミングにて実行させる更新制御部と、
複数の前記グループに対する前記ファームウェア更新処理を逐次実行する過程において、前記ファームウェア更新処理に失敗したグループが発生した場合に、前記更新制御部に対し、ファームウェア未更新の残余の前記グループに対する前記ファームウェア更新処理の実行を制限する指令を行なう更新制限指令部と、
して機能させることを特徴とするコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明はファームウェア更新システム、ファームウェア更新方法及びコンピュータプログラムに関するものであり、特に多数のＩｏＴ機器に実装されているファームウェアを、通信ネットワークを介して更新するためのものに関する。
【背景技術】
【０００２】
インターネットなどの公共通信網との通信機能を実装した電子機器、いわゆるＩｏＴ機器が普及しつつある。そして、センサなどの各種検出装置をＩｏＴ機器に組み込み、これを各所に設置したり移動体に取り付けたりして、その検出装置が収集したデータを所定のサーバなどに送り、各種分析等を行う技術も提案されている（特許文献１、２）。該技術においてＩｏＴ機器には、その処理制御を司るためのファームウェアが実装されており、例えばそのファームウェアで定義される処理方法にしたがってデータ収集等が行われている。
【０００３】
ところで、ＩｏＴ機器に搭載されているファームウェアは、セキュリティ対応強化や機能追加などのために、新しいバージョンのものに更新することが随時行われている。例えば、ＩｏＴ機器をインターネットに接続した場合、ＩｏＴ機器に実装されたファームウェアに脆弱性があると、インターネットを経由してＩｏＴ機器が不正に遠隔操作されたりするリスクが存在する。このため、ファームウェアに脆弱性が見つかったＩｏＴ機機器に対しては、脆弱性を解消する対策を施した更新ファイルを配信し、これを用いて当該ファームウェアを更新することが行われている。ファームウェアの更新処理に関しては、例えば特許文献３に、広域放送システムを用いて多数のＩｏＴ機器に更新ファイルを一斉配信し、一括して更新処理を行なう方式が開示されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特許６３３６６８９号公報
【特許文献２】特許６２８６６０１号公報
【特許文献３】特開２０１８−４５４１１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかし、特許文献３の方式では、更新ファイルが多数のＩｏＴ機器に一斉配信され、ファームウェアの更新がそれらＩｏＴ機器において一括して実行されるため、配信された更新ファイルにバグやセキュリティーホールなどの不具合が存在していると、多数のＩｏＴ機器が一挙に作動不具合を起こしたり、セキュリティ脆弱性を呈したりして、システム全体が機能不全に陥ってしまう恐れがある。
【０００６】
本発明の課題は、通信ネットワークを介して多数のＩｏＴ機器のファームウェアを更新するに際し、ファームウェア更新時の不具合の影響がすべてのＩｏＴ機器に一括して及んでしまうリスクを効果的に軽減できるファームウェア更新システム、ファームウェア更新方法及びコンピュータプログラムを提供することになる。
【課題を解決するための手段】
【０００７】
上記の課題を解決するために、本発明のファームウェア更新システムは、複数のＩｏＴ機器のそれぞれに実装されているファームウェアを、通信ネットワークを介して新しいバージョンのファームウェアに更新するファームウェア更新処理を行なう更新処理部と、ファームウェアの更新処理を更新処理部に対し、複数のＩｏＴ機器を区分する複数のグループ間にて互いに異なるタイミングにて実行させる更新制御部と、複数のグループに対するファームウェア更新処理を逐次実行する過程において、ファームウェア更新処理に失敗したグループが発生した場合に、更新制御部に対し、ファームウェア未更新の残余のグループに対するファームウェア更新処理の実行を制限する指令を行なう更新制限指令部とを備えたことを特徴とする。
【０００８】
また、本発明のファームウェア更新方法は、複数のＩｏＴ機器のそれぞれに実装されているファームウェアを、通信ネットワークを介して新しいバージョンのファームウェアに更新するに際し、ファームウェアの更新処理を、複数のＩｏＴ機器を区分する複数のグループ間にて互いに異なるタイミングにて実行するとともに、複数のグループに対するファームウェア更新処理を逐次実行する過程において、ファームウェア更新処理に失敗したグループが発生した場合に、ファームウェア未更新の残余のグループに対するファームウェア更新処理の実行を制限することを特徴とする。
【０００９】
さらに、本発明のコンピュータプログラムは、コンピュータを、複数のＩｏＴ機器のそれぞれに実装されているファームウェアを、通信ネットワークを介して新しいバージョンのファームウェアに更新するファームウェア更新処理を行なう更新処理部と、ファームウェアの更新処理を更新処理部に対し、複数のＩｏＴ機器を区分する複数のグループ間にて互いに異なるタイミングにて実行させる更新制御部と、複数のグループに対するファームウェア更新処理を逐次実行する過程において、ファームウェア更新処理に失敗したグループが発生した場合に、更新制御部に対し、ファームウェア未更新の残余のグループに対するファームウェア更新処理の実行を制限する指令を行なう更新制限指令部として機能させることを特徴とする。
【発明の効果】
【００１０】
上記本発明においては、複数のＩｏＴ機器のそれぞれに実装されているファームウェアを、通信ネットワークを介して新しいバージョンのファームウェアに更新するに際し、ファームウェアの更新処理を、複数のＩｏＴ機器を区分する複数のグループ間にて互いに異なるタイミングにて実行する。そして、ウェア更新処理に失敗したグループが発生した場合は、ファームウェア未更新の残余のグループに対するファームウェア更新処理の実行を制限する。つまり、複数（多数）のＩｏＴ機器に対するファームウェアの更新が一括して実施されるのではなく、グループごとに異なるタイミングにて逐次実行される。そして、更新ファイルに不具合が含まれている等の要因により、あるグループでファームウェアの更新に失敗した場合は、以降のグループに対してファームウェア更新処理の実行が制限される。これにより、ファームウェア更新時の不具合の影響がすべてのＩｏＴ機器に一括して及んでしまうリスクを効果的に軽減できる。また、多数のＩｏＴ機器に対するファームウェア更新のための通信負荷を、ＩｏＴ機器のグループ分けにより時間軸上にて分散させることが可能となり、通信回線の輻輳等も生じにくい。
【図面の簡単な説明】
【００１１】
【図１】本発明のファームウェア更新システムの第一例を示すブロック図。
【図２】ＩｏＴ機器の構成例を示すブロック図。
【図３】プロキシサーバの構成例を示すブロック図。
【図４】対象動作部の第一例を示すブロック図。
【図５】対象動作部の第二例を示すブロック図。
【図６】対象動作部の第三例を示すブロック図。
【図７】対象動作部の第四例を示すブロック図。
【図８】更新ファイル記憶部の内容の一例を示す模式図。
【図９】グループテーブルの内容の一例を示す模式図。
【図１０】スケジュールテーブルの内容の一例を示す模式図。
【図１１】進捗管理テーブルの内容の一例を示す模式図。
【図１２】システムの全体処理の流れを示すフローチャート。
【図１３】ファームウェアの更新処理の詳細を示すフローチャート。
【図１４】ファームウェアの更新処理の変形例を示す部分フローチャート。
【図１５】グループテーブルの第一変形例を示す模式図。
【図１６】グループテーブルの第二変形例を示す模式図。
【図１７】グループテーブルの第三変形例を示す模式図。
【図１８】本発明のファームウェア更新システムの第二例を示すブロック図。
【発明を実施するための形態】
【００１２】
以下、本発明を実施するための形態を添付の図面を用いて説明する。
図１は本発明のファームウェア更新システムにかかる一実施例を示すブロック図である。該ファームウェア更新システム１においては、複数のＩｏＴ機器１０ａ１、・・・、１０ｘｎが、ＬＡＮ（Local Area Network）７及びインターネット４を含む通信ネットワークを介してファームウェア配信サーバ（以下、ＦＷ配信サーバという）３に接続されている。ＦＷ配信サーバ３は、各ＩｏＴ機器１０ａ１・・・１０ｘｎに実装されるファームウェアの更新ファイルの配信元として機能するものであり、ファームウェアの種類に応じて複数のものがインターネット４上に設けられている。
【００１３】
ＬＡＮ７はインターネットルータ５及びハブ６を介してインターネット４に接続されており、複数のＩｏＴ機器１０ａ１・・・１０ｘｎは、複数のグループ１０Ｇ１・・・１０Ｇｍに区分された形でＬＡＮ７に接続されている。各グループ１０Ｇ１・・・１０Ｇｍは各々複数のＩｏＴ機器１０ａ１・・・１０ｘ１、１０ａ２・・・１０ｘ２、・・・、１０ａｎ・・・１０ｘを含む。
【００１４】
図２は、ＩｏＴ機器１０ａ１・・・１０ｘｎ（以下、符号１０により代表させる）の電気的構造を示すブロック図である。ＩｏＴ機器１０は制御用のマイコン５０を備える。制御用マイコン５０は、ＣＰＵ５１、ＲＡＭ５２、フラッシュＲＯＭ５４、ＲＯＭ５３、入出力部５５、ＬＡＮカード５７、及びそれらを相互に接続するバス（データバス＋アドレスバス）５６を備える。入出力部５５にはＩｏＴ機器の機能動作部３００が動作制御部３００ａを介して接続されている。ＩｏＴ機器１０はＬＡＮカード５７（ＬＡＮ接続インターフェース）を介して図１のＬＡＮ７に接続されることとなる。なお、ＩｏＴ機器１０はＬＡＮ７に対して無線接続可能な機器として構成してもよい。
【００１５】
フラッシュＲＯＭ５４には、機能動作部３００と動作制御部３００ａとが協働して実現する、ＩｏＴ機器１０の基本動作の制御処理を司るファームウェア５４ｂが格納されている。ＣＰＵ５１は、ＲＡＭ５２をワークエリアとして該ファームウェア５４ｂを実行する。また、ＲＯＭ５３には、ファームウェア５４ｂを更新する処理を担う更新実行プログラム５３ａが格納されている。該更新実行プログラム５３ａは、ＣＰＵ５１による実行に伴い更新処理部の機能を実現するものである。
【００１６】
機能動作部３００及び動作制御部３００ａはＩｏＴ機器１０の機器属性（種類）毎に構成の異なるものが設けられ、ファームウェア５４ｂもこれに応じて内容の異なるものが実装される。本実施形態においてＩｏＴ機器１０は、公共エリアや建物内の人や物の存在ないし動きを検知し、その検知内容あるいは該検知内容の解析結果を出力する検知機器として構成されている。
【００１７】
図４は、機能動作部３００を光センサとして構成した例を示すものであり、検知プローブとなる光ビーム（可視光あるいは赤外線）を検知対象物に照射する投光部３１１Ａと、検知対象物からの反射光を検出する受光部３１１Ｂを有する。また、動作制御部３００ａは投光部３１１Ａからの光ビームの出力制御を司る制御回路３１１ａと、受光部３１１Ｂが出力するアナログ検知信号を増幅するアンプ３１１ｂ、アンプ３１１ｂの出力をデジタル化するＡ／Ｄ変換部３１１ｃを含む。ファームウェア５４ｂは、制御回路３１１ａへの光ビームの出力指令と、Ａ／Ｄ変換部３１１ｃからのデジタル化された検知出力を解析して、人や物体を検知しているか否かを判定し、その結果を出力する処理を行なうプログラムとして構成される。
【００１８】
図５は、機能動作部３００を赤外線人感センサとして構成した例を示すものであり、生体からの輻射赤外線を検知する赤外受光部３１４Ｂを有する。また、動作制御部３００ａは赤外受光部３１４Ｂが出力するアナログ検知信号を増幅するアンプ３１４ｂ、アンプ３１４ｂの出力をデジタル化するＡ／Ｄ変換部３１４ｃを含む。ファームウェア５４ｂは、Ａ／Ｄ変換部３１４ｃからのデジタル化された検知出力を解析するとともに、例えば体温近傍の赤外輻射情報に基づき露出した生体表面の有無を判定し、その結果を出力する処理等を行なうプログラムとして構成される。
【００１９】
図６は、機能動作部３００を超音波センサとして構成した例を示すものであり、検知プローブとなる超音波ビームを検知対象物に出射する超音波送信部３１２Ａと、検知対象物からの超音波ビームによる反射波を検出する超音波受信部３１２Ｂを有する。また、動作制御部３００ａは超音波送信部３１２Ａからの超音波ビームの出力制御を司る制御回路３１２ａ、超音波受信部３１２Ｂが受信するアナログ波形信号を増幅するアンプ３１２ｂ、アンプ３１２ｂの出力をデジタル化するＡ／Ｄ変換部３１２ｃを含む。ファームウェア５４ｂは、制御回路３１２ａへの超音波ビームの出力指令と、Ａ／Ｄ変換部３１２ｃからのデジタル化された受信波形を解析して、人や物体を検知しているか否かの判定や、さらには受信波形の周波数解析（例えばドップラーシフト解析）により、検知している人や物体の動き（速度）の特定を行ない、その結果を出力する処理等を行なうプログラムとして構成される。
【００２０】
図７は、機能動作部３００を、人や物品に付与されたＩＣタグ（ＲＦＩＤ）のリーダとして構成した例を示すものであり、ＲＦ励起波を送信する励起波送信部３１３Ａと、検知対象物からの応答波を受信する応答波受信部３１３Ｂを有する。また、動作制御部３００ａは励起波送信部３１３ＡからのＲＦ励起波の出力制御を司る送信制御回路３１３ａと、応答波受信部３１３Ｂが受信するＩＣタグからの受信波形信号を増幅するアンプ３１３ｂ、アンプ３１３ｂから出力される受信波形信号を復調してデジタルベースバンド信号を抽出する復調回路３１３ｃを含む。ファームウェア５４ｂは、送信制御回路３１３ａへのＲＦ励起波の出力指令と、抽出されたデジタルベースバンド信号を解析して、ＩＣタグに格納されている情報を読み取る処理等を行なうプログラムとして構成される。
【００２１】
ＩｏＴ機器としての上記４種類のセンサは、次のような固有の特質を有しており、ＩｏＴ機器の設置エリア内にて適宜組み合わせて設置される。
・光センサ：検知エリア内に被検知体が存在するか否かを、被検知体が物か人かを特に区別することなく判別するのに適している。外乱光がノイズとして作用しやすいという欠点がある。
・赤外線人感センサ：周囲よりも表面温度の高い被検知体の有無を判別でき、検知対象物が人か物かを区別して判別するのに適している。
・超音波センサ：外乱光の影響を受けずに被検知体の検出が可能である。また、ドップラーシフト検知により移動速度を特定することも可能であり、人や物の動線や移動先の予測なども含めた解析に貢献できる。
・ＩＣタグリーダ：ＩＣタグの格納情報を読み取ることができ、ＩＣタグが付与された人や物の特定情報（ＩＤ）を容易に取得できる。
なお、上記の機能動作部３００及び動作制御部３００ａはあくまで例示であって、これらに限定されるものではない。
【００２２】
図１に戻り、ＩｏＴ機器１０ａ１・・・１０ｘｎが接続されているＬＡＮ７には、ハブ６を介してプロキシサーバ２が接続されている。プロキシサーバ２は、これらＩｏＴ機器１０ａ１・・・１０ｘｎのファームウェアの更新処理の制御及び管理を行なう主体として機能する。
【００２３】
図３はプロキシサーバ２の構成例を示すブロック図である。プロキシサーバ２は制御用のマイコン６０を備える。マイコン６０は、ＣＰＵ６１、ＲＡＭ６２、ＲＯＭ６３、ハードディスクドライブ６４、入出力部６５、ＬＡＮカード６７、及びそれらを相互に接続するバス（データバス＋アドレスバス）６６を備える。入出力部６５には、キーボード６９あるいはマウス７０等の入力部が接続される。また、入出力部６５には、ビデオコントローラ６８ａを介してモニタ６８が接続されている。
【００２４】
ハードディスクドライブ６４には、本発明のファームウェア更新システムの基本的な機能を実現するための更新管理ソフトウェア６４ｂがインストールされている。更新管理ソフトウェア６４ｂは、具体的には、ファームウェアの更新処理を、複数のＩｏＴ機器１０ａ１・・・１０ｘｎを区分する複数のグループ１０Ｇ１，１０Ｇ２，・・・１０Ｇｎ間にて互いに異なるタイミングにて実行させる更新制御部と、複数のグループ１０Ｇ１，１０Ｇ２，・・・１０Ｇｎに対するファームウェア更新処理を逐次実行する過程において、ファームウェア更新処理に失敗したグループが発生した場合に、ファームウェア未更新の残余のグループに対するファームウェア更新処理の実行を制限する指令を行なう更新制限指令部としの機能を実現するためのものである。ＣＰＵ６１はＲＡＭ６２をワークエリアとして、これらソフトウェアの実行主体として機能する。
【００２５】
また、ハードディスクドライブ６４には、以下の各記憶部が形成されている。
・更新ファイル記憶部６４ｃ：図１において、インターネット４を介してＦＷ配信サーバ３からダウンロードしたファームウェアの更新ファイルを記憶する。具体的には、図８に示すように、各ＩｏＴ機器１０ａ１・・・１０ｘｎ（図１）に実装されるすべてのファームウェアを、更新配信のために収集・蓄積するものである。ＦＷ０００１，・・・，ＦＷ０００ｍはファームウェアの種別ごとに固有に付与されるファームウェアＩＤである。複数のＩｏＴ機器１０ａ１・・・１０ｘｎ間では、同一のファームウェアを使用するものもあり、それらについては重複を避けた形で更新ファイル記憶部６４ｃに収集されている。
【００２６】
・グループテーブル記憶部６４ｄ：個々のＩｏＴ機器がどのグループに所属するかを、使用するファームウェアについてのファームウェアＩＤ（ＦＷ０００１，・・・，ＦＷ０００ｍ）と対応付けたグループテーブルを記憶するものである。図９にその一例を示しており、該グループテーブル６４ｄｒは、個々のＩｏＴ機器を特定する機器アドレス（ＤＶ０１０１，ＤＶ０１０２、・・・）及びファームウェアＩＤに、所属するグループを特定する情報であるグループＩＤ（ＧＰ００１，ＧＰ００２，・・・）及び機器の属性（例えば、図４〜図７に示したセンサの種別）を特定するための情報である機器属性ＩＤが互いに対応付けられて記憶されている。
【００２７】
機器アドレスは、例えば接続ノードを特定するためのＩＰアドレスであるが、機器固有のＭＡＣアドレス等を用いてもよい）。グループテーブルの内容は、図３のプロキシサーバ２において更新管理ソフトウェア６４ｂの機能により、例えば図９のグループテーブル６４ｄｒの内容を図３のモニタ６８に表示しつつ、キーボード６９及びマウス７０を用いて入力・登録することが可能である。すなわち、上記グループテーブル６４ｄｒはグループ設定部の役割を果たしている。
【００２８】
図９のグループテーブル６４ｄｒにおいては、機器属性が同一（機器属性ＩＤ：ＤＣＦ０１）の複数のＩｏＴ機器が、各々２以上のＩｏＴ機器を含む複数のグループ（ＧＰ００１，ＧＰ００２，・・）に区分されるよう、グループの区分設定がなされている。これにより、同一属性のＩｏＴ機器が非常に多数設置されている場合に、これを適当な数のグループに区分することで、ファームウェアの更新失敗の影響が、該属性の全てのＩｏＴ機器に一括して伝搬してしまう不具合を軽減することができる。なお、図９は、機器属性だけでなく機器形式も同一（機器形式ＩＤ：ＳＰ０１０１）のＩｏＴ機器群が複数のグループに区分されている例を示している。また、図１６に示すように、機器属性が同一（機器属性ＩＤ：ＤＣＦ０１）であって機器形式の異なるＩｏＴ機器群（機器形式ＩＤ：ＳＰ０１０１，ＳＰ０１０２，・・・）を、互いに別のグループに属するように区分を定めることもできる。形式が同一のＩｏＴ機器は同一のバージョンのファームウェアを使用しており、同報配信の採用等により、更新処理のさらなる効率化を図ることが可能となる。また、異なる機器属性ＩＤのＩｏＴ機器に対しては異なるグループＩＤを付与することが望ましい（換言すれば、機器属性の異なるＩｏＴ機器を異なるグループに属するように区分する）。例えば、図４〜図７の属性の異なるセンサ（ＩｏＴ機器）は互いに異なるグループとなるように区分することができる。これにより、グループ別のファームウェア更新処理の実行に伴い、同一属性の機器のファームウェアの更新をまとめて行なうことができ、同じ属性のＩｏＴ機器にファームウェアの新旧のバージョンが混在してしまう不具合を軽減することができる。
【００２９】
・スケジュールテーブル記憶部６４ｅ：ファームウェア更新処理のグループごとの開始時刻を示す実行スケジュールをスケジュールテーブルとして記憶する。図１０はその一例を示すものであり、該スケジュールテーブル６４ｅｒは、更新優先順位（０１、０２、・・・：番号が小さいほど、更新の優先順位が高いことを示す）に対し、グループＩＤ及び更新開始時刻の設定値（日時０１，日時０２，・・）が対応付けて記憶されている。スケジュールテーブル６４ｅｒの内容は、図３のプロキシサーバ２において更新管理ソフトウェア６４ｂの機能により、例えば図９のグループテーブルの内容を図３のモニタ６８に表示しつつ、キーボード６９及びマウス７０を用いて入力・登録することが可能である。すなわち、ファームウェア更新処理のグループごとの開始時刻を示す実行スケジュールを設定するスケジュール設定部の機能が実現されている。これにより、グループごとのファームウェア更新処理の開始時刻を正確に制御することが可能となり、他のグループの更新処理との競合も効果的に回避できる。なお、図９のスケジュールテーブル６４ｅｒでは、グループＩＤ（ＧＰ００１，ＧＰ００２，・・）を更新優先順位（０１、０２、・・・）に対し番号順に配列するデフォルトの設定状態を示している。そして、スケジュールテーブルの内容を変更・登録することで、ＧＰ００３，ＧＰ００４，ＧＰ００１・・・等、グループ間での更新優先順位を任意に変更することが可能である。
【００３０】
また、ファームウェア更新処理の実行にかかる複数のグループ間での優先順位を設定する優先順位設定部の機能も同時に実現されている。具体的には、優先順位が上位に設定されているグループのファームウェア更新処理が、優先順位がそれよりも下位に設定されているグループよりも先に実行されるようにスケジュールが設定される。例えば使用頻度の高いＩｏＴ機器のグループなど、優先順位の高いＩｏＴ機器のファームウェアの更新処理をスケジュールの早期に組み込むことができ、該更新処理をいち早く完了させることができる。また、どのグループのＩｏＴ機器のファームウェアの更新を優先するかが状況により変化する場合は、更新優先順位に対するグループＩＤの対応関係は、随時入れ替えて設定できる利点もある。
【００３１】
進捗管理テーブル記憶部６４ｆ：各グループのＩｏＴ機器のファームウェア更新状況を示す情報をグループ別に示す進捗管理テーブルを記憶する。また、ファームウェア更新処理の進捗率を、それらＩｏＴ機器を区分するグループを単位とした更新完了実績に基づいて算出した値として記憶する。図１１はその一例を示すものであり、該進捗管理テーブル６４ｆｒは、前述のグループＩＤ、機器属性ＩＤ、ファームウェアＩＤ及び機器アドレスが互いに対応付けられるとともに、グループ内の機器アドレスごと（ＩｏＴ機器ごと）のファームウェア更新結果（正常／失敗）と、グループごとのファームウェア更新結果（正常／失敗）とが記録されている。なお、この進捗管理テーブルｆｒの内容は、図３のモニタ６８に、図１１と類似のフォーマットにて進捗率の値とともに表示出力することができ、ファームウェアの更新状況を目視により確認することができる。
【００３２】
以下、更新管理ソフトウェア６４ｂの処理の流れについて、図１２及び図１３のフローチャートを用いて説明する。まず、図１２のＳ１において、ファームウェアの更新ファイルの有無をＦＷ配信サーバ３（図１）に問い合わせる。具体的には、図９のグループテーブル６４ｄｒに含まれるファームウェアＩＤから使用するすべてのファームウェアの種別を特定し、対応するＦＷ配信サーバ３に更新ファイルがあるかどうかの問い合わせを行なう。もし更新ファイルがあればＳ２でこれをダウンロードし、更新ファイル記憶部６４ｃに蓄積する。Ｓ３では、さらにダウンロードするべき次のファームウェアの更新ファイルが存在するかを確認する。存在するようであればＳ１、Ｓ２の処理を繰り返す。また、Ｓ３で全ての更新ファイルのダウンロードが完了すればＳ４に進み、スケジュールテーブル６４ｅｒ（図１０）の作成とスケジュールテーブル記憶部６４ｅへの登録を行なう。
【００３３】
続くＳ５で更新処理を実行する。図１３は、その詳細を示すものである。Ｓ５０１でスケジュールテーブル６４ｅｒ（図１０）をスケジュールテーブル記憶部６４ｅから読み出す。Ｓ５０２では、更新優先順位番号ｉ（スケジュールテーブル６４ｅｒの左端列が示す番号）を初期化する。Ｓ５０３では、更新優先順位番号ｉの現在値に対応するグループＩＤをスケジュールテーブル６４ｅｒ上で特定する。これにより、ファームウェア更新を行なうべきＩｏＴ機器のグループが決定される。
【００３４】
続いて、Ｓ５０４では、決定されたグループに属するＩｏＴ機器のファームウェア更新のための順位番号ｊを初期化する（この順位番号は、例えば図９のグループテーブル６４ｄｒにおいて、該当するグループ内の機器アドレスの配列順に振られているものとする）。Ｓ５０５では、順位番号ｊのＩｏＴ機器のファームウェアＩＤを特定し、これに対応する更新ファイルを更新ファイル記憶部６４ｃ（図８）から読み出す。
【００３５】
次に、Ｓ５０６では、順位番号ｊのＩｏＴ機器の機器アドレスを特定し、Ｓ５０７で当該機器アドレスを有するＩｏＴ機器に対し、ＬＡＮ７（図１）を経由した通信により、ファームウェア更新開始を通知する。ＩｏＴ機器側では、この通知を受け、更新ファイルの送信要求を応答として返す。ただし、ＩｏＴ機器側の不調や通信不具合により応答が返らないこともある。Ｓ５０８では該応答の有無を確認し、応答がなかった場合はＳ５０９を経てＳ５０７に戻り、更新開始通知のリトライを行なう。そして、Ｓ５０９にてリトライ回数が満了しても応答がない場合はＳ５１４に進み、グループ内の個別のＩｏＴ機器のファームウェア更新は「失敗」と判定し、該内容を進捗管理テーブル（図１１）の対応するグループ及び機器アドレスの結果記憶エリアに書き込む。
【００３６】
一方、Ｓ５０８で応答があった場合はＳ５１０に進み、更新ファイルを特定されている機器アドレスをあて先として送信する。ＩｏＴ機器側では更新ファイルを受け取り、ファイル全体が受信でき、かつ、プロキシサーバ２との間でのベリファイ処理により正常に更新ファイルを受信できたことが確認できれば「正常」の応答を返す。ＩｏＴ機器側では、その後更新ファイルをインストールし、実装されているファームウェアを更新する。他方、途中で通信が途絶してファイル全体が受信できなかった場合や、プロキシサーバ２との間でのベリファイ処理にて異常が発見された場合は、「失敗」の応答が返される。
【００３７】
なお、ＩｏＴ機器側にて更新後のファームウェアの動作確認まで行い、正常に動作できたことを確認した後、「正常完了」の応答をプロキシサーバ２側に返すようにしてもよい。この場合、ＩｏＴ機器側では更新ファイルをインストール後、正常に動作したことが確認できれば「正常」の応答を返す。他方、正常動作が確認できなかった場合は、「失敗」の応答が返される。また、更新前のファームウェアは、例えば図２のフラッシュＲＯＭ５４内のバックアップ記憶部５４ｃにバックアップしておくことができる。これにより、ファームウェアの更新に失敗した場合に、更新前のファームウェアにてＩｏＴ機器の動作を継続させることが可能である。
【００３８】
Ｓ５１１では、ＩｏＴ機器側から「正常」の応答があったか否かを確認する。このとき、応答がなかったり、「失敗」が応答されていたりした場合はＳ５１３を経てＳ５０７に戻り、以下の処理を繰り返す形でリトライを行なう。そして、Ｓ５１３にてリトライ回数が満了しても「正常」応答がない場合はＳ５１４に進み、グループ内の個別のＩｏＴ機器のファームウェア更新は「失敗」と判定し、該内容を進捗管理テーブル（図１１）の対応するグループ及び機器アドレスの結果記憶エリアに書き込む。一方、Ｓ５１１で「正常」の応答があった場合はＳ５１２に進み、グループ内の当該のＩｏＴ機器のファームウェア更新を「正常」と判定し、該内容を進捗管理テーブル（図１１）の対応する機器アドレスの結果記憶エリアに書き込む。
【００３９】
以上の処理が終了するとＳ５１５に進み、決定されたグループに属するＩｏＴ機器のファームウェア更新のための順位番号ｊをインクリメントし、Ｓ５１６にて順位番号ｊがグループ内のＩｏＴ機器の総数ｍを上回るまで、Ｓ５０５〜Ｓ５１４の処理を、インクリメント後のｊに対応するＩｏＴ機器に対して繰り返す。そして、Ｓ５１６にてｊ＞ｍとなっていれば、当該グループのＩｏＴ機器のファームウェア更新処理は終わったと判断し、Ｓ５１７に進む。ここでは、グループとしてのファームウェア更新処理が「正常」であるか否かの判定を行なう。
【００４０】
ここでは、グループ内の複数のＩｏＴ機器のファームウェア更新が全て「正常」であった場合にのみグループについての結果も「正常」と判定し（Ｓ５１８）、１つでも「失敗」であれば、グループ全体としてのファームウェア更新結果は「失敗」と判定する（Ｓ５２１）。なお、ファームウェアが「失敗」となるグループ内のＩｏＴ機器数が予め定められた数に達するまではグループ全体としてのファームウェア更新結果を「正常」と判定し、該数を超えた場合は「失敗」と判定することもできる。あるいは、グループ内のすべてのＩｏＴ機器のファームウェア更新が全て「失敗」であった場合にのみ、グループ全体としてのファームウェア更新結果を「失敗」と判定することもできる。これらのいずれを採用するかは、ＩｏＴ機器の種別や使用目的に応じて適宜選択することができる。
【００４１】
Ｓ５１８で、グループのファームウェア更新結果が「正常」であればＳ５１９に進み、更新の進捗率を計算する。具体的には、複数のＩｏＴ機器に対するファームウェア更新処理の進捗率を、それらＩｏＴ機器を区分するグループを単位とした更新完了実績に基づいて算出する。該進捗率は、例えば進捗管理テーブル６４ｆｒ上にて、ファームウェア更新対象のＩｏＴ機器の総数Σと、更新が「正常」に完了しているグループのＩｏＴ機器の数σとを特定し、進捗率ＡＲを、
ＡＲ＝σ／Σ×１００（％）
により計算することができる。なお、予め定められた数のＩｏＴ機器が「失敗」となることが許される場合は、「正常」に完了しているグループについて「失敗」となるＩｏＴ機器の数を進捗率に組み入れてもよいし、これらを省いて進捗率を計算することもでき、ＩｏＴ機器の種別や使用目的に応じて適宜選択することができる。また、より単純に、ファームウェア更新対象のグループの数をＵ、更新が「正常」に完了しているグループの数をｕとして、進捗率ＡＲを、
ＡＲ＝ｕ／Ｕ×１００（％）
により計算してもよい。計算された進捗率は進捗管理テーブルｆｒ上（図１１）に反映され、その内容を図３のモニタ６８上で確認することができる。
【００４２】
続いて、Ｓ５２０では更新優先順位番号ｉがインクリメントされ、Ｓ５２４でｊがグループの総数ｎを上回るまで以降のグループに対し、Ｓ５０３からＳ５２２までの処理が同様に実施される。すなわち、１つのグループに対するファームウェア更新処理が完了していることを条件として、次のグループに対するファームウェア更新処理が開始されるようになっている。これにより、先のグループのファームウェア更新が確実に「正常」であることが確定されたのち、次のグループのファームウェア更新に移行でき、より安全なファームウェア更新の継続が可能となる。Ｓ５２４でｊがグループの総数ｎを上回れば更新処理を完了する。
【００４３】
他方、先のグループの一部のＩｏＴ機器群の更新処理が未完了の状態で、次のグループの更新処理を開始することも可能であり、例えば先のグループの末尾のＩｏＴ機器列の更新処理と、後続のＩｏＴ機器列の更新処理とが並列に実施されるように制御を行なってもよい。具体例としては、前述のごとく、「失敗」となるグループ内のＩｏＴ機器数が予め定められた数まで許される方式が採用される場合において、グループ内の未更新のＩｏＴ機器の残数が、それらが全て「失敗」となった場合でも「正常」判定の条件内に収まっている場合に、次のグループの更新処理に移行させる事例を挙げることができる。
【００４４】
一方、Ｓ５１７で、グループとしてのファームウェア更新処理が「正常」となる条件を充足していない場合はＳ５２２に進み、グループの更新結果を「失敗」と判定し、進捗管理テーブル６４ｆｒ（図１１）にこれを反映する。そして、Ｓ５２３に進み、更新処理を直ちに中止して処理を終了する。これにより、ファームウェア更新時の不具合の影響が以降のグループのＩｏＴ機器に一括して及んでしまうリスクを効果的に軽減できる。特に、プロキシサーバへのウィルス侵入等、サイバー攻撃の影響が懸念される場合は、以降のグループのＩｏＴ機器の種別とは無関係に、更新処理を直ちに停止させることが得策といえる。
【００４５】
以上、本発明の実施形態について説明したがこれに限定されるものではなく、本発明の主旨を逸脱しない範囲内で、種々の変形を付加して実施することが可能である。以下、本発明の種々の変形例について説明する。まず、図１３の処理の流れでは、Ｓ５１７でグループとしてのファームウェア更新処理が「失敗」と判定された場合に、Ｓ５２２で以降の全てのグループへの更新処理の継続が直ちに中止されていたが、これを以下のように変更して実施することが可能である。
【００４６】
（１）ファームウェア更新処理に失敗したグループが発生した場合に、ファームウェア未更新の残余のグループの一部については、ファームウェア更新処理の実行を中止し、残余のものについては更新処理を継続させる。例えば、更新処理に「失敗」したグループの機器属性をグループテーブル６４ｄｒ上で確認し、以降、同じ機器属性のグループについての更新処理は中止し、異なる機器属性のグループについての更新処理は継続するように構成することが可能である。この方式は、例えば、ファームウェアの更新ファイル側のバグによる影響が懸念される場合に有効といえる。
【００４７】
（２）ファームウェア更新処理に失敗したグループが発生した時点での進捗率に基づいて、残余のグループに対するファームウェア更新処理の制限内容を決定する。一例を図１４のフローチャートを用いて説明する。具体的には、図１３のＳ５１７〜Ｓ５２４（一点鎖線で囲んだ部分）を、該図１４の流れに置き換えて実施する。その相違点は、図１４においてＳ５２１でグループの更新結果が「失敗」と判定されたのち、Ｓ５２１２で進捗率ＡＲを読みとり、Ｓ５２１３で該進捗率ＡＲが予め定められた基準値ＡＲ０（例えば４０％〜６０％に設定される）を超えていた場合は更新処理の中止を行なわず、Ｓ５１９に進んで以降のグループへの更新を継続することにある。つまり、ファームウェア更新処理がある程度までは正常に進んでいる点に鑑みれば、途中からこれが「失敗」に転ずることの主たる要因は、更新対象の特定のＩｏＴ機器の不調や通信トラブルに基づく偶発的なものである可能性が高く、かつ不具合の影響が更新継続により他のＩｏＴ機器に伝搬してしまうリスクも低いと考えられる。よって、このような場合には更新処理を継続するようにすることで、残余のグループの更新処理が一律に中止されてしまうことによる効率低下を防止することができる。この場合、更新処理は継続するが、処理結果自体は「失敗」として進捗管理テーブル６４ｆｅ（図１１）に反映させる。
【００４８】
次に、上記の実施形態では、グループごとの更新処理の「正常」「失敗」の結果判定が、予め定められた条件に従い自動的になされていたが、予め定められたタイミング、例えば１つのグループについての更新処理が完了したときや、あるいはＩｏＴ機器で「失敗」の更新結果が発生したときに、処理を一時的に停止し、以下の処理をオペレータの判断で決定するように構成することもできる。例えば、例えばオペレータが進捗管理テーブル６４ｆｅ（図１１）を参照したり、不具合が発生したＩｏＴ機器の点検等を行なったりしたのち、グループとしての「正常」「失敗」を人為的に判定し、キーボード６９ないしマウス７０（図３）からの入力により、「正常」「失敗」の結果入力を行なうようにする。そして、「正常」判定の場合はア予め定められた再開コマンドを手動入力により実行させ、更新処理を再開させるようにする。これにより、更新処理の現状をオペレータが監視しながら、よりきめ細かい更新制御を行なうことが可能となる。なお、この態様に限らず、進捗管理テーブル６４ｆｅにはＩｏＴ機器ごとの更新の「正常」完了あるいは「失敗」終了の時刻を記録することができ、さらに、「失敗」の場合は、「失敗」の種別を合わせて記録することができる。
【００４９】
また、図１５のグループテーブル６４ｄｅに示すように、同じ機器属性ＩＤのＩｏＴ機器が全て同一のグループに属するようにすること、つまり、機器属性の種別に一対一に対応するグループ区分を設定することも可能である。例えば、ダウンロード中のプログラムがウィルス等によるサイバー攻撃により改変された場合、配信元であるＦＷサーバ３（図１）のプログラムの状態と、改変を経てＩｏＴ機器が受信するプログラムは、配信後のベリファイ処理にてエラーとなる。その結果、ある機器属性グループでベリファイ失敗のリトライが続いた場合（例えばプログラムコードの総数チェックなどで、不自然にブロックが増えているなど）、次のグループのＩｏＴ機器の属性が異なっていても（つまり、ファームウェアの種別が異なっていても）、侵入したウィルス等により同様の不具合が継続する恐れがある。よって、この場合も、ある機器属性のグループでファームウェア更新に失敗したとき、次の機器属性のグループへのファームウェア更新を制限する（例えば、停止する）利点はあるといえる。
【００５０】
また、図１７のグループテーブル６４ｄｅに示すように、複数のＩｏＴ機器の設置エリアを複数に区分し（エリアＩＤ：ＡＲ０１，ＡＲ０２，・・）、各エリア内のＩｏＴ機器が同じグループに属するものとなるように、グループの区分を定める。該構成は、例えば、ファームウェア更新の優先順位がエリアによって相違する場合に有効であるといえる。この場合、図１７に示すように、同じエリア内に異なる属性のＩｏＴ機器が混在していてもよい。
【００５１】
次に、図１のシステム構成では、プロキシサーバ２がファームウェアの更新ファイルをダウンロードし、各ＩｏＴ機器１０ａ１、・・・、１０ｘｎにプロキシサーバ２から配信するようにしていたが、図１８に示すように、ＩｏＴ機器１０ａ１、・・・、１０ｘｎがセルラー通信基地局９を介して、ＦＷ配信サーバ３から更新ファイルを無線通信により個々に直接ダウンロードするように構成してもよい。この場合は、図２のプロキシサーバ２に代えて、ＩｏＴ機器１０ａ１、・・・、１０ｘｎに対する更新ファイルダウンロードの許可・不許可を指示する管理サーバ２’が設けられる。管理サーバ２’の処理を行なう場合、例えば図１２のＳ１〜Ｓ３の更新ファイルのダウンロードの処理ステップは不要となる。また、図１３の更新処理においては、Ｓ５１０の処理は、ＩｏＴ機器に向けた「更新ファイルの送信」ではなく、ＩｏＴ機器に対する「更新ファイルのダウンロード指示」となる。なお、図１７においては、ハブ６に無線ＬＡＮルータ８が接続されており、ＩｏＴ機器１０ａ１、・・・、１０ｘｎは該無線ＬＡＮルータ８に無線接続するようにしている。
【符号の説明】
【００５２】
１  ファームウェア更新システム
２  プロキシサーバ
３  ＦＷ配信サーバ
４  インターネット
５  インターネットルータ
６  ハブ
７  ＬＡＮ
８  無線ＬＡＮルータ
９  移動通信基地局
１０ａ１・・・１０ｘｎ  ＩｏＴ機器
１０Ｇ１・・・１０Ｇ  グループ
５０  マイコン
５１  ＣＰＵ
５２  ＲＡＭ
５３  ＲＯＭ
５３ａ  更新実行プログラム
５４  フラッシュＲＯＭ
５４ｂ  駆動制御ファームウェア
５４ｃ  バックアップ記憶部
３００  対象駆動部
３００ａ  駆動制御部
６０  マイコン
６１  ＣＰＵ
６２  ＲＡＭ
６３  ＲＯＭ
６４  ハードディスクドライブ
６４ａ  システムソフトウェア
６４ｂ  更新管理ソフトウェア
６４ｃ  更新ファイル記憶部
６４ｄ  グループテーブル記憶部
６４ｅ  スケジュールテーブル記憶部
６４ｆ  進捗管理テーブル記憶部
６７  ＬＡＮカード
６８  モニタ
６９  キーボード
７０  マウス
【図１】
2020154634.tif 000003
【図２】
2020154634.tif 000004
【図３】
2020154634.tif 000005
【図４】
2020154634.tif 000006
【図５】
2020154634.tif 000007
【図６】
2020154634.tif 000008
【図７】
2020154634.tif 000009
【図８】
2020154634.tif 000010
【図９】
2020154634.tif 000011
【図１０】
2020154634.tif 000012
【図１１】
2020154634.tif 000013
【図１２】
2020154634.tif 000014
【図１３】
2020154634.tif 000015
【図１４】
2020154634.tif 000016
【図１５】
2020154634.tif 000017
【図１６】
2020154634.tif 000018
【図１７】
2020154634.tif 000019
【図１８】
2020154634.tif 000020
【手続補正書】
【提出日】令和2年7月14日(2020.7.14)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
複数のＩｏＴ機器のそれぞれに実装されているファームウェアを、通信ネットワークを介して新しいバージョンのファームウェアに更新するファームウェア更新処理を行なう更新処理部と、
前記ファームウェアの更新処理を前記更新処理部に対し、前記複数のＩｏＴ機器を区分する複数のグループ間にて互いに異なるタイミングにて実行させる更新制御部と、
複数の前記グループに対する前記ファームウェア更新処理を逐次実行する過程において、前記ファームウェア更新処理に失敗したグループが発生した場合に、前記更新制御部に対し、ファームウェア未更新の残余の前記グループに対する前記ファームウェア更新処理の実行を制限する指令を行なう更新制限指令部と、
前記ＩｏＴ機器の種類を特定する情報である機器属性ＩＤが異なる前記ＩｏＴ機器が互いに異なる前記グループに所属するように、複数の前記ＩｏＴ機器に対する前記グループの区分が設定され、前記複数のＩｏＴ機器の各々が属するグループを特定するグループＩＤと前記機器属性ＩＤとが互いに対応付けられた情報であるグループテーブルを記憶するグループテーブル記憶部と、を備え、
前記更新制御部は、前記グループテーブルを用いて前記更新処理を実行する、ファームウェア更新システム。
【請求項２】
前記更新制御部は、１つの前記グループに属する前記ＩｏＴ機器に対する前記ファームウェア更新処理が完了していることを条件として、次のグループに対する前記ファームウェア更新処理を前記更新処理部に開始させるものである請求項１記載のファームウェア更新システム。
【請求項３】
前記ファームウェア更新処理の前記グループごとの開始時刻を示す実行スケジュールを設定するスケジュール設定部を備え、前記更新制御部は、前記実行スケジュールに従い各前記グループの前記ファームウェア更新処理を前記更新処理部に実行させるものである請求項１又は請求項２に記載のファームウェア更新システム。
【請求項４】
前記ファームウェア更新処理の実行にかかる複数の前記グループ間での優先順位を設定する優先順位設定部を備え、
前記スケジュール設定部は、前記優先順位が上位に設定されている前記グループの前記ファームウェア更新処理が、前記優先順位がそれよりも下位に設定されているグループよりも先に実行されるように前記実行スケジュールを設定するものである請求項３記載のファームウェア更新システム。
【請求項５】
前記グループテーブル記憶部が記憶する前記グループテーブルにおいて、前記機器属性ＩＤが同一の複数の前記ＩｏＴ機器は、各々２以上のＩｏＴ機器を含む複数のグループに区分されている、請求項１ないし請求項４のいずれか一項に記載のファームウェア更新システム。
【請求項６】
前記グループテーブル記憶部が記憶する前記グループテーブルにおいて、前記機器属性ＩＤが同一であって使用するファームウェアのバージョンが互いに異なる前記ＩｏＴ機器は、互いに異なる前記グループに区分されている、請求項１ないし請求項５のいずれか一項に記載のファームウェア更新システム。
【請求項７】
前記更新制限指令部は前記更新制御部に対し、前記ファームウェア更新処理に失敗した前記グループが発生した場合に、前記ファームウェア未更新の残余の前記グループの少なくとも一部について、前記ファームウェア更新処理の実行を中止する指令を行なうものである請求項１ないし請求項６のいずれか１項に記載のファームウェア更新システム。
【請求項８】
複数の前記ＩｏＴ機器に対する前記ファームウェア更新処理の進捗率を、それらＩｏＴ機器を区分する前記グループを単位とした更新完了実績に基づいて算出する進捗率算出部を備え、
前記更新制限指令部は、前記ファームウェア更新処理に失敗した前記グループが発生した時点での前記進捗率に基づいて、残余の前記グループに対する前記ファームウェア更新処理の制限内容を決定するものである請求項１ないし請求項７のいずれか１項に記載のファームウェア更新システム。
【請求項９】
複数のＩｏＴ機器のそれぞれに実装されているファームウェアを、通信ネットワークを介して新しいバージョンのファームウェアに更新するに際し、前記ファームウェアの更新処理を、前記複数のＩｏＴ機器を区分する複数のグループ間にて互いに異なるタイミングにて実行するとともに、複数の前記グループに対する前記ファームウェア更新処理を逐次実行する過程において、前記ファームウェアの更新処理に失敗したグループが発生した場合に、ファームウェア未更新の残余の前記グループに対する前記ファームウェア更新処理の実行を制限し、前記ＩｏＴ機器の種類を特定する情報である機器属性ＩＤが異なる前記ＩｏＴ機器が互いに異なる前記グループに所属するように、複数の前記ＩｏＴ機器に対する前記グループの区分が設定され、前記複数のＩｏＴ機器の各々が属するグループを特定するグループＩＤと前記機器属性ＩＤとが互いに対応付けられた情報であるグループテーブルを記憶し、前記グループテーブルを用いて前記更新処理を実行する、ファームウェア更新方法。
【請求項１０】
コンピュータを、
複数のＩｏＴ機器のそれぞれに実装されているファームウェアを、通信ネットワークを介して新しいバージョンのファームウェアに更新するファームウェア更新処理を行なう更新処理部と、
前記ファームウェアの更新処理を前記更新処理部に対し、前記複数のＩｏＴ機器を区分する複数のグループ間にて互いに異なるタイミングにて実行させる更新制御部と、
複数の前記グループに対する前記ファームウェア更新処理を逐次実行する過程において、前記ファームウェア更新処理に失敗したグループが発生した場合に、前記更新制御部に対し、ファームウェア未更新の残余の前記グループに対する前記ファームウェア更新処理の実行を制限する指令を行なう更新制限指令部と、
前記ＩｏＴ機器の種類を特定する情報である機器属性ＩＤが異なる前記ＩｏＴ機器が互いに異なる前記グループに所属するように、複数の前記ＩｏＴ機器に対する前記グループの区分が設定され、前記複数のＩｏＴ機器の各々が属するグループを特定するグループＩＤと前記機器属性ＩＤとが互いに対応付けられた情報であるグループテーブルを記憶するグループテーブル記憶部と、して機能させ、
前記更新制御部は、前記グループテーブルを用いて前記更新処理を実行する、コンピュータプログラム。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】０００７
【補正方法】変更
【補正の内容】
【０００７】
本発明の第１の形態に従えば、複数のＩｏＴ機器のそれぞれに実装されているファームウェアを、通信ネットワークを介して新しいバージョンのファームウェアに更新するファームウェア更新処理を行なう更新処理部と、ファームウェアの更新処理を更新処理部に対し、複数のＩｏＴ機器を区分する複数のグループ間にて互いに異なるタイミングにて実行させる更新制御部と、複数のグループに対するファームウェア更新処理を逐次実行する過程において、ファームウェア更新処理に失敗したグループが発生した場合に、更新制御部に対し、ファームウェア未更新の残余のグループに対するファームウェア更新処理の実行を制限する指令を行なう更新制限指令部と、ＩｏＴ機器の種類を特定する情報である機器属性ＩＤが異なるＩｏＴ機器が互いに異なるグループに所属するように、複数のＩｏＴ機器に対するグループの区分が設定され、複数のＩｏＴ機器の各々が属するグループを特定するグループＩＤと機器属性ＩＤとが互いに対応付けられた情報であるグループテーブルを記憶するグループテーブル記憶部と、を備え、更新制御部は、グループテーブルを用いて更新処理を実行する、ファームウェア更新システムが提供される。本発明の第２の形態に従えば、複数のＩｏＴ機器のそれぞれに実装されているファームウェアを、通信ネットワークを介して新しいバージョンのファームウェアに更新するに際し、ファームウェアの更新処理を、複数のＩｏＴ機器を区分する複数のグループ間にて互いに異なるタイミングにて実行するとともに、複数のグループに対するファームウェア更新処理を逐次実行する過程において、ファームウェアの更新処理に失敗したグループが発生した場合に、ファームウェア未更新の残余のグループに対するファームウェア更新処理の実行を制限し、ＩｏＴ機器の種類を特定する情報である機器属性ＩＤが異なるＩｏＴ機器が互いに異なるグループに所属するように、複数のＩｏＴ機器に対するグループの区分が設定され、複数のＩｏＴ機器の各々が属するグループを特定するグループＩＤと機器属性ＩＤとが互いに対応付けられた情報であるグループテーブルを記憶し、グループテーブルを用いて更新処理を実行する、ファームウェア更新方法が提供される。本発明の第３の形態に従えば、コンピュータを、複数のＩｏＴ機器のそれぞれに実装されているファームウェアを、通信ネットワークを介して新しいバージョンのファームウェアに更新するファームウェア更新処理を行なう更新処理部と、ファームウェアの更新処理を更新処理部に対し、複数のＩｏＴ機器を区分する複数のグループ間にて互いに異なるタイミングにて実行させる更新制御部と、複数のグループに対するファームウェア更新処理を逐次実行する過程において、ファームウェア更新処理に失敗したグループが発生した場合に、更新制御部に対し、ファームウェア未更新の残余のグループに対するファームウェア更新処理の実行を制限する指令を行なう更新制限指令部と、ＩｏＴ機器の種類を特定する情報である機器属性ＩＤが異なるＩｏＴ機器が互いに異なるグループに所属するように、複数のＩｏＴ機器に対するグループの区分が設定され、複数のＩｏＴ機器の各々が属するグループを特定するグループＩＤと機器属性ＩＤとが互いに対応付けられた情報であるグループテーブルを記憶するグループテーブル記憶部と、して機能させ、更新制御部は、グループテーブルを用いて更新処理を実行する、コンピュータプログラムが提供される。本発明の一形態のファームウェア更新システムは、複数のＩｏＴ機器のそれぞれに実装されているファームウェアを、通信ネットワークを介して新しいバージョンのファームウェアに更新するファームウェア更新処理を行なう更新処理部と、ファームウェアの更新処理を更新処理部に対し、複数のＩｏＴ機器を区分する複数のグループ間にて互いに異なるタイミングにて実行させる更新制御部と、複数のグループに対するファームウェア更新処理を逐次実行する過程において、ファームウェア更新処理に失敗したグループが発生した場合に、更新制御部に対し、ファームウェア未更新の残余のグループに対するファームウェア更新処理の実行を制限する指令を行なう更新制限指令部とを備えたことを特徴とする。