(57)【要約】【課題】  コンピュータシステムの問題発生のリスクに応じてサポートサービス料金を変動させることにより，適切な料金体系を提供すること。【解決手段】  ユーザシステムのシステム構成情報をユーザＤＢに登録し，そのシステム構成情報から問題発生のリスクをワーニング情報ＤＢに登録された情報をもとに分析し，分析されたリスクをもとにサポートサービス料金を算出し，ユーザシステムに対するワーニング情報やサポートサービス料金をユーザに通知する。その結果、問題発生のリスクの高いシステムに対して，割高なサポートサービス料金を設定でき、ユーザが割高な料金を嫌うことによって，リスクの小さい，より安定したシステムへの移行を促すことができる。【選択図】  図１
2005099974.tif 000002
【特許請求の範囲】
【請求項１】
情報採取ツールを使って採取したユーザシステムのシステム構成情報をユーザＤＢに登録するユーザＤＢ登録部，パッチの作成元などから入手したパッチ情報をもとにパッチの重要度を判定し，その判定結果をワーニング情報ＤＢに登録するワーニング情報ＤＢ更新部，ユーザシステムのシステム構成情報をもとにユーザシステムで問題が発生するリスクを分析し数値化したり，ユーザシステムに対するワーニング情報をユーザＤＢに登録するリスク分析部，数値化されたリスクをもとにサポートサービス料金を算出する料金算出部、ユーザシステムに対するワーニング情報やサポートサービス料金をユーザに通知するための顧客通知部，ユーザのサポートサービス契約情報やユーザシステムの情報を保管するためのデータベースであるユーザＤＢ，パッチの作成元が公開した全てのパッチの情報を保管するためのデータベースであるワーニング情報ＤＢを備えることを特徴とするリスクに応じて変動するサポートサービス料金設定システム。
【請求項２】
情報採取ツールを使って採取したユーザシステムのシステム構成情報がベンダに送付されることを契機に，ベンダにおいてユーザシステムで問題が発生するリスクを分析し，その分析したリスクをもとにサポートサービス料金を算出し，ユーザにワーニング情報とともにサポートサービス料金を通知することを特徴とするサポートサービス料金設定方法。
【請求項３】
一定期間ごとに，ベンダにおいてユーザシステムのシステム構成情報からユーザシステムで問題が発生するリスクを分析し，その分析したリスクをもとにサポートサービス料金を算出し，ユーザにワーニング情報とともにサポートサービス料金を通知することを特徴とするサポートサービス料金設定方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は，コンピュータシステムのサポートサービスにおいて，システムが抱えている問題発生のリスクを判定後，そのリスクに応じて変動するサポートサービス料金を算出し，ユーザにワーニング情報とサポートサービス料金を提示する方法およびそのシステムに関する。
【背景技術】
【０００２】
コンピュータシステムのユーザ，特に企業ユーザは，サポートサービスベンダから有償のサポートサービスを受けている。一般のサポートサービスの料金には，一定期間は定額の料金体系や，サポートサービスを受けるたびに料金が発生する料金体系などがあるが，いずれにせよ，サポート対象の製品やサポートの内容の準じて均一の料金となっている。
【０００３】
また，サポートサービスの利用率に応じて料金が変動するといった公知例も存在する（特許文献１を参照）。
【０００４】
【特許文献１】特開２００２−１０９４０２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
サポートサービスを頻繁に利用するユーザとしては，システムに潜在的な問題を抱えている場合や，ユーザのシステムに対する技術レベルが低い場合などが挙げられる。
【０００６】
頻繁にサポートサービスを利用するユーザに対しては，従来の均一の料金体系ではなく，特許文献１に示す公報によって，サポートサービスの利用率に応じた料金を設定することにより，適正な料金体系をとることが可能である。
【０００７】
しかしながら，システムに潜在的な問題を抱えている場合については，従来の均一の料金体系や特許文献１に示す公報の料金体系では対応しきれていない。
【０００８】
例えば，システム構成の変更を嫌うユーザは意外と多く，重要な問題を修正したパッチの適用を先送りしてしまう場合がある。この場合，現時点では問題は顕在化していないものの，将来的に問題が発生する可能性を秘めており，このようなシステムは問題発生のリスクが高いといえる。
【０００９】
従来のサポートサービスの料金体系では，問題発生のリスクの高低に関わらず，均一の料金となっており，問題発生のリスクに応じた料金体系は全く考慮されていなかった。問題発生のリスクの高いシステムを持つユーザは，将来的にサポートサービスを利用する可能性が高いことから，ユーザとベンダの双方にとって，従来のサポートサービス料金体系は適正であるとは言えなかった。
【００１０】
本発明の目的は，上記問題を解決するものであり，問題発生のリスクに応じてサポートサービス料金を変動させることにより，適切な料金体系を提供することにある。
【課題を解決するための手段】
【００１１】
上記目的を達成するため，第１の発明は，ユーザが情報採取ツールを使って採取したユーザシステムのシステム構成情報をユーザＤＢに登録するユーザＤＢ登録部，パッチの作成元などから入手したパッチ情報をもとにパッチの重要度を判定し，その判定結果をワーニング情報ＤＢに登録するワーニング情報ＤＢ更新部，ユーザシステムのシステム構成情報をもとにユーザシステムで問題が発生するリスクを分析し数値化したり、ユーザシステムに対するワーニング情報をユーザＤＢに登録するリスク分析部、数値化されたリスクをもとにサポートサービス料金を算出する料金算出部，ユーザシステムに対するワーニング情報やサポートサービス料金をユーザに通知するための顧客通知部，ユーザのサポートサービス契約情報やユーザシステムの情報を保管するためのデータベースであるユーザＤＢ，パッチの作成元が公開した全てのパッチの情報を保管するためのデータベースであるワーニング情報ＤＢを備えることを特徴とする。
【００１２】
第２の発明は，ユーザが情報採取ツールを使って採取したユーザシステムのシステム構成情報をベンダに送付することを契機に，ベンダにおいてユーザシステムで問題が発生するリスクを分析し，その分析したリスクをもとにサポートサービス料金を算出し，ユーザにワーニング情報とともにサポートサービス料金を通知することを特徴とする。
【００１３】
第３の発明は，一定期間ごとに，ベンダにおいてユーザシステムのシステム構成情報からユーザシステムで問題が発生するリスクを分析し，その分析したリスクをもとにサポートサービス料金を算出し，ユーザにワーニング情報とともにサポートサービス料金を通知することを特徴とする。
【発明の効果】
【００１４】
本発明によれば，問題発生のリスクの高いシステムに対して，割高なサポートサービス料金を設定することが可能となり，ユーザが割高な料金を嫌うことによって，リスクの小さい，より安定したシステムへの移行を促すことができる。ベンダとしては，ユーザのシステムで発生する問題のリスクが下がることにより，ユーザからのサポートサービスの利用が減少し，コスト削減の効果がある。
【発明を実施するための最良の形態】
【００１５】
以下，発明を実施するための最良の形態を図面により説明する。
【００１６】
（構成の説明）
図１〜図３を用いて，本発明のシステム構成を説明する。
【００１７】
図１は，リスクに応じたサポートサービス料金を設定するためのシステム全体の構成例である。ベンダ１０１は，ユーザＤＢ更新部１０２，ワーニング情報ＤＢ更新部１０３，リスク分析部１０４，料金算出部１０５，顧客通知部１０６の５つの処理部と，ユーザＤＢ１０７，ワーニング情報ＤＢ１０８の２つのＤＢで構成される。ユーザ１１０は，サポートサービスを新規に契約したとき，またはユーザシステム１１１のシステム構成を変更したとき，情報採取ツール１１２を実行することによりユーザシステム１１１のシステム構成情報を採取し，ベンダ１０１へ送付する。ベンダ１０１に送付されたシステム構成情報は，ユーザＤＢ更新部１０２によってユーザＤＢ１０７に登録される。これについては，のちほど図６を用いて詳述する。ユーザＤＢ１０７が更新されるか，もしくは一定期間ごとに，リスク分析部１０４によって，ユーザシステムの問題発生のリスクを判定する。これについては，のちほど図８を用いて詳述する。料金算出部１０５では，リスク分析部１０４で判定したリスクをもとにサポートサービス料金を算出する。これについては，のちほど図９を用いて詳述する。算出された料金は，顧客通知部１０６によって，ワーニング情報・料金表１０９としてユーザ１１０に送付される。これについては，のちほど図１０を用いて詳述する。ユーザ１１０は，ベンダ１０１から受け取ったワーニング情報・料金表１０９をもとに，システムに必要とされるパッチを適用することで，システムの安定性を高めることができる。ワーニング情報ＤＢ更新部１０３では，情報源サーバ１１３から入手したパッチ情報をもとに，パッチの重要度を判定し，その結果をワーニング情報ＤＢ１０８に登録する。これについては，のちほど図７を用いて詳述する。
【００１８】
ユーザＤＢ１０７は，ユーザ情報を管理するためのデータペースである。図２は，ユーザＤＢの内容の例を示した図である。ユーザＤＢの内容は，ユーザに対して一意に割り当てられる顧客番号２０１，顧客名２０２，ユーザがサポートサービスを契約した年月日である契約開始日２０３，サポートサービスの契約が満了する年月日である契約満了日２０４，情報採取ツール１１２によって採取されたユーザシステム１１１のシステム構成情報を保管するシステム構成情報２０５，リスク分析部１０４によって判定されたユーザシステムのリスク判定結果２０６，リスク分析部１０４によって判定されたユーザシステムのワーニング情報リスト２０７，現サポートサービス契約期間中に適用される今期サポート料金２０８，次期サポートサービス期間に適用が想定される次期サポート料金２０９で構成される。システム構成情報２０５の内容の例として，機種名２１０，ＯＳバージョン２１１，搭載ソフトウェア一覧２１２，適用済みパッチ一覧２１３で構成される。ワーニング情報リスト２０７の内容の例として，ユーザシステムに適用が必要とされるパッチの一覧である適用すべきパッチ一覧２１４で構成される。
【００１９】
ワーニング情報ＤＢ１０８は，パッチの作成元が公開した全てのパッチの情報を管理するためのデータベースである。図３は，ワーニング情報ＤＢの例を示した図である。ワーニング情報ＤＢの内容は，パッチを一意に識別するためのパッチ番号３０１，パッチが適用可能な機種３０２，パッチが適用可能なＯＳバージョン３０３，パッチと依存関係にある依存ソフトウェア３０４，パッチ番号３０１が既に公開済みのパッチを置換する場合その置換されたパッチ番号３０５，パッチの種類を識別するカテゴリ３０６，パッチが公開された年月日である公開日３０７，パッチの作成元がパッチの適用を推奨する度合いである適用の推奨度３０８，ワーニング情報ＤＢ更新部１０３によってパッチの重要度の判定結果を保管する重要度（判定結果）３０９で構成される。
【００２０】
（動作の説明）
図４〜図１２を用いて，本発明の動作の流れを説明する。
【００２１】
図６は，ベンダ１０１がユーザ１１０からシステム構成情報を受け取った後に，ユーザＤＢ１０７を更新するユーザＤＢ更新部１０２の処理の流れを示したフローチャートである。ユーザＤＢ更新部１０２は，情報採取ツール１１２で採取されたシステム構成情報を受け取ると（ステップ１００１），ユーザＤＢ１０７のシステム構成情報２０５を更新し（ステップ１００２），処理を終了する。
【００２２】
図７は，ワーニング情報ＤＢを更新するワーニング情報ＤＢ更新部１０３の処理の流れを示したフローチャートである。まず，情報源サーバ１１３からパッチ情報を入手する（ステップ２００１）。パッチ情報の入手の方法は，定期的または不定期に情報源サーバ１１３からパッチ情報をダウンロードするか，定期的または不定期に情報源サーバ１１３からパッチ情報が配信されるのを待機する方法がある。パッチ情報を入手後，図４で示す重要度判定テーブルをもとに，重要度を計算する（ステップ２００２）。図４の重要度判定テーブルのサンプルでは，重要度を判定するための材料としてカテゴリ，パッチが公開されてからの経過日数，パッチの適用の推奨度の３つの項目について，あらかじめ重要度を設定し，テーブルとして用意しておく。これらの３つの項目は，ワーニング情報ＤＢ１０８のカテゴリ３０６，公開日３０７，適用の推奨度３０８に対応しており，３つの項目の重要度の総和をそのパッチの重要度として計算する。例えば，あるパッチのカテゴリがCritical（重要度１０），パッチが公開されてからの経過日数が３０日以内（重要度３），適用の推奨度が高（重要度７）であった場合，図４の重要度判定テーブルをもとにパッチの重要度を計算すると，そのパッチの重要度は２０となる。最後に，パッチ情報と計算した重要度をワーニング情報ＤＢ１０８に登録し（ステップ２００３），処理を終了する。
【００２３】
図８は，ユーザＤＢ１０７のシステム構成情報２０５が更新された後，またはサポートサービスの契約開始から一定期間が経過したときに実行されるリスク分析部１０４の処理の流れを示したフローチャートである。まず，ユーザＤＢ１０７の各ユーザのシステム構成情報２０５が更新されているか，もしくは，契約開始日２０３から一定期間が経過しているかを確認する（ステップ３００１）。サポートサービスの契約開始日から全くシステム構成情報が更新されない場合でも，ワーニング情報ＤＢ１０８の内容は日々更新され続けているので，一定期間ごとにリスク分析を実施する必要がある。システム構成情報２０５が更新されていない，もしくは，契約開始日２０３から一定期間が経過していない場合は，処理を終了する。システム構成情報２０５が更新されている，もしくは，契約開始日２０３から一定期間が経過している場合は，ワーニング情報ＤＢ１０８から更新されたユーザのシステム要件に一致するパッチを抽出し，システムに適用されているべきパッチ（推奨パッチ）のリストを作成する（ステップ３００２）。
【００２４】
具体的には，ユーザＤＢ１０７に登録されている機種名２１０，ＯＳバージョン２１１，搭載ソフトウェア一覧２１２の情報をもとに，ワーニング情報ＤＢ１０８に登録されている適用機種３０２，ＯＳバージョン３０３，依存ソフトウェア３０４に一致するパッチを抽出し，推奨パッチリストを作成する。推奨パッチリストの作成後，推奨パッチリストから１個の推奨パッチ情報を取り出し，ユーザシステムに推奨パッチが適用済みであるかを確認する（ステップ３００３）。具体的には，ユーザＤＢ１０７の適用済みパッチ一覧２１３に推奨パッチが登録されているかを確認する。推奨パッチが適用済みであればステップ３００９に進む。推奨パッチが適用済みでない場合は，推奨パッチが過去に公開されたパッチを置換するパッチであるかを確認する（ステップ３００４）。
【００２５】
具体的には，ワーニング情報ＤＢ１０８の置換されたパッチ番号３０５にパッチ番号があるかどうかを確認する。置換されたパッチ番号３０５にパッチ番号が登録されていない場合，推奨パッチは，過去に公開されたパッチを置き換えるパッチではなく，新たな問題の修正や新機能の追加などが行われたパッチであることを意味する。置換されたパッチ番号３０５にパッチ番号が登録されている場合，推奨パッチは，置換されたパッチ番号３０５を置き換える後継のパッチであることを意味する。推奨パッチが過去に公開されたパッチを置換するパッチではない場合は，ステップ３００７に進む。推奨パッチが過去に公開されたパッチを置換するパッチである場合は，推奨パッチによって置換されたパッチが適用済みであるかを確認する（ステップ３００５）。
【００２６】
具体的には，ユーザＤＢ１０７の適用済みパッチ一覧２１３に置換されたパッチが登録されているかを確認する。置換されたパッチが適用済みでなければステップ３００７に進む。置換されたパッチが適用済みである場合は，推奨パッチの重要度３０９と置換されたパッチの重要度３０９を比較する（ステップ３００６）。推奨パッチのほうが置換されたパッチの重要度よりも低い，もしくは重要度が同じであれば，ステップ３００９へ進む。推奨パッチのほうが置換されたパッチよりも重要度が高ければ，ステップ３００７に進む。ステップ３００７では，ユーザＤＢ１０７のワーニング情報リスト２０７の適用すべきパッチ一覧２１４に，推奨パッチの番号を登録する。その後，推奨パッチの重要度を累積し（ステップ３００８），ステップ３００９へ進む。なお，推奨パッチの重要度の累積値の初期値は０である。ステップ３００９では，推奨パッチリストの末尾であるかを確認し，末尾ではない場合は，ステップ３００３に戻る。全ての推奨パッチリストのチェックが終わった場合は，ステップ３０１０に進む。ステップ３０１０では，ステップ３００８で累積した重要度をリスク判定結果としてユーザＤＢ１０７のリスク判定結果２０６に登録し，処理を終了する。
【００２７】
図９は，ユーザＤＢ１０７のリスク判定結果２０６が更新されたあとに実行される料金算出部１０５の処理の流れを示したフローチャートである。まず，ユーザＤＢ１０７の各ユーザのリスク判定結果２０６が更新されているかを確認し（ステップ４００１），更新されていない場合は，処理を終了する。更新されている場合は，図５で示す料金テーブルをもとに，割増率を決定する（ステップ４００２）。図５の料金テーブルのサンプルでは，あらかじめ，リスク判定結果の数値に応じて割増率を設定し，テーブルとして用意しておく。このテーブルは，ユーザＤＢ１０７のリスク判定結果２０６と対応しており，例えば，リスク判定結果が１５０であれば，割増率は５％となる。ステップ４００３では，サポート対象の製品はサポート内容によって定められた通常のサポート料金に対して，ステップ４００２によって決定された割増率を乗じた金額を，ユーザＤＢ１０７の次期サポート料金２０９に登録し，処理を終了する。このようにして，リスク判定結果に応じた料金テーブルを用意することにより，問題発生のリスクの高いシステムには，割高な料金設定を行うことができる。
【００２８】
図１０は，ユーザＤＢ１０７のワーニング情報リスト２０７または次期サポート料金２０９が更新された後，またはサポートサービスの契約開始から一定期間が経過したときに実行される顧客通知部１０６の処理の流れを示したフローチャートである。まず，ユーザＤＢ１０７の各ユーザのワーニング情報リスト２０７または次期サポート料金２０９が更新されているか，もしくは，契約開始日２０３から一定期間が経過しているかを確認する（ステップ５００１）。ワーニング情報リスト２０７または次期サポート料金２０９が更新されていない，もしくは，契約開始日２０３から一定期間が経過していない場合は，処理を終了する。ワーニング情報リスト２０７または次期サポート料金２０９が更新されている，もしくは，契約開始日２０３から一定期間が経過している場合は，ステップ５００２に進む。ステップ５００２では，新規ユーザであるかどうかを確認し，新規ユーザであればステップ５００５に進む。新規ユーザではない場合は，ステップ５００３に進む。ステップ５００３では，契約満了日２０４をまもなく迎えるかを確認する。契約満了日に近い場合は，ステップ５００５へ進む。契約満了日がまだ先の場合は，ステップ５００４に進む。ステップ５００４では，サポートサービス期間内のユーザに対して，ワーニング情報を通知することを目的として，ワーニング情報・料金表１０９を作成し，ユーザに送付後，処理を終了する。ワーニング情報を通知することを目的としたワーニング情報・料金表のサンプルを図１１に示す。
【００２９】
図１１のように，問題発生のリスクの高いシステムに対しては，パッチの適用を促すメッセージとともに，パッチを適用しない場合の割高な次期サポートサービス料金を通知することができる。ステップ５００５，ステップ５００６の処理は，新規ユーザおよび契約満了日が近いユーザのための処理を行う。ステップ５００５では，ユーザＤＢ１０７の次期サポート料金２０９に登録されている料金を今期サポート料金２０８にコピーする。その後，ステップ５００６では，サポートサービス料金を通知することを目的として，ワーニング情報・料金表１０９を作成し，ユーザに送付後，処理を終了する。サポートサービス料金を通知することを目的としたワーニング情報・料金表のサンプルを図１２に示す。
【図面の簡単な説明】
【００３０】
【図１】本発明のシステム全体の構成図である。
【図２】ユーザＤＢの内容を示した図である。
【図３】ワーニング情報ＤＢの内容を示した図である。
【図４】重要度判定テーブルのサンプルである。
【図５】料金テーブルのサンプルである。
【図６】ユーザＤＢの更新処理の流れを示すフローチャートである。
【図７】ワーニング情報ＤＢの更新処理の流れを示すフローチャートである。
【図８】リスク分析処理の流れを示すフローチャートである。
【図９】料金算出処理の流れを示すフローチャートである。
【図１０】ユーザにワーニング情報と料金を通知する処理の流れを示すフローチャートである。
【図１１】ワーニング情報を通知することを目的とした，ワーニング情報兼料金表のサンプルである。
【図１２】料金を通知することを目的とした，ワーニング情報兼料金表のサンプルである。
【符号の説明】
【００３１】
１０１：ベンダ、１０２：ユーザＤＢ更新部、１０３：ワーニング情報ＤＢ更新部、
１０４：リスク分析部、１０５：料金算出部、１０６：顧客通知部、１０７：ユーザＤＢ、１０８：ワーニング情報ＤＢ、１０９：ワーニング情報ＤＢ更新部、１１０：ユーザ、１１１：ユーザシステム、１１２：情報採取ツール、１１３：情報源サーバ
【図１】
2005099974.tif 000003
【図２】
2005099974.tif 000004
【図３】
2005099974.tif 000005
【図４】
2005099974.tif 000006
【図５】
2005099974.tif 000007
【図６】
2005099974.tif 000008
【図７】
2005099974.tif 000009
【図８】
2005099974.tif 000010
【図９】
2005099974.tif 000011
【図１０】
2005099974.tif 000012
【図１１】
2005099974.tif 000013
【図１２】
2005099974.tif 000014