(57)【要約】【課題】  利用者の匿名性を高めることができるサービス提供方法及びシステムを提供する。【解決手段】  サービス提供者の端末が、サービス利用者に対してユーザＩＤを生成・発行するとともに該ユーザＩＤの正当性を証明する証明書を生成し、サービスの提供に必要なサービス利用者の個人情報を前記ユーザＩＤと関連付けて記憶し、一の利用者の端末が他の利用者を指定して前記サービス提供者によるサービスを利用する際にユーザＩＤ及び証明書を取得し、該証明書により前記ユーザＩＤの正当性を検証してサービス提供者の端末に提示し、サービス提供者が該ユーザＩＤに関連付けられた個人情報基づきサービス提供を行う。【選択図】  図６
2005050330.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを介して複数の利用者の間でなされる利用者間通信において、
利用者に対してサービスの提供を行うサービス提供者の端末が、サービス利用者に対してユーザＩＤを生成・発行するとともに該ユーザＩＤの正当性を証明する証明書を生成するステップと、サービスの提供に必要なサービス利用者の個人情報を前記ユーザＩＤと関連付けて所定の記憶手段に記憶するステップと、
前記利用者間通信において一の利用者の端末が、他の利用者を指定して前記サービス提供者によるサービスを利用する際に前記他の利用者の端末からユーザＩＤを取得するステップと、サービス提供者の端末から直接又は前記他の利用者の端末を介して前記ユーザＩＤの証明書を取得するステップと、該証明書により前記ユーザＩＤの正当性を検証するステップと、該ユーザＩＤをサービス提供者の端末に提示するステップと、
サービス提供者の端末が、前記一の利用者の端末が提示したユーザＩＤに関連付けられた個人情報を前記記憶手段から抽出するステップと、サービス提供者が該個人情報に基づきサービス提供を行うステップとを含む
ことを特徴とするサービス提供方法。
【請求項２】
ネットワークを介して複数の利用者の間でなされる利用者間通信において、
一の利用者の端末が、他の利用者に対してユーザＩＤ及び該ユーザＩＤの正当性を証明する証明書を生成・発行するステップと、
サービス提供者の端末が、前記他の利用者の端末から受信したユーザＩＤ及び証明書とサービスの提供に必要なサービス利用者の個人情報とを関連付けて所定の記憶手段に記憶するステップと、
前記利用者間通信において一の利用者の端末が、他の利用者を指定して前記サービス提供者によるサービスを利用する際に前記他の利用者の端末からユーザＩＤを取得するステップと、サービス提供者の端末から直接又は前記他の利用者の端末を介して前記ユーザＩＤの証明書を取得するステップと、該証明書により前記ユーザＩＤの正当性を検証するステップと、該ユーザＩＤをサービス提供者の端末に提示するステップと、
サービス提供者の端末が、前記一の利用者の端末が提示したユーザＩＤに関連付けられた個人情報を前記記憶手段から抽出するステップと、サービス提供者が該個人情報に基づきサービス提供を行うステップとを含む
ことを特徴とするサービス提供方法。
【請求項３】
前記一の利用者の端末は複数のサービス提供者のサービスを利用する
ことを特徴とする請求項１又は２何れか１項記載のサービス提供方法。
【請求項４】
前記証明書の生成ステップでは、利用者の端末から取得した該利用者の公開鍵と該利用者のユーザＩＤの組を含む情報に対して電子署名を施すことにより証明書を生成する
ことを特徴とする請求項１又は２何れか１項記載のサービス提供方法。
【請求項５】
前記利用者間通信には利用者間での契約事項に関する情報に対して少なくとも一方の利用者により付せられた電子署名が含まれる
ことを特徴とする請求項１又は２何れか１項記載のサービス提供方法。
【請求項６】
前記サービス提供者の利用を含む一連の利用者間通信を実施した後における同じ利用者間の通信では、先の利用者間通信においてサービス提供者の端末から取得した証明書を用いることにより、サービス提供者の端末を介することなくユーザＩＤの正当性の検証を行う
ことを特徴とする請求項１又は２何れか１項記載のサービス提供方法。
【請求項７】
一の利用者が発行を受けるユーザＩＤは、一の利用者の通信相手先となる複数の他の利用者に応じて又は利用者間通信に応じて互いに異なる
ことを特徴とする請求項１又は２何れか１項記載のサービス提供方法。
【請求項８】
前記サービス提供者の端末は、利用者の個人情報が流出した際には、利用者に対して発行したユーザＩＤを破棄するとともに新たなユーザＩＤ及び証明書を生成し、破棄したユーザＩＤと関連付けられていた利用者の個人情報を新たなユーザＩＤに関連付ける
ことを特徴とする請求項１又は２何れか１項記載のサービス提供方法。
【請求項９】
ネットワークを介して複数の利用者の間でなされる利用者間通信において、
サービス利用者に対してユーザＩＤを生成・発行するとともに該ユーザＩＤの正当性を証明する証明書を生成する手段と、サービスの提供に必要なサービス利用者の個人情報を前記ユーザＩＤと関連付けて所定の記憶手段に記憶しておく手段と、利用者の端末が提示したユーザＩＤに関連付けられた個人情報を抽出する手段とを備えた利用者に対してサービスの提供を行うサービス提供者の端末を有し、
前記利用者間通信において一の利用者の端末は、他の利用者を指定して前記サービス提供者によるサービスを利用する際に、前記他の利用者の端末からユーザＩＤを取得する手段と、サービス提供者の端末から直接又は前記他の利用者の端末を介して前記ユーザＩＤの証明書を取得する手段と、該証明書により前記ユーザＩＤの正当性を検証する手段と、該ユーザＩＤをサービス提供者の端末に提示する手段とを備えた
ことを特徴とするサービス提供システム。
【請求項１０】
ネットワークを介して複数の利用者の間でなされる利用者間通信において、
利用者の端末からのユーザＩＤ及び証明書の登録要求に応じて当該ユーザＩＤ及び該ユーザＩＤの正当性を証明する証明書を該利用者へのサービス提供に必要な個人情報と関連付けて所定の記憶手段に記憶する手段と、利用者の端末が提示したユーザＩＤに関連付けられた個人情報を抽出する手段とを備えた利用者に対してサービスの提供を行うサービス提供者の端末を有し
利用者間通信において一の利用者の端末は、他の利用者に対してユーザＩＤ及び証明書を生成・発行するとともに該ユーザＩＤ及び証明書を他の利用者の端末に送信する手段と、他の利用者を指定して前記サービス提供者によるサービスを利用する際に、前記他の利用者の端末からユーザＩＤを取得する手段と、サービス提供者の端末から直接又は前記他の利用者の端末を介して前記ユーザＩＤの証明書を取得する手段と、該証明書により前記ユーザＩＤの正当性を検証する手段と、該ユーザＩＤをサービス提供者の端末に提示する手段とを備え、
前記他の利用者の端末は、前記一の利用者の端末で発行されたユーザＩＤ及び証明書を前記サービス提供者の端末に登録する手段とを備えた
ことを特徴とするサービス提供システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、例えばオンラインショッピング業者と顧客との間の通信のようにネットワーク上での利用者間の通信において、利用者が第三者であるサービス提供者からサービスを受ける際の利用者のプライバシを保護する技術に関する。
【背景技術】
【０００２】
現実社会においては、二者が何らかの取引や契約等を行う場合、顔と顔を突き合わせ相手がどのような人物であるかを自分で判断したり、その場で価値のあるもの同士（例えば商品と現金）の交換を行ったり、クレジットカードを用いてカード会社による与信情報及び本人の署名を用いたりすることにより、互いに相手を信頼して取引等を行っている。これは現実社会における一種の認証モデルということができる。
【０００３】
一方、ネットワーク上における取引等では、相手や商品等を現実に確認することができないので、前述のような現実社会における認証モデルをそのまま用いることは非常に困難である。そこで、ネットワーク上での取引では、クレジットカードのように第三者による与信情報を用いることにより認証が行われてきた。すなわち、例えばオンラインショッピングにおいては、ショップは顧客からクレジットカード番号，カードホルダ名，有効期限を受信し、これらの情報から当該クレジットカード番号が正当なものであるかをクレジットカード会社に問い合わせ、正当なものであるならば商品の販売を行う。そして、販売後にはクレジットカード会社により決済を行う。
【０００４】
しかし、クレジットカードによる決済システムは元々ネットワーク上における取引を想定していないため、なりすましなどのトラブルが非常に大きな問題となっている。また、クレジットカード番号という個人を一意に特定可能な番号を用いているために、個人の行動履歴を集積し、個人の行動パターンが分かるようになり、新たなプライバシ侵害が起きる可能性がある。また、この個人情報の集積は、クレジットカード番号だけでなく、氏名・住所等を用いても行えるため、これらの個人情報の流通活用は重大なプライバシ侵害を起こす可能性がある。
【０００５】
さらに、現状では、例えば氏名・住所など個人を特定することが可能な個人情報を多数の場所に提示しなければサービスを受けることができない。例えば、オンラインショッピングでは、クレジットカード番号という個人を特定可能な情報をショップに提示するとともに、購入商品を配送するために配送業者に住所・氏名等の個人を特定可能な情報を提示する必要がある。このように多数の者に対して個人情報を提示する必要があるため、個人情報が流出しても、どこから流出したかを特定することは困難であった。これにより、個人情報の取り扱いは情報を受け取ったシステムにより自由に行われることにとなり、個人情報売買を防ぐことは困難であった。さらに、一度提示してしまった個人情報は、削除することが非常に困難であり、流出してしまった個人情報は取り戻すことができないという問題があった。
【０００６】
このような問題を解決するために、サービス提供者が顧客とショップの間に入り、両者の間で匿名でサービスを行う方法なども提案されている（特許文献１参照）。具体的には、配送サービスなどを行うサービス提供者が、顧客から受信した住所・氏名等を登録するとともに該顧客に対して匿名ＩＤを発行する。顧客はショップで商品を購入する際には自身を識別する情報として氏名等を提示するのではなく前記匿名ＩＤを提示する。ショップはサービス提供者に対して匿名ＩＤを提示して商品の配送を依頼する。サービス提供者は提示された匿名ＩＤに対応する住所・氏名等を宛先として商品を配送する。これにより、ショップは「何を購入したか」はわかるが、「誰が購入したか」は分からない。一方、サービス提供者は「誰が何処から購入したか」はわかるが、「何を購入したか」はわからない。
【特許文献１】特開２００２−７９０４号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
しかし、従来の方法では、匿名でサービス提供を行うサービス提供者に全ての情報が集中してしまうため、プライバシ情報の蓄積がなされてしまう。したがって、ひとたび匿名サービス提供者からの情報流出が生じるとその被害は甚大なものになる恐れがあった。
【０００８】
本発明は、上記事情に鑑みてなされたものであり、その目的とするところは、利用者の匿名性を高めることができるサービス提供方法及びシステムを提供することにある。
【課題を解決するための手段】
【０００９】
上記目的を達成するために、本願では、ネットワークを介して複数の利用者の間でなされる利用者間通信において、利用者に対してサービスの提供を行うサービス提供者の端末が、サービス利用者に対してユーザＩＤを生成・発行するとともに該ユーザＩＤの正当性を証明する証明書を生成するステップと、サービスの提供に必要なサービス利用者の個人情報を所定の記憶手段に前記ユーザＩＤと関連付けて記憶するステップと、前記利用者間通信において一の利用者の端末が、他の利用者を指定して前記サービス提供者によるサービスを利用する際に前記他の利用者の端末からユーザＩＤを取得するステップと、サービス提供者の端末から直接又は前記他の利用者の端末を介して前記ユーザＩＤの証明書を取得するステップと、該証明書により前記ユーザＩＤの正当性を検証するステップと、該ユーザＩＤをサービス提供者の端末に提示するステップと、サービス提供者の端末が、前記一の利用者の端末が提示したユーザＩＤに関連付けられた個人情報を前記記憶手段から抽出するステップと、サービス提供者が該個人情報に基づきサービス提供を行うステップとを含むことを特徴とするサービス提供方法を提案する。
【００１０】
また、本願では、ネットワークを介して複数の利用者の間でなされる利用者間通信において、一の利用者の端末が、他の利用者に対してユーザＩＤ及び該ユーザＩＤの正当性を証明する証明書を生成・発行するステップと、サービス提供者の端末が、前記他の利用者の端末から受信したユーザＩＤ及び証明書とサービスの提供に必要なサービス利用者の個人情報とを関連付けて所定の記憶手段に記憶するステップと、前記利用者間通信において一の利用者の端末が、他の利用者を指定して前記サービス提供者によるサービスを利用する際に前記他の利用者の端末からユーザＩＤを取得するステップと、サービス提供者の端末から直接又は前記他の利用者の端末を介して前記ユーザＩＤの証明書を取得するステップと、該証明書により前記ユーザＩＤの正当性を検証するステップと、該ユーザＩＤをサービス提供者の端末に提示するステップと、サービス提供者の端末が、前記一の利用者の端末が提示したユーザＩＤに関連付けられた個人情報を前記記憶手段から抽出するステップと、サービス提供者が該個人情報に基づきサービス提供を行うステップとを含むことを特徴とするサービス提供方法を提案する。
【００１１】
本発明によれば、利用者がサービス提供者からサービスを利用する際には、該サービス提供者又は利用者からユーザＩＤを発行してもらい、利用者間ではこのユーザＩＤを用いて利用者を特定することにより利用者の匿名性が向上する。これは、サービスの享受に必要な個人情報はサービス提供者に開示されることになるが、該個人情報のうち利用者間の通信において不要なものは利用者間で開示する必要がなくなるためである。
【００１２】
また、全ての個人情報を相手先利用者及びサービス提供者に開示する必要が無く、必要な個人情報のみを分散して開示できるので匿名性が高く、サービス提供者が結託しないかぎり個人の特定は困難となる。
【００１３】
さらに、サービス提供者又は利用者はユーザＩＤとともに該ユーザＩＤの正当性を証明する証明書を発行するので、相手先利用者からユーザＩＤの提示を受けた利用者は該証明書を取得・検証することにより、そのユーザＩＤが本当に相手先利用者のものであるかを確認できる。これにより、相手を特定する情報としてユーザＩＤしか提示されていなくても、該ユーザＩＤを用いたサービスの享受を安全に行うことができる。
【００１４】
なお、本発明の利用者及びサービス提供者の典型的且つ具体的な一例としてのオンラインショッピングシステムでは、顧客及びオンラインショップが本願発明の利用者に該当し、決算機関及び配送業者等がサービス提供者に該当する。
【発明の効果】
【００１５】
以上説明したように本発明によれば、プライバシ情報を分散して管理することにより、従来の方法に比べより匿名性の高い情報流通活用を行うことが可能となる。
【発明を実施するための最良の形態】
【００１６】
本願発明では上述のように、サービス提供者は利用者に対してユーザＩＤ及び証明書を発行し、利用者から該ユーザＩＤを提示したサービス要求があればサービスを提供する。これは、サービス提供者が、「このユーザＩＤを有する者について与信を行った」と考えることができる。そこで、以下の説明では、サービス提供者を「与信者」として本願発明の原理について図面を参照して説明する。
【００１７】
図１は本発明の基本原理を説明するものである。図１に示すように、両利用者１１及び１２は自分の信頼する与信者２１に対して、自分の希望する与信内容に対して必要な情報及び対価を渡すことにより与信を依頼し、ユーザＩＤを取得する。このとき、与信者２１に渡す個人情報を可能な限り少なくすることにより、個人情報が特定の者に集積されることを防ぐ。
【００１８】
与信者２１と両利用者１１，１２の間では、電子署名を用いた認証や取引を行う。取引を行う際には与信者２１を介さず、利用者１１，１２間で互いに認証を行うことにより、取引を行った時間や内容を与信者に知られないようにすることができる。取引においては、利用者１１，１２は自分の提示する条件に対して自分が用意した暗号鍵を用いて署名を行い、受け取ったもう一方の利用者１２，１１は署名を検証し、与信者２１による保証を担保に相手の示した条件を信頼する。支払などの決済処理を行う場合は、金額の記載された文書に署名を行った支払証明書を交換し、与信者２１を介して金銭の移動を行う。このとき、与信者２１は金銭の移動のみを知ることができ、取引内容については知ることができない。
【００１９】
次に、利用者１１，１２間の取引を本人の同意がある場合にのみ連携させる方法について図２を用いて説明する。利用者１１が利用者１２及び利用者１３に対して、同じ名前（識別子：ＩＤ）で取引を行う場合、匿名処理を行っていたとしても、利用者１２と利用者１３とが、利用者１１を同じＩＤで認識している場合、利用者１２と利用者１３が結託してしまうと利用者１１の情報を集積することが可能となってしまう。そこで、本願発明では、利用者が取引を行う相手それぞれに対して別のＩＤを使うことによって、情報の集積を行わせないようにする。例えば、利用者１１は個人、与信者２１は銀行やクレジットカード会社のような決済機関、利用者１２及び１３は商品販売店という構成が考えられる。利用者１１は利用者１２で商品の購入を行い、与信者２１が支払を保証することにより、利用者１１は利用者１２の間の売買契約を行う。但しこのとき、利用者１１は銀行口座番号やクレジットカード番号といった他者に対しても同じ番号で認識されるようなユーザＩＤではなく、相手（利用者１２及び１３）によって全て違うユーザＩＤ（場合によっては取引に応じて毎回違うユーザＩＤ）を用いることによって、相手によって自分が与信者２１から与信をうけているというこの認証を行う。また、与信者２１は利用者１１，１２，１３間の取引内容のうち、決済に係わる情報のみを知ることができる。また、図３に示すように、利用者１１と利用者１２の間の配送を行う与信者２２が与信者２１と並列に入ることによって、利用者１１は決済と同様に匿名で商品の配送を受けることができる。また、与信者２１と与信者２２の間で連携を行うことにより、商品の配達が終了したことを通知し、それを基に決済処理を行うことも可能である。これは、商品を受け取っていないのに決済処理がされるのを防ぐことを目的としている。
【００２０】
このように、複数の与信者が利用者間にはいることにより、個々の与信者が得ることのできる内容を減少させ、情報を分散させることが可能であり、与信者同士が結託しなければ、プライバシを守ることが可能である。与信者が二者いる場合の取引方法について図４を用いて説明する。利用者１１は、与信者２１を介して匿名で与信者２２と与信契約を行う（図４（ａ））。次に、利用者１１は与信者２２を介して利用者１２と取引を行うことができる（図４（ｂ））。例えば、与信者２１は決済機関で利用者１１の個人を特定できるような情報を持っていて、決済処理を行うことができる。与信者２２は、利用者１１の個人を特定できるような情報を持っていないが、個人を特定しない範囲の情報（性別、年齢、居住地域、趣味、行動履歴など）を持っていて、マーケッティング処理などを行うことができる。利用者１２は、商品の販売店などで商品者の購買動向の調査を与信者２２に依頼することができる。与信者２２は利用者１２から受けた調査に対する報酬を与信者２１を介することによって匿名の状態でも顧客である利用者１１に還元することができる（図４（ｃ））。このプロセスによって、与信者２２及び利用者１２は、利用者１１の個人を特定することができないが、情報を活用することが可能であり、情報提供の対価を支払うことができる。
【００２１】
さらにもう一者与信者を追加したモデルについて図５を用いて説明する。利用者１１は与信者２１を介して与信者２２と与信契約を行い、利用者１２は与信者２３を介して与信者２２と与信契約を行う（図５（ａ））。その後、利用者１２は与信者２２を介して利用者１２と取引を行う。例えば、利用者１１及び１２は個人、与信者２１及び２３は決済機関、与信者２２はオークションサイトという構成が考えられる。利用者１１と利用者１２は与信者２２において個人間取引を行う。与信者２２は利用者間の取引内容（金銭の授受）を基に、与信者２１及び与信者２３の間で金銭の移動を行う（図５（ｂ））。図３と同様に与信者２２と並列に配送を行う与信者を追加することにより、オークションで問題になっている商品を送ったのに対価が貰えない、対価を払ったのに商品を受け取れないと言うことを防止することができる。
【００２２】
次に、本発明の具体的な実施形態について図面を参照して説明する。まず、本実施の形態の説明で使用する用語について説明する。以下の説明では登場する者として以下の５者がある。なお、下記リストで括弧の中に示されている「利用者」又は「サービス提供者」なる記載は、特許請求の範囲における用語である。
【００２３】
１．Ｕｓｅｒ：商品の購買などを行う顧客（利用者）の端末
２．ＳＰ：オンラインショップや実際の店舗など顧客にサービスや商品を提供する者（利用者）の端末
３．ＩＤＰ：課金決済系に関する与信者（サービス提供者）の端末
４．ＣＲＭ：個人情報に関する与信者（サービス提供者）の端末
５．Ｄｅｌｉｖｅｒｙ：配送に関する与信者（サービス提供者）の端末。
【００２４】
また、上記登場者に払い出されるＩＤとしては以下の３つがある。
【００２５】
１．ＰＩＤ：ユーザを管理（特定）するためにＩＤＰが発行するＩＤ。このＰＩＤは１ユーザにつき１つである。
【００２６】
２．ＵＩＤ：ユーザの匿名性のために、複数払い出されるＩＤ。このＵＩＤの発行は、１取引毎や１店舗に１つなどの形態がある。また、このＵＩＤは、ＩＤＰが発行してもよいし、ＳＰが発行してもよい。ＳＰが発行する場合は、１取引ではなく、ＳＰの顧客ＩＤとなることが多い。
【００２７】
３．ＳＰＩＤ：サービス提供者を識別するＩＤ。ＰＩＤのように固有のものであっても、ＵＩＤのように匿名のものであってもよい。個人個人間の取引の場合はＵＩＤになるし、オンラインショップであれば匿名性は必要なく逆に万人に知れ渡っている方がよいのでＰＩＤを用いた方がよいこともある。図には登場しないが、ＩＤＰも相互認証のためにＩＤを持つ。
【００２８】
上記の個々のＩＤには、認証を行うために公開鍵暗号方式の鍵ペアが割り当てられており、このＩＤを与信するものがＩＤ及び交換鍵に対して証明書を発行する。証明書には有効期限や与信の範囲（匿名決済であれば限度額など）などの情報を含んでいてもよい。
【００２９】
また、上記のＩＤは、一人のユーザが複数のＩＤ及び公開鍵暗号方式の鍵ペア（場合によっては証明書）を管理することになるため、ユーザ側では耐タンパ性があり且つ暗号化などの演算能力のある媒体たとえばＩＣカードに記憶される。これに伴い、Ｕｓｅｒは該ＩＣカードの読み書き手段を備えており、各ＩＤや証明書等をネットワークを介してＳＰやＩＤＰ等に送信可能となっている。このように、ＩＣカードを用いることにより、使用するＩＤを自動的に判別し、ユーザが複数のＩＤなどを意識することなく安全に利用可能である（一つのＩＤでシングルサインオンを行うシステムと比較して安全である）。また、Ｕｓｅｒは、ＳＰやＩＤＰ等に接続して登録作業等を行うための手段としてブラウザを備えている。
【００３０】
ＳＰ，ＩＤＰ，ＣＲＭ，Ｄｅｌｉｖｅｒｙはそれぞれ、各ＩＤ及び個人情報や各ＩＤに対応する公開鍵等を記憶・管理する記憶手段、公開鍵暗号方式を用いた暗号化復号化処理部と、通信相手に対してＩＤを払い出す機能や該ＩＤに対応する証明書（後述する）等を提供する機能等を備えたＩＤ提供部と、通信相手先にサービスの提供を行うサービス提供部を備えている。本実施の形態では、ＩＤ提供部やサービス提供部による機能提供ではインタフェイスとしてＷｅｂを用いている。
【００３１】
［ＵＩＤの発行方法］
次に、前記ＵＩＤの発行及び認証方法について説明する。ここでは、ＳＰはすでにＩＤＰから与信を受けている状態とする。また、ＩＤＰの公開鍵は、誰でも入手可能とする。
【００３２】
［ＳＰによるＵＩＤの発行］
まず、ＳＰがＵＩＤを発行する場合について図６を参照して説明する。Ｕｓｅｒ１は、ＩＤＰ２に与信をしてもらうべく申請（登録）を行う（ステップＳ１０１）。この際、プリペイド的なサービスであればお金の入金が、クレジットカード的なサービスであれば、個人情報（氏名・住所・勤務先・年収など）を知らせる必要がある。次に、ＩＤＰ２はＵｓｅｒ１を識別するためのＩＤ（ＰＩＤ）を作成する（ステップＳ１０２）。次に、ＩＤＰ２は作成したＰＩＤをＵｓｅｒ１に送信する（ステップＳ１０３）。次に、Ｕｓｅｒ１は受け取ったＰＩＤに対し認証用パスワードに相当する公開鍵暗号方式の鍵ペア（ＰＫ，ＳＫ）を作成する（ステップＳ１０４）。鍵の作成はＩＣカード内部で行うことが望ましいが、外部に秘密鍵が漏れなければよい。次に、Ｕｓｅｒ１は、作成した鍵ペアのうち公開鍵ＰＫをＩＤＰ２に送信し、ＩＤＰ２に登録する（ステップＳ１０５）。
【００３３】
ＩＤＰ２は、Ｕｓｅｒ１に対して作成したＰＩＤ及びＵｓｅｒ１から受信した公開鍵ＰＫに対し、ＩＤＰ２の秘密鍵を用いて署名を行い、証明書ＰＫＣを作成する（ステップＳ１０６）。この証明書ＰＫＣには、与信範囲、有効期限などの情報を含んでいてもよい。次に、ＩＤＰ２に対してオフラインでサービスの享受が可能なシステムの場合、証明書ＰＫＣをＵｓｅｒ１に送信し、ＩＣカード等の記録媒体に該証明書ＰＫＣを記憶する（ステップＳ１０７）。
【００３４】
以上のステップがＩＤＰ２とＵｓｅｒ１との間の登録作業である。
【００３５】
次に、Ｕｓｅｒ１は利用したいＳＰ３ｎに接続し、匿名で顧客登録を行う（ステップＳ１０８）。次に、ＳＰ３ｎはＵｓｅｒ１用の顧客ＩＤとしてＵＩＤｎを作成し（ステップＳ１０９）、該ＵＩＤｎをＵｓｅｒ１に送信する（ステップＳ１１０）。
【００３６】
次に、Ｕｓｅｒ１は受け取ったＵＩＤｎに対し認証用のパスワードに相当する公開鍵暗号方式の鍵ペア（ＰＫｎ，ＳＫｎ）を作成する（ステップＳ１１１）。鍵の作成については上記ステップＳ１０４と同様である。次に、Ｕｓｅｒ１は作成した鍵ペアのうち公開鍵ＰＫｎをＳＰ３ｎに送信し、ＳＰ３ｎに登録する（ステップＳ１１２）。
【００３７】
次に、ＳＰ３ｎはＵｓｅｒ１のＵＩＤｎ及び公開鍵ＰＫｎに対し、ＳＰ３ｎの秘密鍵を用いて署名を行い、証明書ＰＫＣｎを作成する（ステップＳ１１３）。この証明書には、有効期限などの情報を含んでいてもよい。ＳＰ３ｎは、作成した証明書ＰＫＣｎを必要に応じてＵｓｅｒ１に送信する（ステップＳ１１４）。
【００３８】
次に、Ｕｓｅｒ１はＳＰ３ｎに対する決済代行処理をＩＤＰ２に依頼する場合、ＳＰ３ｎのＩＤであるＳＰＩＤｎと顧客ＩＤであるＵＩＤｎと公開鍵ＰＫｎ（又は証明書ＰＫＣｎ）とをＩＤＰ２に登録する（ステップＳ１１５）。なお、Ｕｓｅｒ１がＩＤＰ２にログインする際の認証方法については後述する。この際、ＩＤＰ２はＵｓｅｒ１がＳＰ３ｎの正規の顧客であるかＰＫＣｎを用いて認証することができる。ＩＤＰ２では、依頼のあったＵＩＤｎをＵｓｅｒ１の識別ＩＤであるＰＩＤに関連付けを行う。
【００３９】
以上のステップがＳＰ３とＵｓｅｒ１の間の登録作業である。
【００４０】
次に、Ｕｓｅｒ１はＳＰ３ｎのサービスを受けるために、ＳＰ３ｎにログインする（ステップＳ１１６）。なお、Ｕｓｅｒ１がＳＰ３ｎにログインする際の認証方法については後述する。次に、ＳＰ３ｎは、ＩＤＰ２にログインし、自分の顧客ＵＩＤｎの顧客登録がなされいてるか確認する（ステップＳ１１７）。次に、ＩＤＰ２は、ＳＰＩＤｎ及びＵＩＤｎを用いて、ＰＩＤを検索し、登録の有無及び与信の範囲、有効期限などをＳＰ３ｎに通知する（ステップＳ１１８）。また、ＩＤＰ２は顧客により登録された公開鍵ＰＫｎ又は証明書ＰＫＣｎをＳＰ３ｎに送信する。次に、ＳＰ３ｎは、受信した公開鍵ＰＫｎ又は証明書ＰＫＣｎについて自身の公開鍵を用いて署名を確認し、公開鍵ＰＫｎを取り出した後、それが顧客ＵＩＤｎのものであるかを確認する。なお、ＩＤＰ２は、以後、このＵｓｅｒ１の証明書が失効した場合は、ＳＰ３ｎに通知するサービスなども可能である。
【００４１】
以上のステップによりＵＩＤが発行されたので、ＳＰ３ｎはＩＤＰ２の与信範囲に応じてＵｓｅｒ１にサービスを行うことができる。
【００４２】
［ＩＤＰによるＵＩＤの発行］
次に、ＩＤＰ２がＵＩＤを発行する場合について図７を用いて説明する。
【００４３】
まず、Ｕｓｅｒ１はＩＤＰ２に与信をしてもらうべく申請（登録）を行う（ステップＳ２０１）。この際、プリペイド的なサービスであればお金の入金が、クレジットカード的なサービスであれば、個人情報（氏名・住所・勤務先・年収など）を知らせる必要がある。次に、ＩＤＰ２はＵｓｅｒ１を識別するためのＩＤ（ＰＩＤ）と複数のＵＩＤを作成する（ステップＳ２０２）。次に、ＩＤＰ２は作成したＰＩＤ及びＵＩＤのセットをＵｓｅｒ１に送信する（ステップＳ２０３）。次に、Ｕｓｅｒ１は受け取ったＰＩＤ及びＵＩＤに対し認証用パスワードに相当する公開鍵暗号方式の鍵ペア（ＰＫ，ＳＫ）を作成する（ステップＳ２０４）。鍵の作成はＩＣカード内部で行うことが望ましいが、外部に秘密鍵が漏れなければよい。次に、Ｕｓｅｒ１は、作成した鍵ペアのうちＰＩＤ及び各ＵＩＤに対する公開鍵ＰＫをそれぞれＩＤＰ２に送信し、ＩＤＰ２に登録する（ステップＳ２０５）。
【００４４】
ＩＤＰ２は、Ｕｓｅｒ１に対して作成したＰＩＤ及びＵＩＤ並びにＵｓｅｒ１から受信した公開鍵ＰＫに対し、ＩＤＰ２の秘密鍵を用いて署名を行い、証明書ＰＫＣを作成する（ステップＳ２０６）。この証明書ＰＫＣには、与信範囲、有効期限などの情報を含んでいてもよい。次に、ＩＤＰ２に対してオフラインでサービスの享受が可能なシステムの場合、ＰＩＤ及び各ＵＩＤに対する証明書ＰＫＣをＵｓｅｒ１に送信し、ＩＣカード等の記録媒体に該証明書を記憶する（ステップＳ２０７）。
【００４５】
このＵＩＤは基本的に一取引につき一つずつ使うため、頻繁に再発行する必要がある。再発行手続は、ＩＤＰ２による認証の安全性及び通信路の安全性が保証されれば、オンラインで行うことが可能である。
【００４６】
［認証方法］
次に、Ｕｓｅｒ１がＳＰ３ｎに対してログインする際の認証方法について図８を参照して説明する。なお、Ｕｓｅｒ１がＩＤＰ２にログインする際及びＳＰ３ｎがＩＤＰ２にログインする際の認証については、Ｕｓｅｒ１がＳＰ３ｎに対してログインする手順と同様であるので、ここでは説明を省略する。なお、通信路については、ＳＳＬなどの暗号化が行われていて、盗聴されないものとする。
【００４７】
本実施の形態では認証方法としてＰＫＩ（Public Key Infrastructure）を用いる。具体的には、まず、Ｕｓｅｒ１はＳＰ３ｎに接続要求を行う（ステップＳ３０１）。次に、ＳＰ３ｎは、自身ＩＤであるＰＩＤｎをＵｓｅｒ１に送信する（ステップＳ３０２）。ここで、必要に応じて証明書ＰＫＣｎも送信する。Ｕｓｅｒ１は、前記ステップＳ３０２でＰＫＣｎを受け取っていない場合、ＩＤＰ２にＳＰＩＤｎの証明書を要求し（ステップＳ３０３）、ＩＤＰ２は、ＳＰＩＤｎの証明書ＰＫＣｎをＵｓｅｒ１に送信する（ステップＳ３０４）。
【００４８】
次に、Ｕｓｅｒ１は認証用の乱数Ｒを生成し、ＳＰ３ｎに送信する（ステップＳ３０５）。次に、ＳＰ３ｎは、自身の秘密鍵ＳＫｎを用いて乱数Ｒに署名を行い、署名付乱数ＳＫｎ（Ｒ）をＵｓｅｒ１に送信する（ステップＳ３０６）。
【００４９】
次に、Ｕｓｅｒ１はＳＰＩＤｎの証明書ＰＫＣｎからＳＰ３ｎの公開鍵ＰＫｎを取り出し、署名付乱数ＳＫｎ（Ｒ）から乱数Ｒを復号化し、自身が送信したＲと比較することにより認証を行う（ステップＳ３０７）。
【００５０】
このステップＳ３０７で認証が正しく行われたら、Ｕｓｅｒ１はＳＰ３ｎに対して用いる顧客ＩＤであるＵＩＤｍをＳＰ３ｎに送信する（ステップＳ３０８）。ここで、必要に応じて証明書ＰＫＣｍも送信する。ＳＰ３ｎは、前記ステップＳ３０８でＰＫＣｍを受け取っていない場合は、ＩＤの発行元にＵＩＤｍの証明書を要求する（ステップＳ３０９）。ここでは、ＩＤＰ２が発行元である場合について述べるが、ＳＰ３ｎが発行元である場合もある。
【００５１】
次に、ＩＤＰ２はＵＩＤｍの証明書ＰＫＣｍをＳＰ３ｎに送信する（ステップＳ３１０）。次に、ＳＰ３ｎは認証用の乱数Ｒを生成し、Ｕｓｅｒ１に送信する（ステップＳ３１１）。次に、Ｕｓｅｒ１は、ＵＩＤｍ用の秘密鍵ＳＫｍを用いて乱数Ｒに署名を行い、署名付乱数ＳＫｍ（Ｒ）をＳＰ３ｎに送信する（ステップＳ３１２）。次に、ＳＰ３ｎは、証明書ＰＫＣｍからＵＩＤｍの公開鍵ＰＫｍを取りだし、署名付乱数ＳＫｍ（Ｒ）からＲを取りだし、自身が送信したＲと比較することにより認証を行う（ステップＳ３１３）。
【００５２】
このような認証ステップを円滑に実施するために、各種ＩＤを記憶するＩＣカードにはＳＰＩＤに応じてどの顧客ＩＤ（ＵＩＤ）を用いるかを判別する機能を設けると好適である。これにより、Ｕｓｅｒ１がＳＰ３ｎに接続する際、どのＩＤを用いればよいかを意識する必要がなく、相手に応じて全て違う顧客ＩＤを使いながらも、Ｕｓｅｒ１はシングルサインオン感覚で利用できる。これは、通常のシングルサインオンで行われている１つのＩＤを使い回す方法と比較して、非常に安全である。但し、顧客ＩＤを自動認識するために、ＳＰ３が自分のＩＤを詐称した場合、Ｕｓｅｒ１の顧客ＩＤが盗まれる可能性があるが、上記のように相互認証を行うことにより防ぐことができる。
【００５３】
［与信者を利用した匿名サービスの享受］
次に、本発明を用いた各種匿名サービスの実施形態について図面を参照して説明する。ここでは、Ｕｓｅｒ１は、前述のＩＤＰ２に対する登録と同様の方法で、Ｄｅｌｉｖｅｒｙ４に対し登録し、与信（匿名の配送）を依頼しているものとする。このとき、物流であれば、住所・氏名などの情報を、メール配信であればｅ−ｍａｉｌアドレスなどをＤｅｌｉｖｅｒｙ４に対して公開する必要がある。また、同時に配送ＩＤとして複数のＤＩＤを受け取っておいてもよい。このとき、ＵＩＤと同様にＤＩＤに対しても認証用の鍵ペア（ユーザ側）及び証明書（Ｄｅｌｉｖｅｒｙ４側）を作成しておくことによって、配送の確認を認証により証明することが可能となる。
【００５４】
［匿名でオンラインショッピングを行う方法］
まず、匿名でオンラインショッピングを行う方法について図９を参照して説明する。
【００５５】
Ｕｓｅｒ１は、ＩＤＰ２発行又はＳＰ３発行のＵＩＤｎを用いてＳＰ３ｎにログインする（ステップＳ４０１）。このとき、どちらのＵＩＤを用いるかは、ユーザの判断によってもよいし、ＳＰ３から顧客ＩＤが発行されていれば、自動的にＳＰ３発行のＵＩＤを用いるようにしてもよい。
【００５６】
次に、ＳＰ３ｎは、登録作業の過程で与信情報の確認を行っていない場合や、高額取引を行うので改めて与信情報を確認したい場合などは、ＳＰ３ｎがＩＤＰ２に対して与信情報を要求する（ステップＳ４０２）。ＩＤＰ２は、前記ステップＳ４０２で与信情報が要求された場合、与信情報をＳＰ３ｎに送信する（ステップＳ４０３）。
【００５７】
次に、ＳＰ３ｎは、ユーザに要求されたサービス（商品の購入など）に対する請求を行う（ステップＳ４０４）。より具体的には、サービスに対する明細書をＵｓｅｒ１に提示し、金額のみが記載された請求書を送信して支払に同意するかどうかを確認する。
【００５８】
ここで、予め、Ｕｓｅｒ１がＤｅｌｉｖｅｒｙ４から配送用ＩＤとしてＤＩＤの発行を受けていない場合、又はＤＩＤを使い果たしてしまっている場合、Ｕｓｅｒ１はＤｅｌｉｖｅｒｙ４にログインし、配送用ＩＤとしてＤＩＤの発行を依頼する（ステップＳ４０５）。配送先がＤｅｌｉｖｅｒｙ４に登録している氏名・住所と異なる場合には、ＤＩＤ発行の際に配送先の氏名・住所を登録する。また、ＳＰ３ｎが取り扱うことのできるＤｅｌｉｖｅｒｙ４に登録がない場合、Ｕｓｅｒ１はこの時点でＤｅｌｉｖｅｒｙ４に対して登録手続を行い、配送用ＩＤの発行を依頼してもよい。Ｄｅｌｉｖｅｒｙ４は、前記ステップＳ４０５でＤＩＤの発行依頼があった場合、Ｕｓｅｒ１にＤＩＤを払い出す（ステップＳ４０６）。
【００５９】
次に、Ｕｓｅｒ１は、前記ステップＳ４０４で提示された明細書を確認の上、支払金額のみが記録された請求書に対してＵＩＤｎ用の秘密鍵ＳＫｎを用いて署名を行いＳＰ３ｎに送信する。また、配送先指定として、ＤＩＤｍの送信も行う。必要があれば署名入りＤＩＤｍの送信も行う（ステップＳ４０７）。
【００６０】
次に、ＳＰ３ｎは、受け取った署名入り請求書を、ＵＩＤｎ用の公開鍵ＰＫｎを用いてデコードすることにより、請求書に対してきちんと署名が行われているかを確認する（ステップＳ４０８）。このとき、ＳＰ３ｎは、ＩＤＰ２を介することなしに確認を行うことができる。次に、ＳＰ３ｎは、明細書にＳＰ３ｎの秘密鍵で署名を行ったレシートを、支払に対する領収書として発行しＵｓｅｒ１に送信する。
【００６１】
ここでは、以上のステップののち決済処理についてのシーケンスを行うが（下記ステップＳ４０９，Ｓ４１０）、該決済処理に関しては、この一連のシーケンスの中で行う必要はない。
【００６２】
ＳＰ３ｎは、ＩＤＰ２にログインし、ＵＩＤｎ及び署名入りの請求書ＳＫｎ（金額）を送信する（ステップＳ４０９）。次に、ＩＤＰ２は、ＵＩＤｎ（必要があればＳＰＩＤｎも）からＰＩＤを特定し、どのＵｓｅｒ１に対する請求かを特定し、ＵＩＤｎに対して登録されている公開鍵ＰＫｎを用いて署名付請求書ＳＫｎ（金額）をデコードし、請求書にＵｓｅｒ１の署名が入っているかどうかを確認する（ステップＳ４１０）。確認後は金銭の移動手続を行い、結果をＳＰ３ｎに送信する。
【００６３】
このように処理することによって、ＳＰ３ｎは誰にサービスをしているかわからないが決済処理を行うことができる。ＩＤＰ２は、どのＵｓｅｒ１がＳＰ３ｎでいくら使ったかは分かるが、どんなサービスを受けたかは分からなく、また決済処理はサービス提供のタイミングで行われるとは限らないので、いつサービスを受けたかも隠蔽することもできる。
【００６４】
次に、ＳＰ３ｎは、前記ステップＳ４０８の署名確認を行った後、ＤＩＤｍの発行者であるＤｅｌｉｖｅｒｙ４ｍに配送を依頼する（ステップＳ４１１）。署名入りＤＩＤｍも受け取っていれば、ＤＩＤｍとともに送信する。次に、Ｄｅｌｉｖｅｒｙ４ｍは、ＤＩＤｍからＵｓｅｒ１を特定し、配送先を確認して、受取人に商品を届ける（ステップＳ４１２）。署名入りＤＩＤｍを受け取った場合は、例えば無断配送など利用目的以外の配送を防ぐために、署名の確認を行う。受取人がＵｓｅｒ１自身である場合は、受け取りの認印として、ＤＩＤｍの発行時に登録した鍵ペアの秘密鍵を用いて署名を行うといったことも可能である。
【００６５】
この署名を用いた認印を使い、Ｕｓｅｒ１が受け取ったことが確認された後、前記ステップＳ４１０で行われるＩＤＰ２による金銭の移動を行うことも可能である。この場合には、前記ステップＳ４０８においてＳＰ３ｎはＤＩＤｍも同時にＩＤＰ２に送信する。また、前記ステップＳ４１２において署名を用いた認印を受け取ったＤｅｌｉｖｅｒｙ４ｍは、配送ＩＤがＤＩＤｍである配送が終了したことをＩＤＰ２に通知する。そして、前記ステップＳ４１０において、ＩＤＰ２はＤｅｌｉｖｅｒｙ４ｍからの配送完了通知を受け取ったあと金銭の移動処理を行う。
【００６６】
以上のような処理により、例えばオークションの個人間取引において、支払を行ったのに商品を受け取れない、商品を送ったのに支払がされない、などのトラブルを解消することが可能である。
【００６７】
なお、ここではオンラインショッピングについて説明を行ったが、ＳＰ３やＤｅｌｉｖｅｒｙ４に対する顧客登録を行わないのであれば、ＩＣカードのような持ち運びができる媒体を用いていることにより実際の店舗における買い物に対しても適応可能である。また、通信傍受や端末の改変などに対応した相互認証を行っていれば、店舗に設置している端末を用いても顧客登録作業についても安全に行うことが可能である。
【００６８】
このような、匿名でオンラインショッピングを実施する場合、以下に示すようなトラブルが生じることが考えられる。しかし、与信者であるＩＤＰ２，Ｄｅｌｉｖｅｒｙ４と、当事者であるＵｓｅｒ１，ＳＰ３ｎが、それぞれＩＤ情報、取引内容などを出し合い、どちらに責任があるかを明らかにすることできる。以下に具体的なトラブル及び該トラブルに対する本発明の優位性について説明する。
【００６９】
（１）Ｕｓｅｒ１がＳＰ３ｎとの取引を否定した場合、ＳＰ３ｎには前記ステップＳ４０７でＵｓｅｒ１が行った請求書が残っているため、ＩＤＰ２が署名を検証することによってＵｓｅｒ１の否定が虚偽であることを確認することができる。ＳＰ３ｎがＵｓｅｒ１との取引がないのに請求をしようとしても、前記ステップＳ４０７でＵｓｅｒ１が行うはずの署名がないために、ＩＤＰ２における署名検証においてＳＰ３ｎによる不当請求であることを検出可能である。また、Ｕｓｅｒ１とは異なる第三者がＵｓｅｒ１のＳＰ３ｎ用のＵＩＤｎを入手して取引を行おうとしても、前記ステップＳ４０１の認証やステップＳ４０７の署名により不正を検知することが可能である。
【００７０】
一方、従来用いられていたクレジットカード番号を用いた決済の場合、クレジットカード番号のみによって取引が完了してしまうため、Ｕｓｅｒ１が「取引をしていない」と事実否認することが可能である。また、ＳＰ３ｎが不当にＵｓｅｒ１のクレジットカード番号を入手したり、Ｕｓｅｒ１とは異なる第三者がＵｓｅｒ１になりすましてクレジットカード番号を利用して、Ｕｓｅｒ１が関与していない取引の請求がなされてしまう恐れがある。
【００７１】
（２）前記ステップＳ４０８までの処理で売買契約が行われ、支払手続が完了したにもかかわらず、Ｕｓｅｒ１に届かなかった場合が考えられる。この場合、Ｕｓｅｒ１はＩＤＰ２に対して前記ステップＳ４０７で署名を行った証明書の決済の中断を依頼する。その際、配送先をしているＤＩＤｍもＩＤＰ２に送付する。ＩＤＰ２はステップＳ４０７の証明書からＳＰ３ｎを割り出し、ＳＰ３ｎに商品の配送状況を問い合わせる。ＳＰ３ｎが配送状況を回答しなかった場合決済を中断とする。一方、配送状況として「ＤＩＤｍを用いてＤｅｌｉｖｅｒｙ４に配送を依頼した」との回答があった場合、Ｕｓｅｒ１から送付されたＤＩＤｍと照合し、同一のものであれば引き続きＤｅｌｉｖｅｒｙ４に問い合わせを行い、同一のものでなかった場合は決済を中断する。次に、ＩＤＰ２はＤｅｌｉｖｅｒｙ４に問い合わせを行い、ＤＩＤｍの配送状況を調べ、ＳＰ３ｎから依頼が来ていない場合は決済中止を行い、配送中であれば配送を促し、配送済みであればＵｓｅｒ１の受け取とり署名を検証し、Ｕｓｅｒ１の依頼が虚偽であることを検証可能である。決済を中止した場合、Ｕｓｅｒ１にその旨を通知し、ＳＰ３ｎに警告・信用度を落とすなどの処理を行う。Ｕｓｅｒ１が虚偽の発言をしている場合、Ｕｓｅｒ１に警告・与信範囲縮小や取消などの処理を行う。
【００７２】
このように本発明では、オンラインショッピングで生じるで予測される「なりすまし」や業務不履行など種々のトラブルに対する処置が可能であるため、匿名性を有しながら安全性の高い取引を行うことが可能となる。
【００７３】
［ＳＰが匿名のまま顧客管理を行いＣＲＭを行う方法］
通常、ＳＰはカスタマー・リレーションシップ・マネジメント（ＣＲＭ）を行うために情報の収集を行っている。この収集方法としては、ポイントカードを発行するときに個人情報を登録させる方法などがある。ポイントカード発行には、もう一つの目的「顧客の囲い込みを行う」という目的もある。そこで、匿名のままＣＲＭに必要な情報を収集可能であり、顧客の囲い込みも可能な方法について図１０を参照して説明する。なお、ここでは前述した匿名によるオンラインショッピングが実施されている状況であるとする。
【００７４】
まず、Ｕｓｅｒ１は、ＳＰ３にログインする（ステップＳ５０１）。なお、このタイミングで前述したＵＩＤの発行・登録を行ってもよい。
【００７５】
次に、予め、Ｄｅｌｉｖｅｒｙ４から配送用ＩＤとしてＤＩＤの発行を受けていない場合、又はＤＩＤを使い果たしてしまっている場合、Ｕｓｅｒ１はＤｅｌｉｖｅｒｙ４にログインし、配送用ＩＤとしてＤＩＤの発行を依頼する（ステップＳ５０２）。また、ＳＰ３ｎが取り扱うことのできるＤｅｌｉｖｅｒｙ４に登録がない場合、Ｕｓｅｒ１はこの時点でＤｅｌｉｖｅｒｙ４に対して登録手続を行い、配送用ＩＤの発行を依頼してもよい。このＤＩＤには、ダイレクトメール（ＤＭ）であれば氏名・住所、ｅ−ｍａｉｌによる広告などであればＵｓｅｒ１のｅ−ｍａｉｌアドレスなどの情報を関連付ける。Ｄｅｌｉｖｅｒｙ４は、前記ステップＳ５０２においてＤＩＤの発行依頼があった場合、Ｕｓｅｒ１にＤＩＤを払い出し、ＤＩＤに配送用の情報（住所・氏名、ｅ−ｍａｉｌアドレスなど）を関連付ける（ステップＳ５０３）。
【００７６】
次に、Ｕｓｅｒ１は、ＳＰ３ｎに対し個人を特定しない範囲でＣＲＭを行うのに必要な情報（性別、居住地域、年齢、趣味、嗜好など）を登録する（ステップＳ５０４）。性別、居住地域、年齢、趣味、嗜好などの情報は与信者により証明してもらうことも可能である。同時に、配送先指定として、ＤＭや広告メールを受信するためのＤＩＤｍ及び利用目的・有効期限・利用者（ここではＳＰ３ｎ）などをＤＩＤｍに対して作成した秘密鍵ＳＫｎを用いて署名を行った許可証をＳＰ３ｎに送信する。
【００７７】
これにより、ＳＰ３は個人情報の提供の対価として、Ｕｓｅｒ１にサービスを提供したときにポイントサービスをするといった、従来からＳＰが行っているポイントサービスを行うことができ、それにより顧客の囲い込みも可能となる。また、ＳＰ３は必要がればＵｓｅｒ１に対価を払い上記のような与信者により証明を受けた情報を要求することもでき、より精度の高いＣＲＭを行うことが可能となる。
【００７８】
このようにして収集した個人情報と、ＳＰ３がＵｓｅｒ１に提供したサービスの履歴をもとにＣＲＭを行い、顧客のニーズに合った新製品情報などがあった場合にＤＭや広告メールを配信する方法について説明する。
【００７９】
ＳＰ３ｎは、Ｕｓｅｒ１に発送したい広告を作成し、ＤＭであれば封書に、広告メールであれば顧客のＵＩＤｎに対応した公開鍵ＰＫｎを用いて暗号化を行い、送付先であるＤＩＤｍ及び許可書、送付する目的などを添えてＤｅｌｉｖｅｒｙ４に送信する（ステップＳ５０５）。
【００８０】
次に、Ｄｅｌｉｖｅｒｙ４は、ＳＰ３ｎから受け取ったＤＩＤから公開鍵ＰＫｍを特定し、許可書をデコードし、利用条件（利用者、利用目的、有効期限など）が守られているかを確認し、ＤＭ又は広告メールをＵｓｅｒ１に送付する（ステップＳ５０６）。このとき、Ｄｅｌｉｖｅｒｙ４は、ＤＭが封書となっているため、また、広告メールは暗号化されているため内容を知ることができない。一方、Ｕｓｅｒ１は広告を受け取り、ＤＭであれば封書を開き、広告メールであればＤＩＤｍを提供しているＳＰ３ｎに対して登録してある鍵ペアの秘密鍵ＳＫｎを用いてデコードすることにより、内容を読むことができる。
【００８１】
なお、一連の流れと必ずしも連動する必要がないが、ＳＰ３ｎはＵｓｅｒ１から個人情報を受けた場合や、個人情報を利用した場合に、見返りとして対価を支払う必要がある（ステップＳ５０７）。対価としては、現金をＩＤＰ２経由で直接支払ったり、ＳＰ３ｎ独自のポイントを加算したりする。ＳＰ３ｎ独自のポイントの場合、又は複数のＳＰ３でポイントシステムを共有する場合は、ＩＤＰ２のＵｓｅｒ１の個人情報としてポイントを持たせ、ＳＰ３からの依頼によりポイントの増減を行うことも可能である。
【００８２】
以上、匿名でＣＲＭを行う方法について述べてきたが、その利点について説明する。
【００８３】
（ｉ）匿名で処理することによって、プライバシ侵害が起こりにくいため、ＳＰはこれまで以上に顧客情報の収集が可能になる（与信者による結託がなければプライバシ侵害は起こらない）。
【００８４】
（ｉｉ）ＳＰは収集したプライバシ情報を、安全に管理するのに非常に大きなコストがかかると考えられ、このようなプライバシ情報が流出した際、一度流出した情報は二度と消すことができないため非常に大きな問題になるが、匿名処理をすることによって、顧客ＩＤであるＵＩＤを発行しなおすことによって流出した情報を無力化することが可能である。
【００８５】
（ｉｉｉ）ＳＰが個人を特定可能なプライバシ情報（住所・氏名）を収集する目的は、ＤＭや広告メールを届けるということも含まれていると考えるが、匿名システムとして、個人を特定可能なプライバシ情報を入手しなくても、ＤＭや広告メールを届けることが可能となる。
【００８６】
［ＣＲＭサービスを行う会社がＣＲＭを行う方法］
上記では、ＳＰが顧客の購入履歴などを用いてＣＲＭを行う例を示したが、購入履歴などの情報はＳＰだけのものではなく、購入したＵｓｅｒ自身の情報でもある。このような履歴情報はＣＲＭを行う上で非常に価値のある情報なので、Ｕｓｅｒ自身が売り対価を受け取ることが可能である。ここでは、ＣＲＭを行いその結果を売り、その利益を、情報を提供してくれた顧客に還元する方法について図１１を参照して説明する。なお、ここでは前述した匿名によるオンラインショッピングが実施されている状況であるとする。
【００８７】
まず、Ｕｓｅｒ１は、ＣＲＭ５にログインする（ステップＳ６０１）。なお、このタイミングで前述した顧客登録を行ってもよい。登録の際には、Ｕｓｅｒ１はＣＲＭ５に対し個人を特定しない範囲でＣＲＭを行うのに必要な情報（性別、居住地域、年齢もしくは年齢層、趣味、嗜好など）を登録する。性別、居住地域、年齢もしくは年齢層、趣味、嗜好などの情報は、与信者により証明してもらうことも可能である。また、Ｕｓｅｒ１は自分が提供した情報の利用制約条件を設定したり、受け取るＤＭや広告メールの種類を指定したりしてもよい。匿名配送（Ｄｅｌｉｖｅｒｙ）を用いる場合は前述のステップＳ５０２及びＳ５０３の手続を行う。
【００８８】
次に、Ｕｓｅｒ１は、ＳＰ３からサービスを受けた場合に受け取るレシート（前記ステップＳ４０８参照）などを提示することにより、自分の購買履歴などのサービス履歴をＣＲＭ５に提供する（ステップＳ６０２）。ＣＲＭ会社は、複数のＵｓｅｒ１から提供された情報を蓄積し、これらの情報を用いたＣＲＭサービスをＳＰ３などに提供する。
【００８９】
次に、ＳＰ３は、自身が欲するＣＲＭの方法を指定し、ＣＲＭ５に対し処理を依頼する（ステップＳ６０３）。ＣＲＭ５は、ＳＰ３からの依頼に基づき、ＣＲＭを行う。このとき、Ｕｓｅｒ１が情報の利用制約条件がＳＰ３の提示する条件（支払われる対価など）と合うかどうかを判断してからＣＲＭに用いる。
【００９０】
次に、ＣＲＭ５は、上記のＣＲＭの結果をＳＰ３に送信する（ステップＳ６０４）。ＳＰ３は受け取ったＣＲＭの結果を基にして、販売戦略を練ったり、どの顧客に対してどのようなＤＭや広告メールを送ったらよいかを判断することができる。
【００９１】
次に、ＳＰ３は、ＣＲＭの結果に基づいてＤＭや広告メールを送りたいユーザ層を指定し、ＣＲＭ５に対して発送を依頼する（ステップＳ６０５）。ＣＲＭ５は、ＳＰ３から指定されたユーザ層の設定を確認し、ＤＭや広告メールを受け取ることを同意しているユーザに対して発送する（ステップＳ６０６）。匿名配送を用いる場合は、前記ステップＳ５０５及びＳ５０６の手続を行う。
【００９２】
次に、ＣＲＭ５はＩＤＰ２を通して、Ｕｓｅｒ１との契約に基づき、ＳＰ３から支払われた対価の支払いを行う（ステップＳ６０７）。
【００９３】
以上のような処理により、Ｕｓｅｒ１は自分の情報を提供したときだけではなく、その情報が利用されるたびに対価を受け取ることが可能で、しかも、一度提供した情報を、自分の意思により取り戻すことが可能となる。
【００９４】
［ＣＲＭサービスを行う会社がＣＲＭを行うがＣＲＭに履歴情報を蓄積しない方法］
上記のように、ＣＲＭサービス会社に履歴情報を蓄積してＣＲＭを行う場合、処理効率はよいが、履歴が大量に蓄積するためにユーザの行動パターンからある程度ユーザ特定が可能となり、匿名性が保てなくなってしまうおそれがある。そこで、ＣＲＭサービス会社に履歴情報を蓄積することなく、ＣＲＭを行う方法について図１２を参照して説明する。なお、ここでは前述した匿名によるオンラインショッピングが実施されている状況であるとする。
【００９５】
ここで、Ｕｓｅｒ１には、予めホームサーバなどに情報提供サーバ（図示省略）を設けておき、個人を特定しない範囲でＣＲＭを行うのに必要な情報（性別、居住地域、年齢もしくは年齢層、趣味、嗜好など）を登録しておく。性別、居住地域、年齢もしくは年齢層、趣味、嗜好などの情報は与信者による証明を受けておいてもよい。また、ＳＰ３などから受けたサービス履歴情報を前記情報提供サーバに蓄積しておく。Ｕｓｅｒ１は、すべての情報にそれぞれ利用制約条件を付けてもよい。さらに、情報提供サーバには、自身が契約するＣＲＭ５からのアクセスのみを受け付けるように設定しておく（ステップＳ７００）。
【００９６】
次に、Ｕｓｅｒ１はＣＲＭ５に顧客登録を行い、情報提供条件、受け取るＤＭや広告メールの種類を指定しておく。なお、匿名配送（Ｄｅｌｉｖｅｒｙ）を用いる場合は、前記ステップＳ５０２及びＳ５０３の手続を行っておく。
【００９７】
まず、ＳＰ３は、提供してもらう情報を暗号化するための公開鍵暗号方式の鍵ペアＰＫｍ，ＳＫｍを生成し、公開鍵ＰＫｍをＣＲＭ５に送信する（ステップＳ７０１）。また、情報提供に対する対価の条件（例えば「情報量として１０円支払う」など）及び情報を収集するための条件（例えば、「２０歳から３０歳までで関東圏に住んでいる人の過去１年間の履歴情報及び趣味」など）も送信する。
【００９８】
次に、ＣＲＭ５は、ユーザの登録条件とＳＰ３が提示する条件を照らし合わせ、条件に合うユーザに対し情報提供依頼を行い、ＳＰ３から受け取った公開鍵ＰＫｍをユーザの情報提供サーバに送信する（ステップＳ７０２）。
【００９９】
次に、Ｕｓｅｒ１の情報提供サーバは、ユーザが設定している条件に基づいて履歴情報などの提供情報を抽出し、ＳＰ３の公開鍵ＰＫｍで暗号化してＣＲＭ５に送り返す（ステップＳ７０３）。
【０１００】
次に、ＣＲＭ５は、それぞれの情報提供サーバから返信されたユーザの情報を、自身の管理する顧客ＩＤを隠蔽する形で情報ＩＤを付け、ＳＰ３に対して提供する（ステップＳ７０４）。ここで、受信した情報はＳＰ３の公開鍵ＰＫｍで暗号化されているため、ＣＲＭ５はユーザが提供した情報を見ることはできない。
【０１０１】
次に、ＳＰ３は、ＣＲＭ５から受け取った情報を秘密鍵ＳＫｍを用いてデコードし、情報を得る（ステップＳ７０５）。ＳＰ３は、この情報を基にＣＲＭを行うことができる。ＤＭや広告メールを送りたい場合、ＳＰ３はＣＲＭ５に対し情報ＩＤを用いてユーザを指定して発送を依頼する。
【０１０２】
ＣＲＭ５は、指定された情報ＩＤから顧客ＩＤを割り出し、ユーザがＤＭや広告メールの受信を許可している場合、発送を行う（ステップＳ７０６）。なお、匿名配送（Ｄｅｌｉｖｅｒｙ）をもちいる場合は、前記ステップＳ５０５及びＳ５０６の手続を行う。
【０１０３】
次に、ＣＲＭ５は、ＩＤＰ２を介して、ＳＰ３から支払われた情報提供に対する対価の支払を行う（ステップＳ７０７）。
【０１０４】
このような処理により、Ｕｓｅｒ１は情報サーバを構築しなければならないが、該サーバを構築することにより、個人の行動履歴を集約した形で他者に公開することなく、必要な情報を必要な場所だけに提示し、対価を得ることが可能となる。
【０１０５】
［匿名での懸賞付アンケートサイトの実施方法］
インターネット上で懸賞の応募や、懸賞付アンケートを実施している場合、個人情報の収集が目的となっているが多々あるが、懸賞を受け取るために多くのユーザはそれとは気付かずに個人情報を提示してしまっていると考えられる。そこで、匿名で懸賞付アンケートに応募し、匿名のまま懸賞を受け取る方法について図１３を参照して説明する。なお、ここではＵｓｅｒ１は前述した方法によりＵＩＤを取得しているものとする。
【０１０６】
まず、Ｕｓｅｒ１は、懸賞付アンケートサイトであるＳＰ３にログインする（ステップＳ８０１）。なお、このタイミングで前述した顧客登録（ＵＩＤの発行・取得）を行ってもよい。
【０１０７】
次に、ＳＰ３は、アンケートの内容及び懸賞の内容についてＵｓｅｒ１に通知する（ステップＳ８０２）。
【０１０８】
次に、予め、Ｄｅｌｉｖｅｒｙ４から配送用ＩＤとしてＤＩＤの発行を受けていない場合、又はＤＩＤを使い果たしてしまっている場合、Ｕｓｅｒ１はＤｅｌｉｖｅｒｙ４にログインし、配送用ＩＤとしてＤＩＤの発行を依頼する（ステップＳ８０３）。また、ＳＰ３ｎが取り扱うことのできるＤｅｌｉｖｅｒｙ４に登録がない場合、Ｕｓｅｒ１はこの時点でＤｅｌｉｖｅｒｙ４に対して登録手続を行い、配送容ＩＤの発行を依頼してもよい。このＤＩＤには、氏名・住所などの情報を関連付ける。Ｄｅｌｉｖｅｒｙ４は、前記ステップＳ８０３において発行依頼があった場合、Ｕｓｅｒ１にＤＩＤを払い出し、ＤＩＤに発送用の情報（住所・氏名など）を関連付ける（ステップＳ８０４）。
【０１０９】
次に、Ｕｓｅｒ１は、個人を特定しない範囲で必要な個人情報（性別、居住地域、年齢もしくは年齢層、趣味、嗜好など）を含んだ形でアンケートに答え、その結果をＳＰ３に送信する（ステップＳ８０５）。性別、居住地域、年齢もしくは年齢層、趣味、嗜好などの情報は与信者により証明してもらうことも可能である。同時に、懸賞の配布先指定として、ＤＩＤ及び利用目的（懸賞の送付）・有効期限（重複利用を防ぐため）・利用者（ここではＳＰ３ｎ）などをＤＩＤに対して作成した秘密鍵ＳＫｎを用いて署名を行った許可書をＳＰ３ｎに送信する。
【０１１０】
次に、ＳＰ３ｎは、懸賞品の送付依頼を、送付先であるＤＩＤ及び許可書、送付する目的などを添えてＤｅｌｉｖｅｒｙ４に送信する（ステップＳ８０６）。
【０１１１】
次に、Ｄｅｌｉｖｅｒｙ４は、ＳＰ３ｎから受け取ったＤＩＤｍから公開鍵ＰＫｍを特定し、許可書をデコードし、利用条件（利用者、利用目的、有効期限など）が守られているかを確認し、依頼物をＵｓｅｒ１に送付する（ステップＳ８０７）。このとき、依頼物は梱包されているのでＤｅｌｉｖｅｒｙ４は内容を知ることができない。
【０１１２】
なお、懸賞品として金銭やポイントを支払う場合、前記ステップＳ８０６においてＩＤＰ２経由で金銭を支払ったりポイントを加算したりすればよい（図のステップＳ８０６’）。
【０１１３】
このようにして、Ｕｓｅｒ１は匿名で懸賞を受け取ることができ、ＳＰ３は個人を特定できないが、ＣＲＭを行うには十分な個人情報を入手することができ、個人情報流出の問題についても、流出した情報のみでは個人を特定することができないので、売買される心配もない。
【０１１４】
以上詳述したように、本発明によれば、利用者は各種サービスを匿名で教示することができるのでプライバシ保護に優れたものとなる。また、利用者は、各種サービスを実施する者及び通信相手先の利用者に対して、必要最小限の個人情報のみ提示すればよいので、個人情報が特定の者に集中することがない。これにより、流出した個人情報から利用者個人を特定することが困難になるので、取引等の安全性が向上する。また、個人情報が流出した場合であっても、各ユーザＩＤの振り直しを行うことにより、流出情報を無効化することができる。
【０１１５】
以上、本発明の実施形態について詳述したが本発明はこれに限定されるものではない。例えば、上記実施形態では、与信者（サービス提供者）として、決済業務を行うもの、配送業務を行うもの、ＣＲＭを行う者を例示したが、他のサービスであっても本発明を適用できることは言うまでもない。
【０１１６】
また、図７を参照して前述したＩＤＰによるＵＩＤの発行方法、及び、図８を参照して前述した当該ＵＩＤによる認証方法の変形例について、図１４を参照して説明する。図１４は他の例に係るＵＩＤの発行及び認証プロトコルを説明するシーケンスチャートであり、図１４に示す与信者２５は図７及び図８のＩＤＰ２に相当し、利用者１５は図８のＳＰ３に相当する。
【０１１７】
ここでは、初期状態として、Ｕｓｅｒ１は、与信者２５用に、与信者２５用のＩＤであるＩＤｙ−ｕと、当該ＩＤｙ−ｕ用の証明書ＰＫＣｙ−ｕ及び秘密鍵ＳＫｙ−ｕを既に備えているとする。また、与信者２５は、自身のＩＤであるＩＤｙと、当該ＩＤｙ用の証明書ＰＫＣｙ及び秘密鍵ＳＫｙを既に備えているとする。さらに、利用者１５は、与信者用２５用に、与信者２５用のＩＤであるＩＤｙ−ｒと、当該ＩＤｙ−ｒ用の証明書ＰＫＣｙ−ｒ及び秘密鍵ＳＫｙ−ｒを備えるとともに、自身のＵＩＤであるＩＤｙ−αと、当該ＩＤｙ−α用の証明書ＰＫＣｙ−α及び秘密鍵ＳＫｙ−αを既に備えているとする。
【０１１８】
まず、Ｕｓｅｒ１は、与信者２５に対して利用者１５用のＵＩＤの発行を要求する（ステップＳ９０１）。具体的には、まず与信者２５用のＩＤｙ−ｕを提示して与信者２５にログインし、ＵＩＤの発行要求書を与信者２５に送信する。なお、このＵＩＤの発行要求書は、必要に応じて秘密鍵ＳＫｙ−ｕで電子署名を施す。
【０１１９】
与信者２５は、Ｕｓｅｒ１から発行要求書を受信すると、当該発行要求書に電子署名が付されている場合にはその電子署名を検証する。次いで、与信者２５は、ＵＩＤの発行要求に応じてＵｓｅｒ１の利用者１５用のＵＩＤであるＩＤｙ−βを生成し、このＩＤｙ−βを含む登録書をＵｓｅｒ１に送信する（ステップＳ９０２）。このとき、Ｕｓｅｒ１に送信する登録書には、必要に応じて、与信者２５の秘密鍵ＳＫｙによる電子署名を付する。
【０１２０】
Ｕｓｅｒ１は、与信者２５から登録書を受信すると、当該登録書に電子署名が付されている場合にはその電子署名を検証する。次いで、Ｕｓｅｒ１は、当該ＩＤｙ−β用の秘密鍵ＳＫｙ−β及び公開鍵ＰＫｙ−βを作成し（ステップＳ９０３）、このＩＤｙ−β及び公開鍵ＰＫｙ−βの組を登録するよう、当該ＩＤｙ−β及び公開鍵ＰＫｙ−βの組を含む鍵登録依頼書を与信者２５に送信する（ステップＳ９０４）。この時、与信者２５に送信する鍵登録依頼書には秘密鍵ＳＫｙ−ｕで電子署名を施す。
【０１２１】
与信者２５は、Ｕｓｅｒ１から受信した鍵登録依頼書に付された電子署名を検証し（ステップＳ９０５）、この鍵登録依頼書を所定の記憶手段に保存する（ステップＳ９０６）。次いで、与信者２５は、ＩＤｙ−β用の証明書ＰＫＣｙ−βを生成する（ステップＳ９０７）。この証明書ＰＫＣｙ−βは、前記ステップＳ９０２で生成したＵＩＤであるＩＤｙ−β，該ＵＩＤに対応した公開鍵ＰＫｙ−β，発行者を特定するための与信者２５のＩＤｙ，該ＩＤに対応した公開鍵ＰＫｙ，与信内容，有効期限などの情報に、与信者２５の秘密鍵ＳＫｙで電子署名を付したものである。次いで、与信者２５は、Ｕｓｅｒ１のＵｓｅｒ情報として証明書ＰＫＣｙ−βを所定の記憶手段に登録する（ステップＳ９０８）。次いで、与信者２５は、当該証明書ＰＫＣｙ−βをＵｓｅｒ１に送信する（ステップＳ９０９）。
【０１２２】
Ｕｓｅｒ１は、証明書ＰＫＣｙ−βを受信すると当該ＰＫＣｙ−βに付された電子署名を検証する（ステップＳ９１０）。以降、Ｕｓｅｒ１が当該ＩＤｙ−βを用いて利用者１５からサービス提供を受ける場合、このＩＤｙ−β及びＰＫＣｙ−βを利用者１５に提示してログイン（相互認証）を行えばよい（ステップＳ９１１）。
【０１２３】
このような手順により、Ｕｓｅｒ１が、与信者２５から与信を受けたＵＩＤであるＩＤｙ−βを用いて利用者１５と契約を行った後、利用者１５に対して当該ＵＩＤは自分のものではないと主張するという事態を未然に防止できる。また、与信者２５が、Ｕｓｅｒ１から発行依頼を受けずに作成したＵＩＤをＵｓｅｒ１のものとして登録し、このＵＩＤを用いて利用者１５との間で架空契約を行い、その契約を元に課金等の代行処理により架空請求等を行うという事態を未然に防止できる。さらに、プロトコルの途中で中断が生じた場合であっても、Ｕｓｅｒ１が当該ＵＩＤを利用できないだけで、与信者２５や利用者１５が不正に利用することも未然に防止できる。
【０１２４】
次に、図６を参照して前述したＳＰによるＵＩＤの発行方法及び当該ＵＩＤによる認証方法の変形例について図１５及び図１６を参照して説明する。図１５及び図１６は他の例に係るＵＩＤの発行及び認証プロトコルを説明するシーケンスチャートであり、各図に示す与信者２５は図６のＩＤＰ２に相当し、利用者１５は図６のＳＰ３に相当する。なお、各図及び以下の記載において記号Ｘは利用者１５を表す記号ｒ又はαの何れかを意味する。
【０１２５】
ここでは、初期状態として、Ｕｓｅｒ１は、与信者２５用に、与信者２５用のＩＤであるＩＤｙ−ｕと、当該ＩＤｙ−ｕ用の証明書ＰＫＣｙ−ｕ及び秘密鍵ＳＫｙ−ｕを既に備えているとする。また、与信者２５は、自身のＩＤであるＩＤｙと、当該ＩＤｙ用の証明書ＰＫＣｙ及び秘密鍵ＳＫｙを既に備えているとする。さらに、利用者１５は、与信者用２５用に、与信者２５用のＩＤであるＩＤｙ−ｒと、当該ＩＤｙ−ｒ用の証明書ＰＫＣｙ−ｒ及び秘密鍵ＳＫｙ−ｒを備えるとともに、自身のＵＩＤであるＩＤｙ−αと、当該ＩＤｙ−α用の証明書ＰＫＣｙ−α及び秘密鍵ＳＫｙ−αを既に備えているとする。
【０１２６】
まず、Ｕｓｅｒ１は、利用者１５に対してＵＩＤの発行を要求する（ステップＳ１００１）。なお、ここではＵｓｅｒ１は利用者１５に対してログインすることなく発行要求のみを行う。
【０１２７】
利用者１５は、Ｕｓｅｒ１からの発行要求に応じてＵｓｅｒ１の利用者１５用のＵＩＤであるＩＤｘ−γを生成し、このＩＤｘ−γを含む登録書をＵｓｅｒ１に送信する（ステップＳ１００２）。このとき、Ｕｓｅｒ１に送信する登録書には、必要に応じて、利用者１５の秘密鍵ＳＫｙ−ｘによる電子署名を付する。
【０１２８】
Ｕｓｅｒ１は、利用者１５から登録書を受信すると、当該登録書に電子署名が付されている場合にはその電子署名を検証する。次いで、Ｕｓｅｒ１は、当該ＩＤｘ−γ用の秘密鍵ＳＫｘ−γ及び公開鍵ＰＫｘ−βを作成し（ステップＳ１００３）、このＩＤｘ−γ及び公開鍵ＰＫｘ−γの組を登録するよう、当該ＩＤｘ−γ及び公開鍵ＰＫｘ−γの組を含む鍵登録依頼書を利用者１５に送信する（ステップＳ１００４）。
【０１２９】
利用者１５は、Ｕｓｅｒ１から鍵登録依頼書を受信すると、ＩＤｘ−γ用の証明書ＰＫＣｘ−γを生成する（ステップＳ１００５）。この証明書ＰＫＣｘ−γは、前記ステップＳ１００２で生成したＵＩＤであるＩＤｘ−γ，該ＵＩＤに対応した公開鍵ＰＫｘ−γ，発行者を特定するための利用者１５のＩＤｙ−ｘ，該ＩＤに対応した公開鍵ＰＫｙ−ｘ，与信内容，有効期限などの情報に、利用者１５の秘密鍵ＳＫｙ−ｘで電子署名を付したものである。次いで、利用者１５は、Ｕｓｅｒ１の顧客情報として証明書ＰＫＣｘ−γを所定の記憶手段（顧客ＤＢ）に登録する（ステップＳ１００６）。次いで、利用者１５は、当該証明書ＰＫＣｘ−γをＵｓｅｒ１に送信する（ステップＳ１００７）。
【０１３０】
Ｕｓｅｒ１は、証明書ＰＫＣｘ−γを受信すると当該ＰＫＣｘ−γに付された電子署名を検証する（ステップＳ１００８）。次いで、Ｕｓｅｒ１は、与信者２５に対して利用者１５が発行したＵＩＤであるＩＤｘ−γ及び証明書ＰＫＣｘ−γの登録依頼を行う（ステップＳ１００９）。具体的には、まず利用者１５用のＩＤであるＩＤｙ−ｕを用いて与信者２５にログインし、前記ＩＤｘ−γ及び証明書ＰＫＣｘ−γを含む登録依頼書を送信する。ここで、当該登録依頼書には秘密鍵ＳＫｙ−ｕで電子署名を施す。
【０１３１】
与信者２５は、Ｕｓｅｒ１から登録依頼書を受信すると、まず当該登録依頼書に付された電子署名を検証し（ステップＳ１０１０）、当該登録依頼書を所定の記憶手段に保存する（ステップＳ１０１１）。次いで、与信者２５は、Ｕｓｅｒ１のＵｓｅｒ情報として証明書ＰＫＣｘ−γを所定の記憶手段に記憶する（ステップＳ１０１２）。次いで、与信者２５は、証明書ＰＫＣｘ−γの登録が完了した旨をＵｓｅｒ１に通知する（ステップＳ１０１３）。
【０１３２】
以降、Ｕｓｅｒ１が当該ＩＤｘ−γを用いて利用者１５からサービス提供を受ける場合、Ｕｓｅｒ１は当該ＩＤｘ−γを提示して利用者１５にログイン（相互認証）する（ステップＳ１０１４）。このとき必要に応じて証明書ＩＤｘ−γも送信する。
【０１３３】
利用者１５は、Ｕｓｅｒ１が提示したＩＤｘ−γが与信者２５に登録されているかを確認するために利用者２５に登録確認を依頼する（ステップＳ１０１５）。具体的には、利用者１５は自身の与信者２５用のＩＤであるＩＤｙ−ｒを用いて与信者２５にログインし、その後にＩＤｘ−γの登録状況の確認依頼を送信する。
【０１３４】
与信者２５は、利用者１５からの登録状況確認依頼に応じて登録確認を行う（ステップＳ１０１６）。具体的には、所定の記憶手段にＩＤｘ−γの証明書ＰＫＣｘ−γが登録されているかを確認するとともに、該証明書ＰＫＣｘ−γの発行者のＩＤが利用者１５のＩＤであるＩＤｙ−ｒ又はそのＵＩＤであるＩＤｙ−αであるかを確認する。その後に与信者２５は、当該確認結果を利用者１５に送信する（ステップＳ１０１７）。
【０１３５】
このような手順によれば、図１４を参照して前述した変形例を同様の効果を得ることができる。
【０１３６】
次に、図９におけるＵｓｅｒ１とＳＰ３との間における匿名での売買契約に関して電子署名を用いた変形例について図１７を参照して説明する。図１７は匿名売買契約方法を説明するシーケンスチャートであり、同図に示す与信者２５は図９のＩＤＰ２に相当し、利用者１５は図９のＳＰ３に相当する。なお、同図及び以下の記載において記号Ｘは利用者１５を表す記号ｒ又はαの何れかを意味する。
【０１３７】
ここでは、初期状態として、Ｕｓｅｒ１は、与信者２５用に、与信者２５用のＩＤであるＩＤｙ−ｕと、当該ＩＤｙ−ｕ用の証明書ＰＫＣｙ−ｕ及び秘密鍵ＳＫｙ−ｕと、利用者１５用に、利用者１５用のＵＩＤであるＩＤｘ−γと、当該ＩＤｘ−γ用の証明書ＰＫＣｘ−γ及び秘密鍵ＳＫｘ−γとを既に備えているとする。また、与信者２５は、自身のＩＤであるＩＤｙと、当該ＩＤｙ用の証明書ＰＫＣｙ及び秘密鍵ＳＫｙを既に備えているとする。さらに、利用者１５は、与信者用２５用に、与信者２５用のＩＤであるＩＤｙ−ｒと、当該ＩＤｙ−ｒ用の証明書ＰＫＣｙ−ｒ及び秘密鍵ＳＫｙ−ｒを備えるとともに、自身のＵＩＤであるＩＤｙ−αと、当該ＩＤｙ−α用の証明書ＰＫＣｙ−α及び秘密鍵ＳＫｙ−αを既に備えているとする。なお、Ｕｓｅｒ１が有する利用者１５用のＵＩＤは、図１４を参照して前述した方法を用いて与信者２５が発行したものであっても、図１５及び図１６を参照して前述した方法を用いて利用者１５が発行したものであっても良い。
【０１３８】
まず、Ｕｓｅｒ１は、利用者１５に対して利用者１５用のＩＤｘ−γを用いてログイン（相互認証）する（ステップＳ１１０１）。利用者１５は、Ｕｓｅｒ１に対して提供するサービスの内容を提示する（ステップＳ１１０２）。このサービスの内容の提示としては、例えば、利用者１５がオンラインショッピングサイトであれば商品リストの提示などが挙げられる。
【０１３９】
Ｕｓｅｒ１は、利用者１５から受信したサービス内容の中から利用したいサービスを選択し（ステップＳ１１０３）、発注書を送信する（ステップＳ１１０４）。この発注書は、要求するサービスリストを含む情報からなり、必要に応じて秘密鍵ＳＫｘ−γで電子署名を施したものである。
【０１４０】
利用者１５は、Ｕｓｅｒ１からの発注書に応じて売買手続を行う（ステップＳ１１０５）。具体的には、まず発注書に電子署名が付されている場合、当該電子署名を検証する。次いで、見積書及び請求書を作成する。この見積書は、利用者１５のＩＤであるＩＤｙ−ｘ，伝票番号，サービス明細，見積有効期限などの情報に、秘密鍵ＳＫｙ−ｘにて電子署名を施したものである。また、請求書は、利用者１５のＩＤであるＩＤｙ−ｘ，伝票番号，請求金額などの情報に、秘密鍵ＳＫｙ−ｘにて電子署名を施したものである。そして利用者１５は、作成した見積書及び請求書をＵｓｅｒ１に送信する（ステップＳ１１０６）。
【０１４１】
Ｕｓｅｒ１は、利用者１５から受信した書類（見積書及び請求書）を検証する（ステップＳ１１０７）。具体的には、見積書及び請求書に付された電子署名を検証する。また、サービス明細や請求金額等を確認する。次いで、Ｕｓｅｒ１は、当該売買契約に同意する場合、請求書に秘密鍵ＳＫｘ−γにて電子署名を施すことにより支払同意書を生成し（ステップＳ１１０８）、この支払同意書を利用者１５に送信する（ステップＳ１１０９）。
【０１４２】
利用者１５は、Ｕｓｅｒ１から受信した支払同意書に付された電子署名を検証し（ステップＳ１１１０）、受領書を作成する（ステップＳ１１１１）。この受領書は、利用者１５のＩＤであるＩＤｙ−ｘ，伝票番号，請求金額などの情報に、秘密鍵ＳＫｙ−ｘにて電子署名を施したものである。次いで、利用者１５は、この受領書をＵｓｅｒ１に送信する（ステップＳ１１１２）。Ｕｓｅｒ１は、利用者１５から受信した受領書に付された電子署名を検証する（ステップＳ１１１３）。
【０１４３】
また、利用者１５は、与信者２５に対して当該売買契約に係る決済を依頼する（ステップＳ１１１４）。具体的には、利用者１５は、自身の与信者２５用のＩＤであるＩＤｙ−ｒを用いて与信者２５にログイン（相互認証）する。そして、Ｕｓｅｒ１が秘密鍵ＳＫｘ−γで電子署名を施した請求書（支払同意書）を与信者２５に送信する。
【０１４４】
与信者２５は、利用者１５から受信した決済依頼に応じて決済代行を行う（ステップＳ１１１５）。具体的には、利用者１５から受信した請求書に付された電子署名を検証するとともに、請求書に含まれるＩＤｙ−ｘが依頼者であるか否かを検証する。次いで、与信者２５は、利用者１５に対して決済完了通知を送信するとともに（ステップＳ１１１６）、Ｕｓｅｒ１に対して決済代行を行う（ステップＳ１１１７）。具体的には、ＩＤｙ−ｕを有するＵｓｅｒ１に対して請求明細を送付するとともに、口座引落や上位与信者に対する請求処理を行う。なお、このステップＳ１１１７の処理は本売買契約の手順とは非同期で行ってもよい（例えば月末処理として行う）。
【０１４５】
以上のような手順により、Ｕｓｅｒ１がお金を払ったのに利用者１５から商品が受け取れないという事態や、利用者１５がＵｓｅｒ１に商品を送ったのにＵｓｅｒ１からお金を受け取れないという事態を未然に防止できる。また、プロトコルの途中で中断が生じた場合であっても、契約が成立しないだけであり、不正な処理の発生を防止できる。
【０１４６】
なお、前記ステップＳ１１１７において上位の与信者に対して請求する場合、Ｕｓｅｒ１と与信者２５は、上位与信者を介して課金代行を行っている必要がある。この際、与信者２５が月末処理等でＵｓｅｒ１に電子署名入り請求書を送信
し、前記ステップＳ１１０８と同様の電子署名を受ける方法と、この電子署名入りの書類を用いず請求のみを行う方法がある。前者の場合、個々の与信者２５単位で署名検証を行うことで不正検出が可能である。一方、後者の場合、個々の与信者２５で不正検出はできない。そこで、Ｕｓｅｒ１が最上位の与信者に告発等をし、最上位の与信者から下位の与信者に順次、電子署名の提示を請求していくことにより、最下位の与信者が保存している電子署名を得ることができるので、この電子署名を確認することによって不正検出が可能となる。ただしこの場合、Ｕｓｅｒ１の情報が名寄せ（Ｕｓｅｒ１の名の下に当該Ｕｓｅｒ１の個人情報を集約すること）される危険が生じる。
【図面の簡単な説明】
【０１４７】
【図１】本発明の基本原理を説明する図
【図２】本発明の基本原理の他の態様を説明する図
【図３】本発明の基本原理の他の態様を説明する図
【図４】本発明の基本原理の他の態様を説明する図
【図５】本発明の基本原理の他の態様を説明する図
【図６】ＳＰがＵＩＤを発行する流れを説明する図
【図７】ＩＤＰがＵＩＤを発行する流れを説明する図
【図８】ＰＫＩによる認証の流れ説明する図
【図９】オンラインショッピングの流れを説明する図
【図１０】ＳＰがＣＲＭを行う流れを説明する図
【図１１】ＣＲＭサービス会社がＣＲＭを行う流れを説明する図
【図１２】他の例に係るＣＲＭサービス会社がＣＲＭを行う流れを説明する図
【図１３】懸賞付アンケートを行う流れを説明する図
【図１４】他の例に係るＵＩＤの発行及び認証プロトコルを説明するシーケンスチャート
【図１５】他の例に係るＵＩＤの発行及び認証プロトコルを説明するシーケンスチャート
【図１６】他の例に係るＵＩＤの発行及び認証プロトコルを説明するシーケンスチャート
【図１７】匿名売買契約方法を説明するシーケンスチャート
【符号の説明】
【０１４８】
１…Ｕｓｅｒ（商品の購買などを行う顧客（利用者）の端末）、２…ＩＤＰ（課金決済系に関する与信者（サービス提供者）の端末）、３…ＳＰ（オンラインショップや実際の店舗など顧客にサービスや商品を提供する者（利用者）の端末）、４…Ｄｅｌｉｖｅｒｙ配送に関する与信者（サービス提供者）の端末、５…ＣＲＭ（ＣＲＭサービスを行う与信者（サービス提供者）の端末）
【図１】
2005050330.tif 000003
【図２】
2005050330.tif 000004
【図３】
2005050330.tif 000005
【図４】
2005050330.tif 000006
【図５】
2005050330.tif 000007
【図６】
2005050330.tif 000008
【図７】
2005050330.tif 000009
【図８】
2005050330.tif 000010
【図９】
2005050330.tif 000011
【図１０】
2005050330.tif 000012
【図１１】
2005050330.tif 000013
【図１２】
2005050330.tif 000014
【図１３】
2005050330.tif 000015
【図１４】
2005050330.tif 000016
【図１５】
2005050330.tif 000017
【図１６】
2005050330.tif 000018
【図１７】
2005050330.tif 000019