JP6815234B2 - 汎用携帯端末を利用した決済システム - Google Patents

Description

本願発明は、ネットワークを利用した銀行口座間の決済システムに関し、特に利用者が汎用携帯端末や汎用パーソナルコンピュータを利用して決済をおこなう決済システムに係る。

現金以外で決済を行う方法としては、クレジットカードやデビットカードを使用する方法がある。デビットカードによる決済を行うデビットカードサービスであるＪ−Ｄｅｂｉｔ（登録商標）や、同じ銀行の普通預金口座・当座預金口座と取りまとめ口座（別段口座）間で口座振替により即時に資金引落しを行うＣＡＲＤＮＥＴ（登録商標）社の２４時間のリアルタイム口座振替サービスが普及している。また、特開２００９−１７６０６５のように、携帯電話のＩＣチップに電子マネーアプリを組み込み、携帯電話機を利用して電子マネーによる決済を行う技術もある。

特開２００９−１７６０６５

店舗や病院において、クレジットカードやデビットカードを利用できるようにするためには、店舗や病院が決済専用の端末と専用の通信線を用意する必要があり、それらの導入に費用がかかる。また、利用者はクレジットカードやデビットカードをもって、店舗や病院に出向き、店舗や病院にある専用端末にカードを挿入して暗証番号を入力する必要があり、利用に場所や時間の制限がある。特開２００９−１７６０６５では、現金から電子マネーへの変換が必要となり、決済に専用の端末が必要となる。

本願発明では、リアルタイム口座振替サービスを提供するリアルタイム口振ゲートウェイ（ＧＷ）と専用回線を介して接続し、かつ、顧客端末や店舗端末とインターネットを介して接続するウォレットサーバを設ける。顧客と加盟店（および加盟病院）は、それぞれ収納代行企業である銀行（Ｘ銀行とする）に普通預金口座あるいは当座預金口座を持ち、それぞれＸ銀行と口座振替契約を結ぶ必要がある。ウォレットサーバには、口座振替契約を完了した顧客と加盟店の口座情報を予め登録する。ウォレットサーバは、顧客と加盟店にそれぞれシステムに唯一のＩＤを付与する。顧客と加盟店は、それぞれ決済端末用アプリケーションソフトウェア（以下、ユーザアプリとお店アプリ）をそれぞれの携帯端末や汎用パーソナルコンピュータ（以下、端末）にインストールする。決済用アプリケーションソフトウェア（以下、決済アプリ）により、顧客端末と加盟店端末はウォレットサーバを介して通信を行い、加盟店端末が顧客端末に請求書を送る。顧客が請求金額を承認すると、ウォレットサーバ内の決済アプリは顧客の口座情報と請求金額から、口座振替用のデータを作成し、リアルタイム口振ＧＷに送信する。リアルタイム口振ＧＷは、顧客の口座から引落を行って、Ｘ銀行の取りまとめ口座に入金を行う。この段階では、支払い先の加盟店への入金がされていないので、仮決済と呼ぶことにする。ウォレットサーバ内の決済アプリは、リアルタイム口振ＧＷから引落完了の報告を受け取ると、領収書を作成し、顧客端末に領収書を送信する。

取りまとめ口座には、複数の加盟店へ支払われるべき金が区別されることなく一緒に一時保管される。ウォレットサーバは、各加盟店との契約により、定期的に、あるいは、加盟店からの要求に応じて、Ｘ銀行の取りまとめ口座から、加盟店へ支払われるべき金額（分配金）を集計する。さらに、ウォレットサーバは、加盟店の口座情報と請求金額から、入金用口座振替データを作成し、リアルタイム口振ＧＷに送信する。リアルタイム口振ＧＷは、Ｘ銀行の取りまとめ口座から、加盟店の銀行口座への分配金の入金を行う。

加盟店は、決済用に特別な端末や通信回線を用意する必要が無い。個人顧客もカードを持ち歩く必要が無い。また、決済の場所や時間に制限が無い。端末とウォレットサーバの接続には、インターネットを利用するが、口座情報などの重要な情報はインターネットを介さずにリアルタイム口振ＧＷに送られるため、安全性が高い。また、個人顧客の端末に、口座情報やパスワードなどの重要な情報を保存しないため、端末の紛失や盗難による情報漏れや不正利用の可能性が少なくなる。

本発明の他の目的、特徴及び利点は添付図面に関する以下の本発明の実施例の記載から明らかになるであろう。

決済システムの全体的な構成図である。 ウォレットサーバの構成図の一例である。 顧客データベース（ＤＢ）の構成図の一例である。 店舗ＤＢの構成図の一例である。 決済管理ＤＢの構成図の一例である。 実施例１による顧客と店舗で行う決済の流れを示すフローチャートである。 実施例１による顧客端末に示される店舗選択画面表示例である。 実施例１による顧客端末に示されるクーポン提示の表示例である。 実施例１による顧客端末に示される決済画面の表示例である。 実施例１による顧客端末に示されるレシートの表示例である。 実施例１による店舗端末に示される顧客チェックイン時の表示例である。 実施例１による店舗端末に示されるクーポン承認時の表示例である。 実施例１による店舗端末に示される請求額入力表示例である。 実施例１による店舗端末に示される領収書の写し表示例である。 顧客の口座から引落を行うときの口座振替データの一例である。 ウォレットサーバにおいて、取りまとめ口座から各加盟店への分配金の入金処理を行う流れを示すフローチャートである。 取りまとめ口座から各加盟店への入金を行うときの口座振替データの一例である。 マルチバンク決済を説明するための図である。 実施例５によるウォレットサーバの構成図の一例である。 実施例５による顧客ＤＢの構成図である。 実施例５による店舗ＤＢの構成図の一例である。 実施例５による決済管理ＤＢの構成図の一例である。 ウォレットサーバにおいて、銀行間決済を行う流れを示すフローチャートである。

１．システムの全体図
図１に決済システム全体の構成図を示す。
顧客端末１は、汎用的なスマートフォンやタブレットなどの携帯端末であり、タッチパネルなどの入力装置、ディスプレイ画面、インターネットに接続するための無線インタ―フェイス、プロセッサ、メモリを含む。カメラ、Ｂｌｕｅｔｏｏｔｈ（登録商標）や赤外線などの近距離通信システム、ＧＰＳを含んでも良い。顧客端末１は、決済のための決済顧客アプリ（ユーザアプリ）がインストールされている。

店舗端末２も、汎用的なスマートフォン、タブレット、パーソナルコンピュータであり、タッチパネル、マウス、キーボードなどの入力装置、ディスプレイ画面、インターネットに接続するための無線または有線インタ―フェイス、プロセッサ、メモリを含む。カメラ、Ｂｌｕｅｔｏｏｔｈ（登録商標）や赤外線などの近距離通信システム、ＧＰＳを含んでも良い。店舗端末２は、決済のための決済店舗アプリ（お店アプリ）がインストールされている。

ウォレットサーバ４は、顧客端末１、店舗端末２と公衆回線、代表的にはインターネット３により接続される。リアルタイム口座振替ゲートウェイ（リアルタイム口振ＧＷ）７は専用ネットワーク６により収納代行銀行であるＸ銀行のコンピュータシステム８に接続される。ウォレットサーバ４とリアルタイム口振ＧＷ７は、専用回線５により接続される。リアルタイム口振ＧＷ７は、リアルタイムの口座振替サービスを提供する。

２．ウォレットサーバの構成
図２にウォレットサーバ４の構成を示す。ウォレットサーバ４は、プロセッサ、メモリ、大容量記録装置、通信インターフェイスを含む、汎用のサーバであり、図２に示す各部は、プロセッサがメモリ上のソフトウェアプログラムを実行することにより、実現される。

決済アプリケーションソフトウェア（決済アプリ）２００は、以下の機能を実現する部を含む。
（１）認証部２０１：ウォレットサーバ４にアクセスしてきた顧客や店舗を、パスワードのような良く知られた方法を用いて認証する。
（２）口座残高確認部２０２：決済時に、顧客の口座残高を確認する要求をリアルタイム口振ＧＷ７へ出し、顧客の口座のある銀行から顧客の口座残高を入手する。

（３）店舗検索部２０３：顧客端末１からの店舗検索要求と検索条件にしたがって、店舗を検索し、顧客端末１に検索結果を送信する。
（４）通信処理部２０４：顧客端末１と店舗端末２の間の通信を中継し、情報を相互に伝達する。また、ウォレットサーバ４と顧客端末１または店舗端末２の間の通信をおこなう。

（５）割引処理部２０５：顧客端末１が提示し、店舗端末２が承認したクーポンやスタンプに応じて、店舗の定めた割引処理に従って割引金額を計算し、決済金額を決定する。
（６）仮決済処理部２０６：顧客の口座から決済金額を引落して収納代行機関（Ｘ銀行）の取りまとめ口座へ入金するための口座振替データを作成し、リアルタイム口振ＧＷ７に送信する。また、リアルタイム口振ＧＷ７から、引落が正常に完了したかどうかの応答を受け取り、決済管理ＤＢ２４０に記録する。

（７）レシート発行処理部２０７：顧客の口座からの引落が正常に完了したら、レシートを作成し、顧客端末に発送する。
（８）収納金分配部２０８：取りまとめ口座から、各加盟店への収納金の分配を行う。
決済アプリは、その他の処理部、例えば、店舗端末２からの要求により、該当店舗の過去の顧客の中から、条件にあう顧客を検索して、店舗端末２に送信する処理部を含んでも良い。さらに、その処理部は、店舗端末２からの依頼により、検索した顧客に販売促進のための情報を送信しても良い。

上述の機能を実現するために、決済アプリ３００は、以下に示すデータベース（ＤＢ）を使用する。
（Ａ）顧客ＤＢ２２０：図３に一例を示す。顧客ＤＢ２２０は、顧客（ユーザ）をシステムにおいて一意に識別するためのユーザＩＤ３１、ユーザの名前などのユーザ情報３２、ユーザを認証するための情報であるパスワード３３、ユーザの銀行口座情報３４を含む。銀行の口座番号やパスワードは、暗号化されて保存されても良い。顧客ＤＢ２２０は、ユーザが過去に利用した店舗やクーポンを取得した店舗の情報を保持するための利用店舗情報３５を含んでも良い。利用店舗情報３５は、例えば、店舗ＩＤ毎３７に作成され、その店舗に関係するクーポン、スタンプ、割引券、レシートを保存する。接続情報３６は、決済アプリ２００とユーザアプリの接続および通信に使用される情報であり、たとえば、電話番号である。また、顧客の電子メールアドレスを顧客ＤＢ２２０に含んでも良い。
顧客が所定のＸ銀行との口座振替の契約手続きをおこなうことにより、名前、銀行口座情報が顧客ＤＢ２２０登録され、顧客にはユーザＩＤが割り当てられる。

（Ｂ）店舗ＤＢ２３０：図４に一例を示す。店舗ＤＢ２３０は店舗をシステムにおいて一意に識別するための店舗ＩＤ４１、店舗の名前、種別、位置、ＵＲＬなどの店舗情報４２、店舗を認証するための情報であるパスワード４３、店舗の銀行口座情報４４、取りまとめ口座から各店舗へ入金のタイミングを定める分配日４７を含む。分配日４７を未設定にすることにより、店舗からの入金要求に応じて収納金入金を行うようにしても良い。銀行の口座番号やパスワードは、暗号化されて保存されても良い。割引情報４５は、店舗の発行したクーポンやスタンプに対する割引の内容を定める。店舗ＤＢ２３０は、過去の顧客の情報を保存する顧客情報４６を含んでも良い。顧客情報４６は、例えば、ユーザＩＤ毎４８に作成され、その顧客の過去の来店日時、利用金額などを保存できる。接続情報４８は、決済アプリ２００とお店アプリの接続および通信に使用される情報であり、たとえば、ＩＰアドレスである。店舗が、所定のＸ銀行との口座振替の契約手続きをおこなうことにより、店舗情報、銀行口座情報が店舗ＤＢ２３０登録され、店舗には店舗ＩＤが割り当てられる。

（Ｃ）決済管理ＤＢ２４０：図５に一例を示す。決済管理ＤＢ２４０は、決済をシステムにおいて一意に識別するための決済ＩＤ５１、支払いを行う顧客のユーザＩＤ５２、支払いを受ける店舗の店舗ＩＤ５３、仮決済の日時（開始と終了）５４、決済金額５５、仮決済の状態５７を含む。仮決済の状態としては、顧客口座からの引落依頼を作成するまでの「準備中」、引落要求をリアルタイム口振ＧＷ７に送信した後の「引落中」、リアルタイム口振ＧＷ７から引落正常終了を受け取りレシートを作成中の「レシート作成中」、レシートを送信済みの「仮決済正常終了」などがある。分配５８は、取りまとめ口座から加盟店への分配処理がされたか否かを示す。分配処理がされていない場合は、「未」、分配処理がされた場合は、「済み」または分配処理の通番が入る。また、付属情報５６として、割引に使用した、クーポンなどの情報や、請求金額の明細を保存しても良い。

（Ｄ）トランザクション記録ＤＢ２５０：決済管理ＤＢ２４０において、分配処理が終了したレコードをトランザクション記録ＤＢ２５０に移して一定の期間保存する。

３．ユーザ端末と店舗端末
上述のように、ユーザ端末や店舗端末は汎用のスマートフォンやタブレット端末であるが、それぞれ決済ユーザアプリケーションプログラム（ユーザアプリ）と決済お店アプリケーションプログラム（お店アプリ）がインストールされている必要がある。
ユーザアプリとお店アプリは、ユーザや店舗従業員がアプリを選択し、ユーザＩＤとパスワード、店舗ＩＤとパスワードをそれぞれ入力する事により、（および、決済アプリ２００の認証部２０１が認証する事により）ウォレットサーバの利用が可能になる。ユーザＩＤと店舗ＩＤ、およびそれぞれのパスワードは、それぞれのアプリ内に保存されるようにしても良い。ユーザアプリとお店アプリは、それぞれユーザ端末１と店舗端末２の画面に選択肢や入力指示を表示し、ユーザや店舗従業員によって選ばれた選択肢や入力されたデータをウォレットサーバ４の決済アプリ２００へ送信する。選ばれた選択肢や入力されたデータは、決済アプリ２００への要求となり、決済アプリ２００によって処理される。決済アプリ２００は、要求に対する応答を作成して、ユーザアプリまたはお店アプリに送信する。ユーザアプリまたはお店アプリは、決済アプリ２００から受信した応答に従って画面を表示する。

顧客が店舗で食事や買い物をしたあとに、本決済システムにより決済を行う実施例を示す。図６に本決済システムによる決済の流れを示す。以下のステップはウォレットサーバ４の決済アプリ２００により実行される。

＜ステップ６０１＞ 顧客端末１のユーザアプリ上での店舗へのチェックイン操作に応じて、チェックインされた店舗を識別し、識別された店舗の店舗端末２のお店アプリに顧客端末１のユーザ情報を知らせるとともに、ユーザＩＤと店舗ＩＤを含むレコードを作成し、決済管理ＤＢ２３０に登録する。両者の決済手続きに対しシステムで一意な決済ＩＤを割り振る。ユーザアプリ、お店アプリと決済アプリ間の通信には、この決済ＩＤが使用される。（通信処理部２０４と仮決済処理部２０６）

＜ステップ６０２＞ 顧客端末１のユーザアプリ上の操作によりクーポンやスタンプの提示があれば、店舗端末２にその情報を転送する。店舗端末２から承認が得られれば、その情報を決済管理ＤＢ２４０の該当レコードに付属情報５６として保存する。（通信処理部２０４と割引処理部２０５）

＜ステップ６０３＞ 店舗端末２のお店アプリから顧客への請求額送信を受信して、決済管理ＤＢ２４０の付属情報５６に保存する。請求額とともに明細が送信されてきている場合には、明細も同様に保存する。その時にステップ６０２において保存された割引情報がある場合には、店舗ＤＢの割引情報４５を参照して割引額を計算し、割引後の請求額を決済金額として顧客端末１へ送信するとともに、決済管理ＤＢ２４０の該当レコード（決済金額５５）に保存する。決済金額とともに、割引前の請求額と明細を一緒に顧客端末１へ送信しても良い。（通信処理部２０４と割引処理部２０５）

＜ステップ６０４＞ 顧客端末１のユーザアプリ上でユーザが金額を確認し、顧客とウォレットサーバの間で定められた暗証番号あるいはパスワードを入力すると、その情報が決済アプリ２００に通知される。決済アプリは、顧客ＩＤを使用して顧客ＤＢ２２０から顧客の銀行口座番号を入手し、（情報が暗号化されている場合には、復号化を行ったうえで、）引落銀行口座および決済金額から、引落のための口座振替データを作成し、リアルタイム口振ＧＷ７に送信する。

図９は、顧客の口座から引落を依頼するときのリアルタイム口振ＧＷ７に送信される口座振替データの一例である。口座振替データは、データ種別（引落）９１、顧客（ユーザ）の口座情報９２、決済金額９３、引落日時９４を含む。口座情報９２は、銀行コード、支店番号、口座科目、口座番号を含む。また、実施形態に応じて、オプション情報９５として、処理通番、支払い先の店舗ＩＤを含んでも良い。リアルタイム口振ＧＷ７は、この口座振替データを受信すると、顧客の口座から決済金額を引き落とし、収納代行銀行の取りまとめ口座へ入金する。

＜ステップ６０５＞リアルタイム口振ＧＷ７から引落正常終了の通知を受けると、決済アプリ２００は、決済管理ＤＢ２４０に保存しておいた明細、割引前請求額と、決済金額と店舗名をいれた領収書を作成し、顧客端末１のユーザアプリに送信する。また、領収書の写しを店舗端末２のお店アプリに送信してもよい。その後、決済管理ＤＢ２４０の該当決済ＩＤの状態５７を「仮決済正常終了」とする。また、決済管理ＤＢ２４０の該当決済ＩＤの記録をユーザアプリやお店アプリからの要求により、顧客ＤＢ２２０や店舗ＤＢ２３０に保存しても良い。（仮決済処理部２０６とレシート発行処理部２０７）

上述のステップに応じた顧客端末１および店舗端末２の画面表示例を図７Ａ−７Ｄおよび図８Ａ−８Ｄに示す。図７Ａは、顧客がユーザアプリを開き、店舗リストが顧客端末１に表示された場合の例である。顧客が端末画面に表示された店舗リストの中から店舗をタップ動作により選択すると、チェックイン手続きが開始される。支払い時に図７Ｂのようにして、クーポンやポイントを提示・送信できる。

チェックインされた店舗端末２での表示例を図８Ａに示す。店舗従業員は、表示された顧客をタップにより選択し、図８Ｂの画面で提示されたクーポンやスタンプが利用可能かどうかチェックし、承認する。図８Ｃにおいて、請求金額を入力する。
顧客端末１には、割引された請求金額が図７Ｃのように表示されるので、暗証番号を入力して、送信手続きを行う。図７Ｄと図８Ｄは、仮決済終了後に顧客端末１と店舗端末２にそれぞれ、領収書が表示された例である。

収納代行銀行の取りまとめ口座には、多くの店舗への支払い金が多くの顧客口座から引落とされ、それらが区別されることなく一時保管されるが、それらの収納金をそれぞれの店舗へ分配して決済が終了する。

図１０は、ウォレットサーバ４の収納金分配部２０８の行う収納金の分配処理を説明するフローチャートである。

＜ステップ１００１＞ 店舗ＤＢ２３０の分配日４７をチェックし、本日が分配日である店舗ＩＤを抽出する。ステップ１００１において、抽出した各店舗ＩＤについて、ステップ１００２からステップ１００５の処理を繰返す。
＜ステップ１００２＞ 決済管理ＤＢ２４０から、店舗ＩＤ５３がステップ１０００１において抽出した店舗ＩＤであり、状態５７が「仮決済正常終了」であり、かつ、分配５８が「未」であるレコードを抽出する。

＜ステップ１００３＞ ステップ１００２で抽出したレコードの決済金額５５を合算する。抽出したレコードの数あるいは／および合算した決済金額から収納代行の手数料を計算しても良い。合算した決済金額から手数料を減算して、分配金としても良い。
＜ステップ１００４＞ 店舗ＤＢ２３０の該当店舗ＩＤのレコードから店舗の銀行口座情報を特定し、収納代行銀行の取りまとめ口座から、分配金を該当店舗ＩＤの口座に入金するための口振データを作成する。

図１１は、取りまとめ口座からの店舗の銀行口座への分配金の入金を行うための、リアルタイム口振ＧＷ７に送信される口座振替データの一例である。口座振替データは、データ種別（入金）１１０１、店舗の口座情報１１０２、分配金額１１０３、分配日時１１０４を含む。口座情報１１０２は、銀行コード、支店番号、口座科目、口座番号を含む。また、実施形態に応じて、オプション情報１１０５として、処理通番を入れても良い。リアルタイム口振ＧＷ７は、この口座振替データを受信すると、取りまとめ口座から店舗の口座へ分配金の入金をおこなう。

＜ステップ１００５＞リアルタイム口振ＧＷ７から分配終了の通知を受けると、ステップ１００２において抽出した各レコードの分配５８に、分配が済んだことを示す「済み」、あるいは、分配処理の通番を入れる。この手続きにより、顧客と店舗間の決済が完全に終了する。

追加の処理として、各店舗からの要求により、ステップ１００２において抽出したレコードから、分配金の明細を各店舗の望むフォーマットで作成して、各店舗に提供しても良い。
収納金分配部２０８は、分配終了から一定時間が経過した後に、該当レコードを決済管理ＤＢから該当レコードを削除してもよいし、トランザクション記録ＤＢ２５０に移動しても良い。

次のような変形例も可能である。
（１）店舗登録時に、店舗のＧＰＳ位置情報を店舗ＤＢ２３０の店舗情報４２に登録しておく。顧客端末１でユーザアプリを開くと、端末内のＧＰＳが顧客端末１のＧＰＳ位置情報を取得し、ユーザアプリ２００がＧＰＳ位置情報をウォレットサーバ４の決済アプリ２００へ送信する。決済アプリ２００が送信されてきたＧＰＳ位置情報と同じか近接した位置にある店舗の名称を店舗ＤＢから抽出して顧客端末１へ送信し、その画面に表示させる様にしても良い。

（２）顧客端末１のチェックイン操作に代えて、顧客端末１と店舗端末２の間でＢｌｕｅｔｏｏｔｈなどの近距離通信により互いのＩＤを交換し、それぞれのアプリから交換したＩＤと自ＩＤをウォレットサーバ４の決済アプリ２００へ送信することにより、決済アプリ２００が、両ＩＤ間の決済を開始するようにしても良い。

（３）本決済システムで決済を行う上で、顧客の個人名を店舗側に開示する必要は無い。顧客端末１のユーザアプリに個人名隠匿を指示するボタンを設けて、個人名を店舗側に開示しないようにする選択肢を設けても良い。この場合、決済アプリ２００は、チェックイン時にユーザに１回限りのテンポラリＩＤを発行し、決済アプリ２００において、店舗端末２との通信時に顧客ＩＤをテンポラリＩＤに置き換え、また、その逆の置き換えを行う。店舗側にはテンポラリＩＤのみを開示することにより、決済開始から終了までの処理をおこなう。この処理により、口座振替を利用しても、現金と同じように、顧客側の情報を店舗に知られたり蓄積されたりすることなく、決済ができる。決済管理ＤＢ２４０に、個人名隠匿フラグ、および、テンポラリＩＤのフィールドを設ける事により、実現できる。

（４）ウォレットサーバ４に別のコンピュータを接続し、別のコンピュータからも決済記録ＤＢ２４０にアクセスできるようにし、別のコンピュータにおいて上述の収納金分配処理を行っても良い。他の決済方法により集めた収納金のデータとウォレットサーバ４において集めた収納金のデータを、このコンピュータ上で合算して、各店舗へ収納金分配処理をおこなっても良い。

（５）ウォレットサーバ４は、決済アプリ２００の口座残高確認部２０２を使用して、顧客端末１でユーザアプリを開いた時点で、顧客の口座の残高を顧客端末１の画面に表示しても良い。
（６）収納金分配部２０８は、予め定められた分配日ではなく、各店舗からの入金要求に応じて、収納金の分配を行っても良い。この場合、各店舗は自店舗ＩＤを含む入金要求をウォレットサーバ４に送る。ウォレットサーバ４内の収納金分配部２０８が受信要求内の店舗ＩＤに対して、図１０のステップ１００２から１００５を実施することにより、入金要求による収納金分配を実現できる。

病院では、診療後の会計処理に時間がかかり、患者が会計をすませるために待たされることがある。
本実施例の本決済システムでは、患者が顧客端末１において、病院へのチェックインをおこなったあと帰宅してしまっても良い。後に、会計処理を終了してから病院の店舗端末２から患者に請求額を通知することにより、患者は病院を離れても顧客端末１から決済をおこなうことができる。

この場合、決済アプリ２００は患者（ユーザ）のチェックインが行われ、決済管理ＤＢ２４０の決済レコードが登録された時点でユーザアプリとお店アプリに決済ＩＤを通知して、すなわち図６のステップ６０２の処理を終えた時点で処理を中断する。決済管理ＤＢの状態５７を「中断」とする。病院端末２のお店アプリから、中断中の決済を検索して表示させることができる。病院で該当患者の会計処理が終了したら、病院端末２から、請求金額を患者ＩＤと決済ＩＤとともに決済アプリ２００に通知することにより、ステップ６０３以下の処理を再開し、決済処理を再開できる。

通信販売において、本決済システムでは、新しい支払い方法を提供できる。
通信販売での物品の購入申し込み時に、顧客が本決済システムでの決済を選択したとする。店舗は、購入された品物の梱包に２次元コードであるＱＲコード（登録商標）を付与する。ＱＲコードには、店舗ＩＤと購入記録番号が含まれる。

顧客が、そのユーザアプリを開いて、顧客端末１のカメラによりＱＲコードを読み込む事により、ＱＲコード内の店舗ＩＤにより識別される店舗へのチェックインが行われる。店舗アプリには、チェックインした顧客ＩＤとともに購入記録番号がウォレットサーバ４経由で送られる。その後、店舗アプリから顧客端末１に購入記録番号に対応する請求額を通知する。
顧客は、通信販売により届いた品物を確認してから、支払いを簡単に行うことができる。

図１の例では、収納代行銀行として、Ｘ銀行８のコンピュータシステムのみがリアルタイム口振ＧＷ７に接続されているが、他の収納代行銀行（Ｙ銀行やＺ銀行）のコンピュータシステムも接続されて良い。この場合、それぞれの銀行は個別に顧客や店舗と口座振替契約を結ぶことが必要である。リアルタイム口座振替のサービスが提供されているのは、いまのところ、同じ銀行の口座間においてのみである。したがって、顧客と店舗が同じ銀行と口座振替契約をしていることが、本システムで決済を行う上での条件である。

本システムに複数の収納代行銀行を収容するためには、図２のウォレットサーバ４において、顧客ＤＢ２２０，店舗ＤＢ２３０，決済管理ＤＢ２４０，トランザクション記録ＤＢ２５０をそれぞれ銀行毎に用意すれば良い。顧客ＩＤ、店舗ＩＤ、決済ＩＤについては、各銀行で一意な番号をあたえれば良い。ユーザアプリ、お店アプリを各銀行に応じて変え、決済アプリは、ユーザアプリ、お店アプリと接続した時点で、どの銀行の取りまとめ口座を使用して決済を行うか、どのＤＢを利用して処理を行うか認識できるようにする。

あるいは、ユーザアプリが、それぞれ口座振替契約済みの銀行を選択ボタンの形式で画面に表示させ、顧客にどの銀行を介して決済を行うかを選択させるようにしても良い。決済アプリには、ユーザアプリから選択された銀行が通知される。

ウォレットサーバ４が店舗リストを顧客端末１に表示させるときに、顧客が口座振替契約を結んだ銀行を介して決済可能な店舗のみを表示するようにしても良い。

実施例４では、システムが複数の収納代行銀行のコンピュータシステムに接続される例を紹介した。次に、複数の収納代行銀行が相互に関係するマルチバンク決済の実施例を紹介する。図１に示したリアルタイム口振ＧＷ７は、複数の銀行のコンピュータシステムに接続され、それぞれの銀行の口座（預金口座）と取りまとめ口座の間の口座振替（引き落としおよび分配）を取り扱うことができるものとする。

図１２を参照されたい。ユーザａとＡ店舗がそれぞれＸ銀行に口座を持ち、ユーザａはＸ銀行の提供するユーザアプリ（Ｘ）を使用し、Ａ店舗はＸ銀行の提供するお店アプリ（Ｘ）を使用し、Ｘ銀行の提供する決済アプリ（Ｘ）を介して、決済をおこなう。

同様に、ユーザｂとＢ店舗がそれぞれＹ銀行に口座を持ち、ユーザｂはＹ銀行の提供するユーザアプリ（Ｙ）を使用し、Ｂ店舗はＹ銀行の提供するお店アプリ（Ｙ）を使用し、Ｙ銀行の提供する決済アプリ（Ｙ）を介して、決済をおこなう。

更に進めて、本実施例では、図１２の点線で示すように、ユーザａがユーザアプリ（Ｘ）と決済アプリ（Ｘ）を使用して、お店アプリ（Ｙ）を使用するＢ店舗と決済を行うことができるようにする。同様に、ユーザｂがユーザアプリ（Ｙ）と決済アプリ（Ｙ）を使用して、お店アプリ（Ｘ）を使用するＡ店舗と決済を行うことができるようにする。

同様に、Ｚ銀行に口座を持つユーザｃやＣ店舗をシステムに収容し、ユーザａやＡ店舗または／およびユーザｂやＢ店舗と相互に決済できるようにする。

マルチバンク決済の概要を説明する。
ユーザａが、ユーザアプリ（Ｘ）と決済アプリ（Ｘ）を使用して、お店アプリ（Ｙ）を使用するＢ店舗と決済をする場合を考える。ユーザのＸ銀行の口座からＸ銀行の取りまとめ口座へ決済金額が移され、Ｙ銀行の取りまとめ口座からＢ店舗のＹ銀行の口座へ、ユーザａとの決済金額を含む収納金が分配される。

逆に、ユーザｂが、ユーザアプリ（Ｙ）と決済アプリ（Ｙ）を使用して、お店アプリ（Ｘ）を使用するＡ店舗と決済をする場合を考える。ユーザのＹ銀行の口座からＹ銀行の取りまとめ口座へ決済金額が移され、Ｘ銀行の取りまとめ口座からＡ店舗のＸ銀行の口座へ、ユーザｂとの決済金額を含む収納金が分配される。

すなわち、ユーザが、どの銀行と契約している店舗で商品やサービスを購入しようと、ユーザの銀行口座から同じ銀行の取りまとめ口座への引落が行われ、店舗の商品やサービスが、どの銀行に口座を持つユーザに購買されたかにかかわらず、店舗の銀行口座へ、同じ銀行の取りまとめ口座から分配金が支払われる。

のちに、幹事決済銀行が、定められた期間内に行われた異銀行間の決済を取りまとめ、幹事決済銀行とそれぞれの銀行間の精算（銀行間決済）を行う。各店舗への収納金の分配と銀行間決済は別々に非同期に行われる。

このような、マルチバンク決済を行うためのシステム構成を説明する。簡単のため、システムが収納代行銀行として、Ｘ銀行、Ｙ銀行、Ｚ銀行を収容している例を説明する。全体的な構成図は図１と同じであるが、ウォレットサーバ４’の構成が図１３の様になる。実施例１の図２と比較して、異なる構成要素にのみ新たな参照番号を付与し説明する。参照番号にダッシュ（’）がついている構成要素は、実施例１の対応する構成要素とは若干異なる。

上述したように、決済アプリは収納代行銀行毎に用意される。したがってウォレットサーバ４’には、決済アプリ（Ｘ）２００’―Ｘ、 決済アプリ（Ｙ）２００’−Ｙ、決済アプリ（Ｚ）２００’−Ｚが存在する。

顧客ＤＢ２２０’は、複数の決済アプリ２００’―Ｘ、２００’−Ｙ、２００’−Ｚにより共有される。顧客ＤＢ２２０’の詳細を図１４に示す。各ユーザが取引銀行と口座振替の契約手続きを行うことにより、顧客ＤＢ２２０’に登録される。図３に示した顧客ＤＢ２２０と比較して、各ユーザの情報を記憶するレコードに、ユーザの口座の銀行（たとえばＸ銀行）の銀行コード１４０１と、アクセス制限１４０２が加わる。アクセス制限１４０２は、各レコードのアクセスに制限を設けるための情報である。たとえば、銀行コード１４０１の銀行以外の銀行関係者およびアプリケーションソフトウェアからはアクセスできない（値２）、銀行コード１４０１の銀行以外のアプリケーションソフトウェアからは読み込みのみ可能（値１）などである。

店舗ＤＢ２３０’も、複数の決済アプリ２００’―Ｘ、２００’−Ｙ、２００’−Ｚにより共有される。店舗ＤＢ２３０’の詳細を図１５に示す。各店舗が取引銀行と口座振替の契約手続きを行うことにより、店舗ＤＢ２３０’に登録される。図４に示した店舗ＤＢ２３０と比較して、各店舗の情報を記憶するレコードに、店舗の口座の銀行（例えばＹ銀行）の銀行コード１５０１、アクセス制限１５０２、手数料コード１５０３が加わる。アクセス制限は、店舗のレコードのアクセスに制限を設けるための情報である。たとえば、銀行コード１５０１の銀行以外の銀行関係者およびアプリケーションソフトウェアからはアクセスできない（値２）、銀行コード１５０１の銀行以外のアプリケーションソフトウェアからは読み込みのみ可能（値１）などである。手数料コード１５０３は、店舗に課せられる手数料に関する情報であり、たとえば、「決済一件あたり１００円」は手数料コード１である。

決済アプリ（Ｘ）２００’−Ｘにおいて、実施例１の決済アプリ２００および各処理部と異なる部分について説明する。

図１３の店舗検索部２０３’は、店舗ＤＢ２３０’から条件に従って店舗の検索を行うが、まず店舗ＤＢ２３０’の各レコードの銀行コード１５０１をチェックする。銀行コードがＸ銀行である店舗のレコードについては、その店舗を検索対象とし、銀行コードがＸ銀行ではない店舗のレコードについては、アクセス制限１５０２をチェックし、決済アプリ（Ｘ）による読み取りを許されたレコードの店舗のみを検索対象とする。

決済アプリ（Ｘ）２００’−Ｘの通信処理部２０４’は、Ｘ銀行により供給されたお店アプリ（Ｘ）と通信するが、加えて、他の銀行により供給されたお店アプリ（Ｙ）やお店アプリ（Ｚ）とも通信し、必要な情報を送受信できる。通信処理部２０４’は、お店アプリ（Ｘ）と通信しているのか、それ以外のお店アプリと通信しているのか、お店アプリ名や識別子により識別できる。

同様に、お店アプリ（Ｘ）も決済アプリ（Ｘ）２００’−Ｘの通信処理部２０４’と通信するが、加えて、他の銀行により供給された決済アプリ（Ｙ）２００’−Ｙの通信処理部２０４’や決済アプリ（Ｚ）２００’−Ｚの通信処理部２０４’とも通信し、必要な情報を送受信できる。お店アプリ（Ｘ）は決済アプリ（Ｘ）と通信しているのか、それ以外の決済アプリと通信しているのか、決済アプリ名や識別子により識別できる。

したがって、お店アプリ（Ｘ）において、図８Ｂ、８Ｃ、８Ｄのような決済アプリを介した顧客と情報交換時に、顧客がユーザアプリ（Ｘ）を使用しているのか否かを、たとえば、画面の背景の色を変えるなどして、店舗の店員が識別できるようにしても良い。

図１３の通信処理部２０４’および仮決算処理部２０６’は、ユーザアプリおよびお店アプリとの通信が始まった時点で決算管理ＩＤ２４０’のレコードを作成するが、図１６に示すように、図５で示した決算管理ＩＤ２４０と比較して、ユーザの銀行（Ｘ）の銀行コード１６０１、店舗の銀行（Ｙ）の銀行コード１６０２、銀行間フラグ１６０３が追加される。銀行コード１６０１は、決済アプリの提供元の銀行コードと一致する。銀行間フラグ１６０３は、ユーザと店舗が同じ銀行を使用する場合に０、ユーザと店舗が異なる銀行を使用する場合に１とする。トランザクション記録ＤＢ２５０’も決済管理ＤＢ２４０’と同じデータ構造を持つ。決済管理ＤＢ２４０’の各レコードは、決済が終了した後も、銀行間決済の処理が終了するまで、一定期間保存される。

図１３の仮決済処理部２０６’は、ユーザのＸ銀行口座からＸ銀行の取りまとめ口座への口座振替データ（図９）を作成してリアルタイムＧＷ７へ送信する。口座振替データのユーザ口座情報９２は銀行コードを含んでいるため、実施例１と同じデータ構造で対応できる。

一方、収納金の分配は、店舗の利用する銀行により提供される決済アプリの収納金分配部によっておこなわれる。たとえば、Ｂ店舗への収納金の分配は決済アプリ（Ｙ）２００’−Ｙの収納金分配部２０８’によって行われる。図１０は実施例１の収納金分配処理を示しているが、本実施例でも、同様の処理を行う。実施例１と異なる部分について説明する。ステップ１００１において、店舗ＤＢ２３０’（図１５）から、Ｙ銀行の銀行コード１５０１をもち、本日が収納金分配日である店舗ＩＤの抽出を行う。それらの店舗ＩＤに対して、分配金の計算をおこなう。

ステップ１００２において、決算管理ＤＢ２４０’（図１６）から銀行コード１６０２がＹ銀行の銀行コードであり、店舗ＩＤ５３がステップ１００１で抽出した店舗ＩＤであるレコードを抽出する。

ステップ１００３において、ステップ１００２で抽出したレコードの決済金額を計算する。手数料については、決算管理ＤＢ２４０’の銀行間フラグ１６０３と店舗ＤＢ２３０’の手数料コード１５０３から「決済１件１００円」などと計算をおこない、決済金額から差し引いて分配金を決定する。手数料は、別のタイミングで、あるいは、一定の期間の決済の手数料を合算して、店舗の利用銀行から店舗へ請求されても良い。

ステップ１００４において、Ｙ銀行の取りまとめ口座からＢ店舗の銀行口座への口座振替をおこなう。すなわち、口座振替データ（図１１）を作成し、リアルタイムＧＷ７へ送信する。口座振替データ（図１１）は店舗口座情報１１０２に銀行コードを含んでいるため、実施例１と同じデータ構造で対応できる。

銀行間決済について説明する。
ウォレットサーバ４’は、銀行間決済処理部１３０１を有する。銀行間決済処理部１３０１も他の処理部と同様に、プロセッサがソフトウェアプログラムを実行することにより実現される。銀行間決済処理部１３０１は、例えば、１日１回決まった時間に起動される。

図１７は、銀行間決済処理部１３０１の処理を示すフローチャートである。ここでは、銀行コードが０００１であるＸ銀行が幹事決済銀行であるとする。銀行間決済処理部１３０１は、それぞれの銀行が決済に関する資金を「受け取り過ぎ」であるか「支払い過ぎ」であるかを判定し、幹事決済銀行であるＸ銀行のコンピュータシステムへ過不足の金額とともに通知する。

＜ステップ１７０１＞ 決済管理ＤＢ２４０’（図１６）の各レコードの仮決済日時５４と銀行間フラグ１６０３を参照して、決済管理ＤＢ２４０’から、前日に行われた異銀行間の決済レコードを抽出する。

＜ステップ１７０２＞ すべての銀行コードｉ毎に以下の処理を繰返す。幹事決済銀行であるＸ銀行の銀行コード０００１に対しても、同様の処理を行う。

＜ステップ１７０３＞ステップ１７０１で抽出したレコードのうち、支払い元の銀行コード１６０１がｉであるレコードの決済金額５５を合算してＴＯＴＡＬ１（ｉ）とする。

＜ステップ１７０４＞ステップ１７０１で抽出したレコードのうち、支払い先の銀行コード１６０２がｉであるレコードの決済金額５５を合算してＴＯＴＡＬ２（ｉ）とする。

＜ステップ１７０５＞ ＴＯＴＡＬ１（ｉ）−ＴＯＴＡＬ２（ｉ）＝ＳＵＢ（ｉ）を計算し、ステップ１７０３およびステップ１７０４において処理したレコードから作成した明細とともに、幹事決済銀行であるＸ銀行のコンピュータシステムに送付する。明細は、別のタイミングで送られても良い。また、すべての銀行に関するＳＵＢ（ｉ）および明細をまとめて、Ｘ銀行のコンピュータシステムに送付に送付しても良い。

幹事決済銀行であるＸ銀行のコンピュータシステムは、受信したＳＵＢ（ｉ）に従って、銀行コードがｉである銀行との間で、全銀ネットの雑為替による銀行間の付け替え処理により銀行間決済を行う。具体的には、Ｘ銀行のコンピュータシステムは、通知されたＳＵＢ（ｉ）がプラスである場合には、銀行コードがｉである銀行のコンピュータシステムにＳＵＢ（ｉ）の請求を行い、通知されたＳＵＢ（ｉ）がマイナスである場合には、銀行コードがｉである銀行のコンピュータシステムにＳＵＢ（ｉ）の絶対値の付け替え（振込み）を行う。この時に、銀行間決済処理部１３０１が、銀行間決済に係る手数料の計算を行い、ＳＵＢ（ｉ）とあわせて（あるいは相殺して）銀行コードがｉである銀行との間の銀行間決済のための計算を行っても良い。

手数料について、説明する。店舗に課せられる手数料は、予め契約により合意されており（例えば１決済１００円）、店舗ＤＢ２３０’の手数料コード１５０３に記録されている。ユーザの利用銀行と店舗の利用銀行が同じである場合、店舗から徴収する手数料（契約手数料）は、この利用銀行が１００％受け取る。ユーザの利用銀行と店舗の利用銀行が異なる場合、店舗から徴収する手数料は、関係する２つの銀行によって分けされる。例えば図１２において、ユーザａが店舗Ｂにおいて、買い物をした場合には、Ｂ店舗から徴収される手数料１００円は、Ｘ銀行とＹ銀行で分けられ、その比率は契約によって決められる。たとえば、Ｘ銀行は３０円、Ｙ銀行は７０円である。したがって、Ｙ銀行は、店舗Ｂから徴収する手数料のうち、３０円をＸ銀行に支払わなければならない。各決済に関係する手数料の銀行の受け取り分は、契約手数料に銀行の取り分（％）を積算した値になる。別の例では、Ｙ銀行からＸ銀行に支払われる手数料は定額であっても良い。

手数料計算処理を加えた銀行間決済処理部１３０１の一例を示す。
銀行間決済処理部１３０１は、ステップ１７０３において、さらに、支払い元銀行コードがｉであるレコードについて、銀行コードｉの銀行が受け取るべき手数料Ｃ１（ｉ）を上述の方法で計算する。同様に、ステップ１７０４において、さらに、支払い先銀行コードがｉであるレコードについて、銀行コードｉの銀行が支払うべき手数料Ｃ２（ｉ）を上述の方法で計算する。

ステップ１７０５において、上述のＳＵＢ（ｉ）に代えて、ＳＵＢ（ｉ）−Ｃ１（ｉ）＋Ｃ２（ｉ）を、幹事決済銀行のコンピュータシステムに通知しても良い。

次のような変形例も可能である。
（１）ウォレットサーバ４’が複数のコンピュータや複数のプロセッサにより構成され、複数の決済アプリ２００’が別々のコンピュータやプロセッサにより、分散処理されても良い。
（２）ウォレットサーバ４’内のデータベースＤＢ２２０’、２３０’、２４０’、２５０’は、銀行毎に別々にもつように設定しても良い。
（３）ユーザの銀行と店舗の銀行が異なる場合には、割引処理の適用、店舗への顧客情報の開示に制限を設けても良い。
（４）ウォレットサーバ４’に別のコンピュータを接続し、別のコンピュータからも決済記録ＤＢ２４０’にアクセスできるようにし、別のコンピュータにおいて上述の銀行間決済処理を行っても良い。
（５）各店舗に課せられる手数料、異銀行間決済において各銀行に課せられる手数料は、店舗毎、銀行毎に異なっても良い。

ユーザも店舗も既存のハードウェアやネットワークを利用して、日常の買い物やサービスに対する支払いに本決済システムを使用することができる。

上記記載は実施例についてなされたが、本発明はそれに限らず、本発明の精神と添付の請求の範囲の範囲内で種々の変更および修正をすることができることは当業者に明らかである。

１・・・顧客端末
２・・・店舗端末
３・・・インターネット
４・・・ウォレットサーバ
５・・・専用回線
６・・・専用ネットワーク
７・・・リアルタイム口振ＧＷ
８・・・銀行コンピュータシステム
２００・・・決済アプリ
２０１・・・認証部
２０２・・・口座残高確認部
２０３・・・店舗検索部
２０４・・・通信処理部
２０５・・・割引処理部
２０６・・・仮決済処理部
２０７・・・レシート発行処理部
２０８・・・収納金分配部
２２０・・・顧客ＤＢ
２３０・・・店舗ＤＢ
２４０・・・決済管理ＤＢ
２５０・・・トランザクション記録ＤＢ
１３０１・・・銀行間決済処理部

Claims (13)

1. 決済システムであって、
   銀行口座と取りまとめ銀行口座の間のリアルタイム決済をおこなう、リアルタイム口座振替システムと、
   顧客端末および店舗端末と接続された、および、前記リアルタイム口座振替システムと接続された、ウォレットサーバを含み、
   前記ウォレットサーバは、
   あらかじめ顧客の銀行口座情報が登録された顧客データベースと
   あらかじめ店舗の店舗情報と銀行口座情報が登録された店舗データベースを含み、
   前記ウォレットサーバは、
   顧客端末を利用する顧客を識別し、
   前記顧客の端末上の操作により、支払い先店舗を識別し、
   支払い先店舗端末からの請求額を受信して、決済金額を決定し、
   前記顧客データベースから、顧客の銀行口座情報を取得し、
   前記顧客の銀行口座から前記決済金額を引落して前記取りまとめ銀行口座へ入金するための口座振替データを作成し、前記リアルタイム口座振替システムへ送信するとともに、支払い先店舗の識別子と決済金額を決済データベースに記憶し、
   あらかじめ決められたタイミングで、前記決済データベースから同じ支払い先店舗の識別子を含むレコードを抽出し、そこに記録された決済金額を合算し、
   前記店舗データベースから、前記支払い先店舗の銀行口座情報を取得し、
   取りまとめ銀行口座から前記支払い先店舗の銀行口座へ、前記合算した決済金額を入金するための口座振替データを作成し、前記リアルタイム口座振替システムへ送信する、
   ことを特徴とする、決済システム。
2. 請求項１に記載の決済システムであって、
   前記ウォレットサーバと前記顧客端末および前記店舗端末とは、インターネットを介して接続され、
   前記ウォレットサーバと前記リアルタイム口座振替システムは、専用線で接続される、決済システム。
3. 請求項１に記載の決済システムであって、
   前記ウォレットサーバは、更に、
   前記リアルタイム口座振替システムへ、前記顧客の銀行口座から前記決済金額を引落すための口座振替データを送信した後、前記リアルタイム口座振替システムから口座振替結果を受信し、
   口座振替が、正常に行われた場合には、前記店舗情報と前記請求額を含む、レシートを作成し、前記顧客端末に送信する、
   決済システム。
4. ウォレットサーバであって、
   銀行口座と取りまとめ銀行口座の間のリアルタイム決済をおこなうリアルタイム口座振替システムと接続され、および、顧客端末および店舗端末と接続され、
   あらかじめ顧客の銀行口座情報が登録された顧客データベースと
   あらかじめ店舗の店舗情報と銀行口座情報が登録された店舗データベースを含み、
   顧客端末を利用する顧客を識別し、
   前記顧客の端末上の操作により、支払い先店舗を識別し、
   支払い先店舗端末からの請求額を受信して、決済金額を決定し、
   前記顧客データベースから、顧客の銀行口座情報を取得し、
   前記顧客の銀行口座から前記決済金額を引落して前記取りまとめ銀行口座へ入金するための口座振替データを作成し、前記リアルタイム口座振替システムへ送信するとともに、支払い先店舗の識別子と決済金額を決済データベースに記憶し、
   あらかじめ決められたタイミングで、前記決済データベースから同じ支払い先店舗の識別子を含むレコードを抽出し、そこに記録された決済金額を合算し、
   前記店舗データベースから、前記支払い先店舗の銀行口座情報を取得し、
   取りまとめ銀行口座から前記支払い先店舗の銀行口座へ、前記合算した決済金額を入金するための口座振替データを作成し、前記リアルタイム口座振替システムへ送信する、
   ことを特徴とする、ウォレットサーバ。
5. 請求項４に記載のウォレットサーバであって、
   前記リアルタイム口座振替システムとは専用線で接続され、前記顧客端末および前記店舗端末とはインターネットを介して接続される、ウォレットサーバ。
6. 請求項４に記載のウォレットサーバであって、
   更に、前記リアルタイム口座振替システムへ、前記顧客の銀行口座から前記決済金額を引落すための口座振替データを送信した後、前記リアルタイム口座振替システムから口座振替結果を受信し、
   口座振替が、正常に行われた場合には、前記店舗情報と前記請求額を含む、レシートを作成し、前記顧客端末に送信する、
   ウォレットサーバ。
7. 請求項６に記載のウォレットサーバであって、
   更に、前記決済データベースに前記リアルタイム口座振替システムからの引落結果を保存する、
   ウォレットサーバ。
8. 請求項４に記載のウォレットサーバであって、
   前記顧客端末から特典利用の申請を受けると、
   あらかじめ決められた計算式にしたがって、前記請求額から前記特典に応じた割引額を計算し、
   前記請求額から割り引いた金額を、前記口座振替データに使用する決済金額とする、
   ウォレットサーバ。
9. 決済システムであって、
   複数の銀行のコンピュータシステムに接続され、同じ銀行の口座と取りまとめ口座の間のリアルタイム決済をおこなう、リアルタイム口座振替システムと、
   顧客端末および店舗端末と接続された、および、前記リアルタイム口座振替システムと接続された、ウォレットサーバを含み、
   前記ウォレットサーバは、
   あらかじめ顧客の銀行口座情報が登録された顧客データベースと、
   あらかじめ店舗の店舗情報と銀行口座情報が登録された店舗データベースと、
   顧客と店舗の間で行われる決済を記録および管理する決済管理データベースを含み、
   前記ウォレットサーバは、
   顧客端末を利用する顧客を識別し、
   前記顧客の端末上の操作により、支払い先店舗を識別し、
   支払い先店舗端末からの請求額を受信して、決済金額を決定し、
   前記顧客データベースから、前記識別した顧客の銀行口座情報を取得し、
   前記店舗データベースから、前記識別した店舗の銀行口座情報を取得し、
   前記顧客の銀行口座情報、前記店舗の銀行口座情報、前記決済金額を含む決済情報を前記決済管理データベースに記録し、
   前記識別した顧客の銀行口座から前記決済金額を引落し、前記識別した顧客の銀行口座と同じ銀行の取りまとめ銀行口座へ入金するための口座振替データを作成し、前記リアルタイム口座振替システムへ送信し、
   あらかじめ決められた第１のタイミングで、前記決済管理データベースから同じ店舗への支払い決済であるレコードを抽出し、そこに記録された決済金額を合算して前記店舗への分配金を決定し、前記店舗の銀行口座へ、前記店舗の銀行口座と同じ銀行の取りまとめ銀行口座から、前記決定した分配金を入金するための口座振替データを作成し、前記リアルタイム口座振替システムへ送信し、
   あらかじめ決められた第２のタイミングで、前記決済管理データベースから、顧客の銀行口座の属する銀行と店舗の銀行口座の属する銀行が異なる決済レコードを抜き出し、各銀行について、顧客の銀行口座の属する銀行が前記銀行であるレコードに記録された決済金額を合算し、また、店舗の銀行口座の属する銀行が前記銀行であるレコードに記録された決済金額を合算し、双方の合算結果の差をとって、幹事決済銀行のコンピュータシステムへ送信する、
   ことを特徴とする、決済システム。
10. 請求項９に記載の決済システムであって、
    前記ウォレットサーバから合算結果の差を受信した前記幹事決済銀行のコンピュータシステムは、前記合算結果の差にしたがって、各銀行のコンピュータシステムとの間で、銀行間決算を行う、
    決算システム。
11. 請求項９に記載の決済システムであって、
    前記ウォレットサーバと前記顧客端末および前記店舗端末とは、インターネットを介して接続され、
    前記ウォレットサーバと前記リアルタイム口座振替システムは、専用線で接続される、決済システム。
12. 請求項９に記載の決済システムであって、
    各決済において、顧客の銀行口座の属する銀行と店舗の銀行口座の属する銀行が異なる場合、前記ウォレットサーバが、店舗から徴収する手数料を、双方の銀行で分けるように計算する、決済システム。
13. 請求項１２に記載の決済システムであって、
    前記ウォレットサーバが、前記合算結果の差と分けるべき手数料にもとづいて、銀行間決算の金額を幹事決済銀行のコンピュータシステムへ送信する、決済システム。