JP2015049589A - 情報処理システム、売買支援サーバ、販売者端末および購入者端末 - Google Patents
情報処理システム、売買支援サーバ、販売者端末および購入者端末 Download PDFInfo
- Publication number
- JP2015049589A JP2015049589A JP2013179485A JP2013179485A JP2015049589A JP 2015049589 A JP2015049589 A JP 2015049589A JP 2013179485 A JP2013179485 A JP 2013179485A JP 2013179485 A JP2013179485 A JP 2013179485A JP 2015049589 A JP2015049589 A JP 2015049589A
- Authority
- JP
- Japan
- Prior art keywords
- store
- information
- purchaser
- terminal
- user
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Abstract
【課題】購入者が来訪日時を予め指定し、来訪を予約する店舗における商品またはサービスの販売を効果的に支援する。【解決手段】売買支援サーバ14は、販売者の店舗への購入者の来訪予約を示す情報であり、来訪時刻を含む予約情報を購入者端末10から取得する。そして、購入者の画像と来訪時刻を店舗端末12へ通知する。店舗端末12は、販売者の店舗にて購入者が商品またはサービスを購入する際に購入者の画像を販売者に選択させるための選択画面を表示させ、購入者の来訪時刻を含む所定期間内に購入者の画像を選択画面に表示させる。店舗端末12は、販売者が選択画面で選択した購入者を指定した決済要求を売買支援サーバ14へ通知する。売買支援サーバ14は、決済要求で指定された購入者の情報を使用して、商品またはサービス代金の電子決済を実行させる。【選択図】図1
Description
本発明はデータ処理技術に関し、特に商品またはサービスの売買を支援するための情報処理技術に関する。
スマートフォンやタブレット端末の急速な普及は、決済の分野においても大きな影響を与えている。近年、スマートフォンやタブレット端末をクレジットカード決済端末へ応用するソリューションも登場してきている。
また同様の端末を活用して、ユーザの「顔(写真)」と「名前」を利用したクレジットカード決済サービスも登場してきている。このサービスでは、ユーザの端末にて実在する店舗を指定するチェックイン操作を行なうと、ユーザの情報が店舗側へ通知され、ユーザの顔写真と名前が店舗端末に表示される。その後、ユーザが実際に来店して商品を購入する際に、ユーザの「顔」と「名前」の確認をもって決済を完了させるという手法である。
スマホで簡単にカード決済ができる「PayPal Here」、7月に本格導入,[online],2012年 5月 9日,URL,http://www.itmedia.co.jp/mobile/articles/1205/09/news121.html
商品またはサービスの購入者(利用者)によるチェックインという行為は、商品またはサービスの販売者(提供者)の店舗への来訪予定を示す購入者の意思表明といえる。典型的には来訪日時は約束されない。その一方、販売者の店舗の中には、購入者が店舗への来訪日時を予め指定し、来訪を予約するタイプの店舗も存在する。本発明者は、このようなタイプの店舗においても、購入者の顔と名前を利用したカード決済サービスは有用であるが、その具体的な仕組みはこれまで十分に提案されてこなかったと考えた。
本発明は発明者による上記課題認識に基づきなされたものであり、その主な目的は、購入者が来訪を予約する店舗における商品またはサービスの販売を効果的に支援するための技術を提供することにある。
上記課題を解決するために、本発明のある態様の情報処理システムは、商品またはサービスの販売者の端末と、通信網を介して販売者の端末と接続されるサーバと、を備える。サーバは、販売者の店舗への購入者の来訪予約を示す予約情報を、販売者の端末または購入者の端末から取得する予約情報取得部と、予約情報が取得された場合に、販売者の店舗への来訪予約を行った購入者の外見を示す画像を販売者の端末へ提供する購入者画像提供部と、を含む。販売者の端末は、販売者の店舗にて購入者が商品またはサービスを購入する際に購入者の画像を販売者に選択させるための選択画面を表示させる選択画面表示部と、選択画面において選択された購入者を指定した決済要求をサーバへ通知する決済要求通知部と、を含む。サーバは、購入者が商品またはサービスの代金を電子決済するために必要な情報である決済情報を保持する決済情報保持部と、販売者の端末から通知された決済要求で指定された購入者の決済情報を使用して、商品またはサービスの代金の電子決済を実行させる決済処理部と、をさらに含む。
本発明の別の態様は、売買支援サーバである。この売買支援サーバは、商品またはサービスの販売者の端末と通信網を介して接続されるサーバであって、購入者が商品またはサービスの代金を電子決済するために必要な情報である決済情報を保持する決済情報保持部と、販売者の店舗への購入者の来訪予約を示す予約情報を、販売者の端末または購入者の端末から取得する予約情報取得部と、予約情報が取得された場合に、販売者の店舗への来訪予約を行った購入者の外見を示す画像を販売者の端末へ提供することにより、販売者の店舗にて購入者が商品またはサービスを購入する際に購入者の画像を販売者に選択させるための選択画面を販売者の端末に表示させる購入者画像提供部と、販売者の端末において販売者が選択した購入者の画像に対応する購入者の情報を指定した決済要求を販売者の端末から受け付ける決済要求受付部と、販売者の端末から通知された決済要求で指定された購入者の決済情報を使用して、商品またはサービスの代金の電子決済を実行させる決済処理部と、を備える。
本発明のさらに別の態様は、商品またはサービスの販売者端末である。この商品またはサービスの販売者端末は、商品またはサービスの販売者の端末であって、サーバが、販売者の店舗への購入者の来訪予約を示す予約情報を、当該販売者の端末または購入者の端末から取得した場合に、サーバから提供された販売者の店舗への来訪予約を行った購入者の外見を示す画像を取得する購入者画像取得部と、販売者の店舗にて購入者が商品またはサービスを購入する際に購入者の画像を販売者に選択させるための選択画面を表示させる選択画面表示部と、選択画面において選択された購入者を指定した決済要求をサーバへ通知することにより、その購入者の情報を使用した商品またはサービスの代金の電子決済をサーバに実行させる決済要求通知部と、を備える。
本発明のさらに別の態様は、商品またはサービスの購入者端末である。この商品またはサービスの購入者端末は、商品またはサービスの購入者の端末であって、商品またはサービスの販売者の店舗への来訪を予約するための所定の操作入力を購入者から受け付ける受付部と、所定の操作入力が受け付けられた場合に、販売者の店舗への購入者の来訪予約を示す予約情報をサーバへ通知することにより、サーバに、購入者へ通知すべき第1の照合情報を特定可能な第2の照合情報を、購入者に対応づけて記録させるとともに、購入者の外見を示す画像を販売者の端末へ提供させ、販売者の端末において、販売者の店舗にて購入者が商品またはサービスを購入する際に購入者の画像を販売者に選択させるための選択画面に購入者の画像を表示させる予約情報通知部と、購入者が販売者の店舗にて商品を購入する際に、販売者の端末に、販売者が選択した購入者画像に対応する購入者の情報と、販売者の端末が購入者から取得した第1の照合情報とを指定した決済要求をサーバへ通知させ、サーバに、決済要求で指定された第1の照合情報に対応づけてサーバが記録していた第2の照合情報との整合有無にもとづいて商品またはサービスの代金の電子決済の許否を判定させるために、購入者による所定の操作入力への応答として、新たに生成された第1の照合情報を画面に表示させることにより、第1の照合情報を購入者へ通知する照合情報通知部と、を備える。
なお、以上の構成要素の任意の組合せ、本発明の表現を方法、プログラム、プログラムを格納した記録媒体などの間で変換したものもまた、本発明の態様として有効である。
本発明によれば、購入者が来訪を予約する店舗における商品またはサービスの販売を支援することができる。
以下、商品またはサービスの購入者の顔と名前を利用したカード決済サービス、いわば「顔パス決済」に関する複数の実施の形態を説明する。具体的には、第1の実施の形態として、顔パス決済による決済の利便性と安全性の両立を支援するための商品売買システムを説明する。また第2の実施の形態として、精度の高い待ち時間をユーザへ提供することで、サービス購入の利便性を一層高める商品売買システムを説明する。また第3の実施の形態として、移動販売店舗での商品販売に顔パス決済の利便性を提供する商品売買システムを説明する。
また第4の実施の形態として、商品またはサービスの購入者が来訪日時を予め指定し、来訪を予約する店舗における顔パス決済を支援する商品売買システムを説明する。また第5の実施の形態として、音響通信を使用して自動チェックインを実現する商品売買システムを説明する。各実施の形態に記載した技術は、他の実施の形態および変形例に記載の技術を前提として実現されてもよく、言い換えれば、他の実施の形態および変形例に記載の技術との任意の組み合わせが可能なことはもちろんである。
(第1の実施の形態)
第1の実施の形態では、「顔(写真)」と「名前」を利用した顔パス決済は維持しつつ、ワンタイムのコード(言わばワンタイムパスワード)を用いた本人確認を付加した商品売買システムを提案する。このシステムによると、顔パス決済による決済の簡便性・利便性は維持しつつ、本人確認の精度を向上させ、また、利用者側および店舗側の不正を抑制することができる。
第1の実施の形態では、「顔(写真)」と「名前」を利用した顔パス決済は維持しつつ、ワンタイムのコード(言わばワンタイムパスワード)を用いた本人確認を付加した商品売買システムを提案する。このシステムによると、顔パス決済による決済の簡便性・利便性は維持しつつ、本人確認の精度を向上させ、また、利用者側および店舗側の不正を抑制することができる。
図1は、第1の実施の形態の商品売買システム100の構成を示す。商品売買システム100は、購入者端末10で総称される購入者端末10a、購入者端末10b、購入者端末10cと、店舗端末12で総称される店舗端末12a、店舗端末12b、店舗端末12cと、売買支援サーバ14と、決済サーバ16を備える。図1の各装置は、LAN・WAN・インターネット等を含む無線および有線の通信網を介して接続される。
購入者端末10a〜10cは、商品を購入する立場のユーザであり、商品購入時に顔パス決済を利用する複数のユーザ(以下、「利用者」と呼ぶ。)がそれぞれ保持する情報処理端末である。購入者端末10は、好適には利用者が移動時に携帯する携帯情報端末であり、例えばスマートフォンである。変形例として、利用者宅に設置された据置型のPCであってもよい。
店舗端末12a〜12cは、現実世界に実在する複数の店舗のそれぞれに設置され、各店舗の販売員(従業員)により操作される情報処理端末である。本実施の形態の店舗端末12はタブレット端末(タブレットコンピュータ)であることとする。店舗端末12には、商品販売に係る会計処理や決済処理を実行するためのアプリケーション、言わばレジ機能を実現するためのアプリケーションがインストールされている。
売買支援サーバ14は、通信網を介して購入者端末10、店舗端末12、決済サーバ16とデータを送受する情報処理装置である。売買支援サーバ14は、利用者が店舗へ実際に来店して商品を購入する行為を支援する利用者向けサービス、および、店舗にて商品を販売する行為を支援するための店舗向けサービスを提供する。
決済サーバ16は、クレジットカード会社や銀行等の金融機関に設置された情報処理装置であり、売買支援サーバ14からの決済指示にしたがって電子決済処理を実行する。本実施の形態ではクレジットカード決済を実行する。
次に、購入者端末10、店舗端末12、売買支援サーバ14の構成を詳細に説明する。
図2は、図1の購入者端末10の機能構成を示すブロック図である。購入者端末10は、タッチパネル20と制御部24を備える。制御部24は、操作検出部26と、表示制御部28と、通信処理部30と、商品購入支援部32を含む。
図2は、図1の購入者端末10の機能構成を示すブロック図である。購入者端末10は、タッチパネル20と制御部24を備える。制御部24は、操作検出部26と、表示制御部28と、通信処理部30と、商品購入支援部32を含む。
本明細書のブロック図で示す各ブロックは、ハードウェア的には、コンピュータのCPUやメモリをはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウェア、ソフトウェアの組合せによっていろいろなかたちで実現できることは、当業者には理解されるところである。以降のブロック図についても同様である。
例えば、制御部24内の各機能ブロックに対応するプログラムモジュールが購入者端末10のフラッシュメモリ等のストレージに格納され、購入者端末10のCPUがそれらのプログラムモジュールをメインメモリへ読み出して実行することにより制御部24の機能が実現されてもよい。また、制御部24は、ストレージやメインメモリ等の記憶領域へ各種データを記憶させ、そのデータを参照して各機能ブロックに係るデータ処理を実行してもよい。また、商品購入支援部32に対応するアプリケーションソフトウェアが、記録メディアもしくはダウンロード形式にて配布され、購入者端末10にインストールされてもよい。
タッチパネル20は、入力装置(例えばタッチパッド)と一体形成された表示装置(例えば液晶パネル)である。操作検出部26はタッチパネルドライバとしての機能を提供し、例えば、タッチパネル20に対する利用者の操作入力を検出し、その操作内容を商品購入支援部32に渡す。表示制御部28もタッチパネルドライバとしての機能を提供し、例えば、商品購入支援部32から渡されたテキストデータや画像データをタッチパネル20に表示させる。
通信処理部30は外部装置との無線通信を制御する。実施の形態において、通信処理部30は、商品購入支援部32から渡されたデータを売買支援サーバ14へ送信する。また、売買支援サーバ14から送信されたデータを受信して、そのデータを商品購入支援部32へ渡す。
商品購入支援部32は、商品購入支援アプリケーション、具体的には、顔パス決済サービスを利用するための利用者側アプリケーションの機能を提供する。商品購入支援部32は、利用者情報登録部34と、購入支援画面表示部36と、サービス情報取得部38と、チェックイン通知部40と、ワンタイムコード生成部42を含む。
利用者情報登録部34は、顔パス決済を利用するために必要な利用者に関する属性情報を売買支援サーバ14へ登録する。この属性情報には、利用者ID、利用者の氏名、顔写真、クレジットカード決済に必要なクレジットカード情報(例えばクレジットカード種類、カード番号、生年月日、有効期限等)が含まれる。利用者情報登録部34は、利用者に自身の属性情報を入力させるための登録画面をタッチパネル20に表示させてもよい。
購入支援画面表示部36は、顔パス決済サービスにおける利用者用の画面(以下、「商品購入支援画面」とも呼ぶ。)をタッチパネル20に表示させる。商品購入支援画面には、(1)初期画面としての売買支援サーバ14へのログイン画面、(2)顔パス決済サービスを提供するサービス事業者(ブランド)の選択画面、(3)サービス事業者が運営する店舗の選択画面、(4)店舗の詳細情報を表示する店舗詳細画面、(5)店舗にチェックインした場合のチェックイン画面が含まれる。購入支援画面表示部36は、これら複数種類の商品購入支援画面を、利用者の操作に応じて順次切り替えて表示させる。
サービス情報取得部38は、複数種類の商品購入支援画面のそれぞれに表示させるべき情報を売買支援サーバ14から取得する。例えば、(2)サービス事業者選択画面用の情報として、サービス事業者やブランドのID、名称、ロゴ、説明文等を取得する。また、(3)店舗選択画面および(4)店舗詳細画面用の情報として、サービス事業者が運営する複数の店舗それぞれの店舗ID、店舗名、営業時間、住所等を取得する。サービス情報取得部38は、これらのサービス事業者情報や店舗情報を売買支援サーバ14から定期的に取得して所定の記憶領域へ格納してもよく、商品購入支援画面が表示される際に売買支援サーバ14から取得してもよい。
操作検出部26は、(4)店舗詳細画面において、詳細情報を表示中の店舗に対して利用者がチェックインすることを示す所定操作(以下、「チェックイン操作」とも呼ぶ。)がなされたことを検出する。本実施の形態において「チェックイン」は、特定の店舗への来訪を利用者が予定したこと、言い換えれば、未確定であるが特定の店舗への来訪を利用者が企図したこととして位置づけられる。チェックイン通知部40は、チェックイン操作が検出された場合に、その旨を示すチェックイン情報を売買支援サーバ14へ送信する。このチェックイン情報には、利用者IDと、チェックイン対象のサービス事業者IDおよび店舗IDが含まれる。
ワンタイムコード生成部42は、チェックイン情報の通知に対する応答として売買支援サーバ14から送信された乱数列を取得する。ワンタイムコード生成部42は、予め定められた確認コード生成関数に、売買支援サーバ14から取得した乱数列を入力し、その乱数列にもとづく確認コードを生成する。この確認コードは、今回のチェックインに限り一時的に有効な照合情報であり、いわゆるワンタイムパスワードである。本実施の形態では、確認コードが4桁の数字列(0000〜9999)であることとする。購入支援画面表示部36は、ワンタイムコード生成部42が生成した確認コードを(5)チェックイン画面において表示させる。なお購入者端末10は、画面表示以外の方法で確認コードを利用者へ通知してもよく、例えば確認コードを音声出力してもよい。
図3は、図1の店舗端末12の機能構成を示すブロック図である。店舗端末12は、タッチパネル50とチェックイン情報保持部54と制御部56を備える。制御部56は、操作検出部58と、表示制御部60と、通信処理部62と、商品販売支援部64を含む。
一部既述したが、制御部56内の各機能ブロックに対応するプログラムモジュールが店舗端末12のフラッシュメモリ等のストレージに格納され、店舗端末12のCPUがそれらのプログラムモジュールをメインメモリへ読み出して実行することにより制御部56の機能が実現されてもよい。また、制御部56は、ストレージやメインメモリ等の記憶装置へ各種データを記憶させ、そのデータを参照して各機能ブロックに係るデータ処理を実行してもよい。また、商品販売支援部64に対応するアプリケーションソフトウェアが記録メディアもしくはダウンロード形式にて配布され、店舗端末12にインストールされてもよい。また、チェックイン情報保持部54の機能は、店舗端末12のストレージやメインメモリ等の記憶装置により実現されてもよい。
タッチパネル50、操作検出部58、表示制御部60、通信処理部62の機能は、購入者端末10のタッチパネル20、操作検出部26、表示制御部28、通信処理部30の機能と同じであるため説明を省略する。
チェックイン情報保持部54は、自店舗に対してチェックインした利用者、すなわち自店舗へ来店予定の利用者に関する属性情報(以下では「店舗用チェックイン情報」とも呼ぶ。)を保持する。図4は、店舗用チェックイン情報の構成を示す。店舗用チェックイン情報には、利用者のID、氏名、顔写真画像、クレジットカード情報(一部)が含まれる。このクレジットカード情報は、売買支援サーバ14に登録された利用者のクレジットカード情報を、店舗販売員に開示可能な範囲に限定したものであり、例えばクレジットカードの種類と有効期限であってもよい。
図3に戻り、商品販売支援部64は、商品販売支援アプリケーション、具体的には、顔パス決済サービスを利用するための店舗側アプリケーションの機能を提供する。商品販売支援部64は、販売支援画面表示部66と、商品情報取得部68と、チェックイン情報更新部70と、ワンタイムコード取得部72と、決済要求通知部74と、結果取得部76を含む。
販売支援画面表示部66は、顔パス決済サービスにおける店舗用の画面(以下、「商品販売支援画面」とも呼ぶ。)をタッチパネル50に表示させる。商品販売支援画面には、(1)初期画面としてのメニュー選択画面(会計メニューや管理メニュー等)、(2)利用者の購入商品を選択する商品選択画面、(3)決済手段を選択するための会計画面、(4)顔パス決済を行なうための顔パス決済画面、(5)決済の結果を示す決済結果画面が含まれる。販売支援画面表示部66は、これら複数種類の商品販売支援画面を、店舗販売員の操作に応じて順次切り替えて表示させる。
商品情報取得部68は、商品販売支援画面の(2)商品選択画面に表示させるべき商品情報を売買支援サーバ14から取得する。この商品情報には、商品名、商品画像、販売価格が含まれる。商品情報取得部68は、商品情報を売買支援サーバ14から定期的に取得して所定の記憶領域へ格納してもよく、商品選択画面が表示される際に売買支援サーバ14から取得してもよい。
チェックイン情報更新部70は、自店舗に対してチェックインした利用者に関する属性情報である店舗用チェックイン情報(図4)を売買支援サーバ14から取得してチェックイン情報保持部54へ格納する。本実施の形態では、売買支援サーバ14は、公知のプッシュ通知(Push Notification)の仕組みにより店舗用チェックイン情報を店舗端末12へ提供する。チェックイン情報更新部70は、売買支援サーバ14からプッシュ通知された店舗用チェックイン情報を、不図示の仲介サーバを介して取得してもよい。
ワンタイムコード取得部72は、利用者へ予め通知された確認コードを取得する。本実施の形態では、利用者による確認コードの口頭申告を受けた店舗販売員が商品販売支援画面の(4)顔パス決済画面に対して入力した確認コードを取得する。決済要求通知部74は、顔パス決済の実行操作が店舗販売員によりなされた際に、顔写真が選択された利用者のID、サービス事業者ID、店舗ID、決済金額、支払条件、ワンタイムコード取得部72が取得した確認コード等を含む決済要求を売買支援サーバ14へ送信する。後述するように、決済要求において確認コードを売買支援サーバ14へ通知することで、利用者が申告した確認コードと、売買支援サーバ14側が期待する確認コードとの整合有無を売買支援サーバ14に確認させ、利用者が申告した確認コードの正当性を判定させる。
結果取得部76は、決済要求への応答として売買支援サーバ14から提供された決済結果情報を取得する。販売支援画面表示部66は、商品販売支援画面の(5)決済結果画面に、売買支援サーバ14から提供された決済結果情報を表示させる。チェックイン情報更新部70は、結果取得部76が決済結果を受け付けたことを契機として、典型的には商品代金の決済完了を契機として、チェックイン情報保持部54から、決済を行なった利用者のレコードを削除する。店舗販売員は、商品購入時に利用者から確認コードを申告されて、申告コードを知る立場になっている。チェックイン後の決済処理が完了した店舗用チェックイン情報を削除することにより、店舗販売員の不正を防止できる。
図5は、図1の売買支援サーバ14の構成を示すブロック図である。売買支援サーバ14は、サービス情報保持部110と、利用者情報保持部111と、店舗情報保持部112と、制御部114を備える。制御部114は、利用者情報記録部116と、商品情報記録部118と、チェックイン受付部120と、乱数取得部122と、乱数提供部124と、チェックイン情報提供部126と、決済要求受付部128と、決済許否判定部130と、決済処理部132と、結果通知部134を含む。
一部既述したが、制御部114内の各機能ブロックに対応するプログラムモジュールが売買支援サーバ14のハードディスク等のストレージに格納され、売買支援サーバ14のCPUがそれらのプログラムモジュールをメインメモリへ適宜読み出して実行することにより制御部114の機能が実現されてもよい。また、制御部114は、ストレージやメインメモリ等の記憶装置へ各種データを記憶させ、そのデータを参照して各機能ブロックに係るデータ処理を実行してもよい。また、サービス情報保持部110、利用者情報保持部111、店舗情報保持部112の機能は、売買支援サーバ14のストレージやメインメモリ等の記憶装置により実現されてもよい。
サービス情報保持部110は、顔パス決済サービスを提供するサービス事業者に関する情報と、サービス事業者が運営する店舗の情報をサービス情報として保持する記憶領域である。このサービス情報は、購入者端末10の商品購入支援画面において表示させるべき情報でもあり、商品売買システム100の管理者により予め設定される。
利用者情報保持部111は、顔パス決済サービスにおける利用者の情報(以下、「利用者登録情報」とも呼ぶ。)と、利用者がチェックインしたことに関する情報(以下、「利用者チェックイン情報」とも呼ぶ。)を保持する記憶領域である。図6(a)は利用者登録情報の構成を示す。利用者登録情報には、購入者端末10により登録された利用者のID、氏名、顔写真画像、決済に必要なクレジットカードの全情報が含まれる。また図6(b)は利用者チェックイン情報の構成を示す。利用者チェックイン情報には、購入者端末10から通知された利用者ID、チェックイン対象のサービス事業者ID、店舗ID、後述する乱数列および顔パス有効期限が含まれる。
図5に戻り、店舗情報保持部112は、個々の店舗に関する情報(以下、「店舗個別情報」とも呼ぶ。)を保持する。店舗個別情報には、サービス事業者ID、店舗ID、店舗端末情報、商品情報が含まれる。店舗端末情報は、チェックイン情報をプッシュ通知するために必要な店舗端末12の情報を含む。例えば、店舗端末12のIPアドレスであってもよく、個体識別番号(UID)であってもよい。商品情報は、店舗で販売される商品の名称、画像、販売価格を含む。
図5には不図示であるが、売買支援サーバ14は、サービス情報保持部110に保持されたサービス情報を、定期的もしくは購入者端末10の要求に応じて購入者端末10へ提供するサービス情報提供部をさらに備えてもよい。また売買支援サーバ14は、店舗情報保持部112に保持された商品情報を、定期的もしくは店舗端末12の要求に応じて店舗端末12へ提供する商品情報提供部をさらに備えてもよい。
利用者情報記録部116は、購入者端末10から登録された利用者の属性情報を利用者登録情報(図6(a))として利用者情報保持部111へ格納する。商品情報記録部118は、サービス事業者や店舗の情報端末(例えば店舗端末12)から登録された商品情報を受け付け、店舗情報保持部112の商品情報を更新する。
チェックイン受付部120は、購入者端末10から通知されたチェックイン情報を受け付け、利用者チェックイン情報(図6(b))として利用者情報保持部111へ格納する。その際に、チェックイン受付部120は、チェックイン情報の受付日時から所定時間経過した日時(例えば1時間後の日時)を顔パス有効期限として利用者チェックイン情報に設定する。
乱数取得部122は、チェックイン情報が受け付けられた際に、所定の乱数発生器で生成された乱数列を取得する。この乱数列の値は、数学的に発生させる乱数でなくてもよく、ハードウエア乱数やソフトウエア乱数などにより発生させる疑似乱数でもよい。乱数取得部122は、取得した乱数列のデータを、利用者情報保持部111の利用者チェックイン情報に設定する。乱数提供部124は、乱数取得部122が取得した乱数列のデータを、チェックイン情報の通知に対する応答として購入者端末10へ送信する。
チェックイン情報提供部126は、チェックイン情報が受け付けられた際に、チェックインを行なった利用者のIDをキーとして、利用者情報保持部111の利用者登録情報から、店舗端末12へ提供すべき店舗用チェックイン情報(図4)を抽出する。チェックイン情報提供部126は、設定した店舗用チェックイン情報を、公知のプッシュ通知の方法により店舗端末12へ送信する。
決済要求受付部128は、店舗端末12から送信された決済要求を受け付ける。決済許否判定部130は、利用者情報保持部111の利用者チェックイン情報を参照して、決済要求で指定された利用者ID、サービス事業者ID、店舗IDと対応づけられた乱数列および顔パス有効期限を特定する。決済要求受付日時(典型的には現在日時)が顔パス有効期限を途過していた場合、決済許否判定部130は、決済の実行を拒否する。
決済要求受付日時が顔パス有効期限内であった場合、決済許否判定部130は、決済要求で指定された確認コード(ここでは「第1コード」と呼ぶ。)と、特定した乱数列とにもとづいて決済許否を判定する。具体的には、購入者端末10で用いられた確認コード生成関数と同じ関数に乱数列を入力し、この乱数列にもとづく確認コード(ここでは「第2コード」と呼ぶ。)を生成する。そして、第1コードと第2コードとを照合し、両者が一致する場合に、正当な確認コードを受け付けたこととして決済の実行を許可し、相違する場合は決済の実行を拒否する。
決済処理部132は、決済許否判定部130が決済の実行を許可した場合に決済処理を実行する。具体的には、利用者情報保持部111の利用者登録情報に保持されたクレジットカード情報と、決済要求で指定された決済金額および支払条件(支払回数等)を指定した決済指示データを決済サーバ16へ送信する。決済処理部132は、決済サーバ16によるクレジットカード決済の成否を示す情報を決済サーバ16から取得する。
結果通知部134は、決済許否判定結果および決済処理の成否を示す情報を決済結果情報として店舗端末12へ送信する。例えば、顔パス有効期限切れであった場合、顔パス有効期限切れのため決済を拒否する旨の情報であり、新たなチェックイン操作を利用者に促すための情報を決済結果情報として店舗端末12へ提供する。また利用者が申告した確認コードが不正(すなわち第2コードと不一致)であった場合、確認コードが不正である旨の情報を決済結果情報として店舗端末12へ提供する。変形例として、結果通知部134は、決済が失敗となった店舗名を含む情報であり、新たなチェックイン操作を利用者に促すための情報を購入者端末10へ送信してもよい。
以上の構成による商品売買システム100の動作を以下説明する。
顔パス決済サービスの利用前に、利用者は、顔パス決済のための必要情報を売買支援サーバ14へ登録する。この必要情報には、利用者ID、利用者の氏名、顔写真、クレジットカード決済に必要なクレジットカード情報(例えばクレジットカード種類、カード番号、生年月日、有効期限等)が含まれる。売買支援サーバ14の利用者情報記録部116は、利用者登録情報を利用者情報保持部111へ格納する。また、サービス事業者は店舗で販売する商品情報を売買支援サーバ14へ登録し、売買支援サーバ14の商品情報記録部118は商品情報を店舗情報保持部112へ格納する。
顔パス決済サービスの利用前に、利用者は、顔パス決済のための必要情報を売買支援サーバ14へ登録する。この必要情報には、利用者ID、利用者の氏名、顔写真、クレジットカード決済に必要なクレジットカード情報(例えばクレジットカード種類、カード番号、生年月日、有効期限等)が含まれる。売買支援サーバ14の利用者情報記録部116は、利用者登録情報を利用者情報保持部111へ格納する。また、サービス事業者は店舗で販売する商品情報を売買支援サーバ14へ登録し、売買支援サーバ14の商品情報記録部118は商品情報を店舗情報保持部112へ格納する。
(例えば外出中に)利用者は、店舗へ立ち寄ることを思いつくと、購入者端末10にて商品購入支援アプリケーションを起動する。購入者端末10のサービス情報取得部38は、商品購入支援画面に表示させるべきデータを売買支援サーバ14から取得する。購入者端末10の購入支援画面表示部36は、商品購入支援画面として、ログイン画面、サービス事業者選択画面、店舗選択画面を順次表示させた後、店舗選択画面で選択された店舗の詳細情報を示す店舗詳細画面を表示させる。図7は店舗詳細画面を示す。店舗詳細画面140には顔パス決済選択フィールド142が含まれる。顔パス決済を希望する場合、利用者は顔パス決済選択フィールド142に対して所定のチェックイン操作(例えばタップ操作や所定方向へのフリック操作)を入力する。このチェックイン操作により、利用者は将来時点において店舗へ来訪する意志があることを示したこととなり、後述するように、来訪対象の店舗へ利用者の情報が通知される。
店舗詳細画面140においてチェックイン操作が検出されると、購入者端末10のチェックイン通知部40は、チェックイン情報を売買支援サーバ14へ送信する。売買支援サーバ14のチェックイン受付部120は、受け付けたチェックイン情報を利用者チェックイン情報として利用者情報保持部111へ格納する。売買支援サーバ14の乱数取得部122は、チェックイン受付部120がチェックイン情報を受け付けたことを契機として新たに生成された乱数列を取得して利用者チェックイン情報に記録する。売買支援サーバ14の乱数提供部124は、その乱数列のデータを購入者端末10へ送信する。
チェックイン情報通知に対する売買支援サーバ14の応答として乱数列を受信すると、購入者端末10のワンタイムコード生成部42は、売買支援サーバ14から提供された乱数列にしたがって新たに確認コードを生成する。そして販売支援画面表示部66は店舗へのチェックインを受け付けたことを示すチェックイン画面を表示させる。図8はチェックイン画面を示す。チェックイン画面150にはチェックインした利用者に関する情報を表示する利用者情報エリア152が含まれる。利用者情報エリア152には、利用者の写真画像154、氏名156、ワンタイムコード生成部42により生成された確認コード158を表示する。利用者はチェックイン画面150に表示された確認コード158を確認して(例えば記憶して)店舗へ来訪する。
また売買支援サーバ14のチェックイン情報提供部126は、チェックイン受付部120がチェックイン情報を受け付けると、利用者情報保持部111に格納された利用者登録情報から店舗用チェックイン情報を抽出し、その店舗用チェックイン情報を店舗端末12へ送信する。店舗端末12のチェックイン情報更新部70は、売買支援サーバ14から提供された店舗用チェックイン情報を取得してチェックイン情報保持部54へ格納する。
予めチェックインしておいた店舗へ利用者が来店し、購入希望商品を決定して店舗販売員に声をかけると、店舗販売員は店舗端末12を操作し、商品販売支援アプリケーションのメニュー選択画面で会計メニューを選択する。店舗端末12の商品情報取得部68は店舗で販売している商品情報を売買支援サーバ14から取得し、店舗端末12の販売支援画面表示部66は商品情報を並べた商品選択画面を表示させる。
図9は商品選択画面を示す。商品選択画面160の商品選択エリア162には、商品名と商品画像が配置される。明細エリア164には、店舗販売員が商品選択エリア162で選択した商品名と販売価格が表示される。また明細エリア164は、チェックイン状況フィールド166を含む。販売支援画面表示部66は、自店舗に現在チェックインしている利用者数をチェックイン状況フィールド166へ設定し、例えばチェックイン情報保持部54のレコード数をチェックイン状況フィールド166へ設定する。
また販売支援画面表示部66は、商品選択画面160の表示中に新たな店舗用チェックイン情報が売買支援サーバ14から受け付けられた場合(チェックイン情報保持部54に新たなレコードが挿入された場合)に、その店舗用チェックイン情報が示す利用者氏名および顔写真画像をポップアップ168に一時的に表示させる。すなわち、自店舗へのチェックインがあったとき、そのチェックインを行なった利用者の情報を商品選択画面160にポップアップ表示させる。購入される商品の選択が終了し、店舗販売員が会計ボタン170を押下すると、販売支援画面表示部66は、次に会計画面を表示させる。
図10は会計画面を示す。会計画面180は決済手段を選択する画面とも言える。会計画面180には、現金決済指定エリア182と顔パス決済指定エリア184とカード決済指定エリア188が含まれる。現金決済指定エリア182は、現金決済の場合に支払金額を入力するためのエリアである。顔パス決済指定エリア184は、顔パス決済の場合に購入者(すなわち店舗にて商品を購入しようとしている利用者)の顔写真186を選択するためのエリアである。カード決済指定エリア188は、利用者が保持しているクレジットカードの読み込みによるクレジットカード決済の場合に選択するエリアである。
本実施の形態では顔パス決済が選択されることとする。利用者は自身の氏名(ここでは「野村花子」)を店舗販売員へ申告する。店舗販売員は、顔パス決済指定エリア184に表示されたチェックイン済みの複数の利用者それぞれのアイテム(氏名と顔写真の組み合わせ)を確認する。店舗販売員は、利用者の外見を目視し、顔パス決済指定エリア184に表示された「野村花子」の顔写真186と一致することを確認した上で、「野村花子」の顔写真186に対する選択操作(例えばタップ操作)を入力する。販売支援画面表示部66は、次に顔パス決済画面を表示させる。
図11は顔パス決済画面を示す。顔パス決済画面190には、会計画面180で選択された利用者の顔写真192および氏名194、確認コード入力フィールド196、決定ボタン198が表示される。ここで利用者は、チェックイン時に確認した確認コードを店舗販売員へ申告する。店舗販売員は、申告された確認コードを確認コード入力フィールド196へ入力する。なお、顔パス決済画面190では支払条件(支払回数等)の変更も可能である。利用者の外見が顔写真192と一致し、利用者が申告した氏名が氏名194と一致することを店舗販売員が確認し、また、確認コード入力フィールド196への確認コードの入力を完了すると、店舗販売員は、決定ボタン198に対する選択操作を入力して決済処理を実行させる。
顔パス決済画面190において決定ボタン198の選択操作が検出されると、店舗端末12のワンタイムコード取得部72は、確認コード入力フィールド196に入力された確認コード(ここでは「申告コード」と呼ぶ。)を取得する。店舗端末12の決済要求通知部74は、申告コードを含む決済要求を売買支援サーバ14へ送信する。売買支援サーバ14の決済要求受付部128が決済要求を受け付けると、売買支援サーバ14の決済許否判定部130は、決済要求で指定された利用者IDにより利用者チェックイン情報を特定する。そして、利用者チェックイン情報の顔パス有効期限が未経過、かつ、利用者チェックイン情報の乱数列にしたがって、決済要求の受け付けを契機に新たに生成した確認コード(ここでは「照合コード」と呼ぶ。)と、決済要求で指定された申告コードとが整合する場合に、商品代金のクレジットカード決済を許可する。
決済許否判定部130によりクレジットカード決済が許可された場合に、決済処理部132は、決済指示を決済サーバ16へ送信し、商品代金の決済処理を実行させる。結果通知部134は、売買支援サーバ14および決済サーバ16における決済処理の結果を示す情報を店舗端末12へ送信する。店舗端末12の販売支援画面表示部66は、決済処理の結果を画面表示させる。店舗販売員は、決済処理の結果を確認し、決済が正常に完了した旨の内容であれば、商品の販売が正常に完了したとして商品を利用者へ引き渡す。売買支援サーバ14もしくは決済サーバ16において決済処理が拒否され、もしくは失敗した旨の内容であれば、店舗販売員はその旨を利用者へ伝え、例えば新たなチェックイン操作を利用者へ促す。
第1の実施の形態の商品売買システム100によると、利用者は店舗へチェックイン後、実際に店舗へ来訪して商品を購入する際に、氏名と確認コードを申告すれば商品代金の支払を完了できる。すなわち、現金やクレジットカード等の物理的な決済媒体を店舗で取り出すことなく、いわば「顔パス」で商品を購入できる。これにより、商品購入に係る利便性を高める。また、店舗に初めて来訪する場合や来店回数が少ないときでも、あたかも常連客であるかのように簡易な手続で商品を購入でき、利用者に優越感や満足感を抱かせやすくなる。
また商品売買システム100によると、店舗へのチェックイン時に利用者へワンタイムの確認コードを提示する。そして、商品購入時に利用者が申告した確認コードと、商品購入時に売買支援サーバ14側で生成した確認コードとが一致することを条件に、チェックインした人物と、店舗で商品を購入しようとする人物とが同一であると判定し、顔パス決済を許可する。このように、購入者の外見と顔写真とを店舗販売員が目視確認することに加えて、売買支援サーバ14による確認コードの照合処理を併用することで、不正な決済がなされてしまうことを効果的に抑制できる。
例えば、悪意のある第三者が別の利用者へなりすました場合も、その第三者が確認コードを知ることは困難であるため、利用者側の不正行為を効果的に防止できる。また、店舗販売員による購入者の誤認識や操作ミスが発生した場合、例えば顔写真の選択を誤った場合にも確認コードの不整合が検出されるため、誤った決済がなされることを防止できる。また、利用者が申告するまでは店舗販売員も確認コードを知り得ないため、店舗販売員による不正行為も効果的に防止できる。例えば、来店しない利用者の顔写真を指定して、実際には購入されていない商品の代金を不正に支払わせることを防止できる。
また商品売買システム100によると、利用者によるチェックイン後、所定の有効期間内(すなわち顔パス有効期限が未経過の間)に決済要求がなされることをさらなる条件として、顔パス決済を許可する。確認コードが利用者へ提示されてから時間が経過するほど、その確認コードが第三者へ漏洩する可能性は高まり、漏洩すると本人確認の精度が低下してしまう。本実施の形態では、顔パス有効期限を設けることにより、チェックインした人物と、店舗で商品を購入しようとする人物の同一性の確認精度の低下を抑制できる。
以上、第1の実施の形態を説明した。この実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。以下変形例を示す。
第1の実施の形態についての、第1の変形例を説明する。
上記実施の形態では、売買支援サーバ14は、利用者チェックイン情報として確認コードそのものではなく、確認コードの生成元データとしての乱数列を保持した。変形例として、利用者によるチェックイン操作時に、売買支援サーバ14の乱数取得部122は、乱数列をもとに確認コードを生成し、売買支援サーバ14は利用者チェックイン情報としてその確認コードを保持してもよい。また、売買支援サーバ14から購入者端末10へ乱数列を提供することに代えて確認コードを提供してもよい。また上記実施の形態では、利用者によるチェックイン操作時に、売買支援サーバ14が購入者端末10へ乱数列を送信することとした。変形例として、購入者端末10が乱数列を生成し、チェックイン情報に含めて売買支援サーバ14へ送信してもよい。また、購入者端末10が乱数列をもとに確認コードを生成して、その確認コードを売買支援サーバ14へ送信してもよい。このように請求項に記載の「第1の照合情報」と「第2の照合情報」は同じ内容であってもよい。
上記実施の形態では、売買支援サーバ14は、利用者チェックイン情報として確認コードそのものではなく、確認コードの生成元データとしての乱数列を保持した。変形例として、利用者によるチェックイン操作時に、売買支援サーバ14の乱数取得部122は、乱数列をもとに確認コードを生成し、売買支援サーバ14は利用者チェックイン情報としてその確認コードを保持してもよい。また、売買支援サーバ14から購入者端末10へ乱数列を提供することに代えて確認コードを提供してもよい。また上記実施の形態では、利用者によるチェックイン操作時に、売買支援サーバ14が購入者端末10へ乱数列を送信することとした。変形例として、購入者端末10が乱数列を生成し、チェックイン情報に含めて売買支援サーバ14へ送信してもよい。また、購入者端末10が乱数列をもとに確認コードを生成して、その確認コードを売買支援サーバ14へ送信してもよい。このように請求項に記載の「第1の照合情報」と「第2の照合情報」は同じ内容であってもよい。
第1の実施の形態についての、第2の変形例を説明する。
上記実施の形態では、利用者へ通知される確認コードは4桁の数字列とした。変形例として、確認コードは数字列以外の態様のデータでもよく、例えばバーコードやQRコード(登録商標)であってもよい。この場合に、利用者は店舗において確認コードを表示中の購入者端末10を提示し、店舗端末12のワンタイムコード取得部72は、バーコードリーダやQRコードリーダ等の所定の読取り装置を介して、確認コードの内容を取得してもよい。
上記実施の形態では、利用者へ通知される確認コードは4桁の数字列とした。変形例として、確認コードは数字列以外の態様のデータでもよく、例えばバーコードやQRコード(登録商標)であってもよい。この場合に、利用者は店舗において確認コードを表示中の購入者端末10を提示し、店舗端末12のワンタイムコード取得部72は、バーコードリーダやQRコードリーダ等の所定の読取り装置を介して、確認コードの内容を取得してもよい。
第1の実施の形態についての、第3の変形例を説明する。
購入者端末10は自動チェックイン機能を備えてもよい。この変形例では、売買支援サーバ14は、地図上での店舗の位置を示す位置情報(例えば緯度・経度の値)を保持する。購入者端末10のサービス情報取得部38は、売買支援サーバ14から、店舗の位置情報をさらに取得する。また購入者端末10は、GPS装置と位置判定部をさらに備える。GPS装置は、GPS衛星からGPS測位情報を受信し、受信情報から購入者端末10の現在位置を示す情報(例えば緯度・経度の値)を出力する。
購入者端末10は自動チェックイン機能を備えてもよい。この変形例では、売買支援サーバ14は、地図上での店舗の位置を示す位置情報(例えば緯度・経度の値)を保持する。購入者端末10のサービス情報取得部38は、売買支援サーバ14から、店舗の位置情報をさらに取得する。また購入者端末10は、GPS装置と位置判定部をさらに備える。GPS装置は、GPS衛星からGPS測位情報を受信し、受信情報から購入者端末10の現在位置を示す情報(例えば緯度・経度の値)を出力する。
位置判定部は、利用者が予め指定した店舗(以下、「指定店舗」とも呼ぶ。)の近傍に購入者端末10が存在するか否かを判定する。具体的には、指定店舗の所在地から所定の範囲(例えば半径100メートル)内に、GPS装置が出力した購入者端末10の現在位置が含まれる場合に、購入者端末10が指定店舗の近傍に存在すると判定する。チェックイン通知部40は、購入者端末10が指定店舗の近傍に存在すると判定された場合、自動的に指定店舗を指定したチェックイン情報を売買支援サーバ14へ送信する。購入支援画面表示部36は、自動チェックインにおいて生成された確認コードを、指定店舗の情報とともに、図8のチェックイン画面150と同様の自動チェックイン画面に表示させてもよい。
第1の実施の形態についての、第4の変形例を説明する。
購入者端末10および店舗端末12はシンクライアント(Thin Client)として実装されてもよい。例えば購入者端末10は、タッチパネル20への入力データを操作検出部26を介して取得し、売買支援サーバ14から取得された画面データを表示制御部28を介してタッチパネル20に表示させる画面表示部のみを備える構成であってもよい。同様に店舗端末12は、タッチパネル50への入力データを操作検出部58を介して取得し、売買支援サーバ14から取得された画面データを表示制御部60を介してタッチパネル50に表示させる画面表示部のみを備える構成であってもよい。購入者端末10および店舗端末12の画面表示部はウェブブラウザにより実現されてもよい。
購入者端末10および店舗端末12はシンクライアント(Thin Client)として実装されてもよい。例えば購入者端末10は、タッチパネル20への入力データを操作検出部26を介して取得し、売買支援サーバ14から取得された画面データを表示制御部28を介してタッチパネル20に表示させる画面表示部のみを備える構成であってもよい。同様に店舗端末12は、タッチパネル50への入力データを操作検出部58を介して取得し、売買支援サーバ14から取得された画面データを表示制御部60を介してタッチパネル50に表示させる画面表示部のみを備える構成であってもよい。購入者端末10および店舗端末12の画面表示部はウェブブラウザにより実現されてもよい。
この変形例において、売買支援サーバ14は、図2の商品購入支援部32、図3の商品販売支援部64に対応する機能を実現するためのデータ処理を一括して実行する。また売買支援サーバ14は、ウェブサーバの機能を有し、データ処理の結果を示す画面データを構造化文書(HTML、XML等)として購入者端末10および店舗端末12へ提供してもよい。
第1の実施の形態についての、第5の変形例を説明する。
売買支援サーバ14は、確認コードのロックアウト機能をさらに備えてもよい。この変形例では、売買支援サーバ14は、同一の利用者ID、サービス事業者ID、店舗IDを指定する決済要求を複数回受け付ける。そして、それぞれの決済要求で指定された確認コード(第1コード)と、上記の利用者ID、サービス事業者ID、店舗IDの組み合わせにより特定された乱数列にもとづく確認コード(第2コード)が不一致となり、その不一致の回数が所定の閾値(ここでは3回)に達した場合に、上記の利用者ID、サービス事業者ID、店舗IDの組み合わせにより特定された乱数列を無効にする。言い換えれば、事前の利用者のチェックインにより利用者へ提供した確認コードを無効なものとする。
売買支援サーバ14は、確認コードのロックアウト機能をさらに備えてもよい。この変形例では、売買支援サーバ14は、同一の利用者ID、サービス事業者ID、店舗IDを指定する決済要求を複数回受け付ける。そして、それぞれの決済要求で指定された確認コード(第1コード)と、上記の利用者ID、サービス事業者ID、店舗IDの組み合わせにより特定された乱数列にもとづく確認コード(第2コード)が不一致となり、その不一致の回数が所定の閾値(ここでは3回)に達した場合に、上記の利用者ID、サービス事業者ID、店舗IDの組み合わせにより特定された乱数列を無効にする。言い換えれば、事前の利用者のチェックインにより利用者へ提供した確認コードを無効なものとする。
例えば、利用者情報保持部111の利用者チェックイン情報には、照合失敗回数欄(初期値:0)と、無効フラグ欄(初期値:オフ)をさらに設けてもよい。決済許否判定部130は、第1コードと第2コードが不整合であった場合に、決済要求で指定された利用者ID、サービス事業者ID、店舗IDの組み合わせで特定される利用者チェックイン情報について、その照合失敗回数をインクリメントする。そして、照合失敗回数が3回に達すると、利用者チェックイン情報の無効フラグをオンに設定する。決済許否判定部130は、決済要求で指定された利用者ID、サービス事業者ID、店舗IDの組み合わせにより、まず利用者チェックイン情報の無効フラグを確認する。無効フラグがオンであれば、確認コードの照合処理をスキップし、すなわち第1コードと第2コードが一致するか否かにかかわらず、決済の実行を拒否する。結果通知部134は、確認コードが無効になった旨を示す情報であり、また、新たなチェックイン操作を利用者に促すための情報を店舗端末12または購入者端末10へ提供する。なお、新たなチェックインがなされた場合には、新たな乱数列(確認コード)が生成されて新たな利用者チェックイン情報が生成される。
本変形例では、確認コードの照合失敗が所定回数に達すると、利用者によるチェックイン時に発行された確認コードによる電子決済が拒否されることになる。これにより、悪意のある第三者による利用者へのなりすましや、店舗側の不正な決済要求による不正な決済の実行を防止しやすくなる。
次に、上記変形例に関連し、悪意のある第三者による利用者へのなりすましや、店舗側の不正な決済要求を抑制するためのさらなる変形例を説明する。売買支援サーバ14は、所定の条件が満たされた場合にチェックインを拒否するチェックイン判定部をさらに備えてもよい。チェックイン判定部は、第1の不正防止処理として、同日に規定回数以上のチェックインが繰り返された場合に、顔パス決済の利用を一時的に停止してもよい。また、チェックイン判定部は、第2の不正防止処理として、同一の端末から再チェックインが繰り返された場合に、当該端末による顔パス決済を一時的に停止してもよい。
チェックイン判定部の第1の不正防止処理を詳細に説明する。利用者情報保持部111は、当日日付、利用者ID、サービス事業者ID、店舗IDをキーとして、チェックイン回数(初期値:0)と対応づけたチェックイン履歴をさらに保持する。このチェックイン回数には、ある特定の日付における同一利用者による同一店舗へのチェックイン回数が記録される。チェックイン受付部120は、チェックイン情報を受け付けた場合に、当日日付と、チェックイン情報で指定された利用者ID、サービス事業者ID、店舗IDに対応する履歴が記録済みでなければ、チェックイン回数「1」を示すチェックイン履歴を新たに記録し、記録済みであれば、そのチェックイン回数をインクリメントする。
チェックイン判定部は、チェックイン受付部120がチェックイン情報を受け付けた場合に、当日日付、チェックイン情報で指定された利用者ID、サービス事業者ID、店舗IDに対応するチェックイン履歴を特定し、チェックイン回数が5回以下であった場合にチェックインを許可する。以降、乱数列および店舗用チェックイン情報の提供処理が継続される。その一方、チェックイン回数が6回以上であった場合、チェックイン判定部はチェックインを拒否する。この場合に、チェックイン判定部は、利用者による所定操作、例えば予め定められた本人確認操作がなされるまで、チェックイン回数が規定回数を超過した利用者からのチェックインを拒否し、確認コードの発行処理をスキップすることにより、顔パス決済を一時的に停止する。
チェックイン判定部の第2の不正防止処理を詳細に説明する。利用者情報保持部111は、上記第1の構成のチェックイン履歴にさらに端末IDを加えたチェックイン履歴を保持する。また購入者端末10からのチェックイン情報は購入者端末10の端末ID(例えば個体識別番号)をさらに含む。チェックイン受付部120は、チェックイン情報で指定された端末ID、利用者ID、サービス事業者ID、店舗IDをキーとして、チェックイン回数をインクリメントする。
チェックイン判定部は、チェックイン受付部120がチェックイン情報を受け付けた場合に、当日日付、チェックイン情報で指定された端末ID、利用者ID、サービス事業者ID、店舗IDに対応するチェックイン履歴を特定し、チェックイン回数が5回以下であった場合にチェックインを許可する。その一方、チェックイン回数が6回以上であった場合、チェックインを拒否する。この場合に、チェックイン判定部は、利用者による所定操作、例えば予め定められた本人確認操作がなされるまで、チェックイン回数が規定回数を超過した購入者端末10からのチェックインを拒否し、確認コードの発行処理をスキップすることにより、顔パス決済を一時的に停止する。なお、上記第1の不正防止処理と第2の不正防止処理のそれぞれは、第5の変形例に限らず、実施の形態の構成および他の変形例の構成と組み合わせてもよい。
第1の実施の形態についての、第6の変形例を説明する。
売買支援サーバ14は、利用者に対して発行される確認コードの重複を排除するための機能をさらに備えてもよい。既述したように、利用者情報保持部111の利用者チェックイン情報には、利用者IDと対応づけて乱数列が格納される。本変形例ではさらにチェックイン日時が格納されることとし、具体的には、チェックイン受付部120は、利用者チェックイン情報を記録する際に現在日時、言い換えれば、購入者端末10からチェックイン情報を受け付けた日時情報をさらに記録する。乱数取得部122は、利用者と確認コードをセットとして、同一人物に対して発行済みの確認コードと同じ確認コードを同日中に発行することを抑制する。確認コードのユニーク性を担保することで、確認コードの秘匿性を高め、悪意のある第三者や店舗による不正行為を防止しやすくなる。
売買支援サーバ14は、利用者に対して発行される確認コードの重複を排除するための機能をさらに備えてもよい。既述したように、利用者情報保持部111の利用者チェックイン情報には、利用者IDと対応づけて乱数列が格納される。本変形例ではさらにチェックイン日時が格納されることとし、具体的には、チェックイン受付部120は、利用者チェックイン情報を記録する際に現在日時、言い換えれば、購入者端末10からチェックイン情報を受け付けた日時情報をさらに記録する。乱数取得部122は、利用者と確認コードをセットとして、同一人物に対して発行済みの確認コードと同じ確認コードを同日中に発行することを抑制する。確認コードのユニーク性を担保することで、確認コードの秘匿性を高め、悪意のある第三者や店舗による不正行為を防止しやすくなる。
具体的には、乱数取得部122は、乱数発生器から乱数列を取得した際に、取得した乱数列と、チェックイン情報で指定された利用者IDとの組み合わせが、現在日付と対応づけられた既存の利用者チェックイン情報で設定済みか否かを確認する。既存の利用者チェックイン情報に未設定の場合、すなわち取得した乱数列と利用者IDの組み合わせがユニークであれば、乱数取得部122は、取得した乱数列を用いて以降の処理を実行する。その一方、取得した乱数列と利用者IDとの組み合わせが、既存の利用者チェックイン情報で設定済みの場合、すなわち取得した乱数列が当該利用者へ発行済みの乱数列と同じ値であれば、乱数取得部122は乱数発生器から乱数列を再度取得して、既存の利用者チェックイン情報との比較処理を再度実行する。
なお乱数取得部122は、現在日付と対応づけられた既存の利用者チェックイン情報のうち、顔パス有効期限が切れているものは比較対象から除外してもよい。言い換えれば、現在日付と対応づけられ、かつ、顔パス有効期限が未経過の既存の利用者チェックイン情報のみ比較対象として抽出してもよい。また、第1の変形例で既述したように、売買支援サーバ14が乱数列にもとづいて確認コードを生成する場合、利用者チェックイン情報には確認コードが格納されてよい。この場合に乱数取得部122は、生成した確認コードと、既存の利用者チェックイン情報との比較処理を実行してもよい。
また第5の変形例にも関連するが、第6の変形例においても、売買支援サーバ14は、チェックイン情報が受け付けられた際、所定の条件が満たされた場合にチェックインを拒否するチェックイン判定部をさらに備えてもよい。乱数取得部122は、チェックイン判定部が、以下の2つの判定処理の両方でチェックインを許可した(拒否しなかった)ことを条件として、上記の乱数列取得・比較処理を実行してもよい。チェックイン判定部は、第1の判定処理として、チェックインをする利用者が規定時間内に規定距離を超えていないかを判定し、第2の判定処理として、1人の利用者が短期間で大量のチェックインをしていないかを判定する。
チェックイン判定部の第1の判定処理を詳細に説明する。第3の変形例にも関連するが、売買支援サーバ14は、地図上での店舗の位置を示す位置情報(例えば緯度・経度の値)を保持する。チェックイン判定部は、今回受け付けられたチェックイン情報(以下、「当該チェックイン情報」とも呼ぶ。)のチェックイン日時と、店舗IDにより特定される店舗位置を認識する。また、当該チェックイン情報で指定された利用者IDと対応づけられた既存の利用者チェックイン情報(以下、「既存チェックイン情報」とも呼ぶ。)のチェックイン日時と、店舗IDにより特定される店舗位置を認識する。
チェックイン判定部は、当該チェックイン情報での対象店舗と、既存チェックイン情報での対象店舗について、許容する店舗間の距離(各店舗位置の乖離の大きさ)を、当該チェックイン情報のチェックイン日時と、既存チェックイン情報のチェックイン日時の差分に応じて決定する。典型的には、チェック日時の差分が大きいほど、許容する店舗間距離を大きくし、両者が正相関するよう決定する。例えば、チェックイン日時の差分が1時間であれば、許容する店舗間距離を60キロメートルに決定し、チェックイン日時の差分が2時間であれば、許容する店舗間距離を120キロメートルに決定してもよい。
チェックイン判定部は、当該チェックイン情報での対象店舗と、既存チェックイン情報での対象店舗それぞれの位置情報から店舗間距離を算出する。算出した店舗間距離が、許容する店舗間距離より大きい場合、チェックイン判定部はチェックインを拒否する。例えば、同一の利用者が、10時に渋谷の店舗Aに対するチェックイン操作をした後、10時40分に博多の店舗Bに対しチェックイン操作をした場合、チェックイン判定部は後者のチェックインを拒否する。第1の判定処理によると、現実的に来店が困難なチェックインを受け付けた場合に、無駄となることが想定される顔パス決済の準備処理を抑制し、管理すべきチェックイン情報の数を低減して、売買支援サーバ14のシステムリソースの浪費を防止できる。また、店舗側に対して、実質的に意味のないチェックインを通知してしまうことを抑制できる。
チェックイン判定部の第2の判定処理を詳細に説明する。チェックイン判定部は、チェックイン情報で指定された利用者IDと対応づけられた既存の利用者チェックイン情報を参照する。そして、所定時間内(例えば直近の5分間)に記録された利用者チェックイン情報が所定数以上(例えば20件以上)存在した場合に、大量チェックインがなされたと判定し、チェックインを拒否する。
また利用者情報保持部111は、利用者ID、サービス事業者ID、店舗IDをキーとしてチェックイン時刻およびチェックオフ時刻の履歴を保持する。チェックイン受付部120は、チェックイン情報を受け付けるたびに、チェックイン時刻の履歴へ、チェックイン情報の受付日時をチェックイン時刻として逐次記録していく。また、チェックイン受付部120は、チェックオフ情報を受け付けるたびに、チェックオフ時刻の履歴へ、チェックオフ情報の受付日時をチェックオフ時刻として逐次記録していく。なお、チェックオフ情報は、チェックインの取り消しを要求する情報である。売買支援サーバ14は、チェックオフ情報を受け付けると、対応する利用者チェックイン情報を削除してもよく、店舗用チェックイン情報の取り消し要求を店舗端末12へ送信してもよい。
チェックイン判定部は、チェックイン情報で指定された利用者ID、サービス事業者ID、店舗IDをキーとして、チェックイン時刻およびチェックオフ時刻の履歴を参照する。そして、同一店舗に対して所定回数以上のチェックインとチェックオフが繰り返されていることを検出すると、大量チェックインがなされたと判定し、チェックインを拒否する。
第2の判定処理において一旦チェックインを拒否すると、チェックイン判定部は、予め定められたチェックイン許可条件が満たされるまで継続して、拒否対象の利用者IDが指定されたチェックイン情報によるチェックインを拒否する。チェックイン許可条件は、例えば、最終チェックインから30分間が経過したことでもよく、チェックイン拒否を決定してから30分が経過したことでもよい。第2の判定処理によると、現実的に当日来店できないような数のチェックインや、短時間での大量チェックインを防止でき、売買支援サーバ14のシステムリソースの浪費を防止し、またDoS攻撃への耐性も向上できる。なお、上記第1の判定処理および第2の判定処理のそれぞれは、第6の変形例に限らず、実施の形態の構成および他の変形例の構成と組み合わせてもよい。
第1の実施の形態についての、第7の変形例を説明する。
売買支援サーバ14は、特定の店舗において顔パス決済を初めて利用する利用者(以下、「初回顧客」とも呼ぶ。)に対して、その店舗で使用可能なクーポン、例えば割引券や引換券を発行してもよい。本変形例において、売買支援サーバ14は、各店舗が初回顧客へ提供するクーポンの情報の登録を受け付ける。売買支援サーバ14の利用者情報保持部111は、利用者、店舗、チェックイン回数を対応づけたチェックイン履歴をさらに保持する。また売買支援サーバ14のチェックイン受付部120は、チェックイン情報を受け付けると、利用者IDおよび店舗IDに対応するチェックイン履歴のチェックイン回数をインクリメントする。
売買支援サーバ14は、特定の店舗において顔パス決済を初めて利用する利用者(以下、「初回顧客」とも呼ぶ。)に対して、その店舗で使用可能なクーポン、例えば割引券や引換券を発行してもよい。本変形例において、売買支援サーバ14は、各店舗が初回顧客へ提供するクーポンの情報の登録を受け付ける。売買支援サーバ14の利用者情報保持部111は、利用者、店舗、チェックイン回数を対応づけたチェックイン履歴をさらに保持する。また売買支援サーバ14のチェックイン受付部120は、チェックイン情報を受け付けると、利用者IDおよび店舗IDに対応するチェックイン履歴のチェックイン回数をインクリメントする。
売買支援サーバ14はクーポン提供部をさらに備える。クーポン提供部は、チェックイン受付部120がチェックイン情報を受け付けた場合に、利用者IDおよび店舗IDに対応するチェックイン履歴のチェックイン回数を確認する。チェックイン回数が「1」(すなわち初回顧客)の場合、クーポン提供部は、チェックイン対象店舗が提供するクーポンの情報を、乱数列の提供にあわせて購入者端末10へ提供する。これにより、例えば購入者端末10のチェックイン画面150(図8)にクーポン情報を表示させ、利用者の購買意欲を高める。またクーポン提供部は、初回顧客へ提供したクーポンの情報を、チェックイン対象店舗への店舗用チェックイン情報の提供にあわせて店舗端末12へ提供する。これにより、例えば店舗端末12の顔パス決済画面190にクーポン情報を表示させ、クーポン適用対象の顧客であることを店舗販売員に報知することができる。
第1の実施の形態についての、第8の変形例を説明する。
利用者は、自身の属性情報として、カード種類が異なる複数のクレジットカード情報を売買支援サーバ14へ登録してよい。この場合に、売買支援サーバ14は、複数のクレジットカード情報を店舗用チェックイン情報として店舗端末12へ提供し、店舗端末12の販売支援画面表示部66は、図11の顔パス決済画面190に、購入者に対応づけられた複数のクレジットカード情報を選択・切替可能にリスト表示してもよい。店舗販売員は、購入者からの口頭申告により決済で使用するクレジットカードの種類を受け付けて、リスト内からそのクレジットカードを選択する。
利用者は、自身の属性情報として、カード種類が異なる複数のクレジットカード情報を売買支援サーバ14へ登録してよい。この場合に、売買支援サーバ14は、複数のクレジットカード情報を店舗用チェックイン情報として店舗端末12へ提供し、店舗端末12の販売支援画面表示部66は、図11の顔パス決済画面190に、購入者に対応づけられた複数のクレジットカード情報を選択・切替可能にリスト表示してもよい。店舗販売員は、購入者からの口頭申告により決済で使用するクレジットカードの種類を受け付けて、リスト内からそのクレジットカードを選択する。
次に、利用者が複数のクレジットカード情報を登録済みの場合に、どのクレジットカードを使うとメリットが大きいかを自動判定し、メリットが大きいカードをデフォルト表示する構成を説明する。
店舗端末12は、図10の会計画面180において特定の顔写真186が選択された場合に、選択された顔写真186に対応する利用者IDと、購入対象商品、決済金額を、サービス事業者IDおよび店舗IDとともに、売買支援サーバ14へ通知する顧客情報通知部をさらに備える。売買支援サーバ14は、リワード情報保持部とリワード判定部をさらに備える。リワード情報保持部は、クレジットカードごとに定められたリワードプログラムの情報、例えばリワードの種類(電子ポイント提供、キャッシュバック、クーポン提供等)と、リワードの提供条件を保持する。
リワード判定部は、サービス情報保持部110を参照して、店舗端末12から通知されたサービス事業者IDおよび店舗IDに対応するサービス事業者名および店舗名を特定する。また利用者情報保持部111の利用者登録情報を参照して、店舗端末12から通知された利用者IDに対応づけられた複数のクレジットカード情報を特定する。またリワード情報保持部を参照して、各クレジットカードのリワード提供条件を特定する。
リワード判定部は、クレジットカードごとに、リワード提供条件と、サービス事業者名、店舗名、購入対象商品、決済金額とを比較して、提供条件が満たされたリワードの内容を特定する。そして所定の評価関数にしたがって、クレジットカードごとのリワードの大きさ、言い換えれば、購入者にとってのメリットの大きさを判定する。例えば、リワードが電子ポイントやキャッシュバックの提供であれば、その提供額が大きいほどリワードが大きいと判定してもよい。また割引クーポンの提供であれば、その割引額が大きいほどリワードが大きいと判定してもよい。リワード判定部は、購入者が保持するクレジットカードごとのリワードの大きさを示すリワード情報を店舗端末12へ提供する。
店舗端末12の販売支援画面表示部66は、図11の顔パス決済画面190において複数のクレジットカード情報をリスト表示させる際に、売買支援サーバ14から通知されたリワード情報においてリワードが最も大きいとされたクレジットカードを、決済に用いる既定のカードとしての態様で表示させる。例えば、顔パス決済画面190の初期表示時に選択状態で表示させもよく、顔パス決済画面190の支払条件欄でデフォルト表示させてもよい。また販売支援画面表示部66は、顔パス決済画面190において、複数のクレジットカードの情報を、リワードの大きさの降順に並べたリストを表示させてもよい。また、売買支援サーバ14のリワード判定部は、リワードの内容も店舗端末12へ通知してよく、店舗端末12の販売支援画面表示部66は、各クレジットカードに対応づけた態様でリワードの内容を表示させてもよい。
第1の実施の形態についての、第9の変形例を説明する。
チェックイン日時から顔パス有効期限までの期間(以下、「顔パス有効期間」とも呼ぶ。)は固定期間でなくてもよく、利用者と店舗の位置関係に応じて期間の長短が動的に決定されてもよい。顔パス有効期間を維持しながらも、その長短を柔軟に調整することで、不正防止効果を維持しつつ、利用者の利便性を一層向上させることができる。
チェックイン日時から顔パス有効期限までの期間(以下、「顔パス有効期間」とも呼ぶ。)は固定期間でなくてもよく、利用者と店舗の位置関係に応じて期間の長短が動的に決定されてもよい。顔パス有効期間を維持しながらも、その長短を柔軟に調整することで、不正防止効果を維持しつつ、利用者の利便性を一層向上させることができる。
例えば、購入者端末10または売買支援サーバ14は、チェックイン操作時に顔パス有効期間を決定する有効期間決定部をさらに備えてもよい。購入者端末10が有効期間決定部を備える場合は、購入者端末10は、決定した顔パス有効期間をチェックイン情報に含めて売買支援サーバ14へ通知し、売買支援サーバ14は、通知された顔パス有効期間にもとづく顔パス有効期限を利用者チェックイン情報に格納してもよい。また売買支援サーバ14が有効期間決定部を備える場合は、購入者端末10は、自端末の位置情報をチェックイン情報に含めて売買支援サーバ14へ通知してもよい。
有効期間決定部は、チェックイン対象店舗の所在地と、購入者端末10の現在位置が離れているほど、漏洩リスクを考慮した所定期間(例えば12時間)を上限とした範囲内で顔パス有効期間を長くしてもよい。また、チェックイン対象の店舗の所在地と、購入者端末10の現在位置に応じて、利用者が店舗へ移動する際の所要時間を推定してもよく、移動の所要時間が長いほど顔パス有効期間を長くしてもよい。また、移動の所要時間に1時間等の所定時間を加えた結果を顔パス有効期間として決定してもよい。また移動の所要時間を精度よく推定するために、徒歩・自転車・自動車等の移動手段を利用者に選択させてもよく、選択された移動手段と予め対応づけられた平均移動速度に応じて所要時間を推定してもよい。
第1の実施の形態についての、第10の変形例を説明する。
利用者が特定の店舗の常連客、具体的には、特定の店舗において所定回数もしくは所定金額以上の顔パス決済の経験者である場合に、その店舗における顔パス有効期間を、常連客でない他の利用者の顔パス有効期間より長い期間になるよう決定してもよい。常連客は顔パス決済に慣れているため、確認コードの漏洩リスクが相対的に低いことが見込まれ、また、常連客であるため店舗側の不正行為も抑制されることが見込まれるためである。このように常連客を特別待遇とすることで、常連客である利用者に優越感や満足感を一層抱かせやすくなる。
利用者が特定の店舗の常連客、具体的には、特定の店舗において所定回数もしくは所定金額以上の顔パス決済の経験者である場合に、その店舗における顔パス有効期間を、常連客でない他の利用者の顔パス有効期間より長い期間になるよう決定してもよい。常連客は顔パス決済に慣れているため、確認コードの漏洩リスクが相対的に低いことが見込まれ、また、常連客であるため店舗側の不正行為も抑制されることが見込まれるためである。このように常連客を特別待遇とすることで、常連客である利用者に優越感や満足感を一層抱かせやすくなる。
この変形例においても、購入者端末10または売買支援サーバ14は有効期間決定部をさらに備える。また購入者端末10または売買支援サーバ14は、利用者と、その利用者が顔パス決済により商品を購入した店舗、購入回数、決済金額を対応づけた決済履歴を保持する決済履歴保持部をさらに備える。購入者端末10が決済履歴保持部を備える場合、顔パス決済がなされる都度、売買支援サーバ14は決済履歴を購入者端末10へ提供してもよい。
有効期間決定部は、利用者が特定の店舗へチェックインするときに、決済履歴を参照して、その店舗における当該利用者の顔パス決済回数および/または顔パス決済金額を特定する。そして、顔パス決済回数が所定回数(例えば3回)以上、および/または、顔パス決済金額が所定額(例えば1万円)以上であるときに、利用者がチェックイン対象店舗の常連客であると判定する。有効期間決定部は、常連客でないと判定した場合、上記実施の形態や第9の変形例で記載したような通常の方法にて顔パス有効期間を決定する一方、常連客と判定した場合は、通常の方法で決定した顔パス有効期間より長い期間を、常連客に付与する顔パス有効期間として決定する。例えば、通常の方法で決定した顔パス有効期間に対して2時間等の所定時間を加えた期間としてもよい。
第1の実施の形態についての、第11の変形例を説明する。
店舗端末12の販売支援画面表示部66は、顔パス有効期限が切れた利用者のアイテム(例えば氏名と顔写真を含むアイコン)を、販売支援画面(例えば会計画面)において店舗販売員による選択ができない態様で表示させてもよい。例えば、グレーアウトして表示させてもよく、選択操作を無効なものにして(例えばdisable属性を付与して)表示させてもよい。また、顔パス有効期限が切れた利用者のアイテムを販売支援画面で非表示としてもよい。この変形例によると、販売支援画面において選択候補となる利用者を、顔パス有効期限内の利用者に限定できるため、選択候補となる利用者数を抑制でき、店舗販売員による選択の手間を低減させることができる。また、顔パス有効期限が切れた利用者が選択されることを抑制し、例えば店舗販売員が再度のチェックインを利用者へ促すことを支援し、顔パス決済時のエラーの発生を抑制できる。
店舗端末12の販売支援画面表示部66は、顔パス有効期限が切れた利用者のアイテム(例えば氏名と顔写真を含むアイコン)を、販売支援画面(例えば会計画面)において店舗販売員による選択ができない態様で表示させてもよい。例えば、グレーアウトして表示させてもよく、選択操作を無効なものにして(例えばdisable属性を付与して)表示させてもよい。また、顔パス有効期限が切れた利用者のアイテムを販売支援画面で非表示としてもよい。この変形例によると、販売支援画面において選択候補となる利用者を、顔パス有効期限内の利用者に限定できるため、選択候補となる利用者数を抑制でき、店舗販売員による選択の手間を低減させることができる。また、顔パス有効期限が切れた利用者が選択されることを抑制し、例えば店舗販売員が再度のチェックインを利用者へ促すことを支援し、顔パス決済時のエラーの発生を抑制できる。
この変形例において、売買支援サーバ14は、店舗用チェックイン情報として、利用者の顔パス有効期限を店舗端末12へさらに通知してもよい。また売買支援サーバ14は、利用者情報保持部111に格納された各利用者の顔パス有効期限を定期的に参照し、顔パス有効期限が切れた利用者を定期的に検出して、その利用者の情報をチェックイン対象店舗の店舗端末12へ通知してもよい。顔パス有効期限切れの利用者の特定主体は、前者の場合は店舗端末12となり、後者の場合は売買支援サーバ14となる。
第1の実施の形態についての、第11の変形例に関連する第12の変形例を説明する。
店舗端末12の販売支援画面表示部66は、顔パス有効期限が切れた利用者の情報(例えば氏名と顔写真を含むアイテム)を、顔パス有効期限内の利用者の情報表示領域とは別領域に表示させてもよい。例えば、顔パス有効期限が切れた利用者の情報を、顔パス有効期限内の利用者の情報表示領域では非表示とする一方、メニュー画面、商品選択画面、会計画面それぞれの有効期限切れ情報表示領域にて新たに表示させてもよい。この変形例によると、会計画面において選択候補となる利用者を、顔パス有効期限内の利用者に限定できる。これにより、選択候補となる利用者数を抑制して、店舗販売員による選択の手間を低減できる。また、顔パス有効期限が切れた利用者の情報を販売支援画面に常時表示させることで、その利用者が来店した際に、店舗販売員は再度のチェックインを促すための声掛けを実施しやすくなり、顔パス決済時のエラーの発生を抑制できる。
店舗端末12の販売支援画面表示部66は、顔パス有効期限が切れた利用者の情報(例えば氏名と顔写真を含むアイテム)を、顔パス有効期限内の利用者の情報表示領域とは別領域に表示させてもよい。例えば、顔パス有効期限が切れた利用者の情報を、顔パス有効期限内の利用者の情報表示領域では非表示とする一方、メニュー画面、商品選択画面、会計画面それぞれの有効期限切れ情報表示領域にて新たに表示させてもよい。この変形例によると、会計画面において選択候補となる利用者を、顔パス有効期限内の利用者に限定できる。これにより、選択候補となる利用者数を抑制して、店舗販売員による選択の手間を低減できる。また、顔パス有効期限が切れた利用者の情報を販売支援画面に常時表示させることで、その利用者が来店した際に、店舗販売員は再度のチェックインを促すための声掛けを実施しやすくなり、顔パス決済時のエラーの発生を抑制できる。
なお、販売支援画面表示部66は、顔パス有効期限が切れた利用者のうち、顔パス有効期限切れが特定された日時が新しい利用者の情報ほど、強調した態様で販売支援画面に表示させてもよい。例えば、有効期限切れ情報表示領域において、他の利用者の情報より上段に表示させてもよく、強調するための色やオブジェクトを付加して表示させてもよい。最近顔パス有効期限切れとなった利用者の方が、店舗へ来訪する可能性が高いと想定されるところ、その利用者が来店した際に、店舗販売員は再度のチェックインを促すための声掛けを実施しやすくなる。
第1の実施の形態についての、第13の変形例を説明する。
店舗端末12の販売支援画面表示部66は、販売支援画面としての顔写真の選択画面(例えば図10の顔パス決済指定エリア184)において、チェックインした複数の利用者それぞれの来店予定時刻に応じた態様で、各利用者の氏名および顔写真を含むアイテムを表示させてもよい。好適には、現在時刻と来店予定時刻が相対的に近い利用者のアイテムを、現在時刻と来店予定時刻が相対的に離れた利用者のアイテムより強調した態様で表示させる。例えば、強調するための色やオブジェクトを付加して表示させてもよい。また、現在時刻と来店予定時刻が近い利用者のアイテムほど、顔パス決済指定エリア184の上段で表示させてもよい。現在時刻と来店予定時刻が近い利用者は、現在来店する可能性が高い利用者であると想定されるため、顔写真の選択画面において利用者アイテムの選択を容易にすることができる。
店舗端末12の販売支援画面表示部66は、販売支援画面としての顔写真の選択画面(例えば図10の顔パス決済指定エリア184)において、チェックインした複数の利用者それぞれの来店予定時刻に応じた態様で、各利用者の氏名および顔写真を含むアイテムを表示させてもよい。好適には、現在時刻と来店予定時刻が相対的に近い利用者のアイテムを、現在時刻と来店予定時刻が相対的に離れた利用者のアイテムより強調した態様で表示させる。例えば、強調するための色やオブジェクトを付加して表示させてもよい。また、現在時刻と来店予定時刻が近い利用者のアイテムほど、顔パス決済指定エリア184の上段で表示させてもよい。現在時刻と来店予定時刻が近い利用者は、現在来店する可能性が高い利用者であると想定されるため、顔写真の選択画面において利用者アイテムの選択を容易にすることができる。
この変形例において、購入者端末10、店舗端末12、または売買支援サーバ14は、来店時刻推定部をさらに備える。第9の変形例の有効期間決定部と同様に、来店時刻推定部は、チェックイン対象店舗の所在地と、購入者端末10の現在位置に応じて、現在位置から店舗への移動の所要時間を推定する。来店時刻推定部は、チェックイン時刻から移動の所要時間を経過させた時刻を来店予定時刻として特定する。購入者端末10、店舗端末12、売買支援サーバ14のいずれが来店時刻推定部を備える場合も、来店時刻推定部による推定処理に必要な情報(例えばチェックイン時刻、購入者端末10の現在位置、店舗の所在地、移動手段等)は、購入者端末10から売買支援サーバ14へのチェックイン情報の通知、売買支援サーバ14から店舗端末12への店舗用チェックイン情報の通知により伝達してよい。来店時刻推定部が特定した来店予定時刻も同様に伝達してよい。
第1の実施の形態についての、第14の変形例を説明する。
店舗端末12の販売支援画面表示部66は、販売支援画面としての顔写真の選択画面(例えば図10の顔パス決済指定エリア184の表示画面)を表示する前に、確認コードの入力画面を表示させてもよい。そして顔写真の選択画面では、確認コードの一部のデータに整合する顔写真のみを表示させてもよい。また、確認コードの一部のデータに整合する顔写真を、不整合の顔写真より強調した態様(エリアの上段、大きいサイズ、強調色、所定のオブジェクトを付加した態様)で表示させてもよい。確認コードの一部のデータは、確認コードの1桁目の数字であってもよく、1桁目および2桁目の数字列であってもよく、ここでは「限定コード」と呼ぶ。この場合、売買支援サーバ14は、確認コードを保持して、確認コードから限定コードを抽出し、限定コードを含む店舗用チェックイン情報を店舗端末12へ提供してもよい。この変形例によると、不正防止効果を維持しつつ、選択候補となる利用者数を抑制し、店舗販売員による選択の手間を低減させることができる。
店舗端末12の販売支援画面表示部66は、販売支援画面としての顔写真の選択画面(例えば図10の顔パス決済指定エリア184の表示画面)を表示する前に、確認コードの入力画面を表示させてもよい。そして顔写真の選択画面では、確認コードの一部のデータに整合する顔写真のみを表示させてもよい。また、確認コードの一部のデータに整合する顔写真を、不整合の顔写真より強調した態様(エリアの上段、大きいサイズ、強調色、所定のオブジェクトを付加した態様)で表示させてもよい。確認コードの一部のデータは、確認コードの1桁目の数字であってもよく、1桁目および2桁目の数字列であってもよく、ここでは「限定コード」と呼ぶ。この場合、売買支援サーバ14は、確認コードを保持して、確認コードから限定コードを抽出し、限定コードを含む店舗用チェックイン情報を店舗端末12へ提供してもよい。この変形例によると、不正防止効果を維持しつつ、選択候補となる利用者数を抑制し、店舗販売員による選択の手間を低減させることができる。
第1の実施の形態についての、第15の変形例を説明する。
上記実施の形態では、売買支援サーバ14の決済許否判定部130は、決済要求に係る利用者の顔パス有効期限が切れていた場合に、商品代金の決済を禁止することとした。変形例として、決済要求に係る利用者の顔パス有効期限が切れていても、決済金額が所定金額(例えば1万円)以下の場合は、決済を許可してもよい。また第10の変形例に関連して、決済要求に係る利用者が決済対象店舗の常連客である場合は、顔パス有効期限による決済許否判定をスキップしてもよい。言い換えれば、決済要求に係る利用者が決済対象店舗の常連客でない場合に、顔パス有効期限による決済許否判定を実行してもよい。
上記実施の形態では、売買支援サーバ14の決済許否判定部130は、決済要求に係る利用者の顔パス有効期限が切れていた場合に、商品代金の決済を禁止することとした。変形例として、決済要求に係る利用者の顔パス有効期限が切れていても、決済金額が所定金額(例えば1万円)以下の場合は、決済を許可してもよい。また第10の変形例に関連して、決済要求に係る利用者が決済対象店舗の常連客である場合は、顔パス有効期限による決済許否判定をスキップしてもよい。言い換えれば、決済要求に係る利用者が決済対象店舗の常連客でない場合に、顔パス有効期限による決済許否判定を実行してもよい。
第1の実施の形態についての、第16の変形例を説明する。
上記実施の形態では、利用者は自身の顔写真を売買支援サーバ14へ登録し、売買支援サーバ14はチェックインを契機に利用者の顔写真を店舗端末12へ提供し、店舗販売員は、商品購入者と選択画面の顔写真とを見比べることとした。変形例として、利用者(購入者)を識別するために顔写真以外の画像が用いられてもよく、すなわち特定の利用者を他者と区別して認識可能な画像であればよく、利用者の外見の特徴を示す画像であればよい。例えば、利用者の外見の特徴を反映したキャラクターでもよく、利用者をモデルとした肖像画の画像データであってもよい。
上記実施の形態では、利用者は自身の顔写真を売買支援サーバ14へ登録し、売買支援サーバ14はチェックインを契機に利用者の顔写真を店舗端末12へ提供し、店舗販売員は、商品購入者と選択画面の顔写真とを見比べることとした。変形例として、利用者(購入者)を識別するために顔写真以外の画像が用いられてもよく、すなわち特定の利用者を他者と区別して認識可能な画像であればよく、利用者の外見の特徴を示す画像であればよい。例えば、利用者の外見の特徴を反映したキャラクターでもよく、利用者をモデルとした肖像画の画像データであってもよい。
第1の実施の形態についての、第17の変形例を説明する。
現在、電子決済の手段は多様化しており、例えば、クレジットカード決済に加え、プリペイドカード決済、デビットカード決済、通信キャリア一括決済、送金サービス等が存在する。本変形例では、電子決済の多様な手段に対応した顔パス決済を実現することにより、利用者の利便性を一層高める商品売買システム100を提案する。
現在、電子決済の手段は多様化しており、例えば、クレジットカード決済に加え、プリペイドカード決済、デビットカード決済、通信キャリア一括決済、送金サービス等が存在する。本変形例では、電子決済の多様な手段に対応した顔パス決済を実現することにより、利用者の利便性を一層高める商品売買システム100を提案する。
利用者は、自身で使用可能な複数の決済手段について、各決済手段を用いた決済に必要な情報(以下、「決済必要情報」と呼ぶ。)を購入者端末10へ入力する。購入者端末10の利用者情報登録部34は、入力情報を売買支援サーバ14へ送信し、売買支援サーバ14は、利用者が使用可能な複数の決済手段それぞれの決済必要情報を利用者情報保持部111に記憶する。
また利用者は、各決済手段による決済順序を示す情報(以下、「決済順序情報」と呼ぶ。)を購入者端末10へ入力する。購入者端末10の利用者情報登録部34は、入力情報を売買支援サーバ14へ送信し、売買支援サーバ14は、利用者が入力した決済順序情報を利用者情報保持部111に記憶する。売買支援サーバ14の決済処理部132は、上記実施の形態と同様に、決済許否判定部130により決済の実行が許可されたことを条件として、購入代金の電子決済を支援するための以下の処理を実行する。
決済処理部132は、利用者情報保持部111に記憶された電子決済を行うべき利用者の決済順序情報を参照し、決済順序情報が定める順序で電子決済の依頼(使用する決済手段の決済必要情報を設定した電文)を、各決済手段に対応する所定の決済サーバ16へ送信する。例えば、プリペイドカード決済→デビットカード決済→クレジットカード決済という順序が登録されていれば、決済処理部132は、まずプリペイドカード決済を試みる。購入金額がプリペイドカードのチャージ金額を超過していれば、次にデビットカード決済を試みる。デビットカード決済に用いる口座の残高が不足していれば、次にクレジットカード決済を試みる。
この変形例によると、利用者が使用可能な複数の決済手段による電子決済を、利用者が所望する順序で実行できる。また極力、電子決済を成功させるよう制御することで、口座残高不足等に起因する電子決済の失敗を抑制し、利用者の利便性を向上させる。
なお、個々の決済手段の中でも複数の決済方法が存在する場合がある。例えば、デビットカード決済であれば、銀行Aに開設した口座、銀行Bに開設した口座をそれぞれ選択することができる。このような場合に、利用者は、個々の決済手段内での決済順序、例えばデビットカード決済における複数の保有口座の選択順序を含む決済順序情報を購入者端末10に入力する。売買支援サーバ14の利用者情報保持部111は、個々の決済手段内での決済順序を含む決済順序情報を記憶する。売買支援サーバ14の決済処理部132は、決済順序情報が定める順序で決済手段を順次選択し、さらに個々の決済手段内での決済方法を決済順序情報にしたがって順次選択する。そして、決済順序情報に則した決済手段に対応する決済サーバ16に対して、その決済手段における決済方法を指定する(例えば購入代金を引き落とすべき口座を指定する)決済必要情報を設定した電文を送信する。
第1の実施の形態についての、第18の変形例を説明する。
実施の形態で提案した顔パス決済は、来訪予定店舗に対するチェックイン操作をユーザに実施してもらう必要がある。言い換えれば、来店前のチェックインという付加的なオペレーションをユーザに課す。そこで顔パス決済のビジネスを普及させるために、チェックインをユーザに「使ってもらう」ものとするため、本変形例では、チェックインにインセンティブや利便性を用意する技術を提案する。なお、下記の1)から7)は、それらの全てもしくは一部を任意に組み合わせてよいことはもちろんである。
実施の形態で提案した顔パス決済は、来訪予定店舗に対するチェックイン操作をユーザに実施してもらう必要がある。言い換えれば、来店前のチェックインという付加的なオペレーションをユーザに課す。そこで顔パス決済のビジネスを普及させるために、チェックインをユーザに「使ってもらう」ものとするため、本変形例では、チェックインにインセンティブや利便性を用意する技術を提案する。なお、下記の1)から7)は、それらの全てもしくは一部を任意に組み合わせてよいことはもちろんである。
1)クーポンを選択したチェックイン:
利用者は、チェックイン時に、店舗で利用したいクーポンを予め選択する。利用者により選択されたクーポンの情報は店舗側へ通知され、店舗での顔パス決済時に、利用者がチェックインにおいて選択したクーポンを自動適用した会計金額にて決済を実行する。
利用者は、チェックイン時に、店舗で利用したいクーポンを予め選択する。利用者により選択されたクーポンの情報は店舗側へ通知され、店舗での顔パス決済時に、利用者がチェックインにおいて選択したクーポンを自動適用した会計金額にて決済を実行する。
システム構成の一例を説明する。売買支援サーバ14の店舗情報保持部112には、各店舗が利用者へ提供する1つ以上のクーポンの情報が予め格納される。購入者端末10は、店舗詳細画面140を表示するべき際に、店舗情報とともにクーポン情報を売買支援サーバ14から取得し、クーポン情報を店舗詳細画面140に表示させる。店舗詳細画面140において、利用者は、所望のクーポンを選択した上でチェックイン操作を実施する。
続いて購入者端末10は、売買支援サーバ14へ送信するチェックイン情報に、利用者が選択したクーポンを示す情報(以下、「選択クーポン情報」と呼ぶ。)を付加する。売買支援サーバ14は、チェックイン先店舗の店舗端末12へ、利用者の顔写真とともに選択クーポン情報(割引額を含む)を送信する。店舗端末12は、選択クーポン情報を顔パス決済画面190で表示させる。また店舗端末12は、商品やサービスの元の販売価格から、選択クーポン情報が示す割引額を差し引いた金額を会計金額として決定して、顔パス決済画面190に表示させる。決済実行時、店舗端末12は、割引後の会計金額を指定した決済要求を売買支援サーバ14へ送信して電子決済を実行させる。
2)クーポン発行:
チェックイン時や、初回来店時、来店回数10回目等、予め定められたイベントが発生したタイミングでクーポンを発行する。顔パスによる支払時に、事前のチェックイン時に発行されたクーポンが自動適用された会計金額にて決済を実行する。
チェックイン時や、初回来店時、来店回数10回目等、予め定められたイベントが発生したタイミングでクーポンを発行する。顔パスによる支払時に、事前のチェックイン時に発行されたクーポンが自動適用された会計金額にて決済を実行する。
システム構成の一例として、上記1)に類似する構成であってもよい。ただし、売買支援サーバ14は、第5の変形例で記載したチェックイン履歴と、第10の変形例で記載した決済履歴を保持する。さらに、クーポンを発行すべきタイミングか否かを判定するための基準であり、言い換えれば、クーポン発行イベントを実行すべき条件(以下、「クーポン発行条件」と呼ぶ。)を保持する。売買支援サーバ14は、購入者端末10からチェックイン情報を受け付けた場合に、利用者のチェックイン履歴と決済履歴を参照し、クーポン発行条件が充足されたか否かを判定する。クーポン発行条件が充足された場合、売買支援サーバ14は、店舗情報とともにクーポン情報を購入者端末10へ提供し、購入者端末10は、クーポン情報を店舗詳細画面140に表示させる。以降の処理は、上記1)と同じである。
3)時限クーポン:
チェックイン時に、利用者の来店を促進する目的で、所定の有効期間(例えば1時間等)を設定した時限クーポンを発行する。顔パスによる支払時に、事前のチェックイン時に発行された時限クーポンが、その有効期限に応じて自動適用された会計金額にて決済を実行する。
チェックイン時に、利用者の来店を促進する目的で、所定の有効期間(例えば1時間等)を設定した時限クーポンを発行する。顔パスによる支払時に、事前のチェックイン時に発行された時限クーポンが、その有効期限に応じて自動適用された会計金額にて決済を実行する。
システム構成の一例として、上記1)に類似する構成であってもよい。ただし、売買支援サーバ14が保持し、購入者端末10および店舗端末12へ提供されるクーポンは時限クーポンであり、すなわちそのクーポン情報には、チェックインから1時間等の有効期間を示すデータが含まれる。購入者端末10は、クーポン情報としてクーポンの有効期間も表示させて利用者へ提示する。また売買支援サーバ14は、利用者の顔写真、クーポン情報とともに利用者のチェックイン時刻を店舗端末12へ提供する。店舗端末12は、利用者のチェックイン時刻から会計時刻(例えば現在時刻)までの時間にもとづいて、時限クーポンが有効か否かを判定する。有効期間が途過してなければ、言い換えれば、会計タイミングが時限クーポンの有効期間内であれば、店舗端末12は、商品やサービスの元の販売価格から、時限クーポンが示す割引額を差し引いた金額を会計金額として決定する。
4)コメントを付加したチェックイン:
来店前に予め店員に伝えておきたい事項などの情報(以下、「コメント」と呼ぶ。)をコメント欄に入力してからチェックインを実施する。このコメントは店舗側へ通知される。店員はチェックイン者の顔写真とともにコメントを確認して、お客様のおもてなしの準備を予め実施できる。例えば、利用者の購買履歴等を確認して、今回お勧めする商品を予め見繕うことができる。また、コメントで指定された利用者の所望の商品を店頭に並べ、また、その商品情報を調べておく等の準備ができる。
来店前に予め店員に伝えておきたい事項などの情報(以下、「コメント」と呼ぶ。)をコメント欄に入力してからチェックインを実施する。このコメントは店舗側へ通知される。店員はチェックイン者の顔写真とともにコメントを確認して、お客様のおもてなしの準備を予め実施できる。例えば、利用者の購買履歴等を確認して、今回お勧めする商品を予め見繕うことができる。また、コメントで指定された利用者の所望の商品を店頭に並べ、また、その商品情報を調べておく等の準備ができる。
システム構成の一例を説明する。購入者端末10は、利用者が任意のコメントを入力可能なコメント欄を設けた店舗詳細画面140を表示させる。コメントの文字数には制限を設けてもよく、例えば、入力可能な文字数を最大100字にするようコメント欄を設定してもよい。購入者端末10は、コメント欄に入力されたコメントを含むチェックイン情報を売買支援サーバ14へ送信し、売買支援サーバ14は、そのコメントを含む店舗用チェックイン情報を店舗端末12へ送信する。店舗端末12の販売支援画面表示部66は、販売支援画面としてデフォルト表示される初期画面(例えばメニュー選択画面)に、自店舗にチェックイン済みの利用者の氏名および顔写真を表示し、さらに各利用者に対応づけて(例えば利用者の顔写真の近傍位置に)利用者がチェックイン時に入力したコメントを表示させる。
5)来店目的を選択してチェックイン:
利用者は、今回の来店目的を予め選択してからチェックインする。来店目的を示す情報(以下、「来店目的情報」と呼ぶ。)は店舗側へ通知され、店舗端末12は、チェックイン者の氏名、顔写真とともに来店目的を表示する。これにより店員は、利用者の目的を事前に把握した上で、来店した利用者へ適切な声掛けや、商品紹介を実施できる。また、来店目的が例えば「1人で商品を閲覧したい」であれば、利用者への声掛けをあえて抑制し、利用者に自由に商品を閲覧させるよう配慮することもできる。
利用者は、今回の来店目的を予め選択してからチェックインする。来店目的を示す情報(以下、「来店目的情報」と呼ぶ。)は店舗側へ通知され、店舗端末12は、チェックイン者の氏名、顔写真とともに来店目的を表示する。これにより店員は、利用者の目的を事前に把握した上で、来店した利用者へ適切な声掛けや、商品紹介を実施できる。また、来店目的が例えば「1人で商品を閲覧したい」であれば、利用者への声掛けをあえて抑制し、利用者に自由に商品を閲覧させるよう配慮することもできる。
この変形例の商品売買システム100の構成は上記4)に類似する。購入者端末10の店舗詳細画面140に、コメント欄に代えて来店目的の選択欄を設ける。そして、利用者による選択内容をチェックイン情報に付加し、店舗端末12まで伝達する。
6)店員の顔写真付き応答:
利用者がチェックインしたタイミングで、チェックイン先の店員の顔写真付きの応答メッセージを利用者へ提示する。6−1)チェックインの都度、店員がコメントを作成して返信してもよく、6−2)固定文言を返信してもよい。利用者と店舗店員のコミュニケーションを支援して、利用者の来店を促進できる。
利用者がチェックインしたタイミングで、チェックイン先の店員の顔写真付きの応答メッセージを利用者へ提示する。6−1)チェックインの都度、店員がコメントを作成して返信してもよく、6−2)固定文言を返信してもよい。利用者と店舗店員のコミュニケーションを支援して、利用者の来店を促進できる。
まず、上記6−2)のシステム構成例を説明する。売買支援サーバ14は、店舗が予め登録した店員の顔写真と、固定の応答コメントを店舗情報保持部112に保持する。売買支援サーバ14は、購入者端末10からチェックインを受け付けた場合に、その応答として、チェックイン先の店舗に対応づけられた店員の顔写真と応答コメントを店舗情報保持部112から取得して購入者端末10へ提供する。購入者端末10は、チェックイン先の店員の顔写真と応答コメントを表示させる。なお、売買支援サーバ14は、乱数列のデータとともに、店員の顔写真と応答コメントを購入者端末10へ提供してもよい。購入者端末10は、チェックイン画面150に、確認コードともに、店員の顔写真と応答コメントを表示させてもよい。
次に、上記6−1)のシステム構成例を説明する。店舗端末12は、自店舗へチェックインした利用者に対する応答コメントを入力するコメント入力欄を設けたコメント入力画面を表示させる。店員は、コメント入力画面のコメント入力欄に、利用者に応じた応答コメントを入力する。応答コメントは例えば、「○○様へのお勧めの商品として△△を用意しています」等である。店舗端末12は、応答コメントを売買支援サーバ14へ送信し、売買支援サーバ14は、その応答コメントを、店舗が予め登録した店員の顔写真とともに購入者端末10へ送信する。購入者端末10は、チェックイン後の所定の画面に、チェックイン先の店員の顔写真と応答コメントを表示させる。
7)カードやメダルの取得
チェックインしたタイミングで、例えば有名タレントグループのカードをランダムに発行する。取得したカードやメダルはホルダに保管できる。
チェックインしたタイミングで、例えば有名タレントグループのカードをランダムに発行する。取得したカードやメダルはホルダに保管できる。
システム構成の一例を説明する。売買支援サーバ14は、カードやメダル、所定のプレミアム画像等の、チェックイン特典情報を予め保持する。売買支援サーバ14は、購入者端末10からチェックイン情報を受信すると、チェックイン特典情報を購入者端末10へ送信する。乱数列のデータとともにチェックイン特典情報を購入者端末10へ送信してもよい。購入者端末10は、売買支援サーバ14から提供されたチェックイン特典情報を画面に表示させる。また利用者の操作に応じて、チェックイン特典情報をローカルの記憶領域に永続的に記憶させる。
第1の実施の形態についての、第19の変形例を説明する。
実施の形態で示したように、顔パス決済のためのチェックインは、利用者が来店したい店舗のページにて手動でチェックイン操作を実施することを基本とする。本変形例では、利用者の利便性を一層高めるために、ICT技術によりチェックインをサポートする技術を提案する。なお、以下の1)から3)のいずれにもついても、決済時の確認コードの確認(照合)は必要である。また1)から3)の任意の組み合わせが可能である。
実施の形態で示したように、顔パス決済のためのチェックインは、利用者が来店したい店舗のページにて手動でチェックイン操作を実施することを基本とする。本変形例では、利用者の利便性を一層高めるために、ICT技術によりチェックインをサポートする技術を提案する。なお、以下の1)から3)のいずれにもついても、決済時の確認コードの確認(照合)は必要である。また1)から3)の任意の組み合わせが可能である。
1)オートチェックイン:
購入者端末10においてオートチェックイン機能およびGPS機能をオンにしておくことで、利用者が店舗近傍に来たときに自動的に店舗へチェックインする。すなわち購入者端末10の現在位置に応じて自動チェックインを実行する。このシステム構成例は、第3の変形例として既述であるため省略する。
購入者端末10においてオートチェックイン機能およびGPS機能をオンにしておくことで、利用者が店舗近傍に来たときに自動的に店舗へチェックインする。すなわち購入者端末10の現在位置に応じて自動チェックインを実行する。このシステム構成例は、第3の変形例として既述であるため省略する。
2)決まった時間にチェックイン:
曜日や時間指定で自動的にチェックインを実行する。このシステム構成例は、第3の変形例に類似する。購入者端末10は、利用者が予め購入者端末10に登録した日時に至ったことを検出すると、利用者が予め購入者端末10に登録した店舗に対して、第3の変形例に記載した自動チェックイン処理を実行する。
曜日や時間指定で自動的にチェックインを実行する。このシステム構成例は、第3の変形例に類似する。購入者端末10は、利用者が予め購入者端末10に登録した日時に至ったことを検出すると、利用者が予め購入者端末10に登録した店舗に対して、第3の変形例に記載した自動チェックイン処理を実行する。
3)チェックイン高速化:
既述したように、実施の形態では、ログイン画面、サービス事業者選択画面、店舗選択画面を表示後に、チェックイン操作を実施する店舗詳細画面を表示させることとした。本変形例では、手動によるチェックインを前提としつつも、利用者のオペレーション数を低減するための技術を提案する。具体的には、「お気に入り」からダイレクトにチェックインページへ遷移させる。
既述したように、実施の形態では、ログイン画面、サービス事業者選択画面、店舗選択画面を表示後に、チェックイン操作を実施する店舗詳細画面を表示させることとした。本変形例では、手動によるチェックインを前提としつつも、利用者のオペレーション数を低減するための技術を提案する。具体的には、「お気に入り」からダイレクトにチェックインページへ遷移させる。
システム構成の一例を説明する。購入者端末10は、お気に入り画面保持部とお気に入り登録部をさらに備える。特定の店舗の情報を提示してその店舗へのチェックイン操作を受け付ける店舗詳細画面を、お気に入り画面とする旨の登録操作を利用者が入力すると、お気に入り登録部は、その店舗詳細画面のデータをお気に入り画面保持部へ格納する。利用者が購入者端末10のお気に入り選択画面において特定の店舗名称を選択すると、購入支援画面表示部36は、店舗選択画面等、前段の画面の表示をスキップして、お気に入り画面保持部に記憶された店舗詳細画面のうち、選択された店舗名称に対応する店舗詳細画面をタッチパネル20に表示させる。なお、店舗詳細画面がウェブページとして売買支援サーバ14から提供される場合、お気に入り登録部は、購入者端末10にインストールされたウェブブラウザのお気に入り機能に、利用者が指定する店舗詳細画面のページを登録してもよいことはもちろんである。
(第2の実施の形態)
第2の実施の形態では、第1の実施の形態で提案した顔パス決済機能に加えて、サービスの購入希望者に対してサービス提供までの待ち時間の推定値を提示する機能を実現する商品売買システムを提案する。
第2の実施の形態では、第1の実施の形態で提案した顔パス決済機能に加えて、サービスの購入希望者に対してサービス提供までの待ち時間の推定値を提示する機能を実現する商品売買システムを提案する。
これまでにも顧客へおおよその待ち時間を提示するシステムは存在したが、これまでのシステムは、顧客1組あたりの待ち時間を所与の値として予め一律に定めておき、「待ち行列の長さ(待っている顧客数)×顧客1組あたりの待ち時間」により、顧客の待ち時間を決定し、または、待ち行列理論を利用しつつも、平均サービス時間の取得が困難であるため、上記と同様に平均サービス時間を所与の値として定めておき、顧客の待ち時間を決定するレベルにとどまっていた。その結果、顧客へ提示した待ち時間と、実際の待ち時間との乖離が大きくなることがあった。
そこで第2の実施の形態として提案する商品売買システムでは、第1の実施の形態として提案した携帯端末を活用した顔パス決済のフローにおいて、待ち行列へのエントリや会計といった商品売買にかかわるアクションの発生時刻や発生件数を計測する。そして、それらアクションの実測値であり、言い換えれば、店舗にて直近の過去にサービスを享受した利用者に対する実際のサービス提供状況にもとづいて、店舗の待ち時間を推定する。そして、利用者がチェックインを行おうとする際に待ち時間の推定値を提供する。また、最新の実測値(サービス提供状況)を用いて、定期的に待ち時間の推定を繰り返すことで、待ち時間の推定値の精度を維持する。
第2の実施の形態における利用者は、典型的にはサービス販売者の店舗へ来訪し、そのサービスを享受して対価を支払う者であり、すなわちサービスを購入する者である。サービスは、例えば、飲食店での飲食提供サービスや、銀行・専売店・量販店等での窓口サービス、病院での医療サービスを含む。待ち時間は、例えば、購入者端末10を用いて飲食店へチェックインしてから、その飲食店で席に案内されるまで(すなわち飲食店でサービス提供が開始されるまで)の時間である。また、購入者端末10を用いて携帯電話の専売店へチェックインしてから、その専売店の窓口にて対応が始まるまでの時間である。
なお、サービスの購入は、商品の購入を包含する概念である。商品の購入における待ち時間は、利用者が店舗へチェックインしてから、その店舗において所望の商品の購入を完了するまでの時間として定義することができる。
図12は、第2の実施の形態の商品売買システム100の構成を示す。以下、第1の実施の形態で既述した説明は適宜省略する。図12以降の図面において、第1の実施の形態における部材(例えば装置や機能ブロック)と同一もしくは対応する部材には同一の符号を付している。
店舗端末12は、店員操作端末17と店舗内受付端末18を含む。店員操作端末17は、第1の実施の形態の店舗端末12に対応し、典型的には店舗従業員により操作されるタブレット端末である。店員操作端末17は、第1の実施の形態の店舗端末12と同様に顔パス決済支援処理を実行し、さらに、サービス提供を待つ利用者の情報を表示し、利用者へのサービス提供状況の入力を受け付けて売買支援サーバ14へ通知する。店舗内受付端末18は、チェックインを経ずに店舗へ直接来訪した顧客の情報を待ち行列に登録する情報処理端末であり、顧客または店舗従業員により操作される。店舗内受付端末18は、待ち番号が記載された受付票を顧客へ発券するものであってもよい。
売買支援サーバ14は、第1の実施の形態と同様に顔パス決済支援処理を実行し、さらに、顔パス決済に参加する複数の店舗の待ち行列情報、待ち時間情報を管理する。また売買支援サーバ14は、各店舗における現在の待ち時間を推定し、その店舗へチェックインしようとする利用者へ待ち時間の推定値を提供する。
図13は、図12の購入者端末10の機能構成を示すブロック図である。購入者端末10は、待ち行列入力通知部44をさらに含む。第1の実施の形態と同様に、店舗詳細画面において利用者がチェックイン操作を行った場合に、チェックイン通知部40は、チェックイン先として選択された店舗(以下、「選択店舗」とも呼ぶ。)を指定したチェックイン情報を売買支援サーバ14へ送信する。
サービス情報取得部38は待ち時間情報取得部としても機能する。具体的には、サービス情報取得部38は、チェックイン情報への応答として売買支援サーバ14から提供された選択店舗における現在の待ち時間の推定値(以下、「推定待ち時間」とも呼ぶ。)を取得する。またサービス情報取得部38は、選択店舗と同一のグループに属する1つ以上の他店舗(以下、「グループ店舗」とも呼ぶ。)における現在の推定待ち時間も取得する。
購入支援画面表示部36は、待ち時間表示部としても機能する。具体的には、店舗詳細画面において利用者がチェックイン操作を行った場合に、サービス情報取得部38が取得した選択店舗の待ち時間と、グループ店舗の待ち時間を並べて示すチェックイン店舗確認画面をタッチパネル20に表示させる。チェックイン店舗確認画面の具体例は後述する。
待ち行列入力通知部44は、利用者が指定する店舗の待ち行列の中に、利用者を追加するための処理を実行する。具体的には、チェックイン店舗確認画面において利用者が選択店舗とグループ店舗のいずれかに対する来店登録操作を行った場合に、待ち行列入力通知部44は、待ち行列入力情報を売買支援サーバ14へ送信する。
待ち行列入力情報は、第1の実施の形態のチェックイン情報と同じ構成であってよく、例えば利用者IDと、来店登録操作の対象である店舗のIDを指定するものであってよい。また、待ち行列入力情報は、利用者が特定の店舗の待ち行列に並ぶ(エントリする)ことを宣言する情報と言える。売買支援サーバ14は、待ち行列入力情報で指定された店舗を、利用者のチェックイン先の店舗として確定し、利用者の来店を示す店舗用チェックイン情報の提供先として確定する。
図14は、図12の店員操作端末17の機能構成を示すブロック図である。店員操作端末17は、待ち行列情報取得部80と、待ち行列情報表示部82と、サービス状況通知部84をさらに含む。待ち行列情報取得部80は、売買支援サーバ14が管理する自店舗の待ち行列情報を、通信網を介して取得する。実施の形態では、売買支援サーバ14が、待ち行列情報を更新した場合に、その情報と対応づけられた店舗の店員操作端末17へ更新後の待ち行列情報を提供することとする。変形例として、30秒等の所定時間が経過するたびに、待ち行列情報取得部80は、売買支援サーバ14へアクセスして最新の待ち行列情報を取得してもよい。
待ち行列情報表示部82は、待ち行列情報取得部80が取得した待ち行列情報を示す順番待ち管理画面をタッチパネル50に表示させる。順番待ち管理画面の具体例は後述する。
サービス状況通知部84は、順番待ち管理画面に対して、サービス提供の状況の変化を示す情報(以下「サービス状況更新情報」とも呼ぶ。)が入力された場合に、その入力情報を取得する。そして、取得したサービス状況更新情報を売買支援サーバ14へ送信することにより、売買支援サーバ14が管理する自店舗の待ち行列情報を更新させる。具体的には、サービス状況通知部84は、利用者(顧客)に対するサービス提供の開始を示す情報が順番待ち管理画面に入力された場合に、利用者ID、店舗ID、サービス開始日時、サービス提供場所を対応づけたサービス状況更新情報を売買支援サーバ14へ送信する。
図15は、図12の店舗内受付端末18の機能構成を示すブロック図である。店舗内受付端末18は、店員操作端末17の構成に類似し、対応する機能ブロック(同一の符号を付す)を備える。ただし店舗内受付端末18は、未チェックインの状態で来店した顧客用のユーザインタフェース機能を提供するものであり、具体的には、待ち行列情報の表示機能と待ち行列へのエントリ機能を提供する。店舗内受付端末18は、待ち行列情報取得部90と、待ち行列情報表示部92と、待ち行列入力通知部94を備える。
待ち行列情報取得部90は、店員操作端末17の待ち行列情報取得部80に対応し、売買支援サーバ14が管理する自店舗の待ち行列情報を、通信網を介して取得する。待ち行列情報表示部92は、待ち行列情報取得部80が取得した待ち行列情報を示す受付画面をタッチパネル50に表示させる。受付画面の具体例は後述する。
待ち行列入力通知部94は、店舗内受付端末18が設置された店舗の待ち行列の中に、利用者を追加するための処理を実行する。ここで対象とする利用者は、購入者端末10による事前チェックインをせずに店舗へ直接来店した顧客である。待ち行列入力通知部94は、受付画面において利用者が登録操作を行った場合に、予め定められた店舗のIDを指定した待ち行列入力情報を売買支援サーバ14へ送信する。
図16は、図12の売買支援サーバ14の機能構成を示すブロック図である。売買支援サーバ14は、待ち行列情報保持部200と、待ち時間情報保持部201と、待ち時間情報提供部202と、待ち行列入力受付部204と、待ち行列情報更新部206と、待ち行列情報提供部208と、サービス状況受付部210と、待ち時間推定部212をさらに含む。
待ち行列情報保持部200は、顔パス決済に参加している複数の店舗それぞれの待ち行列情報を記憶する記憶領域である。待ち時間情報保持部201は、顔パス決済に参加している複数の店舗それぞれの現在の推定待ち時間を示す待ち時間情報を記憶する記憶領域である。
図17は、待ち行列情報保持部200が記憶する待ち行列情報の構成を示す。待ち行列情報は、管理IDと、店舗IDと、待ち番号と、チェックイン日時と、サービス開始日時と、サービス提供場所を含む。待ち行列情報保持部200は、店舗毎かつチェックイン済み(来店済み)の利用者毎に、待ち行列情報のレコードを保持する。待ち行列情報は、店舗毎に待ち行列に並ぶ利用者を示す情報とも言える。
管理IDは、待ち行列のエントリのユニークなIDであり、ここでは店舗に対してチェックイン済みの利用者のIDとする。待ち番号は、チェックイン済み・来店済みの利用者に提示される店舗毎の整理番号である。サービス開始日時は、店舗において利用者へサービス提供を開始した日時を示す情報である。例えば飲食店においては、利用者を座席へ案内した日時であってもよい。サービス開始場所は、店舗において利用者へサービス提供をする場所を示す情報である。例えば飲食店においては、利用者を案内した座席の識別番号であってもよい。
図18は、待ち時間情報保持部201が記憶する待ち時間情報の構成を示す。待ち時間情報は、グループIDと、店舗IDと、推定待ち時間を含む。待ち時間情報保持部201は、店舗毎に待ち時間情報のレコードを保持する。店舗が他の店舗と同一のグループに属する場合、それらの店舗のレコードには予め同じグループIDが設定される。なお、待ち時間情報のうちグループIDと店舗IDは原則固定であり、その一方、待ち時間は随時更新される。
複数の店舗のグループ化について、例えば、経営者が同一の複数の店舗、同じ企業グループに属する複数の店舗、業務提携している複数の店舗等に対して同一のグループIDを設定してもよい。また、地理的に近傍に位置する複数の店舗、言い換えれば、店舗間の距離が所定範囲内の複数の店舗に対して同一のグループIDが付与されてもよい。また、これらの条件の任意の組み合わせにより店舗のグループを設定してもよい。
図16に戻り、待ち時間情報提供部202は、購入者端末10から送信されたチェックイン情報をチェックイン受付部120が受け付けた場合に、チェックイン情報で指定された選択店舗の待ち時間を待ち時間情報保持部201から取得する。それとともに、選択店舗と同一のグループIDが設定されたグループ店舗の待ち時間も待ち時間情報保持部201から取得する。待ち時間情報提供部202は、選択店舗の待ち時間と、グループ店舗の待ち時間の両方を、チェックイン情報の送信元の購入者端末10へ送信する。
待ち行列入力受付部204は、購入者端末10および店舗内受付端末18から送信された待ち行列入力情報を受け付ける。待ち行列情報更新部206は、待ち行列入力受付部204が受け付けた待ち行列入力情報にもとづいて、待ち行列情報保持部200に格納された待ち行列情報を更新する。
具体的には、待ち行列情報更新部206は、待ち行列入力情報で指定された利用者IDと店舗IDを設定した新規レコードを待ち行列情報保持部200に追加し、そのレコードにさらに以下の情報を記録する。すなわち待ち行列情報更新部206は、店舗IDで特定される店舗について予め定められた待ち番号の体系にしたがって待ち番号を採番して記録する。また、待ち行列入力情報を受け付けた日時をチェックイン日時として記録する。
待ち行列情報提供部208は、待ち行列情報保持部200が保持する待ち行列情報の更新状況を監視し、ある店舗の待ち行列情報が更新された場合に、その店舗の店員操作端末17と店舗内受付端末18に対して更新後の待ち行列情報を送信する。例えば、ある店舗IDの待ち行列情報が更新された場合に、その店舗IDに紐づけられた1つ以上の待ち行列情報を提供する。このとき、待ち時間情報保持部201に格納された当該店舗の待ち時間もあわせて送信する。これにより、最新の待ち行列情報と待ち時間を反映した順番待ち管理画面(店員操作端末17)と受付画面(店舗内受付端末18)を表示させる。
サービス状況受付部210は、店員操作端末17から送信されたサービス状況更新情報を受け付ける。待ち行列情報更新部206は、サービス状況受付部210が受け付けたサービス状況更新情報にもとづいて、待ち行列情報保持部200に格納された待ち行列情報を更新する。具体的には、待ち行列情報更新部206は、サービス状況更新情報で指定された利用者ID(管理ID)および店舗IDで特定されるレコードに対して、サービス状況更新情報で指定されたサービス開始日時とサービス提供場所を追加して記録する。既述したように、更新後の待ち行列情報は、待ち行列情報提供部208により、店員操作端末17および店舗内受付端末18へ提供される。
待ち時間推定部212は、各店舗の最新のサービス提供実績にもとづいて各店舗の現在の待ち時間を推定し、推定した現在の待ち時間によりそれまで待ち時間情報保持部201に格納された各店舗の待ち時間の値を更新する。待ち時間推定部212は、定期的に、例えば先の推定処理から1時間や30分等の所定時間が経過するたびに、各店舗の待ち時間の推定処理および更新処理を繰り返す。更新後の待ち時間情報は、待ち時間情報提供部202により、購入者端末10へ提供される。
ここで、ある1つの店舗(「特定店舗」と呼ぶ。)についての待ち時間の算出方法を説明する。待ち時間推定部212は、待ち行列情報保持部200を参照し、特定店舗のIDが設定された1つ以上の待ち行列情報レコードの中から、直近にサービス提供が開始された所定数のレコードを抽出する。抽出するレコード数は、商品売買システム100の管理者の知見や経験により決定されてよく、例えば、サービス開始日時が新しい方から5つのレコードを抽出してもよい。
待ち時間推定部212は、抽出した各レコードに記録されたチェックイン日時からサービス開始日時までの時間を待ち時間として求め、抽出したレコードの待ち時間の平均値を、特定店舗における現在の待ち時間として決定する。すなわち直近にサービス提供が開始された所定数の待ち行列情報レコードにもとづいた、待ち時間の移動平均値を現在の待ち時間として決定する。ただし、平均値の算出方法に制限はなく、例えば各レコードの待ち時間を求め、サービス開始日時が新しいものほど重い重み付けを付与して算出した加重平均値を現在の待ち時間として決定してもよい。
なお実施の形態では、待ち時間の起点としてチェックイン日時を用いることとし、具体的には、購入者端末10から送信された待ち行列入力情報を売買支援サーバ14が受け付けた日時を使用する。変形例では、待ち時間の起点として、購入者端末10から送信されたチェックイン情報を売買支援サーバ14が受け付けた日時を使用してもよく、また、売買支援サーバ14が店舗用チェックイン情報を店員操作端末17へ送信した日時を使用してもよい。すなわち待ち時間推定部212は、利用者によるチェックイン操作に関する時刻と、店舗におけるサービス提供開始時刻にもとづいて待ち時間を推定してもよい。
以上の構成による商品売買システム100の動作を以下説明する。第2の実施の形態の商品売買システム100の動作は、第1の実施の形態で既述した商品売買システム100の動作が前提となる。第1の実施の形態の商品売買システム100の動作と同じ動作は適宜説明を省略し、主に差分を説明する。なお、以下の例での店舗はレストランとする。
図7の店舗詳細画面140においてチェックイン操作が検出されると、購入者端末10のチェックイン通知部40は、チェックイン情報を売買支援サーバ14へ送信する。売買支援サーバ14のチェックイン受付部120は、購入者端末10から送信されたチェックイン情報を受信する。待ち時間情報提供部202は、チェックイン情報が示す選択店舗の推定待ち時間と、選択店舗に対応づけられたグループ店舗の推定待ち時間を、待ち時間情報保持部201から取得して購入者端末10へ送信する。購入者端末10のサービス情報取得部38は、チェックイン情報通知に対する売買支援サーバ14の応答として待ち時間情報を受信する。購入支援画面表示部36は、選択店舗とグループ店舗の推定待ち時間を提示するチェックイン店舗確認画面を表示させる。
図19は、購入者端末10に表示されるチェックイン店舗確認画面220を示す。選択店舗情報エリア222には、選択店舗の現在の推定待ち時間を表示し、グループ店舗情報エリア224には、グループ店舗の現在の推定待ち時間を表示する。図19では、売買支援サーバ14において、地図上での位置が近い渋谷店、原宿店、恵比寿店が同一グループとして設定されている例を示している。利用者は、選択店舗およびグループ店舗の待ち時間を勘案して、来店登録する店舗を選択し、その店舗の登録ボタン226をタップする(「登録操作」と呼ぶ。)。チェックイン店舗確認画面220において特定の店舗に対する登録操作が検出されると、待ち行列入力通知部44は、登録操作対象店舗を指定した待ち行列入力情報を売買支援サーバ14へ送信する。売買支援サーバ14は、登録操作対象店舗の待ち行列へ利用者を追加する。
ここで、待ち行列への利用者の追加は、店舗内受付端末18を介して行われることもある。図20は、店舗内受付端末18に表示される受付画面230を示す。店舗内受付端末18の待ち行列情報取得部90は、売買支援サーバ14から提供された自店舗の待ち行列情報を取得する。待ち行列情報表示部92は、自店舗の待ち行列情報から、サービス提供を待つ利用者の数と推定待ち時間を抽出する。例えば、売買支援サーバ14から提供された待ち行列情報のレコード数を、サービス提供待ちの利用者数と特定してもよい。なお、サービス提供待ちの利用者には、購入者端末10を介してチェックインした利用者と、店舗内受付端末18を介して登録した利用者の両方が含まれる。待ち行列情報表示部92は、サービス提供待ちの利用者数と推定待ち時間を、受付画面230の待ち時間情報エリア232に表示させる。
購入者端末10によるチェックインをせずに店舗へ直接来店した利用者は、受付画面230に表示された待ち時間等を確認し、登録ボタン234をタップする(「登録操作」と呼ぶ。)。受付画面230において登録操作が検出されると、店舗内受付端末18の待ち行列入力通知部94は、自店舗を指定した待ち行列入力情報を売買支援サーバ14へ送信する。その際に、利用者IDは未設定であってもよく、店舗内受付端末18からの情報であることを示す所定の値を設定してもよい。
売買支援サーバ14の待ち行列入力受付部204は、購入者端末10および店舗内受付端末18から送信された待ち行列入力情報を受信する。送信元が購入者端末10の場合、待ち行列入力受付部204は、待ち行列入力情報にもとづいて利用者チェックイン情報(図6(b))を設定して利用者情報保持部111へ格納する。また乱数取得部122は乱数列を取得し、乱数提供部124はその乱数列を購入者端末10へ提供する。これにより、第1の実施の形態と同様に、利用者へ確認コードが提供される。またチェックイン情報提供部126は、店舗用チェックイン情報を店員操作端末17へ送信する。
待ち行列入力情報の送信元が購入者端末10と店舗内受付端末18のいずれの場合も、待ち行列情報更新部206は、チェックイン先の店舗または店舗内受付端末18が設置された店舗について、その待ち行列情報を更新する。待ち行列情報提供部208は、更新後の待ち行列情報を、その待ち行列情報が対応づけられた店舗の店員操作端末17および店舗内受付端末18へ提供する。これにより、店員操作端末17の順番待ち管理画面と、店舗内受付端末18の受付画面230を、更新後の待ち行列情報を反映した内容へ切り替える。
図21は、店員操作端末17に表示される順番待ち管理画面240を示す。店員操作端末17の待ち行列情報取得部80は、売買支援サーバ14から送信された自店舗の待ち行列情報を受信する。待ち行列情報表示部82は、自店舗の待ち行列情報を順番待ちリスト242に表示させる。そのときチェックイン日時を来店時刻のフィールドに表示させる。また、待ち行列情報として提供された複数レコードを、来店時刻の昇順に、すなわちチェックイン日時もしくは来店日時が古い順に、順番待ちリスト242の上から並べて表示させる。
店舗の従業員は、順番待ち管理画面240を確認して、順番待ちリスト242の上に表示された顧客を優先して席に案内し、顧客へのサービス提供を開始する。そのとき従業員は、席に案内する顧客の待ち番号を確認して、その待ち番号を示す順番待ちリスト242のレコードをタップし、案内座席の情報を入力した上で、案内ボタン244をタップする。案内ボタン244は、サービスの提供開始を登録するボタンと言える。案内ボタン244がタップされると、店員操作端末17のサービス状況通知部84は、利用者へのサービス提供を開始した旨を示すサービス状況更新情報を売買支援サーバ14へ送信する。
売買支援サーバ14のサービス状況受付部210は、店員操作端末17から送信されたサービス状況更新情報を受信する。待ち行列情報更新部206は、サービス状況更新情報が示す店舗の待ち行列情報の中から、サービスが開始された顧客のレコードを特定する。そして、特定したレコードに、サービス状況更新情報が示すサービス開始日時・サービス提供場所の値を記録する。待ち時間推定部212は、定期的に、各店舗の最近の待ち行列情報を参照し、チェックイン日時とサービス開始日時の差分にもとづいて、各店舗の現在の待ち時間を推定する。そして各店舗についての推定待ち時間のデータを待ち時間情報保持部201へ格納することで、最新の推定待ち時間をチェックイン者へ提供する。
店舗にてサービスの提供を開始した後のシステムの動作は、第1の実施の形態と同様である。すなわち、店舗での会計時に、利用者による事前のチェックイン操作に伴って予め店舗へ通知された利用者の写真と、予め利用者へ通知された確認コードを用いた顔パス決済処理を実行する。
第2の実施の形態の商品売買システム100によると、サービス提供待ちの利用者により形成された店舗の待ち行列に対するエントリ時刻と、利用者へのサービス開始時刻を計測し、これらの実測値にもとづいて店舗の待ち時間を推定する。言い換えれば、直近過去の利用者の待ち時間を実測し、その待ち時間にもとづいて、これから店舗へチェックインしようとしている利用者の待ち時間を推定する。また、定期的に直近のサービス提供実績にもとづいて待ち時間を再度推定し、推定値を更新する。これにより、第1の実施の形態で既述した効果に加えて、顔パス決済において必須となる事前チェックイン時に、チェックイン対象店舗の現在の待ち時間として精度の高い推定値を利用者へ提示できる。また、チェックイン実施の意思決定、および、待ち時間の有効活用を支援し、利用者の利便性を高めることができる。
また、店舗詳細画面140で選択された選択店舗の推定待ち時間に加えて、選択店舗と同一のグループに属する他店舗の推定待ち時間も利用者へ提示する。これにより、待ち時間に応じた店舗選択の選択肢を利用者へ提示できる。また販売者にとっても、選択店舗の待ち時間が長い場合でも、グループ店舗への集客を促進できるため、販売の機会損失を回避しやすくなる。
以上、第2の実施の形態を説明した。この実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。以下変形例を示す。
第2の実施の形態についての、第1の変形例を説明する。
上記実施の形態では、チェックイン日時とサービス開始日時の差分にもとづいて待ち時間を推定することとした。変形例として、公知の待ち行列理論を活用し、利用者の平均到着率と平均サービス時間の実測値にもとついて待ち時間を推定してもよい。この変形例の構成でも、第2の実施の形態と同様の効果を奏する。
上記実施の形態では、チェックイン日時とサービス開始日時の差分にもとづいて待ち時間を推定することとした。変形例として、公知の待ち行列理論を活用し、利用者の平均到着率と平均サービス時間の実測値にもとついて待ち時間を推定してもよい。この変形例の構成でも、第2の実施の形態と同様の効果を奏する。
この変形例では、売買支援サーバ14の待ち行列情報保持部200は、待ち行列情報のレコードに、店舗において利用者(顧客)へのサービス提供が終了した日時であるサービス終了日時をさらに保持する。また、店員操作端末17のサービス状況通知部84は、顧客へのサービス提供が終了したことを示す情報の入力を検出すると、そのときの現在日時をサービス終了日時として含むサービス状況更新情報を売買支援サーバ14へ送信する。
例えば、サービス状況通知部84は、サービス代金(商品代金)の決済処理に成功した旨の情報を売買支援サーバ14から受け付けた場合に、利用者ID、店舗ID、サービス終了日時を対応づけたサービス状況更新情報を売買支援サーバ14へ送信してもよい。また、図11に示す顔パス決済画面190において決定ボタン198がタップされた場合に、同様のサービス状況更新情報を売買支援サーバ14へ送信してもよい。売買支援サーバ14のサービス状況受付部210は、利用者IDおよび店舗IDで特定される待ち行列情報のレコードに、サービス終了日時を記録する。
本変形例でも、売買支援サーバ14の待ち時間推定部212は、定期的に各店舗の待ち時間を推定し、待ち時間情報保持部201の待ち時間情報を更新する。ここで、ある1つの店舗(「特定店舗」と呼ぶ。)についての待ち時間の算出方法を説明する。待ち時間推定部212は、待ち行列情報保持部200を参照し、特定店舗のIDが設定された1つ以上の待ち行列情報レコードの中から、直近にサービス提供が終了した所定数のレコードを抽出する。抽出するレコード数は、商品売買システム100の管理者の知見や経験により決定されてよく、例えば、サービス終了日時が新しい方から5つのレコードを抽出してもよい。
待ち時間推定部212は、抽出した各レコードに記録されたサービス開始日時からサービス終了日時までの時間をサービス時間として求め、抽出したレコードのサービス時間の平均値を、特定店舗における現在の平均サービス時間として決定する。すなわち直近にサービス提供が終了した所定数の待ち行列情報レコードにもとづいた、サービス時間の移動平均値を現在の平均サービス時間として推定する。
また待ち時間推定部212は、待ち行列情報保持部200を参照し、特定店舗のIDが設定された1つ以上の待ち行列情報レコードの中から、直近の一定期間、例えば、前回待ち時間を推定してから現在までの期間内のチェックイン件数(店舗内受付端末18からの登録件数を含む)を特定する。具体的には、直近の一定期間内の日時をチェックイン日時とするレコードの件数を、チェックイン件数として特定する。そして、そのチェックイン件数にもとづいて利用者の平均到着率を推定する。言い換えれば、単位時間あたりの特定店舗へのチェックイン頻度を平均到着率として推定する。
待ち時間推定部212は、M/M/Sの待ち行列モデルに、上記で求めた利用者の平均到着率と、平均サービス時間をあてはめることにより、特定店舗の平均待ち時間を算出し、その値を現在の推定待ち時間として記録する。上記モデルの「S」の値は店舗毎に予め定められてよく、1組の顧客を案内する単位となる空間の数であってもよい。例えば特定店舗がレストランであれば、顧客の案内先の単位となる座席数、テーブル数、ボックス数等をSの値として設定してもよい。なお、M/M/Sの待ち行列モデルは公知のモデル、例えば公知の計算式を使用してもよい。
また、サービス時間は、売買支援サーバ14に代わり店員操作端末17が算出してもよい。具体的には、店員操作端末17は、顧客へのサービス開始日時を記憶するサービス開始時刻保持部と、サービス時間算出部をさらに備えてもよい。サービス時間算出部は、顧客へのサービス提供が終了したことを示す情報の入力を検出する(例えば、決済成功の通知を売買支援サーバ14から受け付ける)と、そのときの現在日時をサービス終了日時として決定し、その顧客へのサービス開始日時からサービス終了日時までの時間をサービス時間として算出する。そして店員操作端末17のサービス状況通知部84は、サービス状況更新情報として、サービス時間算出部が算出したサービス時間、利用者IDおよび店舗IDを売買支援サーバ14へ送信してもよい。
このように、店員操作端末17は、売買支援サーバ14に対して、サービス開始時刻とサービス終了時刻を通知してもよく、また、サービス時間そのものを通知してもよい。すなわち、店員操作端末17は、店舗が顧客へ提供したサービス時間を特定可能な情報を売買支援サーバ14へ提供すればよい。売買支援サーバ14は、店員操作端末17から提供された情報にもとづいてサービス時間を特定し、その一方、自身で管理する情報から顧客の到着率を特定し、これを待ち行列モデルに当てはめて平均待ち時間を推定する。
また売買支援サーバ14は、第2の実施の形態に記載の方法と、第1の変形例に記載の方法の両方を使用して、店舗の待ち時間を推定してもよい。そして、短い方の待ち時間を推定待ち時間として利用者へ提示してもよい。この態様によると、サービス開始時点で利用者が店舗に存在することの確実性を高めやすくなり、利用者の不在によりサービスの提供が他者の後に回されてしまうことを防止しやすくなる。また、店舗においてもサービス提供可能となったときに、顧客が来店している可能性が高くなり、効率的なサービス提供を実現しやすくなる。また逆に、長い方の待ち時間を推定待ち時間として利用者へ提示してもよい。この態様によると、事前チェックインした利用者が、推定待ち時間を超えて長時間待たされてしまうことを防止しやすくなる。
第2の実施の形態についての、第2の変形例を説明する。
上記実施の形態では、売買支援サーバ14が、1)店舗における各利用者(顧客)へのサービス開始時刻を記憶し、2)店舗における現在の待ち時間を推定し、3)待ち時間の推定値を購入者端末10へ提供することとした。変形例として、店舗側の装置、例えば店員操作端末17が、上記1)から3)の少なくとも一部を実行してもよい。この変形例の構成でも、第2の実施の形態と同様の効果を奏する。
上記実施の形態では、売買支援サーバ14が、1)店舗における各利用者(顧客)へのサービス開始時刻を記憶し、2)店舗における現在の待ち時間を推定し、3)待ち時間の推定値を購入者端末10へ提供することとした。変形例として、店舗側の装置、例えば店員操作端末17が、上記1)から3)の少なくとも一部を実行してもよい。この変形例の構成でも、第2の実施の形態と同様の効果を奏する。
例えば、店員操作端末17は、実施の形態では売買支援サーバ14が備えることとした待ち時間推定部212を備え、サービス状況更新情報にもとづいて自店舗の待ち時間を推定してもよい。すなわち店員操作端末17は、上記の1)および2)を実行して、自店舗の待ち時間の推定値を売買支援サーバ14へ通知してもよい。売買支援サーバ14は、店員操作端末17から提供された推定待ち時間を記憶し、当該店舗(もしくは当該店舗と同じグループに属する他店舗)へのチェックインがなされる場合に購入者端末10へ提供してもよい。
第2の実施の形態についての、第3の変形例を説明する。
上記実施の形態では言及していないが、売買支援サーバ14は所定の提供条件が充足されたか否かを判定する提供条件判定部をさらに備えてもよい。売買支援サーバ14の待ち時間情報提供部202は、提供条件判定部が提供条件の充足を検出した場合に、選択店舗に加えてグループ店舗の推定待ち時間を購入者端末10へ提供する。その一方、提供条件が充足されず、提供条件の充足が未検出であれば、選択店舗の推定待ち時間のみを購入者端末10へ提供してもよい。
上記実施の形態では言及していないが、売買支援サーバ14は所定の提供条件が充足されたか否かを判定する提供条件判定部をさらに備えてもよい。売買支援サーバ14の待ち時間情報提供部202は、提供条件判定部が提供条件の充足を検出した場合に、選択店舗に加えてグループ店舗の推定待ち時間を購入者端末10へ提供する。その一方、提供条件が充足されず、提供条件の充足が未検出であれば、選択店舗の推定待ち時間のみを購入者端末10へ提供してもよい。
売買支援サーバ14の提供条件判定部は、選択店舗の待ち時間が所定の閾値以上である場合に、提供条件が充足されたと判定してもよい。この閾値は、売買支援サーバ14の管理者が予め定めた固定時間(例えば1時間)であってもよく、利用者が売買支援サーバ14に予め登録した任意の時間であってもよい。
また売買支援サーバ14の待ち時間情報提供部202は、チェックイン情報への応答として、選択店舗の推定待ち時間のみを一旦購入者端末10へ提供してもよい。購入者端末10の店舗詳細画面140においてグループ店舗の情報表示を指示する旨の操作入力を受け付けると、購入者端末10は、グループ店舗の待ち時間提供要求を売買支援サーバ14へ送信してもよい。この要求を受け付けると、購入者端末10の提供条件判定部は、提供条件が充足されたと判定し、待ち時間情報提供部202は、グループ店舗の推定待ち時間をさらに購入者端末10へ提供してもよい。
第2の実施の形態についての、第4の変形例を説明する。
上記実施の形態では言及していないが、売買支援サーバ14は、利用者の待ち時間の残りが予め定められた規定時間になったタイミングで、利用者が予め売買支援サーバ14に登録しておいた連絡先へ、もうすぐサービス提供が開始される旨のメッセージ(以下、「サービス開始アラート」と呼ぶ。)を通知してもよい。この変形例によると、サービス提供の開始時に利用者が店舗に来訪している確実性を高め、利用者が所望のサービスを享受することを支援できる。
上記実施の形態では言及していないが、売買支援サーバ14は、利用者の待ち時間の残りが予め定められた規定時間になったタイミングで、利用者が予め売買支援サーバ14に登録しておいた連絡先へ、もうすぐサービス提供が開始される旨のメッセージ(以下、「サービス開始アラート」と呼ぶ。)を通知してもよい。この変形例によると、サービス提供の開始時に利用者が店舗に来訪している確実性を高め、利用者が所望のサービスを享受することを支援できる。
例えば、売買支援サーバ14の待ち行列情報更新部206は、あるユーザのチェックインに伴い待ち行列情報を待ち行列情報保持部200に記録すべき際に、現在日時から、チェックイン対象店舗の推定待ち時間を経過させたサービス開始日時の推定値(以下、「推定サービス開始日時」と呼ぶ。)を待ち行列情報に含めて記録してもよい。売買支援サーバ14は、アラート通知部をさらに備え、アラート通知部は、現在日時と推定サービス開始日時の間隔が規定時間以下になったことを検出すると、規定の連絡先へサービス開始アラートを送信してもよい。
この規定時間は、売買支援サーバ14において予め定められた時間でもよく、利用者が予め売買支援サーバ14に登録した時間でもよく、例えば15分等に設定されてもよい。規定の連絡先は、典型的にはサービス開始アラートを受信する情報機器であり、例えば、利用者が売買支援サーバ14に予め登録した購入者端末10のアドレスでもよい。サービス開始アラートの送信方法は、電子メールでもよく、スマートフォンに対する公知のプッシュ通知でもよい。
なお、売買支援サーバ14の待ち行列情報更新部206は、待ち時間推定部212が店舗の待ち時間を更新した場合に、更新後の推定待ち時間にもとづいて、事前に記録した推定サービス開始日時を更新してもよい。具体的には、更新前の推定待ち時間と更新後の推定待ち時間の差分を、事前に記録した推定サービス開始日時に反映させてもよい。例えば、更新後の推定待ち時間が更新前の推定待ち時間より短くなった場合、短くなった時間分、推定サービス開始日時を早めるよう更新してもよい。この態様によると、最新の推定待ち時間を反映したタイミングでサービス開始アラートを利用者へ通知できる。
第2の実施の形態についての、第5の変形例を説明する。
第1の実施の形態の変形例としても一部記載したが、売買支援サーバ14から店員操作端末17へ提供される店舗用チェックイン情報には、利用者の顔写真に限らず、利用者を他者と区別することができる情報であり、利用者に関する様々な識別情報が設定されてもよい。この識別情報は、必ずしも利用者の外見の特徴を示す情報でなくてもよい。例えば、店舗(の従業員)と利用者との間で予め取り決めた言葉(合い言葉や、符丁等)であってもよい。この場合、利用者は店舗従業員に合い言葉と名前を申告し、それらが正しければ店舗従業員は決済処理を進めさせてもよい。また、利用者の名前だけ売買支援サーバ14から店員操作端末17へ提供してもよい。この場合、利用者は店舗従業員に名前を申告し、その名前が店員操作端末17上のリストに存在すれば店舗従業員は決済処理を進めさせてもよい。
第1の実施の形態の変形例としても一部記載したが、売買支援サーバ14から店員操作端末17へ提供される店舗用チェックイン情報には、利用者の顔写真に限らず、利用者を他者と区別することができる情報であり、利用者に関する様々な識別情報が設定されてもよい。この識別情報は、必ずしも利用者の外見の特徴を示す情報でなくてもよい。例えば、店舗(の従業員)と利用者との間で予め取り決めた言葉(合い言葉や、符丁等)であってもよい。この場合、利用者は店舗従業員に合い言葉と名前を申告し、それらが正しければ店舗従業員は決済処理を進めさせてもよい。また、利用者の名前だけ売買支援サーバ14から店員操作端末17へ提供してもよい。この場合、利用者は店舗従業員に名前を申告し、その名前が店員操作端末17上のリストに存在すれば店舗従業員は決済処理を進めさせてもよい。
(第3の実施の形態)
第3の実施の形態では、販売者の店舗が移動販売車等による移動販売店舗(例えば「移動スーパーマーケット」)である場合に、第1および第2の実施の形態で提案した顔パス決済を適用する商品売買システム100を提案する。
第3の実施の形態では、販売者の店舗が移動販売車等による移動販売店舗(例えば「移動スーパーマーケット」)である場合に、第1および第2の実施の形態で提案した顔パス決済を適用する商品売買システム100を提案する。
第3の実施の形態では、第1および第2の実施の形態における販売者店舗へのチェックイン操作が、販売者店舗に対して所望の地域へ来訪するよう指示するための来訪指示操作に置き換わる。具体的には、購入者端末10の所定画面(例えば店舗詳細画面140)における来訪指示操作の入力に伴い、購入者端末10は、その来訪指示を示す来訪指示情報を売買支援サーバ14へ送信する。売買支援サーバ14は、利用者の顔写真に加えて来訪指示情報を店舗端末12へ送信する。
来訪指示情報の構成は、第1および第2の実施の形態の店舗用チェックイン情報と同様であるが、販売者店舗が来訪すべき地域および日時を示す情報を含む。来訪指示情報で指定される来訪地域は生活者の生活地域であってもよい。例えば、利用者の住所の近傍地域であってもよく、利用者の職場の近傍地域であってもよく、利用者にとって商品購入に都合のよい地域でよい。これにより販売者は、店舗端末12において利用者の顔写真とともに、訪問先と訪問日時を認識することができる。
利用者は、来訪指示操作の入力画面(例えば店舗詳細画面140)で、販売者店舗の来訪を指示する地域と日時を都度指定してもよい。また来訪地域については、利用者登録等のタイミングで、移動販売店舗に対する訪問希望地域を売買支援サーバ14に登録し、売買支援サーバ14の利用者情報保持部111が記憶してもよい。また、販売者店舗が訪問可能な地域や日時が予め定められてもよく、購入者端末10の店舗詳細画面140において選択可能に表示されてもよい。利用者は、自身に都合のよい地域と日時を選択しつつ、所望の販売者店舗(移動販売店舗)に対する来訪指示操作を入力してもよい。
第3の実施の形態の商品売買システム100の他の構成は、第1または第2の実施の形態の商品売買システム100と同様である。例えば、第1の実施の形態で説明した確認コードの照合処理と組み合わせることにより、セキュリティの強度を一層高めてもよい。第3の実施の形態によると、購入者が移動販売店舗において商品を購入する場合も、言い換えれば、販売者店舗が移動販売店舗である場合も顔パス決済を実現できる。例えば、過疎化地域に対する移動販売車による商品販売サービスに対しても、顔パス決済の利便性を提供できる。
第3の実施の形態の技術思想は、以下に付記する構成として表現することもできる。
第3の実施の形態の技術思想は、以下に付記する構成として表現することもできる。
(付記1)
商品の購入者が用いる購入者端末と、
商品の販売者が用いる販売者端末と、
通信網を介して前記購入者端末および前記販売者端末と接続されるサーバと、
を備え、
販売者の店舗は移動販売店舗であり、
前記購入者端末は、
販売者の店舗が所望の地域へ来訪するよう指示するための来訪指示操作を購入者から受け付ける受付部を含み、
前記サーバは、
購入者が商品代金を電子決済するために必要な情報である決済情報を保持する決済情報保持部と、
前記購入者端末において前記来訪指示操作がなされた場合に、購入者を識別するための購入者識別情報を前記販売者端末へ提供する購入者情報提供部を含み、
前記販売者端末は、
販売者の店舗にて購入者が商品を購入する際に、前記サーバから通知された購入者識別情報の中から、商品を購入する購入者の情報を販売者に選択させるための選択画面を表示させる選択画面表示部と、
前記選択画面において選択された購入者を指定した決済要求を前記サーバへ通知する決済要求通知部と、を含み、
前記サーバは、前記決済要求で指定された購入者の決済情報を使用して、商品代金の電子決済を実行させる決済処理部をさらに含むことを特徴とする情報処理システム。
商品の購入者が用いる購入者端末と、
商品の販売者が用いる販売者端末と、
通信網を介して前記購入者端末および前記販売者端末と接続されるサーバと、
を備え、
販売者の店舗は移動販売店舗であり、
前記購入者端末は、
販売者の店舗が所望の地域へ来訪するよう指示するための来訪指示操作を購入者から受け付ける受付部を含み、
前記サーバは、
購入者が商品代金を電子決済するために必要な情報である決済情報を保持する決済情報保持部と、
前記購入者端末において前記来訪指示操作がなされた場合に、購入者を識別するための購入者識別情報を前記販売者端末へ提供する購入者情報提供部を含み、
前記販売者端末は、
販売者の店舗にて購入者が商品を購入する際に、前記サーバから通知された購入者識別情報の中から、商品を購入する購入者の情報を販売者に選択させるための選択画面を表示させる選択画面表示部と、
前記選択画面において選択された購入者を指定した決済要求を前記サーバへ通知する決済要求通知部と、を含み、
前記サーバは、前記決済要求で指定された購入者の決済情報を使用して、商品代金の電子決済を実行させる決済処理部をさらに含むことを特徴とする情報処理システム。
(第4の実施の形態)
上記第1および第2の実施の形態では、商品またはサービスの購入にあたり商品売買システム100を利用するユーザ(以下では「利用者」と呼ぶが、購入者、顧客ともいえる。)は、実在する店舗を指定するチェックイン操作を購入者端末10で実施した。このチェックインという行為は、所望の商品またはサービスを提供する店舗へ来訪予定であることを示す意思表明といえるが、店舗への来訪日時を約束するものではない。したがって、第1および第2の実施の形態に記載のシステムは、来訪予約が不要の店舗に対して特に好適であった。
上記第1および第2の実施の形態では、商品またはサービスの購入にあたり商品売買システム100を利用するユーザ(以下では「利用者」と呼ぶが、購入者、顧客ともいえる。)は、実在する店舗を指定するチェックイン操作を購入者端末10で実施した。このチェックインという行為は、所望の商品またはサービスを提供する店舗へ来訪予定であることを示す意思表明といえるが、店舗への来訪日時を約束するものではない。したがって、第1および第2の実施の形態に記載のシステムは、来訪予約が不要の店舗に対して特に好適であった。
その一方、来訪日時を指定した来訪予約を利用者が行うべき店舗も存在し、また、予約済みの利用者と予約なしの利用者の両方を受け入れる店舗も存在する。これらの店舗を総称して「予約型店舗」とも呼ぶ。予約型店舗は、レストラン、ブティック、医療機関等、種々の業種、業態を含む。予約型店舗では利用者からの来訪予約を受け付けるが、予約済みの利用者に別途チェックイン操作も課してしまうと、その利用者にとって二度手間となり、利用者の利便性を低下させてしまう場合があることに本発明者は想到した。
そこで第4の実施の形態では、予約型店舗に好適な顔パス決済の仕組みを提案する。第4の実施の形態の商品売買システム100の構成は、第1の実施の形態の商品売買システム100と同様であり、すなわち図1に示す通りである。
図22は、図1の購入者端末10の機能構成を示すブロック図である。第4の実施の形態の購入者端末10は、予約画面表示部250と予約情報通知部252をさらに含む。図22以降の図面では、第1〜第3の実施の形態で説明済みの機能ブロックと同一もしくは対応する機能ブロックには同一の符号を付しており、重複する説明は適宜省略する。
予約画面表示部250は、購入支援画面表示部36と同様に、顔パス決済サービスにおける利用者側の画面である来店予約画面をタッチパネル20に表示させる。購入支援画面表示部36により表示される商品購入支援画面と同様に、来店予約画面には、(1)初期画面としての売買支援サーバ14へのログイン画面、(2)顔パス決済サービスを提供するサービス事業者(ブランド)の選択画面、(3)サービス事業者が運営する店舗の選択画面、(4)店舗の詳細情報を表示する店舗詳細画面、(5)店舗に来店予約をした場合の予約完了画面が含まれる。予約画面表示部250は、これら複数種類の画面を、利用者の操作に応じて順次切り替えて表示させる。現実の実装では、これら複数種類の画面の一部を表示させてもよいことはもちろんである。例えば、個社別に顔パス決済のソリューションを提供する場合、(2)のブランド選択画面はなくてもよく、(3)の店舗選択画面をログイン後のトップ画面として表示させてもよい。
予約画面表示部250は、利用者が予約型店舗を選択し、図7で例示した店舗詳細画面140において顔パス決済選択フィールド142を選択した場合に、来店日および来店時刻の入力フィールドと、予約実行ボタンを含む予約入力画面を表示させる。予約画面表示部250は、チェックインと予約の両方を受け付ける予約型店舗が選択された場合は、来店日時を指定せずに単にチェックインするか、来店日時を指定して来店予約をするかの選択画面をさらに表示させてもよい。なお、予約入力画面は、商品購入支援画面の一部として購入支援画面表示部36が表示させてもよい。
操作検出部26は、予約入力画面において、利用者が来店予約を行うことを示す所定操作(例えば予約実行ボタンの押下操作であり、以下「予約実行操作」と呼ぶ。)を入力した場合に、その事実を検出する。予約情報通知部252は、予約実行操作が検出された場合に、予約入力画面に対する入力情報であり、店舗詳細画面で利用者が顔パス決済を選択した店舗に対する利用者の予約内容を示す予約情報を取得し、売買支援サーバ14へ送信する。この予約情報には、利用者IDと、予約先のサービス事業者IDおよび店舗IDと、来店を約束する日付および時刻(以下、「予約来店日時」と呼ぶ。)が含まれる。
ワンタイムコード生成部42は、予約情報の通知に対する応答として売買支援サーバ14から送信された乱数列を取得し、第1の実施の形態と同様に、取得した乱数列にもとづく確認コードを生成する。第4の実施の形態の確認コードも、今回の来店予約に限り一時的に有効な照合情報であり、いわゆるワンタイムパスワードである。予約画面表示部250は、ワンタイムコード生成部42が生成した確認コードを、図8のチェックイン画面150と同様の予約完了画面に表示させる。予約画面表示部250は、予約完了画面に、利用者が予約実行操作の際に入力した予約来店日時を確認的に表示させる。
図23は、図1の売買支援サーバ14の機能構成を示すブロック図である。第4の実施の形態の売買支援サーバ14は、予約情報受付部260と予約情報提供部262をさらに含む。予約情報受付部260は、チェックイン受付部120と同様に動作する。具体的には、購入者端末10から通知された予約情報を受け付け、その予約情報にもとづく利用者予約情報を利用者情報保持部111へ格納する。
第4の実施の形態において利用者情報保持部111に格納される利用者チェックイン情報は、図6(b)に示す項目に加え、項目「受付区分」をさらに含み、その値として「チェックイン」が設定される。また、第4の実施の形態において利用者情報保持部111に格納される利用者予約情報は、図6(b)に示す項目に加え、項目「受付区分」、「予約来店日時」をさらに含み、それぞれの値として「予約」、利用者が入力した来店日時が設定される。
予約情報受付部260は、予約情報を受け付けた場合に、予約情報が示す予約来店日時にもとづいて顔パス有効期限を設定する。典型的には、顔パス有効期限は、予約来店日時と実際の来店日時の間で想定されるずれや、利用者が来店してから決済行為がなされるまでの想定時間を考慮して設定される。また、店舗毎に予め定められた顔パス有効期限の設定規則にしたがって、顔パス有効期限を設定してもよい。例えば、予約来店日時の前後1時間の期間を顔パス有効期限として設定してもよい。
乱数取得部122は、チェックイン情報が受け付けられた場合と同様に、予約情報が受け付けられた際に、所定の乱数発生器で生成された乱数列を取得する。乱数取得部122は、取得した乱数列のデータを、利用者情報保持部111の利用者予約情報に設定する。乱数提供部124は、乱数取得部122が取得した乱数列のデータを、予約情報の通知に対する応答として購入者端末10へ送信する。
予約情報提供部262は、予約情報が受け付けられた場合に店舗用予約情報を生成し、生成した店舗用予約情報を、公知のプッシュ通知の方法により店舗端末12へ送信する。店舗用予約情報は、図4の店舗用チェックイン情報の項目に加え、項目「受付区分」(値は「予約」)と、項目「来店予約日時」(値は予約情報が示す来店予約日時)を含む。なお、チェックイン情報提供部126が店舗端末12へ送信する店舗用チェックイン情報にも、図4の店舗用チェックイン情報の項目に加え、項目「受付区分」(値は「チェックイン」)が含まれることとする。
図24は、図1の店舗端末12の機能構成を示すブロック図である。第4の実施の形態の店舗端末12は、予約情報保持部270と予約情報更新部272をさらに含む。予約情報保持部270は、自店舗に対して来店予約した利用者に関する属性情報、すなわち上記の店舗用予約情報を保持する。既述したように、店舗用予約情報は、図4の店舗用チェックイン情報の項目に加え、項目「受付区分」(値は「予約」)と、項目「来店予約日時」(値は利用者が設定した来店予約日時)を含む。
予約情報更新部272は、チェックイン情報更新部70に対応し、売買支援サーバ14から送信された店舗用予約情報を受け付け、予約情報保持部270へ格納する。言い換えれば、自店舗に対して来店予約した利用者の顔写真と予約来店日時を売買支援サーバ14から取得して予約情報保持部270へ記録する。
第4の実施の形態の販売支援画面表示部66は、商品販売支援画面として購入者選択画面をタッチパネル50に表示させる。購入者選択画面は、チェックイン済みもしくは来店予約済みの購入者の顔写真の中から、商品またはサービスを購入し、その代金を支払う購入者の顔写真を店舗販売員に選択させる画面である。第4の実施の形態では、購入者選択画面を、売買支援サーバ14へのログイン画面の表示後、メニュー選択画面の表示前に表示する。言い換えれば、売買支援サーバ14へのログイン後、商品販売支援画面のトップ画面として購入者選択画面を表示させる。変形例として、第1の実施の形態と同様に、会計画面180の顔パス決済指定エリア184で表示してもよい。
図25および図26は購入者選択画面を示す。販売支援画面表示部66は、チェックイン情報保持部54に格納された店舗用チェックイン情報と、予約情報保持部270に格納された店舗用予約情報の両方を並べて購入者選択画面280に表示させる。具体的には、店舗用チェックイン情報の場合、受付区分欄に文字列「チェックイン」を設定し、来店予定者欄にチェックイン済み利用者の顔写真画像と氏名を設定する。また店舗用予約情報の場合、受付区分欄に文字列「予約」を設定し、写真欄に来店予約済み利用者の顔写真画像と氏名を設定し、予約来店時刻欄に予約来店時刻を設定する。ここでは、来店予約済み利用者の情報とチェックイン済み利用者の情報の両方を表示しているが、事前の来店予約が必須の店舗であれば前者のみ表示することになる。
販売支援画面表示部66は、来店予約済みの利用者情報(すなわち店舗用予約情報)を、予約来店日時の昇順に並べ、かつ、予約来店日時の近傍期間(実施の形態では来店予約日時の前後1時間)のみ購入者選択画面280に表示させる。言い換えれば、来店予約済みの利用者の顔写真を、少なくとも予約来店日時を含む所定期間に購入者選択画面280に表示させる一方、その期間を経過すると非表示とするよう切り替える。
購入者選択画面280において来店予約済み利用者情報の表示を開始し、また終了するタイミングは、店舗の権限者により任意に決定されて店舗端末12に入力されてよい。店舗端末12の販売支援画面表示部66は、店舗の権限者により指定された開始タイミング(例えば予約来店日時の1時間前)および終了タイミング(例えば予約来店日時の1時間後)にしたがって、来店予約済み利用者情報の表示開始と表示終了を制御してもよい。
なお、購入者選択画面280において来店予約済み利用者情報の表示を開始し、また終了するタイミングは、売買支援サーバ14が設定する顔パス有効期限に対応することが望ましい。例えば、店舗端末12は、店舗の権限者による開始タイミングおよび終了タイミングの入力を受け付けると、その情報を売買支援サーバ14へアップロードしてもよい。売買支援サーバ14は、開始タイミングから終了タイミングまでの期間を顔パス有効期限の設定基準として、アップロード元の店舗と対応づけて保持し、以降その店舗に来店予約した利用者の顔パス有効期限を設定する際にその基準を適用してもよい。
また販売支援画面表示部66は、チェックイン済みの利用者情報(すなわち店舗用チェックイン情報)を、チェックイン日時の昇順(すなわち売買支援サーバ14から店舗用チェックイン情報が通知された順)に並べて表示させる。また、来店予約済みの利用者情報とは異なり、時間経過に伴って非表示とすることはしない。変形例として、第1の実施の形態の第11の変形例、第12の変形例で記載したように、所定期間の経過(例えば顔パス有効期限切れ)に伴い、チェックイン済み利用者情報も購入者選択画面280で非表示としてもよい。なお、チェックイン済み利用者に対する顔パス有効期限の設定基準も、上記同様に、店舗の権限者が決定してもよいことはもちろんである。
図25は、ある日の11時45分の購入者選択画面280の表示内容を示している。同図では、予約済み利用者のうち予約来店時刻が当日の10時45分〜12時45分の「星野二郎」、「野村花子」が表示されている。チェックイン済み利用者の「上野桜」は、「星野二郎」の表示前にチェックインした利用者であり、言い換えれば、チェックイン日時が「星野二郎」の予約来店時刻−1時間より前であるため、「星野二郎」より上位に表示している。また、チェックイン済み利用者の「野上太郎」は、「野村花子」の表示後にチェックインした利用者であり、言い換えれば、チェックイン日時が「野村花子」の予約来店時刻−1時間より後であるため、「野村花子」より下位に表示している。
図26は、図25の表示後、13時15分の購入者選択画面280の表示内容を示している。同図では、予約済み利用者のうち予約来店時刻が当日の12時15分〜14時15分の範囲にある「野村花子」は表示しているが、予約来店時刻から1時間以上が経過した「星野二郎」は非表示としている。チェックイン済み利用者の2名は、そのまま表示を継続している。
以上の構成による商品売買システム100の動作を説明する。以下では、第4の実施の形態において特徴的な動作を説明し、第1〜第3の実施の形態の説明で既述の動作の説明は適宜省略する。
利用者は、購入者端末10にて商品購入支援アプリケーションを起動し、来店予約機能を選択する。購入者端末10のサービス情報取得部38は来店予約画面に表示させるべきデータ、例えば予約型店舗に関するデータを売買支援サーバ14から取得する。購入者端末10の予約画面表示部250は、来店予約画面として、ログイン画面、サービス事業者選択画面、店舗選択画面を順次表示させた後、店舗選択画面で選択された店舗の詳細情報を示す店舗詳細画面を表示させる。
顔パス決済を希望する場合、利用者は、来店日時を所定のフィールドへ入力した上で、予約実行操作(例えば予約実行ボタンに対するタップ操作やフリック操作)を入力する。この予約実行操作により、利用者は指定した来店日時に店舗へ来店することを約束したこととなり、後述するように来訪対象店舗へ利用者の情報が通知される。予約実行操作が検出されると、購入者端末10の予約情報通知部252は、予約情報を売買支援サーバ14へ送信する。売買支援サーバ14の予約情報受付部260は、受け付けた予約情報を利用者予約情報として利用者情報保持部111へ格納する。
売買支援サーバ14の乱数取得部122は、予約情報が受け付けられたことを契機に新たな乱数列を取得して利用者予約情報に記録し、乱数提供部124は、その乱数列のデータを購入者端末10へ送信する。予約情報通知に対する応答として売買支援サーバ14から乱数列を受信すると、購入者端末10のワンタイムコード生成部42は、その乱数列にしたがって確認コードを生成する。予約画面表示部250は、店舗への来店予約が完了したことを示す予約完了画面を表示させ、その画面内に確認コードを表示させる。利用者は、予約実行操作に対する応答として表示された予約完了画面を見て、確認コードを認識し、予約来店時刻の近傍期間に店舗を訪れる。
また売買支援サーバ14の予約情報提供部262は、購入者端末10から予約情報が受け付けられると、利用者情報保持部111に格納された利用者登録情報および利用者予約情報にもとづいて店舗用予約情報を生成する。そして店舗用予約情報を店舗端末12へ送信する。店舗端末12の予約情報更新部272は、売買支援サーバ14から提供された店舗用予約情報を取得して予約情報保持部270へ格納する。
店舗販売員は、店舗端末12にて商品販売支援アプリケーションを起動し、売買支援サーバ14へのログインを完了する。店舗端末12の販売支援画面表示部66は、来店予約済み利用者とチェックイン済み利用者それぞれの顔写真および氏名のリストを含む購入者選択画面280を、ログイン後のトップ画面として典型的には常時表示させる。販売支援画面表示部66は、来店予約済み利用者については、現在時刻が予約来店時刻前後の所定期間内という条件を充足する利用者の情報のみ購入者選択画面280に表示させる。店舗販売員は、購入者選択画面280を見て、来店の可能性が高い顧客を認識し、個々の顧客に最適化したおもてなし、いわゆる個客対応の準備をする。
以降は、第1の実施の形態で説明と同様である。例えば、来店予約済み利用者またはチェックイン済み利用者が店舗へ来店し、購入する商品やサービスを決定して店舗販売員に氏名を申告すると、店舗販売員は、利用者の顔と氏名を確認して、顔と名前に整合する利用者画像を購入者選択画面280で選択する。店舗販売員は、メニュー選択画面で会計メニューを選択し、商品選択画面で利用者が購入する商品やサービスを選択し、会計画面で顔パス決済を選択する。店舗販売員は、確認コードの申告を利用者から受け付け、申告された確認コードを顔パス決済画面に入力し、決済処理の実行を指示する。店舗端末12は、確認コードおよび店舗IDを含む決済要求を売買支援サーバ14へ送信する。売買支援サーバ14は、購入者端末10から受け付けた予約情報にもとづいて、確認コードを照合するための情報と、店舗IDとを対応づけて保持しておく。売買支援サーバ14は、決済要求で指定された確認コードおよび店舗IDの組み合わせにもとづいて照合処理を実行し、その照合結果に応じて、商品またはサービス代金のクレジットカード決済を許可し、もしくは拒否する。許可した場合は、売買支援サーバ14は外部の決済サーバ16と連携してクレジットカード決済を実行する。
第4の実施の形態の商品売買システム100によると、第1〜第3の実施の形態の商品売買システム100により奏する効果に加えて以下の効果を奏する。
すなわち商品売買システム100は、利用者による来店予約を受け付ける予約型店舗の場合、購入者により来店予約がなされたことを契機に顔パス決済の準備処理を実行する。これにより、来店予約済み利用者の利便性を低下させてしまうことなく予約型店舗における顔パス決済を実現できる。言い換えれば、顔パス決済の適用範囲を予約型店舗に対しても好適に拡張できる。
すなわち商品売買システム100は、利用者による来店予約を受け付ける予約型店舗の場合、購入者により来店予約がなされたことを契機に顔パス決済の準備処理を実行する。これにより、来店予約済み利用者の利便性を低下させてしまうことなく予約型店舗における顔パス決済を実現できる。言い換えれば、顔パス決済の適用範囲を予約型店舗に対しても好適に拡張できる。
また商品売買システム100によると、店舗端末12の購入者選択画面280において来店予約済みの利用者情報の表示期間を、予約来店時刻を含む所定期間内に限定する。これにより、複数の来店予約済み利用者の中で、現在時点において来店する可能性が高い利用者のみを店舗販売員に提示しやすくなる。例えば、店舗販売員による個々の顧客に最適化したおもてなしの提供を支援でき、また、予約済み利用者が多数存在しても購入者選択画面280で容易に顔写真を選択できるよう支援できる。
以上、第4の実施の形態を説明した。この実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。以下変形例を示す。
第4の実施の形態に関する第1の変形例を説明する。
上記実施の形態では、利用者の予約情報が購入者端末10→売買支援サーバ14→店舗端末12と伝達されることとした。変形例として、利用者の予約情報は、店舗端末12から売買支援サーバ14へ伝達されてもよい。例えば、利用者が店舗に電話をして来店予約を行った場合、利用者が店舗のウェブサイトにアクセスして来店予約を行った場合、手紙や対面等のオフラインの手段により来店予約を行った場合等である。
上記実施の形態では、利用者の予約情報が購入者端末10→売買支援サーバ14→店舗端末12と伝達されることとした。変形例として、利用者の予約情報は、店舗端末12から売買支援サーバ14へ伝達されてもよい。例えば、利用者が店舗に電話をして来店予約を行った場合、利用者が店舗のウェブサイトにアクセスして来店予約を行った場合、手紙や対面等のオフラインの手段により来店予約を行った場合等である。
この変形例において、店舗端末12は、実施の形態の購入者端末10の予約情報通知部252に対応する予約情報取得部および予約情報通知部をさらに備える。予約情報取得部は、店舗の担当者が自端末に入力した利用者の予約情報を取得し、または、利用者の予約情報を店舗のウェブサーバやデータベースから取得して、予約情報保持部270に記録する。予約情報通知部は、予約情報取得部が取得した予約情報を売買支援サーバ14へ送信する。
この変形例においても、売買支援サーバ14の乱数提供部124は、利用者の確認コードの生成元となる乱数列を購入者端末10へ提供(プッシュ通知等)することにより、購入者端末10を介して利用者に確認コードを提示することが望ましい。店舗端末12の販売支援画面表示部66は、予約情報保持部270に予め格納された予約情報を使用して、購入者選択画面280に来店予約済みの利用者情報を表示させる。
第4の実施の形態に関する第2の変形例を説明する。
上記実施の形態では、店舗端末12の購入者選択画面280における予約済み利用者情報の表示開始および表示終了、言い換えれば、購入者選択画面280の内容の更新を店舗端末12自身で制御することとした。変形例として、購入者選択画面280における予約済み利用者情報の表示開始および表示終了を売買支援サーバ14が制御してもよい。
上記実施の形態では、店舗端末12の購入者選択画面280における予約済み利用者情報の表示開始および表示終了、言い換えれば、購入者選択画面280の内容の更新を店舗端末12自身で制御することとした。変形例として、購入者選択画面280における予約済み利用者情報の表示開始および表示終了を売買支援サーバ14が制御してもよい。
例えば、売買支援サーバ14は購入者情報表示指示部をさらに備えてもよい。購入者情報表示指示部は、予約済み利用者の予約来店時刻と現在時刻との関係を常時管理し、予約来店時刻まであと1時間となった予約済み利用者情報を購入者選択画面280に表示開始するよう指示する旨のデータを店舗端末12へ送信してもよい。また、予約来店時刻から1時間を経過した予約済み利用者情報を購入者選択画面280で非表示とするよう指示する旨のデータを店舗端末12へ送信してもよい。
別の態様として、第1の実施の形態の第4の変形例でも言及したように、売買支援サーバ14は、販売支援画面のウェブページのデータを自身で生成し、店舗端末12へ提供して表示させてもよい。この場合、売買支援サーバ14は、販売支援画面としての購入者選択画面280のコンテンツを、複数の予約済み利用者それぞれの予約来店時刻にもとづいて更新してもよい。具体的には、売買支援サーバ14は、複数の店舗端末12のそれぞれに表示させるべき予約済み利用者情報を現在時刻に応じて調整することにより、各店舗向けの購入者選択画面280のデータを逐次更新してもよい。そして、各店舗向けの最新の購入者選択画面280のデータを各店舗端末12へ提供してもよい。
上記の第1の変形例および第2の変形例に関連するが、利用者の来訪予約は公知のウェブを用いて登録されてもよい。例えば、店舗のウェブサーバもしくは売買支援サーバ14は、店舗(ホテルやレストラン等)への来店予約のための予約画面を示すウェブページを購入者端末10へ提供してもよい。利用者は、来店日時・来店人数等をウェブページへ入力して店舗のウェブサーバもしくは売買支援サーバ14へ送信することにより予約を完了する。ここで予約画面のウェブページでは支払方法として「顔パス」が選択可能である。利用者が顔パスを選択して予約操作を購入者端末10へ入力すると、既述の仕組みにより、店舗端末12は、予約来店時刻±1時間の期間、利用者の顔写真のリストである顔パス決済リストを表示する。
第4の実施の形態に関する第3の変形例を説明する。
上記実施の形態では、来店予約とチェックインの両方を受け付ける店舗において、来店予約済み利用者情報とチェックイン済み利用者情報の両方を購入者選択画面280の同じリスト内に混在させて表示した。しかし利用者情報の表示態様には種々の態様が考えられ、実施の形態の表示態様に限定されるものではない。例えば、来店予約済み利用者情報とチェックイン済み利用者情報を別のリストにおいて、それぞれ予約来店日時の昇順、チェックイン日時の昇順に並べて表示させてもよい。
上記実施の形態では、来店予約とチェックインの両方を受け付ける店舗において、来店予約済み利用者情報とチェックイン済み利用者情報の両方を購入者選択画面280の同じリスト内に混在させて表示した。しかし利用者情報の表示態様には種々の態様が考えられ、実施の形態の表示態様に限定されるものではない。例えば、来店予約済み利用者情報とチェックイン済み利用者情報を別のリストにおいて、それぞれ予約来店日時の昇順、チェックイン日時の昇順に並べて表示させてもよい。
また通常は、チェックインした利用者よりも来店予約した利用者の方が来店確度が高いと考えられる。そこで、来店予約済み利用者情報とチェックイン済み利用者情報の両方を購入者選択画面280の同じリスト内に表示する場合に、より視認性が高いと想定される位置、例えばリストの上位に来店予約済み利用者情報を表示させてもよい。言い換えれば、チェックイン済み利用者情報はチェックイン日時にかかわらず常にリストの下位に表示させてもよい。また、来店予約済み利用者情報とチェックイン済み利用者情報を別のリストで表示する場合にも、来店予約済み利用者のリストを、画面内で相対的に視認性が高いと想定される位置に、相対的に視認性が高い態様(サイズや色等)で表示させてもよい。
第4の実施の形態に関する第4の変形例を説明する。
上記実施の形態では、予約来店日時から所定期間を経過した利用者情報は購入者選択画面280において非表示とした。変形例として、販売支援画面表示部66は、予約来店日時から所定期間を経過した利用者情報の表示を継続させつつも、その表示位置を、購入者選択画面280内の別のリスト(いわば時間切れリスト)、または購入者選択画面280とは別の画面に切り替えてもよい。この変形例によると、予約来店時刻に店舗を訪れなかったものの、少なくとも来店予約を行った利用者を店舗販売員が識別することを容易にし、その利用者に対する対応を支援できる。なお、予約来店日時から所定期間が経過したことの検出日時が新しい利用者の情報ほど、視認性が相対的に高いと想定される位置もしくは態様で表示させることが望ましい。利用者が来訪する可能性は時間の経過とともに低くなると考えられるからである。
上記実施の形態では、予約来店日時から所定期間を経過した利用者情報は購入者選択画面280において非表示とした。変形例として、販売支援画面表示部66は、予約来店日時から所定期間を経過した利用者情報の表示を継続させつつも、その表示位置を、購入者選択画面280内の別のリスト(いわば時間切れリスト)、または購入者選択画面280とは別の画面に切り替えてもよい。この変形例によると、予約来店時刻に店舗を訪れなかったものの、少なくとも来店予約を行った利用者を店舗販売員が識別することを容易にし、その利用者に対する対応を支援できる。なお、予約来店日時から所定期間が経過したことの検出日時が新しい利用者の情報ほど、視認性が相対的に高いと想定される位置もしくは態様で表示させることが望ましい。利用者が来訪する可能性は時間の経過とともに低くなると考えられるからである。
第4の実施の形態に関する第5の変形例を説明する。
上記実施の形態では、店舗への来訪予約を契機とした顔パス決済の安全性向上のために、第1の実施の形態と同様に、利用者しか知り得ない確認コードを払い出した。変形例として、予約を受け付けた店舗が利用者へ予約番号を払い出してもよく、この予約番号が確認コードの代わりに使用されてもよい。店舗端末12(もしくは店舗のウェブサーバ)は、直接購入者端末10へ予約番号を通知し、もしくは、売買支援サーバ14を介して購入者端末10へ予約番号を通知してもよい。購入者端末10は、受け付けた予約番号を確認コードの代わりに表示してもよい。既述したように、予約画面のウェブページが購入者端末10へ提供される場合にも好適であり、顔パス決済を指定した予約登録への応答として、利用者へ予約番号を通知してもよい。
上記実施の形態では、店舗への来訪予約を契機とした顔パス決済の安全性向上のために、第1の実施の形態と同様に、利用者しか知り得ない確認コードを払い出した。変形例として、予約を受け付けた店舗が利用者へ予約番号を払い出してもよく、この予約番号が確認コードの代わりに使用されてもよい。店舗端末12(もしくは店舗のウェブサーバ)は、直接購入者端末10へ予約番号を通知し、もしくは、売買支援サーバ14を介して購入者端末10へ予約番号を通知してもよい。購入者端末10は、受け付けた予約番号を確認コードの代わりに表示してもよい。既述したように、予約画面のウェブページが購入者端末10へ提供される場合にも好適であり、顔パス決済を指定した予約登録への応答として、利用者へ予約番号を通知してもよい。
店舗端末12は、利用者の顔写真のリストとともに各利用者の予約番号を表示させてもよい。利用者が店舗で氏名と予約番号を申告すると、店舗販売員は、利用者の顔・氏名・予約番号が店舗端末12上のリストと整合すれば決済指示を入力してもよい。また、確認コードの場合と同様に、店舗販売員は、利用者の顔写真を選択するとともに予約番号を店舗端末12へ入力し、店舗端末12から売買支援サーバ14へ予約番号を含む決済要求を送信してもよい。売買支援サーバ14は、予約番号を事前に店舗装置から取得して利用者と対応づけて保持してもよく、この予め保持する予約番号と、決済要求で指定された予約番号との照合処理を実行してもよい。さらなる変形例として、確認コードと予約番号のいずれも使用せずに、顔写真と氏名のみを用いた顔パス決済が実行されてもよい。言い換えれば、チェックイン済みまたは予約済みの利用者の顔と氏名を店舗販売員が確認することをもって本人確認を完了させる顔パス決済が実行されてもよい。なお予約番号は、複数の利用者による複数の予約の中から、特定の利用者による特定の予約をユニークに識別可能な情報であればよく、数字・文字・記号等の任意の組み合わせでよい。
第4の実施の形態に関する第6の変形例を説明する。
第1から第4の実施の形態で提案した商品購入もしくはサービス受領のパターンは、利用者から見ると、1)来店予約またはチェックイン(来店宣言)、2)店舗での商品購入もしくはサービス受領、3)顔パス決済であった。ただし、本明細書に記載の技術思想はこのパターンに制限されず、他のパターンにも適用可能である。以下、2つの変形パターンを説明する。以下特に言及しない場合も、既述の仕組みにより、確認コードの払い出しや照合処理を各実施の形態と同様に実行してよいことはもちろんである。
第1から第4の実施の形態で提案した商品購入もしくはサービス受領のパターンは、利用者から見ると、1)来店予約またはチェックイン(来店宣言)、2)店舗での商品購入もしくはサービス受領、3)顔パス決済であった。ただし、本明細書に記載の技術思想はこのパターンに制限されず、他のパターンにも適用可能である。以下、2つの変形パターンを説明する。以下特に言及しない場合も、既述の仕組みにより、確認コードの払い出しや照合処理を各実施の形態と同様に実行してよいことはもちろんである。
変形パターン1:
1)来店予約および/またはチェックイン、2)顔パス決済(オーソリのみ)、3)商品購入もしくはサービス受領、4)顔パス決済(支払)のパターンである。ここでは、ホテル事業者への適用例を示す。
1)来店予約および/またはチェックイン、2)顔パス決済(オーソリのみ)、3)商品購入もしくはサービス受領、4)顔パス決済(支払)のパターンである。ここでは、ホテル事業者への適用例を示す。
利用者は、ウェブ予約画面または購入者端末10のアプリを介してホテルへ宿泊予約(例えば宿泊開始日および出発日の日付が指定される)を登録する。そして、宿泊開始日のホテル到着前に購入者端末10でチェックイン操作を入力し、来店宣言をする。これを、従来、宿泊開始日にホテルのフロントでフロントマンと宿泊客が対面して行ったチェックインに対応させる。例えば、ホテルのフロントマンやホテル端末は、購入者端末10でのチェックイン操作が売買支援サーバ14を介して通知されると、宿泊客が対面でチェックインした場合の一部の作業・処理を事前に人手もしくは自動で実行する。例えば、従来と同様の予約確認、クレジットカードオーソリ、部屋アサイン確認を実行してもよい。なお売買支援サーバ14は、宿泊予約を受け付けた際、もしくは、チェックインを受け付けた際に、宿泊客の顔写真を予約情報とともに店舗端末12(例えばホテルのフロントの端末)へ送信する。
利用者がホテルに到着したときには、予約確認、クレジットカードオーソリ、部屋アサイン確認は終了済みである。したがって、ホテルのフロントマンは、ホテル端末上のリストで利用者の顔と氏名を確認後、例えば部屋への案内、入室カードや朝食券の配布等、宿泊客との対面が前提となる作業のみを実施すればよい。これにより、利用者到着時の手続きを簡素化し、時間短縮を図ることができる。利用者がチェックアウトする際に、購入者端末10は、出発日付に該当する利用者の顔写真と名前をリスト表示し、以降、既述の仕組みにより顔パスによるクレジットカード決済を実行する。
変形パターン2:
1)来店予約および/またはチェックイン、2)顔パス決済、3)商品購入もしくはサービス受領、4)必要に応じて差分(差額)を支払うパターンである。ここでは、レンタカー会社への適用例を示す。
1)来店予約および/またはチェックイン、2)顔パス決済、3)商品購入もしくはサービス受領、4)必要に応じて差分(差額)を支払うパターンである。ここでは、レンタカー会社への適用例を示す。
利用者は、ウェブ予約画面または購入者端末10のアプリを介して、レンタカー予約(例えば利用開始日、利用終了日(返却日)が指定される)を登録する。そしてレンタカー営業所へ到着前に購入者端末10でチェックイン操作を入力し、来店宣言をする。このチェックイン操作はオプションであるが、レンタカー営業所の担当者は、購入者端末10でのチェックイン操作が売買支援サーバ14を介して通知されると、利用者到着時のレンタカー貸出までの時間を短縮するための作業を実施してもよい。例えば、チェックイン利用者用のレンタカーを店舗の正面に移動させ、また、チェックイン利用者用の貸出書類を用意する等の作業を利用者到着前に実施してもよい。利用者来店時に、担当者は、免許証を確認するとともに、既述の仕組みにより顔パスによるクレジットカード決済を店舗端末12を介して実行させる。
レンタカー返却時に、利用者は必要に応じて差分(例えばガソリン代やノンオペレーションチャージ)を支払う。この差分支払は、従前の方法でもよいが、顔パス決済を利用してもよい。この場合、購入者端末10は、返却日に該当する利用者の顔写真と名前をリスト表示し、既述の仕組みにより顔パス決済によるクレジットカード決済を実行する。なお、予約受付時もしくはチェックイン時に確認コードを払い出し、顔パス決済時にその照合処理を実行する場合、売買支援サーバ14は、レンタカー貸出時のクレジットカード決済後も、返却日までは確認コード(売買支援サーバ14が利用者と対応づけて保持する乱数値でもよい)を有効にしておくことが望ましい。これにより、利用者は、レンタカー利用開始時と同じ確認コードを返却時に申告すれば顔パス決済を利用でき、利用者の利便性を高めることができる。
(第5の実施の形態)
第5の実施の形態では、公知の音響通信技術を利用して自動チェックインを実現する商品売買システムを説明する。第1の実施の形態の第3の変形例では、GPS測位情報をもとに、購入者の現在位置の近傍に存在する店舗へ自動チェックインする構成を説明した。しかし、ショッピングモール等の建物内ではGPSによる測位が困難な場合がある。音響通信による自動チェックインはこの問題を解決する。また、店舗が密集していても特定の店舗への自動チェックインを可能にし、さらにまた、音量やスピーカーの指向性により音の到達範囲の制御が可能であるため、自動チェックインの地理的範囲の制御が容易であるという効果も奏する。
第5の実施の形態では、公知の音響通信技術を利用して自動チェックインを実現する商品売買システムを説明する。第1の実施の形態の第3の変形例では、GPS測位情報をもとに、購入者の現在位置の近傍に存在する店舗へ自動チェックインする構成を説明した。しかし、ショッピングモール等の建物内ではGPSによる測位が困難な場合がある。音響通信による自動チェックインはこの問題を解決する。また、店舗が密集していても特定の店舗への自動チェックインを可能にし、さらにまた、音量やスピーカーの指向性により音の到達範囲の制御が可能であるため、自動チェックインの地理的範囲の制御が容易であるという効果も奏する。
第5の実施の形態の商品売買システム100の構成は、第1の実施の形態の商品売買システム100(図1)と同様であるが、音響出力装置と変換サーバをさらに備える。音響出力装置はスピーカーを含み、そのスピーカーは屋内外の任意の位置、例えばエレベータホールやエスカレーターの昇降口、商店街の入口等に設置される。変換サーバは、通信網を介して購入者端末10と接続される。変換サーバは、売買支援サーバ14と同一のサーバとして実装されてもよい。
音響出力装置は、スピーカーを介して、自動チェックインのための情報を変換サーバから取得するために必要なデジタル情報(ここでは「音響ID」と呼ぶ。)が、人間には聞こえにくい高音域に変調された音響信号を出力する。音響IDは、例えば、自動チェックイン先となる店舗の識別情報と変換サーバのアドレスを含む。音響IDの変調には公知の変調技術が使用されればよい。
変換サーバは、音響IDに含まれる店舗識別情報と、顔パス決済サービスにおいて店舗をユニークに識別するためのサービス事業者IDおよび店舗IDを対応づけて保持する。変換サーバは、購入者端末10から店舗識別情報を受け付けると、その店舗識別情報に対応づけられたサービス事業者IDおよび店舗IDを購入者端末10へ送信する。
第5の実施の形態の購入者端末10は、マイクと音響解析部をさらに備える。音響解析部は、マイクにより検出された音響信号を復調し、音に含まれるデジタル情報である音響IDを取得する。この復調処理には公知の復調技術が使用されればよい。音響解析部は、音響IDが示す変換サーバへ、音響IDが示す店舗識別情報を送信し、変換サーバからの応答として、サービス事業者IDおよび店舗IDを取得する。そして、これらの情報をチェックイン通知部40に渡す。チェックイン通知部40は、音響解析部が出力したサービス事業者IDおよび店舗IDを指定したチェックイン情報を売買支援サーバ14へ送信する。以降、利用者が手作業でチェックイン操作を行った場合と同様に、顔パス決済の一連の処理が実行される。
なお、自動チェックインのために必要な情報、例えばサービス事業者IDおよび店舗IDが、音響IDのデータ容量に収まるサイズであれば、音響ID自体がこれらの情報を含んでもよい。この場合、購入者端末10から変換サーバへのアクセスは不要であり、音響解析部は、音響IDが直接的に示すサービス事業者IDおよび店舗IDをチェックイン通知部40に渡してもよい。
また、GPSや音響通信にもとづいて自動チェックインを行う場合は、確認コードの発行および照合に関する処理をスキップしてもよい。例えば、購入者端末10のチェックイン通知部40は、音響解析部が出力したサービス事業者IDおよび店舗IDを指定したチェックイン情報に、自動チェックインを示すフラグを設定して売買支援サーバ14へ送信してもよい。また、購入者端末10のワンタイムコード生成部42は、確認コードの発行をスキップしてもよい。また、上記フラグを検出した売買支援サーバ14は、乱数列の発行処理および確認コードの整合判定処理をスキップしてもよい。商品売買システム100の管理者や店舗の権限者は、利用者の利便性と顔パス決済の安全性を比較考量して、自動チェックインの場合の、確認コードの発行・照合の要否を決定してもよい。
上述した実施の形態および変形例の任意の組み合わせもまた本発明の実施の形態として有用である。例えば、第1の実施の形態についての変形例は、第2の実施の形態、および第2の実施の形態の任意の変形例と組み合わせることができる。第3〜第5の実施の形態との任意の組み合わせももちろん可能である。組み合わせによって生じる新たな実施の形態は、組み合わされる実施の形態および変形例それぞれの効果をあわせもつ。また、請求項に記載の各構成要件が果たすべき機能は、第1〜第5の実施の形態およびそれらの変形例で示された各構成要素の単体もしくはそれらの連係によって実現されることも当業者には理解されるところである。
10 購入者端末、 12 店舗端末、 14 売買支援サーバ、 36 購入支援画面表示部、 42 ワンタイムコード生成部、 66 販売支援画面表示部、 74 決済要求通知部、 100 商品売買システム、 132 決済処理部、 250 予約画面表示部、 252 予約情報通知部、 260 予約情報受付部、 262 予約情報提供部、 270 予約情報保持部、 272 予約情報更新部。
Claims (9)
- 商品またはサービスの販売者の端末と、
通信網を介して前記販売者の端末と接続されるサーバと、
を備え、
前記サーバは、
販売者の店舗への購入者の来訪予約を示す予約情報を、前記販売者の端末または購入者の端末から取得する予約情報取得部と、
前記予約情報が取得された場合に、販売者の店舗への来訪予約を行った購入者の外見を示す画像を前記販売者の端末へ提供する購入者画像提供部と、を含み、
前記販売者の端末は、
販売者の店舗にて購入者が商品またはサービスを購入する際に購入者の画像を販売者に選択させるための選択画面を表示させる選択画面表示部と、
前記選択画面において選択された購入者を指定した決済要求を前記サーバへ通知する決済要求通知部と、を含み、
前記サーバは、
購入者が商品またはサービスの代金を電子決済するために必要な情報である決済情報を保持する決済情報保持部と、
前記販売者の端末から通知された決済要求で指定された購入者の決済情報を使用して、商品またはサービスの代金の電子決済を実行させる決済処理部と、をさらに含むことを特徴とする情報処理システム。 - 前記予約情報は、販売者の店舗への購入者の来訪時刻を含むものであり、
前記販売者の端末の選択画面表示部は、自装置で予め保持する購入者の来訪時刻に関する情報または前記サーバから通知された購入者の来訪時刻に関する情報にしたがって、その来訪時刻を含む所定期間内に購入者の画像を前記選択画面に表示させることを特徴とする請求項1に記載の情報処理システム。 - 商品またはサービスの購入者の端末をさらに備え、
前記購入者の端末は、販売者の店舗への来訪予定を示す所定のチェックイン操作を購入者から受け付ける受付部を含み、
前記サーバの購入者画像提供部は、前記購入者の端末において前記チェックイン操作がなされた場合に、チェックイン操作を行った購入者の外見を示す画像を前記販売者の端末へ提供し、
前記販売者の端末の選択画面表示部は、販売者の店舗への来訪を予約した第1の購入者の画像と、チェックイン操作を行った第2の購入者の画像の両方を前記選択画面に表示させることを特徴とする請求項1に記載の情報処理システム。 - 商品またはサービスの販売者の端末と通信網を介して接続されるサーバであって、
購入者が商品またはサービスの代金を電子決済するために必要な情報である決済情報を保持する決済情報保持部と、
販売者の店舗への購入者の来訪予約を示す予約情報を、前記販売者の端末または購入者の端末から取得する予約情報取得部と、
前記予約情報が取得された場合に、販売者の店舗への来訪予約を行った購入者の外見を示す画像を前記販売者の端末へ提供することにより、販売者の店舗にて購入者が商品またはサービスを購入する際に購入者の画像を販売者に選択させるための選択画面を前記販売者の端末に表示させる購入者画像提供部と、
前記販売者の端末において販売者が選択した購入者の画像に対応する購入者の情報を指定した決済要求を前記販売者の端末から受け付ける決済要求受付部と、
前記販売者の端末から通知された決済要求で指定された購入者の決済情報を使用して、商品またはサービスの代金の電子決済を実行させる決済処理部と、
を備えることを特徴とする売買支援サーバ。 - 前記予約情報は、販売者の店舗への購入者の来訪時刻を含むものであり、
前記予約情報が取得された場合に、販売者の店舗への購入者の来訪時刻に関する情報を前記販売者の端末へ通知することにより、購入者の来訪時刻を含む所定期間内に、前記販売者の端末の選択画面に購入者の画像を表示させる来訪時刻通知部をさらに備えることを特徴とする請求項4に記載の売買支援サーバ。 - 商品またはサービスの販売者の端末であって、
サーバが、販売者の店舗への購入者の来訪予約を示す予約情報を、当該販売者の端末または購入者の端末から取得した場合に、前記サーバから提供された販売者の店舗への来訪予約を行った購入者の外見を示す画像を取得する購入者画像取得部と、
販売者の店舗にて購入者が商品またはサービスを購入する際に購入者の画像を販売者に選択させるための選択画面を表示させる選択画面表示部と、
前記選択画面において選択された購入者を指定した決済要求を前記サーバへ通知することにより、その購入者の情報を使用した商品またはサービスの代金の電子決済を前記サーバに実行させる決済要求通知部と、
を備えることを特徴とする販売者端末。 - 前記予約情報は、販売者の店舗への購入者の来訪時刻を含むものであり、
前記選択画面表示部は、自装置で予め保持する購入者の来訪時刻に関する情報または前記サーバから通知された購入者の来訪時刻に関する情報にしたがって、その来訪時刻を含む所定期間内に購入者の画像を前記選択画面に表示させることを特徴とする請求項6に記載の販売者端末。 - 商品またはサービスの購入者の端末であって、
商品またはサービスの販売者の店舗への来訪を予約するための所定の操作入力を購入者から受け付ける受付部と、
前記所定の操作入力が受け付けられた場合に、販売者の店舗への購入者の来訪予約を示す予約情報をサーバへ通知することにより、前記サーバに、購入者へ通知すべき第1の照合情報を特定可能な第2の照合情報を、購入者に対応づけて記録させるとともに、購入者の外見を示す画像を販売者の端末へ提供させ、前記販売者の端末において、販売者の店舗にて購入者が商品またはサービスを購入する際に購入者の画像を販売者に選択させるための選択画面に購入者の画像を表示させる予約情報通知部と、
購入者が販売者の店舗にて商品を購入する際に、前記販売者の端末に、販売者が選択した購入者画像に対応する購入者の情報と、前記販売者の端末が購入者から取得した第1の照合情報とを指定した決済要求を前記サーバへ通知させ、前記サーバに、前記決済要求で指定された第1の照合情報に対応づけて前記サーバが記録していた第2の照合情報との整合有無にもとづいて商品またはサービスの代金の電子決済の許否を判定させるために、購入者による前記所定の操作入力への応答として、新たに生成された第1の照合情報を画面に表示させることにより、前記第1の照合情報を購入者へ通知する照合情報通知部と、
を備えることを特徴とする購入者端末。 - 前記予約情報は、販売者の店舗への購入者の来訪時刻を含むものであり、
前記予約情報通知部は、前記予約情報をサーバへ通知することにより、購入者の外見を示す画像と購入者の来訪時刻に関する情報を販売者の端末へ提供させ、前記販売者の端末の前記選択画面に、購入者の来訪時刻を含む所定期間内に購入者の画像を表示させることを特徴とする請求項8に記載の購入者端末。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2013179485A JP2015049589A (ja) | 2013-08-30 | 2013-08-30 | 情報処理システム、売買支援サーバ、販売者端末および購入者端末 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2013179485A JP2015049589A (ja) | 2013-08-30 | 2013-08-30 | 情報処理システム、売買支援サーバ、販売者端末および購入者端末 |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2015049589A true JP2015049589A (ja) | 2015-03-16 |
Family
ID=52699588
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2013179485A Pending JP2015049589A (ja) | 2013-08-30 | 2013-08-30 | 情報処理システム、売買支援サーバ、販売者端末および購入者端末 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2015049589A (ja) |
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2017123023A (ja) * | 2016-01-06 | 2017-07-13 | 株式会社リクルートホールディングス | 順番管理システム、表示端末および表示プログラム |
JP2017167656A (ja) * | 2016-03-14 | 2017-09-21 | 株式会社リクルートホールディングス | 順番管理システム、順番管理装置および順番管理プログラム |
JP2019061472A (ja) * | 2017-09-26 | 2019-04-18 | 株式会社日本総合研究所 | コンピュータプログラム及び決済方法 |
JP2019525283A (ja) * | 2016-07-06 | 2019-09-05 | アリババ・グループ・ホールディング・リミテッドAlibaba Group Holding Limited | 異種のコンピュータ処理装置を標準インタフェース及び直接ネットワーク接続を介して接続するためのシステム及び方法 |
JP7136505B1 (ja) | 2021-08-19 | 2022-09-13 | 株式会社スマートホテルソリューションズ | 決済管理装置、決済管理システムおよび決済管理方法 |
JP2022157748A (ja) * | 2021-03-31 | 2022-10-14 | PayPay株式会社 | 情報処理装置、情報処理方法、および情報処理プログラム |
JP7374359B1 (ja) * | 2023-01-24 | 2023-11-06 | PayPay株式会社 | アプリケーションプログラム、決済サーバ、および端末装置の制御方法 |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2002149600A (ja) * | 2000-11-08 | 2002-05-24 | Sony Corp | 情報処理装置および方法、記録媒体、並びにサービス提供システム |
JP2002269479A (ja) * | 2001-03-09 | 2002-09-20 | Sony Corp | 情報処理装置および方法、記録媒体、並びにプログラム |
JP2006050466A (ja) * | 2004-08-06 | 2006-02-16 | Sharp Corp | ユーザ認証システム、該システムの認証方法、ユーザ認証プログラム、および該プログラムを記録した記録媒体 |
JP2012215918A (ja) * | 2011-03-31 | 2012-11-08 | Japan Research Institute Ltd | ハウスカード決済システム、ハウスカード決済方法 |
-
2013
- 2013-08-30 JP JP2013179485A patent/JP2015049589A/ja active Pending
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2002149600A (ja) * | 2000-11-08 | 2002-05-24 | Sony Corp | 情報処理装置および方法、記録媒体、並びにサービス提供システム |
JP2002269479A (ja) * | 2001-03-09 | 2002-09-20 | Sony Corp | 情報処理装置および方法、記録媒体、並びにプログラム |
JP2006050466A (ja) * | 2004-08-06 | 2006-02-16 | Sharp Corp | ユーザ認証システム、該システムの認証方法、ユーザ認証プログラム、および該プログラムを記録した記録媒体 |
JP2012215918A (ja) * | 2011-03-31 | 2012-11-08 | Japan Research Institute Ltd | ハウスカード決済システム、ハウスカード決済方法 |
Non-Patent Citations (2)
Title |
---|
"スマホで簡単にカード決済ができる「PayPal Here」、7月に本格導入", [ONLINE], JPN6013014733, 9 May 2012 (2012-05-09), ISSN: 0003751720 * |
"ソフトバンクとPayPal、合弁会社を設立", [ONLINE], JPN6013014735, 9 May 2012 (2012-05-09), ISSN: 0003751721 * |
Cited By (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2017123023A (ja) * | 2016-01-06 | 2017-07-13 | 株式会社リクルートホールディングス | 順番管理システム、表示端末および表示プログラム |
JP2017167656A (ja) * | 2016-03-14 | 2017-09-21 | 株式会社リクルートホールディングス | 順番管理システム、順番管理装置および順番管理プログラム |
JP2019525283A (ja) * | 2016-07-06 | 2019-09-05 | アリババ・グループ・ホールディング・リミテッドAlibaba Group Holding Limited | 異種のコンピュータ処理装置を標準インタフェース及び直接ネットワーク接続を介して接続するためのシステム及び方法 |
JP2019061472A (ja) * | 2017-09-26 | 2019-04-18 | 株式会社日本総合研究所 | コンピュータプログラム及び決済方法 |
JP2022157748A (ja) * | 2021-03-31 | 2022-10-14 | PayPay株式会社 | 情報処理装置、情報処理方法、および情報処理プログラム |
JP7136505B1 (ja) | 2021-08-19 | 2022-09-13 | 株式会社スマートホテルソリューションズ | 決済管理装置、決済管理システムおよび決済管理方法 |
JP2023029167A (ja) * | 2021-08-19 | 2023-03-03 | 株式会社スマートホテルソリューションズ | 決済管理装置、決済管理システムおよび決済管理方法 |
JP7374359B1 (ja) * | 2023-01-24 | 2023-11-06 | PayPay株式会社 | アプリケーションプログラム、決済サーバ、および端末装置の制御方法 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9723131B1 (en) | Mobile device security | |
JP5872083B2 (ja) | 効率的な取引のためのユーザプロファイルおよび地理的位置 | |
JP5347076B1 (ja) | 情報処理システムおよび情報処理方法 | |
US9324091B2 (en) | Location based mobile user selected time, location, and number limited automatic location based reserve and redeem discounts on products or services with automatic security and feedback features | |
JP2015075947A (ja) | 情報処理システム、売買支援サーバ、販売者端末および購入者端末 | |
US20230153706A1 (en) | Customer transaction system | |
US20090055269A1 (en) | Methods and Systems for Preauthorizing Venue-Based Credit Accounts | |
EP3667592A1 (en) | System and method for managing merchant-consumer interactions | |
JP2015049589A (ja) | 情報処理システム、売買支援サーバ、販売者端末および購入者端末 | |
JP5352730B1 (ja) | 情報処理システム、情報処理方法、商品販売者端末、販売支援方法、売買支援サーバ、売買支援方法、商品購入者端末、購入支援方法およびコンピュータプログラム | |
JP5758173B2 (ja) | ハウスカード決済システム、ハウスカード決済方法 | |
WO2017027235A1 (en) | Methods, systems, and apparatuses for payment fulfillment | |
JP2014203216A (ja) | 決済用端末装置 | |
JP2014203215A (ja) | 決済支援サーバ、決済支援方法、決済支援システム及びコンピュータプログラム | |
JP2014099156A (ja) | 情報処理システム | |
JP2012145983A (ja) | アフィリエイト管理システム、及びアフィリエイトサーバー | |
KR20200041248A (ko) | Sns를 이용한 예약 및 결제 시스템 및 그 방법 | |
JP2014179059A (ja) | 情報処理システム | |
US20220318884A1 (en) | Electronic payment system, electronic payment method, and information storage medium | |
JP6677371B2 (ja) | 時間を単位とする販促ポイントの流通方法及び流通管理システム | |
US20140095356A1 (en) | Enhanced Microgift System and Method of Operation |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20160701 |
|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20170724 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20170808 |
|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20180306 |