JP2016085676A - 個人情報口座バンキング - Google Patents

Abstract

【課題】事業者がサービス提供に必要な情報と顧客が開示を許可する情報とを管理し、必要以上に個人情報が開示されることを回避する。【解決手段】顧客がサービスを受けようとする事業者のウェブページにアクセスすると、顧客端末の画面にサービス提供のために必要な個人情報を開示するための個人情報開示ボタンが表示される。顧客が個人情報開示ボタンを押下すると、事業者サーバは、個人情報口座管理サーバに保管された顧客の個人情報取得要求を送信する。取得要求を受信した個人情報口座管理サーバは、事業者情報ＤＢから、サービスに必要な個人情報の項目を読み出し、その個人情報の項目を元に個人情報ＤＢから個人情報を抽出する。そして、その個人情報の項目が列挙された開示情報選択画面を生成して顧客端末に送信する。顧客は、表示された画面から開示を許可する個人情報を選択する。個人情報口座管理サーバは、選択された情報を事業者サーバに送信する。【選択図】図１

Description

本発明は、個人情報の開示方法に関し、特に、個人情報を管理する個人情報口座管理サーバ、個人情報管理システム及びそのプログラムに関する。

従来から、インターネット上で、様々なサービスが受けられることが可能となっている。この場合、サービスを受けようとする利用者は、ネットワークを介して、サービスを提供する事業者に自身の個人情報を入力することで、サービス事業者との認証が成立し、目的とするサービスが受けられる。

ところで、近年、ハッキング技術の高度化により、インターネットサービスに登録した情報が漏洩する事案が多発し、個人情報の取り扱いに対する危機意識が高まっているが、具体的な対応策が浸透しているとは言えない。事業者では、自社で認証システムは導入しているものの、ワンタイムパスワードや二要素認証等の高度な認証技術が採用されているとはいえない。

そこで、利用者の個人情報を管理する仲介サーバを設けて、仲介サーバ経由で各サービス事業者に個人情報を提供する技術が知られている。

例えば、特許文献１には、利用者が提供を受けたいサービスを指定すると、仲介サーバが、サービス提供のために必要な個人情報の項目を調べ、属性情報データベースから開示が必要な個人情報を抽出し、当該抽出された個人情報に基づきサービス提供のための条件を満たすか否かを判定し、条件を満たす場合にのみ、抽出した個人情報を送信する個人属性情報提供方法が開示されている。また、特許文献２には、個人情報の本人の意思に基づいて決定される特定の個人情報保有機関から特定の第三者機関に個人情報を送信する個人情報提供装置が記載されている。

特開２００８−０４６７３３号公報 特開２０１０−１５２４９２号公報

上記の特許文献１、２に開示された方法によれば、不必要な場合にまで個人情報が開示されることを防止することができる。また、個人情報保有機関を本人の意思に基づいて決定できる。しかしながら、サービス提供者が要求する情報の中には利用者が開示したくない情報が含まれることがあり、この場合、事業者側の必要情報と利用者側の開示情報との間で乖離が生じ、また依然として、必要以上に個人情報が開示されてしまうという課題があった。また、新たにシステムを構築して仲介サーバを設けたり、個人情報保有をする機関を設立したりしなければならないため、多くの時間とコストを要する。さらには、新たに参入する事業者が個人情報を管理する場合、個人情報の取り扱いに関する実績と信頼性が低いため、利用者は不安を覚える可能性もある。そのため、多くの個人情報を堅牢性高く管理している金融機関がセキュリティの一翼を担い、利用者（顧客）及び、一般事業者に対する個人情報管理サービスを提供することが考えられる。

本発明は、このような状況に鑑みなされたものであり、事業者がサービス提供に必要な情報と、顧客が開示を許可する情報とを管理し、必要以上に個人情報が開示されることを回避するための金融機関による個人情報管理システムを提供することを目的とする。

上記課題を解決するため、本発明の個人情報口座管理サーバは、以下のような解決手段を提供する。

顧客端末と、顧客にサービスを提供する事業者の事業者サーバとに、ネットワーク経由で接続される金融機関の個人情報口座管理サーバであって、前記事業者が提供するサービスごとに必要な前記顧客の個人情報の項目が前記事業者のウェブサイトのネットワークアドレスに対応付けて登録される事業者情報データベースと、前記顧客により登録され、前記顧客の個人情報が記憶される個人情報データベースと、前記事業者サーバから前記サービスに必要な個人情報の取得要求を受信すると、前記事業者情報データベースと前記個人情報データベースを参照し、前記サービスに必要な個人情報を抽出する必要情報抽出部と、前記抽出された前記個人情報の中から顧客が開示を許可する個人情報の項目の選択を促す開示情報選択画面を生成する個人情報開示選択部と、前記顧客によって前記事業者に開示することが許可された個人情報を読み出し、前記取得要求のあった前記事業者サーバへ送信指示する制御部と、を備えることを特徴とする。

また、前記事業者情報データベースは、前記サービスの種別ごとに前記必要な個人情報を記憶することを特徴とする。

また、前記制御部は、前記顧客端末に対し、前記事業者情報データベースに登録されている前記サービスごとに必要な前記顧客の個人情報のうち、開示を許可する個人情報の選択入力を促す開示情報選択画面を送信し、前記顧客端末により前記選択入力された情報に基づき、前記個人情報データベースに登録された個人情報の中から前記開示を許可された項目を特定することを特徴とする。

また、前記事業者情報データベースは、前記サービスの利用ごとにカウントするアクセス数を記憶し、前記アクセス数を前記開示情報選択画面に表示することを特徴とする。

また、前記個人情報データベースは、前記個人情報の変更履歴を記憶し、前記変更履歴を前記開示情報選択画面に表示することを特徴とする。

また、前記個人情報口座管理サーバは、前記個人情報の前記事業者への送信履歴である口座明細情報を記憶する口座明細情報データベースをさらに備え、前記制御部は、前記顧客端末からの要求に基づき、前記口座明細情報を送信することを特徴とする。

また、前記制御部は、前記顧客端末からの要求に基づき、前記口座明細情報に記憶された前記個人情報の消去要求を、当該個人情報を提供した事業者サーバに対して送信することを特徴とする。

また、本発明の別の態様では、顧客端末と、顧客にサービスを提供する事業者の事業者サーバと、前記顧客端末と前記事業者サーバとネットワーク経由で接続される金融機関の個人情報口座管理サーバと、を備える個人情報管理システムであって、前記個人情報口座管理サーバは、前記事業者が提供するサービスごとに必要な前記顧客の個人情報の項目が前記事業者のウェブサイトのネットワークアドレスに対応付けて記憶される事業者情報データベースと、前記顧客により登録され、前記顧客の個人情報が記憶される個人情報データベースと、を備え、前記事業者サーバから前記サービスに必要な個人情報の取得要求を受信すると、前記事業者情報データベースと前記個人情報データベースとを参照し、前記サービスに必要な個人情報を抽出し、前記抽出された前記個人情報の中から顧客が開示を許可する個人情報の項目の選択を促す開示情報選択画面を生成し、前記顧客によって前記事業者に開示することが許可された個人情報を読み出し、前記取得要求のあった前記事業者サーバへ送信することを特徴とする。

また、本発明の別の態様では、顧客端末と、顧客にサービスを提供する事業者の事業者サーバとネットワーク経由で接続される金融機関の個人情報口座管理サーバのプログラムであって、前記事業者が提供するサービスごとに必要な前記顧客の個人情報の項目を前記事業者のウェブサイトのネットワークアドレスに対応付けて事業者情報データベースに記憶する手段と、前記顧客により予め登録される前記顧客の個人情報か個人情報データベースに記憶する手段と、前記事業者サーバから前記サービスに必要な個人情報の取得要求を受信すると、前記事業者情報データベースと前記個人情報データベースとを参照し、前記サービスに必要な個人情報を抽出する手段と、前記抽出された前記個人情報の中から顧客が開示を許可する個人情報の項目の選択を促す開示情報選択画面を生成する手段と、前記顧客によって開示が許可された個人情報を読み出し、前記取得要求のあった前記事業者サーバに送信する手段として、コンピュータを機能させることを特徴とする。

本発明によれば、事業者がサービス提供に必要な情報と、顧客が開示を許可する情報とを管理し、必要以上に個人情報が開示されることを回避するための金融機関による個人情報管理システムを提供することができる。

本発明の実施の形態に係る個人情報管理システムのイメージ図である。 本発明の実施の形態に係る個人情報管理システムの機能ブロック図である。 図２に示す個人情報ＤＢのイメージ図である。 図２に示す事業者情報ＤＢのイメージ図である。 本発明の実施の形態に係る個人情報管理システムの処理動作を示すシーケンス図である。 情報端末の承認画面のイメージ図である。 口座明細に利用状況が記載されたイメージ図である。 本発明の実施の形態に係る個人情報管理システムの個人情報口座管理サーバの処理動作を示すフローチャートである。

以下、添付図面を参照して、本発明を実施するための形態（以下、本実施形態と言う）について詳細に説明する。なお、実施形態の説明の全体を通して同じ要素には同じ番号または符号を付している。

図１は、本実施形態に係る個人情報管理システムのイメージ図である。以下では、上記のシステムを「本システム」と呼ぶことにする。

本システムは、顧客とサービス事業者との間に個人情報を管理する金融機関を仲介させ、金融機関が管理運営する個人情報口座管理サーバにより、個人情報を一元化し、サービス事業者が開示を必要とし、かつ、顧客が開示を許可した個人情報のみをサービス事業者に提供するものである。このため、顧客は、予め自身が所有するＰＣやスマートフォン等の端末を操作して個人情報口座管理サーバに個人情報を入力、もしくは金融機関の窓口等から個人情報を登録する。次に、個人情報を受領した個人情報口座管理サーバは、個人情報データベース（以降、個人情報ＤＢと呼ぶ）にその個人情報を保管する。

次に、サービス事業者（事業者サーバ）は、本システムによる個人情報の提供サービスを享受するために、個人情報口座管理サーバに事業者情報を登録し、サービスに必要な顧客の個人情報項目を送信する。ここでいう事業者情報とは、登録する事業者が正規の会社であり、かつ、金融機関と取引のある会社であるか否かを認証するために必要な情報であり、例えば、事業者名、住所、電話番号、資本情報、電子証明書等が、金融機関での審査を経て登録される。

個人情報口座管理サーバは、サービス事業者の認証が成立すると、事業者が提供するサービスごとに必要な顧客の個人情報の各項目をサービス事業者のウェブサイトのネットワークアドレス（ＵＲＬ（Uniform Resource Locator））に対応付けて登録する。このことにより本システムが個人情報を提供するための利用環境が整う。

以下の説明では、顧客が、顧客端末を操作してサービス事業者のサイト（ＥＣ:Electronic Commerceサイト）へアクセスし、ＥＣサイトのウェブページにアクセスして商品購入サービスを利用する場合について例示するが、他のサービスでも基本的に同様である。

顧客は、自身の情報端末を操作し、サービスを受けるウェブページ（事業者サーバ）にアクセスし、購入する商品を選択し、決済画面（一般的には、サービス申込画面）に移行する。このとき、事業者が金融機関の個人情報口座管理サーバに登録済みの場合、この画面上に「個人情報開示ボタン」が表示される。顧客がこの個人情報開示ボタンを押下すると、事業者サーバは、顧客の個人情報を管理している個人情報口座管理サーバに、その顧客の個人情報取得要求を送信する。

個人情報取得要求を受信した個人情報口座管理サーバは、送信元が、登録されている正規のサービス事業者であるか否か判定し、正規のサービス事業者であると確認されると、顧客端末に当該金融機関のログイン画面を表示し、顧客のログインが正常に完了した場合、事業者情報データベース（以降、事業者情報ＤＢと呼ぶ）から、その事業者が提供するサービスに必要な個人情報（以下、必要情報と呼ぶ）の項目を読み出し、その必要情報の項目を元に個人情報データベース（以降、個人情報ＤＢと呼ぶ）からその顧客の個人情報を抽出する。そして、その個人情報の開示許可項目を顧客に選択入力させるための「開示情報選択画面」を生成して顧客端末に送信する。

顧客は、顧客端末に表示された開示情報選択画面により、開示を許可する個人情報の項目と開示を許可しない個人情報の項目とをチェックボックス等によって選択入力する。顧客による選択入力を受けた個人情報口座管理サーバは、開示許可を得た個人情報の項目を抽出して、その情報を事業者サーバに送信する。そして、サービス事業者は、取得した個人情報に基づき顧客にサービスを提供する。

このようにすることで、金融機関は、既に構築した堅牢性の高いセキュリティシステムを活用し、金融資産の口座と同じように、顧客の個人情報を「個人情報口座」として保管し、口座保有者である利用者の選択に基づいて、顧客が開示を許可した個人情報のみをサービス事業者に送信する新たな個人情報管理サービスを提供することができる。

図２は、本実施形態に係る個人情報管理システムの機能ブロック図である。本システムは、顧客端末１０と、顧客にサービスを提供する事業者が管理運営する事業者サーバ３０と、顧客端末１０及び事業者サーバ３０にインターネット等の公衆回線又は専用回線のネットワーク経由で接続される個人情報口座管理サーバ２０とを備える。

（個人情報口座管理サーバの構成）
個人情報口座管理サーバ２０は、典型的には、通信部２１と、必要情報抽出部２２と、個人情報開示選択部２３と、制御部２４と、個人情報ＤＢ１００と、事業者情報ＤＢ２００と、口座明細情報ＤＢ３００とから構成される。

通信部２１は、顧客端末１０または事業者サーバ３０との通信を行う際の通信インタフェースを司り、個人情報口座管理サーバ２０が採用するプロトコル（例えば、インターネットであればＴＣＰ／ＩＰ）に準拠した通信を行う。

必要情報抽出部２２は、事業者サーバ３０からサービスに必要な個人情報の取得要求を受信すると、事業者情報ＤＢ２００と個人情報ＤＢ１００を参照し、サービスに「必要」な個人情報（必要情報）を抽出する。具体的には、事業者情報ＤＢ２００に格納されているサービスごとに必要な個人情報の項目を抽出し、その個人情報の項目に基づき、個人情報ＤＢ１００から該当の個人情報を取り出す。なお、必要情報には、サービスの提供に不可欠な必須情報と、必須ではないがサービス事業者にとっては開示されると望ましいオプション情報を含むものとする。

個人情報開示選択部２３は、必要情報抽出部２２によって、抽出された個人情報の中から顧客が開示を許可する個人情報の項目の選択を促す開示情報選択画面を生成し、顧客が顧客端末１０を操作することにより選択される個人情報の項目を取り込むＵＩ（User Interface）を提供する。詳細は後述する。

制御部２４は、事業者サーバ３０からサービスに必要な個人情報の取得要求を受信すると、顧客が金融機関のログイン画面で正規に認証された場合には、事業者情報ＤＢ２００と個人情報ＤＢ１００を参照し、サービスに必要な個人情報であって、かつ顧客によって事業者に開示することが許可された個人情報を読み出し、取得要求のあった事業者サーバ３０へ送信指示をする制御を行う。また、制御部２４は、事業者情報ＤＢ２００により、サービスの「種別」ごとに必要な個人情報の管理を行う。サービスの種別とは、サービスの種類をカテゴリ別に分類したものであり、例えば、商品購入サービス、配送サービス、ローン契約サービス、レンタカー予約サービス、情報配信サービス等、様々な種類がある。

また、制御部２４は、顧客端末１０に対し、開示情報選択画面を送信し、予め登録された個人情報のうち、顧客端末１０により選択入力された情報に基づき登録された個人情報の中から開示を許可された項目を特定する制御を行う。

なお、個人情報口座管理サーバ２０は、サービス事業者への個人情報の送信履歴である口座明細情報を備えることが好ましい。口座明細情報は、口座明細情報ＤＢ３００に記憶される。この場合、制御部２４は、顧客端末１０の要求に基づき、口座明細情報を送信する制御を行う。また、顧客端末１０の要求に基づき、口座明細情報に記憶された個人情報の消去要求を、当該個人情報を提供した事業者サーバ３０に対して送信する制御を行う。口座明細情報について詳細は後述する。

個人情報ＤＢ１００には、顧客により登録された顧客の個人情報が記憶されている。例えば、図３に示すように、氏名、郵便番号、住所、電話番号、生年月日、性別、職業、年収等が、個人情報の項目として登録されている。個人情報ＤＢ１００に格納される個人情報は、金融機関の既存の顧客（例えば、銀行であれば、口座開設者）であれば、口座開設時に登録されているものを利用してもよい。もちろん、顧客は、顧客端末からあるいは金融機関の窓口等で、本人認証後に、個人情報の追加、編集をすることも可能である。

また、個人情報ＤＢ１００には、個人情報の変更履歴も記憶するようにしてもよい。具体的には、例えば、個人情報登録後に、顧客が転居等を行い、住所、電話番号等が変更になった場合に、住所等の変更を行うが、変更前の個人情報も記憶しておく。このように変更履歴も記憶することで、最新の情報であるかどうかを顧客やサービス事業者が確認することができ、必要に応じて追跡調査も可能になる。また、変更前の個人情報を必要とするサービス事業者、例えば、商品購入サイトでは、変更前の住所等が開示されることによって、変更前後の住所の地域に関する情報等を顧客に提供することが可能となるため、商品の販売促進にも繋がる。もちろん、変更前の住所を開示するかどうかも顧客が選択できるものとする。なお、変更前の個人情報を開示するかどうかも顧客が選択できるようにしてもよい。例えば、結婚して姓を変更した場合、免許が必要なレンタカーサービス等のように、変更後の姓が必要なサービス以外については、変更前の旧姓を開示するようにしてもよい。

事業者情報ＤＢ２００は、サービス事業者が提供するサービスごとに必要な顧客の個人情報の項目が、事業者のウェブサイトのネットワークアドレス（ＵＲＬ）に対応付けて登録されている。例えば、図４（ａ）に示すように、事業者情報ＤＢ２００には、サービス種別、そのサービス提供の情報が開示されているＵＲＬ（利用者がサービスを受けるためにアクセスするＵＲＬ）、サービスに必要となる個人情報項目がＵＲＬに対応付けて登録されている。なお、図示は省略するが、必要情報の各項目には、必須情報であるか、オプション情報であるかの情報が付加される。

事業者情報ＤＢ２００は、サービス事業者を種別に分けて、必要情報を登録するようにしてもよい。図４（ｂ）に図示するように、必要情報には、サービスの種別ごとに、共通で必要となる個人情報項目（共通項目）が登録され、その他、個別のサービス事業者によって必要となる個人情報項目（個別項目）が分けて登録されている。共通項目は、その種別のサービス事業者にとって必須の情報であり、個別項目は、特定の事業者にとって必須情報である場合もあるが、通常は、オプション情報である。なお、この場合も図示は省略するが、個別項目の各項目には、必須であるか又はオプション情報であるかの情報が付加されているものとする。

例えば、図４（ｂ）で図示する例では、サービス種別が商品購入の場合、２つのＵＲＬが登録されているが、個人情報の共通項目は、「氏名、郵便番号、住所、電話番号」であり、ＵＲＬ１１のサービス事業者では、さらに個人情報の個別項目として、「メールアドレス」を必要としている。一方、ＵＲＬ１２のサービス事業者では、さらに個人情報の個別項目として「電話番号２」を必要としている。

上記の本システムの機能ブロックの構成は、あくまで一例であり、一つの機能ブロック（データベース及び機能処理部）を分割したり、複数の機能ブロックをまとめて一つの機能ブロックとして構成したりしてもよい。各機能処理部は、装置に内蔵されたＣＰＵ（Central Processing Unit）が、ＲＯＭ（Read Only Memory）、フラッシュメモリ、ＳＳＤ(Solid State Ｄrive)、ハードディスク等の記憶装置に格納されたコンピュータ・プログラムを読み出し、ＣＰＵにより実行されたコンピュータ・プログラムによって実現される。すなわち、各機能処理部は、このコンピュータ・プログラムが、記憶装置に格納されたデータベース（ＤＢ;Ｄata Base)やメモリ上の記憶領域からテーブル等の必要なデータを読み書きし、場合によっては、関連するハードウェア（例えば、入出力装置、表示装置、通信インタフェース装置）を制御することによって実現される。また、本発明の実施形態におけるデータベースは、商用データベースであってよいが、単なるテーブルやファイルの集合体をも意味し、データベースの内部構造自体は問わないものとする。

（個人情報管理システムの処理動作）
図５は、本実施形態に係る個人情報管理システムの処理動作を示すシーケンス図である。ここでは、予め、個人情報口座管理サーバ２０のデータベース（個人情報ＤＢ１００、事業者情報ＤＢ２００）に顧客の個人情報及び事業者情報が登録されているものとする。以下、事業者サイトがＥＣサイトである場合について説明する。

顧客は、顧客端末１０を操作することにより、サービス提供を受ける事業者サイトの事業者サーバ３０にアクセスし、購入を希望する商品を選択して商品購入決済の要求を行う（ステップＳ１１）。このとき表示される決済画面には、個人情報口座管理サーバ２０にアクセスするための情報がリンクされている。そして、顧客が決済画面から個人情報開示ボタンを押下すると、商品購入決済要求を受信した事業者サーバ３０は、要求のあった顧客の個人情報を取得するために、個人情報口座管理サーバ２０にリンクし（ステップＳ１２）、要求のあった顧客のユーザＩＤをインデックスにして、個人情報を取得する。

個人情報口座管理サーバ２０は、サービス事業者のＵＲＬに基づき、リンク元のサービス事業者のＵＲＬの認証を行う（ステップＳ１３）。サービス事業者の認証は、事業者情報の登録の有無（別途金融機関に登録済みの事業者情報ＤＢ）により判定される。サービス事業者の認証が成立すると（ステップＳ１３“ＹＥＳ”）、個人情報口座管理サーバ２０は、顧客端末１０に、ログイン画面を表示させる（ステップＳ１４）。続いて、顧客は、顧客端末１０に表示されているログイン画面に、予め登録済みのログイン情報（ログインＩＤ，パスワード等）を入力して送信する（ステップＳ１５）。一方、サービス事業者のＵＲＬが登録されていない場合（ステップＳ１３“ＮＯ”）は、個人情報口座管理サーバ２０は、事業者サーバ３０へ、登録されていないことを示すエラー画面を送信し、顧客端末１０に表示させる（ステップＳ１６）。

次に、個人情報口座管理サーバ２０は、顧客端末１０によって入力されたログイン情報の認証を行う（ステップＳ１７）。顧客端末１０の認証が成立した場合（ステップＳ１７“ＹＥＳ”）、個人情報口座管理サーバ２０は、個人情報口座管理サーバ２０を介しての当該事業者のウェブサイトのアクセス数を格納したアクセスカウンタを更新する（ステップＳ１８）。続いて、個人情報口座管理サーバ２０は、事業者サーバ３０が必要とする個人情報の項目が登録されている事業者情報ＤＢ２００を参照し、その項目に基づいて、個人情報ＤＢ１００から該当の個人情報を取り出し、その個人情報が列挙された開示情報選択画面を生成し、顧客端末１０に表示させて顧客に選択入力を促す（ステップＳ１９）。なお、顧客端末１０の認証が不成立の場合（ステップＳ１７“ＮＯ”）、顧客端末１０へ認証が失敗したことを示すエラー画面を顧客端末１０に表示し、再度のログイン情報の入力を促す（ステップＳ２０）。

認証成立後、顧客端末１０は、開示情報選択画面に列挙された個人情報の中から開示を許可する項目を選択する（ステップＳ２１）。開示情報選択画面には、例えば、図６に示すように、サービスごとに必要な個人情報の項目が一覧で表示される。なお、個人情報の項目一覧の中で、サービス事業者がサービス提供に必須な項目は、例えば、星印を付して強調表示される。開示情報選択画面を確認した顧客は、開示を許可する個人情報の項目にチェックマークを付し、決定ボタンを押下することで、個人情報口座管理サーバ２０へ開示情報が送信される。ただし、必須項目のチェックマークは外すことはできないものとする。また、顧客は、事業者からの個人情報の開示要求が一般的な同業者と比較して、個人情報の項目を余分に要求しているか（共通項目以外の項目を要求しているか）を確認することができる。なお、共通項目以外の項目を開示要求している理由（例えば、その開示要求に応えると、なんらかの特典が付与される等）を事業者ＤＢに登録し、開示情報選択画面に表示するようにしてもよい。このようにすることで、顧客は、開示要求の理由に応じて、その項目の個人情報を開示するかどうかを選択することもできる。

また、顧客が、別途、正規の本人確認を受けた後に個人情報を変更し、変更前の情報も個人情報ＤＢに保管している場合、開示情報選択画面において、変更のある項目に「変更有り」ボタンが表示される。顧客がこの「変更有り」ボタンを押下すると、その項目の変更前の情報が表示される。例えば、結婚に伴う姓の変更や、引っ越しに伴う住所等の変更履歴が保管されていると（保管されるのは所定期間内の変更に限定してもよい）、氏名、住所の項目欄に「変更有り」ボタンが表示される。さらに顧客が「変更有り」ボタン押下後に表示される変更前の情報に対しても開示許可をチェックすると、チェックされた項目の変更前の情報も事業者サーバに送信される。

このように制御することで、顧客が開示を許可しない個人情報については、事業者サーバ３０へ送信されないため、顧客の意志が反映された個人情報の開示が可能になる。また、事業者がサービス提供に必要な情報と、顧客が開示を許可する情報とを管理することで、必要以上に個人情報が開示されることを回避することができる。なお、開示情報選択画面の個人情報の項目一覧に、サービス事業者のサービス提供等に役立つ情報をオプション情報として表示させてもよい。例えば、趣味欄を設け、趣味一覧をラジオボタン等で選択させることによって、事業者サーバ３０は、顧客の趣味が分かるため、以降のサービス提供に役立つ。

なお、前述したアクセス数を格納したアクセスカウンタは、図６の開示情報選択画面上に、利用者数として表示してもよい。アクセスカウンタは、個人情報口座管理サーバ２０を介してサービスを１回利用するごとにカウントアップして、そのウェブサイトの累積アクセス数を示すカウンタである。顧客は、アクセスカウンタを参照することで、アクセス数が多いサービス事業者は信頼性が高い業者であると推定することができる。なお、アクセス数に基づいて、サービス事業者の評価情報を表示してもよい。

説明を図５に戻す。個人情報口座管理サーバ２０は、顧客端末１０から受信した個人情報の開示情報を事業者サーバ３０に送信するとともに（ステップＳ２２）、項目別の「変更有り」情報と「変更日時情報」を含む個人情報の開示履歴を顧客ごとに格納する口座明細情報ＤＢ３００に記録する（ステップＳ２３）。口座明細情報ＤＢ３００により、預金口座の通帳のように、個人情報のサービス事業者への送信履歴（開示履歴）を時系列に表示することができる。口座明細情報は、顧客端末１０の画面に表示可能であり、この口座明細情報画面には、図７に示すように、開示履歴として、送信日、サービス種別、開示先の情報が表示される。

顧客は、今後利用する予定のないサービス事業者のサーバに、自らの個人情報をいつまでも残しておくのは、情報流出等の恐れがあるため不安を覚えることがある。そのため、図７に示す口座明細情報画面の開示履歴ごとに「消去要求ボタン」を設け、顧客がそのボタンを押下することで、個人情報口座管理サーバ２０から、事業者サーバ３０へ個人情報の消去要求が送られるようにしてもよい。実際、事業者がその消去要求を実行し、金融機関に消去完了通知を送信することで、そのことが口座明細情報画面に表示されるようにしてもよい。

図５に戻り、事業者サーバ３０は、個人情報口座管理サーバ２０から顧客の開示情報を受信し（ステップＳ２４）、開示情報を元に商品販売のための必要な認証を行い、顧客端末１０へ通知する（ステップＳ２５）。そして、顧客端末１０は、商品販売の承認通知（決済完了）を受領する（ステップＳ２６）ことで、商品購入サービスの一連の流れが終了する。

（個人情報口座管理サーバの処理動作）
図８は、本発明の実施の形態に係る個人情報管理システムの個人情報口座管理サーバの処理動作を示すフローチャートである。

顧客は、前述したように、顧客端末１０を操作することにより、サービス提供を受ける事業者サイトの事業者サーバ３０にアクセスし、ウェブページ（専用画面）の商品一覧の中から購入を希望する商品を選択して商品購入決済の要求を行う。そして、事業者サーバ３０は、要求のあった顧客の個人情報を個人情報口座管理サーバ２０から取得要求を行う。

個人情報口座管理サーバ２０の制御部２４は、事業者サーバ３０から個人情報開示要求を受信すると（ステップＳ３１）、サービス事業者のＵＲＬに基づき、サービス事業者の認証を行う（ステップＳ３２）。なお、サービス事業者の認証は、事業者情報の登録の有無により判定される。

リンク元（事業者サーバ３０）ＵＲＬが登録されている場合（ステップＳ３２“ＹＥＳ”）、制御部２４は、顧客端末１０に個人情報開示選択画面を提供するためのログイン画面を表示する（ステップＳ３３）。一方、リンク元ＵＲＬが登録されていない場合（ステップＳ３２“ＮＯ”）、事業者サーバ３０の画面に登録されていないことを示す認証エラーである旨のエラー画面表示を送信する（ステップＳ４０）。

続いて、制御部２４は、顧客端末１０によって入力されたログイン情報（例えば、ログインＩＤ、パスワード）を受信すると、顧客ごとのログイン情報が格納されている顧客情報ＤＢ（図示省略）に基づいて、ログイン情報の判定を行う（ステップＳ３４）。なお、ステップＳ３２と、ステップＳ３３，Ｓ３４は、処理順序を逆にしてもよい。

顧客端末１０のログイン情報の認証が成立した場合（ステップＳ３４“ＹＥＳ”）、制御部２４は、サービスの利用者数を格納しているアクセスカウンタを更新する（ステップＳ３５）。そして、必要情報抽出部２２は、サービスを提供する事業者サーバ３０から、サービス事業者が必要とする個人情報の項目を事業者情報ＤＢ２００から抽出する（ステップＳ３６）。そして、その項目に基づいて、個人情報ＤＢ１００から該当の個人情報を読出し（ステップＳ３７）、個人情報開示選択部２３へ送る。

一方、顧客端末１０のログイン情報の認証が不成立の場合（ステップＳ３４“ＮＯ”）、顧客端末１０の画面へ認証が不成立であることを示すエラー画面を表示し、再認のログイン情報の入力を促す（ステップＳ４１）。

そして、該当の個人情報を受信した個人情報開示選択部２３は、個人情報の項目が列挙された開示情報選択画面を生成し、顧客端末１０の画面に表示させ、顧客が開示を許可する個人情報の選択を促す（ステップＳ３８）。次に、顧客によって選択された開示情報を読み出し、事業者サーバ３０にその開示情報を送信する（ステップＳ３９）。

（実施形態の効果及び変形例）
以上のように、本システムによれば、個人情報口座管理サーバが個人情報を一元的に保管し、サービス事業者がサービス提供に必要な個人情報を個人情報口座管理サーバに登録し、顧客がサービスの提供を受ける際に、サービス事業者に対して開示を許可する個人情報を顧客に選択させることで、サービス事業者の必要情報と顧客の開示情報を管理し、必要以上の個人情報の開示を回避してセキュリティを高めることができる。また、個人情報の管理を堅牢性高いシステムを構築している金融機関が行うことで、個人情報を開示する側の顧客にとって安心感が高まる。

また、事業者情報データベースは、サービスの種別ごとに必要な個人情報を記憶することができるので、個人情報口座管理サーバは、事業者情報をサービス種別ごとに管理することが可能となり、サービスの種別ごとの共通項目と事業者ごとの個別項目に分けて登録することができる。すなわち、共通項目が１つにまとめられるため、事業者情報データベースの容量が節約され、必要情報を抽出する時間を短縮することができる。また、事業者においても、必要情報の登録をする際にサービス種別ごとの共通項目が選択できれば、登録にかかる手続が簡略化できる。

また、個人情報口座管理サーバは、顧客端末に対し、登録された個人情報のうち、開示を許可する個人情報の選択入力を促す開示情報選択画面を送信する。そして、顧客の選択に基づき、個人情報データベースに登録された個人情報の中から開示を許可する項目を特定することで、必要以上に個人情報が開示されることを回避することができる。また、顧客が事前に個人情報を開示可能な事業者を指定しておく方法の場合、事前に指定していない事業者に対しては本システムのサービスが受けることができないので、その都度別途登録する必要があったり、事業者に対する信頼性の低下や顧客の個人情報の開示方針の変更等にすぐに対応できず、使い勝手が悪くなる場合がある。本システムでは、顧客が事業者のサービスを実際に受けようとするごとに開示する個人情報を確認することで、利便性が上がると同時に、顧客の開示方針の変更にも柔軟に対応できる。

また、事業者情報データベースは、サービスの利用ごとにカウントするアクセス数を記憶し、開示情報選択画面に表示する。顧客は、このアクセス数を参照することで、サービス事業者の信頼性を推定することができる。また、継続してサービスを利用するかどうかわからない事業者や知名度が高くない事業者でも、安心して個人情報を提供するかどうかの判断が可能となる。

また、個人情報データベースは、個人情報の変更履歴を記憶し、変更履歴を開示情報選択画面に表示することで、個人情報が最新の情報であるかどうかを顧客やサービス事業者が確認することができる。また、個人情報の変更の際、各事業者それぞれに変更に伴う届出を行うのではなく、本サービスにおいて、一度変更手続きをすれば各事業者に開示される個人情報が変更され、サービスを利用する顧客の利便性が高まる。

また、個人情報口座管理サーバは、個人情報の事業者への送信履歴である口座明細情報を記憶する口座明細情報データベースをさらに備え、顧客端末からの要求に基づき、口座明細情報を送信する。このようにすることで、顧客は、預金口座の通帳のように、個人情報のサービス事業者への送信履歴が時系列に表示することができるため、いつ、どの事業者に個人情報を開示したかを容易にチェックできる。また、必ず個人情報開示の確認を都度求める事業者と、都度確認を求めなくてよいとする事業者（個人情報の送信履歴をいつでもチェック可能という管理で良しと判断できる事業者）とに区別して管理することを顧客が選択でき、設定できるようしてもよい。このようにすることで、信頼性の高い事業者（例えば、自治体や銀行等）は、都度、顧客に開示する個人情報を確認させる手間を省くことができる。

また、個人情報口座管理サーバは、顧客端末からの要求に基づき、口座明細情報に記憶された個人情報の消去要求を、当該個人情報を提供した事業者サーバに対して送信する。このようにすることで、顧客は、今後利用する予定のないサービス事業者のサーバに、自らの個人情報がいつまでも残ることを防止することができる。

以上、実施形態を用いて本発明を説明したが、本発明の技術的範囲は上記実施形態に記載の範囲に限定されないことは言うまでもない。上記実施形態に、多様な変更または改良を加えることが可能であることが当業者に明らかである。またその様な変更または改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。

１０ 顧客端末
２０ 個人情報口座管理サーバ
２１ 通信部
２２ 必要情報抽出部
２３ 個人情報開示選択部
２４ 制御部
３０ 事業者サーバ
１００ 個人情報データベース（個人情報ＤＢ）
２００ 事業者情報データベース（事業者情報ＤＢ）
３００ 口座明細情報データベース（口座明細情報ＤＢ）

Claims (9)

1. 顧客端末と、顧客にサービスを提供する事業者の事業者サーバとに、ネットワーク経由で接続される金融機関の個人情報口座管理サーバであって、
   前記事業者が提供するサービスごとに必要な前記顧客の個人情報の項目が前記事業者のウェブサイトのネットワークアドレスに対応付けて登録される事業者情報データベースと、
   前記顧客により登録され、前記顧客の個人情報が記憶される個人情報データベースと、
   前記事業者サーバから前記サービスに必要な個人情報の取得要求を受信すると、前記事業者情報データベースと前記個人情報データベースを参照し、前記サービスに必要な個人情報を抽出する必要情報抽出部と、
   前記抽出された前記個人情報の中から顧客が開示を許可する個人情報の項目の選択を促す開示情報選択画面を生成する個人情報開示選択部と、
   前記顧客によって前記事業者に開示することが許可された個人情報を読み出し、前記取得要求のあった前記事業者サーバへ送信指示する制御部と、
   を備えることを特徴とする個人情報口座管理サーバ。
2. 前記事業者情報データベースは、前記サービスの種別ごとに前記必要な個人情報を記憶することを特徴とする請求項１に記載の個人情報口座管理サーバ。
3. 前記制御部は、前記顧客端末に対し、前記事業者情報データベースに登録されている前記サービスごとに必要な前記顧客の個人情報のうち、開示を許可する個人情報の選択入力を促す開示情報選択画面を送信し、
   前記顧客端末により前記選択入力された情報に基づき、前記個人情報データベースに登録された個人情報の中から前記開示を許可された項目を特定することを特徴とする請求項１又は請求項２に記載の個人情報口座管理サーバ。
4. 前記事業者情報データベースは、前記サービスの利用ごとにカウントするアクセス数を記憶し、前記アクセス数を前記開示情報選択画面に表示することを特徴とする請求項３に記載の個人情報口座管理サーバ。
5. 前記個人情報データベースは、前記個人情報の変更履歴を記憶し、前記変更履歴を前記開示情報選択画面に表示することを特徴とする請求項３又は請求項４に記載の個人情報口座管理サーバ。
6. 前記個人情報口座管理サーバは、前記個人情報の前記事業者への送信履歴である口座明細情報を記憶する口座明細情報データベースをさらに備え、
   前記制御部は、
   前記顧客端末からの要求に基づき、前記口座明細情報を送信することを特徴とする請求項１乃至５のいずれか一項に記載の個人情報口座管理サーバ。
7. 前記制御部は、
   前記顧客端末からの要求に基づき、前記口座明細情報に記憶された前記個人情報の消去要求を、当該個人情報を提供した事業者サーバに対して送信することを特徴とする請求項６に記載の個人情報口座管理サーバ。
8. 顧客端末と、顧客にサービスを提供する事業者の事業者サーバと、前記顧客端末と前記事業者サーバとネットワーク経由で接続される金融機関の個人情報口座管理サーバと、を備える個人情報管理システムであって、
   前記個人情報口座管理サーバは、
   前記事業者が提供するサービスごとに必要な前記顧客の個人情報の項目が前記事業者のウェブサイトのネットワークアドレスに対応付けて記憶される事業者情報データベースと、
   前記顧客により登録され、前記顧客の個人情報が記憶される個人情報データベースと、を備え、
   前記事業者サーバから前記サービスに必要な個人情報の取得要求を受信すると、前記事業者情報データベースと前記個人情報データベースとを参照し、前記サービスに必要な個人情報を抽出し、前記抽出された前記個人情報の中から顧客が開示を許可する個人情報の項目の選択を促す開示情報選択画面を生成し、前記顧客によって前記事業者に開示することが許可された個人情報を読み出し、前記取得要求のあった前記事業者サーバへ送信することを特徴とする個人情報管理システム。
9. 顧客端末と、顧客にサービスを提供する事業者の事業者サーバとネットワーク経由で接続される金融機関の個人情報口座管理サーバのプログラムであって、
   前記事業者が提供するサービスごとに必要な前記顧客の個人情報の項目を前記事業者のウェブサイトのネットワークアドレスに対応付けて事業者情報データベースに記憶する手段と、
   前記顧客により予め登録される前記顧客の個人情報か個人情報データベースに記憶する手段と、
   前記事業者サーバから前記サービスに必要な個人情報の取得要求を受信すると、前記事業者情報データベースと前記個人情報データベースとを参照し、前記サービスに必要な個人情報を抽出する手段と、
   前記抽出された前記個人情報の中から顧客が開示を許可する個人情報の項目の選択を促す開示情報選択画面を生成する手段と、
   前記顧客によって開示が許可された個人情報を読み出し、前記取得要求のあった前記事業者サーバに送信する手段
   として、コンピュータを機能させることを特徴とするプログラム。

Images