特許第6857205号(P6857205)IP Force 特許公報掲載プロジェクト 2015.5.11 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 株式会社岩手銀行の特許一覧
<>
  • 特許6857205-決済管理装置、決済管理方法および端末 図000002
  • 特許6857205-決済管理装置、決済管理方法および端末 図000003
  • 特許6857205-決済管理装置、決済管理方法および端末 図000004
  • 特許6857205-決済管理装置、決済管理方法および端末 図000005
  • 特許6857205-決済管理装置、決済管理方法および端末 図000006
  • 特許6857205-決済管理装置、決済管理方法および端末 図000007
  • 特許6857205-決済管理装置、決済管理方法および端末 図000008
  • 特許6857205-決済管理装置、決済管理方法および端末 図000009
  • 特許6857205-決済管理装置、決済管理方法および端末 図000010
  • 特許6857205-決済管理装置、決済管理方法および端末 図000011
  • 特許6857205-決済管理装置、決済管理方法および端末 図000012
  • 特許6857205-決済管理装置、決済管理方法および端末 図000013
  • 特許6857205-決済管理装置、決済管理方法および端末 図000014
  • 特許6857205-決済管理装置、決済管理方法および端末 図000015
  • 特許6857205-決済管理装置、決済管理方法および端末 図000016
  • 特許6857205-決済管理装置、決済管理方法および端末 図000017
  • 特許6857205-決済管理装置、決済管理方法および端末 図000018
  • 特許6857205-決済管理装置、決済管理方法および端末 図000019
  • 特許6857205-決済管理装置、決済管理方法および端末 図000020
  • 特許6857205-決済管理装置、決済管理方法および端末 図000021
  • 特許6857205-決済管理装置、決済管理方法および端末 図000022
  • 特許6857205-決済管理装置、決済管理方法および端末 図000023
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】6857205
(24)【登録日】2021年3月23日
(45)【発行日】2021年4月14日
(54)【発明の名称】決済管理装置、決済管理方法および端末
(51)【国際特許分類】
   G06Q 20/42 20120101AFI20210405BHJP
   G06Q 30/06 20120101ALI20210405BHJP
【FI】
   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)【参考文献】
【文献】 特開2005−222243(JP,A)
【文献】 特開2015−039233(JP,A)
【文献】 特開2002−063532(JP,A)
【文献】 特開2006−040299(JP,A)
【文献】 国際公開第2016/009722(WO,A1)
(58)【調査した分野】(Int.Cl.,DB名)
G06Q10/00−99/00
(57)【特許請求の範囲】
【請求項1】
取引の金額と取引の状況とを示す決済要求を取得する手段と、
取得された決済要求が示す取引の金額と取引の状況とに応じて、支払い側に決済の承認を要求するか否かを判定する手段と、
要求すると判定された場合、支払い側の端末にネットワークを介して承認を要求する手段と、
前記支払い側の端末において決済が承認されると、当該決済を実行する手段と、を備え
決済要求は、取引の状況として、当該取引における支払い側の端末と支払われる側の端末との間の情報のやりとりの方式を特定する情報を含む決済管理装置。
【請求項2】
前記判定する手段は、取引の状況に対応するしきい値と取引の金額との大小関係に応じて承認を要求するか否かを判定する請求項1に記載の決済管理装置。
【請求項3】
決済要求は、取引の状況として、当該取引において支払われる側を特定する情報を含む請求項1または2に記載の決済管理装置。
【請求項4】
決済要求は、取引の状況として、当該取引における支払い側の端末と支払われる側の端末との間の情報のやりとりの方式を特定する第1情報と、当該取引において支払われる側を特定する第2情報と、を含み、
前記判定する手段は、決済要求の第1情報で特定されるやりとりの方式と、当該決済要求の第2情報で特定される支払われる側の信用の度合いと、により定まるしきい値を、当該決済要求が示す取引の金額が上回る場合、承認を要求すると判定する請求項1に記載の決済管理装置。
【請求項5】
やりとりの方式は、アンテナ間の通信による方式と、撮像による方式と、を含み、
前記判定する手段におけるしきい値は、アンテナ間の通信による方式よりも撮像による方式のほうが大きくなるように、かつ、支払われる側の信用の度合いが高いほど大きくなるように、設定される請求項に記載の決済管理装置。
【請求項6】
支払い側の端末および支払われる側の端末はいずれも携帯端末であり、いずれの携帯端末もアンテナ間の通信による方式および撮像による方式の両方に対応可能である請求項に記載の決済管理装置。
【請求項7】
取引の金額と取引の状況とを示す決済要求を取得することと、
取得された決済要求が示す取引の金額と取引の状況とに応じて、支払い側に決済の承認を要求するか否かを判定することと、
要求すると判定された場合、支払い側の端末にネットワークを介して承認を要求することと、
前記支払い側の端末において決済が承認されると、当該決済を実行することと、を含み、
決済要求は、取引の状況として、当該取引における支払い側の端末と支払われる側の端末との間の情報のやりとりの方式を特定する情報を含む決済管理方法。
【請求項8】
取引の金額と取引の状況とを示す決済要求を取得する機能と、
取得された決済要求が示す取引の金額と取引の状況とに応じて、支払い側に決済の承認を要求するか否かを判定する機能と、
要求すると判定された場合、支払い側の端末にネットワークを介して承認を要求する機能と、
前記支払い側の端末において決済が承認されると、当該決済を実行する機能と、を決済管理装置に実現させるためのコンピュータプログラムであって、
決済要求は、取引の状況として、当該取引における支払い側の端末と支払われる側の端末との間の情報のやりとりの方式を特定する情報を含むコンピュータプログラム
【請求項9】
取引における支払い側の端末に、
当該取引における支払い側の端末と支払われる側の端末との間の情報のやりとりの方式を、支払い側が選択可能とする機能と、
支払い側が選択した前記やりとりの方式に関する情報を支払われる側の端末に伝える機能と、
通信または画像により、支払われる側の端末に支払い側を特定する情報を伝える機能と、
請求項1からのいずれか一項に記載の決済管理装置から、ネットワークを介して、取引に係る決済の承認の要求を受信する機能と、
受信した要求に係る決済を承認するか否かを支払い側に、音声または画像により問い合わせる機能と、
ネットワークを介して前記決済管理装置に、問い合わせの結果を示す応答を送信する機能と、を実現させるためのコンピュータプログラム。
【請求項10】
取引における支払い側の端末であって、
当該取引における支払い側の端末と支払われる側の端末との間の情報のやりとりの方式を、支払い側が選択可能とする機能と、
支払い側が選択した前記やりとりの方式に関する情報を支払われる側の端末に伝える機能と、
通信または画像により、支払われる側の端末に支払い側を特定する情報を伝える手段と、
請求項1からのいずれか一項に記載の決済管理装置から、ネットワークを介して、取引に係る決済の承認の要求を受信する手段と、
受信した要求に係る決済を承認するか否かを支払い側に、音声または画像により問い合わせる手段と、
ネットワークを介して前記決済管理装置に、問い合わせの結果を示す応答を送信する手段と、を備える端末。
【請求項11】
取引における支払われる側の端末に、
通信または画像により、支払い側を特定する情報を取得する機能と、
ネットワークを介して請求項1からのいずれか一項に記載の決済管理装置に、取引の金額と取引の状況とを示す決済要求を送信する機能と、
取引に係る決済の承認が前記支払い側に要求されると、承認待ちであることを支払われる側に音声または画像により通知する機能と、を実現させるためのコンピュータプログラムであって、
決済要求は、取引の状況として、当該取引における支払い側の端末と支払われる側の端末との間の情報のやりとりの方式を特定する情報を含むコンピュータプログラム
【請求項12】
取引における支払われる側の端末であって、
通信または画像により、支払い側を特定する情報を取得する手段と、
ネットワークを介して請求項1からのいずれか一項に記載の決済管理装置に、取引の金額と取引の状況とを示す決済要求を送信する手段と、
取引に係る決済の承認が前記支払い側に要求されると、承認待ちであることを支払われる側に音声または画像により通知する手段と、を備え
決済要求は、取引の状況として、当該取引における支払い側の端末と支払われる側の端末との間の情報のやりとりの方式を特定する情報を含む端末。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、決済管理装置、決済管理方法および端末に関する。
【背景技術】
【0002】
数十年前まではテレホンカードなどの磁気カードを専用の装置で読み取るようなものであった電子マネーも、近年では腕時計を改札機に近づけるだけで決済が完了する時代となっている。技術の発展の貢献もあるが、やはりスマートフォンやタブレット端末などの高機能携帯機器の普及が、キャッシュレス決済の普及を力強く後押ししているようである。
【0003】
現在、様々なキャッシュレス決済のシステムが提案されている(例えば、特許文献1参照)。
【先行技術文献】
【特許文献】
【0004】
【特許文献1】特開2011−043983号公報
【発明の概要】
【発明が解決しようとする課題】
【0005】
決済に関する課題のひとつに、ユーザ利便性と不正リスクとの二律背反がある。特許文献1に記載されるような現在のシステムでは、それらの要素のバランスがとれているとは言えない。
【0006】
本発明はこうした課題に鑑みてなされたものであり、その目的は、ユーザ利便性の維持・向上と不正リスクの抑制とのバランスがとれたキャッシュレス決済を実現できる技術の提供にある。
【課題を解決するための手段】
【0007】
本発明のある態様は、決済管理装置に関する。この決済管理装置は、取引の金額と取引の状況とを示す決済要求を取得する手段と、取得された決済要求が示す取引の金額と取引の状況とに応じて、支払い側に決済の承認を要求するか否かを判定する手段と、要求すると判定された場合、支払い側の端末にネットワークを介して承認を要求する手段と、支払い側の端末において決済が承認されると、当該決済を実行する手段と、を備え、決済要求は、取引の状況として、当該取引における支払い側の端末と支払われる側の端末との間の情報のやりとりの方式を特定する情報を含む
【0008】
なお、以上の構成要素の任意の組み合わせや、本発明の構成要素や表現を装置、方法、システム、コンピュータプログラム、コンピュータプログラムを格納した記録媒体などの間で相互に置換したものもまた、本発明の態様として有効である。
【発明の効果】
【0009】
本発明によれば、ユーザ利便性の維持・向上と不正リスクの抑制とのバランスがとれたキャッシュレス決済を実現できる。
【図面の簡単な説明】
【0010】
図1】実施の形態に係る決済システムの構成を示す模式図である。
図2図1の決済サーバのハードウエア構成図である。
図3図1の決済サーバの機能および構成を示すブロック図である。
図4】決済要求の一例を示すデータ構造図である。
図5図3の加盟店管理テーブルの一例を示すデータ構造図である。
図6図3の利用者管理テーブルの一例を示すデータ構造図である。
図7図3のしきい値設定テーブルの一例を示すデータ構造図である。
図8図3の取引管理テーブルの一例を示すデータ構造図である。
図9図1の決済システムにおける処理および信号の流れを示すチャートである。
図10】店舗端末のディスプレイに表示される店舗端末待ち受け画面の代表画面図である。
図11】利用者端末のディスプレイに表示されるQRコード表示画面の代表画面図である。
図12】店舗端末のディスプレイに表示される決済承認待受中画面の代表画面図である。
図13】利用者端末のディスプレイに表示される決済承認画面の代表画面図である。
図14】店舗端末のディスプレイに表示される取引結果画面の代表画面図である。
図15】利用者端末のディスプレイに表示される取引結果画面の代表画面図である。
図16】利用者端末のディスプレイに表示される別の形態の取引結果画面の代表画面図である。
図17】店舗端末のディスプレイに表示される取引結果画面の代表画面図である。
図18】利用者端末のディスプレイに表示される取引結果画面の代表画面図である。
図19】利用者端末のディスプレイに表示される別の取引結果画面の代表画面図である。
図20】店舗端末のディスプレイに表示される第1変形例に係る決済承認画面の代表画面図である。
図21】利用者端末のディスプレイに表示される第1変形例に係る決済承認待受中画面の代表画面図である。
図22】店舗端末のディスプレイに表示される第3変形例に係る店舗端末待ち受け画面の代表画面図である。
【発明を実施するための形態】
【0011】
以下、各図面に示される同一または同等の構成要素、部材、処理、信号には、同一の符号を付するものとし、適宜重複した説明は省略する。また、各図面において説明上重要ではない部材の一部は省略して表示する。
【0012】
(実施の形態)
図1は、実施の形態に係る決済システム1の構成を示す模式図である。決済システム1は、決済サーバ10と、利用者端末20と、店舗端末30と、を備える。決済サーバ10、利用者端末20、店舗端末30はそれぞれインターネットなどのネットワーク40に接続され、ネットワーク40を介して互いに通信可能に構成される。図1に示される構成は例示であり、利用者端末20、店舗端末30の数に制限はない。決済サーバ10は複数のサーバを含んでもよい。
【0013】
決済システム1は、利用者22と加盟店との間のキャッシュレス決済を可能とするシステムである。決済サーバ10はキャッシュレス決済のサービスを提供する事業体により管理される。利用者22、加盟店はいずれも予めサービスに利用登録を行い、端末および口座の情報をサービスに提供し、ID・パスワードの付与を受ける。利用者22は加盟店で取引を行う、例えば商品やサービスの対価を支払う際、キャッシュレス決済を希望することを加盟店店員32に伝える。このキャッシュレス決済において、利用者端末20から店舗端末30に利用者22を特定する利用者IDが通信(例えば、NFC(Near Field Communication)、Bluetooth、WiFi、IR(Infrared、赤外線)など)または画像(例えば、バーコード、QRコードなど)により伝達される。店舗端末30は取得した利用者IDに取引の金額および取引の状況を加えて決済要求を生成し、ネットワーク40を介して決済サーバ10に送信する。決済サーバ10は、決済要求を受信すると、取引の金額と取引の状況とに応じて、支払い側すなわち利用者22に決済の承認を要求するか否かを判定する。決済サーバ10は、要求すると判定したならば、ネットワーク40を介して利用者端末20に承認要求を送信し、利用者端末20は受信した承認要求に応じて利用者22に承認するか否かを問い合わせる。利用者端末20は、問い合わせの結果をネットワーク40を介して決済サーバ10に返信する。決済サーバ10は、利用者端末20において決済が承認されると、当該決済を実行し、承認されない場合には当該決済の実行を取りやめる。決済サーバ10は、決済が実行されたなら決済の結果を、実行されなかったなら決済が行われなかった旨の通知を、利用者端末20および店舗端末30に送信する。
【0014】
決済システム1では、設定している取引の金額のしきい値を超える金額を決済する場合、利用者22による決済の承認を要求する。このしきい値は、決済方式と加盟店の信用度ランクとによって異なる値とする。これにより、不正リスクを軽減しつつ利便性の維持を図ることができ、両者のバランスが保たれるキャッシュレス決済サービスを提供することができる。
【0015】
支払い側の端末である利用者端末20および支払われる側の端末である店舗端末30はいずれも携帯端末(例えば、スマートフォン、タブレット端末、ラップトップPCなど)であり、いずれの携帯端末もアンテナ間の通信により情報を伝達する方式および撮像により情報を伝達する方式の両方に対応可能に構成される。特に利用者端末20は、利用者IDをNFCにより他の端末に送受信する機能、利用者IDを符号化された形で示すQRコードをディスプレイに表示させる機能、および他の端末に表示されたQRコードをカメラなどの撮像手段により読み取る機能を有する。店舗端末30も同様の機能を有する。NFCによる通信は公知の技術を用いて実現されてもよい。QRコードによる情報の伝達は公知の技術を用いて実現されてもよい。
【0016】
利用者端末20のユーザである利用者22は、ダウンロードサイトからネットワーク40を介して決済用アプリケーションプログラム(以下、決済アプリと称す)を利用者端末20にダウンロードし、インストールする。あるいはまた、決済アプリは利用者端末20にプリインストールされていてもよい。決済アプリはキャッシュレス決済のサービスの事業体により提供される。決済アプリが利用者端末20により実行されることにより、利用者端末20は各種機能を実現する。店舗端末30についても同様に、加盟店の加盟店店員32が加盟店用の決済アプリを店舗端末30にダウンロードし、インストールする。
【0017】
図2は、図1の決済サーバ10のハードウエア構成図である。決済サーバ10は、メモリ102と、プロセッサ104と、通信インタフェース106と、ディスプレイ108と、入力インタフェース110と、を備える。これらの要素はそれぞれバス112に接続され、バス112を介して互いに通信する。
【0018】
メモリ102は、データやプログラムを記憶するための記憶領域である。データやプログラムは、メモリ102に恒久的に記憶されてもよいし、一時的に記憶されてもよい。プロセッサ104は、メモリ102に記憶されているプログラムを実行することにより、決済サーバ10の各種機能を実現する。通信インタフェース106は、決済サーバ10の外部との間でデータの送受信を行うためのインタフェースである。通信インタフェース106はネットワーク40と接続され、ネットワーク40を介して利用者端末20や店舗端末30とデータをやりとりする。ディスプレイ108は、各種情報を表示するためのデバイスである。入力インタフェース110は、決済システム1の管理者からの入力を受け付けるためのデバイスである。
【0019】
図3は、図1の決済サーバ10の機能および構成を示すブロック図である。ここに示す各ブロックは、ハードウエア的には、コンピュータのCPUをはじめとする素子や機械装置で実現でき、ソフトウエア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウエア、ソフトウエアの組合せによっていろいろなかたちで実現できることは、本明細書に触れた当業者には理解されるところである。
【0020】
決済サーバ10は、決済要求取得部114と、承認要求有無判定部116と、承認要求部118と、決済処理部120と、加盟店管理テーブル122と、利用者管理テーブル126と、しきい値設定テーブル128と、取引管理テーブル130と、を含む。
【0021】
決済要求取得部114は、利用者22と加盟店との間の取引の金額と当該取引の状況とを示す決済要求を、店舗端末30からネットワーク40を介して取得する。利用者22が加盟店で商品を購入する場合、取引の金額は商品の代金であり、利用者22が加盟店でサービスの提供を受ける場合、取引の金額はサービスの対価である。取引の金額は加盟店店員32が店舗端末30に直接入力することで取得されてもよいし、または店舗端末30と無線で接続されたPOS等の店舗装置から取得されてもよい。あるいはまた、店舗端末30が商品のICタグやバーコードを読み取ることにより、取引の金額が入力されてもよい。あるいはまた、利用者22が代金の自己申告を行う場合は、取引の金額は、利用者端末20から店舗端末30に利用者IDと併せて送信されてもよい。
【0022】
取引の状況は、利用者22と加盟店との間の取引における状況であり、例えば利用者端末20と店舗端末30との間でどのように情報のやりとりがおこなわれたか、や、どの加盟店で取引が行われたか、を含む。決済要求は、取引の状況として、当該取引における利用者端末20と店舗端末30との間の情報のやりとりの方式を特定する方式情報と、当該取引における加盟店を特定する加盟店IDと、を含む。方式情報は、例えば利用者端末20と店舗端末30との間の情報のやりとりがNFCを介して行われたかまたはQRコードを介して行われたかを示す情報である。
【0023】
図4は、決済要求の一例を示すデータ構造図である。決済要求は、加盟店IDと、取引の金額と、利用者IDと、取引を特定する取引IDと、方式情報と、その他の情報と、を含む。方式情報は、利用者IDがQRコードによって利用者端末20から店舗端末30に伝達された場合は「QR」、NFCによって伝達された場合は「NFC」となる。
【0024】
図3に戻り、承認要求有無判定部116は、決済要求取得部114によって取得された決済要求が示す取引の金額と取引の状況とに応じて、利用者22に決済の承認を要求するか否かを判定する。この判定は、取引の状況に対応するしきい値と取引の金額との大小関係に応じて行われる。この判定処理の詳細は後述する。
【0025】
承認要求部118は、承認要求有無判定部116において承認を要求すると判定された場合、利用者端末20にネットワーク40を介して承認を要求する。承認要求部118は、承認を要求するための承認要求を生成し、生成された承認要求を利用者端末20にネットワーク40を介して送信する。併せて承認要求部118は、承認を要求すると判定された場合、店舗端末30からの決済要求に対して、承認待ちであることを示す応答を店舗端末30に送信する。
【0026】
決済処理部120は、承認要求有無判定部116において承認を要求しないと判定された場合、決済を実行し、実行結果(決済額など)を利用者端末20および店舗端末30にネットワーク40を介して送信する。決済処理部120は、承認要求有無判定部116において承認を要求すると判定され、利用者端末20において決済が承認された場合、当該決済を実行し、実行結果を利用者端末20および店舗端末30に送信する。決済処理部120は、承認要求有無判定部116において承認を要求すると判定され、利用者端末20において決済が承認されなかった場合、当該決済の実行をとりやめ、決済が行われなかったことを利用者端末20および店舗端末30に通知する。
【0027】
決済処理部120における決済の処理は、利用者22の決済用口座から加盟店の決済用口座へ取引の金額を電子的に移動するための処理であり、公知の電子決済技術を用いて実現されてもよい。決済は、先払い方式による決済であっても後払い方式による決済であってもよい。利用者端末20や店舗端末30への決済が実行された旨の通知は、実際の資金の移動よりも前であってもよいし、同時であってもよいし、後であってもよい。
【0028】
図5は、図3の加盟店管理テーブル122の一例を示すデータ構造図である。加盟店管理テーブル122は、加盟店IDと、加盟店名と、加盟店の信用度ランクと、加盟店の店舗端末30を特定する情報である店舗端末30のIPアドレスと、加盟店の決済口座を特定する情報である決済口座IDと、を対応付けて保持する。店舗端末30のIPアドレスは、ネットワーク40を介して店舗端末30に情報を送信する際に店舗端末30を特定できる情報であれば、他の情報であってもよい。加盟店名と店舗端末30のIPアドレスと決済口座IDとは、加盟店がサービスに登録する際に加盟店によって入力されたものを取得するか、または店舗端末30から自動的に抽出することにより、加盟店管理テーブル122に登録される。
【0029】
信用度ランクは、加盟店の信用の度合いを示す情報であり、本例では「高」、「低」の二値で表され、ランク「高」はランク「低」よりも信用度が高いことを表す。信用度ランクは、銀行などの金融機関の審査により設定され、サービスの管理者によって加盟店管理テーブル122に登録される。あるいはまた、金融機関が融資などの他の目的で既に加盟店の信用度を判定して自己のシステムに登録している場合、そのシステムから信用度を取り込むことにより加盟店管理テーブル122の信用度ランクを自動的に設定してもよい。
【0030】
図6は、図3の利用者管理テーブル126の一例を示すデータ構造図である。利用者管理テーブル126は、利用者IDと、パスワードと、利用者名と、利用者22の利用者端末20を特定する情報である利用者端末20のIPアドレスと、利用者22の決済口座を特定する情報である決済口座IDと、を対応付けて保持する。利用者端末20のIPアドレスは、ネットワーク40を介して利用者端末20に情報を送信する際に利用者端末20を特定できる情報であれば、他の情報であってもよい。利用者名と利用者端末20のIPアドレスと決済口座IDとは、利用者22がサービスに登録する際に利用者22によって入力されたものを取得するか、または利用者端末20から自動的に抽出することにより、利用者管理テーブル126に登録される。
【0031】
図7は、図3のしきい値設定テーブル128の一例を示すデータ構造図である。しきい値設定テーブル128は、決済方式(QRコード/NFC)と加盟店の信用度ランク(高/低)との組み合わせと、金額のしきい値と、を対応付けて保持する。しきい値設定テーブル128に登録されるしきい値は、サービスの管理者によって設定、入力されてもよい。
【0032】
承認要求有無判定部116は、加盟店管理テーブル122を参照し、決済要求取得部114によって取得された決済要求に含まれる加盟店IDに対応する信用度ランクを特定する。承認要求有無判定部116は、しきい値設定テーブル128を参照し、決済要求に含まれる方式情報が示す決済方式と特定された信用度ランクとの組み合わせに対応するしきい値を決定する。承認要求有無判定部116は、決定されたしきい値を、決済要求が示す取引の金額が上回る場合、承認を要求すると判定し、そうでなければ承認を要求しないと判定する。
【0033】
例えば、加盟店の信用度ランク=「低」の店舗にて、¥10,000の決済を実行する場合、決済方式=「NFC」で実行した場合は決済の承認が必要となり、決済方式=「QRコード」で実行した場合は決済の承認が不要となる。
【0034】
図7の例では、しきい値は、NFC方式よりもQRコード方式のほうが大きくなるように、かつ、加盟店の信用度ランクが高いほど大きくなるように、設定されている。本実施の形態では店舗端末30から決済要求が送信される構成であるから、店舗端末30における不正(改ざん等)への対応がより重要である。したがって、加盟店の信用度が低いほどしきい値を小さく設定することで、不正によるリスクと利便性とのバランスをとるものである。また、NFC方式は手間が少ない分QRコード方式よりも加盟店が利用者22の同意を得ずに決済を行うことが容易であるから、NFC方式のしきい値をより小さく設定することで、やはり不正によるリスクと利便性とのバランスをとっている。
【0035】
図8は、図3の取引管理テーブル130の一例を示すデータ構造図である。取引管理テーブル130は、取引の取引IDと、取引における加盟店の加盟店IDと、取引における利用者の利用者IDと、取引の金額と、取引の日時と、取引における決済方式と、取引において承認が要求されたか否かと、要求された場合にはその承認が得られたか否かと、を対応付けて保持する。
【0036】
以上の構成による決済サーバ10の動作を説明する。
図9は、図1の決済システム1における処理および信号の流れを示すチャートである。利用者22が加盟店において商品の購入を決めると、加盟店店員32は店舗端末30に決済金額すなわち商品の代金を入力する(S902)。店舗端末30は当該取引を特定する取引IDを発行し(S904)、決済金額とQRリーダ画面とを店舗端末30のディスプレイに表示させる(S906)と共に、NFC機能を活性化する。
【0037】
図10は、店舗端末30のディスプレイ34に表示される店舗端末待ち受け画面502の代表画面図である。店舗端末30は図9のステップS906においてディスプレイ34に店舗端末待ち受け画面502を表示させる。店舗端末待ち受け画面502は、決済金額が表示される金額表示領域504と、QRリーダ画面506と、を有する。利用者22がQRコードで決済することを選択した場合、利用者端末20のディスプレイに利用者IDが符号化されたQRコードが表示される。加盟店店員32は店舗端末30のカメラで利用者端末20のディスプレイを撮像することで、このQRコードを店舗端末30に読み込ませる。または、利用者22がNFCで決済することを選択した場合、店舗端末30と利用者端末20とがNFC可能範囲に入るとすぐに、利用者端末20から店舗端末30へのNFCによる利用者IDの伝達が行われる。
【0038】
図11は、利用者端末20のディスプレイ24に表示されるQRコード表示画面の代表画面図である。利用者22が不図示の選択インタフェース等によりQRコードで決済することを選択した場合、ディスプレイ24にQRコード表示画面が表示される。QRコード表示画面に表示されるQRコード508は、利用者22の利用者IDが符号化された情報を含む。なお、選択インタフェースによりQRコードかNFCかを選択する構成に代えて、QRコードを用いる場合に決済アプリを起動し、決済アプリが起動されない場合はNFCで通信するよう構成してもよい。
【0039】
図9に戻り、QRコードをかざすか、NFC通信により(S908)、利用者IDを含む利用者情報が利用者端末20から店舗端末30に伝達される(S910)。店舗端末30は、受信した利用者IDと、加盟店の加盟店IDと、ステップS902で入力された決済金額と、ステップS904で発行した取引IDと、NFCかQRコードかを示す方式情報と、を示す決済要求を生成し、ネットワーク40を介して決済サーバ10に送信する(S912)。
【0040】
決済サーバ10は、決済要求を受信すると、決済方式のチェック、加盟店の信用度ランクチェック、および決済金額しきい値チェックを行うことにより、利用者22に承認を要求するか否かを判定する(S914)。決済サーバ10は、加盟店管理テーブル122を参照し、決済要求が示す加盟店IDからその加盟店の信用度ランクを特定する。決済サーバ10は、しきい値設定テーブル128を参照し、決済要求が示す決済方式と特定された信用度ランクとの組み合わせに対応するしきい値を決済金額しきい値として特定する。決済サーバ10は、決済要求が示す決済金額と特定された決済金額しきい値とを比較し、前者が後者よりも大きい場合、承認を要求すると判定し、そうでなければ承認を要求しないと判定する。
【0041】
ステップS914で承認を要求すると判定された場合、決済サーバ10は決済の承認が届くまで決済を保留する(S916)。決済サーバ10は合わせて、承認待ちであることを示す情報と、メッセージと、取引の内容と、を含む決済応答を生成し、ネットワーク40を介して店舗端末30に送信する(S918)。この際、決済サーバ10は加盟店管理テーブル122を参照することで店舗端末30のアドレスを特定し、特定されたアドレスに対して決済応答を送信する。店舗端末30は、ステップS918の決済応答を受信すると、決済承認待受中画面をディスプレイ34に表示させる(S920)。
【0042】
決済サーバ10はステップS916の保留処理に合わせて、承認待ちであることを示す情報と、メッセージと、取引の内容と、を含む取引結果応答を生成し、ネットワーク40を介して利用者端末20に送信する(S922)。この際、決済サーバ10は利用者管理テーブル126を参照することで利用者端末20のアドレスを特定し、特定されたアドレスに対して取引結果応答を送信する。利用者端末20は、ステップS922の取引結果応答を受信すると、決済を承認するか利用者22に問い合わせるための決済承認画面をディスプレイ24に表示させる(S924)。ステップS910で決済アプリを起動せずにNFCにより通信が行われた場合、このステップS924で決済アプリが起動される。
【0043】
図12は、店舗端末30のディスプレイ34に表示される決済承認待受中画面の代表画面図である。決済承認待受中画面には、ステップS918の決済応答に含まれるメッセージが表示される。図12の例では、メッセージはステップS914で特定された決済金額しきい値を含むが、別の例では含まなくてもよい。
【0044】
図13は、利用者端末20のディスプレイ24に表示される決済承認画面510の代表画面図である。決済承認画面510は、利用者22による承認が必要である旨を示すメッセージ512と、承認しないという意思表示を受け付けるための拒否ボタン514と、承認するという意思表示を受け付けるための承認ボタン516と、を有する。
【0045】
図9に戻り、利用者22は、決済承認画面510において拒否ボタン514または承認ボタン516のいずれかのボタンを押し下げる(例えば、タップするかクリックする)(S926)。利用者端末20は、拒否ボタン514が指定された場合は「否認」、承認ボタン516が指定された場合は「承認」、をそれぞれ示す承認結果情報を含む決済承認要求を生成し、ネットワーク40を介して決済サーバ10に送信する(S928)。
【0046】
決済サーバ10は、受信した承認結果情報が「否認」を示す場合、決済の実行を取りやめる。決済サーバ10は、受信した承認結果情報が「承認」を示す場合、決済の保留を解除する(S930)。決済サーバ10は、ステップS928で受信した決済承認要求に対して、決済を実行するか取りやめるかを示す決済承認応答を生成し、ネットワーク40を介して利用者端末20に送信する(S932)。
【0047】
決済サーバ10は、ステップS914で承認を要求しないと判定された場合、または、ステップS930で保留を解除すると、決済を処理する(S932)。例えば、決済サーバ10は、加盟店管理テーブル122を参照し、ステップS912で受信した決済要求に含まれる加盟店IDに対応する加盟店の決済口座を特定する。決済サーバ10は、利用者管理テーブル126を参照し、ステップS912で受信した決済要求に含まれる利用者IDに対応する利用者22の決済口座を特定する。決済サーバ10は、特定した利用者22の決済口座から、特定した加盟店の決済口座への、決済金額分の金銭の移動を実現するための処理を行う。この処理は、例えば振替や振込の依頼であってもよいし、振替や振込の処理そのものであってもよい。あるいはまた、当該移動を実現する任意の処理であってもよい。決済サーバ10は、合わせて、実行された取引の内容を取引管理テーブル130に登録する。
【0048】
決済サーバ10は、決済を実行したか否かを示す情報と、メッセージと、取引の内容と、を含む決済応答を生成し、ネットワーク40を介して店舗端末30に送信する(S934)。店舗端末30は、ステップS934の決済応答を受信すると、取引結果画面をディスプレイ34に表示させる(S936)。
【0049】
決済サーバ10は、決済を実行したか否かを示す情報と、メッセージと、取引の内容と、を含む取引結果応答を生成し、ネットワーク40を介して利用者端末20に送信する(S938)。利用者端末20は、ステップS938の取引結果応答を受信すると、取引結果画面をディスプレイ24に表示させる(S940)。
【0050】
図14は、店舗端末30のディスプレイ34に表示される取引結果画面の代表画面図である。この取引結果画面は、ステップS934の決済応答が決済を実行したことを示す場合に表示され、取引が完了したことを示すメッセージと、決済金額と、を含む。
【0051】
図15は、利用者端末20のディスプレイ24に表示される取引結果画面の代表画面図である。この取引結果画面は、ステップS938の決済応答が決済を実行したことを示す場合に表示され、取引が完了したことを示すメッセージと、決済金額と、を含む。
【0052】
図16は、利用者端末20のディスプレイ24に表示される別の形態の取引結果画面の代表画面図である。図16の例では、取引が完了したことがプッシュ通知の形で表示される。特に利用者端末20のディスプレイ24のプッシュ通知領域518に、取引が完了したことを示すメッセージが表示される。この場合、決済アプリが起動している必要はないので、この態様はステップS910でNFCが用いられた場合に好適である。
【0053】
図17は、店舗端末30のディスプレイ34に表示される取引結果画面の代表画面図である。この取引結果画面は、ステップS934の決済応答が決済を実行しなかったことを示す場合に表示され、承認されなかったことにより決済が実行されなかったことを示すメッセージを含む。
【0054】
図18は、利用者端末20のディスプレイ24に表示される取引結果画面の代表画面図である。この取引結果画面は、ステップS938の決済応答が決済を実行しなかったことを示す場合に表示され、決済が実行されなかったことを示すメッセージを含む。
【0055】
図19は、利用者端末20のディスプレイ24に表示される別の取引結果画面の代表画面図である。図19図18に対応するプッシュ通知の形での表示の例である。
【0056】
上述の実施の形態において、保持部の例は、ハードディスクや半導体メモリである。また、本明細書の記載に基づき、各部を、図示しないCPUや、インストールされたアプリケーションプログラムのモジュールや、システムプログラムのモジュールや、ハードディスクから読み出したデータの内容を一時的に記憶する半導体メモリなどにより実現できることは本明細書に触れた当業者には理解される。
【0057】
本実施の形態に係る決済システム1によると、取引の状況により決まるしきい値を上回る金額の決済が要求された場合、支払う側に承認を求める。また、決済の金額がしきい値に達しなければ、そのような承認は求められず、即座に決済が実行される。これにより、キャッシュレス決済の利便性の維持を図りつつ、不正のリスクを抑えることができる。
【0058】
また、本実施の形態に係る決済システム1では、決済方式が手軽で手間がかからないほどしきい値を低く設定している。したがって、利便性とリスク抑制との最適化を図ることができる。また、決済システム1では、加盟店の信用度が低いほどしきい値を低く設定している。したがって、利便性とリスク抑制との最適化を図ることができる。
【0059】
また、本実施の形態に係る決済システム1では、利用者22は、NFCを用いる場合には事前に決済アプリを起動する手間がなくなるのでよりスムーズな決済が可能となり、QRコードを用いる場合にはより高額な決済が可能となる。これにより、ユーザ利便性が高まる。
【0060】
以上、実施の形態に係る決済システム1の構成と動作について説明した。この実施の形態は例示であり、各構成要素や各処理の組み合わせにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解される。
【0061】
(第1変形例)
実施の形態では、利用者端末20を介して利用者22に承認するか否かを問い合わせる場合を説明したが、これに限られない。例えば、決済サーバ10が承認を要求すると判定した場合、店舗端末30のディスプレイ34に決済承認画面を表示させ、利用者端末20のディスプレイ24に決済承認待受中画面を表示させる構成としてもよい。
【0062】
図20は、店舗端末30のディスプレイ34に表示される第1変形例に係る決済承認画面520の代表画面図である。決済承認画面520は、図13の決済承認画面510と同様の構成を有する。加盟店店員32は店舗端末30のディスプレイ34に表示された決済承認画面520を利用者22に提示し、利用者22がいずれかのボタンをタップすることで決済の承認・否認がなされる。
【0063】
図21は、利用者端末20のディスプレイ24に表示される第1変形例に係る決済承認待受中画面の代表画面図である。利用者22はこの決済承認待受中画面を見ることで、自分が承認処理を行う必要があることを理解する。
【0064】
(第2変形例)
実施の形態では、利用者22が決済を承認したか否かの情報を利用者端末20が直接ネットワーク40を介して決済サーバ10に送信する場合を説明したが、これに限られない。例えば、利用者22が決済を承認したか否認すると、利用者端末20がその承認結果をNFCを介して店舗端末30に送信し、店舗端末30が承認結果をネットワーク40を介して決済サーバ10に送信してもよい。これは、例えば、利用者端末20がネットワーク40に接続されないがNFC機能は有している場合に適している。
【0065】
(第3変形例)
実施の形態では、店舗端末30が決済要求を決済サーバ10に送信する場合について説明したが、これに限られず、例えば利用者端末20が決済要求を生成し、ネットワーク40を介して決済サーバ10に送信してもよい。この場合、店舗端末30は、図9のステップS906に代えて、決済金額とQRコード表示画面とを含む店舗端末待ち受け画面をディスプレイ34に表示させる。
【0066】
図22は、店舗端末30のディスプレイ34に表示される第3変形例に係る店舗端末待ち受け画面522の代表画面図である。店舗端末待ち受け画面522は、決済金額が表示される金額表示領域504と、QRコードを表示するQRコード表示画面524と、を有する。QRコード表示画面524に表示されるQRコードは、加盟店の加盟店IDと、決済金額と、取引IDと、が符号化された情報を含む。
【0067】
QRコードを用いる場合、利用者22は利用者端末20のカメラで店舗端末30のディスプレイ34を撮像することで、このQRコードを利用者端末20に読み込ませる。利用者端末20は撮像したQRコードを復号することで加盟店の加盟店IDと、決済金額と、取引IDとを取得し、それに利用者IDと決済方式(=「QRコード」)を付加することで決済要求を生成する。
【0068】
NFCを用いる場合、利用者22は決済アプリを起動せずに利用者端末20を店舗端末30に近づける。利用者端末20が店舗端末30とのNFC可能範囲に入ると自動的に通信が行われ、店舗端末30から利用者端末20へ加盟店の加盟店IDと、決済金額と、取引IDとが送信される。
【0069】
(第4変形例)
実施の形態では、利用者端末20から決済サーバ10へは承認要求に対する応答が送信される場合を説明したが、これに限られない。例えば、不正リスクをさらに抑えるために、決済処理のいずれかの段階で利用者端末20から決済サーバ10に利用者ID等の取引認証用の情報を送信してもよい。決済サーバ10は、利用者端末20から直接受信した情報と、店舗端末30から受信した決済要求に含まれる情報とを突合することで、取引認証を実行する。決済サーバ10は、それらが相違する場合、決済を実行せずにエラーを返してもよい。
【0070】
例えば、図9のステップS910でNFCが用いられる場合、店舗端末30から利用者端末20へ加盟店ID、決済金額、取引IDのうちの少なくともひとつが送信されてもよい。利用者端末20は、それらの情報に利用者IDおよび決済方式(=「NFC」)を付加して取引認証用の情報を生成し、ネットワーク40を介して決済サーバ10に送信する。決済サーバ10は、利用者端末20から受信した加盟店ID、決済金額、取引ID(のうちの少なくともひとつ)、利用者ID、決済方式と、店舗端末30から受信した決済要求に含まれる対応する情報と、を比較する。決済サーバ10は、それらが全て一致する場合、決済金額のチェックを実行する等、以降の決済処理を進めるが、いずれかが相違する場合は決済の実行をとりやめ、利用者端末20および店舗端末30にエラーを返す。
なお、図9のステップS928で送信される決済承認要求に、取引認証用の情報が含められてもよい。
【0071】
(他の変形例)
実施の形態では、決済方式と加盟店の信用度ランクとの組み合わせで決済金額しきい値を定める場合について説明したが、これに限られず、例えば、決済方式または加盟店の信用度ランクのいずれか一方により決済金額しきい値を定めてもよい。
【0072】
実施の形態では、決済方式としてアンテナ間の通信による方式(例えば、NFC)および撮像による方式(例えば、QRコード)を採用したが、これに限られない。例えば、通信による方式であっても、利用者端末20で別途、声紋、光彩、静脈、指紋等の生体情報により利用者22が認証された場合とされていない場合とで細分化してもよい。例えば、決済方式として、「生体認証済み、NFC」、「生体認証なし、NFC」、「QRコード」の三種類を設けてもよい。この場合、「生体認証済み、NFC」と「信用度ランク:高」との組み合わせに対するしきい値を最も高く設定し、「QRコード」と「信用度ランク:高」との組み合わせに対するしきい値を次に高く設定してもよい。
【0073】
実施の形態では、決済承認画面を用いて利用者22に承認するか否かを問い合わせる場合を説明したが、これに限られず、例えば画面表示に代えてまたは加えて、音声により問い合わせてもよい。この場合、承認の可否も音声で受け付ける。また、決済承認待受中画面についても同様に、画面表示に代えてまたは加えて、音声により通知してもよい。この変形例は、例えば利用者端末20または店舗端末30のいずれかあるいは両方がディスプレイを有さないスピーカ型の端末である場合に好適である。
【符号の説明】
【0074】
10 決済サーバ、 20 利用者端末、 30 店舗端末、 40 ネットワーク。
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13
図14
図15
図16
図17
図18
図19
図20
図21
図22