JP7053396B2 - 決済システム、決済方法、及びプログラム - Google Patents

Description

本発明は、決済システム、決済方法、及びプログラムに関する。

従来、決済処理を実行するために、スマートフォンやタブレット型端末などのユーザ端末を利用するシステムが知られている。例えば、特許文献１には、ユーザ端末に表示させる画像を次々と切り替え、店舗端末が所定パターンの画像を検出すると、認証成功と判定して決済処理を実行するシステムが記載されている。

特開２０１６－１３６６６５号公報

しかしながら、特許文献１の技術では、例えば、複数のユーザが共同で１つの商品を購入するといった場合には、各ユーザは、自分のユーザ端末を、１人ずつ順番に店舗端末に近づけて決済しなければならないので、非常に手間がかかると考えられる。また例えば、１人のユーザが代表で支払いをしたとしても、支払前又は支払後に他のユーザから集金する手間がかかると考えられる。

本発明は上記課題に鑑みてなされたものであって、その目的は、ユーザの手間を軽減する決済システム、決済方法、及びプログラムを提供することである。

上記課題を解決するために、本発明に係る決済システムは、所定の支払操作に基づいて、ユーザ識別情報とユーザグループ識別情報との少なくとも一方を出力するユーザ端末と、前記ユーザ端末により出力された情報を取得する店舗端末と、前記店舗端末により取得された情報に基づいて、ユーザグループを特定する特定手段と、前記特定手段により特定されたユーザグループ全体の支払額である全体支払額を取得する取得手段と、前記全体支払額に基づいて、前記特定手段により特定されたユーザグループに属する複数のユーザの個々の支払額である個別支払額を決定する決定手段と、前記ユーザごとに、当該ユーザの前記個別支払額に基づく決済をするための処理を実行する実行手段と、を含むことを特徴とする。

本発明に係る決済方法は、所定の支払操作に基づいて、ユーザ識別情報とユーザグループ識別情報との少なくとも一方をユーザ端末に出力させるステップと、前記ユーザ端末により出力された情報を店舗端末に取得させるステップと、前記店舗端末により取得された情報に基づいて、ユーザグループを特定する特定ステップと、前記特定ステップにより特定されたユーザグループ全体の支払額である全体支払額を取得する取得ステップと、前記全体支払額に基づいて、前記特定ステップにより特定されたユーザグループに属する複数のユーザの個々の支払額である個別支払額を決定する決定ステップと、前記ユーザごとに、当該ユーザの前記個別支払額に基づく決済をするための処理を実行する実行ステップと、を含むことを特徴とする。

本発明に係るプログラムは、所定の支払操作に基づいて、ユーザ識別情報とユーザグループ識別情報との少なくとも一方を出力するユーザ端末により出力され、店舗端末により読み取られた情報に基づいて、ユーザグループを特定する特定手段、前記特定手段により特定されたユーザグループ全体の支払額である全体支払額を取得する取得手段、前記全体支払額に基づいて、前記特定手段により特定されたユーザグループに属する複数のユーザの個々の支払額である個別支払額を決定する決定手段、前記ユーザごとに、当該ユーザの前記個別支払額に基づく決済をするための処理を実行する実行手段、としてコンピュータを機能させる。

本発明の一態様では、前記ユーザ端末は、所定の登録操作に基づいて、当該ユーザ端末のユーザが属するユーザグループにバリューを登録するための登録要求を送信し、前記決済システムは、各ユーザグループのバリューを記憶する記憶手段と、前記登録要求を受信した場合に、当該登録要求をしたユーザが属するユーザグループのバリューを増加させる増加手段と、前記実行手段により前記処理が実行された場合に、前記全体支払額に基づいて、前記特定手段により特定されたユーザグループのバリューを減少させる減少手段と、を含むことを特徴とする。

本発明の一態様では、前記決済システムは、前記登録要求を受信した場合に、当該登録要求により登録されるバリューに基づいて、当該登録要求をしたユーザのバリューを確保する確保手段、を更に含むことを特徴とする。

本発明の一態様では、前記実行手段は、前記ユーザごとに、当該ユーザにより登録されたバリューが当該ユーザの前記個別支払額に足りているか否かを判定し、当該判定結果に基づいて前記処理を実行する、ことを特徴とする。

本発明の一態様では、前記実行手段は、前記ユーザごとに、当該ユーザの前記個別支払額に基づく決済処理を実行する、ことを特徴とする。

本発明の一態様では、前記実行手段は、前記ユーザごとに、複数の支払方法の中から当該ユーザにより選択された支払方法で前記個別支払額に基づく決済をするための前記処理を実行する、ことを特徴とする。

本発明の一態様では、前記決済システムは、承認者に対し、所定の承認要求を送信する送信手段を更に含み、前記実行手段は、前記承認者による承認操作に基づいて、前記処理を実行する、ことを特徴とする。

本発明の一態様では、前記送信手段は、前記支払操作をしたユーザ、前記全体支払額、及び前記個別支払額の少なくとも１つを示す情報とともに前記承認要求を送信し、前記承認者の端末は、前記支払操作をしたユーザ、前記全体支払額、及び前記個別支払額の少なくとも１つを表示した後に、前記承認操作を受け付ける、ことを特徴とする。

本発明の一態様では、前記実行手段は、前記特定手段により特定されたユーザグループに属する一部のユーザによる前記承認操作に基づいて、前記処理を実行する、ことを特徴とする。

本発明の一態様では、前記決定手段は、前記一部のユーザによる前記承認操作に基づいて、当該一部のユーザの前記個別支払額を再計算し、前記実行手段は、前記一部のユーザごとに、再計算された当該ユーザの前記個別支払額に基づく前記処理を実行する、ことを特徴とする。

本発明の一態様では、前記送信手段は、前記一部のユーザのユーザ端末に対し、再計算された当該ユーザの前記個別支払額を示す情報とともに、再承認要求を送信し、前記一部のユーザのユーザ端末は、前記再承認要求を受信した場合に、当該ユーザによる再承認操作を受け付け、前記実行手段は、前記一部のユーザによる前記再承認操作に基づいて、前記処理を実行する、ことを特徴とする。

本発明によれば、ユーザの手間を軽減することが可能になる。

決済システムの全体構成を示す図である。 トップ画面の一例を示す図である。 ユーザグループが新規作成される際の画面遷移の一例を示す図である。 ユーザグループに招待されたユーザが参加する際の画面遷移の一例を示す図である。 ユーザグループの参加後にバリューの登録をする際の画面遷移の一例を示す図である。 グループ支払いが行われる際の画面遷移の一例を示す図である。 決済システムで実現される機能の一例を示す機能ブロック図である。 ユーザデータベースの一例を示す図である。 グループデータベースの一例を示す図である。 店舗データベースの一例を示す図である。 決済システムにおいて実行される処理の一例を示すフロー図である。 決済システムにおいて実行される処理の一例を示すフロー図である。 決済システムにおいて実行される処理の一例を示すフロー図である。 決済システムにおいて実行される処理の一例を示すフロー図である。 決済システムにおいて実行される処理の一例を示すフロー図である。 決済システムにおいて実行される処理の一例を示すフロー図である。 変形例の機能ブロック図である。 承認画面の一例を示す図である。

［１．決済システムの全体構成］
以下、本発明に関わる決済システムの実施形態の例を説明する。図１は、決済システムの全体構成を示す図である。図１に示すように、決済システムＳは、ユーザ端末１０、店舗端末２０、及びサーバ３０を含み、これらは、インターネットなどのネットワークに接続可能である。なお、図１では、ユーザ端末１０を２台示しているが、ユーザ端末１０は１台であってもよいし、３台以上あってもよい。また、店舗端末２０とサーバ３０を１台ずつ示しているが、これらは複数台ずつあってよい。

ユーザ端末１０は、ユーザのコンピュータであり、例えば、携帯電話機（スマートフォンを含む）、携帯情報端末（タブレット型コンピュータを含む）、又はパーソナルコンピュータ等である。ユーザ端末１０は、制御部１１、記憶部１２、通信部１３、操作部１４、及び表示部１５を含む。

制御部１１は、少なくとも一つのマイクロプロセッサを含む。制御部１１は、記憶部１２に記憶されたプログラムやデータに従って処理を実行する。記憶部１２は、主記憶部及び補助記憶部を含む。例えば、主記憶部はＲＡＭなどの揮発性メモリであり、補助記憶部は、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、又はハードディスクなどの不揮発性メモリである。通信部１３は、有線通信又は無線通信用の通信インタフェースであり、ネットワークを介してデータ通信を行う。

操作部１４は、ユーザが操作を行うための入力デバイスであり、例えば、タッチパネルやマウス等のポインティングデバイス、キーボード、又はボタンを含む。操作部１４は、操作内容を制御部１１に伝達する。表示部１５は、例えば、液晶表示部又は有機ＥＬ表示部等である。表示部１５は、制御部１１の指示に従って画面を表示する。

店舗端末２０は、店舗のコンピュータであり、例えば、携帯電話機（スマートフォンを含む）、携帯情報端末（タブレット型コンピュータを含む）、ＰＯＳ端末、又はパーソナルコンピュータ等である。店舗端末２０は、制御部２１、記憶部２２、通信部２３、操作部２４、表示部２５、及び読取部２６を含む。

制御部２１、記憶部２２、通信部２３、操作部２４、及び表示部２５のハードウェア構成は、それぞれ制御部１１、記憶部１２、通信部１３、操作部１４、及び表示部１５と同様であってよい。読取部２６は、例えば、画像読取装置又はＩＣチップのリーダライタ等である。本実施形態では、読取部２６は、画像を読み取る画像読取装置であり、例えば、コードリーダ、カメラ、又はスキャナである場合を説明する。

サーバ３０は、サーバコンピュータである。サーバ３０は、制御部２１、記憶部２２、及び通信部２３を含む。制御部２１、記憶部２２、及び通信部２３のハードウェア構成は、それぞれ制御部１１、記憶部１２、及び通信部１３と同様であってよい。

なお、記憶部１２，２２，３２に記憶されるものとして説明するプログラム及びデータは、ネットワークを介して供給されるようにしてもよい。また、上記説明した各コンピュータのハードウェア構成は、上記の例に限られず、種々のハードウェアを適用可能である。例えば、コンピュータ読み取り可能な情報記憶媒体を読み取る構成（例えば、光ディスクドライブやメモリカードスロット）や外部機器とデータの入出力をするための構成（例えば、ＵＳＢポート）が含まれていてもよい。例えば、情報記憶媒体に記憶されたプログラムやデータが上記構成を介して、各コンピュータに供給されるようにしてもよい。また例えば、ユーザ端末１０は、スピーカなどの音声出力部を含んでもよいし、店舗端末２０は、マイクなどの音声検出部を含んでもよい。

［２．決済システムの概要］
次に、決済システムＳの概要を説明する。決済システムＳでは、ユーザは、店舗で商品を購入する場合に、支払いに必要な情報を含む二次元コードをユーザ端末１０に表示させ、当該二次元コードを店舗端末２０に読み取らせることによって電子決済を実行する。

決済システムＳが提供する電子決済サービスでは、個人で支払いをする個人支払いと、ユーザグループで支払いをするグループ支払いと、の２つの方法が用意されている。ユーザは、これら２つの方法の中から任意の方法を選択する。

例えば、ユーザが個人支払いを選択した場合には、予め登録されたユーザの決済情報（例えば、クレジットカード情報や電子マネー情報等）に基づいて決済が実行される。一方、ユーザがグループ支払いを選択した場合には、ユーザグループに属する複数のユーザの各々の決済情報に基づいて決済が実行される。例えば、グループ支払いは、複数のユーザが共同で商品を購入する場合などに利用される。

本実施形態では、主に、グループ支払いについて説明する。例えば、ユーザ端末１０には、電子決済サービスのアプリケーションが予め記憶されており、ユーザが操作部１４を操作して当該アプリケーションを起動させると、トップ画面が表示部１５に表示される。

図２は、トップ画面の一例を示す図である。図２に示すように、トップ画面Ｇ１には、個人支払いをするためのボタンＢ１０、グループ支払いをするためのボタンＢ１１、ユーザグループを新規作成するためのボタンＢ１２、及び各種通知を表示させるためのボタンＢ１３が表示される。例えば、ユーザがボタンＢ１２を選択すると、ユーザグループを新規作成するための新規作成画面が表示部１５に表示される。

図３は、ユーザグループが新規作成される際の画面遷移の一例を示す図である。図３に示すように、新規作成画面Ｇ２には、グループ名を入力するための入力フォームＦ２０と、ユーザグループに招待するユーザのユーザ情報（例えば、ユーザＩＤ、ユーザ名、メールアドレス、銀行口座情報、電話番号、ＳＮＳにおけるアカウント情報若しくは友達情報、又は電子バリューにおける会員登録情報等）を入力するための入力フォームＦ２１と、が表示される。

なお、ユーザグループへの招待は、新規作成時に限られず、ユーザグループの作成後の任意のタイミングにおいて行われてもよい。また、ここでは、ユーザ情報が入力フォームから入力される場合を説明するが、ユーザグループに招待するユーザのユーザ情報は、任意の方法で取得されるようにすればよく、例えば、ユーザ端末１０に記憶されたアドレス帳（電話帳）から取得されてもよいし、サーバ３０から取得されてもよい。他にも例えば、ユーザ情報は、銀行のサーバ、ユーザのアドレス帳を管理するクラウドサーバ、ＳＮＳサーバ、又は電子バリューの管理会社のサーバといった種々のサーバコンピュータから取得されるようにしてもよい。

例えば、ユーザがボタンＢ２２を選択すると、入力フォームＦ２０に入力された名前のユーザグループが作成され、作成完了画面Ｇ３が表示部１５に表示される。作成完了画面Ｇ３には、作成されたユーザグループの名前、作成者の名前、及びユーザグループに招待したユーザの名前が表示される。なお、ユーザを招待するのは、ユーザグループの作成時に限られず、ユーザグループの作成後であってもよい。また、本実施形態では、ユーザグループの作成者は、自動的にユーザグループに参加する場合を説明するが、作成者は、自身が作成したユーザグループに参加しなくてもよい。

ユーザグループが作成されると、ユーザグループに招待されたユーザに対し、所定の招待通知が送信される。例えば、招待通知は、トップ画面Ｇ１のボタンＢ１３を選択することによって表示部１５に表示させることができる。ここでは、ユーザグループに招待されたユーザも、自身のユーザ端末１０にアプリケーションをインストール済みである場合を説明するが、アプリケーションをインストールしていないユーザについては、電子メールやメッセージアプリを利用して招待通知が行われ、アプリケーションのインストールを促してもよい。なお、招待通知は省略してもよく、ユーザ情報が入力されたユーザは自動的にユーザグループ参加してもよい。

図４は、ユーザグループに招待されたユーザが参加する際の画面遷移の一例を示す図である。図４に示すように、招待通知を受け取ったユーザのユーザ端末１０においては、招待通知を表示させるための招待通知画面Ｇ４が表示部１５に表示される。

例えば、招待通知画面Ｇ４には、招待されたユーザグループの名前、作成者の名前、及び参加者の名前といった情報が表示される。ユーザは、ボタンＢ４０を選択することによって、ユーザグループに参加することができる。ユーザがユーザグループに参加すると、参加完了画面Ｇ５が表示部１５に表示される。なお、ユーザは、ボタンＢ４１を選択することによって、ユーザグループへの参加を拒否することもできる。

ユーザグループへの参加が完了すると、ユーザは、ユーザグループに対し、バリューを仮想的に登録することができる。バリューとは、金銭的な価値であり、例えば、現金、クレジットカードの利用枠、電子マネー、又はポイントなどである。以降の説明では、「ユーザグループにバリューを登録する」といった記載をすることがあるが、本実施形態では、バリューは、あくまで仮想的に登録されるだけであり、ユーザグループにバリューが登録された時点で決済処理が実行されてユーザのバリューが実際に消費されるわけではない。

例えば、ユーザが参加完了画面Ｇ５のボタンＢ５０を選択すると、バリューを登録するためのバリュー登録画面Ｇ６が表示部１５に表示される。なお、ユーザがボタンＢ５１を選択すると、特にバリューを登録することなく、トップ画面Ｇ１に戻る。

例えば、バリュー登録画面Ｇ６には、バリューを登録しようとしているユーザグループの名前と、ユーザグループに登録されたバリューの総額と、が表示される。ユーザは、入力フォームＦ６０に自身の登録額を入力して所定の操作をすると、バリューの登録が完了し、登録完了画面Ｇ７が表示部１５に表示される。

例えば、登録完了画面Ｇ７には、バリューを登録したユーザグループの名前、ユーザグループに登録されたバリューの総額、及びユーザの登録額が表示される。なお、ここでは、ユーザグループへの参加時にバリューの登録が実行される場合を説明したが、バリューの登録は、ユーザグループの参加後の任意のタイミングで実行されてもよい。例えば、ユーザがトップ画面Ｇ１のボタンＢ１１を選択した場合に表示される、グループ支払いのメニュー画面からバリューの登録が行われてもよい。

図５は、ユーザグループの参加後にバリューの登録をする際の画面遷移の一例を示す図である。図５に示すように、メニュー画面Ｇ８には、ユーザグループにバリューを登録するためのボタンＢ８０と、グループ支払いをするためのボタンＢ８１と、が表示される。

ユーザがボタンＢ８０を選択すると、グループ支払いをするユーザグループを選択するためのグループ選択画面Ｇ９が表示部１５に表示される。グループ選択画面Ｇ９には、ユーザが参加しているユーザグループに対応するボタンＢ９０Ａ，Ｂ９０Ｂが表示される。なお、本実施形態では、ユーザは複数のユーザグループに参加できるものとするが、１つのユーザグループだけに参加できるように制限されていてもよい。

図５の例では、ユーザは、「ＸＸＸ」と「ＹＹＹ」の２つのユーザグループに参加している。例えば、ボタンＢ９０Ａは、「ＸＸＸ」というユーザグループにバリューを登録するためのボタンであり、「ＸＸＸ」には、合計１２０００円分のバリューが登録されている。また例えば、ボタンＢ９０Ｂは、「ＹＹＹ」というユーザグループのグループ支払いをするためのボタンであり、「ＹＹＹ」には、合計５０００円分のバリューが登録されている。なお、以降では、ボタンＢ９０Ａ，Ｂ９０Ｂを特に区別する必要のないときは、単にボタンＢ９０と記載する。

例えば、ユーザが、バリューを登録するユーザグループのボタンＢ９０を選択すると、バリュー登録画面Ｇ６が表示部１５に表示される。以降の流れは、ユーザグループへの参加時にバリューを登録する時と同じであり、入力フォームＦ６０に登録額を入力して所定の操作をすると、バリューの登録が完了し、登録完了画面Ｇ７が表示部１５に表示される。

以上のようにして、ユーザグループに参加した各ユーザは、自身が参加したユーザグループにバリューを登録する。ユーザグループにバリューが登録されると、当該バリューを利用したグループ支払いが可能になる。

図６は、グループ支払いが行われる際の画面遷移の一例を示す図である。図６に示すように、ユーザがメニュー画面Ｇ８のボタンＢ８１を選択すると、グループ支払いをするユーザグループを選択するためのグループ選択画面Ｇ１０が表示部１５に表示される。グループ選択画面Ｇ９には、ユーザが参加しているユーザグループに対応するボタンＢ１００Ａ，Ｂ１００Ｂが表示される。

図６の例では、ユーザは、「ＸＸＸ」と「ＹＹＹ」の２つのユーザグループに参加している。例えば、ボタンＢ１００Ａは、「ＸＸＸ」というユーザグループのグループ支払いをするためのボタンであり、「ＸＸＸ」には、合計２５０００円分のバリューが登録されている。また例えば、ボタンＢ１００Ｂは、「ＹＹＹ」というユーザグループのグループ支払いをするためのボタンであり、「ＹＹＹ」には、合計１２０００円分のバリューが登録されている。なお、以降では、ボタンＢ１００Ａ，Ｂ１００Ｂを特に区別する必要のないときは、単にボタンＢ１００と記載する。

ユーザが、グループ支払いをするユーザグループのボタンＢ１００を選択すると、グループ支払いに必要な情報を含む二次元コードを表示するためのコード表示画面Ｇ１１が表示部１５に表示される。例えば、二次元コードは、ユーザのユーザＩＤと、グループ支払いの対象となるユーザグループのユーザグループＩＤと、を含む。なお、二次元コードには、他の情報が含まれていてもよく、例えば、グループ支払いであることを識別する情報が含まれていてもよいし、所定の認証情報が含まれていてもよい。

ユーザは、コード表示画面Ｇ１１を表示部１５に表示させると、グループ支払いをする旨を店員に伝える。店員は、店舗端末２０の操作部２４を操作して商品の金額等を入力し、コード表示画面Ｇ１１の二次元コードを読取部２６で読み取る。その後、店舗端末２０は、二次元コードを解析して、サーバ３０に対し、グループ支払いの実行要求を送信する。実行要求には、二次元コードに含まれるユーザＩＤ及びユーザグループＩＤと、店員が入力した金額と、が含まれる。

サーバ３０は、受信した実行要求に基づいて、グループ支払いを実行する。例えば、サーバ３０は、実行要求に含まれるユーザグループＩＤが示すユーザグループに参加した複数のユーザを特定し、支払要求に含まれる支払金額を各ユーザで均等割りするように、グループ支払いを実行する。

なお、ユーザは、クレジットカードや電子マネーといった複数の支払方法の中から、任意の支払方法を選択可能である。支払方法は、予め選択されていてもよいし、ユーザがその場で選択してもよい。グループ支払いにおける各ユーザの決済処理は、ユーザが選択した支払方法に基づいて実行される。また、サーバ３０は、自分で決済処理を実行してもよいし、クレジットカード会社や電子マネー会社などの外部システムに対して決済処理の実行を依頼してもよい。決済処理が実行されると、グループ支払いが完了したことを示す決済完了画面Ｇ１２が表示部１５に表示される。

例えば、決済完了画面Ｇ１２には、グループ支払いが行われたユーザグループの名前、ユーザグループ全体の支払額、ユーザ１人当たりの支払額、支払先の店舗の名前、及び支払者の名前といった情報が表示される。決済完了画面Ｇ１２は、グループ支払いを実行したユーザ（店舗で二次元コードをかざしたユーザ）だけではなく、グループ支払いが行われたユーザグループに参加した他のユーザのユーザ端末１０にも表示される。他のユーザは、同じユーザグループに参加しているユーザによって、グループ支払いが行われたことを把握することができる。

以上のように、決済システムＳは、グループ支払いを実行することにより、例えば、複数のユーザが共同で１つの商品を購入するといった場合であっても、１人ずつ順番にユーザ端末１０を店舗端末２０にかざしたり、支払前又は支払後に集金したりするといったことが発生せず、ユーザの手間を軽減するようにしている。以降、この技術の詳細を説明する。

［３．決済システムにおいて実現される機能］
図７は、決済システムＳで実現される機能の一例を示す機能ブロック図である。ここでは、ユーザ端末１０、店舗端末２０、及びサーバ３０の各々で実現される機能を説明する。

［３－１．ユーザ端末において実現される機能］
ユーザ端末１０では、データ記憶部１００、出力制御部１０１、及び送信部１０２が実現される。データ記憶部１００は、記憶部１２を主として実現され、他の各機能は、制御部１１を主として実現される。

［データ記憶部］
データ記憶部１００は、ユーザ識別情報とユーザグループ識別情報との少なくとも一方を記憶する。データ記憶部１００は、ユーザ識別情報だけを記憶してもよいし、ユーザグループ識別情報だけを記憶してもよいし、これらの両方を記憶してもよい。

ユーザ識別情報は、ユーザを一意に識別する情報であり、例えば、ユーザＩＤ、ユーザアカウント、ユーザ名、又はメールアドレスといった情報である。本実施形態では、ユーザ識別情報の一例としてユーザＩＤを説明する。このため、本実施形態でユーザＩＤと記載した箇所はユーザ識別情報と読み替えることができる。例えば、ユーザＩＤは、電子決済サービスのアプリケーションをユーザ端末１０にインストールし、サーバ３０に対して所定の利用登録をすることで発行され、データ記憶部１００に記憶される。

ユーザグループ識別情報は、ユーザグループを一意に識別する情報であり、例えば、ユーザグループＩＤ又はユーザグループ名といった情報である。本実施形態では、ユーザグループ識別情報の一例としてユーザグループＩＤを説明する。このため、本実施形態でユーザグループＩＤと記載した箇所はユーザグループ識別情報と読み替えることができる。例えば、ユーザグループＩＤは、ユーザが、ユーザグループを新規作成したり、ユーザグループへの参加が完了したりした場合に、サーバ３０から通知されたものがデータ記憶部１００に記憶される。

［出力制御部］
出力制御部１０１は、所定の支払操作に基づいて、ユーザＩＤとユーザグループＩＤとの少なくとも一方を出力する。本実施形態では、出力制御部１０１は、ユーザＩＤとユーザグループＩＤとの両方を出力する場合を一例として説明するが、ユーザＩＤ又はユーザグループＩＤの何れか一方だけを出力してもよい。

なお、ユーザＩＤだけが出力される場合には、サーバ３０は、当該ユーザＩＤに関連付けられたユーザグループＩＤを特定することによって、グループ支払いの対象となるユーザグループを特定してもよい。この場合、ユーザが複数のユーザグループに参加すると、出力制御部１０１から出力されたユーザＩＤだけでは、グループ支払いの対象となるユーザグループを特定できないので、ユーザが参加するユーザグループを１つだけに制限してもよい。ユーザグループを１つだけに制限しない場合には、ユーザ端末１０からユーザＩＤが出力された後に、ユーザ端末１０において、ユーザグループの一覧を表示させ、その中の何れかを選択させるようにしてもよい。

出力とは、例えば、画像の表示、情報の送信、又は音声の出力である。本実施形態では、出力制御部１０１は、ユーザＩＤとユーザグループＩＤを示す画像を表示部１５に表示させることによって、ユーザＩＤとユーザグループＩＤを出力する場合を一例として説明するが、出力制御部１０１は、無線通信を利用してユーザＩＤとユーザグループＩＤを送信してもよいし、ユーザＩＤとユーザグループＩＤを示す音声を音声出力部から出力してもよい。なお、無線通信自体は、種々の通信プロトコルを利用可能であり、例えば、赤外線通信、Ｗｉ－Ｆｉ、又はＢｌｕｅｔｏｏｔｈ（登録商標）といった近距離無線通信であってもよい。

画像は、任意の画像であればよく、例えば、ユーザＩＤとユーザグループＩＤを含むコードであってもよいし、ユーザＩＤとユーザグループＩＤを示す数値や文字であってもよい。コードとしては、任意のコードを利用可能であり、例えば、バーコードであってもよいし、二次元コードであってもよい。本実施形態では、出力制御部は、データ記憶部１００に記憶されたユーザＩＤとユーザグループＩＤを含む二次元コードを表示部１５に表示させる。二次元コードの生成方法自体は、公知の種々の手法を適用可能である。

なお、支払操作は、予め定められた操作であればよく、本実施形態では、二次元コードを表示させるための操作である。グループ選択画面Ｇ１０のボタンＢ１００を選択する操作は、支払操作の一例である。支払操作は、ユーザグループに参加した全てのユーザが行うことができてもよいし、一部のユーザだけが行うことができてもよい。即ち、グループ支払いの支払い権限が与えられたユーザだけが支払操作をすることができてもよい。支払い権限は、ユーザグループの作成者だけが付与されてもよいし、他のユーザに付与されてもよい。どのユーザに支払い権限が付与されているかは、後述するグループデータベースに定義しておけばよい。

［送信部］
送信部１０２は、所定の登録操作に基づいて、ユーザ端末１０のユーザが属するユーザグループにバリューを登録するための登録要求を送信する。登録操作は、予め定められた操作であればよく、例えば、バリュー登録画面Ｇ６の入力フォームＦ６０に登録額を入力する操作であってもよいし、予め定められた複数の登録額の中から登録額を選択する操作であってもよい。

登録要求は、所定形式のデータで送信されるようにすればよく、例えば、登録操作をしたユーザのユーザＩＤ、バリューを登録するユーザグループのユーザグループＩＤ、及び登録額といった情報を含む。なお、送信部１０２は、任意の情報を送信可能であり、例えば、ユーザグループの新規作成の要求やユーザグループへの参加要求などを送信可能であってよい。

［３－２．店舗端末において実現される機能］
店舗端末２０では、データ記憶部２００、金額入力部２０１、情報取得部２０２、及び送信部２０３が実現される。データ記憶部２００は、記憶部２２を主として実現され、他の各機能は、制御部２１を主として実現される。

［データ記憶部］
データ記憶部２００は、店舗識別情報を記憶する。店舗識別情報は、店舗を一意に識別する情報であり、例えば、店舗ＩＤ、店舗アカウント、店舗名、又はメールアドレスといった情報である。本実施形態では、店舗識別情報の一例として店舗ＩＤを説明する。このため、本実施形態で店舗ＩＤと記載した箇所は店舗識別情報と読み替えることができる。例えば、店舗ＩＤは、電子決済サービスのアプリケーションを店舗端末２０にインストールし、サーバ３０に対して所定の利用登録をすることで発行され、データ記憶部２００に記憶される。

［金額入力部］
金額入力部２０１は、操作部２４の検出信号に基づいて、個別支払い又はグループ支払いにおける金額を入力する。金額は、店員が操作部２４から入力した数値である。なお、データ記憶部２００に、商品と金額との関係を示すデータベースを記憶しておき、読取部２６により読み取られた商品のコードに関連付けられた金額に基づいて、個別支払い又はグループ支払いにおける金額が計算されるようにしてもよい。

［情報取得部］
情報取得部２０２は、ユーザ端末１０により出力された情報を取得する。例えば、情報取得部２０２は、通信部２３、操作部２４、又は読取部２６の検出信号に基づいて情報を取得する。

例えば、出力制御部１０１により画像が表示される場合には、情報取得部２０２は、読取部２６により読み取られた画像を取得してもよい。また例えば、ユーザＩＤやユーザグループＩＤといった情報を視覚的に識別できる画像であれば、店員がこれらの情報を見たうえで、操作部２４から入力してもよい。この場合、情報取得部２０２は、操作部２４から入力された情報を取得することになる。

また例えば、出力制御部１０１により情報が送信される場合には、情報取得部２０２は、通信部２３を介して情報を取得する。また例えば、出力制御部１０１により音声が出力される場合には、情報取得部２０２は、音声検出部により検出した音声を取得する。また例えば、ユーザＩＤやユーザグループＩＤといった情報を聴覚的に識別できる音声であれば、店員がこれらの音声を聞いたうえで、操作部２４から入力してもよい。この場合、情報取得部２０２は、操作部２４から入力された情報を取得することになる。

本実施形態では、出力制御部１０１により二次元コードが表示されるので、情報取得部２０２は、読取部２６に読み取られた二次元コードを解析し、二次元コードに含まれるユーザＩＤとユーザグループＩＤを取得することになる。二次元コードの解析方法自体は、公知の種々の手法を適用すればよい。

［送信部］
送信部２０３は、サーバ３０に対し、情報取得部２０２により取得された情報を送信する。なお、送信部２０３は、情報取得部２０２により取得された情報以外の情報も送信してよく、例えば、金額入力部２０１により入力された金額と、データ記憶部２００に記憶された店舗ＩＤと、を送信してもよい。

［３－３．サーバにおいて実現される機能］
サーバ３０では、データ記憶部３００、特定部３０１、取得部３０２、決定部３０３、増加部３０４、確保部３０５、実行部３０６、及び減少部３０７が実現される。データ記憶部３００は、記憶部３２を主として実現され、他の各機能は、制御部３１を主として実現される。

［データ記憶部］
データ記憶部３００は、電子決済に必要なデータを記憶する。ここでは、データ記憶部３００が記憶するデータの一例として、ユーザデータベース、グループデータベース、及び店舗データベースを説明する。

図８は、ユーザデータベースの一例を示す図である。図８に示すように、ユーザデータベースＤＢ１は、ユーザに関する各種情報を格納するデータベースである。例えば、ユーザデータベースＤＢ１には、ユーザＩＤ、ユーザの名前、参加中のユーザグループのユーザグループＩＤ、及び決済情報などが格納される。

決済情報は、決済に必要な情報であり、例えば、複数の支払方法の中からユーザが選択した支払方法で決済するための情報が格納される。例えば、決済情報は、クレジットカード番号、デビットカード番号、引き落とし口座の番号、電子マネー情報、又はポイント情報などである。電子マネー情報は、決済に使用する電子マネーの種類を識別可能な情報であり、例えば、電子マネーの名称、電子マネー会社におけるユーザのＩＤ、及び残高といった情報を含んでもよい。ポイント情報は、決済に使用するポイントの種類を識別可能な情報であり、例えば、ポイントの名称、ポイント管理会社におけるユーザのＩＤ、及び保有ポイントといった情報を含んでもよい。

図９は、グループデータベースの一例を示す図である。図９に示すように、グループデータベースＤＢ２は、ユーザグループに関する各種情報を格納するデータベースである。例えば、グループデータベースＤＢ２には、ユーザグループＩＤ、ユーザグループの名前、作成者のユーザＩＤ、参加者のユーザＩＤ、及びバリューの登録額などが格納される。

バリューの登録額としては、ユーザグループ全体の登録額である全体登録額と、個々のユーザの登録額である個別登録額と、の少なくとも一方が格納される。本実施形態では、全体登録額と個別登録額との両方が格納される場合を説明するが、全体登録額だけが格納されてもよいし、個別登録額だけが格納されてもよい。個別登録額だけが格納される場合には、個別登録額の合計値を計算することで、全体登録額が取得されるようにすればよい。グループデータベースＤＢ２に格納された登録額は、ユーザグループの各ユーザによって仮想的に集められた（プールされた）バリューである。

本実施形態では、データ記憶部３００は、グループデータベースＤＢ２を記憶することによって、各ユーザグループのバリューを記憶することになる。ここでのバリューを記憶するとは、バリューを示す数値を記憶するという意味であり、バリューそのものがグループデータベースＤＢ２に記憶されているわけではない。なお、各ユーザグループのバリューは、グループデータベースＤＢ２以外のデータベースに記憶されてもよい。

図１０は、店舗データベースの一例を示す図である。図１０に示すように、店舗データベースＤＢ３は、店舗に関する各種情報を格納するためのデータベースである。例えば、店舗データベースＤＢ３には、店舗ＩＤ、店舗名、及び受取口座などが格納される。受取口座は、本実施形態における電子決済による支払いを振り込むための銀行口座である。例えば、個別支払い又はグループ支払いが実行されると、受取口座に金額が振り込まれる。

［特定部］
特定部３０１は、店舗端末２０により取得された情報に基づいて、ユーザグループを特定する。本実施形態では、店舗端末２０の情報取得部２０２により二次元コード内のユーザグループＩＤが取得され、送信部２０３によってユーザグループＩＤが送信されるので、特定部３０１は、当該送信されたユーザグループＩＤを取得する。特定部３０１は、グループデータベースＤＢ２とユーザグループＩＤとに基づいて、グループ支払いの対象となるユーザグループを特定する。

なお、１人のユーザに対し、１つのユーザグループだけが登録されている場合には、特定部３０１は、当該１つのユーザグループを特定する。一方、１人のユーザに対し、複数のユーザグループが登録されている場合には、特定部３０１は、複数のユーザグループのうちの何れかを特定する。特定部３０１が特定するユーザグループは、ユーザ端末１０のユーザが属するユーザグループであり、支払いの対象となるユーザグループということもできる。

［取得部］
取得部３０２は、特定部３０１により特定されたユーザグループ全体の支払額である全体支払額を取得する。本実施形態では、店舗端末２０の金額入力部２０１により金額が入力され、送信部２０３によって当該金額が送信されるので、取得部３０２は、当該金額を全体支払額として取得する。

［決定部］
決定部３０３は、全体支払額に基づいて、特定部３０１により特定されたユーザグループに属する複数のユーザの個々の支払額である個別支払額を決定する。決定部３０３は、予め定められた計算式に基づいて、全体支払額から個別支払額を計算すればよく、例えば、全体支払額をユーザの人数で割った数値（均等割りした数値）を個別支払額としてもよいし、ユーザによって重み付けをする（傾斜を付ける）ことによって個別支払額を計算してもよい。他にも例えば、個別支払額は、事後的に調整可能であってもよく、ユーザグループ内の任意のユーザによって変更されてよい。本実施形態では、全体支払額を均等割りした数値が個別支払額となり、各ユーザで同じ負担額となる場合を一例として説明する。即ち、ユーザグループ内で各ユーザが割り勘をする場合を一例として説明する。

［増加部］
増加部３０４は、登録要求を受信した場合に、当該登録要求をしたユーザが属するユーザグループのバリューを増加させる。本実施形態では、登録要求にユーザグループＩＤが含まれているので、増加部３０４は、当該ユーザグループＩＤを参照することで、バリューを増加させるユーザグループを特定する。増加部３０４は、グループデータベースＤＢ２のうち、当該特定したユーザグループの登録額を増加させることになる。増加部３０４による増加額は、固定値であってもよいが、本実施形態では、登録要求に増加額が含まれているので、増加部３０４は、当該増加額に基づいて登録額を増加させる。

［確保部］
確保部３０５は、登録要求を受信した場合に、当該登録要求により登録されるバリューに基づいて、当該登録要求をしたユーザのバリューを確保する。確保とは、将来的に確定する支払いに備えて、事前に必要金額分のバリューを他の用途の支払に利用されないようにすることである。

確保部３０５が実行する処理は、ユーザが選択した支払方法によって異なる。例えば、支払方法がクレジットカードであれば、確保部３０５は、登録額分のオーソリゼーションを実行して決済枠を確保する。別の言い方をすれば、確保部３０５は、登録額分だけデポジット状態とすることによって、決済枠を確保する。なお、クレジットカードにおけるオーソリゼーション又はデポジット自体は、公知の手法によって実行されるようにすればよい。

また例えば、支払方法が電子マネー又はポイントであれば、確保部３０５は、登録額分だけ電子マネー又はポイントを凍結させることによって、電子マネー又はポイントの使用分を確保する。また例えば、支払方法が口座引き落としなどの現金であれば、確保部３０５は、口座残高のうち登録額分を凍結させることによって、使用分の現金を確保する。電子マネー、ポイント、又は口座残高の凍結方法自体は、公知の手法によって実行されるようにすればよい。

なお、確保部３０５によりバリューが確保されたか否かに関係なくバリューの登録が実行されてもよいが、本実施形態では、確保部３０５によりバリューが確保できなかった場合には、バリューの登録が実行されないものとする。即ち、増加部３０４は、確保部３０５によりバリューが確保されなかった場合にはバリューを増加させず、確保部３０５によりバリューが確保された場合にバリューを増加させることになる。

［実行部］
実行部３０６は、ユーザごとに、当該ユーザの個別支払額に基づく決済をするための処理を実行する。後述する変形例（１）のように、実行部３０６が、自分で決済処理を実行してもよいが、本実施形態では、サーバ３０自身が決済処理を実行するのではなく、外部システムに対し、決済処理を依頼するものとする。即ち、外部システムに決済処理を依頼する処理が、実行部３０６が実行する処理の一例である場合を説明する。

グループ支払いでは、ユーザグループ全体で１つの決済処理が実行されるのではなく、あくまで、ユーザグループに参加した個々のユーザごとに、決済処理が実行されることになる。このため、実行部３０６は、ユーザグループに参加したユーザごとに決済の振分けを実行することになる。

本実施形態では、ユーザによって支払方法が異なる可能性があるので、実行部３０６は、ユーザが選択した支払方法に基づいて、決済処理を依頼する外部システムを決定する。支払方法と外部システムとの関係を示すデータは、予めデータ記憶部３００に記憶させておけばよい。このデータには、支払方法ごとに、外部システムのＩＰアドレスなどの情報が格納されているものとする。

例えば、支払方法がクレジットカードであれば、実行部３０６は、クレジッドカード会社のシステムに対し、決済処理の実行を依頼する。クレジットカード会社のシステムにおける決済処理自体は、公知の処理を適用可能である。また例えば、支払方法が電子マネー又はポイントであれば、実行部３０６は、電子マネー又はポイントの管理会社のシステムに対し、決済処理の実行を依頼する。電子マネー又はポイントの管理会社のシステムにおける決済処理自体は、公知の処理を適用可能である。また例えば、支払方法が口座引き落としなどの現金である場合には、実行部３０６は、銀行のシステムに対し、決済処理の実行を依頼する。銀行のシステムにおける決済処理自体は、公知の処理を適用可能である。

本実施形態では、確保部３０５によってバリューが予め確保されているので、実行部３０６は、確保されたバリューを消費するように、外部システムに決済処理を依頼することになる。例えば、支払方法がクレジットカードであれば、実行部３０６は、確保された決済枠を使用する旨の要求を、クレジットカード会社のシステムに送信する。また例えば、支払方法が電子マネー又はポイントであれば、実行部３０６は、凍結された分の電子マネー又はポイントを消費する旨の要求を、電子マネー又はポイントの管理会社のシステムに送信する。また例えば、支払方法が口座引き落としなどの現金である場合には、実行部３０６は、凍結された分の現金を引き落とす旨の要求を、銀行のシステムに送信する。

なお、実行部３０６は、グループデータベースＤＢ２に格納されたユーザグループの登録額と全体支払額とに基づいて、処理を実行するか否かを決定してもよい。例えば、実行部３０６は、ユーザグループの登録額が全体支払額未満である場合は処理を実行せず、ユーザグループの登録額が全体支払額以上である場合に処理を実行してもよい。

また例えば、実行部３０６は、ユーザごとに、当該ユーザにより登録されたバリューが当該ユーザの個別支払額に足りているか否かを判定し、当該判定結果に基づいて処理を実行してもよい。実行部３０６は、グループデータベースＤＢ２に格納された各ユーザの登録額と、当該ユーザの個別支払額と、に基づいて、処理を実行するか否かを決定する。例えば、実行部３０６は、ユーザの登録額が個別支払額未満である場合は処理を実行せず、ユーザの登録額が個別支払額以上である場合は処理を実行してもよい。

また例えば、実行部３０６は、ユーザごとに、複数の支払方法の中から当該ユーザにより選択された支払方法で個別支払額に基づく決済をするための処理を実行してもよい。実行部３０６は、ユーザデータベースＤＢ１に基づいて各ユーザの支払方法を特定し、当該特定した支払方法に基づいて処理を実行すればよい。支払方法に応じた処理内容は先述した通りである。なお、特に複数の支払方法が用意されておらず、支払方法は１つだけであってもよい。

［減少部］
減少部３０７は、実行部３０６により処理が実行された場合に、全体支払額に基づいて、特定部３０１により特定されたユーザグループのバリューを減少させる。本実施形態では、登録要求にユーザグループＩＤが含まれているので、減少部３０７は、当該ユーザグループＩＤを参照することで、バリューを減少させるユーザグループを特定する。減少部３０７は、グループデータベースＤＢ２のうち、当該特定したユーザグループの登録額を全体支払額だけ減少させ、各ユーザの登録額を個別支払額だけ減少させることになる。

［４．本実施形態において実行される処理］
図１１－図１６は、決済システムにおいて実行される処理の一例を示すフロー図である。図１１－図１６に示す処理は、制御部１１，２１，３１が、それぞれ記憶部１２，２２，３２に記憶されたプログラムに従って動作することによって実行される。下記に説明する処理は、図７に示す機能ブロックにより実行される処理の一例である。

図１１に示すように、まず、ユーザ端末１０において、制御部１１は、記憶部１２に記憶されたアプリケーションを起動し、トップ画面Ｇ１を表示部１５に表示させる（Ｓ１）。なお、アプリケーションが起動した場合に、サーバ３０へのログイン処理が実行され、サーバ３０は、どのユーザがアクセスしているか特定可能になっているものとする。以降の説明では、ユーザ端末１０からサーバ３０に対して何らかの情報が送信される場合には、ユーザＩＤも送信されるものとする。

制御部１１は、操作部１４の検出信号に基づいて、ユーザの操作を特定する（Ｓ２）。ユーザがボタンＢ１０を選択した場合（Ｓ２；Ｂ１０）、制御部１１は、個人支払いのための処理を実行し（Ｓ３）、本処理は終了する。Ｓ３においては、例えば、制御部１１は、記憶部１２に記憶されたユーザＩＤを含む二次元コードを表示部１５に表示させ、店舗端末２０の読取部２６で当該二次元コードを読み取ることによって、個人支払いが実行される。なお、二次元コードには、個人支払いであるかグループ支払いであるかを識別する情報が含まれていてもよい。店舗端末２０は、当該情報に基づいて、自身が実行する処理を変えてもよい。

一方、ユーザがボタンＢ１１を選択した場合（Ｓ２；Ｂ１１）、制御部１１は、メニュー画面Ｇ８を表示部１５に表示させ（Ｓ４）、操作部１４の検出信号に基づいて、ユーザの操作を特定する（Ｓ５）。ユーザがボタンＢ８０を選択した場合（Ｓ５；Ｂ８０）、制御部１１は、サーバ３０に対し、ユーザが参加しているユーザグループの取得要求を送信する（Ｓ６）。

サーバ３０においては、ユーザグループの取得要求を受信すると、制御部３１は、ユーザデータベースＤＢ１に基づいて、ユーザが参加しているユーザグループを特定する（Ｓ７）。Ｓ７においては、制御部３１は、ユーザデータベースＤＢ１のうち、取得要求とともに受信したユーザＩＤが格納されたレコードのユーザグループＩＤを取得する。なお、制御部３１は、ユーザデータベースＤＢ１ではなく、グループデータベースＤＢ２に基づいて、ユーザが参加しているユーザグループを特定してもよい。この場合、制御部３１は、グループデータベースＤＢ２のうち、取得要求とともに受信したユーザＩＤが格納されたレコードのユーザグループＩＤを取得する。

制御部３１は、グループデータベースＤＢ２に基づいて、ユーザ端末１０に対し、Ｓ７において特定したユーザグループに関する情報を送信する（Ｓ８）。Ｓ８においては、制御部３１は、ユーザグループＩＤ、ユーザグループの名前、及び登録額といった情報を送信する。

ユーザ端末１０においては、ユーザグループに関する情報を受信すると、制御部１１は、当該情報に基づいて、グループ選択画面Ｇ９を表示部１５に表示させる（Ｓ９）。Ｓ９においては、制御部１１は、サーバ３０から受信した情報に基づいて、ユーザが参加しているユーザグループを特定し、各ユーザグループに対応するボタンＢ９０を表示させる。

制御部１１は、操作部１４の検出信号に基づいて、バリューを登録するユーザグループを特定する（Ｓ１０）。Ｓ１０においては、制御部１１は、ユーザが選択したボタンＢ９０に基づいて、ユーザグループを特定する。

図１２に移り、制御部１１は、Ｓ１０において特定したユーザグループにバリューを登録するためのバリュー登録画面Ｇ６を表示部１５に表示させる（Ｓ１１）。制御部１１は、操作部１４の検出信号に基づいて登録操作を検出すると、サーバ３０に対し、バリューの登録要求を送信する（Ｓ１２）。登録要求には、ユーザのユーザＩＤ、バリューを登録するユーザグループのユーザグループＩＤ、及び入力フォームＦ６０に入力された登録額が含まれているものとする。

サーバ３０においては、バリューの登録要求を受信すると、制御部３１は、登録されたバリューに基づいて、ユーザのバリューを確保する（Ｓ１３）。Ｓ１３においては、制御部３１は、ユーザデータベースＤＢ１に基づいてユーザの支払方法を特定し、当該支払方法に応じてユーザのバリューを確保する。支払方法に応じたバリューの確保方法は先述した通りである。

制御部３１は、Ｓ１３におけるバリューの確保が成功したか否かを判定する（Ｓ１４）。バリューの確保が失敗したと判定された場合（Ｓ１４；Ｎ）、本処理は終了する。この場合、バリューの登録が行われず、所定のエラーメッセージが表示部１５に表示される。この場合、エラーメッセージの中に、バリューの登録が失敗した理由を示す情報が含まれていてもよい。

一方、バリューの確保が成功したと判定された場合（Ｓ１４；Ｙ）、制御部３１は、グループデータベースＤＢ２を更新し、ユーザグループの登録額を増加させる（Ｓ１５）。Ｓ１５においては、制御部３１は、グループデータベースＤＢ２のうち、登録要求に含まれるユーザグループＩＤが格納されたレコードのユーザグループの登録額と、ユーザの登録額と、を増加させる。制御部３１は、ユーザ端末１０に対し、バリューの登録が成功した旨の通知を送信する（Ｓ１６）。

ユーザ端末１０においては、通知を受信すると、制御部１１は、登録完了画面Ｇ７を表示部１５に表示させ（Ｓ１７）、本処理は終了する。なお、トップ画面Ｇ１に戻る操作が行われた場合には、Ｓ１の処理に戻り、メニュー画面Ｇ８に戻る操作が行われた場合には、Ｓ４の処理に戻るものとする。

一方、図１１のＳ５において、ユーザがボタンＢ８１を選択した場合（Ｓ５；Ｂ８１）、図１３に移り、制御部１１は、サーバ３０に対し、ユーザが参加しているユーザグループの取得要求を送信する（Ｓ１８）。Ｓ１８の処理は、Ｓ６の処理と同様であり、続くＳ１９－Ｓ２０の処理は、それぞれＳ７－Ｓ８の処理と同様である。

制御部１１は、受信したユーザグループに関する情報に基づいて、グループ選択画面Ｇ１０を表示部１５に表示させる（Ｓ２１）。Ｓ２１においては、制御部１１は、サーバ３０から受信した情報に基づいて、ユーザが参加しているユーザグループを特定し、各ユーザグループに対応するボタンＢ１００を表示させる。

制御部１１は、操作部１４の検出信号に基づいて、グループ支払いをするユーザグループを特定する（Ｓ２２）。Ｓ２２においては、制御部１１は、ユーザが選択したボタンＢ１００に基づいて、ユーザグループを特定する。

制御部１１は、ユーザＩＤと、Ｓ２２で特定したユーザグループのユーザグループＩＤと、を含む二次元コードを含むコード表示画面Ｇ１１を表示部１５に表示させる（Ｓ２３）。以降、ユーザは、店舗の店員にグループ支払いをする旨を伝えて、店舗端末２０に二次元コードをかざす。

店舗端末２０においては、制御部２１は、操作部２４の検出信号に基づいて、全体支払額を表示部２５に表示させる（Ｓ２４）。Ｓ２４においては、制御部２１は、店舗の店員が入力した金額を表示部２５に表示させることになる。なお、商品のバーコードを読取部２６で読み取ることによって金額が表示されてもよい。また、ユーザが複数の商品をグループ支払いで購入する場合には、これら複数の商品の合計金額が表示されるようにしてよい。

制御部２１は、読取部２６で読み取った二次元コードを解析し、二次元コードに含まれるユーザＩＤとユーザグループＩＤを取得する（Ｓ２５）。制御部２１は、サーバ３０に対し、グループ支払いの実行要求を送信する（Ｓ２６）。グループ支払いの実行要求には、店舗端末２０の記憶部２２に記憶された店舗ＩＤ、Ｓ２４で入力された全体支払額、及びＳ２５で取得されたユーザＩＤ・ユーザグループＩＤが含まれる。

図１４に移り、サーバ３０においては、グループ支払いの実行要求を受信すると、制御部３１は、グループデータベースＤＢ２に基づいて、登録額が全体支払額以上であるか否かを判定する（Ｓ２７）。Ｓ２７においては、制御部３１は、グループデータベースＤＢ２のうち、実行要求に含まれるユーザグループＩＤが格納されたレコードの登録額を取得する。制御部３１は、当該登録額が、実行要求に含まれる全体支払額以上であるか否かを判定する。

登録額が全体支払額未満であると判定された場合（Ｓ２７；Ｎ）、本処理は終了する。この場合、グループ支払いは実行されず、所定のエラーメッセージが表示部１５に表示される。この場合、エラーメッセージの中に、グループ支払いが失敗した理由を示す情報が含まれていてもよい。更に、エラーメッセージは、支払操作をしたユーザ以外のユーザのユーザ端末１０に表示させてもよい。

一方、登録額が全体支払額以上であると判定された場合（Ｓ２７；Ｙ）、制御部３１は、グループデータベースＤＢ２に基づいて、支払い対象のユーザグループに参加している各ユーザの個別支払額を決定する（Ｓ２８）。Ｓ２８においては、制御部３１は、グループデータベースＤＢ２のうち、実行要求に含まれるユーザグループＩＤが格納されたレコードのユーザＩＤに基づいて、ユーザの人数を取得する。制御部３１は、全体支払額をユーザの人数で均等割りした額を個別支払額として決定する。

制御部３１は、グループデータベースＤＢ２に基づいて、各ユーザの登録額が個別支払額以上であるか否かを判定する（Ｓ２９）。Ｓ２９においては、制御部３１は、グループデータベースＤＢ２のうち、実行要求に含まれるユーザグループＩＤが格納されたレコードの各ユーザの登録額を取得する。制御部３１は、ユーザごとに、当該ユーザの登録額が、Ｓ２８で決定した個別支払額以上であるか否かを判定する。

各ユーザの登録額が個別支払額以上であると判定されない場合（Ｓ２９；Ｎ）、本処理は終了する。この場合、グループ支払いは実行されず、所定のエラーメッセージが表示部１５に表示される。この場合、エラーメッセージの中に、グループ支払いが失敗した理由を示す情報が含まれていてもよい。更に、エラーメッセージは、支払操作をしたユーザ以外のユーザのユーザ端末１０に表示させてもよい。

一方、各ユーザの登録額が個別支払額以上であると判定された場合（Ｓ２９；Ｙ）、制御部３１は、ユーザデータベースＤＢ１と店舗データベースＤＢ３とに基づいて、各ユーザの個別支払額に基づく決済をするための処理を実行する（Ｓ３０）。Ｓ３０においては、制御部３１は、店舗データベースＤＢ３のうち、グループ支払いの実行要求に含まれる店舗ＩＤが格納されたレコードの情報を取得する。そして、制御部３１は、ユーザデータベースＤＢ１に基づいてユーザの支払方法を特定し、当該支払方法に応じてユーザの個別支払額に基づく決済をするための処理を実行する。支払方法に応じた当該処理の内容は先述した通りである。外部システムから決済処理が完了した旨の通知が受信されると、制御部３１は、グループデータベースＤＢ２のうち、実行要求に含まれるユーザグループＩＤが格納されたレコードのユーザグループの登録額と、ユーザの登録額と、を減少させる。

制御部３１は、グループ支払いが実行された各ユーザのユーザ端末１０に対し、グループ支払いの実行結果を送信する（Ｓ３１）。ユーザ端末１０においては、グループ支払いの実行結果を受信すると、制御部１１は、決済完了画面Ｇ１２を表示部１５に表示させ（Ｓ３２）、本処理は終了する。なお、トップ画面Ｇ１に戻る操作が行われた場合には、Ｓ１の処理に戻り、メニュー画面Ｇ８に戻る操作が行われた場合には、Ｓ４の処理に戻るものとする。

一方、図１１のＳ２において、ユーザがボタンＢ１２を選択した場合（Ｓ２；Ｂ１２）、図１５に移り、制御部１１は、新規作成画面Ｇ２を表示部１５に表示させる（Ｓ３３）。制御部１１は、操作部１４の検出信号に基づいて、サーバ３０に対し、ユーザグループの作成要求を送信する（Ｓ３４）。作成要求には、ユーザＩＤ、入力フォームＦ２０に入力されたユーザグループの名前、及び入力フォームＦ２１に入力されたユーザ情報が含まれるものとする。

サーバ３０においては、ユーザグループの作成要求を受信すると、制御部３１は、グループデータベースＤＢ２に新たなユーザグループを作成する（Ｓ３５）。Ｓ３５においては、制御部３１は、所定のＩＤ発行ルールに基づいて、ユーザグループＩＤを発行する。そして、制御部３１は、グループデータベースＤＢ２に新たなレコードを作成し、発行したユーザグループＩＤ等を格納する。

制御部３１は、ユーザグループの作成要求に含まれるユーザ情報に基づいて、招待されたユーザのユーザ端末１０に対し、招待通知を送信する（Ｓ３６）。Ｓ３６においては、制御部３１は、アプリケーションをインストール済みのユーザについては、招待通知に関する情報をユーザデータベースＤＢ１に登録し、アプリケーションをインストールしていないユーザについては、電子メール等を送信する。制御部３１は、ユーザ端末１０に対し、ユーザグループの作成結果を送信する（Ｓ３７）。

ユーザ端末１０においては、作成結果を受信すると、制御部１１は、作成完了画面Ｇ３を表示部１５に表示させ（Ｓ３８）、本処理は終了する。なお、トップ画面Ｇ１に戻る操作が行われた場合には、Ｓ１の処理に戻るものとする。

一方、図１１のＳ２において、ユーザがボタンＢ１３を選択した場合（Ｓ２；Ｂ１３）、図１６に移り、制御部１１は、ユーザが受信した各種通知を表示部１５に表示させる（Ｓ３９）。ユーザが招待通知を受信していた場合には、Ｓ３９においては、受信した招待通知が選択可能に表示されるものとする。制御部１１は、ユーザが選択した招待通知に基づいて、招待通知画面Ｇ４を表示部１５に表示させる（Ｓ４０）。制御部１１は、操作部１４の検出信号に基づいて、ユーザの操作を特定する（Ｓ４１）。

ユーザがボタンＢ４１を選択した場合（Ｓ４１；Ｂ４１）、ユーザグループへの参加は行われることなく、本処理は終了する。なお、トップ画面Ｇ１に戻る操作が行われた場合には、Ｓ１の処理に戻るものとする。

一方、ユーザがボタンＢ４０を選択した場合（Ｓ４１；Ｂ４０）、制御部１１は、サーバ３０に対し、ユーザグループへの参加要求を送信する（Ｓ４２）。参加要求には、ユーザＩＤと、招待通知に含まれるユーザグループＩＤと、が含まれるものとする。

サーバ３０においては、参加要求を受信すると、制御部３１は、参加要求をしたユーザをユーザグループに追加する（Ｓ４３）。Ｓ４３においては、制御部３１は、グループデータベースＤＢ２のうち、参加要求に含まれるユーザグループＩＤが格納されたレコードに、参加要求に含まれるユーザＩＤを追加する。制御部３１は、ユーザグループへの参加完了通知を送信する（Ｓ４４）。

ユーザ端末１０においては、参加完了通知を受信すると、制御部１１は、参加完了画面Ｇ５を表示部１５に表示させ（Ｓ４５）、本処理は終了する。なお、ボタンＢ５０が選択された場合には、Ｓ１１の処理に移行し、ボタンＢ５１が選択された場合には、Ｓ１の処理に戻るものとする。

以上説明した決済システムＳによれば、グループ支払いを実行することにより、例えば、複数のユーザが共同で１つの商品を購入するといった場合であっても、１人ずつ順番にユーザ端末１０を店舗端末２０にかざしたり、支払前又は支払後に集金したりするといったことが発生せず、ユーザの手間を軽減することができる。また、ユーザグループに参加した各ユーザによる支払操作を可能とする場合には、ユーザが手分けをして買い物をする場合の手間を効果的に軽減することができる。また、ユーザ１人のクレジットカードの可能額（例えば、２０万円）では足りない商品を購入するといった場合であっても、個々のユーザがバリューを登録して各自の可能額を合わせる（例えば、４人分で８０万円とする）といった柔軟な支払いを可能とすることができる。

また、ユーザグループに参加した各ユーザが、ユーザグループに対してバリューを登録することで、ユーザグループが利用可能なバリューに上限を設けることができる。このため、あるユーザが勝手にグループ支払いをしたことにより、他のユーザに多額の請求が発生するといったことを防止できる。

また、各ユーザがユーザグループに登録するバリューを予め確保することによって、実際には使用できない額以上のバリューがユーザグループに登録されてしまい、実際の支払時に決済不能になってしまうことを防止できる。

また、ユーザごとに、ユーザにより登録されたバリューが当該ユーザの個別支払額に足りているか否かを判定し、当該判定結果に基づいてグループ支払いが実行されることによって、登録額が足りないユーザがいるにも関わらずグループ支払いが実行されてしまうことを防止できる。

また、ユーザごとに、複数の支払方法の中からユーザにより選択された支払方法でグループ支払いが実行されることによって、ユーザの利便性を高めることができる。また、互いに異なる支払方法を利用するユーザ同士で、ユーザグループに共通のバリューを登録してグループ支払いをするといったこともでき、ユーザの利便性を高めることができる。

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

図１７は、変形例の機能ブロック図である。図１７に示すように、以降説明する変形例では、実施形態で説明した各機能の他に、サーバ３０において送信部３０８が実現される。

（１）例えば、実施形態では、実行部３０６が自身で決済処理をするのではなく、外部システム（例えば、クレジットカード会社、電子マネー会社、ポイント発行会社、又は銀行のシステム）に対し、決済処理の実行を依頼する態様を説明したが、決済システムＳ自身が決済機能を有する場合には、実行部３０６が、実行部３０６は、ユーザごとに、当該ユーザの個別支払額に基づく決済処理を実行してもよい。この場合、サーバ３０は、例えば、クレジット決済機能、電子マネー決済機能、ポイント決済機能、及び銀行引き落とし機能の少なくとも１つを含んでいればよい。実行部３０６は、サーバ３０が有する当該機能に基づいて、自身で決済処理を実行する。

変形例（１）によれば、決済システムＳ内で決済処理まで完了することによって、外部システムに対して決済要求を送信して決済完了を受信する手間を省くことで、グループ支払いの処理を高速化することができる。

（２）また例えば、ユーザがグループ支払いをする場合に、承認者に対し、グループ支払いの承認を得るようにしてもよい。

承認者は、支払操作をするユーザ以外の者であり、例えば、同じユーザグループに参加した他のユーザであってもよいし、ユーザグループには参加していない者であってもよい。

同じユーザグループに参加した他のユーザが承認者になる場合には、他のユーザ全員が承認者になってもよいし、一部の他のユーザだけが承認者になってもよい。一部の他のユーザが承認者になる場合には、ユーザグループの代表者が承認者になってもよいし、グループ支払いをしたユーザが指定した他のユーザが承認者になってもよい。他にも例えば、ランダムに選出された他のユーザが承認者になってもよいし、ユーザグループの作成者が承認者になってもよい。

一方、ユーザグループには参加していない者が承認者になる場合には、承認者は、グループ支払いの権限を有する者であり、例えば、ユーザの保護者であってもよいし、ユーザの上司又は経理担当者であってもよい。

変形例（２）の決済システムＳは、送信部３０８を含む。例えば、送信部３０８は、制御部３１を主として実現される。送信部３０８は、承認者に対し、所定の承認要求を送信する。

承認要求は、所定形式のデータにより行われ、例えば、支払操作をしたユーザの名前、全体支払額、及び個別支払金額といった情報を含んでもよい。即ち、送信部３０８は、支払操作をしたユーザ、全体支払額、及び個別支払額の少なくとも１つを示す情報とともに承認要求を送信してもよい。なお、承認要求は、店舗の名前などの他の情報を含んでもよいし、特にこれらの情報は含まれなくてもよい。

ここでは、承認者が、同じユーザグループに参加した他の全てのユーザである場合を一例として説明する。送信部３０８は、特定部３０１により特定されたユーザグループに属する各ユーザのユーザ端末１０に対し、承認要求を送信する場合を説明する。各ユーザのユーザ端末１０は、承認要求を受信した場合に、当該ユーザによる承認操作を受け付ける。例えば、ユーザ端末１０においては、承認要求を受信すると、承認操作を行うための承認画面が表示部１５に表示される。

図１８は、承認画面の一例を示す図である。図１８に示すように、承認画面Ｇ１３には、例えば、支払操作をしたユーザの名前、店舗の名前、全体支払額、及び個別支払金額といった情報が表示される。各ユーザのユーザ端末１０は、支払操作をしたユーザ、全体支払額、及び個別支払額の少なくとも１つを表示した後に、承認操作を受け付ける。

承認操作は、予め定められた操作であればよく、ここでは、ボタンＢ１３０を選択する操作を例に挙げて説明する。例えば、ユーザがボタンＢ１３０を選択すると、グループ支払いを承認することができる。一方、ユーザがボタンＢ１３１を選択すると、グループ支払いを拒否することができる。

例えば、ユーザがボタンＢ１３０を選択すると、ユーザ端末１０は、グループ支払いを承認するための承認通知をサーバ３０に送信する。一方、ユーザがボタンＢ１３１を選択すると、ユーザ端末１０は、グループ支払いを拒否するための拒否通知をサーバ３０に送信する。承認通知及び拒否通知は、所定形式のデータにより行われ、例えば、ユーザＩＤやユーザグループＩＤといった情報を含んでもよい。

本変形例の実行部３０６は、承認者による承認操作に基づいて、処理を実行する。ここでは、承認者が、同じユーザグループに参加した他の全てのユーザである場合を一例として説明するので、実行部３０６は、各ユーザによる承認操作に基づいて、処理を実行する。例えば、実行部３０６は、グループ支払いの対象となったユーザグループに参加する各ユーザ（支払操作をしたユーザを除く）から承認通知又は拒否通知を受信したか否かを判定する。

例えば、実行部３０６は、支払操作をしたユーザを除く全てのユーザから承認通知を受信した場合に、各ユーザの個別支払額に基づく決済をするための処理を実行してもよい。この場合、実行部３０６は、１人でも支払操作を拒否したユーザがいた場合には処理を実行しなくてもよい。

また例えば、実行部３０６は、特定部３０１により特定されたユーザグループに属する一部のユーザによる承認操作に基づいて、処理を実行してもよい。例えば、実行部３０６は、所定数以上のユーザから承認通知を受信した場合に、当該処理を実行してもよい。所定数は、ユーザグループの人数に関係なく固定値としてもよいし、ユーザグループの参加人数に応じた値（例えば、参加人数に所定割合を乗じた値）としてもよい。

また例えば、グループ支払いを承認したユーザと、グループ支払いを拒否したユーザと、が混在していた場合にグループ支払いを実行するか否かを事前に定めておいてもよい。また例えば、この場合にグループ支払いを実行するか否かをその場で決定してもよい。また例えば、承認操作に期限を設けてもよい。この場合、期限内に承認操作が行われなかった場合には、グループ支払いが拒否されたものとみなされてもよい。また例えば、期限内に承認操作が行われなかった場合には、グループ支払いに承認したものとみなしてグループ支払いを実行し、事後的に承認操作を求めるようにしてもよい。この場合、事後的な承認操作には、期限が設けられてもよい。更に、グループ支払いを承認したユーザだけで決済処理が実行され、事後的に承認したユーザの負担分が後で還元されるようにしてもよい。

なお、承認者が、同じユーザグループに参加した一部の他のユーザである場合には、送信部３０８は、当該一部の他のユーザのユーザ端末１０に対して承認要求を送信すればよく、実行部３０６は、一部の他のユーザによる承認操作に基づいて、処理を実行すればよい。また、承認者が、ユーザグループには参加していない者である場合には、送信部３０８は、ユーザグループに参加していない承認者に対して承認要求を送信し、実行部３０６は、当該承認者による承認操作に基づいて、処理を実行すればよい。なお、承認者は、決済システムＳに登録していない者（ユーザＩＤが発行されていない者）であってもよく、この場合には、支払操作をするユーザが、承認者のメールアドレス、ＳＮＳアカウント、又はメッセージアプリのアカウント等の連絡手段を入力するようにしてもよい。この場合、承認者の端末は、承認画面Ｇ１３と同様の画面が表示され、支払操作をしたユーザ、全体支払額、及び個別支払額の少なくとも１つを表示した後に、承認操作を受け付けてもよい。

変形例（２）によれば、承認者に、グループ支払いの承認を求めることによって、不本意なグループ支払いが実行されてしまうことを防止できる。

また、承認者がグループ支払いを承認する際には、支払操作をしたユーザ、全体支払額、又は個別支払額といった情報が表示されるので、承認操作をしてよいか否かの判断がつきやすくなる。

また、ユーザグループに属する一部のユーザによる承認操作に基づいてグループ支払いが実行されることで、例えば、誰か１人が取り込み中のためにグループ支払いができないといったことを防止できる。

（３）また例えば、変形例（２）において、一部のユーザによる承認操作に基づいてグループ支払いが行われる場合に、決定部３０３は、一部のユーザによる承認操作に基づいて、当該一部のユーザの個別支払額を再計算してもよい。

個別支払額の計算方法自体は、実施形態で説明した通りであるが、ここでは、ユーザグループの全員が対象になるのではなく、承認操作をしたユーザと支払操作をしたユーザだけが対象になる点で異なる。このため、決定部３０３は、全体支払額と、承認操作をしたユーザと支払操作をしたユーザの人数と、に基づいて、個別支払額を再計算することになる。再計算の際にも、均等割りにしてもよいし、ユーザによって重み付けをしてもよい。

実行部３０６は、一部のユーザごとに、再計算された当該ユーザの個別支払額に基づく処理を実行することになる。なお、後述する変形例（４）のように、再度の承認操作が行われてもよいし、特に再度の承認操作が行われることなく、グループ支払いが実行されてもよい。再計算された個別支払額が用いられる点以外は、実行部３０６の処理は、実施形態と同様である。

変形例（３）によれば、ユーザグループに属する一部のユーザによる承認操作に基づいてグループ支払いが実行される場合に、個別支払額を再計算することで、承認したユーザだけで、適正な支払額でグループ支払いを実行することができる。

（４）また例えば、変形例（３）において、個別支払額が再計算された場合に、送信部は、一部のユーザのユーザ端末１０に対し、再計算された当該ユーザの個別支払額を示す情報とともに、再承認要求を送信してもよい。

再承認要求は、所定形式のデータにより行われ、例えば、支払操作をしたユーザの名前、全体支払額、及び個別支払金額といった情報を含んでもよい。即ち、送信部３０８は、支払操作をしたユーザ、全体支払額、及び個別支払額の少なくとも１つを示す情報とともに再承認要求を送信してもよい。なお、再承認要求は、店舗の名前などの他の情報を含んでもよいし、特にこれらの情報は含まれなくてもよい。

一部のユーザのユーザ端末１０は、再承認要求を受信した場合に、当該ユーザによる再承認操作を受け付ける。再承認操作は、承認画面Ｇ１３と同様の画面で受け付けられてもよいし、レイアウトやメッセージなどを異ならせてもよい。再承認操作は、予め定められた操作であればよい。

実行部３０６は、一部のユーザによる再承認操作に基づいて、処理を実行する。実行部３０６は、当該一部のユーザの全てにより再承認通知を受信した場合に処理を実行してもよいし、一部のユーザにより再承認通知を受信した場合に処理を実行してもよい点は、変形例（２）と同様である。一部のユーザしか再承認しなかった場合には、再び、変形例（３）の処理が実行されて個別支払額が再計算されてもよいし、グループ支払いが承認されなかったものとしてグループ支払いを実行しないようにしてもよい。

変形例（４）によれば、ユーザグループに属する一部のユーザによる承認操作に基づいてグループ支払いが実行される場合に、再計算された個別支払額を確認させたうえで再承認操作をさせ、不本意な額でグループ支払いが実行されるといったことを防止できる。

（５）また例えば、実施形態では、ユーザ端末１０において二次元コードが表示され、店舗端末２０において二次元コードが読み取られる場合を説明したが、店舗端末２０において二次元コードが表示され、ユーザ端末１０で二次元コードが読み取られることで、グループ支払いが実行されてもよい。なお、本変形例では、ユーザ端末１０は、読取部２６と同様の読取部を備えるものとする。

例えば、店舗端末２０は、記憶部２２に記憶された店舗ＩＤと、操作部２４から入力された全体支払額と、を含む二次元コードを生成し、表示部２５に表示させる。ユーザ端末１０の読取部は、当該二次元コードを読み取り、店舗ＩＤと全体支払額とを取得する。なお、全体支払額は、ユーザ端末１０の操作部１４から入力されてもよい。

ユーザ端末１０は、取得した店舗ＩＤと全体支払額に基づいて、サーバ３０に対し、グループ支払いの実行要求を送信する。グループ支払いの実行要求自体は、実施形態で説明した通りである。即ち、実施形態のＳ２６において店舗端末２０が送信する実行要求が、本変形例では、ユーザ端末１０により送信される。

なお、個別支払い又はグループ支払いの何れかを実行するかは、予め選択されていてもよいし、二次元コードが読み取られた後に選択されてもよい。個別支払いが選択された場合には、ユーザ端末１０は、二次元コードを読み取ることで取得した店舗ＩＤと支払額とに基づいて、サーバ３０に対し、個別支払いの実行要求を送信する。個別支払いの実行要求自体は、実施形態で説明した通りである。即ち、実施形態のＳ３において店舗端末２０が送信する実行要求が、本変形例では、ユーザ端末１０により送信される。

以上のように、ユーザ端末１０ではなく、店舗端末２０において二次元コードが表示され、一連のグループ支払いが実行されることによって、ユーザの手間を軽減してもよい。更に、実施形態のように、ユーザ端末１０で二次元コードを表示させる支払方法とするか、本変形例のように店舗端末２０において、二次元コードを表示させる支払方法とするか、をユーザ又は店舗の担当者が選択できるようにしてもよい。

（６）また例えば、上記変形例の２つ以上を組み合わせてもよい。

また例えば、実施形態では、トップ画面Ｇ１において支払方法が選択された後に、コード表示画面Ｇ１１において二次元コードが表示されて決済が実行される場合を説明したが、支払方法が選択されるタイミングは、任意のタイミングであってよく、二次元コードを表示させた後に、ユーザが支払方法を選択して決済が実行されてもよい。

また例えば、実施形態では、新規作成画面Ｇ２からユーザグループが作成される場合を説明したが、ＳＮＳやメッセージアプリ等において予め作成されたユーザグループ（友達グループ）を、グループ支払いのユーザグループに適用してもよい。例えば、ＳＮＳやメッセージアプリ等におけるユーザグループに基づいて、決済システムＳ内にユーザグループを新規作成してもよい。この場合、当該新規作成されたユーザグループに属するユーザは、ＳＮＳやメッセージアプリ等におけるユーザグループに属するユーザと全く同じであってもよいし、一部のユーザが異なっていてもよい。

他にも例えば、ＳＮＳやメッセージアプリ等におけるユーザグループにグループ支払い機能を付与し、決済システムＳ内に特にユーザグループは新規作成されないようにしてもよい。この場合、決済システムＳは、ＳＮＳやメッセージアプリ等の機能と連携して、グループ支払いの対象となるユーザグループを特定することになる。

また例えば、実施形態では、ユーザがユーザグループにバリューを登録する場合を説明したが、特にバリューの登録が行われることなくグループ支払いが実行されてもよい。この場合、ユーザグループにバリューが登録されていないので、支払操作が行われた場合、実行部３０６は、グループ支払いの対象となるユーザグループの各ユーザにより選択された支払方法に基づいて、クレジットカード会社などの外部システムに対し、個別支払額の決済要求を送信することになる。なお、この場合、何れかの外部システムから、残高不足等の理由により決済が完了しなかった旨の通知を受信した場合には、決済をキャンセルする旨の通知を送信してもよい。

また例えば、実施形態では、ユーザがユーザグループにバリューを登録する際に、事前にその分のバリューが確保される場合を説明したが、特にこのような確保は行われなくてもよい。また例えば、実施形態では、グループ支払いが実行される際に、ユーザごとに、当該ユーザにより登録されたバリューが当該ユーザの個別支払額に足りているか否かが判定される場合を説明したが、特にこのような判定が実行されず、不足分も含めて強制的に決済処理が実行されてもよい。また例えば、ユーザグループへのバリューの登録と同時に、ユーザのバリューが実際に消費されてもよい。即ち、プリペイドカードのように、ユーザグループに対し、各ユーザが予め入金するといったような使い方がなされてもよい。

また例えば、実施形態では、店舗端末２０において全体支払額が入力される場合を説明したが、ユーザ端末１０において全体支払額が入力されてもよい。この場合、ユーザは、決済完了画面Ｇ１２を店員に見せることによって退店できるようにしてもよい。

また例えば、ユーザグループごとに、グループ支払いにおける利用上限額、購入可能商品、又は各ユーザの登録可能額といった情報が設定されていてもよい。また例えば、ユーザグループに参加するユーザは、随時変化してもよく、途中でユーザグループに加入してもよいし、途中でユーザグループから脱退してもよい。ユーザグループから脱退した場合には、確保されたバリューは解放されるようにしてもよい。また例えば、ユーザグループは、任意のタイミングで解散してもよい。ユーザグループが解散した場合には、確保されたバリューは解放されるようにしてもよい。

また例えば、実施形態では、ユーザが自発的にバリューの登録をする場合を説明したが、他のユーザからの要求に応じてバリューの登録が行われるようにしてもよい。例えば、ユーザグループの作成者は、招待する他のユーザに対し、登録してほしい額を通知してもよい。更に、作成者は、ユーザグループ全体で登録してほしい額を通知してもよいし、個々のユーザに登録してほしい額を通知してもよい。なお、作成者以外のユーザにより、登録してほしい額の通知が行われてよい。

また例えば、ユーザ端末１０には、電子マネーやポイントを記録したＩＣチップが備えられていてもよい。ＩＣチップは、制御部、記憶部、及び通信部を含み、記憶部に電子バリューの残高情報や残高情報を変化させるためのプログラムが記憶されている。そして、サーバ３０又は他のサーバからの指示に応じて、自身が記憶する残高情報を変化させるようにしてもよい。

また例えば、サーバ３０で実現されるものとして説明した機能は、ユーザ端末１０又は店舗端末２０で実現されてもよい。例えば、特定部３０１は、店舗端末２０の制御部２１を主として実現されてもよい。この場合、店舗端末２０は、サーバ３０からグループデータベースＤＢ２を取得し、特定部３０１は、グループ支払いの対象となるユーザグループを特定してもよい。また例えば、取得部３０２は、ユーザ端末１０の制御部１１を主として実現されてもよい。この場合、取得部３０２は、操作部１４から入力された全体支払額を取得してもよい。また例えば、取得部３０２は、店舗端末２０の制御部２１を主として実現されてもよい。この場合、取得部３０２は、操作部２４から入力された全体支払額を取得してもよい。

また例えば、決定部３０３は、ユーザ端末１０の制御部１１を主として実現されてもよい。この場合、決定部３０３は、店舗端末２０又はサーバ３０から全体支払額を取得して、個別支払額を決定してもよい。また例えば、決定部３０３は、店舗端末２０の制御部２１を主として実現されてもよい。この場合、決定部３０３は、ユーザ端末１０又はサーバ３０から全体支払額を取得して、個別支払額を決定してもよい。また例えば、実行部３０６は、ユーザ端末１０の制御部１１を主として実現されてもよい。この場合、実行部３０６は、クレジットカード会社などの外部システムに対し、決済処理を依頼してもよい。また例えば、実行部３０６は、店舗端末２０の制御部２１を主として実現されてもよい。この場合、実行部３０６は、クレジットカード会社などの外部システムに対し、決済処理を依頼してもよい。

Ｓ 決済システム、１０ ユーザ端末、２０ 店舗端末、３０ サーバ、１１，２１，３１ 制御部、１２，２２，３２ 記憶部、１３，２３，３３ 通信部、１４，２４ 操作部、１５，２５ 表示部、２６ 読取部、Ｇ１ トップ画面、Ｇ２ 新規作成画面、Ｇ３ 作成完了画面、Ｇ４ 招待通知画面、Ｇ５ 参加完了画面、Ｇ６ バリュー登録画面、Ｇ７ 登録完了画面、Ｇ８ メニュー画面、Ｇ９ グループ選択画面、Ｇ１０ グループ選択画面、Ｇ１１ コード表示画面、Ｇ１２ 決済完了画面、Ｇ１３ 承認画面、１００ データ記憶部、１０１ 出力制御部、１０２ 送信部、２００ データ記憶部、２０１ 金額入力部、２０２ 情報取得部、２０３ 送信部、３００ データ記憶部、３０１ 特定部、３０２ 取得部、３０３ 決定部、３０４ 増加部、３０５ 確保部、３０６ 実行部、３０７ 減少部、３０８ 送信部、Ｂ１０，Ｂ１１，Ｂ１２，Ｂ１３，Ｂ２２，Ｂ４０，Ｂ４１，Ｂ５０，Ｂ５１，Ｂ８０，Ｂ８１，Ｂ９０，Ｂ９０Ａ，Ｂ９０Ｂ，Ｂ１００，Ｂ１００Ａ，Ｂ１００Ｂ，Ｂ１３０，Ｂ１３１ ボタン、Ｆ２０，Ｆ２１，Ｆ６０ 入力フォーム、ＤＢ１ ユーザデータベース、ＤＢ２ グループデータベース、ＤＢ３ 店舗データベース。

Claims (16)

1. 所定の支払操作に基づいて、ユーザ識別情報とユーザグループ識別情報との少なくとも一方を出力するユーザ端末であって、所定の登録操作に基づいて、当該ユーザ端末のユーザが属するユーザグループにバリューを登録するための登録要求を送信するユーザ端末と、
   各ユーザグループのバリューを記憶する記憶手段と、
   前記登録要求を受信した場合に、当該登録要求をしたユーザのバリューの残高を減少させずに他の用途の支払に利用されないようにすることによって、当該ユーザのバリューを確保する確保手段と、
   前記登録要求を受信した場合に、当該登録要求をしたユーザが属するユーザグループのバリューを増加させる増加手段と、
   前記ユーザ端末により出力された情報を取得する店舗端末と、
   前記店舗端末により取得された情報に基づいて、ユーザグループを特定する特定手段と、
   前記特定手段により特定されたユーザグループ全体の支払額である全体支払額を取得する取得手段と、
   前記全体支払額に基づいて、前記特定手段により特定されたユーザグループに属する複数のユーザの個々の支払額である個別支払額を決定する決定手段と、
   前記ユーザごとに、当該ユーザの前記個別支払額に基づく決済をするための処理を実行する実行手段と、
   前記実行手段により前記処理が実行された場合に、前記全体支払額に基づいて、前記特定手段により特定されたユーザグループのバリューを減少させる減少手段と、
   を含むことを特徴とする決済システム。
2. 所定の支払操作に基づいて、ユーザ識別情報とユーザグループ識別情報との少なくとも一方を出力するユーザ端末であって、所定の登録操作に基づいて、当該ユーザ端末のユーザが属するユーザグループにバリューを登録するための登録要求を送信するユーザ端末と、
   各ユーザグループのバリューを記憶する記憶手段と、
   前記登録要求を受信した場合に、当該登録要求をしたユーザが属するユーザグループのバリューを増加させる増加手段と、
   前記ユーザ端末により出力された情報を取得する店舗端末と、
   前記店舗端末により取得された情報に基づいて、ユーザグループを特定する特定手段と、
   前記特定手段により特定されたユーザグループ全体の支払額である全体支払額を取得する取得手段と、
   前記全体支払額に基づいて、前記特定手段により特定されたユーザグループに属する複数のユーザの個々の支払額である個別支払額を決定する決定手段と、
   前記ユーザごとに、当該ユーザにより登録されたバリューが当該ユーザの前記個別支払額に足りているか否かを、所定の実行要求が行われた場合に判定し、当該判定結果に基づいて、当該ユーザの前記個別支払額に基づく決済をするための処理を実行する実行手段と、
   前記実行手段により前記処理が実行された場合に、前記全体支払額に基づいて、前記特定手段により特定されたユーザグループのバリューを減少させる減少手段と、
   を含むことを特徴とする決済システム。
3. 所定の支払操作に基づいて、ユーザ識別情報とユーザグループ識別情報との少なくとも一方を出力するユーザ端末と、
   前記ユーザ端末により出力された情報を取得する店舗端末と、
   前記店舗端末により取得された情報に基づいて、ユーザグループを特定する特定手段と、
   前記特定手段により特定されたユーザグループ全体の支払額である全体支払額を取得する取得手段と、
   前記全体支払額に基づいて、前記特定手段により特定されたユーザグループに属する複数のユーザの個々の支払額である個別支払額を決定する決定手段と、
   前記店舗端末が配置された店舗で支払操作をしたユーザ以外のユーザである承認者に対し、所定の承認要求を送信する送信手段と、
   前記承認者による承認操作に基づいて、前記ユーザごとに、当該ユーザの前記個別支払額に基づく決済をするための処理を実行する実行手段と、
   を含むことを特徴とする決済システム。
4. 前記決済システムは、前記ユーザグループから脱退したユーザに対して確保されたバリュー、又は、前記処理が実行されずに解散した前記ユーザグループのユーザに対して確保されたバリューを解放する解放手段を更に含む、
   ことを特徴とする請求項１に記載の決済システム。
5. 前記実行手段は、前記ユーザごとに、当該ユーザの前記個別支払額に基づく決済処理を実行する、
   ことを特徴とする請求項１～４の何れかに記載の決済システム。
6. 前記実行手段は、前記ユーザごとに、複数の支払方法の中から当該ユーザにより選択された支払方法で前記個別支払額に基づく決済をするための前記処理を実行する、
   ことを特徴とする請求項１～５の何れかに記載の決済システム。
7. 前記送信手段は、前記支払操作をしたユーザ、前記全体支払額、及び前記個別支払額の少なくとも１つを示す情報とともに前記承認要求を送信し、
   前記承認者の端末は、前記支払操作をしたユーザ、前記全体支払額、及び前記個別支払額の少なくとも１つを表示した後に、前記承認操作を受け付ける、
   ことを特徴とする請求項３に記載の決済システム。
8. 前記実行手段は、前記特定手段により特定されたユーザグループに属する一部のユーザによる前記承認操作に基づいて、前記処理を実行する、
   ことを特徴とする請求項３又は７に記載の決済システム。
9. 前記決定手段は、前記一部のユーザによる前記承認操作に基づいて、当該一部のユーザの前記個別支払額を再計算し、
   前記実行手段は、前記一部のユーザごとに、再計算された当該ユーザの前記個別支払額に基づく前記処理を実行する、
   ことを特徴とする請求項８に記載の決済システム。
10. 前記送信手段は、前記一部のユーザのユーザ端末に対し、再計算された当該ユーザの前記個別支払額を示す情報とともに、再承認要求を送信し、
    前記一部のユーザのユーザ端末は、前記再承認要求を受信した場合に、当該ユーザによる再承認操作を受け付け、
    前記実行手段は、前記一部のユーザによる前記再承認操作に基づいて、前記処理を実行する、
    ことを特徴とする請求項９に記載の決済システム。
11. ユーザ端末が、所定の支払操作に基づいて、ユーザ識別情報とユーザグループ識別情報との少なくとも一方を出力し、所定の登録操作に基づいて、当該ユーザ端末のユーザが属するユーザグループにバリューを登録するための登録要求を送信するステップと、
    コンピュータが、
    前記登録要求を受信した場合に、当該登録要求をしたユーザのバリューの残高を減少させずに他の用途の支払に利用されないようにすることによって、当該ユーザのバリューを確保する確保ステップと、
    前記登録要求を受信した場合に、当該登録要求をしたユーザが属するユーザグループのバリューを増加させる増加ステップと、
    前記ユーザ端末により出力された情報を店舗端末に取得させるステップと、
    前記店舗端末により取得された情報に基づいて、ユーザグループを特定する特定ステップと、
    前記特定ステップにより特定されたユーザグループ全体の支払額である全体支払額を取得する取得ステップと、
    前記全体支払額に基づいて、前記特定ステップにより特定されたユーザグループに属する複数のユーザの個々の支払額である個別支払額を決定する決定ステップと、
    前記ユーザごとに、当該ユーザの前記個別支払額に基づく決済をするための処理を実行する実行ステップと、
    前記実行ステップにより前記処理が実行された場合に、前記全体支払額に基づいて、前記特定ステップにより特定されたユーザグループのバリューを減少させる減少ステップと、
    を実行することを特徴とする決済方法。
12. ユーザ端末が、所定の支払操作に基づいて、ユーザ識別情報とユーザグループ識別情報との少なくとも一方を出力し、所定の登録操作に基づいて、当該ユーザ端末のユーザが属するユーザグループにバリューを登録するための登録要求を送信するステップと、
    コンピュータが、
    前記登録要求を受信した場合に、当該登録要求をしたユーザが属するユーザグループのバリューを増加させる増加ステップと、
    前記ユーザ端末により出力された情報を店舗端末に取得させるステップと、
    前記店舗端末により取得された情報に基づいて、ユーザグループを特定する特定ステップと、
    前記特定ステップにより特定されたユーザグループ全体の支払額である全体支払額を取得する取得ステップと、
    前記全体支払額に基づいて、前記特定ステップにより特定されたユーザグループに属する複数のユーザの個々の支払額である個別支払額を決定する決定ステップと、
    前記ユーザごとに、当該ユーザにより登録されたバリューが当該ユーザの前記個別支払額に足りているか否かを、所定の実行要求が行われた場合に判定し、当該判定結果に基づいて、当該ユーザの前記個別支払額に基づく決済をするための処理を実行する実行ステップと、
    前記実行ステップにより前記処理が実行された場合に、前記全体支払額に基づいて、前記特定ステップにより特定されたユーザグループのバリューを減少させる減少ステップと、
    を実行することを特徴とする決済方法。
13. ユーザ端末が、所定の支払操作に基づいて、ユーザ識別情報とユーザグループ識別情報との少なくとも一方を出力するステップと、
    コンピュータが、
    前記ユーザ端末により出力された情報を店舗端末に取得させるステップと、
    前記店舗端末により取得された情報に基づいて、ユーザグループを特定する特定ステップと、
    前記特定ステップにより特定されたユーザグループ全体の支払額である全体支払額を取得する取得ステップと、
    前記全体支払額に基づいて、前記特定ステップにより特定されたユーザグループに属する複数のユーザの個々の支払額である個別支払額を決定する決定ステップと、
    前記店舗端末が配置された店舗で支払操作をしたユーザ以外のユーザである承認者に対し、所定の承認要求を送信する送信ステップと、
    前記承認者による承認操作に基づいて、前記ユーザごとに、当該ユーザの前記個別支払額に基づく決済をするための処理を実行する実行ステップと、
    を実行することを特徴とする決済方法。
14. 所定の支払操作に基づいて、ユーザ識別情報とユーザグループ識別情報との少なくとも一方を出力するユーザ端末により、所定の登録操作に基づいて送信された、当該ユーザ端末のユーザが属するユーザグループにバリューを登録するための登録要求を受信する手段、
    前記登録要求を受信した場合に、当該登録要求をしたユーザのバリューの残高を減少させずに他の用途の支払に利用されないようにすることによって、当該ユーザのバリューを確保する確保手段、
    前記登録要求を受信した場合に、当該登録要求をしたユーザが属するユーザグループのバリューを増加させる増加手段、
    前記ユーザ端末により出力され、店舗端末により読み取られた情報に基づいて、ユーザグループを特定する特定手段、
    前記特定手段により特定されたユーザグループ全体の支払額である全体支払額を取得する取得手段、
    前記全体支払額に基づいて、前記特定手段により特定されたユーザグループに属する複数のユーザの個々の支払額である個別支払額を決定する決定手段、
    前記ユーザごとに、当該ユーザの前記個別支払額に基づく決済をするための処理を実行する実行手段、
    前記実行手段により前記処理が実行された場合に、前記全体支払額に基づいて、前記特定手段により特定されたユーザグループのバリューを減少させる減少手段、
    としてコンピュータを機能させるためのプログラム。
15. 所定の支払操作に基づいて、ユーザ識別情報とユーザグループ識別情報との少なくとも一方を出力するユーザ端末により、所定の登録操作に基づいて送信された、当該ユーザ端末のユーザが属するユーザグループにバリューを登録するための登録要求を受信する手段、
    前記登録要求を受信した場合に、当該登録要求をしたユーザが属するユーザグループのバリューを増加させる増加手段、
    前記ユーザ端末により出力され、店舗端末により読み取られた情報に基づいて、ユーザグループを特定する特定手段、
    前記特定手段により特定されたユーザグループ全体の支払額である全体支払額を取得する取得手段、
    前記全体支払額に基づいて、前記特定手段により特定されたユーザグループに属する複数のユーザの個々の支払額である個別支払額を決定する決定手段、
    前記ユーザごとに、当該ユーザにより登録されたバリューが当該ユーザの前記個別支払額に足りているか否かを、所定の実行要求が行われた場合に判定し、当該判定結果に基づいて、当該ユーザの前記個別支払額に基づく決済をするための処理を実行する実行手段、
    前記実行手段により前記処理が実行された場合に、前記全体支払額に基づいて、前記特定手段により特定されたユーザグループのバリューを減少させる減少手段、
    としてコンピュータを機能させるためのプログラム。
16. 所定の支払操作に基づいて、ユーザ識別情報とユーザグループ識別情報との少なくとも一方を出力するユーザ端末により、所定の登録操作に基づいて送信された、当該ユーザ端末のユーザが属するユーザグループにバリューを登録するための登録要求を受信する手段、
    前記ユーザ端末により出力され、店舗端末により読み取られた情報に基づいて、ユーザグループを特定する特定手段、
    前記特定手段により特定されたユーザグループ全体の支払額である全体支払額を取得する取得手段、
    前記全体支払額に基づいて、前記特定手段により特定されたユーザグループに属する複数のユーザの個々の支払額である個別支払額を決定する決定手段、
    前記店舗端末が配置された店舗で支払操作をしたユーザ以外のユーザである承認者に対し、所定の承認要求を送信する送信手段、
    前記承認者による承認操作に基づいて、前記ユーザごとに、当該ユーザの前記個別支払額に基づく決済をするための処理を実行する実行手段、
    としてコンピュータを機能させるためのプログラム。

Images