(57)【特許請求の範囲】
【請求項１】
送金元口座から送金先口座へ電子バリューを送金する際に、送金元ユーザと送金先ユーザのいずれでもない第三者により該送金先ユーザによる利用に関する適用条件が指定された電子チケットを該送金先ユーザに関連付けてチケット記憶手段に記憶させるチケット登録手段と、
前記送金先ユーザによる前記適用条件を満たす前記電子チケットを伴った電子バリューの利用に対し、前記電子チケットの内容に相当する額の少なくとも一部を前記第三者に負担させるための処理を実行する精算実行手段と、
を備え、
前記チケット登録手段が、前記送金元ユーザの指定に応じて、前記送金元ユーザにより指定された送金要求額の少なくとも一部が前記電子チケットの内容に相当する額の少なくとも一部となるという、前記送金元ユーザによるバリューの送金に関する制限が設けられた場合に限り、前記電子チケットを登録し、
前記送金要求額からその一部を減額して得られる金額を前記送金元口座から前記送金先口座へ移転される電子バリューの金額とすること
を特徴とする電子マネーサーバ。
【請求項２】
前記送金先口座に関連付けて履歴記憶手段に記憶される前記送金先ユーザの電子マネー利用履歴が示す前記送金先ユーザの電子マネー利用傾向に基づいて、該電子マネー利用傾向に適する適用条件が指定された候補チケットを選定する選定手段をさらに備え、
前記チケット登録手段が、前記選定手段により選定された前記候補チケットの中から指定される１又は複数の電子チケットを前記チケット記憶手段に記憶させる、ことを特徴とする請求項１記載の電子マネーサーバ。
【請求項３】
前記選定手段により選定された前記候補チケットの内容を前記送金先ユーザに提示する第１提示手段をさらに備え、
前記チケット登録手段が、前記第１提示手段により提示された候補チケットの中から前記送金先ユーザにより指定される１又は複数の電子チケットを前記チケット記憶手段に記憶させる、ことを特徴とする請求項２記載の電子マネーサーバ。
【請求項４】
前記選定手段により選定された候補チケットの内容を前記送金元ユーザに提示する第２提示手段をさらに備え、
前記チケット登録手段が、前記第２提示手段により提示された候補チケットの中から前記送金元ユーザにより１の電子チケットが指定された場合は当該１の電子チケットを前記チケット記憶手段に記憶させ、前記第２提示手段により提示された電子チケットの中から前記送金元ユーザにより１の電子チケットが指定されなかった場合は前記第１提示手段により提示された候補チケットの中から前記送金先ユーザにより指定される１又は複数の電子チケットを前記チケット記憶手段に記憶させる、ことを特徴とする請求項３記載の電子マネーサーバ。
【請求項５】
前記選定手段が、前記履歴記憶手段に記憶される前記送金先ユーザの電子マネー利用履歴から見出される該送金先ユーザの活動エリアで少なくとも利用可能とする適用条件が指定された前記電子チケットを選定する、ことを特徴とする請求項２から請求項４までのいずれか１項に記載の電子マネーサーバ。
【請求項６】
前記各電子チケットには、前記第三者により、さらに、送金要求額から原資に組み入れられるべき控除金額又はその算定式が指定されており、
前記選定手段が、前記控除金額が前記送金要求額に所定の係数を乗じて得られる金額以内に収まるように、前記候補チケットを選定する、ことを特徴とする請求項２から請求項５までのいずれか１項に記載の電子マネーサーバ。
【請求項７】
前記送金先ユーザ又は前記送金元ユーザにより指定された前記所定の係数の増加要求を取得する増加要求取得手段をさらに備え、
前記選定手段が、前記控除金額が前記送金要求額に前記増加後の所定の係数を乗じて得られる金額以内に収まるように、前記候補チケットを選定する、ことを特徴とする請求項６記載の電子マネーサーバ。
【請求項８】
前記精算実行手段が、さらに、前記送金先ユーザにより前記適用条件を満たす電子マネーの利用がなされた場合に、前記送金元口座の残高を増額させるための原資を前記第三者に負担させるための処理を実行する、ことを特徴とする請求項１から請求項７までのいずれか１項に記載の電子マネーサーバ。
【請求項９】
送金元口座から送金先口座へ電子バリューを送金する際に、送金元ユーザと送金先ユーザのいずれでもない第三者により該送金先ユーザによる利用に関する適用条件が指定された電子チケットを該送金先ユーザに関連付けてチケット記憶手段に記憶させるチケット登録ステップと、
前記送金先ユーザによる前記適用条件を満たす前記電子チケットを伴った電子バリューの利用に対し、前記電子チケットの内容に相当する額の少なくとも一部を前記第三者に負担させるための処理を実行する精算実行ステップと、
を含み、
前記チケット登録ステップで、前記送金元ユーザの指定に応じて、前記送金元ユーザにより指定された送金要求額の少なくとも一部が前記電子チケットの内容に相当する額の少なくとも一部となるという、前記送金元ユーザによるバリューの送金に関する制限が設けられた場合に限り、前記電子チケットを登録し、
前記送金要求額からその一部を減額して得られる金額を前記送金元口座から前記送金先口座へ移転される電子バリューの金額とすることを特徴とするコンピュータによる電子マネー送金方法。
【請求項１０】
送金元口座から送金先口座へ電子バリューを送金する際に、送金元ユーザと送金先ユーザのいずれでもない第三者により該送金先ユーザによる利用に関する適用条件が指定された電子チケットを該送金先ユーザに関連付けてチケット記憶手段に記憶させるチケット登録機能と、
前記送金先ユーザによる前記適用条件を満たす前記電子チケットを伴った電子バリューの利用に対し、前記電子チケットの内容に相当する額の少なくとも一部を前記第三者に負担させるための処理を実行する精算実行機能と、
前記チケット登録機能で、前記送金元ユーザの指定に応じて、前記送金元ユーザにより指定された送金要求額の少なくとも一部が前記電子チケットの内容に相当する額の少なくとも一部となるという、前記送金元ユーザによるバリューの送金に関する制限が設けられた場合に限り、前記電子チケットを登録し、
前記送金要求額からその一部を減額して得られる金額を前記送金元口座から前記送金先口座へ移転される電子バリューの金額とすること
をコンピュータに実現させるためのプログラム。
【請求項１１】
送金元口座から送金先口座へ電子バリューを送金する際に、送金元ユーザと送金先ユーザのいずれでもない第三者により該送金先ユーザによる利用に関する適用条件が指定された電子チケットを該送金先ユーザに関連付けてチケット記憶手段に記憶させるチケット登録機能と、
前記送金先ユーザによる前記適用条件を満たす前記電子チケットを伴った電子バリューの利用に対し、前記電子チケットの内容に相当する額の少なくとも一部を前記第三者に負担させるための処理を実行する精算実行機能と、
前記チケット登録機能で、前記送金元ユーザの指定に応じて、前記送金元ユーザにより指定された送金要求額の少なくとも一部が前記電子チケットの内容に相当する額の少なくとも一部となるという、前記送金元ユーザによるバリューの送金に関する制限が設けられた場合に限り、前記電子チケットを登録し、
前記送金要求額からその一部を減額して得られる金額を前記送金元口座から前記送金先口座へ移転される電子バリューの金額とすること
をコンピュータに実現させるためのプログラムを記録したコンピュータ読取可能な記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、電子マネーサーバ、電子マネー送金方法、プログラム及び記録媒体に関する。
【背景技術】
【０００２】
近年、電子マネーの使用が広く普及してきている。電子マネーでは、バリューと呼ばれる金額情報を貨幣価値に対応させ、バリュー残高を増減することにより資金決済を行う。
一般に、携帯端末（又は電子マネーカード）に内蔵又は装着されたＩＣモジュールにバリューの残高を保持する方式は、ストアードバリュー型と呼ばれている。【０００３】
ストアードバリュー型の電子マネーでは、決済端末は、電子マネーサーバに接続せずに、決済処理をユーザのＩＣモジュール３０との間でローカルに完結させ、取引履歴をログデータとして記録しておく。そして、後ほど、定期、又は不定期にログデータを一括して電子マネーサーバに送信することで、事後的に同期を取るようになっている。
一方、近年、ネットワークの通信能力の向上に伴い、決済端末と電子マネーサーバが同期を取ることで、電子マネーサーバでバリューを管理し、サーバ側で決済処理を行うサーバ管理型のシステムも知られるようになってきた。今後はネットワークインフラが整備されていくに連れて、このようなサーバ管理型のシステムが徐々に普及していくことが予想される。【０００４】
従来、個人間で金銭的価値を送金する手段として、銀行振込がしばしば利用されてきた。一方、近年では、個人間でストアードバリュー型の電子マネーを送金するサービスが提案されている（例えば、特許文献１参照）。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００４−２７２４７０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
普通預金口座の残高には現金への即時換金性があるから、銀行振込により送金された金銭的価値にはほとんど制約がない。これに対し、電子マネーの残高には基本的に換金性がない上に、電子マネーによる決済は加盟店に限定される。そのため、電子マネーによる個人間の送金サービスを広く普及させるには、銀行振込では実現できないような付加価値が求められる。
本発明の目的は、従来にはない付加価値を有する電子マネー送金サービスを提供することである。
【課題を解決するための手段】
【０００７】
請求項１記載の発明では、送金元口座から送金先口座へ電子バリューを送金する際に、送金元ユーザと送金先ユーザのいずれでもない第三者により該送金先ユーザによる利用に関する適用条件が指定された電子チケットを該送金先ユーザに関連付けてチケット記憶手段に記憶させるチケット登録手段と、前記送金先ユーザによる前記適用条件を満たす前記電子チケットを伴った電子バリューの利用に対し、前記電子チケットの内容に相当する額の少なくとも一部を前記第三者に負担させるための処理を実行する精算実行手段と、を備え、前記チケット登録手段が、前記送金元ユーザの指定に応じて、前記送金元ユーザにより指定された送金要求額の少なくとも一部が前記電子チケットの内容に相当する額の少なくとも一部となるという、前記送金元ユーザによるバリューの送金に関する制限が設けられた場合に限り、前記電子チケットを登録し、前記送金要求額からその一部を減額して得られる金額を前記送金元口座から前記送金先口座へ移転される電子バリューの金額とすることを特徴とする電子マネーサーバを提供する。
請求項２記載の発明では、前記送金先口座に関連付けて履歴記憶手段に記憶される前記送金先ユーザの電子マネー利用履歴が示す前記送金先ユーザの電子マネー利用傾向に基づいて、該電子マネー利用傾向に適する適用条件が指定された候補チケットを選定する選定手段をさらに備え、前記チケット登録手段が、前記選定手段により選定された前記候補チケットの中から指定される１又は複数の電子チケットを前記チケット記憶手段に記憶させる、ことを特徴とする請求項１記載の電子マネーサーバを提供する。
請求項３記載の発明では、前記選定手段により選定された前記候補チケットの内容を前記送金先ユーザに提示する第１提示手段をさらに備え、前記チケット登録手段が、前記第１提示手段により提示された候補チケットの中から前記送金先ユーザにより指定される１又は複数の電子チケットを前記チケット記憶手段に記憶させる、ことを特徴とする請求項２記載の電子マネーサーバを提供する。
請求項４記載の発明では、前記選定手段により選定された候補チケットの内容を前記送金元ユーザに提示する第２提示手段をさらに備え、前記チケット登録手段が、前記第２提示手段により提示された候補チケットの中から前記送金元ユーザにより１の電子チケットが指定された場合は当該１の電子チケットを前記チケット記憶手段に記憶させ、前記第２提示手段により提示された電子チケットの中から前記送金元ユーザにより１の電子チケットが指定されなかった場合は前記第１提示手段により提示された候補チケットの中から前記送金先ユーザにより指定される１又は複数の電子チケットを前記チケット記憶手段に記憶させる、ことを特徴とする請求項３記載の電子マネーサーバを提供する。
請求項５記載の発明では、前記選定手段が、前記履歴記憶手段に記憶される前記送金先ユーザの電子マネー利用履歴から見出される該送金先ユーザの活動エリアで少なくとも利用可能とする適用条件が指定された前記電子チケットを選定する、ことを特徴とする請求項２から請求項４までのいずれか１項に記載の電子マネーサーバを提供する。
請求項６記載の発明では、前記各電子チケットには、前記第三者により、さらに、送金要求額から原資に組み入れられるべき控除金額又はその算定式が指定されており、前記選定手段が、前記控除金額が前記送金要求額に所定の係数を乗じて得られる金額以内に収まるように、前記候補チケットを選定する、ことを特徴とする請求項２から請求項５までのいずれか１項に記載の電子マネーサーバを提供する。
請求項７記載の発明では、前記送金先ユーザ又は前記送金元ユーザにより指定された前記所定の係数の増加要求を取得する増加要求取得手段をさらに備え、前記選定手段が、前記控除金額が前記送金要求額に前記増加後の所定の係数を乗じて得られる金額以内に収まるように、前記候補チケットを選定する、ことを特徴とする請求項６記載の電子マネーサーバを提供する。
請求項８記載の発明では、前記精算実行手段が、さらに、前記送金先ユーザにより前記適用条件を満たす電子マネーの利用がなされた場合に、前記送金元口座の残高を増額させるための原資を前記第三者に負担させるための処理を実行する、ことを特徴とする請求項１から請求項７までのいずれか１項に記載の電子マネーサーバを提供する。
請求項９記載の発明では、送金元口座から送金先口座へ電子バリューを送金する際に、送金元ユーザと送金先ユーザのいずれでもない第三者により該送金先ユーザによる利用に関する適用条件が指定された電子チケットを該送金先ユーザに関連付けてチケット記憶手段に記憶させるチケット登録ステップと、前記送金先ユーザによる前記適用条件を満たす前記電子チケットを伴った電子バリューの利用に対し、前記電子チケットの内容に相当する額の少なくとも一部を前記第三者に負担させるための処理を実行する精算実行ステップと、を含み、前記チケット登録ステップで、前記送金元ユーザの指定に応じて、前記送金元ユーザにより指定された送金要求額の少なくとも一部が前記電子チケットの内容に相当する額の少なくとも一部となるという、前記送金元ユーザによるバリューの送金に関する制限が設けられた場合に限り、前記電子チケットを登録し、前記送金要求額からその一部を減額して得られる金額を前記送金元口座から前記送金先口座へ移転される電子バリューの金額とすることを特徴とするコンピュータによる電子マネー送金方法を提供する。
請求項１０記載の発明では、送金元口座から送金先口座へ電子バリューを送金する際に、送金元ユーザと送金先ユーザのいずれでもない第三者により該送金先ユーザによる利用に関する適用条件が指定された電子チケットを該送金先ユーザに関連付けてチケット記憶手段に記憶させるチケット登録機能と、前記送金先ユーザによる前記適用条件を満たす前記電子チケットを伴った電子バリューの利用に対し、前記電子チケットの内容に相当する額の少なくとも一部を前記第三者に負担させるための処理を実行する精算実行機能と、前記チケット登録機能で、前記送金元ユーザの指定に応じて、前記送金元ユーザにより指定された送金要求額の少なくとも一部が前記電子チケットの内容に相当する額の少なくとも一部となるという、前記送金元ユーザによるバリューの送金に関する制限が設けられた場合に限り、前記電子チケットを登録し、前記送金要求額からその一部を減額して得られる金額を前記送金元口座から前記送金先口座へ移転される電子バリューの金額とすることをコンピュータに実現させるためのプログラムを提供する。
請求項１１記載の発明では、送金元口座から送金先口座へ電子バリューを送金する際に、送金元ユーザと送金先ユーザのいずれでもない第三者により該送金先ユーザによる利用に関する適用条件が指定された電子チケットを該送金先ユーザに関連付けてチケット記憶手段に記憶させるチケット登録機能と、前記送金先ユーザによる前記適用条件を満たす前記電子チケットを伴った電子バリューの利用に対し、前記電子チケットの内容に相当する額の少なくとも一部を前記第三者に負担させるための処理を実行する精算実行機能と、前記チケット登録機能で、前記送金元ユーザの指定に応じて、前記送金元ユーザにより指定された送金要求額の少なくとも一部が前記電子チケットの内容に相当する額の少なくとも一部となるという、前記送金元ユーザによるバリューの送金に関する制限が設けられた場合に限り、前記電子チケットを登録し、前記送金要求額からその一部を減額して得られる金額を前記送金元口座から前記送金先口座へ移転される電子バリューの金額とすることをコンピュータに実現させるためのプログラムを記録したコンピュータ読取可能な記録媒体を提供する。
【発明の効果】
【０００８】
本発明によれば、従来にはない付加価値を有する電子マネー送金サービスを提供することができる。
【図面の簡単な説明】
【０００９】
【図１】本実施形態に係る電子マネーシステムのネットワーク構成を説明するための図である。
【図２】本実施形態に係る電子マネーの送金を説明するための図である。
【図３】本実施形態に係るギフトの使用を説明するための図である。
【図４】携帯端末の構成を説明するための図である。
【図５】携帯端末を用いての電子マネーの決済を説明するための図である。
【図６】非同期決済端末の構成を説明するための図である。
【図７】電子マネーサーバの構成を説明するための図である。
【図８】（１）電子マネーサーバのユーザＤＢの論理構成を説明するための図であり、（２）ギフトサーバ（ギフトＤＢ）の論理構成を説明するための図である。
【図９】本実施形態に係るギフト付き電子マネーの送金のバリエーションを説明するための図である。
【図１０】本実施形態に係る送金の処理手順を示したフローチャートである。
【図１１】（１）本実施形態に係る送金を行う際、送金元の携帯端末に表示される画面の一例を示した図であり、（２）本実施形態に係る送金を行う際、送金先の携帯端末に表示される画面の一例を示した図である。
【図１２】本実施形態に係るギフトを用いて端末側バリュー残高で決済を行う処理手順を示したフローチャートである。
【図１３】本実施形態に係るギフトを用いて端末側バリュー残高で決済を行う処理手順を示したフローチャートである。
【図１４】本実施形態に係るギフトを用いてサーバ側バリュー残高で決済を行う処理手順を示したフローチャートである。
【図１５】図１２に示す処理の変形例の処理手順を示したフローチャートである。
【図１６】図１２に示す処理の変形例の処理手順を示したフローチャートである。
【図１７】図１２に示す処理の変形例の処理手順を示したフローチャートである。
【発明を実施するための形態】
【００１０】
（１）実施形態の概要
図２に示すように、ユーザＡが、ユーザＢに電子マネーにて行う送金は、電子マネーサーバ２内のサーバ側バリュー残高を移動させることで行う。この送金を行う際に、ユーザＢに、原資の少なくとも一部を広告主負担とする電子ギフト（例えば、電子クーポン、用途限定付き電子マネー、電子商品券など。電子チケットの一例。）を付与する。付与されたギフトは、ユーザＢの口座に紐付けられ、ユーザＢが電子マネーを利用する際、同時に利用することができる。
ユーザＢに付与されるべきギフトの選定に当たっては、例えば、ユーザＢによる電子マネーを用いて行った購買履歴を参照する。これにより、ニーズに即したギフトが付与されるようにする。
また、広告主が電子ギフトの適用条件（例えば、利用可能な地域、利用可能な店舗、対象の商品、利用可能な時期、利用可能な時間帯など）を設定し、ユーザＢによる適用条件を満たす電子マネーの利用に対し、電子ギフトが適用されるようにする。これにより、特定の店舗への誘導、特定の商品の購入等を効果的に促進する効果が期待できる。その結果、広告の出稿が促進され、送金サービスそのものの利用も促進され得る。
【００１１】
図９には、本実施形態に係るギフト付き電子マネーの送金のバリエーションが示してある。以下のバリエーションでは、ギフトの原資の少なくとも一部を、送金元のユーザでも送金先のユーザでもない第三者（広告主）が負担している。
（１）は、ギフト１００円分の半額をユーザＡが、他の半額を広告主が負担している。
（２）は、ギフト全額（１００円分）を広告主が負担している。
（３）は、ギフト２００円分の半額をユーザＡが、他の半額を広告主が負担している。但し、送金される電子マネーは２９００円分となっている。
なお、上記（３）のように電子マネーの送金に一定の制限（ここでは、送金要求額の一部がギフトの原資に転換していること）が課される場合に限り、送金にギフトを付加することが可能となるように構成してもよい。
【００１２】
（２）実施形態の詳細
図１は、第１の実施形態に係る電子マネーシステム１のネットワーク構成を説明するための図である。
電子マネーシステム１は、電子マネーサーバ２、インターネット３、携帯端末５、決済端末６、非同期決済端末７、通信回線８などを用いて構成されている。
この電子マネーシステム１では、サーバ側バリュー残高によるサーバ管理型システムと端末側バリュー残高によるストアードバリュー型システムが混在している。
【００１３】
電子マネーサーバ２は、バリューによる貨幣価値の移動を管理するサーバ装置である。ここで、バリューとは、貨幣価値に対応させた電子情報であり、電子マネーシステム１は、バリューの残高（以下、バリュー残高）を増減することにより貨幣価値を移動させる。
そして、電子マネーシステム１の事業体は、バリューの移動に対応させて実際の貨幣を移動させることによりバリューと実際の貨幣の移動を対応させる。
また、電子マネーサーバ２は、ギフトの生成時に原資を徴収しない場合に、ギフトが利用される際に又は利用された後に、当該ギフトの原資の少なくとも一部を広告主に負担させるための処理を実行する。
【００１４】
電子マネーサーバ２は、サーバ側で残高の管理を行う「サーバ側バリュー残高」を記憶している。
一方、携帯端末５は、携帯端末５に内蔵又は装着されたＩＣモジュール３０に「端末側バリュー残高」を記憶している。
電子マネーサーバ２は、管理のため、必ずしも必須ではないが、携帯端末５に対応付けてバリュー残高の管理値を記憶している。「サーバ側バリュー残高」と「端末側バリュー残高」とは、常に同期を取って、同一の値であることが望ましい。しかし、現実には電子マネーサーバ２とリアルタイムで接続できない、非同期決済端末７も多数存在する。そのため、生成したログデータを後にバッチ処理で電子マネーサーバ２に送り、事後的に同期を取るようにしている。
【００１５】
携帯端末５は、例えば、スマートフォン、携帯電話、ゲーム機、タブレット型コンピュータなどで構成された携帯端末であって、インターネット３に接続する機能と、決済端末６や非同期決済端末７と近距離無線通信により接続する機能とを備えている。
携帯端末５は、ＩＣモジュール３０を内蔵又は装着しており、これに電子マネー番号と端末側バリュー残高を記憶している。
【００１６】
決済端末６は、携帯端末５と近距離無線通信を行うと共に通信回線８を介して電子マネーサーバ２とも通信し、電子マネーサーバ２に決済金額などの情報を送信したり、電子マネーサーバ２と携帯端末５の通信を中継したりする。決済端末６は、携帯端末５を用いた決済時にリアルタイムで電子マネーサーバ２とオンライン通信する同期型決済端末である。決済端末６は、端末側バリュー残高による決済と、サーバ側バリュー残高による決済と、の少なくともいずれかに対応している。
決済端末６は、コンビニエンスストアなどのリアル店舗（不動産店舗などで物理的に営業している実店舗）の会計カウンタや自動販売機などに設置されている。
通信回線８は、電子マネーサーバ２と決済端末６又は非同期決済端末７を接続する回線である。通信回線８として専用回線を用いることもできるし、インターネット３などの汎用の回線を用いてもよい。
【００１７】
非同期決済端末７は、例えば、ネットワーク設備の不便な店舗や自動販売機などに設置されており、携帯端末５と近距離無線通信を行う機能を備えている。
非同期決済端末７は、携帯端末５と近距離無線通信を行って、端末側バリュー残高により決済を行う。非同期決済端末７は、通常は電子マネーサーバ２と接続しておらず（そのため、サーバ型電子マネーの決済ができない）、携帯端末５との決済内容を一時的にログデータとして記憶しておく。
そして、非同期決済端末７は、例えば１日に一回程度、通信回線８を用いて電子マネーサーバ２に接続し、電子マネーサーバ２にログデータを送信する。ネットワーク通信設備がない環境では、ログデータを記録した記録媒体を担当者が手動で収集する場合もある。
電子マネーサーバ２は、端末側バリュー残高に関しては、決済端末６を介してＩＣモジュール３０にリアルタイムにアクセスした履歴と、非同期決済端末７から送信されるログデータと、によって資金移動を管理する。
【００１８】
図４は、携帯端末５のハードウェア的な構成を示した図である。ここでは、一例として携帯端末５をスマートフォンであるとするが、携帯電話も同様である。
ゲーム機、タブレット型コンピュータは、通常携帯電話網の基地局アンテナと無線通信する機能を備えておらず、無線ＬＡＮのアクセスポイントと無線通信する機能のみを備えている場合が多い。なお、スマートフォンも無線ＬＡＮのアクセスポイントと無線通信する機能を備えている機種がある。
携帯端末５は、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）１１、ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）１２、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）１３、入力部１４、出力部１５、通信制御部１６、近距離通信制御部１７、記憶部１８、マイクロフォン２０、加速度センサ２１、ＧＰＳ受信機２２、ＩＣモジュール３０などがバスライン１９によって接続している。
【００１９】
ＣＰＵ１１は、ＲＯＭ１２や記憶部１８に記録したプログラムを実行して各種の情報処理や携帯端末５全体の制御を行う。本実施形態では、例えば、後述の電子マネーアプリケーションプログラムの提供する機能により電子マネーサーバ２と協働してバリュー残高による決済処理を支援する。
ＲＯＭ１２は、読み取り専用のメモリであって、携帯端末５が動作するための基本的なプログラム、パラメータ、データなどが記録されている。
ＲＡＭ１３は、読み書きが可能なメモリであって、ＣＰＵ１１が情報処理を行う際のワーキングメモリを提供する。
【００２０】
出力部１５は、ユーザに対して情報を出力する機能部であって、例えば、画面表示用の液晶ディスプレイ、音声を出力するスピーカなどを備えている。液晶ディスプレイには、例えば、電子マネーアプリケーションプログラムを起動するためのアイコンなどが表示される。
入力部１４は、外部からの情報を入力する機能部であって、例えば、液晶ディスプレイ上に設置されたタッチパネルなどを備えている。ユーザは、液晶ディスプレイ上の表示に対応してタッチパネルにタッチすることにより情報を入力することができる。
【００２１】
記憶部１８は、例えば、ＥＥＰＲＯＭ（Ｅｌｅｃｔｒｉｃａｌｌｙ  Ｅｒａｓａｂｌｅ  ａｎｄ  Ｐｒｏｇｒａｍｍａｂｌｅ  ＲＯＭ）やハードディスクなどの記録媒体を用いて構成されており、携帯端末５を制御する基本的なプログラムであるＯＳ（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）やバリューによる決済を支援する電子マネーアプリケーションプログラム、その他のプログラムやデータを記録している。
通信制御部１６は、携帯電話網の基地局アンテナと無線通信するためのアンテナを備えており、携帯端末５をインターネット３や電話回線に接続する。携帯端末５は、通信制御部１６を介してインターネット３経由で電子マネーサーバ２と通信することができる。
また、スマートフォンも無線ＬＡＮのアクセスポイントと無線通信するための機能を備えている。
近距離通信制御部１７は、決済端末６や非同期決済端末７のリーダライタと近距離無線通信するためのアンテナを備えており、ＩＣモジュール３０を決済端末６や非同期決済端末７に接続する。ＩＣモジュール３０は、近距離通信制御部１７を介して決済端末６や非同期決済端末７と通信する他、携帯端末５の通信制御部１６を経由して電子マネーサーバ２と通信することができる。
【００２２】
ＩＣモジュール３０は、汎用のアプリケーションを記憶したＩＣモジュールであり、携帯端末５に内蔵又は装着されている。ＩＣモジュール３０には、ユーザがダウンロードしたアプリケーションを記憶させることができる。
ＩＣモジュール３０は、ＣＰＵ、ＲＡＭ、ＲＯＭなどによって構成され、各種プログラムに従って情報処理を行う情報処理部２６と不揮発性のメモリで構成された記憶部２７を備えている。
記憶部２７には、電子マネー番号と端末側バリュー残高、図示しないが、情報処理部２６によってバリュー残高を操作するためのバリュー操作プログラム、及び電子マネーサーバ２がＩＣモジュール３０を認証する認証データなどが記憶されている。また、決済及びチャージのログデータなども記憶されている。
電子マネー番号は、電子マネーサーバ２が、当該携帯端末５（ＩＣモジュール３０）が、何れのユーザのものであるかを識別するための番号である。
【００２３】
ＩＣモジュール３０における端末側バリュー残高に関する減額処理、及び増額処理は外部からの命令によりＩＣモジュール３０内の情報処理部２６に形成されたバリュー操作プログラムが行う。これは、バリュー残高の処理をＩＣモジュール３０内に限定することによりセキュリティを高めるためである。
【００２４】
なお、端末側バリュー残高の処理に関しては、ＩＣモジュール３０に入力される情報は暗号化されており、ＩＣモジュール３０の内部で復号され、ＩＣモジュール３０から出力される情報は、これらモジュール内で暗号化してから出力される。
マイクロフォン２０は、外部からの音声を受けて電気信号に変換する。
加速度センサ２１は、加速度の測定を目的とした慣性センサである。加速度を測定し、信号処理を行うことによって、携帯端末５の傾きや動き、振動や衝撃といったさまざまな情報を得ることができる。
ＧＰＳ受信機２２は、複数のＧＰＳ衛星からの電波を受信してそれぞれとの距離を割り出すことにより、当該携帯端末５の現在位置を測定することができる。
【００２５】
図５は、携帯端末５の機能を説明するための図である。
電子マネーアプリケーションプログラムを実行すると携帯端末５に電子マネーアプリケーション２９が形成される。
決済端末６を備えたリアル店舗での決済の場合は、近距離通信制御部１７は、決済端末６と通信すると共に決済端末６を介して電子マネーサーバ２と通信する。サーバ側バリューで決済を行う場合、リアルタイムでサーバ側バリューを減額することで決済を行う。
非同期決済端末７を備えたリアル店舗での決済の場合は、近距離通信制御部１７は、非同期決済端末７と通信する。
また、電子マネーアプリケーション２９は、ＩＣモジュール３０にアクセスすることができる。
【００２６】
リアル店舗での決済の場合、近距離通信制御部１７は、ＩＣモジュール３０でバリュー操作プログラムを動作させて、端末側バリュー残高を増減させたり、電子マネー番号を読み出したりすることができる。
そして、決済処理を行う際、ＩＣモジュール３０は、近距離通信制御部１７を介して、非同期決済端末７からバリュー残高を更新（減額）するようにとの要求を受けて、端末側バリュー残高を更新（減額）する。
ここで行う端末側バリュー残高更新処理には、次のような方式が考えられる。
【００２７】
（方式１）端末側バリュー残高更新要求として上書き命令を送信する場合。
この場合、電子マネーサーバ２は、携帯端末５のＩＣモジュール３０のＣＰＵから受信した端末側バリュー残高に対して決済金額による減算を行い、減算後の残高を算出する。そして、非同期決済端末７は、端末側バリュー残高更新要求として、当該算出後の残高に上書きする上書き命令を送信する。携帯端末５のＩＣモジュール３０のＣＰＵは、当該上書き命令に従って端末側バリュー残高を上書きして更新する。
（方式２）端末側バリュー残高更新要求として減算命令を送信する場合。
この場合、非同期決済端末７は、決済金額分だけバリュー残高を減算する減算命令を端末側バリュー残高更新要求として携帯端末５のＩＣモジュール３０のＣＰＵに送信する。携帯端末５のＩＣモジュール３０のＣＰＵは、当該命令に従って端末側バリュー残高から決済金額を減算して端末側バリュー残高を更新する。
その後、ＩＣモジュール３０は、端末側バリュー残高を更新した旨を非同期決済端末７に通知する。
【００２８】
次に、リアル店舗でのチャージを説明する。
このチャージを行うのは、前提として、チャージを行うバリューに相当する貨幣を非同期決済端末７を操作する店員が受け取っていることである。そして、チャージ処理を行う際、ＩＣモジュール３０は、近距離通信制御部１７を介して非同期決済端末７から端末側バリュー残高を更新（増額）するようにとの要求を受けて、端末側バリュー残高を更新（増額）する。
その後、ＩＣモジュール３０は、端末側バリュー残高を更新した旨を非同期決済端末７に通知する。
【００２９】
このチャージでは、非同期決済端末７を介さずに、直接電子マネーサーバ２からチャージを行うこともできる。この場合、携帯端末５の通信制御部１６を介して電子マネーサーバ２にアクセスし、ユーザの認証処理、クレジット会社サーバなどの認証機関サーバの許可などの手順を経る。そして、電子マネーサーバ２から、金額変更（増額）情報を携帯端末５が受信し、ＩＣモジュール３０は、端末側バリュー残高を更新（増額）する。
【００３０】
図６は、非同期決済端末７のハードウェア的な構成の一例を示した図である。
非同期決済端末７は、ＣＰＵ１３１、ＲＯＭ１３３、ＲＡＭ１３４、通信制御部１３５、記憶部１３６、入力部１３７、出力部１３８、リーダライタ部１３９、表示部１４０などがバスラインで接続されて構成されており、決済処理装置としての機能を有している。
ＣＰＵ１３１は、所定のプログラムに従って情報処理を行うほか、非同期決済端末７全体の制御などを行う。本実施の形態では、ＣＰＵ１３１は、金額変更情報を携帯端末５のＩＣモジュール３０に送信して、金額変更処理を行わせる。
ＲＯＭ１３３は、非同期決済端末７を動作させるための基本的なプログラムやパラメータなどを記憶した読み出し専用メモリである。
ＲＡＭ１３４は、ＣＰＵ１３１のワーキングメモリを提供したり、記憶部１３６に記憶されたプログラムやデータをロードして記憶したりなどする随時書き込み読み出し可能なメモリである。
通信制御部１３５は、ネットワークを介して非同期決済端末７を電子マネーサーバ２に接続する接続装置である。
【００３１】
入力部１３７は、非同期決済端末７が店舗に設置されたものである場合、例えば、キーボード、バーコードリーダなどの入力装置を備えており、操作担当者が商品コードや決済金額やチャージ金額などを入力できるようになっている。
また、非同期決済端末７が、通過ゲートに設置されたものである場合、入力部１３７は、例えば、通過ゲートの制御装置に接続されており、通過ゲートの制御装置から決済金額の入力を受け付けるようになっている。
【００３２】
出力部１３８は、非同期決済端末７が店舗に設置されたものである場合、例えば、液晶表示装置等の表示部１４０、プリンタなどに接続されており、顧客や加盟店の操作担当者に情報を提示するようになっている。
また、非同期決済端末７が、通過ゲートに設置されたものである場合、例えば、出力部１３８はゲート扉を駆動する駆動装置や、通過ゲートに設置された警告灯や音声出力装置などに接続されており、ゲート扉を開閉したり、ゲート扉の開閉に同期して警告灯を点滅させたり警告音を発生させたりする。
リーダライタ部１３９は、アンテナを内蔵しており、携帯端末５に内蔵又は装着されたＩＣモジュール３０と無線通信を行う。
非同期決済端末７が、店舗に設置されるものである場合、リーダライタ部１３９は、キャッシュレジスタ近辺に設置され、ユーザが商品の決済時に、携帯端末５又は電子マネーカードをリーダライタ部１３９に近接させることができるようになっている。
また、非同期決済端末７が、通過ゲートに設置されるものである場合、リーダライタ部１３９は、通過ゲート上面の、ゲート扉よりも手前側に設置され、ユーザが通過ゲートを通過する際に、携帯端末５又は電子マネーカードをリーダライタ部１３９に近接させることができるようになっている。
【００３３】
記憶部１３６は、例えばハードディスクやその他の記憶媒体と、これらを駆動する駆動装置から構成されており、各種プログラムを格納したプログラム格納部１４２、データを格納したデータ格納部１４４などから構成されている。
プログラム格納部１４２には、決済端末６を機能させるための基本的なプログラムであるＯＳや、電子マネーカード１００に金額変更処理を行わせたり、不足金額を電子マネーサーバ２にチャージさせたりするためのプログラムなどが記憶されている。
データ格納部１４４には、非同期決済端末７のＩＤ情報である端末ＩＤや、ＩＣモジュール３０との取引履歴である利用ログデータなどを記憶している。この利用ログデータは、ＣＰＵ１３１が行うバッチ処理にて、定期的又は不定期に電子マネーサーバ２に送信される。
【００３４】
表示部１４０は、決済金額、決済前残高、決済後残高、決済不能の場合の不足額等を例えば液晶表示装置に表示する。また、この実施形態では、決済処理を行う際の個々の商品の価格を入力する毎に、その累積した価格を表示するようにしている。
【００３５】
図７は、電子マネーサーバ２の構成を説明するための図である。
電子マネーサーバ２は、ＣＰＵ３１、ＲＯＭ３２、ＲＡＭ３３、通信制御部３４、記憶部３５などがバスライン３６によって接続している。
ＣＰＵ３１は、ＲＯＭ３２や記憶部３５に記録したプログラムを実行して各種の情報処理や電子マネーサーバ２全体の制御を行う。例えば、携帯端末５からチャージの要求を受けてチャージの実行をする。
非同期決済端末７での決済では、電子マネーサーバ２は、非同期決済端末７がバリュー残高を更新したログデータを後ほど非同期決済端末７から受信して処理する。
なお、電子マネーサーバ２とオンラインで接続できる決済端末６の場合、通信しながらサーバ側バリュー残高をリアルタイムで更新することによりバリューによる決済処理を行うことができる。
【００３６】
ＲＯＭ３２は、読み取り専用のメモリであって、電子マネーサーバ２が動作するための基本的なプログラム、パラメータ、データなどが記録されている。
ＲＡＭ３３は、読み書きが可能なメモリであって、ＣＰＵ３１が情報処理を行う際のワーキングメモリを提供する。
通信制御部３４は、電子マネーサーバ２が通信回線８を介して決済端末６、非同期決済端末７、携帯端末５と通信したり、インターネット３を介して携帯端末５と通信したりする。
記憶部３５は、例えば、大容量のハードディスクで構成されており、ＣＰＵ３１がバリューによる決済処理を行ったり、チャージを行うための電子マネー管理プログラムやその他のプログラム、ユーザのサーバ側バリュー残高を管理したり、チャージの履歴を管理するユーザＤＢ（データベース）、加盟店のバリュー決済を管理する加盟店ＤＢ、各決済処理を記録したログデータを格納するログデータＤＢなどを記録している。
なお、この図７の例では、単一の電子マネーサーバ２を説明したが、この電子マネーサーバ２が、機能を分散することにより複数のサーバ装置から構成されるようにしてもよい。
【００３７】
次に、図８の各図を用いて電子マネーサーバ２の有するデータベースについて説明する。
図８（１）は、ユーザＤＢの論理的な構成を説明するための図である。
本実施形態では、ユーザＩＤに対応して、電子マネー番号が記憶されている。ここでは、サーバ側電子マネー番号と端末側電子マネー番号とを同一の電子マネー番号として管理するようにしているが、別々に管理するようにしてもよい。なお、図示しないがＩＣモジュール３０の認証データなどの項目も記憶されている。
項目「ユーザＩＤ」は、ユーザの識別情報である。
項目「電子マネー番号」は、バリュー残高を他のユーザのサーバ側バリュー残高から識別するための口座番号である。
項目「バリュー残高」は、当該口座が記録しているバリュー残高である。
項目「氏名」は、ユーザの氏名である。
項目「住所」は、ユーザの住所である。
項目「生年月日」は、ユーザの生年月日である。年齢を記録するようにしてもよい。
項目「電話番号」は、ユーザが保持する携帯端末の電話番号である。
項目「メールアドレス」は、ユーザが保持する携帯端末のメールアドレスである。
項目「他のＩＤ」とは、例えば、特定のサイトでのサービスを受けるために付与された一意のＩＤ等である。
【００３８】
図８（２）は、ギフトサーバ２００のＤＢの論理的な構成を説明するための図である。
項目「電子マネー番号」は、バリュー残高を他のユーザのサーバ側バリュー残高から識別するための口座番号である。
項目「ギフトＩＤ」は、ギフトをユーザＢに付与する際、生成したＩＤであり、ユーザＢの電子マネー番号と紐付けされている。
項目「ギフトＩＤの内容」は、当該ギフトの内容であり、例えばギフトの適用条件（例えば、利用可能な地域、利用可能な店舗、対象の商品、利用可能な時期、利用可能な時間帯など）を含む。具体的には、「店舗Ａで５％引き」、「店舗Ｂで午前中にコーヒー２００円割引き」、「店舗Ｃでコーラ１本無料」など、である。
項目「ギフトの有効期限」は、ギフトを利用できる期限である。
項目「ギフトの使用の有無」は、当該ギフトが使用されたか否かを記録する項目である。使用された場合は「済」、使用されていない場合は「未」と登録される。
なお、この図８（２）のギフトＤＢは、電子マネーサーバ２とは別個にギフトサーバ２００に設けるようにしてもよいが、他のＤＢと同様に電子マネーサーバ２に設けるようにしてもよい。
【００３９】
次に、本実施形態の処理手順をフローチャートを参照して説明する。
まず、図１０のフローチャートを参照して、携帯端末Ａから携帯端末Ｂへ送金する処理について説明する。
ここでは、携帯端末Ａのユーザ（ユーザＡ）が携帯端末Ｂのユーザ（ユーザＢ）に送金するとする。また、図２に示すように、ユーザＡが、ユーザＢに電子マネーにて行う送金は、電子マネーサーバ２内のサーバ側バリュー残高を移動させることで行うものとする。
まず、ユーザＡは、電子マネーサーバ２に対してギフト付き送金をする旨の申し込みを行う（ステップ１０）。このとき、送金したい金額、送金先を指定する情報も送信する。この送信は、申し込み時に所定のフォームに従って、同時に行ってもよいし、電子マネーサーバ２から送信されてきたフォームに記載して、返信するようにしてもよい。
送金先を指定する情報としては、相手方の電子マネー番号、相手方のＩＤ（メールアドレス、特定のサイトのユーザ名）、携帯端末Ｂの電話番号、相手方の住所、氏名等があり、また、ＳＮＳ（ソーシャル・ネットワーク・サービス）の写真などからＧＵＩにて選択するようにしてもよい。
【００４０】
このギフト付き送金の申し込みを受けた電子マネーサーバ２は、送金先を指定する情報から相手先（携帯端末Ｂ）のＤＢ（データベース）を検索して、電子マネー番号を取得する（送金先を指定する情報として電子マネー番号が送信されてきた場合は、そのまま当該電子マネー番号を取得する）。そして、当該電子マネー番号に係る利用ログを検索して、購買履歴を取得する（ステップ１５）。
取得した購買履歴からギフトの候補を選定する。例えば、ユーザＢが過去に度々ファーストフード店で飲食をしていた、コンビニエンスストアでプライベートブランドのスイーツを定期的に購入していたとすると、当該ファーストフード店のコーヒー券、又はコンビニのスイーツの割引券を候補として提示する。このようしてギフトの候補を選定することで、ギフトとしてユーザＢに送られたとき、ユーザＢにとって有用なギフトとなり、結果として使用される可能性が高まる。
【００４１】
ここに示す例では、３０００円の送金要求に対して、電子マネー２９００円を送金し、２００円分のギフトをユーザＢに付与する。このギフトの２００円分のうち、１００円分は送金要求額の一部が原資となっており、残りの１００円分を広告主が負担する。ギフトとしては、当該ファーストフード店のコーヒー券２００円分、又はコンビニのスイーツの割引券２００円分を候補として提示する。これにより、ユーザＢは、受領する電子マネーの金額が減少する代わりに、時間的・空間的な限定があるものの該減少金額を補って余りある電子ギフトを取得することが可能になる。
【００４２】
そして、電子マネーサーバ２は、図１１（１）に示すような送金内容確認を携帯端末Ａへ送信する（ステップ２０）。この携帯端末Ａへの送信は電子メールで行う。また、他の方法、例えば携帯端末Ａのアプリケーションに通知が表示されたり、ＳＮＳでの表示、特定のサイトのログイン後画面での表示でもよい。
また、ステップ１０の処理をＨＴＴＰリクエストにて行えば、ステップ２０の処理はそのレスポンスでもよい。そして、ステップ２０の電子メールにハイパーリンク（ＵＲＬ）を記載しておき、携帯端末Ａのユーザがそのリンクをクリックすることで、ステップ２５の内容を含み又は指定するＨＴＴＰリクエストが電子マネーサーバ２に送信されるようにしてもよい。
【００４３】
そして、ステップ２０で送信された送金内容確認は、携帯端末Ａの入力部１４に、図１１（１）の画面として表示される。
これに対して、ユーザＡは、送金金額を確認し、誤りがあれば、電子マネーサーバ２に訂正を要求する。また、複数あるギフトの候補から１のギフトを選定してもよいし、複数の候補をそのままユーザＢに送り、ユーザＢの側で選定するようにしてもよい。ユーザＡの選択により、ギフトを付加しないでもよい。
また、電子マネーサーバ２にさらに他の候補を要求するようにしてもよい。
さらに、ユーザＡの側でギフトを選定し、これをギフトの候補として追加するように要請できるように構成してもよい。
なお、ステップ１０からステップ２５の処理を１の処理として同時に実施してしまうようにしてもよい。
【００４４】
ユーザＡが送金金額を確認し、ギフトの選択を行うと、携帯端末Ａは、当該送金内容確認・ギフト選択を電子マネーサーバ２に送信し（ステップ２５）、これを受けて、電子マネーサーバ２は、携帯端末Ｂに対して、ユーザＡから送金依頼があった旨を送信し、送金受領の確認を求める（ステップ３０）。
これを受けて、ユーザＢが送金の承認を携帯端末Ｂから電子マネーサーバ２へ送信すると（ステップ３５）、電子マネーサーバ２は、携帯端末Ｂに図１１（２）に示したような送金内容確認を送信する（ステップ４０）。このとき、複数のギフトが提示されている場合は、その選択を求める。
なお、複数のギフトの取得を認め、１のギフトを使用した場合、その段階で他のギフトが失効するという構成にしてもよい。
【００４５】
ここで、電子マネーサーバ２が、携帯端末Ｂから送金内容確認・ギフトの選択送信を受信する（ステップ４５）。なお、ステップ２５からステップ４０までの処理を１の処理として同時に実施してしまうようにしてもよい。
そして、電子マネーサーバ２は、送金処理を実行する（ステップ５０）。
この送金処理は、携帯端末Ａのサーバ側バリュー残高を３０００円分減少させ、携帯端末Ｂのバリュー残高を２９００円分増加させることにより行う。
その後、電子マネーサーバ２は、ユーザＡに指定され又はユーザＢにより選択されたギフトをその内容とするギフトＩＤを生成し（ステップ５５）、生成したギフトＩＤと携帯端末Ｂの電子マネー番号とを対応付けて登録する（ステップ６０）。この登録は、電子マネーサーバ内のＤＢに行ってもよいし、図３に示すように、電子マネーサーバとインターネット３を介して接続可能なギフトサーバ２００内のＤＢに行うようにしてもよい。
【００４６】
続いて、電子マネーサーバ２は、送金完了通知を携帯端末Ａと携帯端末Ｂに送信する（ステップ６５）。携帯端末Ｂに対しては、ギフトが登録された旨も同時に通知するようにしてもよい。
送金完了通知を携帯端末Ａが受信し（ステップ７０）、かつ携帯端末Ｂが受信して（ステップ７５）、本実施形態に係る送金処理が完了する。
【００４７】
なお、ユーザＡの携帯端末５ＡのＩＣモジュール３０に記憶されている端末側バリュー残高を電子マネーサーバ２に記憶されているユーザＡのサーバ側バリュー残高にアップロード可能となっている。また、ユーザＢのサーバ側バリュー残高をユーザＢの携帯端末５Ｂにダウンロードすることも可能となっている。このアップロード、ダウンロードは自動で行う設定としてもよいし、ユーザの操作に基づいて手動で行うようにしてもよい。このダウンロードは、送金ＵＲＬをユーザＢがクリックすることにより行うようにしてもよい。
【００４８】
送金処理とアップロード処理・ダウンロード処理とを任意に組合せ可能に構成すれば、より柔軟性の高い送金サービスを提供することが可能になる。
例えば、アップロード処理と送金処理とを自動的に連続して実行することにより、ユーザＡの携帯端末５ＡのＩＣモジュール３０に記憶されている端末側バリュー残高から電子マネーサーバ２に記憶されているユーザＢのサーバ側バリュー残高に電子マネーを移転させることができる。また、送金処理とダウンロード処理とを自動的に連続して実行することにより、電子マネーサーバ２に記憶されているユーザＡのサーバ側バリュー残高からユーザＢの携帯端末５ＢのＩＣモジュール３０に記憶されている端末側バリュー残高に電子マネーを移転させることができる。
さらに、アップロード処理と送金処理とダウンロード処理とを自動的に連続して実行することにより、ユーザＡの携帯端末５ＡのＩＣモジュール３０に記憶されている端末側バリュー残高からユーザＢの携帯端末５ＢのＩＣモジュール３０に記憶されている端末側バリュー残高に電子マネーを移転させることができる。
【００４９】
次に、ギフトの選定方法について説明する。
上記した例では、携帯端末Ｂのユーザの購買履歴を検索して、ギフト候補を選定したが、他の方法によって、選定することもできる。付与されたギフトをユーザＢが使用しなければ、ギフトを付与することが無意味になってしまうため、ユーザＢにとって有用であり、ニーズに合致しているものを選定することが望ましい。
具体的には、ユーザＢのギフトの利用履歴、各種クーポンの利用履歴、ユーザＢの個人情報を用いて選定する。個人情報としては、ユーザの年齢、性別、住所等である。また、携帯端末Ｂの位置情報（ＧＰＳ受信機２２から取得する）、店舗の位置情報を加味して選定するようにしてもよい。
さらに、ギフトの人気順情報、ユーザＡとユーザＢ間の送金金額、送金手数料金額を考慮して選定してもよい。ギフトの人気順情報を考慮するとは、ギフトとして人気のある商品（サービス）を提示してユーザＡ又はユーザＢに勧めることである。
【００５０】
仮に、ユーザＢが高円寺駅周辺に在住で、購買履歴からスーパーＤのプライベートブランドであるワインを購入していたとする。そして、店舗の位置情報から高円寺駅周辺に当該スーパーＤが存在することを前提に、プライベートブランドであるワインの割引券をギフトとして付与する。
【００５１】
他のギフトの選定方法として、広告主の意向を重視して選定する方法をあげることができる。
例えば、携帯端末Ｂのユーザが、購買履歴から通常ファーストフード店Ｅ社、Ｆ社を定期的に利用していた場合、その競合店のＧ社を広告主として、２００円分のコーヒー券を提示するようにしてもよい。この場合、Ｇ社は、他店の常連客を自店へと誘導することが期待できるので、広告主となる動機付けを高めることができる。
また、ユーザＢの住所から駅前のドラッグストアＨに行くには、往復の交通費２００円（バス代）を負担しなければならないとする。このとき、ドラッグストアＨで電子マネーを用いて何らかの買い物をすることを条件に、ギフトとして２００円分の交通費を付与するようにしてもよい。ドラッグストアＨとしては、来店を期待できるので、広告主となる動機付けを高めることができる。
【００５２】
上記した実施形態では、ユーザＡの側で単数又は複数のギフト候補を選定する例を説明したが、ユーザＡは、ギフトを選定せず、全ての選択をユーザＢに委ねるという選択を可能とするようにしてもよい。
また、ギフトを受け取るユーザＢは、複数のギフト候補を受領（仮登録）し、１のギフトを使用した段階で他のギフトが失効するという構成にしてもよい。
【００５３】
ギフトには、通常、有効期限が定められており、少なくとも、ユーザＢにはギフト付与時に通知しておく必要がある。
また、一定期間が経過しても当該ギフトが使用されない場合、例えば電子メールなどで、ユーザＢに「ギフトの有効期限がせまっています。早めのご来店をお待ちしています。」といったギフトの使用を促すようにしてもよい。
ギフトの使用場所は、店舗の内部に限られず、例えば自動販売機、駅に設置された改札の開閉ゲート、タクシー内の決済端末であってもよい。
また、ギフトが全国展開しているチェーン店が発行するものであっても、ギフトが使用可能な店舗を特定の１店舗、又は一定地域（例えば、新宿区、沖縄県、九州）といった限定を設けるようにしてもよい。
【００５４】
ギフトの使用時間に制限を設けるようにしてもよい。例えば、飲食店の場合、昼食時（午前１１時３０分から午後１時３０分）以外の時間帯のみ使用可能とすることで、混雑時以外に来店してもらえるので、飲食店の効率的な経営に貢献することができる。
また、上記例にあるように、ファーストフード店でコーヒー券２００円分のギフトを使用して、かつ一定金額以上の飲食をした場合、当該店舗の負担で、決済時に再度ギフトを付与するようにしてもよい。こうすることで、ギフトにより来店した客に再度の来店を促すことができる。
【００５５】
ギフトを生成する毎に、当該ギフトの原資の負担条件（例えば、１単位あたりの価格、ユーザＡと広告主の負担割合）を設定するようにすることもできる。こうすることで、広告主は、自己の戦略に応じて柔軟に広告を出稿することができる。
また、ユーザＡ又はユーザＢの意向により、ギフトの原資を任意に追加することができるようにしてもよい。こうすることで、原資の負担条件（割合）に応じてギフトに対する広告主の負担額を増額させることが期待できる。特に、ユーザＢの意向により、送金額のうちギフトの原資に転換される金額（控除金額）を増額してもよい。
ギフトを、用途を限定しない商品券的なものとしてもよい。この場合、「１００円分のギフト（商品券）」により、販売価格から１００円を減算して決済を行うようにする。
【００５６】
広告主からの広告料の徴収は、ギフト発行時に請求してもよいが、成果報酬的に実際にギフトが使用されることを条件に請求するようにしてもよい。
仮に、成果報酬的に広告料を請求することとすれば、広告主は無駄な広告料を負担する必要がなくなり、少なくとも、店先や路上で割引き券を配布するより遙かに効率的な顧客誘導を行うことができる。
【００５７】
次に、図１２、図１３のフローチャートを参照して、決済時にギフトが使用される処理手順を説明する。図３は、ギフトが使用される場面を説明するための図である。ユーザＢが、電子マネーを用いて決済を行う場合、携帯端末５Ｂを決済端末６のリーダライタ部１３９にかざすと、ＩＣモジュール３０から電子マネー番号が決済端末６に送られ、決済端末６からこの電子マネー番号が電子マネーサーバ２に送られる。電子マネーサーバ２は、当該電子マネーに紐付けられているギフトＩＤをギフトサーバ２００から検索する。検索した結果、ギフトＩＤが存在した場合、そのギフト内容を取得し、その内容と決済内容が一致すれば、電子マネーサーバ２は、決済端末６に対して、当該ギフトの内容を加味した決済を行うように指示する。
【００５８】
まず、図１２、図１３は、端末側バリュー残高とサーバ側バリュー残高とが併存するハイブリッド型電子マネーシステムにおいて、端末側バリュー残高を用いた決済処理を説明するためのフローチャートである。なお、ここで用いる決済端末６は、電子マネーサーバ２とリアルタイムでアクセスしている同期型の決済端末６である。
まず、店舗において、決済端末６は、店員の手入力又はバーコードの読取りなどにより、決済内容を取得する（ステップ１００）。ここで、決済内容とは、品目と価格である。
ここで、店員は、ユーザＢに対して、携帯端末Ｂをリーダライタ部１３９にかざすように求め、このリーダライタ部１３９から携帯端末Ｂに電子マネー番号を要求する（ステップ１０５）。これを受けて、携帯端末Ｂの電子マネーアプリケーションは、電子マネー番号を決済端末６に送信する（ステップ１１０）。
【００５９】
このとき、ユーザＢがギフトを用いて決済を行う希望を伝えた場合に、電子マネーサーバ２に対してギフトＩＤを検索して、決済を行うように要求する。
しかし、ユーザＢからの要求がなくてもギフトを用いて決済するようにしてもよい。この場合、ユーザＢがギフトの存在を失念していてもギフトを用いて決済を行うことができる。決済完了時に、決済完了を報知する際、「Ａ氏からのギフトにより決済しました。」と表示するか、レシートにその旨を印字して出力するようにしてもよい。
【００６０】
決済端末６は、携帯端末Ｂから電子マネー番号を受信し（ステップ１１５）、ステップ１００で取得した決済内容と共に電子マネーサーバ２へ送信する（ステップ１２０）。
電子マネーサーバ２は、決済端末６から決済内容と電子マネー番号を受信した後（ステップ１２５）、受信した電子マネー番号から対応付けて登録されているギフトＩＤを検索する（ステップ１３０）。このギフトＩＤがギフトサーバ２００に登録されている場合は、ギフトサーバ２００を検索する。また、電子マネーサーバ２内のＤＢに登録されている場合は、そのＤＢを検索する。
その結果、受信した電子マネー番号に対応付けて登録されているギフトＩＤが存在した場合（ステップ１３５；Ｙ）、当該ギフトＩＤのギフト内容を取得する（ステップ１４０）。
【００６１】
そして、取得した当該ギフトＩＤのギフト内容とステップ１２０で取得した決済内容とが一致するか否かを判断する（ステップ１４５）。その結果、当該ギフトＩＤのギフト内容と決済内容とが一致した場合（ステップ１４５；Ｙ）、一致したギフト内容を加味して決済金額を確定する（ステップ１５３）。
一方、受信した電子マネー番号に対応付けて登録されているギフトＩＤが存在しない場合（ステップ１３５；Ｎ）、又は当該ギフトＩＤのギフト内容と決済内容とが一致しない場合（ステップ１４５；Ｎ）、電子マネーサーバ２は、ステップ１２０で取得された決済内容に基づき決済金額を確定する（ステップ１５２）。
【００６２】
決済金額が確定すると、電子マネーサーバ２は、端末側バリュー残高の減算要求を携帯端末ＢのＩＣモジュール３０に送信する。この送信は、決済端末６を介して行う（ステップ１６０）。
この端末側バリュー残高の減算要求を受信した携帯端末ＢのＩＣモジュール３０は、端末側バリュー残高の減算処理を行い（ステップ１６５）、端末側バリュー残高の減算処理が完了した旨を決済端末６を介して電子マネーサーバ２に通知する（ステップ１７０）。
【００６３】
端末側バリュー残高の減算処理が完了した旨の通知を受けた電子マネーサーバ２は、決済完了通知を決済端末６に送信する（ステップ１７５）。この決済完了通知を受けた決済端末６は、決済が完了した旨の報知（例えば、決済の完了を示す決済音を発する）を行う（ステップ１８０）。
一方、電子マネーサーバ２は、ログデータＤＢに利用ログデータを登録するとともに（ステップ１８５）、ギフトが利用された場合には当該ギフトＩＤに関するギフトの処理が完了した旨を登録して（ステップ１９０）、処理を終了する。ギフトＤＢの更新は、ギフトがギフトサーバ２００に登録されている場合には、当該ギフトサーバ２００に、電子マネーサーバ内のＤＢに登録されている場合は、当該ＤＢに「済」の登録を行う。
【００６４】
次に、図１４を参照して、端末側バリュー残高とサーバ側バリュー残高とが併存するハイブリッド型電子マネーシステムにおいて、サーバ側バリュー残高を用いた決済処理を説明する。ここで用いる決済端末６も、電子マネーサーバ２とリアルタイムでアクセスしている同期型決済端末である。
なお、図１２のフローチャートと同一の処理は、同一のステップ番号を付して説明する。
ステップ１００からステップ１４５までは、図１２のフローチャートと同一の処理を行うため、説明を省略する。
そして、ステップ１４５で、電子マネーサーバ２が、取得した当該ギフトＩＤのギフト内容とステップ１２０で取得した決済内容とが一致すると判断した場合（ステップ１４５；Ｙ）、ギフト内容を加味した決済を行う（ステップ１４７）。具体的には、「コーヒー２００円割引き」、「コーラ１本無料」などに対応した決済価格を算出し、算出した決済価格に基づいて決済を行う。この決済は、算出した決済価格分のサーバ側バリュー残高を減算することにより行う。
ギフトＩＤが存在しない場合（ステップ１３５；Ｎ）、及びギフト内容と決済内容に一致がない場合（ステップ１４５；Ｎ）、通常の決済を行う（ステップ１４６）。すなわち、決済価格分のサーバ側バリュー残高を減算する。
【００６５】
その後、電子マネーサーバ２は、決済完了通知を決済端末６に送信する（ステップ１７５）。そして、決済端末６は、決済が完了した旨の報知（例えば、決済の完了を示す決済音を発する）を行う（ステップ１８０）。
一方、電子マネーサーバ２は、ギフトが利用された場合には当該ギフトＩＤに関するギフトの処理が完了した旨を登録して（ステップ１９０）、処理を終了する。
【００６６】
次に、図１２、図１３の処理の変形例を、図１５、図１６、図１７のフローチャートを参照して説明する。
この変形例も端末側バリュー残高とサーバ側バリュー残高とが併存するハイブリッド型電子マネーシステムにおいて、端末側バリュー残高を用いた決済処理を行う。
ここで用いる決済端末６は、電子マネーサーバ２とリアルタイムでアクセスしている同期型決済端末である。なお、図１２、図１３のフローチャートと同一の処理は、同一のステップ番号を付して説明する。
この変形例では、ギフトＩＤのギフト内容を電子マネーサーバ２から決済端末６に送信し、ギフト内容と決済内容に一致があるか否かを決済端末側で判断することを特徴としている。
【００６７】
ステップ１００からステップ１１５までは、同一の処理である。そして、決済端末６から電子マネーサーバ２へ電子マネー番号を送信する（ステップ１２１）。ここでは、決済内容を送信する必要がない。
そして、電子マネーサーバ２は、決済端末６から電子マネー番号を受信した後（ステップ１２６）、受信した電子マネー番号から対応付けて登録されているギフトＩＤを検索する（ステップ１３０）。このギフトＩＤがギフトサーバ２００に登録されている場合は、ギフトサーバ２００を検索する。また、電子マネーサーバ２内のＤＢに登録されている場合は、そのＤＢを検索する（ステップ１３５）。
その結果、受信した電子マネー番号に対応付けて登録されているギフトＩＤが存在した場合（ステップ１３５；Ｙ）、当該ギフトＩＤのギフト内容を取得する（ステップ１４０）。
そして、その取得した当該ギフトＩＤのギフト内容を決済端末６に送信する（ステップ１５１）。一方、受信した電子マネー番号に対応付けて登録されているギフトＩＤが存在しなかった場合（ステップ１３５；Ｎ）、ギフトが存在しない旨の通知を送信する（ステップ１４９）。
【００６８】
決済端末６は、ステップ１００で取得した決済内容との関係で適用可能なギフトがあるか否かを判断する（ステップ１５５）。適用可能なギフトがない場合（ステップ１５５；Ｎ）、ステップ１００で取得した決済内容に基づき決済金額を確定する（ステップ１５６）。
一方、適用可能なギフトがあった場合（ステップ１５５；Ｙ）、ギフト内容を加味して決済金額を確定する（ステップ１５７）。
決済金額が確定すると、決済端末６は、電子マネーサーバ２に、決済金額を指定した決済依頼を送信するとともに、ギフトが利用された場合はさらにギフト利用通知を送信する（ステップ１５８）。
ステップ１６０からステップ１９０の処理は、図１３と同様である。
【００６９】
次に、他の変形例を説明する。
この変形例では、携帯端末Ｂが、予めギフトＩＤを保持していることを前提とする。携帯端末Ｂが、予めギフトＩＤを保持するために、図１０のステップ７５で、送金完了通知を受信する際に、同時に電子マネーサーバ２からギフトＩＤも受信するようにする。
そして、受信したギフトＩＤを記憶部１８又はＩＣモジュール３０の記憶部２７に記憶させる。
【００７０】
次に、決済を行う際に、決済端末６は、電子マネー番号と当該ギフトＩＤを取得し、電子マネーサーバ２から当該ギフトＩＤのギフト内容を取得し、決済内容と一致していれば、ギフト内容を加味した決済を行うようにする。
この変形例によれば、ギフトサーバ２００又は電子マネーサーバ２のＤＢに電子マネー番号とギフトＩＤの組を保持しておく必要がなくなる。
【００７１】
また、決済端末にギフトＩＤのギフト内容を保持しておけば、決済端末の側で、ギフトの内容を加味した決済を行うか否かを判断することができる。
そのため、リアルタイムで電子マネーサーバ２と接続することができない非同期決済端末７であってもこのサービスを実現することができる。
なお、複数の店舗で利用可能で、かつ、利用回数に制限のあるギフトについては、決済端末から共通してアクセス可能なサーバ側（例えば、電子マネーサーバ２、ギフトサーバ２００）にて利用の有無を管理する態様が好ましい。
【００７２】
次に、リアルタイム移転について説明する。
通常、銀行振込みで送金を行う場合、他行振込みの場合や、営業時間外の振込みのとき、リアルタイムで送金を行うことができず、移転が翌営業日扱いとなることがある。電子マネー送金では、営業時間、送金先に拘わらず、リアルタイムで送金を行うことができる。
一方、電子マネーで送金を行う場合、リアルタイムで行うか否かをオプションとして設定し、リアルタイムで行うオプションが選択されなかった場合、ギフトを付加するようにしてもよい。すなわち、ユーザＡに、リアルタイム移転かリアルタイムでないギフト付き移転かを選択させるようにする。
このように、電子マネーの送金に一定の制限が付される場合に限り、ギフトの付加が可能になるように構成してもよい。
【００７３】
また、ユーザＢが、用途限定の解除を不可として電子マネーの送金を受けた場合、その用途限定の額に応じてギフトによる特典（還元率、割引率）を上昇させるようにしてもよい。
また、ユーザＢが、電子ギフトの適用条件を満たすように電子マネーを利用した場合に、広告主又は電子マネーサービス事業者の負担により、ユーザＡに価値を還元してもよい。例えば、ユーザＡのサーバ側バリュー残高を更新するとよい。
【符号の説明】
【００７４】
１  電子マネーシステム
２  電子マネーサーバ
３  インターネット
４  電子マネーカード
５  携帯端末
６  決済端末
７  非同期決済端末
８  通信回線
１１  ＣＰＵ
１２  ＲＯＭ
１３  ＲＡＭ
１４  入力部
１５  出力部
１６  通信制御部
１７  近距離通信制御部
１８  記憶部
１９  バスライン
２０  マイクロフォン
２１  加速度センサ
２２  ＧＰＳ受信機
２６  情報処理部
２７  記憶部
２９  電子マネーアプリケーション
３０  ＩＣモジュール
３１  ＣＰＵ
３２  ＲＯＭ
３３  ＲＡＭ
３４  通信制御部
３５  記憶部
３６  バスライン
【図１】
0005918866.tif 000002
【図２】
0005918866.tif 000003
【図３】
0005918866.tif 000004
【図４】
0005918866.tif 000005
【図５】
0005918866.tif 000006
【図６】
0005918866.tif 000007
【図７】
0005918866.tif 000008
【図８】
0005918866.tif 000009
【図９】
0005918866.tif 000010
【図１０】
0005918866.tif 000011
【図１１】
0005918866.tif 000012
【図１２】
0005918866.tif 000013
【図１３】
0005918866.tif 000014
【図１４】
0005918866.tif 000015
【図１５】
0005918866.tif 000016
【図１６】
0005918866.tif 000017
【図１７】
0005918866.tif 000018