(57)【要約】  匿名電子署名から当該署名を作成したメンバを自由に特定することを抑制することができる情報処理装置、情報処理システム、メンバ特定方法、及びプログラムを提供する。開示装置（３）は、匿名電子署名を構成する情報である署名情報を受信する受信部（６）と、前記署名情報に基づいて、前記匿名電子署名を作成したメンバを特定する情報である特定情報を生成する特定情報生成部（７）と、特定情報生成部（７）による前記特定情報の生成回数を記憶する記憶部（８）と、前記特定情報を送信する送信部（９）とを有する。
2020053994.tif 000002
【特許請求の範囲】
【請求項１】
匿名電子署名を構成する情報である署名情報を受信する受信手段と、
前記署名情報に基づいて、前記匿名電子署名を作成したメンバを特定する情報である特定情報を生成する特定情報生成手段と、
前記特定情報生成手段による前記特定情報の生成回数を記憶する記憶手段と、
前記特定情報を送信する送信手段と
を有する情報処理装置。
【請求項２】
前記受信手段は、電子オークションにおける現在の評価値の更新情報を受信し、
前記送信手段は、前記更新情報と記憶されている現在の前記生成回数とを関連づけた情報を送信する
請求項１に記載の情報処理装置。
【請求項３】
前記関連づけた情報に対してデジタル署名を生成する署名生成手段をさらに有し、
前記送信手段は、前記デジタル署名が付与された前記関連づけた情報を送信する
請求項２に記載の情報処理装置。
【請求項４】
前記特定情報生成手段は、記憶された前記生成回数が予め設定された上限値未満である場合、前記特定情報を生成する
請求項１乃至３のいずれか一項に記載の情報処理装置。
【請求項５】
前記匿名電子署名は、電子オークションの入札情報に付与された署名であり、
前記上限値は、前記電子オークションにおける最大落札者数である
請求項４に記載の情報処理装置。
【請求項６】
前記情報処理装置は、該情報処理装置内のデータの漏洩を防ぐための機構を有することが予め保障されている装置である
請求項１乃至５のいずれか１項に記載の情報処理装置。
【請求項７】
匿名電子署名付きの入札情報を受信し、電子オークションによる競りを管理する管理装置と、前記匿名電子署名を作成したメンバである参加者装置を特定する開示装置とを備え、
前記管理装置は、
受信した前記入札情報のうち送信元の前記参加者装置を特定すべき前記入札情報に付与されていた前記匿名電子署名を構成する情報である署名情報を前記開示装置に送信する第１の送信手段と、
前記開示装置から前記匿名電子署名を作成した前記参加者装置を特定する情報である特定情報を受信する第１の受信手段と
を有し、
前記開示装置は、
前記管理装置から前記署名情報を受信する第２の受信手段と、
前記第２の受信手段が受信した前記署名情報に基づいて、前記特定情報を生成する特定情報生成手段と、
前記特定情報生成手段による前記特定情報の生成回数を記憶する記憶手段と、
前記特定情報を前記管理装置に送信する第２の送信手段と、
を有する情報処理システム。
【請求項８】
前記第１の送信手段は、前記電子オークションにおける現在の評価値を更新する場合、評価値の更新情報を前記開示装置に送信し、
前記第２の受信手段は、前記管理装置から前記更新情報を受信し、
前記第２の送信手段は、前記更新情報と記憶されている現在の前記生成回数とを関連づけた情報を送信する
請求項７に記載の情報処理システム。
【請求項９】
前記入札情報及び前記更新情報が前記管理装置及び前記参加者装置で共有される
請求項８に記載の情報処理システム。
【請求項１０】
前記入札情報及び前記更新情報は、ブロックチェーンにより前記管理装置及び前記参加者装置で共有される
請求項９に記載の情報処理システム。
【請求項１１】
前記入札情報に付与された前記匿名電子署名も共有され、
前記情報処理システムは、前記参加者装置をさらに有し、
前記参加者装置は、前記匿名電子署名を検証する検証手段を有する
請求項９又は１０に記載の情報処理システム。
【請求項１２】
情報処理装置が、
匿名電子署名を構成する情報である署名情報を受信し、
前記署名情報に基づいて、前記匿名電子署名を作成したメンバを特定する情報である特定情報を生成し、
前記特定情報の生成回数を記憶し、
前記特定情報を送信する
メンバ特定方法。
【請求項１３】
匿名電子署名を構成する情報である署名情報を受信する受信ステップと、
前記署名情報に基づいて、前記匿名電子署名を作成したメンバを特定する情報である特定情報を生成する特定情報生成ステップと、
前記特定情報の生成回数を記憶する記憶ステップと
前記特定情報を送信する送信ステップと
をコンピュータに実行させるプログラムが格納された非一時的なコンピュータ可読媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、情報処理装置、情報処理システム、メンバ特定方法、及びプログラムが格納された非一時的なコンピュータ可読媒体に関し、例えば、特に、電子オークションに関する。
【背景技術】
【０００２】
現代社会において電子オークションが盛んに行われている。その中でも、広く用いられているオークションは英国オークションである。英国オークションでは、ある対象に対し、一定の期間の間に買い手側から入札価格を募集する。この時入札価格は公開されており、買い手側が価格を吊り上げながら入札し、最も高い価格を提示した買い手が落札する。【０００３】
英国オークションでは参加者側や主催者側の不正を防止するために、入札者に匿名性を持たせることが重要である。例えば、参加者側の不正としては参加者同士の談合がある。匿名性がないと誰がどんな価格を入札しているかがわかるため、談合の参加者達がお互いを監視でき、談合が成り立ってしまう。一方、主催者側での不正としては、落札者以外の入札価格を知ることで、参加者の支払い能力をわかってしまうことがある。また、参加者の入札価格の履歴が主催者側に知られることで、参加者の入札戦略が漏洩するリスクが生じる。【０００４】
そのため、一般に主催者側の役割（すなわち、オークションの管理と参加者の特定）を異なる主体に分散させることが行われている。それに適しているのは、匿名認証を可能にするグループ署名である。【０００５】
非特許文献１ではグループ署名を用いた英国オークションが提案されている。ここでは、オークション管理者（auction manager）と参加者情報の開示管理者（revocation manager）が導入されている。ここで、オークション管理者は参加者登録、入札等を管理する。オークション終了後に開示管理者が落札者の情報を開示する。
非特許文献２には、非特許文献１で提案されたグループ署名方式に用いられた、ゼロ知識証明データの作成方法と検証方法が説明されている。
非特許文献３では、グループ署名を構成するゼロ知識証明データの作成方法が説明されている。【０００６】
また、グループ署名以外の方法で上記と同様なオークション管理者と開示管理者がいる匿名オークションシステムを実現する方法も非特許文献４に提案されている。そこでは、オークション参加者が署名鍵に対応する検証鍵を開示管理者（registration manager）に登録し、開示管理者はオークション参加者の公開鍵に対し秘密変換を行った情報を公開する。オークション管理者（auction manager）は公開された情報にさらに秘密変換を行った情報を公開する。オークション参加者は、オークション管理者が公開した情報から自分に対応する情報を探し、署名生成を行い、入札する。この方式では、ユーザの検証鍵を開示管理者が管理することにより、オークション管理者が署名作成者を特定できなくしている。【０００７】
グループ署名を用いた方式と用いない方式のいずれの場合も、最初のパラメータセットアップ段階で設定された開示管理者の秘密鍵を用いればユーザの特定が可能となっている。【０００８】
なお、上述した技術の他に、オークションにおける匿名性に関する技術として、特許文献１に記載された技術がある。しかし、特許文献１は、買い手の匿名性が重要であることを言及しているが、この文献で提案されている技術では、匿名化は、売り手と買い手間の匿名化である。具体的には売り手と買い手が匿名でメール送信できるように、メールの送信元のアドレスをフィルタリングするメールサーバを設けている。したがって、特許文献１に記載された技術では、管理者へのメッセージは匿名ではないため、管理者に対する匿名性について検討されていない。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】特開２００１−１９５５１１号公報
【非特許文献】
【００１０】
【非特許文献１】Khanh Quoc Nguyen and Jacques Traore, “An Online Public Auction Protocol Protecting Bidder Privacy”, 2000, ACISP 2000, LNCS 1841, pp. 427-442.
【非特許文献２】Jan Camenisch, “Efficient and Generalized Group Signatures”, 1997, EUROCRYPT ’97, LNCS 1233, pp. 465-479.
【非特許文献３】Jan Camenisch and Markuc Stadler, “Efficient Group Signature Schemes for Large Groups”, 1997, CRYPTO ’97, pp. 410-424.
【非特許文献４】Kazumasa Omote and Atsuko Miyaji, “A Practical English Auction with One-time Registration”, 2001, Proceedings of ACISP2001, pp. 221-234.
【発明の概要】
【発明が解決しようとする課題】
【００１１】
前述のように、オークション管理者は、開示管理者の秘密鍵を得ない限り、署名の作成者を自ら特定することはできない。しかしながら、開示管理者による署名作成者の特定及びその特定結果の通知が自由に行われてしまうと、開示管理者が無制限に署名作成者を特定する事態をもたらす恐れがある。【００１２】
本開示は、このような問題点を解決するためになされたものであり、匿名電子署名から当該署名を作成したメンバを自由に特定することを抑制することができる情報処理装置、情報処理システム、メンバ特定方法、及びプログラムを提供することを目的とする。
【課題を解決するための手段】
【００１３】
本開示の第１の態様にかかる情報処理装置は、
匿名電子署名を構成する情報である署名情報を受信する受信手段と、
前記署名情報に基づいて、前記匿名電子署名を作成したメンバを特定する情報である特定情報を生成する特定情報生成手段と、
前記特定情報生成手段による前記特定情報の生成回数を記憶する記憶手段と、
前記特定情報を送信する送信手段と
を有する。【００１４】
本開示の第２の態様にかかる情報処理システムは、
匿名電子署名付きの入札情報を受信し、電子オークションによる競りを管理する管理装置と、前記匿名電子署名を作成したメンバである参加者装置を特定する開示装置とを備え、
前記管理装置は、
受信した前記入札情報のうち送信元の前記参加者装置を特定すべき前記入札情報に付与されていた前記匿名電子署名を構成する情報である署名情報を前記開示装置に送信する第１の送信手段と、
前記開示装置から前記匿名電子署名を作成した前記参加者装置を特定する情報である特定情報を受信する第１の受信手段と
を有し、
前記開示装置は、
前記管理装置から前記署名情報を受信する第２の受信手段と、
前記第２の受信手段が受信した前記署名情報に基づいて、前記特定情報を生成する特定情報生成手段と、
前記特定情報生成手段による前記特定情報の生成回数を記憶する記憶手段と、
前記特定情報を前記管理装置に送信する第２の送信手段と、
を有する。【００１５】
本開示の第３の態様にかかるメンバ特定方法は、
情報処理装置が、
匿名電子署名を構成する情報である署名情報を受信し、
前記署名情報に基づいて、前記匿名電子署名を作成したメンバを特定する情報である特定情報を生成し、
前記特定情報の生成回数を記憶し、
前記特定情報を送信する。【００１６】
本開示の第４の態様にかかるプログラムは、
匿名電子署名を構成する情報である署名情報を受信する受信ステップと、
前記署名情報に基づいて、前記匿名電子署名を作成したメンバを特定する情報である特定情報を生成する特定情報生成ステップと、
前記特定情報の生成回数を記憶する記憶ステップと
前記特定情報を送信する送信ステップと
をコンピュータに実行させる。
【発明の効果】
【００１７】
本開示によれば、匿名電子署名から当該署名を作成したメンバを自由に特定することを抑制することができる情報処理装置、情報処理システム、メンバ特定方法、及びプログラムを提供することができる。
【図面の簡単な説明】
【００１８】
【図１】グループ署名方式における構成主体を役割別に示した図である。
【図２】グループ署名の生成手順を示す図である。
【図３】実施形態の概要にかかる情報処理システム１の構成の一例を示すブロック図である。
【図４】第１の実施形態に係るオークションシステム１１の構成の一例を示す図である。
【図５】第１の実施形態に係る管理者装置１０の構成の一例を示すブロック図である。
【図６】第１の実施形態に係る管理者装置１０のハードウェア構成の一例を示すブロック図である。
【図７】第１の実施形態に係るトラステッドハードウェア２０の構成の一例を示すブロック図である。
【図８】第１の実施形態に係る参加者装置３０の構成の一例を示すブロック図である。
【図９】第１の実施形態に係るオークションシステム１１におけるセットアップ動作の一例を示すシーケンス図である。
【図１０】第１の実施形態に係るオークションシステム１１における入札動作の一例を示すシーケンス図である。
【図１１】第１の実施形態に係るオークションシステム１１における入札者の特定動作の一例を示すシーケンス図である。
【図１２】第２の実施形態に係るトラステッドハードウェア４０の構成の一例を示すブロック図である。
【図１３】第２の実施形態に係るオークションシステムのセットアップ動作の一例を示すシーケンス図である。
【図１４】第２の実施形態に係るオークションシステムにおける入札者の特定動作の一例を示すシーケンス図である。
【図１５】第３の実施形態に係るオークションシステム１３の構成の一例を示す図である。
【図１６】第３の実施形態に係る管理者装置５０の構成の一例を示すブロック図である。
【図１７】第３の実施形態に係る情報共有サーバー６０の構成の一例を示すブロック図である。
【図１８】第３の実施形態に係る参加者装置７０の構成の一例を示すブロック図である。
【図１９】第３の実施形態に係るオークションシステム１３のセットアップ動作の一例を示すシーケンス図である。
【図２０】第３の実施形態に係るオークションシステム１３における入札動作の一例を示すシーケンス図である。
【図２１】第４の実施形態に係るオークションシステム１４の構成の一例を示す図である。
【図２２】第４の実施形態に係る管理者装置１００の構成の一例を示すブロック図である。
【図２３】第４の実施形態に係る参加者装置９０の構成の一例を示すブロック図である。
【図２４】第４の実施形態に係るオークションシステム１４のセットアップ動作の一例を示すシーケンス図である。
【図２５】第４の実施形態に係るオークションシステム１４における入札動作の一例を示すシーケンス図である。
【図２６】第４の実施形態に係るオークションシステム１４における入札者の特定動作の一例を示すシーケンス図である。
【発明を実施するための形態】
【００１９】
説明の明確化のため、以下の記載及び図面は、適宜、省略、及び簡略化がなされている。なお、各図面において、同一の要素には同一の符号が付されており、必要に応じて重複説明は省略されている。
【００２０】
前述のように、オークションにおいて参加者の匿名性を担保することが入札者やオークション主催者側での様々な不正を防止することにつながる。実施形態の理解を容易にするために、まず、一例として、英国オークションについて説明し、それにおける課題を説明する。
【００２１】
英国オークションの管理者は、入札者から受け取った入札メッセージが正当な作成者によって作成されたことと入札価格が現在の最高価格より高いことを確認できれば、最高価格を更新する。この時、管理者はオークション参加者の誰が入札メッセージを作成したかを知る必要はない。入札者を特定する必要性があるのは、オークションが終了し、落札者を特定するときか、不正な入札を行う参加者を特定するときである。また、オークションの趣旨から、同一の参加者が作成した複数の入札メッセージを互いに関連付ける必要性もない。管理者は最終的に誰が落札したかがわかればよい。
【００２２】
そのため、英国オークションに対してグループ署名方式を用いて入札者の匿名化を図る方式が提案されている。グループ署名の詳しい解説は非特許文献２にあるため、ここではその概略を説明する。グループ署名方式は匿名電子署名の一種である。なお、匿名電子署名とは、匿名認証に用いられる電子署名である。グループ署名方式は、あるメッセージに署名した人がグループに所属していることを検証しつつ、誰が署名したかを隠す暗号技術である。図１は、グループ署名方式における構成主体を役割別に示した図である。図１にあるようにグループ管理者１５と特権者１６とグループメンバ１７が存在する。
【００２３】
グループ管理者１５と特権者１６はグループ署名を作成するのに用いるパラメータを設定し、公開する。グループメンバ１７はこの公開情報をもとに自身の秘密情報を生成し、グループ管理者１５に登録する。登録は、特権者１６のみがグループメンバ１７の作成したグループ署名からグループメンバ１７を特定できるように行われる。これにより、グループ管理者１５はグループ署名がグループメンバ１７によって作成されたことを検証することができる。より具体的には、以下のように動作する。
【００２４】
まず、セットアップ動作を説明する。初期設定は以下の手順で示されるセットアップ動作により行われる。
１．グループ管理者１５はグループ署名作成用のパラメータを設定し、管理者用秘密鍵以外のパラメータを公開する。管理者用秘密鍵はメンバ登録の際に発行するメンバ証明書の作成に用いる。
２．グループ管理者１５の公開したパラメータを基に特権者１６は特権者用秘密鍵と公開鍵を作成し、特権者用公開鍵を公開する。特権者用秘密鍵はのちにグループメンバ１７の特定に用いる。
３．グループメンバ１７は管理者の公開したパラメータを基に各自のグループメンバ用公開鍵とグループメンバ用秘密鍵を生成する。そして、グループメンバ用公開鍵をグループ管理者１５に送信する。グループメンバ用秘密鍵はのちにグループ署名を作成するのに用いる。
４．グループ管理者１５は受け取ったグループメンバ用公開鍵を基にグループ管理者用秘密鍵を用いて、メンバ毎にメンバ証明書を作成し、グループメンバ１７に送信する。グループ管理者１５はグループメンバ用公開鍵とそれを作成したグループメンバのＩＤを記録し、保管する。この記録は、のちにグループ署名からそれを作成したグループメンバ１７を特定する際に用いられる。
以上で、グループメンバの登録が完了する。
【００２５】
次に、図２を基にグループメンバによる、グループ署名の作成動作を説明する。図２は、グループ署名の生成手順を示す図である。図２に示すように、グループメンバ１７は自身のグループメンバ用秘密鍵ＳＫと特権者用公開鍵ＰＫと署名したいメッセージＭを基にグループ署名ＧＳを作成する。この署名にはグループメンバ１７がグループ管理者１５から発行されたメンバ証明書を所有していることがゼロ知識証明により示されている。グループ署名ＧＳの正当性は公開されている情報を基に誰でも検証することができる。
【００２６】
最後に、グループ署名ＧＳを基に、それを作成したグループメンバ１７を特定する動作を説明する。グループメンバ１７の特定は、以下の手順で行われる。
１．グループ署名ＧＳから作成者を特定できるのは特権者用秘密鍵を持っている特権者１６のみである。特権者１６はグループ署名ＧＳと特権者用秘密鍵を用いて、グループ署名ＧＳを作成したグループメンバ１７のグループメンバ用公開鍵、あるいはそれから計算できる情報を計算できる。そして、特権者１６は計算結果をグループ管理者１５に渡す。
２．グループ管理者１５は受け取った情報と自身が保有するグループメンバ１７のグループメンバ用公開鍵とＩＤの記録から、グループ署名ＧＳを作成したグループメンバ１７のＩＤを特定する。
以上がグループ署名方式の概略である。
【００２７】
グループ署名方式では上述のように、グループ管理者１５や特権者１６のどっちか一人でグループメンバ１７を特定できないため、英国オークションの方式で参加者のプライバシを守ることに適している。例えば、グループ管理者１５がオークションの運用を行うオークション管理者になり、特権者１６が入札メッセージについているグループ署名から落札者を特定する開示管理者になることで英国オークションを運用することができる。グループメンバ１７としての参加者は入札価格メッセージに前述のようにグループ署名を付けることで、匿名性を保ちつつ自分が正当な参加者であることを管理者に示すことができる。
【００２８】
一見、上記のようにオークション参加者のプライバシを保護しつつ、オークションの運用が成り立つように見える。しかし、特権者１６による署名作成者の特定及びその特定結果の通知が自由に行われてしまうと、オークション主催者側が入札を行った参加者を逐一特定することができてしまう。これは、特権者用秘密鍵が漏えいした場合にも、同じである。その結果、オークション参加者のプライバシが著しく損なわれる。例えば、前述のように参加者の入札履歴から、入札の戦略が読み取られてしまう。また、特定の参加者の入札を妨害することも考えられる。もしくは、参加者が最後に提示した入札価格などから支払い能力も知られてしまう。あるいは、これらの情報が他の参加者に漏洩されれば、さらにプライバシが侵害されるリスクが生じる。
【００２９】
このことから、グループ署名などの匿名電子署名から当該署名を作成したメンバを自由に特定することを抑制するための技術が求められている。
【００３０】
＜実施形態の概要＞
実施形態の詳細を説明する前に、まず、実施形態の概要について説明する。図３は、実施形態の概要にかかる情報処理システム１の構成の一例を示すブロック図である。図３に示すように、情報処理システム１は、管理装置２と開示装置３とを有する。管理装置２及び開示装置３は、情報処理装置と称されることがある。
【００３１】
管理装置２は、匿名電子署名付きの入札情報を受信し、電子オークションによる競りを管理する装置である。管理装置２は、図１のグループ管理者１５に対応している。管理装置２は、送信部４と、受信部５とを有する。
【００３２】
送信部４は、受信した入札情報のうち、当該入札情報の送信元の参加者装置（図３において不図示）を特定すべき入札情報に付与されていた匿名電子署名を構成する情報である署名情報を開示装置３に送信する。すなわち、匿名電子署名を作成した参加者装置を特定するために、送信部４は、当該署名情報を開示装置３に送信する。
【００３３】
受信部５は、開示装置３から特定情報を受信する。ここで、特定情報とは、匿名電子署名を作成した参加者装置を特定する情報であり、後述するグループ署名作成者特定情報に相当する。すなわち、受信部５は、開示装置３による署名作成者の特定結果を受信する。
【００３４】
開示装置３は、匿名電子署名を作成したメンバである参加者装置を特定する装置である。開示装置３は、図１の特権者１６と対応している。開示装置３は、受信部６と、特定情報生成部７と、記憶部８と、送信部９とを有する。
【００３５】
受信部６は、管理装置２から匿名電子署名を構成する情報である署名情報を受信する。すなわち、受信部６は、開示装置３の送信部４が送信した、署名作成者の特定が求められている匿名電子署名についての署名情報を受信する。
【００３６】
特定情報生成部７は、受信部６が受信した署名情報に基づいて、匿名電子署名を作成した参加者装置を特定する特定情報を生成する。特定情報生成部７は、例えば、受信した署名情報と、開示装置３が予め有する秘密鍵とを用いて、特定情報を生成する。なお、特定情報の具体的な生成方法は、匿名電子署名の方式に依存している。特定情報生成部７は、匿名電子署名の作成者の公知の特定方法に従った演算を、受信した署名情報（匿名電子署名）と、開示装置３が予め有する秘密鍵とを用いて行なって、特定情報を生成すればよい。
【００３７】
記憶部８は、特定情報の生成回数を記憶する。記憶部８は、例えば、メモリ、ストレージなどの記憶装置に、生成回数を記憶する。記憶部８は、特定情報生成部７による特定情報の生成の度に、生成回数として記憶する値を１だけインクリメントする。
【００３８】
送信部９は、特定情報生成部７により生成された特定情報を管理装置２に送信する。これにより、管理装置２の受信部５は、署名作成者の特定結果を受信する。すなわち、これにより、管理装置２は、いずれの参加者装置により生成された匿名電子署名であるかについて確認することができる。
【００３９】
情報処理システム１では、上述の通り、記憶部８が特定情報の生成回数を記憶する。このため、匿名電子署名を作成した参加者装置が何回特定されたかを管理することが可能となる。このため、匿名電子署名から当該署名を作成したメンバを自由に特定することを抑制することができる。なお、図３では、開示装置３に加え管理装置２を含む情報処理システム１を例示したが、他の実施形態も実現できる。例えば、管理装置２を含まない実施形態、すなわち開示装置３に注目した実施形態も実現できることは言うまでもない。また、開示装置３における上記処理を行なうプログラム又は方法などについての実施形態も実現できる。これらの実施形態においても、特定情報の生成回数が記憶されるため、匿名電子署名から当該署名を作成したメンバを自由に特定することを抑制することができる。
【００４０】
＜第１の実施形態＞
以下、実施形態の詳細について、図面を用いて説明する。以下の実施形態では、英国オークションシステムへの応用を例にとり説明する。けれども、本願開示が適用可能なシステムを英国型匿名オークションシステムに限定する趣旨ではない。管理するデータの正当性を検証可能にしつつ、当該データから管理者が得られる情報を適切に制限する必要なシステムであれば、どのようなシステムであってもよい。例えば、入札価格が上がっていく英国型オークション以外にも、入札価格が下がっていくダッチオークションシステムが上記の条件に該当する。あるいは、上記システムとして英国オークションやダッチオークションのように入札価格がオープンな公開入札方式以外にも、封印入札方式のオークションシステムについても適用可能である。封印入札方式の入札システムでは、管理者が入札の都度、その正当性を検証しつつ、落札者を特定する必要があるが、封印入札方式も落札者以外の参加者の入札価格を特定する必要がないから上記要件に該当する。このように、本願開示は例えば入札の匿名性が求められる任意の電子オークションに適用可能である。
【００４１】
（システム構成概略）
図４は第１の実施形態に係るオークションシステム１１の構成の一例を示す図である。図４を参照すると、オークションシステム１１は管理者装置１０、トラステッドハードウェア２０、参加者装置３０−１〜３０−Ｎ（Ｎは整数、以下同じ）を含んで構成されている。なお、以降の説明において、参加者装置３０−１〜３０−Ｎのそれぞれを区別する特段の必要がない場合には、単に「参加者装置３０」と表記する。管理者装置１０と参加者装置３０は、インターネット等のネットワークを介して相互に接続されている。また、管理者装置１０とトラステッドハードウェア２０もインターネット等のネットワークを介して相互に接続されている。なお、トラステッドハードウェア２０と参加者装置３０も、インターネット等のネットワークを介して相互に接続されてもよい。
【００４２】
（管理者装置１０）
管理者装置１０は、例えばオークションの管理者が所有し、オークションの準備や運営を行うために利用される装置である。管理者装置１０は、図３の管理装置２に対応しており、また、匿名電子署名付きの入札情報を受信し、電子オークションによる競りを管理する装置の一例である。図５は、管理者装置１０の構成の一例を示すブロック図である。図５に示すように、管理者装置１０は、制御部１１０、格納部１２０、通信部１３０を備える。これらの各部は、例えば、デスクトップパソコン、ラップトップパソコン、ワークステーション、タブレット、スマートホン等のコンピュータでプログラムを実行することにより実現する。
【００４３】
したがって、管理者装置１０は、例えば、図６に示すようなハードウェア構成を有する。すなわち、図６に示すように、管理者装置１０は、ネットワークインタフェース１５０、メモリ１５１、及びプロセッサ１５２を含む。なお、後述するように、図６に示す構成は、トラステッドハードウェア２０及び参加者装置３０などの構成としても理解される。
【００４４】
ネットワークインタフェース１５０は、他の装置と通信するために使用される。ネットワークインタフェース１５０は、例えば、ネットワークインタフェースカード（ＮＩＣ）を含んでもよい。
メモリ１５１は、例えば、揮発性メモリ及び不揮発性メモリの組み合わせによって構成される。メモリ１５１は、プロセッサ１５２により実行される、１以上の命令を含むソフトウェア（コンピュータプログラム）などを格納するために使用される。また、メモリ１５１は格納部１２０による情報の保存領域として使用される。
プロセッサ１５２は、メモリ１５１からソフトウェア（コンピュータプログラム）を読み出して実行することで、図５に示した各構成の処理を行う。プロセッサ１５２は、例えば、マイクロプロセッサ、ＭＰＵ(Micro Processor Unit)、又はＣＰＵ(Central Processing Unit)などであってもよい。プロセッサ１５２は、複数のプロセッサを含んでもよい。
【００４５】
図５に戻り、図５に示した各構成の説明を続ける。
制御部１１０は、パラメータ設定部１１１、署名鍵ペア生成部１１２、署名生成部１１３、署名検証部１１４、及び価格検証部１１５、及びグループ署名作成者確認部１１６を備える。
【００４６】
パラメータ設定部１１１はオークションに用いるグループ署名作成用のパラメータを設定する。なお、設定されるパラメータの詳細については後述する。
署名鍵ペア生成部１１２はデジタル署名生成用の署名鍵と、生成されたデジタル署名を検証するための検証鍵とからなる鍵ペアを生成する。
【００４７】
署名生成部１１３は、署名鍵ペア生成部１１２が生成し、管理者装置１０が保有する前記署名鍵でデジタル署名を生成する。管理者装置１０が送信する情報にデジタル署名を付け、受信側が予め取得した、署名鍵ペア生成部１１２で生成された検証鍵を用いてそのデジタル署名を検証することで、受信側は当該情報が管理者装置１０により作成された情報であることを確認できる。
【００４８】
署名検証部１１４は、参加者装置３０又はトラステッドハードウェア２０が作成するデジタル署名の検証、及び参加者装置３０が作成するグループ署名の検証をする。署名検証部１１４は、参加者装置３０の後述する署名鍵ペア生成部３１１が生成し、管理者装置１０が予め署名検証鍵格納部１２３に格納した検証鍵を用いて、参加者装置３０が送信した情報に付けられているデジタル署名を検証する。同様に、署名検証部１１４は、予め署名検証鍵格納部１２３に格納された、トラステッドハードウェア２０の後述する署名鍵ペア生成部２１２が生成した検証鍵を用いて、トラステッドハードウェア２０が送信した情報に付けられているデジタル署名を検証する。なお、署名検証部１１４によるグループ署名の検証の詳細については後述する。
【００４９】
価格検証部１１５は、新しい入札メッセージ（入札価格とグループ署名）を受け取った際に、提示された入札価格が入札情報格納部１２２によって格納された現在の最高価格より大きいか否かを検証する。また、価格検証部１１５は、入札価格が現在の最高価格よりも大きい場合は、価格を更新するメッセージ（更新された現在の最高価格を示すメッセージ）を作成する。以下、このメッセージについて、価格更新メッセージと称す。
【００５０】
グループ署名作成者確認部１１６は、トラステッドハードウェア２０から受信した、グループ署名の作成者を特定する情報（以下、グループ署名作成者特定情報と称す）を用いて、グループ署名の作成者のＩＤ（参加者装置３０のＩＤ）を特定する。グループ署名作成者確認部１１６は、データ格納部１２１が格納した情報と、グループ署名作成者特定情報とに基づいて、当該グループ署名作成者特定情報に対応するＩＤを特定する。
【００５１】
格納部１２０は、データ格納部１２１、入札情報格納部１２２、及び署名検証鍵格納部１２３を備える。
データ格納部１２１は参加者装置３０からグループへの登録の際に受け取った情報（後述の登録動作で説明）とＩＤのペアをメモリ１５１などの記憶装置に格納する。ＩＤはグループ署名におけるグループのメンバを識別できるものであればよく、管理者装置１０が生成してもよいし、参加者装置３０が生成し管理者装置１０に通知したものでもよい。例えば、ＩＤは、メールアドレス、電話番号、文字列、画像、音などでもよい。
【００５２】
入札情報格納部１２２は参加者装置３０から受け取った入札メッセージをメモリ１５１などの記憶装置に格納する。
署名検証鍵格納部１２３はトラステッドハードウェア２０と参加者装置３０のデジタル署名を検証するために公開された検証鍵をメモリ１５１などの記憶装置に格納する。すなわち、署名検証鍵格納部１２３はオークションの開始前に予めトラステッドハードウェア２０及び参加者装置３０から取得したデジタル署名用の検証鍵をメモリ１５１などの記憶装置に格納する。
【００５３】
通信部１３０は情報通信部１３１を備える。情報通信部１３１はグループをセットアップする際のトラステッドハードウェア２０及び参加者装置３０との通信を、ネットワークインタフェース１５０を用いて行なう。また、さらに、情報通信部１３１は参加者装置３０からの入札メッセージの受信、トラステッドハードウェア２０との価格更新メッセージの送受信、参加者装置３０への価格更新メッセージの送信を、ネットワークインタフェース１５０を用いて行なう。情報通信部１３１は無線通信により通信を実施しもよいし有線通信により通信を実施してもよいし、これらの組み合わせにより通信を実施してもよい。なお、情報通信部１３１は、図３の送信部４及び受信部５に相当する。
【００５４】
（トラステッドハードウェア２０）
トラステッドハードウェア２０は管理者装置１０との通信によりオークションにおいて開示管理者の役割を担い、オークション管理者の権限を制限するための装置である。トラステッドハードウェア２０は、図３の開示装置３に対応しており、また、匿名電子署名を作成したメンバである参加者装置３０を特定する装置の一例である。トラステッドハードウェア２０は、いわゆるトラステッドハードウェアとして構成された装置である。
【００５５】
近年、暗号技術の応用における信頼の起点を人から安全な装置に移すための技術開発が進められている。その結果、デバイスの外部へ機密情報を漏らすことなく、安全に公開鍵ペアを生成したり、データを暗号化して保管したりするなどのことができるハードウェアが製品化されている。このようなデバイスは信頼の起点となり得ると言う意味でトラステッドハードウェアと呼ばれており、例えば、Intel SGXやARM社のTrustZoneなどがある。
【００５６】
このため、トラステッドハードウェア２０は予めプログラムした通りに動作し、内部で保管される情報への外部からの不正なアクセスを許さない装置である。すなわち、トラステッドハードウェア２０内のデータの漏洩を防ぐための機構を有することが予め保障されている装置である。トラステッドハードウェアは例えばオークション管理者が所有するが、上述の通りトラステッドハードウェアはセキュアな構成であるため安全性が担保されているので、オークション管理者以外が所有しても構わない。
【００５７】
図７は、トラステッドハードウェア２０の構成の一例を示すブロック図である。図７に示すように、トラステッドハードウェア２０は制御部２１０、格納部２２０、通信部２３０を備える。これらの各部は、コンピュータとしてのトラステッドハードウェア２０がプログラムを実行することにより実現する。すなわち、トラステッドハードウェア２０は、管理者装置１０と同様、例えば図６に示す構成を有している。したがって、例えば、トラステッドハードウェア２０のメモリ１５１は格納部２２０による情報の保存領域として使用される。また、トラステッドハードウェア２０のプロセッサ１５２は、トラステッドハードウェア２０のメモリ１５１からソフトウェア（コンピュータプログラム）を読み出して実行することで、図７に示した各構成の処理を行う。
【００５８】
このような構成により、トラステッドハードウェア２０は後述する開示管理者の秘密鍵（前述の「特権者用秘密鍵」に相当する）を保持し、入札メッセージに含まれるグループ署名を基に作成者を特定できる情報を開示する。また、開示の回数に応じて増加する開示回数カウンタの値を保持し、管理者装置１０が送信するメッセージに開示回数カウンタの値を添付する。
【００５９】
制御部２１０はデータ開示部２１１、署名鍵ペア生成部２１２、署名生成部２１３、署名検証部２１４、パラメータ設定部２１５、及び開示回数付与メッセージ生成部２１６を備える。
【００６０】
データ開示部２１１は、図３の特定情報生成部７に相当する。データ開示部２１１は管理者装置１０から開示依頼メッセージがあった場合、それに含まれるグループ署名を基にその作成者（参加者装置３０）を特定できる情報を抽出する。
署名鍵ペア生成部２１２はトラステッドハードウェア２０から送信するメッセージに付与されるデジタル署名の生成用の署名鍵と、生成されたデジタル署名を検証するための検証鍵とからなる鍵ペアを生成する。
【００６１】
署名生成部２１３はトラステッドハードウェア２０が送信するメッセージに付与するデジタル署名を署名鍵ペア生成部２１２が生成した署名鍵を使って生成する。このデジタル署名が付与されたメッセージを受信した装置は、予め取得した、署名鍵ペア生成部２１２で生成された検証鍵を用いてデジタル署名を検証することで、当該メッセージがトラステッドハードウェア２０により作成されたものであることを確認できる。
【００６２】
署名検証部２１４は管理者装置１０から受信したメッセージに付与されたデジタル署名を管理者装置１０から事前に受信した検証鍵で検証する。より詳細には、署名検証部２１４は、管理者装置１０の署名鍵ペア生成部１１２が生成しトラステッドハードウェア２０の署名検証鍵格納部２２２が予め記憶装置に格納した検証鍵を用いて、管理者装置１０が送信した情報に付けられているデジタル署名を検証する。
【００６３】
パラメータ設定部２１５は管理者装置１０から受信したパラメータを基に開示管理者用鍵ペア（すなわち、後述のステップＳ１０５で生成される開示管理者の公開鍵YRと秘密鍵ω）を生成する。なお、開示管理者用鍵ペアは、上述した特権者用秘密鍵と特権者用公開鍵に相当する。
【００６４】
開示回数付与メッセージ生成部２１６は、トラステッドハードウェア２０が管理者装置１０から価格更新メッセージを受信すると、受信した価格更新メッセージと、開示回数格納部２２１が格納した現在のカウンタ値とを関連づけた情報（メッセージ）を生成する。すなわち、このメッセージは、現在の価格と現在のカウンタ値とを含む。このメッセージは価格更新メッセージとして、参加者装置３０に通知されることとなる。
【００６５】
格納部２２０は開示回数格納部２２１と署名検証鍵格納部２２２を備える。
開示回数格納部２２１はトラステッドハードウェア２０がグループ署名作成者の情報を開示した回数（換言すると、トラステッドハードウェア２０がグループ署名作成者の情報を生成した回数）を数えるためのカウント値をメモリ１５１などの記憶装置に格納する。簡単のため、開示回数のカウンタ値はゼロから始まるとする。なお、開示回数格納部２２１は、図３の記憶部８に相当する。
【００６６】
署名検証鍵格納部２２２は管理者装置１０のデジタル署名を検証するために公開された検証鍵（管理者装置１０の署名鍵ペア生成部１１２により生成された検証鍵）をメモリ１５１などの記憶装置に格納する。
【００６７】
通信部２３０は情報通信部２３１を備える。情報通信部２３１はトラステッドハードウェア２０と管理者装置１０の間の通信を、ネットワークインタフェース１５０を用いて行う。情報通信部２３１は無線通信により通信を実施してもよいし有線通信により通信を実施してもよいし、これらの組み合わせにより通信を実施してもよい。なお、情報通信部２３１は、図３の受信部６及び送信部９に相当する。
【００６８】
（参加者装置３０）
参加者装置３０は例えばオークションに参加する参加者が所有し、入札を行うために利用される装置である。図８は、参加者装置３０の構成の一例を示すブロック図である。図８に示すように、参加者装置３０は制御部３１０、格納部３２０、及び通信部３３０を備える。これらの装置は例えば、デスクトップパソコン、ラップトップパソコン、ワークステーション、タブレット、スマートホン等のコンピュータでプログラムを実行することにより実現する。すなわち、図８に示した各部は、コンピュータとしての参加者装置３０がプログラムを実行することにより実現する。つまり、参加者装置３０は、管理者装置１０と同様、例えば図６に示す構成を有している。したがって、例えば、参加者装置３０のメモリ１５１は格納部３２０による情報の保存領域として使用される。また、参加者装置３０のプロセッサ１５２は、参加者装置３０のメモリ１５１からソフトウェア（コンピュータプログラム）を読み出して実行することで、図８に示した各構成の処理を行う。
【００６９】
制御部３１０は署名鍵ペア生成部３１１、署名生成部３１２、署名検証部３１３、パラメータ設定部３１４、入札メッセージ生成部３１５、及びカウント値検証部３１６を備える。
【００７０】
署名鍵ペア生成部３１１はオークション開始前に参加者装置３０が管理者装置１０と行う通信において通信内容に付与するデジタル署名を生成するための署名鍵と、生成されたデジタル署名を検証するための検証鍵を生成する。
【００７１】
署名生成部３１２は前記デジタル署名の生成と、入札メッセージに付与するグループ署名の生成とを行なう。署名生成部３１２は署名鍵ペア生成部３１１が生成した署名鍵を用いてデジタル署名を生成する。グループ署名はメンバ用秘密鍵を知らない限り作成できない複数のゼロ知識証明データから構成される。具体的な構成方法は後述するが、署名生成部３１２は、メンバ用秘密鍵、グループ署名用公開鍵を用いてゼロ知識証明データ、すなわちグループ署名を作成する。
【００７２】
署名検証部３１３は管理者装置１０からのメッセージに含まれる管理者装置１０又はトラステッドハードウェア２０のデジタル署名を検証する。署名検証部３１３は、管理者装置１０の署名鍵ペア生成部１１２が生成した検証鍵又はトラステッドハードウェア２０の署名鍵ペア生成部２１２が生成した検証鍵を用いて行う。
【００７３】
パラメータ設定部３１４は管理者装置１０から受信したパラメータを基に参加者鍵ペアを生成する。参加者鍵ペアは、前述のグループメンバ用公開鍵とグループメンバ用秘密鍵に対応する。
【００７４】
入札メッセージ生成部３１５は、電子オークションの入札情報、すなわち入札価格を示す情報を生成する。入札メッセージ生成部３１５は、例えば、ユーザからの入力操作等で指示された価格を入札価格としたメッセージを生成する。
【００７５】
カウント値検証部３１６は、価格更新メッセージに付与されているカウント値に基づいて、署名者の不正な特定が行なわれていないかを検証する。具体的には、カウント値検証部３１６は、入札開始から落札に至るまでのオークション中に参加者装置３０が受信する価格更新メッセージのそれぞれに付与されているカウント値が同じであるか否かを判定することによりカウント値の検証を行なう。カウント値検証部３１６は、これらが同じである場合、署名者の不正な特定が行なわれていないと判定する。
【００７６】
格納部３２０は署名検証鍵格納部３２１と開示回数格納部３２２を備える。
署名検証鍵格納部３２１は管理者装置１０のデジタル署名を検証するために公開された検証鍵とトラステッドハードウェア２０のデジタル署名を検証するために公開された検証鍵をメモリ１５１などの記憶装置に格納する。すなわち、署名検証鍵格納部３２１は、管理者装置１０の署名鍵ペア生成部１１２により生成された検証鍵と、トラステッドハードウェア２０の署名鍵ペア生成部２１２により生成された検証鍵とを格納する。
【００７７】
開示回数格納部３２２はトラステッドハードウェア２０が後述の価格更新メッセージに付与する開示回数のカウント値をメモリ１５１などの記憶装置に格納する。簡単のため、開示回数格納部３２２は、初期値としてゼロを格納する。
【００７８】
通信部３３０は情報通信部３３１を備える。情報通信部３３１は参加者装置３０と管理者装置１０の間の通信を、ネットワークインタフェース１５０を用いて行う。情報通信部３３１は無線通信により通信を実施してもよいし有線通信により通信を実施してもよいし、これらの組み合わせにより通信を実施してもよい。
【００７９】
（動作の説明）
次に、管理者装置１０、トラステッドハードウェア２０、及び参加者装置３０を含むオークションシステム１１の概略動作を、図面を参照しながら説明する。ここで、管理者装置１０、トラステッドハードウェア２０、及び参加者装置３０は事前にそれぞれ署名鍵ペア生成部１１２、署名鍵ペア生成部２１２、署名鍵ペア生成部３１１によりデジタル署名生成用の署名鍵と検証鍵を生成しているものとする。また、管理者装置１０、トラステッドハードウェア２０、及び参加者装置３０は、事前にお互いに生成した検証鍵を交換しているものとする。このため、管理者装置１０の署名検証鍵格納部１２３、トラステッドハードウェア２０の署名検証鍵格納部２２２、及び参加者装置３０の署名検証鍵格納部３２１は、それぞれ、他の装置のデジタル署名の検証鍵を記憶装置に格納している。
【００８０】
なお、トラステッドハードウェア２０がトラステッドハードウェアであることとその内部プログラムを参加者が検証できることが望ましい。トラステッドハードウェア２０がトラステッドハードウェアであるか否かに関しては例えば、トラステッドハードウェア２０の製造者による証明により、検証できる。また、内部で保管するプログラムに関しては、求められた場合にトラステッドハードウェア２０がプログラムそのもの、あるいはそのハッシュ値にデジタル署名を添付して出力できるようにすれば、検証が可能である。これにより、検証者は開示管理者の役割が正しく実装されているか、内部で生成した秘密鍵を外部に出力していないかなどを確認できる。
【００８１】
（セットアップ動作）
まず、オークションの開始前に行なわれるセットアップ動作を図９を参照しながら説明する。
（ステップＳ１０１）管理者装置１０のパラメータ設定部１１１は、グループ署名の作成に必要なパラメータを設定する。具体的なパラメータの内容は以下の通りである。
n, e： ＲＳＡ（Rivest-Shamir-Adleman）公開鍵暗号化方式の公開鍵。
d：オークション管理者の秘密鍵。
ここでnはセキュリティパラメータによって決まる所定のビット数の２つの素数の積であり、セキュリティパラメータは例えば、生成する鍵の長さである。なお、管理者装置１０はオークション管理者の秘密鍵dをメンバ証明書を作成するのに用いる。
p：p-1がnの倍数となる素数。
g：位数nの巡回群Gの生成元。GはZp*の部分群。ここでZp*はpを法とする既約剰余類群である。
a：Zn*の元であって、位数がφ(n)/4である元。ここでφはオイラー関数である。
λ：オークション参加者の秘密鍵と定数εの長さの上限。εはゼロ知識証明データの作成に用いるパラメータである。詳細は非特許文献３を参照せよ。
【００８２】
（ステップＳ１０２）管理者装置１０の署名生成部１１３は、ステップＳ１０１で生成したオークション管理者の秘密鍵以外のパラメータを含むメッセージにデジタル署名を付与する。
（ステップＳ１０３）そして、管理者装置１０の情報通信部１３１はオークション管理者の秘密鍵以外のパラメータをグループ署名用署名パラメータとしてトラステッドハードウェア２０に送信する。
【００８３】
（ステップＳ１０４）トラステッドハードウェア２０の署名検証部２１４は、管理者装置１０から受信したメッセージに付与されたデジタル署名を署名検証鍵格納部２２２が格納した検証鍵を用いて検証する。
（ステップＳ１０５）管理者装置１０から受信したパラメータを用いて、トラステッドハードウェア２０のパラメータ設定部２１５は、以下を計算する。
ω：Zn*のランダムな元（乱数）。ここで、ωは、開示管理者の秘密鍵として用いられる。
h：Gのランダムな生成元。
YR：YR = hω 。ここで、YRは、開示管理者の公開鍵として用いられる。
b：1以外の整数。
（ステップＳ１０６）トラステッドハードウェア２０の署名生成部２１３は、(h, b, YR)にデジタル署名を付ける。
（ステップＳ１０７）そして、トラステッドハードウェア２０の情報通信部２３１は、ステップＳ１０６でデジタル署名が付与されたメッセージを、開示管理者用公開鍵として管理者装置１０に送信する。
【００８４】
（ステップＳ１０８）管理者装置１０の署名検証部１１４は、トラステッドハードウェア２０から受け取ったメッセージのデジタル署名を検証する。
（ステップＳ１０９）管理者装置１０の署名生成部１１３はグループの公開鍵Y=(n, e, G, g, a, b, λ, ε, h, YR)にデジタル署名を付与する。
（ステップＳ１１０）管理者装置１０の情報通信部１３１はステップＳ１０９で作成したメッセージを参加者装置３０に送信する。
【００８５】
（ステップＳ１１１）参加者装置３０の署名検証部３１３は、署名検証鍵格納部３２１が格納した管理者装置１０の署名検証鍵を用いて、管理者装置１０から受け取ったメッセージのデジタル署名を検証する。
【００８６】
（登録動作）
次に、引き続き図９を参照しながら、参加者装置３０のグループへの登録動作を説明する。
（ステップＳ１１２）ステップＳ１１１の後、参加者装置３０のパラメータ設定部３１４は、グループ公開鍵を基に、以下を計算することにより、参加者鍵ペア（すなわち、グループメンバ用秘密鍵、及びグループメンバ用公開鍵）を生成する。
x：2λ-1より小さい乱数。
y：y=gx mod n
ここで、xはグループメンバ用秘密鍵で、yはグループメンバ用公開鍵である。
（ステップＳ１１３）参加者装置３０の署名生成部３１２は、ステップＳ１１２で生成したグループメンバ用公開鍵yにデジタル署名を付与する。
（ステップＳ１１４）参加者装置３０の情報通信部３３１は、デジタル署名付きのグループメンバ用公開鍵yを管理者装置１０に送信する。
【００８７】
（ステップＳ１１５）管理者装置１０の署名検証部１１４は署名検証鍵格納部１２３が格納した署名検証鍵を用いて、参加者装置３０から受信したメッセージに含まれるデジタル署名を検証する。
（ステップＳ１１６）管理者装置１０のデータ格納部１２１はグループメンバ用公開鍵yと参加者装置３０のIDとを対にして保存する。このデータはのちに参加者装置３０を特定する際に用いる。
（ステップＳ１１７）管理者装置１０のパラメータ設定部１１１は、以下に示す式１を計算することによりメンバ証明書ｖを計算する。
（式１）v = (y + b)d mod n
（ステップＳ１１８）管理者装置１０の署名生成部１１３はステップＳ１１７で生成したメンバ証明書にデジタル署名を付与する。
（ステップＳ１１９）管理者装置１０の情報通信部１３１は、デジタル署名付きのメンバ証明書を参加者装置３０に送信する。
（ステップＳ１２０）参加者装置３０の署名検証部３１３は、署名検証鍵格納部３２１が格納した署名検証鍵を用いて、管理者装置１０から受信したメッセージのデジタル署名を検証する。
【００８８】
以上説明した登録動作により、参加者装置３０にグループ署名を作成するのに必要な参加者用秘密鍵xとメンバ証明書vが揃う。
【００８９】
（入札動作）
次に、図１０を参照しながら参加者装置３０が入札する際の概略動作を説明する。なお、ここでは、参加者装置３０のうち参加者装置３０−Ｎが入札を行なった場合を例に説明する。
【００９０】
（ステップＳ２０１）参加者装置３０−Ｎの署名生成部３１２は入札メッセージ生成部３１５が生成した入札メッセージm（すなわち、入札価格）に対し、以下の手順でグループ署名（g’, z’, d1, d2, V1, V2, V3）を生成する。
署名生成部３１２は、まず、以下（式２〜式５）を計算する。
r, u：Zn*内の乱数
（式２）g’ = gr
（式３）z’= g’y
（式４）d1 = YRu gy 
（式５）d2 = hu
次に、署名生成部３１２は、これらと前記参加者用の秘密鍵と前記メンバ証明書と前記入札メッセージmを用いて以下の式（式６〜式８）で示される３つゼロ知識証明データV1、V2、V3を作成する。
（式６）V1 = SK{(γ, δ)：z’ = g’γ Λ d2 = hδ Λ d1 = YRδgγ}(m)
（式７）V2 = SK{(β)：z’ = g’^（ａ^β）}(V1)
（式８）V3 = SK{(α)：z’g’b = g’^(α^ｅ)}(V2)
【００９１】
ここでゼロ知識証明データに係る記号の説明をする。SK{(x1,…, xk)：z1 = f1(x1,…, xk) ∧ … ∧ zl = fl(x1,…, xk)}(m)は、z1 = f1(x1,…, xk)からzl = fl(x1,…, xk)までの式を満たす秘密x1,…, xkを知っていることを証明するデータをメッセージmに付与したことを示している。
【００９２】
ゼロ知識証明の詳細な説明は非特許文献４に譲るとして、ここではV3を例にとりゼロ知識証明データの作成方法と検証方法を説明する。ゼロ知識証明データV3の実態は以下の式９を満たす（V2, c, s, g0, … , ge）である。
（式９）c = H(V2||g0||…||ge||g0r||…||ge-1r)
ここで、上記式に示す記号及び変数は次の通りある。
||: 連結演算子
H：ハッシュ関数
r：Zn*内の乱数
s = r - cα mod n
g0 = g’
gi+1 = giα  （ここで、ｉ = 0, …, e - 1）
【００９３】
なお、管理者装置１０の署名検証部１１４は、このゼロ知識証明データを検証するときは(V2, c, s, g0, … , ge)とグループの公開鍵Yを用いて以下の二つの式（式１０、式１１）が成立するかを検証する。
（式１０）z’g’b = ge
（式１１）c = H(V2||g0||…||ge||g0s g1c ||…||ge-1s gec)
【００９４】
引き続き、ステップＳ２０１以降の動作について説明する。
（ステップＳ２０２）参加者装置３０−Ｎの情報通信部３３１は、グループ署名付きの入札メッセージを管理者装置１０に送信する。
（ステップＳ２０３）管理者装置１０の署名検証部１１４は、参加者装置３０−Ｎから受信した入札メッセージのグループ署名を検証する。
（ステップＳ２０４）管理者装置１０の価格検証部１１５は、入札情報格納部１２２が格納した現在の最高価格と比較することにより、受信した入札メッセージに示される価格が、現在の最高価格を更新する価格であるか否かを検証する。
（ステップＳ２０５）入札価格が最高価格を更新している場合は、管理者装置１０の価格検証部１１５は、価格更新メッセージ（更新された現在の最高価格を示すメッセージ）を作成する。そして、署名生成部１１３は、価格更新メッセージに対し、デジタル署名を付与する。
（ステップＳ２０６）管理者装置１０の情報通信部１３１は、価格更新メッセージをトラステッドハードウェア２０に送信する。すなわち、管理者装置１０の情報通信部１３１は、電子オークションにおける現在の評価値（すなわち、競り対象の評価値）を更新する場合、評価値の更新情報（すなわち、更新後の評価値）をトラステッドハードウェア２０に送信する。なお、本実施の形態では評価値は一例として価格であるが、オークション対象の価値を示す他の値が評価値として用いられてもよいことは言うまでもない。これにより、トラステッドハードウェア２０の情報通信部２３１は、電子オークションにおける現在の評価値の更新情報を受信する。
【００９５】
（ステップＳ２０７）トラステッドハードウェア２０の署名検証部２１４は、署名検証鍵格納部２２２が格納した検証鍵を用いて、価格更新メッセージのデジタル署名を検証する。
（ステップＳ２０８）署名を検証できた場合は、トラステッドハードウェア２０の開示回数付与メッセージ生成部２１６は開示回数のカウント値と最高価格とを合わせたメッセージを作成する。
（ステップＳ２０９）トラステッドハードウェア２０の署名生成部２１３は、ステップＳ２０８で作成されたメッセージ、すなわちカウント値を含む価格更新メッセージに対するデジタル署名を生成し、生成したデジタル署名をこのメッセージに付与する。
（ステップＳ２１０）トラステッドハードウェア２０の情報通信部２３１は、デジタル署名が付与された価格更新メッセージを管理者装置１０に送信する。なお、本実施の形態では、トラステッドハードウェア２０と参加者装置３０が通信可能に接続していない場合を説明しているが、これらが接続している場合は価格更新メッセージをトラステッドハードウェア２０から直接、参加者装置３０に送信しても構わない。このように、トラステッドハードウェア２０の情報通信部２３１は、価格更新メッセージと、記憶されている現在の開示回数（グループ署名作成者特定情報の生成回数）とを関連づけた情報を送信する。
【００９６】
（ステップＳ２１１）管理者装置１０の署名検証部１１４は、署名検証鍵格納部１２３が格納した署名検証鍵を用いて、トラステッドハードウェア２０から受信したメッセージのデジタル署名を検証する。
（ステップＳ２１２）管理者装置１０の情報通信部１３１は、開示回数のカウント値を含む価格更新メッセージを全ての参加者装置３０に送信する。
【００９７】
（ステップＳ２１３）参加者装置３０の署名検証部３１３は署名検証鍵格納部３２１が格納したトラステッドハードウェア２０の署名検証鍵を用いて、管理者装置１０から受信したメッセージに付与されているトラステッドハードウェア２０のデジタル署名を検証する。
（ステップＳ２１４）参加者装置３０のカウント値検証部３１６は管理者装置１０から今回受信した価格更新メッセージに含まれる開示回数のカウント値と前回受信した価格更新メッセージに含まれていた開示回数のカウント値とが同じであるかを確認する。これらが異なる場合、入札者の特定が行なわれたことを意味する。また、これらが異なる場合は、カウント値検証部３１６が、これら２つのカウント値の差を計算することにより、管理者装置１０が入札者情報の特定を何回行ったかを知ることができる。
【００９８】
（特定動作）
次に、管理者装置１０が入札メッセージとそれに含まれるグループ署名を作成した参加者装置３０を特定する際の、管理者装置１０とトラステッドハードウェア２０の動作を図１１を用いて説明する。
【００９９】
（ステップＳ３０１）オークション終了後に、管理者装置１０の署名生成部１１３は、入札情報格納部１２２が格納した、最高価格を入札した入札メッセージから（d1, d2）を取得し、これにデジタル署名を付与する。
（ステップＳ３０２）管理者装置１０の情報通信部１３１は、上記デジタル署名付きの（d1, d2）をトラステッドハードウェア２０に送信することで、グループ署名の作成者を特定する情報の開示をトラステッドハードウェア２０に依頼する。すなわち、情報通信部１３１は、落札者のグループ署名をトラステッドハードウェア２０に送信することにより、当該落札者を特定する情報の開示をトラステッドハードウェア２０に要求する。このように、情報通信部１３１は、管理者装置１０が受信した入札情報のうち送信元の参加者装置を特定すべき入札情報に付与されていた匿名電子署名をトラステッドハードウェア２０に送信する。そして、トラステッドハードウェア２０の情報通信部２３１は、この匿名電子署名を管理者装置１０から受信する。
【０１００】
（ステップＳ３０３）トラステッドハードウェア２０の署名検証部２１４は、署名検証鍵格納部２２２が格納した検証鍵を用いて、管理者装置１０から受信したメッセージのデジタル署名を検証する。
（ステップＳ３０４）トラステッドハードウェア２０のデータ開示部２１１は、保有する秘密鍵ωを用いて式１２に示すように、グループ署名作成者特定情報zを計算する。
（式１２）z = d1/d2ω = gy 
（ステップＳ３０５）トラステッドハードウェア２０の開示回数格納部２２１は、現在格納されているカウント値を１だけ増やした値を、新たなカウント値として格納する。
（ステップＳ３０６）トラステッドハードウェア２０の署名生成部２１３は、前記グループ署名作成者特定情報zにデジタル署名を付与する。
（ステップＳ３０７）トラステッドハードウェア２０の情報通信部２３１は、デジタル署名付きのグループ署名作成者特定情報zを落札者情報として管理者装置１０に送信する。これにより、管理者装置１０の情報通信部１３１は、トラステッドハードウェア２０からグループ署名作成者特定情報zを受信する。
【０１０１】
（ステップＳ３０８）管理者装置１０の署名検証部１１４は、署名検証鍵格納部１２３が格納した署名検証鍵を用いて、トラステッドハードウェア２０から受信したメッセージのデジタル署名を検証する。
（ステップＳ３０９）管理者装置１０がグループ署名作成者特定情報zを受け取ると、管理者装置１０のグループ署名作成者確認部１１６は、データ格納部１２１が格納した情報と、グループ署名作成者特定情報zとを用いて、参加者装置３０のIDを特定する。
【０１０２】
以上、第１の実施形態について説明した。第１の実施形態にかかるオークションシステム１１においては、トラステッドハードウェア２０において、グループ署名作成者特定情報zの生成回数（開示回数）が記録される。したがって、グループ署名を作成した参加者装置が何回特定されたかを管理することが可能となる。このため、グループ署名を作成したメンバを自由に特定することを抑制することができる。また、オークションシステム１１では、図１０のステップＳ２１０で示したように、トラステッドハードウェア２０が、価格更新メッセージとグループ署名作成者特定情報zの現在の生成回数（開示回数）とを関連づけた情報を送信する。このため、参加者装置３０は、オークションにおける価格更新の度に、不正な開示の有無を把握することができる。すなわち、管理者装置１０からの価格更新メッセージに含まれるトラステッドハードウェア２０のカウント値を参加者装置３０が把握することが可能となり、それにより、入札の途中で管理者装置１０が入札者の特定を行ったかを検知することが可能となる。また、図１０のステップＳ２１０では、トラステッドハードウェア２０の情報通信部２３１は、トラステッドハードウェア２０のデジタル署名が付与されたメッセージを送信している。このため、参加者装置３０が受信したカウンタ値がトラステッドハードウェア２０から送信されたものであることを保障することができる。さらに、トラステッドハードウェア２０は、データの漏洩を防ぐための機構を有することが予め保障されている。このため、トラステッドハードウェア２０以外の装置が、不正にトラステッドハードウェア２０から入手した秘密鍵に基づいて、カウンタ値の更新を経ずに、グループ署名作成者特定情報を生成できない。
【０１０３】
＜第２の実施形態＞
次に、第２の実施形態について説明する。第１の実施形態では、参加者装置３０は、価格更新メッセージに含まれる開示回数のカウント値を把握することにより、入札の途中で管理者装置１０が入札者の特定を行ったかを検知することができた。けれども、入札の終了後にオークション管理者（管理者装置１０）が、トラステッドハードウェア２０にグループ署名作成者特定情報の開示を依頼した場合、参加者（参加者装置３０）に知られることなく入札者の特定ができてしまう恐れがある。このような事態を防ぐために、第２の実施形態では、トラステッドハードウェア２０の代わりに、開示回数に上限値を設ける機能を有するトラステッドハードウェア４０を用いる。なお、第１の実施形態と同様、本実施形態でも、管理者装置１０及び参加者装置３０がオークションシステムに用いられる。以下、第１の実施形態と同様な構成及び動作については、重複する説明を適宜省略する。
【０１０４】
トラステッドハードウェア４０は、格納部２２０が格納部４２０に置き換えられた点で、トラステッドハードウェア２０と異なっている。格納部４２０は、開示回数上限値格納部４２３を有する点で、格納部２２０と異なっている。
【０１０５】
開示回数上限値格納部４２３は、グループ署名作成者特定情報の開示回数、すなわち、グループ署名作成者特定情報の生成回数の上限を、メモリ１５１などの記憶装置に格納する。格納される上限値はセットアップ段階で設定される。セットアップ段階でこの上限値が参加者装置３０に通知される。これにより、オークション参加者はオークション管理者が何回、入札者を特定できるかを知ることができる。簡単のため、本実施の形態では、格納される上限値を１とするが、１に限らず、オークション管理者と参加者間で合意が取れた値ならいくつでも構わない。この上限値は、電子オークションにおける最大落札者数であってもよい。最大落札者数を上限値とすることにより、落札者以外の入札者が不正に特定されることを抑制することができる。
【０１０６】
本実施の形態では、データ開示部２１１は、グループ署名作成者特定情報の開示回数（生成回数）が予め設定された上限値未満である場合、新たにグループ署名作成者特定情報を生成する。このため、入札者特定動作時に、管理者装置１０からグループ署名作成者特定情報の開示依頼をトラステッドハードウェア４０が受けると、データ開示部２１１は、次のように動作する。すなわち、データ開示部２１１は、グループ署名作成者特定情報の開示回数についてのカウント値が、開示回数上限値格納部４２３により記憶された上限値未満である場合に限り、開示管理者用の秘密鍵ωを用いてグループ署名作成者特定情報を計算する。
【０１０７】
（動作の説明）
以下、第２の実施形態に係るオークションシステムの動作について説明する。
（セットアップ動作）
図１３を参照しながら、第２の実施形態に係る英国オークションシステムにおけるセットアップ動作を説明する。なお、以下の説明では、図９に示したステップと同様のステップについては、説明を省略する。省略された説明については、適宜、図９における説明のトラステッドハードウェア２０をトラステッドハードウェア４０と読み替えることで、図１３における説明とすることができる。
【０１０８】
図１３に示したシーケンス図は、以下の点で、図９に示したシーケンス図と異なっている。
ステップＳ１０１がステップＳ４０１に置き換えられている。
ステップＳ１０６がステップＳ４０２及びステップＳ４０３に置き換えられている。
ステップＳ１０９がステップＳ４０４に置き換えられている。
ステップＳ１１１とステップＳ１１２の間に、ステップＳ４０５が追加されている。
【０１０９】
以下、図１３に示したシーケンス図について説明する。
（ステップＳ４０１）管理者装置１０のパラメータ設定部１１１は、図９のステップＳ１０１で生成するパラメータの他に、さらに、開示回数上限値Lを設定する。
【０１１０】
ステップＳ４０１の後、処理はステップＳ１０２へ移行する。また、ステップＳ１０２〜ステップＳ１０５の後、処理はステップＳ４０２へ移行する。
【０１１１】
（ステップＳ４０２）トラステッドハードウェア４０の開示回数上限値格納部４２３は、管理者装置１０により設定された開示回数上限値Lを記憶装置に記憶する。これにより、トラステッドハードウェア４０に開示回数上限値Lが設定される。
（ステップＳ４０３）トラステッドハードウェア４０の署名生成部２１３は、(L, h, b, YR)にデジタル署名を付ける。ステップＳ４０３の後、処理はステップＳ１０７へ移行する。また、ステップＳ１０７〜ステップＳ１０８の後、処理はステップＳ４０４へ移行する。
【０１１２】
（ステップＳ４０４）管理者装置１０の署名生成部１１３はグループの公開鍵Y=(n, e, G, g, a, b, λ, ε, h, YR)と、ステップＳ１０７でトラステッドハードウェア４０から受信したメッセージにデジタル署名を付与する。ステップＳ４０４の後、ステップＳ１１０、ステップＳ１１１の処理が行なわれる。ステップＳ１１１の後、処理はステップＳ４０５へ移行する。
【０１１３】
（登録動作）
次に、参加者装置３０のグループへの登録動作を説明する。
（ステップＳ４０５）参加者装置３０の情報通信部３３１は、管理者装置１０から受信した開示回数上限値Lを参加者が認識できる装置に出力する。この出力は、ディスプレイによる表示出力でもよいし、音声により開示回数上限値Lを読み上げる音声出力でも構わない。ステップＳ４０５の後、処理はステップＳ１１２へ移行する。その後、ステップＳ１１２〜ステップＳ１２０の処理が行なわれる。
【０１１４】
（入札動作）
第１の実施形態の説明で参照した図１０と同様の流れで入札動作における処理が行なわれるため、説明を省略する。
【０１１５】
（特定動作）
次に、図１４を参照しながら、第２の実施形態にかかるオークションシステムにおいてグループ署名を作成した参加者装置３０を特定する際の動作を説明する。なお、以下の説明では、図１１に示したステップと同様のステップについては、説明を省略する。
【０１１６】
図１４に示したシーケンス図は、ステップＳ３０３とステップＳ３０４の間にステップＳ５０１が追加されている点で、図１１に示したシーケンス図と異なっている。
ステップＳ３０１〜ステップＳ３０３の後、処理はステップＳ５０１へ移行する。
（ステップＳ５０１）トラステッドハードウェア４０のデータ開示部４１１は、開示回数格納部４２１により格納された現在の開示回数のカウント値が開示回数上限値格納部４２３により格納された上限値より小さいことを確認する。開示回数のカウント値が開示回数上限値以上である場合、トラステッドハードウェア４０のデータ開示部４１１は予め設定された例外処理を実行する。例外処理とは例えば、エラーメッセージや警告メッセージを出力することを指している。開示回数のカウント値が開示回数上限値未満である場合、ステップＳ３０４〜ステップＳ３０９の処理が行なわれる。
【０１１７】
以上、第２の実施形態について説明した。第２の実施形態では、データ開示部２１１は、グループ署名作成者特定情報の生成回数（開示回数）が予め設定された上限値未満である場合、新たにグループ署名作成者特定情報を生成する。これにより、管理者装置１０が入札者情報を特定できる回数を制限することができる。これにより、例えば、オークションが終了した後に、管理者が無制限に入札者を特定することを防ぐことができる。
【０１１８】
＜第３の実施形態＞
次に第３の実施形態について説明する。第２の実施形態では参加者装置３０が管理者装置１０からのみ価格更新メッセージを取得している。この際、管理者装置１０が恣意的に各参加者装置３０に異なる価格更新メッセージを送ることが考えられる。また、管理者装置１０が入札メッセージを意図的に無視したり、偽の高い最高入札価格を含む価格更新メッセージにより不正に価格を操作したりすることを防ぐことが求められる。そこで、第３の実施形態について説明する。なお、以下の説明では、上述した実施形態と同様な構成及び動作については、重複する説明を適宜省略する。
【０１１９】
（システム構成概略）
第３の実施形態について説明する。図１５は、第３の実施形態に係るオークションシステム１３の構成の一例を示す図である。図１５に示されるように、オークションシステム１３は管理者装置５０、トラステッドハードウェア４０、情報共有サーバー６０、及び参加者装置７０−１〜７０−Ｎ（Ｎは整数、以下同じ）を含んで構成されている。なお、以降の説明において、参加者装置７０−１〜７０−Ｎのそれぞれを区別する特段の必要がない場合には、単に「参加者装置７０」と表記する。管理者装置５０とトラステッドハードウェア４０は、通信可能に接続されている。また、情報共有サーバー６０は、管理者装置５０および参加者装置７０と、インターネット等のネットワークを介して相互に接続されている。
【０１２０】
（管理者装置５０）
図１６は管理者装置５０の構成の一例を示すブロック図である。図１６に示すように、管理者装置５０は、制御部１１０、格納部５２０、及び通信部５３０を備える。すなわち、管理者装置５０は、格納部１２０が格納部５２０に置き換わり、通信部１３０が通信部５３０に置き変わった点で、管理者装置１０と異なっている。また、格納部５２０はデータ格納部１２１のみを備える点で、管理者装置１０の格納部１２０と異なっている。通信部５３０は共有情報通信部５３１を備える。共有情報通信部５３１はトラステッドハードウェア４０及び情報共有サーバー６０との通信を、ネットワークインタフェース１５０を用いて行なう。
【０１２１】
（情報共有サーバー６０）
情報共有サーバー６０は、入札情報と署名検証鍵を管理者装置５０と参加者装置７０の間で共有するための装置である。図１７は情報共有サーバー６０の構成の一例を示すブロック図である。図１７に示すように、情報共有サーバー６０は、制御部６１０、通信部６２０と格納部６３０を備える。図１７に示した各部は、コンピュータとしての情報共有サーバー６０がプログラムを実行することにより実現する。つまり、情報共有サーバー６０は、例えば図６に示す構成を有している。したがって、例えば、情報共有サーバー６０のプロセッサ１５２は、情報共有サーバー６０のメモリ１５１からソフトウェア（コンピュータプログラム）を読み出して実行することで、図１７に示した各構成の処理を行う。
【０１２２】
制御部６１０は、情報共有サーバー６０の各部を制御する。格納部６３０は共有情報格納部６３１を備える。共有情報格納部６３１は入札情報と、管理者装置５０、トラステッドハードウェア４０、及び参加者装置７０の署名検証鍵とをメモリ１５１などの記憶装置に格納する。通信部６２０は共有情報通信部６２１を備える。共有情報通信部６２１は管理者装置５０及び参加者装置７０との通信を、ネットワークインタフェース１５０を用いて行う。通信を行うのに必要な情報、例えば、ＩＰアドレス（Internet Protocol Address）などは事前に共有情報通信部６２１に登録されているとする。
【０１２３】
（参加者装置７０）
図１８は、参加者装置７０の構成の一例を示すブロック図である。図１８に示すように、参加者装置７０は制御部３１０、及び通信部７２０を備える。すなわち、参加者装置７０は、格納部３２０が省略され、通信部３３０が通信部７２０に置き変わった点で、参加者装置３０と異なっている。なお、格納部３２０が省略されているのは、本実施形態では、格納部３２０により参加者装置３０に記憶されていた情報が、情報共有サーバー６０に記憶されるためである。通信部７２０は共有情報通信部７２１を備える。共有情報通信部７２１は情報共有サーバー６０との通信を、ネットワークインタフェース１５０を用いて行う。
【０１２４】
（動作の説明）
以下、第３の実施形態に係るオークションシステムの動作について説明する。
（セットアップ動作）
図１９を参照しながら、第３の実施形態に係る英国オークションシステムにおけるセットアップ動作を説明する。なお、以下の説明では、第２の実施の形態で参照した図１３に示したステップと同様のステップについては、説明を省略する。
【０１２５】
図１９に示したシーケンス図は、署名を検証するための検証鍵が情報共有サーバー６０から取得される点と、グループ公開鍵、グループメンバ用公開鍵、及びメンバ証明書の送受信が情報共有サーバー６０を介して行なわれる点で、図１３に示したシーケンス図と異なっている。すなわち、具体的には以下の点で、図１９に示したシーケンス図は、図１３に示したシーケンス図と異なっている。
ステップＳ１０８がステップＳ６０１に置き換えられている。
ステップＳ１１０がステップＳ６０２及びステップＳ６０３に置き換えられている。
ステップＳ１１１がステップＳ６０４に置き換えられている。
ステップＳ１１４がステップＳ６０５及びステップＳ６０６に置き換えられている。
ステップＳ１１５がステップＳ６０７に置き換えられている。
ステップＳ１１９がステップＳ６０８及びステップＳ６０９に置き換えられている。
ステップＳ１２０がステップＳ６１０に置き換えられている。
【０１２６】
以下、図１９に示したシーケンス図について説明する。
ステップＳ４０１〜ステップＳ１０７の後、処理はステップＳ６０１へ移行する。
（ステップＳ６０１）管理者装置５０の共有情報通信部５３１は、情報共有サーバー６０の共有情報格納部６３１により記憶されたトラステッドハードウェア４０の署名検証鍵を取得する。そして、署名検証部１１４は、取得した署名検証鍵を用いて、トラステッドハードウェア４０から受け取ったメッセージのデジタル署名を検証する。なお、これは一つの例であり、管理者装置５０が署名検証鍵を保有しても構わない。ステップＳ６０１の後、処理はステップＳ４０４へ移行し、その後、ステップＳ６０２へ移行する。
【０１２７】
（ステップＳ６０２）管理者装置５０の共有情報通信部５３１は、情報共有サーバー６０にグループ公開鍵（ステップＳ４０４で得られたメッセージ）を送信する。情報共有サーバー６０の共有情報格納部６３１は、受信したグループ公開鍵を情報共有サーバー６０の記憶装置に記憶する。
（ステップＳ６０３）情報共有サーバー６０の共有情報通信部６２１は、参加者装置７０に、管理者装置５０から受信したグループ公開鍵を送信する。なお、これは一つの例であり、参加者装置７０が定期的に情報共有サーバー６０に新着情報を問い合わせるようにしても構わない。また、グループ公開鍵は、情報共有サーバー６０を介さずに直接各参加者装置７０に送信しても構わない。ステップＳ６０３の後、処理はステップＳ６０４へ移行する。
【０１２８】
（ステップＳ６０４）参加者装置７０の共有情報通信部７２１は、情報共有サーバー６０から管理者装置５０の署名検証鍵を取得する。そして、署名検証部３１３は、その署名検証鍵を用い、管理者装置５０のデジタル署名を検証する。なお、これは一つの例であり、参加者装置７０が署名検証鍵を保有しても構わない。ステップＳ６０４の後、処理はステップＳ４０５へ移行する。そして、ステップＳ４０５、ステップＳ１１２、ステップＳ１１３の後、処理はステップＳ６０５へ移行する。
【０１２９】
（ステップＳ６０５）参加者装置７０の共有情報通信部７２１は、参加者用の公開鍵を情報共有サーバー６０に送信する。情報共有サーバー６０の共有情報格納部６３１は、受信した参加者用の公開鍵を情報共有サーバー６０の記憶装置に記憶する。
（ステップＳ６０６）情報共有サーバー６０の共有情報通信部６２１は、参加者用の公開鍵を管理者装置５０に送信する。なお、これは一つの例であり、管理者装置５０が定期的に情報共有サーバー６０に新着情報を問い合わせるようにしても構わない。ステップＳ６０６の後、処理は、ステップＳ６０７へ移行する。
【０１３０】
（ステップＳ６０７）管理者装置５０の共有情報通信部５３１は、情報共有サーバー６０の共有情報格納部６３１により記憶された参加者装置７０の署名検証鍵を取得する。そして、署名検証部１１４は、情報共有サーバー６０を介して参加者装置３０から受け取ったメッセージのデジタル署名を検証する。ステップＳ６０７の後、処理はステップＳ１１６へ移行する。そして、ステップＳ１１６〜ステップＳ１１８の後、処理はステップＳ６０８へ移行する。
【０１３１】
（ステップＳ６０８）管理者装置５０の共有情報通信部５３１は、情報共有サーバー６０にメンバ証明書を送信する。そして、情報共有サーバー６０の共有情報格納部６３１は、受信したメンバ証明書を記憶装置に記憶する。なお、本実施の形態ではＩＤは管理者装置５０のデータ格納部１２１により管理者装置５０に記憶されるが、ＩＤを情報共有サーバー６０に記憶させてもよい。この場合、ステップＳ６０３において、メンバ証明書及びＩＤが送信され、情報共有サーバー６０の共有情報格納部６３１は、受信したメンバ証明書とＩＤのペアを記憶装置に記憶する。
（ステップＳ６０９）情報共有サーバー６０の共有情報通信部６２１は、参加者装置７０に管理者装置５０から受信したメンバ証明書を送信する。ステップＳ６０９の後、処理はステップＳ６１０へ移行する。
【０１３２】
（ステップＳ６１０）参加者装置７０の共有情報通信部７２１は、情報共有サーバー６０から管理者装置５０の署名検証鍵を取得する。そして、署名検証部３１３は、その署名検証鍵を用い、管理者装置５０のデジタル署名を検証する。
【０１３３】
（入札動作）
図２０を参照しながら、第３の実施形態に係る英国オークションシステムにおける入札動作を説明する。なお、以下の説明では、図１０に示したステップと同様のステップについては、説明を省略する。
【０１３４】
本実施形態における入札動作と第２の実施形態における入札動作との違いは、主に次の点である。参加者装置７０は入札メッセージを情報共有サーバー６０に送信する。そして、情報共有サーバー６０はそのメッセージを管理者装置５０に送信する。また、管理者装置５０は最高価格を更新する際、管理者装置５０のデジタル署名付きの価格更新メッセージを情報共有サーバー６０に送信する。そして、情報共有サーバー６０はそのメッセージを参加者装置７０に送信する。参加者装置７０は受信メッセージに含まれるデジタル署名を、情報共有サーバー６０から取得した署名検証鍵を用いて検証する。
【０１３５】
具体的には以下の点で、図２０に示したシーケンス図は、図１０に示したシーケンス図と異なっている。
ステップＳ２０２がステップＳ７０１及びステップＳ７０２に置き換えられている。
ステップＳ２１１がステップＳ７０３に置き換えられている。
ステップＳ２１２がステップＳ７０４及びステップＳ７０５に置き換えられている。
ステップＳ２１３がステップＳ７０６に置き換えられている。
【０１３６】
以下、図２０に示したシーケンス図について説明する。ステップＳ２０１の後、処理はステップＳ７０１、ステップＳ７０２へ移行する。
（ステップＳ７０１）参加者装置７０−Ｎの共有情報通信部７２１は、グループ署名付きの入札メッセージを情報共有サーバー６０に送信する。情報共有サーバー６０の共有情報格納部６３１は、受信した入札メッセージを情報共有サーバー６０の記憶装置に記憶する。
（ステップＳ７０２）情報共有サーバー６０の共有情報通信部６２１は、管理者装置５０に、参加者装置７０−Ｎから受信した入札メッセージを送信する。ステップＳ７０２の後、処理はステップＳ２０３へ移行する。ステップＳ２０３〜ステップＳ２１０の後、処理は、ステップＳ７０３へ移行する。
【０１３７】
（ステップＳ７０３）管理者装置５０の共有情報通信部５３１は、情報共有サーバー６０の共有情報格納部６３１により記憶されたトラステッドハードウェア４０の署名検証鍵を取得する。そして、署名検証部１１４は、取得した署名検証鍵を用いて、トラステッドハードウェア４０から受け取ったメッセージのデジタル署名を検証する。ステップＳ７０３の後、処理はステップＳ７０４、ステップＳ７０５へ移行する。
【０１３８】
（ステップＳ７０４）管理者装置５０の共有情報通信部５３１は、開示回数のカウント値を含む価格更新メッセージを、情報共有サーバー６０に送信する。情報共有サーバー６０の共有情報格納部６３１は、受信した価格更新メッセージを情報共有サーバー６０の記憶装置に記憶する。
（ステップＳ７０５）情報共有サーバー６０の共有情報通信部６２１は、全ての参加者装置７０に、管理者装置５０から受信した価格更新メッセージを送信する。ステップＳ７０５の後、処理はステップＳ７０６へ移行する。
【０１３９】
（ステップＳ７０６）参加者装置７０の共有情報通信部７２１は、情報共有サーバー６０からトラステッドハードウェア４０の署名検証鍵を取得する。そして、署名検証部３１３は、その署名検証鍵を用い、トラステッドハードウェア４０のデジタル署名を検証する。ステップＳ７０６の後、ステップＳ２１４の処理が行なわれる。
【０１４０】
このように、情報共有サーバー６０を介して、入札メッセージと価格更新メッセージが送られることで、全ての参加者装置７０が同じ情報を同じタイミングで受け取ることができる。これにより、管理者が特定の参加者装置７０への通知を遅らせたり、入札メッセージを故意や過失により、無視したりすることを防げるようになる。
【０１４１】
（特定動作）
第３の実施形態にかかるオークションシステム１３においてグループ署名を作成した参加者装置７０を特定する際の動作は、第２の実施形態にかかるオークションシステムにおいてグループ署名を作成した参加者装置３０を特定する際の動作とほぼ同じである。すなわち、本実施の形態における特定動作のシーケンスは、図１４で示したシーケンスとほぼ同じである。異なる点は、管理者装置５０がトラステッドハードウェア４０のデジタル署名を検証する際、本実施形態では、情報共有サーバー６０から検証鍵を取得する点である。すなわち、図１４のステップＳ３０８において、本実施の形態では、共有情報通信部５３１が、情報共有サーバー６０に記憶された検証鍵を取得し、署名検証部１１４は、取得した署名検証鍵を用いてデジタル署名を検証する。もちろん、情報共有サーバー６０に検証鍵を格納せずに、第２の実施形態と同様、各装置が検証鍵を記憶していてもよい。
【０１４２】
以上、第３の実施形態について説明した。本実施形態では、情報共有サーバー６０を設置し、参加者装置７０の入札メッセージ及び管理者装置５０の価格更新メッセージを情報共有サーバー６０で公開している。すなわち、入札メッセージ（入札情報）及び価格更新メッセージ（更新情報）が管理者装置５０及び参加者装置７０で共有される。このため、全参加者が最新の入札状況を把握することができる。すなわち、管理者が故意や過失により、入札メッセージを無視したり、特定の参加者に他の参加者より早く、価格更新メッセージを通知し、有利な状況を作ったりし、価格を不正に操作することが防げるようになった。
【０１４３】
なお、本実施形態の変形例として、参加者装置７０の署名検証部３１３に、情報共有サーバー６０に共有されている入札メッセージに付与されているグループ署名データを検証する機能を持たせてもよい。グループ公開鍵があれば、誰でもグループ署名データを検証できるため、参加者装置７０の署名検証部３１３が、情報共有サーバー６０において共有されるグループ公開鍵を用いて、管理者装置５０の署名検証部１１４と同様にグループ署名を検証することもできる。なお、この場合、グループ公開鍵は、情報共有サーバー６０において共有されてもよいし、予め参加者装置７０に記憶されていてもよい。このように参加者が、他の参加者の作成した入札メッセージを検証することで、管理者が正当な入札メッセージを無視し、価格更新メッセージを送信しなければ、それを検知できるようになる。また、不正な入札メッセージを管理者が無視すれば、その状況が把握できる。
【０１４４】
＜第４の実施形態＞
上述のように、第３の実施形態では、情報共有サーバー６０を導入し、入札情報を管理者装置５０と参加者装置７０が共有することで、管理者による不正を防げるようになった。けれども、情報共有サーバー６０に保管される入札情報が不正に改ざんされ、正しい入札履歴が残らない可能性がある。そのため、第４の実施形態では、情報共有の手段としてブロックチェーンを用いる。
【０１４５】
ブロックチェーンにはpeer-to-peer (P2P) ネットワークと公開鍵暗号技術が使われており、ブロックチェーンにより分散台帳が実現されている。ブロックチェーンへのすべての参加者は公開鍵と秘密鍵のペアを所有し、台帳に記入するために生成した全ての情報に秘密鍵による電子署名とその検証のための公開鍵が付与される。そして、この情報はP2Pネットワークを通してブロックチェーンの全ての参加者に送信され、電子署名の検証などの末に台帳に記入される。ブロックチェーンの主な特徴は台帳（共有情報）の透明性と耐改竄性である。透明性とは、ブロックチェーンのすべての参加者が同じ情報を取得できることが保証されていることを指す。耐改竄性は、台帳に記されたデータの改竄が困難であることを指す。耐改竄性は、ハッシュチェーンの利用により得られる。
【０１４６】
この実施形態では、情報共有サーバーではなく、ブロックチェーンの台帳に、入札メッセージ、価格更新メッセージといった共有情報を記入することで、これらの情報の透明性と耐改竄性を担保し、前述の管理者による不正や入札履歴の変更を防げる。
【０１４７】
（システム構成概略）
第４の実施形態について説明する。図２１は、第４の実施形態に係るオークションシステム１４の構成の一例を示す図である。図２１に示されるように、オークションシステム１４は管理者装置１００、トラステッドハードウェア４０、参加者装置９０−１〜９０−Ｎ（Ｎは整数、以下同じ）を含んで構成されている。なお、以降の説明において、参加者装置９０−１〜９０−Ｎのそれぞれを区別する特段の必要がない場合には、単に「参加者装置９０」と表記する。管理者装置１００および参加者装置９０のそれぞれは、ネットワーク８０を介して相互に通信可能に接続されており、トラステッドハードウェア４０は、管理者装置１００と通信可能に接続されている。ネットワーク８０はインターネット、LAN、VPNなど情報通信が可能なネットワークである。
【０１４８】
（管理者装置１００）
図２２は管理者装置１００の構成の一例を示すブロック図である。管理者装置１００は制御部１０１０、格納部５２０、及びブロックチェーン制御部１０２０を備える。すなわち、管理者装置１００は、制御部１１０が制御部１０１０に置き換わり、通信部５３０がブロックチェーン制御部１０２０に置き変わった点で、第３の実施形態の管理者装置５０と異なっている。
【０１４９】
制御部１０１０はパラメータ設定部１１１、署名検証部１０１１、価格検証部１１５、及びグループ署名作成者確認部１１６を備える。すなわち、制御部１０１０は、署名鍵ペア生成部１１２及び署名生成部１１３が省かれ、署名検証部１１４が署名検証部１０１１に置き変わった点で、管理者装置５０の制御部１１０と異なっている。
【０１５０】
署名検証部１０１１はネットワーク８０を介して受け取った入札メッセージに付与されたグループ署名データを検証する。なお、検証方法については、上述した実施形態と同様である。ブロックチェーン制御部１０２０は分散台帳に係る全ての操作を制御する。これには、電子署名付きメッセージの作成、電子署名の検証、台帳の更新と保管、P2Pネットワークを介したメッセージの送受信などが含まれる。また、ブロックチェーン制御部１０２０は、ブロックチェーンについての制御のほかに、さらに、管理者装置１００とトラステッドハードウェア４０との間のメッセージの送受信を行う。その際、ブロックチェーン制御部１０２０はトラステッドハードウェア４０へ送られるメッセージに電子署名を付与し、送信する。ブロックチェーン制御部１０２０はトラステッドハードウェア４０から受信するメッセージに付与された電子署名を検証する。このように、ブロックチェーン制御部１０２０は、ブロックチェーンに利用される電子署名の付与及び検証の技術をトラステッドハードウェア４０との通信にも利用している。
【０１５１】
（参加者装置９０）
図２３は参加者装置９０の構成の一例を示すブロック図である。参加者装置９０は制御部９１０及びブロックチェーン制御部９２０を備える。すなわち、参加者装置９０は、制御部３１０が制御部９１０に置き換わり、通信部７２０がブロックチェーン制御部９２０に置き変わった点で、第３の実施形態の参加者装置７０と異なっている。
【０１５２】
制御部９１０はパラメータ設定部３１４、署名生成部９１１、入札メッセージ生成部３１５、及びカウント値検証部３１６を備える。すなわち、制御部９１０は、署名鍵ペア生成部３１１及び署名検証部３１３が省かれ、署名生成部３１２が署名生成部９１１に置き変わった点で、参加者装置７０の制御部３１０と異なっている。署名生成部９１１はグループ署名の生成を行う。なお、生成方法については、参加者装置７０の署名生成部３１２と同様である。ブロックチェーン制御部９２０は入札メッセージ以外のメッセージについて、ブロックチェーン制御部１０２０と同様の制御を行なう。グループ署名が付与された入札メッセージについては、匿名性を保つ必要があるので、ブロックチェーン制御部９２０は電子署名を付与しない。
【０１５３】
（動作の説明）
ブロックチェーンにかかわる設定と動作については通常のブロックチェーンのそれと同じであるため、説明の簡潔さを保つために説明を省略し、異なる動作のみ説明する。ここで、通常のブロックチェーンとは例えば、Hyperledger fabricを想定している。ユースケースの都合上、パーミッション型ブロックチェーンが適しているが、正当なグループ署名を作成できる参加者は予め登録されるため、パーミッションレス型ブロックチェーンでもよい。通常のブロックチェーンと異なる動作とは入札メッセージを指している。通常のブロックチェーンのメッセージと異なり、作成者の電子署名が付与されていない。本実施形態ではグループ署名が検証できればよいため、入札メッセージを有効なメッセージとする。
【０１５４】
（セットアップ動作）
図２４を参照しながら、第４の実施形態に係る英国オークションシステムにおけるセットアップ動作を説明する。なお、以下の説明では、既に説明したステップについては、その詳細な説明を省略する。第４の実施形態におけるセットアップ動作は、ブロックチェーンの利用に伴い、通信処理並びに署名の生成処理及び検証処理が第３の実施形態と異なるが、基本的な処理の流れは、第３の実施形態と同様である。
【０１５５】
まず、管理者装置１００においてステップＳ４０１の処理が行なわれた後、ステップＳ８０１の処理が行なわれる。
（ステップＳ８０１）管理者装置１００のブロックチェーン制御部１０２０は、ステップＳ４０１で生成したオークション管理者の秘密鍵以外のパラメータを含むメッセージにデジタル署名を付与する。
（ステップＳ８０２）管理者装置１００のブロックチェーン制御部１０２０は、デジタル署名が付与されたメッセージをトラステッドハードウェア４０に送信する。
ステップＳ８０２の後、ステップＳ１０４、ステップＳ１０５、ステップＳ４０２、ステップＳ４０３、ステップＳ１０７の処理が行なわれる。
【０１５６】
（ステップＳ８０３）管理者装置１００のブロックチェーン制御部１０２０は、ステップＳ１０７による伝送により受け取ったメッセージのデジタル署名を検証する。
（ステップＳ８０４）管理者装置１００のブロックチェーン制御部１０２０は、グループの公開鍵及び開示回数の上限値を台帳に記録する処理を行なう。すなわち、ブロックチェーン制御部１０２０は更新内容を、ネットワーク８０を介して参加者装置９０に送信する。これに対し、参加者装置９０のブロックチェーン制御部９２０はメッセージの署名を検証し、問題がなければ、グループの公開鍵及び開示回数の上限値を台帳に記録する。
ステップＳ８０４の後、ステップＳ４０５及びステップＳ１１２の処理が行なわれる。ステップＳ１１２の後、ステップＳ８０５の処理が行なわれる。
【０１５７】
（ステップＳ８０５）参加者装置９０のブロックチェーン制御部９２０は、グループメンバ用公開鍵を台帳に記録する。
ステップＳ８０５の後、ステップＳ１１６及びステップＳ１１７の処理が行なわれる。ステップＳ１１７の後、ステップＳ８０６の処理が行なわれる。
【０１５８】
（ステップＳ８０６）管理者装置１００のブロックチェーン制御部１０２０は、メンバ証明書を台帳に記録する。なお、ステップＳ８０６において、メンバ証明書とＩＤとを対応づけて台帳に記録してもよい。ここで、ＩＤは該当する参加者がわかるようメンバ証明書と対応づけられているものとする。この他のやり方として、ＩＤの代わりに参加者装置９０の公開鍵を台帳に記録してもよい。
（ステップＳ８０７）管理者装置１００による台帳の記録処理が行なわれると、参加者装置９０のブロックチェーン制御部９２０は、台帳からメンバ証明書を取得する。
【０１５９】
（入札動作）
図２５を参照しながら、第４の実施形態に係る英国オークションシステムにおける入札動作を説明する。なお、以下の説明では、既に説明したステップについては、その詳細な説明を省略する。第４の実施形態における入札動作は、ブロックチェーンの利用に伴い、通信処理が第３の実施形態と異なるが、基本的な処理の流れは、第３の実施形態と同様である。
【０１６０】
まず、参加者装置９０−ＮにおいてステップＳ２０１の処理が行なわれた後、ステップＳ９０１の処理が行なわれる。
（ステップＳ９０１）参加者装置９０のブロックチェーン制御部９２０は、グループ署名付きの入札メッセージを台帳に記録する。
（ステップＳ９０２）管理者装置１００のブロックチェーン制御部１０２０は、入札メッセージを取得し、当該入札メッセージに付与されているグループ署名を検証する。
ステップＳ９０２の後、ステップＳ２０４の処理が行なわれる。ステップＳ２０４の後、処理はステップＳ９０３へ移行する。
【０１６１】
（ステップＳ９０３）管理者装置１００の価格検証部１１５は価格更新メッセージを作成し、ブロックチェーン制御部１０２０は、価格更新メッセージに対しデジタル署名を付与する。
（ステップＳ９０４）管理者装置１００のブロックチェーン制御部１０２０は、価格更新メッセージをトラステッドハードウェア４０に送信する。
ステップＳ９０４の後、ステップＳ２０７、ステップＳ２０８、ステップＳ２０９、及びステップＳ２１０の処理が行なわれる。ステップＳ２１０の後、ステップＳ９０５の処理が行なわれる。
【０１６２】
（ステップＳ９０５）管理者装置１００のブロックチェーン制御部１０２０は、ステップＳ２１で送信されたメッセージのデジタル署名を検証する。
（ステップＳ９０６）管理者装置１００のブロックチェーン制御部１０２０は価格更新メッセージを台帳に記録する。
（ステップＳ９０７）参加者装置９０のブロックチェーン制御部９２０は価格更新メッセージを取得し、カウント値検証部３１６は、開示回数のカウント値が適正であるかを検証する。
【０１６３】
なお、ブロックチェーンを用いることにより、オークションシステムの共有情報の改竄耐性が上がったことから、トラステッドハードウェア４０は、入札の度に、開示回数のカウント値をメッセージに含めることをやめてもよい。すなわち、ステップＳ２０８を入札の度に行なわなくてもよい。この場合、開示回数のカウント値が変更したときのみメッセージにカウント値を付記し、それをブロックチェーンに記録すればよい。
【０１６４】
（特定動作）
入札メッセージから入札者を特定する動作を図２６を参照しながら説明する。なお、以下の説明では、既に説明したステップについては、その詳細な説明を省略する。第４の実施形態における特定動作は、ブロックチェーンの利用に伴い、通信処理が上述の実施形態と異なるが、基本的な処理の流れは同様である。
【０１６５】
（ステップＳ１００１）管理者装置１００のブロックチェーン制御部１０２０は、作成者を特定したい入札メッセージについてのグループ署名にデジタル署名を付与する。
（ステップＳ１００２）管理者装置１００のブロックチェーン制御部１０２０は、ステップＳ１００１でデジタル署名が付与されたメッセージをトラステッドハードウェア４０に送信する。
ステップＳ１００２の後、ステップＳ３０３、ステップＳ５０１、ステップＳ３０４、ステップＳ３０５、ステップＳ３０６、及びステップＳ３０７の処理が行なわれる。ステップＳ３０７の後、ステップＳ１００３の処理が行なわれる。
【０１６６】
（ステップＳ１００３）管理者装置１００のブロックチェーン制御部１０２０は、受信したメッセージに付与された電子署名を検証する。
ステップＳ１００３の後、ステップＳ３０９の処理が行なわれる。
【０１６７】
以上、第４の実施形態について説明した。第４の実施形態では、オークションの管理者と参加者がブロックチェーンにより情報共有を行なう。すなわち、入札メッセージ（入札情報）及び価格更新メッセージ（更新情報）が、ブロックチェーンにより管理者装置１００及び参加者装置９０で共有される。このため、入札情報や更新情報について、透明で、かつ、改竄不能な共有を実現できる。ここで、複数のノード（すなわち、ブロックチェーンに参加している装置）が不正な情報を台帳に記録した場合、台帳が何台までの不正に対する改竄耐性を有するかは、ブロックチェーンの合意形成プロトコルに依存する。例えば、典型的な合意形成プロトコルであるPractical Byzantine Fault Tolerance (PBFT)の場合は、台帳の改竄耐性が保証されるのは不正なノード数が全ノードの３分の１以下である場合である。
【０１６８】
なお、本実施形態の変形例として、第３の実施形態で述べた変形例と同様の変形例も実現可能である。すなわち、参加者装置９０に、ブロックチェーンで共有されている入札メッセージに付与されているグループ署名を検証する機能を持たせてもよい。
【０１６９】
（その他の変形例）
上述した各実施の形態では、セットアップ動作、入札動作、特定動作に注目して説明したが、もちろん、入札の開始と終了を決める動作が追加されてもよい。開始及び終了を決める条件として時刻などの条件があり得る。例えば、そのような条件として時刻が用いられる場合には、オークションシステムには時刻サーバーが追加されてもよい。
また、もちろん公開鍵暗号や共通鍵暗号を用いてオークションの通信内容をオークションに無関係な第３者から秘匿することも可能である。
また、管理者装置の格納部は外部のデータ保管サーバーなどにデータを記憶してもよい。
【０１７０】
また、トラステッドハードウェアを管理者装置と通信可能に接続されている外部の装置として実施の形態は説明されているが、実際にIntel社のSGXやARM社のTrustZoneのようにトラステッドハードウェアが管理者装置内に含まれていてもよい。
【０１７１】
第１および第２の実施形態では非特許文献１に記載されたグループ署名を例にとり説明したが、他のグループ署名方式を用いることができるのはもちろんである。これには、グループのメンバが後から追加されたり、失効されたりできるグループ署名方式も含まれる。その場合は、オークションの参加者を追加したり、失効させたりする制御部が管理者装置に含まれていてもよい。また、この制御部は、管理者装置の外部にサーバー装置としてあってもよい。
また、もちろん、必要に応じて参加者が自身の入札価格をキャンセルする機能を実現することができる。
【０１７２】
また、もちろん、一般的なグループ署名方式より匿名性を高めた、ダイナミックアキュムレータを組み合わせたグループ署名を用いた英国オークションを実現することができる。ダイナミックアキュムレータは２００２年にアキュムレータスキームを基にCamenischとLysyanskayaにより考案され、グループ署名との組み合わせにより、匿名性の高いグループ署名が実現できることが示されている。ダイナミックアキュムレータを組み合わせたグループ署名を用いた英国オークションを実現する場合、ユーザが作成するメッセージに確率的暗号化されたIDを添付させ、その復号鍵をトラステッドハードウェアに持たせればよい。
【０１７３】
また、非特許文献４で提案されている英国オークション方式も実現することができる。その場合は、第３の実施形態の情報共有サーバー６０、あるいは第４の実施形態のブロックチェーンに、非特許文献４で示される方式に含まれるオークション管理者や開示管理者用の公開掲示板の情報を記録すればよい。
【０１７４】
また、上述したプログラムは、様々なタイプの非一時的なコンピュータ可読媒体（ｎｏｎ−ｔｒａｎｓｉｔｏｒｙ  ｃｏｍｐｕｔｅｒ  ｒｅａｄａｂｌｅ  ｍｅｄｉｕｍ）を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体（ｔａｎｇｉｂｌｅ  ｓｔｏｒａｇｅ  ｍｅｄｉｕｍ）を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体（例えばフレキシブルディスク、磁気テープ、ハードディスクドライブ）、光磁気記録媒体（例えば光磁気ディスク）、ＣＤ−ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）ＣＤ−Ｒ、ＣＤ−Ｒ／Ｗ、半導体メモリ（例えば、マスクＲＯＭ、ＰＲＯＭ（Ｐｒｏｇｒａｍｍａｂｌｅ  ＲＯＭ）、ＥＰＲＯＭ（Ｅｒａｓａｂｌｅ  ＰＲＯＭ）、フラッシュＲＯＭ、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ））を含む。また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体（ｔｒａｎｓｉｔｏｒｙ  ｃｏｍｐｕｔｅｒ  ｒｅａｄａｂｌｅ  ｍｅｄｉｕｍ）によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。
【０１７５】
以上、実施の形態を参照して本願発明を説明したが、本願発明は上記によって限定されるものではない。本願発明の構成や詳細には、発明のスコープ内で当業者が理解し得る様々な変更をすることができる。
【０１７６】
上記の実施形態の一部又は全部は、以下の付記のようにも記載され得るが、以下には限られない。
（付記１）
匿名電子署名を構成する情報である署名情報を受信する受信手段と、
前記署名情報に基づいて、前記匿名電子署名を作成したメンバを特定する情報である特定情報を生成する特定情報生成手段と、
前記特定情報生成手段による前記特定情報の生成回数を記憶する記憶手段と、
前記特定情報を送信する送信手段と
を有する情報処理装置。
（付記２）
前記受信手段は、電子オークションにおける現在の評価値の更新情報を受信し、
前記送信手段は、前記更新情報と記憶されている現在の前記生成回数とを関連づけた情報を送信する
付記１に記載の情報処理装置。
（付記３）
前記関連づけた情報に対してデジタル署名を生成する署名生成手段をさらに有し、
前記送信手段は、前記デジタル署名が付与された前記関連づけた情報を送信する
付記２に記載の情報処理装置。
（付記４）
前記特定情報生成手段は、記憶された前記生成回数が予め設定された上限値未満である場合、前記特定情報を生成する
付記１乃至３のいずれか一項に記載の情報処理装置。
（付記５）
前記匿名電子署名は、電子オークションの入札情報に付与された署名であり、
前記上限値は、前記電子オークションにおける最大落札者数である
付記４に記載の情報処理装置。
（付記６）
前記情報処理装置は、該情報処理装置内のデータの漏洩を防ぐための機構を有することが予め保障されている装置である
付記１乃至５のいずれか１項に記載の情報処理装置。
（付記７）
匿名電子署名付きの入札情報を受信し、電子オークションによる競りを管理する管理装置と、前記匿名電子署名を作成したメンバである参加者装置を特定する開示装置とを備え、
前記管理装置は、
受信した前記入札情報のうち送信元の前記参加者装置を特定すべき前記入札情報に付与されていた前記匿名電子署名を構成する情報である署名情報を前記開示装置に送信する第１の送信手段と、
前記開示装置から前記匿名電子署名を作成した前記参加者装置を特定する情報である特定情報を受信する第１の受信手段と
を有し、
前記開示装置は、
前記管理装置から前記署名情報を受信する第２の受信手段と、
前記第２の受信手段が受信した前記署名情報に基づいて、前記特定情報を生成する特定情報生成手段と、
前記特定情報生成手段による前記特定情報の生成回数を記憶する記憶手段と、
前記特定情報を前記管理装置に送信する第２の送信手段と、
を有する情報処理システム。
（付記８）
前記第１の送信手段は、前記電子オークションにおける現在の評価値を更新する場合、評価値の更新情報を前記開示装置に送信し、
前記第２の受信手段は、前記管理装置から前記更新情報を受信し、
前記第２の送信手段は、前記更新情報と記憶されている現在の前記生成回数とを関連づけた情報を送信する
付記７に記載の情報処理システム。
（付記９）
前記入札情報及び前記更新情報が前記管理装置及び前記参加者装置で共有される
付記８に記載の情報処理システム。
（付記１０）
前記入札情報及び前記更新情報は、ブロックチェーンにより前記管理装置及び前記参加者装置で共有される
付記９に記載の情報処理システム。
（付記１１）
前記入札情報に付与された前記匿名電子署名も共有され、
前記情報処理システムは、前記参加者装置をさらに有し、
前記参加者装置は、前記匿名電子署名を検証する検証手段を有する
付記９又は１０に記載の情報処理システム。
（付記１２）
情報処理装置が、
匿名電子署名を構成する情報である署名情報を受信し、
前記署名情報に基づいて、前記匿名電子署名を作成したメンバを特定する情報である特定情報を生成し、
前記特定情報の生成回数を記憶し、
前記特定情報を送信する
メンバ特定方法。
（付記１３）
匿名電子署名を構成する情報である署名情報を受信する受信ステップと、
前記署名情報に基づいて、前記匿名電子署名を作成したメンバを特定する情報である特定情報を生成する特定情報生成ステップと、
前記特定情報の生成回数を記憶する記憶ステップと
前記特定情報を送信する送信ステップと
をコンピュータに実行させるプログラムが格納された非一時的なコンピュータ可読媒体。
【符号の説明】
【０１７７】
１    情報処理システム
２    管理装置
３    開示装置
４、９    送信部
５、６    受信部
７    特定情報生成部
８    記憶部
１０、５０、１００    管理者装置
１１、１３、１４    オークションシステム
１５    グループ管理者
１６    特権者
１７    グループメンバ
２０、４０    トラステッドハードウェア
３０、７０、９０    参加者装置
６０    情報共有サーバー
８０    ネットワーク
１１０、２１０、３１０、６１０、９１０、１０１０    制御部
１１１、２１５、３１４    パラメータ設定部
１１２、２１２、３１１    署名鍵ペア生成部
１１３、２１３、３１２、９１１    署名生成部
１１４、２１４、３１３、１０１１    署名検証部
１１５    価格検証部
１１６    グループ署名作成者確認部
１２０、２２０、３２０、４２０、５２０、６３０    格納部
１２１    データ格納部
１２２    入札情報格納部
１２３、２２２、３２１    署名検証鍵格納部
１３０、２３０、３３０、５３０、６２０、７２０    通信部
１３１、２３１、３３１、４３１    情報通信部
１５０    ネットワークインタフェース
１５１    メモリ
１５２    プロセッサ
２１１、４１１    データ開示部
２１６    開示回数付与メッセージ生成部
２２１、３２２、４２１    開示回数格納部
３１５    入札メッセージ生成部
３１６    カウント値検証部
４２３    開示回数上限値格納部
５３１、６２１、７２１    共有情報通信部
６３１    共有情報格納部
９２０、１０２０    ブロックチェーン制御部
【図１】
2020053994.tif 000003
【図２】
2020053994.tif 000004
【図３】
2020053994.tif 000005
【図４】
2020053994.tif 000006
【図５】
2020053994.tif 000007
【図６】
2020053994.tif 000008
【図７】
2020053994.tif 000009
【図８】
2020053994.tif 000010
【図９】
2020053994.tif 000011
【図１０】
2020053994.tif 000012
【図１１】
2020053994.tif 000013
【図１２】
2020053994.tif 000014
【図１３】
2020053994.tif 000015
【図１４】
2020053994.tif 000016
【図１５】
2020053994.tif 000017
【図１６】
2020053994.tif 000018
【図１７】
2020053994.tif 000019
【図１８】
2020053994.tif 000020
【図１９】
2020053994.tif 000021
【図２０】
2020053994.tif 000022
【図２１】
2020053994.tif 000023
【図２２】
2020053994.tif 000024
【図２３】
2020053994.tif 000025
【図２４】
2020053994.tif 000026
【図２５】
2020053994.tif 000027
【図２６】
2020053994.tif 000028
【手続補正書】
【提出日】令和3年3月5日(2021.3.5)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
匿名電子署名を構成する情報である署名情報を受信する受信手段と、
前記署名情報に基づいて、前記匿名電子署名を作成したメンバを特定する情報である特定情報を生成する特定情報生成手段と、
前記特定情報生成手段による前記特定情報の生成回数を記憶する記憶手段と、
前記特定情報を送信する送信手段と
を有する情報処理装置。
【請求項２】
前記受信手段は、電子オークションにおける現在の評価値の更新情報を受信し、
前記送信手段は、前記更新情報と記憶されている現在の前記生成回数とを関連づけた情報を送信する
請求項１に記載の情報処理装置。
【請求項３】
前記関連づけた情報に対してデジタル署名を生成する署名生成手段をさらに有し、
前記送信手段は、前記デジタル署名が付与された前記関連づけた情報を送信する
請求項２に記載の情報処理装置。
【請求項４】
前記特定情報生成手段は、記憶された前記生成回数が予め設定された上限値未満である場合、前記特定情報を生成する
請求項１乃至３のいずれか一項に記載の情報処理装置。
【請求項５】
前記匿名電子署名は、電子オークションの入札情報に付与された署名であり、
前記上限値は、前記電子オークションにおける最大落札者数である
請求項４に記載の情報処理装置。
【請求項６】
前記情報処理装置は、該情報処理装置内のデータの漏洩を防ぐための機構を有することが予め保障されている装置である
請求項１乃至５のいずれか１項に記載の情報処理装置。
【請求項７】
匿名電子署名付きの入札情報を受信し、電子オークションによる競りを管理する管理装置と、前記匿名電子署名を作成したメンバである参加者装置を特定する開示装置とを備え、
前記管理装置は、
受信した前記入札情報のうち送信元の前記参加者装置を特定すべき前記入札情報に付与されていた前記匿名電子署名を構成する情報である署名情報を前記開示装置に送信する第１の送信手段と、
前記開示装置から前記匿名電子署名を作成した前記参加者装置を特定する情報である特定情報を受信する第１の受信手段と
を有し、
前記開示装置は、
前記管理装置から前記署名情報を受信する第２の受信手段と、
前記第２の受信手段が受信した前記署名情報に基づいて、前記特定情報を生成する特定情報生成手段と、
前記特定情報生成手段による前記特定情報の生成回数を記憶する記憶手段と、
前記特定情報を前記管理装置に送信する第２の送信手段と、
を有する情報処理システム。
【請求項８】
前記第１の送信手段は、前記電子オークションにおける現在の評価値を更新する場合、評価値の更新情報を前記開示装置に送信し、
前記第２の受信手段は、前記管理装置から前記更新情報を受信し、
前記第２の送信手段は、前記更新情報と記憶されている現在の前記生成回数とを関連づけた情報を送信する
請求項７に記載の情報処理システム。
【請求項９】
前記入札情報及び前記更新情報が前記管理装置及び前記参加者装置で共有される
請求項８に記載の情報処理システム。
【請求項１０】
前記入札情報及び前記更新情報は、ブロックチェーンにより前記管理装置及び前記参加者装置で共有される
請求項９に記載の情報処理システム。
【請求項１１】
前記入札情報に付与された前記匿名電子署名も共有され、
前記情報処理システムは、前記参加者装置をさらに有し、
前記参加者装置は、前記匿名電子署名を検証する検証手段を有する
請求項９又は１０に記載の情報処理システム。
【請求項１２】
情報処理装置が、
匿名電子署名を構成する情報である署名情報を受信し、
前記署名情報に基づいて、前記匿名電子署名を作成したメンバを特定する情報である特定情報を生成し、
前記特定情報の生成回数を記憶し、
前記特定情報を送信する
メンバ特定方法。
【請求項１３】
匿名電子署名を構成する情報である署名情報を受信する受信ステップと、
前記署名情報に基づいて、前記匿名電子署名を作成したメンバを特定する情報である特定情報を生成する特定情報生成ステップと、
前記特定情報の生成回数を記憶する記憶ステップと
前記特定情報を送信する送信ステップと
をコンピュータに実行させるプログラム。
【国際調査報告】
2020053994.tif 000029
2020053994.tif 000030
2020053994.tif 000031