JP2014203216A - 決済用端末装置 - Google Patents

Abstract

【課題】利用者の決済に係る顔写真画像を評価する。
【解決手段】利用者の顔写真画像を含む利用者情報を保持する記憶部と、複数の利用者の中から選択された一の利用者の顔写真画像を表示する顔写真表示領域と、一の利用者の顔写真画像に対する応答を受け付ける応答入力領域と、顔写真表示領域に表示されている顔写真画像に係る利用者に関する決済の指示を受け付ける決済指示領域と、を含む決済用ＧＵＩを表示する表示部と、応答入力領域が受け付けた応答及び決済指示領域が受け付けた決済の指示に応じた出力をする出力部と、を有する。
【選択図】図２０

Description

本発明は、決済用端末装置の技術に関する。

スマートフォンやタブレット端末の急速な普及は、決済の分野においても大きな影響を与えている。近年、スマートフォンやタブレット端末をクレジットカード決済端末へ応用するソリューションも登場してきている。

また同様の端末を活用して、ユーザの「顔（写真）」と「名前」を利用したクレジットカード決済サービスも登場してきている。このサービスでは、ユーザの端末にて実在する店舗を指定する操作を行なうと、ユーザの情報が店舗側へ通知され、ユーザの顔写真と名前が店舗端末に表示される。その後、ユーザが実際に来店して商品を購入する際に、ユーザの「顔」と「名前」の確認をもって決済を完了させるという手法である。

ソフトバンク株式会社、ＰａｙＰａｌ、"ソフトバンクとペイパルが合弁会社を設立 〜グローバルモバイル決済ソリューション「ＰａｙＰａｌ Ｈｅｒｅ」を発表 中小規模事業者における、クレジットカードやデビットカード、ＰａｙＰａｌによる決済を実現〜"、［ｏｎｌｉｎｅ］、［平成２４年１０月２３日検索］、インターネット＜ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．ｓｏｆｔｂａｎｋ．ｃｏ．ｊｐ／ｊａ／ｎｅｗｓ／ｐｒｅｓｓ／２０１２／２０１２０５０９＿０１／＞

上記の手法では、店舗の販売員（店員）が、ユーザの外見およびユーザが申告した名前を、店舗側に通知された顔写真および名前と比較することをもって本人確認を行なう。

ここで、顔写真が本人を識別するために十分な品質（有効性）を有していないと、店員は正しく本人確認を行えない。しかし、例えば、顔画像認識技術を活用して、顔写真が本人を識別するために十分な品質を有しているか否かを判断することは、精度及びコストの面で難しい場合もある。

本発明は上記課題を鑑みてなされたものであり、その主な目的は、顔写真を活用した決済手法の支援技術を提供することにある。

本発明の一実施形態に係る決済用端末装置は、
利用者の顔写真画像を含む利用者情報を保持する記憶部と、
複数の利用者の中から選択された一の利用者の顔写真画像を表示する顔写真表示領域と、一の利用者の顔写真画像に対する応答を受け付ける応答入力領域と、顔写真表示領域に表示されている顔写真画像に係る利用者に関する決済の指示を受け付ける決済指示領域と、を含む決済用ＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）を表示する表示部と、
応答入力領域が受け付けた応答、及び前記決済指示領域が受け付けた決済の指示に応じた出力をする出力部と、を有する。

本発明によれば、人間（店員等）の判断を利用して顔写真の品質を簡便に判定することができる。

第１の実施形態に係る商品売買システムの構成を示す図である。 図１の購入者端末の機能構成を示すブロック図である。 図１の店舗端末の機能構成を示すブロック図である。 店舗用チェックイン情報の構成を示す図である。 図１の売買支援サーバの構成を示すブロック図である。 図６（ａ）は利用者登録情報の構成を示し、図６（ｂ）は利用者チェックイン情報の構成を示す図である。 店舗詳細画面を示す図である。 チェックイン画面を示す図である。 商品選択画面を示す図である。 会計画面を示す図である。 顔パス決済画面を示す図である。 第２の実施形態に係る売買支援サーバの機能構成を示すブロック図である。 利用者情報保持部が記録する情報を示す。 決済履歴情報保持部が記録する情報を示す。 顔写真有効度を算出する処理のフローチャートの一例を示す。 顔パス決済判定部の処理のフローチャートの一例を示す。 顔パス決済判定部の判断及びアクションの表を示す。 第２の実施形態に係る店舗端末の機能構成を示すブロック図である。 チェックイン情報保持部の記憶する情報と、決済要求情報とを示す。 顔パス決済用ＧＵＩの一例を示す。

（第１の実施形態）
本実施の形態では、「顔（写真）」と「名前」を利用した決済手法（以下、「顔パス決済」とも呼ぶ。）は維持しつつ、ワンタイムのコード（言わばワンタイムパスワード）を用いた本人確認を付加した商品売買システムを提案する。このシステムによると、顔パス決済による決済の簡便性・利便性は維持しつつ、本人確認の精度を向上させ、また、利用者側および店舗側の不正を抑制することができる。

図１は、実施の形態の商品売買システム１００の構成を示す。商品売買システム１００は、購入者端末１０で総称される購入者端末１０ａ、購入者端末１０ｂ、購入者端末１０ｃと、店舗端末１２で総称される店舗端末１２ａ、店舗端末１２ｂ、店舗端末１２ｃと、売買支援サーバ１４と、決済サーバ１６を備える。図１の各装置は、ＬＡＮ・ＷＡＮ・インターネット等を含む無線および有線の通信網を介して接続される。

購入者端末１０ａ〜１０ｃは、商品を購入する立場のユーザであり、商品購入時に顔パス決済を利用する複数のユーザ（以下、「利用者」と呼ぶ。）がそれぞれ保持する情報処理端末である。購入者端末１０は、好適には利用者が移動時に携帯する携帯情報端末であり、例えばスマートフォンである。変形例として、利用者宅に設置された据置型のＰＣであってもよい。

店舗端末１２ａ〜１２ｃは、現実世界に実在する複数の店舗のそれぞれに設置され、各店舗の販売員（従業員）により操作される情報処理端末である。本実施の形態の店舗端末１２はタブレット端末（タブレットコンピュータ）であることとする。店舗端末１２には、商品販売に係る会計処理や決済処理を実行するためのアプリケーション、言わばレジ機能を実現するためのアプリケーションがインストールされている。

売買支援サーバ１４は、通信網を介して購入者端末１０、店舗端末１２、決済サーバ１６とデータを送受する情報処理装置である。売買支援サーバ１４は、利用者が店舗へ実際に来店して商品を購入する行為を支援する利用者向けサービス、および、店舗にて商品を販売する行為を支援するための店舗向けサービスを提供する。

決済サーバ１６は、クレジットカード会社や銀行等の金融機関に設置された情報処理装置であり、売買支援サーバ１４からの決済指示にしたがって電子決済処理を実行する。本実施の形態ではクレジットカード決済を実行する。

次に、購入者端末１０、店舗端末１２、売買支援サーバ１４の構成を詳細に説明する。
図２は、図１の購入者端末１０の機能構成を示すブロック図である。購入者端末１０は、タッチパネル２０と制御部２４を備える。制御部２４は、操作検出部２６と、表示制御部２８と、通信処理部３０と、商品購入支援部３２を含む。

本明細書のブロック図で示す各ブロックは、ハードウェア的には、コンピュータのＣＰＵやメモリをはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウェア、ソフトウェアの組合せによっていろいろなかたちで実現できることは、当業者には理解されるところである。以降のブロック図についても同様である。

例えば、制御部２４内の各機能ブロックに対応するプログラムモジュールが購入者端末１０のフラッシュメモリ等のストレージに格納され、購入者端末１０のＣＰＵがそれらのプログラムモジュールをメインメモリへ読み出して実行することにより制御部２４の機能が実現されてもよい。また、制御部２４は、ストレージやメインメモリ等の記憶領域へ各種データを記憶させ、そのデータを参照して各機能ブロックに係るデータ処理を実行してもよい。また、商品購入支援部３２に対応するアプリケーションソフトウェアが、記録メディアもしくはダウンロード形式にて配布され、購入者端末１０にインストールされてもよい。

タッチパネル２０は、入力装置（例えばタッチパッド）と一体形成された表示装置（例えば液晶パネル）である。操作検出部２６はタッチパネルドライバとしての機能を提供し、例えば、タッチパネル２０に対する利用者の操作入力を検出し、その操作内容を商品購入支援部３２に渡す。表示制御部２８もタッチパネルドライバとしての機能を提供し、例えば、商品購入支援部３２から渡されたテキストデータや画像データをタッチパネル２０に表示させる。

通信処理部３０は外部装置との無線通信を制御する。実施の形態において、通信処理部３０は、商品購入支援部３２から渡されたデータを売買支援サーバ１４へ送信する。また、売買支援サーバ１４から送信されたデータを受信して、そのデータを商品購入支援部３２へ渡す。

商品購入支援部３２は、商品購入支援アプリケーション、具体的には、顔パス決済サービスを利用するための利用者側アプリケーションの機能を提供する。商品購入支援部３２は、利用者情報登録部３４と、購入支援画面表示部３６と、サービス情報取得部３８と、チェックイン通知部４０と、ワンタイムコード生成部４２を含む。

利用者情報登録部３４は、顔パス決済を利用するために必要な利用者に関する属性情報を売買支援サーバ１４へ登録する。この属性情報には、利用者ＩＤ、利用者の氏名、顔写真、クレジットカード決済に必要なクレジットカード情報（例えばクレジットカード種類、カード番号、生年月日、有効期限等）が含まれる。利用者情報登録部３４は、利用者に自身の属性情報を入力させるための登録画面をタッチパネル２０に表示させてもよい。

購入支援画面表示部３６は、顔パス決済サービスにおける利用者用の画面（以下、「商品購入支援画面」とも呼ぶ。）をタッチパネル２０に表示させる。商品購入支援画面には、（１）初期画面としての売買支援サーバ１４へのログイン画面、（２）顔パス決済サービスを提供するサービス事業者（ブランド）の選択画面、（３）サービス事業者が運営する店舗の選択画面、（４）店舗の詳細情報を表示する店舗詳細画面、（５）店舗にチェックインした場合のチェックイン画面が含まれる。購入支援画面表示部３６は、これら複数種類の商品購入支援画面を、利用者の操作に応じて順次切り替えて表示させる。

サービス情報取得部３８は、複数種類の商品購入支援画面のそれぞれに表示させるべき情報を売買支援サーバ１４から取得する。例えば、（２）サービス事業者選択画面用の情報として、サービス事業者やブランドのＩＤ、名称、ロゴ、説明文等を取得する。また、（３）店舗選択画面および（４）店舗詳細画面用の情報として、サービス事業者が運営する複数の店舗それぞれの店舗ＩＤ、店舗名、営業時間、住所等を取得する。サービス情報取得部３８は、これらのサービス事業者情報や店舗情報を売買支援サーバ１４から定期的に取得して所定の記憶領域へ格納してもよく、商品購入支援画面が表示される際に売買支援サーバ１４から取得してもよい。

操作検出部２６は、（４）店舗詳細画面において、詳細情報を表示中の店舗に対して利用者がチェックインすることを示す所定操作（以下、「チェックイン操作」とも呼ぶ。）がなされたことを検出する。本実施の形態において「チェックイン」は、特定の店舗への来訪を利用者が予定したこと、言い換えれば、未確定であるが特定の店舗への来訪を利用者が企図したこととして位置づけられる。チェックイン通知部４０は、チェックイン操作が検出された場合に、その旨を示すチェックイン情報を売買支援サーバ１４へ送信する。このチェックイン情報には、利用者ＩＤと、チェックイン対象のサービス事業者ＩＤおよび店舗ＩＤが含まれる。

ワンタイムコード生成部４２は、チェックイン情報の通知に対する応答として売買支援サーバ１４から送信された乱数列を取得する。ワンタイムコード生成部４２は、予め定められた確認コード生成関数に、売買支援サーバ１４から取得した乱数列を入力し、その乱数列にもとづく確認コードを生成する。この確認コードは、今回のチェックインに限り一時的に有効な照合情報であり、いわゆるワンタイムパスワードである。本実施の形態では、確認コードが４桁の数字列（００００〜９９９９）であることとする。購入支援画面表示部３６は、ワンタイムコード生成部４２が生成した確認コードを（５）チェックイン画面において表示させる。なお購入者端末１０は、画面表示以外の方法で確認コードを利用者へ通知してもよく、例えば確認コードを音声出力してもよい。

図３は、図１の店舗端末１２の機能構成を示すブロック図である。店舗端末１２は、タッチパネル５０とチェックイン情報保持部５４と制御部５６を備える。制御部５６は、操作検出部５８と、表示制御部６０と、通信処理部６２と、商品販売支援部６４を含む。

一部既述したが、制御部５６内の各機能ブロックに対応するプログラムモジュールが店舗端末１２のフラッシュメモリ等のストレージに格納され、店舗端末１２のＣＰＵがそれらのプログラムモジュールをメインメモリへ読み出して実行することにより制御部５６の機能が実現されてもよい。また、制御部５６は、ストレージやメインメモリ等の記憶装置へ各種データを記憶させ、そのデータを参照して各機能ブロックに係るデータ処理を実行してもよい。また、商品販売支援部６４に対応するアプリケーションソフトウェアが記録メディアもしくはダウンロード形式にて配布され、店舗端末１２にインストールされてもよい。また、チェックイン情報保持部５４の機能は、店舗端末１２のストレージやメインメモリ等の記憶装置により実現されてもよい。

タッチパネル５０、操作検出部５８、表示制御部６０、通信処理部６２の機能は、購入者端末１０のタッチパネル２０、操作検出部２６、表示制御部２８、通信処理部３０の機能と同じであるため説明を省略する。

チェックイン情報保持部５４は、自店舗に対してチェックインした利用者、すなわち自店舗へ来店予定の利用者に関する属性情報（以下では「店舗用チェックイン情報」とも呼ぶ。）を保持する。図４は、店舗用チェックイン情報の構成を示す。店舗用チェックイン情報には、利用者のＩＤ、氏名、顔写真画像、クレジットカード情報（一部）が含まれる。このクレジットカード情報は、売買支援サーバ１４に登録された利用者のクレジットカード情報を、店舗販売員に開示可能な範囲に限定したものであり、例えばクレジットカードの種類と有効期限であってもよい。

図３に戻り、商品販売支援部６４は、商品販売支援アプリケーション、具体的には、顔パス決済サービスを利用するための店舗側アプリケーションの機能を提供する。商品販売支援部６４は、販売支援画面表示部６６と、商品情報取得部６８と、チェックイン情報更新部７０と、ワンタイムコード取得部７２と、決済要求通知部７４と、結果取得部７６を含む。

販売支援画面表示部６６は、顔パス決済サービスにおける店舗用の画面（以下、「商品販売支援画面」とも呼ぶ。）をタッチパネル５０に表示させる。商品販売支援画面には、（１）初期画面としてのメニュー選択画面（会計メニューや管理メニュー等）、（２）利用者の購入商品を選択する商品選択画面、（３）決済手段を選択するための会計画面、（４）顔パス決済を行なうための顔パス決済画面、（５）決済の結果を示す決済結果画面が含まれる。販売支援画面表示部６６は、これら複数種類の商品販売支援画面を、店舗販売員の操作に応じて順次切り替えて表示させる。

商品情報取得部６８は、商品販売支援画面の（２）商品選択画面に表示させるべき商品情報を売買支援サーバ１４から取得する。この商品情報には、商品名、商品画像、販売価格が含まれる。商品情報取得部６８は、商品情報を売買支援サーバ１４から定期的に取得して所定の記憶領域へ格納してもよく、商品選択画面が表示される際に売買支援サーバ１４から取得してもよい。

チェックイン情報更新部７０は、自店舗に対してチェックインした利用者に関する属性情報である店舗用チェックイン情報（図４）を売買支援サーバ１４から取得してチェックイン情報保持部５４へ格納する。本実施の形態では、売買支援サーバ１４は、公知のプッシュ通知（Push Notification）の仕組みにより店舗用チェックイン情報を店舗端末１２へ提供する。チェックイン情報更新部７０は、売買支援サーバ１４からプッシュ通知された店舗用チェックイン情報を、不図示の仲介サーバを介して取得してもよい。

ワンタイムコード取得部７２は、利用者へ予め通知された確認コードを取得する。本実施の形態では、利用者による確認コードの口頭申告を受けた店舗販売員が商品販売支援画面の（４）顔パス決済画面に対して入力した確認コードを取得する。決済要求通知部７４は、顔パス決済の実行操作が店舗販売員によりなされた際に、顔写真が選択された利用者のＩＤ、サービス事業者ＩＤ、店舗ＩＤ、決済金額、支払条件、ワンタイムコード取得部７２が取得した確認コード等を含む決済要求を売買支援サーバ１４へ送信する。後述するように、決済要求において確認コードを売買支援サーバ１４へ通知することで、利用者が申告した確認コードと、売買支援サーバ１４側が期待する確認コードとの整合有無を売買支援サーバ１４に確認させ、利用者が申告した確認コードの正当性を判定させる。

結果取得部７６は、決済要求への応答として売買支援サーバ１４から提供された決済結果情報を取得する。販売支援画面表示部６６は、商品販売支援画面の（５）決済結果画面に、売買支援サーバ１４から提供された決済結果情報を表示させる。チェックイン情報更新部７０は、結果取得部７６が決済結果を受け付けたことを契機として、典型的には商品代金の決済完了を契機として、チェックイン情報保持部５４から、決済を行なった利用者のレコードを削除する。店舗販売員は、商品購入時に利用者から確認コードを申告されて、申告コードを知る立場になっている。チェックイン後の決済処理が完了した店舗用チェックイン情報を削除することにより、店舗販売員の不正を防止できる。

図５は、図１の売買支援サーバ１４の構成を示すブロック図である。売買支援サーバ１４は、サービス情報保持部１１０と、利用者情報保持部１１１と、店舗情報保持部１１２と、制御部１１４を備える。制御部１１４は、利用者情報記録部１１６と、商品情報記録部１１８と、チェックイン受付部１２０と、乱数取得部１２２と、乱数提供部１２４と、チェックイン情報提供部１２６と、決済要求受付部１２８と、決済許否判定部１３０と、決済処理部１３２と、結果通知部１３４を含む。

一部既述したが、制御部１１４内の各機能ブロックに対応するプログラムモジュールが売買支援サーバ１４のハードディスク等のストレージに格納され、売買支援サーバ１４のＣＰＵがそれらのプログラムモジュールをメインメモリへ適宜読み出して実行することにより制御部１１４の機能が実現されてもよい。また、制御部１１４は、ストレージやメインメモリ等の記憶装置へ各種データを記憶させ、そのデータを参照して各機能ブロックに係るデータ処理を実行してもよい。また、サービス情報保持部１１０、利用者情報保持部１１１、店舗情報保持部１１２の機能は、売買支援サーバ１４のストレージやメインメモリ等の記憶装置により実現されてもよい。

サービス情報保持部１１０は、顔パス決済サービスを提供するサービス事業者に関する情報と、サービス事業者が運営する店舗の情報をサービス情報として保持する記憶領域である。このサービス情報は、購入者端末１０の商品購入支援画面において表示させるべき情報でもあり、商品売買システム１００の管理者により予め設定される。

利用者情報保持部１１１は、顔パス決済サービスにおける利用者の情報（以下、「利用者登録情報」とも呼ぶ。）と、利用者がチェックインしたことに関する情報（以下、「利用者チェックイン情報」とも呼ぶ。）を保持する記憶領域である。図６（ａ）は利用者登録情報の構成を示す。利用者登録情報には、購入者端末１０により登録された利用者のＩＤ、氏名、顔写真画像、決済に必要なクレジットカードの全情報が含まれる。また図６（ｂ）は利用者チェックイン情報の構成を示す。利用者チェックイン情報には、購入者端末１０から通知された利用者ＩＤ、チェックイン対象のサービス事業者ＩＤ、店舗ＩＤ、後述する乱数列および顔パス有効期限が含まれる。

図５に戻り、店舗情報保持部１１２は、個々の店舗に関する情報（以下、「店舗個別情報」とも呼ぶ。）を保持する。店舗個別情報には、サービス事業者ＩＤ、店舗ＩＤ、店舗端末情報、商品情報が含まれる。店舗端末情報は、チェックイン情報をプッシュ通知するために必要な店舗端末１２の情報を含む。例えば、店舗端末１２のＩＰアドレスであってもよく、個体識別番号（UID）であってもよい。商品情報は、店舗で販売される商品の名称、画像、販売価格を含む。

図５には不図示であるが、売買支援サーバ１４は、サービス情報保持部１１０に保持されたサービス情報を、定期的もしくは購入者端末１０の要求に応じて購入者端末１０へ提供するサービス情報提供部をさらに備えてもよい。また売買支援サーバ１４は、店舗情報保持部１１２に保持された商品情報を、定期的もしくは店舗端末１２の要求に応じて店舗端末１２へ提供する商品情報提供部をさらに備えてもよい。

利用者情報記録部１１６は、購入者端末１０から登録された利用者の属性情報を利用者登録情報（図６（ａ））として利用者情報保持部１１１へ格納する。商品情報記録部１１８は、サービス事業者や店舗の情報端末（例えば店舗端末１２）から登録された商品情報を受け付け、店舗情報保持部１１２の商品情報を更新する。

チェックイン受付部１２０は、購入者端末１０から通知されたチェックイン情報を受け付け、利用者チェックイン情報（図６（ｂ））として利用者情報保持部１１１へ格納する。その際に、チェックイン受付部１２０は、チェックイン情報の受付日時から所定時間経過した日時（例えば１時間後の日時）を顔パス有効期限として利用者チェックイン情報に設定する。

乱数取得部１２２は、チェックイン情報が受け付けられた際に、所定の乱数発生器で生成された乱数列を取得する。この乱数列の値は、数学的に発生させる乱数でなくてもよく、ハードウエア乱数やソフトウエア乱数などにより発生させる疑似乱数でもよい。乱数取得部１２２は、取得した乱数列のデータを、利用者情報保持部１１１の利用者チェックイン情報に設定する。乱数提供部１２４は、乱数取得部１２２が取得した乱数列のデータを、チェックイン情報の通知に対する応答として購入者端末１０へ送信する。

チェックイン情報提供部１２６は、チェックイン情報が受け付けられた際に、チェックインを行なった利用者のＩＤをキーとして、利用者情報保持部１１１の利用者登録情報から、店舗端末１２へ提供すべき店舗用チェックイン情報（図４）を抽出する。チェックイン情報提供部１２６は、設定した店舗用チェックイン情報を、公知のプッシュ通知の方法により店舗端末１２へ送信する。

決済要求受付部１２８は、店舗端末１２から送信された決済要求を受け付ける。決済許否判定部１３０は、利用者情報保持部１１１の利用者チェックイン情報を参照して、決済要求で指定された利用者ＩＤ、サービス事業者ＩＤ、店舗ＩＤと対応づけられた乱数列および顔パス有効期限を特定する。決済要求受付日時（典型的には現在日時）が顔パス有効期限を途過していた場合、決済許否判定部１３０は、決済の実行を拒否する。

決済要求受付日時が顔パス有効期限内であった場合、決済許否判定部１３０は、決済要求で指定された確認コード（ここでは「第１コード」と呼ぶ。）と、特定した乱数列とにもとづいて決済許否を判定する。具体的には、購入者端末１０で用いられた確認コード生成関数と同じ関数に乱数列を入力し、この乱数列にもとづく確認コード（ここでは「第２コード」と呼ぶ。）を生成する。そして、第１コードと第２コードとを照合し、両者が一致する場合に、正当な確認コードを受け付けたこととして決済の実行を許可し、相違する場合は決済の実行を拒否する。

決済処理部１３２は、決済許否判定部１３０が決済の実行を許可した場合に決済処理を実行する。具体的には、利用者情報保持部１１１の利用者登録情報に保持されたクレジットカード情報と、決済要求で指定された決済金額および支払条件（支払回数等）を指定した決済指示データを決済サーバ１６へ送信する。決済処理部１３２は、決済サーバ１６によるクレジットカード決済の成否を示す情報を決済サーバ１６から取得する。

結果通知部１３４は、決済許否判定結果および決済処理の成否を示す情報を決済結果情報として店舗端末１２へ送信する。例えば、顔パス有効期限切れであった場合、顔パス有効期限切れのため決済を拒否する旨の情報であり、新たなチェックイン操作を利用者に促すための情報を決済結果情報として店舗端末１２へ提供する。また利用者が申告した確認コードが不正（すなわち第２コードと不一致）であった場合、確認コードが不正である旨の情報を決済結果情報として店舗端末１２へ提供する。変形例として、結果通知部１３４は、決済が失敗となった店舗名を含む情報であり、新たなチェックイン操作を利用者に促すための情報を購入者端末１０へ送信してもよい。

以上の構成による商品売買システム１００の動作を以下説明する。
顔パス決済サービスの利用前に、利用者は、顔パス決済のための必要情報を売買支援サーバ１４へ登録する。この必要情報には、利用者ＩＤ、利用者の氏名、顔写真、クレジットカード決済に必要なクレジットカード情報（例えばクレジットカード種類、カード番号、生年月日、有効期限等）が含まれる。売買支援サーバ１４の利用者情報記録部１１６は、利用者登録情報を利用者情報保持部１１１へ格納する。また、サービス事業者は店舗で販売する商品情報を売買支援サーバ１４へ登録し、売買支援サーバ１４の商品情報記録部１１８は商品情報を店舗情報保持部１１２へ格納する。

（例えば外出中に）利用者は、店舗へ立ち寄ることを思いつくと、購入者端末１０にて商品購入支援アプリケーションを起動する。購入者端末１０のサービス情報取得部３８は、商品購入支援画面に表示させるべきデータを売買支援サーバ１４から取得する。購入者端末１０の購入支援画面表示部３６は、商品購入支援画面として、ログイン画面、サービス事業者選択画面、店舗選択画面を順次表示させた後、店舗選択画面で選択された店舗の詳細情報を示す店舗詳細画面を表示させる。図７は店舗詳細画面を示す。店舗詳細画面１４０には顔パス決済選択フィールド１４２が含まれる。顔パス決済を希望する場合、利用者は顔パス決済選択フィールド１４２に対して所定のチェックイン操作（例えばタップ操作や所定方向へのフリック操作）を入力する。このチェックイン操作により、利用者は将来時点において店舗へ来訪する意志があることを示したこととなり、後述するように、来訪対象の店舗へ利用者の情報が通知される。

店舗詳細画面１４０においてチェックイン操作が検出されると、購入者端末１０のチェックイン通知部４０は、チェックイン情報を売買支援サーバ１４へ送信する。売買支援サーバ１４のチェックイン受付部１２０は、受け付けたチェックイン情報を利用者チェックイン情報として利用者情報保持部１１１へ格納する。売買支援サーバ１４の乱数取得部１２２は、チェックイン受付部１２０がチェックイン情報を受け付けたことを契機として新たに生成された乱数列を取得して利用者チェックイン情報に記録する。売買支援サーバ１４の乱数提供部１２４は、その乱数列のデータを購入者端末１０へ送信する。

チェックイン情報通知に対する売買支援サーバ１４の応答として乱数列を受信すると、購入者端末１０のワンタイムコード生成部４２は、売買支援サーバ１４から提供された乱数列にしたがって新たに確認コードを生成する。そして販売支援画面表示部６６は店舗へのチェックインを受け付けたことを示すチェックイン画面を表示させる。図８はチェックイン画面を示す。チェックイン画面１５０にはチェックインした利用者に関する情報を表示する利用者情報エリア１５２が含まれる。利用者情報エリア１５２には、利用者の写真画像１５４、氏名１５６、ワンタイムコード生成部４２により生成された確認コード１５８を表示する。利用者はチェックイン画面１５０に表示された確認コード１５８を確認して（例えば記憶して）店舗へ来訪する。

また売買支援サーバ１４のチェックイン情報提供部１２６は、チェックイン受付部１２０がチェックイン情報を受け付けると、利用者情報保持部１１１に格納された利用者登録情報から店舗用チェックイン情報を抽出し、その店舗用チェックイン情報を店舗端末１２へ送信する。店舗端末１２のチェックイン情報更新部７０は、売買支援サーバ１４から提供された店舗用チェックイン情報を取得してチェックイン情報保持部５４へ格納する。

予めチェックインしておいた店舗へ利用者が来店し、購入希望商品を決定して店舗販売員に声をかけると、店舗販売員は店舗端末１２を操作し、商品販売支援アプリケーションのメニュー選択画面で会計メニューを選択する。店舗端末１２の商品情報取得部６８は店舗で販売している商品情報を売買支援サーバ１４から取得し、店舗端末１２の販売支援画面表示部６６は商品情報を並べた商品選択画面を表示させる。

図９は商品選択画面を示す。商品選択画面１６０の商品選択エリア１６２には、商品名と商品画像が配置される。明細エリア１６４には、店舗販売員が商品選択エリア１６２で選択した商品名と販売価格が表示される。また明細エリア１６４は、チェックイン状況フィールド１６６を含む。販売支援画面表示部６６は、自店舗に現在チェックインしている利用者数をチェックイン状況フィールド１６６へ設定し、例えばチェックイン情報保持部５４のレコード数をチェックイン状況フィールド１６６へ設定する。

また販売支援画面表示部６６は、商品選択画面１６０の表示中に新たな店舗用チェックイン情報が売買支援サーバ１４から受け付けられた場合（チェックイン情報保持部５４に新たなレコードが挿入された場合）に、その店舗用チェックイン情報が示す利用者氏名および顔写真画像をポップアップ１６８に一時的に表示させる。すなわち、自店舗へのチェックインがあったとき、そのチェックインを行なった利用者の情報を商品選択画面１６０にポップアップ表示させる。購入される商品の選択が終了し、店舗販売員が会計ボタン１７０を押下すると、販売支援画面表示部６６は、次に会計画面を表示させる。

図１０は会計画面を示す。会計画面１８０は決済手段を選択する画面とも言える。会計画面１８０には、現金決済指定エリア１８２と顔パス決済指定エリア１８４とカード決済指定エリア１８８が含まれる。現金決済指定エリア１８２は、現金決済の場合に支払金額を入力するためのエリアである。顔パス決済指定エリア１８４は、顔パス決済の場合に購入者（すなわち店舗にて商品を購入しようとしている利用者）の顔写真１８６を選択するためのエリアである。カード決済指定エリア１８８は、利用者が保持しているクレジットカードの読み込みによるクレジットカード決済の場合に選択するエリアである。

本実施の形態では顔パス決済が選択されることとする。利用者は自身の氏名（ここでは「野村花子」）を店舗販売員へ申告する。店舗販売員は、顔パス決済指定エリア１８４に表示されたチェックイン済みの複数の利用者それぞれのアイテム（氏名と顔写真の組み合わせ）を確認する。店舗販売員は、利用者の外見を目視し、顔パス決済指定エリア１８４に表示された「野村花子」の顔写真１８６と一致することを確認した上で、「野村花子」の顔写真１８６に対する選択操作（例えばタップ操作）を入力する。販売支援画面表示部６６は、次に顔パス決済画面を表示させる。

図１１は顔パス決済画面を示す。顔パス決済画面１９０には、会計画面１８０で選択された利用者の顔写真１９２および氏名１９４、確認コード入力フィールド１９６、決定ボタン１９８が表示される。ここで利用者は、チェックイン時に確認した確認コードを店舗販売員へ申告する。店舗販売員は、申告された確認コードを確認コード入力フィールド１９６へ入力する。なお、顔パス決済画面１９０では支払条件（支払回数等）の変更も可能である。利用者の外見が顔写真１９２と一致し、利用者が申告した氏名が氏名１９４と一致することを店舗販売員が確認し、また、確認コード入力フィールド１９６への確認コードの入力を完了すると、店舗販売員は、決定ボタン１９８に対する選択操作を入力して決済処理を実行させる。

顔パス決済画面１９０において決定ボタン１９８の選択操作が検出されると、店舗端末１２のワンタイムコード取得部７２は、確認コード入力フィールド１９６に入力された確認コード（ここでは「申告コード」と呼ぶ。）を取得する。店舗端末１２の決済要求通知部７４は、申告コードを含む決済要求を売買支援サーバ１４へ送信する。売買支援サーバ１４の決済要求受付部１２８が決済要求を受け付けると、売買支援サーバ１４の決済許否判定部１３０は、決済要求で指定された利用者ＩＤにより利用者チェックイン情報を特定する。そして、利用者チェックイン情報の顔パス有効期限が未経過、かつ、利用者チェックイン情報の乱数列にしたがって、決済要求の受け付けを契機に新たに生成した確認コード（ここでは「照合コード」と呼ぶ。）と、決済要求で指定された申告コードとが整合する場合に、商品代金のクレジットカード決済を許可する。

決済許否判定部１３０によりクレジットカード決済が許可された場合に、決済処理部１３２は、決済指示を決済サーバ１６へ送信し、商品代金の決済処理を実行させる。結果通知部１３４は、売買支援サーバ１４および決済サーバ１６における決済処理の結果を示す情報を店舗端末１２へ送信する。店舗端末１２の販売支援画面表示部６６は、決済処理の結果を画面表示させる。店舗販売員は、決済処理の結果を確認し、決済が正常に完了した旨の内容であれば、商品の販売が正常に完了したとして商品を利用者へ引き渡す。売買支援サーバ１４もしくは決済サーバ１６において決済処理が拒否され、もしくは失敗した旨の内容であれば、店舗販売員はその旨を利用者へ伝え、例えば新たなチェックイン操作を利用者へ促す。

本実施の形態の商品売買システム１００によると、利用者は店舗へチェックイン後、実際に店舗へ来訪して商品を購入する際に、氏名と確認コードを申告すれば商品代金の支払を完了できる。すなわち、現金やクレジットカード等の物理的な決済媒体を店舗で取り出すことなく、いわば「顔パス」で商品を購入できる。これにより、商品購入に係る利便性を高める。また、店舗に初めて来訪する場合や来店回数が少ないときでも、あたかも常連客であるかのように簡易な手続で商品を購入でき、利用者に優越感や満足感を抱かせやすくなる。

また商品売買システム１００によると、店舗へのチェックイン時に利用者へワンタイムの確認コードを提示する。そして、商品購入時に利用者が申告した確認コードと、商品購入時に売買支援サーバ１４側で生成した確認コードとが一致することを条件に、チェックインした人物と、店舗で商品を購入しようとする人物とが同一であると判定し、顔パス決済を許可する。このように、購入者の外見と顔写真とを店舗販売員が目視確認することに加えて、売買支援サーバ１４による確認コードの照合処理を併用することで、不正な決済がなされてしまうことを効果的に抑制できる。

例えば、悪意のある第三者が別の利用者へなりすました場合も、その第三者が確認コードを知ることは困難であるため、利用者側の不正行為を効果的に防止できる。また、店舗販売員による購入者の誤認識や操作ミスが発生した場合、例えば顔写真の選択を誤った場合にも確認コードの不整合が検出されるため、誤った決済がなされることを防止できる。また、利用者が申告するまでは店舗販売員も確認コードを知り得ないため、店舗販売員による不正行為も効果的に防止できる。例えば、来店しない利用者の顔写真を指定して、実際には購入されていない商品の代金を不正に支払わせることを防止できる。

また商品売買システム１００によると、利用者によるチェックイン後、所定の有効期間内（すなわち顔パス有効期限が未経過の間）に決済要求がなされることをさらなる条件として、顔パス決済を許可する。確認コードが利用者へ提示されてから時間が経過するほど、その確認コードが第三者へ漏洩する可能性は高まり、漏洩すると本人確認の精度が低下してしまう。本実施の形態では、顔パス有効期限を設けることにより、チェックインした人物と、店舗で商品を購入しようとする人物の同一性の確認精度の低下を抑制できる。

以上、本発明を実施の形態をもとに説明した。この実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。以下変形例を示す。

第１の変形例を説明する。
上記実施の形態では、売買支援サーバ１４は、利用者チェックイン情報として確認コードそのものではなく、確認コードの生成元データとしての乱数列を保持した。変形例として、利用者によるチェックイン操作時に、売買支援サーバ１４の乱数取得部１２２は、乱数列をもとに確認コードを生成し、売買支援サーバ１４は利用者チェックイン情報としてその確認コードを保持してもよい。また、売買支援サーバ１４から購入者端末１０へ乱数列を提供することに代えて確認コードを提供してもよい。また上記実施の形態では、利用者によるチェックイン操作時に、売買支援サーバ１４が購入者端末１０へ乱数列を送信することとした。変形例として、購入者端末１０が乱数列を生成し、チェックイン情報に含めて売買支援サーバ１４へ送信してもよい。また、購入者端末１０が乱数列をもとに確認コードを生成して、その確認コードを売買支援サーバ１４へ送信してもよい。このように請求項に記載の「第１の照合情報」と「第２の照合情報」は同じ内容であってもよい。

第２の変形例を説明する。
上記実施の形態では、利用者へ通知される確認コードは４桁の数字列とした。変形例として、確認コードは数字列以外の態様のデータでもよく、例えばバーコードやＱＲコード（登録商標）であってもよい。この場合に、利用者は店舗において確認コードを表示中の購入者端末１０を提示し、店舗端末１２のワンタイムコード取得部７２は、バーコードリーダやＱＲコードリーダ等の所定の読取り装置を介して、確認コードの内容を取得してもよい。

第３の変形例を説明する。
購入者端末１０は自動チェックイン機能を備えてもよい。この変形例では、売買支援サーバ１４は、地図上での店舗の位置を示す位置情報（例えば緯度・経度の値）を保持する。購入者端末１０のサービス情報取得部３８は、売買支援サーバ１４から、店舗の位置情報をさらに取得する。また購入者端末１０は、ＧＰＳ装置と位置判定部をさらに備える。ＧＰＳ装置は、ＧＰＳ衛星からＧＰＳ測位情報を受信し、受信情報から購入者端末１０の現在位置を示す情報（例えば緯度・経度の値）を出力する。

位置判定部は、利用者が予め指定した店舗（以下、「指定店舗」とも呼ぶ。）の近傍に購入者端末１０が存在するか否かを判定する。具体的には、指定店舗の所在地から所定の範囲（例えば半径１００メートル）内に、ＧＰＳ装置が出力した購入者端末１０の現在位置が含まれる場合に、購入者端末１０が指定店舗の近傍に存在すると判定する。チェックイン通知部４０は、購入者端末１０が指定店舗の近傍に存在すると判定された場合、自動的に指定店舗を指定したチェックイン情報を売買支援サーバ１４へ送信する。購入支援画面表示部３６は、自動チェックインにおいて生成された確認コードを、指定店舗の情報とともに、図８のチェックイン画面１５０と同様の自動チェックイン画面に表示させてもよい。

第４の変形例を説明する。
購入者端末１０および店舗端末１２はシンクライアント（Thin Client)として実装されてもよい。例えば購入者端末１０は、タッチパネル２０への入力データを操作検出部２６を介して取得し、売買支援サーバ１４から取得された画面データを表示制御部２８を介してタッチパネル２０に表示させる画面表示部のみを備える構成であってもよい。同様に店舗端末１２は、タッチパネル５０への入力データを操作検出部５８を介して取得し、売買支援サーバ１４から取得された画面データを表示制御部６０を介してタッチパネル５０に表示させる画面表示部のみを備える構成であってもよい。購入者端末１０および店舗端末１２の画面表示部はウェブブラウザにより実現されてもよい。

この変形例において、売買支援サーバ１４は、図２の商品購入支援部３２、図３の商品販売支援部６４に対応する機能を実現するためのデータ処理を一括して実行する。また売買支援サーバ１４は、ウェブサーバの機能を有し、データ処理の結果を示す画面データを構造化文書（ＨＴＭＬ、ＸＭＬ等）として購入者端末１０および店舗端末１２へ提供してもよい。

第５の変形例を説明する。
売買支援サーバ１４は、確認コードのロックアウト機能をさらに備えてもよい。この変形例では、売買支援サーバ１４は、同一の利用者ＩＤ、サービス事業者ＩＤ、店舗ＩＤを指定する決済要求を複数回受け付ける。そして、それぞれの決済要求で指定された確認コード（第１コード）と、上記の利用者ＩＤ、サービス事業者ＩＤ、店舗ＩＤの組み合わせにより特定された乱数列にもとづく確認コード（第２コード）が不一致となり、その不一致の回数が所定の閾値（ここでは３回）に達した場合に、上記の利用者ＩＤ、サービス事業者ＩＤ、店舗ＩＤの組み合わせにより特定された乱数列を無効にする。言い換えれば、事前の利用者のチェックインにより利用者へ提供した確認コードを無効なものとする。

例えば、利用者情報保持部１１１の利用者チェックイン情報には、照合失敗回数欄（初期値：０）と、無効フラグ欄（初期値：オフ）をさらに設けてもよい。決済許否判定部１３０は、第１コードと第２コードが不整合であった場合に、決済要求で指定された利用者ＩＤ、サービス事業者ＩＤ、店舗ＩＤの組み合わせで特定される利用者チェックイン情報について、その照合失敗回数をインクリメントする。そして、照合失敗回数が３回に達すると、利用者チェックイン情報の無効フラグをオンに設定する。決済許否判定部１３０は、決済要求で指定された利用者ＩＤ、サービス事業者ＩＤ、店舗ＩＤの組み合わせにより、まず利用者チェックイン情報の無効フラグを確認する。無効フラグがオンであれば、確認コードの照合処理をスキップし、すなわち第１コードと第２コードが一致するか否かにかかわらず、決済の実行を拒否する。結果通知部１３４は、確認コードが無効になった旨を示す情報であり、また、新たなチェックイン操作を利用者に促すための情報を店舗端末１２または購入者端末１０へ提供する。なお、新たなチェックインがなされた場合には、新たな乱数列（確認コード）が生成されて新たな利用者チェックイン情報が生成される。

本変形例では、確認コードの照合失敗が所定回数に達すると、利用者によるチェックイン時に発行された確認コードによる電子決済が拒否されることになる。これにより、悪意のある第三者による利用者へのなりすましや、店舗側の不正な決済要求による不正な決済の実行を防止しやすくなる。

次に、上記変形例に関連し、悪意のある第三者による利用者へのなりすましや、店舗側の不正な決済要求を抑制するためのさらなる変形例を説明する。売買支援サーバ１４は、所定の条件が満たされた場合にチェックインを拒否するチェックイン判定部をさらに備えてもよい。チェックイン判定部は、第１の不正防止処理として、同日に規定回数以上のチェックインが繰り返された場合に、顔パス決済の利用を一時的に停止してもよい。また、チェックイン判定部は、第２の不正防止処理として、同一の端末から再チェックインが繰り返された場合に、当該端末による顔パス決済を一時的に停止してもよい。

チェックイン判定部の第１の不正防止処理を詳細に説明する。利用者情報保持部１１１は、当日日付、利用者ＩＤ、サービス事業者ＩＤ、店舗ＩＤをキーとして、チェックイン回数（初期値：０）と対応づけたチェックイン履歴をさらに保持する。このチェックイン回数には、ある特定の日付における同一利用者による同一店舗へのチェックイン回数が記録される。チェックイン受付部１２０は、チェックイン情報を受け付けた場合に、当日日付と、チェックイン情報で指定された利用者ＩＤ、サービス事業者ＩＤ、店舗ＩＤに対応する履歴が記録済みでなければ、チェックイン回数「１」を示すチェックイン履歴を新たに記録し、記録済みであれば、そのチェックイン回数をインクリメントする。

チェックイン判定部は、チェックイン受付部１２０がチェックイン情報を受け付けた場合に、当日日付、チェックイン情報で指定された利用者ＩＤ、サービス事業者ＩＤ、店舗ＩＤに対応するチェックイン履歴を特定し、チェックイン回数が５回以下であった場合にチェックインを許可する。以降、乱数列および店舗用チェックイン情報の提供処理が継続される。その一方、チェックイン回数が６回以上であった場合、チェックイン判定部はチェックインを拒否する。この場合に、チェックイン判定部は、利用者による所定操作、例えば予め定められた本人確認操作がなされるまで、チェックイン回数が規定回数を超過した利用者からのチェックインを拒否し、確認コードの発行処理をスキップすることにより、顔パス決済を一時的に停止する。

チェックイン判定部の第２の不正防止処理を詳細に説明する。利用者情報保持部１１１は、上記第１の構成のチェックイン履歴にさらに端末ＩＤを加えたチェックイン履歴を保持する。また購入者端末１０からのチェックイン情報は購入者端末１０の端末ＩＤ（例えば個体識別番号）をさらに含む。チェックイン受付部１２０は、チェックイン情報で指定された端末ＩＤ、利用者ＩＤ、サービス事業者ＩＤ、店舗ＩＤをキーとして、チェックイン回数をインクリメントする。

チェックイン判定部は、チェックイン受付部１２０がチェックイン情報を受け付けた場合に、当日日付、チェックイン情報で指定された端末ＩＤ、利用者ＩＤ、サービス事業者ＩＤ、店舗ＩＤに対応するチェックイン履歴を特定し、チェックイン回数が５回以下であった場合にチェックインを許可する。その一方、チェックイン回数が６回以上であった場合、チェックインを拒否する。この場合に、チェックイン判定部は、利用者による所定操作、例えば予め定められた本人確認操作がなされるまで、チェックイン回数が規定回数を超過した購入者端末１０からのチェックインを拒否し、確認コードの発行処理をスキップすることにより、顔パス決済を一時的に停止する。なお、上記第１の不正防止処理と第２の不正防止処理のそれぞれは、第５の変形例に限らず、実施の形態の構成および他の変形例の構成と組み合わせてもよい。

第６の変形例を説明する。
売買支援サーバ１４は、利用者に対して発行される確認コードの重複を排除するための機能をさらに備えてもよい。既述したように、利用者情報保持部１１１の利用者チェックイン情報には、利用者ＩＤと対応づけて乱数列が格納される。本変形例ではさらにチェックイン日時が格納されることとし、具体的には、チェックイン受付部１２０は、利用者チェックイン情報を記録する際に現在日時、言い換えれば、購入者端末１０からチェックイン情報を受け付けた日時情報をさらに記録する。乱数取得部１２２は、利用者と確認コードをセットとして、同一人物に対して発行済みの確認コードと同じ確認コードを同日中に発行することを抑制する。確認コードのユニーク性を担保することで、確認コードの秘匿性を高め、悪意のある第三者や店舗による不正行為を防止しやすくなる。

具体的には、乱数取得部１２２は、乱数発生器から乱数列を取得した際に、取得した乱数列と、チェックイン情報で指定された利用者ＩＤとの組み合わせが、現在日付と対応づけられた既存の利用者チェックイン情報で設定済みか否かを確認する。既存の利用者チェックイン情報に未設定の場合、すなわち取得した乱数列と利用者ＩＤの組み合わせがユニークであれば、乱数取得部１２２は、取得した乱数列を用いて以降の処理を実行する。その一方、取得した乱数列と利用者ＩＤとの組み合わせが、既存の利用者チェックイン情報で設定済みの場合、すなわち取得した乱数列が当該利用者へ発行済みの乱数列と同じ値であれば、乱数取得部１２２は乱数発生器から乱数列を再度取得して、既存の利用者チェックイン情報との比較処理を再度実行する。

なお乱数取得部１２２は、現在日付と対応づけられた既存の利用者チェックイン情報のうち、顔パス有効期限が切れているものは比較対象から除外してもよい。言い換えれば、現在日付と対応づけられ、かつ、顔パス有効期限が未経過の既存の利用者チェックイン情報のみ比較対象として抽出してもよい。また、第１の変形例で既述したように、売買支援サーバ１４が乱数列にもとづいて確認コードを生成する場合、利用者チェックイン情報には確認コードが格納されてよい。この場合に乱数取得部１２２は、生成した確認コードと、既存の利用者チェックイン情報との比較処理を実行してもよい。

また第５の変形例にも関連するが、第６の変形例においても、売買支援サーバ１４は、チェックイン情報が受け付けられた際、所定の条件が満たされた場合にチェックインを拒否するチェックイン判定部をさらに備えてもよい。乱数取得部１２２は、チェックイン判定部が、以下の２つの判定処理の両方でチェックインを許可した（拒否しなかった）ことを条件として、上記の乱数列取得・比較処理を実行してもよい。チェックイン判定部は、第１の判定処理として、チェックインをする利用者が規定時間内に規定距離を超えていないかを判定し、第２の判定処理として、１人の利用者が短期間で大量のチェックインをしていないかを判定する。

チェックイン判定部の第１の判定処理を詳細に説明する。第３の変形例にも関連するが、売買支援サーバ１４は、地図上での店舗の位置を示す位置情報（例えば緯度・経度の値）を保持する。チェックイン判定部は、今回受け付けられたチェックイン情報（以下、「当該チェックイン情報」とも呼ぶ。）のチェックイン日時と、店舗ＩＤにより特定される店舗位置を認識する。また、当該チェックイン情報で指定された利用者ＩＤと対応づけられた既存の利用者チェックイン情報（以下、「既存チェックイン情報」とも呼ぶ。）のチェックイン日時と、店舗ＩＤにより特定される店舗位置を認識する。

チェックイン判定部は、当該チェックイン情報での対象店舗と、既存チェックイン情報での対象店舗について、許容する店舗間の距離（各店舗位置の乖離の大きさ）を、当該チェックイン情報のチェックイン日時と、既存チェックイン情報のチェックイン日時の差分に応じて決定する。典型的には、チェック日時の差分が大きいほど、許容する店舗間距離を大きくし、両者が正相関するよう決定する。例えば、チェックイン日時の差分が１時間であれば、許容する店舗間距離を６０キロメートルに決定し、チェックイン日時の差分が２時間であれば、許容する店舗間距離を１２０キロメートルに決定してもよい。

チェックイン判定部は、当該チェックイン情報での対象店舗と、既存チェックイン情報での対象店舗それぞれの位置情報から店舗間距離を算出する。算出した店舗間距離が、許容する店舗間距離より大きい場合、チェックイン判定部はチェックインを拒否する。例えば、同一の利用者が、１０時に渋谷の店舗Ａに対するチェックイン操作をした後、１０時４０分に博多の店舗Ｂに対しチェックイン操作をした場合、チェックイン判定部は後者のチェックインを拒否する。第１の判定処理によると、現実的に来店が困難なチェックインを受け付けた場合に、無駄となることが想定される顔パス決済の準備処理を抑制し、管理すべきチェックイン情報の数を低減して、売買支援サーバ１４のシステムリソースの浪費を防止できる。また、店舗側に対して、実質的に意味のないチェックインを通知してしまうことを抑制できる。

チェックイン判定部の第２の判定処理を詳細に説明する。チェックイン判定部は、チェックイン情報で指定された利用者ＩＤと対応づけられた既存の利用者チェックイン情報を参照する。そして、所定時間内（例えば直近の５分間）に記録された利用者チェックイン情報が所定数以上（例えば２０件以上）存在した場合に、大量チェックインがなされたと判定し、チェックインを拒否する。

また利用者情報保持部１１１は、利用者ＩＤ、サービス事業者ＩＤ、店舗ＩＤをキーとしてチェックイン時刻およびチェックオフ時刻の履歴を保持する。チェックイン受付部１２０は、チェックイン情報を受け付けるたびに、チェックイン時刻の履歴へ、チェックイン情報の受付日時をチェックイン時刻として逐次記録していく。また、チェックイン受付部１２０は、チェックオフ情報を受け付けるたびに、チェックオフ時刻の履歴へ、チェックオフ情報の受付日時をチェックオフ時刻として逐次記録していく。なお、チェックオフ情報は、チェックインの取り消しを要求する情報である。売買支援サーバ１４は、チェックオフ情報を受け付けると、対応する利用者チェックイン情報を削除してもよく、店舗用チェックイン情報の取り消し要求を店舗端末１２へ送信してもよい。

チェックイン判定部は、チェックイン情報で指定された利用者ＩＤ、サービス事業者ＩＤ、店舗ＩＤをキーとして、チェックイン時刻およびチェックオフ時刻の履歴を参照する。そして、同一店舗に対して所定回数以上のチェックインとチェックオフが繰り返されていることを検出すると、大量チェックインがなされたと判定し、チェックインを拒否する。

第２の判定処理において一旦チェックインを拒否すると、チェックイン判定部は、予め定められたチェックイン許可条件が満たされるまで継続して、拒否対象の利用者ＩＤが指定されたチェックイン情報によるチェックインを拒否する。チェックイン許可条件は、例えば、最終チェックインから３０分間が経過したことでもよく、チェックイン拒否を決定してから３０分が経過したことでもよい。第２の判定処理によると、現実的に当日来店できないような数のチェックインや、短時間での大量チェックインを防止でき、売買支援サーバ１４のシステムリソースの浪費を防止し、またＤｏＳ攻撃への耐性も向上できる。なお、上記第１の判定処理および第２の判定処理のそれぞれは、第６の変形例に限らず、実施の形態の構成および他の変形例の構成と組み合わせてもよい。

第７の変形例を説明する。
売買支援サーバ１４は、特定の店舗において顔パス決済を初めて利用する利用者（以下、「初回顧客」とも呼ぶ。）に対して、その店舗で使用可能なクーポン、例えば割引券や引換券を発行してもよい。本変形例において、売買支援サーバ１４は、各店舗が初回顧客へ提供するクーポンの情報の登録を受け付ける。売買支援サーバ１４の利用者情報保持部１１１は、利用者、店舗、チェックイン回数を対応づけたチェックイン履歴をさらに保持する。また売買支援サーバ１４のチェックイン受付部１２０は、チェックイン情報を受け付けると、利用者ＩＤおよび店舗ＩＤに対応するチェックイン履歴のチェックイン回数をインクリメントする。

売買支援サーバ１４はクーポン提供部をさらに備える。クーポン提供部は、チェックイン受付部１２０がチェックイン情報を受け付けた場合に、利用者ＩＤおよび店舗ＩＤに対応するチェックイン履歴のチェックイン回数を確認する。チェックイン回数が「１」（すなわち初回顧客）の場合、クーポン提供部は、チェックイン対象店舗が提供するクーポンの情報を、乱数列の提供にあわせて購入者端末１０へ提供する。これにより、例えば購入者端末１０のチェックイン画面１５０（図８）にクーポン情報を表示させ、利用者の購買意欲を高める。またクーポン提供部は、初回顧客へ提供したクーポンの情報を、チェックイン対象店舗への店舗用チェックイン情報の提供にあわせて店舗端末１２へ提供する。これにより、例えば店舗端末１２の顔パス決済画面１９０にクーポン情報を表示させ、クーポン適用対象の顧客であることを店舗販売員に報知することができる。

第８の変形例を説明する。
利用者は、自身の属性情報として、カード種類が異なる複数のクレジットカード情報を売買支援サーバ１４へ登録してよい。この場合に、売買支援サーバ１４は、複数のクレジットカード情報を店舗用チェックイン情報として店舗端末１２へ提供し、店舗端末１２の販売支援画面表示部６６は、図１１の顔パス決済画面１９０に、購入者に対応づけられた複数のクレジットカード情報を選択・切替可能にリスト表示してもよい。店舗販売員は、購入者からの口頭申告により決済で使用するクレジットカードの種類を受け付けて、リスト内からそのクレジットカードを選択する。

次に、利用者が複数のクレジットカード情報を登録済みの場合に、どのクレジットカードを使うとメリットが大きいかを自動判定し、メリットが大きいカードをデフォルト表示する構成を説明する。

店舗端末１２は、図１０の会計画面１８０において特定の顔写真１８６が選択された場合に、選択された顔写真１８６に対応する利用者ＩＤと、購入対象商品、決済金額を、サービス事業者ＩＤおよび店舗ＩＤとともに、売買支援サーバ１４へ通知する顧客情報通知部をさらに備える。売買支援サーバ１４は、リワード情報保持部とリワード判定部をさらに備える。リワード情報保持部は、クレジットカードごとに定められたリワードプログラムの情報、例えばリワードの種類（電子ポイント提供、キャッシュバック、クーポン提供等）と、リワードの提供条件を保持する。

リワード判定部は、サービス情報保持部１１０を参照して、店舗端末１２から通知されたサービス事業者ＩＤおよび店舗ＩＤに対応するサービス事業者名および店舗名を特定する。また利用者情報保持部１１１の利用者登録情報を参照して、店舗端末１２から通知された利用者ＩＤに対応づけられた複数のクレジットカード情報を特定する。またリワード情報保持部を参照して、各クレジットカードのリワード提供条件を特定する。

リワード判定部は、クレジットカードごとに、リワード提供条件と、サービス事業者名、店舗名、購入対象商品、決済金額とを比較して、提供条件が満たされたリワードの内容を特定する。そして所定の評価関数にしたがって、クレジットカードごとのリワードの大きさ、言い換えれば、購入者にとってのメリットの大きさを判定する。例えば、リワードが電子ポイントやキャッシュバックの提供であれば、その提供額が大きいほどリワードが大きいと判定してもよい。また割引クーポンの提供であれば、その割引額が大きいほどリワードが大きいと判定してもよい。リワード判定部は、購入者が保持するクレジットカードごとのリワードの大きさを示すリワード情報を店舗端末１２へ提供する。

店舗端末１２の販売支援画面表示部６６は、図１１の顔パス決済画面１９０において複数のクレジットカード情報をリスト表示させる際に、売買支援サーバ１４から通知されたリワード情報においてリワードが最も大きいとされたクレジットカードを、決済に用いる既定のカードとしての態様で表示させる。例えば、顔パス決済画面１９０の初期表示時に選択状態で表示させもよく、顔パス決済画面１９０の支払条件欄でデフォルト表示させてもよい。また販売支援画面表示部６６は、顔パス決済画面１９０において、複数のクレジットカードの情報を、リワードの大きさの降順に並べたリストを表示させてもよい。また、売買支援サーバ１４のリワード判定部は、リワードの内容も店舗端末１２へ通知してよく、店舗端末１２の販売支援画面表示部６６は、各クレジットカードに対応づけた態様でリワードの内容を表示させてもよい。

第９の変形例を説明する。
チェックイン日時から顔パス有効期限までの期間（以下、「顔パス有効期間」とも呼ぶ。）は固定期間でなくてもよく、利用者と店舗の位置関係に応じて期間の長短が動的に決定されてもよい。顔パス有効期間を維持しながらも、その長短を柔軟に調整することで、不正防止効果を維持しつつ、利用者の利便性を一層向上させることができる。

例えば、購入者端末１０または売買支援サーバ１４は、チェックイン操作時に顔パス有効期間を決定する有効期間決定部をさらに備えてもよい。購入者端末１０が有効期間決定部を備える場合は、購入者端末１０は、決定した顔パス有効期間をチェックイン情報に含めて売買支援サーバ１４へ通知し、売買支援サーバ１４は、通知された顔パス有効期間にもとづく顔パス有効期限を利用者チェックイン情報に格納してもよい。また売買支援サーバ１４が有効期間決定部を備える場合は、購入者端末１０は、自端末の位置情報をチェックイン情報に含めて売買支援サーバ１４へ通知してもよい。

有効期間決定部は、チェックイン対象店舗の所在地と、購入者端末１０の現在位置が離れているほど、漏洩リスクを考慮した所定期間（例えば１２時間）を上限とした範囲内で顔パス有効期間を長くしてもよい。また、チェックイン対象の店舗の所在地と、購入者端末１０の現在位置に応じて、利用者が店舗へ移動する際の所要時間を推定してもよく、移動の所要時間が長いほど顔パス有効期間を長くしてもよい。また、移動の所要時間に１時間等の所定時間を加えた結果を顔パス有効期間として決定してもよい。また移動の所要時間を精度よく推定するために、徒歩・自転車・自動車等の移動手段を利用者に選択させてもよく、選択された移動手段と予め対応づけられた平均移動速度に応じて所要時間を推定してもよい。

第１０の変形例を説明する。
利用者が特定の店舗の常連客、具体的には、特定の店舗において所定回数もしくは所定金額以上の顔パス決済の経験者である場合に、その店舗における顔パス有効期間を、常連客でない他の利用者の顔パス有効期間より長い期間になるよう決定してもよい。常連客は顔パス決済に慣れているため、確認コードの漏洩リスクが相対的に低いことが見込まれ、また、常連客であるため店舗側の不正行為も抑制されることが見込まれるためである。このように常連客を特別待遇とすることで、常連客である利用者に優越感や満足感を一層抱かせやすくなる。

この変形例においても、購入者端末１０または売買支援サーバ１４は有効期間決定部をさらに備える。また購入者端末１０または売買支援サーバ１４は、利用者と、その利用者が顔パス決済により商品を購入した店舗、購入回数、決済金額を対応づけた決済履歴を保持する決済履歴保持部をさらに備える。購入者端末１０が決済履歴保持部を備える場合、顔パス決済がなされる都度、売買支援サーバ１４は決済履歴を購入者端末１０へ提供してもよい。

有効期間決定部は、利用者が特定の店舗へチェックインするときに、決済履歴を参照して、その店舗における当該利用者の顔パス決済回数および／または顔パス決済金額を特定する。そして、顔パス決済回数が所定回数（例えば３回）以上、および／または、顔パス決済金額が所定額（例えば１万円）以上であるときに、利用者がチェックイン対象店舗の常連客であると判定する。有効期間決定部は、常連客でないと判定した場合、上記実施の形態や第９の変形例で記載したような通常の方法にて顔パス有効期間を決定する一方、常連客と判定した場合は、通常の方法で決定した顔パス有効期間より長い期間を、常連客に付与する顔パス有効期間として決定する。例えば、通常の方法で決定した顔パス有効期間に対して２時間等の所定時間を加えた期間としてもよい。

第１１の変形例を説明する。
店舗端末１２の販売支援画面表示部６６は、顔パス有効期限が切れた利用者のアイテム（例えば氏名と顔写真を含むアイコン）を、販売支援画面（例えば会計画面）において店舗販売員による選択ができない態様で表示させてもよい。例えば、グレーアウトして表示させてもよく、選択操作を無効なものにして（例えばdisable属性を付与して）表示させてもよい。また、顔パス有効期限が切れた利用者のアイテムを販売支援画面で非表示としてもよい。この変形例によると、販売支援画面において選択候補となる利用者を、顔パス有効期限内の利用者に限定できるため、選択候補となる利用者数を抑制でき、店舗販売員による選択の手間を低減させることができる。また、顔パス有効期限が切れた利用者が選択されることを抑制し、例えば店舗販売員が再度のチェックインを利用者へ促すことを支援し、顔パス決済時のエラーの発生を抑制できる。

この変形例において、売買支援サーバ１４は、店舗用チェックイン情報として、利用者の顔パス有効期限を店舗端末１２へさらに通知してもよい。また売買支援サーバ１４は、利用者情報保持部１１１に格納された各利用者の顔パス有効期限を定期的に参照し、顔パス有効期限が切れた利用者を定期的に検出して、その利用者の情報をチェックイン対象店舗の店舗端末１２へ通知してもよい。顔パス有効期限切れの利用者の特定主体は、前者の場合は店舗端末１２となり、後者の場合は売買支援サーバ１４となる。

第１１の変形例に関連する第１２の変形例を説明する。
店舗端末１２の販売支援画面表示部６６は、顔パス有効期限が切れた利用者の情報（例えば氏名と顔写真を含むアイテム）を、顔パス有効期限内の利用者の情報表示領域とは別領域に表示させてもよい。例えば、顔パス有効期限が切れた利用者の情報を、顔パス有効期限内の利用者の情報表示領域では非表示とする一方、メニュー画面、商品選択画面、会計画面それぞれの有効期限切れ情報表示領域にて新たに表示させてもよい。この変形例によると、会計画面において選択候補となる利用者を、顔パス有効期限内の利用者に限定できる。これにより、選択候補となる利用者数を抑制して、店舗販売員による選択の手間を低減できる。また、顔パス有効期限が切れた利用者の情報を販売支援画面に常時表示させることで、その利用者が来店した際に、店舗販売員は再度のチェックインを促すための声掛けを実施しやすくなり、顔パス決済時のエラーの発生を抑制できる。

なお、販売支援画面表示部６６は、顔パス有効期限が切れた利用者のうち、顔パス有効期限切れが特定された日時が新しい利用者の情報ほど、強調した態様で販売支援画面に表示させてもよい。例えば、有効期限切れ情報表示領域において、他の利用者の情報より上段に表示させてもよく、強調するための色やオブジェクトを付加して表示させてもよい。最近顔パス有効期限切れとなった利用者の方が、店舗へ来訪する可能性が高いと想定されるところ、その利用者が来店した際に、店舗販売員は再度のチェックインを促すための声掛けを実施しやすくなる。

第１３の変形例を説明する。
店舗端末１２の販売支援画面表示部６６は、販売支援画面としての顔写真の選択画面（例えば図１０の顔パス決済指定エリア１８４）において、チェックインした複数の利用者それぞれの来店予定時刻に応じた態様で、各利用者の氏名および顔写真を含むアイテムを表示させてもよい。好適には、現在時刻と来店予定時刻が相対的に近い利用者のアイテムを、現在時刻と来店予定時刻が相対的に離れた利用者のアイテムより強調した態様で表示させる。例えば、強調するための色やオブジェクトを付加して表示させてもよい。また、現在時刻と来店予定時刻が近い利用者のアイテムほど、顔パス決済指定エリア１８４の上段で表示させてもよい。現在時刻と来店予定時刻が近い利用者は、現在来店する可能性が高い利用者であると想定されるため、顔写真の選択画面において利用者アイテムの選択を容易にすることができる。

この変形例において、購入者端末１０、店舗端末１２、または売買支援サーバ１４は、来店時刻推定部をさらに備える。第９の変形例の有効期間決定部と同様に、来店時刻推定部は、チェックイン対象店舗の所在地と、購入者端末１０の現在位置に応じて、現在位置から店舗への移動の所要時間を推定する。来店時刻推定部は、チェックイン時刻から移動の所要時間を経過させた時刻を来店予定時刻として特定する。購入者端末１０、店舗端末１２、売買支援サーバ１４のいずれが来店時刻推定部を備える場合も、来店時刻推定部による推定処理に必要な情報（例えばチェックイン時刻、購入者端末１０の現在位置、店舗の所在地、移動手段等）は、購入者端末１０から売買支援サーバ１４へのチェックイン情報の通知、売買支援サーバ１４から店舗端末１２への店舗用チェックイン情報の通知により伝達してよい。来店時刻推定部が特定した来店予定時刻も同様に伝達してよい。

第１４の変形例を説明する。
店舗端末１２の販売支援画面表示部６６は、販売支援画面としての顔写真の選択画面（例えば図１０の顔パス決済指定エリア１８４の表示画面）を表示する前に、確認コードの入力画面を表示させてもよい。そして顔写真の選択画面では、確認コードの一部のデータに整合する顔写真のみを表示させてもよい。また、確認コードの一部のデータに整合する顔写真を、不整合の顔写真より強調した態様（エリアの上段、大きいサイズ、強調色、所定のオブジェクトを付加した態様）で表示させてもよい。確認コードの一部のデータは、確認コードの１桁目の数字であってもよく、１桁目および２桁目の数字列であってもよく、ここでは「限定コード」と呼ぶ。この場合、売買支援サーバ１４は、確認コードを保持して、確認コードから限定コードを抽出し、限定コードを含む店舗用チェックイン情報を店舗端末１２へ提供してもよい。この変形例によると、不正防止効果を維持しつつ、選択候補となる利用者数を抑制し、店舗販売員による選択の手間を低減させることができる。

第１５の変形例を説明する。
上記実施の形態では、売買支援サーバ１４の決済許否判定部１３０は、決済要求に係る利用者の顔パス有効期限が切れていた場合に、商品代金の決済を禁止することとした。変形例として、決済要求に係る利用者の顔パス有効期限が切れていても、決済金額が所定金額（例えば１万円）以下の場合は、決済を許可してもよい。また第１０の変形例に関連して、決済要求に係る利用者が決済対象店舗の常連客である場合は、顔パス有効期限による決済許否判定をスキップしてもよい。言い換えれば、決済要求に係る利用者が決済対象店舗の常連客でない場合に、顔パス有効期限による決済許否判定を実行してもよい。

第１６の変形例を説明する。
上記実施の形態では、利用者は自身の顔写真を売買支援サーバ１４へ登録し、売買支援サーバ１４はチェックインを契機に利用者の顔写真を店舗端末１２へ提供し、店舗販売員は、商品購入者と選択画面の顔写真とを見比べることとした。変形例として、利用者（購入者）を識別するために顔写真以外の画像が用いられてもよく、すなわち特定の利用者を他者と区別して認識可能な画像であればよく、利用者の外見の特徴を示す画像であればよい。例えば、利用者の外見の特徴を反映したキャラクターでもよく、利用者をモデルとした肖像画の画像データであってもよい。

（第２の実施形態）
以下、第２の実施形態を説明する。その際、第１の実施形態との共通点については説明を省略或いは簡略する。

図１２は、第２の実施形態に係る売買支援サーバ１４−２の機能構成を示すブロック図である。

売買支援サーバ１４−２は、利用者情報記録部１１６と、チェックイン受付部１２０と、乱数生成部１２２と、乱数提供部１２４と、チェックイン情報提供部１２６と、商品情報記録部１１８と、決済要求受付部１２８−２と、決済許否判定部１３０−２と、決済処理部１３２と、結果通知部１３４と、顔写真有効度算出部２０１と、顔写真有効期限変更部２０３と、顔パス決済判定部２０３と、を有する。売買支援サーバ１４−２は、サービス情報保持部１１０と、利用者情報保持部１１１−２と、店舗情報保持部１１２と、決済履歴情報保持部２１１とを有する。利用者情報記録部１１６と、チェックイン受付部１２０と、乱数生成部１２２と、乱数提供部１２４と、チェックイン情報提供部１２６と、商品情報記録部１１８と、決済処理部１３２と、結果通知部１３４と、サービス情報保持部１１０と、店舗情報保持部１１２との機能は、第１の実施形態において説明した通りである。よって、ここでの説明を省略する。

図１３は、第２の実施形態において利用者情報保持部１１１−２が記録する情報を示す。利用者情報保持部１１１−２は、図１３（ａ）に示す利用者登録情報４０１と、図１３（ｂ）に示す利用者チェックイン情報４０２と、を保持する。

利用者登録情報４０１は、図６（ａ）に示した利用者ＩＤ、氏名、顔写真画像、クレジットカード情報に加えて、顔写真有効期限と、顔写真有効度とを有する。

利用者チェックイン情報４０２は、図６（ｂ）に示した利用者ＩＤ、サービス事業者ＩＤ、店舗ＩＤ、乱数列、顔パス有効期限に加えて、顔写真有効度を有する。

顔写真有効期限は、顔写真画像の有効期限を示す日時を保持する。売買支援サーバ１４−２は、顔写真有効期限を過ぎた顔写真画像は、新しい顔写真画像に更新される必要があるとしても良い。売買支援サーバ１４−２は、顔写真有効期限を過ぎている場合、利用者からのチェックインを許可しないとしても良い。売買支援サーバ１４−２は、顔写真有効期限を過ぎている場合、利用者の顔パス決済を許可しないとしても良い。売買支援サーバ１４−２は、所定の条件に基づいて、顔写真有効期限を延長又は短縮しても良い。当該処理の詳細については後述する。

顔写真有効度は、顔写真画像の有効性（信頼性）を示す情報（例えば数値）を保持する。売買支援サーバ１４−２は、顔写真画像について、本人であることを識別するための品質が高い場合、その顔写真画像の顔写真有効度を高く算出しても良い。売買支援サーバ１４−２は、顔写真画像について、本人であることを識別するための品質が低い場合、その顔写真画像の顔写真有効度を低く算出しても良い。顔写真有効度の算出方法の詳細については後述する。

図１４は、決済履歴情報保持部２１１が記録する情報を示す。決済履歴情報保持部２１１は、図１４（ａ）に示す決済履歴情報４０３を保持する。

決済履歴情報４０３は、決済日時と、利用者ＩＤと、顔写真画像と、サービス事業者ＩＤと、店舗ＩＤと、決済手段と、決済応対店員ＩＤと、顔写真評価と、決済金額と、決済成否と、を有する。

利用者ＩＤ、顔写真画像、サービス事業者ＩＤ、店舗ＩＤ、利用者ＩＤ及び店舗ＩＤの内容は、図６で説明した通りである。よって、ここでの説明を省略する。

決済日時は、利用者が決済を行った日時を保持する。

決済手段は、利用者が行った決済手段を識別するための情報（例えばＩＤ）を保持する。決済手段は、例えば、現金決済、クレジットカード決済、電子マネー決済顔パス決済、及びポイント決済等の何れかを識別するためのＩＤを保持する。

決済応対店員ＩＤは、決済を行った店員を識別するための情報（例えばＩＤ）を保持する。

顔写真評価は、顔写真画像に対する決済応対店員ＩＤに係る店員の評価を保持する。顔写真評価は、例えばＯＫ／ＮＧの二値評価であっても良いし、例えば１〜５段階（数値が大きいほど評価が高い）の多値評価であっても良い。顔写真評価は、本人と識別できるか否かに基づく一次元の評価であっても良いし、さらに他の評価軸を組み合わせた多次元の評価であっても良い。例えば、顔写真評価は、本人の識別可否の評価に加えて（又は評価に代えて）、顔写真に対して、髪型が異なっている、サングラスを掛けている、マスクを付けている等の特徴に関する評価軸を有しても良い。顔パス決済に応対した店員は、店舗端末１２−２を操作して、これらの顔写真評価を入力する。顔写真評価の入力方法の詳細については後述する。

決済金額は、利用者の決済金額（合計金額）を保持する。

決済成否は、決済サーバ１６において利用者のクレジットカード等による決済（与信）が成功したか否かを示す情報を保持する。つまり、決済成否は、決済サーバ１６によって決定される。決済サーバ１６における決済が失敗した場合の決済履歴情報も保持しているのは、売買支援サーバ１４−２において、決済が失敗した場合の顔写真評価も保持しておきたいからである。なぜなら、顔写真評価の数が多いほど、顔写真画像の顔写真有効度をより良い精度で算出できる可能性があるからである。ただし、決済成否は、決済サーバ１６で判断される構成に限られない。例えば、売買支援サーバ１４−２又は店舗端末１２−２が決済成否を判断する構成であっても良い。以下、図１２の説明に戻る。

顔写真有効度算出部２０１は、顔写真画像に対する顔写真有効度を算出する。つまり、顔写真有効度算出部２０１は、決済履歴情報４０３に基づいて、利用者の顔写真画像と関連付けて行われた決済に関する顔写真有効度を算出する。

顔写真有効度算出部２０１は、利用者が顔パス決済を行った回数が所定の回数以下である場合、利用者の顔写真画像の顔写真有効度に所定の下限を設定しても良い。つまり、利用者が顔パス決済を行った回数が有意な顔写真有効度を算出するに不足している場合は、仮に顔写真有効度が小さい場合であっても、顔パス決済を不許可としないようにしても良い。

顔写真有効度算出部２０１は、利用者が行った全ての決済に対して顔パス決済を行った割合が高いほど、利用者の顔写真画像の顔画像有効度を高く算出しても良い。

顔写真有効度算出部２０１は、顔パス決済に応対した店員の数が多いほど、利用者の顔写真画像の顔写真有効度を高く算出しても良い。店員の数は、重複しない店員の数としても良い。つまり、一人の利用者に対して同じ店員が二回以上応対した場合は、その店員を一人と数えても良い。

顔写真有効度算出部２０１は、決済応対店員の顔写真画像に対する顔写真評価に基づいて、利用者の顔写真画像の顔写真有効度を算出しても良い。

顔写真有効度算出部２０１は、決済応対店員の顔写真画像に対する顔写真評価の総計が大きいほど、利用者の顔写真画像の顔写真有効度を高く算出しても良い。

顔写真有効度算出部２０１は、顔パス決済に応対した店員の数と当該決済応対店員の顔写真画像に対する顔写真評価とに基づいて、利用者の顔写真画像の顔写真有効度を算出しても良い。例えば、当該顔写真画像に対する顔写真評価の総計を当該顔写真画像に応対した店員の数で除算した平均値に基づいて、当該顔写真画像の顔写真有効度を算出しても良い。

顔写真有効度算出部２０１は、決済履歴情報４０３に基づいて、例えば、以下の（Ａ）又は（Ｂ）によって顔写真有効度を算出する。
（Ａ）顔写真有効度算出部２０１は、利用者が行った決済の全回数における顔パス決済の回数の割合に基づいて、顔写真有効度を算出する。
（Ｂ）顔写真有効度算出部２０１は、利用者が行った決済に対応した重複しない店員の全人数における顔パス決済に対応した（重複しない）店員の人数の割合に基づいて、顔写真有効度を算出する。

上記（Ａ）及び（Ｂ）は、何れも顔パス決済数の割合が大きい場合に、顔写真有効度が高くなる。つまり、顔パス決済を頻繁に利用する利用者の顔写真画像ほど、顔写真有効度は高くなる。

顔写真有効度算出部２０１は、上記（Ａ）及び（Ｂ）を組み合わせて、顔写真有効度を算出しても良い。又は、顔写真有効度算出部２０１は、上記（Ａ）及び（Ｂ）に加え、又は（Ａ）及び（Ｂ）の代わりに、店員からの顔写真画像に対する顔写真評価を用いて、顔写真有効度を算出しても良い。以下、この算出方法について、図面を用いて説明する。

図１５は、顔写真有効度を算出する処理のフローチャートの一例を示す。

顔写真有効度算出部２０１は、顔写真有効度を算出する対象の利用者ＩＤを特定する（Ｓ１０１）。なお、顔写真有効度算出部２０１は、顔写真有効度を算出する対象を、利用者ＩＤではなく、顔写真画像によって特定しても良い。

顔写真有効度算出部２０１は、決済履歴情報保持部２１１から、その特定した利用者ＩＤを含む１以上の決済履歴情報４０３を抽出する（Ｓ１０２）。以下、この抽出した１以上の決済履歴情報４０３の束を決済履歴情報リストという。

顔写真有効度算出部２０１は、決済履歴情報リストの決済手段を参照して、決済手段毎（１番目の決済手段、２番目の決済手段、…）の決済回数をカウントする（Ｓ１０３）。ここで、ｉ番目の決済手段の決済回数をＳＴ_ｉと表現する（ｉは１以上の整数）。また、ｋ番目の決済手段が顔パス決済手段であるとする（ｋは１以上の整数）。ＳＴ_ｉは、決済履歴情報リストの決済成否を参照して成功した決済（与信が通った決済）のみをカウントしたものであっても良いし、決済成否に関わらず（与信が通った否かに関わらず）全ての決済をカウントしたものであっても良い。

顔写真有効度算出部２０１は、決済履歴情報リストの決済応対店員ＩＤを参照して、決済手段毎の（重複しない）決済応対店員数をカウントする（Ｓ１０４）。ここで、ｉ番目の決済応対店員数をＮ_ｉと表現する。つまり、Ｎ_ｋは、顔パス決済に対応した店員数を示す。

顔写真有効度算出部２０１は、決済履歴情報リストの顔写真評価を参照して、顔パス決済に対応した店員毎（１番目の顔パス決済応対店員、２番目の顔パス決済応対店員、…）の顔写真評価を抽出する（Ｓ１０５）。ここで、ｊ番目の顔パス決済応対店員の顔写真評価ＰをＰ_ｊと表現する（ｊは１以上の整数）。また、顔写真評価Ｐは、「０＜顔写真評価Ｐ≦１」であるとする。顔写真評価Ｐは、後述する店舗端末１２−２の顔写真評価領域５０６（図２０参照）から入力されても良い。

そして、顔写真有効度算出部２０１は、上述の各値を下記の（式１）に代入して、利用者ＩＤに係る顔写真画像の顔写真有効度を算出する（Ｓ１０６）。算出された顔写真有効度は、利用者登録情報４０１の顔写真有効度に保持される。

（式１）によれば、顔写真有効度は、以下の特性を有する。
・顔パス決済回数が多いほど、顔写真有効度は高くなる。
・（重複しない）顔パス決済応対店員数が多いほど、顔写真有効度は高くなる。
・顔パス決済応対店員の顔写真評価が高いほど、顔写真有効度は高くなる。
・顔パス決済応対店員数が多くても、多くの顔パス決済応対店員の顔写真評価が低い場合、顔写真有効度は低くなる。

顔写真有効度算出部２０１は、顔写真評価を用いずに顔写真有効度を算出しても良い。例えば、顔写真有効度算出部２０１は、上記（式１）のＰ_ｊを何れも「１」とした下記の（式２）に、上述の各値を代入して顔写真有効度を算出する。

顔写真有効度算出部２０１は、ＳＴ_ｋが所定の数に満たない場合、上記（式１）又は（式２）とは異なる式によって顔写真有効度を算出しても良い。なぜなら、ＳＴ_ｋが所定の数に満たない場合は、有意な顔写真有効度を算出できない虞があるからである。そこで、顔写真有効度算出部２０１は、ＳＴ_ｋが所定の数に満たない場合、顔写真有効度を一律に５０（％）としても良いし、顔写真有効度の下限を５０（％）としても良い。これにより、ＳＴ_ｋが所定の数に満たない場合に、顔パス決済が不許可となることを回避できる。

また、顔写真有効度算出部２０１は、顔パス決済の間隔に応じて顔写真有効度に重み付けを行って顔写真有効度を算出しても良い。例えば、顔写真有効度算出部２０１は、最後に顔パス決済を行ってからの経過時間に応じて顔写真有効度が低くなるように重み付けを行っても良い。顔写真有効度算出部２０１は、最後に顔パス決済を行ってからの経過時間が所定よりも短い場合に顔写真有効度が高くなるように重み付けを行っても良い。以下、図１２の説明に戻る。

顔パス決済判定部２０３は、チェックイン要求を送信してきた利用者の顔パス決済を許可するか否かを判定する。顔パス決済判定部２０３は、その利用者に対応する利用者登録情報４０１に基づいて、顔パス決済を許可するか否かを判定しても良い。顔パス決済判定部２０３は、その利用者登録情報４０１に含まれる顔写真有効度及び／又は顔写真有効期限に基づいて、顔パス決済を許可するか否かを判定しても良い。

顔パス決済判定部２０３は、顔写真有効度が所定の第１閾値よりも大きい場合、利用者の顔写真画像を用いた顔パス決済を許可すると判定しても良い。

顔パス決済判定部２０３は、顔画像有効度が上記の第１閾値以下の場合、利用者の顔写真画像と利用者に予め知らされている確認コードとを用いた決済を許可すると判定しても良い。

顔パス決済判定部は、顔画像有効度が上記の第１閾値よりも小さい所定の第２閾値未満の場合、利用者の顔写真画像を用いた決済を許可しないと判定しても良い。以下、顔パス決済判定部２０３の処理について、更に図面を用いて説明する。

図１６は、顔パス決済判定部２０３の処理のフローチャートの一例を示す。

顔パス決済判定部２０３は、購入者端末１０からチェックイン要求を受信すると（Ｓ２０１）、利用者登録情報４０１から、利用者の顔写真画像の顔写真有効度を取得する（Ｓ２０２）。

顔パス決済判定部２０３は、例えば、その顔写真有効度が、（Ａ）「顔写真有効度＜５０−α」、（Ｂ）「５０−α≦顔写真有効度≦５０＋β」、（Ｃ）「５０＋β＜顔写真有効度」、の何れに該当するかを判定する（Ｓ２０３）。ここで、α及びβは、顔写真画像を有効とする範囲を決定するための所定の閾値であり、α＝βであっても良いし、α≠βであっても良い。

（Ａ）「顔写真有効度＜５０−α」に該当する場合
顔パス決済判定部２０３は、顔パス決済を許可しないと判定する。この場合、売買支援サーバ１４−２は、購入者端末１０に、チェックインを許可できない旨の応答を返しても良い。顔パス決済判定部２０３は、購入者端末１０（つまり、利用者）に、顔写真画像の再登録を要求しても良い。

（Ｂ）「５０−α≦顔写真有効度≦５０＋β」に該当する場合
顔パス決済判定部２０３は、顔写真画像及び氏名と、確認コードによる顔パス決済を許可すると判定する。この場合、売買支援サーバ１４−２は、第１の実施形態で説明した様に、利用者の顔写真画像及び氏名と、乱数とを購入者端末１０に送信する。また、売買支援サーバ１４−２は、利用者の顔写真画像及び氏名と、ワンタイムコードとを店舗端末１２に送信する。これにより、利用者がその店舗において氏名及び確認コード（ワンタイムコード）を伝え、店員がその利用者の顔写真画像、氏名及び確認コードを確認することにより、顔パス決済を実現することができる。なお、ＳＴ_ｋが所定の数に満たない場合、顔写真有効度を一律に５０（％）としておくと、顔パス決済判定部２０３は、当該（Ｂ）の処理を実行することとなる。又は、ＳＴ_ｋが所定の数に満たない場合、顔写真有効度の下限を５０（％）としておくと、顔パス決済判定部２０３は、少なくとも当該（Ｂ）の処理を実行することになる。

（Ｃ）「５０＋β＜顔写真有効度」に該当する場合
顔パス決済判定部２０３は、顔写真及び氏名のみによる顔パス決済を許可すると判定する。この場合、売買支援サーバ１４−２は、上記（Ｂ）と同様の処理を行っても良いが、次の処理を行っても良い。つまり、売買支援サーバ１４−２は、購入者端末１０に乱数を送信する処理と、ワンタイムコードを生成して店舗端末１２へ送信する処理とを省略しても良い。

図１７は、上述の顔パス決済判定部２０３の判断及びアクションの表を示す。

上述の処理は、ＳＴ_ｋが所定の数に満たない場合の対処を、顔写真有効度の算出段階に含めている。これに対して、当該図１７を用いて説明する処理は、ＳＴ_ｋが所定の数に満たない場合の対処を、顔パス決済判定部２０３の判定段階に含めている。つまり、顔パス決済判定部２０３は、顔写真有効度が図１７（Ａ）乃至（Ｃ）の何れに該当するかを判定した後、顔パス決済数が所定数以上であるか否かに応じて、顔パス決済の方法及びアクションを決定しても良い。以下、図１２の説明に戻る。

顔写真有効期限変更部２０２は、利用者登録情報４０１の顔写真有効期限を変更するか否かを判定する。顔写真有効期限変更部２０２は、利用者登録情報４０１及び／又は決済履歴情報４０３に基づいて、顔写真有効期限を延長するか否かを判定する。又は、顔写真有効期限変更部２０２は、利用者登録情報４０１及び／又は決済履歴情報４０３に基づいて、顔写真有効期限を短縮するか否かを判定しても良い。顔写真有効期限変更部２０２は、図１６に示した「（Ｃ）５０＋α＜顔写真有効度」の場合、顔写真有効期限を当初の期限よりも延長しても良い。顔写真有効期限更新部２０２は、図１６に示した「（Ａ）顔写真有効度＜５０−α」の場合、顔写真有効期限を当初の期限よりも短縮しても良い。顔写真有効期限変更部２０２は、所定期間に所定回数以上顔パス決済を利用した利用者に対して、顔写真有効期限を当初の期限よりも延長しても良い。顔写真有効期限変更部２０２は、顔写真有効期限の日前から所定期間の間に、上述の顔写真有効期限を変更するか否かを判定しても良い。

特典変更部２０４は、利用者の顔写真有効度に応じて、その利用者に提供する特典を変更する。例えば、特典として決済を行った店舗で利用可能なポイントを利用者に提供する場合、顔写真有効度の大きい利用者に、より高い割合でポイントを提供しても良い。例えば、期間限定の特典を利用者に提供する場合、その限定された期間における顔写真有効度の大きい利用者に、より良い得点を提供しても良い。

顔写真更新要求部２０５は、利用者の顔写真有効度が所定の閾値以下の場合、利用者に対して顔写真画像の更新を要求する。例えば、顔写真更新要求部２０５は、「（Ｃ）顔写真有効度＜５０−α」の場合、利用者の購入者端末１０に対して、顔写真画像を更新しなければ顔パス決済を利用できなくなる旨を通知しても良い。例えば、顔写真更新要求部２０４は、「（Ｂ）５０−α≦顔写真有効度≦５０＋β」の場合、利用者の購入者端末１０に対して、より高品質の顔写真画像に更新することにより、確認コードの入力が不要となる旨を通知しても良い。

図１８は、第２の実施形態に係る店舗端末１２−２の機能構成を示すブロック図である。

店舗端末１２−２は、販売支援画面表示部６６−２と、チェックイン情報更新部７０と、決済手段制御部２１と、決済要求通知部７４と、商品情報取得部６８と、ワンタイムコード取得部７２と、結果取得部７６とを有する。店舗端末１２−２は、チェックイン情報保持部７４−２を有する。チェックイン情報更新部７０と、決済手段制御部２１と、決済要求通知部７４と、商品情報取得部６８と、ワンタイムコード取得部７２と、結果取得部７６との機能は、第１の実施形態において説明した通りである。よって、ここでの説明を省略する。

図１９は、チェックイン情報保持部７４−２の記憶する情報と、決済要求情報とを示す。チェックイン情報保持部７４−２は、店舗チェックイン情報４０４を保持する。

図１９（ａ）に示す店舗チェックイン情報４０４は、売買支援サーバ１４−２から送信される。チェックイン情報更新部７０が、店舗チェックイン情報４０４を受信し、チェックイン情報保持部７４−２に保持させる。店舗チェックイン情報４０４は、利用者ＩＤと、氏名と、顔写真画像と、クレジットカード番号と、顔写真有効度と、を示す情報を有する。これらの内容は、上述において図１３を用いて説明した通りである。よって、ここでの説明を省略する。

図１９（ｂ）に示す決済要求情報４０５は、決済要求通知部７４から売買支援サーバ１４−２に送信される。決済要求情報４０５は、利用者ＩＤと、氏名と、決済手段と、決済金額と、クレジットカードと、決済応対店員ＩＤと、顔写真評価と、を有する。これらの内容は、上述において図１４を用いて説明した通りである。よって、ここでの説明を省略する。図１８の説明に戻る。

販売支援画面表示部６６−２は、第１の実施形態で説明した機能に加えて、以下の機能を有する。なお、機能の説明においては、適宜、後述する図２０に示す符号も用いる。

販売支援画面表示部６６−２は、顔パス決済用ＧＵＩ５００を生成し、タッチパネル５０に表示する。販売支援画面表示部６６−２は、タッチパネル５０を介して顔パス決済用ＧＵＩ５００に入力（操作）された内容に基づいて、所定の処理を実行する。

販売支援画面表示部６６−２は、複数の利用者の中から選択された一の利用者の顔写真画像５２２を表示する顔写真表示領域５０２と、その一の利用者の顔写真画像５２２に対する評価（応答）を受け付ける顔写真評価入力領域５０６と、顔写真表示領域５０２に表示されている顔写真画像５２２に係る利用者に関する決済の指示を受け付ける決済決定ボタン５０７と、を有する顔パス決済用ＧＵＩ５００を生成し、タッチパネル５０に表示する。

販売支援画面表示部６６−２は、顔パス決済用ＧＵＩ５００の決済決定ボタン５０７を、評価入力領域５０６に評価が入力された後、決済の指示を受け付け可能な状態としても良い。

販売支援画面表示部６６−２は、店舗チェックイン情報４０４に含まれている顔写真評価度に応じた表示態様で顔パス決済用ＧＵＩ５００を生成しても良い。例えば、販売支援画面表示部６６−２は、顔写真評価度が所定の閾値以下の場合、顔写真表示領域５０２を、注意を喚起する表示態様（例えば、顔写真表示領域の枠を通常とは異なる色とする等）とする顔パス決済用ＧＵＩ５００を生成しても良い。

販売支援画面表示部６６−２は、顔パス決済用ＧＵＩ５００に、利用者に予め知らされている確認コードの入力を受け付ける確認コード入力領域５０４を有し、顔パス決済用ＧＵＩ５００の確認コード入力領域５０４を、評価入力領域５０６に評価が入力されるまで、確認コードの入力を受け付けない状態としても良い。

販売支援画面表示部６６−２は、評価入力領域５０６に入力された評価が所定の閾値よりも大きい場合は、確認コード入力領域５０４に対する確認コードの入力を省略可能とし、その旨を示す表示態様を示す顔パス決済用ＧＵＩ５００を生成しても良い。

決済手段制御部２２１は、利用者の希望する決済手段に応じた決済の処理を行う。利用者の希望する決済手段が顔パス決済の場合、決済手段制御部２２１は、顔パス決済用ＧＵＩ５００を販売支援画面表示部６６−２に表示させる。また、決済手段制御部２２１は、その顔パス決済用ＧＵＩ５００に対する操作に応じて所定の処理を実行する。

決済手段制御部２２１は、利用者の顔写真評価度に応じて、利用者の顔写真画像を用いた決済の許否を判定しても良い。つまり、顔パス決済の許否については、決済支援サーバ１４−２の側で行っても良いし、店舗端末１２−２の側で行っても良いし、両方で行っても良い。

決済手段制御部２２１は、例えば、「（Ｃ）顔写真評価度＜５０−α」の場合、利用者の顔写真画像を用いた決済を許可しないと判定しても良い。

決済手段制御部２２１は、例えば、「（Ａ）５０＋β＜顔写真評価度」の場合、利用者の顔写真画像を用いた決済を許可すると判定しても良い。

決済手段制御部２２１は、例えば、「（Ｂ）５０−α≦顔写真評価度≦５０＋β」の場合（つまり、顔写真評価度が所定の範囲内である場合）、利用者の顔写真画像及び確認コードを用いた決済を許可すると判定しても良い。そして、販売支援画面表示部６６−２は、当該（Ｂ）の判定の場合に、確認コード入力領域５０４を含む顔パス決済用ＧＵＩ５００を生成し、上記（Ａ）の判定の場合には、確認コード入力領域５０４を含まない顔パス決済用ＧＵＩ５００を生成しても良い。

決済手段制御部２２１は、顔パス決済用ＧＵＩ５００の決済決定ボタン５０７が決済の指示を受けた場合、決済の処理を要求する決済要求情報に、顔写真評価入力領域５０６から入力された顔写真画像の評価を含めて販売支援サーバ１４−２に送信する。

図２０は、顔パス決済用ＧＵＩ５００の一例を示す。当該顔パス決済用ＧＵＩ５００は、図１０の画面から決済対象の利用者が選択された後に表示される。

顔パス決済用ＧＵＩ５００は、合計金額表示領域５０１と、決済条件表示領域５０５と、顔写真表示領域５０２と、氏名表示領域５０３と、確認コード入力領域５０４と、顔写真評価入力領域５０６と、決済決定ボタン５０７と、を有する。

合計金額表示領域５０１には、利用者と店舗との間の当該決済の合計金額が表示される。

顔写真表示領域５０２には、図１０の画面から選択された利用者の顔写真画像５２２が表示される。

決済条件表示領域５０５には、決済の条件が表示される。例えば、クレジットカードで決済を行う場合、決済条件表示領域５０５には、クレジットカードのカード名及び有効期限と、支払い回数等が表示される。決済条件表示領域５０５には、決済条件を変更するための決済変更ボタン５１１が表示されても良い。

氏名表示領域５０３には、図１０の画面から選択された利用者の氏名が表示される。

確認コード入力領域５０４は、利用者から伝えられた確認コードを入力するための領域である。確認コードは、店員によって入力されても良いし、利用者によって入力されても良い。

顔写真評価領域５０６は、顔写真表示領域５０２に表示されている顔写真画像５２２の評価を入力するための領域である。この評価は、店員によって入力される。例えば、顔写真評価領域５０６には、「○」ボタンと、「△」ボタンと、「×」ボタンとが表示される。そして、店員は、決済時に利用者と顔写真表示領域５０２に表示されている顔写真画像５２２とを比較し、顔写真画像５２２に問題が無い場合には「○」ボタンを、顔写真画像５２２に多少の問題がある場合には「△」ボタンを、顔写真画像５２２に重大な問題がある場合には「×」ボタンをタッチする。例えば、「○」ボタンがタッチされた場合、顔写真評価Ｐを「１」とし、「△」ボタンがタッチされた場合、顔写真評価Ｐを「０．５」とし、「×」ボタンがタッチされた場合、顔写真評価Ｐを「０．１」としても良い。

顔写真画像５２２に多少の問題がある場合とは、例えば、顔写真画像５２２が不鮮明な場合、髪型が大きく異なっている場合、サングラス（めがね）の着脱が異なっている場合、顔写真画像５２２から推定される年齢と利用者本人から推定される年齢とが大きく乖離している場合等である。顔写真画像５２２に重大な問題がある場合とは、例えば、顔写真画像５２２が利用者本人であるとは思えない場合等である。

顔パス決済に応対する店員は、例えば、次の手続を行う。
（１）店員が、自己のＩＤ（決済応対店員ＩＤ）を店舗端末１２−２に入力し、顔パス決済を選択すると、店舗端末１２−２に図１０に示す画面が表示される。
（２）店員が、図１０に示す画面から利用者の氏名を選択すると、図２０に示す顔パス用ＧＵＩ５００が画面に表示される。
（３）店員は、利用者本人の顔と、顔パス用ＧＵＩ５００の顔写真表示領域５０２に表示されている顔写真画像５２２とを比較し、利用者が本人であることを確認する。
（４）店員は、利用者から伝えられた氏名と、氏名表示領域５０３に表示されている氏名とを比較し、本人であることを確認する。
（５）店員は、利用者から伝えられた確認コードを、確認コード入力領域５０４に入力し、本人であるか否かを店舗端末１２−２に判定させる。
（６）店員は、上記（３）〜（６）が何れも問題が無い場合、本人であると判断し、決済決定ボタン５０７をタッチする。

顔パス決済用ＧＵＩ５００は、顔画像有効度の高い利用者の場合（例えば、上記「（Ａ）５０＋β＜顔写真有効度」の場合）、確認コード入力領域５０４を表示しなくても良い。この場合、店員は、上記（５）の確認コードの入力を省略できるとしても良い。これにより、利用者は、確認コードを店員に伝える必要が無くなるため、より一層、お得意様としての満足感を得ることができる。また、店員は、確認コードを入力する手間を省くことができるため、決済に要する時間を短縮することができる。

顔パス決済用ＧＵＩ５００は、顔写真評価領域５０６において「△」又は「×」ボタンがタッチされた場合に確認コード入力領域５０４を表示し、「○」ボタンがタッチされた場合は確認コード入力領域５０４を表示しなくても良い。これにより、店員は、顔写真画像５２２から利用者が本人であるか否かを判定しにくい場合であっても、確認コードによって利用者が本人であるか否かを判定することができる。

顔パス決済用ＧＵＩ５００は、顔写真評価領域５０６のいずれかのボタンがタッチされるまで、決済決定ボタン５０７が反応しないようにしても良い。このとき、顔パス決済用ＧＵＩ５００は、決済決定ボタン５０７をグレーアウト表示しても良い。これにより、売買支援サーバ１４−２は、顔写真画像５２２の評価をより多く得ることができるので、顔写真有効度の精度を高めることができる。

顔パス決済用ＧＵＩ５００は、確認コード入力領域５０４に正しい確認コードが入力されるまで、決済決定ボタン５０７が反応しないようにしても良い。このとき、顔パス決済用ＧＵＩ５００は、決済決定ボタン５０７をグレーアウト表示しても良い。これにより、利用者が本人で無い場合に、店員が誤って決済を指示してしまう可能性を低減できる。

顔パス決済用ＧＵＩ５００は、顔写真評価領域５０６のいずれかのボタンがタッチされ、且つ、確認コード入力領域５０４に正しい確認コードが入力されるまで、決済決定ボタン５０７が反応しないようにしても良い。これにより、売買支援サーバ１４−２は、顔写真画像の評価をより多く得ることができるので、顔写真有効度の精度を高めることができる上、利用者が本人で無い場合に、店員が誤って決済してしまう可能性を低減できる。

図２０における顔写真評価領域５０６は、３つの評価用ボタンを有しているが、それ以外のボタン数で構成されても良い。例えば、顔写真評価領域５０６は、本人であると認識できた場合にタッチ（押下）される「○」ボタンと、本人であると認識できなかった場合にタッチされる「×」ボタンの２つの評価用ボタンで構成されても良い。例えば、顔写真評価領域５０６は、１つのボタンのみを有しており、そのボタンがタッチされた回数に応じて顔写真評価が入力されても良い。又は、顔写真評価領域５０６には、顔写真評価に対応する番号が表示されており、店員は、店舗端末１２−２に備えられている物理的なキーボードからその顔写真評価に対応する番号を入力するとしても良い。

例えば、顔写真評価領域５０６は、店員が、顔写真画像が不正に登録されたもの（例えば盗難されたもの等）であると判断した場合にタッチする「異常通報」ボタンを有しても良い。そして、この「異常通報」ボタンがタッチされた場合、決済手段制御部２２１は、顔パス決済を不許可とし、異常が発生した旨を売買支援サーバ１４−２に通知するようにしても良い。そして、売買支援サーバ１４−２は、その通知を受けて、その利用者に係る決済を一時的に凍結しても良い。

第２の実施の形態についての第１の変形例を説明する。
現在、電子決済の手段は多様化しており、例えば、クレジットカード決済に加え、プリペイドカード決済、デビットカード決済、通信キャリア一括決済、送金サービス等が存在する。本変形例では、電子決済の多様な手段に対応した顔パス決済を実現することにより、利用者の利便性を一層高める商品売買システム１００を提案する。

利用者は、自身で使用可能な複数の決済手段について、各決済手段を用いた決済に必要な情報（以下、「決済必要情報」と呼ぶ。）を購入者端末１０へ入力する。購入者端末１０の利用者情報登録部３４は、入力情報を売買支援サーバ１４−２へ送信し、売買支援サーバ１４−２は、利用者が使用可能な複数の決済手段それぞれの決済必要情報を利用者情報保持部１１１−２に記憶する。

また利用者は、各決済手段による決済順序を示す情報（以下、「決済順序情報」と呼ぶ。）を購入者端末１０へ入力する。購入者端末１０の利用者情報登録部３４は、入力情報を売買支援サーバ１４−２へ送信し、売買支援サーバ１４−２は、利用者が入力した決済順序情報を利用者情報保持部１１１−２に記憶する。売買支援サーバ１４−２の決済処理部１３２は、上記実施の形態と同様に、決済許否判定部１３０−２により決済の実行が許可されたことを条件として、購入代金の電子決済を支援するための以下の処理を実行する。

決済処理部１３２は、利用者情報保持部１１１−２に記憶された電子決済を行うべき利用者の決済順序情報を参照し、決済順序情報が定める順序で電子決済の依頼（使用する決済手段の決済必要情報を設定した電文）を、各決済手段に対応する所定の決済サーバ１６へ送信する。例えば、プリペイドカード決済→デビットカード決済→クレジットカード決済という順序が登録されていれば、決済処理部１３２は、まずプリペイドカード決済を試みる。購入金額がプリペイドカードのチャージ金額を超過していれば、次にデビットカード決済を試みる。デビットカード決済に用いる口座の残高が不足していれば、次にクレジットカード決済を試みる。

この変形例によると、利用者が使用可能な複数の決済手段による電子決済を、利用者が所望する順序で実行できる。また極力、電子決済を成功させるよう制御することで、口座残高不足等に起因する電子決済の失敗を抑制し、利用者の利便性を向上させる。

なお、個々の決済手段の中でも複数の決済方法が存在する場合がある。例えば、デビットカード決済であれば、銀行Ａに開設した口座、銀行Ｂに開設した口座をそれぞれ選択することができる。このような場合に、利用者は、個々の決済手段内での決済順序、例えばデビットカード決済における複数の保有口座の選択順序を含む決済順序情報を購入者端末１０に入力する。売買支援サーバ１４−２の利用者情報保持部１１１−２は、個々の決済手段内での決済順序を含む決済順序情報を記憶する。売買支援サーバ１４−２の決済処理部１３２は、決済順序情報が定める順序で決済手段を順次選択し、さらに個々の決済手段内での決済方法を決済順序情報にしたがって順次選択する。そして、決済順序情報に則した決済手段に対応する決済サーバ１６に対して、その決済手段における決済方法を指定する（例えば購入代金を引き落とすべき口座を指定する）決済必要情報を設定した電文を送信する。

第２の実施の形態についての第２の変形例を説明する。
実施の形態で提案した顔パス決済は、来訪予定店舗に対するチェックイン操作をユーザに実施してもらう必要がある。言い換えれば、来店前のチェックインという付加的なオペレーションをユーザに課す。そこで顔パス決済のビジネスを普及させるために、チェックインをユーザに「使ってもらう」ものとするため、本変形例では、チェックインにインセンティブや利便性を用意する技術を提案する。なお、下記の１）から７）は、それらの全てもしくは一部を任意に組み合わせてよいことはもちろんである。

１）クーポンを選択したチェックイン：
利用者は、チェックイン時に、店舗で利用したいクーポンを予め選択する。利用者により選択されたクーポンの情報は店舗側へ通知され、店舗での顔パス決済時に、利用者がチェックインにおいて選択したクーポンを自動適用した会計金額にて決済を実行する。

システム構成の一例を説明する。売買支援サーバ１４−２の店舗情報保持部１１２には、各店舗が利用者へ提供する１つ以上のクーポンの情報が予め格納される。購入者端末１０は、店舗詳細画面１４０を表示するべき際に、店舗情報とともにクーポン情報を売買支援サーバ１４−２から取得し、クーポン情報を店舗詳細画面１４０に表示させる。店舗詳細画面１４０において、利用者は、所望のクーポンを選択した上でチェックイン操作を実施する。

続いて購入者端末１０は、売買支援サーバ１４−２へ送信するチェックイン情報に、利用者が選択したクーポンを示す情報（以下、「選択クーポン情報」と呼ぶ。）を付加する。売買支援サーバ１４−２は、チェックイン先店舗の店舗端末１２へ、利用者の顔写真とともに選択クーポン情報（割引額を含む）を送信する。店舗端末１２は、選択クーポン情報を顔パス決済用ＧＵＩ５００で表示させる。また店舗端末１２は、商品やサービスの元の販売価格から、選択クーポン情報が示す割引額を差し引いた金額を会計金額として決定して、顔パス決済用ＧＵＩ５００に表示させる。決済実行時、店舗端末１２は、割引後の会計金額を指定した決済要求を売買支援サーバ１４−２へ送信して電子決済を実行させる。

２）クーポン発行：
チェックイン時や、初回来店時、来店回数１０回目等、予め定められたイベントが発生したタイミングでクーポンを発行する。顔パスによる支払時に、事前のチェックイン時に発行されたクーポンが自動適用された会計金額にて決済を実行する。

システム構成の一例として、上記１)に類似する構成であってもよい。ただし、売買支援サーバ１４−２は、第１の実施形態についての第５の変形例で記載したチェックイン履歴と、第１位の実施形態についての第１０の変形例で記載した決済履歴を保持する。さらに、クーポンを発行すべきタイミングか否かを判定するための基準であり、言い換えれば、クーポン発行イベントを実行すべき条件（以下、「クーポン発行条件」と呼ぶ。）を保持する。売買支援サーバ１４−２は、購入者端末１０からチェックイン情報を受け付けた場合に、利用者のチェックイン履歴と決済履歴を参照し、クーポン発行条件が充足されたか否かを判定する。クーポン発行条件が充足された場合、売買支援サーバ１４−２は、店舗情報とともにクーポン情報を購入者端末１０へ提供し、購入者端末１０は、クーポン情報を店舗詳細画面１４０に表示させる。以降の処理は、上記１)と同じである。

３）時限クーポン：
チェックイン時に、利用者の来店を促進する目的で、所定の有効期間（例えば１時間等）を設定した時限クーポンを発行する。顔パスによる支払時に、事前のチェックイン時に発行された時限クーポンが、その有効期限に応じて自動適用された会計金額にて決済を実行する。

システム構成の一例として、上記１)に類似する構成であってもよい。ただし、売買支援サーバ１４−２が保持し、購入者端末１０および店舗端末１２へ提供されるクーポンは時限クーポンであり、すなわちそのクーポン情報には、チェックインから１時間等の有効期間を示すデータが含まれる。購入者端末１０は、クーポン情報としてクーポンの有効期間も表示させて利用者へ提示する。また売買支援サーバ１４−２は、利用者の顔写真、クーポン情報とともに利用者のチェックイン時刻を店舗端末１２へ提供する。店舗端末１２は、利用者のチェックイン時刻から会計時刻（例えば現在時刻）までの時間にもとづいて、時限クーポンが有効か否かを判定する。有効期間が途過してなければ、言い換えれば、会計タイミングが時限クーポンの有効期間内であれば、店舗端末１２は、商品やサービスの元の販売価格から、時限クーポンが示す割引額を差し引いた金額を会計金額として決定する。

４）コメントを付加したチェックイン：
来店前に予め店員に伝えておきたい事項などの情報（以下、「コメント」と呼ぶ。）をコメント欄に入力してからチェックインを実施する。このコメントは店舗側へ通知される。店員はチェックイン者の顔写真とともにコメントを確認して、お客様のおもてなしの準備を予め実施できる。例えば、利用者の購買履歴等を確認して、今回お勧めする商品を予め見繕うことができる。また、コメントで指定された利用者の所望の商品を店頭に並べ、また、その商品情報を調べておく等の準備ができる。

システム構成の一例を説明する。購入者端末１０は、利用者が任意のコメントを入力可能なコメント欄を設けた店舗詳細画面１４０を表示させる。コメントの文字数には制限を設けてもよく、例えば、入力可能な文字数を最大１００字にするようコメント欄を設定してもよい。購入者端末１０は、コメント欄に入力されたコメントを含むチェックイン情報を売買支援サーバ１４へ送信し、売買支援サーバ１４−２は、そのコメントを含む店舗用チェックイン情報を店舗端末１２へ送信する。店舗端末１２の販売支援画面表示部６６は、販売支援画面としてデフォルト表示される初期画面（例えばメニュー選択画面）に、自店舗にチェックイン済みの利用者の氏名および顔写真を表示し、さらに各利用者に対応づけて（例えば利用者の顔写真の近傍位置に）利用者がチェックイン時に入力したコメントを表示させる。

５）来店目的を選択してチェックイン：
利用者は、今回の来店目的を予め選択してからチェックインする。来店目的を示す情報（以下、「来店目的情報」と呼ぶ。）は店舗側へ通知され、店舗端末１２は、チェックイン者の氏名、顔写真とともに来店目的を表示する。これにより店員は、利用者の目的を事前に把握した上で、来店した利用者へ適切な声掛けや、商品紹介を実施できる。また、来店目的が例えば「１人で商品を閲覧したい」であれば、利用者への声掛けをあえて抑制し、利用者に自由に商品を閲覧させるよう配慮することもできる。

この変形例の商品売買システム１００の構成は上記４)に類似する。購入者端末１０の店舗詳細画面１４０に、コメント欄に代えて来店目的の選択欄を設ける。そして、利用者による選択内容をチェックイン情報に付加し、店舗端末１２まで伝達する。

６）店員の顔写真付き応答：
利用者がチェックインしたタイミングで、チェックイン先の店員の顔写真付きの応答メッセージを利用者へ提示する。６−１）チェックインの都度、店員がコメントを作成して返信してもよく、６−２）固定文言を返信してもよい。利用者と店舗店員のコミュニケーションを支援して、利用者の来店を促進できる。

まず、上記６−２)のシステム構成例を説明する。売買支援サーバ１４−２は、店舗が予め登録した店員の顔写真と、固定の応答コメントを店舗情報保持部１１２に保持する。売買支援サーバ１４は、購入者端末１０からチェックインを受け付けた場合に、その応答として、チェックイン先の店舗に対応づけられた店員の顔写真と応答コメントを店舗情報保持部１１２から取得して購入者端末１０へ提供する。購入者端末１０は、チェックイン先の店員の顔写真と応答コメントを表示させる。なお、売買支援サーバ１４−２は、乱数列のデータとともに、店員の顔写真と応答コメントを購入者端末１０へ提供してもよい。購入者端末１０は、チェックイン画面１５０に、確認コードともに、店員の顔写真と応答コメントを表示させてもよい。

次に、上記６−１）のシステム構成例を説明する。店舗端末１２は、自店舗へチェックインした利用者に対する応答コメントを入力するコメント入力欄を設けたコメント入力画面を表示させる。店員は、コメント入力画面のコメント入力欄に、利用者に応じた応答コメントを入力する。応答コメントは例えば、「○○様へのお勧めの商品として△△を用意しています」等である。店舗端末１２は、応答コメントを売買支援サーバ１４−２へ送信し、売買支援サーバ１４−２は、その応答コメントを、店舗が予め登録した店員の顔写真とともに購入者端末１０へ送信する。購入者端末１０は、チェックイン後の所定の画面に、チェックイン先の店員の顔写真と応答コメントを表示させる。

７）カードやメダルの取得
チェックインしたタイミングで、例えば有名タレントグループのカードをランダムに発行する。取得したカードやメダルはホルダに保管できる。

システム構成の一例を説明する。売買支援サーバ１４−２は、カードやメダル、所定のプレミアム画像等の、チェックイン特典情報を予め保持する。売買支援サーバ１４−２は、購入者端末１０からチェックイン情報を受信すると、チェックイン特典情報を購入者端末１０へ送信する。乱数列のデータとともにチェックイン特典情報を購入者端末１０へ送信してもよい。購入者端末１０は、売買支援サーバ１４−２から提供されたチェックイン特典情報を画面に表示させる。また利用者の操作に応じて、チェックイン特典情報をローカルの記憶領域に永続的に記憶させる。

第２の実施の形態についての第３の変形例を説明する。
実施の形態で示したように、顔パス決済のためのチェックインは、利用者が来店したい店舗のページにて手動でチェックイン操作を実施することを基本とする。本変形例では、利用者の利便性を一層高めるために、ＩＣＴ技術によりチェックインをサポートする技術を提案する。なお、以下の１）から３）のいずれにもついても、決済時の確認コードの確認（照合）は必要である。また１）から３）の任意の組み合わせが可能である。

１）オートチェックイン：
購入者端末１０においてオートチェックイン機能およびＧＰＳ機能をオンにしておくことで、利用者が店舗近傍に来たときに自動的に店舗へチェックインする。すなわち購入者端末１０の現在位置に応じて自動チェックインを実行する。このシステム構成例は、第１の実施形態における第３の変形例として既述であるため省略する。

２）決まった時間にチェックイン：
曜日や時間指定で自動的にチェックインを実行する。このシステム構成例は、第１の実施形態における第３の変形例に類似する。購入者端末１０は、利用者が予め購入者端末１０に登録した日時に至ったことを検出すると、利用者が予め購入者端末１０に登録した店舗に対して、第１の実施形態における第３の変形例に記載した自動チェックイン処理を実行する。

３）チェックイン高速化：
既述したように、実施の形態では、ログイン画面、サービス事業者選択画面、店舗選択画面を表示後に、チェックイン操作を実施する店舗詳細画面を表示させることとした。本変形例では、手動によるチェックインを前提としつつも、利用者のオペレーション数を低減するための技術を提案する。具体的には、「お気に入り」からダイレクトにチェックインページへ遷移させる。

システム構成の一例を説明する。購入者端末１０は、お気に入り画面保持部とお気に入り登録部をさらに備える。特定の店舗の情報を提示してその店舗へのチェックイン操作を受け付ける店舗詳細画面を、お気に入り画面とする旨の登録操作を利用者が入力すると、お気に入り登録部は、その店舗詳細画面のデータをお気に入り画面保持部へ格納する。利用者が購入者端末１０のお気に入り選択画面において特定の店舗名称を選択すると、購入支援画面表示部３６は、店舗選択画面等、前段の画面の表示をスキップして、お気に入り画面保持部に記憶された店舗詳細画面のうち、選択された店舗名称に対応する店舗詳細画面をタッチパネル２０に表示させる。なお、店舗詳細画面がウェブページとして売買支援サーバ１４−２から提供される場合、お気に入り登録部は、購入者端末１０にインストールされたウェブブラウザのお気に入り機能に、利用者が指定する店舗詳細画面のページを登録してもよいことはもちろんである。

（第３の実施形態）
第３の実施の形態では、販売者の店舗が移動販売車等による移動販売店舗（例えば「移動スーパーマーケット」）である場合に、第１および第２の実施の形態で提案した顔パス決済を適用する商品売買システム１００を提案する。

第３の実施の形態では、第１および第２の実施の形態における販売者店舗へのチェックイン操作が、販売者店舗に対して所望の地域へ来訪するよう指示するための来訪指示操作に置き換わる。具体的には、購入者端末１０の所定画面（例えば店舗詳細画面１４０）における来訪指示操作の入力に伴い、購入者端末１０は、その来訪指示を示す来訪指示情報を売買支援サーバ１４へ送信する。売買支援サーバ１４（１４−２）は、利用者の顔写真に加えて来訪指示情報を店舗端末１２へ送信する。

来訪指示情報の構成は、第１および第２の実施の形態の店舗用チェックイン情報と同様であるが、販売者店舗が来訪すべき地域および日時を示す情報を含む。来訪指示情報で指定される来訪地域は生活者の生活地域であってもよい。例えば、利用者の住所の近傍地域であってもよく、利用者の職場の近傍地域であってもよく、利用者にとって商品購入に都合のよい地域でよい。これにより販売者は、店舗端末１２において利用者の顔写真とともに、訪問先と訪問日時を認識することができる。

利用者は、来訪指示操作の入力画面（例えば店舗詳細画面１４０）で、販売者店舗の来訪を指示する地域と日時を都度指定してもよい。また来訪地域については、利用者登録等のタイミングで、移動販売店舗に対する訪問希望地域を売買支援サーバ１４に登録し、売買支援サーバ１４（１４−２）の利用者情報保持部１１１（１１１−２）が記憶してもよい。また、販売者店舗が訪問可能な地域や日時が予め定められてもよく、購入者端末１０の店舗詳細画面１４０において選択可能に表示されてもよい。利用者は、自身に都合のよい地域と日時を選択しつつ、所望の販売者店舗（移動販売店舗）に対する来訪指示操作を入力してもよい。

第３の実施の形態の商品売買システム１００の他の構成は、第１または第２の実施の形態の商品売買システム１００と同様である。例えば、第１の実施の形態で説明した確認コードの照合処理と組み合わせることにより、セキュリティの強度を一層高めてもよい。第３の実施の形態によると、購入者が移動販売店舗において商品を購入する場合も、言い換えれば、販売者店舗が移動販売店舗である場合も顔パス決済を実現できる。例えば、過疎化地域に対する移動販売車による商品販売サービスに対しても、顔パス決済の利便性を提供できる。
第３の実施の形態の技術思想は、以下に付記する構成として表現することもできる。

（付記１）
商品の購入者が用いる購入者端末と、
商品の販売者が用いる販売者端末と、
通信網を介して前記購入者端末および前記販売者端末と接続されるサーバと、
を備え、
販売者の店舗は移動販売店舗であり、
前記購入者端末は、
販売者の店舗が所望の地域へ来訪するよう指示するための来訪指示操作を購入者から受け付ける受付部を含み、
前記サーバは、
購入者が商品代金を電子決済するために必要な情報である決済情報を保持する決済情報保持部と、
前記購入者端末において前記来訪指示操作がなされた場合に、購入者を識別するための購入者識別情報を前記販売者端末へ提供する購入者情報提供部を含み、
前記販売者端末は、
販売者の店舗にて購入者が商品を購入する際に、前記サーバから通知された購入者識別情報の中から、商品を購入する購入者の情報を販売者に選択させるための選択画面を表示させる選択画面表示部と、
前記選択画面において選択された購入者を指定した決済要求を前記サーバへ通知する決済要求通知部と、を含み、
前記サーバは、前記決済要求で指定された購入者の決済情報を使用して、商品代金の電子決済を実行させる決済処理部をさらに含むことを特徴とする情報処理システム。

上述した本発明の実施形態は、本発明の説明のための例示であり、本発明の範囲をそれらの実施形態にのみ限定する趣旨ではない。当業者は、本発明の要旨を逸脱することなしに、他の様々な態様で本発明を実施することができる。

１０…購入者端末 １２…店舗端末、 １４、１４−２…売買支援サーバ、 ３６…購入支援画面表示部 ３８…サービス情報取得部、 ４０…チェックイン通知部 ４２…ワンタイムコード生成部 ６６、６６−２…販売支援画面表示部 ７０…チェックイン情報更新部 ７２…ワンタイムコード取得部 ７４…決済要求通知部 １００…商品売買システム １２０…チェックイン受付部 １２２…乱数取得部 １２４…乱数提供部 １２６…チェックイン情報提供部 １２８、１２８−２…決済要求受付部 １３０、１３０−２…決済許否判定部 １３２…決済処理部 ２０１…顔写真有効度算出部 ２０２…顔写真有効期限変更部 ２０３…顔パス決済判定部 ２２１…決済手段制御部

Claims (6)

1. 利用者の顔写真画像を含む利用者情報を保持する記憶部と、
   複数の利用者の中から選択された一の利用者の顔写真画像を表示する顔写真表示領域と、前記一の利用者の顔写真画像に対する応答を受け付ける応答入力領域と、前記顔写真表示領域に表示されている顔写真画像に係る利用者に関する決済の指示を受け付ける決済指示領域と、を含む決済用ＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）を表示する表示部と、
   前記応答入力領域が受け付けた応答、及び前記決済指示領域が受け付けた決済の指示に応じた出力をする出力部と
   を有する決済用端末装置。
   
2. 前記決済用ＧＵＩにおいて、
   前記応答入力領域が応答を受け付けた後、前記決済指示領域が、前記決済の指示を受け付け可能となる
   請求項１に記載の決済用端末装置。
   
3. 前記利用者情報は、前記顔写真画像に対する評価指標を含み、
   前記表示部に表示される決済用ＧＵＩは、前記評価指標に応じた表示態様で表示される
   請求項１又は２に記載の決済用端末装置。
   
4. 前記一の利用者の顔写真画像に対する評価指標に応じて、前記利用者の決済の許否を判定する決済判定部、をさらに有する
   請求項３に記載の決済用端末装置。
   
5. 前記決済判定部は、前記評価指標が所定の範囲内である場合、前記利用者に予め知らされている確認コードを用いた決済を許可し、
   前記決済判定部が前記確認コードを用いた決済を許可した場合、前記決済用ＧＵＩは、前記確認コードの入力を受け付ける確認コード入力領域をさらに有する
   請求項４に記載の決済用端末装置。
   
6. 前記決済指示領域が決済の指示を受け付けた場合、決済の要求に関する情報であって、前記応答入力領域から入力された前記顔写真画像に対する応答を含む決済要求情報を、サーバに送信する送信部と、
   前記顔写真画像に対する評価指標を含む利用者情報を、前記サーバから受信する受信部と、をさらに有する
   請求項３乃至５の何れか一項に記載の決済用端末装置。
   
   
   

Images