JP2023006668A - 金融機関システム、支払方法、及びプログラム - Google Patents

Abstract

【課題】払込票又は払込用番号を利用した支払サービスと連携する電子決済サービスの事業者の手間を軽減する。【解決手段】支払システム（１）の支払処理実行手段（２０２）は、ユーザ端末（５０）により読み取られた払込票、又は、ユーザ端末（５０）に入力された払込用番号に基づいて、ユーザ端末（５０）から利用可能な電子決済サービスを利用した支払処理を実行する。入金処理実行手段（２０３）は、支払処理が実行された場合に、電子決済サービスを提供する事業者から、払込票又は払込用番号を利用した支払サービスを提供する金融機関への入金処理を実行する。精算処理実行手段（２０５）は、入金処理が実行された場合に、金融機関から精算先への精算処理を実行する。【選択図】図５

Description

本開示は、支払システム、支払方法、及びプログラムに関する。

従来、払込票又は払込用番号を利用して、公共料金などの支払をする支払サービスが知られている。特許文献１には、払込票受領書に基づいて取得された入金確定予定データと、払込票に基づいて取得された入金明細データと、を対応付けてマッチングすることによって、マッチング作業の時間短縮及び業務負担の軽減を実現する技術が記載されている。特許文献２には、ユーザ端末で払込票を読み取って本人認証を行った後に、ユーザの口座から支払先の口座への振込処理を実行する技術が記載されている。

特許第６０２７８９９号公報 特開２００５－２２８１５６号公報

しかしながら、特許文献１の技術では、ユーザは、金融機関の窓口を訪れて払込票の支払をする必要があるので、ユーザの手間がかかる。特許文献２の技術では、ユーザ端末からの払込票の支払が可能だが、銀行振込しか利用できないので、ユーザの利便性を十分に高めることができない。例えば、ユーザが普段から利用している電子決済サービスで払込票の支払が可能になれば、ユーザの利便性が高まるが、電子決済サービスの事業者は、払込票の支払に関する機能を独自に開発する必要があるので、事業者の手間がかかる。

本開示の目的の１つは、払込票又は払込用番号を利用した支払サービスと連携する電子決済サービスの事業者の手間を軽減することである。

本開示に係る支払システムは、ユーザ端末により読み取られた払込票、又は、ユーザ端末に入力された払込用番号に基づいて、前記ユーザ端末から利用可能な電子決済サービスを利用した支払処理を実行する支払処理実行手段と、前記支払処理が実行された場合に、前記電子決済サービスを提供する事業者から、前記払込票又は前記払込用番号を利用した支払サービスを提供する金融機関への入金処理を実行する入金処理実行手段と、前記入金処理が実行された場合に、前記金融機関から精算先への精算処理を実行する精算処理実行手段と、を含む。

支払システムの全体構成の一例を示す図である。 電子決済アプリから表示される画面の一例を示す図である。 支払アプリから支払サービスを利用する場合の流れを示す図である。 支払サービスにおける資金の流れの一例を示す図である。 支払システムにおいて実現される機能の一例を示す機能ブロック図である。 ユーザデータベースのデータ格納例を示す図である。 加盟店データベースのデータ格納例を示す図である。 支払システムにおいて実行される処理の一例を示すフロー図である。 支払システムにおいて実行される処理の一例を示すフロー図である。 変形例における機能ブロックの一例を示す図である。 変形例１における資金の流れの一例を示す図である。

［１．支払システムの全体構成］
以下、本開示に係る実施形態の例について図面に基づき詳細に説明する。図１は、支払システムの全体構成の一例を示す図である。図１に示すように、例えば、支払システム１は、事業者サーバ１０、銀行サーバ２０、収納代行会社サーバ３０、加盟店サーバ４０、及びユーザ端末５０を含み、これらは、インターネットなどのネットワークＮに接続可能である。なお、支払システム１は、少なくとも１つのコンピュータを含めばよく、図１の例に限られない。

事業者サーバ１０は、電子決済サービスを提供する事業者のサーバコンピュータである。電子決済サービスは、コンピュータを利用した電子的な決済である。この決済は、キャッシュレス決済と呼ばれることもある。電子決済サービスで利用可能な決済手段は、任意の種類であってよい。例えば、クレジットカード、デビットカード、電子マネー、電子キャッシュ、ポイント、銀行口座、ウォレット、又は仮想通貨を利用した決済である。バーコード又は二次元コード等のコードを利用した決済もコード決済と呼ぶことがあるので、これらのコードも決済手段の１つである。

事業者サーバ１０は、制御部１１、記憶部１２、及び通信部１３を含む。制御部１１は、例えば、少なくとも１つのプロセッサを含む。記憶部１２は、ＲＡＭ等の揮発性メモリと、ハードディスク等の不揮発性メモリと、の少なくとも一方を含む。通信部１３は、有線通信用の通信インタフェースと、無線通信用の通信インタフェースと、の少なくとも一方を含む。

銀行サーバ２０は、後述の支払サービスを提供する銀行のサーバコンピュータである。銀行は、金融機関の一例である。このため、本実施形態で銀行と記載した箇所は、金融機関と読み替えることができる。金融機関自体は、信用金庫や労働金庫といった任意の機関であってよく、銀行に限られない。例えば、銀行サーバ２０は、制御部２１、記憶部２２、及び通信部２３を含む。制御部２１、記憶部２２、及び通信部２３のハードウェア構成は、それぞれ制御部１１、記憶部１２、及び通信部１３と同様であってよい。

収納代行会社サーバ３０は、支払サービスにおける収納代行会社のサーバコンピュータである。例えば、収納代行会社サーバ３０は、制御部３１、記憶部３２、及び通信部３３を含む。制御部３１、記憶部３２、及び通信部３３のハードウェア構成は、それぞれ制御部１１、記憶部１２、及び通信部１３と同様であってよい。

加盟店サーバ４０は、支払サービスにおける加盟店のサーバコンピュータである。例えば、加盟店サーバ４０は、制御部４１、記憶部４２、及び通信部４３を含む。制御部４１、記憶部４２、及び通信部４３のハードウェア構成は、それぞれ制御部１１、記憶部１２、及び通信部１３と同様であってよい。

ユーザ端末５０は、ユーザのコンピュータである。本実施形態では、ユーザは、電子決済サービス及び支払サービスの両方を利用する。例えば、ユーザ端末５０は、スマートフォン、タブレット端末、ウェアラブル端末、又はパーソナルコンピュータである。例えば、ユーザ端末５０は、制御部５１、記憶部５２、通信部５３、操作部５４、表示部５５、及び撮影部５６を含む。制御部５１、記憶部５２、及び通信部５３のハードウェア構成は、それぞれ制御部１１、記憶部１２、及び通信部１３と同様であってよい。操作部５４は、タッチパネル等の入力デバイスである。表示部５５は、液晶ディスプレイ又は有機ＥＬディスプレイである。撮影部５６は、少なくとも１つのカメラを含む。

なお、記憶部１２，２２，３２，４２，５２に記憶されるプログラム及びデータの少なくとも一方は、ネットワークＮを介して供給されてもよい。また、事業者サーバ１０、銀行サーバ２０、収納代行会社サーバ３０、加盟店サーバ４０、及びユーザ端末５０の各々には、コンピュータ読み取り可能な情報記憶媒体を読み取る読取部（例えば、光ディスクドライブやメモリカードスロット）と、外部機器とデータの入出力をするための入出力部（例えば、ＵＳＢポート）と、の少なくとも一方が含まれてもよい。例えば、情報記憶媒体に記憶されたプログラム及びデータの少なくとも一方が、読取部及び入出力部の少なくとも一方を介して供給されてもよい。

［２．支払システムの概要］
本実施形態では、ユーザが電子決済サービスを利用して払込票の支払を行う場面を例に挙げて、支払システム１の処理を説明する。払込票は、コンビニエンスストアなどの店舗で支払をするための用紙である。払込票は、請求書又は納付書と呼ばれることもある。払込票は、任意の形式であってよく、例えば、加盟店の名前、加盟店の口座の情報、支払金額、支払期限、及びバーコードが印刷されている。

払込票は、任意の支払で利用可能であり、例えば、税金、公共料金、又はインターネットで購入した商品の支払で利用されてよい。加盟店は、ユーザの支払を最終的に受け取る者であり、例えば、自治体や商品を販売した店舗である。払込票には、加盟店ではなく、収納代行会社が記載されていてもよい。

例えば、払込票は、ユーザに郵送で送付される。払込票は、電子的なファイルとしてユーザに送付され、ユーザによって印刷されてもよい。他にも例えば、ユーザがコンビニエンスストアの端末などで払込用番号を入力することによって印刷される用紙が払込票に相当してもよい。なお、払込票は、用紙に印刷されていなくてもよく、画面に電子的に表示されてもよい。

バーコードには、支払に必要な情報が含まれており、例えば、個々の支払を一意に識別する支払ＩＤ、加盟店を一意に識別する加盟店ＩＤ、支払金額、及び支払期限といった情報が含まれている。本実施形態では、払込票に記載のコードの一例としてバーコードを説明するが、払込票に記載のコードは、バーコードに限られない。払込票に記載のコードは、二次元コードなどの他の任意のコードを利用可能である。このため、本実施形態でバーコードと記載した箇所は、他の任意のコードに読み替えることができる。

ユーザは、払込票のバーコードをユーザ端末５０で読み取ることによって、コンビニエンスストアなどに行かなくても、払込票の支払をすることができる。以降、ユーザ端末５０から払込票の支払が可能になるサービスを支払サービスと記載する。

本実施形態では、銀行は、口座を開設したユーザを対象にした支払サービスを提供している。例えば、銀行に口座を開設したユーザは、銀行が提供する金融サービスを利用するためのアプリケーション（以降、銀行アプリ）をユーザ端末５０にインストールする。ユーザは、銀行アプリを利用して、自身の口座の残高を利用して払込票の支払を行う。銀行の口座を利用した支払サービス自体は、公知の方法を利用可能である。

ユーザは、ユーザ端末５０にインストールされた電子決済アプリを利用して、払込票の支払をすることもできる。電子決済アプリは、電子決済サービスを利用するためのアプリケーションである。本実施形態では、クレジットカードでチャージした電子マネーを利用するタイプの電子決済サービスを例に挙げるが、電子決済サービスで利用可能な決済手段自体は、先述した種々のタイプを利用可能である。

電子決済アプリから利用可能な払込サービスは、銀行アプリから利用可能な払込サービスの機能の一部又は全部を利用している。例えば、銀行アプリから利用可能な払込サービスにおいて、銀行サーバ２０のＡＰＩを利用して払込票の支払のための処理が実行される。電子決済アプリから利用可能な払込サービスも、このＡＰＩの全部又は一部が利用される。このため、本実施形態では、銀行アプリから利用可能な払込サービスの既存の仕組みを流用して、電子決済アプリから利用可能な払込サービスの仕組みが実現される。

なお、ユーザは、電子決済サービスの利用登録を済ませているものとする。更に、ユーザは、電子決済サービスにクレジットカードを登録済みであり、ある程度の額の電子マネーをチャージ済みであるものとする。例えば、ユーザがユーザ端末５０を操作して電子決済アプリを起動させると、電子決済アプリのトップ画面が表示部５５に表示される。

図２は、電子決済アプリから表示される画面の一例を示す図である。図２に示すように、トップ画面Ｇ１には、電子マネーの残高が表示される。ユーザがアイコンＩ１０を選択すると、事前に登録したクレジットカードを利用して電子マネーをチャージできる。ユーザがアイコンＩ１１を選択すると、クレジットカードの登録等の設定を行うことができる。ユーザがアイコンＩ１２を選択すると、電子マネーを利用するためのコードが表示部５５に表示される。コードが店舗のＰＯＳ端末等で読み取られると、電子マネーを利用した決済処理が実行される。

なお、決済処理自体は、表示部５５に表示されたコードを利用する方法に限られず、任意の方法であってよい。例えば、決済処理は、店舗等に掲示されたコードを読み取る方法であってもよいし、ユーザ端末５０の操作だけで完結する方法であってもよい。他にも例えば、ＩＣチップが搭載されたユーザ端末５０であれば、ＩＣチップを利用して決済処理が実行されてもよい。

本実施形態では、電子決済アプリは、スーパーアプリに相当する。電子決済アプリは、任意のミニアプリを提供可能であり、例えば、オンラインショッピングアプリ、配車アプリ、デリバリーアプリ、チケット予約アプリ、又は電子書籍アプリといったミニアプリを提供する。スーパーアプリ及びミニアプリ自体は、公知の種々のタイプのアプリを利用可能である。トップ画面Ｇ１には、ユーザが利用中のミニアプリのアイコンＩ１３が表示される。

本実施形態では、ユーザがミニアプリを追加すると、このミニアプリがユーザ端末５０にインストールされるものとするが、ミニアプリは、ブラウザを利用したいわゆるウェブビューとして提供されてもよい。ミニアプリは、スーパーアプリである電子決済アプリと連携可能である。例えば、ミニアプリ内で何らかの支払が発生する場合、スーパーアプリの決済手段を利用した決済処理を実行できる。

ユーザがトップ画面Ｇ１のアイコンＩ１４を選択すると、電子決済アプリから追加可能なミニアプリの一覧を示す一覧画面Ｇ２が表示部５５に表示される。本実施形態では、一覧画面Ｇ２に示すように、払込票を利用した支払サービスを提供可能なミニアプリが用意されている。支払サービスは、銀行が運営するサービスである。以降、このミニアプリを、支払アプリと記載する。支払アプリは、銀行が作成してユーザに提供される。

ユーザが一覧画面Ｇ２のアイコンＩ２０を選択すると、支払アプリの追加を確認するための確認画面Ｇ３が表示部５５に表示される。確認画面Ｇ３には、支払サービスが銀行により運営されるサービスであることを示すメッセージＭ３０と、支払サービスの利用規約を表示させるためのボタンＢ３１と、が表示される。ユーザは、ボタンＢ３１を選択して利用規約を確認したうえで、チェックボックスＣ３２を選択する。

ユーザが確認画面Ｇ３のボタンＢ３３を選択すると、電子決済アプリに支払アプリが追加される。支払サービスは、銀行が運営するサービスなので、支払アプリが追加されると、支払サービスに必要な情報が事業者サーバ１０から銀行サーバ２０に提供される。図２では省略しているが、情報の提供についての同意を促すメッセージが表示されるようにしてもよい。支払アプリが追加されると、トップ画面Ｇ１に支払アプリを示すアイコンＩ１５が表示される。以降、ユーザは、支払アプリから支払サービスを利用できるようになる。例えば、ユーザがアイコンＩ１５を選択すると、支払アプリのトップ画面が表示部５５に表示される。

図３は、支払アプリから支払サービスを利用する場合の流れを示す図である。図３に示すように、支払アプリのトップ画面Ｇ４には、支払サービスが銀行により運営されるサービスであることを示すメッセージＭ４０が表示される。ユーザがボタンＢ４１を選択すると、支払サービスで利用可能な加盟店の一覧を表示部５５に表示させることができる。払込票を発行した全ての加盟店が支払サービスに対応してもよいが、本実施形態では、一部の加盟店だけが支払サービスに対応しているものとする。

ユーザがボタンＢ４２を選択すると、撮影部５６が起動し、撮影画面Ｇ５が表示部５５に表示される。撮影部５６は、所定のフレームレートで連続的に撮影処理を行う。撮影画面Ｇ５には、撮影部５６により撮影された画像が表示される。ユーザ端末５０は、公知の検出アルゴリズムに基づいて、撮影画像からバーコードを検出する。ユーザ端末５０は、バーコードを検出すると、バーコードに含まれるバーコード情報を抽出して銀行サーバ２０に送信する。バーコード情報は、事業者サーバ１０を経由してログを取らせるようにしてもよいが、本実施形態では、ユーザ端末５０から銀行サーバ２０に直接的に送信されるものとする。

銀行サーバ２０は、受信したバーコード情報に基づいて加盟店を特定し、支払サービスを利用可能な加盟店であるか否かを判定する。支払サービスを利用可能な加盟店ではないと判定された場合には、ミニアプリから払込票の支払をすることはできないので、その旨を示すエラーメッセージが表示部５５に表示される。一方、支払サービスを利用可能な加盟店であると判定された場合には、支払を確認するための確認画面Ｇ６が表示部５５に表示される。

例えば、確認画面Ｇ６には、加盟店、支払金額、及び支払元といった情報が表示される。これらの情報は、銀行サーバ２０に予め登録されていてもよいし、銀行サーバ２０が収納代行会社サーバ３０、加盟店サーバ４０、又は他のサーバに問い合わせることによって取得されてもよい。支払元は、払込票の支払で利用する決済手段に関する情報である。例えば、電子決済アプリから利用可能な電子マネーの名前、電子マネーの名義人、電子マネーの残高、及び支払後の電子マネーの残高が支払元として表示される。

ユーザが初めて支払アプリを利用する場合には、利用規約を表示させるためのボタンＢ６０が表示されてもよい。ユーザは、ボタンＢ６０を選択して利用規約を確認したうえで、チェックボックスＣ６１を選択する。２回目以降の利用時には、ボタンＢ６０及びチェックボックスＣ６１は表示されないようにしてもよい。ユーザがチェックボックスＣ６１にチェックを入れた状態でボタンＢ６２を選択すると、ユーザの電子マネーの残高を利用した払込票の支払が実行され、支払が完了したことを示す完了画面Ｇ７が表示部５５に表示される。

図４は、支払サービスにおける資金の流れの一例を示す図である。図４に示すように、ユーザは、事業者に、電子マネーを利用して支払を行う。事業者は、任意のタイミングで、銀行に開設された第１口座に、ある程度の金額（例えば、数万円～数百万円程度）を一度にまとめて入金する。第１口座は、事業者用の法人口座である。第１口座は、支払サービス以外の他の目的で利用されてもよいが、本実施形態では、原則として支払サービスのためだけに利用されるものとする。

銀行には、第１口座の他に、収納代行会社への精算用の第２口座が開設されている。銀行は、所定の送金サイクルで、第１口座から第２口座への送金を行う。銀行は、所定の精算サイクルで、第２口座に基づいて、収納代行会社への精算を行う。この精算自体は、振込等の任意の方法を利用可能である。収納代行会社は、銀行からの精算に基づいて、加盟店への精算を行う。この精算も、振込等の任意の方法を利用可能である。銀行から収納代行会社への精算と、収納代行会社から加盟店への精算と、の各々は、公知の方法を利用可能である。本実施形態では、図４のような流れにより、ユーザから加盟店に資金が移動する。

例えば、銀行アプリが提供する既存の支払サービスも、ユーザの個人の口座から、第２口座に相当する口座への送金が行われた後に、収納代行会社への精算が行われる。このため、支払アプリが提供する支払サービスにおける資金の流れについても、既存の支払サービスを流用できる。銀行アプリが提供する既存の支払サービスと、支払アプリが提供する支払サービスと、で第２口座を共通化してもよい。

なお、払込、支払、入金、送金、及び精算といった用語は、どの用語も概ね資金の移動を意味するが、本実施形態では、払込は、「払込票」又は「払込用番号」を特定する場合にのみ使用し、原則として資金の移動では使用しないものとする。支払、入金、送金、及び精算の各々の用語は、下記の意味で使用する。
支払：ユーザから事業者への資金の移動
入金：事業者から銀行への資金の移動
送金：銀行内の資金の移動
精算：銀行から収納代行会社への資金の移動、又は、収納代行会社から加盟店への資金の移動

以上のように、支払システム１は、銀行が提供している支払サービスの機能を流用し、電子決済サービスを利用した払込票の支払を実現する。これにより、電子決済サービスの事業者は、支払サービスを実現するにあたり、払込票の支払に関する機能を独自に開発する必要がなくなり、事業者の手間を軽減するようにしている。以降、支払システム１の構成の詳細について説明する。

［３．支払システムにおいて実現される機能］
図５は、支払システム１において実現される機能の一例を示す機能ブロック図である。本実施形態では、事業者サーバ１０、銀行サーバ２０、収納代行会社サーバ３０、加盟店サーバ４０、及びユーザ端末５０の各々で実現される機能を説明する。

［３－１．事業者サーバにおいて実現される機能］
図５に示すように、事業者サーバ１０では、データ記憶部１００、認証処理実行部１０１、及び決済処理実行部１０２が実現される。データ記憶部１００は、記憶部１２を主として実現される。他の各機能は、制御部１１を主として実現される。

［データ記憶部］
データ記憶部１００は、電子決済サービスを提供するために必要なデータを記憶する。データ記憶部１００は、支払サービスの一部の機能を提供するために必要なデータも記憶する。例えば、データ記憶部１００は、ユーザデータベースＤＢ１を記憶する。

図６は、ユーザデータベースＤＢ１のデータ格納例を示す図である。図６に示すように、ユーザデータベースＤＢ１は、電子決済サービスのユーザに関する情報が格納されたデータベースである。例えば、ユーザデータベースＤＢ１には、ユーザＩＤ、パスワード、氏名、ミニアプリ情報、電子マネー情報、及びクレジットカード情報が格納される。ユーザが電子決済サービスの利用登録を行うと、ユーザデータベースＤＢ１に新たなレコードが作成され、このユーザのユーザＩＤ等の情報が格納される。

ユーザＩＤは、電子決済サービスにおいてユーザを識別可能なユーザ識別情報である。ユーザ識別情報は、ユーザアカウントといったように、ユーザＩＤ以外の名前で呼ばれる情報であってもよい。メールアドレス又は電話番号といった他の情報がユーザ識別情報として利用されてもよい。ユーザＩＤには、氏名以外の任意の個人情報が関連付けられていてもよい。例えば、ユーザのメールアドレス、電話番号、住所、生年月日、又は性別といった情報がユーザＩＤに関連付けられていてもよい。これらの情報の全部又は一部は、ユーザが選択したミニアプリの提供者と共有されてもよい。

ミニアプリ情報は、電子決済アプリから利用可能な複数のミニアプリのうち、ユーザにより選択された少なくとも１つのミニアプリに関する情報である。例えば、ミニアプリ情報は、ユーザが利用中のミニアプリを識別可能なアプリＩＤを含む。ミニアプリ情報は、ミニアプリの利用状況を含んでもよいが、本実施形態では、個々のミニアプリの利用状況は、ミニアプリの提供者が管理するものとする。例えば、支払アプリの提供者は銀行なので、支払アプリの利用状況（支払済みの払込票の支払金額や加盟店等）は、銀行サーバ２０のデータ記憶部２００に記憶される。

電子マネー情報は、ユーザの電子マネーに関する情報である。例えば、電子マネー情報には、電子マネーの残高を含む。電子マネー情報は、利用履歴又はチャージ履歴といった情報を含んでもよい。クレジットカード情報は、電子決済サービスに登録されたユーザのクレジットカードに関する情報である。例えば、クレジットカード情報は、クレジットカードのカード番号、有効期限、又は名義人といった情報が格納される。ユーザがクレジットカードを追加すると、当該クレジットカードに対応するクレジットカード情報がユーザデータベースＤＢ１に格納される。

［認証処理実行部］
認証処理実行部１０１は、ユーザが電子決済アプリから決済処理の実行を要求した場合に、所定の認証処理を実行する。本実施形態では、ユーザ端末５０で生体認証が実行され、認証処理実行部１０１は、ユーザ端末５０から生体認証の実行結果を取得する。生体認証自体は、任意の方法を利用可能であり、例えば、顔認証、指紋認証、又は虹彩認証を利用可能である。認証処理実行部１０１は、生体認証の実行結果が失敗を示す場合、認証処理が失敗したと判定し、生体認証の実行結果が成功を示す場合、認証処理が成功したと判定する。

なお、認証処理自体は、任意の方法を利用可能であり、本実施形態の例に限られない。例えば、生体認証は、ユーザ端末５０で実行されるのではなく、事業者サーバ１０で実行されてもよい。この場合、ユーザデータベースＤＢ１には、生体認証の正解となる生体情報が格納されているものとする。生体認証以外の他の方法としては、パスワード認証又はパスコード認証といった知識認証が利用されてもよいし、カード等の所持物を確認する所持認証が利用されてもよい。知識認証又は所持認証も、ユーザ端末５０で実行されてもよいし、事業者サーバ１０で実行されてもよい。

［決済処理実行部］
決済処理実行部１０２は、ユーザが電子決済アプリから決済処理の実行を要求した場合に、ユーザデータベースＤＢ１に格納されたユーザの決済手段に基づいて、決済処理を実行する。本実施形態では、決済処理実行部１０２は、認証処理が失敗した場合には決済処理を実行せず、認証処理が成功した場合に決済処理を実行する。なお、決済処理の実行時に認証処理が要求されなくてもよい。決済処理自体は、公知の種々の方法を利用可能である。

本実施形態では、電子マネーが利用されるので、決済処理実行部１０２は、ユーザの電子マネー情報が示す残高を、所定の金額だけ減少させることによって、決済処理を実行する。この金額は、払込票の支払金額と同じであってもよいし、この支払金額に所定の手数料が加算された額であってもよい。ユーザがクレジットカードや銀行口座といった他の決済手段を支払元として設定した場合にも、決済処理実行部１０２は、当該他の決済手段に基づいて、所定の金額の決済処理を実行すればよい。決済処理実行部１０２は、払込票以外の任意の場面における決済処理も実行可能である。

［３－２．銀行サーバにおいて実現される機能］
図５に示すように、銀行サーバ２０では、データ記憶部２００、実行結果取得部２０１、支払処理実行部２０２、入金処理実行部２０３、送金処理実行部２０４、及び精算処理実行部２０５が実現される。データ記憶部２００は記憶部２２を主として実現され、他の各機能は制御部２１を主として実現される。

［データ記憶部］
データ記憶部２００は、支払サービスを提供するために必要なデータを記憶する。例えば、データ記憶部２００は、加盟店データベースＤＢ２を記憶する。

図７は、加盟店データベースＤＢ２のデータ格納例を示す図である。図７に示すように、加盟店データベースＤＢ２は、支払サービスの加盟店に関する情報が格納されたデータベースである。例えば、加盟店データベースＤＢ２には、加盟店を識別可能な加盟店ＩＤと、加盟店の名前である加盟店名と、が格納される。加盟店データベースＤＢ２に加盟店ＩＤが格納された加盟店は、電子決済サービスを利用した払込票の支払が可能な加盟店である。

払込票の中には、本実施形態の支払サービスに対応していない加盟店の払込票も存在する。この加盟店の払込票が誤ってユーザ端末５０で読み取られた場合に、本実施形態の処理等を実行しないようにするために、加盟店データベースＤＢ２に、支払サービスに対応可能な加盟店が定義されている。支払サービスに対応可能な加盟店が追加又は削除された場合には、加盟店データベースＤＢ２が更新される。

なお、データ記憶部２００に記憶されるデータは、加盟店データベースＤＢ２に限られない。例えば、データ記憶部２００は、銀行に開設された口座に関する口座データベースを記憶してもよい。例えば、口座データベースには、支店名、口座番号、口座種別、残高、入出金明細、及び名義人といった情報が格納される。本実施形態では、第１口座及び第２口座が支払サービスで利用されるので、口座データベースには、第１口座及び第２口座の各々に関する情報も格納される。後述の入金処理及び送金処理の各々が実行されると、口座データベースに格納された第１口座の情報が更新される。後述の送金処理及び精算処理の各々が実行されると、口座データベースに格納された第２口座の情報が更新される。

例えば、データ記憶部２００は、払込票に関する払込票データベースを記憶してもよい。例えば、払込票データベースには、個々の支払を識別可能な支払ＩＤ、加盟店ＩＤ、支払金額、及び支払期限といった情報が格納される。払込票のバーコードには、少なくとも支払ＩＤが含まれる。支払ＩＤは、バーコードとしてではなく、文字又は数字として払込票に印刷されていてもよい。払込票には、支払ＩＤ以外の他の情報（加盟店名等）が含まれてもよい。他の情報も、バーコードに含まれていてもよいし、文字又は数字として払込票に印刷されていてもよい。

なお、払込票データベースには、支払前の払込票と、支払済みの払込票と、の両方の情報が格納されていてもよいし、何れか一方のみの情報だけが格納されていてもよい。払込票データベースには、支払済みの払込票に関する収納情報が格納されてもよい。収納情報は、収納代行会社サーバ３０に送信される。収納情報自体は、公知の種々の情報を利用可能である。払込票の支払に必要な情報自体も、公知の種々の情報を利用可能である。

［実行結果取得部］
実行結果取得部２０１は、ユーザ端末５０から、払込票が読み取られた場合に実行された認証処理の実行結果を取得する。認証処理の実行結果とは、認証処理が成功したか否かを示す情報である。本実施形態では、生体認証自体はユーザ端末５０で実行されるが、事業者サーバ１０の認証処理実行部１０１により生体認証の実行結果が確認されるので、ユーザ端末５０は、事業者サーバ１０の認証処理実行部１０１から、認証処理の実行結果を取得して銀行サーバ２０に送信する。

実行結果取得部２０１は、ユーザ端末５０を介して、事業者サーバ１０の認証処理実行部１０１により実行された認証処理の実行結果を取得する。なお、実行結果取得部２０１は、ユーザ端末５０を介することなく、事業者サーバ１０から直接的に、認証処理の実行結果を取得してもよい。また、認証処理がユーザ端末５０だけで完結する場合には、実行結果取得部２０１は、ユーザ端末５０だけで完結した認証処理の実行結果を取得すればよい。

［支払処理実行部］
支払処理実行部２０２は、ユーザ端末５０により読み取られた払込票に基づいて、ユーザ端末５０から利用可能な電子決済サービスを利用した支払処理を実行する。支払処理は、電子決済サービスにおけるユーザの決済手段を利用して、払込票の支払を行うための処理である。本実施形態では、ユーザの電子マネーの残高から、払込票の支払金額に応じた額だけを引くための処理が支払処理に相当する。

なお、厳密には、電子マネーの残高を引く処理は、事業者サーバ１０の決済処理実行部１０２により実行されるので、支払処理実行部２０２は、事業者サーバ１０の決済処理実行部１０２に、電子マネーの残高を引く処理を依頼することによって、支払処理を実行する。本実施形態では、支払処理実行部２０２が、ユーザ端末５０を介して、事業者サーバ１０に、電子マネーの残高を引く処理を依頼する場合を説明するが、支払処理実行部２０２は、事業者サーバ１０に対して直接的に、電子マネーの残高を引く処理を依頼してもよい。

本実施形態では、電子決済アプリのミニアプリが利用されるので、支払処理実行部２０２は、ミニアプリに基づいて、支払処理を実行する。ユーザ端末５０は、ミニアプリに基づいて、払込票の読み取りを実行したり、銀行サーバ２０との通信を実行したりする。ミニアプリ上では、ユーザ端末５０は、原則として事業者サーバ１０とは通信せずに、基本的には銀行サーバ２０と通信する。ユーザ端末５０が何らか事業者サーバ１０と通信したとしても、最低限の内容しかやり取りしないものとする。

例えば、支払処理実行部２０２は、ユーザ端末５０から、ミニアプリを利用して取得されたバーコード情報を取得する。支払処理実行部２０２は、バーコード情報に基づいて、ユーザ端末５０で読み取られた払込票の加盟店ＩＤを取得する。加盟店ＩＤは、バーコード情報に含まれていてもよいし、バーコード情報に含まれる情報に関連付けられて払込票データベースに格納されていてもよい。支払処理実行部２０２は、加盟店データベースＤＢ２を参照し、当該取得された加盟店ＩＤが格納されているか否かを判定する。即ち、支払処理実行部２０２は、当該取得された加盟店ＩＤが示す加盟店が支払サービスに対応しているか否かを判定する。

支払処理実行部２０２は、加盟店データベースＤＢ２に加盟店ＩＤが格納されていると判定されない場合、支払処理を実行しない。支払処理実行部２０２は、加盟店データベースＤＢ２に加盟店ＩＤが格納されていると判定された場合、加盟店データベースＤＢ２及び払込票データベースに基づいて、加盟店名や支払金額等の情報を取得し、ユーザ端末５０に送信する。ユーザ端末５０には、この情報に基づいて確認画面Ｇ６が表示される。

支払処理実行部２０２は、ユーザ端末５０から、確認画面Ｇ６のボタンＢ６２が選択されたことを示す通知を受信すると、既に特定された支払ＩＤに基づいて支払処理を実行する。例えば、支払処理実行部２０２は、ユーザ端末５０に対し、支払ＩＤに関連付けられた支払金額に応じた額だけ電子マネーを引く処理を依頼する。ユーザ端末５０は、ミニアプリから電子決済アプリを呼び出して、電子決済アプリの機能を利用して、事業者サーバ１０の決済処理実行部１０２との間で決済処理を実行する。

先述したように、決済処理が実行される前に認証処理が実行されるので、支払処理実行部２０２は、認証処理の実行結果に基づいて、支払処理を実行する。認証処理が失敗すれば、決済処理自体が実行されないので、支払処理は完了しない。支払処理実行部２０２は、認証処理が成功すれば、決済処理が実行されるので、以降の支払処理を実行する。なお、認証処理が成功しても、電子マネーの残高が不足する場合には、支払処理は完了しない。電子マネーの残高が不足するか否かは、認証処理が実行される前に判定されてもよい。

事業者サーバ１０の決済処理実行部１０２による決済処理が完了すると、電子マネーの残高が支払金額に応じた額だけ減少し、支払処理実行部２０２は、ユーザ端末５０から決済処理が完了したことを示す通知を取得する。支払処理実行部２０２は、この通知を受信すると、収納情報を生成し、払込票データベースに格納する。支払処理実行部２０２は、収納代行会社サーバ３０に、この収納情報を送信する。この収納情報は、払込票データベースに格納された払込票の消し込みに利用されてもよい。即ち、個々の払込票の支払が完了したか否かを判定するために、収納情報が利用されてもよい。

［入金処理実行部］
入金処理実行部２０３は、支払処理が実行された場合に、電子決済サービスを提供する事業者から、払込票を利用した支払サービスを提供する銀行への入金処理を実行する。入金処理は、支払処理における支払金額以上の資金を移動するための処理である。本実施形態では、振込を利用して入金処理が実行される場合を説明するが、入金処理は、事業者から銀行に資金を移動可能な方法であればよい。資金を移動させる方法自体は、公知の種々の方法を利用可能である。例えば、事業者が第１口座とは別に同一名義の口座を開設済みである場合には、振替によって入金処理が実行されてもよい。

本実施形態では、銀行には、入金処理用の第１口座と、精算処理用の第２口座と、が存在し、入金処理は、第１口座への資金の移動を意味する。このため、入金処理実行部２０３は、支払処理が実行された場合に、事業者から第１口座への入金処理を実行する。例えば、事業者サーバ１０は、事業者の従業員等が操作する端末から所定の入金操作を受け付けた場合に、銀行サーバ２０に、入金処理の実行を依頼する。この依頼には、入金処理における入金額が含まれる。入金処理実行部２０３は、この依頼に基づいて、入金処理を実行し、第１口座の残高を、事業者により指定された金額だけ増やす。なお、入金処理の依頼は、事業者の従業員等により手動で行われるのではなく、バッチ処理等によって定期的に実行されてもよい。

［送金処理実行部］
送金処理実行部２０４は、第１口座から第２口座への送金処理を実行する。この送金処理は、第１口座の残高の一部又は全部を、第２口座に移動させる処理である。送金処理では、収納情報が作成された払込票の支払金額の合計金額以上の資金が移動するものとするが、この合計金額よりも多少であれば少ない資金が移動してもよい。また、送金処理における送金額は、収納情報に応じて動的に決定されるのではなく、固定金額であってもよい。

例えば、送金処理実行部２０４は、所定の送金サイクルに基づいて、送金処理の実行タイミングが訪れたか否かを判定する。送金サイクルは、送金処理の実行周期である。本実施形態では、送金処理が定期的に実行される場合を説明するが、送金処理は、不定期的に実行されてもよい。例えば、銀行の従業員等が何らかの操作をしたタイミングで送金処理が実行されてもよい。

［精算処理実行部］
精算処理実行部２０５は、入金処理が実行された場合に、銀行から収納代行会社への精算処理を実行する。収納代行会社は、精算先の一例である。このため、本実施形態で収納代行会社について説明している箇所は、精算先と読み替えることができる。精算先は、銀行が一時的に預かった資金を移動させる移動先である。銀行から加盟店に直接的に資金が移動する場合には、精算先は、加盟店であってもよい。精算先は、収納代行会社又は加盟店以外の名前で呼ばれる組織であってもよい。

本実施形態では、精算処理実行部２０５は、入金処理及び送金処理の各々が実行された場合に、第２口座に基づいて、精算処理を実行する。例えば、精算処理実行部２０５は、所定の精算サイクルに基づいて、精算処理の実行タイミングが訪れたか否かを判定する。精算サイクルは、精算処理の実行周期である。本実施形態では、精算処理が定期的に実行される場合を説明するが、精算処理は、不定期的に実行されてもよい。例えば、銀行の従業員等が何らかの操作をしたタイミングで精算処理が実行されてもよい。

例えば、精算処理実行部２０５は、払込票データベースを参照し、未精算の収納情報を取得する。精算処理実行部２０５は、未精算の収納情報が示す支払金額の合計額に基づいて、精算処理を実行する。精算処理実行部２０５は、収納代行会社の口座に、この合計額を振り込むことによって、精算処理を実行する。この口座は、本実施形態で説明している銀行であってもよいし、他行であってもよい。この口座は、銀行以外の口座であってもよい。精算処理における資金の移動方法も、入金処理等と同様に、振込に限られず、種々の方法を利用可能である。

［３－３．収納代行会社サーバにおいて実現される機能］
図５に示すように、収納代行会社サーバ３０では、データ記憶部３００が実現される。データ記憶部３００は、記憶部３２を主として実現される。データ記憶部３００は、収納代行会社が取り扱う払込票に関するデータベースを記憶する。このデータベースは、銀行サーバ２０に記憶されるものと同様のデータベースであってもよいが、収納代行会社は、本実施形態の支払サービス以外の他の支払サービスにも対応していることがあるので、より多くの払込票に関する情報が格納されているものとする。

収納代行会社サーバ３０は、銀行サーバ２０から収納情報を受信すると、データ記憶部３００に記憶されたデータベースに基づいて、未精算の払込票の消込を実行する。収納代行会社サーバ３０は、個々の加盟店ごとに、精算済の払込票の支払金額の合計額の精算処理を実行する。この精算処理が任意の方法で実行可能である点は、銀行サーバ２０の精算処理実行部２０５と同様である。

［３－４．加盟店サーバにおいて実現される機能］
図５に示すように、加盟店サーバ４０では、データ記憶部４００が実現される。データ記憶部４００は、記憶部４２を主として実現される。データ記憶部４００は、加盟店が発行した払込票に関するデータベースを記憶する。このデータベースは、収納代行会社サーバ３０に記憶されるデータベースのうち、加盟店が発行した払込票に関する情報が格納される。加盟店サーバ４０は、データ記憶部４００に記憶されたデータベースに基づいて、未精算の払込票の消込を実行してもよい。加盟店サーバ４０は、収納代行会社サーバ３０による精算処理が実行された場合には、この精算処理の実行結果を、データ記憶部４００のデータベースに格納する。

［３－５．ユーザ端末において実現される機能］
図５に示すように、ユーザ端末５０では、データ記憶部５００、検出部５０１、受付部５０２、及び表示制御部５０３が実現される。データ記憶部５００は、記憶部５２を主として実現される。他の各機能は、制御部５１を主として実現される。ユーザ端末５０には、電子決済サービスに関するスーパーアプリである電子決済アプリがインストールされている。電子決済アプリから、支払サービスに関するミニアプリである支払アプリを利用可能である。

［データ記憶部］
データ記憶部５００は、バーコードに対応する支払を実行するために必要なデータを記憶する。データ記憶部５００は、電子決済アプリ及び支払アプリを記憶する。データ記憶部５００は、アプリにログインするための情報を記憶してもよい。電子決済アプリで複数の決済手段を利用可能な場合には、データ記憶部５００は、ユーザにより選択された決済手段を識別する情報を記憶してもよい。

［検出部］
検出部５０１は、払込票のバーコードを検出する。本実施形態では、撮影部５６により撮影された撮影画像が利用される場合を説明するが、ユーザ端末５０に専用のコードリーダを備えておいてもよい。例えば、検出部５０１は、撮影画像を画像解析して、バーコードを検出する。検出部５０１は、検出したバーコードに含まれるバーコード情報を取得する。検出部５０１は、バーコードを利用せずに、撮影画像に対して光学文字認識を利用して、払込票に記載された情報を検出してもよい。この場合、撮影画像が銀行サーバ２０に送られて、光学文字認識が銀行サーバ２０で実行されてもよい。

［受付部］
受付部５０２は、ユーザの操作を受け付ける。例えば、受付部５０２は、図２及び図３で説明した各画面に対する操作を受け付ける。

［表示制御部］
表示制御部５０３は、電子決済アプリ及び支払アプリの少なくとも一方に基づいて、図２及び図３で説明した各画面を表示させる。

［４．支払システムにおいて実行される処理］
図８及び図９は、支払システム１において実行される処理の一例を示すフロー図である。図８及び図９に示す処理は、制御部１１，２１，３１，４１，５１の各々が記憶部１２，２２，３２，４２，５２に記憶されたプログラムに従って動作することによって実行される。この処理は、各機能ブロックが実行する処理の一例である。なお、ユーザは、電子決済サービスへの利用登録、電子決済アプリのインストール、及び支払アプリの利用設定を完了しているものとする。このため、ユーザ端末５０では、図２のアイコンＩ１５を含むトップ画面Ｇ１を表示可能であるものとする。

図８に示すように、ユーザ端末５０は、ユーザの操作に基づいて電子決済アプリを起動して、電子決済アプリのトップ画面Ｇ１を表示部５５に表示させる（Ｓ１）。Ｓ１では、ユーザ端末５０及び事業者サーバ１０の間でログイン処理が実行されてもよい。ユーザ端末５０は、ユーザがアイコンＩ１５を選択すると、支払アプリを起動して、支払アプリのトップ画面Ｇ４を表示部５５に表示させる（Ｓ２）。Ｓ２では、ユーザ端末５０及び銀行サーバ２０の間でログイン処理が実行されてもよい。ユーザ端末５０は、ユーザがボタンＢ４２を選択すると、撮影部５６を起動して、撮影画面Ｇ５を表示部５５に表示させる（Ｓ３）。Ｓ３においては、ユーザ端末５０は、撮影部５６の検出信号に基づいて連続的に撮影画像を取得し、撮影画面Ｇ５に撮影画像を表示させる。

ユーザ端末５０は、撮影画像に基づいて、バーコードを検出する（Ｓ４）。Ｓ４においては、ユーザ端末５０は、公知の検出アルゴリズムに基づいて、撮影画像を画像解析してバーコードを検出する。ユーザ端末５０は、検出アルゴリズムに定義されたルールに基づいて、バーコードに含まれるバーコード情報を取得する。バーコード情報には、個々の支払を識別可能な情報が含まれるものとする。

ユーザ端末５０は、銀行サーバ２０に、バーコードから取得したバーコード情報を送信する（Ｓ５）。銀行サーバ２０は、バーコード情報を受信すると、加盟店データベースＤＢ２に基づいて、支払サービスに対応可能な加盟店であるか否かを判定する（Ｓ６）。支払サービスに対応可能な加盟店であると判定されない場合（Ｓ６；Ｎ）、所定のエラーメッセージが表示されて本処理は終了する。

支払サービスに対応可能な加盟店であると判定された場合（Ｓ６；Ｙ）、銀行サーバ２０は、ユーザ端末５０に、支払金額等の情報を送信する（Ｓ７）。ユーザ端末５０は、支払金額等の情報を受信すると、確認画面Ｇ６を表示部５５に表示させる（Ｓ８）。ユーザ端末５０は、ユーザがボタンＢ６０を選択して利用規約を確認し、チェックボックスＣ６１にチェックが入れられた状態でボタンＢ６２を選択すると、銀行サーバ２０に、支払処理の実行要求を送信する（Ｓ９）。

銀行サーバ２０は、支払処理の実行要求を受信すると、ユーザ端末５０に、電子決済アプリを呼び出して認証処理を実行するように依頼する（Ｓ１０）。ユーザ端末５０は、依頼を受信すると、事業者サーバ１０との間で認証処理を実行する（Ｓ１１）。ユーザ端末５０は、銀行サーバ２０に、認証処理の実行結果を送信する（Ｓ１２）。

銀行サーバ２０は、認証処理の実行結果を受信すると、認証処理の実行結果を参照する（Ｓ１３）。認証処理の実行結果が失敗だった場合（Ｓ１３；失敗）、所定のエラーメッセージが表示されて本処理は終了する。認証処理の実行結果が成功だった場合（Ｓ１３；成功）、銀行サーバ２０は、ユーザ端末５０に、電子マネーの利用を依頼する（Ｓ１４）。図８のフロー図では、Ｓ１０、Ｓ１３、及びＳ１４の一連の処理が支払処理に相当する。

図９に移り、ユーザ端末５０は、銀行サーバ２０からの依頼に基づいて、事業者サーバ１０との間で、電子マネーを利用するための決済処理を実行する（Ｓ１５）。ユーザ端末５０は、銀行サーバ２０に、電子マネーが利用されたことを通知する（Ｓ１６）。銀行サーバ２０は、通知を受信すると、収納情報を生成し（Ｓ１７）、ユーザ端末５０に、支払処理が完了したことを通知する（Ｓ１８）。ユーザ端末５０は、通知を受信すると、完了画面Ｇ７を表示部５５に表示させる（Ｓ１９）。以上により、ユーザ端末５０側の処理は完了する。

事業者サーバ１０は、事業者の従業員等の操作に基づいて、銀行サーバ２０に、第１口座への入金処理の実行を依頼する（Ｓ２０）。銀行サーバ２０は、この依頼に基づいて、第１口座への入金処理を実行する（Ｓ２１）。銀行サーバ２０は、所定の送金サイクルに基づいて、第１口座から第２口座への送金処理を実行する（Ｓ２２）。銀行サーバ２０は、所定の精算サイクルに基づいて、収納代行会社への精算処理を実行する（Ｓ２３）。精算処理の実行結果は、収納代行会社サーバ３０に送信される。収納代行会社サーバ３０は、加盟店への精算処理を実行する（Ｓ２４）。

以上説明した支払システム１によれば、ユーザ端末５０により払込票が読み取られた場合に、支払処理、入金処理、及び精算処理の各々を実行することによって、支払サービスと連携する電子決済サービスの事業者側で独自の機能を開発させることなく、銀行側の機能を利用して支払サービスを提供できるので、事業者の手間を軽減できる。例えば、銀行に口座を開設していないユーザだったとしても、支払サービスを利用できるので、ユーザの利便性が向上する。また、ユーザは、普段使い慣れている電子マネーを利用して払込票の支払が可能になるので、この点でもユーザの利便性が向上する。銀行としても、既存の銀行アプリからの支払サービスの仕組みを流用できるので、銀行側の負担もさほど大きくはならない。

また、支払システム１は、第１口座から第２口座への送金処理を実行し、入金処理及び送金処理の各々が実行された場合に、第２口座に基づいて、精算処理を実行することによって、精算処理に必要な資金を第２口座で一括管理し、精算処理を簡易化できる。

また、支払システム１は、スーパーアプリである電子決済アプリから利用可能なミニアプリである支払アプリに基づいて、支払処理を実行することによって、事業者が提供する電子決済アプリを利用して支払サービスを提供できる。例えば、支払アプリは、原則として銀行側で開発するものなので、事業者の手間を軽減できる。支払アプリ自体は、既存の支払サービスを提供する銀行アプリを流用して作成可能なので、銀行側の負担もさほど大きくはならない。

また、支払システム１は、ユーザ端末５０から取得された認証処理の実行結果に基づいて、支払処理を実行することによって、支払サービスにおけるセキュリティが高まる。認証時に必要な情報を銀行側で管理しなくても、セキュリティの高い支払サービスを実現できる。

［５．変形例］
なお、本開示は、以上に説明した実施の形態に限定されるものではない。本開示の趣旨を逸脱しない範囲で、適宜変更可能である。

図１０は、変形例における機能ブロックの一例を示す図である。図１０に示すように、変形例では、実施形態で説明した機能に加えて、収納情報取得部２０６、第１判定部２０７、第１制限部２０８、第２判定部２０９、及び第２制限部２１０が実現される。

［５－１．変形例１］
例えば、支払サービスは、複数の事業者の各々の電子決済サービスと連携してもよい。即ち、ユーザ端末５０から利用可能な電子決済サービスが複数存在し、ユーザは、任意の電子決済サービスを利用して払込票の支払が可能であってもよい。この場合に、第１口座は、事業者ごとに存在してもよい。即ち、銀行には、複数の事業者の各々の第１口座が開設されている。１つの事業者に対し、複数の第１口座が存在してもよい。

図１１は、変形例１における資金の流れの一例を示す図である。図１１の例では、３つの事業者Ｘ～Ｚの各々が電子決済サービスを提供している。銀行には、事業者Ｘ～Ｚの各々の第１口座ＡＸ～ＡＺが存在する。入金処理実行部２０３は、複数の事業者の各々から第１口座ＡＸ～ＡＺへの入金処理を実行する。例えば、入金処理実行部２０３は、事業者Ｘから第１口座ＡＸへの入金処理を実行する。入金処理実行部２０３は、事業者Ｙから第１口座ＡＹへの入金処理を実行する。入金処理実行部２０３は、事業者Ｚから第１口座ＡＺへの入金処理を実行する。個々の第１口座ＡＸ～ＡＺへの入金処理は、実施形態で説明した通りである。なお、以降では、事業者Ｘ～Ｚ及び第１口座ＡＸ～ＡＺの符号を省略する。

送金処理実行部２０４は、複数の事業者の各々の第１口座から第２口座への送金処理を実行する。変形例１では、第１口座と第２口座は、多対１で対応する。即ち、第２口座は、複数の事業者に共通の口座である。第２口座は、複数の第１口座の各々からの資金を集約する口座である。個々の第１口座から第２口座への送金処理は、実施形態で説明した通りである。図１１の例であれば、３つの第１口座からの資金が第２口座に集約される。第２口座は、第１口座ごとに用意されてもよい。即ち、複数の第２口座が存在してもよい。

なお、ある第１口座から第２口座への送金処理のタイミングと、他の第１口座から第２口座への送金処理のタイミングと、は同じであってもよいし、互いに異なってもよい。図１１の例であれば、事業者Ｘの第１口座ＡＸから第２口座への送金処理のタイミング、事業者Ｙの第１口座ＡＹから第２口座への送金処理のタイミング、及び事業者Ｚの第１口座ＡＺから第２口座への送金処理のタイミングの各々は、同じであってもよいし、互いに異なってもよい。

変形例１によれば、複数の事業者の各々から第１口座への入金処理を実行し、複数の事業者の各々の第１口座から第２口座への送金処理を実行することによって、複数の事業者の各々の電子決済サービスを利用した支払サービスを提供できる。ユーザは、任意の事業者の電子決済サービスを利用できるので、ユーザの利便性が高まる。

［５－２．変形例２］
例えば、実施形態で説明したように、精算処理実行部２０５は、所定の精算サイクルに基づいて、精算処理を実行する。送金処理実行部２０４は、精算サイクルよりも短い送金サイクルに基づいて、送金処理を実行してもよい。例えば、銀行から収納代行会社への精算サイクルを３日とすると、第１口座から第２口座への送金サイクルは、１日又は２日であってもよい。送金処理実行部２０４は、ある送金タイミングｔ１が訪れて送金処理を実行した場合に、この送金タイミングから送金サイクルだけ後のタイミングを、次の送金タイミングｔ２として特定する。送金処理実行部２０４は、送金タイミングｔ２が訪れた場合に、送金タイミングｔ１から送金タイミングｔ２までの間に生成された収納情報の総額に基づいて、送金処理を実行する。

変形例２によれば、精算サイクルよりも短い送金サイクルに基づいて、送金処理を実行することによって、第２口座の残高が不足することを防止できる。

［５－３．変形例３］
例えば、入金処理実行部２０３は、第１口座の残高に基づいて、入金処理を実行してもよい。入金処理実行部２０３は、第１口座の残高が所定の閾値未満になった場合に、自動的に入金処理を実行する。入金処理実行部２０３は、第１口座の残高が閾値以上の場合には、入金処理は実行しない。第１口座の残高が閾値以上であったとしても、入金処理実行部２０３は、事業者の従業員等により入金処理が指示されたり、所定のタイミングが訪れたりした場合には、その都度入金処理を実行してもよい。

なお、入金処理実行部２０３は、第１口座の残高に基づいて、入金処理を事業者に促すための他の処理を実行してもよい。他の処理は、事業者に何らかの情報を出力するものであればよい。例えば、事業者サーバ１０又は事業者の従業員等の端末に、入金処理を促す旨のメッセージを送信する処理が他の処理に相当してもよい。このメッセージは、任意の媒体を利用可能であり、例えば、電子メール、ＳＮＳ、ＳＭＳ、又はメッセージアプリを利用してもよい。他にも例えば、メッセージではなく、所定のアラートを示す信号を出力する処理が他の処理に相当してもよい。

変形例３によれば、第１口座の残高に基づいて、入金処理又は入金処理を事業者に促すための他の処理を実行することによって、第１口座の残高が不足することを防止できる。

［５－４．変形例４］
例えば、変形例３で説明した閾値は、固定値であってもよいが、送金処理に必要な合計額が収納情報によって把握できるので、この閾値は、収納情報に基づいて決定されてもよい。変形例４の支払システム１は、支払処理が実行された払込票又は払込用番号に関する収納情報を取得する収納情報取得部２０６を含む。例えば、収納情報取得部２０６は、実施形態で説明した払込票データベースを参照し、収納情報を取得する。収納情報は、他のデータベースに格納されていてもよい。

入金処理実行部２０３は、送金処理が実行される前に、第１口座の残高と、収納情報と、に基づいて、第１口座の残高が不足するか否かを予測する。例えば、入金処理実行部２０３は、収納情報に基づいて、送金処理に必要な必要額を算出する。この必要額は、未精算の払込票の支払金額の総額である。入金処理実行部２０３は、第１口座の残高が当該算出された必要額以上であるか否かを判定する。入金処理実行部２０３は、第１口座の残高が不足すると予測された場合に、入金処理又は他の処理を実行する。

変形例４によれば、送金処理が実行される前に、第１口座の残高と、収納情報と、に基づいて、第１口座の残高が不足するか否かを予測し、第１口座の残高が不足すると予測された場合に、入金処理又は他の処理を実行することによって、第１口座の残高が不足することをより確実に防止できる。第１口座に本当に資金が必要な時にだけ入金処理又は他の処理を実行することによって、無駄な入金処理又は他の処理が実行されるのを防止できる。その結果、銀行サーバ２０の処理負荷を軽減できる。

［５－５．変形例５］
例えば、あるタイミングの入金処理が実行されてから、次のタイミングの入金処理が実行されるまでの間に、複数の支払処理が実行された場合には、入金処理実行部２０３は、複数の支払処理の各々の支払金を、一度にまとめて銀行に入金するための入金処理を実行してもよい。例えば、ユーザデータベースＤＢ１に、支払アプリから行われた払込票の支払の履歴が格納されているものとする。事業者サーバ１０は、この履歴に基づいて、次の入金処理のタイミングまでの間に実行された複数の支払処理の各々の支払金額の総額を計算する。事業者サーバ１０は、銀行サーバ２０に、当該計算された総額の入金処理を依頼する。入金処理実行部２０３は、この依頼に基づいて入金処理を実行する。

変形例５によれば、複数の支払処理の各々の支払金を、一度にまとめて金融機関に入金するための入金処理を実行することによって、何度も入金処理が実行されるといったことを防止し、入金処理の実行回数を減らすことができる。その結果、事業者サーバ１０及び銀行サーバ２０の各々の処理負荷を軽減できる。事業者からしても、入金処理のための手数料を抑えることができる。

［５－６．変形例６］
例えば、事業者は、支払サービスに関する複数の加盟店のうちの少なくとも１つの加盟店に対応可能であってもよい。即ち、事業者は、全ての加盟店の払込票について、電子決済アプリのミニアプリである支払アプリからの支払を可能にするのではなく、一部の加盟店の払込票についてのみ、支払を可能にしてもよい。例えば、事業者は、公共料金は対応可能とするが、オンラインショッピングモールの商品の支払は対応しない、といったように、任意の加盟店を対応可能な加盟店として指定できる。

支払システム１は、第１判定部２０７及び第１制限部２０８を含む。第１判定部２０７は、払込票又は払込用番号に対応する加盟店が上記少なくとも１つの加盟店であるか否かを判定する。上記少なくとも１つの加盟店とは、事業者が対応可能な加盟店なので、以降では、対応可能加盟店と記載する。このため、対応可能加盟店と記載した箇所は、少なくとも１つの加盟店と読み替えることができる。対応可能加盟店は、加盟店データベースＤＢ２に定義された加盟店である。変形例６では、加盟店データベースＤＢ２に定義された加盟店は、事業者が指定した対応可能加盟店である。

第１制限部２０８は、対応可能加盟店であると判定されない場合、支払処理、入金処理、及び精算処理のうちの少なくとも１つの実行を制限する。変形例６では、これらの全てが実行されない場合を説明するが、例えば、支払処理だけは実行するが、入金処理及び精算処理は実行しないといったように、少なくとも１つが実行されないように制限すればよい。支払処理が実行される場合には、この支払処理は、事後的にキャンセルされる。

なお、第１制限部２０８は、対応可能加盟店であると判定されない場合、ユーザ端末５０に、その旨を通知してもよい。第１制限部２０８は、対応可能加盟店であると判定された場合、ユーザ端末５０に、その旨を通知したうえで、支払処理が実行されるようにしてもよい。更に、この通知をせずに、支払処理が実行されるようにしてもよい。

変形例６によれば、払込票に対応する加盟店が対応可能加盟店であると判定されない場合、支払処理、入金処理、及び精算処理のうちの少なくとも１つの実行を制限することによって、事業者が対応していない加盟店の払込票の支払処理等が実行されることを防止できる。事業者は、任意の対応可能加盟店を決めることができるので、事業者の利便性が高まる。

［５－７．変形例７］
例えば、変形例１で説明したように、支払サービスが、複数の事業者の各々の電子決済サービスと連携する場合に、事業者ごとに、対応可能加盟店が定められていてもよい。この場合、変形例６のように対応可能加盟店を定めるためには、加盟店データベースＤＢ２には、事業者を識別可能な事業者ＩＤごとに、対応可能加盟店の加盟店ＩＤ及び加盟店名が定義されている。個々の事業者は、支払サービスの複数の加盟店のうちの任意の加盟店を、対応可能加盟店として指定できる。

第１判定部２０７は、払込票に対応する加盟店が、支払処理に対応する事業者の対応可能加盟店であるか否かを判定する。払込票に対応する加盟店とは、払込票に記載された加盟店である。払込票に対応する加盟店は、払込票を発行した加盟店、又は、払込票の支払により最終的に資金を受け取る加盟店ということもできる。第１判定部２０７は、ユーザ端末５０から支払処理の要求を受信した場合に、この要求に基づいて、払込票に対応する加盟店の加盟店ＩＤを取得する。この加盟店ＩＤの取得方法は、実施形態で説明した通りである。第１判定部２０７は、ユーザ端末５０が利用中の支払アプリに基づいて事業者を特定し、この事業者に関連付けられた対応可能加盟店として、払込票に対応する加盟店の加盟店ＩＤが加盟店データベースＤＢ２に格納されているか否かを判定する。

第１制限部２０８は、支払処理に対応する事業者の対応可能加盟店であると判定されない場合、支払処理、入金処理、及び精算処理のうちの少なくとも１つの実行を制限する。この制限の方法は、変形例６で説明した通りである。

変形例７によれば、払込票に対応する加盟店が、支払処理に対応する対応可能加盟店であると判定されない場合、支払処理、入金処理、及び精算処理のうちの少なくとも１つの実行を制限することによって、複数の事業者が支払サービスに対応する場合であったとしても、個々の事業者が対応していない加盟店の払込票の支払処理等が実行されることを防止できる。事業者は、任意の対応可能加盟店を決めることができるので、事業者の利便性が高まる。

［５－８．変形例８］
例えば、変形例１で説明したように、支払サービスが、複数の事業者の各々の電子決済サービスと連携する場合に、支払サービスに関する複数の加盟店の各々は、複数の事業者の少なくとも１つの事業者に対応可能であってもよい。即ち、変形例６－７のように、事業者が加盟店を指定するのではなく、加盟店が事業者を指定してもよい。個々の加盟店が指定した事業者は、加盟店データベースＤＢ２に格納されているものとする。

即ち、加盟店は、全ての事業者の電子決済サービスを利用して払込票の支払を可能にするのではなく、一部の事業者の電子決済サービスについてのみ、払込票の支払を可能にしてもよい。例えば、加盟店は、事業者Ｘの電子決済サービスは対応可能とするが、事業者Ｙの電子決済サービスは対応しない、といったように、任意の事業者を対応可能な事業者として指定できる。

支払システム１は、第２判定部２０９及び第２制限部２１０を含む。第２判定部２０９は、支払処理に対応する事業者が、払込票又は払込用番号に対応する加盟店の少なくとも１つの事業者であるか否かを判定する。上記少なくとも１つの事業者とは、加盟店が対応可能な加盟店なので、以降では、対応可能事業者と記載する。このため、対応可能事業者と記載した箇所は、少なくとも１つの事業者と読み替えることができる。対応可能事業者は、加盟店データベースＤＢ２に定義された事業者である。変形例８では、加盟店データベースＤＢ２に定義された事業者は、加盟店が指定した対応可能事業者である。

第２制限部２１０は、払込票に対応する加盟店の対応可能事業者であると判定されない場合、支払処理、入金処理、及び精算処理のうちの少なくとも１つの実行を制限する。変形例８では、これらの全てが実行されない場合を説明するが、例えば、支払処理だけは実行するが、入金処理及び精算処理は実行しないといったように、少なくとも１つが実行されないように制限すればよい。支払処理が実行される場合には、この支払処理は、事後的にキャンセルされる。

なお、第２制限部２１０は、対応可能事業者であると判定されない場合、ユーザ端末５０に、その旨を通知してもよい。第２制限部２１０は、対応可能事業者であると判定された場合、ユーザ端末５０に、その旨を通知したうえで、支払処理が実行されるようにしてもよい。更に、この通知をせずに、支払処理が実行されるようにしてもよい。

変形例８によれば、支払処理に対応する事業者が、払込票に対応する加盟店の対応可能事業者であると判定されない場合、支払処理、入金処理、及び精算処理のうちの少なくとも１つの実行を制限することによって、加盟店が対応していない事業者の電子決済サービスを利用した支払処理等が実行されることを防止できる。加盟店は、任意の対応可能事業者を決めることができるので、加盟店の利便性が高まる。

［５－９．変形例９］
例えば、実施形態では、払込票を利用した支払を例に挙げて説明したが、払込票ではなく、払込用番号を入力させる支払についても同様の処理を利用可能である。払込用番号は、支払を一意に識別する情報である。払込用番号は、支払ＩＤと同じであってもよいし、支払ＩＤとは異なる情報であってもよい。払込用番号は、電子メール等でユーザに通知される。ユーザがコンビニエンスストアの端末等で払込用番号を入力すると、支払をするための用紙（払込票の一種）が印刷され、店員が操作する端末等で支払をすることができる。本変形例では、このような払込用番号をユーザ端末５０に入力することによって、支払をする場合を説明する。

本変形例の払込票データベースには、支払ＩＤに関連付けられて払込用番号が格納されているものとする。支払システム１で実行される処理は、実施形態で説明した処理と概ね同様であるが、ユーザ端末５０がバーコードを読み取ってバーコード情報に含まれる支払ＩＤを取得する処理が、ユーザ端末５０に入力された払込用番号を利用して支払ＩＤを取得する処理に置き換わる点で異なる。支払処理実行部２０２は、ユーザ端末５０に入力された払込用番号に基づいて、ユーザ端末５０から利用可能な電子決済サービスを利用した支払処理を実行する。他の点は概ね実施形態及び他の変形例と同様であり、払込票の記載を払込用番号に読み替えればよい。

例えば、入金処理実行部２０３は、支払処理が実行された場合に、電子決済サービスを提供する事業者から、払込用番号を利用した支払サービスを提供する銀行への入金処理を実行する。収納情報取得部２０６は、支払処理が実行された払込用番号に関する収納情報を取得する。第１判定部２０７は、払込用番号に対応する加盟店が、支払処理に対応する事業者の少なくとも１つの加盟店であるか否かを判定する。実行結果取得部２０１は、ユーザ端末５０から、払込用番号が入力された場合に実行された認証処理の実行結果を取得する。第１判定部２０７は、払込用番号に対応する加盟店が、支払処理に対応する事業者の少なくとも１つの加盟店であるか否かを判定する。これらの処理の詳細は、実施形態及び先述した変形例の通りである。

変形例９によれば、ユーザ端末５０に払込用番号を入力する場合の支払サービスにおける事業者の手間を軽減できる。

［５－１０．変形例１０］
例えば、上記変形例を組み合わせてもよい。

例えば、スーパーアプリ及びミニアプリの概念がない通常のアプリを利用して支払サービスが提供されてもよい。例えば、アプリではなく、ブラウザから支払サービスが提供されてもよい。例えば、電子マネーではなく、クレジットカード等を利用して払込票又は払込用番号の支払が実現されてもよい。例えば、第１口座が存在せず、事業者が第２口座に直接的に入金してもよい。逆に第２口座が存在せず、第１口座から収納代行会社に直接的に精算が行われてもよい。例えば、支払時の認証処理は省略されてもよい。例えば、データ記憶部２００は、銀行サーバ２０とは別のデータベースサーバで実現されてもよい。銀行サーバ２０において実現されるものとして説明した機能は、事業者サーバ１０、収納代行会社サーバ３０、加盟店サーバ４０、又はユーザ端末５０といった他のコンピュータで実現されてもよい。各機能は、複数のコンピュータで分担されてもよい。

１ 支払システム、Ｎ ネットワーク、１０ 事業者サーバ、１１，２１，３１，４１，５１ 制御部、１２，２２，３２，４２，５２ 記憶部、１３，２３，３３，４３，５３ 通信部、２０ 銀行サーバ、３０ 収納代行会社サーバ、４０ 加盟店サーバ、５０ ユーザ端末、５４ 操作部、５５ 表示部、５６ 撮影部、Ｇ１ トップ画面、Ｇ２ 一覧画面、Ｇ３ 確認画面、Ｇ４ トップ画面、Ｇ５ 撮影画面、Ｇ６ 確認画面、Ｇ７ 完了画面、Ｂ３１，Ｂ３３，Ｂ４１，Ｂ４２，Ｂ６０，Ｂ６２ ボタン、Ｃ３２，Ｃ６１ チェックボックス、ＤＢ１ ユーザデータベース、ＤＢ２ 加盟店データベース、Ｉ１０，Ｉ１１，Ｉ１２，Ｉ１３，Ｉ１４，Ｉ１５，Ｉ２０ アイコン、Ｍ３０，Ｍ４０ メッセージ、１００ データ記憶部、１０１ 認証処理実行部、１０２ 決済処理実行部、２００ データ記憶部、２０１ 実行結果取得部、２０２ 支払処理実行部、２０３ 入金処理実行部、２０４ 送金処理実行部、２０５ 精算処理実行部、２０６ 収納情報取得部、２０７ 第１判定部、２０８ 第１制限部、２０９ 第２判定部、２１０ 第２制限部、３００ データ記憶部、４００ データ記憶部、５００ データ記憶部、５０１ 検出部、５０２ 受付部、５０３ 表示制御部。

Claims (14)

1. ユーザ端末により読み取られた払込票、又は、ユーザ端末に入力された払込用番号に基づいて、前記ユーザ端末から利用可能な電子決済サービスを利用した支払処理を実行する支払処理実行手段と、
   前記支払処理が実行された場合に、前記電子決済サービスを提供する事業者から、前記払込票又は前記払込用番号を利用した支払サービスを提供する金融機関への入金処理を実行する入金処理実行手段と、
   前記入金処理が実行された場合に、前記金融機関から精算先への精算処理を実行する精算処理実行手段と、
   を含む支払システム。
2. 前記金融機関には、前記入金処理用の第１口座と、前記精算処理用の第２口座と、が存在し、
   前記入金処理実行手段は、前記支払処理が実行された場合に、前記事業者から前記第１口座への前記入金処理を実行し、
   前記支払システムは、前記第１口座から前記第２口座への送金処理を実行する送金処理実行手段を更に含み、
   前記精算処理実行手段は、前記入金処理及び前記送金処理の各々が実行された場合に、前記第２口座に基づいて、前記精算処理を実行する、
   請求項１に記載の支払システム。
3. 前記支払サービスは、複数の前記事業者の各々の前記電子決済サービスと連携し、
   前記第１口座は、前記事業者ごとに存在し、
   前記入金処理実行手段は、前記複数の事業者の各々から前記第１口座への前記入金処理を実行し、
   前記送金処理実行手段は、前記複数の事業者の各々の前記第１口座から前記第２口座への前記送金処理を実行する、
   請求項２に記載の支払システム。
4. 前記精算処理実行手段は、所定の精算サイクルに基づいて、前記精算処理を実行し、
   前記送金処理実行手段は、前記精算サイクルよりも短い送金サイクルに基づいて、前記送金処理を実行する、
   請求項２又は３に記載の支払システム。
5. 前記入金処理実行手段は、前記第１口座の残高に基づいて、前記入金処理又は前記入金処理を前記事業者に促すための他の処理を実行する、
   請求項２～４の何れかに記載の支払システム。
6. 前記支払システムは、前記支払処理が実行された前記払込票又は前記払込用番号に関する収納情報を取得する収納情報取得手段を更に含み、
   前記入金処理実行手段は、前記送金処理が実行される前に、前記第１口座の残高と、前記収納情報と、に基づいて、前記第１口座の残高が不足するか否かを予測し、前記第１口座の残高が不足すると予測された場合に、前記入金処理又は前記他の処理を実行する、
   請求項５に記載の支払システム。
7. 前記入金処理実行手段は、複数の前記支払処理の各々の支払金を、一度にまとめて前記金融機関に入金するための前記入金処理を実行する、
   請求項１～６の何れかに記載の支払システム。
8. 前記ユーザ端末には、前記電子決済サービスに関するスーパーアプリがインストールされており、
   前記スーパーアプリから、前記支払サービスに関するミニアプリを利用可能であり、
   前記支払処理実行手段は、前記ミニアプリに基づいて、前記支払処理を実行する、
   請求項１～７の何れかに記載の支払システム。
9. 前記事業者は、前記支払サービスに関する複数の加盟店のうちの少なくとも１つの加盟店に対応可能であり、
   前記支払システムは、
   前記払込票又は前記払込用番号に対応する前記加盟店が前記少なくとも１つの加盟店であるか否かを判定する第１判定手段と、
   前記少なくとも１つの加盟店であると判定されない場合、前記支払処理、前記入金処理、及び前記精算処理のうちの少なくとも１つの実行を制限する第１制限手段と、
   を更に含む請求項１～８の何れかに記載の支払システム。
10. 前記支払サービスは、複数の前記事業者の各々の前記電子決済サービスと連携し、
    前記事業者ごとに、前記少なくとも１つの加盟店が定められており、
    前記第１判定手段は、前記払込票又は前記払込用番号に対応する前記加盟店が、前記支払処理に対応する前記事業者の前記少なくとも１つの加盟店であるか否かを判定し、
    前記第１制限手段は、前記支払処理に対応する前記事業者の前記少なくとも１つの加盟店であると判定されない場合、前記支払処理、前記入金処理、及び前記精算処理のうちの少なくとも１つの実行を制限する、
    請求項９に記載の支払システム。
11. 前記支払サービスは、複数の前記事業者の各々の前記電子決済サービスと連携し、
    前記支払サービスに関する複数の加盟店の各々は、前記複数の事業者の少なくとも１つの事業者に対応可能であり、
    前記支払システムは、
    前記支払処理に対応する前記事業者が、前記払込票又は前記払込用番号に対応する前記加盟店の前記少なくとも１つの事業者であるか否かを判定する第２判定手段と、
    前記払込票又は前記払込用番号に対応する前記加盟店の前記少なくとも１つの事業者であると判定されない場合、前記支払処理、前記入金処理、及び前記精算処理のうちの少なくとも１つの実行を制限する第２制限手段と、
    を更に含む請求項１～１０の何れかに記載の支払システム。
12. 前記支払システムは、前記ユーザ端末から、前記払込票が読み取られた場合又は前記払込用番号が入力された場合に実行された認証処理の実行結果を取得する実行結果取得手段を更に含み、
    前記支払処理実行手段は、前記認証処理の実行結果に基づいて、前記支払処理を実行する、
    請求項１～１１の何れかに記載の支払システム。
13. ユーザ端末により読み取られた払込票、又は、ユーザ端末に入力された払込用番号に基づいて、前記ユーザ端末から利用可能な電子決済サービスを利用した支払処理を実行する支払処理実行ステップと、
    前記支払処理が実行された場合に、前記電子決済サービスを提供する事業者から、前記払込票又は前記払込用番号を利用した支払サービスを提供する金融機関への入金処理を実行する入金処理実行ステップと、
    前記入金処理が実行された場合に、前記金融機関から精算先への精算処理を実行する精算処理実行ステップと、
    を含む支払方法。
14. ユーザ端末により読み取られた払込票、又は、ユーザ端末に入力された払込用番号に基づいて、前記ユーザ端末から利用可能な電子決済サービスを利用した支払処理を実行する支払処理実行手段、
    前記支払処理が実行された場合に、前記電子決済サービスを提供する事業者から、前記払込票又は前記払込用番号を利用した支払サービスを提供する金融機関への入金処理を実行する入金処理実行手段、
    前記入金処理が実行された場合に、前記金融機関から精算先への精算処理を実行する精算処理実行手段、
    としてコンピュータを機能させるためのプログラム。

Images