特許 7153756 電子決済システム、電子決済方法、及びプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B1)

(11)【特許番号】

(24)【登録日】2022-10-05

(45)【発行日】2022-10-14

(54)【発明の名称】電子決済システム、電子決済方法、及びプログラム

(51)【国際特許分類】

   G06Q 20/22 20120101AFI20221006BHJP

【ＦＩ】

G06Q20/22

【請求項の数】 20

(21)【出願番号】P 2021061502

(22)【出願日】2021-03-31

【審査請求日】2021-03-31

(73)【特許権者】

【識別番号】399037405

【氏名又は名称】楽天グループ株式会社

(74)【代理人】

【識別番号】110000154

【氏名又は名称】弁理士法人はるか国際特許事務所

(72)【発明者】

【氏名】福島 祥子

【審査官】安田 勇太

(56)【参考文献】

【文献】特開２０１０－２３１５８３（ＪＰ，Ａ）

【文献】特開２０２０－１０６９６３（ＪＰ，Ａ）

【文献】特開２０００－２５９７０５（ＪＰ，Ａ）

【文献】特開２０１５－２０３８８７（ＪＰ，Ａ）

【文献】特開２００２－１５０１８４（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｑ １０／００ －９９／００

(57)【特許請求の範囲】

【請求項1】

ユーザが所定の場所を訪れて、前記場所における複数の決済端末の各々で電子決済を実行する場合に、前記電子決済の決済要求を受け付ける電子決済システムであって、
前記決済要求のたびに実行される都度決済、又は、前記複数の決済端末の各々からの複数の前記決済要求が一括された一括決済の何れを実行するかを、前記ユーザに応じて決定する決定手段と、
前記決定手段の決定結果に基づいて、前記都度決済又は前記一括決済を実行する電子決済実行手段と、
を含む電子決済システム。

【請求項2】

前記電子決済システムは、前記ユーザが前記場所を訪れた場合に、前記ユーザのユーザ端末と、前記場所のチェックイン端末と、の少なくとも一方を利用して、前記場所へのチェックインを実行するチェックイン実行手段を更に含み、
前記決定手段は、前記チェックインの後の決済方法として、前記都度決済又は前記一括決済の何れを実行するかを決定し、
前記電子決済実行手段は、
前記チェックインの後に、前記決済要求を受け付けるたびに、前記都度決済を実行し、
前記チェックインの後に受け付けられた前記複数の決済要求に基づいて、前記一括決済を実行する、
請求項１に記載の電子決済システム。

【請求項3】

前記電子決済システムは、前記ユーザが前記場所から離れる場合に、前記ユーザ端末、前記チェックイン端末、及び前記場所の他の端末の少なくとも１つを利用して、前記場所からのチェックアウトを実行するチェックアウト実行手段を更に含み、
前記決定手段は、前記チェックインの後であり、かつ、前記チェックアウトの前の決済方法として、前記都度決済又は前記一括決済の何れを実行するかを決定し、
前記電子決済実行手段は、
前記チェックインの後であり、かつ、前記チェックアウトの前に、前記決済要求を受け付けるたびに、前記都度決済を実行し、
前記チェックインの後であり、かつ、前記チェックアウトの前に受け付けられた前記複数の決済要求に基づいて、前記一括決済を実行する、
請求項２に記載の電子決済システム。

【請求項4】

ユーザが所定の場所を訪れて一連のサービスを利用する場合に、電子決済の決済要求を受け付ける電子決済システムであって、
前記電子決済における前記ユーザの信頼度を取得する信頼度計算手段と、
前記信頼度に基づいて、前記決済要求のたびに実行される都度決済、又は、複数の前記決済要求が一括された一括決済の何れを実行するかを決定する決定手段と、
前記決定手段の決定結果に基づいて、前記都度決済又は前記一括決済を実行する電子決済実行手段と、
を含む 電子決済システム。

【請求項5】

前記決済要求は、前記ユーザのユーザ端末にインストールされた決済アプリを利用して行われ、
前記決定手段は、前記決済アプリを利用して受け付けられた前記決済要求の決済方法として、前記都度決済又は前記一括決済の何れを実行するかを決定し、
前記電子決済実行手段は、前記決済アプリを利用して受け付けられた前記決済要求に基づいて、前記都度決済又は前記一括決済を実行する、
請求項１～４の何れかに記載の電子決済システム。

【請求項6】

前記ユーザは、前記場所を訪れて複数の位置の各々には、前記決済端末が配置され、
前記決定手段は、前記複数の位置の各々に配置された前記決済端末からの前記決済要求に応じた決済方法として、前記都度決済又は前記一括決済を決定し、
前記電子決済実行手段は、
前記複数の位置の各々に配置された前記決済端末から前記決済要求を受け付けるたびに、前記都度決済を実行し、
前記複数の位置の各々に配置された前記決済端末からの前記複数の決済要求に基づいて、前記一括決済を実行する、
請求項１～５の何れかに記載の電子決済システム。

【請求項7】

ユーザが所定の場所を訪れて一連のサービスを利用する場合に、電子決済の決済要求を受け付ける電子決済システムであって、
前記決済要求のたびに実行される都度決済、又は、複数の前記決済要求が一括された一括決済の何れを実行するかを、前記ユーザに応じて決定する決定手段と、
前記決定手段の決定結果に基づいて、前記都度決済又は前記一括決済を実行する電子決済実行手段と、
を含み、
前記決定手段は、
前記一括決済を実行すると決定された場合に、前記複数の決済要求の利用額を合計した合計額が閾値以上であるか否かを判定し、
前記合計額が前記閾値以上であると判定された場合に、前記一括決済から前記都度決済に変更し、
前記電子決済実行手段は、前記一括決済から前記都度決済に変更された後は、前記決済要求が受け付けられるたびに、前記都度決済を実行する、
電子決済システム。

【請求項8】

ユーザが所定の場所を訪れて一連のサービスを利用する場合に、電子決済の決済要求を受け付ける電子決済システムであって、
前記ユーザが利用可能な決済手段の残高に基づいて、前記決済要求のたびに実行される都度決済、又は、複数の前記決済要求が一括された一括決済の何れを実行するかを決定する決定手段と、
前記決定手段の決定結果に基づいて、前記都度決済又は前記一括決済を実行する電子決済実行手段と、
を含む 電子決済システム。

【請求項9】

前記決定手段は、前記ユーザが利用可能な複数の決済手段のうち、前記ユーザにより選択された前記決済手段に基づいて、前記都度決済又は前記一括決済の何れを実行するかを決定する、
請求項１～８の何れかに記載の電子決済システム。

【請求項10】

前記電子決済実行手段は、
前記一括決済を実行する場合に、前記ユーザが利用可能な決済手段の残高が、前記複数の決済要求の利用額を合計した合 計値以上であるか否かを判定し、
前記残高が前記合計額以上であると判定された場合に、前記一括決済を実行し、
前記電子決済システムは、前記ユーザによる、前記一括決済の実行指示を受け付ける実行指示受付手段を更に含み、
前記電子決済実行手段は、前記実行指示が受け付けられた場合に、前記一括決済を実行し、
前記電子決済システムは、前記実行指示が受け付けられる前に、前記残高が前記合計額未満であると判定された場合に、前記ユーザに所定の通知を行う通知手段、
を更に含む請求項１～９の何れかに記載の電子決済システム。

【請求項11】

前記ユーザは、前記電子決済を提供する第１サービスと、前記場所に関する第２サービスと、を利用可能であり、
前記電子決済システムは、
前記ユーザが前記場所を訪れた場合に、前記ユーザのユーザ端末と、前記場所のチェックイン端末と、の少なくとも一方を利用して、前記第１サービスで前記ユーザを識別可能な第１情報を取得する第１情報取得手段と、
前記第１情報又は前記第１情報に関連付けられた第２情報に基づいて、前記場所へのチェックインを実行するチェックイン実行手段と、
を含む請求項１～１０の何れかに記載の電子決済システム。

【請求項12】

前記電子決済実行手段は、前記ユーザのユーザ端末を利用して前記電子決済を実行し、
前記場所には、前記ユーザの生体認証を実行するための認証装置が配置されており、
前記電子決済システムは、前記チェックインが実行された場合には、前記場所において、前記ユーザ端末を利用せずに、前記生体認証によって前記電子決済が実行されることを許可する許可手段、
を含む請求項２、３、又は１１に記載の電子決済システム。

【請求項13】

ユーザが所定の場所を訪れて、前記場所における複数の決済端末の各々で電子決済を実行する場合に、前記電子決済の決済要求をコンピュータが受け付ける電子決済方法であって、
前記コンピュータが、
前記決済要求のたびに実行される都度決済、又は、前記複数の決済端末の各々からの複数の前記決済要求が一括された一括決済の何れを実行するかを、前記ユーザに応じて決定する決定ステップと、
前記決定ステップの決定結果に基づいて、前記都度決済又は前記一括決済を実行する電子決済実行ステップと、
を実行する電子決済方法。

【請求項14】

ユーザが所定の場所を訪れて一連のサービスを利用する場合に、電子決済の決済要求をコンピュータが受け付ける電子決済方法であって、
前記コンピュータが、
前記電子決済における前記ユーザの信頼度を取得する信頼度計算ステップと、
前記信頼度に基づいて、前記決済要求のたびに実行される都度決済、又は、複数の前記決済要求が一括された一括決済の何れを実行するかを決定する決定ステップと、
前記決定ステップの決定結果に基づいて、前記都度決済又は前記一括決済を実行する電子決済実行ステップと、
を実行する電子決済方法。

【請求項15】

ユーザが所定の場所を訪れて一連のサービスを利用する場合に、電子決済の決済要求をコンピュータが受け付ける電子決済方法であって、
前記コンピュータが、
前記決済要求のたびに実行される都度決済、又は、複数の前記決済要求が一括された一括決済の何れを実行するかを、前記ユーザに応じて決定する決定ステップと、
前記決定ステップの決定結果に基づいて、前記都度決済又は前記一括決済を実行する電子決済実行ステップと、
を実行し、
前記決定ステップは、
前記一括決済を実行すると決定された場合に、前記複数の決済要求の利用額を合計した合計額が閾値以上であるか否かを判定し、
前記合計額が前記閾値以上であると判定された場合に、前記一括決済から前記都度決済に変更し、
前記電子決済実行ステップは、前記一括決済から前記都度決済に変更された後は、前記決済要求が受け付けられるたびに、前記都度決済を実行する、
電子決済方法。

【請求項16】

ユーザが所定の場所を訪れて一連のサービスを利用する場合に、電子決済の決済要求をコンピュータが受け付ける電子決済方法であって、
前記コンピュータが、
前記ユーザが利用可能な決済手段の残高に基づいて、前記決済要求のたびに実行される都度決済、又は、複数の前記決済要求が一括された一括決済の何れを実行するかを決定する決定ステップと、
前記決定ステップの決定結果に基づいて、前記都度決済又は前記一括決済を実行する電子決済実行ステップと、
を実行する電子決済方法。

【請求項17】

ユーザが所定の場所を訪れて、前記場所における複数の決済端末の各々で電子決済を実行する場合に、前記電子決済の決済要求を受け付けるコンピュータを、
前記決済要求のたびに実行される都度決済、又は、前記複数の決済端末の各々からの複数の前記決済要求が一括された一括決済の何れを実行するかを、前記ユーザに応じて決定する決定手段、
前記決定手段の決定結果に基づいて、前記都度決済又は前記一括決済を実行する電子決済実行手段、
として機能させるためのプログラム。

【請求項18】

ユーザが所定の場所を訪れて一連のサービスを利用する場合に、電子決済の決済要求を受け付けるコンピュータを、
前記電子決済における前記ユーザの信頼度を取得する信頼度計算手段、
前記信頼度に基づいて、前記決済要求のたびに実行される都度決済、又は、複数の前記決済要求が一括された一括決済の何れを実行するかを決定する決定手段、
前記決定手段の決定結果に基づいて、前記都度決済又は前記一括決済を実行する電子決済実行手段、
として機能させるためのプログラム。

【請求項19】

ユーザが所定の場所を訪れて一連のサービスを利用する場合に、電子決済の決済要求を受け付けるコンピュータを、
前記決済要求のたびに実行される都度決済、又は、複数の前記決済要求が一括された一括決済の何れを実行するかを、前記ユーザに応じて決定する決定手段、
前記決定手段の決定結果に基づいて、前記都度決済又は前記一括決済を実行する電子決済実行手段、
として機能させ、
前記決定手段は、
前記一括決済を実行すると決定された場合に、前記複数の決済要求の利用額を合計した合計額が閾値以上であるか否かを判定し、
前記合計額が前記閾値以上であると判定された場合に、前記一括決済から前記都度決済に変更し、
前記電子決済実行手段は、前記一括決済から前記都度決済に変更された後は、前記決済要求が受け付けられるたびに、前記都度決済を実行する、
プログラム。

【請求項20】

ユーザが所定の場所を訪れて一連のサービスを利用する場合に、電子決済の決済要求を受け付けるコンピュータを、
前記ユーザが利用可能な決済手段の残高に基づいて、前記決済要求のたびに実行される都度決済、又は、複数の前記決済要求が一括された一括決済の何れを実行するかを決定する決定手段、
前記決定手段の決定結果に基づいて、前記都度決済又は前記一括決済を実行する電子決済実行手段、
として機能させるためのプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、電子決済システム、電子決済方法、及びプログラムに関する。

【背景技術】

【0002】

従来、電子決済の利便性を高める技術が知られている。例えば、特許文献１には、ユーザが飲食店を訪れた場合に、ユーザ端末の飲食店アプリで表示させた二次元コードを、この飲食店のテーブルに配置された決済端末に読み取らせることによって、この飲食店にユーザをチェックインさせるシステムが記載されている。ユーザは、チェックインした飲食店における注文と、この飲食店の退店時の電子決済と、をユーザ端末から指示できる。

【先行技術文献】

【特許文献】

【0003】

【文献】特開２０２０－１６０６８９号公報

【発明の概要】

【発明が解決しようとする課題】

【0004】

ユーザによっては、自身が訪れた場所で利用した一連のサービスに関する電子決済を、都度実行したいこともあれば、一括で実行したいこともある。しかしながら、特許文献１の技術では、ユーザがチェックインした飲食店における個々の注文の合計額に応じた電子決済が退店時実行されるだけなので、ユーザの利便性を十分に高めることはできない。

【0005】

本開示の目的の１つは、ユーザが所定の場所を訪れて一連のサービスを利用する場合の電子決済の利便性を高めることである。

【課題を解決するための手段】

【0006】

本開示に係る電子決済システムは、ユーザが所定の場所を訪れて一連のサービスを利用する場合に、電子決済の決済要求を受け付ける電子決済システムであって、前記決済要求のたびに実行される都度決済、又は、複数の前記決済要求が一括された一括決済の何れを実行するかを、前記ユーザに応じて決定する決定手段と、前記決定手段の決定結果に基づいて、前記都度決済又は前記一括決済を実行する電子決済実行手段と、を含む。

【発明の効果】

【0007】

本開示によれば、ユーザが所定の場所を訪れて一連のサービスを利用する場合の電子決済の利便性が高まる。

【図面の簡単な説明】

【0008】

【図1】電子決済システムの全体構成の一例を示す図である。

【図2】第２サービスからチケットを購入する手順の一例を示す図である。

【図3】第１アプリから表示される画面の一例を示す図である。

【図4】ユーザがスタジアムを訪れてチェックインする様子の一例を示す図である。

【図5】ユーザがスタジアムで電子決済を実行する場合の第１アプリの画面の一例を示す図である。

【図6】ユーザがスタジアムで電子決済を実行する場合の第１アプリの画面の一例を示す図である。

【図7】電子決済システムで実現される機能の一例を示す機能ブロック図である。

【図8】第１データベースのデータ格納例を示す図である。

【図9】第２データベースのデータ格納例を示す図である。

【図10】電子決済システムで実行される処理の一例を示すフロー図である。

【図11】電子決済システムで実行される処理の一例を示すフロー図である。

【図12】電子決済システムで実行される処理の一例を示すフロー図である。

【図13】変形例における機能ブロック図の一例である。

【図14】変形例２の電子決済システムの一例を示す図である。

【図15】変形例３の電子決済システムの一例を示す図である。

【図16】変形例４の電子決済システムの一例を示す図である。

【図17】変形例７の履歴確認画面の一例を示す図である。

【図18】変形例８におけるチェックアウト画面の一例を示す図である。

【図19】変形例９における履歴確認画面の一例を示す図である。

【図20】変形例１０の電子決済システムの一例を示す図である。

【発明を実施するための形態】

【0009】

［１．電子決済システムの全体構成］
本開示に係る電子決済システムの実施形態の一例を説明する。図１は、電子決済システムの全体構成の一例を示す図である。図１に示すように、電子決済システムＳは、第１サーバ１０、第２サーバ２０、ユーザ端末３０、チェックイン端末４０、及び決済端末５０を含む。これらは、インターネット等のネットワークＮに接続可能である。電子決済システムＳは、少なくとも１つのコンピュータを含めばよく、図１の例に限られない。

【0010】

第１サーバ１０は、第１サービスのサーバコンピュータである。第１サービスは、電子決済を提供するサービスである。第１サービスは、電子決済の機能だけを提供するサービスに限られず、ＳＮＳ（Social Networking Service）等の他の機能とともに、電子決済の機能を提供するものであってもよい。

【0011】

第１サーバ１０は、制御部１１、記憶部１２、及び通信部１３を含む。制御部１１は、少なくとも１つのプロセッサを含む。記憶部１２は、ＲＡＭ等の揮発性メモリと、ハードディスク等の不揮発性メモリと、を含む。通信部１３は、有線通信用の通信インタフェースと、無線通信用の通信インタフェースと、の少なくとも一方を含む。

【0012】

第２サーバ２０は、第２サービスのサーバコンピュータである。本実施形態では、第２サービスの一例として、チケット販売サービスを説明する。第２サービスは、第１サービスと連携可能なサービスである。第２サービスは、第１サービスとは異なるサービスである。第２サービスは、本実施形態の例に限られず、任意のサービスであってよい。第２サーバ２０は、制御部２１、記憶部２２、及び通信部２３を含む。制御部２１、記憶部２２、及び通信部２３の物理的構成は、それぞれ制御部１１、記憶部１２、及び通信部１３と同様である。

【0013】

ユーザ端末３０は、ユーザが操作するコンピュータである。例えば、ユーザ端末３０は、スマートフォン、タブレット端末、ウェアラブル端末、又はパーソナルコンピュータである。ユーザ端末３０は、制御部３１、記憶部３２、通信部３３、操作部３４、表示部３５、撮影部３６、ＩＣチップ３７、及びＧＰＳ受信部３８を含む。制御部３１、記憶部３２、及び通信部３３の物理的構成は、それぞれ制御部１１、記憶部１２、及び通信部１３と同様である。

【0014】

操作部３４は、タッチパネル等の入力デバイスである。表示部３５は、液晶ディスプレイ又は有機ＥＬディスプレイである。撮影部３６は、少なくとも１つのカメラを含む。ＩＣチップ３７は、任意の規格のチップであってよく、例えば、ＦｅｌｉＣａ（登録商標）のチップ、又は、非接触型規格におけるいわゆるＴｙｐｅＡ若しくはＴｙｐｅＢのチップである。ＧＰＳ受信部３８は、衛星からの信号を受信する受信機を含む。ＧＰＳ受信部３８は、現在位置又は現在日時の取得に利用される。

【0015】

チェックイン端末４０は、ユーザが訪れる場所に配置されたコンピュータである。例えば、チェックイン端末４０は、パーソナルコンピュータ、タブレット端末、又はスマートフォンである。チェックイン端末４０は、制御部４１、記憶部４２、通信部４３、操作部４４、表示部４５、及び読取部４６を含む。制御部４１、記憶部４２、通信部４３、操作部４４、及び表示部４５の物理的構成は、それぞれ制御部１１、記憶部１２、通信部１３、操作部３４、及び表示部３５と同様である。読取部４６は、コードリーダ又はカメラを含む。読取部４６は、チェックイン端末４０の外部に接続されていてもよい。

【0016】

決済端末５０は、電子決済を実行するためのコンピュータである。例えば、決済端末５０は、ＰＯＳ端末、パーソナルコンピュータ、タブレット端末、又はスマートフォンである。決済端末５０は、制御部５１、記憶部５２、通信部５３、操作部５４、表示部５５、及び読取部５６を含む。制御部５１、記憶部５２、通信部５３、操作部５４、表示部５５、及び読取部５６の物理的構成は、それぞれ制御部１１、記憶部１２、通信部１３、操作部３４、表示部３５、及び読取部４６と同様である。

【0017】

なお、第１サーバ１０、第２サーバ２０、ユーザ端末３０、チェックイン端末４０、及び決済端末５０の各々に記憶されるプログラム又はデータは、ネットワークＮを介して供給されてもよい。また、情報記憶媒体に記憶されたプログラム又はデータが、コンピュータ読み取り可能な情報記憶媒体を読み取る読取部（例えば、光ディスクドライブやメモリカードスロット）、又は、外部機器とデータの入出力をするための入出力部（例えば、ＵＳＢポート）を介して供給されてもよい。

【0018】

［２．電子決済システムの概要］
本実施形態では、第１サービスのアプリケーションである第１アプリに基づいて、電子決済が実行される場合を説明する。第１アプリは、ユーザ端末３０にインストールされている。電子決済で利用可能な決済手段は、任意の種類であってよく、例えば、クレジットカード、デビットカード、電子マネー、電子キャッシュ、ポイント、銀行口座、ウォレット、仮想通貨、又はこれらの組み合わせであってもよい。

【0019】

第１サービスでは、ユーザ端末３０のＩＣチップ３７を利用して電子決済が実行されてもよい。第１サービスでは、ユーザ端末３０を利用せずに、ＩＣカード又は磁気カード等の物理的なカードを利用して電子決済が実行されてもよい。第１サービスでは、ユーザの所有物ではなく、ユーザ自身を利用して（即ち、生体認証を利用して）電子決済が実行されてもよい。これらの電子決済でも、任意の決済手段を利用可能である。

【0020】

第２サービスは、ユーザによるチケットの購入申し込みを受け付ける。第２サービスで販売されるチケット自体は、公知のプレイガイドで取り扱い可能なチケットであればよい。例えば、第２サービスでは、スポーツの試合、コンサート、演劇、その他のイベント、映画館、又は美術館等のチケットが販売される。本実施形態では、ユーザが第２サービスを利用して野球の試合のチケットを購入する場合を例に挙げる。まず、ユーザは、第２サービスにログインしてチケットを購入する。

【0021】

図２は、第２サービスからチケットを購入する手順の一例を示す図である。図２に示すように、ユーザがユーザ端末３０から第２サーバ２０にアクセスすると、第２サービスのトップページＰ１が表示される。ユーザは、トップページＰ１から任意の検索条件を入力し、所望のチケットを検索する。ユーザが、所望のチケットの購入申し込みをすると、第２サービスのログインページＰ２が表示される。

【0022】

本実施形態では、第１サービス及び第２サービスで共通のユーザＩＤ及びパスワードが利用される。ユーザは、１組のユーザＩＤ及びパスワードで、第１サービス及び第２サービスの両方にログインできる。ユーザが、入力フォームＦ２０，Ｆ２１にユーザＩＤ及びパスワードを入力してボタンＢ２２を選択すると、第２サービスにログインする。ユーザが第２サービスにログインして支払いの手続きをすると、チケットの購入が完了する。ユーザは、第１サービスを利用してチケットの代金を支払ってもよいし、第２サービスに登録された他の決済手段を利用してチケットの代金を支払ってもよい。

【0023】

チケットの購入が完了すると、ユーザ端末３０には、チケットの購入が完了したことを示す購入完了ページＰ３が表示される。本実施形態では、紙のチケットが印刷されるのではなく、ユーザは、第１アプリを利用してスタジアムにチェックインする。購入完了ページＰ３には、ユーザの購入内容と、当日のチェックイン方法と、が案内される。なお、ユーザは、ブラウザから第１サービスを利用してもよい。この場合、ブラウザの画面を利用してチェックインが実行されてもよい。

【0024】

図３は、第１アプリから表示される画面の一例を示す図である。ユーザがユーザ端末３０を操作して第１アプリを起動させると、第１サーバ１０及びユーザ端末３０の間で、第１サービスにログインするための処理が実行される。第１アプリが起動したタイミングで、ユーザＩＤ及びパスワードの入力が要求されてもよい。本実施形態では、過去に第１サービスにログイン済みであり、ユーザＩＤ及びパスワードの入力が省略される場合を説明する。

【0025】

図３に示すように、ユーザが第１サービスにログインすると、第１アプリのホーム画面Ｇ４が表示される。ホーム画面Ｇ４には、電子決済用のコードＣ４０が表示される。コードＣ４０は、第１サービスでユーザを識別可能なＩＤを含む。このＩＤは、先述したユーザＩＤであってもよいが、本実施形態では、ユーザＩＤとは異なる情報の場合を説明する。以降、このＩＤを、コードＩＤと記載する。

【0026】

コードＩＤには、有効期限が設定される。第１サーバ１０は、あるコードＩＤの有効期限が経過すると、新たなコードＩＤを発行し、コードＩＤ及び有効期限を更新する。コードＩＤ及び有効期限は、ユーザＩＤと関連付けられて第１サーバ１０に保持される。コードＩＤには、有効期限が設定されなくてもよい。コードＣ４０は、コードＩＤ以外の他の情報を含んでもよい。例えば、コードＣ４０は、電子決済用のコードであることを識別可能な情報を含んでもよい。第１サーバ１０は、この情報により、電子決済の実行が要求されていることを識別してもよい。

【0027】

ユーザは、コードＣ４０を利用して電子決済を実行できる。例えば、ユーザは、スタジアムにチェックインした後に、決済端末５０にコードＣ４０を読み取らせると、予め設定された決済手段（図３ではクレジットカード）に基づいて、電子決済を実行できる。コードＣ４０は、スタジアム以外の任意の場所の電子決済で利用可能である。図３に示すように、ユーザがコードＣ４０を利用して電子決済を実行すると、電子決済が完了したことを示す決済完了画面Ｇ５が表示される。決済完了画面Ｇ５には、支払い元になった決済手段、利用日時、支払先、及び利用額が表示される。

【0028】

なお、電子決済の実行方法自体は、種々の手法を利用可能である。例えば、決済端末５０に表示されたコードをユーザ端末３０で読み取る方法、紙等に印刷されて店舗に掲示されたコードをユーザ端末３０で読み取る方法、ユーザ端末３０のＩＣチップ３７を決済端末５０のリーダライタにかざす方法、又はユーザ端末３０に対する操作だけで完結する方法であってもよい。

【0029】

図３に示すように、ホーム画面Ｇ４は、チェックイン用のコードを表示させるためのボタンＢ４１を含む。ユーザがボタンＢ４１を選択すると、チェックイン用のコードＣ６０を含む表示画面Ｇ６が表示部３５に表示される。コードＣ６０は、コードＩＤを含む。コードＣ６０は、コードＩＤ以外の他の情報を含んでもよい。例えば、コードＣ６０は、チェックイン用のコードであることを識別可能な情報を含んでもよい。第１サーバ１０は、この情報により、チェックインの実行が要求されていることを識別してもよい。コードＣ４０が含むコードＩＤと、コードＣ６０が含むコードＩＤと、が異なってもよい。即ち、複数のコードＩＤが発行されてもよい。

【0030】

表示画面Ｇ６に示すように、コードＣ６０は、全国のスタジアムのチェックインで利用できる。コードＣ６０は、スタジアム以外の他の施設へのチェックインでも利用できる。例えば、第１サービスが旅行予約サービスと提携する場合（即ち、第２サービスが旅行予約サービスである場合）には、ユーザは、旅行予約サービスから予約したホテルに、コードＣ６０を利用してチェックインできる。本実施形態では、ユーザは、試合当日にスタジアムを訪れると、第１アプリを起動させて、表示画面Ｇ６にコードＣ６０を表示させる。

【0031】

図４は、ユーザがスタジアムを訪れてチェックインする様子の一例を示す図である。図４に示すように、ユーザは、スタジアムのエントランスに配置されたチェックイン端末４０の読取部４６にコードＣ６０をかざす。チェックイン端末４０は、読取部４６でコードＣ６０を読み取ると、コードＣ６０に含まれるコードＩＤを、第１サーバ１０に送信する。第１サーバ１０は、コードＩＤに関連付けられたユーザＩＤを特定し、このユーザＩＤを第２サーバ２０に送信する。

【0032】

第２サーバ２０は、第１サーバ１０から受信したユーザＩＤに関連付けられたチケットの内容を取得し、チェックインを実行する。チェックインが完了すると、ユーザ端末３０には、チェックインが完了したことを示すチェックイン完了画面Ｇ７（図３）が表示される。チェックイン完了画面Ｇ７には、ユーザが購入したチケットの詳細が表示される。チェックインが完了した場合、チェックイン端末４０は、自身に接続されたプリンタから、ユーザが購入したチケットを発券してもよい。

【0033】

本実施形態では、スタジアムにおける決済方法として、スタジアムにおける電子決済を都度実行する都度決済、又は、チェックインしてからチェックアウトするまでの電子決済を一括して実行する一括決済の何れかを、ユーザが選択できるようになっている。例えば、図３のチェックイン完了画面Ｇ７には、都度決済を選択するためのボタンＢ７０と、一括決済を選択するためのボタンＢ７１と、が表示される。ユーザは、チェックイン時に選択した決済方法を、スタジアムの滞在中に変更可能である。ユーザが何も選択しなければ、都度決済及び一括決済のうち、予め定められた方が自動的に選択される。

【0034】

図４に戻り、チェックインが完了すると、ユーザは、スタジアムのエントランスから入場する。本実施形態では、スタジアムにおける複数の位置に、決済端末５０が配置されている。決済端末５０は、スタジアム付近であれば、スタジアム外に配置されてもよい。ユーザは、スタジアムの任意の位置に移動し、第１アプリを利用して商品を購入できる。スタジアム内を移動する売り子が電子決済に対応する場合には、売り子は、可搬型の決済端末５０を持ち歩いてもよい。

【0035】

図５及び図６は、ユーザがスタジアムで電子決済を実行する場合の第１アプリの画面の一例を示す図である。図５に示すように、ユーザがスタジアムにチェックインすると、チェックイン中のスタジアムを示す情報Ｉ４２、決済方法を変更するためのボタンＢ４３、及びスタジアムにおける電子決済の利用履歴を確認するためのボタンＢ４４がホーム画面Ｇ４に表示される。図５のホーム画面Ｇ４Ａは、都度決済が選択された場合を示し、ホーム画面Ｇ４Ｂは、一括決済が選択された場合を示す。

【0036】

ホーム画面Ｇ４Ａの状態でコードＣ４０が決済端末５０によって読み取られると、都度決済が実行されて決済完了画面Ｇ５が表示される。図５の決済完了画面Ｇ５は、ユーザが、都度決済を選択し、スタジアムの売り子から商品を購入した場合を示す。ユーザが都度決済で商品を購入すると、この商品の電子決済は、即時に実行される。図５の決済完了画面Ｇ５の例では、ユーザが購入した３００円の商品のクレジットカード決済が即時に実行される。

【0037】

ユーザが、ホーム画面Ｇ４Ａの状態でボタンＢ４３を選択すると、決済方法が一括払いに変更される（ホーム画面Ｇ４Ｂの状態）。ユーザが、再びボタンＢ４３を選択すると、決済方法を都度決済に戻すことができる。ユーザが決済方法を変更すると、決済方法の変更が第１サーバ１０に通知され、第１サーバ１０は、選択中の決済方法を特定できる。なお、コードＣ４０には、ユーザが選択した決済方法を識別可能な情報が含まれてもよい。第１サーバ１０は、この情報により、ユーザが選択した決済方法を識別してもよい。

【0038】

ホーム画面Ｇ４Ｂの状態でコードＣ４０が決済端末５０によって読み取られると、一括決済の決済要求が受け付けられたことを示す受付完了画面Ｇ８が表示される。図５の受付完了画面Ｇ８では、ユーザが、一括決済を選択し、スタジアムの売り子から商品を購入した場合を示している。ユーザが一括決済で商品を購入すると、この商品の電子決済は、いったん保留されて即時には実行されない。図５の受付完了画面Ｇ８の例では、ユーザが購入した３００円の商品のクレジットカード決済は、即時には実行されない。このクレジットカード決済は、ユーザがスタジアムからチェックアウトする時に、他の商品とともに一括して実行される。

【0039】

例えば、図４に示すように、ユーザが、座席に来た売り子からのお茶の購入、売店におけるグッズの購入、レストランにおける弁当の購入、自動販売機におけるジュースの購入、及び売店におけるアイスの購入を、一括決済で実行したとする。一括決済なので、これら５回分の電子決済は、いったん保留にされて即時には実行されない。ユーザは、保留になっている一括決済の詳細を、第１アプリから確認できる。例えば、ユーザが図５のボタンＢ４４を選択すると、図６に移り、スタジアムにおける電子決済の利用履歴を確認するための履歴確認画面Ｇ９が表示される。

【0040】

履歴確認画面Ｇ９には、都度決済の利用履歴を示す情報Ｉ９０、一括決済の利用履歴を示す情報Ｉ９１、及び一括決済の合計額と全体の合計額を示す情報Ｉ９２が表示される。図６の例では、ユーザは、都度決済を実行しておらず、情報Ｉ９０には、「なし」と表示される。例えば、ユーザが、決済方法を都度決済に変更して商品を購入すると、この商品に対応する都度決済の利用日時、支払先、利用額、及び明細が、情報Ｉ９０として表示される。この商品の購入に応じて、情報Ｉ９２が示す全体の合計額も更新される。

【0041】

図６の例では、図４で説明した５つの商品が一括決済で購入されているので、これら５つの商品の各々に対応する一括決済の利用日時、支払先、利用額、及び明細が、情報Ｉ９１として表示される。履歴確認画面Ｇ９には、これら５つの利用額の合計額を示す情報Ｉ９２も表示される。情報Ｉ９２は、ユーザがスタジアムで一括決済を実行するたびに更新される。

【0042】

ユーザは、履歴確認画面Ｇ９を確認しつつ、スタジアムにおける一連のサービスを都度決済又は一括決済で利用する。スタジアムで提供されるサービスは、商品の販売サービスに限られず、任意のサービスであってよい。図４に示すように、試合が終了すると、ユーザは、チェックイン端末４０の読取部４６にコードＣ６０（図６の表示画面Ｇ６）をかざし、スタジアムからチェックアウトする。チェックアウト時の流れは、チェックイン時の流れと同様である。第２サーバ２０は、第１サーバ１０を介してチェックアウトしたユーザを特定すると、チェックアウトの処理を実行する。

【0043】

本実施形態では、ユーザがスタジアムからチェックアウトする場合に、一括決済が実行される。図６の例であれば、保留になっていた５つの商品の電子決済が一度に実行される。本実施形態では、５つの商品に対応する５回のクレジットカード決済が次々と実行される場合を説明するが、５つの商品の合計額を１回のクレジットカード決済で実行されてもよい。１回のクレジットカード決済とする場合、電子決済システムＳの内部で、５つの商品を販売した各会社に適切な利用額が送金されるものとする。

【0044】

なお、一括決済では、個々の電子決済ごとに決済手段が異なってもよい。例えば、図６のタオルだけ電子マネー決済を利用して、他の商品はクレジットカード決済を利用する、といったことが可能であってもよい。チェックアウトが完了すると、チェックアウト完了画面Ｇ１０が表示され、ユーザは、スタジアムのエントランスから退場する。チェックアウト完了画面Ｇ１０には、一括決済の実行結果の詳細を示す情報Ｉ１００と、一括決済の合計額を示すＩ１０１と、が表示される。

【0045】

以上のように、本実施形態の電子決済システムＳは、スタジアムにおける決済方法として、都度決済及び一括決済のうちの好きな方をユーザが選択できるようになっている。これにより、ユーザがスタジアムを訪れて一連のサービスを利用する場合の電子決済の利便性を高めることができる。以降、この技術の詳細を説明する。

【0046】

［３．電子決済システムで実現される機能］
図７は、電子決済システムＳで実現される機能の一例を示す機能ブロック図である。

【0047】

［３－１．第１サーバで実現される機能］
図７に示すように、第１サーバ１０では、データ記憶部１００、決定部１０１、決済要求受付部１０２、及び電子決済実行部１０３が実現される。データ記憶部１００は、記憶部１２を主として実現される。決定部１０１、決済要求受付部１０２、及び電子決済実行部１０３の各々は、制御部１１を主として実現される。

【0048】

［データ記憶部］
データ記憶部１００は、ユーザに第１サービスを提供するために必要なデータと、ユーザのチェックインに必要なデータと、を記憶する。例えば、データ記憶部１００は、第１データベースＤＢ１を記憶する。

【0049】

図８は、第１データベースＤＢ１のデータ格納例を示す図である。図８に示すように、第１データベースＤＢ１は、第１サービスの利用設定をしたユーザに関する情報が格納されたデータベースである。例えば、第１データベースＤＢ１には、ユーザＩＤ、パスワード、コードＩＤ、有効期限、氏名、決済情報、第１サービスの利用履歴、及びチェックイン情報が格納される。

【0050】

ユーザＩＤは、第２情報の一例である。このため、ユーザＩＤと記載した箇所は、第２情報と読み替えることができる。第２情報は、ユーザＩＤに限られず、少なくとも第２サービスでユーザを識別可能な情報であればよい。例えば、第２情報は、ＩＤと呼ばれる情報ではなく、ユーザアカウント等の他の名前で呼ばれる情報であってもよいし、メールアドレスが第２情報をとして利用されてもよい。他にも例えば、第２情報は、第１サービスと共通のユーザＩＤではなく、第２サービスで独自に発行されたユーザＩＤであってもよい。

【0051】

コードＩＤは、第１情報の一例である。このため、コードＩＤと記載した箇所は、第１情報と読み替えることができる。第１情報は、コードＩＤに限られず、少なくとも第１サービスでユーザを識別可能な情報であればよい。例えば、第１情報は、ＩＤと呼ばれる情報ではなく、ユーザアカウント等の他の名前で呼ばれる情報であってもよいし、メールアドレスが第１情報をとして利用されてもよい。

【0052】

例えば、ユーザＩＤが第１情報に相当してもよい。ユーザＩＤが第１情報に相当する場合には、後述の第２情報が存在せず、第２情報がチェックインで利用されなくてもよい。他にも例えば、第１情報は、第２サービスと共通のユーザＩＤではなく、第１サービスで独自に発行されたユーザＩＤであってもよい。この場合には、第２サービス側でユーザを特定する必要があるので、第２情報が存在し、第２情報がチェックインで利用されてもよい。第１情報と第２情報の関連付けは、第１データベースＤＢ１ではなく、第２データベースＤＢ２で管理されてもよい。

【0053】

本実施形態では、ユーザの会員登録の手続きは、第１サービス及び第２サービスで共通している。ユーザが会員登録をすると、第１サービス及び第２サービスの両方でユーザを識別可能な情報であるユーザＩＤが発行される。例えば、ユーザＩＤに関連付けられるユーザの登録情報は、第１データベースＤＢ１及び第２データベースＤＢ２とは異なる管理用のデータベースに格納される。登録情報は、パスワード、氏名、住所、及び電話番号等である。登録情報には、その他の個人情報が含まれてもよい。

【0054】

ユーザは、会員登録の手続きを完了した後に、第１サービスの利用設定の手続きをする。この利用設定の手続きが完了すると、ユーザに対応するレコードが第１データベースＤＢ１に作成される。このレコードには、管理用のデータベースに格納されたユーザＩＤ、パスワード、及び氏名が格納される。

【0055】

決済情報は、ユーザが登録した決済手段に関する情報である。例えば、決済情報は、複数の決済手段の中からユーザが支払い元に指定した決済手段である支払い元情報、ユーザが選択中の決済方法（都度決済が選択されているか、一括決済が選択されているか、を識別可能な情報）、ユーザが登録したクレジットカードの番号等を含むクレジットカード情報、ユーザの電子マネーのＩＤ等を含む電子マネー情報、及びユーザの電子キャッシュのＩＤ等を含む電子キャッシュ情報を含む。決済情報は、決済手段に応じた情報を含めばよい。あるユーザの電子決済は、このユーザの決済情報に基づいて実行される。

【0056】

利用履歴は、過去におけるユーザの電子決済の履歴である。この利用履歴は、スタジアム内の電子決済に限られず、スタジアム外の電子決済も含む。この利用履歴は、チェックインが発生しない場所における電子決済も含む。例えば、利用履歴には、一括決済フラグ、利用日時、支払先、利用額、及び明細を含む。利用履歴は、後述の電子決済実行部１０３により更新される。

【0057】

一括決済フラグは、一括決済の対象となる電子決済を識別可能な情報である。図８の例では、一括決済フラグが「１」の電子決済は、一括決済の対象である。一括決済フラグが「０」の電子決済は、一括決済の対象ではなく、都度決済の対象である。利用日時は、電子決済が利用された日時である。支払先は、電子決済の相手に関する情報である。本実施形態では、コードＣ４０を決済端末５０で読み取ることによって電子決済が実行されるので、コードＣ４０を読み取った決済端末５０を識別する端末ＩＤが支払先として格納される。

【0058】

利用額は、電子決済における決済額である。ユーザが複数の商品の合計額を１回の電子決済で支払った場合には、この合計額が利用額に相当する。明細は、電子決済で購入された商品を識別可能な情報である。ユーザが複数の商品を１回の電子決済で購入した場合には、明細には、全ての商品を識別可能な情報が示されてもよいし、一部の商品だけを識別可能な情報が示されてもよい。

【0059】

チェックイン情報は、チェックインの状況に関する情報である。例えば、チェックイン情報は、チェックインが実行されたスタジアム、チェックインが実行された日時、及びチェックアウトが実行された日時を含む。なお、第１データベースＤＢ１に格納される情報は、図８の例に限られず、任意の情報が格納されてよい。例えば、ユーザＩＤ及びパスワードの入力を省略して第１サービスにログインするための情報が格納されてもよい。

【0060】

［決定部］
決定部１０１は、決済要求のたびに実行される都度決済、又は、複数の決済要求が一括された一括決済の何れを実行するかを、ユーザに応じて決定する。本実施形態では、決定部１０１は、ユーザの選択に基づいて、都度決済又は一括決済の何れを実行するかを決定する。都度決済又は一括決済の決定方法は、ユーザによる選択に限られず、後述の変形例のように、電子決済システムＳにおいて自動的に選択されてもよい。

【0061】

ユーザに応じて決定するとは、ユーザごとに、都度決済又は一括決済の何れを実行するかを決定することである。決定部１０１は、ユーザの決済方法として、都度決済又は一括決済の何れかを決定する。本実施形態では、決定部１０１は、チェックインの後の決済方法として、都度決済又は一括決済の何れを実行するかを決定する。即ち、決定部１０１は、チェックインの後であり、かつ、チェックアウトの前の決済方法として、都度決済又は一括決済の何れを実行するかを決定する。決定部１０１は、ユーザがチェックインした場所（本実施形態では、スタジアム）における電子決済の決済方法として、都度決済又は一括決済の何れを実行するかを決定する。

【0062】

本実施形態では、決済要求は、ユーザのユーザ端末３０にインストールされた第１アプリを利用して行われるので、決定部１０１は、第１アプリを利用して受け付けられた決済要求の決済方法として、都度決済又は一括決済の何れを実行するかを決定する。第１アプリは、決済アプリの一例である。このため、第１アプリと記載した箇所は、決済アプリと読み替えることができる。

【0063】

本実施形態では、ユーザは、スタジアムを訪れて複数の位置で一連のサービスを利用可能であり、これら複数の位置には、決済要求を送信可能な決済端末５０が配置されている。このため、決定部１０１は、複数の位置に配置された決済端末５０からの決済要求に応じた決済方法として、都度決済又は一括決済を決定する。ユーザがスタジアムからチェックアウトして、スタジアム外の決済端末５０からの決済要求については、一括決済の対象とはならない。

【0064】

スタジアムは、所定の場所の一例である。このため、スタジアムと記載した箇所は、所定の場所と読み替えることができる。所定の場所は、その中の複数の位置で電子決済が可能な場所である。所定の場所は、ある程度の広さを有しており、ユーザはその中を移動可能である。所定の場所の中では、複数のサービスが提供されてよい。所定の場所の中で、個々のサービスが提供される位置が、上記説明した複数の位置になる。

【0065】

所定の場所は、チケット購入や予約等の申し込みが発生しない場所であってもよい。例えば、この場所は、ショッピングモール、日帰りの温泉施設、イベント会場、ゲームセンター、百貨店、空港、又は駅等の施設であってもよい。これらの施設では、敷地内の複数の位置で電子決済が可能である。ユーザは、特に予約をせずに、これらの施設を訪れる。これらの施設には、本実施形態と同様のチェックイン端末４０が配置されており、本実施形態と同様の手順によってチェックインが実行されてよい。

【0066】

［決済要求受付部］
決済要求受付部１０２は、ユーザがスタジアムを訪れて一連のサービスを利用する場合に、電子決済の決済要求を受け付ける。本実施形態では、決済端末５０は、第１アプリによって表示されたコードＣ４０を読み取り、コードＣ４０に含まれるコードＩＤを取得すると、第１サーバ１０にコードＩＤを含む決済要求を送信する。決済要求は、電子決済を実行するための要求であり、所定の形式のデータが送信されることによって行われる。決済要求は、コードＩＤ以外にも、電子決済に必要な情報を含む。例えば、決済要求は、決済端末５０を識別可能な端末ＩＤと、利用額と、を含む。決済要求は、明細を含んでもよい。

【0067】

本実施形態では、決済要求受付部１０２は、スタジアムにおける決済端末５０から、決済要求を受け付ける。この決済要求には、都度決済の決済要求と、一括決済の決済要求と、が含まれる。都度決済の決済要求が受け付けられた場合には、電子決済が即時に実行される。一括決済の決済要求が受け付けられた場合には、電子決済の実行がいったん保留される。保留された電子決済は、第１データベースＤＢ１の利用履歴に格納される。図８の例であれば、利用履歴において、一括決済フラグが「１」の電子決済は、保留された電子決済に相当する。

【0068】

なお、一括決済の最終的な実行は、一括決済の決済要求とは別に指示される。本実施形態では、チェックイン端末４０から受信するチェックアウトの実行要求が、一括決済の最終的な実行の指示に相当する。この指示は、チェックアウトの実行要求に限られず、任意の指示であってよい。例えば、後述の変形例のように、ユーザによる指示であってもよい。他にも例えば、何らかの指示が受け付けられるのではなく、所定の日時が訪れること、チェックインからの経過時間が所定の時間になること、又は試合が終了することといったような条件が満たされた場合に、一括決済の最終的な実行が行われてもよい。

【0069】

［電子決済実行部］
電子決済実行部１０３は、ユーザが利用可能な決済手段に基づいて、電子決済を実行する。本実施形態では、ユーザがスタジアムにチェックインすると、決定部１０１により都度決済又は一括決済の何れかが、このユーザの決済方法として決定されるので、電子決済実行部１０３は、決定部１０１の決定結果に基づいて、都度決済又は一括決済を実行する。例えば、電子決済実行部１０３は、ユーザのユーザ端末３０にインストールされた第１アプリを利用して、都度決済又は一括決済を実行する。

【0070】

電子決済実行部１０３は、決済要求受付部１０２が受け付けた決済要求に基づいて、電子決済を実行する。例えば、電子決済実行部１０３は、第１データベースＤＢ１を参照し、決済要求に含まれるコードＩＤに関連付けられた決済情報を取得する。電子決済実行部１０３は、当該取得された決済情報に基づいて、決定部１０１により決定されたユーザの決済方法（本実施形態では、ユーザが自分で選択した決済方法）を特定する。

【0071】

ユーザの決済方法が都度決済である場合、電子決済実行部１０３は、チェックインの後に、決済要求を受け付けるたびに、都度決済を実行する。本実施形態では、電子決済実行部１０３は、チェックインの後であり、かつ、チェックアウトの前に、決済要求を受け付けるたびに、都度決済を実行する。電子決済実行部１０３は、スタジアムにおける複数の位置に配置された決済端末５０から決済要求を受け付けるたびに、都度決済を実行する。

【0072】

例えば、電子決済実行部１０３は、決済要求受付部１０２が受け付けた決済要求の電子決済を、保留せずに即時に実行する。電子決済の実行方法自体は、公知の方法を利用可能である。例えば、クレジットカード決済であれば、決済要求に含まれる利用額に応じた与信が行われ、電子マネー決済であれば、決済要求に含まれる利用額に応じて残高を差し引く処理が実行される。

【0073】

電子決済実行部１０３は、都度決済の実行結果を、ユーザ端末３０及び決済端末５０に送信する。電子決済実行部１０３は、都度決済の実行結果に基づいて、第１データベースＤＢ１の利用履歴を更新する。この利用履歴の一括決済フラグは「０」になる。この利用履歴に含まれる利用日時、支払先、利用額、及び明細は、それぞれ現在日時、決済要求を送信した決済端末５０の端末ＩＤ、及び決済要求に含まれる利用額と明細になる。

【0074】

ユーザの決済方法が一括決済である場合、電子決済実行部１０３は、チェックインの後に受け付けられた複数の決済要求に基づいて、一括決済を実行する。本実施形態では、電子決済実行部１０３は、チェックインの後であり、かつ、チェックアウトの前に受け付けられた複数の決済要求に基づいて、一括決済を実行する。電子決済実行部１０３は、スタジアムにおける複数の位置に配置された決済端末５０からの複数の決済要求に基づいて、一括決済を実行する。

【0075】

例えば、電子決済実行部１０３は、決済要求受付部１０２が受け付けた決済要求の電子決済を、即時には実行せずに保留し、第１データベースＤＢ１の利用履歴を更新する。この利用履歴の一括決済フラグは「１」になる。この利用履歴に含まれる利用日時、支払先、利用額、及び明細は、それぞれ現在日時、決済要求を送信した決済端末５０の端末ＩＤ、及び決済要求に含まれる利用額と明細になる。利用履歴には、一括決済が完了したか否かを識別可能な情報が含まれてもよい。

【0076】

本実施形態では、ユーザがチェックアウトをする場合に、電子決済実行部１０３は、これら複数の決済要求の電子決済を、一度にまとめて実行する。電子決済実行部１０３は、チェックアウトの対象となるユーザのユーザＩＤに関連付けられた利用履歴のうち、一括決済フラグが「１」の利用履歴に基づいて、一括決済を実行する。この利用履歴がｎ個（ｎは自然数）存在したとすると、電子決済実行部１０３は、支払い元として選択された決済手段に基づいて、これらｎ個の利用履歴に対応するｎ回の電子決済を、一括決済として次々と実行する。ｎの数値が１のこともあるので、この場合には、１回の電子決済が一括決済として実行される。先述したように、電子決済実行部１０３は、ｎ個の利用履歴の利用額を合計した合計額に基づいて、１回の電子決済を一括決済として実行してもよい。

【0077】

ユーザの支払い元が電子マネー、電子キャッシュ、又は銀行口座の場合には、残高の確認が行われる。電子決済実行部１０３は、一括決済を実行する場合に、ユーザが利用可能な決済手段の残高が、複数の決済要求の利用額を合計した合計値以上であるか否かを判定する。電子決済実行部１０３は、残高が合計額以上であると判定された場合に、一括決済を実行する。残高が合計額未満であれば、一括決済が実行されない。この場合、ユーザは、支払い元を変更するか、残高をチャージしたうえで、一括決済を実行しなおす。

【0078】

なお、電子決済実行部１０３は、決済端末５０以外の他の端末から決済要求を受信した場合も同様にして電子決済を実行すればよい。ただし、本実施形態では、スタジアム外における電子決済は、原則として都度決済が実行されるものとする。ユーザがスタジアム以外の他の場所を訪れて、当該他の場所が本実施形態の電子決済システムＳに対応している場合には、この場所における電子決済として、一括決済が実行されてもよい。

【0079】

［３－２．第２サーバで実現される機能］
図７に示すように、第２サーバ２０では、データ記憶部２００、第２サービス提供部２０１、チェックイン実行部２０２、及びチェックアウト実行部２０３が実現される。データ記憶部２００は、記憶部２２を主として実現される。第２サービス提供部２０１、チェックイン実行部２０２、及びチェックアウト実行部２０３の各々は、制御部２１を主として実現される。

【0080】

［データ記憶部］
データ記憶部２００は、ユーザに第２サービスを提供するために必要なデータと、ユーザのチェックインに必要なデータと、を記憶する。例えば、データ記憶部２００は、第２データベースＤＢ２を記憶する。

【0081】

図９は、第２データベースＤＢ２のデータ格納例を示す図である。図９に示すように、第２データベースＤＢ２は、第２サービスの利用設定をしたユーザに関する情報が格納されたデータベースである。例えば、第２データベースＤＢ２には、ユーザＩＤ、パスワード、氏名、申込情報、及びチェックイン情報が格納される。

【0082】

ユーザは、会員登録の手続きを完了した後に、第２サービスの利用設定の手続きをする。この利用設定の手続きが完了すると、ユーザに対応するレコードが第２データベースＤＢ２に作成される。このレコードには、管理用のデータベースに格納されたユーザＩＤ、パスワード、及び氏名が格納される。

【0083】

申込情報は、第２サービスに関する申し込みの内容に関する情報である。本実施形態では、チケットの購入申し込みが第２サービスに関する申し込みに相当する。このため、チケットの購入申し込みについて説明している箇所は、第２サービスに関する申し込みと読み替えることができる。第２サービスに関する申し込みは、第２サービスから行われる申し込み、又は、第２サービスを利用するための申し込みである。申し込みは、チケットの購入申し込みに限られず、例えば、宿泊施設やレストラン等の施設の予約、又は、飛行機や列車等の予約が申し込みに相当してもよい。

【0084】

申込情報は、第２サービスに応じた内容を含めばよい。本実施形態では、チケットの購入申し込みが申し込みに相当するので、申込情報は、購入されたチケットの内容を示す。例えば、申込情報は、試合が開催される日時、スタジアム内の座席、及びチケットの価格を含む。チェックイン情報は、第１データベースＤＢ１と同様である。第２サーバ２０によってチェックイン情報が更新され、第１サーバ１０に共有される。なお、第２データベースＤＢ２に格納される情報は、図９の例に限られず、任意の情報が格納されてよい。例えば、コードＩＤが格納されてもよい。また、データ記憶部２００は、トップページＰ１等のデータやチケットの残席情報を記憶してもよい。

【0085】

［第２サービス提供部］
第２サービス提供部２０１は、ユーザに第２サービスを提供する。第２サービス提供部２０１は、第２サービスの内容に応じた処理を実行すればよい。本実施形態では、チケット購入サービスが第２サービスに相当するので、例えば、第２サービス提供部２０１は、チケットの購入申し込みを受け付けるためのページ（トップページＰ１等）を、ユーザに提供する。また例えば、第２サービス提供部２０１は、ユーザが入力した検索条件に基づいて、チケットを検索する。また例えば、第２サービス提供部２０１は、あるユーザがチケットを購入した場合に、申込情報を生成し、このユーザのユーザＩＤに関連付けて第２データベースＤＢ２に格納する。

【0086】

［チェックイン実行部］
チェックイン実行部２０２は、ユーザがスタジアムを訪れた場合に、ユーザのユーザ端末３０と、スタジアムのチェックイン端末４０と、の少なくとも一方を利用して、スタジアムへのチェックインを実行する。本実施形態では、チェックイン実行部２０２は、コードＩＤ又はコードＩＤに関連付けられたユーザＩＤに基づいて、スタジアムへのチェックインを実行する。

【0087】

本実施形態の第２サーバ２０は、自身でコードＩＤを管理しないので、チェックイン実行部２０２は、コードＩＤに関連付けられたユーザＩＤに基づいて、スタジアムへのチェックインを実行する。第２サーバ２０が自身でコードＩＤを管理する場合には、チェックイン実行部２０２は、コードＩＤに基づいて、スタジアムへのチェックインを実行する。この場合、ユーザＩＤはチェックインで利用されない。

【0088】

チェックインを実行するとは、ユーザがスタジアムを訪れたことを検知することである。スタジアムを訪れたユーザを特定すること、又は、ユーザが訪れたスタジアムを特定することは、チェックインを実行することに相当する。チェックインは、ユーザがスタジアムに入場する権利を有するか否かの確認ということもできる。例えば、第２データベースＤＢ２のチェックイン情報を更新することは、チェックインを実行することに相当する。また例えば、ユーザが訪れたスタジアムのチェックイン端末４０又はこのスタジアムの他の端末に、ユーザの申込情報の全部又は一部を送信することは、チェックインを実行することに相当する。

【0089】

本実施形態では、チェックイン実行部２０２は、あるユーザのユーザＩＤに関連付けられた申込情報に基づいて、このユーザのチェックインを実行する。チェックインの対象となるユーザのユーザＩＤは、第２サーバ２０自身で特定してもよいが、本実施形態では、チェックイン実行部２０２は、第１サーバ１０から受信したユーザＩＤに関連付けられた申込情報に基づいて、チェックインを実行する。

【0090】

例えば、チェックイン実行部２０２は、第１サーバ１０から受信したユーザＩＤに関連付けられた申込情報が第２データベースＤＢ２に存在する場合には、このユーザＩＤに関連付けられたチェックイン情報を更新する。チェックイン実行部２０２は、申込情報に対応するスタジアムにユーザがチェックイン済みであることを示し、かつ、チェックイン日時として現在日時を含むように、このチェックイン情報を更新する。また例えば、チェックイン実行部２０２は、このユーザＩＤに関連付けられた申込情報の全部又は一部を、ユーザが訪れたスタジアムのチェックイン端末４０又はこのスタジアムの他の端末に送信する。

【0091】

［チェックアウト実行部］
チェックアウト実行部２０３は、ユーザがスタジアムから離れる場合に、ユーザ端末３０、チェックイン端末４０、及びスタジアムの他の端末の少なくとも１つを利用して、スタジアムからのチェックアウトを実行する。他の端末は、チェックアウトのために用意されたチェックアウト用の端末であってもよいし、決済端末５０等の端末であってもよい。これらの端末は、チェックイン端末４０と同様の物理的構成及び機能を有する。

【0092】

チェックアウト実行部２０３は、チェックイン時の流れと同様にして、チェックアウトを実行する。例えば、チェックイン端末４０は、ユーザ端末３０のコードＣ６０に含まれるコードＩＤを第１サーバ１０に送信する。その後は、第１サーバ１０から第２サーバ２０に、このコードＩＤに関連付けられたユーザＩＤが送信され、このユーザＩＤのチェックイン情報が更新されることによって、チェックアウトが実行される。先述したように、この一連の流れの中で、第１サーバ１０の電子決済実行部１０３による一括決済が実行される。

【0093】

［３－３．ユーザ端末で実現される機能］
図７に示すように、ユーザ端末３０では、データ記憶部３００、表示制御部３０１、及び選択受付部３０２が実現される。データ記憶部３００は、記憶部３２を主として実現される。表示制御部３０１及び選択受付部３０２の各々は、制御部３１を主として実現される。

【0094】

[データ記憶部]
データ記憶部３００は、ユーザが第１サービス及び第２サービスを利用するために必要なデータと、チェックインに必要なデータと、を記憶する。例えば、データ記憶部３００は、第１アプリ及びコードＩＤを記憶する。ユーザ端末３０は、第１サーバ１０により発行されたコードＩＤを受信して自身のデータ記憶部３００に記録する。ユーザ端末３０は、コードＩＤの有効期限も受信した場合には、有効期限も自身のデータ記憶部３００に記録する。

【0095】

［表示制御部］
表示制御部３０１は、第１サーバ１０から受信したデータに基づいて、図２、図３、及び図５の各々に示す画面を表示部３５に表示させる。例えば、表示制御部３０１は、第１サービスを利用するための第１アプリに基づいて、コードＩＤを含むコードを表示可能である。本実施形態では、表示制御部３０１は、第１サービス用のコードＣ４０と、第２サービス用のコードＣ６０と、を表示可能である。

【0096】

本実施形態では、コードＣ４０もコードＩＤを含む場合を説明するが、コードＣ４０は、コードＩＤを含まずに、ユーザを識別可能な他の情報を含んでもよい。コードＣ４０，Ｃ６０は、任意のコードであってよく、時間経過に応じて見た目が変わるコードであってもよい。表示制御部３０１は、データ記憶部３００に記憶されたコードＩＤをコード化し、コードＣ４０，Ｃ６０を表示させる。

【0097】

［選択受付部］
選択受付部３０２は、ユーザによる、都度決済又は一括決済の何れかの選択を受け付ける。本実施形態では、選択受付部３０２は、ボタンＢ４４（図５）又はボタンＢ７０，Ｂ７１（図３）を利用して選択を受け付ける。都度決済又は一括決済の選択は、任意のユーザインタフェースを利用すればよく、本実施形態の例に限られない。例えば、チェックボックスやドラムロール型の他の入力フォームを利用して選択が受け付けられてもよい。選択受付部３０２は、音声入力を利用して選択を受け付けてもよい。

【0098】

［３－４．チェックイン端末で実現される機能］
図７に示すように、チェックイン端末４０では、データ記憶部４００と、コードＩＤ取得部４０１と、が実現される。データ記憶部４００は、記憶部４２を主として実現される。コードＩＤ取得部４０１は、制御部４１を主として実現される。

【0099】

[データ記憶部]
データ記憶部４００は、チェックインに必要なデータを記憶する。例えば、データ記憶部４００は、チェックイン端末４０を識別可能な端末ＩＤと、第１サーバ１０を識別可能な情報と、を記憶する。他にも例えば、データ記憶部４００は、チェックイン端末４０が配置されたスタジアムを識別可能な情報を記憶してもよい。

【0100】

［コードＩＤ取得部］
コードＩＤ取得部４０１は、第１サービスのユーザがスタジアムを訪れた場合に、ユーザのユーザ端末３０と、スタジアムのチェックイン端末４０と、の少なくとも一方を利用して、第１サービスでユーザを識別可能なユーザのコードＩＤを取得する。本実施形態では、ユーザ端末３０及びチェックイン端末４０の両方が利用される場合を説明するが、後述の変形例のように、ユーザ端末３０又はチェックイン端末４０の何れか一方だけが利用されてもよい。

【0101】

本実施形態では、ユーザ端末３０のデータ記憶部３００にコードＩＤが記録されているので、コードＩＤ取得部４０１は、ユーザ端末３０に記録されたコードＩＤを取得する。例えば、コードＩＤ取得部４０１は、コードＣ６０がチェックイン端末４０で読み取られた場合に、コードＩＤを取得する。コードＩＤ取得部４０１は、このコードＩＤを第１サーバ１０に送信する。このコードＩＤとともに、端末ＩＤと、チェックイン端末４０が配置されたスタジアムを識別可能な情報と、の少なくとも一方が送信されてもよい。

【0102】

なお、コードＩＤは、光学的に取得されなくてもよく、通信によって取得されてもよい。チェックイン端末４０は、コードＩＤを取得するための端末であればよく、コードＩＤの取得方法に応じた端末であればよい。例えば、ユーザ端末３０と通信可能な通信機器がチェックイン端末４０に相当してもよい。通信自体は、任意のプロトコルを利用可能であり、例えば、Ｗｉ－Ｆｉ（登録商標）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、又は赤外線通信であってもよいし、公知のＩＣカードで採用されている近距離無線通信であってもよい。

【0103】

スタジアムは、第２サービスに関する場所の一例である。このため、スタジアムと記載した箇所は、第２サービスに関する場所と読み替えることができる。第２サービスに関する場所は、第２サービスを利用して申し込まれる場所、又は、第２サービスが提供される場所である。例えば、第２サービスに関する場所は、宿泊施設、観光施設、公共施設、空港、駅、店舗、レストラン、又は美容院といった他の施設であってもよいし、屋外のスペースやバス停のように、特段の施設が存在しない場所が、第２サービスに関する場所であってもよい。

【0104】

［３－５．決済端末で実現される機能］
図７に示すように、決済端末５０では、データ記憶部５００と、コードＩＤ取得部５０１と、が実現される。データ記憶部５００は、記憶部５２を主として実現される。コードＩＤ取得部５０１は、制御部５１を主として実現される。

【0105】

[データ記憶部]
データ記憶部５００は、電子決済に必要なデータを記憶する。例えば、データ記憶部５００は、決済端末５０を識別可能な端末ＩＤと、第１サーバ１０を識別可能な情報と、を記憶する。他にも例えば、データ記憶部５００は、決済端末５０が配置されたスタジアムを識別可能な情報を記憶してもよい。

【0106】

［コードＩＤ取得部］
コードＩＤ取得部５０１は、ユーザ端末３０に記憶されたコードＩＤを取得する。コードＩＤの取得方法は、コードＩＤ取得部４０１と同様である。例えば、コードＩＤ取得部５０１は、コードＣ４０が決済端末５０で読み取られた場合に、コードＩＤを取得する。コードＩＤ取得部５０１は、このコードＩＤを含む決済要求を第１サーバ１０に送信する。このコードＩＤとともに、端末ＩＤと、決済端末５０が配置されたスタジアムを識別可能な情報と、の少なくとも一方を含む決済要求が送信されてもよい。

【0107】

［４．電子決済システムで実行される処理］
図１０～図１２は、電子決済システムＳで実行される処理の一例を示すフロー図である。図１０～図１２に示す処理は、制御部１１，２１，３１，４１，５１の各々が記憶部１２，２２，３２，４２，５２の各々に記憶されたプログラムに従って動作することによって実行される。図１０～図１２の処理は、図７の機能ブロックにより実行される処理の一例である。

【0108】

図１０に示すように、第２サーバ２０及びユーザ端末３０の間で、チケットの購入申し込み処理が実行される（Ｓ１）。Ｓ１では、図２を参照して説明した流れによって、チケットが購入される。第２サーバ２０は、ユーザ端末３０から受信した情報に基づいて申込情報を生成し、チケットを購入したユーザのユーザＩＤに関連付けて第２データベースＤＢ２に格納する。

【0109】

ユーザ端末３０は、ユーザが操作部３４から第１アプリを選択すると、記憶部３２に記憶された第１アプリを起動させ（Ｓ２）、第１サーバ１０との間で、ログイン処理を実行する（Ｓ３）。Ｓ３では、ユーザ端末３０は、第１サーバ１０に、ログイン処理の実行要求を送信する。この実行要求は、ログインに必要な情報を含み、本実施形態ではコードＩＤの発行要求に相当する。第１サーバ１０は、ユーザ端末３０から受信した情報と、第１データベースＤＢ１と、に基づいて、ログイン処理を実行する。第１サーバ１０は、ログインが成功した場合、有効期限内の他のコードＩＤと重複しないようにコードＩＤを発行して有効期限を設定し、ユーザ端末３０に送信する。ユーザ端末３０は、コードＩＤを受信すると、記憶部３２のうちの第１アプリの記憶領域にコードＩＤ及び有効期限を記録する。

【0110】

ユーザ端末３０は、第１アプリのホーム画面Ｇ４を表示部３５に表示させ（Ｓ４）、ユーザがボタンＢ４１を選択すると、第１アプリの記憶領域に記録されたコードＩＤに基づいて、チェックイン用のコードＣ６０を表示画面Ｇ６に表示させる（Ｓ５）。ユーザ端末３０は、ユーザは、チケットを購入したスタジアムを訪れた場合に、Ｓ５で表示させたコードＣ６０をチェックイン端末４０にかざす。チェックイン端末４０は、読取部４６によるコードＣ６０の読取結果に基づいて、コードＣ６０に含まれるコードＩＤを取得し、自身の端末ＩＤ及びコードＩＤを第１サーバ１０に送信する（Ｓ６）。

【0111】

第１サーバ１０は、端末ＩＤ及びコードＩＤを受信すると、第２サーバ２０との間でチェックインが実行される（Ｓ７）。Ｓ７では、第１サーバ１０は、第１データベースＤＢ１に基づいて、チェックイン端末４０から受信したコードＩＤに関連付けられたユーザＩＤを取得する。第１サーバ１０は、第２サーバ２０に、チェックイン端末４０から受信した端末ＩＤと、当該取得されたユーザＩＤと、を送信する。第２サーバ２０は、端末ＩＤ及びユーザＩＤを受信すると、第２データベースＤＢ２に基づいて、このユーザＩＤに関連付けられたチケットの申込情報に基づいて、スタジアムへのチェックインを実行する。第２サーバ２０は、第１サーバ１０から受信したユーザＩＤに関連付けられたチェックイン情報を更新する。また、第２サーバ２０は、ユーザ端末３０に、申込情報の全部又は一部を送信する。

【0112】

ユーザ端末３０は、申込情報の全部又は一部を受信すると、チェックイン完了画面Ｇ７を表示部３５に表示させて、ユーザによる決済方法の選択を受け付ける（Ｓ８）。Ｓ８では、ユーザ端末３０は、ユーザが選択した決済方法を識別可能な情報を、第１サーバ１０に送信する。第１サーバ１０は、この情報を受信し、ユーザの決済方法として、都度決済又は一括決済の何れを実行するかを決定する（Ｓ９）。Ｓ９では、第１サーバ１０は、ユーザが選択した決済方法を識別可能な情報がユーザの決済情報に格納されるように、第１データベースＤＢ１を更新する。

【0113】

以降、ユーザは、スタジアムに入場し、任意の場所で電子決済を利用できる。図１１に移り、ユーザ端末３０は、電子決済用のコードＣ４０をホーム画面Ｇ４に表示させる（Ｓ１０）。ユーザは、スタジアムの任意の位置におけるサービスの支払いをする場合に、Ｓ１０で表示させたコードＣ４０を決済端末５０にかざす。決済端末５０は、読取部５６によるコードＣ４０の読取結果に基づいて、コードＣ４０に含まれるコードＩＤを取得し、第１サーバ１０に端末ＩＤ及びコードＩＤを含む決済要求を送信する（Ｓ１１）。

【0114】

第１サーバ１０は、決済要求を受信すると（Ｓ１２）、第１データベースＤＢ１に格納されたユーザの決済方法を参照する（Ｓ１３）。Ｓ１３では、決済要求に含まれるコードＩＤに関連付けられた決済情報が参照される。都度決済が選択されている場合（Ｓ１３；都度決済）、第１サーバ１０は、Ｓ１２で受信した決済要求に基づいて、都度決済を実行する（Ｓ１４）。Ｓ１４では、第１サーバ１０は、決済端末５０から受信したコードＩＤに関連付けられた決済情報に基づいて、都度決済を実行する。第１サーバ１０は、都度決済の実行結果に基づいて、ユーザの利用履歴を更新し、都度決済の実行結果をユーザ端末３０に送信する。ユーザ端末３０は、第１サーバ１０から都度決済の実行結果を受信すると、決済完了画面Ｇ５を表示部３５に表示させる（Ｓ１５）。

【0115】

Ｓ１３において、一括決済が選択されている場合（Ｓ１３；一括決済）、第１サーバ１０は、Ｓ１２で受信した決済要求の電子決済を保留にする（Ｓ１６）。Ｓ１６では、第１サーバ１０は、一括決済フラグが「１」の利用履歴が追加されるように、第１データベースＤＢ１に格納する。第１サーバ１０は、一括決済の処理結果を示す情報を、ユーザ端末３０に送信する。ユーザ端末３０は、第１サーバ１０から一括決済の処理結果を受信すると、受付完了画面Ｇ８を表示部３５に表示させる（Ｓ１７）。

【0116】

ユーザ端末３０は、ユーザの操作を特定する（Ｓ１８）。Ｓ１８では、ホーム画面Ｇ４に戻り電子決済用のコードＣ４０を表示させて決済端末５０にかざす操作、ボタンＢ４１を選択する操作、ボタンＢ４３を選択する操作、又はボタンＢ４４を選択する操作の何れかが行われる場合を説明する。

【0117】

電子決済用のコードＣ４０を表示させて決済端末５０にかざす操作が行われた場合（Ｓ１８；電子決済）、Ｓ１０～Ｓ１７の流れと同様の処理が実行される。なお、コードＩＤは、電子決済が実行されるたびに更新されてもよい。コードＩＤの有効期限が経過したり、ユーザが更新の操作をしたりした場合にも、コードＩＤが更新されてもよい。第１アプリが終了して再び起動した場合にも、コードＩＤが更新されてもよい。

【0118】

ユーザがホーム画面Ｇ４のボタンＢ４３を選択した場合（Ｓ１８；Ｂ４３）、ユーザ端末３０は、第１サーバ１０との間で、ユーザの決済方法を変更する処理を実行する（Ｓ１９）。Ｓ１９では、ユーザ端末３０は、ユーザが選択した決済方法を識別可能な情報を、第１サーバ１０に送信する。第１サーバ１０は、この情報を受信し、ユーザが選択した決済方法を識別可能な情報がユーザの決済情報に格納されるように、第１データベースＤＢ１を更新する。

【0119】

ユーザがホーム画面Ｇ４のボタンＢ４４を選択した場合（Ｓ１８；Ｂ４４）、ユーザ端末３０は、第１サーバ１０に履歴確認画面Ｇ９の表示要求を送信し、第１サーバ１０から受信したデータに基づいて、履歴確認画面Ｇ９を表示させる（Ｓ２０）。第１サーバ１０は、表示要求を受信すると、第１データベースＤＢ１に基づいて、表示要求をしたユーザのユーザＩＤに関連付けられた利用履歴を取得し、履歴確認画面Ｇ９の表示データをユーザ端末３０に送信する。この表示データは、任意のデータ形式であればよく、第１アプリで何らかの画面を表示させるためのデータであればよい。例えば、表示データは、ＨＴＭＬデータであってもよい。

【0120】

Ｓ２０では、第１サーバ１０は、このユーザＩＤに関連付けられた利用履歴のうち、利用日時がチェックイン日時よりも後の利用履歴を取得し、履歴確認画面Ｇ９の表示データを生成する。第１サーバ１０は、当該取得された利用履歴の一括決済フラグが「０」の利用履歴に含まれる利用日時、支払先、利用額、及び明細を、情報Ｉ９０として取得する。第１サーバ１０は、当該取得された利用履歴の一括決済フラグが「１」の利用履歴に含まれる利用日時、支払先、利用額、及び明細を、情報Ｉ９１として取得する。第１サーバ１０は、一括決済の合計額及び全体の合計額を計算し、情報Ｉ９２として取得する。ユーザ端末３０は、表示データを受信すると、履歴確認画面Ｇ９を表示部３５に表示させ、その後、ホーム画面Ｇ４に戻る操作が行われた場合にホーム画面Ｇ４が表示されてＳ１８の処理に戻る。

【0121】

Ｓ１８において、ユーザがホーム画面Ｇ４のボタンＢ４１を選択した場合（Ｓ１８；Ｂ４１）、図１２に移り、ユーザ端末３０は、Ｓ５～Ｓ７の処理と同様の流れのＳ２１，Ｓ２２，Ｓ２４の処理により、スタジアムからのチェックアウトが実行される。ただし、第１サーバ１０は、Ｓ２３において、第１データベースＤＢ１に基づいて、チェックアウトしようとしているユーザの一括決済を実行する（Ｓ２３）。Ｓ２３では、第１サーバ１０は、第１データベースＤＢ１を参照し、このユーザの利用履歴のうち、一括決済フラグが「１」の利用履歴に基づいて、一括決済を実行する。一括決済及びチェックアウトが完了すると、Ｓ２５において、チェックアウト完了画面Ｇ１０の表示に必要なデータがユーザ端末３０に送信されてチェックアウト完了画面Ｇ１０が表示され、本処理は終了する。チェックアウトが実行されるまで、Ｓ１０～Ｓ２０の処理が繰り返されて、ユーザは、スタジアムにおける複数の位置で利用した一連のサービスの電子決済を実行し、その利用履歴を履歴確認画面Ｇ９から随時確認できる。

【0122】

本実施形態の電子決済システムＳによれば、ユーザがスタジアムを訪れて一連のサービスを利用する場合に、ユーザに応じて決定された都度決済又は一括決済を実行することによって、ユーザに応じた決済方法でスタジアムの電子決済を実行できるので、ユーザが訪れたスタジアムにおける電子決済の利便性が高まる。例えば、スタジアムで利用した合計額を把握したユーザは一括決済を選択し、特に気にならないユーザは都度決済を選択するといったことができるので、ユーザにとって使い勝手の良い電子決済サービスを提供できる。また、一括決済の対象を無制限とするのではなく、スタジアム内に限定することで、ある特定の場所で利用した合計額を把握しやすくなる。

【0123】

また、電子決済システムＳは、ユーザの決済方法として都度決済が決定された場合には、チェックインの後に、決済要求を受け付けるたびに、都度決済を実行する。電子決済システムＳは、ユーザの決済方法として一括決済が決定された場合には、チェックインの後に受け付けられた複数の決済要求に基づいて、一括決済を実行する。これにより、ユーザがスタジアムにチェックインした後における電子決済の利便性が高まる。

【0124】

また、電子決済システムＳは、ユーザの決済方法として都度決済が決定された場合には、チェックインの後であり、かつ、チェックアウトの前に、決済要求を受け付けるたびに、都度決済を実行する。電子決済システムＳは、ユーザの決済方法として一括決済が決定された場合には、チェックインの後であり、かつ、チェックアウトの前に受け付けられた複数の決済要求に基づいて、一括決済を実行する。これにより、ユーザがスタジアムにチェックインしてからチェックアウトするまでの間における電子決済の利便性が高まる。

【0125】

また、電子決済システムＳは、ユーザによる、都度決済又は一括決済の何れかの選択を受け付けることによって、ユーザが所望する決済方法で電子決済を実行し、電子決済の利便性が高まる。

【0126】

また、電子決済システムＳは、第１アプリを利用して受け付けられた決済要求に基づいて、都度決済又は一括決済を実行することによって、ユーザ端末３０にインストールされたアプリケーションという手軽な手段を利用して都度決済又は一括決済を実行できる。

【0127】

また、電子決済システムＳは、ユーザが訪れたスタジアムにおける複数の位置に配置された決済端末５０からの複数の決済要求に基づいて、一括決済を実行することによって、スタジアムの種々の場所における電子決済をまとめた一括決済を実行し、電子決済の利便性が高まる。

【0128】

また、電子決済システムＳは、ユーザが利用可能な決済手段の残高が、複数の決済要求の利用額を合計した合計値以上であると判定された場合に、一括決済を実行することによって、一括決済の対象となる複数の決済要求の電子決済を確実に実行できる。

【0129】

また、電子決済システムＳは、ユーザがスタジアムを訪れた場合に、ユーザのユーザ端末３０と、スタジアムのチェックイン端末４０と、の少なくとも一方を利用してスタジアムへのチェックインを実行することによって、チェックインに必要な情報の管理を簡易化できる。例えば、ユーザが購入したチケットのチェックイン用のコードを電子メールで送信し、ユーザが試合当日にこのコードをユーザ端末３０に表示させてチェックインすることも考えられるが、ユーザは、多数の電子メールからコードを探し出す必要があり、情報の管理が煩雑になる。この点、ユーザが普段使用する第１アプリからチェックインできるようにすることで、管理すべき情報の数を減らせる。

【0130】

［５．変形例］
なお、本開示は、以上に説明した実施の形態に限定されるものではない。本開示の趣旨を逸脱しない範囲で、適宜変更可能である。

【0131】

図１３は、変形例における機能ブロック図の一例である。以降説明する変形例では、図１３に示す各機能が実現される。信頼度取得部１０４、通知部１０５、領収書出力部１０６、利用額取得部１０７、情報提供部１０８、及び許可部１０９の各々は、制御部１１を主として実現される。実行指示受付部４０２は、制御部４１を主として実現される。

【0132】

［５－１．変形例１］
例えば、電子決済システムＳは、電子決済におけるユーザの信頼度を取得する信頼度取得部１０４を更に含んでもよい。信頼度は、電子決済におけるユーザの信頼性を示す指標である。電子決済が正常に完了する確率が高いほど、信頼度が高くなる。例えば、クレジットカード決済であれば、信頼度取得部１０４は、クレジットカード会社で保有するユーザの信頼度を取得する。この信頼度は、いわゆる信用情報と呼ばれる情報である。電子マネー等の他の決済事業者が保有する信用情報が信頼度として取得されてもよい。悪意のあるユーザが不正をすることもあるので、信頼度が低いほど不正を働きやすいユーザのこともある。信頼度は、不正をしない度合いということもできる。

【0133】

また例えば、信頼度取得部１０４は、第１データベースＤＢ１に格納されたユーザの利用履歴に基づいて、ユーザの信頼度を計算してもよい。変形例１では、利用履歴には、未完了の決済要求（エラーになった決済要求）も含まれるものとする。未完了の決済要求は、電子決済を完了できなかった決済要求である。例えば、クレジットカード決済であれば、与信エラーになった場合に未完了になる。また例えば、電子マネー決済、電子キャッシュ決済、又は銀行口座を利用した決済であれば、残高不足の場合に未完了になる。他にも例えば、ブラックリストが存在する決済手段であれば、何らかの理由でブラックリストに載った場合に未完了になる。

【0134】

例えば、信頼度取得部１０４は、過去に未完了になった数が少ないほど信頼度が高くなるように、ユーザの信頼度を計算する。信頼度の計算方法自体は、公知の種々の方法を利用可能であり、例えば、機械学習の学習モデルを利用した方法であってもよい。この学習モデルには、種々のユーザの特徴量（例えば、ユーザの利用額、利用場所、及び利用時間等）と、このユーザが信頼できるか否かを示す情報と、の関係を示す訓練データが学習されている。信頼度取得部１０４は、信頼度の計算対象となるユーザの特徴量を学習モデルに入力し、学習モデルから出力された信頼度を取得してもよい。この信頼度は、学習モデルによって推定された信頼度である。

【0135】

決定部１０１は、信頼度取得部１０４により取得された信頼度に基づいて、都度決済又は一括決済の何れを実行するかを決定する。例えば、決定部１０１は、あるユーザの信頼度が閾値未満であれば、このユーザに一括決済を許可せずに、このユーザの決済方法として、都度決済を決定する。この場合、ユーザは、一括決済を選択できず、都度決済しか選択できない。即ち、強制的に都度決済が決定される。

【0136】

決定部１０１は、あるユーザの信頼度が閾値以上であれば、このユーザに一括決済を許可する。この場合、決定部１０１は、都度決済及び一括決済のうち、ユーザが選択した方を、このユーザの決済方法として決定する。ユーザは、都度決済及び一括決済のうちの好きな方を選択できる。なお、あるユーザの信頼度が閾値以上である場合、このユーザの決済方法が強制的に一括決済となるようにしてもよい。

【0137】

変形例１によれば、ユーザの信頼度に基づいて、都度決済又は一括決済の何れを実行するかを決定することによって、電子決済が未完了になることを防止しやすくなる。例えば、一括決済は合計額が高額になりがちであるところ、信頼度の低いユーザが一括決済を実行しようとすると、一括決済が未完了になる確率が高くなる。信頼度の低いユーザは、比較的低額な都度決済にすることで、電子決済が未完了になることを防止しやすくなる。信頼度の高いユーザについては、一括決済が多少高額になったとしても、一括決済を完了できる確率が高いため、利便性の高い一括決済を利用させることができる。実施形態のように、チェックアウト時に一括決済が実行される場合、ユーザは、電子決済が未完了になると、その場で他の決済手段を選択したりチャージをしたりする必要があり、円滑なチェックアウトができなくなる可能性があるが、電子決済が完了しやすい決済方法とすることで、円滑なチェックアウトが可能になる。その結果、スタジアムのエントランス等における混雑を緩和できる。他にも例えば、信頼のできないユーザが一括決済をせずにスタジアムのエントランスを突破するといったことを未然に防止できる。

【0138】

［５－２．変形例２］
図１４は、変形例２の電子決済システムＳの一例を示す図である。変形例２の決定部１０１は、決済要求が受け付けられるたびに、都度決済又は一括決済の何れを実行するかを決定する。図１４に示すように、チェックイン時にユーザが都度決済又は一括決済を選択するのではなく、ユーザがコードＣ４０を決済端末５０にかざすたびに、都度決済又は一括決済の何れかを選択するための選択画面Ｇ１１が表示される。

【0139】

ユーザは、ボタンＢ１１０を選択すると、都度決済を選択できる。ユーザは、ボタンＢ１１１を選択すると、一括決済を選択できる。決定部１０１は、選択画面Ｇ１１における選択結果に基づいて、決済要求が受け付けられるたびに、都度決済又は一括決済の何れを実行するかを決定する。このため、変形例１では、ユーザの決済方法を識別可能な情報を第１データベースＤＢ１に格納する必要はない。

【0140】

変形例２の選択受付部３０２は、ユーザによる、ボタンＢ１１０又はボタンＢ１１１の選択を受け付ける。ユーザが決済方法を選択する方法自体は、実施形態で説明したように、任意の方法を利用可能である。選択受付部３０２は、ユーザがボタンＢ１１０又はボタンＢ１１１の何れかを選択したうえでボタンＢ１１２を選択すると、ユーザの選択結果を第１サーバ１０に送信する。

【0141】

第１サーバ１０は、ユーザの選択結果を受信すると、電子決済実行部１０３は、都度決済が実行された決済要求を一括決済の対象から除外し、都度決済が実行されなかった複数の決済要求に基づいて、一括決済を実行する。実施形態で説明したように、第１サーバ１０が決済端末５０から決済要求を受信した場合には、電子決済実行部１０３は、ユーザの選択結果を受信するまでは、この決済要求を保留する。

【0142】

電子決済実行部１０３は、ユーザの選択結果を受信した場合に、この選択結果に応じた処理を実行する。例えば、電子決済実行部１０３は、ユーザが都度決済を選択したことを示す選択結果を受信した場合には、この選択結果の受信に応じて、実施形態で説明した流れで都度決済を実行する。図１４に示すように、ユーザ端末３０には、都度決済が完了したことを示す決済完了画面Ｇ５が表示される。この決済完了画面Ｇ５は、図５と同様である。

【0143】

また例えば、電子決済実行部１０３は、ユーザが一括決済を選択したことを示す選択結果を受信した場合には、この選択結果の受信に応じて、実施形態で説明した流れで電子決済の実行を保留すればよい。図１４に示すように、ユーザ端末３０には、決済要求が受け付けられて電子決済が保留されたことを示す受付完了画面Ｇ８が表示される。この受付完了画面Ｇ８は、図５と同様である。

【0144】

変形例２によれば、決済要求が受け付けられるたびに、都度決済又は一括決済の何れを実行するかを決定することによって、電子決済におけるユーザの利便性が高まる。例えば、ユーザは、スタジアムにおける飲食代だけを一括決済の対象とすることによって、スタジアムにおける飲食代の領収書を１つにまとめることができる。この場合、一括決済の領収書は、第１アプリから出力可能とする。

【0145】

［５－３．変形例３］
図１５は、変形例３の電子決済システムＳの一例を示す図である。図１５の例では、第１アプリの支払い元として電子マネーが選択されており、ユーザの決済方法として一括決済が選択されている（ホーム画面Ｇ４Ｃの状態）。変形例１で説明したように、一括決済の合計額が多くなると、チェックアウト時に電子マネーの残高が不足し、スムーズにチェックアウトできない可能性がある。そこで、変形例３では、一括決済の合計額が多くなった場合に、都度決済に自動的に変更されるようになっている。

【0146】

変形例３の決定部１０１は、一括決済を実行すると決定された場合に、複数の決済要求の利用額を合計した合計額が閾値以上であるか否かを判定する。この合計額は、ユーザの利用履歴のうち、一括決済フラグが「１」の利用額の合計額である。この閾値は、固定値であってもよいし、可変値であってもよい。可変値である場合には、電子マネーの残高に応じた閾値であってもよい。この場合、電子マネーの残高がそのまま閾値になってもよいし、電子マネーの残高よりも多い額又は少ない額が閾値になってもよい。他にも例えば、変形例１で説明した信頼度に応じた閾値であってもよい。

【0147】

決定部１０１は、合計額が閾値以上であると判定された場合に、一括決済から都度決済に変更する。図１５に示すように、ユーザの決済方法として、都度決済が自動的に選択される（ホーム画面Ｇ４Ｄの状態）。この場合、ボタンＢ４３がグレーアウト又は消去され、ユーザが決済方法の変更を指示できないようにしてもよい。第１データベースＤＢ１に格納されたユーザの決済方法は、決定部１０１により都度決済に変更される。

【0148】

電子決済実行部１０３は、一括決済から都度決済に変更された後は、決済要求が受け付けられるたびに、都度決済を実行する。都度決済の実行方法は、実施形態で説明した通りである。図１５に示すように、ユーザがボタンＢ４４を選択して履歴確認画面Ｇ９が表示された場合には、電子マネーの残高と、チェックアウト前のチャージを促すメッセージと、を含む情報Ｉ９３が表示されてもよい。電子マネーの残高は、ホーム画面Ｇ４Ｃ，Ｇ４Ｄに表示されてもよい。

【0149】

図１５の例では、情報Ｉ９１が示す「３／２７ １６：０２：２５」の店舗３の決済端末５０からの決済要求により、一括決済の合計額が閾値（例えば、電子マネーの残高の３３００円よりも１円高い３３０１円）以上になったので、一括決済から都度決済に変更されている。情報Ｉ９０が示す「３／２７ １６：１２：３５」の売り子２の決済端末５０からの決済要求は、都度決済として処理されている。情報Ｉ９３に示すように、このままではユーザは一括決済を実行できないので、第１アプリ等を利用して電子マネーにチャージすることが促される。なお、図１５の例において、「３／２７ １６：０２：２５」の店舗３の決済端末５０からの決済要求が一括決済として処理される前に、都度決済に変更されてもよい。この場合、一括決済の合計額が電子マネーの残高を超える前に、一括決済から都度決済に変更される。

【0150】

変形例３によれば、一括決済の合計額が閾値以上であると判定された場合に、一括決済から都度決済に変更することによって、一括決済が未完了になりにくくなる。

【0151】

［５－４．変形例４］
図１６は、変形例４の電子決済システムＳの一例を示す図である。実施形態では、チェックアウト時に一括決済が実行される場合を説明したが、変形例４では、ユーザがスタジアムにいる間に一括決済を指示できるものとする。ユーザがスタジアムにいる間であったとしても、一括決済の実行が指示されると、一括決済が実行される。一括決済は、いつでも実行を指示できてもよいが、変形例４では、一括決済の合計額が閾値以上になった場合に、スタジアム内で一括決済を指示できるようになる。

【0152】

変形例４の電子決済実行部１０３は、一括決済を実行すると決定された場合に、複数の決済要求の利用額を合計した合計額（一括決済の合計額）が閾値以上であるか否かを判定する。図１６に示すように、ユーザがホーム画面Ｇ４のコードＣ４０を決済端末５０にかざした場合に、この判定が実行される。この閾値は、変形例３と同じ値であってもよいし、異なる値であってもよい。電子決済実行部１０３は、この合計額がこの閾値以上であると判定された場合に、一括決済を実行する。この場合の流れは、実施形態で説明した通りであり、図８のような受付完了画面Ｇ８が表示される。

【0153】

電子決済実行部１０３は、一括決済の合計額が閾値未満であると判定された場合には、一括決済の実行を制限する。この制限は、一括決済を実行しないことを意味してもよいし、通常の一括決済の流れとは異なる流れになることを意味してもよい。例えば、図１６に示すように、電子決済実行部１０３は、チェックアウトの前に、いったん一括決済を実行することを確認するためのメッセージを受付完了画面Ｇ８に表示させるためのデータを、ユーザ端末３０に送信する。ユーザ端末３０には、図１６の受付完了画面Ｇ８が表示される。ユーザが図１６のボタンＢ８０を選択しなかった場合、受付完了画面Ｇ８に表示された決済要求は、一括決済の対象から除外される。即ち、この決済要求は、キャンセルされる。

【0154】

ユーザが図１６のボタンＢ８０を選択すると、電子決済実行部１０３は、一括決済を実行し、一括決済の決済完了画面Ｇ１２がユーザ端末３０に表示される。この一括決済は、チェックアウトの前に実行される点で実施形態と異なるだけであり、一括決済の実行方法自体は、実施形態で説明した通りである。決済完了画面Ｇ１２には、実行された一括決済の詳細を示す情報Ｉ１２０と、実行された一括決済の合計額を示す情報Ｉ１２１と、が表示される。ユーザは、まだチェックアウトしていないので、引き続きスタジアムでサービスを利用できる。ユーザが一括決済を利用する場合、一から再び一括決済の決済要求が保留される。

【0155】

変形例４によれば、一括決済の合計額が閾値以上であると判定された場合に、一括決済を実行することによって、ある程度こまめに一括決済を実行し、一括決済が未完了になりにくくなる。こまめに一括決済を実行することで、チェックアウト時の一括決済の合計額が高額になりすぎることを防止できる。

【0156】

［５－５．変形例５］
例えば、決定部１０１は、ユーザが利用可能な決済手段の残高に基づいて、都度決済又は一括決済の何れを実行するかを決定してもよい。この決済手段は、残高の概念が存在する決済手段であり、例えば、電子マネー、電子キャッシュ、又は銀行口座を利用した決済手段である。決済手段の残高は、第１データベースＤＢ１に格納されていてもよいし、決済手段を管理する決済事業者に問いあわせることによって取得されてもよい。

【0157】

決定部１０１は、支払い元として選択された決済手段の残高が閾値以上であるか否かを判定する。この閾値は、固定値であってもよいし、可変値であってもよい。可変値である場合には、閾値は、ユーザの過去の利用履歴から決定されてもよい。例えば、ユーザの過去の利用履歴における平均利用額が高いほど、閾値が大きくなる。決定部１０１は、残高が閾値未満であれば、このユーザに一括決済を許可せずに、このユーザの決済方法として、都度決済を決定する。この場合、ユーザは、一括決済を選択できず、都度決済しか選択できない。即ち、強制的に都度決済が決定される。

【0158】

決定部１０１は、残高が閾値以上であれば、このユーザに一括決済を許可する。この場合、決定部１０１は、都度決済及び一括決済のうち、ユーザが選択した方を、このユーザの決済方法として決定する。ユーザは、都度決済及び一括決済のうちの好きな方を選択できる。なお、あるユーザの残高が閾値以上である場合、このユーザの決済方法が強制的に一括決済となるようにしてもよい。

【0159】

変形例５によれば、ユーザが利用可能な決済手段の残高に基づいて、都度決済又は一括決済の何れを実行するかを決定することによって、電子決済が未完了になることを防止しやすくなる。例えば、一括決済は高額になりがちであるところ、決済手段の残高の少ないユーザが一括決済を実行しようとすると、一括決済が未完了になる確率が高くなる。残高が少ないユーザは、利用額が比較的低額な都度決済にすることで、電子決済が未完了になることを防止しやすくなる。残高の多いユーザについては、一括決済が多少高額になったとしても、一括決済を完了できる確率が高いため、利便性の高い一括決済を利用させることができる。その結果、変形例１と同様の理由で、円滑なチェックアウトが可能になり、スタジアムのエントランス等における混雑を緩和できる。

【0160】

［５－６．変形例６］
例えば、決定部１０１は、ユーザが利用可能な複数の決済手段のうち、ユーザにより選択された決済手段に基づいて、都度決済又は一括決済の何れを実行するかを決定する。例えば、電子マネー又は電子キャッシュは、残高の上限額が定められていることが多く、電子決済が比較的未完了になりやすい。一方、クレジットカード決済の与信枠や銀行口座の残高は、電子マネー又は電子キャッシュの残高よりも余裕があることが多いので、電子決済が比較的未完了になりにくい。

【0161】

そこで、決定部１０１は、ユーザの支払い元の決済手段が電子マネー又は電子キャッシュの場合には、このユーザに一括決済を許可せずに、このユーザの決済方法として、都度決済を決定する。この場合、ユーザは、一括決済を選択できず、都度決済しか選択できない。即ち、強制的に都度決済が決定される。なお、オートチャージに対応可能な電子マネー又は電子キャッシュであれば、未完了になりにくいので、一括決済が許可されてもよい。

【0162】

決定部１０１は、ユーザの支払い元の決済手段がクレジットカード又は銀行口座である場合には、このユーザに一括決済を許可する。この場合、決定部１０１は、都度決済及び一括決済のうち、ユーザが選択した方を、このユーザの決済方法として決定する。ユーザは、都度決済及び一括決済のうちの好きな方を選択できる。なお、ユーザの支払い元の決済手段がクレジットカード又は銀行口座である場合には、このユーザの決済方法が強制的に一括決済となるようにしてもよい。

【0163】

なお、決済手段と、ユーザの決済方法と、関係は、上記の例に限られない。データ記憶部１００に、都度決済しか許可されない決済手段の種類と、都度決済だけでなく一括決済も許可される決済手段の種類と、が定義されていればよい。決定部１０１は、この定義に基づいて、ユーザに許可される決済方法を特定すればよい。

【0164】

変形例６によれば、ユーザが利用可能な複数の決済手段のうち、ユーザにより選択された決済手段に基づいて、都度決済又は一括決済の何れを実行するかを決定することによって、電子決済が未完了になることを防止しやすくなる。例えば、一括決済は高額になりがちであるところ、残高が少なくなりがちな電子マネー又は電子キャッシュで一括決済を実行しようとすると、一括決済が未完了になる確率が高くなる。このため、電子マネー又は電子キャッシュが支払い元として選択された場合に、利用額が比較的低額な都度決済にすることで、電子決済が未完了になることを防止しやすくなる。未完了になりにくいクレジットカード又は銀行口座が支払い元として選択された場合には、一括決済が多少高額になったとしても、一括決済を完了できる確率が高いため、利便性の高い一括決済を利用させることができる。その結果、変形例１及び変形例５と同様の理由で、円滑なチェックアウトが可能になり、スタジアムのエントランス等における混雑を緩和できる。

【0165】

［５－７．変形例７］
図１７は、変形例７の履歴確認画面Ｇ９の一例を示す図である。図１７に示すように、変形例７の履歴確認画面Ｇ９は、一括決済の合計額が多くなった場合に、アラートを示す情報Ｉ９４が表示されるようになっている。

【0166】

変形例７の電子決済システムＳは、ユーザによる、一括決済の実行指示を受け付ける実行指示受付部４０２を更に含む。実施形態のように、チェックアウト時に一括決済が実行される場合には、実行指示受付部４０２は、ユーザによるチェックアウトの指示を受け付ける。この指示自体は、実施形態で説明したように、コードＣ４０をチェックイン端末４０にかざす操作が一例として挙げられる。一括決済の実行指示は、ユーザ端末３０から行われてもよい。この場合、実行指示受付部４０２は、ユーザ端末３０により実現される。

【0167】

電子決済実行部１０３は、実行指示が受け付けられた場合に、一括決済を実行する。実行指示が一括決済のトリガとなる。一括決済の実行方法自体は、実施形態で説明した通りである。変形例７の電子決済システムＳは、実行指示が受け付けられる前に、残高が合計額未満であると判定された場合に、ユーザに所定の通知を行う通知部１０５を含む。図１７の例であれば、通知部１０５は、情報Ｉ９４を含む履歴確認画面Ｇ９の表示データを生成し、ユーザ端末３０に送信することによって通知を行う。通知は、任意の方法で行われてよく、画像を利用した視覚的な方法に限られない。例えば、音声を利用して聴覚的な通知が行われてもよいし、ユーザ端末３０の振動を利用して触覚的な通知が行われてもよい。

【0168】

変形例７によれば、一括決済の実行指示が受け付けられる前に、残高が合計額未満であると判定された場合に、ユーザに所定の通知を行うことによって、電子決済が未完了になることを防止しやすくなる。

【0169】

［５－８．変形例８］
図１８は、変形例８におけるチェックアウト完了画面Ｇ１０の一例を示す図である。変形例８の電子決済システムＳは、電子決済実行部１０３により一括決済が実行された場合に、一括決済における合計額の領収書を出力する領収書出力部１０６を含んでもよい。例えば、ユーザがチェックアウト完了画面Ｇ１０のボタンＢ１０３を選択すると、ユーザ端末３０から第１サーバ１０に、一括決済の領収書を出力するための要求が送信される。第１サーバ１０が、この情報を受信すると、領収書出力部１０６は、領収書を生成する。

【0170】

なお、領収書のフォーマットのデータは、データ記憶部１００に予め記憶されているものとする。領収書出力部１０６は、このフォーマットに合計額をはめ込むことによって、領収書を生成する。領収書の但し書きは、一括決済に含まれる明細に応じた内容が設定される。ユーザ端末３０には、この領収書を含む領収書画面Ｇ１３が表示される。入力フォームＦ１３０には、第１データベースＤＢ１に登録された氏名が自動入力される。ユーザは、入力フォームＦ１３０から宛名を変更できる。ユーザがボタンＢ１３１を選択すると、第１サーバ１０は、この領収書のデータを、ユーザのメールアドレスに送信する。このメールアドレスは、第１データベースＤＢ１に登録されているものとする。領収書のデータは、ＳＮＳ又はメッセージアプリ等の任意の手段を利用して送信可能である。領収書の出力は、領収書の画面をユーザ端末３０に表示させること、又は、領収書のデータをユーザに送信することである。

【0171】

変形例８によれば、一括決済における合計額の領収書を出力することによって、ユーザの利便性が高まる。例えば、ユーザが顧客との接待でスタジアムを訪れた場合に、スタジアム内における電子決済には、接待のための電子決済と、私的な電子決済と、が混在することがある。この点、接待の経費として申請可能なものだけを一括決済の対象にすることによって、接待の経費として申請可能な領収書を出力でき、ユーザの利便性が高まる。

【0172】

［５－９．変形例９］
図１９は、変形例９における履歴確認画面Ｇ９の一例を示す図である。図１９に示すように、例えば、履歴確認画面Ｇ９には、ユーザに付与される特典に関する情報Ｉ９５と、スタジアムのおすすめの情報Ｉ９６と、が表示される。図１９の例では、スタジアムに併設された駐車場の料金が無料になることが特典に相当する。この特典は、データとして電子的に付与されてもよいし、スタジアム内のスタッフにユーザ端末３０を見せる等することによって付与されてもよい。ユーザがスタジアム内で所定額（図１９では５０００円）利用すると、駐車場が無料になる。情報Ｉ９５は、スタジアムの駐車場が無料になるまでに必要な残り金額が示される。情報Ｉ９６は、駐車場が無料になるまでの不足額を達成できる程度の商品が表示されてもよい。

【0173】

変形例９の電子決済システムＳは、複数の決済要求の利用額を取得する利用額取得部１０７と、複数の利用額に応じた情報を、ユーザに提供する情報提供部１０８と、を含む。第１データベースＤＢ１に格納された利用履歴に利用額が含まれているので、利用額取得部１０７は、第１データベースＤＢ１を参照し、スタジアム内でユーザが利用した一連のサービスの利用額を取得する。第１データベースＤＢ１には、スタジアム外の電子決済の利用履歴も存在するので、利用額取得部１０７は、あるユーザの利用履歴のうち、スタジアム内における電子決済の利用額を取得する。スタジアム内における電子決済は、利用履歴に含まれる支払先から特定されてもよいが、本実施形態では、スタジアムへのチェックインが実行されるので、スタジアム内における電子決済は、利用履歴に含まれる利用日時から特定される。

【0174】

情報提供部１０８は、第１アプリを利用して、ユーザに情報Ｉ９０～Ｉ９２，Ｉ９５，Ｉ９６を提供する。利用額に応じた情報とは、利用額に応じて内容が変わる情報である。この情報は、ユーザが訪れたスタジアムに関する情報である。例えば、この情報は、個々の利用額そのもの、利用額の合計額、所定の額になるまでの不足額、利用額に応じたおすすめ情報、又は利用額に応じたクーポン情報である。これらの情報の提供に必要なデータは、第１サーバ１０又は他のコンピュータに記憶されているものとする。

【0175】

ここでの提供とは、何らかの手段を利用してユーザに情報を与えることである。本実施形態では、第１アプリの画面を利用して画像を表示することが提供に相当する場合を説明するが、他の手段を利用して提供が行われてもよい。例えば、第１アプリ以外のアプリ又はブラウザを利用して画像を表示することが提供に相当してもよい。また例えば、電子メール等のメッセージを利用して情報を送信することが提供に相当してもよい。また例えば、視覚的な情報の提供に限られず、ボイスメール等の音声を利用した情報の提供であってもよい。

【0176】

変形例９のように、ユーザがスタジアムで所定の額以上の利用をした場合に、ユーザに所定の特典が与えられる場合には、情報提供部１０８は、利用額取得部１０７により取得された複数の利用額に基づいて、特典に必要な額を計算し、当該計算された額を、情報Ｉ９５としてユーザに提供してもよい。

【0177】

特典とは、ユーザに何らかの利益が発生するものである。特典は、有体物であってもよいし、データのような無体物であってもよい。特典は、ユーザが何かを行うことができる権利であってもよい。本実施形態では、駐車場の無料券が特典に相当する場合を説明する。このため、駐車場の無料券について説明している箇所は、特典と読み替えることができる。特典は、本実施形態の例に限られない。特典自体は、公知の特典を利用可能であり、例えば、クーポン、割引、商品そのもの、又は何らかの利用券であってもよい。

【0178】

情報提供部１０８は、特典を得るための基準となる額と、上記計算された合計額と、の差を特典に必要な額として計算する。例えば、情報提供部１０８は、当該計算された額を、情報Ｉ９５としてユーザに提供する。また例えば、情報提供部１０８は、当該計算された額以上の商品又は商品の組み合わせを検索し、情報Ｉ９６としてユーザに提供する。商品の価格等の情報は、データ記憶部１００に記憶されているものとする。

【0179】

変形例９によれば、複数の決済要求の利用額に応じた情報を、ユーザに提供することによって、ユーザに有益な情報を提供できる。

【0180】

［５－１０．変形例１０］
例えば、第１サービスが、ユーザ端末３０を利用した電子決済を提供するサービスである場合、ユーザは、電子決済を実行しようとすると、ユーザ端末３０を取り出す必要がある。この点、ユーザ端末３０を取り出す手間を省くために、生体認証を利用して電子決済を実行することが検討されている。例えば、ユーザの顔認証だけで電子決済時の認証が完了するのであれば、ユーザは、ユーザ端末３０を取り出さなくて済む。

【0181】

しかしながら、第１サービスのユーザの中には、あるユーザと顔が似た他のユーザが存在することがある。この場合、あるユーザが顔認証で電子決済を実行しようとすると、顔が似た他のユーザに誤認証されてしまい、適切な電子決済が実行できないことがある。第１サービスを利用していない悪意のある第三者が、顔が似たユーザに成りすまして、このユーザのクレジットカード等を利用して電子決済する可能性もある。

【0182】

そこで、変形例１０では、あるユーザがチェックインした場所の中であれば、このユーザについては、顔認証による電子決済が許可されるようになっている。この場所の中にいる人間の数は限られているので、顔認証が成功する程度に顔が似た者がいる可能性は非常に低い。チェックイン時には、ユーザ端末３０を利用してセキュアな本人確認（いわゆる所持認証）が行われるため、顔認証による電子決済の範囲を、チェックインした場所に限定することによって、ユーザの利便性を高めつつ、セキュリティ性を担保できる。

【0183】

図２０は、変形例１０の電子決済システムＳの一例を示す図である。図２０に示すように、実施形態と同様にして、ユーザがスタジアムにチェックインすると、スタジアム内に配置された決済端末５０であれば、生体認証による電子決済が可能になる。このため、ユーザは、コードＣ４０を表示させる必要はない。

【0184】

決済端末５０は、認証装置の一例である。このため、決済端末５０と記載した箇所は、認証装置と読み替えることができる。認証装置は、生体認証が可能な装置であればよい。電子決済実行部１０３が、ユーザのユーザ端末３０を利用して電子決済を実行する場合に、スタジアムには、ユーザの生体認証を実行するための認証装置が配置されている。変形例１０では、顔認証が生体認証に相当する場合を説明するが、生体認証自体は、任意の生体認証を利用可能である。例えば、指紋認証、静脈認証、又は声紋認証といった他の生体認証が利用されてもよい。

【0185】

変形例１０の第１データベースＤＢ１には、ユーザＩＤに関連付けて、生体認証で利用される認証情報が格納されている。この認証情報は、生体認証における正解となる情報であり、例えば、顔の特徴量、顔写真、指紋パターン、静脈パターン、又は声紋パターンであってよい。ユーザは、第１サービスの利用設定時に、認証情報の登録に必要な情報（顔写真等）を第１サーバ１０にアップロードする。第１サーバ１０は、当該アップロードされた情報に基づいて、このユーザのユーザＩＤに関連付けて、認証情報を格納する。

【0186】

変形例１０の電子決済システムＳは、チェックインが実行された場合には、スタジアムにおいて、ユーザ端末３０を利用せずに、生体認証によって電子決済が実行されることを許可する許可部１０９を含む。第１サーバ１０は、第２サーバ２０からチェックインが実行されたユーザのユーザＩＤを取得する。第１サーバ１０は、第２サーバ２０からこのユーザＩＤを取得するのではなく、チェックイン時に第２サーバ２０に送信したユーザＩＤを、データ記憶部１００に保持してもよい。

【0187】

例えば、許可部１０９は、スタジアムにチェックインしたユーザのユーザＩＤに、生体認証による電子決済が許可されたことを示す情報を関連付ける。これらの関連付けは、第１データベースＤＢ１に保持されてもよいし、他のデータベースに保持されてもよい。電子決済実行部１０３は、生体認証による電子決済が許可されたユーザについては、このユーザの生体認証が成功した場合に、電子決済を実行する。

【0188】

電子決済実行部１０３は、生体認証による電子決済が許可されていないユーザについては、生体認証による電子決済を実行しない。電子決済実行部１０３は、生体認証による電子決済が許可されていないユーザであったとしても、もし仮にスタジアム以外のコンピュータから生体認証による電子決済の要求を受け付けたとしても、生体認証による電子決済を実行しない。スタジアムにチェックインしたユーザと顔が似た他のユーザが第１データベースＤＢ１に登録されていたとしても、当該他のユーザはチェックインしていないので、生体認証の判定時に当該他のユーザの情報は判定されない。このため、当該他のユーザのクレジットカード情報等の決済情報は利用されない。

【0189】

図２０の例であれば、ユーザは、スタジアムの座席でドリンクを購入する場合に、売り子が所持する決済端末５０のカメラで自分の顔を撮影させる。決済端末５０は、自身の端末ＩＤとともに、撮影画像を第１サーバ１０に送信する。第１サーバ１０が端末ＩＤ及び撮影画像を受信すると、電子決済実行部１０３は、撮影画像から顔の特徴量を計算する。電子決済実行部１０３は、第１データベースＤＢ１に格納された認証情報のうち、スタジアムにチェックイン中のユーザの認証情報を取得する。

【0190】

電子決済実行部１０３は、計算した顔の特徴量と、取得した認証情報と、に基づいて、生体認証を実行する。生体認証自体は、公知の方法を利用可能であり、顔の特徴量の類似度によって成否が判定されるようにすればよい。顔認証以外の生体認証が利用される場合も同様に、生体認証自体は、公知の方法を利用可能である。認証時の判定対象となる認証情報が、チェックイン中のユーザのものだけに限定されるようにすればよい。

【0191】

電子決済実行部１０３は、生体認証が成功した場合に、電子決済を実行する。電子決済実行部１０３は、第１データベースＤＢ１を参照し、計算した顔の特徴量と類似する認証情報に関連付けられたクレジットカード情報等の決済情報を取得する。電子決済実行部１０３は、この決済情報に基づいて、電子決済を実行する。図２０に示すように、ユーザがスタジアム内の売店でグッズを購入する場合、及び、スタジアム内のレストランで食事した場合も同様に、顔認証だけで電子決済が許可される。

【0192】

許可部１０９は、ユーザがチェックアウトした場合、チェックインしてから所定の時間が経過した場合、又はチェックインした後の所定の時間が訪れた場合には、生体認証による電子決済を禁止する。図２０の例であれば、ユーザがチェックイン端末４０にユーザ端末３０のコードＣ６０をかざしてチェックアウトした場合には、許可部１０９は、生体認証が許可されないように、第１データベースＤＢ１を更新する。

【0193】

変形例１０によれば、チェックインが実行された場合には、スタジアムおいて、ユーザ端末を利用せずに、生体認証によって電子決済が実行されることを許可することによって、ユーザの利便性を高めることができる。また、生体認証による電子決済が許可される範囲をスタジアム内に限定することで、誤認証や成りすましを防止し、セキュリティを高めることができる。

【0194】

［５－１１．変形例１１］
例えば、上記説明した変形例を組み合わせてもよい。

【0195】

また例えば、チェックアウトの手続きは省略してもよい。この場合、ユーザがユーザ端末３０から一括決済の指示をしてもよい。また例えば、電子決済用のコードと、チェックイン用のコードと、は同じであってもよい。チェックイン用のコードと、チェックアウト用のコードと、は異なってもよい。１つのコードで複数の第２サービスに関する場所にチェックイン可能であってもよい。即ち、第１サービスは、複数の第２サービスと連携してもよい。第１サービスが複数の第２サービスと連携する場合には、履歴確認画面Ｇ９には、第２サービスごとに、複数の利用額に応じた情報が表示されてもよい。

【0196】

また例えば、ユーザがユーザ端末３０をチェックイン端末４０にかざすことによってチェックインが実行される場合を説明したが、画像を利用するのではなく、ＩＣチップ３７に記録された何らかのＩＤをチェックイン端末４０に読み取らせてチェックインが実行されてもよい。また例えば、ユーザ端末３０又はチェックイン端末４０の何れか一方のみによってチェックインが実行されてもよい。例えば、スタジアム等の場所に掲示又は何らかのコンピュータに表示されたコードがユーザ端末３０の撮影部３６で撮影された場合に、ユーザ端末３０から第１サーバ１０に、この場所を識別可能な情報と、ユーザ端末３０に記憶されたコードＩＤと、が送信されてもよい。この場合、チェックイン端末４０は不要になる。

【0197】

また例えば、ユーザ端末３０のＧＰＳ受信部３８によって検出された現在位置がスタジアムの付近になった場合に、チェックインが実行されてもよい。この場合、チェックイン端末４０は不要になる。また例えば、ユーザがＩＣカード又は磁気カードをチェックイン端末４０で読み取ることによってチェックインが実行されてもよい。この場合、ユーザ端末３０は不要になる。第１サーバ１０及び第２サーバ２０には、実施形態で説明したユーザＩＤと、ＩＣカード又は磁気カードに含まれるＩＤと、の関係が記憶されているものとする。他にも例えば、ユーザがチェックイン端末４０からの生体認証でチェックインが実行されてもよい。この場合もユーザ端末３０は不要になる。第１サーバ１０及び第２サーバ２０には、実施形態で説明したユーザＩＤと、ユーザの生体情報と、の関係が記憶されているものとする。

【0198】

また例えば、第１サーバ１０と第２サーバ２０が分けられておらず、１つのコンピュータで各機能が実現されてもよい。また例えば、第１サーバ１０で実現されるものとして説明した機能は、複数のコンピュータで分担されてもよい。また例えば、第２サーバ２０で実現されるものとして説明した機能は、複数のコンピュータで分担されてもよい。各機能は、少なくとも１つのコンピュータで実現されるようにすればよい。

【符号の説明】

【0199】

Ｓ 電子決済システム、Ｎ ネットワーク、１１，２１，３１，４１，５１ 制御部、１２，２２，３２，４２，５２ 記憶部、１３，２３，３３，４３，５３ 通信部、３０ ユーザ端末、３４，４４，５４ 操作部、３５，４５，５５ 表示部、３６ 撮影部、３７ ＩＣチップ、３８ ＧＰＳ受信部、４０ チェックイン端末、４６，５６ 読取部、５０ 決済端末、Ｇ４ ホーム画面、Ｇ５ 決済完了画面、Ｇ６ 表示画面、Ｇ８ 受付完了画面、Ｇ９ 履歴確認画面、Ｇ１０ チェックアウト完了画面、Ｇ１１ 選択画面、Ｇ１２ 決済完了画面、Ｇ１３ 領収書画面、Ｐ１ トップページ、Ｐ２ ログインページ、Ｐ３ 購入完了ページ、１００ データ記憶部、１０１ 決定部、１０２ 決済要求受付部、１０３ 電子決済実行部、１０４ 信頼度取得部、１０５ 通知部、１０６ 領収書出力部、１０７ 利用額取得部、１０８ 情報提供部、１０９ 許可部、２００ データ記憶部、２０２ チェックイン実行部、２０３ チェックアウト実行部、３００ データ記憶部、３０１ 表示制御部、３０２ 選択受付部、４００ データ記憶部、４０１ コードＩＤ取得部、４０２ 実行指示受付部、５００ データ記憶部、５０１ コードＩＤ取得部、Ｂ２２，Ｂ４１，Ｂ４３，Ｂ４４，Ｂ７０，Ｂ７１，Ｂ８０，Ｂ１０３，Ｂ１１０，Ｂ１１１，Ｂ１１２，Ｂ１３１ ボタン、Ｃ４０，Ｃ６０ コード、Ｉ４２，Ｉ９０，Ｉ９１，Ｉ９２，Ｉ９３，Ｉ９４，Ｉ９５，Ｉ９６，Ｉ１００，Ｉ１２０，Ｉ１２１ 情報。

【要約】      （修正有）

【課題】ユーザが所定の場所を訪れて一連のサービスを利用する場合の電子決済の利便性を高める電子決済システム、電子決済方法及びプログラムを提供する。
【解決手段】第１サーバ１０、第２サーバ２０、ユーザ端末３０、チェックイン端末４０及び決済端末５０が、インターネット等のネットワークに接続可能な電子決済システムにおいて、第１サーバ１０は、ユーザが所定の場所を訪れて一連のサービスを利用する場合に、電子決済の決済要求を受け付ける決済要求受付部１０２と、決済要求のたびに実行される都度決済又は複数の決済要求が一括された一括決済の何れを実行するかをユーザに応じて決定する決定部１０１と、決定手部１０１の決定結果に基づいて、都度決済又は一括決済を実行する電子決済実行部１０３と、を有する。
【選択図】図７

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】