登録情報管理システム
【課題】複数のサイトに登録された情報への一括した処理を容易とする登録情報管理システムを提供する。
【解決手段】登録情報管理システムが，ネットワーク上の複数のサイトにそれぞれ登録され，かつ同一の個人の属性情報を有する複数の登録属性情報ファイルへの処理を要求する処理要求情報を受信する手段と，前記受信される処理要求情報に基づき，前記複数の登録属性情報ファイルへの一括処理を要求する一括処理メッセージを生成する手段と，前記生成される一括処理メッセージに基づき，前記複数の登録属性情報ファイルそれぞれへの処理を要求する複数の個別処理メッセージを生成する手段と，前記生成される複数の個別処理メッセージを前記複数のサイトに送信する手段と，を具備する。
【解決手段】登録情報管理システムが，ネットワーク上の複数のサイトにそれぞれ登録され，かつ同一の個人の属性情報を有する複数の登録属性情報ファイルへの処理を要求する処理要求情報を受信する手段と，前記受信される処理要求情報に基づき，前記複数の登録属性情報ファイルへの一括処理を要求する一括処理メッセージを生成する手段と，前記生成される一括処理メッセージに基づき，前記複数の登録属性情報ファイルそれぞれへの処理を要求する複数の個別処理メッセージを生成する手段と，前記生成される複数の個別処理メッセージを前記複数のサイトに送信する手段と，を具備する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は，ネットワーク上の登録情報を管理する登録情報管理システムに関する。
【背景技術】
【０００２】
電子サービスにおいて，そのサービスの利用者のユーザ・アカウント，住所，氏名，電話番号，年齢などの属性情報（アイデンティティ（Identity））を登録することがある。例えば，あるポータルサイトを利用して買い物をする場合，利用者（ユーザ，以降，プリンシパルと記述）がアイデンティティをポータルサイトで登録する必要がある。複数のサービスを利用する場合，通例，プリンシパルが複数のサービスに登録し，各サービスがアイデンティティのライフサイクルを管理する。
【０００３】
最近では，ネットワークに分散されるアイデンティティの相互参照を可能とするネットワークアイデンティティ技術が確立しつつある。これにより，分散されたアイデンティティのインターオペラビリティ（相互運用性）を確保しながら，高信頼化されたアイデンティティを活用することが可能となってきている。アイデンティティの相互参照により，プリンシパルにより適したサービスの提供が容易となる。
【０００４】
例えば，Liberty Alliance Projectで策定されているLiberty Alliance仕様では，アイデンティティのリソース解決のためのサービス仕様としてLiberty ID-WSF Discovery Service Specification（以降，Discovery Serviceと表記する）や，アイデンティティ情報の取得/修正を行うデータサービスのためのテンプレート仕様としてLiberty ID-WSF Data Services Template Specification（以降，DSTと表記する），Liberty ID-WSF上で公開される具体的なアイデンティティサービス仕様としてID-SIS Personal Profile Service Specification（以降，ID-SIS-PPと表記する）などが公開されている（非特許文献１〜３参照）。
【非特許文献１】Liberty Alliance Project, “Liberty ID-WSF Discovery Service Specification, Version 1.1”, [online],2003年11月12日, [平成16年12月24日検索], インターネット <URL: http://www.projectliberty.org/specs/liberty-idwsf-disco-svc-v1.1.pdf>
【非特許文献２】Liberty Alliance Project, “Liberty ID-WSF Data Services Template Specification, Version 1.0”, [online],2003年11月12日, [平成16年12月24日検索], インターネット <URL: http://www.projectliberty.org/specs/liberty-idwsf-dst-v1.0.pdf>
【非特許文献３】Liberty Alliance Project, “Liberty ID-SIS Personal Profile Service Specification, Version 1.0”, [online],2003年11月12日, [平成16年12月24日検索], インターネット <URL: http://www.projectliberty.org/specs/liberty-idsis-pp-v1.0.pdf >
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら，アイデンティティ所有者（プリンシパル）自身が分散管理されているアイデンティティを統括管理することは必ずしも容易でない。例えば，プリンシパルがアイデンティティを様々なサービスに登録している場合，自分のアイデンティティ情報を自分自身でメンテナンスする必要がある。しかし，複数の場所に管理されるアイデンティティを個別にメンテナンスすることは，プリンシパルの負担となる。例えば，プリンシパルの住所が変更になった場合，住所情報が登録されているサービスを探し出し，各サービスで管理されているアイデンティティ情報の中から住所情報を修正しなければならない。
【０００６】
本発明は，複数のサイトに登録された情報への一括した処理を容易とする登録情報管理システムを提供することを目的とする。
【課題を解決するための手段】
【０００７】
本発明の一態様に係る登録情報管理システムは，ネットワーク上の複数のサイトにそれぞれ登録され，かつ同一の個人の属性情報を有する複数の登録属性情報ファイルへの処理を要求する処理要求情報を受信する処理要求情報受信手段と，前記受信される処理要求情報に基づき，前記複数の登録属性情報ファイルへの一括処理を要求する一括処理メッセージを生成する一括処理メッセージ生成手段と，前記生成される一括処理メッセージに基づき，前記複数の登録属性情報ファイルそれぞれへの処理を要求する複数の個別処理メッセージを生成する個別処理メッセージ生成手段と，前記生成される複数の個別処理メッセージを前記複数のサイトに送信する個別処理メッセージ送信手段と，を具備することを特徴とする。
【発明の効果】
【０００８】
本発明によれば，複数のサイトに登録された情報への一括した処理を容易とする登録情報管理システムを提供できる。
【発明を実施するための最良の形態】
【０００９】
以下，図面を参照して，本発明の実施の形態を詳細に説明する。
（第１の実施の形態）
図１は，本発明の第１実施形態に係る登録情報管理システム１００を表すブロック図である。
登録情報管理システム１００は，プリンシパルコンピュータ１１０，ポータルサイトサーバ１２０，属性プロバイダサーバ１３０，リソース情報検索プロバイダサーバ１４０を備える。
【００１０】
登録情報管理システム１００は，異なるドメインに対応する複数の属性プロバイダサーバ１３０で管理されるリソースの構造情報や属性情報などのデータ操作を一括して処理するFacade Data Service（以降，FDSと表記する）を提供する。属性プロバイダサーバ１３０毎に個別に行っていた取得や修正などの処理を一括して実行することができる。
【００１１】
本実施形態では，FDSを提供する本体はポータルサイトサーバ１２０である。後述する第２の実施形態では，ポータルサイトサーバとＦＤＳサーバとの連携によってFDSを提供すると共に，ＦＤＳサーバがプリンシパルの代理人として機能する。なお，本実施形態では，プリンシパル自体が一括処理の主体であることから，認証処理は含まれない。
【００１２】
FDSの一例として，プリンシパル（電子サービスの利用者）の属性情報（アイデンティティ）の一括処理を行うアイデンティティサービス（Facade Query and Modify Service（以降，FQMSと表記する））を挙げることができる。
【００１３】
プリンシパルの属性は，電子サービス上に登録されたプリンシパルのユーザ・アカウント，住所，氏名，電話番号，年齢などの個人情報である。電子サービスにおいて，プリンシパルそれぞれの属性はリソースと呼ばれるファイル（登録属性情報ファイル）に登録される。即ち，プリンシパルそれぞれに対応して，リソースが存在する。
プリンシパルのリソースの構造情報や存在場所情報（場所情報）を含めたリソースに関する情報全般がリソース情報である。
【００１４】
プリンシパルコンピュータ１１０は，プリンシパル（サービス利用者）が操作するコンピュータである。プリンシパルコンピュータ１１０は，そのプリンシパルの属性情報の一覧を要求する入力手段，例えば，キーボードと，この要求に応じて，そのプリンシパルの属性情報の一覧を提示する表示部，例えば，液晶表示装置を備える。
【００１５】
ポータルサイトサーバ１２０は，プリンシパルコンピュータ１１０とネットワーク（例えば，インターネット）で接続されるコンピュータであり，例えば，インターネット上のポータルサイトに配置される。ポータルサイトサーバ１２０は，一括処理メッセージ生成部１２１，メッセージ一括処理部１２２，リソース解決部１２３，アプリケーション１２４を有する。
【００１６】
一括処理メッセージ生成部１２１，メッセージ一括処理部１２２は，アプリケーション１２４のプロキシとして属性情報の一括処理を担うものであり，ポータルサイトサーバ１２０のライブラリを用いて構築できる。
一括処理メッセージ生成部１２１は，属性プロバイダサーバ１３０で管理されている属性情報を一括処理（取得又は修正）する際に用いる一括処理メッセージを生成する。
【００１７】
メッセージ一括処理部１２２は，一括処理メッセージ解釈部１２５，一括代理処理部１２６を有する。
一括処理メッセージ解釈部１２５は，一括処理メッセージを解釈する。
一括代理処理部１２６は，属性情報を提供する属性プロバイダサーバ１３０に対して処理要求を行い，その結果を１つにまとめてアプリケーション１２４に返す。一括代理処理部１２６は，個別処理メッセージを生成する個別処理メッセージ生成手段およびと個別処理メッセージを前記複数のサイトに送信する個別処理メッセージ送信手段して機能する。
【００１８】
リソース解決部１２３は，リソースを解決すると共に，プリンシパルのリソース場所情報を提供するものであり，登録属性情報ファイルの複写に含まれる属性の項目を抽出する抽出手段として機能する。即ち，ここでいうリソースの解決は，プリンシパルの属性の項目を抽出することにある。
リソース解決部１２３は，リソース情報検索プロバイダサーバ１４０にプリンシパルを識別するプリンシパル識別子を送り，リソース情報検索の検索を要求し，リソース情報（リソース場所情報を含む）を受け取る。リソース解決部１２３はリソース情報を解析して，そのリソース情報に含まれる属性の項目を抽出する。
【００１９】
ソース解決部１２３は，リソース情報（登録属性情報ファイル）の構造を定義するリソース構造定義情報を含むリソース構造定義テーブルを保持するデータベース（リソース構造定義ＤＢ）を有する。ソース解決部１２３は，リソース構造定義テーブルを用いてリソース情報から属性の項目を抽出する。なお，リソース構造の定義の例として，Discovery Serviceでの<ResourceOffering>を挙げることができる。
【００２０】
リソース構造定義テーブルで構造が定義されないリソース情報については，属性プロバイダサーバ１３０から取得されるリソース構造定義情報を用いて，属性の項目を抽出する。ソース解決部１２３は，取得したリソース情報の構造定義情報がリソース構造定義ＤＢ中に格納されていない場合に，そのリソース情報の構造の検索を属性プロバイダサーバ１３０に要求し，リソース構造定義情報を取得する。
【００２１】
アプリケーション１２４は，プリンシパルコンピュータ１１０とのユーザインタフェースの役割を果たし，属性情報の一括処理を行うためにリソース解決部１２３に要求を送り，その結果をプリンシパルコンピュータ１１０に提供する。アプリケーション１２４は，抽出される属性の項目を提示する提示手段および処理要求情報を受信する処理要求情報受信手段として機能する。
【００２２】
属性プロバイダサーバ１３０は，ポータルサイトサーバ１２０とネットワーク（例えば，インターネット）で接続されるコンピュータであり，プリンシパルの属性情報を管理する属性プロバイダに対応する。属性プロバイダサーバ１３０は，要求に応じて属性情報を提供する属性情報提供部１３１を有する。
【００２３】
リソース情報検索プロバイダサーバ１４０は，ポータルサイトサーバ１２０とネットワーク（例えば，インターネット）で接続されるコンピュータであり，プリンシパルが所有するリソース情報を管理する。リソース情報検索プロバイダサーバ１４０は，要求に応じてリソース情報を検索するリソース情報検索部１４１を有する。
【００２４】
リソース情報検索部１４１は，データベース（リソース情報ＤＢ）を有する。リソース情報ＤＢは，プリンシパル識別子，プリンシパルのリソース情報（そのプリンシパルの属性情報が登録されている属性プロバイダサーバ１３０のアドレス（リソースの場所情報）を含む）を対応して保持する。即ち，リソース情報ＤＢは，プリンシパル（個人）と，リソース（登録属性情報ファイル）の複写と，を対応して記憶する記憶手段として機能する。
【００２５】
リソース情報検索部１４１がプリンシパル識別子に基づきリソース情報データベースを検索することで，そのプリンシパルのリソース情報およびリソース場所情報を得ることができる。リソース情報およびリソースの場所情報の組み合わせは，そのプリンシパルの属性情報が登録されている電子サービス毎に存在する。
【００２６】
このリソース情報に含まれる属性情報は，属性プロバイダサーバ１３０に登録されている属性情報と本質的に異なるものではない。但し，属性プロバイダサーバ１３０上の属性情報は，登録されている属性情報（登録属性情報）そのものであるのに対し，リソース情報データベース上の属性情報は登録されている属性情報のコピー（複写属性情報）である。
【００２７】
このため，リソース情報データベース上のリソース情報は登録リソース情報と食い違う可能性がある（登録リソース情報への変更が複写登録情報に反映されることが必ずしも保証されない）。また，その逆に，複写登録情報を変更しても，登録リソース情報が変更される訳でもない。
以上のように，リソース情報データベース上のリソース情報は，プリンシパルの便宜のために，登録されているリソース情報（登録リソース情報）のコピー（複写リソース情報）を集積したものである。
【００２８】
（登録情報管理システム１００の動作）
図２は，登録情報管理システム１００での処理の流れの概要を示したシーケンス図である。図３は，登録情報管理システム１００での処理の流れの詳細を示したシーケンス図である。図４〜図６は，プリンシパルコンピュータ１１０上に表示される画面の例を示す図である。図７は，属性情報を一括取得するためのメッセージの構造の例を示す図である。
【００２９】
処理の流れは以下の通りである。
（１）リソース情報の検索要求
１）プリンシパルコンピュータ１１０が，ポータルサイトサーバ１２０にアクセスする。
このとき，プリンシパルコンピュータ１１０からのプリンシパル識別子の送信等によって，ポータルサイトサーバ１２０がプリンシパルを認識できる。
【００３０】
２）ポータルサイトサーバ１２０は，プリンシパルコンピュータ１１０にリソース情報検索画面を表示させる（図４参照）。
ポータルサイトサーバ１２０が，プリンシパルを認識していることから，本図に示すように，プリンシパルコンピュータ１１０の画面上に「ようこそ，○○さん」と表示される。
【００３１】
３）プリンシパルコンピュータ１１０は，ポータルサイトサーバ１２０にリソース情報の検索を要求する。
プリンシパルが，リソース情報検索画面からリソース情報の検索を要求する情報（検索要求情報）を入力または選択する（図４参照）。この入力・選択されたリソース情報を検索する検索要求情報が，プリンシパルコンピュータ１１０からポータルサイトサーバ１２０に送られる。
ここでは，図４に示されるように，プリンシパルが，属性情報として「氏名」，「住所」を検索項目として選択し，「検索」ボタンを押すことで，リソース情報の検索を要求することを考える。
【００３２】
（２）リソース情報の検索
１）ポータルサイトサーバ１２０が検索要求情報を受け取ると，アプリケーション１２４は，リソース解決部１２３のインスタンスを生成する。
２）アプリケーション１２４は，リソース解決部１２３に対してプリンシパル識別子を送り，そのプリンシパルのリソース情報の検索を要求する。
【００３３】
３）リソース解決部１２３は，リソース情報検索プロバイダサーバ１４０に対して，プリンシパル識別子を送り，そのプリンシパルのリソース情報の検索を要求する。即ち，そのプリンシパルの属性が登録されている属性プロバイダサーバ１３０のアドレス（リソースの場所情報）およびリソース情報の取得を要求する。
【００３４】
４）リソース情報検索プロバイダサーバ１４０は，リソース解決部１２３にリソース情報およびリソースの場所情報を返す。
リソース情報検索部１４１は，リソース情報データベースから，そのプリンシパルに対応するリソース情報およびリソースの場所情報を検索し，リソース解決部１２３に返信する。
【００３５】
（３）リソース情報の解析
１）リソース解決部１２３は，リソース情報を解析して，そのリソースに含まれる属性の項目を抽出する。リソース解決部１２３のリソース構造定義ＤＢ上にそのリソースの構造情報が保持されている場合（例えば，ID-SIS-PPなどの標準のスキーマが用いられているリソースの場合），リソース解決部１２３はリソースの構造を解析して，リソースに含まれる属性の項目を抽出できる。
ここでは，そのプリンシパルの属性情報が属性プロバイダ（１）〜（３）（属性プロバイダサーバ１３０（１）〜１３０（３））に登録され，かつ属性の項目が「名前」，「住所」であるとする。即ち，属性プロバイダ（１）〜（３）に対応する３組のリソース情報およびリソース場所情報が取得され，そのリソース情報から属性の項目「名前」，「住所」が抽出されている。
【００３６】
２）リソース解決できない場合，リソース解決部１２３は属性プロバイダサーバ１３０からリソースの構造情報を取得する。取得された構造情報に基づき，リソース中に含まれる属性の項目が抽出される。
【００３７】
（４）属性情報の一括取得要求
１）アプリケーション１２４は，リソース情報の一覧を表示するリソース情報表示画面をプリンシパルコンピュータ１１０上に表示させる（図５参照）。
本図に示されるように，３つのリソース場所情報に対応する属性プロバイダ（１）〜（３），および属性の項目「名前」，「住所」が対応して表示される。
【００３８】
２）プリンシパルコンピュータ１１０は，ポータルサイトサーバ１２０に属性情報を指定してそれらの一括取得を要求する。即ち，プリンシパルコンピュータ１１０からポータルサイトサーバ１２０に一括取得要求情報（一覧の中からプリンシパルによって複数選択された属性情報の一括取得処理を要求する情報）が送られる。
【００３９】
（５）属性情報の一括取得メッセージの生成
１）ポータルサイトサーバ１２０が一括取得要求情報を受け取ると，アプリケーション１２４は，一括処理メッセージ生成部１２１のインスタンスを生成する。
２）一括処理メッセージ生成部１２１は，その要求を受けて，一括取得用のメッセージを生成して，これをアプリケーション１２４に返す（図７参照）。
【００４０】
図７では，属性情報の一括取得を行うためのメッセージであるFDSのQueryメッセージ（以降，FDSQueryと表記する）の構造を模式的に示している。
記述部Ｄ１０がFDSQueryメッセージの全体を，記述部Ｄ１１が記述部Ｄ１０の一部の詳細を表す。
記述部Ｄ１１は，一括処理メッセージ生成部１２１で生成されるメッセージである。記述部Ｄ１１は，一括取得用のメッセージの基本となるものであり，前記DSTで定義されたQueryメッセージ（以降，DSTQueryメッセージと表記する）の<Extension>要素（DSTを拡張するために用意されている要素）を拡張し，その中に一括取得の対象となるリソース情報を含めている。リソース情報には，前記Discovery Serviceで定義された<ResourceOffering>要素（リソース情報を提供するための要素）を利用する。
【００４１】
（６）属性情報の一括取得
１）アプリケーション１２４は，メッセージ一括処理部１２２に対して一括処理を要求する。
２）メッセージ一括処理部１２２は，一括処理メッセージ解釈部１２５を用いて一括処理メッセージを解釈する。
【００４２】
３）メッセージ一括処理部１２２の一括代理処理部１２６は，属性情報提供部１３１（１），１３１（２）それぞれに，属性要求メッセージを生成して，送信する。属性情報提供部１３１（１），１３１（２）は，属性要求メッセージに対応して，属性情報を返信する。その結果，メッセージ一括処理部１２２は，属性情報提供部１３１（１），１３１（２）それぞれから，属性情報を取得する。
【００４３】
（７）属性情報の一括表示
１）メッセージ一括処理部１２２の一括処理メッセージ解釈部１２５は，各属性プロバイダサーバ１３０から取得した属性情報を応答メッセージにまとめる。
２）メッセージ一括処理部１２２の一括処理メッセージ解釈部１２５は，一括処理の応答としてアプリケーション１２４に属性情報を送る。
【００４４】
３）アプリケーション１２４は属性情報を受け取り，プリンシパルコンピュータ１１０上に属性情報の一覧を表示させる（図６参照）。
属性プロバイダ（１），（２）それぞれで登録された属性の項目「名前」，「住所」が表示される。この結果，プリンシパルが属性プロバイダ（１），（２）それぞれでの「名前」，「住所」の登録状況を確認できる。
【００４５】
登録情報管理システム１００を用いることで，異なるドメイン上で分散して管理されているプリンシパルのアイデンティティ（属性情報）のメンテナンスが容易となる。即ち，アイデンティティの参照を一括して実行できる。一括して処理することで，個々に処理する場合と比べて，処理に要するデータ量を低減できる。
なお，属性情報の参照以外の属性情報の変更，削除等の処理一般についても，同様に一括して実行させることが可能である。
【００４６】
（第２の実施の形態）
図８は本発明の第２実施形態に係る登録情報管理システム２００を表すブロック図である。
登録情報管理システム２００は，FQMSを提供するものであり，プリンシパルコンピュータ２１０，ポータルサイトサーバ２２０，属性プロバイダサーバ２３０，リソース情報検索プロバイダサーバ２４０，ＦＤＳサーバ２５０，オーソリティサーバ２６０を備える。
【００４７】
本実施形態では，ポータルサイトサーバ２２０とＦＤＳサーバ２５０との連携によってFDSを提供すると共に，ＦＤＳサーバがプリンシパルの代理人として機能する。また，この代理人による処理の信頼性を確保するための認証処理を行い，オーソリティサーバ２６０がその中心的な役割を担う。
【００４８】
プリンシパルコンピュータ２１０は，プリンシパル（サービス利用者）が操作するコンピュータである。プリンシパルコンピュータ２１０は，そのプリンシパルの属性情報の一覧を要求する入力手段，例えば，キーボードと，この要求に応じて，そのプリンシパルの属性情報の一覧を提示する表示部，例えば，液晶表示装置を備える。
【００４９】
ポータルサイトサーバ２２０は，プリンシパルコンピュータ２１０とネットワーク（例えば，インターネット）で接続されるコンピュータであり，例えば，インターネット上のポータルサイトに配置される。ポータルサイトサーバ２２０は，一括処理メッセージ生成部２２１，メッセージ一括処理部２２２，リソース解決部２２３，アプリケーション２２４を有する。
【００５０】
一括処理メッセージ生成部２２１，メッセージ一括処理部２２２は，アプリケーション２２４のプロキシとして属性情報の一括処理を担うものであり，ポータルサイトサーバ２２０のライブラリを用いて構築できる。
一括処理メッセージ生成部２２１は，属性プロバイダサーバ２３０で管理されている属性情報を一括処理（取得又は修正）する際に用いる一括処理メッセージを生成する。
【００５１】
メッセージ一括処理部２２２は，一括処理メッセージ送信部２２７を有する。
一括処理メッセージ送信部２２７は，一括処理メッセージ生成部２２１で生成された一括処理メッセージをＦＤＳサーバ２５０に送信する。
【００５２】
リソース解決部１２３は，リソースを解決すると共に，プリンシパルのリソース場所情報を提供するものであり，登録属性情報ファイルの複写に含まれる属性の項目を抽出する抽出手段として機能する。即ち，ここでいうリソースの解決は，プリンシパルの属性の項目を抽出することにある。
リソース解決部１２３は，リソース情報検索プロバイダサーバ１４０にプリンシパルを識別するプリンシパル識別子を送り，リソース情報検索の検索を要求し，リソース情報（リソース場所情報を含む）を受け取る。リソース解決部１２３はリソース情報を解析して，そのリソース情報に含まれる属性の項目を抽出する。
【００５３】
ソース解決部２２３は，リソース情報（登録属性情報ファイル）の構造を定義するリソース構造定義情報を含むリソース構造定義テーブルを保持するデータベース（リソース構造定義ＤＢ）を有する。ソース解決部２２３は，リソース構造定義テーブルを用いてリソース情報から属性の項目を抽出する。なお，リソース構造の定義の例として，Discovery Serviceでの<ResourceOffering>を挙げることができる。
【００５４】
リソース構造定義テーブルで構造が定義されないリソース情報については，属性プロバイダサーバ２３０から取得されるリソース構造定義情報を用いて，属性の項目を抽出する。ソース解決部２２３は，取得したリソース情報の構造定義情報がリソース構造定義ＤＢ中に格納されていない場合に，そのリソース情報の構造の検索を属性プロバイダサーバ２３０に要求し，リソース構造定義情報を取得する。
【００５５】
アプリケーション２２４は，プリンシパルコンピュータ２１０とのユーザインタフェースの役割を果たし，属性情報の一括処理を行うためにリソース解決部２２３に要求を送り，その結果をプリンシパルコンピュータ２１０に提供する。アプリケーション２２４は，抽出される属性の項目を提示する提示手段および処理要求情報を受信する処理要求情報受信手段として機能する。
アプリケーション２２４は，オーソリティサーバ２６０に対してリソース操作の処理権限を委譲してもらうための権限委譲情報を要求する。アプリケーション２２４は，オーソリティサーバ２６０から受け取った権限委譲情報をＦＤＳサーバ２５０に送信する。
【００５６】
ＦＤＳサーバ２５０は，権限委譲情報により，属性プロバイダサーバ２３０に対して自身がサブジェクトの正当な代理者であることを証明できる。また，属性プロバイダサーバ２３０は，権限委譲情報に基づいた信頼性情報からリソース操作の要求発信元がプリンシパルであることを確認できる。
【００５７】
属性プロバイダサーバ２３０は，属性情報提供部２３１を有する。属性プロバイダサーバ２３０は，オーソリティサーバ２６０に信頼性情報を要求して，それを検証した後，属性処理を行う。
【００５８】
リソース情報検索プロバイダサーバ２４０は，プリンシパルが所有するリソース情報を管理しており，要求に応じてリソース情報を検索するリソース情報検索部２４１を有する。
リソース情報検索部２４１は，データベース（リソース情報ＤＢ）を有する。リソース情報ＤＢは，プリンシパル識別子，プリンシパルのリソース情報（そのプリンシパルの属性情報が登録されている属性プロバイダサーバ２３０のアドレス（リソースの場所情報）を含む）を対応して保持する。即ち，リソース情報ＤＢは，プリンシパル（個人）と，リソース（登録属性情報ファイル）の複写と，を対応して記憶する記憶手段として機能する。
【００５９】
ＦＤＳサーバ２５０は，メッセージ一括処理部２５１を有する。
メッセージ一括処理部２５１は，一括処理メッセージ解釈部２５２と，一括代理処理部２５３とを有する。
【００６０】
一括処理メッセージ解釈部２５２は，サブジェクトの代理として属性情報の一括処理を担い，一括処理メッセージを解釈する。また，一括処理メッセージ解釈部２５２は，一括処理メッセージを受信すると，ポータルサイトサーバ２２０に対して権限委譲情報を要求する。一括処理メッセージ解釈部２５２は，委譲要求メッセージを送信する委譲要求メッセージ送信手段および委譲許可メッセージを受信する委譲許可メッセージ受信手段として機能する。
【００６１】
一括代理処理部２５３は，属性情報を提供する属性プロバイダサーバ２３０に対して代理で属性情報の取得要求を行い，その結果を１つにまとめてアプリケーション２２４に返す。一括代理処理部２５３は，個別処理メッセージを生成する個別処理メッセージ生成手段およびと個別処理メッセージを前記複数のサイトに送信する個別処理メッセージ送信手段して機能する。
一括代理処理部２５３は，属性プロバイダサーバ２３０に属性情報を要求するメッセージに権限委譲情報を含める。自身の信頼性，すなわち自身がサブジェクトの正当な代理者であることを証明するためである。
【００６２】
オーソリティサーバ２６０は，プリンシパルのアイデンティティ情報を保管し，サブジェクトを認証する。オーソリティサーバ２６０は，例えば，第三者機関によって管理される。
オーソリティサーバ２６０は，ポータルサイトサーバ２２０から権限委譲要求メッセージ（認可対象主体（ＦＤＳサーバ２５０），認可対象動作（例えば，読み出し），認可対象リソース（リソース識別情報，例えば，リソース場所情報）の情報を含む）を受け取って，権限委譲応答メッセージを返信する。
その後，オーソリティサーバ２６０は，属性プロバイダサーバ２３０から信頼性情報要求メッセージ（認可対象主体（ＦＤＳサーバ２５０），認可対象動作，認可対象リソースの情報を含む）を受け取って，信頼性情報メッセージを返信する。
【００６３】
このとき，オーソリティサーバ２６０は，権限委譲要求メッセージと頼性情報要求メッセージとに含まれる情報（認可対象主体，認可対象動作，認可対象リソースを識別する情報）が一致しているか否かに基づいて，認可対象主体による認可対象リソースへの認可対象動作の可否（アクセスの可否）を決定し，信頼性情報メッセージにこのアクセス可否情報を含め，返信する。
この信頼性情報メッセージに基づいて，属性プロバイダサーバ２３０は，ＦＤＳサーバ２５０へのリソースのアクセスを許可あるいは禁止する。この結果，プリンシパルの代理人としてのＦＤＳサーバ２５０の信頼性が保証される。
【００６４】
（登録情報管理システム２００の動作）
図９は，登録情報管理システム２００での処理の流れの概要を示したシーケンス図である。図１０は，登録情報管理システム２００での処理の流れの詳細を示したシーケンス図である。図１１は，登録情報管理システム２００での信頼性確立のための処理の流れの一例を示したシーケンス図である。
図１２〜図２１は，登録情報管理システム２００で送受信されるメッセージの構造の例を示す図である。
【００６５】
処理の流れは以下の通りである。
（１）リソース情報の検索要求
１）プリンシパルコンピュータ２１０が，ポータルサイトサーバ２２０にアクセスする。
２）ポータルサイトサーバ２２０は，プリンシパルコンピュータ２１０にリソース情報検索画面を表示させる（図４参照）。
３）プリンシパルコンピュータ２１０は，ポータルサイトサーバ２２０にリソース情報の検索を要求する。
プリンシパルが，リソース情報検索画面（図４参照）からリソース情報の検索を要求する情報（検索要求情報）を入力または選択することで，プリンシパルコンピュータ２１０からポータルサイトサーバ２２０に検索要求情報が送られる。
【００６６】
（２）リソース情報の検索
１）ポータルサイトサーバ２２０が検索要求情報を受け取ると，アプリケーション２２４は，リソース解決部２２３のインスタンスを生成する。
２）アプリケーション２２４は，リソース解決部２２３に対してプリンシパル識別子を送り，そのプリンシパルのリソース情報の検索を要求する。
３）リソース解決部２２３は，リソース情報検索プロバイダサーバ２４０に対して，プリンシパル識別子を送り，そのプリンシパルのリソース情報の取得を要求する。
４）リソース情報検索プロバイダサーバ２４０は，リソース解決部２２３にリソース情報（リソースの場所情報を含む）を返す。
【００６７】
（３）リソース情報の解析
１）リソース解決部２２３は，リソース情報を解析して，そのリソースに含まれる属性の項目を抽出する。リソース解決部２２３のリソース構造定義ＤＢ上にそのリソースの構造情報が保持されている場合（例えば，ID-SIS-PPなどの標準のスキーマが用いられているリソースの場合），リソース解決部２２３はリソースの構造を解析して，リソースに含まれる属性の項目を抽出できる。
２）リソース解決できない場合，リソース解決部２２３は属性プロバイダサーバ２３０からリソースの構造情報を取得する。取得された構造情報に基づき，リソース中に含まれる属性の項目が抽出される。
【００６８】
（４）属性情報の一括取得要求
１）アプリケーション２２４は，リソース情報の一覧を表示するリソース情報表示画面をプリンシパルコンピュータ２１０上に提示させる（図５参照）。
２）プリンシパルコンピュータ２１０は，ポータルサイトサーバ２２０に属性情報を指定してそれらの一括取得を要求する。即ち，プリンシパルコンピュータ２１０からポータルサイトサーバ２２０に一括取得要求情報（一覧の中からプリンシパルによって複数選択された属性情報の一括取得処理を要求する情報）が送られる。
【００６９】
（５）属性情報の一括取得メッセージの生成
１）ポータルサイトサーバ２２０が一括取得要求情報を受け取ると，アプリケーション２２４は，一括処理メッセージ生成部２２１のインスタンスを生成する。
２）一括処理メッセージ生成部２２１は，その要求を受けて，一括取得用のメッセージを生成して，これをアプリケーション２２４に返す（図１２Ａ，図１２Ｂ参照）。
３）ポータルサイトサーバ２２０のメッセージ一括処理部２２２は，一括処理メッセージをＦＤＳサーバ２５０のメッセージ一括処理部２５１に送信する。
【００７０】
図１２Ａは，属性情報を取得する一括処理メッセージの一例の全体を示す。図１２Ｂは，図１２Ａの一括処理メッセージの<Delegation>要素部分Ａ１１を拡大して示す。図１２Ａ，１２Ｂの一括処理メッセージは，Liberty ID-WSF Soap Binding Specificationに基づく。一括処理メッセージのヘッダ部（Header）内には，この仕様を独自に拡張して定義した<Delegation>要素部分Ａ１１の直下に<DelegationRef>要素が配置される。<DelegationRef>要素内に，識別子（itemID属性），権限を委譲する処理の種類（type属性），代理処理対象への参照（ref属性），代理処理対象となるリソース（resourceID属性）が含まれる。このresourceID属性が，リソース場所情報に相当する。
このヘッダ部は，ボディ部（Body）の<Extension>要素と対応する。即ち，ボディ部の<Extension>要素（本図のＡ１２）でのitemID属性とヘッダ部のref属性とが一致している。
【００７１】
ここでは，属性プロバイダ（１），（２）に対応して，itemID，type属性，ref属性，resourceID属性が2組示される（「"query#000000001"，"Query"，"000000001"，""」，「"query#000000001"，"Query"，"000000002"，""」）。
このヘッダ部に含まれる複数組の属性と対応して，ボディ部（Body）に<Extension>要素が複数配置される。図１２Aでは，ヘッダ部のref属性"000000001"，"000000002"に対応して，ボディ部の<Extension>要素が重なって配置される。
なお，mustUnderstand属性及びactor属性は，SOAPの仕様に規定されている。
【００７２】
（６）権限委譲処理
１）メッセージ一括処理部２５１は，一括処理メッセージを受信すると，ポータルサイトサーバ２２０に対し代理処理が行えるように権限委譲を要求する（権限委譲要求メッセージの送信）。
図１３は，権限委譲要求メッセージの一例を示す図である。本図では，独自に定義した<DelegationAuthorityRequest>要素の直下の<DelegationRef>要素に，認可対象となる主体名（<Subject>要素，ＦＤＳサーバ２５０），認可対象となる動作（<Action>要素），認可対象となるリソース（<Resource>要素）を含めている。
【００７３】
２）ポータルサイトサーバ２２０は，オーソリティサーバ２６０に権限委譲の処理を要求する（権限委譲要求メッセージの送信）。
図１４Ａ，図１４Ｂは，権限委譲要求メッセージの一例を示す図である。図１４Ａは，権限委譲要求メッセージの全体を示す。図１４Ｂは，図１４Ａ中の<DelegationRequest>要素Ａ２０の詳細を表す図である。独自に定義した<DelegationRequest>要素の直下の<Delegation>要素に，認可対象となる主体名（<Subject>要素（Ａ２１），ＦＤＳサーバ２５０），認可対象となる動作（<Action>要素（Ａ２２）），認可対象となるリソース（<Resource>要素（Ａ２３））を含めている。
【００７４】
<Resource>要素はリソース場所情報に対応し，リソース場所情報によってリソースを識別している。ここでは<Action>要素が，「Read（読み出し）」である。この権限委譲要求メッセージには，図１２Ａに示されるように，Security Assertion Markup Language（以降，SAMLと表記する）のAuthenticationQuery（認証要求問合せ）メッセージが含まれる。
なお，Liberty ID-WSF Soap Binding Specification以外に，SPML（Service Provisioning Markup Language）などの標準仕様を利用可能である。
【００７５】
３）オーソリティサーバ２６０は，ＦＤＳサーバ２５０に対して代理処理権限を付与する（権限委譲応答メッセージの返信）。
図１５は，権限委譲応答メッセージの例を示す図である。本図では，権限委譲情報としてSecurity Assertion Markup Language（以降，SAMLと表記する）のAssertionを用いている。<Assertion>要素（Ａ２４）に認可対象となる主体（ＦＤＳサーバ２５０）への認証のアサーション（主張）が含まれる。
【００７６】
４）ポータルサイトサーバ２２０は，メッセージに権限委譲情報を含めてＦＤＳサーバ２５０に送信する（権限委譲メッセージの送信）。
図１６は，権限委譲メッセージの例を示す図である。<Assertion>要素（Ａ２５）に認可対象となる主体（ＦＤＳサーバ２５０）への認証のアサーション（主張）が含まれる。
【００７７】
（７）属性情報の一括取得
１）メッセージ一括処理部２５１は，一括処理メッセージ解釈部２５２を用いて一括処理メッセージを解釈して，属性プロバイダサーバ２３０毎にメッセージを分割する。
【００７８】
２）メッセージ一括処理部２５１の一括代理処理部２５３は，属性プロバイダサーバ２３０毎に，受け取った権限委譲情報を含めた個別属性要求メッセージを生成する。
図１７は，個別属性取得要求メッセージの例を示す図である。本図では，Liberty ID-WSF SOAP Binding Specificationで定義されているSOAPヘッダ内の<Assertion>要素（Ａ３１）に認可対象となる主体（ＦＤＳサーバ２５０）への認証のアサーション（主張）が含まれる（<wsse:Security>要素の直下に<saml:Assertion>要素を含めている）。また，ここでは，属性プロバイダサーバ２３０毎に対応して，<Query>要素（Ａ３２）は1つだけとなっている。
【００７９】
３）ＦＤＳサーバ２５０は，属性要求メッセージを属性プロバイダサーバ２３０（１），２３０（２）に送信し，属性情報の取得を要求する。
【００８０】
（８）信頼性の確認
１）属性プロバイダサーバ２３０（１），２３０（２）は，ＦＤＳサーバ２５０の信頼性を検証するために，属性要求メッセージ含まれている権限委譲情報を用いて，オーソリティサーバ２６０に信頼性情報を要求する（信頼性情報要求メッセージの送信）。
図１８は，信頼性情報要求メッセージの例を示す図である。本図では，信頼性情報を取得するために，SAMLのAuthorizationDecisionQuery（認可決定問合せ要求）メッセージを用いている。AuthorizationDecisionQueryのメッセージ構造は，SAMLの仕様に記述される。
信頼性情報要求メッセージのAssertion>要素（Ａ３３）に認可対象となる主体（ＦＤＳサーバ２５０）への認証のアサーション（主張）が含まれる。また，信頼性情報要求メッセージには，リソースへのアクセスを要求する情報が含まれる（Ａ３４）。
【００８１】
２）オーソリティサーバ２６０は，権限委譲情報からＦＤＳサーバ２５０がポータルサイトサーバ２２０の正当な代理者であることを証明する信頼性情報を属性プロバイダサーバ２３０（１），２３０（２）に返信する（信頼性情報メッセージの送信）。
図１９は，信頼性情報メッセージの例を示す図である。本図では，信頼性情報メッセージとして，SAMLのAuthorizationStatement（認可決定応答）メッセージを示している。AuthorizationStatementのメッセージ構造は，SAMLの仕様に記述される。
信頼性情報メッセージには，リソースへのアクセスの許可，禁止を表すアクセス許可情報（Ａ３５）および認可対象となる主体（ＦＤＳサーバ２５０）を表す情報（Ａ３６）が含まれる。
本図では，Decision属性の値が“Permit（許可）”であることから，正当な代理（アクセスの許可）を意味する。
【００８２】
３）属性プロバイダサーバ２３０（１），２３０（２）は，信頼性情報を検証して，属性プロバイダサーバ２３０（１）は要求発信元がポータルサイトサーバ２２０であり，ＦＤＳサーバ２５０がポータルサイトサーバ２２０の正当な代理者であることを確認する。既述のように，信頼性情報メッセージのDecision属性の値によって正当な代理の有無を確認できる。
【００８３】
（９）属性情報の送信
１）ＦＤＳサーバ２５０の信頼性を検証できれば，属性プロバイダサーバ２３０（１），２３０（２）は属性情報を取得する。
２）属性プロバイダサーバ２３０は，ＦＤＳサーバ２５０に属性情報を含めたメッセージを返信する（属性取得応答メッセージの送信）。
図２０は，属性取得応答メッセージの例を示す図である。本図では，図１７の<Query>要素が1つだったので，<QueryResponse>要素（Ａ４１）も1つである。即ち，ＦＤＳサーバ２５０は，属性プロバイダサーバ２３０（１），２３０（２）それぞれから別個にの属性情報を受け取る。
【００８４】
（７）属性情報の一括表示
１）メッセージ一括処理部２５１の一括処理メッセージ解釈部２５２は，各属性プロバイダサーバ２３０（１），２３０（２）から取得した属性情報を応答メッセージにまとめる。
２）メッセージ一括処理部２５１の一括処理メッセージ解釈部２５２は，一括処理要求の応答としてポータルサイトサーバ２２０のメッセージ一括処理部２２２に属性情報を返す（一括処理応答メッセージの送信）。一括処理の結果は1つにまとめて，一括処理応答メッセージのSOAP Bodyの直下に含める。
図２１は，一括処理応答メッセージの一例を示す図である。一括処理の結果がまとめられていることから，<QueryResponse>要素が複数存在する。
３）ＦＤＳサーバ２５０は，一括処理応答メッセージをポータルサイトサーバ２２０に返信する。
４）アプリケーション２２４は属性情報を受け取り，プリンシパルコンピュータ２１０上に属性情報の一覧を表示させる（図６参照）。
【００８５】
登録情報管理システム２００を用いることで，異なるドメイン上で分散して管理されているプリンシパルのアイデンティティ（属性情報）のメンテナンスが容易となる。即ち，アイデンティティの参照を一括して実行できる。一括して処理することで，個々に処理する場合と比べて，処理に要するデータ量を低減できる。
また，プリンシパルから一括処理の権限を委譲された代理者（ＦＤＳサーバ２５０）の正当性の確保が容易となる。
なお，属性情報の参照以外の属性情報の変更，削除等の処理一般についても，同様に一括して実行させることが可能である。
【００８６】
（第３の実施形態）
第１，第２の実施形態では，データ操作の対象が属性情報であったが，データ操作の対象をリソースの構造情報とすることも可能である。即ち，リソースの構造情報の交渉取得を一括して行うことができる。
リソースの提供者とサブジェクトの間でリソース情報や属性情報に関して事前に合意が取れている場合，すなわちアイデンティティ情報の構造が共通化されている場合，リソース解決における問題は生じない。例えば，ID-SIS-PPなどの標準のスキーマを用いる場合である。
【００８７】
しかし，標準のスキーマが独自に拡張されていたり，独自に定義されたスキーマが用いられていると，どのようなリソース情報なのかを把握できなくなり，リソース解決だけでなく属性情報の交換も困難になってしまう。
リソースの構造情報（スキーマなど）を取得し，それを解析することで，動的にリソースを解決することが考えられる。場合によっては，リソースの構造情報の取得は１つの属性プロバイダサーバでなく，複数に対して行うことが想定される。
【００８８】
このように，リソースの構造情報の一括した取得は，有用である。例えば，リソース解決部１２３，２２３が属性プロバイダサーバ１３０，２３０から構造情報を一括して取得できる。
本実施形態は，データ操作の対象が異なることを除けば，第１，第２の実施形態と本質的に異なる訳ではないので，詳細な説明を省略する。
【００８９】
（その他の実施形態）
本発明の実施形態は上記の実施形態に限られず拡張，変更可能であり，拡張，変更した実施形態も本発明の技術的範囲に含まれる。
【図面の簡単な説明】
【００９０】
【図１】本発明の第１実施形態に係る登録情報管理システムを表すブロック図である。
【図２】第１実施形態に係る登録情報管理システムでの処理の流れの概要を示したシーケンス図である。
【図３】第１実施形態に係る登録情報管理システムでの処理の流れの詳細を示したシーケンス図である。
【図４】プリンシパルコンピュータ上に表示される画面の例を示す図である。
【図５】プリンシパルコンピュータ上に表示される画面の例を示す図である。
【図６】プリンシパルコンピュータ上に表示される画面の例を示す図である。
【図７】属性情報を一括取得するためのメッセージの構造の例を示す図である。
【図８】本発明の第２実施形態に係る登録情報管理システムを表すブロック図である。
【図９】第２実施形態に係る登録情報管理システムでの処理の流れの概要を示したシーケンス図である。
【図１０】第２実施形態に係る登録情報管理システムでの処理の流れの詳細を示したシーケンス図である。
【図１１】第２実施形態に係る登録情報管理システムでの信頼性確立のための処理の流れを示したシーケンス図である。
【図１２Ａ】第２実施形態に係る登録情報管理システムで送受信されるメッセージの構造の例の全体を示す図である。
【図１２Ｂ】第２実施形態に係る登録情報管理システムで送受信されるメッセージの構造の例の一部を示す図である。
【図１３】第２実施形態に係る登録情報管理システムで送受信されるメッセージの構造の例を示す図である。
【図１４Ａ】第２実施形態に係る登録情報管理システムで送受信されるメッセージの構造の例の全体を示す図である。
【図１４Ｂ】第２実施形態に係る登録情報管理システムで送受信されるメッセージの構造の例の一部を示す図である。
【図１５】第２実施形態に係る登録情報管理システムで送受信されるメッセージの構造の例を示す図である。
【図１６】第２実施形態に係る登録情報管理システムで送受信されるメッセージの構造の例を示す図である。
【図１７】第２実施形態に係る登録情報管理システムで送受信されるメッセージの構造の例を示す図である。
【図１８】第２実施形態に係る登録情報管理システムで送受信されるメッセージの構造の例を示す図である。
【図１９】第２実施形態に係る登録情報管理システムで送受信されるメッセージの構造の例を示す図である。
【図２０】第２実施形態に係る登録情報管理システムで送受信されるメッセージの構造の例を示す図である。
【図２１】第２実施形態に係る登録情報管理システムで送受信されるメッセージの構造の例を示す図である。
【符号の説明】
【００９１】
１００…登録情報管理システム、１１０…プリンシパルコンピュータ、１２０…ポータルサイトサーバ、１２１…一括処理メッセージ生成部、１２２…メッセージ一括処理部、１２３…リソース解決部、１２４…アプリケーション、１２５…一括処理メッセージ解釈部、１２６…一括代理処理部、１３０…属性プロバイダサーバ、１３１…属性情報提供部、１４０…リソース情報検索プロバイダサーバ、１４１…リソース情報検索部、２００…登録情報管理システム、２１０…プリンシパルコンピュータ、２２０…ポータルサイトサーバ、２２１…一括処理メッセージ生成部、２２２…メッセージ一括処理部、２２３…リソース解決部、２２４…アプリケーション、２２７…一括処理メッセージ送信部、２３０…属性プロバイダサーバ、２３１…属性情報提供部、２４０…リソース情報検索プロバイダサーバ、２４１…リソース情報検索部、２５０…ＦＤＳサーバ、２５１…メッセージ一括処理部、２５２…一括処理メッセージ解釈部、２５３…一括代理処理部、２６０…オーソリティサーバ
【技術分野】
【０００１】
本発明は，ネットワーク上の登録情報を管理する登録情報管理システムに関する。
【背景技術】
【０００２】
電子サービスにおいて，そのサービスの利用者のユーザ・アカウント，住所，氏名，電話番号，年齢などの属性情報（アイデンティティ（Identity））を登録することがある。例えば，あるポータルサイトを利用して買い物をする場合，利用者（ユーザ，以降，プリンシパルと記述）がアイデンティティをポータルサイトで登録する必要がある。複数のサービスを利用する場合，通例，プリンシパルが複数のサービスに登録し，各サービスがアイデンティティのライフサイクルを管理する。
【０００３】
最近では，ネットワークに分散されるアイデンティティの相互参照を可能とするネットワークアイデンティティ技術が確立しつつある。これにより，分散されたアイデンティティのインターオペラビリティ（相互運用性）を確保しながら，高信頼化されたアイデンティティを活用することが可能となってきている。アイデンティティの相互参照により，プリンシパルにより適したサービスの提供が容易となる。
【０００４】
例えば，Liberty Alliance Projectで策定されているLiberty Alliance仕様では，アイデンティティのリソース解決のためのサービス仕様としてLiberty ID-WSF Discovery Service Specification（以降，Discovery Serviceと表記する）や，アイデンティティ情報の取得/修正を行うデータサービスのためのテンプレート仕様としてLiberty ID-WSF Data Services Template Specification（以降，DSTと表記する），Liberty ID-WSF上で公開される具体的なアイデンティティサービス仕様としてID-SIS Personal Profile Service Specification（以降，ID-SIS-PPと表記する）などが公開されている（非特許文献１〜３参照）。
【非特許文献１】Liberty Alliance Project, “Liberty ID-WSF Discovery Service Specification, Version 1.1”, [online],2003年11月12日, [平成16年12月24日検索], インターネット <URL: http://www.projectliberty.org/specs/liberty-idwsf-disco-svc-v1.1.pdf>
【非特許文献２】Liberty Alliance Project, “Liberty ID-WSF Data Services Template Specification, Version 1.0”, [online],2003年11月12日, [平成16年12月24日検索], インターネット <URL: http://www.projectliberty.org/specs/liberty-idwsf-dst-v1.0.pdf>
【非特許文献３】Liberty Alliance Project, “Liberty ID-SIS Personal Profile Service Specification, Version 1.0”, [online],2003年11月12日, [平成16年12月24日検索], インターネット <URL: http://www.projectliberty.org/specs/liberty-idsis-pp-v1.0.pdf >
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら，アイデンティティ所有者（プリンシパル）自身が分散管理されているアイデンティティを統括管理することは必ずしも容易でない。例えば，プリンシパルがアイデンティティを様々なサービスに登録している場合，自分のアイデンティティ情報を自分自身でメンテナンスする必要がある。しかし，複数の場所に管理されるアイデンティティを個別にメンテナンスすることは，プリンシパルの負担となる。例えば，プリンシパルの住所が変更になった場合，住所情報が登録されているサービスを探し出し，各サービスで管理されているアイデンティティ情報の中から住所情報を修正しなければならない。
【０００６】
本発明は，複数のサイトに登録された情報への一括した処理を容易とする登録情報管理システムを提供することを目的とする。
【課題を解決するための手段】
【０００７】
本発明の一態様に係る登録情報管理システムは，ネットワーク上の複数のサイトにそれぞれ登録され，かつ同一の個人の属性情報を有する複数の登録属性情報ファイルへの処理を要求する処理要求情報を受信する処理要求情報受信手段と，前記受信される処理要求情報に基づき，前記複数の登録属性情報ファイルへの一括処理を要求する一括処理メッセージを生成する一括処理メッセージ生成手段と，前記生成される一括処理メッセージに基づき，前記複数の登録属性情報ファイルそれぞれへの処理を要求する複数の個別処理メッセージを生成する個別処理メッセージ生成手段と，前記生成される複数の個別処理メッセージを前記複数のサイトに送信する個別処理メッセージ送信手段と，を具備することを特徴とする。
【発明の効果】
【０００８】
本発明によれば，複数のサイトに登録された情報への一括した処理を容易とする登録情報管理システムを提供できる。
【発明を実施するための最良の形態】
【０００９】
以下，図面を参照して，本発明の実施の形態を詳細に説明する。
（第１の実施の形態）
図１は，本発明の第１実施形態に係る登録情報管理システム１００を表すブロック図である。
登録情報管理システム１００は，プリンシパルコンピュータ１１０，ポータルサイトサーバ１２０，属性プロバイダサーバ１３０，リソース情報検索プロバイダサーバ１４０を備える。
【００１０】
登録情報管理システム１００は，異なるドメインに対応する複数の属性プロバイダサーバ１３０で管理されるリソースの構造情報や属性情報などのデータ操作を一括して処理するFacade Data Service（以降，FDSと表記する）を提供する。属性プロバイダサーバ１３０毎に個別に行っていた取得や修正などの処理を一括して実行することができる。
【００１１】
本実施形態では，FDSを提供する本体はポータルサイトサーバ１２０である。後述する第２の実施形態では，ポータルサイトサーバとＦＤＳサーバとの連携によってFDSを提供すると共に，ＦＤＳサーバがプリンシパルの代理人として機能する。なお，本実施形態では，プリンシパル自体が一括処理の主体であることから，認証処理は含まれない。
【００１２】
FDSの一例として，プリンシパル（電子サービスの利用者）の属性情報（アイデンティティ）の一括処理を行うアイデンティティサービス（Facade Query and Modify Service（以降，FQMSと表記する））を挙げることができる。
【００１３】
プリンシパルの属性は，電子サービス上に登録されたプリンシパルのユーザ・アカウント，住所，氏名，電話番号，年齢などの個人情報である。電子サービスにおいて，プリンシパルそれぞれの属性はリソースと呼ばれるファイル（登録属性情報ファイル）に登録される。即ち，プリンシパルそれぞれに対応して，リソースが存在する。
プリンシパルのリソースの構造情報や存在場所情報（場所情報）を含めたリソースに関する情報全般がリソース情報である。
【００１４】
プリンシパルコンピュータ１１０は，プリンシパル（サービス利用者）が操作するコンピュータである。プリンシパルコンピュータ１１０は，そのプリンシパルの属性情報の一覧を要求する入力手段，例えば，キーボードと，この要求に応じて，そのプリンシパルの属性情報の一覧を提示する表示部，例えば，液晶表示装置を備える。
【００１５】
ポータルサイトサーバ１２０は，プリンシパルコンピュータ１１０とネットワーク（例えば，インターネット）で接続されるコンピュータであり，例えば，インターネット上のポータルサイトに配置される。ポータルサイトサーバ１２０は，一括処理メッセージ生成部１２１，メッセージ一括処理部１２２，リソース解決部１２３，アプリケーション１２４を有する。
【００１６】
一括処理メッセージ生成部１２１，メッセージ一括処理部１２２は，アプリケーション１２４のプロキシとして属性情報の一括処理を担うものであり，ポータルサイトサーバ１２０のライブラリを用いて構築できる。
一括処理メッセージ生成部１２１は，属性プロバイダサーバ１３０で管理されている属性情報を一括処理（取得又は修正）する際に用いる一括処理メッセージを生成する。
【００１７】
メッセージ一括処理部１２２は，一括処理メッセージ解釈部１２５，一括代理処理部１２６を有する。
一括処理メッセージ解釈部１２５は，一括処理メッセージを解釈する。
一括代理処理部１２６は，属性情報を提供する属性プロバイダサーバ１３０に対して処理要求を行い，その結果を１つにまとめてアプリケーション１２４に返す。一括代理処理部１２６は，個別処理メッセージを生成する個別処理メッセージ生成手段およびと個別処理メッセージを前記複数のサイトに送信する個別処理メッセージ送信手段して機能する。
【００１８】
リソース解決部１２３は，リソースを解決すると共に，プリンシパルのリソース場所情報を提供するものであり，登録属性情報ファイルの複写に含まれる属性の項目を抽出する抽出手段として機能する。即ち，ここでいうリソースの解決は，プリンシパルの属性の項目を抽出することにある。
リソース解決部１２３は，リソース情報検索プロバイダサーバ１４０にプリンシパルを識別するプリンシパル識別子を送り，リソース情報検索の検索を要求し，リソース情報（リソース場所情報を含む）を受け取る。リソース解決部１２３はリソース情報を解析して，そのリソース情報に含まれる属性の項目を抽出する。
【００１９】
ソース解決部１２３は，リソース情報（登録属性情報ファイル）の構造を定義するリソース構造定義情報を含むリソース構造定義テーブルを保持するデータベース（リソース構造定義ＤＢ）を有する。ソース解決部１２３は，リソース構造定義テーブルを用いてリソース情報から属性の項目を抽出する。なお，リソース構造の定義の例として，Discovery Serviceでの<ResourceOffering>を挙げることができる。
【００２０】
リソース構造定義テーブルで構造が定義されないリソース情報については，属性プロバイダサーバ１３０から取得されるリソース構造定義情報を用いて，属性の項目を抽出する。ソース解決部１２３は，取得したリソース情報の構造定義情報がリソース構造定義ＤＢ中に格納されていない場合に，そのリソース情報の構造の検索を属性プロバイダサーバ１３０に要求し，リソース構造定義情報を取得する。
【００２１】
アプリケーション１２４は，プリンシパルコンピュータ１１０とのユーザインタフェースの役割を果たし，属性情報の一括処理を行うためにリソース解決部１２３に要求を送り，その結果をプリンシパルコンピュータ１１０に提供する。アプリケーション１２４は，抽出される属性の項目を提示する提示手段および処理要求情報を受信する処理要求情報受信手段として機能する。
【００２２】
属性プロバイダサーバ１３０は，ポータルサイトサーバ１２０とネットワーク（例えば，インターネット）で接続されるコンピュータであり，プリンシパルの属性情報を管理する属性プロバイダに対応する。属性プロバイダサーバ１３０は，要求に応じて属性情報を提供する属性情報提供部１３１を有する。
【００２３】
リソース情報検索プロバイダサーバ１４０は，ポータルサイトサーバ１２０とネットワーク（例えば，インターネット）で接続されるコンピュータであり，プリンシパルが所有するリソース情報を管理する。リソース情報検索プロバイダサーバ１４０は，要求に応じてリソース情報を検索するリソース情報検索部１４１を有する。
【００２４】
リソース情報検索部１４１は，データベース（リソース情報ＤＢ）を有する。リソース情報ＤＢは，プリンシパル識別子，プリンシパルのリソース情報（そのプリンシパルの属性情報が登録されている属性プロバイダサーバ１３０のアドレス（リソースの場所情報）を含む）を対応して保持する。即ち，リソース情報ＤＢは，プリンシパル（個人）と，リソース（登録属性情報ファイル）の複写と，を対応して記憶する記憶手段として機能する。
【００２５】
リソース情報検索部１４１がプリンシパル識別子に基づきリソース情報データベースを検索することで，そのプリンシパルのリソース情報およびリソース場所情報を得ることができる。リソース情報およびリソースの場所情報の組み合わせは，そのプリンシパルの属性情報が登録されている電子サービス毎に存在する。
【００２６】
このリソース情報に含まれる属性情報は，属性プロバイダサーバ１３０に登録されている属性情報と本質的に異なるものではない。但し，属性プロバイダサーバ１３０上の属性情報は，登録されている属性情報（登録属性情報）そのものであるのに対し，リソース情報データベース上の属性情報は登録されている属性情報のコピー（複写属性情報）である。
【００２７】
このため，リソース情報データベース上のリソース情報は登録リソース情報と食い違う可能性がある（登録リソース情報への変更が複写登録情報に反映されることが必ずしも保証されない）。また，その逆に，複写登録情報を変更しても，登録リソース情報が変更される訳でもない。
以上のように，リソース情報データベース上のリソース情報は，プリンシパルの便宜のために，登録されているリソース情報（登録リソース情報）のコピー（複写リソース情報）を集積したものである。
【００２８】
（登録情報管理システム１００の動作）
図２は，登録情報管理システム１００での処理の流れの概要を示したシーケンス図である。図３は，登録情報管理システム１００での処理の流れの詳細を示したシーケンス図である。図４〜図６は，プリンシパルコンピュータ１１０上に表示される画面の例を示す図である。図７は，属性情報を一括取得するためのメッセージの構造の例を示す図である。
【００２９】
処理の流れは以下の通りである。
（１）リソース情報の検索要求
１）プリンシパルコンピュータ１１０が，ポータルサイトサーバ１２０にアクセスする。
このとき，プリンシパルコンピュータ１１０からのプリンシパル識別子の送信等によって，ポータルサイトサーバ１２０がプリンシパルを認識できる。
【００３０】
２）ポータルサイトサーバ１２０は，プリンシパルコンピュータ１１０にリソース情報検索画面を表示させる（図４参照）。
ポータルサイトサーバ１２０が，プリンシパルを認識していることから，本図に示すように，プリンシパルコンピュータ１１０の画面上に「ようこそ，○○さん」と表示される。
【００３１】
３）プリンシパルコンピュータ１１０は，ポータルサイトサーバ１２０にリソース情報の検索を要求する。
プリンシパルが，リソース情報検索画面からリソース情報の検索を要求する情報（検索要求情報）を入力または選択する（図４参照）。この入力・選択されたリソース情報を検索する検索要求情報が，プリンシパルコンピュータ１１０からポータルサイトサーバ１２０に送られる。
ここでは，図４に示されるように，プリンシパルが，属性情報として「氏名」，「住所」を検索項目として選択し，「検索」ボタンを押すことで，リソース情報の検索を要求することを考える。
【００３２】
（２）リソース情報の検索
１）ポータルサイトサーバ１２０が検索要求情報を受け取ると，アプリケーション１２４は，リソース解決部１２３のインスタンスを生成する。
２）アプリケーション１２４は，リソース解決部１２３に対してプリンシパル識別子を送り，そのプリンシパルのリソース情報の検索を要求する。
【００３３】
３）リソース解決部１２３は，リソース情報検索プロバイダサーバ１４０に対して，プリンシパル識別子を送り，そのプリンシパルのリソース情報の検索を要求する。即ち，そのプリンシパルの属性が登録されている属性プロバイダサーバ１３０のアドレス（リソースの場所情報）およびリソース情報の取得を要求する。
【００３４】
４）リソース情報検索プロバイダサーバ１４０は，リソース解決部１２３にリソース情報およびリソースの場所情報を返す。
リソース情報検索部１４１は，リソース情報データベースから，そのプリンシパルに対応するリソース情報およびリソースの場所情報を検索し，リソース解決部１２３に返信する。
【００３５】
（３）リソース情報の解析
１）リソース解決部１２３は，リソース情報を解析して，そのリソースに含まれる属性の項目を抽出する。リソース解決部１２３のリソース構造定義ＤＢ上にそのリソースの構造情報が保持されている場合（例えば，ID-SIS-PPなどの標準のスキーマが用いられているリソースの場合），リソース解決部１２３はリソースの構造を解析して，リソースに含まれる属性の項目を抽出できる。
ここでは，そのプリンシパルの属性情報が属性プロバイダ（１）〜（３）（属性プロバイダサーバ１３０（１）〜１３０（３））に登録され，かつ属性の項目が「名前」，「住所」であるとする。即ち，属性プロバイダ（１）〜（３）に対応する３組のリソース情報およびリソース場所情報が取得され，そのリソース情報から属性の項目「名前」，「住所」が抽出されている。
【００３６】
２）リソース解決できない場合，リソース解決部１２３は属性プロバイダサーバ１３０からリソースの構造情報を取得する。取得された構造情報に基づき，リソース中に含まれる属性の項目が抽出される。
【００３７】
（４）属性情報の一括取得要求
１）アプリケーション１２４は，リソース情報の一覧を表示するリソース情報表示画面をプリンシパルコンピュータ１１０上に表示させる（図５参照）。
本図に示されるように，３つのリソース場所情報に対応する属性プロバイダ（１）〜（３），および属性の項目「名前」，「住所」が対応して表示される。
【００３８】
２）プリンシパルコンピュータ１１０は，ポータルサイトサーバ１２０に属性情報を指定してそれらの一括取得を要求する。即ち，プリンシパルコンピュータ１１０からポータルサイトサーバ１２０に一括取得要求情報（一覧の中からプリンシパルによって複数選択された属性情報の一括取得処理を要求する情報）が送られる。
【００３９】
（５）属性情報の一括取得メッセージの生成
１）ポータルサイトサーバ１２０が一括取得要求情報を受け取ると，アプリケーション１２４は，一括処理メッセージ生成部１２１のインスタンスを生成する。
２）一括処理メッセージ生成部１２１は，その要求を受けて，一括取得用のメッセージを生成して，これをアプリケーション１２４に返す（図７参照）。
【００４０】
図７では，属性情報の一括取得を行うためのメッセージであるFDSのQueryメッセージ（以降，FDSQueryと表記する）の構造を模式的に示している。
記述部Ｄ１０がFDSQueryメッセージの全体を，記述部Ｄ１１が記述部Ｄ１０の一部の詳細を表す。
記述部Ｄ１１は，一括処理メッセージ生成部１２１で生成されるメッセージである。記述部Ｄ１１は，一括取得用のメッセージの基本となるものであり，前記DSTで定義されたQueryメッセージ（以降，DSTQueryメッセージと表記する）の<Extension>要素（DSTを拡張するために用意されている要素）を拡張し，その中に一括取得の対象となるリソース情報を含めている。リソース情報には，前記Discovery Serviceで定義された<ResourceOffering>要素（リソース情報を提供するための要素）を利用する。
【００４１】
（６）属性情報の一括取得
１）アプリケーション１２４は，メッセージ一括処理部１２２に対して一括処理を要求する。
２）メッセージ一括処理部１２２は，一括処理メッセージ解釈部１２５を用いて一括処理メッセージを解釈する。
【００４２】
３）メッセージ一括処理部１２２の一括代理処理部１２６は，属性情報提供部１３１（１），１３１（２）それぞれに，属性要求メッセージを生成して，送信する。属性情報提供部１３１（１），１３１（２）は，属性要求メッセージに対応して，属性情報を返信する。その結果，メッセージ一括処理部１２２は，属性情報提供部１３１（１），１３１（２）それぞれから，属性情報を取得する。
【００４３】
（７）属性情報の一括表示
１）メッセージ一括処理部１２２の一括処理メッセージ解釈部１２５は，各属性プロバイダサーバ１３０から取得した属性情報を応答メッセージにまとめる。
２）メッセージ一括処理部１２２の一括処理メッセージ解釈部１２５は，一括処理の応答としてアプリケーション１２４に属性情報を送る。
【００４４】
３）アプリケーション１２４は属性情報を受け取り，プリンシパルコンピュータ１１０上に属性情報の一覧を表示させる（図６参照）。
属性プロバイダ（１），（２）それぞれで登録された属性の項目「名前」，「住所」が表示される。この結果，プリンシパルが属性プロバイダ（１），（２）それぞれでの「名前」，「住所」の登録状況を確認できる。
【００４５】
登録情報管理システム１００を用いることで，異なるドメイン上で分散して管理されているプリンシパルのアイデンティティ（属性情報）のメンテナンスが容易となる。即ち，アイデンティティの参照を一括して実行できる。一括して処理することで，個々に処理する場合と比べて，処理に要するデータ量を低減できる。
なお，属性情報の参照以外の属性情報の変更，削除等の処理一般についても，同様に一括して実行させることが可能である。
【００４６】
（第２の実施の形態）
図８は本発明の第２実施形態に係る登録情報管理システム２００を表すブロック図である。
登録情報管理システム２００は，FQMSを提供するものであり，プリンシパルコンピュータ２１０，ポータルサイトサーバ２２０，属性プロバイダサーバ２３０，リソース情報検索プロバイダサーバ２４０，ＦＤＳサーバ２５０，オーソリティサーバ２６０を備える。
【００４７】
本実施形態では，ポータルサイトサーバ２２０とＦＤＳサーバ２５０との連携によってFDSを提供すると共に，ＦＤＳサーバがプリンシパルの代理人として機能する。また，この代理人による処理の信頼性を確保するための認証処理を行い，オーソリティサーバ２６０がその中心的な役割を担う。
【００４８】
プリンシパルコンピュータ２１０は，プリンシパル（サービス利用者）が操作するコンピュータである。プリンシパルコンピュータ２１０は，そのプリンシパルの属性情報の一覧を要求する入力手段，例えば，キーボードと，この要求に応じて，そのプリンシパルの属性情報の一覧を提示する表示部，例えば，液晶表示装置を備える。
【００４９】
ポータルサイトサーバ２２０は，プリンシパルコンピュータ２１０とネットワーク（例えば，インターネット）で接続されるコンピュータであり，例えば，インターネット上のポータルサイトに配置される。ポータルサイトサーバ２２０は，一括処理メッセージ生成部２２１，メッセージ一括処理部２２２，リソース解決部２２３，アプリケーション２２４を有する。
【００５０】
一括処理メッセージ生成部２２１，メッセージ一括処理部２２２は，アプリケーション２２４のプロキシとして属性情報の一括処理を担うものであり，ポータルサイトサーバ２２０のライブラリを用いて構築できる。
一括処理メッセージ生成部２２１は，属性プロバイダサーバ２３０で管理されている属性情報を一括処理（取得又は修正）する際に用いる一括処理メッセージを生成する。
【００５１】
メッセージ一括処理部２２２は，一括処理メッセージ送信部２２７を有する。
一括処理メッセージ送信部２２７は，一括処理メッセージ生成部２２１で生成された一括処理メッセージをＦＤＳサーバ２５０に送信する。
【００５２】
リソース解決部１２３は，リソースを解決すると共に，プリンシパルのリソース場所情報を提供するものであり，登録属性情報ファイルの複写に含まれる属性の項目を抽出する抽出手段として機能する。即ち，ここでいうリソースの解決は，プリンシパルの属性の項目を抽出することにある。
リソース解決部１２３は，リソース情報検索プロバイダサーバ１４０にプリンシパルを識別するプリンシパル識別子を送り，リソース情報検索の検索を要求し，リソース情報（リソース場所情報を含む）を受け取る。リソース解決部１２３はリソース情報を解析して，そのリソース情報に含まれる属性の項目を抽出する。
【００５３】
ソース解決部２２３は，リソース情報（登録属性情報ファイル）の構造を定義するリソース構造定義情報を含むリソース構造定義テーブルを保持するデータベース（リソース構造定義ＤＢ）を有する。ソース解決部２２３は，リソース構造定義テーブルを用いてリソース情報から属性の項目を抽出する。なお，リソース構造の定義の例として，Discovery Serviceでの<ResourceOffering>を挙げることができる。
【００５４】
リソース構造定義テーブルで構造が定義されないリソース情報については，属性プロバイダサーバ２３０から取得されるリソース構造定義情報を用いて，属性の項目を抽出する。ソース解決部２２３は，取得したリソース情報の構造定義情報がリソース構造定義ＤＢ中に格納されていない場合に，そのリソース情報の構造の検索を属性プロバイダサーバ２３０に要求し，リソース構造定義情報を取得する。
【００５５】
アプリケーション２２４は，プリンシパルコンピュータ２１０とのユーザインタフェースの役割を果たし，属性情報の一括処理を行うためにリソース解決部２２３に要求を送り，その結果をプリンシパルコンピュータ２１０に提供する。アプリケーション２２４は，抽出される属性の項目を提示する提示手段および処理要求情報を受信する処理要求情報受信手段として機能する。
アプリケーション２２４は，オーソリティサーバ２６０に対してリソース操作の処理権限を委譲してもらうための権限委譲情報を要求する。アプリケーション２２４は，オーソリティサーバ２６０から受け取った権限委譲情報をＦＤＳサーバ２５０に送信する。
【００５６】
ＦＤＳサーバ２５０は，権限委譲情報により，属性プロバイダサーバ２３０に対して自身がサブジェクトの正当な代理者であることを証明できる。また，属性プロバイダサーバ２３０は，権限委譲情報に基づいた信頼性情報からリソース操作の要求発信元がプリンシパルであることを確認できる。
【００５７】
属性プロバイダサーバ２３０は，属性情報提供部２３１を有する。属性プロバイダサーバ２３０は，オーソリティサーバ２６０に信頼性情報を要求して，それを検証した後，属性処理を行う。
【００５８】
リソース情報検索プロバイダサーバ２４０は，プリンシパルが所有するリソース情報を管理しており，要求に応じてリソース情報を検索するリソース情報検索部２４１を有する。
リソース情報検索部２４１は，データベース（リソース情報ＤＢ）を有する。リソース情報ＤＢは，プリンシパル識別子，プリンシパルのリソース情報（そのプリンシパルの属性情報が登録されている属性プロバイダサーバ２３０のアドレス（リソースの場所情報）を含む）を対応して保持する。即ち，リソース情報ＤＢは，プリンシパル（個人）と，リソース（登録属性情報ファイル）の複写と，を対応して記憶する記憶手段として機能する。
【００５９】
ＦＤＳサーバ２５０は，メッセージ一括処理部２５１を有する。
メッセージ一括処理部２５１は，一括処理メッセージ解釈部２５２と，一括代理処理部２５３とを有する。
【００６０】
一括処理メッセージ解釈部２５２は，サブジェクトの代理として属性情報の一括処理を担い，一括処理メッセージを解釈する。また，一括処理メッセージ解釈部２５２は，一括処理メッセージを受信すると，ポータルサイトサーバ２２０に対して権限委譲情報を要求する。一括処理メッセージ解釈部２５２は，委譲要求メッセージを送信する委譲要求メッセージ送信手段および委譲許可メッセージを受信する委譲許可メッセージ受信手段として機能する。
【００６１】
一括代理処理部２５３は，属性情報を提供する属性プロバイダサーバ２３０に対して代理で属性情報の取得要求を行い，その結果を１つにまとめてアプリケーション２２４に返す。一括代理処理部２５３は，個別処理メッセージを生成する個別処理メッセージ生成手段およびと個別処理メッセージを前記複数のサイトに送信する個別処理メッセージ送信手段して機能する。
一括代理処理部２５３は，属性プロバイダサーバ２３０に属性情報を要求するメッセージに権限委譲情報を含める。自身の信頼性，すなわち自身がサブジェクトの正当な代理者であることを証明するためである。
【００６２】
オーソリティサーバ２６０は，プリンシパルのアイデンティティ情報を保管し，サブジェクトを認証する。オーソリティサーバ２６０は，例えば，第三者機関によって管理される。
オーソリティサーバ２６０は，ポータルサイトサーバ２２０から権限委譲要求メッセージ（認可対象主体（ＦＤＳサーバ２５０），認可対象動作（例えば，読み出し），認可対象リソース（リソース識別情報，例えば，リソース場所情報）の情報を含む）を受け取って，権限委譲応答メッセージを返信する。
その後，オーソリティサーバ２６０は，属性プロバイダサーバ２３０から信頼性情報要求メッセージ（認可対象主体（ＦＤＳサーバ２５０），認可対象動作，認可対象リソースの情報を含む）を受け取って，信頼性情報メッセージを返信する。
【００６３】
このとき，オーソリティサーバ２６０は，権限委譲要求メッセージと頼性情報要求メッセージとに含まれる情報（認可対象主体，認可対象動作，認可対象リソースを識別する情報）が一致しているか否かに基づいて，認可対象主体による認可対象リソースへの認可対象動作の可否（アクセスの可否）を決定し，信頼性情報メッセージにこのアクセス可否情報を含め，返信する。
この信頼性情報メッセージに基づいて，属性プロバイダサーバ２３０は，ＦＤＳサーバ２５０へのリソースのアクセスを許可あるいは禁止する。この結果，プリンシパルの代理人としてのＦＤＳサーバ２５０の信頼性が保証される。
【００６４】
（登録情報管理システム２００の動作）
図９は，登録情報管理システム２００での処理の流れの概要を示したシーケンス図である。図１０は，登録情報管理システム２００での処理の流れの詳細を示したシーケンス図である。図１１は，登録情報管理システム２００での信頼性確立のための処理の流れの一例を示したシーケンス図である。
図１２〜図２１は，登録情報管理システム２００で送受信されるメッセージの構造の例を示す図である。
【００６５】
処理の流れは以下の通りである。
（１）リソース情報の検索要求
１）プリンシパルコンピュータ２１０が，ポータルサイトサーバ２２０にアクセスする。
２）ポータルサイトサーバ２２０は，プリンシパルコンピュータ２１０にリソース情報検索画面を表示させる（図４参照）。
３）プリンシパルコンピュータ２１０は，ポータルサイトサーバ２２０にリソース情報の検索を要求する。
プリンシパルが，リソース情報検索画面（図４参照）からリソース情報の検索を要求する情報（検索要求情報）を入力または選択することで，プリンシパルコンピュータ２１０からポータルサイトサーバ２２０に検索要求情報が送られる。
【００６６】
（２）リソース情報の検索
１）ポータルサイトサーバ２２０が検索要求情報を受け取ると，アプリケーション２２４は，リソース解決部２２３のインスタンスを生成する。
２）アプリケーション２２４は，リソース解決部２２３に対してプリンシパル識別子を送り，そのプリンシパルのリソース情報の検索を要求する。
３）リソース解決部２２３は，リソース情報検索プロバイダサーバ２４０に対して，プリンシパル識別子を送り，そのプリンシパルのリソース情報の取得を要求する。
４）リソース情報検索プロバイダサーバ２４０は，リソース解決部２２３にリソース情報（リソースの場所情報を含む）を返す。
【００６７】
（３）リソース情報の解析
１）リソース解決部２２３は，リソース情報を解析して，そのリソースに含まれる属性の項目を抽出する。リソース解決部２２３のリソース構造定義ＤＢ上にそのリソースの構造情報が保持されている場合（例えば，ID-SIS-PPなどの標準のスキーマが用いられているリソースの場合），リソース解決部２２３はリソースの構造を解析して，リソースに含まれる属性の項目を抽出できる。
２）リソース解決できない場合，リソース解決部２２３は属性プロバイダサーバ２３０からリソースの構造情報を取得する。取得された構造情報に基づき，リソース中に含まれる属性の項目が抽出される。
【００６８】
（４）属性情報の一括取得要求
１）アプリケーション２２４は，リソース情報の一覧を表示するリソース情報表示画面をプリンシパルコンピュータ２１０上に提示させる（図５参照）。
２）プリンシパルコンピュータ２１０は，ポータルサイトサーバ２２０に属性情報を指定してそれらの一括取得を要求する。即ち，プリンシパルコンピュータ２１０からポータルサイトサーバ２２０に一括取得要求情報（一覧の中からプリンシパルによって複数選択された属性情報の一括取得処理を要求する情報）が送られる。
【００６９】
（５）属性情報の一括取得メッセージの生成
１）ポータルサイトサーバ２２０が一括取得要求情報を受け取ると，アプリケーション２２４は，一括処理メッセージ生成部２２１のインスタンスを生成する。
２）一括処理メッセージ生成部２２１は，その要求を受けて，一括取得用のメッセージを生成して，これをアプリケーション２２４に返す（図１２Ａ，図１２Ｂ参照）。
３）ポータルサイトサーバ２２０のメッセージ一括処理部２２２は，一括処理メッセージをＦＤＳサーバ２５０のメッセージ一括処理部２５１に送信する。
【００７０】
図１２Ａは，属性情報を取得する一括処理メッセージの一例の全体を示す。図１２Ｂは，図１２Ａの一括処理メッセージの<Delegation>要素部分Ａ１１を拡大して示す。図１２Ａ，１２Ｂの一括処理メッセージは，Liberty ID-WSF Soap Binding Specificationに基づく。一括処理メッセージのヘッダ部（Header）内には，この仕様を独自に拡張して定義した<Delegation>要素部分Ａ１１の直下に<DelegationRef>要素が配置される。<DelegationRef>要素内に，識別子（itemID属性），権限を委譲する処理の種類（type属性），代理処理対象への参照（ref属性），代理処理対象となるリソース（resourceID属性）が含まれる。このresourceID属性が，リソース場所情報に相当する。
このヘッダ部は，ボディ部（Body）の<Extension>要素と対応する。即ち，ボディ部の<Extension>要素（本図のＡ１２）でのitemID属性とヘッダ部のref属性とが一致している。
【００７１】
ここでは，属性プロバイダ（１），（２）に対応して，itemID，type属性，ref属性，resourceID属性が2組示される（「"query#000000001"，"Query"，"000000001"，""」，「"query#000000001"，"Query"，"000000002"，""」）。
このヘッダ部に含まれる複数組の属性と対応して，ボディ部（Body）に<Extension>要素が複数配置される。図１２Aでは，ヘッダ部のref属性"000000001"，"000000002"に対応して，ボディ部の<Extension>要素が重なって配置される。
なお，mustUnderstand属性及びactor属性は，SOAPの仕様に規定されている。
【００７２】
（６）権限委譲処理
１）メッセージ一括処理部２５１は，一括処理メッセージを受信すると，ポータルサイトサーバ２２０に対し代理処理が行えるように権限委譲を要求する（権限委譲要求メッセージの送信）。
図１３は，権限委譲要求メッセージの一例を示す図である。本図では，独自に定義した<DelegationAuthorityRequest>要素の直下の<DelegationRef>要素に，認可対象となる主体名（<Subject>要素，ＦＤＳサーバ２５０），認可対象となる動作（<Action>要素），認可対象となるリソース（<Resource>要素）を含めている。
【００７３】
２）ポータルサイトサーバ２２０は，オーソリティサーバ２６０に権限委譲の処理を要求する（権限委譲要求メッセージの送信）。
図１４Ａ，図１４Ｂは，権限委譲要求メッセージの一例を示す図である。図１４Ａは，権限委譲要求メッセージの全体を示す。図１４Ｂは，図１４Ａ中の<DelegationRequest>要素Ａ２０の詳細を表す図である。独自に定義した<DelegationRequest>要素の直下の<Delegation>要素に，認可対象となる主体名（<Subject>要素（Ａ２１），ＦＤＳサーバ２５０），認可対象となる動作（<Action>要素（Ａ２２）），認可対象となるリソース（<Resource>要素（Ａ２３））を含めている。
【００７４】
<Resource>要素はリソース場所情報に対応し，リソース場所情報によってリソースを識別している。ここでは<Action>要素が，「Read（読み出し）」である。この権限委譲要求メッセージには，図１２Ａに示されるように，Security Assertion Markup Language（以降，SAMLと表記する）のAuthenticationQuery（認証要求問合せ）メッセージが含まれる。
なお，Liberty ID-WSF Soap Binding Specification以外に，SPML（Service Provisioning Markup Language）などの標準仕様を利用可能である。
【００７５】
３）オーソリティサーバ２６０は，ＦＤＳサーバ２５０に対して代理処理権限を付与する（権限委譲応答メッセージの返信）。
図１５は，権限委譲応答メッセージの例を示す図である。本図では，権限委譲情報としてSecurity Assertion Markup Language（以降，SAMLと表記する）のAssertionを用いている。<Assertion>要素（Ａ２４）に認可対象となる主体（ＦＤＳサーバ２５０）への認証のアサーション（主張）が含まれる。
【００７６】
４）ポータルサイトサーバ２２０は，メッセージに権限委譲情報を含めてＦＤＳサーバ２５０に送信する（権限委譲メッセージの送信）。
図１６は，権限委譲メッセージの例を示す図である。<Assertion>要素（Ａ２５）に認可対象となる主体（ＦＤＳサーバ２５０）への認証のアサーション（主張）が含まれる。
【００７７】
（７）属性情報の一括取得
１）メッセージ一括処理部２５１は，一括処理メッセージ解釈部２５２を用いて一括処理メッセージを解釈して，属性プロバイダサーバ２３０毎にメッセージを分割する。
【００７８】
２）メッセージ一括処理部２５１の一括代理処理部２５３は，属性プロバイダサーバ２３０毎に，受け取った権限委譲情報を含めた個別属性要求メッセージを生成する。
図１７は，個別属性取得要求メッセージの例を示す図である。本図では，Liberty ID-WSF SOAP Binding Specificationで定義されているSOAPヘッダ内の<Assertion>要素（Ａ３１）に認可対象となる主体（ＦＤＳサーバ２５０）への認証のアサーション（主張）が含まれる（<wsse:Security>要素の直下に<saml:Assertion>要素を含めている）。また，ここでは，属性プロバイダサーバ２３０毎に対応して，<Query>要素（Ａ３２）は1つだけとなっている。
【００７９】
３）ＦＤＳサーバ２５０は，属性要求メッセージを属性プロバイダサーバ２３０（１），２３０（２）に送信し，属性情報の取得を要求する。
【００８０】
（８）信頼性の確認
１）属性プロバイダサーバ２３０（１），２３０（２）は，ＦＤＳサーバ２５０の信頼性を検証するために，属性要求メッセージ含まれている権限委譲情報を用いて，オーソリティサーバ２６０に信頼性情報を要求する（信頼性情報要求メッセージの送信）。
図１８は，信頼性情報要求メッセージの例を示す図である。本図では，信頼性情報を取得するために，SAMLのAuthorizationDecisionQuery（認可決定問合せ要求）メッセージを用いている。AuthorizationDecisionQueryのメッセージ構造は，SAMLの仕様に記述される。
信頼性情報要求メッセージのAssertion>要素（Ａ３３）に認可対象となる主体（ＦＤＳサーバ２５０）への認証のアサーション（主張）が含まれる。また，信頼性情報要求メッセージには，リソースへのアクセスを要求する情報が含まれる（Ａ３４）。
【００８１】
２）オーソリティサーバ２６０は，権限委譲情報からＦＤＳサーバ２５０がポータルサイトサーバ２２０の正当な代理者であることを証明する信頼性情報を属性プロバイダサーバ２３０（１），２３０（２）に返信する（信頼性情報メッセージの送信）。
図１９は，信頼性情報メッセージの例を示す図である。本図では，信頼性情報メッセージとして，SAMLのAuthorizationStatement（認可決定応答）メッセージを示している。AuthorizationStatementのメッセージ構造は，SAMLの仕様に記述される。
信頼性情報メッセージには，リソースへのアクセスの許可，禁止を表すアクセス許可情報（Ａ３５）および認可対象となる主体（ＦＤＳサーバ２５０）を表す情報（Ａ３６）が含まれる。
本図では，Decision属性の値が“Permit（許可）”であることから，正当な代理（アクセスの許可）を意味する。
【００８２】
３）属性プロバイダサーバ２３０（１），２３０（２）は，信頼性情報を検証して，属性プロバイダサーバ２３０（１）は要求発信元がポータルサイトサーバ２２０であり，ＦＤＳサーバ２５０がポータルサイトサーバ２２０の正当な代理者であることを確認する。既述のように，信頼性情報メッセージのDecision属性の値によって正当な代理の有無を確認できる。
【００８３】
（９）属性情報の送信
１）ＦＤＳサーバ２５０の信頼性を検証できれば，属性プロバイダサーバ２３０（１），２３０（２）は属性情報を取得する。
２）属性プロバイダサーバ２３０は，ＦＤＳサーバ２５０に属性情報を含めたメッセージを返信する（属性取得応答メッセージの送信）。
図２０は，属性取得応答メッセージの例を示す図である。本図では，図１７の<Query>要素が1つだったので，<QueryResponse>要素（Ａ４１）も1つである。即ち，ＦＤＳサーバ２５０は，属性プロバイダサーバ２３０（１），２３０（２）それぞれから別個にの属性情報を受け取る。
【００８４】
（７）属性情報の一括表示
１）メッセージ一括処理部２５１の一括処理メッセージ解釈部２５２は，各属性プロバイダサーバ２３０（１），２３０（２）から取得した属性情報を応答メッセージにまとめる。
２）メッセージ一括処理部２５１の一括処理メッセージ解釈部２５２は，一括処理要求の応答としてポータルサイトサーバ２２０のメッセージ一括処理部２２２に属性情報を返す（一括処理応答メッセージの送信）。一括処理の結果は1つにまとめて，一括処理応答メッセージのSOAP Bodyの直下に含める。
図２１は，一括処理応答メッセージの一例を示す図である。一括処理の結果がまとめられていることから，<QueryResponse>要素が複数存在する。
３）ＦＤＳサーバ２５０は，一括処理応答メッセージをポータルサイトサーバ２２０に返信する。
４）アプリケーション２２４は属性情報を受け取り，プリンシパルコンピュータ２１０上に属性情報の一覧を表示させる（図６参照）。
【００８５】
登録情報管理システム２００を用いることで，異なるドメイン上で分散して管理されているプリンシパルのアイデンティティ（属性情報）のメンテナンスが容易となる。即ち，アイデンティティの参照を一括して実行できる。一括して処理することで，個々に処理する場合と比べて，処理に要するデータ量を低減できる。
また，プリンシパルから一括処理の権限を委譲された代理者（ＦＤＳサーバ２５０）の正当性の確保が容易となる。
なお，属性情報の参照以外の属性情報の変更，削除等の処理一般についても，同様に一括して実行させることが可能である。
【００８６】
（第３の実施形態）
第１，第２の実施形態では，データ操作の対象が属性情報であったが，データ操作の対象をリソースの構造情報とすることも可能である。即ち，リソースの構造情報の交渉取得を一括して行うことができる。
リソースの提供者とサブジェクトの間でリソース情報や属性情報に関して事前に合意が取れている場合，すなわちアイデンティティ情報の構造が共通化されている場合，リソース解決における問題は生じない。例えば，ID-SIS-PPなどの標準のスキーマを用いる場合である。
【００８７】
しかし，標準のスキーマが独自に拡張されていたり，独自に定義されたスキーマが用いられていると，どのようなリソース情報なのかを把握できなくなり，リソース解決だけでなく属性情報の交換も困難になってしまう。
リソースの構造情報（スキーマなど）を取得し，それを解析することで，動的にリソースを解決することが考えられる。場合によっては，リソースの構造情報の取得は１つの属性プロバイダサーバでなく，複数に対して行うことが想定される。
【００８８】
このように，リソースの構造情報の一括した取得は，有用である。例えば，リソース解決部１２３，２２３が属性プロバイダサーバ１３０，２３０から構造情報を一括して取得できる。
本実施形態は，データ操作の対象が異なることを除けば，第１，第２の実施形態と本質的に異なる訳ではないので，詳細な説明を省略する。
【００８９】
（その他の実施形態）
本発明の実施形態は上記の実施形態に限られず拡張，変更可能であり，拡張，変更した実施形態も本発明の技術的範囲に含まれる。
【図面の簡単な説明】
【００９０】
【図１】本発明の第１実施形態に係る登録情報管理システムを表すブロック図である。
【図２】第１実施形態に係る登録情報管理システムでの処理の流れの概要を示したシーケンス図である。
【図３】第１実施形態に係る登録情報管理システムでの処理の流れの詳細を示したシーケンス図である。
【図４】プリンシパルコンピュータ上に表示される画面の例を示す図である。
【図５】プリンシパルコンピュータ上に表示される画面の例を示す図である。
【図６】プリンシパルコンピュータ上に表示される画面の例を示す図である。
【図７】属性情報を一括取得するためのメッセージの構造の例を示す図である。
【図８】本発明の第２実施形態に係る登録情報管理システムを表すブロック図である。
【図９】第２実施形態に係る登録情報管理システムでの処理の流れの概要を示したシーケンス図である。
【図１０】第２実施形態に係る登録情報管理システムでの処理の流れの詳細を示したシーケンス図である。
【図１１】第２実施形態に係る登録情報管理システムでの信頼性確立のための処理の流れを示したシーケンス図である。
【図１２Ａ】第２実施形態に係る登録情報管理システムで送受信されるメッセージの構造の例の全体を示す図である。
【図１２Ｂ】第２実施形態に係る登録情報管理システムで送受信されるメッセージの構造の例の一部を示す図である。
【図１３】第２実施形態に係る登録情報管理システムで送受信されるメッセージの構造の例を示す図である。
【図１４Ａ】第２実施形態に係る登録情報管理システムで送受信されるメッセージの構造の例の全体を示す図である。
【図１４Ｂ】第２実施形態に係る登録情報管理システムで送受信されるメッセージの構造の例の一部を示す図である。
【図１５】第２実施形態に係る登録情報管理システムで送受信されるメッセージの構造の例を示す図である。
【図１６】第２実施形態に係る登録情報管理システムで送受信されるメッセージの構造の例を示す図である。
【図１７】第２実施形態に係る登録情報管理システムで送受信されるメッセージの構造の例を示す図である。
【図１８】第２実施形態に係る登録情報管理システムで送受信されるメッセージの構造の例を示す図である。
【図１９】第２実施形態に係る登録情報管理システムで送受信されるメッセージの構造の例を示す図である。
【図２０】第２実施形態に係る登録情報管理システムで送受信されるメッセージの構造の例を示す図である。
【図２１】第２実施形態に係る登録情報管理システムで送受信されるメッセージの構造の例を示す図である。
【符号の説明】
【００９１】
１００…登録情報管理システム、１１０…プリンシパルコンピュータ、１２０…ポータルサイトサーバ、１２１…一括処理メッセージ生成部、１２２…メッセージ一括処理部、１２３…リソース解決部、１２４…アプリケーション、１２５…一括処理メッセージ解釈部、１２６…一括代理処理部、１３０…属性プロバイダサーバ、１３１…属性情報提供部、１４０…リソース情報検索プロバイダサーバ、１４１…リソース情報検索部、２００…登録情報管理システム、２１０…プリンシパルコンピュータ、２２０…ポータルサイトサーバ、２２１…一括処理メッセージ生成部、２２２…メッセージ一括処理部、２２３…リソース解決部、２２４…アプリケーション、２２７…一括処理メッセージ送信部、２３０…属性プロバイダサーバ、２３１…属性情報提供部、２４０…リソース情報検索プロバイダサーバ、２４１…リソース情報検索部、２５０…ＦＤＳサーバ、２５１…メッセージ一括処理部、２５２…一括処理メッセージ解釈部、２５３…一括代理処理部、２６０…オーソリティサーバ
【特許請求の範囲】
【請求項１】
ネットワーク上の複数のサイトにそれぞれ登録され，かつ同一の個人の属性情報を有する複数の登録属性情報ファイルへの処理を要求する処理要求情報を受信する処理要求情報受信手段と，
前記受信される処理要求情報に基づき，前記複数の登録属性情報ファイルへの一括処理を要求する一括処理メッセージを生成する一括処理メッセージ生成手段と，
前記生成される一括処理メッセージに基づき，前記複数の登録属性情報ファイルそれぞれへの処理を要求する複数の個別処理メッセージを生成する個別処理メッセージ生成手段と，
前記生成される複数の個別処理メッセージを前記複数のサイトに送信する個別処理メッセージ送信手段と，
を具備することを特徴とする登録情報管理システム。
【請求項２】
前記受信される処理要求情報に基づき，前記登録属性情報ファイルへの処理の権限委譲を要求する委譲要求メッセージを送信する委譲要求メッセージ送信手段と，
前記送信される委譲要求メッセージに対応して返信され，かつ前記権限委譲を許可する委譲許可情報を含む委譲許可メッセージを受信する委譲許可メッセージ受信手段と，をさらに具備し，
前記受信される委譲許可メッセージに対応して，前記一括処理メッセージ生成手段が，委譲許可情報を含む一括処理メッセージを生成する
ことを特徴とする請求項１記載の登録情報管理システム。
【請求項３】
前記一括処理メッセージが，権限委譲の主体を表す識別子をさらに含み，
前記登録情報管理システムが，前記識別子に基づいて，権限委譲の信頼性を確認する信頼性確認手段をさらに具備する
ことを特徴とする請求項２記載の登録情報管理システム。
【請求項４】
前記処理が，前記複数の登録属性情報ファイルの取得，修正，またはその構造情報の取得の少なくとも何れかである
ことを特徴とする請求項１記載の登録情報管理システム。
【請求項５】
前記個人と，前記登録属性情報ファイルの複写と，を対応して記憶する記憶手段と，
前記記憶された登録属性情報ファイルの複写に含まれる属性の項目を抽出する抽出手段と，
前記抽出される属性の項目を提示する提示手段と，をさらに具備し，
前記処理要求情報送信手段が，前記複数の登録属性情報ファイルから選択される属性の項目への処理を要求する処理要求情報を受信する，
ことを特徴とする請求項１記載の登録情報管理システム。
【請求項１】
ネットワーク上の複数のサイトにそれぞれ登録され，かつ同一の個人の属性情報を有する複数の登録属性情報ファイルへの処理を要求する処理要求情報を受信する処理要求情報受信手段と，
前記受信される処理要求情報に基づき，前記複数の登録属性情報ファイルへの一括処理を要求する一括処理メッセージを生成する一括処理メッセージ生成手段と，
前記生成される一括処理メッセージに基づき，前記複数の登録属性情報ファイルそれぞれへの処理を要求する複数の個別処理メッセージを生成する個別処理メッセージ生成手段と，
前記生成される複数の個別処理メッセージを前記複数のサイトに送信する個別処理メッセージ送信手段と，
を具備することを特徴とする登録情報管理システム。
【請求項２】
前記受信される処理要求情報に基づき，前記登録属性情報ファイルへの処理の権限委譲を要求する委譲要求メッセージを送信する委譲要求メッセージ送信手段と，
前記送信される委譲要求メッセージに対応して返信され，かつ前記権限委譲を許可する委譲許可情報を含む委譲許可メッセージを受信する委譲許可メッセージ受信手段と，をさらに具備し，
前記受信される委譲許可メッセージに対応して，前記一括処理メッセージ生成手段が，委譲許可情報を含む一括処理メッセージを生成する
ことを特徴とする請求項１記載の登録情報管理システム。
【請求項３】
前記一括処理メッセージが，権限委譲の主体を表す識別子をさらに含み，
前記登録情報管理システムが，前記識別子に基づいて，権限委譲の信頼性を確認する信頼性確認手段をさらに具備する
ことを特徴とする請求項２記載の登録情報管理システム。
【請求項４】
前記処理が，前記複数の登録属性情報ファイルの取得，修正，またはその構造情報の取得の少なくとも何れかである
ことを特徴とする請求項１記載の登録情報管理システム。
【請求項５】
前記個人と，前記登録属性情報ファイルの複写と，を対応して記憶する記憶手段と，
前記記憶された登録属性情報ファイルの複写に含まれる属性の項目を抽出する抽出手段と，
前記抽出される属性の項目を提示する提示手段と，をさらに具備し，
前記処理要求情報送信手段が，前記複数の登録属性情報ファイルから選択される属性の項目への処理を要求する処理要求情報を受信する，
ことを特徴とする請求項１記載の登録情報管理システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２Ａ】
【図１２Ｂ】
【図１３】
【図１４Ａ】
【図１４Ｂ】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２Ａ】
【図１２Ｂ】
【図１３】
【図１４Ａ】
【図１４Ｂ】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【公開番号】特開２００８−３３６３８（Ｐ２００８−３３６３８Ａ）
【公開日】平成２０年２月１４日（２００８．２．１４）
【国際特許分類】
【出願番号】特願２００６−２０６４７２（Ｐ２００６−２０６４７２）
【出願日】平成１８年７月２８日（２００６．７．２８）
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【出願人】（３０１０６３４９６）東芝ソリューション株式会社 (1,478)
【公開日】平成２０年２月１４日（２００８．２．１４）
【国際特許分類】
【出願日】平成１８年７月２８日（２００６．７．２８）
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【出願人】（３０１０６３４９６）東芝ソリューション株式会社 (1,478)
[ Back to top ]