(57)【要約】【課題】分散システムにおいてユーザ情報を効率的に外部へ提供する。【解決手段】情報提供システム１００は、ユーザ情報を提供する複数の情報提供装置１０４を備える。各情報提供装置１０４は、ユーザ情報の取得要求をサービス提供装置３００から受け付け、要求された項目を示す要求項目情報を、サービス提供装置３００を介してユーザ端末２００へ通知する。そして、他の情報提供装置１０４で設定された要求項目情報をユーザ端末２００から受け付けた際、その要求項目情報が示すユーザ情報の提供許否をユーザ端末２００に確認し、提供が許可された項目を示す許可項目情報を、ユーザ端末２００を介してサービス提供装置３００へ通知する。そして、他の情報提供装置１０４で設定された許可項目情報をサービス提供装置３００から受け付けた際、その許可項目情報が示すユーザ情報をサービス提供装置３００へ提供する。【選択図】図１
2011209862.tif 000002
【特許請求の範囲】
【請求項１】
ユーザの属性を示すユーザ情報を提供する複数の情報提供装置を備え、
前記複数の情報提供装置のそれぞれは、
ユーザ情報に含まれる１以上の項目のうち少なくとも一部の取得要求を外部装置から受け付ける要求受付部と、
要求された項目を示す要求項目情報を、前記外部装置を介してユーザ端末へ通知する要求項目通知部と、
他の情報提供装置において設定された要求項目情報を前記ユーザ端末から受け付けた際、その要求項目情報が示す項目のユーザ情報について、前記外部装置への提供許否を前記ユーザ端末に確認する許否確認部と、
提供が許可された項目を示す許可項目情報を、前記ユーザ端末を介して前記外部装置へ通知する許可項目通知部と、
他の情報提供装置において設定された許可項目情報を前記外部装置から受け付けた際、その許可項目情報が示す項目のユーザ情報を前記外部装置へ提供するユーザ情報提供部と、を含むことを特徴とする情報提供システム。
【請求項２】
前記複数の情報提供装置のそれぞれは、前記１以上の項目のそれぞれと、各項目を一意に特定するための項目番号とを対応づけた同一の対応関係を保持する対応関係保持部をさらに含み、
前記要求項目通知部は、要求された項目の項目番号を示す情報を前記要求項目情報として通知し、
前記許否確認部は、前記要求項目情報が示す項目番号に対応するユーザ情報の提供許否を確認し、
前記許可項目通知部は、提供が許可されたユーザ情報に対応する項目番号を示す情報を前記許可項目情報として通知し、
前記ユーザ情報提供部は、前記許可項目情報が示す項目番号に対応するユーザ情報を前記外部装置へ提供することを特徴とする請求項１に記載の情報提供システム。
【請求項３】
前記要求項目通知部は、ユーザ情報の項目数のビット長を有し、要求された項目の項目番号が示す位置のビットを他のビットとは異なる値としたビット列について、そのビット列を示す情報を前記要求項目情報として通知し、
前記許否確認部は、前記要求項目情報が示すビット列において前記異なる値が設定された位置に対応するユーザ情報の提供許否を確認し、
前記許可項目通知部は、ユーザ情報の項目数のビット長を有し、提供が許可されたユーザ情報の項目番号が示す位置のビットを他のビットとは異なる値としたビット列について、そのビット列を示す情報を前記許可項目情報として通知し、
前記ユーザ情報提供部は、前記許可項目情報が示すビット列において前記異なる値が設定された位置に対応するユーザ情報を前記外部装置へ提供することを特徴とする請求項２に記載の情報提供システム。
【請求項４】
前記要求項目通知部は、所定の文字コードにおいて区別可能に表される文字数の範囲内で可及的に大きな値を基数として、前記ビット長の値を表した文字列を前記要求項目情報として通知することを特徴とする請求項３に記載の情報提供システム。
【請求項５】
前記要求項目通知部は、前記外部装置から受け付けられた情報であって、前記ユーザ端末において確認させるべき付加情報を前記要求項目情報と対応づけて通知し、
前記許否確認部は、ユーザ情報の提供許否を確認する際、前記付加情報を前記ユーザ端末へ提示することを特徴とする請求項１から４のいずれかに記載の情報提供システム。
【請求項６】
前記要求項目通知部は、前記要求項目情報と前記付加情報のうち少なくとも前記付加情報を、前記複数の情報提供装置間で共通の鍵により暗号化し、
前記許否確認部は、暗号化されたデータを前記共通の鍵により復号した後、ユーザ情報の提供許否を確認することを特徴とする請求項５に記載の情報提供システム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、データ処理技術に関し、特に、ユーザに関する情報を外部へ提供する技術に関する。
【背景技術】
【０００２】
インターネットやブロードバンドサービスの普及に伴って、様々な金融サービスやＥＣ（Electronic Commerce）がオンラインでユーザに提供されている。このようなオンラインサービスを提供するサービス提供装置の中には、サービスを提供するためにユーザの情報を要求するものがある。以下の特許文献１では、サービス提供装置に対するユーザ情報の提供許否をユーザに確認し、提供が許可されたユーザ情報をサービス提供装置へ提供する属性情報開示技術が提案されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００９−１９９５７３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
クラウドコンピューティング等の分散処理技術が提唱されてきており、ユーザ情報の提供に関する一連のプロセスが複数の装置により分散実行されることが考えられる。本発明者は、このような分散処理システムにおいてユーザ情報を効率的に外部へ提供する発想や、その具体的な方法はこれまで十分に提案されてこなかったと考えた。
【０００５】
本発明は、本発明者の上記課題認識に基づきなされたものであり、その主たる目的は、分散処理システムにおいてユーザ情報を効率的に外部へ提供する技術を提供することである。
【課題を解決するための手段】
【０００６】
上記課題を解決するために、本発明のある態様の情報提供システムは、ユーザの属性を示すユーザ情報を提供する複数の情報提供装置を備える。複数の情報提供装置のそれぞれは、ユーザ情報に含まれる１以上の項目のうち少なくとも一部の取得要求を外部装置から受け付ける要求受付部と、要求された項目を示す要求項目情報を、外部装置を介してユーザ端末へ通知する要求項目通知部と、他の情報提供装置において設定された要求項目情報をユーザ端末から受け付けた際、その要求項目情報が示す項目のユーザ情報について、外部装置への提供許否をユーザ端末に確認する許否確認部と、提供が許可された項目を示す許可項目情報を、ユーザ端末を介して外部装置へ通知する許可項目通知部と、他の情報提供装置において設定された許可項目情報を外部装置から受け付けた際、その許可項目情報が示す項目のユーザ情報を外部装置へ提供するユーザ情報提供部と、を含む。
【０００７】
なお、以上の構成要素の任意の組合せ、本発明の表現を装置、方法、システム、プログラム、プログラムを格納した記録媒体などの間で変換したものもまた、本発明の態様として有効である。
【発明の効果】
【０００８】
本発明によれば、分散処理システムにおいてユーザ情報を効率的に外部へ提供できる。
【図面の簡単な説明】
【０００９】
【図１】実施の形態の情報提供システムの概略構成を示す図である。
【図２】ユーザ情報を提供する従来の第１方法を示すシーケンス図である。
【図３】ユーザ情報を提供する従来の第２方法を示すシーケンス図である。
【図４】図１の情報提供装置１０４の機能構成を示すブロック図である。
【図５】対応関係保持部に保持される対応関係の一例を示す図である。
【図６】情報提供要求の一例を示す図である。
【図７】変換圧縮データの構成を示す図である。
【図８】確認画面の一例を示す図である。
【図９】実施の形態におけるユーザ情報の提供プロセスを示すシーケンス図である。
【発明を実施するための形態】
【００１０】
図１は、実施の形態の情報提供システムの概略構成を示す。サービス提供装置３００は、ユーザにより操作されるユーザ端末２００からの要求に応じて所定のサービスを提供するサーバ装置である。本実施の形態では、ユーザが所望する情報を含むウェブページをユーザ端末２００へ提供するウェブサーバであることとする。ユーザ端末２００は、ウェブブラウザが搭載され、ウェブページを表示可能な情報処理端末であり、例えばＰＣや携帯電話端末であってもよい。
【００１１】
サービス提供装置３００は、ユーザ端末２００へウェブページを提供するに際し、その条件として、ユーザの属性に関する情報（以下、「ユーザ情報」とも呼ぶ。）の提供を要求する。言い換えれば、サービス提供装置３００からサービスを享受するために、ユーザ端末２００はサービス提供装置３００に対してユーザ情報を提供する必要がある。このユーザ情報には、氏名、年齢、住所、性別、職業、年収、口座番号、クレジットカード番号等、様々な項目の情報が含まれる。
【００１２】
また、本実施の形態においてユーザ情報は情報提供システム１００に保持される。ユーザ端末２００およびサービス提供装置３００は、情報提供システム１００に対し適宜アクセスすることにより、情報提供システム１００からサービス提供装置３００へユーザ情報を提供させる。具体的には、サービス提供装置３００は情報提供システム１００に対してユーザ情報の提供を要求し、ユーザ端末２００は情報提供システム１００に対してユーザ情報の提供を許可する必要がある。
【００１３】
情報提供システム１００は、ユーザ情報ＤＢ１０２と、情報提供装置１０４で総称される第１の情報提供装置１０４ａ、第２の情報提供装置１０４ｂ、・・・とを備える。ユーザ情報ＤＢ１０２は、ユーザ情報が格納されたストレージを備え、ユーザ情報を一元的に管理するバックエンドのデータベースサーバである。一方で、第１の情報提供装置１０４ａおよび第２の情報提供装置１０４ｂは、ユーザ情報の提供要求を外部から受け付けるフロントエンドの情報処理装置であり、ユーザ情報の提供に関する複数の要求を負荷分散して処理する。なお、図１には図示しないが、情報提供システム１００は、外部からの複数の要求を振分ける負荷分散装置を適宜備えてもよい。
【００１４】
情報提供システム１００の外部（例えばユーザ端末２００やサービス提供装置３００）からは、ユーザ情報の提供に関する要求を実際に処理する装置を意識することなく、その要求を単一のエンティティに送信する。例えば、共通のアドレス（ＵＲＬ等）を指定して要求を送信する。情報提供システム１００に対する複数の要求のそれぞれは、複数の情報提供装置１０４のいずれかにより処理される。すなわち、情報提供システム１００では、ユーザ情報の提供がクラウドコンピューティングに基づく分散処理により実現される。なお、図１の各装置は、ＬＡＮ／ＷＡＮ／インターネット等、公知の通信手段を含む通信網により相互に接続される。
【００１５】
次に、本発明の特徴的な構成を説明する前に、情報提供装置１０４からサービス提供装置３００へユーザ情報を提供する従来の方法を説明する。
【００１６】
図２は、ユーザ情報を提供する従来の第１方法を示すシーケンス図である。ユーザ端末２００がサービス提供装置３００に対してサービスの提供を要求すると（Ｓ１０）、サービス提供装置３００はユーザ端末２００に対してユーザ情報の提供を要求する（Ｓ１２）。ユーザ端末２００は、情報提供装置１０４に対してユーザ情報の提供を要求する（Ｓ１４）。情報提供装置１０４は、その要求データに基づき、ユーザ情報の提供許否を確認するための画面（以下、「確認画面」とも呼ぶ。）のデータを設定する（Ｓ１６）。そして確認画面のデータをユーザ端末２００へ送信して表示させる（Ｓ１８）。確認画面に対するユーザの操作に基づき、ユーザ端末２００は、ユーザ情報の提供を承認する旨のデータを情報提供装置１０４へ送信する（Ｓ２０）。情報提供装置１０４はユーザ情報をユーザ端末２００へ送信し（Ｓ２２）、ユーザ端末２００は取得したユーザ情報をサービス提供装置３００へ送信する（Ｓ２４）。以降、サービス提供装置３００からユーザ端末２００へサービスが提供され、例えばユーザが所望するウェブページがサービス提供装置３００からユーザ端末２００へ送信される。
【００１７】
この第１方法では、ユーザ情報を要求する旨のデータを装置間で持ち回ることになる。このデータは、例えば、ＨＴＴＰ（ＧＥＴ）リクエストにおいてＵＲＬのパラメータとして伝送される。ところで、サービス提供装置３００がユーザ端末２００に要求するユーザ情報の項目種類（例えば氏名、年齢、性別、住所、メールアドレス、・・・）は多数にのぼることがあり、この場合、Ｓ１４で送信される要求データのサイズは大きくなる。一般的に、ウェブブラウザには送信データ量の制限が設けられている（例えば、最大サイズが２ＫＢに制限される）ため、ウェブブラウザを介して要求データを送信することが困難になることがある。また一般的にネットワークトラヒックは低いことが望ましく、また、サーバ装置に比べてハードウェアリソース量が制限されやすいユーザ端末２００においては、中継すべきデータサイズは小さいことが望ましい。このような観点からも、第１方法には改善すべき余地があるといえる。
【００１８】
図３は、ユーザ情報を提供する従来の第２方法を示すシーケンス図である。この第２方法は、予めサービス提供装置３００から情報提供装置１０４へユーザ情報を要求しておき、その要求を一意に特定することが可能なポインタ情報のみを装置間で持ち回る。このポインタ情報は、「Ａｒｔｉｆａｃｔ」、「Ｒｅｓｐｏｎｓｅ  Ａｒｔｉｆａｃｔ」とも呼ばれる。これにより、ユーザ端末２００において取り扱うべきデータ量を低減し、第１方法の問題を解決する。以下、具体的に説明する。
【００１９】
ユーザ端末２００は、サービス提供装置３００に対してサービスの提供を要求する（Ｓ３０）。サービス提供装置３００は、情報提供装置１０４に対してユーザ情報の提供を要求する（Ｓ３２）。情報提供装置１０４は、要求データをローカルストレージに格納する（Ｓ３４）。そして、要求データを受け付けた旨を示す情報であり、情報提供装置１０４においてその要求データを一意に指し示すポインタ情報（以下、「要求受付情報」とも呼ぶ。）をサービス提供装置３００へ送信する（Ｓ３６）。この要求受付情報は、例えば、情報提供装置１０４のローカルストレージにおける要求データの格納位置を示す情報である。サービス提供装置３００は、要求受付情報をユーザ端末２００へ転送し（Ｓ３８）、ユーザ端末２００は、要求受付情報を情報提供装置１０４へ送信する（Ｓ４０）。情報提供装置１０４は、その要求受付情報に基づいて元の要求データを特定し、その要求データから確認画面のデータを設定する（Ｓ４２）。
【００２０】
続いて、情報提供装置１０４は確認画面のデータをユーザ端末２００へ送信して表示させ（Ｓ４４）、ユーザ端末２００はユーザ情報の提供を許可する旨のデータを情報提供装置１０４へ送信する（Ｓ４６）。情報提供装置１０４は、ユーザ情報の提供が許可された旨を示す情報であり、元の要求データを一意に指し示すポインタ情報（以下、「提供許可情報」とも呼ぶ。）をユーザ端末２００へ送信する（Ｓ４８）。この提供許可情報は、例えば、要求受付情報の一部が改変された（特定の項目値やビット値が提供許可情報を示す値に変更された）ものである。ユーザ端末２００は提供許可情報をサービス提供装置３００へ転送し（Ｓ５０）、サービス提供装置３００は提供許可情報を情報提供装置１０４へ送信する（Ｓ５２）。情報提供装置１０４は、提供許可情報に基づいて元の要求データを特定し、要求されたユーザ情報を所定の記憶装置（例えばユーザ情報ＤＢ１０２）から取得して（Ｓ５４）、サービス提供装置３００へ送信する（Ｓ５６）。
【００２１】
上述のとおり、第２方法において装置間で持ち回るデータは、要求データのポインタ情報となるため、そのデータ量が削減されるが、第２方法では新たな問題が生じる。すなわち、情報提供システム１００のように外部からの要求が複数の情報提供装置１０４で分散処理される場合には、サービス提供装置３００からの要求データを受け付けて要求受付情報を設定する情報提供装置１０４と、その要求受付情報をユーザ端末２００から受け付ける情報提供装置１０４とが異なることがある。例えば、サービス提供装置３００がＡ国に設置され、その一方でユーザ端末２００がＢ国に設置されているとき、サービス提供装置３００からの要求はＡ国に設置された情報提供装置１０４により処理され、ユーザ端末２００からの要求はＢ国に設置された情報提供装置１０４により処理されることがある。この場合、ユーザ端末２００からの要求を受け付けた情報提供装置１０４では、元の要求データが保持されていないため、要求受付情報から元の要求データを再生できず、その結果、ユーザ情報の提供プロセスが続行不能になってしまう。
【００２２】
なお、複数の情報提供装置１０４のローカルストレージ間でレプリケーションを行うことも考えられるが、レプリケーションにはある程度の時間を要するため、レプリケーションが間に合わないことがある。また、レプリケーションの完了まで処理を遅延させる場合は、要求の受け付けから情報提供までに要する時間が増大し、スループットの低下等、サービスレベルが低下してしまう。
【００２３】
そこで本実施の形態では、ユーザ情報の提供を要求する旨のデータ（以下、「情報提供要求」とも呼ぶ。）そのものではなく、より小さいサイズの受付情報を装置間で持ち回るという第２方法の技術思想は維持しつつ、第２方法の上記デメリットを改善した技術を提案する。具体的には、いずれの情報提供装置１０４においても受付情報から元の情報提供要求を再生可能とする技術を提案する。
【００２４】
図４は、図１の情報提供装置１０４の機能構成を示すブロック図である。本明細書のブロック図において示される各ブロックは、ハードウェア的には、コンピュータのＣＰＵをはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウェア、ソフトウェアの組合せによっていろいろなかたちで実現できることは、当業者には理解されるところである。例えば、各機能ブロックは、コンピュータプログラムとして記録媒体に格納され、情報提供装置１０４のハードディスクにインストールされ、情報提供装置１０４のメインメモリに適宜読み出されてプロセッサにて実行されてもよい。
【００２５】
情報提供装置１０４は、対応関係保持部１０と、各種データ処理を実行するデータ処理部２０とを備える。データ処理部２０は、情報提供要求の受付に関連する処理を実行する受付処理部３０と、ユーザ情報の提供許否の確認に関連する処理を実行する確認処理部４０と、ユーザ情報の提供に関連する処理を実行する提供処理部５０とを有する。受付処理部３０は、要求受付部３２と、要求項目設定部３４と、要求項目通知部３６とを含む。確認処理部４０は、要求項目受付部４２と、許否確認部４４と、許可項目設定部４６と、許可項目通知部４８とを含む。提供処理部５０は、許可項目受付部５２と、ユーザ情報取得部５４と、ユーザ情報提供部５６とを含む。なお図４には図示しないが、情報提供装置１０４は、データ処理部２０において処理対象となる各種データを、通信網を介して、外部装置と送受信する通信制御部をさらに備えている。
【００２６】
対応関係保持部１０は、情報提供要求に含まれるデータと、他のデータとの対応関係を保持する記憶領域である。この対応関係は、情報提供要求を他のデータにマッピングする際に参照される。図５は、対応関係保持部１０に保持される対応関係の一例を示す。同図の項目名フィールドには、ユーザ情報に含まれる複数項目の名称が設定される。この名称は、情報提供要求に設定される形式の文字列であり、例えばＵＲＬ形式で設定される。項目番号フィールドには、各項目を一意に特定するための項目番号（言い換えれば各項目のＩＤ）が設定される。表示名フィールドには、各項目を確認画面で表示する際の表示名が設定される。なお、表示名が「非表示」のものは確認画面では表示されない。
【００２７】
図４に戻り、要求受付部３２は、サービス提供装置３００から送信された情報提供要求を受け付ける。図６は、情報提供要求の一例を示す。同図の要求項目６０は、ＯｐｅｎＩＤのＡｔｔｒｉｂｕｔｅＥｘｃｈａｎｇｅ（属性交換）のバージョンが「１．１」であることを示している。要求項目６２は、ユーザの愛称を要求するものであり、デフォルト値として「ｍａｒｋ」が設定されている。要求項目６４はユーザのメールアドレスを要求するものであり、要求項目６６はユーザの使用言語を要求するものである。
【００２８】
図４に戻り、要求項目設定部３４は、対応関係保持部１０の対応関係を参照して、情報提供要求を圧縮したデータであり、情報提供要求の内容を後の時点で再生可能なデータ（以下、「変換圧縮データ」とも呼ぶ。）を設定する。
【００２９】
図７は、変換圧縮データの構成を示す。変換圧縮データ７０は、要求項目情報７２とパラメータ情報７４とが、「：」をデリミタ文字として連結される。要求項目情報７２は、ユーザ情報に含まれる複数項目のうち、どの項目が要求されているかを示す情報であり、要求された項目の項目番号を示す文字列である。パラメータ情報７４は、ユーザ情報の１以上の項目に対して設定された１以上のパラメータ７６を含む。パラメータ７６は、サービス提供装置３００側で設定されて情報提供要求に付加されたデータであり、典型的にはユーザに確認させるべき文字列である。例えば、図４における要求項目６０の「１．１」や、要求項目６２における「ｍａｒｋ」が該当する。図７で示すように、パラメータ情報７４は、１以上のパラメータ７６が「，」をデリミタ文字として連結される。なお、デリミタ文字とした「：」や「，」は例示であり、他の文字（列）やビット列であってもよいことはもちろんである。例えば、変換圧縮データの送受に適用される通信プロトコルや、変換圧縮データが設定されるメッセージの規約により使用が制限される文字以外であればよい。
【００３０】
要求項目設定部３４による要求項目情報７２の設定方法を説明する。まず、ユーザ情報に含まれる項目数をビット長とする２進表記のビット列について、情報提供要求で指定された項目番号に対応するビットを「１」、未指定の（すなわち要求対象でない）項目番号に対応するビットを「０」としたビット列を設定する。ここで、ユーザ情報に含まれる項目数は、言い換えれば、対応関係保持部１０に保持されるユーザ情報の項目数であり、本実施の形態では仮に１０ビットとする。また、項目番号に対応するビットは、項目番号がそのままビットの桁数に対応し、例えば項目番号「１」は１桁目（ＬＳＢ）、項目番号２は２桁目、・・・項目番号１０は１０桁目（ＭＳＢ）に対応することとする。したがって、図６の情報提供要求の場合、ビット列「０１０００００１１１」が設定される。
【００３１】
次に、上記で設定したビット列の値を、所定値ｎを基数として表現した文字列（ｎ進文字列）を要求項目情報７２とする。基数ｎは、所定の文字コードにおいて区別可能に表現できる文字数の範囲内で、可及的に大きな値となることが望ましい。基数ｎが大きいほど、ビット列の値を少ない桁数で表現でき、要求項目情報７２のデータサイズを小さくできるからである。言い換えれば圧縮効率が高まるからである。
【００３２】
例えば、８ビットの文字コード、例えば、シフトＪＩＳコード（の一部）を用いて要求項目情報７２を表す場合には、ｎ＝２５６が設定されてもよい。また、ＡＳＣＩＩコードを使用する場合は、ｎ＝１６（０〜９、Ａ〜Ｆ）、ｎ＝６２（０〜９、ａ〜ｚ、Ａ〜Ｚ）、ｎ＝９６（ＡＳＣＩＩ印刷可能文字）、ｎ＝１２８（ＡＳＣＩＩ制御文字およびＡＳＣＩＩ印刷可能文字）のいずれかに設定されてもよい。また、ｎ≦１２８を満たす任意の数であってもよい。本実施の形態では、ｎ＝６２であることとする。先のビット列「０１０００００１１１」は、要求項目情報７２としては「４ｆ」と表現されることになる。
【００３３】
要求項目設定部３４によるパラメータ情報７４の設定方法を説明する。要求項目設定部３４は、情報提供要求においてユーザ情報の項目と対応づけて設定された値（例えば、サービス提供装置３００における設定値やデフォルト値）を、項目番号と対応づけてパラメータ７６とする。そして、パラメータ７６を連結させてパラメータ情報７４とする。本実施の形態では、図６の情報提供要求から設定されるパラメータ情報７４は、「１＝１．１，２＝ｍａｒｋ」となる。したがって、図６の情報提供要求から最終的に設定される変換圧縮データ７０は、「４ｆ：１＝１．１，２＝ｍａｒｋ」となる。この場合、情報提供要求は２５６文字である一方、変換圧縮データ７０は１３文字であり、データサイズが約１８分の１へ圧縮されたことになる。
【００３４】
図４に戻り、要求項目通知部３６は、要求項目設定部３４において設定された変換圧縮データをサービス提供装置３００へ送信する。この変換圧縮データは、図３の第２方法における要求受付情報に対応するものであり、サービス提供装置３００は、情報提供装置１０４から受信した変換圧縮データをユーザ端末２００へ送信する。
【００３５】
要求項目受付部４２は、ユーザ端末２００から送信された変換圧縮データを受け付ける。許否確認部４４は、変換圧縮データから元の情報提供要求の内容を再生する。具体的には、変換圧縮データの要求項目情報７２から、提供が要求された１以上の項目を特定し、変換圧縮データのパラメータ情報７４から、各項目に設定されたパラメータ値を特定する。例えば、変換圧縮データ「４ｆ：１＝１．１，２＝ｍａｒｋ」の要求項目情報７２「４ｆ」から、ビット列「０１０００００１１１」を特定し、項目番号１〜３および９が要求されたと判定する。また、パラメータ情報７４「１＝１．１，２＝ｍａｒｋ」から、項目番号１のパラメータとして「１．１」が設定され、項目番号２のパラメータとして「ｍａｒｋ」が設定されたと判定する。
【００３６】
許否確認部４４は、対応関係保持部１０の対応関係を参照して、要求された項目番号の表示名を特定し、その項目番号に対応するユーザ情報の項目が要求された旨を確認画面のデータとして設定する。また、パラメータとして設定された設定値・デフォルト値もまた確認画面のデータとして設定する。なお、表示名が「非表示」の項目については、確認画面のデータには設定しない。
【００３７】
図８は、確認画面の一例を示す。同図の確認画面８０は、変換圧縮データ「４ｆ：１＝１．１，２＝ｍａｒｋ」に基づき設定された確認画面を示している。チェックボックス８２は、提供を許可する項目に対してユーザがチェックを付与するチェックボックスである。例えば、メールアドレスの提供をユーザが拒否する場合、ユーザはメールアドレスのチェックボックスをチェックしない（そのチェックボックスからチェックを外す）。入力フィールド８４は、サービス提供装置３００がデフォルト値として設定した「ｍａｒｋ」を変更する場合に、変更後の愛称（ここでは「Ｔａｒｏ」）を入力するフィールドである。送信ボタン８６が押下されると、ユーザ端末２００のウェブブラウザは、確認画面８０におけるチェックボックス８２のチェック状況（すなわちユーザ情報の提供許否状況）や、入力フィールド８４へ入力されたデータを情報提供装置１０４へ送信する。
【００３８】
図４に戻り、許可項目設定部４６は、ユーザ端末２００から通知された提供許否状況に基づいて、図７に示した形式の変換圧縮データを設定する。許可項目設定部４６は、提供が許可された項目番号に対応するビットを「１」とし、提供が拒否されたもしくは提供がそもそも要求されていない項目番号に対応するビットを「０」としたビット列を設定する。そして、そのビット列の値を、所定値ｎを基数として表現した文字列を要求項目情報７２とする。例えば、図８で示すようにメールアドレスの提供が拒否された場合、ビット列は「０１００００００１１」となるため、ｎ＝６２の場合の要求項目情報７２は「４ｂ」となる。
【００３９】
許可項目設定部４６は、確認画面８０に表示された項目のパラメータについては確認画面８０への入力内容に基づいてパラメータ情報７４を設定する。その一方で、確認画面８０に非表示とされた項目のパラメータについてはそのまま引き継ぐ。例えば、要求項目受付部４２により受け付けられた変換圧縮データのパラメータ情報７４のうち確認画面８０に非表示のパラメータ情報７４を、提供許否状況に基づく変換圧縮データのパラメータ情報７４としてそのまま設定してもよい。図８で示すように愛称が変更された場合、パラメータ情報７４は「１＝１．１，２＝Ｔａｒｏ」と設定される。したがって、図８の提供許否状況から最終的に設定される変換圧縮データは、「４ｂ：１＝１．１，２＝Ｔａｒｏ」となる。
【００４０】
許可項目通知部４８は、許可項目設定部４６において設定された変換圧縮データをユーザ端末２００へ送信する。この変換圧縮データは、図３の第２方法における提供許可情報に対応するものであり、ユーザ端末２００は、情報提供装置１０４から受信した変換圧縮データをサービス提供装置３００へ送信する。
【００４１】
許可項目受付部５２は、サービス提供装置３００から送信された変換圧縮データを受け付ける。ユーザ情報取得部５４は、許否確認部４４と同様に変換圧縮データの解析処理を実行して、変換圧縮データから元の提供許否状況の内容を再生する。具体的には、変換圧縮データの要求項目情報７２の値を２進表記に変換することにより、提供が許可された１以上の項目を特定する。また、変換圧縮データのパラメータ情報７４から、各項目に設定されたパラメータ値を特定する。ユーザ情報取得部５４は、対応関係保持部１０に保持された対応関係を参照して、提供が許可された項目番号の項目名を特定し、その項目名に対応するユーザ情報をユーザ情報ＤＢ１０２から取得する。
【００４２】
例えば、要求項目情報７２が６２進表記で「４ｂ」の場合、その２進表記は「０１００００００１１」であるため、属性交換のバージョン、愛称、使用言語をユーザ情報ＤＢ１０２から取得する。なお、パラメータ情報７４でデータが指定された項目（例えば、図８の確認画面８０で入力された愛称）については、ユーザ情報ＤＢ１０２に保持された情報よりも、パラメータ情報７４での指定内容が優先されてサービス提供装置３００へ通知されてもよい。言い換えれば、ユーザ情報ＤＢ１０２のユーザ情報を、パラメータの設定値に置き換えてもよい。
【００４３】
ユーザ情報提供部５６は、ユーザ情報取得部５４により取得されたユーザ情報をサービス提供装置３００へ送信する。これにあわせて、変換圧縮データに設定された各項目のパラメータ値をサービス提供装置３００へ送信する。ユーザ情報提供部５６は、図６の情報提供要求と同一または対応する形式、例えば、ユーザ情報やパラメータ値を要求項目６２のように「ｖａｌｕｅ」として設定した形式のデータを送信してもよい。
【００４４】
以上の構成による動作を以下説明する。以下では、サービス提供装置３００は第１の情報提供装置１０４ａにアクセスし、ユーザ端末２００は第２の情報提供装置１０４ｂにアクセスすることとする。しかし、複数の情報提供装置１０４の様々な組み合わせにより、ユーザ情報の提供が実現されてよいことはもちろんである。例えば、図示しない第３の情報提供装置の受付処理部３０と、第１の情報提供装置１０４ａの確認処理部４０と、第２の情報提供装置１０４ｂの提供処理部５０とによって、ひとつの情報提供要求をトリガとする一連の情報提供プロセスが分散実行されてもよい。
【００４５】
図９は、実施の形態におけるユーザ情報の提供プロセスを示すシーケンス図である。ユーザ端末２００は、サービス提供装置３００に対してサービスの提供を要求する（Ｓ６０）。サービス提供装置３００は、第１の情報提供装置１０４ａに対してユーザ情報の提供を要求する（Ｓ６２）。第１の情報提供装置１０４ａの要求受付部３２は、その要求（情報提供要求）を受け付け、要求項目設定部３４は、情報提供要求を変換した圧縮データである要求状況圧縮データを設定する（Ｓ６４）。そして、要求項目通知部３６は、要求状況圧縮データをサービス提供装置３００へ送信する（Ｓ６６）。サービス提供装置３００は、要求状況圧縮データをユーザ端末２００へ転送し（Ｓ６８）、ユーザ端末２００は、要求状況圧縮データを第２の情報提供装置１０４ｂへ送信する（Ｓ７０）。
【００４６】
続いて、第２の情報提供装置１０４ｂの要求項目受付部４２は要求状況圧縮データを受け付け、許否確認部４４は、要求状況圧縮データに基づいて確認画面のデータを設定し（Ｓ７２）、そのデータをユーザ端末２００へ送信して確認画面を表示させる（Ｓ７４）。ユーザ端末２００はユーザ情報の提供許否を示す提供許否状況を第２の情報提供装置１０４ｂへ通知する（Ｓ７６）。第２の情報提供装置１０４ｂの許可項目設定部４６は、提供許否状況を受け付け、提供許否状況を変換した圧縮データである許否状況圧縮データを設定し（Ｓ７８）、許可項目通知部４８は許否状況圧縮データをユーザ端末２００へ送信する（Ｓ８０）。ユーザ端末２００は許否状況圧縮データをサービス提供装置３００へ転送し（Ｓ８２）、サービス提供装置３００は許否状況圧縮データを第１の情報提供装置１０４ａへ送信する（Ｓ８４）。
【００４７】
続いて、第１の情報提供装置１０４ａの許可項目受付部５２は、許否状況圧縮データを受け付け、ユーザ情報取得部５４は許否状況圧縮データに基づいてユーザ情報ＤＢ１０２からユーザ情報を取得する（Ｓ８６）。第１の情報提供装置１０４ａのユーザ情報提供部５６は、ユーザ情報およびユーザにより設定されたパラメータ値等をサービス提供装置３００へ送信する（Ｓ８８）。以降、第１の情報提供装置１０４ａから提供されたユーザ情報に基づき、サービス提供装置３００においてサービスの提供可否が決定され、ユーザ端末２００に対するサービス提供が適宜実行される。
【００４８】
本実施の形態の情報提供システム１００によれば、元の情報提供要求や提供許否状況を圧縮した変換圧縮データ（要求状況圧縮データ、許否状況圧縮データ）を装置間で持ち回る。これにより、提供すべきユーザ情報の項目数が多数となる場合でも、ウェブブラウザ等、アプリケーションで取り扱うべきデータ量が削減され、アプリケーションにおける取り扱いデータ量の制限を超過してしまうことを回避できる。また、ネットワークトラヒックも低減できる。すなわち、上述した従来の第１方法で生じる問題を解決できる。
【００４９】
元の情報提供要求や提供許否状況の圧縮について付言する。要求された項目や提供が許可された項目を、項目名そのものでなく項目番号で表すことにより、変換圧縮データのサイズを削減できる。また、項目数をビット長とするビット列（２進文字列）で表すことにより、変換圧縮データのサイズを一層削減できる。さらに、より大きなｎ進文字列に変換することにより、変換圧縮データのサイズをより一層削減できる。
【００５０】
また情報提供システム１００によれば、要求状況圧縮データから元の情報提供要求の内容を特定可能であり、許否状況圧縮データから元の提供許否状況の内容を特定可能である。これにより、元の情報提供要求や提供許否状況を保存する必要がなく、またその保存情報を後に参照する必要がなく、複数の情報提供装置１０４においてユーザ情報の提供に必要な一連のプロセスが分散実行される。すなわち、上述した従来の第２方法で生じる問題を解決できる。
【００５１】
なお、情報提供システム１００においては、従来の第２方法の仕組みに則ってユーザ情報の提供が実現される。すなわち、情報提供システム１００の外部装置であるサービス提供装置３００やユーザ端末２００にとっては、持ち回るデータが変更となるだけであり、従来の第２方法と同様に動作すればよい。言い換えれば、情報提供システム１００にアクセスする外部装置に対して特別な構成を強いることがなく、従来の第２方法で生じる問題を解決できる。
【００５２】
ユーザ情報の提供に必要なプロセスの分散実行について付言する。従来の第２方法では情報提供要求を保存する必要があったため、いわばステートフルな処理態様となり、分散実行が制約されるという問題を生じていた。これに対して、本実施の形態の提案方法においては、情報提供要求や提供許否状況の保存は不要であり、複数の情報提供装置１０４のいずれもが同じ処理を実行できる。いわばステートレスな処理態様となり、分散実行の制約は生じない。これにより、ユーザ情報の提供に必要な一連のプロセスを、より一層効率的に分散実行できる。
【００５３】
また情報提供システム１００によれば、対応関係保持部１０の対応関係において予め設定された項目名だけでなく、サービス提供装置３００で設定されたパラメータ、および、ユーザ端末２００で設定されたパラメータを、変換圧縮データに設定して装置間で持ち回る。これにより、サービス提供装置３００とユーザ端末２００との間で、予め規定されたユーザ情報のみならず任意のパラメータ値を相互に通知することができる。
【００５４】
以上、本発明を実施の形態をもとに説明した。この実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。以下変形例を示す。
【００５５】
上記実施の形態では、ユーザ情報のいずれかの項目に対応するパラメータ情報７４が変換圧縮データ７０に設定されることとした。変形例では、サービス提供装置３００からの情報提供要求に含まれる情報であり、ユーザ情報のいずれの項目にも対応しない任意の情報が変換圧縮データ７０に設定されてもよい。そして、この任意の情報は、そのまま確認画面に表示されてもよい。同様に確認画面において入力された情報であり、ユーザ情報のいずれの項目にも対応しない任意の情報が変換圧縮データ７０に設定されてもよく、そのままサービス提供装置３００へ提供されてもよい。この任意の情報は、例えば、変換圧縮データ７０において、パラメータ情報７４の後に「：任意の文字列」の形式で設定されてもよい。この変形例によれば、サービス提供装置３００とユーザ端末２００との間で、予め規定されたユーザ情報のみならず任意の情報を相互に通知することができる。
【００５６】
上記実施の形態では特に言及していないが、要求項目設定部３４は、複数の情報提供装置１０４間で予め定められた共通の鍵情報（文字列等）を用いて、変換圧縮データ７０（要求状況圧縮データ）を暗号化してもよい。許否確認部４４は、暗号化された要求状況圧縮データを上記共通の鍵情報を用いて復号し、確認画面を設定する。同様に、許可項目設定部４６は、上記共通の鍵情報を用いて、変換圧縮データ７０（許否状況圧縮データ）を暗号化してもよい。ユーザ情報取得部５４は、暗号化された許否状況圧縮データを上記共通の鍵情報を用いて復号し、ユーザ情報を取得する。この場合の暗号アルゴリズムとしては、鍵情報の公開範囲が複数の情報提供装置１０４間に限られること、および、処理時間が短いことが望ましいことから、ＤＥＳやＡＥＳ等の共通鍵方式のアルゴリズムが採用されてもよい。
【００５７】
この変形例によれば、悪意をもつ第三者が変換圧縮データを取得した場合であっても、ユーザ情報の漏洩を防止できる。なお、変換圧縮データ７０における要求項目情報７２の部分は、コード化されており、ユーザ情報の各項目の項目番号および基数ｎが漏洩しない限りは、元データの復元（すなわち要求された項目）の特定は困難である。したがって、暗号化および復号に要する時間を短縮するために、パラメータ情報７４のみを暗号化することとしてもよい。
【００５８】
上記実施の形態では特に言及していないが、複数の情報提供要求のそれぞれをトリガとする処理が、複数の情報提供装置１０４間で並行実行されてもよい。この場合、単一の情報提供装置１０４においては、その受付処理部３０と、確認処理部４０と、提供処理部５０とのそれぞれで、異なる情報提供要求に関する処理が並行実行されてもよい。この変形例によれば、実施の形態の特徴であるステートレスな処理態様を活かして、ユーザ情報の提供に関する一連のプロセスを一層効率的に分散処理できる。さらに言えば、情報提供システム１００のシステムリソースを有効活用して、ユーザ情報の提供処理のスループットを向上させることができる。
【００５９】
上述した実施の形態および変形例の任意の組み合わせもまた本発明の実施の形態として有用である。組み合わせによって生じる新たな実施の形態は、組み合わされる実施の形態および変形例それぞれの効果をあわせもつ。
【００６０】
請求項に記載の各構成要件が果たすべき機能は、実施の形態および変形例において示された各構成要素の単体もしくはそれらの連携によって実現されることも当業者には理解されるところである。
【符号の説明】
【００６１】
１０  対応関係保持部、  ３２  要求受付部、  ３４  要求項目設定部、  ３６  要求項目通知部、  ４２  要求項目受付部、  ４４  許否確認部、  ４６  許可項目設定部、  ４８  許可項目通知部、  ５２  許可項目受付部、  ５４  ユーザ情報取得部、  ５６  ユーザ情報提供部、  １００  情報提供システム、  １０２  ユーザ情報ＤＢ、  １０４  情報提供装置、  ２００  ユーザ端末、  ３００  サービス提供装置。
【図１】
2011209862.tif 000003
【図２】
2011209862.tif 000004
【図３】
2011209862.tif 000005
【図４】
2011209862.tif 000006
【図５】
2011209862.tif 000007
【図６】
2011209862.tif 000008
【図７】
2011209862.tif 000009
【図８】
2011209862.tif 000010
【図９】
2011209862.tif 000011