JP5186790B2 - 電子マネー取引方法、及び電子マネーシステム - Google Patents

Description

本発明は、電子マネー取引方法、及び電子マネーシステム、に関し、特に証書型電子マネーの取引方法に関する。

近年、電子マネーを利用した電子商取引が活発化している。電子マネーとは、商取引においてサービスや商品の対価として用いられる通貨や証書としての機能する電子情報である。ここで、通貨とは、例えば現金や商品券、企業が発行するポイント等に相当し、証書とは、割り当てられた金額に応じて価値が変わる小切手等に相当する。電子マネーの発行元（例えば銀行）は、電子署名を施すことで電子情報に電子マネーとしての機能を持たせる。この場合、電子マネーの利用者は、電子マネーの発行元から送られる電子署名を検証することで、取得した電子マネーが正規の電子マネーであるかどうかを確認することができる。

電子マネーはオープンループ型とクローズドループ型とがあるが、個人間の電子商取引が増加に伴い紙幣と同様に取り扱えるオープンループ型の電子マネーの開発要求が高まっている。

電子マネーは、紙幣と同様に、偽造及び変造禁止及び匿名取引等を原則として利用される必要がある。匿名取引とは、送金側（例えばサービス利用者）に関する情報が受取側（例えばサービス提供者）に知られずに電子マネーの送受が行われる取引のことである。従来技術では、ブラインド署名によって電子マネーに匿名性を与えている。

ブラインド署名とは、署名依頼者が、署名者にデータの内容を知られずに署名を受ける技術である。以下、ブラインド署名を利用した電子マネーについて説明する。電子マネーの発行元は、依頼者から乱数による識別番号を含む署名対象データと要求額を受け取り、依頼者の口座から要求額を減じ、署名対象データに対し電子署名を行う。このとき、発行元は、署名対象データの内容を見ずに署名する。依頼者は発行元から電子署名を受取り、これを電子マネーとして利用する。このような電子マネーが、サービス提供者に支払われて利用される場合、サービス提供者は、受け取った電子マネーを公開鍵で検証して利用する。

又、証書として利用される電子マネーは、二重使用が禁止される。このため、証書として発行された電子マネーは、検証センタによって、二重使用がチェックされ、不正送金が防止される。詳細には、証書として発行された電子マネーは、送金側によって金額が指定され、受取側に渡される。ここで、受取側は、当該電子マネーを検証センタ（例えば発行元の銀行）に検証してもらう。検証センタでは、電子マネーの二重使用のチェックが行われる。検証において合格である場合、当該電子マネーに指定された金額が受取側の口座に入金される。又、検証において不合格である場合、入金は拒否される。

上述のようにブラインド署名を利用した場合、発行元（検証センタ）及びサービス提供者は、電子マネーの識別番号を知ることはできない。このため、サービス提供者が電子マネーの二重使用の検証を検証センタに依頼しても、発行した識別番号を利用して使用状況を確認することはできない。そこで、ブラインド署名を利用する場合、検証センタは、使用済みの電子マネーを登録するためのデータベースが設けられ、これを利用して電子マネーの使用状況を確認する。検証センタは、サービス提供者から送られた電子マネーが既にデータベースに登録されている場合、不正送金（二重使用）と判定する。又、電子マネーが未登録である場合、合格とされ、電子マネーに指定された金額がサービス提供者の口座に入金される。

このように、ブラインド署名技術を用いることで、依頼者に関する情報を秘匿可能な電子マネーを実現する。この際、使用済みの電子マネーを登録することで電子マネー利用者による二重使用を防ぐことができる。更に、従来技術として、利用者が、通常では露見しない形で自身の識別情報を含ませた電子マネーを発行元（検証センタ）に送って、電子マネーの利用状況を確認する技術がある。これにより、不正使用を検出した場合、発行者（検証センタ）は、この識別情報を何らかの方法で知ることで不正使用者を特定することができる。

しかし、このような従来技術による電子マネーでは、電子マネーの不正使用を検出するために、使用された電子マネーを全て登録しなければならない。このため、電子マネーの利用が進めば進むほどデータベースに登録される使用済み電子マネーの情報量は増大し、実用的ではない。

又、従来技術では、正規の利用者が電子マネーの利用（決済）を終えていない期間、すなわち電子マネーが使用済みとして登録されていない期間に、不正な方法（例えば複製）で入手した電子マネーが利用（決済）されると、発行元（検証者）は、当該電子マネーを不正使用者の口座へ入金してしまう。このような場合、正規の利用者の電子マネーは決済できなくなる。不正使用者は逃亡する可能性があるため、例え、決済時に通知された識別情報によって不正使用者を特定しても、使用された電子マネーは戻らない場合がある。

更に、従来技術では、電子マネーの送金者は匿名ＩＤを利用して電子マネーを送金する。この場合、送金回数が多くなるとリンカビリティがあるために、送金者の受取者に対する匿名性が失われやすい。例えば、送金時に一度でもユーザ登録を行って個人情報が流出すれば、その後の送金履歴の全てが個人情報とリンクされた状態で受取者に漏洩する危険がある。

ブラインド署名を利用した電子マネーに関する従来技術として、例えば、特開平９−１２８４６５がある（特許文献１参照）。特許文献１に記載の電子現金方法は、信託機関が電子マネーの利用者と公開情報との対応表を秘密に管理し、署名した利用許可証を利用者に発行する。銀行は、その利用許可証にブラインド署名し、電子紙幣（電子マネー）として利用者に発行する。利用者は、小売店にて電子マネーを使用する際、当該電子マネーに金額を指定する。小売店は、電子マネーの決済時、利用者との更新履歴情報を銀行に送り、電子マネーに指定された金額を受領する。

一方、署名者の個人情報を秘匿した署名方法としてグループ署名がある。グループ署名によって署名を検証するサービス提供者は、署名者を特定することなく署名の検証を行うことができる。グループ署名のため暗号技術として、例えば、特表２００５−５１３９５６（特許文献２参照）や、特表２００５−５２５７２１がある（特許文献３参照）。
特開平９−１２８４６５ 特表２００５−５１３９５６ 特表２００５−５２５７２１ Ｇ． Ａｔｅｎｉｅｓｅ， Ｊ． Ｃａｍｅｎｉｓｃｈ， Ｍ． Ｊｏｙｅ ａｎｄ Ｇ． Ｔｓｕｄｉｋ， "Ａ Ｐｒａｃｔｉｃａｌ ａｎｄ Ｐｒｏｖａｂｌｅ Ｓｅｃｕｒｅ Ｃｏａｌｉｔｉｏｎ−Ｒｅｓｉｓｔａｎｔ Ｇｒｏｕｐ Ｓｉｇｎａｔｕｒｅ Ｓｃｈｅｍｅ"， Ｉｎ Ａｄｖａｎｃｅｓ ｉｎ Ｃｒｙｐｔｏｌｏｇｙ ＣＲＹＰＴＯ ２０００， ＬＮＣＳ １８８０， ｐ２５５−２７０， Ｓｐｒｉｎｇｅｒ −Ｖｅｒｌａｇ， ２０００．

本発明の目的は、証書型の電子マネーの不正使用や誤使用を防止することにある。

本発明の他の目的は、電子マネーの利用におけるアンリンカビリティを確保することにある。

本発明の更に他の目的は、不正に利用された電子マネーのトレースを可能にすることにある。

以下に、［発明を実施するための最良の形態］で使用される番号・符号を括弧付きで用いて、［課題を解決するための手段］を説明する。この番号・符号は、［特許請求の範囲］の記載と［発明を実施するための最良の形態］の記載との対応関係を明らかにするために付加されたものであるが、［特許請求の範囲］に記載されている発明の技術的範囲の解釈に用いてはならない。

本発明による電子マネーシステムは、ネットワーク（１００）を介して相互に接続される管理サーバ（４０）と、検証サーバ（３０）と、送金端末（１０）と、受取端末（２０）とを具備する。管理サーバ（４０）は、送金端末（１０）の要求に応じて、証書ＩＤを含む非アクティブ電子証書（５００Ａ、５００Ｂ）を発行し、前記証書ＩＤを前記検証サーバ（３０）に通知する。送金端末（１０）は、非アクティブ電子証書（５００Ａ、５００Ｂ）に対しグループ署名（６０２Ａ、６０２Ｂ）を施してアクティブ電子証書（６００Ａ、６００Ｂ）を生成する。送金端末（１０）は、予め管理サーバ（４０）においてグループ登録し、送金端末（１０）固有のメンバ鍵（９４）を取得している。送金端末（１０）は、このメンバ鍵（９４）を利用してグループ署名（６０２Ａ、６０２Ｂ）を行う。受取端末（２０）は、送金端末（１０）から取得したアクティブ電子証書（６００Ａ、６００Ｂ）を、グループ署名（６０２Ａ、６０２Ｂ）に基づいて検証する。受取端末（２０）は、予め管理サーバ（４０）から取得したグループ公開鍵（９１）を用いてグループ署名（６０２Ａ、６０２Ｂ）の検証を行う。検証サーバ（３０）は、管理サーバ（４０）から通知された証書ＩＤと、受取端末（２０）で検証されたアクティブ電子証書（６００Ａ、６００Ｂ）に含まれる証書ＩＤとを照合し、アクティブ電子証書（６００Ａ、６００Ｂ）の使用可否を検証する。これにより、受取端末（２０）は自身の保有するアクティブ電子証書（６００Ａ、６００Ｂ）の使用可否を確認できる。

管理サーバ（４０）は、受取端末（２０）毎の電子マネー口座の残高が記録された電子マネー口座データベース（５１）を備えることが好ましい。管理サーバ（４０）は、検証サーバ（３０）において使用可能と判定されたアクティブ電子証書（６００Ａ、６００Ｂ）の示す金額（６１１Ａ、５１１Ｂ）に基づいて、受取端末（２０）に対応する口座の残金を更新する。これにより受取端末（２０）は、アクティブ電子証書（６００Ａ、６００Ｂ）を自口座に入金することができる。尚、受取端末（２０）は、管理サーバ（４０）以外に設けられた電子マネー口座、金融機関における現金口座やクレジット口座、あるいはキャリア等の課金口座にアクティブ電子証書（６００Ａ、６００Ｂ）（に相当する金額）を入金しても良い。

検証サーバ（３０）は、管理サーバ（４０）から通知された証書ＩＤを記録する証書ＩＤデータベース（４９）を備える。検証サーバ（３０）は、検証要求されたアクティブ電子証書（６００Ａ、６００Ｂ）に含まれる証書ＩＤが証書ＩＤデータベース（４９）に記録されていない場合、アクティブ電子証書（６００Ａ、６００Ｂ）の使用を禁止する。

検証サーバ（３０）は、口座データベース（５１）の更新に応じて証書ＩＤデータベース（４９）に記録された証書ＩＤを消去する。このため、本発明に係る検証サーバ（３０）は、管理サーバ（４０）から発行された全ての電子マネーのうち、現在流通している電子マネーに関する情報のみで電子マネーの使用可否の検証ができる。又、証書ＩＤデータベース（４９）から電子マネーの証書ＩＤを消去する際、電子マネーの利用アーカイブとして、当該証書ＩＤと決済した端末を識別するユーザＩＤとを紐つけて、他のデータベースに記録しても構わない。

受取端末（２０）は、自身が保有するアクティブ電子証書（６００Ａ、６００Ｂ）のロック要求を発行することが好ましい。検証サーバ（３０）は、ロック要求に応答して、アクティブ電子証書（６００Ａ、６００Ｂ）の利用を禁止する。これにより、電子マネーの不正使用（例えば、電子マネーの二重使用）を防止できる。又、受取端末（２０）は、自身が保有するアクティブ電子証書（６００Ａ、６００Ｂ）のリフレッシュ要求を発行することが好ましい。管理サーバ（４０）は、リフレッシュ要求に応答して、アクティブ電子証書（６００Ａ、６００Ｂ）の証書ＩＤを変更し、変更後の証書ＩＤを検証サーバ（３０）に通知する。これにより、他の端末が発行された証書ＩＤを不正に取得しても、その証書ＩＤを無効にし、電子マネーの不正使用を防止することができる。

管理サーバ（４０）は、非アクティブ電子証書（５００Ａ、５００Ｂ）の証書ＩＤと、非アクティブ電子証書（５００Ａ、５００Ｂ）の発行先の送金端末（１０）とを対応付けて記録する証書ＩＤデータベース（４９）を備える。このため、管理サーバ（４０）は、電子マネーの発行先を特定することができる。

管理サーバ（４０）は、証書ＩＤを含む証書情報（５０１Ａ、５０１Ｂ）に対し、管理サーバ秘密鍵（９２）を用いて管理サーバ署名（５０２Ａ、５０２Ｂ）を施して非アクティブ電子証書（５００Ａ、５００Ｂ）を生成することが好ましい。送金端末（１０）は、管理サーバ（４０）から取得した管理公開鍵（９３）を用いて管理サーバ署名（５０２Ａ、５０２Ｂ）を検証する。

送金端末（１０）は、アクティブ電子証書（６００Ａ、６００Ｂ）の利用条件（６０１Ａ、６０１Ｂ）を設定することが好ましい。検証サーバ（３０）は、利用条件に基づいて前記アクティブ電子証書（６００Ａ、６００Ｂ）の利用可否を検証する。

利用条件（６０１Ａ、６０１Ｂ）は、アクティブ電子証書（６００Ａ、６００Ｂ）の利用可能な有効期限（５１２Ａ、５１２Ｂ）を含むことが好ましい。これにより、アクティブ電子証書（６００Ａ、６００Ｂ）の使用期限を設定することができる。

第１の態様に係る管理サーバ（４０）は、送金端末（１０）の与信残高を記録する与信残高データベース（５０）を備えることが好ましい。送金端末（１０）は、非アクティブ電子マネー（５００Ａ）の使用限度額（５１１Ａ）を指定する。管理サーバ（４０）は、使用限度額（５１１Ａ）を非アクティブ電子マネー（５００Ａ）に設定し、使用限度額（５１１Ａ）に基づき送金端末（１０）の与信残高を更新する。又、管理サーバ（４０）は与信残高データベース（５０）とは別に、送金端末（１０）の電子マネーが預金される電子マネー口座を備えても良い。管理サーバ（４０）は、指定した使用限度額（５１１Ａ）に基づいて、この電子マネー口座の預金額を更新する。この電子マネー口座を利用することで、与信残高データベース（５０）のみの場合に比べ、非アクティブ電子マネー（５００Ａ）の使用限度額を多く利用できる。

本発明によれば、証書型の電子マネーの不正使用や誤使用を防止することができる。

又、電子マネーの送金側と受取側との間における匿名性を確保することができる。

更に、不正に利用された電子マネーのトレースが可能となる。

以下、添付図面を参照して、本発明による電子マネーシステムの実施の形態を説明する。図面において同一、又は類似の参照符号は、同一、類似、又は等価な構成要素を示している。

１．第１の実施の形態
図１から図１９を参照して、本発明による電子マネーシステムの第１の実施の形態を説明する。第１の実施の形態では、携帯通信網に例示されるネットワークに接続する端末間において電子マネーが取引される電子マネーシステムを一例に説明する。ここで取り扱われる電子マネーは、それ自体が価値をもつ電子証書型の電子マネーである。

（構成）
図１から図７を参照して、本発明による電子マネーシステムの第１の実施の形態の構成を説明する。図１は、第１の実施の形態における電子マネーシステムの構成を示す図である。図１を参照して、電子マネーシステムは、キャリアネットワーク１００に接続される送金端末１０、受取端末２０、検証サーバ３０、管理サーバ４０を具備する。

キャリアネットワーク１００は、通信事業者や企業（以下、キャリアと称す）が運営する通信網であり、例えば、携帯電話通信網、固定電話通信網、企業内ＬＡＮである。管理サーバ４０は、電子マネーを発行するキャリアや銀行等の機関（以下、発行機関と称す）が運営するコンピュータ装置である。検証サーバ３０は、電子マネーを検証する機関（以下、検証機関と称す）が運営するコンピュータ装置である。検証機関は、発行機関と同一の企業でも、他の企業（例えば、発行機関に電子マネーの検証業務を委託された第３者機関）でもどちらでも良い。第１の実施の形態では、同一のキャリアが発行機関及び検証機関として検証サーバ３０及び管理サーバ４０を運営する形態を一例に説明する。又、第１の実施の形態における送金端末１０及び受取端末２０は、電子マネー利用者（個人又は企業）が持つ通信端末として説明する。

ここで、第１の実施の形態における電子マネーシステムの概要を説明する。管理サーバ４０は、送金端末１０の要求に応じて、電子証書である非アクティブ電子マネー５００Ａを発行する。この際、非アクティブ電子マネー５００Ａには使用限度額が記され、管理サーバ４０のみが保有する秘密鍵（管理サーバ秘密鍵９０）によって電子署名（管理サーバ署名５０２Ａ）が施される。送金端末１０は、非アクティブ電子マネー５００Ａを有効化してアクティブ電子マネー６００Ａを生成する。ここで有効化とは、非アクティブ電子マネー５００Ａに、使用限度額以下の金額を割り当て、グループ署名６０２Ａを施すことである。これにより、アクティブ電子マネー６００Ａは、決済可能（通貨として利用可能）な電子マネーとなる。又、検証サーバ３０は、アクティブ電子マネー６００Ａの利用可否を検証する。アクティブ電子マネー６００Ａを受け取った受取端末２０は、任意の時期に検証サーバ３０にアクティブ電子マネー６００Ａを送信して、その利用可否を検証することができる。又、検証サーバ３０は、アクティブ電子マネー６００Ａを検証し、電子マネーの不正使用（口座への不正な入金や二重使用）を防止する機能を有する。

以下、第１の実施の形態における電子マネーシステムの構成について詳細に説明する。

送金端末１０は、Ｉ／Ｏインタフェース１４によってキャリアネットワーク１００に接続可能な通信端末（例示：携帯通信端末やコンピュータ）である。Ｉ／Ｏインタフェース１４は、無線回線あるいは有線回線を介してキャリアネットワーク１００に接続し、送金端末１０とキャリアネットワーク１００との間におけるデータの送受信を制御する。又、送金端末１０は、近距離無線通信回線２００を介して受取端末２０と接続可能なＩ／Ｏインタフェース１５を備える。Ｉ／Ｏインタフェース１５は、近距離無線通信回線２００を介して接続する受取端末２０とのデータの送受信を制御する。送金端末１０は、近距離無線通信回線２００を介して受取端末２０にアクティブ電子マネー６００Ａを送信する。ここでは、秘匿通信が可能な通信プロトコル（例えば、ＨＴＴＰＳ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ ｏｖｅｒ Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ）を使用した通信が好適である。近距離無線通信回線２００は、例えば、ＮＦＣ（Ｎｅａｒ Ｆｉｅｌｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）、赤外線通信回線、Ｂｌｕｅｔｏｏｔｈ（登録商標）である。尚、近距離無線通信回線２００は、送金端末１０と受取端末２０との間においてデータの送受信ができれば良いため、無線回線に限定されるものでなく有線回線でも構わない。又、近距離無線通信回線２００を介して送受信されるデータは、キャリアネットワーク１００を介して送受信されても構わない。

送金端末１０は、バス１６に接続されるＣＰＵ１１、ＲＡＭ１２、記憶装置１３を備える。ＣＰＵ１１は、Ｉ／Ｏインタフェース１４、１５を制御して各種データの送受信を制御する。又、ＣＰＵ１１は、記憶装置１３に格納された送金端末用プログラム１７を実行して、図２に示される各機能を実現する。詳細には、ＣＰＵ１１は、ＲＡＭ１２に一時格納した送金端末用プログラム１７を実行して、電子証書要求部１７１、管理サーバ署名検証部１７２、電子証書有効化部１７３の各機能を実現する。

電子証書要求部１７１は、管理サーバ４０に対し、グループ加入や電子マネーの発行を要求する。本発明による電子マネーシステムでは、管理サーバ４０にグループ登録されない端末には電子マネーは発行されない。このため、送金端末１０は、電子マネーの発行を受ける前に管理サーバ４０にグループ登録される必要がある。管理サーバ署名検証部１７２は、管理サーバ公開鍵９３を用いて管理サーバ署名５０２Ａを検証する。電子証書有効化部１７３は、管理サーバ４０から発行された非アクティブ電子マネー５００Ａを有効化し、アクティブ電子マネー６００Ａを生成する。この際、電子証書有効化部１７３は、非アクティブ電子マネー５００Ａに金額６１１Ａを指定し、グループ登録時に作成したメンバ鍵９４を用いてグループ署名６０２Ａを施し、アクティブ電子マネー６００Ａを生成する。このように、送金端末１０は、送金端末用プログラム１７を実行することで、非アクティブ電子マネー５００Ａの取得、使用金額の指定及び電子署名によるアクティブ電子マネー６００Ａの生成を実行する。

アクティブ電子マネー６００Ａの生成の際に施されるグループ署名６０２Ａの詳細を説明する。本発明では、例えば、Ｇ． Ａｔｅｎｉｅｓｅ， Ｊ． Ｃａｍｅｎｉｓｃｈ， Ｍ． Ｊｏｙｅ ａｎｄ Ｇ． Ｔｓｕｄｉｋ， “Ａ Ｐｒａｃｔｉｃａｌ ａｎｄ Ｐｒｏｖａｂｌｅ Ｓｅｃｕｒｅ Ｃｏａｌｉｔｉｏｎ−Ｒｅｓｉｓｔａｎｔ Ｇｒｏｕｐ Ｓｉｇｎａｔｕｒｅ Ｓｃｈｅｍｅ”， Ｉｎ Ａｄｖａｎｃｅｓ ｉｎ Ｃｒｙｐｔｏｌｏｇｙ ＣＲＹＰＴＯ ２０００， ＬＮＣＳ １８８０， ｐ２５５−２７０， Ｓｐｒｉｎｇｅｒ −Ｖｅｒｌａｇ， ２０００．に記載のグループ署名方法が利用される。グループ登録した送金端末１０は、管理サーバ４０においてグループ登録することにより、送金端末１０固有のメンバ鍵９４、及びメンバ証明情報９６を取得する。詳細には、送金端末１０は、乱数とグループ公開鍵９１とから端末公開鍵、端末秘密鍵、及び署名部分情報を生成し、端末公開鍵及び署名部分情報を管理サーバ４０に送信する。管理サーバ４０は、署名用グループ秘密鍵９０Ａと、送金端末１０から受け取った署名部分情報とを用いてデジタル署名を生成し、メンバ証明情報９６として出力する。送金端末１０は、管理サーバ４０によって署名されたメンバ証明情報９６を保有することで、グループへの登録が保証される。一方、管理サーバ４０は、端末固有のメンバ鍵９４を生成するための部分情報を送金端末１０に送信する。送金端末１０は、グループ登録時に生成した乱数、管理サーバ４０からの部分情報、及び端末公開鍵に対応する端末秘密鍵を用いて送金端末１０固有のメンバ鍵９４を生成する。

以上のように、管理サーバ４０へグループ登録した端末（例えば送金端末１０）は、端末固有のメンバ鍵９４及びメンバ証明情報９６を取得することができる。送金端末１０はメンバ鍵９４とメンバ証明情報９６を用いることで、電子証書にグループ署名を施す。詳細には、送金端末１０の電子証書有効化部１７３は、メンバ鍵９４と、図示しない乱数発生器によって生成された乱数と、メンバ証明情報９６とから変換データを生成する。電子証書有効化部１７３は、この変換データとメッセージ（非アクティブ電子マネー５００Ａ及び利用条件６０１Ａ）とを用いてグループ署名６０２Ａを生成する。尚、本発明に係るグループ署名には、処理速度の速い楕円曲線上のＷｅｉｌペアリング、又はＴａｔｅペアリングの双線形性を利用したグループ署名が好適である。

グループ署名は、グループに共通のグループ公開鍵９１によって検証することができる。このため、署名を検証した端末（例えば受取端末２０）は、グループ署名した端末（例えば送金端末１０）を特定することができない。しかし、検証サーバ３０は、暗号用グループ秘密鍵９０Ｂを用いてグループ署名から、署名した送金端末１０の端末公開鍵を抽出することができる。一方、管理サーバ４０は、グループ登録時に、送金端末１０のユーザＩＤ９５と端末公開鍵、メンバ証明情報９６に施したデジタル署名等を対応付けて記録している。このため、管理サーバ４０のみが、検証サーバ３０によってグループ署名から抽出された端末公開鍵を取得することで、電子マネーを有効化した送金端末１０を特定することができる。

受取端末２０は、Ｉ／Ｏインタフェース２４によってキャリアネットワーク１００に接続可能な通信端末（例示：携帯通信端末やコンピュータ）である。Ｉ／Ｏインタフェース２５は、無線回線あるいは有線回線を介してキャリアネットワーク１００に接続し、受取端末２０とキャリアネットワーク１００との間におけるデータの送受信を制御する。又、受取端末２０は、近距離無線通信回線２００を介して送金端末１０と接続可能なＩ／Ｏインタフェース２４を備える。受取端末２０は、近距離無線通信回線２００を介して送金端末１０からアクティブ電子マネー６００Ａを取得する。ここでは、秘匿通信が可能な通信プロトコル（例えば、ＨＴＴＰＳ）を使用した通信が好適である。

受取端末２０は、バス２６に接続されるＣＰＵ２１、ＲＡＭ２２、記憶装置２３を備える。ＣＰＵ２１は、Ｉ／Ｏインタフェース２４、２５を制御して各種データの送受信を制御する。又、ＣＰＵ２１は、記憶装置２３に格納された受取端末用プログラム２７を実行して、図３に示される各機能を実現する。詳細には、ＣＰＵ２１は、ＲＡＭ２２に一時格納した受取端末用プログラム２７をを実行して、グループ署名検証部２７１、管理サーバ署名検証部２７２、電子証書利用部２７３の各機能を実現する。

グループ署名検証部２７１は、事前に取得したグループ公開鍵９１を用いて、送金端末１０から取得したアクティブ電子マネー６００Ａに施されたグループ署名６０２Ａの検証を行う。管理サーバ署名検証部２７２は、事前に取得した管理サーバ公開鍵９３を用いてアクティブ電子マネー６００Ａに施された管理サーバ署名５０２Ａを検証する。電子証書利用部２７３は、取得したアクティブ電子マネー６００Ａが利用可能かを調べるため、アクティブ電子マネー６００Ａを検証サーバ３０に送信する。電子証書利用部２７３は、アクティブ電子マネー６００Ａの決済処理を行う。詳細には、電子証書利用部２７３は、決済要求とともにアクティブ電子マネー６００Ａを、検証サーバ３０又は管理サーバ４０送信し、自身の持つ口座又はＩＣカードへ入金させる。

検証サーバ３０は、Ｉ／Ｏインタフェース３５によってキャリアネットワーク１００に接続可能なコンピュータ装置である。Ｉ／Ｏインタフェース３５は、通信回線を介してキャリアネットワーク１００に接続し、検証サーバ３０とキャリアネットワーク１００との間におけるデータの送受信を制御する。又、検証サーバ３０は、通信回線３００を介して管理サーバ４０に接続するＩ／Ｏインタフェース３４を備える。Ｉ／Ｏインタフェース３４は、管理サーバ４０と間のデータの送受信を制御する。

検証サーバ３０は、バス３６に接続されるＣＰＵ３１、ＲＡＭ３２、記憶装置３３を備える。ＣＰＵ３１は、Ｉ／Ｏインタフェース３４、３５を制御して各種データの送受信を制御する。図４を参照して記憶装置３３は、検証サーバ用プログラム３７を格納する。又、記憶装置３３は、発行された電子マネー（非アクティブ電子マネー５００Ａ）を識別するための証書ＩＤを格納する証書ＩＤデータベース３８（証書ＩＤ Ｄ／Ｂ３８）を備える。ＣＰＵ３１は、検証サーバ用プログラム３７を実行して、図５に示される各機能を実現する。詳細には、ＣＰＵ３１は、ＲＡＭ３２に一時格納した検証サーバ用プログラム３７を実行して、利用状況検証部３７１、利用条件検証部３７２、グループ署名検証部３７３、管理サーバ署名検証部３７４の各機能を実現する。

利用状況検証部３７１は、管理サーバ４０から発行された証書ＩＤを証書ＩＤ Ｄ／Ｂ３８に登録する。利用状況検証部３７１は、検証要求又は決済要求に応答して、受信したアクティブ電子マネー６００Ａの利用可否を証書ＩＤ Ｄ／Ｂ３８を参照して検証する。詳細には、アクティブ電子マネー６００Ａに含まれる証書ＩＤ５１３Ａと一致する証書ＩＤが、証書ＩＤ Ｄ／Ｂ３８に存在する場合、当該アクティブ電子マネー６００Ａは利用可能である判定される。利用可能と判定された後の処理は、検証処理か決済処理かによって異なる。検証要求に応答した検証処理において利用可能と判定された場合、利用状況検証部３７１は、検証要求した受取端末２０のユーザＩＤを証書ＩＤとを対応付けて証書ＩＤ Ｄ／Ｂ３８に格納する。決済要求に応答した決済処理において利用可能と判定された場合、当該証書ＩＤを証書ＩＤ Ｄ／Ｂ３８から削除し、変更履歴を図示しないアーカイブデータベースに保存する。一方、証書ＩＤ５１３Ａと一致する証書ＩＤが証書ＩＤ Ｄ／Ｂ３８にない場合、アクティブ電子マネー６００Ａは使用不可であると判定される。利用状況検証部３７１は、検証結果を検証依頼元（例えば受取端末２０）及び管理サーバ４０に通知する。又、利用状況検証部３７１は、検証結果とともに検証依頼元から送られたユーザＩＤを管理サーバ４０に通知する。更に、決済要求に応じた検証において使用不可と判定された場合、利用状況検証部３７１は、不正使用とみなし、決済依頼元から送られたユーザＩＤとともに管理サーバ４０に通報しても良い。

証書ＩＤ Ｄ／Ｂ３８には、発行済みで未使用の電子マネーの証書ＩＤが記録されているため、従来技術のように、使用済みの電子マネーに関するデータを全て蓄積する必要はない。このため、容量の小さなデータベースで電子マネーの使用状況を検証し、不正使用のチェックが行える。又、検証サーバ３０は、検証依頼元から送信されるユーザＩＤによって検証依頼元を特定する情報を有していないため、検証依頼元（例えば受取端末２０）の匿名性は、検証サーバ３０に対して確保される。

後述するようにアクティブ電子マネー６００Ａには、電子マネーとしての利用条件が指定されている。利用条件検証部３７２は、この利用条件を参照して、アクティブ電子マネー６００Ａが利用可能か否かの判定を行う。

グループ署名検証部３７３は、事前に取得したグループ公開鍵９１を用いて、受取端末２０から取得したアクティブ電子マネー６００Ａに施されたグループ署名の検証を行う。管理サーバ署名検証部３７４は、事前に取得した管理サーバ公開鍵９３を用いてアクティブ電子マネー６００Ａに施された管理サーバ署名を検証する。

管理サーバ４０は、Ｉ／Ｏインタフェース４４によってキャリアネットワーク１００に接続可能なコンピュータ装置である。Ｉ／Ｏインタフェース４４は、通信回線を介してキャリアネットワーク１００に接続し、管理サーバ４０とキャリアネットワーク１００との間におけるデータの送受信を制御する。又、管理サーバ４０は、通信回線３００を介して検証サーバ３０に接続するＩ／Ｏインタフェース４５を備える。Ｉ／Ｏインタフェース４５は、管理サーバ４０と間のデータの送受信を制御する。通常、管理サーバ４０と検証サーバ３０との間におけるデータの送受信は、通信回線３００を介して行われる。サーバ４０と検証サーバ３０との間におけるデータの送受信はキャリアネットワーク１００を介して行われても構わない。ただし、秘匿強度の高い専用線である通信回線３００を介して検証サーバ３０と管理サーバ４０との間の通信を行うことがより好ましい。又、検証サーバ３０と管理サーバ４０は同一装置内に設けられても、別々に離隔されて設けられてもどちらでも構わない。

管理サーバ４０は、バス４６に接続されるＣＰＵ４１、ＲＡＭ４２、記憶装置４３を備える。ＣＰＵ４１は、Ｉ／Ｏインタフェース４４、４５を制御して各種データの送受信を制御する。図６を参照して記憶装置４３は、管理サーバ用プログラム４７を格納する。又、記憶装置４３は、グループデータベース４８（グループＤ／Ｂ４８）、証書ＩＤデータベース４９（証書ＩＤ Ｄ／Ｂ４９）、与信残高データベース５０（与信残高Ｄ／Ｂ５０）、電子マネー口座データベース５１（電子マネー口座Ｄ／Ｂ５１）を備える。

ＣＰＵ４１は、管理サーバ用プログラム４７を実行して、図７に示される各機能を実現する。詳細には、ＣＰＵ４１は、ＲＡＭ４２に一時格納した管理サーバ用プログラム４７を実行して、グループ登録部４７１、電子証書発行部４７２、与信残高管理部４７３、電子マネー口座管理部４７４の各機能を実現する。

グループ登録部４７１は、複数の端末を所定のカテゴリ毎にグループ化してグループＤ／Ｂ４８に登録する。例えば、端末が利用しているキャリア毎にグループ化したり、端末のユーザの利用地域や個人情報に応じたカテゴリ毎にグループ化する。

グループ登録部４７１は、グループ毎にグループ秘密鍵９０（署名用グループ秘密鍵９０Ａ、暗号用グループ秘密鍵９０Ｂ）、及びグループ公開鍵９１（署名用グループ公開鍵９１Ａ、及び暗号用グループ公開鍵９１Ｂ）を生成する。生成した暗号用グループ秘密鍵９０Ｂ、及び暗号用グループ公開鍵９１Ｂは、検証サーバ３０に送信される。尚、暗号用秘密鍵９０Ｂを管理サーバ４０に対して秘密にしたい場合は、暗号用グループ秘密鍵９０Ｂ、及び暗号用グループ公開鍵９１Ｂは予め検証サーバ３０で生成しておき、暗号用グループ公開鍵９１Ｂのみが管理サーバ４０に送信されても良い。

又、グループ登録部４７１は、要求に応じて端末（例えば送金端末１０）に固有のメンバ証明情報９６を生成する。グループ登録の際、グループ登録部４７１は、端末を識別するためのユーザＩＤ９５を端末毎に付与し、このユーザＩＤ９５とグループ（グループ秘密鍵９０、グループ公開鍵９１）とを対応付けてグループＤ／Ｂ４８に格納する。又、メンバ証明情報９６が付与された端末をグループ登録する場合、これらの情報もユーザＩＤに対応付けてグループＤ／Ｂ４８に登録される。グループ登録部４７１は、グループに登録しようとする端末に対し、グループ公開鍵９１を送信し、メンバ証明情報９６及びメンバ鍵９４を生成するための部分情報を生成する。これにより、グループＤ／Ｂ４８に登録された端末は、管理サーバ４０から発行される電子マネー（非アクティブ電子マネー５００Ａ）を電子証書として利用（有効化）することができる。

電子証書発行部４７２は、送金端末１０からの要求に応じて電子証書である非アクティブ電子マネー５００Ａを発行する。この際、非アクティブ電子マネー５００Ａを識別する証書ＩＤを決定し、電子証書ＩＤ Ｄ／Ｂ４９に登録する。証書ＩＤは、非アクティブ電子マネー毎に異なり、ランダムに設定されることが好ましい。又、電子証書発行部４７２は、非アクティブ電子マネー５００Ａの発行先のユーザＩＤと発行した電子マネーの証書ＩＤとを対応付けて電子証書ＩＤ Ｄ／Ｂ４９に格納する。これにより、管理サーバ４０は、発行した電子マネーと発行先の端末（例えば送金端末１０）とを対応付けて管理することができる。尚、検証サーバ３０と管理サーバ４０が同一のキャリアによって運営される場合、電子証書ＩＤ Ｄ／Ｂ３８、４９は共通化されても良い。又、決済（入金）を終えた電子マネーに対応する証書ＩＤは、電子証書ＩＤ Ｄ／Ｂ４９から削除される。この際、電子証書ＩＤは、入金した端末のＩＤ（ユーザＩＤ９５）とともにアーカイブ用のデータベース（図示なし）に記録されても良い。更に、電子証書発行部４７２は、リフレッシュ要求に応じて新たな電子証書ＩＤを電子マネーに付与し、電子証書ＩＤ Ｄ／Ｂ４９を更新する。

与信残高管理部４７３は、与信残高Ｄ／Ｂ５０に記録される与信残高を管理する。与信残高Ｄ／Ｂ５０は、管理サーバ４０から発行される非アクティブ電子マネー５００Ａを利用可能な端末（例えば、送金端末１０）毎の与信残高が記録されるデータベースである。与信残高管理部４７３は、発行した非アクティブ電子マネー５００Ａに割り当てた使用限度額や、検証サーバ３０から通知される検証結果に含まれる金額に応じて送金端末１０に対応する与信残高を更新する。ここで管理される与信残高は、グループ登録された送金端末１０のユーザＩＤに対応付けられることが好ましい。すなわち、端末（送金端末１０）は、グループ登録によって、与信残高Ｄ／Ｂ５０を利用可能となることが好ましい。

電子マネー口座管理部４７４は、電子マネー口座Ｄ／Ｂ５１に格納される電子マネー口座を管理する。電子マネー口座Ｄ／Ｂ５１は、端末（例えば受取端末２０）毎の電子マネー口座を備える。電子マネー口座管理部４７４は、アクティブ電子マネー６００Ａに含まれる金額を、入金要求元の端末に対応する電子マネー口座に入金する。又、電子マネー口座管理部４７４は、必要に応じて端末からの要求に応じた金額を電子マネー口座Ｄ／Ｂ５１から出金する。尚、電子マネー口座管理部４７４、及び電子マネー口座Ｄ／Ｂ５１は、管理サーバ４０とは異なるコンピュータ装置に設けられても良い。この場合、電子マネー口座Ｄ／Ｂ５１は、管理サーバ４０を所有するキャリアとは異なる機関によって運営されていても構わない。

以上のような構成により、本発明による電子マネーシステムによれば以下に示す事項を実現できる。（１）管理サーバ署名によって電子マネーの発行元が保証される。（２）グループ署名によって、送金端末１０の匿名性を確保しつつ、電子マネーの署名検証が可能となる。（３）管理サーバ４０において、発行先の送金端末１０（ユーザＩＤ）と、発行した電子マネーの証書ＩＤとを対応付けているため、電子マネーのトレーサビリティを実現できる。（４）電子マネー（アクティブ電子マネー６００Ａ）を受け取った受取端末２０は、任意の時期に電子マネーの使用可否を検証できる。（５）検証サーバ３０によって電子マネーの不正使用を未然に防止できる。（６）電子マネーの使用可否を、電子マネー毎に付与された証書ＩＤを用いて検証するため、不正使用を防止するために使用するデータ容量を削減できる。（７）電子マネーに利用条件を付与して、電子マネーの利用可否を制限することができる。

（動作）
図面を参照して、本発明による電子マネーシステムの第１の実施の形態における動作の詳細を説明する。送金端末１０は、管理サーバ４０から電子証書（使用限度額が指定された非アクティブ電子マネー５００Ａ）を取得する前に、グループ登録する必要がある。又、受取端末２０は、送金端末１０から渡される電子マネー（金額が指定されたアクティブ電子マネー）を利用するため、事前に、グループ公開鍵９１を取得する必要がある。図８を参照して、本発明に係る送金端末１０のグループ登録、及び受取端末２０のグループ公開鍵取得における動作を説明する。先ず、送金端末１０のグループ登録について説明する。

ここで、送金端末１０のグループ登録処理の前に、管理サーバ４０は、グループ毎にグループ秘密鍵９０（署名用グループ秘密鍵９０Ａ、暗号用グループ秘密鍵９０Ｂ）及びグループ公開鍵９１（署名用グループ公開鍵９１Ａ、暗号用グループ公開鍵９１Ｂ）を生成している。生成された暗号用グループ秘密鍵９０Ｂ及び暗号用グループ公開鍵９１Ｂは、検証サーバ３０に送信される。尚、暗号用グループ秘密鍵９０Ｂ及び暗号用グループ公開鍵９１Ｂを管理サーバ４０に対して秘密にしたい場合、予め、検証サーバ３０が、暗号用グループ秘密鍵９０Ｂ及び暗号用グループ公開鍵９１Ｂを生成し、暗号用公開鍵９１Ｂのみを管理サーバ４０に送信しても良い。

送金端末１０は、管理サーバ４０に対し、グループへの登録要求を発行する（ステップＳ１）。管理サーバ４０は、グループ登録要求に応答して、予め設定しているグループに送金端末１０を登録する（ステップＳ２）。送金端末１０からのグループ登録要求が発行されると、管理サーバ４０のグループ登録部４７１は、登録要求に含まれる情報（例えば、送金端末１０が所属するキャリアに関する情報）に基づいて送金端末１０を登録するグループを決定する。そして、グループ登録部４７１は、決定したグループのグループ公開鍵９１を送金端末１０に送信する（図示なし）。送金端末１０は、乱数とグループ公開鍵９１とを用いて端末公開鍵と端末秘密鍵、及び署名部分情報を生成し、端末公開鍵及び署名部分情報を管理サーバ４０に送信する。グループ登録部４７１は、署名部分情報、及び署名用グループ秘密鍵９０Ａを用いて、送金端末１０に固有のメンバ証明情報９６を生成する。この際、グループ登録部４７１は、送金端末１０に固有のユーザＩＤ９５を取得し、このユーザＩＤ９５をグループに登録する。ここでは、ユーザＩＤ９５、メンバ証明情報９６、グループ（グループ秘密鍵９０、グループ公開鍵９１）、及びグループ登録の際に送金端末１０から送信された端末公開鍵とが紐つけられてグループＤ／Ｂ４８に格納される。これにより、送金端末１０固有の端末公開鍵は、ユーザＩＤ９５や、送金端末１０を特定する情報（例えば送金端末１０のユーザに関する情報や、送金端末１０にアクセス可能なアドレス情報）に対応付けられてグループＤ／Ｂ４８に格納される。尚、グループ登録部４７１は、送金端末１０からのグループ登録要求に応答して新たなグループ（グループ秘密鍵９０、グループ公開鍵９４）を設定し、このグループに送金端末１０を登録しても良いし、既存のグループに登録しても良い。又、管理サーバ４０がキャリアネットワーク１００を運営するキャリアによって運営される場合、送金端末１０や受取端末２０がキャリアネットワーク１００を利用するための契約時にグループ登録が行われることが好ましい。

グループ登録が完了すると管理サーバ４０は、管理サーバ公開鍵９３、ユーザＩＤ９５、メンバ証明情報９６を、送金端末１０に送信する（ステップＳ３）。この際、管理サーバ４０は、端末固有のメンバ鍵９４を生成するための部分情報を送金端末１０に送信する。送金端末１０は、端末公開鍵に対応する端末秘密鍵を用いて、送信された部分情報と乱数から送金端末１０固有のメンバ鍵９４を生成する（ステップＳ４）。ここで、管理サーバ公開鍵９３は、事前に送金端末１０に配布されていても構わない。又、管理サーバ４０は、グループ登録処理やグループ設定処理において新たなグループ秘密鍵９０やグループ公開鍵９１を生成した場合、あるいは管理サーバ公開鍵９３を新しい鍵に更新した場合、検証サーバ３０に対して新たな暗号用グループ秘密鍵９０Ｂ、グループ公開鍵９１、管理サーバ公開鍵９３を送信する（ステップＳ５Ｙｅｓ、Ｓ６）。このように、管理サーバ４０は、新しいグループ秘密鍵９０及びグループ公開鍵９１、又は管理サーバ公開鍵９３を更新する毎に、検証サーバ３０に鍵の配布を行う。これにより、検証サーバ３０は、常に新しい暗号用グループ秘密鍵９０Ｂ、グループ公開鍵９１、及び管理サーバ公開鍵９３を入手できる。又、管理サーバ４０は、検証サーバ３０からの要求に応じて最新の暗号用グループ秘密鍵９０Ｂ、グループ公開鍵９１又は管理サーバ公開鍵９３を送信しても良い。

一方、受取端末２０は、任意の時期に管理サーバ４０からグループ公開鍵９１及び管理サーバ公開鍵９３を取得する。詳細には、先ず受取端末２０は、公開鍵要求を管理サーバ４０に発行する（ステップＳ７）。公開鍵要求には、所望のグループ（グループ公開鍵９１）を指定する情報（例えば、キャリアを指定する情報）が含まれていても良い。管理サーバ４０は、公開鍵要求に応答して、グループ公開鍵９１及び管理サーバ公開鍵９３を受取端末２０に送信する（ステップＳ８）。ここで、グループの指定がある場合、管理サーバ４０は、指定されたグループのグループ公開鍵９１を送信することが好ましい。

又、受取端末２０は、送金端末１０と同様な方法（ステップＳ１〜Ｓ３）によりグループ登録処理を行っても良い。これにより、受取端末２０は、メンバ証明情報９６を取得し、受取端末２０に固有のメンバ鍵９４を生成することができる。この場合、受取端末２０は、送金端末１０が有する電子証書有効化部１７３と同じ機能を備えることが好ましい。受取端末２０が電子証書有効化部１７３を備えることで、後述するリフレッシュ処理において、管理サーバ４０によって証書ＩＤ５１３Ａが書き換えられた非アクティブ電子マネー５００Ａを有効化することができる。尚、受取端末２０が登録するグループは、送金端末１０と同じグループでも別のグループでもどちらでも構わない。

以上のように、送金端末１０（受取端末２０）は、管理サーバ４０が管理するグループに登録されることで、管理サーバ４０が発行する非アクティブ電子マネー５００Ａを有効化して利用することが可能となる。又、電子マネーシステム内の各構成は、グループ公開鍵９１及び管理サーバ公開鍵９３を取得することで電子マネーの署名を検証することができる。尚、ユーザＩＤ９５は、ＵＩＭ（Ｕｓｅｒ Ｉｄｅｎｔｉｔｙ Ｍｏｄｕｌｅ）やＳＩＭ（Ｓｕｂｓｃｒｉｂｅｒ Ｉｄｅｎｔｉｔｙ Ｍｏｄｕｌｅ）カードに記録される加入者情報でも良い。この場合、ユーザＩＤ９５は、端末が加入するキャリアしか知り得ない情報であるため、キャリアが管理サーバ４０を運用することが好ましい。これにより、ユーザ（送金端末１０や受取端末２０）を特定する情報の秘匿性を高めることができる。この場合、端末（例えば送金端末１０）は、ユーザＩＤ９５が書き込まれたＳＩＭカード（図示なし）を備える通信端末である。

本発明による電子マネーシステムにおける各構成の鍵の保有状況を図９に示す。ここでは、送金端末１０がグループ登録し、受取端末２０が公開鍵要求を発行した後の鍵の保有状況が示される。グループ登録よって送金端末１０は、グループ公開鍵９１、メンバ鍵９４、管理サーバ公開鍵９３、メンバ証明情報９６を取得し、記憶装置１３内に格納する。又、送金端末１０は、送金端末１０に割り当てられたユーザＩＤ９５を記憶装置１３又は図示しないＳＩＭカードに格納して保有する。公開鍵要求によって受取端末２０は、グループ公開鍵９１、管理サーバ公開鍵９３を取得し、記憶装置２３に格納する。又、受取端末２０は、受取端末２０に割り当てられたユーザＩＤ９５を記憶装置２３又は図示しないＳＩＭカードに格納して保有する。更に、受取端末２０が送金端末１０と同様にグループ登録している場合、メンバ鍵９４及びメンバ証明情報９６が記憶装置２３に格納される（図示なし）。検証サーバ３０は、暗号用グループ秘密鍵９０Ｂ、グループ公開鍵９１、管理サーバ公開鍵９３を記憶装置３３に格納している。管理サーバ４０は、グループ秘密鍵９０、グループ公開鍵９１、管理サーバ秘密鍵９２、管理サーバ公開鍵９３を記憶装置４３に格納している。又、管理サーバ４０は、グループ登録された端末（送金端末１０又は受取端末２０）の端末公開鍵と、端末固有のユーザＩＤ９５とを紐つけてグループＤ／Ｂ４９に記録している。このため、管理サーバ４０は、ユーザＩＤ９５を利用して送金端末１０及び受取端末２０を特定することができる。

次に、図１０を参照して、本実施の形態における電子マネーの発行から送金、受取までの動作の詳細を説明する。送金端末１０は、使用限度額を指定した電子マネー要求を管理サーバ４０に発行する（ステップＳ１１、Ｓ１２）。ここで、使用限度額とは、管理サーバ４０から発行される電子証書（非アクティブ電子マネー５００Ａ）に設定できる金額の上限値を指定する情報である。

電子マネー要求を受け付けた管理サーバ４０は、指定された使用限度額を設定した非アクティブ電子マネーを生成する（ステップＳ１３）。詳細には、管理サーバ４０の電子証書発行部４７２は、ユーザＩＤ９５及びメンバ証明情報９６で送金端末１０をグループ登録されているかどうかを確認し、グループ登録されている場合、指定された使用限度額に応じた非アクティブ電子マネー５００Ａを生成する。図１１を参照して、ここでは電子証書発行部４７２は、指定された使用限度額５１１Ａ、発行日時５１２、非アクティブ電子マネーを識別する証書ＩＤ５１３Ａを含む証書情報５０１Ａを生成する。発行日時５１２Ａは、規定のフォーマットの文字列のみであっても、正確な時刻情報によって証書情報５０１Ａの生成時刻を保証するタイムスタンプでも構わない。次に、電子証書発行部４７２は証書情報５０１Ａに対し、管理サーバ秘密鍵９２を用いて管理サーバ署名５０２Ａを施し、非アクティブ電子マネー５００Ａを生成する。

管理サーバ４０は、生成した非アクティブ電子マネー５００Ａを、キャリアネットワーク１００を介して要求元の送金端末１０に発行する（ステップＳ１４）。この際、管理サーバ４０は、発行した非アクティブ電子マネー５００Ａに割り当てた証書ＩＤの登録及び通知、与信残高の更新を行う（ステップＳ１５、Ｓ１６、Ｓ１８）。詳細には、管理サーバ４０の電子証書発行部４７２は、非アクティブ電子マネー５００Ａに割り当てた証書ＩＤ５１３Ａ、発行日時５１２Ａ、発行先のユーザＩＤ９５を対応付けて証書ＩＤ Ｄ／Ｂ４９に登録する（ステップＳ１５）。又、電子証書発行部４７２は、証書ＩＤ５１３Ａと発行日時５１２Ａを通信回線３００を介して検証サーバ３０に通知する（ステップＳ１６）。検証サーバ３０は、通知された証書ＩＤ５１３Ａと発行日時５１２Ａとを対応付けて証書ＩＤ Ｄ／Ｂ３８に登録する（ステップＳ１７）。管理サーバ４０の与信残高管理部４７３は、使用限度額５１１Ａに応じて与信残高Ｄ／Ｂ５０を更新する（ステップＳ１８）。ここでは、使用限度額５１１Ａに相当する金額が送金端末１０に対応する与信残高から差し引かれる。例えば、送金端末１０に対応する与信残高が１００００であり使用限度額５１１Ａが１０００である場合、更新後の与信残高は、９０００となる。尚、ステップＳ１５、Ｓ１６における証書ＩＤの登録通知処理とステップＳ１８における与信残高更新処理の実行順は、非アクティブ電子マネー発行後であればこの限りではない。又、管理サーバ４０は、与信残高Ｄ／Ｂ５０の他に送金端末１０の電子マネーが預金される電子マネー口座Ｄ／Ｂを備えても良い。この場合、非アクティブ電子マネー５００Ａの発行の際、管理サーバ４０は使用限度額５１１Ａに相当する金額をこの電子マネー口座Ｄ／Ｂから差し引く。与信残高Ｄ／Ｂ５０のみでは、送金端末１０が使用できる電子マネーの額は与信残高によって制限されるが、このような電子マネー口座Ｄ／Ｂを利用することで、更に高額の電子マネーを利用できる。尚、管理サーバ４０は、非アクティブ電子マネー５００Ａを発行する際、与信残高Ｄ／Ｂと電子マネー口座Ｄ／Ｂを併用してもよいし、与信残高Ｄ／Ｂのみ、あるいは電子マネー口座Ｄ／Ｂのみを利用して発行しても良い。もちろんこの電子マネー口座Ｄ／Ｂは、図６に示す電子マネー口座Ｄ／Ｂ５１が利用されも良いし、非アクティブ電子マネーの発行専用に使用されるデータベースでも良い。

送金端末１０は、非アクティブ電子マネー５００Ａを受け取ると、管理サーバ公開鍵９３を用いて管理サーバ署名５０２Ａの検証を行う（ステップＳ１９）。これにより、非アクティブ電子マネー５００Ａが管理サーバ４０から正規に発行されたものであることが確認できる。署名検証において合格である場合、送金端末１０は、電子証書としての非アクティブ電子マネー５００Ａを元に、通貨として機能するアクティブ電子マネー６００Ａを生成する（ステップＳ２０）。ここでは、送金端末１０の電子証書有効化部１７３は、非アクティブ電子マネー５００Ａに利用条件６０１Ａを付加した情報（メッセージ）に対し、メンバ鍵９４及びメンバ証明情報９６等を用いてグループ署名６０２Ａを施し、図１２に示すようなアクティブ電子マネー６００Ａを生成する。この際、電子証書有効化部１７３は、乱数、グループ公開鍵９１、又は共通変数等を利用してグループ署名６０２Ａを施しても良い。利用条件６０１Ａとして設定される情報は、アクティブ電子マネー６００Ａの価値を決定する金額６１１Ａや、アクティブ電子マネー６００Ａの使用可能期限を決める有効期限６１２Ａである。又、当該アクティブ電子マネー６００Ａの検証先となる検証サーバ３０のアドレスが含まれていても良い。ステップＳ２０における有効化処理により、アクティブ電子マネー６００Ａは通貨として価値を有する電子マネーとなる。尚、金額６１１Ａは通貨価値を決定するため必ず設定されなければならないが、有効期限６１２Ａは設定されなくても良い。又、有効期限６１２Ａとは異なる、電子マネーの利用を制限する条件（例えば利用可能な店舗情報）を利用条件６０１Ａとして付加しても構わない。

送金端末１０は、生成したアクティブ電子マネー６００Ａを受取端末２０に送信する（ステップ２１）。アクティブ電子マネー６００Ａの送金に際し、送金端末１０は、受取端末２０と近距離無線回線２００を介して接続することが好ましい。送金端末１０は、受取端末２０からの送金要求（図示なし）に応じて近距離無線回線２００を介してアクティブ電子マネー６００Ａを送信する。近距離無線回線２００を介して送金することで、ユーザは簡易に、且つ通信費をかけることなく電子マネーの送金が可能となる。尚、アクティブ電子マネー６００Ａの送金は、キャリアネットワーク１００を介して行われても良い。キャリアネットワーク１００を介して送金することで、遠距離にいる相手に対し電子マネーの送金が可能となる。この場合、秘匿通信が可能な通信プロトコルを使用した通信によってアクティブ電子マネー６００Ａが送信されることが好適である。

送金の一例を以下に示す。サービス利用者が送金端末１０を所有し、サービス提供者が受取端末２０を所有している場合、アクティブ電子マネー６００Ａは、サービスの対価として送金端末１０から受取端末２０に送金される。あるいは、企業通貨の発行元企業が送金端末１０を所有し、企業通貨の利用者が受取端末を所有している場合、企業通貨としてアクティブ電子マネー６００Ａが送金端末１０から受取端末２０に送金（発行）される。この場合、アクティブ電子マネー６００Ａに割り当てらる金額６１１Ａは、受取端末２０からの要求（図示なし）に応じた金額が設定されることが好ましい。

受取端末２０は、アクティブ電子マネー６００Ａを受け取ると、管理サーバ公開鍵９３を用いて管理サーバ署名５０２Ａを検証するとともに、グループ公開鍵９１を用いてグループ署名６０２Ａを検証する（ステップＳ２２）。これにより、受取端末２０はアクティブ電子マネー６００Ａが正規な電子マネーかどうかを判断する。アクティブ電子マネー６００Ａは、グループ署名６１２Ａされているため、受取端末２０は、送金端末１０に関する情報を知ることなく電子マネーを検証することができる。

アクティブ電子マネー６００Ａの送金後、送金端末１０は、アクティブ電子マネー６００Ａに割り当てた金額６１１Ａを管理サーバ４０に通知する（ステップＳ２３）。この際、管理サーバ４０は、証書ＩＤ５１３Ａに対応するユーザＩＤの与信残高を、送金された金額６１１Ａに基づいて更新する。ここでは、使用限度額５１１Ａと金額６１１Ａとの差額に相当する金額が送金端末１０に対応する与信残高に加算される。例えば、与信残高が９０００、使用限度額５１１Ａが１０００、金額６１１Ａが６００である場合、更新後の与信残高は９４００となる。これにより、実際に使用（送金）された金額が与信残高から差し引かれることになる。尚、後述するように、金額６１１Ａに基づく与信残高の更新は、送金したアクティブ電子マネー６００Ａが検証サーバ３０において検証された時や、送金したアクティブ電子マネー６００Ａの決済時（送金先の口座への入金時）に行われても良い。ただし、ステップＳ２３の金額６１１Ａの通知に応じて与信残高が更新される方法によれば、送金後、任意の時期に（通常、送金後すぐに）与信残高を更新できる。しかし、この場合、送金端末１０は、与信残高更新のために管理サーバ４０に接続しなけらばならず手間や時間がかかる。又、送金端末１０から通知された金額は信頼できるものでなくてはならないため、情報の改ざんを防止するための機能を送金端末１０に設ける必要がある。一方、アクティブ電子マネー６００Ａの検証時や入金時に与信残高が更新される方法によれば、送金端末１０は、送金後、管理サーバ４０に接続する必要がなく、改ざん防止のための機能を必要としない。特に入金時に与信残高が更新されると、利用額と送金額との整合を確実に取ることができる。しかし、この場合、送金先の端末（ここでは受取端末２０）がアクティブ電子マネー６００Ａの検証や入金をしない限り、与信残高が更新されないため、送金端末１０が送金した金額以上に与信残高が少ない状態が続く可能性がある。以上のような与信残高の更新方法（更新時期）は、電子マネーシステムの特性に応じて選択されることが好ましい。

次に、図１３を参照して、アクティブ電子マネー６００Ａの検証処理について説明する。受取端末２０は、アクティブ電子マネー６００Ａを取得すると、任意の時期にアクティブ電子マネー６００Ａが使用できるか否かを検証することができる。検証に先立ち、受取端末２０は、キャリアネットワーク１００を介して検証サーバ３０に接続する。この際、利用条件６０１Ａに含まれる検証サーバのアドレスを利用して検証サーバ３０を特定する。受取端末２０は、検証要求とともにアクティブ電子マネー６００Ａを、キャリアネットワークを介して検証サーバ３０に送信する（ステップＳ３１）。

検証サーバ３０は、検証要求に応答して、最新の管理サーバ公開鍵９３を用いて管理サーバ署名５０２Ａの検証を行い、最新のグループ公開鍵９１を用いてグループ署名６０２Ａの検証を行う（ステップＳ３２）。アクティブ電子マネー６００Ａが正規の電子マネーである場合、その使用可否を検証する（ステップＳ３３）。ステップＳ３３では、証書ＩＤによる使用可否の検証と、利用条件による使用可否の検証が行われる。詳細には、検証サーバ３０の利用状況検証部３７１は、アクティブ電子マネー６００Ａに含まれる証書ＩＤ５１３Ａと一致する証書ＩＤが証書ＩＤ Ｄ／Ｂ３８に登録されているかを確認する。この際、証書ＩＤ５１３Ａと一致する証書ＩＤが登録されている場合、合格と判定され、登録されていない場合、不合格と判定される。又、利用条件検証部３７２は、アクティブ電子マネー６００Ａに含まれる利用条件６０１Ａを参照して、当該アクティブ電子マネー６００Ａが利用可能かどうかを判定する。例えば、利用条件６０１Ａとして有効期限６１２Ａが指定されている場合、現在時が有効期限を超えているかどうかに応じて利用可否を判定する。又、有効期限６１２Ａが所定の期間を示している場合、証書ＩＤ Ｄ／Ｂ３８に登録されている発行日時、又はアクティブ電子マネー６００Ａに含まれる発行日時５１２Ａから現在時間での期間を計算し、その期間が有効期限を超えているかどうかで利用可否を判定する。

検証サーバ３０は、ステップＳ３３における検証結果を受取端末２０及び管理サーバ４０に通知する（ステップＳ３４、Ｓ３５）。検証の際、アクティブ電子マネーの不正使用が発覚した場合（証書ＩＤ Ｄ／Ｂ３８に登録されていないアクティブ電子マネーが送信された場合）、その旨を検証結果として管理サーバ４０に通知しても良い。この際、検証サーバ３０は、暗号用グループ秘密鍵９０Ｂを用いてアクティブ電子マネー６００Ａから、グループ署名６１２Ａを施した送金端末１０の端末公開鍵を抽出し、検証結果とともに管理サーバ４０に送信する。管理サーバ４０では、端末公開鍵と送金端末１０を特定する情報（ユーザＩＤ９５やキャリアネットワーク１００の加入者情報）とを紐つけているため、管理サーバ４０を所有するキャリアのみが、どの端末が電子マネーを不正使用又は誤送信したかを知ることができる。又、検証サーバ３０は、検証結果とともに、アクティブ電子マネー６００Ａに含まれる証書ＩＤ５１３、使用限度額５１１Ａ及び金額６１１Ａを管理サーバ４０に送信しても良い。これにより管理サーバ４０は、証書ＩＤ５１３から特定した送金端末１０の与信残高を更新することができる（電子マネー検証時における与信残高の更新）。

検証結果を通知した検証サーバ３０は、検証したアクティブ電子マネー６００Ａに対応する証書ＩＤに、検証要求元のユーザＩＤ９５を対応付けて証書ＩＤ Ｄ／Ｂ３８を更新する（ステップＳ３６）。この際、当該証書ＩＤに他のユーザＩＤ９５が対応付けられて記録されている場合、新しいユーザＩＤ９５に書き換えられ、変更履歴が図示しないアーカイブデータベースに記録される。例えば、受取端末２０が検証済みのアクティブ電子マネー６００Ａを他の受取端末２０に送金し、他の受取端末２０が当該アクティブ電子マネー６００Ａの検証を行う場合、前回検証した受取端末２０のユーザＩＤ９５は、他の受取端末２０のユーザＩＤ９５に書き換えられる。このため、検証サーバ３０は、証書ＩＤ Ｄ／Ｂ３８に記録されたユーザＩＤの更新によって、アクティブ電子マネー６００Ａを検証した最新の端末のユーザＩＤ９５（通常、現在時においてアクティブ電子マネー６００Ａを保有している端末のユーザＩＤ９５）を知ることができる。

検証サーバ３０は、証書ＩＤ Ｄ／Ｂ３８を操作することで現在流通している電子マネーの利用を制限することができる。例えば、送金端末１０のユーザの資産が公的機関から差し押さえられた場合、検証サーバ３０は、証書ＩＤ Ｄ／Ｂ３８から、当該送金端末１０に発行した非アクティブ電子マネー５００Ａの証書ＩＤを削除する。これにより、当該送金端末１０が生成するアクティブ電子マネー６００Ａは使用不可能となる。このように、電子マネーの使用制限を短時間に行うことができる。

又、アクティブ電子マネー６００Ａを保有する受取端末２０は、電子マネーのロックやリフレッシュを行うことで、他の端末（第３者）によるアクティブ電子マネー６００Ａの不正使用を防止することができる。受取端末２０は、ロックやリフレッシュを実行する前に、保有するアクティブ電子マネー６００Ａの検証を実行していることが好ましい。これにより、受取端末２０のユーザＩＤ９５が検証サーバ３０に登録され、検証サーバ３０は、登録された受取端末２０を当該アクティブ電子マネー６００Ａの最新の保有者として認知することができる。

図１４を参照して、本発明におけるロック処理の動作を説明する。受取端末２０は、キャリアネットワーク１００を介して検証サーバ３０に接続し、検証サーバ３０に対して、ロック要求を発行する（ステップＳ４１）。この際、受取端末２０は、ロック要求とともにアクティブ電子マネー６００ＡとユーザＩＤ９５を送信する。検証サーバ３０は、ステップＳ３２及びＳ３３と同様にアクティブ電子マネー６００Ａの署名検証と、使用可否の検証を行う（ステップＳ４２、Ｓ４３）。この際、電子証書ＩＤ Ｄ／Ｂ３８を参照し、送信されたユーザＩＤ９５が既に登録されているか否かによってロック要求元の端末確認が行われることが好ましい。ステップＳ４２及びＳ４３において合格である場合、アクティブ電子マネー６００Ａのロック処理が行われる（ステップＳ４４）。ロック処理では検証サーバ３０は、証書ＩＤ Ｄ／Ｂ３８に格納された証書ＩＤにロックを示すフラグを立てて、アクティブ電子マネー６００Ａの使用を禁止する。検証サーバ３０は、当該証書ＩＤと一致する証書ＩＤ５１３Ａを有したアクティブ電子マネー６００Ａであっても、ロックされている場合、不合格とし、決済処理（入金処理）を拒否する。又、ステップＳ４３において、検証サーバ３０は、受取端末２０しかわからないパスワードによってロック要求元を確認しても良い。パスワードは、ロック要求に先立って行われたアクティブ電子マネー６００Ａの検証時に、受取端末２０が検証サーバ３０に設定することで利用できる。

検証サーバ３０は、ロック処理が終わると、ロック要求元の受取端末２０のユーザＩＤ９５とロック対象のアクティブ電子マネー６００Ａの証書ＩＤ５１３Ａとを対応付けて、履歴として図示しないアーカイブデータベースに記録する（ステップＳ４５）。これにより。アクティブ電子マネー６００Ａに対してロックした端末の履歴を管理することができる。ロック処理後、ロック応答として受取端末２０にロック完了を通知する（ステップＳ４６）。この通知は、管理サーバ４０に対して行われても良い。この場合、管理サーバ４０は、ロック完了通知に応じて自身の証書ＩＤ Ｄ／Ｂ４９に対し、ステップＳ４４と同様なロック処理やステップＳ４５と同様なロック処理の履歴の記録を行っても良い。

ロックの解除については、上述のロック処理と同様に、受取端末２０からのロック解除処理に応答してロックを示すフラグが該当する証書ＩＤから外されることで実現する。

以上のように、受取端末２０は、保有するアクティブ電子マネー６００Ａの入金処理をロックできるため、第３者による不正使用を防ぐことができる。電子マネーの特性上、受取端末２０が保有するアクティブ電子マネー６００Ａは、他の端末を経由している場合が多い。このため、経由先の端末がアクティブ電子マネーを複製する危険がある。このような場合、ユーザＩＤやパスワードを用いてロック処理することで、アクティブ電子マネーの不正使用を防ぐとともに、第３者によるロック処理の試みも防止できる。

図１５を参照して、本発明におけるリフレッシュ処理の動作を説明する。ここで、リフレッシュ要求可能な受取端末２０は、グループ登録によってメンバ鍵９４及びメンバ証明情報９６を取得しているものとする。受取端末２０は、キャリアネットワーク１００を介して検証サーバ３０に接続し、検証サーバ３０に対して、リフレッシュ要求を発行する（ステップＳ４６）。この際、受取端末２０は、ロック要求とともにアクティブ電子マネー６００ＡとユーザＩＤ９５を送信する。検証サーバ３０は、ステップＳ３２及びＳ３３と同様にアクティブ電子マネー６００Ａの署名検証と、使用可否の検証を行う（ステップＳ４７、Ｓ４８）。ここで、合格である場合、検証サーバ３０は、管理サーバ４０に対しリフレッシュ要求を発行する（ステップＳ４９）。この際、検証サーバ３０は、リフレッシュ要求とともにアクティブ電子マネー６００Ａと要求元のユーザＩＤ９５を送信する。

管理サーバ４０は、リフレッシュ要求に応答して、送信されたアクティブ電子マネー６００Ａの証書ＩＤ５１３Ａを新たな証書ＩＤに変更する（ステップＳ５０）。詳細には、管理サーバ４０の電子証書発行部４７２は、リフレッシュ要求に応答して新たな証書ＩＤを発行し、証書ＩＤ５１３を書き換える。電子証書発行部４７２は、変更前の証書ＩＤと変更後の証書ＩＤとを紐つけて、証書ＩＤ Ｄ／Ｂ４９に格納する。これにより、管理サーバ４０は証書ＩＤの変更履歴を作成することができる。電子証書発行部４７２は、新たな証書ＩＤを含む証書情報５０１Ａに対し、管理サーバ秘密鍵９２を用いて管理サーバ署名５０２Ａを施した非アクティブ電子マネー５００Ａを生成する。

管理サーバ４０は、証書ＩＤ５１３を書き換えた非アクティブ電子マネー５００Ａを受取端末２０に送信する（ステップＳ５１）。この際、電子証書発行部４７２は、リフレッシュ対象のアクティブ電子マネー６００Ａにおける金額６１１Ａを、新たな使用限度額５１１Ａに設定して非アクティブ電子マネー５００Ａに付与する。例えば、金額６１１Ａが６００である場合、６００が使用限度額５１１Ａに設定される。

管理サーバ４０は、生成した非アクティブ電子マネー５００Ａを、検証サーバ３０を介して受取端末２０に送信する（ステップＳ５１）。ここで管理サーバ４０は通信回線３００を介して検証サーバ３０に非アクティブ電子マネー５００Ａを送信する。受取端末２０は、キャリアネットワーク１００を介して接続している受取端末２０に非アクティブ電子マネー５００Ａを送信する。尚、受取端末２０と検証サーバ３０との接続が切断された後、管理サーバ４０からキャリアネットワーク１００を介して受取端末２０に非アクティブ電子マネー５００Ａが送信されても良い。

管理サーバ４０は、上述のステップＳ１５、Ｓ１６及びＳ１８と同様に、新たに発行した非アクティブ電子マネー５００Ａの証書ＩＤの登録、通知を行う（ステップＳ５２、Ｓ５３）。

検証サーバ３０は、証書ＩＤ Ｄ／Ｂ３８にある、古い証書ＩＤを新たな証書ＩＤによって上書き更新する（ステップＳ５４）。尚、ステップＳ５１において非アクティブ電子マネー５００Ａを中継する際、非アクティブ電子マネー５００Ａから証書ＩＤ５１２Ａ及び発行日時５１３Ａを取得して証書ＩＤ Ｄ／Ｂ３８を更新しても良い。

受取端末２０は、非アクティブ電子マネー５００Ａを受け取ると、管理サーバ公開鍵９３を用いて管理サーバ署名５０２Ａの検証を行う（ステップＳ５５）。これにより、非アクティブ電子マネー５００Ａが管理サーバ４０から正規に発行されたものであることが確認できる。署名検証において合格である場合、受取端末２０は、ステップＳ２０と同様に、メンバ鍵９４及びメンバ証明情報９６を用いてグループ署名を施し、通貨として機能するアクティブ電子マネー６００Ａを生成する（ステップＳ５６）。

ステップＳ４８において、検証サーバ３０は、受取端末２０しかわからないパスワードによってリフレッシュ要求元を確認しても良い。このパスワードは、ステップＳ３１からＳ３６におけるアクティブ電子マネー６００Ａの検証時に、受取端末２０が検証サーバ３０に設定することで利用できる。

アクティブ電子マネー６００Ａが他のサーバ、端末、又は信頼できないネットワークを経由している場合、経由先のサーバ、端末、又は信頼できないネットワークに証書ＩＤ５１３Ａが漏洩する危険がある。本発明では、リフレッシュ処理によって、保有するアクティブ電子マネー６００Ａの証書ＩＤ５１３Ａを変更できるため、証書ＩＤ５１３Ａが漏洩した場合においても、第３者による不正使用を防止することができる。

次に、図１６から図１９を参照して、本発明に係るアクティブ電子マネー６００Ａの決済処理（入金処理）について説明する

図１６を参照して、管理サーバ４０に設けられた電子マネー口座への入金処理の動作を説明する。受取端末２０は、保有するアクティブ電子マネー６００Ａを入金するため、キャリアネットワーク１００を介して管理サーバ４０に接続する。受取端末２０は、管理サーバ４０に対して決済要求を発行するとともに、アクティブ電子マネー６００ＡとユーザＩＤ９５を送信する（ステップＳ６１）。管理サーバ４０は、決済要求に応答して、アクティブ電子マネー６００Ａの検証要求を検証サーバ３０に発行するとともに、検証対象のアクティブ電子マネー６００Ａを送信する（ステップＳ６２）。検証サーバ３０は、ステップＳ３２及びステップＳ３３と同様に署名検証及び使用可否の検証を実行する（ステップＳ６３、Ｓ６４）。

管理サーバ４０は、検証サーバ３０から検証結果を受け取り（ステップＳ６５）、検証結果に基づき電子マネー口座Ｄ／Ｂ５１への入金処理を実行する（ステップＳ６６）。ここでは、アクティブ電子マネー６００Ａに記載された金額６１１Ａに応じて、送信されたユーザＩＤ９５に対応する口座が更新される。電子マネー口座Ｄ／Ｂ５１が更新されると、管理サーバ４０は、自身の証書ＩＤ Ｄ／Ｂ４９から入金したアクティブ電子マネー６００Ａの証書ＩＤ５１３Ａを削除し（ステップＳ６７）、当該証書ＩＤの消去要求を検証サーバ３０に発行する（ステップＳ６８）。この際、管理サーバ４０は、入金したアクティブ電子マネー６００Ａの電子証書ＩＤを、入金した端末のＩＤ（ここでは、受取端末２０のユーザＩＤ９５）とともにアーカイブデータベース（図示なし）に記録しても良い。これにより、電子マネーの使用者の履歴を管理することができる。又、この履歴情報は、定期的に消去されても良い。検証サーバ３０は、管理サーバ４０からの消去要求に応じて、証書ＩＤ Ｄ／Ｂ３８から当該証書ＩＤを削除する（ステップＳ６９）。これにより、検証サーバ３０は、管理サーバ４０から発行された全ての電子マネーのうち、現在流通している電子マネーに関する情報（証書ＩＤ）のみで電子マネーの使用可否を検証することとなる。又、管理サーバ４０は、電子マネー口座Ｄ／Ｂ５１を更新すると、決済要求に対する決済応答を受取端末２０に発行し（図示なし）、入金処理を終了する。又、管理サーバ４０は、入金されるアクティブ電子マネー６００Ａに含まれる使用限度額５１１Ａ及び金額６１１Ａに基づき、証書ＩＤ５１３から特定した送金端末１０の与信残高を更新しても良い。

ここでは、入金処理において、受取端末２０から管理サーバ４０に対し決済要求が発行された形態を説明したが、検証サーバ３０を経由して管理サーバ４０に対し決済要求が発行されても良い。この場合、検証サーバ３０は、トランザクション処理によって金額６１１Ａを管理サーバ４０の電子マネー口座Ｄ／Ｂ５１に入金する。尚、電子マネー口座５１は管理サーバ４０の外に設けられても良い。又、受取端末２０からの決済要求に応じて検証サーバ３０は、トランザクション処理によってアクティブ電子マネー６００Ａを、他の外部の電子マネー口座、金融機関における預金口座やクレジット口座、キャリアにおける課金口座に入金しても良い。

又、図１７に示すように、受取端末２０は、電子マネーをチャージ可能なＩＣカード８０（例えばＭＩＦＡＲＥ（登録商標）、ＦｅｌｉＣａ（登録商標）、ＥＬＷＩＳＥ（登録商標））を備えても良い。又、近距離無線通信回線１５は、ＩＣカード８０に内蔵されていても構わない。受取端末２０がＩＣカード８０を有している形態では、図１８に示すように、本発明による電子マネーシステムは、キャリアネットワーク１００に、グローバルネットワーク（例えばインターネット４００）を介して接続されるチャージサーバ６０を備えることが好ましい。本発明に係るチャージサーバ６０は、受取端末２０からの入金要求に応答して、当該受取端末２０のＩＣカード８０にアクティブ電子マネー６００Ａに記載された金額を入金する。

図１９を参照して、ＩＣカードへの入金処理の動作を説明する。受取端末２０は、保有するアクティブ電子マネー６００Ａを入金するため、キャリアネットワーク１００及びインターネット４００を介してチャージサーバ６０に接続する。受取端末２０は、チャージサーバ６０に対して決済要求を発行するとともに、アクティブ電子マネー６００ＡとユーザＩＤ９５を送信する（ステップＳ７１）。チャージサーバ６０は、決済要求に応答して、アクティブ電子マネー６００Ａの検証要求を検証サーバ３０に発行するとともに、検証対象のアクティブ電子マネー６００Ａを送信する（ステップＳ７２）。検証サーバ３０は、ステップＳ３２及びステップＳ３３と同様に署名検証及び使用可否の検証を実行する（ステップＳ７３、Ｓ７４）。

チャージサーバ６０は、検証サーバ３０から検証結果を受け取り（ステップＳ７５）、検証結果に基づきＩＣカード８０への入金処理を実行する（ステップＳ７６）。ここでは、チャージサーバ６０は、送信されたユーザＩＤ９５に対応するＩＣカード８０に更新命令を発行し、アクティブ電子マネー６００Ａに記載された金額６１１Ａをトランザクション処理によってＩＣカード８０へ入金する。入金が完了すると受取端末２０は更新応答をチャージサーバ６０に発行する（ステップＳ７８）。チャージサーバ６０は、更新応答に応じて、当該証書ＩＤの消去要求を検証サーバ３０に発行する（ステップＳ７９）。検証サーバ３０は、消去要求に応じて、証書ＩＤ Ｄ／Ｂ３８から当該証書ＩＤを削除する（ステップＳ８０）。チャージサーバ６０は、消去要求を発行すると、決済要求に対する決済応答を受取端末２０に発行し（図示なし）、入金処理を終了する。

ここでは、入金処理において、受取端末２０からチャージサーバ６０に対し決済要求が発行された形態を説明したが、検証サーバ３０を経由してチャージサーバ６０に対し決済要求が発行されても良い。

以上のように、アクティブ電子マネー６００Ａが自口座やＩＣカードに入金される際、検証サーバ３０内の証書ＩＤは消去される。例えば、アクティブ電子マネー６００Ａが二重使用された場合、すなわち、同じ証書ＩＤの複数の電子マネーが不正使用された場合、最初に決済要求されたアクティブ電子マネー６００Ａは入金されるが、後の決済要求については、証書ＩＤが登録されていないため、入金は拒否される。このように、本発明に係る電子マネーシステムは、電子マネーの不正使用を未然に防止することができる。

本実施の形態では、送金端末１０と受取端末２０とが同一のキャリアネットワークを利用する場合について説明したが、他のキャリアネットワークを利用する受取端末２０に対する送金も同様に実行できる。この場合、受取端末２０は、送金端末１０側のキャリアネットワーク１００に設けられた検証サーバ３０に対し、アクティブ電子マネー６００Ａとともに決済要求を発行する。検証サーバ３０は、アクティブ電子マネーを検証し、合格である場合、トランザクション処理により金額６１１Ａを受取端末２０側の電子マネー口座に入金する。この際、検証サーバ３０と、受取端末２０側の電子マネー口座とは秘匿性のある専用線で接続されることが好ましい。このように、他のキャリアネットワークへも、検証サーバ３０によって検証した後に入金することができる。

２．第２の実施の形態
図２０及び図２１を参照して、本発明による電子マネーシステムの第２の実施の形態を説明する。第２の実施の形態では、管理サーバ４０が発行する電子マネーを企業通貨（例えばポイント、商品券、チケット）として利用する電子マネーシステムを説明する。以下では、第１の実施の形態と同様の構成要素には、同様な符号を付して説明する。又、第１の実施の形態と同様な構成についてはその説明を省略し、異なる点のみを説明する。

第２の実施の形態における送金端末１０は企業サーバ等に適用され、キャリアが発行する電子マネーを企業通貨としてユーザ（受取端末２０）に発行する。この際、企業は、キャリアが発行する電子マネー（非アクティブポイント５００Ｂ）に使用条件を付加して、企業独自の企業通貨（アクティブポイント６００Ｂ）として使用する。これにより、ユーザは、複数の企業が発行する独自の企業通貨を利用でき、且つこれらの企業通貨を共通の口座（キャリアが管理する電子マネー口座Ｄ／Ｂ５１）に入金できる。例えば、ユーザは異なる企業の発行する企業通貨を、キャリアが発行する電子マネー（通常、加入者の通信使用量に応じて提供されるポイント）として貯めることができる。この場合、企業は、キャリアネットワーク１００の加入者を顧客として取り込むことができる。

図２０及び図２１を参照して、送金端末１０が受取端末２０に発行する企業通貨について説明する。ここで、管理サーバ４０は第１の実施の形態における非アクティブ電子マネー５００Ａに替えて図２０に示す非アクティブポイント５００Ｂを発行し、送金端末１０は、非アクティブポイント５００Ｂを有効化して図２１に示すアクティブポイント６００Ｂを生成する。

図２０は、管理サーバ４０が発行する非アクティブポイントの一例である。送金端末１０は、ポイント数を指定した電子マネーの発行要求を管理サーバ４０に発行する。管理サーバ４０は、電子マネー発行要求に応答して非アクティブポイント５００Ｂを生成する。管理サーバ４０は、指定されたポイント数５１１Ｂ、発行日時５１２Ｂ、証書ＩＤ５１３Ｂを含む証書情報５０１Ｂに対し、管理サーバ秘密鍵９２によって管理サーバ署名５０２Ｂを施し、非アクティブポイント５００Ｂを生成する。ここで、発行日時５１２Ｂは、規定のフォーマットの文字列のみであっても、正確な時刻情報によって証書情報５０１Ｂの生成時刻を保証するタイムスタンプでも構わない。第２の実施の形態における管理サーバ４０は、与信残高Ｄ／Ｂ５０に替えて、企業（送金端末１０）毎に利用可能なポイントを管理するポイントＤ／Ｂを保持することが好ましい。ポイントＤ／Ｂには、キャリアと契約した企業が利用可能なポイント数が設定される。非アクティブポイント５００Ｂを発行する際、発行先の送金端末１０に対応するポイントＤ／Ｂからポイント数５１１Ｂが減じられる。送金端末１０を運用する企業は、使用したポイント数に応じた対価を、定期的又は任意な時期にキャリアに支払い、ポイントＤ／Ｂの使用限度数を復帰することができる。ここで、非アクティブポイント５００Ｂに使用されるポイントは、キャリアネットワーク１００の使用量に応じて加入者に提供されるポイントであることが好ましい。

図２１は、送金端末１０によって有効化されたアクティブポイント６００Ｂの一例である。送金端末１０は、電子証書としての非アクティブ電子ポイント５００Ｂを元に、通貨として機能するアクティブ電子ポイント６００Ｂを生成する。送金端末１０の電子証書有効化部１７３は、非アクティブ電子ポイント５００Ｂに利用条件６０１Ｂを付加した情報（メッセージ）に対し、メンバ鍵９４を用いてグループ署名６０２Ｂを施し、図２１に示すようなアクティブ電子ポイント６００Ｂを生成する。利用条件６０１Ｂとして設定される情報は、アクティブ電子ポイント６００Ｂを利用可能な店舗に関する情報（利用可能店舗６１１Ｂ）や、アクティブ電子マネー６００Ａの使用可能期限を決める有効期限６１２Ｂである。又、当該アクティブ電子ポイント６００Ｂの検証先となる検証サーバ３０のアドレスが含まれていても良い。アクティブポイント６００Ｂの通貨価値はポイント数５１１Ｂで決まる。又、利用条件６０１Ｂに設定される条件として、店舗情報６１１Ｂや有効期限６１２Ｂとは異なる、電子マネーの利用を制限する条件（アクティブ電子ポイントと交換可能な商品やサービスに関する情報）を利用条件６０１Ａに付加しても構わない。

受取端末２０は、送金端末１０から発行されるアクティブ電子ポイント６００Ｂの署名を検証した後、他の受取端末２０に送信（送金）して利用する。他の受取端末２０は、アクティブ電子ポイント６００Ｂの管理サーバ署名５０２Ｂ及びグループ署名６０２Ｂを検証し、利用条件６０１Ａに適合しているかを検証する。ここでは、店舗情報６１１Ｂに自身が含まれているかや、有効期限６１２Ｂを超えていないかが検証される。尚、アクティブ電子ポイント６００Ｂの利用可否の検証を検証サーバ３０に依頼しても構わない。この場合、検証サーバ３０には、利用店舗を識別する情報が登録されていることが好ましい。検証サーバ３０は、検証対象のアクティブ電子ポイント６００Ｂに含まれる店舗情報６１１Ｂと検証依頼元から通知される店舗情報とを照合して当該アクティブ電子ポイント６００Ｂの利用可否を判定する。

受取端末２０は、上述の決済処理と同様に、取得したアクティブ電子ポイント６００Ｂを管理サーバ４０の電子口座Ｄ／Ｂ５１に入金する。この際、管理サーバ４０は、入金対象のアクティブポイント６００Ｂのポイント数６１１Ｂに相当する額（ポイント数）を当該受取端末２０の電子マネー口座に入金する。

例えば、送金端末１０がＰＯＳ（Ｐｏｉｎｔ ｏｆ Ｓａｌｅｓ）端末であり、当該ＰＯＳ端末を利用する企業を１つのグループとして管理サーバ４０に登録される場合、管理サーバ４０は、どの店舗のどのＰＯＳ端末がどのようなポイントを発行したかをトレースできる。又、企業は、管理サーバ４０からグループに登録されたＰＯＳ端末のポイント発行状況を取得することで、企業経営や市場調査に資する情報を得ることができる。更に、グループ署名によって受取端末２０に対するＰＯＳ端末の匿名性が保たれているため、受取端末２０（ポイントを取得した客）は、どのＰＯＳ端末からポイントが発行されたかを知ることができない。

本発明では、アクティブ電子ポイント６００Ｂへの署名は、ＰＯＳ端末固有のメンバ鍵９５を利用して行われる。このため、メンバ鍵９５が漏洩した場合、当該ＰＯＳ端末のメンバ鍵９５のみを更新すれば良く、他のＰＯＳ端末のメンバ鍵９５を更新する必要はない。又、不正に利用されたアクティブ電子ポイント６００Ｂの発行元を管理サーバ４０においてトレースしているため、メンバ鍵９５の漏洩元のＰＯＳ端末を特定することができる。更に、暗号用グループ秘密鍵９０Ｂを保有する端末（ここでは検証サーバ３０）以外の端末は、アクティブ電子ポイント６００Ｂを有効化したＰＯＳ端末に関する情報を、アクティブ電子ポイント６００Ｂから取得できない。このため、ＰＯＳ端末の成りすましを防止できる。

上述の効果はＰＯＳ端末を一例にして説明したがこれに限らないのは言うまでもない。又、第１の実施の形態においても同様な効果が得られるのは言うまでもない。

本発明による電子マネーシステムによれば、例えば、電子マネー口座Ｄ／Ｂ５１をキャリアの課金システムに適用し、電子マネー口座Ｄ／Ｂ５１に入金された電子マネーや電子ポイントをユーザに対する通信料金の一部又は全部として利用することができる。又、電子マネー口座Ｄ／Ｂ５１に入金された電子マネーや電子ポイントを、図示しない銀行に入金（現金への換金）することも可能である。この場合、キャリアがユーザの指定取引金融機関との間で月次などの定期的に行う決済や、ユーザが指定する金融機関との間で行うデビット決済、ユーザが指定するプリペイド式電子マネーによる決済等がある。更に、電子マネー口座Ｄ／Ｂ５１内の電子マネーを他のクレジット口座へ移動することも可能である。

更に、本発明に係る管理サーバ４０及び検証サーバ３０は、キャリアによって運用することが好適である。信用の高いキャリアによって電子マネーの発行機関と検証機関を一元的に運用することで、複数の企業による運用に比べ、電子マネーの信頼性が高くなる。又、キャリアは、秘匿性が高く、端末を識別するための加入者情報を管理している。これをユーザＩＤ９５として用いて送金端末１０を管理することで、グループ署名による秘匿性を堅持することができる。

以上のように、本発明による電子マネーシステムは、電子マネーや電子ポイントを有効化するための署名としてグループ署名を利用しているため、電子マネーや電子ポイントを取引きする端末間における端末情報（個人情報）の流出を防ぐとともに、発行された電子マネーや電子ポイントと、その送金元又は発行元の端末（送金端末１０）とを紐つけて管理することができる。又、検証サーバ３０は、現在流通している電子マネーの証書ＩＤによって、電子マネーの使用可否を判定する。このため、使用可否判定に利用する情報量を従来に比べ少なくすることができる。

以上、本発明の実施の形態を詳述してきたが、具体的な構成は上記実施の形態に限られるものではなく、本発明の要旨を逸脱しない範囲の変更があっても本発明に含まれる。本発明に係る電子マネーを取り扱う端末は、送金端末１０及び受取端末２０の両方の機能を有しても構わない。又、管理サーバ秘密鍵９２が署名用グループ秘密鍵９０Ａと同一であっても良く、管理サーバ公開鍵９３が、署名用グループ公開鍵９１Ｂと同一であっても良い。この場合、鍵管理の手間と電子証書を検証する手間を一部省略することができる。

更に、送金端末１０は、アクティブ電子マネー６００Ａを複製し、複数の受取端末２０に送信しても良い。この場合、複数の受取端末２０のうち、最初に検証サーバ３０においてアクティブ電子マネー６００Ａの検証を行った受取端末２０のみが当該アクティブ電子マネー６００Ａを利用することができる。例えば、送金端末１０を持つユーザが、自宅の複数の部屋に設置された受取端末２０を用いてインターネットショッピングを行う場合、全ての受取端末２０にアクティブ電子マネー６００Ａを送信しておくことで、特定の受取端末６００Ａに制約されず所望の部屋で買い物をすることができる。この場合、買い物に利用した受取端末２０以外の受取端末２０に格納されたアクティブ電子マネー６００Ａは、認証サーバ３０において認証されないので利用できなくなる。

通常、受取端末２０は、アクティブ電子マネー６００Ａの取得直後に、検証サーバ３０において利用可否の検証を受け、その結果に応じてアクティブ電子マネー６００Ａの受取完了又は受取失敗を送金端末１０に通知する。しかし、受取端末２０の使用者の中には、検証サーバ３０から利用可能の通知を受けても、アクティブ電子マネー６００Ａを取得できないと、虚偽の通知をする者もいる。このような場合、送金端末１０は、送金前にアクティブ電子マネー６００Ａを複製し、受取失敗の通知を受領後、複製したアクティブ電子マネー６００Ａを検証サーバ３０において検証することで、受取端末２０の虚偽を見破ることができる。例えば、送金端末１０の要求による検証において、利用可能と判定された場合、受取端末２０がアクティブ電子マネー６００Ａを検証サーバ３０において検証していない、又は検証できなかったことがわかる。前者の場合、受取端末２０は、アクティブ電子マネー６００Ａを正しく受け取っているが、検証済みであることを装っている可能性が考えられる。後者の場合、アクティブ電子マネー６００を正しく受け取れなかった可能性が考えられる。しかし、両者とも、送金端末１０による検証によって、送金済みのアクティブ電子マネー６００Ａは利用できなくなるので、新たな証書ＩＤ５１３Ａを有するアクティブ電子マネー６００Ａを受取端末２０に送金することで、２重送金を防止しつつ受取失敗を解消できる。又、送金端末１０の要求による検証において、利用不可と判定された場合、当該アクティブ電子マネー６００Ａが検証サーバ３０において検証済みであることがわかる。この場合、検証において利用可能通知を受領した受取端末２０が、利用できないと虚偽の報告をした場合と、他の端末によって不正利用された場合とが考えられる。どの端末がアクティブ電子マネー６００Ａを不正使用したかは、検証サーバ３０における証書ＩＤ Ｄ／Ｂ３８から抽出したユーザＩＤを用いて、管理サーバ４０において特定することができる。

図１は、本発明による電子マネーシステムの第１の実施の形態における構成を示す図である。 図２は、本発明に係る送金端末用プログラムの機能を示す図である。 図３は、本発明に係る受取端末用プログラムの機能を示す図である。 図４は、本発明に係る検証サーバが備える記憶装置の構成を示す図である。 図５は、本発明に係る検証サーバ用プログラムの機能を示す図である。 図６は、本発明に係る管理サーバが備える記憶装置の構成を示す図である。 図７は、本発明に係る管理サーバ用プログラムの機能を示す図である。 図８は、本発明による電子マネーシステムのグループ登録処理及び公開鍵取得処理を示すシーケンス図である。 図９は、本発明による電子マネーシステムにおける各構成要素が保有する鍵の種類を示す図である。 図１０は、本発明による電子マネーシステムにおける電子マネーの発行及び送金処理の動作を示すシーケンス図である。 図１１は、本発明による非アクティブ電子マネーの構成を示す図である。 図１２は、本発明によるアクティブ電子マネーの構成を示す図である。 図１３は、本発明による電子マネーシステムにおけるアクティブ電子マネー検証処理の動作を示すシーケンス図である。 図１４は、本発明による電子マネーシステムにおけるロック処理の動作を示すシーケンス図である。 図１５は、本発明による電子マネーシステムにおけるリフレッシュ処理の動作を示すシーケンス図である。 図１６は、本発明による電子マネーシステムにおけるアクティブ電子マネーの入金処理の動作の一例を示すシーケンス図である。 図１７は、ＩＣカードを有した受取端末を具備する電子マネーシステムの構成を示す図である。 図１８は、ＩＣカードを有した受取端末の構成を示す図である。 図１９は、本発明による電子マネーシステムにおけるアクティブ電子マネーの入金処理の動作の一例を示すシーケンス図である。 図２０は、本発明による電子マネーシステムにおける非アクティブポイントの構成を示す図である。 図２１は、本発明による電子マネーシステムにおけるアクティブポイントの構成を示す図である。

符号の説明

１０：送金端末
２０：受取端末
３０：検証サーバ
４０：管理サーバ
６０：チャージサーバ
８０：ＩＣカード
１００：キャリアネットワーク
２００、３００：通信回線
１１、２１、３１、４１：ＣＰＵ
１２、２２、３２、４２：ＲＡＭ
１３、２３、３３、４３：記憶装置
１４、２４、３４、４４：Ｉ／Ｏインタフェース
１５、２５、３５、４５：近距離通信インタフェース
１６、２６、３６、４６：バス
３８、４９：証書ＩＤ Ｄ／Ｂ
４８：グループＤ／Ｂ
５０：与信残高Ｄ／Ｂ
５１：電子マネー口座Ｄ／Ｂ
９０：グループ秘密鍵
９０Ａ：署名用グループ秘密鍵
９０Ｂ：暗号用グループ秘密鍵
９１：グループ公開鍵
９１Ａ：署名用グループ公開鍵
９１Ｂ：暗号用グループ公開鍵
９２：管理サーバ秘密鍵
９３：管理サーバ公開鍵
９４：メンバ鍵
９６：メンバ証明情報
１７：送金端末用プログラム
１７１：電子証書要求部
１７２：管理サーバ署名検証部
１７３：電子証書有効化部
２７：受取端末用プログラム
２７１：グループ署名検証部
２７２：管理サーバ署名検証部
２７３：電子証書利用部
３７：検証サーバ用プログラム
３７１：利用状況検証部
３７２：利用条件検証部
３７３：グループ署名検証部
３７４：管理サーバ署名検証部
４７：管理サーバ用プログラム
４７１：グループ登録部
４７２：電子証書発行部
４７３：与信残高管理部
４７４：電子マネー口座管理部
５００Ａ：非アクティブ電子マネー（非アクティブ電子証書）
５００Ｂ：非アクティブポイント（非アクティブ電子証書）
６００Ａ：アクティブ電子マネー（アクティブ電子証書）
６００Ｂ：アクティブポイント（アクティブ電子証書）
５０１Ａ、５０１Ｂ：証書情報
５０２Ａ、５０２Ｂ：管理サーバ署名
５１１Ａ：使用限度額
５１２Ａ、５１２Ｂ：発行日時
５１３Ａ、５１３Ｂ：証書ＩＤ
５１１Ｂ：ポイント数
６０１Ａ、６０１Ｂ利用条件
６０２Ａ：グループ署名
６０２Ｂ：グループ署名（企業署名）
６１１Ａ：金額
６１２Ａ、６１２Ｂ：有効期限
６１１Ｂ：利用可能店舗

Claims (25)

1. 管理サーバと、検証サーバと、送金端末と、受取端末とを備える電子マネーシステムにおいて、
   （Ａ）前記管理サーバが、前記送金端末の要求に応じて、証書ＩＤを含む非アクティブ電子証書を発行し、前記証書ＩＤを前記検証サーバに通知するステップと、
   （Ｂ）前記送金端末が、前記非アクティブ電子証書に対しグループ署名を施してアクティブ電子証書を生成するステップと、
   （Ｃ）前記受取端末が、前記送金端末から取得した前記アクティブ電子証書の前記グループ署名を、グループ公開鍵を用いて検証するステップと、
   （Ｄ）前記検証サーバが、前記（Ａ）ステップにおいて通知された証書ＩＤと、前記（Ｃ）ステップにおいて検証されたアクティブ電子証書に含まれる証書ＩＤとを照合し、前記アクティブ電子証書の使用可否を検証するステップと、
   を具備する電子マネー取引方法。
2. 請求項１に記載の電子マネー取引方法において、
   前記管理サーバが、前記（Ｄ）ステップにおいて使用可能と判定されたアクティブ電子証書の示す金額に基づいて、前記受取端末に対応する口座の残金を更新するステップを更に具備する電子マネー取引方法。
3. 請求項２に記載の電子マネー取引方法において、
   前記検証サーバが、前記管理サーバから通知された証書ＩＤを証書ＩＤデータベースに記録するステップを更に具備し、
   前記（Ｄ）ステップは、前記（Ｃ）ステップにおい検証されたアクティブ電子証書に含まれる証書ＩＤが前記証書ＩＤデータベースに記録されていない場合、前記アクティブ電子証書の使用を禁止するステップを備える
   電子マネー取引方法。
4. 請求項３に記載の電子マネー取引方法において、
   前記検証サーバが、前記口座の更新に応じて前記記録された証書ＩＤを消去するステップを更に具備する電子マネー取引方法。
5. 請求項１から４いずれか１項に記載の電子マネー取引方法において、
   前記受取端末が、自身が保有するアクティブ電子証書のロック要求を発行するステップと、
   前記検証サーバが、前記ロック要求に応答して、前記アクティブ電子証書の利用を禁止するステップと、
   を更に具備する電子マネー取引方法。
6. 請求項１から５いずれか１項に記載の電子マネー取引方法において、
   前記受取端末が、自身が保有するアクティブ電子証書のリフレッシュ要求を発行するステップと、
   前記管理サーバが、前記リフレッシュ要求に応答して、前記アクティブ電子証書の証書ＩＤを変更するステップと、変更後の証書ＩＤを前記検証サーバに通知するステップと、
   を更に具備する電子マネー取引方法。
7. 請求項１から６いずれか１項に記載の電子マネー取引方法において、
   前記管理サーバが、前記非アクティブ電子証書の証書ＩＤと、前記非アクティブ電子証書の発行先の前記送金端末とを対応付けて記録するステップを更に具備する電子マネー取引方法。
8. 請求項１から７いずれか１項に記載の電子マネー取引方法において、
   前記（Ａ）ステップは、前記管理サーバが、前記証書ＩＤを含む証書情報に対し、管理サーバ秘密鍵を用いて管理サーバ署名を施すステップを備え、
   前記（Ｂ）ステップは、前記送金端末が、前記管理サーバから取得した管理公開鍵を用いて前記管理サーバ署名を検証するステップを備える
   電子マネー取引方法。
9. 請求項１から８いずれか１項に記載の電子マネー取引方法において、
   前記（Ｂ）ステップは、前記送金端末が、前記アクティブ電子証書の利用条件を設定するステップを備え、
   前記（Ｃ）ステップは、前記検証サーバが、前記利用条件に基づいて前記アクティブ電子証書の利用可否を検証するステップを備える
   電子マネー取引方法。
10. 請求項９に記載の電子マネー取引方法において、
    前記利用条件は、前記アクティブ電子証書の利用可能な有効期限である電子マネー取引方法。
11. 請求項１から１０いずれか１項に記載の電子マネー取引方法において、
    前記送金端末が、前記非アクティブ電子証書の使用限度額を指定するステップと、
    前記管理サーバが、前記使用限度額を前記非アクティブ電子証書に設定するステップと、
    前記管理サーバが、前記使用限度額に基づき前記送金端末の与信残高を更新するステップと、
    を更に具備する電子マネー取引方法。
12. 請求項１から１０いずれか１項に記載の電子マネー取引方法において、
    前記送金端末が、前記非アクティブ電子証書の価値を決めるポイント数を指定するステップと、
    前記管理サーバが、前記ポイント数を前記非アクティブ電子証書に設定するステップと、
    前記管理サーバが、前記ポイント数に基づき前記送金端末のポイント残高を更新するステップと、
    を更に具備する電子マネー取引方法。
13. ネットワークを介して相互に接続される管理サーバと、検証サーバと、送金端末と、受取端末とを具備し、
    前記管理サーバは、前記送金端末の要求に応じて、証書ＩＤを含む非アクティブ電子証書を発行し、前記証書ＩＤを前記検証サーバに通知し、
    前記送金端末は、前記非アクティブ電子証書に対しグループ署名を施してアクティブ電子証書を生成し、
    前記受取端末は、前記送金端末から取得した前記アクティブ電子証書の前記グループ署名を、グループ公開鍵を用いて検証し、
    前記検証サーバは、前記管理サーバから通知された証書ＩＤと、前記受取端末で検証されたアクティブ電子証書に含まれる証書ＩＤとを照合し、前記アクティブ電子証書の使用可否を検証する
    電子マネーシステム。
14. 請求項１３に記載の電子マネーシステムにおいて、
    前記管理サーバは、受取端末毎の電子マネー口座の残高が記録された電子マネー口座データベースを備え、前記検証サーバにおいて使用可能と判定されたアクティブ電子証書の示す金額に基づいて、前記受取端末に対応する口座の残金を更新する
    電子マネーシステム。
15. 請求項１４に記載の電子マネーシステムにおいて、
    前記検証サーバは、前記管理サーバから通知された証書ＩＤを記録する証書ＩＤデータベースを備え、検証要求されたアクティブ電子証書に含まれる証書ＩＤが前記証書ＩＤデータベースに記録されていない場合、前記アクティブ電子証書の使用を禁止する
    電子マネーシステム。
16. 請求項１５に記載の電子マネーシステムにおいて、
    前記検証サーバは、前記電子マネー口座データベースの更新に応じて前記証書ＩＤデータベースに記録された証書ＩＤを消去する
    電子マネーシステム。
17. 請求項１３から１６いずれか１項に記載の電子マネーシステムにおいて、
    前記受取端末は、自身が保有するアクティブ電子証書のロック要求を発行し、
    前記検証サーバは、前記ロック要求に応答して、前記アクティブ電子証書の利用を禁止する
    電子マネーシステム。
18. 請求項１３から１７いずれか１項に記載の電子マネーシステムにおいて、
    前記受取端末は、自身が保有するアクティブ電子証書のリフレッシュ要求を発行し、
    前記管理サーバは、前記リフレッシュ要求に応答して、前記アクティブ電子証書の証書ＩＤを変更し、変更後の証書ＩＤを前記検証サーバに通知する
    電子マネーシステム。
19. 請求項１３から１８いずれか１項に記載の電子マネーシステムにおいて、
    前記管理サーバは、前記非アクティブ電子証書の証書ＩＤと、前記非アクティブ電子証書の発行先の前記送金端末とを対応付けて記録する証書ＩＤデータベースを備える
    電子マネーシステム。
20. 請求項１３から１９いずれか１項に記載の電子マネーシステムにおいて、
    前記管理サーバは、前記証書ＩＤを含む証書情報に対し、管理サーバ秘密鍵を用いて管理サーバ署名を施して前記非アクティブ電子証書を生成し、
    前記送金端末は、前記管理サーバから取得した管理公開鍵を用いて前記管理サーバ署名を検証する
    電子マネーシステム。
21. 請求項１３から２０いずれか１項に記載の電子マネーシステムにおいて、
    前記送金端末は、前記アクティブ電子証書の利用条件を設定し、
    前記検証サーバは、前記利用条件に基づいて前記アクティブ電子証書の利用可否を検証する
    電子マネーシステム。
22. 請求項２１に記載の電子マネーシステムにおいて、
    前記利用条件は、前記アクティブ電子証書の利用可能な有効期限である電子マネーシステム。
23. 請求項１３から２２いずれか１項に記載の電子マネーシステムにおいて、
    前記管理サーバは、前記送金端末の与信残高を記録する与信残高データベースを備え、
    前記送金端末は、前記非アクティブ電子証書の使用限度額を指定し、
    前記管理サーバは、前記使用限度額を前記非アクティブ電子証書に設定し、前記使用限度額に基づき前記送金端末の与信残高を更新する
    電子マネーシステム。
24. 請求項１３から２２いずれか１項に記載の電子マネーシステムにおいて、
    前記管理サーバは、前記送金端末の使用可能ポイント数を記録するポイント残高データベースを備え、
    前記送金端末は、前記非アクティブ電子証書の価値を決めるポイント数を指定し、
    前記管理サーバは、前記ポイント数を前記非アクティブ電子証書に設定し、前記ポイント数に基づき前記送金端末のポイント残高を更新する
    電子マネーシステム。
25. 請求項１３から２４いずれか１項に記載の電子マネーシステムにおいて、
    前記送金端末と前記受取端末は、近距離無線通信回線を介して接続し、
    前記送金端末は、前記アクティブ電子証書を前記近距離無線通信回線を介して前記受取端末に送信する
    電子マネーシステム。

Images