JP2020046959A - 情報処理システム、情報処理装置、制御方法、及び制御プログラム - Google Patents

Abstract

【課題】情報処理システムにおいて、メッセージ量を削減する。【解決手段】第一の情報処理装置が仲介装置１０を介して第二の情報処理装置から複数のユーザのユーザデータを取得する情報処理システムにおいて、前記第一の情報処理装置は前記複数のユーザのユーザデータについて、抽出用情報の取得要求を前記第二の情報処理装置に送信し、前記仲介装置１０は、前記第一の情報処理装置が前記取得要求に応じて前記第二の情報処理装置から受信した前記抽出用情報に基づいた情報を前記第一の情報処理装置から受信し、受信した前記情報に基づいて、前記取得要求の対象となる複数のユーザを抽出し、抽出した前記複数のユーザについての情報を前記第二の情報処理装置に送信し、前記第二の情報処理装置は、前記仲介装置１０により抽出された前記複数のユーザについての情報に基づき、前記複数のユーザのユーザデータを抽出して一括して前記第一の情報処理装置に送信する。【選択図】図７

Description

本発明は、情報処理システム、情報処理装置、制御方法、及び制御プログラムに関する。

種々のサービス事業者毎に保有するパーソナルデータを管理するサービスとして、ＰＤＳ（Personal Data Store；パーソナルデータ・ストア）がある。また、このようなパーソナルデータはユーザデータともいい、パーソナルデータを第三者が活用すべく、第三者にパーソナルデータを提供する手法の開発が広く行なわれている。

第三者にパーソナルデータを提供する方式としてＵＭＡ（User Managed Access）がある。このＵＭＡでは、第三者であるクライアント（データ利用者）のクライアントサーバと、サービス事業者（データ提供者）のサーバであるリソースサーバ（Resource Server；RS）との間に認可サーバ（Authorization Server ；AS）が設けられる。そして、この認可サーバが仲介者となり、クライアントサーバとリソースサーバ間でのデータ連携を仲介する。

このようなＵＭＡを利用したシステムは、認可サーバがクライアントの同意を代理として取得することにより、ＰＤＳを用いることなくリソースサーバがクライアントサーバに対して直接パーソナルデータを提供することを可能とする。

特開２０１５−２０１０９８号公報

上述したＵＭＡは、パーソナルデータが帰属するユーザ（オーナ）毎にパーソナルデータを連携させるプロトコルであるため、このようなＵＭＡを利用したシステムでは、クライアントサーバがユーザ毎にリソースサーバからパーソナルデータを取得することになる。そのため、クライアントサーバが、多数のユーザに関するパーソナルデータを取得しようとすると、メッセージが大量に発生するという課題がある。

１つの側面では、情報処理システムにおいて、メッセージ量の削減を目的とする。

この情報処理システムは、第一の情報処理装置が仲介装置を介して第二の情報処理装置から複数のユーザのユーザデータを取得する情報処理システムにおいて、前記第一の情報処理装置は、前記複数のユーザのユーザデータについて、抽出用情報の取得要求を前記第二の情報処理装置に送信し、前記仲介装置は、前記第一の情報処理装置が前記取得要求に応じて前記第二の情報処理装置から受信した前記抽出用情報に基づいた情報を前記第一の情報処理装置から受信し、受信した前記情報に基づいて、前記取得要求の対象となる複数のユーザを抽出し、抽出した前記複数のユーザについての情報を前記第二の情報処理装置に送信し、前記第二の情報処理装置は、前記仲介装置により抽出された前記複数のユーザについての情報に基づき、前記複数のユーザのユーザデータを抽出して一括して前記第一の情報処理装置に送信する。

一実施形態によれば、情報処理システムにおいて、メッセージ量を削減することができる。

実施形態の一例としての情報処理システムのハードウェア構成を例示する図である。 実施形態の一例としての情報処理システムにおける情報処理装置のハードウェア構成を例示する図である。 実施形態の一例としての情報処理システムにおけるユーザ端末のハードウェア構成を例示する図である。 実施形態の一例としての情報処理システムにおける情報処理装置の機能構成を例示する図である。 実施形態の一例としての情報処理システムにおけるトークン情報を例示する図である。 実施形態の一例としての情報処理システムにおける制御処理の概要を例示する図である。 実施形態の一例としての情報処理システムにおける制御処理の概要を例示する図である。 実施形態の一例としての情報処理システムにおける同意情報を例示する図である。 実施形態の一例としての情報処理システムにおけるユーザポリシー情報を例示する図である。 実施形態の一例としての情報処理システムにおけるフェーズ１の制御処理を例示する図である。 実施形態の一例としての情報処理システムにおいてリソースサーバが管理するフィルタ情報を例示する図である。 実施形態の一例としての情報処理システムにおける応答メッセージを例示する図である。 実施形態の一例としての情報処理システムにおいてクライアントサーバが管理するフィルタ情報を例示する図である。 実施形態の一例としての情報処理システムにおけるフェーズ２の制御処理を例示する図である。 実施形態の一例としての情報処理システムにおけるユーザ情報を例示する図である。 実施形態の一例としての情報処理システムにおけるフェーズ１の制御処理を例示するフローチャートである。 実施形態の一例としての情報処理システムにおけるフェーズ２の制御処理を例示するフローチャートである。 変形例としての情報処理システムにおけるフェーズ１の制御処理を例示する図である。 変形例としての情報処理システムにおけるフェーズ２の制御処理を例示する図である。

以下、図面を参照して本発明の実施の形態を説明する。ただし、以下に説明する実施形態は、あくまでも例示あり、以下に明示しない種々の変形や技術の適用を排除する意図等はない。例えば、本実施形態を、その趣旨を逸脱しない範囲で種々変形して実施することができる。なお、以下の実施形態で用いる図面において、同一符号を付した部分は、特に断らない限り、同一若しくは同様の部分を表す。

〔１〕一実施形態
〔１−１〕一実施形態に係る情報処理システムのハードウェア構成例
図１は、実施形態の一例としての情報処理システム１のハードウェア構成を例示する図である。なお、本実施形態に係る情報処理システム１においては、上述した認可サーバとして同意ポータルサーバ１０が設けられるものとする。

この図１に示すように、情報処理システム１は、同意ポータルサーバ１０と、クライアントサーバ２０と、リソースサーバ３０と、ユーザによって利用される１つ以上のユーザ端末４０−１，４０−２，・・・，４０−ｎ（ｎは整数）とを備える。以下、ユーザ端末を示す符号としては、複数のユーザ端末のうち１つを特定する必要があるときには符号４０−１，４０−２，・・・，４０−ｎを用いるが、任意のユーザ端末を指すときには符号４０を用いる。また、同意ポータルサーバ１０と、クライアントサーバ２０と、リソースサーバ３０と、複数のユーザ端末４０とは、インターネット等のネットワーク９０を介して接続される。

このクライアントサーバ２０は、データ利用者であるクライアントによって用いられるサーバであり、リソースサーバ３０は、データ提供者によって用いられるサーバである。なお、同意ポータルサーバ１０は認可サーバ（Authorization Server；AS）に相当し、このリソースサーバ３０はRSとも表す。また、同意ポータルサーバ１０は情報処理装置、または、仲介装置ともいう。

なお、図１には、情報処理システム１が、同意ポータルサーバ１０と、クライアントサーバ２０と、リソースサーバ３０とを１つずつ備える例を図示したが、それぞれ複数を備えてよい。

〔１−２〕一実施形態に係る情報処理システムにおける同意ポータルサーバのハードウェア構成例
図２は、実施形態の一例としての情報処理システム１における同意ポータルサーバ１０のハードウェア構成を例示する図である。

同意ポータルサーバ１０は、サーバ機能を有するコンピュータであり、この図２に示すように、ＣＰＵ（Central Processing Unit）１１、記憶部１２、メモリ１３、ＩＦ（Interface）部１４、入力部１５、及び、表示部１６を備えてよい。

ＣＰＵ１１は、後述する記憶部１２に格納されるＯＳ（Operating System）やプログラムを実行し、例えば、情報処理システム１における通信を実現すべく同意ポータルサーバ１０を制御する。本実施形態では、ＣＰＵ１１は、後述する制御プログラム９１を実行する。

記憶部１２は、種々のデータやプログラム等を格納するハードウェアの一例である。例えば、記憶部１２は、同意ポータルサーバ１０の二次記憶装置として使用されてよく、ＯＳやファームウェア、アプリケーション等のプログラム、及び、各種データが格納されてよい。記憶部１２としては、例えば、ＨＤＤ（Hard Disk Drive）等の磁気ディスク装置の他、ＳＳＤ(Solid State Drive)やＳＣＭ(Storage Class Memory)等の半導体記憶装置が挙げられる。また、記憶部１２は、同意ポータルサーバ１０の各種機能の全部若しくは一部を実現するプログラムを格納してもよい。

メモリ１３は、種々のデータやプログラムを格納するハードウェアの一例である。メモリ１３としては、揮発性メモリ、例えば、ＤＲＡＭ（Dynamic RAM）等のＲＡＭが挙げられる。なお、ＲＡＭはRandom Access Memoryの略称である。

ＩＦ部１４は、ネットワーク９０を介して、クライアントサーバ２０と、リソースサーバ３０と、複数のユーザ端末４０との間の各接続及び各通信の制御等を行なう通信インタフェースの一例である。例えば、ＩＦ部１４としては、イーサネット（登録商標）、光通信（例えばFibre Channel）等に準拠したアダプタが挙げられる。なお、同意ポータルサーバ１０は、図示しない管理者の管理端末との間の接続及び通信の制御等を行なう通信インタフェースをそなえてもよく、当該通信インタフェースを用い、ネットワーク９０を介して制御プログラム９１をダウンロードしてもよい。

入力部１５は、例えば、マウス、キーボード、タッチパネル、操作ボタン等の入力装置の少なくともいずれか一つを含んでよい。

表示部１６は、例えば、ディスプレイや、プロジェクタ、スピーカ、プリンタ等の出力装置の少なくともいずれか一つを含んでよい。

〔１−３〕一実施形態に係る情報処理システムにおけるユーザ端末のハードウェア構成例
図３は、実施形態の一例としての情報処理システム１におけるユーザ端末４０のハードウェア構成を例示する図である。

この図３に示すように、ユーザ端末４０は、ＣＰＵ４１、記憶部４２、メモリ４３、ＩＦ部４４、入力部４５、及び、表示部４６を備えてよい。

また、このユーザ端末４０は、インターネット等のネットワーク９０を介して、同意ポータルサーバ１０、クライアントサーバ２０、リソースサーバ３０、及び、他のユーザ端末４０と接続される。

ＣＰＵ４１は、後述する記憶部４２に格納されるＯＳやプログラムを実行し、情報処理システム１内での通信を実現する。本実施形態では、ＣＰＵ４１は、後述するポリシー登録プログラム９２を実行する。

記憶部４２は、種々のデータやプログラム等を格納するハードウェアの一例である。例えば、記憶部４２は、ユーザ端末４０の二次記憶装置として使用されてよく、ＯＳやファームウェア、アプリケーション等のプログラム、及び、各種データが格納されてよい。記憶部４２としては、例えば、ＨＤＤ等の磁気ディスク装置の他、ＳＳＤやＳＣＭ等の半導体記憶装置が挙げられる。また、記憶部４２は、ユーザ端末４０の各種機能の全部若しくは一部を実現するプログラムを格納してもよい。

メモリ４３は、種々のデータやプログラムを格納するハードウェアの一例である。メモリ２３としては、揮発性メモリ、例えば、ＤＲＡＭ等のＲＡＭが挙げられる。

ＩＦ部４４は、ネットワーク９０を介して、同意ポータルサーバ１０、クライアントサーバ２０、リソースサーバ３０、及び、他のユーザ端末４０との間の各接続及び各通信の制御等を行なう通信インタフェースの一例である。例えば、ＩＦ部４４としては、イーサネット（登録商標）、光通信（例えばFibre Channel）等に準拠したアダプタが挙げられる。なお、ユーザ端末４０は、図示しない管理者の管理端末との間の接続及び通信の制御等を行なう通信インタフェースをそなえてもよい。そして、当該通信インタフェースを用い、ネットワーク９０を介してポリシー登録プログラム９２をダウンロードしてもよい。

入力部４５は、例えば、マウス、キーボード、タッチパネル、操作ボタン等の入力装置の少なくともいずれか一つを含んでよい。

表示部４６は、例えば、ディスプレイや、プロジェクタ、スピーカ、プリンタ等の出力装置の少なくともいずれか一つを含んでよい。

なお、上述の如く構成されたユーザ端末４０としては、ＰＣ（Personal Computer）、タブレット、スマートフォン、ＰＤＡ（Personal Digital Assistant）、または、携帯電話等のコンピュータが挙げられる。

〔１−４〕一実施形態に係る情報処理システムにおける同意ポータルサーバの機能構成例
図４は、上述した図２に示す実施形態の一例としての情報処理システム１における同意ポータルサーバ１０の機能構成を例示する図である。

この図４に示すように、同意ポータルサーバ１０は、例示的に、ポリシー管理部５０、コマンド情報解析部５１、チケット発行部５２、チケット検証部５３、トークン発行部５４、及び、トークン検証部５５を備えてよい。

また、図４に示すように、記憶部１２は、同意情報６０、ユーザポリシー情報６１、チケット情報６２、トークン情報６３、基本情報６４、及び、ユーザ情報６５を備えてよい。

ポリシー管理部５０は、ユーザとクライアント（データ利用者）との間における、当該ユーザのパーソナルデータの取り扱いに関する契約に関し、ユーザが当該契約に同意するか否かを当該ユーザから取得し、例えば、記憶部１２の同意情報６０に格納する。本実施形態において、ポリシー管理部５０は、ユーザが、クライアントに対して自身のパーソナルデータの開示に同意するか否かを当該ユーザから取得し、記憶部１２の同意情報６０（後述）に格納する。なお、同意情報６０については後述する。

また、ポリシー管理部５０は、ユーザがユーザ端末４０を用いて登録したアクセス制御ポリシー（後述）を取得し、記憶部１２のユーザポリシー情報６１に格納する。本実施形態において、ポリシー管理部５０は、ユーザが自身のパーソナルデータのうち、クライアント（データ利用者）への開示を希望しない情報を当該ユーザから取得し、記憶部１２のユーザポリシー情報６１に格納する。なお、ユーザポリシー情報６１については後述する。このポリシー管理部は、対象ユーザ抽出部の一例である。

コマンド情報解析部５１は、リソースサーバ３０から取得したコマンド情報を保持して解析する。本実施形態において、コマンド情報解析部５１は、取得したコマンド情報を解析した結果、その取得したコマンドが「meta_info」であれば、現在の処理がフェーズ１（詳細は後述）におけるものであると判断する。

一方、コマンド情報解析部５１は、取得したコマンドが「M_all」であれば、現在の処理がフェーズ２（詳細は後述）におけるものであると判断する。

チケット発行部５２は、チケットを生成し、生成したチケットをリソースサーバ３０に対して送信（発行）する。このチケットとは、セキュアなデータ連携技術において公知であるため説明を省略するが、本実施形態では、クライアントサーバ２０に対して後述するトークンの発行に必要なものである。

また、チケット発行部５２は、このチケットを生成するために、例えば、ＵＭＡにおける公知のチケット生成手法を用いてもよい。

また、チケット発行部５２は、例えば、この送信したチケットに関する情報を記憶部１２のチケット情報６２に格納する。その際、チケット発行部５２は、この送信したチケットに関する情報を、例えば、当該セッションの識別子（ＩＤ）やクライアントサーバ２０の情報に対応させてチケット情報６２に格納してもよい。なお、チケット情報６２については後述する。

チケット検証部５３は、クライアントサーバ２０から送信されたチケットを受信し、受信したチケットがチケット発行部５２により生成されたチケットと同一であるかを検証する。その際、チケット検証部５３は、チケット情報６２を参照して当該検証を行なってもよい。

トークン発行部５４は、トークンを生成し、クライアントサーバ２０に対してトークンを送信（発行）する。このトークンとは、クライアントサーバ２０を認証するものであり、ＵＭＡ等のデータ連携技術において公知であるため説明を省略する。

また、トークン発行部５４は、発行したトークンとコマンド情報とを関連付けて、例えば、記憶部１２のトークン情報６３に格納する。そして、トークン発行部５４は、このトークンを生成するために、例えば、ＵＭＡにおける公知のトークン生成手法を用いてもよい。なお、トークン情報６３については後述する。

また、トークン発行部５４は、クライアントの基本情報を、記憶部１２の基本情報６４から抽出する。

トークン検証部５５は、クライアントサーバ２０から送信されたトークンが、トークン発行部５４により生成されたトークンと同一であるかを検証する。その際、トークン検証部５５は、トークン情報６３を参照して当該検証を行なってもよい。

以下に、記憶部１２に格納される、同意情報６０、ユーザポリシー情報６１、チケット情報６２、トークン情報６３、基本情報６４、及び、ユーザ情報６５についてそれぞれ説明する。

同意情報６０は、ユーザとクライアント（データ利用者）との間における、当該ユーザのパーソナルデータの取り扱いに関する契約について、ユーザが当該契約に同意するか否かを管理するものである。本実施形態における同意情報６０は、ユーザが、クライアントに対して自身のパーソナルデータの開示に同意するか否かを格納するものとする。なお、同意情報６０に格納される情報については図８を用いて後述する。

ユーザポリシー情報６１は、ユーザがユーザ端末４０を用いて登録したアクセス制御ポリシー（後述）を管理するものである。本実施形態におけるユーザポリシー情報６１は、ユーザが自身のパーソナルデータのうち、クライアント（データ利用者）への開示を希望しない情報を格納するものとする。なお、ユーザポリシー情報６１に格納される情報については図９を用いて後述する。

チケット情報６２は、チケット発行部５２が生成してリソースサーバ３０に対して送信（発行）したチケットを管理するものである。このチケット情報６２では、チケット発行部５２によって生成され送信されたチケットに関する情報を、例えば、当該セッションの識別子（ＩＤ）やクライアントサーバ２０の情報と対応づけて管理してもよい。

トークン情報６３は、トークン発行部５４が生成してクライアントサーバ２０に対して送信（発行）したトークンを管理するものである。このトークン情報６３では、コマンド情報（後述）を、生成され送信されたトークンに関する情報や、リソースサーバ３０が管理するリソースＩＤ（後述）と対応づけて管理してもよい。なお、トークン情報６３の構成については図５を用いて後述する。なお、トークン情報６３に格納される情報については後述する。

ここで、図５を用いてトークン情報６３を説明する。

この図５は、本実施形態に係る情報処理システム１において、同意ポータルサーバ１０が備えるトークン情報６３を例示したものである。

この図５に例示するトークン情報６３は、“コマンド情報”、“リソースＩＤ”、及び“トークンＩＤ”の各フィールドを備える。

このトークン情報６３のフィールド“コマンド情報”は、コマンド情報解析部５１が取得したコマンド情報を格納するものであり、例えば、「M_all」を格納する。

トークン情報６３のフィールド“リソースＩＤ”は、フィールド“コマンド情報”によって特定されるユーザのＩＤ（識別子）を格納するものである。例えば、「M_all」のようにユーザ全員を対象にしたデータ取得要求の場合、対象となる全ユーザのＩＤを格納する。なお、リソースＩＤについては後述する。

トークン情報６３のフィールド“トークンＩＤ”は、トークンを一意に特定するための情報を格納するものである。このトークンＩＤに格納される値は、トークンを一意に特定するための識別子（例えば、「ｔｏｋｅｎ−１」）であってもよいし、トークン発行部５４が発行したトークン値であってもよい。

なお、フェーズ１（後述）はメタ情報の要求を処理する段階であるため、当該要求には対象ユーザに関する情報は含まれない。したがって、本実施形態において、フェーズ１では、トークン情報６３のフィールド“リソースＩＤ”には「ＮＵＬＬ」を格納する。

基本情報６４は、クライアントがリソースサーバ３０に対して取得を希望する情報（項目）を管理するものである。この基本情報６４は、リソースサーバ３０毎に取得を希望する情報を管理するものであってもよく、また、クライアントによって事前に設定されてもよい。なお、基本情報６４は、クライアントによって随時変更されてもよい。

ユーザ情報６５は、ユーザＩＤ（後述）とリソースＩＤ（後述）とをユーザ毎に対応付けて管理するものである。また、ユーザ情報６５は、当該リソースＩＤを管理するリソースサーバ３０との情報も含む。

〔１−５〕一実施形態に係る情報処理システムにおける制御処理の概要
上述の如く構成された実施形態の一例として、情報処理システム１でのパーソナルデータ取得を制御するための処理の概要を、図６を参照しながら、図７に示すシーケンスチャートに従って説明する。

図６は、本実施形態に係る情報処理システム１における制御処理の概要を例示する図である。図７は、図６に例示する情報処理システム１におけるパーソナルデータ取得の制御処理の概要を示すシーケンスチャートである。

この図６は、保険会社が自動車会社に対して、自動車会社の保有するパーソナルデータのうち、最新加入者に関するデータを要求し、当該要求に対して、自動車会社が保険会社にパーソナルデータを送信する場合を例示する。すなわち、図６における保険会社は、図１に示すデータ利用者に相当し、図６における保険会社のサーバ２００は、図１に示すクライアントサーバ２０に相当する。また、図６における自動車会社は図１に示すデータ提供者に相当し、図６における自動車会社のサーバ３００は図１に示すリソースサーバ３０に相当する。なお、図１と同様に、図６に例示する同意ポータルサーバ１０（AS）は、保険会社のサーバ２００と自動車会社のサーバ３００間でのデータ連携を仲介する。

上述の図６に例示するようなデータ連携を実現するために、本実施形態に係る情報処理システム１においては、図７に例示するような制御を行なう。

図７に例示するように、本情報処理システム１では、フェーズ１とフェーズ２との２段階に分けて制御を行なうものとする。

フェーズ１とは、保険会社のサーバ２００が、自動車会社のサーバ３００に対してメタ情報（後述）を要求し、当該要求に対して、自動車会社のサーバ３００が保険会社のサーバ２００に対して自動車会社のメタ情報を送信する段階である。

また、フェーズ２とは、フェーズ１に続いて行なう処理であり、保険会社のサーバ２００が自動車会社のサーバ３００に対して所望のパーソナルデータを要求する。そして、自動車会社のサーバ３００が、当該要求に対して、保険会社のサーバ２００に対して要求されたパーソナルデータを送信する段階である。なお、図６，図７では、保険会社のサーバ２００から自動車会社のサーバ３００に対して最新加入者のパーソナルデータを要求する処理を例示する。

また、図７のステップＡ１に示すように、フェーズ１の処理を行なう前に、ユーザは同意ポータルサーバ１０との契約に同意すると共に、アクセス制御ポリシーを登録しておくものとする。なお、このステップＡ１に示す処理は、ユーザ毎に行なうものとする。

この同意ポータルサーバ１０との契約とは、ユーザと、パーソナルデータの利用者である保険会社との間における、当該ユーザのパーソナルデータとの取り扱いに関する取り決めである。本実施形態において、同意ポータルサーバ１０との契約とは、ユーザのパーソナルデータを保険会社に対して開示する際の取り決めであり、当該契約への同意とは、ユーザが当該開示に同意するか否かを定めたものである。

このステップＡ１において、例えば、“ユーザＩＤ”が「User-１」であるユーザが、保険会社に対して自身のパーソナルデータの開示に同意した場合、同意ポータルサーバ１０のポリシー管理部５０は、その旨を記憶部１２の同意情報６０に格納する。

ここで、同意情報６０について図８を用いて説明する。

図８は、図６に示す実施形態の一例としての情報処理システム１における同意情報６０を例示する図である。本実施形態では、図８に例示するように、同意情報６０をテーブル形式で表現しているが、同意情報６０に格納される情報の表現形式はテーブルに限られるものではなく、種々変形して実施することができる。

この図８に例示する同意情報６０は、“ユーザＩＤ”、“利用目的”、“利用データ”、“データ利用者”、“データ提供者”、及び、“同意”の各フィールドを備える。この図８は、上述した契約において、データ提供者である自動者会社が保有する運転データを、保険料の算定のためにデータ利用者である保険会社へ提供する例について示す。なお、ユーザがデータ利用者である保険会社と契約する際、データ提供者である自動者会社が保有する運転データを保険会社へ提供することで保険料を算定するための同意としてもよい。

この同意情報６０のフィールド“ユーザＩＤ”は、ユーザを一意に特定するための識別子（ＩＤ）を格納するものであり、例えば、「User-１」を格納する。本実施形態において、この識別子は、例えば、同意ポータルサーバ１０によって発行されるものとする。

同意情報６０のフィールド“利用目的”は、ユーザのパーソナルデータがデータ利用者によって利用される目的を格納するものであり、例えば、「保険料算定のため」を格納する。

同意情報６０のフィールド“利用データ”は、ユーザのパーソナルデータのうちデータ利用者によって利用されるデータの種別（内容）を格納するものであり、例えば、「運転データ」を格納する。

同意情報６０のフィールド“データ利用者”は、フィールド“ユーザＩＤ”によって特定されるユーザにとって同意の対象となるデータ利用者（クライアント）を示す情報を格納するものであり、例えば、「保険会社」を格納する。このフィールド“データ利用者”に格納される値は、データ利用者（クライアント）の名称を格納してもよいし、データ利用者（クライアント）を一意に特定する識別子を格納してもよい。

同意情報６０のフィールド“データ提供者”は、フィールド“ユーザＩＤ”によって特定されるユーザに関するパーソナルデータを保有しているデータ提供者を示す情報を格納するものであり、例えば、「自動車会社」を格納する。このフィールド“データ提供者”に格納される値は、データ提供者の名称を格納してもよいし、データ提供者を一意に特定する識別子を格納してもよい。

同意情報６０のフィールド“同意”は、フィールド“ユーザＩＤ”によって特定されるユーザが、フィールド“データ利用者”によって特定されるデータ利用者（クライアント）に対して、同意したか否かに関する情報を格納するものである。本実施形態において、ユーザがデータ利用者（クライアント）に対して既に同意している場合、フィールド“同意”には、「同意済み」を格納するものとする。

例えば、図７に示すステップＡ１において、“ユーザＩＤ”が「User-１」であるユーザが、保険会社に対して自身のパーソナルデータの開示に同意した場合について説明する。この場合、同意ポータルサーバ１０のポリシー管理部５０は、同意情報６０において、“ユーザＩＤ”が「User-１」の“同意”のフィールドに、例えば、「同意済み」を格納する（図８参照）。

また、図７に示すステップＡ１において、ユーザは、上述した契約への同意と共にアクセス制御ポリシーを登録する。

本実施形態において、アクセス制御ポリシーとは、パーソナルデータに対するアクセス制限を規定する情報である。例えば、ユーザが自身のパーソナルデータのうち、クライアントサーバ（データ利用者のサーバ）２０への開示を希望しない情報がある場合に、その情報を登録するものである。本実施形態において、ユーザが自身のパーソナルデータのうち、保険会社への開示を希望しない情報をアクセス制御ポリシーに登録してもよい。

ここで、ユーザポリシー情報６１について図９を用いて説明する。

図９は、図６に示す実施形態の一例としての情報処理システム１におけるユーザポリシー情報６１を例示する図である。本実施形態では、図９に例示するように、ユーザポリシー情報６１をテーブル形式で表現しているが、ユーザポリシー情報６１に格納される情報の表現形式はテーブルに限られるものではなく、種々変形して実施することができる。

この図９に例示するユーザポリシー情報６１は、“ユーザＩＤ”、及び“ポリシー”の各フィールドを備える。

このユーザポリシー情報６１のフィールド“ユーザＩＤ”は、ユーザを一意に特定するための識別子（ＩＤ）を格納するものであり、例えば、「００１」を格納する。このフィールド“ユーザＩＤ”に格納する値は、上述の同意情報６０（図８参照）のフィールド“ユーザＩＤ”に格納する値に対応するものとする。

ユーザポリシー情報６１のフィールド“ポリシー”は、フィールド“ユーザＩＤ”によって特定されるユーザが、自身のパーソナルデータのうち、クライアントサーバ２０への開示を希望しない情報を登録するものである。本実施形態において、ユーザがクライアントサーバ２０への開示を希望しない情報がある場合、フィールド“ポリシー”には当該情報を格納するものとする。一方、ユーザがクライアントサーバ２０への開示を希望しない情報がない場合、フィールド“ポリシー”には、「なし」を格納するものとする。

例えば、図７に示すステップＡ１において、“ユーザＩＤ”が「User-ｘ」であるユーザが、保険会社に対して自身のパーソナルデータのうち、購買記録について開示を希望しない場合について説明する。この場合、同意ポータルサーバ１０のポリシー管理部５０は、ユーザポリシー情報６１において、“ユーザＩＤ”が「User-ｘ」の“ポリシー”のフィールドに、例えば、「購買記録」を格納する（図９参照）。

このように図７に示すステップＡ１において、ユーザがアクセス制御ポリシーに同意した場合には、同意ポータルサーバ１０は、図９に例示するユーザポリシー情報６１に基づき、図７に示すフェーズ１，フェーズ２の制御を行なう。

一方、図７に示すステップＡ１において、ユーザがアクセス制御ポリシーに同意しなかった場合には、図７に示すフェーズ１，フェーズ２の制御を行なわずに、ポリシー管理部５０は処理を完了してもよい。

〔１−６〕一実施形態に係る情報処理システムにおけるフェーズ１の制御処理
実施形態の一例として、情報処理システム１におけるフェーズ１の制御処理について、図１０に示すシーケンスチャート（Ｓ１〜Ｓ１６）に従って説明する。

図１０は、上述の図７に示したフェーズ１の制御処理を説明するためのシーケンスチャートである。この図１０を用いて、保険会社のサーバ２００が自動車会社のサーバ３００に対してメタ情報（後述）を要求し、自動車会社のサーバ３００から当該メタ情報を取得する処理について説明する。

ここでまず、本実施形態に係るメタ情報について説明する。本実施形態において、メタ情報とは、リソースサーバ３０が備える自身のフィルタ情報やデータ形式である。このメタ情報はリソースサーバ３０毎に異なる場合がある。以下、メタ情報に含まれる、フィルタ情報とデータ形式とのそれぞれについて説明する。

図１１は、本実施形態に係る情報処理システム１において、リソースサーバ３０として機能する自動車会社のサーバ３００が備えるフィルタ情報を例示したものである。

この図１１に例示するフィルタ情報は、“フィルタ”、及び“属性”の各フィールドを備える。

このフィルタ情報のフィールド“フィルタ”は、一例として、「対象サービス情報」、「基本情報」、及び、「データ構成」を格納する。これは、自動車会社のサーバ３００（リソースサーバ３０）が備えるパーソナルデータが、対象サービス情報、基本情報、及び、運転情報毎に分類されていることを意味している。すなわち、保険会社のサーバ２００は、自動車会社のサーバ３００の保有するパーソナルデータのうち、対象サービス情報、基本情報、及び、運転情報のうち少なくとも何れかを抽出（フィルタ）してパーソナルデータを取得可能である。

フィルタ情報のフィールド“属性”は、フィールド“フィルタ”により特定される属性を格納するものである。

図１１は、フィルタ「対象サービス情報」により特定される属性として、「Ｍ」や「ＳＣ」があることを例示している。この属性「Ｍ」はメンバを表し、保険会社のサーバ２００が、例えば、「Ｍ：会員」や「Ｍ：加入者全員」のように指定することができるものとする。これにより、保険会社のサーバ２００は、自動車会社のサーバ３００の保有するパーソナルデータのうち、会員のパーソナルデータや加入者全員のパーソナルデータを取得することが可能となる。この属性「Ｍ」（メンバ）についてはフェーズ２の説明において後述する。

また、図１１に例示する属性「ＳＣ」はサービスクラスを表す。属性「ＳＣ」は、上述した属性「Ｍ」と同様に、その属性値を設定することにより、保険会社のサーバ２００は、所望のサービスクラスに属するパーソナルデータを取得することが可能となる。

また、図１１は、フィルタ「基本情報」により特定される属性として、「年代」、「エリア」、及び、「性別」があることを例示している。例えば、保険会社のサーバ２００は、例えば、「年代：３０」と指定することにより、３０代の会員のパーソナルデータを自動車会社のサーバ３００から取得できる。このフィルタ「基本情報」についてはフェーズ２の説明において後述する。

また、図１１は、フィルタ「データ構成」により特定される属性として、「走行距離」や「位置情報」等があることを例示している。

また、上述のフィルタ情報と併せてメタ情報に含まれるデータ形式としては、例えば、データの項目や転送形式（例えば、ＪＳＯＮ（JavaScript Object Notation））がある。

次に、図１０に示すシーケンスチャートを用いて、上述のようなメタ情報を取得するフェーズ１の処理について説明する。

ステップＳ１において、保険会社のサーバ２００が自動車会社のサーバ３００に対してメタ情報を要求する。その際、本実施形態では、図１０に例示するように、例えば、ＨＴＴＰ（Hypertext Transfer Protocol）１．１に基づく通信プロトコルを用いる場合、要求メッセージとして、ＧＥＴコマンド（“GET /users/operation/meta_info”）を用いるものとする。このようなＧＥＴコマンドの場合、当該コマンドの末尾の文字列「meta_info」をコマンド情報、または、抽出用情報という。また、保険会社のサーバ２００は、ＧＥＴコマンドの引数やパラメータに「meta_info」を指定して（例えば、“GET /users/operation?meta_info”）、メタ情報を要求してもよい。

本実施形態では、ＧＥＴコマンドのコマンド情報に、フェーズ１では「meta_info」と設定し、後述するフェーズ２では「M_all」と設定することで、コマンド情報に設定した値は、現在いずれのフェーズを実行しているかを示すフラグとして機能する。

続くステップＳ２において、自動車会社のサーバ３００は同意ポータルサーバ１０に対し、上記ステップＳ１にて取得したコマンド情報を送信する（載せ替える）。その際、本実施形態では、自動車会社のサーバ３００は、ＰＯＳＴコマンドを用いてコマンド情報を送信する。

続くステップＳ３において、同意ポータルサーバ１０のコマンド情報解析部５１は、取得したコマンド情報をトークン情報６３に保持（格納）する。

また、コマンド情報解析部５１は取得したコマンド情報を解析する。上述したように、コマンド情報解析部５１は、コマンド情報を解析した結果、取得したコマンド情報が「meta_info」であれば、現在の処理がフェーズ１におけるものであると判断し、図１０（フェーズ１）に示すステップＳ４以降の処理を継続する。

一方、コマンド情報解析部５１は、取得したコマンド情報を保持して解析した結果、取得したコマンドが「meta_info」以外（例えば「M_all」）であれば、現在の処理がフェーズ２におけるものであると判断し、後続するフェーズ２の処理を継続する。

これは、フェーズ１のステップＳ１，Ｓ２に示す処理と、後述するフェーズ２のステップＴ１，Ｔ２に示す処理とがコマンド情報以外は類似しているため、コマンド情報に基づき現在の処理がいずれのものであるかを判断するためである。

このステップＳ３において、同意ポータルサーバ１０のコマンド情報解析部５１は、取得したコマンド情報をトークン情報６３に格納するが、その際、取得したコマンド情報をフィールド“コマンド情報”に格納するものとする。

ステップＳ４において、同意ポータルサーバ１０のチケット発行部５２は、チケットを生成（発行）する。なお、チケット発行部５２は、上述したとおり、このチケットを生成するために、例えば、ＵＭＡにおける公知のチケット生成手法を用いてもよい。

続くステップＳ５において、同意ポータルサーバ１０のチケット発行部５２は、生成したチケットを自動車会社のサーバ３００に対して送信する。

そして、チケット発行部５２は、例えば、この送信したチケットに関する情報を記憶部１２のチケット情報６２に格納する。その際、チケット発行部５２は、この送信したチケットに関する情報を、例えば、当該セッションの識別子（ＩＤ）やクライアントサーバ２０の情報に対応させてチケット情報６２に格納してもよい。

続くステップＳ６において、自動車会社のサーバ３００は、上記ステップＳ５において受信したチケットを、同意ポータルサーバ１０のＵＲＩ（Uniform Resource Identifier）と併せて保険会社のサーバ２００に送信する。

続くステップＳ７において、保険会社のサーバ２００は、上記ステップＳ６にて受信したチケットを、同意ポータルサーバ１０に送信する。ここでは、チケットの送付先として、上記ステップＳ６にて送信された同意ポータルサーバ１０のＵＲＩを指定してもよい。

続くステップＳ８において、同意ポータルサーバ１０のチケット検証部５３は、保険会社のサーバ２００から送信されたチケットが、上述のステップＳ４で生成したチケットと同一のものであるかを検証する。その際、チケット検証部５３は、チケット情報６２を参照して当該検証を行なってもよい。

このステップＳ８において、チケット検証部５３は、上述のステップＳ４，Ｓ５にてチケット発行部５２が生成し自動車会社のサーバ３００に送信したトークンと、上述のステップＳ７で保険会社のサーバ２００が送信したチケットとが一致するか否かを検証する。なお、この検証においてチケットが一致しないと判定した場合には、チケット検証部５３は処理を完了してもよい。

また、同意ポータルサーバ１０のトークン発行部５４は、保険会社の基本情報と対象サービス情報とを、記憶部１２の基本情報６４から抽出する。

上述したように、保険会社の基本情報と対象サービス情報とは、データ利用者としての保険会社が、データ提供者である自動車会社からの取得を希望する情報であり、要求データ項目ともいう。ここでは、保険会社の基本情報は、例えば、年代、エリア、及び、性別とし、対象サービス情報とは、保険会社が、自動車会社からの取得を希望する情報である。また、保険会社の対象サービス情報は、会員、及び、サービスクラスとする。

続くステップＳ９において、トークン発行部５４はトークンを生成する。なお、トークン発行部５４は、上述の如く、このトークンを生成するために、例えば、ＵＭＡにおける公知のトークン生成手法を用いてもよい。

そして、トークン発行部５４は、この生成したトークンと、上述のステップＳ３にて保持，解析したコマンド情報とを関連付けて、例えば、記憶部１２のトークン情報６３に格納する。

続くステップＳ１０において、同意ポータルサーバ１０のトークン発行部５４は、上述のステップＳ９において生成したトークンを、保険会社のサーバ２００に対して送信する。

続くステップＳ１１において、保険会社のサーバ２００は、上述のステップＳ１０において送信されたトークンを、自動車会社のサーバ３００に対して送信する。

続くステップＳ１２において、自動車会社のサーバ３００は、上述のステップＳ１１において送信されたトークンを検証すべく、同意ポータルサーバ１０に対して送信する。

続くステップＳ１３において、同意ポータルサーバ１０のトークン検証部５５は、上述のステップＳ１２において送信されたトークン、すなわち、保険会社のサーバ２００から自動車会社のサーバ３００に対して送信されたトークンの妥当性を検証する。その際、トークン検証部５５は、トークン情報６３を参照して当該検証を行なってもよい。

このステップＳ１３において、トークン検証部５５は、例えば、上述のステップＳ９にて生成し保険会社のサーバ２００に送信したトークンと、上述のステップＳ１２で自動車会社のサーバ３００から送信されたトークンとが一致するか否かを検証する。

続くステップＳ１４において、トークン検証部５５は、上述のステップＳ１３において検証した結果を自動車会社のサーバ３００に対して送信する。トークン検証部５５は、上述のステップＳ１３において当該検証を行なった結果、一致すると判定した場合には、検証結果として、例えば、「ＯＫ」を自動車会社のサーバ３００に対して送信してもよい。

また、ステップＳ１４において、トークン検証部５５は、検証結果と併せて、上述のステップＳ８において抽出した保険会社の基本情報と対象サービス情報とを送信する。

このステップＳ１４において、自動車会社のサーバ３００が、トークンが一致するとの検証結果を受信した場合、ステップＳ１２で同意ポータルサーバ１０が自動車会社のサーバ３００を介して正当なクライアント（保険会社）からトークンを受け取ったことになる。したがって、このステップＳ１４においてトークンが一致するとの検証結果を受信した場合、後続のステップＳ１５以降の処理を実行する。すなわち、自動車会社のサーバ３００から保険会社のサーバ２００に対してメタ情報が送信されることになる。

一方、ステップＳ１４において、自動車会社のサーバ３００が、トークンが一致しないとの検証結果を受信した場合には、処理を終了してもよい。

ステップＳ１５において、自動車会社のサーバ３００は保険会社へのサーバ２００への応答メッセージとしてメタ情報を送信する。

図１２は、本実施形態に係る情報処理システム１における応答メッセージを例示したものである。

この図１２に例示するように、応答メッセージにはフィルタ情報とデータ形式とが含まれる。

このステップＳ１５において、自動車会社のサーバ３００は、メタ情報に、上述のステップＳ１４で送信された保険会社の基本情報と対象サービス情報とに応じた情報を含めて、例えば、図１２に示す応答メッセージを保険会社へのサーバ２００へ送信してもよい。または、保険会社の基本情報と対象サービス情報とは、予め自動車会社のサーバ３００の供える図示しない記憶装置等に保存しておいてもよい。

上述したように、この保険会社の基本情報と対象サービス情報とは、データ利用者としての保険会社が、データ提供者である自動車会社からの取得を希望する情報である。この保険会社の基本情報と対象サービス情報とを、上述のステップＳ１４にて自動車会社のサーバ３００が受信することにより、自動車会社のサーバ３００は、保険会社が所望する情報に応じたメタ情報を保険会社に送信することが可能となる。

続くステップＳ１６において、保険会社のサーバ２００は自動車会社のサーバ３００からメタ情報を取得する。

図１３は、本実施形態に係る情報処理システム１において、クライアントサーバ２０として機能する保険会社のサーバ２００が管理するフィルタ情報を例示したものである。

保険会社のサーバ２００は、このステップＳ１６において取得したメタ情報を用いて、図１３に例示するような、自身の管理するフィルタ情報を更新してもよい。

このように図１０に示すフェーズ１（ステップＳ１〜Ｓ１６）の処理を経て、データ利用者である保険会社のサーバ２００は、データ提供者である自動車会社のサーバ３００から、当該自動車会社のサーバ３００のメタ情報を取得する。このフェーズ１の処理については、後述するフェーズ２に示すパーソナルデータの取得処理が実行される度に実行しなくてもよく、例えば、定期的に（例えば、１日につき１回）実行してもよい。

〔１−７〕一実施形態に係る情報処理システムにおけるフェーズ２の制御処理
実施形態の一例として、情報処理システム１におけるフェーズ２の制御処理について、図１４に示すシーケンスチャート（Ｔ１〜Ｔ１６）に従って説明する。

図１４は、上述の図７に示したフェーズ２の制御処理を説明するためのシーケンスチャートである。この図１４を用いて、保険会社のサーバ２００が自動車会社のサーバ３００に対し所望のユーザに関するパーソナルデータを要求し、自動車会社のサーバ３００から当該パーソナルデータを取得する処理について説明する。

ステップＴ１において、保険会社のサーバ２００が自動車会社のサーバ３００に対してパーソナルデータを要求する。ここでは、保険会社のサーバ２００が、対象ユーザをユーザ全員とし、ユーザ全員分のパーソナルデータを要求する場面を例にとる。本実施形態では、図１４に例示するように、例えば、ＨＴＴＰ（Hypertext Transfer Protocol）１．１に基づく通信プロトコルを用いる場合、ＧＥＴコマンド（“GET /users/operation/M_all”）を用いるものとする。また、保険会社のサーバ２００は、ＧＥＴコマンドの引数やパラメータに「M_all」を指定して（例えば、“GET /users/operation?M_all”）、パーソナルデータを要求してもよい。

このように、ＧＥＴコマンドのコマンド情報を、このフェーズ２では「M_all」と設定する。

続くステップＴ２において、自動車会社のサーバ３００は、保険会社のサーバ２００から受信したＧＥＴコマンドからコマンド情報「M_all」を取得する。

そして、自動車会社のサーバ３００は、同意ポータルサーバ１０に対し、上記ステップＴ１にて取得したコマンド情報を送信する（載せ替える）。その際、本実施形態では、自動車会社のサーバ３００はＰＯＳＴコマンドを用いてコマンド情報を送信する。

続くステップＴ３において、同意ポータルサーバ１０のコマンド情報解析部５１は、取得したコマンド情報をトークン情報６３フィールド“コマンド情報”に格納する。

また、コマンド情報解析部５１は取得したコマンド情報を解析する。そして、上述したように、コマンド情報解析部５１は、コマンド情報を解析した結果、取得したコマンド情報が「M_all」であることから、現在の処理がフェーズ２におけるものであると判断し、後続のフェーズ２の処理（ステップＴ４以降）を継続する。

続くステップＴ４において、同意ポータルサーバ１０のチケット発行部５２は、チケットを生成（発行）する。

続くステップＴ５において、同意ポータルサーバ１０のチケット発行部５２は、生成したチケットを自動車会社のサーバ３００に対して送信する。

そして、チケット発行部５２は、例えば、この送信したチケットに関する情報を記憶部１２のチケット情報６２に格納する。

続くステップＴ６において、自動車会社のサーバ３００は、上記ステップＴ５において受信したチケットを、同意ポータルサーバ１０のＵＲＩと併せて保険会社のサーバ２００に送信する。

続くステップＴ７において、保険会社のサーバ２００は、上記ステップＴ６にて受信したチケットを、同意ポータルサーバ１０に送信する。ここでは、チケットの送付先として、上記ステップＴ６にて送信された同意ポータルサーバ１０のＵＲＩを指定してもよい。

続くステップＴ８において、同意ポータルサーバ１０のチケット検証部５３は、保険会社のサーバ２００から送信されたチケットが、上述のステップＴ４で生成したチケットと同一のものであるかを検証する。

このステップＴ８において、同意ポータルサーバ１０のポリシー管理部５０は、記憶部１２のユーザポリシー情報６１を参照し、パーソナルデータの取得対象となるユーザ（対象ユーザ）が同意済みであるか否かをユーザ毎に確認する。このパーソナルデータの対象ユーザは、上述したステップＴ３にて取得したコマンド情報から判断することができる。

そして、ポリシー管理部５０は、同意済みであると確認した各ユーザについて、ユーザ情報６５を参照して、リソースＩＤを取得（抽出）する。このリソースＩＤとは、ユーザを一意に特定するための識別子（ＩＤ）であり、リソースサーバ３０によってユーザ毎に発行され管理されるものである。一方、上述したように、ユーザＩＤは同意ポータルサーバ１０によって発行されるので、各ユーザに付与されるユーザＩＤとリソースＩＤとは異なる場合がある。そこで、このユーザ情報６５では、ユーザＩＤとリソースＩＤとをユーザ毎に対応付けて管理する。

ここで、ユーザ情報６５について図１５を用いて説明する。

図１５は、図６に示す実施形態の一例としての情報処理システム１におけるユーザ情報６５を例示する図である。本実施形態では、図１５に例示するように、ユーザ情報６５をテーブル形式で表現しているが、ユーザ情報６５に格納される情報の表現形式はテーブルに限られるものではなく、種々変形して実施することができる。

この図１５に例示するユーザ情報６５は、“ユーザＩＤ”、“データ提供者”、及び“リソースＩＤ”の各フィールドを備える。

このユーザ情報６５のフィールド“ユーザＩＤ”は、ユーザを一意に特定するための識別子（ＩＤ）を格納するものであり、例えば、「User-１」を格納する。本実施形態において、この識別子は、例えば、同意ポータルサーバ１０によって発行されるものとする。

ユーザ情報６５のフィールド“データ提供者”は、フィールド“ユーザＩＤ”によって特定されるユーザに関するパーソナルデータを保有しているデータ提供者を示す情報を格納するものであり、例えば、「自動車会社」を格納する。このフィールド“データ提供者”に格納される値は、データ提供者の名称を格納してもよいし、データ提供者を一意に特定する識別子を格納してもよい。

ユーザ情報６５のフィールド“リソースＩＤ”は、フィールド“データ提供者”によって特定されるリソースサーバ３０が、フィールド“ユーザＩＤ”によって特定されるユーザに対して付与した識別子（ＩＤ）を格納するものである。このフィールド“リソースＩＤ”には、例えば、「r1452642」が格納される。

このように、ユーザ情報６５は、リソースサーバ３０によって管理されるリソースＩＤを含む。したがって、本実施形態においては、当該フェーズ２の処理を開始する前に、同意ポータルサーバ１０が備えるトークン情報６３と、リソースサーバ３０によって管理されるリソースＩＤとを同期させるものとするが、同期のタイミングはこれに限られない。

図１４に示すシーケンスチャートの説明に戻り、ステップＴ８において、ポリシー管理部５０が、ユーザ情報６５を参照して各ユーザのリソースＩＤを取得（抽出）すると、この取得したリソースＩＤをトークン情報６３に格納する。その際、該当するユーザが複数である場合には、これらのユーザのリソースＩＤを、例えば、“，”で連結してトークン情報６３に格納してもよい（図５参照）。

また、ステップＴ８において、同意ポータルサーバ１０のポリシー管理部５０は、図９に示すユーザポリシー情報６１を参照してアクセス制御を行なう。例えば、ポリシー管理部５０は、対象ユーザのうち、開示を希望しないユーザがいるかどうかを確認する等してアクセス制御を行なってもよい。

続くステップＴ９において、同意ポータルサーバ１０のトークン発行部５４はトークンを生成する。このトークンの有効期間は、安全性を考慮して、１ユーザデータを取得する場合よりも短く設定する。また、例えば、このトークンを１回の利用として制限するなどトークンの利用回数を制限してもよく、その利用回数はサービスや利用するデータに応じて変更してもよい。

そして、トークン発行部５４は、この生成したトークンと、上述のステップＴ３にて保持，解析したコマンド情報とを関連付けて、例えば、記憶部１２のトークン情報６３に格納する。

続くステップＴ１０において、トークン発行部５４は、上述のステップＴ９において生成したトークンを、保険会社のサーバ２００に対して送信（発行）する。

続くステップＴ１１において、保険会社のサーバ２００は、上述のステップＴ１０において送信されたトークンを、自動車会社のサーバ３００に対して送信する。

続くステップＴ１２において、自動車会社のサーバ３００は、上述のステップＴ１１において送信されたトークンを検証すべく、同意ポータルサーバ１０に対して送信する。

続くステップＴ１３において、同意ポータルサーバ１０のトークン検証部５５は、上述のステップＴ１２において送信されたトークン、すなわち、保険会社のサーバ２００から自動車会社のサーバ３００に対して送信されたトークンの妥当性を検証する。

続くステップＴ１４において、トークン検証部５５は、上述のステップＴ１３において検証した結果を自動車会社のサーバ３００に対して送信する。

また、このステップＴ１４において、トークン検証部５５は、検証結果と併せて、上述のステップＴ８において抽出した対象ユーザのリソースＩＤ（のリスト）を送信する。

このステップＴ１４で、自動車会社のサーバ３００が、トークンが一致するとの検証結果を受信した場合には、ステップＴ１２にて同意ポータルサーバ１０が自動車会社のサーバ３００を介し正当なクライアント（保険会社）からトークンを受け取ったことになる。したがって、このステップＴ１４においてトークンが一致するとの検証結果を受信した場合、後続のステップＴ１５以降の処理を実行する。すなわち、自動車会社のサーバ３００から保険会社のサーバ２００に対して対象ユーザのパーソナルデータが送信されることになる。

続くステップＴ１５において、自動車会社のサーバ３００は、対象ユーザのパーソナルデータを保険会社のサーバ２００に送信する。

続くステップＴ１６において、保険会社のサーバ２００は自動車会社のサーバ３００から対象ユーザのパーソナルデータを取得する。

このようにして、フェーズ２では、複数ユーザのパーソナルデータを一度にクライアントへ提供することができる。

〔１−８〕一実施形態に係る情報処理システムにおけるフェーズ１の制御処理（フローチャート）
実施形態の一例として、情報処理システム１におけるフェーズ１の制御処理について、図１６に示すフローチャート（ステップＱ１〜Ｑ２，Ｑ１０〜Ｑ１２，Ｑ２０〜Ｑ２３，Ｑ３０〜Ｑ３２，Ｑ４０〜Ｑ４２）に従って説明する。

この図１６は、上述の図１０に示したフェーズ１の制御処理（シーケンスチャート）を説明するためのフローチャートである。この図１６を用いて、保険会社のサーバ２００が自動車会社のサーバ３００に対してメタ情報を要求し、自動車会社のサーバ３００から当該メタ情報を取得する処理について説明する。

ステップＱ１において、同意ポータルサーバ１０は、ユーザ端末４０、保険会社のサーバ２００、または、自動車会社のサーバ３００から要求メッセージを受信する。

続くステップＱ２において、上述したステップＱ１にて取得した要求メッセージが、ユーザ端末４０から送信された契約や同意に基づくものである場合、処理がステップＱ１０に移行する（ステップＱ２における“メッセージ１”ルート参照）。

ステップＱ１０において、同意ポータルサーバ１０のポリシー管理部５０は、上述したステップＱ１で受信した要求メッセージの送信元であるユーザとの間で契約処理を行なう。例えば、ポリシー管理部５０は、当該ユーザのユーザ端末４０に対し契約書を提示（表示）する処理を行なう。

続くステップＱ１１において、ポリシー管理部５０は、上述したステップＱ１０にて提示した契約書に対してユーザ端末４０から同意する旨の返答を受信すると、当該返答に基づいて同意処理を行なう。本実施形態において、ポリシー管理部５０は、同意情報６０に当該ユーザが「同意済み」であることを示す情報を格納する。

続くステップＱ１２において、ポリシー管理部５０は、述したステップＱ１１にて同意したユーザについて、当該ユーザのパーソナルデータに対するアクセス制限に関する情報をユーザポリシー情報６１に設定する。例えば、本実施形態において、当該ユーザが自身のパーソナルデータのうち、クライアントサーバ（データ利用者のサーバ）２０への開示を希望しない情報がある場合、同意ポリシー管理部５０は、ユーザポリシー情報６１にその情報を登録する。そして、ポリシー管理部５０は、この契約、及び、同意処理を終了する。

一方、ステップＱ２において、上述したステップＱ１にて取得した要求メッセージが、自動車会社のサーバ３００から送信されたコマンド情報である場合、処理がステップＱ２０に移行する（ステップＱ２における“メッセージ２”ルート参照）。

ステップＱ２０において、同意ポータルサーバ１０が上述したステップＱ２で受信したコマンド情報が、多数ユーザのパーソナルデータを要求することを示すものである場合、処理がＱ２１に移行する（ステップＱ２０におけるＮＯルート参照）。

一方、ステップＱ２０で、同意ポータルサーバ１０が上述したステップＱ２にて受信したコマンド情報が、１ユーザ（ユーザ１人分）のパーソナルデータを要求することを示すものである場合、処理がＱ２３に移行する（ステップＱ２０におけるＹＥＳルート参照）。

ステップＱ２１において、同意ポータルサーバ１０のコマンド情報解析部５１は、上述したステップＱ１にて取得したコマンド情報（要求メッセージ）を保持する。

続くステップＱ２２において、同意ポータルサーバ１０のチケット発行部５２は、チケットを生成（発行）する。そして、チケット発行部５２は、生成したチケットを自動車会社のサーバ３００に対して送信する。そして、チケット発行部５２は処理を終了する。

また、ステップＱ２３では、同意ポータルサーバ１０が、例えば、公知のＵＭＡ方式を用いてユーザリソース情報を取得して保持するものとする。そして、処理がステップＱ２２に移行する。

一方、ステップＱ２において、上述したステップＱ１にて取得した要求メッセージが、保険会社のサーバ２００から送信されたチケットである場合、処理がステップＱ３０に移行する（ステップＱ２における“メッセージ３”ルート参照）。

ステップＱ３０において、同意ポータルサーバ１０のチケット検証部５３は、上述したステップＱ１にて取得したチケット（要求メッセージ）が、上述したステップＱ２２にてチケット発行部５２により発行され送信されたチケットと同一のものであるかを検証する。

このステップＱ３０において、チケット検証部５３は、チケットが同一のものである（正当なチケットである）と判断した場合、処理がステップＱ３１に進む。

続くステップＱ３１において、同意ポータルサーバ１０のトークン発行部５４は、保険会社の基本情報と対象サービス情報とを、例えば、記憶部１２の基本情報６４から抽出する。そして、処理がステップＱ３２に進む。

続くステップＱ３２において、トークン発行部５４はトークンを生成する。そして、トークン発行部５４は、この生成したトークンを、保険会社のサーバ２００に対して送信する。そして、チケット検証部５３は処理を終了する。

一方、ステップＱ２において、上述したステップＱ１にて取得した要求メッセージが、保険会社のサーバ２００から送信されたトークンである場合、処理がステップＱ４０に移行する（ステップＱ２における“メッセージ４”ルート参照）。

ステップＱ４０において、同意ポータルサーバ１０のトークン検証部５５は、上述したステップＱ１にて取得したトークン（要求メッセージ）が、上述したステップＱ３２にてトークン発行部５４により生成され送信されたトークンと同一のものであるかを検証する。

このステップＱ４０において、トークン検証部５５は、トークンが同一のものである、すなわち、当該トークンが正当であると判断した場合、処理がステップＳ４１に移行する（ステップＱ４０における“正当である”ルート参照）。

一方、ステップＱ４０において、トークン検証部５５は、同一のものではない、すなわち、当該トークンが正当ではないと判断した場合、処理がステップＳ４２に移行する（ステップＱ４０における“正当ではない”ルート参照）。

ステップＱ４１において、トークン検証部５５は、上述のステップＱ４０における検証結果と、上述のステップＱ３１で抽出した保険会社の基本情報と対象サービス情報とを自動車会社のサーバ３００に送信する。そして、トークン検証部５５は処理を終了する。

また、ステップＱ４２において、トークン検証部５５は、上述のステップＱ４０における検証結果としてエラーを自動車会社のサーバ３００に送信する。そして、トークン検証部５５は処理を終了する。

〔１−９〕一実施形態に係る情報処理システムにおけるフェーズ２の制御処理（フローチャート）
実施形態の一例として、情報処理システム１におけるフェーズ２の制御処理について、図１７に示すフローチャート（ステップＲ１〜Ｒ２，Ｒ１０〜Ｒ１２，Ｒ２０〜Ｒ２３，Ｒ３０〜Ｒ３５，Ｒ４０〜Ｒ４２）に従って説明する。

図１７は、上述の図１４に示したフェーズ２の制御処理（シーケンスチャート）を説明するためのフローチャートである。この図１７を用いて、保険会社のサーバ２００が自動車会社のサーバ３００に対し所望のユーザに関するパーソナルデータを要求し、自動車会社のサーバ３００から当該パーソナルデータを取得する処理について説明する。

ステップＲ１において、同意ポータルサーバ１０は、ユーザ端末４０、保険会社のサーバ２００、または、自動車会社のサーバ３００から要求メッセージを受信する。

続くステップＲ２において、上述したステップＲ１にて取得した要求メッセージが、ユーザから送信された契約や同意に基づくものである場合、ステップＲ１０に移行する（ステップＲ２における“メッセージ１”ルート参照）。そして、同意ポータルサーバ１０では、ステップＲ１０〜Ｒ１２に示す処理を実行するが、これらの各処理については図１６（ステップＱ１０〜Ｑ１２）を用いて上述したので、ここでは説明を省略する。

一方、ステップＲ２において、上述したステップＲ１にて取得した要求メッセージが、自動車会社のサーバ３００から送信されたコマンド情報である場合、処理がステップＲ２０に移行する（ステップＲ２における“メッセージ２”ルート参照）。そして、同意ポータルサーバ１０では、ステップＲ２０〜Ｒ２３に示す処理を実行するが、これらの各処理については図１６（ステップＱ２０〜Ｑ２３）を用いて上述したので、ここでは説明を省略する。

一方、ステップＲ２において、上述したステップＲ１にて取得した要求メッセージが、保険会社のサーバ２００から送信されたチケットである場合、処理がステップＲ３０に移行する（ステップＲ２における“メッセージ５”ルート参照）。

ステップＲ３０において、同意ポータルサーバ１０のチケット検証部５３は、上述したステップＲ１にて取得したチケット（要求メッセージ）が、上述したステップＲ２２にてチケット発行部５２により生成され送信されたチケットと同一のものであるかを検証する。

このステップＲ３０において、チケット検証部５３は、チケットが同一のものである（正当なチケットである）と判断した場合、処理がステップＲ３１に進む。

続くステップＲ３１において、同意ポータルサーバ１０のポリシー管理部５０は、記憶部１２の同意情報６０を参照し、パーソナルデータの取得対象となるユーザ（対象ユーザ）が同意済みであるか否かを対象ユーザ毎に確認する。

このステップＲ３１において、ポリシー管理部５０は、対象ユーザ（全員）が同意済みであることを確認した場合、処理がステップＲ３２に移行する（ステップＲ３１における同意済みルート参照）。

一方、ステップＲ３１において、ポリシー管理部５０は、対象ユーザのうち同意済みではないユーザを確認した場合、処理がステップＲ３５に移行する（ステップＲ３１における同意未ルート参照）。

ステップＲ３２において、ポリシー管理部５０は、記憶部１２のユーザポリシー情報６１を参照して、各ユーザのリソースＩＤを取得（抽出）してアクセス制御を行なう。例えば、ポリシー管理部５０は、ユーザポリシー情報６１に基づき、ユーザが開示を希望しないパーソナルデータがあるかどうかを確認する等してアクセス制御を行なってもよい。そして、処理がステップＲ３３に移行する。

また、ステップＲ３５において、ポリシー管理部５０は、対象ユーザのうち同意済みではないユーザを対象ユーザから削除するものとする。そして、処理がステップＲ３３に移行する。

続くステップＲ３３において、ポリシー管理部５０は、ユーザ情報６５を参照し、各ユーザのリソースＩＤを取得（抽出）する。そして、処理がステップＲ３４に移行する。

続くステップＲ３４において、同意ポータルサーバ１０のトークン発行部５４は、トークンを生成し、保険会社のサーバ２００に対して送信（発行）する。そして、トークン発行部５４は、処理を終了する。

一方、ステップＲ２において、上述したステップＲ１にて取得した要求メッセージが、保険会社のサーバ２００から送信されたトークンである場合、処理がステップＲ４０に移行する（ステップＲ２における“メッセージ６”ルート参照）。

ステップＲ４０において、同意ポータルサーバ１０のトークン検証部５５は、上述したステップＲ１にて取得したトークン（要求メッセージ）が、上述したステップＲ３４にてトークン発行部５４により生成され送信されたトークンと同一のものであるかを検証する。

このステップＲ４０において、トークン検証部５５は、トークンが同一のものである、すなわち、当該トークンが正当であると判断した場合、処理がステップＲ４１に移行する（ステップＲ４０における“正当である”ルート参照）。

一方、ステップＲ４０において、トークン検証部５５は、同一のものではない、すなわち、当該トークンが正当ではないと判断した場合、処理がステップＲ４２に移行する（ステップＲ４０における“正当ではない”ルート参照）。

ステップＲ４１において、トークン検証部５５は、上述のステップＲ４０における検証結果と、上述のステップＲ３３で抽出した、対象ユーザのリソースＩＤ（のリスト）を自動車会社のサーバ３００に送信する。そして、トークン検証部５５は処理を終了する。

また、ステップＲ４２において、トークン検証部５５は、上述のステップＲ４０における検証結果としてエラーを自動車会社のサーバ３００に送信する。そして、トークン検証部５５は処理を終了する。

〔２〕一実施形態の変形例
図７，図１０，図１４のシーケンスチャート、及び、図１６，図１７のフローチャートでは、保険会社のサーバ２００が自動車会社のサーバ３００から情報を取得する際の同意ポータルサーバ１０による制御処理を説明したが、これに限定されるものではない。例えば、図１８，図１９に例示するように、保険会社側にゲートウェイを配置し、また、自動車会社側にゲートウェイを配置し、これらの各ゲートウェイが、保険会社のサーバ２００と自動車会社のサーバ３００とをそれぞれ代行してもよい。この保険会社側のゲートウェイを第一の情報処理装置側ゲートウェイともいい、自動車会社側のゲートウェイを第二の情報処理装置側ゲートウェイともいう。

そして、本変形例において、同意ポータルサーバ１０は、保険会社側のゲートウェイと、自動車会社側のゲートウェイとの仲介者として機能する。

図１８は、本変形例に係る情報処理システム１におけるフェーズ１の制御処理を説明するためのシーケンスチャートである。

この図１８に例示するように、ステップＳ１において、保険会社のサーバ２００は、メタ情報の取得要求を保険会社側のゲートウェイにまず送信し、保険会社側のゲートウェイが当該要求を自動車会社側のゲートウェイに対して送信する。すなわち、保険会社のサーバ２００は、当該要求を保険会社側のゲートウェイ経由で自動車会社側のゲートウェイに送信する点が上述した一実施形態と異なる点である。

そして、後続のステップＳ２〜Ｓ１５の一連の処理において、上述した一実施形態では保険会社のサーバ２００が行なっていた処理を本変形例では保険会社側のゲートウェイが代行（実行）する。

同様に、本変形例におけるステップＳ２〜Ｓ１５の一連の処理において、上述した一実施形態では自動車会社のサーバ３００が行なっていた処理を本変形例では自動車会社側のゲートウェイが代行（実行）する。

また、ステップＳ１４において、同意ポータルサーバ１０のトークン検証部５５は、検証結果、及び、保険会社の基本情報と対象サービス情報とを、自動車会社側のゲートウェイ経由で自動車会社のサーバ３００に対して送信することになる。

そして、ステップＳ１５において、自動車会社のサーバ３００は、自身のメタ情報を、自動車会社側のゲートウェイ経由で保険会社側のゲートウェイに送信する。

また、ステップＳ１６においては、保険会社側のゲートウェイは、自動車会社のサーバ３００からメタ情報を取得し、この取得したメタ情報を保険会社のサーバ２００に送信する。すなわち、自動車会社のサーバ３００は、メタ情報を保険会社側のゲートウェイ経由で保険会社のサーバ２００に送信する点が上述した一実施形態と異なる点である。

また、図１９は、本変形例に係る情報処理システム１におけるフェーズ２の制御処理を説明するためのシーケンスチャートである。

この図１９に例示するように、ステップＴ１において、保険会社のサーバ２００は、パーソナルデータの取得要求を保険会社側のゲートウェイにまず送信し、保険会社側のゲートウェイが当該要求を自動車会社側のゲートウェイに対して送信する。すなわち、保険会社のサーバ２００は、当該要求を保険会社側のゲートウェイ経由で自動車会社側のゲートウェイに送信する点が上述した一実施形態と異なる点である。

そして、後続のステップＴ２〜Ｔ１５の一連の処理において、上述した一実施形態では保険会社のサーバ２００が行なっていた処理を本変形例では保険会社側のゲートウェイが代行（実行）する。

同様に、本変形例におけるステップＴ２〜Ｔ１５の一連の処理において、上述した一実施形態では自動車会社のサーバ３００が行なっていた処理を本変形例では自動車会社側のゲートウェイが代行（実行）する。

また、ステップＴ１４において、同意ポータルサーバ１０のトークン検証部５５は、検証結果、及び、リソースＩＤ（のリスト）を、自動車会社側のゲートウェイ経由で自動車会社のサーバ３００に対して送信することになる。

そして、ステップＴ１５において、自動車会社のサーバ３００は、自身のメタ情報を、自動車会社側のゲートウェイ経由で保険会社側のゲートウェイに送信する。

また、ステップＴ１６においては、保険会社側のゲートウェイは、自動車会社のサーバ３００からパーソナルデータを取得し、この取得したパーソナルデータを保険会社のサーバ２００に送信する。すなわち、自動車会社のサーバ３００は、パーソナルデータを保険会社側のゲートウェイ経由で保険会社のサーバ２００に送信する点が上述した一実施形態と異なる点である。

このように本変形例では、自動車会社のサーバ３００と保険会社のサーバ２００に代わり、それぞれのゲートウェイが各ステップの処理を代行（実行）することにより、自動車会社のサーバ３００と保険会社のサーバ２００との負荷が少なくなる。また、自動車会社のサーバ３００と保険会社のサーバ２００とにおいては、送信するメッセージや受信するメッセージを削減できる。

〔３〕効果
このように、一実施形態、及び、変形例に係る情報処理システム１では、仲介者として機能する同意ポータルサーバ１０が、コマンド情報を解析し、対象ユーザを抽出することにより、多数のユーザに関するパーソナルデータを一度にまとめて取得する。これにより、発生するメッセージ量を削減することができる。

また、一実施形態、及び、変形例に係る情報処理システム１では、パーソナルデータの要求，取得処理を行なう段階であるフェーズ２だけでなく、データ提供者のメタ情報を取得する段階のフェーズ１を設けた。これにより、データ提供者毎に異なる場合が多いメタ情報を、データ提供者毎に定義することを避けることができる。また、必要に応じてフェーズ１の処理を実行することにより、最新のメタ情報を取得することが可能となる。

同様に、一実施形態、及び、変形例に係る情報処理システム１では、データ利用者の基本情報や対象サービスを取得する処理を、フェーズ１の処理に組み込んだ。これにより、データ利用者毎に異なる場合が多い、データ利用者の基本情報や対象サービスを、データ利用者毎に定義することを避けることができる。また、必要に応じてフェーズ１の処理を実行することにより、データ利用者毎の最新の基本情報や対象サービスを取得することが可能となる。

また、一実施形態、及び、変形例に係る情報処理システム１では、ＵＭＡ方式に基づき、フェーズ１とフェーズ２との処理を定義したことにより、ＵＭＡ方式を採用したシステムから本方式を採用したシステムに移行する場合にインタフェースの変更が少なくて済む。

また、変形例に係る情報処理システム１では、クライアントサーバ２０とリソースサーバ３０との処理を代行するゲートウェイをそれぞれ配備することで、クライアントサーバ２０とリソースサーバ３０とにおけるメッセージ量を削減できる。

また、変形例に係る情報処理システム１では、クライアントサーバ２０（データ利用者のサーバ）とデータ利用者側のゲートウェイとの間で通信されるメッセージは少なく、このメッセージは簡易なもので済む。したがって、ＵＭＡ等のプロトコルを意識せず、クライアントサーバ２０におけるアプリケーション等の開発が容易に実現できるうえ、当該アプリケーションにおけるメッセージ処理の負荷も削減できる。

同様に、変形例に係る情報処理システム１では、リソースサーバ３０（データ提供者のサーバ）とデータ提供者側のゲートウェイとの間で通信されるメッセージは少なく、このメッセージは簡易なもので済む。したがって、ＵＭＡ等のプロトコルを意識せず、リソースサーバ３０におけるアプリケーション等の開発が容易に実現できるうえ、当該アプリケーションにおけるメッセージ処理の負荷も削減できる。

〔４〕その他
上述した一実施形態に係る技術は、以下のように変形、変更して実施することができる。

上述した一実施形態、及び、変形例では、情報処理システム１において、処理をフェーズ１とフェーズ２とに分割したが、これらの２つの処理をまとめて１つの処理として実行してもよい。その場合、フェーズ１とフェーズ２とにおける同一の処理については、一つのプロセスにまとめてもよい。

また、上述した一実施形態、及び、変形例では、同意情報６０、ユーザポリシー情報６１、チケット情報６２、トークン情報６３、基本情報６４、及び、ユーザ情報６５を同意ポータルサーバ１０の記憶部１２に備える構成としたが、これに限られない。また、これらの各情報は、例えば、同意ポータルサーバ１０の外部に備える図示しない記憶部に格納してもよい。その場合、同意ポータルサーバ１０は、例えば、ネットワーク経由でこれらの情報を取得してもよい。

また、上述した一実施形態、及び、変形例に係る情報処理システム１では、同意ポータルサーバ１０が備えるトークン情報６３と、リソースサーバ３０によって管理されるリソースＩＤとを同期させるものとしたが、これに限られない。また、同意ポータルサーバ１０が備えるトークン情報６３に対して、リソースサーバ３０が自身が管理するリソースＩＤを書込んでもよい。

〔５〕付記
以上の実施形態に関し、さらに以下の付記を開示する。

（付記１）
第一の情報処理装置が仲介装置を介して第二の情報処理装置から複数のユーザのユーザデータを取得する情報処理システムにおいて、
前記第一の情報処理装置は、前記複数のユーザのユーザデータについて、抽出用情報の取得要求を前記第二の情報処理装置に送信し、
前記仲介装置は、前記第一の情報処理装置が前記取得要求に応じて前記第二の情報処理装置から受信した前記抽出用情報に基づいた情報を前記第一の情報処理装置から受信し、受信した前記情報に基づいて、前記取得要求の対象となる複数のユーザを抽出し、抽出した前記複数のユーザについての情報を前記第二の情報処理装置に送信し、
前記第二の情報処理装置は、前記仲介装置により抽出された前記複数のユーザについての情報に基づき、前記複数のユーザのユーザデータを抽出して一括して前記第一の情報処理装置に送信する、
ことを特徴とする、情報処理システム。

（付記２）
前記仲介装置は、前記抽出用情報がメタ情報の取得を示す場合、前記第一の情報処理装置の要求データ項目を前記第二の情報処理装置に送信し、
前記第二の情報処理装置は、前記第二の情報処理装置のメタ情報を前記第一の情報処理装置に送信する、
ことを特徴とする、付記１記載の情報処理システム。

（付記３）
前記メタ情報は、少なくともフィルタ情報とデータ形式とのいずれかを含む、
ことを特徴とする、付記２記載の情報処理システム。

（付記４）
前記第一の情報処理装置は、前記メタ情報を取得した後、前記複数のユーザのユーザデータを取得する、
ことを特徴とする、付記２記載の情報処理システム。

（付記５）
前記情報処理システムはさらに、第一の情報処理装置側ゲートウェイと第二の情報処理装置側ゲートウェイとを備え、
前記第一の情報処理装置側ゲートウェイと、前記第二の情報処理装置側ゲートウェイとは、それぞれ、前記第一の情報処理装置と前記第二の情報処理装置とにおける処理を代行する、
ことを特徴とする、付記１〜付記４のいずれか一項に記載の情報処理システム。

（付記６）
第一の情報処理装置が複数のユーザのユーザデータについて第二の情報処理装置に送信した取得要求に関連する抽出用情報を前記第一の情報処理装置から受信するチケット検証部と、
受信した前記抽出用情報に基づいて、前記取得要求の対象となる複数のユーザを抽出する対象ユーザ抽出部と、
抽出した前記複数のユーザについての情報を前記第二の情報処理装置に送信する送信部と、
を備える、
ことを特徴とする、情報処理装置。

（付記７）
前記送信部が、前記抽出用情報がメタ情報の取得を示す場合、前記第一の情報処理装置の要求データ項目を前記第二の情報処理装置に送信する、
ことを特徴とする、付記６記載の情報処理装置。

（付記８）
前記メタ情報は、少なくともフィルタ情報とデータ形式とのいずれかを含む、
ことを特徴とする、付記７記載の情報処理装置。

（付記９）
第一の情報処理装置が仲介装置を介して第二の情報処理装置から複数のユーザのユーザデータを取得する情報処理システムにおいて、
前記第一の情報処理装置が、前記複数のユーザのユーザデータについて、抽出用情報の取得要求を前記第二の情報処理装置に送信する処理と、
前記仲介装置が、前記第一の情報処理装置が前記取得要求に応じて前記第二の情報処理装置から受信した前記抽出用情報に基づいた情報を前記第一の情報処理装置から受信し、受信した前記情報に基づいて、前記取得要求の対象となる複数のユーザを抽出し、抽出した前記複数のユーザについての情報を前記第二の情報処理装置に送信する処理と、
前記第二の情報処理装置が、前記仲介装置により抽出された前記複数のユーザについての情報に基づき、前記複数のユーザのユーザデータを抽出して一括して前記第一の情報処理装置に送信する処理と、
を備える、
ことを特徴とする、制御方法。

（付記１０）
前記仲介装置が、前記抽出用情報がメタ情報の取得を示す場合、前記第一の情報処理装置の要求データ項目を前記第二の情報処理装置に送信する処理と、
前記第二の情報処理装置が、前記第二の情報処理装置のメタ情報を前記第一の情報処理装置に送信する処理と、
を備える、
ことを特徴とする、付記９記載の制御方法。

（付記１１）
前記メタ情報は、少なくともフィルタ情報とデータ形式とのいずれかを含む、
ことを特徴とする、付記１０記載の制御方法。

（付記１２）
前記第一の情報処理装置が、前記メタ情報を取得した後、前記複数のユーザのユーザデータを取得する、
ことを特徴とする、付記１０記載の制御方法。

（付記１３）
前記情報処理システムはさらに、第一の情報処理装置側ゲートウェイと第二の情報処理装置側ゲートウェイとを備え、
前記第一の情報処理装置側ゲートウェイと、前記第二の情報処理装置側ゲートウェイとは、それぞれ、前記第一の情報処理装置と前記第二の情報処理装置とにおける処理を代行する、
ことを特徴とする、付記９〜付記１２のいずれか一項に記載の制御方法。

（付記１４）
第一の情報処理装置と第二の情報処理装置とを通信可能に接続する仲介装置のプロセッサに、
前記第一の情報処理装置が複数のユーザのユーザデータについて前記第二の情報処理装置に送信した取得要求に関連する抽出用情報を前記第一の情報処理装置から受信し、
受信した前記抽出用情報に基づいて、前記取得要求の対象となる複数のユーザを抽出し、
抽出した前記複数のユーザについての情報を前記第二の情報処理装置に送信する、処理を実行させる、
ことを特徴とする制御プログラム。

（付記１５）
前記抽出用情報がメタ情報の取得を示す場合、前記第一の情報処理装置の要求データ項目を前記第二の情報処理装置に送信する処理を前記プロセッサに実行させる、
ことを特徴とする、付記１４記載の制御プログラム。

（付記１６）
前記メタ情報は、少なくともフィルタ情報とデータ形式とのいずれかを含む、
ことを特徴とする、付記１５記載の制御プログラム。

１ 情報処理システム
１０ 同意ポータルサーバ（仲介装置）
１１ ＣＰＵ
１２ 記憶部
１３ メモリ
１４ ＩＦ部
１５ 入力部
１６ 表示部
２０ クライアントサーバ（第一の情報処理装置）
３０ リソースサーバ（第二の情報処理装置）
４０ ユーザ端末
４１ ＣＰＵ
４２ 記憶部
４３ メモリ
４４ ＩＦ部
４５ 入力部
４６ 表示部
５０ ポリシー管理部（対象ユーザ抽出部）
５１ コマンド情報解析部
５２ チケット発行部
５３ チケット検証部
５４ トークン発行部
５５ トークン検証部（送信部）
５６ リソースＩＤ抽出部
６０ 同意情報
６１ ユーザポリシー情報
６２ チケット情報
６３ トークン情報
６４ 基本情報
６５ ユーザ情報
９０ ネットワーク
９１ 制御プログラム
９２ ポリシー登録プログラム
２００ 保険会社のサーバ
３００ 自動車会社のサーバ

Claims (8)

1. 第一の情報処理装置が仲介装置を介して第二の情報処理装置から複数のユーザのユーザデータを取得する情報処理システムにおいて、
   前記第一の情報処理装置は、前記複数のユーザのユーザデータについて、抽出用情報の取得要求を前記第二の情報処理装置に送信し、
   前記仲介装置は、前記第一の情報処理装置が前記取得要求に応じて前記第二の情報処理装置から受信した前記抽出用情報に基づいた情報を前記第一の情報処理装置から受信し、受信した前記情報に基づいて、前記取得要求の対象となる複数のユーザを抽出し、抽出した前記複数のユーザについての情報を前記第二の情報処理装置に送信し、
   前記第二の情報処理装置は、前記仲介装置により抽出された前記複数のユーザについての情報に基づき、前記複数のユーザのユーザデータを抽出して一括して前記第一の情報処理装置に送信する、
   ことを特徴とする、情報処理システム。
2. 前記仲介装置は、前記抽出用情報がメタ情報の取得を示す場合、前記第一の情報処理装置の要求データ項目を前記第二の情報処理装置に送信し、
   前記第二の情報処理装置は、前記第二の情報処理装置のメタ情報を前記第一の情報処理装置に送信する、
   ことを特徴とする、請求項１記載の情報処理システム。
3. 前記メタ情報は、少なくともフィルタ情報とデータ形式とのいずれかを含む、
   ことを特徴とする、請求項２記載の情報処理システム。
4. 前記第一の情報処理装置は、前記メタ情報を取得した後、前記複数のユーザのユーザデータを取得する、
   ことを特徴とする、請求項２記載の情報処理システム。
5. 前記情報処理システムはさらに、第一の情報処理装置側ゲートウェイと第二の情報処理装置側ゲートウェイとを備え、
   前記第一の情報処理装置側ゲートウェイと、前記第二の情報処理装置側ゲートウェイとは、それぞれ、前記第一の情報処理装置と前記第二の情報処理装置とにおける処理を代行する、
   ことを特徴とする、請求項１〜請求項４のいずれか一項に記載の情報処理システム。
6. 第一の情報処理装置が複数のユーザのユーザデータについて第二の情報処理装置に送信した取得要求に関連する抽出用情報を前記第一の情報処理装置から受信するチケット検証部と、
   受信した前記抽出用情報に基づいて、前記取得要求の対象となる複数のユーザを抽出する対象ユーザ抽出部と、
   抽出した前記複数のユーザについての情報を前記第二の情報処理装置に送信する送信部と、
   を備える、
   ことを特徴とする、情報処理装置。
7. 第一の情報処理装置が仲介装置を介して第二の情報処理装置から複数のユーザのユーザデータを取得する情報処理システムにおいて、
   前記第一の情報処理装置が、前記複数のユーザのユーザデータについて、抽出用情報の取得要求を前記第二の情報処理装置に送信する処理と、
   前記仲介装置が、前記第一の情報処理装置が前記取得要求に応じて前記第二の情報処理装置から受信した前記抽出用情報に基づいた情報を前記第一の情報処理装置から受信し、受信した前記情報に基づいて、前記取得要求の対象となる複数のユーザを抽出し、抽出した前記複数のユーザについての情報を前記第二の情報処理装置に送信する処理と、
   前記第二の情報処理装置が、前記仲介装置により抽出された前記複数のユーザについての情報に基づき、前記複数のユーザのユーザデータを抽出して一括して前記第一の情報処理装置に送信する処理と、
   を備える、
   ことを特徴とする、制御方法。
8. 第一の情報処理装置と第二の情報処理装置とを通信可能に接続する仲介装置のプロセッサに、
   前記第一の情報処理装置が複数のユーザのユーザデータについて前記第二の情報処理装置に送信した取得要求に関連する抽出用情報を前記第一の情報処理装置から受信し、
   受信した前記抽出用情報に基づいて、前記取得要求の対象となる複数のユーザを抽出し、
   抽出した前記複数のユーザについての情報を前記第二の情報処理装置に送信する、処理を実行させる、
   ことを特徴とする制御プログラム。

Images