JP6615980B2 - 決済処理システムおよび決済処理方法 - Google Patents

Description

本発明は、決済処理システムおよび決済処理方法に関する。

現在、様々な決済手段が金融機関や決済代行業者等から提供されている。例えば、従来から存在する現金の他、クレジットカード、デビットカード、およびプリペイドカードがそれにあたる。また、そうした決済手段の多様化と共に、キャッシュレス社会実現を見据えた決済高度化が推進されている。

そうした決済に関連する従来技術として、以下の技術が提案されている。すなわち、施設で購入する商品および施設で提供を受けるサービスの注文を処理する管理装置によって、通信回線を経由して前記管理装置に結合された端末装置から注文された商品およびサービスの内容を受け付ける方法において、前記端末装置から送信された前記端末装置の位置を示す位置情報を前記管理装置が受信する段階と、前記位置情報に基づいて、前記端末装置の位置から予め定める範囲に所在する施設の名称を前記端末装置上で表示するために前記管理装置が前記端末装置に送信する段階と、前記施設の名称の内の指定された施設の名称を前記端末装置から受信する段階と、前記指定された施設で販売される商品および提供されるサービスの一覧を前記端末装置上で表示するために前記管理装置が前記端末装置に送信する段階と、前記一覧から選択された商品およびサービスの名称を前記端末装置から受信し、前記管理装置の所定のメモリに記憶する段階と、から構成されることを特徴とする方法（特許文献１参照）などが提案されている。

また、クレジットカードの提示等を不要としカード決済により商品購入を可能とするシステムとして、ユーザーのスマートフォンがサーバーから得たソフトウェアを利用し、顧客情報及びカード番号等のカード情報をサーバーに送信し、サーバーが顧客情報及びカード情報をクレジットカード会社のＰＣへ送信して顧客として登録可能か否かの認証を要求し、認証が得られた場合にカード情報を抹消して顧客情報をＤＢに格納してユーザーを登録顧客とし、登録顧客のスマートフォンから顧客情報が店舗ＰＣに送信されてＰＣがサーバーに顧客情報確認を依頼し、サーバーはＰＣにカード決済承認を求め、ＰＣが承認した場合にサーバーは、登録顧客に決済ＯＫかを求め、決済ＯＫの返信を受けて各ＰＣに決済完了の連絡を送信する携帯端末機用決済システム（特許文献２参照）なども提案されている。

特開２０１４−５６５５８号公報 特開２０１５−１２２０４５号公報

キャッシュレスで迅速な決済が可能という点で、クレジットカード決済は有用である。但し、このクレジットカード決済の実行には、少なからぬ決済手数料が必要となる。

ところが、小資本の店舗等では、販売機会や顧客の喪失を懸念して、この決済手数料分を顧客への請求金額に上乗せしにくい状況がある。一方、こうした決済手数料分を顧客への請求金額に上乗せしないとすれば、店舗自身の利益を決済手数料の原資としなければならない。

そのため、小資本の店舗等では、クレジットカード決済に代表されるキャッシュレス決済を安易に導入出来ず、決済の迅速化、多様化を図ることも難しかった。

そこで本発明の目的は、迅速かつ低コストのキャッシュレス決済を可能とする技術を提供することにある。

上記課題を解決する本発明の決済処理システムは、各店舗の所在地を示す登録位置情報および当該店舗の決済口座情報と、各店舗のユーザの決済口座情報とを格納した記憶装置と、前記店舗の店舗端末から得た現在位置情報が、当該店舗の登録位置情報の示す所定領域内を示す場合、当該店舗のユーザに関して生じた決済機会に伴い、当該決済機会に対応した所定コードおよび決済情報を、前記店舗端末から得て記憶装置に格納する処理と、所定コードを含む支払要求を、所定のユーザ端末から得た場合、当該ユーザ端末から得た現在位置情報と、前記登録位置情報とに基づき、当該ユーザ端末の現在位置に所在する店舗を特定し、当該店舗に関して保持する所定コードと前記支払要求が含む所定コードとが一致する場合、当該所定コードに紐付いた決済情報と当該店舗および当該ユーザの前記決済口座情報とに基づき、当該ユーザと当該店舗の決済口座間での送金処理を勘定系システムに要求する処理とを実行する演算装置とを備えることを特徴とする。

また、本発明の決済処理方法は、各店舗の所在地を示す登録位置情報および当該店舗の決済口座情報と、各店舗のユーザの決済口座情報とを格納した記憶装置を備えた情報処理システムが、前記店舗の店舗端末から得た現在位置情報が、当該店舗の登録位置情報の示す所定領域内を示す場合、当該店舗のユーザに関して生じた決済機会に伴い、当該決済機会に対応した所定コードおよび決済情報を、前記店舗端末から得て記憶装置に格納する処理と、所定コードを含む支払要求を、所定のユーザ端末から得た場合、当該ユーザ端末から得た現在位置情報と、前記登録位置情報とに基づき、当該ユーザ端末の現在位置に所在する店舗を特定し、当該店舗に関して保持する所定コードと前記支払要求が含む所定コードとが一致する場合、当該所定コードに紐付いた決済情報と当該店舗および当該ユーザの前記決済口座情報とに基づき、当該ユーザと当該店舗の決済口座間での送金処理を勘定系システムに要求する処理とを実行することを特徴とする。

本発明によれば、迅速かつ低コストのキャッシュレス決済が可能となる。

本実施形態における決済処理システムを含むネットワーク構成図である。 本実施形態の決済処理システムのハードウェア構成例を示す図である。 本実施形態の店舗端末のハードウェア構成例を示す図である。 本実施形態のユーザ端末のハードウェア構成例を示す図である。 本実施形態の法人管理テーブルの構成例を示す図である。 本実施形態の決済期限テーブルの構成例を示す図である。 本実施形態のユーザ管理テーブルの構成例を示す図である。 本実施形態の決済情報テーブルの構成例を示す図である。 本実施形態の分割決済情報テーブルの構成例を示す図である。 本実施形態の決済処理方法のフロー例１を示す図である。 本実施形態における画面例１を示す図である。 本実施形態における画面例２を示す図である。 本実施形態の決済処理方法のフロー例２を示す図である。 本実施形態における画面例３を示す図である。 本実施形態の決済処理方法のフロー例３を示す図である。 本実施形態における画面例４を示す図である。

−−−ネットワーク構成−−−
以下に本発明の実施形態について図面を用いて詳細に説明する。図１は本実施形態の決済処理システム１００を含むネットワーク構成例を示す図である。図１に示す決済処理システム１００は、迅速かつ低コストのキャッシュレス決済を可能とするためのコンピュータシステムである。

こうした決済処理システム１００は、ネットワーク１０に接続され、店舗端末２００、ユーザ端末３００、および勘定系システム４００とデータ通信可能となっている。

このうち店舗端末２００は、何らかの決済が発生する店舗等で利用される端末である。また、ユーザ端末３００は、そうした店舗を訪れて、商品やサービスを購入する各ユーザの端末である。また、勘定系システム４００は、金融機関での勘定系業務に伴う各種処理を実行するシステムである。
−−−ハードウェア構成例−−−
また、決済処理システム１００のハードウェア構成は以下の如くとなる。決済処理システム１００は、ハードディスクドライブなど適宜な不揮発性記憶素子で構成される記憶装置１０１、ＲＡＭなど揮発性記憶素子で構成されるメモリ１０３、記憶装置１０１に保持されるプログラム１０２をメモリ１０３に読み出すなどして実行しシステム自体の統括制御を行なうとともに各種判定、演算及び制御処理を行なうＣＰＵなど演算装置１０４、ネットワーク１０と接続し他装置との通信処理を担う通信装置１０５を備える。

なお、記憶装置１０１には、上述のプログラム１０２の他に、法人管理テーブル１２５、決済期限テーブル１２６、ユーザ管理テーブル１２７、決済情報テーブル１２８、および、分割決済情報テーブル１２９を保持する。これらテーブルのデータ構成については後述する。

また図３は、本実施形態の店舗端末２００のハードウェア構成例を示す図である。本実施形態の店舗端末２００は、例えば、店舗スタッフが決済業務時に用いるタブレット端末、あるいはノートＰＣを想定出来る。

具体的には、ハードディスクドライブなど適宜な不揮発性記憶素子で構成される記憶装置２０１、ＲＡＭなど揮発性記憶素子で構成されるメモリ２０３、記憶装置２０１に保持されるプログラム２０２をメモリ２０３に読み出すなどして実行しシステム自体の統括制御を行なうとともに各種判定、演算及び制御処理を行なうＣＰＵなど演算装置２０４、タッチパネル等の入出力装置２０５、ネットワーク１０と接続し他装置との通信処理を担う通信装置２０６、およびＧＰＳユニット２１０を備える。

このうちＧＰＳユニット２１０は、ＧＰＳ衛星からの信号を得て自機の現在位置を測位可能なユニットである。その測位精度について特に限定しないが、ＩＭＥＳ（Ｉｎｄｏｏｒ ＭＥｓｓａｇｉｎｇ Ｓｙｓｔｅｍ）や、携帯電話基地局、無線ＬＡＮアクセスポイントなど、各種補間技術を利用して当該ＧＰＳユニット２１０での測位精度を高めた運用を行うとすれば好適である。

なお、記憶装置２０１におけるプログラム２０２は、本実施形態の決済処理システム１００が当該店舗端末２００に提供する機能を利用するためのアプリ２０２５を少なくとも含んでいる。

このアプリ２０２５は、主たる機能として、当該店舗での決済機会に際し、上述のＧＰＳユニット２１０で得た現在位置情報を、当該店舗の店舗ＩＤと共に決済処理システム１００に送信し、当該店舗に関して決済可能なエリアに当該店舗端末２００が所在していることを確認する機能と、当該確認の成功を経て、当該店舗のスタッフ等から入力された（或いは当該アプリ２０２５が自動生成した）アクセスコードを、当該決済機会に関する決済情報と対応付けて、決済処理システム１００に登録する機能を有する。

また図４に、本実施形態のユーザ端末３００のハードウェア構成例を示す。本実施形態においてユーザ端末３００は、ハードディスクドライブなど適宜な不揮発性記憶素子で構成される記憶装置３０１、ＲＡＭなど揮発性記憶素子で構成されるメモリ３０３、記憶装置３０１に保持されるプログラム３０２をメモリ３０３に読み出すなどして実行しシステム自体の統括制御を行なうとともに各種判定、演算及び制御処理を行なうＣＰＵなど演算装置３０４、タッチパネル等の入出力装置３０５、ネットワーク１０と接続し他装置との通信処理を担う通信装置３０６、およびＧＰＳユニット３１０を備える。

このうちＧＰＳユニット３１０の構成は上述の店舗端末２００におけるＧＰＳユニット２１０と同様である。

なお、記憶装置３０１におけるプログラム３０２は、本実施形態の決済処理システム１００が当該ユーザ端末３００に提供する機能を利用するためのアプリ３０２５を少なくとも含んでいる。

このアプリ３０２５は、主たる機能として、当該店舗での決済機会に際し、上述のＧＰＳユニット３１０で得た現在位置情報を決済処理システム１００に送信し、当該ユーザ端末３００の現在位置に所在する登録店舗を確認する機能と、当該確認を経た後、ユーザが入出力装置３０５で入力してきたアクセスコードを決済処理システム１００に送信して、当該店舗に関して登録済みのアクセスコードとの照合依頼を行う機能を有する。
−−−データ構成例−−−
続いて、本実施形態の決済処理システム１００が用いるテーブルについて説明する。図５に、本実施形態における法人管理テーブル１２５の一例を示す。法人管理テーブル１２５は、決済処理システム１００を利用する各店舗に関する情報を蓄積したテーブルである。 そのデータ構造は、当該店舗の運営法人を一意に特定する法人番号と、当該運営法人の各店舗を一意に特定する店舗ＩＤとをキーにして、当該店舗の店舗名、所在地、登録位置、認証情報、決済口座、エリアタイプ、登録地点、および許容範囲、といったデータから成るレコードの集合体である。

このうち所在地は、行政区画における住所表記に対応した情報であり、当該店舗の住所である。また、登録位置は、当該店舗に関する情報を法人管理テーブル１２５に登録する際、登録を行った店舗端末２００のＧＰＳユニット２１０から得たＧＰＳ座標値（すなわち現在位置情報）である。本実施形態においては、これら所在地と登録位置とは、互いに同じ地点を指し示す値である。換言すれば、ＧＰＳユニット２１０から得たＧＰＳ座標値が、店舗側から申告してきた所在地の位置と一致しない場合、当該法人管理テーブル１２５への店舗登録はなされない。

また、認証情報は、当該店舗の店舗端末２００で利用するアプリ２０２５の利用時に必要となるパスワードである。当該認証情報は、法人管理テーブル１２５に格納されず、当該アプリ２０２５が保持し、認証処理を行うとしてもよい。

また、決済口座は、当該店舗における決済機会に、当該店舗の顧客たるユーザから当該店舗への送金処理での送金先となる銀行口座である。

また、エリアタイプは、当該店舗が建物に所在する固定型の店舗か、或いは、当該店舗が自動車等による移動店舗か、に応じて定まる、決済可能なエリアの種類である。例えば、「固定型」店舗の場合、当該店舗の所在地或いは登録位置を一部または全部含む区画が、決済可能なエリアとなる。他方、「都度登録型」店舗の場合、当該店舗の所在地或いは登録位置を中心にした一定範囲の円形区画（勿論、区画形状は一例である）が、決済可能なエリアとなる。

上述の決済可能なエリアを特定するための情報が、「登録地点」となる。エリアタイプ「固定型」の場合、「登録地点」は、決済可能なエリアの形状における各頂点のＧＰＳ座標値となる。一方、エリアタイプ「都度登録型」の場合、「登録地点」は、円形の決済可能なエリアの中心点のＧＰＳ座標値となる。

また、「許容範囲」は、ユーザ端末３００の現在位置が当該店舗の登録位置或いは決済可能なエリアの範囲に含まれると判定しうる許容範囲を規定した値である。例えばエリアタイプ「固定型」の場合、当該店舗の決済可能なエリア（登録地点１、登録地点２、・・・）を規定する境界線からの距離となる。従って、ユーザ端末３００の現在位置が、決済可能なエリアの外であるが、当該エリアの境界線から許容範囲の距離までの間に位置する場合、当該ユーザ端末３００は当該店舗における決済可能なエリアに所在すると判定される。他方、エリアタイプ「都度登録型」の場合、当該店舗の登録位置または決済可能なエリア（登録地点１）からの距離となる。

また図６に、本実施形態における決済期限テーブル１２６の一例を示す。決済期限テーブル１２６は、各店舗ごとの、当該決済処理システム１００による決済処理の期限を規定したテーブルである。

そのデータ構造は、店舗ＩＤをキーとして、決済期限時刻、期限超過時の決済方法、およびカード決済可否といったデータから成るレコードの集合体である。

このうち「決済期限時刻」は、各店舗における売上データの締め時刻に応じた決済期限の時刻となる。また、「期限超過時の決済方法」は、上述の「決済期限時刻」を経過してしまった場合の決済方法であり、各店舗が希望する決済方法となる。また、「カード決済可否」は、当該店舗にてクレジットカード決済を利用出来るか否かを示す。

また図７に、本実施形態におけるユーザ管理テーブル１２７の一例を示す。ユーザ管理テーブル１２７は、上述の店舗を利用する顧客たるユーザの情報を蓄積したテーブルである。

そのデータ構造は、ユーザを一意に特定するユーザＩＤをキーとして、当該ユーザの決済口座、およびカード情報といったデータから成るレコードの集合体である。このうち「決済口座」は、当該ユーザに関する各店舗における決済機会に、当該ユーザから利用店舗への送金処理での送金元となる銀行口座である。

また、「カード情報」は、当該ユーザに関して、上述の「決済期限時刻」を過ぎた時刻での決済機会が生じた場合に、代替決済手段たるクレジットカードの情報である。

また図８に、本実施形態における決済情報テーブル１２８の一例を示す。決済情報テーブル１２８は、各店舗にて生じた決済機会に対応する決済情報を蓄積したテーブルである。 そのデータ構造は、決済情報を店舗端末２００から受け付けた際の番号、すなわち受付番号をキーとして、当該店舗の店舗ＩＤ、決済金額、アクセスコード、決済期限、登録時位置情報、決済完了、および、エリアタイプといったデータから成るレコードの集合体である。このうち決済金額は、当該決済機会において当該店舗のユーザから当該店舗に送金される金額、となる。

また図９に、本実施形態における分割決済情報テーブル１２９の一例を示す。分割決済情報テーブル１２９は、上述の決済情報テーブル１２８に登録された決済情報に対し、ユーザ端末３００から複数人での支払分担（いわゆる、割り勘）の意思通知を受けた場合に生成されるテーブルである。

そのデータ構造は、上述の支払分担の意思通知の対象となった決済情報の受付番号をキーとして、当該決済機会が生じた店舗、決済金額、アクセスコード、決済期限、個別決裁完了、および、決済完了といったデータから成るレコードの集合体である。

このうち、「決済金額」は、上述の決済情報テーブル１２８における当該決済情報の「決済金額」の値のうち、各ユーザの分担分を示すものである。図９の例であれば、受付番号「２０１６０１０４／０００００２」なる決済情報に関して、元の決済金額「￥１２，８００」のうち、一方のユーザが「￥８，０００」、他方のユーザが「￥４，８００」、それぞれ分担する状況を示している。またこうした決済金額の分担に伴い、アクセスコードも、１人目のものに「−１／２」、２人目のものに「−２／２」、なる値を付随させている。

また、「個別決済完了」の値は、各ユーザがその分担分の決済を完了させた場合に「済」、決済を完了させていない場合に「未」、となる。１つの受付番号に関する、この「個別決済完了」の各欄が全て「済」となった場合、「決済完了」欄の値は、「済」となる。他方、１つの受付番号に関する「個別決済完了」の各欄のうち１つでも「未」となっている場合、「決済完了」欄の値は、「未」となる。図９の例では、この「決済完了」欄にて、個別決済の完了状況を示す、「１／２」（すなわち、全部で２件の個別決済のうち１件のみ完了）といった値を更に登録している。
−−−フロー例１−−−
以下、本実施形態における決済処理方法の実際手順について図に基づき説明する。以下で説明する決済処理方法に対応する各種動作は、決済処理システム１００がメモリ１０３に読み出して実行するプログラムによって実現される。そして、これらのプログラムは、以下に説明される各種の動作を行うためのコードから構成されている。

図１０は、本実施形態における決済処理方法のフロー例１を示す図である。ここではまず、店舗に関する情報を法人管理テーブル１２５に登録するフローについて説明する。なお、このフローの開始に際し、店舗端末２００は、当該決済処理システム１００などの適宜なサーバシステムから、上述のアプリ２０２５をダウンロードおよびインストールしているものとする。

店舗端末２００は、アプリ２０２５のインターフェイス（例：図１１参照）を入出力装置２０５で表示させ、店舗スタッフからの、法人番号、店舗名および所在地の各情報の入力を受け付ける（ｓ１００）。このｓ１００において、店舗端末２００は、得られた各情報を、決済処理システム１００に送信するものとする。なお、ここで店舗端末２００が受け付ける情報のうち法人番号は必須ではない。例えば、当該店舗の運営者が法人格を持たず、個人事業主である場合、店舗端末２００は、法人番号に代えて、代表者の氏名等を受け付けるとしてもよい。

また、店舗端末２００は、当該店舗のエリアタイプに関する選択を、入出力装置２０５で受け付ける（ｓ１０１）。このｓ１０１において、店舗端末２００は、受け付けたエリアタイプの情報を、決済処理システム１００に送信するものとする。

一方、決済処理システム１００は、当該店舗に関する、法人番号、店舗名、所在地、およびエリアタイプの各情報を、店舗端末２００から受信する（ｓ１０２）。

次に決済処理システム１００は、ｓ１０２で得た当該店舗のエリアタイプが、「固定型」と「都度登録型」のいずれであるか判定する（ｓ１０３）。この判定の結果、当該店舗に関して選択されたエリアタイプが「都度登録型」であった場合（ｓ１０３：ｎ）、決済処理システム１００は、処理をｓ１０８へ遷移させる。

他方、上述の判定の結果、当該店舗に関して選択されたエリアタイプが、「固定型」であった場合（ｓ１０３：ｙ）、決済処理システム１００は、当該店舗端末２００に対し、そのＧＰＳユニット２１０で測位した現在位置情報を要求し、これを取得する（ｓ１０４）。

続いて決済処理システム１００は、店舗端末２００から得た当該現在位置情報が、ｓ１００で当該店舗に関し得ている所在地を示すものか判定する（ｓ１０５）。

この判定の結果、当該店舗端末２００の現在位置が当該店舗の所在地にないことが判明した場合（ｓ１０５：ｎ）、決済処理システム１００は、「店舗所在地と店舗端末の現在位置が整合しません」などといった所定のエラー通知を店舗端末２００に返し（ｓ１０６）、処理を一旦終了する。

他方、上述の判定の結果、当該店舗端末２００の現在位置が当該店舗の所在地にあることが判明した場合（ｓ１０５：ｙ）、決済処理システム１００は、当該店舗端末２００に対し、当該店舗の決済口座の情報と、当該店舗端末２００にインストールされたアプリ２０２５の利用に必要な認証情報（例：パスワード）の指定を、要求する（ｓ１０７）。

店舗端末２００は、上述の要求を受けて入出力装置２０５で表示させ、当該店舗のスタッフ等からの決済口座の情報と、当該アカウントの認証情報の入力を受け付ける（ｓ１０８）。このｓ１０８において、店舗端末２００は、受け付けた決済口座および認証情報の各情報を、決済処理システム１００に送信するものとする。

なお、この場合の店舗端末２００は、決済処理システム１００に対する上述の認証情報の送信を行わず、当該店舗端末２００で保持するアプリ２０２５に設定するとしてもよい。

決済処理システム１００は、店舗端末２００が送信した、上述の決済口座および認証情報を受信し、これを、ｓ１０２で得た、当該店舗に関する、法人番号、店舗名、所在地、およびエリアタイプの各情報と対応付けて、レコードを生成し、当該レコードを法人管理テーブル１２５に格納する（ｓ１０９）。なお、当該ステップｓ１０９において、決済処理システム１００は、当該店舗に関して店舗ＩＤを所定のアルゴリズムで生成し、当該レコードに格納するものとする。

続いて決済処理システム１００は、当該店舗に関して決済可能なエリアに関する指定要求を、上述の店舗端末２００に送信し、当該店舗端末２００からその回答、すなわち「登録地点」の情報を取得し、これを当該店舗のレコードにおける「登録地点」欄にそれぞれ格納する（ｓ１１０）。

この場合、店舗端末２００は、ｓ１０５の判定にて店舗端末２００の現在位置との整合性が担保された、当該店舗の所在地が含まれる所定マップ（図１２参照）を表示させる。これを閲覧する当該店舗のスタッフ等は、店舗端末２００を携行しつつ当該マップ上を移動し、決済可能なエリアの境界線上の各頂点で、地点登録指示を入力する。当該スタッフ等が考える決済可能なエリアの形状が矩形であれば、４つの頂点にて地点登録指示を入力することとなる。勿論、こうした決済可能なエリアの形状に関して限定するものではない。１つのエリアを規定出来る閉じた図形の形状であれば、いずれの形状でも良い。

一方、店舗端末２００は、上述の地点登録指示の各々を入出力装置２０５で受け、当該指示を受けるごとに、ＧＰＳユニット２１０から現在位置情報を取得し、これを決済処理システム１００に送信する。上述の例であれば、４つの現在位置情報が送信されることになる。

他方、決済処理システム１００は、上述のように店舗端末２００から送信された、各地点登録指示に伴う現在位置情報を受信し、これを当該店舗のレコードにおける「登録地点」欄にそれぞれ格納する。

なお、詳細説明は行わないが、各ユーザのユーザ端末３００にも、決済処理システム１００からアプリ３０２５がダウンロードされ、インストールがなされるものとする。また、このアプリ３０２５を介して、当該ユーザの決済口座の情報が入力され、決済処理システム１００のユーザ管理テーブル１２７に登録されるものとする。
−−−フロー例２−−−
次に、店舗での決済機会の発生に伴う、決済情報の登録処理について説明する。図１３は、本実施形態における決済処理方法のフロー例２を示す図である。

この場合、店舗のスタッフ等は、店舗端末２００にてアプリ２０２５を起動し、パスワード等の認証情報を入力する。店舗端末２００では、この認証情報と当該店舗の店舗ＩＤを含む認証要求を決済処理システム１００に送信する（ｓ２００）。勿論、アプリ２０２５が認証情報を保持している場合、アプリ２０２５で認証情報同士の照合による認証処理を実行するため、当該認証要求の送信は不要である。こうした認証に関する運用は、状況に応じて適宜に行えばよい。

上述の認証要求の結果、決済処理システム１００での認証処理（ｓ２０１）を経て、認証失敗との結果を得た場合（ｓ２０２：ｎ）、店舗端末２００のアプリ２０２５は、認証エラーとなった旨を入出力装置２０５に表示し（ｓ２０３）、処理を一旦終了する。

他方、上述の認証要求の結果、決済処理システム１００から認証成功との結果を得た場合（ｓ２０２：ｙ）、店舗端末２００は、ＧＰＳユニット２１０から現在位置情報を取得し、これを決済処理システム１００に送信する（ｓ２０４）。

一方、決済処理システム１００は、上述の店舗端末２００の現在位置情報を受信し、これが当該店舗の決済可能なエリア内を示すものか判定する（ｓ２０５）。この処理に際し、決済処理システム１００は、当該店舗に関して法人管理テーブル１２５で保持する各登録地点の値を抽出し、当該値を結んだ領域内に、上述の現在位置情報たるＧＰＳ座標値が含まれるか判定することになる。勿論、この判定の際に、当該店舗に関する「許容範囲」を法人管理テーブル１２５で特定しておき、店舗端末２００の現在位置が、上述の領域を外れた場合でも、許容範囲には含まれるか判定する。

上述の判定の結果、店舗端末２００が決済可能なエリアに所在していないことが判明した場合（ｓ２０６：ｎ）、決済処理システム１００は、「店舗端末が決済可能なエリア外に所在しているようです」といったエラーメッセージを店舗端末２００に送信し（ｓ２０７）、処理を終了する。

他方、上述の判定の結果、店舗端末２００が決済可能なエリアに所在していることが判明した場合（ｓ２０６：ｙ）、決済処理システム１００は、当該決済機会における決済金額およびアクセスコードの入力要求を、店舗端末２００に送信し、これを取得する（ｓ２０８）。

この場合、店舗端末２００のアプリ２０２５は、決済金額とアクセスコードの入力用のインターフェイス（図１４参照）を入出力装置２０５で表示させることになる。店舗スタッフ等は、このインターフェイスにて、当該決済機会における決済金額とアクセスコードを入力する。なお、アクセスコードは、決済機会毎に一意に対応付くコードである。そのため、店舗スタッフ等が自ら考えて入力する場合の他、アプリ２０２５が所定のアルゴリズムにより自動生成するとしてもよい。或るは、決済処理システム１００が、アプリ２０２５からの要求を受けて生成し、これを店舗端末２００のアプリ２０２５に返すとしてもよい。

決済処理システム１００は、ｓ２０８で、決済金額とアクセスコードを店舗端末２００から取得したことに応じ、当該決済金額とアクセスコードを含むレコードを生成し、これに受付番号を付与した上で、決済情報テーブル１２８に格納し（ｓ２０９）、当該フローを終了する。なお、当該店舗の店舗スタッフ等は、こうした登録完了に伴って当該決済機会におけるアクセスコードを、当該ユーザに伝達する。但し、この伝達手法については問わない。例えば、アクセスコードを記載した紙片をユーザに手渡しするケース、アクセスコードを赤外線など適宜な近距離無線通信により、店舗端末２００からユーザ端末３００に送信、或いは単に口頭で、など様々採用出来る。

図８で既に示した決済情報テーブル１２８を例とすれば、受付番号「２０１６０１０４／０００００１」なるレコードは、店舗ＩＤ「Ａ０１」なる店舗の店舗端末２００から決済情報を得て生成されたものであり、その決済機会における決済金額は「￥４，９８０」、アクセスコードは「＊＊＊＊＊」である。

なお、このレコードにおける「決済期限」の値は、決済処理システム１００が、決済期限テーブル１２６にて当該店舗「Ａ０１」の決済期限時刻を特定し、当該時刻を、当該レコードの生成日における決済期限としたものである。

また、「登録時位置情報」は、上述のステップｓ２０６での判定により、決済可能なエリア内での所在が確認された店舗端末２００の現在位置情報（ｓ２０４で得たもの）、となる。なお、当該フローの実行時点では決済処理は行っていないため、「決済完了」欄には「未」の値が設定されている。

また、「エリアタイプ」欄に関しては、決済処理システム１００が、店舗ＩＤ「Ａ０１」に基づき法人管理テーブル１２５で特定したエリアタイプの値となる。
−−−フロー例３−−−
次に、上述の決済機会において支払を行うユーザと、当該支払を受ける店舗との間での決済、すなわち送金処理に関するフローを説明する。図１５は、本実施形態における決済処理方法のフロー例３を示す図である。

ここで上述のユーザは、ユーザ端末３００にてアプリ３０２５を起動するものとする。起動したアプリ３０２５は、ＧＰＳユニット３１０から現在位置情報を取得し、これを決済処理システム１００に送信する（ｓ３００）。

決済処理システム１００は、アプリ３０２５から送信されてきた現在位置情報を受信し、これを決済情報テーブル１２８の各レコードに照合し、「登録時位置情報」が一致するレコード、すなわち決済情報を特定する（ｓ３０１）。

次に決済処理システム１００は、上述で特定したレコードから店舗ＩＤを読み出し、これに対応する店舗名を法人管理テーブル１２５で特定すると共に、当該決済情報が示す決済金額とあわせて、決済情報としてユーザ端末３００に送信する（ｓ３０２）。

ユーザ端末３００は、上述の店舗名および決済金額の情報を含む決済情報を受信し、これを入出力装置２０５に表示させる（ｓ３０３）。ユーザはこの決済情報（図１６参照）を閲覧し、決済内容を確認する。複数の決済情報が表示されている場合、ユーザは処理を行う対象を適宜に選択するものとする。そしてこのユーザは、決済を行う決済情報に関して、店舗スタッフ等から事前に通知されているアクセスコードを、アプリ３０２５に対して入力する。

ユーザ端末３００のアプリ３０２５は、アクセスコードの入力を受け付けて、これを含む照合依頼を決済処理システム１００に送信する（ｓ３０４）。

決済処理システム１００は、ユーザ端末３００からアクセスコードを受信し、このアクセスコードが、決済情報テーブル１２８での該当レコードにおけるアクセスコードと一致するか判定する（ｓ３０５）。

上述の判定の結果、各アクセスコードが一致しなかった場合（ｓ３０６：ｎ）、決済処理システム１００は、「アクセスコードが一致しません」といったエラーメッセージをユーザ端末３００に返し（ｓ３０７）、フローをｓ３０５に戻すか、或いは処理を終了する。

他方、上述の判定の結果、各アクセスコードが一致した場合（ｓ３０６：ｙ）、決済処理システム１００は、決済情報テーブル１２８において決済期限の値を参照し、当該値が、現在日時を過ぎていないか判定する（ｓ３０８）。

上述の判定の結果、決済期限が現在日時を過ぎていた場合（ｓ３０８：ｎ）、決済処理システム１００は、決済期限が過ぎている旨を示すメッセージをユーザ端末３００に返し、決済期限テーブル１２６における、当該店舗の期限超過時の決済方法を特定し、当該決済方法による決済処理を実行する（ｓ３０９）。

例えば、図６の決済期限テーブル１２６において、店舗「Ａ０１」の期限超過時の決済方法は「クレジットカード決済」である。また、当該決済における一方の主体であるユーザのユーザＩＤが「ＡＵ０１」である場合、そのカード情報はユーザ管理テーブル１２７にて取得出来る。そこで決済処理システム１００は、当該カード情報が示すクレジットカードでの、上述の決済金額の決済依頼を、該当クレジットカード会社に通知する。

他方、上述の判定の結果、決済期限が現在日時を過ぎていない場合（ｓ３０８：ｙ）、決済処理システム１００は、当該決済情報が含む店舗ＩＤをキーに法人管理テーブル１２５から決済口座の情報を取得し、同様に、アプリ３０２５から得られる当該ユーザのユーザＩＤをキーにユーザ管理テーブル１２７から決済口座の情報を取得する（ｓ３１０）。

また決済処理システム１００は、ｓ３１０で得た決済口座の情報と、上述の決済金額の情報に基づき、当該ユーザの決済口座から当該店舗の決済口座に、決済金額分の送金を要求する電文を生成し、これを勘定系システム４００に送信する（ｓ３１１）。

なお、こうした送金の処理は、送金元と送金先の口座が同じ金融機関であれば、更には、同じ支店であれば、送金手数料が非常に低いものとなり好適である。よって、店舗とその顧客たるユーザとで、同じ金融機関で決済口座を開設するよう運用を行えばよい。

ここで、上述のフローのうち、例えば、ステップｓ３０５において、決済処理システム１００は、アクセスコードとともに、当該決済機会に関して複数人での支払を分担する意思通知を、ユーザ端末３００から受信するとしてもよい。

この意思通知は、アクセスコードに、人数分だけ連続する所定値を付与したことをもってみなすとできる。或いは、支払を分担するユーザの人数の通知であってもよい。

例えば、アクセスコードが「１２３４」であり、支払を分担するユーザが２人であった場合、当該人数の指示を受けたユーザ端末３００が、「１／２」と「２／２」の値を、それぞれアクセスコードに付与し、「１２３４−１／２」、および「１２３４−２／２」なるアクセスコードを生成する。勿論、こうした処理は、ユーザ自身が行っても良いし、或いは、当該人数の通知をユーザ端末３００から受けた決済処理システム１００が実行するとしてもよい。

またこの場合、ユーザ端末３００または決済処理システム１００は、元のアクセスコード「１２３４」に紐付く決済金額を、上述の支払を分担するユーザの人数で除算する、或いは、ユーザから指定を受けた金額毎に分割する、といった処理を実行し、各ユーザごとの決済金額を特定する。

こうした処理により、支払を分担するユーザ各々と対応する決済情報が、ユーザ端末３００ないし決済処理システム１００により、分割決済情報テーブル１２９に格納される。

決済処理システム１００は、上述の新たなアクセスコードに対応した、各ユーザ分の決済情報に基づき、ユーザ端末３００への決済情報の送信（ｓ３０２）、ユーザ端末３００からのアクセスコード受信と分割決済情報テーブル１２８に基づくアクセスコード一致判定（ｓ３０５、ｓ３０６）、決済期限の超過判定（ｓ３０７、ｓ３０８）、決済期限超過時の決済処理（ｓ３０９）、決済口座の情報取得（ｓ３１０）、勘定系システム４００への決済要求電文の送信（ｓ３１１）、と同様の処理をそれぞれ実行する。

また、決済処理システム１００は、上述の決済要求電文の送信を経て、支払を分担するユーザ各ユーザに関して個別の決済処理が完了した場合に、当該決済情報（上述の例であればアクセスコード「１２３４」の件）の決済処理は完了したと判定し、その旨を分割決済情報テーブル１２９の「決済完了」欄に設定すると共に、ユーザ端末３００に通知して当該処理を終了する。

なお、個別の決済処理が全て完了したことを判定する場合、分割決済情報テーブル１２９の該当受付番号に関する「個別決済完了」欄が全て「済」となった事象を検知するか、或いは、当該複数ユーザの各々と当該店舗の決済口座間での送金処理による送金額の合計が、アクセスコード「１２３４」の決済金額（決済情報テーブル１２８の値）とが一致する状態となったことを検知する、とすればよい。

また、図１５のフローに基づく上述の各処理のうち、ユーザ端末３００によるものは店舗端末２００が行い、決済処理システム１００がデータ授受を行う相手も店舗端末２００であるとしてもよい。こうした形態は、例えば、上述のユーザが適宜な端末を所持しておらず、当該ユーザが該当店舗の店舗端末２００を一時的に借りてアクセスコードの入力等を行うケースなどに適用出来る。

本実施形態の決済処理技術によれば、迅速かつ低コストのキャッシュレス決済が可能となる。具体的には、従来であればクレジットカード決済（デビット決済含む）を導入出来なかった店舗等であっても、決済手数料や専用端末（例：ＰＯＳ）の導入コストを憂慮せず、簡便にキャッシュレス決済の導入が可能となる。

本明細書の記載により、少なくとも次のことが明らかにされる。すなわち、本実施形態の決済処理システムにおいて、前記演算装置は、所定店舗の店舗端末より、当該店舗の現在位置、登録希望住所、および決済口座の各情報を含む登録要求を受信し、前記現在位置の情報が前記登録希望住所を示すものである場合、当該店舗に関して、前記現在位置を前記登録位置情報とし、前記決済口座の情報と対応付けて記憶装置に格納する処理を更に実行するものである、としてもよい。

これによれば、実際に店舗端末が所在する現在位置と、当該店舗に関して登録しようとしている住所とが整合する場合にのみ、当該店舗に関する情報登録を実行することとなる。このことで、架空店舗や虚偽の住所を申告して不正な決済を行おうとする悪意の第三者の登録を排除出来る。ひいては、迅速かつ低コストのキャッシュレス決済を、適宜なセキュアな環境下で実行可能となる。

また、本実施形態の決済処理システムにおいて、前記演算装置は、前記登録位置情報および決済口座の情報の格納に際し、当該登録位置情報が示す位置を含む所定範囲の指定を、前記店舗端末から受け付けて、当該指定を受け付けた所定範囲の情報を前記所定領域の情報として記憶装置に格納する処理を更に実行するものである、としてもよい。

これによれば、店舗内でも決済動作が可能な領域を予め限定し、人目を避けうる場所での不明瞭な決済手続き等を排除することが出来る。ひいては、迅速かつ低コストのキャッシュレス決済を、更に適宜なセキュアな環境下で実行可能となる。

また、本実施形態の決済処理システムにおいて、前記演算装置は、所定期間内に得た複数の支払要求各々が、複数ユーザ各々による支払分担の意図を示す所定値の付随した同一の所定コードを含む場合、当該支払要求各々に基づく、当該複数ユーザの各々と当該店舗の決済口座間の送金処理の要求を実行し、当該複数ユーザの各々に関する前記各要求の結果、当該勘定系システムからの各回答結果に問題がない場合に、前記所定コードに紐付いた決済情報に関する決済が完了した旨を所定装置に出力するものである、としてもよい。

これによれば、いわゆる割り勘での支払を希望するユーザに対応しつつ、迅速かつ低コストのキャッシュレス決済が可能となる。

また、本実施形態の決済処理方法において、前記情報処理システムが、所定店舗の店舗端末より、当該店舗の現在位置、登録希望住所、および決済口座の各情報を含む登録要求を受信し、前記現在位置の情報が前記登録希望住所を示すものである場合、当該店舗に関して、前記現在位置を前記登録位置情報とし、前記決済口座の情報と対応付けて記憶装置に格納する処理を更に実行する、としてもよい。

また、本実施形態の決済処理方法において、前記情報処理システムが、前記登録位置情報および決済口座の情報の格納に際し、当該登録位置情報が示す位置を含む所定範囲の指定を、前記店舗端末から受け付けて、当該指定を受け付けた所定範囲の情報を前記所定領域の情報として記憶装置に格納する処理を更に実行する、としてもよい。

また、本実施形態の決済処理方法において、前記情報処理システムが、所定期間内に得た複数の支払要求各々が、複数ユーザ各々による支払分担の意図を示す所定値の付随した同一の所定コードを含む場合、当該支払要求各々に基づく、当該複数ユーザの各々と当該店舗の決済口座間の送金処理の要求を実行し、当該複数ユーザの各々に関する前記各要求の結果、当該勘定系システムからの各回答結果に問題がない場合に、前記所定コードに紐付いた決済情報に関する決済が完了した旨を所定装置に出力する、としてもよい。

１０ ネットワーク
１００ 決済処理システム
１０１ 記憶装置
１０２ プログラム
１０３ メモリ
１０４ 演算装置
１０５ 通信装置
１２５ 法人管理テーブル
１２６ 決済期限テーブル
１２７ ユーザ管理テーブル
１２８ 決済情報テーブル
１２９ 分割決済情報テーブル
２００ 店舗端末
２０１ 記憶装置
２０２ プログラム
２０２５ アプリ
２０３ メモリ
２０４ 演算装置
２０５ 入出力装置
２０６ 通信装置
２１０ ＧＰＳユニット
３００ ユーザ端末
３０１ 記憶装置
３０２ プログラム
３０２５ アプリ
３０３ メモリ
３０４ 演算装置
３０５ 入出力装置
３０６ 通信装置
３１０ ＧＰＳユニット
４００ 勘定系システム

Claims (8)

1. 各店舗の所在地を示す登録位置情報および当該店舗の決済口座情報と、各店舗のユーザの決済口座情報とを格納した記憶装置と、
   前記店舗の店舗端末から得た現在位置情報が、当該店舗の登録位置情報の示す所定領域内を示す場合、当該店舗のユーザに関して生じた決済機会に伴い、当該決済機会に対応した所定コードおよび決済情報を、前記店舗端末から得て記憶装置に格納する処理と、
   所定コードを含む支払要求を、所定のユーザ端末から得た場合、当該ユーザ端末から得た現在位置情報と、前記登録位置情報とに基づき、当該ユーザ端末の現在位置に所在する店舗を特定し、当該店舗に関して保持する所定コードと前記支払要求が含む所定コードとが一致する場合、当該所定コードに紐付いた決済情報と当該店舗および当該ユーザの前記決済口座情報とに基づき、当該ユーザと当該店舗の決済口座間での送金処理を勘定系システムに要求する処理とを実行する演算装置と、
   を備えることを特徴とする決済処理システム。
2. 前記演算装置は、
   所定店舗の店舗端末より、当該店舗の現在位置、登録希望住所、および決済口座の各情報を含む登録要求を受信し、前記現在位置の情報が前記登録希望住所を示すものである場合、当該店舗に関して、前記現在位置を前記登録位置情報とし、前記決済口座の情報と対応付けて記憶装置に格納する処理を更に実行するものである、
   ことを特徴とする請求項１に記載の決済処理システム。
3. 前記演算装置は、
   前記登録位置情報および決済口座の情報の格納に際し、当該登録位置情報が示す位置を含む所定範囲の指定を、前記店舗端末から受け付けて、当該指定を受け付けた所定範囲の情報を前記所定領域の情報として記憶装置に格納する処理を更に実行するものである、
   ことを特徴とする請求項２に記載の決済処理システム。
4. 前記演算装置は、
   所定期間内に得た複数の支払要求各々が、複数ユーザ各々による支払分担の意図を示す所定値の付随した同一の所定コードを含む場合、当該支払要求各々に基づく、当該複数ユーザの各々と当該店舗の決済口座間の送金処理の要求を実行し、
   当該複数ユーザの各々に関する前記各要求の結果、当該勘定系システムからの各回答結果に問題がない場合に、前記所定コードに紐付いた決済情報に関する決済が完了した旨を所定装置に出力するものである、
   ことを特徴とする請求項１に記載の決済処理システム。
5. 各店舗の所在地を示す登録位置情報および当該店舗の決済口座情報と、各店舗のユーザの決済口座情報とを格納した記憶装置を備えた情報処理システムが、
   前記店舗の店舗端末から得た現在位置情報が、当該店舗の登録位置情報の示す所定領域内を示す場合、当該店舗のユーザに関して生じた決済機会に伴い、当該決済機会に対応した所定コードおよび決済情報を、前記店舗端末から得て記憶装置に格納する処理と、
   所定コードを含む支払要求を、所定のユーザ端末から得た場合、当該ユーザ端末から得た現在位置情報と、前記登録位置情報とに基づき、当該ユーザ端末の現在位置に所在する店舗を特定し、当該店舗に関して保持する所定コードと前記支払要求が含む所定コードとが一致する場合、当該所定コードに紐付いた決済情報と当該店舗および当該ユーザの前記決済口座情報とに基づき、当該ユーザと当該店舗の決済口座間での送金処理を勘定系システムに要求する処理とを実行する、
   ことを特徴とする決済処理方法。
6. 前記情報処理システムが、
   所定店舗の店舗端末より、当該店舗の現在位置、登録希望住所、および決済口座の各情報を含む登録要求を受信し、前記現在位置の情報が前記登録希望住所を示すものである場合、当該店舗に関して、前記現在位置を前記登録位置情報とし、前記決済口座の情報と対応付けて記憶装置に格納する処理を更に実行する、
   ことを特徴とする請求項５に記載の決済処理方法。
7. 前記情報処理システムが、
   前記登録位置情報および決済口座の情報の格納に際し、当該登録位置情報が示す位置を含む所定範囲の指定を、前記店舗端末から受け付けて、当該指定を受け付けた所定範囲の情報を前記所定領域の情報として記憶装置に格納する処理を更に実行する、
   ことを特徴とする請求項６に記載の決済処理方法。
8. 前記情報処理システムが、
   所定期間内に得た複数の支払要求各々が、複数ユーザ各々による支払分担の意図を示す所定値の付随した同一の所定コードを含む場合、当該支払要求各々に基づく、当該複数ユーザの各々と当該店舗の決済口座間の送金処理の要求を実行し、
   当該複数ユーザの各々に関する前記各要求の結果、当該勘定系システムからの各回答結果に問題がない場合に、前記所定コードに紐付いた決済情報に関する決済が完了した旨を所定装置に出力する、
   ことを特徴とする請求項５に記載の決済処理方法。

Images