JP2007148593A - 情報通信システム、決済仲介装置及び情報端末装置 - Google Patents

Abstract

【課題】 異なる決済システム間で送金処理を行うことができる情報通信システム等を提供する。
【解決手段】 送金側の携帯電話端末装置１０のユーザがメッセージの送信時に現金情報の添付を要求すると、電子メールクライアント１２０は、添付する現金情報の種類（電子通貨等）の選択を要求する。決済処理部１４０は選択された種類に応じた現金情報を生成し、電子メールクライアント１２０が生成された現金情報を添付したメッセージを送信する。ＤＣＳ３１の配信管理部３１ｂは、現金情報が添付されたメッセージを受信すると、送金先のユーザの携帯電話端末装置１０にその旨を通知する。送金先のユーザが受領に用いる電子通貨等を選択すると、電子メールクライアント１２０はＤＣＳ３１に、対応する決済サーバ５１．５２，５３に対する受領処理を要求する。
【選択図】 図１

Description

本発明は、異なる決済システム間で送金処理を行うことができる情報通信システム等に関する。

不正な書き換え等を防止した電子情報を金額情報として扱い、電子通貨として決済を行い得るようにした電子通貨システムが知られている（例えば特許文献１参照。）。

また、ＦｅｌｉＣａ（登録商標）等の非接触ＩＣカードを用いたＥｄｙ（登録商標）やＳｕｉｃａ（登録商標）等の電子通貨システムも普及しつつある。さらに、ＦｅｌｉＣａ（登録商標）の機能を搭載した携帯電話も普及しつつある（例えば特許文献２）。

これらの電子通貨システムでは、同一の電子通貨間であれば、電子通貨による送金処理を実現できる可能性がある。
特許第３２６３６７３号公報（第３頁−第５頁、図１） 特許第３５６２６４７号公報（第４頁−第７頁、図１、図２）

しかしながら、従来の電子通貨システムでは、異なる電子通貨間での決済処理は考慮されておらず、異なる電子通貨間での送金処理をあきらめるか、複数のシステムを別個に利用する必要があった。

また、送金処理を行うためには、送金しようとする相手が電子通貨を利用できるか否か、あるいは、利用できる電子通貨の種類等を、送金しようとする者が予め知っている必要があり、確認等の作業が繁雑であった。

本発明は、上述のような課題に鑑みてなされたものであり、異なる決済システム間で送金処理を行うことができる情報通信システム等を提供することを目的とする。また、本発明は、電子メールのメッセージを用いて簡単に送金処理を行うことができる情報通信システム等を提供することを目的とする。

上述の問題を解決するために、本発明の請求項１に係る情報通信システムは、少なくとも２つの異なる電子通貨システムに対して決済を要求する情報を生成し得る決済要求手段と，電子通貨システムに対して決済を要求する情報（決済情報）を電子メールのメッセージに添付して送信する添付制御手段と，ユーザからの指示に応じてメッセージに添付する決済情報の種類の選択を行う選択手段とを有する情報端末装置と、各電子通貨システム毎に設けられた決済センタの口座を管理する口座管理手段と，この情報端末装置からのメッセージに添付されている決済情報の種類に対応する決済センタの口座に対して当該決済情報によって指定された金額の決済を行う収納処理手段とを有する決済仲介装とを備えることを特徴とする。

この情報通信システムでは、情報端末装置の選択手段が、ユーザからの指示に応じて、メッセージに添付する決済情報（電子通貨システムに対して決済を要求する情報）の種類の選択を行い、添付制御手段が、選択された決済情報を電子メールのメッセージに添付して送信する。決済仲介手段の収納処理手段は、情報端末装置からのメッセージに添付されている決済情報の種類に対応する決済センタの口座に対して当該決済情報によって指定された金額の決済を行う。

また、本発明の請求項２に係る情報通信システムは、請求項１に係る情報通信システムにおいて、決済仲介装置が、メッセージの宛先に対応するユーザの情報端末装置からの要求に応じて、当該要求中で指定された種類の電子通貨システムの口座に、当該電子通貨システムに対する決済センタの口座から決済情報中で指定された金額の決済を行う領収処理手段を備えることを特徴とする。

この情報通信システムでは、決済仲介装置の領収処理手段が、メッセージの宛先に対応するユーザの情報端末装置からの要求に応じて、当該要求中で指定された種類の電子通貨システムの口座に、当該電子通貨システムに対する決済センタの口座から決済情報中で指定された金額の決済を行う。

また、本発明の請求項４に係る決済仲介装置は、少なくとも２つの異なる電子通貨システムに対する決済センタの口座を管理する口座管理手段と、情報端末装置からのメッセージに添付された，電子通貨システムに対して決済を要求する情報（決済情報）の種類に対応する決済センタの口座に対して当該決済情報によって指定された金額の決済を行う収納処理手段と、メッセージの宛先に対応するユーザの情報端末装置からの要求に応じて、当該要求中で指定された種類の電子通貨システムの口座に、当該電子通貨システムに対する決済センタの口座から決済情報中で指定された金額の決済を行う領収処理手段とを備えることを特徴とする

この決済仲介装置では、収納処理手段が、情報端末装置からのメッセージに添付されている決済情報の種類に対応する決済センタの口座に対して当該決済情報によって指定された金額の決済を行い、領収処理手段が、メッセージの宛先に対応するユーザの情報端末装置からの要求に応じて、当該要求中で指定された種類の電子通貨システムの口座に、当該電子通貨システムに対する決済センタの口座から決済情報中で指定された金額の決済を行う。

また、本発明の請求項６に係る情報端末装置は、少なくとも２つの異なる電子通貨システムに対して決済を要求する情報を生成し得る決済要求手段と、電子通貨システムに対して決済を要求する情報（決済情報）を電子メールのメッセージに添付して送信する添付制御手段と、ユーザからの指示に応じて、メッセージに添付する決済情報の種類の選択を行う選択手段とを備えることを特徴とする。

この情報端末装置では、選択手段が、ユーザからの指示に応じて、メッセージに添付する決済情報（電子通貨システムに対して決済を要求する情報）の種類の選択を行い、添付制御手段が、選択された決済情報を電子メールのメッセージに添付して送信する。

また、本発明の請求項７に係る情報端末装置は、少なくとも２つの電子通貨システムに対して決済を行い得る決済仲介装置から決済情報が添付されたメッセージを受信した旨の通知を受信する通知受信手段と、通知に応じて，受領に用いる電子通貨システムの選択を入力する選択入力手段と、選択された電子通貨システムの種類及び口座を示す情報を決済仲介装置に送信する領収要求手段と、要求に応じた決済仲介装置からの指示に応じて電子通貨システムによる決済を行う決済手段とを備えることを特徴とする。

この情報端末装置では、選択入力手段が、決済仲介装置から決済情報が添付されたメッセージを受信した旨の通知に応じて，受領に用いる電子通貨システムの選択を入力し、領収要求手段が、選択された電子通貨システムの種類及び口座を示す情報を決済仲介装置に送信し、決済手段が、要求に応じた決済仲介装置からの指示に応じて電子通貨システムによる決済を行う。

本発明の請求項１に係る情報通信システムでは、情報端末装置の選択手段が、ユーザからの指示に応じて、メッセージに添付する決済情報（電子通貨システムに対して決済を要求する情報）の種類の選択を行い、添付制御手段が、選択された決済情報を電子メールのメッセージに添付して送信する。決済仲介手段の収納処理手段は、情報端末装置からのメッセージに添付されている決済情報の種類に対応する決済センタの口座に対して当該決済情報によって指定された金額の決済を行うことにより、メッセージに添付する決済情報を異なる電子通貨システムのいずれかから選択することができる。これにより、ユーザは複数の電子通貨システムから決済に用いるものを選択することができ、利便性の向上に寄与することができる。また、メッセージに決済情報を添付して送信を行うことにより、ユーザに電子メールのメッセージにより送金を行うような操作感を与えることができ、操作性の向上に寄与することができる。

本発明の請求項２に係る情報通信システムでは、決済仲介装置の領収処理手段が、メッセージの宛先に対応するユーザの情報端末装置からの要求に応じて、当該要求中で指定された種類の電子通貨システムの口座に、当該電子通貨システムに対する決済センタの口座から決済情報中で指定された金額の決済を行うことにより、メッセージの宛先のユーザが、送信側のユーザが用いた電子決済システムとは独立に、受領に用いる電子通貨システムを選択することができる。これにより、ユーザの利便性の向上に寄与することができる。

本発明の請求項４に係る決済仲介装置では、収納処理手段が、情報端末装置からのメッセージに添付されている決済情報の種類に対応する決済センタの口座に対して当該決済情報によって指定された金額の決済を行い、領収処理手段が、メッセージの宛先に対応するユーザの情報端末装置からの要求に応じて、当該要求中で指定された種類の電子通貨システムの口座に、当該電子通貨システムに対する決済センタの口座から決済情報中で指定された金額の決済を行うことにより、メッセージの宛先のユーザが、送信側のユーザが用いた電子通貨システムと異なる電子通貨システムを用いた場合でも決済を行うことができる。これにより、ユーザの選択の幅を広げ、利便性の向上に寄与することができる。

本発明の請求項６に係る決済仲介装置では、選択手段が、ユーザからの指示に応じて、メッセージに添付する決済情報（電子通貨システムに対して決済を要求する情報）の種類の選択を行い、添付制御手段が、選択された決済情報を電子メールのメッセージに添付して送信することにより、メッセージに添付する決済情報を異なる電子通貨システムのいずれかから選択することができる。これにより、ユーザは複数の電子通貨システムから決済に用いるものを選択することができ、利便性の向上に寄与することができる。また、メッセージに決済情報を添付して送信を行うことにより、ユーザに電子メールのメッセージにより送金を行うような操作感を与えることができ、操作性の向上に寄与することができる。

本発明の請求項７に係る決済仲介装置では、選択入力手段が、決済仲介装置から決済情報が添付されたメッセージを受信した旨の通知に応じて，受領に用いる電子通貨システムの選択を入力し、領収要求手段が、選択された電子通貨システムの種類及び口座を示す情報を決済仲介装置に送信し、決済手段が、要求に応じた決済仲介装置からの指示に応じて電子通貨システムによる決済を行うことにより、メッセージの宛先のユーザが、送信側のユーザが用いた電子決済システムとは独立に、受領に用いる電子通貨システムを選択することができる。これにより、ユーザの利便性の向上に寄与することができる。

本発明は、例えば複数の電子通貨システム間で決済を行い得る情報通信システムに適用することができる。

（全体構成）
この情報通信システムは、例えば図１に示すように、携帯電話端末装置（ＵＥ：User Equipment）１０と、この携帯電話端末装置１０との間で無線通信サービスを提供する移動体通信網２０と、決済仲介サーバ（ＣＣＳ：Cash Control Server）３０と、ファイアウォール（Ｆ／Ｗ）４０と、このＦ／Ｗ４０を介してＣＣＳ３０と接続され，ユーザ（当該情報通信システムの加入者）の口座からの決済を行う決済サーバ群５０とを備えている。

決済サーバ群５０は、例えばＳｕｉｃａ等の第１の電子通貨による決済を行う第１の決済サーバ（電子通貨Ｓ）５１と、例えばＥｄｙ等の第１の電子通貨とは異なる第２の電子通貨による決済を行う第２の決済サーバ（電子通貨Ｅ）５２と、例えば銀行口座に対する振込等を行う決済サーバ（銀行）５３と、これら以外の例えばクレジットカード等の手段による決済を行う決済サーバ（その他）とを備えている。

この情報通信システムでは、異なる決済手段の間（例えば電子通貨Ｓと電子通貨Ｅの間、あるいはこれらの電子通貨と銀行口座の間）で送金処理を行うことができるようになっている。

携帯電話端末装置１０は、例えば移動体通信網２０と通信を行う高周波（ＲＦ：Radio Frequency）部１１と、ＭＰＵ（Micro Processing Unit）１２と、メモリ（図示せず）と、ＦｅｌｉＣａ（登録商標）チップ等の非接触ＩＣ１３と、ＰＩＮ（Personal Identity Number）コード等のユーザの識別情報等が格納されたＳＩＭ（Subscriber Identity Module）１４と、ユーザからの指示を入力する操作キー１５と、液晶ディスプレイ等からなる表示部１６と、音声通話を行うための音声ＣＯＤＥＣ１７，スピーカ１８，ＭＩＣ１９等を備えている。

また、ＭＰＵ１２は、例えばメモリに保持されている制御プログラムの実行により、ＲＦ部１１，操作キー１５，表示部１６，音声ＣＯＤＥＣ１７を含む携帯電話端末装置１０全体の動作を制御する。また、ＭＰＵ１２は、制御プログラムの実行により、携帯電話端末装置１０全体の通信を制御する通信制御部１１０，電子メールサービスを利用する電子メールクライアント１２０，ＨＴＴＰサービスを利用するＷｅｂブラウザ１３０，決済処理を実行する決済処理部１４０等としても機能する。

メモリは、例えば音声通信，データ通信等のデータを一時的に保持するバッファ、携帯電話端末装置１０の動作設定，制御プログラムの実行時の変数，電子メールのメッセージ等を格納する保持部等として用いられる。

移動体通信網２０は、例えば無線アクセス系としてＷ−ＣＤＭＡ（Wideband Code Division Multiple Access）方式，コアネットワーク系としてＧＰＲＳ（General Packet Radio Service）方式を採用したデジタル無線通信網等からなる。この移動体通信網２０は、携帯電話端末装置１０との間で無線通信を行う基地局装置（ＮＢ：ＮｏｄｅＢ）２１ａ，２１ｂ，…，２１ｎと、各基地局装置２１ａ〜２１ｎの制御を行うＲＮＣ（Radio Network Controller）２２と、コアネットワーク（ＣＮ）を構成するＳＧＳＮ（Serving GPRS Support Node）２３及びＧＧＳＮ（Gateway GPRS Support Node）２４と、移動体通信網２０の加入者の情報を保持するＤＳ（ディレクトリサーバ：Directory Server）２５と、ＭＳＣ（Mobile Switching Circuit）２６と、ショートメッセージサービスを提供するショートメッセージセンタ（ＳＭＳＣ：Short Message Service Center）２７と、ショートメッセージの送信管理等を行うＰＰＧ（Push Proxy Gateway）２８とを備えている。

ＣＣＳ３０は、例えば決済を要求するメッセージの配信管理を行うＤＣＳ（デリバリコトロールサーバ：Delivery Control Server）３１と、決済処理に関する電子メールのメッセージを保持するＭＢ（メールボックス：Mail Box）３２と、ユーザの口座等に対する振り込み，送金等の決済処理を行うＡＳ（アカウントサーバ：Account Server）３３とを備えている。これら各サーバは、図示しないＣＰＵ、ＲＡＭ、ＲＯＭ、ハードディスクドライブ（ＨＤＤ）や光ディスクドライブ等からなる記憶装置、あるいはシステムバスなどからなるハードウェアを備えている。そして、これらのハードウェア上で所定のプログラムを実行することにより、処々の機能を実現している。各処理を動作させるためのプログラムはＲＯＭや記憶装置に記憶されており、必要に応じてＣＰＵやＲＡＭ上の作業エリアに呼び出されて実行される。なお、これらのサーバは１台のコンピュータシステムで構成してもいいし、複数のサーバ機能をそれぞれ受け持つ複数台のコンピュータをネットワークで結んで構成するようにしてもよい。

この情報通信システムでは、メッセージの配信サービスとして、ＳＭＳ（Short Message Service）と、ＭＭＳ（Multimedia Messaging Service）の２系統の電子メールサービスとを利用することができるようになっている。電子メールクライアント１２０は、メッセージのサイズ，添付ファイルの有無，送信先あるいはユーザの選択等に応じて、いずれのサービスを利用するか選択する。

携帯電話端末装置１０から送信されたＳＭＳのメッセージは、ＮＢ２１ａ（ＮＢ２１ｂ，…，２１ｎ），ＲＮＣ２２，ＭＳＣ２６を経由してＳＭＳＣ２７に供給される。このように送信されたＳＭＳのメッセージは、いわゆるＷＡＰ Ｐｕｓｈと言われる動作により、ＳＭＳＣ２７から、ＭＳＣ２６，ＲＮＣ２２，ＮＢ２１ａ（ＮＢ２１ｂ，…，２１ｎ）を経由して携帯電話端末装置１０に供給されるようになっている。

この情報通信システムでは、ＤＣＳ３１は、ＭＭＳのメッセージの送受信を行うメールサーバ（ＳＭＴＰ／ＰＯＰ［あるいはＩＭＡＰ］サーバ）３４の機能として実装されている。上述のＭＭＳのメッセージを送信する際には、当該メッセージは、携帯電話端末装置１０から、ＮＢ２１ａ（ＮＢ２１ｂ，…，２１ｎ），ＲＮＣ２２，ＳＧＳＮ２３，ＧＧＳＮ２４，ＤＣＳ３１を経由してＭＢ３２に格納される。ＤＣＳ３１は、ＭＭＳのメッセージを受信すると、ＭＭＳのメッセージを受信した旨を通知するＳＭＳのメッセージを生成し、ＰＰＧ２８経由で当該ＭＭＳのメッセージの宛先のユーザの携帯電話端末装置１０宛に送信する。

このようなＳＭＳのメッセージを確認したユーザからの指示があると、電子メールクライアント１２０は、ＭＢ３２に対してＭＭＳのメッセージの送信を要求する。これに応じてＭＢ３２は、要求されたＭＭＳのメッセージを携帯電話端末装置１０宛に送信する。このメッセージは、ＭＢ３２から、ＧＧＳＮ２４，ＳＧＳＮ２３，ＲＮＣ２２，ＮＢ２１ａ（ＮＢ２１ｂ，…，２１ｎ）を経由して、携帯電話端末装置１０に供給される。

携帯電話端末装置１０の非接触ＩＣ１３には、例えば図２に示すように、電子通貨Ｓにおける識別情報（ＩＤ），残高等を記憶する記憶領域１３１と、電子通貨Ｅにおける識別情報（ＩＤ），残高等を記憶する記憶領域１３２と、記憶領域１３１，１３２に対するアクセスを制御するアクセス制御部１３３と、外部のリーダライタ等の装置との通信を制御する通信制御部１３４とが設けられている。

通信制御部１３４は、外部のリーダライタ等の装置と非接触で通信を行うことができるようになっている。アクセス制御部１３３と決済処理部１４０は、配線等を介して接続されている。決済処理部１４０には、記憶領域１３１（電子通貨Ｓ）に対するアクセス手順等を定義したＡＰＩ（Application Program Interface）１４１と、記憶領域１３２（電子通貨Ｅ）に対するアクセス手順，データ等を定義したＡＰＩ１４２と、決済サーバ５３に対するアクセス手順，データ等を定義したＡＰＩ１４３とが設けられている。電子メールクライアント１２０は、これらのＡＰＩ１４１，１４２，１４３を利用して電子通貨Ｓ，電子通貨Ｅあるいは銀行口座における現金情報を添付したメッセージの送受信等を行うことができるようになっている。

ＭＢ３２には、例えば図３に示すように、現金情報が添付されたメッセージを格納する領域３２２と、これ以外の通常のメッセージを格納する領域３２３と、これらのメッセージの管理情報を格納する領域３２１とが設けられている。現金情報が添付されたメッセージは、送信者からのメッセージ（支払要求）と、受信者に対するメッセージ（領収要求）で１つの単位として格納されている。

各領域３２２，３２３に格納されるメッセージは、例えば図４に示すように、メッセージ毎にメールアドレス等の送信元の識別情報（Origination ID），送信先の識別情報（Destination ID），メッセージＩＤ（Mail ID），メッセージのデータ（Mail Data）を有している。具体的には、各々のメッセージは、例えば図５に示すように構成されている。メッセージヘッダ２０１中のＦｒｏｍフィールドがOrigination IDに、ＴｏフィールドがDestination IDに、Ｍｅｓｓａｇｅ−ＩＤフィールドがMail IDに、それぞれ対応している。また、メール本文２０２がMail Dataに対応している。

また、添付ファイル２０２ｂ中の現金情報“cash.dat”は、例えば図６に示すように、当該添付ファイルに対応する電子通貨等の種類を示す情報（Attached Type）と、当該電子通貨等の識別情報（ＩＤ）と、添付した金額を示す情報（Attached Price）等の情報が所定の手順で暗号化・符号化されて含まれている。

また、ＤＣＳ３１は、例えば上述の図３に示すように、メッセージの管理情報を保持する管理ＤＢ３１ａと、メッセージの配信管理を行う配信管理部３１ｂとを有している。管理ＤＢ３１ａには、現金情報が添付されているメッセージ毎に、例えば図７に示すように、メールアドレス等の送信元の識別情報（Origination ID）．送信先の識別情報（Destination ID），メッセージＩＤ（Mail ID），添付金額（Attached price），添付された現金情報の種類（Attached Type），メッセージの処理状況（Mail Status）等を示す情報が格納されている。メッセージの処理状況は、例えば「Ｍａｉｌ送信」，「Ｍａｉｌ受信」，「入金処理」，「出金処理」等のパラメータを含んでいる。各パラメータは、例えば「未」あるいは「済」の値を取り得るようになっている。具体的には、例えば「Ｍａｉｌ送信＝未」といった文字データから構成することができる。

配信管理部３１ｂは、受信したメッセージに現金情報が添付されている場合には、当該メッセージを決済メッセージ格納領域３２２に格納し、当該メッセージについての情報を上述の管理ＤＢ３１ａに登録し、配信管理を行う。一方、受信したメッセージに現金情報が添付されていない場合には、当該メッセージを通常メッセージ格納領域３２３に格納し、通常のメッセージと同様の配信管理を行う。

また、この情報通信システムでは、ＣＣＳ３０を仮想的に決済センタとし、電子通貨Ｓ，電子通貨Ｅ，銀行等の決済システム毎に対応させて決済センタの口座を設けている。このため、ＡＳ３３には、例えば上述の図３に示すように、決済センタの銀行口座に対する入出金処理を行う銀行口座管理部３３３と、決済センタの電子通貨Ｓ口座に対する入出金処理を行う電子通貨Ｓ口座管理部３３１と、決済センタの電子通貨Ｅ口座に対する入出金処理を行う電子通貨Ｅ口座管理部３３２と、決済処理を行う決済処理部３３５と、決済サーバ群５０との間の通信処理等を行う通信処理部３３６とを有している。

現金情報を添付したメッセージを送受信する際に、携帯電話端末装置１０，ＤＣＳ３１，ＭＢ３２，ＡＳ３３，ＤＳ２５，決済サーバ群５０等の間で送受信するコマンドは、例えば図８〜図１３に示すように定義されている。これらの図中では、「方向」欄の矢印が、対応する装置間のコマンドの向きを示している。例えば図８中では、右矢印が、携帯電話端末装置１０からＤＣＳ３１に対するコマンド、左矢印がＤＣＳ３１から携帯電話端末装置１０に対するコマンドであることを示している。

携帯電話端末装置１０とＤＣＳ３１との間のコマンドは、例えば図８に示すように定義されている。Ｍｏｎｅｙ Ｓｕｂｍｉｔコマンドは、現金情報を添付したメッセージを送金するコマンドである。Ｍｏｎｅｙ Ｎｏｔｉｆｙコマンドは、現金情報が添付されているメッセージを受信した旨を携帯電話端末装置１０に通知するコマンドである。Ｄｅｌｉｖｅｒ Ｒｅｑｕｅｓｔコマンドは、現金情報が添付されているメッセージの現金データ以外の部分の受信を要求するコマンドであり、Ｄｅｌｉｖｅｒ Ｍｅｓｓａｇｅコマンドは、これに対する応答としてメッセージの現金データ以外の部分を携帯電話端末装置１０に供給するコマンドである。Ｍｏｎｅｙ Ｒｅｑｕｅｓｔコマンドは、携帯電話端末装置１０が現金情報の受信を要求するコマンドである。これらのコマンドの他に、電子メールのメッセージの送受信等の一般的なコマンドが別途定義されている。

ＤＣＳ３１とＭＢ３２との間のコマンドは、例えば図９に示すように定義されている。Ｓａｖｅ Ｒｅｑｕｅｓｔコマンドは、ＭＢ３２にメッセージの保存を要求するコマンドである。Ｄｅｌｉｖｅｒ Ｒｅｑｕｅｓｔコマンドは、メッセージの現金情報以外の部分の受信（ＭＢ３２からの読み出し）を要求するコマンドであり、Ｄｅｌｉｖｅｒ Ｍｅｓｓａｇｅコマンドは、これに対する応答としてＭＢ３２から読み出されたメッセージの現金情報以外の部分を供給するコマンドである。Ｄｅｌｅｔｅ Ｒｅｑｕｅｓｔコマンドは、ＭＢ３２にメッセージの削除を求めるコマンドである。これらのコマンドの他に、ＭＢ３２に対してメッセージの読み出し，転送等を要求する一般的なコマンドが定義されている。

ＤＣＳ３１とＡＳ３３との間のコマンドは、例えば図１０に示すように定義されている。Ｄｅｐｏｓｉｔ Ｒｅｑｕｅｓｔコマンドは、決済センタの口座からの電子通貨の出金を要求するコマンドである。Ｃｈａｒｇｅ Ｒｅｑｕｅｓｔコマンドは、決済センタの口座に対する電子通貨の入金を要求するコマンドである。Ｃｈａｒｇｅ Ｉｎｆｏｒｍａｔｉｏｎコマンドは、決済センタの口座に対する入出金があったことを通知するコマンドである。

ＤＣＳ３１とＤＳ２５との間のコマンドは、例えば図１１に示すように定義されている。Ｓｕｂｓｃｒｉｂｅｒ Ｄａｔａ Ｒｅｑｕｅｓｔコマンドは、ユーザ（加入者）についての情報を要求するコマンドであり、Ｓｕｂｓｃｒｉｂｅｒ Ｄａｔａコマンドは、これに対する応答として加入者の情報を供給するコマンドである。

ＡＳ３３と決済サーバ群５０との間のコマンドは、例えば図１２に示すように定義されている。Ｃａｓｈ Ｄａｔａ Ｓｙｎｃｈｒｏｎｉｚｅコマンドは、決済サーバ５１，５２に対して電子通貨の情報の同期を求めるコマンドである。Ｄｅｐｏｓｉｔ Ｒｅｑｕｅｓｔコマンドは、決済センタの口座からの電子通貨の出金を要求するコマンドである。Ｃｈａｒｇｅ Ｒｅｑｕｅｓｔコマンドは、決済センタの口座に対する電子通貨の入金を要求するコマンドである。

以上の他に、一般的なコマンドとして、例えば図１３に示すように、コマンドに対する応答（ＲＳＰ：Response）等が定義されている。

（動作：送金処理）
図１４は、メッセージの作成及び送信処理の例を示すフローチャートであり、図１５は、当該処理において携帯電話端末装置１０の表示部１６に表示される画像の例を示している。現金情報を添付したメッセージを作成する際には、ユーザはまず宛先・件名等を入力し（図１４中のＳ１）、メッセージの本文を入力する（Ｓ２）。この状態で、電子メールクライアント１２０は、例えば図１５（Ａ）に示すように、表示部１６にメッセージ本文を示す画像を表示させる。

この状態において、ユーザがファイルの添付を指示すると、電子メールクライアント１２０は、例えば図１５（Ｂ）に示すように、添付ファイルの種類の入力を求める画像を表示させる（Ｓ３）。これに応じてユーザが添付ファイルの種類を入力すると、電子メールクライアント１２０は、指示されたファイルの形式が「現金」か否かを判定する（Ｓ４）。指示されたファイルの形式が「現金」でない場合には、電子メールクライアント１２０は、指示されたファイルの形式に応じた処理を実行し（Ｓ５）、メッセージの送信処理を実行する（Ｓ１４）。

一方、指示されたファイルの形式が「現金」である場合には、電子メールクライアント１２０は、例えば図１５（Ｃ）に示すように、添付する「現金」の種類（送金に用いる電子通貨等）の選択を求める画像を表示させる。これに応じて、ユーザが選択を行うと、電子メールクライアント１２０は、ユーザの選択に応じて対応するＡＰＩ１４１，１４２，１４３を選択する（Ｓ６）。この後、電子メールクライアント１２０は、ＡＰＩ１４１，１４２，１４３を介して、記憶領域１３１，１３２からの識別情報の取得（Ｓ７，Ｓ８）あるいは銀行口座の口座番号の取得（Ｓ９）等の処理を行う。この後、例えば図１５（Ｄ）に示すような画像を表示させ、添付する金額を入力させる（Ｓ７，Ｓ８，Ｓ９）。

金額の入力が終了すると、電子メールクライアント１２０は、例えば図１５（Ｅ）に示す画像を表示させ、ユーザからの指示を待機する。ユーザからの指示があると、電子メールクライアント１２０は、送信指示であるか否かを判断し（Ｓ１０）、送信指示でなければ、一時保存（保存）や破棄（終了）といった他の指示に対応する処理を実行する（Ｓ１１）。送信指示である場合には、電子メールクライアント１２０は、例えば図１５（Ｆ）に示す画像を表示させ、ユーザにＰＩＮコードの入力を要求する（Ｓ１２）。これに応じてユーザがＰＩＮコードを入力すると、電子メールクライアント１２０は、ＳＩＭ１４に記録されているＰＩＮコードと比較し、正しいか否かを判断する（Ｓ１３）。誤っている場合には、ユーザにＰＩＮコードの再入力を求める（Ｓ１２）。入力されたＰＩＮコードが正しい場合には、電子メールクライアント１２０は、例えば図１５（Ｇ）に示す画像を表示させ、ＤＣＳ３１宛にメッセージを送信する（Ｓ１４）。メッセージの送信が正常に終了すると、電子メールクライアント１２０は、例えば図１５（Ｈ）に示す画像を表示させ、ユーザに、メッセージの送信が終了した旨を通知する。

この後、電子メールクライアント１２０は、メッセージに添付した現金情報に対応するＡＰＩ１４１，１４２を介して、記憶領域１３１，１３２に格納されている電子通貨の残高を添付した金額分、減少させる。

（電子通貨Ｅ）
図１６は、例えば電子通貨Ｅによる送金処理を行う際の情報通信システム全体の動作を示している。上述の図１４中のＳ１４における現金情報を添付したメッセージの送信は、上述の図８中のＭｏｎｅｙ Ｓｕｂｍｉｔコマンドによって行われる（Ｓ１０３）。このようなメッセージを受信すると、ＤＣＳ３１は、まず、Ｓｕｂｓｃｒｉｂｅｒ Ｄａｔａ ＲｅｑｕｅｓｔコマンドによりＤＳ２５に送信先のアドレスに対応するユーザ（加入者）についての情報を確認する（Ｓ１０４）。ユーザが現金情報を添付したメッセージの送受信サービスを利用できるか否かは、ユーザ毎にＤＳ２５に登録されている。現金情報を添付したメッセージを受領可能である場合には、ＤＣＳ３１は、上述の図１０中のＤｅｐｏｓｉｔ Ｒｅｑｕｅｓｔコマンドにより、ＡＳ３３に加入者の口座からの電子通貨の出金（決済センタの口座に対する入金）を要求する（Ｓ１０５）。これに応じて、ＡＳ３３は、Ｃａｓｈ Ｄａｔａ Ｓｙｎｃｈｒｏｎｉｚｅコマンドにより決済サーバ５２との間で電子通貨のデータを同期させ（Ｓ１０６）、Ｄｅｐｏｓｉｔ Ｒｅｑｕｅｓｔコマンドによりユーザの口座からの出金を決済サーバ５２に要求する（Ｓ１０７）。これに対する応答（ＲＳＰ）は、決済サーバ５３からＡＳ３３を経由してＤＣＳ３１に通知される（Ｓ１０８，Ｓ１０９）。

ＤＣＳ３１は、決済サーバ５２からの応答があると、当該メッセージについての管理情報を管理ＤＢ３１ａに登録し（Ｓ１１０）、携帯電話端末装置１０に現金情報を添付したメッセージの送信が終了したことを通知し（Ｓ１１１）、ＭＢ３２にＳａｖｅ Ｒｅｑｕｅｓｔコマンドと共に当該メッセージを供給する（Ｓ１１２）。ＭＢ３２は、当該メッセージを保存すると（Ｓ１１３）、ＤＣＳ３１に応答（ＲＳＰ）を送信する（Ｓ１１４）。

一方、携帯電話端末装置１０の電子メールクライアント１２０は、上述のＤＣＳ３１からの応答（Ｓ１１１）があると、ＡＰＩ１４２を介して、記憶領域１３２に格納されている電子通貨Ｅの残高を減少させる（Ｓ１１５）。

また、決済サーバ５２は、ＡＳ３３からのＤｅｐｏｓｉｔ Ｒｅｑｕｅｓｔコマンド（Ｓ１０７）を受信すると、ユーザの口座（電子通貨Ｅ）からの出金処理を実行し（Ｓ１２０）、Ｃｈａｒｇｅ ＲｅｑｕｅｓｔコマンドによりＡＳ３３に決済センタの口座（電子通貨Ｅ）に対する入金を要求する（Ｓ１２１）。ＡＳ３３の決済処理部３３５は、この要求に応じて、電子通貨Ｅ口座管理部３３２により決済センタの口座（電子通貨Ｅ）に入金処理を行って電子通貨Ｅの残高を増加させる（Ｓ１２２）。

入金処理が終了すると、ＡＳ３３は、決済サーバ５２に入金処理が終了した旨を示す応答（ＲＳＰ）を送信する（Ｓ１２３）。さらに、ＡＳ３３は、Ｃｈａｒｇｅ Ｉｎｆｏｒｍａｔｉｏｎコマンドにより、決済センタの口座に対する入出金があったことをＤＣＳ３１に通知する（Ｓ１２４）。ＤＣＳ３１は、これに応じて、管理ＤＢ３１ａ中の当該メッセージの処理状況を変更する（Ｓ１２５）。具体的には、例えば図７中のＭａｉｌ Ｓｔａｔｕｓを“入金処理＝済”にする。変更が終了すると、ＤＣＳ３１は、その旨をＡＳ３３に通知する（Ｓ１２６）。

以上の処理により、携帯電話端末装置１０のユーザの口座（電子通貨Ｅ）から決済センタの口座（電子通貨Ｅ）に送金が行われた状態となる。なお、電子通貨Ｓによる送金処理では、電子通貨Ｓにおける入出金処理に従って、上述の動作と同様に、ユーザの口座（電子通貨Ｓ）から決済センタの口座（電子通貨Ｓ）に送金が行われる。また、銀行の口座による送金処理では、例えば図１７に示すように、ＡＳ３３と銀行の決済サーバ５３の間で所定の手順で振込等の出金処理が行われ（Ｓ１０６’〜Ｓ１０８’，Ｓ１２０’〜Ｓ１２３’）、上述の動作と同様に、ユーザの口座（銀行）から決済センタの口座（銀行）に送金が行われる。

（動作：受領処理）
図１８は、メッセージの受信処理の例を示すフローチャートであり、図１９は、当該処理において携帯電話端末装置１０の表示部１６に表示される画像の例を示している。現金情報が添付されたメッセージを受信すると、ＤＣＳ３１は、その旨を上述の図８中のＭｏｎｅｙ ＮｏｔｉｆｙコマンドによりＳＭＳで携帯電話端末装置１０の電子メールクライアント１２０に通知する。このような通知があると、電子メールクライアント１２０は、この図１８に示す処理を開始する。

これに応じて、電子メールクライアント１２０は、ＭＢ３２に当該メッセージの受信を要求する。このような要求を受信すると、ＭＢ３２は、例えば図２０及び図２１に示すように、要求されているメッセージの現金情報以外の部分に、現金情報が添付されていることを示す情報と金額を示す情報から生成したファイルを添付し、電子メールクライアント１２０宛に送信する。

このようなメッセージを受信すると、電子メールクライアント１２０は、例えば図１９（Ａ）に示す画像を表示部１６に表示させ、ユーザにメッセージを受信したことを通知する。これに応じて、ユーザがメッセージの表示を指示すると、例えば図１９（Ｂ）に示すように、メッセージの本文と、現金情報が添付されている旨を示す画像６１と、金額を示す画像６２と、受領の指示入力の画像６３を表示部１６に表示させる（Ｓ２１）。この後、ユーザから受領が指示されると（Ｓ２２）、電子メールクライアント１２０は、例えば図１９（Ｃ）に示すように、受領に用いる電子通貨等の選択を求める画像を表示させる。これに応じて、ユーザが電子通貨等を選択すると、電子メールクライアント１２０は、例えば図１９（Ｄ）に示すような画像を表示させ、ユーザにＰＩＮコードの入力を要求する（Ｓ２７）。ユーザがＰＩＮコードを入力すると、電子メールクライアント１２０は、ＳＩＭ１４に記録されているＰＩＮコードと比較し、正しいか否かを判断する（Ｓ２８）。誤っている場合には、ユーザにＰＩＮコードの再入力を求める（Ｓ２７）。入力されたＰＩＮコードが正しい場合には、電子メールクライアント１２０は、例えば図１９（Ｅ）に示す画像を表示させ、受領を要求するメッセージをＤＣＳ３１宛に送信する（Ｓ２９）。電子通貨等の受領が正常に終了し、ＤＣＳ３１からの応答があると（Ｓ３０）、電子メールクライアント１２０は、対応するＡＰＩ１４１，１４２，１４３を介して、記憶領域１３１，１３２の電子通貨を増加させる（あるいは銀行口座の残高情報を増加させる。）。この後、例えば図１９（Ｆ）に示す画像を表示させ、ユーザに、受領が終了した旨を通知する。また、電子メールクライアント１２０は、当該メッセージの状態を例えば「受領済」とする。これにより、ユーザが当該メッセージの表示を指示しても、電子メールクライアント１２０は、例えば図１９（Ｇ）に示すように、上述のボタンの画像６３は表示させない。

図２２は、例えば電子通貨Ｓによる受領処理を行う際の情報通信システム全体の動作を示している。上述のＳＭＳによる現金情報が添付されたメッセージの受信通知（Ｓ２０１）があると、携帯電話端末装置１０の電子メールクライアント１２０は、上述の図８中のＤｅｌｉｖｅｒ ＲｅｑｕｅｓｔコマンドによりＤＣＳ３１にメッセージの送信を要求する（Ｓ２０２）。ＤＣＳ３１は、これに応じて、Ｄｅｌｉｖｅｒ ＲｅｑｕｅｓｔコマンドによりＭＢ３２にメッセージの現金情報以外の部分の受信を要求する（Ｓ２０３）。これに応じてＭＢ３２からＤｅｌｉｖｅｒ Ｍｅｓｓａｇｅコマンドによりメッセージが読み出されると（Ｓ２０４）、ＤＣＳ３１は、このメッセージを携帯電話端末装置１０の電子メールクライアント１２０に供給する（Ｓ２０５）。この後、電子メールクライアント１２０から応答（ＲＳＰ）があると（Ｓ２０６）、ＤＣＳ３１は、管理ＤＢ３１ａ内の当該メッセージの処理状況を変更する（Ｓ２０７）。具体的には、例えば図７中のＭａｉｌ Ｓｔａｔｕｓを“Ｍａｉｌ受信＝済”にする。

一方、携帯電話端末装置１０の電子メールクライアント１２０は、受信したメッセージを表示させ（Ｓ２１１）、ユーザに受領に用いる電子通貨等の選択を求める（Ｓ２１２）。この後、例えば電子通貨Ｓとしての受領が指示されると（Ｓ２１３）、電子メールクライアント１２０は、上述の図８中のＭｏｎｅｙ ＲｅｑｕｅｓｔコマンドをＤＣＳ３１に送信し（Ｓ２１４）、電子通貨Ｓとしての受領を要求する。ＤＣＳ３１は、この要求に応じて、ＡＳ３３に上述の図１０中のＣｈａｒｇｅ Ｒｅｑｕｅｓｔコマンドを送信し、ユーザの口座（電子通貨Ｓ）に対する入金を要求する（Ｓ２１５）。

この要求に応じて、ＡＳ３３の決済処理部３３５は、電子通貨Ｓ口座管理部３３１に指示して決済サーバ５１に、ユーザの口座（電子通貨Ｓ）に対する入金を要求させる。電子通貨Ｓ口座管理部３３１は、Ｃａｓｈ Ｄａｔａ Ｓｙｎｃｈｒｏｎｉｚｅコマンドにより決済サーバ５１との間で電子通貨のデータを同期させ（Ｓ２１６）、Ｃｈａｒｇｅ Ｒｅｑｕｅｓｔコマンドによりユーザの口座に対する入金を決済サーバ５１に要求する（Ｓ２１７）。これに対する応答（ＲＳＰ）は、決済サーバ５１からＡＳ３３，ＤＣＳ３１を介して携帯電話端末装置１０の電子メールクライアント１２０に通知される（Ｓ２１８，Ｓ２１９，Ｓ２２０）。

電子メールクライアント１２０は、この応答（Ｓ２２０）があると、ＡＰＩ１４１を介して、記憶領域１３１に格納されている電子通貨Ｓの残高を増加させる（Ｓ２２１）。

一方、決済サーバ５１は、ＡＳ３３からのＣｈａｒｇｅ Ｒｅｑｕｅｓｔコマンド（Ｓ２１７）を受信すると、ユーザの口座（電子通貨Ｓ）に対する入金処理を実行し（Ｓ２３０）、Ｄｅｐｏｓｉｔ ＲｅｑｕｅｓｔコマンドによりＡＳ３３に決済センタの口座（電子通貨Ｓ）からの出金を要求する（Ｓ２３１）。ＡＳ３３の決済処理部３３５は、この要求に応じて、電子通貨Ｓ口座管理部３３１により決済センタの口座（電子通貨Ｓ）からの出金処理を行って電子通貨Ｓの残高を減少させる（Ｓ２３２）。

出金処理が終了すると、ＡＳ３３は、決済サーバ５１に入金処理が終了した旨を示す応答（ＲＳＰ）を送信する（Ｓ２３３）。さらに、ＡＳ３３は、Ｃｈａｒｇｅ Ｉｎｆｏｒｍａｔｉｏｎコマンドにより、決済センタの口座に対する入出金があったことをＤＣＳ３１に通知する（Ｓ２３４）。ＤＣＳ３１は、これに応じて、管理ＤＢ３１ａ中の当該メッセージの処理状況を変更する（Ｓ２３５）。具体的には、例えば図７中のＭａｉｌ Ｓｔａｔｕｓを“出金処理＝済”にする。変更が終了すると、ＤＣＳ３１は、その旨をＡＳ３３に通知する（Ｓ２３６）。

この後、ＤＣＳ３１は、上述の図９中のＤｅｌｅｔｅ Ｒｅｑｕｅｓｔコマンドにより、当該メッセージの削除をＭＢ３２に要求する（Ｓ２３７）。ＭＢ３２は、この要求に応じて当該メッセージを削除し（Ｓ２３８）、削除が終了すると、その旨をＤＣＳ３１に通知する（Ｓ２３９）。

以上の処理により、決済センタの口座（電子通貨Ｓ）から携帯電話端末装置１０のユーザの口座（電子通貨Ｓ）に送金が行われた状態となる。なお、電子通貨Ｅによる受領処理では、電子通貨Ｅにおける入出金処理に従って、上述の動作と同様に、決済センタの口座（電子通貨Ｅ）からユーザの口座（電子通貨Ｅ）に送金が行われる。また、銀行の口座による受領処理では、例えば図２３に示すように、ＡＳ３３と銀行の決済サーバ５３の間で所定の手順で振込等の送金処理が行われ（Ｓ２１６’〜Ｓ２１８’，Ｓ２３０’〜Ｓ２３３’）、上述の動作と同様に、決済センタの口座（銀行）からユーザの口座（銀行）に送金が行われる。

（効果）
この情報通信システムでは、送信側のユーザからの電子通貨等を、当該電子通貨等に対応する決済センタの口座に一旦プールし、受信側のユーザが選択した電子通貨等に対応する決済センタの口座から受信側のユーザの口座に入金している。この情報通信システムでは、受信側のユーザは、送信側のユーザが用いた電子通貨等とは独立に、受領に用いる電子通貨等を選択することができる。これにより、この情報通信システムでは、電子メールのメッセージを用いて、異なる電子通貨等の間で決済を行うことができ、利便性の向上に寄与することができる。また、送信側と受信側で独立に電子通貨等を選択することができるため、送金が成功する確率の向上に寄与することができる。

また、この情報通信システムでは、上述のように、電子メールのメッセージの作成において添付する電子通貨等の選択，金額の選択等を行ない、選択に応じた現金情報をメッセージに添付して送信している。このため、ユーザに、電子メールのメッセージに擬似的に現金を添付して送信するような操作感を提供することができ、操作性の向上に寄与することができる。

また、この情報通信システムでは、携帯電話端末装置１０に複数の電子通貨等による決済を行い得る決済処理部１４０を設け、メッセージに添付する電子通貨等を、メッセージの作成時に選択することができる。これにより、ユーザがアプリケーションの切り換え等を行わずに、使用する電子通貨等を選択することができ、利便性の向上に寄与することができる。

また、この情報通信システムでは、上述のように、送信側の携帯電話端末装置１０において、現金情報を添付したメッセージの送信が指示された際に、ＰＩＮコード等の認証情報の入力を求めている。これにより、セキュリティの向上に寄与することができる。また、受信側の携帯電話端末装置１０において、受領が指示された際に、ＰＩＮコード等の認証情報の入力を求めている。これにより、セキュリティの向上に寄与することができる。

また、この情報通信システムでは、上述のように、ＤＣＳ３１が、現金情報を添付したメッセージの処理状況について、メッセージの配信状態と共に、現金情報の入出金状態を、管理ＤＢ３１ａに保持している管理情報中の「Ｍａｉｌ Ｓｔａｔｕｓ」中の各パラメータの値により管理している。これにより、現金情報の授受を適切に管理し、電子通貨等の不正等を防止することができる。

ところで、上述の図２２，２３中に示す受領処理においては、センタ口座から出金が終了した旨の通知（Ｓ２３４，Ｓ２３４’）を確認し、管理ＤＢ３１ａに登録（Ｓ２３５）した後に、ＭＢ３２から現金情報が添付されたメッセージを削除するようにしている（Ｓ２３８）。処理の迅速化等の観点からは、ＤＣＳ３１が受領処理を開始した後（Ｓ２１５）に当該メッセージを削除するようにすることもできる。しかし、この場合は、入金処理（Ｓ２３０，Ｓ２３０’）がエラー等になってしまうと、メッセージを復元することが困難である。このため、センタ口座からの出金が完了した後に、メッセージを削除することにより、処理の確実性の向上に寄与することができる。

また、この情報通信システムでは、上述のように、現金情報を添付したメッセージの送受信状態を送金側のユーザの携帯電話端末装置１０及び受領側の携帯電話端末装置１０各々に通知するようにしている。これにより、ユーザはメッセージの処理状態を知ることができ、操作性の向上に寄与することができる。

（電子通貨同期処理詳細）
上述の図１６中のＳ１０６における電子通貨の同期処理は、具体的には、例えば図２４に示すように実行される。ＡＳ３３は、ＤＣＳ３１からＤｅｐｏｓｉｔ Ｒｅｑｕｅｓｔコマンドが供給されると（Ｓ１０５）、送金側のユーザの電子通貨Ｅの口座番号等の識別情報と残高を示す情報等をＣａｓｈ Ｄａｔａ Ｓｙｎｃｈｒｏｎｉｚｅコマンドのパラメータとして決済サーバ５２に送信して電子通貨の同期処理を開始する（Ｓ３００）。

決済サーバ５２は、ＡＳ３３から供給された識別情報が電子通貨Ｅの正規の登録ユーザのものであるか否かを確認し（Ｓ３０１）、正規の登録ユーザでない場合には、ＡＳ３３にエラーである旨の応答［ＲＳＰ（Ｅｒｒｏｒ）］を送信する（Ｓ３０２）。この応答は、ＡＳ３３からＤＣＳ３１を介して携帯電話端末装置１０に供給される（Ｓ３０３，Ｓ３０４）。

このような応答を受信すると、携帯電話端末装置１０の電子メールクライアント１２０は、正規の登録ユーザではない旨のエラーメッセージを表示させ（Ｓ３０５）、以降の送金処理を実行しない。

正規の登録である場合には、決済サーバ５２は、電子通貨Ｅの残高が正しいか否かを確認し（Ｓ３１１）、正しくない場合には、ＡＳ３３にエラーである旨の応答［ＲＳＰ（Ｅｒｒｏｒ）］を送信する（Ｓ３１２）。この応答は、ＡＳ３３からＤＣＳ３１を介して携帯電話端末装置１０に供給される（Ｓ３１３，Ｓ３１４）。

このような応答を受信すると、携帯電話端末装置１０の電子メールクライアント１２０は、電子通貨Ｅの残高が正しくない旨のエラーメッセージを表示させ（Ｓ３１５）、以降の送金処理を実行しない。

電子通貨Ｅの残高が正しい場合には、決済サーバ５２は、電子通貨の同期処理を終了し（Ｓ３２０）、以降の処理を実行する。

このように、電子通貨の同期処理においてエラーが発生した場合に、送金側の携帯電話端末装置１０にエラー通知を行い、エラー内容の表示を行うことにより、送金側のユーザは、送金処理が失敗したことを知ることができる。これにより、利便性の向上に寄与することができる。さらに、エラー内容に応じた通知を行い、エラー内容に応じた表示を行うことにより、送金側のユーザは、送金処理が失敗した理由を知ることができる。これにより、エラー内容に応じた対処が容易になる。

（加入者確認処理詳細）
上述の図１６中のＳ１０４における加入者の確認処理は、具体的には、例えば図２５に示すように実行される。携帯電話端末装置１０から電子通貨の送金が指示されると（Ｓ１０３）、ＤＣＳ３１は、ＤＳ２５に、メッセージの送信先のユーザについての情報を要求する（Ｓ４００）。ＤＳ２５から加入者情報が供給されると（Ｓ４０１）、ＤＣＳ３１は、送信先のユーザが当該情報通信システムの加入者か否かを確認する（Ｓ４０２）。

当該情報通信システムの加入者でない場合には、ＤＣＳ３１は、利用できない旨の応答［ＲＳＰ（Ｅｒｒｏｒ）］を携帯電話端末装置１０宛に送信する（Ｓ４０３）。このような応答を受信すると、携帯電話端末装置１０の電子メールクライアント１２０は、
送信先のユーザが当該情報通信システムの加入者でない旨のエラーメッセージを表示させ（Ｓ４０４）、以降の送金処理を実行しない。

送信先が当該情報通信システムの加入者である場合には、ＤＣＳ３１は、送信先のユーザが現金情報を添付したメッセージの配信サービスを利用できるか否かを確認する（Ｓ４０５）。送信先のユーザが当該サービスを利用できない場合には、ＤＣＳ３１は、送信先のユーザが当該サービスを利用できない旨の応答［ＲＳＰ（Ｅｒｒｏｒ）］を携帯電話端末装置１０宛に送信する（Ｓ４０６）。このような応答を受信すると、携帯電話端末装置１０の電子メールクライアント１２０は、送信先のユーザが当該サービスを利用できない旨のエラーメッセージを表示させ（Ｓ４０７）、以降の送金処理を実行しない。

送信先が当該情報通信システムの加入者であり、現金情報を添付したメッセージの配信サービスを利用可能である場合には、ＤＣＳ３１は、以降の処理を実行する。

この情報通信システムでは、ＤＣＳ３１が、メッセージの送信先のユーザが当該情報通信システムの加入者であり、現金情報を添付したメッセージの配信サービスを利用可能である場合に送金処理を実行し、それ以外の場合には、携帯電話端末装置１０にエラー通知を行う。すなわち、送金側のユーザが、現金情報を添付したメッセージの配信サービスを利用可能か否か相手先のユーザに確認しなくても、利用可能な場合にのみ送金処理が行われる。これにより、利便性の向上に寄与することができる。

（有効期間管理）
また、この情報通信システムでは、送金側のユーザが送金処理を行った後、所定の期間（有効期間）内に送金先のユーザが受領処理を行わない場合に、送金側のユーザに対する返金処理を実行するようになっている。ＤＣＳ３１は、管理ＤＢ３１ａに基づいて、現金情報が添付されているメッセージ有効期間が経過した場合に、図２６に示す処理を実行する。

有効期間が経過した場合に、ＤＣＳ３１は、まず、上述の図８中のＭｏｎｅｙ Ｎｏｔｉｆｙコマンドにより、有効期間が経過した旨を携帯電話端末装置１０に通知する（Ｓ５０１）。この通知は、ＳＭＳにより携帯電話端末装置１０の電子メールクライアント１２０に供給される。このような通知があると、電子メールクライアント１２０は、上述の図８中のＤｅｌｉｖｅｒ ＲｅｑｕｅｓｔコマンドによりＤＣＳ３１にメッセージの送信を要求する（Ｓ５０２）。ＤＣＳ３１は、これに応じて、Ｄｅｌｉｖｅｒ ＲｅｑｕｅｓｔコマンドによりＭＢ３２に当該メッセージの受信を要求する（Ｓ５０３）。これに応じてＭＢ３２からＤｅｌｉｖｅｒ Ｍｅｓｓａｇｅコマンドによりメッセージが読み出されると（Ｓ５０４）、ＤＣＳ３１は、このメッセージを携帯電話端末装置１０の電子メールクライアント１２０に供給する（Ｓ５０５）。この後、電子メールクライアント１２０から応答（ＲＳＰ）があると（Ｓ５０６）、ＤＣＳ３１は、管理ＤＢ３１ａ内の当該メッセージの処理状況を変更する（Ｓ５０７）。

電子メールクライアント１２０は、メッセージを受信すると、例えば図２７（Ａ）に示すように、先の送金先のユーザが有効期間内に受領しなかった旨を示すエラーメッセージを表示させる（Ｓ５１１）。

これに応じて、ユーザが返金処理を指示すると（Ｓ５１２）、電子メールクライアント１２０は、上述の図８中のＭｏｎｅｙ ＲｅｑｕｅｓｔコマンドをＤＣＳ３１に送信し（Ｓ５１３）、送金側のユーザが添付した電子通貨（この場合は電子通貨Ｅ）の受領を要求する。ＤＣＳ３１は、この要求に応じて、ＡＳ３３に上述の図１０中のＣｈａｒｇｅ Ｒｅｑｕｅｓｔコマンドを送信し、ユーザの口座（電子通貨Ｅ）に対する入金を要求する（Ｓ５１４）。

この要求に応じて、ＡＳ３３の決済処理部３３５は、電子通貨Ｅ口座管理部３３２に指示して決済サーバ５２に、ユーザの口座（電子通貨Ｅ）に対する入金を要求させる。電子通貨Ｓ口座管理部３３１は、Ｃａｓｈ Ｄａｔａ Ｓｙｎｃｈｒｏｎｉｚｅコマンドにより決済サーバ５２との間で電子通貨のデータを同期させ（Ｓ５１５）、Ｃｈａｒｇｅ Ｒｅｑｕｅｓｔコマンドによりユーザの口座に対する入金を決済サーバ５２に要求する（Ｓ５１６）。これに対する応答（ＲＳＰ）は、決済サーバ５２からＡＳ３３，ＤＣＳ３１を介して携帯電話端末装置１０の電子メールクライアント１２０に通知される（Ｓ５１７，Ｓ５１８，Ｓ５１９）。

電子メールクライアント１２０は、この応答（Ｓ５１９）があると、ＡＰＩ１４１を介して、記憶領域１３２に格納されている電子通貨Ｅの残高を増加させた後（Ｓ５１０）、例えば図２７（Ｂ）に示すように、返金後の電子通貨Ｅの残高を表示させる。これにより、ユーザは現在の電子通貨Ｅの残高を知ることができる。

一方、決済サーバ５２は、ＡＳ３３からのＣｈａｒｇｅ Ｒｅｑｕｅｓｔコマンド（Ｓ５１６）を受信すると、ユーザの口座（電子通貨Ｅ）に対する入金処理を実行し（Ｓ５３０）、Ｄｅｐｏｓｉｔ ＲｅｑｕｅｓｔコマンドによりＡＳ３３に決済センタの口座（電子通貨Ｅ）からの出金を要求する（Ｓ５３１）。ＡＳ３３の決済処理部３３５は、この要求に応じて、電子通貨Ｅ口座管理部３３２により決済センタの口座（電子通貨Ｅ）からの出金処理を行って電子通貨Ｅの残高を減少させる（Ｓ５３２）。

出金処理が終了すると、ＡＳ３３は、決済サーバ５２に入金処理が終了した旨を示す応答（ＲＳＰ）を送信する（Ｓ５３３）。さらに、ＡＳ３３は、Ｃｈａｒｇｅ Ｉｎｆｏｒｍａｔｉｏｎコマンドにより、決済センタの口座に対する入出金があったことをＤＣＳ３１に通知する（Ｓ５３４）。ＤＣＳ３１は、これに応じて、管理ＤＢ３１ａ中の当該メッセージの処理状況を変更する（Ｓ５３５）。変更が終了すると、ＤＣＳ３１は、その旨をＡＳ３３に通知する（Ｓ５３６）。

この後、ＤＣＳ３１は、上述の図９中のＤｅｌｅｔｅ Ｒｅｑｕｅｓｔコマンドにより、当該メッセージの削除をＭＢ３２に要求する（Ｓ５３７）。ＭＢ３２は、この要求に応じて当該メッセージを削除し（Ｓ５３８）、削除が終了すると、その旨をＤＣＳ３１に通知する（Ｓ５３９）。

以上の処理により、決済センタの口座（電子通貨Ｅ）から携帯電話端末装置１０のユーザの口座（電子通貨Ｅ）に返金が行われた状態となる。

この後、送金先のユーザが受領処理を指示し（Ｓ５５３）、上述の図８中のＭｏｎｅｙ ＲｅｑｕｅｓｔコマンドをＤＣＳ３１に送信しても（Ｓ５５４）、ＤＣＳ３１は、管理ＤＢ３１ａを確認してエラーであると判定する（Ｓ５５５）。エラーと判定した場合には、ＤＣＳ３１は、有効期間が経過したことを示す応答［ＲＳＰ（Ｅｒｒｏｒ）］を携帯電話端末装置１０に送信する。このような応答を受信すると、携帯電話端末装置１０の電子メールクライアント１２０は、例えば図２７（Ｃ）に示すように、有効期間（保存期間）が過ぎた旨の表示を行う（Ｓ５５７）。これにより、送金先のユーザは有効期間が過ぎたことを知ることができる。

この情報通信システムでは、上述のように、現金情報を添付したメッセージの保存期間（有効期間）を設定している。また、有効期限が経過した場合に、送金元のユーザに対する返金処理を行うようにしている。また、上述のように、送金元のユーザが添付した電子通貨等と同一の電子通貨等で返金処理を行うため、返金を受けるユーザは改めて受け取りに用いる電子通貨等を指定する必要がなく、利便性の向上に寄与することができる。

また、この情報通信システムでは、有効期間が経過した後に、送金先のユーザが受領を指示した場合に、ＤＣＳ３１がエラーである旨を示す応答を携帯電話端末装置１０に送信するため、送金先のユーザが有効期間を経過したことを知ることができる。これにより、送金元、送金先の双方のユーザが、送金処理が行われなかったことを知ることができる。

（エラー処理詳細）
また、この情報通信システムでは、送金先のユーザが受領処理を実行した際に、電子通貨の状態不正である等のエラーが発生した場合にも、送金側のユーザに対する返金処理を実行するようになっている。例えば図２８中のＳ６０１において、送金先のユーザが電子通貨Ｓとしての受領を要求すると、電子メールクライアント１２０は、上述の図８中のＭｏｎｅｙ ＲｅｑｕｅｓｔコマンドをＤＣＳ３１に送信する（Ｓ６０２）。ＤＣＳ３１は、この要求に応じて、ＡＳ３３に上述の図１０中のＣｈａｒｇｅ Ｒｅｑｕｅｓｔコマンドを送信し、ユーザの口座（電子通貨Ｓ）に対する入金を要求する（Ｓ６０３）。

この要求に応じて、ＡＳ３３の決済処理部３３５は、電子通貨Ｓ口座管理部３３１に指示して決済サーバ５１に、ユーザの口座（電子通貨Ｓ）に対する入金を要求させる。電子通貨Ｓ口座管理部３３１は、Ｃａｓｈ Ｄａｔａ Ｓｙｎｃｈｒｏｎｉｚｅコマンドにより決済サーバ５１との間で電子通貨のデータを同期させる（Ｓ６０４）。

ここで、例えば電子通貨Ｓの残高が不正である等のエラーが発生すると（Ｓ６０５）、決済サーバ５１はその旨を示す応答［ＲＳＰ（Ｅｒｒｏｒ）］をＡＳ３３に送信する（Ｓ６０６）。この応答は、ＤＣＳ３１を介して携帯電話端末装置１０に供給される（Ｓ６０７．Ｓ６０８）。ＤＣＳ３１は、この応答に応じて、管理ＤＢ３１ａ中の当該メッセージの状態（Ｍａｉｌ Ｓｔａｔｕｓ）を変更する（Ｓ６０９）。

このような応答を受信すると、携帯電話端末装置１０の電子メールクライアント１２０は、例えば図２９（Ａ）に示すように、電子通貨が不正である旨の表示を行う（Ｓ６１０）。これにより、送金先のユーザは、受領処理が失敗したことを知ることができる。

さらに、ＤＣＳ３１は、送金元のユーザの携帯電話端末装置１０に送金処理が失敗したことを通知する（Ｓ６２１〜Ｓ６２６）。これに応じて、送金元のユーザの携帯電話端末装置１０の電子メールクライアント１２０は、例えば図２９（Ｂ）に示すように、送信先のユーザが受領できなかったことを示すエラーメッセージを表示させる（Ｓ６３１）。これに応じて、送信元のユーザが返金処理を指示すると（Ｓ６３２）、上述の図２６中のＳ５１３〜Ｓ５３９と同様の処理により、送金元のユーザに対する返金処理が実行される（Ｓ６３３〜Ｓ６５９）。

返金処理が終了すると、携帯電話端末装置１０の電子メールクライアント１２０にはその旨が通知され（Ｓ６３９）、電子メールクライアント１２０は、ＡＰＩ１４２を介して記憶領域１３２に格納されている電子通貨Ｅの残高を増加させた後（Ｓ６４０）、例えば図２９（Ｃ）に示すように、返金後の残高を表示させる。これにより、送金元のユーザは返金後の電子通貨Ｅの残高を知ることができる。

この情報通信システムでは、上述のように、送金先のユーザが受領に失敗した際に、送金元のユーザの携帯電話端末装置１０に、その旨を通知し、送金元のユーザに対する返金処理を実行するようにしている。これにより、現金情報の取り扱いの確実性の向上に寄与することができる。

また、この情報通信システムでは、上述の図２８中に示す返金処理と同様に、送金元のユーザが添付した電子通貨等と同一の電子通貨等で返金処理を行うため、返金を受けるユーザは改めて受け取りに用いる電子通貨等を指定する必要がなく、利便性の向上に寄与することができる。

本発明の実施例１に係る情報通信システムの構成例を示すブロック図である。 前記情報通信システムを構成する携帯電話端末装置の要部の構成例を示すブロック図である。 前記情報通信システムを構成するＣＣＳの構成例を示すブロック図である。 前記ＣＣＳを構成するＭＢに格納される電子メールのメッセージの構成の例を示す図である。 前記メッセージの具体例を示す図である。 前記メッセージの要部の具体例を示す図である。 前記ＣＣＳを構成するＤＣＳの管理ＤＢに格納される情報の例を示す図である。 前記情報通信システムにおけるコマンドの例を示す図である。 前記情報通信システムにおけるコマンドの例を示す図である。 前記情報通信システムにおけるコマンドの例を示す図である。 前記情報通信システムにおけるコマンドの例を示す図である。 前記情報通信システムにおけるコマンドの例を示す図である。 前記情報通信システムにおけるコマンドの例を示す図である。 前記情報通信システムを構成する携帯電話端末装置における送金処理の例を示すフローチャートである。 前記送金処理において携帯電話端末装置の表示部に表示される画像の例を示す図である。 前記送金処理において電子通貨を選択した場合の前記情報通信システム全体の動作の例を示すシーケンス図である。 前記送金処理において銀行を選択した場合の前記情報通信システム全体の動作の例を示すシーケンス図である。 前記情報通信システムを構成する携帯電話端末装置における受領処理の例を示すフローチャートである。 前記受領処理において携帯電話端末装置の表示部に表示される画像の例を示す図である。 現金情報が添付されたメッセージに応じて送金先の携帯電話端末装置に供給されるメッセージの具体例を示す図である。 前記メッセージの要部の具体例を示す図である。 前記受領処理において電子通貨を選択した場合の前記情報通信システム全体の動作の例を示すシーケンス図である。 前記受領処理において銀行を選択した場合の前記情報通信システム全体の動作の例を示すシーケンス図である。 前記送金処理における電子通貨の同期処理の詳細の例を示すシーケンス図である。 前記送金処理における加入者確認処理の詳細の例を示すシーケンス図である。 前記送金処理において所定の保存期間が経過した場合の、返金処理の詳細の例を示すシーケンス図である。 前記返金処理において携帯電話端末装置の表示部に表示される画像の例を示す図である。 前記受領処理においてエラーが発生した場合の、返金処理の詳細の例を示すシーケンス図である。 前記返金処理において携帯電話端末装置の表示部に表示される画像の例を示す図である。

符号の説明

１０ 携帯電話端末装置，３０ ＣＣＳ、３１ ＤＣＳ、３２ ＭＢ、３３ ＡＳ、５１，５２，４３ 決済サーバ、１２０ 電子メールクライアント、１４０ 決済処理部、１４１，１４２，１４３ ＡＰＩ

Claims (7)

1. 少なくとも２つの異なる電子通貨システムに対して決済を要求する情報を生成し得る決済要求手段と，前記電子通貨システムに対して決済を要求する情報（決済情報）を電子メールのメッセージに添付して送信する添付制御手段と，ユーザからの指示に応じて前記メッセージに添付する決済情報の種類の選択を行う選択手段とを有する情報端末装置と、
   前記各電子通貨システム毎に設けられた決済センタの口座を管理する口座管理手段と，該情報端末装置からのメッセージに添付されている前記決済情報の種類に対応する前記決済センタの口座に対して当該決済情報によって指定された金額の決済を行う収納処理手段とを有する決済仲介装置と
   を備えることを特徴とする情報通信システム。
2. 前記決済仲介装置は、
   前記メッセージの宛先に対応するユーザの情報端末装置からの要求に応じて、当該要求中で指定された種類の電子通貨システムの口座に、当該電子通貨システムに対する前記決済センタの口座から前記決済情報中で指定された金額の決済を行う領収処理手段を備えることを特徴とする請求項１記載の情報通信システム。
3. 前記決済仲介装置は、
   前記収納処理手段による決済の後に、前記メッセージの宛先に対応するユーザの情報端末装置に、前記決済情報が添付されたメールを受信した旨を通知する通知手段を備えることを特徴とする請求項１記載の情報通信システム。
4. 少なくとも２つの異なる電子通貨システムに対する決済センタの口座を管理する口座管理手段と、
   情報端末装置からのメッセージに添付された，前記電子通貨システムに対して決済を要求する情報（決済情報）の種類に対応する前記決済センタの口座に対して当該決済情報によって指定された金額の決済を行う収納処理手段と、
   前記メッセージの宛先に対応するユーザの情報端末装置からの要求に応じて、当該要求中で指定された種類の電子通貨システムの口座に、当該電子通貨システムに対する前記決済センタの口座から前記決済情報中で指定された金額の決済を行う領収処理手段と
   を備えることを特徴とする決済仲介装置。
5. 前記収納処理手段による決済の後に、前記メッセージの宛先に対応するユーザの情報端末装置に、前記決済情報が添付されたメールを受信した旨を通知する通知手段を備えることを特徴とする請求項４記載の決済仲介装置。
6. 少なくとも２つの異なる電子通貨システムに対して決済を要求する情報を生成し得る決済要求手段と、
   前記電子通貨システムに対して決済を要求する情報（決済情報）を電子メールのメッセージに添付して送信する添付制御手段と、
   ユーザからの指示に応じて、前記メッセージに添付する決済情報の種類の選択を行う選択手段と
   を備えることを特徴とする情報端末装置。
7. 少なくとも２つの電子通貨システムに対して決済を行い得る決済仲介装置から決済情報が添付されたメッセージを受信した旨の通知を受信する通知受信手段と、
   該通知に応じて，受領に用いる前記電子通貨システムの選択を入力する選択入力手段と、
   該選択された電子通貨システムの種類及び口座を示す情報を前記決済仲介装置に送信する領収要求手段と、
   該要求に応じた前記決済仲介装置からの指示に応じて前記電子通貨システムによる決済を行う決済手段と
   を備えることを特徴とする情報端末装置。

Images