(57)【要約】【課題】匿名によるサービス提供の要求を受けると、サービス提供者は誰からのサービス提供の要求か判らないため、サービスを受けた会員に対して当該サービスに応じた、例えばサービス料金や物販であれば購入代金に応じたポイントを付与することができない。【解決手段】会員は、会員装置を用いて自装置の画面上に表示された商品またはサービスのうち、自己が要求する商品またはサービスを選択し、この選択した商品またはサービスの要求のための要求情報を会員装置の秘密鍵に基づいて生成する。検証者は、検証者装置を用いて、この生成された要求情報を前記会員装置の対応する公開鍵で検証する。この検証の結果、特に問題ないと判断された場合に、提供者装置では、会員の使用する会員装置に対して、当該選択された商品またはサービスの提供を開始する。【選択図】図２
2008245023.tif 000002
【特許請求の範囲】
【請求項１】
追跡機能を有するグループ署名方式により、商品またはサービスからなる販売対象の匿名注文と、前記匿名注文に応じた販売対象の販売または提供とを実行するために、少なくとも１つの会員装置及び検証装置からなる匿名注文システムであって、
前記会員装置は、
当該会員装置を使用する会員の秘密鍵を記憶する公開鍵記憶手段と、
前記公開鍵記憶手段に記憶される秘密鍵に基づいて前記選択された商品またはサービスの販売または提供対象の商品サービス要求情報を生成する商品サービス要求情報生成手段と、
前記商品サービス要求情報生成手段により生成された商品サービス要求情報に対して、前記検証装置による検証の結果、問題ないと判断された場合に、当該検証装置からの商品またはサービスの販売または提供を受理する商品サービス受理手段と、
前記検証装置による販売及び提供対象の商品またはサービスの内容を表示するとともに、当該会員に当該内容の選択を促す商品サービス選択表示部と、
前記検証装置は、
前記会員装置を使用する会員のグループ公開鍵を記憶するグループ公開鍵記憶手段と、
前記会員装置から送信される商品サービス要求情報を検証する商品サービス要求情報検証手段と、
前記商品サービス要求情報検証手段による検証の結果、問題ないと判断された場合に、前記会員装置に対して前記選択された商品またはサービスの販売または提供を実行する商品サービス販売提供手段と、
を備えることを特徴とする匿名注文システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、匿名で受けたサービスの履歴を管理する匿名注文システムに関する。
【背景技術】
【０００２】
最近、サービスを提供して決済するサービス提供システムでは、匿名の会員を認証可能なグループ署名方式を用いたものが知られている（例えば、非特許文献１〜３参照）。この種のサービス提供システムは、大まかには次の（１）〜（３）のように運営される。
【０００３】
（１）管理者は、予め会員の申し込みにより、会員の決済情報などの個人情報と、会員がどのグループに所属するかと、をグループ署名方式に基づいて登録する。なお、グループ署名方式の詳細については後述する。
【０００４】
（２）登録の後、匿名の会員は、サービスの要求と共に、所属しているグループをサービス提供者に通知する。このとき、サービス提供者は、匿名の会員に関し、“誰が”という個人情報を入手不可能となっている。サービス提供者は、会員が所属しているグループのうち、サービスを利用可能なグループの情報を返す。
【０００５】
（３）匿名の会員は、サービスを利用可能なグループのうち、選択したグループによるグループ署名を生成してサービス提供者に送る。サービス提供者は、このグループ署名を検証した後、そのグループが無効とされていなければ、要求されたサービスに相当するサービスデータを匿名の会員に送る。匿名の会員は、このサービスデータに基づいてサービスの提供を受ける。
【０００６】
図１はこのようなサービス提供システムの概要を示す模式図である。なお、前述した説明中、会員は会員とも呼ばれ、サービス提供者は検証者とも呼ばれる。
【０００７】
管理者装置１００は、会員登録後に会員装置２００となる会員端末からの要求に基づいて、要求されたサービスを利用可能なグループに所属する旨を証明するためのメンバ証明書を発行する機能を有し、会員情報を管理するサーバである。会員情報とは、会員の公開鍵と、決済情報等の個人情報と、メンバ証明書とを含み、サービスを利用した際のグループ署名に基づいて、会員から決済処理をするための秘密管理情報である。
【０００８】
会員装置２００は、管理者装置１００に管理される会員が所有する装置で、例えばパーソナルコンピュータ（ＰＣ）の様な汎用計算機が使用可能となっている。会員装置２００は、会員がメンバ証明書の発行の授受や，検証者装置３００からサービスの提供を受けるために，グループ署名方式を用いるためのデータ及びプログラムを格納し、公開鍵ペアの生成やグループ署名の生成といった演算を実行し、ネットワーク通信を行なう機能をもっている。
【０００９】
検証者装置３００は、会員装置２００からのサービス要求に基づき、利用可能なサービスを会員装置２００に表示させ、会員装置２００から送信されるサービス要求を検証し、会員装置２００にサービスを提供する装置である。
【００１０】
会員装置２００となる会員端末は、管理者装置１００へ会員登録のための要求を出す（ＳＴ１）。この要求には、会員の公開鍵と、決済情報等の個人情報とが含まれている。管理者装置１００では、この要求に従い会員登録を行うと，会員の公開鍵を管理者装置１００の秘密鍵で署名し、得られたメンバ証明書を会員装置２００に発行する（ＳＴ２）。
【００１１】
会員装置２００は，インターネットなどのネットワークを通じて検証者装置３００へアクセスし、利用可能なサービスの情報を検証者装置３００から入手する（ＳＴ３）。会員装置２００は、利用可能なサービスのうち、受けたいサービスを選択し，サービス要求としてのグループ署名を検証者装置３００へ送る（ＳＴ４）。
【００１２】
検証者装置３００は，会員装置２００から送られたグループ署名を検証し，正当であればサービスデータを会員装置２００へ送る。しかる後、検証者装置３００は、サービスデータを送ったとして管理者装置１００へ会員のグループ署名を送る（ＳＴ５）。
【００１３】
管理者装置１００は，このグループ署名を検証し，正当であればグループ署名のメンバ証明書から会員を特定し、サービス料金の決済代行を行い、匿名の会員の決済結果を検証者装置３００へ送る（ＳＴ６）。
【００１４】
＜グループ署名方式＞
グループ署名とは、デジタル署名方式の一種であり、これまで様々な方式が提案されている（例えば、非特許文献１〜３等参照）。グループ署名方式は、非特許文献１によれば、以下の第１乃至第３の性質を持っている。
【００１５】
第１の性質は、あるグループに所属する任意のメンバがグループの代表として署名を生成することが可能な性質である。第２の性質は、検証者側においては、グループのメンバにより生成された署名である旨を検証可能であるものの、署名を生成したメンバ（以下、署名者ともいう）を特定することが困難であるという匿名性を持つ性質である。第３の性質は、特定の情報により、グループ署名から署名者を特定することが可能な性質である（以下、追跡可能性ともいう）。
【００１６】
続いて、このようなグループ署名方式について、特許文献３に記載されているカメニッシュ(J. Camenisch)らのグループ署名方式を代表例として述べる。ここで、次の表１は、カメニッシュらのグループ署名方式の記号とその説明を示している。
【表１】
2008245023.tif 000003
【００１７】
（Ｃａｍ．１：準備）
グループ管理者ＧＭは、ＲＳＡ暗号方式の公開鍵ｅ，ｎ，素数Ｌ，元ｇ，元ａ，整数μおよびセキュリティパラメータεの組ｙＧ＝（ｅ，ｎ，Ｌ，ｇ，ａ，μ，ε）をグループ公開鍵として公開する。メンバＡとなるユーザは、秘密鍵ｘ∈｛１，…，２μ−１｝を選び、公開鍵ｙ＝ａｘ ｍｏｄ ｎを作る。
【００１８】
（Ｃａｍ．２：グループ参加要求）
メンバＡとなるユーザは、乱数ｔ∈｛１，…，２ε(μ+k)−１｝を選び、公開鍵ｙに対する秘密鍵ｘの知識証明ＳＫ（ｙ）を算出する。知識証明ＳＫ（ｙ）は、次のｃ１，ｓ１の組である。  
ｃ１＝ｈ（ｙ‖ａ‖ａｔ（ｍｏｄ ｎ））
ｓ１＝ｔ−ｘｃ１
そして、ユーザは、公開鍵ｙ及び知識証明ＳＫ（ｙ）をグループ管理者ＧＭに送る。
【００１９】
（Ｃａｍ．３：メンバ証明書発行）
グループ管理者ＧＭは、ｓ１’＝ｓ１（ｍｏｄ λ（ｎ））を算出し、次のｃ１の式により、正しい秘密鍵ｘをユーザが保持している旨を検証する。
【数１】
2008245023.tif 000004
【００２０】
その後、グループ管理者ＧＭは、適切な方法でユーザの参加権限を確認する。
【００２１】
しかる後、グループ管理者ＧＭは、ｙ＋δに対して次式のように署名を施してメンバ証明書νを発行し、秘密にユーザに送る。
【００２２】
ν＝（ｙ＋δ）ｄ （ｍｏｄ ｎ）
なお、δは例えば１である。
【００２３】
（Ｃａｍ．４：グループ署名）
署名者としてのメンバＡは、ｚ＝ｇｙ （ｍｏｄ Ｌ）を求める。その後、メンバＡは、ｕｉ＞ｘを満たすｋ個の乱数ｕｉ∈｛１，…，２εμ−１｝を選び、秘密鍵ｘの知識証明ＳＫ２(ｍ)＝（ｃ２，ｓ2,1，…，ｓ2,k）を次式のように求める。
【数２】
2008245023.tif 000005
【００２４】
ｓ2,i＝ｕｉ−ｘ    …（ｃ２(i)＝０のとき）
ｓ2,i＝ｕｉ        …（その他のとき）
但し、ｉ＝１，…，ｋ
ここで、ｃ２(i)とは、ｃ２の２進表示上位ビットからのｉ番目（ｉ＝１，…，ｋ）のビットを示す。
【００２５】
また、メンバＡは、乱数ｗｉ∈Ｚｎ*を選び、メンバ証明書νの知識証明ＳＫ３(ｍ)＝（ｃ３，ｓ3,1，…，ｓ3,k）を次式のように求める。
【数３】
2008245023.tif 000006
【００２６】
ｓ3,j＝ｗｊ／ν  （ｍｏｄ ｎ）  …（ｃ３(j)＝０のとき）
ｓ3,j＝ｗｊ        …（その他のとき）
但し、ｊ＝１，…，ｋ
結局、ｍについてのグループ署名は、（ｚ，ＳＫ２(ｍ)，ＳＫ３(ｍ)）である。
【００２７】
（Ｃａｍ．５：グループ署名検証）
検証者Ｖは、グループ署名の正当性を以下のように検証し、正しければｍを受理する。
【数４】
2008245023.tif 000007
【００２８】
（Ｃａｍ．６：追跡）
グループ管理者ＧＭは、任意のグループ署名（ｚ，ＳＫ２(ｍ)，ＳＫ３(ｍ)）に対して、グループに参加している全てのメンバの公開鍵ｙから、以下の式が成り立つ公開鍵ｙを見つけることにより、グループ署名を生成したメンバを特定することが出来る。
【００２９】
ｚ＝ｇｙ （ｍｏｄ Ｌ）
以上のようなカメニッシュのグループ署名方式は、メンバ証明書νに関連した秘密鍵ｘを用いてＳＫ２（ｍ）を作成することから、否認不可性を実現している。また、ＳＫ３（ｍ）の検証により、グループ公開鍵ｅを用いて、メンバ証明書νを署名者であるメンバＡが保持する旨を検証することから、検証性が示される。
【００３０】
また、検証者Ｖがゼロ知識証明を用いて検証するので、メンバＡの個人情報が漏洩せず、匿名性が保たれる。また、メンバＡの署名のｚは１つしかない秘密鍵ｘから作られるので、同じ基底ｇを用いるとセッション同士でメンバの情報がリンク（結合）可能となる。よって、署名毎に異なる基底ｇを用いれば、非結合性を満たす。  
さらに、グループ管理者ＧＭは、ＧＭのみが知っているグループに参加しているメンバの公開鍵ｙを用いて、グループ署名を生成したメンバを特定することが可能であり、よって追跡可能性を満たす。
【００３１】
以上がカメニッシュのグループ署名方式であり、前述した非特許文献１記載の第１乃至第３の性質を有している。また、グループ署名方式は、この方式に限らず様々な方式があるが、いずれの方式も同様に第１乃至第３の性質をもっている。
【００３２】
なお、係るグループ署名方式は、上述した説明では１つのグループに適用されたが、本発明の各実施形態では複数のグループ内の各グループに適用される。各実施形態の管理者装置は、上述したグループ署名方式を各グループに適用すると共に、各グループを個別のグループＩＤにより識別して管理する。その他、本発明の各実施形態と、前述したカメニッシュのグループ署名方式との対応関係は、次の表２に示す通りである。
【表２】
2008245023.tif 000008
【００３３】
なお、図１に示した匿名認証によるサービス提供については、非特許文献４，５及び特許文献１に詳しい。
【非特許文献１】D. Chaum, E. van Heyst, “Group Signatures”, EUROCRYPT’91, LNCS 547, Springer-Verlag, pp.257-265, 1991.
【非特許文献２】G. Ateniese , J. Camenisch, M. Joye and G. Tsudik. A practical and provably secure coalition-resistant group signature scheme. CRYPTO 2000, LNCS 1880, Springer-Verlag, pp.255-270, 2000.
【非特許文献３】J. Camenisch, M. Stadler, “Efficient Group Signature Schemes for Large Groups”, CRYPTO’97, LNCS 1294, pp.410-424, 1997.
【非特許文献４】加藤，岡田，吉田；“プライバシを保護する匿名認証システムの開発”，Computer Security Symposium 2003予稿集，p.569-574,2003
【非特許文献５】岡田，吉田，加藤；“計算能力の低いデバイスに適したグループ署名方式”，SCIS2005予稿集III/IV.p.1147-1152,2005
【特許文献１】特開２００４−５４９０５号公報
【発明の開示】
【発明が解決しようとする課題】
【００３４】
匿名によるサービス提供の要求を受けると、サービス提供者は誰からのサービス提供の要求か判らないため、サービスを受けた会員に対して当該サービスに応じた、例えばサービス料金や物販であれば購入代金に応じたポイントを付与することができない、という問題があった。
【課題を解決するための手段】
【００３５】
上記課題を解決するために、本発明は、追跡機能を有するグループ署名方式により、商品またはサービスからなる販売対象の匿名注文と、前記匿名注文に応じた販売対象の販売または提供とを実行するために、少なくとも１つの会員装置及び検証装置からなる匿名注文システムであって、前記会員装置は、当該会員装置を使用する会員の公開鍵を記憶する公開鍵記憶手段と、前記公開鍵記憶手段に記憶される公開鍵に基づいて前記選択された商品またはサービスの販売または提供対象の商品サービス要求情報を生成する商品サービス要求情報生成手段と、前記商品サービス要求情報生成手段により生成された商品サービス要求情報に対して、前記検証装置による検証の結果、問題ないと判断された場合に、当該検証装置からの商品またはサービスの販売または提供を受理する商品サービス受理手段と、前記検証装置による販売及び提供対象の商品またはサービスの内容を表示するとともに、当該会員に当該内容の選択を促す商品サービス選択表示部と、前記検証装置は、前記会員装置を使用する会員のグループ公開鍵を記憶するグループ公開鍵記憶手段と、前記会員装置から送信される商品サービス要求情報を検証する商品サービス要求情報検証手段と、前記商品サービス要求情報検証手段による検証の結果、問題ないと判断された場合に、前記会員装置に対して前記選択された商品またはサービスの販売または提供を実行する商品サービス販売提供手段とを備えることを特徴とする。
【発明の効果】
【００３６】
本発明では、サービス提供者には匿名のまま、サービスを利用した会員が、サービス料金や購入代金に応じたサービス提供が規定するポイントが付与されることが可能とする。
【発明を実施するための最良の形態】
【００３７】
以下、本発明の各実施形態について図面を用いて説明する。
【００３８】
図２乃至図３は、本発明の第1の実施形態について説明した図である。
【００３９】
図２は第1の実施形態の構成について説明した図であり、図３は第1の実施形態の処理の流れについて説明した図である。
【００４０】
なお、ここで説明する実施形態では、匿名でサービスを受けるための詳細な説明は、図１で示した流れに基づいて行われる。従って、匿名でサービスを受けるための詳細については省略し、本発明の部分について説明する。
【００４１】
図１に示すように、匿名によるサービス提供では検証者装置300は誰がサービスを受けたか分からないため、サービスを受けた会員（会員装置）へポイントを付与することが出来ない。また、図１で示した匿名によるサービスでは、2つのサービスの要求に対して、同じ人からのサービス要求なのか、異なる人からのサービス要求なのかも分からない。
【００４２】
会員装置200には、サービス提供元である検証者装置300が提供するサービスの内容を表示うし、受けたいサービスが選択するサービス表示・選択部201、選択されたサービスから会員装置200内の記憶部203に格納された署名鍵によりサービス要求を生成するサービス要求生成部202、会員が自分のポイントを管理者装置100へ確認するポイント確認要求部206、確認したポイントを会員装置へ表示するポイント表示部205、検証者装置から提供されるサービスを受けるサービス受理部204、からなる。
【００４３】
サービスを提供する検証者装置300は、会員装置200へサービスの内容を表示するサービス表示部301、会員装置100から送られるサービス要求を検証するサービス要求検証部302、ならびに検証の際に必要なグループ公開鍵を格納した検証者装置300内のメモリ部303、サービス要求に従ってサービスを提供するサービス提供部304、サービスに応じたポイントを生成するポイント生成部305、管理者装置100へ決済を要求する決済要求部306、からなる。
【００４４】
管理者装置100は、検証者装置300から送られる決済要求を受け付け処理する決済要求受付部101、会員情報や会員のポイント情報を管理する管理者装置内のメモリ部102、会員装置200からのポイント確認要求を検証するために必要なグループ公開鍵を格納したメモリ部103、ポイント確認要求を受付け、会員装置200へ確認したポイント情報を送るポイント確認要求受付部104、からなる。
【００４５】
図３を用いて、第1の実施形態について処理の流れを説明する。
【００４６】
会員装置200から検証者装置300へサービス要求が送られると、検証者装置300は提供可能なサービスを表示するためのメニュー情報をサービス提示部301から会員装置200へ送る。
【００４７】
会員装置200は、送られたメニュー情報から提供されるサービスの一覧を、サービス表示・選択部201にて表示する。そして、会員装置200を使用する会員は、使用対象のサービスを選択し、引き続き管理者装置100へポイント確認要求部206からポイント確認要求を出す。このポイント確認要求は、会員装置200の記憶部203に格納された署名鍵により生成されたグループ署名である。このグループ署名には、どの検証者装置（サービス提供者）か特定する情報が含まれている。
【００４８】
管理者装置100は、会員装置200からのポイント確認要求をポイント確認要求受付部104にて受信し、管理者装置100のメモリ部103に格納されているグループ公開鍵にて会員であることを検証し、かつそのグループ公開鍵に対応するグループ秘密鍵によりポイント確認要求を送った会員を図示しないメモリ部内の会員情報102から検索して特定する。会員が過去にサービスを受け、サービス提供者からポイントが付与されているか確認する。これは、グループ署名に対してグループ秘密鍵を用いて署名生成者を特定し、かつそのグループ署名に含まれているサービス提供者を特定する情報により、どのサービス提供者のポイントがどれ位あるかを検索することにより情報が取り出される。
【００４９】
取り出されたポイント情報を、ポイント確認要求受付部104から会員装置200へ送ると、会員装置200ではポイント表示部205によりポイントが表示される。
【００５０】
そして、受けるサービスの内容と、ポイントを使うのであればその旨を含め、署名鍵によりグループ署名が生成されサービス要求情報としてサービス要求生成部202で生成し検証者装置300へ送信する。ポイントを使うか否かは、サービス要求情報のポイントエリアがNullであればポイントを使わず、値が入っていれば、そのポイントを利用する、という意思表示としてよい。
【００５１】
検証者装置300では、サービス要求情報をサービス要求検証部302にてグループ公開鍵を用いて検証する。検証結果が真であれば、サービス料金や購入金額に応じたポイント額を生成し、サービス提供部301からサービスを提供し、ポイント発生額を通知する。
【００５２】
会員装置200は、サービス受理部204にてサービスを受けると、サービス受理確認を検証者装置300へ返す。これにより、会員装置200と検証者装置300との間のサービスのやり取りが終了する。
【００５３】
検証者装置300はサービスの提供を終えると、決済要求情報を決済要求部306にて生成する。この決済要求情報は、会員装置200から送られたサービス要求情報と、今回のサービスにより発生したポイント額からなる情報である。
【００５４】
管理者装置100は決済要求情報を受け取ると、グループ公開鍵を用いて正当性を検証し、グループ秘密鍵を用いてサービスを受けた人を特定する。そして、今回発生したポイントを更新し、決済を行う。決済が終了したら決済確認結果を検証者装置300へ返す。そして、会員装置200へは、今回の決済額と更新された累積ポイント情報とを送る。
【００５５】
本発明により、会員はサービス提供者が複数あったとしても、サービス提供者毎のポイントが、サービス提供者から匿名であっても付与され、ポイントサービスが受けられるようになる。
【００５６】
もし、サービス要求情報に含まれるポイントが偽造されたとしても、検証者装置300から管理者装置100へ決済要求が行われる際にポイント額のチェックを行うことにより、実際に使えるポイントよりも大きいポイントを使うと要求したとしても、決済の際に正当な料金を会員から決済することで不正を防止できる。
【００５７】
図４乃至図５は、第2の実施形態を示した図である。
【００５８】
図４は第2の実施形態の構成を示し、図５は第2の実施形態の処理を説明した図である。
【００５９】
構成の多くは図２と同じなので、異なる部分について説明する。
【００６０】
第1の実施形態ではサービス提供時に会員が持っているポイントを管理者装置へ問い合わせるようになっていた。第2の実施形態では、ポイント情報を会員装置200内のメモリ部208に格納し、ポイント管理部207で管理される。そこが、第１の実施形態と異なる部分である。
【００６１】
図５を用いて、第2の実施形態の処理を説明する。
【００６２】
会員装置200から検証者装置300へサービス要求が送られると、検証者装置300は提供可能なサービスを表示するためのメニュー情報をサービス提示部から会員装置200へ送る。
【００６３】
会員装置200は、送られたメニュー情報から提供されるサービスの一覧を、サービス表示・選択部201にて表示する。そしてサービスを選択し、会員装置200内に格納されているポイント情報を確認し、会員装置200へ表示し、選択したサービスの内容とポイント情報を元に署名鍵を用いて、サービス要求生成部202でサービス要求情報を生成する。
【００６４】
第1の実施形態と同様にポイントを使うか否かは、サービス要求情報のポイントエリアがNullであればポイントを使わず、値が入っていれば、そのポイントを利用する、という意思表示としてよい。
【００６５】
検証者装置300では、サービス要求情報をサービス要求検証部302にてグループ公開鍵を用いて検証する。検証結果が真であれば、サービス料金や購入金額に応じたポイント額を生成し、サービス提供部304からサービスを提供し、ポイント発生額を通知する。
【００６６】
検証者装置300は決済要求情報を決済要求部306にて生成する。この決済要求情報は、会員装置200から送られたサービス要求情報と、今回のサービスにより発生したポイント額からなる情報である。
【００６７】
管理者装置100は決済要求情報を受け取ると、グループ公開鍵を用いて正当性を検証し、グループ秘密鍵を用いてサービスを受けた人を特定する。そして、ポイントが正しく使われているか確認する。例えば管理者装置100で確認したポイントよりも大きいポイントを使おうとしていないか、などである。これらが正しければ決済処理を行い、決済確認結果とポイント確認結果を検証者装置300へ返す。
【００６８】
検証者装置300は、決済確認結果とポイント確認結果を受け取ると、サービスと今回発生したポイントを会員装置200へ送る。そして、会員装置200へは、今回の決済額と更新された累積ポイント情報とを送る。
【００６９】
会員装置200は、サービス受理部にてサービスを受けとり、ポイント情報をポイント管理部205にて更新する。そして、サービス受理確認を検証者装置300へ返す。これにより、会員装置200と検証者装置300との間のサービスのやり取りが終了する。
【００７０】
さらに会員装置200は、更新されたポイント情報についてグループ署名を生成し、ポイント更新情報として管理者装置100へ送る。管理者装置100では、先に検証者装置300から送られた決済要求情報に含まれるポイント情報と、会員装置から送られたポイント情報を照合し誤りがなければ会員情報のポイント情報を更新し、会員へ決済情報と累積ポイント情報を送る。
【００７１】
第２の実施形態により、会員装置200はサービスを要求する際に管理者装置100へ接続する必要がなく、サービスを受けた後で管理者装置100へ通知するだけでよくなる。
【００７２】
図６乃至図７は、第３の実施形態を示した図である。
【００７３】
図６は第３の実施形態の構成を示し、図７は第３の実施形態の処理を説明した図である。
【００７４】
構成の多くは図４と同じなので、異なる部分について説明する。
【００７５】
図６では、検証者装置300のメモリ部303に検証者署名鍵、検証者公開鍵が加わっている。これが、第２の実施形態と異なる部分である。
【００７６】
それでは、図７を用いて第3の実施形態の処理の流れを説明する。
【００７７】
会員装置200から検証者装置300へサービス要求が送られると、検証者装置300は提供可能なサービスを表示するためのメニュー情報をサービス提示部301から会員装置200へ送る。
【００７８】
会員装置200は、送られたメニュー情報から提供されるサービスの一覧を、サービス表示・選択部201にて表示する。そして、会員装置200を使用する会員は、使用したいと思うサービスを選択し、会員装置200内に格納されているポイント情報を確認し、会員装置200へ表示し、選択したサービスの内容とポイント情報を元に署名鍵を用いて、サービス要求生成部202でサービス要求情報を生成する。
【００７９】
ここで、第1ならびに第2の実施形態と異なるのは、ポイント情報が検証者装置300の電子署名となっている点である。第3の実施形態では、サービス要求情報は検証者装置300の電子署名であるポイント情報の署名対象データと、サービス内容とをグループ署名の対象データとしてグループ署名が行う。これにより、グループ署名のポイント情報と検証者装置300の電子署名であるポイント情報とに関連性がつく。
【００８０】
さて、会員装置が保持しているポイントから、どれだけのポイントを使うか否かは、第1の実施形態と同様にサービス要求情報のポイントエリアに使用するポイント額を記述すればよい。
【００８１】
ポイントを使わなければ、ポイント情報を送らず、かつサービス要求情報のポイントエリアがNullになっている。ポイント情報が送られても、サービス要求情報のポイントエリアがNullであれば、ポイントを使わない、という意思表示と判断してよい。
【００８２】
そして、ポイント情報が送られ、サービス要求のポイントエリアに値が入っていれば、その値が利用するポイント額と判断する。
【００８３】
検証者装置300では、サービス要求情報をサービス要求検証部302にてグループ公開鍵を用いて検証する。そして、ポイント情報を検証者装置300の検証者の署名鍵（公開鍵）で検証する。どちらの検証結果も真であれば、サービス料金や購入金額に応じたポイント額を生成し、新たなポイント情報を検証者署名鍵で生成し、サービス提供部304からサービスを提供し、ポイント情報を送る。
【００８４】
検証者装置300は決済要求情報を決済要求部306にて生成する。この決済要求情報は、会員装置200から送られたサービス要求情報と、今回のサービスにより発生したポイント額からなる情報である。
【００８５】
管理者装置100は決済要求情報を受け取ると、グループ公開鍵を用いて正当性を検証し、グループ秘密鍵を用いてサービスを受けた人を特定する。そして、ポイントが正しく使われているか確認する。例えば管理者装置100で確認したポイントよりも大きいポイントを使おうとしていないか、などである。これらが正しければ決済処理を行い、決済確認結果とポイント確認結果を検証者装置300へ返す。
【００８６】
検証者装置300は、決済確認結果とポイント確認結果を受け取ると、サービスと今回発生したポイントを会員装置200へ送る。
【００８７】
会員装置200は、サービス受理部204にてサービスを受けとり、ポイント情報をポイント管理部205にて検証者公開鍵で検証し、検証結果が真であればポイント情報を更新する。そして、サービス受理確認を検証者装置300へ返す。これにより、会員装置200と検証者装置300との間のサービスのやり取りが終了する。
【００８８】
検証者装置300は、決済要求情報とポイント情報を管理者装置100へ送り、管理者装置100は決済要求情報をグループ公開鍵で検証し、ポイント情報を検証者公開鍵で検証する。どちらの検証結果も真であれば、会員情報のポイント情報を更新し、決済を行う。そして検証者装置300へ決済確認結果を通知する。
【００８９】
そして、会員装置200へは、今回の決済額と更新された累積ポイント情報とを送る。
【００９０】
第3の実施形態により、ポイント情報の正当性が検証者装置300の公開鍵で検証できるため、不正が困難となる。
【図面の簡単な説明】
【００９１】
【図１】既存のシステム構成を示した図である。
【図２】本発明の第１の実施形態の構成を示した図である。
【図３】本発明の第１の実施形態の処理の流れを示した図である。
【図４】本発明の第２の実施形態の構成を示した図である。
【図５】本発明の第２の実施形態の処理の流れを示した図である。
【図６】本発明の第３の実施形態の構成を示した図である。
【図７】本発明の第３の実施形態の処理の流れを示した図である。
【符号の説明】
【００９２】
１００…管理者装置、２００…会員装置、３００…検証者装置、１０１…決済要求受付部、１０２…記憶部、１０４…ポイント確認要求受付部、２０１…サービス表示・選択部、２０２…サービス要求生成部、２０３…記憶部、２０４…サービス受理部、２０５…ポイント表示部、２０６…ポイント確認要求部、３０１…サービス提示部、３０２…サービス要求検証部、３０３…記憶部、３０４…サービス提供部、３０５…ポイント生成部、３０６…決済要求部
【図１】
2008245023.tif 000009
【図２】
2008245023.tif 000010
【図３】
2008245023.tif 000011
【図４】
2008245023.tif 000012
【図５】
2008245023.tif 000013
【図６】
2008245023.tif 000014
【図７】
2008245023.tif 000015