特許 6857205 決済管理装置、決済管理方法および端末

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

(12)【公報種別】特許公報(B2)

(11)【特許番号】6857205

(24)【登録日】2021年3月23日

(45)【発行日】2021年4月14日

(54)【発明の名称】決済管理装置、決済管理方法および端末

(51)【国際特許分類】

   G06Q 20/42 20120101AFI20210405BHJP

   G06Q 30/06 20120101ALI20210405BHJP

【ＦＩ】

   G06Q20/42

   G06Q30/06

【請求項の数】12

【全頁数】19

(21)【出願番号】特願2019-73056(P2019-73056)

(22)【出願日】2019年4月5日

(65)【公開番号】特開2020-170472(P2020-170472A)

(43)【公開日】2020年10月15日

【審査請求日】2019年4月5日

(73)【特許権者】

【識別番号】500011528

【氏名又は名称】株式会社岩手銀行

(73)【特許権者】

【識別番号】000004237

【氏名又は名称】日本電気株式会社

(74)【代理人】

【識別番号】100076428

【弁理士】

【氏名又は名称】大塚 康徳

(74)【代理人】

【識別番号】100115071

【弁理士】

【氏名又は名称】大塚 康弘

(74)【代理人】

【識別番号】100112508

【弁理士】

【氏名又は名称】高柳 司郎

(74)【代理人】

【識別番号】100116894

【弁理士】

【氏名又は名称】木村 秀二

(74)【代理人】

【識別番号】100130409

【弁理士】

【氏名又は名称】下山 治

(74)【代理人】

【識別番号】100134175

【弁理士】

【氏名又は名称】永川 行光

(74)【代理人】

【識別番号】100199277

【弁理士】

【氏名又は名称】西守 有人

(72)【発明者】

【氏名】関村 淳哉

(72)【発明者】

【氏名】伊藤 幸太

(72)【発明者】

【氏名】齊藤 俊幸

(72)【発明者】

【氏名】矢澤 賢一郎

(72)【発明者】

【氏名】関 陽子

(72)【発明者】

【氏名】シャキヤ ラビン

(72)【発明者】

【氏名】伊藤 明美

(72)【発明者】

【氏名】鈴木 遼一

(72)【発明者】

【氏名】馬場 真一郎

(72)【発明者】

【氏名】須藤 圭輔

【審査官】 加内 慎也

(56)【参考文献】

【文献】 特開２００５−２２２２４３（ＪＰ，Ａ）

【文献】 特開２０１５−０３９２３３（ＪＰ，Ａ）

【文献】 特開２００２−０６３５３２（ＪＰ，Ａ）

【文献】 特開２００６−０４０２９９（ＪＰ，Ａ）

【文献】 国際公開第２０１６／００９７２２（ＷＯ，Ａ１）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｑ１０／００−９９／００

(57)【特許請求の範囲】

【請求項1】

取引の金額と取引の状況とを示す決済要求を取得する手段と、
取得された決済要求が示す取引の金額と取引の状況とに応じて、支払い側に決済の承認を要求するか否かを判定する手段と、
要求すると判定された場合、支払い側の端末にネットワークを介して承認を要求する手段と、
前記支払い側の端末において決済が承認されると、当該決済を実行する手段と、を備え、
決済要求は、取引の状況として、当該取引における支払い側の端末と支払われる側の端末との間の情報のやりとりの方式を特定する情報を含む決済管理装置。

【請求項2】

前記判定する手段は、取引の状況に対応するしきい値と取引の金額との大小関係に応じて承認を要求するか否かを判定する請求項１に記載の決済管理装置。

【請求項3】

決済要求は、取引の状況として、当該取引において支払われる側を特定する情報を含む請求項１または２に記載の決済管理装置。

【請求項4】

決済要求は、取引の状況として、当該取引における支払い側の端末と支払われる側の端末との間の情報のやりとりの方式を特定する第１情報と、当該取引において支払われる側を特定する第２情報と、を含み、
前記判定する手段は、決済要求の第１情報で特定されるやりとりの方式と、当該決済要求の第２情報で特定される支払われる側の信用の度合いと、により定まるしきい値を、当該決済要求が示す取引の金額が上回る場合、承認を要求すると判定する請求項１に記載の決済管理装置。

【請求項5】

やりとりの方式は、アンテナ間の通信による方式と、撮像による方式と、を含み、
前記判定する手段におけるしきい値は、アンテナ間の通信による方式よりも撮像による方式のほうが大きくなるように、かつ、支払われる側の信用の度合いが高いほど大きくなるように、設定される請求項４に記載の決済管理装置。

【請求項6】

支払い側の端末および支払われる側の端末はいずれも携帯端末であり、いずれの携帯端末もアンテナ間の通信による方式および撮像による方式の両方に対応可能である請求項５に記載の決済管理装置。

【請求項7】

取引の金額と取引の状況とを示す決済要求を取得することと、
取得された決済要求が示す取引の金額と取引の状況とに応じて、支払い側に決済の承認を要求するか否かを判定することと、
要求すると判定された場合、支払い側の端末にネットワークを介して承認を要求することと、
前記支払い側の端末において決済が承認されると、当該決済を実行することと、を含み、
決済要求は、取引の状況として、当該取引における支払い側の端末と支払われる側の端末との間の情報のやりとりの方式を特定する情報を含む決済管理方法。

【請求項8】

取引の金額と取引の状況とを示す決済要求を取得する機能と、
取得された決済要求が示す取引の金額と取引の状況とに応じて、支払い側に決済の承認を要求するか否かを判定する機能と、
要求すると判定された場合、支払い側の端末にネットワークを介して承認を要求する機能と、
前記支払い側の端末において決済が承認されると、当該決済を実行する機能と、を決済管理装置に実現させるためのコンピュータプログラムであって、
決済要求は、取引の状況として、当該取引における支払い側の端末と支払われる側の端末との間の情報のやりとりの方式を特定する情報を含むコンピュータプログラム。

【請求項9】

取引における支払い側の端末に、
当該取引における支払い側の端末と支払われる側の端末との間の情報のやりとりの方式を、支払い側が選択可能とする機能と、
支払い側が選択した前記やりとりの方式に関する情報を支払われる側の端末に伝える機能と、
通信または画像により、支払われる側の端末に支払い側を特定する情報を伝える機能と、
請求項１から６のいずれか一項に記載の決済管理装置から、ネットワークを介して、取引に係る決済の承認の要求を受信する機能と、
受信した要求に係る決済を承認するか否かを支払い側に、音声または画像により問い合わせる機能と、
ネットワークを介して前記決済管理装置に、問い合わせの結果を示す応答を送信する機能と、を実現させるためのコンピュータプログラム。

【請求項10】

取引における支払い側の端末であって、
当該取引における支払い側の端末と支払われる側の端末との間の情報のやりとりの方式を、支払い側が選択可能とする機能と、
支払い側が選択した前記やりとりの方式に関する情報を支払われる側の端末に伝える機能と、
通信または画像により、支払われる側の端末に支払い側を特定する情報を伝える手段と、
請求項１から６のいずれか一項に記載の決済管理装置から、ネットワークを介して、取引に係る決済の承認の要求を受信する手段と、
受信した要求に係る決済を承認するか否かを支払い側に、音声または画像により問い合わせる手段と、
ネットワークを介して前記決済管理装置に、問い合わせの結果を示す応答を送信する手段と、を備える端末。

【請求項11】

取引における支払われる側の端末に、
通信または画像により、支払い側を特定する情報を取得する機能と、
ネットワークを介して請求項１から６のいずれか一項に記載の決済管理装置に、取引の金額と取引の状況とを示す決済要求を送信する機能と、
取引に係る決済の承認が前記支払い側に要求されると、承認待ちであることを支払われる側に音声または画像により通知する機能と、を実現させるためのコンピュータプログラムであって、
決済要求は、取引の状況として、当該取引における支払い側の端末と支払われる側の端末との間の情報のやりとりの方式を特定する情報を含むコンピュータプログラム。

【請求項12】

取引における支払われる側の端末であって、
通信または画像により、支払い側を特定する情報を取得する手段と、
ネットワークを介して請求項１から６のいずれか一項に記載の決済管理装置に、取引の金額と取引の状況とを示す決済要求を送信する手段と、
取引に係る決済の承認が前記支払い側に要求されると、承認待ちであることを支払われる側に音声または画像により通知する手段と、を備え、
決済要求は、取引の状況として、当該取引における支払い側の端末と支払われる側の端末との間の情報のやりとりの方式を特定する情報を含む端末。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、決済管理装置、決済管理方法および端末に関する。

【背景技術】

【0002】

数十年前まではテレホンカードなどの磁気カードを専用の装置で読み取るようなものであった電子マネーも、近年では腕時計を改札機に近づけるだけで決済が完了する時代となっている。技術の発展の貢献もあるが、やはりスマートフォンやタブレット端末などの高機能携帯機器の普及が、キャッシュレス決済の普及を力強く後押ししているようである。

【0003】

現在、様々なキャッシュレス決済のシステムが提案されている（例えば、特許文献１参照）。

【先行技術文献】

【特許文献】

【0004】

【特許文献1】特開２０１１−０４３９８３号公報

【発明の概要】

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

【0005】

決済に関する課題のひとつに、ユーザ利便性と不正リスクとの二律背反がある。特許文献１に記載されるような現在のシステムでは、それらの要素のバランスがとれているとは言えない。

【0006】

本発明はこうした課題に鑑みてなされたものであり、その目的は、ユーザ利便性の維持・向上と不正リスクの抑制とのバランスがとれたキャッシュレス決済を実現できる技術の提供にある。

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

【0007】

本発明のある態様は、決済管理装置に関する。この決済管理装置は、取引の金額と取引の状況とを示す決済要求を取得する手段と、取得された決済要求が示す取引の金額と取引の状況とに応じて、支払い側に決済の承認を要求するか否かを判定する手段と、要求すると判定された場合、支払い側の端末にネットワークを介して承認を要求する手段と、支払い側の端末において決済が承認されると、当該決済を実行する手段と、を備え、決済要求は、取引の状況として、当該取引における支払い側の端末と支払われる側の端末との間の情報のやりとりの方式を特定する情報を含む。

【0008】

なお、以上の構成要素の任意の組み合わせや、本発明の構成要素や表現を装置、方法、システム、コンピュータプログラム、コンピュータプログラムを格納した記録媒体などの間で相互に置換したものもまた、本発明の態様として有効である。

【発明の効果】

【0009】

本発明によれば、ユーザ利便性の維持・向上と不正リスクの抑制とのバランスがとれたキャッシュレス決済を実現できる。

【図面の簡単な説明】

【0010】

【図1】実施の形態に係る決済システムの構成を示す模式図である。

【図2】図１の決済サーバのハードウエア構成図である。

【図3】図１の決済サーバの機能および構成を示すブロック図である。

【図4】決済要求の一例を示すデータ構造図である。

【図5】図３の加盟店管理テーブルの一例を示すデータ構造図である。

【図6】図３の利用者管理テーブルの一例を示すデータ構造図である。

【図7】図３のしきい値設定テーブルの一例を示すデータ構造図である。

【図8】図３の取引管理テーブルの一例を示すデータ構造図である。

【図9】図１の決済システムにおける処理および信号の流れを示すチャートである。

【図10】店舗端末のディスプレイに表示される店舗端末待ち受け画面の代表画面図である。

【図11】利用者端末のディスプレイに表示されるＱＲコード表示画面の代表画面図である。

【図12】店舗端末のディスプレイに表示される決済承認待受中画面の代表画面図である。

【図13】利用者端末のディスプレイに表示される決済承認画面の代表画面図である。

【図14】店舗端末のディスプレイに表示される取引結果画面の代表画面図である。

【図15】利用者端末のディスプレイに表示される取引結果画面の代表画面図である。

【図16】利用者端末のディスプレイに表示される別の形態の取引結果画面の代表画面図である。

【図17】店舗端末のディスプレイに表示される取引結果画面の代表画面図である。

【図18】利用者端末のディスプレイに表示される取引結果画面の代表画面図である。

【図19】利用者端末のディスプレイに表示される別の取引結果画面の代表画面図である。

【図20】店舗端末のディスプレイに表示される第１変形例に係る決済承認画面の代表画面図である。

【図21】利用者端末のディスプレイに表示される第１変形例に係る決済承認待受中画面の代表画面図である。

【図22】店舗端末のディスプレイに表示される第３変形例に係る店舗端末待ち受け画面の代表画面図である。

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

【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】

１０ 決済サーバ、 ２０ 利用者端末、 ３０ 店舗端末、 ４０ ネットワーク。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】

【図22】