特開 2022-171342 口座払いシステム及び口座払い方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2022171342

(43)【公開日】2022-11-11

(54)【発明の名称】口座払いシステム及び口座払い方法

(51)【国際特許分類】

   G06Q 20/32 20120101AFI20221104BHJP

【ＦＩ】

G06Q20/32

【審査請求】有

【請求項の数】9

【出願形態】ＯＬ

(21)【出願番号】P 2021077932

(22)【出願日】2021-04-30

【新規性喪失の例外の表示】特許法第３０条第２項適用申請有り 令和３年１月２５日、ｈｔｔｐｓ：／／ｗｗｗ．ｒａｋｕｔｅｎ－ｂａｎｋ．ｃｏ．ｊｐ／、ｈｔｔｐｓ：／／ｗｗｗ．ｒａｋｕｔｅｎ－ｂａｎｋ．ｃｏ．ｊｐ／ｐｒｅｓｓ／２０２１／２１０１２５．ｈｔｍｌ、ｈｔｔｐｓ：／／ｗｗｗ．ｒａｋｕｔｅｎ－ｂａｎｋ．ｃｏ．ｊｐ／ｇｓ／ｐａｙ／ 令和３年１月２５日、ｈｔｔｐｓ：／／ｃｏｒｐ．ｒａｋｕｔｅｎ．ｃｏ．ｊｐ／、ｈｔｔｐｓ：／／ｃｏｒｐ．ｒａｋｕｔｅｎ．ｃｏ．ｊｐ／ｎｅｗｓ／ｕｐｄａｔｅ／２０２１／０１２５＿０２．ｈｔｍｌ？ｓｃｉｄ＝ｗｉ＿ｒｐｔ＿ｔｏｐ＿ｊｐ＿０４２０１９、ｈｔｔｐｓ：／／ｐａｙ．ｒａｋｕｔｅｎ．ｃｏ．ｊｐ／、ｈｔｔｐｓ：／／ｐａｙ．ｒａｋｕｔｅｎ．ｃｏ．ｊｐ／ｇｕｉｄｅ／ｂａｎｋ＿ｐａｙｍｅｎｔ／？ｌ－ｉｄ＝ｇｕｉｄｅ＿ｒａｋｕｔｅｎ＿ｂａｎｋ 令和３年１月２５日、ｈｔｔｐｓ：／／ａｐｐｓ．ａｐｐｌｅ．ｃｏｍ／、ｈｔｔｐｓ：／／ａｐｐｓ．ａｐｐｌｅ．ｃｏｍ／ｊｐ／ａｐｐ／％Ｅ６％Ａ５％ＢＤ％Ｅ５％Ａ４％Ａ９％Ｅ３％８３％９Ａ％Ｅ３％８２％Ａ４－％Ｅ３％８１％８Ｂ％Ｅ３％８２％９３％Ｅ３％８１％９Ｆ％Ｅ３％８２％９３－％Ｅ３％８１％８Ａ％Ｅ５％ＢＥ％９７％Ｅ３％８１％ＡＡ％Ｅ３％８２％Ｂ９％Ｅ３％８３％９Ｅ％Ｅ３％８３％９Ｂ％Ｅ６％Ｂ１％ＢＡ％Ｅ６％Ｂ８％８８％Ｅ３％８２％Ａ２％Ｅ３％８３％９７％Ｅ３％８３％ＡＡ／ｉｄ１１３９７５５２２９、ｈｔｔｐｓ：／／ｐｌａｙ．ｇｏｏｇｌｅ．ｃｏｍ／、ｈｔｔｐｓ：／／ｐｌａｙ．ｇｏｏｇｌｅ．ｃｏｍ／ｓｔｏｒｅ／ａｐｐｓ／ｄｅｔａｉｌｓ？ｉｄ＝ｊｐ．ｃｏ．ｒａｋｕｔｅｎ．ｐａｙ

(71)【出願人】

【識別番号】510247995

【氏名又は名称】楽天銀行株式会社

(74)【代理人】

【識別番号】110000154

【氏名又は名称】弁理士法人はるか国際特許事務所

(72)【発明者】

【氏名】今野 俊貴

(72)【発明者】

【氏名】松田 勇作

【テーマコード（参考）】

5L055

【Ｆターム（参考）】

5L055AA64

(57)【要約】      （修正有）

【課題】口座払いにおけるセキュリティを高める口座払いシステム、口座払い方法、口座アプリ及び決済アプリを提供する。
【解決手段】口座払いシステムにおいて、ユーザ端末３０は、銀行アプリＡ１を実行し、電子決済を利用するための決済アプリＡ２からの要求に基づいて、決済アプリＡ２を利用して口座から決済金額を引き落とす口座払いを許可するための処理を実行する銀行アプリ実行部３０１と、所定の口座を利用するための銀行アプリＡ１が同じユーザ端末３０にインストールされていることを条件として許可される、決済アプリＡ２を利用して口座から決済金額を引き落とす口座払いを実行するための処理を実行する決済アプリ実行部３０２を有する。
【選択図】図６

【特許請求の範囲】

【請求項1】

所定の口座を利用するための口座アプリと、電子決済を利用するための決済アプリと、が同じユーザ端末にインストールされていることを条件として、前記決済アプリを利用して前記口座から決済金額を引き落とす口座払いを許可する許可手段と、
前記口座払いが許可された場合に、前記口座払いを実行する実行手段と、
を含む口座払いシステム。

【請求項2】

前記許可手段は、前記口座アプリ及び前記決済アプリが同じ前記ユーザ端末にインストールされており、かつ、前記口座アプリ及び前記決済アプリの両方にユーザがログインすることを条件として、前記口座払いを許可する、
請求項１に記載の口座払いシステム。

【請求項3】

前記口座払いシステムは、前記口座払いの設定時に、複数の前記口座のうち、前記ユーザが指定した前記口座に関する認証を実行する設定手段を更に含み、
前記許可手段は、前記認証が成功し、前記設定時に指定された前記口座の前記口座アプリ及び前記決済アプリが同じ前記ユーザ端末にインストールされており、かつ、前記設定時に指定された前記口座の前記口座アプリ及び前記決済アプリの両方に前記ユーザがログインすることを条件として、前記口座払いを許可する、
請求項２に記載の口座払いシステム。

【請求項4】

前記口座アプリの記憶領域には、前記口座に対応するユーザＩＤの入力を省略可能な認証方法で利用される認証用ＩＤが記録されており、
１つの前記ユーザＩＤに対して利用可能な前記認証用ＩＤは、所定数に制限されており、
前記条件に含まれる前記口座アプリへのログインは、前記認証用ＩＤを利用した前記認証方法によって行われる、
請求項２又は３に記載の口座払いシステム。

【請求項5】

前記許可手段は、前記口座払いが許可されたことを示す許可情報を発行することによって、前記口座払いを許可し、
前記実行手段は、前記口座払いが許可された場合に、前記許可情報の有効性を確認し、前記口座払いを実行する、
請求項１～４の何れかに記載の口座払いシステム。

【請求項6】

前記許可手段は、前記口座アプリに前記許可情報を送信し、
前記口座アプリは、前記許可情報を受信すると、前記決済アプリに前記許可情報を転送し、
前記決済アプリは、前記許可情報を受信すると、前記決済アプリの記憶領域に前記許可情報を記録し、
前記実行手段は、前記決済アプリの前記記憶領域に記録された前記許可情報の有効性を確認する、
請求項５に記載の口座払いシステム。

【請求項7】

前記実行手段は、前記決済アプリが起動した場合と、前記決済アプリが起動した後に前記口座払いに関する指示が行われた場合と、の少なくとも一方において、前記許可情報の有効性を確認する、
請求項５又は６に記載の口座払いシステム。

【請求項8】

前記口座払いは、前記ユーザ端末に表示されたコードに基づいて実行され、
前記指示は、前記コードを表示させるための指示である、
請求項７に記載の口座払いシステム。

【請求項9】

前記実行手段は、本人確認のための認証を更に実行し、当該認証が成功した場合に前記口座払いを実行する、
請求項１～８の何れかに記載の口座払いシステム。

【請求項10】

前記決済アプリは、複数の前記ユーザ端末の各々にインストール可能であり、
前記口座払いシステムは、前記複数のユーザ端末の各々に、同じ前記口座を利用した前記口座払いが許可されることを制限する第１制限手段、
を更に含む請求項１～９の何れかに記載の口座払いシステム。

【請求項11】

前記決済アプリは、複数のユーザＩＤの各々を利用してログイン可能であり、
前記口座払いシステムは、前記複数のユーザＩＤの各々に、同じ前記口座を利用した前記口座払いが許可されることを制限する第２制限手段、
を更に含む請求項１～１０の何れかに記載の口座払いシステム。

【請求項12】

所定の口座を利用するための口座アプリと、電子決済を利用するための決済アプリと、が同じユーザ端末にインストールされていることを条件として、前記決済アプリを利用して前記口座から決済金額を引き落とす口座払いを許可する許可ステップと、
前記口座払いが許可された場合に、前記口座払いを実行する実行ステップと、
を含む口座払い方法。

【請求項13】

所定の口座を利用するための口座アプリであって、
同じユーザ端末にインストールされた、電子決済を利用するための決済アプリからの要求に基づいて、前記決済アプリを利用して前記口座から決済金額を引き落とす口座払いを許可するための処理を実行する口座アプリ実行手段、
として前記ユーザ端末を機能させるための口座アプリ。

【請求項14】

電子決済を利用するための決済アプリであって、
所定の口座を利用するための口座アプリが同じユーザ端末にインストールされていることを条件として許可される、前記決済アプリを利用して前記口座から決済金額を引き落とす口座払いを実行するための処理を実行する決済アプリ実行手段、
として前記ユーザ端末を機能させるための決済アプリ。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、口座払いシステム、口座払い方法、口座アプリ、及び決済アプリに関する。

【背景技術】

【0002】

従来、ユーザの口座を利用して電子決済を実行する技術が知られている。例えば、特許文献１には、ユーザの口座から携帯電話の電子マネーにチャージして電子決済を実行する技術が記載されている。また例えば、特許文献２には、ユーザの口座に生体情報を関連付けておき、電子決済を実行する端末に生体情報を入力することによって、ユーザの口座から決済金額を直接的に引き落とす口座払いについて記載されている。

【先行技術文献】

【特許文献】

【0003】

【特許文献1】特開２００９－０７５９８５号公報

【特許文献2】特開２０１９－１６８９５９号公報

【発明の概要】

【発明が解決しようとする課題】

【0004】

しかしながら、特許文献１の技術では、電子マネーの利用時に残高が不足した場合、ユーザがその場でチャージの操作をしなければならないので、ユーザの利便性を十分に高めることができない。特許文献２に記載の口座払いは、ユーザの口座から決済金額が直接的に引き落とされるので、その場で急いでチャージする必要はなくなるが、直接的な引き落としという性質上、不正利用に対するセキュリティを十分に担保する必要がある。

【0005】

本開示の目的の１つは、口座払いにおけるセキュリティを高めることである。

【課題を解決するための手段】

【0006】

本開示に係る口座払いシステムは、所定の口座を利用するための口座アプリと、電子決済を利用するための決済アプリと、が同じユーザ端末にインストールされていることを条件として、前記決済アプリを利用して前記口座から決済金額を引き落とす口座払いを許可する許可手段と、前記口座払いが許可された場合に、前記口座払いを実行する実行手段と、を含む。

【発明の効果】

【0007】

本開示によれば、口座払いにおけるセキュリティが高まる。

【図面の簡単な説明】

【0008】

【図1】口座払いシステムの全体構成の一例を示す図である。

【図2】口座払いの申し込み手順の一例を示す図である。

【図3】口座払いの申し込み手順の一例を示す図である。

【図4】口座払いの申し込み手順の一例を示す図である。

【図5】口座払いの利用手順の一例を示す図である。

【図6】口座払いシステムで実現される機能を示す機能ブロック図の一例である。

【図7】銀行データベースのデータ格納例を示す図である。

【図8】決済データベースのデータ格納例を示す図である。

【図9】設定処理のフロー図の一例である。

【図10】設定処理のフロー図の一例である。

【図11】実行処理のフロー図の一例である。

【図12】実行処理のフロー図の一例である。

【図13】実行処理のフロー図の一例である。

【図14】変形例の機能ブロック図である。

【発明を実施するための形態】

【0009】

［１．口座払いシステムの全体構成］
本開示に係る口座払いシステムの実施形態の一例を説明する。図１は、口座払いシステムの全体構成の一例を示す図である。図１に示すように、口座払いシステムＳは、銀行サーバ１０、決済サーバ２０、ユーザ端末３０、及び店舗端末４０を含む。銀行サーバ１０、決済サーバ２０、ユーザ端末３０、及び店舗端末４０の各々は、インターネット等のネットワークＮに接続可能である。口座払いシステムＳは、少なくとも１つのコンピュータを含めばよく、図１の例に限られない。

【0010】

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

【0011】

決済サーバ２０は、銀行と連携する決済事業者のサーバコンピュータである。例えば、決済サーバ２０は、制御部２１、記憶部２２、及び通信部２３を含む。制御部２１、記憶部２２、及び通信部２３の物理的構成は、それぞれ制御部１１、記憶部１２、及び通信部１３と同様である。

【0012】

ユーザ端末３０は、ユーザのコンピュータである。例えば、ユーザ端末３０は、スマートフォン、タブレット端末、ウェアラブル端末、又はパーソナルコンピュータである。ユーザ端末３０は、制御部３１、記憶部３２、通信部３３、操作部３４、表示部３５、及び撮影部３６を含む。制御部３１、記憶部３２、及び通信部３３の物理的構成は、それぞれ制御部１１、記憶部１２、及び通信部１３と同様である。操作部３４は、タッチパネル等の入力デバイスである。表示部３５は、液晶ディスプレイ又は有機ＥＬディスプレイである。撮影部３６は、少なくとも１つのカメラを含む。

【0013】

店舗端末４０は、店舗のコンピュータである。例えば、店舗端末４０は、ＰＯＳ端末、スマートフォン、タブレット端末、又はパーソナルコンピュータである。店舗端末４０は、制御部４１、記憶部４２、通信部４３、操作部４４、表示部４５、及び読取部４６を含む。制御部４１、記憶部４２、通信部４３、操作部４４、及び表示部４５の物理的構成は、それぞれ制御部１１、記憶部１２、通信部１３、操作部３４、及び表示部３５と同様である。読取部４６は、バーコード又は二次元コード等のコードを読み取り可能なコードリーダ又はカメラである。

【0014】

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

【0015】

［２．口座払いシステムの概要］
本実施形態では、ユーザは、銀行に口座を開設済みである。ユーザは、ユーザ端末３０を操作して、銀行が提供するオンラインの金融サービスを利用する。金融サービス自体は、公知の種々のサービスであってよく、例えば、入出金明細の確認、残高の確認、振込、振替、又は送金等であってよい。本実施形態では、ユーザが、ユーザ端末３０にインストールされた銀行アプリから金融サービスを利用する場合を説明する。

【0016】

銀行アプリは、口座を利用するためのアプリケーションである。銀行アプリは、口座アプリの一例である。このため、銀行アプリと記載した箇所は、口座アプリと読み替えることができる。銀行以外の口座の適用例は、後述の変形例で説明する。ユーザは、銀行アプリにログインすると、自身の口座をオンラインで利用できる。例えば、銀行アプリの初期設定時に、ユーザは、予め銀行から通知されたユーザＩＤ及びパスワードを入力する。以降、このユーザＩＤ及びパスワードを、銀行ユーザＩＤ及び銀行パスワードと記載する。

【0017】

本実施形態では、銀行アプリの初期設定時に、口座に対応する銀行ユーザＩＤの入力を省略可能な認証方法の設定が行われる。以降、この認証方法を、クイックログイン認証という。クイックログイン認証では、ユーザは、銀行パスワードさえ入力すれば、銀行アプリにログインできる。クイックログイン認証では、銀行パスワードを入力する代わりに、生体認証を利用することもできる。クイックログイン認証では、ユーザ端末３０に固有の認証用ＩＤが発行され、銀行サーバ１０とユーザ端末３０の各々に記録される。認証用ＩＤを利用することによって、銀行ユーザＩＤの入力を省略できる。本実施形態では、認証用ＩＤは、原則として１台のユーザ端末３０にのみ発行される。このため、クイックログイン認証は、非常にセキュリティの高い認証方法である。

【0018】

ユーザは、決済サービスに会員登録済みである。ユーザは、ユーザ端末３０を操作して、決済事業者が提供する決済サービスを利用する。決済サービスは、所定の決済手段の電子決済を提供するサービスである。決済手段は、任意の種類であってよく、例えば、クレジットカード、デビットカード、電子マネー、電子キャッシュ、ポイント、仮想通貨、又はこれらの組み合わせであってもよい。本実施形態では、ユーザが、ユーザ端末３０にインストールされた決済アプリから決済サービスを利用する場合を説明する。

【0019】

決済アプリは、電子決済を利用するためのアプリケーションである。例えば、ユーザは、決済アプリにログインすると、現実の店舗又はオンラインで電子決済を利用できる。例えば、ユーザは、自身のユーザＩＤ及びパスワードを入力すると、決済アプリにログインできる。以降、このユーザＩＤ及びパスワードを、決済ユーザＩＤ及び決済パスワードと記載する。決済ユーザＩＤ及び決済パスワードは、会員登録時に発行されてもよいし、電子商取引サービス等の他のサービスで発行されたものが流用されてもよい。

【0020】

ユーザは、複数の決済手段のうちの何れかを、支払い元の決済手段として指定できる。本実施形態では、ユーザ端末３０の表示部３５に表示させたコードを、店舗端末４０の読取部４６で読み取ることによって、電子決済が実行される場合を説明する。電子決済の実行方法自体は、種々の手法を利用可能であり、例えば、店舗端末４０の表示部４５に表示されたコードをユーザ端末３０の撮影部３６で読み取る方法、紙等に印刷されて店舗に掲示されたコードをユーザ端末３０の撮影部３６で読み取る方法、又はユーザ端末３０に対する操作だけで完結する方法であってもよい。

【0021】

本実施形態では、ユーザは、決済アプリを利用して、ユーザの口座から決済金額を引き落とす口座払いを利用できる。口座払いは、決済事業者ではなく、銀行が運営及び提供するサービスである。口座払いでは、電子マネー等のチャージ金額がユーザの口座から引き落とされるのではなく、電子マネー等の他の決済手段を介することなく、ユーザの口座から決済金額が直接的に引き落とされる。このため、ユーザの口座は、決済手段の１つである。ユーザは、口座払いを利用するために、ユーザ端末３０を操作して口座払いの申し込みを行う。

【0022】

図２～図４は、口座払いの申し込み手順の一例を示す図である。図２に示すように、本実施形態では、銀行アプリ及び決済アプリの両方がユーザ端末３０にインストール済みなので、銀行アプリのアイコンＩ１０と、決済アプリのアイコンＩ１１と、の各々がユーザ端末３０のホーム画面Ｇ１に表示される。

【0023】

ユーザがアイコンＩ１１を選択すると、決済アプリが起動し、決済アプリのホーム画面Ｇ２が表示される。図２の例では、支払い元としてクレジットカードが選択されている。ホーム画面Ｇ２のコードＣ２０が店舗端末４０の読取部４６によって読み取られると、支払い元として指定されたクレジットカードを利用した電子決済が実行される。コードＣ２０には、決済サーバ２０により発行されたＩＤが含まれる。このＩＤは、決済ユーザＩＤとは異なるＩＤであり、決済アプリを識別可能な情報である。このＩＤは、一定期間（例えば、５分）のみ有効である。この期間が経過すると、このＩＤを更新する必要がある。

【0024】

ユーザがボタンＢ２１を選択すると、支払い元として設定可能な決済手段の一覧を示す設定画面Ｇ３が表示される。ユーザが、口座払いに対応するエリアＡ３０を選択した後にボタンＢ３１を選択すると、口座払いの設定をするための設定画面Ｇ４が表示される。入力フォームＦ４０～Ｆ４２には、決済アプリにログイン中のユーザが予め決済サーバ２０に登録した姓、名、及び生年月日が自動入力される。ユーザは、姓、名、及び生年月日の各々を手入力してもよい。

【0025】

ユーザがボタンＢ４３を選択すると、図３に移り、銀行の第１認証ページＰ４４が口座払いの設定画面Ｇ４に表示される。第１認証ページＰ４４は、いわゆるウェブビューの画面である。見た目上は、決済アプリの画面として表示されるが、第１認証ページＰ４４の部分はブラウザを利用して表示される。第１認証ページＰ４４上で入力された情報は、銀行サーバ１０に対して送信され、決済サーバ２０を含む決済事業者側には送信されない。これらの点は、後述の第２認証ページＰ４５及び第３認証ページＰ４６も同様である。

【0026】

図３に示すように、ユーザの口座に対応する銀行ユーザＩＤ及び銀行パスワードの入力が促される。ユーザが、入力フォームＦ４４０，Ｆ４４１に銀行ユーザＩＤ及び銀行パスワードを入力した後にボタンＢ４４２を選択すると、銀行ユーザＩＤ及び銀行パスワードに基づく認証が実行される。この認証の際に、入力フォームＦ４０～Ｆ４２に入力された氏名及び生年月日と、銀行サーバ１０に登録された氏名及び生年月日と、の一致が判定されてもよい。

【0027】

銀行ユーザＩＤ及び銀行パスワードに基づく認証が成功すると、本人確認のために、口座の支店名（支店番号）及び口座番号を入力するための第２認証ページＰ４５が設定画面Ｇ４に表示される。ユーザが、入力フォームＦ４５０，Ｆ４５１に支店名及び口座番号を入力した後にボタンＢ４５２を選択すると、支店名及び口座番号に基づく認証が実行される。

【0028】

支店名及び口座番号に基づく認証が成功すると、ワンタイムキーと口座の暗証番号を入力するための第３認証ページＰ４６が設定画面Ｇ４に表示される。ユーザが、ボタンＢ４６０を選択すると、ユーザのメールアドレスにワンタイムキーが送信される。ユーザは、電子メールに記載されたワンタイムキーを確認し、入力フォームＦ４６１にワンタイムキーを入力する。ユーザが、入力フォームＦ４６２に暗証番号を入力してボタンＢ４６３を選択すると、ワンタイムキー及び暗証番号に基づく認証が実行される。

【0029】

ワンタイムキー及び暗証番号に基づく認証が成功すると、図４に移り、ウェブビューの第３認証ページＰ４６が閉じられて、銀行アプリからの認証を促すダイアログＤ４７が設定画面Ｇ４に表示される。ユーザがボタンＢ４７０を選択すると、銀行アプリが起動し、クイックログイン認証をするための認証画面Ｇ５が表示される。認証画面Ｇ５が表示されるまでは、銀行アプリは起動しておらず、銀行アプリへのログインも行われていない。図３の第１認証ページＰ４４～第３認証ページＰ４６における認証は、銀行アプリへのログインではなく、銀行アプリを介して行われない銀行サーバ１０への直接的なログインである。

【0030】

銀行アプリがインストールされていない場合には、銀行アプリのインストールが促される。銀行アプリをインストールしていなければ、以降の手順に進むことはできない。認証画面Ｇ５では、銀行ユーザＩＤが表示されず、銀行ユーザＩＤの入力フォームも表示されない。ユーザが、入力フォームＦ５０に銀行パスワードを入力してボタンＢ５１を選択すると、クイックログイン認証が実行される。

【0031】

本実施形態では、クイックログイン認証が成功すると、口座払いの実行に必要なトークンが発行される。トークンは、銀行アプリ経由で決済アプリの記憶領域に記録される。例えば、トークンは、決済アプリの一部として記録される。その後、銀行アプリが閉じられて決済アプリの支払い元の設定画面Ｇ３に戻り、支払い元が変更されたことを示すダイアログＤ３２が表示される。ユーザが、ボタンＢ３２０を選択すると、決済アプリのホーム画面Ｇ２に戻り、口座払いの実行時における認証方法を選択するためのダイアログＤ２２が表示される。

【0032】

本実施形態では、口座払いの実行時における認証方法として、生体認証及び暗証番号認証の２つが用意されている。ユーザは、ボタンＢ２２０により生体認証を選択できる。ユーザは、ボタンＢ２２１により暗証番号認証を選択できる。ユーザが、ボタンＢ２２０又はボタンＢ２２１を選択すると、口座払いの全ての設定が完了する。以降、ユーザは、ユーザ端末３０にコードを表示させて口座払いを利用できる。

【0033】

図５は、口座払いの利用手順の一例を示す図である。図５に示すように、支払い元が口座払いに変更されると、決済アプリのホーム画面Ｇ２には、後述のコードＣ２５の表示を促すメッセージＭ２２が表示される。この時点では、コードＣ２５は表示されない。ユーザが、コードを表示させるためにタップ等の操作をすると、図４のダイアログＤ２２から選択された認証方法の認証が実行される。

【0034】

ユーザが暗証番号認証を選択した場合には、暗証番号の入力を促すダイアログＤ２３がホーム画面Ｇ２に表示される。ユーザが、入力フォームＦ２３０に暗証番号を入力してボタンＢ２３１を選択すると、銀行サーバ１０との間で暗証番号認証が実行される。暗証番号認証が成功すると、口座払いを実行するためのコードＣ２５がホーム画面Ｇ２に表示される。口座払いのコードＣ２５に含まれる情報の種類は、クレジットカード払いのコードＣ２０と同様である。

【0035】

ユーザが生体認証を選択した場合には、銀行サーバ１０との間で生体認証を実行中であることを示すダイアログＤ２４がホーム画面Ｇ２に表示される。図５では、顔認証を例に挙げるが、生体認証自体は、指紋認証等の他の方法も利用可能である。生体認証では、ユーザ端末３０の機能が利用されてもよいが、最終的な確認は銀行サーバ１０によって行われる。生体認証が成功すると、口座払いを実行するためのコードＣ２５がホーム画面Ｇ２に表示される。

【0036】

ユーザは、ホーム画面Ｇ２にコードＣ２５を表示させると、店員にコードＣ２５を提示する。店員が店舗端末４０の読取部４６でコードＣ２５を読み取ると、銀行サーバ１０が主体となる処理によって、ユーザの口座から決済金額が引き落とされる。ユーザ端末３０及び店舗端末４０の各々には、口座払いが完了した旨が表示される。

【0037】

以上のように、本実施形態の口座払いシステムＳでは、口座払いを実行するための条件として、銀行アプリ及び決済アプリの両方がユーザ端末３０にインストールされていること、口座払いの申し込み時の各認証を成功させること、及び口座払い直前の認証を成功させることといった種々の条件が存在する。これにより、口座払いにおけるセキュリティが高まる。以降、口座払いシステムＳの詳細について説明する。

【0038】

［３．口座払いシステムで実現される機能］
図６は、口座払いシステムＳで実現される機能を示す機能ブロック図の一例である。本実施形態では、口座払いは、銀行により運営及び提供されるサービスなので、主な機能が銀行サーバ１０によって実現される場合を説明する。なお、店舗端末４０は、コードＣ２５を読み取る機能と、口座払いに必要な情報を決済サーバ２０に送信する機能と、を含めばよいので、図６では省略する。

【0039】

［３－１．銀行サーバにおいて実現される機能］
図６に示すように、銀行サーバ１０では、データ記憶部１００、設定部１０１、許可部１０２、及び実行部１０３が実現される。データ記憶部１００は記憶部１２を主として実現され、他の各機能は制御部１１を主として実現される。

【0040】

［データ記憶部］
データ記憶部１００は、口座払いを実現するために必要なデータを記憶する。ここでは、データ記憶部１００が記憶するデータの一例として、銀行データベースＤＢ１を説明する。

【0041】

図７は、銀行データベースＤＢ１のデータ格納例を示す図である。図７に示すように、銀行データベースＤＢ１は、銀行に開設された口座に関する情報が格納されたデータベースである。例えば、銀行データベースＤＢ１には、銀行ユーザＩＤ、銀行パスワード、氏名、生年月日、メールアドレス、支店番号、口座番号、暗証番号、ワンタイムキー情報、クイックログイン情報、及び口座払い情報が格納される。銀行データベースＤＢ１の個々のレコードは、個々の口座に対応する。

【0042】

銀行ユーザＩＤは、オンラインで金融サービスを利用するためのユーザアカウントである。銀行ユーザＩＤは、口座ごとに発行されるので、口座を一意に識別可能である。銀行パスワードは、口座へのログインに必要なパスワードである。氏名、生年月日、及びメールアドレスは、口座の開設時に登録された個人情報である。メールアドレスは、事後的に変更可能である。支店番号及び口座番号は、口座を一意に識別可能な情報である。暗証番号は、一部の金融サービスを利用する場合に必要な認証情報である。

【0043】

ワンタイムキー情報は、ユーザのメールアドレスに通知されたワンタイムキーと、このワンタイムキーの有効期限と、を含む。クイックログイン情報は、クイックログイン認証の設定に関する情報であり、例えば、クイックログイン認証の設定有無を示す情報と、クイックログイン認証で利用される認証用ＩＤと、を含む。口座払い情報は、口座払いの設定に関する情報であり、例えば、口座払いの設定有無を示す情報、口座払いの設定をしたユーザの決済ユーザＩＤ、及び口座払いが設定されてトークンＴが発行されたユーザ端末３０を識別可能な情報を含む。

【0044】

なお、銀行データベースＤＢ１には、任意の情報が格納されてよく、例えば、ユーザの住所又は電話番号といった他の個人情報、口座の残高、又は入出金明細といった情報が格納されてもよい。また、データ記憶部１００は、銀行データベースＤＢ１以外のデータを記憶してもよく、例えば、トークン認証等の各認証を実行するためのプログラム、トークンＴを発行するためのプログラム、ワンタイムキーを発行するためのプログラム、又はウェブビューとして表示される第１認証ページＰ４４～第３認証ページＰ４６のデータ（ＨＴＭＬデータ等）を記憶してもよい。

【0045】

［設定部］
設定部１０１は、口座払いの設定時に、複数の口座のうち、ユーザが指定した口座に関する認証を実行する。この複数の口座とは、銀行に開設された全ての口座を意味する。ユーザが指定した口座とは、ユーザが口座払いで利用する口座である。ユーザは、銀行ユーザＩＤと、支店名及び口座番号と、の少なくとも一方を指定することによって、口座を指定する。例えば、第１認証ページＰ４４の入力フォームＦ４４０から銀行ユーザＩＤを入力することは、口座を指定することに相当する。第２認証ページＰ４５の入力フォームＦ４５０，Ｆ４５１から支店名及び口座番号を入力することも、口座を指定することに相当する。

【0046】

口座に関する認証とは、口座に関連付けられて登録された情報に基づいて実行される認証である。この認証は、銀行アプリＡ１からのクイックログイン認証の前に実行される認証である。本実施形態では、設定部１０１は、第１認証ページＰ４４からの銀行ユーザＩＤ及び銀行パスワードに基づく認証、第２認証ページＰ４５からの支店名及び口座番号に基づく認証、第３認証ページＰ４６からのワンタイムキー認証、及び第３認証ページＰ４６からの暗証番号認証の４つの認証を実行する。設定部１０１は、これら４つの認証のうちの一部だけを実行してもよいし、生体認証や合言葉認証といった他の認証を実行してもよい。

【0047】

口座払いの設定とは、口座払いが許可されるために必要な処理を実行することである。設定部１０１は、口座払いの申し込みをしたユーザの決済ユーザＩＤ等を決済サーバ２０から取得して口座払い情報を生成し、銀行データベースＤＢ１に格納する。設定部１０１は、銀行アプリからのクイックログイン認証の前段階までに必要な処理を実行する。

【0048】

例えば、設定部１０１は、第１認証ページＰ４４の入力フォームＦ４４０からユーザが入力した銀行ユーザＩＤに基づいて、認証を実行する。設定部１０１は、銀行データベースＤＢ１を参照し、当該入力された銀行ユーザＩＤに関連付けられた銀行パスワードを取得する。設定部１０１は、当該取得された銀行パスワードと、第１認証ページＰ４４の入力フォームＦ４４１からユーザが入力した銀行パスワードと、が一致するか否かを判定する。これらが一致する場合に、認証が成功する。

【0049】

また例えば、設定部１０１は、第２認証ページＰ４５の入力フォームＦ４５０，Ｆ４５１からユーザが入力した支店名及び口座番号に基づいて、認証を実行する。設定部１０１は、当該入力された支店名及び口座番号の組み合わせが銀行データベースＤＢ１に存在するか否かを判定する。この組み合わせが存在する場合に、認証が成功する。

【0050】

また例えば、設定部１０１は、ワンタイムキーを発行して有効期限とともに銀行データベースＤＢ１に格納し、このワンタイムキーをユーザのメールアドレスに通知する。ワンタイムキーは、ＳＭＳ等の他の通知手段によって通知されてもよい。設定部１０１は、第３認証ページＰ４６の入力フォームＦ４６１からユーザが入力したワンタイムキーと、ユーザに通知されたワンタイムキーと、が一致するか否かを判定する。これらが一致し、かつ、ワンタイムキーの有効期限内である場合に、ワンタイムキー認証が成功する。

【0051】

また例えば、設定部１０１は、第３認証ページＰ４６の入力フォームＦ４６２からユーザが入力した暗証番号と、銀行データベースＤＢ１から取得された正解となる暗証番号と、が一致するか否かを判定する。正解となる暗証番号は、銀行ユーザＩＤ及び銀行パスワードに基づく認証と、支店名及び口座番号に基づく認証と、が成功した口座の暗証番号である。これらが一致する場合に、暗証番号認証は成功する。

【0052】

［許可部］
許可部１０２は、所定の口座を利用するための銀行アプリＡ１と、電子決済を利用するための決済アプリＡ２と、が同じユーザ端末３０にインストールされていることを条件として、決済アプリＡ２を利用して口座から決済金額を引き落とす口座払いを許可する。この条件は、ユーザの口座からの口座払いを許可するか否かの判定基準である。銀行アプリＡ１及び決済アプリＡ２のインストールは、条件の１つであり、本実施形態では、下記に説明するような他の条件も存在する。

【0053】

口座払いを許可するとは、口座払いの実行を許可することである。本実施形態では、口座払いに必要な設定が全て完了して、支払い元が口座払いに変更されることが、口座払いを許可することに相当する場合を説明する。他にも例えば、口座払いの実行に必要な情報（本実施形態ではトークンＴ）を発行することが、口座払いを許可することに相当してもよい。また例えば、口座払いを実行して口座の残高から決済金額を引き落とすことが、口座払いを許可することに相当してもよい。

【0054】

本実施形態では、ユーザの口座からの口座払いが許可されると、決済アプリＡ２を利用して口座払いの実行が指示された場合に、この口座からの決済金額の引き落としが可能になる。ユーザの口座からの口座払いが許可されない場合には、決済アプリＡ２を利用した口座払いの実行の指示自体ができない、又は、口座払いの実行の指示ができたとしても、口座からの決済金額の引き落としができない。

【0055】

例えば、許可部１０２は、決済アプリＡ２がインストールされているが銀行アプリＡ１がインストールされていない場合、銀行アプリＡ１がインストールされているが決済アプリＡ２がインストールされていない場合、又は銀行アプリＡ１も決済アプリＡ２もインストールされていない場合には、口座払いを許可しない。本実施形態では、支払い元の設定が完了した後は、銀行アプリＡ１を削除したとしても、トークンＴが有効である限りは、口座払いが実行可能であるものとする。トークンＴが無効になった場合には、再び許可部１０２による許可が必要になる。

【0056】

本実施形態では、許可部１０２は、銀行アプリＡ１及び決済アプリＡ２が同じユーザ端末３０にインストールされており、かつ、銀行アプリＡ１及び決済アプリＡ２の両方にユーザがログインすることを条件として、口座払いを許可する。本実施形態では、ユーザが決済アプリＡ２にログインした後に銀行アプリＡ１にログインする場合を説明するが、ユーザは、銀行アプリＡ１にログインした後に決済アプリＡ２にログインしてもよい。許可部１０２は、ユーザが決済アプリＡ２及び銀行アプリＡ１の少なくとも一方にログインしなかった場合には、銀行アプリＡ１及び決済アプリＡ２が同じユーザ端末３０にインストールされていたとしても、口座払いを許可しない。

【0057】

本実施形態では、許可部１０２は、設定部１０１の認証（先述した４つの認証）が成功し、口座払いの設定時に指定された口座の銀行アプリＡ１及び決済アプリＡ２が同じユーザ端末３０にインストールされており、かつ、口座払いの設定時に指定された口座の銀行アプリＡ１及び決済アプリＡ２の両方にユーザがログインしたことを条件として、口座払いを許可する。口座払いの設定時に指定された口座とは、設定部１０１の設定における認証で指定された口座である。例えば、この口座は、第１認証ページＰ４４の入力フォームＦ４４０に入力された銀行ユーザＩＤによって識別される口座である。即ち、この口座は、第２認証ページＰ４５の入力フォームＦ４５０，Ｆ４５１に入力された支店名及び口座番号によって識別される口座である。口座払いの設定時に指定された口座の銀行アプリＡ１とは、この口座を利用するための銀行アプリＡ１である。この銀行アプリＡ１は、この口座にログインしたことのあるアプリである。

【0058】

本実施形態では、銀行アプリＡ１の記憶領域には、クイックログイン認証で利用される認証用ＩＤが記録されている。１つの銀行ユーザＩＤに対して利用可能な認証用ＩＤは、所定数（本実施形態では１つとするが任意の数であってよい）に制限されている。許可部１０２の条件に含まれる銀行アプリＡ１へのログインは、認証用ＩＤを利用したクイックログイン認証によって行われる。即ち、銀行アプリＡ１からのクイックログイン認証によって、口座払いの設定時に指定された口座にログインすることが、口座払いが許可される条件になる。許可部１０２は、この口座へのクイックログイン認証が成功しなかった場合には、設定部１０１の設定における認証が成功しており、銀行アプリＡ１及び決済アプリＡ２が同じユーザ端末３０にインストールされており、決済アプリＡ２にログインしていたとしても、口座払いを許可しない。なお、銀行アプリＡ１へのログインでは、クイックログイン認証以外の他の認証方法（例えば、銀行ユーザＩＤ及び銀行パスワードの両方の入力が要求される認証方法）が利用されてもよい。

【0059】

本実施形態では、許可部１０２は、口座払いが許可されたことを示すトークンＴを発行することによって、口座払いを許可する。例えば、許可部１０２は、銀行アプリＡ１にトークンＴを送信する。トークンＴは、許可情報の一例である。このため、トークンＴと記載した箇所は許可情報と読み替えることができる。許可情報は、口座払いが許可された場合に発行される認証情報である。許可情報は、トークンＴに限られない。許可情報は、口座払いが許可されたことを何らか識別可能な情報であればよく、ＩＤのような情報であってもよい。許可部１０２は、口座払いが許可された時点から所定時間後の時点までを、トークンＴの有効期間として設定する。トークンＴは、原則として銀行サーバ１０に保持されない情報であるが、トークンＴが銀行サーバ１０に保持されてもよい。トークンＴの発行方法自体は、公知の方法を利用可能である。

【0060】

［実行部］
実行部１０３は、口座払いが許可された場合に、口座払いを実行する。実行部１０３は、あるユーザの口座払いにおける決済金額を、このユーザの口座から引き落とすことによって、口座払いを実行する。本実施形態では、決済金額が、店舗端末４０から決済サーバ２０を介して銀行サーバ１０に送信される場合を説明するが、決済金額は、ユーザ端末３０又は店舗端末４０から銀行サーバ１０に直接的に送信されてもよい。

【0061】

本実施形態では、実行部１０３は、口座払いが許可された場合に、トークンＴの有効性を確認し、口座払いを実行する。例えば、実行部１０３は、ユーザ端末３０に記憶されたトークンＴに基づいて、トークン認証を実行することによって、トークンＴの有効性を確認する。トークン認証自体は、公知の認証方法を利用可能である。本実施形態では、実行部１０３は、決済アプリＡ２の記憶領域に記録されたトークンＴの有効性を確認することになる。

【0062】

例えば、実行部１０３は、決済アプリＡ２が起動した場合と、決済アプリＡ２が起動した後に口座払いに関する指示が行われた場合と、の少なくとも一方において、トークンＴの有効性を確認する。本実施形態では、これらの両方の場合にトークンＴの有効性が確認されるが、何れか一方の場合のみにトークンＴの有効性が確認されてもよい。口座払いに関する指示は、口座払いを実行するための意思表示となる指示である。本実施形態では、口座払いは、ユーザ端末３０に表示されたコードＣ２５に基づいて実行されるので、この指示は、コードＣ２５を表示させるための指示である。ホーム画面Ｇ２におけるタップは、コードＣ２５の表示の指示の一例である。この指示は、任意の操作によって行われてよい。

【0063】

店舗端末４０の表示部４５に表示又は店舗に掲示されたコードをユーザ端末３０の撮影部３６で読み取ることによって口座払いが実行される場合には、口座払いに関する指示は、撮影部３６を起動させるための起動指示、又は、撮影部３６が起動してコードを読み取った後に、ユーザ端末３０に対して行われる口座払いの実行指示である。ユーザ端末３０に対するユーザの操作によって口座払いが実行される場合には、口座払いに関する指示は、ユーザ端末３０に対して行われる口座払いの実行指示である。

【0064】

例えば、実行部１０３は、本人確認のための認証を実行し、口座払いを実行する。本実施形態では、トークンＴの有効性が確認された場合（トークンＴの有効性が確認された後）に、この認証が実行される場合を説明するが、トークンＴの有効性が確認される前に、この認証が実行されてもよい。この認証が成功した場合に、口座払いが実行される。このため、この認証が成功しなかった場合には、トークンＴの有効性が確認されたとしても、口座払いは実行されない。例えば、実行部１０３は、ユーザにより選択された認証方法に基づいて認証を実行する。実行部１０３は、ユーザが暗証番号認証を選択した場合には、ダイアログＤ２３の入力フォームＦ２３０から入力された暗証番号に基づいて、暗証番号認証を実行する。実行部１０３は、ユーザが生体認証を選択した場合には、例えば撮影部３６により生成された画像に基づいて、生体認証を実行する。

【0065】

［３－２．決済サーバにおいて実現される機能］
図６に示すように、決済サーバ２０では、データ記憶部２００が実現される。データ記憶部２００は記憶部２２を主として実現される。データ記憶部２００は、口座払いを実現するために必要なデータを記憶する。ここでは、データ記憶部２００が記憶するデータの一例として、決済データベースＤＢ２を説明する。

【0066】

図８は、決済データベースＤＢ２のデータ格納例を示す図である。図８に示すように、決済データベースＤＢ２は、決済サービスの利用登録をしたユーザに関する情報が格納されたデータベースである。例えば、決済データベースＤＢ２には、決済ユーザＩＤ、決済パスワード、氏名、生年月日、メールアドレス、支払い元情報、クレジットカード情報、電子マネー情報、電子キャッシュ情報、及び口座払い情報が格納される。

【0067】

決済ユーザＩＤは、決済サービスにおけるユーザアカウントである。決済パスワードは、決済アプリＡ２へのログインに必要なパスワードである。氏名、生年月日、及びメールアドレスは、決済サービスの会員登録時に登録された個人情報である。メールアドレスは、事後的に変更可能である。支払い元情報は、支払い元として設定中の決済手段を識別可能な情報である。

【0068】

クレジットカード情報は、クレジットカード番号、クレジットカードの有効期限、及びユーザの氏名を含む。電子マネー情報は、電子マネーを一意に識別する電子マネーＩＤと、残高と、を含む。電子キャッシュ情報は、電子キャッシュを一意に識別する電子キャッシュＩＤと、残高と、を含む。口座払い情報は、口座払いで利用する口座の銀行ユーザＩＤと、この口座の支店名（支店番号）及び口座番号と、の少なくとも一方を含む。

【0069】

なお、決済データベースＤＢ２には、任意の情報が格納されてよく、例えば、コードＣ２０，Ｃ２５に含まれるＩＤ及び有効期限、又は、ユーザの住所等の他の個人情報が格納されてもよい。また、データ記憶部２００は、決済データベースＤＢ２以外のデータを記憶してもよく、例えば、認証を実行するためのプログラムを記憶してもよい。

【0070】

［３－３．ユーザ端末において実現される機能］
図６に示すように、ユーザ端末３０では、データ記憶部３００、銀行アプリ実行部３０１、及び決済アプリ実行部３０２が実現される。データ記憶部３００は記憶部３２を主として実現され、他の各機能は制御部３１を主として実現される。

【0071】

［データ記憶部］
データ記憶部３００は、口座払いを実現するために必要なデータを記憶する。例えば、データ記憶部３００は、銀行アプリＡ１、決済アプリＡ２、トークンＴ、トークンＴの有効期限、及び生体認証情報を記憶する。この生体認証情報は、生体認証時の正解となる情報である。また例えば、データ記憶部３００は、銀行アプリＡ１のクイックログイン認証の設定と、決済アプリＡ２における支払い元や認証方法の設定と、を記憶してもよい。

【0072】

［銀行アプリ実行部］
銀行アプリ実行部３０１は、銀行アプリＡ１を実行する。銀行アプリ実行部３０１は、同じユーザ端末３０にインストールされた、電子決済を利用するための決済アプリＡ２からの要求に基づいて、決済アプリＡ２を利用して口座から決済金額を引き落とす口座払いを許可するための処理を実行する。クイックログイン認証は、口座払いを許可するための処理に相当する。本実施形態では、銀行アプリＡ１は、トークンＴを受信すると、決済アプリＡ２にトークンＴを転送するので、この転送の処理も、口座払いを許可するための処理に相当する。

【0073】

［決済アプリ実行部］
決済アプリ実行部３０２は、決済アプリＡ２を実行する。決済アプリ実行部３０２は、所定の口座を利用するための銀行アプリＡ１が同じユーザ端末３０にインストールされていることを条件として許可される、決済アプリＡ２を利用して口座から決済金額を引き落とす口座払いを実行するための処理を実行する。この処理は、口座払いに必要な処理であればよく、本実施形態で決済アプリＡ２を利用して実行されるものとして説明した処理であればよい。

【0074】

例えば、ホーム画面Ｇ２と、設定画面Ｇ３，Ｇ４と、の各々を表示させる処理、又は、これらの画面から入力された情報を銀行サーバ１０又は決済サーバ２０に送信する処理は、口座払いを実行するための処理に相当する。また例えば、決済サーバ２０から一時的なＩＤを受信してホーム画面Ｇ２のコードＣ２５を表示させる処理は、口座払いを実行するための処理に相当する。本実施形態では、決済アプリＡ２は、トークンＴを受信すると、決済アプリＡ２に対応する記憶領域にトークンＴを記録するので、この処理も、口座払いを実行するための処理に相当する。

【0075】

［４．口座払いシステムで実行される処理］
次に、口座払いシステムＳで実行される処理を説明する。本実施形態では、口座払いシステムＳで実行される処理のうち、口座払いの設定をするための設定処理と、口座払いを実行するための実行処理と、について説明する。設定処理及び実行処理の各々は、各機能ブロックが実行する処理の一例である。

【0076】

［４－１．設定処理］
図９及び図１０は、設定処理のフロー図の一例である。設定処理は、制御部１１，２１，３１の各々が記憶部１２，２２，３２に記憶されたプログラムに従って動作することによって実行される。ここでは、図２を参照して説明したように、支払い元としてクレジットカード決済が選択されているものとする。

【0077】

図９に示すように、ユーザ端末３０は、ユーザ端末３０のホーム画面Ｇ１を表示部３５に表示させる（Ｓ１００）。ユーザ端末３０は、ユーザがアイコンＩ１１を選択すると決済アプリＡ２を起動させ（Ｓ１０１）、決済サーバ２０との間で認証を実行する（Ｓ１０２）。この認証では、ユーザに決済ユーザＩＤ及び決済パスワードを入力させてもよいし、決済アプリＡ２の記憶領域に記録された認証情報が利用されてもよい。決済サーバ２０は、ユーザ端末３０に対し、一定期間のみ有効なＩＤを生成して送信する（Ｓ１０３）。ユーザ端末３０は、このＩＤを受信すると、決済アプリＡ２のホーム画面Ｇ２を表示部３５に表示させる（Ｓ１０４）。Ｓ１０４では、ユーザ端末３０は、受信したＩＤをコード化し、コードＣ２０をホーム画面Ｇ２に表示させる。

【0078】

ユーザ端末３０は、ユーザがボタンＢ２１を選択すると、支払い元の設定画面Ｇ３を表示部３５に表示させる（Ｓ１０５）。ユーザ端末３０は、ユーザがエリアＡ３０を選択した後にボタンＢ３１を選択すると、口座払いの設定画面Ｇ４を表示部３５に表示させる（Ｓ１０６）。Ｓ１０６では、設定画面Ｇ４の入力フォームＦ４０～Ｆ４２に自動入力される姓、名、及び生年月日は、決済データベースＤＢ２から取得される。ユーザ端末３０は、ユーザがボタンＢ４３を選択すると、銀行サーバ１０に対し、銀行の第１認証ページＰ４４へのアクセス要求を送信する（Ｓ１０７）。

【0079】

銀行サーバ１０は、アクセス要求を受け付けると、記憶部１２に記憶された第１認証ページＰ４４のデータを送信する（Ｓ１０８）。ユーザ端末３０は、このデータを受信すると、設定画面Ｇ４に第１認証ページＰ４４を表示させる（Ｓ１０９）。ユーザ端末３０は、ユーザが入力フォームＦ４４０，Ｆ４４１に銀行ユーザＩＤ及び銀行パスワードを入力した後にボタンＢ４４２を選択すると、銀行サーバ１０との間で、銀行ユーザＩＤ及び銀行パスワードに基づく認証を実行する（Ｓ１１０）。この認証が失敗すると、本処理は終了する。

【0080】

銀行ユーザＩＤ及び銀行パスワードに基づく認証が成功すると、銀行サーバ１０は、ユーザ端末３０に対し、記憶部１２に記憶された第２認証ページＰ４５のデータを送信する（Ｓ１１１）。ユーザ端末３０は、このデータを受信すると、設定画面Ｇ４に第２認証ページＰ４５を表示させる（Ｓ１１２）。ユーザ端末３０は、ユーザが入力フォームＦ４５０，Ｆ４５１に支店名及び口座番号を入力した後にボタンＢ４５２を選択すると、銀行サーバ１０との間で、支店名及び口座番号に基づく認証を実行する（Ｓ１１３）。この認証が失敗すると、本処理は終了する。

【0081】

支店名及び口座番号に基づく認証が成功すると、銀行サーバ１０は、ユーザ端末３０に対し、記憶部１２に記憶された第３認証ページＰ４６のデータを送信する（Ｓ１１４）。図１０に移り、ユーザ端末３０は、このデータを受信すると、設定画面Ｇ４に第３認証ページＰ４６を表示させる（Ｓ１１５）。ユーザ端末３０は、ユーザがボタンＢ４６０を選択すると、銀行サーバ１０に対し、ワンタイムキーの発行要求を送信する（Ｓ１１６）。

【0082】

銀行サーバ１０は、発行要求を受信すると、ワンタイムキーを発行して銀行データベースＤＢ１に格納し、ユーザのメールアドレスにワンタイムキーを送信する（Ｓ１１７）。ユーザ端末３０は、ユーザが電子メールのワンタイムキーを確認すると、入力フォームＦ４６１に対するワンタイムキーの入力を受け付ける（Ｓ１１８）。ユーザ端末３０は、ユーザが入力フォームＦ４６２に暗証番号を入力した後にボタンＢ４６３を選択すると、銀行サーバ１０との間で、ワンタイムキー及び暗証番号に基づく認証を実行する（Ｓ１１９）。Ｓ１１９の認証が失敗すると、本処理は終了する。

【0083】

ワンタイムキー及び暗証番号に基づく認証が成功すると、銀行サーバ１０は、ユーザ端末３０に対し、口座払いの設定に必要な全ての認証が成功したことを示す成功通知を送信する（Ｓ１２０）。ユーザ端末３０は、成功通知を受信すると、第３認証ページＰ４６を閉じてダイアログＤ４７を設定画面Ｇ４に表示させる（Ｓ１２１）。ユーザ端末３０は、ユーザがボタンＢ４７０を選択すると、決済アプリＡ２をバックグラウンドに移行させて銀行アプリＡ１を起動させ（Ｓ１２２）、認証画面Ｇ５を表示部３５に表示させる（Ｓ１２３）。Ｓ１２２では、銀行アプリＡ１がインストールされていない場合には、銀行アプリＡ１のダウンロードを要求する画面が表示されて本処理は終了する。Ｓ１２３では、ユーザがクイックログイン認証の設定を済ませていない場合には、この設定を要求する画面が表示されて本処理は終了する。

【0084】

ユーザ端末３０は、ユーザが入力フォームＦ５０に銀行パスワードを入力してボタンＢ５１を選択すると、銀行サーバ１０との間で、クイックログイン認証を実行する（Ｓ１２４）。Ｓ１２４では、ユーザ端末３０は、銀行アプリＡ１の記憶領域に記録された認証用ＩＤと、ユーザが認証画面Ｇ５の入力フォームＦ５０から入力した銀行パスワードと、を銀行サーバ１０に送信する。銀行サーバ１０は、銀行データベースＤＢ１を参照し、認証用ＩＤに関連付けられた銀行パスワードと、ユーザが入力した銀行パスワードと、が一致するか否かを判定する。クイックログイン認証は、これらが一致した場合に成功する。Ｓ１２４のクイックログイン認証が失敗すると、本処理は終了する。

【0085】

クイックログイン認証が成功すると、銀行サーバ１０は、所定の発行ルールに基づいて、有効期限が設定されたトークンＴを発行してユーザ端末３０に送信する（Ｓ１２５）。ユーザ端末３０は、銀行アプリＡ１を利用してトークンＴを受信すると、銀行アプリＡ１から決済アプリＡ２にトークンＴを転送し、決済アプリＡ２の記憶領域内にトークンＴを記録する（Ｓ１２６）。ユーザ端末３０は、銀行アプリＡ１をバックグラウンドに移行又は終了して決済アプリＡ２をフォアグラウンドに戻し、ダイアログＤ３２を設定画面Ｇ３に表示させる（Ｓ１２７）。Ｓ１２７では、支払い元が口座払いに変更された旨の通知が決済サーバ２０に送信されて、ユーザの支払い元情報が更新される。

【0086】

ユーザ端末３０は、ユーザがボタンＢ３２０を選択すると、ダイアログＤ２２をホーム画面Ｇ２に表示させる（Ｓ１２８）。ユーザ端末３０は、ユーザがボタンＢ２２０又はボタンＢ２２１を選択すると、ユーザが選択した認証方法を、決済アプリＡ２の記憶領域内に記録し（Ｓ１２９）、本処理は終了する。ユーザが選択した認証方法は、銀行サーバ１０に送信されて、銀行データベースＤＢ１に格納されてもよい。

【0087】

［４－２．実行処理］
図１１～図１３は、実行処理のフロー図の一例である。実行処理は、制御部１１，２１，３１，４１の各々が記憶部１２，２２，３２，４２に記憶されたプログラムに従って動作することによって実行される。ここでは、図９及び図１０の設定処理が完了し、支払い元に口座払いが設定されているものとする。図１１に示すように、Ｓ２００～Ｓ２０２の処理は、Ｓ１００～Ｓ１０２の処理と同様である。

【0088】

Ｓ２０２の認証が成功すると、ユーザ端末３０は、銀行サーバ１０との間で、決済アプリＡ２の記憶領域に記録されたトークンＴの有効性を確認するトークン認証を実行する（Ｓ２０３）。Ｓ２０３のトークン認証は、現在日時がトークンＴの有効期限内であり、かつ、正当なトークンＴであることが確認された場合に成功する。有効期限の確認は、ユーザ端末３０によって行われてもよいし、銀行サーバ１０によって行われてもよい。トークン認証が失敗した場合には、本処理は終了する。トークン認証の実行結果は、銀行サーバ１０からユーザ端末３０に送信される。ユーザ端末３０は、銀行サーバ１０から受信したトークンＴの有効性を参照する（Ｓ２０４）。

【0089】

トークンＴが無効である場合（Ｓ２０４；Ｎ）、ユーザ端末３０は、銀行アプリＡ１のクイックログイン認証の設定があるか否かを判定する（Ｓ２０５）。クイックログイン認証の設定がないと判定された場合（Ｓ２０５；Ｎ）、本処理は終了する。この場合、ユーザは、自分で銀行アプリＡ１を起動して、クイックログイン認証の設定を行う。一方、クイックログイン認証の設定があると判定された場合（Ｓ２０５；Ｙ）、ユーザ端末３０は、決済アプリＡ２をバックグラウンドに移行して銀行アプリＡ１を起動し（Ｓ２０６）、Ｓ１２３と同様の認証画面Ｇ５を表示部３５に表示させる（Ｓ２０７）。続くＳ２０８～Ｓ２１０の処理は、Ｓ１２４～Ｓ１２６の処理と同様である。決済アプリＡ２の記憶領域にトークンＴが記録されると、Ｓ２１１の処理に移行する。

【0090】

Ｓ２０４において、トークンＴが有効である場合（Ｓ２０４；Ｙ）、ユーザ端末３０は、図５の左上の状態のホーム画面Ｇ２を表示部３５に表示させる（Ｓ２１１）。ユーザ端末３０は、ユーザがコードＣ２５を表示させるためにタップをしたか否かを判定する（Ｓ２１２）。タップをしたと判定されない場合（Ｓ２１２；Ｎ）、本処理は終了する。

【0091】

一方、タップをしたと判定された場合（Ｓ２１２；Ｙ）、図１２に移り、ユーザ端末３０は、銀行サーバ１０との間で、Ｓ２０３と同様のトークン認証を実行し（Ｓ２１３）、銀行サーバ１０から受信したトークンＴの有効性を参照する（Ｓ２１４）。トークンＴが無効である場合（Ｓ２１４；Ｎ）、Ｓ２０５～Ｓ２１０の処理と同様のＳ２１５～Ｓ２２０の処理が実行され、Ｓ２２１の処理に移行する。なお、トークン認証は、実行処理において一回だけ実行されてもよい。即ち、Ｓ２０３～Ｓ２１０及びＳ２１３～Ｓ２２０のいずれか一方が省略されてもよい。

【0092】

Ｓ２１４において、トークンＴが有効である場合（Ｓ２１４；Ｙ）、ユーザ端末３０は、銀行サーバ１０との間で、ユーザが選択した認証方法の認証を実行する（Ｓ２２１）。Ｓ２２１では、ユーザが暗証番号認証を選択した場合には、ユーザ端末３０は、銀行サーバ１０に対し、ユーザを識別可能な情報と、ユーザが入力フォームＦ２３０に入力した暗証番号と、を送信する。ユーザが入力した暗証番号と、ユーザに対応するレコードの暗証番号と、が一致した場合に、暗証番号認証が成功する。ユーザが生体認証を選択した場合には、ユーザ端末３０は、ＯＳの機能を利用して顔認証等の生体認証を実行し、銀行サーバ１０に対し、認証結果を送信する。銀行サーバ１０は、認証結果を受信すると、ユーザ端末３０に対し、認証結果を確認した旨の通知を送信する。

【0093】

Ｓ２２１における認証が成功すると、Ｓ１０３及びＳ１０４の処理と同様のＳ２２２及びＳ２２３の処理が実行されて、コードＣ２５がホーム画面Ｇ２に表示される。図１３に移り、ユーザは、店舗の店員にコードＣ２５を見せる。店舗端末４０は、読取部４６によってコードＣ２５を読み取ると（Ｓ２２４）、決済サーバ２０に対し、コードＣ２５から抽出された情報と、決済金額等の情報と、を含む決済要求を送信する（Ｓ２２５）。

【0094】

決済サーバ２０は、決済要求を受信すると、銀行サーバ１０に対し、口座払いの実行要求を送信する（Ｓ２２６）。銀行サーバ１０は、実行要求を受信すると、口座払いを実行し（Ｓ２２７）、決済サーバ２０に対し、口座払いの実行結果を送信する（Ｓ２２８）。決済サーバ２０は、口座払いの実行結果を受信すると、ユーザ端末３０及び店舗端末４０の各々に対し、口座払いの実行結果を送信する（Ｓ２２９）。ユーザ端末３０及び店舗端末４０の各々は、口座払いの実行結果を表示部３５，４５に表示させ（Ｓ２３０，Ｓ２３１）、本処理は終了する。

【0095】

本実施形態の口座払いシステムＳによれば、銀行アプリＡ１及び決済アプリＡ２が同じユーザ端末３０にインストールされていることを条件として、口座払いを許可することによって、決済アプリＡ２から銀行に所定の申し込み手続きをすれば口座払いを利用できる場合に比べて、銀行アプリＡ１のインストール（即ち、銀行アプリＡ１及び決済アプリＡ２の協働）も条件になるので、口座払いにおけるセキュリティが高まる。また、口座の残高は、電子マネー又は電子キャッシュの残高よりも多く残高不足になりにくいので、ユーザの利便性も高まる。例えば、ユーザが、電子マネー又は電子キャッシュの残高が不足してその場でチャージしたり、他の決済手段に支払い元をその場で変更したりするといった手間が発生するのを防止できる。

【0096】

また、口座払いシステムＳは、銀行アプリＡ１及び決済アプリＡ２が同じユーザ端末３０にインストールされており、かつ、銀行アプリＡ１及び決済アプリＡ２の両方にユーザがログインしたことを条件として、口座払いを許可することによって、決済アプリＡ２へのログインだけではなく、銀行アプリＡ１へのログインも条件になるので、口座払いにおけるセキュリティが更に高まる。

【0097】

また、口座払いシステムＳは、口座払いの設定時の認証が成功し、口座払いの設定時に指定された口座の銀行アプリＡ１及び決済アプリＡ２が同じユーザ端末３０にインストールされており、かつ、口座払いの設定時に指定された口座の銀行アプリＡ１及び決済アプリＡ２の両方にユーザがログインしたことを条件として、口座払いを許可することによって、口座払いの設定時に指定した口座の銀行アプリＡ１へのログインが条件になるので、口座払いにおけるセキュリティが更に高まる。例えば、ユーザ端末３０に何らかの銀行アプリＡ１がインストールされていたとしても、この銀行アプリＡ１が、口座払いの設定時に指定した口座を利用するためのものでなければ、口座払いが許可されないため、口座払いにおけるセキュリティが高まる。

【0098】

また、口座払いシステムＳは、ある１つの銀行ユーザＩＤに対して利用可能な認証用ＩＤが所定数に制限されるクイックログイン認証で銀行アプリＡ１にログインすることを、口座払いを許可するための条件にすることによって、よりセキュリティの高いクイックログイン認証が条件になるので、口座払いにおけるセキュリティが更に高まる。ユーザからしてみても、普段使い慣れているクイックログイン認証をすれば口座払いの設定が完了し、慣れていない操作をせずに済むので、ユーザの利便性が高まる。

【0099】

また、口座払いシステムＳは、トークンＴの有効性を確認し、口座払いを実行することによって、口座払いの実行時に複雑な手順が要求されなくなり、ユーザの利便性が更に高まる。また、許可部１０２により口座払いが許可された後であったとしても、実行部１０３により口座払いが実行される時にトークンＴの有効性を確認することによって、口座払いにおけるセキュリティが更に高まる。

【0100】

また、口座払いシステムＳは、銀行アプリＡ１を介して決済アプリＡ２に対応する記憶領域に記録されたトークンＴの有効性を確認することによって、銀行アプリＡ１がユーザ端末３０にインストールされていることをより確実に確認できるので、口座払いにおけるセキュリティが更に高まる。

【0101】

また、口座払いシステムＳは、決済アプリＡ２が起動した場合にトークンＴの有効性を確認することによって、ユーザが口座払いを実行する時にトークンＴが無効であることに気付き、慌ててトークンＴを再発行するといったことを防止できる。その結果、店舗の回転効率が高まる。また、口座払いシステムＳは、決済アプリＡ２が起動した後に口座払いに関する指示が行われた場合にトークンＴの有効性を確認することによって、口座払いが実行される直前にトークンＴの有効性を確認し、口座払いにおけるセキュリティが更に高まる。また、口座払いシステムＳは、トークンＴの有効性を複数回確認すれば、口座払いにおけるセキュリティが更に高まる。

【0102】

また、口座払いシステムＳは、コードＣ２５を表示させるための指示が行われた場合に、トークンＴの有効性を確認することによって、口座払いが実行される直前にトークンＴの有効性を確認し、口座払いにおけるセキュリティが更に高まる。

【0103】

また、口座払いシステムＳは、本人確認のための認証を実行し、当該認証が成功した場合に口座払いを実行することによって、銀行アプリＡ１及び決済アプリＡ２の同じユーザ端末３０へのインストールだけでなく、本人確認のための認証も必要になるので、セキュリティが更に高まる。

【0104】

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

【0105】

図１４は、変形例の機能ブロック図である。図１４に示すように、変形例では、第１制限部１０４及び第２制限部１０５が実現される。これらは、制御部１１を主として実現される。

【0106】

（１）例えば、決済アプリＡ２は、複数のユーザ端末３０の各々にインストール可能であってもよい。本変形例では、ユーザは、スマートフォンであるユーザ端末３０Ａと、タブレット端末であるユーザ端末３０Ｂと、の各々に決済アプリＡ２をインストールし、それぞれで同じ決済ユーザＩＤでログインしているものとする。支払い元が口座払い以外であれば、ユーザは、同じ決済ユーザＩＤでユーザ端末３０Ａ，３０Ｂの各々の決済アプリＡ２にログインして、クレジットカード等を利用した電子決済を実行できる。

【0107】

本変形例の口座払いシステムＳは、第１制限部１０４を含む。第１制限部１０４は、複数のユーザ端末３０の各々に、同じ口座を利用した口座払いが許可されることを制限する。例えば、第１制限部１０４は、ユーザ端末３０Ａの決済アプリＡ２の支払い元としてユーザの口座の口座払いが設定される状態と、ユーザ端末３０Ｂの決済アプリＡ２の支払い元として同じ口座の口座払いが設定される状態と、の両方が同時に成立することを制限する。

【0108】

例えば、ユーザが、ユーザ端末３０Ａから口座払いを申し込み、ユーザ端末３０ＡにトークンＴが発行されたとする。その後に、ユーザが、ユーザ端末３０Ｂから口座払いを申し込み、ユーザ端末３０ＢにトークンＴが発行されたとする。この場合、第１制限部１０４は、先に発行されたユーザ端末３０ＡのトークンＴを無効にする。これにより、ユーザ端末３０Ａからは口座払いを利用できなくなる。ユーザがユーザ端末３０Ａから口座払いを利用したい場合には、ユーザ端末３０Ａの銀行アプリＡ１から再度クイックログイン認証を実行する。この場合、第１制限部１０４は、ユーザ端末３０ＢのトークンＴを無効にする。

【0109】

変形例（１）によれば、複数のユーザ端末３０の各々に、同じ口座を利用した口座払いが許可されることを制限することによって、悪意のある第三者が自身のユーザ端末３０で口座払いを利用することを制限し、口座払いにおけるセキュリティが更に高まる。

【0110】

（２）また例えば、決済アプリＡ２は、複数の決済ユーザＩＤの各々を利用してログイン可能であってもよい。ユーザは、複数の決済ユーザＩＤを発行している。各決済ユーザＩＤには、個別にクレジットカード情報等が関連付けられており、ユーザは、好きな決済ユーザＩＤで決済アプリＡ２にログインできる。

【0111】

本変形例の口座払いシステムＳは、第２制限部１０５を含む。第２制限部１０５は、複数の決済ユーザＩＤの各々に、同じ口座を利用した口座払いが許可されることを制限する。第２制限部１０５は、第１の決済ユーザＩＤから口座払いの設定をした口座は、第２の決済ユーザＩＤから口座払いの設定が行われないように制限する。この制限には、制限期間（例えば、３０日程度）が設けられてもよい。例えば、第２制限部１０５は、制限期間が経過した後であれば、第２の決済ユーザＩＤから口座払いの設定が行われることを許可してもよい。この場合、第２制限部１０５は、第１の決済ユーザＩＤから口座払いが利用できないように制限してもよい。

【0112】

変形例（２）によれば、複数の決済ユーザＩＤの各々に、同じ口座を利用した口座払いが許可されることを制限することによって、悪意のある第三者が自身の決済ユーザＩＤで口座払いを利用することを制限し、口座払いにおけるセキュリティが更に高まる。

【0113】

（３）また例えば、上記説明した変形例を組み合わせてもよい。

【0114】

また例えば、実施形態では、トークンＴが有効である限りは、銀行アプリＡ１がユーザ端末３０から削除されたとしても、口座払いを実行できる場合を説明したが、口座払いの実行時にも銀行アプリＡ１のインストールが条件になってもよい。この場合、許可部１０２は、口座払いが実行される場合に、銀行アプリＡ１と決済アプリＡ２が同じユーザ端末３０にインストールされていることを条件として、口座払いの実行を許可すればよい。例えば、決済アプリＡ２に対応する記憶領域に記録されたトークンＴが、銀行アプリＡ１に再度転送され、銀行アプリＡ１経由で銀行サーバ１０に送信されることによって、銀行アプリＡ１のインストールが確認されてもよい。実施形態で説明した他の条件についても同様であり、許可部１０２は、口座払いの実行時に、個々の条件が満たされるか否かを判定すればよい。

【0115】

また例えば、口座払いの申し込み時には、銀行アプリＡ１と決済アプリＡ２が同じユーザ端末３０にインストールされていることは条件にならなくてもよい。この場合、第１認証ページＰ４４～第３認証ページＰ４６の各々の認証が成功すれば、口座払いが支払い元として設定されてもよい。これらの認証は、銀行アプリＡ１がインストールされていなくても成功可能である。その後に、ユーザが図５のホーム画面Ｇ２をタップ等してコードＣ２５を表示させようとした場合には、クイックログイン認証が要求される。銀行アプリＡ１がインストールされていなければ、当然のことながらクイックログイン認証は成功できない。この時点でクイックログイン認証が実行されてトークンＴが発行されてもよい。また例えば、トークンＴを利用せずに、口座払いが実行されてもよい。例えば、口座払いのたびに、銀行側で何らかの本人確認のための認証が実行されてもよい。

【0116】

また例えば、口座払いでは、銀行以外の他の口座が利用されてもよい。このため、口座アプリは、銀行アプリＡ１に限られない。例えば、他の口座は、信用金庫等の金融機関の口座であってもよい。また例えば、電子マネーや仮想通貨の口座もあるが、このような口座が口座払いで利用されてもよい。

【0117】

また例えば、口座払いは、銀行が主体となるのではなく、銀行と決済事業者の両方が運営及び提供するサービスであってもよい。この場合、銀行サーバ１０において実現されるものとして説明した機能は、決済サーバ２０及びユーザ端末３０の何れかで実現されてもよい。また例えば、各機能は、他のコンピュータで実現されてもよいし、複数のコンピュータで分担されてもよい。

【符号の説明】

【0118】

Ｓ 口座払いシステム、１０ 銀行サーバ、２０ 決済サーバ、３０ ユーザ端末、４０ 店舗端末、１１，２１，３１，４１ 制御部、１２，２２，３２，４２ 記憶部、１３，２３，３３，４３ 通信部、３４，４４ 操作部、３５，４５ 表示部、３６ 撮影部、４６ 読取部、１００，２００，３００ データ記憶部、１０１ 設定部、１０２ 許可部、１０３ 実行部、１０４ 第１制限部、１０５ 第２制限部、３０１ 銀行アプリ実行部、３０２ 決済アプリ実行部、Ｎ ネットワーク、Ｔ トークン、Ａ１ 銀行アプリ、Ａ２ 決済アプリ、Ｇ１，Ｇ２ ホーム画面、Ｇ３，Ｇ４ 設定画面、Ｇ５ 認証画面、Ａ３０ エリア、Ｃ２０，Ｃ２５ コード、Ｄ２２，Ｄ２３，Ｄ２４，Ｄ３２，Ｄ４７ ダイアログ、ＤＢ１ 銀行データベース、ＤＢ２ 決済データベース、Ｉ１０，Ｉ１１ アイコン、Ｍ２２ メッセージ、Ｐ４４ 第１認証ページ、Ｐ４５ 第２認証ページ、Ｐ４６ 第３認証ページ、Ｂ２１，Ｂ３１，Ｂ４３，Ｂ５１，Ｂ２２０，Ｂ２２１，Ｂ２３１，Ｂ３２０，Ｂ４４２，Ｂ４５２，Ｂ４６０，Ｂ４６３，Ｂ４７０ ボタン、Ｆ４０，Ｆ５０，Ｆ２３０，Ｆ４４０，Ｆ４４１，Ｆ４５０，Ｆ４６０，Ｆ４６１，Ｆ４６２ 入力フォーム。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【手続補正書】

【提出日】2022-08-19

【手続補正1】

【補正対象書類名】特許請求の範囲

【補正対象項目名】全文

【補正方法】変更

【補正の内容】

【特許請求の範囲】

【請求項1】

所定の口座を利用するための口座アプリからのログインを受け付ける第１受付手段と、
電子決済を利用するための決済アプリであって、前記決済アプリを利用して前記口座から決済金額を引き落とす口座払いの申し込みが可能な前記決済アプリからのログインを受け付ける第２受付手段と、
同じユーザ端末から前記口座アプリと前記決済アプリの両方のログインと前記申し込みを受け付けた場合に、前記口座アプリと前記決済アプリが前記ユーザ端末にインストールされていると判定し、前記口座払いが許可されたことを示す許可情報を発行し、前記許可情報の有効性の確認に必要な確認情報をデータベースに格納し、前記許可情報を前記ユーザ端末に送信することによって、前記口座払いを許可する許可手段と、
を含み、
前記ユーザ端末は、前記口座アプリを介して前記決済アプリに対応する記憶領域に、前記許可情報を記録し、
前記口座払いシステムは、前記口座払いが許可された場合に、前記口座アプリを介して前記決済アプリに対応する前記記憶領域に記録された前記許可情報と、前記データベースに格納された前記確認情報と、に基づいて、前記有効性を確認し、前記口座払いを実行する実行手段を更に含む、
口座払いシステム。

【請求項2】

前記口座払いシステムは、前記口座払いの設定時に、複数の前記口座のうち、ユーザが指定した前記口座に関する認証を実行する設定手段を更に含み、
前記許可手段は、前記認証が成功し、前記設定時に指定された前記口座の前記口座アプリ及び前記決済アプリが同じ前記ユーザ端末にインストールされている場合に、前記口座払いを許可する、
請求項１に記載の口座払いシステム。

【請求項3】

前記口座アプリの記憶領域には、前記口座に対応するユーザＩＤの入力を省略可能な認証方法で利用される認証用ＩＤが記録されており、
１つの前記ユーザＩＤに対して利用可能な前記認証用ＩＤは、所定数に制限されており、
前記口座アプリへのログインは、前記認証用ＩＤを利用した前記認証方法によって行われる、
請求項２に記載の口座払いシステム。

【請求項4】

前記実行手段は、前記決済アプリが起動した場合と、前記決済アプリが起動した後に前記口座払いに関する指示が行われた場合と、の少なくとも一方において、前記許可情報の有効性を確認する、
請求項１～３の何れかに記載の口座払いシステム。

【請求項5】

前記口座払いは、前記ユーザ端末に表示されたコードに基づいて実行され、
前記指示は、前記コードを表示させるための指示である、
請求項４に記載の口座払いシステム。

【請求項6】

前記実行手段は、本人確認のための認証を更に実行し、当該認証が成功した場合に前記口座払いを実行する、
請求項１～５の何れかに記載の口座払いシステム。

【請求項7】

前記決済アプリは、複数の前記ユーザ端末の各々にインストール可能であり、
前記口座払いシステムは、前記複数のユーザ端末の各々に、同じ前記口座を利用した前記口座払いが許可されることを制限する第１制限手段、
を更に含む請求項１～６の何れかに記載の口座払いシステム。

【請求項8】

前記決済アプリは、複数のユーザＩＤの各々を利用してログイン可能であり、
前記口座払いシステムは、前記複数のユーザＩＤの各々に、同じ前記口座を利用した前記口座払いが許可されることを制限する第２制限手段、
を更に含む請求項１～７の何れかに記載の口座払いシステム。

【請求項9】

コンピュータが、
所定の口座を利用するための口座アプリからのログインを受け付ける第１受付ステップと、
電子決済を利用するための決済アプリであって、前記決済アプリを利用して前記口座から決済金額を引き落とす口座払いの申し込みが可能な前記決済アプリからのログインを受け付ける第２受付ステップと、
同じユーザ端末から前記口座アプリと前記決済アプリの両方のログインと前記申し込みを受け付けた場合に、前記口座アプリと前記決済アプリが前記ユーザ端末にインストールされていると判定し、前記口座払いが許可されたことを示す許可情報を発行し、前記許可情報の有効性の確認に必要な確認情報をデータベースに格納し、前記許可情報を前記ユーザ端末に送信することによって、前記口座払いを許可する許可ステップと、
を実行し、
前記ユーザ端末は、前記口座アプリを介して前記決済アプリに対応する記憶領域に、前記許可情報を記録し、
前記コンピュータは、前記口座払いが許可された場合に、前記口座アプリを介して前記決済アプリに対応する前記記憶領域に記録された前記許可情報と、前記データベースに格納された前記確認情報と、に基づいて、前記有効性を確認し、前記口座払いを実行する実行ステップを更に実行する、
口座払い方法。