JP2013539561A

JP2013539561A - 電子マネーの管理方法

Info

Publication number: JP2013539561A
Application number: JP2013500253A
Authority: JP
Inventors: 武水沼
Original assignee: Individual
Current assignee: Individual
Priority date: 2010-07-09
Filing date: 2010-07-09
Publication date: 2013-10-24
Anticipated expiration: 2030-07-09
Also published as: JP5721086B2; US20130238903A1; WO2012004838A1

Abstract

サービス提供者がユーザーに対してサービスを提供する方法が示されている。このサービス提供方法は、ユーザーから提供された第一の情報に対してサービス提供者が電子署名を行い、ユーザーへ提供するステップと、前記第一の情報を特定して行われたリクエストを受け、正当なものであれば、そのリクエストを受諾するステップと、前記リクエストを受諾した場合、ユーザーから第二の情報を受信するステップと、情報処理装置を用いて、前記第一の情報と前記第二の情報が所定の関係を有しているか否かを決定するステップと、前記第二の情報が所定の関係を有していることが決定された場合に、前記サービスの提供に必要な処理を開始するステップと、前記サービスの提供が行われた後も、その証拠として前記第二の情報を保存するステップとからなる。
【選択図】図１

Description

本発明は、サービス提供方法に関するものであり、特に、インターネットを介した安全性と信頼性の高いサービス提供方法に関する。

インターネットを利用する際、なりすましや盗聴、データ改竄といったリスクが常につきまとう。暗号の利用は、このような不正行為に対抗する技術的手段の一つである。特に、ＰＫＩ（Public Key Infrastructure：公開鍵基盤）は、ＳＳＬ(Secure Socket Layer)を始めとして、インターネットを安全に利用するには欠かせない技術となっている。

また、直接インターネットの利用ではないが、ＩＣカード型の電子マネーは、暗号を利用してセキュリティを強化することで近年非常に普及している。暗号を利用したインターネット上の電子マネーとしては、デジ・キャッシュ社が開発したEcash (商標）がある。Ecashでは、一般的なＰＫＩの技術ではなく、ブラインド署名という手段を用いて、ある程度の匿名性を確保している。しかし、提携銀行に口座を開かなければ利用できず、煩雑な処理を要することから利用者数が伸びず失敗に終わっている。

その他にも、暗号を利用したネットワーク型電子マネーの実装方法が提案されてきたが、その多くが大きな成功を収めるには至っていない。現在、流通しているネットワーク型の電子マネーとしては、購入時に発行されるプリペイド番号にのみ通貨価値を持たせるものが主流となっている。特許文献１にその具体例が記載されている。このような電子マネーは、暗号を利用しておらず、専ら発行者とユーザーとの間の信頼関係を基礎としている。

特開２００６ - ３１８５０２号公報

クライアント認証や暗号化を行わないでインターネットを介したサービスを提供する場合、どうしても一定数のトラブルは避けられない。例えば、商品（サービス）を購入していないのに電子マネー残高が減っている、という苦情がしばしば発生する。これがユーザーの勘違いであるか、ユーザーの不注意で電子マネー情報が漏洩したのか、システムの誤動作であるか、何らかのハッキングが行われたのか、事実関係を明らかにすることは難しい。すなわち、責任の所在が不明確で、被害を被ったとするユーザーを納得させる説明は困難である。

例えば、プリペイド番号を利用する電子マネーの一つである「ネットキャッシュ」（株式会社エヌ・ティ・ティ・カードソリューション）の場合、プリペイド番号が流出し不正に利用されていたことが、２００６年にユーザーからの問い合わせで判明した（インターネット〈 URL：http://www.ntt-card.co.jp/company/news/39.html〉）。この例では、アクセスログの解析から流出がサーバーからであったことが判明したが、ユーザーの勘違いや不正なクレームがあった場合、事実関係の証明は困難である。特に、匿名での利用では、クレームを行うのに躊躇してあきらめてしまうこともある。それにもかかわらず、大部分のネットワーク型の電子マネーで事実上クライアント認証や暗号化を行っていない理由は、そのメリットよりもデメリット(導入コストや使い勝手の悪さ)が上回っているからである。

一方で、ＰＫＩは、その原理的な有効性にもかかわらず、少なくとも個人レベルでは、主にその一方向についてのみ普及している。すなわち、サービスの提供側といった法人が、公開鍵証明書を持ち、サービスに関する情報に電子署名を行い、それを一般の個人が確認してサービスを利用するといった利用が大部分である。本来は、個人も電子証明書を持ち、電子署名を行うことで、受けるサービスの幅を広げる可能性があるはずであるが、そのようは利用は例外的と言って良い。

実際、個人が電子証明書を利用する場面というのは、非常に限られている。この理由は、やはりＰＫＩの導入には煩雑さがある為と思われる。現在では、どうしても必要な場合には、認証局に申し込みを行い、必要な手続きに従って個人の電子証明書を取得する。これには手間と時間だけでなく費用もかかる。また有効期間にも気を配る必要がある。そして、その電子証明書はそのユーザー個人を特定するものなので、印章と同様にその管理を慎重に行う必要がある。ある意味では、印章よりももっと直接にユーザー個人を特定する機能を有するので、もしも漏洩すれば、悪用される危険性がより高いと言える。

従って、本発明の一つの目的は、最小限のリスクと、最小限の実装・運用コストで、セキュリティレベルの高いサービスを提供する方法を実現することである。

上記課題を解決するために、本発明は、サービス提供者がユーザーに対してサービスを行う方法であって、以下の構成をその要旨とする。すなわち、ユーザーから提供された第一の情報を、受信装置により受信するステップと、情報処理装置を用いて、前記第一の情報に対してサービス提供者が電子署名を行うステップと、ユーザーから送信された第二の情報を受信装置により受信するステップと、情報処理装置を用いて、前記第一の情報と前記第二の情報が所定の関係を有しているか否かを決定するステップと、前記第二の情報が所定の関係を有していることが決定された場合に、ユーザーに対して前記所定のサービスを実行するステップとからなり、前記第二の情報を受信前の段階において、現状の情報処理技術によっては、前記第一の情報と前記所定の関係を有する情報の生成は、事実上不可能であると考えられていることを要旨とする。

上記要件において、「情報処理装置を用いて、前記第一の情報と前記第二の情報の組み合わせが所定の関係を有しているか否かを決定する」ことが可能であり、「現状の情報処理技術によっては、前記第二の情報を得る前に、前記第一の情報と前記所定の関係を有する情報を生成することは、事実上不可能であると考えられている」ような第一の情報および第二の情報の具体例としては、以下のものがある。

１）第一の情報を電子署名の検証を行う検証鍵（公開鍵）とし、第二の情報を上記検証鍵で検証可能な電子署名とする。
２）第一の情報をハッシュ値すなわちハッシュ関数の計算値とし、第二の情報を上記ハッシュ値の原像とする。
３）第一の情報を十分に大きな素数又は疑似素数P、Qの積とし、第二の情報をP、Qの少なくとも一方とする。
図１を参照して、上記構成によるサービス提供方法のプロセスを詳しく説明する。まず、ユーザーから提供された第一の情報を、情報受信装置により受信して電子署名を行う。これはサービス提供者がユーザーに対して、サービスの提供を保証するものである。例えば、この電子署名は、所定の現金との引き換えで行われる（図１の上段）。ユーザーは、この電子署名を検証することで、権利の確認を行うことができる。

サービスの提供を受ける際には（図１の中段）、ユーザーは第一の情報を特定したサービスリクエストをサービス提供者へ提示する。ここで第一の情報を特定する方法は、直接第一の情報を提示することもできるが、間接的に第一の情報の特定を可能とする別の情報を提示してもよい。例えば、第一の情報にＩＤを割り当て、このＩＤをリクエストに含めることができる。

もし、このリクエストが正当なものであれば、第一の情報に署名があるのでサービス提供者はそれを拒否できないリクエストが受諾された場合、ユーザーは第二の情報を送信する。サービス提供者は、第一の情報と第二の情報が所定の関係を有しているか否かを決定する。このような関係を持つ第二の情報は、上記ユーザー以外は提示できない。勿論、サービス提供者も、第二の情報を算出できない。これは、サービス提供者が情報漏洩の責任を負わないことを意味する。第二の情報が第一の情報との間に所定の関係を有していることが決定された場合、ユーザーに対して所定のサービスが実行される。

ここで、リクエストと共に受信した情報で特定される第二の情報が既に受信されていた場合（図１の下段）、リクエストは、正当なものではないと判断される。すなわち、既に受信されている第二の情報は、対応するサービスが既に提供されていることを証明するものであり、リクエストは、同じ第一の情報を二重使用するもので正当なものではない。もちろん、リクエスト自体に不整合がある場合も、そのリクエストは受理されない。

本発明のサービス提供方法によれば、以下のような効果が期待できる。
リスクコストが回避される。サービスを受ける権利は、サービスを提供する側ではなく、サービスを受ける側で管理し安全に保管できると共にその義務がある。従って、サービス提供者は、その権利に関する情報を管理し、その権利を守る義務を負わない。
争議が防止される。各当事者は、自身の利益を保全する為に必要な行為を行う義務を負うが、自身の利益に関して他の当事者に対して責任を求めることはできない。どのような損害も、その損害を被った当事者に起因する。責任の所在は常に明確である。

図１は、本発明のサービス提供方法の基本プロセスを説明する図である。図２は、本発明の実施例１として、電子マネーの管理方法の基本的な考え方を説明する図である。図３は、実施例１の電子マネーの管理方法の基本的な考え方を説明する図である。図４は、実施例１の電子マネーの管理方法の基本的な考え方を説明する図であり、電子財布にユニークなシリアル番号を割り当てた場合を示す。図５は、実施例１の電子マネーの管理方法を、インターネットによって実装した例を示す図である。図６は、実施例１の電子マネー処理サーバーを示すブロック図である。図７は、実施例１の電子マネーの管理方法で用いられる電子財布構造体の例を示す図である。図８は、実施例１の電子マネーの管理方法で用いられる電子財布構造体の別の例を示す図である。図９は、電子マネーを利用する為のクライアント・システムの構成の一般的な例を示すブロック図である。図１０は、実施例１の電子マネーの管理方法で用いられる移動リクエストに対する代理署名サーバーの移動プロトコルを説明する図である。図１１は、実施例１の電子マネーの管理方法で用いられる電子財布購入手続きを示す図である。図１２は、実施例１の電子マネーの管理方法で用いられる電子財布の構造体データと秘密鍵を含む連結ＱＲコードを示す図である。図１３は、実施例１の電子マネーの管理方法で用いられる支払い画面を示す図である。図１４は、実施例１の電子マネーの管理方法で用いられる携帯電話の支払い画面を示す図である。図１５は、実施例１の電子マネーの管理方法で用いられるＰＣ側の入金確認画面を示す図である。図１６は、実施例１の電子マネーの管理方法によって行われる電子財布購入の方法の一例を示す図である。図１７は、実施例１の電子マネーの管理方法によって行われる電子財布購入と使用の方法の例を示す図である。図１８は、実施例１の電子マネーの管理方法によって行われる購入と使用の方法の別の例を示す図である。図１９は、実施例１の電子マネーの管理方法によって行われる購入と使用の方法の更に別の例を示す図である。図２０は、実施例１の電子マネーの管理方法によって行われる購入と使用の方法の更に別の例を示す図である。図２１は、実施例１の電子マネーの管理方法で用いられる電子財布構造体の更に別の例を示す図である。図２２は、携帯電話のみで行われる実施例１の電子マネーの管理方法による電子マネーの使用の例を示す図である。図２３は、本発明のサービス提供方法によってチケットを受け取るための電子マネー受領証を示す図である。図２４は、本発明のサービス提供方法によってコンサート会場へ入場するための入場証明書を示す図である。図２５は、実施例１の電子マネーの管理方法による電子マネーによるリアル物品の匿名購入例を説明する図である。図２６は、本発明のサービス提供方法によって商品受領の権利を示す電子マネー受領証を示す図である。図２７は、本発明のサービス提供方法によって商品を受け取るための商品受領証を示す図である。図２８は、電子財布間の移動に制限を設けた場合の、実施例１の電子マネーの管理方法を説明する表である。図２９は、実施例１の電子マネーの管理方法の流通性の無い実装の電子財布構造体を示す図である。図３０は、実施例１の電子マネーの管理方法の流通性の無い実装のプロトコルを説明する図である。図３１は、実施例１の電子マネーの管理方法においてメッセージメンバーが追加された電子財布構造体を示す図である。図３２は、協調して動作する代理署名サーバーを複数設けられている場合の、実施例１の電子マネーの管理方法を説明する図である。図３３は、実施例２の電子マネーの管理方法で用いられる電子財布構造体の例を示す図である。図３４は、実施例２の電子マネーの管理方法によって行われるオンラインショップでの支払例を説明する図である。図３５は、実施例２の電子マネーの管理方法で用いられるカスタマイズされたセキュリティー・チップ(TPM: Trusted Platform Module)を示す概略図である。図３６は、実施例２の電子マネーの管理方法で用いられるMACユニットを示す概略図である。図３７は、実施例２の電子マネーの管理方法において、仲介サーバー側で電子財布を管理する為の構造体を示す図である。図３８は、実施例２の電子マネーの管理方法におけるユーザー側での出金ハッシュ管理を説明する図である。図３９は、図３８の出金ハッシュ管理を採用した場合の、実施例２の電子マネーの管理方法において、ユーザー側で電子財布を管理する為の構造体を示す図である。図４０は、入金ハッシュを省略した場合の、実施例２の電子マネーの管理方法で用いられる電子財布構造体の例を示す図である。図４１は、入金ハッシュを省略した場合の、実施例２の電子マネーの管理方法において、仲介サーバー側で電子財布を管理する為の構造体を示す図である。図４２は、入金ハッシュを省略した場合の、実施例２の電子マネーの管理方法において、ユーザー側での出金ハッシュ管理を説明する図である。

本実施例は、本発明のサービス提供方法を利用した電子マネーの管理方法に関する。図２、図３は、本実施例の基本的な考え方を説明する為の図である。ここでは、説明を分かりやすくする為に、最小限の必須要件のみを含んでいる。このままでも機能するが、実際の実装では不便がある。好適な実装例は後に説明する。

本実施例では、ユーザー同士が電子マネーに署名を行いお互いに証明書を発行する。すなわち、電子財布１を持つユーザー１が一定額の電子マネーを、電子財布２を持つユーザー２へ渡したいとする。この場合、ユーザー１は、公開鍵n1に関連付けられた電子財布１から、公開鍵n2に関連付けられた電子財布２へ、一定額の電子マネーを移動することになる。ユーザー１が、署名をした電子マネーを、直接ユーザー２へ渡すとすると、電子財布２において様々な署名が入り乱れ処理が困難となる。

そこで、本実施例では、電子マネーの移動には必ず代理署名サーバーがユーザー間に仲介することにする。仲介の為に、代理署名サーバーには、各ユーザーの公開鍵が、電子財布の中心的な要素として登録されている。代理署名サーバーは、ユーザー１から移動リクエストと共に電子マネーを受け取ると、その署名を公開鍵n1によって検証する。検証が成功すると、この署名を担保にして、代理署名サーバーが署名した電子マネーを、指定されているユーザー２へ渡す。すなわち、ユーザー署名は、ユーザー認証として使用すると共に出金証明書として保管する。これは本発明の重要な特徴である。

ユーザー２に電子マネーの有効性を直接保証するのは代理署名サーバーであり、代理署名サーバーに消費した電子マネーの有効性を保証するのはユーザー１の署名である。電子マネーを消費したのはユーザー１であり、その電子マネーを受け取ったのはユーザー２であり、間接的ではあるが最終的にその電子マネーを保証するのはユーザー１の署名である。

このシステムのユーザーは、出金証明書に付けられた代理署名の有効性を否定できない。なぜなら、そのユーザーの電子マネーを保証するのも代理署名の有効性だからである。すなわち、電子マネーの使用の事実を否定する為に、署名の有効性を否定すれば、同じ署名で有効性が保証されている電子マネーそのものを否定することになるからである。

以下、電子マネーの移動のプロセスを説明する。ここでは、ユーザー１は電子財布１に入金額d1を所有しており、ユーザー２は電子財布２に入金額d2を所有しているものとする。また、電子財布１および電子財布２の公開鍵を、公開鍵n1および公開鍵n2とする。

入金額d1は、どこかの電子財布から受け取った電子マネーの総額であり、当該電子財布の公開鍵に関連付けて、代理署名サーバーの秘密鍵piによって署名されている。この代理署名{n1, d1}psは、公開鍵n1と入金額d1に対してなされており、入金額証明書と呼ぶこととする。

また、出金額w1は、電子財布１から移動した電子マネー、すなわちユーザー１が使った電子マネーの出金の累計であり、公開鍵n1に対応するユーザー秘密鍵p1 によって署名されている。このユーザー署名{w1}p1は、出金額証明書と呼ぶこととする。

図３に示されているように、これらの情報は、各署名や公開鍵と共に電子財布データを構成しており、代理署名サーバーとユーザーが保管している。電子財布の残高は、入金額から出金額を差し引いた額である。

ここで、ユーザー１は、ユーザー２へ電子マネーvを支払いたいとする。出金額w1までは、既に使用し出金額証明書を発行している。従って、ユーザー１は、出金w1の増分として電子マネーvを使用する移動リクエストを代理署名サーバーへ送信する。出金額w1+vが入金額d1を上回る場合、代理署名サーバーは移動リクエストを拒否する。(ただし、下記の実装例のように、これに例外を導入しても良い。)そして、代理署名サーバーは、出金額w1+vに対して公開鍵n1で署名したユーザー署名{w1+v}p1を受け取る。ここでは、受取先ユーザー（支払先）は公開鍵n2で指定するものとする。

代理署名サーバーは、電子財布２の入金額d2をvだけ増加させてから、公開鍵n2に関連付けて代理署名サーバーの秘密鍵piによって署名する。電子財布２の入金額証明書は、この署名によって更新される。これで、電子財布２の残高がvだけ増える。電子財布１でも、出金額w1と出金額証明書が更新される。電子マネーの移動処理はこれですべてである。

電子財布２の入金額証明書は、代理署名サーバーのデータベースにおいて、更新され、それをユーザー２がダウンロードすることが出来る。また、後述の例では、更新後の電子財布２の入金額証明書はユーザー１へ返され、ユーザー１からユーザー２へ送信される。

つまり、ユーザー１は、自分の電子財布１からの出金vについて署名を行うことになる。この署名を担保にして、代理署名サーバーは、ユーザー２の入金額d2をvだけ増加させて署名を行う。すなわち、ユーザー１が保証した内容に基づいて、代理署名サーバーが代理で署名したとみることができる。例えば、ユーザー２の入金額d2が、複数のユーザーから移動した電子マネーを含む場合、入金額証明書はこれら複数のユーザーの署名を纏めて代理で行ったものとみることができる。

ここで重要なのは、ユーザー１やユーザー２は、公開鍵n1や公開鍵n2について、何らの裏付けや認証を必要としないという点である。つまり、後に説明する様に、パソコンなどでユーティリティで生成した公開鍵を、そのまま代理署名サーバーへ送信するだけで良い。

代理署名サーバーが、その公開鍵を含む入金額証明書を発行するので、上記の通り、ユーザーは、その公開鍵を否認できない。ユーザーは、電子財布のデータと入金額証明書のみによって、客観的に入金額の有効性を証明できる。一方、代理署名サーバーは、電子財布のデータと出金額証明書のみによって、客観的に出金額の有効性を証明できる。

上記説明では、ユーザー公開鍵が電子財布と一対一に対応しており、電子財布を特定するインデックスとなっている。しかし、ユーザー公開鍵をインデックスとすると、データの検索に不便がある。また、同じユーザー公開鍵を利用して複数の電子財布を生成することができない。実際には、図４に示したように、電子財布にユニークなシリアル番号を割り当て、入金額証明書と出金額証明書ではシリアル番号も含めて証明するようにすると良い。

上記代理署名サーバーは、電子マネーを現金のように、人の手から人の手に渡っていくシステムを構築するだけである。以下、電子マネーの発行と、電子マネーそのものに価値を与える方法について説明する。

発行する前は電子マネーは存在しない。電子マネーを発行する方法のひとつは、システムの構築の際に、代理署名サーバー内で十分な額の入金額を発行額として発行者の電子財布に書き込む。これが電子マネーの発行である。

この最初の電子財布から、他の電子財布へ電子マネーの移動を行うことで、電子マネーが、インターネット上を自由に流通するようになる。この電子マネーを利用したいユーザーは、円をドルに交換する様に、円を電子マネーへ両替することができる。

この電子マネーでは、発行者の電子財布の発行額（または、発行者の電子財布からの移動額）に対応する供託を行い、更に、常に電子マネーを円に両替できること、ショッピングモードで利用出来ること、又は特定の用途に利用できること等を証明する証明書を、代理署名サーバーの公開鍵psと関連付けて発行することで信用を確保する。この証明書に付けられた発行者の署名は、認証局（ＣＡ）による公開鍵証明書によって証明される。

なお、発行者の電子財布のシリアル番号は０とするが、その他の電子財布のシリアル番号はまだない。後述の通り、シリアル番号を指定しないで公開鍵と共に移動リクエストを行うと、代理署名サーバーは新たなシリアル番号の電子財布にこの公開鍵を関連付けて、電子マネーの移動を行う。例えば、電子財布の購入者は、現金を支払い、公開鍵を電子財布の所有者（以下、移動元電子財布と呼び、発行者の電子財布でありえる）に送る。移動元電子財布の所有者は、新たな電子財布へ電子マネーの移動を行う。

上記例では、発行者の電子財布も他の電子財布と全く同じ扱いとなるので、代理署名サーバーの動作はシンプルである。もう一つの電子マネーの発行方法では、発行者の電子財布を特別扱いとし、出金額が入金額よりも大きくても良いとする。この場合、初期の入金額を書き込む必要はなく、入金額も出金額も共に０で良い。出金額が電子マネーの発行総額であり、入金額は他の電子財布から移動してきた電子マネーの発行総額であり、例えば換金額である。出金額から入金額を差し引いたものが、電子マネーの供給量である。

複数の銀行が、発行者となっても良い。その場合には、発行者の電子財布間で電子マネーの移動を行い銀行間の決済がなされることになる。発行者の電子財布のシリアル番号は、例えば"*"を任意の１６進数として0x000000**とする。また、代理署名サーバーは、出金額が入金額を超えても、このようなシリアル番号の電子財布からの電子マネー移動リクエストを受理する。

以下、上記基本的な原理に基づく、電子マネーの管理方法の具体的な実装例を説明する。以下の例では、任意の公開鍵暗号システムに基づく電子署名アルゴリズムを利用可能である。すなわち、平文を署名鍵で処理することで署名を生成し、署名の検証を検証鍵で行う。しかし、データベースにおいては、各レコードにユニークな情報のみが問題となる。従って、この明細書においては、適宜、各鍵ペアにユニークな検証鍵情報を公開鍵と呼び、各鍵ペアの秘匿される署名鍵情報を秘密鍵と呼ぶこととする。例えば、RSA署名では、平文cと署名値sとの関係は以下の通りである。
c = s^e mod n
s = c^d mod ｎ

つまり、平文cに対して、dとnを用いて署名値sを計算できる。また、署名値sに対して、eとnを用いて平文cを計算できる。ここで、署名鍵はdとnであり、検証鍵は、eとnとなっている。通常、eは予め一定の数に決めておくので、実質的な検証鍵、つまり各レコード(電子財布)にユニークな公開鍵はnである。また、nが公開されているので、実質的な秘匿すべき署名鍵(秘密鍵)はdである。

従って、以下の記述では、dのみを秘密鍵と呼び、nのみを公開鍵と呼ぶことにする。また、以下の記述では、パディングやハッシュ処理など平文への前処理も含めて署名の処理とする。例えば、平文へ秘密鍵でべき乗演算を行なって署名を生成する場合も、この平文への署名と呼び、平文のハッシュ値に対して秘密鍵でべき乗演算を行なって署名を生成する場合も、この平文への署名と呼ぶ。更に、以下の実装例では、所定の形式の平文と署名値を別々に扱っているが、署名値は平文の内容を証明している。本システムにおいては、平文が他の情報から生成できるので、生成した平文と署名値を組み合わせれば電子証明書となる。従って、以下の実装例では、適宜、署名値を証明書と呼ぶことにする。

以下の記述では、電子財布データを表す電子財布構造体の例が示されている。これらの例は、電子署名アルゴリズムとして、最も一般的になっているRSA署名に基づいている。しかし、鍵長が非常に短いという特徴を持っているECDSAといった他の電子署名アルゴリズムについても、同様の電子財布構造体が容易に定義できる。

図５に示したように、電子マネー処理サーバー１が、インターネットへ接続している。この電子マネーのユーザーは、後述の電子財布を所有しており、パーソナル・コンピュータ(ＰＣ)、ＰＤＡ、携帯電話などを用い、インターネット経由でサーバー１へアクセスすることでサービスを利用する。

また、図６に示したように、この電子マネー処理サーバー１は、発行者サーバー２と、代理署名サーバー３とからなっている。発行者サーバー２と代理署名サーバー３は、共に汎用コンピュータで実装されており、1000BASE-T、USB3、IEEE1394等の通信ケーブルで互いに接続されている。代理署名サーバー３を専用コンピュータとして、セキュリティを向上させることもできる。

発行者サーバー２は、インターネットから移動リクエストを受信するＳＳＬ通信ユニット４と、記憶装置５と、このＳＳＬ通信ユニット４を介して受信された移動リクエストを記憶装置５を用いて処理する要求処理ユニット６とからなる。ここでＳＳＬ通信ユニット４は、ＳＳＬで保護された通信を行うが、このＳＳＬはＴＬＳ(Transport Layer Security)も含むものとする。

代理署名サーバー３は、電子財布構造体のデータを格納する記憶装置７と、代理署名用秘密鍵を格納し暗号処理を内部で行うＨＳＭ(ハードウエア・セキュリティ・モジュール)８と、記憶装置７で管理された電子財布間で電子マネーの移動を行う移動処理ユニット９とからなる。

この実施例では、インターネットとの通信は、発行者サーバー２のＳＳＬ通信ユニット４を介して行っている。従って、代理署名サーバー３は、インターネットとの直接の通信を行わないので、電子マネー処理サーバー１との組み合わせで、発行者のクライアントシステムを兼ねた、完全な代理署名サーバーとなっている。代理署名サーバーのクライアントである発行者が、代理署名サーバーの運用者となっている為、セキュリティの目的も含めて、このような関係となっている。勿論、代理署名サーバー３がインターネット経由で発行者サーバー２へ接続していても良い。

移動処理ユニット９には、電子マネーの移動処理のみを行う為の機能だけが実装されている。すなわち、移動リクエストが正しくなければ拒否する機能と、正しければ受理し、後述のプロトコルに従って記憶装置７に格納された電子財布間で電子マネーの移動を行う機能である。それ以外の機能は、すべて発行者サーバー２で行う様にしている。このようにすることで、電子マネーの移動に関して、セキュリティを高めることができる。

ここでは、発行者サーバーが、各移動リクエストを一旦トラップしてから代理署名サーバー３へ転送し、代理署名サーバー３の応答も一旦トラップしてからユーザーへ送信するようになっている。これにより、例えば、其々の電子財布に対応してユーザー情報を管理したり、電子財布データのバックアップを取ったりといった事柄可能となる。

ＨＳＭ８は、代理署名用秘密鍵を外部へ出すことなく、移動処理ユニット９からの要求に応じて、この代理署名用秘密鍵による署名を高速に行う。更に、ユーザーによる署名の検証もＨＳＭ８が行っても良い。

ここでは、発行者サーバー２と代理署名サーバー３を別のコンピュータとすることで、セキュリティを向上させている。しかし、簡易的に、発行者サーバー２と代理署名サーバー３を一つのワークステーションで構成することも可能である。

電子マネーは電子財布に保存される。１つの電子財布は、電子財布構造体の１つのインスタンスとなっている。この電子財布構造体は、図７に示したような構造を持っている。この電子財布構造体のインスタンスは、代理署名サーバーと各ユーザーの双方で保存される。しかし、後で詳しく述べるように、電子財布に格納されている電子マネーを安全に管理できるのは各ユーザーだけであり、従って、各ユーザーにその責任が存在する。一方、代理署名サーバーは、電子マネーの二重使用をチェックする必要がある。

電子財布構造体は、当該電子財布の識別番号としてのシリアル番号sn(32ビット整数)と、ユーザー公開鍵user_pubkey(2048ビット整数)と、電子財布の発行日時issue_time(32ビット整数)と、この電子財布への電子マネーの移動を最後に行った電子財布のシリアル番号である移動元シリアル番号sn_payer(32ビット整数)と、電子マネーの最後の受領額received_amount(32ビット整数)と、電子マネーの最後の受領日時receive_time(32ビット整数)と、入金額deposit(32ビット整数)と、出金額withdraw(32ビット整数)と、代理署名サーバーによる代理署名proxy_signature(2048ビット整数)と、ユーザーによるユーザー署名user_signature(2048ビット整数)からなっている。図７では、2048ビット整数の型をbigintとして示しているが、プログラム内部では、一般にプリミティブ型整数の配列で処理される。

ここで、移動元シリアル番号sn_payerと、受領額received_amountと、受領日時receive_timeは、後述のように移動の事実を証明する為に導入されている。しかし、このメンバーは応用によっては省略可能である。省略した場合には、電子財布の構造体を図８に示した様に、よりコンパクトな構成となる。

いずれにせよ、構造体にはポインタは含まれておらず、電子財布は固定長データのみからなる。従って、データベースといっても、各フィールドの合計である796バイトの固定長のレコードが一定間隔で並んでいるだけで良い。

実際には代理署名フィールドは、代理署名サーバーでは使用されないので、省略して良い。もし必要があれば、他のフィールドの値から算出できる。この場合、データベースの電子財布レコードのサイズは、540バイトとなる。

通常は、シリアル番号が主キーとなる。しかし、電子財布のアドレスとシリアル番号が対応して入れば、シリアル番号から算出されたアドレスで直接アクセスされる。従って、シリアル番号のフィールドを省略して、536バイトのデータを電子財布のインスタンスとして格納する様にしても良い。例えば、個々のレコードへのアクセスは、ベースアドレス+sn*536で行うことができる。この明細書では、適宜、文字"*"を乗算演算子として使用する。

また、ユーザーも、所有する電子財布のデータを、ユーザー公開鍵に対応する秘密鍵と共に保存しておく。ただし、ユーザー署名はユーザー側では使用されないので、省略して良い。もし必要があれば、他のフィールドの値から算出できる。その場合、保存すべき電子財布のデータは540バイトとなる。

後述の通り、最初のインスタンスは発行者自身の電子財布であり、このシリアル番号を０としている。その場合、ベースアドレスを０とし電子財布構造体のサイズをDとして、シリアル番号Ｓの電子財布は、アドレスD*Sでアクセスできる。例えば、シリアル番号Ｓの電子財布は、アドレス540*Sでアクセスできる。

一つの電子財布は、構造体の一つのインスタンスに対応しており、データベースではそのままバイナリデータとして格納される。また、一つの電子財布は、やはりバイナリデータとして送信され、バイナリデータのファイルとしてユーザー側で保管される。なお、電子財布とシリアル番号snは一対一に対応しているので、以下の記述ではシリアル番号がsnである電子財布を、適宜電子財布snと表記する。

この電子マネーを利用する為のクライアント・システムの構成の一般的な例を図９に示す。

すなわち、このシステムは、ＳＳＬ通信を行うためのＳＳＬ通信ユニット１１と、署名値を計算する署名ユニット１２と、署名値を検証する検証ユニット１３と、暗号鍵を生成する暗号鍵生成ユニット１４と、ユーザー秘密鍵を保存するユーザー秘密鍵保存手段１５と、電子財布のデータを格納する電子財布構造体格納手段１６とを備えている。そして、更に全体の処理を制御する処理制御ユニット１７が設けられている。

図に示された各ユニットは、システム実装の形態により、ソフトウエア・モジュールとして実装されたりハードウエア(ファームウエア)として実装されたりする。また、各ユニットが個別のモジュールとして実装される場合もあり、他のユニットが一体的に複合モジュールとして実装される場合もある。また、ユーザー秘密鍵保存手段１５と電子財布構造体格納手段１６とが、同一の記憶装置で実装されている場合もあり、各々暗号化されて保存されている場合もある。

まず、パーソナル・コンピュータ(ＰＣ)をクライアント・システムとして利用する場合を説明する。当然ながら、ＰＣにはＯＳがインストールされており、プログラムからインターネットへ接続できるシステム・サービスが稼働しているものとする。

上記各ユニットを含んだ電子財布プログラムとして最も普通に考えられるのは、Webブラウザへのプラグインとしての実装である。この場合、このプラグインには、電子署名などによりＰＣ内部の電子財布のデータへのアクセス権が与えられているものとする。このプラグインは、ユーザーの操作やＨＴＭＬファイルに従って、適宜公開鍵と秘密鍵のペアを生成したり、署名をしたり、検証したり、電子財布のデータを更新したりする。具体的な操作や動作は、後で電子財布の操作目的に沿って説明する。

電子財布のデータやユーザー秘密鍵は、例えば、暗号化してからＰＣ内部のハードディスクやUSBメモリ等の外部メモリへ格納しておくことができる。この場合暗号化鍵は保存せずに、その都度パスワードから生成する様にする。しかし、電子財布のデータとユーザー秘密鍵を同一ＰＣで扱うのは、好ましくない。例えば、秘密鍵を外部へ出すことなく内部で暗号処理を行うＨＳＭを使うこともできるが、コストがかかる。高価なＨＳＭを用いずに、これらを別々に扱う方法の幾つかが後で示される。

要素proxy_signatureは、上記電子財布構造体のメンバーの中からsn、user_pubkey、issue_time、sn_payerと、received_amountと、receive_timeおよびdepositを連結したビット列データを平文として、代理署名サーバーの秘密鍵によって得られた署名値である。

また、要素user_signatureは、sn、user_pubkey、issue_timeおよびwithdrawを連結したビット列データを平文として、ユーザー公開鍵user_pubkeyに対応するユーザーの秘密鍵によって得られた署名値である。署名アルゴリズムは、この電子マネーの発行者によって公開されている契約書（約款）によって、SHA256WithRSAEncryption等と指定されている。代理署名とユーザー署名の署名アルゴリズムは必ずしも同一でなくても良い。ユーザーは、ユーザー公開鍵に対応するユーザー秘密鍵を用いて、電子財布構造体のインスタンスである電子財布に入っている電子マネーを使用する。

代理署名の検証に用いられる公開鍵は別途ダウンロード可能となっており、認証局(ＣＡ)の公開鍵証明書によって、運用者のものであることが証明できる。また、ユーザー公開鍵は、代理署名によって保証されている。従って、代理署名は、シリアル番号"sn"、ユーザー公開鍵"user_pubkey"、発行日時"issue_time"および入金額"deposit"と組み合わせて、入金額証明書となっている。同様に、ユーザー署名は、シリアル番号"sn"および出金額"withdraw"と組み合わせて、出金額証明書となっている。

電子財布の残高は、入金額から出金額を差し引いたものである。ここでの入金額とは、電子財布の発行時からの累計の入金額である。同様に、出金額とは、電子財布の発行時からの累計の出金額である。従って、ユーザーは、この残高の範囲で電子マネーを使用することができる。また、代理署名サーバーは、この残高を超える電子マネーの使用は拒否できる。

また、一般公開情報として電子マネーの使用に関する契約書が、電子マネーの発行者のサイトからダウンロード可能に提供されている。この契約書の一方の当事者は発行者であり、他方は各電子財布の入金額証明書で証明されている公開鍵に対応する秘密鍵を有するユーザーである。

契約書には、ＣＡによって証明されている発行者自身の署名が付けられており、少なくとも以下の内容が含まれている。

１）電子財布構造体の構成、有効期限、代理署名サーバーが従うべきプロトコル。
ここでは、代理署名サーバーの動作について記述している。電子財布の代理署名とユーザー署名の方式および代理署名検証用公開鍵についての記述も含まれている。例えば、公開指数が65537で2048ビットのRSAと、ハッシュ関数SHA-256等を指定する。また、有効期限は、電子財布データの発行日時から１年といった具合に決めておく。代理署名サーバーのプロトコルの好適な具体例は、後に詳しく説明する。

２）発行者の情報、電子マネーの使用範囲。
ここでは、発行者が誰で、電子マネーはどのように使用できるかについて記述している。

３）発行者およびユーザーの責任の範囲。
ここでは、特に、真正な出金額証明書に基づいて行われた行為については、発行者は責任がないという点が確認されている。すなわち、真正な出金額証明書を持っていれば誰であっても、それに対応する電子マネーを使用する権利を持っていることが明記されている。また、電子マネーの使用要求を受けた場合、代理署名サーバーは、対応する出金額証明書の提示によらなければ、その使用要求を拒否できない点が確認されている。

以下、ユーザーからのリクエストに対する、代理署名サーバーのプロトコルについて説明する。リクエストは、一つの電子財布から別の電子財布へ電子マネーを移動する為のものである。

上記の通り、電子マネーの移動を行うには、移動元電子財布に移動する電子マネーと等しいか大きな残高がなければならない。従って、代理署名サーバーの初期設定として、発行者の電子財布が生成されていなければ、電子マネーのシステムは機能しない。

ここでは、発行者の電子財布のシリアル番号は０とし、ユーザー公開鍵は発行者の公開鍵であるが、一般には入金額証明書を検証する為の代理署名サーバーの公開鍵とは別物である。この実施例では、発行者も代理署名サーバーのユーザーにすぎない。発行日時は、便宜上３００年後といった未来の値としておく。これは、この電子財布は期限切れとならないための設定である。また、入金額は0x40000000、出金額は0とする。この場合、代理署名サーバーから見た残高は0x40000000であるが、経理上は実質残高０と考えられる。実質残高は、(入金額 - 0x40000000) - 出金額で算出されるであろう。その他の初期設定は、サーバーの動作や電子マネーの運用には影響を与えないので、すべてNULLとしておく。

後述の通り、ユーザーが電子財布を購入すると、発行者の電子財布から新たな電子財布へ電子マネーが移動される。従って、初期値として、発行者の電子財布には十分な入金額が設定されている必要がある。応用によっては、入金額のビット数を大きくしておく。

また、ユーザーが換金を希望する場合には、ユーザーの電子財布からこの発行者の電子財布へ電子マネーが移動される。この電子マネー・システムが稼働開始直後は、発行者の電子財布にのみ残高があり、これが他の電子財布へと移動し、また、一般ユーザーの電子財布同士での電子マネー移動が行われていく。この場合、システム全体で見れば、残高は変わらないことになる。しかし、この実施例では、電子マネーの移動に対して所定の手数料がかかるので、移動元電子財布の出金額の増加幅は、移動先電子財布の入金額の増加幅にこの手数料を加えたものに等しい。従って、電子マネーの移動が行われる毎に、システム全体の残高が減少していくことになる。

以下の例では、代理署名サーバーは、電子財布間で電子マネーの移動だけを機械的に行う。従って、代理署名サーバーからみれば、発行者自身もユーザーの一人であり、他のユーザーと何ら変わるところはない。ただし、上記の通り、発行者の電子財布を例外的に扱う方法もある。

以下、図１０を参照して、移動リクエストに対する代理署名サーバーの移動プロトコルを説明する。この移動プロトコルに従った処理は、一つのＳＳＬセッションの中で完結する。ここでは、サーバー認証のみが行われ、ＳＳＬによるクライアント認証は行われない。処理が中断してセッションがタイムアウトすると、セッションの処理情報は破棄される。タイムアウトの時間は、セッションの最大継続時間である。

電子マネーの移動には、ユーザーが手数料fを支払うものとする。しかし、発行者の電子財布が移動元であれば、電子マネーの購入であって使用ではないので、代理署名サーバーにおいて手数料fはかからないようにすることもできる。先ず、電子マネーの移動を希望するユーザーは、クライアント端末を介して、移動元および移動先の電子財布のシリアル番号s1およびs2、移動先の電子財布のユーザー公開鍵n2、出金額w1、移動額v、移動手数料fと共に、移動リクエストを送信する(U1)。なお、上記システム例において、代理署名サーバーとユーザー間の発行者サーバー２が、セキュリティ対策の目的で、移動元ユーザーに対して移動元電子財布のユーザー公開鍵n1の添付を要求しても良い。もしも、ユーザー公開鍵n1が正しくなければ、その移動リクエストは代理署名サーバーへ転送することなく拒否される。

移動先の電子財布のユーザー公開鍵n2は、省略しても良い。すなわち、移動リクエストに添付されるユーザー公開鍵n2をNULLとしても良い。代理署名サーバーは、NULLの公開鍵を正しいものとして受け入れる。もしも、移動元ユーザーが、正しいユーザー公開鍵n2を知っている場合には、それを添付することで誤送金を防止することができる。例えば、オンラインショップが、移動先電子財布のシリアル番号に加え、公開鍵証明書を開示している場合、ユーザー(購買者)は、その公開鍵を添付することで移動先を確実に特定できる。

移動先の電子財布のシリアル番号s2として、0xFFFFFFFFを指定した場合には、移動先が新規の電子財布であることを示している。この場合には、代理署名サーバーは、未使用のシリアル番号を決定して新規の電子財布の為の構造体インスタンスに対して処理を行う。上記移動リクエストには、新規の電子財布のユーザー公開鍵n2となるべき公開鍵を添付しておく必要がある。

代理署名サーバーは、この移動リクエストを受信すると(S1)、受理可能か否かを確認する(S2)。受理可能であれば、代理署名サーバー内のデータベースの電子財布s1およびs2のレコード（構造体インスタンス）に対して、排他ロックを設定し、移動リクエスト受理通知をクライアントへ送信し(S3)、クライアントからの出金額証明書として署名値の受信を待つ。

一方、移動リクエストが受理できない場合には、不受理通知が返される(S4)。例えば、受信した出金額w1が、代理署名サーバー内のデータベースのレコードと矛盾していたり、出金額w1と移動額vと手数料fの和が、電子財布s1の入金額を超えていた場合には、この移動リクエストは不受理となる。しかし、発行者の電子財布を例外的に扱う場合には、発行者の移動リクエストは、出金額w1と移動額vと手数料fの和が、電子財布s1の入金額を超えていても、発行者の移動リクエストを拒否しない。また、0xFFFFFFFF以外の移動先の電子財布のユーザー公開鍵が添付されており、代理署名サーバー内のデータベースのユーザー公開鍵と違っている場合にも、移動リクエストは不受理となる。

そして、不受理通知と共に、その理由が通知される。提示された出金額w1が代理署名サーバー内のデータベースの記録よりも小さい場合には、正しい出金額w1と共に証拠として記録されているユーザー署名がクライアントへ送信される。ユーザーは、受信した出金額とユーザー署名により、対応する電子マネーが既に使用されていたことを確認できる。

また、一つの電子財布に対して、一つの移動リクエストのみが受理される。つまり、対応するレコードに排他ロックがかけられており、電子財布s1又はs2に対して、何らかの処理が行われている途中であれば、やはりこの移動リクエストは不受理となる。不受理の場合は(U2、NO)、クライアントにはその表示が行われる(U3)。

移動リクエスト受理通知があれば(U2、YES)、クライアントは、ユーザー秘密鍵p1を用いて、s1（32ビット整数）、ユーザー公開鍵n1(2048ビット整数)、発行日時t1（32ビット整数）に、w1+v+f（32ビット整数）を連結して得た2144ビットの平文データを作成する(U4)。そして、クライアントは、この平文データに署名して、SigU1としてのユーザー署名{s1, n1, t1, w1+v+f}p1を生成する(U4)。なお、この連結は、上記の通りビット列として単純に連結する。このユーザー署名SigU1は、代理署名サーバーへ送信する(U5)。

署名値SigU1を、所定時間内に受信しないと(S5、NO)、代理署名サーバーは処理を終了する。署名値SigU1を受信すると(S5、YES)、代理署名サーバーはn1を用いて、平文{s1, n1, t1, w1+v+f}に対する署名SigU1の検証を行う(S6)。検証が失敗すれば(S7、NO)、理由と共に不受理の通知を行い、処理を終了する。すなわち、署名値SigU1によってクライアント認証を行っている。不受理の通知を受けたクライアントは(U6、YES)、不受理の表示を行い処理を終了する。

検証が成功すれば(S7、YES)、電子財布s1と電子財布s2のデータを更新する(S8)。すなわち、電子財布s1の出金額w1とユーザー署名を、w1+v+fとSigU1に更新する。また、電子財布s2の構造体インスタンスについては、移動元シリアル番号、受領額および受領日時を、夫々、s1、v、現在時刻tcで更新する。更に、入金額d2は、vを加算して更新する。電子財布s2が新規の場合は、受信したユーザー公開鍵n2を書き込み、発行日時t2を現在時刻tcとし、出金額w2を０とし、入金額d2をvとしておく。

次に、代理署名サーバーは、更新されたデータをもとに、電子財布s2のシリアル番号s2と、ユーザー公開鍵n2と、発行日時t2と、移動元シリアル番号s1と、移動額vと、受領日時tcと、入金額d2とを、夫々ビット連結した2240ビットの平文を作成し、これに署名を行って代理署名SigI2を生成する(S9)。

最後に、署名値SigI2を含む電子財布s2のレコードと共に移動完了通知をクライアントへ送信して(S10)、処理を終了する。この場合、電子財布s2のレコードから、出金額w2やユーザー署名SigU2が無くても、クライアント側で代理署名の検証は可能である。適宜、移動完了通知から出金額w2やユーザー署名SigU2の送信は省略しても良い。

クライアントは、移動完了通知を受信したら、電子財布s2の署名値SigI2を検証して(U7)、検証に成功すれば処理を終了する(U8、YES)。通常はあり得ないが、検証に失敗すれば(U8、NO)、エラーの表示を行う(U9)。

上記の通り、電子マネーの移動を行ったクライアントは、移動完了通知と共に署名値SigI2を含む入金額証明書を受け取る。この入金額証明書は、受領日時(receive_time)に、電子財布s1 (sn）から電子財布s2(sn_payer）へ受領額v(received_amount）だけの電子マネーが移動したという移動証明書にもなっている。クライアントは、受け取った入金額証明書を、支払いの確認書として移動先(ショップなど)へ送信する。また、移動先が、ユーザー公開鍵にＣＡによる公開鍵証明書を公開していれば、移動証明書は移動先電子財布の所有者をも特定したものになる。

上記プロトコルでは、移動元の電子財布のユーザー公開鍵の送信は必須ではない。しかし、常にこれを要求することで、セキュリティを向上させることも可能である。この場合、正しい移動元電子財布のユーザー公開鍵の送信がなければ、移動リクエストは拒否される。

また、代理署名サーバーの秘密鍵は、対応する公開鍵証明書が公開されていれば、同じものでなくとも構わない。すなわち、任意のタイミングで更新可能である。その更新によって公開鍵証明書の有効期限が延長されるが、それに伴って電子財布の有効期限も延長することが望ましい。

本実施例の電子マネーは、一つの電子財布から別の電子財布へ移動することで利用される。例えば、商品の購入者は、自分の電子財布から、オンラインショップの電子財布へ電子マネーを移動することで支払いを行う。この場合、オンラインショップの電子財布は常に移動先となるので、取引にあたって、受け取った移動証明書を代理署名サーバーの鍵で検証して、支払いの確認を行えば良い。従って、月末の電子マネー換金といった時以外は、秘密鍵は用いないので、その管理は容易である。

また、オンラインコンテンツを購入するのと同様に、電子マネー(電子財布)を購入できる。すなわち、購入者は、ユーザー公開鍵および入金額の組み合わせを商品都市的指定することで電子財布を購入する。電子財布販売を行うオンラインショップ(発行者または他のブローカー)は、支払いを受けて、自分の電子財布から指定された公開鍵に関連付けられた新規の電子財布へ、入金額の電子マネーを移動する。そして、移動証明書が購入者へ渡される。購入者は移動証明書で、電子財布の中身を確認する。

更に、換金も同様に可能である。すなわち、ユーザーは自分の電子財布から、オンラインショップの指定する電子財布へ換金額および手数料の電子マネーを移動する。オンラインショップは、移動証明書を確認して、ユーザーの銀行口座等を利用して換金を実行する。

次に、一般ユーザーが、本件発明の電子マネーを利用する手続きの一例を示す。少額取引に限定する場合は、より使い勝手のよいシンプルな方法も考えれるが、ここでは、セキュリティを重視した方法を説明する。

電子財布は、上記の通りオンラインショップから、他の有料コンテンツと同様に購入できる。ただし、予めブラウザには、プラグインとして電子財布ユーティリティがインストールされているものとする。このプラグインには、電子署名などによりＰＣ内部のローカルストレージへのアクセス権が与えられているものとする。また、購入者は、予め電子財布用のアプリがインストールされている携帯電話を所有しているものとする。この携帯電話には内蔵カメラが備えられている。以下、図１１を参照して、電子財布購入手続きを説明する。

すなわち、購入者が、オンラインショップのＳＳＬ対応サイトにアクセスし商品として電子財布を選択すると、ウインドウＷ１が開く。ここで購入者は入金額を指定し、購入ボタンを押す。するとプラグインが実行される。ここで、プラグインが実行する処理は、次の通りである。

先ず、処理中である旨の表示を行ってから、公開鍵と秘密鍵のペアを生成する。また、その公開鍵(ユーザー公開鍵)を秘密鍵で署名した自己署名も生成する（Ｓ１）。この鍵ペアは、ディスクへは保存せずにメモリだけにおかれる。そして、ユーザー公開鍵、自己署名および入金額をオンラインショップへ送信する（Ｓ２）。オンラインショップでは、受け取った自己署名を検証してから、受領の応答を返す（Ｓ３）。そして、ウインドウＷ２が開き、電子財布の購入準備が整った旨の表示を行う（Ｓ４）。

この表示で、公開鍵および秘密鍵をQRコード等で印刷することができる。又は、画面にQRコードを表示し、携帯電話のカメラで取り込んでおくこともできる。これは、通信エラー等に備えておく為であり、ウインドウＷ２を省略して処理を簡略化しても良い。その後、決済画面が表示され、オンラインコンテンツ等の商品購入の手続きと同様に支払いを行う。なお、上記支払いの手続きは、通常のオンラインの支払い手続きと同じであり、よく知られているのでここではその説明を省略する。

支払い確認後、オンラインショップでは、受信した公開鍵に対応する新規電子財布に購入した電子マネーを移動する。そして、プラグイン経由で移動証明書がこのＰＣへダウンロードされる（Ｓ５）。この移動証明書を格納するファイルは、他のプロセスとは共有不可のテンポラリファイルとしてＰＣで生成される。そして、プラグインは、この新規電子財布の秘密鍵を、識別の為に参照番号を関連付けて、ＰＣの所定の記憶領域に保存する（Ｓ６）。

また、プラグインは、移動証明書から、この新規電子財布の構造体データと秘密鍵の情報を含む連結ＱＲコードを生成して、図１２のように印刷する（Ｓ７）。図１２では、上段が構造体データであり、中段および下段が重複して秘密鍵となっている。また、構造体データのＱＲコードは、複数のシンボルからなる連結ＱＲコードとなっており、ユーザー署名のデータは常に初期値０なので含まれていない。印刷の後、テンポラリファイルは完全に削除しておく。これで、秘密鍵以外の電子財布の情報はＰＣには残らない。この印刷した構造体データ(上段)は、上記アプリにより携帯電話に取り込んで、電子財布構造体として管理される（Ｓ８）。

以上の様に、電子財布構造体と秘密鍵は、携帯電話とＰＣとで別々に保存される。従って、携帯電話とＰＣの双方がなければ、電子財布を使うことができず安全性が高まる。また、後述の通り、秘密鍵のＱＲコードが印刷された上記下段を切り取って持っていけば、外出時であっても携帯電話のみで利用することもできる。例えば、上記秘密鍵の紙片は、本当の札入れに入れておく。

若干のリスクはあるが、秘密鍵のQRコードを直接携帯電話へ取り込んで、携帯電話で管理してもよい。しかし、印刷した紙片は、そのままバックアップとなるので安心である。

ユーザーは、携帯電話で電子財布を利用することができる。上記の通り、携帯電話には予め電子財布用のアプリがインストールされており、電子財布構造体が取り込まれている。

ただし、予めブラウザには、プラグインとして電子財布ユーティリティがインストールされているものとする。このプラグインには、電子署名などによりＰＣ内部のローカルストレージへのアクセス権が与えられているものとする。現行の携帯電話の多くは、ＳＳＬ通信が可能でPKI関連のAPIが利用できるようになっており、この目的で利用可能である。

ＰＣ側で、オンラインショップでの支払いに電子マネーを指定すると、オンラインショップのサーバーは、移動先電子財布のシリアル番号と、支払い金額と、移動証明書送信用のＵＲＬと、受注番号、商品名等の購入情報をＰＣ側へ送信する。プラグインは、それらの購入・支払い情報を受信し、これらの情報を、ＰＣに保存されている秘密鍵と共に連結ＱＲコードを生成して、図１３のように支払い画面に表示する。

購入者が携帯電話で上記アプリを起動し、ＰＣの画面に表示されているＱＲコードを取り込むと、携帯電話の画面に、図１４の様な購入・支払いの詳細が表示される。複数の電子財布が有効な場合には、アプリ側で自動的にいずれか一つが選択される。ここで購入者は、その内容を確認し、必要により支払いに利用する電子財布を変更して、実行ボタンをクリックする。すると、アプリは、代理署名サーバーにアクセスして支払い金額の電子マネーを移動先電子財布へ移動し、その後受注番号および移動証明書をオンラインショップへ送信する。オンラインショップでは、受信した移動証明書を検証すると、図１５のようにＰＣ側で入金完了の表示を行う。そして、商品がオンラインコンテンツであれば、ダウンロードが可能となる。

上記携帯電話を用いれば、上記アプリケーションを立ち上げて、本電子マネーをリアル店舗で利用することも可能である。本電子マネーを利用可能な店舗では、バーコードやＱＲコードで商品の価格が表示されている。勿論、手入力で直接金額を携帯電話へ打ち込んでも良い。また、店舗側の電子財布のシリアル番号や支払い補助サーバーのＵＲＬもＱＲコードで表示されている。このＵＲＬには、リアル店舗の識別番号も含まれている。

客はＱＲコードを携帯電話で読み取ってから商品を買い物かごへ入れる。携帯電話では、価格を加算して総額を計算する。レジへ行く前に、客は携帯電話で代理署名サーバーにアクセスし、店舗の電子財布への支払いを行う。そして、支払い補助サーバーへアクセスして、リアル店舗の識別番号と共に移動証明書を送信する。支払い補助サーバーは、移動証明書の受領日時を確認し検証をしてから、支払い番号を返す。この支払い番号は、携帯電話で表示される。同時に、支払い補助サーバーは、リアル店舗の識別番号を参照して、その店舗のレジにも移動元電子財布のシリアル番号と共に、支払い番号と移動額を送信する。個人商店のように、レジが対応していない場合には、予め登録してある店員の携帯電話に送信する。従って、レジで計算した後、客は、現金で支払う代わりに支払い番号を口頭で伝えるだけで良い。より正確には、シリアル番号で支払者を確認することもできる。また、万一、計算間違いがあれば、現金で清算すれば良い。

上記した電子財布の購入では、一時的ではあるが、ＰＣが秘密鍵と公開鍵や電子財布構造体のすべてを扱う。より、安全性を高めるには、秘密鍵と電子財布構造体を完全に分離することが望ましい。以下、そのような方法の例を説明する。ＰＣ側にはプラグインがインストールされ、携帯電話側には、電子財布用のアプリケーションがインストールされている。このアプリケーションは、専用アプリケーションでも良いし、ウェブブラウザとしても機能しても良い。

先ず、ＰＣ側のプラグインで、公開鍵と秘密鍵の鍵ペアを生成し、その公開鍵を秘密鍵で署名した自己署名も生成する。この鍵ペアには（上記参照番号となる）ユニークな識別番号が付されており、この識別番号と公開鍵および自己署名がQRコードで表示される(図１６)。また、秘密鍵は識別番号に関連付けられ、ディスクに保存され、ＰＣで管理される。

購入者は、表示されている公開鍵や自己署名を、識別番号と共に携帯電話に取り込む。

購入者は、携帯電話でオンラインショップにアクセスし、入金額を指定して電子財布の購入を選択してから、携帯電話に保存されている公開鍵と自己署名がアップロードされる。この処理は、携帯電話にインストールされているアプリで行う。オンラインショップでは、自己署名を検証してから、携帯電話に決済画面を表示する。そして、通常のオンラインコンテンツ等の商品購入の手続きと同様に支払いが行われる。

支払い確認後、オンラインショップでは、受信した公開鍵に対応する新規電子財布に購入した電子マネーを移動する。そして、移動証明書が携帯電話にダウンロードされ、電子財布構造体として管理される。電子財布の利用は、上記の通りＰＣの秘密鍵を用いて携帯電話で行う。

図１７は、電子財布の購入１を示す。この場合、ＰＣが鍵ペアを生成し、電子財布の購入を行う。この電子財布は、携帯電話へ送信後にＰＣから削除される。図１８は、電子財布の購入２を示す。この場合、携帯電話がＰＣから送信された公開鍵を用いて電子財布の購入を行う。これらのケースでは、ＰＣから送信された秘密鍵を用いて、携帯電話が電子財布を使って商品購入を行う。秘密鍵は、使用後に携帯電話から削除される。より完全に秘密鍵と電子財布を分離するには、例えば、次のようにする。

図１７や図１８では、電子財布利用の際に、ＰＣから携帯電話へ支払い情報と秘密鍵が送られているが、図１９に示した例では支払い情報のみを送るようにする。そして、携帯電話では、支払い情報と電子財布構造体の情報に基づいて、秘密鍵で署名を行うべき(ハッシュ等の前処理を行った)平文を計算し、ＰＣへ送信する。ＰＣでは、受け取った平文に秘密鍵で署名を行い、署名値を携帯電話へ送信する。携帯電話では、受け取った署名値によって支払いを行う。この場合、署名の為、公開鍵も秘密鍵と共にＰＣに保存しておく。

また、図２０では、携帯電話で鍵ペアを生成し、その公開鍵をＰＣへ送信する。非力な携帯電話の場合では、鍵ペアを生成するには時間がかかるが、購入の段階だけなので大きな支障はない。ＰＣでは、この公開鍵に基づいて電子財布の購入を行い、電子財布の管理も行う。電子財布の使用するには、ＰＣ側で署名が必要な(ハッシュ等の前処理を行った)平文を計算し、携帯電話へ送信する。携帯電話では、これに署名を行い、ＰＣへ送信する。この署名を用いて、ＰＣ側で支払いが行われる。

図１８ないし図２０では、ＰＣから携帯電話への通信と、携帯電話からＰＣへの通信が存在する。ＰＣから携帯電話への通信は、上記の通り、QRコードを携帯電話のカメラで読み取るので、実装が容易でセキュリティも高い。ＰＣにカメラが設けれていれば、携帯電話からＰＣへの通信も同様に行うことが可能となる。ＰＣにカメラが設けれていなければ、携帯電話からＰＣへの通信は、インターネットを経由して行うことができる。すなわち、上記QRコードにＰＣのメールアドレスを含ませるようにすれば、携帯電話から必要なデータをＰＣへ送信することができる。または、QRコードを表示した後、ＰＣ側の電子財布プログラムでは所定のポートでリッスンを行う。QRコードには、ＰＣのＩＰアドレスと共に所定のポートの番号も含まれている。従って、携帯電話は、この場合ＩＰアドレスとポート経由で必要なデータをＰＣへ送信することができる。

ＰＣのみで電子マネーを利用できると便利である。その為に、代理署名サーバーとユーザーとの間で、秘密情報が共有される。ただし、この秘密情報は、あくまで補助的なものであり、代理署名サーバーにセキュリティ上の負担を追加するものではない。ここでは、図７の電子財布構造体に対して、図２１に示したように共有する秘密情報としてパスワード要素"password"が追加されている。このパスワード要素pwは、ユーザーによって設定される。以下、図１０のフローチャートと異なる点のみを説明する。

すなわち、図１０のステップU1において、移動リクエストと共に、ユーザーは更にパスワードのペアを送信する。代理署名サーバーは、このパスワードのペアを受取り、電子財布のパスワード要素がNULL(0)でなければ、ペアの最初のパスワードと照合する。このNULL(0)は、パスワードが設定されていないことを意味する。最初のパスワードがNULLでないパスワード要素と一致していない場合、移動リクエストは拒否される。最初のパスワードがパスワード要素と一致している場合、移動リクエストは受理される。最初のパスワードpwを用いて、ユーザーは、図１０のステップU4において、ユーザー署名{s1, n1, t1, w1+v+f, pw}p1を生成する。すなわち、ユーザーは、パスワードpwが設定されていることを証明する。図１０のステップS8において、電子財布のパスワード要素ペアがペアの他方のパスワードによって更新される。これにより、ユーザーはパスワードの更新が容易に行える。従って、パスワードを秘匿しておく限りにおいて、ＰＣに保存してあるすべての情報が盗まれても、パスワードレベルのセキュリティは確保される。ただし、代理署名サーバーは、電子財布に関するいかなる損害にも責任を負わない。

上記例では、アクセスするユーザーを認証する為の秘密情報が、電子財布構造体に含まれている。電子財布構造体から秘密情報を除くこともできる。これは、図３６に示した後述のMACユニットから、各アクセスユーザーの秘密情報を生成することで実現する。例えば、認証が必要な場合、図３６のMACユニットへ、鍵Ｋの上位24ビットとしてシリアル番号sを入力し、他の下位488ビットを０にセットすることにより、秘密情報を生成することができる。認証は、この秘密情報の下位の数桁の数字を、ユーザーがパスワードとして入力した数桁の数字と、この秘密情報の下位ビットと比較することで行う。

携帯電話で活動するマルウェアは限られているので、携帯電話で電子財布を購入し、携帯電話で電子マネーを使用するということもできる(図２２)。上記の通り、QRコードなどを利用して携帯電話で支払いを済ませ、レジで支払い番号を口頭で伝えるだけで良い。携帯電話を紛失した場合には、現金同様に盗用されてしまうが、携帯電話そのものと同程度の金額であれば、電子財布の完全な情報を携帯電話に保存するのも現実的な選択肢の一つである。なお、図２２において、価格情報を携帯電話へ入力した後の、ステップii)、iii)、iv)、v)は、ソフトウエアによる一連の処理として自動で実行される。

ユーザーは秘密鍵を排他的に所有する限りにおいて、自己の資産は電子財布そのものの情報によって安全である。しかし、代理署名サーバーの秘密鍵の漏洩がない場合でも、代理署名サーバー内のデータベースの情報が破損したり改竄されたりした場合、発行者には一定の損害が発生する。例えば、代理署名サーバー内のデータベースから、ユーザー署名を削除されると、不正直なリクエストに対して出金額の立証ができなくなってしまう。

このような場合に、取引のログを収集しておけば、代理署名サーバー内のデータベースの復旧が可能である。発行者サーバー２は、電子マネーの移動毎に、送受信された入金額証明書と出金額証明書を、取引ログに保存しておくと良い。これにより、代理署名サーバー内のデータベースが故障した場合でも、出金額の証明が可能である。

更に、このようなログ情報は、非常にシンプルなデータ構造なので、統計的な処理により様々な情報の抽出を行い得ると考えられれる。例えば、常時電子マネーの流れをモニターすることで、経済全体の動きを推量したり、不自然な電子マネーの動きを抽出することも可能である。

コンサートのチケットを電子マネーで購入する場合を考える。上記の通り、購入者は、チケット販売サイトの電子財布（移動先電子財布）へ所定の額の電子マネーを移動し、移動証明書をチケット販売サイトへ送信する。

ここでは、移動証明書を送信する際に、支払いに用いた購入者の電子財布の入金額証明書もチケット販売サイトへ送信する。これは、この入金額証明書を、購入者の公開鍵証明書として利用する為である。移動証明書を確認の後、チケット販売サイトは、図２３および図２４に示したような電子マネー受領証と入場証明書を発行する。電子マネー受領証は、移動先電子財布の公開鍵に対応する秘密鍵で署名されている。この公開鍵には、公開鍵証明書が公開されている。

電子マネー受領証では、そこに記載されたチケットの代金としての電子マネーの受領と、移動元電子財布の入金額証明書で証明された公開鍵に対応する秘密鍵で署名のなされた入場証明書と引き換えにコンサート会場への入場を許可する旨が記載されている。また、入場証明書は、購入者が署名をしてデジタル・チケットとして使用できる。

例えば、購入者は、チケットの識別番号と共に入場証明書の署名をQRコードで紙片に打ち出しておく。これがデジタル・チケットとなり、QRコードリーダの設置された入り口で提示する。入り口では、識別番号によって既に入場が行われていないかを確認する。

もしも、この識別番号によって既に入場が行われていれば、先に入場者から得た署名付き入場証明書のコピーを示して、入場を拒否する。すなわち、本発明の考え方からすれば、先の入場者は正規の購入者と看做される。

まだ入場が行われていない場合には、そこで提示された入場証明書の署名をスキャンして、正当な入場者であることを確認してから、入場を許可する。この署名付き入場証明書は、当該識別番号に対応する入場を証明する証拠として保存しておく。QRコードリーダは、インターネットに接続し、カメラの搭載されたネットブックまたは係員の携帯電話でも良い。このネットブックや携帯電話には、予め発行された入場証明書と、その(ハッシュ等の前処理を行った)平文および対応する公開鍵がダウンロードされており、提示された入場証明書の署名の検証に使われる。これにより同一デジタル・チケットの二重使用が防止される。

この方法は、鉄道、バス、飛行機といった乗り物の自由席券や指定席券といったチケットにも、同様に応用できる。

次に、コンビニなどの店舗で電子財布の購入を行う場合を説明する。電子財布の購入を希望するユーザーは、ＰＣから店舗のＳＳＬ対応サイトへアクセスして、電子財布購入の申し込みを行う。その際に、この申し込みには、購入する電子財布のユーザー公開鍵と入金額の情報が含まれている。秘密鍵はＰＣへ保存されるが、ここでは支払いを行わない。

店舗のサイトでは、申し込みに対して、有効期限を指定した予約受付番号を発行する。この段階では店舗サイトでは、購入申し込みの内容を保存しておくだけで、電子マネーの処理は行わない。有効期限、例えば３日を過ぎた購入申し込みは消去する。

申し込みの後、ユーザーは店舗へ出向き、予約受付番号を提示して、所定の金額を支払う。支払いを受けた店舗は、店舗サイトへ支払いの情報を送信し、予約受付番号に対応する予約情報に基づいて、店舗の電子財布から新たな電子財布へ電子マネーが移動される。ユーザーには、購入した電子財布のシリアル番号が印字されたレシートが渡される。

その後、ユーザーは、このシリアル番号と購入予約受付番号によって、店舗のサイトから新たな電子財布の構造体データをダウンロードできる。ダウンロードは携帯電話で行い、この電子財布の使用は、図１７、図１８または図１９の使用フェーズで説明した様に行う。なお、支払い金額は、電子財布に含まれる電子マネーの総額に、代理署名サーバーおよび店舗の処理手数料を加えたものとなる。この購入方法により、未成年や学生などクレジットカードを持っていないユーザーでも、電子財布を購入することができる。

上記電子マネーを利用して、デジタルコンテンツを匿名でダウンロード購入できる。しかし、書籍や日用雑貨などのリアル物品の購入の場合は、支払いを匿名で行っても、受け取りの段階で住所氏名の配送情報が必要となる。

受け取りも匿名で行う方法を、以下に示す。ここでは、コンビニなどの店舗において受け取りを行うものとする。すなわち、オンラインショップでリアルな商品を購入するにあたって、購入者は、具体的な店舗名を指定して店舗受け取りを希望する。具体的な店舗名は、例えば、オンラインショップサイトのページに表示されたコンビニのチェーン店の中から指定する。更に、店舗受け取りの期間、例えば、2010年11月10日から2010年11月14日までに受け取ることを指定する。これらの購入情報は、購入者のシリアル番号s1と共にオンラインショップへ送信される(図２５のｉ）。

これに対して、オンラインショップは、代金を受け取るオンラインショップの電子財布のシリアル番号s2、識別のための購入番号およ注文内容の詳細を記載した注文受理通知を購入者へ送信する(図２５のii）)。購入者は、上記の通り電子マネーの移動リクエスト(s1->s2, v)を送信し(図２５のiii）)、移動証明書を受け取る(図２５のiv）)。

そして、購入者は、移動証明書と共に、購入者自身の電子財布の入金額証明書{s1, n1, ...}psをオンラインショップへ送信する(図２５のv）。オンラインショップは、移動証明書を確認して、電子マネー受領証および商品受領証を発行する(図２５のvi）)。この電子マネー受領証には、ショップ側の署名が付けられており、移動元と移動先の電子財布のシリアル番号や、移動額の受理を含む売買の詳細と共に、購入者の商品を受け取る権利が証明されている。また、上記受け取り店舗や商品受け渡しの期間も指定されている。そして、オンラインショップは、商品を発送する(図２５のvii）)。

この商品受領証は、購入者による商品の受領を記載したものである。購入者は、このファイルのハッシュ(SHA-256)に上記電子財布の秘密鍵p1で署名を行い、署名をＱＲコードに変換して、商品受領証と共にプリントアウトしておく。

その後、購入者は店舗へ出向き、購入番号を示して商品の受け渡しを求める。店舗では、商品の保管を確認し、ＱＲコード（{商品受領証}p1）の提示を求める。そして、購入番号をもとに、発送元であるオンラインショップのサイトから対応する公開鍵n1と商品受領証をダウンロードし(図２５のviii）、購入者が提示したＱＲコードの署名を検証する(図２５のix）。署名の検証が成功すれば、商品の引き渡しを行う。署名は商品受領証として店舗側サーバーに保存しておく。

電子マネー受領証と商品受領証の具体例を、図２６や図２７に示す。図２６の電子マネー受領証は、オンラインショップの署名によって、商品受領の権利を有することが保証されている。図２７の商品受領証の署名によって、ユーザーは、自分が商品受領の権利を持つ購入者であることを証明でき、またオンラインショップ側では商品受領の事実を証明できる。このユーザー署名の検証に用いる公開鍵は、移動元の電子財布の入金額証明書で証明されている。

応用によっては、電子財布間の移動に制限を設けることが望ましいこともある。例えば、現在流通するプリペイドカードのように、発行者以外の電子財布間の電子マネーの移動を禁止してもよい。また、インターネットのショッピング・モールがこのサービスを提供する場合、支払いはモール内の加盟店に限定される。

より一般的には図２８に示したように、シリアル番号の上位ビットで電子財布のユーザーレベルを設定しても良い。すなわち、レベル１の電子財布には、上位４ビットが"0001"のシリアル番号が与えられる。例えば、ユーザー公開鍵に公開鍵証明書が公開されていれば、レベル１の電子財布となる。同様に、レベル２、３、４のユーザーには、夫々上位４ビットが"001*"、"01**"および"1***"のシリアル番号が与えられる。ここで、"*"は０または１である。上位４ビットが"0000"のシリアル番号は、未使用または予約番号である。

例えば、電子財布と関連づけて所有者の個人情報が登録されていれば、レベル２の電子財布となる。また、クレジットカード決済など、購入者の情報が存在する場合は、レベル３の電子財布となる。その他の、匿名の電子財布は、レベル４の電子財布となる。夫々のレベルに、残高の上限を定めても良い。図２８では、各レベルでの移動可能な電子マネーの最大額の大きさを相対的に示している。すなわち、レベル１同士では無制限に移動可能であり、レベル４同士では移動不可となっている。また、図で、＜Ｌ、＜Ｍ、＜Ｓの順に移動可能な電子マネーの最大額が小さくなっている。図６に示した電子マネー処理サーバー１の場合、上記制限に従って、発行者サーバー２が不適切な移動リクエストを拒否し、代理署名サーバー３へは転送しない。

この実装では、ブローカーが電子マネーを発行し、その電子マネーを購入した消費者は、加盟店でのみこの電子マネーを利用できる。加盟店は、売上の電子マネーをブローカーから回収する。すなわち、消費者は、支払いを行う加盟店を指定して、自身の電子財布から電子マネーに署名をして、この署名された電子マネー（出金額証明書）をブローカーのサーバーへ送信する。これにより電子財布の残高は減少するが、電子マネーはどこにも移動しない。

図２９に、この例の電子財布構造体を示す。ここでは、図８の電子財布構造体に加えて、支払先IDとしてpayee_id、最後に支払った電子マネーの額を示す支払額payment_amountおよび、支払の行われた日時payment_timeが加わっている。ショップへの支払いを行う消費者に対して、ブローカーサーバーは、図３０に示したような支払いプロトコルに従って通信を行う。ブローカーサーバーと消費者との間には、ショップのサーバーが介在する。消費者はショップサーバーへデータを送信し、ショップサーバーはそれを確認してブローカーサーバーへ転送する。また、ブローカーサーバーはショップサーバーへデータを返し、ショップサーバーは、それを確認して消費者へ転送する。ただし消費者は、電子マネーの購入は上記例と同じ方法で、ブローカーサーバーと直接通信により行うことができる。

先ず、電子マネーによる支払いを希望するユーザーは、消費者端末を介して、支払元電子財布のシリアル番号s1、支払先id、支払日時となる現在時刻tc、出金額w1、支払額ｖと共に、支払いリクエストを送信する(U1)。ブローカーサーバーは、この支払いリクエストを受信すると(S1)、受理可能か否かを確認する(S2)。受理可能であれば、ブローカーサーバー内のデータベースの電子財布s1のレコードに対して、排他ロックを設定し、支払いリクエスト受理通知を消費者へ送信し(S3)、消費者からの署名値の受信を待つ。

一方、支払いリクエストが受理できない場合には、その旨の通知が行われる(S4)。例えば、受信した出金額w1が、ブローカーサーバー内のデータベースのレコードと矛盾していた場合には、この支払いリクエストは不受理となる。

そして、不受理通知と共に、その理由が通知される。提示された出金額w1がブローカーサーバー内のデータベースの記録よりも小さい場合には、正しい出金額w1と共に証拠として記録されているユーザー署名が消費者へ送信される。不受理の場合は(U2、NO)、消費者にはその表示が行われる(U3)。

支払いリクエスト受理通知があれば(U2、YES)、消費者は、ユーザー秘密鍵p1を用いて、s1、ユーザー公開鍵n1、発行日時t1、id、v、支払日時としての現在時刻tc、w1+vを連結して得た平文データを作成する(U4)。そして、消費者は、この平文データに署名して、SigU1としてのユーザー署名{s1, n1, t1, id, v, tc, w1+v}p1を生成する(U4)。なお、この連結は、上記の通りビット列として単純に連結する。このユーザー署名SigU1は、上記平文と共に、出金額証明書としてブローカーサーバーへ送信する(U5)。

署名値SigU1を、所定時間内に受信しないと(S5、NO)、ブローカーサーバーは処理を終了する。署名値SigU1を受信すると(S5、YES)、ブローカーサーバーはn1を用いて、平文{s1, n1, t1, id, v, tc, w1+v}に対する署名SigU1の検証を行う(S6)。検証が失敗すれば(S7、NO)、理由と共に不受理の通知を行い、処理を終了する。不受理の通知を受けた消費者は(U6、YES)、不受理の表示を行い処理を終了する。

検証が成功すれば(S7、YES)、電子財布s1のデータを更新する(S8)。すなわち、電子財布s1の支払先、支払日時、支払額、出金額w1およびユーザー署名を、id、v、tc、w1+vおよびSigU1に更新する。また、ブローカーサーバーで管理している支払先idに対応する売上データを更新する(S9)。最後に、支払い完了通知を消費者へ送信して(S10)、処理を終了する。消費者は、支払い完了通知を受信して(U7)、処理を終了する。

ショップサーバーは、上記出金額証明書を保持しているので、売上の証明となる。決済はショップサーバーの保持している出金額証明書に基づいて、例えば月末〆などで既存の方法で行われる。また、ブローカーサーバー側でも同様に、出金額証明書は消費者が行った電子マネーの消費額の証明となる。事後トラブルに関しては、ショップとブローカー間は従来の信頼関係で成り立っているが、上記の通り消費者とブローカー（ショップ）間にはそのような信頼関係は不要である。いずれにせよ、この場合ブローカーサーバー側では、取引毎の署名は不要となり、サーバー側の負荷が小さく抑えられる。

電子マネーの移動において、シリアル番号を手作業で入力する場合もあり得る。通常の銀行振込では振込先の氏名を照合することで、間違った口座番号による誤送金が防止されている。ここでは、シリアル番号で移動を行うので、入力誤り検出処理を設けることが望ましい。

次の様にシリアル番号を拡張すれば、誤移動の確率を大幅に小さくすることができる。すなわち、１６進法の上記シリアル番号の最下位に更に１６ビットの誤り検出用の符号（0〜Fの一文字）を追加して、電子財布番号として利用する。この１６進数は、追加後の各桁の数字（0〜F）の総和をSUM(si)として、次の式が成り立つ様に決定する。
SUM(si) mod16=０

例えば、シリアル番号がf549802では、f+5+4+9+8+0+2+5=16d*3なので、f5498025を電子財布を特定する為の電子財布番号として利用するものとする。ユーザー同士では、シリアル番号ではなく電子財布番号でやりとりを行う様にする。

従って、電子マネーの移動において、ユーザーはシリアル番号ではなくこの電子財布番号を、相手の電子財布を特定する番号として自身の端末へ入力する。端末では、電子財布番号の各文字を数値化してSUM(si)&0xfを計算し、０でなければ指定された番号が誤りであることを表示して、再度入力を促す。０なら、最下位の一文字を削除してシリアル番号を取り出し、上記の処理を行う。

このようにすることで、シリアル番号を手作業で入力する場合であっても、入力ミスによる誤移動の可能性は非常に低くなる。例えば、誤り入力が一文字の場合は、すべてエラーとなる。また、二文字以上の誤り入力があった場合でも、エラーとならない確率は概ね1/16である。

図３１に示したように、電子財布構造体に、メッセージを格納するメンバー"message"を追加しても良い。すなわち、支払元が、移動リクエストに添付されたメッセージ（ここでは、最大16バイト）は、代理署名サーバーによって支払先の電子財布の"message"に格納される。この"message"は、少なくとも代理署名サーバーのレコードには保存される。このメンバーは、代理署名を行う平文へ加えられる。従って、代理署名によって、このメッセージが支払元によって書き込まれたものであることが証明されている。

協調して動作する代理署名サーバーを複数設けることも考えられる。複数の代理署名サーバーは、負荷を分散させることができる。更に、システム更新（鍵ペア等）をスムーズに行う為に、新たな電子財布は、更新された鍵を用いて、より新しい代理署名サーバーで発行することによりシステム更新（鍵ペア等）をスムーズに行うことが可能となる。また、全ての電子財布の有効期限が切れた代理署名サーバーはリセットする。或いは、電子マネーの移動が、別の運用者による２つの実装の間で行われるかもしれない。いずれにせよ、シリアル番号の上位ビットで代理署名サーバーを区別することができる。

或る代理署名サーバーで管理している電子財布から、別の代理署名サーバーで管理している電子財布への電子マネーの移動は、例えば、次のようにして行うことができる。

図３２で、ユーザーAは、代理署名サーバーAで管理している電子財布UAから、代理署名サーバーBで管理しているユーザーBの電子財布UBへ、電子マネーの移動を行いたいとする。先ず、ユーザーAは、移動リクエストUAー＞UBを発行者サーバーへ送信する。発行者サーバーは、代理署名サーバーAで管理している電子財布SAと、代理署名サーバーBで管理している電子財布SBを所有している。発行者サーバーは、代理署名サーバーBにおいて電子マネーの発行を行っている。すなわち、電子財布SBは、発行者用の特別な電子財布である。電子財布UAは、通常の電子財布であっても、発行者用の特別な電子財布であっても良い。電子財布UAが通常の電子財布である場合、この発行者サーバーは代理署名サーバーAとは無関係であり、代理署名サーバーAには別の発行者が存在する。

発行者サーバーは、移動リクエストUAー＞UBを、２つの移動リクエストUA - ＞SAとSB - ＞UBに変換して、代理署名サーバー3Aと代理署名サーバー3Bへ送信する。そして、代理署名サーバー3Aと代理署名サーバー3Bから、移動証明書UA - ＞SAとSB - ＞UBとを受信する。

この場合、移動証明書UA - ＞SAとSB - ＞UBは、２つの移動証明書の受領日時がほぼ一致しているので、間接的ではあるが、移動UAー＞UBをも示している。電子財布構造体で上記メンバー"message"を利用可能であれば、移動ＩＤを移動証明書UA - ＞SAとSB - ＞UBの双方に書き入れることで、移動UAー＞UBを厳密に証明できる。

従って、移動証明書UA - ＞SAとSB - ＞UBをユーザーAへ送信し、ユーザーAはそれらをユーザーBへ送信する。移動元が発行者であるSB - ＞UBの移動には手数料が発生しないとすれば、２つの代理署名サーバーを跨る電子マネーの移動でも、同一代理署名サーバー内の移動と手数料は同じである。また、シリアル番号を１６進法の８桁表記とした場合、例えば、最上位の一桁で代理署名サーバーを区別すれば、電子財布を一律にシリアル番号で管理できる。

実施例１では、取引毎に、処理量の大きい電子署名の生成や検証が必要となる。負荷の低減方法としては、署名や検証の処理を高速な専用ハードウエアを複数設けて並列処理を行うことが考えられる。

また、電子署名のアルゴリズムとして、ECDSAといった楕円曲線暗号を利用することで電子署名の生成を高速化することも考えられる。

以下、図８に示した電子財布構造体を用いた電子マネーの移動方法を説明する。ここでは、ユーザーがオンラインショップで買い物をし、電子マネーで支払いを行うものとする。勿論、この方法は一般的な電子マネーの移動に応用出来る。

オンラインショップでの支払いに電子マネーを指定した場合、ユーザーは移動元電子財布のシリアル番号、出金額w1、移動額v、移動手数料fを、オンラインショップへ送信する。オンラインショップは、それらの情報を受信し、移動先電子財布の情報と共に、移動リクエストを代理署名サーバーへ送信する。移動リクエストが受理可能ならば、代理署名サーバーは、移動リクエスト受理通知をオンラインショップへ返す。オンラインショップは、この受理通知をユーザーへ転送する。ユーザーは、出金額証明書をオンラインショップへ送信する。オンラインショップは、この出金額証明書を、代理署名サーバーへ転送する。代理署名サーバーは、出金額証明書を確認して、入金額証明書をオンラインショップへ返す。オンラインショップは、入金額証明書を確認して、商品の引渡しを行う。

言うまでもなく、この支払い方法は、図７に示した電子財布構造体を用いた代理署名サーバーであっても利用できる。従って、オンラインショップは、このような方法と上記［電子財布の利用］で説明した方法のいずれかを選択できる。

実施例1では、電子マネーの移動毎に、代理署名サーバーにおいて電子署名を行うので負荷が大きい。この実施例では、電子財布の生成の際にのみ電子署名を行い、電子財布間の電子マネーの移動は、ハッシュ計算だけで完了することができる。

実施例2の詳細を記述する前に、ハッシュ関数とハッシュ連鎖についての説明を行っておく。ここでハッシュ関数とは、暗号処理で用いられている一方向性関数と考えられる関数をいう。具体例としては、MD2、MD4、MD5、SHA、SHA-2や、現在開発中の安全性の向上したSHA-3などがある。

また、ハッシュ連鎖とは、次のようにして生成されるハッシュの列を言う。まず、乱数Rを生成し、この乱数Rをハッシュ関数h()に代入して計算結果(ハッシュ)を得る。そして、この計算結果を同じハッシュ関数h()に代入し次の計算結果を得る、といった処理を再帰的に所定回数nだけ繰り返し、n個の計算結果の数列を得る。そして、最後の計算結果のインデックスが0であり、最初の計算結果のインデックスが(nー1)であるように、この数列にインデックスを割り振り、インデックスnの要素として乱数Rを加える。こうしてインデックスkが割り当てられたハッシュ連鎖h(k)が生成される。
h(k) = h^n-k(R)
(ただし、k = 0 to n、h⁰(R) = R）

ハッシュ連鎖の特徴は、一方向性である。つまり、h(i)が分かればj＜iとしてh(j)は容易に計算できる。しかし、k＞iとしてh(k)の計算は困難である。h(0)をルート・ハッシュと呼ぶ。また、h(n)を原ハッシュと呼ぶこととする。関連するハッシュ連鎖がm個あった場合、纏めてハッシュ連鎖ベクトルと呼ぶ。

以下に説明する実装例において、各記号は以下のような意味を持つものとする。

ｉ）大文字から始まる記号はベクトルまたはスカラーを表す。つまり、ベクトルとして解釈しても良いし、スカラーとして解釈しても良い。ベクトルの各要素は下付文字で区別する。スカラーの場合の和、差、積は、通常の和、差、積である。

ii）小文字の記号または小文字から始まる記号は常にスカラー、すなわち単独の数値を表す。

iii）二つのベクトルA、Bの和A+Bは、通常のベクトル和を表す。すなわち、ベクトルの次元をmとして、A=(A₁, A₂, ..., A_m-1, A_m)、B=(B₁, B₂, ...B_m-1, B_m)として、A+B=(A₁+B₁, A₂+B₂, ..., A_m-1+B_m-1, ..., A_m+B_m)となる。

iv）二つのベクトルA、Bの差AーBは、通常のベクトル差を表す。すなわち、A - B=(A₁ - B₁, A₂ - B₂, ..., A_m-1 - B_m-1, ..., A_m - B_m) となる。

v）二つのベクトルA、Bの積A×Bは、内積を表す。すなわち、A * B=SUM(A_kB_k)となる。ここでSUM()はkが1からmまでの総和である。

vi）A(k)をインデックスkの付けられたベクトル連鎖とした場合、すなわち、各要素A_i(k)をインデックスkの付けられたハッシュ連鎖とした場合、インデックスをベクトルXとして、ベクトルA(X)を次のように定義する。

A(X)₁=A(X₁)₁
A(X)₂=A(X₂)₂
...
A(X)_m-1=A(X_m-1)_m-1
A(X)_m=A(X_m)_m

ただし、A(0)は、夫々のハッシュ連鎖のルートハッシュからなるものと定義する。

電子財布s：シリアル番号sが割り振られた電子財布
Hw(s)：電子財布sから電子マネーの出金を行うためのハッシュ連鎖である出金ハッシュ連鎖ベクトル
Hd(s)：電子財布sへ電子マネーの入金を行うためのハッシュ連鎖である入金ハッシュ連鎖ベクトル
Xw(s)：Hw(s)の各ハッシュ連鎖における使用済のハッシュの末尾の位置を示すインデックスベクトルである出金インデックスベクトル
Xd(s)：Hd(s)の各ハッシュ連鎖における使用済のハッシュの末尾の位置を示すインデックスベクトルである入金インデックスベクトル
Ww(s)：Xw(s) * Ww(s)により累計出金額を算出する為の重みである出金ウエイトベクトル
Wd(s)：Xd(s) * Wd(s)により累計入金額を算出する為の重みである入金ウエイトベクトル
Lw(s)：出金ハッシュ連鎖ベクトルHw(s)の長さであるハッシュ連鎖長ベクトル
Ld(s)：入金ハッシュ連鎖ベクトルHd(s)の長さであるハッシュ連鎖長ベクトル

ここでは、電子財布sを生成する場合、Hw(s)の一つのハッシュについて、最初のインデックスを0として、最後のインデックスがnとすると、nはこのハッシュ連鎖の長さである。Hw(s)やHd(s)に含まれるハッシュ連鎖の長さは、自由に設定できる。一方、電子財布sを生成する場合、通常、入金インデックスベクトルXd(s)の初期値の少なくとも一つの要素は、電子財布sの残高の初期値によって0以上の値となる。

また、Ww(s)、Wd(s)、Lw(s)やLd(s)は、一般には電子財布毎に異なる値でも良いが、説明をわかりやすくする為に、以下の例ではシリアル番号に依存しないWw、Wd、LwおよびLdを共通の値として採用する。シリアル番号に依存する場合には、Ww(s)、Wd(s)、Lw(s)やLd(s)は電子財布構造体のメンバーに含まれる。

実施例2の電子財布構造体は、図３３のように定義される。すなわち、電子財布構造体は、当該電子財布の識別番号としてのシリアル番号s(32ビット整数)と、電子財布の発行日時issue_time(32ビット整数)と、Xd(s)であるdeposit[m1](32ビット整数×m1)と、Xw(s)であるwithdraw[m2](32ビット整数×m2)と、ベクトルHd(s, Xd(s))である"deposit_hash[m1]"(256ビット整数×m1)と、ベクトルHw(s, Xw(s))である"withdraw_hash[m2]"(256ビット整数×m2)と、仲介署名"signature"(2048ビット整数)とからなっている。m1とm2は自然数であり、同じでも異なっていても良く、入金ハッシュ連鎖および出金ハッシュ連鎖のベクトルの次元となっている。

また、図３３では、256ビット整数の型をbigint2として示しているが、プログラム内部では、一般にプリミティブ型整数の配列で処理される。

この電子財布構造体の各インスタンスは、対応する電子財布のユーザーと、上記代理署名サーバーに対応する仲介サーバーが保持する。仲介署名は、電子財布のインスタンスを生成する際に作成されるものであり、シリアル番号s、発行日時、入金ハッシュ連鎖ベクトルのルートハッシュHd(0)および出金ハッシュ連鎖ベクトルのルートハッシュHw(0)をビット列として連結したデータを、SHA-256のハッシュ関数で処理したハッシュに対して作成される。

なお、ここで説明する実施例では、誤解のない場合には、シリアル番号の表示を適宜省略する。従って、電子財布の残高は対応する構造体の要素の値から、以下の式で算出される。この値は常に正でなければならない。
Xd＊Wd - Xw＊Wｗ

未開示出金ハッシュは、その電子財布の所有者が生成し、自己責任で秘匿する。また、未開示入金ハッシュは、仲介サーバーが生成し、自己責任で秘匿する。移動元ユーザーは、未開示出金ハッシュの各値を、電子コインとして仲介サーバーへ送信する。仲介サーバーはその電子コインを使用済み証拠として保存し、代わりに対応する額の入金ハッシュを電子コインとして、移動先ユーザーへ送信する。

入金および出金ハッシュ連鎖の原ハッシュは、電子財布関連データであるが、電子財布構造体のメンバーではない。その理由は、原ハッシュは電子財布構造体とユニークに対応するからであり、電子財布構造体は電子財布の現在の状態を表す完結したデータとなっているからであり、原ハッシュは電子財布を使用するためのデバイスとしてのみ機能するからである。後述の例では、一つの秘密鍵からすべての入金ハッシュが算出され、ハッシュの為の特別なデータは不要である。しかし、仲介サーバーで電子財布を生成する毎に、入金ハッシュを計算する為の乱数を生成してもよい。この場合、この乱数ハッシュ、夫々の電子財布に対応して電子財布構造体のインスタンスと共に保存する必要がある。

電子財布構造体の仕様の具体例は次の通りである。出金ハッシュ連鎖のハッシュ数は３であり、ハッシュ連鎖長ベクトルLwは(200, 100, 50)である。入金ハッシュ連鎖の要素の数は３であり、ハッシュ連鎖長ベクトルLdは(200, 100, 50)である。単位を円として、出金ウエイトベクトルWwは(10, 100, 1000)であり、入金ウエイトベクトルWwは(10, 100, 1000)である。この場合、5, 000円の電子マネーの格納された電子財布の生成では、入金インデックスの初期値は、例えば(0, 0, 5)や(50, 15, 3)等と選択できる。

また、ハッシュ連鎖のハッシュアルゴリズムはSHA-256であり、仲介署名の署名アルゴリズムはSHA256WithRSAEncryptionである。電子財布の有効期限は、例えば、その発行日時から一年と定められる。

上記仕様は、ＣＡの公開鍵証明書と共にダウンロード可能となっている運用者の証明書に記載されている。いずれにせよ、実施例１と同様に、ユーザーは電子マネーの有効性を所有するデータのみから立証できるような構成となっている。

ここでも、ユーザーと仲介サーバー間の通信は、一つのＳＳＬセッションの中で完結する。しかし、サーバー認証のみが行われ、ＳＳＬによるクライアント認証は行われない。

仲介サーバーは、ユーザーからのリクエストに従って、電子財布を生成する。それには、先ずユーザーから入金インデックスベクトルの初期値Xd(s)と、出金ハッシュ連鎖のルートハッシュベクトルHw(0)を受け取る。そして、シリアル番号sを決定し、入金ハッシュ連鎖のルートハッシュベクトルを生成する。

仲介サーバーは、秘密鍵piを用いて、これらシリアル番号s、発行日時としての現在時刻、ルートハッシュHd(s, 0)、受けたHw(0)であるルートハッシュHw(s, 0)に対して署名を行って仲介署名{s, t, Hd(s, 0), Hw(s, 0)}psを作成する。更に、受けたXd(s)に従って、Hd(s, Xd(s))を算出する。ここで、電子財布に格納する電子マネーの額vは、v=Xd(s) * Wdで計算される。

そして、シリアル番号s、仲介署名およびHd(s, Xd(s))を、ユーザーへ送信する。ユーザーは、これらのデータを用いて電子財布構造体のインスタンスを構成できる。また、仲介サーバー側のデータベースでは、生成した電子財布構造体のインスタンスにおいて、出金インデックスベクトルXw(s)の各要素を０で初期化し、その他のメンバーに上記値を代入する。

仲介サーバーが受信する移動リクエストには、移動元の電子財布のシリアル番号s1、Xw(s1)、Xd(s1)、Xw(s1)の増分Dw(s1)、Xd(s1)の増分Dd(s1)、移動先の電子財布のシリアル番号s2、Xw(s2)、Xd(s2)、Xw(s2)の増分Dw(s2)、Xd(s2)の増分Dd(s2)が含まれている。

また、電子マネー移動には、例えば移動額の一定割合といった所定の手数料fがかかるものとする。または、手数料fを、仲介サーバーに要求される計算量に応じて算出されるようにしても良い。

まず、ユーザーから移動リクエストが仲介サーバーへ送信される。受信した移動リクエストに対して、仲介サーバーは、以下の条件が満たされていれば、この移動リクエストを受理する。

１）Xw(s1)、Xd(s1)、Xw(s2)およびXd(s2)が、仲介サーバーの記録と整合すること。
２）Xd(s1)+Dd(s1)とXd(s2)+Dd(s2)のいずれもLdを超えず、また、Xw(s1)+Dw(s1)とXw(s2)+Dw(s2)のいずれもLwを超えないこと。
３）(Xd(s1)+Dd(s1)) * Wd - (Xw(s1)+Dw(s1)) * Ww＞０
４）(Xd(s2)+Dd(s2)) * Wd - (Xw(s2)+Dw(s2)) * Ww＞０
５）Dw(s1) * Ww - Dd(s1) * Wd=Dd(s2) * Wd - Dw(s2) * Ww+ｆ

もし、上記条件のいずれかが満たされていなければ、仲介サーバーは、その理由と共に拒否メッセージを返して処理を終了する。例えば、Xw(s1)に仲介サーバーの記録よりも小さい要素があれば、すなわち、既に使用済みハッシュの使用が要求されていれば、仲介サーバーは既に受けていたそのハッシュをユーザーへ返す。

移動リクエストの受理通知を受けると、ユーザーは、Hw(s1, Xw(s1)+Dw(s1))および Hw(s2, Xw(s2)+Dw(s2))を仲介サーバーへ送信する。仲介サーバーは、受信したハッシュを検証し、正しくないハッシュが含まれていれば拒否通知を返し、正しければHd(s1, Xd(s1)+Dd(s1))およびHd(s2, Xd(s2)+Dd(s2))を返す。すなわち、出金ハッシュによってクライアント認証を行っている。仲介サーバーとユーザーは、処理結果に従って、電子財布s1およびs2の構造体インスタンスを更新する。すなわち、Xd(s1)、Xw(s1)、Hd(s1, Xd(s1))、Hw(s1, Xw(s1))を、夫々、Xd(s1)+Dd(s1)、Xw(s1)+ Dw(s1)、Hd(s1, Xd(s1)+Dd(s1))、Hw(s1, Xw(s1)+Dw(s1))に更新し、Xd(s2)、Xw(s2)、Hd(s2, Xd(s2))、Hw(s2, Xw(s2))を、夫々、Xd(s2)+Dd(s2)、Xw(s2)+ Dw(s2)、Hd(s2, Xd(s2)+Dd(s2))、Hw(s2, Xw(s2)+Dw(s2))に更新する。

実施例１とは異なり、実施例２では移動証明書が利用できない。従って、電子マネー移動の手続きは、実施例１とは若干異なる。以下、図３４を参照して、オンラインショップでの支払例を説明する。

支払い金額v（移動額）が決定したら、ステップi)でユーザーは、移動元情報として、自分の電子財布のシリアル番号s1、Xw(s1)、Xd(s1)、出金インデックスベクトルXw(s1)の増分Dw(s1)、入金インデックスベクトルXd(s1)の増分Dd(s1)をオンラインショップのサーバーへ送信する。ここで、v = Dw(s1) * Ww - Dd(s1) * Wd - fである。

オンラインショップでは、ステップii)で、これらの情報に加えて、オンラインショップ側の電子財布のシリアル番号s2、出金インデックスベクトルXw(s2)、入金インデックスベクトルXd(s2)、出金インデックスベクトルXw(s2)の増分Dw(s2)、入金インデックスベクトルXd(s2)の増分Dd(s2)を、電子マネーの移動リクエストとして仲介サーバーへ送信する。ここで、v=Dd(s2) * Wd - Dw(s2) * Wwである。

仲介サーバーは、上記の通りのプロトコルに従って、送信された移動リクエストの内容をチェックし問題がなければ、ステップiii)でリクエスト受理メッセージACKを返す。また、オンラインショップでも、ステップiv)で受理メッセージACKをユーザーへ返す。

それに対してユーザーは、ステップv)で支払いの為のHw(s1、(Xw(s1)+Dw(s1))をオンラインショップへ送信する。オンラインショップは、受けたハッシュを、Hw(s2、(Xw(s2)+Dw(s2))と共に、ステップvi)で仲介サーバーへ送信する。

仲介サーバーは、送信された出金ハッシュをチェックし問題がなければ、ステップvii)でHd(s1, Hd(s1)+Dd(s1))およびHd(s2, Hd(s2)+Dd(s2))を返すことで電子マネーの移動を行い、電子財布の記録を更新しておく。また、オンラインショップでも、ステップviii)でHd(s1, Hd(s1)+Dd(s1))をユーザーへお釣りとして返す。

実施例１と同様に、リアル店舗で電子マネーの利用することができる。まず、必要なアプリと共に携帯電話に電子財布をインストールしておく。紛失や盗難などに備えてセキュリティを高める場合には、原ハッシュは携帯電話に保存せずにQRコードで紙に打ち出して本当の財布に入れておき、必要に応じて携帯電話のカメラで取り込むようにしても良い。この場合、多額の電子マネーが電子財布に入っているなら、必要な額のハッシュを打ち出して、一部の電子マネーだけを持ち歩くことができる。

ユーザーは商品に付けられたQRコード等により、又は直接入力によって支払金額を携帯電話に入力する。その支払金額に対応する出金ハッシュを計算して、店舗ＩＤおよびシリアル番号と共に、電子マネーとして店舗のサーバーへ送信する。送信を受けた店舗サーバーは、その電子マネーを自身の電子財布へ移動する。移動が成功すれば、支払い番号をユーザーおよび店舗へ返す。

従って、レジで計算した後、ユーザーは、現金で支払う代わりに支払い番号を口頭で伝えるだけで良い。より正確には、シリアル番号で支払者を確認することもできる。また、万一、計算間違いがあれば、現金で清算すれば良い。

図３５は、本実施例の仲介サーバーで使用するカスタマイズされたセキュリティー・チップ(TPM: Trusted Platform Module)を示す概略図である。このチップには乱数生成器が設けられており、内部で秘密鍵が生成保管される。この秘密鍵を用いて、チップ内部で上記仲介署名が行われる。

このチップの特徴点は、一般的なセキュリティー・チップと異なるのは、秘密鍵をMACユニットの入力の一部として利用する点にある。一般的にMACユニットでは、メッセージと鍵を入力とし、タグ(MAC: Message Authentication Code)を出力する。メッセージや鍵が1ビットでも異なると、全く異なるタグが出力される。

ここでは、MACユニットは、電子財布のシリアル番号sと、入金ハッシュ連鎖ベクトルの要素Hd_i(s)の序数ｉ（例えば、上記3本の入金ハッシュの場合では、入金ウエイトが10のハッシュ連鎖の序数は0、10のハッシュ連鎖の序数は1、100のハッシュ連鎖の序数は2）を鍵として受け取る。以下、この序数を連鎖番号と呼ぶ。一方、秘密鍵がメッセージとして入力される。

まず、電子財布の生成要求を受けた場合、入金ルートハッシュが準備される。すなわち、シリアル番号sと連鎖番号0を、秘密鍵と共に図３５のMACユニットに入力して、出力されたタグを、このシリアル番号sに対応する0番目の入金ハッシュ連鎖のn番目(n:ハッシュ長)のハッシュ、すなわち原ハッシュとする。このハッシュの値を再帰的にn回ハッシュ関数で処理すれば、0番目の入金ハッシュ連鎖のルート・ハッシュが得られる。同じ処理を連鎖番号をインクリメントして繰り返し行えば、入金ハッシュ連鎖ベクトルHd(s)全体のルート・ハッシュが得られることになる。

入金インデックスの初期値と、計算された入金ハッシュの初期値と、シリアル番号と、ユーザーから受信した出金ルート・ハッシュを含む電子財布の情報を作成し、上記秘密鍵によって署名することにより仲介サーバーの証明書が作成される。このような方法で、仲介サーバー側では、全ての電子財布の入金ハッシュに関する秘匿情報を、一つの秘密鍵に縮約することができる。

シリアル番号sの電子財布のi番目の入金ハッシュ連鎖のk番目の要素、すなわちHd_i(s, k)が必要である場合、この値は次のようにして計算される。すなわち、図３５のチップにシリアル番号sと連鎖番号iを入力して、内部でMACユニットから出力されたタグを、再帰的に必要回数つまりｎ - ｋ回ハッシュ関数で処理すればよい。このようなシステムでは、仲介サーバー側で、秘密情報である入金ハッシュに関する情報を管理する必要がないという利点に加え、チップでハッシュ計算を行うので、サーバーへの負荷が緩和されるという利点もある。

図３６に、MACユニットの内部構造の一例を示す。これはMAC計算回路のよく知られた実装例であり、HMAC(Keyed-Hashing for Message Authentication code)を出力する。ここでは、シリアル番号sと連鎖番号iを連結し、更に秘密鍵の一部(上位480ビット)をパディングビットとして連結し、全体で512ビットの鍵としている。そして、この512ビットの鍵と共に、秘密鍵をメッセージとして用いてHMAC処理を行っている。図３６で、ipadおよびopadは、バイト"0x36"および"0x5C"を夫々64個並べたビット列である。この512ビットの鍵をKとし、秘密鍵をPrivateKeyとして、HMACはよく知られた下記の計算式で求められる。ここで、SHA-1はハッシュ関数である。
HMAC = SHA-1(K XOR opad, SHA-1(K XOR ipad, PrivateKey)）

なお、シリアル番号sと連鎖番号iと秘密鍵から、MAC生成のための鍵とメッセージを生成する方法は、色々考えられる。また、上記処理は、カスタマイズされたＴＰＭを用いなくとも、ソフトウエアによっても実装できる。

この場合、仲介サーバー側の、各ユーザーのレコードは図３７に示したような構造体のインスタンスとして管理される。図３７の構造体では、Hd(s, Xd(s))である"deposit_hash[]"が含まれていない。これは、もし必要があれば、上記原ハッシュと、Xd(s)である"deposit[]"から算出できる。また、図３７の構造体では、仲介署名が含まれていない。これは、もし必要があれば、他のフィールドの値から算出できる。

ユーザー側のクライアント・システムは、通常のPCや携帯電話等、任意のハードウエアに実装できる。ここでは、PCのソフトウエアユニットとして実装する。

このクライアント・システムでは、電子財布の生成にあたって、ルート・ハッシュを計算しなければならない。それには、まず乱数生成器で乱数を生成する。この実施例では、全ハッシュの元データとなる一つの256ビットの乱数を生成する。この元データを、電子財布の指定ハッシュ関数(ここではSHAー256)とは別のハッシュ関数(ここではHAVALとしておく)によって繰り返し処理する。

すなわち、元データを出金ハッシュ連鎖の数だけHAVALで繰り返し処理し、出金ハッシュ連鎖の原ハッシュHw(s, Lw(s))を計算する。この原ハッシュHw(s, Lw(s)) の各々をLw(s)回SHAー256で処理し、ルート・ハッシュを得る(図３８)。このようにすることで、ユーザー側でも、出金ハッシュ連鎖に関するすべての秘匿情報が256ビットの元データに集約される。この場合、ユーザー側の電子財布レコードは図３９に示したような構造体のインスタンスとして管理される。図３９の構造体では、Hw(s, Xw(s))である"withdraw_hash[]"が含まれていない。これは、もし必要があれば、上記原ハッシュと、Xw(s)である"withdraw[]"から算出できる。

出金ハッシュ連鎖の数が大きい場合、HAVALの計算量が大きくなる。元データにiを加算してからHAVALで処理することで、i番目の入金ハッシュ連鎖の末尾のハッシュHw_i(s, Lw(s))を計算してもよい。または、出金ハッシュ連鎖の数がハッシュ長以下であれば、元データをiビットだけローテーションさせてからHAVALで処理することで、i番目の入金ハッシュ連鎖の末尾のハッシュHw_i(s, Lw(s))を計算してもよい。更に、一人のユーザーが、インデックスとして連続番号の付された複数の電子財布を使用することもあり得る。例えば、このインデックスは０から始まる電子財布番号であり、上記元データは、各電子財布について単一の256ビット共通元データに電子財布番号の0x1000倍を加えることで計算される。これにより、すべての電子財布に関する秘匿情報が256ビットの共通元データに集約される。

実施例2は電子コイン型の電子マネーなので、取引を繰り返すと、電子財布のハッシュが枯渇する。ハッシュ長を大きくすれば、これを改善することができる。しかし、ハッシュ計算の回数が増えれば、計算量が少ないという実施例2の特徴が損なわれる。

ハッシュ連鎖ベクトルの次元(ハッシュ連鎖の数)を大きくすれば、計算量を抑えると共に、電子財布の容量を増やすことができる。例えば、256次元に増やす(m1=m2=256)。この場合でも、上記の通り、仲介サーバーでの秘匿情報は秘密鍵のみである。また、各ユーザーの秘匿情報は256ビットの乱数が一つだけである。

仲介サーバーで保存すべき、ユーザー当たりの使用済み出金ハッシュは256×256ビット=65, 536ビット（8,192バイト）となる。各ユーザーでも保存すべき取得済み入金ハッシュは、8192バイトとなる。しかし、、取引毎に更新されるデータは、256ビット（32バイト）のハッシュが高々数個程度である。

ハッシュ連鎖の数を多くしたので、ハッシュ長は短くても問題はない。例えば１６とすると、一本あたりのインデックスは４ビットでよい。この場合、入金と出金共にインデックスベクトルの必要なビット数は4×256ビットで、1024ビット（128バイト）となる。

取引毎に通信が必要なのは、使用するハッシュの連鎖番号と、そのインデックスおよび個数のみなので、インデックスベクトルの全体を送信する必要はない。すなわち、連鎖番号（１バイト）、インデックス（４ビット）および個数（４ビット）の全体で、２バイトの情報で表せる。従って、一回の取引当たり、使用するハッシュ連鎖毎に34バイト程度の情報を送信すれば良いことになる。

256本の内訳の例としては、例えば、10円ないし1, 000円迄は10円刻みで100本、1, 100円ないし10, 000円迄は100円刻みで90本、11, 000円ないし76, 000円は1, 000円刻みで66本といった方法がある。この場合、ハッシュ長さを１６として、一つの電子財布で入出金合わせて最大約一億円の移動が可能となる。このようにすることで、計算量を抑えつつ、残高管理型の電子マネーに近い使い勝手が実現する。

上記例では、お釣りとして、移動元電子財布へ入金ハッシュが渡され、移動先電子財布から出金ハッシュが送信される。これは、910円を支払うのに、1, 010円を払って、100円のお釣りをもらうのと同じであり、電子財布のハッシュの消費を抑える為である。

しかし、入金ハッシュの計算は、仲介サーバーへの負荷を増大させる。仲介サーバー側でのハッシュ計算の量に応じた移動手数料を設定すれば、ユーザー側の協力を受けることができる。

上記システムから、入金ハッシュを省略しても良い。例えば、ショッピングモールのサーバーが仲介サーバーとなり、出金ハッシュでの支払いを受け付ける。この場合、プリペイド式の電子マネーとなるが、サーバー側では使用済みの証拠が残り、ユーザー側では出金ハッシュといったデータのみで、電子マネーの所有権を証明できる。従って、銀行が発行し利用者に渡った紙幣そのものの保管責任から開放されるのと同様に、電子マネーの発行者は、発行し利用者に渡った電子マネーそのものを保管し守る責任から開放される。

この場合、電子財布構造体は、図４０のように定義される。新たな電子財布への入金額は、要素initial_depositに初期値が設定され、出金ハッシュの消費に伴なって単純に減少する。仲介サーバー側の、各ユーザーのレコードは図４１に示したような構造体のインスタンスとして管理される。また、ユーザー側の電子財布レコードは図４２に示したような構造体のインスタンスとして管理される。

以上述べたように、本発明のサービス提供方法は、サービス提供者とユーザーとの間の信頼性のある取引に利用できる。

１電子マネー処理サーバー
２発行者サーバー
３代理署名サーバー
４通信ユニット
５記憶装置
６要求処理ユニット
７記憶装置
８ＨＳＭ
９移動処理ユニット
１１通信ユニット
１２署名ユニット
１３検証ユニット
１４暗号鍵生成ユニット
１５ユーザー秘密鍵保存手段
１６電子財布構造体格納手段
１７処理制御ユニット

本発明は、電子マネーの管理方法に関するものであり、特に、インターネットを介した安全性と信頼性の高い電子マネーの管理方法に関する。

Claims

サービス提供者がユーザーに対してサービスを行う方法であって、
ユーザーから提供された第一の情報を、情報受信装置により受信するステップと、
情報処理装置を用いて、前記第一の情報に対してサービス提供者が電子署名を行い、ユーザーへ提供するステップと、
前記第一の情報を特定して行われたリクエストを受け、正当なものであれば、そのリクエストを受諾するステップと、
前記リクエストを受諾した場合、ユーザーから送信された第二の情報を情報受信装置により受信するステップと、
情報処理装置を用いて、前記第一の情報と前記第二の情報が所定の関係を有しているか否かを決定するステップと、
前記第二の情報が所定の関係を有していることが決定された場合に、情報処理装置を用いて、前記サービスの提供に必要な処理を開始するステップと、
前記サービスの提供が行われた後も、その証拠として前記第二の情報を保存するステップとからなり、
前記リクエストと共に受信した情報で特定される第二の情報が既に受信され、対応するサービスが既に提供されている場合、前記リクエストは、正当なものではないと判断され、
現状の情報処理技術によっては、前記第二の情報を得る前に、前記第一の情報と前記所定の関係を有する情報を生成することは、事実上不可能であると考えられているサービス提供方法。