(57)【要約】【課題】ネットワークを介して更新機能を取得するインストール処理において、不要な機能更新を回避し、システム運用を効率化すること。【解決手段】ネットワークを介して更新機能を取得するインストール処理方法であって、更新可能な機能に関する情報をネットワークを介して取得し、前記更新可能な機能に対応する機能の動作に関する情報を取得し、前記動作に関する情報に基づいて前記更新可能な機能のインストールを決定し、前記インストールの決定に応じて前記更新可能な機能をインストールするためのインストール情報を取得し、前記取得したインストール情報に基づいて前記更新可能な機能をインストールすることを特徴とする。【選択図】図５
2009093267.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを介して更新機能を取得するインストール処理方法であって、
更新可能な機能に関する情報をネットワークを介して取得し、
前記更新可能な機能に対応する機能の動作に関する情報を取得し、
前記動作に関する情報に基づいて前記更新可能な機能のインストールを決定し、
前記インストールの決定に応じて前記更新可能な機能をインストールするためのインストール情報を取得し、
前記取得したインストール情報に基づいて前記更新可能な機能をインストールすることを特徴とする、インストール処理方法。
【請求項２】
前記動作に関する情報は、前記更新可能な機能に対応する機能の動作履歴に関する情報であり、
前記更新可能な機能の動作履歴がある場合に当該更新可能な機能のインストールを決定することを特徴とする、請求項１に記載のインストール処理方法。
【請求項３】
前記動作に関する情報は、前記更新可能な機能に対応する機能の動作の実行可能性に関する情報であり、
前記更新可能な機能の動作実行可能性がある場合に当該更新可能な機能のインストールを決定することを特徴とする、請求項１に記載のインストール処理方法。
【請求項４】
前記動作の実行に関する情報は、前記更新可能な機能の障害発生に関する情報であり、
前記更新可能な機能の障害発生が確認された場合に当該更新可能な機能のインストールを決定することを特徴とする、請求項１に記載のインストール処理方法。
【請求項５】
前記更新可能な機能に障害が発生したことをユーザに通知し、
ユーザが前記更新可能な機能のインストールの決定を指示する指示手段を構成し、
前記指示手段からの指示に応じて前記更新可能な機能のインストールを決定することを特徴とする、請求項４に記載のインストール処理方法。
【請求項６】
前記動作の実行に関する情報は、前記更新可能な機能の障害発生履歴に関する情報であり、
前記更新可能な機能に障害発生履歴がある場合に当該更新された機能のインストールを決定することを特徴とする、請求項１に記載のインストール処理方法。
【請求項７】
前記動作の実行に関する情報は、前記更新可能な機能の障害発生の可能性に関する情報であり、
前記更新可能な機能に障害発生の可能性がある場合に当該更新された機能のインストールを決定することを特徴とする、請求項１に記載のインストール処理方法。
【請求項８】
前記インストール処理方法を適用する装置の起動に応じて、前記インストールの決定処理を実行することを特徴とする、請求項２乃至７いずれか１項に記載のインストール処理方法。
【請求項９】
前記インストール処理方法を適用する装置の起動に応じて、前記インストール情報を取得することを特徴とする、請求項２乃至８いずれか１項に記載のインストール処理方法。
【請求項１０】
前記インストール処理方法を適用する装置の起動に応じて、前記更新可能な機能をインストールすることを特徴とする、請求項２乃至９いずれか１項に記載のインストール処理方法。
【請求項１１】
前記更新可能な機能に対応する機能の動作に応じて、前記インストールの決定処理を実行することを特徴とする、請求項２乃至１０いずれか１項に記載のインストール処理方法。
【請求項１２】
前記更新可能な機能に対応する機能の動作に応じて、前記インストール情報を取得することを特徴とする、請求項２乃至１１いずれか１項に記載のインストール処理方法。
【請求項１３】
前記更新可能な機能に対応する機能の動作に応じて、前記更新可能な機能をインストールすることを特徴とする、請求項２乃至１２いずれか１項に記載のインストール処理方法。
【請求項１４】
前記更新可能な機能に対応する機能の動作完了に応じて、前記インストールの決定処理を実行することを特徴とする、請求項２乃至１３いずれか１項に記載のインストール処理方法。
【請求項１５】
前記更新可能な機能に対応する機能の動作完了に応じて、前記インストール情報を取得することを特徴とする、請求項２乃至１４いずれか１項に記載のインストール処理方法。
【請求項１６】
前記更新可能な機能に対応する機能の動作完了に応じて、前記更新可能な機能をインストールすることを特徴とする、請求項２乃至１５いずれか１項に記載のインストール処理方法。
【請求項１７】
前記インストール処理方法を適用する装置の動作終了に応じて、前記インストールの決定処理を実行することを特徴とする、請求項２乃至１６いずれか１項に記載のインストール処理方法。
【請求項１８】
前記インストール処理方法を適用する装置の動作終了に応じて、前記インストール情報を取得することを特徴とする、請求項２乃至１７いずれか１項に記載のインストール処理方法。
【請求項１９】
前記インストール処理方法を適用する装置の動作終了に応じて、前記更新可能な機能をインストールすることを特徴とする、請求項２乃至１８いずれか１項に記載のインストール処理方法。
【請求項２０】
請求項２乃至１９いずれか１項に記載のインストール処理方法をインストール処理装置に実行させることを特徴とする、インストール処理プログラム。
【請求項２１】
請求項２０に記載のインストール処理プログラムをインストール処理装置が読み取り可能な形式で記録したことを特徴とする、記録媒体。
【請求項２２】
請求項２０に記載のプログラムを搭載したインストール処理装置。
【請求項２３】
前記更新可能な機能に関する情報及び前記更新可能な機能をインストールするためのインストール情報のうち、少なくとも一方の情報が格納された情報格納端末と、
請求項２２に記載のインストール処理装置とを含み構成されたインストール処理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークを利用したバージョンアップインストールの自動化システムに関し、特にネットワークの負荷軽減技術に関する。
【背景技術】
【０００２】
従来より、例えば、特開特許文献１にても開示されているように、クライアント端末装置（クライアントＰＣ）のユーザのログオンによってインストーラ制御プログラムをダウンロードして、その制御プログラムがインストーラを制御してインストールするような、インストール処理システムがひろく知られている。
【０００３】
また、既にインストールされているプログラムに対して、随時ネットワークを介してのバージョンアップインストールサービスが提供される、バージョンアップインストールの自動化に関して、現在、様々な発明がされている。特許文献２は、必要な機能のみをインストールする発明である。但し、この発明は、インストールに必要な情報をクライアントからサーバに送るということ、必要な機能は使用している機能ではなく実行を許可されている機能であること、必要な機能の差分のみインストールする点で本発明とはことなる。
【０００４】
その他、アプリケーションソフトウェアの更新処理に関連するものに、特許文献３の発明がある。この発明では、ソフトウェアの起動回数等の更新条件を満足するソフトウェアのみ選択的に、しかも自動的に更新される。これによりユーザは面倒なソフトウェア更新の取捨選択作業から解放されるとされる。
【特許文献１】特開２００５−２５４７７号公報
【特許文献２】特許３８０１５２４号公報
【特許文献３】特開２００４−３５５５６３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
この種装置は、各ユーザのログオンが同じ時間帯で一斉にログオンすることが多い。そのため、特許文献１のインストール処理システムのような形態のものでは、例えばユーザのログオンによってインストーラ制御プログラムをダウンロードしてこの制御プログラムがインストーラを制御してインストールするケース等、業務開始時などの特定の時間帯にインストーラのダウンロード処理が集中してネットワークに負荷がかかるという問題点がある。また、例えば、使用していない機能部分の更新など、ユーザのアプリケーションの使用状況によっては不必要な更新も一律に行われてしまい一定のインストール処理時間がかかり業務に影響を及ぼす可能性があり不都合である。
【０００６】
本発明は、上述した実情を考慮してなされたもので、インストールの時間的集中を防止してネットワークの負荷が軽減でき、また、ユーザ毎に当該ユーザにとって不必要なバージョンアップを避ける（保留する）ことができ業務効率化に寄与するインストーラ制御技術を新たに提案する。
【課題を解決するための手段】
【０００７】
上記の課題を解決するために、請求項１に記載の発明は、ネットワークを介して更新機能を取得するインストール処理方法であって、更新可能な機能に関する情報をネットワークを介して取得し、前記更新可能な機能に対応する機能の動作に関する情報を取得し、前記動作に関する情報に基づいて前記更新可能な機能のインストールを決定し、前記インストールの決定に応じて前記更新可能な機能をインストールするためのインストール情報を取得し、前記取得したインストール情報に基づいて前記更新可能な機能をインストールすることを特徴とする。
【０００８】
また、請求項２に記載の発明は、請求項１に記載のインストール処理方法において、前記動作に関する情報は、前記更新可能な機能に対応する機能の動作履歴に関する情報であり、前記更新可能な機能の動作履歴がある場合に当該更新可能な機能のインストールを決定することを特徴とする。
【０００９】
また、請求項３に記載の発明は、請求項１に記載のインストール処理方法において、前記動作に関する情報は、前記更新可能な機能に対応する機能の動作の実行可能性に関する情報であり、前記更新可能な機能の動作実行可能性がある場合に当該更新可能な機能のインストールを決定することを特徴とする。
【００１０】
また、請求項４に記載の発明は、請求項１に記載のインストール処理方法において、前記動作の実行に関する情報は、前記更新可能な機能の障害発生に関する情報であり、前記更新可能な機能の障害発生が確認された場合に当該更新可能な機能のインストールを決定することを特徴とする。
【００１１】
また、請求項５に記載の発明は、請求項４に記載のインストール処理方法において、前記更新可能な機能に障害が発生したことをユーザに通知し、ユーザが前記更新可能な機能のインストールの決定を指示する指示手段を構成し、前記指示手段からの指示に応じて前記更新可能な機能のインストールを決定することを特徴とする。
【００１２】
また、請求項６に記載の発明は、請求項１に記載のインストール処理方法において、前記動作の実行に関する情報は、前記更新可能な機能の障害発生履歴に関する情報であり、前記更新可能な機能に障害発生履歴がある場合に当該更新された機能のインストールを決定することを特徴とする。
【００１３】
また、請求項７に記載の発明は、請求項１に記載のインストール処理方法において、前記動作の実行に関する情報は、前記更新可能な機能の障害発生の可能性に関する情報であり、前記更新可能な機能に障害発生の可能性がある場合に当該更新された機能のインストールを決定することを特徴とする。
【００１４】
また、請求項８に記載の発明は、請求項２乃至７いずれか１項に記載のインストール処理方法において、前記インストール処理方法を適用する装置の起動に応じて、前記インストールの決定処理を実行することを特徴とする。
【００１５】
また、請求項９に記載の発明は、請求項２乃至８いずれか１項に記載のインストール処理方法において、前記インストール処理方法を適用する装置の起動に応じて、前記インストール情報を取得することを特徴とする。
【００１６】
また、請求項１０に記載の発明は、請求項２乃至９いずれか１項に記載のインストール処理方法において、前記インストール処理方法を適用する装置の起動に応じて、前記更新可能な機能をインストールすることを特徴とする。
【００１７】
また、請求項１１に記載の発明は、請求項２乃至１０いずれか１項に記載のインストール処理方法において、前記更新可能な機能に対応する機能の動作に応じて、前記インストールの決定処理を実行することを特徴とする。
【００１８】
また、請求項１２に記載の発明は、請求項２乃至１１いずれか１項に記載のインストール処理方法において、前記更新可能な機能に対応する機能の動作に応じて、前記インストール情報を取得することを特徴とする。
【００１９】
また、請求項１３に記載の発明は、請求項２乃至１２いずれか１項に記載のインストール処理方法において、前記更新可能な機能に対応する機能の動作に応じて、前記更新可能な機能をインストールすることを特徴とする。
【００２０】
また、請求項１４に記載の発明は、請求項２乃至１３いずれか１項に記載のインストール処理方法において、前記更新可能な機能に対応する機能の動作完了に応じて、前記インストールの決定処理を実行することを特徴とする。
【００２１】
また、請求項１５に記載の発明は、請求項２乃至１４いずれか１項に記載のインストール処理方法において、前記更新可能な機能に対応する機能の動作完了に応じて、前記インストール情報を取得することを特徴とする。
【００２２】
また、請求項１６に記載の発明は、請求項２乃至１５いずれか１項に記載のインストール処理方法において、前記更新可能な機能に対応する機能の動作完了に応じて、前記更新可能な機能をインストールすることを特徴とする。
【００２３】
また、請求項１７に記載の発明は、請求項２乃至１６いずれか１項に記載のインストール処理方法において、前記インストール処理方法を適用する装置の動作終了に応じて、前記インストールの決定処理を実行することを特徴とする。
【００２４】
また、請求項１８に記載の発明は、請求項２乃至１７いずれか１項に記載のインストール処理方法において、前記インストール処理方法を適用する装置の動作終了に応じて、前記インストール情報を取得することを特徴とする。
【００２５】
また、請求項１９に記載の発明は、請求項２乃至１８いずれか１項に記載のインストール処理方法において、前記インストール処理方法を適用する装置の動作終了に応じて、前記更新可能な機能をインストールすることを特徴とする。
【００２６】
また、請求項２０に記載の発明は、インストール処理プログラムであって、請求項２乃至１９いずれか１項に記載のインストール処理方法をインストール処理装置に実行させることを特徴とする。
【００２７】
また、請求項２１に記載の発明は、記録媒体であって、請求項２０に記載のインストール処理プログラムをインストール処理装置が読み取り可能な形式で記録したことを特徴とする。
【００２８】
また、請求項２２に記載の発明は、インストール処理装置であって、請求項２０に記載のプログラムを搭載したことを特徴とする。
【００２９】
また、請求項２３に記載の発明は、インストール処理システムであって、前記更新可能な機能に関する情報及び前記更新可能な機能をインストールするためのインストール情報のうち、少なくとも一方の情報が格納された情報格納端末と、請求項２２に記載のインストール処理装置とを含み構成されたことを特徴とする。
【発明の効果】
【００３０】
請求項１、２の本発明によれば、インストールするユーザ（クライアント端末装置）が限定されるため、ダウンロード総数が減り、ネットワーク負荷を軽減する効果が得られる。また、バージョンアップの必要性があるユーザあるいはクライアント端末装置のみインストールを行うので、無駄なインストール時間が減り、業務の効率化が期待できる。
【００３１】
また、請求項３の本発明によれば、いままでに実行したことはなく、初めて該当する機能を実行する場合でも、当該機能を最新の更新された状態で実行することができる。
【００３２】
また、請求項４の本発明によれば、実際に発生したエラーに関する機能のバージョンアップを行うため、ネットワーク負荷の軽減、及び、無駄なインストール時間の更なる軽減が可能となる。
【００３３】
請求項５の本発明によれば、いままでに発生したことはなく、初めて該当エラーが発生した場合でも、更新されたエラー対応処理が行われる。また、請求項５の発明によれば利用者の指示がある場合にインストール処理を行うので、エラーが発生する毎にインストール制御プログラムによる処理が行われる不都合を避けることができ、必要なときだけインストールの要否を判断してインストール処理より効果的にインストール処理実行の分散が行われ、ネットワークの負荷軽減効果が高まる。
【００３４】
更に、請求項８〜１９の発明によれば、それぞれのユーザが同時に実行することはないと期待できる、アプリケーションの起動時や機能実行時にインストール処理を行うことによって、インストール処理実行の一層の分散が図れてネットワークの負荷軽減効果が高まる。また、機能終了時やアプリケーション時やログオフ時にこれらのインストール処理を行うようにすることで、業務を妨げずにより効率的なインストール処理が行えることが期待できる。
【発明を実施するための最良の形態】
【００３５】
〔第１実施形態〕
以下、図面を参照して、本発明の実施形態を詳細に説明する。図１は、本発明が適用されたネットワークシステムのシステム構成図である。この実施形態システムは、ＬＡＮ（Local Area Network）などのネットワーク５００で接続された、ドメインコントローラ200、ファイルサーバ３００、複数台のクライアント端末装置１００（１００ａ，１００ｂ；以下、クライアントＰＣと言う）からなる。
【００３６】
Microsoft Windows（登録商標）ＯＳによるネットワーク環境において、ドメインコントローラ２００は、ユーザやセキュリティに関する情報を管理し、ユーザ認証を行うサーバである。また、ファイルサーバ３００とは、自身の管理している記憶装置をネットワーク上の他のコンピュータと共有し、外部から利用できるようにするサーバである。クライアントＰＣ：１００はユーザが日常業務において利用しているパーソナルコンピュータ等の端末のことである。
【００３７】
本実施形態では、ログインスクリプトという仕組みを利用している。ログインスクリプトとはユーザのログイン時に実行されるスクリプトであり、システムを使うために必要な各種設定を行ったり、ユーザごとのカスタマイズを行うことができる。Microsoft Windows（登録商標）ＯＳによるドメイン環境では、ユーザはクライアントＰＣを利用するとき、ユーザ名、パスワードなどの認証情報を入力する。この情報はドメインコントローラに送られ、正しいユーザ名、パスワードであればシステムへのログインが許可され、ユーザはシステム上のサービスを利用することができるようになる。このログイン処理においてログインスクリプトが動作するようにドメインコントローラ２００にログインスクリプトを設定することができる。
【００３８】
図２は本実施形態の、［クライアントＰＣ；１００］と［ドメインコントローラ；２００］および［ファイルサーバ；３００］それぞれの本発明関連要部を示したブロック図である。各ネットワーク装置における図示要素について説明する。
【００３９】
［クライアントＰＣ］
・アプリケーション４００：インストールされている応用プログラム並びにＯＳの提供プログラム
・インストーラ３１０：更新可能な機能を更新するためのインストール情報であり、ファイルサーバよりダウンロードされる。
・バージョン情報管理部１１１：インストールされているアプリケーションのバージョンを管理する。
・実行モジュール４０１：アプリケーションの実行モジュール。エラーが発生した場合、アラートを表示したり、エラー情報処理部にエラー情報を通知したりする。また、機能が実行した情報を実行機能処理部に通知する。
・エラー情報処理部４０２：実行モジュールより通知されたエラー情報をエラー情報管理部に渡す。
・エラー情報管理部１１３：エラー情報処理部より渡されたエラー情報を記録、管理する。
・実行機能情報処理部４０３：実行モジュールより通知された機能情報を実行機能情報管理部に渡す。
・実行機能情報管理部１１２：実行機能情報処理部より渡された機能情報、すなわち実行された機能情報を記録、管理する。
・インストール制御プログラム２１０：インストール要否を判定し、インストール処理を実行する。ドメインコントローラからダウンロードされる。
【００４０】
[ドメインコントローラ]
・インストール制御プログラム２１０：インストール要否を判定し、インストール処理を実行する。ログインスクリプトに設置することにより、ユーザがログインしたクライアントＰＣ上にダウンロードされる仕組みとなっている。
［ファイルサーバ］
・インストーラ３１０：ソフトウェアのインストールパッケージ
・インストーラ更新情報３１１：インストーラの更新情報が記述されているファイル
・バージョン情報３１２：インストーラのバージョンが記述されているファイル
【００４１】
図３に本実施形態のインストール制御プログラム２１０に関する詳細ブロック図を示す。
・インストール制御部２１１：インストールの起動やインストールの監視を行う。
・インストール要否判定部２１２：クライアントＰＣのエラー情報管理部で管理しているエラー情報、または、実行機能情報管理部で管理している実行機能情報とファイルサーバのインストーラ更新情報管理部で管理している更新情報を利用してインストール要否判定を行う。
・ダウンロード実行判定部２１３：インストール要否判定部での判定結果より、インストーラダウンロード実行を行うかどうかを管理する。
【００４２】
図４は、本実施形態システムにおける各部の動作を示した動作フローで以下の過程からなる。
Ｓ１）クライアントＰＣよりユーザがログインする。
Ｓ２）ログインスクリプトにより、インストール制御プログラム２１０がログインしたクライアントＰＣにダウンロードされる。
Ｓ３）インストール制御プログラム２１０は、ファイルサーバからインストーラ更新情報を取得する。
Ｓ４）インストール制御プログラム２１０は、３で取得したインストーラ更新情報と、クライアントＰＣの実行機能情報管理部より取得した実行機能情報を利用して、普段利用している機能に関して更新があるかどうかを判定する（判定の詳細については後述する）。
Ｓ５）Ｓ４の判定の結果、更新がある場合はダウンロード実行判定部にてダウンロード実行フラグをＯＮにする。
Ｓ６）インストール制御プログラム２１０は、ダウンロード実行フラグがＯＮの場合、ファイルサーバからインストーラ３１０のダウンロードを行う。
Ｓ７）インストール制御プログラム２１０は、インストーラ３１０が正常にダウンロードされた場合、ダウンロードしたインストーラ３１０を起動し、インストールを開始する。
【００４３】
図４の動作について、図５を参照して更に詳細に説明する。尚、図５においては、インストール制御プログラム２１０がドメインコントローラ２００からクライアントＰＣ１００にダウンロードされた後の動作について説明する。クライアントＰＣ１００においてインストール制御プログラム２１０が動作開始すると、インストール制御部２１１は、ファイルサーバ３００からインストーラ更新情報３１１をダウンロードし、取得する（Ｓ５０１）。
【００４４】
ここで、図６を参照して、インストーラ更新情報３１１について説明する。図６に示すように、インストーラ更新情報３１１には、情報分類及びバージョンごとの機能名の情報が含まれる。情報分類とは、インストーラ更新情報３１１が何の情報によって構成されているかを示す情報であり、本実施形態に係るインストーラ更新情報３１１は、更新した機能名を示す情報である。また、バージョンごとの機能名の情報として、“ｆｕｎｃｔｉｏｎＢ”、“ｆｕｎｃｔｉｏｎＣ”は、バージョンが“４”であることを示している。また、“ｆｕｎｃｔｉｏｎＡ”は、バージョンが“３”であることを示している。また、“ｆｕｎｃｔｉｏｎＥ”、“ｆｕｎｃｔｉｏｎＦ”は、バージョンが“２”であることを示している。
【００４５】
また、インストール制御部２１１は、インストーラ更新情報３１１の取得の後、若しくはインストーラ更新情報３１１の取得と並行して、クライアントＰＣ１００内のバージョン情報管理部１１１から、クライアントＰＣ１００に既にインストールされているソフトウェア・アプリケーションのバージョン情報を取得する（Ｓ５０２）。ここで、図７（ａ）、（ｂ）を参照して、クライアントＰＣ１００に既にインストールされているソフトウェア・アプリケーションのバージョン情報について説明する。
【００４６】
図７（ａ）は、クライアントＰＣ１００ａが保持するバージョン情報であり、図７（ｂ）は、クライアントＰＣ１００ｂが保持するバージョン情報である。図７（ａ）、（ｂ）に示すように、クライアントＰＣ１００が保持するバージョン情報には、夫々の機能名及びその機能のバージョン情報が含まれる。図７（ａ）の例においては、例えば、“ｆｕｎｃｔｉｏｎＡ”のバージョンは“３”であることが示されている。また、図７（ｂ）の例においては、例えば、“ｆｕｎｃｔｉｏｎＡ”のバージョンは“２”であることが示されている。
【００４７】
また、インストール制御部２１１は、インストーラ更新情報３１１の取得の後、若しくはインストーラ更新情報３１１の取得と並行して、実行機能情報管理部１１２から、クライアントＰＣ１００において実行されたソフトウェア・アプリケーションの機能情報を取得する（Ｓ５０３）。ここで、図７（ａ）、（ｂ）を参照して、クライアントＰＣ１００の実行機能情報について説明する。図７（ａ）は、クライアントＰＣ１００ａの実行機能情報であり、図７（ｂ）は、クライアントＰＣ１００ｂの実行機能情報である。
【００４８】
図７（ａ）、（ｂ）に示すように、実行機能情報には、夫々の機能が実行された日付及び実行された機能名が含まれる。図７（ａ）の例においては、例えば、クライアントＰＣ１００ａにおいて、“２００６／０８／３０”に“ｆｕｎｃｔｉｏｎＣ”の機能が実行されたことが示されている。また、図７（ｂ）の例においては、例えば、クライアントＰＣ１００ｂにおいて、“２００６／０８／３０”に“ｆｕｎｃｔｉｏｎＦ”の機能が実行されたことが示されている。
【００４９】
Ｓ５０１〜Ｓ５０３夫々の情報取得が完了すると、インストール制御部２１１は、Ｓ５０１、Ｓ５０２、Ｓ５０３において夫々取得した情報をインストール要否判定部２１２に入力する（Ｓ５０４）。インストール要否判定部２１２は、インストール制御部２１１から入力された情報に基づき、インストールの要否を判定する。ここで、図９を参照して、本実施形態に係るインストール要否の判定方法について説明する、図９は、本実施形態に係るインストール要否の判定動作を示すフローチャートである。
【００５０】
図９に示すように、インストール要否判定部２１２は、インストール制御部２１１から情報を取得すると（Ｓ９０１）、図７において説明した“ｆｕｎｃｔｉｏｎＡ”、“ｆｕｎｃｔｉｏｎＢ”等の各機能について、クライアントＰＣ１００にインストールされている機能のバージョンと、インストーラ更新情報のバージョン情報とを比較する（Ｓ９０２）。比較の結果、機能が更新されていれば、即ち、クライアントＰＣ１００にインストールされている機能のバージョンが、インストーラ更新情報のバージョンよりも古ければ（Ｓ９０３／ＹＥＳ）、インストール要否判定部２１２は、図８において説明した実行機能情報を参照し、当該機能が実行されているか否かを確認する（Ｓ９０４）。
【００５１】
Ｓ９０４の確認の結果、該当する機能が実行されている場合（Ｓ９０５／ＹＥＳ）、インストール要否判定部２１２は、当該機能のインストールが必要であると判定する（Ｓ９０６）。他方、Ｓ９０２の比較の結果、機能が更新されていない場合（Ｓ９０３／ＮＯ）や、機能が更新されていても、クライアントＰＣ１００において実行されていない機能である場合（Ｓ９０５／ＮＯ）、インストール要否判定部２１２は、当該機能のインストールが不要であると判定する（Ｓ９０７）。全ての機能についてのインストール要否判定が終了するまで、インストール要否判定部２１２はＳ９０２〜Ｓ９０７の処理を繰り返す（Ｓ９０８／ＮＯ）。全ての機能について判定が終了したら（Ｓ９０８／ＹＥＳ）、インストール要否判定部２１２は、インストール制御部２１１に対して判定結果を送信し（Ｓ９０９）、処理を終了する。
【００５２】
インストール要否判定部によるインストール要否の判定について、図６、図７（ａ）、（ｂ）及び図８（ａ）、（ｂ）を用いて更に具体的に説明する。まず、クライアントＰＣ１００ａについて説明する。図６と図７（ａ）を比較すると（Ｓ９０２）、更新されている機能は、“ｆｕｎｃｔｉｏｎＢ”、“ｆｕｎｃｔｉｏｎＣ”、“ｆｕｎｃｔｉｏｎＥ”、“ｆｕｎｃｔｉｏｎＦ”であることがわかる（Ｓ９０３）。ここで、図８（ａ）を参照すると、“ｆｕｎｃｔｉｏｎＢ”、“ｆｕｎｃｔｉｏｎＣ”は実行されているが、“ｆｕｎｃｔｉｏｎＥ”、“ｆｕｎｃｔｉｏｎＦ”は実行されていない（Ｓ９０５）。従って、クライアントＰＣ１００ａにおいては、“ｆｕｎｃｔｉｏｎＢ”、“ｆｕｎｃｔｉｏｎＣ”がインストール必要として判定され（Ｓ９０６）、その他の機能はインストール不要として判定される（Ｓ９０７）。
【００５３】
次に、クライアントＰＣ１００ｂについて説明する。図６と図７（ｂ）を比較すると（Ｓ９０２）、更新されている機能は、“ｆｕｎｃｔｉｏｎＡ”、“ｆｕｎｃｔｉｏｎＢ”、“ｆｕｎｃｔｉｏｎＣ”であることがわかる（Ｓ９０３）。ここで、図８（ｂ）を参照すると、“ｆｕｎｃｔｉｏｎＡ”は実行されているが、“ｆｕｎｃｔｉｏｎＢ”、“ｆｕｎｃｔｉｏｎＣ”は実行されていない（Ｓ９０５）。従って、クライアントＰＣ１００ｂにおいては、“ｆｕｎｃｔｉｏｎＡ”のみがインストール必要として判定され（Ｓ９０６）、その他の機能はインストール不要として判定される（Ｓ９０７）。
【００５４】
図５に戻り、インストール制御部２１１は、インストール要否判定部２１２から判定結果を受信すると、その判定結果をダウンロード実行判定部２１３に送信する（Ｓ５０６）。判定結果を受信したダウンロード実行判定部２１３は、インストールが必要であると判定された機能について、ダウンロードの実行を決定し、インストール制御部２１１に通知する（Ｓ５０７）。ダウンロード実行の判定結果を受信したインストール制御部２１１は、その判定結果に応じて該当する機能のインストーラ３１０をファイルサーバ３００からダウンロードして取得し（Ｓ５０８）、取得したインストーラを起動して更新機能をインストールする（Ｓ５０９）。
【００５５】
以上説明したように、本実施形態に係るネットワークシステムにおいては、各クライアントＰＣ１００の機能更新の要否を判断する際に、機能更新の有無に加えて、更新された機能が各クライアントＰＣ１００において実行されているか否か、即ち、更新可能な機能の動作履歴に関する情報を参照する。これにより、夫々のクライアントＰＣにおいて不要な機能は更新されないため、クライアントＰＣにおける処理の削減やネットワーク負荷の低減等、システム運用を効率化することが可能となる。
【００５６】
尚、上記の説明においては、更新可能な機能に対応する機能の動作履歴に基づいて、インストールの要否を決定する例を説明した。この他、装置の動作態様に基づいて将来実行され得る機能を予測してもよい。これにより、動作履歴がない機能であっても、将来の動作の実行可能性に基づいて機能の更新を実行することが可能となる。
【００５７】
〔第２実施形態〕
上述実施形態では、クライアントＰＣ：１００にて、これまでに実行された機能情報に着目してインストーラのダウンロードおよびインストールの実行を行っているが、エラー情報を利用する実施形態も考えられる。なお、この形態は、判定と実行する処理（実行機能情報管理部１１２による）のみが前実施形態と異なるもので、その他の共通する点については全て説明を省略する。
【００５８】
本実施形態においては、図４の動作フローの過程；ｓ４）で、実行機能情報管理部が、エラー情報処理部４０２から取得したエラー情報を利用することで、インストーラ３１０のダウンロードおよび実行を行う。本実施形態に係る動作について、図１０を参照して更に詳細に説明する。尚、図１０においても、図５と同様にインストール制御プログラム２１０がドメインコントローラ２００からクライアントＰＣ１００にダウンロードされた後の動作について説明する。図１０に示すように、本実施形態に係る動作は、前実施形態における図５の動作と概ね同様であるため、異なる部分のみ説明する。
【００５９】
まず、本実施形態においては、Ｓ１００１においてインストール制御部２１１がファイルサーバ３００から取得するインストーラ更新情報の内容が、前実施形態と異なる。図１１を参照して、本実施形態に係るインストーラ更新情報３１１について説明する。図１１に示すように、インストーラ更新情報３１１には、情報分類及びバージョンごとのエラーコードの情報が含まれる。本実施形態に係るインストーラ更新情報３１１は、修復したエラーコードの情報であり、情報分類にはその旨が示されている。また、バージョンごとのエラーコードの情報として、“００２”、“００３”のエラーコードに対する修復バージョンは、“４”であることを示している。また、“００１”のエラーコードに対する修復バージョンは、“３”であることを示している。また、“００５”、“００６”のエラーコードに対する修復バージョンは、“２”であることを示している。
【００６０】
図１０に戻り、本実施形態に係る動作が前実施形態と異なる他の点として、インストール制御部２１１がＳ１００２において取得するバージョン情報の内容が異なる。ここで、図１２（ａ）、（ｂ）を参照して、クライアントＰＣ１００のエラー情報について説明する。図１２（ａ）は、クライアントＰＣ１００ａのエラー情報であり、図１２（ｂ）は、クライアントＰＣ１００ｂのエラー情報である。図１２（ａ）、（ｂ）に示すように、クライアントＰＣ１００が保持するバージョン情報には、夫々のエラーコード及びそのエラーコードの修復バージョン情報が含まれる。図１２（ａ）の例においては、例えば、エラーコード“００１”の修復バージョンは“３”であることが示されている。また、図１２（ｂ）の例においては、例えば、エラーコード“００１”のバージョンは“２”であることが示されている。
【００６１】
図１０に戻り、本実施形態に係る動作が前実施形態と異なる他の点として、インストール制御部２１１は、前実施形態のＳ５０３の処理に代えて、エラー情報管理部１１３にアクセスし、エラー情報を取得する（Ｓ１００３）。ここで、図１３（ａ）、（ｂ）を参照して、クライアントＰＣ１００のエラー情報について説明する。図１３（ａ）は、クライアントＰＣ１００ａのエラー情報であり、図１３（ｂ）は、クライアントＰＣ１００ｂのエラー情報である。
【００６２】
図１３（ａ）、（ｂ）に示すように、エラー情報には、夫々の機能が実行された日付及び実行された機能名が含まれる。図１３（ａ）の例においては、例えば、クライアントＰＣ１００ａにおいて、“２００６／０８／３０”にエラーコード“００３”のエラーが発生したことが示されている。また、図１３（ｂ）の例においては、例えば、クライアントＰＣ１００ｂにおいて、“２００６／０８／３０”にエラーコード“００６”のエラーが発生したことが示されている。
【００６３】
図１０に戻り、本実施形態に係る動作が前実施形態と更に異なる点として、Ｓ１００５におけるインストール要否判定処理が異なる。ここで、図１４を参照して、本実施形態に係るインストール要否の判定方法について説明する。インストール要否判定部２１２は、インストール制御部２１１から情報を取得すると（Ｓ１４０１）、図１２において説明したエラーコード“００１”、“００２”等の各エラーコードについて、クライアントＰＣ１００にインストールされている修復バージョンと、インストーラ更新情報の修復バージョン情報とを比較する（Ｓ１４０２）。比較の結果、修復機能が更新されていれば、即ち、クライアントＰＣ１００にインストールされている修復バージョンが、インストーラ更新情報の修復バージョンよりも古ければ（Ｓ１４０３／ＹＥＳ）、インストール要否判定部２１２は、図１３において説明したエラー情報を参照し、当該エラーが発生しているか否かを確認する（Ｓ１４０４）。
【００６４】
Ｓ１４０４の確認の結果、該当するエラーが発生している場合（Ｓ１４０５／ＹＥＳ）、インストール要否判定部２１２は、当該エラーに対応する修復機能のインストールが必要であると判定する（Ｓ１４０６）。他方、Ｓ１４０２の比較の結果、機能が更新されていない場合（Ｓ１４０３／ＮＯ）や、機能が更新されていても、クライアントＰＣ１００においてエラーが発生していない場合（Ｓ１４０５／ＮＯ）、インストール要否判定部２１２は、当該機能のインストールが不要であると判定する（Ｓ１４０７）。全てのエラーコードについてのインストール要否判定が終了するまで、インストール要否判定部２１２はＳ１４０２〜Ｓ１４０７の処理を繰り返す（Ｓ１４０８／ＮＯ）。全てのエラーコードについて判定が終了したら（Ｓ１４０８／ＹＥＳ）、インストール要否判定部２１２は、インストール制御部２１１に対して判定結果を送信し（Ｓ１４０９）、処理を終了する。
【００６５】
インストール要否判定部によるインストール要否の判定について、図１１、図１２（ａ）、（ｂ）及び図１３（ａ）、（ｂ）を用いて更に具体的に説明する。まず、クライアントＰＣ１００ａについて説明する。図１１と図１２（ａ）を比較すると（Ｓ１４０２）、更新されている修復機能は、エラーコード“００２”、“００３”、“００５”、“００６”であることがわかる（Ｓ１４０３）。ここで、図１３（ａ）を参照すると、エラーコード“００２”、“００３”のエラーは発生しているが、“００５”、“００６”のエラーは発生していない（Ｓ１４０５）。従って、クライアントＰＣ１００ａにおいては、エラーコード“００２”、“００３”に対応する修復機能がインストール必要として判定され（Ｓ１４０６）、その他の機能はインストール不要として判定される（Ｓ１４０７）。
【００６６】
次に、クライアントＰＣ１００ｂについて説明する。図１１と図１２（ｂ）を比較すると（Ｓ１４０２）、更新されている機能は、エラーコード“００１”、“００２”、“００３”、“００６”であることがわかる（Ｓ１４０３）。ここで、図１３（ｂ）を参照すると、エラーコード“００１”、“００６”のエラーは発生しているが、“００２”、“００３”のエラーは発生していない（Ｓ１４０５）。従って、クライアントＰＣ１００ｂにおいては、エラーコード“００１”、“００６”二対応する修復機能がインストール必要として判定され（Ｓ１４０６）、その他の機能はインストール不要として判定される（Ｓ１４０７）。
【００６７】
図１０のＳ１００６以降の処理については、図５において説明した態様と同様に処理が実行される。以上説明したように、本実施形態に係るネットワークシステムにおいては、各クライアントＰＣ１００の機能更新の要否を判断する際に、機能更新の有無に加えて、更新された機能が修復するエラーが各クライアントＰＣ１００において発生しているか否かを参照する。これにより、夫々のクライアントＰＣにおいて不要な機能は更新されないため、クライアントＰＣにおける処理の削減やネットワーク負荷の低減等、システム運用を効率化することが可能となる。
【００６８】
尚、本実施形態においては、更新可能な機能の動作に関する情報として、エラー情報、即ち、対応する機能の障害発生に関する情報を参照する例を説明した。この他、障害が発生したことをトリガとして図５において説明した動作が実行されるように構成することも可能である。この場合、インストール制御部２１１が参照するのは障害発生履歴ではなく、そのタイミングにおいて障害が発生しているか否かを参照する。
【００６９】
また、装置の動作履歴に基づいて、将来発生し得る障害を予測する機能を設けても良い。この場合、障害発生履歴がない場合であっても、将来の障害発生可能性に基づいて、対応する更新を実行することができる。
【００７０】
〔第３実施形態〕
次に、第３の実施形態を説明する（ネットワークシステムは、図１参照）。図１５は、本実施形態の関連要部ブロック図である。第１、第２実施形態（図２参照）と比べ、［クライアントＰＣ；１００］と［ドメインコントローラ；２００］が、以下の点で異なる。
【００７１】
［クライアントＰＣ］
・インストール制御プログラム２１０Ｂ：インストール要否を判定し、インストール処理を実行する。インストーラとパッケージングするなどして、クライアントＰＣに保持する（あるいは、ドメインコントローラよりダウンロードされる、）。
［ドメインコントローラ］
・ファイルサーバ情報２３０：クライアントＰＣからファイルサーバにアクセスするために、ファイルサーバのネットワークアドレスなどを保持する。
【００７２】
図１６に本実施形態のインストール制御プログラム２１０Ｂに関する詳細ブロック図を示す。前実施形態とは、インストール制御プログラム起動の指示を行う入出力部２１４を有する点が異なっている。
【００７３】
本実施形態の動作フローを図１７に示す。前実施形態の動作フロー（図４）とは異なり、ログインスクリプトによってファイルサーバ情報２３０のダウンロードを行う。そして、インストーラ制御プログラム２１０Ｂの起動は、実行モジュール４０１やログオフスクリプトが行う。ちなみに、ここでは詳述はしないが、第３実施形態のような構成で、これまでの実施形態のように全てをログインスクリプトが行うことも可能であり本発明に含まれる。
【００７４】
図１７に示すように、第３実施形態では、
Ｓ２１）クライアントＰＣよりユーザがログインする。
Ｓ２２）ログインスクリプトにより、ファイルサーバ情報がログインしたクライアントＰＣにダウンロードされる。
Ｓ２３）実行モジュール（または、ログインスクリプト、または、ログオフスクリプト等）がインストーラ制御プログラム起動を指示する。
Ｓ２４）インストール制御プログラムは、ダウンロードされたファイルサーバ情報を取得する。
Ｓ２５）インストール制御プログラムは、ファイルサーバからインストーラ更新情報を取得する。
Ｓ２６）実行モジュール（または、ログインスクリプト、または、ログオフスクリプト等）が、インストーラ制御プログラムに対してインストール要否判定処理を実行する指示を行う。
Ｓ２７）インストール制御プログラムは、５で取得したインストーラ更新情報と、クライアントＰＣの実行機能情報管理部より取得した実行機能情報を利用して、普段利用している機能に関して更新があるかどうかを判定する。
Ｓ２８）過程；Ｓ２４）の判定結果、更新がある場合はダウンロード実行判定部にてダウンロード実行フラグをＯＮにする。
Ｓ２９）実行モジュール（または、ログインスクリプト、または、ログオフスクリプト等）は、インストール制御プログラムに対してダウンロードを実行する指示を行う。
Ｓ３０）インストール制御プログラムは、ダウンロード実行フラグがＯＮの場合、ファイルサーバからインストーラのダウンロードを行う。
Ｓ３１）実行モジュール（または、ログインスクリプト、または、ログオフスクリプト等）は、インストール制御プログラムに対してインストールを実行する指示を行う。
Ｓ３２）インストール制御プログラムは、インストーラが正常にダウンロードされた場合、ダウンロードしたインストーラを起動し、インストールを開始する。
【００７５】
〔第４実施形態〕
図１５の実行機能情報処理部４０３により、図１７に示す前記動作フローにおいて、インストーラ制御プログラム２１０Ｂの起動を行う形態とすることができる。
【００７６】
〔第５実施形態〕
図１５のエラー情報処理部４０２により、図１７に示す動作フローにおいて、インストーラ制御プログラムの起動を行う形態とすることができる。
【００７７】
〔第６実施形態〕
図１７に示す、動作フローにおいて、インストーラ制御プログラムの起動を、後述の［修復］ボタンを押下したタイミングで行う形態としても良い。図１８に、この態様における、エラーが発生したことを示すＵＩの一例を示す。エラーが発生したことを示すアラートに、［修復］ボタンを設けている。
【００７８】
〔その他の実施形態〕
これまで説明した各実施形態では、インストールの要否判定処理、インストーラのダウンロード処理、インストーラの実行処理は、インストール制御プログラム２１０を起動することで連続して行われる態様について説明した。しかし、本発明では、図１６中に示されているインストール制御プログラム２１０Ｂにおける、入出力部２１４によって（制御下で）それぞれの処理を実行する契機の指示を個々に行い、インストーラ制御部２１１においてそれぞれの処理を個々に行う態様とすることが可能である。
【００７９】
例えば、インストール要否判定処理については、図１７に示した、前記動作フローにおいて、インストール要否判定処理実行の指示をログイン時にログインスクリプトにて行うことができる。
また、アプリケーション実行時にアプリケーション実行モジュール、または、実行機能情報処理部、または、エラー情報処理部が行うことができる。
また、機能実行時に該当機能実行モジュール、または、実行機能情報処理部、または、エラー情報処理部が行うことができる。
また、機能終了時に該当機能実行モジュール、または、実行機能情報処理部、または、エラー情報処理部が行うことができる。
また、アプリケーション終了時にアプリケーション実行モジュール、または、実行機能情報処理部、または、エラー情報処理部が行うことができる。
また、ログオフ時にログオフスクリプトにて行うことができる。
【００８０】
インストーラのダウンロード実行の指示も特定の時点で行うことができる。例えば、図１７に示す、前記動作フローにおいて、インストーラのダウンロード実行の指示をログイン時にログインスクリプトにて行うことができる。
アプリケーション実行開始時にアプリケーション実行モジュール、または、実行機能情報処理部、または、エラー情報処理部が行うことができる。
機能実行時に該当機能実行モジュール、または、実行機能情報処理部、または、エラー情報処理部が行うことができる。
機能終了時に該当機能実行モジュール、または、実行機能情報処理部、または、エラー情報処理部が行うことができる。
アプリケーション終了時にアプリケーション実行モジュール、または、実行機能情報処理部、または、エラー情報処理部が行うことができる。
ログオフ時にログオフスクリプトにて行うことができる。
【００８１】
インストーラのダウンロード実行の指示も特定の時点で行うことができる。例えば、図１７に示す、前記動作フローにおいて、インストーラ実行の指示を、ログイン時にログインスクリプトにて行うことができる。
アプリケーション実行時にアプリケーション実行モジュール、または、実行機能情報処理部、または、エラー情報処理部が行うことができる。
機能実行時に該当機能実行モジュール、または、実行機能情報処理部、または、エラー情報処理部が行うことができる。
機能終了時に該当機能実行モジュール、または、実行機能情報処理部、または、エラー情報処理部が行うことができる。
アプリケーション終了時にアプリケーション実行モジュール、または、実行機能情報処理部、または、エラー情報処理部が行うことができる。
ログオフ時にログオフスクリプトにて行うことができる。
【００８２】
なお、上述した、インストールの要否判定処理、インストーラのダウンロード処理、インストーラの実行処理の時期は、時系列的な整合性を保って任意に組み合わせることができる。
【００８３】
これまでの説明では、インストーラ実行に際しては、バージョン単位で予定されている全ての変更を一括してバージョンアップすることを想定して説明しているが、インストーラ側の微細な対応を前提に、上述判定時にバージョンアップが必要と判定された部分単位でバージョンアップを行うようにして（部分単位で変更が済んだか否かを管理を行い、次の判定に反映させるものとする）、処理負荷の一層の分散を図る応用も考えられる。
【図面の簡単な説明】
【００８４】
【図１】本発明が適用されたネットワークシステムのシステム図である。
【図２】第１実施形態における、各ネットワーク装置それぞれの発明関連要部を示したブロック図である。
【図３】第１実施形態のインストール制御プログラムに関する詳細ブロック図である。
【図４】第１実施形態システムにおける各部の動作を示した動作フローでである。
【図５】第１実施形態システムにおけるインストール処理動作を示すシーケンス図である。
【図６】第１実施形態のインストーラ更新情報に含まれる情報例を示す図である。
【図７】第１実施形態のクライアントＰＣのバージョン情報に含まれる情報例を示す図である。
【図８】第１実施形態のクライアントＰＣの実行機能情報に含まれる情報例を示す図である。
【図９】第１実施形態のインストール要否判定動作を示すフローチャートである。
【図１０】第２実施形態システムにおけるインストール処理動作を示すシーケンス図である。
【図１１】第２実施形態のインストーラ更新情報に含まれる情報例を示す図である。
【図１２】第２実施形態のクライアントＰＣのバージョン情報に含まれる情報例を示す図である。
【図１３】第２実施形態のクライアントＰＣのエラー情報に含まれる情報例を示す図である。
【図１４】第２実施形態のインストール要否判定動作を示すフローチャートである。
【図１５】第２実施形態における、各ネットワーク装置それぞれの要部を示したブロック図である。
【図１６】第３実施形態のインストール制御プログラムに関する詳細ブロック図である。
【図１７】第３実施形態システムにおける各部の動作を示した動作フローでである。
【図１８】エラーが発生したことを示すＵＩの一例を示す図である。
【符号の説明】
【００８５】
１００（１００ａ，１００ｂ）    クライアントＰＣ（クライアント端末装置）
１１１    バージョン情報管理部
１１２    実行機能情報管理部
１１３    エラー情報管理部
２００    ドメインコントローラ
２１０、２１０Ｂ    インストール制御プログラム（インストーラ処理プログラム群）
２１１    インストール制御部
２１２    インストール要否判定部
２１３    ダウンロード実行判定部
２３０    ファイルサーバ情報
３００    ファイルサーバ
３１０    インストーラ
３１１    インストーラ更新情報
３１２    バージョン情報
４００    アプリケーションプログラム
４０１    実行モジュール
４０２    エラー情報処理部
４０３    実行機能情報処理部
５００    ネットワーク
６００    ネットワークシステム（インストール処理システム）
【図１】
2009093267.tif 000003
【図２】
2009093267.tif 000004
【図３】
2009093267.tif 000005
【図４】
2009093267.tif 000006
【図５】
2009093267.tif 000007
【図６】
2009093267.tif 000008
【図７】
2009093267.tif 000009
【図８】
2009093267.tif 000010
【図９】
2009093267.tif 000011
【図１０】
2009093267.tif 000012
【図１１】
2009093267.tif 000013
【図１２】
2009093267.tif 000014
【図１３】
2009093267.tif 000015
【図１４】
2009093267.tif 000016
【図１５】
2009093267.tif 000017
【図１６】
2009093267.tif 000018
【図１７】
2009093267.tif 000019
【図１８】
2009093267.tif 000020