JPWO2004013789A1 - 電子マネー取引システムにおける電子財布の金額データ更新方法 - Google Patents

Abstract

電子マネー取引システムにおける電子財布に記録された金額データの更新方法に関し、利用者の電子財布と金融機関または電子マネー会社とがオンラインで接続されていなくても、電子財布の金額データを更新することが可能になる。利用者が設定した保留日、保留方法、設定保留額を基に、金融機関は、利用者の預金口座から所定の金額を保留する。保留結果を基に作成された保留実施リストによって、取引決済端末において、電子財布の金額データが更新されることを特徴とする。保留は、預金口座残高が保留に必要な額を上回れば実施される。また、貸付機能を設定することにより、預金口座残高不足で保留が実施されない場合に、金融機関または電子マネー会社とオンラインで承認を得ることなく、電子財布の金額データを増額することも可能である。

Description

本発明は、電子マネー取引システムに関し、特に電子財布の金額データの更新方法に関する。

クレジットカードや現金以外の決済手段として、貨幣価値を金額データとして記録した電子マネーを用い、取引において当該金額データを加減額する電子マネー取引は、インターネットを利用した電子商取引や現実の店舗において導入されており、既存の決済手段に代わるものとして注目されている。
従来の電子マネー取引において、利用者の電子マネーは、利用者が取引に使用可能な金額データとして、電子財布に記録される。利用者が電子マネーを使用するには、まず金融機関または電子マネー会社と利用者の電子財布とがオンライン接続された状態で、電子財布に記録された金額データを増額する、入金手続きを行う必要があった。
従来の入金手続きとしては、利用者が、電子財布を電子マネーの入金機能を備えた端末（以降、電子マネー入金端末と呼ぶ）に装着し、入金手続きを行う第１の手続きと、パーソナルコンピュータ（以降、ＰＣと呼ぶ）などでウォレットと呼ばれる特殊なソフトウェアを使用し、クレジットカードやキャッシュカードを使用して手続きを行う第２の手続きがあった。
しかしながら、第１の手続きの場合、利用者は、実際に電子財布を携帯し、電子マネー入金端末へ出向かなければならない。また、電子マネー入金端末は、都市の一部にしか存在せず、数が少ないという課題がある。第２の手続きの場合、電子マネー入金端末に出向く必要はないが、利用者は電子マネー会社ごとにウォレットと呼ばれるソフトウェアを複数用意し、設定しなければならない。また、利用者がＰＣを使える環境にいないことも考えられ、そうした状況下では入金手続きを行うことができない。
特開２００１−２８３２９６号には、ＩＣカードに記録された金額データの範囲内で、一般商店に設置された現金引出端末から、銀行またはクレジットカード会社といった金融機関に接続することなく、オフラインで現金を引き出す方法が提案されている。
しかしながら、ＩＣカードに金額データを記録するには、利用者が電子マネー入金端末で入金手続きを行う必要があり、入金手続きの煩雑さを軽減する提案はなされていない。
以上のように、従来の電子マネー取引システムにおいては、電子マネーの入金手続きをするために、入金時に金融機関または電子マネー会社と利用者の電子財布とがオンライン接続された状態でないと入金手続きを行うことができず、利用者にとって入金手続きは行いやすいものではなく、むしろ煩雑なものであった。

本発明の目的は、入金手続きの際利用者の電子財布と金融機関または電子マネー会社とがオンラインで接続されていない状況で、利用者の電子財布の金額データを更新できる金額データ更新方法および電子マネー取引システムを提供し、入金手続きの煩雑さを軽減することにある。
上記目的を達成するため、本発明では、利用者が取引可能な金額データが記録された電子財布と、前記電子財布に記録された金額データに基づき取引を可能とする取引決済端末と、前記利用者の預金口座を登録して管理する金融機関サーバを有する電子マネー取引システムにおける電子財布の金額データ更新方法であって、前記金融機関サーバにおいて、前記電子財布により取引が行われる際、前記設定された保留額と、取引金額に基づき前記電子財布に利用可能金額を更新記録することを特徴とする電子財布の金額データ更新方法を提供する。
上記発明の実施の形態によれば、利用者が設定した期日に金融機関において利用者の預金口座から所定の金額が保留され、保留が実施された日後最初に取引決済端末にて利用者が取引を行う際に、取引決済端末にて、金融機関または電子マネー会社とオンライン接続することなく、利用者の電子財布に記録された金額データが増額され、電子マネーの入金が実施される。
別の実施の形態によれは、金融機関にて預金口座残高が、保留に必要な額（以降、保留額と呼ぶ）を上回ることで保留が実施され、保留が実施された日後最初に取引決済端末にて利用者が取引を行う際に、取引決済端末にて、金融機関または電子マネー会社とオンライン接続することなく、利用者の電子財布に記録された金額データが増額され、電子マネーの入金が実施される。
別の実施の形態によれば、利用者が貸付機能を電子マネーサービスに追加する契約をし、その設定が電子財布に記録されることにより、利用者が取引決済端末にて取引を行う際に、金融機関または電子マネー会社とオンライン接続することなく、貸付として利用者の電子財布に記録された金額データが増額される。
上記発明によれば、利用者は商品やサービスなどの決済時に、入金手続きも同時に行うことができ、決済と入金が１度で済むので、便利である。
また、預金口座残高が不足し、利用者が設定した期日に保留が実施されない場合でも、その後預金口座残高が、保留に必要な額を上回れば、再び電子マネーの入金が実施される。預金口座への入金は、銀行の店舗、現金自動預け払い機（以降、ＡＴＭと呼ぶ）や、携帯電話などの通信機能を備えた携帯端末、インターネットに接続可能なＰＣなどの端末を利用して行うことができる。このように、多くの手段が用意されていることから、従来のように数少ない電子マネーの入金端末にて入金手続きを行うより、利用者にとっての利便性は高い。
また、電子マネー会社においては、入金手続きに必要な装置が、店舗などに設置される取引決済端末と銀行の預金口座への入金端末（ＡＴＭ、携帯端末、ＰＣなど）に集約され、専用の電子マネー入金端末を設置する必要がなく、大幅なコスト削減が可能である。

図１は、本発明の第１の実施の形態を示す図である。
図２は、本発明の第２の実施の形態を示す図である。
図３は、本発明の第３の実施の形態を示す図である。
図４は、利用者情報の例を示す図である。
図５は、保留処理を示すフローチャートである。
図６は、預金口座情報の例を示す図である。
図７は、保留実施リストの例を示す図である。
図８は、入金処理を示すフローチャートである。
図９は、購入処理を示すフローチャートである。
図１０は、入金電文の例を示す図である。
図１１は、取引報告電文の例を示す図である。
図１２、図１３、図１４は、本発明の第１の実施の形態における第１の入金例を説明する図である。
図１５、図１６、図１７、図１８は、本発明の第１の実施の形態における第２の入金例を説明する図である。
図１９、図２０は、本発明の第１の実施の形態における第３の入金例を説明する図である。

以下、本発明の実施の形態について図面に従って説明する。しかしながら、本発明の技術的範囲はかかる実施の形態によって限定されるものではなく、特許請求の範囲に記載された発明とその均等物に及ぶものである。
（１）第１の実施の形態
図１は、本発明の第１の実施の形態を示す図である。第１の実施の形態では、金融機関サーバ４０にて保留が実施されると、利用者の預金口座に対する保留実施の有無が記載された保留実施リストが取引決済端末２０に送信される。利用者が取引決済端末２０にて、取引を行う際前記保留実施リストが参照され、保留が実施された預金口座に対応する電子財布１０の金額データが増額され、入金が実施されるものである。
図１における電子マネー取引システムは、利用者が使用可能な金額データが記録される電子財布１０と、商品やサービスの決済に使用され、店舗などに設置される取引決済端末２０と、利用者の預金口座の出納管理を行い、金融機関に設置される金融機関サーバ４０とを有する。なお、本明細書においては、電子財布はＩＣカードで、金融機関は銀行で実現されているものとする。
最初に電子財布１０を説明する。利用者の電子マネーは、電子財布１０に使用可能な金額データとして記録され、店舗などに設置された取引決済端末２０にて、利用者が支払いを行うと減額され、入金が実施されると増額される。
電子財布１０内記録媒体１１には利用者情報１２が格納される。図４は、利用者情報１２の例である。図４には、利用者氏名６１、ＩＣカードを識別するためのカード番号６２、ＩＣカード内に記録された電子マネー残高である、カード残高６３、利用者が保留を希望する設定日である保留日６４、利用者が保留を希望する金額である設定保留額６５が記録される。
他に、最後に電子マネーの入金が実施された日付である、最終入金日６６、最後に電子マネーが使用された日付である、最終利用日６７、銀行の預金口座残高が不足し保留が実施されなかった場合に、電子マネーの貸付を行うかを判定するための貸付機能６８が記録される。
第１の実施の形態における入金の流れを構成と合わせて説明する。金融機関サーバ４０は、後述する図５の保留処理にて、保留を実施し、保留実施リスト２４を作成する。金融機関サーバ４０は、取引決済端末２０から、入金電文２５、出金電文２６、貸付電文２７を受信し、保留結果の可否である保留実施リスト２４を送信するための通信装置４１と、預金口座情報４３を格納するための蓄積装置４２とを備えている。
図６は、預金口座情報の例である。簡単化のために利用者Ｔａｒｏの列だけを抜き出してあるが、実際は利用者全員がリストに格納されている。利用者氏名６１、カード番号６２、保留日６４、設定保留額６５に加え、預金口座番号６９、利用者の貸付残高を示す、貸付残高７０、利用者の預金残高を示す、預金口座残高７１、金融機関サーバ４０に記録された電子マネー残高である、保留残高７２、最後に保留が実施された日付である、最終保留日７３が記録される。図９では、預金口座番号Ａ０００１の利用者Ｔａｒｏが、カード番号０００１の電子財布を所有していること等がわかる。
図７は、保留実施リストの例である。簡単化のためにカード番号０００１の列だけを抜き出してあるが、実際は利用者全員がリストに格納されている。カード番号６２と保留結果７４が記録されている。図７では、カード番号０００１で保留が実施されたと判定できる。
図５は、金融機関サーバ４０が行う保留処理を説明する図である。本保留処理では、設定された保留日以降最初に預金口座残高が設定保留額を上回ると保留が実施される。
まず金融機関サーバ４０が、保留処理を実施する当日が保留日であるかを判定する（Ｓ１０１）。金融機関サーバ４０は、保留処理を実施日の日付と、預金口座情報４３の保留日６４が一致したら、今日が保留日であると判定すればよい。ステップＳ１０１で、保留処理を実施する当日が保留日であると判定されたら、預金口座残高７１が設定保留額６５を上回るか判定する（Ｓ１０３）。ステップＳ１０３で預金口座残高７１が設定保留額６５を上回ると判定されたら、設定保留額分を保留し、預金口座情報４３を更新する（Ｓ１０４）。ステップＳ１０４では、預金口座残高７１、保留残高７２、最終保留日７３が更新される。ステップＳ１０４が済むと、保留実施リスト２４を更新する（Ｓ１０５）。ステップＳ１０５では、保留が行われた預金口座番号７４に対応するカード番号６２の保留結果７４をＯＫに、保留が行われない預金口座番号７４に対応するカード番号６２の保留結果７４をＮＧにすればよい。そして、金融機関サーバ４０は、取引決済端末２０に保留実施リスト２４を送信し（Ｓ１０６）、保留処理は終了する。
ステップＳ１０１で、保留処理を実施する当日が保留日でないと判定された場合、金融機関サーバ４０は、最終保留日７３から１ヶ月経過しているか判定する（Ｓ１０２）。保留処理の実施日と預金口座情報４３の最終保留日７３とを比較すればよい。ステップＳ１０２で、１ヶ月経過していれば、保留処理の実施日前の最も近い保留日において保留がされていないことになり、この時点で保留可能であれば、保留を実施するために、ステップＳ１０３へ進む。
ステップＳ１０２で１ヶ月経過していなければ、保留処理の実施日前の最も近い保留日に保留が実施されており、保留の必要はなく、保留実施リスト更新（Ｓ１０５）に進む。また、ステップＳ１０３で、預金口座残高が設定保留額を上回らなかった場合も、保留の必要はなく、保留実施リスト更新（Ｓ１０５）に進む。
ステップＳ１０４では、保留される額を設定保留額と同額としているが、これを設定保留額と保留残高の差額とし、ステップＳ１０３にて預金口座残高が当該差額を上回れば、当該差額を保留するとしても構わない。
図５の保留処理によって、預金口座残高が保留額を上回れば、設定された保留日６４から次回の保留日６４までの間に１回保留が実施され、利用者の預金口座残高７１が不当に減額される、過度の保留を防ぐことができる。
また、保留日６４に預金口座残高７１が足りなくても、その後預金口座残高７１が保留額を上回った時点で保留が実施される。預金口座への入金、振込は、街頭またはコンビニエンスストアに多数設置されるＡＴＭや、通信機能を備えた携帯端末またはＰＣなどから容易に行うことができるので、利用者にとって便利である。
次に、取引決済端末２０を説明する。取引決済端末２０は、受信した保留判定リスト２４を基に、利用者が取引を行う際に、電子財布のカード残高６３を増額するか決定する図８の入金処理と、利用者が行う取引に応じて、電子財布１０に記録されたカード残高６３を更新し、取引状況を金融機関サーバ４０に報告するため、出金や入金の報告電文を送信する図９の購入処理を行う。
取引決済端末２０は、電子財布１０内利用者情報１２を読み出し、更新された前記利用者情報を書き込むための電子財布リーダライタ２１と、電子財布１０に対し、カード残高６３を増額するかを判定するための保留実施リスト２４および金融機関サーバ４０に取引状況を報告するための入金電文２５、出金電文２６、貸付電文２７を格納する蓄積装置２３と、データを送受信するための通信装置２２とを備える。
図８を用いて入金処理を説明する。本入金処理では、保留が実施された日後最初に取引決済端末２０にて決済が行われる際に、利用者の電子財布のカード残高６３を増額し、金融機関サーバ４０へ報告するための電文を作成するものである。
図８では、まず入金処理を実施する当日が当該入金処理の実施日前の最も近い保留日以降最初の利用日か判定する（Ｓ７０１）。ステップＳ７０１は、取引決済端末２０が、入金処理を実施する日の日付と電子財布１０内利用者情報１２の最終利用日６７および保留日６４を比較することで判定が可能である。ステップＳ７０１で最初の利用日であると判定された場合、保留実施リスト２４にて、前記利用者に対応するカード番号にて保留が実施されたかを判定する（Ｓ７０３）。
入金処理の実施日前の最も近い保留日以降最初の利用で、保留が実施されている場合、電子財布１０のカード残高６３を設定保留額分増額する入金を実施し、利用者情報を更新する（Ｓ７０５）。入金実施によって、カード残高６３と最終入金日６６が更新される。ステップＳ７０５が済むと、金融機関サーバ４０に利用者の電子財布のカード残高を増額したことを報告するための入金電文２５を作成し（Ｓ７０６）、入金処理は終了する。
ステップＳ７０１で入金処理を実施する当日が入金処理の実施日前の最も近い保留日以降最初の利用日でなかった場合、最終入金日６６から１ヶ月経過しているか判定する（Ｓ７０２）。ステップＳ７０２で、最終入金日から１ヶ月経過していれば、入金処理の実施日前の最も近い保留日以降最初の利用日において、入金が実施されなかったことになり、入金の必要があるかを判定するステップＳ７０３に進む。ステップＳ７０２で、最終入金日６６から１ヶ月経過していない場合は、入金処理の実施日前の最も近い保留日以降に入金が実施されたことになり、入金の必要はなく、入金処理を終了する。
ステップＳ７０３で、前記利用者に対応するカード番号にて保留が実施されなかった場合、貸付機能６８が設定されているか判定する（Ｓ７０４）。貸付機能６８が設定されている場合は、設定保留額分が貸付として入金されるため、ステップＳ７０６に進む。ステップＳ７０４で貸付機能が設定されていない場合、入金は実施されず、入金処理を終了する。
本入金処理によって、利用者の預金口座にて保留が実施された場合か、貸付が設定されている場合に、電子財布のカード残高が増額され、電子マネー入金端末に出向いて、入金手続きを行う必要がなくなる。
入金処理が済むと、取引決済端末２０にて図９の購入処理が行われる。購入処理は、利用者が利用可能な電子マネーが購入金額を上回る場合に、電子財布の金額データを減額し、金融機関サーバ４０に報告するための電文を作成するものである。
図９では、まずカード残高６３が購入額を上回るかを判定する（Ｓ８０１）。ステップＳ８０１で上回ると判定されれば、電子財布１０のカード残高６３を購入額分減額する出金を実施し、利用者情報１２を更新する（Ｓ８０２）。ステップＳ８０２では、カード残高６３から購入額が減額され、最終利用日６７が更新される。
ステップＳ８０２が済むと、出金電文２６を作成し（Ｓ８０３）、購入処理が終了する。出金電文２６には、出金のあったカード番号と出金額が記録される。ステップＳ８０１で、カード残高６３が購入額を上回らなかった場合、購入はできず、購入処理を終了する。
図１０は、入金処理、購入処理にて作成される電文のうち入金電文の例である。簡単化のためにカード番号が０００１の列だけを抜き出してある。電文が入金か、出金か、貸付かを示す電文種類７５、カード番号６２、実施された金額７６が記録される。図１０では、カード番号０００１で１０，０００円の入金が実施されたことがわかる。電文種類７１が、出金であれば、出金電文２６、貸付であれば、貸付電文２７である。また電文は、別々に送信されるのではなく、業務終了後その日の取引がまとめられて、取引報告電文として送信されてもよい。図１１は、取引報告電文の例である。
入金処理、購入処理で作成された電文は、金融機関サーバ４０に送信され、保留残高が更新される。これにより、電子財布のカード残高と、保留残高が一致し、電子マネー取引システムとしての整合性が保たれる。
以上述べてきた第１の実施の形態により、利用者は預金口座に設定保留額を上回る金額を預金しておけば、保留日に自動的に保留が実施され、その後取引決済端末において取引を行う際、決済と同時に自動的に入金手続きも行うことができるので、わざわざ入金手続きのために、電子マネー入金端末へ出向く手間を省くことができ、利用者にとっては便利である。
（２）第２の実施の形態
図２は、本発明の第２の実施の形態を示す図である。第２の実施の形態は、第１の実施の形態と異なり、金融機関サーバ４０と取引決済端末２０間のデータ送受信を電子マネー会社サーバ３０が仲介する場合である。第１の実施の形態は、電子マネーサービスの提供を金融機関自身が行うような場合に適用できるが、第２の実施の形態は金融機関とは別の機関が電子マネーサービスを提供する場合に適用可能である。
電子マネー会社サーバ３０は、電子マネーの残高や使用状況の履歴を利用者に提供するために、電子マネー口座を管理し、また取引決済端末２０と金融機関サーバ４０とのデータ送受信の仲介をする。電子マネー会社サーバ３０は、取引決済端末２０および金融機関サーバ４０とデータを送受信するための通信装置３１と、利用者の電子マネー口座情報３３を格納するための蓄積装置３２を備える。
電子マネー会社サーバ３０は、電子マネー口座情報３３として預金口座情報４３と同じ情報を管理し、また通信装置３１を用いて、取引決済端末２０と金融機関サーバ４０からのデータを転送すればよい。
通信装置３１は、必要な箇所以外に情報が流出しないようセキュリティに配慮し、電子マネー会社サーバと取引決済端末とを接続するネットワークと、電子マネー会社サーバと金融機関サーバとを接続するネットワークを切り離す目的で、２つの異なるインタフェースで実現されても、または２つの通信装置により実現されても構わない。
（３）第３の実施の形態
図３は、本発明の第３の実施の形態を示す図である。第３の実施の形態は、第１または第２の実施の形態において取引決済端末２０が複数存在する場合、各取引決済端末２０の通信装置２２でデータの送受信を行うのではなく、通信装置の機能を１箇所にまとめて行うものである。
図３では、第２の実施の形態を基にしている。第３の実施の形態では、取引決済端末２０は、蓄積装置２３に代わり、着脱可能な記録媒体２８と、電子財布１０内の利用者情報１２を読み出し、更新された情報を書き込むための電子財布リーダライタ２１とを備える。取引情報収集端末５０は、記録媒体２８からデータを読み出し、書き込む記録媒体リーダライタ５１と、電子マネー会社サーバ３０とデータの送受信を行う通信装置５２とを備えている。
第３の実施の形態は、例えば業務終了後に、各取引決済端末２０から記録媒体を外し、取引情報収集端末５０に装着することで、入金電文２４、出金電文２５、貸付電文２６、保留実施リスト２４の送受信を１箇所でまとめて行うものである。
これは、１つの拠点に多数の取引決済端末が存在するか、または仮の店舗やイベント等の臨時出店で、電子マネー会社サーバ３０とのネットワークが取引決済端末台数分確保できない環境に適している。
１つの拠点に多数の取引決済端末２０が存在すると、業務終了後の処理が業務終了を機に一度に大量に発生することになる。これにより、電子マネー会社サーバ３０や、取引決済端末２０が設定されている拠点のネットワークに負荷がかかり、処理の効率もよくない。そこで、１日の取引状況を１箇所にまとめて送受信すれば、こうした負荷を減らし、処理の効率を上げることが可能である。
また、臨時の出店やイベント等で、電子マネー会社サーバと接続する手段が取引決済端末２０の台数分確保できないことも考えられる。しかし１箇所でも電子マネー会社サーバ３０と接続する手段が確保でき、そこに取引情報収集端末５０を設置することができれば、業務終了後記録媒体２８を装着することで、入金電文２５、出金電文２６、貸付電文２７の送信と翌日以降の保留実施リスト２４を受信することができ、電子マネーを使用した決済が可能になる。
なお、記録媒体リーダライタ５１には、１度に複数の記録媒体を処理する能力があってもよい。
続いて実際の入金例を説明する。簡単化のために、１人の利用者についての動きを説明するが、複数人についての適用が可能である。また、本明細書における入金例は、第３の実施の形態で実施されるものとする。
（４）第１の入金例
次に第１の実施の形態に基づく、第１の入金例について説明する。第１の入金例は、金融機関サーバ４０にて保留日に保留が実施され、その翌日に利用者が取引決済端末２０にて決済を行う際に、入金手続きが行われ、電子財布１０内のカード残高６３が増額され、そして購入金額分減額される例である。
第１の入金例においては、保留日は、毎月２５日、設定保留額は１０，０００円で、最後に入金が行われたのは、２００２年５月２６日、最後に電子マネーが使用されたのは、２００２年６月２３日で、貸付機能は設定されていないとする。
図１２、図１３、図１４は、本発明の第１の実施の形態における第１の入金例を説明する図である。６月２５日の業務終了後の時点から説明を開始する。図１２には、６月２５日業務終了後の時点での、利用者Ｔａｒｏについての、利用者情報１０１、保留実施リスト１０２、預金口座情報１０３が書かれている。
まず、金融機関サーバ４０において、図５の保留処理が行われる（Ｓ１）。ステップＳ１では、保留処理の実施日が６月２５日であり、これは保留日６４にあたる（図５、Ｓ１０１）。預金口座残高３００，０００円が設定保留額１０，０００円を上回るので、１０，０００円の保留が実施され、預金口座残高７６が２９０，０００円に、保留残高７７が１３，０００円に、最終保留日７３が２００２年６月２５日に、それぞれ更新される（図５、Ｓ１０４）。図１２の預金口座情報１０４は、ステップＳ１０４で更新される箇所を抜き出したものである。
続いて、保留実施リスト２４が更新され、カード番号０００１の保留結果７４がＯＫになる（Ｓ１０６）。ステップＳ１０６で更新された保留実施リスト２４が取引決済端末２０に送信され（Ｓ１０７）、保留処理は終了する。
取引決済端末２０は、保留実施リスト１０２を更新する（Ｓ２）。ステップＳ５は、受信した保留実施リストをそのまま蓄積装置２３に保存すればよい。保留実施リスト１０５は、ステップＳ５で更新される箇所を抜き出したものである。６月２５日業務終了後の処理は以上である。
図１３に移り、６月２６日の業務時間中に、利用者は店舗で１，０００円の品物を購入するために、取引決済端末２０に電子財布１０を装着する（Ｓ３）。取引決済端末２０は、図８の入金処理を行う（Ｓ４）。
ステップＳ４では、最終利用日６７が２００２年６月２３日で、保留日６４が毎月２５日であることから、入金処理の実施日である２００２年６月２６日は、入金処理の実施日前の最も近い保留日後最初の利用日と判定される（図８、Ｓ７０１）。最新の保留実施リスト１０７を見ると、保留結果７４がＯＫとなっており、設定保留額と同じ１０，０００円の入金が実施され、カード残高が１３，０００円に、最終入金日が６月２６日に更新される（Ｓ７０５）。利用者情報１０６は、ステップＳ７０５で更新される箇所を抜き出したものである。続いて、入金電文２５が作成され（Ｓ７０６）、入金処理は終了する。入金電文２５には、カード番号０００１に１０，０００円の入金が実施されたことが記録される。
ステップＳ３が済むと、図９の購入処理を行う（Ｓ５）。ステップＳ５では、カード残高６３が１３，０００円、購入額は１，０００円なので、出金を実施する（図９、Ｓ８０１）。カード残高６３が１２，０００円に減額され、最終利用日６７が２００２年６月２６日に更新される（Ｓ８０２）。利用者情報１０７は、ステップＳ８０２で更新される箇所を抜き出したものである。ステップＳ８０２が済むと、出金電文２６が作成され（Ｓ８０３）、カード番号０００１で１，０００円の出金があったことが記録される。６月２６日業務中の処理は以上である。
６月２６日の業務終了後、取引決済端末２０は金融機関サーバ４０に入金電文２５を送信する（Ｓ６）。ステップＳ６で送信される入金電文２５により、金融機関サーバ４０は、カード番号０００１に対応する電子財布で１０，０００円の入金が実施されたことがわかる。金融機関サーバ４０は、既に保留処理の際に、預金口座情報４３を更新済みであり、受信した入金電文は確認のために用いる。
図１４に移り、ステップＳ６が済むと、取引決済端末２０は、金融機関サーバ４０に出金電文２６を送信する（Ｓ７）。ステップＳ７で送信される出金電文２６により、金融機関サーバ４０は、カード番号０００１に対応する電子財布１０で１，０００円の出金が実施されたことがわかる。次に金融機関サーバ４０は受信した出金電文２６に沿って預金口座情報４３を更新する（Ｓ８）。出金電文２６によって、１，０００円の出金がわかり、保留残高７２が１２，０００円に減額される。預金口座情報１０８はステップＳ８で更新される箇所を抜き出したものである。
ステップＳ８によって、電子財布１０内のカード残高６３と金融機関サーバ内の保留残高７２がすべて１２，０００円で一致し、同期が取られる。続いて、出金が実施された店舗に対して、購入代金の振込みが行われる（Ｓ９）。出金が行われた店舗の情報は、図示はしないが、出金電文２６に記録されていてもよいし、出金電文とは別に送信されてもよい。
以上会計の処理が済んだところで、金融機関サーバ４０は図５の保留処理を行う（Ｓ１０）。保留処理の実施日は、６月２６日であり、保留日ではない。最終保留日７３は預金口座情報１０５から２００２年６月２５日であり、１ヶ月は経過していないので、保留は実施されない（図５、Ｓ１０２）。カード番号０００１で保留が実施されなかったことが記録された保留実施リスト２４が取引区決済端末２０に送信され（Ｓ１０６）、保留処理は終了する。
取引決済端末２０では、保留実施リスト２４を更新する（Ｓ１１）。ステップＳ１０において、保留結果７４がＮＧになっており、それが反映される。保留実施リスト１０９は、ステップＳ１１で更新される箇所である。
以上で６月２６日の業務終了後の処理は完了し、第１の入金例は終了する。
第１の入金例によって、利用者が設定した保留日６４に保留が実施されれば、保留日６４後利用者が最初に取引決済端末２０にて決済を行う際に、電子財布に対し、電子財布のカード残高６３の増額が行われる。これによって、利用者はわざわざ電子マネー入金端末に行って入金手続きをする必要がなく、決済と同時に自動的に入金が実施されることになり便利である。最後に入金が実施された日を記録しておくことで、入金が誤って複数回実施されることも防ぐことができる。
また、当日の業務時間前までに得ている保留実施リストを基にカード残高の増額を行ううので、入金の承認を得るために金融機関や電子マネー会社とオンライン接続する必要がないことから、入金手続きの迅速化を実現でき、また通信費用のコスト削減も可能となる。
（５）第２の入金例
次に第２の入金例について説明する。第２の入金例は、保留日に預金口座残高不足により保留が実施されず、保留日の翌日に利用者が取引決済端末にて決済を行う際には、入金手続きが行われず、電子財布の金額データは購入金額分減額される。その後、預金口座に入金がされた結果、保留が実施され、保留実施日の翌日に利用者が取引決済端末にて決済を行う際に、入金手続きが行われる例である。
第２の入金例においては、保留日は、毎月２５日、設定保留額は１０，０００円で、最後に入金が行われたのは、２００２年５月２６日、最後に電子マネーが使用されたのは、２００２年６月２３日で、貸付機能は設定されていないとする。
図１５、図１６、図１７、図１８は、本発明の第１の実施の形態における第２の入金例を説明する図である。６月２５日の業務終了後の時点から説明を開始する。図１５には、６月２５日業務終了後の時点での、利用者Ｔａｒｏについての、利用者情報１１０、保留実施リスト１１１、預金口座情報１１２が書かれている。
まず、金融機関サーバ４０において、図５の保留処理が行われる（Ｓ１）。保留処理の実施日は６月２５日であり、これは保留日６４であるため、預金口座残高が設定保留額を上回るか判定される（図５、Ｓ１０３）。だが、預金口座残高が２０円しかなく、設定保留額を上回らないので、保留は実施されない。カード番号０００１で、保留が実施されなかったことが記録された保留実施リスト２４が、取引決済端末２０に送信され（Ｓ１０６）、保留処理は終了する。
取引決済端末２０は、保留実施リスト２４を更新する（Ｓ２）。ステップＳ５は、受信した保留実施リストを保存すれば、更新が完了する。ここでは、保留が実施されておらず、特に保留実施リスト１１１と変更はない。６月２５日の業務終了後の処理は以上である。
６月２６日の業務時間中に、利用者は店舗で１，０００円の品物を購入するために、取引決済端末２０にて決済を行う（Ｓ３）。取引決済端末２０は、図８の入金処理を行う（Ｓ４）。まず入金処理の実施日が本入金処理の実施日前の最も近い保留日以降最初の利用か判定する（図８、Ｓ７０１）。利用者情報１２を読み取り、最終利用日６７が２００２年６月２３日、保留日６４が毎月２５日であるので、入金処理の実施日である２００２年６月２６日は、入金処理の実施日前の最も近い最初の利用日と判定される。続いて保留が実施されたか確認する（Ｓ７０３）。保留実施リスト１１１を見ると、保留結果はＮＧである。次に貸し付け機能の有無を判定する（Ｓ７０４）。利用者情報１１０をみれば、貸付機能６８も「無し」であり設定されていないため、入金は実施されず、入金処理を終了する。
続いて、図１６に移り、取引決済端末２０は図９の購入処理を行う（Ｓ５）。カード残高６３は、３，０００円で、購入額は１，０００円であるので、出金が実施される（Ｓ８０１）。カード残高６３が、２，０００円に減額され、最終利用日６７が６月２６日に更新される（Ｓ８０２）。利用者情報１１８は、ステップＳ８０２で更新される箇所を抜き出したものである。そして、出金電文２６が作成される（Ｓ８０３）。出金電文２６には、カード番号０００１にて１，０００円の出金があったことが記録される。
６月２６日の業務終了後、取引決済端末２０は金融機関サーバ４０に出金電文２６を送信する（Ｓ７）。
金融機関サーバ４０は、受信した出金電文２６に沿って預金口座情報４３を更新する（Ｓ８）。変換された出金電文２６によって、金融機関サーバ４０は、カード番号０００１にて１，０００円の出金が実施されたとわかり、保留残高７２が２，０００円に減額される。預金口座情報１１４は、ステップＳ８で更新される箇所を抜き出したものである。そして、出金が実施された店舗に対して、購入代金の振込みが行われる（Ｓ９）。
ステップＳ９が済むと、金融機関サーバ４０は、図５の保留処理を行う（Ｓ１０）。保留処理の実施日は、６月２６日であり、保留日ではない。最終保留日７３は預金口座情報１１７から２００２年５月２６日であり、１ヶ月が経過するので、保留可能かを判定するためステップＳ１０３を行う（図５、Ｓ１０２）。しかし、預金口座残高７１は２０円のままであり、設定保留額６５を上回ることなく、保留は実施されない（Ｓ１０３）。カード番号０００１で保留が実施されなかったことが記録された保留実施リスト２４が取引決済端末２０に送信され（Ｓ１０６）、保留処理は終了する。
取引決済端末２０では、保留実施リスト２４を更新する（Ｓ１１）。６月２６日業務終了後の処理は以上である。
図１７に移り、６月２７日に、預金口座Ａ０００１へ３００，０００円の入金が実施される（Ｓ１２）。預金口座残高７１が、預金口座情報１１５に示されるように、３００，０２０円に増額される。
６月２７日の業務終了後、金融機関サーバ４０は、図５の保留処理を行う（Ｓ１３）。保留処理の実施日は、６月２７日であり、保留日ではないが、最終保留日７３は、２００２年５月２５日であり、１ヶ月が経過しているため、保留額の計算が行われる（図５、Ｓ１０２）。保留方法は、差額であり、設定保留額１０，０００円と、保留残高２，０００円の差額である８，０００円が保留額になる。預金口座残高７１は、３００，０２０円であり、保留額を上回るので、保留が実施される（Ｓ１０４）。預金口座残高７１が、２９２，０２０円、保留残高７２が１０，０００円、最終保留日７３が６月２７日に更新される（Ｓ１０５）。預金口座情報１１６は、ステップＳ１０５で更新される箇所を抜き出したものである。そして、カード番号０００１で保留が実施されたことが記録された保留実施リスト２４が送信され（Ｓ１０７）、保留処理は終了する。
取引決済端末２０は、保留実施リスト２４を更新する（Ｓ１４）。保留実施リスト１１７は、ステップＳ１４で更新される箇所を抜き出したものである。
６月２８日の業務中、利用者は店舗で１，０００円の品物を購入するために、取引決済端末２０にて決済を行う（Ｓ１５）。図１８に移り、取引決済端末２０は、図８の入金処理を行う（Ｓ１６）。利用者情報１１０および利用者情報１１３から最終利用日６７が２００２年６月２６日で、保留日６４が毎月２５日であることから、入金処理の実施日である２００２年６月２７日は、入金処理の実施日前の最も近い保留日後最初の利用日ではない（図８、Ｓ７０１）。したがって、最終入金日６６から１ヶ月が経過しているか判定する（Ｓ７０２）。利用者情報１１０から、最終入金日６６は、２００２年５月２６日であり、１ヶ月が経過しており、保留が実施されたか判定する（Ｓ７０３）。保留実施リスト１１７から、カード番号０００１の保留結果はＯＫであり、入金が実施される（Ｓ７０５）。カード残高６３が１２，０００円に、最終入金日６６が６月２８日に更新される。利用者情報１１８は、ステップＳ７０５で更新される箇所である。ステップＳ７０５が済むと、入金電文２５が作成される。入金電文２５には、カード番号０００１で、１０，０００円の入金が実施されたことが記録される。
後に続く、購入処理や、業務終了後の処理は、第１の入金例のステップＳ５からステップＳ１１と同じであり、説明は省略する。以上で第２の入金例を終了する。
第２の入金例によって、利用者が設定した保留日６４に預金口座残高７１が保留額を上回らず、その結果保留が実施されなくても、保留日後預金口座残高７１が保留額を上回れば、自動的に保留が実施され、その後店舗での決済を行う際にオフラインで電子財布のカード残高６３が増額され、入金が実施される。預金口座への入金や振込みは、多数あるＡＴＭ、携帯端末、ＰＣなどのさまざまな手段を用いて行うことができ、電子マネーの入金端末で行うよりも、作業は行いやすく利用者にとっては便利である。
（６）第３の入金例
続いて第３の入金例を説明する。第３の入金例は、保留日に保留が実施されなかったが、貸付機能が設定されており、保留日の翌日に利用者が取引決済端末にて決済を行う際に、電子財布の金額データが保留額分増額される例である。
第３の入金例においては、保留日は、毎月２５日、保留方法は一定、設定保留額は１０，０００円で、最後に入金が行われたのは、２００２年５月２６日、最後に電子マネーが使用されたのは、２００２年６月２３日で、貸付機能が設定されているとする。
図１９、図２０は、本発明の第１の実施の形態における第３の入金例を説明する図である。６月２５日の業務終了の時点から説明を開始する。図１９には、６月２５日業務終了後の時点での、利用者Ｔａｒｏについての、利用者情報１１９、保留実施リスト１２０、預金口座情報１２１が書かれている。
まず、金融機関サーバ４０において、図５の保留処理が行われる（Ｓ１）。保留処理の実施日は６月２５日であり、これは保留日であるため、保留可能か判定するステップＳ１０３を行う（図５、Ｓ１０１）。だが、預金口座残高は２０円であり、設定保留額６５を上回っていないので、保留は実施されない（Ｓ１０３）。カード番号０００１で保留が実施されなかった旨が記録された保留実施リスト２４が、取引決済端末２０へ送信され（Ｓ１０６）、保留処理は終了する。
取引決済端末２０は受信した保留実施リスト２４を更新する（Ｓ２）。保留が実施されなかったので、保留実施リスト１２０と変更はない。
６月２６日の業務中に、利用者は店舗で１，０００円の品物を購入するために、取引決済端末２０にて決済を行う（Ｓ３）。図２０に移り、取引決済端末２０は図８の入金処理を行う（Ｓ４）。保留日は、毎月２５日で、最終利用日が６月２３日であることから、入金処理の実施日である２００２年６月２６日は、入金処理の実施日前の最も近い保留日後最初の利用日と判定され、保留結果７４がＯＫか判定される（図８、Ｓ７０３）。保留実施リスト１２０を見ると、保留結果はＮＧであるため、貸付機能６８が設定されているか判定する（Ｓ７０４）。利用者情報１１９の貸付機能６８は「あり」で、貸付機能が設定されている。したがって、貸付として入金が実施される。設定保留額６５と同額の１０，０００円分電子財布のカード残高が増額される（Ｓ７０５）。カード残高６３が１３，０００円に、最終入金日６６が６月２６日に更新される。利用者情報１２２は、ステップＳ７０５で更新される箇所を抜き出したものである。そして、貸付電文２７が作成される（Ｓ７０６）。貸付電文２７には、カード番号０００１で、１０，０００円の貸付が実施されたことが記録されている。
続いて、取引決済端末２０は図９の購入処理を行う（Ｓ５）。カード残高６３は、１３，０００円で、購入額は１，０００円であり、購入は可能である。そこで出金が実施され、カード残高６３が１２，０００円に、最終利用日６７が６月２６日に更新される（図９、Ｓ８０２）。利用者情報１２３は、ステップＳ８０２で更新される箇所を抜き出したものである。
６月３０日の業務終了後、取引決済端末２０は、貸付電文２７を送信する（Ｓ１７）。貸付電文２７によって、金融機関サーバ４０は、カード番号０００１に対応する電子財布１０にて、１０，０００円の貸付が実施されたことがわかる。
金融機関サーバ４０は、受信した貸付電文２７を基に、預金口座情報４３を更新する（Ｓ１８）。保留残高７２が１３，０００円に、貸付残高７０が１０，０００円に更新される。預金口座情報１２４は、ステップＳ１８で更新される箇所を抜き出したものである。
その後の業務終了後の処理は、第１の実施例のステップＳ７からステップＳ１１までと同じであり、説明は省略する。
以上で第３の入金例を終了する。
第３の入金例によって、利用者が貸付機能６８を設定しておけば、預金口座残高７１が不足して保留日６４に保留が実施されなくても、入金処理の実施日前の最も近い保留日後最初に取引決済端末２０で決済を行う際に、貸付として電子財布のカード残高６３が増額される。このとき、電子マネー会社または金融機関にオンラインで承認を得ることなく、オフラインで処理を行うことが可能である。利用者にとっては、預金口座残高７１が不足しても通常通り、電子マネーの使用を続けることができ、便利である。また、１度貸付が行われると、次回の保留日６４が来るか、または１ヶ月が経過しないと、貸付が実施されないので、過度の貸付を防止することもできる。
なお本実施例は、図示はしないが、電子マネー会社との契約時に、貸付限度額を設定するか、もしくは金融機関が貸付限度額を設定し、貸付残高７６が当該貸付限度額を超えない範囲で貸付が行われることが望ましい。
なお、本明細書において、電子財布１０は、ＩＣカードで実現されているものとしたが、利用者情報１２の蓄積機能を備えた携帯端末で実現されてもよい。また、金融機関は銀行で実現されているものとしたが、クレジットカード会社で実現することも可能である。その場合、すべての入金を貸付として処理すればよい。通常、与信限度額が設定されるので、貸付残高７０が与信限度額を超えたときは、保留が実施されないようにする。引き落としが実施されれば、貸付残高をゼロに戻せばよい。

産業上の利用の可能性

以上説明したように本発明によれば、入金手続き時に金融機関や電子マネー会社とオンラインで接続されていないオフライン環境であっても、取引決済端末にて、利用者が商品やサービスの決済を行う際に、電子財布の金額データが増額される。また、店舗などに設置される取引決済端末を用いて電子マネーの入金を行うことができ、電子マネーの入金専用の端末を別に設置する必要がなくなり、入金端末の開発、設置、管理にかかるコストを削減することが可能である。

Claims (16)

1. 利用者が取引可能な金額データが記録された電子財布と、前記電子財布に記録された金額データに基づき取引を可能とする取引決済端末と、前記利用者の預金口座を登録して管理する金融機関サーバを有する電子マネー取引システムにおける電子財布の金額データ更新方法であって、
   前記金融機関サーバにおいて、前記利用者の預金口座残高のうち所定額を保留額として設定し、
   前記取引決済端末において、前記電子財布により取引が行われる際、前記設定された保留額と、取引金額に基づき前記電子財布に利用可能金額を更新記録することを特徴とする電子財布の金額データ更新方法。
2. 請求の範囲１において、
   前記利用者の預金口座残高のうち所定額として設定される保留額は、前記利用者により前記金融機関サーバに対して要求された額であることを特徴とする電子財布の金額データ更新方法。
3. 請求の範囲２において、
   更に、前記利用者により前記金融機関サーバに対して保留日の設定を可能とし、前記保留日に、前記利用者の預金口座残高が、保留額を上回ることを条件として前記保留額を設定することを特徴とする電子財布の金額データ更新方法。
4. 請求の範囲２において、
   更に、前記金融機関サーバにおいて、最後に保留が実施された最終保留日が記録され、前記最終保留日から所定日が経過後、前記利用者の預金口座残高が保留額を上回ることを条件として前記保留額を設定することを特徴とする電子財布の金額データ更新方法。
5. 請求の範囲２において、
   前記利用者により前記電子財布に対して貸付機能の設定を可能とし、前記貸付機能の設定がされていることを条件とし、前記利用者の預金口座残高に関係なく、前記所定額が保留額として設定されることを特徴とする電子財布の金額データ更新方法。
6. 請求の範囲１または請求の範囲２において、
   更に、前記電子財布において、最後に金額データが増額された最終入金日が記録され、前記取引決済端末において、前記最終入金日から所定日が経過後であることを条件として前記保留額と前記取引金額に基づき前記利用金額を更新記録することを特徴とする電子財布の金額データ更新方法。
7. 請求の範囲４において、
   更に、前記電子財布において、最後に金額データの更新が実施された最終入金日が記録され、前記取引決済端末において、前記最終入金日が、前記最終保留日前であることを条件として前記保留額と前記取引金額に基づき前記利用金額を更新記録することを特徴とする電子財布の金額データ更新方法。
8. 利用者が取引可能な金額データが記録された電子財布と、前記電子財布に記録された金額データに基づき取引を可能とする取引決済端末と、前記利用者の預金口座を登録して管理する金融機関サーバを有する電子マネー取引システムにおいて、
   前記金融機関サーバは、前記利用者の預金口座残高のうち所定額を保留額として設定し、
   前記取引決済端末は、前記電子財布により取引が行われる際、前記設定された保留額と、取引金額に基づき前記電子財布に利用可能金額を更新記録することを特徴とする電子マネー取引システム。
9. 請求の範囲８において、
   更に、前記取引決済端末は着脱可能な記録媒体を有し、電子マネー取引システムは前記記録媒体のデータを一括して送受信するための取引情報収集端末を有することを特徴とする電子マネー取引システム。
10. 請求の範囲８において、
    前記利用者の預金口座残高のうち所定額として設定される保留額は、前記利用者により前記金融機関サーバに対して要求された額であることを特徴とする電子マネー取引システム。
11. 請求の範囲１０において、
    前記電子財布は、前記利用者により設定される貸付機能データを有し、前記貸付機能の設定がされていることを条件とし、前記金融機関サーバは、前記利用者の預金口座残高に関係なく、前記所定額を保留額として設定することを特徴とする電子マネー取引システム。
12. 請求の範囲１０おいて、
    更に、前記金融機関サーバは、前記利用者により設定される保留日データを有し、前記保留日に、前記利用者の預金口座残高が、保留額を上回ることを条件として前記保留額を設定することを特徴とする電子マネー取引システム。
13. 請求の範囲１０において、
    更に、前記金融機関サーバは、最後に保留が実施された最終保留日データを有し、前記最終保留日から所定日が経過後、前記利用者の預金口座残高が前記保留額を上回ることを条件として前記保留額を設定することを特徴とする電子マネー取引システム。
14. 請求の範囲８または請求の範囲１０において、
    更に、前記電子財布は、最後に金額データが増額された最終入金日データを有し、前記取引決済端末は、前記最終入金日から所定日が経過後であることを条件として前記保留額と前記取引金額に基づき前記利用金額を更新記録することを特徴とする電子マネー取引システム。
15. 請求の範囲１３において、
    更に、前記電子財布は、最後に金額データが増額された最終入金日データを有し、前記取引決済端末は、前記最終入金日が、前記最終保留日前であることを条件として前記保留額と前記取引金額に基づき前記利用金額を更新記録することを特徴とする電子マネー取引システム。
16. 請求の範囲１または請求の範囲８において、
    前記電子財布は、ＩＣカード、赤外線または短距離無線による通信機能を備えた携帯型端末または携帯電話であることを特徴とする、前記金額データの更新方法。

Images