JP2017211722A - 適用支援プログラム、適用支援装置および適用支援方法 - Google Patents

Abstract

【課題】更新プログラムの適用エラーが生じる情報処理装置の候補群に更新プログラムを優先的に適用させる。【解決手段】ソフトウェアの更新プログラムを受け付けると、更新プログラムの適用エラーの原因に関する情報を該更新プログラムに対応付けて記憶する記憶部を参照して、受け付けた前記更新プログラムに対応付けられた適用エラーの原因に関する情報を取得し、情報処理装置のインベントリ情報を該情報処理装置に対応付けて記憶する記憶部を参照して、複数の情報処理装置にそれぞれ対応付けられた複数のインベントリ情報を取得し、取得した前記複数のインベントリ情報と、取得した前記適用エラーの原因に関する情報とに基づき、前記複数の情報処理装置のうち、受け付けた前記更新プログラムの適用エラーが生じる情報処理装置の候補群を推定し、推定した前記候補群に含まれる情報処理装置に、受け付けた前記更新プログラムの適用を許可することを示す情報を送信する、処理をコンピュータに実行させる。【選択図】図６

Description

本発明は、適用支援プログラム、適用支援装置および適用支援方法に関する。

企業内等で利用されるＰＣ（Personal Computer）等の端末のソフトウェアの脆弱性を悪用したサイバー攻撃が増大しており、その攻撃手法も多種多様化していることから、これまで以上に脆弱性を排除し、重要な情報が盗み出されるような事態を防ぐ必要性が増してきている。

ソフトウェアの脆弱性を改善するため、ソフトウェアベンダからパッチ（セキュリティパッチ、更新プログラム）が適時に提供され、企業等では各端末にパッチを適用することで対応を行う。

マイクロソフト社はゼロデイ攻撃（パッチが提供される前の攻撃）への対策として、Windows10から、セキュリティパッチの提供サイクルをこれまでの月次提供から随時提供に変更している。そのため、日々の運用の中で各ベンダから提供されるパッチの展開（企業内等でのパッチ適用の実施推進）にさらなる迅速性が求められることになると予想される。また、ＩＴベンダから提供される業務パッケージ等においても、アジャイル開発に代表されるような短いサイクルで製品開発を実施し、短いサイクルで障害修正パッチを提供するような提供手法に変わってきている。

そのため、パッチ展開においては、パッチの安全性を検証した上で、いかに早く、全端末への適用を完了させるかが求められている。

従来は、負荷分散によるスケジューリングを行う場合を除き、全端末に対して一斉にパッチを配付（配信）した上で、端末の利用者によるパッチの適用または未適用の状態を監視していた。そして、未適用状態を検出した場合は、利用者へ督促を行うことで、パッチ適用完了までの時間を短縮する手法が取られていた。

一方、大規模システムやクラウドサービスシステムのサーバを対象としたパッチ適用の技術（特許文献１、２等）やＰＣにおけるアップデートの必要性を判断する技術（特許文献３等）が知られている。

ＷＯ２０１３／０５１１４２号公報 特開２０１２−１６８７３３号公報 特開２０１５−１４１７１９号公報

上述したように、従来はパッチが未適用の端末の利用者へ督促を行うことが主な対策であったが、パッチ適用を阻害する要因としては、利用者が多忙等の理由によりパッチを適用しないこと以外にも要因がある。すなわち、企業内等における端末は、通常、ハードウェアまたはソフトウェアの構成が一律でないため、環境不整合の問題によりパッチの適用に失敗してしまう端末が一定割合存在する。環境不整合による適用失敗については、パッチ提供元から情報提供されていないことが多いため、パッチ提供元への問い合わせが必要であり、調査に時間を要する。

そのため、早期にパッチの適用を完了させるためには、環境不整合の問題により失敗してしまう端末を早期に検出し、早期にパッチ提供元へ問い合わせを行うことが不可欠である。

しかし、従来は適用／未適用の状態だけを監視していたため、どの端末がパッチ適用に失敗しているかが判断できない。なお、パッチ適用時の実行ログを参照するなどしてパッチ適用の成功／失敗の判断を追加する手法も考えられる。しかし、端末へのパッチ適用が利用者によってすぐに実施されなかった場合は、結果としてパッチの適用が失敗した場合に、管理者が失敗と判断するのに時間がかかってしまい、早期検知ができない。

図１は従来におけるパッチの配布から適用の完了までの例を示す図である。図１（ａ）は、協力的な利用者がパッチ配布からすぐにパッチ適用を行い、成功した場合を示している。図１（ｂ）は、協力的な利用者がパッチ配布からすぐにパッチ適用を行ったが失敗した場合を示している。この場合、協力的な利用者は、すぐに管理者へ問合せを行い、管理者の指示に従ってログ等の調査資料を採取し、ベンダによる調査に入ることができる。その後、失敗の原因に対応した対処を行い、パッチ適用を成功させることができる。

一方、図１（ｃ）は、非協力的な利用者がパッチが配布されても業務を優先してパッチの適用を後回しした場合を示している。この例では、パッチ適用が成功したことから、パッチの適用完了までの時間は短く済んでいる。また、図１（ｄ）は、非協力的な利用者がパッチが配布されても業務を優先してパッチの適用を後回しした場合で、更に、パッチ適用が失敗した場合を示している。この場合、管理者への問合せも後回しとなり、管理者から要求された調査資料の採取も後回しとなる可能性が高いことから、ベンダによる調査がずれこみ、パッチの適用完了までの時間が長期化する。

図１（ｂ）（ｄ）からも明らかなように、パッチ展開の完了を早めるためには、適用失敗（適用エラー）の可能性の高い端末（情報処理装置）から優先的にパッチ（更新プログラム）の適用を開始させる必要がある。

そこで、一側面では、更新プログラムの適用エラーが生じる情報処理装置の候補群に更新プログラムを優先的に適用させることを目的とする。

一つの形態では、ソフトウェアの更新プログラムを受け付けると、更新プログラムの適用エラーの原因に関する情報を該更新プログラムに対応付けて記憶する記憶部を参照して、受け付けた前記更新プログラムに対応付けられた適用エラーの原因に関する情報を取得し、情報処理装置のインベントリ情報を該情報処理装置に対応付けて記憶する記憶部を参照して、複数の情報処理装置にそれぞれ対応付けられた複数のインベントリ情報を取得し、取得した前記複数のインベントリ情報と、取得した前記適用エラーの原因に関する情報とに基づき、前記複数の情報処理装置のうち、受け付けた前記更新プログラムの適用エラーが生じる情報処理装置の候補群を推定し、推定した前記候補群に含まれる情報処理装置に、受け付けた前記更新プログラムの適用を許可することを示す情報を送信する、処理をコンピュータに実行させる。

更新プログラムの適用エラーが生じる情報処理装置の候補群に更新プログラムを優先的に適用させることができる。

従来におけるパッチの配布から適用の完了までの例を示す図である。 一実施形態にかかるシステムの構成例を示す図である。 サーバ装置の機能構成例を示す図である。 クライアント端末の機能構成例を示す図である。 サーバ装置およびクライアント端末のハードウェア構成例を示す図である。 実施形態の処理例を示すシーケンス図である。 端末の状態遷移の例を示す図である。 グループ毎の端末の状態の例を示す図（その１）である。 グループ毎の端末の状態の例を示す図（その２）である。 グループ毎の端末の状態の例を示す図（その３）である。 適用失敗候補グループ作成の処理例を示すフローチャートである。 パッチ詳細情報ＤＢの例を示す図である。 インベントリＤＢの例を示す図である。 失敗条件候補ＤＢの例を示す図である。 「失敗条件を拡張した一時配列を作成」の処理例を示す図である。 一時配列（Ｔ１）の例を示す図である。 「失敗条件に用いる値を確定した一時配列を作成」の処理例を示すフローチャートである。 一時配列（Ｔ２、Ｔ３）の例を示す図である。 一時配列（Ｔ６）の例を示す図である。 パッチの適用の失敗の原因の例を示す図である。 失敗条件を拡張して適用失敗候補端末を特定する例を示す図（その１）である。 失敗条件を拡張して適用失敗候補端末を特定する例を示す図（その２）である。 「適用失敗候補グループを作成し、適用失敗候補グループＤＢに格納」の処理例を示すフローチャートである。 適用失敗候補グループＤＢの例を示す図である。 優先適用端末の決定の処理例を示すフローチャートである。 適用成功時動作傾向ＤＢおよび適用失敗時動作傾向ＤＢの例を示す図である。 利用者業務特性ＤＢの例を示す図である。 一時配列（Ｔ７、Ｔ８、Ｔ９、Ｔ１０）の例を示す図である。 「利用者業務特性を考慮した時間帯に応じた優先適用端末の設定」の処理例を示すフローチャートである。 一時配列（Ｔ１１、Ｔ１２、Ｔ１３、Ｔ１４、Ｔ１５）の例を示す図である。 適用失敗候補グループＤＢの優先適用端末選定後の例を示す図である。 失敗条件候補ＤＢの更新の処理例を示すフローチャートである。 適用履歴ＤＢの例を示す図である。 クライアント端末からサーバ装置への適用結果通知の例を示す図である。 一時配列（Ｔ１６）の例を示す図である。

以下、本発明の好適な実施形態につき説明する。

＜構成＞
図２は一実施形態にかかるシステムの構成例を示す図である。図２において、ソフトウェアベンダ等のパッチ提供元１に、ネットワーク２を介して、企業等の管理下にあるサーバ装置３が接続されている。パッチ提供元１には、パッチの適用失敗の原因や対処等について対応する提供元担当者が配備されている。サーバ装置３には、パッチの配布や適用失敗時の対処等について対応する管理者が配備されている。また、サーバ装置３には、社内ＬＡＮ（Local Network）等のネットワーク４を介して、各利用者が使用する複数のクライアント端末５が接続されている。クライアント端末５は、ＰＣ等の情報処理装置である。

図３はサーバ装置３の機能構成例を示す図である。図３において、サーバ装置３は、適用対象パッチ情報登録部３０１と適用失敗候補グループ作成部３０２と優先適用端末決定部３０３とパッチ配信部３０４とを備えている。また、サーバ装置３は、適用結果取得部３０５と失敗原因取得部３０６と失敗条件候補登録部３０７とインベントリ収集指示部３０８とを備えている。処理に際して参照・更新するデータベースとして、パッチ詳細情報ＤＢ３１１とインベントリＤＢ３１２と失敗条件候補ＤＢ３１３と適用失敗候補グループＤＢ３１４とを備えている。また、適用履歴ＤＢ３１５と利用者業務特性ＤＢ３１６と適用成功時動作傾向ＤＢ３１７と適用失敗時動作傾向ＤＢ３１８とを備えている。

適用対象パッチ情報登録部３０１は、サーバ装置３の管理者のパッチ適用指示に従い、パッチ提供元１からパッチ情報を取得し、パッチ詳細情報ＤＢ３１１に登録する機能を有している。サーバ装置３の管理者は、パッチ詳細情報ＤＢ３１１のパッチ詳細情報に、パッチ提供元１からのパッチ情報に含まれない他の情報を追加してパッチ詳細情報を整備する。適用失敗候補グループ作成部３０２は、パッチ詳細情報ＤＢ３１１とインベントリＤＢ３１２と失敗条件候補ＤＢ３１３を参照し、適用失敗の可能性がある端末の適用失敗候補グループを作成して適用失敗候補グループＤＢ３１４に格納する機能を有している。優先適用端末決定部３０３は、適用失敗候補グループＤＢ３１４の適用失敗候補グループから利用者の協力度やパッチ適用の時間帯傾向等に基づき、パッチの適用を優先的に行わせる優先適用端末を決定する機能を有している。優先適用端末決定部３０３は、処理に際して、利用者業務特性ＤＢ３１６、適用成功時動作傾向ＤＢ３１７および適用失敗時動作傾向ＤＢ３１８を参照する。

パッチ配信部３０４は、クライアント端末５に、パッチ適用指示状態（優先適用、適用待機、任意適用）を伴ってパッチを配信する機能を有している。優先適用は、パッチの適用が推奨される状態である。適用待機は、パッチの適用が行えない状態である。任意適用は、パッチの適用が行える状態である。なお、パッチのプログラム本体はネットワーク上の所定の場所に格納し、その場所にアクセスしてパッチを適用すべき旨の情報を配信する。

適用結果取得部３０５は、クライアント端末５から適用結果通知を受信し、適用結果から該当する内容を適用履歴ＤＢ３１５、利用者業務特性ＤＢ３１６、適用成功時動作傾向ＤＢ３１７および適用失敗時動作傾向ＤＢ３１８に格納する機能を有している。失敗原因取得部３０６は、パッチ提供元より提供された失敗原因を管理者から取得し、適用履歴ＤＢ３１５に格納する機能を有している。失敗条件候補登録部３０７は、適用履歴ＤＢ３１５の適用履歴から失敗条件候補を抽出し、失敗条件候補ＤＢ３１３に格納する機能を有している。インベントリ収集指示部３０８は、クライアント端末５に対してインベントリ情報を要求し、取得したインベントリ情報をインベントリＤＢ３１２に格納する機能を有している。

図４はクライアント端末５の機能構成例を示す図である。図４において、クライアント端末５は、パッチ受信部５０１と適用指示状態変更部５０２とパッチ適用動作制御部５０３とパッチ適用部５０４と適用結果通知部５０５とインベントリ収集部５０６とを備えている。パッチ受信部５０１は、サーバ装置３からパッチの配信を受け、配信内容に含まれるパッチ適用指示状態をパッチ適用指示状態データ５０７に保持する機能を有している。適用指示状態変更部５０２は、同じ適用失敗候補グループに属する他のクライアント端末５から適用成功の通知や所定時間内に適用が行われなかった旨等の通知を受けた場合に、パッチ適用指示状態を変更する機能を有している。

パッチ適用動作制御部５０３は、パッチ適用指示状態データ５０７に従って、パッチ適用動作を制御する機能を有している。パッチ適用部５０４は、利用者の操作に従って、パッチ適用の処理を実行する機能を有している。適用結果通知部５０５は、パッチ適用結果等をサーバ装置３、他のクライアント端末５または管理者に通知する機能を有している。インベントリ収集部５０６は、クライアント端末５内のインベントリ情報を収集し、サーバ装置３からの要求に応じ、インベントリ情報を送信する機能を有している。

図５はサーバ装置３およびクライアント端末５のハードウェア構成例を示す図である。図５において、サーバ装置３等は、バス３７を介して相互に接続されたＣＰＵ（Central Processing Unit）３１、ＲＯＭ（Read Only Memory）３２、ＲＡＭ（Random Access Memory）３３を備えている。また、サーバ装置３等は、ＨＤＤ（Hard Disk Drive）／ＳＳＤ（Solid State Drive）３４、接続Ｉ／Ｆ（Interface）３５、通信Ｉ／Ｆ３６を備えている。ＣＰＵ３１は、ＲＡＭ３３をワークエリアとしてＲＯＭ３２またはＨＤＤ／ＳＳＤ３４等に格納されたプログラムを実行することで、サーバ装置３等の動作を統括的に制御する。接続Ｉ／Ｆ３５は、サーバ装置３等に接続される機器とのインタフェースである。通信Ｉ／Ｆ３６は、ネットワークを介して他の情報処理装置と通信を行うためのインタフェースである。

図３および図４で説明した各装置の機能は、ＣＰＵ３１において所定のプログラムが実行されることで実現される。プログラムは、記録媒体を経由して取得されるものでもよいし、ネットワークを経由して取得されるものでもよいし、ＲＯＭ組込でもよい。処理に際して参照・更新されるデータは、ＲＡＭ３３またはＨＤＤ／ＳＳＤ３４に保持される。

＜動作＞
図６は上記の実施形態の処理例を示すシーケンス図である。図６において、管理者がサーバ装置３に対してパッチ適用指示を行うと（ステップＳ１）、適用対象パッチ情報登録部３０１は、パッチ提供元１にパッチ情報を要求する（ステップＳ２）。適用対象パッチ情報登録部３０１は、パッチ提供元１からパッチ情報を取得すると（ステップＳ３）、パッチ詳細情報ＤＢ３１１に登録する。パッチ情報には、パッチ名、分類（OS、software等）、種別（セキュリティ、緊急等）、適用対象ソフト名等が含まれているが、これらのパッチ情報に含まれない他の情報を、管理者は外部サービス等を利用してパッチ詳細情報ＤＢ３１１に追加する。他の情報には、適用可否チェック対象リソース、適用可否チェック条件等がある。パッチ詳細情報ＤＢ３１１の具体例については後述する。

次いで、適用失敗候補グループ作成部３０２は、パッチ詳細情報ＤＢ３１１とインベントリＤＢ３１２と失敗条件候補ＤＢ３１３を参照し、適用失敗の可能性がある端末の適用失敗候補グループを作成して適用失敗候補グループＤＢ３１４に格納する（ステップＳ４）。適用失敗候補グループ作成部３０２は、対象となるパッチについての過去の失敗条件から適用失敗の可能性のある端末を推定し、インベントリ情報に基づくソフトウェア（ＯＳ、ミドルウェア、ソフトウェア等）の構成ごとに分類し、適用失敗候補グループを作成する。インベントリ情報に基づいて分類を行うのは、同じソフトウェアの構成の端末は同じ原因による適用失敗が同様に起こることが予想されるからである。利用するデータベースおよび処理の詳細については後述する。

次いで、優先適用端末決定部３０３は、適用失敗候補グループＤＢ３１４の適用失敗候補グループから利用者の協力度やパッチ適用の時間帯傾向等に基づき、パッチの適用を優先的に行わせる優先適用端末を決定する（ステップＳ５）。また、パッチの対象となるソフトウェアの起動回数等の情報に基づき、業務への影響の少なさを優先適用端末の決定に用いてもよい。利用するデータベースおよび処理の詳細については後述する。

なお、適用失敗候補グループ毎に１つの優先端末を決定するものとしているが、２以上の優先端末を決定してもよい。優先端末を適用失敗候補グループに属する端末の一部に限るのは、同じ原因に基づく適用失敗が同時期に発生することによる管理者の対応の負荷の増大を防止するためである。

次いで、パッチ配信部３０４は、クライアント端末５Ａ、５Ｂ、・・に、パッチ適用指示状態（優先適用、適用待機、任意適用）を伴ってパッチを配信する（ステップＳ６）。なお、パッチのプログラム本体はネットワーク上の所定の場所に格納し、その場所にアクセスしてパッチを適用すべき旨の情報を配信する。

クライアント端末５Ａのパッチ適用部５０４は、パッチ適用指示状態が優先適用である場合または任意適用である場合、利用者に対してパッチ適用を案内する（ステップＳ７）。これに応えて利用者がパッチ適用操作を行うと（ステップＳ８）、パッチ適用部５０４は、パッチ適用の処理を実行する。

適用結果通知部５０５は、パッチ適用結果（適用成功、適用失敗）をサーバ装置３に通知する（ステップＳ９）。また、適用失敗の場合、適用結果通知部５０５は、管理者にも適用失敗を電子メール等で通知する（ステップＳ１０）。

クライアント端末５Ａがある適用失敗候補グループに属し、かつ優先端末に選択されている場合であって、適用成功の場合、適用結果通知部５０５は、同じ適用失敗候補グループに属する他のクライアント端末５Ｂに端末間で適用成功を通知する（ステップＳ１１）。クライアント端末５Ｂは適用指示状態変更部５０２で適用成功の通知を受けると、パッチ適用指示状態データ５０７の状態を適用待機から任意適用に変更する（ステップＳ１２）。

また、クライアント端末５Ａがある適用失敗候補グループに属し、優先端末に選択されている場合で、所定の時間が経過してもパッチの適用が行われない場合、適用結果通知部５０５は、同グループのクライアント端末５Ｂにパッチ未適用を通知する（ステップＳ１１）。クライアント端末５Ｂは適用指示状態変更部５０２でパッチ未適用の通知を受けると、自己が次の優先順位である場合、パッチ適用指示状態データ５０７の状態を適用待機から優先適用に変更する（ステップＳ１２）。

図７は端末の状態遷移の例を示す図であり、状態は「任意適用」「優先適用」「適用待機」「適用完了」がある。前述したように、任意適用はパッチの適用が行える状態であり、優先適用はパッチの適用が推奨される状態であり、適用待機はパッチの適用が行えない状態である。各端末は、開始時は任意適用であり、適用失敗候補グループ毎に１つの端末（優先端末）が優先適用に設定され、同グループ内の他の端末は適用待機となる。優先端末（優先適用）においてパッチの適用が成功すると適用完了となる。優先端末（優先適用）においてパッチの適用が所定の時間にわたって行われない場合、元の優先適用であった端末は適用待機となり、同じ適用失敗候補グループに属する他の端末であって優先順位が次の端末が優先適用となる。優先適用の端末がパッチの適用に失敗した場合、状態は変わらず、その適用失敗候補グループについては、管理者が介在した対処が行われるまで、パッチの適用は行われない。

図８はグループ毎の端末の状態の例を示す図であり、適用失敗候補グループＡの一番上の端末が優先適用とされ、他は適用待機とされている。適用失敗候補グループＢは上から２番目の端末が優先適用とされ、他は適用待機とされている。適用失敗候補グループＣは一番下の端末が優先適用とされ、他は適用待機とされている。その他グループの端末は、すべて任意適用に設定されている。この状態で、適用失敗候補グループＡの一番上の端末が所定の時間にわたってパッチの適用が行われない場合、図９に示すように、２番目の端末に優先適用が移行し、元の端末は適用待機となる。この状態で、適用失敗候補グループＡの２番目の端末がパッチの適用に成功すると、図１０に示すように、２番目の端末以外の端末が任意適用となる。

図６に戻り、適用失敗の通知を受けた管理者は、パッチ提供元１の提供元担当者に調査依頼を行い（ステップＳ１３）、提供元担当者から失敗原因報告が行われると（ステップＳ１４）、管理者は失敗原因を適用履歴ＤＢ３１５に登録する（ステップＳ１５）。

＜詳細動作＞
図１１は適用失敗候補グループ作成部３０２による適用失敗候補グループ作成の処理例を示すフローチャートである。図１１において、適用失敗候補グループ作成部３０２は、パッチ詳細情報ＤＢ３１１を参照し（ステップＳ１０１）、インベントリＤＢ３１２を参照し（ステップＳ１０２）、失敗条件候補ＤＢ３１３を参照する（ステップＳ１０３）。図１２はパッチ詳細情報ＤＢ３１１の例を示す図であり、「パッチ名」「分類（OS、software等）」「種別（セキュリティ、緊急等）」「適用対象ソフト名」「適用可否チェック対象リソース」「適用可否チェック条件」等の項目を有している。「適用可否チェック対象リソース」には、「リソース種別」「リソースＩＤ」「属性名」等が含まれている。図１３はインベントリＤＢ３１２の例を示す図であり、「端末」「インベントリ値」等の項目を有している。インベントリ値には、「ＯＳ名」「導入ソフト」「ＩＰアドレス」「レジストリ」「ファイル」等が含まれている。図１４は失敗条件候補ＤＢ３１３の例を示す図であり、「適用対象ソフト名」「リソース種別」「リソースＩＤ」「属性名」等の項目を有している。

図１１に戻り、適用失敗候補グループ作成部３０２は、パッチ詳細情報および失敗条件候補から、失敗条件を拡張した一時配列を作成する（ステップＳ１０４）。処理の詳細については後述する。

次いで、適用失敗候補グループ作成部３０２は、失敗条件に用いる値を確定した一時配列を作成する（ステップＳ１０５）。処理の詳細については後述する。

次いで、適用失敗候補グループ作成部３０２は、インベントリ情報を用いて、適用失敗候補グループを作成し、適用失敗候補グループＤＢ３１４に格納する（ステップＳ１０６）。適用失敗候補グループＤＢ３１４の具体例および処理の詳細については後述する。

次に、図１５は「失敗条件を拡張した一時配列を作成」（図１１のステップＳ１０４）の処理例を示す図である。図１５において、適用失敗候補グループ作成部３０２は、パッチ詳細情報ＤＢ３１１（図１２）のパッチ名数分ループして処理を行う（ステップＳ１１１〜Ｓ１１７）。

ループ内の処理として、適用失敗候補グループ作成部３０２は、パッチ詳細情報ＤＢ３１１（図１２）において、パッチ名に対応する適用対象ソフト名とリソースＩＤを取得する（ステップＳ１１２）。

次いで、適用失敗候補グループ作成部３０２は、取得した適用対象ソフト名で失敗条件候補ＤＢ３１３（図１４）を検索し（ステップＳ１１３）、検索結果を一時配列（Ｔ１）に追加する （ステップＳ１１４）。

次いで、適用失敗候補グループ作成部３０２は、取得したリソースＩＤで失敗条件候補ＤＢ３１３（図１４）を検索し（ステップＳ１１５）、検索結果を一時配列（Ｔ１）に追加する（ステップＳ１１６）。

図１６は、パッチ名数分ループした後の一時配列（Ｔ１）の例を示す図である。"Product_X"をキーに抽出した結果、"HKLM\YYY\BB\B"をキーに抽出した結果、"C:\Program …Y\B.inf"をキーに抽出した結果、"Product_Y"をキーに抽出した結果、"C:\Program …Y\A.inf"をキーに抽出した結果が追加されている。太字・斜線で示した内容は、関連する項目から拡張された結果を示している。詳細については後述する。

次に、図１７は「失敗条件に用いる値を確定した一時配列を作成」（図１１のステップＳ１０５）の処理例を示すフローチャートである。図１７において、適用失敗候補グループ作成部３０２は、パッチ詳細情報ＤＢ３１１（図１２）の適用可否チェック条件を反転させ、所定項目を抽出した一時配列（Ｔ２）を作成する（ステップＳ１２１）。適用可否チェック条件を反転させるのは、成功の条件から失敗条件に変換するためである。図１８の上段には一時配列（Ｔ２）の例を示している。

図１７に戻り、適用失敗候補グループ作成部３０２は、一時配列（Ｔ１）（図１６）から重複行を削除する（ステップＳ１２２）。次いで、適用失敗候補グループ作成部３０２は、重複行を削除した一時配列（Ｔ１）と一時配列（Ｔ２）（図１８上段）をマージし、リソースＩＤ、属性名の一致する行は一時配列（Ｔ２）の失敗条件を採用し、一時配列（Ｔ３）を作成する（ステップＳ１２３）。図１８の下段には一時配列（Ｔ３）の例を示している。

図１７に戻り、適用失敗候補グループ作成部３０２は、一時配列（Ｔ３）（図１８下段）のレコード数分ループして処理を行う（ステップＳ１２４〜Ｓ１３７）。

ループ内の処理として、適用失敗候補グループ作成部３０２は、失敗条件が"−"（空欄）か否か判断する（ステップＳ１２５）。失敗条件が"−"でない場合（ステップＳ１２５のＮｏ）、適用失敗候補グループ作成部３０２は、ループ内で一時配列（Ｔ３）の次のレコードの処理に移行する（ステップＳ１３７→Ｓ１２４）。

失敗条件が"−"である場合（ステップＳ１２５のＹｅｓ）、適用失敗候補グループ作成部３０２は、一時配列（Ｔ４）<key, value配列>（値（失敗条件），該当端末）を作成する（ステップＳ１２６）。一時配列（Ｔ４）は値を一時的に保持するだけであるため、図示を省略する。

次いで、適用失敗候補グループ作成部３０２は、適用対象の端末台数分ループして処理を行う（ステップＳ１２７〜Ｓ１３２）。

ループ内の処理として、適用失敗候補グループ作成部３０２は、インベントリＤＢ３１２（図１３）のリソース種別のカラムを、リソースＩＤ、属性名で検索し（ステップＳ１２８）、検索結果の値が一時配列（Ｔ４）のkeyに存在するか否か判断する（ステップＳ１２９）。

keyに存在する場合（ステップＳ１２９のＹｅｓ）、適用失敗候補グループ作成部３０２は、一時配列（Ｔ４）のkeyのvalueに該当端末を追加する（ステップＳ１３０）。また、keyに存在しない場合（ステップＳ１２９のＮｏ）、適用失敗候補グループ作成部３０２は、一時配列（Ｔ４）に値と該当端末を追加する（ステップＳ１３１）。そして、適用失敗候補グループ作成部３０２は、ループ内で次の端末の処理に移行する（ステップＳ１３２→Ｓ１２７）。

次いで、端末台数分のループを抜けた場合、適用失敗候補グループ作成部３０２は、一時配列（Ｔ４）から一時配列（Ｔ５） <key,value>（値（失敗条件）、該当端末の割合（％））を作成する（ステップＳ１３３）。そして、適用失敗候補グループ作成部３０２は、一時配列（Ｔ５）で、該当端末の割合が閾値を越える要素があるか否か判断する（ステップＳ１３４）。閾値は、例えば５０％とする。閾値を超えない場合は、環境に依存する属性であるため、除外する。閾値を超える場合は、正常適用できると判断する。なお、一時配列（Ｔ５）は値を一時的に保持するだけであるため、図示を省略する。

閾値を越える要素がある場合（ステップＳ１３４のＹｅｓ）、適用失敗候補グループ作成部３０２は、一時配列（Ｔ３）（図１８下段）の失敗条件"−"をkeyで書き換え、keyが複数ある場合は、閾値を超えるkey以外を行追加する（ステップＳ１３５）。閾値を越える要素がない場合（ステップＳ１３４のＮｏ）、適用失敗候補グループ作成部３０２は、一時配列（Ｔ３）（図１８下段）から除外する（ステップＳ１３６）。そして、適用失敗候補グループ作成部３０２は、ループ内で次のレコードの処理に移行する（ステップＳ１３７→Ｓ１２４）。

次いで、一時配列（Ｔ３）（図１８下段）のレコード数分のループを抜けた場合、適用失敗候補グループ作成部３０２は、一時配列（Ｔ３）（図１８下段）に登録されている条件でインベントリＤＢ３１２（図１３）から該当端末を検索する。そして、適用失敗候補グループ作成部３０２は、結果をグループ作成条件一覧に追加し、一時配列（Ｔ６）を作成し（ステップＳ１３８）、処理を終了する。図１９は一時配列（Ｔ６）の例を示している。

ここで、上述した適用失敗候補グループ作成部３０２による失敗条件の拡張について、より詳しく説明する。

図２０はパッチの適用の失敗の原因の例を示す図である。端末PC-AのＯＳはWindows7、導入ソフトはProduct X、・・、端末PC-BのＯＳはWindows7、導入ソフトはProduct Y、・・とする。端末PC-CのＯＳはWindows8、導入ソフトはProduct X、Product Y、・・、端末PC-DのＯＳはWindows8、導入ソフトはProduct X、Product Y、・・とする。

この環境で、過去、パッチPatch-A、適用対象ソフトProduct Xについて端末PC-Aで適用失敗があり、その後の対処で適用が完了しているとする。この適用失敗の原因は特定のレジストリキーの不具合であることが分かっているものとする。また、パッチPatch-B、適用対象ソフトProduct Yについて端末PC-Cで適用失敗があり、その後の対処で適用が完了しているとする。この適用失敗の原因はファイルのバージョンの不整合であることが分かっているものとする。

図２１はパッチPatch-Aについて失敗条件を拡張して適用失敗候補端末を特定する例を示す図である。特定のレジストリキーで適用失敗が生じたことは失敗条件として把握されている。また、他の失敗条件候補として、特定のパッチとは関係なく、同じレジストリのディレクトリの他のキーについてと、所定のファイルのファイルサイズについても候補に挙がっているとする。例えば、過去に適用失敗があった原因のレジストリと同じディレクトリの他の値を、環境によって変化するもの（日付、ユーザ名等）を除いて、候補として挙げておくことができる。

この場合、端末PC-Aについては、パッチPatch-Aについての過去の失敗原因と同じ理由から適用失敗候補として抽出される。また、端末PC-Cについては、パッチPatch-Aについての過去の失敗原因とは別に、拡張されて、適用失敗候補として抽出される。ここで、端末PC-Cの"name Product-X"は、他の端末PC-A、端末PC-Dでの対応箇所では"name Product_X"となっていて、"-"と"_"の違いがあり、所定の閾値を下回る少数派である端末PC-Cが適用失敗候補として抽出されている。

図２２はパッチPatch-Bについて失敗条件を拡張して適用失敗候補端末を特定する例を示す図である。特定のファイルのバージョンの不整合で適用失敗が生じたことは失敗条件として把握されている。また、他の失敗条件候補として、特定のパッチとは関係なく、適用失敗の原因となったファイルと同じフォルダ内の他のファイルについてのバージョンについても候補に挙がっているとする。

この場合、端末PC-Cについては、パッチPatch-Bについての過去の失敗原因と同じ理由から適用失敗候補として抽出される。また、端末PC-Dについては、パッチPatch-Bについての過去の失敗原因とは別に、拡張されて、適用失敗候補として抽出される。ここで、端末PC-Dのファイルバージョン"C"は、他の端末PC-B、端末PC-Cでの対応ファイルでは"なし"となっていて、所定の閾値を下回る少数派である端末PC-Dが適用失敗候補として抽出されている。

次に、図２３は「適用失敗候補グループを作成し、適用失敗候補グループＤＢに格納」（図１１のステップＳ１０６）の処理例を示すフローチャートである。図２３において、適用失敗候補グループ作成部３０２は、一時配列（Ｔ６）（図１９）の適用対象パッチ数分ループして処理を行う（ステップＳ１４１〜Ｓ１４９）。

ループ内の処理として、適用失敗候補グループ作成部３０２は、失敗条件の全組み合わせパターンを作成し（ステップＳ１４２）、組み合わせに使用した要素の数が多い順にソートする（ステップＳ１４３）。

次いで、適用失敗候補グループ作成部３０２は、組み合わせパターン数分ループして処理を行う（ステップＳ１４４〜Ｓ１４８）。

ループ内の処理として、適用失敗候補グループ作成部３０２は、組み合わせパターンに該当する端末を抽出し（ステップＳ１４５）、抽出された端末から過去に抽出された端末は除外する（ステップＳ１４６）。

そして、適用失敗候補グループ作成部３０２は、組み合わせパターン、適用対象パッチ、適用対象ソフト名、該当端末を適用失敗候補グループＤＢ３１４に挿入する（ステップＳ１４７）。図２４は適用失敗候補グループＤＢ３１４の例を示している。

次に、図２５は優先適用端末決定部３０３による優先適用端末の決定の処理例を示すフローチャートである。図２５において、優先適用端末決定部３０３は、適用成功時動作傾向ＤＢ３１７を参照し（ステップＳ２０１）、適用失敗時動作傾向ＤＢ３１８を参照し（ステップＳ２０２）、利用者業務特性ＤＢ３１６を参照する （ステップＳ２０３）。図２６の上段は適用成功時動作傾向ＤＢ３１７の例を示しており、「適用対象ソフト名」「端末名」「適用成功パッチ数」「適用開始平均時間」「適用完了平均時間」「対処提示〜パッチ適用開始までの平均時間」等の項目を有している。図２６の下段は適用失敗時動作傾向ＤＢ３１８の例を示しており、「適用対象ソフト名」「端末名」「適用失敗パッチ数」の項目を有している。また、「適用失敗〜管理者への連絡（電話／メール）までの平均時間」「適用失敗〜Logファイル参照までの平均時間」「適用失敗〜Logファイルコピーまでの平均時間」等の項目を有している。図２７は利用者業務特性ＤＢ３１６の例を示しており、「適用対象ソフト名」「端末名」「am」「pm」「残業時間」「9」〜「18〜」等の項目を有している。「9」〜「18〜」は業務時間の９から１７時台と残業時間における過去にパッチの適用が行われた回数を示している。「am」は全時間帯合計に対する午前（「9」〜「11」）の合計の比率、「pm」は全時間帯合計に対する午後（「12」〜「17」）の合計の比率、「残業時間」は全時間帯合計に対する残業時間（「18〜」）の数の比率である。

図２５に戻り、優先適用端末決定部３０３は、適用操作傾向に基づいたランキングを決定し、適用成功時動作傾向ＤＢ３１７をソートした結果を一時配列（Ｔ７）に格納する（ステップＳ２０４）。ソート条件は、例えば、第一キー：対処提示〜パッチ適用開始までの平均時間、第二キー：適用開始平均時間、第三キー：適用完了平均時間とする。図２８の最上段に一時配列（Ｔ７）の例を示す。

図２５に戻り、優先適用端末決定部３０３は、適用結果報告傾向に基づいたランキングを決定し、適用失敗時動作傾向ＤＢ３１８をソートした結果を一時配列（Ｔ８）に格納する（ステップＳ２０５）。ソート条件は、例えば、第一キー：適用失敗〜管理者への連絡までの平均時間とする。図２８の上から２段目に一時配列（Ｔ８）の例を示す。

図２５に戻り、優先適用端末決定部３０３は、調査スキル傾向に基づいたランキングを決定し、適用失敗時動作傾向ＤＢ３１８をソートした結果を一時配列（Ｔ９）に格納する（ステップＳ２０６）。ソート条件は、例えば、第一キー：適用失敗〜Logファイルコピーまでの平均時間、第二キー：適用失敗〜Logファイル参照までの平均時間とする。図２８の上から３段目に一時配列（Ｔ９）の例を示す。

図２５に戻り、優先適用端末決定部３０３は、各端末に対して、上記の３つの傾向のランキングの和を取ることで総合ポイントを算出し、一時配列（Ｔ１０）に格納する（ステップＳ２０７）。図２８の一番下の段に一時配列（Ｔ１０）の例を示す。

図２５に戻り、優先適用端末決定部３０３は、利用者業務特性を考慮した時間帯に応じた優先適用端末を設定する（ステップＳ２０８）。

次に、図２９は「利用者業務特性を考慮した時間帯に応じた優先適用端末の設定」（図２５のステップＳ２０８）の処理例を示すフローチャートである。図２９において、優先適用端末決定部３０３は、端末数分ループして処理を行い（ステップＳ２１１〜Ｓ２１５）、その中で更に時間帯の分割数分ループして処理を行う（ステップＳ２１２〜Ｓ２１４）。

そのループ内の処理として、適用失敗候補グループ作成部３０２は、時間帯での総合ポイントの算出を行う（ステップＳ２１３）。具体的には、一時配列（Ｔ１０）（図２８下段）の総合ポイントを利用者業務特性ＤＢ３１６（図２７）の「am」「pm」「残業時間」の時間帯の割合で割り、その結果を一時配列（Ｔ１１）に格納する（ステップＳ２１４）。ここでの総合ポイントは値が小さいほどランキングが高くなり、「am」「pm」「残業時間」の時間帯の割合で割ることで、時間帯の割合が大きいほどランキングが高くなるように補正される。その結果、パッチ配信を行う時間帯（午前、午後、残業時間）においてパッチが適用される傾向の高い端末が上位にランキングされる。図３０の一番上の段に一時配列（Ｔ１１）の例を示す。

図２９に戻り、ループを抜けると、適用失敗候補グループ作成部３０２は、一時配列（Ｔ１２）に、一時配列（Ｔ１１)をam総合ポイントで昇順ソートして順位付けした結果を格納する（ステップＳ２１６）。同様に、適用失敗候補グループ作成部３０２は、一時配列（Ｔ１３)に、一時配列（Ｔ１１)をpm総合ポイントで昇順ソートして順位付けした結果を格納する（ステップＳ２１７）。また、適用失敗候補グループ作成部３０２は、一時配列（Ｔ１４)に、一時配列（Ｔ１１)を残業時間総合ポイントで昇順ソートして順位付けした結果を格納する（ステップＳ２１８）。図３０に一時配列（Ｔ１２）（Ｔ１３)（Ｔ１４)の例を示す。

図２９に戻り、適用失敗候補グループ作成部３０２は、一時配列（Ｔ１２)、(Ｔ１３)、(Ｔ１４)をマージし、一時配列（Ｔ１５)を作成する（ステップＳ２１９）。図３０の一番下の段に一時配列（Ｔ１５)の例を示す。

図２９に戻り、適用失敗候補グループ作成部３０２は、一時配列（Ｔ１５)を適用失敗候補グループＤＢ３１４にマージし（ステップＳ２２０）、処理を終了する。図３１に、マージ後の適用失敗候補グループＤＢ３１４の例を示している。パッチの配信にあっては、各適用失敗候補グループにおいて、配信の時間帯に対応する優先度に基づいて優先端末を決定する。

なお、時間帯における過去のパッチの適用傾向に基づいて端末の優先度を補正する例について説明したが、各端末におけるパッチの対象となるソフトウェアの起動回数が基準値よりも少なく、適用失敗時の業務への影響が少ない端末の優先度を上げるように補正してもよい。

次に、図３２は、失敗条件候補登録部３０７による失敗条件候補ＤＢ３１３の更新の処理例を示すフローチャートである。図３２において、失敗条件候補登録部３０７は、適用履歴ＤＢ３１５を参照し、結果が失敗の履歴を取得し、一時配列（Ｔ１６)に格納する（ステップＳ３０１）。図３３は適用履歴ＤＢ３１５の例を示している。なお、適用履歴ＤＢ３１５は、図３４に示すような適用成功時・適用失敗時にクライアント端末５から送信される適用結果通知と、失敗原因取得部３０６により管理者から取得される情報とに基づいて格納されるものである。また、図３５は一時配列（Ｔ１６)の例を示している。

図３２に戻り、失敗条件候補登録部３０７は、一時配列（Ｔ１６)のレコード数分ループして処理を行う（ステップＳ３０２〜Ｓ３０７）。

そのループ内の処理として、失敗条件候補登録部３０７は、リソース種別がレジストリであるか否か判断する（ステップＳ３０３）。リソース種別がレジストリである場合（ステップＳ３０３のＹｅｓ）、失敗条件候補登録部３０７は、同一階層のレジストリの値の名前を取得し、一時配列（Ｔ１６)に追加する（ステップＳ３０４）。

リソース種別がレジストリでない場合（ステップＳ３０３のＮｏ）、失敗条件候補登録部３０７は、リソース種別がファイルであるか否か判断する（ステップＳ３０５）。リソース種別がファイルである場合（ステップＳ３０５のＹｅｓ）、失敗条件候補登録部３０７は、ファイルの属性名を全て一時配列（Ｔ１６)に追加する（ステップＳ３０６）。

その後、ループを抜けると、失敗条件候補登録部３０７は、一時配列（Ｔ１６)を失敗条件候補ＤＢ３１３に追加し（ステップＳ３０８）、処理を終了する。

＜総括＞
以上説明したように、本実施形態によれば、更新プログラムの適用エラーが生じる情報処理装置の候補群に更新プログラムを優先的に適用させることができる。

また、候補群の一部に更新プログラムの適用を限ることで、適用失敗によるインシデントの大量発生を防止することができ、管理者の負担を低減することができる。

また、協力的な利用者の使用する情報処理装置を優先することで、適用完了までの時間をより早めることができる。更に、更新プログラムの対象となるソフトウェアの利用度の低い情報処理装置を優先することで、適用失敗時における業務への影響を少なくすることができる。

以上、好適な実施の形態により説明した。ここでは特定の具体例を示して説明したが、特許請求の範囲に定義された広範な趣旨および範囲から逸脱することなく、これら具体例に様々な修正および変更を加えることができることは明らかである。すなわち、具体例の詳細および添付の図面により限定されるものと解釈してはならない。

以上の説明に関し、更に以下の項を開示する。
（付記１）
ソフトウェアの更新プログラムを受け付けると、更新プログラムの適用エラーの原因に関する情報を該更新プログラムに対応付けて記憶する記憶部を参照して、受け付けた前記更新プログラムに対応付けられた適用エラーの原因に関する情報を取得し、
情報処理装置のインベントリ情報を該情報処理装置に対応付けて記憶する記憶部を参照して、複数の情報処理装置にそれぞれ対応付けられた複数のインベントリ情報を取得し、
取得した前記複数のインベントリ情報と、取得した前記適用エラーの原因に関する情報とに基づき、前記複数の情報処理装置のうち、受け付けた前記更新プログラムの適用エラーが生じる情報処理装置の候補群を推定し、
推定した前記候補群に含まれる情報処理装置に、受け付けた前記更新プログラムの適用を許可することを示す情報を送信する、
処理をコンピュータに実行させることを特徴とする適用支援プログラム。
（付記２）
推定した前記候補群に含まれる情報処理装置の一部に、受け付けた前記更新プログラムの適用を許可することを示す情報を送信する、
ことを特徴とする付記１に記載の適用支援プログラム。
（付記３）
前記一部の情報処理装置が前記更新プログラムの適用を所定の時間にわたって実施しない場合、前記一部の情報処理装置について前記更新プログラムの適用を許可を取り消し、前記候補群に含まれる他の情報処理装置に前記更新プログラムの適用を許可する、
ことを特徴とする付記２に記載の適用支援プログラム。
（付記４）
前記一部の情報処理装置が前記更新プログラムの適用に成功した場合、前記候補群に含まれる他の情報処理装置に前記更新プログラムの適用を許可することを示す情報を送信する、
ことを特徴とする付記２に記載の適用支援プログラム。
（付記５）
更新プログラムの適用に関する対応の迅速さを情報処理装置に対応付けて記憶する記憶部を参照して、推定した前記情報処理装置の候補群のうち、更新プログラムの適用に関する対応の迅速さが基準を満たす情報処理装置を特定し、
特定した前記情報処理装置に、受け付けた前記更新プログラムの適用を許可することを示す情報を送信する、
ことを特徴とする付記２乃至４のいずれか一項に記載の適用支援プログラム。
（付記６）
更新プログラムの適用に関する時間帯毎の実施傾向を情報処理装置に対応付けて記憶する記憶部を参照して、推定した前記情報処理装置の候補群のうち、更新プログラムを配布する時間帯における実施傾向が基準を満たす情報処理装置を特定し、
特定した前記情報処理装置に、受け付けた前記更新プログラムの適用を許可することを示す情報を送信する、
ことを特徴とする付記２乃至５のいずれか一項に記載の適用支援プログラム。
（付記７）
ソフトウェアの起動回数を情報処理装置に対応付けて記憶する記憶部を参照して、推定した前記情報処理装置の候補群のうち、受け付けた前記更新プログラムにかかるソフトウェアの起動回数が基準よりも少ない情報処理装置を特定し、
特定した前記情報処理装置に、受け付けた前記更新プログラムの適用を許可することを示す情報を送信する、
ことを特徴とする付記２乃至６のいずれか一項に記載の適用支援プログラム。
（付記８）
ソフトウェアの更新プログラムを受け付けると、更新プログラムの適用エラーの原因に関する情報を該更新プログラムに対応付けて記憶する記憶部を参照して、受け付けた前記更新プログラムに対応付けられた適用エラーの原因に関する情報を取得する手段と、
情報処理装置のインベントリ情報を該情報処理装置に対応付けて記憶する記憶部を参照して、複数の情報処理装置にそれぞれ対応付けられた複数のインベントリ情報を取得する手段と、
取得した前記複数のインベントリ情報と、取得した前記適用エラーの原因に関する情報とに基づき、前記複数の情報処理装置のうち、受け付けた前記更新プログラムの適用エラーが生じる情報処理装置の候補群を推定する手段と、
推定した前記候補群に含まれる情報処理装置に、受け付けた前記更新プログラムの適用を許可することを示す情報を送信する手段と、
を備えたことを特徴とする適用支援装置。
（付記９）
推定した前記候補群に含まれる情報処理装置の一部に、受け付けた前記更新プログラムの適用を許可することを示す情報を送信する、
ことを特徴とする付記８に記載の適用支援装置。
（付記１０）
前記一部の情報処理装置が前記更新プログラムの適用を所定の時間にわたって実施しない場合、前記一部の情報処理装置について前記更新プログラムの適用を許可を取り消し、前記候補群に含まれる他の情報処理装置に前記更新プログラムの適用を許可する、
ことを特徴とする付記９に記載の適用支援装置。
（付記１１）
前記一部の情報処理装置が前記更新プログラムの適用に成功した場合、前記候補群に含まれる他の情報処理装置に前記更新プログラムの適用を許可することを示す情報を送信する、
ことを特徴とする付記９に記載の適用支援装置。
（付記１２）
更新プログラムの適用に関する対応の迅速さを情報処理装置に対応付けて記憶する記憶部を参照して、推定した前記情報処理装置の候補群のうち、更新プログラムの適用に関する対応の迅速さが基準を満たす情報処理装置を特定し、
特定した前記情報処理装置に、受け付けた前記更新プログラムの適用を許可することを示す情報を送信する、
ことを特徴とする付記９乃至１１のいずれか一項に記載の適用支援装置。
（付記１３）
更新プログラムの適用に関する時間帯毎の実施傾向を情報処理装置に対応付けて記憶する記憶部を参照して、推定した前記情報処理装置の候補群のうち、更新プログラムを配布する時間帯における実施傾向が基準を満たす情報処理装置を特定し、
特定した前記情報処理装置に、受け付けた前記更新プログラムの適用を許可することを示す情報を送信する、
ことを特徴とする付記９乃至１２のいずれか一項に記載の適用支援装置。
（付記１４）
ソフトウェアの起動回数を情報処理装置に対応付けて記憶する記憶部を参照して、推定した前記情報処理装置の候補群のうち、受け付けた前記更新プログラムにかかるソフトウェアの起動回数が基準よりも少ない情報処理装置を特定し、
特定した前記情報処理装置に、受け付けた前記更新プログラムの適用を許可することを示す情報を送信する、
ことを特徴とする付記９乃至１３のいずれか一項に記載の適用支援装置。
（付記１５）
ソフトウェアの更新プログラムを受け付けると、更新プログラムの適用エラーの原因に関する情報を該更新プログラムに対応付けて記憶する記憶部を参照して、受け付けた前記更新プログラムに対応付けられた適用エラーの原因に関する情報を取得し、
情報処理装置のインベントリ情報を該情報処理装置に対応付けて記憶する記憶部を参照して、複数の情報処理装置にそれぞれ対応付けられた複数のインベントリ情報を取得し、
取得した前記複数のインベントリ情報と、取得した前記適用エラーの原因に関する情報とに基づき、前記複数の情報処理装置のうち、受け付けた前記更新プログラムの適用エラーが生じる情報処理装置の候補群を推定し、
推定した前記候補群に含まれる情報処理装置に、受け付けた前記更新プログラムの適用を許可することを示す情報を送信する、
処理をコンピュータが実行することを特徴とする適用支援方法。
（付記１６）
推定した前記候補群に含まれる情報処理装置の一部に、受け付けた前記更新プログラムの適用を許可することを示す情報を送信する、
ことを特徴とする付記１５に記載の適用支援方法。
（付記１７）
前記一部の情報処理装置が前記更新プログラムの適用を所定の時間にわたって実施しない場合、前記一部の情報処理装置について前記更新プログラムの適用を許可を取り消し、前記候補群に含まれる他の情報処理装置に前記更新プログラムの適用を許可する、
ことを特徴とする付記１６に記載の適用支援方法。
（付記１８）
前記一部の情報処理装置が前記更新プログラムの適用に成功した場合、前記候補群に含まれる他の情報処理装置に前記更新プログラムの適用を許可することを示す情報を送信する、
ことを特徴とする付記１６に記載の適用支援方法。
（付記１９）
更新プログラムの適用に関する対応の迅速さを情報処理装置に対応付けて記憶する記憶部を参照して、推定した前記情報処理装置の候補群のうち、更新プログラムの適用に関する対応の迅速さが基準を満たす情報処理装置を特定し、
特定した前記情報処理装置に、受け付けた前記更新プログラムの適用を許可することを示す情報を送信する、
ことを特徴とする付記１６乃至１８のいずれか一項に記載の適用支援方法。
（付記２０）
更新プログラムの適用に関する時間帯毎の実施傾向を情報処理装置に対応付けて記憶する記憶部を参照して、推定した前記情報処理装置の候補群のうち、更新プログラムを配布する時間帯における実施傾向が基準を満たす情報処理装置を特定し、
特定した前記情報処理装置に、受け付けた前記更新プログラムの適用を許可することを示す情報を送信する、
ことを特徴とする付記１６乃至１９のいずれか一項に記載の適用支援方法。
（付記２１）
ソフトウェアの起動回数を情報処理装置に対応付けて記憶する記憶部を参照して、推定した前記情報処理装置の候補群のうち、受け付けた前記更新プログラムにかかるソフトウェアの起動回数が基準よりも少ない情報処理装置を特定し、
特定した前記情報処理装置に、受け付けた前記更新プログラムの適用を許可することを示す情報を送信する、
ことを特徴とする付記１６乃至２０のいずれか一項に記載の適用支援方法。

１ パッチ提供元
２ ネットワーク
３ サーバ装置
３０１ 適用対象パッチ情報登録部
３０２ 適用失敗候補グループ作成部
３０３ 優先適用端末決定部
３０４ パッチ配信部
３０５ 適用結果取得部
３０６ 失敗原因取得部
３０７ 失敗条件候補登録部
３０８ インベントリ収集指示部
３１１ パッチ詳細情報ＤＢ
３１２ インベントリＤＢ
３１３ 失敗条件候補ＤＢ
３１４ 適用失敗候補グループＤＢ
３１５ 適用履歴ＤＢ
３１６ 利用者業務特性ＤＢ
３１７ 適用成功時動作傾向ＤＢ
３１８ 適用失敗時動作傾向ＤＢ
４ ネットワーク
５ クライアント端末
５０１ パッチ受信部
５０２ 適用指示状態変更部
５０３ パッチ適用動作制御部
５０４ パッチ適用部
５０５ 適用結果通知部
５０６ インベントリ収集部
５０７ パッチ適用指示状態データ

Claims (9)

1. ソフトウェアの更新プログラムを受け付けると、更新プログラムの適用エラーの原因に関する情報を該更新プログラムに対応付けて記憶する記憶部を参照して、受け付けた前記更新プログラムに対応付けられた適用エラーの原因に関する情報を取得し、
   情報処理装置のインベントリ情報を該情報処理装置に対応付けて記憶する記憶部を参照して、複数の情報処理装置にそれぞれ対応付けられた複数のインベントリ情報を取得し、
   取得した前記複数のインベントリ情報と、取得した前記適用エラーの原因に関する情報とに基づき、前記複数の情報処理装置のうち、受け付けた前記更新プログラムの適用エラーが生じる情報処理装置の候補群を推定し、
   推定した前記候補群に含まれる情報処理装置に、受け付けた前記更新プログラムの適用を許可することを示す情報を送信する、
   処理をコンピュータに実行させることを特徴とする適用支援プログラム。
2. 推定した前記候補群に含まれる情報処理装置の一部に、受け付けた前記更新プログラムの適用を許可することを示す情報を送信する、
   ことを特徴とする請求項１に記載の適用支援プログラム。
3. 前記一部の情報処理装置が前記更新プログラムの適用を所定の時間にわたって実施しない場合、前記一部の情報処理装置について前記更新プログラムの適用を許可を取り消し、前記候補群に含まれる他の情報処理装置に前記更新プログラムの適用を許可する、
   ことを特徴とする請求項２に記載の適用支援プログラム。
4. 前記一部の情報処理装置が前記更新プログラムの適用に成功した場合、前記候補群に含まれる他の情報処理装置に前記更新プログラムの適用を許可することを示す情報を送信する、
   ことを特徴とする請求項２に記載の適用支援プログラム。
5. 更新プログラムの適用に関する対応の迅速さを情報処理装置に対応付けて記憶する記憶部を参照して、推定した前記情報処理装置の候補群のうち、更新プログラムの適用に関する対応の迅速さが基準を満たす情報処理装置を特定し、
   特定した前記情報処理装置に、受け付けた前記更新プログラムの適用を許可することを示す情報を送信する、
   ことを特徴とする請求項２乃至４のいずれか一項に記載の適用支援プログラム。
6. 更新プログラムの適用に関する時間帯毎の実施傾向を情報処理装置に対応付けて記憶する記憶部を参照して、推定した前記情報処理装置の候補群のうち、更新プログラムを配布する時間帯における実施傾向が基準を満たす情報処理装置を特定し、
   特定した前記情報処理装置に、受け付けた前記更新プログラムの適用を許可することを示す情報を送信する、
   ことを特徴とする請求項２乃至５のいずれか一項に記載の適用支援プログラム。
7. ソフトウェアの起動回数を情報処理装置に対応付けて記憶する記憶部を参照して、推定した前記情報処理装置の候補群のうち、受け付けた前記更新プログラムにかかるソフトウェアの起動回数が基準よりも少ない情報処理装置を特定し、
   特定した前記情報処理装置に、受け付けた前記更新プログラムの適用を許可することを示す情報を送信する、
   ことを特徴とする請求項２乃至６のいずれか一項に記載の適用支援プログラム。
8. ソフトウェアの更新プログラムを受け付けると、更新プログラムの適用エラーの原因に関する情報を該更新プログラムに対応付けて記憶する記憶部を参照して、受け付けた前記更新プログラムに対応付けられた適用エラーの原因に関する情報を取得する手段と、
   情報処理装置のインベントリ情報を該情報処理装置に対応付けて記憶する記憶部を参照して、複数の情報処理装置にそれぞれ対応付けられた複数のインベントリ情報を取得する手段と、
   取得した前記複数のインベントリ情報と、取得した前記適用エラーの原因に関する情報とに基づき、前記複数の情報処理装置のうち、受け付けた前記更新プログラムの適用エラーが生じる情報処理装置の候補群を推定する手段と、
   推定した前記候補群に含まれる情報処理装置に、受け付けた前記更新プログラムの適用を許可することを示す情報を送信する手段と、
   を備えたことを特徴とする適用支援装置。
9. ソフトウェアの更新プログラムを受け付けると、更新プログラムの適用エラーの原因に関する情報を該更新プログラムに対応付けて記憶する記憶部を参照して、受け付けた前記更新プログラムに対応付けられた適用エラーの原因に関する情報を取得し、
   情報処理装置のインベントリ情報を該情報処理装置に対応付けて記憶する記憶部を参照して、複数の情報処理装置にそれぞれ対応付けられた複数のインベントリ情報を取得し、
   取得した前記複数のインベントリ情報と、取得した前記適用エラーの原因に関する情報とに基づき、前記複数の情報処理装置のうち、受け付けた前記更新プログラムの適用エラーが生じる情報処理装置の候補群を推定し、
   推定した前記候補群に含まれる情報処理装置に、受け付けた前記更新プログラムの適用を許可することを示す情報を送信する、
   処理をコンピュータが実行することを特徴とする適用支援方法。

Images