JP2013230558A - 画像形成装置、システム、画像形成装置の制御方法、及びプログラム - Google Patents

Abstract

【課題】デバイスから配信したインストーラによりクライアント装置でエラーが発生したことをデバイス側で把握し、同一のインストーラを配信した他のクライアント装置で同じエラーが発生することを抑え、管理者の負荷を軽減すること。
【解決手段】識別情報が埋め込まれたデバイスドライバのインストーラを保持するデバイス１０２の管理エージェント５００１が、クライアント装置１０４からの要求に応じて、前記インストーラをクライアント装置１０４に配信する。また、管理エージェント５００１は、前記クライアント装置１０４から、前記識別情報を含む、前記インストーラの実行でエラーが発生したことを示すエラー情報を受信する。そして、管理エージェント５００１は、受信したエラー情報に含まれる識別情報に対応するインストーラと同一のインストーラを配信したユーザの宛先に、同一のインストーラの実行でエラーが発生したことを示す警告を送信する。
【選択図】図３

Description

本発明は、画像形成装置、システム、画像形成装置の制御方法、及びプログラムに関する。

従来、管理装置と、１又は複数のデバイスと、それらデバイス内で動作しているエージェントと、１又は複数のクライアント装置と、それらを繋ぐネットワークからなるネットワークデバイス管理システムが存在している。そのようなシステムのなかには、管理装置からデバイス内に置かれたエージェントに対してデバイスドライバをインストールするインストーラソフトウェアの実行ファイルを送信し、当該デバイスに格納する機能を備えたものが存在する。

さらに、そのようなシステムにおいて、デバイス内のエージェントが、デバイス内に格納された実行ファイルの予め定められたデータ領域に対してそのデバイスの属性値を上書き保存する機能を備えるようなものが存在する。さらに、そのようなシステムにおいて、デバイス内のエージェントは、ユーザの使用するクライアント装置からの指示により、その実行ファイルをエージェントからそのクライアント装置へダウンロードする機能を備えている。

その実行ファイルは、ユーザがクライアント装置にダウンロードされ、実行が指示された場合に、デバイスドライバのインストーラを起動する。そのインストーラは、実行ファイルのデータ領域に上書き保存されたデバイスの属性値を参照する機能を備えている。実行中、そのインストーラは、その参照した属性値を使用してデバイスドライバのインストール処理を行う。すなわち、そのインストーラは、デバイスの属性値を、ユーザの手動による入力を経ずして認識する機能を備えている。その機能により、そのインストーラが、ドライバのインストールを、ユーザの手動入力を求めることなく実行完了することが可能となるような管理システムが存在する。このようなシステムにより、ユーザは、そのクライアント装置に対して、そのデバイスを使用可能な状態とするドライバのインストールを容易に実行することができる。

また、従来のネットワーク管理システムの中には、そのようなエージェントが実行ファイルのデータ領域に属性値を保存せず、クライアント装置へダウンロードする際のファイル名にデバイスの属性値および管理者のメールアドレスを付加するものが存在する。

そして、そのようなシステムの中には、そのような実行ファイルの実行時に、特定のエラーが発生した場合には、その付加された管理者のメールアドレスに対して、エラー通知を実行する機能を備えたものが存在する（特許文献１参照）。このシステムにより、クライアント装置が実行ファイルからソフトウェアを実行して特定のエラーになった場合には、管理者が通知メールを受け取り、問題が発生したことを知ることができるようになる。

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

上記特許文献１の管理システムでは、そのインストーラによるインストールの実行時に発生したエラーを、管理者へメールにより伝達することができる。そして、管理者は、このようなメールによる通知を受け取ったあと、エラーの発生状況をあらためて調査し、原因を突き止めていた。また、原因がインストーラ自身にあることが判明した場合、管理者が手動で、そのインストーラのダウンロードを停止していた。

なお、このような管理方法では、管理者に相応の管理負荷が発生するとともに、管理者が長期不在等の場合には、迅速に対応することができず、エラー発生したインストーラと同じインストーラが他のユーザのクライアント装置にダウンロードされて再びエラーを発生してしまう可能性があった。

本発明は、上記の問題点を解決するためになされたものである。本発明の目的は、画像形成装置から配信したインストーラの実行により情報処理装置でエラーが発生したことを画像形成装置側で把握可能となり、同一のインストーラを配信した他の情報処理装置で同じエラーが発生することを抑え、管理者の管理にかかる手間を大幅に軽減することができる仕組みを提供することである。

本発明は、画像形成装置であって、識別情報が埋め込まれたデバイスドライバのインストーラを保持する保持手段と、情報処理装置からの要求に応じて、前記保持手段に保持しているインストーラを、前記情報処理装置に配信する配信手段と、前記配信手段で前記インストーラを配信した前記情報処理装置から、前記インストーラに埋め込まれた識別情報を含む、前記インストーラの実行でエラーが発生したことを示すエラー情報を、受信する受信手段と、を有することを特徴とする。

本発明によれば、画像形成装置から配信したインストーラの実行により情報処理装置でエラーが発生したことを画像形成装置側で把握可能となり、同一のインストーラを配信した他の情報処理装置で同じエラーが発生することを抑えることができ、管理者の管理にかかる手間を大幅に軽減することができる。

本発明の実施例１の画像形成システムの一例を示すシステム構成図である。 デバイス及び情報処理装置のハードウェア構成の一部を模式化したブロック図である。 デバイス管理ソフトウェア４００１及び管理エージェント５００１の内部構成の一例を示すブロック図である。 実施例１におけるインストーラ６０００の処理の一例を示すフローチャートである。 実施例１における管理エージェント５００１のエラー管理モジュール５１０２により実行される処理の一例を示すフローチャートである。 実施例１においてファイル管理モジュール４１０１が生成するインストーラファイルの構成の一例を示す図である。 本発明のエラー通知データの構成の一例を示す図である。 本発明の管理装置１０３で動作しているデバイス管理ソフトウェア４００１のエラー管理モジュール４１０２の動作の一例を示すフローチャートである。 図８のＳ１０２０１で生成される実施例１のエラー通知メールの一例を示す図である。 実施例１の全体の処理の流れを模式的に示す図である。 実施例２における管理エージェント５００１のエラー管理モジュール５１０２の内部処理の一例を示すフローチャートである。 実施例３のデバイス管理ソフトウェア４００１の条件管理モジュール４１０３のユーザインタフェースとしての追加判定条件設定画面の一例を示す図である。 実施例３における管理エージェント５００１のエラー管理モジュール５１０２の内部処理の一例を示すフローチャートである。 実施例４のファイル管理モジュール５１０１の処理の一例を示すフローチャートである。 実施例４のクライアント装置１０４のＯＳ上で実行されるインストーラ６０００の処理の一例を示すフローチャートである。 図８のＳ１０２０１で生成される実施例４のエラー通知メールの一例を示す図である。 実施例４の全体の処理の流れを模式的に示す図である。 実施例５のファイル管理モジュール５１０１がデバイス１０２の操作パネル２０４に表示するメールアドレス入力画面の一例を示す図である。 ファイルをダウンロードするための手段を通知する電子メールの一例を示す図である。 実施例５のファイル管理モジュール５１０１の処理の一例を示すフローチャートである。 実施例５における管理エージェント５００１のエラー管理モジュール５１０２により実行される処理の一例を示すフローチャートである。 図２１のＳ２８３０２で生成される電子メールの一例を示す図である。 実施例５の全体の処理の流れを模式的に示す図である。 実施例６における管理エージェント５００１のエラー管理モジュール５１０２により実行される処理の一例を示すフローチャートである。 図２４のＳ３１４０４で生成される通知メールの一例を示す図である。 実施例６の全体の処理の流れを模式的に示す図である。 実施例７におけるデバイス管理ソフトウェア４００１のファイル管理モジュール４１０１により実行される処理の一例を示すフローチャートである。 実施例７においてファイル管理モジュール４１０１が生成するインストーラファイルの構成の一例を示す図である。 実施例７におけるインストーラ６０００の処理の一例を示すフローチャートである。 実施例７のファイル管理モジュール５１０１の処理の一例を示すフローチャートである。 実施例７における管理エージェント５００１のエラー管理モジュール５１０２により実行される処理の一例を示すフローチャートである。 実施例７の全体の処理の流れを模式的に示す図である。

以下、本発明を実施するための形態について図面を用いて説明する。

図１は、本発明の実施例１の画像形成システムの一例を示すシステム構成図である。
図１において、１０１はネットワークである。画像形成装置１０２（１０２ａ、１０２ｂ、１０２ｃ）は、ネットワーク１０１に接続されたデバイス（例えば、印刷装置、複合機、スキャナ等）である。以下、画像形成装置１０２をデバイス１０２という。

管理装置１０３は、ネットワーク１０１に接続され、管理者がデバイス１０２を管理するために使用する情報処理装置である。クライアント装置１０４は、ネットワーク１０１に接続され、一般ユーザがデバイス１０２を利用するために使用する情報処理装置である。管理装置１０３及びクライアント装置１０４はそれぞれ、ネットワーク１０１を介してデバイス１０２と通信可能である。

管理装置１０３で管理するデバイスは、プリンタ、スキャナ、ＦＡＸ機能やコピー機能を併せ持つ複合機等の画像形成装置を含み、クライアント装置１０４にインストールされたデバイスドライバを用いて利用可能な装置を含むものとする。

図２（ａ）は、デバイス１０２のハードウェア構成の一部を模式化したブロック図である。
図２（ａ）において、２０１はデバイス１０２の制御部である。制御部２０１は、コントローラ２０２、ストレージ２０３、操作パネル２０４、ネットワークインタフェース２０５、エンジンインタフェース２０６等を有する。

制御部２０１は、ネットワークインタフェース２０５を通して、ネットワーク１０１に接続している。エンジンインタフェース２０６には、デバイス１０２の画像形成エンジン（不図示）が接続されている。

コントローラ２０２は、コントローラ２０２内の不図示のＲＯＭやストレージ２０３にコンピュータ読み取り可能に記録されたプログラムを読み出して実行することにより、デバイス１０２全体を制御する。

図２（ｂ）は、管理装置１０３およびクライアント装置１０４であるところの情報処理装置のハードウェア構成を模式化したブロック図である。
図２（ｂ）に示すように、３０１は情報処理装置（管理装置１０３、クライアント装置１０４）の本体である。情報処理装置本体３０１は、中央処理装置（以下ＣＰＵ）３０２、ＣＰＵに接続されたバス３０３、ＲＡＭ３０４、ＲＯＭ３０５、ネットワークインタフェース３０６、ＨＩＤインタフェース３０７、ストレージ３０８を有する。

ＲＡＭ３０４は、読み書き可能なメモリであり、ＣＰＵ３０２のワーク領域として使用される。ＲＯＭ３０５は、読み出し専用のメモリである。情報処理装置本体３０１は、ネットワークインタフェース３０６を通してネットワーク１０１に接続している。ストレージ３０８は、ハードディスク、フラッシュメモリ等の不揮発性の記憶装置である。

ＨＩＤインタフェース３０７は、対人インタフェースデバイスインタフェースである。ＨＩＤインタフェース３０７は、例えばキーボードやマウスなどの入力デバイス３０９、例えばディスプレイやスピーカーなどの出力デバイス３１０を接続する。

ＣＰＵ３０２は、ＲＯＭ３０５やストレージ３０８にコンピュータ読み取り可能に記録されたプログラムを読み出して実行することにより、情報処理装置全体を制御する。

以下、図３（ａ）を参照して、本発明の管理装置１０３内で動作するデバイス管理ソフトウェアの内部構成について説明する。
図３（ａ）は、本発明の管理装置１０３内で動作するデバイス管理ソフトウェア４００１の内部構成の一例を示すブロック図である。
デバイス管理ソフトウェア４００１は、管理装置１０３のストレージ３０８内に格納されており、管理装置１０３のオペレーティングシステム（ＯＳ）によってＲＡＭ３０４上に読み込まれて実行される。なお、ＯＳやデバイス管理ソフトウェア４００１の実行は、管理装置１０３のＣＰＵ３０２によって行われる。

デバイス管理ソフトウェア４００１は、ファイル管理モジュール４１０１、エラー管理モジュール４１０２、条件管理モジュール４１０３、デバイス管理モジュール４１０４を有する。即ち、これらのモジュール４１０１〜４１０４は、ストレージ３０８にコンピュータ読み取り可能に記録されたプログラムを、ＣＰＵ３０２が実行することにより実現されるものである。

ファイル管理モジュール４１０１は、例えばストレージ３０８に格納されている結合対象のファイル群を取得し、該ファイル群を結合してインストーラソフトウェア実行ファイル（以下、インストーラファイル）を生成する。

なお、結合対象となる第１のファイルは、デバイス１０２のデバイスドライバを情報処理装置にインストールするためのインストールパッケージファイルセットである。また、結合対象となる第２のファイルは、インストーラの実行部分を保持するデータファイルである。また、結合対象となる第３のファイルは、インストーラファイル内にインストール用のデバイス属性値を格納するためのインストール用デバイス属性値格納用データ領域部分を保持するデータファイルである。なお、デバイス１０２のデバイスドライバとは、デバイス１０２の機能を利用するためのデバイスドライバであればどのような種類のデバイスドライバであってもよい。一例を示すと、プリンタドライバ、スキャナドライバ、ファックスドライバ等が、上記デバイスドライバに該当する。

ここで、図６を用いて、ファイル管理モジュール４１０１が生成するインストーラファイルの構成について説明する。
図６は、実施例１においてファイル管理モジュール４１０１が生成するインストーラファイルの構成の一例を示す図である。
図６において、８００１は、インストーラファイルの実行部分であり、上述した第２のファイルに対応する部分である。８００２は、デバイスドライバのインストールパッケージファイルセットを圧縮したデータ（以下、ファイルセット圧縮データ）であり、上述した第１のファイルに対応する部分である。８００３は、インストール用デバイス属性値格納用データ領域（以下、属性値格納用データ領域）であり、上述した第３のファイルに対応する部分である。

８００４は、属性値格納用データ領域８００３の先頭のファイルの末尾からのオフセット値を記録したオフセット値Ａの格納領域である。８００５は、ファイルセット圧縮データ８００２の先頭位置のファイルの末尾からのオフセット値を記録したオフセット値Ｂの格納領域である。８１０１はインストーラファイルの先頭を示し、８１０２はインストーラファイルの末尾を示す。

このインストーラファイルは、クライアント装置１０４のＯＳによって読み込まれた時に、実行部分８００１がクライアント装置１０４のＲＡＭ３０４上へ展開される。そして、当該クライアント装置１０４のＣＰＵ３０２によって規定のエントリポイントに制御を移すことで、インストーラが実行される仕組みとなっている。

以下、図３（ａ）の説明に戻る。
エラー管理モジュール４１０２は、デバイス１０２の管理エージェント５００１（図３（ｂ））からのエラー通知をネットワーク経由で受信し、管理者へ通知するためのものである。
なお、条件管理モジュール４１０３については、後述する実施例３で説明する。また、デバイス管理モジュール４１０４については、後述する実施例７で説明する。

図３（ｂ）は、本発明の実施例１のデバイス１０２内で動作する管理エージェント５００１の内部構成の一例を示すブロック図である。
管理エージェント５００１は、デバイス１０２のコントローラ２０２上で動作するプログラムとして実行される。管理エージェント５００１は、コントローラ２０２内の不図示のＲＯＭやストレージ２０３に格納されており、コントローラ２０２により実行される。

管理エージェント５００１は、ファイル管理モジュール５１０１、エラー管理モジュール５１０２、ダウンロード制御モジュール５１０３、トランザクションＩＤ管理モジュール５１０４を有する。即ち、これらのモジュール５１０１〜５１０４は、コントローラ２０２内の不図示のＲＯＭやストレージ２０３にコンピュータ読み取り可能に記録されたプログラムを、コントローラ２０２が実行することにより実現されるものである。

ファイル管理モジュール５１０１は、管理装置１０３のファイル管理モジュール４１０１（図３（ａ））からインストーラファイルを受け取り、当該インストーラファイルをストレージ２０３へ格納する。また、ファイル管理モジュール５１０１は、ストレージ２０３へ格納したインストーラファイルの属性値格納用データ領域８００３に、デバイスの属性値を書き込む。また、ファイル管理モジュール５１０１は、クライアント装置１０４からの要求に応答して、インストーラファイルをクライアント装置１０４へダウンロードする。

エラー管理モジュール５１０２は、クライアント装置１０４にダウンロードされて実行されたインストーラから送信されるエラー情報を受信し、エラーの原因を判定する。また、エラー管理モジュール５１０２は、上記受信したエラー情報および解析した判定結果を、エラー通知として、管理装置１０３上のエラー管理モジュール４１０２へ送信する。なお、上記クライアントから受信するエラー情報には、インストーラを特定するための識別情報が含まれているものとする。そして、エラー管理モジュールは、管理装置１０３上のエラー管理モジュール４１０２へ送信するエラー通知に、上記インストーラを特定するための識別情報を含めるものとする。

ダウンロード制御モジュール５１０３は、エラー管理モジュール５１０２がエラーの原因がインストーラにあると判定した場合、ファイル管理モジュール５１０１にダウンロード停止を指示する。
なお、トランザクションＩＤ管理モジュール５１０４については、後述する実施例７で説明する。

次に、本発明の実施例１におけるインストーラの動作について説明する。
インストーラファイルは、クライアント装置１０４から、管理エージェント５００１のファイル管理モジュール５１０１に対して送信されるダウンロード要求に応じて、デバイス１０２からクライアント装置１０４へダウンロードされる。ダウンロードされたインストーラファイルは、例えばクライアント装置１０４のストレージ３０８に格納される。このダウンロードは、クライアント装置１０４のＯＳに組み込まれている機能により実行することが可能である。

例えば、ファイル管理モジュール５１０１がＨＴＭＬにより表現されるＷｅｂブラウザ画面を通じたダウンロード手段を提供しているケースについて考えてみる。このケースでは、クライアント装置１０４のＯＳ上に配置されたＷｅｂブラウザからダウンロード要求を行い、Ｗｅｂブラウザの機能に基づいて上記のダウンロードを行うことが可能である。近年では、ＯＳにＷｅｂブラウザ機能が最初から統合されているものも多い。また、他の例として、ファイル管理モジュール５１０１がネットワーク共有フォルダ機能を通じてファイルをアクセス可能な状態に置いているケースについて考えてみる。このケースでは、クライアント装置１０４のＯＳ上に配置された当該共有フォルダ機能のクライアントソフトウェアの機能に基づいてファイルを取得することで、上記のダウンロードが実現される。近年のＯＳは、共有フォルダへのアクセスを行うクライアント機能が最初から統合されているものも多い。

クライアント装置１０４にダウンロードされたインストーラファイルは、当該クライアント装置１０４のＯＳで実行可能なファイル形式をしている。このため、当該クライアント装置１０４が一般ユーザからインストーラファイルの実行指示をうけた場合には、ＯＳは、当該インストーラファイルをＲＡＭ３０４上に読み込み実行することができる。これにより、クライアント装置１０４上にインストーラ６０００（図４）が実現される。すなわち、インストーラ６０００は、デバイス１０２からダウンロードされ、クライアント装置１０４のストレージ３０８にコンピュータ読み取り可能に記録されたインストーラファイルを、クライアント装置１０４のＣＰＵ３０２が読み出して実行することにより実現されるものである。

以下、図４を用いて、インストーラ６０００により行われる処理について説明する。
図４は、実施例１におけるインストーラ６０００の処理の一例を示すフローチャートである。なお、図４中のＳ６１０１〜Ｓ６２０２は、インストーラ６０００が実行する各ステップを示す。

まず、インストーラ６０００は、Ｓ６１０１において、属性値を取得する。ここでは、インストーラ６０００は、インストーラファイル内のオフセット値Ａ格納領域８００４からオフセット値Ａを読み出し、そのオフセット値Ａを使用して、属性値格納用データ領域８００３を参照して、デバイス属性値を読み出す。

次に、Ｓ６１０２において、インストーラ６０００は、ファイルセット展開処理を行う。ここでは、インストーラ６０００は、インストーラファイル内のオフセット値Ｂ格納領域８００５からオフセット値Ｂを読み出し、そのオフセット値Ｂを使用して、ファイルセット圧縮データ８００２を参照する。さらに、インストーラ６０００は、ファイルセット圧縮データ８００２を伸長して、元のファイルセットを復元し、クライアント装置１０４のストレージ３０８へ展開する。そして、インストーラ６０００は、このファイルセット展開でエラーが発生したかどうかを判定する。

上記Ｓ６１０２において、ファイルセット展開でエラーが発生したと判定した場合（展開エラーの場合）、インストーラ６０００は、Ｓ６２０１へ処理を進める。展開エラーは、例えば、ファイルセット圧縮データ８００２の内容が不正で伸長処理を行うことができない場合や、ファイルセット圧縮データ８００２が伸長する大きさの上限を超えている場合に発生する。また、このインストーラ６０００の保持している実行権限において、ストレージ３０８に対してファイルを書き込むことが不可能である場合にも展開エラーが発生する。

一方、上記Ｓ６１０２において、ファイルセット展開でエラーが発生していないと判定した場合（展開成功の場合）、インストーラ６０００は、Ｓ６１０３へ処理を進める。

Ｓ６１０３では、インストーラ６０００は、ストレージ３０８に展開されたインストールパッケージのファイルセットに含まれているインストールを実行するためのコマンドを呼び出す（コマンド起動）。なお、インストーラ６０００は、このコマンド起動において、上記Ｓ６１０１で取得したインストール用のデバイス属性値を当該コマンドに対してパラメータとして渡す。これにより、当該コマンドは、クライアント装置１０４上において一般ユーザからのデバイス属性値の手動入力を必要とせずとも、デバイスドライバを当該デバイス１０２に対して接続可能となるようにインストール処理することが可能となる。コマンド起動後、インストーラ６０００は、上記コマンド起動でエラーが発生したかどうかを判定する。

上記Ｓ６１０３において、コマンド起動でエラーが発生しなかったと判定した場合（起動成功の場合）、インストーラ６０００は、デバイスドライバの当該クライアント装置１０４のＯＳへのインストールを完了し、本フローチャートの処理を終了する。

一方、上記Ｓ６１０３において、コマンド起動でエラーが発生したと判定した場合（起動エラーの場合）、インストーラ６０００は、Ｓ６２０１に処理を進める。起動エラーは、例えば、コマンドを起動しようとしたがそのためのコマンド実行ファイルが見当たらない場合や、それ以外のコマンドを実行するために必須であるようなファイルが上記Ｓ６１０２にて展開したファイルセットの中に見当たらない場合に起こる。また、当該コマンドを起動しようとしたが、このインストーラ６０００の保持している実行権限において、当該コマンドを最後まで実行する権限がなかった場合にも起動エラーが発生する。あるいは、当該ＯＳが、当該コマンドがインストールしようとしているデバイスドライバと互換性がないことが判明した場合にも起動エラーが発生することがある。例えば、当該ＯＳが３２ビットエディションであるのに対して当該コマンドがインストールしようとしているデバイスドライバが６４ビットエディション用である場合などである。また、起動エラーは、当該コマンド実行ファイルが不正なフォーマットになっており、当該ＯＳがそれを実行することができないといった場合にも発生する。

あるいは、次のような場合にも起動エラーが発生する。管理エージェント５００１は全ての既存の妥当なデバイスドライバのインストールパッケージのファイルセットについてファイルサイズやタイムスタンプ、チェックサムなどのデータを蓄積しておくことができる。当該展開されたファイルセットのそれらデータを取得あるいは算出し、その蓄積されたデータの中に一致するものがなかった場合にも、当該ファイルセットは不正なものであるためインストールを中止するということができる。この場合も、インストーラソフトウェア実行ファイルが不正であったため、起動エラーが発生したこととして扱うことが可能である。

なお、上記Ｓ６１０２やＳ６１０３いずれでエラーが発生した場合も、エラーに関する情報が当該クライアント装置１０４上に残されている。また、インストーラ６０００自身も内部的に起こったエラーについての情報（エラーコード等）を保持している。クライアント装置１０４上に残されているエラーに関する情報としては、ＯＳのシステムログや、コマンドが独自で用意しているログファイル、あるいは画面上に表示されるメッセージやシステムコンソールメッセージ、エラーコード、エラー発生時のメモリダンプ等などが考えられる。なお、これらのエラー情報には、エラー発生日時等も含まれる。

Ｓ６２０１では、インストーラ６０００は、上記のようなエラー情報を収集し、一元化する。また、インストーラ６０００は、当該インストーラを特定する識別情報（以下、インストーラＩＤ）を取得する。なお、インストーラＩＤは、予めインストーラファイルに組み込まれたものであってもよいし、インストーラファイルのタイムスタンプ、チェックサムや、これらの組み合わせをインストーラＩＤとして用いてもよい。さらに、インストーラ６０００は、クライアント装置１０４を特定するための識別情報（クライアントＩＤ）、例えば、クライアント装置１０４のネットワークアドレスやホスト名、ＭＡＣアドレスなどを取得する。また、インストーラ６０００は、クライアント装置１０４のＯＳを特定するための識別情報（クライアントＯＳ情報）、例えばオペレーティングシステムの名称、バージョン、エディションの種別などの情報を取得する。また、インストーラ６０００は、インストーラ６０００を実行している実行権限を特定するための情報、例えば、どのユーザの実行権限で実行していたのか、あるいはその実行権限はどのユーザグループに属しているのか、またはどのようなアクセスコントロールトークンによって実行権限が規定されていたのか、などの情報を取得する。そして、以上のように収集した情報も上記エラー情報として一元化する。

次に、Ｓ６２０２において、インストーラ６０００は、上記Ｓ６２０１にて収集され一元化されたエラー情報等を、管理エージェント５００１のエラー管理モジュール５１０２へ送信する。この際に、インストーラ６０００は、以下の方法により管理エージェント５００１のネットワークアドレスを取得する。インストーラ６０００は、当該管理エージェント５００１がインストールさせようとしていたデバイス１０２のコントローラ上で当該管理エージェント５００１が動作していることを利用する。すなわち、当該管理エージェント５００１のネットワークアドレスは、上記Ｓ６１０１にて取得したデバイス属性値に含まれているデバイスのネットワークアドレスと一致している。このため、インストーラ６０００は、当該ネットワークアドレスを利用して、当該管理エージェント５００１に対して送信を行うことが可能となる。このようにしてインストーラ６０００は、エラーが発生した場合には、エラー情報を管理エージェント５００１へ送信することができる。なお、当該Ｓ６２０２のエラー情報送信処理を完了すると、インストーラ６０００は、本フローチャートの処理を終了する。

以下、図５を参照して、実施例１における管理エージェント５００１のエラー管理モジュール５１０２により行われる処理について説明する。
図５は、実施例１における管理エージェント５００１のエラー管理モジュール５１０２により実行される処理の一例を示すフローチャートである。なお、図中のＳ７１０１〜Ｓ７２０３は、エラー管理モジュール５１０２が実行する各ステップを示す。

まず、エラー管理モジュール５１０２は、Ｓ７１０１において、図４のＳ６２０２でインストーラ６０００から送信されたエラー情報を受信すると、Ｓ７１０２に処理を進める。なお、エラー管理モジュール５１０２は、エラー情報の受信日時を記憶しておく。また、受信したエラー情報には、上述したように、クライアント装置１０４上で収集されたエラーに関する情報、インストーラＩＤ、エラー発生日時、クライアントＩＤ、クライアントＯＳ情報、実行権限情報等が含まれている。

Ｓ７１０２では、エラー管理モジュール５１０２は、上記Ｓ７１０１で受信したエラー情報を解析する。
次に、Ｓ７１０３において、エラー管理モジュール５１０２は、上記Ｓ７１０２での解析結果と、エラーが発生したクライアント装置に関する情報を含むエラー通知データを生成する。このエラー通知データは、その他の管理者がエラーの発生に対応するために必要なデータを含むよう構成される。

ここで、図７を用いて、エラー通知データについて説明する。
図７は、本発明のエラー通知データの構成の一例を示す図である。
図７に示すように、エラー通知データは、通知生成日時９００１、通知元エージェントＩＤ９００２、ユーザ情報２２１０１、インストーラＩＤ９００３、エラー情報受信日時９１０１、エラー発生日時９１０２、エラー解析結果サマリ９１０３、エラー解析結果詳細データ９１０４、クライアントＩＤ９２０１、クライアントＯＳ情報９２０２、実行権限情報９２０３等を有する。

通知生成日時９００１は、このエラー通知データの生成日時である。通知元エージェントＩＤ９００２は、このエラー通知データを生成した管理エージェント５００１を特定するための識別情報である。通知元エージェントＩＤ９００２には、例えば、デバイス１０２のネットワークアドレスやホスト名、ＭＡＣアドレスやシリアルナンバーなどが用いられる。

インストーラＩＤ９００３は、実際にエラーを発生したインストーラファイルを特定するための識別情報であり、上記受信したエラー情報に含まれる。エラー情報受信日時９１０１は、エラー情報をエラー管理モジュール５１０２が受信した日時である。エラー発生日時９１０２は、クライアント装置１０４上でインストーラ６０００がエラーの発生を検知した日時であり、上記受信したエラー情報に含まれる。

エラー解析結果サマリ９１０３は、エラー管理モジュール５１０２が解析した結果のサマリである。エラー解析結果詳細データ９１０４は、エラー管理モジュール５１０２が解析した結果の詳細データである。

クライアントＩＤ９２０１は、クライアント装置１０４を特定するための識別情報であり、上記受信したエラー情報に含まれる。クライアントＩＤ９２０１には、例えば、クライアント装置１０４のネットワークアドレスやホスト名、ＭＡＣアドレスなどが用いられる。

クライアントＯＳ情報９２０２は、クライアント装置１０４のＯＳを特定するための識別情報であり、上記受信したエラー情報に含まれる。クライアントＯＳ情報９２０２には、例えばオペレーティングシステムの名称、バージョン、エディションの種別などが含まれる。

実行権限情報９２０３は、インストーラ６０００を実行していた実行権限を特定するための情報であり、上記受信したエラー情報に含まれる。実行権限情報９２０３には、例えば、どのユーザの実行権限で実行していたのか、あるいはその実行権限はどのユーザグループに属しているのか、またはどのようなアクセスコントロールトークンによって実行権限が規定されていたのか、などの情報が含まれることが想定される。

なお、ユーザ情報２２１０１については、後述する実施例４で説明する。
以下、図５のフローチャートの説明に戻る。
上記Ｓ７１０３のエラー通知生成処理を完了すると、エラー管理モジュール５１０２は、Ｓ７１０４に処理を進める。
次に、Ｓ７１０４では、エラー管理モジュール５１０２は、上記Ｓ７１０３にて生成したエラー通知データを、デバイス管理ソフトウェア４００１のエラー管理モジュール４１０２に対して送信する。

次に、Ｓ７２０１において、エラー管理モジュール５１０２は、上記Ｓ７１０３にて取得した解析結果により、エラーの原因がインストーラ６０００にあったのか、クライアント装置１０４又はそのＯＳにあったのかを判定する。また、エラー管理モジュール５１０２は、上記受信したエラー情報および解析した判定結果を、エラー通知として、管理装置１０３上のエラー管理モジュール４１０２へ送信する。

次に、Ｓ７２０２において、エラー管理モジュール５１０２は、上記Ｓ７２０１での判定結果に基づいて、ダウンロードを停止するかどうかを判断する。
上記Ｓ７２０２において、エラー管理モジュール５１０２は、上記Ｓ７２０１でエラーの原因がクライアント装置１０４又はそのＯＳにあったと判定した場合、ダウンロードを停止しない（停止不要）という判断を行い、そのまま本フローチャートの処理を終了する。

一方、上記Ｓ７２０２において、エラー管理モジュール５１０２は、上記Ｓ７２０１でエラーの原因がインストーラ６０００にあったと判定した場合、ダウンロードを停止する（停止必要）という判断を行い、Ｓ２３０３に処理を進める。

Ｓ７２０３では、エラー管理モジュール５１０２は、ダウンロード制御モジュール５１０３に対して、インストーラＩＤ９００３に対応するインストーラファイルのダウンロードを停止するよう指示を行う。該指示を受けた、ダウンロード制御モジュール５１０３は、ファイル管理モジュール５１０１に対して、上記インストーラＩＤ９００３に対応するインストーラファイルのダウンロード要求の受け付けを停止するよう指示をおこなう。指示を受けたファイル管理モジュール５１０１は、クライアント装置１０４からの、前記インストーラＩＤ９００３に対応するインストーラのダウンロード要求の受け付けを停止し、ダウンロードを実行しないよう動作を変更する。

ファイル管理モジュール５１０１は、別途、管理者によりダウンロード再開が指示された場合にのみ、上記ダウンロードの要求の受け付けを停止しているインストーラファイルのダウンロードの要求を受け付ける。そして、その場合には、ダウンロードの要求を受け付けたらファイル管理モジュール５１０１がダウンロードを実行するよう動作を変更する。

また、ファイル管理モジュール５１０１は、以下の条件のときに、上記ダウンロードの要求の受け付けを停止しているインストーラファイルのダウンロードの要求を受け付け、ダウンロードを実行するよう動作を変更する。その条件とは、すなわちインストーラファイルがファイル管理モジュール５１０１にて受信されて新たなファイルに差し替えられた場合である。

以下、図８を用いて、管理装置１０３で動作しているデバイス管理ソフトウェア４００１のエラー管理モジュール４１０２の動作について説明する。
図８は、本発明の管理装置１０３で動作しているデバイス管理ソフトウェア４００１のエラー管理モジュール４１０２の動作の一例を示すフローチャートである。なお、図８中のＳ１０１０１〜Ｓ１０３０１は、エラー管理モジュール４１０２が実行する各ステップを示す。

まず、エラー管理モジュール４１０２は、Ｓ１０１０１において、管理エージェント５００１のエラー管理モジュール５１０２から図５のＳ７２０１で送信されたエラー通知を受信すると、Ｓ１０１０２に処理を進める。

Ｓ１０１０２では、エラー管理モジュール４１０２は、デバイス管理ソフトウェア４００１のエラー通知処理設定を取得する。エラー通知処理設定には、画面に表示して通知するか、管理者へメールを送信して通知するかを選択する設定などが考えられる。ここではその二つの通知方法が選択可能であるとする。なお、通知設定は、予め管理者により設定され、管理装置１０３のストレージ３０８等に保存され、デバイス管理ソフトウェア４００１内に読み込まれるものとする。さらに、エラー管理モジュール４１０２は、上記取得したエラー通知処理設定が、画面に表示して通知するか、管理者へメールを送信して通知するか判定する。

上記Ｓ１０１０２において、上記エラー通知処理設定が画面に表示して通知する設定であると判定した場合（画面表示通知の場合）、エラー管理モジュール４１０２は、Ｓ１０１０３へ処理を進める。

Ｓ１０１０３では、エラー管理モジュール４１０２は、管理装置１０３のＨＩＤインタフェース３０７を通じて出力デバイス３１０上に、エラー通知の内容を表示し、本フローチャートの処理を終了する。

一方、上記Ｓ１０１０２において、上記エラー通知処理設定が、管理者へメールを送信して通知する設定であると判定した場合（メール通知）、エラー管理モジュール４１０２は、Ｓ１０２０１へ処理を進める。

Ｓ１０２０１では、エラー管理モジュール４１０２は、まず電子メールデータ（エラー通知メール）を生成する。そして、エラー管理モジュール４１０２は、当該電子メールデータの本文部分に、エラー通知の内容を、電子メールデータの本文部分に使用可能なように整形したデータをセットする。さらに、エラー管理モジュール４１０２は、当該電子メールデータのヘッダ部分の宛先項目に、デバイス管理ソフトウェア４００１内で記憶された管理者のメールアドレスを取得し設定する。なお、上記管理者のメールアドレスは、予め管理者により設定され、管理装置１０３のストレージ３０８等に保存され、デバイス管理ソフトウェア４００１内に読み込まれるものとする。

ここで、図９を用いて、上記Ｓ１０２０１で生成されるエラー通知メールについて説明する。
図９は、図８のＳ１０２０１で生成される実施例１のエラー通知メールの一例を示す図である。
図９において、１１００１は、エラー通知メールとしての電子メールデータのヘッダ部分である。１１００２は、エラー通知メールとしての電子メールデータの本文部分である。

以下、図８のフローチャートの説明に戻る。
上記Ｓ１０２０１のエラー通知メールの生成を完了すると、エラー管理モジュール４１０２は、Ｓ１０２０２に処理を進める。
Ｓ１０２０２では、エラー管理モジュール４１０２は、上記Ｓ１０２０１で生成したエラー通知メールを送信する。詳細には、エラー管理モジュール４１０２は、デバイス管理ソフトウェア４００１内に記憶されているメールサーバ設定で指定されるメールサーバに対して電子メール送信のためのセッションを開き、上記エラー通知メールを送信する。なお、上記メールサーバ設定は、予め管理者により設定され、管理装置１０３のストレージ３０８等に保存され、デバイス管理ソフトウェア４００１内に読み込まれるものとする。そして、エラー管理モジュール４１０２は、上記エラー通知メールの送信が成功したかどうかを判定する。

上記エラー通知メールの送信が成功したと判定した場合（Ｓ１０２０２でメール送信成功の場合）、エラー管理モジュール４１０２は、本フローチャートの処理を終了する。
一方、上記エラー通知メールの送信でエラーが発生したと判定した場合（Ｓ１０２０２でメール送信エラーの場合）、エラー管理モジュール４１０２は、Ｓ１０３０１に処理を進める。

Ｓ１０３０１では、エラー管理モジュール４１０２は、管理装置１０３のＨＩＤインタフェース３０７を通じて出力デバイス３１０上に、エラー通知メールの送信がエラーになったことを表示し、Ｓ１０１０３に処理を戻し、同じく管理装置１０３のＨＩＤインタフェース３０７上にエラー通知の内容を表示する。そして、本フローチャートの処理を終了する。

以下、図１０を用いて、実施例１の全体の処理の流れを説明する。
図１０は、実施例１の全体の処理の流れを模式的に示す図である。なお、図中のＳ１２００１〜Ｓ１２００９は、管理装置１０３、デバイス１０２、クライアント装置１０４のいずれかが実行するステップを示す。

Ｓ１２００１において、管理装置１０３は、デバイス１０２に対して、インストーラファイルをアップロードする。
Ｓ１２００２において、インストーラファイルを受信したデバイス１０２上の管理エージェント５００１は、当該ファイルをストレージ２０３内に保存した後、現在のデバイス１０２の属性値で書き換える（属性値書換）。

次に、Ｓ１２００３において、クライアント装置１０４からリクエストがあった場合には、デバイス１０２からクライアント装置１０４へ当該インストーラファイルのダウンロードが行われる。

次に、一般ユーザがインストールファイルの実行を指示すると、Ｓ１２００４において、クライアント装置１０４は、インストールファイルを実行し、インストーラ６０００によりインストールを行う。そして、クライアント装置１０４はエラーが発生したかどうかのチェックを行う。エラーが発生した場合（Ｓ１２００５）、クライアント装置１０４は、Ｓ１２００６において、エラー情報（インストーラＩＤ等を含む）をデバイス１０２上の管理エージェント５００１に対して送信する。

デバイス１０２上の管理エージェント５００１は、クライアント装置１０４からエラー情報（インストーラＩＤ等を含む）を受信すると、Ｓ１２００７において、当該エラー情報の解析を行う。そして、デバイス１０２上の管理エージェント５００１は、Ｓ１２００８において、エラー情報の解析結果を、管理装置１０３へエラー通知するとともに、必要であれば、Ｓ１２００９において、上記インストーラファイルのダウンロード停止を行う。

背景技術の欄等で示したように、従来より、一般ユーザがデバイスからクライアント装置にダウンロードしたインストーラファイルにより、デバイスドライバをインストールするシステムがあった。

そのようなシステムを構築するにおいて、本発明の実施例１を適用すれば、当該インストーラが実行された際にエラーが発生した場合、インストーラからデバイスの管理エージェント５００１へエラー情報（インストーラＩＤ等を含む）を送信することが可能になる。この時、インストーラは、デバイスドライバを設定するために使用可能であるデバイス１０２のネットワークアドレス情報を、管理エージェント５００１へエラー情報を送信する際に流用することが可能になる。さらに、管理エージェント５００１は、上記インストーラから受信したエラー情報（インストーラＩＤ等を含む）を解析することにより、当該インストーラソフトウェアのダウンロードを停止すべきかどうかを判断し、停止することが可能となる。また、デバイス管理ソフトウェア４００１は、管理エージェント５００１から受信したエラーの発生通知を管理者に転送し、管理者に対してエラーの発生を通知することができる。

これらの構成により、本発明の実施例１の管理システムは、デバイスドライバのインストーラのダウンロードとそのインストールを容易にすることができることに加えて、次のような効果を奏する。インストーラがエラーを発生したときに、デバイスの管理エージェント５００１が、必要な場合にはダウンロードを自動的に停止することで、他の一般ユーザが同様のインストールを実行しエラーを再発させることを防止できる。これにより、配布するインストーラについて管理を行う管理者の管理にかかる負荷を大幅に軽減することができる。

次に、本発明の実施例２について図面を用いて説明する。
なお、実施例２では、実施例１と異なる箇所のみ説明を行う。
以下、図１１を用いて、実施例２における管理エージェント５００１のエラー管理モジュール５１０２の内部処理について説明する。
図１１は、実施例２における管理エージェント５００１のエラー管理モジュール５１０２の内部処理の一例を示すフローチャートである。なお、図中のＳ７１０１〜Ｓ１３３０５は、エラー管理モジュール５１０２が実行する各ステップを示す。

Ｓ７１０１〜Ｓ７１０４は、図５に示したものと同一であるので説明は省略する。
Ｓ７２０１において、エラー管理モジュール５１０２は、Ｓ７１０３にて取得した解析結果により、エラーの原因がインストーラ６０００にあったのか、クライアント装置１０４又はそのＯＳにあったのかを判定する。そして、エラー管理モジュール５１０２は、エラー原因が確定できたかどうか判定する。

上記Ｓ７２０１において、エラー原因が特定できたと判定した場合（原因確定の場合）、エラー管理モジュール５１０２は、Ｓ７１０１で受信したエラー情報および解析した判定結果を、エラー通知として、管理装置１０３上のエラー管理モジュール４１０２へ送信し、Ｓ７２０２に処理を進める。なお、Ｓ７２０２〜Ｓ７２０３は、図５と同一の処理であるので説明は省略する。

なお、実環境においてはエラー情報が充分収集できないなどの要因があり、どちらに原因があったのかを判定できないケースが存在する。そのように、エラー原因が特定できなかったと判定した場合（Ｓ７２０１で情報不足で原因不確定の場合）、エラー管理モジュール５１０２は、Ｓ１３３０１に処理を進める。

Ｓ１３３０１では、エラー管理モジュール５１０２は、Ｓ７１０１で受信したエラー情報から特徴量を抽出し、該抽出した特徴量をストレージ２０３内に蓄積する。なお、特徴量とは、例えば、エラーコードや、メモリダンプ内の特定の領域の情報等のように、発生したエラーに対応する特徴的な情報であればどのような情報であってもよい。

次に、Ｓ１３３０４において、エラー管理モジュール５１０２は、上記Ｓ１３３０１でエラー情報から抽出した特徴量を、これまでに蓄積されたものとの間で照合する。
次に、Ｓ１３３０５において、エラー管理モジュール５１０２は、上記Ｓ１３３０４で照合を行った結果を取得して、特徴量の類似しているエラー情報が時系列的にどれくらいの期間どれくらいの頻度で発生しているかを判定する。さらに、エラー管理モジュール５１０２は、該判定の結果、現在から一定期間過去の間に一定基準数を超える回数繰り返し同一特徴量を持ったエラー情報が受信されている（頻度高）かどうかを判定する。

そして、現在から一定期間過去の間に一定基準数を超える回数繰り返し同一特徴量を持ったエラー情報が受信されていると判定した場合、Ｓ１３３０５で「頻度高」と判定し、エラー管理モジュール５１０２は、Ｓ７２０３に処理を進める。そして、Ｓ７２０３において、エラー管理モジュール５１０２は、当該インストーラ６０００に対応するインストーラファイルのダウンロードを停止し、本フローチャートの処理を終了する。

一方、上記Ｓ１３３０５で、エラー管理モジュール５１０２は、現在から一定期間過去の間に一定基準数を超える回数繰り返し同一特徴量を持ったエラー情報が受信されていないと判定した場合、「頻度低」と判定し、エラー管理モジュール５１０２は、そのまま本フローチャートの処理を終了する。

以上示したように、実施例２によれば、エラーの原因がインストーラ６０００とクライアント装置１０４のいずれにあるのか判定不可能な場合にも、類するエラーが頻発することを検知した場合には、ダウンロードを停止する。これにより、実施例１の効果に加えて、エラーが頻発するインストーラについては、その実行ファイルのダウンロードを自動的に停止することが可能となる。少なくともエラー情報が蓄積されていけば、それ以降はそのようなインストールの実行を防止することができる。この結果、管理者の管理負担をさらに軽減することが可能となる。

次に、本発明の実施例３について図面を用いて説明する。
なお、実施例３では、実施例２と異なる箇所のみ説明を行う。
以下、図３（ａ）に示したデバイス管理ソフトウェア４００１内の条件管理モジュール４１０３について説明する。
実施例３において、条件管理モジュール４１０３は、管理エージェント５００１から追加判定条件データをダウンロードする機能を備える。条件管理モジュール４１０３は、エラー管理モジュール５１０２から受信した追加判定条件データを、管理装置１０３のストレージ３０８に蓄積する機能を備えている。また、条件管理モジュール４１０３は、追加判定条件データに対して、管理者が個別の条件を編集したり、削除したり、あるいは新規の条件を追加したりする編集手段を与える。さらに、条件管理モジュール４１０３は、追加判定条件データを管理エージェント５００１へアップロードする機能を備える。

追加判定条件データは、レコードＩＤ、追加判定条件式、ダウンロード停止フラグにより、１つのレコードを構成する。追加判定条件データは、１又は複数のレコードで構成される。なお、追加判定条件データの詳細は、後述する図１２の１７２０１に示す。

実施例３において、エラー管理モジュール５１０２は、デバイス管理ソフトウェア４００１の条件管理モジュール４１０３からのダウンロード要求に応じて、条件管理モジュール４１０３に対して、追加判定条件データを送信する機能を備えている。また、エラー管理モジュール５１０２は、条件管理モジュール４１０３からアップロードされる追加判定条件データを受信する機能を備えている。そして、エラー管理モジュール５１０２は、条件管理モジュール４１０３から受信した追加判定条件データを、ストレージ２０３に蓄積する機能を備えている。

さらに、エラー管理モジュール５１０２は、インストーラ６０００から受信したエラー情報と、上記追加判定条件データ内の判定条件とが一致しているかどうかを検出する機能を備えている。

以下、図１２を参照して、条件管理モジュール４１０３のユーザインタフェースについて説明する。
図１２は、実施例３のデバイス管理ソフトウェア４００１の条件管理モジュール４１０３のユーザインタフェースとしての追加判定条件設定画面の一例を示す図である。この画面は、条件管理モジュール４１０３により、管理装置１０３の出力デバイス３１０に表示され、入力デバイス３０９からの入力を受け付け可能に制御される。

図１２において、１７１０１は、ダウンロードボタンである。ダウンロードボタン１７１０１が入力デバイス３０９を用いてユーザにより押下されると、条件管理モジュール４１０３は、追加判定条件のダウンロードを実行する。詳細には、条件管理モジュール４１０３は、管理エージェント５００１のエラー管理モジュール５１０２に対してダウンロードの要求を行う。当該要求に応じて、エラー管理モジュール５１０２が追加判定条件データを条件管理モジュール４１０３に送信し、該追加判定条件データを条件管理モジュール４１０３が受信する。

１７１０２は、編集ボタンである。編集ボタン１７１０２が入力デバイス３０９を用いてユーザにより押下されると、デバイス管理ソフトウェアは、右ペインに編集画面（１７２０１〜１７４０４で構成される）を表示する。図１２は、編集画面が表示された状態を表している。

１７１０３は、アップロードボタンである。アップロードボタン１７１０３が入力デバイス３０９を用いてユーザにより押下されると、条件管理モジュール４１０３は、追加判定条件データのアップロードを行う。即ち、条件管理モジュール４１０３が追加判定条件データを管理エージェント５００１のエラー管理モジュール５１０２に送信し、該追加判定条件データを、エラー管理モジュール５１０２が受信する。

以下、編集ボタン１７１０２の押下により表示される編集画面について説明する。
１７２０１は、条件管理モジュール４１０３が受信した追加判定条件データを一覧表示するリストボックスである。１７３０１は、現在編集している追加判定条件のレコードＩＤを表示している。

１７３０２は、現在編集している追加判定条件の追加判定条件式の文字列を編集可能に表示するグラフィカルユーザインタフェース（ＧＵＩ）のコントロールである。１７３０３は、上記１７３０２に表示されている文字列を、判定条件に「含む」／「含まない」を選択するためのＧＵＩのコントロールである。１７３０４は、現在編集している追加判定条件のダウンロード停止フラグの値を「する」／「しない」に選択するためのＧＵＩのコントロールである。なお、コントロール１７３０１〜１７３０４は、入力デバイス３０９を用いて操作可能である。

１７４０１は、新規追加ボタンである。入力デバイス３０９を用いてユーザにより新規追加ボタン１７４０１が押下されると、条件管理モジュール４１０３は、現在編集している追加判定条件の値で新しいレコードを生成し、追加判定条件データに追加する。

１７４０２は、更新ボタンである。入力デバイス３０９を用いてユーザにより更新ボタン１７４０２が押下されると、条件管理モジュール４１０３は、現在編集している追加判定条件の値を、上記１７３０１に表示されているレコードＩＤに対応する追加判定条件データのレコードに上書きする。

１７４０３は、削除ボタンである。入力デバイス３０９を用いてユーザにより削除ボタン１７４０３が押下されると、条件管理モジュール４１０３は、現在編集している追加判定条件の、上記１７３０１に表示されているレコードＩＤに対応する追加判定条件データのレコードを削除する。

１７４０４は、キャンセルボタンである。入力デバイス３０９を用いてユーザによりキャンセルボタン１７４０４が押下されると、条件管理モジュール４１０３は、現在編集している追加判定条件に対してユーザが加えた変更をすべて破棄し、編集をキャンセルする。

以下、図１３を用いて、実施例３における管理エージェント５００１のエラー管理モジュール５１０２の内部処理について説明する。
図１３は、実施例３における管理エージェント５００１のエラー管理モジュール５１０２の内部処理の一例を示すフローチャートである。なお、図中のＳ７１０１〜Ｓ１８４０１は、エラー管理モジュール５１０２が実行する各ステップを示す。

Ｓ７１０１〜Ｓ７１０４は、図１１に示したものと同一であるので説明は省略する。
エラー管理モジュール５１０２は、Ｓ７２０１において、エラー原因が特定できたと判定した場合（原因確定）、Ｓ７１０１で受信したエラー情報および解析した判定結果を、エラー通知として、管理装置１０３上のエラー管理モジュール４１０２へ送信し、Ｓ７２０２に処理を進める。なお、Ｓ７２０２〜Ｓ１３３０５は、図１１に示したものと同一であるので説明は省略する。

一方、上記Ｓ７２０１において、インストーラ６０００に原因があるのかクライアント装置１０４に原因があるのか特定できなかったと判定した場合（原因不確定）、エラー管理モジュール５１０２は、Ｓ１８４０１に処理を進める。

Ｓ１８４０１では、エラー管理モジュール５１０２は、Ｓ７１０１で受信したエラー情報と一致するものが、蓄積されている追加判定データの中にあるか検出する処理を行い、一致するものが検出されたかどうかを判定する。

一致するものが検出されたと判定した場合（Ｓ１８４０１で「一致あり」の場合）、エラー管理モジュール５１０２は、その追加判定条件に基づいて、Ｓ７２０２の処理を実行するように制御する。Ｓ１８４０１からＳ７２０２へ進んだ場合には、エラー管理モジュール５１０２は、一致した追加判定条件を表す追加判定条件データのレコードを参照し、そのダウンロード停止フラグの値を取得する。さらに、エラー管理モジュール５１０２は、ダウンロード停止フラグの値が「（ダウンロード停止）する」であった場合には、「停止必要」と判断し、Ｓ７２０３に処理を進める。一方、ダウンロード停止フラグの値が「（ダウンロード停止）しない」であった場合には、エラー管理モジュール５１０２は、「停止不要」と判断し、そのまま処理を終了する。

一方、上記Ｓ１８４０１において、一致するものが検出されなかったと判定した場合（「一致なし」の場合）、エラー管理モジュール５１０２は、Ｓ１３３０１に処理を進める。Ｓ１３３０１〜Ｓ１３３０５の説明は省略する。

以上のように、実施例３によれば、エラーの原因がインストーラ６０００とクライアント装置１０４のいずれにあるのか判定不可能な場合に、管理者が追加した判定条件に対する一致を判定し、一致したデータに基づいてダウンロードを停止するか否かを決定することが可能となる。そこで一致する判定条件がなかった場合には、さらに、取得したエラー情報に類するエラーが頻発することを検知した場合にはダウンロードを停止する。このような構成により、実施例２の構成ではダウンロードを自動的に停止できないような場合でも、管理者が判定条件を自在に追加することにより、ダウンロードを自動的に停止するかどうかを決定することが可能となる。よって、管理者が指定した条件に合致するエラー情報をもたらすエラーが発生した場合には、以後そのようなインストールの実行を防止することができる。この結果、管理者の管理負担をさらに軽減することが可能となる。

以下、本発明の実施例４について図面を用いて説明する。
なお、実施例４では、実施例１と異なる箇所のみ説明を行う。
実施例４のファイル管理モジュール５１０１（図３（ｂ））は、ダウンロード時にユーザの認証を行う機能をさらに備えている。
以下、図１４を用いて、実施例４のファイル管理モジュール５１０１の処理について説明する。
図１４は、実施例４のファイル管理モジュール５１０１の処理の一例を示すフローチャートである。なお、図中のＳ２０１０１〜Ｓ２０３０１は、ファイル管理モジュール５１０１が実行する各ステップを示す。

まず、ファイル管理モジュール５１０１は、Ｓ２０１０１において、クライアント装置１０４からのダウンロード要求を受信すると、Ｓ２０１０２に処理を進める。
Ｓ２０１０２では、ファイル管理モジュール５１０１は、当該クライアント装置１０４に対してユーザ認証を要求する。
そして、Ｓ２０１０３において、ファイル管理モジュール５１０１は、当該クライアント装置１０４から、応答として送信されてきたユーザ認証情報を受信すると、Ｓ２０１０４に処理を進める。

Ｓ２０１０４では、ファイル管理モジュール５１０１は、上記Ｓ２０１０３で受信したユーザ認証情報に基づいて、ユーザ認証を実行し、ユーザ認証が成功したかどうかを判定する。なお、認証情報は、デバイス１０２のストレージ３０８に記憶されているものであっても、又は他の装置に記憶されているものであってもよい。また、図示しない認証サーバ等に認証処理を依頼する構成であってもよい。

上記２０１０４において、ユーザ認証が成功したと判定した場合（認証成功の場合）、ファイル管理モジュール５１０１は、Ｓ２０２０１に処理を進める。
Ｓ２０２０１では、ファイル管理モジュール５１０１は、インストーラファイルに対して、上記認証に成功したユーザ認証情報から抽出したユーザ情報を埋め込む。
次に、Ｓ２０２０２において、ファイル管理モジュール５１０１は、上記Ｓ２０２０１でユーザ情報が埋め込まれたインストーラファイルを、上記クライアント装置１０４へダウンロードするために送信する。該ダウンロードが完了すると、ファイル管理モジュール５１０１は、本フローチャートの処理を終了する。

一方、上記２０１０４において、ユーザ認証が失敗したと判定した場合（認証失敗の場合）、ファイル管理モジュール５１０１は、Ｓ２０３０１に処理を進める。
Ｓ２０３０１では、ファイル管理モジュール５１０１は、ユーザ認証に失敗したことを、クライアント装置１０４へ通知し（ダウンロードエラー返却）、本フローチャートの処理を終了する。

以下、図１５を用いて、実施例４のインストーラ６０００の処理について説明する。
図１５は、実施例４のクライアント装置１０４のＯＳ上で実行されるインストーラ６０００の処理の一例を示すフローチャートである。なお、図中のＳ６１０１〜Ｓ６１０３，Ｓ６２０２，Ｓ２１３０１〜Ｓ２１３０２は、インストーラ６０００が実行する各ステップを示す。

Ｓ６１０１〜Ｓ６１０３，Ｓ６２０１の処理は、図４に示したものと同一であるので説明は省略する。
Ｓ６２０１でエラー情報を取得したのち、インストーラ６０００は、Ｓ２１３０１に処理を進める。
Ｓ２１３０１では、インストーラ６０００は、上記図１４のＳ２０２０１でファイル管理モジュール５１０１によりインストーラファイルに埋め込まれたユーザ情報を取得する。

次に、Ｓ２１３０２において、インストーラ６０００は、上記Ｓ２１３０１で取得したユーザ情報を、送信対象であるエラー情報に追加で埋め込む。
次に、Ｓ６２０２において、インストーラ６０００は、上記Ｓ６２０１にて収集され一元化され、上記Ｓ２１３０２にてユーザ情報が埋め込まれたエラー情報を、管理エージェント５００１のエラー管理モジュール５１０２へ送信し、本フローチャートの処理を終了する。

このように、上記インストーラ６０００から送信されたエラー情報を受信すると、エラー管理モジュール５１０２は、該エラー情報を解析し、エラー通知データ（図７）を作成する（図５のＳ７１０１〜Ｓ７１０３）。なお、実施例４のエラー管理モジュール５１０２は、エラー通知データを作成する場合に、該エラー通知データのユーザ情報２２１０１に、上記Ｓ７１０１で受信したエラー情報に埋め込まれているユーザ情報を格納する。なお、このユーザ情報は、上記図１４のＳ２０２０１にてファイル管理モジュール５１０１によりインストーラファイルに埋め込まれ、さらに、上記図１５のＳ２１３０２にてインストーラ６０００によりエラー情報に埋め込まれたユーザ情報に対応する。

エラー通知データを作成すると、エラー管理モジュール５１０２は、該エラー通知データを、デバイス管理ソフトウェア４００１のエラー管理モジュール４１０２に対して送信する。

このように、上記エラー管理モジュール５１０２から送信されたエラー通知データを受信し、エラー通知処理設定がメール通知の場合、エラー管理モジュール４１０２は、電子メールデータ（エラー通知メール）を生成する（図８のＳ１００１〜Ｓ１０２０１）。なお、実施例４のエラー管理モジュール４１０２は、エラー通知メールを作成する場合に、図１６に示すようなエラー通知メールを作成する。

ここで、図１６を用いて、実施例４のエラー通知メールについて説明する。
図１６は、図８のＳ１０２０１で生成される実施例４のエラー通知メールの一例を示す図である。
ヘッダ部分１１００１は、図９と同様である。本文部分２３１０１は、図９の本文部分１１００２と比較してユーザ情報２３１０２が追加されている。即ち、実施例４のエラー管理モジュール４１０２は、エラー通知メールを作成する場合に、エラー通知データに埋め込まれているユーザ情報を、エラー通知メールの本文２３１０１に記載する。なお、このユーザ情報２３１０２は、上記図１４のＳ２０２０１にてファイル管理モジュール５１０１によりインストーラファイルに埋め込まれ、さらに、上記図１５のＳ２１３０２にてインストーラ６０００によりエラー情報に埋め込まれ、さらに、上記図５のＳ７１０３にてエラー管理モジュール５１０２によりエラー通知データのユーザ情報２２１０１に格納されたユーザ情報に対応する。

以下、図１７を用いて、実施例４の全体の処理の流れを説明する。
図１７は、実施例４の全体の処理の流れを模式的に示す図である。なお、図中のＳ１２００１〜Ｓ１２００９、Ｓ１５０１〜Ｓ１５０２は、管理装置１０３、デバイス１０２、クライアント装置１０４のいずれかが実行するステップを示す。

Ｓ１２００１〜Ｓ１２００９は、図１０に示したものと同一であるので説明を省略する。
Ｓ１５０１において、クライアント装置１０４の一般ユーザは、デバイス１０２の管理エージェント５００１にログインするために、デバイス１０２の管理エージェント５００１に、認証情報を送信する。

クライアント装置１０４から認証要求があると、デバイス１０２の管理エージェント５００１は、Ｓ１５０２において、認証処理を行い、該認証処理で得たユーザ情報を、Ｓ１２００３でダウンロードするインストーラファイルに付加する。

また、Ｓ１２００５にてエラーが発生した場合には、クライアント装置１０４で実行されているインストーラ６０００は、Ｓ１２００６で送信するエラー情報に、上記ダウンロードしたインストーラファイルに付加されていたユーザ情報を付加する。

また、デバイス１０２の管理エージェント５００１は、Ｓ１２００８にて管理装置１０３に対して送信されるエラー通知に、上記エラー情報に付加されていたユーザ情報を付加する。

以上示したように、実施例４によれば、実施例１の効果に加えて、管理者は、インストーラがエラーを発生したときに、それがどのユーザによりダウンロードされたインストーラファイルによるものであるかを容易に知ることができる。一方、インストーラがエラーを発生した場合に、そのエラーの原因がインストーラにあるのであれば、以後そのようなインストールの実行を防止することができる。加えて管理者は、そのインストーラをダウンロードしたユーザ本人にコンタクトを取って、状況を聞き取ることが可能になるため、迅速にトラブルシュートを完遂することが可能になる。よって、実施例４のシステムでは、これらの利点の結果として、管理者の管理負担をさらに軽減することが可能となる。

以下、本発明の実施例５について図面を用いて説明する。
なお、実施例５では、実施例４と異なる箇所のみ説明を行う。
実施例５のファイル管理モジュール５１０１（図３（ｂ））は、ユーザの操作に応じて、デバイス１０２の操作パネル２０４に、ドライバダウンロード手段を通知するためのメールアドレス入力画面（図１８）を表示する機能を備える。さらに、実施例５のファイル管理モジュール５１０１は、当該メールアドレス入力画面（図１８）にてユーザにより入力されたメールアドレスに対して、インストーラファイルを入手する手段について通知する電子メールを生成して送信する機能を備える。また、実施例５のファイル管理モジュール５１０１は、そのようにして通知メールを送信したメールアドレスを蓄積する機能を備える。

図１８は、実施例５のファイル管理モジュール５１０１がデバイス１０２の操作パネル２０４に表示するメールアドレス入力画面の一例を示す図である。
図１８において、２５１０１は、メールアドレス入力欄である。２５１０２は、通知メール送信ボタンである。２５１０３は、キャンセルボタンである。
一般ユーザが本画面をデバイス１０２の操作パネル２０４に表示させたのちに、メールアドレス入力欄２５１０１に自身のメールアドレスを入力し、通知メール送信ボタン２５１０２を押下すると、ファイル管理モジュール５１０１は、入力されたメールアドレスに対して、ファイルをダウンロードするための手段を通知する電子メールを送信する。

ここで、図１９を用いて、上記ファイルをダウンロードするための手段を通知する電子メールについて説明する。
図１９は、ファイルをダウンロードするための手段を通知する電子メールの一例を示す図である。
図１９において、２６００１は、電子メールのヘッダ部分である。２６００２は、電子メールの本文部分である。２６００３は、インストーラファイルを入手するためのダウンロード画面（ダウンロードページ）のワールドワイドウェブのアドレスを示す汎用リソース位置記述子（以下ＵＲＬ）である。

一般ユーザは、図１９に示すような電子メールをクライアント装置１０４で受信したのちに、当該電子メールに含まれるＵＲＬ２６００３をクリックして、Ｗｅｂブラウザを用いて、インストーラファイルを入手するためのダウンロード画面にアクセスする。さらに、一般ユーザは、該ダウンロード画面から、インストーラファイルのダウンロード要求を行い、インストーラファイルをクライアント装置１０４にダウンロードすることが可能となる。

なお、ＵＲＬ２６００３には、ハッシュタグが付加されている。ハッシュタグは、当該電子メールの送信先のメールアドレス（ｆｏｏｂａｒ＠ｅｘａｍｐｌｅ.ｃｏｍ）をそのまま表現する「＃ｆｏｏｂａｒ＋ａｔ＋ｅｘａｍｐｌｅ＋ｄｏｔ＋ｃｏｍ」という形式で提示されている。しかし、ここをランダムな文字列に置き換え、当該ランダムな文字列と当該メールアドレスを組のデータとして蓄積しておいてもよい。

以下、図２０を用いて、実施例５のファイル管理モジュール５１０１の処理について説明する。
図２０は、実施例５のファイル管理モジュール５１０１の処理の一例を示すフローチャートである。なお、図中のＳ２０１０１〜Ｓ２０３０１、Ｓ２７１０１〜Ｓ２７２０１は、ファイル管理モジュール５１０１が実行する各ステップを示す。

なお、Ｓ２０１０１は、図１４に示したものと同一であるので説明は省略する。
Ｓ２７１０１において、ファイル管理モジュール５１０１は、Ｓ２０１０１で受信したダウンロード要求を解析し、そのリクエストＵＲＬからメールアドレスを抽出する。さらに、ファイル管理モジュール５１０１は、リクエストＵＲＬからメールアドレスの抽出に成功したかどうかを判定する。

ＵＲＬのハッシュタグにメールアドレスをそのまま記載する方式を選択した場合、リクエストＵＲＬに、ＵＲＬ２６００３には付帯していたハッシュタグ「＃ｆｏｏｂａｒ＋ａｔ＋ｅｘａｍｐｌｅ＋ｄｏｔ＋ｃｏｍ」が含まれていないと、メールアドレスの抽出に失敗したと判定する。また、メールアドレスとして正規の形式に読み替えることができない文字列がハッシュタグとして付与されている場合にも、メールアドレスの抽出に失敗したと判定する。

あるいは、ＵＲＬのハッシュタグにランダム文字列を記載する方式を選択した場合、付帯していたハッシュタグのランダム文字列が、通知メールアドレスとして蓄積された中に記録されていなかった場合にはメールアドレスの抽出に失敗したと判定する。

上記Ｓ２７１０１において、メールアドレスの抽出に失敗したと判定した場合（抽出失敗の場合）、ファイル管理モジュール５１０１は、Ｓ２０３０１に処理を進め、ダウンロードエラーをクライアント装置１０４へ返却して、本フローチャートの処理を終了する。なお、Ｓ２０３０１は、図１４に示したものと同一であるので説明は省略する。

一方、上記Ｓ２７１０１において、メールアドレスの抽出に成功したと判定した場合（抽出成功）、ファイル管理モジュール５１０１は、Ｓ２７２０１に処理を進める。
Ｓ２７２０１では、ファイル管理モジュール５１０１は、上記Ｓ２７１０１で抽出したメールアドレスを、インストーラファイルに埋め込み、Ｓ２０２０２において、該インストーラファイルを上記クライアント装置１０４へ送信し、本フローチャートの処理を終了する。

実施例５のクライアント装置１０４のＯＳ上で実行されるインストーラ６０００の処理は、図１５に示したものに準ずる。ただし、図１５でユーザ情報としているものは、実施例５では、インストーラファイルから抽出されたメールアドレスとする。

即ち、インストーラ６０００は、ファイルセット展開エラー又はコマンド起動エラーが発生した場合、エラー情報を収集し、該収集したエラー情報に、ユーザ情報として、インストーラファイルに埋め込まれたメールアドレスを埋め込み、該エラー情報を、エラー管理モジュール５１０２へ送信する。

以下、図２１を参照して、実施例５における管理エージェント５００１のエラー管理モジュール５１０２により行われる処理について説明する。
図２１は、実施例５における管理エージェント５００１のエラー管理モジュール５１０２により実行される処理の一例を示すフローチャートである。なお、図中のＳ７１０１〜Ｓ７２０３、Ｓ２８３０１〜Ｓ２８３０３は、エラー管理モジュール５１０２が実行する各ステップを示す。

Ｓ７１０１〜Ｓ７２０３は、図５に示したものと同一であるので説明は省略する。ただし、実施例５では、ユーザ情報としてメールアドレスを用いるため、Ｓ７１０３で生成するエラー通知データのユーザ情報２２１０１には、上記Ｓ７１０１で受信したエラー情報にユーザ情報として埋め込まれているメールアドレスを格納する。

Ｓ７２０２にてダウンロード停止必要と判定した場合、エラー管理モジュール５１０２は、ダウンロード停止処理（Ｓ７２０３）を実行した後に、Ｓ２８３０１に処理を進める。

一方、Ｓ７２０２にてダウンロード停止不必要と判定した場合、エラー管理モジュール５１０２は、そのままＳ２８３０１に処理を進める。
Ｓ２８３０１では、エラー管理モジュール５１０２は、Ｓ７１０１で受信したエラー情報に埋め込まれているメールアドレス（即ち、ダウンロードされたインストーラファイルに埋め込またメールアドレス）を抽出する。

次に、Ｓ２８３０２において、エラー管理モジュール５１０２は、インストーラ６０００でエラーが発生した一般ユーザに対して、上記Ｓ２８３０１で抽出したメールアドレスを用いて通知を行うためのメールを生成する。
次に、Ｓ２８３０３において、エラー管理モジュール５１０２は、上記Ｓ２８３０２で生成したメールを送信し、本フローチャートの処理を終了する。

ここで、図２２を用いて、Ｓ２８３０２で生成されるメールについて説明する。
図２２は、図２１のＳ２８３０２で生成される電子メールの一例を示す図である。
図２２（ａ）は、インストーラ６０００に問題があった場合の電子メールの例である。
図２２（ａ）において、２９００１は、電子メールのヘッダ部分である。２９００２は、電子メールの本文部分である。本文部分２９００２には、インストーラファイルが壊れていたことが記載されており、ユーザは当該ファイルが正しいファイルに差し替えられるまで待機すること、という指示が記載されている。

また、図２２（ｂ）はクライアント装置１０４が原因でエラーになった場合の電子メールの例である。
図２２（ｂ）において、２９１０１は、電子メールのヘッダ部分である。２９１０２は、電子メールの本文部分である。本文部分２９１０２は、例えば、インストーラがクライアント装置１０４のＯＳに適合しなかったという原因について説明している。そのうえで、管理者に連絡を取り正しいファイルをダウンロードしてインストールを再実行するように、という指示が記載されている。

また、実施例５のデバイス管理ソフトウェア４００１のエラー管理モジュール４１０２が、エラー管理モジュール５１０２から図２１のＳ７１０４で送信されるエラー通知を受信して、生成する電子メールデータは、図１６に掲げたものに準ずる。ただし、生成する電子メールデータには、ユーザ情報２３１０２として、ダウンロードされたインストーラファイルに埋め込またメールアドレスが記載されている。

以下、図２３を用いて、実施例５の全体の処理の流れを説明する。
図２３は、実施例５の全体の処理の流れを模式的に示す図である。なお、図中のＳ１２００１〜Ｓ１２００９、Ｓ１９００１〜Ｓ１９００５は、管理装置１０３、デバイス１０２、クライアント装置１０４のいずれかが実行するステップを示す。

Ｓ１２００１〜Ｓ１２００２は、図１７に示したものと同一であるので説明を省略する。
Ｓ１９００１において、一般ユーザによるデバイス１０２上からの通知メール送信ボタン２５１０２の操作を検知すると、デバイス１０２の管理エージェント５００１は、Ｓ１９００２に処理を進める。

Ｓ１９００２では、デバイス１０２の管理エージェント５００１は、上記Ｓ１９００１でユーザにより入力されたメールアドレスをＲＡＭ３０４又はストレージ３０８に記録する。

さらに、Ｓ１９００３において、デバイス１０２の管理エージェント５００１は、上記Ｓ１９００２で記録したメールアドレスに、ＵＲＬにハッシュタグを付加したものを記載した通知メール（図１９）を送信する。当該一般ユーザは、クライアント装置１０４にてそのメールを受信したら、該メールに記載されたＵＲＬをクリックする。この操作に応じて、クライアント装置１０４は、Ｓ１９００４において、Ｗｅｂブラウザを用い、上記ＵＲＬにアクセスし、ダウンロード要求を行う。

これによりダウンロード要求しているユーザのメールアドレスを特定することが可能になるため、デバイス１０２の管理エージェント５００１は、Ｓ１２００３でダウンロードされるインストーラファイルに、当該ユーザのユーザ情報として、当該ユーザのメールアドレスを付与する。なお、Ｓ１２００３〜Ｓ１２００４は、図１７に示したものと同一であるので説明を省略する。

また、Ｓ１２００５にてエラーが発生した場合には、クライアント装置１０４で実行されているインストーラ６０００は、Ｓ１２００６で送信するエラー情報に、上記ダウンロードしたインストーラファイルに付加されていたユーザ情報（本実施例では、メールアドレス）を付加する。

また、デバイス１０２の管理エージェント５００１は、Ｓ１２００７にてエラー情報を解析し、Ｓ１２００８にて管理装置１０３に対して送信されるエラー通知に、上記エラー情報に付加されていたユーザ情報として、メールアドレスを付加する。そして、Ｓ１２００９において、上記インストーラファイルのダウンロード停止を行う。

さらに、Ｓ１９００５において、デバイス１０２の管理エージェント５００１は、上記エラー情報にユーザ情報として付加されていたメールアドレスを持つ当該一般ユーザに、エラーの内容を通知するメール（図２２）を送信する。

以上示したように、実施例５によれば、実施例４の効果に加え、管理者は、インストーラがエラーを発生したときに、それがどのユーザによりダウンロードされたものであるかを容易に知ることができる。また、管理エージェント５００１が、上記インストーラでエラーが発生した一般ユーザへ直接状況を報せる電子メールを送信することにより、一般ユーザも直ちに何が起こっているかを知ることができるようになり、適切な対処が可能となる。また、管理者は、より迅速にトラブルシュートを完遂することが可能になる。本実施例のシステムは、これらの利点の結果として管理者の管理負担をさらに軽減することが可能となる。

なお、実施例５では、デバイス１０２の操作パネル２０４に表示されるメールアドレス入力画面（図１８）から、インストーラのダウンロードを要求するユーザのメールアドレスを入力する構成を説明した。しかし、デバイス１０２の操作パネル２０４からユーザＩＤ等を入力して、予めユーザＩＤに紐付けられた該ユーザのメールアドレスを取得するように構成してもよい。例えば、フェリカ等のＩＣカードを用いて、デバイス１０２にログインし、該ログインしたユーザに予め紐付けられた該ユーザのメールアドレスを取得して、インストーラファイルを入手する手段について通知する電子メールを生成して送信するようにしてもよい。

なお、ユーザＩＤ等のユーザの情報に紐付けられた該ユーザのメールアドレスは、デバイス１０２のストレージ３０８に記憶されているものであっても、他の装置に記憶されているものであってもよい。また、デバイス１０２が、図示しない認証サーバ等に認証処理を依頼し、認証に成功した場合に、該サーバから取得する構成であってもよい。

また、デバイス１０２から送信するインストーラファイルを入手する手段について通知は、電子メールに限定されるものではない。電子メール以外の手段であっても、ユーザのアカウントに対して、インストーラファイルを入手する手段を通知可能な方法であれば、どのような通知方法を用いてもよい。例えば、ユーザアカウント毎に割り当てられたホーム画面を開いて、該ユーザアカウント宛てに送信されたメッセージを閲覧可能なシステム等を用いてもよい。

以下、本発明の実施例６について図面を用いて説明する。
なお、実施例６では、実施例５と異なる箇所のみ説明を行う。
実施例６のファイル管理モジュール５１０１は、インストーラファイルのアップロード履歴およびダウンロード履歴のデータをデバイス１０２のストレージ２０３に蓄積する機能を備えている。なお、ダウンロード履歴のデータは、ダウンロード要求に含まれるユーザ情報（ここでは、ダウンロード者のメールアドレス）と、該ダウンロード要求の対象となるインストーラのインストーラＩＤとを対応付けたデータである。

以下、図２４を参照して、実施例６における管理エージェント５００１のエラー管理モジュール５１０２により行われる処理について説明する。
図２４は、実施例６における管理エージェント５００１のエラー管理モジュール５１０２により実行される処理の一例を示すフローチャートである。なお、図中のＳ７１０１〜Ｓ７２０３、Ｓ２８３０１〜Ｓ２８３０２、Ｓ３１４０１〜Ｓ３１４０５は、エラー管理モジュール５１０２が実行する各ステップを示す。

Ｓ７１０１〜Ｓ７２０３は、図２１に示したものと同様であるので説明は省略する。
Ｓ７２０２にてダウンロード停止必要と判定した場合、エラー管理モジュール５１０２は、ダウンロード停止処理（Ｓ７２０３）を実行した後に、Ｓ３１４０１に処理を進める。

Ｓ３１４０１では、エラー管理モジュール５１０２は、ファイル管理モジュール５１０１に蓄積されたアップロード履歴およびダウンロード履歴のデータを参照する。そして、エラー管理モジュール５１０２は、上記各履歴から、当該インストーラファイルをダウンロードしたダウンロード者のメールアドレス一覧を抽出し、Ｓ２８３０１に処理を進める。

一方、Ｓ７２０２にてダウンロード停止不必要と判定した場合、エラー管理モジュール５１０２は、Ｓ２８３０１に処理を進める。
Ｓ２８３０１では、エラー管理モジュール５１０２は、Ｓ７１０１で受信したエラー情報に埋め込まれているメールアドレス（即ち、ダウンロードされたインストーラファイルに埋め込またメールアドレス）を抽出する。

次に、Ｓ３１４０２において、エラー管理モジュール５１０２は、Ｓ７２０２におけるダウンロード停止の判断を参照する。そして、上記Ｓ７２０２にてダウンロードを停止すべき（ダウンロード停止必要）と判断していた場合には、エラー管理モジュール５１０２は、Ｓ３１４０３へ処理を進める。一方、上記Ｓ７２０２にてダウンロード停止不要と判断していた場合には、エラー管理モジュール５１０２は、Ｓ２８３０２へ処理を進める。

Ｓ３１４０３では、エラー管理モジュール５１０２は、上記Ｓ２８３０１で抽出した実際にエラーが発生した一般ユーザのメールアドレスを、上記Ｓ３１４０１で抽出したダウンロード者のメールアドレス一覧から除外する。

次に、Ｓ３１４０４において、エラー管理モジュール５１０２は、上記Ｓ３１４０３でエラーが発生した一般ユーザを除外したメールアドレス一覧を用いて、実際にエラーが発生した一般ユーザ以外のダウンロード者に対する通知メールを生成し、Ｓ２８３０２に処理を進める。

ここで、図２５を用いて、上記図２４のＳ３１４０４で生成される通知メールについて説明する。
図２５は、図２４のＳ３１４０４で生成される通知メールの一例を示す図である。
図２５において、３２００１は、通知メールのヘッダ部分である。３２００２は、通知メールの本文部分である。本文部分３２００２では、ダウンロードしたインストーラソフトウェア実行ファイルが壊れておりエラーを発生させることを警告し、インストールを実行しないよう通知している。

以下、図２４のフローチャートの説明に戻る。
Ｓ２８３０２では、エラー管理モジュール５１０２は、実際にエラーが発生した一般ユーザに対して、上記Ｓ２８３０１で抽出したメールアドレスを用いて通知を行うためのメールを生成する。ここで生成される通知メールは、図２２に示したものと同様である。

次に、Ｓ３１４０５において、エラー管理モジュール５１０２は、Ｓ２８３０２にて生成した電子メール、及び、もしスＳ３１４０４を実行していればそこで生成した電子メールを送信し、本フローチャートの処理を終了する。

以下、図２６を用いて、実施例６の全体の処理の流れを説明する。
図２６は、実施例６の全体の処理の流れを模式的に示す図である。なお、図中のＳ１２００１〜Ｓ１２００９、Ｓ１９００１〜Ｓ１９００５、Ｓ３０００１は、管理装置１０３、デバイス１０２、クライアント装置１０４のいずれかが実行するステップを示す。

Ｓ１２００１〜Ｓ１２００９、Ｓ１９００１〜Ｓ１９００５は、図２３に示したものと同一であるので詳細な説明は省略する。
Ｓ１９００５において、デバイス１０２上の管理エージェント５００１は、ダウンロードしエラーを実際に発生したクライアント装置１０４のユーザに対してエラー通知メール（図２２）を送信する。

管理エージェント５００１はＳ１９００５の後、あるいはＳ１９００５と並行して、Ｓ３０００１において、同一インストーラファイルをダウンロードした別のクライアント装置（１０４Ｂとする）のユーザに対するエラー通知メール（図２５）の送信である。これにより、同一のインストーラファイルをダウンロードしたユーザにはエラーが発生したことの通知が行われる。

以上示したように、実施例６によれば、管理エージェント５００１は、インストーラがエラーを発生した場合に、以下のような処置をとる。すなわち、実際にエラーを発生した一般ユーザに対しては状況を知らせるメールを送信する。さらに、当該エラーのエラー情報を解析した結果ダウンロードを停止すべきであると判断した場合、当該ファイルがアップロードされて以来ダウンロードを実行したユーザに対して状況を知らせるメールを送信する。このことにより、実施例６では、実施例５の効果に加え、まだエラーを発生させていないダウンロード者も当該インストーラファイルが壊れている（エラーが発生してしまう）ことを容易に知ることができるようになる。よって、実際にエラーの発生したクライアント装置１０４以外での新たなエラーの発生を未然に防止することが可能となる。実施例６のシステムは、これらの利点の結果として管理者の管理負担をさらに軽減することが可能となる。

次に本発明の実施例７について図面を用いて説明する。
なお、実施例７では、実施例６と異なる箇所のみ説明を行う。
以下、図３（ａ）に示したデバイス管理ソフトウェア４００１内のデバイス管理モジュール４１０４について説明する。
デバイス管理モジュール４１０４は、管理装置１０３が管理対象とする管理エージェント５００１が動作しているデバイス１０２ａ、１０２ｂ、１０２ｃのデータを蓄積している。

以下、図２７を参照して、実施例７におけるデバイス管理ソフトウェア４００１のファイル管理モジュール４１０１により行われる処理について説明する。
図２７は、実施例７におけるデバイス管理ソフトウェア４００１のファイル管理モジュール４１０１により実行される処理の一例を示すフローチャートである。なお、図中のＳ３５１０１〜Ｓ３５３０５は、ファイル管理モジュール４１０１が実行する各ステップを示す。

Ｓ３５１０１において、ファイル管理モジュール４１０１は、インストーラファイルの送信対象となるデバイスを取得する。送信対象となるデバイスは、管理者が画面上でデバイスデータ蓄積モジュール３４２０１に蓄積されている管理対象デバイスデータの中から送信対象となるデバイスとして選択したものを示す。あるいは、デバイスデータ蓄積モジュール３４２０１に蓄積されている管理対象デバイスデータの指す管理対象デバイス全てを送信対象デバイスとしてもよい。ここではデバイス１０２ａ、１０２ｂ、１０２ｃが送信対象となったと仮定して説明する。

次に、Ｓ３５１０２において、ファイル管理モジュール４１０１は、今回のアップロードに対して付与される一意の識別子であるトランザクションＩＤを生成する。
次に、Ｓ３５２０１において、ファイル管理モジュール４１０１は、以下のＳ３５３０１〜Ｓ３５３０５の処理を、上記Ｓ３５１０１で取得した送信対象デバイスに対して順番に実行し、全ての送信対象デバイスに対して処理が完了するまでループするように制御する。すなわち、上述の例では、Ｓ３５３０１〜Ｓ３５３０５の処理を、デバイス１０２ａ、１０２ｂ、１０２ｃに対して返して実行する（３回ループする）。

以下、Ｓ３５３０１〜Ｓ３５３０５の処理について説明する。
まず、Ｓ３５３０１において、ファイル管理モジュール４１０１は、例えばストレージ３０８に格納しておいた結合対象のファイル群を取得し、該ファイル群を結合してインストーラファイルを生成する。

ここで、図２８を用いて、実施例７において、ファイル管理モジュール４１０１が生成するインストーラファイルの構成について説明する。
図２８は、実施例７においてファイル管理モジュール４１０１が生成するインストーラファイルの構成の一例を示す図である。
なお、８００１〜８００５は、図６に示したものと同一であるので説明は省略する。
３６１０１は、図２７のＳ３５１０１で取得した送信対象デバイス全ての属性値を格納するための送信対象全デバイス属性値格納用データ領域である。ここでは、属性値としてそれぞれのデバイスの全属性値を網羅する必要はなく、少なくともデバイス（画像形成装置）を特定するための特定情報が含まれていればよく、個別のネットワークアドレスの一覧などを格納すれば充分である。

３６２０１は、オフセット値Ｃの格納領域である。オフセット値Ｃは、送信対象全デバイス属性値格納用データ領域３６１０１のファイル末尾からのオフセットを示す。３６２０２は、トランザクションＩＤの格納領域である。格納領域３６２０２は、図２７のＳ３５１０２にて生成されたトランザクションＩＤを格納するために使用される。

以下、図２７のフローチャートの説明に戻る。
次に、Ｓ３５３０２において、ファイル管理モジュール４１０１は、このループで現在送信対象としているデバイス（例えばデバイス１０２ａ）の属性値をインストール用デバイス属性値格納用データ領域８００３へ埋め込む。

次に、Ｓ３５３０３において、ファイル管理モジュール４１０１は、上記Ｓ３５１０１で取得した送信対象デバイス全てのそれぞれの属性値のうち必要なもの（例えば、ネットワークアドレス）を送信対象全デバイス属性値格納用データ領域３６１０１へ埋め込む。

次に、Ｓ３５３０４において、ファイル管理モジュール４１０１は、トランザクションＩＤの格納領域３６２０２へ、上記Ｓ３５１０２で生成したトランザクションＩＤを埋め込む。

次に、Ｓ３５３０５において、ファイル管理モジュール４１０１は、このループにおいて現在送信対象としているデバイス（例えばデバイス１０２ａ）上の管理エージェント５００１に対して、インストーラファイルをアップロードする。そして、ファイル管理モジュール４１０１は、上記Ｓ３５２０１に戻り、次の送信対象デバイスの処理に移行する。
そして、全ての送信対象デバイスに対して処理が完了すると（Ｓ３５２０１でループ終了）、ファイル管理モジュール４１０１は、本フローチャートの処理を終了する。

以下、図２９を用いて、実施例７において、インストーラ６０００により行われる処理について説明する。
図２９は、実施例７におけるインストーラ６０００の処理の一例を示すフローチャートである。なお、図中のＳ６１０１〜Ｓ６２０２、Ｓ３７３０１〜Ｓ３７３０２は、インストーラ６０００が実行する各ステップを示す。

なお、Ｓ６１０１〜Ｓ６１０３の処理は、図４に示したものと同一であるので説明は省略する。
Ｓ６２０１では、インストーラ６０００は、エラー情報の一部として、当該インストーラファイルのトランザクションＩＤの格納領域３６２０２から、トランザクションＩＤを取得する。なお、トランザクションＩＤはＳ６１０１の属性値取得ステップで予め取得しておいても構わない。上記Ｓ６２０１でエラー情報を収集したのち、インストーラ６０００は、Ｓ３７３０１に処理を進める。

Ｓ３７３０１では、インストーラ６０００は、インストーラファイルに埋め込まれた送信対象全デバイス属性値格納用データ領域３６１０１から、アップロード送信時に送信対象とされたデバイスの各ネットワークアドレスを取得する。上述の例では、デバイス１０２ａ、１０２ｂ、１０２ｃのぞれぞれのネットワークアドレスを取得する。

次に、Ｓ３７３０２において、インストーラ６０００は、以下のＳ６２０２の処理を、上記Ｓ３７３０１でネットワークアドレスを取得した全ての送信対象デバイスに対して順番に実行し、全ての送信対象デバイスに対して処理が完了するまでループするように制御する。すなわち、上述の例では、Ｓ６２０２の処理を、デバイス１０２ａ、１０２ｂ、１０２ｃに対して返して実行する（３回ループする）。

Ｓ６２０２では、インストーラ６０００は、現在送信対象となっているデバイス（例えばデバイス１０２ａ）に対して、上記Ｓ６２０１で収集したエラー情報を送信する。なお、ここで送信するエラー情報には、上記Ｓ６１０１で取得したデバイス属性情報が、エラー発生デバイスの情報として含まれているものとする。
そして、全ての送信対象デバイスに対して処理が完了すると（Ｓ３７３０２でループ終了）、インストーラ６０００は、本フローチャートの処理を終了する。

以下、図３（ｂ）に示した管理エージェント５００１内のトランザクションＩＤ管理モジュール５１０４について説明する。
トランザクションＩＤ管理モジュール５１０４は、ファイル管理モジュール５１０１がインストーラファイルを受信するときに、当該ファイルのトランザクションＩＤを取得してストレージ３０８に蓄積する。また、トランザクションＩＤ管理モジュール５１０４は、エラー管理モジュール５１０２がエラー情報を受信したときに、上記蓄積されているトランザクションＩＤの中に、当該エラー情報に含まれるトランザクションＩＤと一致するものがないかチェックする。

以下、図３０を用いて、実施例７のファイル管理モジュール５１０１の処理について説明する。
図３０は、実施例７のファイル管理モジュール５１０１の処理の一例を示すフローチャートである。なお、図中のＳ３９１０１〜Ｓ３９３０２は、ファイル管理モジュール５１０１が実行する各ステップを示す。

まず、ファイル管理モジュール５１０１は、Ｓ３９１０１において、管理装置１０３のファイル管理モジュール４１０１から送られてくるアップロード要求を受信すると、Ｓ３０１９２に処理を進める。

Ｓ３９１０２では、ファイル管理モジュール５１０１は、上記アップロード要求したファイル管理モジュール４１０１に対して、アップロードを開始するよう要求を行う。
次に、Ｓ３９１０３において、ファイル管理モジュール５１０１は、上記ファイル管理モジュール４１０１からアップロードされたインストーラファイルを受信する。
次に、Ｓ３９２０１において、ファイル管理モジュール５１０１は、上記Ｓ３９１０３で受信したインストーラファイルのトランザクションＩＤを格納する格納領域３６２０２から、トランザクションＩＤを取得する。

次に、Ｓ３９２０２において、ファイル管理モジュール５１０１は、上記Ｓ３９２０１で取得したトランザクションＩＤを、トランザクションＩＤ管理モジュール５１０４に引き渡し、ストレージ３０８に蓄積させる。

次に、Ｓ３９３０１において、ファイル管理モジュール５１０１は、当該管理エージェント５００１が動作しているデバイス（例えばデバイス１０２ａ）の現在の属性値（ＩＰアドレス等）を取得する。

そして、Ｓ３９３０２において、ファイル管理モジュール５１０１は、上記Ｓ３９３０１で取得した属性値で、上記Ｓ３９１０３で受信したインストーラファイルの属性値格納用データ領域８００３を書き換え、本フローチャートの処理を終了する。

以下、図３１を参照して、実施例７における管理エージェント５００１のエラー管理モジュール５１０２により行われる処理について説明する。
図３１は、実施例７における管理エージェント５００１のエラー管理モジュール５１０２により実行される処理の一例を示すフローチャートである。なお、図中のＳ７１０１〜Ｓ７２０３、Ｓ４０３０１〜Ｓ４０３０２は、エラー管理モジュール５１０２が実行する各ステップを示す。

まず、エラー管理モジュール５１０２は、Ｓ７１０１において、インストーラ６０００から送信されたエラー情報を受信すると、Ｓ４０３０１に処理を進める。
Ｓ４０３０１では、エラー管理モジュール５１０２は、上記Ｓ７１０１で受信したエラー情報に含まれているトランザクションＩＤを、トランザクションＩＤ管理モジュール５１０４に引き渡す。トランザクションＩＤ管理モジュール５１０４は、自身で蓄積したトランザクションＩＤの中に、上記引き渡されたトランザクションＩＤと一致するもの検出し、検出結果をエラー管理モジュール５１０２に返す。

そして、上記Ｓ７１０１で受信したエラー情報に含まれているトランザクションＩＤと一致するものが、トランザクションＩＤ管理モジュール５１０４に蓄積されていないと判定した場合（一致不検出）、エラー管理モジュール５１０２は、そのまま本フローチャートの処理を終了する。この場合、受け取ったエラー情報は、当該デバイス（例えばデバイス１０２ａ）の管理エージェント５００１ではアップロードされたことのないインストーラファイルに関するものであるので、これ以上の処理は行わずここで終了する。

一方、上記Ｓ７１０１で受信したエラー情報に含まれているトランザクションＩＤと一致するものが、トランザクションＩＤ管理モジュール５１０４に蓄積されているものから検出されたと判定した場合（一致検出）、エラー管理モジュール５１０２は、Ｓ７１０２に処理を進める。

Ｓ７１０２では、エラー管理モジュール５１０２は、上記Ｓ７１０１で受信したエラー情報を解析する。
次に、Ｓ４０３０２において、エラー管理モジュール５１０２は、上記Ｓ７１０１で受信したエラー情報を引き起こしたダウンロードファイルのダウンロード元のデバイス（エラー発生デバイス）を識別する。

そして、エラー発生デバイスが、現在この管理エージェント５００１が動作しているデバイス（自デバイス、例えばデバイス１０２ａ）であると判定した場合（Ｓ４３０２で「自デバイス」の場合）、エラー管理モジュール５１０２は、Ｓ７１０３に処理を進める。

一方、エラー発生デバイスが、現在この管理エージェント５００１が動作しているデバイスとは異なるデバイスであると判定した場合（Ｓ４３０２で「他デバイス」の場合）、エラー管理モジュール５１０２は、Ｓ７２０１に処理を進める。以降の処理の説明は図５に示したものと同一であるので省略する。

以上示したように、実施例７によれば、インストーラは、エラーを発生した場合に以下のような動作を行う。すなわち、インストーラは、自身に埋め込まれた送信対象全デバイスに対してトランザクションＩＤを含むエラー情報を送信する。当該エラー情報を受信した管理エージェント５００１は当該トランザクションＩＤが自身の保持しているインストーラファイルのものと一致する場合には、そのエラー情報を解析する。解析した結果としてダウンロードを停止すべきと判断した場合にはダウンロードを停止する。

以下、図３２を用いて、実施例７の全体の処理の流れを説明する。
図３２は、実施例７の全体の処理の流れを模式的に示す図である。なお、図中のＳ１２００１〜Ｓ１２００９、Ｓ１９００１〜Ｓ１９００５、Ｓ３３００１〜Ｓ３３００５は、管理装置１０３、デバイス１０２ａ、デバイス１０２ｂ、クライアント装置１０４のいずれかが実行するステップを示す。また、Ｓ１２００１〜Ｓ１２００９の各処理、及びＳ１９００１〜Ｓ１９００５の各処理は、図２３に示したものと同一であるので説明は省略する。

なお、実施例７では、Ｓ１２００１において、デバイス１０２ａにインストーラソフトウェア実行ファイルをアップロードする際に、同時に別のデバイス１０２ｂにもアップロードが行われている。ここでは、別のデバイスとして、デバイス１０２ｂについてのみ図示しているが、デバイスがさらに複数存在していても同様である。

デバイス１０２ｂ上にも、管理エージェント５００１が存在しており、アップロードを受けると、デバイス１０２ａのＳ１２００２と同様に、デバイス１０２ｂの管理エージェント５００１は、Ｓ３３００２において、属性値書換処理を同様に実行する。

この後、クライアント装置１０４上でエラーが発生した場合（Ｓ１２００５）、クライアント装置１０４のインストーラ６０００は、そのエラー情報を、デバイス１０２ａに送信する（Ｓ１２００６）が、同時にデバイス１０２ｂにも送信する（Ｓ３３００３）。

これは、管理装置１０３が、上記Ｓ３３００１でアップロードを行う際に、インストーラファイル内の領域（図２８の３６１０１）に対して、一括アップロードの対象となった各デバイスの情報を両方埋め込んでいるために可能になっている。

デバイス１０２ｂ上の管理エージェント５００１は、エラー情報を受け取った後、デバイス１０２ａ上の管理エージェント５００１のＳ１２００７と同様に、エラー情報を解析する（Ｓ３３００４）。さらに、デバイス１０２ｂ上の管理エージェント５００１は、デバイス１０２ａ上の管理エージェント５００１のＳ１２００９と同様に、必要であればダウンロードを停止する（Ｓ３３００５）。

以上示したように、実施例７によれば、まだエラーが発生していないデバイス上の管理エージェント５００１も他のデバイスで同一のインストーラソフトウェア実行ファイルが壊れていることを容易に知ることができるようになる。これにより、実施例６の効果に加え、実際にエラーの発生したデバイス（例えば１０２ａ）以外のデバイス（例えば１０２ｂや１０２ｃ）で新たに同様のエラーが発生することを防止することが可能となる。本実施例のシステムは、これらの利点の結果として管理者の負担をさらに軽減することが可能となる。

なお、本実施例で扱うデバイスドライバとは、デバイス１０２の機能を利用するためのデバイスドライバであればどのような種類のデバイスドライバであってもよい。一例を示すと、プリンタドライバ、スキャナドライバ、ファックスドライバ等が、上記デバイスドライバに該当する。

以上示したように、本発明の管理システムは、インストーラが一般ユーザのクライアント装置にてインストールを実行しようとしてエラーになった場合に、そのエラーの発生通知と内容を受け取ることができる。また、本発明の管理システムは、そのエラーの発生通知を管理者に転送し、管理者に対してエラーの発生を通知することができる。さらに、本発明の管理システムは、そのエラーの内容を解析して原因を検知することができ、その原因がそのインストーラソフトウェア自身にあることが分かった場合には、そのインストーラソフトウェアのダウンロードを停止することができる。

これにより、本発明の管理システムは、管理者がデバイスにアップロードし、一般ユーザがダウンロードして実行するインストーラソフトウェアについて、以下のような効果を奏する。すなわち、そのインストーラソフトウェアが、それ自身が原因でエラーを発生することが分かったときに、そのことを管理者に通知して注意を喚起することができる。また、同時に他の一般ユーザがそのインストーラをダウンロードおよび実行して、再度同じエラーを発生させることを防止することができる。これらの結果として、本発明の管理システムは、エラーの発生を低減し、管理者の管理にかかる手間を大幅に軽減することができる。

従って、本発明によれば、画像形成装置から配信したインストーラの実行により情報処理装置でエラーが発生したことを画像形成装置側で把握可能となり、同一のインストーラを配信した他の情報処理装置で同じエラーが発生することを抑えることができ、管理者の管理にかかる手間（負荷）を大幅に軽減することができる。

なお、上述した各種データの構成及びその内容はこれに限定されるものではなく、用途や目的に応じて、様々な構成や内容で構成されることは言うまでもない。
以上、一実施形態について示したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記憶媒体等としての実施態様をとることが可能である。具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。
また、上記各実施例を組み合わせた構成も全て本発明に含まれるものである。

（他の実施例）
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。

また、本発明は、複数の機器から構成されるシステムに適用しても、１つの機器からなる装置に適用してもよい。
本発明は上記実施例に限定されるものではなく、本発明の趣旨に基づき種々の変形（各実施例の有機的な組合せを含む）が可能であり、それらを本発明の範囲から除外するものではない。即ち、上述した各実施例及びその変形例を組み合わせた構成も全て本発明に含まれるものである。

Claims (13)

1. 画像形成装置であって、
   識別情報が埋め込まれたデバイスドライバのインストーラを保持する保持手段と、
   情報処理装置からの要求に応じて、前記保持手段に保持しているインストーラを、前記情報処理装置に配信する配信手段と、
   前記配信手段で前記インストーラを配信した前記情報処理装置から、前記インストーラに埋め込まれた識別情報を含む、前記インストーラの実行でエラーが発生したことを示すエラー情報を、受信する受信手段と、
   を有することを特徴とする画像形成装置。
2. 前記インストーラに埋め込まれた識別情報と、当該インストーラが配信される前記情報処理装置のユーザ情報と、を対応付けて蓄積する蓄積手段と、
   前記受信手段が受信したエラー情報に含まれる識別情報に対応付けて蓄積されているユーザ情報に基づき、前記インストーラの実行でエラーが発生したことを示す警告を行う警告手段と、をさらに有することを特徴とする請求項１に記載の画像形成装置。
3. 前記蓄積手段は、前記情報処理装置からの要求に含まれるユーザ情報と、当該要求の対象となるインストーラに埋め込まれた識別情報とを対応付けて蓄積することを特徴とする請求項２に記載の画像形成装置。
4. 前記情報処理装置に対して、前記インストーラの要求を行うためのダウンロードページのアドレス情報を含む電子メールを送信する送信手段と、
   前記ダウンロードページを用いて前記インストーラの要求が行われた後に、前記受信手段が前記エラー情報を受信した場合に、当該エラー情報に含まれる前記アドレス情報に埋め込まれていたユーザ情報に基づき、前記インストーラの実行でエラーが発生したことを示す警告を行う警告手段と、をさらに有することを特徴とする請求項１に記載の画像形成装置。
5. 前記警告手段は、前記警告として、宛先に前記ユーザ情報により特定されるメールアドレスが設定された電子メールを送信することを特徴とする請求項２乃至４のいずれか１項に記載の画像形成装置。
6. 前記保持手段に保持されるインストーラには、前記画像形成装置の特定情報と、前記画像形成装置と同一のトランザクションにて前記インストーラがアップロードされた他の画像形成装置の特定情報とが埋め込まれ、
   前記情報処理装置は、前記エラー情報を前記インストーラに埋め込まれた特定情報で特定される前記画像形成装置及び他の画像形成装置に対してエラー情報を送信し、
   前記受信手段は、前記情報処理装置から送信された当該エラー情報を受信することを特徴とする請求項１乃至５のいずれか１項に記載の画像形成装置。
7. 前記配信手段は、前記受信手段がエラー情報を受信した場合、該エラー情報に含まれる識別情報に対応するインストーラの配信を停止することを特徴とする請求項１乃至６のいずれか１項に記載の画像形成装置。
8. 前記配信手段は、前記受信手段が受信したエラー情報に基づき、エラーの原因がインストーラにあると判定した場合には、前記エラー情報に含まれる識別情報に対応するインストーラの配信を停止することを特徴とする請求項７に記載の画像形成装置。
9. インストーラの配信を停止する場合の条件を記憶する記憶手段をさらに有し、
   前記配信手段は、前記エラーの原因がインストーラにあると判定できない場合で、前記エラー情報が前記記憶手段に記憶される条件に合致した場合に、前記エラー情報に含まれる識別情報に対応するインストーラの配信を停止することを特徴とする請求項８に記載の画像形成装置。
10. 管理装置に対して、前記受信手段が受信したエラー情報に含まれる識別情報を含む通知を行う通知手段をさらに有することを特徴とする請求項１乃至９のいずれか１項に記載の画像形成装置。
11. 画像形成装置と情報処理装置を有するシステムであって、
    前記画像形成装置は、
    識別情報が埋め込まれたデバイスドライバのインストーラを保持する保持手段と、
    情報処理装置からの要求に応じて、前記保持手段に保持しているインストーラを、前記情報処理装置に配信する配信手段と、
    前記配信手段で前記インストーラを配信した前記情報処理装置から、前記インストーラに埋め込まれた識別情報を含む、前記インストーラの実行でエラーが発生したことを示すエラー情報を、受信する受信手段とを有するものであり、
    前記情報処理装置は、
    前記画像形成装置に要求して、前記画像形成装置に保持される識別情報が埋め込まれたデバイスドライバのインストーラを、前記画像形成装置から受信するダウンロード手段と、
    前記ダウンロード手段がダウンロードした前記インストーラに従い、前記画像形成装置のデバイスドライバの前記情報処理装置へのインストール処理を実行する実行手段と、
    前記インストール処理の実行でエラーが発生した場合、前記インストーラに埋め込まれた識別情報を含む、前記エラーが発生したことを示すエラー情報を、前記画像形成装置に送信する送信手段とを有する、
    ことを特徴とするシステム。
12. 識別情報が埋め込まれたデバイスドライバのインストーラを保持する保持手段を有する画像形成装置の制御方法であって、
    情報処理装置からの要求に応じて、前記保持手段に保持しているインストーラを、前記情報処理装置に配信する配信工程と、
    前記配信工程で前記インストーラを配信した前記情報処理装置から、前記インストーラに埋め込まれた識別情報を含む、前記インストーラの実行でエラーが発生したことを示すエラー情報を、受信する受信工程と、
    を有することを特徴とする制御方法。
13. コンピュータを、請求項１乃至１０のいずれか１項に記載された手段として機能させるためのプログラム。

Images