(57)【要約】【課題】ソフトウェアのバージョン情報の更新の問い合わせ処理を効率化することを目的とする。【解決手段】バッチ処理でソフトウェアの情報が記録部に記録されていた場合には、受信手段により受信されたリクエストの応答として、ネットワークデバイスに対して、バッチ処理で記録されたソフトウェアの情報に基づく通知を実行することによって課題を解決する。【選択図】図９
2016110222.tif 000002
【特許請求の範囲】
【請求項１】
管理対象のネットワークデバイスのソフトウェアを管理する管理システムであって、
前記管理対象のネットワークデバイスからのリクエストを受信する受信手段と、
前記受信手段によるリクエストの受信に応じて、前記ネットワークデバイスに提供すべきソフトウェアを特定する特定手段と、
前記リクエストの応答として、前記ネットワークデバイスに対して、前記特定手段により特定されたソフトウェアの情報に基づく通知を実行する通知手段と、
バッチ処理手段によるバッチ処理を制御する制御手段と、を有し、
前記バッチ処理手段は、
ソフトウェアの更新の対象となるネットワークデバイスを抽出する抽出手段と、
前記抽出手段により抽出されたネットワークデバイスに対して一定期間内に定期アップデートによるソフトウェアの更新が行われたか否かを判断する判断手段と、
前記判断手段により前記更新が行われたと判断されたネットワークデバイスに対して適用可能なソフトウェアを特定し、特定したソフトウェアの情報を記録部に記録する記録手段と、を有し、
前記通知手段は、前記バッチ処理でソフトウェアの情報が前記記録部に記録されていた場合には、前記受信手段により受信されたリクエストの応答として、前記ネットワークデバイスに対して、前記バッチ処理で記録された前記ソフトウェアの情報に基づく通知を実行することを特徴とする管理システム。
【請求項２】
前記バッチ処理手段は、前回、バッチ処理を実行してからソフトウェアの登録更新がされたネットワークデバイスのデバイスモデルを抽出するデバイスモデル抽出手段を更に有することを特徴とする請求項１に記載の管理システム。
【請求項３】
前記抽出手段は、前記デバイスモデル抽出手段により抽出された前記デバイスモデルに対応するネットワークデバイスのうち、ソフトウェアのネットワークデバイスへの配信のスケジュールを管理するデバイス配信状態データに登録されているネットワークデバイスを、ソフトウェアの更新の対象となるネットワークデバイスとして抽出することを特徴とする請求項２に記載の管理システム。
【請求項４】
前記デバイス配信状態データを管理するデータ管理手段を更に有することを特徴とする請求項３に記載の管理システム。
【請求項５】
前記受信手段により前記リクエストが受信された場合、前記リクエストに含まれる更新種別に基づいて、定期アップデートか否かを判断する更新種別判断手段を更に有し、
前記通知手段は、前記更新種別判断手段により定期アップデートであると判断され、かつ、前記バッチ処理でソフトウェアの情報が前記記録部に記録されていた場合には、前記リクエストの応答として、前記ネットワークデバイスに対して、前記バッチ処理で記録された前記ソフトウェアの情報に基づく通知を実行することを特徴とする請求項１乃至４の何れか１項に記載の管理システム。
【請求項６】
前記特定手段は、前記判断手段により定期アップデートでないと判断された場合、前記ネットワークデバイスに提供すべきソフトウェアを特定し、
前記通知手段は、前記ネットワークデバイスに対して、前記特定手段により特定されたソフトウェアの情報に基づく通知を実行することを特徴とする請求項５に記載の管理システム。
【請求項７】
前記制御手段は、前記バッチ処理手段によるバッチ処理を行うタイミングを前記管理システムの負荷状況データに基づき決定し、決定したタイミングで前記バッチ処理が実行されるよう制御することを特徴とする請求項１乃至６の何れか１項に記載の管理システム。
【請求項８】
前記通知手段は、前記バッチ処理で特定されたソフトウェアの格納先を示すアドレス情報を通知することを特徴とする請求項１乃至７の何れか１項に記載の管理システム。
【請求項９】
前記特定手段は、前記受信手段によるリクエストの受信に応じて前記ネットワークデバイスに対して適用可能なソフトウェアを検索することで、前記ネットワークデバイスに提供すべきソフトウェアを特定することを特徴とする請求項１乃至８の何れか１項に記載の管理システム。
【請求項１０】
管理対象のネットワークデバイスのソフトウェアを管理する管理システムが実行する情報処理方法であって、
前記管理対象のネットワークデバイスからのリクエストを受信する受信ステップと、
前記受信ステップによるリクエストの受信に応じて、前記ネットワークデバイスに提供すべきソフトウェアを特定する特定ステップと、
前記リクエストの応答として、前記ネットワークデバイスに対して、前記特定ステップにより特定されたソフトウェアの情報に基づく通知を実行する通知ステップと、
バッチ処理ステップによるバッチ処理を制御する制御ステップと、を含み、
前記バッチ処理ステップは、
ソフトウェアの更新の対象となるネットワークデバイスを抽出する抽出ステップと、
前記抽出ステップにより抽出されたネットワークデバイスに対して一定期間内に定期アップデートによるソフトウェアの更新が行われたか否かを判断する判断ステップと、
前記判断ステップにより前記更新が行われたと判断されたネットワークデバイスに対して適用可能なソフトウェアを特定し、特定したソフトウェアの情報を記録部に記録する記録ステップと、を含み、
前記通知ステップでは、前記バッチ処理でソフトウェアの情報が前記記録部に記録されていた場合には、前記受信ステップにより受信されたリクエストの応答として、前記ネットワークデバイスに対して、前記バッチ処理で記録された前記ソフトウェアの情報に基づく通知を実行することを特徴とする情報処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、管理システム及び情報処理方法に関する。
【背景技術】
【０００２】
デバイスのソフトウェアのバージョンアップ又は障害等の理由によりソフトウェアを更新する必要が生じた場合に、次のようにソフトウェアの更新が行われている。即ち、インターネット経由で配信システムによりソフトウェアの更新が行われるか、ＵＳＢ経由／イントラネット経由のアップデートツールを使用することでソフトウェアの更新が行われる。
デバイスのソフトウェアは、一つ以上のモジュールから構成されることがある。適切なバージョン情報の組合せでソフトウェアを配信するために、各モジュールのソフトウェア・バージョン情報の組合せをソフトウェアのバージョン情報として管理する必要がある。特許文献１には配信システムがデバイスからソフトウェアのバージョン情報を通知してもらい、そのバージョン情報を基に、適用するソフトウェアを決定し、最適な配信処理を行う技術が提案されている。前記配信システムは、最新モジュールのリストと最新モジュールの実行に必要な他のモジュールのリストとの情報に基づいて更新処理を実行する。これにより、モジュール間の依存関係を考慮した状態で更新処理が自動的に行われる。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００５−１３５１８７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
今日、多くのデバイスが配信システムに接続され、ソフトウェアの更新処理の自動化が行われている。また、デバイスの多様化に伴い、更新処理の対象となるソフトウェアの種類も増加の傾向にある。つまり、検索対象となるモジュールの組み合わせが急速に増加している。このような中で、配信システムにおいて、各デバイスのソフトウェアのバージョン情報から適用可能なソフトウェアのモジュールの組み合わせを見つけ出すには多くの処理時間が必要となる。更に、対象デバイスの増加のため、配信システムでは、デバイスからの更新可能なソフトウェアの問い合わせ処理の負荷が集中している。
配信システムが、予め、デバイスにインストールされているソフトウェアのモジュールを全て把握しておけば、デバイスからの問い合わせ処理は必要なくなる。しかしながら、個別の障害対応のために、サービスマンが配信システムを使わずに障害対策のソフトウェア等をデバイスへ直接、インストールする場合も多々ある。特に、多様な機能を持つ画像形成装置のように顧客毎にカスタマイズされて利用されるデバイスの場合には、この傾向が強い。したがって、配信システムが全てのデバイスの状況を把握していることを前提とすることができず、デバイスから配信システムへの問い合わせ処理は必要なプロセスの一つとなっている。同様の傾向がある製品としては、ネットワークに接続された家電、又は、車両や携帯電話等も、自動配信とサービスマンとによるソフトウェアのインストールとが併用されているものとして挙げられる。
本発明は、ソフトウェアのバージョン情報の更新の問い合わせ処理を効率化することを目的とする。
【課題を解決するための手段】
【０００５】
そこで、本発明は、管理対象のネットワークデバイスのソフトウェアを管理する管理システムであって、前記管理対象のネットワークデバイスからのリクエストを受信する受信手段と、前記受信手段によるリクエストの受信に応じて、前記ネットワークデバイスに提供すべきソフトウェアを特定する特定手段と、前記リクエストの応答として、前記ネットワークデバイスに対して、前記特定手段により特定されたソフトウェアの情報に基づく通知を実行する通知手段と、バッチ処理手段によるバッチ処理を制御する制御手段と、を有し、前記バッチ処理手段は、ソフトウェアの更新の対象となるネットワークデバイスを抽出する抽出手段と、前記抽出手段により抽出されたネットワークデバイスに対して一定期間内に定期アップデートによるソフトウェアの更新が行われたか否かを判断する判断手段と、前記判断手段により前記更新が行われたと判断されたネットワークデバイスに対して適用可能なソフトウェアを特定し、特定したソフトウェアの情報を記録部に記録する記録手段と、を有し、前記通知手段は、前記バッチ処理でソフトウェアの情報が前記記録部に記録されていた場合には、前記受信手段により受信されたリクエストの応答として、前記ネットワークデバイスに対して、前記バッチ処理で記録された前記ソフトウェアの情報に基づく通知を実行することを特徴とする。
【発明の効果】
【０００６】
本発明によれば、ソフトウェアのバージョン情報の更新の問い合わせ処理を効率化することができる。
【図面の簡単な説明】
【０００７】
【図１】ネットワークシステムのシステム構成の一例を示す図である。
【図２】アプリケーションサーバのハードウェア構成等の一例を示す図である。
【図３】配信システム等の機能構成の一例を示す図である。
【図４】ファームウェアを更新する情報処理の一例を示すシーケンス図である。
【図５】ファームウェアを更新する情報処理の一例を示すシーケンス図である。
【図６】バッチ処理部で実行されるバッチ処理の一例を示すフローチャートである。
【図７】図６におけるステップＳ１００１の詳細を示すフローチャートである。
【図８】ステップＳ１００２の詳細を示すフローチャートである。
【図９】バージョン情報返却処理部の情報処理の一例を示すフローチャートである。
【図１０】ファームウェア返却処理部の情報処理の一例を示すフローチャートである。
【図１１】更新情報記録処理部の情報処理の一例を示すフローチャートである。
【図１２】配信設定確認処理部の情報処理の一例を示すフローチャートである。
【図１３】配信設定処理部の情報処理の一例を示すフローチャートである。
【発明を実施するための形態】
【０００８】
以下、本発明の実施形態について図面に基づいて説明する。
【０００９】
図１は、ネットワークシステムのシステム構成の一例を示す図である。図１に示される様に、ネットワークシステムは、配信システム１０、コンテンツサーバ２０、販売会社システム３０等を含む。配信システム１０は、Ｗｅｂサーバ１２、ＤＢサーバ１３及びアプリケーションサーバ１１を含む。配信システム１０は、インターネット１００に接続されたＷｅｂサーバ１２を介して、各顧客企業１１４、１１９、１２９のデバイス１１５〜１１６、１２０、１２１、１２４〜１２７、１３１と通信を行い、ファームウェアの配信制御を行う。配信システム１０は、管理対象のデバイスのファームウェアを管理し、前記デバイスからの要求に応じてファームウェアを配信する管理システムの一例である。
ファームウェアの実ファイルはコンテンツサーバ２０にある。配信システム１０は、デバイスへファームウェアをインストールする場合、コンテンツサーバ２０上の実ファイルの位置情報を取得し、コンテンツサーバ２０からファームウェアをダウンロードする。配信システム１０によるこのような処理より、多くのデバイスのファームウェア配信の負荷を分散し、効率よくファームウェアの配信を行うことができる。
コンテンツサーバ２０は、コンテンツ管理サーバ２１及びファイル・ストレージ２２、２３を含む。コンテンツ管理サーバ２１は、外部からのリクエストに従って、ファイル・コンテンツ、即ちファームウェアを保存、又は提供する。
【００１０】
デバイスには、マルチ・ファンクション・プリンタ（ＭＦＰ）や、シングル・ファンクション・プリンタ（ＳＦＰ）等の種類があり、デバイスのモデル毎に一つ又は複数の機能が搭載されている。そして、機能毎に、異なるファームウェアモジュールがインストールされることにより、デバイスの各機能が利用可能となる。また、デバイスのファームウェアが修正された場合や機能の改善又は追加された場合には、ファームウェアモジュールを更新することで、各機能等を利用することができるようになる。
本実施形態では、デバイスとしてＭＦＰ及びＳＦＰを例に挙げているが、これに限らず、配信システム１０による自動配信が為される一方で、人によるファームウェアの手動更新が行われる場合があるデバイスであれば、本実施形態の技術は有効である。他に本実施形態が有効な例としては、インターネットに接続された家電、電子制御機器を複数搭載する車両、又は携帯電話等が挙げられる。ＭＦＰやＳＦＰ、家電、車両、携帯電話等は、ネットワークデバイスの例である。
また、本実施形態では、配信するソフトウェアの一例としてファームウェアを例に挙げているが、これに限られず、アプリケーションソフトウェアやオペレーティングシステムであっても本実施形態の技術を適用することができる。
販売会社システム３０は、デバイスを各顧客企業１１４、１１９、１２９へ販売し、維持、管理するデバイスの製造会社又はデバイスの販売会社がファームウェアの登録・管理のためのシステムである。販売会社システム３０は、１台以上のＰＣ３１、３２又はサーバ３３、３４を含む。販売会社システム３０から配信システム１０及びコンテンツサーバ２０へアクセスすることにより、ファームウェアの登録及びファームウェアの配信設定が行われる。
【００１１】
図２は、アプリケーションサーバ１１のハードウェア構成等の一例を示す図である。本実施形態におけるアプリケーションサーバ１１は、ネットワークインタフェース２０４を介して、Ｗｅｂサーバ１２やＤＢサーバ１３と互いに接続されている。アプリケーションサーバ１１は、バス２０５を介して接続されたＣＰＵ２０１、ＲＡＭ２０２、ＲＯＭ２０３、ネットワークインタフェース２０４、ＨＤＤ２０６等を含む。ＣＰＵ２０１がＨＤＤ２０６又はＲＯＭ２０３、ＲＡＭ２０２に記録されたデータ及びプログラムを読み出して処理を実行することによりアプリケーションサーバ１１の機能等が実現される。ネットワークインタフェース２０４は、配信システム１０内のサーバ間の機能連携に使われると共に、インターネット１００を介して、外部システムと通信するためにも使用される。
アプリケーションサーバ１１以外のサーバ等（例えば、Ｗｅｂサーバ１２、ＤＢサーバ１３）も図２に示すハードウェア構成と同様のハードウェア構成を有する。各サーバのＣＰＵが各サーバのＲＯＭ、ＨＤＤ等に記憶されたプログラムに基づき処理を実行することによって、各サーバの機能等が実現される。
配信システム１０の機能は、アプリケーションサーバ１１単独、又はアプリケーションサーバ１１とＤＢサーバ１３との連携等によって実現される。
【００１２】
図３は、配信システム１０等の機能構成の一例を示す図である。
デバイス３０１は、配信システム１０に接続されるデバイスの一例である。Ｗｅｂブラウザ３０２は、配信システム１０に接続される販売会社システムの一例であるクライアントシステムのＷｅｂブラウザである。
Ｗｅｂインターフェース部３１０は、デバイスに対するファームウェアの配信機能を提供する。
ユーザインタフェース部３１１は、配信システムにアクセスして、ファームウェアの登録や配信設定を行う。
リクエスト受信部３１２は、デバイスからのリクエストを受信する。
レスポンス返信部３１３は、デバイスへレスポンスを返す。
バッチ処理部３１４は、デバイスへ配信するファームウェアを予めバッチ処理で求める。
バージョン情報返却処理部３１５は、デバイスからの問い合わせに対して、更新するファームウェアの情報を求める。
ファームウェア返却処理部３１６は、デバイスから指定されたバージョン情報のファームウェアの場所を示す情報を求める。
【００１３】
更新情報記録処理部３１７は、デバイスからの通知に従って、デバイスにインストールされているファームウェアの情報を記録する。
配信設定確認処理部３１８は、デバイスからの問い合わせに対して、配信システムに設定されている配信設定情報を求める。
配信設定処理部３１９は、デバイス又は、販売会社システムからのリクエストに対して、ファームウェア配信の設定を行う。
ＤＢアクセス部３２０は、各種処理に応じて、データ管理部３３０で管理されているテーブルのデータを更新又は検索する。
データ管理部３３０は、以下のテーブルを管理する。即ち、デバイスモデル管理テーブル３３１、ファームウェアグループ管理テーブル３３２、更新可能バージョン管理テーブル３３３、デバイス配信状態テーブル３３４、デバイスファームウェア管理テーブル３３５、負荷状況テーブル３３６である。各テーブルは、例えば、ＤＢサーバ１３のハードディスク等に記憶される。各テーブルの詳細は、後述する表において説明する。デバイス配信状態テーブル３３４に格納されているデータは、デバイス配信状態データの一例である。負荷状況テーブル３３６に格納されているデータは、負荷状況データの一例である。
【００１４】
図４は、デバイスのファームウェアを更新する情報処理の一例を示すシーケンス図である。なお、以下の図面では、簡略化のため、「ファームウェア」を「ＦＷ」とも記す。
操作者４０３は、デバイスのファームウェア更新を行う操作をするサービスマン又はユーザである。
操作者４０３は、ファームウェア更新を行う対象デバイスであるデバイス４００の操作パネルを操作し、ファームウェアの更新画面の表示を要求する。デバイス４００は、操作パネルを介した操作者４０３の前記操作を受け付け、前記要求を受け取る（ＳＣ４１０）。
前記要求に応じて、デバイス４００は、デバイス４００に現在インストールされているファームウェアのバージョン情報を配信システム１０へ送り、デバイス４００に適用可能なファームウェアのバージョン情報が存在するか、確認する（ＳＣ４１１）。デバイス４００は、デバイス４００に適用可能なファームウェアのバージョン情報が存在する場合には適用可能なファームウェアのバージョン情報の一覧を要求する。デバイス４００は、配信システム１０へ、このＳＣ４１１のリクエストが、デバイス側操作の手動更新操作であることを示す情報（更新種別）を合わせて送る。
ＳＣ４１１の要求に対して、配信システム１０は、適用可能なファームウェアのバージョン情報の一覧を返却する（ＳＣ４１２）。
デバイス４００は、ＳＣ４１２で受信したファームウェアのバージョン情報の一覧を操作パネルに表示することで操作者４０３へ示し、更新するファームウェアのバージョン情報を選択することを促す（ＳＣ４１３）。
【００１５】
操作者４０３は、更新するファームウェアのバージョン情報を選択する操作を行う。デバイス４００は、前記選択の操作を受け付ける（ＳＣ４１４）。
デバイス４００は、操作者４０３によって選択されたファームウェアのバージョン情報を指定して、配信システム１０に要求する（ＳＣ４１５）。
配信システム１０は、指定されたファームウェアのバージョン情報を構成するファームウェアのモジュールをダウンロードするためのＵＲＬのリストをデバイス４００へ返す（ＳＣ４１６）。ＵＲＬは、該当するファームウェアのモジュールが格納されているコンテンツサーバ２０上のダウンロード場所を示している。
デバイス４００は、ＵＲＬに従って、コンテンツサーバ２０へファームウェアのモジュールをダウンロードするためのリクエストを送る（ＳＣ４１７）。
リクエストに応じて、コンテンツサーバ２０は、モジュールのファームウェアファイルをデバイス４００へ返す（ＳＣ４１８）。ダウンロードするファームウェアのモジュールが複数ある場合には、デバイス４００及びコンテンツサーバ２０は、ＳＣ４１７とＳＣ４１８との処理をファームウェアのモジュールの数の分、繰り返す。
ファームウェアのモジュールがダウンロードできた場合、デバイス４００は、ファームウェアのインストールを行う（ＳＣ４１９）。
ファームウェアのインストールが完了すると、デバイス４００は、配信システム１０へ、ファームウェアの更新が完了したことを通知する（ＳＣ４２０）。このとき、デバイス４００は、配信システム１０へ、更新後のファームウェアのバージョン情報を送信する。
最後に、デバイス４００は、ファームウェアの更新が完了したことを操作パネルに表示することで操作者４０３に示して（ＳＣ４２１）、デバイス４００における更新処理を完了する。
【００１６】
また、図４には、デバイスの操作によってファームウェアを更新するもう一つの処理も示されている。
サービスマン４０４は、ファームウェアモジュールを可搬メディア（例えばＣＤやＤＶＤ等）で持参してきたサービスマンである。サービスマン４０４は、ファームウェアをデバイス４００へインストールするためのツール（例えば、デバイスと通信可能なノートＰＣ等）をデバイス４００へ接続し、持参したファームウェアモジュールをデバイス４００へ転送する。デバイス４００は、ファームウェアモジュールの転送を受け付ける（ＳＣ４３０）。
デバイス４００は、サービスマン４０４から転送されたファームウェアのインストールを行う（ＳＣ４３１）。
そして、デバイス４００は、ファームウェアの更新完了を操作パネルに表示することでサービスマン４０４に対して示して（ＳＣ４３２）、更新処理を完了する。
ＳＣ４３０からＳＣ４３２までで示したファームウェア更新手順の場合には、配信システム１０が使用されていないため、更新完了後にデバイス４００にインストールされているファームウェアのバージョン情報は配信システムに通知されない。
【００１７】
図５は、デバイス４００及び配信システム１０において設定されている配信設定に従って、自動でデバイスのファームウェアを更新するときの情報処理の一例を示すシーケンス図である。
図５に示す設定は、図４で示したデバイスと同じデバイスに対して設定する事も可能である。
サービスマン４０５は自動配信の設定を行うサービスマンである。
図５に示す流れにおいて、設定操作をする対象によって、設定の流れは二種類あることを示している。
まず、一つは、サービスマン４０５が配信システム１０に対して自動配信の設定操作を行う処理４０６の流れである。そして、もう一つは、サービスマン４０５がデバイス４００に対して自動設定の設定操作を行う処理４０７の流れである。
処理４０６の場合、サービスマン４０５は、Ｗｅｂブラウザ３０２を介して、配信システム１０に対して、ファームウェアの更新予約設定を行う。配信システム１０は、Ｗｅｂブラウザ３０２を介した前記ファームウェアの更新予約設定を受け付ける（ＳＣ４４０）。ファームウェアの更新予約設定のために、サービスマン４０５は、Ｗｅｂブラウザ３０２を介して、デバイスを指定するための情報（後述するデバイスＩＤ）を指定する。また、サービスマン４０５は、Ｗｅｂブラウザ３０２を介して、更新予約設定において、ファームウェアの更新を実行する日時の指定、又は、定期的にファームウェアの更新処理を実行する定期アップデートの指定の何れかを設定する。
配信システム１０は、受け付けた設定内容をシステム内に記録すると、確認のために予約内容をＷｅｂブラウザ３０２を介して、サービスマン４０５に示して（ＳＣ４４１）、設定を完了する。
【００１８】
一方、処理４０７の場合、サービスマン４０５は、デバイス４００に対して、ファームウェアの更新予約設定を行う。デバイス４００は、サービスマン４０５によるファームウェアの更新予約設定を受け付ける（ＳＣ４５０）。
ＳＣ４５０に対して、デバイス４００は、ファームウェアの更新予約設定に基づき配信設定の情報を記憶すると共に、配信システム１０に対して、配信設定の情報を送信する（ＳＣ４５１）。送信する内容は、ＳＣ４４０で設定された内容と同様である。
ＳＣ４５１に対して、配信システム１０は、設定内容をシステム内に記録すると、確認のために予約内容である配信設定情報をデバイス４００へ返却する（ＳＣ４５２）。
デバイス４００は、予約内容を操作パネルに表示することによりサービスマン４０５に示して（ＳＣ４５３）、設定を完了する。
処理４０６と処理４０７との処理は、両方共何度でも実施することが可能であるが、後から設定されたほうが優先とし、配信システム１０に記録される内容は最後の設定で上書きされるものとする。
【００１９】
処理４０８は、デバイス４００における、配信システム１０の設定内容を確認するシーケンスである。
デバイス４００は、配信システム１０に対して、デバイス４００を示すデバイスＩＤを送信して、配信システム１０が記録している配信設定を確認する（ＳＣ４６０）。
ＳＣ４６０に対して、配信システム１０は、デバイス４００に対応する、そのときの配信設定内容を配信設定情報として返却する（ＳＣ４６１）。
デバイス４００は、配信システム１０から返却された配信設定内容で、自身の記憶されている配信設定内容を上書きする。
処理４０８の処理は、デバイス４００において、定期的に実行され、その周期は少なくとも、ファームウェアの定期アップデートの周期として設定可能な一番短い間隔よりも短いものである。
【００２０】
処理４０９の処理は、デバイス４００に記憶された配信設定内容に従って、所定日時又は設定された周期で定期的に実行されるファームウェアの更新処理である。
配信設定で決められた予約日時４７０になると、デバイス４００は、デバイス４００に現在インストールされているファームウェアのバージョン情報を配信システム１０へ送る（ＳＣ４７１）。これにより、デバイス４００は、配信システム１０にデバイス４００に適用可能なファームウェアの最新バージョン情報が存在するかを問い合わせる。デバイス４００は、配信システム１０へ、このＳＣ４７１のリクエストが、配信設定による自動更新操作であることを示す情報（更新種別として、日時指定更新又は定期アップデートの何れか）を合わせて送る。
ＳＣ４７１に対して、配信システム１０は、存在すれば、適用可能なファームウェアの最新バージョン情報のＵＲＬを返却する（ＳＣ４７２）。
デバイス４００は、ファームウェアの最新バージョン情報を指定して、配信システム１０に要求する（ＳＣ４７３）。
配信システム１０は、指定されたファームウェアのバージョン情報を構成するファームウェアのモジュールをダウンロードするためのＵＲＬのリストをデバイス４００へ返す（ＳＣ４７４）。ファームウェアのモジュールをダウンロードするためのＵＲＬは、ファームウェアのモジュールの格納先を示すアドレス情報の一例である。
【００２１】
デバイス４００は、ＵＲＬに従って、コンテンツサーバ２０へファームウェアのモジュールをダウンロードするためのリクエストを送る（ＳＣ４７５）。
コンテンツサーバ２０は、前記リクエストに応じて、モジュールのファームウェアファイルをデバイス４００へ返す（ＳＣ４７６）。
デバイス４００及びコンテンツサーバ２０は、ダウンロードするファームウェアのモジュール数分だけ、（ＳＣ４７５）と（ＳＣ４７６）との処理を繰り返す。
ファームウェアのモジュールがダウンロードできた場合、デバイス４００は、ファームウェアのインストールを行う（ＳＣ４７７）。
ファームウェアのインストールが完了すると、デバイス４００は、配信システム１０へ、ファームウェアの更新が完了したことを通知する（ＳＣ４７８）。このとき、デバイス４００は、配信システム１０へ、更新後のファームウェアのバージョン情報を送信する。
【００２２】
表Ａにデバイスにインストールされているファームウェアのバージョン情報の一例を示す。
【表１】
2016110222.tif 000003
【００２３】
バージョン情報は、ファームウェアを構成するモジュール名とモジュール名に対応するバージョン情報との組合せの一覧を含む。表Ａに示す内容は、デバイス内で管理されているバージョン情報のテーブルの内容でもある。
表Ａに示す例において、デバイスにインストールされているファームウェアは、ＡからＦまでの６つモジュールから構成されており、それらのバージョン情報は何れも「０１．００」であることが分かる。
【００２４】
表Ａに示す内容は、図４におけるＳＣ４１１、図５におけるＳＣ４７１にて、配信システム１０へ更新可能なファームウェアを問い合わせるために、デバイス４００から配信システム１０へ送信される。
また、デバイスにおいて、ファームウェアを更新すると、更新したファームウェアに従って、表Ａに示すテーブルも更新される。そして、更新された内容が、図４におけるＳＣ４２０、図５におけるＳＣ４７８にて、デバイス４００から配信システム１０へ通知される。
各デバイスには、個体を識別するためのＩＤとしてシリアル番号が付与され、このシリアル番号をデバイスＩＤと呼ぶ。デバイスＩＤは製造会社及び販売会社によって管理されている。製造会社及び販売会社は、デバイスＩＤで、商品であるデバイス個体を管理すると共に、ある一定範囲のデバイスＩＤで、同じモデルの商品として管理する。ここで、同じモデルの商品は、同じファームウェアが適用できることも表している。配信システム１０は、デバイスのモデルとデバイスシリアル番号との対応を管理し、デバイスモデルに対応してファームウェアを登録、管理している。
【００２５】
表Ｂに、配信システムにおいて、デバイスのモデルとデバイスシリアル番号との対応を管理する表であるデバイスモデル管理テーブル３３１の例を示す。
【表２】
2016110222.tif 000004
【００２６】
表Ｂにおいて、「デバイスＩＤ開始」と「デバイスＩＤ終了」とが示すカラムは、デバイスモデルに対応するシリアル番号の範囲を示している。また、「モデル識別ＩＤ」は、デバイスモデルを識別するためのＩＤである。例えば、表Ｂの１行目において、デバイスシリアル番号がＡＢＡ０１０００からＡＢＡ０１９９９までの１０００台のデバイスが、「ＭＩＤ＿１」というＩＤのデバイスモデルに対応することを示している。また、表Ｂの２行目に示すように、ＡＢＣ０１０００からＡＢＣ０１９９９までのデバイスも「ＭＩＤ＿１」に対応することを示している。更に、表Ｂの６行目に示すようにＡＢＤ０４０００からＡＢＤ０４９９９が「ＭＩＤ＿５」に対応することを示している。一方で、表Ｂの７行目に示すようにＡＢＤ０４０００からＡＢＤ４１９９は「ＭＩＤ＿６」にも対応していることを示している。ＡＢＤ０４０００からＡＢＤ４１９９までのデバイスは「ＭＩＤ＿５」と「ＭＩＤ＿６」との両方のモデルに対応していることを示している。後述するように、ＢＤ０４０００からＡＢＤ４１９９までのデバイスが「ＭＩＤ＿５」に対応するファームウェアと「ＭＩＤ＿６」に対応するファームウェアとの両方をインストール可能であることを意味する。表Ｂに示すように、配信システム１０は、複数のデバイス個体を複数のデバイスモデルに対応付けて管理する。
【００２７】
「更新」と「削除」とは、デバイスモデルの登録更新を判断するためのフラグである。新しく販売又は市場で管理されるデバイスが登録される場合には、販売会社システムから配信システム１０にアクセスして、デバイスモデルの登録が行われる。デバイスモデルの登録が行われると、デバイスモデル管理テーブル３３１が更新される。デバイスモデル管理テーブル３３１に行が追加又は行が更新された場合には、該当する行の更新フラグがセットされる。デバイスモデル管理テーブル３３１から行が削除される場合には、まず、削除フラグがセットされ、後述のフラグリセット（Ｓ１２０３）の際にテーブルから行が削除される。
デバイスにインストールされるファームウェアには、モジュールのバージョン情報の適切な組合せが存在する。この適切なバージョン情報のモジュールの一組をファームウェアグループと呼ぶ。また、配信システム１０は、デバイスモデル毎にファームウェアグループを識別するためのＩＤを管理し、そのＩＤをファームウェアグループバージョン情報と呼ぶ。配信システム１０にファームウェアを登録する際には、デバイスモデルとファームウェアグループバージョン情報とが決定され、ファームウェアグループの組み合わせで登録される。
【００２８】
表Ｃに、配信システム１０が管理するデバイスモデル毎のファームウェアグループ管理テーブル３３２の例を示す。
【表３】
2016110222.tif 000005
【００２９】
表Ｃにおいて、「モデル識別ＩＤ」と「ＦＷ＿ＧＲＰ＿ＶＥＲ」との組合せでファームウェアグループが識別される。「モデル識別ＩＤ」は、表Ｂにて管理される「モデル識別ＩＤ」に対応する。「ＦＷ＿ＧＲＰ＿ＶＥＲ」はファームウェアグループバージョン情報を示す。「モジュール名」はそのファームウェアグループにおけるモジュールを表し、対応するモジュールのバージョン情報を「ＦＷ＿ＶＥＲ」が、モジュールの実体へのリンクを「ＤＬ＿ＵＲＬ」が、表している。表Ｃにおいて、例えば、１行目から６行目までで、デバイスモデル「ＭＩＤ＿１」のファームウェアグループバージョン情報「０１．００」がモジュールＡからＦまでで構成され、各モジュールのバージョン情報は何れも「０１．００」であることを示している。各モジュールは「ＤＬ＿ＵＲＬ」に示すリンク先にアクセスすることによって取得することが可能であることを示している。「ＤＬ＿ＵＲＬ」は、ファームウェアの実体を登録したコンテンツサーバにおけるアクセス先を示している。例えば、「ＭＩＤ＿１」の「０１．００」のモジュール「Ａ」は、１行目の「ＤＬ＿ＵＲＬ」に示すリンク先から取得できることを示している。
【００３０】
「更新」と「削除」とは、ファームウェアグループ管理テーブル３３２の登録更新を判断するためのフラグである。
新しくファームウェアグループバージョン情報を登録する場合、又は、既存のファームウェアグループバージョン情報にモジュールを追加する場合、ファームウェアグループ管理テーブル３３２に行が追加され、更新フラグがセットされる。また、既存のモジュールを差し替えたり、登録内容の間違いを訂正したりする場合には、ファームウェアグループ管理テーブル３３２の該当する行が更新され、更新フラグがセットされる。ファームウェアグループバージョン情報を削除する場合は、削除対象の該当する行の削除フラグがセットされる。既存のファームウェアグループバージョン情報から特定のモジュールを取り除く場合も、削除対象の該当する行の削除フラグがセットされる。削除フラグがセットされた行は、後述のフラグリセット（Ｓ１１０９）の際にテーブルから削除される。
【００３１】
配信システム１０におけるファームウェアの登録とは、コンテンツサーバ２０へファームウェアのモジュールの実体を登録し、実体の登録先に合わせてファームウェアグループ管理テーブル３３２を更新する処理のことを指す。
ファームウェアグループバージョン情報は、数値として大きい方が新しいことを示す。同じモデル識別ＩＤの中では、最も大きい数値のファームウェアグループバージョン情報が最新バージョン情報である。一方、あるファームウェアグループバージョン情報から配信システム１０によって自動更新することのできるファームウェアグループバージョン情報が制限される場合がある。例えば、内部データを置き換えても動作可能か否かの問題等から、ある程度最近のバージョン情報でなければ、最新バージョン情報に更新できない場合、等である。配信システム１０は、更新可能バージョン管理テーブル３３３で、自動更新することのできるファームウェアグループバージョン情報の制限に関する条件等を管理する。
【００３２】
表Ｄに、配信システム１０が管理する、更新可能バージョン管理テーブル３３３の例を示す。
【表４】
2016110222.tif 000006
【００３３】
表Ｄにおいて、一つの行は一つの条件を示す。条件は「モデル識別ＩＤ」に示すデバイスモデルにおいて、ファームウェアグループバージョン情報を示す「更新元バージョン」から「更新後バージョン」へのバージョン情報の更新が可能であることである。例えば、１行目は、「ＭＩＤ＿１」に属するデバイスに、ファームウェアグループバージョン情報「０１．００」がインストールされている場合、「０２．００」への更新が可能であることを示している。他の行も同様に自動更新可能なファームウェアグループバージョン情報の組合せを示している。一方、表Ｄに登録されていない条件の自動更新はできないことを示す。あるファームウェアグループバージョン情報から同じモデル識別ＩＤの中で更新可能な最新のファームウェアグループバージョン情報は、更新可能バージョン管理テーブル３３３に示す条件の中で最も大きい数値を持つファームウェアグループバージョン情報である。
【００３４】
配信システム１０による自動更新ができない条件のファームウェアグループバージョン情報へ更新したい場合には、図４のＳＣ４３０から示す手順のように、デバイス上の操作により、手動で更新を行う必要がある。
配信システム１０は、配信対象とするデバイス毎に配信及び更新の記録を管理する。また設定がされているデバイスについては、配信システム１０は、配信のスケジュールも管理する。配信のスケジュール等をデバイスＩＤに対応付けて管理するための表がデバイス配信状態テーブル３３４である。
【００３５】
表Ｅに、配信システム１０が管理する、デバイス配信状態テーブル３３４の例を示す。
【表５】
2016110222.tif 000007
【００３６】
表Ｅにおいて、一つの行は一つのデバイスの情報を示す。
「デバイスＩＤ」はその行が示す情報が対象とするデバイスを示す。
「配信日時」は、最後に配信システム１０がデバイスに対してファームウェアを配信した日時を示す記録である。「配信日時」に記録される情報は、図４におけるＳＣ４１６又は図５におけるＳＣ４７４に対応する処理のタイムスタンプである。表Ｅの例において「〜」と略記している部分は、例えば「２０１４／１０／２４  ２０：１０：０５」のように、日付と時間とを合わせた情報が入っているものとする。以下、「更新日時」と「配信予定日時」との例も同様である。
「更新日時」は、デバイスがファームウェアグループを最後に更新した日時を示す記録である。「更新日時」に記録される情報は、図４におけるＳＣ４２０又は図５におけるＳＣ４７８に対応する処理のタイムスタンプである。
「更新タイプ」は、「更新日時」の時点で更新されたファームウェアグループバージョン情報が配信された時点での更新種別の記録である。更新種別は、図４におけるＳＣ４１１又は図５におけるＳＣ４７１でデバイスから送られる情報である。更新種別には、「手動更新」、「日時指定配信」、「定期アップデート」の３種類がある。図４における、ＳＣ４３０〜ＳＣ４３２のシーケンスのように、デバイスからの更新通知が無いファームウェア更新方法の場合、配信システム１０は、「更新タイプ」を関知せず、更新しない。また、配信システム１０は、ＳＣ４２０又はＳＣ４７８によってデバイスからの更新通知が確認されない場合には更新しない。
【００３７】
「配信予定日時」は、デバイスにおけるファームウェア更新予約設定のうち、日時指定がされている場合の予約日時である。
「定期曜日」は、デバイスにおけるファームウェア更新予約設定のうち、定期アップデートの指定がされている場合の定期実行曜日である。
「定期時間」は、デバイスにおけるファームウェア更新予約設定のうち、定期アップデートの指定がされている場合の定期実行時間である。
「配信予約日時」、「定期曜日」及び「定期時間」は、図５におけるＳＣ４４０又はＳＣ４５１で指定される情報を記録する。また、図５におけるＳＣ４６０の確認に対して返却する配信設定情報も「配信予約日時」、「定期曜日」及び「定期時間」に記録される情報である。
「バッチ対象」は、後述のバッチ処理の結果、予め求められたファームウェアグループバージョン情報を返す場合にセットされるフラグである。
「ＶＥＲ」は、「バッチ対象」がセットされている場合に、デバイスに対して返されるファームウェアグループバージョン情報である。
配信システム１０は、デバイスに現在インストールされていると想定されるファームウェアモジュールのセットをデバイスファームウェア管理テーブル３３５に記録している。
【００３８】
表Ｆに、配信システム１０が管理する、デバイスファームウェア管理テーブル３３５の例を示す。
【表６】
2016110222.tif 000008
【００３９】
「デバイスＩＤ」は記録対象のデバイスである。デバイス毎に、「モジュール名」とそのモジュールの「バージョン」との組合せが記録されている。
配信システム１０は、図４におけるＳＣ４２０又は図５におけるＳＣ４７８でデバイスからファームウェア更新通知で受信した情報をデバイスファームウェア管理テーブル３３５に記録する。
【００４０】
図６は、バッチ処理部３１４で実行されるバッチ処理の一例を示すフローチャートである。
図６に示すフローチャートの処理は、一日に数回、間隔を空けて実行される。実行タイミングは基本的に所定の周期（例えば６時間毎等）に従う。但し、後述するように、配信システム１０にかかる負荷が時間ごとに差がある場合には、負荷の高いタイミングを外して実行されるものとする。
ステップＳ１０００において、バッチ処理部３１４は、バッチ処理を開始する。
ステップＳ１００１では、バッチ処理部３１４は、前回バッチ処理を実行してからファームウェアの登録更新がされたデバイスモデルを抽出する。バッチ処理部３１４は、抽出したデバイスモデルをここではＭ＿ＬＩＳＴというリストに保存する。ステップＳ１００１の処理の詳細は、後述する図７に示す。ステップＳ１００１の処理は、デバイスモデル抽出処理の一例である。
ステップＳ１００２では、バッチ処理部３１４は、更に、ファームウェアの更新をチェックする対象となるデバイスを抽出する。バッチ処理部３１４は、抽出したデバイスをここではＤ＿ＬＩＳＴというリストに保存する。ステップＳ１００２の処理の詳細は、後述する図８に示す。
【００４１】
バッチ処理部３１４は、ステップＳ１００３から開始する繰り返し処理を実行することによって、抽出した対象デバイス（Ｄ＿ＬＩＳＴ）に列挙されたデバイスを順にチェックする。より具体的には、バッチ処理部３１４は、次から述べる処理を行う。
ステップＳ１００４では、バッチ処理部３１４は、対象デバイスが一定期間（例えば１週間）内に定期アップデートによる更新が行われたかを判断する。より具体的には、バッチ処理部３１４は、デバイス配信状態テーブル３３４における対象デバイスのレコードで更新タイプが「定期アップデート」であり、かつ、更新日時が所定の期間（上記１週間）以内であるか否かを判断する。バッチ処理部３１４は、一定期間内に定期アップデートがされている場合には、ステップＳ１００５へ進む。バッチ処理部３１４は、そうでない場合には、ステップＳ１００８へ進み、次の対象デバイスのチェックを行う。
ステップＳ１００５では、バッチ処理部３１４は、対象デバイスの現在バージョン情報からバージョンアップ可能な最新バージョン情報を求める。より具体的には、バッチ処理部３１４は、デバイスファームウェア管理テーブル３３５から対象デバイスのファームウェアバージョン情報を求め、更に更新可能バージョン管理テーブル３３３から更新可能な最新のファームウェアグループバージョン情報を求める。なお、ここでファームウェアを構成するモジュールの数が変化する可能性がある場合、バッチ処理部３１４は、モジュールのリストのハッシュ値等を保持しておき、それを比較することで、変化の検出をしてもよい。バッチ処理部３１４は、バージョン情報に変化がなければ通常の比較により更新可能バージョン情報を求め、バージョン情報が変わっている場合にはモジュール毎の比較を行うことにより更新可能バージョン情報を求める。
【００４２】
ステップＳ１００６では、バッチ処理部３１４は、更新可能な最新バージョン情報が存在するか否かで処理を分岐する。バッチ処理部３１４は、更新可能な最新のファームウェアグループバージョン情報が存在する場合（Ｓ１００６でＹｅｓ）、ステップＳ１００７へ進む。バッチ処理部３１４は、存在しない場合（Ｓ１００６でＮｏ）、ステップＳ１００８へ進み、次の対象デバイスのチェックを行う。既に対象デバイスには最新のファームウェアグループバージョン情報がインストールされている場合には、存在しないことになる。またファームウェアグループバージョン情報は更新されているが、対象デバイスに新ストールされているファームウェアグループバージョン情報からは更新できない場合も、存在しないことになる。
ステップＳ１００７では、バッチ処理部３１４は、求めた更新可能バージョン情報をデバイス配信状態テーブル３３４の「ＶＥＲ」列に記録する。デバイス配信状態テーブル３３４は、記録部の一例である。
ステップＳ１００８では、バッチ処理部３１４は、抽出した対象デバイスリスト（Ｄ＿ＬＩＳＴ）を全てチェックしたかを判断する。バッチ処理部３１４は、全ての対象デバイスをチェックした場合（ステップＳ１００８でＹｅｓ）、ステップＳ１０１０へ進み、バッチ処理を終了する。バッチ処理部３１４は、チェックする対象デバイスが残っている場合（ステップＳ１００８でＮｏ）、ステップＳ１００９へ進む。
ステップＳ１００９では、バッチ処理部３１４は、対象デバイスリストの次のデバイスに進み、ステップＳ１００４からの処理を繰り返す。
【００４３】
図７は、図６におけるステップＳ１００１の詳細を示すフローチャートである。
ステップＳ１１００において、バッチ処理部３１４は、処理を開始する。
バッチ処理部３１４は、ステップＳ１１０１から開始する繰り返し処理によって、更新可能バージョン管理テーブル３３３の行（レコード）を順にチェックする。より具体的には次から述べる処理を行う。
ステップＳ１１０２では、バッチ処理部３１４は、「追加」又は「削除」の列がセットされているか否かで処理を分岐する。バッチ処理部３１４は、「追加」、「削除」の何れかのフラグがセットされている場合（Ｓ１１０２でＹｅｓ）、ステップＳ１１０３へ進む。一方、バッチ処理部３１４は、「追加」、「削除」の何れのフラグもセットされていない場合（Ｓ１１０２でＮｏ）、ステップＳ１１０５へ進み、次の行のチェックを行う。
ステップＳ１１０３では、バッチ処理部３１４は、対象行の「追加」フラグをリセットする。また、バッチ処理部３１４は、「削除」フラグがセットされている場合には、対象行を削除する。なお、バッチ処理部３１４は、対象行を削除してもここで対象としているモデル識別ＩＤは、次の処理のために記憶しておく。
【００４４】
ステップＳ１１０４では、バッチ処理部３１４は、対象行の「モデル識別ＩＤ」の値を抽出リスト（Ｍ＿ＬＩＳＴ）に追加する。なお、バッチ処理部３１４は、抽出リスト内でモデル識別ＩＤが重複する場合には、重複分を削除しておくものとする。
ステップＳ１１０５では、バッチ処理部３１４は、更新可能バージョン管理テーブル３３３を全てチェックしたかを判断する。バッチ処理部３１４は、全ての行をチェックした場合（Ｓ１１０５でＹｅｓ）には、次の処理（ステップＳ１１０７）へ進む。一方、バッチ処理部３１４は、チェックする対象行が残っている場合（Ｓ１１０５でＮｏ）、ステップＳ１１０６へ進む。
ステップＳ１１０６では、バッチ処理部３１４は、更新可能バージョン管理テーブル３３３の次の行へ進み、ステップＳ１１０２からの処理を繰り返す。
【００４５】
次に、バッチ処理部３１４は、ステップＳ１１０７から開始する繰り返し処理によって、ファームウェアグループ管理テーブル３３２の行を順にチェックする。より具体的には次から述べる処理を行う。
ステップＳ１１０８では、バッチ処理部３１４は、「更新」又は「削除」の列がセットされているか否かで処理を分岐する。バッチ処理部３１４は、「更新」、「削除」の何れかのフラグがセットされている場合（Ｓ１１０８でＹｅｓ）、ステップＳ１１０９へ進む。一方、バッチ処理部３１４は、「更新」、「削除」の何れのフラグもセットされていない場合（Ｓ１１０８でＮｏ）、ステップＳ１１１１へ進み、次の行のチェックを行う。
ステップＳ１１０９では、バッチ処理部３１４は、対象行の「更新」フラグをリセットする。また、バッチ処理部３１４は、「削除」フラグがセットされている場合には、対象行を削除する。なお、バッチ処理部３１４は、対象行を削除してもここで対象としているモデル識別ＩＤは、次の処理のために記憶しておく。
ステップＳ１１１０では、バッチ処理部３１４は、対象行の「モデル識別ＩＤ」の値を抽出リスト（Ｍ＿ＬＩＳＴ）に追加する。なお、バッチ処理部３１４は、抽出リスト内でモデル識別ＩＤが重複する場合には、重複分を削除しておくものとする。
【００４６】
ステップＳ１１１１では、バッチ処理部３１４は、ファームウェアグループ管理テーブル３３２を全てチェックしたかを判断する。バッチ処理部３１４は、全ての行をチェックした場合（Ｓ１１１１でＹｅｓ）、ステップＳ１１１３へ進み処理を終了する。一方、バッチ処理部３１４は、チェックする対象の行が残っている場合（Ｓ１１１１でＮｏ）、ステップＳ１１１２へ進む。
ステップＳ１１１２では、バッチ処理部３１４は、ファームウェアグループ管理テーブル３３２の次の行へ進み、ステップＳ１１０８からの処理を繰り返す。
ステップＳ１１１３では、バッチ処理部３１４は、処理を終了し、この時点での結果を図６のステップＳ１００１の処理における抽出リスト（Ｍ＿ＬＩＳＴ）とする。
【００４７】
図８は、ステップＳ１００２の詳細を示すフローチャートである。
ステップＳ１２００から、バッチ処理部３１４は、前の処理結果であるＭ＿ＬＩＳＴを受けて、図８に示す処理を開始する。
バッチ処理部３１４は、ステップＳ１２０１から開始する繰り返し処理によって、デバイスモデル管理テーブル３３１の行を順にチェックする。より具体的には次から述べる処理を行う。
ステップＳ１２０２では、バッチ処理部３１４は、「更新」又は「削除」の列がセットされているか否かで処理を分岐する。バッチ処理部３１４は、「更新」、「削除」何れかのフラグがセットされている場合（ステップＳ１２０２でＹｅｓ）、ステップＳ１２０３へ進む。バッチ処理部３１４は、何れのフラグもセットされていない場合（ステップＳ１２０２でＮｏ）、ステップＳ１２０４へ進む。
ステップＳ１２０３では、バッチ処理部３１４は、対象行の「更新」フラグをリセットする。また、バッチ処理部３１４は、「削除」フラグがセットされている場合には、対象行を削除する。なお、バッチ処理部３１４は、対象行を削除してもここで対象としている「デバイスＩＤ開始」と「デバイスＩＤ終了」との値は、次の処理のために記憶しておく。
【００４８】
ステップＳ１２０４では、バッチ処理部３１４は、対象行の「モデル識別ＩＤ」がＭ＿ＬＩＳＴに含まれているか否かで処理を分岐する。バッチ処理部３１４は、対象行の「モデル識別ＩＤ」がＭ＿ＬＩＳＴに含まれている場合（ステップＳ１２０４でＹｅｓ）、ステップＳ１２０５へ進む。一方、バッチ処理部３１４は、対象行の「モデル識別ＩＤ」がＭ＿ＬＩＳＴに含まれていない場合（ステップＳ１２０４でＮｏ）、ステップＳ１２０７へ進み、次の行のチェックを行う。
ステップＳ１２０５では、バッチ処理部３１４は、対象行の「デバイスＩＤ開始」と「デバイスＩＤ終了」とからデバイスＩＤの範囲を決定する。そして、バッチ処理部３１４は、更に決定した範囲でデバイス配信状態テーブル３３４の「デバイスＩＤ」に登録されているデバイスをリストとして抽出する。この際、バッチ処理部３１４は、デバイス配信状態テーブル３３４における対象デバイスの「バッチ対象」フラグをセットする。
ステップＳ１２０６では、バッチ処理部３１４は、ステップ１２０５で抽出したデバイスＩＤのリストを抽出リスト（Ｄ＿ＬＩＳＴ）に追加する。
【００４９】
ステップＳ１２０７では、バッチ処理部３１４は、デバイスモデル管理テーブル３３１を全てチェックしたかを判断する。バッチ処理部３１４は、全ての行をチェックした場合（ステップＳ１２０７でＹｅｓ）、ステップＳ１２０９へ進み処理を終了する。バッチ処理部３１４は、チェックする対象行が残っている場合（ステップＳ１２０７でＮｏ）、ステップＳ１２０８へ進む。
ステップＳ１２０８では、バッチ処理部３１４は、デバイスモデル管理テーブル３３１の次の行へ進み、ステップＳ１２０２からの処理を繰り返す。
ステップＳ１２０９では、バッチ処理部３１４は、図８に示す処理を終了し、この時点での結果を図６のステップＳ１００２の処理における抽出リスト（Ｄ＿ＬＩＳＴ）とする。
【００５０】
図９は、バージョン情報返却処理部３１５で処理される、図４におけるＳＣ４１１、ＳＣ４１２、図５におけるＳＣ４７１、ＳＣ４７２の処理を示すフローチャートである。
バージョン情報返却処理部３１５は、図４におけるＳＣ４１１又は図５におけるＳＣ４７１に示すリクエストがあった場合、ステップＳ１３００からの処理を開始する。
ステップＳ１３０１では、バージョン情報返却処理部３１５は、図４におけるＳＣ４１１又は図５におけるＳＣ４７１でデバイスから送信される情報を受信する。
ステップＳ１３０２では、バージョン情報返却処理部３１５は、リクエストの更新種別が定期アップデートであるか否かによって処理を分岐する。バージョン情報返却処理部３１５は、定期アップデートの場合（Ｓ１３０２でＹｅｓ）、ステップＳ１３０３へ進む。一方、バージョン情報返却処理部３１５は、定期アップデートでない場合（Ｓ１３０２でＮｏ）、つまり手動更新又は日時指定更新の場合、ステップＳ１３０９へ進む。
ステップＳ１３０２の判断の処理は、更新種別判断処理の一例である。
ステップＳ１３０３では、バージョン情報返却処理部３１５は、デバイスファームウェア管理テーブル３３５に残るファームウェアバージョン情報とデバイスから送信されたファームウェアバージョン情報とを比較する。
ステップＳ１３０４では、バージョン情報返却処理部３１５は、ファームウェアバージョン情報の比較結果によって処理を分岐する。バージョン情報返却処理部３１５は、ファームウェアバージョン情報が一致する場合（ステップＳ１３０４でＹｅｓ）、ステップＳ１３０５へ進む。一方、バージョン情報返却処理部３１５は、ファームウェアバージョン情報が一致しない場合（ステップＳ１３０４でＮｏ）、ステップＳ１３０９へ進む。
【００５１】
ステップＳ１３０５では、バージョン情報返却処理部３１５は、リクエストを受信したデバイスのデバイスＩＤがバッチで求めたＤ＿ＬＩＳＴに含まれるか否かによって処理を分岐する。バージョン情報返却処理部３１５は、デバイスＩＤがバッチで求めたＤ＿ＬＩＳＴに含まれない場合（ステップＳ１３０５でＮｏ）、ステップＳ１３０８へ進む。ステップＳ１３０８では、バージョン情報返却処理部３１５は、更新可能バージョン無しとする。そして、バージョン情報返却処理部３１５は、ステップＳ１３１７に処理を進める。一方、バージョン情報返却処理部３１５は、デバイスＩＤがバッチで求めたＤ＿ＬＩＳＴに含まれ含まれる場合（ステップＳ１３０５でＹｅｓ）、ステップＳ１３０６へ進む。
ステップＳ１３０６では、バージョン情報返却処理部３１５は、予めバッチで求めた最新のファームウェアグループバージョン情報（デバイス配信状態テーブル３３４の「ＶＥＲ」の値に対応）に更新バージョン情報があるか否かによって処理を分岐する。バージョン情報返却処理部３１５は、更新バージョン情報の有無を、更新可能バージョン管理テーブル３３３から判断する。バージョン情報返却処理部３１５は、更新バージョン情報がある場合（Ｓ１３０６でＹｅｓ）、ステップＳ１３０８へ進む。ステップＳ１３０８では、バージョン情報返却処理部３１５は、更新可能バージョン情報無しとして、リクエストの応答として返却する。そして、バージョン情報返却処理部３１５は、ステップＳ１３１７に処理を進める。一方、バージョン情報返却処理部３１５は、更新バージョン情報が無い場合（Ｓ１３０６でＮｏ）、ステップＳ１３０７へ進む。
【００５２】
ステップＳ１３０７では、バージョン情報返却処理部３１５は、デバイス配信状態テーブル３３４の「更新タイプ」を「定期アップデート」に設定し、デバイス配信状態テーブル３３４の「ＶＥＲ」の値に対応する最新バージョン情報を、リクエストの応答として返却する。
ステップＳ１３０９では、バージョン情報返却処理部３１５は、デバイスから送信されたファームウェアバージョン情報に一致するファームウェアグループバージョン情報をファームウェアグループ管理テーブル３３２から探し出す。この処理は、表Ｃの中から、例えて言えば表Ａの組合せを探し出す作業に相当する。デバイスにインストールされている表Ａの各モジュールの各バージョン情報が全て一致するファームウェアグループバージョン情報を探し出さなければならない。従来技術におけるバージョン情報の問い合わせに対する処理は、全ての問い合わせに対して、この処理を行っていたため、上述した課題の原因となっていた。本実施形態においては、ステップＳ１３０２とＳ１３０４とで絞り込まれた一部のデバイスからの問い合わせに対してのみステップＳ１３０９の処理が実行される。このため、問い合わせ処理、即ち図４におけるＳＣ４１１、ＳＣ４１２、図５におけるＳＣ４７１、ＳＣ４７２の処理の効率化が図られる。
【００５３】
ステップＳ１３１０では、バージョン情報返却処理部３１５は、デバイスから送信されたファームウェアバージョン情報からファームウェアグループバージョン情報を特定できたか否かで処理を分岐する。バージョン情報返却処理部３１５は、ファームウェアバージョン情報からファームウェアグループバージョン情報を特定できた場合（ステップＳ１３１０でＹｅｓ）、ステップＳ１３１１へ進む。一方、バージョン情報返却処理部３１５は、ファームウェアバージョン情報からファームウェアグループバージョン情報を特定できなかった場合（ステップＳ１３１０でＮｏ）、ステップＳ１３０８へ進む。ステップＳ１３０８では、バージョン情報返却処理部３１５は、更新可能バージョン情報無しとする。そして、バージョン情報返却処理部３１５は、ステップＳ１３１７に処理を進める。
ステップＳ１３１１では、バージョン情報返却処理部３１５は、リクエストの更新種別が手動更新であるか否かで処理を分岐する。バージョン情報返却処理部３１５は、リクエストの更新種別が手動更新である場合（ステップＳ１３１１でＹｅｓ）、ステップＳ１３１２へ進む。一方、バージョン情報返却処理部３１５は、リクエストの更新種別が手動更新でない場合（ステップＳ１３１１でＮｏ）、つまり定期アップデート又は日時指定更新の場合、ステップＳ１３１４へ進む。
ステップＳ１３１２では、バージョン情報返却処理部３１５は、更新可能バージョン管理テーブル３３３から、更新可能なバージョン情報一覧を検索する。
ステップＳ１３１３では、バージョン情報返却処理部３１５は、デバイス配信状態テーブル３３４の「更新タイプ」を「手動更新」に設定し、検索結果のバージョン情報一覧を、リクエストの応答として返却する。そして、バージョン情報返却処理部３１５は、ステップＳ１３１７に処理を進める。
【００５４】
ステップＳ１３１４では、バージョン情報返却処理部３１５は、ステップＳ１３０９で特定したファームウェアグループバージョン情報及びモデル識別ＩＤに基づき更新可能バージョン管理テーブル３３３から、更新可能な最新バージョン情報を検索する。
ステップＳ１３１５では、バージョン情報返却処理部３１５は、最新バージョン情報の有無によって処理を分岐する。バージョン情報返却処理部３１５は、更新可能な最新バージョン情報が存在した場合（ステップＳ１３１５でＹｅｓ）、ステップＳ１３１６へ進む。更新可能な最新バージョン情報が存在しない場合（ステップＳ１３１５でＮｏ）、ステップＳ１３０８へ進む。ステップＳ１３０８では、バージョン情報返却処理部３１５は、更新可能バージョン情報無しとする。そして、バージョン情報返却処理部３１５は、ステップＳ１３１７に処理を進める。
ステップＳ１３１６では、バージョン情報返却処理部３１５は、デバイス配信状態テーブル３３４の「更新タイプ」にリクエストの更新種別に従って、日時指定又は定期アップデートの値をセットし、検索結果のバージョン情報を、リクエストの応答として返却する。
ステップＳ１３１７では、バージョン情報返却処理部３１５は、バージョン情報返却処理を終了する。
【００５５】
図１０は、ファームウェア返却処理部３１６で処理される、図４におけるＳＣ４１５、ＳＣ４１６、図５におけるＳＣ４７３、ＳＣ４７４の処理を示すフローチャートである。
ファームウェア返却処理部３１６は、図４におけるＳＣ４１５又は図５におけるＳＣ４７３に示すリクエストがあった場合、ステップＳ１４００からの処理を開始する。
ステップＳ１４０１では、ファームウェア返却処理部３１６は、図４におけるＳＣ４１５又は図５におけるＳＣ４７３でデバイスから送信される情報を受信する。受信する情報は、モデル識別ＩＤ、デバイスＩＤ、ファームウェアグループバージョン情報である。
ステップＳ１４０２では、ファームウェア返却処理部３１６は、ファームウェアグループ管理テーブル３３２から、モデル識別ＩＤ及びファームウェアグループバージョン情報で検索を実行し、モジュール一式のＵＲＬリストを取得する。
ステップＳ１４０３では、ファームウェア返却処理部３１６は、検索結果のＵＲＬリストを一つ又は複数、返却する。この処理は、図４におけるＳＣ４１６又は図５におけるＳＣ４７４に対応する。また、ファームウェア返却処理部３１６は、同時にデバイス配信状態テーブル３３４のデバイスＩＤに対応する「配信日時」を現在日時で更新する。また、ファームウェア返却処理部３１６は、デバイスＩＤに対応する、「バッチ対象」、「ＶＥＲ」、をクリアする。
ステップＳ１４０４で、ファームウェア返却処理部３１６は、図１０に示す処理を終了する。
【００５６】
図１１は、更新情報記録処理部３１７で処理される、図４におけるＳＣ４２０、図５におけるＳＣ４７８の処理を示すフローチャートである。
更新情報記録処理部３１７は、図４におけるＳＣ４２０又は図５におけるＳＣ４７８に示す通知があった場合、ステップＳ１５００からの処理を開始する。
ステップＳ１５０１では、更新情報記録処理部３１７は、図４におけるＳＣ４２０又は図５におけるＳＣ４７８でデバイスから送信される情報を受信する。受信する情報は、デバイスＩＤとデバイスにインストールされたファームウェアバージョン情報とである。
ステップＳ１５０２では、更新情報記録処理部３１７は、受信したデバイスＩＤとファームウェアバージョン情報とで、デバイスファームウェア管理テーブル３３５を更新する。更に、更新情報記録処理部３１７は、デバイスＩＤに対応するデバイス配信状態テーブル３３４における「更新日時」を現在日時で更新する。また、更新情報記録処理部３１７は、「配信日時」から「更新日時」までが所定時間（例えば２時間等）を超える場合には、「更新タイプ」をリセットする。
ステップＳ１５０３では、更新情報記録処理部３１７は、図１１に示す処理を終了する。
【００５７】
図１２は、配信設定確認処理部３１８で処理される、図５におけるＳＣ４６０、ＳＣ４６１の処理を示すフローチャートである。
配信設定確認処理部３１８は、図５におけるＳＣ４６０に示すリクエストがあった場合、ステップＳ１６００からの処理を開始する。
ステップＳ１６０１では、配信設定確認処理部３１８は、図５における４６０でデバイスから送信される情報を受信する。受信する情報は、デバイスＩＤである。
ステップＳ１６０２では、配信設定確認処理部３１８は、デバイス配信状態テーブル３３４から、デバイスＩＤに対応する「配信予定日時」、「定期曜日」、「定期時間」を検索する。
ステップＳ１６０３では、配信設定確認処理部３１８は、検索した結果の配信設定情報をデバイスへ返却する。ステップＳ１６０３の処理は、図５におけるＳＣ４６１の処理に対応する。
ステップＳ１６０４では、配信設定確認処理部３１８は、図１２に示す処理を終了する。
【００５８】
図１３は、配信設定処理部３１９で処理される、図５におけるＳＣ４５１、ＳＣ４５２の処理を示すフローチャートである。
配信設定処理部３１９は、図５におけるＳＣ４５１に示すリクエストがあった場合、ステップＳ１７００からの処理を開始する。
ステップＳ１７０１では、配信設定処理部３１９は、図５におけるＳＣ４５１でデバイスから送信される情報を受信する。受信する情報は、デバイスＩＤ、配信予定日時、定期曜日、定期時間である。
ステップＳ１７０２では、配信設定処理部３１９は、受信した情報からデバイスＩＤに対応するデバイス配信状態テーブル３３４の「配信予定日時」、「定期曜日」、「定期時間」を更新する。
ステップＳ１７０３では、配信設定処理部３１９は、設定結果をデバイスへ返却する。返却内容は設定内容と同じである。
ステップＳ１７０４では、配信設定処理部３１９は、図１３に示す処理を終了する。
【００５９】
配信システム１０は、曜日及び時間帯で、アクセスの負荷が異なるため、バッチ処理は負荷の低い時間帯で実施する方が効率的である。そこで、負荷の低い時間帯に起動するようにバッチ起動スケジュールを制御するため、配信システム１０は、負荷の高低を知るための負荷状況テーブルを持つ。
表Ｇに、配信システム１０が管理する負荷状況テーブル３３６の例を示す。
【００６０】
【表７】
2016110222.tif 000009
【００６１】
表Ｇにおいて、列方向は、１日を１時間単位で区切って、２４個の時間帯を表している。行方向は、曜日毎の負荷を表している。曜日と時間との組合せ毎に三段階で示す負荷状況が記憶される。「Ｈ」は高負荷を表し、最も負荷が高いことを表す。「Ｌ」は低負荷を表し、最も負荷が低いことを表す。「Ｍ」は中負荷を表し、中程度の負荷であることを表す。また、「Ｍ＊」や「Ｌ＊」のように「＊」がついている時間帯はバッチ処理が起動される時間帯を表している。バッチ起動の時間帯は、基本的には６時間毎の０時、６時、１２時、１８時、が定時と設定されている。但し、配信システム１０は、定時が高負荷時間帯（「Ｈ」）である場合や、中負荷（「Ｍ」）でもより負荷の低い低負荷時間帯がある場合には、定時からずらした時間帯をバッチ処理の起動タイミングとする。
バッチ処理の起動は、負荷状況テーブル３３６の起動タイミングで実行される。
配信システム１０は、管理者等により手動での設定、更新操作に基づき、負荷状況テーブル３３６を設定、更新してもよいし、監視機能等によって計測された配信システム１０の負荷状況に基づき、負荷状況テーブル３３６を設定、更新してもよい。
本実施形態においては、負荷状況テーブル３３６は予め表Ｇに示す内容のように設定されているものとする。
【００６２】
以上述べた処理により、定期アップデートの設定がなされているデバイスを対象として、予め更新するファームウェアの特定を実行しておくことで、バージョン情報の問い合わせに対して比較による検索処理を実施するデバイスを減らすことができる。これにより、問い合わせ処理の負荷が軽減し、バージョン情報の問い合わせ処理のパフォーマンスが向上する。結果、対象デバイスとファームウェアを構成するモジュール数が増えても、デバイスのファームウェア更新サービスを正常に維持することができる。
ここで、本実施形態における定期アップデートとは、近い過去（定期アップデートの周期内）自動配信による更新があり、かつ、近い未来（定期アップデートの周期内）配信（更新）リクエストを送る設定になっていることを意味するものである。したがって、定期アップデートの設定は、必ずしも設定の周期性に限定するものではなく、複数の自動配信スケジュールの設定に従って、十分短い期間で配信が行われる場合にも有効である。
【００６３】
＜その他の実施形態＞
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読み出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
【００６４】
以上、上述した各実施形態によればデバイスからのファームウェア等のソフトウェアのバージョン情報の更新の問い合わせ処理を効率化することができる。
【符号の説明】
【００６５】
１０  配信システム、２０  コンテンツサーバ、２０１  ＣＰＵ、２０６  ＨＤＤ、４００  デバイス
【図１】
2016110222.tif 000010
【図２】
2016110222.tif 000011
【図３】
2016110222.tif 000012
【図４】
2016110222.tif 000013
【図５】
2016110222.tif 000014
【図６】
2016110222.tif 000015
【図７】
2016110222.tif 000016
【図８】
2016110222.tif 000017
【図９】
2016110222.tif 000018
【図１０】
2016110222.tif 000019
【図１１】
2016110222.tif 000020
【図１２】
2016110222.tif 000021
【図１３】
2016110222.tif 000022