JP2005050311A - サービス提供方法及びシステム - Google Patents

Abstract

【課題】 利用者の匿名性を高めることができるサービス提供方法及びシステムを提供する。
【解決手段】 サービス提供者の端末が、サービス利用者に対してユーザＩＤを生成・発行するとともに該ユーザＩＤの正当性を証明する証明書を生成し、サービスの提供に必要なサービス利用者の個人情報を前記ユーザＩＤと関連付けて記憶し、一の利用者の端末が他の利用者を指定して前記サービス提供者によるサービスを利用する際にユーザＩＤ及び証明書を取得し、該証明書により前記ユーザＩＤの正当性を検証してサービス提供者の端末に提示し、サービス提供者が該ユーザＩＤに関連付けられた個人情報基づきサービス提供を行う。
【選択図】 図６

Description

本発明は、例えばオンラインショッピング業者と顧客との間の通信のようにネットワーク上での利用者間の通信において、利用者が第三者であるサービス提供者からサービスを受ける際の利用者のプライバシを保護する技術に関する。

現実社会においては、二者が何らかの取引や契約等を行う場合、顔と顔を突き合わせ相手がどのような人物であるかを自分で判断したり、その場で価値のあるもの同士（例えば商品と現金）の交換を行ったり、クレジットカードを用いてカード会社による与信情報及び本人の署名を用いたりすることにより、互いに相手を信頼して取引等を行っている。これは現実社会における一種の認証モデルということができる。

一方、ネットワーク上における取引等では、相手や商品等を現実に確認することができないので、前述のような現実社会における認証モデルをそのまま用いることは非常に困難である。そこで、ネットワーク上での取引では、クレジットカードのように第三者による与信情報を用いることにより認証が行われてきた。すなわち、例えばオンラインショッピングにおいては、ショップは顧客からクレジットカード番号，カードホルダ名，有効期限を受信し、これらの情報から当該クレジットカード番号が正当なものであるかをクレジットカード会社に問い合わせ、正当なものであるならば商品の販売を行う。そして、販売後にはクレジットカード会社により決済を行う。

しかし、クレジットカードによる決済システムは元々ネットワーク上における取引を想定していないため、なりすましなどのトラブルが非常に大きな問題となっている。また、クレジットカード番号という個人を一意に特定可能な番号を用いているために、個人の行動履歴を集積し、個人の行動パターンが分かるようになり、新たなプライバシ侵害が起きる可能性がある。また、この個人情報の集積は、クレジットカード番号だけでなく、氏名・住所等を用いても行えるため、これらの個人情報の流通活用は重大なプライバシ侵害を起こす可能性がある。

さらに、現状では、例えば氏名・住所など個人を特定することが可能な個人情報を多数の場所に提示しなければサービスを受けることができない。例えば、オンラインショッピングでは、クレジットカード番号という個人を特定可能な情報をショップに提示するとともに、購入商品を配送するために配送業者に住所・氏名等の個人を特定可能な情報を提示する必要がある。このように多数の者に対して個人情報を提示する必要があるため、個人情報が流出しても、どこから流出したかを特定することは困難であった。これにより、個人情報の取り扱いは情報を受け取ったシステムにより自由に行われることにとなり、個人情報売買を防ぐことは困難であった。さらに、一度提示してしまった個人情報は、削除することが非常に困難であり、流出してしまった個人情報は取り戻すことができないという問題があった。

このような問題を解決するために、サービス提供者が顧客とショップの間に入り、両者の間で匿名でサービスを行う方法なども提案されている（特許文献１参照）。具体的には、配送サービスなどを行うサービス提供者が、顧客から受信した住所・氏名等を登録するとともに該顧客に対して匿名ＩＤを発行する。顧客はショップで商品を購入する際には自身を識別する情報として氏名等を提示するのではなく前記匿名ＩＤを提示する。ショップはサービス提供者に対して匿名ＩＤを提示して商品の配送を依頼する。サービス提供者は提示された匿名ＩＤに対応する住所・氏名等を宛先として商品を配送する。これにより、ショップは「何を購入したか」はわかるが、「誰が購入したか」は分からない。一方、サービス提供者は「誰が何処から購入したか」はわかるが、「何を購入したか」はわからない。
特開２００２−７９０４号公報

しかし、従来の方法では、匿名でサービス提供を行うサービス提供者に全ての情報が集中してしまうため、プライバシ情報の蓄積がなされてしまう。したがって、ひとたび匿名サービス提供者からの情報流出が生じるとその被害は甚大なものになる恐れがあった。

本発明は、上記事情に鑑みてなされたものであり、その目的とするところは、利用者の匿名性を高めることができるサービス提供方法及びシステムを提供することにある。

上記目的を達成するために、本願では、ネットワークを介して複数の利用者の間でなされる利用者間通信において、利用者に対してサービスの提供を行うサービス提供者の端末が、サービス利用者に対してユーザＩＤを生成・発行するとともに該ユーザＩＤの正当性を証明する証明書を生成するステップと、サービスの提供に必要なサービス利用者の個人情報を前記ユーザＩＤと関連付けて記憶するステップと、前記利用者間通信において一の利用者の端末が、他の利用者を指定して前記サービス提供者によるサービスを利用する際に前記他の利用者の端末からユーザＩＤを取得するステップと、サービス提供者の端末から直接又は前記他の利用者の端末を介して前記ユーザＩＤの証明書を取得するステップと、該証明書により前記ユーザＩＤの正当性を検証するステップと、該ユーザＩＤをサービス提供者の端末に提示するステップと、サービス提供者の端末が、前記一の利用者の端末が提示したユーザＩＤに関連付けられた個人情報を抽出するステップと、サービス提供者が該個人情報に基づきサービス提供を行うステップとを含むことを特徴とするサービス提供方法を提案する。

また、本願では、ネットワークを介して複数の利用者の間でなされる利用者間通信において、一の利用者の端末が、他の利用者に対してユーザＩＤ及び該ユーザＩＤの正当性を証明する証明書を生成・発行するステップと、サービス提供者の端末が、前記他の利用者の端末から受信したユーザＩＤ及び証明書とサービスの提供に必要なサービス利用者の個人情報とを関連付けて記憶するステップと、前記利用者間通信において一の利用者の端末が、他の利用者を指定して前記サービス提供者によるサービスを利用する際に前記他の利用者の端末からユーザＩＤを取得するステップと、サービス提供者の端末から直接又は前記他の利用者の端末を介して前記ユーザＩＤの証明書を取得するステップと、該証明書により前記ユーザＩＤの正当性を検証するステップと、該ユーザＩＤをサービス提供者の端末に提示するステップと、サービス提供者の端末が、前記一の利用者の端末が提示したユーザＩＤに関連付けられた個人情報を抽出するステップと、サービス提供者が該個人情報に基づきサービス提供を行うステップとを含むことを特徴とするサービス提供方法を提案する。

本発明によれば、利用者がサービス提供者からサービスを利用する際には、該サービス提供者又は利用者からユーザＩＤを発行してもらい、利用者間ではこのユーザＩＤを用いて利用者を特定することにより利用者の匿名性が向上する。これは、サービスの享受に必要な個人情報はサービス提供者に開示されることになるが、該個人情報のうち利用者間の通信において不要なものは利用者間で開示する必要がなくなるためである。

また、全ての個人情報を相手先利用者及びサービス提供者に開示する必要が無く、必要な個人情報のみを分散して開示できるので匿名性が高く、サービス提供者が結託しないかぎり個人の特定は困難となる。

さらに、サービス提供者又は利用者はユーザＩＤとともに該ユーザＩＤの正当性を証明する証明書を発行するので、相手先利用者からユーザＩＤの提示を受けた利用者は該証明書を取得・検証することにより、そのユーザＩＤが本当に相手先利用者のものであるかを確認できる。これにより、相手を特定する情報としてユーザＩＤしか提示されていなくても、該ユーザＩＤを用いたサービスの享受を安全に行うことができる。

なお、本発明の利用者及びサービス提供者の典型的且つ具体的な一例としてのオンラインショッピングシステムでは、顧客及びオンラインショップが本願発明の利用者に該当し、決算機関及び配送業者等がサービス提供者に該当する。

以上詳述したように、本発明によれば、プライバシ情報を分散して管理することにより、従来の方法に比べより匿名性の高い情報流通活用を行うことが可能となる。

本願発明では上述のように、サービス提供者は利用者に対してユーザＩＤ及び証明書を発行し、利用者から該ユーザＩＤを提示したサービス要求があればサービスを提供する。これは、サービス提供者が、「このユーザＩＤを有する者について与信を行った」と考えることができる。そこで、以下の説明では、サービス提供者を「与信者」として本願発明の原理について図面を参照して説明する。

図１は本発明の基本原理を説明するものである。図１に示すように、両利用者１１及び１２は自分の信頼する与信者２１に対して、自分の希望する与信内容に対して必要な情報及び対価を渡すことにより与信を依頼し、ユーザＩＤを取得する。このとき、与信者２１に渡す個人情報を可能な限り少なくすることにより、個人情報が特定の者に集積されることを防ぐ。

与信者２１と両利用者１１，１２の間では、電子署名を用いた認証や取引を行う。取引を行う際には与信者２１を介さず、利用者１１，１２間で互いに認証を行うことにより、取引を行った時間や内容を与信者に知られないようにすることができる。取引においては、利用者１１，１２は自分の提示する条件に対して自分が用意した暗号鍵を用いて署名を行い、受け取ったもう一方の利用者１２，１１は署名を検証し、与信者２１による保証を担保に相手の示した条件を信頼する。支払などの決済処理を行う場合は、金額の記載された文書に署名を行った支払証明書を交換し、与信者２１を介して金銭の移動を行う。このとき、与信者２１は金銭の移動のみを知ることができ、取引内容については知ることができない。

次に、利用者１１，１２間の取引を本人の同意がある場合にのみ連携させる方法について図２を用いて説明する。利用者１１が利用者１２及び利用者１３に対して、同じ名前（識別子：ＩＤ）で取引を行う場合、匿名処理を行っていたとしても、利用者１２と利用者１３とが、利用者１１を同じＩＤで認識している場合、利用者１２と利用者１３が結託してしまうと利用者１１の情報を集積することが可能となってしまう。そこで、本願発明では、利用者が取引を行う相手それぞれに対して別のＩＤを使うことによって、情報の集積を行わせないようにする。例えば、利用者１１は個人、与信者２１は銀行やクレジットカード会社のような決済機関、利用者１２及び１３は商品販売店という構成が考えられる。利用者１１は利用者１２で商品の購入を行い、与信者２１が支払を保証することにより、利用者１１は利用者１２との間の売買契約を行う。但しこのとき、利用者１１は銀行口座番号やクレジットカード番号といった他者に対しても同じ番号で認識されるようなユーザＩＤではなく、相手（利用者１２及び１３）によって全て違うユーザＩＤ（場合によっては取引に応じて毎回違うユーザＩＤ）を用いることによって、相手によって自分が与信者２１から与信をうけているということの認証を行う。また、与信者２１は利用者１１，１２，１３間の取引内容のうち、決済に係わる情報のみを知ることができる。また、図３に示すように、利用者１１と利用者１２の間の配送を行う与信者２２が与信者２１と並列に入ることによって、利用者１１は決済と同様に匿名で商品の配送を受けることができる。また、与信者２１と与信者２２の間で連携を行うことにより、商品の配達が終了したことを通知し、それを基に決済処理を行うことも可能である。これは、商品を受け取っていないのに決済処理がされるのを防ぐことを目的としている。

このように、複数の与信者が利用者間にはいることにより、個々の与信者が得ることのできる内容を減少させ、情報を分散させることが可能であり、与信者同士が結託しなければ、プライバシを守ることが可能である。与信者が二者いる場合の取引方法について図４を用いて説明する。利用者１１は、与信者２１を介して匿名で与信者２２と与信契約を行う（図４（ａ））。次に、利用者１１は与信者２２を介して利用者１２と取引を行うことができる（図４（ｂ））。例えば、与信者２１は決済機関で利用者１１の個人を特定できるような情報を持っていて、決済処理を行うことができる。与信者２２は、利用者１１の個人を特定できるような情報を持っていないが、個人を特定しない範囲の情報（性別、年齢、居住地域、趣味、行動履歴など）を持っていて、マーケッティング処理などを行うことができる。利用者１２は、商品の販売店などで商品者の購買動向の調査を与信者２２に依頼することができる。与信者２２は利用者１２から受けた調査に対する報酬を与信者２１を介することによって匿名の状態でも顧客である利用者１１に還元することができる（図４（ｃ））。このプロセスによって、与信者２２及び利用者１２は、利用者１１の個人を特定することができないが、情報を活用することが可能であり、情報提供の対価を支払うことができる。

さらにもう一者与信者を追加したモデルについて図５を用いて説明する。利用者１１は与信者２１を介して与信者２２と与信契約を行い、利用者１２は与信者２３を介して与信者２２と与信契約を行う（図５（ａ））。その後、利用者１２は与信者２２を介して利用者１２と取引を行う。例えば、利用者１１及び１２は個人、与信者２１及び２３は決済機関、与信者２２はオークションサイトという構成が考えられる。利用者１１と利用者１２は与信者２２において個人間取引を行う。与信者２２は利用者間の取引内容（金銭の授受）を基に、与信者２１及び与信者２３の間で金銭の移動を行う（図５（ｂ））。図３と同様に与信者２２と並列に配送を行う与信者を追加することにより、オークションで問題になっている商品を送ったのに対価が貰えない、対価を払ったのに商品を受け取れないと言うことを防止することができる。

次に、本発明の具体的な実施形態について図面を参照して説明する。まず、本実施の形態の説明で使用する用語について説明する。以下の説明では登場する者として以下の５者がある。なお、下記リストで括弧の中に示されている「利用者」又は「サービス提供者」なる記載は、特許請求の範囲における用語である。

１．Ｕｓｅｒ：商品の購買などを行う顧客（利用者）の端末
２．ＳＰ：オンラインショップや実際の店舗など顧客にサービスや商品を提供する者（利用者）の端末
３．ＩＤＰ：課金決済系に関する与信者（サービス提供者）の端末
４．ＣＲＭ：個人情報に関する与信者（サービス提供者）の端末
５．Ｄｅｌｉｖｅｒｙ：配送に関する与信者（サービス提供者）の端末。

また、上記登場者に払い出されるＩＤとしては以下の３つがある。

１．ＰＩＤ：ユーザを管理（特定）するためにＩＤＰが発行するＩＤ。このＰＩＤは１ユーザにつき１つである。

２．ＵＩＤ：ユーザの匿名性のために、複数払い出されるＩＤ。このＵＩＤの発行は、１取引毎や１店舗に１つなどの形態がある。また、このＵＩＤは、ＩＤＰが発行してもよいし、ＳＰが発行してもよい。ＳＰが発行する場合は、１取引ではなく、ＳＰの顧客ＩＤとなることが多い。

３．ＳＰＩＤ：サービス提供者を識別するＩＤ。ＰＩＤのように固有のものであっても、ＵＩＤのように匿名のものであってもよい。個人個人間の取引の場合はＵＩＤになるし、オンラインショップであれば匿名性は必要なく逆に万人に知れ渡っている方がよいのでＰＩＤを用いた方がよいこともある。図には登場しないが、ＩＤＰも相互認証のためにＩＤを持つ。

上記の個々のＩＤには、認証を行うために公開鍵暗号方式の鍵ペアが割り当てられており、このＩＤを与信するものがＩＤ及び交換鍵に対して証明書を発行する。証明書には有効期限や与信の範囲（匿名決済であれば限度額など）などの情報を含んでいてもよい。

また、上記のＩＤは、一人のユーザが複数のＩＤ及び公開鍵暗号方式の鍵ペア（場合によっては証明書）を管理することになるため、ユーザ側では耐タンパ性があり且つ暗号化などの演算能力のある媒体たとえばＩＣカードに記憶される。これに伴い、Ｕｓｅｒは該ＩＣカードの読み書き手段を備えており、各ＩＤや証明書等をネットワークを介してＳＰやＩＤＰ等に送信可能となっている。このように、ＩＣカードを用いることにより、使用するＩＤを自動的に判別し、ユーザが複数のＩＤなどを意識することなく安全に利用可能である（一つのＩＤでシングルサインオンを行うシステムと比較して安全である）。また、Ｕｓｅｒは、ＳＰやＩＤＰ等に接続して登録作業等を行うための手段としてブラウザを備えている。

ＳＰ，ＩＤＰ，ＣＲＭ，Ｄｅｌｉｖｅｒｙはそれぞれ、各ＩＤ及び個人情報や各ＩＤに対応する公開鍵等を記憶・管理する記憶手段、公開鍵暗号方式を用いた暗号化復号化処理部と、通信相手に対してＩＤを払い出す機能や該ＩＤに対応する証明書（後述する）等を提供する機能等を備えたＩＤ提供部と、通信相手先にサービスの提供を行うサービス提供部を備えている。本実施の形態では、ＩＤ提供部やサービス提供部による機能提供ではインタフェイスとしてＷｅｂを用いている。

［ＵＩＤの発行方法］
次に、前記ＵＩＤの発行及び認証方法について説明する。ここでは、ＳＰはすでにＩＤＰから与信を受けている状態とする。また、ＩＤＰの公開鍵は、誰でも入手可能とする。

［ＳＰによるＵＩＤの発行］
まず、ＳＰがＵＩＤを発行する場合について図６を参照して説明する。Ｕｓｅｒ１は、ＩＤＰ２に与信をしてもらうべく申請（登録）を行う（ステップＳ１０１）。この際、プリペイド的なサービスであればお金の入金が、クレジットカード的なサービスであれば、個人情報（氏名・住所・勤務先・年収など）を知らせる必要がある。次に、ＩＤＰ２はＵｓｅｒ１を識別するためのＩＤ（ＰＩＤ）を作成する（ステップＳ１０２）。次に、ＩＤＰ２は作成したＰＩＤをＵｓｅｒ１に送信する（ステップＳ１０３）。次に、Ｕｓｅｒ１は受け取ったＰＩＤに対し認証用パスワードに相当する公開鍵暗号方式の鍵ペア（ＰＫ，ＳＫ）を作成する（ステップＳ１０４）。鍵の作成はＩＣカード内部で行うことが望ましいが、外部に秘密鍵が漏れなければよい。次に、Ｕｓｅｒ１は、作成した鍵ペアのうち公開鍵ＰＫをＩＤＰ２に送信し、ＩＤＰ２に登録する（ステップＳ１０５）。

ＩＤＰ２は、Ｕｓｅｒ１に対して作成したＰＩＤ及びＵｓｅｒ１から受信した公開鍵ＰＫに対し、ＩＤＰ２の秘密鍵を用いて署名を行い、証明書ＰＫＣを作成する（ステップＳ１０６）。この証明書ＰＫＣには、与信範囲、有効期限などの情報を含んでいてもよい。次に、ＩＤＰ２に対してオフラインでサービスの享受が可能なシステムの場合、証明書ＰＫＣをＵｓｅｒ１に送信し、ＩＣカード等の記録媒体に該証明書ＰＫＣを記憶する（ステップＳ１０７）。

以上のステップがＩＤＰ２とＵｓｅｒ１との間の登録作業である。

次に、Ｕｓｅｒ１は利用したいＳＰ３ｎに接続し、匿名で顧客登録を行う（ステップＳ１０８）。次に、ＳＰ３ｎはＵｓｅｒ１用の顧客ＩＤとしてＵＩＤｎを作成し（ステップＳ１０９）、該ＵＩＤｎをＵｓｅｒ１に送信する（ステップＳ１１０）。

次に、Ｕｓｅｒ１は受け取ったＵＩＤｎに対し認証用のパスワードに相当する公開鍵暗号方式の鍵ペア（ＰＫｎ，ＳＫｎ）を作成する（ステップＳ１１１）。鍵の作成については上記ステップＳ１０４と同様である。次に、Ｕｓｅｒ１は作成した鍵ペアのうち公開鍵ＰＫｎをＳＰ３ｎに送信し、ＳＰ３ｎに登録する（ステップＳ１１２）。

次に、ＳＰ３ｎはＵｓｅｒ１のＵＩＤｎ及び公開鍵ＰＫｎに対し、ＳＰ３ｎの秘密鍵を用いて署名を行い、証明書ＰＫＣｎを作成する（ステップＳ１１３）。この証明書には、有効期限などの情報を含んでいてもよい。ＳＰ３ｎは、作成した証明書ＰＫＣｎを必要に応じてＵｓｅｒ１に送信する（ステップＳ１１４）。

次に、Ｕｓｅｒ１はＳＰ３ｎに対する決済代行処理をＩＤＰ２に依頼する場合、ＳＰ３ｎのＩＤであるＳＰＩＤｎと顧客ＩＤであるＵＩＤｎと公開鍵ＰＫｎ（又は証明書ＰＫＣｎ）とをＩＤＰ２に登録する（ステップＳ１１５）。なお、Ｕｓｅｒ１がＩＤＰ２にログインする際の認証方法については後述する。この際、ＩＤＰ２はＵｓｅｒ１がＳＰ３ｎの正規の顧客であるかＰＫＣｎを用いて認証することができる。ＩＤＰ２では、依頼のあったＵＩＤｎをＵｓｅｒ１の識別ＩＤであるＰＩＤに関連付けを行う。

以上のステップがＳＰ３とＵｓｅｒ１の間の登録作業である。

次に、Ｕｓｅｒ１はＳＰ３ｎのサービスを受けるために、ＳＰ３ｎにログインする（ステップＳ１１６）。なお、Ｕｓｅｒ１がＳＰ３ｎにログインする際の認証方法については後述する。次に、ＳＰ３ｎは、ＩＤＰ２にログインし、自分の顧客ＵＩＤｎの顧客登録がなされいてるか確認する（ステップＳ１１７）。次に、ＩＤＰ２は、ＳＰＩＤｎ及びＵＩＤｎを用いて、ＰＩＤを検索し、登録の有無及び与信の範囲、有効期限などをＳＰ３ｎに通知する（ステップＳ１１８）。また、ＩＤＰ２は顧客により登録された公開鍵ＰＫｎ又は証明書ＰＫＣｎをＳＰ３ｎに送信する。次に、ＳＰ３ｎは、受信した公開鍵ＰＫｎ又は証明書ＰＫＣｎについて自身の公開鍵を用いて署名を確認し、公開鍵ＰＫｎを取り出した後、それが顧客ＵＩＤｎのものであるかを確認する。なお、ＩＤＰ２は、以後、このＵｓｅｒ１の証明書が失効した場合は、ＳＰ３ｎに通知するサービスなども可能である。

以上のステップによりＵＩＤが発行されたので、ＳＰ３ｎはＩＤＰ２の与信範囲に応じてＵｓｅｒ１にサービスを行うことができる。

［ＩＤＰによるＵＩＤの発行］
次に、ＩＤＰ２がＵＩＤを発行する場合について図７を用いて説明する。

まず、Ｕｓｅｒ１はＩＤＰ２に与信をしてもらうべく申請（登録）を行う（ステップＳ２０１）。この際、プリペイド的なサービスであればお金の入金が、クレジットカード的なサービスであれば、個人情報（氏名・住所・勤務先・年収など）を知らせる必要がある。次に、ＩＤＰ２はＵｓｅｒ１を識別するためのＩＤ（ＰＩＤ）と複数のＵＩＤを作成する（ステップＳ２０２）。次に、ＩＤＰ２は作成したＰＩＤ及びＵＩＤのセットをＵｓｅｒ１に送信する（ステップＳ２０３）。次に、Ｕｓｅｒ１は受け取ったＰＩＤ及びＵＩＤに対し認証用パスワードに相当する公開鍵暗号方式の鍵ペア（ＰＫ，ＳＫ）を作成する（ステップＳ２０４）。鍵の作成はＩＣカード内部で行うことが望ましいが、外部に秘密鍵が漏れなければよい。次に、Ｕｓｅｒ１は、作成した鍵ペアのうちＰＩＤ及び各ＵＩＤに対する公開鍵ＰＫをそれぞれＩＤＰ２に送信し、ＩＤＰ２に登録する（ステップＳ２０５）。

ＩＤＰ２は、Ｕｓｅｒ１に対して作成したＰＩＤ及びＵＩＤ並びにＵｓｅｒ１から受信した公開鍵ＰＫに対し、ＩＤＰ２の秘密鍵を用いて署名を行い、証明書ＰＫＣを作成する（ステップＳ２０６）。この証明書ＰＫＣには、与信範囲、有効期限などの情報を含んでいてもよい。次に、ＩＤＰ２に対してオフラインでサービスの享受が可能なシステムの場合、ＰＩＤ及び各ＵＩＤに対する証明書ＰＫＣをＵｓｅｒ１に送信し、ＩＣカード等の記録媒体に該証明書を記憶する（ステップＳ２０７）。

このＵＩＤは基本的に一取引につき一つずつ使うため、頻繁に再発行する必要がある。再発行手続は、ＩＤＰ２による認証の安全性及び通信路の安全性が保証されれば、オンラインで行うことが可能である。

［認証方法］
次に、Ｕｓｅｒ１がＳＰ３ｎに対してログインする際の認証方法について図８を参照して説明する。なお、Ｕｓｅｒ１がＩＤＰ２にログインする際及びＳＰ３ｎがＩＤＰ２にログインする際の認証については、Ｕｓｅｒ１がＳＰ３ｎに対してログインする手順と同様であるので、ここでは説明を省略する。なお、通信路については、ＳＳＬなどの暗号化が行われていて、盗聴されないものとする。

本実施の形態では認証方法としてＰＫＩ（Public Key Infrastructure）を用いる。具体的には、まず、Ｕｓｅｒ１はＳＰ３ｎに接続要求を行う（ステップＳ３０１）。次に、ＳＰ３ｎは、自身ＩＤであるＰＩＤｎをＵｓｅｒ１に送信する（ステップＳ３０２）。ここで、必要に応じて証明書ＰＫＣｎも送信する。Ｕｓｅｒ１は、前記ステップＳ３０２でＰＫＣｎを受け取っていない場合、ＩＤＰ２にＳＰＩＤｎの証明書を要求し（ステップＳ３０３）、ＩＤＰ２は、ＳＰＩＤｎの証明書ＰＫＣｎをＵｓｅｒ１に送信する（ステップＳ３０４）。

次に、Ｕｓｅｒ１は認証用の乱数Ｒを生成し、ＳＰ３ｎに送信する（ステップＳ３０５）。次に、ＳＰ３ｎは、自身の秘密鍵ＳＫｎを用いて乱数Ｒに署名を行い、署名付乱数ＳＫｎ（Ｒ）をＵｓｅｒ１に送信する（ステップＳ３０６）。

次に、Ｕｓｅｒ１はＳＰＩＤｎの証明書ＰＫＣｎからＳＰ３ｎの公開鍵ＰＫｎを取り出し、署名付乱数ＳＫｎ（Ｒ）から乱数Ｒを復号化し、自身が送信したＲと比較することにより認証を行う（ステップＳ３０７）。

このステップＳ３０７で認証が正しく行われたら、Ｕｓｅｒ１はＳＰ３ｎに対して用いる顧客ＩＤであるＵＩＤｍをＳＰ３ｎに送信する（ステップＳ３０８）。ここで、必要に応じて証明書ＰＫＣｍも送信する。ＳＰ３ｎは、前記ステップＳ３０８でＰＫＣｍを受け取っていない場合は、ＩＤの発行元にＵＩＤｍの証明書を要求する（ステップＳ３０９）。ここでは、ＩＤＰ２が発行元である場合について述べるが、ＳＰ３ｎが発行元である場合もある。

次に、ＩＤＰ２はＵＩＤｍの証明書ＰＫＣｍをＳＰ３ｎに送信する（ステップＳ３１０）。次に、ＳＰ３ｎは認証用の乱数Ｒを生成し、Ｕｓｅｒ１に送信する（ステップＳ３１１）。次に、Ｕｓｅｒ１は、ＵＩＤｍ用の秘密鍵ＳＫｍを用いて乱数Ｒに署名を行い、署名付乱数ＳＫｍ（Ｒ）をＳＰ３ｎに送信する（ステップＳ３１２）。次に、ＳＰ３ｎは、証明書ＰＫＣｍからＵＩＤｍの公開鍵ＰＫｍを取りだし、署名付乱数ＳＫｍ（Ｒ）からＲを取りだし、自身が送信したＲと比較することにより認証を行う（ステップＳ３１３）。

このような認証ステップを円滑に実施するために、各種ＩＤを記憶するＩＣカードにはＳＰＩＤに応じてどの顧客ＩＤ（ＵＩＤ）を用いるかを判別する機能を設けると好適である。これにより、Ｕｓｅｒ１がＳＰ３ｎに接続する際、どのＩＤを用いればよいかを意識する必要がなく、相手に応じて全て違う顧客ＩＤを使いながらも、Ｕｓｅｒ１はシングルサインオン感覚で利用できる。これは、通常のシングルサインオンで行われている１つのＩＤを使い回す方法と比較して、非常に安全である。但し、顧客ＩＤを自動認識するために、ＳＰ３が自分のＩＤを詐称した場合、Ｕｓｅｒ１の顧客ＩＤが盗まれる可能性があるが、上記のように相互認証を行うことにより防ぐことができる。

［与信者を利用した匿名サービスの享受］
次に、本発明を用いた各種匿名サービスの実施形態について図面を参照して説明する。ここでは、Ｕｓｅｒ１は、前述のＩＤＰ２に対する登録と同様の方法で、Ｄｅｌｉｖｅｒｙ４に対し登録し、与信（匿名の配送）を依頼しているものとする。このとき、物流であれば、住所・氏名などの情報を、メール配信であればｅ−ｍａｉｌアドレスなどをＤｅｌｉｖｅｒｙ４に対して公開する必要がある。また、同時に配送ＩＤとして複数のＤＩＤを受け取っておいてもよい。このとき、ＵＩＤと同様にＤＩＤに対しても認証用の鍵ペア（ユーザ側）及び証明書（Ｄｅｌｉｖｅｒｙ４側）を作成しておくことによって、配送の確認を認証により証明することが可能となる。

［匿名でオンラインショッピングを行う方法］
まず、匿名でオンラインショッピングを行う方法について図９を参照して説明する。

Ｕｓｅｒ１は、ＩＤＰ２発行又はＳＰ３発行のＵＩＤｎを用いてＳＰ３ｎにログインする（ステップＳ４０１）。このとき、どちらのＵＩＤを用いるかは、ユーザの判断によってもよいし、ＳＰ３から顧客ＩＤが発行されていれば、自動的にＳＰ３発行のＵＩＤを用いるようにしてもよい。

次に、ＳＰ３ｎは、登録作業の過程で与信情報の確認を行っていない場合や、高額取引を行うので改めて与信情報を確認したい場合などは、ＳＰ３ｎがＩＤＰ２に対して与信情報を要求する（ステップＳ４０２）。ＩＤＰ２は、前記ステップＳ４０２で与信情報が要求された場合、与信情報をＳＰ３ｎに送信する（ステップＳ４０３）。

次に、ＳＰ３ｎは、ユーザに要求されたサービス（商品の購入など）に対する請求を行う（ステップＳ４０４）。より具体的には、サービスに対する明細書をＵｓｅｒ１に提示し、金額のみが記載された請求書を送信して支払に同意するかどうかを確認する。なおここで、必要に応じて、明細書に対してＳＰ３ｎの秘密鍵を用いて電子署名を施してもよい。これにより、ＳＰ３ｎがユーザに提供するサービスが、明細書の内容であることをＳＰ３ｎ自身が証明することができる。

ここで、予め、Ｕｓｅｒ１がＤｅｌｉｖｅｒｙ４から配送用ＩＤとしてＤＩＤの発行を受けていない場合、又はＤＩＤを使い果たしてしまっている場合、Ｕｓｅｒ１はＤｅｌｉｖｅｒｙ４にログインし、配送用ＩＤとしてＤＩＤの発行を依頼する（ステップＳ４０５）。配送先がＤｅｌｉｖｅｒｙ４に登録している氏名・住所と異なる場合には、ＤＩＤ発行の際に配送先の氏名・住所を登録する。また、ＳＰ３ｎが取り扱うことのできるＤｅｌｉｖｅｒｙ４に登録がない場合、Ｕｓｅｒ１はこの時点でＤｅｌｉｖｅｒｙ４に対して登録手続を行い、配送用ＩＤの発行を依頼してもよい。Ｄｅｌｉｖｅｒｙ４は、前記ステップＳ４０５でＤＩＤの発行依頼があった場合、Ｕｓｅｒ１にＤＩＤを払い出す（ステップＳ４０６）。

次に、Ｕｓｅｒ１は、前記ステップＳ４０４で提示された明細書を確認の上、支払金額のみが記録された請求書に対してＵＩＤｎ用の秘密鍵ＳＫｎを用いて署名を行いＳＰ３ｎに送信する。また、配送先指定として、ＤＩＤｍの送信も行う。必要があれば署名入りＤＩＤｍの送信も行う（ステップＳ４０７）。なお、この署名つき請求書と、前記ステップＳ４０４における署名つき明細書とによってユーザ側の支払意思が証明されるので、両者間の契約が成立したものと考えられる。

次に、ＳＰ３ｎは、受け取った署名入り請求書を、ＵＩＤｎ用の公開鍵ＰＫｎを用いてデコードすることにより、請求書に対してきちんと署名が行われているかを確認する（ステップＳ４０８）。このとき、ＳＰ３ｎは、ＩＤＰ２を介することなしに確認を行うことができる。次に、ＳＰ３ｎは、明細書にＳＰ３ｎの秘密鍵で署名を行ったレシートを、支払に対する領収書として発行しＵｓｅｒ１に送信する。

ここでは、以上のステップののち決済処理についてのシーケンスを行うが（下記ステップＳ４０９，Ｓ４１０）、該決済処理に関しては、この一連のシーケンスの中で行う必要はない。

ＳＰ３ｎは、ＩＤＰ２にログインし、ＵＩＤｎ及び署名入りの請求書ＳＫｎ（金額）を送信する（ステップＳ４０９）。次に、ＩＤＰ２は、ＵＩＤｎ（必要があればＳＰＩＤｎも）からＰＩＤを特定し、どのＵｓｅｒ１に対する請求かを特定し、ＵＩＤｎに対して登録されている公開鍵ＰＫｎを用いて署名付請求書ＳＫｎ（金額）をデコードし、請求書にＵｓｅｒ１の署名が入っているかどうかを確認する（ステップＳ４１０）。確認後は金銭の移動手続を行い、結果をＳＰ３ｎに送信する。

このように処理することによって、ＳＰ３ｎは誰にサービスをしているかわからないが決済処理を行うことができる。ＩＤＰ２は、どのＵｓｅｒ１がＳＰ３ｎでいくら使ったかは分かるが、どんなサービスを受けたかは分からなく、また決済処理はサービス提供のタイミングで行われるとは限らないので、いつサービスを受けたかも隠蔽することもできる。

次に、ＳＰ３ｎは、前記ステップＳ４０８の署名確認を行った後、ＤＩＤｍの発行者であるＤｅｌｉｖｅｒｙ４ｍに配送を依頼する（ステップＳ４１１）。署名入りＤＩＤｍも受け取っていれば、ＤＩＤｍとともに送信する。次に、Ｄｅｌｉｖｅｒｙ４ｍは、ＤＩＤｍからＵｓｅｒ１を特定し、配送先を確認して、受取人に商品を届ける（ステップＳ４１２）。署名入りＤＩＤｍを受け取った場合は、例えば無断配送など利用目的以外の配送を防ぐために、署名の確認を行う。受取人がＵｓｅｒ１自身である場合は、受け取りの認印として、ＤＩＤｍの発行時に登録した鍵ペアの秘密鍵を用いて署名を行うといったことも可能である。

この署名を用いた認印を使い、Ｕｓｅｒ１が受け取ったことが確認された後、前記ステップＳ４１０で行われるＩＤＰ２による金銭の移動を行うことも可能である。この場合には、前記ステップＳ４０８においてＳＰ３ｎはＤＩＤｍも同時にＩＤＰ２に送信する。また、前記ステップＳ４１２において署名を用いた認印を受け取ったＤｅｌｉｖｅｒｙ４ｍは、配送ＩＤがＤＩＤｍである配送が終了したことをＩＤＰ２に通知する。そして、前記ステップＳ４１０において、ＩＤＰ２はＤｅｌｉｖｅｒｙ４ｍからの配送完了通知を受け取ったあと金銭の移動処理を行う。

以上のような処理により、例えばオークションの個人間取引において、支払を行ったのに商品を受け取れない、商品を送ったのに支払がされない、などのトラブルを解消することが可能である。

なお、ここではオンラインショッピングについて説明を行ったが、ＳＰ３やＤｅｌｉｖｅｒｙ４に対する顧客登録を行わないのであれば、ＩＣカードのような持ち運びができる媒体を用いていることにより実際の店舗における買い物に対しても適応可能である。また、通信傍受や端末の改変などに対応した相互認証を行っていれば、店舗に設置している端末を用いても顧客登録作業についても安全に行うことが可能である。

このような、匿名でオンラインショッピングを実施する場合、以下に示すようなトラブルが生じることが考えられる。しかし、与信者であるＩＤＰ２，Ｄｅｌｉｖｅｒｙ４と、当事者であるＵｓｅｒ１，ＳＰ３ｎが、それぞれＩＤ情報、取引内容などを出し合い、どちらに責任があるかを明らかにすることできる。以下に具体的なトラブル及び該トラブルに対する本発明の優位性について説明する。

（１）Ｕｓｅｒ１がＳＰ３ｎとの取引を否定した場合、ＳＰ３ｎには前記ステップＳ４０７でＵｓｅｒ１が行った請求書が残っているため、ＩＤＰ２が署名を検証することによってＵｓｅｒ１の否定が虚偽であることを確認することができる。ＳＰ３ｎがＵｓｅｒ１との取引がないのに請求をしようとしても、前記ステップＳ４０７でＵｓｅｒ１が行うはずの署名がないために、ＩＤＰ２における署名検証においてＳＰ３ｎによる不当請求であることを検出可能である。また、Ｕｓｅｒ１とは異なる第三者がＵｓｅｒ１のＳＰ３ｎ用のＵＩＤｎを入手して取引を行おうとしても、前記ステップＳ４０１の認証やステップＳ４０７の署名により不正を検知することが可能である。

一方、従来用いられていたクレジットカード番号を用いた決済の場合、クレジットカード番号のみによって取引が完了してしまうため、Ｕｓｅｒ１が「取引をしていない」と事実否認することが可能である。また、ＳＰ３ｎが不当にＵｓｅｒ１のクレジットカード番号を入手したり、Ｕｓｅｒ１とは異なる第三者がＵｓｅｒ１になりすましてクレジットカード番号を利用して、Ｕｓｅｒ１が関与していない取引の請求がなされてしまう恐れがある。

（２）前記ステップＳ４０８までの処理で売買契約が行われ、支払手続が完了したにもかかわらず、Ｕｓｅｒ１に届かなかった場合が考えられる。この場合、Ｕｓｅｒ１はＩＤＰ２に対して前記ステップＳ４０７で署名を行った証明書の決済の中断を依頼する。その際、配送先をしているＤＩＤｍもＩＤＰ２に送付する。ＩＤＰ２はステップＳ４０７の証明書からＳＰ３ｎを割り出し、ＳＰ３ｎに商品の配送状況を問い合わせる。ＳＰ３ｎが配送状況を回答しなかった場合決済を中断とする。一方、配送状況として「ＤＩＤｍを用いてＤｅｌｉｖｅｒｙ４に配送を依頼した」との回答があった場合、Ｕｓｅｒ１から送付されたＤＩＤｍと照合し、同一のものであれば引き続きＤｅｌｉｖｅｒｙ４に問い合わせを行い、同一のものでなかった場合は決済を中断する。次に、ＩＤＰ２はＤｅｌｉｖｅｒｙ４に問い合わせを行い、ＤＩＤｍの配送状況を調べ、ＳＰ３ｎから依頼が来ていない場合は決済中止を行い、配送中であれば配送を促し、配送済みであればＵｓｅｒ１の受け取とり署名を検証し、Ｕｓｅｒ１の依頼が虚偽であることを検証可能である。決済を中止した場合、Ｕｓｅｒ１にその旨を通知し、ＳＰ３ｎに警告・信用度を落とすなどの処理を行う。Ｕｓｅｒ１が虚偽の発言をしている場合、Ｕｓｅｒ１に警告・与信範囲縮小や取消などの処理を行う。

このように本発明では、オンラインショッピングで生じるで予測される「なりすまし」や業務不履行など種々のトラブルに対する処置が可能であるため、匿名性を有しながら安全性の高い取引を行うことが可能となる。

［ＳＰが匿名のまま顧客管理を行いＣＲＭを行う方法］
通常、ＳＰはカスタマー・リレーションシップ・マネジメント（ＣＲＭ）を行うために情報の収集を行っている。この収集方法としては、ポイントカードを発行するときに個人情報を登録させる方法などがある。ポイントカード発行には、もう一つの目的「顧客の囲い込みを行う」という目的もある。そこで、匿名のままＣＲＭに必要な情報を収集可能であり、顧客の囲い込みも可能な方法について図１０を参照して説明する。なお、ここでは前述した匿名によるオンラインショッピングが実施されている状況であるとする。

まず、Ｕｓｅｒ１は、ＳＰ３にログインする（ステップＳ５０１）。なお、このタイミングで前述したＵＩＤの発行・登録を行ってもよい。

次に、予め、Ｄｅｌｉｖｅｒｙ４から配送用ＩＤとしてＤＩＤの発行を受けていない場合、又はＤＩＤを使い果たしてしまっている場合、Ｕｓｅｒ１はＤｅｌｉｖｅｒｙ４にログインし、配送用ＩＤとしてＤＩＤの発行を依頼する（ステップＳ５０２）。また、ＳＰ３ｎが取り扱うことのできるＤｅｌｉｖｅｒｙ４に登録がない場合、Ｕｓｅｒ１はこの時点でＤｅｌｉｖｅｒｙ４に対して登録手続を行い、配送用ＩＤの発行を依頼してもよい。このＤＩＤには、ダイレクトメール（ＤＭ）であれば氏名・住所、ｅ−ｍａｉｌによる広告などであればＵｓｅｒ１のｅ−ｍａｉｌアドレスなどの情報を関連付ける。Ｄｅｌｉｖｅｒｙ４は、前記ステップＳ５０２においてＤＩＤの発行依頼があった場合、Ｕｓｅｒ１にＤＩＤを払い出し、ＤＩＤに配送用の情報（住所・氏名、ｅ−ｍａｉｌアドレスなど）を関連付ける（ステップＳ５０３）。

次に、Ｕｓｅｒ１は、ＳＰ３ｎに対し個人を特定しない範囲でＣＲＭを行うのに必要な情報（性別、居住地域、年齢、趣味、嗜好など）を登録する（ステップＳ５０４）。性別、居住地域、年齢、趣味、嗜好などの情報は与信者により証明してもらうことも可能である。同時に、配送先指定として、ＤＭや広告メールを受信するためのＤＩＤｍ及び利用目的・有効期限・利用者（ここではＳＰ３ｎ）などをＤＩＤｍに対して作成した秘密鍵ＳＫｎを用いて署名を行った許可証をＳＰ３ｎに送信する。なお、ＣＲＭを行うのに必要な個人情報を与信者により証明してもらう方法については後述する。

これにより、ＳＰ３は個人情報の提供の対価として、Ｕｓｅｒ１にサービスを提供したときにポイントサービスをするといった、従来からＳＰが行っているポイントサービスを行うことができ、それにより顧客の囲い込みも可能となる。また、ＳＰ３は必要があればＵｓｅｒ１に対価を払い上記のような与信者により証明を受けた情報を要求することもでき、より精度の高いＣＲＭを行うことが可能となる。

このようにして収集した個人情報と、ＳＰ３がＵｓｅｒ１に提供したサービスの履歴をもとにＣＲＭを行い、顧客のニーズに合った新製品情報などがあった場合にＤＭや広告メールを配信する方法について説明する。

ＳＰ３ｎは、Ｕｓｅｒ１に発送したい広告を作成し、ＤＭであれば封書に、広告メールであれば顧客のＵＩＤｎに対応した公開鍵ＰＫｎを用いて暗号化を行い、送付先であるＤＩＤｍ及び許可書、送付する目的などを添えてＤｅｌｉｖｅｒｙ４に送信する（ステップＳ５０５）。

次に、Ｄｅｌｉｖｅｒｙ４は、ＳＰ３ｎから受け取ったＤＩＤから公開鍵ＰＫｍを特定し、許可書をデコードし、利用条件（利用者、利用目的、有効期限など）が守られているかを確認し、ＤＭ又は広告メールをＵｓｅｒ１に送付する（ステップＳ５０６）。このとき、Ｄｅｌｉｖｅｒｙ４は、ＤＭが封書となっているため、また、広告メールは暗号化されているため内容を知ることができない。一方、Ｕｓｅｒ１は広告を受け取り、ＤＭであれば封書を開き、広告メールであればＤＩＤｍを提供しているＳＰ３ｎに対して登録してある鍵ペアの秘密鍵ＳＫｎを用いてデコードすることにより、内容を読むことができる。

なお、一連の流れと必ずしも連動する必要がないが、ＳＰ３ｎはＵｓｅｒ１から個人情報を受けた場合や、個人情報を利用した場合に、見返りとして対価を支払う必要がある（ステップＳ５０７）。対価としては、現金をＩＤＰ２経由で直接支払ったり、ＳＰ３ｎ独自のポイントを加算したりする。ＳＰ３ｎ独自のポイントの場合、又は複数のＳＰ３でポイントシステムを共有する場合は、ＩＤＰ２のＵｓｅｒ１の個人情報としてポイントを持たせ、ＳＰ３からの依頼によりポイントの増減を行うことも可能である。

以上、匿名でＣＲＭを行う方法について述べてきたが、その利点について説明する。

（ｉ）匿名で処理することによって、プライバシ侵害が起こりにくいため、ＳＰはこれまで以上に顧客情報の収集が可能になる（与信者による結託がなければプライバシ侵害は起こらない）。

（ｉｉ）ＳＰは収集したプライバシ情報を、安全に管理するのに非常に大きなコストがかかると考えられ、このようなプライバシ情報が流出した際、一度流出した情報は二度と消すことができないため非常に大きな問題になるが、匿名処理をすることによって、顧客ＩＤであるＵＩＤを発行しなおすことによって流出した情報を無力化することが可能である。

（ｉｉｉ）ＳＰが個人を特定可能なプライバシ情報（住所・氏名）を収集する目的は、ＤＭや広告メールを届けるということも含まれていると考えるが、匿名システムとして、個人を特定可能なプライバシ情報を入手しなくても、ＤＭや広告メールを届けることが可能となる。

［ＣＲＭサービスを行う会社がＣＲＭを行う方法］
上記では、ＳＰが顧客の購入履歴などを用いてＣＲＭを行う例を示したが、購入履歴などの情報はＳＰだけのものではなく、購入したＵｓｅｒ自身の情報でもある。このような履歴情報はＣＲＭを行う上で非常に価値のある情報なので、Ｕｓｅｒ自身が売り対価を受け取ることが可能である。ここでは、ＣＲＭを行いその結果を売り、その利益を、情報を提供してくれた顧客に還元する方法について図１１を参照して説明する。なお、ここでは前述した匿名によるオンラインショッピングが実施されている状況であるとする。

まず、Ｕｓｅｒ１は、ＣＲＭ５にログインする（ステップＳ６０１）。なお、このタイミングで前述した顧客登録を行ってもよい。登録の際には、Ｕｓｅｒ１はＣＲＭ５に対し個人を特定しない範囲でＣＲＭを行うのに必要な情報（性別、居住地域、年齢もしくは年齢層、趣味、嗜好など）を登録する。性別、居住地域、年齢もしくは年齢層、趣味、嗜好などの情報は、与信者により証明してもらうことも可能である。また、Ｕｓｅｒ１は自分が提供した情報の利用制約条件を設定したり、受け取るＤＭや広告メールの種類を指定したりしてもよい。匿名配送（Ｄｅｌｉｖｅｒｙ）を用いる場合は前述のステップＳ５０２及びＳ５０３の手続を行う。なお、ＣＲＭを行うのに必要な個人情報を与信者により証明してもらう方法については後述する。

次に、Ｕｓｅｒ１は、ＳＰ３からサービスを受けた場合に受け取るレシート（前記ステップＳ４０８参照）などを提示することにより、自分の購買履歴などのサービス履歴をＣＲＭ５に提供する（ステップＳ６０２）。ＣＲＭ会社は、複数のＵｓｅｒ１から提供された情報を蓄積し、これらの情報を用いたＣＲＭサービスをＳＰ３などに提供する。

次に、ＳＰ３は、自身が欲するＣＲＭの方法を指定し、ＣＲＭ５に対し処理を依頼する（ステップＳ６０３）。ＣＲＭ５は、ＳＰ３からの依頼に基づき、ＣＲＭを行う。このとき、Ｕｓｅｒ１が情報の利用制約条件がＳＰ３の提示する条件（支払われる対価など）と合うかどうかを判断してからＣＲＭに用いる。

次に、ＣＲＭ５は、上記のＣＲＭの結果をＳＰ３に送信する（ステップＳ６０４）。ＳＰ３は受け取ったＣＲＭの結果を基にして、販売戦略を練ったり、どの顧客に対してどのようなＤＭや広告メールを送ったらよいかを判断することができる。

次に、ＳＰ３は、ＣＲＭの結果に基づいてＤＭや広告メールを送りたいユーザ層を指定し、ＣＲＭ５に対して発送を依頼する（ステップＳ６０５）。ＣＲＭ５は、ＳＰ３から指定されたユーザ層の設定を確認し、ＤＭや広告メールを受け取ることを同意しているユーザに対して発送する（ステップＳ６０６）。匿名配送を用いる場合は、前記ステップＳ５０５及びＳ５０６の手続を行う。

次に、ＣＲＭ５はＩＤＰ２を通して、Ｕｓｅｒ１との契約に基づき、ＳＰ３から支払われた対価の支払いを行う（ステップＳ６０７）。

以上のような処理により、Ｕｓｅｒ１は自分の情報を提供したときだけではなく、その情報が利用されるたびに対価を受け取ることが可能で、しかも、一度提供した情報を、自分の意思により取り戻すことが可能となる。

［ＣＲＭサービスを行う会社がＣＲＭを行うがＣＲＭに履歴情報を蓄積しない方法］
上記のように、ＣＲＭサービス会社に履歴情報を蓄積してＣＲＭを行う場合、処理効率はよいが、履歴が大量に蓄積するためにユーザの行動パターンからある程度ユーザ特定が可能となり、匿名性が保てなくなってしまうおそれがある。そこで、ＣＲＭサービス会社に履歴情報を蓄積することなく、ＣＲＭを行う方法について図１２を参照して説明する。なお、ここでは前述した匿名によるオンラインショッピングが実施されている状況であるとする。

ここで、Ｕｓｅｒ１には、予めホームサーバなどに情報提供サーバ（図示省略）を設けておき、個人を特定しない範囲でＣＲＭを行うのに必要な情報（性別、居住地域、年齢もしくは年齢層、趣味、嗜好など）を登録しておく。性別、居住地域、年齢もしくは年齢層、趣味、嗜好などの情報は与信者による証明を受けておいてもよい。また、ＳＰ３などから受けたサービス履歴情報を前記情報提供サーバに蓄積しておく。Ｕｓｅｒ１は、すべての情報にそれぞれ利用制約条件を付けてもよい。さらに、情報提供サーバには、自身が契約するＣＲＭ５からのアクセスのみを受け付けるように設定しておく（ステップＳ７００）。

次に、Ｕｓｅｒ１はＣＲＭ５に顧客登録を行い、情報提供条件、受け取るＤＭや広告メールの種類を指定しておく。なお、匿名配送（Ｄｅｌｉｖｅｒｙ）を用いる場合は、前記ステップＳ５０２及びＳ５０３の手続を行っておく。

まず、ＳＰ３は、提供してもらう情報を暗号化するための公開鍵暗号方式の鍵ペアＰＫｍ，ＳＫｍを生成し、公開鍵ＰＫｍをＣＲＭ５に送信する（ステップＳ７０１）。また、情報提供に対する対価の条件（例えば「情報量として１０円支払う」など）及び情報を収集するための条件（例えば、「２０歳から３０歳までで関東圏に住んでいる人の過去１年間の履歴情報及び趣味」など）も送信する。

次に、ＣＲＭ５は、ユーザの登録条件とＳＰ３が提示する条件を照らし合わせ、条件に合うユーザに対し情報提供依頼を行い、ＳＰ３から受け取った公開鍵ＰＫｍをユーザの情報提供サーバに送信する（ステップＳ７０２）。

次に、Ｕｓｅｒ１の情報提供サーバは、ユーザが設定している条件に基づいて履歴情報などの提供情報を抽出し、ＳＰ３の公開鍵ＰＫｍで暗号化してＣＲＭ５に送り返す（ステップＳ７０３）。

次に、ＣＲＭ５は、それぞれの情報提供サーバから返信されたユーザの情報を、自身の管理する顧客ＩＤを隠蔽する形で情報ＩＤを付け、ＳＰ３に対して提供する（ステップＳ７０４）。ここで、受信した情報はＳＰ３の公開鍵ＰＫｍで暗号化されているため、ＣＲＭ５はユーザが提供した情報を見ることはできない。

次に、ＳＰ３は、ＣＲＭ５から受け取った情報を秘密鍵ＳＫｍを用いてデコードし、情報を得る（ステップＳ７０５）。ＳＰ３は、この情報を基にＣＲＭを行うことができる。ＤＭや広告メールを送りたい場合、ＳＰ３はＣＲＭ５に対し情報ＩＤを用いてユーザを指定して発送を依頼する。

ＣＲＭ５は、指定された情報ＩＤから顧客ＩＤを割り出し、ユーザがＤＭや広告メールの受信を許可している場合、発送を行う（ステップＳ７０６）。なお、匿名配送（Ｄｅｌｉｖｅｒｙ）をもちいる場合は、前記ステップＳ５０５及びＳ５０６の手続を行う。

次に、ＣＲＭ５は、ＩＤＰ２を介して、ＳＰ３から支払われた情報提供に対する対価の支払を行う（ステップＳ７０７）。

このような処理により、Ｕｓｅｒ１は情報サーバを構築しなければならないが、該サーバを構築することにより、個人の行動履歴を集約した形で他者に公開することなく、必要な情報を必要な場所だけに提示し、対価を得ることが可能となる。

［匿名での懸賞付アンケートサイトの実施方法］
インターネット上で懸賞の応募や、懸賞付アンケートを実施している場合、個人情報の収集が目的となっていることが多々あるが、懸賞を受け取るために多くのユーザはそれとは気付かずに個人情報を提示してしまっていると考えられる。そこで、匿名で懸賞付アンケートに応募し、匿名のまま懸賞を受け取る方法について図１３を参照して説明する。なお、ここではＵｓｅｒ１は前述した方法によりＵＩＤを取得しているものとする。

まず、Ｕｓｅｒ１は、懸賞付アンケートサイトであるＳＰ３にログインする（ステップＳ８０１）。なお、このタイミングで前述した顧客登録（ＵＩＤの発行・取得）を行ってもよい。

次に、ＳＰ３は、アンケートの内容及び懸賞の内容についてＵｓｅｒ１に通知する（ステップＳ８０２）。

次に、予め、Ｄｅｌｉｖｅｒｙ４から配送用ＩＤとしてＤＩＤの発行を受けていない場合、又はＤＩＤを使い果たしてしまっている場合、Ｕｓｅｒ１はＤｅｌｉｖｅｒｙ４にログインし、配送用ＩＤとしてＤＩＤの発行を依頼する（ステップＳ８０３）。また、ＳＰ３ｎが取り扱うことのできるＤｅｌｉｖｅｒｙ４に登録がない場合、Ｕｓｅｒ１はこの時点でＤｅｌｉｖｅｒｙ４に対して登録手続を行い、配送容ＩＤの発行を依頼してもよい。このＤＩＤには、氏名・住所などの情報を関連付ける。Ｄｅｌｉｖｅｒｙ４は、前記ステップＳ８０３において発行依頼があった場合、Ｕｓｅｒ１にＤＩＤを払い出し、ＤＩＤに発送用の情報（住所・氏名など）を関連付ける（ステップＳ８０４）。

次に、Ｕｓｅｒ１は、個人を特定しない範囲で必要な個人情報（性別、居住地域、年齢もしくは年齢層、趣味、嗜好など）を含んだ形でアンケートに答え、その結果をＳＰ３に送信する（ステップＳ８０５）。性別、居住地域、年齢もしくは年齢層、趣味、嗜好などの情報は与信者により証明してもらうことも可能である。同時に、懸賞の配布先指定として、ＤＩＤ及び利用目的（懸賞の送付）・有効期限（重複利用を防ぐため）・利用者（ここではＳＰ３ｎ）などをＤＩＤに対して作成した秘密鍵ＳＫｎを用いて署名を行った許可書をＳＰ３ｎに送信する。

次に、ＳＰ３ｎは、懸賞品の送付依頼を、送付先であるＤＩＤ及び許可書、送付する目的などを添えてＤｅｌｉｖｅｒｙ４に送信する（ステップＳ８０６）。

次に、Ｄｅｌｉｖｅｒｙ４は、ＳＰ３ｎから受け取ったＤＩＤｍから公開鍵ＰＫｍを特定し、許可書をデコードし、利用条件（利用者、利用目的、有効期限など）が守られているかを確認し、依頼物をＵｓｅｒ１に送付する（ステップＳ８０７）。このとき、依頼物は梱包されているのでＤｅｌｉｖｅｒｙ４は内容を知ることができない。

なお、懸賞品として金銭やポイントを支払う場合、前記ステップＳ８０６においてＩＤＰ２経由で金銭を支払ったりポイントを加算したりすればよい（図のステップＳ８０６’）。

このようにして、Ｕｓｅｒ１は匿名で懸賞を受け取ることができ、ＳＰ３は個人を特定できないが、ＣＲＭを行うには十分な個人情報を入手することができ、個人情報流出の問題についても、流出した情報のみでは個人を特定することができないので、売買される心配もない。

上記の各実施の形態において、一の利用者（上記実施の形態では例えばＵｓｅｒ１）が他の利用者（上記実施の形態では例えばＳＰ３）に情報を提供する場合、当該情報の正当性をサービス提供者（上記実施の形態では例えばＩＤＰ２やＣＲＭ５）が保証すると好適である。具体的には、上述の［ＳＰが匿名のまま顧客管理を行いＣＲＭを行う方法］においてＵｓｅｒ１がＳＰ３ｎに対して個人情報を送信する場合（ステップＳ５０４）や、上述の［ＣＲＭサービスを行う会社がＣＲＭを行う方法］においてＵｓｅｒ１がＣＲＭ５に個人情報を送信する場合（ステップＳ６０１）などが挙げられる。なお、このようなサービス提供者による情報正当性の保証サービスをここでは情報与信と呼ぶことにする。

以下に、図１４を参照して情報与信の概要について説明する。図１４は情報与信の流れを説明する図である。なお、情報与信における個人情報提供方法の具体的方法については後述する。

ここでは、図１４に例示するように、Ｕｓｅｒ１がＳＰ３に対して個人情報を送信する場合について考える。Ｕｓｅｒ１が利用者であるＳＰ３に提供する個人情報の正当性は、直接は与信者としてのＣＲＭ５が証明する。ＣＲＭ５では、個人情報の正当性を証明するために、ＩＤＰ２による情報与信サービスを用いる。従って、ＣＲＭ５はＳＰ３にとっては上位の与信者となり、ＩＤＰ２はＣＲＭ５にとっては上位の与信者となる。換言すれば、ＣＲＭ５は与信者且つ利用者となる。

まず、Ｕｓｅｒ１は、予めＩＤＰ２に対して個人情報を提供しておく（ステップＳ９０１）。例えば、個人情報としては、氏名、住所、性別、生年月日、勤務先、年収などが挙げられる。

次に、ＩＤＰ２は、Ｕｓｅｒ１から提供された個人情報を所定の記憶装置に記憶するとともに個人情報の正当性を確認する（ステップＳ９０２）。ここで正当性の確認は、例えば銀行による口座開設の際やクレジットカード会社によるカード作成の際などにおけるユーザの本人確認方法と同様に行う。例えば、郵便物の到達性や、勤務先への電話確認や、公的証明書による課税証明などが挙げられる。これによりＩＤＰ２は、正確な個人情報を入手する。

次に、ＩＤＰ２は、必要に応じて、個人情報の一部を欠落させる処理（縮退）を行う（ステップＳ９０３）。例えば、住所を都道府県名や市区町村名までに縮退したり、生年月日を年齢や年齢層という情報に縮退したり、勤務先を職種という情報に縮退したり、年収を何百万円台という情報に縮退することなどが考えられる。ＩＤＰ２は縮退した個人情報を所定の記憶手段に記憶・管理する。

以上のような環境において、与信者であるＩＤＰ２はＵｓｅｒ１に対して、「ＩＤＰ２が確認しているＵｓｅｒ１の情報が正しいこと」を証明する情報与信サービスが提供可能となる（ステップＳ９０４）。具体的には、Ｕｓｅｒ１は、ＣＲＭ５に対して後述する各方法により個人情報を提供し（ステップＳ９０５）、ＩＤＰ２はＣＲＭ５に対して「Ｕｓｅｒ１がＣＲＭ５に対して提供した個人情報」の正当性を証明する（ステップＳ９０６）。

同様にして、与信者であるＣＲＭ５はＵｓｅｒ１に対して、「ＣＲＭ５が確認しているＵｓｅｒ１の情報が正しいこと」を証明する情報与信サービスが提供可能となる（ステップＳ９０７）。具体的には、Ｕｓｅｒ１は、ＳＰ３に対して後述する各方法により個人情報を提供し（ステップＳ９０８）、ＣＲＭ５はＳＰ３に対して「Ｕｓｅｒ１がＳＰ３に対して提供した個人情報」の正当性を証明する（ステップＳ９０６）。ここで、ＣＲＭ５は、個人情報の正当性を証明するために、ＩＤＰ２による情報与信を利用している点に留意されたい。すなわち、与信者は上位の与信者に情報与信をしてもらうことにより、前述したようなユーザの本人確認等を行う必要がない。

次に、前記ステップＳ９０５，Ｓ９０８の個人情報提供の具体的手法について図１５〜図１７を参照して説明する。この個人情報提供は、第１の利用者が第２の利用者に送信したい個人情報に対して与信者が電子署名を付する方法と、第１の利用者が第２の利用者に送信したい個人情報を与信者が提供する方法に大別される。さらに、後者の方法は、第１の利用者が与信者に対して、第２の利用者からの個人情報へのアクセス権を設定する方法と、第１の利用者が第２の利用者に対して、与信者からの情報取得を許可する権利を付与する方法とに別れる。以下、３つの方法についてそれぞれ詳述する。

まず、第１の方法について図１５を参照して説明する。ここでは、Ｕｓｅｒ１が利用者１５に対して個人情報を提供する際に当該個人情報の正当性を与信者２５が電子署名により証明する場合について説明する。なお、（与信者２５，利用者１５）の組み合わせは、図１４の例では、（ＩＤＰ２，ＣＲＭ５）や（ＣＲＭ５，ＳＰ３）に相当する。

図１５に示すように、Ｕｓｅｒ１は、与信者２５に書類発行依頼を行う（ステップＳ１００１）。具体的には、まず、Ｕｓｅｒ１の与信者用ＩＤ（与信者２５がＩＤＰ２であればＰＩＤ）を用いて与信者２５にログインする。次いで、Ｕｓｅｒ１は、与信者２５に書類発行依頼を行う。この書類発行依頼には、Ｕｓｅｒ１が利用者１５で既に利用しているＩＤ又は利用者１５でこれから利用しようとしているＩＤ（以下これらのＩＤをＩＤｘと呼ぶ）と、利用者１５に対して提供する個人情報であって与信者２５による与信を希望するもの（例えば居住地域であれば「東京都」など）、という情報が含まれる。

次に、与信者２５は、Ｕｓｅｒ１から受信した書類発行依頼について確認処理を行う（ステップＳ１００２）。具体的には、書類発行依頼に含まれるＩＤｘの正当性、及び、個人情報の正当性を確認する。ＩＤｘの正当性は、当該ＩＤｘが利用者１５で既に利用しているＩＤの場合、該利用者１５用のＩＤであるかどうかを判定し、当該ＩＤｘが利用者でこれから利用しようとしているＩＤの場合、与信者２５がＵｓｅｒ１に対して払い出したＩＤかどうかを判定する。また、個人情報の正当性は、与信者２５が自ら個人情報の正当性を確認しているかを判定し、又は、上位の与信者から与信された個人情報であるかを判定する。

次に、与信者２５は、Ｕｓｅｒ１に対して書類を発行する（ステップＳ１００３）。具体的には、前記ＩＤｘ及び個人情報を含む書類に対して与信者２５の秘密鍵を用いて電子署名を施し、この電子署名つき書類をＵｓｅｒ１に送信する。なお、ここで書類に含まれる情報は、必要に応じて縮退されたものである。

次に、Ｕｓｅｒ１は、利用者１５に対して与信済情報を提供する（ステップＳ１００４）。具体的には、前記ＩＤｘを用いて利用者１５にログインし、次いで前記ステップＳ１００３で与信者２５から受信した電子署名つき書類を利用者１５に送信する。

最後に、利用者１５は、利用者１５から受信した与信済情報を確認する（ステップＳ１００５）。具体的には、与信者２５の公開鍵を用いてＵｓｅｒ１から受信した書類の電子署名を検証し、書類に含まれるＩＤがＵｓｅｒ１のＩＤであるＩＤｘであることを確認する。これにより、利用者１５は、電子署名つき書類に含まれる個人情報が与信者２５により正当なものであると証明されていること、すなわち該個人情報が与信者２５により与信済みであるということを確認できる。なお、与信者２５の公開鍵は、予め又は署名検証時など適宜、与信者２５から入手しておけばよい（ステップＳ１０００）。

次に、第２の方法について図１６を参照して説明する。ここでは、Ｕｓｅｒ１が利用者１５に対して個人情報を提供する際に、Ｕｓｅｒ１により設定されたアクセス権に基づき与信者２５が当該個人情報のアクセス制御を行う場合について説明する。なお、（与信者２５，利用者１５）の組み合わせは、図１４の例では、（ＩＤＰ２，ＣＲＭ５）や（ＣＲＭ５，ＳＰ３）に相当する。

図１６に示すように、Ｕｓｅｒ１は、与信者２５に対してアクセス権の設定を行う（ステップＳ１１０１）。具体的には、まず、Ｕｓｅｒ１の与信者用ＩＤ（与信者２５がＩＤＰ２であればＰＩＤ）を用いて与信者２５にログインする。次いで、Ｕｓｅｒ１は、与信者２５に対してアクセス権の設定を行うために、Ｕｓｅｒ１が利用者１５で既に利用しているＩＤ又は利用者１５でこれから利用しようとしているＩＤであるＩＤｘと、個人情報の提供先である利用者１５のＩＤ（以下ＩＤｓと記す）と、利用者１５に対して提供する個人情報であって与信者２５による与信を希望する情報の種別（例えば「居住地域」など）、という情報を与信者２５に送信する。

次に、与信者２５は、Ｕｓｅｒ１から受信した各情報の確認処理を行う（ステップＳ１１０２）。具体的には、ＩＤｘ及びＩＤｓの正当性、並びに、個人情報の正当性を確認する。ＩＤｘの正当性は、当該ＩＤｘが利用者１５で利用しているかどうかを判定し、ＩＤｓの正当性は、当該ＩＤｓが与信者２５に登録されているどうかを判定する。また、個人情報の正当性は、与信者２５が自ら個人情報の正当性を確認しているかを判定し、又は、上位の与信者から与信された個人情報であるかを判定する。与信者２５は、Ｕｓｅｒ１から受信した各情報に基づき個人情報へのアクセス権（開示又は非開示）を設定する。

次に、利用者１５は、与信者２５からＵｓｅｒ１の個人情報を取得する（ステップＳ１１０３）。具体的には、利用者１５が、利用者１５の与信者用ＩＤ（与信者２５がＩＤＰ２であればＰＩＤ）を用いて与信者２５にログインする。次いで、利用者１５は、与信者２５に対して、Ｕｓｅｒ１のＩＤであるＩＤｘを提示してＵｓｅｒ１の個人情報の取得を要求する。

与信者２５は、前記ステップＳ１１０１でＵｓｅｒ１から受信したアクセス権に関する情報に基づき、利用者１５からのアクセスに対してアクセス制御を行う（ステップＳ１１０４）。具体的には、利用者１５から提示されたＩＤｘの個人情報を検索し、該ＩＤｘについてのアクセス制御情報を取得し、利用者１５から要求された個人情報のＩＤｓに対するアクセス権（開示又は非開示）を参照する。次いで、与信者２５は、与信済情報を要求元の利用者１５に提供する（ステップＳ１１０５）。すなわち、与信者２５はＵｓｅｒ１の個人情報を利用者１５に送信するが、この個人情報は与信者２５により正当性が証明された情報であり、しかもＵｓｅｒ１から直接受信したものではなく与信者２５から受信した情報であるため（Ｕｓｅｒ１からの直接受信だと虚偽の情報を受信する可能性がある）、利用者１５は当該個人情報を与信済み情報として取り扱うことができる。なお、ここで利用者１５に送信する個人情報は、必要に応じて縮退されたものである。

次に、第３の方法について図１７を参照して説明する。ここでは、Ｕｓｅｒ１が利用者１５に対して個人情報を提供する際に、Ｕｓｅｒ１が利用者１５に付与した情報取得権に基づき、与信者２５が当該個人情報のアクセス制御を行う場合について説明する。なお、（与信者２５，利用者１５）の組み合わせは、図１４の例では、（ＩＤＰ２，ＣＲＭ５）や（ＣＲＭ５，ＳＰ３）に相当する。

図１７に示すように、Ｕｓｅｒ１は、利用者１５に対して情報取得権を発行する（ステップＳ１２０１）。この情報取得権は、Ｕｓｅｒ１が利用者１５で利用しているＩＤであるＩＤｘと、利用者１５のＩＤであるＩＤｓと、利用者１５に対して提供する個人情報であって与信者２５による与信を希望する情報の種別（例えば「居住地域」など）、という情報に対して、ＩＤｘ用の秘密鍵を用いて電子署名を施したものである。

次に、Ｕｓｅｒ１は、利用者１５に対して情報取得権を送信する（ステップＳ１２０２）。具体的には、Ｕｓｅｒ１は、Ｕｓｅｒ１のＩＤであるＩＤｘを用いて利用者１５にログインし、前記ステップＳ１２０１で生成した電子署名つき情報取得権を利用者１５に送信する。

次に、利用者１５は、Ｕｓｅｒ１から受信した情報取得権の確認処理を行う（ステップＳ１２０３）。具体的には、情報取得権に含まれるＩＤｘの公開鍵を用いて情報取得権に付された電子署名を検証する。次いで、利用者１５は、ＩＤｘの個人情報取得を試みる（ステップＳ１２０４）。具体的には、利用者１５は、利用者１５の与信者用ＩＤ（与信者２５がＩＤＰ２であればＰＩＤ）を用いて与信者２５にログインする。次いで、利用者１５は、Ｕｓｅｒ１から受信した電子署名つき情報取得権を与信者２５に送信する。

与信者２５は、利用者１５から受信した情報取得権の確認処理を行う（ステップＳ１２０４）。具体的には、情報取得権に含まれるＩＤｘ及びＩＤｓの正当性、情報取得権に付された電子署名の正当性、並びに、個人情報の正当性を確認する。ＩＤｘの正当性は、当該ＩＤｘが利用者１５で利用しているかどうかを判定し、ＩＤｓの正当性は、当該ＩＤｓが利用者１５のＩＤとして与信者２５に登録されているどうかを判定する。また、個人情報の正当性は、与信者２５が自ら個人情報の正当性を確認しているかを判定し、又は、上位の与信者から与信された個人情報であるかを判定する。そして、与信者２５は、与信済情報を要求元の利用者１５に提供する（ステップＳ１２０６）。すなわち、与信者２５はＵｓｅｒ１の個人情報を利用者１５に送信するが、この個人情報は与信者２５により正当性が証明された情報であり、しかもＵｓｅｒ１から直接受信したものではなく与信者２５から受信した情報であるため（Ｕｓｅｒ１からの直接受信だと虚偽の情報を受信する可能性がある）、利用者１５は当該個人情報を与信済み情報として取り扱うことができる。なお、ここで利用者１５に送信する個人情報は、必要に応じて縮退されたものである。

以上詳述したように、本発明によれば、利用者は各種サービスを匿名で教示することができるのでプライバシ保護に優れたものとなる。また、利用者は、各種サービスを実施する者及び通信相手先の利用者に対して、必要最小限の個人情報のみ提示すればよいので、個人情報が特定の者に集中することがない。これにより、流出した個人情報から利用者個人を特定することが困難になるので、取引等の安全性が向上する。また、個人情報が流出した場合であっても、各ユーザＩＤの振り直しを行うことにより、流出情報を無効化することができる。

以上、本発明の実施形態について詳述したが本発明はこれに限定されるものではない。例えば、上記実施形態では、与信者（サービス提供者）として、決済業務を行うもの、配送業務を行うもの、ＣＲＭを行う者を例示したが、他のサービスであっても本発明を適用できることは言うまでもない。

本発明の基本原理を説明する図 本発明の基本原理の他の態様を説明する図 本発明の基本原理の他の態様を説明する図 本発明の基本原理の他の態様を説明する図 本発明の基本原理の他の態様を説明する図 ＳＰがＵＩＤを発行する流れを説明する図 ＩＤＰがＵＩＤを発行する流れを説明する図 ＰＫＩによる認証の流れ説明する図 オンラインショッピングの流れを説明する図 ＳＰがＣＲＭを行う流れを説明する図 ＣＲＭサービス会社がＣＲＭを行う流れを説明する図 他の例に係るＣＲＭサービス会社がＣＲＭを行う流れを説明する図 懸賞付アンケートを行う流れを説明する図 情報与信サービスの概要を説明する図 個人情報提供方法の流れを説明する図 他の例に掛かる個人情報提供方法の流れを説明する図 他の例に掛かる個人情報提供方法の流れを説明する図

符号の説明

１…Ｕｓｅｒ（商品の購買などを行う顧客（利用者）の端末）、２…ＩＤＰ（課金決済系に関する与信者（サービス提供者）の端末）、３…ＳＰ（オンラインショップや実際の店舗など顧客にサービスや商品を提供する者（利用者）の端末）、４…Ｄｅｌｉｖｅｒｙ配送に関する与信者（サービス提供者）の端末、５…ＣＲＭ（ＣＲＭサービスを行う与信者（サービス提供者）の端末）

Claims (15)

1. ネットワークを介して複数の利用者の間でなされる利用者間通信において、
   利用者に対してサービスの提供を行うサービス提供者の端末が、サービス利用者に対してユーザＩＤを生成・発行するとともに該ユーザＩＤの正当性を証明する証明書を生成するステップと、サービスの提供に必要なサービス利用者の個人情報を前記ユーザＩＤと関連付けて所定の記憶手段に記憶するステップと、
   前記利用者間通信において一の利用者の端末が、他の利用者を指定して前記サービス提供者によるサービスを利用する際に前記他の利用者の端末からユーザＩＤを取得するステップと、サービス提供者の端末から直接又は前記他の利用者の端末を介して前記ユーザＩＤの証明書を取得するステップと、該証明書により前記ユーザＩＤの正当性を検証するステップと、該ユーザＩＤをサービス提供者の端末に提示するステップと、
   サービス提供者の端末が、前記一の利用者の端末が提示したユーザＩＤに関連付けられた個人情報を前記記憶手段から抽出するステップと、サービス提供者が該個人情報に基づきサービス提供を行うステップとを含む
   ことを特徴とするサービス提供方法。
2. ネットワークを介して複数の利用者の間でなされる利用者間通信において、
   一の利用者の端末が、他の利用者に対してユーザＩＤ及び該ユーザＩＤの正当性を証明する証明書を生成・発行するステップと、
   サービス提供者の端末が、前記他の利用者の端末から受信したユーザＩＤ及び証明書とサービスの提供に必要なサービス利用者の個人情報とを関連付けて所定の記憶手段に記憶するステップと、
   前記利用者間通信において一の利用者の端末が、他の利用者を指定して前記サービス提供者によるサービスを利用する際に前記他の利用者の端末からユーザＩＤを取得するステップと、サービス提供者の端末から直接又は前記他の利用者の端末を介して前記ユーザＩＤの証明書を取得するステップと、該証明書により前記ユーザＩＤの正当性を検証するステップと、該ユーザＩＤをサービス提供者の端末に提示するステップと、
   サービス提供者の端末が、前記一の利用者の端末が提示したユーザＩＤに関連付けられた個人情報を前記記憶手段から抽出するステップと、サービス提供者が該個人情報に基づきサービス提供を行うステップとを含む
   ことを特徴とするサービス提供方法。
3. 前記一の利用者の端末は複数のサービス提供者のサービスを利用する
   ことを特徴とする請求項１又は２何れか１項記載のサービス提供方法。
4. 前記証明書の生成ステップでは、利用者の端末から取得した該利用者の公開鍵と該利用者のユーザＩＤの組を含む情報に対して電子署名を施すことにより証明書を生成する
   ことを特徴とする請求項１又は２何れか１項記載のサービス提供方法。
5. 前記利用者間通信には利用者間での契約事項に関する情報に対して少なくとも一方の利用者により付せられた電子署名が含まれる
   ことを特徴とする請求項１又は２何れか１項記載のサービス提供方法。
6. 前記サービス提供者の利用を含む一連の利用者間通信を実施した後における同じ利用者間の通信では、先の利用者間通信においてサービス提供者の端末から取得した証明書を用いることにより、サービス提供者の端末を介することなくユーザＩＤの正当性の検証を行う
   ことを特徴とする請求項１又は２何れか１項記載のサービス提供方法。
7. 一の利用者が発行を受けるユーザＩＤは、一の利用者の通信相手先となる複数の他の利用者に応じて又は利用者間通信に応じて互いに異なる
   ことを特徴とする請求項１又は２何れか１項記載のサービス提供方法。
8. 前記サービス提供者の端末は、利用者の個人情報が流出した際には、利用者に対して発行したユーザＩＤを破棄するとともに新たなユーザＩＤ及び証明書を生成し、破棄したユーザＩＤと関連付けられていた利用者の個人情報を新たなユーザＩＤに関連付ける
   ことを特徴とする請求項１又は２何れか１項記載のサービス提供方法。
9. サービス提供者の端末が、前記他の利用者の端末からの要求に応じて、前記記憶手段に記憶されている該他の利用者についての個人情報に対して電子署名を付するとともに該電子署名付き個人情報を要求元の利用者の端末に送信するステップと、
   該他の利用者の端末が、サービス提供者の端末から受信した電子署名付き個人情報を通信相手先である前記一の利用者の端末に送信するステップとを備えた
   ことを特徴とする請求項１又は２何れか１項記載のサービス提供方法。
10. サービス提供者の端末が、前記他の利用者の端末からの要求に応じて、該他の利用者の端末との通信相手先である前記一の利用者の端末にのみ、前記記憶手段に記憶されている該他の利用者についての個人情報を提供するステップを備えた
    ことを特徴とする請求項１又は２何れか１項記載のサービス提供方法。
11. 前記他の利用者の端末が、サービス提供者の端末に対して、少なくとも該他の利用者の端末との通信相手先である前記一の利用者の端末のユーザＩＤを送信するステップと、
    サービス提供者の端末が、前記他の利用者の端末から受信したユーザＩＤに基づき利用者の端末からの前記個人情報へのアクセスを制御するステップとを備えた
    ことを特徴とする請求項１０記載のサービス提供方法。
12. 前記他の利用者の端末が、該他の利用者の端末との通信相手先である前記一の利用者の端末に対して、少なくとも自身のユーザＩＤ及び該一の利用者のユーザＩＤを含む情報取得権に電子署名を付して送信するステップと、
    該一の利用者の端末が、前記他の利用者の端末から受信した情報取得権をサービス提供者の端末に送信するステップと、
    サービス提供者の端末が、前記一の利用者の端末から受信した電子署名付き情報取得権に基づき該一の利用者の端末へ前記個人情報を提供するステップとを備えた
    ことを特徴とする請求項１０記載のサービス提供方法。
13. サービス提供者の端末は、個人情報の一部を欠落させてから該個人情報を利用者の端末に提供する
    ことを特徴とする請求項９又は１０何れか１項記載のサービス提供方法。
14. ネットワークを介して複数の利用者の間でなされる利用者間通信において、
    サービス利用者に対してユーザＩＤを生成・発行するとともに該ユーザＩＤの正当性を証明する証明書を生成する手段と、サービスの提供に必要なサービス利用者の個人情報を前記ユーザＩＤと関連付けて所定の記憶手段に記憶しておく手段と、利用者の端末が提示したユーザＩＤに関連付けられた個人情報を抽出する手段とを備えた利用者に対してサービスの提供を行うサービス提供者の端末を有し、
    前記利用者間通信において一の利用者の端末は、他の利用者を指定して前記サービス提供者によるサービスを利用する際に、前記他の利用者の端末からユーザＩＤを取得する手段と、サービス提供者の端末から直接又は前記他の利用者の端末を介して前記ユーザＩＤの証明書を取得する手段と、該証明書により前記ユーザＩＤの正当性を検証する手段と、該ユーザＩＤをサービス提供者の端末に提示する手段とを備えた
    ことを特徴とするサービス提供システム。
15. ネットワークを介して複数の利用者の間でなされる利用者間通信において、
    利用者の端末からのユーザＩＤ及び証明書の登録要求に応じて当該ユーザＩＤ及び該ユーザＩＤの正当性を証明する証明書を該利用者へのサービス提供に必要な個人情報と関連付けて所定の記憶手段に記憶する手段と、利用者の端末が提示したユーザＩＤに関連付けられた個人情報を抽出する手段とを備えた利用者に対してサービスの提供を行うサービス提供者の端末を有し
    利用者間通信において一の利用者の端末は、他の利用者に対してユーザＩＤ及び証明書を生成・発行するとともに該ユーザＩＤ及び証明書を他の利用者の端末に送信する手段と、他の利用者を指定して前記サービス提供者によるサービスを利用する際に、前記他の利用者の端末からユーザＩＤを取得する手段と、サービス提供者の端末から直接又は前記他の利用者の端末を介して前記ユーザＩＤの証明書を取得する手段と、該証明書により前記ユーザＩＤの正当性を検証する手段と、該ユーザＩＤをサービス提供者の端末に提示する手段とを備え、
    前記他の利用者の端末は、前記一の利用者の端末で発行されたユーザＩＤ及び証明書を前記サービス提供者の端末に登録する手段とを備えた
    ことを特徴とするサービス提供システム。
    

Images