(57)【要約】【課題】利用者の操作履歴に関する評価値の情報をサーバが持っていない場合でも、そのサーバが、その利用者の他のサーバでの操作履歴に応じた評価値の情報に基づき、その利用者からの要求に応じて行う処理を制御できるようにする。【解決手段】サーバＡは、利用者からアクセスを受けた場合。サーバＢに対して認証を要求する（Ｓ４、Ｓ５）。この要求を受けたサーバＢは、その利用者の認証アサーションと評価値をサーバＡに提供する（Ｓ６，Ｓ７）。サーバＡは、認証アサーションをチェックして、その利用者のログインの可否を判定する（Ｓ８）。またサーバＡは、その利用者の自サーバでの操作履歴に基づき求めた評価値が自サーバ内に記憶されていればその評価値を用いて、相でなければステップＳ７でサーバＢから取得した評価値に基づき、その利用者に提供するサービス内容を判定する（Ｓ９）。【選択図】図７
2008257434.tif 000002
【特許請求の範囲】
【請求項１】
各利用者の自サーバでの操作履歴に基づく評価値を記憶する評価値記憶手段と、
利用者からの処理要求に応じて、第２のサーバから、前記利用者の前記第２のサーバでの操作履歴に基づく評価値を取得する取得手段と、
前記利用者からの処理要求に対して前記利用者の評価値に応じた処理を実行する処理実行手段であって、前記利用者の評価値が前記評価値記憶手段から取得できる場合は、前記評価値記憶手段から取得した前記利用者の評価値に応じた処理を実行し、前記利用者の評価値が前記評価値記憶手段から取得できない場合は、前記取得手段が前記第２のサーバから取得した前記利用者の評価値に応じた処理を実行する処理実行手段と、
を備えるサーバ。
【請求項２】
サーバの信頼度ごとに、当該信頼度のサーバにおける利用者の評価値を自サーバにおける評価値へと換算する換算情報を記憶した換算情報記憶手段と、
前記第２のサーバの信頼度を判定する信頼度判定手段と、
前記取得手段が前記第２のサーバから取得した前記利用者の評価値を、前記第２のサーバの信頼度に対応する換算情報に基づき自サーバにおける評価値に換算する換算手段と、
を更に備え、
前記処理実行手段は、前記利用者の評価値が前記評価値記憶手段から取得できない場合は、前記換算手段による換算結果の評価値に応じた処理を実行する、
ことを特徴とする請求項１記載のサーバ。
【請求項３】
前記信頼度判定手段は、前記取得手段が取得した各利用者の前記第２のサーバでの評価値と、前記評価値記憶手段に記憶されたそれら各利用者の評価値との差異に基づき、前記第２のサーバの信頼度を判定する、
ことを特徴とする請求項２記載のサーバ。
【請求項４】
コンピュータに、
各利用者の自サーバでの操作履歴に基づく評価値を評価値記憶手段に記憶させるステップと、
利用者からの処理要求に応じて、第２のサーバから、前記利用者の前記第２のサーバでの操作履歴に基づく評価値を取得するステップと、
前記利用者からの処理要求に対して前記利用者の評価値に応じた処理を実行するステップであって、前記利用者の評価値が前記評価値記憶手段から取得できる場合は、前記評価値記憶手段から取得した前記利用者の評価値に応じた処理を実行し、前記利用者の評価値が前記評価値記憶手段から取得できない場合は、前記第２のサーバから取得した前記利用者の評価値に応じた処理を実行するステップと、
を実行させるためのプログラム。
【請求項５】
第１のサーバと第２のサーバとを含み、
前記第１のサーバは、
各利用者の前記第１のサーバでの操作履歴に基づく評価値を記憶する第１の評価値記憶手段と、
利用者からの処理要求に応じて、第２のサーバから、前記利用者の前記第２のサーバでの操作履歴に基づく評価値を取得する取得手段と、
前記利用者からの処理要求に対して前記利用者の評価値に応じた処理を実行する処理実行手段であって、前記利用者の評価値が前記第１の評価値記憶手段から取得できる場合は、前記第１の評価値記憶手段から取得した前記利用者の評価値に応じた処理を実行し、前記利用者の評価値が前記第１の評価値記憶手段から取得できない場合は、前記取得手段が前記第２のサーバから取得した前記利用者の評価値に応じた処理を実行する処理実行手段と、
を備え、
前記第２のサーバは、
各利用者の前記第２のサーバでの操作履歴に基づく評価値を記憶する第２の評価値記憶手段と、
利用者からの前記第１のサーバに対する処理要求に応じて、前記第２の評価値記憶手段に記憶された前記利用者の評価値を前記第１のサーバへ提供する評価値提供手段と、
を備える、情報処理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サーバ及び情報処理システムに関する。
【背景技術】
【０００２】
ネットワーク上には、利用者にサービスを提供するサーバ（或いはサービスプロバイダ）が数多く存在する。例えば、Ｗｅｂサービスを提供するサーバがその一例である。従来、これらのサーバは、それぞれ個別に利用者のアカウントや個人情報を管理している。利用者が複数のサーバからサービスを受けようとすれば、それら各サーバにそれぞれログインする必要があった。
【０００３】
近年では１回のログインでネットワーク上の複数のサーバにアクセスできるようにするシングル・サインオンのシステムが提案されている。このシングル・サインオンの実現のために様々な技術が開発され、標準仕様の策定のための取り組みもなされている。例えば、リバティ・アライアンスがその一例である。
【０００４】
一般的なシングル・サインオンのシステムでは、登録されている利用者は信頼できるものとして扱うため、別のサーバはその利用者のログインを認めることになる。
【０００５】
また、単一のサーバごとのセキュリティ管理として、サーバ内での利用者の挙動を評価し、不正アクセスなどの望ましくない挙動があった場合に、その挙動を行った利用者のアカウントをロックするなどの対処を行うことは行われている。
【０００６】
特許文献１には、アカウントＩＤの割り当て要求を受け付けると共に利用者の個人情報を入力して審査し、審査結果がＯＫであればアカウントＩＤの作成と使用要求のあったシステム資源に利用者エントリを登録するアカウント管理システムが開示される。
【０００７】
特許文献２には、個人信用度蓄積開示システムが開示される。このシステムは、個人情報管理部と個人信用度表示部を含み、インターネットの利用者に対し自己の信用度を開示することを希望する会員を集め前記個人情報管理部において各会員の個人情報を蓄積して有料で登録しＩＤ番号とパスワードを応募会員に付与し、前記個人信用度表示部はインターネット上のＷＥＢサーバに開設したホームページを含み、前記応募会員は自己のインターネットのサイト上での関連情報を前記ホームページに登録し、前記関連情報は前記ＩＤ番号とリンクされている会員特定用キーワードを含むように構成したものである。
【０００８】
【特許文献１】特開２００２−２４５０１０号公報
【特許文献２】特開２００２−００７６０１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００９】
サーバが利用者の評価情報を持っていない場合には、そのサーバがその利用者から要求を受けた場合に、その要求に応えてよいか否かが判定できなかった。
【００１０】
本発明は、利用者の評価情報をサーバが持っていない場合でも、そのサーバが、その利用者の他のサーバでの評価情報に基づき、その利用者からの要求に応じて行う処理を制御できるようにするシステムを提供する。
【課題を解決するための手段】
【００１１】
請求項１に係る発明は、各利用者の自サーバでの操作履歴に基づく評価値を記憶する評価値記憶手段と、利用者からの処理要求に応じて、第２のサーバから、前記利用者の前記第２のサーバでの操作履歴に基づく評価値を取得する取得手段と、前記利用者からの処理要求に対して前記利用者の評価値に応じた処理を実行する処理実行手段であって、前記利用者の評価値が前記評価値記憶手段から取得できる場合は、前記評価値記憶手段から取得した前記利用者の評価値に応じた処理を実行し、前記利用者の評価値が前記評価値記憶手段から取得できない場合は、前記取得手段が前記第２のサーバから取得した前記利用者の評価値に応じた処理を実行する処理実行手段と、を備えるサーバである。
【００１２】
請求項２に係る発明は、請求項１に係る発明であって、サーバの信頼度ごとに、当該信頼度のサーバにおける利用者の評価値を自サーバにおける評価値へと換算する換算情報を記憶した換算情報記憶手段と、前記第２のサーバの信頼度を判定する信頼度判定手段と、前記取得手段が前記第２のサーバから取得した前記利用者の評価値を、前記第２のサーバの信頼度に対応する換算情報に基づき自サーバにおける評価値に換算する換算手段と、を更に備え、前記処理実行手段は、前記利用者の評価値が前記評価値記憶手段から取得できない場合は、前記換算手段による換算結果の評価値に応じた処理を実行する、ことを特徴とする。
【００１３】
請求項３に係る発明は、請求項２に係る発明において、前記信頼度判定手段は、前記取得手段が取得した各利用者の前記第２のサーバでの評価値と、前記評価値記憶手段に記憶されたそれら各利用者の評価値との差異に基づき、前記第２のサーバの信頼度を判定する、ことを特徴とする。
【００１４】
請求項４に係る発明は、コンピュータに、各利用者の自サーバでの操作履歴に基づく評価値を評価値記憶手段に記憶させるステップと、利用者からの処理要求に応じて、第２のサーバから、前記利用者の前記第２のサーバでの操作履歴に基づく評価値を取得するステップと、前記利用者からの処理要求に対して前記利用者の評価値に応じた処理を実行するステップであって、前記利用者の評価値が前記評価値記憶手段から取得できる場合は、前記評価値記憶手段から取得した前記利用者の評価値に応じた処理を実行し、前記利用者の評価値が前記評価値記憶手段から取得できない場合は、前記第２のサーバから取得した前記利用者の評価値に応じた処理を実行するステップと、を実行させるためのプログラムである。
【００１５】
請求項５に係る発明は、第１のサーバと第２のサーバとを含み、前記第１のサーバは、各利用者の前記第１のサーバでの操作履歴に基づく評価値を記憶する第１の評価値記憶手段と、利用者からの処理要求に応じて、第２のサーバから、前記利用者の前記第２のサーバでの操作履歴に基づく評価値を取得する取得手段と、前記利用者からの処理要求に対して前記利用者の評価値に応じた処理を実行する処理実行手段であって、前記利用者の評価値が前記第１の評価値記憶手段から取得できる場合は、前記第１の評価値記憶手段から取得した前記利用者の評価値に応じた処理を実行し、前記利用者の評価値が前記第１の評価値記憶手段から取得できない場合は、前記取得手段が前記第２のサーバから取得した前記利用者の評価値に応じた処理を実行する処理実行手段と、を備え、前記第２のサーバは、各利用者の前記第２のサーバでの操作履歴に基づく評価値を記憶する第２の評価値記憶手段と、利用者からの前記第１のサーバに対する処理要求に応じて、前記第２の評価値記憶手段に記憶された前記利用者の評価値を前記第１のサーバへ提供する評価値提供手段と、を備える、情報処理システムである。
【発明の効果】
【００１６】
請求項１、４及び５に係る発明によれば、利用者に関する評価情報をサーバが持っていない場合でも、そのサーバが、その利用者の他のサーバでの評価情報に基づき、その利用者からの要求に応じて行う処理を制御できる。
【００１７】
請求項２に係る発明によれば、信頼度の高いサーバから取得した評価情報と信頼度の低いサーバから取得した評価情報とで、異なった取り扱いをすることができる。
【００１８】
請求項３に係る発明によれば、第２のサーバの各利用者に対する評価情報の差異に基づき、第２のサーバの信頼度を判定することができる。
【発明を実施するための最良の形態】
【００１９】
以下、本発明の実施形態を説明する。本実施形態の情報処理システムは、第１のサーバと第２のサーバとを含む。
【００２０】
第１のサーバは、各利用者の前記第１のサーバでの操作履歴に基づく評価値を記憶する第１の評価値記憶手段と、利用者からの処理要求に応じて、第２のサーバから、前記利用者の前記第２のサーバでの操作履歴に基づく評価値を取得する取得手段と、前記利用者からの処理要求に対して前記利用者の評価値に応じた処理を実行する処理実行手段であって、前記利用者の評価値が前記第１の評価値記憶手段から取得できる場合は、前記第１の評価値記憶手段から取得した前記利用者の評価値に応じた処理を実行し、前記利用者の評価値が前記第１の評価値記憶手段から取得できない場合は、前記取得手段が前記第２のサーバから取得した前記利用者の評価値に応じた処理を実行する処理実行手段と、を備える。
【００２１】
ここで、第１の評価値記憶手段には、第１のサーバでの利用者の操作履歴に基づき、第１のサーバの評価基準に従って判定された当該利用者の評価値が記憶されている。評価値は、例えば、当該利用者の第１のサーバに対するログイン時の操作履歴（例えば、どの端末からいつログインしたかなど）や、ログイン後に当該利用者が第１のサーバに対して行った要求やデータ入力などの操作履歴（例えば、アクセス権のないデータの要求を何度も繰り返すなど）に基づき求められる。評価値記憶手段に記憶される評価値は、第１のサーバを管理する管理者が利用者の操作履歴に基づき判定してもよいし、第１のサーバが備える評価値判定手段が自動的に判定してもよい。後者の場合、評価値を自動判定する評価値判定手段としては、従来から知られているものを用いればよい。第２のサーバからの評価値は、第２のサーバから直接取得してもよいし、利用者の端末を経由して、例えばリダイレクトなどの方法で、取得してもよい。１つの例では、評価値は、リバティ・アライアンス(Liberty Alliance)におけるアイデンティティ連携の枠組みの中で、認証アサーションと対応づけて（例えば認証アサーションのデータの中に組み込まれて）第２のサーバから第１のサーバに提供される。ただし、評価値の受け渡しの方法はこれに限るものではない。
【００２２】
処理実行手段は、利用者からの処理要求に応じて、その利用者の評価値に応じた処理を実行する。例えば、評価値が閾値未満であればログインを認めないという制御がその一例である。また、別の例として、処理実行手段が実行する処理（言い換えれば、利用者に対して提供するサービス）に複数のレベルが設定されており、利用者の評価値に応じたレベルの処理が実行されるようにするという制御も考えられる。本実施形態では、第１のサーバが自分の基準に従って定めた評価値が存在しない場合、第２のサーバから受け取った評価値を利用する。これにより、第１のサーバに利用者の評価値が保持されていない場合に、その利用者の第２のサーバでの評価値に応じた処理が実行される。
【００２３】
一方、第２のサーバは、各利用者の前記第２のサーバでの操作履歴に基づく評価値を記憶する第２の評価値記憶手段と、利用者からの前記第１のサーバに対する処理要求に応じて、前記第２の評価値記憶手段に記憶された前記利用者の評価値を前記第１のサーバへ提供する評価値提供手段と、を備える。
【００２４】
ここで、第２の評価値記憶手段には、第２のサーバの基準に従って判定された各利用者の評価値が記憶されている。評価値提供手段は、例えば、利用者から処理要求を受けた第１のサーバから当該利用者の評価値を要求された場合に、その評価値を第１のサーバに提供する。例えばリバティ・アライアンスの枠組みの場合、第１のサーバが第２のサーバに対して利用者の認証アサーションを要求された場合に、その要求に応じた認証アサーションと共に評価値を提供してもよい。また、別の例として、第２のサーバが、利用者から第１のサーバが提供するサービスを要求された場合に、第１のサーバに対してその要求を伝達する際に、その利用者の評価値を提供するようにしてもよい。評価値は、第１のサーバに対して直接提供してもよいし、（リダイレクトなどの方法で）利用者の端末を介して提供してもよい。
【００２５】
以下、本実施形態の具体例を説明する。以下の具体例は、リバティ・アライアンスの枠組みを利用したものである。ただし、当業者ならば容易に理解できるように、リバティ・アライアンス以外の枠組みを用いたシステムでも、同様の制御は可能である。
【００２６】
図１の示すように、この例の情報処理システムは、インターネット等のデータ通信ネットワーク４００を介して相互に接続可能なサーバＡ１００，サーバＢ２００，及び利用者端末３００を備える。サーバＡ１００は、利用者に対して情報や処理機能などのサービスを提供するサーバ（サービス・プロバイダ：ＳＰ）であり、例えばＷｅｂサーバやＷｅｂアプリケーションサーバ画素の一例である。サーバＢ２００は、リバティ・アライアンスにおけるアイデンティティ・プロバイダ（ＩＤＰ）の役割を果たすサーバである。すなわち、この例では、サーバＡ１００とサーバＢ２００とは、リバティ・アライアンスにおける同一のトラストサークルに属しており、サーバＢ２００は、リバティ・アライアンスの枠組みにしたがって、サーバＡ１００を利用しようとする利用者の認証を行う。なお、サーバＢ２００が、利用者に対してサービスを提供するサービス・プロバイダの役割を担ってもよい。利用者端末３００は、利用者が操作するコンピュータであり、サーバＡ１００からサービスを受けるため必要なソフトウエア（例えばＷｅｂブラウザや各種の通信プロトコル）を備える。
【００２７】
図１では、サーバＡ１００，サーバＢ２００，及び利用者端末３００をそれぞれ１つずつしか示さなかったが、ネットワーク４００上にそれらがそれぞれ複数存在していてもよい。１つのトラストサークルの中にＩＤＰが複数存在してもよい。
【００２８】
次に、図２を参照して、サーバＡ１００の詳細な機能構成の一例を説明する。図示のように、サーバＡ１００は、サービス提供部１１０，監視部１２０，認証処理部１３０及び記憶装置１５０を備える。
【００２９】
サービス提供部１１０は、利用者に対するサービス（例えば情報や処理機能の提供）を行うための機能モジュールである。例えば、Ｗｅｂサーバ機能やアプリケーションサーバ機能がその一例である。本実施形態の評価値に基づくサービス提供の制御は、サービス提供部１１０が提供するサービスの内容には直接依存しないので、サービス提供部１１０についての詳細な説明は省略する。
【００３０】
監視部１２０は、サービス提供部１１０及び認証処理部１３０等の各機能モジュールに対する利用者の操作履歴（例えば利用者からの入力の内容や、利用者がその入力に用いた環境の情報など）を監視し、その監視結果に応じて利用者の当該サーバＡ１００における操作履歴についての評価値を生成し、更新する。監視部１２０は、サービス提供部１１０及び認証処理部１３０において、例えば図３に列挙するような利用者の操作履歴を監視し、監視によって検出した操作履歴に従って当該利用者の評価値を算出したり、更新したりする。図３には、セキュリティ上のリスクがある操作履歴、即ち評価値を下げる方向の操作履歴のみが列挙されるが、評価値を上げる方向の操作履歴があってももちろんよい。図３に列挙された各操作履歴には、例えば点数（点数に正負があってもよい）が規定されており、検出した操作履歴に対応する点数に応じて当該利用者の評価値を求める。なお、このような操作履歴に基づく評価値の算出アルゴリズムには従来から様々なものがあり、監視部１２０はそのような従来のアルゴリズムを用いればよい。監視部１２０が計算又は更新した利用者の評価値は、記憶装置１５０の利用者評価値テーブル１５４に記憶される。
【００３１】
認証処理部１３０は、利用者の認証のための各種処理を担当する。認証処理部１３０は、認証部１３２，サービス判定部１３４及び連携処理部１４０を有する。認証部１３２は、サーバＡ１００単体での利用者認証処理を実行する。認証部１３２が行う利用者認証は、ユーザＩＤ（識別情報）とパスワードの組合せによるパスワード認証や、デジタル証明書を用いた認証、指紋等の生体情報を用いた生体認証など、従来からある認証方法を用いるものでよい。リバティ・アライアンスは、個々のＩＤＰ、ＳＰが行う認証方式に依存するものではないので、どのような方式を用いてもよい。
【００３２】
サービス判定部１３４は、利用者に提供するサービスの内容（サービスのレベルや種類など）を、利用者の評価値に応じて判定する。評価値に基づくサービス内容の判定技術は従来から各種知られており、サービス判定部１３４はそれら従来の技術をもちいるものでよい。
【００３３】
連携処理部１４０は、リバティ・アライアンスにおけるアイデンティティ連携のための処理を実行する。この例では、サーバＡ１００はＳＰ（サービス・プロバイダ）なので、ＩＤＰ（アイデンティティ・プロバイダ）であるサーバＢ２００から利用者の認証情報（認証アサーション）を求めることになる。認証情報取得部１４２は、そのような認証情報の取得のための処理を行う。また、評価値取得部１４４は、サーバＢ２００から利用者の評価値を取得するための処理を行う。この他、連携処理部１４０は、アイデンティティ連携のための各種の処理機能を備えるが、これらについては周知であるので説明を省略する。
【００３４】
記憶装置１５０は、例えばハードディスクなどの不揮発性の記憶装置であり、連携情報テーブル１５２及び利用者評価値テーブル１５４を記憶する。連携情報テーブル１５２は、アイデンティティ連携のための連携情報を保持するテーブルである。連携情報テーブル１５２については、後でその具体例を説明する。利用者評価値テーブル１５４には、監視部２２０が求めた各利用者の評価値が保持される。利用者評価値テーブル１５４のデータ内容の一例を図４に示す。この例では、サーバＡ１００に登録された利用者ごとに、その利用者の利用者名、及び自サーバＡ１００の操作履歴に基づき判定された評価値（図示例では１〜５までの５段階）が登録される。また、利用者評価値テーブル１５４には、サーバＡ１００が連携している他のサーバの評価値を記録してもよい。図示例では、サーバＢ２００での１〜４の４段階の評価値と、その４段階の評価値を自サーバＡ１００の５段階の評価値に合わせるべく正規化した値とが記録されている。
【００３５】
なお、自サーバＡ１００での操作履歴に基づく評価値は、利用者が一度も自サーバＡ１００を利用していない時点では存在しない。また、一度求められた利用者の評価値を規則や利用者の要求等に応じて消去するケースも考えられ、このようなケースではその利用者の評価値はテーブル１５４に存在しない。サービス判定部１３４は、利用者評価値テーブル１５４に、自サーバＡ１００での利用者の評価値が存在する場合には、その利用者に提供するサービスの内容をその評価値を用いて判定し、存在しない場合は、連携先であるＩＤＰ（サーバＢ２００）から取得した評価値に基づきその判定を行う。
【００３６】
次に、図５を参照して、サーバＢ２００の詳細を説明する。サービス提供部２１０は、サービス提供部１１０と同様、利用者に対して情報や処理機能などといったサービスを提供する。監視部２２０は、監視部１２０と同様、サーバＢ２００での利用者の操作履歴を監視し、その監視結果に基づき利用者の評価値を判定して利用者評価値テーブル２５４に記録する。利用者評価値テーブル２５４には、監視部２２０が求めた自サーバＢ２００の評価値の他に、他のサーバ（他のＩＤＰやＳＰ）が求めた評価値を記録してもよい。
【００３７】
認証処理部２３０は、利用者の認証のための各種処理を担当する。認証処理部２３０は、認証部２３２，サービス判定部２３４及び連携処理部２４０を有する。認証部２３２は、認証部１３２と同様、パスワード認証等の基本的な認証処理を行う。サービス判定部２３４は、サービス判定部１３４と同様、利用者評価値テーブル２５４に登録された情報に基づき、利用者に提供するサービス内容を判定する。連携処理部２４０は、アイデンティティ連携のための処理を行う。この例では、サーバＢ２００はＩＤＰとしての役割を果たすので、連携処理部２４０は、連携しているＳＰ（サーバＡ１００）に対して、利用者についての認証アサーションを提供する認証情報提供部２４２を備える。また、連携処理部２４０は、利用者に対する認証アサーションと対応づけて、その利用者の自サーバＢ２００での操作履歴に基づく評価値を提供する評価値提供部２４４を備える。
【００３８】
また、記憶装置２５０は、記憶装置１５０と同様、連携情報テーブル２５２及び利用者評価値テーブル２５４を記憶する。連携情報テーブル２５２は、連携情報テーブル１５２と同様、アイデンティティ連携のための情報を保持する。
【００３９】
ここで、図６を参照して、連携情報テーブル１５２及び２５２に保持される連携情報の具体例を説明する。図６には、同一の利用者について、サーバＡ１００とサーバＢ２００がそれぞれ保持する連携情報を例示する。図６の上側のテーブルはサーバＢ２００が持つその利用者の連携情報を示し、下側のテーブルは同じ利用者についてサーバＡ１００が持つ連携情報を示す。ある利用者についての連携情報には、当該サーバにおけるその利用者のアカウント名と、当該サーバの認証部１３２又は２３２での認証に用いられる認証情報（例えばパスワードなど）と、連携先のＳＰ、ＩＤＰの各々に対応する連携アカウント情報とが含まれる。図６の例では、アカウント名「User001@server_B.com」と「User2313@server_A.com」とは同一の利用者がそれぞれサーバＢ２００とＡ１００で取得したアカウント名である。個々の連携先に対応する連携アカウント情報には、その連携先のサーバを特定するドメイン名と、その連携先との間で当該利用者を特定するための「仮名」及び「名前」とが含まれる。例えば、「仮名」は、サーバＢ２００が連携先のサーバとの通信の際に当該利用者を特定するために用いる名前であり、サーバＢ２００が任意に割り当てる。その逆に、「名前」は、連携先のサーバが当該利用者を特定する際に用いる名前であり、その連携先サーバが任意に割り当てる。したがって、連携している一方のサーバでの「仮名」はもう一方のサーバの「名前」と同じ値である。各サーバは、仮名を用いることで、連携先のサーバに対して利用者のアカウント名を知らせずに済む。利用者がサーバＡ１００とＢ２００とにアクセスして、アカウント連携のための操作を行うと、サーバＡ１００とＢ２００とがそれぞれその利用者に与えた仮名を交換し、それぞれ図６に例示したような連携アカウント情報を生成する。このようなアカウント連携の処理は、リバティ・アライアンスの仕様に規定されているので、これ以上の詳細は省略する。
【００４０】
次に、図７を参照して、本実施形態のシステムにおけるシングルサインオン処理の流れの例を説明する。この例は、ある利用者が、サーバＡ１００のサービスを利用する場合の例である。なお、ここでは、この処理が実行される前に、その利用者がサーバＡ１００とＢ２００とに対するアカウント連携の操作を完了させているものとする。
【００４１】
図７の例では、まずその利用者が利用者端末３００からＩＤＰであるサーバＢ２００に対してアクセスし、ログイン認証を受ける（Ｓ１）。このステップでは、利用者は、サーバＢ２００の認証部２３２に対して自分の認証情報（例えばパスワード）を提示することで認証を受ける。利用者が提示した認証情報が正しい場合、認証部２３０は認証が成功したと判定する。この場合、サービス判定部２３４が、その利用者の評価値を利用者評価値テーブル２５４から求め、その評価値に応じた処理をサービス提供部２１０に指示する。例えば、サービス提供部２１０は、Ｗｅｂページを利用者端末３００に提供する（Ｓ２）。サービス提供部２１０が提供するＷｅｂページには、当該ユーザがアカウント連携操作を行った他のサーバ（この例ではサーバＡ１００）のＷｅｂページへのリンクが含まれる。利用者が、利用者端末３００のＷｅｂブラウザにてそのリンクを選択すると、Ｗｅｂブラウザは、サーバＡ１００に対してそのＷｅｂページを要求する（Ｓ３）。この要求には、例えば、元のサーバＢ２００を特定する情報（例えばサーバＢ２００のドメイン名）と当該利用者のサーバＢ２００における仮名が含まれる。このためには、例えば、Ｗｅｂページに表示するサーバＡ１００を指したリンクに、パラメータとしてサーバＢ２００の情報と利用者の仮名を組み込んでおけばよい。
【００４２】
この要求を受けたサーバＡ１００の連携処理部１４０は、その要求に含まれる情報が示すサーバＢ２００に対する認証要求を生成してこれを利用者端末３００へと送る（Ｓ４）。この認証要求には、サーバＡ１００を特定する情報と、当該利用者のサーバＡ１００における仮名が含まれる。この認証要求は、HTTP(Hypertext Transfer Protocol)リダイレクト又はForm Postを用いて、利用者端末３００からサーバＢ２００へとリダイレクトされる（Ｓ５）。
【００４３】
この例では、既にサーバＢ２００はその利用者のログイン認証を済ませているので、ステップＳ５の認証要求を受け取ると、その利用者についての認証アサーションを生成し、これを利用者端末３００を経由してサーバＡ１００に送る（Ｓ６及びＳ７）。ここで、サーバＢ２００の評価値提供部２４４は、その利用者のサーバＢ２００における評価値を利用者評価値テーブル２５４から取得し、それを認証アサーションに対応づけて（例えば認証アサーションに１要素として組み込んで）、利用者端末３００経由でサーバＡ１００へと提供する（Ｓ６及びＳ７）。認証アサーションのデータ内容についてはリバティ・アライアンスの仕様に規定されているので説明を省略する。
【００４４】
認証アサーション及び利用者の評価値を受け取ったサーバＡ１００の連携処理部１４０は、認証アサーションをチェックしてその利用者のログインを認めるか否かを判定する（Ｓ８）。ログインを認める場合、更に、サービス判定部１３４が、その利用者の評価値（利用者評価値テーブル１５４に登録された値、又はサーバＢ２００から受け取った値）に基づき、その利用者に対して与えるサービス内容を判定する（Ｓ９）。このステップＳ９の詳細な処理手順については、後で図８を参照してその一例を説明する。このようにサービス内容が判定されると、その判定結果に従ってサービス提供部１１０が利用者端末３００に対してサービスを提供する。
【００４５】
図７に例示した手順では、利用者がまずＩＤＰであるサーバＢ２００にログインした後、ＳＰであるサーバＡ１００にアクセスしたが、本実施形態の方式の適用はこのような場合に限らない。利用者がまずサーバＡ１００にアクセスし、その後でサーバＢ２００でログイン認証を行ってもよい。この場合、最初にアクセスされたサーバＡ１００は、例えば、認証に利用するＩＤＰのリストを示したＷｅｂページを利用者端末３００に提供し、利用者はそのリストの中から自分が使用するＩＤＰを選択すればよい。この選択結果を受けた連携処理部１４０は、選択されたＩＤＰに対する認証要求を生成し、この認証要求を利用者端末３００経由でサーバＢ２００に送る。そして、この認証要求を受けたサーバＢ２００が、ログイン画面を提供し、その利用者のログイン認証を行う。そして、ログイン認証が成功すれば、連携処理部２４０が認証アサーションを生成し、これをその利用者の評価値と共にサーバＡ１００に提供する。
【００４６】
以上に説明した図７の手順は、リバティ・アライアンスのブラウザＰＯＳＴ方式によるシングルサインオンの手順を示したものである。リバティ・アライアンスのシングルサインオンには、この他にもブラウザ・アーティファクト方式やＬＥＣＰ(Liberty Enabled Client/Proxy)方式などがある。どの方式を用いる場合にも、認証アサーションと対応づけて評価値情報をサーバＢ２００からサーバＡ１００に提供可能である。例えばブラウザ・アーティファクト方式の場合、周知のように、サーバＡ１００がサーバＢ２００に直接アクセスして認証アサーションを取得する。このときにサーバＡ１００は、認証アサーションと共に評価値を取得すればよい。
【００４７】
以上の例では、サーバＢ２００での利用者の評価値を認証アサーションと対応づけてサーバＡ１００に送ったが、評価値送信のタイミングはこれに限らない（これは、後述する変形例でも同様である）。例えばステップＳ２及びＳ３（図７）で利用者をサーバＢ２００からサーバＡ１００に誘導する際に、サーバＢ２００での評価値をサーバＡ１００に提供するようにしてもよい。これには、例えばステップＳ２で利用者に提供するＷｅｂページ上のサーバＡ１００を指すリンクに、その評価値を例えばパラメータとして埋め込んでおけばよい。また、この代わりに、そのＷｅｂページ上のサーバＡ１００を示すリンクがサーバＢ２００内の特定のＵＲＬ(Uniform Resource Locator)を指すようにしておき、そのリンクが選択された場合にサーバＢ２００がHTTPリダイレクトによりその評価値を利用者端末経由でサーバＡ１００に送るようにしてもよい。
【００４８】
次に図８を参照して、図７のステップＳ９の詳細な手順の一例を説明する。この手順では、まずサーバＡ１００のサービス判定部１３４は、まず利用者評価値テーブル１５４から当該利用者の当該サーバＡ１００での評価値を取得する（Ｓ２１）。評価値が取得できた場合（Ｓ２２の判定結果がＹｅｓ）は、サービス判定部１３４は、その評価値に応じて、その利用者に提供するサービス内容（サービスのレベル又は種類）を判定する（Ｓ２５）。
【００４９】
一方、ステップＳ２１で、当該利用者の当該サーバＡ１００での評価値が取得できなかった場合、サービス判定部１３４は、評価値取得部１４４がその利用者の認証アサーションと共に受け取った評価値（サーバＢ２００での評価値）を取得する（Ｓ２３）。そして、その評価値を正規化して、自サーバＡ１００での評価値の尺度での値とする（Ｓ２４）。例えば、サーバＢ２００の評価値が１（最低）から４（最高）までの４段階で「３」である場合において、サーバＡ１００の評価値が１（最低）から５（最高）までの５段階であれば、正規化処理により、サーバＢ２００から受け取った評価値「３」は５段階評価の「３．７５」に変換される。そして、サービス判定部１３４は、このように正規化された評価値に基づき、当該利用者に提供するサービスの内容を判定する（Ｓ２５）。例えば、評価値が非常に低い場合には、実質的なサービスを提供しないという制御も可能である。また、利用者に提供する情報や処理機能の質や量を評価値に応じて制御してもよい。
【００５０】
なお、ステップＳ２４での正規化を実現するために、サーバＢ２００からサーバＡ１００に提供される評価値に、その評価値の尺度を表す情報を付加してもよい。評価値の尺度を表す情報は、例えば、評価値の最小値と最大値、評価値の刻み、評価値の極性（大きい値と小さい値のどちらか「良い」のかを示す情報）などを含む。なお、トラストサークルに参加しているすべてのサーバで評価値の尺度が一致している場合は、正規化の必要はない。
【００５１】
このような処理により、サーバＡ１００が当該利用者の評価値を利用者評価値テーブル１５４に保持していない場合でも、ＩＤＰ（サーバＢ２００）から提供される当該利用者の評価値に基づき当該利用者に対するサービス内容が判定される。なお、この判定に用いられたサーバＢ２００からの評価値（正規化後）は、当該利用者のサーバＡ１００での評価値の初期値として、利用者評価値テーブル１５４に登録してもよい。この場合、その後のサーバＡ１００での利用者の操作履歴に基づき、その利用者のサーバＡ１００での評価値が更新されていく。
【００５２】
本実施形態の方式を用いない場合、サーバＡ１００が利用者の評価値を持っていなければ、その利用者を例えば最低レベルの評価値又は平均レベルの評価値であるとして一律に取り扱うしかない。これに対し、本実施形態の方式を用いれば、連携している他のサーバでの当該利用者の評価値を利用するので、その利用者の実績が反映されることになる。
【００５３】
以上の例では、サーバＢ２００からサーバＡ１００に評価値を提供する場合を説明したが、サーバＡ１００及びＢ２００の両方が相手に対して利用者の評価値を提供する機能を持つようにしてもよい。
【００５４】
次に、図９〜図１３を参照して、変形例を説明する。この変形例では、サーバ（第１のサーバ）は、他のサーバ（第２のサーバ）から受け取った利用者の評価値を、その第２のサーバの信頼度に応じて換算して利用する。ここでいう第２のサーバの信頼度は、第２のサーバが提供する評価値が、第１のサーバからみてどの程度信頼できるかを示す値である。１つの例では、第１のサーバの管理者が、第２のサーバの信頼度の数値を定めればよい。また、別の例として、第１のサーバと第２のサーバとが同じ利用者に付与している評価値同士の差の程度に基づき信頼度を規定してもよい。例えば、両者の評価値の差が小さいほど、相互に対する信頼度は高い。以下では、同一利用者に対する評価値の差に基づき信頼度を自動判定する例について説明する。
【００５５】
例えば、サーバＡ１００の監視部１２０が各利用者について判定した評価値と、サーバＢ２００から取得したそれら各利用者の評価値との関係が図９に示すようなものであったとする。この例では、サーバＢ２００から取得した評価値はサーバＡ１００での評価値と尺度が違うため、正規化されている。同一利用者について、この正規化後のサーバＢ２００での評価値から、サーバＡ１００の評価値を引くことにより「評価値差分」を求める。この評価値差分の全利用者についての自乗平均を、例えばサーバＡ１００の評価値に対するサーバＢの評価値の相異度と規定することができる（なお、この相異度の求め方はあくまで一例である）。この相異度が小さいほど、サーバＢ２００の評価値付与の傾向がサーバＡ１００の評価値付与の傾向に近いということになり、サーバＢ２００のサーバＡ１００から見た信頼度が高くなる。相異度から信頼度の値を求める規則は、あらかじめ定めておけばよい。
【００５６】
これまでの例では、サーバＡ１００にとっては、評価値の提供を受けるサーバがサーバＢ２００しかなかったが、そのようなサーバが複数ある場合には、サーバごとに、そのサーバから取得された各利用者の評価値が記憶され、上述の方法で相異度が計算され、その相異度に基づき信頼度が計算される。
【００５７】
図１０は、この変形例におけるサーバＡ１００の機能構成を示している。図１０において、図２に示した構成要素に対応する構成要素には同一符号を付して説明を省略する。図１０に示すように、この変形例のサーバＡ１００は、図２に示した構成に加え、信頼度判定部１４６と評価値換算部１４８を備えると共に、記憶装置１５０内にサーバ信頼度テーブル１５６及び換算テーブル１５８を備える。
【００５８】
サーバ信頼度テーブルは１５６には、例えば図１１に示すように、サーバごとにその信頼度が登録されている。この例では、サーバの信頼度は「高」、「中」、「低」の３段階である。この例では、例えば、前述のようにして計算した相異度に対して例えば２段階の閾値を設け、相異度が低い方の閾値よりも小さいサーバの信頼度は「高」、相異度が高い方の閾値よりも大きいサーバの信頼度は「低」、それ以外のサーバの信頼度は「中」とすればよい。連携処理部１４０の信頼度判定部１４６が、例えば定期的に利用者評価値テーブル１５４を参照して各サーバの相異度を計算し、その相異度に基づき各サーバの信頼度を判定してサーバ信頼度テーブル１５６の内容を更新する。なお、サーバ信頼度テーブル１５６の更新は、定期的なものに限られるものではない。例えば、他のサーバＸから利用者の評価値を得るごとに、その評価値を計算に入れてそのサーバＸの信頼度を更新してもよい。
【００５９】
換算テーブル１５８には、信頼度の範囲ごとに、その範囲に属する信頼度を持つサーバから得た評価値（正規化後）を、自サーバＡ１００の評価値に換算するための換算情報が登録されている。基本的な考え方は、サーバの信頼度が高いほどそのサーバから得た評価値を尊重するというものである。一方、サーバの信頼度が低いほどそのサーバから得た評価値の信頼性が低いということなので、その評価値の値によらず一律に近い扱いをすることになる。一律の取り扱いのレベルをどのレベルとするかは、自サーバＡ１００のポリシーによる。例えば、１つのポリシーでは、サーバの信頼度が低いほど、そのサーバから取得した評価値が自サーバＡ１００での評価値の中央値に近づくように換算する。また、別のポリシーでは、自サーバＡ１００での最低の評価値に近づくように換算する。
【００６０】
換算テーブル１５８の一例を図１２に示す。この例は、信頼度が高いサーバからの評価値（正規化後）は保存し、信頼度の低いサーバからの評価値は自サーバＡ１００の評価値の中央値に丸めるという考え方に従ったものである。評価値換算部１４８は、他のサーバから取得した評価値をこの換算テーブル１５８を参照して自サーバＡ１００での値に換算する。
【００６１】
この変形例の大まかな処理の流れは、上述の実施形態（図７参照）と同様でよい。ただしステップＳ９のサービス内容の判定処理は、図８に示した処理手順に、信頼度を考慮した処理が加わる。この処理手順を図１３に示す。図１３において、図８に示したステップと同様のステップには同一符号を付して説明を省略する。
【００６２】
図１３の手順では、サーバＡ１００がサーバＢ２００から取得した利用者の評価値を正規化（Ｓ２４）した後、信頼度判定部１４６がサーバ信頼度テーブル１５６からサーバＢ２００の信頼度を取得する（Ｓ２６）。そして、評価値換算部１４８がその信頼度に対応する換算情報を換算テーブル１５８から取得し、ステップＳ２４で正規化した評価値をその換算情報に基づき換算する（Ｓ２７）。例えば、図１２の換算テーブルを用いる場合において、サーバＢ２００の信頼度が「中」であった場合、正規化した評価値が１．２５は、２に換算される。そして、この換算結果の評価値を用いて、利用者に提供するサービス内容が判定される（Ｓ２５）。
【００６３】
以上では、リバティ・アライアンスの枠組みを利用してサーバ間で評価値を受け渡す例を説明したが、上記実施形態及び変形例の適用対象はこれに限らない。例えば、HTTPリダイレクトやＰＯＳＴメソッドを利用すれば、あるサーバが提供したＷｅｂページから他のサーバへ各種のデータを送ることができるので、そのような方法を用いて評価値をサーバ間で受け渡してもよい。
【００６４】
以上に例示したサーバＡ１００及びサーバＢ２００は、典型的には汎用のコンピュータに上述の各機能モジュールの処理を表すプログラムを実行させることにより実現される。ここで、コンピュータは、例えば、ハードウエアとして、図１４に示すように、ＣＰＵ５００等のマイクロプロセッサ、ランダムアクセスメモリ（ＲＡＭ）５０２およびリードオンリメモリ（ＲＯＭ）５０４等のメモリ（一次記憶）、ＨＤＤ（ハードディスクドライブ）５０６を制御するＨＤＤコントローラ５０８、各種Ｉ／Ｏ（入出力）インタフェース５１０、ローカルエリアネットワークなどのネットワークとの接続のための制御を行うネットワークインタフェース５１２等が、たとえばバス５１４を介して接続された回路構成を有する。また、そのバス５１４に対し、例えばＩ／Ｏインタフェース５１０経由で、ＣＤやＤＶＤなどの可搬型ディスク記録媒体に対する読み取り及び／又は書き込みのためのディスクドライブ５１６、フラッシュメモリなどの各種規格の可搬型の不揮発性記録媒体に対する読み取り及び／又は書き込みのためのメモリリーダライタ５１８、などが接続されてもよい。実施形態又は変形例の処理内容が記述されたプログラムがＣＤやＤＶＤ等の記録媒体を経由して、又はネットワーク等の通信手段経由で、ハードディスクドライブ等の固定記憶装置に保存され、画像形成装置にインストールされる。固定記憶装置に記憶されたプログラムがＲＡＭ５０２に読み出されＣＰＵ５００等のマイクロプロセッサにより実行されることにより、実施形態又は変形例の処理が実現される。
【図面の簡単な説明】
【００６５】
【図１】実施形態の情報処理システムの概略構成の一例を示す図である。
【図２】サーバＡ（ＳＰ）の詳細な機能構成の一例を示す図である。
【図３】サーバ上で監視対象となる利用者の操作履歴の例を示した図である。
【図４】利用者評価値テーブルのデータ内容の一例を示す図である。
【図５】サーバＢ（ＩＤＰ）の詳細な機能構成の一例を示す図である。
【図６】連携情報の例を示す図である。
【図７】実施形態の処理の流れの例を示す図である。
【図８】評価値に基づくサービス内容の判定の手順の一例を示す図である。
【図９】変形例の利用者評価値テーブルのデータ内容の例を示す図である。
【図１０】変形例のサーバＡの機能構成の一例を示す図である。
【図１１】サーバ信頼度テーブルのデータ内容の一例を示す図である。
【図１２】換算テーブルのデータ内容の一例を示す図である。
【図１３】評価値に基づくサービス内容の判定の手順の別の例を示す図である。
【図１４】コンピュータのハードウエア構成の一例を示す図である。
【符号の説明】
【００６６】
１００  サーバＡ、１１０  サービス提供部、１２０  監視部、１３０  認証処理部、１３２  認証部、１３４  サービス判定部、１４０  連携処理部、１４２  認証情報取得部、１４４  評価値取得部、１４６  信頼度判定部、１４８  評価値換算部、１５０  記憶装置、１５２  連携情報テーブル、１５４  利用者評価値テーブル、１５６  サーバ信頼度テーブル、１５８  換算テーブル、２１０  サービス提供部、２２０  監視部、２３０  認証処理部、２３２  認証部、２３４  サービス判定部、２４０  連携処理部、２４２  認証情報提供部、２４４  評価値提供部、２５０  記憶装置、２５２  連携情報テーブル、２５４  利用者評価値テーブル、３００  利用者端末、４００  データ通信ネットワーク。
【図１】
2008257434.tif 000003
【図２】
2008257434.tif 000004
【図３】
2008257434.tif 000005
【図４】
2008257434.tif 000006
【図５】
2008257434.tif 000007
【図６】
2008257434.tif 000008
【図７】
2008257434.tif 000009
【図８】
2008257434.tif 000010
【図９】
2008257434.tif 000011
【図１０】
2008257434.tif 000012
【図１１】
2008257434.tif 000013
【図１２】
2008257434.tif 000014
【図１３】
2008257434.tif 000015
【図１４】
2008257434.tif 000016