JP2003067326A - ネットワーク上の資源流通システム、及び相互認証システム - Google Patents

Abstract

(57)【要約】 【課題】 複数のエンティティの各々が保管する資源
を、このエンティティの各々が相互に利用し合えるよう
にする。 【解決手段】 利用者（図示は省略）は利用者端末１を
使用し、窓口サーバ２に対して、資源提供サーバ４が提
供する資源を通信回線３を介して要求する。利用者情報
ＤＢ２２には、利用者を認証するための情報が記録され
ている。資源提供者情報ＤＢ２３には、資源提供者の信
用度を検証するための情報が記録されている。資源提供
者情報ＤＢ４３には、窓口サーバ２を認証するための情
報が記録されている。利用者情報ＤＢ４２には、窓口サ
ーバ２によって認証され、資源へのアクセスが許可され
る利用者に関する情報が記録されている。許可データＤ
Ｂ４４には、資源へのアクセスを制限するための情報が
記録されている。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、ネットワーク上の
資源流通システム及び相互認証システムに関し、特に、
ネットワーク上の複数のエンティティの各々が、それぞ
れが所有する資源を互いに利用し合うネットワーク上の
資源流通システムと、ネットワーク上の複数のエンティ
ティの各々が、任意の仲間エンティティとの認証を行う
相互認証システムに関する。

【０００２】

【従来の技術】従来は、ネットワーク上の資源流通シス
テムとして、１つのエンティティ（ネットワーク上のノ
ードであり、利用者認証、利用可能資源の保管、後述す
るアクセス制限等の機能を有するネットワーク構成要
素）が、利用可能な資源を保管すると共に、利用者認証
処理とアクセス制限処理（要求された情報を利用させる
か否かの判断処理であり、著作権等の処理も含まれる）
とを行う場合が多かった。

【０００３】最近になって、例えば、利用者、資源提供
サーバ、窓口サーバといったエンティティの役割分担を
決めるシステムが提案され、また、エンティティ間の相
互認証のために認証を専門とし、公開鍵認証書等を発行
する認証局（CertificationAuthority）を設置するシス
テムも提案されるようになった。

【０００４】

【発明が解決しようとする課題】ところで、上記従来の
ネットワーク上の資源流通システムでは、エンティティ
の役割分担が固定的であり、複数のエンティティの各々
が保管する資源を、このエンティティの各々が相互に利
用し合うといった資源流通形態は実現されていなかっ
た。それ故、この資源流通形態を具体的に実現するため
に必要な相互認証システムについても実現していなかっ
た。

【０００５】また、上記従来のネットワーク上の資源流
通システムでは、上記の事情からも明らかなように、複
数のエンティティグループを結合して、より広域的なネ
ットワークコミュニティを構築するといった課題も解決
されていなかった。

【０００６】一方、認証局を設置する従来の相互認証シ
ステム（ＰＫＩ等による相互認証システム）にも、認証
局の信頼性を比較する尺度が存在しないといった問題点
や、公開鍵証明書や証明書ベースの証明書の発行数が増
大するといった問題点、さらには、認証方式や認証の仕
組み、公開鍵のフォーマット等が統一されていないとい
った問題点が有った。

【０００７】また、複数のコミュニティ間でサービス
や、様々なレベルの交流を実現する上で、利用者認証の
方式が各コミュニティによって異なることが大きな問題
点であった。

【０００８】なお、各エンティティが集めた利用者情報
（個人情報等）の取り扱いには特別な注意が必要であ
り、利用者情報の流出や流用は禁止されているために、
これらを一元的に集中管理することができないといった
背景もあった。

【０００９】本発明は、以上のような従来のネットワー
ク上の資源流通システムにおける問題点に鑑みてなされ
たものであり、複数のエンティティの各々が保管する資
源を、このエンティティの各々が相互に利用し合うこと
ができるネットワーク上の資源流通システムを提供する
ことを目的とする。

【００１０】本発明の他の目的は、複数のエンティティ
の各々が提供するサービス（資源提供等）を、このエン
ティティの各々が相互に利用し合う際に必要となる相互
認証を効果的に実現する相互認証システムを提供するこ
とにある。

【００１１】

【課題を解決するための手段】本発明では上記の課題を
解決するために、１以上の資源提供サーバが提供する資
源を、１以上の利用者が、前記資源提供サーバと通信回
線で接続された利用者端末を介して要求し、前記要求し
た資源を前記通信回線を介して前記利用者端末にダウン
ロードして利用するネットワーク上の資源流通システム
において、前記利用者の認証に必要な情報を記録する第
１の利用者情報データベースと、資源提供者の信頼性の
検証に必要な情報を記録する第１の資源提供者情報デー
タベースとを備え、前記利用者の任意の１つの利用者端
末から送信される前記資源提供サーバへの資源要求の窓
口となって、前記資源要求に対応する資源要求指令を前
記資源要求に指定された前記資源提供サーバに送信する
１以上の窓口サーバと、前記窓口サーバの認証に必要な
情報を記録する第２の資源提供者情報データベースと、
前記窓口サーバが認証した前記利用者に関する情報を取
り出し可能に記録する第２の利用者情報データベース
と、前記利用者に提供する資源へのアクセス制限を記録
する許可データデータベースとを備え、前記窓口サーバ
の任意の１つからの資源要求に応答して資源を送信する
資源提供サーバとを備えたことを特徴とするネットワー
ク上の資源流通システムが提供される。

【００１２】また、本発明では上記の課題を解決するた
めに、１以上のサービスサーバと、前記サービスサーバ
が提供するサービスを利用する１以上の利用者と、前記
サービスサーバと前記利用者の利用者端末とを仲介する
１以上の窓口サーバから成る第１のコミュニティと、前
記第１のコミュニティと同様の構成要素を含むコミュニ
ティから成る第２のコミュニティとを含むネットワーク
コミュニティにおける相互認証システムであって、前記
第１のコミュニティに属する窓口サーバの任意の１つが
作成した公開鍵証明書を発行する第１の認証局と、前記
第２のコミュニティに属する窓口サーバの任意の１つが
作成した公開鍵証明書を発行する第２の認証局と、前記
第１の認証局、及び前記第２の認証局がそれぞれ発行し
た公開鍵証明書を所定の評価項目に基づいて評価した評
価情報を記録する信頼性データベースを具備する格付け
サーバとを有することを特徴とする相互認証システムが
提供される。

【００１３】即ち、本発明では、ネットワーク上の資源
流通システムに、資源提供サーバの窓口業務を代行する
窓口サーバを設置すると共に、窓口サーバに、利用者を
認証するに必要な利用者情報を記録する第１の利用者情
報データベースと、ネットワークコミュニティ内の資源
提供者（エンティティ）の信用度を記録する第１の資源
提供者情報データベースとを備え、さらに、資源提供サ
ーバにも、窓口サーバを認証するために必要な情報を記
録する第２の資源提供者情報データベースと、窓口サー
バが認証した利用者に関する情報を含む利用者情報を記
録する第２の利用者情報データベースとを備える構成と
することにより、複数のエンティティの各々が保管する
資源を、このエンティティの各々が相互に利用し合うこ
とができるようにしている。

【００１４】また、複数のコミュニティから成るネット
ワークコミュニティに、複数のコミュニティのいずれか
に属する複数の認証局の各々が発行する公開鍵証明書を
それぞれ評価する機能を有する格付けサーバを設置し、
複数のコミュニティのいずれかに属する複数の窓口サー
バ間で、互いの信用度、及び使用する公開鍵証明書の信
用度や保証金額をチェックすることを可能にすることに
より、複数のエンティティの各々が提供するサービス
を、このエンティティの各々が相互に利用し合う際に必
要となる相互認証を効果的に実現している。

【００１５】

【発明の実施の形態】以下、本発明の実施の形態を図面
に基づいて説明する。 （第１の実施の形態）本実施の形態は、複数のエンティ
ティの各々が保管する資源を、このエンティティの各々
が相互に利用し合うことができるネットワーク上の資源
流通システムに係る。

【００１６】図１は、本発明の第１の実施の形態に係る
ネットワーク上の資源流通システムの全体構成を示すブ
ロック図である。本実施の形態に係るネットワーク上の
資源流通システムは、資源の利用者が使用する利用者端
末１と、利用者端末１からの要求の窓口となる窓口サー
バ２と、利用者端末１、窓口サーバ２、及び後述する資
源提供サーバ４を互いに通信可能に接続する通信回線３
と、利用者に提供することができる資源を蓄積保管する
資源提供サーバ４とを含む。

【００１７】ここで、利用者端末１、窓口サーバ２、資
源提供サーバ４は、それぞれ複数とすることが可能であ
るものとする。また、通信回線３は、その経路にインタ
ーネット網を含むことが可能であり、また、全体がイン
ターネット網であることも可能であるものとする。

【００１８】さらに、ここで、資源とは、例えば、静止
画像、動画像、テキスト文、音声情報等の形態をとる各
種情報（コンテンツ）、及びサービス情報情報等を含む
ものとする。

【００１９】利用者端末１は、資源の要求に必要な処理
を行うと共に全体を制御する制御部１１と、ダウンロー
ドした資源を格納するためのダウンロードＤＢ（データ
ベース）１２と、通信回線３と通信可能に接続するため
の通信部１３とを備える。

【００２０】ここで、制御部１１は、窓口サーバ２の認
証を受けるために必要な認証情報を管理する認証部１１
１と、資源を要求するための指令（資源要求指令）を作
成する要求作成部１１２とを備える。

【００２１】窓口サーバ２は、要求された資源の窓口業
務として必要な処理を行うと共に全体を制御する制御部
２１と、利用者に関する個人情報を記録する利用者情報
ＤＢ２２と、資源提供者（オリジナル資源サーバ、資源
提供サーバ（ここでは資源提供サーバ４）、窓口サーバ
（ここでは窓口サーバ２）等）に関する信頼性情報を記
録する資源提供者情報ＤＢ２３と、通信回線３と通信可
能に接続するための通信部２４とを備える。

【００２２】ここで、制御部２１は、利用者の認証を行
うと共に、資源提供サーバ４から送信された利用可能資
源を利用者に提供可能な形式に変換するための利用者認
証部２１１と、要求された資源を保管する資源提供サー
バ（ここでは資源提供サーバ４）に対して資源を要求す
るための指令、即ち、資源要求指令を作成するリクエス
ト生成部２１２とを備える。

【００２３】資源提供サーバ４は、要求された資源を引
き渡すために必要な処理を行うと共に全体を制御する制
御部４１と、利用者に関する個人情報を記録する利用者
情報ＤＢ４２と、資源提供者に関する信頼性情報を記録
する資源提供者情報ＤＢ４３と、資源の使用を許可する
か否かの情報を記録する許可データＤＢ４４とを備え
る。

【００２４】なお、利用者に提供するための資源を蓄積
保管するデータベースについては、図示を省略してい
る。ここで、制御部４１は、窓口サーバ２の認証を行う
ための認証部（図示は省略）と、窓口サーバ２からの資
源要求指令を検証すると共に、利用可能な資源を送信形
式に変換するためのリクエスト検証部４１１と、要求さ
れた情報を利用させるか否かの判断や、著作権等の処理
を行いながら利用者に提供するための利用可能な資源を
取り出す資源へのアクセス制限部４１２と、利用者に提
供する資源、及び資源の状態を管理する資源・資源管理
部４１３とを備える。

【００２５】なお、本実施の形態では、リクエスト検証
部４１１と資源へのアクセス制限部４１２とを共に資源
提供サーバ４内のモジュールとしているが、一般には、
リクエスト検証部４１１（即ち、資源要求指令の検証を
行うモジュール）と、資源へのアクセス制限部４１２
（即ち、資源へのアクセス制限を検証するモジュール）
とが、同一エンティティに存在するとは限らない。

【００２６】以下、本実施の形態に係るネットワーク上
の資源流通システムの機能を、主な構成要素別に説明す
る。利用者端末１の制御部１１は、要求作成部１１２を
起動して資源要求指令を作成し、さらに通信部１３を起
動して、この資源要求指令を通信回線３を介して窓口サ
ーバ２に送信する。この資源要求指令には、資源提供者
を指定する情報も含められる。なお、必要なら、この資
源要求指令を暗号化することも可能である。この暗号化
は、ＩＤ＆パスワードに対しては、ＳＳＬ（Secure Soc
kets Layer）等の暗号通信用プロトコルを使用すること
ができる。なお、この資源要求指令の送信に際しては、
要求作成部１１２は、認証部１１１が管理する認証情報
により窓口サーバ２の認証を受けセキュアなパスを得
る。このセキュアなパスは、ＰＫＩ（Public Key Infra
structure）等による相互認証の結果として得ることが
できる。

【００２７】その後、制御部１１は、この指令により、
窓口サーバ２から送信されてくる資源を、ダウンロード
ＤＢ１２に記録する。窓口サーバ２の制御部２１は、利
用者認証部２１１とリクエスト生成部２１２とを起動
し、利用者認証部２１１は、利用者情報ＤＢ２２を参照
して利用者の認証を行い、この認証がとれると、制御部
２１は、利用者端末１から送信された資源要求指令をリ
クエスト生成部２１２に引き渡す。

【００２８】リクエスト生成部２１２は、資源提供者情
報ＤＢ２３を参照して、受け取った資源要求指令に指定
された資源提供者の信頼性を検証する。この検証によ
り、資源提供者の信頼性が保証されない場合は、通信部
２４と通信回線３を介して利用者端末１に、その旨を通
知する。

【００２９】また、リクエスト生成部２１２は、資源提
供者の信頼性が保証される場合は、利用可能資源を保管
する資源提供サーバ（ここでは資源提供サーバ４）に対
する資源要求指令を作成し、この資源要求指令を通信部
２４と通信回線３を介して資源提供サーバ４に送信す
る。この資源要求指令の送信に際しては、リクエスト生
成部２１２は、資源提供サーバ４との間で相互認証によ
りセキュアなパスを得る。なお、この資源要求指令に
は、資源を要求してきた利用者を特定するための利用者
情報が含められる。

【００３０】さらに、リクエスト生成部２１２は、資源
提供サーバ（ここでは資源提供サーバ４）から送信され
た利用可能資源を利用者に引き渡す形式に変換する。資
源提供サーバ４の制御部４１は、窓口サーバ２の認証を
行うと共に、リクエスト検証部４１１、資源へのアクセ
ス制限部４１２、資源・資源管理部４１３を起動し、リ
クエスト検証部４１１では、窓口サーバ２からの資源要
求指令を検証し、また、資源へのアクセス制限部４１２
により、要求された情報を利用させるか否かの判断や、
著作権等の処理を行いながら利用者に提供するための利
用可能な資源を取り出し、さらに、資源・資源管理部４
１３により、保管している資源の状態の記録を更新す
る。

【００３１】また、リクエスト検証部４１１は、この利
用者に提供するための利用可能な資源が資源・資源管理
部４１３から取り出された後には、この資源を窓口サー
バ２への送信形式に変換し、通信部４５と通信回線３を
介して窓口サーバ２に送信する。

【００３２】なお、リクエスト検証部４１１は、窓口サ
ーバ２からの資源要求指令を検証することにより、この
資源要求指令に対する応答を判断する。この資源要求指
令の検証は、利用者を認証した窓口サーバ２の信頼性を
検証するか、または、利用者の信頼性を検証するかのい
ずれか１つの方法により行われる。そのいずれの方法を
選択するかのアルゴリズムは、リクエスト検証部４１１
に対して予め決定されている。窓口サーバ２の信頼性の
方が検証される場合、資源提供者情報ＤＢ４３から窓口
サーバ２に関する信頼性情報を取り出し、その内容によ
り資源へのアクセスを許可するか否かを決定する。ま
た、利用者の信頼性の方が検証される場合、窓口サーバ
２からの資源要求指令に含まれる利用者情報を参照して
利用者を特定し、この利用者に関する個人情報を利用者
情報ＤＢ４２から検索して取り出し、その内容により資
源へのアクセスを許可するか否かを決定する。

【００３３】図２は、本発明の第１の実施の形態に係る
ネットワーク上の資源流通システムの１例としての動作
を示す説明図である。図２では、利用者が利用者端末１
を使用し、窓口サーバ２を介して資源提供サーバ４が保
管する資源を要求する場合のネットワーク上の資源流通
システムの動作が示されている。

【００３４】図２に示す符号Ｓ１〜Ｓ２０は、動作ステ
ップを示し、符号Ｓ１〜Ｓ２０の記載位置は、それぞ
れ、該当する動作ステップが実行されるシステム上の位
置を示すものとする。

【００３５】以下、図２を参照して、本実施の形態に係
るネットワーク上の資源流通システムの１例としての動
作を説明する。まず、ステップＳ１では、利用者が、利
用者端末１を使用し、資源提供サーバ４が保管する資源
を要求する資源要求指令を作成し、窓口サーバ２の利用
者認証部２１１での認証を受けることにより窓口サーバ
２との間でセキュアなパスを確立した後、作成した資源
要求指令を窓口サーバ２へ送信する。

【００３６】なお、必要に応じて、この資源要求指令は
暗号化される。この暗号化は、ＩＤ＆パスワードに対し
ては、ＳＳＬ等の暗号通信用プロトコルを使用すること
ができる。

【００３７】また、この資源要求指令の送信に際して確
立されるセキュアなパスは、要求作成部１１２は、認証
部１１１が管理する認証情報により窓口サーバ２の認証
を受けることや、ＰＫＩ等により相互認証することで得
られる。このＰＫＩベースの認証に際しては、利用者が
自己の署名秘密鍵と公開鍵のペアを持つ場合、証明書ベ
ースの相互認証を経てセッション鍵を合意する等して、
セキュアパスを実現する。

【００３８】ステップＳ２では、窓口サーバ２の利用者
認証部２１１が、利用者の認証を行って利用者端末１と
の間のセキュアなパスを確立した後、利用者端末１から
の資源要求指令を受け付ける。この時、ＰＫＩベースの
セキュアパスが形成される場合には、利用者情報ＤＢ２
２を参照し、資源要求指令の内容との無矛盾性のチェッ
クを行う。また、ＩＤ＆パスワードに対しては、利用者
が提供した情報と、資源要求内容との無矛盾性のチェッ
クを行う。

【００３９】ステップＳ３では、利用者認証部２１１
が、利用者の認証がとれた場合に、資源要求指令に基づ
く資源の提供をリクエスト生成部２１２に送出する。ス
テップＳ４では、リクエスト生成部２１２が、資源要求
指令に含まれる資源提供者が信頼できるか否かを資源提
供者情報ＤＢ２３を参照して検証する。この資源提供者
が信頼できない場合、または信頼性が低い場合は、その
旨の通知を利用者端末１に返す。

【００４０】ステップＳ５では、リクエスト生成部２１
２が、資源提供サーバ４に対する資源要求指令を作成す
る。また、資源提供サーバ４との間で確立すべきセキュ
アパスを生成する。この時、ＰＫＩに基づく場合、証明
書ベースの相互認証とセッション鍵の合意が行われる。
サーバ証明書認証に基づくサーバ認証だけの場合等は、
ＳＳＬ等によりセキュアパスを構築する。この認証形態
や、認証に必要な情報は、資源提供者情報ＤＢ２３に記
録しておくことも可能である。

【００４１】ステップＳ６では、この認証がとれると、
リクエスト生成部２１２は、ステップＳ５で作成した資
源提供サーバ４に対する資源要求指令を資源提供サーバ
４に送信する。

【００４２】ステップＳ７では、資源提供サーバ４のリ
クエスト検証部４１１が、ステップＳ６で窓口サーバ２
との認証がとれた後、窓口サーバ２から送信された資源
要求指令を検証する。

【００４３】ステップＳ８では、リクエスト検証部４１
１が、ステップＳ８での検証結果により、この資源要求
指令に対する応答を判断する。この資源要求指令の検証
は、利用者を認証した窓口サーバ２の信頼性を検証する
か、または、利用者の信頼性を検証するかのいずれか１
つの方法により行う。そのいずれの方法を選択するかを
決めるアルゴリズムは、リクエスト検証部４１１に対し
て予め決定されている。窓口サーバ２の信頼性の方が検
証される場合、資源提供者情報ＤＢ４３から窓口サーバ
２に関する信頼性情報を取り出し、その内容により資源
へのアクセスを許可するか否かを決定する。また、利用
者の信頼性の方が検証される場合、窓口サーバ２からの
資源要求指令に含まれる利用者情報を参照して利用者を
特定し、この利用者に関する個人情報を利用者情報ＤＢ
４２から検索して取り出し、その内容により資源へのア
クセスを許可するか否かを決定する。これらの決定が、
資源へのアクセスを許可するものである時、資源へのア
クセス制限を検証するためのチェック要求を作成する。

【００４４】ステップＳ９では、ステップＳ８で作成し
たチェック要求が、リクエスト検証部４１１から資源へ
のアクセス制限部４１２に送出される。この資源へのア
クセス制限を検証するモジュール（即ち、資源へのアク
セス制限部４１２）が、資源要求指令の検証を行うモジ
ュール（即ち、リクエスト検証部４１１）と同一エンテ
ィティ（即ち、資源提供サーバ４）に存在するとは限ら
ない。両者が異なるエンティティに存在する場合は、リ
クエスト検証部４１１と資源へのアクセス制限部４１２
との間で、上記チェック要求の送出の前に、相互認証や
セキュアパス確立のための問い合わせを済ませる。

【００４５】ステップＳ１０では、資源へのアクセス制
限部４１２が、受け取ったチェック要求を検証して、資
源へのアクセスを許可するか、または不許可にするかを
判断する。この判断に際しては、許可データＤＢ４４を
参照する。この許可データＤＢ４４には、資源の状態
（著作権等の権利状態を含む）や操作に関する許可情報
が記録されている。エンティティ（資源提供者）によっ
て許可情報が異なる場合、リクエスト検証部４１１が作
成する上記チェック要求にエンティティの種別を含ませ
ておく。

【００４６】ステップＳ１１では、チェック要求に対す
る応答が資源へのアクセス制限部４１２からリクエスト
検証部４１１に返される。ステップＳ１２では、リクエ
スト検証部４１１が、資源へのアクセス制限部４１２か
ら受け取ったチェック要求に対する応答が、資源の利用
を許可するものであった場合、資源・資源管理部４１３
に対して資源要求指令に要求された処理（資源の取り出
し等）を指示する。チェック要求に対する応答が、資源
の利用を許可するものではなかった場合、ステップＳ１
５に進む。

【００４７】ステップＳ１３では、資源・資源管理部４
１３が、要求された資源情報を取り出し、リクエスト検
証部４１１に引き渡すと共に資源の状態の記録を更新す
る。但し、資源・資源管理部４１３は、要求された資源
情報そのものは引き渡さずに、要求された資源情報をア
クセスするに必要な情報のみをリクエスト検証部４１１
に引き渡すことも可能である。

【００４８】ステップＳ１４では、リクエスト検証部４
１１が、資源・資源管理部４１３から、資源要求指令で
要求していた資源情報を受け取る。ステップＳ１５で
は、資源へのアクセス制限部４１２から受け取ったチェ
ック要求に対する応答が、資源の利用を許可するもので
あった場合、リクエスト検証部４１１は、ステップＳ１
４で受け取った資源情報を窓口サーバ２に送信する形式
に変換する。資源へのアクセス制限部４１２から受け取
ったチェック要求に対する応答が、資源の利用を不許可
にするものであった場合、リクエスト検証部４１１は、
不許可であることを通知する情報、及び付帯情報が有る
時は、この付帯情報とを窓口サーバ２に送信する形式に
変換する。

【００４９】ステップＳ１６では、リクエスト検証部４
１１が、ステップＳ１５で変換された送信形式の資源情
報を窓口サーバ２に送信する。ステップＳ１７では、窓
口サーバ２のリクエスト生成部２１２が、資源提供サー
バ４のリクエスト検証部４１１から送信された資源情報
を検証する。また、この情報に基づき、必要ならば、利
用者情報ＤＢ２２や資源提供者情報ＤＢ２３の記録を更
新する。さらに、この情報を利用者端末１に送信する形
式に変換する。

【００５０】ステップＳ１８では、リクエスト生成部２
１２が、上記送信形式の資源情報を利用者認証部２１１
に送出する。ステップＳ１９では、利用者認証部２１１
が、上記送信形式の資源情報に対して利用者端末１に送
信するために必要な処理（例えば、署名付け等）を行
う。

【００５１】ステップＳ２０では、窓口サーバ２から利
用者端末１へ、上記処理済の送信形式の資源情報を送信
する。図３は、本発明の第１の実施の形態に係るネット
ワーク上の資源流通システムの他の１例としての動作を
示す説明図である。

【００５２】図３では、第１のエンティティが第２のエ
ンティティに利用可能資源を供給する動作が示されてい
る。図３に示す符号Ｃ１〜Ｃ２５は、動作ステップを示
し、符号Ｃ１〜Ｃ２５の記載位置は、それぞれ、該当す
る動作ステップが実行されるシステム上の位置を示すも
のとする。

【００５３】以下、図３を参照して、本実施の形態に係
るネットワーク上の資源流通システムの他の１例として
の動作を説明する。まず、ステップＣ１では、資源提供
サーバ４Ａに対する資源要求指令が、どこかのエンティ
ティ（即ち、或る利用者と、その利用者端末との複合体
であり、以下、「エンティティＸ」と呼称する）から資
源提供サーバ４Ａに送信される。この送信に際しては、
図２のステップＳ５，Ｓ６での説明と同様に、相互認証
によるセキュアパスが確立される。

【００５４】ステップＣ２では、資源提供サーバ４Ａの
リクエスト検証部４１１Ａが、上記の資源提供サーバ４
Ａに対する資源要求指令を検証する。また、この検証結
果により、この資源要求指令に対する応答を判断する。
この資源要求指令の検証は、利用者を認証したエンティ
ティＸの信頼性を検証するか、または、利用者の信頼性
を検証するかのいずれか１つの方法により行う。そのい
ずれの方法を選択するかを決めるアルゴリズムは、リク
エスト検証部４１１Ａに対して予め決定されている。エ
ンティティＸの信頼性の方が検証される場合、資源提供
者情報ＤＢ４３ＡからエンティティＸに関する信頼性情
報を取り出し、その内容により資源へのアクセスを許可
するか否かを決定する。また、利用者の信頼性の方が検
証される場合、エンティティＸからの資源要求指令に含
まれる利用者情報を参照して利用者を特定し、この利用
者に関する個人情報を利用者情報ＤＢ４２Ａから検索し
て取り出し、その内容により資源へのアクセスを許可す
るか否かを決定する。これらの決定が、資源へのアクセ
スを許可するものである時、資源へのアクセス制限を検
証するためのチェック要求を作成する。

【００５５】ステップＣ３では、ステップＣ２で作成し
たチェック要求が、リクエスト検証部４１１Ａから資源
へのアクセス制限部４１２Ａに送出される。この資源へ
のアクセス制限を検証するモジュール（即ち、資源への
アクセス制限部４１２Ａが、資源要求指令の検証を行う
モジュール（即ち、リクエスト検証部４１１Ａ）と同一
エンティティ（即ち、資源提供サーバ４Ａ）に存在する
とは限らない。両者が異なるエンティティに存在する場
合は、リクエスト検証部４１１Ａと資源へのアクセス制
限部４１２Ａとの間で、上記チェック要求の送出の前
に、相互認証やセキュアパス確立のための問い合わせを
済ませる。

【００５６】ステップＣ４では、資源へのアクセス制限
部４１２Ａが、受け取ったチェック要求を検証して、資
源へのアクセスを許可するか、または不許可にするかを
判断する。この判断に際しては、許可データＤＢ４４Ａ
を参照する。この許可データＤＢ４４Ａには、資源の状
態（著作権等の権利状態を含む）や操作に関する許可情
報が記録されている。エンティティ（資源提供者）によ
って許可情報が異なる場合、リクエスト検証部４１１Ａ
が作成する上記チェック要求にエンティティの種別を含
ませておく。

【００５７】ステップＣ５では、チェック要求に対する
応答が資源へのアクセス制限部４１２Ａからリクエスト
検証部４１１Ａに返される。ステップＣ６では、リクエ
スト検証部４１１Ａが、資源へのアクセス制限部４１２
Ａから受け取ったチェック要求に対する応答が、資源の
利用を許可するものであった場合、資源・資源管理部４
１３Ａに対して資源要求指令に要求された処理（資源の
取り出し等）を指示する。チェック要求に対する応答
が、資源の利用を許可するものではなかった場合、ステ
ップＣ２３に進む。

【００５８】ステップＣ７では、資源・資源管理部４１
３Ａが、要求された資源情報を取り出そうとする。しか
し、この要求された資源は、資源提供サーバ４Ｂに保管
されているものであるので、資源・資源管理部４１３Ａ
は、リクエスト生成部４１４において資源提供サーバ４
Ｂに対する資源要求指令を作成してもらうための資源要
求指令作成要求を作成する。この資源要求指令作成要求
には、必要とする資源を示す情報と、資源提供者を指定
する情報とが含められる。

【００５９】ステップＣ８では、ステップＣ７で作成さ
れた資源要求指令作成要求を、リクエスト生成部４１４
に送出する。ステップＣ９では、リクエスト生成部４１
４が、資源提供サーバ４Ｂに送信する資源要求指令を作
成する。この時、この資源要求指令に含める要求者をエ
ンティティＸとするか、または資源提供サーバ４Ａとす
るかは、予め与えられたアルゴリズムにより判断する。
このアルゴリズムは、例えば、発生する費用の負担や、
資源提供サーバ４Ｂが保管する資源を必要とする条件等
から判断するようなものとすることが可能である。ま
た、資源要求指令作成要求に資源提供者が指定されてい
る場合には、資源提供者情報ＤＢ４３Ａを参照して、こ
の資源提供者の信頼性を検証しておく。さらに、資源要
求指令作成要求に資源のみが指定されて、資源提供者が
指定されていない場合には、やはり資源提供者情報ＤＢ
４３Ａを参照して、最適な資源提供者を検索する。以
下、ここでは資源提供者を資源提供サーバ４Ｂとする。

【００６０】ステップＣ１０では、リクエスト生成部４
１４が、ステップＣ９で作成した資源提供サーバ４Ｂへ
の資源要求指令を資源提供サーバ４Ｂへ送信する。この
送信に際しては、必要な相互認証がなされ、セキュアパ
スが確立される。この認証方法や、セキュアパスの作成
方法は、資源提供者情報ＤＢ４３Ａに記録されている資
源提供サーバ４Ｂに関する情報から与えられる。

【００６１】ステップＣ１１では、資源提供サーバ４Ｂ
のリクエスト検証部４１１Ｂが、ステップＣ１０で資源
提供サーバ４Ａとの認証がとれた後、資源提供サーバ４
Ａから送信された資源要求指令を検証する。

【００６２】ステップＣ１２では、リクエスト検証部４
１１Ｂが、ステップＣ１０での検証結果により、この資
源要求指令に対する応答を判断する。この資源要求指令
の検証は、エンティティＸ（利用者）を認証した資源提
供サーバ４Ａの信頼性を検証するか、または、エンティ
ティＸの信頼性を検証するかのいずれか１つの方法によ
り行う。そのいずれの方法を選択するかを決めるアルゴ
リズムは、リクエスト検証部４１１Ｂに対して予め決定
されている。資源提供サーバ４Ａの信頼性の方が検証さ
れる場合、資源提供者情報ＤＢ４３Ｂから資源提供サー
バ４Ａに関する信頼性情報を取り出し、その内容により
資源へのアクセスを許可するか否かを決定する。また、
エンティティＸの信頼性の方が検証される場合、資源提
供サーバ４Ａからの資源要求指令に含まれる利用者情報
を参照してエンティティＸを特定し、このエンティティ
Ｘに関する個人情報を利用者情報ＤＢ４２Ｂから検索し
て取り出し、その内容により資源へのアクセスを許可す
るか否かを決定する。これらの決定が、資源へのアクセ
スを許可するものである時、資源へのアクセス制限を検
証するためのチェック要求を作成する。

【００６３】ステップＣ１３では、ステップＣ１２で作
成したチェック要求が、リクエスト検証部４１１Ｂから
資源へのアクセス制限部４１２Ｂに送出される。この資
源へのアクセス制限を検証するモジュール（即ち、資源
へのアクセス制限部４１２Ｂが、資源要求指令の検証を
行うモジュール（即ち、リクエスト検証部４１１Ｂ）と
同一エンティティ（即ち、資源提供サーバ４Ｂ）に存在
するとは限らない。両者が異なるエンティティに存在す
る場合は、リクエスト検証部４１１Ｂと資源へのアクセ
ス制限部４１２Ｂとの間で、上記チェック要求の送出の
前に、相互認証やセキュアパス確立のための問い合わせ
を済ませる。

【００６４】ステップＣ１４では、資源へのアクセス制
限部４１２Ｂが、受け取ったチェック要求を検証して、
資源へのアクセスを許可するか、または不許可にするか
を判断する。この判断に際しては、許可データＤＢ４４
Ｂを参照する。この許可データＤＢ４４Ｂには、資源の
状態（著作権等の権利状態を含む）や操作に関する許可
情報が記録されている。エンティティ（資源提供者）に
よって許可情報が異なる場合、リクエスト検証部４１１
Ｂが作成する上記チェック要求にエンティティの種別を
含ませておく。

【００６５】ステップＣ１５では、チェック要求に対す
る応答が資源へのアクセス制限部４１２Ｂからリクエス
ト検証部４１１Ｂに返される。ステップＣ１６では、リ
クエスト検証部４１１Ｂが、資源へのアクセス制限部４
１２Ｂから受け取ったチェック要求に対する応答が、資
源の利用を許可するものであった場合、資源・資源管理
部４１３Ｂに対して資源要求指令に要求された処理（資
源の取り出し等）を指示する。チェック要求に対する応
答が、資源の利用を許可するものではなかった場合、ス
テップＣ１９に進む。

【００６６】ステップＣ１７では、資源・資源管理部４
１３Ｂが、要求された資源情報を取り出し、リクエスト
検証部４１１Ｂに引き渡すと共に資源の状態の記録を更
新する。但し、資源・資源管理部４１３Ｂは、要求され
た資源情報そのものは引き渡さずに、要求された資源情
報をアクセスするに必要な情報のみをリクエスト検証部
４１１Ｂに引き渡すことも可能である。

【００６７】ステップＣ１８では、リクエスト検証部４
１１Ｂが、資源・資源管理部４１３Ｂから、資源要求指
令で要求していた資源情報を受け取る。ステップＣ１９
では、資源へのアクセス制限部４１２Ｂから受け取った
チェック要求に対する応答が、資源の利用を許可するも
のであった場合、リクエスト検証部４１１Ｂは、ステッ
プＣ１８で受け取った資源情報を資源提供サーバ４Ａに
送信する形式に変換する。資源へのアクセス制限部４１
２Ｂから受け取ったチェック要求に対する応答が、資源
の利用を不許可にするものであった場合、リクエスト検
証部４１１Ｂは、不許可であることを通知する情報、及
び付帯情報が有る時は、この付帯情報とを資源提供サー
バ４Ａに送信する形式に変換する。

【００６８】ステップＣ２０では、リクエスト検証部４
１１Ｂが、ステップＣ１９で変換された送信形式の資源
情報を資源提供サーバ４Ａに送信する。ステップＣ２１
では、資源提供サーバ４Ａのリクエスト生成部４１４
が、資源提供サーバ４Ｂのリクエスト検証部４１１Ｂか
ら送信された資源情報を検証する。また、この情報に基
づき、必要ならば、利用者情報ＤＢ４２Ａや資源提供者
情報ＤＢ４３Ａの記録を更新する。さらに、この情報を
資源・資源管理部４１３Ａに送出する形式に変換する。

【００６９】ステップＣ２２では、リクエスト生成部４
１４が、上記送信形式の資源情報を資源・資源管理部４
１３Ａに送出する。ステップＣ２３では、資源・資源管
理部４１３Ａが、上記送信形式の資源情報をエンティテ
ィＸに送信する形式に変換する。また、ここでは、上記
送信形式の資源情報を資源・資源管理部４１３Ａが管理
する資源に追加することも可能である。

【００７０】ステップＣ２４では、資源・資源管理部４
１３Ａから、リクエスト検証部４１Ａに、上記エンティ
ティＸに送信する形式の資源情報を送出する。ステップ
Ｃ２５では、上記エンティティＸに送信する形式の資源
情報に対してエンティティＸに送信するために必要な処
理（例えば、署名付け等）を行う。

【００７１】ステップＣ２６では、資源提供サーバ４Ａ
からエンティティＸへ、上記処理済の送信形式の資源情
報を送信する。 （第２の実施の形態）本実施の形態は、信用格付け型モ
デルによる相互認証システムに係る。

【００７２】その特徴は、複数の認証局が発行する公開
鍵証明書に対して格付けを行うこと、作成した信用格付
け情報に基づき、信用対応表（信用性に係る対応表と保
証金額に関する対応表の２種類が有る）を作成するこ
と、証明書の問い合わせに対して、信用性応答または保
証金額応答または信用性と保証金額応答を返すこと、及
び応答内容と、格付けを行う組織自体の信用によって、
相互認証するか否かを決定することである。

【００７３】図４は、本発明の第２の実施の形態に係る
相互認証システムの全体構成を示すブロック図である。
本実施の形態に係る相互認証システムは、資源提供等の
サービスを行うサービスサーバＡ（５Ａ）、サービスサ
ーバＢ（５Ｂ）と、サービスサーバＡ（５Ａ）、サービ
スサーバＢ（５Ｂ）の窓口業務をそれぞれ担当する窓口
サーバＡ（６Ａ）、窓口サーバＢ（６Ｂ）と、複数の認
証局が発行する公開鍵証明書に対して格付けを行う格付
けサーバ８と、公開鍵証明書を含む各種証明書を発行す
る認証局Ａ（９Ａ）、認証局Ｂ（９Ｂ）と、サービスサ
ーバＡ（５Ａ）、窓口サーバＡ（６Ａ）、格付けサーバ
８、及び認証局Ａ（９Ａ）を互いに通信可能に接続する
専用通信回線Ａ（１０Ａ）と、サービスサーバＢ（５
Ｂ）、窓口サーバＢ（６Ｂ）、格付けサーバ８、及び認
証局Ｂ（９Ｂ）を互いに通信可能に接続する専用通信回
線Ｂ（１０Ｂ）と、利用者Ａ，Ｂ（図示は省略）が使用
する利用者端末Ａ（７Ａ）、利用者端末Ｂ（７Ｂ）と、
サービスサーバＡ（５Ａ）、サービスサーバＢ（５
Ｂ）、窓口サーバＡ（６Ａ）、窓口サーバＢ（６Ｂ）、
利用者端末Ａ（７Ａ）、及び利用者端末Ｂ（７Ｂ）を互
いに通信可能に接続するインターネット網１０を含む。

【００７４】ここで、専用通信回線１０Ａ、１０Ｂは、
それぞれ、その経路にインターネット網を含むことが可
能であり、また、全体がインターネット網であることも
可能であるものとする。

【００７５】また、インターネット網１０は、他の専用
通信回線で代替することが可能であるものとする。これ
ら主な各構成要素の機能は、格付けサーバ８を除いて、
図１に示す第１の実施の形態に係るネットワーク上の資
源流通システムの対応する各構成要素に準じるものとす
る。具体的には、図４に示すサービスサーバＡ（５
Ａ）、サービスサーバＢ（５Ｂ）が図１に示す資源提供
サーバ４に、図４に示す窓口サーバＡ（６Ａ）、窓口サ
ーバＢ（６Ｂ）が図１に示す窓口サーバ２に、図４に示
す利用者端末Ａ（７Ａ）、利用者端末Ｂ（７Ｂ）が図１
に示す利用者端末１に、それぞれ対応している。

【００７６】格付けサーバ８は、窓口サーバＢ（６Ｂ）
からの問い合わせに対して、信用性に係る対応表と保証
金額に関する対応表とを組み合わせた応答を返す。この
窓口サーバＢ（６Ｂ）からの問い合わせ内容には、認証
局Ａ（９Ａ）の信頼性、認証局Ａ（９Ａ）が保証する保
証内容、発生する費用の負担方法等の情報がある。

【００７７】図５は、本発明の第２の実施の形態に係る
相互認証システムの相互認証に関する動作を示す説明図
である。以下、図４，５を参照して、本実施の形態に係
る相互認証システムの相互認証に関する動作を説明す
る。

【００７８】まず、ステップＰ１では、利用者Ａ（図示
は省略）は、利用者端末Ａ（７Ａ）を使用してサービス
サーバＢ（５Ｂ）のサービス（資源提供等）を利用する
旨の要求指令（メッセージ）を作成し、窓口サーバＡ
（６Ａ）に送信する。

【００７９】ステップＰ２では、窓口サーバＡ（６Ａ）
が、利用者Ａを、自己が採用している認証方式により認
証する。また、利用者端末Ａ（７Ａ）から送信された要
求指令を解析して、サービスサーバＢ（５Ｂ）のサービ
スを利用する際に必要な窓口サーバＢ（６Ｂ）の認証を
受けるために、サービスサーバＢ（５Ｂ）に対して窓口
サーバＡ（６Ａ）が既に済ませた認証の結果を承認する
ことを求めるメッセージを作成する。この時、もしもサ
ービスサーバＢ（５Ｂ）が必要とする認証エンティティ
（認証局）が不明な場合は、ステップＰ２’にて格付け
サーバ８に対して必要な認証エンティティを問い合わせ
る。

【００８０】ステップＰ３では、ステップＰ２で作成し
たメッセージを窓口サーバＢ（６Ｂ）に送信する。但し
この際、サービス用の公開鍵証明書に基づく認証はなさ
れない。何故ならば、窓口サーバＡ（６Ａ）と窓口サー
バＢ（６Ｂ）とで、公開鍵証明書を発行している認証局
が異なっていたり、公開鍵証明書のフォーマットや認証
方式が異なっていたりする可能性が有るからである。な
お、この場面でのプロトコルについては後述する。

【００８１】ステップＰ４では、窓口サーバＢ（６Ｂ）
が、窓口サーバＡ（６Ａ）から送信されてきたメッセー
ジを解析し、要求されたサービスの利用を許可するか否
かを判断する。その際、窓口サーバＡ（６Ａ）が認証し
た利用者が利用者Ａであること、その認証に使用した公
開鍵証明書を発行している認証局が認証局Ａ（９Ａ）で
あることが確認される。これ以外に必要となる情報は、
（１）認証局Ａ（９Ａ）、（２）認証局Ａ（９Ａ）の保
証範囲（保証内容）、（３）窓口サーバＢ（６Ｂ）の方
針、（４）発生する費用の負担方法、である。

【００８２】この内、（３）の情報は、経営上の判断
や、サービスシステムとしての判断を必要とする情報で
あり、いわば人間系により決定される情報である。ま
た、（１）、（２）、（４）の情報は、（３）と同様に
人間系での解決も可能であるが、窓口サーバＡ（６Ａ）
と窓口サーバＢ（６Ｂ）との共通のシステムや枠組みの
範囲内において、格付けサーバ８が発行する信用性情報
と、保証金額対応表を参照することで入手可能となる。

【００８３】費用の発生が見込まれたり、サービスサー
バＢ（５Ｂ）が提供するサービスに対して金銭的保証が
存在する場合等には、格付けサーバ８に対して、窓口サ
ーバＡ（６Ａ）が、このサービスを許可する際の認証に
使用している公開鍵証明書の信用度と、保証金額とを問
い合わせる問い合わせメッセージを作成する。ここでは
問い合わせメッセージを作成し、格付けサーバ８が発行
する信用性情報と、保証金額対応表を参照するものとす
る。なお、この問い合わせメッセージで問い合わせるこ
とができる情報の詳細については後述する。

【００８４】ステップＰ５では、窓口サーバＢ（６Ｂ）
が、ステップＰ４で作成した問い合わせメッセージを格
付けサーバ８に送信する。この際、窓口サーバＢ（６
Ｂ）と格付けサーバ８とが、共に同じ認証局が発行した
公開鍵証明書を所持しているならば、その公開鍵証明書
を使用して相互認証し、セキュアパスを確立する。

【００８５】しかし、もしも同じ認証局が発行した公開
鍵証明書を所持していないならば、格付けサーバ８のサ
ーバ証明書に基づくＳＳＬベースのセキュアパスを確立
し、その後、窓口サーバＢ（６Ｂ）の公開鍵証明書を格
付けサーバ８に通知し、リクエストに窓口サーバＢ（６
Ｂ）が署名する。格付けサーバ８は、窓口サーバＢ（６
Ｂ）の公開鍵証明書を先ず検証する。通常、窓口サーバ
Ｂ（６Ｂ）の公開鍵証明書は、格付けサーバ８が対象と
している認証局ならば、格付けサーバ８が保持している
か、または獲得可能な状態にある。この公開鍵証明書が
存在しないということは、格付けサーバ８の信用性対応
表や保証金額対応表に記載されていない可能性が高い。
格付けサーバ８が取り扱っていなかった認証局の発行し
た証明書に関する相互認証は、相手の詳細な調査が行わ
れることもなく、「その他の認証局」としての共通の扱
いを受ける。その扱いとは、サービス拒否であるかも知
れない。

【００８６】以下では、このような事柄について検証の
結果、窓口サーバＢ（６Ｂ）が、取り扱い可能な（妥当
な）エンティティであると判断されて、相互に認証がな
されたものとする。

【００８７】ステップＰ６では、格付けサーバ８が、窓
口サーバＢ（６Ｂ）から送信された問い合わせメッセー
ジを確認する。それが妥当な問い合わせメッセージであ
った場合、信用性対応表と保証金額対応表とを組み合わ
せた回答を用意する。

【００８８】ステップＰ７では、格付けサーバ８が、こ
の回答を、ステップＰ５で確立したセキュアパスを介し
て窓口サーバＢ（６Ｂ）に送信する。ステップＰ８で
は、窓口サーバＢ（６Ｂ）が、受け取った回答を検証す
る。この回答内容が、窓口サーバＡ（６Ａ）から要求さ
れたサービスを、窓口サーバＡ（６Ａ）に提供するのに
十分なものであった場合には、必要な公開鍵ペアの生成
をセキュアパスを介して窓口サーバＡ（６Ａ）に要求す
る。これにより、窓口サーバＡ（６Ａ）は、必要な公開
鍵ペアを生成し、セキュアパスを介して窓口サーバＢ
（６Ｂ）に送信する。その他、窓口サーバＢ（６Ｂ）が
必要とする情報が有れば、窓口サーバＢ（６Ｂ）から窓
口サーバＡ（６Ａ）に要求され、その情報を窓口サーバ
Ｂ（６Ｂ）が窓口サーバＡ（６Ａ）から受け取る。その
後、ステップＰ９に進む。

【００８９】もしも、窓口サーバＢ（６Ｂ）が格付けサ
ーバ８から受け取った回答が、要求されたサービスを、
窓口サーバＡ（６Ａ）に提供するのに不十分であると判
断させるものであった場合は、窓口サーバＡ（６Ａ）の
要求に対するサービス提供拒否の回答メッセージを作成
し、窓口サーバＢ（６Ｂ）の署名を付けてステップＰ１
３に進む。

【００９０】ステップＰ９では、窓口サーバＢ（６Ｂ）
が、ステップＰ８で用意された公開鍵についての公開鍵
証明書を発行するように認証局Ｂ（９Ｂ）に要求する。
この時、必要ならば、窓口サーバＢ（６Ｂ）と認証局Ｂ
（９Ｂ）との間にセキュアパスを確立し、公開鍵以外の
情報を、このセキュアパスを介して窓口サーバＢ（６
Ｂ）から認証局Ｂ（９Ｂ）に送信する。

【００９１】ステップＰ１０では、認証局Ｂ（９Ｂ）
が、窓口サーバＢ（６Ｂ）から送信されてきた情報に基
づいて公開鍵証明書を発行する。ステップＰ１１では、
認証局Ｂ（９Ｂ）が、発行した公開鍵証明書を窓口サー
バＢ（６Ｂ）に送信する。

【００９２】ステップＰ１２では、窓口サーバＢ（６
Ｂ）が、認証局Ｂ（９Ｂ）から受け取った公開鍵証明書
を含む回答メッセージを作成し、署名を付ける。ステッ
プＰ１３では、窓口サーバＢ（６Ｂ）が、ステップＰ８
またはステップＰ１２で作成された回答メッセージを窓
口サーバＡ（６Ａ）に送信する。

【００９３】ステップＰ１４では、窓口サーバＡ（６
Ａ）が、受け取った回答メッセージを検証して改竄の無
いことを確認する。回答メッセージに公開鍵が添付され
ている場合は、この公開鍵を取り出し、サービス利用の
ために必要なリソース（資源）を確保する。

【００９４】ステップＰ１４では、利用者端末Ａ（７
Ａ）を介して利用者Ａに、サービスサーバＢ（５Ｂ）の
サービスを利用するための準備が整った旨、または、サ
ービスサーバＢ（５Ｂ）のサービスは利用できない旨を
通知する。

【００９５】図６は、本発明の第２の実施の形態に係る
相互認証システムにおいて、異なる認証局を有する認証
エンティティ（サービス窓口）間でセキュアパスを確立
してメッセージを送信する方法を示す説明図である。

【００９６】図６では、２つの認証エンティティ（窓口
サーバＡ（６Ａ）と窓口サーバＢ（６Ｂ））が、公開鍵
系の暗号を利用し、かつ、それぞれが保持する公開鍵証
明書を交付した認証局が異なるケースにおいて、窓口サ
ーバＡ（６Ａ）が、窓口サーバＢ（６Ｂ）に対してサー
ビスの利用許可を取り付ける場合を示す。

【００９７】この場合は、通常、窓口サーバＢ（６Ｂ）
のサーバ証明書を使用して、サーバ認証（但し、クライ
アント側を窓口サーバＡ（６Ａ）とする）を行い、セッ
ション鍵を共有してセキュアパス（秘匿通信路）を確立
し、窓口サーバＡ（６Ａ）から窓口サーバＢ（６Ｂ）に
メッセージを送信する。このメッセージには、送信者が
特定されるように窓口サーバＡ（６Ａ）の電子署名を付
けておく。このメッセージを受信する窓口サーバＢ（６
Ｂ）は、この電子署名を検証する。また、必要ならば、
認証局Ａ（９Ａ）の自己証明書（自己、即ち認証局Ａ
（９Ａ）を証明する証明書）を入手する。

【００９８】また、これ以外の方法として、下記の方法
が存在する。 （方法１）：窓口サーバＡ（６Ａ）の公開鍵証明書を利
用し、要求者認証（この場合は窓口サーバＡ（６Ａ）を
要求者とする）によって最初のセキュアパスを確立す
る。具体的には、窓口サーバＢ（６Ｂ）に対して、サー
バ認証（窓口サーバＢ（６Ｂ）をサーバとする）と、セ
ッション鍵の共有とによってセキュアパスを確立し、窓
口サーバＡ（６Ａ）への再接続を要求する。その際、窓
口サーバＡ（６Ａ）は、自己からの再接続要求と、これ
に対する窓口サーバＢ（６Ｂ）からの接続との対応を記
録するためにチケットを発行する。

【００９９】このチケットは、窓口サーバＡ（６Ａ）が
管理する。窓口サーバＢ（６Ｂ）は、窓口サーバＡ（６
Ａ）に対してサーバ認証とセッション鍵の共有によるセ
キュアパスを確立し、窓口サーバＡ（６Ａ）が発行した
チケットを送り返す。窓口サーバＡ（６Ａ）は、受け取
ったチケットをチェックし、妥当なクライアントである
ことを確認した後に、メッセージを送信する。

【０１００】（方法２）：窓口サーバＡ（６Ａ）と窓口
サーバＢ（６Ｂ）との、それぞれ異なる認証局、即ち認
証局Ａ（９Ａ）と認証局Ｂ（９Ｂ）が交付した公開証明
書を使用し、相互認証してセキュアパスを確立する。こ
の場合、公開証明書と署名を受け取った側は、直ちに交
付したそれぞれの認証局の公開鍵証明書を相手側から入
手する。その後、相手側の署名、公開鍵証明書をそれぞ
れ検証する。相互に認証した後、問題が無ければ、セキ
ュアパスに用いるセッション鍵について合意する。その
後、このセッション鍵を用いたセキュアパスを確立す
る。

【０１０１】なお、通信相手が特定された後、相手側の
信頼度を確認するために、図４，５に示す格付けサーバ
８に問い合わせることも可能である。当然ながら、この
格付けサーバ８への問い合わせの結果次第により、問題
が有れば、セキュアパスの確立を行わない場合も有り得
る。

【０１０２】図７は、本発明の第２の実施の形態に係る
相互認証システムにおいて、異なる暗号方式を採用する
認証エンティティ（サービス窓口）間でメッセージを送
信する方法を示す説明図である。

【０１０３】図７では、窓口サーバＡ（６Ａ）が公開系
の暗号方式以外の暗号方式を採用し、窓口サーバＢ（６
Ｂ）が公開系の暗号方式を採用している場合に窓口サー
バＡ（６Ａ）から窓口サーバＢ（６Ｂ）にメッセージを
送信する方法を示す。

【０１０４】この場合は、下記の要求を解決することが
必要となる。 （要求１）：窓口サーバＡ（６Ａ）から窓口サーバＢ
（６Ｂ）に送信されるメッセージは、窓口サーバＡ（６
Ａ）が作成したものであり、改竄された場合は、その改
竄を検知することが可能である。

【０１０５】（要求２）：窓口サーバＡ（６Ａ）から窓
口サーバＢ（６Ｂ）に送信されるメッセージは暗号化
し、盗聴されないようにすること。この（要求２）に対
しては、サーバ認証（但し、窓口サーバＢ（６Ｂ）をサ
ーバとする）と、セッション鍵の共有によるセキュアパ
スの確立で応ずることができる。

【０１０６】また、（要求１）に対しては、窓口サーバ
Ａ（６Ａ）が採用する暗号処理方式によって改竄を検知
することができる場合は、処理後に窓口サーバＢ（６
Ｂ）において改竄を検証する方法が存在する。しかし、
窓口サーバＡ（６Ａ）が採用する暗号処理方式では改竄
を検知することが不可能である場合は、そのようなエン
ティティからのメッセージを受け付けて処理するか否か
は窓口サーバＢ（６Ｂ）で判断するしか対策が無い。そ
の判断を、図４に示す格付けサーバ８に予め登録してお
くことにより、窓口サーバＡ（６Ａ）は事前にそれをチ
ェックすることで、窓口サーバＢ（６Ｂ）へのメッセー
ジが送信可能か否かを確認することができる。

【０１０７】なお、窓口サーバＡ（６Ａ）と窓口サーバ
Ｂ（６Ｂ）の双方が採用している暗号系、認証システム
に、制限事項、制約、使用条件等が有る場合は、図４に
示す格付けサーバ８に、その内容を予め登録しておくこ
とができる。

【０１０８】また、窓口サーバＡ（６Ａ）と窓口サーバ
Ｂ（６Ｂ）の双方が、公開鍵系暗号を使用しない場合に
ついては、メッセージを送信する窓口サーバＡ（６Ａ）
は、図４に示す格付けサーバ８に問い合わせて、自己が
採用する基準が、受信側エンティティ（ここでは、窓口
サーバＢ（６Ｂ））が求める基準を満たすか否かを事前
に判断することができる。

【０１０９】図８は、本発明の第２の実施の形態に係る
相互認証システムにおいて、共通の公開鍵証明書を保持
する２つの認証エンティティ（サービス窓口）間でメッ
セージを送信する方法を示す説明図である。

【０１１０】図８では、認証局Ｘ（９Ｘ）の発行サービ
スによって、証明書（例えば、サーバ証明書）のような
ものを窓口サーバＡ（６Ａ）と窓口サーバＢ（６Ｂ）の
双方が保持している場合に窓口サーバＡ（６Ａ）から窓
口サーバＢ（６Ｂ）へメッセージを送信する方法を示
す。

【０１１１】この場合は、通常の認証処理とセキュアパ
スの確立を行う。また、証明書を発行する認証局（ここ
では、認証局Ｘ（９Ｘ））を特に限定する必要が無い。
例えば、図４に示す格付けサーバ８が特に指定する認証
局の発行サービスであっても、または、それとは関係の
無い認証局の発行サービスであっても構わない。但し、
認証局（ここでは、認証局Ｘ（９Ｘ））が発行する証明
書が証明（保障）している内容が、通信相手の認証と、
セキュアパスの確立に使用できることが必要である。

【０１１２】図９は、本発明の第２の実施の形態に係る
相互認証システムにおいて格付けサーバが保持している
評価項目を例示する説明図である。図９は、認証局が発
行する各種の公開鍵証明書に対する評価項目を示す。

【０１１３】窓口サーバからの問い合わせメッセージ
は、この評価項目について問い合わせるものである。図
９では、この評価項目の一部を例示しているが、一般
に、格付けサーバ（本実施の形態では格付けサーバ８）
は、下記の評価項目についての評価を記録している。

【０１１４】（１）サービスを提供する事業会社名、
（２）サービス名、（３）サービスの種類、（４）サー
ビスを利用する際の窓口サーバ名、（５）証明書を発行
するプロセス、計算機システム、運用体制、チェックや
監査体制、（６）証明書が保障する対象、（７）証明書
が保障する範囲、（８）証明書を発行している会社（認
証局等）の経営状態（公開されている情報に基づく会社
の格付けであり、社債格付け等を参照して決定され
る）、（９）証明書に基づくサービスの利用料金（提供
可能なサービスと、その価格）、（１０）証明書に基づ
くサービスを利用した場合の料金支払い方法（相互接続
による追加料金、振込み先、決裁方法等）、（１１）他
のサービスと、相互接続の可否（認める／認めない、一
部のサービスのみ認めるといった条件等）、（１２）証
明書が使用する暗号の方式。

【０１１５】これらの評価項目と、その評価の各々は、
信頼性ＤＢデータベース）に格納される。なお、この信
頼性ＤＢを検索する時には、上記評価項目の（１）〜
（４）を検索キーとすることができる。

【０１１６】図１０は、本実施の形態に係る相互認証シ
ステムにおいて、格付けサーバと窓口サーバとの間で使
用される通信プロトコルの１例を示す説明図である。図
１０に示す通信プロトコルでは、前提として、或る１つ
の窓口サーバＸ（６Ｘ）に対して、窓口サーバＸ（６
Ｘ）が、格付けサーバ８への問い合わせ権を有するサー
バであることを証明するための公開鍵証明書を発行され
ているものとする。

【０１１７】まず、ステップＱ１では、窓口サーバＸ
（６Ｘ）が、格付けサーバ８に対して、窓口サーバＸ
（６Ｘ）の公開鍵証明書と、窓口サーバＸ（６Ｘ）の電
子署名付きのセキュアパスの確立要求（要求メッセー
ジ）を送信する。

【０１１８】ステップＱ２では、格付けサーバ８が、窓
口サーバＸ（６Ｘ）から送信された公開鍵証明書と、セ
キュアパス確立要求の電子署名を検証し、正当な要求者
であることを確認する。この確認の後、窓口サーバＸ
（６Ｘ）から送信された要求メッセージに、格付けサー
バ８の署名を付け、格付けサーバ８の公開鍵証明書と共
に窓口サーバＸ（６Ｘ）に送信する。

【０１１９】ステップＱ３では、窓口サーバＸ（６Ｘ）
が、格付けサーバ８の公開鍵証明書と、格付けサーバ８
の署名が付いた要求メッセージを確認する。ステップＱ
４では、窓口サーバＸ（６Ｘ）が、相手の計算機が正し
く格付けされたサーバ８であることを確認した後、サブ
セッション鍵を決め、サブセッション鍵送信メッセージ
を作成する。次に、作成したサブセッション鍵送信メッ
セージに窓口サーバＸ（６Ｘ）の電子署名を付けたもの
と、窓口サーバＸ（６Ｘ）の公開鍵証明書とを格付けサ
ーバ８の公開鍵で暗号化して成るメッセージを格付けサ
ーバ８に送信する。

【０１２０】ステップＱ５では、格付けサーバ８が、受
け取ったメッセージをプライベート鍵で復号化し、サブ
セッション鍵送信メッセージの電子署名を検証して、窓
口サーバＸ（６Ｘ）を確認する。その後、格付けサーバ
８は、セッション鍵を作成し、格付けサーバ８のプライ
ベート鍵で署名を付け、さらに、それをサブセッション
鍵で暗号化する。

【０１２１】ステップＱ６では、格付けサーバ８が、ス
テップＱ５で暗号化したセッション鍵と署名を窓口サー
バＸ（６Ｘ）に送信する。ステップＱ７では、窓口サー
バＸ（６Ｘ）が、受信したセッション鍵と署名をサブセ
ッション鍵で復号化し、セッション鍵と格付けサーバ８
の署名を取り出す。次に、この署名を確認し、以後、セ
ッション鍵でメッセージを暗号化する。

【０１２２】ステップＱ８では、窓口サーバＸ（６Ｘ）
が、格付けサーバ８に対して用意されている問い合わせ
メニューから選択した要求メッセージに、窓口サーバＸ
（６Ｘ）の署名を付け、セッション鍵で暗号化したメッ
セージを格付けサーバ８に送信する。

【０１２３】ステップＱ９では、格付けサーバ８が、受
け取ったメッセージを復号化し、窓口サーバＸ（６Ｘ）
の署名を検証する。要求メッセージに対する応答データ
を検索する。次に、この応答データに格付けサーバ８の
署名を付け、セッション鍵で暗号化する。

【０１２４】ステップＱ１０では、格付けサーバ８が、
ステップＱ９で暗号化した署名付きの応答データを窓口
サーバＸ（６Ｘ）に送信する。ステップＱ１１では、窓
口サーバＸ（６Ｘ）が、受信した署名付きの応答データ
をセッション鍵で復号化し、署名を確認する。

【０１２５】なお、ステップＱ１〜Ｑ７は、セキュアパ
スを確立するための他の手順や方法に置き換えることも
可能である。 （第３の実施の形態）本実施の形態は、窓口サーバに対
して格付けサーバが一時的に信用を供与するモデルによ
る相互認証システムに係る。

【０１２６】本発明の第３の実施の形態に係る相互認証
システムの構成は、本発明の第２の実施の形態に係る相
互認証システムの構成と同じである。しかし、相互認証
を実現する手順や各構成要素の処理が、本発明の第２の
実施の形態に係る相互認証システムとは異なる。

【０１２７】図１１は、本発明の第３の実施の形態に係
る相互認証システムにおける相互認証の実現方法（処理
手順）を示す説明図である。まず、ステップＵ１では、
利用者Ａ（図示は省略）は、利用者端末Ａ（７Ａ）を使
用して、サービスサーバＢ（５Ｂ）が提供するサービス
（資源の提供等）を要求するサービス要求指令を窓口サ
ーバＡ（６Ａ）に送信する。但し、利用者Ａと窓口サー
バＡ（６Ａ）との間の認証や、セキュアパスの確立は、
既に完了しているものとする。

【０１２８】ステップＵ２では、窓口サーバＡ（６Ａ）
が、受信したサービス要求指令に基づいて、サービスサ
ーバＢ（５Ｂ）が提供するサービスを受けるために必要
な信用供与を要求する要求メッセージを作成し、窓口サ
ーバＡ（６Ａ）の電子署名を付ける。

【０１２９】ステップＵ３では、窓口サーバＡ（６Ａ）
が、格付けサーバ８との公開鍵証明書に基づく相互認証
を行う（但し、格付けサーバ８は、窓口サーバＡ（６
Ａ）が作成し、発行を要求された公開鍵証明書を既に発
行しており、これは格付けサーバ８自体も使用可能であ
るものとする）。この時、必要ならばセッション鍵も合
意してセキュアパスを確立する。その後、ステップＵ２
で作成された要求メッセージを格付けサーバ８に送信す
る。

【０１３０】ステップＵ４では、格付けサーバ８が、ス
テップＵ３で送信された要求メッセージを検証し、要求
されているサービスをチェックする。この時、要求され
ているサービスの提供に必要な信用と公開鍵証明書の保
証金額とを調べ、同時に、窓口サーバＡ（６Ａ）の信用
と公開鍵証明書の保証金額とをチェックする。これによ
り、窓口サーバＡ（６Ａ）の信用や公開鍵証明書の保証
金額が不足している場合は、サービス提供に際して追加
料金を付けるか、またはサービスの提供を拒否する。ま
た、追加料金を付けてサービスを提供する場合は、窓口
サーバＡ（６Ａ）が拒否していないことを確認する。こ
れにより、サービスの提供が可能と確認された場合、サ
ービスの提供が可能である旨の通知と、サービスサーバ
Ｂ（５Ｂ）が認証している窓口サーバＢ（６Ｂ）に送信
するためのサービス利用登録要求を作成する。なお、こ
のサービスの提供が可能である旨の通知には、必要とな
る署名鍵、及び暗号鍵の鍵長や暗号方式といった条件を
含める。また、サービスの提供が不可能の場合は、サー
ビスの提供が不可能である旨の通知を作成する。

【０１３１】ステップＵ５では、ステップＵ４で作成し
た応答（サービスの提供についての通知や要求に）格付
けサーバ８の署名を付けて窓口サーバＡ（６Ａ）に送信
する。

【０１３２】ステップＵ６では、窓口サーバＡ（６Ａ）
が、受信した応答の署名を確認し、格付けサーバ８から
の応答であることを確認する。サービスの提供について
の通知が、サービスの提供が可能である旨の通知であっ
た場合は、この通知から必要な署名鍵、暗号鍵の鍵長や
暗号方式を取り出す。また、指定された方式の鍵を準備
する。即ち、公開鍵、秘密鍵のペアを準備し、この秘密
鍵をステップＵ１で受信した利用者Ａからのサービス要
求指令にリンクさせて記録しておく。

【０１３３】ステップＵ７では、窓口サーバＡ（６Ａ）
が、ステップＵ６で作成した公開鍵を格付けサーバ８に
送信する。ステップＵ８では、格付けサーバ８が、窓口
サーバＡ（６Ａ）から受信した公開鍵が指定した方式の
鍵であることを確認する。指定した方式の鍵であれば、
窓口サーバＢ（６Ｂ）に送信するためのサービス利用登
録要求を準備する。

【０１３４】以下、ステップＵ８〜Ｕ１０におけるサー
ビス利用登録準備〜証明書発行準備までの処理手順は、
複数の方法が選択可能である。 （方法１）ステップＵ９で送信するサービス利用登録要
求に、必要な情報を全て埋め込んでおく。

【０１３５】（方法２）格付けサーバ８と、窓口サーバ
Ｂ（６Ｂ）との間で、予め必要なプロトコルを決めてお
き、格付けサーバ８側が対応する。 （方法３）格付けサーバ８と、窓口サーバＢ（６Ｂ）と
の間で、予め必要なプロトコルを決めておき、窓口サー
バＢ（６Ｂ）側が対応する。

【０１３６】なお、窓口サーバＡ（６Ａ）から受信した
公開鍵が不正な鍵（指定した方式の鍵ではない）であっ
た場合は、鍵が不正である旨を通知する異常応答を作成
した後、ステップＵ２１に進む。

【０１３７】ステップＵ９では、格付けサーバ８が、ス
テップＵ４で作成したサービス利用登録要求を窓口サー
バＢ（６Ｂ）に送信するため、格付けサーバ８と窓口サ
ーバＢ（６Ｂ）との間で公開鍵証明書に基づく相互認証
を行う。この際、必要ならばセッション鍵を合意してセ
キュアパスを確立する。この後、サービス利用登録要求
を窓口サーバＢ（６Ｂ）に送信する。

【０１３８】ステップＵ１０では、窓口サーバＢ（６
Ｂ）が、受信したサービス利用登録要求を検証し、登録
すべきか、それとも拒否すべきかを判断する。拒否する
場合は、不許可応答を作成してステップＵ１９に進む。
また、許可する場合は、認証に必要なデータを、ステッ
プＵ８に記載した３方法のいずれかの方法で入手する。

【０１３９】以下、ここでは方法１を選択するものとし
て、ステップＵ１３に進む。ステップＵ１１では、方法
２または方法３を選択した場合のステップとして、窓口
サーバＢ（６Ｂ）が、認証に必要な情報を格付けサーバ
８に要求する。

【０１４０】ステップＵ１２では、方法２または方法３
を選択した場合のステップとして、格付けサーバ８が、
窓口サーバＢ（６Ｂ）に送信するための認証に必要な情
報を作成する。

【０１４１】ステップＵ１３では、格付けサーバ８が、
認証に必要なデータを窓口サーバＢ（６Ｂ）に送信す
る。方法２または方法３を選択した場合、ステップＵ１
１〜Ｕ１３を必要なだけ繰り返す。十分な情報を得た
後、ステップＵ１４に進む。

【０１４２】ステップＵ１４では、窓口サーバＢ（６
Ｂ）が、受信した認証に必要なデータを検証する。問題
が有れば不許可とし、異常応答を準備してステップＵ１
９に進む。また、問題が無ければ、認証局Ｂ（９Ｂ）と
窓口サーバＢ（６Ｂ）との間で予め決められているフォ
ーマットによる公開鍵証明書の発行要求（認証局Ｂ（９
Ｂ）に対して要求される）を作成する。なお、本来、窓
口サーバＢ（６Ｂ）と認証局Ｂ（９Ｂ）との間のプロト
コルは様々であり、ここでは、公開鍵証明書発行要求に
必要な情報を含める方法であるものとする。また、複数
回のやり取りが、ステップＵ１４〜ステップＵ１６で行
われる場合も有り得る。

【０１４３】ステップＵ１５では、認証局Ｂ（９Ｂ）と
窓口サーバＢ（６Ｂ）との間で、公開鍵証明書に基づく
相互認証が行われる。通信相手を確認した後、必要なら
ばセッション鍵を合意してセキュアパスを確立する。そ
の後、ステップＵ１４で作成した公開鍵証明書の発行要
求を認証局Ｂ（９Ｂ）に送信する。

【０１４４】ステップＵ１６では、認証局Ｂ（９Ｂ）
が、公開鍵に対する公開鍵証明書を、要求されたフォー
マットで作成し、発行する。ステップＵ１７では、認証
局Ｂ（９Ｂ）が、公開鍵証明書を、窓口サーバＢ（６
Ｂ）に送信する。

【０１４５】ステップＵ１８では、窓口サーバＢ（６
Ｂ）が、受信した公開鍵証明書に窓口サーバＢ（６Ｂ）
の署名を付ける。ステップＵ１９では、窓口サーバＢ
（６Ｂ）が、公開鍵証明書、または不許可応答、または
異常応答を、格付けサーバ８に送信する。

【０１４６】ステップＵ２０では、格付けサーバ８が、
公開鍵証明書を受信した場合、この公開鍵証明書に付け
られた窓口サーバＢ（６Ｂ）の署名を検証する。その
後、許可応答であれば、受信した窓口サーバＢ（６Ｂ）
の署名付きの公開鍵証明書に、格付けサーバ８の署名を
追加する。

【０１４７】ステップＵ２１では、格付けサーバ８が、
各署名付きの公開鍵証明書、または異常応答を、窓口サ
ーバＡ（６Ａ）に送信する。ステップＵ２２では、窓口
サーバＡ（６Ａ）が、受信した各署名付きの公開鍵証明
書を検証し、格付けサーバ８の署名を確認する。その
後、この公開鍵証明書をステップＵ６において利用者Ａ
からのサービス要求指令にリンクした秘密鍵の公開鍵、
秘密鍵のペアにリンクする。

【０１４８】ステップＵ２３では、窓口サーバＡ（６
Ａ）が、利用者端末Ａへの送信を介して、利用者Ａにサ
ービスの利用準備が整った旨を通知する。なお、図６〜
８に示したエンティティ間の認証、データ署名、暗号化
の方法については、本実施の形態にも適用可能である。
また、図９に示す認証局の評価項目は、本実施の形態に
係る認証局の評価項目として適用可能である。

【０１４９】（第４の実施の形態）本実施の形態は、公
開鍵証明書と公開鍵ペアを使用して窓口サーバに対して
格付けサーバが一時的に信用を供与するモデルによる相
互認証システムに係る。

【０１５０】本発明の第４の実施の形態に係る相互認証
システムの構成は、本発明の第２の実施の形態に係る相
互認証システムの構成と同じである。しかし、相互認証
を実現する手順や各構成要素の処理が、本発明の第２の
実施の形態に係る相互認証システムとは異なる。

【０１５１】図１２は、本発明の第４の実施の形態に係
る相互認証システムにおける相互認証の実現方法（処理
手順）を示す説明図である。まず、ステップＶ１では、
利用者Ａ（図示は省略）の利用者端末Ａ（７Ａ）と窓口
サーバＡ（６Ａ）との間で相互に認証が行われ、必要な
らばセキュアパスが確立された後、サービスサーバＢ
（５Ｂ）が提供するサービス（資源の提供等であり、以
下「サービスＢ」と呼称する）の利用を窓口サーバＡ
（６Ａ）に要求する。

【０１５２】ステップＶ２では、窓口サーバＡ（６Ａ）
が、利用者端末Ａ（７Ａ）を介した利用者Ａからの要求
を解析し、窓口サーバＡ（６Ａ）がサービスＢの利用を
許可するならば、サービスＢの利用に必要な認証を取得
するように要求する格付けサーバ８に対するメッセージ
を作成する。このメッセージには窓口サーバＡ（６Ａ）
の電子署名を付ける。

【０１５３】ステップＶ３では、格付けサーバ８と窓口
サーバＡ（６Ａ）との間で、公開鍵証明書に基づく相互
認証を行い、必要ならばセッション鍵を合意してセキュ
アパスを確立する。その後、ステップＶ２で作成したメ
ッセージを、窓口サーバＡ（６Ａ）から格付けサーバ８
に送信する。

【０１５４】ステップＶ４では、格付けサーバ８が、受
信したメッセージの電子署名を検証する。また、このメ
ッセージの内容を解析し、要求されているサービスをチ
ェックする。このサービスの提供に必要な信用と公開鍵
証明書の保証金額を調べ、他方、窓口サーバＡ（６Ａ）
の信用と公開鍵保証金額をチェックする。

【０１５５】窓口サーバＡ（６Ａ）の信用や公開鍵証明
書の保証金額が不足している場合、要求されたサービス
の提供に際して追加料金を付けるか、またはサービスの
提供を拒否する。また、追加料金を付ける場合は、窓口
サーバＡ（６Ａ）が拒否していないことを確認する。サ
ービスの提供が可能な場合は、可能応答と、サービスＢ
の窓口である窓口サーバＢ（６Ｂ）に対して送信するた
めのサービス利用登録要求とを作成する。この可能応答
には、格付けサーバ８側で割り当てたサービス識別子を
含める。なお、サービスの提供が不可能な場合は、不可
能応答を作成する。その後、これらの作成された応答に
格付けサーバ８の電子署名を付ける。

【０１５６】ステップＶ５では、ステップＶ４で作成し
た応答を窓口サーバＡ（６Ａ）に送信する。ステップＶ
６では、窓口サーバＡ（６Ａ）が、受信した応答の電子
署名を検証し、格付けサーバ８からの応答であることを
確認する。可能応答の場合は、この可能応答から提供サ
ービス識別子を取り出す（以後、格付けサーバ８に対し
て、利用者ＡからのサービスＢを利用するための問い合
わせには、この提供サービス識別子を使用する）。その
後、この提供サービス識別子を記入した応答メッセージ
を作成する。この応答メッセージには窓口サーバＡ（６
Ａ）の電子署名を付ける。

【０１５７】ステップＶ７では、窓口サーバＡ（６Ａ）
が、提供サービス識別子を記入した電子署名付きの応答
メッセージを格付けサーバ８に送信する。ステップＶ８
では、格付けサーバ８が、受信した応答メッセージの電
子署名を検証した後、窓口サーバＡ（６Ａ）の利用者で
ある利用者Ａに代わり、窓口サーバＢ（６Ｂ）の認証を
受けるために窓口サーバＢ（６Ｂ）に送信するサービス
利用登録要求を作成する。また、サービスＢを利用する
ために必要となる公開鍵・秘密鍵のペアを準備（作成）
する。鍵長や暗号方式等は調べて準備する。

【０１５８】以下、ステップＶ８〜Ｖ１０におけるサー
ビス利用登録準備〜証明書発行準備までの処理手順は、
複数の方法・プロトコルが選択可能である。 （方法１）ステップＶ９で送信するサービス利用登録要
求に、必要な情報を全て埋め込んでおく。

【０１５９】（方法２）格付けサーバ８と、窓口サーバ
Ｂ（６Ｂ）との間で、予め必要なプロトコルを決めてお
き、格付けサーバ８側が対応する。 （方法３）格付けサーバ８と、窓口サーバＢ（６Ｂ）と
の間で、予め必要なプロトコルを決めておき、窓口サー
バＢ（６Ｂ）側が対応する。

【０１６０】なお、受信した応答メッセージの電子署名
が不正であるか、またはサービス識別子が異常である場
合は、窓口サーバＡ（６Ａ）に対して異常であることを
通知するための異常応答を作成してステップＶ２１に進
む。

【０１６１】次に、送信するサービス利用登録要求に格
付けサーバ８の電子署名を付ける。ステップＶ９では、
格付けサーバ８が、ステップＶ４で作成したサービス利
用登録要求を窓口サーバＢ（６Ｂ）に送信するため、格
付けサーバ８と窓口サーバＢ（６Ｂ）との間で公開鍵証
明書に基づく相互認証を行う。この際、必要ならばセッ
ション鍵を合意してセキュアパスを確立する。この後、
サービス利用登録要求を窓口サーバＢ（６Ｂ）に送信す
る。

【０１６２】ステップＶ１０では、窓口サーバＢ（６
Ｂ）が、受信したサービス利用登録要求を検証し、登録
すべきか、それとも拒否すべきかを判断する。拒否する
場合は、不許可応答を作成してステップＶ１９に進む。
また、許可する場合は、認証に必要なデータを、ステッ
プＶ８に記載した３方法のいずれかの方法で入手する。

【０１６３】以下、ここでは方法１を選択するものとし
て、ステップＶ１３に進む。ステップＶ１１では、方法
２または方法３を選択した場合のステップとして、窓口
サーバＢ（６Ｂ）が、認証に必要な情報を格付けサーバ
８に要求する。

【０１６４】ステップＶ１２では、方法２または方法３
を選択した場合のステップとして、格付けサーバ８が、
窓口サーバＢ（６Ｂ）に送信するための認証に必要な情
報を作成する。

【０１６５】ステップＶ１３では、格付けサーバ８が、
認証に必要なデータを窓口サーバＢ（６Ｂ）に送信す
る。方法２または方法３を選択した場合、ステップＶ１
１〜Ｖ１３を必要なだけ繰り返す。十分な情報を得た
後、ステップＶ１４に進む。

【０１６６】ステップＶ１４では、窓口サーバＢ（６
Ｂ）が、受信した認証に必要なデータを検証する。問題
が有れば不許可とし、異常応答を準備してステップＶ１
９に進む。また、問題が無ければ、認証局Ｂ（９Ｂ）と
窓口サーバＢ（６Ｂ）との間で予め決められているフォ
ーマットによる公開鍵証明書の発行要求（認証局Ｂ（９
Ｂ）に対して要求される）を作成する。なお、本来、窓
口サーバＢ（６Ｂ）と認証局Ｂ（９Ｂ）との間のプロト
コルは様々であり、ここでは、公開鍵証明書発行要求に
必要な情報を含める方法であるものとする。また、複数
回のやり取りが、ステップＶ１４〜ステップＶ１６で行
われる場合も有り得る。

【０１６７】ステップＶ１５では、認証局Ｂ（９Ｂ）と
窓口サーバＢ（６Ｂ）との間で、公開鍵証明書に基づく
相互認証が行われる。通信相手を確認した後、必要なら
ばセッション鍵を合意してセキュアパスを確立する。そ
の後、ステップＶ１４で作成した公開鍵証明書の発行要
求を認証局Ｂ（９Ｂ）に送信する。

【０１６８】ステップＶ１６では、認証局Ｂ（９Ｂ）
が、公開鍵に対する公開鍵証明書を、要求されたフォー
マットで作成し、発行する。ステップＶ１７では、認証
局Ｂ（９Ｂ）が、公開鍵証明書を、窓口サーバＢ（６
Ｂ）に送信する。

【０１６９】ステップＶ１８では、窓口サーバＢ（６
Ｂ）が、受信した公開鍵証明書に窓口サーバＢ（６Ｂ）
の署名を付ける。ステップＶ１９では、窓口サーバＢ
（６Ｂ）が、公開鍵証明書、または不許可応答、または
異常応答を、格付けサーバ８に送信する。

【０１７０】ステップＶ２０では、格付けサーバ８が、
公開鍵証明書を受信した場合、この公開鍵証明書に付け
られた窓口サーバＢ（６Ｂ）の署名を検証する。その
後、受信した窓口サーバＢ（６Ｂ）の署名付きの公開鍵
証明書を、提供サービス識別子とリンクした公開鍵・秘
密鍵のペアとリンクさせる。その後、登録成功通知を作
成し、格付けサーバ８の電子署名を付ける。

【０１７１】ステップＶ２１では、格付けサーバ８が、
電子署名付きの登録成功通知を、窓口サーバＡ（６Ａ）
に送信する。ステップＶ２２では、窓口サーバＡ（６
Ａ）が、受信した電子署名付きの登録成功通知を検証
し、格付けサーバ８の署名を確認する。その後、提供サ
ービス識別子を使用したサービス要求を有効とする利用
者Ａへの通知メッセージを作成する。

【０１７２】ステップＶ２３では、窓口サーバＡ（６
Ａ）が、利用者Ａの利用者端末Ａへ、利用者Ａへの通知
メッセージを送信する。なお、図６〜８に示したエンテ
ィティ間の認証、データ署名、暗号化の方法について
は、本実施の形態にも適用可能である。また、図９に示
す認証局の評価項目は、本実施の形態に係る認証局の評
価項目として適用可能である。

【０１７３】

【発明の効果】以上に説明したとおり、本発明では、ネ
ットワーク上の資源流通システムに、資源提供サーバの
窓口業務を代行する窓口サーバを設置すると共に、窓口
サーバに、利用者を認証するに必要な利用者情報を記録
する第１の利用者情報データベースと、ネットワークコ
ミュニティ内の資源提供者（エンティティ）の信用度を
記録する第１の資源提供者情報データベースとを備え、
さらに、資源提供サーバにも、窓口サーバを認証するた
めに必要な情報を記録する第２の資源提供者情報データ
ベースと、窓口サーバが認証した利用者に関する情報を
含む利用者情報を記録する第２の利用者情報データベー
スとを備えたので、複数のエンティティの各々が保管す
る資源を、このエンティティの各々が相互に利用し合う
ことができるようになる。

【０１７４】また、複数のコミュニティから成るネット
ワークコミュニティに、複数のコミュニティのいずれか
に属する複数の認証局の各々が発行する公開鍵証明書を
それぞれ評価する機能を有する格付けサーバを設置し、
複数のコミュニティのいずれかに属する複数の窓口サー
バ間で、互いの信用度、及び使用する公開鍵証明書の信
用度や保証金額をチェックするようにしたので、複数の
エンティティの各々が提供するサービスを、このエンテ
ィティの各々が相互に利用し合う際に必要となる相互認
証を効果的に実現することができる。

【図面の簡単な説明】

【図１】本発明の第１の実施の形態に係るネットワーク
上の資源流通システムの全体構成を示すブロック図であ
る。

【図２】本発明の第１の実施の形態に係るネットワーク
上の資源流通システムの１例としての動作を示す説明図
である。

【図３】本発明の第１の実施の形態に係るネットワーク
上の資源流通システムの他の１例としての動作を示す説
明図である。

【図４】本発明の第２の実施の形態に係る相互認証シス
テムの全体構成を示すブロック図である。

【図５】本発明の第２の実施の形態に係る相互認証シス
テムの相互認証に関する動作を示す説明図である。

【図６】本発明の第２の実施の形態に係る相互認証シス
テムにおいて、異なる認証局を有する認証エンティティ
（サービス窓口）間でセキュアパスを確立してメッセー
ジを送信する方法を示す説明図である。

【図７】本発明の第２の実施の形態に係る相互認証シス
テムにおいて、異なる暗号方式を採用する認証エンティ
ティ（サービス窓口）間でメッセージを送信する方法を
示す説明図である。

【図８】本発明の第２の実施の形態に係る相互認証シス
テムにおいて、共通の公開鍵証明書を保持する２つの認
証エンティティ（サービス窓口）間でメッセージを送信
する方法を示す説明図である。

【図９】認証局が発行する各種の公開鍵証明書に対する
評価項目を示す。

【図１０】本実施の形態に係る相互認証システムにおい
て、格付けサーバと窓口サーバとの間で使用される通信
プロトコルの１例を示す説明図である。

【図１１】本発明の第３の実施の形態に係る相互認証シ
ステムにおける相互認証の実現方法（処理手順）を示す
説明図である。

【図１２】本発明の第４の実施の形態に係る相互認証シ
ステムにおける相互認証の実現方法（処理手順）を示す
説明図である。

【符号の説明】

１……利用者端末、２……窓口サーバ、３……通信回
線、４……資源提供サーバ、５Ａ，５Ｂ……サービスサ
ーバＡ，Ｂ、６Ａ，６Ｂ……窓口サーバＡ，Ｂ、７Ａ，
７Ｂ……利用者端末Ａ，Ｂ、８……格付けサーバ、９
Ａ，９Ｂ……認証局Ａ，Ｂ、１０……インターネット
網、１１，２１，４１……制御部、１２……ダウンロー
ドＤＢ（データベース）、１３，２４，４５……通信
部、２２，４２……利用者情報ＤＢ（データベース）、
２３，４３……資源提供者情報ＤＢ（データベース）、
４４……許可データＤＢ（データベース）、１１２…要
求作成部、１１１…認証部、２１１…利用者認証部、２
１２…リクエスト生成部、４１１…リクエスト検証部、
４１２…資源へのアクセス制限部、４１３…資源・資源
管理部

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁷ 識別記号 ＦＩ テーマコート゛(参考） Ｇ０６Ｆ 17/60 ３３０ Ｇ０６Ｆ 17/60 ３３０ ５１２ ５１２ Ｈ０４Ｌ 9/32 Ｈ０４Ｌ 9/00 ６７５Ｂ

Claims (15)

【特許請求の範囲】
1. 【請求項１】 １以上の資源提供サーバが提供する資源
   を、１以上の利用者が、前記資源提供サーバと通信回線
   で接続された利用者端末を介して要求し、前記要求した
   資源を前記通信回線を介して前記利用者端末にダウンロ
   ードして利用するネットワーク上の資源流通システムに
   おいて、 前記利用者の認証に必要な情報を記録する第１の利用者
   情報データベースと、資源提供者の信頼性の検証に必要
   な情報を記録する第１の資源提供者情報データベースと
   を備え、前記利用者の任意の１つの利用者端末から送信
   される前記資源提供サーバへの資源要求の窓口となっ
   て、前記資源要求に対応する資源要求指令を前記資源要
   求に指定された前記資源提供サーバに送信する１以上の
   窓口サーバと、 前記窓口サーバの認証に必要な情報を記録する第２の資
   源提供者情報データベースと、前記窓口サーバが認証し
   た前記利用者に関する情報を取り出し可能に記録する第
   ２の利用者情報データベースと、前記利用者に提供する
   資源へのアクセス制限を記録する許可データデータベー
   スとを備え、前記窓口サーバの任意の１つからの資源要
   求に応答して資源を送信する資源提供サーバと、 を備えたことを特徴とするネットワーク上の資源流通シ
   ステム。
2. 【請求項２】 前記窓口サーバは、前記利用者の利用者
   端末からの資源要求を受信した時を起点として、前記第
   １の利用者情報データベースを参照して前記利用者の認
   証を行うと共に、前記認証がとれた場合に、引き続き前
   記第１の資源提供者情報データベースを参照して前記資
   源要求に指定された資源提供者の信頼性を検証し、前記
   資源提供者が信頼できる資源提供者であることが確認さ
   れた場合に、前記資源提供サーバに前記資源要求に対応
   した資源要求指令を送信することを特徴とする請求項１
   記載のネットワーク上の資源流通システム。
3. 【請求項３】 前記資源提供サーバは、前記窓口サーバ
   からの資源要求指令を受信した時を起点として、前記第
   ２の資源提供者情報データベースを参照して前記窓口サ
   ーバの認証を行うと共に、前記認証がとれた場合に、要
   求された資源を提供するか否かの決定を、前記認証時に
   参照した前記第２の資源提供者情報データベース内の前
   記窓口サーバに関する情報を参照するか、または前記窓
   口サーバが認証した前記利用者に関する情報を前記第２
   の利用者情報データベースにより参照して行うことを特
   徴とする請求項１記載のネットワーク上の資源流通シス
   テム。
4. 【請求項４】 前記資源提供サーバは、前記窓口サーバ
   からの資源提供要求を受信した時を起点として、前記窓
   口サーバからの資源要求指令が自己以外の他の資源提供
   サーバの資源を要求するものであった場合に、前記自己
   以外の他の資源提供サーバに対して、資源要求指令を送
   信し、前記自己以外の他の資源提供サーバから前記資源
   要求指令で要求した資源を入手した後、前記入手した資
   源を前記窓口サーバに送信することを特徴とする請求項
   １記載のネットワーク上の資源流通システム。
5. 【請求項５】 前記利用者端末から前記窓口サーバへの
   資源要求、及び前記窓口サーバから前記資源提供サーバ
   への資源要求指令は、暗号化されていることを特徴とす
   る請求項１記載のネットワーク上の資源流通システム。
6. 【請求項６】 前記利用者端末から前記窓口サーバへの
   資源要求、及び前記窓口サーバから前記資源提供サーバ
   への資源要求指令の送信に際しては、暗号化／復号化に
   係る暗号鍵の証明書ベースの相互認証を行うことを特徴
   とする請求項１記載のネットワーク上の資源流通システ
   ム。
7. 【請求項７】 前記利用者端末から前記窓口サーバへの
   資源要求、及び前記窓口サーバから前記資源提供サーバ
   への資源要求指令の送信に際しては、セッション鍵を合
   意し、セキュアパスを確立することを特徴とする請求項
   ６記載のネットワーク上の資源流通システム。
8. 【請求項８】 １以上のサービスサーバと、前記サービ
   スサーバが提供するサービスを利用する１以上の利用者
   と、前記サービスサーバと前記利用者の利用者端末とを
   仲介する１以上の窓口サーバから成る第１のコミュニテ
   ィと、前記第１のコミュニティと同様の構成要素を含む
   コミュニティから成る第２のコミュニティとを含むネッ
   トワークコミュニティにおける相互認証システムであっ
   て、 前記第１のコミュニティに属する窓口サーバの任意の１
   つが作成した公開鍵証明書を発行する第１の認証局と、 前記第２のコミュニティに属する窓口サーバの任意の１
   つが作成した公開鍵証明書を発行する第２の認証局と、 前記第１の認証局、及び前記第２の認証局がそれぞれ発
   行した公開鍵証明書を所定の評価項目に基づいて評価し
   た評価情報を記録する信頼性データベースを具備する格
   付けサーバと、 を有することを特徴とする相互認証システム。
9. 【請求項９】 前記窓口サーバからの前記格付けサーバ
   への問い合わせの内容には、前記公開鍵証明書の信用性
   に関する情報と、前記公開鍵証明書の保証金額に関する
   情報とを含むことを特徴とする請求項８記載の相互認証
   システム。
10. 【請求項１０】 前記第１のコミュニティに属する窓口
    サーバは、前記利用者端末からのサービス利用要求が送
    信された時を起点として、前記サービス利用要求に指定
    された前記第２のコミュニティに属する窓口サーバに関
    する情報を前記格付けサーバに問い合わせ、前記格付け
    サーバからの前記問い合わせに対応する応答を参照して
    前記利用者への応答を決めることを特徴とする請求項８
    記載の相互認証システム。
11. 【請求項１１】 前記第２のコミュニティに属する窓口
    サーバは、前記第１のコミュニティに属する窓口サーバ
    からのサービス利用要求が送信された時を起点として、
    前記第１のコミュニティに属する窓口サーバが使用して
    いる公開鍵証明書の信用性に関する情報と、前記公開鍵
    証明書の保証金額に関する情報とを前記格付けサーバに
    問い合わせ、前記格付けサーバからの前記問い合わせに
    対応する応答を参照して前記第１のコミュニティに属す
    る窓口サーバへの応答を決めることを特徴とする請求項
    ８記載の相互認証システム。
12. 【請求項１２】 前記格付けサーバは、前記第１及び第
    ２のコミュニティに属する窓口サーバからの前記公開鍵
    証明書の評価を求める問い合わせに応じて、前記評価情
    報を参照して作成した前記公開鍵証明書の評価結果を前
    記窓口サーバに通知することを特徴とする請求項８記載
    の相互認証システム。
13. 【請求項１３】 前記格付けサーバは、前記第１のコミ
    ュニティに属する窓口サーバからの、前記第２のコミュ
    ニティに属するサービスサーバが提供するサービスを利
    用するに必要な信用度の検証を要求するメッセージを受
    信した時を起点として、前記第１のコミュニティに属す
    る窓口サーバの信用度を検証し、前記信用度に問題が無
    い場合に、前記第２のコミュニティに属するサービスサ
    ーバが提供するサービスを利用するために必要な暗号鍵
    の公開鍵証明書を前記第２のコミュニティに属する窓口
    サーバを介して前記第２のコミュニティに属する認証局
    に発行させ、前記発行された公開鍵を前記第２のコミュ
    ニティに属する窓口サーバを介して取り寄せて前記第１
    のコミュニティに属する窓口サーバに送信することを特
    徴とする請求項８記載の相互認証システム。
14. 【請求項１４】 前記格付けサーバは、前記信用度の検
    証をクリアした前記第１のコミュニティに属する窓口サ
    ーバから送信された公開鍵を検証し、前記公開鍵が前記
    暗号鍵の仕様に基づく正当な公開鍵であった場合には、
    前記第２のコミュニティに属するサービスサーバが提供
    するサービスを前記第２のコミュニティに属する窓口サ
    ーバを介して利用するに必要な公開鍵証明書を、前記第
    ２のコミュニティに属する認証局から、前記第２のコミ
    ュニティに属する窓口サーバを介して取り寄せて前記第
    １のコミュニティに属する窓口サーバに送信することを
    特徴とする請求項１３記載の相互認証システム。
15. 【請求項１５】 前記信用度の検証内容には、前記第２
    のコミュニティに属するサービスサーバが提供するサー
    ビスを利用するに必要な信用度及び公開鍵証明書の保証
    金額と、前記第１のコミュニティに属する窓口サーバの
    信用度及び公開鍵証明書とを比較検討することが含まれ
    ることを特徴とする請求項１３記載の相互認証システ
    ム。