図1は、本実施形態における電子決済システム1のブロック図である。電子決済システム1は、複数の第一端末装置2、第二端末装置3、情報処理装置4を含む。電子決済システム1の一例として、後述する電子決済システム11が挙げられる。複数の第一端末装置2は、個体識別情報(例えば、後述するリストバンドID)を保持する。複数の第一端末装置2の一例として、後述するリストバンド16が挙げられる。第二端末装置3は、商品の情報を保持すると共に、第一端末装置2から個体識別情報を読み出すことができる。第二端末装置3の一例として、後述する決済端末15が挙げられる。情報処理装置4は、個体識別情報と関係づけられたユーザの情報を格納する。情報処理装置4の一例として、後述するサーバ13が挙げられる。
電子決済システム1は、取得部5、支払額決定部6、決済処理部7を含む。取得部5は、商品の購入に関連する複数の個体識別情報を取得する。取得部5の一例として、後述する取得部65が挙げられる。
支払額決定部6は、商品の購入金額と、取得した個体識別情報の数とに基づいて、個体識別情報に関連づけられたユーザ毎の支払額を決定する。支払額決定部6の一例として、後述する支払額決定部66が挙げられる。
決済処理部7は、支払額決定部が決定する支払額に基づいて、ユーザ毎に決済処理を行う。決済処理部7の一例として、後述する決済処理部67が挙げられる。
このように構成することにより、後払い方式での割り勘での決済処理の効率化を図ることができる。なお、図1では、取得部5、支払額決定部6、決済処理部7、金額管理部8は、情報処理装置4に含まれているが、これに限定されず、それらの一部または全てが情報処理装置4に含まれていなくても、電子決済システム1に含まれていればよい。
支払額決定部6は、第二端末装置3において所定のモード中に取得した個体識別情報の数、所定の時間内に取得した個体識別情報の数、または第二端末装置3において設定した数を、支払額を決定する処理で用いる除数として用いる。
このように構成することにより、割り勘処理のバリエーションを増やすことにより、割り勘処理の自由度を高めることができる。
前記電子決済システム1は、さらに、金額管理部8を含む。金額管理部8は、個体識別情報に関連づけられたユーザ毎の決済処理の行われていない商品の合計額と、ユーザの情報に対応付けられる上限額から合計額を差し引いた使用可能額とを管理する。金額管理部は、支払額決定部7により決定される支払額が使用可能額の範囲内であるかの判定を行う。金額管理部8の一例として、後述する金額管理部68が挙げられる。
また、情報処理装置4は、個体識別情報を保持する第一端末装置2から個体識別情報を読み出し可能であると共に、商品の情報を保持する第二端末装置3と、通信可能であってもよい。この場合、情報処理装置4は、格納部9、取得部5、支払額決定部6、決済処理部7、金額管理部8を含んでもよい。
格納部9は、個体識別情報と関連づけられたユーザの情報を格納する。格納部9の一例として、記憶部70が挙げられる。
取得部5は、上述の通り、第二端末装置3から、商品の購入金額と、商品の購入に関連する複数の個体識別情報とを取得する。支払額決定部6は、上述の通り、購入金額と、取得した個体識別情報の数とに基づいて、個体識別情報に関連づけられた前記ユーザ毎の支払額を決定する。決済処理部7は、上述の通り、支払額決定部6が決定する支払額に基づいて、ユーザ毎に、決済処理を行う。
このように構成することにより、後払い方式での割り勘での決済処理の効率化を図ることができる。
図2は、本実施形態における電子決済システム11のネットワーク構成例を示す図である。電子決済システム11は、電子決済システム1の一例である。電子決済システム11は、端末装置12、サーバ装置(以下、「サーバ」と称する。)13、入場受付端末14、決済端末15、リストバンド16、与信照会・決済システム18及び通信ネットワーク19を含む。端末装置12、サーバ13、入場受付端末14、決済端末15、与信照会・決済システム18は、有線通信または無線通信により、通信ネットワーク17を介して、通信可能に接続されている。
本実施形態では、一例として、入場受付端末14、決済端末15が設置されたイベント会場17において、1以上のユーザが集まっているとする。そして、各ユーザは、少なくとも1台の端末装置12を携帯しているものとする。ここで、イベント会場17に入場する場合には、事前に参加申し込みとして、所定の情報を登録(事前登録)する必要がある。事前登録では、イベント会場での商品の購入やサービスの提供に対する対価の支払いを容易するための後払い方式に関する設定も行う。事前登録を済ませたユーザには、イベント参加資格が与えられ、イベント会場への入場を許可する入場許可情報(例えば、QRコード(登録商標)等の二次元コード)が発行される。なお、以下では、商品にはサービスも含まれるものとし、サービスの提供に対する対価の支払いは、商品の購入に含まれるものとする。
イベント会場へ入場する場合、ユーザは、入場受付にて、自身の端末装置12にその発行された二次元コードを表示させる。すると、入場受付担当者は、入場受付端末14でその二次元コードを読み取り、予め用意していたリストバンド16のリストバンドIDを読み取り、サーバ13へ送信する。サーバ13は、二次元コードからユーザ情報を取得し、ユーザ情報とリストバンドIDを紐づける。紐づけ完了後、入場受付担当者は、その紐づけられたリストバンドIDを保持するリストバンド16をユーザに渡す。ユーザは、イベント会場17でそのリストバンド16を用いて商品の購入を行うことができる。
端末装置12は、例えばユーザが携帯するスマートフォン、タブレット端末、携帯電話等の通信ネットワークに接続可能な通信機能を有する電子端末装置である。なお、端末装置12は、いわゆるパーソナルコンピュータであってもよい。
入場受付端末14は、サーバ13と通信してユーザ情報とリストバンドIDとを紐づけるための装置であり、QRリーダ14aと、リストバンドIDリーダ14bを含む。QRリーダ14aは、端末装置12に表示された二次元コード等の入場許可情報を読み取る。リストバンドIDリーダ14bは、NFC(Near field communication)等の近距離無線通信を介してリストバンド16に保持されているリストバンドIDを読み取る。
決済端末15は、サーバ13と通信してイベント会場17でそのリストバンド16を用いて商品を購入する場合の決済端末であり、NFC等の近距離無線通信を介してリストバンド16に保持されているリストバンドIDを読み取る読取機能を有する。
リストバンド16は、リストバンドIDリーダ14b及び決済端末15と近距離無線通信を行うためのNFCチップ等を内蔵している。NFCチップは、リストバンドを識別する個体識別情報(リストバンドID)を保持する記憶部を含む。
サーバ13は、端末装置12、入場受付端末14、決済端末15と通信可能な情報処理装置である。サーバ13は、端末装置12からの要求に応じてユーザ情報(支払情報を含む)を登録したり、入場受付端末14からの要求に応じてユーザ情報とリストバンドIDとを紐づけたり、決済端末からの要求に応じて決済処理を行ったりする。
サーバ13は、決済処理を行う場合には、与信照会・決済システム18に通信を行い、与信照会を行う。与信照会とは、クレジットカード会社に対してクレジットカード利用者の信用確認(有効性の確認や利用枠の確認)をすることをいう。与信照会がカード会社により承認されることで、決済金額が一時的に(仮に)確保される。
サーバ13は、1台以上の物理的な情報処理装置により構成されるサーバシステムであってもよいし、1台以上の仮想サーバ装置により構成される仮想サーバシステムであってもよい。
図3は、本実施形態における電子決済システムの機能及び構成ブロック図である。端末装置12は、通信部21、操作表示部22を含む。通信部21は、通信ネットワーク19に接続された機器との通信を可能にするインターフェースである。ここでは、サーバ13と通信を行う。
操作表示部22は、入力操作により入力が可能であると共に、表示も可能なタッチパネルである。なお、本実施形態では、一例として、操作表示部22を用いるが、これに限定されず、入力部と表示部とがそれぞれ独立していてもよい。操作表示部22を用いて、ユーザは、イベントへの参加申し込み時(事前)に、端末装置12を介してユーザにより入力されるユーザ情報を登録する。ユーザ情報の登録後、イベントへの参加資格としての入場許可情報が発行され、その入場許可情報は、例えば二次元コードとして操作表示部22に表示させることができる。
入場受付端末14は、通信部31、二次元コードリーダ14a、リストバンドIDリーダ14bを含む。
二次元コードリーダ14aは、端末装置12に表示させたQRコード(登録商標)等の二次元コードを読み取ることができる。なお、本実施形態では二次元コードを用いるが、これに限定されず、例えば、一次元コードであってもよい。リストバンドIDリーダ14bは、NFC等の近距離無線通信を介してリストバンド16の記憶部51に保持されているリストバンドIDを読み取ることができる。
通信部31は、通信ネットワーク19に接続された機器との通信を可能にするインターフェースであり、ここでは、サーバ13と通信を行う。通信部31は、対応付けてまたは連続して読み取られた二次元コードとリストバンドIDとをペアにして、サーバ13へ送信する。
なお、入場受付端末14は、サーバ13への処理要求の結果を表示させるためにディスプレイ等の表示部(不図示)を含んでいてもよい。
決済端末15は、通信部41、操作表示部42、読取部43を含む。通信部41は、通信ネットワーク19に接続された機器との通信を可能にするインターフェースであり、ここでは、サーバ13と通信を行う。
操作表示部42は、入力操作により入力が可能であると共に、表示も可能なタッチパネルである。なお、本実施形態では、一例として、操作表示部42を用いるが、これに限定されず、入力部と表示部とがそれぞれ独立していてもよい。この実施形態では、例えば、操作表示部42は、商品情報を入力したり、割り勘等をする場合に支払い方法のモードの設定を行ったり、サーバ13への処理要求の結果を表示させることができる。
読取部43は、NFC等の近距離無線通信を介してリストバンド16に保持されているリストバンドIDを読み取る読取機能を有する。
なお、決済端末15は、商品コードを読み取るためのバーコードリーダ(または二次元コードリーダ)等やNFC等の近距離無線通信を用いて情報を読み取る商品情報読取部(不図示)を含んでもよい。また、決済端末15は、レシートを発行できるように、プリンタ等の出力装置を設けてもよい。
サーバ13は、通信部61、制御部62、記憶部70を含む。通信部61は、通信ネットワーク19に接続された機器との通信を可能にするインターフェースである、ここでは、端末装置12、入場受付端末14、決済端末15及び与信照会・決済システム18と通信を行う。
制御部62は、ユーザ情報登録部63、関係付け部64、取得部65、支払額決定部66、決済処理部67、金額管理部68として機能する。
ユーザ情報登録部63は、イベントへの参加申し込み時(事前)に、端末装置12を介してユーザにより入力されるユーザ情報を取得して、ユーザ情報管理テーブル71に登録する。
関係付け部64は、入場受付端末14からペアとして送信された二次元コードとリストバンドIDとを取得すると、入場許可情報管理テーブル74からその取得した二次元コード(入場許可情報)に対応するユーザIDを検索する。関係付け部64は、検索されたユーザIDと、取得したリストバンドIDとを関係付けて、ユーザID・リストバンドID関係テーブル75に登録する。
取得部65は、決済端末15から送信された購入商品情報とリストバンドID等を取得する。
支払額決定部66は、商品の購入金額と、取得したリストバンドIDの数とに基づいて、リストバンドIDに関連づけられたユーザ毎の支払額を決定する。
決済処理部67は、支払額決定部66により決定された支払額に基づいて、ユーザ毎に決済処理を行う。ここで、支払額決定部67は、決済端末15において所定のモード中に取得したリストバンドIDの数、所定の時間内に取得したリストバンドIDの数、または決済端末15において設定した数を、支払額を決定する処理で用いる除数として用いる。
金額管理部68は、リストバンドIDに関連づけられたユーザ毎の決済処理の行われていない商品の合計額と、ユーザの情報に対応付けられる上限額から合計額を差し引いた使用可能額とを管理し、支払額決定部66により決定される支払額が使用可能額の範囲内であるかの判定を行う。
記憶部70は、ユーザ情報管理テーブル71、クレジットカード払い情報管理テーブル72、後払い管理テーブル73、入場許可情報管理テーブル74、ユーザID・リストバンドID関係テーブル75、商品情報管理テーブル76、支払履歴管理テーブル77を格納する。
ユーザ情報管理テーブル71は、電子決済システム11を利用するユーザの情報を管理するためのテーブルである。クレジットカード払い情報管理テーブル72は、支払い方法としてクレジットカード払い方法を選択したユーザのクレジットカード情報を管理するテーブルである。後払い管理テーブル73は、支払い方法として後払い方法を選択したユーザの請求書の送付先を管理するテーブルである。入場許可情報管理テーブル74は、イベント会場への入場資格のあるユーザを管理するテーブルである。ユーザID・リストバンドID関係テーブル75は、ユーザIDとリストバンドIDとを紐づけるためのテーブルである。商品情報管理テーブル76は、商品の種類ごとに商品を管理するテーブルである。支払履歴管理テーブル77は、リストバンド16を用いて購入した商品等に関する情報の履歴である。
図4は、本実施形態におけるサーバの記憶部70に格納されているテーブル構造の一例を示す図である。
ユーザ情報管理テーブル71は、「ユーザID」、「氏名」、「住所」、「電話番号」、「支払方法コード」、「上限額」、「支払累積額」等のデータ項目を含む。「ユーザID」は、電子決済システム11において、ユーザを識別するユーザ識別情報であって、ユーザ情報管理テーブル71への登録の際に、ユーザ情報登録部63により付与される。「氏名」、「住所」、「電話番号」には、ユーザIDに対応するユーザの氏名、住所、電話番号が登録される。「支払い方法コード」には、例えばクレジットカード払い決済方法(支払い方法コード=「1」)またはコンビニエンスストア等の店舗での後払い決済(コンビニ決済)(支払い方法コード=「2」)が登録される。「上限額」には、例えば所定の期間(例えば、1日間、1週間等)で利用することができる金額の上限額が登録される。「支払累積額」には、リストバンド16を用いて所定の期間で支払った金額の累積値(合計値)が登録される。
クレジットカード払い情報管理テーブル72は、「ユーザID」、「支払方法コード」、「選択/非選択」、「クレジットカード情報」のデータ項目を含む。「選択/非選択」には、どのクレジットカード情報が選択されたかを示すフラグ(1:選択、0:非選択)が格納される。「クレジットカード情報」には、クレジットカードの番号等の情報が格納される。なお、「クレジットカード情報」は、特にセキュリティが高いので暗号化されている。
後払い管理テーブル73は、「ユーザID」、「支払方法コード」、「選択/非選択」、「請求書送付先住所」、「請求書送付先電話番号」のデータ項目を含む。「選択/非選択」には、どの請求書送付先住所情報が選択されたかを示すフラグ(1:選択、0:非選択)が格納される。「請求書送付先住所」には、請求書の送付先の住所情報が格納される。「請求書送付先電話番号」には、請求書の送付先の電話番号が格納される。
入場許可情報管理テーブル74は、「入場許可情報」、「ユーザID」のデータ項目を含む。「入場許可情報」は、本実施形態では二次元コードまたは二次元コードによって表される情報である。
ユーザID・リストバンドID関係テーブル75は、「ユーザID」、「リストバンドID」のデータ項目を含む。
商品情報管理テーブル76は、「商品コード」、「商品名」、「単価」のデータ項目を含む。「商品コード」には、商品の種類を特定する情報が格納されている。「商品名」には、商品コードに対応する商品の名称が格納されている。「単価」には、商品コードに対応する商品の単価情報が格納されている。
交友履歴管理テーブル77は、「お問い合わせ番号」、「ユーザID」、「注文日時」、「購入商品明細情報」、「合計金額」、「決済状況」、「割り勘フラグ」のデータ項目を含む。「お問い合わせ番号」は、電子決済システム11において各取引を識別する情報であり、サーバ13により取引単位で付与される。「注文日時」には、その取引を行った日時が格納される。「購入商品明細情報」には、その取引において、購入した1以上の商品情報及びその金額が格納される。「合計金額」には、その取引での購入金額の合計、具体的には「購入商品明細情報」の商品の金額の合計が格納される。「決済状況」には、決済済か否かが格納される。「割り勘フラグ」(1:割り勘あり、0:割り勘無し)には、割り勘した取引情報であるか否かが格納される。
図5は、本実施形態における事前登録処理のシーケンス図である。図6、図7及び図8はそれぞれ、本実施形態における事前登録処理において端末装置に表示されるタッチ決済の表示例(その1、その2、その3)を示す図である。以下では、図6~図8を参照しながら、図5を説明する。なお、説明の便宜上、以下では、端末装置12の操作表示部22に表示させることを、端末装置12に表示させると記載する場合もある。
まず、ユーザは、イベントへの参加するためには、参加申し込みとして事前に所定の設定を行う必要がある。そこで、ユーザは、端末装置12にインストールされたブラウザを用いて、所定のポータルサイトへアクセスする(S1)。すると、ポータルサイトに対して所定の入力操作を行って、所定のイベントへの参加申し込みを行うと共に、イベント会場での決済方法を登録するための設定画面(タッチ決済画面)を表示させる(S2)。具体的には、ユーザは、図6に示すように、ポータルサイト画面において、「タッチ決済」タブ82を選択すると、タッチ決済を行うための画面が表示される。
ユーザは、図6の「利用手続きをする」83を押下すると、端末装置12はサーバ13に決済方法の設定要求を送信する(S3)。それに応じて、サーバ13は、図7に示すように決済方法の設定画面91を端末装置12に表示させる(S4)。
ユーザは、端末装置12を用いて決済方法の設定画面91に決済方法を入力する。例えば、決済方法の設定画面91において、ユーザはクレジットカード払いを選択する場合にはクレジットカード払い設定欄92に必要情報を入力する。既に1つ以上のクレジットカード情報が登録されている場合にはそのクレジットカードの下4桁が表示され、いずれかのクレジットカードを選択することができる。また、「クレジットカードを追加」ボタン93を押下した場合には、新たにクレジットカードを登録することができる。
また、決済方法の設定画面91において、後払い(後日郵送されてくる請求書を用いて、コンビニエンスストアで代金の支払いを行う形式)を選択する場合には後払い設定欄94に必要情報を入力する。既に1つ以上の請求書送付先住所が登録されている場合にはその請求書送付住所が表示され、いずれかの請求書送付先住所を選択することができる。また、「新しいお届け先を追加」ボタン95を押下した場合には、新たに請求書送付先住所を登録することができる。
なお、代金の支払いはコンビニエンスストアに限定されず、請求書が銀行、郵便局等での支払いも許容している場合には銀行、郵便局等で支払うようにしてもよい。
また、決済方法の設定画面91のクレジットカード払い設定欄92及び/または後払い設定欄94において、上述した「上限額」を設定することができる。
ユーザは、決済方法の設定画面91において必要情報を入力し終わって、図7の「お申込みを確定する」ボタン96を押下すると、端末装置12はサーバ13にユーザ情報の登録要求を送信する(S5)。それに応じて、サーバ13は、ユーザの氏名、電話番号及び住所(さらにはクレジットカード情報を含んでいてもよい。)に基づいて、与信照会・決済システム18に与信照会を行い(S6)、与信照合結果を受け取る(S7)。すると、サーバ13は、設定完了画面(図8)を端末装置12に表示させる(S8)。サーバ13は、設定完了画面(図8)では、タッチ決済の設定が完了した旨及び登録した内容を表示させる。
なお、事前登録においてはショートメールサービス認証(SMS認証)を用いてもよい。これにより、事前登録時のセキュリティを向上させることができる。なお、図7において、「戻る」ボタン97を押下すると遷移前の画面に戻る。
図9は、本実施形態におけるユーザIDとリストバンドIDとの関係付け処理のシーケンス図である。図10は、本実施形態におけるユーザIDとリストバンドIDとの関係付け処理において端末装置に表示される二次元コードの表示例を示す図である。以下では、図10を参照しながら、図9を説明する。
イベント会場への入場に際して、ユーザは、端末装置12を用いて、ポータルサイトにアクセスする。それかは、ユーザは図10に示すように「二次元コード」タブ101を選択すると、二次元コードが表示される(S11)。
入場受付担当者は、入場受付端末14の二次元コードリーダ14aを用いて、その二次元コードを読み取る(S12)。次に、入場受付担当者は、入場受付端末14のリストバンドIDリーダ14bを用いて、リストバンド16からリストバンドIDを読み取る(S13)。入場受付端末14は、入場受付担当者により所定の操作がなされると、その二次元コードとそのリストバンドIDをペアにして、サーバ13に送信する(S14)。なお、ここで読み取るリストバンド16のリストバンドIDは、当該リストバンド固有のIDであり、かついずれのユーザIDとも関係付けは行われていないものとする。
サーバ13は、その二次元コードとそのリストバンドIDを取得すると、入場許可情報管理テーブル74からその二次元コードに対応するユーザIDを検索する(S15)。サーバ13は、その検索されたユーザIDとリストバンドIDとを関係付けて、ユーザID・リストバンドID関係情報75に格納する(S16)。サーバ13は、入場受付端末14に、関係付け完了通知を送信する(S17)。それにより、端末装置12に関係付け完了を示す情報が表示された場合、入場受付担当者は、その関係付けを行ったリストバンド16をそのユーザに渡す(S18)。イベント会場17において、ユーザはその関係付けを行ったリストバンド16を装着するものとする。
以下では、単独購入の場合、及び複数人での割り勘による購入の場合でのタッチ決済処理のバリエーションについて、実施例1~4を用いて説明する。
図11は、本実施形態(実施例1)におけるタッチ決済処理(単独購入の場合)のシーケンス図である。ユーザ(1人)は、購入対象商品を購入する場合、販売員に清算依頼を行う(S21)。販売員は、決算端末15のバーコードリーダを用いて購入対象商品に付与されている商品コード(例えばバーコード)を読み取り、決算端末15はその商品コードを取得する(S22)。
決算端末15は取得した商品コードをサーバ13に送信する(S23)。サーバ13は、商品情報管理テーブル76から、その商品コードに対応する商品情報(商品名、単価)を取得し、決算端末15へ送信する(S24)。
販売員は、決算端末15に表示された商品情報に基づいて、ユーザに支払金額を提示する(S25)。ユーザは、リストバンド16を提示する(S26)。
販売員は、決算端末15の読取部43を用いて、リストバンド16からリストバンドIDを読み出す(S27)。決算端末15は、購入情報(商品コード、単価、個数)と、リストバンドIDをサーバ13に送信する(S28)。
サーバ13は、購入情報(商品コード、単価、個数)と、リストバンドIDを用いて決済処理を行う。ここで、サーバ13は、ユーザ情報に基づいて、所定期間における支払累積額と今回の支払額の和が、予め設定した上限額を超えるか否かを判定する。リストバンドIDに対応するユーザ情報の決済方法がクレジットカード払いである場合には、サーバ13は与信照会・決済システム18に与信照会を行う(S29)。与信照会・決済システム18から与信照会結果を受け取ると(S30)、サーブ13は、所定期間における支払累積額と今回の支払額の和が、予め設定した上限額を超えるか否かに応じて、または与信照会結果に応じて、決済完了か決済不可かを決済端末15に通知する(S31)。決済端末15は、決済完了か決済不可かに応じてレシートを発行する(S32)。決済完了の場合は、決済端末15は、決済情報をレシートに出力する。決済不可の場合には、決済端末15は、「決済ができませんでした。」旨の内容を用紙に出力する。
図12は、本実施形態(実施例1)におけるサーバのタッチ決済処理(単独購入の場合)の処理を示すフローチャートである。図12のフローチャートは、図11のS28~S31に対応する。
取得部65は、端末装置15からリストバンドIDと購入情報(商品コード、金額、個数)を取得する(S41)。
支払額決定部66は、ユーザID・リストバンドID関係テーブル75から、取得したリストバンドIDに対応するユーザIDを取得する。支払額決定部66は、ユーザ情報管理テーブル71から、その取得したユーザIDに対応するユーザ情報を取得する(S42)。支払額決定部66は、その取得したユーザ情報から、支払方法コード、支払累計額、上限額を取得する(S43)。
金額管理部68は、上限額に基づいて、取得した支払累積額に今回の購入金額(支払金額)を加えた金額は、使用可能額の範囲内か、すなわち上限額を超えていないかを判定する(S44)。
取得した支払累積額に今回の購入金額(支払金額)を加えた金額が、使用可能額の範囲内であると判定された場合(S44でYES)、支払額決定部66は、今回の購入金額を決済額として決定する(S45)。
決済処理部67は、取得した決済方法コードに基づいて、決定した決済額について決済処理を行う(S46)。取得した決済方法コード=1(クレジットカード払い)の場合、決済処理部67は、クレジットカード払い管理テーブル72から、ユーザIDに対応する有効なクレジットカード情報を取得する。決済処理部67は、取得したクレジットカード情報に基づいて、与信照会・決済システム18に与信照会を行い、決定した決済額について決済処理を行う。
取得した決済方法コード=2(後払い)の場合、決済処理部67は、後払い管理テーブル73から、ユーザIDに対応する有効な請求書送付先情報を取得する。決済処理部67は、取得した請求書送付先情報に基づいて、決定した決済額について決済処理を行う。
決済処理部67は、決済処理完了後、ユーザ情報管理テーブル71のそのユーザIDに対応する支払い累計額に、今回決済処理を行った額を加えて、支払い累計額を更新する(S47)。決済処理部67は、決済端末15に決済完了を通知する(S48)。
取得した支払累積額に今回の購入金額(支払金額)を加えた金額が、使用可能額の範囲外であると判定された場合(S44でNO)、金額管理部68は、決済端末15に決済ができないことを通知する(S49)。
図13は、本実施形態(実施例2)におけるタッチ決済処理(複数人での割り勘による購入の場合)のシーケンス図である。図13は、図11のS26~S30をS26a~S30aに置換し、さらにS51,S52,S53の処理を追加したものである。図13では、図11と異なる部分のみを説明し、その他の共通の符号が付与されているものについてはその説明を省略する。
販売員は、決算端末15に表示された商品情報に基づいて、ユーザに支払金額を提示する(S25)。複数のユーザは、販売員に割り勘で購入する旨を伝えると(S51)、販売員は、決済端末15の操作表示部22を操作して、割り勘支払いモードに設定する(S52)。
n(n:任意の整数)人のユーザはそれぞれ、決済端末15に各自のリストバンド16をかざす。すると、決済端末15の読取部43は、かざされたリストバンドのそれぞれから、リストバンドIDを読み出す(S27a)。
割り勘する全員のリストバンドIDを読み取った場合、販売員は、決済端末15の確定ボタンを押下する(S53)。決算端末15は、購入情報(商品コード、単価、個数)と、n個のリストバンドIDをサーバ13に送信する(S28a)。
サーバ13は、購入情報(商品コード、単価、個数)と、n個のリストバンドIDを用いて決済処理を行う。ここで、サーバ13は、ユーザ情報に基づいて、所定期間における支払累積額と今回の支払額の和が、予め設定した上限額を超えるか否かを判定する。リストバンドIDに対応するユーザ情報の決済方法がクレジットカード払いである場合には、サーバ13は与信照会・決済システム18に与信照会を行う(S29a)。与信照会・決済システム18から与信照会結果を受け取ると(S30a)、サーブ13は、ユーザ毎に、所定期間における支払累積額と今回の支払額の和が、予め設定した上限額を超えるか否かに応じて、または与信照会結果に応じて、決済完了か決済不可かを決済端末15に通知する(S31a)。決済端末15は、ユーザ毎に、決済完了か決済不可かに応じてレシートを発行する(S32a)。決済が完了した場合、決済端末15は、ユーザ毎に、決済情報のレシートを発行する。決済不可した場合、決済端末15は、例えば、決済端末15の操作表示部42に「決済ができませんでした。」旨を表示する。
図14は、本実施形態(実施例2)におけるサーバのタッチ決済処理(複数人での割り勘による購入の場合)の処理を示すフローチャートである。図14のフローチャートは、図11のS28a~S31aに対応する。
取得部65は、端末装置15からn個のリストバンドIDと購入情報(商品コード、金額(単価)、個数)を取得する(S61)。
支払額決定部66は、ユーザID・リストバンドID関係テーブル75から、取得したリストバンドIDそれぞれに対応するユーザIDを取得する。支払額決定部66は、ユーザ情報管理テーブル71から、その取得したユーザIDそれぞれに対応するユーザ情報を取得する。支払額決定部66は、その取得したユーザ情報それぞれから、支払方法コード、支払累計額、上限額を取得する(S62)。
支払額決定部66は、購入金額(金額(単価)×個数)をnで割って、商を各ユーザの支払金額Pとして設定する(S63)。なお、余りは、いずれかのリストバンドIDに対応するユーザの支払金額に含ませてもよい。
支払額決定部66は、各ユーザの支払累計額(今回の購入金額を含む。)が使用可能額に収まっているかをチェックするための変数を0で初期化する(S64)。
金額管理部68は、リストバンドID(ユーザID)毎に、S65~S67の処理を行う。すなわち、金額管理部68は、上限額に基づいて、取得した支払累積額に今回の支払金額Pを加えた金額は、使用可能額の範囲内か、すなわち上限額を超えていないかを判定する(S65)。
取得した支払累積額に今回の支払金額Pを加えた金額が、使用可能額の範囲内であると判定された場合(S65でYES)、支払額決定部66は、今回の支払金額Pを決済額として決定する(S66)。
取得した支払累積額に今回の支払金額Pを加えた金額が、使用可能額の範囲外であると判定された場合(S65でNO)、金額管理部68は、処理中のユーザIDを記憶すると共に、chkの値をインクリメントする(S67)。
決済処理部67は、chk=0か否かを判定する(S68)。chk=0の場合(S68)、決済処理部67は、リストバンドID(ユーザID)毎に、S69~S70の処理を行う。すなわち、決済処理部67は、リストバンドID(ユーザID)毎に、取得した決済方法コードに基づいて、決定した決済額について決済処理を行う(S69)。取得した決済方法コード=1(クレジットカード払い)の場合、決済処理部67は、クレジットカード払い管理テーブル72から、ユーザIDに対応する有効なクレジットカード情報を取得する。決済処理部67は、取得したクレジットカード情報に基づいて、与信照会・決済システム18に与信照会を行い、決定した決済額について決済処理を行う。
取得した決済方法コード=2(後払い)の場合、決済処理部67は、後払い管理テーブル73から、ユーザIDに対応する有効な請求書送付先情報を取得する。決済処理部67は、取得した請求書送付先情報に基づいて、決定した決済額について決済処理を行う。
なお、S69において、割り勘するメンバーの決済方法において、クレジットカード払いと後払いとが混在している場合、各自の決済方法に応じて、上述と同様に対応する。例えば、決済処理部67は、決済方法がクレジットカード払いのメンバーについては、取得したクレジットカード情報に基づいて、与信照会・決済システム18に与信照会を行い、決定した決済額について決済処理を行う。また、決済処理部67は、決済方法が後払いのメンバーについては、取得した請求書送付先情報に基づいて、定した決済額について決済処理を行う。
決済処理部67は、リストバンドID(ユーザID)毎に、決済処理完了後、ユーザ情報管理テーブル71のそのユーザIDに対応する支払い累計額に、今回決済処理を行った額を加えて、支払い累計額を更新する(S70)。決済処理部67は、決済端末15に決済完了を通知する(S71)。
chk>0の場合(S68でNO)、金額管理部68は、決済端末15に決済ができないことを通知する(S72)。より具体的には、金額管理部68は、ユーザ情報管理テーブル71から、S67で記憶したユーザIDに対応するユーザ名を取得し、そのユーザの上限額を超える旨のメッセージを通知してもよい。
図15は、本実施形態(実施例3)におけるタッチ決済処理(複数人での割り勘による購入の場合)のシーケンス図である。図15は、図13のS52をS81に置換し、さらにS53の処理を省略したものである。図15では、図13と異なる部分のみを説明し、その他の共通の符号が付与されているものについてはその説明を省略する。
販売員は、決算端末15に表示された商品情報に基づいて、ユーザに支払金額を提示する(S25)。複数のユーザは、販売員に割り勘で購入する旨を伝えると(S51)、販売員は、決済端末15の操作表示部22を操作して、割り勘する人数nを登録する(S81)。
n(n:任意の整数)人のユーザはそれぞれ、決済端末15に各自のリストバンド16をかざす。すると、決済端末15の読取部43は、かざされたリストバンドのそれぞれから、リストバンドIDを読み出す(S27a)。S81で登録したn個分リストバンドIDを読み出すと、決算端末15は、購入情報(商品コード、単価、個数)と、n個のリストバンドIDをサーバ13に送信する(S28a)。
なお、本実施形態(実施例3)におけるサーバのタッチ決済処理(複数人での割り勘による購入の場合)の処理を示すフローチャートは、図14と同じなので、その説明を省略する。
図16は、本実施形態(実施例4)におけるタッチ決済処理(複数人での割り勘による購入の場合)のシーケンス図である。図16は、図15のS81をS91に置換し、さらにS92の処理を追加したものである。図16では、図15と異なる部分のみを説明し、その他の共通の符号が付与されているものについてはその説明を省略する。
販売員は、決算端末15に表示された商品情報に基づいて、ユーザに支払金額を提示する(S25)。複数のユーザは、販売員に割り勘で購入する旨を伝えると(S51)、販売員は、n(n:任意の整数)人のユーザに、決済端末15に各自のリストバンド16をかざすように促す。決済端末15は、所定時間の計測を開始する(S91)。
n(n:任意の整数)人のユーザはそれぞれ、決済端末15に各自のリストバンド16をかざす。すると、決済端末15の読取部43は、かざされたリストバンドのそれぞれから、リストバンドIDを読み出す(S27a)。決済端末15は、所定時間の計測終了後(所定時間の経過後)、購入情報(商品コード、単価、個数)と、n個のリストバンドIDをサーバ13に送信する(S28a)。
なお、本実施形態(実施例4)におけるサーバのタッチ決済処理(複数人での割り勘による購入の場合)の処理を示すフローチャートは、図14と同じなので、その説明を省略する。
なお、決済端末15を操作するオペレータの服にLED(Light Emitting Diode)組み込んでおき、決済時に決済金額に応じて、そのLEDを光らせる演出をしてもよい。これにより、イベント会場において、より楽しい雰囲気を作り出すことができる。
また、上記実施形態では、リストバンドIDをリストバンド内のNFCシップに保持させて、近距離無線通信でリストバンドIDを読み出したが、これに限定されない。例えば、リストバンド16にリストバンドIDに対応するバーコードまたは二次元コードを設けて置き、それをバーコードリーダや二次元コードリーダで読み取るようにしてもよい。
また、固有識別情報を保持するデバイスは、リストバンド16に限定されず、例えば、個体識別情報を保持し近距離無線通信により前記個体識別情報の読み出しが可能なウェアラブル端末装置であってもよいし、スマートフォン等の携帯通信端末であってもよい。
また、本実施形態では、複数人での割り勘による購入の場合、そのうちの1人でも上限額を超える場合は、その取引は中止される例を説明したが、これに限定されない。例えば、複数人での割り勘による購入の場合、そのうちのいずれかの者が上限額を超える場合は、サーバ13は、その上限を超える者以外の者を対象に、再度、S63以降の処理を行うようにしてもよい。
図17は、本実施形態(実施例1~4を含む。)におけるプログラムを実行するコンピュータのハードウェア環境の構成ブロック図の一例である。コンピュータ111は、端末装置12、サーバ13、入場受付端末14、決済端末15として機能する。コンピュータ111は、CPU112、ROM113、RAM114、記憶装置115、入力I/F116、出力I/F117、通信I/F118、読取装置119、バス120によって構成されている。
ここで、CPUは、中央演算装置を示す。ROMは、リードオンリメモリを示す。RAMは、ランダムアクセスメモリを示す。I/Fは、インターフェースを示す。バス140には、CPU112、ROM113、RAM114、記憶装置115、入力I/F116、出力I/F117、通信I/F118、及び必要に応じて読取装置119が接続されている。
CPU112は、記憶装置115から本実施形態に係るプログラムを読み出し、サーバ13として機能する場合には、ユーザ情報登録部63、関係付け部64、取得部65、支払額決定部66、決済処理部67、金額管理部68として当該プログラムを実行する。ROM113は、読み出し専用のメモリを示す。RAM114は、一時的に記憶するメモリである。
記憶装置115は、大容量の情報を記憶する装置である。記憶装置115としては、ハードディスク、ソリッドステートドライブ(SSD)、フラッシュメモリカードなど様々な形式の記憶装置を使用することができる。記憶装置115には、本発明の実施形態に係るプログラムや、記憶部70に格納されている各種データが記憶されている。
入力I/F116は、キーボード、マウス、電子カメラ、ウェブカメラ、マイク、スキャナ、センサ、タブレット、タッチパネル、情報読取装置等の入力装置と接続することが可能である。また、出力I/F117は、ディスプレイ、タッチパネル、プロジェクタ、プリンタ、スピーカ等の出力装置と接続することが可能である。
通信I/F118は、通信ネットワークと接続して他の装置と通信するためのポート等のインターフェースである。通信ネットワークは、インターネット、ローカルエリアネットワーク(LAN)、ワイドエリアネットワーク(WAN)、専用線、有線、無線等の通信網であってよい。読取装置119は、可搬型記録媒体を読み出す装置である。
上記実施形態で説明した処理を実現するプログラムは、プログラム提供者側から通信ネットワークおよび通信I/F118を介して、例えば記憶装置115に格納されてもよい。また、上記実施形態で説明した処理を実現するプログラムは、市販され、流通している可搬型記憶媒体に格納されていてもよい。この場合、この可搬型記憶媒体は読取装置115にセットされて、CPU112によってそのプログラムが読み出されて、実行されてもよい。可搬型記憶媒体としてはCD-ROM、フレキシブルディスク、光ディスク、光磁気ディスク、ICカード、USBメモリ装置、半導体メモリカードなど様々な形式の記憶媒体を使用することができる。このような記憶媒体に格納されたプログラムが読取装置119によって読み取られる。
また、当該プログラムは、スタンドアローン型のコンピュータにインストールされてもよいし、クラウドコンピュータによりインストールされて機能のみをユーザに提供してもよい。
本実施形態によれば、後払い方式での割り勘での決済処理の効率化を図ることができる。すなわち、後払い形式において、クレジットカード会社での決済の前に購入金額を割り勘した後にユーザ毎にクレジットカード会社での決済処理をすることができるので、時間も短く、余計な手間をかけずに効率的に決済処理を行うことができる。
以上、実施形態、変形例に基づき本態様について説明してきたが、上記した態様の実施の形態は、本態様の理解を容易にするためのものであり、本態様を限定するものではない。本態様は、その趣旨並びに特許請求の範囲を逸脱することなく、変更、改良され得ると共に、本態様にはその等価物が含まれる。また、その技術的特徴が本明細書中に必須なものとして説明されていなければ、適宜、削除することができる。