JP2013012224A - 個人情報保護装置 - Google Patents

個人情報保護装置 Download PDF

Info

Publication number
JP2013012224A
JP2013012224A JP2012189990A JP2012189990A JP2013012224A JP 2013012224 A JP2013012224 A JP 2013012224A JP 2012189990 A JP2012189990 A JP 2012189990A JP 2012189990 A JP2012189990 A JP 2012189990A JP 2013012224 A JP2013012224 A JP 2013012224A
Authority
JP
Japan
Prior art keywords
user
personal information
name
site
processing
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2012189990A
Other languages
English (en)
Other versions
JP5198678B2 (ja
Inventor
Masamichi Torikai
將迪 鳥飼
Yutaka Tsukamoto
豊 塚本
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Individual
Original Assignee
Individual
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Family has litigation
First worldwide family litigation filed litigation Critical https://patents.darts-ip.com/?family=47685989&utm_source=google_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=JP2013012224(A) "Global patent litigation dataset” by Darts-ip is licensed under a Creative Commons Attribution 4.0 International License.
Application filed by Individual filed Critical Individual
Priority to JP2012189990A priority Critical patent/JP5198678B2/ja
Publication of JP2013012224A publication Critical patent/JP2013012224A/ja
Application granted granted Critical
Publication of JP5198678B2 publication Critical patent/JP5198678B2/ja
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Images

Abstract

【課題】ユーザのプライバシーを保護しつつユーザの行動履歴データに基づいたよりカスタマイズされたユーザ好みの情報やサービスをユーザ側に提供しやすくする。
【解決手段】ウェブサイトからのアクセス履歴の提供依頼を受付けた場合に(S530でYES)ユーザの許可証の返信を該ウェブサイトから受付け(S537でYES)、その許可証が適正なことを条件に(S539でYES)アクセス履歴のウェブサイトへの提供を許容するための制御を行なう(S547、S548、S540)。ウェブサイトが許可証を所有していない場合に(S538でYES)ユーザに対し、ウェブサイトにアクセス履歴を提供してもよい旨を承諾したことを確認し(S543、S544、S546)、承諾したことの確認ができない場合にアクセス履歴のウェブサイトへの提供を拒否する制御を行なう(S545)。
【選択図】図19

Description

本発明は、コンピュータシステムを利用して、ネットワーク上での個人情報を保護する個人情報保護装置に関する。
従来において、ユーザがネットワークを通してサイトにアクセスして、たとえばショッピング等のネットワーク上での何らかの行動を起こす際に、当該ユーザの住所氏名や年齢あるいは嗜好情報等の個人情報の送信をサイト側から要求される場合がある。
このような場合において、個人のプライバシーを維持したまま、安心できる状態で安全に正しく権限を与えられた情報転送を行なうものとして、特許文献1に記載のものがあった。この特許文献1に記載のものは、第1のデータ記憶はユーザーに関する静的身元確認データを含む。第2のデータ記憶はユーザーに関する適度に動的な個人データを含む。第3のデータ記憶は、ユーザーに関する動的実態的人口統計学的情報データを含む。上記のシステムで電子ウォレット(財布)を使用して、データの選択された部分をダウンロードしてユーザーに使用させることができる。データは、フォームを埋めたり、ユーザーにサービスを提供したり、ユーザーの匿名性を維持したまま店主が選択的に販売対象となるユーザーを定めることができるように使用することができる。
特開平11−250165号公報
本発明の目的は、ユーザのプライバシーを保護しつつユーザの行動履歴データに基づいたよりカスタマイズされたユーザ好みの情報やサービスをユーザ側に提供しやすくすることである。
課題を解決するための手段の具体例
次に、課題を解決するための各種手段と実施の形態との対応関係を以下に括弧書で示す。
[1] コンピュータシステムを利用して、ネットワーク上での個人情報を保護する個人情報保護装置であって、
ユーザがネットワーク上で行動した結果第1ウェブサイトに蓄積された行動履歴データを該第1ウェブサイトとは別の第2ウェブサイトへ提供するための制御を行なう行動履歴データ提供制御手段(たとえば、図19の他のトラップ型VPのアクセス履歴の提供の制御を行なうVP管理サーバ9、データベース12a)を含み、
該行動履歴データ提供制御手段は、
前記ユーザが前記第2ウェブサイトに前記行動履歴データを提供してもよい旨を承諾したことを証する電子的許可証を前記第2ウェブサイトから受付ける許可証受付手段(たとえば、S536〜S538)と、
該許可証受付手段により受付けられた前記電子的許可証が適正か否か判定する判定手段(たとえば、S539)と、
該判定手段により適正であるとの判定が行なわれたことを条件として、前記行動履歴データの前記第2ウェブサイトへの提供を許容するための制御を行なう許容制御手段(たとえば、S547、S548、S540)と、
前記第2ウェブサイトが前記電子的許可証を所有していない場合に(たとえば、S538でYES)、前記第2ウェブサイトに前記行動履歴データを提供してもよい旨を前記ユーザが承諾したことを確認する確認手段(たとえば、S543、S544、S546)と、
該確認手段による前記承諾したことの確認ができない場合に前記行動履歴データの前記第2ウェブサイトへの提供を拒否する制御を行なう拒否制御手段(たとえば、S545)とを有する。
[2] 前記ユーザが前記第2ウェブサイトに前記行動履歴データを提供する際に条件付きで前記行動履歴データを提供する旨の承諾を行なうことが可能であり(たとえば、S544)、
前記確認手段は、前記条件付きで承諾したことを確認する(たとえば、S543、S544、S546)。
[3] 現実世界での実在人物(たとえば、RP)を特定して識別するための実在人物用識別データ(たとえば、図3;氏名(太郎)や住所等)とは異なる仮想人物(たとえば、VP)を識別するための仮想人物用識別データ(たとえば、図3、図4;氏名(B13P)や最寄のコンビニの住所等)を生成する仮想人物用識別データ生成手段と、
前記実在人物であるユーザが前記仮想人物としてネットワーク上で行動してウェブサイトにアクセスする際に、ユーザを特定する情報の要求に応じて、当該ユーザに対応する前記仮想人物用識別データを当該ウェブサイトの業者に提供する提供手段(たとえば、ブラウザフォン30、図27のS590〜S593、S596〜S600、S581、S121)とをさらに含む。
[4] 前記仮想人物用識別データは、前記ウェブサイトの業者に提供されるユーザの匿名としてのコードデータを含む(たとえば、図4のB13PやNPXA)。
[5] 前記仮想人物用の電子証明書を発行する電子証明書発行手段(たとえば、S441)をさらに含む。
課題を解決するための手段の具体例の効果
上記のような構成によれば、ユーザが第1ウェブサイトに蓄積された自己の行動履歴データを第2ウェブサイトに提供してもよい旨の確認がとれたことを条件に行動履歴データの第2ウェブサイトへの提供が許容され、その行動履歴データに基づいたよりカスタマイズされたユーザ好みの情報やサービスをユーザ側に提供しやすくなる。
個人情報保護システムの全体構成を示す概略システム図である。 (a)は会社の概略構成を示し、(b)はユーザ宅の概略構成を示す図である。 金融機関に設置されたデータベースに記憶されている各種データを示す説明図である。 金融機関に設置されたデータベースに記憶されている各種データを示す説明図である。 金融機関に設置されたデータベースに記憶されている各種データを示す説明図である。 金融機関に設置されているデータベースに記憶されている各種データを示す説明図である。 XMLストアのデータベースに記憶されている各種データを示す説明図である。 コンビニエンスストアに設置されているデータベースに記憶されている各種情報を説明するための説明図である。 ユーザ端末の一例としてのブラウザフォンを示す正面図である。 ユーザに携帯されるVP用IC端末の回路を示すブロック図および記憶情報の内訳を示す図である。 VP用IC端末のクッキーデータ記憶領域に記憶されているクッキーデータの内訳を示す図である。 VP管理サーバの処理動作を示すフローチャートである。 (a)はVP管理サーバの処理動作を示すフローチャートであり、(b)は個人情報の登録処理のサブルーチンプログラムを示すフローチャートである。 トラップ情報の登録処理のサブルーチンプログラムを示すフローチャートである。 個人情報の確認処理のサブルーチンプログラムを示すフローチャートである。 個人情報の照合,流通チェックのサブルーチンプログラムを示すフローチャートである。 (a)は個人情報の照合,流通チェックのサブルーチンプログラムを示すフローチャートであり、(b)は個人情報の販売代行のサブルーチンプログラムを示すフローチャートである。 メール転送,流通チェックのサブルーチンプログラムを示すフローチャートである。 他のトラップ型VPのアクセス履歴の提供処理のサブルーチンプログラムを示すフローチャートである。 信頼度ランキング情報の集計,提供処理のサブルーチンプログラムを示すフローチャートである。 認証用サーバの処理動作を示すフローチャートである。 決済サーバの処理動作を示すフローチャートである。 決済処理のサブルーチンプログラムを示すフローチャートである。 (a)は決済処理のサブルーチンの一部を示し、(b)は正当機関証明処理のサブルーチンプログラムを示すフローチャートである。 クレジットカード発行会社からの問合せ処理のサブルーチンプログラムを示すフローチャートである。 ブラウザフォンの処理動作を示すフローチャートである。 VP用クッキー処理のサブルーチンプログラムを示すフローチャートである。 (a)は住所,氏名,Eメールアドレスの送信処理のサブルーチンプログラムを示すフローチャートであり、(b)はRP用のクッキー処理のサブルーチンプログラムを示すフローチャートである。 VP出生依頼処理のサブルーチンプログラムを示すフローチャートである。 (a)は正当機関チェック処理のサブルーチンプログラムを示すフローチャートであり、(b)は電子証明書発行要求処理のサブルーチンプログラムを示すフローチャートである。 (a)はVP用入力処理のサブルーチンプログラムを示すフローチャートであり、(b)はRP用入力処理のサブルーチンプログラムを示すフローチャートである。 SETによる決済処理の概要を説明するための説明図である。 VP用決済処理のサブルーチンプログラムを示すフローチャートである。 (a)は本人証明処理のサブルーチンプログラムを示すフローチャートであり、(b)はVP用決済処理のサブルーチンプログラムの一部を示すフローチャートである。 VP用決済処理のサブルーチンプログラムの一部を示すフローチャートである。 (a)はVP用Webブラウザ,メール処理のサブルーチンプログラムを示すフローチャートであり、(b)は偽RPアクセス処理のサブルーチンプログラムを示すフローチャートである。 (a)はVP用IC端末の処理動作を示すフローチャートであり、(b)はRP用IC端末の処理動作を示すフローチャートである。 (a)は暗証番号チェック処理のサブルーチンプログラムを示すフローチャートであり、(b)はクッキー処理(VP用)のサブルーチンプログラムを示すフローチャートであり、(c)は本人証明処理(VP用)のサブルーチンプログラムを示すフローチャートであり、(d)は本人証明処理(RP用)のサブルーチンプログラムを示すフローチャートである。 (a)はデータ入力処理のサブルーチンプログラムを示すフローチャートであり、(b)はユーザエージェント動作処理のサブルーチンプログラムを示すフローチャートであり、(c)はリロード金額の使用処理のサブルーチンプログラムを示すフローチャートであり、(d)はRP署名処理のサブルーチンプログラムを示すフローチャートであり、(e)はVP署名処理のサブルーチンプログラムを示すフローチャートである。 その他の動作処理のサブルーチンプログラムを示すフローチャートである。 トラップ型VP処理のサブルーチンプログラムを示すフローチャートである。 コンビニサーバの処理動作を示すフローチャートである。 (a)は暗証番号チェック処理のサブルーチンプログラムを示すフローチャートであり、(b)は本人チェック処理のサブルーチンプログラムを示すフローチャートであり、(c)は決済処理のサブルーチンプログラムを示すフローチャートである。 別実施の形態を示し、(a)は、VP用IC端末に記憶されているトラップ情報であり、(b)は、トラップ型VP処理のサブルーチンプログラムを示すフローチャートであり、(c)は、VP用IC端末の制御動作を示すフローチャートである。
次に、本発明の実施の形態を図面に基づいて詳細に説明する。図1は、ブロードバンドを利用したネットワークシステムを示し、個人情報保護システムの全体の概略を示す構成図である。広域・大容量中継網43を通じて、クレジットカード発行会社群4、加盟店契約会社群5、受信局42、加盟店群6、サプライヤ群1、NM群(ニューミドルマン群)48、電子行政群49、XMLストア50、コンテンツプロバイダ群51、信号52、携帯電話網54に接続されたゲートウェイ53、インターネットI、ユーザ宅47、認証局群46、コンビニエンスストア群2、会社群45、データセンタ44、放送局41、金融機関群7等が、情報の送受信ができるように構成されている。なお、図中40は衛星(サテライト)であり、放送局41からの放送電波を中継して受信局42に電波を送るためのものである。
クレジットカード発行会社群4とは、たとえばSET(Secure Electronic Transaction)により決済を行なう場合のイシュアとしての機能を発揮するカード発行会社である。加盟店契約会社群5は、電子モール等を構成する加盟店群6が契約している金融機関等からなる会社であり、SETにおけるアクアイアラとして機能する機関である。サプライヤ群1とは、商品メーカー等であり、商品や情報を提供する機関のことである。NM群48とは、サプライヤ群1と消費者(自然人または法人)との仲立ちを行ない、たとえば消費者のショッピング等の消費行動の支援を行なうサービス業者のことである。従来の問屋や商社等の中間業者が、サプライヤ群の販売支援を行なうのに対し、このNM群48は、消費者の購入支援(消費行動支援)を行なう点で相違する。NM群48の具体例としては、消費者の嗜好情報や購買履歴情報やWebサイトへのアクセス履歴情報をデータベースとして蓄積し、その蓄積されている消費者のプロフィール情報(個人情報)に基づいてその消費者にマッチする商品情報等を推薦して、消費者の消費行動を助けるサービス業者が当てはまる。
電子行政群49は、たとえば市役所や税務署あるいは中央官庁等の行政を電子化したものである。XMLストア50とは、XMLによる統一されたデータ構造によってデータを格納するとともに、必要に応じてデータの要求者に所定のデータを提供するデータベースのことである。XMLストア50には、ユーザの各種個人情報やユーザエージェント(エージェント用知識データを含む)を格納している。金融機関群7やユーザからXMLストア50にアクセスがあった場合には、本人認証を行なってセキュリティを保ったうえで、必要なデータを提供できるように構成されている。コンテンツプロバイダ群51とは、映像、文字、音等の種々のコンテンツをネットワークを通じて提供する業者群のことである。交通整理を行なうための信号機52も、広域・大容量中継網43に接続され、遠隔制御できるように構成されている。
携帯電話網45に接続されている基地局55に対し、ブラウザフォン(次世代携帯電話)30の電波が送信され、基地局55,携帯電話網45,ゲートウェイ53,広域・大容量中継網43を介して、金融機関群7,加盟店群6,NM群48,電子行政群49,XMLストア50,コンテンツプロバイダ群51等にアクセスできるように構成されている。また車両56も同様に、基地局55,携帯電話網54,ゲートウェイ53,広域・大容量中継網54を介して、各種サービス業者や各種機関にアクセスできるように構成されている。
認証局群46とは、電子証明書の発行希望者に対して本人認証をしたうえで電子証明書を発行する機関である。データセンタ44は、放送局41から電波により配信される各種データを格納,管理する機関のことである。加盟店群6,サプライヤ群1,NM群48,電子行政群49,コンテンツプロバイダ群51等にユーザが所定の情報の送信を依頼した場合に、大容量のデータを送信する際には、それら各機関やサービス業者の配信するデータを一旦データセンタ44に格納しておき、所定の日時が来たときに放送局41から電波を通じてそのデータを配信し、受信局42で受信したデータを所定のユーザに広域・大容量中継網43を通じて配信する。
なお、図1中二重線で示した部分は、無線LAN,CATV,衛星,xDSL(digital subscriber line),FTTH(fiber to the home)などである。
本実施の形態では、認証局群46ばかりでなく、金融機関群7も、電子証明書を発行する。図1中、19はユーザに携帯されるIC端末であり、後述するようにユーザのプロフィール情報(個人情報)等が格納されている。
図2(a)は、図1に示した会社群45の一例を示し、図2(b)は、図1に示したユーザ宅47の一例を示している。
会社45内には、社内LANが構築されており、パーソナルコンピュータ57,自動販売機58,サーバ59,データベース60,ノート型パーソナルコンピュータ62,ファクシミリ61が情報のやり取りができるように接続されている。
ブラウザフォン30は、パーソナルコンピュータ57,自動販売機58,サーバ59,他のブラウザフォン30に対し、ブルートゥース(Bluetooth)(登録商法)を使用して直接送受信できるように構成されている。前述したデータセンタ44は、配信しようとするコンテンツ等の情報のうちセキュリティを要求される情報に関しては暗号化して格納しており、その暗号化情報を配信するときには暗号化された情報のままで放送局41から電波により配信される。一方、IC端末19は、個人情報の他にそのIC端末19の所持者であるユーザの本人認証用の鍵や暗号アルゴリズム等のセキュリティ機能が備えられている。前述した放送局41から配信されてきて広域・大容量中継網43等を経由して会社45内の社内LANに伝送されてきた暗号化情報は、このIC端末19に記憶されている鍵およびアルゴリズムによって復号化できるように構成されている。
さらに、ブラウザフォン30にこのIC端末19を接続することにより、送られてきた情報をブラウザフォン30で受けてその暗号化情報をIC端末19により復号化して平文等の元の情報にして表示することができる。ブラウザフォン30にIC端末19を接続した場合には、さらに通話を暗号化して送受信することができる。暗号化された通話をブラウザフォン30が受信すれば、IC端末19によりリアルタイムで復号化してもとの通話に戻してその通話をスピーカから流すことができるように構成されている。
ファクシミリ61にIC端末19を接続することにより、ファクシミリ61による送受信データを暗号化することができる。そして暗号化されたデータをファクシミリ61が受信すれば、IC端末19によりそれを復号化して平文等の元のデータに戻してプリントアウトできる。
図2(b)のユーザ宅47のRANには、セットボックス63、テレビ67、パーソナルコンピュータ68、照明64、冷蔵庫69、エアコンディショナ65、電話66、電子錠70等が接続されている。
図2に示す、パーソナルコンピュータ57、自動販売機58、サーバ59、ファクシミリ61、ノート型パーソナルコンピュータ62、セットボックス63、テレビ67、パーソナルコンピュータ68、照明器具64、冷蔵庫69、エアコンディショナ65、電話66、電子錠70等は、それぞれURLが割振られており、外部から広域・大容量中継網43等を経由してそのURL(Uniform Resource Locator)にアクセスすることによりそれぞれの装置にアクセスできるように構成されている。それぞれの装置にアクセスし、その装置の現在の状態等をチェックしたり、外部から遠隔操作できる。たとえば、電子錠70にアクセスして施錠されていない場合には遠隔操作によって施錠したり、エアコンディショナ65にアクセスして、ユーザがユーザ宅47に帰宅する10分ほど前に、エアコンディショナ65が作動するようにセットしたり等ができる。
図3は、金融機関7を説明するための説明図である。金融機関7には、VP管理サーバ9、決済サーバ10、認証用サーバ11、データベース12a,12bが備えられている。VP管理サーバ9は、仮想人物としてのバーチャルパーソン(以下、単に「VP」という)を管理するためのサーバである。VPとは、現実世界に実在しないネットワーク上で行動する仮想の人物のことであり、現実世界での実在人物であるリアルパーソン(以下、単に「RP」という)がネットワーク上で行動する際に、VPになりすましてそのVPとして行動できるようにするために誕生させた仮想人物のことである。
VP管理サーバ9は、後述するように、RPからVPの出生依頼があれば、そのVPの氏名や住所等の所定情報を決定してVPを誕生させ、そのVPのデータをデータベース12aに記憶させておく機能を有している。また、このVP管理サーバ9は、VP用の電子証明書を作成して発行する機能も有している。VPが売買や決済等の法律行為を行なう場合に、この電子証明書を相手方に送信することにより、仮想人物でありながら独立して法律行為を行なうことが可能となる。
認証用サーバ11は、RP用の電子証明書を作成して発行する機能を有する。金融機関7に設置されている決済サーバ10は、RPによる電子マネーやデビットカードを使用しての決済ばかりでなく、VPとして電子マネーやデビットカードを使用しての決済を行なうための処理を行なう機能も有している。
データベース12aは、RPやVPに関するデータを格納するものである。データベース12bは、広域・大容量中継網43やインターネットIに接続されているサイト(業者)を管理するためのデータを格納している。
図3に示すように、データベース12aには、RP用のデータとして、RPの氏名、住所、認証鍵KN、公開鍵KT、口座番号等が記憶されている。認証鍵とは、RPが金融機関7にアクセスしてきた場合に共通鍵暗号方式により本人認証を行なうための鍵である。公開鍵とは、公開鍵暗号方式に用いられる鍵であり、秘密鍵とペアとなっている鍵である。口座番号は、当該金融機関7においてRPが開設している口座番号のことである。
トラップ情報とは、サイト(業者)側が個人情報を収集してそれを不正に流通させた場合に、それを行なった犯人を割出すためにトラップ(罠)を仕掛けるための情報である。たとえば、VPが自己の個人情報をあるサイト(第1譲渡先)に譲渡する際に、その第1譲渡先特有の氏名を用いる。すなわち、VPが自己の氏名を複数種類有し、サイト(業者)ごとに使い分ける。このようなVP氏名を、便宜上トラップ型VP氏名という。このようにすれば、ダイレクトメールやEメールが業者側から送られてきた場合には、そのメールの宛名がトラップ型VP氏名となっているはずである。その送ってきたサイト(業者)が、トラップ型VP氏名から割出される第1譲渡先とは異なりかつ譲渡した自己の個人情報の開示許容範囲(流通許容範囲)を超えたサイト(業者)であった場合には、その個人情報が第1譲渡先によって不正に開示(流通)されたこととなる。このように、不正流通(不正開示)を行なった第1譲渡先を、トラップ型VP氏名から割出すことができる。
なお、図3では、次郎が第2トラップ情報、第3トラップ情報、第2個人情報、第3個人情報、2つの情報を有している。次郎が、ネットワーク上で行動する場合に、この2人のVPを使い分けて行動するために、これら2種類のVP情報を金融機関7に登録している。VPの住所とは、後述するように、RPの希望するまたはRPの住所に近いコンビニエンスストア2の住所である。その結果、VPとして電子ショッピングをした場合の商品の配達先が、そのVPの住所であるコンビニエンスストア2に配達されることとなる。RPは、その配達されてきた商品をVPになりすましてコンビニエンスストア2にまで出向いて商品を引取ることが可能となる。このようにすれば、住所を手がかりにVPとRPとの対応関係が見破られてしまう不都合が防止できる。
図3に示したトラップ情報の詳細は、図4に示されている。第1トラップ情報、第2トラップ情報、…の各トラップ情報は、サイト名ごとに、氏名(トラップ型VP氏名)、公開鍵、Eメールアドレス、バーチャル口座番号、バーチャルクレジット番号を含んでいる。たとえば、サイト名(業者名)ABCにVPがアクセスする際には、VPの本名であるB13Pを用い、VPの秘密鍵KSBとペアの公開鍵KPB'を用い、VPの本当のEメールアドレスである○□×△×を用い、VPの本当の口座番号である2503を用い、VPの本当のクレジット番号である3288を用いる。
一方、サイト名(業者名)MTTにアクセスする場合には、VPの本名をそのVPの秘密鍵で1回暗号化したE(B13P)を、トラップ型VP氏名として用いる。秘密鍵としては、VPの本当の秘密鍵KSBをVPの本当の秘密鍵KSBで1回暗号化したEKSB(KSB)を用いる。この秘密鍵EKSB(KSB)に対する公開鍵KPBがデータベース12aに格納されている。Eメールアドレスとしては、金融機関7がトラップ型VPのために開設しているEメールアドレス△△△△△を用いる。口座番号としては、VPの本当の口座番号をVPの本当の秘密鍵で1回暗号化したE(2503)をバーチャル口座番号として用いる。クレジット番号は、VPの本当のクレジット番号をVPの本当の秘密鍵で1回暗号化したE(3288)を用いる。
さらに、サイト名(業者名)MECにアクセスする場合には、VPの秘密鍵でVPの本名を2回暗号化したE2(B13P)をトラップ型VP氏名として用いる。
VPがトラップ型VP氏名E2(B13P)を用いてネットワーク上で行動する場合には、秘密鍵KSBを秘密鍵KSBで2回暗号化した2回暗号化秘密鍵E2 KSB(KSB)を用いる。その2回暗号化秘密鍵とペアになっている公開鍵がKPB″である。Eメールアドレスは、金融機関7がトラップ型VP用のEメールアドレスとして開設している△△△△△を用いる。バーチャル口座番号は、VPの本当の口座番号を秘密鍵で2回暗号化したE2(2503)を用いる。クレジット番号は、VPの本当のクレジット番号をVPの秘
密鍵で2回暗号化したバーチャルクレジット番号E2(3288)を用いる。
このように、サイト名ごとに、トラップ情報の暗号回数が異なる。サイト側(業者側)に提供した個人情報というものは、ネットワーク上を流通した後最終的にはその個人情報主にEメールやダイレクトメールの形で返ってくる。この個人情報の帰還ループを利用してトラップを仕掛けて個人情報の不正流通を行なった犯人を追跡できるようにするのが、このトラップ情報の狙いである。すなわち、ユーザをネット上で追跡するトラッキング型クッキーの逆を行なうものである。
図5は、図3に示したVPの個人情報を説明する図である。第1個人情報、第2個人情報、第3個人情報、…の各個人情報は、個人情報A、個人情報B、…の複数種類の個人情報が集まって構成されている。たとえば、個人情報Aは、VPの年齢,性別,職業,年収等であり、個人情報Bは、VPの嗜好に関する情報である。
図5に示すように、各個人情報は,金融機関7の秘密鍵KSによるデジタル署名が付されている。たとえば,第1個人情報の個人情報Aは、○○△の個人情報自体に対しデジタル署名であるDKS(○○△)が付されている。
このデータベース12aに格納されている各個人情報は、後述するように、金融機関7がその真偽をチェックして正しいもののみをデータベース12aに格納し、正しいことを認証するためのデジタル署名が付される。
図6は、金融機関7のデータベース12bに格納されている情報を示す図である。データベース12bには、サイト名(業者名)ごとに、その業者が個人情報を不正入手した値と、個人情報を不正流出(不正流通)した値と、それら両値から割出される悪い順位とが記憶されている。
後述するように、あるサイト名(業者名)MTTが、個人情報を不正に入手すればその不正入手値が「1」加算更新され、個人情報を不正に流通すれば、その不正流通値が「1」加算更新される。そして悪い順位は、不正入手値+2×不正流出値の計算式で値を出し、その値が大きいほど悪い順位が上位となる。前記計算式の値が一番大きければ悪い順位が一番となる。
図7は、XMLストア50の構成を示す図である。XMLストア50には、データベース72とそれを制御するサーバ71とが設置されている。サーバ71は、XMLストア50にアクセスしてきた者を、本人認証してアクセス制御する機能も備えている。
データベース72には、XMLで表現されたデータが格納されている。そのデータの中身は、VP情報として、VPの氏名であるたとえばB13P、VPユーザエージェント(知識データを含む)、サイト別情報として、サイト名たとえばABC、そのサイトにアクセスしたVPに発行された電子証明書、そのVPの個人情報と当該サイトのプライバシーポリシーとそれら両情報に対し当該VPが付したデジタル署名DKSB(個人情報+ポリシー)と当該サイトABCが付したデジタル署名DKSA(個人情報+ポリシー)と、トラップ情報としての暗号化回数「0」と、当該VPのEメールアドレスである○□×△×が含まれている。さらに、VPがサイト名MTTにアクセスした場合には、そのサイト名MTTにアクセスしたトラップ型VPに対し発行された電子証明書と、そのサイトにトラップ型VPが提供した個人情報とそのサイトのプライバシーポリシーとそれら両情報に対する当該トラップ型VPのデジタル署名と当該サイトのデジタル署名と、トラップ情報としての暗号回数「1」とEメールアドレスとが含まれている。
さらに、氏名がNPXAの他のVPの情報も、前述と同様の項目がデータベース72に記憶される。このデータベース72には、非常に多くのVPごとに、前述した項目でデータが記憶されている。
なお、サイト名ABCについては、図4で説明したように、トラップ情報として1回も暗号化していない情報を用いているために、データベース72に格納されている暗号回数も「0」となっている。サイト名MTTについて言えば、図4で説明したように、トラップ情報として1回暗号化した情報を用いているために、データベース72に記憶されている暗号化回数も「1」となっている。
前述したVPユーザエージェントとは、ユーザであるVPのために動作する自立型ソフトウェアのことである。このVPユーザエージェントは、ネットワークを通して移動できるようにモバイルエージェントで構成されている。
なお、図3〜図7に示した各データは、暗号化した状態で各データベースに格納しておいてもよい。そうすれば、万一データが盗まれたとしても、解読できないために、セキュリティ上の信頼性が向上する。一方、たとえばVP(トラップ型VPを含む)がネットワーク上で目に余る不正行為(たとえば刑法に違反する行為)を行なった場合には、所定機関(たとえば警察等)からの要請等に応じて、そのVPをデータベース12a等から検索してそのVPに対応するRPを割出し、RPの住所氏名等を要請のあった所定機関(たとえば警察等)に提供するようにしてもよい。
図8は、コンビニエンスストア2の構成を示す図である。コンビニエンスストア2には、データベース75と、それに接続されたサーバ74と、そのサーバに接続された端末73とが設置されている。データベース75には、当該コンビニエンスストアに住所を持つVP(トラップ型VPを含む)の氏名と、それら各氏名に対応して、商品の預かり情報、Eメールアドレス、顧客管理情報等が記憶されている。
当該コンビニエンスストア2にB13PのVPが購入した商品が配達されれば、データベース75のB13Pの記憶領域に、商品預かり情報として「ABC会社からの商品預かり,未決済」が格納される。この未決済とは、B13Pがネットを通じて商品を購入したもののまだ支払を行なっていない状態のことである。
データベース75のEメールアドレスの欄には、各VPに対応してEメールアドレスが格納されている。B13Pの場合には、トラップ型VPでないために、当該VPの本当のEメールアドレスである○□×△×が格納されている。
トラップ型VPであるE(B13P)も同様に、商品預かり情報としてたとえば「MTT会社からの商品預かり,決済済」が格納される。なお、E(B13P)は、トラップ型VPであるために、Eメールアドレスは、金融機関7のトラップ型VPのために開設されているEメールアドレスが格納される。
サーバ74は、後述するように、コンビニエンスストア2にVP(トラップ型VPを含む)として商品を引取りに来た顧客が、当該コンビニエンスストア2に登録されているVP(トラップ型VPを含む)に対し商品を預かっている場合にはその商品をVP(トラップ型VPを含む)に引渡すための処理を行なう。
コンビニエンスストア2は、商品の預かりサービスばかりでなくVP用のダイレクトメールの預かりサービスも行なう。VPはコンビニエンスストア2が住所でありVP宛のダイレクトメールはコンビニエンスストア2に郵送されるためである。
図9は、ユーザに用いられる端末の一例のブラウザフォン30を示す正面図である。ブラウザフォン30には、マイクロコンピュータ199が備えられている。このマイクロコンピュータ199には、CPU(Central Processing Unit)197と、I/Oポート198と、ROM195と、EEPROM194と、RAM196とが備えられている。このブラウザフォン30は、USB(Universal Serial Bus)ポートを備えており、USBポートに対し、IC端末19Rまたは19Vまたは19Iが差込み可能に構成されている。IC端末19Rは、RP用のIC端末である。IC端末19Vは、VP用のIC端末である。IC端末19Iは、後述するように金融機関が発行したVP用のデータやプログラムが格納されてユーザにまで配達されてくるものであり、その配達されてきたIC端末19Iをブラウザフォン30のUSBポートに指込むことにより、IC端末19Iに記憶されているデータやソフトウェアがブラウザフォン30に記憶されることとなる。
図10は、VP用IC端末19Vを説明するための説明図である。VP用IC端末19Vは、前述したように、ブラウザフォン30のUSBポート18に対し着脱自在に構成されており、USBポート18に差込むことにより、ブラウザフォン30との情報がやり取りできるようになり、使用可能な状態となる。
VP用IC端末19V内には、LSIチップ20が組込まれている。このLSIチップ20には、制御中枢としてのCPU24、CPU24の動作プログラムが記憶されているROM25、CPU24のワークエリアとしてのRAM22、電気的に記憶データを消去可能なEEPROM26、コプロセッサ23、外部とのデータの入出力を行なうためのI/Oポート21等が設けられており、それらがバスにより接続されている。
EEPROM26には、電子マネー用のプログラムであるモンデックス(リロード金額データを含む)、その他の各種アプリケーションソフト、VP用に発行された電子証明書、暗証番号、クッキーデータが記憶されている。
さらに、VP用IC端末19Vは、VPのユーザエージェントとしての機能を有しており、ユーザエージェント用知識データとして、デビットカード情報、クレジットカード情報、VPの氏名,住所、VPのEメールアドレス、VPの公開鍵KPと秘密鍵KS、RPの認証鍵KN、VPの年齢,職業等、VPの各種嗜好情報、VPの家族構成、…等の各種知識データが記憶されている。
RP用IC端末19Rの場合も、図10に示したVP用IC端末19Vとほぼ同様の構成を有している。相違点といえば、EEPROM26に記録されているユーザエージェント用知識データの内容が相違する。具体的には、VPの氏名,住所の代わりにRPの氏名,住所、VPのEメールアドレスの代わりにRPのEメールアドレス,VPの公開鍵や秘密鍵の代わりにRPの公開鍵,秘密鍵、VPの年齢や職業等の代わりにRPの年齢や職業等、VPの各種嗜好情報の代わりにRPの各種嗜好情報、VPの家族構成の代わりにRPの家族構成となる。
なお、VPの家族構成は、VPに対応するRPの家族がVPを誕生させている場合には、その誕生しているVPの名前や住所や年齢等のデータから構成されている。つまり、RPの家族に対応するVPの家族すなわちバーチャル家族のデータがこのVPの家族構成の記憶領域に記憶されることとなる。
図11は、図10に示したクッキーデータの詳細を示す図である。クッキーデータの記憶領域には、VP氏名ごとに、そのVP氏名を用いてアクセスしたサイト(業者)側から送られてきたクッキーが格納される。VPが本名B13Pを用いてサイトにアクセスする場合には、既にトラップ型VPを用いてアクセスしたサイト以外のサイトは、どのサイトでもアクセスできる。その結果、本名B13Pに限り多くのサイトからのクッキーデータが記憶されている。
図12は、図3に示したVP管理サーバ9の処理動作を示すフローチャートである。ステップS(以下単にSという)1により、VPの出生依頼があったか否かの判断がなされる。顧客(ユーザ)がブラウザフォン30を操作してVPの出生依頼を行なえば、S1aに進み、正当機関である旨の証明処理がなされる。この証明処理は、金融機関7がVPの管理をする正当な機関であることを証明するための処理であり、他人が金融機関7になりすます不正行為を防止するための処理である。この処理については、図24(b)に基づいて後述する。次にS2へ進み、RPの氏名,住所の入力要求をブラウザフォン30へ送信する。次にS3へ進み、RPの氏名,住所の返信がブラウザフォン30からあったか否かの判断がなされ、あるまで待機する。
ユーザであるRPがブラウザフォン30から自分の氏名,住所を入力して送信すれば、S3によりYESの判断がなされてS4へ進み、乱数Rを生成してチャレンジデータとしてブラウザフォン30へ送信する処理がなされる。ユーザがVPの出生依頼を行なう場合には、ブラウザフォン30のUSBポート18にVP用IC端末19Vを差込んでおく。その状態で、VP管理サーバ9から乱数Rが送信されてくれば、その乱数をVP用IC端末19Vへ入力する。すると、後述するように、VP用IC端末19V内において入力された乱数RをRPの認証鍵KNを用いて暗号化する処理がなされ、その暗号結果がブラウザフォン30へ出力される。ブラウザフォン30では、その出力されてきた暗号化データであるレスポンスデータIをVP管理サーバ9へ送信する。すると、S5によりYESの判断がなされてS6へ進み、RPの認証鍵KNを用いて、受信したレスポンスデータIを復号化する処理すなわちDKN(I)を算出する処理がなされる。次にS7へ進み、S4により生成した乱数R=DKN(I)であるか否かの判断がなされる。
VPの出生依頼者が金融機関7のデータベース12に記憶されている正規のRPである場合には、R=DKN(I)となるために、制御がS9へ進むが、データベース12に記憶されているRPに他人がなりすましてVPの出生依頼を行なった場合には、R=DKN(I)とはならないために、制御がS8へ進み、アクセス拒絶の旨がブラウザフォン30へ送信されてS1へ戻る。
一方、S7によりYESの判断がなされた場合には、S9へ進み、希望のコンビニエンスストアの入力があったか否かの判断がなされる。VPの出生依頼を行なったRPは、誕生してくるVPの住所となるコンビニエンスストアについて特に希望するコンビニエンスストアがあれば、ブラウザフォン30に入力してVP管理サーバ9へ送信する。その場合には、S9によりYESの判断がなされてS10へ進み、その入力されてきたコンビニエンスストアの情報を記憶した後S12へ進む。一方、希望するコンビニエンスストアの入力がなかった場合にはS11へ進み、RPの住所に近いコンビニエンスストアを検索してそのコンビニエンスストアを記憶した後S12へ進む。
S12では、VPの氏名,VPの住所であるコンビニエンスストアの住所,VPのEメールアドレス等を決定する。次にS13へ進み、VPの公開鍵の送信要求をブラウザフォン30へ送信する。そして、S14へ進み、公開鍵KPの返信があったか否かの判断がなされ、あるまで待機する。VPの公開鍵の送信要求を受けたブラウザフォン30は、接続されているVP用IC端末19Vへ公開鍵出力要求を出力する。すると、後述するように、VP用IC端末19Vは、記憶しているVP用の公開鍵KPをブラウザフォン30へ出力する。ブラウザフォン30では、その出力されてきたVP用の公開鍵KPをVP管理サーバ9へ返信する。すると、S14よりYESの判断がなされてS15へ進み、RPに対応付けて、VPの氏名,住所,公開鍵KP,Eメールアドレスをデータベース12へ記憶させる処理がなされる。
次にS16へ進み、VPの電子証明書を作成してXMLストア50に登録する処理がなされる。次にS17へ進み、RPに、VPの氏名,コンビニエンスストアの住所,コンビニエンスストアの名称,Eメールアドレス,電子証明書を記憶したIC端末19Iを郵送するための処理がなされる。次にS18へ進み、S12で決定された住所のコンビニエンスストアにVPの氏名,Eメールアドレス,当該金融機関7の名称を送信する処理がなされる。次にS19へ進み、正当機関である旨の証明処理がなされる。この正当機関である旨の証明処理は、前述したS1aと同じ処理である。次にS1へ戻る。
本発明でいう「匿名用の電子証明書」とは、ユーザと当該ユーザが用いる匿名(VP氏名)との対応関係を特定可能な情報を登録している守秘義務のある所定機関(金融機関7)により発行され、前記匿名を用いるユーザが当該所定機関に登録されているユーザであることを証明する証明書を含む概念である。よって、本人確認に用いる一般的なデジタルIDばかりでなく、前記所定機関が前記匿名を用いるユーザに対し当該ユーザは当該所定機関に登録されているユーザであることを証明する電子的な証明書をすべて含む概念である。たとえば、ユーザが用いる匿名とその匿名が前記所定機関に登録されているメッセージとに対し、前記所定機関によるデジタル署名が施されただけの、簡単な証明書を含む概念である。
S1によりNOの判断がなされた場合にはS13(a)のS400へ進む。S400では、個人情報の登録処理が行なわれ、次にS401によりトラップ情報の登録処理が行なわれ、S402により個人情報の確認処理が行なわれ、S403により個人情報の照合,流通チェック処理が行なわれ、S404により個人情報の販売代行処理が行なわれ、S405によりメール転送,流通チェック処理が行なわれ、S406により他のトラップ型VPのアクセス履歴の提供処理が行なわれ、S407により信頼度ランキング情報の集計,提供処理が行なわれてS1へ戻る。ユーザから個人情報の提供を受けたサイト(業者)側では、提供してもらった個人情報が本当に正しい内容であるか否かを確認したいというニーズがある。そこで、金融機関7のVP管理サーバ9は、ユーザから個人情報を受付けてその個人情報が正しい個人情報かどうかをチェックし、正しい個人情報のみをデータベース12aに登録する。その処理をS400により行なう。
一方、ネットワーク上でVPの利用が盛んになった場合には、RPとVPとの両方の詳しい個人情報を収集した業者が、両個人情報をしらみつぶしにマッチングして、両個人情報が一致するRP氏名とVP氏名とを割出し、VPに対応するRPを予測してしまうという不都合が生ずる恐れがある。そこで、個人情報をデータベース12aに登録する場合には、勤務先名や所属部署名あるいは役職等のRPが特定されてしまうような個人情報を排除(または変更)して、登録する必要がある。そのような処理を、S400により行なう。
一方、個人情報主であるユーザは、自己の個人情報が正しい内容で流通しているか否かを監視し、間違っていれば正しい内容に修正したいというニーズがある。そこで、データベース12bに登録されている自己の個人情報の真偽をユーザがチェックできるように、S402により、個人情報の確認処理が行なわれる。
さらに、ユーザが自己の個人情報の公開範囲(流通範囲)を限定した上でその個人情報を業者側(サイト側)に提供した場合に、その公開範囲(流通範囲)が守られているか否かを監視したいというニーズがある。個人情報の提供を受けた業者側は、前述したようにその個人情報が正しい情報であるか否かを確認したいというニーズがある。そこで、サイト側(業者側)が所有している個人情報を正しい個人情報が登録されているデータベース12aの個人情報と照合できるようにする一方、その照合対象となった業者側所有の個人情報の流通許容範囲をチェックして正しく流通されているか否かをチェックできるように、S403の処理が行なわれる。
ユーザは、個人情報を提供する見返りとして、何らかのサービスあるいは金銭を入手したいというニーズがある。そこで、S404により、個人情報の販売代行が行なわれる。図4に基づいて説明したように、トラップ型VPは、Eメールアドレスを金融機関7のトラップ型VP用として開設しているアドレスにしているため、そのトラップ型VPに宛てたEメールは金融機関7のトラップ型VP用に開設されたEメールアドレス宛に送られる。そこで、その送られてきたEメールを対応するVPのEメールアドレスに転送する必要がある。その処理を、S405により行なう。その際に、業者側から送られてくるEメールの宛名はトラップ型VPとなっているために、そのトラップ型VPに対応するサイトを割出し(図4参照)、その割出されたサイトからのEメールでなかった場合には当該トラップ型VPの個人情報の流通許容範囲内のサイトからのEメールか否かをチェックし、流通チェックを行なうことも、S405により行なわれる。
図4に基づいて説明したように、トラップ型VP氏名をサイト別に使い分ける場合には、ユーザ側において、それら氏名毎に分離してサイト側からのクッキーが記録されるように交通整理を行なう必要がある。同一のクッキーが複数のトラップ型VPにまたがって共通に付着されている場合には、その複数のトラップ型VPは同一人物のVPであることが見破られてしまうためである。
このような交通整理を行なった場合には、業者側(サイト側)は、ある1つのトラップ型VPについてのアクセス履歴情報や商品購入履歴情報を収集することはできるが、同一のVPでありながら他のトラップ型VP氏名使用時におけるアクセス履歴や商品購入履歴情報は収集できなくなる。つまり、業者側(サイト側)は、あるVPについてその一部の履歴情報しか収集できなくなるという不都合が生ずる。
そこで、業者側(サイト側)から要請があった場合に、他のトラップ型VPのアクセス履歴を提供し得る処理が、S406により行なわれる。
ユーザが自己の個人情報をサイト側(業者側)に提供する際には、その業者がプライバシー保護に関してどの程度信用できる業者であるか否か確認したいというニーズがある。そこで、S407により、信頼度ランキング情報の集計を行なってその集計結果を提供する処理が行なわれる。
図13の(b)は、S400の個人情報の登録処理のサブルーチンプログラムを示すフローチャートである。この個人情報の登録処理は、ユーザがVPとして個人情報を登録する際の処理である。
乱数Rを受信したブラウザフォン30は、そのブラウザフォン30に接続されているVP用IC端末19Vに記憶されているVP用の秘密鍵を用いて乱数Rを1回暗号化してレスポンスデータIを生成する。そしてそのレスポンスデータIを金融機関7のVP用管理サーバ9へ送信する。
S410により、ユーザ側から個人情報の登録要求があったか否かの判断がなされ、ない場合にはこのサブルーチンプログラムが終了する。登録要求があった場合にはS411へ進み、正当機関証明処理がなされる。次に制御がS412へ進み、VPの氏名の入力要求がなされ、S413により入力があったか否かの判断がなされる。入力があった場合には制御がS414へ進み、乱数Rを生成してチャレンジデータとして登録要求を行なったユーザ側に送信する処理がなされる。S415へ進み、ユーザ側からレスポンスデータIを受信したか否かの判断がなされ、受信するまで待機する。受信した段階でS416へ進み、VPの公開鍵KPをデータベース12aから検索して、受信したレスポンスデータIを公開鍵KPで暗号化したDkp(I)を生成する処理がなされる。
次に制御がS417へ進み、チャレンジデータRとDkp(I)が等しいか否かの判断がなされる。等しくなければユーザの本人認証ができなかったこととなりS422へ進み、登録拒否の処理がなされる。S417によりYESの判断がなされた場合には制御がS418へ進み、登録要求を出したユーザに対し登録を希望する個人情報の入力要求を出す処理がなされる。次にS419へ進み、入力があったか否かの判断がなされ、入力があるまで待機する。入力があった段階で制御がS420へ進み、登録対象の個人情報の真偽チェックを行なう。
この真偽チェックは、たとえば、XMLストア50にアクセスして該当するユーザの個人情報が登録されている場合にそれと照合チェックしたり、電子行政群49に含まれる市役所等にアクセスしてそこに登録されている個人情報と照合チェックしたりして行なわれる。このような機械検索による照合チェックだけでは不十分な場合には、金融機関7の調査員が裏取り調査を行なって真偽チェックを行なう。
次に制御がS421へ進み、真偽チェックの結果正しいか否かの判断がなされ、正しくない場合にはS422へ進み登録拒否の処理がなされる一方、正しい場合にはS423へ進み、RPが特定される個人情報か否かの判断がなされる。登録しようとしているVPの個人情報の中に、たとえば勤務先名や所属部署名あるいは役職等のRPが特定されてしまうような個人情報が存在する場合に、それをそのまま登録してしまうと、その登録情報からどのVPがどのRPに対応するかを第三者に予測されてしまう恐れがある。このデータベース12aに登録される個人情報は、S403やS404によりサイト側(業者側)が知り得る状態となる。その結果、サイト側(業者側)に、RPとVPとの対応関係が予測される恐れが生ずる。
そこで、S423により、RPが特定される個人情報か否かの判断がなされ、予測される個人情報でなければS425へ進むが、予測される恐れのある個人情報の場合にはS424へ進み、その個人情報を加工する処理がなされた後S425へ進む。たとえば、勤務先名がMECであった場合には、それをたとえば「某大手電気メーカー」に加工したり、役職がたとえば専務であった場合には、たとえば「重役」に加工したりする。
S425では、個人情報に当該金融機関のデジタル署名を付してユーザ名別に登録する処理がなされる。その結果、図5に示すようなデータがデータベース12aに登録される。
図14は、S401に示されたトラップ情報の登録処理のサブルーチンプログラムを示すフローチャートである。S430により、正当機関証明処理がなされ、S431により、VP氏名の入力要求がトラップ情報の登録依頼をしてきたVPに出される。次にS432へ進み、その登録依頼をしてきたVPが自己のVP氏名を入力したか否かの判断がなされ、入力するまでS431の要求が出される。次に制御がS433へ進み、乱数Rを生成してチャレンジデータとして登録依頼者であるVPに送信する処理がなされる。S434により、レスポンスデータIを受信したか否かの判断がなされる。
送信されてきたチャレンジデータRを受信した登録依頼者であるVPがそのチャレンジデータRを自己の秘密鍵で暗号化してレスポンスデータIを生成し、金融機関7のVP管理サーバ9へ送信する。すると、制御がS435へ進み、登録依頼をしてきたVPの公開鍵KPをデータベース12aから検索し、受信したレスポンスデータIをその公開鍵KPで復号化する処理を行なう。そしてS436により、チャレンジデータR=Dkp(I)であるか否かの判断がなされ、イコールでない場合には認証の結果そのVPが本人と確定できないということであり、S437により登録拒否の通知がそのVPになされる。一方、S436によりYESの判断がなされて認証の結果VPが本人であることが確認できた場合には、制御がS438へ進み、トラップ情報の送信要求をそのVPへ送信する処理がなされる。
VPから登録してもらいたいトラップ情報が送信されてきたか否かがS439によりなされ、送信されてくるまで待機する。送信されてきた段階で制御がS440へ進み、送信されてきたトラップ情報をデータベース12aに記憶させる処理がなされる。このトラップ情報は、登録依頼者であるVPに対応した記憶領域に記憶される。次に制御がS441へ進み、そのトラップ情報に対する電子署名を金融機関7が生成して、その電子証明書をXMLストア50へ登録する処理がなされる。その結果、図7に基づいて説明したように、XMLストア50のデータベース72に電子証明書が格納される。
この電子証明書は、XMLストア50に格納する代わりに登録依頼を行なってきたVPのIC端末19Vに格納してもよい。しかし、トラップ情報は、前述したように、そのVPがアクセスしたWebサイト毎に異なり、その結果電子証明書もWebサイト毎に異なることとなり、多数の電子証明書をIC端末19Vに格納するとなると、記憶容量の問題が生ずる。ゆえに、本実施の形態では、その記憶容量の問題を克服するために、XMLストア50へ登録する。なお、IC端末19Vの記憶容量が非常に大きなものであれば、金融機関7が発行した電子証明書のすべてまたはその大半をこのIC端末19Vに記憶させてもよい。
図15は、S402に示された個人情報の確認処理のサブルーチンプログラムを示すフローチャートである。金融機関7のデータベース12aに登録されている自己の個人情報をユーザが確認したい場合には、ユーザがRPとして金融機関7のVP管理サーバ9へ確認要求を送信する。その確認要求の送信があればS450によりYESの判断がなされ、S451〜S458により、前述したものと同様の本人認証処理がなされる。なお、S452による氏名の入力要求とは、ユーザのRPの氏名の入力要求である。本人認証の結果ユーザが本人であることが確認された場合にはS457によりYESの判断がなされて制御がS459へ進む。
S459では、個人情報の確認要求であったか否かの判断がなされる。この個人情報の確認処理のサブルーチンプログラムは、ユーザから自己の個人情報の変更要求があった場合も対処できるように構成されている。そのユーザからの個人情報の変更要求の場合には、S459によりNOの判断がなされるが、個人情報の確認要求であった場合にはS459によりYESの判断がなされて制御がS460へ進み、入力されたRP氏名に対応する個人情報をそのユーザに送信する処理がなされる。
送信されてきた個人情報を確認したユーザは、その個人情報の中に間違った個人情報がある場合、あるいは、転職や引越し等を行なって個人情報が変更された場合には、自己の個人情報の変更要求を金融機関7のVP管理サーバ9へ送信する。すると、S450aによりYESの判断がなされて制御がS451へ進み、S451〜S458の認証処理が行なわれる。そして認証の結果本人であることが確認された場合にはS457によりYESの判断がなされてS459へ進み、個人情報の確認要求であったか否かの判断がなされる。この場合には、個人情報の変更要求であるために、制御がS459aへ進み、変更したい個人情報(変更情報)の送信要求がそのユーザに対してなされる。
ユーザは、自己の個人情報中のどの箇所をどのように変更したいかという変更情報を金融機関7のVP管理サーバ9へ送信する。すると、S459bによりYESの判断がなされてS461により、その送信されてきた変更情報が正しいか否かの真偽チェックがなされる。次にS462により、そのチェックの結果をユーザに返信する処理がなされる。次にS463により、チェックの結果正しいか否かの判断がなされ、正しくなければ個人情報の変更を行なうことなくそのままこのサブルーチンプログラムが終了するが、正しい場合にはS464へ進み、データベース12a中の個人情報の該当箇所を変更する処理がなされる。
図16は、S403により示された個人情報の照合,流通チェック処理のサブルーチンプログラムを示すフローチャートである。S465により、照合依頼があったか否かの判断がなされる。たとえば、Webサイト側において、アクセスしてきたユーザの住所、氏名、年齢、性別、年収、嗜好情報等の、個人情報を収集した場合に、その個人情報が本当に正しい個人情報であるか否かを金融機関7において照合できるようにしたのが、このサブルーチンプログラムである。そのようなサイト側(業者側)から照合依頼があれば、制御がS466へ進み、金融機関7側の電子証明書をサイト側(業者側)へ送信し、S467により、そのサイト側(業者側)の電子証明書の送信を要求する処理がなされる。その業者側から自己の電子証明書が送信されてくればS468によりYESの判断がなされて制御がS469へ進み、照合したいユーザの氏名をその照合依頼者に要求する処理がなされる。照合依頼者であるサイト側(業者側)が照合したいユーザの氏名を送信してくれば、制御がS473へ進み、照合したい個人情報の送信要求が依頼者側に出される。依頼者側が照合したい個人情報を金融機関7側に送信してくれば、制御がS471へ進む。
S471では、送信されてきた依頼者の電子証明書の業者名(サイト名)と送信されてきた照合対象となるユーザ名とが合致するか否かをトラップ情報に基づいてチェックする処理がなされる。依頼者の電子証明書には、当該依頼者の業者名(サイト名)が記載されている。図4に基づいて説明したように、VPは、Webサイトへアクセスする際に、VPの本名を使う場合もあればトラップ型VPを使う場合もある。つまり、VPは、アクセスするサイト毎に氏名を使い分けているのである。よって、たとえば、図4のMTTから個人情報の照合依頼があった場合には、S470により受信したユーザ氏名は本来E(B13P)の筈である。このように、サイト名とそれに用いられているVP氏名とが一致するか否かがS472により判断され、一致する場合にはS473へ進むが、一致しない場合には図17のS494へ進む。
S494では、XMLストアの該当個人情報を検索して、プライバシーポリシーに定められている流通許容範囲内に依頼者が含まれているか否かをチェックする処理がなされる。業者名(サイト名)とユーザ名とが一致しなければ、即個人情報の不正流通がなされたと判断すべきではなく、VPがサイト側に個人情報を提供する際にある一定の流通許容範囲内においては他の業者にその個人情報を流通(開示)させてもよいことを承諾している場合が考えられる。この流通許容範囲は、サイト側が用意しているプライバシーポリシーに記述されている。そこで、S494により、XMLストアの該当個人情報を検索して、そこに格納されているプライバシーポリシーに定められている流通許容範囲内に依頼者が含まれているか否かをチェックするのである。たとえば、依頼者MTTから送られてきてユーザ名がB13Pであり(図4参照)、そのユーザ名からそれに対応するサイト名ABCを割出すことができる。
その割出されたサイト名ABCに基づいてXMLストア50のデータベース72を検索し、サイト名ABCに付随して格納されている「ポリシー」を検索する(図7参照)。このプライバシーポリシーは、WebサイトABCが個人情報を収集する際にユーザ側に提示したものであり、そのプライバシーポリシーには、収集した個人情報の流通許容範囲が記述されている。その流通許容範囲内に照合依頼者であるMTTが含まれているか否かが、S494によっりチェックされる。含まれている場合にはS494aによりYESの判断がなされてS475へ進むが、含まれていない場合には、その個人情報が不正に流通されたということになり、S495以降の処理がなされる。
S495では、依頼者名に対応させて個人情報の不正入手値を「1」加算更新する処理がなされる。前述した例では、依頼者MTTがVP氏名B13Pを送信してきたということは、サイト(業者)ABCからVP氏名B13Pの個人情報を不正に入手したということである。よって、S495により、不正入手値を「1」加算更新する処理がなされる。この不正入手値は、データベース12bに格納される(図6参照)。
次に制御がS496へ進み、送信されてきたユーザ名に対応するサイト名(業者名)を割出し、そのサイト名(業者名)に対応させて個人情報の不正流出値を「1」加算更新する処理がなされる。前述した例では、送られてきたユーザ名B13Pに対応するサイト名(業者名)ABCを割出し、そのサイト名(業者名)ABCに対応させて個人情報の不正流出値を「1」加算更新する。つまり、サイト(業者)ABCは、VP氏名B13Pの個人情報をMTTに不正に流出させたのであり、そのため、不正流出値を「1」加算更新するのである。この不正流出値も、データベース12bに格納される(図6参照)。
次に制御がS497へ進み、個人情報の不正があった旨およびその詳細データを該当するユーザに通知する処理がなされる。
一方、依頼者の電子証明書に記載されている業者名と送られてきたユーザ名とが合致する場合には、制御がS475へ進み、依頼者から送信されてきた個人情報をデータベース12aの該当するユーザの個人情報(図5参照)と照合する処理がなされる。次にS476により、照合対象となっているユーザのユーザエージェントをXMLストアから呼出す処理がなされる。次にS477により、そのユーザエージェントに照合結果を知らせ、依頼者に返信してよいか否かを尋ねる処理がなされる。ユーザエージェントからの返答があれば、制御がS479へ進み、依頼者に返信してよい旨の返答であった場合には、制御がS486へ進み、照合結果、正しい個人情報にデジタル署名を付す処理がなされる。このデジタル署名は、正しい個人情報である旨を金融機関7が確認したことを表わすものである。次にS487により、そのデジタル署名を付した個人情報を依頼者に返信して、それ以外は誤りである旨を依頼者に通知する処理がなされる。なお、依頼者から送信されてきた個人情報に相当するユーザの個人情報がデータベース12aになかった場合には、照合できないために、その照合できなかった個人情報について照合できなかった旨を依頼者に返信する。
一方、ユーザエージェントからの返答の結果がOKでなかった場合には制御がS480へ進み、依頼者への返信の条件としてその依頼者(業者)から見返りを要求するという内容の返答がユーザエージェントからなされたか否かの判断がなされる。ユーザエージェントは、OKの返答と見返り要求の返答と依頼者への返信を拒否する返答との3種類の返答を行なう。依頼者への返信を拒否する返答であった場合には、制御がS481へ進み、回答拒否を依頼者に返信する処理がなされる。
見返りを要求する返答であった場合には、制御がS482へ進み、出された見返り要求を依頼者に返信する処理がなされる。次にS483により、依頼者からの返答があったか否かの判断がなされ、返答があるまで待機する。返答があった段階でS484により、交渉が成立したか否かの判断がなされる。交渉不成立の場合には制御がS481へ進み、回答を拒否する旨を依頼者に返信する処理がなされる。交渉が成立したと判断される場合にはS485へ進み、交渉が成立した旨をユーザに通知する処理がなされる。それと同時に、金融機関7のVP管理サーバ9は、交渉によって決定された見返り内容を記憶しておく。次に、制御がS486へ進む。
図17の(b)は、S404により示された個人情報の販売代行処理のサブルーチンプログラムを示すフローチャートである。S498により、個人情報の購入要求があったか否かの判断がなされる。業者側から金融機関7のVP管理サーバ9に個人情報の購入要求があれば、制御がS499へ進み、金融機関7の電子証明書をその購入要求者に送信する処理がなされる。次にS500により、購入要求者の電子証明書の送信をその購入要求者に要求する処理がなされる。購入要求者から電子証明書の送信があれば制御がS502へ進み、購入対象のユーザ名を購入要求者に要求する処理がなされる。購入要求者から購入対象のユーザ名の送信があれば、制御がS504へ進み、送信されてきたユーザ名のユーザエージェントをXMLストア50から呼出す処理がなされる。
次にS505により、そのユーザエージェントと購入依頼者とで直接交渉させる処理がなされる。この交渉は、購入要求者に対し個人情報を提供してもよいか否か、また提供するにあたってはどの程度の見返りを要求するか、またその見返り内容は金銭の支払かあるいはサービスの提供か等の交渉である。S506により、交渉が成立したか否かの判断がなされ、不成立の場合には、S507により、販売を拒否する旨を依頼者(購入要求者)に返信する処理がなされる。交渉が成立していると判断された場合には、制御がS508へ進み、ユーザ名,購入依頼者名,見返り等の販売条件,個人情報の開示許容範囲(流通許容範囲)を含むプライバシーポリシーに対し、ユーザ,依頼者(購入要求者),金融機関7のそれぞれのデジタル署名を付して記憶する処理がなされる。次にS509により、販売が決定された金融機関7のデジタル署名を付して依頼者に返信する処理がなされる。
金融機関7のデータベース12aに格納されている個人情報は、その金融機関によって真偽チェックがなされて正しい個人情報のみが格納されており、その正しい個人情報を業者に提供する場合やその正しい個人情報との照合結果を業者に提供する場合には、S486、S509により金融機関7のデジタル署名が付される。よって、業者が所有する個人情報のうち金融機関7のデジタル署名が付されていない個人情報については、誤りの可能性のある個人情報であり、金融機関7のデジタル署名が付されている個人情報は正しい個人情報であることが、一目瞭然でわかる。
図18は、S405に示されたメール転送,流通チェックのサブルーチンプログラムを示すフローチャートである。S514により、サイト(業者)からメールが送られてきたか否かの判断がなされる。図4等に基づいて説明したように、VPが、本名を用いてサイトにアクセスした場合にはVP自身のEメールアドレスをそのサイト側に通知するが、トラップ型VP氏名を用いてサイトにアクセスした場合には、金融機関7のトラップ型VP用として開設されているEメールアドレスをそのサイト側に提供する。その結果、そのサイトからのEメールは、金融機関7のトラップ型VP用に開設されたEメールアドレスで送られてくることとなる。
金融機関7では、そのトラップ型VP用に開設したEメールアドレスに送信されてきたメールがある場合には、VP管理用サーバ9は、S514により、YESの判断を行なう。その結果、制御がS515へ進み、その送られてきたEメールに含まれている宛名に対応するサイト名(業者名)をデータベース12aから割出す処理を行なう。データベース12aは、図4に基づいて説明したように、VPの氏名とそのVPがアクセスしたサイト名とが対応付けられて記憶されている。この対応関係を利用して、メールの宛名から対応するサイト名(業者名)を割出す処理がなされる。
次にS516により、割出されたサイト名とEメールを送ったサイト名とが一致するか否かの判断がなされる。本来なら一致する筈であるが、個人情報が不正に流通された場合には、その不正流通された個人情報を不正入手したサイトがその個人情報主にEメールを送る場合がある。その場合には、割出されたサイト名とメールを送ったサイト名とが一致しない状態となる。
割出されたサイト名とメールを送ったサイト名とが一致しない場合に、即座に個人情報が不正流通されたとは断定できない。サイト側に個人情報を提供する際に、ある一定の流通許容範囲内においては流通させてもよいと個人情報主であるユーザから承諾を得ている場合がある。よって、図17のS494,S494aで説明したのと同様に、S522に制御が進み、XMLストアの該当個人情報を検索して、ポリシーに定められている流通許容範囲内にEメール送信者が含まれるか否かチェックする処理がなされ、S523により、含まれると判断された場合には制御がS517へ進むが、含まれないと判断された場合には制御がS519へ進む。
S519では、Eメールを送ったサイト名に対応させて個人情報の不正入手値を「1」加算更新する処理がなされ、S520により、S515によって割出されたサイト名に対応させて個人情報の不正流出値を「1」加算更新する処理がなされる。次にS521により、個人情報の不正があった旨およびその詳細データを該当するユーザへ通知する処理がなされる。
一方、個人情報が不正流通されていないと判断された場合には制御がS517へ進み、Eメールの宛名に対応するユーザのメールアドレスを割出す処理がなされ、S518により、その割出されたアドレスにEメールを転送する処理がなされる。
図19は、S406に示された他のトラップ型VPのアクセス履歴の提供処理のサブルーチンプログラムを示すフローチャートである。前述したように、VPがトラップ型VPとしてサイトにアクセスした場合には、そのサイト側から送られてくるクッキーはそのトラップ型VPのみに対応してVPをIC端末19Vに記憶される(図11参照)。よって、トラップ型VPとしてアクセスを受けたサイト側では、そのトラップ型VPのみのアクセス履歴や購買履歴しか収集できず、そのトラップ型VPが他のトラップ型VPとしてまたはVPの本名を用いてネットワーク上で行動したその行動履歴(アクセス履歴等)は、何ら集計できない。このような場合において、そのサイト側から他のトラップ型VP(本名を用いたVPを含む)のアクセス履歴等のネットワーク上の行動履歴のデータを提供してもらいたいという依頼が、金融機関7にあった場合には、S530によりYESの判断がなされて制御がS531へ進み、金融機関7の電子証明書を送信する処理がなされる。
次にS532により、依頼者の電子証明書の送信をその依頼者に要求する処理がなされる。電子証明書がその依頼者から送信されてきた段階でS533によりYESの判断がなされて制御がS534へ進み、提供してもらいたいユーザの氏名を依頼者に対し要求する処理がなされる。次にS535へ進み、依頼者からユーザの氏名の送信があったか否かの判断がなされ、あった場合にS536へ進み、ユーザの許可証の送信をその依頼者に要求する処理がなされる。ユーザは、トラップ型VPとしてサイトにアクセスして個人情報を提供する際に、他のトラップ型VP(本名を用いたVPを含む)のアクセス履歴等のネットワーク上の行動履歴データも提供してよい旨の承諾を行なう場合がある。
つまり、図4を参照して、たとえばVPがトラップ型VPであるE2(B13P)としてサイトMECにアクセスして個人情報を提供した際に、他のトラップ型VPであるE(B13P)が本名B13Pを用いたVPのアクセス履歴等のネットワーク上の行動履歴データも併せてそのサイトMECに提供してもよいことを承諾する場合がある。その場合には、ユーザは、その旨を示す電子的な許可証をそのサイトに送信する。この許可証は、ユーザのデジタル署名が付されている。S536の要求に応じてサイトがその許可証を送信すれば、S537によりYESの判断がなされ、S539によりその許可証が適正であるか否かの判断がなされる。適正でない場合にはS545により、アクセス履歴の提供を拒否する通知が依頼者に送信されるが、適正である場合にはS540により、送信されてきたユーザ氏名に対応する他のトラップ型VP(本名を用いたVPを含む)のアクセス履歴等のネットワーク上での行動履歴データを割出してその依頼者に送信する処理がなされる。
一方、依頼者であるサイト側がユーザの許可証を持っていない場合には、許可証なしの返信を金融機関7に送信する。すると、S538によりYESの判断がなされて制御がS541へ進み、当該ユーザのユーザエージェントをXMLストア50から呼出す処理がなされ、S542により、そのユーザエージェントと依頼者であるサイト側とを直接交渉させる処理がなされる。
次にS543により、交渉が成立したか否かの判断がなされる。交渉不成立の場合にはS545によりアクセス履歴の提供を拒否する通知が依頼者側に送信される。一方、交渉成立の場合には制御がS544へ進み、個人情報主であるユーザが無条件で許諾したか否かの判断がなされる。無条件で許諾した場合には、制御がS540へ進み、アクセス履歴等の行動履歴データを依頼者側に送信する処理がなされる。一方、ユーザが条件付きの許諾を行なった場合には、制御がS546へ進み、その条件を記憶する処理がなされた後、S540へ進む。S546による条件を記憶する際には、交渉の当事者であるユーザおよび依頼者の名前と決定された条件とを個人情報の開示許容範囲(流通許容範囲)を含む依頼者側のプライバシーポリシーとに対し、交渉の当事者,金融機関7のそれぞれのデジタル署名を付して記憶する。
図20は、S407により示された信頼度ランキング情報の集計,提供処理のサブルーチンプログラムを示すフローチャートである。このサブルーチンプログラムは、データベース12bの記憶データに基づいてVP管理サーバ9が動作するためのものである。S550により、各サイト(業者)毎に、J=不正入手値+不正流出値×2 を算出する処理がなされる。これは、個人情報を不正に入手した者よりも個人情報を不正に流出(流通)させた者の方が、悪質であり罪が重たいために、×2を行なっているのである。
次にS551により、算出されたJが大きい順に悪い順位を算出して各サイト(業者)毎にデータベース12bに記憶させる処理がなされる。次にS552により、順位の公表要求があったか否かの判断がなされる。個人情報主であるユーザあるいは業者等から順位の公表要求が金融機関7のVP管理サーバ9にあった場合には、制御がS553へ進み、その要求者に対し順位データを送信する処理がなされる。
図21は、図3に示した認証用サーバ11の処理動作を示すフローチャートである。まずS25により,RPから電子証明書の発行依頼があったか否かの判断がなされ、あるまで待機する。ユーザであるRPがブラウザフォン30からRPの電子証明書の発行依頼要求を認証用サーバ11へ送信すれば、制御がS26へ進み、RPの住所,氏名,公開鍵の送信要求をブラウザフォン30へ送信する処理がなされる。次にS27へ進み、ブラウザフォン30からRPの住所,氏名,公開鍵の返信があるか否かの判断がなされ、あるまで待機する。そして、返信があった段階で制御がS28へ進み、RPの電子証明書を作成してブラウザフォン30へ送信する処理がなされる。次にS29へ進み、RPの住所,氏名,公開鍵KPをデータベース12aに記憶する処理がなされてS25へ戻る。
図22〜図24は、図3の決済サーバ10の処理動作を示すフローチャートである。S35により、RPの銀行口座番号の作成依頼があったか否かの判断がなされ、ない場合にはS39へ進み、VPの銀行口座番号の作成依頼があったか否かの判断がなされ、ない場合にはS40へ進み、デビットカードの発行要求があったか否かの判断がなされ、ない場合にはS41へ進み、決済要求があったか否かの判断がなされ、ない場合にはS35へ戻る。
このS35〜S41のループの巡回途中で、ユーザが金融機関7へ出向き、RPの銀行口座の開設依頼を行なってRPの銀行口座番号の作成依頼が入力されれば、制御がS36へ進み、RPの住所,氏名等の入力要求がなされ、入力があれば制御がS38へ進み、RPの銀行口座を作成して、データベース12aに記憶するとともにRPに通知する処理がなされてS35へ戻る。
ユーザが金融機関7へ出向き、VPの銀行口座の開設依頼を行なってVPの銀行口座番号の作成依頼要求が入力されれば、S42へ進み、VPの住所,氏名等,RPの住所,氏名等の入力要求がなされる。ユーザは、これら情報を手動でキーボードから入力するか、または、決済サーバ10にRP用IC端末19RやVP用IC端末19Vを接続してこれらデータを自動入力する。データが入力されれば、制御がS44へ進み、RPとVPの対応が適正であるか否かが、データベース12aを検索することにより確認される。
RPとVPの対応が適正でない場合にはS51へ進み、対応が不適正である旨を報知してS35へ戻る。一方、RPとVPとの対応が適正な場合にはS45へ進み、VPの銀行口座を作成して、データベース12aに記憶するとともに、VPに対応するRPにその銀行口座を郵送する処理がなされた後S35へ戻る。
ユーザが金融機関7へ出向き、デビットカードの発行要求の依頼を行なってデビットカードの発行要求の入力があれば、S40によりYESの判断がなされてS46へ進み、口座番号と氏名と暗証番号の入力要求がなされる。ユーザがRP用のデビットカードの発行を要求する場合には、RPの銀行口座番号と氏名と暗証番号を入力する。一方、ユーザがVP用のデビットカードの発行要求を希望する場合には、VPの銀行口座番号とVPの氏名とVPの暗証番号とを入力する。これらのデータの入力は、RP用IC端末19RまたはVP用IC端末19Vを決済サーバ10へ接続して自動的に入力する。
これらデータの入力が行なわれれば制御がS48へ進み、入力データをデータベース12aへ記憶するとともに、デビットカードを発行する処理がなされる。次にS49へ進み、発行されたデビットカードの記憶データをRP用IC端末またはVP用IC端末へ伝送する処理がなされてS35へ戻る。
決済サーバ10に決済要求が送信されてくれば、S41によりYESの判断がなされてS50へ進み、決済処理がなされた後S35へ戻る。
図23は、図22に示したS50の決済処理のサブルーチンプログラムを示すフローチャートである。決済要求には、銀行口座内の資金を一部RP用IC端末19RまたはVP用IC端末19Vに引落す引落し要求と、デビットカードを使用しての決済要求と、クレジットカードを使用して決済を行なった場合のクレジットカード発行会社からのクレジット使用金額の引落し要求とがある。まずS55よりIC端末19Rまたは19Vへの引落し要求があったか否かの判断がなされ、ない場合にはS57へ進み、デビットカードを使用しての決済要求があったか否かの判断がなされ、ない場合にはS58へ進み、クレジットカード発行会社からの引落し要求があったか否かの判断がなされ、ない場合にはS554へ進み、クレジットカード発行会社からの問合せ処理が行なわれた後、S59によりその他の処理がなされてこのサブルーチンプログラムが終了する。
ユーザがブラウザフォン30等からRP用IC端末19RまたはVP用IC端末19Vへ資金の一部引落し要求を決済サーバ10へ送信した場合には、S55によりYESの判断がなされてS56へ進み、正当機関証明処理がなされた後S60へ進む。S60では、氏名の入力要求をブラウザフォン30等へ送信する処理がなされる。その要求を受けたブラウザフォン30では、接続されているIC端末19Rまたは19Vに対し氏名の出力要求を伝送する。すると、接続されているIC端末19Rまたは19Vから氏名がブラウザフォン30へ伝送され、その伝送されてきた氏名をブラウザフォン30が決済サーバ10へ伝送する。すると、S61によりYESの判断がなされてS62へ進み、乱数Rを生成してチャレンジデータとしてブラウザフォン30へ送信する処理がなされる。
その乱数Rを受けたブラウザフォン30は、後述するように、接続されているIC端末19Rまたは19Vに対し乱数Rを伝送する。乱数Rを受取ったIC端末がRP用IC端末19Rの場合には、記憶している認証鍵KNを用いてRを暗号化してレスポンスデータIを生成し、それをブラウザフォン30へ出力する。ブラウザフォン30では、その出力されてきたレスポンスデータIを決済サーバ10へ送信する。一方、乱数Rを受取ったIC端末がVP用IC端末19Vの場合には、受取った乱数Rを記憶している公開鍵KPを用いて暗号化してレスポンスデータIを生成し、ブラウザフォン30へ出力する。ブラウザフォン30では、その出力されてきたレスポンスデータIを決済サーバ10へ送信する。
レスポンスデータIが送信されてくれば、S63によりYESの判断がなされてS64に進み、S60に応じて入力された氏名がRPのものであるか否かが判別され、RPの場合にはS65へ進み、RPの認証鍵KNをデータベース12から検索してその認証鍵KNを用いて受信したレスポンスデータIを復号化する処理すなわちDKN(I)を生成する処理がなされる。次にS66へ進み、R=DKN(I)であるか否かの判断がなされる。IC端末への引落し要求を行なったユーザがデータベース12に登録されている適正なユーザである場合には、R=DKN(I)となるはずであるが、データベース12に登録されているユーザになりすまして銀行口座の資金の一部を引落しするという不正行為が行われた場合には、RとDKN(I)とが一致しない状態となる。その場合には制御がS79へ進み、不適正である旨をブラウザフォン30へ返信する処理がなされてサブルーチンプログラムが終了する。
一方、R=DKN(I)の場合には制御がS67へ進み、引落し額の入力要求をブラウザフォン30へ送信する処理がなされ、引落し額がブラウザフォン30から送信されてくれば、制御がS69へ進み、RPの口座から引落し額Gを減算してGをブラウザフォン30へ送信する処理がなされてサブルーチンプログラムが終了する。
一方、ユーザがVPとしてVP用IC端末19Vへの引落しを行なう場合には、VPの本名を用いる。入力された氏名がVPの本名であった場合にはS64によりNOの判断がなされて制御が図9のS85へ進む。S85では、VPの公開鍵KPをデータベース12から検索してその公開鍵KPを用いて受信したレスポンスデータIを復号化する処理すなわちDKP(I)を生成する処理がなされる。次にS86へ進み、R=DKP(I)であるか否かの判断がなされる。引落し要求を行なっているものがデータベース12に登録されているVPになりすまして引落すという不正行為を行なっている場合には、S86によりNOの判断がなされてS79に進み、不適正である旨がブラウザフォン30へ返信されることとなる。一方、S86によりYESの判断がなされた場合にはS87へ進み、引落し額Gの入力要求をブラウザフォン30へ送信する処理がなされ、ブラウザフォン30から引落し額Gの送信があれば、S89へ進み、VPの銀行口座からGを減算してGをブラウザフォン30へ送信する処理がなされた後サブルーチンプログラムが終了する。
ユーザがデビットカードを使用しての決済を行なうべくデビットカード使用操作を行なった場合には、デビットカード使用要求が決済サーバ10へ送信され、S57によりYESの判断がなされてS56へ進み、正当機関証明処理がなされる。次にS70へ進み、暗証番号とカード情報入力要求がユーザのブラウザフォン30へ送信される。デビットカードの暗証番号とデビットカード情報とがブラウザフォン30から決済サーバ10へ送信されてくれば制御がS72へ進み、その送信されてきたデータが適正であるか否かの判断がなされ、不適正であればS79へ進む。
一方、適正である場合にはS73へ進み、使用額Gの入力を待つ。ユーザが使用額Gを入力してそれが決済サーバ10へ送信されてくれば制御がS74へ進み、該当する口座を検索してGを減算するとともにGをユーザのブラウザフォン30に送信する処理がなされる。
ユーザがRPまたはVPの本名を用いて後述するようにクレジットカードによるSETを用いた決済を行なった場合には、クレジットカード発行会社4(図1,図15参照)からクレジット支払金額の引落し要求が決済サーバ10へ送信される。その引落し要求が送信されてくればS58によりYESの判断がなされてS56の正当機関証明処理がなされた後S75へ進み、ユーザの氏名,口座番号の入力を待つ。クレジットカード発行会社4からユーザの氏名と口座番号とが送信されてくれば制御がS76へ進み、その入力されたデータが適正であるか否かをデータベース12を検索して判別する。不適正の場合にはS79へ進むが、適正な場合にはS77へ進み、引落し額Gの入力を待機する。クレジットカード発行会社4から引落し額Gすなわちクレジット支払額と手数料との合計金額が送信されてくれば制御がS78へ進み、口座からGを減算してクレジットカード発行会社の口座Gに加算する処理すなわち資金の移動処理がなされる。
S58によりNOの判断がなされた場合にはS554によるクレジット発行会社4からの問合せ処理が行なわれた後S59へ進み、その他の処理が行なわれる。
図24(b)は、前述したS1a,S19,S56に示された正当機関証明処理のサブルーチンプログラムを示すフローチャートである。まずS90により、当該機関の電子証明書を送信する処理がなされる。この電子証明書を受信した側においては、乱数Rを生成してその乱数Rを送信する。すると、S91によりYESの判断がなされてS92へ進み、その受信した乱数Rを当該機関の秘密鍵KSで暗号化する処理すなわちL=EKS(R)を算出する処理がなされ、その算出されたLを返信する処理がなされる。
このLを受信した受信側においては、既に受信している電子証明書内の当該機関の公開鍵KPを利用してLを復号化することによりRを得ることができる。そのRと送信したRとがイコールであるか否かをチェックすることにより、正当機関であるか否かをチェックすることが可能となる。これについては後述する。
図25は、S554に示されたクレジットカード会社からの問合せ処理のサブルーチンプログラムを示すフローチャートである。前述したように、VPがトラップ型VPとしてサイトにアクセスして電子ショッピング等を行なってクレジット決済を行なった場合には、VP本人のクレジット番号が用いられるのではなく、そのVP本人のクレジット番号を何回か秘密鍵で暗号化した暗号化クレジット番号が用いられることとなる。たとえば、図4に示すように、トラップ型VP氏名E(B13P)としてサイトMPPにアクセスしたVPは、電子ショッピング等を行なってクレジット決済をする際には、バーチャルクレジット番号E(3288)を用いる。VPは、クレジットカード発行会社4に対し3288のクレジット番号は登録しているが、E(3288)の暗号化クレジット番号までは登録していない。よって、E(3288)のバーチャルクレジット番号がクレジット決済に伴ってクレジットカード発行会社4に送信されてきた場合には、クレジットカード発行会社4は、そのE(3288)のバーチャルクレジット番号を自社で検索して真偽を確かめることはできない。
そこで、そのような場合に、クレジットカード発行会社は、金融機関7にそのバーチャルクレジット番号が正しいか否かの照会を行なってもらうのである。
クレジットカード発行会社からの問合せがあれば制御はS561へ進み、S561〜S568の前述したものと同様の認証処理が行なわれる。認証の結果本人が確認されればS567によりYESの判断がなされてS569へ進み、照会対象データの入力要求がクレジットカード発行会社に送信される。この照会対象データとは、前述したバーチャルクレジット番号とトラップ型VP氏名とを含む。このトラップ型VP氏名をも入力されることにより、そのトラップ型VP氏名とバーチャルクレジット番号とが対応しているか否か等も照会できる。
照会対象データがクレジットカード発行会社から送信されてくれば制御はS571へ進み、データベース12aを検索してその送信されてきた照会対象データと照合する処理がなされる。次にS572により、照合結果送られてきた照会対象データが適正であるか否かの判断がなされ、適正な場合にS573により、適正な旨をクレジットカード発行会社へ返信し、照合結果適正でない場合にはS574により、不適正な旨がクレジットカード発行会社に返信される。S573による適正な旨を返信する際には、S570により入力された照会対象データに対し適正な旨を表わす金融機関7側のデジタル署名を付し、そのデジタル署名付きデータが問合せをしたクレジットカード発行会社4へ返信されることとなる。
図26〜図31,図33〜図36は、ブラウザフォン30の動作を説明するためのフローチャートである。S95により、IC端末使用モードであるか否かの判断がなされる。ブラウザフォン30は、RP用IC端末19RまたはVP用IC端末19Vのうちのいずれか少なくとも一方をUSBポート18に接続していなければ動作しないIC端末使用モードと、IC端末を接続していなくても動作可能なIC端末未使用モードとに切換えることが可能に構成されている。そして、IC未使用モードでない場合にはS96へ進み、その他の処理がなされるが、IC端末使用モードになっている場合には、S97へ進み、VP用IC端末19Vが接続されているか否かの判断がなされ、接続されていない場合にはS98へ進み、RP用IC端末19Rが接続されているか否かの判断がなされ、接続されていない場合すなわち両IC端末ともに接続されていない場合には、制御はS99へ進み、IC端末未使用の警告表示がなされた後S95へ戻る。
一方、VP用IC端末19Vが接続されている場合には、制御はS100へ進み、VP用のクッキー処理がなされる。この処理については、図27に基づいて後述する。ブラウザフォン30は、サイト側から送られてきたクッキーデータを記憶するための記憶領域を有していない。ゆえに、サイト側から送られてきたクッキーデータであって記憶する必要のあるものは、すべてVP用IC端末19VまたはRP用IC端末19Rに記憶される。次に制御はS101へ進み、VP出生依頼処理がなされる。この処理については図29に基づいて後述する。次にS102へ進み、VP用入力処理がなされる。この処理については図31(a)に基づいて後述する。次にS103へ進みVP用決済処理がなされる。この処理については図33に基づいて説明する。
次に制御がS580へ進み、個人情報の登録処理がなされる。この個人情報の登録処理は、図13(b)に示したVP管理サーバ9の登録処理に対応するブラウザフォン30側の処理である。まずVPとしての本人認証処理を行ない、VP管理サーバ9が本人認証の確認を行なったことを条件として、VPの個人情報を金融機関7のVP管理サーバ9へ送信してデータベース12aに登録してもらう処理を行なう。
次に制御がS582へ進み、個人情報の確認処理がなされる。この処理は、金融機関7のVP管理サーバ9により図15に示された確認処理に対応してブラウザフォン30によりなされる処理である。まずVPとしての本人認証がなされ、次に、データベース12aに格納されている自分の個人情報の確認を行なう処理がなされる。一方、確認の結果誤りがある場合あるいは引越しや転職等によって個人情報に変更があった場合には、このS582により、その変更情報が、金融機関7のVP管理サーバ9へ送信される。
次に制御がS583へ進み、VP用Webブラウザ,メール処理がなされる。この処理は、図36(a)に基づいて後述する。次に制御がS585へ進み、住所,氏名,Eメールアドレスの送信処理が行なわれる。一方、ブラウザフォン30のUSBポート18にRP用IC端末19Rが接続されている場合には、S98によりYESの判断がなされてS104へ進み、RP用のクッキー処理がなされる。この処理については図28(b)に基づいて後述する。次にS105へ進み、電子証明書発行要求処理がなされる。この処理については図30(b)に基づいて後述する。次に制御がS106へ進み、RP用入力処理がなされる。この処理については図31(b)に基づいて後述する。次にS107へ進み、RP用決済処理がなされる。この処理については、VP用決済処理と類似した制御処理であり、図示を省略する。次に制御がS584へ進み、偽RPアクセス処理がなされる。この偽RPアクセス処理は、図36(b)に基づいて後述する。
図27は、S102により示されたクッキー処理のサブルーチンプログラムを示すフローチャートである。S110により、暗証番号が適正である旨のチェックが済んでいるか否かの判断がなされる。チェック済みである場合にはS120へ進むが、まだチェック済みでない場合にはS111へ進み、暗証番号の入力要求を表示する。ユーザがブラウザフォン30のキーボード77からVP用IC端末19Vの暗証番号を入力すれば、制御がS113へ進み、入力された暗証番号をVP用IC端末19Vへ伝送する処理がなされ、VP用IC端末から適否の返信があるまで待機する(S114)。暗証番号が入力されたVP用IC端末19Vでは、後述するように、記憶している暗証番号と入力された暗証番号とを照合して一致するか否かの判断を行ない、一致する場合には適正である旨の返信を行ない、一致しない場合には不適正である旨の返信を行なう。適正である旨が返信されてきた場合には、S115によりYESの判断がなされるが、不適正である旨が返信されてきた場合には制御がS116へ進み、不適正である旨の報知(表示)がブラウザフォン30によりなされる。
適正である場合にのみ暗証番号チェック済み状態となり、制御がS119へ進み、Webサイトへのアクセス操作があったか否かの判断がなされ、ない場合にはS120に進み、その他の処理がなされてこのサブルーチンプログラムが終了する。一方、サイトへのアクセス操作があった場合にはS590へ進み、そのサイトにトラップ型VPを既に使用しているか否かを、VP用IC端末19Vに問う処理がなされる。VP用IC端末19Vは、図11に基づいて説明したように、クッキーデータの記憶領域に、アクセスしたサイト名とそれに用いたVP氏名とを記憶している。VP用IC端末では、ブラウザフォン30から問合せがあったサイトにトラップ型VPを使用しているか否かを、このクッキーデータ記憶領域を検索して割出す。そしてその回答をブラウザフォン30へ返信する。すると、制御はS592へ進み、その回答がトラップ型VPを使用済みという内容であるか否かの判断がなされる。使用済みであるとの回答内容であった場合には、制御はS593へ進み、使用しているトラップ型VPとそれに対応するクッキーとをVP用IC端末のクッキーデータ記憶領域から呼出し、そのクッキーとともにサイトへアクセスする処理がなされる。
次に制御がS594へ進み、アクセスしたサイトからクッキーが送信されてきたか否かの判断がなされ、送信されてきていない場合にはこのサブルーチンプログラムが終了する。一方、クッキーデータとともにサイトへアクセスしたとしても、そのサイトの別のページをアクセスした際にさらに別のクッキーがサイト側から送られてくる場合がある。そのようなクッキーが送られてきた場合には、S594によりYESの判断がなされて制御がS595へ進み、トラップ型VP氏名と送られてきたクッキーデータとをVP用IC端末へ転送する処理がなされる。VP用IC端末では、伝送されてきたクッキーデータを伝送されてきたトラップ型VP氏名に対応させて記憶させる処理が行なわれる。
S592により、トラップ型VPがまだ使用されていないサイトであると判断された場合には、制御がS596へ進み、トラップ型VPの使用の有無をユーザに尋ねる処理が行なわれる。具体的には、ブラウザフォン30の表示部76に、「トラップ型VPを使用しますか?」の表示を行なう。
次にS597により、使用する旨の操作がキーボード77から入力されたか否かの判断がなされる。使用しない旨の操作が行なわれた場合には制御がS121へ進むが、使用する旨の操作が行なわれた場合には、制御がS598へ進み、VP用IC端末19Vへ新たなトラップ型VPの生成を要求する処理がなされる。このS598の処理は、S119によりアクセス操作がされたサイト名とトラップ型VPの生成を要求する指令とを、VP用IC端末19Vへ伝送するものである。
VP用IC端末では、その要求を受ければ、クッキーデータ領域に記憶されているVP氏名の最後のもの(図11ではE3(B13P)が何回暗号化されているかを判別し(図11では3回)、その暗号化回数よりも1つ多い暗号化回数(図11では4回)VP氏名の本名(B13P)を暗号化して新たなトラップ型VP氏名E4(B13P)を生成する。そしてその生成された新たなトラップ型VPをブラウザフォン30へ出力する。すると、S599によりYESの判断がなされてS600へ進み、VP用IC端末から送られてきたトラップ型VPの氏名を用いてサイトへアクセスする処理がなされる。よって、サイト側から氏名を要求されれば、その新たなトラップ型VP氏名E4(B13P)を伝送する。ただし、住所はB13Pの住所すなわち、VP本人のコンビニエンスストアの住所を伝送する。またEメールアドレスは、金融機関7がトラップ型VP用として開設しているEメールアドレスである△△△△△を伝送する。
次に制御がS581へ進み、トラップ情報の登録処理がなされる。このトラップ情報の登録処理は、S598に従って新たなトラップ型VPが生成されたために、その新たに生成されたトラップ型VPをデータベース12aに登録してもらうために金融機関7のVP管理サーバ9へ送信するための処理である。この処理は、たとえば後述するS143〜S145,S150〜S152,S160〜S163と同様のセキュリティのためのチェック処理を行ない、その後新たに生成されたトラップ型VPのデータすなわちトラップ型VP氏名,そのトラップ型VP氏名を用いるサイト名,公開鍵,バーチャル口座番号,バーチャルクレジット番号を送信する処理である。
次に制御がS601へ進み、サイト側からクッキーが送信されてきたか否かの判断がなされる。送信されてきた場合には制御がS602へ進み、そのサイトに使用しているトラップ型VP氏名と送られてきたクッキーデータとをVP用IC端末へ伝送する処理がなされる。VP用IC端末では、その伝送されてきたクッキーデータを伝送されてきたトラップ型VP氏名に対応する領域に記憶させる処理を行なう。
S597により、トラップ型VPを使用しない旨の操作がなされたと判断された場合には制御がS121へ進み、VP用IC端末からVP用のクッキーすなわちVPの本名(図11ではB13P)に対応して記憶されているクッキー(図11ではabc,hij,amz,rak…)を呼出し、それらクッキーとともにサイトへアクセスする処理がなされる。
この場合には、そのアクセスしたサイトでは、VP本名を用いることとなる。
次に制御がS122へ進み、サイトからクッキーが送信されてきたか否かの判断がなされる。サイト側からクッキーが送信されてくれば、制御がS123へ進み、その送信されてきたクッキーをVP用IC端末19Vへ伝送する処理がなされる。VP用IC端末19Vでは、クッキーデータが単独で伝送されてくれば、自動的にVP本名に対応する記憶領域にその伝送されてきたクッキーデータを記憶する処理を行なう。
図28(a)は、S585により示された住所,氏名,Eメールアドレスの送信処理のサブルーチンプログラムを示すフローチャートである。S700により、サイト側から住所,氏名,Eメールアドレスの送信要求があったか否かの判断がなされ、ない場合にはこのサブルーチンプログラムが終了する。あった場合には制御がS701へ進み、そのサイトに使用しているVPの氏名,住所,Eメールアドレスを送信する処理がなされる。たとえば図11に示す例の場合には、サイトMTTに使用しているVP氏名はE(B13P)であるために、この氏名E(B13P)を送信する。住所は、B13Pの住所すなわち□△〇である(図3参照)。Eメールアドレスは、金融機関7がトラップ型VP用として開設しているEメールアドレス△△△△△が送信される。
このVP用のクッキー処理と住所,氏名,Eメールアドレスの送信処理とが行なわれた結果、あるサイトにトラップ型VPとしてアクセスした場合には以降そのサイトにアクセスした際自動的に前回のトラップ型VP氏名が用いられて前回のトラップ型VPとしてアクセスする状態となる。またサイト側から送られてくるクッキーデータも、そのサイトに対応するトラップ型VP氏名に付着する状態となる。具体的には、図11を参照して、サイトMTTにトラップ型VP氏名E(B13P)を使用して一旦アクセスすれば、それ以降においては、MTTにアクセスする場合には必ずこのトラップ型VP氏名E(B13P)が用いられ、その際には、前回MTTから送られてきたクッキーmttとともにMTTにアクセスすることとなる。一方、VPがその本名B13Pを用いてMTTにアクセスすることはできない。このようなアクセスを行なおうとした場合には、S592によりYESの判断がなされてS593により、自動的にE(B13P)としてMTTにアクセスする状態となる。
VP用IC端末19Vを使用している場合には、VPの氏名や住所等がサイト側に収集されることはあっても、RPの氏名や住所等がサイト側に収集されることがないために、ユーザ側においてもプライバシーを保護することが可能となる。
しかも、トラップ型VP氏名を利用することにより、前述したように、個人情報の不正流出等をチェックすることが可能となる。
図28(b)は、S104に示されたRP用のクッキー処理のサブルーチンプログラムを示すフローチャートである。S125により、暗証番号のチェック済みであるか否かの判断がなされ、暗証番号が適正な旨のチェックが既に行なわれている場合にはS125によりYESの判断がなされてS132へ進む。一方、適正な暗証番号である旨のチェックが済んでいない場合にはS126へ進み、暗証番号の入力要求がなされ、RP用IC端末19Rの暗証番号をユーザがキーボードから入力すれば、S128へ進み、入力された暗証番号とRP用IC端末へ伝送する処理がなされる。そしてRP用IC端末19Rから暗証番号の適否の返信があるまで待機する(S129)。
RP用IC端末19Rから暗証番号の適否の判定結果が返信されてくれば、S130へ進み、適正である旨の返信結果であるか否かの判断がなされ、適正でない場合にはS131へ進み、不適正である旨の報知(表示)がなされる。一方、適正である旨の返信であった場合には、S134へ進み、サイトへのアクセス操作があったか否かの判断がなされ、ない場合にはS137のその他の処理が行なわれる。一方、サイトへのアクセス操作があった場合にはS135へ進み、サイトからクッキー(この場合にはトラッキング型クッキー)が送信されてきたか否かの判断がなされる。サイトからクッキーが送信されてきた場合には、S136へ進み、送信されてきたクッキーを拒絶する処理がなされる。その結果、RP用IC端末19Rをパソコン30のUSBポート18へ接続して使用している場合には、サイト側から送信されてきたクッキー(トラッキング型クッキー)をすべて拒絶し、そのクッキーがRP用IC端末19Rに記録されてしまうことが防止できる。
その結果、RP用IC端末19Rを使用してユーザがRPとしてネットワーク上で行動する場合には、トラッキング型クッキーを手掛かりのユーザの本名であるRPの氏名や住所等を収集されることがなく、ユーザのプライバシーが守られる。
図29はS101に示されたVP出生依頼処理のサブルーチンプログラムを示すフローチャートである。このVP出生依頼は、PVを新たに誕生させるための依頼をVP管理サーバ9へ出すための処理である。S140により、暗証番号のチェック済みであるか否かの判断がなされ、適正な暗証番号である旨のチェックが済んでいる場合にはS141へ進むが、適正な暗証番号のチェックが未だ済んでいない場合にはこのサブルーチンプログラムが終了する。適正な暗証番号である旨のチェックが済んでいる場合にはS141へ進みV出生要求の操作があったか否かの判断がなされる。ユーザがブラウザフォン30のキーボードを操作してVP出生要求の操作を行なえば、制御がS142へ進み、VP出生依頼要求を金融機関7のVP管理サーバ9へ送信する処理がなされる。次にS143へ進み、正当機関チェック処理がなされる。この正当機関チェック処理は、相手側の機関(この場合には金融機関7)が正当な機関であるか否かをチェックするものであり、金融機関7になりすまして対応する不正行為を防止するためのものであり、図30(a)にそのサブルーチンプログラムが示されている。
先に、図30(a)に基づいて正当機関チェック処理のサブルーチンプログラムを説明する。この正当機関チェック処理は、図24(b)に示された正当機関証明処理に対応するチェック側のプログラムである。まずS160により、電子証明書を受信したか否かの判断を行ない、受信するまで待機する。正当機関証明処理では、図24に示されているように、S90により電子証明書が送信される。この電子証明書が送信されてくれば、制御がS161へ進み、乱数Rを生成して送信する処理がなされる。すると、機関側では、図24に示すようにS92により、当該機関の秘密鍵SKを用いて受信した乱数Rを暗号化してLを算出して送信する処理が行なわれる。このRの暗号化データLをブラウザフォン30が受信すれば、制御がS163へ進み、受信した電子証明書内の公開鍵KPを用いてLを復号化する処理すなわちDKP(L)を算出する処理が行なわれる。
そして、図29のS144へ進み、R=DKP(L)であるか否かの判断がなされる。正当な機関である場合には、R=DKP(L)となるはずであり、その場合にはS146へ進むが、他人が金融機関7になしすましている場合には、S144によりNOの判断がなされ、S145へ進み、正当機関でない旨の警告表示がブラウザフォン30によりなされてこのサブルーチンプログラムが終了する。
正当機関であることが確認された場合には、S146へ進み、RPの氏名,住所の入力要求を受信したか否かの判断がなされ、受信するまで待機する。VP管理サーバ9では、前述したように、VP出生依頼要求を受信すれば、RPの氏名,住所の入力要求を送信するのであり(S2参照)、そのRPの氏名,住所の入力要求をブラウザフォン30が受信すれば、S146によりYESの判断がなされて制御がS147へ進む。
S147では、RPの氏名,住所の入力指示をブラウザフォン30のディスプレイに表示する処理がなされ、入力があるまで待機する(S148)。入力があった段階でS149へ進み、その入力データを金融機関7のVP管理サーバ9へ送信する処理がなされる。
次にS150へ進み、本人証明処理が行なわれる。この本人証明処理は、VP出生依頼を行なったユーザが本人自身であるか否かを証明するための処理であり、図34(a)にそのサブルーチンプログラムが示されている。ここで、図34(a)に基づいて、その本人証明書のサブルーチンプログラムを説明する。
この本人証明処理は、前述したS4,S62等に基づいて乱数Rが送信されてきた場合にその乱数に基づいて本人証明を行なうためのものである。まずS125により、乱数Rを受信したか否かの判断がなされ、受信するまで待機する。乱数Rを受信した場合にはS216へ進み、その受信した乱数RをIC端末19Rまたは19Vへ送信する処理がなされる。IC端末では、後述するように、記憶している認証鍵KNまたは公開鍵KPを用いて乱数Rを暗号化してレスポンスデータIを生成して出力する処理が行われる。そのレスポンスデータIが出力されてくれば、S217によりYESの判断がなされてS218へ進み、そのIをVP管理サーバ9へ送信する処理がなされる。
図29に示すVP出生依頼処理を行なう場合には、ブラウザフォン30のUSBポート18にVP用IC端末19Vを接続している。そして、VP出生依頼処理の際の本人証明処理では、VP用IC端末19Vに記憶されているRPの認証鍵KNを用いて乱数Rを暗号化する処理がなされる。これについては、後述する。
その結果、図29のS150のVP出生依頼処理の際の本人証明では、RPであることの証明がなされる。
次にS151へ進み、アクセス拒絶を受信したか否かの判断がなされ、アクセス拒絶を受信した場合にS152へ進み、アクセス拒絶の表示が行なわれる。一方、アクセスが許容された場合にはS153へ進み、VP出生依頼を行なったユーザが希望するコンビニエンスストア2の入力があるか否かの判断がなされる。出生したVPの住所が、コンビニエンスストア2の住所となるために、ユーザは、自己の希望するコンビニエンスストア2がある場合には、そのコンビニエンスストア2を特定する情報をブラウザフォン30のキーボードから入力する。入力があれば、S154により、その希望のコンビニエンスストア2のデータがVP管理サーバ9へ送信される。希望のコンビニエンスストア2の入力がなかった場合には、前述したように、RPの住所に最も近いコンビニエンスストア2の住所が出生したVPの住所となる。
次にS155へ進み、VPの公開鍵の送信要求があったか否かの判断がなされ、あるまで待機する。VP管理サーバ9では、前述したように、VPの出生依頼があった場合に、VPの公開鍵の送信要求を出す(S30参照)。その送信要求をブラウザフォン30が受ければ、制御がS156へ進み、VP用IC端末19Vへ公開鍵出力要求を出す。すると、VP用IC端末19Vが、記憶しているVPの公開鍵KPを出力する。その出力があれば、制御がS158へ進み、その出力された公開鍵KPを金融機関7のVP管理サーバ9へ送信する。
図30(b)は、S105に示された電子証明書発行要求処理のサブルーチンプログラムを示すフローチャートである。S165により、適正な暗証番号である旨のチェックが済んでいるか否かの判断がなされ、未だに済んでいない場合にはこのサブルーチンプログラムが終了する。一方、適正な暗証番号である旨のチェックが済んでいる場合にはS166へ進み、RP用電子証明書の発行依頼操作があったか否かの判断がなされる。ユーザがブラウザフォン30のキーボードを操作して発行依頼を行なった場合には、制御がS167へ進み、RPの住所,氏名の入力指示が表示される。ユーザがキーボードより入力すれば、制御がS169へ進み、RP用IC端末19Rから公開鍵KPを呼出す処理がなされる。この電子証明書発行要求処理を行なう場合には、ユーザは、ブラウザフォン30のUSBポート18に自己のRP用IC端末19Rを接続しておく必要がある。そして、S169の処理が行なわれた場合には、その接続されているRP用IC端末19Rが記憶しているRP用の公開鍵KPがブラウザフォン30に出力され、S170により、その出力されてきた公開鍵KPと入力されたRPの住所,氏名とが金融機関7の認証用サーバ11へ送信される。
図31(a)はS102に示されたVP用入力処理のサブルーチンプログラムを示し、図31(b)はS106に示されたRP用入力処理のサブルーチンプログラムを示すフローチャートである。
VP用入力処理が行なわれる場合には、ブラウザフォン30のUSBポート18にVP用IC端末19Vを接続しておく必要がある。S175により、適正な暗証番号である旨のチェックが終了しているか否かの判断がなされ、適正な暗証番号のチェックが未だなされていない場合にはこのサブルーチンプログラムが終了する。適正な暗証番号のチェック済の場合には、S176へ進み、VP用入力操作があったか否かの判断がなされる。前述したように、金融機関7のVP管理サーバ9によりVPの出生処理が行なわれた場合には、誕生したVPの氏名,住所(コンビニエンスストア2の住所),コンビニエンスストア2の名称,Eメールアドレス,電子証明書が記憶されたIC端末19Iが郵送されてくるのであり、そのIC端末19Iをユーザがブラウザフォン30に挿入すれば、S176によりYESの判断がなされてS178へ進み、そのIC端末19Iの記録データが読込まれて接続されているVP用IC端末19Vへ伝送される。
ユーザがブラウザフォン30のキーボードからVP用ユーザエージェントの知識データの入力操作を行なえば、S177によりYESの判断がなされてS179へ進み、入力された知識データをVP用IC端末19Vへ伝送する処理がなされる。
ユーザが金融機関7の自己の口座から資金を一部引落しすれば、その引落し額Gがブラウザフォン30へ送信されてくる(S69参照)。その引落し額Gがブラウザフォン30に入力されれば、S180によりYESの判断がなされてS181へ進み、引落し額GをVP用IC端末19Vへ転送してリロード金額として加算記憶させる処理がなされる。
RP用入力処理が行なわれる場合には、ブラウザフォン30のUSBポート18にRP用IC端末19Rを接続しておく必要がある。まずS185により、適正な暗証番号のチェックが済んでいるか否かの判断がなされ、済んでいる場合にはS186へ進み、RPの電子証明書を受信したか否かの判断がなされる。ユーザがRPの電子証明書の発行依頼を認証用サーバに対し行なえば、前述したように、RPの電子証明書が作成されてブラウザフォン30に送信されてくる(S28参照)。その電子証明書が送信されてくれば、S186によりYESの判断がなされてS187へ進み、受信した電子証明書をRP用IC端末19Rへ伝送して、RP用IC端末へ記憶させる処理がなされる。
ユーザがブラウザフォン30のキーボードを操作して、RP用ユーザエージェントの知識データの入力操作を行なえば、S188によりYESの判断がなされてS189へ進み、その入力された知識データをRP用IC端末19Rへ伝送する処理がなされ、RP用IC端末19Rがその入力された知識データを記憶する。
ユーザが決済サーバ10に対し自己の口座内の資金の一部を引落す引落し要求を行なった場合には、前述したように、引落し金額であるGが決済サーバ10からユーザのブラウザフォン30へ送信される。すると、S190によりYESの判断がなされてS191へ進み、引落し額GをRP用IC端末19Rへ伝送し、リロード金額としてGを加算更新する処理が行なわれる。
図32は、ユーザ(RPとVPが存在する)がクレジットカードの支払を行なってSETに従った決済が行なわれる場合の全体概略システムを示す図である。まず、カード会員がクレジットカードの発行手続を行なえば、クレジットカード発行会社4に設置されているサーバが、クレジット発行の申込みがあったことを判別して、当該カード会員に対しクレジットカード番号を発行する。その際に、カード会員がVP用のクレジットカードの発行を要求した場合には、クレジットカード発行会社4のサーバは、そのVPの氏名や住所等のデータを入力してもらい、そのデータに基づいて金融機関などに登録されているVPか否かを金融機関7に問合せる。そして、金融機関7のデータベース12に記憶されている正規のVPであることが確認されたことを条件として、クレジットカード発行会社4のサーバは、そのVPに対しクレジット番号を発行する処理を行なう。
つまり、クレジットカード発行会社4のサーバは、仮想人物用のクレジット番号を発行するクレジット番号発行ステップを含んでいる。また、仮想人物用のクレジット番号を発行するクレジット番号発行手段を含んでいる。さらに、このクレジット番号発行ステップまたはクレジット番号発行手段は、前述したように、クレジット番号発行対象となる仮想人物が前記所定機関に登録されている正規の仮想人物であることが確認されたことを条件として、前記クレジット番号を発行する。クレジットカード発行会社4によって発行されたクレジットカード(RP用とVP用の2種類存在する)を所持するユーザは、SETによる取引をするための会員の登録要求を認証用サーバ11に出す。認証用サーバ11は、そのユーザがクレジットカード発行会社4のクレジット会員であるか否かの認証要求をクレジットカード発行会社4に出す。クレジットカード発行会社4からクレジットカードの会員である旨の認証の回答が認証用サーバ11に返信されてくれば、認証用サーバ11は、SET用の電子証明書を作成してカード会員に送る。
電子モール等の加盟店6がSETによる取引を可能にするためには、まず、SETによる取引のための会員登録要求を認証用サーバ11に出す。認証用サーバ11では、加盟店6が契約している加盟店契約会社(アクアイアラ)5に、当該加盟店6が正当な契約会社であるか否かの認証要求を送信する。加盟店契約会社5から正当な加盟店である旨の回答が返信されてくれば、認証用サーバ11は、その加盟店6のためのSET用の電子証明書を作成して加盟店6に発行する。
この状態で、カード会員が加盟店6により電子ショッピングを行なってSETにより取引を行なう場合には、まず商品やサービス等の購入要求をカード会員が加盟店6へ送信する。加盟店6では、その購入要求を承認してよいか否かの承認要求を支払承認部33からペイメントゲートウェイ27を介してクレジットカード発行会社4へ送信する。クレジットカード発行会社4から承認の回答がペイメントゲートウェイ27を介して加盟店6に返信されてくれば、加盟店6は、購入を受理した旨をカード会員に送信する。また加盟店6は、支払要求部34から支払要求をペイメントゲートウェイ27に送信する。ペイメントゲートウェイ27は、その支払要求に応じた決済要求をクレジットカード発行会社4へ送信するとともに、支払回答を加盟店6へ返信する。
カード会員と加盟店6との間では、商品やサービスの購入取引を行なう際に、互いの電子証明書を送信して、正当な本人である旨の確認が行なわれる。
クレジットカード発行会社4が、ユーザとしてのRPにクレジットカードを発行した場合には、そのクレジットカード番号等のカード情報が当該ユーザのRP用IC端末19Rに入力されて記憶される。一方、ユーザがVPとしてクレジットカード発行会社4からクレジットカードの発行を受ける際には、VP用に発行された電子証明書をクレジットカード発行会社4に送信し、金融機関7による身分の証明を行なってもらう必要がある。その上で、クレジットカード発行会社4がクレジットカードを発行した場合には、そのクレジットカードのカード番号等のカード情報が当該ユーザのVP用IC端末19Vに入力されて記憶される。
前述したSET用の電子証明書の発行も、RP用とVP用との2種類のケースに分けて発行される。そしてそれぞれ発行されたSET用の電子証明書が、それぞれのIC端末19Rまたは19Vに入力されて記憶される。
図33は、S103に示したVP用決済処理のサブルーチンプログラムを示すフローチャートである。まずS195により、適正な暗証番号である旨のチェックが終了しているか否かの判断がなされ、終了していなければこのサブルーチンプログラムが終了し、適正な暗証番号のチェック済の場合にはS196へ進む。
このVP用決済処理は、金融機関7のユーザの銀行口座内の資金の一部を引落してVP用IC端末19Vへリロードする処理と、デビットカードを使用して決済を行なう処理と、クレジットカードを使用して決済を行なう処理と、VP用IC端末19Vへリロードされているリロード金額を使用して決済を行なう場合とを有している。
ユーザが自己の銀行口座内の資金を一部引落してVP用IC端末へリロードする操作を行なえば、S197により、その引落し要求が金融機関7の決済サーバ10へ送信される。次にS198へ進み、正当機関チェック処理(図30(a)参照)が行なわれる。
次にS199へ進み、R=DKP(L)である否かの判断がなされ、正当機関でない場合にはS119によりNOの判断がなされてS200へ進み、正当機関でない旨の警告表示がなされる。一方、正当機関である場合には、R=DKP(L)となるために、制御がS201へ進み、氏名の入力要求があったか否かの判断がなされ、あるまで待機する。前述したように、決済サーバ10は、IC端末への引落し要求があった場合には、氏名の入力要求を送信する(S60参照)。この氏名の入力要求が送信されてくれば、S201によりYESの判断がなされてS202へ進み、VP用IC端末19VからVPの氏名を呼出して決済サーバ10へ送信する処理がなされる。次にS203へ進み、本人証明処理(図34(a)参照)がなされる。
次にS204へ進み、引落し額の入力要求があったか否かの判断がなされ、なければS205へ進み、不適正な旨の返信があったか否かの判断がなされ、なければS204へ戻る。この204,205のループの巡回途中で、決済サーバ10がユーザの正当性が確認できないと判断した場合には不適正である旨の返信を行なう(S79参照)。その結果、S205によりYESの判断がなされてS207へ進み、不適正である旨がパーソナルコンピュータのディスプレイにより表示される。一方、決済サーバ10が本人認証の結果正当な本人であると判断した場合には引落し額の入力要求をブラウザフォン30へ送信する(S87参照)。すると、S204によりYESの判断がなされてS206へ進む。
S206では、引落し額の入力指示をブラウザフォン30のディスプレイに表示させる処理がなされる。ユーザがキーボードから引落し額を入力すれば、S208によりYESの判断がなされてS209へ進み、その入力された引落し額Gを決済サーバ10へ送信する処理がなされる。決済サーバ10では、引落し額Gを受信すれば、VPの口座からGを減算してGを送信する処理がなされる(S89参照)。その結果、S210によりYESの判断がなされてS211へ進み、引落し額GをVP用IC端末19Vへ送信してGをリロード金額に加算更新する処理がなされる。
S196により、NOの判断がなされた場合には、図34(b)のS220へ進み、デビットカードの使用操作があったか否かの判断がなされる。デビットカードの使用操作があった場合には、S235へ進み、デビットカード使用要求を決済サーバ10へ送信する処理がなされる。次にS221へ進み、正当機関チェック処理(図30(a)参照)がなされる。そしてS222へ進み、R=DKP(L)であるか否かの判断がなされる。正当機関でない場合には、NOの判断がなされてS223へ進み、正当機関でない旨の警告表示がなされる。一方、正当機関である場合には制御がS224へ進み、デビットカードの暗証番号とカード情報の入力要求があったか否かの判断がなされ、あるまで待機する。決済サーバ10は、デビットカードの使用要求があった場合には、暗証番号とカード情報の入力要求をブラウザフォン30へ送信する(S70参照)。その送信を受信すれば、制御がS225へ進み、暗証番号の入力指示がブラウザフォン30の表示部76に表示される。ユーザがデビットカードの暗証番号をキーボードから入力すれば、S226によりYESの判断がなされてS227へ進み、VP用ICカード19Vからカード情報を読出し暗証番号とともに決済サーバ10へ送信する処理がなされる。
次にS228へ進み、不適正である旨の返信があったか否かの判断がなされる。暗証番号とカード情報とを受信した決済サーバ10は、適正か否かの判断を行ない(S72)、適正でない場合には不適正である旨の返信を行なう(S79参照)。不適正である旨が返信されてくれば、S228によりYESの判断がなされてS229へ進み、不適正である旨の表示がなされる。一方、不適正である旨の返信が送られてこなければ、制御がS230へ進み、使用金額の入力指示がパーソナルコンピュータのディスプレイに表示される。ユーザが使用金額をキーボードから入力すれば、S231によりYESの判断がなされてS232へ進み、入力された使用金額Gを決済サーバ10へ送信する処理がなされる。
使用金額Gを受信した決済サーバ10は、前述したように、ユーザに該当する銀行口座を検索して使用金額Gを減算するとともに、その使用金額Gをブラウザフォン30に返信する処理を行なう(S74)。
その結果、S233によりYESの判断がなされてS234へ進み、決済が完了した旨の表示をブラウザフォン30の表示部76に表示させる処理がなされる。
S220によりNOの判断がなされた場合には、制御がS238へ進む。S238では、クレジットカードの使用操作があったか否かの判断がなされる。ユーザがブラウザフォン30のキーボード77を操作してクレジットカードの使用を入力すれば、制御がS237へ進み、クレジットカードによる決済要求を加盟店6へ送信する処理がなされる。この加盟店は、ユーザが商品やサービスを購入しようとしている商店である。次に制御がS239へ進み、正当機関チェック処理がなされる。この正当機関チェック処理は、図30(a)に示したものである。この正当機関チェック処理に合せて、加盟店6は、当該加盟店の電子証明書を顧客のブラウザフォン30へ送信し、次に乱数Rを受信すれば、その乱数を自己の秘密鍵KSを用いて暗号化し、その暗号結果Lを顧客のブラウザフォン30へ送信する。
制御がS240へ進み、R=DKP(L)であるか否かの判断がなされる。正当な販売店(加盟店)でない場合には、S240によりNOの判断がなされて、S241へ進み、正当な販売店でない旨の警告表示がなされる。一方、正当な販売店(加盟店)である場合には、S242へ進み、オーダ情報OIと支払指示PIとが作成される。オーダ情報OIとは、商品やサービス等の購入対象物や購入個数等を特定するための情報である。支払指示PIは、たとえばクレジット番号何々のクレジットカードを利用してクレジットの支払を行なう旨の指示等である。
次にS243へ進み、オーダ情報OIと支払指示PIのメッセージダイジェストを連結した二重ダイジェストMDを算出する処理がなされる。次にS244へ進み、二重ダイジェストMDとクレジットカードを使用するVP氏名とをVP用IC端末19Vへ伝送して署名指示を出すとともに、VP用電子証明書の出力要求を行なう。
クレジットカードを使用するVP氏名と署名指示と電子証明書の出力要求を受けたVP用IC端末19Vは、入力されたVP氏名をクッキーデータ記憶領域と照合してそのVP氏名がVPの本名B13P(図11参照)を何回暗号化したものかを割出す。そしてその回数だけ秘密鍵を秘密鍵で暗号化して、その暗号化秘密鍵(KS)を用いて入力されたMDを復号化していわゆる二重署名を生成する。この二重署名を便宜上D(KS)(MD)と表現する。VP用IC端末19Vは、そのD(KS)(MD)をブラウザフォン30へ出力する。
S244に従って入力されたVP氏名がVPの本名B13Pであった場合には、VP用IC端末19Vは、その本名に対する電子証明書を格納しているために、その格納している電子証明書をブラウザフォン30へ出力する。一方、S244に従って入力されたVP氏名がトラップ型VP氏名であった場合には、VP用IC端末19Vがそのトラップ型VP氏名用の電子証明書を格納していない。そのトラップ型VP氏名用の電子証明書は、前述したようにXMLストア50に格納されている。よって、その場合には、VP用IC端末19Vは、XMLストア50に電子証明書を取寄せる旨の指示をブラウザフォン30へ出力する。
S244の要求をVP用IC端末19Vへ出力した後、VP用IC端末19Vから何らかの返信があれば、S245によりYESの判断がなされてS605へ制御が進む。S605では、XMLストア50への電子証明書の取り寄せ指示であったか否かの判断がなされ、取り寄せ指示でなかった場合にはS246へ進むが、取り寄せ指示であった場合には制御がS606へ進む。S606では、XMLストア50へアクセスしてトラップ型VP氏名に対応する電子証明書を検索してS246へ進み、オーダ情報OIと支払指示PIと出力されてきた署名としてのD(KS)(MD)とVP用電子証明書とを加盟店6へ送信する処理がなされる。加盟店6では、それら情報を確認した上で、ユーザの購入要求を受理する購入受理の回答をユーザのブラウザフォン30へ送信する。すると、S247によりYESの判断がなされてS248へ進み、取引が完了した旨の表示が行なわれる。
S238によりNOの判断がなされた場合にS249へ進み、リロード金額の使用操作があったか否かの判断がなされる。ユーザが、VP用IC端末19Vに蓄えられているリロード金額を使用する旨のキーボード操作を行なえば、制御がS250へ進み、使用金額の入力指示がブラウザフォン30のディスプレイに表示される。ユーザが使用金額をキーボードから入力すれば、S251によりYESの判断がなされてS252へ進み、入力された使用金額Gの引落し要求をVP用IC端末19Vへ伝送する処理がなされる。
VP用IC端末19Vでは、後述するように、引落し要求を受ければ、その使用金額Gだけリロード金額を減算更新し、引落しが完了した旨の信号をブラウザフォン30へ返信する。すると、S252aによりYESの判断がなされてS252bへ進み、Gの支払処理がなされる。
なお、RP用決済処理は、以上説明したVP用決済処理とほとんど同じ内容の処理であるために、図示および説明の繰返しを省略する。
図36(a)は、S58に示したVP用Webブラウザ,メール処理のサブルーチンプログラムを示すフローチャートである。S607により、サイトへのアクセス要求があったか否かの判断がなされる。ない場合にはメールの送信要求があったか否かの判断がなされる。ない場合にはこのサブルーチンプログラムが終了する。
ユーザがブラウザフォン30のキーボード77を操作してサイトへアクセスする操作を行なった場合にはS607によりYESの判断がなされて制御がS608へ進む。S608では、ブルートゥース(Bluetooth)(登録商法)が使用できる端末が近くにあるか否かの判断がなされる。ブルートゥース(登録商法)は、10メートル程度の近距離無線通信インターフェイスのコード名であり、ブラウザフォン30に標準装備されている。このS608により、10メートル四方に広域・大容量中継網43に接続されてブルートゥース(登録商法)が使用できる端末がない場合には、制御がS612へ進み、アクセスできない旨をブラウザフォン30の表示部76に表示する処理がなされる。一方、ブルートゥース(登録商法)が使用できる端末がある場合にはS609へ進み、ブルートゥース(登録商法)を用いてその端末経由でサイトにアクセスする処理がなされる。
このように、ブラウザフォン30にVP用IC端末19Vを接続してVPとしてブラウザフォン30からサイトにアクセスする場合には、携帯電話用の基地局55,携帯電話網45,ゲートウェイ53経由でサイトにアクセスするのでなく、広域・大容量中継網に接続された端末経由でアクセスする。その理由は、ブラウザフォン30が発信している電波を手掛かりにその現在位置が割出されるおそれがあるためである。ブラウザフォン30の場合には、ブラウザフォン30同士の通話を実現するために、ブラウザフォン30が位置する一番近い基地局55を割出してその基地局55から通話電波を発信するようにしているために、ブラウザフォン30の位置情報が特定できるように構成されている。このような位置がある程度割出し可能なブラウザフォン30を利用して、RPとしてそのブラウザフォン30を利用したり、あるいはVPとしてサイトにアクセスしたりした場合には、あるRPとあるVPとが常に同じ位置に存在することが統計上突き止められてしまい、そのRPとそのVPとは同一人物ではないかと、見破られてしまうおそれがある。
そこで、VPとしてブラウザフォン30を利用してネットワーク上で行動する場合には、携帯電話網54を利用することなくブルートゥース(登録商法)を利用して広域・大容量中継網43に接続されている端末経由でネットワーク内に入り込むようにしているのである。
一方、ユーザがブラウザフォン30のキーボード77を操作してEメールの送受信要求を行なった場合には、S610によりYESの判断がなされて制御がS611へ進み、ブルートゥース(登録商法)が使用できる端末が近くにあるか否かの判断がなされる。ない場合にはS611aに進み、Eメールの送受信ができない旨を表示部76に表示させる制御を行なった後、このサブルーチンプログラムが終了する。一方、近くにブルートゥース(登録商法)が使用できる端末があった場合には制御がS613へ進み、ブルートゥース(登録商法)を用いてその端末経由でEメールの送受信を行なう処理がなされる。
図36(b)は、S584に示された偽RPアクセス処理のサブルーチンプログラムを示すフローチャートである。ユーザがVPとしてネットワーク上で行動することが多くなれば、RPとVPとの両方の詳しい個人情報を収集した業者が、両個人情報を虱潰しにマッチングチェックして、両個人情報が一致するRP氏名とVP氏名とを割出し、VPに対応するRPの名前を予測してしまうという不都合が生ずるおそれがある。その1つの解決方法として、RPの個人情報の信頼性を低下させることが考えられる。その偽RPアクセス処理は、RPの氏名を名乗ってランダムにサイトを次から次へとアクセスして渡り歩く動作を自動的に行なうものである。
S650により偽RPアクセス要求があったか否かの判断がなされ、ない場合にはこのサブルーチンプログラムが終了する。ユーザがブラウザフォン30のキーボード77を操作して偽RPアクセス要求を行なえば、制御がS651へ進み、乱数Rを発生させる処理がなされる。次にS652により、その乱数RからURL(Uniform Resource Locator)を作成する処理がなされる。次にS653により、そのURLへアクセスを試みる処理がなされる。次にS654により、そのアクセスが成功したか否かの判断がなされる。このURLは乱数によってランダムに生成されたものであるために、そのURLに必ず該当するサイトがあるとは限らない。よって、該当するサイトがなければS654によりNOの判断がなされて制御が再びS651へ戻り、S651〜S653の処理を繰返す。
このS561〜S564のループを巡回することによって、ランダムに生成されたURLに該当するサイトがあった場合には、S654によりYESの判断がなされてS655へ進み、アクセスしようとしているサイトが予め設定されたアクセス許容範囲内のものであるか否かの判断がなされる。ユーザは、たとえば、RP用IC端末19Rに格納されているユーザエージェントに対し、アクセスを行なってもよい許容範囲を入力設定しておく。たとえば風俗営業関連のサイト以外を許容する等のように、アクセス許容範囲を入力設定しておく。S655では、ブラウザフォン30に接続されているRP用IC端末19Rに格納されているユーザエージェントに対し、アクセスしようとしているサイトがその予め入力設定されたアクセス許容範囲内のものであるか否かを問合せる処理を行なう。アクセス許容範囲内でない場合には制御が再びS651へ戻り、再度乱数によるURLの生成およびそのURLへのアクセスが試みられる。
S655によりアクセス許容範囲内であると判断された場合には、制御がS662へ進み、RP用IC端末19Rからクッキーを呼出して、そのクッキーとともにサイトへアクセスする処理がなされる。
次に制御がS656へ進み、そのサイトにアクセスするとともにそのサイト内でランダムに行動し、かつ、極力RPの住所,氏名および偽の嗜好情報等をそのサイト側に提供する処理がなされる。この処理は、ブラウザフォン30に接続されているRP用IC端末19R内のユーザエージェントと協働で行なわれる。次に制御がS660へ進み、サイト側からクッキーの送信があったか否かの判断がなされる。ない場合にはS657へ制御が進むが、あった場合にはS661へ制御が進み、その送信されてきたクッキーをRP用IC端末19Rに記憶させる処理がなされた後S657へ進む。
次にS657により、そのサイトのアクセスを終了させる処理がなされ、S658により、所定時間経過したか否かの判断がなされ、未だ所定時間経過していない場合には再びS651へ戻るが、所定時間経過したと判断された場合にはこのサブルーチンプログラムが終了する。
図37(a)を参照し、VP用IC端末19Vは、S253により、暗証番号チェック処理を行なう。次にS254へ進み、クッキー処理を行なう。次にS255へ進み、本人証明処理を行なう。次にS256へ進み、データ入力処理を行なう。次にS257へ進み、ユーザエージェント動作処理を行なう。次にS258へ進み、リロード金額の使用処理を行なう。次にS259へ進み、署名処理を行なう。次にS615により、トラップ型VP処理がなされる。この処理は、図41に基づいて後述する。
図37(b)を参照して、RP用IC端末19Rは、S260により、暗証番号チェック処理を行ない、S262により、本人証明処理を行ない、S263により、データ入力処理を行ない、S264により、ユーザエージェント動作処理を行ない、S265により、リロード金額の使用処理を行なう。次にS266へ進み、署名処理を行なう。
図38(a)は、S253,S260に示された暗証番号チェック処理のサブルーチンプログラムを示すフローチャートである。S268により、暗証番号が入力されたか否かの判断がなされ、入力されていない場合にはこのままサブルーチンプログラムが終了する。一方、暗証番号が入力されれば、S269へ進み、入力された暗証番号を記憶している暗証番号と照合する処理がなされる。次にS270へ進み、照合の結果一致するか否かの判断がなされ、一致しない場合にはS271へ進み、不適正な旨をブラウザフォン30へ送信する処理がなされる。一方、一致する場合にはS272へ進み、適正な旨の返信を行なう。
図38(b)は、S254に示されたクッキー処理(VP用)のサブルーチンプログラムを示すフローチャートである。S275により、クッキーの入力があるか否かの判断がなされる。ブラウザフォン30にVP用IC端末19Vが接続された時点で、そのブラウザフォン30にクッキーの記録があった場合には、前述したように、その記録されているクッキーデータがVP用IC端末19Vへ伝送される(S118参照)。また、ブラウザフォン30によりサイトへアクセスしてそのサイトからクッキーが送信されてきた場合にも、その送信されてきたクッキーデータをVP用IC端末19Vへ伝送する(S123参照)。VP用IC端末19Vでは、S118やS123によってクッキーが伝送されてくれば、S275によりYESの判断がなされてS276へ進み、その入力されたクッキーデータをVP氏名に対応するクッキー記憶領域に記憶する処理を行なう。
一方、S275によりNOの判断がなされた場合には、S277へ進み、クッキーの呼出があるか否かの判断がなされる。ブラウザフォン30によりサイトへアクセスする場合には、VP用IC端末19Vからクッキーを呼出し、そのクッキーとともにサイトへアクセスする(S121参照)。そのクッキーの呼出処理が行なわれれば、S277によりYESの判断がなされてS278へ進み、VP氏名に対応するクッキー記憶領域に記憶しているクッキーデータと必要に応じてトラップ型VP氏名とをブラウザフォン30に出力する処理がなされる。
図38(c)は、S255に示された本人証明処理(VP用)のサブルーチンプログラムを示すフローチャートである。S280により、乱数Rの入力があったか否かの判断がなされ、ない場合にはこのサブルーチンプログラムが終了する。乱数Rの入力があった場合にS281へ進み、VP出生依頼時であるか否かの判断がなされる。VP出生依頼時の場合には、S6,S151で説明したように、RPの認証鍵KNを用いてRPが正当な本人であることを証明する必要がある。そのために、VP出生依頼時の場合にはS283進み、入力された乱数RをRPの認証鍵KNで暗号化してIを生成する処理すなわちI=EKN(R)の算出処理を行なう。そして、と284により、その算出されたIをブラウザフォン30へ出力する処理がなされる。
一方、VP出生依頼時でない場合には、S281によりNOの判断がなされてS282へ進み、VPは正当な本人であることを証明するべく、VPの秘密鍵KSを用いて入力された乱数Rを暗号化してIを算出する処理、すなわち、I=ESK(R)を算出する処理を行なう。そしてS248により、その算出されたIをブラウザフォン30へ出力する処理がなされる。
図38(d)は、S262に示された本人証明処理(RP用)のサブルーチンプログラムを示すフローチャートである。S287により、乱数Rが入力されたか否かの判断がなされ、入力されていなければこのサブルーチンプログラムが終了する。一方、入力された場合には、制御がS288へ進み、RP用IC端末19Rに記憶されている認証鍵KNを用いて入力されたRを暗号化してIを算出する処理、すなわち、I=EKN(R)の算出処理が行なわれる。次にS289へ進み、その算出されたIをブラウザフォン30へ出力する処理がなされる。
図39(a)は、S256,S263に示されたデータ入力処理のサブルーチンプログラムを示すフローチャートである。S293により、データ入力があったか否かの判断がなされる。入力されるデータとしては、前述したように、VP管理サーバ9によって誕生したVPに関するデータが記録されているCD−ROMの記録データ、ユーザエージェントの知識データ(S179,S189参照)、引落し額G(S181,S191参照)等がある。これらのデータが入力されれば、制御がS294へ進み、入力データに対応する記憶領域に入力データを記憶させる処理がなされる。
図39(b)は、S257,S264に示されたユーザエージェント動作処理のサブルーチンプログラムを示すフローチャートである。S295により、公開鍵出力要求があったか否かの判断がなされる。公開鍵の出力要求があった場合には、S298に進み、記憶している公開鍵KPを出力する処理がなされる。S295によりNOの判断がなされた場合にS296へ進み、デビットカード情報の出力要求があったか否かの判断がなされる。あった場合にはS299へ進み、記憶しているデビットカード情報を出力する処理がなされる。
S296によりNOの判断がなされた場合にはS297へ進み、クレジットカード情報の出力要求があったか否かの判断がなされる。あった場合にはS300へ進み、記憶しているクレジットカード情報を出力する処理がなされる。次にS301へ進み、その他の動作処理が行なわれる。このその他の動作処理は、図40に基づいて後述する。
図39(c)は、S258,S265に示されたリロード金額の使用処理のサブルーチンプログラムを示すフローチャートである。S302により、引落し額Gの引落し要求があったか否かの判断がなされ、ない場合にはこのサブルーチンプログラムが終了する。あった場合には、S303へ進み、記憶しているリロード金額がGを減算する処理がなされ、S304へ進み、引落し完了信号を返信する処理がなされる。
図39(d)は、S259,S266により示された署名処理のサブルーチンプログラムを示すフローチャートである。S370により、メッセージダイジェストMDの入力があったか否かの判断がなされ、ない場合にはこのサブルーチンプログラムが終了する。一方、S244等によってMDがIC端末へ伝送されてくれば、S370によりYESの判断がなされS371へ進み、その入力されたメッセージダイジェストMDを秘密鍵KSで復号化して電子署名を生成する処理がなされる。次にS372へ進み、その電子署名DKS(MD)を出力する処理がなされる。
図39(e)は、S259により示されたVP署名処理のサブルーチンプログラムを示すフローチャートである。S999により、メッセージダイジェストMDとVP氏名との入力がブラウザフォン30からあったか否かの判断がなされ、ない場合にはこのサブルーチンプログラムが終了する。
MDとVP氏名との入力があった場合には制御がS998へ進み、その入力されたVP氏名から秘密鍵(KS)を生成する処理がなされる。具体的には、VP用IC端末19Vは、入力されたVP氏名に基づいてクッキーデータ記憶領域を検索してその入力されたVP氏名が本名B13P(図11参照)を何回暗号化したものであるかを割出す。その割出された暗号化回数だけVPの秘密鍵をVPの秘密鍵で暗号化して秘密鍵(KS)を生成する。
次に制御がS997へ進み、その秘密鍵(KS)を用いてメッセージダイジェストMDを復号化して二重署名を生成する処理がなされる。次に制御がS998へ進み、その二重署名D(KS)(MD)をブラウザフォン30へ出力する処理がなされる。
図40は、S301に記載されたその他の動作処理のサブルーチンプログラムを示すフローチャートである。S305により、個人情報の送信要求を受けた否かの判断がなされる。この個人情報とは、図10に示されたユーザエージェント用知識データのことであり、たとえば年齢や職業や各種嗜好情報や家族構成等の個人情報のことである。なお、VPの住所、氏名、Eメールアドレスに関しては、S700,S701で処理する。ユーザが加盟店6やライフ支援センター8やその他各種サイトにアクセスした場合に、サイト側から個人情報を要求される場合がある。個人情報の要求を受けた場合には、制御がS306へ進み、プライバシーポリシーを受信したか否かの判断がなされる。サイト側が、個人情報を要求する場合には、その個人情報の収集目的や利用範囲等を明示したプライバシーポリシーをユーザ側に送信する。そのプライバシーポリシーを受信すれば、制御がS307へ進み、個人情報を送信して良いか否かの判断がなされる。
この判断は、予めユーザがIC端末19Rまたは19Vに、どのような場合に個人情報を送信して良いか否かを入力設定し、その入力設定データに基づいて判断がなされる。送信要求対象となる個人情報の種類やプライバシーポリシーの内容に基づいて、S307によりYESの判断がなされた場合には、S310へ進み、プライバシーポリシーと個人情報とをまとめてIC端末19Rまた19Vの秘密鍵KSにより復号化して電子署名を生成する処理がなされる。次にS310へ進み、要求されている個人情報と電子署名とをサイト側に送信する処理がなされる。
次に制御がS313へ進み、個人情報の送信要求を送信してきたサイトの種類に応じてVPの性格を変化させる処理がなされる。VP用IC端末19Vには、ユーザエージェントとしてのプログラムが記憶されているとともに、ユーザがアクセスするサイトの種類に応じてVPの性格を変化させるという、ゲームソフトの分野でよく用いられているプログラムが記憶されている。たとえば、ユーザがVPとして学術的なサイトに頻繁にアクセスした場合には、VPの性格が理知的で学者肌の性格となる。一方、ユーザが風俗関係のサイトに頻繁にアクセスした場合には、VPの性格が、ふしだらでブロークンな性格となる。
S307によりNOの判断がなされた場合には、S308へ進み、要求されている個人情報が出力できないか否かの判断がなされ、出力できないと判断された場合にはS311へ進み、送信拒絶の旨をサイトに送信する処理がなされた後S313へ進む。
IC端末19Rおよび19Vに記憶されているユーザエージェントでは、送信できるかまたは送信できないかの判断がつかない場合には、制御がS309へ進み、出力要求を受けた個人情報とプライバシーポリシーとをブラウザフォン30のディスプレイに出力して、ユーザ自身に送信の許否を求める処理がなされる。それを見たユーザは、送信して良いか否かをキーボードから入力する。送信して良い旨の入力があった場合にはS312によりYESの判断がなされてS310へ進むが、送信してはならない入力があった場合には、S312によりNOの判断がなされてS311へ進む。
S305によりNOの判断がなされた場合には、S314へ進み、ユーザであるRPから会話要求があったか否かの判断がなされる。ユーザが、VP(VPのユーザエージェント)と会話がしたい場合には、会話を要求する旨の操作をキーボードから入力する。すると、S314によりYESの判断がなされてS314aへ進み、VPの現在の正確を反映させながら会話をすることが可能となる。
図41は、S615により示されたトラップ型VP処理のサブルーチンプログラムを示すフローチャートである。S620により、新たなトラップ型VPの生成要求があったか否かの判断がなされ、ない場合にはS623へ進み、トラップ型VPが使用済みであるか否かの問合せがあったか否かの判断がなされ、ない場合にはこのサブルーチンプログラムが終了する。
ブラウザフォン30がS598に従ってVP用IC端末19Vに新たなトラップ型VPの生成要求を出した場合には、S620によりYESの判断がなされて制御がS621へ進む。S621では、VP用IC端末19Vのクッキーデータ領域の最後のVP氏名の暗号回数nを「1」加算して、VPの本名をn+1回秘密鍵で暗号化して新たなトラップ型VP氏名を生成する処理がなされる。たとえば図11の場合には、クッキーデータ領域の最後のVP氏名E3(B13P)の暗号回数が3回であり、これに「1」加算して暗号回数4にし、VPの本名B13Pを4回暗号化して新たなトラップ型VP氏名E4(B13P)を生成する処理がなされる。
次にS622へ進み、その生成されたトラップ型VPを、ブラウザフォン30へ出力するとともに、クッキーデータ領域における最後のVP氏名の次の空き領域に記憶させる処理がなされる。
S590に従ってブラウザフォン30がVP用IC端末19Vに対し今アクセスしようとしているサイトにトラップ型VPが既に使用されているか否かの問合せを行なった場合には、S623によりYESの判断がなされて制御がS624へ進む。この問合せの際にはブラウザフォン30はVP用IC端末19Vに対し、今アクセスしようとしているサイト名も併せて伝送する。S624では、クッキーデータ領域(図11参照)を検索する処理がなされる。制御がS625へ進み、伝送されてきたサイト名に対しトラップ型VP氏名が使用済みであるか否かの判断がなされる。たとえばブラウザフォン30から伝送されてきたサイト名がMECであった場合には、図11を参照して、トラップ型VP氏名E2(B13P)が使用済みであることがわかる。
トラップ型VP氏名が使用済みであると判断された場合には制御がS626へ進み、使用済みである旨をブラウザフォン30へ出力するとともに、S627により、使用されているトラップ型VPとそれに対応するクッキーデータとをブラウザフォン30へ出力する処理がなされる。たとえば、図11の場合には、伝送されてきたサイト名がMECであった場合には、トラップ型VPとしてE2(B13P)がブラウザフォン30へ出力される
とともに、クッキーデータmecがブラウザフォン30へ出力される。
図11のクッキーデータ領域を検索した結果、ブラウザフォン30から伝送されてきたサイト名に対しトラップ型VPが未だ使用されていない場合にはS625によりNOの判断がなされて制御がS628へ進み、未使用の旨をブラウザフォン30へ出力する処理がなされる。
図42,図43は、コンビニエンスストア2のサーバ16の処理動作を説明するためのフローチャートである。S315により、VPの氏名,Eメールアドレス,金融機関の名称を受信したか否かの判断がなされ、受信していない場合にS316へ進み、VPが購入した商品を預かったか否かの判断がなされ、預かっていない場合にS317へ進み、商品の引取り操作があったか否かの判断がなされ、ない場合にはS318へ進み、その他の処理を行なった後S315へ戻る。
このS315〜S318のループの巡回途中で、決済サーバ10が誕生したVPの氏名,Eメールアドレス,当該金融機関の名称をコンビニエンスストア2へ送信した場合には(S18参照)、S315によりYESの判断がなされてS319へ進み、正当機関チェック処理がなされた後、S320へ進む。
S320では、R=DKP(L)であるか否かの判断がなされ、正当機関でない場合にはNOの判断がなされてS321へ進み、正当機関でない旨の警告表示がなされる。一方、正当機関である場合にはS320によりYESの判断がなされてS322へ進み、受信データをデータベース17へ登録する処理がなされる。
ユーザがVPとしてたとえば電子ショッピング等を行なってそのVPの住所であるコンビニエンスストア2に購入商品が配達されてコンビニエンスストア2がその商品を預かった場合には、S316によりYESの判断がなされてS316aへ進み、該当するVPの商品預かり情報のアドレス領域に商品を預かった旨の情報を記憶させる処理がなされる。その際に、当該商品の決済が済んでいるか否かの情報も併せて記憶させる。次に制御がS323へ進み、当該VPのEメールアドレスを割出し、そのEメールアドレスへ商品を預かった旨のメールを送信する処理がなされる。VPは、そのEメールを見ることにより、コンビニエンスストアに購入商品が配達されたことを知ることができ、その商品を引取るためにそのコンビニエンスストアに出向く。
ユーザがVPとしてコンビニエンスストア2に出向き、配達された商品を引取るための操作を行なえば、S317によりYESの判断がなされる。そして制御がS324へ進み、VP用IC端末19Vの差込指示が表示される。それを見たユーザは、自己のVP用IC端末19Vを端末73のUSBポートへ差込んで接続する。すると、S325によりYESの判断がなされてS326へ進み、暗証番号チェック処理がなされる。ユーザは、端末73に設けられているキーボードからVP用の暗証番号を入力する。暗証番号が一致して適正であることを条件として、制御がS327へ進み、接続されているVP用IC端末19VからVP用の氏名を呼出してそれに基づいてデータベース17を検索する処理がなされる。そして、該当するVPの商品預かり情報のアドレス領域に、商品預かり情報が記録されているか否かの判断がS328によりなされる。商品預かり情報がなければS329へ進み、預かり商品がない旨が表示される。一方、商品預かり情報がある場合にはS330へ進み、電子証明書の出力要求がVP用IC端末19Vに対しなされる。VP用IC端末19Vは、それを受けて、記憶している電子証明書をサーバ16に出力する。すると、S331によりYESの判断がなされてS332へ進み、出力されてきた電子証明書内の公開鍵KPを読出し、S333により、本人チェック処理がなされる。
差込まれているVP用IC端末19Vは、前述したように、VP本名に対する電子証明書は格納しているものの、トラップ型VPに対する電子証明書は格納しておらず、そのトラップ型VPに対する電子証明書はXMLストア50に格納されている。VP本名を用いて電子ショッピング等を行なってその購入商品がコンビニエンスストア2へ届けられた場合には、S327に従って呼出されたVP氏名はVPの本名となる。その場合には、S330の要求に従ってVP用IC端末19Vは電子証明書を出力することができる。その場合にS331によりYESの判断がなされて制御がS332へ進む。一方、トラップ型VP氏名を用いて電子ショッピングを行ないその購入商品がコンビニエンスストア2へ届けられた場合には、その商品をトラップ型VPとしてコンビニエンスストア2へ引取りに行くこととなる。その場合には、S327によってVP用IC端末19Vから呼出されるVP氏名は、トラップ型VP氏名となる。その結果、そのトラップ型VP氏名に対応する電子証明書の出力要求がS330からVP用IC端末19Vに対し出される。その場合には、VP用IC端末19Vは、XMLストア50から電子証明書を取り寄せる旨の指示を出力する。
その出力があれば、制御がS631へ進み、XMLストア50へアクセスして該当する電子証明書を取り寄せる処理がなされた後制御がS332へ進む。
次にS334へ進み、R=DKP(I)であるか否かの判断がなされる。正当でないなりすましのVPである場合には、S334によりNOの判断がなされてS335へ進み、不適正である旨が表示される。一方、適正なVPであった場合には、制御がS336へ進み、預かり商品番号を表示し、S337により、その商品に関し決済済みであるか否かの判断がなされ、決済済みの場合にはS339へ進むが、決済済みでない場合にはS338へ進み、決済処理が行なわれる。
S339では、商品の引渡しが完了したか否かの判断がなされる。コンビニエンスストア2の店員は、S336により表示された預かり商品番号を見て、該当する番号の商品を探し出し、顧客にその商品を引渡した後、商品引渡し完了操作を行なう。すると、S339によりYESの判断がなされてS340へ進み、データベース17の商品預かり情報のアドレス領域を更新し、商品預かりなしの状態にした後、S315へ戻る。
S326の暗証番号チェック処理は、図43(a)に示されている。S345により、暗証番号の入力指示が表示され、ユーザが入力すればS347へ進み、その入力された暗証番号をサーバ16に接続されているVP用IC端末19Vへ伝送し、その暗証番号の適否の判定結果がVP用IC端末19Vから返送されてくれば、S349へ進む。S349では、適正な判定結果か否かが判別され、不適正であればS350により不適正の表示を行なってS315へ戻るが、適正であればこのサブルーチンが終了して、制御がS327へ進む。
S333の本人チェック処理は、図43(b)に示されている。S355により、乱数Rを生成してVP用IC端末へ伝送する処理がなされ、チャレンジデータRに対するレスポンスデータIがVP用IC端末から返送されてくるまで待機する。Iが返送されてくれば、このサブルーチンが終了する。
S338の決済処理は、図43(c)に示されている。S359により、預かり商品の価格を表示する処理がなされ、S360へ進み、入金があるか否かの判断がなされる。ない場合にはS362へ進み、リロード金額による支払操作があったか否かの判断がなされ、ない場合にはS360へ戻る。そして、ユーザが現金による支払を行なってコンビニエンスストアの店員が入金があった旨の操作を行なえば、S360によりYESの判断がなされてS361へ進み、商品販売会社の口座へ入金処理を行なってこのサブルーチンプログラムが終了する。
一方、ユーザがVP用IC端末19に記憶されているリロード金額を使用して支払操作を行なうべくその旨の操作がなされれば、S362によりYESの判断がなされてS363へ進み、価格Gの引落し要求をVP用IC端末19Vへ伝送する処理がなされる。そしてS364へ進み、VP用IC端末19Vから引落し完了信号が出力されてきたか否かの判断がなされ、出力されてくるまで待機する。そして、引落し完了信号を受信すれば、S364によりYESの判断がなされてS361へ進む。
次に、別実施の形態を説明する。この別実施の形態は、ブラウザフォン30やユーザのパーソナルコンピュータ等のユーザ側端末およびIC端末19およびWebサイトによって、個人情報保護のシステムが完結する簡易型システムである。前述した実施の形態との相違は、トラップ型VPのEメールアドレスがVP本名のEメールアドレスと同じである。よって、トラップ型VP宛のEメールを金融機関7が転送する必要がない。またトラップ型VPの氏名は、そのトラップ型VPがアクセスするサイトの名称を、VP本名に用いられる秘密鍵で暗号化したものを用いる。トラップ型VPの口座番号やクレジット番号も、VPが本名として用いる口座番号,クレジット番号と同じものを用いる。
図44(a)は、VP用IC端末19VのEEPROM26のクッキー記憶領域に格納されている情報を示す図である。このクッキー記憶領域には、VP氏名として、VPの本名B13Pのみが記憶され、トラップ型VP氏名は何ら記憶されない。トラップ型VPの氏名は、トラップ型VPとしてアクセスしたサイトを本名のVPの秘密鍵KSBで暗号化したものを用いる。この暗号化回数は1回に限らず2回以上の或る定められた回数であってもよい。よって、トラップ型VPがアクセスしたサイト名のみを記憶させることにより、そのサイト名に対応するトラップ型VPの氏名は、わざわざ記憶させなくとも、EKSB(サイト名)の演算式に従って必要に応じてその都度算出することができる。トラップ型VPの秘密鍵は、トラップ型VPに対応するサイト名を本名のVPの秘密鍵KSBで復号化したものを用いる。よって、トラップ型VPに対応させて逐一公開鍵や秘密鍵をVP用IC端末19Vに記憶させる必要はなく、秘密鍵=DKSB(サイト名)の演算式に従って必要に応じてその都度算出することができる。よって、XMLストア50の「暗号回数」の記憶が不要となる。
図44(b)は、トラップ型VP処理のサブルーチンプログラムを示すフローチャートである。このサブルーチンプログラムは、図41に示したトラップ型VP処理の別実施の形態である。S960により、新たなトラップ型VPの生成要求がブラウザフォン30からあったか否かの判断がなされ、あった場合には制御がS959へ進み、アクセスするサイトの名称の入力要求がブラウザフォン30へ出される。ブラウザフォン30からアクセスするサイトの名称が伝送されてくれば、制御がS957へ進み、その伝送されてきたサイト名をVPの本名B13Pの秘密鍵KSBで暗号化して、新たなトラップ型VP氏名であるEKSB(サイト名)を算出する処理がなされる。次に制御がS956へ進み、その算出した新たなトラップ型VP氏名をブラウザフォン30へ出力する処理がなされ、S954により、入力されたサイト名をクッキー記憶領域に記憶させる処理がなされる。
S953〜S948は、図41に示したS623〜S628と同じ制御のために、説明の繰返しを省略する。
図44(c)は、VP用IC端末19Vによって行なわれる個人情報流通チェックのサブルーチンプログラムを示すフローチャートである。S970により、Eメールの受信があったか否かの判断がなされ、ない場合にはこのサブルーチンプログラムが終了する。トラップ型VP宛のEメールの受信があれば、ブラウザフォン30は、そのEメールデータをVP用IC端末へ入力する。すると制御がS969へ進み、その入力されたEメールの宛名をVPの本名に用いられる公開鍵KPBで復号化するDKPB(宛名)の演算を行ない、その演算結果がEメールの送信者名と一致するか否かの判断がなされる。
Eメールの宛名はトラップ型VP氏名となっており、そのトラップ型VP氏名は、そのトラップ型VPがアクセスしたサイト名をVPの秘密鍵KSBで暗号化したものを用いている。よって、トラップ型VPがその氏名を用いてアクセスしたサイトからそのトラップ型VP宛にEメールが送信された場合には、S969によりYESの判断がなされる筈である。その場合には、S968により、適正である旨がブラウザフォン30へ出力され、ブラウザフォン30の表示部76によりその旨が表示される。一方、トラップ型VPがその氏名を用いてアクセスしたサイト以外のサイトからそのトラップ型VP氏名をEメールの宛名としてEメールが送信されてくれば、S969によりNOの判断がなされ、制御がS967へ進む。S967では、Eメールの宛名を本名のVPの公開鍵KPBで復号化する処理がなされる。その結果、Eメールの宛名であるトラップ型VP氏名が公開鍵KPBで復号化されて平文のサイト名が算出されることとなる。このサイト名は、Eメールの宛名に用いられているVP氏名としてアクセスしたサイト名のことであり、アクセスしたサイトが個人情報をEメールの送信者に不正流通したことが考えられる。よって、S967により、DKPB(宛名)が不正流通し、送信者名の業者が不正入手した旨をブラウザフォン30へ出力する。ブラウザフォン30では、その旨を表示部76により表示させる。
なお、S969によりNOの判断がなされた場合に、前述した図17のS494とS494aとの処理を行なった後、S494aによりNOの判断がなされた場合にのみS967へ進むようにしてもよい。
次に、以上説明した実施の形態における変形例や特徴点等を以下に列挙する。
(1) 前述したように、ブラウザフォン(携帯電話)30やPHS(Personal Handy-phone System)等の最寄の基地局に対し電波で送受信する携帯型送受信機の場合には、最寄の基地局を特定するために携帯型送受信機の現在地がある程度割出されるようになっている。このような携帯型送受信機を用いてVPとしてサイトにアクセスする等のネットワーク上での行動を行なう場合には、そのVPとして携帯型送受信機を利用している最中に位置がある程度特定されてしまうおそれがある。その結果、あるVPはあるRPと常に同じ場所に位置するという統計上の結果が割出されてしまい、VPとRPとの関連が見破られてしまうおそれがある。
そこで、次のような手段を採用する。
ユーザに携帯され最寄の基地局との間で電波による送受信を行なって該基地局を通してネットワーク内に進入可能な携帯型送受信機であって、
現実世界での実在人物(リアルパーソン)がネットワーク上で行動する際に、仮想人物(バーチャルパーソン)になりすまして該仮想人物として行動できるようにするための仮想人物用処理機能(S100〜S103,S580,S582〜S585)が備えられており、
該仮想人物用処理機能を用いてユーザが仮想人物としてネットワーク内に進入する場合に、ネットワークに接続された端末に対し直接無線通信(ブルートゥース)(登録商法)を行ない、前記基地局からの進入ルートではなく前記端末からネットワーク内に進入する処理を行なうための仮想人物用別ルート進入手段(S607〜S613)を備えている、携帯型送受信機(ブラウザフォン30等)。
このような手段を採用した結果、ユーザは、仮想人物としてネットワーク内に進入する際には、仮想人物用別ルート進入手段を利用して、基地局からの進入ルートではなく別ルートによる進入が可能となり、その結果、仮想人物の位置が特定されてしまう不都合を極力防止することができる。
このような効果を奏する手段として、次のようなものを採用してもよい。
ユーザに携帯され、最寄の基地局に対し電波により送受信を行なってネットワーク内に進入可能な携帯型送受信機(ブラウザフォン30等)に備えられているプロセッサ(CPU197)を動作させるプログラムであって、
前記プロセッサに、
現実世界での実在人物(リアルパーソン)がネットワーク上で行動する際に、仮想人物(バーチャルパーソン)になりすまして該仮想人物として行動できるようにするための処理を行なう仮想人物処理手段(S100〜S103,S580,S582〜S585)と、
該仮想人物処理手段によりユーザが仮想人物としてネットワーク内に進入する際に、該ネットワークに接続されている端末に対し直接無線通信を行なって、前記基地局からの進入ルートではなく前記端末からネットワーク内に進入する仮想人物用別ルート進入手段(S607〜S613)と、
として機能させるプログラム。
(2) ユーザの個人情報を利用する業者側は、提供してもらいたい個人情報が本当に正しい内容であるか否かを確認したいというニーズがある。
そこで、以下のような手段を採用する。
所定機関にユーザから個人情報の登録要請があった場合に、その個人情報の真偽チェックを行なうための処理を行なう真偽チェック処理手段(S420)と、
該真偽チェック処理手段による処理の結果、正しいと判断される個人情報に対し前記所定機関のデジタル署名を施すデジタル署名手段(S425)と、
該デジタル署名が施された前記個人情報を当該個人情報のユーザが特定可能な態様で格納する個人情報格納手段(S425,データベース12a)と、
あるユーザ名を指定しての依頼者からの要請に応じて、該ユーザ名に対応する個人情報を前記個人情報格納手段から検索する検索手段とを含む、個人情報システム。
この個人情報システムは、以下の手段をさらに含んでもよい。
前記依頼者が所有する個人情報の真偽のチェックを依頼してきた場合に、該チェック対象となる前記依頼者の所有する個人情報に対応する個人情報を前記個人情報格納手段から検索し、該検索された個人情報と前記依頼者の個人情報とを照合して真偽チェックを行なう真偽チェック手段(S471,S472)、
該真偽チェック手段による真偽の結果を前記依頼者に通知する結果通知手段(S487)、
前記真偽チェック手段のチェックの結果と前記依頼者の個人情報が正しい内容であった場合に該個人情報に対し前記所定機関のデジタル署名を施すデジタル署名手段(S486)、
前記真偽チェック手段による真偽チェックの結果を前記依頼者に通知してよいか否かを真偽チェック対象となっている個人情報に対応するユーザに尋ねるための処理を行なう手段(S476,S477)、
前記個人情報格納手段に格納されている個人情報の購入要求が依頼者からあった場合に、該購入の対価をめぐる交渉を行なうための処理を行なう交渉処理手段(S504〜S506)、
該交渉処理手段による交渉の結果交渉が成立した場合に、購入対象の個人情報を当該個人情報に対する前記所定機関のデジタル署名とともに購入依頼者に送信する送信手段(S509)、
前記交渉処理手段の結果交渉が成立した場合にその成立した条件に対し、購入対象の個人情報に対応するユーザ、前記購入依頼者、前記所定機関のそれぞれのデジタル署名を付して記憶しておく記憶手段(S508)。
(3) ユーザがVPとしてネットワーク上で行動することが多くなれば、RPとVPとの両方の詳しい個人情報を収集した業者が、両個人情報を虱潰しにマッチングチェックして、両個人情報が一致するRP氏名とVP氏名とを割出し、VPに対応するRPの名前を予測してしまうという不都合が生ずるおそれがある。そこで、次のような解決手段を採用する。
現実世界での実在人物(リアルパーソン)がネットワーク上で行動する際に、仮想人物(バーチャルパーソン)になりすまして該仮想人物として行動できるようにした個人情報保護方法に用いられる個人情報保護装置であって、
前記実在人物の要求に応じて、該実在人物が意図しないサイトにアクセスするアクセス手段(S651〜S662)を含む、個人情報保護装置。
このような手段を採用した結果、実在人物が意図しないサイトへのアクセスが自動的に行なわれることとなり、当該実在人物の個人情報の信頼性を低下させることができる。その結果、実在人物と仮想人物との両個人情報のマッチングチェックの結果の信頼性を低下させることができる。
この個人情報保護装置は、さらに以下の手段を含んでもよい。
前記アクセス手段によりアクセスしたサイト内で、前記実在人物が意図しない行動を行なう行動手段(S656)、
前記アクセス手段によりアクセスしたサイトに対し、前記実在人物の実名(太郎)を提供する処理を行なう個人情報提供処理手段(S656)、
前記アクセス手段によりアクセスしたサイトからユーザを識別するために送信されてきた識別データ(クッキー)を受付けて記憶させるための処理を行なうクッキー受付処理手段(S660,S661)、
前記アクセス手段に備えられ、アクセスするサイトがユーザによって予め設定されたアクセス許容範囲内のものか否かを判別してアクセス許容範囲内でない場合にはアクセスしないアクセス禁止手段(S655)、
なお、この個人情報保護装置は、前述した実施の形態では、ユーザ側端末(ブラウザフォン30等)により構成されているが、本発明はこれに限らず、たとえばユーザ側の依頼に応じて偽RPアクセス処理サービスを行なう所定のサービス機関を設置し、そのサービス機関に対しユーザ側からの要求があった場合に、前述したアクセス手段、行動手段、等の動作を行なうようにしてもよい。さらに、実在人物の嗜好情報とは異なる嗜好情報をサイト側に提供してもよい。
(4) 本発明でいう「人物」,「個人」の用語は、自然人に限らず法人をも含む広い概念である。本発明でいう「匿名」とは、仮想人物(VP)の氏名のことであり、仮想人物の氏名と実在人物の匿名とは同じ概念である。したがって、仮想人物の住所やEメールアドレスや電子証明書は、実在人物が匿名でネットワーク上で行動する場合の住所,Eメールアドレス,電子証明書ということになる。
本発明でいう「個人情報保護装置」は、装置単体ばかりでなく、複数の装置がある目的を達成するために協働するように構築されたシステムをも含む広い概念である。
(5) 図1に示すように、本実施の形態では、金融機関7に、VP管理機能と、決済機能と、認証機能とを設けたが、金融機関7から、VP管理機能を分離独立させ、金融機関以外の他の守秘義務を有する所定機関にVP管理機能を肩代わりさせてもよい。その肩代わりする所定機関としては、官公庁等の公共的機関であってもよい。さらに、RPやVPに電子証明書を発行する電子証明書発行機能を、金融機関7から分離独立させ、専門の認証局に肩代わりさせてもよい。
また、本実施の形態では、コンビニエンスストア2の住所をVPの住所としているが、その代わりに、たとえば郵便局や物流業者における荷物の集配場等をVPの住所としてもよい。またVPの住所となる専用の施設を新たに設置してもよい。
VPを誕生させる処理は、本実施の形態では、所定機関の一例としての金融機関7が行なっているが、本発明はこれに限らず、たとえば、ユーザ自身が自己の端末(ブラウザフォン30等)によりVPを誕生(出生)させ、その誕生させたVPの氏名,住所,公開鍵,口座番号,Eメールアドレス等のVP用情報を、金融機関7等の所定機関に登録するようにしてもよい。
また、誕生したVPは、必ずしも所定機関に登録させなくてもよい。
(6) 処理装置の一例としてのIC端末19Rまたは19Vは、ICカードや携帯電話あるいはPHSやPDA(Personal digital Assistant)等の携帯型端末で構成してもよい。これら携帯型端末で構成する場合には、VP用の携帯型端末とRP用の携帯型端末との2種類のものを用意してもよいが、VP用モードあるいはRP用モードに切換え可能に構成し、1種類の携帯型端末で事足りるように構成してもよい。
図9に示したIC端末19Iによるアプリケーションソフトのインストールに代えて、当該アプリケーションソフトのサプライヤからネットワーク経由で当該アプリケーションソフトをブラウザフォン30等へダウンロードするように構成してもよい。
(7) 本実施の形態では、図12に示したように、VPの誕生時にそのVPの電子証明書が自動的に作成されて発行されるように構成したが、その代わりに、ユーザからの電子証明書の発行依頼があって初めてVPの電子証明書の作成発行を行なうようにしてもよい。
図23等に示すように、本実施の形態では、RPの本人認証を行なう場合には、RPの認証鍵KNを用いるようにしたが、RPが電子証明書の発行を受けている場合には、その電子証明書内の公開鍵を用いてRPの本人認証を行なうようにしてもよい。
(8) ブラウザフォン30に代えて、パーソナルコンピュータを用いてもよい。
トラップ型VP用に金融機関7が開設したEメールアドレス△△△△△は、1種類のみのEメールアドレスではなく、複数種類用意し、トラップ型VP氏名毎に使い分けるようにしてもよい。S620〜S622またはS960〜S956により、新たな匿名(トラップ型VP氏名)の生成要求があった場合に、今までに使われていない匿名を生成する新匿名生成手段が構成されている。S431〜S441またはS954により、前記新匿名生成手段により生成された匿名の登録を行なう匿名登録機関(金融機関7またはEEPROM26)に対し新たに生成された匿名の登録依頼があった場合に、該匿名を登録する匿名登録手段が構成されている。
前述したS450〜S460により、ユーザの個人情報を登録している登録機関に対しユーザから自己の個人情報の確認要求があった場合に、当該ユーザの本人認証を行なう本人認証手段(S452〜S458)による本人認証の結果本人であることが確認されたことを条件として、当該ユーザに対応する個人情報を当該ユーザに送信する個人情報送信手段が構成されている。
図44(a)で示したトラップ型VP氏名は、サイト名をVPの秘密鍵KSBで複合化したものであってもよい。
つまり、S957により、DKSB(サイト名)の演算を行なってトラップ型VP氏名を生成してもよい。その場合には、S969により、EKPB(Eメールの宛名)=送信者名 の演算式による判別を行なうこととなる。S967では、EKPB(Eメールの宛名)が不正流出し、送信者名の業者が不正入手した旨を出力するという処理になる。
前述したS957により、ユーザがネットワークを通してアクセスするサイトに対し、当該サイトの名称を当該ユーザが使用できる鍵(秘密鍵KSB)により暗号化または復号化して生成した匿名を生成する匿名生成手段が構成されている。
ユーザがネットワークを通してアクセスし自己の個人情報を提供したサイトを特定するために用いる識別情報を特定可能な情報であって、前記個人情報を入手した者がその個人情報主であるユーザにメールを送る場合には該メールに含まれることとなる識別情報として、前述した実施の形態では匿名(トラップ型VP氏名)を用いたが、その代わりにまたはそれに加えて、サイト毎に使い分ける複数のEメールアドレスやダイレクトメール用の住所(私書箱等)を用いてもよい。
(9) ネットワーク(広域・大容量中継網43)上での個人情報を保護する個人情報保護システムであって、
現実世界での実在人物(リアルパーソン)がネットワーク上で行動する際に、仮想人物(バーチャルパーソン)になりすまして該仮想人物として行動できるようにするための所定の仮想人物を誕生させる処理を行なう仮想人物誕生処理手段(S1〜S12)と、
前記実在人物と前記仮想人物との対応関係を特定可能な情報を守秘義務のある所定機関において登録する処理を行なう登録処理手段(S15)を含むことを特徴とする、個人情報保護システム。
(10) 前記所定機関は、金融機関7である。
(11) ネットワーク(広域・大容量中継網43)上での個人情報を保護する個人情報保護システムであって、
現実世界での実在人物(リアルパーソン)がネットワーク上で行動する際に、仮想人物(バーチャルパーソン)になりすまして該仮想人物として行動できるようにするための所定の仮想人物を誕生させる処理を行なう仮想人物誕生処理手段(S1〜S12)と、
前記仮想人物用の電子証明書を発行するための処理を行なう電子証明書発行処理手段(S16)とを含む。
(12) ネットワーク(広域・大容量中継網43)上での個人情報を保護する個人情報保護システムであって、
現実世界での実在人物(リアルパーソン)がネットワーク上で行動する際に、仮想人物(バーチャルパーソン)になりすまして該仮想人物として行動できるようにするための所定の仮想人物を誕生させるための処理を行なう仮想人物誕生処理手段(S1〜S12)と、
前記仮想人物の住所を、前記実在人物とは異なる住所に設定するための処理を行なう住所設定手段(S9〜S12)とを含む。
(13) 前記仮想人物の住所は、所定のコンビニエンスストアの住所である(S9〜S11)。
(14) ネットワーク(広域・大容量中継網43)上での個人情報を保護する個人情報保護システムであって、
現実世界での実在人物(リアルパーソン)がネットワーク上で行動する際に、仮想人物(バーチャルパーソン)になりすまして該仮想人物として行動できるようにするための所定の仮想人物を誕生させるための処理を行なう仮想人物誕生処理手段(S1〜S12)と、
前記仮想人物用のクレジット番号を発行するための処理を行なうクレジット番号発行処理手段(カード発行会社4)とを含み、
該クレジット番号発行処理手段により発行されたクレジット番号を利用して前記仮想人物としてクレジットによる支払ができるようにした(S58,S56,S75〜S78)。
(15) ネットワーク(広域・大容量中継網43)上での個人情報を保護する個人情報保護システムであって、
現実世界での実在人物(リアルパーソン)がネットワーク上で行動する際に、仮想人物(バーチャルパーソン)になりすまして該仮想人物として行動できるようにするための所定の仮想人物を誕生させる処理を行なう仮想人物誕生処理手段(S1〜S12)と、
前記仮想人物用の銀行口座を開設するための処理を行なう口座開設処理手段(S39,S42〜S45)とを含み、
該口座開設処理手段によって開設された口座内の資金を利用して前記仮想人物として決済ができるようにした(S55〜S57,S60〜S74)。
(16) ネットワーク(広域・大容量中継網43)上での個人情報を保護する個人情報保護システムであって、
現実世界での実在人物(リアルパーソン)がネットワーク上で行動する際に、仮想人物(バーチャルパーソン)になりすまして該仮想人物として行動できるようにするための所定の仮想人物を誕生させるための処理を行なう仮想人物誕生処理手段(S1〜S12)を含み、
前記実在人物としてネットワーク上で行動する場合と前記仮想人物としてネットワーク上で行動する場合とで、サイト側がユーザを識別するために送信してくる識別データ(クッキー)の受付制限を異ならせることができるようにした(S110〜S123,S125〜S137)。
(17) ネットワーク(広域・大容量中継網43)上での個人情報の保護に用いられる処理装置(VP管理サーバ9)であって、
現実世界での実在人物(リアルパーソン)がネットワーク上で行動する際に、仮想人物(バーチャルパーソン)になりすまして該仮想人物として行動できるようにするための所定の仮想人物を誕生させる要求を受付ける要求受付手段(S1)と、
該要求受付手段により要求が受付けられたことを条件として(S1によりYESの判断がなされたことを条件として)、仮想人物を誕生させるための処理を行なう仮想人物誕生処理手段(S1a〜S12)と、
該仮想人物誕生処理手段により誕生した仮想人物と該仮想人物に対応する前記実在人物との対応関係を特定可能な情報をデータベースとして記憶させるための処理を行なう対応関係記憶処理手段(S15)とを含む。
(18) ネットワーク(広域・大容量中継網43)上での個人情報を保護するための処理装置(VP管理サーバ9)であって、
現実世界での実在人物(リアルパーソン)がネットワーク上で行動する際に、仮想人物(バーチャルパーソン)になりすまして該仮想人物として行動できるようにするために誕生した所定の仮想人物の公開鍵(KB)の入力を受付けて(S14)、該入力された公開鍵をデータベースに記憶させるための処理を行なう公開鍵記憶処理手段(S15)と、
前記記憶された公開鍵に対応する前記仮想人物用の電子証明書を作成して発行する処理を行なうための電子証明書作成発行処理手段(S16)とを含み、
該電子証明書作成発行処理手段は、前記実在人物と前記仮想人物との対応関係を特定可能な情報が守秘義務のある所定機関(金融機関7)に登録されている登録済みの前記仮想人物であることを条件として(S7によりYESの判断がなされたことを条件として)、電子証明書の作成発行処理を行なう(S16の処理を行なう)。
(19) ネットワーク(広域・大容量中継網43)上での個人情報を保護するための処理装置(加盟店6のサーバ)であって、
現実世界での実在人物(リアルパーソン)がネットワーク上で行動する際に、仮想人物(バーチャルパーソン)になりすまして該仮想人物として行動できるようにするために誕生した所定の仮想人物に発行されたクレジット番号を利用してクレジット支払による購入要求があった場合に、支払の承認処理を行なうための支払承認処理手段(支払承認部33)と、
該支払承認処理手段により承認されたクレジットによる支払の要求をクレジットカード発行会社4に出すための処理を行なう支払要求処理手段(支払要求部33)とを含み、
前記支払承認処理手段は、前記仮想人物用に発行された電子証明書を確認した上で、支払の承認を行なう。
(20) ネットワーク(広域・大容量中継網43)上での個人情報を保護するための処理装置(決済サーバ10)であって、
現実世界での実在人物(リアルパーソン)がネットワーク上で行動する際に、仮想人物(バーチャルパーソン)になりすまして該仮想人物として行動できるようにするために誕生した所定の仮想人物用に開設された銀行口座内の資金を決済に用いるために引落す引落し要求を受付けるための処理を行なう引落し要求受付処理手段(S55)と、
該引落し要求受付処理手段により引落し要求が受付けられた場合に、該当する前記仮想人物に相当する銀行口座を割出して該銀行口座内の資金から引落し要求金額(G)に相当する資金を引落すための処理を行なう引落し処理手段(S69)とを含んでいる。
(21) ネットワーク(広域・大容量中継網43)上での個人情報を保護するための処理装置(サーバ16)であって、
現実世界での実在人物(リアルパーソン)がネットワーク上で行動する際に、仮想人物(バーチャルパーソン)になりすまして該仮想人物として行動できるようにするために誕生した所定の仮想人物の住所であって、前記実在人物とは異なる住所(コンビニエンスストア2の住所)に前記処理装置が設置されており、
該処理装置が設置されている住所を自己の住所としている前記仮想人物を特定可能な情報をデータベース17に記憶させるための処理を行なう記憶処理手段(S322)と、
該記憶処理手段に記憶されている仮想人物が購入した商品であって前記処理装置が設置されている住所に配達されてきた商品を預かったことを特定可能な情報をデータベースに記憶させるための処理を行なう預り情報記憶処理手段(S316a)と、
前記預った商品の引落し要求があった場合に(S317によりYESの判断がなされた場合に)、当該引渡し要求を出した仮想人物が前記データベースに記憶されている仮想人物であることを確認し(S327)、かつ、商品を扱っている仮想人物であることを確認したことを条件として(S328によりYESの判断がなされたことを条件として)、該当する商品の受渡しの許可を出すための処理を行なう受渡し許可処理手段(S336)とを含む。
(22) ネットワーク(広域・大容量中継網43)上での個人情報を保護するためのプログラムまたは該プログラムを記録している記録媒体(CD−ROM31)であって、
コンピュータ(パーソナルコンピュータ30)に、
現実世界での実在人物(リアルパーソン)がネットワーク上で行動する際に、仮想人物(バーチャルパーソン)になりすまして該仮想人物として行動できるようにするための所定の仮想人物を誕生させるための要求操作があったか否かを判定する誕生要求判定手段(S141)と、
該誕生要求判定手段により誕生要求があった旨の判定がなされた場合に、前記仮想人物の出生依頼要求を所定機関(金融機関7)に送信するための処理を行なう出生要求送信手段(S142)と、
前記仮想人物の出生要求を行なう前記実在人物を特定可能な情報であって前記仮想人物の出生に必要となる情報を前記所定機関へ送信するための処理を行なう所定情報送信手段(S147〜S149)と、
して機能させるためのプログラム、または該プログラムが記憶されているコンピュータ読取可能な記録媒体。
(23) ネットワーク(広域・大容量中継網43)上での個人情報を保護するための処理装置(VP用IC端末19V)であって、
該処理装置は、ユーザの端末(パーソナルコンピュータ30)に対して情報のやり取りが可能に構成されているとともに(USBポート18を介して情報のやり取りが可能に構成されているとともに)、ユーザに携帯される携帯型の処理装置であり、現実世界での実在人物(リアルパーソン)である前記ユーザがネットワーク上で所定の仮想人物になりすまして該仮想人物として行動する際に使用され、
サイト側がユーザを識別するために送信してくる識別データ(クッキー)が前記端末に対し送信されてきた場合に該識別データを当該端末の代わりに記憶可能に構成されている(S276)。
(24) さらに、前記端末(パーソナルコンピュータ30)によってユーザがサイトにアクセスした際に、必要に応じて記憶している前記識別データ(クッキーデータ)を出力して該識別データを前記サイトに送信できるように構成されている(S278)。
(25) 前記処理装置(VP用IC端末19V)は、
前記ユーザの端末に対し情報の入出力を可能にするための入出力部(I/Oポート21)と、
前記ユーザの端末から前記識別情報が入力されてきた場合に(S275によりYESの判断がなされた場合に)、該入力された識別情報を記憶する識別情報記憶手段(S276)とをさらに含む。
(26) 前記処理装置(VP用IC端末19V)は、
前記ユーザの端末から前記識別情報の出力指令が入力されてきた場合に(S277によりYESの判断がなされた場合に)、記憶している前記識別情報を外部出力する識別情報外部出力手段(S278)をさらに含む。
(27) 前記処理装置(VP用IC端末19V)は、
前記仮想人物に関する情報(VPの氏名,住所、VPのEメールアドレス、VPの公開鍵と秘密鍵、VPの年齢,職業等)を記憶しており、
前記VPに関する情報の出力指令が入力されてきた場合に(S295,S305等によりYESの判断がなされた場合に)、前記記憶している仮想人物に関する情報を外部出力する情報外部出力手段(S298,S310等)をさらに含む。
前述した正当機関証明処理,正当機関チェック処理,本人証明処理,S4〜S7等の本人チェック処理により、本人であることの確認を行なってなりすましを防止するための本人認証手段が構成されている。
S13〜S16により、バーチャルパーソン(仮想人物)用の電子証明書を作成して発行する仮想人物用電子証明書発行手段が構成されている。S25〜S28により、現実世界に実在するリアルパーソン(実在人物)用の電子証明書を作成して発行する実在人物用電子証明書発行手段が構成されている。
S39〜S45により、仮想人物(バーチャルパーソン)用の銀行口座を作成するための処理を行なう銀行口座作成処理手段が構成されている。
S40〜S49により、実在人物(リアルパーソン)または仮想人物(バーチャルパーソン)用のデビットカードを発行するための処理を行なうデビットカード発行処理手段が構成されている。S55〜S69により、仮想人物(バーチャルパーソン)に携帯される処理装置(VP用IC端末19V)に対し、該仮想人物(バーチャルパーソン)の銀行口座内の資金の一部を引落してリロードするための処理を行なう資金引落し処理手段が構成されている。
S57〜S74により、仮想人物(バーチャルパーソン)のデビットカードを使用して決済を行なうための処理を行なうデビットカード用決済処理手段が構成されている。S57〜S78により、仮想人物(バーチャルパーソン)のクレジットカードを使用しての決済を行なうための処理を行なうクレジットカード用決済処理手段が構成されている。このクレジットカード用決済処理手段は、Secure Electronic Transaction(SET)に準拠して決済を行なう。
(28) 本実施の形態では、図28に示したように、クッキーの受付を制限または拒絶するようにしたが、それに代えてまたはそれに加えて、ユーザがサイト側に再アクセスした際に、既に記憶しているクッキーを当該サイト側へ送信することを禁止または制限するように制御してもよい。すなわち、本発明における個人情報保護システムにおいては、実在人物としてネットワーク上で行動する場合と仮想人物としてネットワーク上で行動する場合とで、サイト側がユーザを識別するために送信してきた識別データであって既に記憶されている識別データを前記サイト側へ送信する際の送信制限を異ならせることができるようにしてもよい。
S140〜S158により、ユーザが自己の仮想人物(バーチャルパーソン)の出生依頼を行なう処理を行なうための出生依頼処理手段が構成されている。S9〜S12により、出生させる仮想人物(バーチャルパーソン)の住所であって出生依頼者である実在人物(リアルパーソン)の住所とは異なった住所を決定するための処理を行なう住所決定処理手段が構成されている。この住所決定処理手段は、コンビニエンスストアの住所を仮想人物(バーチャルパーソン)の住所として決定する。また、この住所決定処理手段は、出生依頼者である実在人物(リアルパーソン)の希望するコンビニエンスストアの住所を仮想人物(バーチャルパーソン)の住所として決定可能である。また、この住所決定処理手段は、出生依頼者である実在人物(リアルパーソン)の住所に近いコンビニエンスストアの住所を仮想人物(バーチャルパーソン)の住所として決定することが可能である。
S305〜S312により、ユーザに携帯される前記処理装置(RP用IC端末19R,VP用IC端末19V)に設けられ、当該処理装置の所有者であるユーザの実在人物(リアルパーソン)としての個人情報または仮想人物(バーチャルパーソン)としての個人情報の送信要求を受けた場合に、記憶している個人情報の中から該当する個人情報を選び出して出力する処理が可能な個人情報自動出力手段が構成されている。この個人情報自動出力手段は、送信要求の対象となっている個人情報が送信してよいものであるか否かを自動的に判別するための処理を行なう自動判別処理手段(S307,308,310,311)を含んでいる。この自動判別処理手段は、どの種類の個人情報を出力してよいかをユーザが事前に入力設定でき、その入力設定に従って自動判別を行なう。またこの自動判別処理手段は、自動判別できない場合には、要求対象となっている個人情報と送信されてきたプライバシーポリシーとを出力してユーザに対し送信の許否を求めるための処理を行なう(S309)。
S313により、ユーザに携帯される仮想人物(バーチャルパーソン)用の処理装置に設けられ、当該処理装置の使用状況に応じて当該処理装置によって形成される仮想人物の性格を変化させる仮想人物性格変化形成手段が構成されている。この仮想人物性格変化形成手段は、ユーザが仮想人物(バーチャルパーソン)としてアクセスしたサイトの種類に応じて性格を変化させる。
S314,S314aにより、ユーザが仮想人物(バーチャルパーソン)と会話を要求した場合に、前記性格変化形成手段により形成された現在の性格を反映して仮想人物(バーチャルパーソン)との会話を実現させる処理を行なう性格反映型会話実現処理手段が構成されている。
コンビニエンスストア2により、仮想人物(バーチャルパーソン)がネットワーク上で購入した商品が配達されてきた場合に当該商品を預る商品預り場が構成されている。データベース17により、前記商品預り場で商品を預る対象となる仮想人物(バーチャルパーソン)を登録しておくバーチャルパーソン登録手段が構成されている。このバーチャルパーソン登録手段は、仮想人物(バーチャルパーソン)ごとに分類して、商品を預っているか否かを特定するための預り特定情報が記憶される。さらに、当該商品の決済が済んでいるか否かを特定するための決済特定情報が記憶される。また、前記仮想人物(バーチャルパーソン)ごとに分類して当該仮想人物(バーチャルパーソン)のEメールアドレスを記憶している。
S323により、前記商品預り場に設けられ、商品を預っている仮想人物(バーチャルパーソン)のEメールアドレスに対し商品を預った旨のEメールを送信するための処理を行なうEメール送信処理手段が構成されている。S317〜S340により、前記商品預り場に設けられ、ユーザが仮想人物(バーチャルパーソン)として商品を引取りにきた場合に、当該ユーザに対し該当する商品を引渡すための処理を行なう商品引渡し処理手段が構成されている。この商品引渡し処理手段は、引取りにきたユーザの仮想人物(バーチャルパーソン)が本人であることを確認できたことを条件として引渡し処理を行なう。前記商品引き渡し処理手段は、引き渡す商品が決済済みであるか否かを判別し、決済済みでない場合には決済が行なわれたことを条件として商品の引渡し処理を行なう。
以上の実施の形態には以下の発明が開示されている。
(1) コンピュータシステムを利用して、ネットワーク上で個人情報を保護する個人情報保護方法であって、
ユーザがネットワーク(広域・大容量中継網43)を通してアクセスし自己の個人情報を提供するサイトを特定するために用いる識別情報であって、前記個人情報を入手した者がその個人情報主であるユーザにメール(Eメール,ダイレクトメール)を送る場合に該メールに含まれることとなる識別情報(匿名としてのトラップ型VP氏名, 図44(a)のEKSB(サイト名),サイト毎に使い分けるEメールアドレスやダイレクトメール用の住所)をプロセッサ(CPU24)を利用して生成する識別情報生成ステップ(S620とS621またはS960〜S956)と、
該識別情報生成ステップにより生成された識別情報を用いてユーザがサイトにアクセスして個人情報を提供する個人情報提供ステップ(S593,S600,S700,S701)と、
該個人情報提供ステップにより提供された前記個人情報を入手した者が該個人情報主であるユーザに対し送ったメールに含まれている前記識別情報に基づいて特定される前記サイトと前記メールの送り主とが一致するか否かを判定して前記ユーザの個人情報の流通状態を監視する監視ステップ(S516またはS969)とを含む個人情報保護方法。
(2) 前記識別情報は、サイト毎に使い分けるユーザの匿名(図11,図44(a)に示すトラップ型VP氏名)である。
(3) コンピュータシステムを利用して、ネットワーク上での個人情報を保護する個人情報保護装置であって、
ユーザがネットワーク(広域・大容量中継網43)を通してアクセスし自己の個人情報を提供したサイトを特定するために用いる識別情報を特定可能な情報であって、前記個人情報を入手した者がその個人情報主であるユーザにメールを送る場合には該メールに含まれることとなる識別情報を特定可能な情報(匿名としてのトラップ型VP氏名,図44(a)のKSBとサイト名,サイト毎に使い分けるEメールアドレスやダイレクトメール用の住所)を格納する識別情報格納手段(データベース12a,EEPROM26)と、
前記個人情報を入手した者がその個人情報主であるユーザに対し送ったメール(Eメール,ダイレクトメール)に含まれている前記識別情報に基づいて特定される前記サイトと前記メールの送り主とが一致するか否かを判定して前記ユーザの個人情報の流通状態を監視する監視手段(S516,S522,S523)とを含む個人情報保護装置。
(4) 前記監視手段は、前記識別情報に基づいて特定される前記サイトに前記ユーザが自己の個人情報を提供した際に承諾した当該個人情報の流通許容範囲内(XMLストア50のデータベース72に格納されているプライバシーポリシーによって特定される流通許容範囲内)に前記メールの送り主が含まれていない場合に不適正である旨の判定(S523によるNOの判定)を行なう。
(5) コンピュータシステムを利用して、ネットワーク(広域・大容量中継網43)上での個人情報を保護する個人情報保護装置であって、
ユーザがネットワークを通してアクセスし自己の個人情報を提供したサイトを特定するために用いる識別情報を特定可能な情報であって、前記個人情報を入手した者がその個人情報主であるユーザにメール(Eメール,ダイレクトメール)を送る場合には該メールに含まれることとなる識別情報を特定可能な情報(匿名としてのトラップ型VP氏名,図44(a)のKSBとサイト名,サイト毎に使い分けるEメールアドレスやダイレクトメール用の住所)を格納する識別情報格納手段(S622,EEPROM26)と、
ユーザがネットワークを通してサイトにアクセスする際に、当該サイトを特定するために用いる識別情報が既に前記識別情報格納手段に格納されている場合には、当該格納されている識別情報を前記サイトに対して用いるための処理を行なう識別情報使用制御手段(S623〜S628)とを含む、個人情報保護装置。
(6) ユーザと当該ユーザが用いる前記識別情報との対応関係を特定可能な情報を守秘義務のある所定機関(金融機関7)において登録する処理を行なうための登録処理手段(S440)を、前記個人情報保護装置がさらに含む。
(7) 前記識別情報は、ユーザが前記サイト毎に使い分ける匿名(トラップ型VP氏名)である(図11参照)。
(8) 前記個人情報保護装置は、前記ユーザが前記匿名を用いてネットワーク上で行動する際に使用する前記匿名用の電子証明書を発行する処理を行なうための電子証明書発行処理手段(S441)をさらに含んでいる。
(9) 前記電子証明書は、ユーザと当該ユーザが用いる前記識別情報との対応関係を特定可能な情報を登録している守秘義務のある所定機関(金融機関7)により発行され、前記匿名を用いるユーザが当該所定機関において登録されているユーザであることを証明するものである。
(10) 前記ユーザが前記匿名を用いてネットワーク上で行動する際の住所を、前記ユーザの住所とは異なる住所(コンビニエンスストア2の住所)に設定する処理を行なう住所設定手段(S11,S12)を、前記個人情報保護装置がさらに含んでいる。
(11) 前記住所設定手段は、所定のコンビニエンスストアの住所を設定する(S11,S12参照)。
(12) 前記個人情報保護装置は、前記ユーザが前記匿名を用いてネットワーク上で行動するべくサイトにアクセスする場合には、ユーザが実名(たとえば太郎)を用いてネットワーク上で行動した際にサイト側からユーザを識別するために送信されてきた識別データ(クッキー)を、アクセスするサイトに送信しないようにするための処理を行なう識別データ制御処理手段(S590〜S602)をさらに含む。
(13) 前記識別データ制御処理手段は、
前記匿名を用いてアクセスしたサイト(たとえばMTT,MEC等)から送られてきた前記識別データ(クッキー)のみを当該匿名専用の識別データとして格納する匿名対応識別データ格納手段(S595,S276,EEPROM26のクッキーデータ記憶領域(図11参照))と、
以降ユーザが前記匿名を用いて当該匿名により特定される前記サイトにアクセスする場合に、前記匿名対応識別データ格納手段を検索して当該匿名に対応する識別データを割出し、該識別データを前記サイトへ送信する識別データ検索送信手段(S623〜S628)とを含んでいる。
(14) 前記個人情報保護装置は、
ユーザが前記匿名を用いてネットワーク上で行動した場合の行動履歴(どのサイトにアクセスしたか等のアクセス履歴等)をどの匿名を用いて行動したかを特定できる態様で格納する行動履歴データ格納手段(データベース12a(図4参照))と、
ユーザが前記匿名を用いてアクセスしたサイト側から、前記ユーザの他の匿名を用いてのネットワーク上での行動履歴データの提供を求められた場合に、前記行動履歴データ格納手段を検索して前記他の匿名を用いての行動履歴データを前記サイトへ提供するための処理を行なう行動履歴データ提供処理手段(S530〜S546)とをさらに含む。
(15) 前記個人情報保護装置は、前記行動履歴データ提供処理手段に対し匿名を通知して該匿名を用いたユーザの他の匿名を用いてのネットワーク上での行動履歴データの提供を要求された場合に(ユーザの氏名が送信されてきてS535によりYESの判断がなされた場合に)、該要求者と前記通知された匿名に基づいて特定される前記サイトとが一致するか否かを判定して前記ユーザの個人情報の流通状態を監視する監視手段(S548)をさらに含む。
(16) 前記個人情報保護装置は、あるユーザによって使用された複数種類の匿名のための共通のクレジット番号(VP本名のクレジット番号)を各匿名から割出し可能な態様で格納するための処理を行なうクレジット番号格納処理手段(S438〜S440)と、
ユーザが前記匿名を用いてネットワーク上でクレジット決済を行なった場合に、クレジット会社からの当該匿名に対応するクレジット番号の有無の問合せを受付け、前記クレジット番号登録処理手段により登録されたクレジット番号を検索して前記問合せのあった匿名に対するクレジット番号の有無を判別し、その判別結果を前記クレジット会社に通知するための処理を行なう通知手段(S560〜S574)とを含んでいる。
(17) 前記個人情報保護装置は、ユーザが前記匿名によりネットワーク上で行動する際の当該匿名宛の電子メールを受付け、該電子メールを当該匿名に対応するユーザが閲覧可能な電子メールアドレスに転送する、匿名宛電子メール転送手段(S514〜S522)をさらに含む。
(18) 前記個人情報保護装置は、前記匿名宛電子メール転送手段が受付けた前記電子メールの宛名である匿名に基づいて特定される前記サイトと前記受付けた電子メールの送り主とが一致するか否かを判定して前記ユーザの個人情報の流通状態を監視する監視手段をさらに含む。
(19) 前記監視手段は、複数のユーザに対し適正であるか否かの判定サービスを行なう所定機関(金融機関7)に設置され、該所定機関には、前記監視手段による監視結果を集計してサイト毎の個人情報に関する信頼度を算出する信頼度算出手段(S550,S551)と、
該信頼度算出手段により算出された信頼度情報を提供する信頼度情報提供手段(S553)とが備えられている。
(20) 前記匿名は、当該匿名を用いるサイトの名称を、当該匿名を用いるユーザが使用できる鍵(秘密鍵)で暗号化または復号化したものである。
(21) ネットワーク(広域・大容量中継網43)上での個人情報を保護するためのプログラムであって、
プロセッサ(CPU24)に、
ユーザがネットワークを通してアクセスし自己の個人情報を提供したサイトを特定するために用いる識別情報を特定可能な情報であって、前記個人情報を入手した者がその個人情報主であるユーザにメール(Eメール,ダイレクトメール)を送る場合には該メールに含まれることとなる識別情報を特定可能な情報(トラップ型VP氏名,図44(a)に示すKSBとサイト名,サイト毎に使い分けるEメールアドレスやダイレクトメール用の住所)をメモリ(EEPROM26)に記憶させる識別情報記憶手段(S622)と、
ユーザがネットワークを通してサイトにアクセスする際に、当該サイトを特定するために用いる識別情報が既に前記メモリに記憶されている場合には、当該記憶されている識別情報を前記サイトに対し用いるための処理を行なう識別情報使用制御手段(S625〜S627)と、
して機能させるためのプログラム。
(22) 前記識別情報は、ユーザがサイト毎に使い分ける匿名(トラップ型VP氏名)であり、
プロセッサに、さらに、
前記ユーザが前記匿名を用いてネットワーク上で行動するべくサイトにアクセスする場合には、ユーザが実名(たとえば太郎)を用いてネットワーク上で行動した際にサイト側からユーザを識別するために送信されてきた識別データ(クッキー)を、アクセスするサイトに送信しないようにする処理を行なう識別データ制御処理手段(S623〜S628)として機能させる。
(23) 前記識別データ制御処理手段は、
前記匿名を用いてアクセスしたサイトから送られてきた前記識別データ(クッキー)のみを当該匿名専用の識別データとしてメモリに記憶させる匿名対応識別データ記憶手段(S622)と、
以降ユーザが前記匿名を用いて当該匿名により特定される前記サイトにアクセスする場合に、前記メモリを検索して当該匿名に対応して格納されている識別データを割出し、該識別データを前記サイトへ送信するための処理を行なう識別データ検索送信処理手段(S625〜S627)とを含む。
(24) ネットワーク(広域・大容量中継網43)上で個人情報を保護するためのプログラムであって、
プロセッサ(CPU24)に、
ユーザがネットワークを通してアクセスするサイトに対し、当該サイトの名称を当該ユーザが使用できる鍵(秘密鍵KSB)により暗号化または復号化して生成した匿名(トラップ型VP氏名)を使用し、匿名宛の電子メールを受信した場合に、当該電子メールの宛名である匿名を鍵(公開鍵KPB)により復号化または暗号化して平文のサイトの名称に戻す変換手段(S969)と、
して機能させるためのプログラム。
(25) プロセッサ(CPU24)に、さらに、
前記変換手段により変換されたサイトの名称と前記受信した電子メールの送り主の名称とが一致するか否かを判定して前記ユーザの個人情報の流通状態を監視する監視手段(S969、S968)として機能させる、プログラム。
上記発明は、前述した(1)〜(25)のみに限定されるものではなく、(1)〜(25)の中から任意に2つ以上選択したものの組合せも、本発明の解決手段である。
上記発明は以下のような効果を奏する。
ユーザの個人情報を入手した者がその個人情報主であるユーザに対し送ったメールに含まれている識別情報に基づいて、当該個人情報を提供したサイトが特定されるのであり、そのサイトと前記メールの送り主とが一致するか否かが判別される。個人情報の提供を受けたサイトが他の業者にその個人情報を流通させてその個人情報を受取った業者から当該個人情報のユーザに対しメールが送られた場合には、そのメールに含まれている識別情報に基づいて特定されるサイトとそのメールの送り主である業者の名前とが一致しないこととなる。その結果、ユーザの個人情報の第1譲渡先のサイトから他の業者にその個人情報が譲ったことが判別可能となる。
前記識別情報がサイト毎に使い分けられるユーザの匿名の場合には、個人情報を入手した業者がユーザを特定するのにその匿名を用い、その匿名からは当該ユーザの個人情報の第1譲渡先であるサイト名が特定できる。
識別情報に基づいて特定されるサイトにユーザが自己の個人情報を提供した際に承諾した当該個人情報の流通許容範囲内にメールの送り主が含まれていない場合に不適正である旨の判定が行なわれるようにした場合には、個人情報の譲渡時のユーザの個人情報流通許容範囲の承諾をも考慮した適否判定が可能となる。
ユーザがネットワークを通してサイトにアクセスする際に、当該サイトを特定するために用いる識別情報が既に用いられている場合に、その識別情報を前記サイトに対して用いるための処理が行なわれるために、同じサイトに対して複数種類の識別情報を用いる無駄を省くことができる。
ユーザとそのユーザが用いる前記識別情報との対応関係を特定可能な情報が守秘義務のある所定機関に登録された場合には、たとえばユーザと業者側との間において、ユーザと前記識別情報との対応関係をめぐるトラブルが発生した場合に、所定機関に登録されている対応関係の情報を参照することが可能となる。
前記匿名用の電子証明書が発行された場合には、ユーザがたとえば売買を行なう際に相手側にその電子証明書を提示して匿名として売買を行なうことが可能となり、ユーザが匿名を用いて法律行為を行なうことが可能となる。
ユーザが匿名を用いてネットワーク上で行動する際の住所が、当該ユーザの住所とは異なる住所に設定されれば、その住所を手掛かりにある匿名とあるユーザとが同一人物であることを突き止められてしまう不都合を極力防止することができる。
ユーザが匿名を用いてネットワーク上で行動する際の住所がコンビニエンスストアの住所であれば、匿名を用いてたとえば電子ショッピング等を行なった場合の商品の届出先がそのコンビニエンスストアとなり、ユーザが匿名としてその商品を引取りに行く際の利便性が向上する。
ユーザが匿名を用いてネットワーク上で行動するべくサイトにアクセスする場合には、ユーザが実名を用いてネットワーク上で行動した際にサイト側からユーザを識別するために送信されてきた識別データを、アクセスするサイトに送信しないようにするための処理が行なわれた場合には、その識別データを手掛かりにある匿名とあるユーザとが同一人物であることが見破られてしまう不都合を極力防止することができる。
匿名を用いてアクセスしたサイトから送られてきた前記識別データのみが当該匿名専用の識別データとして格納され、以降ユーザが前記匿名を用いて当該匿名により特定されるサイトにアクセスする場合に、その匿名に対応する識別データが前記サイトへ送信されるようにした場合には、識別情報を手掛かりにある匿名と他の匿名とが同一人物であることが見破られてしまう不都合を極力防止することができる。
その際に、ユーザが匿名を用いてアクセスしたサイト側から、ユーザの他の匿名を用いての行動履歴データを前記サイトへ提供できるようにした場合には、識別データを手掛かりにある匿名と他の匿名とが同一人物であることを見破られる不都合を防止できながらも、同一人物に関するネットワーク上の行動履歴データをサイト側に提供して、その行動履歴データに基づいたよりカスタマイズされたユーザ好みの情報やサービスをユーザ側に提供しやすくなる。
ユーザが匿名を用いてネットワーク上でクレジット決済を行なった場合に、クレジット会社から当該匿名に対応するクレジット番号の有無の問合せを受け、その匿名のための共通のクレジット番号が検索されて、問合せのあった匿名に対応するクレジット番号の有無が判別され、その判別結果がクレジット会社に通知されるために、複数種類の匿名のための共通のクレジット番号までクレジット会社に登録しておく必要がなくなり、その共通のクレジット番号を手掛かりにある匿名と他の匿名とが同一人物であることを見破られる不都合が極力防止できる。
ユーザが匿名によりネットワーク上で行動する際の当該匿名宛の電子メールが受付けられてその電子メールが当該匿名に対応するユーザが閲覧可能な電子メールアドレスに転送されるために、電子メールアドレスを手掛かりにある匿名と他の匿名とが同一人物であることを見破られる不都合を極力防止することができる。
その匿名宛の電子メールの転送の際に、その電子メールの宛名である匿名に基づいて特定されるサイトとその電子メールの送り主とが一致するか否かを判定してユーザの個人情報の流通状態が監視されるために、電子メールの転送時に自動的に監視がなされてユーザの利便性が向上する。
信頼度算出手段により算出されたサイト毎の個人情報に関する信頼度が提供されれば、ユーザがサイトに対し個人情報を提供する際の判断基準となり、ユーザの利便性が向上する。
ユーザが使用できる鍵でサイトの名称を暗号化または復号化したものを、当該サイトに用いる匿名にした場合には、業者側から送られてきたメールの宛名である匿名を、鍵により復号化または暗号化することによってサイト名に変換することができる。
今回開示された実施の形態はすべての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は上記した説明ではなくて特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。
I インターネット、43 広域・大容量中継網、1 サプライヤ群、4 クレジットカード発行会社群、7 金融機関群、5 加盟店契約会社群、50 XMLストア、2 コンビニエンスストア群、45 会社群、30 ブラウザフォン、54 携帯電話網、55 基地局、47 ユーザ宅、9 VP管理サーバ、10 決済サーバ、11 認証用サーバ、12a,12b データベース、72 データベース、75 データベース、19V VP用IC端末、19R RP用IC端末、18 USBポート、26 EEPROM、33 支払承認部、34 支払要求部。

Claims (5)

  1. コンピュータシステムを利用して、ネットワーク上での個人情報を保護する個人情報保護装置であって、
    ユーザがネットワーク上で行動した結果第1ウェブサイトに蓄積された行動履歴データを該第1ウェブサイトとは別の第2ウェブサイトへ提供するための制御を行なう行動履歴データ提供制御手段を含み、
    該行動履歴データ提供制御手段は、
    前記ユーザが前記第2ウェブサイトに前記行動履歴データを提供してもよい旨を承諾したことを証する電子的許可証を前記第2ウェブサイトから受付ける許可証受付手段と、
    該許可証受付手段により受付けられた前記電子的許可証が適正か否か判定する判定手段と、
    該判定手段により適正であるとの判定が行なわれたことを条件として、前記行動履歴データの前記第2ウェブサイトへの提供を許容するための制御を行なう許容制御手段と、
    前記第2ウェブサイトが前記電子的許可証を所有していない場合に、前記第2ウェブサイトに前記行動履歴データを提供してもよい旨を前記ユーザが承諾したことを確認する確認手段と、
    該確認手段による前記承諾したことの確認ができない場合に前記行動履歴データの前記第2ウェブサイトへの提供を拒否する制御を行なう拒否制御手段とを有する、個人情報保護装置。
  2. 前記ユーザが前記第2ウェブサイトに前記行動履歴データを提供する際に条件付きで前記行動履歴データを提供する旨の承諾を行なうことが可能であり、
    前記確認手段は、前記条件付きで承諾したことを確認する、請求項1に記載の個人情報保護装置。
  3. 現実世界での実在人物を特定して識別するための実在人物用識別データとは異なる仮想人物を識別するための仮想人物用識別データを生成する仮想人物用識別データ生成手段と、
    前記実在人物であるユーザが前記仮想人物としてネットワーク上で行動してウェブサイトにアクセスする際に、ユーザを特定する情報の要求に応じて、当該ユーザに対応する前記仮想人物用識別データを当該ウェブサイトの業者に提供する提供手段とをさらに含む、請求項1または請求項2に記載の個人情報保護装置。
  4. 前記仮想人物用識別データは、前記ウェブサイトの業者に提供されるユーザの匿名としてのコードデータを含む、請求項1〜請求項3のいずれかに記載の個人情報保護装置。
  5. 前記仮想人物用の電子証明書を発行する電子証明書発行手段をさらに含む、請求項1〜請求項4のいずれかに記載の個人情報保護装置。
JP2012189990A 2012-08-30 2012-08-30 個人情報保護装置 Expired - Lifetime JP5198678B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2012189990A JP5198678B2 (ja) 2012-08-30 2012-08-30 個人情報保護装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2012189990A JP5198678B2 (ja) 2012-08-30 2012-08-30 個人情報保護装置

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2010254057A Division JP5168676B2 (ja) 2010-11-12 2010-11-12 個人情報保護装置

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2013005051A Division JP5257911B2 (ja) 2013-01-16 2013-01-16 個人情報保護装置

Publications (2)

Publication Number Publication Date
JP2013012224A true JP2013012224A (ja) 2013-01-17
JP5198678B2 JP5198678B2 (ja) 2013-05-15

Family

ID=47685989

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2012189990A Expired - Lifetime JP5198678B2 (ja) 2012-08-30 2012-08-30 個人情報保護装置

Country Status (1)

Country Link
JP (1) JP5198678B2 (ja)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH11250165A (ja) 1997-11-12 1999-09-17 Citicorp Dev Center Inc 分散ネットワークベースの電子ウォレット
JP2001188757A (ja) * 1999-12-28 2001-07-10 Nippon Telegr & Teleph Corp <Ntt> 証明書を用いたサービス提供方法
JP2003067524A (ja) 2001-08-28 2003-03-07 Laurel Intelligent Systems Co Ltd 個人情報保護方法、個人情報保護装置およびプログラム
JP2011060316A (ja) 2010-11-12 2011-03-24 Laurel Intelligent Systems Co Ltd 個人情報保護方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH11250165A (ja) 1997-11-12 1999-09-17 Citicorp Dev Center Inc 分散ネットワークベースの電子ウォレット
JP2001188757A (ja) * 1999-12-28 2001-07-10 Nippon Telegr & Teleph Corp <Ntt> 証明書を用いたサービス提供方法
JP2003067524A (ja) 2001-08-28 2003-03-07 Laurel Intelligent Systems Co Ltd 個人情報保護方法、個人情報保護装置およびプログラム
JP2011060316A (ja) 2010-11-12 2011-03-24 Laurel Intelligent Systems Co Ltd 個人情報保護方法

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
JPN3013001618; 国際公開第99/24891号公報 , 19990520, 世界知的所有権機関
JPN3013001623; 塚本豊: 上申書 , 20120830

Also Published As

Publication number Publication date
JP5198678B2 (ja) 2013-05-15

Similar Documents

Publication Publication Date Title
WO2002033610A1 (fr) Procede et systeme de protection d&#39;informations personnelles, dispositif de traitement, emetteur-recepteur portatif et programme
US11783323B1 (en) Autonomous devices
US10862671B2 (en) Global ownership registry
JP4597867B2 (ja) プライバシー保護方法、プライバシー保護用識別子発信装置、プライバシー保護システムおよびプログラム
KR101661933B1 (ko) 블록체인을 기반으로 하는 공인인증서 인증시스템 및 이를 이용한 인증방법
CN107005563B (zh) 用于机器对机器装置的供应平台
ES2299667T3 (es) Un sistema de gestion de la informacion.
KR101155858B1 (ko) 전자 이체 시스템
KR100792147B1 (ko) 휴대폰번호 또는 소정의 가상번호를 이용한 쌍방향금융결제 서비스 방법
JP3987710B2 (ja) 認定システムおよび認証方法
US20140032589A1 (en) Domain name searching with reputation rating
US20090165107A1 (en) Identification managment system for electronic device authentication
CN105580038A (zh) 用于可互操作的网络令牌处理的系统和方法
CN109791660A (zh) 数据保护系统和方法
JP2004517381A (ja) 電子契約のために電子通信を用いる方法およびシステム
JP2002298055A (ja) 電子商取引システム
JP5544486B2 (ja) 個人情報管理装置
JP5158662B2 (ja) 個人情報保護装置
JP5510690B2 (ja) 個人情報保護装置
JP5257912B2 (ja) 個人情報管理装置
JP5168676B2 (ja) 個人情報保護装置
JP2001216360A (ja) 予約証明証発行装置および方法
JP5257911B2 (ja) 個人情報保護装置
JP5198678B2 (ja) 個人情報保護装置
JP5326178B2 (ja) 個人情報管理装置

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20121218

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20130116

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20130205

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20130206

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20160215

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Ref document number: 5198678

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

S111 Request for change of ownership or part of ownership

Free format text: JAPANESE INTERMEDIATE CODE: R313113

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

S533 Written request for registration of change of name

Free format text: JAPANESE INTERMEDIATE CODE: R313533

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

S111 Request for change of ownership or part of ownership

Free format text: JAPANESE INTERMEDIATE CODE: R313111

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

EXPY Cancellation because of completion of term