(57)【要約】【課題】ユーザがサービスを享受しようとする際に、その際のユーザの形態およびアクセス環境に影響されずに、当該サービスをユーザが享受可能な新規な主体（サブジェクト）を生成でき、しかも生成された主体の信頼性を保証できるようにする。【解決手段】主体生成部（主体生成・関連付け手段）１１２は、外部からサービス要求が与えられる毎に、新たな主体（サブジェクト）を生成する。信頼保証情報検証部１１４は、サービス要求側の主体の信頼性を検証する。主体信頼保証情報生成部（主体生成・関連付け手段）１１５は、サービス要求側の主体の信頼性が信頼保証情報検証部１１４によって確認されたならば、新たな主体と当該信頼性が確認された主体とを関連付けする。【選択図】      図２
2008108203.tif 000002
【特許請求の範囲】
【請求項１】
サービス提供装置によって提供されるサービスを享受する主体を管理する主体動的制御装置であって、
外部から与えられる前記サービス提供装置に対するサービス要求に応じて、サービス要求側の主体の信頼性を検証する検証手段と、
前記サービス要求に応じて新たな主体を生成して、当該新たな主体と前記検証手段によって信頼性が確認された少なくとも一つ以上の主体とを関連付けする主体生成・関連付け手段とを具備することを特徴とする主体動的制御装置。
【請求項２】
前記検証手段によって信頼性が確認された主体と関連付けされた前記新たな主体を前記サービス提供装置に提供することで、前記サービス要求側に代わってサービスを要求するサービス要求手段
を更に具備することを特徴とする請求項１記載の主体動的制御装置。
【請求項３】
前記サービス要求側の主体の信頼性が特定の認証装置によって保証されていることを示す当該主体の信頼保証情報を取得する信頼保証情報取得手段を更に具備し、
前記検証手段は、前記信頼保証情報取得手段によって取得された信頼保証情報の信頼性を検証することで、当該信頼保証情報に対応する主体の信頼性を確認する
ことを特徴とする請求項１記載の主体動的制御装置。
【請求項４】
前記信頼保証情報取得手段は、前記サービス要求側の主体の信頼保証情報を前記認証装置から当該サービス要求側によって取得させることにより、当該サービス要求側から前記信頼保証情報を取得し、
前記主体生成・関連付け手段は、前記検証手段によって信頼性が確認された主体の前記信頼保証情報に基づいて、前記新たな主体の信頼保証情報を生成する主体信頼保証情報生成手段を含み、前記主体信頼保証情報生成手段は、前記新たな主体の信頼保証情報を生成することにより前記新たな主体と前記検証手段によって信頼性が確認された主体とを関連付けする
ことを特徴とする請求項３記載の主体動的制御装置。
【請求項５】
サービス提供装置によって提供されるサービスを享受する主体を管理するコンピュータに、
外部から与えられる前記サービス提供装置に対するサービス要求に応じて、サービス要求側の主体の信頼性を検証するステップと、
前記サービス要求に応じて新たな主体を生成して記憶手段に格納するステップと、
前記新たな主体と前記検証するステップによって信頼性が確認された少なくとも一つ以上の主体とを前記記憶手段内で関連付けするステップと
を実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サービスを享受する主体（サブジェクト）を管理する技術に係わり、特に、外部からのサービス要求に応じてサービス要求側の主体と結合された新たな主体を生成して管理するのに好適な主体動的制御装置及びプログラムに関する。
【背景技術】
【０００２】
近年、種々の電子サービスが普及している。この電子サービスによれば、ユーザがパーソナルコンピュータ、店頭端末等のクライアント装置（端末装置）を操作して当該クライアント装置からサービスプロバイダ装置（サービス提供装置）にサービスを要求することで、ユーザは当該プロバイダ装置から所望のサービスを享受できる。
【０００３】
電子サービスにおいては、そのサービスに対してユーザ・アカウントなどのアイデンティティ（Identity）を登録して利用することが多い。アイデンティティのライフルサイクル管理は、当該アイデンティティに対応するサービスの種類に依存する。このため、複数種類のサービスを利用する場合には、ユーザは一般に、サービス毎に事前にアイデンティティの登録処理をする必要がある。
【０００４】
一方、最近では、ネットワーク上に分散されるアイデンティティの相互参照を可能とするネットワークアイデンティティ技術が確立しつつあり、業界標準化団体によってその仕様（業界標準仕様）が策定され、公開もされている（例えば、非特許文献１参照）。このネットワークアイデンティティ技術により、分散傾向にあるアイデンティティのインターオペラビリティ（相互運用性）を確保し、高信頼化されたアイデンティティの活用が可能となってきている。
【０００５】
ネットワークアイデンティティ技術では、サービスを享受する対象を表現するサブジェクト（subject）または主体という概念が導入されている。一般的にサブジェクトは概念的用語として用いられるが、本発明においては、サービスを享受するためにアクセスしてきた対象を情報処理的に取り扱うための具体的な情報として以後取り扱う。より詳しくは、本発明におけるサブジェクトとは、少なくとも一つの識別情報と、任意の属性情報によって構成される情報であるとする。識別情報は、サブジェクトを一意に識別可能な識別子である。また、属性情報は、サブジェクトに関連する追加的な情報である。サブジェクトの好適な例としては、Java (登録商標) 2 SDKの認証と認可の標準機構である、Java Authentication and Authorization Service（JAAS）におけるSubjectが挙げられる。Subjectは、特定の単一エンティティに関する関連情報をグループ化した情報である。Subjectにより、Javaアプリケーションは、アクセスしてきた対象を識別したり、パスワードなどのセキュリティ関連属性を取得することができる。
【０００６】
通常、固定的なサブジェクトの扱いでは、ユーザがサービスを享受するための登録処理を行う必要があるため、ユーザ負担を強いることになる。
【０００７】
その一方、ネットワークアイデンティティ技術では、複数のアカウントを相互に連携するアカウント・リンキングに代表される、サブジェクトを関連付けする手法も実現されている。そこで、この手法を適用し、他のアカウントに属するプロファイル情報（つまり、アイデンティティ情報）を参照することにより、ユーザの登録処理時における入力負担を減らすことが可能となる。
【０００８】
また、アカウント・リンキングの手法に関し、ネットワークアイデンティティ技術とは異なる技術であるものの、例えば家族のメンバなど、複数のユーザが同時に同一サービスを享受するものにおいて、当該複数のユーザ（家族メンバ）のアクセス制御情報をユーザ情報アクセス制御装置にてバインド（結合）する手法が提案されている（例えば、特許文献１参照）。但し特許文献１に記載された手法は、複数のユーザ（家族メンバ）をバインドしたアカウント（家族アカウント）を、ユーザ情報アクセス制御装置に事前登録するという暗黙的なユーザ登録を前提とする。
【特許文献１】特開２００２−２８８１３５（段落００１４、段落００１９、段落００２４−００２９、図１、図３、図４）
【非特許文献１】Liberty Alliance Project（リバティ・アライアンス・プロジェクト）,Liberty Alliance ID-FF 1.2 Specifications,[online], 2004年9月12日, [平成16年12月6日検索],インターネット<URL:http://www.projectliberty.org/specs/liberty-idff-1.2-20040912.zip>
【発明の開示】
【発明が解決しようとする課題】
【０００９】
上記したように、非特許文献１に記載されたネットワークアイデンティティ技術によれば、サブジェクトを関連付けする手法を適用して、他のアカウントに属するプロファイル情報を参照することにより、ユーザの登録処理時における入力負担を減らすことが可能となる。しかしながら、アカウントの登録処理自体は各サービスで事前に必要であることから、従来のサブジェクトを関連付けする手法は、固定的なサブジェクト利用にならざるを得ないことが容易に予想される。また、従来技術の多くは、サブジェクトのプリンシパル（Principal：ここではサブジェクトの実体として表現する）が同一であることを前提としているため、異なるプリンシパルのサブジェクトを動的にリンキングまたはバインディングすることはあまり考えられていない。グループアカウントのように、異なるプリンシパルのサブジェクトをバインディングするような例もあるが、これもバインディング対象が既存のアカウントであり、動的なバインディングとは異なる。また、特許文献１に記載された複数のユーザ（家族メンバ）のアクセス制御情報をバインドする手法も、暗黙的なユーザ登録を前提しており、動的なバインディングとは異なる。
【００１０】
上記非特許文献１には、アカウント・リンキングの概念としてのフェデレーション（Federation）と呼ばれる連携形態について記載されている。この連携形態は、連携されるアイデンティティが対等な関係を前提としており、階層的にアイデンティティを連携することは想定していない。
【００１１】
また、ゲストユーザのような一時的で匿名な利用形態の場合、信頼性を確保しようとすると、サブジェクトの秘密性を確保することが難しくなることが知られている。このため、現在提供されているサービスの多くは、信頼性もしくは秘密性の何れか一方を確保するに留まっている。
【００１２】
今後、ユーザが享受するサービスやアクセス環境、ユーザ形態が多様になり、リアルタイムでのサービス提供が求められると予想される。ゆえに、ユーザが享受するサービスと、ユーザの形態や環境に特化した、複数のプリンシパルのサブジェクトをバインディングするような、より柔軟なサブジェクトを取扱うことのできる仕組みが要求される。また、そのサブジェクトの信頼性と秘密性を両立できるような仕組みも求められる。しかし、上述した従来技術は、このような要求に応えられるものではない。
【００１３】
本発明は上記事情を考慮してなされたものでその目的は、ユーザがサービスを享受しようとする際に、その際のユーザの形態およびアクセス環境に影響されずに、当該サービスをユーザが享受可能な新規な主体（サブジェクト）を生成でき、しかも生成された主体の信頼性を保証できる主体動的制御装置及びプログラムを提供することにある。
【課題を解決するための手段】
【００１４】
本発明の１つの観点によれば、サービス提供装置によって提供されるサービスを享受する主体を管理する主体動的制御装置が提供される。この主体動的制御装置は、外部から与えられるサービス提供装置に対するサービス要求に応じて、サービス要求側の主体の信頼性を検証する検証手段と、上記サービス要求に応じて新たな主体を生成して、当該新たな主体と上記検証手段によって信頼性が確認された少なくとも一つ以上の主体とを関連付けする主体生成・関連付け手段とを備える。
【００１５】
上記した構成においては、外部からサービス要求が与えられる毎に、主体生成・関連付け手段によって、新たな主体（サブジェクト）が生成される。つまり、サービス要求毎に、新たな主体が動的に生成される。また、サービス要求側（例えば、ユーザおよび／または当該ユーザによる操作に応じてサービス要求を送出するクライアント装置）の主体、つまりレルム（Realm：ここでは、属するエンティティ間で信頼関係が確立可能で、かつ当該主体の信頼性を保証するための認証を行う認証装置により管理される領域として表現）に属している主体の信頼性が検証手段によって検証される。ここで、サービス要求側の主体の信頼性が確認されたならば、新たな主体と当該信頼性が確認された主体とが関連付け（バインド）される。この関連付け後の新たな主体がサービス提供装置に提供される。
【００１６】
このように上記の構成においては、外部からサービス要求が与えられる毎に、その要求されたサービスを享受する新たな主体が動的に生成される。これにより、ユーザにサービスを享受するために事前の登録処理を強いることなく、柔軟な主体の取り扱いが可能となる。しかも、上記構成においては、新たな主体が、サービス要求側の信頼性が確認された主体とバインドされる。このサービス要求側の信頼性が確認された主体としては、一般にサービスを必要とするユーザおよび／または当該ユーザがサービス要求のために直接または間接に利用するクライアント装置である。このように、新たな主体が、サービス要求側の信頼性が確認された主体とバインドされることで、当該新たな主体が動的に生成されるものでありながら、当該新たな自身の信頼性も保証されたものとすることができる。したがって、この新たな主体をサービス提供装置に提供することで、ユーザの利用する機器（クライアント装置）やアクセス経路などの主体の環境を考慮した、サービスを享受するための適切なアクセス制御が実現可能となる。
【００１７】
ここで、サービス要求側の主体の信頼性が特定の認証装置によって保証されていることを示す当該主体の信頼保証情報を取得する信頼保証情報取得手段を追加するならば、この信頼保証情報取得手段によって取得された信頼保証情報の信頼性を検証するだけで、当該信頼保証情報に対応する主体の信頼性を簡単かつ確実に確認できる。
【００１８】
また、信頼保証情報取得手段が、サービス要求側の主体の信頼保証情報を特定の認証装置から当該サービス要求側によって取得させることにより、当該サービス要求側から上記信頼保証情報を取得する構成とすると良い。このようにすると、サービス要求側と認証手段との間のネゴシエーションにより、信頼保証情報に含まれる当該サービス要求側に関連する情報を当該サービス要求側のポリシーに従って（サービスが要求するポリシーに合致する範囲内で）制限することが可能となるため、上記新たな主体の信頼性と秘密性とを両立させることが可能となる。
【００１９】
また、新たな主体と信頼性が確認された主体とをバインドするには、検証手段によって信頼性が確認された主体の信頼保証情報に基づいて、新たな主体の信頼保証情報を生成すると良い。特に、新たな主体の信頼保証情報に、検証手段によって信頼性が確認された主体の信頼保証情報を含めるならば、新たな主体の信頼性と秘密性とを効果的に両立させることが可能となる。
【００２０】
なお、サービスを享受する主体を管理する上記主体動的制御装置に係わる本発明は、サービスを享受する主体をコンピュータにより管理する主体動的制御方法に係わる発明、更にはサービスを享受する主体を管理するためのプログラムに係わる発明として捉えることも可能である。
【発明の効果】
【００２１】
本発明によれば、外部からサービス要求が与えられる毎に、要求されたサービスを享受する新たな主体が動的に生成されることから、ユーザにサービスを享受するために事前の登録処理を強いることなく、柔軟な主体の取り扱いが実現できる。しかも本発明によれば、新たな主体が、サービス要求側の信頼性が確認された主体と関連付け（バインド）されることで、当該新たな主体が動的に生成されるものでありながら、当該新たな主体自身の信頼性も保証されたものとすることができ、ユーザの利用する機器やアクセス経路などの主体の環境を考慮した、サービスを享受するための適切なアクセス制御が実現できる。
【発明を実施するための最良の形態】
【００２２】
以下、本発明の実施の形態につき図面を参照して説明する。  
［第１の実施形態］
図１は本発明の第１の実施形態に係わる主体動的制御装置１１を含む電子サービスシステムの構成を示すブロック図である。同図に示すように、主体動的制御装置１１はネットワークＮＷ上に存在する。ネットワークＮＷ上には、サービスを享受するユーザが操作するのに用いられる、クライアント装置１２を始めとする複数のクライアント装置が存在する。図１には、クライアント装置１２以外のクライアント装置については省略されている。主体動的制御装置１１は例えばコンピュータによって実現され、サービスを享受する主体（サブジェクト）を動的に生成して管理する。つまり主体動的制御装置１１は、ユーザの操作に従ってクライアント装置１２から与えられるサービス要求に応じて、そのサービスを享受する新たな主体を生成して管理する。本実施形態では、この主体動的制御装置１１が各サービスのポータルとして動作することを想定している。つまり、主体動的制御装置１１は、サービス提供に関し、ポータルサーバとして位置付けられる。
【００２３】
なお、ここでの主体は、少なくとも一つの識別情報と、任意の属性情報によって構成される情報である。識別情報は、主体を一意に識別可能な識別子であり、少なくとも次に述べるレルムの範囲内で一意であることが望ましい。属性情報は、主体に関連する追加的な情報であり、様々な情報を含めることができる。一般的には、プリンシパルの住所や年齢、性別などが挙げられる。主体が非人間的な装置に関連付けられているのであれば、装置の種別や搭載OSなどの装置に関する情報がこれにあたる。また、主体が自身を証明するための認証要素情報（クレデンシャル）も属性情報に含めてもよい。属性情報は、サービスで必要とする情報であり、どのような属性情報を必要とするかはサービス毎に異なり、属性情報を必要としないケースも想定され、そのような場合には主体には属性情報を含めなくともよい。
【００２４】
ネットワークＮＷ上にはまた、信頼関係が構築された既存レルムが複数存在する。レルム（Realm）とは、当該レルムに属するエンティティ（サブジェクトの実体）間で信頼関係が確立可能で、かつ次に述べるトラストアンカにより管理される概念的な領域（一種のドメイン）を指す。複数のレルムの各々には信頼関係を管理するエンティティであるトラストアンカが存在する。図１の例では、２つのトラストアンカＴＡ１およびＴＡ２が存在する。トラストアンカＴＡ１およびＴＡ２は、それぞれ自身が存在する、信頼関係が確立されたレルムを管理する。トラストアンカＴＡ１は、例えば公的ユーザ情報を保証するための公的認証を行うユーザ認証サーバ（認証装置）である。トラストアンカＴＡ２は、例えば機器情報を保証するための機器認証を行う外部認証サーバ（認証装置）である。
【００２５】
ネットワークＮＷ上にはまた、ユーザＵを始めとする複数のユーザに各種のサービスを提供するサービス提供装置としてのサービスプロバイダ装置１３も存在する。このサービスプロバイダ装置１３は、ネットワークＮＷ上のいずれかのトラストアンカＴＡｉ（ここではｉは１または２）が管理するレルムに属する。サービスプロバイダ装置１３は、レルムで確立された信頼関係を、サービスを提供する際における信頼性の根拠とする。
【００２６】
図２は、主体動的制御装置１１の機能構成を示すブロック図である。同図に示すように、主体動的制御装置１１は、インタフェース部１１１と、主体生成部１１２と、主体管理部１１３と、信頼保証情報検証部１１４と、主体信頼保証情報生成部１１５と、主体制御部１１６と、記憶部１１７とを備えている。インタフェース部１１１は外部との通信インタフェースをなす。主体生成部１１２はユーザの操作に伴うクライアント装置からのサービス要求に応じて新たな主体を生成する。主体管理部１１３は生成された主体を管理する。信頼保証情報検証部１１４は、ユーザＵまたはクライアント装置１２から送信される信頼保証情報を検証する。主体信頼保証情報生成部１１５は、生成された主体に関する信頼保証情報を生成する。主体制御部１１６は、主体生成のための制御を行う。記憶部１１７は、主体管理部１１３によって管理される主体の情報（アカウント情報）等を記憶するのに用いられる。
【００２７】
主体動的制御装置１１内の主体生成部１１２、主体管理部１１３、信頼保証情報検証部１１４、主体信頼保証情報生成部１１５および主体制御部１１６は、コンピュータにインストールされた所定のソフトウェアプログラム（主体動的制御ソフトウェア）を当該コンピュータ（内のＣＰＵ）が読み取って実行することにより実現される。このプログラムは、コンピュータで読み取り可能な記憶媒体に予め格納して頒布可能である。また、このプログラムが、ネットワークを介してダウンロード（頒布）されても構わない。
【００２８】
次に、図１のシステムにおける動作について、図３および図４を参照して説明する。なお、図３は図１のシステムにおける動作の手順を示すシーケンスチャート、図４は主体動的制御装置１１によって生成される主体のアカウント情報の一例を示す。
【００２９】
今、ユーザＵが、サービスプロバイダ装置１３によるサービスの提供を必要とするものとする。この場合、ユーザＵは、例えばクライアント装置１２を操作して、当該クライアント装置１２から主体動的制御装置１１に対して、サービスプロバイダ装置１３によるサービスの提供を要求するためのサービス要求を発行させる（ステップＳ１）。このサービス要求は、主体動的制御装置１１のインタフェース部１１１で受信されて、主体制御部１１６に渡される。
【００３０】
主体制御部１１６は、インタフェース部１１１で受信されたサービス要求を受けとると、当該サービス要求で要求されたサービスを享受する新たな主体を生成する必要があると判断する。ここで、ユーザＵおよびクライアント装置１２は、それぞれ異なる主体（元の主体）のプリンシパルである。
【００３１】
主体制御部１１６は、まず主体管理部１１３に対して、新たな主体の生成を要求する。主体生成部１１２は、この主体生成要求に従い、インタフェース部１１１で受信されたサービス要求に関連するユーザＵおよびクライアント装置１２（つまりサービス要求側のユーザＵおよびクライアント装置１２）に対応し、要求されたサービスを享受する新たな主体を生成する（ステップＳ２）。但し、この段階では、新たな主体の識別情報４１（図４参照）が、当該主体のアカウント情報の一部として生成されるだけであり、属性情報は存在しない。生成された主体のアカウント（アイデンティティ）情報（識別情報４１）は、記憶部１１７の所定領域（主体管理領域）に格納される。
【００３２】
次に、主体制御部１１６はユーザＵおよびクライアント装置１２の各々に固有の主体、即ち異なるプリンシパルの主体（元の主体）の信頼性を確認するために信頼保証情報取得手段として機能して、クライアント装置１２に対して、ユーザＵおよび当該クライアント装置１２の各々の信頼保証情報を要求する（ステップＳ３）。ここでは主体制御部１１６は、上記ステップＳ１で要求されたサービスの提供に必要な条件（サービスのポリシー）として、ユーザおよびクライアント装置各々（に固有の主体）の信頼保証情報が必要であることが、主体制御部１１６とサービスプロバイダ装置１３との間のネゴシエーションで既に分かっているものとする。
【００３３】
ユーザＵおよび／またはクライアント装置１２は、主体制御部１１６からの信頼保証情報要求に応じて、当該ユーザＵおよびクライアント装置１２１に適した１つまたは複数の特定のトラストアンカと信頼関係を確立する。ここでは、ユーザＵに関しては、ユーザ認証サーバであるトラストアンカＴＡ１との間で、クライアント装置１２に関しては外部認証サーバであるトラストアンカＴＡ２との間で、それぞれ信頼関係が確立されるものとする（ステップＳ４，Ｓ６）。
【００３４】
トラストアンカＴＡ１は、ユーザＵを始めとする複数のユーザ各々のアカウント情報を保持している。トラストアンカＴＡ２は、クライアント装置１２を始めとする複数のクライアント装置各々（に固有の主体）のアカウント情報を保持している。
【００３５】
トラストアンカＴＡ１およびＴＡ２は、それぞれ、ユーザＵおよびクライアント装置１２との信頼関係を確立すると、当該ユーザＵおよびクライアント装置１２の各々の信頼保証情報をユーザＵまたはクライアント装置１２、例えばクライアント装置１２に送出する（ステップＳ５，Ｓ８）。このユーザＵおよびクライアント装置１２の信頼保証情報は、それぞれ、トラストアンカＴＡ１およびＴＡ２が保持しているユーザＵおよびクライアント装置１２各々のアカウント情報（つまりユーザＵおよびクライアント装置１２各々に固有の主体）を保証する情報である。この信頼保証情報として、認証アサーションや公開鍵証明書が挙げられる。信頼保証情報は、周知のように、信頼できる第三者（TTP：Third Trusted Party）などにより主体（サブジェクト）の信頼性を保証した情報であり、電子的に信頼性を検証することができる。
【００３６】
ユーザＵおよびクライアント装置１２の信頼保証情報が、それぞれ、当該ユーザＵおよびクライアント装置１２に固有の主体（のアカウント情報）を保証したトラストアンカＴＡ１およびＴＡ２の識別（ＩＤ）情報を含んでいても構わない。また、ユーザＵおよびクライアント装置１２の信頼保証情報が、それぞれ、当該ユーザＵおよびクライアント装置１２に固有の属性情報を含んでいても構わない。
【００３７】
信頼保証情報に含まれる属性情報は、ユーザＵまたはクライアント装置１２の主導により、それぞれ、当該ユーザＵまたはクライアント装置１２とトラストアンカＴＡ１またはＴＡ２との間のネゴシエーションによって決定することができる。つまり、信頼保証情報に含まれる属性情報を、ユーザＵまたはクライアント装置１２自身が制限することができる。この信頼保証情報は、後述するように、主体動的制御装置１１からサービスプロバイダ装置１３に渡される。しかし、この信頼保証情報に含まれる属性情報がユーザＵまたはクライアント装置１２によって制限されることから、ユーザＵまたはクライアント装置１２の秘密性を確保できる。但し、サービスプロバイダ装置１３が提供するサービスの種類によって、最低限必要とされる属性情報が予め定められている。このため、要求されたサービスを享受するには、信頼保証情報には、当該サービスに最低限必要とされる属性情報が含まれている必要がある。
【００３８】
クライアント装置１２は、ユーザＵおよびクライアント装置１２の信頼保証情報が、それぞれトラストアンカＴＡ１およびＴＡ２から送出されると、先のステップＳ３での主体動的制御装置１１からの信頼保証情報要求に対する応答として、当該ユーザＵおよびクライアント装置１２の信頼保証情報を主体動的制御装置１１に送出する（ステップＳ８）。このユーザＵおよびクライアント装置１２の信頼保証情報は、主体動的制御装置１１のインタフェース部１１１で受信され、信頼保証情報取得手段として機能している主体制御部１１６に渡される。
【００３９】
主体制御部１１６は、インタフェース部１１１で受信されたユーザＵおよびクライアント装置１２の信頼保証情報を受けとると当該信頼保証情報を記憶部１１７の所定領域（一時領域）に格納して、当該信頼保証情報の検証を信頼保証情報検証部１１４に要求する。信頼保証情報検証部１１４は、要求された信頼保証情報の信頼性を検証することで、当該信頼保証情報に対応する主体の信頼性を確認する（ステップＳ９）。なお、認証アサーションや公開鍵証明書等の信頼保証情報の検証手法は従来から良く知られている。したがって本実施形態では、検証の手法自体に関する説明は省略されている。
【００４０】
信頼保証情報検証部１１４による信頼保証情報の検証結果は主体制御部１１６に通知される。主体制御部１１６は、要求されたユーザＵおよびクライアント装置１２の信頼保証情報の信頼性が確認された場合、当該信頼保証情報を、新たに生成された主体の信頼性根拠として利用する。即ち主体制御部１１６は主体信頼保証情報生成部１１５を制御して、記憶部１１７の一時領域に格納されている、信頼性が確認されたユーザＵおよびクライアント装置１２の信頼保証情報に基づき、ステップＳ２で新たに生成された主体に関する信頼保証情報を生成させる。これにより、例えば図４に示す信頼保証情報４２１および４２２が、新たに生成された主体のアカウント情報（アイデンティティ情報）の属性情報の一部として生成される（ステップＳ１０）。
【００４１】
生成された信頼保証情報（信頼保証情報４２１および４２２）は、記憶部１１７の主体管理領域に格納されている、新たに生成された主体のアカウント情報に含まれている識別情報４１とリンク付けされて、当該主体管理領域に格納される。信頼保証情報４２１および４２２は、例えばユーザＵおよびクライアント装置１２の信頼保証情報である。
【００４２】
以上の説明から明らかなように、上記ステップＳ１０において、信頼保証情報４２１および４２２が新たに生成された主体（新たな主体）のアカウント情報の属性情報の一部として生成されることにより、当該新たな主体に、インタフェース部１１１で受信されたサービス要求に関連するユーザＵおよびクライアント装置１２（サービス要求側）に固有の主体（元の主体）が関連付け（バインド）される。本実施形態では、このステップＳ１０により、新たな主体の生成が完了する。
【００４３】
主体動的制御装置１１は、ステップＳ１０で生成された信頼保証情報によって、サービス要求側の主体と関連付けられた新たな主体をサービスプロバイダ装置１３に対して提供することで、ユーザＵまたはクライアント装置１２に代わって、当該サービスプロバイダ装置１３に対してサービスを要求する（ステップＳ１１）。ここで、新たな主体をサービスプロバイダ装置１３に提供することは、当該新たな主体のアカウント情報（アイデンティティ情報）を当該サービスプロバイダ装置１３に提供（通知）することを意味する。この新たな主体のアカウント情報は、当該新たな主体の信頼保証情報を構成する、要求されたサービスの提供に必要なサービス要求側の主体の信頼保証情報（ここでは、ユーザＵおよびクライアント装置１２の信頼保証情報）を含んでいる。
【００４４】
サービスプロバイダ装置１３は、主体動的制御装置１１により提供される新たな主体に関する信頼保証情報（を構成するサービス要求側の主体の信頼保証情報）に基づいて当該新たな主体の信頼性を確認することで（ステップＳ１２）、例えばクライアント装置１２を介してユーザＵに対するサービス提供を行う（ステップＳ１３）。
【００４５】
上述したように、本実施形態では、サービスプロバイダ装置１３に対する外部からのサービス要求を主体動的制御装置１１が受け付ける毎に、当該サービス要求で要求されたサービスを享受する新たな主体が生成される。つまり、この新たなサービスは一時的なものである。そこで本実施形態では、生成された主体は主体管理部１１３によってライフサイクル管理され、予め定められたルールに基づいて記憶部１１７から削除される。ここでは、説明を簡略化するために、主体の生成時点から一定時間経過後に当該主体（のアカウント情報）が削除されるものとするが、これ以外のルールであっても構わない。
【００４６】
以上により本実施形態においては、ユーザＵとクライアント装置１２との組み合わせを前提とするアカウントを予め登録しておかなくても、ユーザＵがクライアント装置１２を操作して所望のサービスを要求するだけで、当該サービスに固有のアカウント（アイデンティティ）を持つ新たな主体を自動生成することから、ユーザＵは当該サービスの提供を受けることができる。しかも、サービス要求側の主体（実施形態では、ユーザＵおよびクライアント装置１２にそれぞれ対応する主体）の信頼性は、トラストアンカからサービス要求側に与えられる信頼保証情報により保証されるため、この信頼保証情報によってサービス要求側の元の主体と関連付けされる新たな主体の信頼性は保証される。加えて、信頼保証情報に含まれるユーザＵまたはクライアント装置１２の属性情報は、当該ユーザＵまたはクライアント装置１２自身が決定できるため、秘密性を保つことができる。
【００４７】
上記実施形態では、ユーザＵおよびクライアント装置１２各々の信頼保証情報が、要求されたサービスの提供に必要である場合を想定している。しかし、要求されるサービスによっては、サービス要求に関連する全ての主体（元の主体）の信頼保証情報を必要としないこともある。したがって、新たな主体に、サービス要求に関連する全ての主体のうちの一部（少なくとも１つ）が関連付けられるものであっても構わない。
【００４８】
また、上記実施形態では、主体制御部１１６（主体動的制御装置１１）が、サービスの種類毎に、そのサービスに必要な主体の信頼保証情報を、サービスプロバイダ装置１３とのネゴシエーションによって予め把握している場合を想定している。しかし、主体制御部１１６が、サービスに必要な主体の信頼保証情報を必ずしも把握している必要はない。この場合、主体制御部１１６は、サービス要求に関連する全ての主体の信頼保証情報を取得して、その全ての信頼保証情報により、新たな主体に、当該サービス要求に関連する全ての主体を関連付けし、要求されたサービスを提供するための必要条件となる信頼性情報をサービスプロバイダ装置１３に選択させるようにしても構わない。
【００４９】
［第２の実施形態］
次に本発明の第２の実施形態について図面を参照して説明する。図５は本発明の第２の実施形態に係わる主体動的制御装置１１を含む電子サービスシステムの構成を示すブロック図である。図５において、図１と同様な要素には同一参照符号を付してある。
【００５０】
第２の実施形態の特徴は、ネットワークＮＷ上に、クライアント装置１２に加えて、もう１つの別のクライアント装置１２０が存在し、ユーザＵは２つ（複数）のクライアント装置１２および１２０の任意の１つまたは両方を利用して、サービスプロバイダ装置１３からサービスの提供を受けることを可能とした点にある。ここで、クライアント装置１２０がコンビニエンスストア等に設置される店頭端末であるものとする。しかも、このクライアント装置（店頭端末）１２０が、主体動的制御装置１１を内蔵しているものとする。一方、クライアント装置１２は、クライアント装置（店頭端末）１２０との間で無線通信が可能な携帯端末、例えば携帯電話機であるものとする。またネットワークＮＷ上には、トラストアンカＴＡ１に代えて、クライアント装置（携帯電話機）および当該クライアント装置（携帯電話機）を所有するユーザの情報を保証するトラストアンカＴＡ１０が存在するものとする。
【００５１】
以下、図５のシステムにおける動作を、ユーザＵがクライアント装置（携帯電話機）１２およびクライアント装置（店頭端末）１２０の両方を用いてサービスプロバイダ装置１３からサービスの提供を受ける場合を例に、図６の動作の流れ図を参照して説明する。
【００５２】
まずユーザＵがクライアント装置（店頭端末）１２０を操作して、何らかのサービス要求のための操作を行ったものとする（ステップＳ２１）。すると、クライアント装置（店頭端末）１２０は、ユーザＵに対して、クライアント装置（携帯電話機）１２をクライアント装置（店頭端末）１２０との間で無線通信可能な状態にさせるための操作案内メッセージを出力（表示または音声により出力）する。ユーザＵが、このメッセージに従う動作を行った結果、クライアント装置（携帯電話機）１２とクライアント装置（店頭端末）１２０との間で無線通信可能な状態になったものとする。この場合、クライアント装置（店頭端末）１２０内では、主体動的制御装置１１により上記ステップＳ２に相当する動作、つまり新たな主体を生成する動作（ここでは、新たな主体の識別情報の生成）が行われる。また、主体動的制御装置１１により信頼保証情報要求が発行される。
【００５３】
クライアント装置（店頭端末）１２０は、主体動的制御装置１１により信頼保証情報要求が発行されたことを検出すると、クライアント装置（携帯電話機）１２に対して当該信頼保証情報要求を送信する（ステップＳ２２）。これによりクライアント装置（携帯電話機）１２はトラストアンカＴＡ１０との間で信頼関係を確立し（ステップＳ２３）、当該トラストアンカＴＡ１０からクライアント装置（携帯電話機）１２自身の信頼保証情報およびユーザＵの信頼保証情報を取得する（ステップＳ２４）。クライアント装置（携帯電話機）１２は、取得した自身の信頼保証情報およびユーザＵの信頼保証情報をクライアント装置（店頭端末）１２０に送信する（ステップＳ２５）。
【００５４】
一方、クライアント装置（店頭端末）１２０は、トラストアンカＴＡ２との間で信頼関係を確立し（ステップＳ２６）、当該トラストアンカＴＡ１０からクライアント装置（店頭端末）１２０自身の信頼保証情報を取得する（ステップＳ２７）。クライアント装置（店頭端末）１２０が取得した、ユーザＵ、クライアント装置（携帯電話機）１２およびクライアント装置（店頭端末）１２０各々の信頼保証情報を、当該クライアント装置（店頭端末）１２０内の主体動的制御装置１１に渡す。
【００５５】
以降の動作は、上記第１の実施形態と同様である。即ち、主体動的制御装置１１では、ユーザＵ、クライアント装置（携帯電話機）１２およびクライアント装置（店頭端末）１２０各々の信頼保証情報が検証され、これらの信頼保証情報の信頼性が確認されると、新たな主体に関する信頼保証情報が生成される。第２の実施形態では、新たな主体に関する信頼保証情報には、ユーザＵ、クライアント装置（携帯電話機）１２およびクライアント装置（店頭端末）１２０各々の信頼保証情報が用いられる。これにより、新たな主体に、要求されたサービスに関連するユーザＵ、クライアント装置（携帯電話機）１２およびクライアント装置（店頭端末）１２０各々に固有の主体（元の主体）が関連付けされる。主体動的制御装置１１は、この関連付け後の新たな主体をクライアント装置（店頭端末）１２０によりサービスプロバイダ装置１３に提供させることで、サービスプロバイダ装置１３に対して、ステップＳ２１で要求されたサービスを要求する（ステップＳ２８）。
【図面の簡単な説明】
【００５６】
【図１】本発明の第１の実施形態に係わる主体動的制御装置１１を含む電子サービスシステムの構成を示すブロック図。
【図２】上記主体動的制御装置１１の機能構成を示すブロック図。
【図３】図１のシステムにおける動作の流れを示すシーケンスチャート。
【図４】主体動的制御装置１１によって生成される新たな主体のアカウント情報の主要部の一例を示す図。
【図５】本発明の第２の実施形態に係わる電子サービスシステムの構成を示すブロック図。
【図６】図１のシステムにおける動作の流れを示す図。
【符号の説明】
【００５７】
１１…主体動的制御装置、１２，１２０…クライアント装置、１３…サービスプロバイダ装置、１１１…インタフェース部、１１２…主体生成部（主体生成・関連付け手段）、１１３…主体管理部、１１４…信頼保証情報検証部、１１５…主体信頼保証情報生成部（主体生成・関連付け手段）、１１６…主体制御部（信頼保証情報取得手段、サービス要求手段）、１１７…記憶部１１７、Ｕ…ユーザ、ＴＡ１，ＴＡ２，ＴＡ１０…トラストアンカ、ＮＷ…ネットワーク。
【図１】
2008108203.tif 000003
【図２】
2008108203.tif 000004
【図３】
2008108203.tif 000005
【図４】
2008108203.tif 000006
【図５】
2008108203.tif 000007
【図６】
2008108203.tif 000008