JP2018190341A

JP2018190341A - システム及び配信方法

Info

Publication number: JP2018190341A
Application number: JP2017094880A
Authority: JP
Inventors: 慶諾大嶋; Keita Oshima
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2017-05-11
Filing date: 2017-05-11
Publication date: 2018-11-29

Abstract

【課題】デバイスのソフトウェアを更新する際のサーバの負荷を低減できる配信システムを提供する。【解決手段】配信システムは、ソフトウェア配信とは非同期に、予めファームウェアとアプリケーションのバージョン依存関係を考慮して、各デバイスに配信する予定のファームウェアとアプリケーションの適切なバージョンの組合せを求めておく。自動更新時に、デバイスから現在のファームウェアバージョンを受信し、予め求めておいたファームウェアとアプリケーションの適切なバージョンの組合せにより配信する。【選択図】図５

Description

本発明は、デバイス等のクライアントにインストールされるソフトウェアを管理して配信するシステム及び配信方法に関する

複合機等のデバイスにおいては、デバイス本来の組み込み機能を実現するためのファームウェアと、利用者毎に後からインストールして使用するアプリケーションという二種類のソフトウェアが利用可能である。通常、アプリケーションは、利用者によって選択され、インストール、起動される。アプリケーションには、利用するために追加の利用料金（ライセンス）が必要な場合もある。

ところで、ファームウェアおよびアプリケーション（まとめてソフトウェアと呼ぶ。）は、不具合の修正や機能拡張のためにバージョンアップが実施される場合がある。そして、バージョンアップでは、ファームウェアだけでなく、アプリケーションであっても、デバイスの製造元あるいは販売者によってバージョンアップ版のインストールが行われる場合もある。さらに、ソフトウェアのインストールあるいはバージョンアップ版ソフトウェアへの更新において、デバイスをネットワーク経由で配信サーバに接続し、デバイスに対して遠隔地からのソフトウェア配信も行われている。

一般的にPCや携帯端末などでは、クライアントから自動で定期的に配信サーバに問い合わせてソフトウェアのバージョンアップを行う仕組みが提供されている。これらのクライアントにおいて、配信サーバへの問い合わせおよびバージョンアップのタイミングは、クライアント側の設定をする利用者が常時存在することから、比較的自由なタイミングを選ぶことが出来る。

複合機等のデバイスにおいても、同様の自動バージョンアップを行う仕組みの要求が存在する。しかしながら、オフィス等の中で不特定多数のユーザが利用する一方、そのデバイスの管理者は遠隔地にいることが多い。したがって、これらのデバイスの特徴として、自動バージョンアップが可能なタイミングはどのデバイスにおいても高々一種類である。すなわち、そのデバイスを利用するオフィス業務が休みとなるタイミングである。これは、週の特定曜日のその地域における深夜、多くの業態では、週末の深夜に限られる。このため、各デバイスのファームウェアおよびデバイス上で動作しているアプリケーションの自動バージョンアップは、この限られたタイミングでまとめて実施する必要がある。

ところで、デバイスで動作するアプリケーションのバージョンは、そのプラットフォームの一部を構成するファームウェアのバージョンに依存する場合がある。例えば、ファームウェアのバージョンアップ前に更新が必要なアプリケーションのバージョンや、あるバージョンのアプリケーションの動作に必要なファームウェアのバージョンが限定されている場合などである。例えば、特許文献１のように、インストール情報を送信して複数のアップデートデータを取得するとともにアップデートの順序を示す順序情報を取得する管理装置が提案されている。ここでの配信サーバは、複数ソフトウェア間のバージョンに依らず整合性がある場合にはアップデート順序を指定しない順序情報を生成し、バージョンに依り整合性が無い場合にはアップデート順序を指定する順序情報を生成する。

特許第5293522号公報

デバイスの利用者は、全てのアプリケーションを常に最新に維持することを望むとは限らない。利用者個々の事情で、特定のバージョンを使い続けたい場合がある。また、デバイスやアプリケーションの販売者側の観点でも、セキュリティ対策、緊急障害対応等、サービスマンの判断で配信するものに限定してアプリケーションのバージョンアップを行う場合がある。

このため、配信するアプリケーションとバージョンの判断、すなわち更新対象のアプリケーションの特定とそのバージョンの特定とをデバイス毎に行う必要がある。この判断には、ファームウェアのバージョンアップ判定、アプリケーション毎のバージョンアップ判定、ファームウェアのバージョンに依存するアプリケーションのバージョンアップ判定、の三つが必要である。

しかしながら、上述の通り、限られた一つのタイミングで、この三つの判定を同時に実施すると、配信処理時のサーバ負荷が大きくなる。

本発明は上記従来例に鑑みて成されたもので、デバイスのソフトウェアを更新する際のサーバの負荷を低減することができるソフトウェアシステム及び方法を提供することを目的とする。

上記目的を達成するために本発明は以下の構成を有する。

複数のデバイスと配信システムとを含むシステムであって、
前記配信システムは、
デバイスにインストールされているファームウェア及びアプリケーションのバージョン情報と、前記ファームウェア及びアプリケーションの更新予定のバージョン情報とを、デバイスＩＤごとに管理する管理手段と、
前記デバイスからの該デバイスのデバイスＩＤと該デバイスにインストールされているアプリケーションのバージョン情報を含む更新通知の受信に応じて、前記管理手段により管理される前記デバイスにインストールされているアプリケーションのバージョン情報を更新し、さらに、前記管理手段により管理された前記ファームウェア及びアプリケーションの更新予定のバージョン情報の更新を行う更新手段と、
前記デバイスから、該デバイスのデバイスＩＤと該デバイスにインストールされているファームウェアのバージョン情報とを含む、ファームウェアの更新の確認要求を受信する受信手段と、
前記受信手段により受信した前記確認要求に含まれる情報が示す前記ファームウェアのバージョン情報に基づいて該ファームウェアの更新予定のバージョン情報を特定し、さらに、前記管理手段で前記確認要求に含まれるデバイスＩＤに対応する前記アプリケーションについての更新予定が既に管理されていた際には、当該更新予定に基づいて、前記デバイスにインストールされているアプリケーションについての更新予定のバージョン情報の特定を行う特定手段と、
特定された前記ファームウェアの更新予定のバージョン情報と前記アプリケーションの更新予定のバージョン情報とを前記確認要求への応答として、前記デバイスに送信する応答手段と、を有し、
前記デバイスでは、前記応答に従い前記ファームウェア及びアプリケーションが更新され、当該アプリケーションの更新に応じてデバイスＩＤと更新後のアプリケーションのバージョン情報を含む更新通知が前記配信システムに送信されることを特徴とするシステム。

本発明によれば、デバイスのソフトウェアを更新する際のサーバの負荷を低減することができる。

システム構成図サーバのハードウェア構成を示す図配信システム及びデバイスの機能ブロック図アプリケーション及びFWのインストールにおけるシーケンス例を示す図アプリケーション及びFWの自動更新におけるシーケンス例を示す図アプリケーション更新通知受信時処理を示すフローチャート更新予定バージョン情報更新のフローチャート更新するファームウェアバージョン判断のフローチャート更新するアプリケーションバージョン判断のフローチャート自動更新問い合わせ受信時処理を示すフローチャート更新予定バージョン情報更新バッチ処理のフローチャートアプリケーション及びFWのユーザモード更新におけるシーケンス例を示す図

●システム構成
図１は、本実施例のシステム構成図を示すブロック図である。配信システム１０は、Webサーバ１２、DBサーバ１３及びアプリケーションサーバ１１から成る。そして、インターネット１００に接続されたWebサーバ１２を介して、各顧客企業１１４、１１９、１２９のデバイス１１５〜１１６、１２０、１２１、１２４〜１２７、１３１と通信を行う。これにより、アプリケーションプログラム（以後「アプリ」と略記）及びファームウェア（以後「FW」と略記）の配信制御を行う。なおアプリケーションプログラムとファームウェアとを併せてソフトウェアと呼ぶこともある。アプリ及びFWの実ファイルはコンテンツサーバ２０にあり、デバイスへアプリをインストールする場合には、配信システム１０がコンテンツサーバ２０上の実ファイルの位置情報を取得し、コンテンツサーバからソフトウェアを配信先の例えばデバイスやパーソナルコンピュータ等にダウンロードする。各顧客サイトにおいては、パーソナルコンピュータ１１７，１２２，１２３およびＬＡＮ１１８，１２８を介して、あるいはＬＡＮ１３０を介して、ソフトウェアのファイルがデバイスに配信されて、ソフトウェアが更新される。これにより、多くのデバイスのソフトウェア配信の負荷を分散し効率良くソフトウェアの配信を行うことが出来る。アプリ及びFWそれぞれの更新も同様である。コンテンツサーバ２０は、コンテンツ管理サーバ２１およびファイル・ストレージ２２、２３から成る。コンテンツ管理サーバ２１は、外部からのリクエストに従って、ファイル・コンテンツすなわちアプリ及びFWを保存、あるいは提供する。

デバイスには、マルチ・ファンクション・プリンタ（MFP）や、シングル・ファンクション・プリンタ（SFP）等の種類があり、デバイスのモデル毎に一つあるいは複数の機能が搭載されている。それらの機能を実現するためのFWがインストールされることにより、デバイスの各機能が利用可能となる。また、デバイスのモデル毎、あるいは、デバイスのモデルに共通で実行可能なアプリをインストールして実行することが可能である。デバイスの利用者は、そのデバイスで利用可能な複数のアプリの中から、所望のものを選び、購入するなどして入手することにより、インストールを行う。また、デバイスのアプリの不具合が修正された場合や機能の改善あるいは追加された場合には、アプリを更新することで、それらを利用することが出来る。アプリは、デバイスが配信システム１０と通信することにより、コンテンツをダウンロードしてインストールあるいは更新することが出来る。なおネットワークに接続されたデバイスを、ネットワークデバイス或いはネットワーク機器と呼ぶことがある。販売会社システム３０は、デバイスを各顧客企業１１４、１１９、１２９へ販売し、維持、管理するデバイスの製造会社あるいはデバイスの販売会社がアプリ及びFWの登録・管理のための操作をする。販売会社システム３０は、１台以上のPC３１、３２あるいはサーバ３３、３４から成る。販売会社システム３０から配信システム１０およびコンテンツサーバ２０へアクセスすることにより、アプリ及びFWの登録と配信設定を行う。また、デバイスには、ファームウェアおよびアプリの自動更新を行うための仕組みが有り、定期的に配信システム１０へ更新情報を確認する日時を設定できるようになっている。

●サーバの構成
図２は、本実施例のハードウェア構成を示すブロック図である。本実施例におけるアプリケーションサーバ１１は、ネットワークインタフェース２０４を介して、Webサーバ１２やDBサーバ１３と互いに接続されている。アプリケーションサーバ１１は、バス２０５を介して接続されたCPU２０１、RAM２０２、ROM２０３、ネットワークインタフェース２０４、HDD２０６などから成る。配信システム１０はHDD２０６あるいはROM２０３、RAM２０２に記録されたデータ及びプログラムを読み出してCPU２０１で実行することにより実現される。また、その機能は、複数のサーバの機能の連携によって実現される場合もある。ネットワークインタフェース２０４は、配信システム１０内のサーバ間の機能連携に使われると共に、インターネット１００を介して、外部システムと通信するためにも使用される。なお、図２はアプリケーションサーバ１１に対応して図示しているが、他のサーバやデバイスも同様のハードウェア構成を持っているものとする。

●配信システムの機能構成
図３は、本実施例における配信システム１０およびデバイスの機能構成を示すブロック図である。Ｗｅｂブラウザ３０２は、配信システム１０に接続する販売会社システムのクライアントシステムであるWebブラウザを示す。したがってＷｅｂブラウザ３０２は配信システム１０には含まれない。なお以下の説明では、配信システム１０を配信サーバと呼び、デバイスを含めたソフトウェア配信システムと区別することがある。

Ｗｅｂインターフェース部３１０は、デバイスに対するアプリ及びFWの配信機能を提供する。Webインターフェース部３１０は、各デバイスから各種リクエストを受信し、処理結果を返却する。例えば、アプリ配送情報のリクエストを受信すると、対象とするアプリの格納されている場所を検索し、アプリを取得するためのURLとして返却する。リクエスト処理の詳細については、後述する。
ユーザインターフェース部３１１は、配信システムにアクセスして、アプリ及びFWの登録や配信設定、定期アップデート設定を行う。
リクエスト受信部３１２は、デバイスからのリクエストを受信する。
レスポンス返信部３１３は、デバイスへレスポンスを返す。
配信設定制御部３１４は、FWおよびアプリの配信設定を制御する。
バッチ処理部３１５は、管理情報の非同期更新を行う。
３１７は、デバイスへの配信に伴う制御を行う配信制御部である。
スケジューラ３１８は、バッチ処理を定時起動する。

DBアクセス部３２０は、各種処理に応じて、データ管理部３３０で管理されているテーブルのデータを更新あるいは検索する。データ管理部３３０で管理されているテーブルには以下のものが含まれる。各テーブルについては追って説明する。
アプリ情報管理テーブル３３１
登録アプリ管理テーブル３３２
アプリバージョン管理テーブル３３３
登録ファームウェア管理テーブル３３４
ファームウェアバージョン管理テーブル３３５
バージョン制限管理テーブル３３６
デバイス管理テーブル３３７
更新予定バージョン管理テーブル３３８。

一方、デバイス４００は以下の構成を有する。なおここでいう構成は、ソフトウェアの新規或いは更新インストールを行うための構成であり、複写等、デバイスとしての機能を果たすための構成については省略した。メイン処理部３４０は、デバイス４００の本来の機能を実行する。メイン処理部３４０は、例えば、プリンターであれば画像形成処理を行う等の主機能を果たす。デバイス４００は、この主機能の他に、デバイスのFWおよびアプリの配信制御を行うための機能も備えている。それが、機能ブロック３４１から３４８である。ここでいう配信制御は、たとえば指定された時期に更新をチェックし、ダウンロードされるソフトウェアを受信し、更新するといった手順を含んでよい。
Webインターフェース部３４１は、配信システム１０からアプリ及びFWの配信を受け、配信システム１０のWebインターフェース３１０と例えばＨＴＴＰを用いて接続されている。
配信処理部３４２は、例えば、販売会社システム３０により別途指定された時期（曜日や時刻等）であることをチェックする。また例えば、指定時期に至るとＷｅｂインターフェース部３４１を介して配信サーバ１０にファームウェアの更新の有無を照会することなどを行うことができる。
アプリインストール部３４３は、ダウンロードされたインストールすべきアプリケーションをインストールする。
アプリ更新部３４４は、ダウンロードされた更新すべきアプリケーションを更新する。
FW更新部３４５は、ダウンロードされた更新すべきファームウェアを更新する。
ＦＷ格納部３４７は、配信されたFWを格納する。
アプリ格納部３４８は、配信されたアプリを格納する。

●手動更新処理のシーケンス例
図４は、デバイスにおいて、デバイスの利用者によるアプリのインストール、あるいは、サービスマンによるファームウェアのインストール、のデバイス操作を実施する時の流れの例を示すシーケンス図である。

利用者４０１は、新しいアプリをデバイス４００へインストールするために、デバイス４００のユーザインターフェースを操作し、アプリのインストール指示４１０を出す。
指示４１０に対応して、デバイス４００は、インストールするアプリを特定する情報であるアプリ配送情報要求４１１を配信システム１０へ送り、対応するアプリを特定するアプリ情報を要求する。これに対して、配信システム１０は、デバイス４００からのリクエストをWebインターフェース部３１０で処理する。配信システム１０は、アプリ配送情報要求４１１指定された情報（アプリ）に従って、インストールするアプリの例えば識別情報を含むアプリ情報４１２をデバイス４００に応答する。デバイス４００はさらに、そのアプリのバージョンを指定するアプリバージョン指定４１３を配信システム１０に送信する。配信システム１０は、指定されたアプリの指定されたバージョンをダウンロードするためのURL応答４１４を応答する。以後、配信システム１０が処理する、デバイス４００からのリクエストは、Webインターフェース部３１０で処理されるものとして説明を続ける。なお、アプリ配送情報要求４１１、アプリバージョン指定４１３は、一つのメッセージにまとめることができるならば、一つのメッセージにしてもよい。

デバイス４００は、応答されたURLでコンテンツサーバ２０にアクセスし、インストールするアプリのファイルを要求するアプリ要求４１５を送信する。アプリ要求４１５は例えば取得したＵＲＬに対するＨＴＴＰ要求である。その応答４１６で取得したアプリのファイルを使用して、デバイス４００はアプリのインストール処理４１７を行う。インストール処理４１７が終了し、インストールしたアプリが起動すると、デバイス４００は、配信システム１０へ、アプリのインストール完了を通知するアプリ更新通知４１８を送信する。この時、新しくインストールされたアプリケーションを含め、その時点でデバイス４００にインストールされているアプリケーションとバージョンの一覧情報を、配信システム１０へ通知する。すなわちアプリ更新通知４１８には、インストールされているアプリケーションとバージョンの一覧情報が含まれている。

デバイス４００からアプリ更新通知４１８を受けると、配信システム１０は、それを記録し、デバイス４００に現在インストールされているアプリの情報を更新するアプリ状態記録４１９を実行する。デバイスのアプリ状態を示す情報は上書きによって更新してもよいし、履歴を残しつつ更新してもよい。配信システム１０は、アプリの状態を記録すると、デバイス４００へ応答４２０を返す。

また、別のタイミングにおいて（すなわちソフトウェアのインストール或いは更新とは非同期に）、サービスマン４０４は、デバイス４００にファームウェアをインストールするための例えばPC３１をデバイス４００に接続する。ファームウェアは、デバイス４００に接続したPC３１のハードディスクあるいは別のメディアに記録されている。接続したPC３１からのファームウェアのインストール操作４３０に従って、PC３１からデバイス４００へインストールされるファームウェアがアップロードされる。デバイス４００は、アップロードされたファームウェアのバージョンで、ファームウェアの更新処理４３１を実施し、デバイス４００自身を再起動するデバイス再起動処理４３２を実行する。再起動後、インストールしたバージョンのファームウェアによってデバイス４００は起動し、ファームウェアの更新完了表示４３３を行ってサービスマン４０４によるファームウェアのインストールは完了する。

以上のようにして、ユーザ４０１やサービスマン４０４による操作をトリガとして、アプリケーションのインストール（更新を含む）やファームウェアの更新が実行できる。

●自動更新処理のシーケンス例
図５は、デバイス４００と配信システム１０との間で実施されるファームウェアおよびアプリケーションの自動更新処理のやり取りの例を示すシーケンス図である。デバイス４００には、定期的に、ファームウェアおよびアプリケーションの更新の有無を確認する日時が設定されている。この日時、例えば毎週日曜日の深夜１時、になると、デバイス４００は、配信システム１０に対して、適用可能ＦＷ情報要求（確認要求とも呼ぶ）４４１を送信してファームウェアおよびアプリケーションの更新可能なバージョンの有無を問い合わせる。この時、デバイス４００からの問い合わせには、デバイス４００に組み込まれたファームウェアの現在のファームウェアバージョンを示す情報が含まれる。なお、デバイス４００からの問い合わせである適用可能ＦＷ情報要求４４１には、デバイス４００にインストールされたアプリケーションのバージョン情報などは含む必要が無い。この適用可能ＦＷ情報に対して、配信システム１０は、デバイス４００で更新すべきファームウェアおよびアプリケーションの情報（ＦＷ／アプリ情報）４４２を応答する。

デバイス４００へ応答するＦＷ／アプリ情報４４２は、たとえば、コンテンツタイプ、ID、バージョンの組合せを含む（表９参照）。コンテンツタイプは、FWの更新前に更新するアプリか、FWの更新後に更新するアプリか、ファームウェアか、いずれかを示す。IDは、アプリIDまたはデバイスモデルを示す。バージョンは各コンテンツのバージョンを示す。これにより、デバイス４００に対して、更新すべきアプリケーション及び／又はファームウェアを示す。

ここでファームウェアに関してはデバイス４００から受信したファームウェアバージョン（ファームウェアの識別情報を含む）に基づいて、配信システム１０は更新の有無を判定できる。アプリに関しては、配信システム１０が各デバイスにインストールされているアプリに関する情報（バージョンも含む）を有する場合には、その情報に基づいて更新の有無を判定できる。例えば現在インストールされているアプリケーションのバージョンよりも新しいバージョンがそのアプリに関して用意されていれば、アプリ情報として例えばアプリの識別情報とバージョンとを応答すればよい。インストールの順序に関しては、別途定義されたインストール順の制約を示す情報を参照すればよい。デバイス４００は、ＦＷ／アプリ情報４４２で受信したファームウェアおよびアプリに関する情報に従って、シーケンス４４３以降で、ファームウェアおよびアプリケーションの更新を行う。

まず、ソフトウェア配信システム全体において、ファームウェアの更新前に、更新するアプリケーションがある場合には、シーケンス４４３を実行する。シーケンス４４３においては、デバイス４００は、受信したＦＷ／アプリ情報４４２から取得したアプリケーションとバージョンの情報をアプリバージョン指定４４４として配信システム１０へ送り、その応答としてダウンロードURL４４５を受信する。デバイス４００はアプリバージョン指定４４４を送信する際に、自身にインストールされているアプリについて、現在のバージョンより新しいバージョンがＦＷ／アプリ情報４４２に含まれていれば、そのアプリについてアプリバージョン指定４４４を送信する。

デバイス４００は、応答されたURLでコンテンツサーバ２０にアクセスし、インストールするアプリのファイルを要求する４４６。その応答４４７で取得したアプリのファイルを使用して、デバイス４００はアプリの新バージョンへの更新をアプリ更新処理４４８により行う。アプリの更新が終了し、更新したアプリが起動すると、デバイス４００は、配信システム１０へ、アプリの更新完了をアプリ更新完了通知４４９により通知する。この時、更新されたアプリケーションを含め、その時点でデバイス４００にインストールされているアプリケーションとバージョンの一覧情報を、配信システム１０へ通知する。

デバイス４００からアプリ更新通知４４９を受けると、配信システム１０は、アプリ状態記録４５０を行って、デバイス４００に現在インストールされているアプリの情報を更新する４５０。配信システム１０は、アプリの状態を記録すると、デバイス４００へ応答を４５１返す。

シーケンス４４３は、ファームウェアの更新前に更新するアプリケーションが複数ある場合には、アプリケーションの数だけ繰り返される。なお一回の手続きで複数のアプリケーションを更新してもよい。

次に、更新するファームウェアのバージョンがある場合には、シーケンス４５２を実行する。シーケンス４５２において、デバイス４００は、ＦＷ／アプリ情報４４２からファームウェアのバージョンを指定する情報を配信システム１０へ送り４５３、ダウンロードURL４５４を受信する。ファームウェアのバージョンを指定する情報の決定の仕方も、アプリケーションと同様でよい。

デバイス４００は、応答されたURL４５４でコンテンツサーバ２０にアクセスし、インストールするファームウェアのファイルを要求するＦＷ要求４５５を送信する。その応答４５６で取得したファームウェアのファイル４５６を使用して、デバイス４００はファームウェアの更新処理４５７を行う。バージョン更新が終了し、デバイス４００を再起動するためのデバイス再起動処理４５８を行うと、デバイス４００は、配信システム１０へ、ファームウェの更新通知４５９を通知する。この時、ファームウェ更新通知４５９により、更新されたファームウェアのバージョン情報を、配信システム１０へ通知する。

デバイス４００からファームウェアの更新通知４５９を受けると、配信システム１０は、それを記録するＦＷ状態記録４６０を実行し、デバイスのファームウェアの現在バージョンの情報を更新する４６０。配信システム１０は、ファームウェアのバージョン情報を記録すると、デバイス４００へ応答４６１を返す。

最後に、ファームウェアの更新後に更新するアプリケーションのバージョンがある場合には、シーケンス４６２を実行する。シーケンス４６２における、処理４６３から処理４７０は、シーケンス４４３のそれと同様である。また、ファームウェアの更新後に更新するアプリケーションが複数ある場合には、アプリケーションの数だけ繰り返す。

●配信システム１０により管理される情報
次に、本発明における配信システム１０の管理する情報、および、デバイスとやり取りする情報について説明する。表１にアプリ情報管理テーブル３３１に格納されているアプリ情報の例を示す。

アプリ情報は、アプリID、アプリ名の組合せの一覧から成る。アプリ名は、アプリIDで特定されるアプリケーションの名称を示す。アプリ名は利用者に表示されるものであり、管理上は、アプリケーションはアプリIDで一意に識別される。

さらに、表２に登録アプリ管理テーブル３３２に格納されているアプリの登録情報の例を示す。

アプリの登録情報は、ファイルID、アプリID、バージョン、URLの組合せの一覧から成る。アプリIDが示すアプリケーションのあるバージョンは、それぞれ異なるファイルIDで一意に識別される。また、ファイルIDに対応するアプリケーションのファイルが、コンテンツサーバ２０において、ファイルＩＤに対応するURLに示す場所に格納されている。アプリの登録情報は、販売会社システム３０から担当者がアプリを登録する際に入力され、更新されることで維持されている。

アプリケーションの更新においては、バージョン更新の際にアプリケーションが動作するための設定値が変わった場合など、バージョン更新用の仕組みを更新後バージョンのアプリケーションに実装する必要がある場合がある。したがって、更新前後のバージョン間にバージョン更新可能な組み合わせが存在する。例えば、現在がバージョン１、最新バージョンがバージョン３だとする。この時、バージョン１から最新バージョン（バージョン３）へ更新する前に、一旦バージョン２へ更新してから、改めてバージョン３へ更新する必要がある場合がある。このような更新可能なバージョンの組合せをアプリバージョンの管理情報で管理している。表３にアプリバージョン管理テーブル３３３に格納されている更新可能なアプリバージョンの管理情報の例を示す。

更新可能なアプリバージョンの管理情報は、アプリID、更新元バージョン、更新後バージョンの組合せの一覧から成る。1つの組合せは、そのアプリIDにおける、更新元バージョンから更新後バージョンへの更新が可能であることを示している。アプリバージョン管理テーブル３３３に登録されていないバージョンの組合せは、配信システム１０による更新が出来ないことを意味する。この更新可能なバージョンの組合せ情報は、販売会社システム３０から担当者がアプリを登録する際にアプリの管理情報と合わせて入力され、更新されることで維持されている。

アプリと同様に、配信システム１０は、配信可能なFWも管理する。表４に登録ファームウェア管理テーブル３３４に登録されているFWの管理情報の例を示す。

FWの管理情報は、デバイスモデル、バージョン、URLの組合せの一覧から成る。デバイスモデルとバージョンの組合せに対応するFWのファイルは、URLに示すコンテンツサーバ２０上の記憶場所に格納されている。FWの管理情報は、販売会社システム３０から担当者がFWを登録する際に入力され、更新されることで維持されている。

FWにおいては、バージョン更新の際にソフトウェアの構成が変わった場合など、バージョン更新用の仕組みを更新後バージョンのFWに実装する必要がある場合がある。したがって、更新前後のバージョン間にバージョン更新可能な組み合わせが存在する。例えば、現在がバージョン１、最新バージョンがバージョン３だとする。この時、バージョン１から最新バージョンへ更新する前に、一旦バージョン２へ更新してから、改めてバージョン３へ更新する必要がある場合がある。このような更新可能なバージョンの組合せをFWバージョンの管理情報で管理している。表５にファームウェアバージョン管理テーブル３３５に格納されている更新可能なFWバージョンの管理情報の例を示す。

更新可能なFWバージョンの管理情報は、デバイスモデル、更新元バージョン、更新後バージョンの組合せの一覧から成る。デバイスモデルは、同じFWを適用可能なデバイスのグループを表す。1つの組合せは、そのデバイスモデルにおける、更新元バージョンから更新後バージョンへの更新が可能であることを示している。ファームウェアバージョン管理テーブル３３５に登録されていないバージョンの組合せは、更新出来ないことを意味する。この更新可能なバージョンの組合せ情報は、販売会社システム３０から担当者がFWを登録する際にFWの管理情報と合わせて入力され、更新されることで維持されている。

アプリケーションにおいては、そのアプリケーションのバージョンが動作する環境、すなわち、ファームウェアのバージョンが限られる場合がある。例えば、アプリAのバージョン１はファームウェアのバージョン１の上で動作するように実装されているが、アプリAのバージョン２は、ファームウェアのバージョン２の上でなくては動作しない、という場合がある。このような場合には、アプリAをバージョン２へ更新する前にファームウェアをバージョン２に更新する必要がある。このようなアプリのバージョンおよびFWのバージョンの動作可能な組み合わせをバージョン組み合わせ情報で管理している。表６にバージョン制限管理テーブル３３６に格納されているバージョン組み合わせ情報の例を示す。

バージョン組み合わせ情報は、デバイスモデル、FWバージョン、ファイルIDの組合せの一覧から成るブラックリストである。1つの組合せは、デバイスモデルにおけるFWバージョンが示すバージョンのFW上でファイルIDが示すアプリのバージョンが動作しないことを示す。このバージョン組み合わせ情報は、販売会社システム３０から担当者がFWおよびアプリケーションを登録する際に登録するファームウェアあるいはアプリケーションに依存関係があることが分った時に入力され、更新されることで維持されている。

配信システム１０は、配信対象となる各デバイスの状態を保持し管理している。デバイスの状態を示す情報の一つとして、各デバイスで動作しているFWのバージョン情報がある。表７にデバイス管理テーブル３３７に格納されているデバイス管理情報の例を示す。

デバイスの管理情報は、デバイスID、デバイスモデル、バージョンの組合せの一覧から成る。デバイスＩＤは、デバイスの個体ごとの識別情報である。デバイスモデルは、デバイスIDで識別されるデバイスが属するデバイスモデルである。バージョンは、そのデバイスで現在動作しているFWのバージョンを示す。デバイスは、図５に示したシーケンスにおいて、配信システム１０と通信する際に、自身のデバイスIDを合わせて通知する。配信システム１０は、ＦＷ更新通知４５９で得られたデバイスIDとFWのバージョンから、４６０の処理においてデバイス管理テーブル３３７を更新する。なお、デバイスIDとデバイスモデルの対応については、不図示の管理情報に基づいて、デバイスIDからデバイスモデルへ一意に対応付けられるものとする。

デバイスの状態を示すもう一つの情報として、各デバイスにインストールされているアプリとその状態の情報がある。さらに、配信システム１０は、それらのアプリおよびFWを次の更新タイミングでどのバージョンへ更新するか否かの情報を管理している。表８に更新予定バージョン管理テーブル３３８に格納されているデバイスの更新予定バージョン情報の例を示す。

更新予定バージョン情報は、デバイスID、アプリID、現在VER、更新VER、更新時、更新FWVERの組合せの一覧から成る。現在VERは、デバイスＩＤで示されるデバイスにインストールされたアプリIDで示されるアプリのバージョンを示す。デバイスIDとアプリID、現在VERの組合せによって、デバイスIDに示すデバイスにアプリIDとバージョンの組合せが示すアプリがインストールされていることを示している。また、インストール済みアプリ情報は、次に更新予定のアプリケーションとFWのバージョン情報とをさらに保持している。更新VERは、アプリIDの更新予定のバージョンを示す。更新FWVERは、FWの更新予定のバージョンを示す。「更新時」は、更新VERに示すアプリのバージョンをFW更新の前に更新するか、後に更新するかを示す。更新VERと更新時、更新FWVERの組合せによって、次回FWのバージョンに更新する際に、合わせてその前後のいずれかでアプリのバージョンに更新する予定であることを示している。更新の予定が無ければ、これらは空欄となる。この情報は、図４におけるアプリ状態記録４１９あるいは、図５におけるアプリ状態記録４５０及び４６９の処理で更新される。この情報に従って、配信システム１０は、デバイスからの問い合わせに対して、更新すべきFWおよびアプリの情報を返却する。

表９に、図５におけるＦＷ／アプリ情報４４２で配信システム１０がデバイス４００へ返す情報の例を示す。

デバイス４００へ応答する情報は、コンテンツタイプ、ID、バージョンの組合せの一覧から成る。コンテンツタイプは、前アプリ、後アプリ、FWのいずれかである。前アプリは、FWの更新前に更新するアプリを示す。後アプリは、FWの更新後に更新するアプリである。FWはファームウェアである。コンテンツタイプが前アプリあるいは後アプリの場合には、IDは、アプリIDを示す。コンテンツタイプがFWの場合には、IDはデバイスモデルを示す。バージョンは各コンテンツのバージョンを示す。コンテンツタイプが前アプリあるいは後アプリの場合には、バージョンは、アプリIDに対応するバージョンを示す。コンテンツタイプがFWの場合には、バージョンは、デバイスモデルに対応するFWバージョンである。

デバイスへ応答する情報は、更新予定バージョン管理テーブル３３８から、情報を返却するデバイスのデバイスIDに対応するレコードを絞り込み、アプリID、更新VER、更新時、更新FWVERの情報を取り出したものである。更新予定バージョン管理テーブル３３８のデバイスIDに対応するレコードに更新FWVERが記録されていない場合、すなわちFWのバージョン更新が予定されていない場合には、コンテンツタイプがFWの情報は含まれない。また、同じくデバイスIDに対応するレコードにいずれのアプリIDの更新VERも記録されていない場合には、コンテンツタイプが前アプリおよび後アプリの情報は含まれない。

また、デバイスにアプリが一つもインストールされていない場合には、更新予定バージョン情報が存在しないため、デバイスからの問い合わせ時にコンテンツタイプがFWの情報だけが生成される。デバイスに返却する情報の作成方法については、図１０で後述する。

●配信システムによる更新予定バージョン管理テーブル（表８）の更新
次に、配信システムの更新予定バージョン情報の更新処理について説明する。図６は、配信システム１０における、デバイス４００からアプリ更新通知４４９を受信した場合の処理（アプリ状態記録処理４５０）の例を示すフローチャートである。図６（ａ）は、図４のシーケンスにおけるアプリ状態記録処理４１９および図５のシーケンスにおけるアプリ状態記録処理４５０、４６９に対応する処理で、配信制御部３１７で実行される内容である。すなわちＣＰＵ２０１により実行される。

アプリ状態記録処理４１９、４５０あるいはアプリ状態記録処理４６９に対応して、ステップS１０００からの処理を開始する。ここで、デバイスからは、デバイスIDおよびそのデバイスにインストールされている全アプリケーションのアプリIDおよびバージョンを受信する。

ステップS１００１からステップS１００６まででデバイス４００から通知された全アプリのアプリIDについて、順に処理していく。ステップS１００２では、更新予定バージョン管理テーブル３３８に、デバイスから通知されたデバイスIDおよび現在処理中のアプリIDの組合せに対応するレコードが存在するかを確認する。存在する場合（Yes.）には、ステップS１００４へ進み、存在しない場合（No.）には、ステップS１００３へ進む。ステップS１００３では、デバイスIDとアプリIDの組合せに対応するレコードを追加する。ステップS１００４では、デバイス４００から通知されたデバイスIDおよび現在処理中のアプリIDの組合せに対応するレコードの現在VERを、デバイス４００から通知されたアプリIDに対応するバージョンで更新する。次にステップS１００５で、更新VER、更新時、更新FWVERをクリアする。ステップS１００６では、デバイスから受信した全てのアプリIDについてステップS１００５までの処理を完了したかを判断する。処理が完了していないアプリIDが残っている場合（No.）には、ステップS１００１へ戻り、残りのアプリIDについての処理を行う。全てのアプリIDについて処理が完了している場合（Yes.）は、ステップS１００７へ進み、非同期バッチ処理を起動する。非同期バッチ処理は、図６（ａ）と並列で（或いは非同期に）動作する、図６（ｂ）に示す処理である。図６（ｂ）に示す処理が起動したら、その終了を待たずにステップＳ１００８へ進む。ステップＳ１００８では、デバイス４００へ、アプリ更新通知４４９等に対する応答を返す。これは、図４のシーケンスにおける応答４２０および図５のシーケンスにおける応答４５１、４７０に対応する
図６（ｂ）は、図６（ａ）におけるステップＳ１００７で起動され、バッチ処理部３１５で処理される、単一デバイスIDを指定した更新予定バージョン情報更新のバッチ処理のフローチャートの例である。

ステップＳ１１００にて、デバイスから受信したデバイスIDをもって処理を開始する。
ステップS１１０１では、デバイスIDを指定して、更新予定バージョン情報更新（図７）の処理を呼び出す。当該デバイスIDの更新予定バージョン情報更新が終了したら、ステップS１００２にてバッチ処理を終了する。更新予定バージョン情報を現在行っているソフトウェア更新の必要性の確認を滞らせることなく、次に更新対象となるソフトウェアのバージョンを示す情報が更新される。

●更新予定バージョン情報更新処理
次に、更新予定バージョン情報更新処理の詳細を説明する。図７は、更新予定バージョン情報更新処理の例を示すフローチャートである。更新予定バージョン情報更新処理は、指定されたデバイスIDにおいて、呼び出し時点での情報に基づいて、次の更新タイミングで配信するFWのバージョンとアプリとそのバージョンを予め判断しておく。FWとアプリはそれぞれ更新予定バージョンを決定する。その時点の情報によって、FWだけ配信、アプリだけ配信、FWとアプリの両方を配信、となる場合があるが、更新時におけるFWとアプリのバージョンの組合せに制約がある場合には、その制約を満たしたバージョンが配信されるように決定される。

呼び出し元からデバイスIDが指定されて、ステップS１１１０からの処理を開始する。ステップS１１１１では、更新FWバージョン判断処理（図８）を呼び出す。呼出し時には、対象となるデバイスＩＤを指定しておく。更新FWバージョン判断処理は、指定されたデバイスIDにおいて次に更新するFWバージョンの情報を更新予定バージョン管理テーブル３３８へ反映する。
ステップS１１１２からステップS１１１４までで指定されたデバイスIDに対応するデバイスにインストールされている全アプリのアプリIDについて、順に処理していく。
ステップS１１１３では、更新アプリバージョン判断処理（図９）を呼び出す。更新アプリバージョン判断処理は、指定されたデバイスIDと現在処理中のアプリIDにおいて次に更新するアプリバージョンの情報を更新予定バージョン管理テーブル３３８（表８）へ反映する。
ステップS１１１４では、全てのアプリIDについてステップS１１１３までの処理を完了したかを判断する。処理が完了していないアプリIDが残っている場合（No.）には、ステップS１１１２へ戻り、残りのアプリIDについての処理を行う。全てのアプリIDについて処理が完了している場合（Yes.）は、ステップS１１１５へ進み、更新予定バージョン情報更新処理を終了する。

●更新FWバージョン判断処理（Ｓ１１１１）
図８は、図７のステップＳ１１１１における更新FWバージョン判断処理の例を示すフローチャートである。呼び出し元からデバイスIDが指定されて、ステップS１２００からの処理を開始する。次に、ステップS１２０１では、登録ファームウェア管理テーブル３３４（表４）を検索して、指定されたデバイスIDに対応するデバイスモデルで最新のファームウェアのバージョンを求める。本実施例においては、バージョンは数値で定義されており、同じデバイスモデルのFWのバージョンの中で数値の昇順に新しくなっているものとする。したがって、数値が最も大きいものが最新バージョンである。この最新のバージョンを最初の更新候補バージョンとする。なおデバイスモデルは例えばデバイスIDから特定できるものとする。
次に、ステップS１２０２では、デバイス管理テーブル３３７（表７）からデバイスIDに対応するデバイスの現在バージョン（すなわち当該デバイスのファームウェアの現在のバージョン）を取得して、現在の更新候補バージョンが、デバイスの現在バージョンよりも新しいか、を判断する。更新候補バージョンが現在バージョンよりも新しい場合（Yes.）には、ステップS１２０３へ進む。現在バージョンよりも新しくない場合（No.）には、FWバージョン更新の必要が無いため、ステップS１２０９へ進む。ステップS１２０９では、更新予定バージョン管理テーブル３３８（表８）における、指定されたデバイスIDに一致する全てのレコードの更新FWVERを空欄にする。

ステップS１２０３では、デバイスIDに対応するデバイスの現在バージョンから更新候補バージョンへの更新が可能か否かを判断する。これには、ファームウェアバージョン管理テーブル３３５（表５）から、デバイスIDに対応するデバイスモデル、デバイスIDに対応する現在バージョンを更新元、更新候補バージョンを更新後、とした組合せを検索する。該当する組合せが存在する場合（Yes.）には、その組み合わせは更新可能な組み合わせであり、ステップS１２０４へ進む。該当する組合せが存在しない場合（No.）には、ステップS１２１０へ進む。
ステップS１２１０では、登録ファームウェア管理テーブル３３４（表４）を検索して、現在の更新候補バージョンから一つ前のバージョンを求め、それを新たな更新候補バージョンとしてステップS１２０２からの処理を繰り返す。

ステップS１２０４からステップS１２０７までで、更新予定バージョン管理テーブル３３８（表８）において、指定されたデバイスIDに対応するデバイスにインストールされている全アプリのアプリIDについて、順に動作確認判断の処理をしていく。ステップS１２０４では、更新予定バージョン管理テーブル３３８に登録されたアプリIDに順次着目する。現在着目しているアプリIDを着目アプリIDと呼ぶ。これはアプリID以外の他の処理対象についても同様とする。

ステップS１２０５では、更新予定バージョン管理テーブル３３８（表８）から着目アプリIDとその現在VERを特定する。そして特定した着目アプリIDとその現在VERとで登録アプリ管理テーブル３３２（表２）を検索し、該当するファイルIDを特定する。指定されたデバイスIDに対応するデバイスモデルと現在の更新候補FWバージョン、特定したアプリのファイルIDの組合せが、バージョン制限管理テーブル３３６（表６）に存在するかを検索する。組合せが存在すれば動作不可能、組合せが存在しなければ動作可能である。ステップS１２０６では、ステップS１２０５の検索結果に従って、処理を分岐する。動作可能（Yes.）である場合には、ステップS１２０７へ進む。動作不可能である場合（No.）には、ステップS１２１０へ進み、現在の更新候補バージョンの一つ前のバージョンを求め、それを新たな更新候補バージョンとしてステップS１２０２からの処理を繰り返す。

ステップS１２０７では、全てのアプリIDについてステップS１２０６までの処理を完了したかを判断する。処理が完了していないアプリIDが残っている場合（No.）には、ステップS１２０４へ戻り、残りのアプリIDについての処理を行う。全てのアプリIDについて処理が完了している場合（Yes.）は、ステップS１２０８へ進む。
ステップS１２０８へ進むと、そのときのFWの更新候補バージョンは、デバイスにインストールされた全てのアプリが動作可能、かつ、現在よりも新しいバージョンである。したがって、更新予定バージョン管理テーブル３３８（表８）における、指定されたデバイスIDに一致する全てのレコードの更新FWVERへ、FWの現在の更新候補バージョンを反映する。
ステップS１２１１で、更新FWバージョン判断処理は終了し、呼び出し元に戻る。

以上の手順により、デバイス４００からのアプリ更新通知の受信をトリガとして、そのデバイス４００のファームウェアの更新可能な新しいバージョンを決定できる。決定されたバージョン情報は、たとえば次回の適用可能FW情報要求４４１に応答してデバイス４００に送信できる。またこの処理はトリガとなった処理とは非同期に実行されるので、デバイスへの応答に遅延をもたらすことを防止できる。

●更新アプリバージョン判断処理
図９は、更新アプリバージョン判断処理の例を示すフローチャートである。呼び出し元からデバイスIDとアプリIDが指定されて、ステップS１３００からの処理を開始する。それぞれ着目デバイスIDおよび着目アプリIDと呼ぶ。
次に、ステップS１３０１では、登録アプリ管理テーブル３３２（表２）を検索して、指定されたアプリIDで最新のバージョンを求める。本実施例においては、FW同様、アプリバージョンも数値で定義されており、同じアプリIDのバージョンの中で数値の昇順に新しくなっているものとする。したがって、数値が最も大きいものが最新バージョンである。この最新バージョンを最初の更新候補バージョンとする。
次に、ステップS１３０２では、更新予定バージョン管理テーブル３３８（表８）からデバイスIDとアプリIDの組合せに対応するアプリの現在VERを取得する。そして、現在の更新候補バージョンが、デバイスにインストールされている現在VERよりも新しいか、を判断する。更新候補バージョンが現在VERよりも新しい場合（Yes.）には、ステップS１３０３へ進む。現在VERよりも新しくない場合（No.）には、アプリバージョン更新の必要が無いため、ステップS１３１４へ進む。
ステップS１３１４へ来たということは、FW更新前後のバージョンに関わらず動作可能で現在よりも新しいアプリのバージョンは存在しないということである。したがってステップS１３１４では、更新予定バージョン管理テーブル３３８（表８）における、指定されたデバイスIDとアプリIDに一致するレコードの更新VERを空欄にする。

ステップS１３０３では、デバイスIDに対応するデバイスの現在バージョンから更新候補バージョンへの更新が可能か否かを判断する。これには、アプリバージョン管理テーブル３３３（表３）から、指定されたアプリIDと現在VERとを更新元とし、更新候補のバージョンを更新後とした組合せを検索する。更新可能つまり組合せが存在する場合（Yes.）には、ステップS１３０４へ進む。更新不可能、つまり組合せが存在しない場合（No.）には、ステップS１３１１へ進む。
ステップS１３０４では、更新予定バージョン管理テーブル３３８（表８）から、指定されたデバイスIDとアプリIDの組合せを検索し、更新FWVERが存在するか否かを判断する。更新FWVERがある場合（Yes.）には、ステップS１３０５へ進み、無い場合（No.）には、ステップS１３０９へ進む。
ステップS１３０５では、まず、更新FWバージョン（更新FWVER）とアプリの更新候補バージョンの組合せが動作可能かを、バージョン制限管理テーブル３３６（表６）から判断する。判断方法については、前述のステップS１２０５と同様であるので省略する。ステップS１３０６では、その判定結果に従って、動作可能である場合（Yes.）には、ステップS１３０７へ進む。動作不可能である場合（No.）には、ステップS１３１１へ進む。
ステップS１３１１では、登録アプリ管理テーブル３３２を検索して、現在の更新候補バージョンから一つ前のバージョンを求め、ステップS１３０２からの処理を繰り返す。

ステップS１３０７では、デバイス管理テーブル３３７（表７）から取得した現在FWバージョンと着目アプリの更新候補バージョンの組合せが動作可能かを、バージョン制限管理テーブル３３６（表６）から判断する。動作可能である場合（Yes.）には、FWのバージョン更新前にアプリの更新をすることが出来るため、ステップS１３０８からステップS１３１２へ進む。動作不可能である場合（No.）には、FWのバージョン更新後にアプリの更新を行う必要があるため、ステップS１３０８からステップS１３１３へ進む。

ステップS１３０９は、更新FWバージョンが無い場合の判断処理である。ステップS１３０７と同様に、現在FWバージョンとアプリの更新候補バージョンの組合せが動作可能かを、バージョン制限管理テーブル３３６（表６）から判断する。ステップS１３０９の場合では、FWの更新が無いため、動作不可能である場合（No.）、ステップS１３１０からステップS１３１１へ進み、一つ前のバージョンを更新候補バージョンとし、ステップS１３０２からの処理を繰り返す。動作可能である場合（Yes.）、アプリだけの更新は可能であるため、ステップS１３１０からステップS１３１２へ進む。FWの更新が無いアプリだけの更新の場合、前更新と後更新の両方が可能であるが、本実施例では、前更新で統一する処理としている。

ステップS１３１２へきたということは、アプリの更新候補バージョンは、対象デバイスの現在のFWバージョンで動作可能ということである。さらに、これから更新予定のFWバージョンでも動作可能あるいはFWの更新が無い、かつ、着目アプリの更新候補バージョンは、現在のバージョンよりも新しいということである。したがって、更新予定バージョン管理テーブル３３８（表８）における、指定されたデバイスIDとアプリIDに一致するレコードの更新VERへ、当該アプリの現在の更新候補バージョンを反映する。そして、当該レコードの更新時には、「前」を設定する。

ステップS１３１３へ来たということは、アプリの現在の更新候補バージョンは、対象デバイスの現在のFWバージョンで動作不可能ということである。しかし、更新予定のバージョンのFWの更新後には動作可能、かつ、着目アプリの更新候補バージョンは、現在のバージョンよりも新しいということである。したがって、更新予定バージョン管理テーブル３３８に（表８）おける、指定されたデバイスIDとアプリIDに一致するレコードの更新VERへアプリの現在の更新候補バージョンを反映する。そして、当該レコードの更新時には、「後」を設定する。
ステップS１３１５で、更新アプリバージョン判断処理は終了し、呼び出し元に戻る。

以上の手順により、デバイス４００からのアプリ更新通知の受信をトリガとして、そのデバイス４００のアプリの更新可能なバージョンを決定できる。決定したアプリの更新バージョンは、現在のファームウェアまたは更新後のファームウェアで動作可能であることが保証されている。またこの処理はトリガとなった処理とは非同期に実行されるので、デバイスへの応答に遅延をもたらすことを防止できる。

●FWおよびアプリの自動更新処理
図１０は、配信システム１０におけるFWおよびアプリの自動更新処理の例を示すフローチャートである。図１０は、図５のシーケンスにおける適用可能ＦＷ情報要求４４１の受信に対応して、FW／アプリ情報４４２の応答のために配信制御部３１７で処理される内容である。

適用可能ＦＷ情報要求４４１の受信に対応して、ステップS１４００からの処理を開始する。ステップS１４０１で、デバイスからは、デバイスIDおよびそのデバイスにインストールされているFWのバージョンを受信する。このデバイスが着目デバイスとなる。ここで、受信した着目デバイスのFWバージョンをDFWVER、デバイスIDをX、として内部処理の変数に格納する。このデバイスを以下ではデバイスXと呼ぶこともある。
ステップS１４０２では、登録ファームウェア管理テーブル３３４（表４）からデバイスIDがXのレコードを検索し、そのバージョンを取得する。これが、配信システム１０が把握している着目デバイスのFWバージョンである。そして、受信した着目デバイスのFWバージョンであるDFWVERと、配信システム１０が把握しているFWバージョンとが一致しているかを判断する。一致している場合（Yes.）には、ステップS１４０３へ進む。異なる場合（No.）には、ステップS１４０４へ進む。
ステップS１４０３では、デバイスXの更新予定情報があるか否かを判断する。つまり、更新予定バージョン管理テーブル３３８（表８）に、デバイスIDがXのレコードが含まれているかを検索する。含まれていればデバイスXにアプリがインストールされているかを判断する。たとえばアプリIDが登録されていれば、アプリがインストールされていると判定できる。アプリがインストールされている場合には、FWの配信バージョン（更新FWVER）とアプリの配信バージョン（更新VER）を合わせて判断する。アプリがインストールされていない場合には、FW配信バージョン（更新FWVER）だけを判断する。DFWVERと配信システム１０が把握しているFWバージョンが一致し（S1402-YES）、かつ、アプリがインストールされている場合（S1403-Yes.）には、更新予定バージョン情報更新処理（図７）で判断済みのFWとアプリのバージョン（すなわち更新予定バージョン管理テーブル３３８に登録されたFWとアプリのバージョン）で更新すればよい。したがって、ステップS１４１３へ進む。

アプリがインストールされていない場合（No.）には、デバイス４００から受信したファームウェアバージョンDFWVERを元に更新するFWのバージョンを判断する必要があるため、ステップS１４０４へ進む。アプリがインストールされていない場合で、更新するFWのバージョンが決定した場合には、ステップS１４０８で再度、アプリがインストールされているか否かが判断されて、処理が分岐する。

ステップS１４０４では、デバイス管理テーブル３３７（表７）から、デバイスIDがXのレコードを検索しデバイスモデルを特定する。そして、登録ファームウェア管理テーブル３３４（表４）から当該デバイスモデルのFWの最新バージョンを求める。ここで、内部処理の変数CURVERに求めた最新バージョンを格納する。CURVERは、現在の更新候補のバージョンを示す。
ステップS１４０５で、ファームウェアの更新候補ベージョンCURVERが現在バージョンDFWVERよりも新しいかを判断する。新しい場合には、ステップS１４０５へ進む。新しくない場合（No.）には、更新予定バージョン情報更新処理（図７）で判断済みのFWとアプリのバージョンで更新してはいけない、あるいは更新する必要が無いため、ステップS１４１０へ進む。
ステップS１４０６では、DFWVERからCURVERへのFWのバージョン更新が出来るか否かを、ファームウェアバージョン管理テーブル３３５（表５）から判断する。更新可能な場合（Yes.）には、ステップS１４０８へ進む。更新不可能な場合（No.）には、ステップS１４０７へ進み、登録ファームウェア管理テーブル３３４（表４）から一つ前のバージョンを求めてCURVERを更新し、ステップ１４０５からの処理を繰り返す。

ステップS１４０８では、デバイスXについて、アプリ及び／又はFWの更新予定情報があるか否かを、更新予定バージョン管理テーブル３３８（表８）を参照して判断する。デバイスXにアプリがインストールされていない場合には、ここまでの処理において決定されたCURVERが、更新するFWのバージョンを示している。ステップS１４０８において、デバイスXの更新予定情報があると判定された場合（Yes.）には、ステップS１４０９へ進む。デバイスXの更新予定情報が無い場合（No.）、すなわち、アプリがインストールされていない場合には、ステップS１４２５へ進み、FWの更新情報のみを応答するための処理を行う。すなわち、ステップS１４２５では、応答４４２に、ファームウェアの現在の更新候補バーションCURVERを追加する。そしてステップS１４２６で追加されたファームウェアの現在の更新候補バーションを含む応答をデバイス４００に送信する。

ステップS１４０９では、更新予定バージョン情報更新（図７）によって事前に更新予定バージョン管理テーブル３３８（表８）に記録されている更新FWVERと、現在のファームウェアの更新候補バージョンCURVERとが同じであるかを判断する。同じである場合（Yes.）には、アプリの更新が有ったとしても、FWの更新の後で更新が可能であることが判断済みであるため、次のステップS１４１２へ進む。異なる場合（No.）には、ステップS１４１０へ進む。
ステップS１４１０では、デバイス管理テーブル３３７（表７）におけるデバイスXのレコードに対して、デバイス４００から受信したファームウェアバージョンDFWVERの値でバージョンを更新する。ステップS１４１０を通らない処理フローの場合には、デバイスXのFWのバージョン更新が実施されるため、図５におけるFW状態記録処理４６０のタイミングでデバイスXのデバイス管理情報（表７）は更新される。ステップS１４１１では、FWもアプリも更新情報は無いため、図５のFW／アプリ情報４４２は更新情報無しでデバイス４００へ応答される。

一方ステップS１４１２では、内部処理の変数であるAFTERフラグをオンにセットする（初期値はオフ）。すなわち、アプリの更新時期を、ファームウェアの更新の後に設定する。このフラグがセットされて、後のステップS１４１６へ進んだ場合には、「更新時」を「後」の値として処理を進める。すなわち、更新予定バージョン管理テーブル３３８における、全てのアプリの更新時が「後」として見なされることを意味する。そして、ステップS１４１３へ進む。
ステップS１４１３からの処理で、更新予定バージョン管理テーブル３３８の情報から、デバイス４００へ応答する情報（表９）を作成する。ステップS１４１３では、更新予定バージョン管理テーブル３３８（表８）からデバイスXのレコードを検索する。
ステップS１４１４では、まず検索結果として得られた該当するレコードのうち、最初のレコードを取得して、対象レコードとする。
ステップS１４１５では、対象レコードに更新VERの記録があるか否かを判断する。つまり、対象レコードのアプリの更新バージョンがあるか否かを判断する。ある場合（Yes.）には、ステップS１４１６へ進み、応答情報に対象のアプリの更新情報を追加する。無い場合（No.）には、ステップS１４１９へ進み、処理を進める。
ステップS１４１６では、デバイスへ応答する情報におけるアプリの更新時を前後どちらにするかの判断をする。ステップS１４１２にて、AFTERフラグがセットされている場合には、ここにおいて、アプリは全て「後」更新と判断される。そうでない場合には、更新予定バージョン情報における対象レコードの「更新時」の値に従って、「前」か「後」と判断される。「前」と判断された場合には、ステップS１４１７へ進み、「後」と判断された場合には、ステップS１４１８へ進む。
ステップS１４１７では、表９で例示したデバイスへ応答する情報に、コンテンツタイプとして「前アプリ」、IDとして対象レコードのアプリIDの値、バージョンとして対象レコードの更新VERの値から成る組合せを追加する。
ステップS１４１８では、表９で例示したデバイスへ応答する情報に、コンテンツタイプとして「後アプリ」、IDとして対象レコードのアプリIDの値、バージョンとして対象レコードの更新VERの値から成る組合せを追加する。

ステップS１４１９では、対象レコードがデバイスの最終レコードであるかを判断する。最終レコードである場合（Yes.）には、ここまでで全てのアプリの応答情報の追加が終了しているため、ステップS１４２１へ進み、FWの応答情報の判断処理を行う。最終レコードでない場合（No.）には、ステップS１４２０へ進む。
ステップS１４２０では、検索結果から次のレコードを取得して、それを対象レコードとし、ステップS１４１５からの処理を繰り返す。

ステップS１４２１では、最終レコードに対して、更新FWVERの記録があるか否かを判断する。つまり、デバイスXにFWの更新バージョンがあるか否かを判断する。ある場合（Yes.）には、ステップS１４２２へ進み、デバイスへの応答情報にFWの更新情報を追加する。無い場合（No.）には、ステップS１４２４へ進む。
ステップS１４２２では、表９で例示したデバイスへ応答する情報に、コンテンツタイプとして「FW」、IDとしてXのデバイスモデルの値、バージョンとして対象レコードの更新FWVERの値から成る組合せを追加する。
ステップS１４２３では、ここまでに作成したデバイスへの応答情報をもって、FWとアプリの更新情報をデバイスへ応答して、応答４４２とする。なお、ステップS１４１５からS１４２０の処理の繰り返しの中でアプリの更新情報が一つもなければ、ここでFWの更新情報のみとなる場合もある。
ステップS１４２４では、ここまでに作成したデバイスへの応答情報をもって、アプリの更新情報のみをデバイスへ応答して応答４４２とする。
ステップS１４２５では、表９で例示したデバイスへ応答する情報に、コンテンツタイプとして「FW」、IDとしてXのデバイスモデルの値、バージョンとしてCURVERの値から成る組合せを追加する。
ステップS１４２６では、ここまでに作成したデバイスへの応答情報をもって、FWの更新情報のみをデバイスへ応答して応答４４２とする。

図１０の手順をまとめると、デバイスが申告したファームウェアバージョンと、サーバが管理しているデバイスのファームウェアバージョンとが一致しているなら、更新予定を確認し、更新予定があるならば、ＦＷ／アプリ応答４４２は、更新予定バージョン管理テーブル３３８の登録内容に従う。

一方、デバイスが申告したファームウェアバージョンと、サーバが管理しているデバイスのファームウェアバージョンとが一致していないか、または更新予定がない場合には、まずファームウェアの更新バージョンを決定する。更新バージョンは、デバイスの現在のバージョンより新しく、かつ、更新可能なバージョンのうち最も新しいバージョンである。このときには、更新されるアプリはすべてファームウェアの後に更新するものと設定する。

これによって、更新すべきファームウェアのバージョン及びアプリのバージョンを決定できる。また、アプリの更新バージョンが図６（ｂ）の処理で決定されている場合には、アプリのバージョンも併せてデバイスに通知することができる。

●FW登録更新時処理
更新予定バージョン情報は、新しくFWが登録された時にも更新される。FWが新規に登録されれば、自動アップデートによる定期確認の際に新しいFWの方を配信する判断となる可能性がある。この時には、アプリの動作依存情報も反映されている必要がある。

図１１（ａ）は、FW登録後にバッチ処理部３１５で処理される、FW登録更新時処理の例を示すフローチャートである。
FWの登録によって、登録ファームウェア管理テーブル３３４（表４）、ファームウェアバージョン管理テーブル３３５（表５）、および、バージョン制限管理テーブル３３６（表６）が更新されると、ステップS１１２０からの処理が開始する。

ステップS１１２１では、FW登録された対象のデバイスモデルを特定する。ここで、対象デバイスモデルに属するデバイスIDの一覧を持って、ステップS１１２２からステップS１１２４までで対象デバイスモデルに属する全デバイスIDについて、順に処理していく。
ステップS１１２３は、処理するデバイスIDで、更新予定バージョン情報更新処理（図７、ステップS１１１０）を呼び出す。
ステップS１１２４では、デバイスモデルに属する全てのデバイスIDについてステップS１１２３の処理を完了したかを判断する。処理が完了していないデバイスIDが残っている場合（No.）には、ステップS１１２２へ戻り、残りのデバイスIDについての処理を行う。全てのデバイスIDについて処理が完了している場合（Yes.）は、ステップS１１２５へ進み、FW登録更新時処理を終了する。

この手順で、ファームウェアの新バージョンが登録されると、それに応じて更新予定バージョン管理テーブル３３８を更新することができる。

●定時バッチ処理
さらに、バッチ処理部３１５は、定期的にスケジュールされた日時に起動する定時バッチ処理も行う。アプリのバージョンだけが更新された場合などは、この定時バッチ処理で、更新予定バージョン管理テーブル３３８を更新する。
図１１（ｂ）は、定時バッチ処理の例を示すフローチャートである。例えば、毎日深夜0時に処理を起動するように設定されたスケジューラ３１８により、バッチ処理部３１５において、ステップS１１３０からの処理を開始する。
ステップS１１３１からステップS１１３３までで、更新予定バージョン管理テーブル３３８（表８）に登録された全デバイスIDについて、順に処理していく。
ステップS１１３２は、処理するデバイスIDで、更新予定バージョン情報更新処理（図７、ステップS１１１０）を呼び出す。
ステップS１１３３では、全てのデバイスIDについてステップS１１３２の処理を完了したかを判断する。処理が完了していないデバイスIDが残っている場合（No.）には、ステップS１１３１へ戻り、残りのデバイスIDについての処理を行う。全てのデバイスIDについて処理が完了している場合（Yes.）は、ステップS１１３４へ進み、定時バッチ処理理を終了する。

この手順で、アプリの新バージョンが登録されていると、それに応じて更新予定バージョン管理テーブル３３８を更新することができる。図１１に示したように、更新予定バージョン管理テーブル３３８は、設定した所定時期や、ファームウェアの登録などの所定のイベントをトリガとして実行させることもできる。

以上、本実施例では、無人で適切な最新バージョンに更新されている状態が望ましい、（定期）自動更新配信の場合のシーケンスについて説明した。しかしながら、有人であっても容易に適切なバージョンへの更新が可能となるようにするための仕組みとしても、本実施例に係る発明は適用可能である。

図１２は、デバイスにおいて、デバイスの利用者によるFWおよびアプリの最新版への更新を実施する時の流れの例を示すシーケンス図である。図１２のシーケンスは、基本的に図５のシーケンスに従うため、図５との差異のみ説明する。

利用者４０１は、デバイス４００のソフトウェア（FWおよびアプリ）を適切な組み合わせの最新版へと更新するために、デバイス４００への更新指示を行う４８０。これは、例えば、デバイス４００の操作パネルに、「ソフトウェアの最新化」等のボタンがあり、これを押下することにより、続くシーケンスが回診することを意味する。以後、図５に示したデバイス４００と配信システム１０との通信シーケンスと同じやり取りを即時で実行することにより、利用者によるソフトウェア最新化が可能となる。

以上述べたように、配信システムにおいて、自動更新時にデバイスから現在のFWバージョンを受信するだけで、最新のアプリとFWを配信することが出来る。配信システムは、非同期で予め、各デバイスに配信予定のFWとアプリのバージョンを特定しておくことにより、配信時にサーバの応答速度を低下させることなくアプリとFWの適切なバージョンの組み合わせで配信することが出来る。適切な組み合わせについては、デバイスの現在バージョンを含め、アプリのバージョンだけを更新することが適切な場合は、アプリだけを配信し、FWだけ更新することが適切な場合は、FWだけを配信する。

これにより、MFPのようなデバイスにおいても、限られた現実的更新タイミングで、FWおよび複数のアプリをまとめて更新することが出来るようになり、MFPのようなデバイスにおいても配信スケジュールに関わる運用課題が軽減できた。また、FWとの組み合わせで動作が保証出来ているアプリだけを自動更新するということも可能となった。

［その他の実施例］
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

１０配信システム、２０コンテンツサーバ、３０販売会社システム、４００デバイス

Claims

複数のデバイスと配信システムとを含むシステムであって、
前記配信システムは、
デバイスにインストールされているファームウェア及びアプリケーションのバージョン情報と、前記ファームウェア及びアプリケーションの更新予定のバージョン情報とを、デバイスＩＤごとに管理する管理手段と、
前記デバイスからの該デバイスのデバイスＩＤと該デバイスにインストールされているアプリケーションのバージョン情報を含む更新通知の受信に応じて、前記管理手段により管理される前記デバイスにインストールされているアプリケーションのバージョン情報を更新し、さらに、前記管理手段により管理された前記ファームウェア及びアプリケーションの更新予定のバージョン情報の更新を行う更新手段と、
前記デバイスから、該デバイスのデバイスＩＤと該デバイスにインストールされているファームウェアのバージョン情報とを含む、ファームウェアの更新の確認要求を受信する受信手段と、
前記受信手段により受信した前記確認要求に含まれる情報が示す前記ファームウェアのバージョン情報に基づいて該ファームウェアの更新予定のバージョン情報を特定し、さらに、前記管理手段で前記確認要求に含まれるデバイスＩＤに対応する前記アプリケーションについての更新予定が既に管理されていた際には、当該更新予定に基づいて、前記デバイスにインストールされているアプリケーションについての更新予定のバージョン情報の特定を行う特定手段と、
特定された前記ファームウェアの更新予定のバージョン情報と前記アプリケーションの更新予定のバージョン情報とを前記確認要求への応答として、前記デバイスに送信する応答手段と、を有し、
前記デバイスでは、前記応答に従い前記ファームウェア及びアプリケーションが更新され、当該アプリケーションの更新に応じてデバイスＩＤと更新後のアプリケーションのバージョン情報を含む更新通知が前記配信システムに送信されることを特徴とするシステム。
請求項１に記載のシステムであって、
前記更新手段はさらに、前記ファームウェアの新しいバージョン情報が前記配信システムに登録された際に前記更新を行うことを特徴とするシステム。
請求項１又は２に記載のシステムであって、
前記更新手段はさらに、所定のトリガで前記更新を行うことを特徴とするシステム。
請求項３に記載のシステムであって、
前記所定のトリガは、所定の時期に達したことであることを特徴とするシステム。
請求項１乃至４のいずれか一項に記載のシステムであって、
前記応答手段はさらに、前記アプリケーションの更新予定のバージョン情報が、前記ファームウェアの更新予定のバージョン情報と組み合わせられる場合には、前記アプリケーションの更新を前記ファームウェアの更新の後で行うことを示す情報を前記応答に含めることを特徴とするシステム。
請求項１乃至５のいずれか一項に記載のシステムであって、
前記更新手段は、前記デバイスから受信した前記ファームウェアのバージョン情報に基づいて、前記バージョン情報が示すバージョンよりも新しく、かつ、前記バージョンから更新可能であり、かつ、前記デバイスにインストールされている前記アプリケーションと組み合わせ可能であるようなバージョンのうち、最新のバージョンを、新たな前記ファームウェアの更新予定のバージョン情報とすることを特徴とするシステム。
請求項１乃至６のいずれか一項に記載のシステムであって、
前記更新手段は、前記デバイスから受信した前記デバイスＩＤに基づいて、前記デバイスにインストールされている前記アプリケーションについて、前記デバイスにインストールされているバージョン情報が示すバージョンよりも新しく、かつ、前記バージョンから更新可能であり、かつ、前記デバイスにインストールされている前記ファームウェアの更新予定のバージョンと組み合わせ可能であるようなバージョンのうち、最新のバージョンを、新たな前記アプリケーションの更新予定のバージョン情報とすることを特徴とするシステム。
請求項７に記載のシステムであって、
前記更新手段は、前記デバイスにインストールされている前記ファームウェアの更新予定のバージョンと組み合わせ可能でなくとも、前記デバイスにインストールされている前記ファームウェアの現在のバージョンと組み合わせ可能であれば、当該バージョンを、新たな前記アプリケーションの更新予定のバージョン情報とすることを特徴とするシステム。
複数のデバイスと配信システムとを含むシステムによる配信方法であって、
前記配信システムが、
デバイスにインストールされているファームウェア及びアプリケーションのバージョン情報と、前記ファームウェア及びアプリケーションの更新予定のバージョン情報とを、デバイスＩＤごとに管理し、
前記デバイスからの該デバイスのデバイスＩＤと該デバイスにインストールされているアプリケーションのバージョン情報を含む更新通知の受信に応じて、前記デバイスにインストールされているアプリケーションのバージョン情報を更新し、さらに、前記ファームウェア及びアプリケーションの更新予定のバージョン情報の更新を行い、
前記デバイスから、該デバイスのデバイスＩＤと該デバイスにインストールされているファームウェアのバージョン情報とを含む、ファームウェアの更新の確認要求を受信し、
受信した前記確認要求に含まれる情報が示す前記ファームウェアのバージョン情報に基づいて該ファームウェアの更新予定のバージョン情報を特定し、さらに、前記確認要求に含まれるデバイスＩＤに対応する前記アプリケーションについての更新予定が既に管理されていた際には、当該更新予定に基づいて、前記デバイスにインストールされているアプリケーションについての更新予定のバージョン情報の特定を行い、
特定された前記ファームウェアの更新予定のバージョン情報と前記アプリケーションの更新予定のバージョン情報とを前記確認要求への応答として、前記デバイスに送信し、
前記デバイスが、
前記応答に従い前記ファームウェア及びアプリケーションを更新し、当該アプリケーションの更新に応じてデバイスＩＤと更新後のアプリケーションのバージョン情報を含む更新通知を前記配信システムに送信することを特徴とするシステム。