(57)【要約】【課題】サービス購入者の利便性を効果的に高める。【解決手段】購入者端末１０において販売者の店舗に対するチェックイン操作がなされると、売買支援サーバ１４は、購入者の顔写真を店舗端末１２へ提供する。店舗にて購入者がサービスを購入する際、店舗端末１２は、購入者の顔写真を販売者に選択させ、顔写真が選択された購入者を指定した決済要求を売買支援サーバ１４へ通知する。売買支援サーバ１４は、購入者による登録情報を使用して、サービス代金の電子決済を実行させる。売買支援サーバ１４は、販売者の店舗における実際のサービス提供状況を店舗端末１２から取得し、取得した情報にもとづいて店舗における待ち時間を推定し、購入者によるチェックイン操作の際に待ち時間の推定値を購入者端末１０へ提供する。【選択図】図１２
2014178770.tif 000002
【特許請求の範囲】
【請求項１】
サービスの購入者が用いる購入者端末と、
サービスの販売者が用いる販売者端末と、
通信網を介して前記購入者端末および前記販売者端末と接続されるサーバと、
を備え、
前記購入者端末は、
販売者の店舗への来訪予定を示す所定のチェックイン操作を購入者から受け付ける受付部を含み、
前記サーバは、
購入者がサービス代金を電子決済するために必要な情報である決済情報を保持する決済情報保持部と、
前記購入者端末において前記チェックイン操作がなされた場合に、購入者を識別するための購入者識別情報を前記販売者端末へ提供する購入者情報提供部を含み、
前記販売者端末は、
販売者の店舗にて購入者がサービスを購入する際に、前記サーバから通知された購入者識別情報の中から、サービスを購入する購入者の情報を販売者に選択させるための選択画面を表示させる選択画面表示部と、
前記選択画面において選択された購入者を指定した決済要求を前記サーバへ通知する決済要求通知部と、を含み、
前記サーバは、前記決済要求で指定された購入者の決済情報を使用して、サービス代金の電子決済を実行させる決済処理部をさらに含み、
前記販売者端末は、販売者の店舗において各購入者に対してサービスの提供を開始した時刻を前記サーバへ通知するサービス状況通知部をさらに含み、
前記サーバは、
販売者の店舗に対して過去チェックイン操作を行った購入者について、そのチェックイン操作に関する時刻と、販売者の店舗におけるサービス提供開始時刻にもとづいて、チェックイン操作から店舗におけるサービス開始までの待ち時間を推定する待ち時間推定部と、
前記購入者端末においてチェックイン操作がなされた場合に、前記待ち時間推定部が推定した待ち時間を示す情報を前記購入者端末へ通知する待ち時間通知部と、をさらに含むことを特徴とする情報処理システム。
【請求項２】
サービスの購入者が用いる購入者端末と、
サービスの販売者が用いる販売者端末と、
通信網を介して前記購入者端末および前記販売者端末と接続されるサーバと、
を備え、
前記購入者端末は、
販売者の店舗への来訪予定を示す所定のチェックイン操作を購入者から受け付ける受付部を含み、
前記サーバは、
購入者がサービス代金を電子決済するために必要な情報である決済情報を保持する決済情報保持部と、
前記購入者端末において前記チェックイン操作がなされた場合に、購入者を識別するための購入者識別情報を前記販売者端末へ提供する購入者情報提供部を含み、
前記販売者端末は、
販売者の店舗にて購入者がサービスを購入する際に、前記サーバから通知された購入者識別情報の中から、サービスを購入する購入者の情報を販売者に選択させるための選択画面を表示させる選択画面表示部と、
前記選択画面において選択された購入者を指定した決済要求を前記サーバへ通知する決済要求通知部と、を含み、
前記サーバは、前記決済要求で指定された購入者の決済情報を使用して、サービス代金の電子決済を実行させる決済処理部をさらに含み、
前記販売者端末は、販売者の店舗において各購入者に対してサービスの提供を開始してから終了するまでのサービス時間に関する情報を前記サーバへ通知するサービス状況通知部をさらに含み、
前記サーバは、
１人以上の購入者による販売者の店舗に対するチェックイン操作の受け付け状況にもとづいて購入者の到着率を推定し、その到着率と前記販売者端末から通知されたサービス時間に関する情報にもとづいて、チェックイン操作から店舗におけるサービス開始までの待ち時間を推定する待ち時間推定部と、
前記購入者端末においてチェックイン操作がなされた場合に、前記待ち時間推定部が推定した待ち時間を示す情報を前記購入者端末へ通知する待ち時間通知部と、をさらに含むことを特徴とする情報処理システム。
【請求項３】
前記サーバの待ち時間推定部は、同一のグループに対応づけられた複数の店舗のそれぞれについて、チェックイン操作からサービス開始までの待ち時間を推定し、
前記サーバの待ち時間通知部は、前記購入者端末においてあるグループに属する店舗に対するチェックイン操作がなされた場合に、そのグループに属する複数の店舗それぞれについて推定された待ち時間を前記購入者端末へ通知することを特徴とする請求項１または２に記載の情報処理システム。
【請求項４】
サービスの購入者が用いる購入者端末と、サービスの販売者が用いる販売者端末と、通信網を介して前記購入者端末および前記販売者端末と接続されるサーバと、が実行する方法であって、
前記購入者端末が、販売者の店舗への来訪予定を示す所定のチェックイン操作を購入者から受け付けるステップと、
前記サーバが、前記購入者端末において前記チェックイン操作がなされた場合に、購入者を識別するための購入者識別情報を前記販売者端末へ提供するステップと、
前記販売者端末が、販売者の店舗にて購入者がサービスを購入する際に、前記サーバから通知された購入者識別情報の中から、サービスを購入する購入者の情報を販売者に選択させるための選択画面を表示させるステップと、
前記販売者端末が、前記選択画面において選択された購入者を指定した決済要求を前記サーバへ通知するステップと、
前記サーバが、所定の記憶領域に保持された、各購入者がサービス代金を電子決済するために必要な情報である決済情報のうち前記決済要求で指定された購入者の決済情報を使用して、サービス代金の電子決済を実行させるステップと、
を備え、
前記販売者端末または前記サーバが、
販売者の店舗において各購入者に対してサービスの提供を開始した時刻を記憶するステップと、
販売者の店舗に対して過去チェックイン操作を行った購入者について、そのチェックイン操作に関する時刻と、販売者の店舗におけるサービス提供開始時刻にもとづいて、チェックイン操作から店舗におけるサービス開始までの待ち時間を推定するステップと、
前記購入者端末においてチェックイン操作がなされた場合に、前記推定するステップにおいて推定した待ち時間を示す情報を前記購入者端末へ通知するステップと、
をさらに実行することを特徴とする情報処理方法。
【請求項５】
サービスの購入者が用いる購入者端末と、サービスの販売者が用いる販売者端末と、通信網を介して前記購入者端末および前記販売者端末と接続されるサーバと、が実行する方法であって、
前記購入者端末が、販売者の店舗への来訪予定を示す所定のチェックイン操作を購入者から受け付けるステップと、
前記サーバが、前記購入者端末において前記チェックイン操作がなされた場合に、購入者を識別するための購入者識別情報を前記販売者端末へ提供するステップと、
前記販売者端末が、販売者の店舗にて購入者がサービスを購入する際に、前記サーバから通知された購入者識別情報の中から、サービスを購入する購入者の情報を販売者に選択させるための選択画面を表示させるステップと、
前記販売者端末が、前記選択画面において選択された購入者を指定した決済要求を前記サーバへ通知するステップと、
前記サーバが、所定の記憶領域に保持された、各購入者がサービス代金を電子決済するために必要な情報である決済情報のうち前記決済要求で指定された購入者の決済情報を使用して、サービス代金の電子決済を実行させるステップと、
を備え、
前記販売者端末または前記サーバが、
販売者の店舗において各購入者に対してサービスの提供を開始してから終了するまでのサービス時間に関する情報を記憶するステップと、
１人以上の購入者による販売者の店舗に対するチェックイン操作の受け付け状況にもとづいて購入者の到着率を推定し、その到着率と前記サービス時間に関する情報にもとづいて、チェックイン操作から店舗におけるサービス開始までの待ち時間を推定するステップと、
前記購入者端末においてチェックイン操作がなされた場合に、前記推定するステップにおいて推定した待ち時間を示す情報を前記購入者端末へ通知するステップと、
をさらに実行することを特徴とする情報処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はデータ処理技術に関し、特にサービスの売買を支援するための情報処理技術に関する。
【背景技術】
【０００２】
スマートフォンやタブレット端末の急速な普及は、決済の分野においても大きな影響を与えている。近年、スマートフォンやタブレット端末をクレジットカード決済端末へ応用するソリューションも登場してきている。
【０００３】
また同様の端末を活用して、ユーザの「顔（写真）」と「名前」を利用したクレジットカード決済サービスも登場してきている。このサービスでは、ユーザの端末にて実在する店舗を指定する操作を行なうと、ユーザの情報が店舗側へ通知され、ユーザの顔写真と名前が店舗端末に表示される。その後、ユーザが実際に来店して商品を購入する際に、ユーザの「顔」と「名前」の確認をもって決済を完了させるという手法である。
【先行技術文献】
【非特許文献】
【０００４】
【非特許文献１】Ｓｑｕａｒｅ，  Ｉｎｃ．、“Square Wallet”、[online]、[平成２５年２月２５日検索］、インターネット＜URL:https://squareup.com/wallet＞
【発明の概要】
【発明が解決しようとする課題】
【０００５】
飲食店や病院等において、サービスを購入しようとするサービス利用者が、サービスを受けるために順番待ちをする待ち行列をつくることがある。一般的に待ち行列が長い場合、いつまで待てばよいのか判らないことに対するストレスや、待ち時間の長さが判らないため待ち時間の有効活用が困難なことに対するストレス等、サービス購入者に不満やストレスを感じさせてしまい、また、サービスの販売者にとってもサービス販売の機会損失を生じさせてしまうことがあると本発明者は認識した。
【０００６】
本発明は上記課題を鑑みてなされたものであり、その主な目的は、サービス購入者の利便性を効果的に高めるための技術を提供することにある。
【課題を解決するための手段】
【０００７】
上記課題を解決するために、本発明のある態様の情報処理システムは、サービスの購入者が用いる購入者端末と、サービスの販売者が用いる販売者端末と、通信網を介して購入者端末および販売者端末と接続されるサーバと、を備える。購入者端末は、販売者の店舗への来訪予定を示す所定のチェックイン操作を購入者から受け付ける受付部を含む。サーバは、購入者がサービス代金を電子決済するために必要な情報である決済情報を保持する決済情報保持部と、購入者端末においてチェックイン操作がなされた場合に、購入者を識別するための購入者識別情報を販売者端末へ提供する購入者情報提供部を含む。販売者端末は、販売者の店舗にて購入者がサービスを購入する際に、サーバから通知された購入者識別情報の中から、サービスを購入する購入者の情報を販売者に選択させるための選択画面を表示させる選択画面表示部と、選択画面において選択された購入者を指定した決済要求をサーバへ通知する決済要求通知部と、を含む。サーバは、決済要求で指定された購入者の決済情報を使用して、サービス代金の電子決済を実行させる決済処理部をさらに含む。販売者端末は、販売者の店舗において各購入者に対してサービスの提供を開始した時刻をサーバへ通知するサービス状況通知部をさらに含む。サーバは、販売者の店舗に対して過去チェックイン操作を行った購入者について、そのチェックイン操作に関する時刻と、販売者の店舗におけるサービス提供開始時刻にもとづいて、チェックイン操作から店舗におけるサービス開始までの待ち時間を推定する待ち時間推定部と、購入者端末においてチェックイン操作がなされた場合に、待ち時間推定部が推定した待ち時間を示す情報を購入者端末へ通知する待ち時間通知部と、をさらに含む。
【０００８】
本発明の別の態様もまた、情報処理システムである。この情報処理システムは、サービスの購入者が用いる購入者端末と、サービスの販売者が用いる販売者端末と、通信網を介して購入者端末および販売者端末と接続されるサーバと、を備える。購入者端末は、販売者の店舗への来訪予定を示す所定のチェックイン操作を購入者から受け付ける受付部を含む。サーバは、購入者がサービス代金を電子決済するために必要な情報である決済情報を保持する決済情報保持部と、購入者端末においてチェックイン操作がなされた場合に、購入者を識別するための購入者識別情報を販売者端末へ提供する購入者情報提供部を含む。販売者端末は、販売者の店舗にて購入者がサービスを購入する際に、サーバから通知された購入者識別情報の中から、サービスを購入する購入者の情報を販売者に選択させるための選択画面を表示させる選択画面表示部と、選択画面において選択された購入者を指定した決済要求をサーバへ通知する決済要求通知部と、を含む。サーバは、決済要求で指定された購入者の決済情報を使用して、サービス代金の電子決済を実行させる決済処理部をさらに含む。販売者端末は、販売者の店舗において各購入者に対してサービスの提供を開始してから終了するまでのサービス時間に関する情報をサーバへ通知するサービス状況通知部をさらに含む。サーバは、１人以上の購入者による販売者の店舗に対するチェックイン操作の受け付け状況にもとづいて購入者の到着率を推定し、その到着率と販売者端末から通知されたサービス時間に関する情報にもとづいて、チェックイン操作から店舗におけるサービス開始までの待ち時間を推定する待ち時間推定部と、購入者端末においてチェックイン操作がなされた場合に、待ち時間推定部が推定した待ち時間を示す情報を購入者端末へ通知する待ち時間通知部と、をさらに含む。
【０００９】
本発明のさらに別の態様は、情報処理方法である。この方法は、サービスの購入者が用いる購入者端末と、サービスの販売者が用いる販売者端末と、通信網を介して購入者端末および販売者端末と接続されるサーバと、が実行する方法であって、購入者端末が、販売者の店舗への来訪予定を示す所定のチェックイン操作を購入者から受け付けるステップと、サーバが、購入者端末においてチェックイン操作がなされた場合に、購入者を識別するための購入者識別情報を販売者端末へ提供するステップと、販売者端末が、販売者の店舗にて購入者がサービスを購入する際に、サーバから通知された購入者識別情報の中から、サービスを購入する購入者の情報を販売者に選択させるための選択画面を表示させるステップと、販売者端末が、選択画面において選択された購入者を指定した決済要求をサーバへ通知するステップと、サーバが、所定の記憶領域に保持された、各購入者がサービス代金を電子決済するために必要な情報である決済情報のうち決済要求で指定された購入者の決済情報を使用して、サービス代金の電子決済を実行させるステップと、を備える。販売者端末またはサーバが、販売者の店舗において各購入者に対してサービスの提供を開始した時刻を記憶するステップと、販売者の店舗に対して過去チェックイン操作を行った購入者について、そのチェックイン操作に関する時刻と、販売者の店舗におけるサービス提供開始時刻にもとづいて、チェックイン操作から店舗におけるサービス開始までの待ち時間を推定するステップと、購入者端末においてチェックイン操作がなされた場合に、推定するステップにおいて推定した待ち時間を示す情報を購入者端末へ通知するステップと、をさらに実行する。
【００１０】
本発明のさらに別の態様もまた、情報処理方法である。この方法は、サービスの購入者が用いる購入者端末と、サービスの販売者が用いる販売者端末と、通信網を介して購入者端末および販売者端末と接続されるサーバと、が実行する方法であって、購入者端末が、販売者の店舗への来訪予定を示す所定のチェックイン操作を購入者から受け付けるステップと、サーバが、購入者端末においてチェックイン操作がなされた場合に、購入者を識別するための購入者識別情報を販売者端末へ提供するステップと、販売者端末が、販売者の店舗にて購入者がサービスを購入する際に、サーバから通知された購入者識別情報の中から、サービスを購入する購入者の情報を販売者に選択させるための選択画面を表示させるステップと、販売者端末が、選択画面において選択された購入者を指定した決済要求をサーバへ通知するステップと、サーバが、所定の記憶領域に保持された、各購入者がサービス代金を電子決済するために必要な情報である決済情報のうち決済要求で指定された購入者の決済情報を使用して、サービス代金の電子決済を実行させるステップと、を備える。販売者端末またはサーバが、販売者の店舗において各購入者に対してサービスの提供を開始してから終了するまでのサービス時間に関する情報を記憶するステップと、１人以上の購入者による販売者の店舗に対するチェックイン操作の受け付け状況にもとづいて購入者の到着率を推定し、その到着率とサービス時間に関する情報にもとづいて、チェックイン操作から店舗におけるサービス開始までの待ち時間を推定するステップと、購入者端末においてチェックイン操作がなされた場合に、推定するステップにおいて推定した待ち時間を示す情報を購入者端末へ通知するステップと、をさらに実行する。
【００１１】
なお、以上の構成要素の任意の組合せ、本発明の表現をシステム、プログラム、プログラムを格納した記録媒体などの間で変換したものもまた、本発明の態様として有効である。
【発明の効果】
【００１２】
本発明によれば、サービス購入者の利便性を効果的に高めることを支援できる。
【図面の簡単な説明】
【００１３】
【図１】第１の実施の形態の商品売買システムの構成を示す図である。
【図２】図１の購入者端末の機能構成を示すブロック図である。
【図３】図１の店舗端末の機能構成を示すブロック図である。
【図４】店舗用チェックイン情報の構成を示す図である。
【図５】図１の売買支援サーバの構成を示すブロック図である。
【図６】図６（ａ）は利用者登録情報の構成を示し、図６（ｂ）は利用者チェックイン情報の構成を示す図である。
【図７】店舗詳細画面を示す図である。
【図８】チェックイン画面を示す図である。
【図９】商品選択画面を示す図である。
【図１０】会計画面を示す図である。
【図１１】顔パス決済画面を示す図である。
【図１２】第２の実施の形態の商品売買システムの構成を示す図である。
【図１３】図１２の購入者端末の機能構成を示すブロック図である。
【図１４】図１２の店員操作端末の機能構成を示すブロック図である。
【図１５】図１２の店舗内受付端末の機能構成を示すブロック図である。
【図１６】図１２の売買支援サーバの機能構成を示すブロック図である。
【図１７】待ち行列情報の構成を示す図である。
【図１８】待ち時間情報の構成を示す図である。
【図１９】チェックイン店舗確認画面を示す図である。
【図２０】受付画面を示す図である。
【図２１】順番待ち管理画面を示す図である。
【発明を実施するための形態】
【００１４】
以下、決済の利便性と安全性の両立を支援するための商品売買システムを第１の実施の形態として説明する。そして、第１の実施の形態の技術を前提として、精度の高い待ち時間をユーザへ提供することでサービス購入の利便性を一層高める商品売買システムを第２の実施の形態として説明する。同様に、第１および第２の実施の形態の技術を前提として、移動販売店舗での商品販売に顔パス決済の利便性を提供する商品売買システムを第３の実施の形態として説明する。
【００１５】
（第１の実施の形態）
第１の実施の形態では、「顔（写真）」と「名前」を利用した決済手法（以下、「顔パス決済」とも呼ぶ。）は維持しつつ、ワンタイムのコード（言わばワンタイムパスワード）を用いた本人確認を付加した商品売買システムを提案する。このシステムによると、顔パス決済による決済の簡便性・利便性は維持しつつ、本人確認の精度を向上させ、また、利用者側および店舗側の不正を抑制することができる。
【００１６】
図１は、第１の実施の形態の商品売買システム１００の構成を示す。商品売買システム１００は、購入者端末１０で総称される購入者端末１０ａ、購入者端末１０ｂ、購入者端末１０ｃと、店舗端末１２で総称される店舗端末１２ａ、店舗端末１２ｂ、店舗端末１２ｃと、売買支援サーバ１４と、決済サーバ１６を備える。図１の各装置は、ＬＡＮ・ＷＡＮ・インターネット等を含む無線および有線の通信網を介して接続される。
【００１７】
購入者端末１０ａ〜１０ｃは、商品を購入する立場のユーザであり、商品購入時に顔パス決済を利用する複数のユーザ（以下、「利用者」と呼ぶ。）がそれぞれ保持する情報処理端末である。購入者端末１０は、好適には利用者が移動時に携帯する携帯情報端末であり、例えばスマートフォンである。変形例として、利用者宅に設置された据置型のＰＣであってもよい。
【００１８】
店舗端末１２ａ〜１２ｃは、現実世界に実在する複数の店舗のそれぞれに設置され、各店舗の販売員（従業員）により操作される情報処理端末である。本実施の形態の店舗端末１２はタブレット端末（タブレットコンピュータ）であることとする。店舗端末１２には、商品販売に係る会計処理や決済処理を実行するためのアプリケーション、言わばレジ機能を実現するためのアプリケーションがインストールされている。
【００１９】
売買支援サーバ１４は、通信網を介して購入者端末１０、店舗端末１２、決済サーバ１６とデータを送受する情報処理装置である。売買支援サーバ１４は、利用者が店舗へ実際に来店して商品を購入する行為を支援する利用者向けサービス、および、店舗にて商品を販売する行為を支援するための店舗向けサービスを提供する。
【００２０】
決済サーバ１６は、クレジットカード会社や銀行等の金融機関に設置された情報処理装置であり、売買支援サーバ１４からの決済指示にしたがって電子決済処理を実行する。本実施の形態ではクレジットカード決済を実行する。
【００２１】
次に、購入者端末１０、店舗端末１２、売買支援サーバ１４の構成を詳細に説明する。
図２は、図１の購入者端末１０の機能構成を示すブロック図である。購入者端末１０は、タッチパネル２０と制御部２４を備える。制御部２４は、操作検出部２６と、表示制御部２８と、通信処理部３０と、商品購入支援部３２を含む。
【００２２】
本明細書のブロック図で示す各ブロックは、ハードウェア的には、コンピュータのＣＰＵやメモリをはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウェア、ソフトウェアの組合せによっていろいろなかたちで実現できることは、当業者には理解されるところである。以降のブロック図についても同様である。
【００２３】
例えば、制御部２４内の各機能ブロックに対応するプログラムモジュールが購入者端末１０のフラッシュメモリ等のストレージに格納され、購入者端末１０のＣＰＵがそれらのプログラムモジュールをメインメモリへ読み出して実行することにより制御部２４の機能が実現されてもよい。また、制御部２４は、ストレージやメインメモリ等の記憶領域へ各種データを記憶させ、そのデータを参照して各機能ブロックに係るデータ処理を実行してもよい。また、商品購入支援部３２に対応するアプリケーションソフトウェアが、記録メディアもしくはダウンロード形式にて配布され、購入者端末１０にインストールされてもよい。
【００２４】
タッチパネル２０は、入力装置（例えばタッチパッド）と一体形成された表示装置（例えば液晶パネル）である。操作検出部２６はタッチパネルドライバとしての機能を提供し、例えば、タッチパネル２０に対する利用者の操作入力を検出し、その操作内容を商品購入支援部３２に渡す。表示制御部２８もタッチパネルドライバとしての機能を提供し、例えば、商品購入支援部３２から渡されたテキストデータや画像データをタッチパネル２０に表示させる。
【００２５】
通信処理部３０は外部装置との無線通信を制御する。実施の形態において、通信処理部３０は、商品購入支援部３２から渡されたデータを売買支援サーバ１４へ送信する。また、売買支援サーバ１４から送信されたデータを受信して、そのデータを商品購入支援部３２へ渡す。
【００２６】
商品購入支援部３２は、商品購入支援アプリケーション、具体的には、顔パス決済サービスを利用するための利用者側アプリケーションの機能を提供する。商品購入支援部３２は、利用者情報登録部３４と、購入支援画面表示部３６と、サービス情報取得部３８と、チェックイン通知部４０と、ワンタイムコード生成部４２を含む。
【００２７】
利用者情報登録部３４は、顔パス決済を利用するために必要な利用者に関する属性情報を売買支援サーバ１４へ登録する。この属性情報には、利用者ＩＤ、利用者の氏名、顔写真、クレジットカード決済に必要なクレジットカード情報（例えばクレジットカード種類、カード番号、生年月日、有効期限等）が含まれる。利用者情報登録部３４は、利用者に自身の属性情報を入力させるための登録画面をタッチパネル２０に表示させてもよい。
【００２８】
購入支援画面表示部３６は、顔パス決済サービスにおける利用者用の画面（以下、「商品購入支援画面」とも呼ぶ。）をタッチパネル２０に表示させる。商品購入支援画面には、（１）初期画面としての売買支援サーバ１４へのログイン画面、（２）顔パス決済サービスを提供するサービス事業者（ブランド）の選択画面、（３）サービス事業者が運営する店舗の選択画面、（４）店舗の詳細情報を表示する店舗詳細画面、（５）店舗にチェックインした場合のチェックイン画面が含まれる。購入支援画面表示部３６は、これら複数種類の商品購入支援画面を、利用者の操作に応じて順次切り替えて表示させる。
【００２９】
サービス情報取得部３８は、複数種類の商品購入支援画面のそれぞれに表示させるべき情報を売買支援サーバ１４から取得する。例えば、（２）サービス事業者選択画面用の情報として、サービス事業者やブランドのＩＤ、名称、ロゴ、説明文等を取得する。また、（３）店舗選択画面および（４）店舗詳細画面用の情報として、サービス事業者が運営する複数の店舗それぞれの店舗ＩＤ、店舗名、営業時間、住所等を取得する。サービス情報取得部３８は、これらのサービス事業者情報や店舗情報を売買支援サーバ１４から定期的に取得して所定の記憶領域へ格納してもよく、商品購入支援画面が表示される際に売買支援サーバ１４から取得してもよい。
【００３０】
操作検出部２６は、（４）店舗詳細画面において、詳細情報を表示中の店舗に対して利用者がチェックインすることを示す所定操作（以下、「チェックイン操作」とも呼ぶ。）がなされたことを検出する。本実施の形態において「チェックイン」は、特定の店舗への来訪を利用者が予定したこと、言い換えれば、未確定であるが特定の店舗への来訪を利用者が企図したこととして位置づけられる。チェックイン通知部４０は、チェックイン操作が検出された場合に、その旨を示すチェックイン情報を売買支援サーバ１４へ送信する。このチェックイン情報には、利用者ＩＤと、チェックイン対象のサービス事業者ＩＤおよび店舗ＩＤが含まれる。
【００３１】
ワンタイムコード生成部４２は、チェックイン情報の通知に対する応答として売買支援サーバ１４から送信された乱数列を取得する。ワンタイムコード生成部４２は、予め定められた確認コード生成関数に、売買支援サーバ１４から取得した乱数列を入力し、その乱数列にもとづく確認コードを生成する。この確認コードは、今回のチェックインに限り一時的に有効な照合情報であり、いわゆるワンタイムパスワードである。本実施の形態では、確認コードが４桁の数字列（００００〜９９９９）であることとする。購入支援画面表示部３６は、ワンタイムコード生成部４２が生成した確認コードを（５）チェックイン画面において表示させる。なお購入者端末１０は、画面表示以外の方法で確認コードを利用者へ通知してもよく、例えば確認コードを音声出力してもよい。
【００３２】
図３は、図１の店舗端末１２の機能構成を示すブロック図である。店舗端末１２は、タッチパネル５０とチェックイン情報保持部５４と制御部５６を備える。制御部５６は、操作検出部５８と、表示制御部６０と、通信処理部６２と、商品販売支援部６４を含む。
【００３３】
一部既述したが、制御部５６内の各機能ブロックに対応するプログラムモジュールが店舗端末１２のフラッシュメモリ等のストレージに格納され、店舗端末１２のＣＰＵがそれらのプログラムモジュールをメインメモリへ読み出して実行することにより制御部５６の機能が実現されてもよい。また、制御部５６は、ストレージやメインメモリ等の記憶装置へ各種データを記憶させ、そのデータを参照して各機能ブロックに係るデータ処理を実行してもよい。また、商品販売支援部６４に対応するアプリケーションソフトウェアが記録メディアもしくはダウンロード形式にて配布され、店舗端末１２にインストールされてもよい。また、チェックイン情報保持部５４の機能は、店舗端末１２のストレージやメインメモリ等の記憶装置により実現されてもよい。
【００３４】
タッチパネル５０、操作検出部５８、表示制御部６０、通信処理部６２の機能は、購入者端末１０のタッチパネル２０、操作検出部２６、表示制御部２８、通信処理部３０の機能と同じであるため説明を省略する。
【００３５】
チェックイン情報保持部５４は、自店舗に対してチェックインした利用者、すなわち自店舗へ来店予定の利用者に関する属性情報（以下では「店舗用チェックイン情報」とも呼ぶ。）を保持する。図４は、店舗用チェックイン情報の構成を示す。店舗用チェックイン情報には、利用者のＩＤ、氏名、顔写真画像、クレジットカード情報（一部）が含まれる。このクレジットカード情報は、売買支援サーバ１４に登録された利用者のクレジットカード情報を、店舗販売員に開示可能な範囲に限定したものであり、例えばクレジットカードの種類と有効期限であってもよい。
【００３６】
図３に戻り、商品販売支援部６４は、商品販売支援アプリケーション、具体的には、顔パス決済サービスを利用するための店舗側アプリケーションの機能を提供する。商品販売支援部６４は、販売支援画面表示部６６と、商品情報取得部６８と、チェックイン情報更新部７０と、ワンタイムコード取得部７２と、決済要求通知部７４と、結果取得部７６を含む。
【００３７】
販売支援画面表示部６６は、顔パス決済サービスにおける店舗用の画面（以下、「商品販売支援画面」とも呼ぶ。）をタッチパネル５０に表示させる。商品販売支援画面には、（１）初期画面としてのメニュー選択画面（会計メニューや管理メニュー等）、（２）利用者の購入商品を選択する商品選択画面、（３）決済手段を選択するための会計画面、（４）顔パス決済を行なうための顔パス決済画面、（５）決済の結果を示す決済結果画面が含まれる。販売支援画面表示部６６は、これら複数種類の商品販売支援画面を、店舗販売員の操作に応じて順次切り替えて表示させる。
【００３８】
商品情報取得部６８は、商品販売支援画面の（２）商品選択画面に表示させるべき商品情報を売買支援サーバ１４から取得する。この商品情報には、商品名、商品画像、販売価格が含まれる。商品情報取得部６８は、商品情報を売買支援サーバ１４から定期的に取得して所定の記憶領域へ格納してもよく、商品選択画面が表示される際に売買支援サーバ１４から取得してもよい。
【００３９】
チェックイン情報更新部７０は、自店舗に対してチェックインした利用者に関する属性情報である店舗用チェックイン情報（図４）を売買支援サーバ１４から取得してチェックイン情報保持部５４へ格納する。本実施の形態では、売買支援サーバ１４は、公知のプッシュ通知（Push Notification）の仕組みにより店舗用チェックイン情報を店舗端末１２へ提供する。チェックイン情報更新部７０は、売買支援サーバ１４からプッシュ通知された店舗用チェックイン情報を、不図示の仲介サーバを介して取得してもよい。
【００４０】
ワンタイムコード取得部７２は、利用者へ予め通知された確認コードを取得する。本実施の形態では、利用者による確認コードの口頭申告を受けた店舗販売員が商品販売支援画面の（４）顔パス決済画面に対して入力した確認コードを取得する。決済要求通知部７４は、顔パス決済の実行操作が店舗販売員によりなされた際に、顔写真が選択された利用者のＩＤ、サービス事業者ＩＤ、店舗ＩＤ、決済金額、支払条件、ワンタイムコード取得部７２が取得した確認コード等を含む決済要求を売買支援サーバ１４へ送信する。後述するように、決済要求において確認コードを売買支援サーバ１４へ通知することで、利用者が申告した確認コードと、売買支援サーバ１４側が期待する確認コードとの整合有無を売買支援サーバ１４に確認させ、利用者が申告した確認コードの正当性を判定させる。
【００４１】
結果取得部７６は、決済要求への応答として売買支援サーバ１４から提供された決済結果情報を取得する。販売支援画面表示部６６は、商品販売支援画面の（５）決済結果画面に、売買支援サーバ１４から提供された決済結果情報を表示させる。チェックイン情報更新部７０は、結果取得部７６が決済結果を受け付けたことを契機として、典型的には商品代金の決済完了を契機として、チェックイン情報保持部５４から、決済を行なった利用者のレコードを削除する。店舗販売員は、商品購入時に利用者から確認コードを申告されて、申告コードを知る立場になっている。チェックイン後の決済処理が完了した店舗用チェックイン情報を削除することにより、店舗販売員の不正を防止できる。
【００４２】
図５は、図１の売買支援サーバ１４の構成を示すブロック図である。売買支援サーバ１４は、サービス情報保持部１１０と、利用者情報保持部１１１と、店舗情報保持部１１２と、制御部１１４を備える。制御部１１４は、利用者情報記録部１１６と、商品情報記録部１１８と、チェックイン受付部１２０と、乱数取得部１２２と、乱数提供部１２４と、チェックイン情報提供部１２６と、決済要求受付部１２８と、決済許否判定部１３０と、決済処理部１３２と、結果通知部１３４を含む。
【００４３】
一部既述したが、制御部１１４内の各機能ブロックに対応するプログラムモジュールが売買支援サーバ１４のハードディスク等のストレージに格納され、売買支援サーバ１４のＣＰＵがそれらのプログラムモジュールをメインメモリへ適宜読み出して実行することにより制御部１１４の機能が実現されてもよい。また、制御部１１４は、ストレージやメインメモリ等の記憶装置へ各種データを記憶させ、そのデータを参照して各機能ブロックに係るデータ処理を実行してもよい。また、サービス情報保持部１１０、利用者情報保持部１１１、店舗情報保持部１１２の機能は、売買支援サーバ１４のストレージやメインメモリ等の記憶装置により実現されてもよい。
【００４４】
サービス情報保持部１１０は、顔パス決済サービスを提供するサービス事業者に関する情報と、サービス事業者が運営する店舗の情報をサービス情報として保持する記憶領域である。このサービス情報は、購入者端末１０の商品購入支援画面において表示させるべき情報でもあり、商品売買システム１００の管理者により予め設定される。
【００４５】
利用者情報保持部１１１は、顔パス決済サービスにおける利用者の情報（以下、「利用者登録情報」とも呼ぶ。）と、利用者がチェックインしたことに関する情報（以下、「利用者チェックイン情報」とも呼ぶ。）を保持する記憶領域である。図６（ａ）は利用者登録情報の構成を示す。利用者登録情報には、購入者端末１０により登録された利用者のＩＤ、氏名、顔写真画像、決済に必要なクレジットカードの全情報が含まれる。また図６（ｂ）は利用者チェックイン情報の構成を示す。利用者チェックイン情報には、購入者端末１０から通知された利用者ＩＤ、チェックイン対象のサービス事業者ＩＤ、店舗ＩＤ、後述する乱数列および顔パス有効期限が含まれる。
【００４６】
図５に戻り、店舗情報保持部１１２は、個々の店舗に関する情報（以下、「店舗個別情報」とも呼ぶ。）を保持する。店舗個別情報には、サービス事業者ＩＤ、店舗ＩＤ、店舗端末情報、商品情報が含まれる。店舗端末情報は、チェックイン情報をプッシュ通知するために必要な店舗端末１２の情報を含む。例えば、店舗端末１２のＩＰアドレスであってもよく、個体識別番号（UID）であってもよい。商品情報は、店舗で販売される商品の名称、画像、販売価格を含む。
【００４７】
図５には不図示であるが、売買支援サーバ１４は、サービス情報保持部１１０に保持されたサービス情報を、定期的もしくは購入者端末１０の要求に応じて購入者端末１０へ提供するサービス情報提供部をさらに備えてもよい。また売買支援サーバ１４は、店舗情報保持部１１２に保持された商品情報を、定期的もしくは店舗端末１２の要求に応じて店舗端末１２へ提供する商品情報提供部をさらに備えてもよい。
【００４８】
利用者情報記録部１１６は、購入者端末１０から登録された利用者の属性情報を利用者登録情報（図６（ａ））として利用者情報保持部１１１へ格納する。商品情報記録部１１８は、サービス事業者や店舗の情報端末（例えば店舗端末１２）から登録された商品情報を受け付け、店舗情報保持部１１２の商品情報を更新する。
【００４９】
チェックイン受付部１２０は、購入者端末１０から通知されたチェックイン情報を受け付け、利用者チェックイン情報（図６（ｂ））として利用者情報保持部１１１へ格納する。その際に、チェックイン受付部１２０は、チェックイン情報の受付日時から所定時間経過した日時（例えば１時間後の日時）を顔パス有効期限として利用者チェックイン情報に設定する。
【００５０】
乱数取得部１２２は、チェックイン情報が受け付けられた際に、所定の乱数発生器で生成された乱数列を取得する。この乱数列の値は、数学的に発生させる乱数でなくてもよく、ハードウエア乱数やソフトウエア乱数などにより発生させる疑似乱数でもよい。乱数取得部１２２は、取得した乱数列のデータを、利用者情報保持部１１１の利用者チェックイン情報に設定する。乱数提供部１２４は、乱数取得部１２２が取得した乱数列のデータを、チェックイン情報の通知に対する応答として購入者端末１０へ送信する。
【００５１】
チェックイン情報提供部１２６は、チェックイン情報が受け付けられた際に、チェックインを行なった利用者のＩＤをキーとして、利用者情報保持部１１１の利用者登録情報から、店舗端末１２へ提供すべき店舗用チェックイン情報（図４）を抽出する。チェックイン情報提供部１２６は、設定した店舗用チェックイン情報を、公知のプッシュ通知の方法により店舗端末１２へ送信する。
【００５２】
決済要求受付部１２８は、店舗端末１２から送信された決済要求を受け付ける。決済許否判定部１３０は、利用者情報保持部１１１の利用者チェックイン情報を参照して、決済要求で指定された利用者ＩＤ、サービス事業者ＩＤ、店舗ＩＤと対応づけられた乱数列および顔パス有効期限を特定する。決済要求受付日時（典型的には現在日時）が顔パス有効期限を途過していた場合、決済許否判定部１３０は、決済の実行を拒否する。
【００５３】
決済要求受付日時が顔パス有効期限内であった場合、決済許否判定部１３０は、決済要求で指定された確認コード（ここでは「第１コード」と呼ぶ。）と、特定した乱数列とにもとづいて決済許否を判定する。具体的には、購入者端末１０で用いられた確認コード生成関数と同じ関数に乱数列を入力し、この乱数列にもとづく確認コード（ここでは「第２コード」と呼ぶ。）を生成する。そして、第１コードと第２コードとを照合し、両者が一致する場合に、正当な確認コードを受け付けたこととして決済の実行を許可し、相違する場合は決済の実行を拒否する。
【００５４】
決済処理部１３２は、決済許否判定部１３０が決済の実行を許可した場合に決済処理を実行する。具体的には、利用者情報保持部１１１の利用者登録情報に保持されたクレジットカード情報と、決済要求で指定された決済金額および支払条件（支払回数等）を指定した決済指示データを決済サーバ１６へ送信する。決済処理部１３２は、決済サーバ１６によるクレジットカード決済の成否を示す情報を決済サーバ１６から取得する。
【００５５】
結果通知部１３４は、決済許否判定結果および決済処理の成否を示す情報を決済結果情報として店舗端末１２へ送信する。例えば、顔パス有効期限切れであった場合、顔パス有効期限切れのため決済を拒否する旨の情報であり、新たなチェックイン操作を利用者に促すための情報を決済結果情報として店舗端末１２へ提供する。また利用者が申告した確認コードが不正（すなわち第２コードと不一致）であった場合、確認コードが不正である旨の情報を決済結果情報として店舗端末１２へ提供する。変形例として、結果通知部１３４は、決済が失敗となった店舗名を含む情報であり、新たなチェックイン操作を利用者に促すための情報を購入者端末１０へ送信してもよい。
【００５６】
以上の構成による商品売買システム１００の動作を以下説明する。
顔パス決済サービスの利用前に、利用者は、顔パス決済のための必要情報を売買支援サーバ１４へ登録する。この必要情報には、利用者ＩＤ、利用者の氏名、顔写真、クレジットカード決済に必要なクレジットカード情報（例えばクレジットカード種類、カード番号、生年月日、有効期限等）が含まれる。売買支援サーバ１４の利用者情報記録部１１６は、利用者登録情報を利用者情報保持部１１１へ格納する。また、サービス事業者は店舗で販売する商品情報を売買支援サーバ１４へ登録し、売買支援サーバ１４の商品情報記録部１１８は商品情報を店舗情報保持部１１２へ格納する。
【００５７】
（例えば外出中に）利用者は、店舗へ立ち寄ることを思いつくと、購入者端末１０にて商品購入支援アプリケーションを起動する。購入者端末１０のサービス情報取得部３８は、商品購入支援画面に表示させるべきデータを売買支援サーバ１４から取得する。購入者端末１０の購入支援画面表示部３６は、商品購入支援画面として、ログイン画面、サービス事業者選択画面、店舗選択画面を順次表示させた後、店舗選択画面で選択された店舗の詳細情報を示す店舗詳細画面を表示させる。図７は店舗詳細画面を示す。店舗詳細画面１４０には顔パス決済選択フィールド１４２が含まれる。顔パス決済を希望する場合、利用者は顔パス決済選択フィールド１４２に対して所定のチェックイン操作（例えばタップ操作や所定方向へのフリック操作）を入力する。このチェックイン操作により、利用者は将来時点において店舗へ来訪する意志があることを示したこととなり、後述するように、来訪対象の店舗へ利用者の情報が通知される。
【００５８】
店舗詳細画面１４０においてチェックイン操作が検出されると、購入者端末１０のチェックイン通知部４０は、チェックイン情報を売買支援サーバ１４へ送信する。売買支援サーバ１４のチェックイン受付部１２０は、受け付けたチェックイン情報を利用者チェックイン情報として利用者情報保持部１１１へ格納する。売買支援サーバ１４の乱数取得部１２２は、チェックイン受付部１２０がチェックイン情報を受け付けたことを契機として新たに生成された乱数列を取得して利用者チェックイン情報に記録する。売買支援サーバ１４の乱数提供部１２４は、その乱数列のデータを購入者端末１０へ送信する。
【００５９】
チェックイン情報通知に対する売買支援サーバ１４の応答として乱数列を受信すると、購入者端末１０のワンタイムコード生成部４２は、売買支援サーバ１４から提供された乱数列にしたがって新たに確認コードを生成する。そして販売支援画面表示部６６は店舗へのチェックインを受け付けたことを示すチェックイン画面を表示させる。図８はチェックイン画面を示す。チェックイン画面１５０にはチェックインした利用者に関する情報を表示する利用者情報エリア１５２が含まれる。利用者情報エリア１５２には、利用者の写真画像１５４、氏名１５６、ワンタイムコード生成部４２により生成された確認コード１５８を表示する。利用者はチェックイン画面１５０に表示された確認コード１５８を確認して（例えば記憶して）店舗へ来訪する。
【００６０】
また売買支援サーバ１４のチェックイン情報提供部１２６は、チェックイン受付部１２０がチェックイン情報を受け付けると、利用者情報保持部１１１に格納された利用者登録情報から店舗用チェックイン情報を抽出し、その店舗用チェックイン情報を店舗端末１２へ送信する。店舗端末１２のチェックイン情報更新部７０は、売買支援サーバ１４から提供された店舗用チェックイン情報を取得してチェックイン情報保持部５４へ格納する。
【００６１】
予めチェックインしておいた店舗へ利用者が来店し、購入希望商品を決定して店舗販売員に声をかけると、店舗販売員は店舗端末１２を操作し、商品販売支援アプリケーションのメニュー選択画面で会計メニューを選択する。店舗端末１２の商品情報取得部６８は店舗で販売している商品情報を売買支援サーバ１４から取得し、店舗端末１２の販売支援画面表示部６６は商品情報を並べた商品選択画面を表示させる。
【００６２】
図９は商品選択画面を示す。商品選択画面１６０の商品選択エリア１６２には、商品名と商品画像が配置される。明細エリア１６４には、店舗販売員が商品選択エリア１６２で選択した商品名と販売価格が表示される。また明細エリア１６４は、チェックイン状況フィールド１６６を含む。販売支援画面表示部６６は、自店舗に現在チェックインしている利用者数をチェックイン状況フィールド１６６へ設定し、例えばチェックイン情報保持部５４のレコード数をチェックイン状況フィールド１６６へ設定する。
【００６３】
また販売支援画面表示部６６は、商品選択画面１６０の表示中に新たな店舗用チェックイン情報が売買支援サーバ１４から受け付けられた場合（チェックイン情報保持部５４に新たなレコードが挿入された場合）に、その店舗用チェックイン情報が示す利用者氏名および顔写真画像をポップアップ１６８に一時的に表示させる。すなわち、自店舗へのチェックインがあったとき、そのチェックインを行なった利用者の情報を商品選択画面１６０にポップアップ表示させる。購入される商品の選択が終了し、店舗販売員が会計ボタン１７０を押下すると、販売支援画面表示部６６は、次に会計画面を表示させる。
【００６４】
図１０は会計画面を示す。会計画面１８０は決済手段を選択する画面とも言える。会計画面１８０には、現金決済指定エリア１８２と顔パス決済指定エリア１８４とカード決済指定エリア１８８が含まれる。現金決済指定エリア１８２は、現金決済の場合に支払金額を入力するためのエリアである。顔パス決済指定エリア１８４は、顔パス決済の場合に購入者（すなわち店舗にて商品を購入しようとしている利用者）の顔写真１８６を選択するためのエリアである。カード決済指定エリア１８８は、利用者が保持しているクレジットカードの読み込みによるクレジットカード決済の場合に選択するエリアである。
【００６５】
本実施の形態では顔パス決済が選択されることとする。利用者は自身の氏名（ここでは「野村花子」）を店舗販売員へ申告する。店舗販売員は、顔パス決済指定エリア１８４に表示されたチェックイン済みの複数の利用者それぞれのアイテム（氏名と顔写真の組み合わせ）を確認する。店舗販売員は、利用者の外見を目視し、顔パス決済指定エリア１８４に表示された「野村花子」の顔写真１８６と一致することを確認した上で、「野村花子」の顔写真１８６に対する選択操作（例えばタップ操作）を入力する。販売支援画面表示部６６は、次に顔パス決済画面を表示させる。
【００６６】
図１１は顔パス決済画面を示す。顔パス決済画面１９０には、会計画面１８０で選択された利用者の顔写真１９２および氏名１９４、確認コード入力フィールド１９６、決定ボタン１９８が表示される。ここで利用者は、チェックイン時に確認した確認コードを店舗販売員へ申告する。店舗販売員は、申告された確認コードを確認コード入力フィールド１９６へ入力する。なお、顔パス決済画面１９０では支払条件（支払回数等）の変更も可能である。利用者の外見が顔写真１９２と一致し、利用者が申告した氏名が氏名１９４と一致することを店舗販売員が確認し、また、確認コード入力フィールド１９６への確認コードの入力を完了すると、店舗販売員は、決定ボタン１９８に対する選択操作を入力して決済処理を実行させる。
【００６７】
顔パス決済画面１９０において決定ボタン１９８の選択操作が検出されると、店舗端末１２のワンタイムコード取得部７２は、確認コード入力フィールド１９６に入力された確認コード（ここでは「申告コード」と呼ぶ。）を取得する。店舗端末１２の決済要求通知部７４は、申告コードを含む決済要求を売買支援サーバ１４へ送信する。売買支援サーバ１４の決済要求受付部１２８が決済要求を受け付けると、売買支援サーバ１４の決済許否判定部１３０は、決済要求で指定された利用者ＩＤにより利用者チェックイン情報を特定する。そして、利用者チェックイン情報の顔パス有効期限が未経過、かつ、利用者チェックイン情報の乱数列にしたがって、決済要求の受け付けを契機に新たに生成した確認コード（ここでは「照合コード」と呼ぶ。）と、決済要求で指定された申告コードとが整合する場合に、商品代金のクレジットカード決済を許可する。
【００６８】
決済許否判定部１３０によりクレジットカード決済が許可された場合に、決済処理部１３２は、決済指示を決済サーバ１６へ送信し、商品代金の決済処理を実行させる。結果通知部１３４は、売買支援サーバ１４および決済サーバ１６における決済処理の結果を示す情報を店舗端末１２へ送信する。店舗端末１２の販売支援画面表示部６６は、決済処理の結果を画面表示させる。店舗販売員は、決済処理の結果を確認し、決済が正常に完了した旨の内容であれば、商品の販売が正常に完了したとして商品を利用者へ引き渡す。売買支援サーバ１４もしくは決済サーバ１６において決済処理が拒否され、もしくは失敗した旨の内容であれば、店舗販売員はその旨を利用者へ伝え、例えば新たなチェックイン操作を利用者へ促す。
【００６９】
第１の実施の形態の商品売買システム１００によると、利用者は店舗へチェックイン後、実際に店舗へ来訪して商品を購入する際に、氏名と確認コードを申告すれば商品代金の支払を完了できる。すなわち、現金やクレジットカード等の物理的な決済媒体を店舗で取り出すことなく、いわば「顔パス」で商品を購入できる。これにより、商品購入に係る利便性を高める。また、店舗に初めて来訪する場合や来店回数が少ないときでも、あたかも常連客であるかのように簡易な手続で商品を購入でき、利用者に優越感や満足感を抱かせやすくなる。
【００７０】
また商品売買システム１００によると、店舗へのチェックイン時に利用者へワンタイムの確認コードを提示する。そして、商品購入時に利用者が申告した確認コードと、商品購入時に売買支援サーバ１４側で生成した確認コードとが一致することを条件に、チェックインした人物と、店舗で商品を購入しようとする人物とが同一であると判定し、顔パス決済を許可する。このように、購入者の外見と顔写真とを店舗販売員が目視確認することに加えて、売買支援サーバ１４による確認コードの照合処理を併用することで、不正な決済がなされてしまうことを効果的に抑制できる。
【００７１】
例えば、悪意のある第三者が別の利用者へなりすました場合も、その第三者が確認コードを知ることは困難であるため、利用者側の不正行為を効果的に防止できる。また、店舗販売員による購入者の誤認識や操作ミスが発生した場合、例えば顔写真の選択を誤った場合にも確認コードの不整合が検出されるため、誤った決済がなされることを防止できる。また、利用者が申告するまでは店舗販売員も確認コードを知り得ないため、店舗販売員による不正行為も効果的に防止できる。例えば、来店しない利用者の顔写真を指定して、実際には購入されていない商品の代金を不正に支払わせることを防止できる。
【００７２】
また商品売買システム１００によると、利用者によるチェックイン後、所定の有効期間内（すなわち顔パス有効期限が未経過の間）に決済要求がなされることをさらなる条件として、顔パス決済を許可する。確認コードが利用者へ提示されてから時間が経過するほど、その確認コードが第三者へ漏洩する可能性は高まり、漏洩すると本人確認の精度が低下してしまう。本実施の形態では、顔パス有効期限を設けることにより、チェックインした人物と、店舗で商品を購入しようとする人物の同一性の確認精度の低下を抑制できる。
【００７３】
以上、第１の実施の形態を説明した。この実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。以下変形例を示す。
【００７４】
第１の実施の形態についての、第１の変形例を説明する。
上記実施の形態では、売買支援サーバ１４は、利用者チェックイン情報として確認コードそのものではなく、確認コードの生成元データとしての乱数列を保持した。変形例として、利用者によるチェックイン操作時に、売買支援サーバ１４の乱数取得部１２２は、乱数列をもとに確認コードを生成し、売買支援サーバ１４は利用者チェックイン情報としてその確認コードを保持してもよい。また、売買支援サーバ１４から購入者端末１０へ乱数列を提供することに代えて確認コードを提供してもよい。また上記実施の形態では、利用者によるチェックイン操作時に、売買支援サーバ１４が購入者端末１０へ乱数列を送信することとした。変形例として、購入者端末１０が乱数列を生成し、チェックイン情報に含めて売買支援サーバ１４へ送信してもよい。また、購入者端末１０が乱数列をもとに確認コードを生成して、その確認コードを売買支援サーバ１４へ送信してもよい。このように請求項に記載の「第１の照合情報」と「第２の照合情報」は同じ内容であってもよい。
【００７５】
第１の実施の形態についての、第２の変形例を説明する。
上記実施の形態では、利用者へ通知される確認コードは４桁の数字列とした。変形例として、確認コードは数字列以外の態様のデータでもよく、例えばバーコードやＱＲコード（登録商標）であってもよい。この場合に、利用者は店舗において確認コードを表示中の購入者端末１０を提示し、店舗端末１２のワンタイムコード取得部７２は、バーコードリーダやＱＲコードリーダ等の所定の読取り装置を介して、確認コードの内容を取得してもよい。
【００７６】
第１の実施の形態についての、第３の変形例を説明する。
購入者端末１０は自動チェックイン機能を備えてもよい。この変形例では、売買支援サーバ１４は、地図上での店舗の位置を示す位置情報（例えば緯度・経度の値）を保持する。購入者端末１０のサービス情報取得部３８は、売買支援サーバ１４から、店舗の位置情報をさらに取得する。また購入者端末１０は、ＧＰＳ装置と位置判定部をさらに備える。ＧＰＳ装置は、ＧＰＳ衛星からＧＰＳ測位情報を受信し、受信情報から購入者端末１０の現在位置を示す情報（例えば緯度・経度の値）を出力する。
【００７７】
位置判定部は、利用者が予め指定した店舗（以下、「指定店舗」とも呼ぶ。）の近傍に購入者端末１０が存在するか否かを判定する。具体的には、指定店舗の所在地から所定の範囲（例えば半径１００メートル）内に、ＧＰＳ装置が出力した購入者端末１０の現在位置が含まれる場合に、購入者端末１０が指定店舗の近傍に存在すると判定する。チェックイン通知部４０は、購入者端末１０が指定店舗の近傍に存在すると判定された場合、自動的に指定店舗を指定したチェックイン情報を売買支援サーバ１４へ送信する。購入支援画面表示部３６は、自動チェックインにおいて生成された確認コードを、指定店舗の情報とともに、図８のチェックイン画面１５０と同様の自動チェックイン画面に表示させてもよい。
【００７８】
第１の実施の形態についての、第４の変形例を説明する。
購入者端末１０および店舗端末１２はシンクライアント（Thin Client)として実装されてもよい。例えば購入者端末１０は、タッチパネル２０への入力データを操作検出部２６を介して取得し、売買支援サーバ１４から取得された画面データを表示制御部２８を介してタッチパネル２０に表示させる画面表示部のみを備える構成であってもよい。同様に店舗端末１２は、タッチパネル５０への入力データを操作検出部５８を介して取得し、売買支援サーバ１４から取得された画面データを表示制御部６０を介してタッチパネル５０に表示させる画面表示部のみを備える構成であってもよい。購入者端末１０および店舗端末１２の画面表示部はウェブブラウザにより実現されてもよい。
【００７９】
この変形例において、売買支援サーバ１４は、図２の商品購入支援部３２、図３の商品販売支援部６４に対応する機能を実現するためのデータ処理を一括して実行する。また売買支援サーバ１４は、ウェブサーバの機能を有し、データ処理の結果を示す画面データを構造化文書（ＨＴＭＬ、ＸＭＬ等）として購入者端末１０および店舗端末１２へ提供してもよい。
【００８０】
第１の実施の形態についての、第５の変形例を説明する。
売買支援サーバ１４は、確認コードのロックアウト機能をさらに備えてもよい。この変形例では、売買支援サーバ１４は、同一の利用者ＩＤ、サービス事業者ＩＤ、店舗ＩＤを指定する決済要求を複数回受け付ける。そして、それぞれの決済要求で指定された確認コード（第１コード）と、上記の利用者ＩＤ、サービス事業者ＩＤ、店舗ＩＤの組み合わせにより特定された乱数列にもとづく確認コード（第２コード）が不一致となり、その不一致の回数が所定の閾値（ここでは３回）に達した場合に、上記の利用者ＩＤ、サービス事業者ＩＤ、店舗ＩＤの組み合わせにより特定された乱数列を無効にする。言い換えれば、事前の利用者のチェックインにより利用者へ提供した確認コードを無効なものとする。
【００８１】
例えば、利用者情報保持部１１１の利用者チェックイン情報には、照合失敗回数欄（初期値：０）と、無効フラグ欄（初期値：オフ）をさらに設けてもよい。決済許否判定部１３０は、第１コードと第２コードが不整合であった場合に、決済要求で指定された利用者ＩＤ、サービス事業者ＩＤ、店舗ＩＤの組み合わせで特定される利用者チェックイン情報について、その照合失敗回数をインクリメントする。そして、照合失敗回数が３回に達すると、利用者チェックイン情報の無効フラグをオンに設定する。決済許否判定部１３０は、決済要求で指定された利用者ＩＤ、サービス事業者ＩＤ、店舗ＩＤの組み合わせにより、まず利用者チェックイン情報の無効フラグを確認する。無効フラグがオンであれば、確認コードの照合処理をスキップし、すなわち第１コードと第２コードが一致するか否かにかかわらず、決済の実行を拒否する。結果通知部１３４は、確認コードが無効になった旨を示す情報であり、また、新たなチェックイン操作を利用者に促すための情報を店舗端末１２または購入者端末１０へ提供する。なお、新たなチェックインがなされた場合には、新たな乱数列（確認コード）が生成されて新たな利用者チェックイン情報が生成される。
【００８２】
本変形例では、確認コードの照合失敗が所定回数に達すると、利用者によるチェックイン時に発行された確認コードによる電子決済が拒否されることになる。これにより、悪意のある第三者による利用者へのなりすましや、店舗側の不正な決済要求による不正な決済の実行を防止しやすくなる。
【００８３】
次に、上記変形例に関連し、悪意のある第三者による利用者へのなりすましや、店舗側の不正な決済要求を抑制するためのさらなる変形例を説明する。売買支援サーバ１４は、所定の条件が満たされた場合にチェックインを拒否するチェックイン判定部をさらに備えてもよい。チェックイン判定部は、第１の不正防止処理として、同日に規定回数以上のチェックインが繰り返された場合に、顔パス決済の利用を一時的に停止してもよい。また、チェックイン判定部は、第２の不正防止処理として、同一の端末から再チェックインが繰り返された場合に、当該端末による顔パス決済を一時的に停止してもよい。
【００８４】
チェックイン判定部の第１の不正防止処理を詳細に説明する。利用者情報保持部１１１は、当日日付、利用者ＩＤ、サービス事業者ＩＤ、店舗ＩＤをキーとして、チェックイン回数（初期値：０）と対応づけたチェックイン履歴をさらに保持する。このチェックイン回数には、ある特定の日付における同一利用者による同一店舗へのチェックイン回数が記録される。チェックイン受付部１２０は、チェックイン情報を受け付けた場合に、当日日付と、チェックイン情報で指定された利用者ＩＤ、サービス事業者ＩＤ、店舗ＩＤに対応する履歴が記録済みでなければ、チェックイン回数「１」を示すチェックイン履歴を新たに記録し、記録済みであれば、そのチェックイン回数をインクリメントする。
【００８５】
チェックイン判定部は、チェックイン受付部１２０がチェックイン情報を受け付けた場合に、当日日付、チェックイン情報で指定された利用者ＩＤ、サービス事業者ＩＤ、店舗ＩＤに対応するチェックイン履歴を特定し、チェックイン回数が５回以下であった場合にチェックインを許可する。以降、乱数列および店舗用チェックイン情報の提供処理が継続される。その一方、チェックイン回数が６回以上であった場合、チェックイン判定部はチェックインを拒否する。この場合に、チェックイン判定部は、利用者による所定操作、例えば予め定められた本人確認操作がなされるまで、チェックイン回数が規定回数を超過した利用者からのチェックインを拒否し、確認コードの発行処理をスキップすることにより、顔パス決済を一時的に停止する。
【００８６】
チェックイン判定部の第２の不正防止処理を詳細に説明する。利用者情報保持部１１１は、上記第１の構成のチェックイン履歴にさらに端末ＩＤを加えたチェックイン履歴を保持する。また購入者端末１０からのチェックイン情報は購入者端末１０の端末ＩＤ（例えば個体識別番号）をさらに含む。チェックイン受付部１２０は、チェックイン情報で指定された端末ＩＤ、利用者ＩＤ、サービス事業者ＩＤ、店舗ＩＤをキーとして、チェックイン回数をインクリメントする。
【００８７】
チェックイン判定部は、チェックイン受付部１２０がチェックイン情報を受け付けた場合に、当日日付、チェックイン情報で指定された端末ＩＤ、利用者ＩＤ、サービス事業者ＩＤ、店舗ＩＤに対応するチェックイン履歴を特定し、チェックイン回数が５回以下であった場合にチェックインを許可する。その一方、チェックイン回数が６回以上であった場合、チェックインを拒否する。この場合に、チェックイン判定部は、利用者による所定操作、例えば予め定められた本人確認操作がなされるまで、チェックイン回数が規定回数を超過した購入者端末１０からのチェックインを拒否し、確認コードの発行処理をスキップすることにより、顔パス決済を一時的に停止する。なお、上記第１の不正防止処理と第２の不正防止処理のそれぞれは、第５の変形例に限らず、実施の形態の構成および他の変形例の構成と組み合わせてもよい。
【００８８】
第１の実施の形態についての、第６の変形例を説明する。
売買支援サーバ１４は、利用者に対して発行される確認コードの重複を排除するための機能をさらに備えてもよい。既述したように、利用者情報保持部１１１の利用者チェックイン情報には、利用者ＩＤと対応づけて乱数列が格納される。本変形例ではさらにチェックイン日時が格納されることとし、具体的には、チェックイン受付部１２０は、利用者チェックイン情報を記録する際に現在日時、言い換えれば、購入者端末１０からチェックイン情報を受け付けた日時情報をさらに記録する。乱数取得部１２２は、利用者と確認コードをセットとして、同一人物に対して発行済みの確認コードと同じ確認コードを同日中に発行することを抑制する。確認コードのユニーク性を担保することで、確認コードの秘匿性を高め、悪意のある第三者や店舗による不正行為を防止しやすくなる。
【００８９】
具体的には、乱数取得部１２２は、乱数発生器から乱数列を取得した際に、取得した乱数列と、チェックイン情報で指定された利用者ＩＤとの組み合わせが、現在日付と対応づけられた既存の利用者チェックイン情報で設定済みか否かを確認する。既存の利用者チェックイン情報に未設定の場合、すなわち取得した乱数列と利用者ＩＤの組み合わせがユニークであれば、乱数取得部１２２は、取得した乱数列を用いて以降の処理を実行する。その一方、取得した乱数列と利用者ＩＤとの組み合わせが、既存の利用者チェックイン情報で設定済みの場合、すなわち取得した乱数列が当該利用者へ発行済みの乱数列と同じ値であれば、乱数取得部１２２は乱数発生器から乱数列を再度取得して、既存の利用者チェックイン情報との比較処理を再度実行する。
【００９０】
なお乱数取得部１２２は、現在日付と対応づけられた既存の利用者チェックイン情報のうち、顔パス有効期限が切れているものは比較対象から除外してもよい。言い換えれば、現在日付と対応づけられ、かつ、顔パス有効期限が未経過の既存の利用者チェックイン情報のみ比較対象として抽出してもよい。また、第１の変形例で既述したように、売買支援サーバ１４が乱数列にもとづいて確認コードを生成する場合、利用者チェックイン情報には確認コードが格納されてよい。この場合に乱数取得部１２２は、生成した確認コードと、既存の利用者チェックイン情報との比較処理を実行してもよい。
【００９１】
また第５の変形例にも関連するが、第６の変形例においても、売買支援サーバ１４は、チェックイン情報が受け付けられた際、所定の条件が満たされた場合にチェックインを拒否するチェックイン判定部をさらに備えてもよい。乱数取得部１２２は、チェックイン判定部が、以下の２つの判定処理の両方でチェックインを許可した（拒否しなかった）ことを条件として、上記の乱数列取得・比較処理を実行してもよい。チェックイン判定部は、第１の判定処理として、チェックインをする利用者が規定時間内に規定距離を超えていないかを判定し、第２の判定処理として、１人の利用者が短期間で大量のチェックインをしていないかを判定する。
【００９２】
チェックイン判定部の第１の判定処理を詳細に説明する。第３の変形例にも関連するが、売買支援サーバ１４は、地図上での店舗の位置を示す位置情報（例えば緯度・経度の値）を保持する。チェックイン判定部は、今回受け付けられたチェックイン情報（以下、「当該チェックイン情報」とも呼ぶ。）のチェックイン日時と、店舗ＩＤにより特定される店舗位置を認識する。また、当該チェックイン情報で指定された利用者ＩＤと対応づけられた既存の利用者チェックイン情報（以下、「既存チェックイン情報」とも呼ぶ。）のチェックイン日時と、店舗ＩＤにより特定される店舗位置を認識する。
【００９３】
チェックイン判定部は、当該チェックイン情報での対象店舗と、既存チェックイン情報での対象店舗について、許容する店舗間の距離（各店舗位置の乖離の大きさ）を、当該チェックイン情報のチェックイン日時と、既存チェックイン情報のチェックイン日時の差分に応じて決定する。典型的には、チェック日時の差分が大きいほど、許容する店舗間距離を大きくし、両者が正相関するよう決定する。例えば、チェックイン日時の差分が１時間であれば、許容する店舗間距離を６０キロメートルに決定し、チェックイン日時の差分が２時間であれば、許容する店舗間距離を１２０キロメートルに決定してもよい。
【００９４】
チェックイン判定部は、当該チェックイン情報での対象店舗と、既存チェックイン情報での対象店舗それぞれの位置情報から店舗間距離を算出する。算出した店舗間距離が、許容する店舗間距離より大きい場合、チェックイン判定部はチェックインを拒否する。例えば、同一の利用者が、１０時に渋谷の店舗Ａに対するチェックイン操作をした後、１０時４０分に博多の店舗Ｂに対しチェックイン操作をした場合、チェックイン判定部は後者のチェックインを拒否する。第１の判定処理によると、現実的に来店が困難なチェックインを受け付けた場合に、無駄となることが想定される顔パス決済の準備処理を抑制し、管理すべきチェックイン情報の数を低減して、売買支援サーバ１４のシステムリソースの浪費を防止できる。また、店舗側に対して、実質的に意味のないチェックインを通知してしまうことを抑制できる。
【００９５】
チェックイン判定部の第２の判定処理を詳細に説明する。チェックイン判定部は、チェックイン情報で指定された利用者ＩＤと対応づけられた既存の利用者チェックイン情報を参照する。そして、所定時間内（例えば直近の５分間）に記録された利用者チェックイン情報が所定数以上（例えば２０件以上）存在した場合に、大量チェックインがなされたと判定し、チェックインを拒否する。
【００９６】
また利用者情報保持部１１１は、利用者ＩＤ、サービス事業者ＩＤ、店舗ＩＤをキーとしてチェックイン時刻およびチェックオフ時刻の履歴を保持する。チェックイン受付部１２０は、チェックイン情報を受け付けるたびに、チェックイン時刻の履歴へ、チェックイン情報の受付日時をチェックイン時刻として逐次記録していく。また、チェックイン受付部１２０は、チェックオフ情報を受け付けるたびに、チェックオフ時刻の履歴へ、チェックオフ情報の受付日時をチェックオフ時刻として逐次記録していく。なお、チェックオフ情報は、チェックインの取り消しを要求する情報である。売買支援サーバ１４は、チェックオフ情報を受け付けると、対応する利用者チェックイン情報を削除してもよく、店舗用チェックイン情報の取り消し要求を店舗端末１２へ送信してもよい。
【００９７】
チェックイン判定部は、チェックイン情報で指定された利用者ＩＤ、サービス事業者ＩＤ、店舗ＩＤをキーとして、チェックイン時刻およびチェックオフ時刻の履歴を参照する。そして、同一店舗に対して所定回数以上のチェックインとチェックオフが繰り返されていることを検出すると、大量チェックインがなされたと判定し、チェックインを拒否する。
【００９８】
第２の判定処理において一旦チェックインを拒否すると、チェックイン判定部は、予め定められたチェックイン許可条件が満たされるまで継続して、拒否対象の利用者ＩＤが指定されたチェックイン情報によるチェックインを拒否する。チェックイン許可条件は、例えば、最終チェックインから３０分間が経過したことでもよく、チェックイン拒否を決定してから３０分が経過したことでもよい。第２の判定処理によると、現実的に当日来店できないような数のチェックインや、短時間での大量チェックインを防止でき、売買支援サーバ１４のシステムリソースの浪費を防止し、またＤｏＳ攻撃への耐性も向上できる。なお、上記第１の判定処理および第２の判定処理のそれぞれは、第６の変形例に限らず、実施の形態の構成および他の変形例の構成と組み合わせてもよい。
【００９９】
第１の実施の形態についての、第７の変形例を説明する。
売買支援サーバ１４は、特定の店舗において顔パス決済を初めて利用する利用者（以下、「初回顧客」とも呼ぶ。）に対して、その店舗で使用可能なクーポン、例えば割引券や引換券を発行してもよい。本変形例において、売買支援サーバ１４は、各店舗が初回顧客へ提供するクーポンの情報の登録を受け付ける。売買支援サーバ１４の利用者情報保持部１１１は、利用者、店舗、チェックイン回数を対応づけたチェックイン履歴をさらに保持する。また売買支援サーバ１４のチェックイン受付部１２０は、チェックイン情報を受け付けると、利用者ＩＤおよび店舗ＩＤに対応するチェックイン履歴のチェックイン回数をインクリメントする。
【０１００】
売買支援サーバ１４はクーポン提供部をさらに備える。クーポン提供部は、チェックイン受付部１２０がチェックイン情報を受け付けた場合に、利用者ＩＤおよび店舗ＩＤに対応するチェックイン履歴のチェックイン回数を確認する。チェックイン回数が「１」（すなわち初回顧客）の場合、クーポン提供部は、チェックイン対象店舗が提供するクーポンの情報を、乱数列の提供にあわせて購入者端末１０へ提供する。これにより、例えば購入者端末１０のチェックイン画面１５０（図８）にクーポン情報を表示させ、利用者の購買意欲を高める。またクーポン提供部は、初回顧客へ提供したクーポンの情報を、チェックイン対象店舗への店舗用チェックイン情報の提供にあわせて店舗端末１２へ提供する。これにより、例えば店舗端末１２の顔パス決済画面１９０にクーポン情報を表示させ、クーポン適用対象の顧客であることを店舗販売員に報知することができる。
【０１０１】
第１の実施の形態についての、第８の変形例を説明する。
利用者は、自身の属性情報として、カード種類が異なる複数のクレジットカード情報を売買支援サーバ１４へ登録してよい。この場合に、売買支援サーバ１４は、複数のクレジットカード情報を店舗用チェックイン情報として店舗端末１２へ提供し、店舗端末１２の販売支援画面表示部６６は、図１１の顔パス決済画面１９０に、購入者に対応づけられた複数のクレジットカード情報を選択・切替可能にリスト表示してもよい。店舗販売員は、購入者からの口頭申告により決済で使用するクレジットカードの種類を受け付けて、リスト内からそのクレジットカードを選択する。
【０１０２】
次に、利用者が複数のクレジットカード情報を登録済みの場合に、どのクレジットカードを使うとメリットが大きいかを自動判定し、メリットが大きいカードをデフォルト表示する構成を説明する。
【０１０３】
店舗端末１２は、図１０の会計画面１８０において特定の顔写真１８６が選択された場合に、選択された顔写真１８６に対応する利用者ＩＤと、購入対象商品、決済金額を、サービス事業者ＩＤおよび店舗ＩＤとともに、売買支援サーバ１４へ通知する顧客情報通知部をさらに備える。売買支援サーバ１４は、リワード情報保持部とリワード判定部をさらに備える。リワード情報保持部は、クレジットカードごとに定められたリワードプログラムの情報、例えばリワードの種類（電子ポイント提供、キャッシュバック、クーポン提供等）と、リワードの提供条件を保持する。
【０１０４】
リワード判定部は、サービス情報保持部１１０を参照して、店舗端末１２から通知されたサービス事業者ＩＤおよび店舗ＩＤに対応するサービス事業者名および店舗名を特定する。また利用者情報保持部１１１の利用者登録情報を参照して、店舗端末１２から通知された利用者ＩＤに対応づけられた複数のクレジットカード情報を特定する。またリワード情報保持部を参照して、各クレジットカードのリワード提供条件を特定する。
【０１０５】
リワード判定部は、クレジットカードごとに、リワード提供条件と、サービス事業者名、店舗名、購入対象商品、決済金額とを比較して、提供条件が満たされたリワードの内容を特定する。そして所定の評価関数にしたがって、クレジットカードごとのリワードの大きさ、言い換えれば、購入者にとってのメリットの大きさを判定する。例えば、リワードが電子ポイントやキャッシュバックの提供であれば、その提供額が大きいほどリワードが大きいと判定してもよい。また割引クーポンの提供であれば、その割引額が大きいほどリワードが大きいと判定してもよい。リワード判定部は、購入者が保持するクレジットカードごとのリワードの大きさを示すリワード情報を店舗端末１２へ提供する。
【０１０６】
店舗端末１２の販売支援画面表示部６６は、図１１の顔パス決済画面１９０において複数のクレジットカード情報をリスト表示させる際に、売買支援サーバ１４から通知されたリワード情報においてリワードが最も大きいとされたクレジットカードを、決済に用いる既定のカードとしての態様で表示させる。例えば、顔パス決済画面１９０の初期表示時に選択状態で表示させもよく、顔パス決済画面１９０の支払条件欄でデフォルト表示させてもよい。また販売支援画面表示部６６は、顔パス決済画面１９０において、複数のクレジットカードの情報を、リワードの大きさの降順に並べたリストを表示させてもよい。また、売買支援サーバ１４のリワード判定部は、リワードの内容も店舗端末１２へ通知してよく、店舗端末１２の販売支援画面表示部６６は、各クレジットカードに対応づけた態様でリワードの内容を表示させてもよい。
【０１０７】
第１の実施の形態についての、第９の変形例を説明する。
チェックイン日時から顔パス有効期限までの期間（以下、「顔パス有効期間」とも呼ぶ。）は固定期間でなくてもよく、利用者と店舗の位置関係に応じて期間の長短が動的に決定されてもよい。顔パス有効期間を維持しながらも、その長短を柔軟に調整することで、不正防止効果を維持しつつ、利用者の利便性を一層向上させることができる。
【０１０８】
例えば、購入者端末１０または売買支援サーバ１４は、チェックイン操作時に顔パス有効期間を決定する有効期間決定部をさらに備えてもよい。購入者端末１０が有効期間決定部を備える場合は、購入者端末１０は、決定した顔パス有効期間をチェックイン情報に含めて売買支援サーバ１４へ通知し、売買支援サーバ１４は、通知された顔パス有効期間にもとづく顔パス有効期限を利用者チェックイン情報に格納してもよい。また売買支援サーバ１４が有効期間決定部を備える場合は、購入者端末１０は、自端末の位置情報をチェックイン情報に含めて売買支援サーバ１４へ通知してもよい。
【０１０９】
有効期間決定部は、チェックイン対象店舗の所在地と、購入者端末１０の現在位置が離れているほど、漏洩リスクを考慮した所定期間（例えば１２時間）を上限とした範囲内で顔パス有効期間を長くしてもよい。また、チェックイン対象の店舗の所在地と、購入者端末１０の現在位置に応じて、利用者が店舗へ移動する際の所要時間を推定してもよく、移動の所要時間が長いほど顔パス有効期間を長くしてもよい。また、移動の所要時間に１時間等の所定時間を加えた結果を顔パス有効期間として決定してもよい。また移動の所要時間を精度よく推定するために、徒歩・自転車・自動車等の移動手段を利用者に選択させてもよく、選択された移動手段と予め対応づけられた平均移動速度に応じて所要時間を推定してもよい。
【０１１０】
第１の実施の形態についての、第１０の変形例を説明する。
利用者が特定の店舗の常連客、具体的には、特定の店舗において所定回数もしくは所定金額以上の顔パス決済の経験者である場合に、その店舗における顔パス有効期間を、常連客でない他の利用者の顔パス有効期間より長い期間になるよう決定してもよい。常連客は顔パス決済に慣れているため、確認コードの漏洩リスクが相対的に低いことが見込まれ、また、常連客であるため店舗側の不正行為も抑制されることが見込まれるためである。このように常連客を特別待遇とすることで、常連客である利用者に優越感や満足感を一層抱かせやすくなる。
【０１１１】
この変形例においても、購入者端末１０または売買支援サーバ１４は有効期間決定部をさらに備える。また購入者端末１０または売買支援サーバ１４は、利用者と、その利用者が顔パス決済により商品を購入した店舗、購入回数、決済金額を対応づけた決済履歴を保持する決済履歴保持部をさらに備える。購入者端末１０が決済履歴保持部を備える場合、顔パス決済がなされる都度、売買支援サーバ１４は決済履歴を購入者端末１０へ提供してもよい。
【０１１２】
有効期間決定部は、利用者が特定の店舗へチェックインするときに、決済履歴を参照して、その店舗における当該利用者の顔パス決済回数および／または顔パス決済金額を特定する。そして、顔パス決済回数が所定回数（例えば３回）以上、および／または、顔パス決済金額が所定額（例えば１万円）以上であるときに、利用者がチェックイン対象店舗の常連客であると判定する。有効期間決定部は、常連客でないと判定した場合、上記実施の形態や第９の変形例で記載したような通常の方法にて顔パス有効期間を決定する一方、常連客と判定した場合は、通常の方法で決定した顔パス有効期間より長い期間を、常連客に付与する顔パス有効期間として決定する。例えば、通常の方法で決定した顔パス有効期間に対して２時間等の所定時間を加えた期間としてもよい。
【０１１３】
第１の実施の形態についての、第１１の変形例を説明する。
店舗端末１２の販売支援画面表示部６６は、顔パス有効期限が切れた利用者のアイテム（例えば氏名と顔写真を含むアイコン）を、販売支援画面（例えば会計画面）において店舗販売員による選択ができない態様で表示させてもよい。例えば、グレーアウトして表示させてもよく、選択操作を無効なものにして（例えばdisable属性を付与して）表示させてもよい。また、顔パス有効期限が切れた利用者のアイテムを販売支援画面で非表示としてもよい。この変形例によると、販売支援画面において選択候補となる利用者を、顔パス有効期限内の利用者に限定できるため、選択候補となる利用者数を抑制でき、店舗販売員による選択の手間を低減させることができる。また、顔パス有効期限が切れた利用者が選択されることを抑制し、例えば店舗販売員が再度のチェックインを利用者へ促すことを支援し、顔パス決済時のエラーの発生を抑制できる。
【０１１４】
この変形例において、売買支援サーバ１４は、店舗用チェックイン情報として、利用者の顔パス有効期限を店舗端末１２へさらに通知してもよい。また売買支援サーバ１４は、利用者情報保持部１１１に格納された各利用者の顔パス有効期限を定期的に参照し、顔パス有効期限が切れた利用者を定期的に検出して、その利用者の情報をチェックイン対象店舗の店舗端末１２へ通知してもよい。顔パス有効期限切れの利用者の特定主体は、前者の場合は店舗端末１２となり、後者の場合は売買支援サーバ１４となる。
【０１１５】
第１の実施の形態についての、第１１の変形例に関連する第１２の変形例を説明する。
店舗端末１２の販売支援画面表示部６６は、顔パス有効期限が切れた利用者の情報（例えば氏名と顔写真を含むアイテム）を、顔パス有効期限内の利用者の情報表示領域とは別領域に表示させてもよい。例えば、顔パス有効期限が切れた利用者の情報を、顔パス有効期限内の利用者の情報表示領域では非表示とする一方、メニュー画面、商品選択画面、会計画面それぞれの有効期限切れ情報表示領域にて新たに表示させてもよい。この変形例によると、会計画面において選択候補となる利用者を、顔パス有効期限内の利用者に限定できる。これにより、選択候補となる利用者数を抑制して、店舗販売員による選択の手間を低減できる。また、顔パス有効期限が切れた利用者の情報を販売支援画面に常時表示させることで、その利用者が来店した際に、店舗販売員は再度のチェックインを促すための声掛けを実施しやすくなり、顔パス決済時のエラーの発生を抑制できる。
【０１１６】
なお、販売支援画面表示部６６は、顔パス有効期限が切れた利用者のうち、顔パス有効期限切れが特定された日時が新しい利用者の情報ほど、強調した態様で販売支援画面に表示させてもよい。例えば、有効期限切れ情報表示領域において、他の利用者の情報より上段に表示させてもよく、強調するための色やオブジェクトを付加して表示させてもよい。最近顔パス有効期限切れとなった利用者の方が、店舗へ来訪する可能性が高いと想定されるところ、その利用者が来店した際に、店舗販売員は再度のチェックインを促すための声掛けを実施しやすくなる。
【０１１７】
第１の実施の形態についての、第１３の変形例を説明する。
店舗端末１２の販売支援画面表示部６６は、販売支援画面としての顔写真の選択画面（例えば図１０の顔パス決済指定エリア１８４）において、チェックインした複数の利用者それぞれの来店予定時刻に応じた態様で、各利用者の氏名および顔写真を含むアイテムを表示させてもよい。好適には、現在時刻と来店予定時刻が相対的に近い利用者のアイテムを、現在時刻と来店予定時刻が相対的に離れた利用者のアイテムより強調した態様で表示させる。例えば、強調するための色やオブジェクトを付加して表示させてもよい。また、現在時刻と来店予定時刻が近い利用者のアイテムほど、顔パス決済指定エリア１８４の上段で表示させてもよい。現在時刻と来店予定時刻が近い利用者は、現在来店する可能性が高い利用者であると想定されるため、顔写真の選択画面において利用者アイテムの選択を容易にすることができる。
【０１１８】
この変形例において、購入者端末１０、店舗端末１２、または売買支援サーバ１４は、来店時刻推定部をさらに備える。第９の変形例の有効期間決定部と同様に、来店時刻推定部は、チェックイン対象店舗の所在地と、購入者端末１０の現在位置に応じて、現在位置から店舗への移動の所要時間を推定する。来店時刻推定部は、チェックイン時刻から移動の所要時間を経過させた時刻を来店予定時刻として特定する。購入者端末１０、店舗端末１２、売買支援サーバ１４のいずれが来店時刻推定部を備える場合も、来店時刻推定部による推定処理に必要な情報（例えばチェックイン時刻、購入者端末１０の現在位置、店舗の所在地、移動手段等）は、購入者端末１０から売買支援サーバ１４へのチェックイン情報の通知、売買支援サーバ１４から店舗端末１２への店舗用チェックイン情報の通知により伝達してよい。来店時刻推定部が特定した来店予定時刻も同様に伝達してよい。
【０１１９】
第１の実施の形態についての、第１４の変形例を説明する。
店舗端末１２の販売支援画面表示部６６は、販売支援画面としての顔写真の選択画面（例えば図１０の顔パス決済指定エリア１８４の表示画面）を表示する前に、確認コードの入力画面を表示させてもよい。そして顔写真の選択画面では、確認コードの一部のデータに整合する顔写真のみを表示させてもよい。また、確認コードの一部のデータに整合する顔写真を、不整合の顔写真より強調した態様（エリアの上段、大きいサイズ、強調色、所定のオブジェクトを付加した態様）で表示させてもよい。確認コードの一部のデータは、確認コードの１桁目の数字であってもよく、１桁目および２桁目の数字列であってもよく、ここでは「限定コード」と呼ぶ。この場合、売買支援サーバ１４は、確認コードを保持して、確認コードから限定コードを抽出し、限定コードを含む店舗用チェックイン情報を店舗端末１２へ提供してもよい。この変形例によると、不正防止効果を維持しつつ、選択候補となる利用者数を抑制し、店舗販売員による選択の手間を低減させることができる。
【０１２０】
第１の実施の形態についての、第１５の変形例を説明する。
上記実施の形態では、売買支援サーバ１４の決済許否判定部１３０は、決済要求に係る利用者の顔パス有効期限が切れていた場合に、商品代金の決済を禁止することとした。変形例として、決済要求に係る利用者の顔パス有効期限が切れていても、決済金額が所定金額（例えば１万円）以下の場合は、決済を許可してもよい。また第１０の変形例に関連して、決済要求に係る利用者が決済対象店舗の常連客である場合は、顔パス有効期限による決済許否判定をスキップしてもよい。言い換えれば、決済要求に係る利用者が決済対象店舗の常連客でない場合に、顔パス有効期限による決済許否判定を実行してもよい。
【０１２１】
第１の実施の形態についての、第１６の変形例を説明する。
上記実施の形態では、利用者は自身の顔写真を売買支援サーバ１４へ登録し、売買支援サーバ１４はチェックインを契機に利用者の顔写真を店舗端末１２へ提供し、店舗販売員は、商品購入者と選択画面の顔写真とを見比べることとした。変形例として、利用者（購入者）を識別するために顔写真以外の画像が用いられてもよく、すなわち特定の利用者を他者と区別して認識可能な画像であればよく、利用者の外見の特徴を示す画像であればよい。例えば、利用者の外見の特徴を反映したキャラクターでもよく、利用者をモデルとした肖像画の画像データであってもよい。
【０１２２】
第１の実施の形態についての、第１７の変形例を説明する。
現在、電子決済の手段は多様化しており、例えば、クレジットカード決済に加え、プリペイドカード決済、デビットカード決済、通信キャリア一括決済、送金サービス等が存在する。本変形例では、電子決済の多様な手段に対応した顔パス決済を実現することにより、利用者の利便性を一層高める商品売買システム１００を提案する。
【０１２３】
利用者は、自身で使用可能な複数の決済手段について、各決済手段を用いた決済に必要な情報（以下、「決済必要情報」と呼ぶ。）を購入者端末１０へ入力する。購入者端末１０の利用者情報登録部３４は、入力情報を売買支援サーバ１４へ送信し、売買支援サーバ１４は、利用者が使用可能な複数の決済手段それぞれの決済必要情報を利用者情報保持部１１１に記憶する。
【０１２４】
また利用者は、各決済手段による決済順序を示す情報（以下、「決済順序情報」と呼ぶ。）を購入者端末１０へ入力する。購入者端末１０の利用者情報登録部３４は、入力情報を売買支援サーバ１４へ送信し、売買支援サーバ１４は、利用者が入力した決済順序情報を利用者情報保持部１１１に記憶する。売買支援サーバ１４の決済処理部１３２は、上記実施の形態と同様に、決済許否判定部１３０により決済の実行が許可されたことを条件として、購入代金の電子決済を支援するための以下の処理を実行する。
【０１２５】
決済処理部１３２は、利用者情報保持部１１１に記憶された電子決済を行うべき利用者の決済順序情報を参照し、決済順序情報が定める順序で電子決済の依頼（使用する決済手段の決済必要情報を設定した電文）を、各決済手段に対応する所定の決済サーバ１６へ送信する。例えば、プリペイドカード決済→デビットカード決済→クレジットカード決済という順序が登録されていれば、決済処理部１３２は、まずプリペイドカード決済を試みる。購入金額がプリペイドカードのチャージ金額を超過していれば、次にデビットカード決済を試みる。デビットカード決済に用いる口座の残高が不足していれば、次にクレジットカード決済を試みる。
【０１２６】
この変形例によると、利用者が使用可能な複数の決済手段による電子決済を、利用者が所望する順序で実行できる。また極力、電子決済を成功させるよう制御することで、口座残高不足等に起因する電子決済の失敗を抑制し、利用者の利便性を向上させる。
【０１２７】
なお、個々の決済手段の中でも複数の決済方法が存在する場合がある。例えば、デビットカード決済であれば、銀行Ａに開設した口座、銀行Ｂに開設した口座をそれぞれ選択することができる。このような場合に、利用者は、個々の決済手段内での決済順序、例えばデビットカード決済における複数の保有口座の選択順序を含む決済順序情報を購入者端末１０に入力する。売買支援サーバ１４の利用者情報保持部１１１は、個々の決済手段内での決済順序を含む決済順序情報を記憶する。売買支援サーバ１４の決済処理部１３２は、決済順序情報が定める順序で決済手段を順次選択し、さらに個々の決済手段内での決済方法を決済順序情報にしたがって順次選択する。そして、決済順序情報に則した決済手段に対応する決済サーバ１６に対して、その決済手段における決済方法を指定する（例えば購入代金を引き落とすべき口座を指定する）決済必要情報を設定した電文を送信する。
【０１２８】
第１の実施の形態についての、第１８の変形例を説明する。
実施の形態で提案した顔パス決済は、来訪予定店舗に対するチェックイン操作をユーザに実施してもらう必要がある。言い換えれば、来店前のチェックインという付加的なオペレーションをユーザに課す。そこで顔パス決済のビジネスを普及させるために、チェックインをユーザに「使ってもらう」ものとするため、本変形例では、チェックインにインセンティブや利便性を用意する技術を提案する。なお、下記の１）から７）は、それらの全てもしくは一部を任意に組み合わせてよいことはもちろんである。
【０１２９】
１）クーポンを選択したチェックイン：
利用者は、チェックイン時に、店舗で利用したいクーポンを予め選択する。利用者により選択されたクーポンの情報は店舗側へ通知され、店舗での顔パス決済時に、利用者がチェックインにおいて選択したクーポンを自動適用した会計金額にて決済を実行する。
【０１３０】
システム構成の一例を説明する。売買支援サーバ１４の店舗情報保持部１１２には、各店舗が利用者へ提供する１つ以上のクーポンの情報が予め格納される。購入者端末１０は、店舗詳細画面１４０を表示するべき際に、店舗情報とともにクーポン情報を売買支援サーバ１４から取得し、クーポン情報を店舗詳細画面１４０に表示させる。店舗詳細画面１４０において、利用者は、所望のクーポンを選択した上でチェックイン操作を実施する。
【０１３１】
続いて購入者端末１０は、売買支援サーバ１４へ送信するチェックイン情報に、利用者が選択したクーポンを示す情報（以下、「選択クーポン情報」と呼ぶ。）を付加する。売買支援サーバ１４は、チェックイン先店舗の店舗端末１２へ、利用者の顔写真とともに選択クーポン情報（割引額を含む）を送信する。店舗端末１２は、選択クーポン情報を顔パス決済画面１９０で表示させる。また店舗端末１２は、商品やサービスの元の販売価格から、選択クーポン情報が示す割引額を差し引いた金額を会計金額として決定して、顔パス決済画面１９０に表示させる。決済実行時、店舗端末１２は、割引後の会計金額を指定した決済要求を売買支援サーバ１４へ送信して電子決済を実行させる。
【０１３２】
２）クーポン発行：
チェックイン時や、初回来店時、来店回数１０回目等、予め定められたイベントが発生したタイミングでクーポンを発行する。顔パスによる支払時に、事前のチェックイン時に発行されたクーポンが自動適用された会計金額にて決済を実行する。
【０１３３】
システム構成の一例として、上記１)に類似する構成であってもよい。ただし、売買支援サーバ１４は、第５の変形例で記載したチェックイン履歴と、第１０の変形例で記載した決済履歴を保持する。さらに、クーポンを発行すべきタイミングか否かを判定するための基準であり、言い換えれば、クーポン発行イベントを実行すべき条件（以下、「クーポン発行条件」と呼ぶ。）を保持する。売買支援サーバ１４は、購入者端末１０からチェックイン情報を受け付けた場合に、利用者のチェックイン履歴と決済履歴を参照し、クーポン発行条件が充足されたか否かを判定する。クーポン発行条件が充足された場合、売買支援サーバ１４は、店舗情報とともにクーポン情報を購入者端末１０へ提供し、購入者端末１０は、クーポン情報を店舗詳細画面１４０に表示させる。以降の処理は、上記１)と同じである。
【０１３４】
３）時限クーポン：
チェックイン時に、利用者の来店を促進する目的で、所定の有効期間（例えば１時間等）を設定した時限クーポンを発行する。顔パスによる支払時に、事前のチェックイン時に発行された時限クーポンが、その有効期限に応じて自動適用された会計金額にて決済を実行する。
【０１３５】
システム構成の一例として、上記１)に類似する構成であってもよい。ただし、売買支援サーバ１４が保持し、購入者端末１０および店舗端末１２へ提供されるクーポンは時限クーポンであり、すなわちそのクーポン情報には、チェックインから１時間等の有効期間を示すデータが含まれる。購入者端末１０は、クーポン情報としてクーポンの有効期間も表示させて利用者へ提示する。また売買支援サーバ１４は、利用者の顔写真、クーポン情報とともに利用者のチェックイン時刻を店舗端末１２へ提供する。店舗端末１２は、利用者のチェックイン時刻から会計時刻（例えば現在時刻）までの時間にもとづいて、時限クーポンが有効か否かを判定する。有効期間が途過してなければ、言い換えれば、会計タイミングが時限クーポンの有効期間内であれば、店舗端末１２は、商品やサービスの元の販売価格から、時限クーポンが示す割引額を差し引いた金額を会計金額として決定する。
【０１３６】
４）コメントを付加したチェックイン：
来店前に予め店員に伝えておきたい事項などの情報（以下、「コメント」と呼ぶ。）をコメント欄に入力してからチェックインを実施する。このコメントは店舗側へ通知される。店員はチェックイン者の顔写真とともにコメントを確認して、お客様のおもてなしの準備を予め実施できる。例えば、利用者の購買履歴等を確認して、今回お勧めする商品を予め見繕うことができる。また、コメントで指定された利用者の所望の商品を店頭に並べ、また、その商品情報を調べておく等の準備ができる。
【０１３７】
システム構成の一例を説明する。購入者端末１０は、利用者が任意のコメントを入力可能なコメント欄を設けた店舗詳細画面１４０を表示させる。コメントの文字数には制限を設けてもよく、例えば、入力可能な文字数を最大１００字にするようコメント欄を設定してもよい。購入者端末１０は、コメント欄に入力されたコメントを含むチェックイン情報を売買支援サーバ１４へ送信し、売買支援サーバ１４は、そのコメントを含む店舗用チェックイン情報を店舗端末１２へ送信する。店舗端末１２の販売支援画面表示部６６は、販売支援画面としてデフォルト表示される初期画面（例えばメニュー選択画面）に、自店舗にチェックイン済みの利用者の氏名および顔写真を表示し、さらに各利用者に対応づけて（例えば利用者の顔写真の近傍位置に）利用者がチェックイン時に入力したコメントを表示させる。
【０１３８】
５）来店目的を選択してチェックイン：
利用者は、今回の来店目的を予め選択してからチェックインする。来店目的を示す情報（以下、「来店目的情報」と呼ぶ。）は店舗側へ通知され、店舗端末１２は、チェックイン者の氏名、顔写真とともに来店目的を表示する。これにより店員は、利用者の目的を事前に把握した上で、来店した利用者へ適切な声掛けや、商品紹介を実施できる。また、来店目的が例えば「１人で商品を閲覧したい」であれば、利用者への声掛けをあえて抑制し、利用者に自由に商品を閲覧させるよう配慮することもできる。
【０１３９】
この変形例の商品売買システム１００の構成は上記４)に類似する。購入者端末１０の店舗詳細画面１４０に、コメント欄に代えて来店目的の選択欄を設ける。そして、利用者による選択内容をチェックイン情報に付加し、店舗端末１２まで伝達する。
【０１４０】
６）店員の顔写真付き応答：
利用者がチェックインしたタイミングで、チェックイン先の店員の顔写真付きの応答メッセージを利用者へ提示する。６−１）チェックインの都度、店員がコメントを作成して返信してもよく、６−２）固定文言を返信してもよい。利用者と店舗店員のコミュニケーションを支援して、利用者の来店を促進できる。
【０１４１】
まず、上記６−２)のシステム構成例を説明する。売買支援サーバ１４は、店舗が予め登録した店員の顔写真と、固定の応答コメントを店舗情報保持部１１２に保持する。売買支援サーバ１４は、購入者端末１０からチェックインを受け付けた場合に、その応答として、チェックイン先の店舗に対応づけられた店員の顔写真と応答コメントを店舗情報保持部１１２から取得して購入者端末１０へ提供する。購入者端末１０は、チェックイン先の店員の顔写真と応答コメントを表示させる。なお、売買支援サーバ１４は、乱数列のデータとともに、店員の顔写真と応答コメントを購入者端末１０へ提供してもよい。購入者端末１０は、チェックイン画面１５０に、確認コードともに、店員の顔写真と応答コメントを表示させてもよい。
【０１４２】
次に、上記６−１）のシステム構成例を説明する。店舗端末１２は、自店舗へチェックインした利用者に対する応答コメントを入力するコメント入力欄を設けたコメント入力画面を表示させる。店員は、コメント入力画面のコメント入力欄に、利用者に応じた応答コメントを入力する。応答コメントは例えば、「○○様へのお勧めの商品として△△を用意しています」等である。店舗端末１２は、応答コメントを売買支援サーバ１４へ送信し、売買支援サーバ１４は、その応答コメントを、店舗が予め登録した店員の顔写真とともに購入者端末１０へ送信する。購入者端末１０は、チェックイン後の所定の画面に、チェックイン先の店員の顔写真と応答コメントを表示させる。
【０１４３】
７）カードやメダルの取得
チェックインしたタイミングで、例えば有名タレントグループのカードをランダムに発行する。取得したカードやメダルはホルダに保管できる。
【０１４４】
システム構成の一例を説明する。売買支援サーバ１４は、カードやメダル、所定のプレミアム画像等の、チェックイン特典情報を予め保持する。売買支援サーバ１４は、購入者端末１０からチェックイン情報を受信すると、チェックイン特典情報を購入者端末１０へ送信する。乱数列のデータとともにチェックイン特典情報を購入者端末１０へ送信してもよい。購入者端末１０は、売買支援サーバ１４から提供されたチェックイン特典情報を画面に表示させる。また利用者の操作に応じて、チェックイン特典情報をローカルの記憶領域に永続的に記憶させる。
【０１４５】
第１の実施の形態についての、第１９の変形例を説明する。
実施の形態で示したように、顔パス決済のためのチェックインは、利用者が来店したい店舗のページにて手動でチェックイン操作を実施することを基本とする。本変形例では、利用者の利便性を一層高めるために、ＩＣＴ技術によりチェックインをサポートする技術を提案する。なお、以下の１）から３）のいずれにもついても、決済時の確認コードの確認（照合）は必要である。また１）から３）の任意の組み合わせが可能である。
【０１４６】
１）オートチェックイン：
購入者端末１０においてオートチェックイン機能およびＧＰＳ機能をオンにしておくことで、利用者が店舗近傍に来たときに自動的に店舗へチェックインする。すなわち購入者端末１０の現在位置に応じて自動チェックインを実行する。このシステム構成例は、第３の変形例として既述であるため省略する。
【０１４７】
２）決まった時間にチェックイン：
曜日や時間指定で自動的にチェックインを実行する。このシステム構成例は、第３の変形例に類似する。購入者端末１０は、利用者が予め購入者端末１０に登録した日時に至ったことを検出すると、利用者が予め購入者端末１０に登録した店舗に対して、第３の変形例に記載した自動チェックイン処理を実行する。
【０１４８】
３）チェックイン高速化：
既述したように、実施の形態では、ログイン画面、サービス事業者選択画面、店舗選択画面を表示後に、チェックイン操作を実施する店舗詳細画面を表示させることとした。本変形例では、手動によるチェックインを前提としつつも、利用者のオペレーション数を低減するための技術を提案する。具体的には、「お気に入り」からダイレクトにチェックインページへ遷移させる。
【０１４９】
システム構成の一例を説明する。購入者端末１０は、お気に入り画面保持部とお気に入り登録部をさらに備える。特定の店舗の情報を提示してその店舗へのチェックイン操作を受け付ける店舗詳細画面を、お気に入り画面とする旨の登録操作を利用者が入力すると、お気に入り登録部は、その店舗詳細画面のデータをお気に入り画面保持部へ格納する。利用者が購入者端末１０のお気に入り選択画面において特定の店舗名称を選択すると、購入支援画面表示部３６は、店舗選択画面等、前段の画面の表示をスキップして、お気に入り画面保持部に記憶された店舗詳細画面のうち、選択された店舗名称に対応する店舗詳細画面をタッチパネル２０に表示させる。なお、店舗詳細画面がウェブページとして売買支援サーバ１４から提供される場合、お気に入り登録部は、購入者端末１０にインストールされたウェブブラウザのお気に入り機能に、利用者が指定する店舗詳細画面のページを登録してもよいことはもちろんである。
【０１５０】
（第２の実施の形態）
第２の実施の形態では、第１の実施の形態で提案した顔パス決済機能に加えて、サービスの購入希望者に対してサービス提供までの待ち時間の推定値を提示する機能を実現する商品売買システムを提案する。
【０１５１】
これまでにも顧客へおおよその待ち時間を提示するシステムは存在したが、これまでのシステムは、顧客１組あたりの待ち時間を所与の値として予め一律に定めておき、「待ち行列の長さ（待っている顧客数）×顧客１組あたりの待ち時間」により、顧客の待ち時間を決定し、または、待ち行列理論を利用しつつも、平均サービス時間の取得が困難であるため、上記と同様に平均サービス時間を所与の値として定めておき、顧客の待ち時間を決定するレベルにとどまっていた。その結果、顧客へ提示した待ち時間と、実際の待ち時間との乖離が大きくなることがあった。
【０１５２】
そこで第２の実施の形態として提案する商品売買システムでは、第１の実施の形態として提案した携帯端末を活用した顔パス決済のフローにおいて、待ち行列へのエントリや会計といった商品売買にかかわるアクションの発生時刻や発生件数を計測する。そして、それらアクションの実測値であり、言い換えれば、店舗にて直近の過去にサービスを享受した利用者に対する実際のサービス提供状況にもとづいて、店舗の待ち時間を推定する。そして、利用者がチェックインを行おうとする際に待ち時間の推定値を提供する。また、最新の実測値（サービス提供状況）を用いて、定期的に待ち時間の推定を繰り返すことで、待ち時間の推定値の精度を維持する。
【０１５３】
第２の実施の形態における利用者は、典型的にはサービス販売者の店舗へ来訪し、そのサービスを享受して対価を支払う者であり、すなわちサービスを購入する者である。サービスは、例えば、飲食店での飲食提供サービスや、銀行・専売店・量販店等での窓口サービス、病院での医療サービスを含む。待ち時間は、例えば、購入者端末１０を用いて飲食店へチェックインしてから、その飲食店で席に案内されるまで（すなわち飲食店でサービス提供が開始されるまで）の時間である。また、購入者端末１０を用いて携帯電話の専売店へチェックインしてから、その専売店の窓口にて対応が始まるまでの時間である。
【０１５４】
なお、サービスの購入は、商品の購入を包含する概念である。商品の購入における待ち時間は、利用者が店舗へチェックインしてから、その店舗において所望の商品の購入を完了するまでの時間として定義することができる。
【０１５５】
図１２は、第２の実施の形態の商品売買システム１００の構成を示す。以下、第１の実施の形態で既述した説明は適宜省略する。図１２以降の図面において、第１の実施の形態における部材（例えば装置や機能ブロック）と同一もしくは対応する部材には同一の符号を付している。
【０１５６】
店舗端末１２は、店員操作端末１７と店舗内受付端末１８を含む。店員操作端末１７は、第１の実施の形態の店舗端末１２に対応し、典型的には店舗従業員により操作されるタブレット端末である。店員操作端末１７は、第１の実施の形態の店舗端末１２と同様に顔パス決済支援処理を実行し、さらに、サービス提供を待つ利用者の情報を表示し、利用者へのサービス提供状況の入力を受け付けて売買支援サーバ１４へ通知する。店舗内受付端末１８は、チェックインを経ずに店舗へ直接来訪した顧客の情報を待ち行列に登録する情報処理端末であり、顧客または店舗従業員により操作される。店舗内受付端末１８は、待ち番号が記載された受付票を顧客へ発券するものであってもよい。
【０１５７】
売買支援サーバ１４は、第１の実施の形態と同様に顔パス決済支援処理を実行し、さらに、顔パス決済に参加する複数の店舗の待ち行列情報、待ち時間情報を管理する。また売買支援サーバ１４は、各店舗における現在の待ち時間を推定し、その店舗へチェックインしようとする利用者へ待ち時間の推定値を提供する。
【０１５８】
図１３は、図１２の購入者端末１０の機能構成を示すブロック図である。購入者端末１０は、待ち行列入力通知部４４をさらに含む。第１の実施の形態と同様に、店舗詳細画面において利用者がチェックイン操作を行った場合に、チェックイン通知部４０は、チェックイン先として選択された店舗（以下、「選択店舗」とも呼ぶ。）を指定したチェックイン情報を売買支援サーバ１４へ送信する。
【０１５９】
サービス情報取得部３８は待ち時間情報取得部としても機能する。具体的には、サービス情報取得部３８は、チェックイン情報への応答として売買支援サーバ１４から提供された選択店舗における現在の待ち時間の推定値（以下、「推定待ち時間」とも呼ぶ。）を取得する。またサービス情報取得部３８は、選択店舗と同一のグループに属する１つ以上の他店舗（以下、「グループ店舗」とも呼ぶ。）における現在の推定待ち時間も取得する。
【０１６０】
購入支援画面表示部３６は、待ち時間表示部としても機能する。具体的には、店舗詳細画面において利用者がチェックイン操作を行った場合に、サービス情報取得部３８が取得した選択店舗の待ち時間と、グループ店舗の待ち時間を並べて示すチェックイン店舗確認画面をタッチパネル２０に表示させる。チェックイン店舗確認画面の具体例は後述する。
【０１６１】
待ち行列入力通知部４４は、利用者が指定する店舗の待ち行列の中に、利用者を追加するための処理を実行する。具体的には、チェックイン店舗確認画面において利用者が選択店舗とグループ店舗のいずれかに対する来店登録操作を行った場合に、待ち行列入力通知部４４は、待ち行列入力情報を売買支援サーバ１４へ送信する。
【０１６２】
待ち行列入力情報は、第１の実施の形態のチェックイン情報と同じ構成であってよく、例えば利用者ＩＤと、来店登録操作の対象である店舗のＩＤを指定するものであってよい。また、待ち行列入力情報は、利用者が特定の店舗の待ち行列に並ぶ（エントリする）ことを宣言する情報と言える。売買支援サーバ１４は、待ち行列入力情報で指定された店舗を、利用者のチェックイン先の店舗として確定し、利用者の来店を示す店舗用チェックイン情報の提供先として確定する。
【０１６３】
図１４は、図１２の店員操作端末１７の機能構成を示すブロック図である。店員操作端末１７は、待ち行列情報取得部８０と、待ち行列情報表示部８２と、サービス状況通知部８４をさらに含む。待ち行列情報取得部８０は、売買支援サーバ１４が管理する自店舗の待ち行列情報を、通信網を介して取得する。実施の形態では、売買支援サーバ１４が、待ち行列情報を更新した場合に、その情報と対応づけられた店舗の店員操作端末１７へ更新後の待ち行列情報を提供することとする。変形例として、３０秒等の所定時間が経過するたびに、待ち行列情報取得部８０は、売買支援サーバ１４へアクセスして最新の待ち行列情報を取得してもよい。
【０１６４】
待ち行列情報表示部８２は、待ち行列情報取得部８０が取得した待ち行列情報を示す順番待ち管理画面をタッチパネル５０に表示させる。順番待ち管理画面の具体例は後述する。
【０１６５】
サービス状況通知部８４は、順番待ち管理画面に対して、サービス提供の状況の変化を示す情報（以下「サービス状況更新情報」とも呼ぶ。）が入力された場合に、その入力情報を取得する。そして、取得したサービス状況更新情報を売買支援サーバ１４へ送信することにより、売買支援サーバ１４が管理する自店舗の待ち行列情報を更新させる。具体的には、サービス状況通知部８４は、利用者（顧客）に対するサービス提供の開始を示す情報が順番待ち管理画面に入力された場合に、利用者ＩＤ、店舗ＩＤ、サービス開始日時、サービス提供場所を対応づけたサービス状況更新情報を売買支援サーバ１４へ送信する。
【０１６６】
図１５は、図１２の店舗内受付端末１８の機能構成を示すブロック図である。店舗内受付端末１８は、店員操作端末１７の構成に類似し、対応する機能ブロック（同一の符号を付す）を備える。ただし店舗内受付端末１８は、未チェックインの状態で来店した顧客用のユーザインタフェース機能を提供するものであり、具体的には、待ち行列情報の表示機能と待ち行列へのエントリ機能を提供する。店舗内受付端末１８は、待ち行列情報取得部９０と、待ち行列情報表示部９２と、待ち行列入力通知部９４を備える。
【０１６７】
待ち行列情報取得部９０は、店員操作端末１７の待ち行列情報取得部８０に対応し、売買支援サーバ１４が管理する自店舗の待ち行列情報を、通信網を介して取得する。待ち行列情報表示部９２は、待ち行列情報取得部８０が取得した待ち行列情報を示す受付画面をタッチパネル５０に表示させる。受付画面の具体例は後述する。
【０１６８】
待ち行列入力通知部９４は、店舗内受付端末１８が設置された店舗の待ち行列の中に、利用者を追加するための処理を実行する。ここで対象とする利用者は、購入者端末１０による事前チェックインをせずに店舗へ直接来店した顧客である。待ち行列入力通知部９４は、受付画面において利用者が登録操作を行った場合に、予め定められた店舗のＩＤを指定した待ち行列入力情報を売買支援サーバ１４へ送信する。
【０１６９】
図１６は、図１２の売買支援サーバ１４の機能構成を示すブロック図である。売買支援サーバ１４は、待ち行列情報保持部２００と、待ち時間情報保持部２０１と、待ち時間情報提供部２０２と、待ち行列入力受付部２０４と、待ち行列情報更新部２０６と、待ち行列情報提供部２０８と、サービス状況受付部２１０と、待ち時間推定部２１２をさらに含む。
【０１７０】
待ち行列情報保持部２００は、顔パス決済に参加している複数の店舗それぞれの待ち行列情報を記憶する記憶領域である。待ち時間情報保持部２０１は、顔パス決済に参加している複数の店舗それぞれの現在の推定待ち時間を示す待ち時間情報を記憶する記憶領域である。
【０１７１】
図１７は、待ち行列情報保持部２００が記憶する待ち行列情報の構成を示す。待ち行列情報は、管理ＩＤと、店舗ＩＤと、待ち番号と、チェックイン日時と、サービス開始日時と、サービス提供場所を含む。待ち行列情報保持部２００は、店舗毎かつチェックイン済み（来店済み）の利用者毎に、待ち行列情報のレコードを保持する。待ち行列情報は、店舗毎に待ち行列に並ぶ利用者を示す情報とも言える。
【０１７２】
管理ＩＤは、待ち行列のエントリのユニークなＩＤであり、ここでは店舗に対してチェックイン済みの利用者のＩＤとする。待ち番号は、チェックイン済み・来店済みの利用者に提示される店舗毎の整理番号である。サービス開始日時は、店舗において利用者へサービス提供を開始した日時を示す情報である。例えば飲食店においては、利用者を座席へ案内した日時であってもよい。サービス開始場所は、店舗において利用者へサービス提供をする場所を示す情報である。例えば飲食店においては、利用者を案内した座席の識別番号であってもよい。
【０１７３】
図１８は、待ち時間情報保持部２０１が記憶する待ち時間情報の構成を示す。待ち時間情報は、グループＩＤと、店舗ＩＤと、推定待ち時間を含む。待ち時間情報保持部２０１は、店舗毎に待ち時間情報のレコードを保持する。店舗が他の店舗と同一のグループに属する場合、それらの店舗のレコードには予め同じグループＩＤが設定される。なお、待ち時間情報のうちグループＩＤと店舗ＩＤは原則固定であり、その一方、待ち時間は随時更新される。
【０１７４】
複数の店舗のグループ化について、例えば、経営者が同一の複数の店舗、同じ企業グループに属する複数の店舗、業務提携している複数の店舗等に対して同一のグループＩＤを設定してもよい。また、地理的に近傍に位置する複数の店舗、言い換えれば、店舗間の距離が所定範囲内の複数の店舗に対して同一のグループＩＤが付与されてもよい。また、これらの条件の任意の組み合わせにより店舗のグループを設定してもよい。
【０１７５】
図１６に戻り、待ち時間情報提供部２０２は、購入者端末１０から送信されたチェックイン情報をチェックイン受付部１２０が受け付けた場合に、チェックイン情報で指定された選択店舗の待ち時間を待ち時間情報保持部２０１から取得する。それとともに、選択店舗と同一のグループＩＤが設定されたグループ店舗の待ち時間も待ち時間情報保持部２０１から取得する。待ち時間情報提供部２０２は、選択店舗の待ち時間と、グループ店舗の待ち時間の両方を、チェックイン情報の送信元の購入者端末１０へ送信する。
【０１７６】
待ち行列入力受付部２０４は、購入者端末１０および店舗内受付端末１８から送信された待ち行列入力情報を受け付ける。待ち行列情報更新部２０６は、待ち行列入力受付部２０４が受け付けた待ち行列入力情報にもとづいて、待ち行列情報保持部２００に格納された待ち行列情報を更新する。
【０１７７】
具体的には、待ち行列情報更新部２０６は、待ち行列入力情報で指定された利用者ＩＤと店舗ＩＤを設定した新規レコードを待ち行列情報保持部２００に追加し、そのレコードにさらに以下の情報を記録する。すなわち待ち行列情報更新部２０６は、店舗ＩＤで特定される店舗について予め定められた待ち番号の体系にしたがって待ち番号を採番して記録する。また、待ち行列入力情報を受け付けた日時をチェックイン日時として記録する。
【０１７８】
待ち行列情報提供部２０８は、待ち行列情報保持部２００が保持する待ち行列情報の更新状況を監視し、ある店舗の待ち行列情報が更新された場合に、その店舗の店員操作端末１７と店舗内受付端末１８に対して更新後の待ち行列情報を送信する。例えば、ある店舗ＩＤの待ち行列情報が更新された場合に、その店舗ＩＤに紐づけられた１つ以上の待ち行列情報を提供する。このとき、待ち時間情報保持部２０１に格納された当該店舗の待ち時間もあわせて送信する。これにより、最新の待ち行列情報と待ち時間を反映した順番待ち管理画面（店員操作端末１７）と受付画面（店舗内受付端末１８）を表示させる。
【０１７９】
サービス状況受付部２１０は、店員操作端末１７から送信されたサービス状況更新情報を受け付ける。待ち行列情報更新部２０６は、サービス状況受付部２１０が受け付けたサービス状況更新情報にもとづいて、待ち行列情報保持部２００に格納された待ち行列情報を更新する。具体的には、待ち行列情報更新部２０６は、サービス状況更新情報で指定された利用者ＩＤ（管理ＩＤ）および店舗ＩＤで特定されるレコードに対して、サービス状況更新情報で指定されたサービス開始日時とサービス提供場所を追加して記録する。既述したように、更新後の待ち行列情報は、待ち行列情報提供部２０８により、店員操作端末１７および店舗内受付端末１８へ提供される。
【０１８０】
待ち時間推定部２１２は、各店舗の最新のサービス提供実績にもとづいて各店舗の現在の待ち時間を推定し、推定した現在の待ち時間によりそれまで待ち時間情報保持部２０１に格納された各店舗の待ち時間の値を更新する。待ち時間推定部２１２は、定期的に、例えば先の推定処理から１時間や３０分等の所定時間が経過するたびに、各店舗の待ち時間の推定処理および更新処理を繰り返す。更新後の待ち時間情報は、待ち時間情報提供部２０２により、購入者端末１０へ提供される。
【０１８１】
ここで、ある１つの店舗（「特定店舗」と呼ぶ。）についての待ち時間の算出方法を説明する。待ち時間推定部２１２は、待ち行列情報保持部２００を参照し、特定店舗のＩＤが設定された１つ以上の待ち行列情報レコードの中から、直近にサービス提供が開始された所定数のレコードを抽出する。抽出するレコード数は、商品売買システム１００の管理者の知見や経験により決定されてよく、例えば、サービス開始日時が新しい方から５つのレコードを抽出してもよい。
【０１８２】
待ち時間推定部２１２は、抽出した各レコードに記録されたチェックイン日時からサービス開始日時までの時間を待ち時間として求め、抽出したレコードの待ち時間の平均値を、特定店舗における現在の待ち時間として決定する。すなわち直近にサービス提供が開始された所定数の待ち行列情報レコードにもとづいた、待ち時間の移動平均値を現在の待ち時間として決定する。ただし、平均値の算出方法に制限はなく、例えば各レコードの待ち時間を求め、サービス開始日時が新しいものほど重い重み付けを付与して算出した加重平均値を現在の待ち時間として決定してもよい。
【０１８３】
なお実施の形態では、待ち時間の起点としてチェックイン日時を用いることとし、具体的には、購入者端末１０から送信された待ち行列入力情報を売買支援サーバ１４が受け付けた日時を使用する。変形例では、待ち時間の起点として、購入者端末１０から送信されたチェックイン情報を売買支援サーバ１４が受け付けた日時を使用してもよく、また、売買支援サーバ１４が店舗用チェックイン情報を店員操作端末１７へ送信した日時を使用してもよい。すなわち待ち時間推定部２１２は、利用者によるチェックイン操作に関する時刻と、店舗におけるサービス提供開始時刻にもとづいて待ち時間を推定してもよい。
【０１８４】
以上の構成による商品売買システム１００の動作を以下説明する。第２の実施の形態の商品売買システム１００の動作は、第１の実施の形態で既述した商品売買システム１００の動作が前提となる。第１の実施の形態の商品売買システム１００の動作と同じ動作は適宜説明を省略し、主に差分を説明する。なお、以下の例での店舗はレストランとする。
【０１８５】
図７の店舗詳細画面１４０においてチェックイン操作が検出されると、購入者端末１０のチェックイン通知部４０は、チェックイン情報を売買支援サーバ１４へ送信する。売買支援サーバ１４のチェックイン受付部１２０は、購入者端末１０から送信されたチェックイン情報を受信する。待ち時間情報提供部２０２は、チェックイン情報が示す選択店舗の推定待ち時間と、選択店舗に対応づけられたグループ店舗の推定待ち時間を、待ち時間情報保持部２０１から取得して購入者端末１０へ送信する。購入者端末１０のサービス情報取得部３８は、チェックイン情報通知に対する売買支援サーバ１４の応答として待ち時間情報を受信する。購入支援画面表示部３６は、選択店舗とグループ店舗の推定待ち時間を提示するチェックイン店舗確認画面を表示させる。
【０１８６】
図１９は、購入者端末１０に表示されるチェックイン店舗確認画面２２０を示す。選択店舗情報エリア２２２には、選択店舗の現在の推定待ち時間を表示し、グループ店舗情報エリア２２４には、グループ店舗の現在の推定待ち時間を表示する。図１９では、売買支援サーバ１４において、地図上での位置が近い渋谷店、原宿店、恵比寿店が同一グループとして設定されている例を示している。利用者は、選択店舗およびグループ店舗の待ち時間を勘案して、来店登録する店舗を選択し、その店舗の登録ボタン２２６をタップする（「登録操作」と呼ぶ。）。チェックイン店舗確認画面２２０において特定の店舗に対する登録操作が検出されると、待ち行列入力通知部４４は、登録操作対象店舗を指定した待ち行列入力情報を売買支援サーバ１４へ送信する。売買支援サーバ１４は、登録操作対象店舗の待ち行列へ利用者を追加する。
【０１８７】
ここで、待ち行列への利用者の追加は、店舗内受付端末１８を介して行われることもある。図２０は、店舗内受付端末１８に表示される受付画面２３０を示す。店舗内受付端末１８の待ち行列情報取得部９０は、売買支援サーバ１４から提供された自店舗の待ち行列情報を取得する。待ち行列情報表示部９２は、自店舗の待ち行列情報から、サービス提供を待つ利用者の数と推定待ち時間を抽出する。例えば、売買支援サーバ１４から提供された待ち行列情報のレコード数を、サービス提供待ちの利用者数と特定してもよい。なお、サービス提供待ちの利用者には、購入者端末１０を介してチェックインした利用者と、店舗内受付端末１８を介して登録した利用者の両方が含まれる。待ち行列情報表示部９２は、サービス提供待ちの利用者数と推定待ち時間を、受付画面２３０の待ち時間情報エリア２３２に表示させる。
【０１８８】
購入者端末１０によるチェックインをせずに店舗へ直接来店した利用者は、受付画面２３０に表示された待ち時間等を確認し、登録ボタン２３４をタップする（「登録操作」と呼ぶ。）。受付画面２３０において登録操作が検出されると、店舗内受付端末１８の待ち行列入力通知部９４は、自店舗を指定した待ち行列入力情報を売買支援サーバ１４へ送信する。その際に、利用者ＩＤは未設定であってもよく、店舗内受付端末１８からの情報であることを示す所定の値を設定してもよい。
【０１８９】
売買支援サーバ１４の待ち行列入力受付部２０４は、購入者端末１０および店舗内受付端末１８から送信された待ち行列入力情報を受信する。送信元が購入者端末１０の場合、待ち行列入力受付部２０４は、待ち行列入力情報にもとづいて利用者チェックイン情報（図６（ｂ））を設定して利用者情報保持部１１１へ格納する。また乱数取得部１２２は乱数列を取得し、乱数提供部１２４はその乱数列を購入者端末１０へ提供する。これにより、第１の実施の形態と同様に、利用者へ確認コードが提供される。またチェックイン情報提供部１２６は、店舗用チェックイン情報を店員操作端末１７へ送信する。
【０１９０】
待ち行列入力情報の送信元が購入者端末１０と店舗内受付端末１８のいずれの場合も、待ち行列情報更新部２０６は、チェックイン先の店舗または店舗内受付端末１８が設置された店舗について、その待ち行列情報を更新する。待ち行列情報提供部２０８は、更新後の待ち行列情報を、その待ち行列情報が対応づけられた店舗の店員操作端末１７および店舗内受付端末１８へ提供する。これにより、店員操作端末１７の順番待ち管理画面と、店舗内受付端末１８の受付画面２３０を、更新後の待ち行列情報を反映した内容へ切り替える。
【０１９１】
図２１は、店員操作端末１７に表示される順番待ち管理画面２４０を示す。店員操作端末１７の待ち行列情報取得部８０は、売買支援サーバ１４から送信された自店舗の待ち行列情報を受信する。待ち行列情報表示部８２は、自店舗の待ち行列情報を順番待ちリスト２４２に表示させる。そのときチェックイン日時を来店時刻のフィールドに表示させる。また、待ち行列情報として提供された複数レコードを、来店時刻の昇順に、すなわちチェックイン日時もしくは来店日時が古い順に、順番待ちリスト２４２の上から並べて表示させる。
【０１９２】
店舗の従業員は、順番待ち管理画面２４０を確認して、順番待ちリスト２４２の上に表示された顧客を優先して席に案内し、顧客へのサービス提供を開始する。そのとき従業員は、席に案内する顧客の待ち番号を確認して、その待ち番号を示す順番待ちリスト２４２のレコードをタップし、案内座席の情報を入力した上で、案内ボタン２４４をタップする。案内ボタン２４４は、サービスの提供開始を登録するボタンと言える。案内ボタン２４４がタップされると、店員操作端末１７のサービス状況通知部８４は、利用者へのサービス提供を開始した旨を示すサービス状況更新情報を売買支援サーバ１４へ送信する。
【０１９３】
売買支援サーバ１４のサービス状況受付部２１０は、店員操作端末１７から送信されたサービス状況更新情報を受信する。待ち行列情報更新部２０６は、サービス状況更新情報が示す店舗の待ち行列情報の中から、サービスが開始された顧客のレコードを特定する。そして、特定したレコードに、サービス状況更新情報が示すサービス開始日時・サービス提供場所の値を記録する。待ち時間推定部２１２は、定期的に、各店舗の最近の待ち行列情報を参照し、チェックイン日時とサービス開始日時の差分にもとづいて、各店舗の現在の待ち時間を推定する。そして各店舗についての推定待ち時間のデータを待ち時間情報保持部２０１へ格納することで、最新の推定待ち時間をチェックイン者へ提供する。
【０１９４】
店舗にてサービスの提供を開始した後のシステムの動作は、第１の実施の形態と同様である。すなわち、店舗での会計時に、利用者による事前のチェックイン操作に伴って予め店舗へ通知された利用者の写真と、予め利用者へ通知された確認コードを用いた顔パス決済処理を実行する。
【０１９５】
第２の実施の形態の商品売買システム１００によると、サービス提供待ちの利用者により形成された店舗の待ち行列に対するエントリ時刻と、利用者へのサービス開始時刻を計測し、これらの実測値にもとづいて店舗の待ち時間を推定する。言い換えれば、直近過去の利用者の待ち時間を実測し、その待ち時間にもとづいて、これから店舗へチェックインしようとしている利用者の待ち時間を推定する。また、定期的に直近のサービス提供実績にもとづいて待ち時間を再度推定し、推定値を更新する。これにより、第１の実施の形態で既述した効果に加えて、顔パス決済において必須となる事前チェックイン時に、チェックイン対象店舗の現在の待ち時間として精度の高い推定値を利用者へ提示できる。また、チェックイン実施の意思決定、および、待ち時間の有効活用を支援し、利用者の利便性を高めることができる。
【０１９６】
また、店舗詳細画面１４０で選択された選択店舗の推定待ち時間に加えて、選択店舗と同一のグループに属する他店舗の推定待ち時間も利用者へ提示する。これにより、待ち時間に応じた店舗選択の選択肢を利用者へ提示できる。また販売者にとっても、選択店舗の待ち時間が長い場合でも、グループ店舗への集客を促進できるため、販売の機会損失を回避しやすくなる。
【０１９７】
以上、第２の実施の形態を説明した。この実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。以下変形例を示す。
【０１９８】
第２の実施の形態についての、第１の変形例を説明する。
上記実施の形態では、チェックイン日時とサービス開始日時の差分にもとづいて待ち時間を推定することとした。変形例として、公知の待ち行列理論を活用し、利用者の平均到着率と平均サービス時間の実測値にもとついて待ち時間を推定してもよい。この変形例の構成でも、第２の実施の形態と同様の効果を奏する。
【０１９９】
この変形例では、売買支援サーバ１４の待ち行列情報保持部２００は、待ち行列情報のレコードに、店舗において利用者（顧客）へのサービス提供が終了した日時であるサービス終了日時をさらに保持する。また、店員操作端末１７のサービス状況通知部８４は、顧客へのサービス提供が終了したことを示す情報の入力を検出すると、そのときの現在日時をサービス終了日時として含むサービス状況更新情報を売買支援サーバ１４へ送信する。
【０２００】
例えば、サービス状況通知部８４は、サービス代金（商品代金）の決済処理に成功した旨の情報を売買支援サーバ１４から受け付けた場合に、利用者ＩＤ、店舗ＩＤ、サービス終了日時を対応づけたサービス状況更新情報を売買支援サーバ１４へ送信してもよい。また、図１１に示す顔パス決済画面１９０において決定ボタン１９８がタップされた場合に、同様のサービス状況更新情報を売買支援サーバ１４へ送信してもよい。売買支援サーバ１４のサービス状況受付部２１０は、利用者ＩＤおよび店舗ＩＤで特定される待ち行列情報のレコードに、サービス終了日時を記録する。
【０２０１】
本変形例でも、売買支援サーバ１４の待ち時間推定部２１２は、定期的に各店舗の待ち時間を推定し、待ち時間情報保持部２０１の待ち時間情報を更新する。ここで、ある１つの店舗（「特定店舗」と呼ぶ。）についての待ち時間の算出方法を説明する。待ち時間推定部２１２は、待ち行列情報保持部２００を参照し、特定店舗のＩＤが設定された１つ以上の待ち行列情報レコードの中から、直近にサービス提供が終了した所定数のレコードを抽出する。抽出するレコード数は、商品売買システム１００の管理者の知見や経験により決定されてよく、例えば、サービス終了日時が新しい方から５つのレコードを抽出してもよい。
【０２０２】
待ち時間推定部２１２は、抽出した各レコードに記録されたサービス開始日時からサービス終了日時までの時間をサービス時間として求め、抽出したレコードのサービス時間の平均値を、特定店舗における現在の平均サービス時間として決定する。すなわち直近にサービス提供が終了した所定数の待ち行列情報レコードにもとづいた、サービス時間の移動平均値を現在の平均サービス時間として推定する。
【０２０３】
また待ち時間推定部２１２は、待ち行列情報保持部２００を参照し、特定店舗のＩＤが設定された１つ以上の待ち行列情報レコードの中から、直近の一定期間、例えば、前回待ち時間を推定してから現在までの期間内のチェックイン件数（店舗内受付端末１８からの登録件数を含む）を特定する。具体的には、直近の一定期間内の日時をチェックイン日時とするレコードの件数を、チェックイン件数として特定する。そして、そのチェックイン件数にもとづいて利用者の平均到着率を推定する。言い換えれば、単位時間あたりの特定店舗へのチェックイン頻度を平均到着率として推定する。
【０２０４】
待ち時間推定部２１２は、Ｍ／Ｍ／Ｓの待ち行列モデルに、上記で求めた利用者の平均到着率と、平均サービス時間をあてはめることにより、特定店舗の平均待ち時間を算出し、その値を現在の推定待ち時間として記録する。上記モデルの「Ｓ」の値は店舗毎に予め定められてよく、１組の顧客を案内する単位となる空間の数であってもよい。例えば特定店舗がレストランであれば、顧客の案内先の単位となる座席数、テーブル数、ボックス数等をＳの値として設定してもよい。なお、Ｍ／Ｍ／Ｓの待ち行列モデルは公知のモデル、例えば公知の計算式を使用してもよい。
【０２０５】
また、サービス時間は、売買支援サーバ１４に代わり店員操作端末１７が算出してもよい。具体的には、店員操作端末１７は、顧客へのサービス開始日時を記憶するサービス開始時刻保持部と、サービス時間算出部をさらに備えてもよい。サービス時間算出部は、顧客へのサービス提供が終了したことを示す情報の入力を検出する（例えば、決済成功の通知を売買支援サーバ１４から受け付ける）と、そのときの現在日時をサービス終了日時として決定し、その顧客へのサービス開始日時からサービス終了日時までの時間をサービス時間として算出する。そして店員操作端末１７のサービス状況通知部８４は、サービス状況更新情報として、サービス時間算出部が算出したサービス時間、利用者ＩＤおよび店舗ＩＤを売買支援サーバ１４へ送信してもよい。
【０２０６】
このように、店員操作端末１７は、売買支援サーバ１４に対して、サービス開始時刻とサービス終了時刻を通知してもよく、また、サービス時間そのものを通知してもよい。すなわち、店員操作端末１７は、店舗が顧客へ提供したサービス時間を特定可能な情報を売買支援サーバ１４へ提供すればよい。売買支援サーバ１４は、店員操作端末１７から提供された情報にもとづいてサービス時間を特定し、その一方、自身で管理する情報から顧客の到着率を特定し、これを待ち行列モデルに当てはめて平均待ち時間を推定する。
【０２０７】
また売買支援サーバ１４は、第２の実施の形態に記載の方法と、第１の変形例に記載の方法の両方を使用して、店舗の待ち時間を推定してもよい。そして、短い方の待ち時間を推定待ち時間として利用者へ提示してもよい。この態様によると、サービス開始時点で利用者が店舗に存在することの確実性を高めやすくなり、利用者の不在によりサービスの提供が他者の後に回されてしまうことを防止しやすくなる。また、店舗においてもサービス提供可能となったときに、顧客が来店している可能性が高くなり、効率的なサービス提供を実現しやすくなる。また逆に、長い方の待ち時間を推定待ち時間として利用者へ提示してもよい。この態様によると、事前チェックインした利用者が、推定待ち時間を超えて長時間待たされてしまうことを防止しやすくなる。
【０２０８】
第２の実施の形態についての、第２の変形例を説明する。
上記実施の形態では、売買支援サーバ１４が、１）店舗における各利用者（顧客）へのサービス開始時刻を記憶し、２）店舗における現在の待ち時間を推定し、３）待ち時間の推定値を購入者端末１０へ提供することとした。変形例として、店舗側の装置、例えば店員操作端末１７が、上記１）から３）の少なくとも一部を実行してもよい。この変形例の構成でも、第２の実施の形態と同様の効果を奏する。
【０２０９】
例えば、店員操作端末１７は、実施の形態では売買支援サーバ１４が備えることとした待ち時間推定部２１２を備え、サービス状況更新情報にもとづいて自店舗の待ち時間を推定してもよい。すなわち店員操作端末１７は、上記の１）および２）を実行して、自店舗の待ち時間の推定値を売買支援サーバ１４へ通知してもよい。売買支援サーバ１４は、店員操作端末１７から提供された推定待ち時間を記憶し、当該店舗（もしくは当該店舗と同じグループに属する他店舗）へのチェックインがなされる場合に購入者端末１０へ提供してもよい。
【０２１０】
第２の実施の形態についての、第３の変形例を説明する。
上記実施の形態では言及していないが、売買支援サーバ１４は所定の提供条件が充足されたか否かを判定する提供条件判定部をさらに備えてもよい。売買支援サーバ１４の待ち時間情報提供部２０２は、提供条件判定部が提供条件の充足を検出した場合に、選択店舗に加えてグループ店舗の推定待ち時間を購入者端末１０へ提供する。その一方、提供条件が充足されず、提供条件の充足が未検出であれば、選択店舗の推定待ち時間のみを購入者端末１０へ提供してもよい。
【０２１１】
売買支援サーバ１４の提供条件判定部は、選択店舗の待ち時間が所定の閾値以上である場合に、提供条件が充足されたと判定してもよい。この閾値は、売買支援サーバ１４の管理者が予め定めた固定時間（例えば１時間）であってもよく、利用者が売買支援サーバ１４に予め登録した任意の時間であってもよい。
【０２１２】
また売買支援サーバ１４の待ち時間情報提供部２０２は、チェックイン情報への応答として、選択店舗の推定待ち時間のみを一旦購入者端末１０へ提供してもよい。購入者端末１０の店舗詳細画面１４０においてグループ店舗の情報表示を指示する旨の操作入力を受け付けると、購入者端末１０は、グループ店舗の待ち時間提供要求を売買支援サーバ１４へ送信してもよい。この要求を受け付けると、購入者端末１０の提供条件判定部は、提供条件が充足されたと判定し、待ち時間情報提供部２０２は、グループ店舗の推定待ち時間をさらに購入者端末１０へ提供してもよい。
【０２１３】
第２の実施の形態についての、第４の変形例を説明する。
上記実施の形態では言及していないが、売買支援サーバ１４は、利用者の待ち時間の残りが予め定められた規定時間になったタイミングで、利用者が予め売買支援サーバ１４に登録しておいた連絡先へ、もうすぐサービス提供が開始される旨のメッセージ（以下、「サービス開始アラート」と呼ぶ。）を通知してもよい。この変形例によると、サービス提供の開始時に利用者が店舗に来訪している確実性を高め、利用者が所望のサービスを享受することを支援できる。
【０２１４】
例えば、売買支援サーバ１４の待ち行列情報更新部２０６は、あるユーザのチェックインに伴い待ち行列情報を待ち行列情報保持部２００に記録すべき際に、現在日時から、チェックイン対象店舗の推定待ち時間を経過させたサービス開始日時の推定値（以下、「推定サービス開始日時」と呼ぶ。）を待ち行列情報に含めて記録してもよい。売買支援サーバ１４は、アラート通知部をさらに備え、アラート通知部は、現在日時と推定サービス開始日時の間隔が規定時間以下になったことを検出すると、規定の連絡先へサービス開始アラートを送信してもよい。
【０２１５】
この規定時間は、売買支援サーバ１４において予め定められた時間でもよく、利用者が予め売買支援サーバ１４に登録した時間でもよく、例えば１５分等に設定されてもよい。規定の連絡先は、典型的にはサービス開始アラートを受信する情報機器であり、例えば、利用者が売買支援サーバ１４に予め登録した購入者端末１０のアドレスでもよい。サービス開始アラートの送信方法は、電子メールでもよく、スマートフォンに対する公知のプッシュ通知でもよい。
【０２１６】
なお、売買支援サーバ１４の待ち行列情報更新部２０６は、待ち時間推定部２１２が店舗の待ち時間を更新した場合に、更新後の推定待ち時間にもとづいて、事前に記録した推定サービス開始日時を更新してもよい。具体的には、更新前の推定待ち時間と更新後の推定待ち時間の差分を、事前に記録した推定サービス開始日時に反映させてもよい。例えば、更新後の推定待ち時間が更新前の推定待ち時間より短くなった場合、短くなった時間分、推定サービス開始日時を早めるよう更新してもよい。この態様によると、最新の推定待ち時間を反映したタイミングでサービス開始アラートを利用者へ通知できる。
【０２１７】
第２の実施の形態についての、第５の変形例を説明する。
第１の実施の形態の変形例としても一部記載したが、売買支援サーバ１４から店員操作端末１７へ提供される店舗用チェックイン情報には、利用者の顔写真に限らず、利用者を他者と区別することができる情報であり、利用者に関する様々な識別情報が設定されてもよい。この識別情報は、必ずしも利用者の外見の特徴を示す情報でなくてもよい。例えば、店舗（の従業員）と利用者との間で予め取り決めた言葉（合い言葉や、符丁等）であってもよい。この場合、利用者は店舗従業員に合い言葉と名前を申告し、それらが正しければ店舗従業員は決済処理を進めさせてもよい。また、利用者の名前だけ売買支援サーバ１４から店員操作端末１７へ提供してもよい。この場合、利用者は店舗従業員に名前を申告し、その名前が店員操作端末１７上のリストに存在すれば店舗従業員は決済処理を進めさせてもよい。
【０２１８】
（第３の実施の形態）
第３の実施の形態では、販売者の店舗が移動販売車等による移動販売店舗（例えば「移動スーパーマーケット」）である場合に、第１および第２の実施の形態で提案した顔パス決済を適用する商品売買システム１００を提案する。
【０２１９】
第３の実施の形態では、第１および第２の実施の形態における販売者店舗へのチェックイン操作が、販売者店舗に対して所望の地域へ来訪するよう指示するための来訪指示操作に置き換わる。具体的には、購入者端末１０の所定画面（例えば店舗詳細画面１４０）における来訪指示操作の入力に伴い、購入者端末１０は、その来訪指示を示す来訪指示情報を売買支援サーバ１４へ送信する。売買支援サーバ１４は、利用者の顔写真に加えて来訪指示情報を店舗端末１２へ送信する。
【０２２０】
来訪指示情報の構成は、第１および第２の実施の形態の店舗用チェックイン情報と同様であるが、販売者店舗が来訪すべき地域および日時を示す情報を含む。来訪指示情報で指定される来訪地域は生活者の生活地域であってもよい。例えば、利用者の住所の近傍地域であってもよく、利用者の職場の近傍地域であってもよく、利用者にとって商品購入に都合のよい地域でよい。これにより販売者は、店舗端末１２において利用者の顔写真とともに、訪問先と訪問日時を認識することができる。
【０２２１】
利用者は、来訪指示操作の入力画面（例えば店舗詳細画面１４０）で、販売者店舗の来訪を指示する地域と日時を都度指定してもよい。また来訪地域については、利用者登録等のタイミングで、移動販売店舗に対する訪問希望地域を売買支援サーバ１４に登録し、売買支援サーバ１４の利用者情報保持部１１１が記憶してもよい。また、販売者店舗が訪問可能な地域や日時が予め定められてもよく、購入者端末１０の店舗詳細画面１４０において選択可能に表示されてもよい。利用者は、自身に都合のよい地域と日時を選択しつつ、所望の販売者店舗（移動販売店舗）に対する来訪指示操作を入力してもよい。
【０２２２】
第３の実施の形態の商品売買システム１００の他の構成は、第１または第２の実施の形態の商品売買システム１００と同様である。例えば、第１の実施の形態で説明した確認コードの照合処理と組み合わせることにより、セキュリティの強度を一層高めてもよい。第３の実施の形態によると、購入者が移動販売店舗において商品を購入する場合も、言い換えれば、販売者店舗が移動販売店舗である場合も顔パス決済を実現できる。例えば、過疎化地域に対する移動販売車による商品販売サービスに対しても、顔パス決済の利便性を提供できる。
第３の実施の形態の技術思想は、以下に付記する構成として表現することもできる。
【０２２３】
（付記１）
商品の購入者が用いる購入者端末と、
商品の販売者が用いる販売者端末と、
通信網を介して前記購入者端末および前記販売者端末と接続されるサーバと、
を備え、
販売者の店舗は移動販売店舗であり、
前記購入者端末は、
販売者の店舗が所望の地域へ来訪するよう指示するための来訪指示操作を購入者から受け付ける受付部を含み、
前記サーバは、
購入者が商品代金を電子決済するために必要な情報である決済情報を保持する決済情報保持部と、
前記購入者端末において前記来訪指示操作がなされた場合に、購入者を識別するための購入者識別情報を前記販売者端末へ提供する購入者情報提供部を含み、
前記販売者端末は、
販売者の店舗にて購入者が商品を購入する際に、前記サーバから通知された購入者識別情報の中から、商品を購入する購入者の情報を販売者に選択させるための選択画面を表示させる選択画面表示部と、
前記選択画面において選択された購入者を指定した決済要求を前記サーバへ通知する決済要求通知部と、を含み、
前記サーバは、前記決済要求で指定された購入者の決済情報を使用して、商品代金の電子決済を実行させる決済処理部をさらに含むことを特徴とする情報処理システム。
【０２２４】
上述した実施の形態および変形例の任意の組み合わせもまた本発明の実施の形態として有用である。例えば、第１の実施の形態についての変形例は、第２の実施の形態、および第２の実施の形態の任意の変形例と組み合わせることができる。第３の実施の形態との任意の組み合わせももちろん可能である。組み合わせによって生じる新たな実施の形態は、組み合わされる実施の形態および変形例それぞれの効果をあわせもつ。また、請求項に記載の各構成要件が果たすべき機能は、実施の形態および変形例において示された各構成要素の単体もしくはそれらの連係によって実現されることも当業者には理解されるところである。
【符号の説明】
【０２２５】
１０  購入者端末、  １２  店舗端末、  １４  売買支援サーバ、  ３６  購入支援画面表示部、  ３８  サービス情報取得部、  ４０  チェックイン通知部、  ６６  販売支援画面表示部、  ７０  チェックイン情報更新部、  ７４  決済要求通知部、  ８４  サービス状況通知部、  １００  商品売買システム、  １２０  チェックイン受付部、  １２６  チェックイン情報提供部、  １３２  決済処理部、  ２１２  待ち時間推定部、  ２０２  待ち時間情報提供部。
【図１】
2014178770.tif 000003
【図２】
2014178770.tif 000004
【図３】
2014178770.tif 000005
【図４】
2014178770.tif 000006
【図５】
2014178770.tif 000007
【図６】
2014178770.tif 000008
【図７】
2014178770.tif 000009
【図８】
2014178770.tif 000010
【図９】
2014178770.tif 000011
【図１０】
2014178770.tif 000012
【図１１】
2014178770.tif 000013
【図１２】
2014178770.tif 000014
【図１３】
2014178770.tif 000015
【図１４】
2014178770.tif 000016
【図１５】
2014178770.tif 000017
【図１６】
2014178770.tif 000018
【図１７】
2014178770.tif 000019
【図１８】
2014178770.tif 000020
【図１９】
2014178770.tif 000021
【図２０】
2014178770.tif 000022
【図２１】
2014178770.tif 000023