JP2017033147A - 配信システム、配信方法及びプログラム - Google Patents

Abstract

【課題】複数デバイスでアプリの一括リモートアップデートを行う際、デバイス毎、アプリ毎に実行状態が異なるため、一律に起動、停止を決定できない。【解決手段】配信システムは、ネットワークデバイスにインストールされているファームウェアおよびアプリケーションのそれぞれの識別情報およびバージョン情報を取得し、取得した情報に基づいて、ファームウェアの配信設定のための第１の画面と、アプリケーションの配信設定のための第２の画面とを切り替えて表示し、第１の画面を介して指定されたファームウェアの配信設定、または第２の画面を介して指定されたアプリケーションの配信設定をネットワークデバイスに送信する。送信されるアプリケーションの配信設定には、該アプリケーションの配信後の稼働状態の指定が含まれる。【選択図】 図５

Description

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

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

ところで、ファームウェアおよびアプリケーションは、不具合の修正や機能拡張のためにバージョンアップが実施される場合がある。そして、バージョンアップでは、ファームウェアだけでなく、アプリケーションであっても、デバイスの製造元あるいは販売者によってバージョンアップ版のインストールが行われる場合もある。さらに、ソフトウェアのインストールあるいはバージョンアップ版ソフトウェアへの更新において、デバイスをネットワーク経由で配信サーバに接続し、デバイスに対して遠隔地からのソフトウェア配信も行われている。ここで、ファームウェアのような常時動作しているソフトウェアのバージョンアップでは、ソフトウェアの更新後も動作状態であるのが常であるため、遠隔地からの配信においても更新後に起動状態となるように制御される。ソフトウェア更新時の起動状態制御については、更新に当たってシステムリブートするか否かを制御する技術も提案されている（例えば、特許文献１）。

特開２０１１−２８７４号公報

デバイスの製造元あるいは販売者が、遠隔地からアプリケーションの配信を行う場合、更新後の起動状態を指定したい場合がある。例えば、起動時に初期設定を行うようなアプリケーションの場合、更新後に確実に起動していることが望ましい。また、アプリケーションの更新と同期して、ファームウェアあるいは他のアプリケーションの更新等が必要な場合、一旦アプリケーションの更新をしておき、他のソフトウェアの更新が行われるまで停止状態にしておきたい場合もある。

しかしながら、各デバイスで動作しているアプリケーションは、デバイス毎に実行状態（起動しているか、あるいは停止しているか）が異なる。また、その理由もデバイスの利用者毎に様々である。アプリケーションがインストールされている場合には起動状態が通常である。しかし、例えば、利用可能日数が制限されているライセンスに従ってアプリケーションを利用している場合、利用者は不必要にライセンスを消費したくないために、利用する時以外は停止しているかも知れない。また、一方で、不具合があることが分かっているアプリケーションの場合、利用者は不具合が解消されるまで停止状態で維持しているかも知れない。このような場合には、不具合が修正されたバージョンへの更新が行われた後に起動状態にすることが妥当である。従って、デバイスの製造元あるいは販売者は、遠隔地からの配信において、一律に更新後の起動・停止状態を決定するわけにはいかない。

従って、本発明の目的は、複数デバイスへの一括リモート配信において、各デバイスのアプリ更新後の起動状態を適切に制御できるようにすることである。

上記課題を解決するため、本発明は、ネットワークデバイスにインストールされているファームウェアおよびアプリケーションのそれぞれの識別情報およびバージョン情報を取得する取得手段と、前記取得手段により取得された情報に基づいて、前記ファームウェアに関する配信設定のための第１の画面と、前記アプリケーションに関する配信設定のための第２の画面とを切り替えて表示する表示手段と、前記表示された第１の画面を介して指定された前記ファームウェアに関する配信設定、または前記表示された第２の画面を介して指定された前記アプリケーションに関する配信設定を前記ネットワークデバイスに送信する送信手段を有し、前記送信される前記アプリケーションに関する配信設定には、該アプリケーションの配信後の稼働状態の指定が含まれることを特徴とする配信システムを提供する。

各デバイスにインストールされたアプリケーションの起動状態がそれぞれ異なっていても、複数デバイスへの一括リモート配信において、各デバイスのアプリ更新後の起動状態を適切に制御できるようになる。これにより、サービスマンによる複数デバイス管理におけるアプリケーションのバージョン更新作業が効率化する。結果、大量デバイスの保守状態が改善するようになる。

実施例１における、システム構成図 実施例１における、サーバのハードウェア構成 実施例１における、配信システム及びデバイスの機能ブロック図 実施例１における、利用者およびサービスマンの操作に伴う配信システムの通信シーケンス例 実施例１における、アプリ更新の配信シーケンス例 実施例１における、ファームウェア更新の配信シーケンス例 実施例１における、アプリ配信設定における対象デバイス検索画面例 実施例１における、アプリ配信設定における配信アプリ選択及び対象デバイス選択画面例 実施例１における、アプリ配信設定における配信設定画面例 実施例１における、配信システムにおける配信設定のフローチャート 実施例１における、デバイスにおける配信処理部のフローチャート 実施例１における、デバイスにおけるアプリインストール部のフローチャート 実施例１における、デバイスにおけるアプリ起動制御部の停止処理のフローチャート 実施例１における、デバイスにおけるアプリ起動制御部の起動処理のフローチャート 実施例１における、デバイスにおけるＦＷ更新部のフローチャート 実施例１における、デバイスにおけるアプリ更新部のフローチャート 実施例１における、配信システムにおける配信設定確認リクエストの処理のフローチャート 実施例１における、配信システムにおけるアプリ更新通知リクエストの処理のフローチャート 実施例１における、配信システムにおけるアプリ起動状態通知リクエストの処理のフローチャート 実施例３における、配信システムにおけるデフォルト起動状態判断部の処理のフローチャート 実施例４における、アプリ更新の配信シーケンス例 実施例４における、デバイスにおけるアプリ更新部のフローチャート 実施例４における、アプリ更新通知リクエストの処理のフローチャート

以下、本発明を実施するための形態について図面を用いて説明する。なお、フローチャートの記述においては、各ステップを「Ｓ」で表す。

＜実施例１＞
図１は実施例１のシステム構成を示すブロック図である。配信システム１０はＷｅｂサーバ１２、ＤＢサーバ１３及びアプリケーションサーバ１１を備える。Ｗｅｂサーバ１２はインターネット１００に接続されており、配信システム１０はＷｅｂサーバ１２を介して顧客企業１１４のデバイス１１５〜１１７、顧客企業１１９のデバイス１２０〜１２７、顧客企業１２９のデバイス１３１と通信を行う。これにより、アプリケーションソフトウェア（以後「アプリ」と略記）及びファームウェア（以後「ＦＷ」と略記）の配信制御を行う。

アプリ及びＦＷの実ファイルはコンテンツサーバ２０にあり、デバイスへアプリをインストールする場合には、配信システム１０からコンテンツサーバ２０上の実ファイルの位置情報を取得し、コンテンツサーバ２０からアプリをダウンロードする。これにより、多くのデバイスのアプリ配信の負荷を分散し効率良くアプリの配信を行うことが出来る。アプリ及びＦＷの更新も同様である。コンテンツサーバ２０は、コンテンツ管理サーバ２１およびファイル・ストレージ２２、２３を備える。コンテンツ管理サーバ２１は、外部からのリクエストに従って、ファイル・コンテンツすなわちアプリ及びＦＷを保存、あるいは提供する。

顧客企業のデバイスには、マルチ・ファンクション・プリンタ（ＭＦＰ）や、シングル・ファンクション・プリンタ（ＳＦＰ）等の種類があり、デバイスのモデル毎に一つあるいは複数の機能が搭載されている。それらの機能を実現するためのＦＷがインストールされることにより、デバイスの各機能が利用可能となる。また、デバイスのモデル毎、あるいは、デバイスのモデルに共通で実行可能なアプリをインストールして実行することが可能である。各アプリは、デバイスのＦＷと独立して実行、停止が可能である。デバイスの利用者は、そのデバイスで利用可能な複数のアプリの中から、所望のものを選び、ライセンスを購入するなどして入手することにより、インストールを行う。また、デバイスのアプリの不具合が修正された場合や機能の改善あるいは追加された場合には、アプリを更新することで、それらを利用することが出来る。

本実施例では、デバイスとしてＭＦＰおよびＳＦＰを例に挙げているが、これに限るものではない。すなわち、配信システム１０によるアプリの自動配信が為される一方で、デバイス本体の機能とは独立して、インストール、アンインストール、起動、停止が制御可能なアプリが利用可能なデバイスであれば、本発明の技術は有効である。他に本発明が有効な例としては、インターネットに接続された家電、電子制御機器を複数搭載する車両、あるいは携帯電話などが挙げられる。

販売会社システム３０は、デバイスを各顧客企業１１４、１１９、１２９へ販売し、維持、管理するデバイスの製造会社あるいはデバイスの販売会社がアプリ及びＦＷの登録・管理のための操作をする。販売会社システム３０は、１台以上のＰＣ３１、３２あるいはサーバ３３、３４を備える。販売会社システム３０から配信システム１０およびコンテンツサーバ２０へアクセスすることにより、アプリ及びＦＷの登録と配信設定を行う。

図２は本実施例のハードウェア構成を示すブロック図である。アプリケーションサーバ１１は、バス２０５を介して接続されたＣＰＵ２０１、ＲＡＭ２０２、ＲＯＭ２０３、ネットワークインタフェース２０４、ＨＤＤ２０６等を備える。また、アプリケーションサーバ１１は、ネットワークインタフェース２０４を介してＷｅｂサーバ１２やＤＢサーバ１３と互いに接続されている。配信システム１０はＨＤＤ２０６やＲＯＭ２０３、ＲＡＭ２０２に記録されたデータ及びプログラムを読み出してＣＰＵ２０１で実行することにより実現される。また、その機能は、複数のサーバの機能の連携によって実現される場合もある。ネットワークインタフェース２０４は、配信システム１０内のサーバ間の機能連携に使われると共に、インターネット１００を介して、外部システムと通信するためにも使用される。なお、図２はアプリケーションサーバ１１に対応して図示しているが、デバイスも同様のハードウェア構成を持っているものとする。

図３は、本実施例における配信システム１０の機能構成を示すブロック図である。デバイス（ネットワークデバイス）４００は配信システム１０に接続するデバイスの一例である。Ｗｅｂブラウザ３０２は、配信システム１０に接続する販売会社システムの一例としてのクライアントシステムである。

Ｗｅｂインターフェース部３１０はデバイス４００に対するアプリ及びＦＷの配信機能を提供するものであり、各デバイスから各種リクエストを受信し、処理結果を返却する。例えば、アプリ配送情報のリクエストを受信すると、対象とするアプリの格納されている場所を検索し、アプリを取得するためのＵＲＬとして返却する。リクエスト処理の詳細については、後述する。

ユーザインタフェース部３１１は、配信システムにアクセスして、アプリ及びＦＷの登録や配信設定を行う。リクエスト受信部３１２はデバイスからのリクエストを受信する。レスポンス返信部３１３はデバイスへレスポンスを返す。配信設定制御部３１４はＦＷおよびアプリの配信設定を制御するものであり、デバイス管理部３１５、アプリ配信設定部３１７、ＦＷ配信設定部３１８を制御して、ユーザインタフェース部３１１で表示する配信設定のための画面の出力内容を決定する。デフォルト起動状態判断部３１９は、アプリ配信設定部３１７から呼び出されて、デフォルト起動状態を判断する。

ＤＢアクセス部３２０は、各種処理に応じて、データ管理部３３０で管理されている以下のテーブルのデータを更新あるいは検索する。即ち、登録アプリ管理テーブル３３１、更新可能アプリ管理テーブル３３２は、登録ファームウェア管理テーブル３３３、デバイス管理テーブル３３４、インストール済みアプリ管理テーブル３３５、アプリ配信管理テーブル３３６である。また、ＦＷ配信管理テーブル３３７、更新後状態テーブル３３８である。

デバイス４００の構成は以下の通りである。メイン処理部３４０はデバイス４００の本来の主機能（例えば、プリンターであれば画像形成処理）を処理する。デバイス４００は、この主機能の他に、デバイスのＦＷおよびアプリの配信制御を行うための機能も備えている。その機能を処理するのが以下の機能ブロック３４１〜３４８である。

ブロック３４１は、配信システム１０からアプリ及びＦＷの配信を受けるためのＷｅｂインターフェース部であり、配信システム１０のＷｅｂインターフェース部３１０と接続されている。ブロック３４２は配信処理部である。ブロック３４３はアプリインストール部である。ブロック３４４はアプリ更新部である。ブロック３４５はＦＷ更新部である。ブロック３４６はアプリ起動制御部である。ブロック３４７は配信されたＦＷを格納するＦＷ格納部である。ブロック３４８は配信されたアプリを格納するアプリ格納部である。

図４は、デバイスのアプリ及びＦＷをインストールあるいは更新するために、デバイスを維持、管理するサービスマン、および、デバイスの利用者の操作によってデバイス及び配信システムを操作する時の流れの例を示すシーケンス図である。利用者４０１がデバイス４００を利用し、サービスマン４０２がデバイス４００に対して、アプリおよびＦＷの更新のために、配信システム１０へのリモート配信の設定操作を行う。

点線４０９で囲まれた範囲は利用者４０１が新しいアプリをインストールする時のシーケンスを示している。利用者４０１は新しいアプリをデバイス４００へインストールするために、デバイス４００のユーザインタフェースを操作し、アプリのインストール指示を出す（４１０）。この指示に対応してデバイス４００は、インストールするアプリを特定する情報を配信システム１０へ送り、対応するアプリを要求する（４１１）。これに対して配信システム１０は、デバイス４００からのリクエストをＷｅｂインターフェース部３１０で処理する。Ｗｅｂインターフェース部３１０は、リクエストで渡されるアプリ名称あるいはアプリＩＤを持って登録アプリ管理テーブル３３１からアプリのＵＲＬを検索する。配信システム１０は、検索したＵＲＬを、プログラムファイルをダウンロードするためのＵＲＬとして、デバイス４００へ返却する（４１２）。以後、配信システム１０が処理するデバイス４００からのリクエストは、Ｗｅｂインターフェース部３１０で処理されるものとして説明を続ける。

デバイス４００は返却されたＵＲＬでコンテンツサーバ２０にアクセスし、インストールするアプリのファイルを要求する（４１３）。その応答（４１４）で取得したアプリのファイルを使用して、デバイス４００はアプリのインストール処理を行う（４１５）。インストール処理が終了しインストールしたアプリが起動すると、デバイス４００は配信システム１０へ、新しいアプリがインストールされたことを通知する（４１６）。デバイス４００からアプリのインストール通知を受けると、配信システム１０はそれを記録し、デバイスに現在インストールされているアプリの情報を更新する（４１７）。この時、通知を受けた対象デバイスにおける対象アプリの動作状態（稼働状態）が「起動」中であることも記憶しておく。配信システム１０は、アプリの状態を記録すると、デバイス４００へ応答を返す（４１８）。

次に、点線４２０で囲まれた範囲は、利用者４０１がインストールされたアプリを停止する時のシーケンスを示している。アプリのインストール後、何らかの理由でアプリの動作を停止させたい場合、利用者４０１は、デバイス４００のユーザインタフェースを操作し、アプリの停止指示を出す（４２１）。これに応じて、デバイス４００は対象アプリの実行を停止する（４２２）。そして、配信システム１０へ当該アプリの状態を通知し、停止状態になったことを伝える（４２３）。停止の通知を受けた配信システム１０は、それを記録し、対象アプリの動作状態が「停止」中として、現在インストールされているアプリの情報を更新する（４２４）。そして、デバイス４００へ応答を返す（４２５）。

点線４３０で囲まれた範囲は、利用者４０１が停止中のアプリを再起動する時のシーケンスを示している。利用者４０１は、デバイス４００のユーザインタフェースを操作し、アプリの起動指示を出す（４３１）。これに応じて、デバイス４００は対象アプリの実行を開始する（４３２）。そして、配信システム１０へ当該アプリの状態を通知し、起動状態になったことを伝える（４３３）。起動の通知を受けた配信システム１０は、それを記録し、対象アプリの動作状態が「起動」中として、現在インストールされているアプリの情報を更新する（４３４）。そして、デバイス４００へ応答を返す（４３５）。

点線４２０と４３０で囲まれた範囲の処理は、利用者の意図に従って、どのタイミングでも実施可能である。配信システム１０は、アプリ起動状態通知（４２３、４３３）に従って、随時、配信システム１０内のアプリ状態情報を更新する。

点線４４０で囲まれた範囲は、サービスマン４０２によって、アプリの更新のための配信予約設定４４１を操作することを示している。また、点線４４２で囲まれた範囲は、サービスマン４０２によって、ＦＷの更新のための配信予約設定４４３を操作することを示している。点線４４０と４４２の範囲の処理は、サービスマン４０２によってどのタイミングでも実施可能であるが、点線４４０の範囲については、対象デバイスに設定対象のアプリがインストールされていることが前提となる。本実施例における説明においては、点線４４０と４４２の範囲の処理は排他的に実施されるものとするが、両者を同時に実施することも可能である。

点線４４４で囲まれた範囲は、デバイス４００から配信システム１０に対して、定期的に問い合わせる配信設定確認のシーケンスを示している。デバイス４００は、所定の周期あるいは決められたタイミングにおいて、配信システム１０に、デバイス４００向けのアプリ更新あるいはＦＷ更新の設定があるかどうかを問い合わせる（４４５）。配信システム１０は、アプリ更新あるいはＦＷ更新の配信設定の有無と配信設定がある場合には、その情報をデバイス４００へ応答する（４４６）。

図５はアプリ更新の配信設定がある場合の流れを示すシーケンス図である。処理４４１、４４５、４４６は、図４に示す同じ番号のシーケンスと同じものを示している。まず、サービスマン４０２がアプリの更新予約を設定（４４１）すると、配信システム１０はその後のデバイス４００からの配信設定確認（４４５）で配信設定情報を返す（４４６）。ここで返された配信設定情報には、配信日時情報、配信識別情報及び更新後の実行状態指示情報が含まれる。デバイス４００は、予約された配信日時（４５２）になると、配信システム１０へ配信識別情報を送り、対応するアプリを要求する（４５３）。これに対して、配信システム１０は、リクエストで渡される配信識別情報からアプリ配信管理テーブル３３６を検索して、アプリＩＤとバージョンを特定し、さらに登録アプリ管理テーブル３３１からアプリのＵＲＬを検索する。配信システム１０は、検索したＵＲＬを、プログラムファイルをダウンロードするためのＵＲＬとして、デバイス４００へ返却する（４５４）。デバイス４００は返却されたＵＲＬでコンテンツサーバ２０にアクセスし、インストールするアプリのファイルを要求する（４５５）。コンテンツサーバ２０はそのアプリのファイルをデバイス４００に返す（４５６）。

点線４５７で囲まれた範囲は、対象となるアプリのデバイスにおける動作状態によって処理の有無が変わる。更新対象となるアプリが動作している場合は、デバイス４００は、対象アプリを停止する（４５８）。その後、応答（４５６）で取得したアプリのファイルを使用して、アプリの更新処理を行う（４５９）。

点線４６０で囲まれた範囲は、処理４４６で取得した配信設定情報に従って処理の内容が変わる。取得した配信設定情報の更新後実行状態指示がアプリを起動状態とする場合には、更新処理後、対象アプリの起動処理を行う（４６１）。その後、デバイス４００は、配信システム１０へアプリの更新完了及び更新後の実行状態を通知する（４６２）。更新の通知を受けた配信システム１０はそれを記録し、対象アプリの動作状態を更新する（４６３）。そして、デバイス４００へ応答を返す（４６４）。

図６は、ＦＷ更新の配信設定がある場合の流れを示すシーケンス図である。処理４４３、４４５、４４６は、図４に示す同じ番号のシーケンスと同じものを示している。まず、サービスマン４０２がＦＷの更新予約を設定（４４３）すると、配信システム１０は、その後のデバイス４００からの配信設定確認（４４５）で配信設定情報を返す（４４６）。ここで返された配信設定情報には、配信日時情報、配信識別情報が含まれる。デバイス４００は予約された配信日時（４７２）になると、配信システム１０へ配信識別情報を送り、対応するＦＷを要求する（４７３）。これに対して、配信システム１０は、渡された配信識別情報からＦＷ配信管理テーブル３３７を検索して、バージョンを特定し、さらに登録ファームウェア管理テーブル３３３からＦＷのＵＲＬを検索する。配信システム１０は、検索したＵＲＬをプログラムファイルをダウンロードするためのＵＲＬとして、デバイス４００へ返却する（４７４）。

デバイス４００は、返却されたＵＲＬでコンテンツサーバ２０にアクセスし、インストールするＦＷのファイルを要求する（４７５）。コンテンツサーバ２０は要求されたファイルをデバイス４００に返す（４７６）。デバイス４００は、応答（４７６）で取得したＦＷのファイルを使用して、ＦＷの更新処理（４７７）を行って再起動する（４７８）。再起動後、デバイス４００は、配信システム１０へ更新後のバージョン情報を含めてＦＷの更新通知を送る（４７９）。配信システム１０は、デバイス４００からの更新通知によって、渡された更新後バージョンの情報でデバイス管理テーブル３３４を更新する。これにより、配信システム１０に保持している、デバイス４００のＦＷの現在バージョンの情報が更新される。配信システム１０はデバイス４００へ応答を返し（４８１）、これによりこのシーケンスは終了する。

次に、処理４４１に示すアプリの配信設定における設定方法について説明する。図７に、サービスマン４０２がＷｅｂブラウザ３０２を使用して、アプリあるいはＦＷの更新のために配信設定を行うために最初に表示されるユーザインタフェース画面の例を示す。

図７の画面５００では、まず、更新対象の配信ソフトウェア種別選択と配信対象デバイスの検索を行う。ラジオボタン５０１は配信ソフトウェア種別を選択するためのボタンである。ＦＷ更新の配信設定の場合には「ファームウェア配信」を選択し、アプリ更新の配信設定の場合には「アプリケーション配信」を選択する。フィールド５０２には、所定のＦＷバージョンを持つデバイスを選択するための検索条件を入力する。フィールド５０３には、所定のアプリがインストールされているデバイスを選択するための検索条件を入力する。フィールド５０４には、所定のアプリのバージョンがインストールされているデバイスを選択するための検索条件を入力する。フィールド５０５は、特定の機種のデバイスを選択するために、デバイスモデル名を検索条件に入力する。フィールド５０６には、予め、対象デバイスの一覧が分かっている場合に、対象デバイスのデバイスＩＤが記述されたファイルを入力する。各デバイスには、個体を識別するためのＩＤとしてシリアル番号が付与されており、これをデバイスＩＤと呼ぶ。デバイスＩＤは製造会社および販売会社によって管理されている。そして、商品であるデバイス個体を管理するとともに、ある一定範囲のデバイスＩＤを同じモデルの商品として管理する。フィールド５０６に、ファイルを入力後、アップロードボタン５０８を押下することによって、対象デバイス一覧を対象として表示することができる。ラジオボタン５０１で、“ファームウェア配信”を選択し、フィールド５０２、５０５に検索条件を入力して、検索ボタン５０７を押下することにより、配信システム１０が管理するデバイス群の中から検索条件に合った一覧を表示する画面（不図示）へ遷移する。また、検索条件の代わりに、対象デバイスのデバイスＩＤが記述されたファイルをフィールド５０６に入力して、アップロードボタン５０８を押下することによって、対象デバイス一覧を対象として表示する画面（不図示）へ遷移する。

ラジオボタン５０１で“アプリケーション配信”を選択し、フィールド５０３〜５０５に検索条件を入力し、検索ボタン５０７を押下すると、配信システム１０が管理するデバイス群の中から検索条件に合った一覧を表示する次の画面（図８の５２０）へ遷移する。また、検索条件の代わりに、対象デバイスのデバイスＩＤが記述されたファイルをフィールド５０６に入力して、アップロードボタン５０８を押下することによって、対象デバイス一覧を対象として表示する次の画面（図８の５２０）へ遷移する。

図８に、“アプリケーション配信”について、配信対象デバイスを選択するために表示されるユーザインタフェース画面の例を示す。画面５２０の画面は図７の５００から遷移して表示される。また、画面５２０の中で検索条件を変えてデバイスの一覧を表示しなおすことも出来る。項目５２１〜５２８のユーザインタフェースは、図７における項目５０１〜５０８に対応して同じ機能を持つものとする。図８における例では、ラジオボタン５２１に示すように、「アプリケーション配信」のための設定画面になっていることを示している。

図８の画面５２０の下部には、検索あるいは一覧ファイルのアップロードにより一覧表示されたデバイスが表示される。欄５３０は配信対象デバイスを選択するチェックボックスを示す。欄５３１はサービスマン４０２から見た対象デバイスの顧客、すなわち利用者の顧客名を示す。欄５３２は個々のデバイスを識別するデバイスＩＤを示す。欄５３３はそのデバイスのモデル名を示す。欄５３４はそのデバイスで動作しているＦＷのバージョンを示す。欄５３５はそのデバイスにインストールされているアプリ（複数の場合あり）のアプリ名を示す。欄５３６はアプリ毎に個々のアプリを識別するアプリＩＤを示す。欄５３７はアプリ毎にそのアプリのバージョンを示す。

欄５３８はアプリ毎にそのアプリのデバイスにおける実行状態を示す。実行状態は、「起動」、「停止」、「不明」のいずれかである。図４における処理４１６、４２２、４３２、図５における処理４６１で通知された情報がある場合には、「起動」あるいは「停止」が表示される。通信上の不具合がある、デバイス側で起動状態情報を通知しない設定になっている、あるいは、通知する機能が無いデバイス等では、「不明」が表示される場合もある。欄５３９はアプリ毎に使用可能なライセンスの残数（例えば残日数）を示す。残数制限がある場合、デバイスから残数の情報が通知されれば、この欄に残数を示す数値が表示される。残数制限が無い場合や、情報が通知されない場合には、「Ｎ／Ａ」が表示される。画面に表示し切れないデバイスリストがある場合は、スクロールバー５４０を用いて参照することができる。
図８では、ラジオボタン５０１で配信の種別として“ファームウェア配信”を選択した場合の検索などにより表示される前述した対象デバイス一覧とは異なり、欄５３５〜５３９などに示すアプリケーション配信に特有な情報も表示される。

図８の画面５２０を参照するサービスマン４０２は、ここで検索条件を変えながら、デバイス一覧を表示しなおして、最終的な配信対象のデバイスを欄５３０のチェックボックスで決定する。そして、デバイス一覧確定のための「次へ」ボタン５４１を押下することで、配信設定を行う次の画面（図９の５６０）へ遷移する。

図９に、更新アプリと配信設定を対象デバイスに対して設定するために表示されるユーザインタフェース画面の例を示す。画面５６０はアプリ更新のための配信設定のユーザインタフェース画面である。フィールド５６１は更新するアプリをアプリ名で指定するものである。ここでアプリを指定することにより、画面下部に表示されるデバイス一覧において、フィールド５６１で選択したアプリが現在インストールされているデバイスだけが配信対象として絞り込まれて表示が更新される。フィールド５６２は更新するアプリをアプリＩＤで指定するものである。フィールド５６２で選択した結果はフィールド５６１にも反映され、対応するアプリ名が表示される。逆にフィールド５６１で選択されたアプリ名に対応するＩＤでフィールド５６２も同時に更新されるものとする。フィールド５６１と同様に、下部に表示されるデバイス一覧も、そのアプリがインストールされたデバイスに更新される。フィールド５６３は更新するアプリのバージョンを指定するものである。

配信システム１０は、各デバイスにインストールされているアプリの一覧および、配信可能なアプリのバージョンを保持している。したがって、公知の技術により、フィールド５６１、５６２、５６３は、有効なアプリとバージョンのみを表示するドロップダウンメニューとすることも可能である。

図９の画面５６０の下部には、配信対象として絞り込まれたデバイスの一覧が表示される。このユーザインタフェースにおいて、欄５７４に示す配信日時、および、欄５７５に示す配信後状態をデバイス毎に設定することができる。さらに、欄５６４に示す配信日時の一括設定、および、欄５６５の配信後状態の一括設定によって、一覧に表示されたデバイス全てに同じ設定を一括設定することも可能である。

欄５６６は配信対象として絞り込まれたデバイスの利用者の顧客名を示す。欄５６７は配信対象として絞り込まれたデバイスＩＤを示す。欄５６８は配信対象として絞り込まれたデバイスのモデル名を示す。欄５６９は配信対象として絞り込まれたデバイスで動作しているＦＷのバージョンを示す。欄５７０は５６１および５６２で指定されたアプリの、そのデバイスにインストールされているバージョンである。欄５７１はフィールド５６１および５６２で指定されたアプリの、そのデバイスにおける実行状態を示す。欄５７２はフィールド５６１および５６２で指定されたアプリの、そのデバイスにインストールされているバージョンから、フィールド５６３で指定されたバージョンへの更新が可能か否かを示す。欄５７２に「可」と表示されれば、アプリ更新の配信が可能であり、「不可」と表示されれば、そのデバイスに対するアプリ更新の配信設定はされない。欄５７３はフィールド５６１および５６２で指定されたアプリの、そのデバイスにおけるライセンス残数情報を示す。

サービスマン４０２は、欄５６６〜５７３の情報を参照しながら、欄５７４の配信日時および欄５７５の配信後状態をデバイス毎に設定する。欄５７４に設定された配信日時は、図５における処理４４６で各デバイスに返却され、予約日時（４５２）のタイミングとなる。欄５７５および５６５では、「起動」、「停止」、「維持」、「自動」の４つの状態を選択することが出来る。「起動」を選択すると、図５の処理４４６で返却される更新後起動状態として「起動」が指定される。同様に「停止」「維持」も更新後起動状態として指定される。「自動」の場合には、配信システム１０によって自動判断された結果が指定される。画面に表示し切れないデバイスリストがある場合は、スクロールバー５７６を用いて参照することができる。

サービスマン４０２はフィールド５６１〜５６３で更新対象のアプリと更新後のバージョンを指定し、欄５６４、５６５、５７４、５７５で各デバイスの配信設定を入力した後、「登録」ボタン５７８を押下する。このようにして、各デバイスに対する配信設定（図５の処理４４１）が完了する。「戻る」ボタン５７７を押下すると、図８の画面５２０に戻る。「キャンセル」ボタン５７９を押下すると、配信設定を中止する。

なお、本実施例において、不図示の画面により、図７のラジオボタン５０１で「ファームウェア配信」を選択した場合にも、図８、図９に示すアプリ配信設定画面と同様に、対象デバイス毎にＦＷのバージョン選択及び配信日時指定が出来るものとする。また、「ファームウェア配信」を選択した場合、図８の項目５３０〜５４１に相当する情報は表示されず、図９のユーザインタフェース画面に相当する画面も表示されない。

以下、表を用いて、アプリ、ＦＷ、デバイスのそれぞれの管理情報と、アプリの配信情報の例を説明する。まず、表Ａに登録アプリ管理テーブル３３１に格納されているアプリの管理情報の例を示す。

アプリの管理情報は、登録ＩＤ、アプリＩＤ、アプリ名、バージョン、ＵＲＬの組合せの一覧を含む。あるバージョンの一つのアプリファイルは、アプリＩＤとバージョンの組合せで一意に識別され、ＵＲＬに示すコンテンツサーバ２０上の記憶場所に格納される。登録されたアプリの管理情報には一意の登録ＩＤが付与され、管理情報の中で識別できる。また、ユーザインタフェース上での表示において分かり易いようにアプリ名を付けることが出来る。アプリの管理情報は、販売会社システム３０から担当者がアプリを登録する際に入力され、更新されることで維持される。

デバイスにインストールされたアプリをバージョンアップなどで更新する場合、更新可能なバージョンを識別するために、配信システム１０は、更新可能なアプリの組合せも管理する。表Ｂに更新可能アプリ管理テーブル３３２に格納されている更新可能なアプリの組合せ管理情報の例を示す。

更新可能アプリの管理情報は、表Ａに示す管理情報によって管理される登録ＩＤを使用して、更新前後の登録ＩＤの組合せの一覧を含む。表Ｂに存在する、更新元の登録ＩＤと更新後の登録ＩＤの組合せが表Ｂに示す管理情報に存在する場合のみ、その登録ＩＤ間での更新が可能であることを示す。この組み合わせによる判断結果が、例えば図９における欄５７２（配信）に反映される。更新可能アプリの管理情報は、販売会社システム３０から担当者がアプリを登録する際に入力され、更新されることで維持される。

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

ＦＷの管理情報は、デバイスモデル、バージョン、ＵＲＬの組合せの一覧を含む。デバイスモデルとバージョンの組合せに対応するＦＷのファイルは、ＵＲＬに示すコンテンツサーバ２０上の記憶場所に格納される。ＦＷについてもアプリと同様に、不図示の管理情報によって、更新可能なバージョンの組合せを管理する。ＦＷの管理情報は、販売会社システム３０から担当者がＦＷを登録する際に入力され、更新されることで維持される。

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

デバイスの管理情報は、デバイスＩＤ、デバイスモデル、バージョン、顧客名の組合せの一覧を含む。モデルは、デバイスＩＤで識別されるデバイスのモデルである。バージョンは、そのデバイスで現在動作しているＦＷのバージョンを示す。顧客名は、そのデバイスを所有する顧客名である。

デバイスの状態を示すもう一つの情報として、各デバイスにインストールされているアプリとその状態の情報がある。表Ｅにインストール済みアプリ管理テーブル３３５に格納されているデバイスのインストール済みアプリ情報の例を示す。

インストール済みアプリ情報は、デバイスＩＤ、アプリＩＤ、バージョン、動作状態、ライセンス残数、残数対応の組合せの一覧を含む。デバイスＩＤとアプリＩＤ、バージョンの組合せによって、デバイスＩＤに示すデバイスにアプリＩＤとバージョンの組合せが示すアプリがインストールされていることを示す。また、動作状態はそのアプリの動作状態を示す。残数対応は、ライセンス残数の情報が有効な場合にはＴＲＵＥ、ライセンス残数の情報が無効な場合にはＦＡＬＳＥとなるフラグである。ライセンス残数は、そのデバイスにおけるアプリのライセンス残数を示す。残数対応がＦＡＬＳＥの場合には、ライセンス残数の値は使用しない。

表Ｆに、アプリ配信管理テーブル３３６に格納されているアプリの配信情報の例を示す。図９に示す画面５６０においてアプリの配信設定が登録されると、表Ｆに示すアプリ配信情報が更新されて、配信設定のレコードが追加される。アプリ配信情報は、配信ＩＤ、デバイスＩＤ、アプリＩＤ、バージョン、配信日時、状態指示の組合せの一覧を含む。配信ＩＤは、残りの列の組合せで配信設定が追加される時に一意の識別子を生成して設定する。

図１０に配信システム１０における配信設定のフローチャートの例を示す。図１０の処理は、図４の処理４４１および４４３に対応して配信設定制御部３１４で処理されるものであり、図７から図９に示す画面表示に対応する。

図４の処理４４１あるいは４４３によるサービスマン４０２からの更新予約操作により、配信設定処理が開始する（Ｓ１２００）。配信設定制御部３１４は、Ｓ１２０１で、デバイス検索画面（図７）をユーザインタフェース部３１１へ表示する。図７におけるラジオボタン５０１で配信種別が、フィールド５０２〜５０５で検索条件が入力され、検索ボタン５０７が押下されると、Ｓ１２０２からＳ１２０４へ進む。一方、配信種別が入力され、フィールド５０６で一覧ファイルが入力され、アップロードボタン５０８が押下されると、Ｓ１２０２からＳ１２０３へ進む。

配信設定制御部３１４は、Ｓ１２０３では、アップロードされたファイルからデバイスＩＤの一覧を読み込み、Ｓ１２０４では、デバイス管理部３１５を呼び出す。デバイス管理部３１５は、Ｓ１２０４にて、検索条件に合致するデバイスの一覧を、デバイス管理テーブル３３４およびインストール済みアプリテーブル３３５から検索する。これらによって得られたデバイス一覧に対して、配信設定制御部３１４は、デバイス管理部３１５を呼び出し、デバイス状態情報を取得する（Ｓ１２０５）。

次に配信設定制御部３１４は、ラジオボタン５０１で指定された配信種別に従って、配信設定の内容を判断して以降の処理を切り替える（Ｓ１２０６）。つまり、ＦＷの場合にはＳ１２０７へ進み、処理４４３に対応する配信設定を行い、アプリの場合にはＳ１２０９へ進み、処理４４１に対応する配信設定を行う。

Ｓ１２０７で、ＦＷ配信設定部３１８はＦＷ配信設定画面を表示し、ＦＷの配信設定を行ない、そして、ＦＷ配信管理テーブル３３７を更新する。これにより、配信設定処理は終了する（Ｓ１２０８）。

Ｓ１２０９では、配信設定制御部３１４は、対象デバイス選択画面（図８）をユーザインタフェース部３１１へ表示する。ここで、図８の画面５２０の下部にはＳ１２０５で取得したデバイス状態情報を表示する。Ｓ１２１０で、配信設定制御部３１４は、押下されたボタンによって、次の画面遷移あるいは表示の更新を判断する。検索ボタン５２７が押された場合にはＳ１２１１へ進み、デバイス管理部３１５がデバイスの検索を行う。アップロードボタン５２８が押下された場合にはＳ１２１２へ進み、デバイスＩＤの一覧を読み込む。いずれの場合も、デバイス管理部３１５がデバイス状態情報取得（Ｓ１２１３）を行い、配信設定制御部３１４がデバイス状態情報を更新する（Ｓ１２１４）。そして、対象デバイス一覧が確定されるまで図８の画面５２０の更新を繰り返す。

Ｓ１２１０で「次へ」ボタン５４１が押下されると、Ｓ１２１５へ進む。Ｓ１２１５では、アプリ配信設定部３１７が、選択された対象デバイスの中で、選択されたアプリの情報だけに絞り込む。これは、アプリ配信設定部３１７の内部の処理であるが、絞り込まれた内容は、図９における一覧表示の内容に相当する。Ｓ１２１６では、アプリ配信設定部３１７が、更新可能アプリ管理テーブル３３２を検索し、更新するアプリのバージョン情報と絞り込まれたデバイス状態情報から、各デバイスのアプリが更新可能か否かを判断する。これは、図９の欄５７２に表示される内容に相当する。

Ｓ１２１７で、デフォルト起動状態判断部３１９が、絞り込まれている各デバイスのアプリに対して、更新後の起動状態を決定する。これは、図９の欄５７５の初期表示及び、欄５６５において「自動」が選択された時に設定される内容に相当する。Ｓ１２１８で、配信設定制御部３１４は、アプリ配信設定画面（図９）をユーザインタフェース部３１１へ表示する。ここで、図９に一覧表示される初期値は、Ｓ１２１５〜Ｓ１２１７で決定した内容に従う。

次に、図９に示す画面の入力操作に従って、バージョンの選択とアプリの選択が変更されたかどうかを判断する（Ｓ１２１９、Ｓ１２２０）。フィールド５６３でバージョンの選択が変更された場合は、Ｓ１２１９からＳ１２１５に戻り、デバイス状態情報の絞り込み表示、及び配信可否（欄５７２）と更新後起動状態（欄５７５）の設定表示を更新する。フィールド５６１あるいは５６２でアプリの選択が変更された場合には、Ｓ１２２０からＳ１２１５に戻り、同様に設定表示を更新する。

さらに、図９の入力画面の中で、いずれかの操作ボタンが押下されたかどうかを判定する（Ｓ１２２１）。各デバイスへの配信日時および更新後起動状態が全て設定され、「登録」ボタン５７８が押下されると、Ｓ１２２１からＳ１２２２へ進む。Ｓ１２２１で「戻る」ボタン５７７が押下されたと判断された場合には、Ｓ１２０９、すなわち図８の画面の処理へ戻る。Ｓ１２２１で「キャンセル」ボタン５７９が押下されたと判断された場合には、Ｓ１２２３へ進み、処理を終了する。Ｓ１２２２で、アプリ配信設定部３１７が図９の画面に手入力された内容をアプリ配信管理テーブル３３６へ反映する。この後、Ｓ１２２３へ進み、処理を終了する。

次に、デフォルト起動状態判断部３１９におけるＳ１２１７の処理における判断方法について説明する。表Ｇに更新後状態テーブル３３８に格納されているアプリ更新後の起動状態指定値情報の例を示す。

起動状態指定値情報は、更新前登録ＩＤ、更新後登録ＩＤ、更新後起動状態の組合せの一覧を含む。更新前登録ＩＤは、デバイスにインストールされているアプリの登録ＩＤである。また、更新後登録ＩＤは、配信設定を行う更新後のアプリの登録ＩＤである。ここで、登録ＩＤは、登録アプリ管理テーブル３３１で管理されているものを参照する。つまり、更新前登録ＩＤと更新後登録ＩＤの組合せに合致するアプリ配信設定がされるデバイスは、配信設定画面表示の配信後状態（欄５７５）の初期値は、この更新後起動状態で定義された値を使用する。該当する組み合わせが存在しない場合には、「維持」を初期値とする。

また、更新前登録ＩＤあるいは更新後登録ＩＤが「＊」になっている場合には、任意の登録ＩＤが合致すると判断する。例えば、表Ｇにおける３行目の例では、任意の登録ＩＤのアプリから登録ＩＤが１２２２にアプリ配信設定されるデバイスについては、初期値として「起動」を指定することを意味する。また、４行目の例では、登録ＩＤが１２１２のアプリからアプリ配信設定される場合には、初期値として「停止」を指定することを意味する。表Ｇの記述方法の例においては、任意の登録ＩＤの組合せを記述可能であるが、実際には、同じアプリＩＤでなければ更新出来ないため、異なるアプリ間の設定は参照されない。また、更新可能アプリ管理テーブル３３２によって更新可能な組み合わせが決定されるため、更新不可能な組み合わせについては、無効な設定となる。起動状態指定値情報は、販売会社システム３０から担当者がアプリを登録する際に入力され、更新されることで維持される。

次にデバイス側の配信処理について説明する。図１１は、デバイス４００における配信処理のフローチャートの例である。図１１は、デバイスの起動から、アプリおよびＦＷの配信を受ける処理全体を表す。この処理は配信処理部３４２で実行されるものである。

まず、Ｓ１０００でデバイス４００の電源が入ると、配信処理部３４２は、電源投入前にＦＷの更新処理があったかどうかを判断する（Ｓ１００１）。これは、後述の図１５におけるＳ１１０４の記録情報を確認して行なう。ＦＷの更新があった場合には、Ｓ１００２にて、ＦＷの更新通知を配信システム１０へ送信する。この通知は、図６の処理４７９に対応する。ここで送信される情報は、表Ｄに対応するデバイス管理テーブルを更新するための情報である。すなわち、デバイス４００のデバイスＩＤ、デバイスモデル、更新後のバージョンである。

次に、Ｓ１００３で、デバイス４００における入力操作を確認する。入力操作がある場合には、その操作に応じてそれぞれの処理を行う。アプリインストールの入力操作（図４の処理４１０）がされた場合（「インストール」）には、Ｓ１００４にて、アプリインストール部３４３を呼び出し、後述の図１２に示す処理を行う。アプリ停止操作（図４の処理４２１）がされた場合（「停止」）には、Ｓ１００５にて、アプリ起動制御部３４６を呼び出し、後述の図１３に示す処理を行う。アプリ起動操作（図４の処理４３１）がされた場合（「起動」）には、Ｓ１００６にて、アプリ起動制御部３４６を呼び出し、後述の図１４に示す処理を行う。

Ｓ１００７では、デバイス４００における配信スケジュールがあるかどうかの判断を行う。これは、後述のＳ１０１６あるいはＳ１０１７において設定されたスケジュールを確認するものである。スケジュールがある場合にはＳ１００８へ進む。Ｓ１００８において、その時点でスケジュールされている配信日時となっているかどうか判断し、当該配信日時になっている場合にはＳ１００９へ進み、未だ配信日時でない場合にはＳ１０１２へ進む。Ｓ１００９では、スケジュールされている配信種別がアプリあるいはＦＷのいずれかを確認する。アプリの場合にはＳ１０１０へ進み、ＦＷの場合にはＳ１０１１へ進む。アプリの場合は図５の処理４５２のタイミングからのシーケンスに対応し、ＦＷの場合は図６の処理４７２のタイミングからのシーケンスに対応する。

Ｓ１０１０では、アプリ更新部３４４を呼び出し、後述の図１６に示す処理を行ない、Ｓ１０１１では、ＦＷ更新部３４５を呼び出し、後述の図１５の処理を行う。Ｓ１０１１のＦＷ更新処理の呼び出し後は、アプリ同様次の処理へ進む。

次に、Ｓ１０１２にて、配信設定の確認を行う。これは、図４、図５、図６におけるシーケンスの処理４４５および４４６に対応する。配信処理部３４２は、処理４４５に対応して、配信システム１０に対して、自身のデバイスＩＤを送信する。デバイス４００に対する配信設定がある場合には、配信処理部３４２は、配信システム１０から配信設定の情報を受信する。処理４４６で受信する配信設定情報は、アプリの配信の場合には、表Ｆにおけるデバイス４００のデバイスＩＤに対応する情報である。配信処理部３４２は、配信システム１０より、アプリの配信設定があるという情報に加えて、配信ＩＤ、アプリＩＤ、バージョン、配信日時、アプリ更新後の状態指示を受信する。

Ｓ１０１３では、配信システム１０からのレスポンスに従って、配信設定の有無を判断する。配信設定がある場合にはＳ１０１４へ進み、配信設定が無い場合にはＳ１００３へ戻り、配信処理を繰り返す。Ｓ１０１４では、配信システム１０から受信した配信日時を記憶する。ここで記憶された配信日時は、Ｓ１００７およびＳ１００８における配信スケジュール有無の判断で参照される。

Ｓ１０１５では、受信した配信種別を判別する。配信システム１０から受信した配信設定がアプリ配信設定であった場合はＳ１０１６へ進み、アプリ配信の配信設定を記憶してアプリ配信をスケジュールする。受信した配信設定がＦＷ配信設定の場合はＳ１０１７へ進み、ＦＷ配信の配信設定を記憶してＦＷ配信をスケジュールする。いずれの場合も配信設定を記憶したら、Ｓ１００３へ戻り、配信処理を繰り返す。表Ｈに、デバイス４００が記憶するアプリ配信の配信設定情報の例を示す。アプリ配信設定情報は、配信ＩＤ、アプリＩＤ、バージョン、配信日時、状態指示の組合せで記憶される。

図１２に、図１１におけるＳ１００４に対応するアプリのインストール処理のフローチャートの例を示す。この処理はアプリインストール部３４３にて実行される。配信処理部３４２から呼び出されると、アプリインストール部３４３はＳ１０３０からの処理を開始する。

Ｓ１０３１では、配信システム１０に対して、インストールするアプリの名称あるいはアプリＩＤを送信して、アプリのファイルをダウンロードするためのＵＲＬを取得する。この処理は図４の処理４１１および４１２に対応する。Ｓ１０３２では、取得したＵＲＬからアプリのファイルをダウンロードする。この処理は図４の処理４１３および４１４に対応する。Ｓ１０３３にて取得したアプリをインストールし、Ｓ１０３４でそのアプリを起動する。これら処理は図４の処理４１５に対応する。

Ｓ１０３５では、アプリの起動が成功して正常に動作しているかどうかを判断し、正常に動作している場合はＳ１０３７へ進み、正常に動作していない場合はＳ１０３６へ進む。Ｓ１０３７では、図４の処理４１６および４１８に対応する、アプリのインストール通知を配信システム１０へ送信する。ここで、アプリインストール部３４３が配信システムへ送信する情報は、表Ｅの情報に対応する。すなわち、デバイス４００のデバイスＩＤ、インストールしたアプリのアプリＩＤとバージョン、動作状態が現在「起動」であること、ライセンスに関する情報がある場合には、残数対応フラグのＴＲＵＥとライセンス残数を送信する。配信システム１０からの応答（処理４１８）が返ってきたら、Ｓ１０３８にて処理を終了して、図１１の処理へ戻る。Ｓ１０３６ではインストールのエラー表示を出し、Ｓ１０３８で処理を終了して、図１１の処理へ戻る。

図１３に、図１１におけるＳ１００５に対応するアプリの停止処理のフローチャートの例を示す。この処理はアプリ起動制御部３４６にて実行される。配信処理部３４２から呼び出されると、アプリ起動制御部３４６はＳ１０５０からの処理を開始する。

まず、Ｓ１０５１にて、指定されたアプリを停止する。この処理は図４の処理４２２に対応する。Ｓ１０５２にて、図４の処理４２３および４２５に対応する、指定されたアプリを停止したことを配信システム１０へ通知する。ここで、アプリ起動制御部３４６が配信システム１０へ送信する情報は、図１２のＳ１０３７で送信する情報と同じく、表Ｅの情報に対応する。ただし、動作状態は現在「停止」であることを通知する。配信システム１０からの応答（処理４２５）が返ってきたら、Ｓ１０５３にて処理を終了して、図１１の処理へ戻る。

図１４に、図１１におけるＳ１００６に対応するアプリの起動処理のフローチャートの例を示す。この処理はアプリ起動制御部３４６にて実行される。配信処理部３４２から呼び出されると、アプリ起動制御部３４６はＳ１０７０からの処理を開始する。

Ｓ１０７１にて、指定されたアプリを起動する。この処理は図４の処理４３２に対応する。Ｓ１０７２で、アプリの起動が成功して正常に動作しているかどうかを判断し、正常に動作している場合はＳ１０７４へ進み、正常に動作していない場合はＳ１０７３へ進む。Ｓ１０７４では、図４の処理４３３および４３５に対応する、アプリが起動したことを配信システム１０へ送信する。ここで、アプリ起動制御部３４６が配信システム１０へ送信する情報は、図１２のＳ１０３７で送信する情報と同じく、表Ｅの情報に対応する。配信システム１０からの応答（処理４３５）が返ってきたら、Ｓ１０７５にて処理を終了して、図１１の処理へ戻る。Ｓ１０７３では起動のエラー表示を出し、Ｓ１０７５で処理を終了して、図１１の処理へ戻る。

図１５に、図１１におけるＳ１０１１に対応するＦＷ更新処理のフローチャートの例を示す。この処理はＦＷ更新部３４５にて実行される。配信処理部３４２から呼び出されると、ＦＷ更新部３４５はＳ１１００からの処理を開始する。

Ｓ１１０１では、配信システム１０に対して、配信設定から得られる配信ＩＤを送信し、更新するＦＷのファイルをダウンロードするためのＵＲＬを取得する。この処理は図６の処理４７３および４７４に対応する。Ｓ１１０２では取得したＵＲＬからＦＷのファイルをダウンロードする。この処理は図６の処理４７５および４７６に対応する。Ｓ１１０３にて、再起動した後にダウンロードしたＦＷで動作するように更新するＦＷをインストールする。そして、再起動時である図１１のＳ１００１でチェックされる更新処理情報を記憶する（Ｓ１１０４）。この処理は図６の処理４７７に対応する。そして、デバイス４００を再起動して終了する（Ｓ１１０５）。

図１６に、図１１におけるＳ１０１０に対応するアプリ更新処理のフローチャートの例を示す。この処理はアプリ更新部３４４にて処理される。配信処理部３４２から呼び出されると、アプリ更新部３４４はＳ１１２０からの処理を開始する。

Ｓ１１２１では、配信システム１０に対して、配信設定から得られる配信ＩＤを送信し、更新するアプリのファイルをダウンロードするためのＵＲＬを取得する。この処理は図５の処理４５３および４５４に対応する。Ｓ１１２２では、取得したＵＲＬからアプリのファイルをダウンロードする。この処理は図５の処理４５５および４５６に対応する。次に、Ｓ１１２３にて、現在の対象アプリの起動状態を記憶する。Ｓ１１２４にて、アプリの起動状態を判断し、起動中の場合（「実行中」）には、Ｓ１１２５へ進み、アプリケーションの停止処理を行う。これは図５の処理４５８に対応する。続いてＳ１１２６に進み、アプリケーションの更新処理を行う。これは図５の処理４５９に対応する。Ｓ１１２４でアプリの起動状態が停止中の場合（「停止中」）には、停止処理なしでＳ１１２６へ進む。

その後、処理４４６で受信しＳ１０１６で記憶した配信設定（表Ｈ）に含まれるアプリ更新後の起動状態指示によって処理を分岐する（Ｓ１１２７）。起動状態指示が停止指示の場合（「停止」）は、停止状態のままで良いのでＳ１１３２へ進む。起動指示の場合（「起動」）はＳ１１２９へ進む。更新前状態を維持する指示（「状態維持」）の場合は、Ｓ１１２８へ進み、Ｓ１１２３で記憶した起動前状態を確認する。Ｓ１１２８において、更新前状態が「起動」であった場合はＳ１１２９へ進み、「停止」であった場合はＳ１１３２へ進む。

Ｓ１１２９ではインストールしたアプリを起動する。この処理は図５の処理４６１に対応する。Ｓ１１３０では、アプリの起動が成功して正常に動作しているかどうかを判断し、正常に動作している場合はＳ１１３２へ、正常に動作していない場合はＳ１１３１へ進む。Ｓ１１３１で、アプリの更新が失敗したことを配信システム１０へ送信する。Ｓ１１３２で、アプリの更新が成功したこと、即ちアプリのインストール通知と同じ情報を配信システム１０へ送信する。ここで、アプリインストール部４３４が配信システム１０へ送信する情報は、図１２のＳ１０３７で送信する情報と同じく、表Ｅの情報に対応する。ただし、動作状態は現在の状態に合わせて「起動」あるいは「停止」を通知する。Ｓ１１３１およびＳ１１３２における配信システム１０への通知は、図５の処理４６２に対応する。配信システム１０からの応答（処理４６４）が返ってきたら、Ｓ１１３３にて処理を終了して、図１１の処理へ戻る。

図１７に、配信システム１０における、デバイス４００からの配信設定確認リクエストの処理のフローチャートの例を示す。この処理は、図４〜図６の処理４４５および４４６に対応して、Ｗｅｂインターフェース部３１０で実行される。処理４４６で各デバイスから配信設定の有無の確認リクエストがくると、Ｓ１３００からの処理を開始する。

先ず、Ｓ１３０１でリクエストを受信する。Ｓ１３０２では、リクエストで渡されるデバイスＩＤを持って、アプリ配信管理テーブル３３６からアプリ配信設定を検索する。Ｓ１３０３では、アプリ配信設定の有無を判断し、アプリ配信設定がある場合はＳ１３０４へ進み、無い場合はＳ１３０６へ進む。Ｓ１３０４では、アプリ配信管理テーブル３３６から対象デバイスＩＤの配信設定情報を取得して、アプリ配信設定情報として返却する。そして処理を終了する（Ｓ１３０５）。

Ｓ１３０６では、リクエストで渡されるデバイスＩＤを持って、ＦＷ配信管理テーブル３３７からＦＷ配信設定を検索する。Ｓ１３０７でＦＷ配信設定の有無を判断し、ＦＷ配信設定がある場合はＳ１３０８へ進み、無い場合はＳ１３１０へ進む。Ｓ１３０８では、ＦＷ配信管理テーブル３３７から対象デバイスＩＤの配信設定情報を取得して、ＦＷ配信設定情報として返却する。そして処理を終了する（Ｓ１３０９）。Ｓ１３１０では、アプリ、ＦＷいずれの配信設定も無いものとして応答を返す。そして処理を終了する（Ｓ１３１１）。

図１８に、配信システム１０における、デバイス４００からのアプリ更新通知リクエストの処理のフローチャートの例を示す。この処理は、図４の処理４１６、および図５の処理４６２に対応して、Ｗｅｂインターフェース部３１０で実行される。処理４１６あるいは４６２で各デバイスからアプリ更新通知のリクエストがくると、Ｓ１３４０からの処理を開始する。

まず、Ｓ１３４１でリクエストを受信する。Ｓ１３４２で、リクエストで渡される表Ｅに対応する情報をもって、インストール済みアプリ管理テーブル３３５を更新し、続けて、Ｓ１３４３で応答を返却する。そして処理を終了する（Ｓ１３４４）。

図１９に、配信システム１０における、デバイス４００からのアプリ起動状態通知リクエストの処理のフローチャートの例を示す。この処理は、図４の処理４２３および４３３に対応して、Ｗｅｂインターフェース部３１０で実行される。処理４２３あるいは４３３で、各デバイスからアプリ起動状態通知のリクエストがくると、Ｓ１３５０からの処理を開始する。

先ず、Ｓ１３５１でリクエストを受信する。Ｓ１３５２で、リクエストで渡される表Ｅに対応する情報をもって、インストール済みアプリ管理テーブル３３５を更新し、続けて、Ｓ１３５３で応答を返却する。そして処理を終了する（Ｓ１３５４）。

以上、述べたように、配信システムにおいて、各デバイスのＦＷおよびアプリのインストール状態、起動状態を維持し、アプリの更新のために配信設定を行う際に、各デバイス毎に更新後の起動状態を指定できるようにした。これにより、複数デバイスのアプリの起動状態がそれぞれ異なっても、適切な起動状態で一括してリモート配信で更新が出来るようになった。また、更新元あるいは更新後のアプリの組合せ毎に更新後の起動状態を一括して自動設定が出来るようにしたことで、アプリ特有の事情に合わせて、容易に起動状態を一括設定することも可能となった。

＜実施例２＞
実施例１においては、図７におけるフィールド５０６（図１０のＳ１２０３）、あるいは図８におけるフィールド５２６（同図Ｓ１２１２）の入力画面で指定しアップロードする一覧ファイルは、デバイスＩＤの一覧である。実施例２においては、ここでアップロードするファイルにアプリ更新後の状態指定の情報も含めた一覧ファイルを指定する。なお、実施例２については、実施例１と基本的な構成が同じであるため、実施例１との差異についてのみ説明する。

表Ｉに、アプリ更新後の起動状態指定も含めた対象デバイス一覧ファイルの例を示す。表Ｉに示す例は、例えば、CSVファイル（カンマ区切りファイル）のような形式でファイルに保存されているものとする。

表Ｉに示す対象デバイス一覧ファイルは、デバイスＩＤ、アプリＩＤおよび状態指示の組合せの一覧を含む。デバイスＩＤは配信設定対象デバイスを示し、アプリＩＤはデバイスＩＤに対応して、更新後状態を指定するアプリを示す。図１０のＳ１２０３あるいはＳ１２１２で、表Ｉに示す例の一覧ファイルを読み込んだ場合、図１０のＳ１２１７において、表Ｉの状態指示の列の値に従って、更新後起動状態のデフォルト値が決定される。また、一括設定の「自動」指定時の状態指示も同様に決定されるものとする。

以上、述べたように、配信システムにおいて対象デバイス一覧をファイルで指定する際に更新後起動状態をデバイス毎に指定することで、ユーザインタフェースで個別に設定するよりも柔軟な運用を行うことも可能となる。

＜実施例３＞
以下、実施例３について説明する。なお、実施例３については、実施例１と基本的な構成が同じであるため、実施例１との差異についてのみ説明する。図２０に、実施例３における、デフォルト起動状態判断部３１９の処理のフローチャートの例を示す。

Ｓ１４００で、実施例１における図１０のＳ１２１７の処理を開始する。Ｓ１４０１では、図１０のＳ１２１５で絞りこまれた配信対象デバイス一覧のデバイスＩＤを、順に処理するため、一時変数Target_IDに保持する。以後、Ｓ１４０２からＳ１４１７までの処理を各デバイスＩＤに対して繰り返し処理する。

Ｓ１４０２では、このフローチャートの処理における、デフォルト起動状態を決定するための一時変数TMPに「不明」を設定する。Ｓ１４０３では、インストール済みアプリ管理テーブル３３５に記録されているデバイスのアプリ情報を順に処理するため、該テーブルの各レコード（行）を一時変数Ref_IDに保持する。以後、Ｓ１４０４からＳ１４１３までの処理を各アプリ情報に対して繰り返し処理する。

Ｓ１４０４では、Ref_IDが示すレコードが記録しているアプリＩＤが現在配信設定しようとしているアプリＩＤと一致するかどうか判断し、一致する場合はＳ１４０５へ、一致しない場合はＳ１４１３へ進む。Ｓ１４０５では、Ref_IDが示すレコードが記録しているアプリバージョンがTarget_IDのデバイスにインストールされている配信対象アプリのバージョンと一致するかどうかを判断し、一致する場合はＳ１４０６へ、一致しない場合はＳ１４１３へ進む。Ｓ１４０６では、デバイス管理テーブル３３４からデバイスＩＤに対応するデバイスモデルを検索し、Ref_IDが示すレコードが記録しているデバイスＩＤのデバイスとTarget_IDのデバイスモデルが一致するかどうかを判断する。一致する場合はＳ１４０７へ、一致しない場合はＳ１４１３へ進む。Ｓ１４０７では、デバイス管理テーブル３３４からデバイスＩＤに対応するＦＷバージョンを検索し、Ref_IDが示すレコードが記録しているデバイスＩＤのデバイスとTarget_IDのＦＷバージョンが一致するかどうかを判断する。一致する場合はＳ１４０８へ、一致しない場合はＳ１４１３へ進む。

次に、Ｓ１４０８で、Ref_IDに記録されているアプリの起動状態を判断し、その結果によって処理を分岐する。起動状態が「不明」の場合はＳ１４１３へ進み、「起動」の場合はＳ１４０９へ進み、「停止」の場合はＳ１４１１へ進む。Ｓ１４０９では、一時変数TMPが「停止」になっているかどうかを判断する。TMPが「停止」である場合、同条件デバイスの中に「起動」状態のものと「停止」状態のものが混在していることを意味している。従って、Ｓ１４１４へ進み、Target_IDに対する状態指示を「維持」に決定する。TMPが「停止」ではない場合には、Ｓ１４１０へ進み、TMPに「起動」を設定して、Ｓ１４０３へ戻る。

Ｓ１４１１では、一時変数TMPが「起動」になっているかどうかを判断する。TMPが「起動」である場合、同条件デバイスの中に「起動」状態のものと「停止」状態のものが混在していることを意味している。従って、Ｓ１４１４へ進む。TMPが「起動」ではない場合は、Ｓ１４１２へ進み、TMPに「停止」を設定して、Ｓ１４０３へ戻る。

Ｓ１４１３では、インストール済みアプリ管理テーブル３３５の全レコードを検査したかどうかを判断する。まだ検査するレコードが残っている場合は、Ｓ１４０３へ戻り、処理を繰り返す。全レコードを検査した場合は、Ｓ１４１５にて、TMPＳ１４０２で設定した初期値の「不明」のままかどうかを判断する。TMPが「不明」の場合、Target_IDと同条件のデバイスが他に無いか、同条件の全てのデバイスにおいて、同条件のアプリの起動状態が全て「不明」、すなわち、情報が無いことを意味する。従って、Ｓ１４１４へ進み、Target_IDに対する状態指示を「維持」に決定する。TMPが「不明」以外の場合（「起動」あるいは「停止」）は、同条件の全デバイスにおいて、起動状態が「不明」のデバイスを除くと、全て同じ起動状態であることを意味する。従って、Ｓ１４１６へ進み、Target_IDのデバイスにおける起動状態が「不明」であっても、他のデバイスに合わせてTMPを更新後の起動状態と決定する。

Ｓ１４１４、Ｓ１４１６からＳ１４１７に進み、全ての配信対象デバイスについて検査したかどうかを判断する。全てのデバイスについて判断した場合は、Ｓ１４１８へ進み、処理を終了する。まだ検査するデバイスが残っている場合は、Ｓ１４０１へ戻り、処理を繰り返す。

以上、述べたように、デフォルト起動状態の判断において、同条件の他のデバイスのアプリの状態から判断することにより、対象デバイスが多い場合、かつ、アプリ等から一律に状態を決定できない場合でも更新後状態を一括して決定することが可能となる。この判断は、動作状態の不明デバイスを含め決定することができるという効果がある。

＜実施例４＞
以下、実施例４について説明する。なお、実施例４については、実施例１と基本的な構成が同じであるため、実施例１との差異についてのみ説明する。図２１は、実施例４における、アプリ更新の配信設定シーケンス図である。図２１は、実施例１における図５との差異部分を図示している。実施例１と同じ処理の部分については、図５と同じ番号を付している。

図２１において、点線６０６で囲まれた範囲では、処理４６４で配信システム１０が返す応答結果に従って、デバイス４００がシーケンスを繰り返す。また、点線６００で囲まれた範囲では、処理４６２で受信したデバイス４００からの通知内容に従って、処理の有無が変わる。配信システム１０は、デバイス４００からのアプリ更新通知が失敗を示す場合、そして、デバイス４００における対象アプリの更新前の起動状態が「起動」であった場合には、処理６０１に示す配信設定を行う。これは、更新前のバージョンのアプリに戻すために、元のバージョンのアプリの配信設定を行うものである。これにより、次回の配信設定確認（処理４４５）のタイミングにおいて、正常に動作していた元のバージョンのアプリに戻すことが可能となる。

また、処理４６４の応答において、配信システム１０は、デバイス４００に対するアプリの「起動」「停止」「状態維持」の指示を含めて返す。点線６０２および６０４で囲まれた範囲では、配信システム１０からの応答の内容に従って、デバイス４００の処理の内容および有無が変化する。処理６０３は、デバイス４００がアプリの停止処理を行うことを示す。処理６０５は、デバイス４００がアプリの起動処理を行うことを示す。処理の有無及びその判断処理について、次のフローチャートで説明する。

図２２に、実施例４における、デバイス４００のアプリ更新処理のフローチャートの例を示す。図２２は、図１６との差異部分を図示している。実施例１と同じ処理の部分については、図１６と同じ番号を付している。

デバイス４００は、Ｓ１１３１およびＳ１１３２において、更新通知をした後、配信システム１０からの応答を受信する（Ｓ１５００）。そして、Ｓ１５０１にて、配信システム１０からの状態指示に従って、処理を分岐する。配信システム１０からの状態指示が、「起動」の場合は、Ｓ１１２９へ戻り、再度アプリ起動処理を行う。状態指示が「停止」の場合は、Ｓ１５０２へ進み、アプリの停止処理を行い、アプリの更新処理を終了する。状態指示が「状態維持」の場合は、そのままアプリの更新処理を終了する。

図２３に、実施例４における、配信システム１０のアプリ起動状態通知リクエストの処理のフローチャートの例を示す。図２３は実施例１における図１８に替わるものである。実施例１と同じ処理の部分については、図１８と同じ番号を付している。

Ｓ１３４１で受信した通知の内容に従って、Ｓ１５２０で更新が成功したかどうかを判断する。更新が成功している場合はＳ１３４２へ進み、アプリの状態情報を更新し、続いてＳ１５２７で、「状態維持」の指示を含めて応答する。更新が失敗した場合はＳ１５２１へ進む。Ｓ１５２１では、インストール済みアプリ管理テーブル３３５を検索し、対象デバイスにおける対象アプリの更新前の起動状態によって処理を分岐する。更新前の状態が「停止」であった場合はＳ１５２２へ進み、「起動」であった場合はＳ１５２４へ進む。

Ｓ１５２２では、停止状態でインストール済みアプリ管理テーブル３３５を更新する。そして、Ｓ１５２３で、デバイス４００に対して、対象アプリの「停止」指示を含めて応答する。Ｓ１５２４では、インストール済みアプリ管理テーブル３３５を検索し、対象デバイスにおける対象アプリの更新前のアプリのバージョンを取得する。そして、アプリ配信管理テーブル３３６を更新し、更新前のバージョンのアプリの配信予約を入れる。さらに、Ｓ１５２５で、停止状態でインストール済みアプリ管理テーブル３３５を更新する。そして、Ｓ１５２６で、デバイス４００に対して、対象アプリの「起動」指示を含めて応答する。Ｓ１５２５にて、「停止」状態で更新するのは、デバイス４００においてアプリの再起動で失敗した場合にそれ以上起動指示を出さないようにするためである。

以上、述べたように、デバイスにおけるアプリ更新後の起動失敗に際しても、配信システムからの指示を送信することによって、配信システムの判断で適切な動作状態及び、正常なバージョンへの復帰が可能となる。

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

１０ 配信システム
４００ デバイス
３１０ Ｗｅｂインタフェース部
３１１ ユーザインタフェース部

Claims (10)

1. ネットワークデバイスにインストールされているファームウェアおよびアプリケーションのそれぞれの識別情報およびバージョン情報を取得する取得手段と、
   前記取得手段により取得された情報に基づいて、前記ファームウェアに関する配信設定のための第１の画面と、前記アプリケーションに関する配信設定のための第２の画面とを切り替えて表示する表示手段と、
   前記表示された第１の画面を介して指定された前記ファームウェアに関する配信設定、または前記表示された第２の画面を介して指定された前記アプリケーションに関する配信設定を前記ネットワークデバイスに送信する送信手段を有し、
   前記送信される前記アプリケーションに関する配信設定には、該アプリケーションの配信後の稼働状態の指定が含まれることを特徴とする配信システム。
2. 前記アプリケーションに関する配信には該アプリケーションのインストールおよび更新が含まれ、前記ファームウェアに関する配信には該ファームウェアの更新が含まれることを特徴とする、請求項１に記載の配信システム。
3. 前記第１の画面を介して、前記ネットワークデバイスと、配信すべきファームウェアの識別情報とを含む配信設定の指定を行う第１の指定手段と、前記第２の画面を介して、前記ネットワークデバイスと、配信すべきアプリケーションの識別情報と、該アプリケーションの配信後の稼働状態とを含む配信設定の指定を行う第２の指定手段とをさらに有することを特徴とする、請求項１または２に記載の配信システム。
4. 前記第２の画面を介して指定できる稼働状態には、アプリケーションの起動、停止、または更新前の状態の維持が含まれることを特徴とする、請求項１〜３のいずれか１項に記載の配信システム。
5. 前記取得手段は、前記ネットワークデバイスにインストールされているアプリケーションの稼働状態をさらに取得し、前記第２の画面では、当該アプリケーションの識別情報、バージョン情報、及び稼働状態が表示されることを特徴とする、請求項１〜４のいずれか１項に記載の配信システム。
6. 同じ条件の他のネットワークデバイスの稼働状態に従って、アプリケーションの配信後の稼働状態を決定することを特徴とする、請求項１〜５のいずれか１項に記載の配信システム。
7. 前記ネットワークデバイスの更新前のアプリケーションの配信設定を行うことを特徴とする、請求項１〜６のいずれか１項に記載の配信システム。
8. 前記送信される前記ファームウェアに関する配信設定または前記アプリケーションに関する配信設定には、配信日時の指定が含まれることを特徴とする、請求項１〜７のいずれか１項に記載の配信システム。
9. ネットワークデバイスにインストールされているファームウェアおよびアプリケーションのそれぞれの識別情報およびバージョン情報を取得するステップと、
   前記取得された情報に基づいて、前記ファームウェアに関する配信設定のための第１の画面と、前記アプリケーションに関する配信設定のための第２の画面とを切り替えて表示するステップと、
   前記表示された第１の画面を介して指定された前記ファームウェアに関する配信設定、または前記表示された第２の画面を介して指定された前記アプリケーションに関する配信設定を前記ネットワークデバイスに送信するステップを有し、
   前記送信される前記アプリケーションに関する配信設定には、該アプリケーションの配信後の稼働状態の指定が含まれることを特徴とする、配信システムにおける配信方法。
10. 請求項１〜８のいずれか１項に記載の配信システムをコンピュータで実現させるためのプログラム。

Images