JP6717906B2

JP6717906B2 - プログラム、情報処理方法、および情報処理装置

Info

Publication number: JP6717906B2
Application number: JP2018177135A
Authority: JP
Inventors: 高橋　一生; 一生高橋; デイビッドアンドレアスモール
Original assignee: Mercari Inc
Current assignee: Mercari Inc
Priority date: 2018-09-21
Filing date: 2018-09-21
Publication date: 2020-07-08
Anticipated expiration: 2038-09-21
Also published as: JP2020047181A

Description

本開示は、プログラム、情報処理方法、および情報処理装置に関する。

近年、ユーザが立て替えた費用を回収するための割り勘処理を効率よく行う決済アプリケーションの開発が行われている。例えば、特許文献１には、決済アプリケーション上で割り勘人数や誰に請求するかの情報を入力して、他のユーザに割り勘額の支払いを請求することができる決済サービスが開示されている。

特開２０１３−２３８９９８号公報

しかしながら、ユーザが、上記のようなアプリケーションを用いて割り勘処理を行う場合、レシートを添付したり、割り勘額を決めて入力したりする必要がある。例えば、割り勘対象の人数が多い場合、ユーザは、割り勘対象の人数分、金額を決めたり、その金額を入力したりしなければならない。そのため、割り勘処理の手続きが煩雑になるという課題がある。

本開示の一側面では、複数人での割り勘決済を容易にし、割り勘処理の利便性を向上させることを可能にするプログラム、情報処理方法、および情報処理装置を提供することを目的とする。

本開示の一実施形態に係るプログラムは、情報処理装置に、支払額を含む第１情報コードを表示画面に表示制御するステップと、前記情報コードを読み取った各情報処理装置によって送信されたアカウント情報を受信したサーバにより処理される決済事前処理に基づき、各アカウント情報に基づく割り勘対象ユーザの総数を用いて前記支払額を除算した割り勘額を取得するステップと、前記割り勘額を用いる割り勘処理を含む決済処理を前記サーバに実行させる契機となる第２情報コードを前記表示画面に表示制御するステップと、前記決済処理又は前記割り勘処理の完了通知を前記サーバから受信するステップ、を実行させる。

図１は、実施形態の一態様に係る通信システムの構成を示す。図２は、本開示に係る情報処理装置のハードウェア構成の一例を示す。図３は、第１実施形態におけるサーバの機能構成の一例を示す。図４は、各管理ＤＢの一例を示す。図５は、端末の機能構成の一例を示す。図６は、第１実施形態に係る取得部の機能の一例を示す。図７は、第１実施形態に係る通信システムが行う店舗読取型コード決済時の処理手順のシーケンスの一例を示す。図８は、第１実施形態に係る端末１２０に表示される画面の一例を示す。図９は、第１Ａ実施例に係るサーバと端末との処理のシーケンスの一例を示す。図１０は、第１実施形態に係る通信システムが行うユーザ読取型コード決済時の処理手順のシーケンスの一例を示す。図１１は、第１Ｂ実施例に係る通信システムの処理のシーケンスの一例を示す。図１２は、第２実施形態におけるサーバの機能構成の一例を示す。図１３は、第２実施形態における端末の機能構成の一例を示す。図１４は、第２実施形態に係る通信システム１が行う処理手順のシーケンスの一例を示す。第２実施形態に係る各端末が行う候補者リストの作成および表示に関する処理手順のシーケンスの一例を示す。図１６は、第２実施形態に係る端末１２０Ａに表示される画面の一例を示す。図１７は、第１実施例に係る端末１２０Ａに表示される候補者リストの表示画面の一例を示す。図１８は、第２実施例に係る端末１２０に表示される決済完了通知の表示画面の一例を示す。

＜法令遵守＞
本明細書に記載の開示は、実施される場合、本開示を実施する各国の法令を遵守のうえで実施される。また、本明細書に記載の開示は、各国の法令を遵守するために必要な、当業者が成し得る全ての変更、置換、変形、改変、および修正をもって実施される。

本開示に係るプログラム、情報処理方法、および情報処理装置を実施するための形態について、図面を参照して説明する。

＜システム構成＞
図１は、本開示の一実施形態に係る通信システム１の構成を示す。図１に開示されるように、通信システム１では、ネットワーク１２５を介してサーバ１１０Ａ、サーバ１１０Ｂと、端末１２０Ａ、端末１２０Ｂ、端末１２０Ｃと、ＰＯＳ（Point of Sales）端末１３０Ａ、ＰＯＳ端末１３０Ｂと、外部システム１４０とが接続される。外部システム１４０は、限定でなく例として、他の事業者（金融機関、クレジットカード会社など）や他の事業部門によって運営されるサーバなどによって構築される。

本開示において、サーバ１１０Ａと、サーバ１１０Ｂとをそれぞれ区別する必要がない場合は、サーバ１１０Ａとサーバ１１０Ｂとは、それぞれサーバ１１０と表現されてもよい。

本開示において、端末１２０Ａと、端末１２０Ｂと、端末１２０Ｃとをそれぞれ区別する必要がない場合は、端末１２０Ａと端末１２０Ｂと端末１２０Ｃとは、それぞれ端末１２０と表現されてもよい。

本開示において、サーバ１１０と、端末１２０とをそれぞれ区別する必要がない場合は、サーバ１１０と端末１２０とは、それぞれ情報処理装置２００と表現されてもよい。なお、ネットワーク１２５に接続される情報処理装置２００の数は限定されない。

サーバ１１０は、ネットワーク１２５を介してユーザが利用する端末１２０に、所定のサービスを提供する。所定のサービスは、限定でなく例として、決済サービス、金融サービス、電子商取引サービス、インスタントメッセンジャーを代表とするＳＮＳ（Social Networking Service）、楽曲・動画・書籍などのコンテンツ提供サービス等を含む。ユーザが端末１２０を介して所定のサービスを利用することで、サーバ１１０は１以上の端末１２０に所定のサービスを提供することができる。

本開示において、決済サービスとは１以上のユーザが金銭または金銭相当物の授受ができるサービスを意味する。限定でなく例として、一次元コード（バーコードなど）、二次元コード（ＱＲコード（登録商標）など）、近距離無線通信（NFC、BLE、WI-FI、超音波など）を利用して決済を行うサービスを含む。また、必要に応じて一次元コード、または、二次元コードなどの情報コードを利用した決済において、支払いを行うユーザが情報コードを読み取ることで決済を行うことを「ユーザ読取型コード決済」と表現し、支払いを行うユーザが情報コードを表示し、それを請求ユーザ（または店舗）が読み取ることで決済を行うことを「店舗読取型コード決済」と表現する。

必要に応じて、ユーザＸが利用する端末を端末１２０Ｘと表現し、ユーザＸまたは端末１２０Ｘに対応づけられた、所定のサービスにおけるユーザ情報をユーザ情報Ｘと表現する。なお、ユーザ情報とは、所定のサービスにおいてユーザが利用するアカウントに対応付けられたユーザの情報である。ユーザ情報は、限定でなく例として、ユーザにより入力される、または、所定のサービスにより付与される、ユーザの名前、ユーザのアイコン画像、ユーザの年齢、ユーザの性別、ユーザの住所、ユーザの趣味趣向、ユーザの識別子などのユーザに対応づけられた情報、ユーザに対応付けられた電子バリュー（電子マネー）の残高情報、ユーザに対応付けられたクレジットカード情報（クレジットカード番号など）を含み、これらのいずれか一つまたは、組み合わせであってもよい。

ネットワーク１２５は、２以上の情報処理装置２００を接続する役割を担う。ネットワーク１２５は、端末１２０がサーバ１１０に接続した後、データを送受信することができるように接続経路を提供する通信網を意味する。

ネットワーク１２５のうちの１つまたは複数の部分は、有線ネットワークや無線ネットワークであってもよい。ネットワーク１２５は、限定でなく例として、アドホック・ネットワーク（Ad Hoc Network）、イントラネット、エクストラネット、仮想プライベート・ネットワーク（Virtual Private Network：ＶＰＮ）、ローカル・エリア・ネットワーク（Local Area Network：ＬＡＮ）、ワイヤレスＬＡＮ（Wireless LAN：ＷＬＡＮ）、広域ネットワーク（Wide Area Network：ＷＡＮ）、ワイヤレスＷＡＮ（Wireless WAN：ＷＷＡＮ）、大都市圏ネットワーク（Metropolitan Area Network：ＭＡＮ）、インターネットの一部、公衆交換電話網（Public Switched Telephone Network：ＰＳＴＮ）の一部、携帯電話網、ＩＳＤＮｓ（Integrated Service Digital Networks）、無線ＬＡＮｓ、ＬＴＥ（Long Term Evolution）、ＣＤＭＡ（Code Division Multiple Access）、ブルートゥース（Bluetooth（登録商標））、衛星通信など、または、これらの２つ以上の組合せを含むことができる。ネットワーク１２５は、１つまたは複数のネットワーク１２５を含むことができる。

情報処理装置２００は、本開示に記載される機能、および／または、方法を実現できる情報処理装置であればどのような情報処理装置であってもよい。
情報処理装置２００は、限定ではなく例として、スマートフォン、携帯電話（フィーチャーフォン）、コンピュータ（限定でなく例として、デスクトップ、ラップトップ、タブレットなど）、サーバ装置、メディアコンピュータプラットホーム（限定でなく例として、ケーブル、衛星セットトップボックス、デジタルビデオレコーダなど）、ハンドヘルドコンピュータデバイス（限定でなく例として、ＰＤＡ（Personal Digital Assistant）、電子メールクライアントなど）、ウェアラブル端末（限定でなく例として、メガネ型デバイス、時計型デバイスなど）、他種のコンピュータ、またはコミュニケーションプラットホームを含む。

ＰＯＳ端末１３０は、店舗にて、ユーザ（顧客）からの支払いを受け取るユーザ（店員等）が利用する端末であり、二次元コードリーダーを備えており、読み取った二次元コードをサーバ１１０に送信する機能を有している。二次元コードリーダーは、一次元コードリーダーや、三次元コードリーターでもよい。また、一次元コード、及び二次元コード、三次元コードを含む多次元コードは、本開示において情報コードと呼ばれてもよい。

＜ハードウェア（ＨＷ；HardWare）構成＞
図２を用いて、通信システム１に含まれる情報処理装置２００及びＰＯＳ端末１３０のＨＷ構成について説明する。

情報処理装置２００は、プロセッサ２０１と、メモリ２０２と、ストレージ２０３と、入出力インタフェース（入出力Ｉ／Ｆ）２０４と、通信インタフェース（通信Ｉ／Ｆ）２０５とを含む。情報処理装置２００のＨＷの各構成要素は、限定でなく例として、バスＢを介して相互に接続される。

情報処理装置２００は、プロセッサ２０１と、メモリ２０２と、ストレージ２０３と、入出力Ｉ／Ｆ２０４と、通信Ｉ／Ｆ２０５との協働により、本開示に記載される機能、および／または、方法を実現する。

プロセッサ２０１は、ストレージ２０３に記憶されるプログラムに含まれるコードまたは命令によって実現する機能、および／または、方法を実行する。プロセッサ２０１は、限定でなく例として、中央処理装置（ＣＰＵ）、ＭＰＵ（Micro Processing Unit）、ＧＰＵ（Graphic s Processing Unit）、マイクロプロセッサ（microprocessor）、プロセッサコア（processor core）、マルチプロセッサ（multiprocessor）、ＡＳＩＣ（Application-Specific Integrated Circuit）、ＦＰＧＡ（Field Programmable Gate Array）等を含み、集積回路（ＩＣ（Integrated Circuit）チップ、ＬＳＩ（Large Scale Integration））等に形成された論理回路（ハードウェア）や専用回路によって各実施形態に開示される各処理を実現してもよい。また、これらの回路は、１または複数の集積回路により実現されてよく、各実施形態に示す複数の処理を１つの集積回路により実現されることとしてもよい。また、ＬＳＩは、集積度の違いにより、ＶＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩなどと呼称されることもある。

メモリ２０２は、ストレージ２０３からロードしたプログラムを一時的に記憶し、プロセッサ２０１に対して作業領域を提供する。メモリ２０２には、プロセッサ２０１がプログラムを実行している間に生成される各種データも一時的に格納される。メモリ２０２は、限定でなく例として、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）などを含む。

ストレージ２０３は、以下に開示する機能、および／または、方法を実行するためのプログラムを記憶する。ストレージ２０３は、限定でなく例として、ＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）、フラッシュメモリなどを含む。

通信Ｉ／Ｆ２０５は、ネットワーク１２５を介して各種データの送受信を行う。当該通信は、有線、無線のいずれで実行されてもよく、互いの通信が実行できるのであれば、どのような通信プロトコルを用いてもよい。通信Ｉ／Ｆ２０５は、ネットワーク１２５を介して、他の情報処理装置との通信を実行する機能を有する。通信Ｉ／Ｆ２０５は、各種データをプロセッサ２０１からの指示に従って、他の情報処理装置に送信する。また、通信Ｉ／Ｆ２０５は、他の情報処理装置から送信された各種データを受信し、プロセッサ２０１に伝達する。

入出力Ｉ／Ｆ２０４は、情報処理装置２００に対する各種操作を入力する入力装置、および、情報処理装置２００で処理された処理結果を出力する出力装置を含む。入出力Ｉ／Ｆ２０４は、入力装置と出力装置が一体化していてもよいし、入力装置と出力装置とに分離していてもよい。

入力装置は、ユーザからの入力を受け付けて、当該入力に係る情報をプロセッサ２０１に伝達できる全ての種類の装置のいずれか、または、その組み合わせにより実現される。入力装置は、限定でなく例として、タッチパネル、タッチディスプレイ、キーボード等のハードウェアキーや、マウス等のポインティングデバイス、カメラ（画像を介した操作入力）、マイク（音声による操作入力）を含む。

出力装置は、プロセッサ２０１で処理された処理結果を出力することができる全ての種類の装置のいずれか、または、その組み合わせにより実現される。当該処理結果を映像、および／または、動画像として出力する場合、出力装置は、フレームバッファに書き込まれた表示データに従って、当該表示データを表示することができる全ての種類の装置のいずれかまたはその組み合わせにより実現される。出力装置は、限定でなく例として、タッチパネル、タッチディスプレイ、モニタ（限定でなく例として、液晶ディスプレイ、ＯＥＬＤ（Organic Electroluminescence Display）など）、ヘッドマウントディスプレイ（ＨＤＭ：Head Mounted Display）、プロジェクションマッピング、ホログラム、空気中など（真空であってもよい）に画像やテキスト情報等を表示可能な装置、スピーカ（音声出力）、プリンターなどを含む。なお、これらの出力装置は、３Ｄで表示データを表示可能であってもよい。

本開示の各実施形態のプログラムは、コンピュータに読み取り可能な記憶媒体に記憶された状態で提供されてもよい。記憶媒体は、「一時的でない有形の媒体」に、プログラムを記憶可能である。プログラムは、限定でなく例として、ソフトウェアプログラムやコンピュータプログラムを含む。

記憶媒体は適切な場合、１つまたは複数の半導体ベースの、または他の集積回路（ＩＣ）（限定でなく例として、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）、特定用途向けＩＣ（ＡＳＩＣ）など）、ハード・ディスク・ドライブ（ＨＤＤ）、ハイブリッド・ハード・ドライブ（ＨＨＤ）、光ディスク、光ディスクドライブ（ＯＤＤ）、光磁気ディスク、光磁気ドライブ、フロッピィ・ディスケット、フロッピィ・ディスク・ドライブ（ＦＤＤ）、磁気テープ、固体ドライブ（ＳＳＤ）、ＲＡＭドライブ、セキュア・デジタル・カードもしくはドライブ、任意の他の適切な記憶媒体、またはこれらの２つ以上の適切な組合せを含むことができる。記憶媒体は、適切な場合、揮発性、不揮発性、または揮発性と不揮発性の組合せでよい。

また、本開示のプログラムは、当該プログラムを伝送可能な任意の伝送媒体（通信ネットワークや放送波等）を介して、情報処理装置２００に提供されてもよい。
また、本開示の各実施形態は、プログラムが電子的な伝送によって具現化された、搬送波に埋め込まれたデータ信号の形態でも実現され得る。

なお、本開示のプログラムは、限定でなく例として、ＪａｖａＳｃｒｉｐｔ（登録商標）、Ｐｙｔｈｏｎなどのスクリプト言語、Ｃ言語、Ｇｏ言語、Ｓｗｉｆｔ，Ｋｏｌｔｉｎ、Ｊａｖａ（登録商標）などを用いて実装される。

情報処理装置２００おける処理の少なくとも一部は、１以上のコンピュータにより構成されるクラウドコンピューティングにより実現されていてもよい。

情報処理装置２００における処理の少なくとも一部を、他の情報処理装置により行う構成としてもよい。この場合、プロセッサ２０１により実現される各機能部の処理のうち少なくとも一部の処理を、他の情報処理装置で行う構成としてもよい。

＜その他＞
明示的な言及のない限り、本開示の実施形態における判定の構成は必須でなく、判定条件を満たした場合に所定の処理が動作されたり、判定条件を満たさない場合に所定の処理がされたりしてもよい。

本開示では、明記されない限り、または文脈によって示されない限り、「または」は排他的ではなく包含的な意味である。したがって、本開示では、明記されていない限り、または文脈によって示されない限り、「ＡまたはＢ」は「Ａ、Ｂ、またはその両方」を意味する。さらに、「ＡおよびＢの少なくとも一方」は、「Ａ、Ｂ、またはその両方」を意味する。さらに、明記されない限り、または文脈によって示されない限り、「ａ」、「ａｎ」、または「ｔｈｅ」は「１つまたは複数」を意味するものとする。したがって、本明細書では、別段に明記されない限り、または文脈によって示されない限り、「ａｎＡ」または「ｔｈｅＡ」は「１つまたは複数のＡ」を意味する。

本開示は、本開示の実施形態、および／または、実施例に対して、当業者が成し得る全ての変更、置換、変形、改変、および修正を包含する。同様に、適切な場合、添付の特許請求の範囲は、本開示の実施形態、および／または、実施例に対して、当業者が成し得る全ての変更、置換、変形、改変、および修正を包含する。さらに、本開示は、当業者が成し得る、本開示における実施形態、および／または、実施例の１つまたは複数の特徴と、本開示における他の実施形態、および／または、実施例の１つまたは複数の特徴との任意の組合せを包含する。

加えて、特定の機能を実施するように適合される、配置される、能力を有する、構成される、使用可能である、動作可能である、または動作できる装置またはシステムあるいは装置またはシステムの構成要素に対する添付の特許請求の範囲での参照は、その装置、システム、または構成要素がそのように適合される、配置される、能力を有する、構成される、使用可能にされる、動作可能にされる、または動作できる限り、その装置、システム、構成要素またはその特定の機能がアクティベートされ、オンにされ、またはロック解除されているか否かに関わらず、その装置、システム、構成要素を包含する。

本開示は、明示されない限り、いずれの実施形態または実施例を実施するに際して、事前に、または、実施の直前にユーザからの同意を取得してもよい。また、取得する同意は、包括的なものでもよく、都度取得するものでもよい。

＜第１実施形態＞
第１実施形態は、ユーザが端末１２０を用いて、ネットワーク１２５経由によるオンライン処理で、情報コードによる決済サービスを受ける際に、割り勘処理を可能とする実施形態である。

情報コードは、一次元コード、二次元コード、三次元コードなどの多次元コードを含むコードである。なお、一次元コードは、限定でなく例として、バーコードであってもよい。また、二次元コードは、限定でなく例として、ＱＲコード（登録商標）、ＡｚｔｅｃＣｏｄｅ、ＰＤＦ４１７等であってもよい。三次元コードは、限定でなく例として、ＱＲコード（登録商標）に色を組み合わせたＰＭコード（登録商標）等であってもよい。以下の説明では、説明の便宜上、二次元コードによる決済を行う前提で説明するが、第１実施形態及び第２実施形態は、一次元コードまたは三次元コードを含む多次元コードによる決済にも適用することが可能である。

第１実施形態における店舗読取型コード決済の一側面では、支払い対象ユーザの端末１２０に表示された二次元コードを、割り勘対象ユーザの端末１２０が読み取ってサーバ１１０に送信する。支払い対象ユーザの端末１２０が、サーバ１１０から送信される割り勘対象ユーザのアカウント情報に基づいて割り勘対象の総数を取得する。支払い対象ユーザの端末１２０は、取得した総数を用いて、割り勘額を取得し、割り勘額を含む決済リクエストをサーバ１１０に送信する。これにより、ユーザに煩雑な手続きを行わせることなく、割り勘処理を容易に実行することが可能になる。

また、第１実施形態における店舗読取型コード決済の一側面では、割り勘対象ユーザが、支払い対象ユーザと所定の関係がある場合に、割り勘処理を実行する。また、本側面において、支払い対象ユーザと所定の関係がある他のユーザに、支払額の全額を代理で払ってもらうことも可能である。これにより、関係のない他人に無断等で、支払い対象ユーザの支払額の一部、または全部を支払わせることを防止することが可能になり、セキュリティの向上を図ることができる。

また、第１実施形態におけるユーザ読取型コード決済の一側面では、支払い対象ユーザの端末１２０が、店舗等に掲載された二次元コードや、ＰＯＳ端末１３０等に表示された二次元コードを読み取り、読み取った二次元コードに基づいて割り勘用の二次元コードを生成し、生成した二次元コードを画面に表示する。後の処理は店舗読取型コード決済の処理と同様であり、割り勘対象ユーザの端末１２０が、支払い対象ユーザの端末１２０に表示された二次元コードを読み取ることで、割り勘処理や決済処理が行われる。これにより、煩雑な手続きをユーザが行うことなく、割り勘処理を容易に行うことが可能になる。

また、第１実施形態におけるユーザ読取型コード決済の一側面では、店舗等に掲示された二次元コードや、ＰＯＳ端末１３０等に表示された二次元コードを、割り勘を行う各ユーザの端末１２０が読み取り、読み取った二次元コードに含まれる情報や各ユーザのアカウント情報などをサーバ１１０に送信する。サーバ１１０は、受信した情報に基づいて、割り勘対象ユーザの総数や割り勘額を算出し、算出した情報を各端末１２０に送信する。これにより、ユーザ読取型コード決済の場合でも、煩雑な手続きをユーザが行うことなく、割り勘処理を容易に実行することが可能になる。また、端末１２０側は、二次元コードの読み取り、割り勘額の表示、決済処理のリクエストの送信を行えばよく、実体的な計算処理が不要になるため、端末１２０の処理速度の向上を図ることが可能になる。

また、第１実施形態の開示技術は、店舗側の既存のシステムや、既に掲示している二次元コードを変更しなくても導入可能であるため、店舗側にとっても、本開示の技術を容易に適用することが可能になる。

＜第１実施形態の機能構成＞
（１）サーバの機能構成
図３は、第１実施形態におけるサーバ１１０の機能構成の一例を示す図である。図３に開示の機能部は、情報処理装置２００が備えるプロセッサ２０１と、メモリ２０２と、ストレージ２０３と、入出力Ｉ／Ｆ２０４と、通信Ｉ／Ｆ２０５との協働により実現される。

サーバ１１０は、例えば、入出力部３０２と、通信部３０４と、決済事前処理部３０６と、割り勘処理部３０８と、決済処理部３１０と、記憶部３１２とを有する。入出力部３０２は、例えば、入出力Ｉ／Ｆ２０４を用いて実現されうる。また、通信部３０４は、例えば、通信Ｉ／Ｆ２０５を用いて実現されうる。決済事前処理部３０６と、割り勘処理部３０８と、決済処理部３１０とは、プロセッサ２０１が、記憶部３１２に格納されているプログラムを読み出して実行することで実現されうる。記憶部３１２は、メモリ２０２および／またはストレージ２０３を用いて実現される。

記憶部３１２は、第１の実施形態に係るサーバ１１０が実行するプログラムと、二次元コード決済を利用するユーザのアカウント情報を管理するユーザ管理ＤＢ（DataBase）と、ユーザ同士の所定の関係を管理する関連管理ＤＢと、ユーザが行った決済処理の履歴を管理する決済管理ＤＢとを格納する。図４は、各管理ＤＢの一例を示す図である。

図４（Ａ）は、ユーザ管理ＤＢの一例を示す。ユーザ管理ＤＢには、決済事業者により作成された各ユーザのアカウントに関する情報が管理される。「ユーザＩＤ」には、サーバ１１０がユーザを一意に識別するためのユーザ識別情報（ＩＤ：Identifier）が格納される。「パスワード」には、ユーザ認証を行うためのパスワードが格納される。「残高」には、ユーザが保有する金銭の残高が格納される。なお、図４（Ａ）に図示していないが、ユーザ管理ＤＢは、ユーザの端末１２０により発行された二次元コードの情報を一時的に格納するようにしてもよい。二次元コードの情報は、限定でなく例として、二次元コードを識別するコード識別情報や、二次元コードの有効期限などを含んでもよい。ユーザ管理ＤＢで管理されている情報の一部又は全部を、アカウント情報とも称す。

図４（Ｂ）は、関連管理ＤＢの一例を示す。「グループＩＤ」には、ユーザの所定の関係を識別するための識別情報が格納される。「ユーザＩＤ」には、所定の関係を有するユーザのユーザ識別情報が格納される。

所定の関係とは、サーバ１１０が、２以上のユーザ間の所定の関係を記憶していることを意味する。限定でなく例として、所定の関係は、相互に関係構築を承認した関係、少なくとも一方が関係構築を申し入れた関係、ユーザ情報に基づき構築された関係、ユーザ行動に基づき構築された関係、所定の条件が満たされたことにより関係構築がなされた状態を含んでもよい。なお、ユーザ情報に基づき構築された関係とは、１以上の同一または類似するユーザ情報を有するユーザ同士を関係づけた関係を含んでもよいし、ユーザ行動に基づき構築された関係とは、１以上の同一または類似するユーザ行動を有するユーザ同士を関係づけた関係を含んでもよい。

また、ユーザと所定の関係にあるユーザは、限定ではなく例として、ユーザと所定の関係にある全てのユーザでもよいし、予め定められた所定の人数のユーザであってもよいし、親密度が所定の度合い以上のユーザであってもよい。

ここで、親密度とは、所定の期間内（１か月間や２か月間などの予め固定された期間でもよいし、所定の関係を構築してから現在までの期間でもよい）においてユーザとの間で送受信したメッセージの送受信量が多い順に親密度が高くなるように決定される度合いであってもよい。また、所定の期間内においてユーザ間で行われた取引（商品の売買や、資産の送受信・両替等などを含む）の回数が多い順に親密度が高くなるように決定される度合いでもよい。

また、親密度とは、所定の関係が構築されてから現在までの期間の長さが長いほど親密度が高くなるように決定される度合いであってもよい。所定の関係を構築してから現在までの期間の長さは、絶対値であってもよいし、ユーザと所定の関係にある１以上のユーザの中での相対値であってもよい。

また、親密度とは、ユーザと所定の関係にある複数の他のユーザについて、他のユーザがユーザの位置から所定の範囲内にいる時間の長さが長いほど、親密度が高くなるように決定される度合いであってもよい。また、親密度とは、ユーザと所定の関係にある複数のユーザについて、所定の関係が構築されてから現在までの期間と、各ユーザの位置情報とに基づいて推定される関係性（例えば家族関係にあると推定される等が高いほど親密度が高くなるように決定される度合いであってもよい。

また、親密度とは、ユーザと所定の関係にある複数の他のユーザについて、ユーザと共通のユーザの数（共通の友達の人数）が多いほど親密度が高くなるように決定される度合いであってもよい。

また、親密度とは、ユーザとコミュニケーションをとっているユーザと所定の関係を構築しているユーザのうち、ユーザ自身と所定の関係にあるユーザの数が多いほど親密度が高くなるように決定される度合いであってもよい。

また、親密度とは、ユーザ自身の属性と、ユーザと所定の関係にある複数のユーザの各々の属性との間における類似度が高いほど親密度が高くなるように決定される度合いであってもよい。ユーザの属性とは、限定ではなく例として、興味又は関心であってもよい。

限定でなく例として、図４（Ｂ）に示すグループＩＤ「Ｇ０１」は、家族を表しており、ユーザＩＤ「Ｕ０１」、「Ｕ０３」、「Ｕ０５」が示すユーザ達は、みんな１つの家族の構成員であることを表す。関連管理ＤＢは、このデータベースを管理する管理者により新規のグループ及びユーザ達が登録されてもよい。

図４（Ｃ）は、決済管理ＤＢの一例を示す図である。「日時」には、二次元コード決済が完了した日時が格納される。「店舗ＩＤ」には、二次元コード決済が行われた店舗の店舗情報（店舗ＩＤとも称す）が格納される。なお、店舗ＩＤは、店舗に複数のＰＯＳ端末１３０がある場合は、ＰＯＳ端末１３０のＩＤでもよい。「支払額」には、二次元コード決済が行われた際の支払額が格納される。また、決済管理ＤＢは、決済を識別する情報である決済ＩＤなどがある場合は、決済ＩＤを管理するようにしてもよい。これにより、決済情報の検索が容易になる。

入出力部３０２は、入出力Ｉ／Ｆ２０４を介して各種データの入力を受け付ける処理、及び、入出力Ｉ／Ｆ２０４を介して各種のデータを出力する処理を行う機能を有する。

通信部３０４は、通信Ｉ／Ｆ２０５を介して端末１２０及びＰＯＳ端末１３０から各種データを受信する処理、及び、通信Ｉ／Ｆ２０５を用いて各種のデータを端末１２０及びＰＯＳ端末１３０に送信する処理を行う機能を有する。

決済事前処理部３０６は、各ユーザの端末１２０から送信されたアカウント情報に基づいて、決済を行うための事前処理を行う機能を有する。決済事前処理は、割り勘額を取得するための処理であり、各種処理を含む。例えば、決済事前処理部３０６は、端末１２０からアカウント情報の送信リクエストに対して、ユーザのアカウント情報を所定の端末１２０に送信したりする。また、決済事前処理部３０６は、送信された各ユーザのアカウント情報に基づいて、割り勘対象のユーザの総数を求めたり、又は支払額からユーザの総数を除算して割り勘額を求めたりしてもよい。

割り勘処理部３０８は、支払いにおいて立て替えてもらったユーザの残高から割り勘額を減算し（引き出し）、支払いを行ったユーザの残高に加算する（振り込む）処理を行う機能を有する。また、割り勘処理部３０８は、割り勘額の引き出し及び振り込みの処理を、後述する決済処理の後に行っても、前に行ってもよい。

決済処理部３１０は、二次元コード決済を実行するための各種の処理を行う機能を有する。具体的には、決済処理部３１０は、決済リクエストに含まれる情報に基づいて決済処理を行う。決済処理は、支払い対象のユーザの残高から支払額を減算し、決済リクエストなどから特定される店舗の口座に支払額を振り込む処理を含む。ここで、店舗の口座とは、店舗が所有しているアカウントを含む。店舗の口座に支払額を振り込む（預け入れる）／引き出すとは、店舗のアカウントの残高に支払額を加算する／減算することを含む。

次に、二次元コード決済における店舗読取型コード決済と、ユーザ読取型コード決済との場合に分けて、通信部３０４、決済事前処理部３０６、割り勘処理部３０８、及び決済処理部３１０の具体的な機能について説明する。

（Ａ）店舗読取型コード決済におけるサーバの機能構成
通信部３０４は、支払い対象ユーザ（例、ユーザＡ）の端末１２０に表示された二次元コードを読み取った各端末１２０から、割り勘対象ユーザのアカウント情報、及び支払い対象ユーザのユーザＩＤなどを受信する受信部（第１Ａ受信部）として機能する。二次元コードには、例えば、この二次元コードを生成した支払い対象ユーザＡ、および／または、支払額を含む。アカウント情報は、限定でなく例として、二次元コードを読み取った端末１２０を利用する割り勘対象ユーザ（例えば、ユーザＢ、ユーザＣ）のユーザＩＤ及びパスワードを含む。また、通信部３０４は、受信した割り勘対象ユーザのアカウント情報及び支払い対象ユーザのユーザＩＤに基づく決済事前処理の結果などを、支払い対象ユーザの端末１２０に送信する送信部（第１Ａ送信部）としても機能する。

また、通信部３０４は、支払い対象ユーザの端末１２０から、各割り勘対象ユーザのアカウント認証及び残高確認リクエストを受信する受信部（第２Ａ受信部）として機能してもよい。アカウント認証及び残高確認リクエストには、例えば、割り勘対象ユーザのアカウント情報、及び割り勘額が含まれる。また、通信部３０４は、支払い対象ユーザの端末１２０に、各割り勘対象ユーザのアカウント認証及び残高確認の結果を送信する送信部（第２Ａ送信部）として機能してもよい。アカウント認証及び残高確認の結果には、例えば、割り勘対象ユーザのユーザＩＤ及びパスワードに基づくアカウント認証の成否、並びに割り勘対象ユーザのアカウントに関連付けられる残高が割り勘額以上であるか否かの結果が含まれる。

また、通信部３０４は、支払い対象ユーザの端末１２０に表示された二次元コードを読み取ったＰＯＳ端末１３０から、店舗側に支払額を支払うための決済リクエストを受信する受信部（第３Ａ受信部）として機能してもよい。決済リクエストには、例えば、二次元コードを読み取ったＰＯＳ端末１３０に関連付けられる店舗ＩＤ、支払額、及び支払い対象ユーザのユーザＩＤなどが含まれる。また、通信部３０４は、ＰＯＳ端末１３０、および／または、支払い対象ユーザの端末１２０に、決済の完了通知を送信する送信部（第３Ａ送信部）として機能してもよい。

決済事前処理部３０６は、第１Ａ受信部により受信された割り勘対象ユーザのアカウント情報及び支払い対象ユーザのユーザＩＤ等に基づいて、決済を行うための事前処理を行う。決済事前処理部３０６は、例えば、支払い対象ユーザのユーザＩＤから支払い対象ユーザを特定する。次に、決済事前処理部３０６は、割り勘対象ユーザのアカウント情報を、第１Ａ送信部を介して支払い対象ユーザの端末１２０に送信するよう指示する。また、決済事前処理部３０６は、支払額を取得できる場合は、所定期間内に受信したアカウント情報の総数に応じて割り勘額を算出し、割り勘額を支払い対象ユーザの端末１２０に送信するようにしてもよい。この場合、割り勘額の算出については、支払い対象ユーザの端末１２０から割り勘額の算出リクエストを受信したときに算出するようにしてもよい。これにより、割り勘の人数が決まった後に、適切な割り勘額が算出されるようになる。

また、決済事前処理部３０６は、第２Ａ受信部により受信された割り勘対象ユーザのアカウント認証及び残高確認リクエストに応じて、アカウント認証処理及び残高確認処理を行う。決済事前処理部３０６は、アカウント認証処理として、第２Ａ受信部により受信されたアカウント情報を基にユーザ管理ＤＢに問い合わせ、割り勘対象ユーザの認証が成功したか否かを判定する。また、決済事前処理部３０６は、残高確認処理として、第２Ａ受信部により受信された割り勘額を基にユーザ管理ＤＢに問い合わせ、割り勘対象ユーザの残高が割り勘額以上であるか否かを判定する。また、決済事前処理部３０６は、アカウント認証の結果、及び残高確認の結果を、第２Ａ送信部を介して支払い対象ユーザの端末１２０に送信するよう指示する。

割り勘処理部３０８は、第３Ａ受信部により受信された決済リクエストに応じて、支払い対象ユーザ以外の割り勘対象の各ユーザのアカウントを特定し、特定されたアカウントに紐づけられた各ユーザの残高から割り勘額を減算し、支払い対象ユーザの残高に加算する割り勘処理を行う。また、割り勘処理部３０８は、割り勘処理の完了通知を、第３Ａ送信部を介して、支払い対象ユーザの端末１２０に送信する。

決済処理部３１０は、第３Ａ受信部により受信された決済リクエストに応じて、店舗ＩＤに関連付けられる店舗の口座に、支払い対象ユーザの残高から減算した支払額を支払う決済処理を行う。決済処理は、外部システム１４０を用いて行われる。また、決済処理部３１０は、決済処理の完了通知を、第３Ａ送信部を介して、二次元コードを読み取ったＰＯＳ端末１３０、および／または、支払い対象ユーザの端末１２０に送信する。なお、上述したとおり、割り勘処理及び決済処理の順序は問わず、どちらが先に行われてもよいが、支払い対象ユーザが割り勘額を回収し損ねることを防ぐために、本開示では、割り勘処理を先に実行する例を説明する。

また、決済事前処理部３０６は、二次元コードを表示した端末１２０のユーザと、この二次元コードを読み取った端末１２０のユーザとの所定の関係に応じて、割り勘処理を実行するか否かを判定してもよい。この場合、決済事前処理部３０６は、第１Ａ受信部により受信された支払い対象ユーザのユーザＩＤと、アカウント情報に含まれるユーザＩＤとが所定の関係を有するかを関連管理ＤＢに問い合わせる。決済事前処理部３０６は、問い合わせ結果を取得し、ユーザ間の所定の関係を示す判定結果を、第１Ａ送信部を介して支払い対象ユーザの端末１２０に送信する。例えば、支払い対象ユーザと、割り勘対象ユーザとが所定の関係（例えば、家族、大学の友人等）を有する場合に、割り勘処理を実行することが可能になる。これにより、所定の関係のないユーザとの割り勘処理を防ぐことができ、セキュリティの向上を図ることができる。

また、割り勘処理以外にも、二次元コードを表示した端末１２０のユーザの代わりに、この二次元コードを読み取った端末１２０のユーザに全額支払ってもらうような処理にも、本開示の技術は適用可能である。例えば、子供であるユーザＡの決済を、ユーザＡの親であるユーザＢが行う場合に、割り勘ではなく代理支払いであることを示す代理情報を含む二次元コードが、ユーザＡの端末１２０Ａに表示される。このとき、ユーザＢの端末１２０Ｂが二次元コードを読み取って、二次元コードに含まれる代理情報及びユーザＡのユーザＩＤと、端末１２０Ｂ側で追加されたユーザＢのアカウント情報とがサーバ１１０に送信される。決済事前処理部３０６は、ユーザＡのユーザＩＤと、ユーザＢのアカウント情報に含まれるユーザＢのユーザＩＤとに基づいて、ユーザ間の所定の関係を判定する。決済事前処理部３０６は、ユーザ間の所定の関係がある場合に、代理支払いを行うことを許可する。これにより、所定の関係のないユーザによる代理支払いを防止することができ、セキュリティの向上を図ることができる。

（Ｂ）ユーザ読取型コード決済におけるサーバの機能構成
通信部３０４は、店舗に対応付けられた二次元コード（例えば、店舗の所定位置に掲示された、またはＰＯＳ端末１３０に表示された二次元コード）を読み取った各端末１２０から、この二次元コードに含まれる決済情報、及び、二次元コードを読み取った端末１２０のユーザのアカウント情報などを受信する受信部（第１Ｂ受信部）として機能する。決済情報は、例えば支払額などを含む。また、通信部３０４は、受信された各アカウント情報に基づく決済事前処理の結果を、決済情報を送信した各端末１２０に送信する送信部（第１Ｂ送信部）としても機能する。決済事前処理の結果は、例えば、受信された各アカウント情報に関連付けられるユーザの総数を用いて支払額を除算した割り勘額を含んでもよい。また、通信部３０４は、各端末１２０から決済リクエストを受信する受信部（第２Ｂ受信部）としても機能する。また、通信部３０４は、決済リクエストに応じて処理された割り勘処理、および／または、決済処理の完了通知を、二次元コードを表示したＰＯＳ端末１３０、および／または、二次元コードを読み取った各端末１２０に送信する送信部（第２Ｂ送信部）としても機能する。

なお、ユーザ読取型コード決済において、ＰＯＳ端末１３０に表示された二次元コードを、支払い対象ユーザの端末１２０が読み取り、この端末１２０が、割り勘処理用の二次元コードを生成し、生成した二次元コードを割り勘対象ユーザの各端末１２０に読み取らせてもよい。この場合、以降のサーバ１１０側の機能は、店舗読取型コード決済の場合の機能と同様であるが、決済リクエストは、支払い対象ユーザの端末１２０から送信されてもよい。よって、以下では、ＰＯＳ端末１３０等に表示された二次元コードを、割り勘対象ユーザの各端末１２０が読み取ることを例にして説明する。

決済事前処理部３０６は、決済事前処理として、第１Ｂ受信部により受信された各アカウント情報に関連付けられるユーザ（割り勘対象ユーザ）の総数を求め、この総数と支払額の少なくとも一部を用いて割り勘額を算出する。例えば、決済事前処理部３０６は、支払額を総数で除算して算出した割り勘額を含む決済事前処理の結果を、第１Ｂ送信部を介して各ユーザの端末１２０に送信する。これにより、サーバ側で割り勘額を算出するため、端末１２０側の処理負荷を減らすことができる。

また、決済事前処理部３０６は、決済事前処理として、割り勘対象ユーザの総数を、第１Ｂ送信部を介して各ユーザの端末１２０に送信するようにしてもよい。この場合、端末１２０側で割り勘額の算出が行われるため、各端末１２０は、支払額をサーバ１１０側に送信しなくてもよい。

割り勘処理部３０８は、第２Ｂ受信部により受信された決済リクエストに応じて、決済リクエストを送信した各端末１２０を利用する割り勘対象の各ユーザの残高から、決済事前処理部３０６により算出された割り勘額を減算して引き出す。

決済処理部３１０は、割り勘処理部３０８により減算された各割り勘額を、決済リクエストに含まれる店舗ＩＤに関連付けられる店舗の口座に支払う決済処理を行う。また、決済処理部３１０は、決済処理の完了通知を、第２Ｂ送信部を介して、二次元コードを表示したＰＯＳ端末１３０、および／または、二次元コードを読み取った各端末１２０に送信する。

なお、ユーザ読取型コード決済の場合、割り勘処理部３０８及び決済処理部３１０は、上述した割り勘額の引き出しから、店舗口座への預け入れまでを協働して行ってもよい。また、割り勘額が端末１２０側で算出される場合、端末１２０から送信される決済リクエストには、割り勘額が含まれてもよい。この場合、割り勘処理部３０８は、第２受信部により受信された決済リクエストに含まれる割り勘額を、割り勘対象の各ユーザの残高から減算して引き出すようにしてもよい。

ユーザ読取型コード決済における他の例として、事前チェックインが考えられる。例えば、レストランの各テーブルに、このテーブルまたはレストランを識別するための識別情報（以下、支払先ＩＤとも称す）が変換された二次元コードが掲示されたり、テーブルに設置された端末１２０の画面に表示されたりする。そのテーブルに座る各ユーザは、自分の端末１２０を用いて二次元コードを読み取って、チェックイン処理を行う。チェックイン処理において、各端末１２０は、読み取った支払先ＩＤ、及びユーザのアカウント情報をサーバ１１０に送信する。

次に、店舗側において、このテーブルでの注文が全て完了したのち、ユーザからの指示に応じて、チェックアウト処理が行われる。チェックアウト処理において、例えば、ユーザが、テーブルに設置された端末１２０上で、注文完了を指示すると、この端末１２０から、支払先ＩＤ及び支払額がサーバ１１０に送信される。サーバ１１０の決済事前処理部３０６は、支払額を取得すると、チェックインしたユーザ（割り勘対象ユーザ）の数と支払額の少なくとも一部を用いて割り勘額を算出する。以降の処理は、上述したユーザ読取型コード決済の処理と同様である。これにより、ユーザは、支払いのためにレジなどに並ぶ必要がなく、迅速に支払いを済ませることができる。

（２）端末の機能構成
図５を用いて端末１２０の機能構成を説明する。図５に開示の機能部は、情報処理装置２００が備えるプロセッサ２０１と、メモリ２０２と、ストレージ２０３と、入出力Ｉ／Ｆ２０４と、通信Ｉ／Ｆ２０５との協働により実現される。

端末１２０は、入出力部５０２と、通信部５０４と、生成部５０６と、表示制御部５０８と、取得部５１０と、調整部５１２と、決済制御部５１４と、読み取り部５１６と、記憶部５１８を有する。入出力部５０２と、通信部５０４と、生成部５０６と、表示制御部５０８と、取得部５１０と、調整部５１２と、決済制御部５１４と、読み取り部５１６とは、プロセッサ２０１が、記憶部５１８に格納されているプログラムを読み出して実行することで実現される。記憶部５１８は、メモリ２０２および／またはストレージ２０３を用いて実現される。上述したとおり、二次元コード決済は、店舗読取型コード決済と、ユーザ読取型コード決済とを含むため、まずは店舗読取型コード決済における端末１２０の機能構成について説明し、次に、ユーザ読取型コード決済における端末１２０の機能構成について説明する。

（Ａ）店舗読取型コード決済における端末の機能構成
入出力部５０２は、入出力Ｉ／Ｆ２０４を介して各種データの入力を受け付ける処理、及び、入出力Ｉ／Ｆ２０４を介して各種のデータを出力する処理を行う機能を有する。

通信部５０４は、通信Ｉ／Ｆ２０５を介してサーバ１１０から各種データを受信する処理、及び、通信Ｉ／Ｆ２０５を用いて各種のデータをサーバ１１０に送信する処理を行う機能を有する。通信部５０４は、割り勘対象ユーザのアカウント情報、及び支払い対象ユーザのユーザＩＤなどを受信したサーバ１１０により処理される決済事前処理に基づき、割り勘対象ユーザの各アカウント情報を受信する受信部（第４Ａ受信部）として機能する。アカウント情報は、限定でなく例として、二次元コードを読み取った端末１２０を利用する割り勘対象ユーザのユーザＩＤ及びパスワードを含む。

また、通信部５０４は、各割り勘対象ユーザのアカウント認証及び残高確認リクエストを、サーバ１１０に送信する送信部（第４Ａ送信部）として機能してもよい。アカウント認証及び残高確認リクエストには、例えば、割り勘対象ユーザのアカウント情報、及び割り勘額が含まれる。また、通信部５０４は、サーバ１１０から、各割り勘対象ユーザのアカウント認証及び残高確認の結果を受信する受信部（第５Ａ受信部）として機能してもよい。アカウント認証及び残高確認の結果には、例えば、割り勘対象ユーザのユーザＩＤ及びパスワードに基づくアカウント認証の成否、及び割り勘対象ユーザのアカウントに関連付けられる残高が割り勘額以上であるか否かの結果が含まれる。

また、通信部５０４は、支払い対象ユーザの端末１２０に表示された二次元コードを読み取ったＰＯＳ端末１３０に、店舗側に支払額を支払うための決済リクエストを送信する送信部（第５Ａ送信部）として機能してもよい。決済リクエストは、例えば、二次元コードに含まれてもよい。また、通信部５０４は、サーバ１１０から、決済の完了通知を受信する受信部（第５Ａ受信部）として機能してもよい。

生成部５０６は、支払い対象ユーザの端末１２０に表示するための二次元コードの生成を補助する。具体的には、生成部５０６は、二次元コードを生成するための補助画面を表示画面に表示するよう表示制御部５０８に指示する。補助画面は、例えば、支払額の入力欄や、割り勘にするか否かの選択欄を含む。生成部５０６は、入出力部５０２を介して、補助画面に入力された情報に基づいて、割り勘用の二次元コードを生成する。割り勘用の二次元コードは、第１情報コードとも称される。

表示制御部５０８は、端末１２０の表示画面への表示を制御する。例えば、表示制御部５０８は、生成部５０６により指示された補助画面を表示画面に表示するよう制御したり、生成部５０６により生成された二次元コードを表示画面に表示するよう制御したりする。また、表示制御部５０８は、後述する調整部５１２により指示された調整画面を表示画面に表示するよう制御する。なお、補助画面や調整画面は、表示画面の画面全体として実装されたり、表示画面のユーザインターフェースの一部として実装されたりしてもよい。

取得部５１０は、二次元コードを読み取った各端末１２０によって送信されたアカウント情報を受信したサーバ１１０により処理される決済事前処理に基づき、各アカウント情報に基づく割り勘対象ユーザの総数と、支払額の少なくとも一部とを用いて算出された割り勘額を取得する。

図６は、第１実施形態に係る取得部５１０の機能の一例を示すブロック図である。図６に示すように、取得部５１０は、限定でなく例として、総数算出部６０２と、割り勘額算出部６０４とを有する。

総数算出部６０２は、取得されたアカウント情報の数に基づいて、割り勘対象ユーザの総数を算出する。例えば、総数算出部６０２は、取得されたアカウント情報が３つである場合、アカウント情報の数（３）に支払い対象ユーザの数（１）を加算して、総数（４）を算出する。

割り勘額算出部６０４は、総数算出部６０２により算出された総数と、生成部５０６における補助画面内で入力された支払額の少なくとも一部とを用いて、割り勘額を算出する。例えば、割り勘額算出部６０４は、支払額が１２，０００円であり、総数が４である場合、支払額（１２，０００円）を総数（４）で除算して、割り勘額（３，０００円）を算出する。なお、取得部５１０は、決済事前処理部３０６により割り勘額が算出される場合は、サーバ１１０側で算出された割り勘額を取得する。

図５に戻り、調整部５１２は、割り勘の人数を調整するための調整画面を表示画面に表示するよう表示制御部５０８に指示する。調整部５１２は、例えば、プラスボタン、マイナスボタンを用いることで、割り勘対象人数を調整できるようにする。これにより、例えば、端末１２０を持っていないユーザが、割り勘対象に含まれる場合、このユーザを割り勘対象ユーザに含めることができるようになる。また、誤って割り勘対象に含まれたユーザを割り勘対象ユーザから外すため、割り勘対象ユーザの総数から人数を減らすことができるようになる。

決済制御部５１４は、決済処理および／または割り勘処理の実行を制御する機能を有する。決済制御部５１４は、限定でなく例として、各割り勘対象ユーザのアカウント認証及び残高確認リクエストをサーバ１１０に送信するよう通信部５０４に指示する。この場合、決済制御部５１４は、残高確認リクエストに、取得部５１０で取得された割り勘額や、各割り勘対象ユーザのアカウント情報（ユーザＩＤ及びパスワード）を含めてもよい。

また、決済制御部５１４は、サーバ１１０から残高確認結果を取得すると、所定のユーザの残高が割り勘額未満の場合、割り勘処理を停止したり、表示画面に警告を出すように表示制御部５０８に指示したりする。また、残高確認結果が、全割り勘対象ユーザの残高が割り勘額以上であることを示す場合、決済制御部５１４は、支払額を含む二次元コードを表示画面に表示するよう表示制御部５０８に指示する。また、二次元コードには支払対象ユーザのユーザＩＤが含められてもよい。決済用の二次元コードは、第２情報コードとも称される。

読み取り部５１６は、二次元コードを読み取るリーダーの機能を有する。例えば、読み取り部５１６は、店舗に掲示されている二次元コード、ＰＯＳ端末１３０に表示されている二次元コード、または端末１２０の表示画面に表示されている二次元コードを読み取る。読み取り部５１６により読み取られた情報は、サーバ１１０に送信されたり、各種処理に用いられたりする。

記憶部５１８は、第１の実施形態に係る端末１２０が実行するプログラムを格納する。このプログラムは、限定でなく例として、開示の二次元コード決済における割り勘処理を実行するためのプログラムである。

＜第１実施形態における店舗読取型コード決済時の動作処理＞
図７を参照し、第１実施形態に係る通信システム１の店舗読取型コード決済時の処理について説明する。図７は、第１実施形態に係る通信システム１が行う店舗読取型コード決済時の処理手順のシーケンスの一例を示す図である。図７に示す例は、ユーザが、割り勘処理を行うための二次元コード（第１情報コード）を生成し、各割り勘対象ユーザに二次元コードを読み取らせて割り勘処理を行う場合を想定したシーケンスである。

ステップＳ７０２で、端末１２０Ａの入出力部５０２は、ユーザから、補助画面内の支払額の入力や、割り勘処理の選択を受け付ける。例えば、入出力部５０２は、二次元コード決済を行うアプリケーションにおいて、ユーザによる表示画面上のソフトテンキーなどを用いての支払額の入力や、割り勘処理を行うためのボタンの押下を受け付ける。

ステップＳ７０４で、端末１２０Ａの生成部５０６は、入出力部５０２による支払額の入力や、割り勘処理の選択に基づいて、割り勘用の二次元コードを生成する。割り勘処理用の二次元コードは、支払額の情報や、端末１２０Ａを利用する支払い対象ユーザのユーザＩＤ等が変換されて含まれる。また、二次元コードは、割り勘処理を実行することを示す情報が変換されて含まれてもよい。これにより、この二次元コードを読み取った各端末１２０は、割り勘処理であることを迅速に認識することが可能になる。

ステップＳ７０６で、端末１２０Ａの表示制御部５０８は、生成部５０６により生成された二次元コードを表示画面に表示するよう制御する。

ステップＳ７０８で、端末１２０Ｂの読み取り部５１６は、端末１２０Ａに表示されている二次元コードを読み取る。

ステップＳ７１０で、端末１２０Ｂの通信部５０４は、端末１２０ＢのユーザＢのアカウント情報を端末１２０Ａに送信するための送信リクエストをサーバ１１０に送信する。例えば、送信リクエストには、端末１２０Ｂを利用するユーザＢにより入力されたアカウント情報や、端末１２０Ａを利用するユーザＡのユーザＩＤが含まれる。

ステップＳ７１２で、サーバ１１０の通信部３０４は、ユーザＢのアカウント情報を端末１２０Ａに送信する。サーバ１１０は、例えば、ユーザＡのユーザＩＤに基づいて、アカウント情報の送信先の端末１２０Ａを特定可能である。

ステップＳ７１４で、端末１２０Ｃの読み取り部５１６は、端末１２０Ａに表示されている二次元コードを読み取る。

ステップＳ７１６で、端末１２０Ｃの通信部５０４は、端末１２０ＣのユーザＣのアカウント情報を端末１２０Ａに送信するための送信リクエストをサーバ１１０に送信する。例えば、送信リクエストには、端末１２０Ｃを利用するユーザＣにより入力されたアカウント情報や、端末１２０Ａを利用するユーザＡのユーザＩＤが含まれる。

ステップＳ７１８で、サーバ１１０の通信部３０４は、ユーザＣのアカウント情報を端末１２０Ａに送信する。サーバ１１０は、例えば、ユーザＡのユーザＩＤに基づいて、アカウント情報の送信先の端末１２０Ａを特定可能である。

ステップＳ７２０で、端末１２０Ａの調整部５１２は、総数算出部６０２により算出された割り勘対象の総数を調整する。例えば、総数算出部６０２は、受信された２つのアカウント情報から、割り勘対象ユーザが２人であることを特定し、この２人に支払い対象ユーザの１人を足して、総数は３人であると特定する。次に、調整部５１２は、調整画面などを用いて、入出力部５０２により入力された総数に対するユーザからの調整指示を取得する。例えば、ユーザが「＋」のボタンを１回押下すると、調整部５１２は、総数を１つ増加させ、ユーザが「−」のボタンを１回押下すると、調整部５１２は、総数を１つ減少させる。また、調整部５１２は、各ユーザが負担する金額を調整できてもよい。これにより、より柔軟な割り勘を行うことができる。なお、調整部５１２は、必ずしも必要な構成ではないが、この機能を設けることにより、現金で払いたいユーザなどがいる場合に割り勘対象の総数を調整することが可能になる。また、割り勘額は端末１２０Ａを使用するユーザＡによって、ユーザ毎に設定されても良い。

ステップＳ７２２で、端末１２０Ａの取得部５１０は、割り勘額を決定する。例えば、取得部５１０の割り勘額算出部６０４は、ステップＳ７０２で入力された支払額を、総数算出部６０２により決定された総数、又は調整部５１２により調整された総数で除算し、支払額を算出する。

ステップＳ７２４で、端末１２０Ａの通信部５０４は、サーバ１１０に、割り勘対象のユーザＢとユーザＣのアカウント認証及び残高確認リクエストを送信する。アカウント認証及び残高確認リクエストには、限定でなく例として、割り勘対象ユーザのアカウント情報、割り勘額が含まれる。

ステップＳ７２６で、サーバ１１０の決済事前処理部３０６は、割り勘対象ユーザのアカウント認証と、残高確認を行う。アカウント認証について、サーバ１１０の決済事前処理部３０６は、受信したアカウント情報に含まれるユーザＩＤ及びパスワードが、ユーザ管理ＤＢに登録されているユーザＩＤ及びパスワードと一致するか否かを判定する。ユーザＩＤ及びパスワードが一致する場合は認証成功を表し、ユーザＩＤ及びパスワードが一致しない場合は認証失敗を表す。

また、残高確認について、サーバ１１０の決済事前処理部３０６は、ユーザ管理ＤＢに保持されている各割り勘対象ユーザの残高が、受信された割り勘額以上であるか否かを判定する。残高が割り勘額以上であれば、残高有りを表し、残高が割り勘額未満であれば、残高不足（残高無し）を表す。

ステップＳ７２８で、サーバ１１０の通信部３０４は、アカウント認証及び残高確認結果を端末１２０Ａに送信する。アカウント認証及び残高確認結果には、例えば、アカウント認証の成否、残高の有無が含まれる。

ステップＳ７３０で、端末１２０Ａの決済制御部５１４は、アカウント認証及び残高確認結果が、アカウント認証成功、及び残高有を示していれば、決済のための二次元コード（第２情報コード）を表示画面に表示するよう表示制御部５０８に指示する。これにより、表示画面には、二次元コードが表示される。二次元コードには、例えば、支払額、ユーザＡのユーザＩＤなどが含まれてもよい。

ステップＳ７３２で、ＰＯＳ端末１３０は、端末１２０Ａの表示画面に表示された二次元コードを読み取る。

ステップＳ７３４で、ＰＯＳ端末１３０は、支払額、ユーザＡのユーザＩＤ、店舗ＩＤなどを含む決済リクエストをサーバ１１０に送信する。

ステップＳ７３６で、サーバ１１０の割り勘処理部３０８及び決済処理部３１０は、割り勘処理及び決済処理を実行する。例えば、割り勘処理部３０８は、割り勘対象ユーザのユーザＢ及びユーザＣの残高から割り勘額を減算し、引き出した金額を支払い対象ユーザのユーザＡの残高に加算する。次に、決済処理部３１０は、ユーザＡの残高から支払額を引き出し、引き出した支払額を外部システム１４０（図７に不図示）に登録されている店舗の口座に振り込む。支払い対象ユーザのユーザＡの残高と、割り勘対象ユーザのユーザＢ及びユーザＣの残高とから割り勘額を減算し、外部システム１４０（図７に不図示）に登録されている店舗の口座に振り込むように構成されてもよい。

ステップＳ７３８で、サーバ１１０の通信部３０４は、割り勘処理、及び決済処理が完了した後、完了通知をＰＯＳ端末１３０に送信する。

ステップＳ７４０で、サーバ１１０の通信部３０４は、割り勘処理、及び決済処理が完了した後、完了通知をＰＯＳ端末１３０に送信する。

なお、割り勘対象ユーザのアカウント認証については、ステップＳ７１０やステップＳ７１６の後に行われてもよい。この場合、ステップＳ７１２、Ｓ７１８では、アカウント認証結果が端末１２０Ａに送信される。また、この場合、ステップＳ７２４、Ｓ７２６、Ｓ７２８では、アカウント認証に関する処理は行われない。これにより、割り勘処理の初期段階でアカウント認証処理が行われることで、アカウント認証できないユーザを、決済アプリケーションにおける割り勘処理から早期に排除することができる。

また、ステップＳ７０４とステップＳ７３０において表示される二次元コードは、同一の二次元コードでもよい。これにより、再度二次元コードを生成する処理を省くことができる。同一の二次元コードは、ユーザＡのユーザＩＤ、支払額を含み、さらに、決済を識別するための決済ＩＤを含んでもよい。決済ＩＤが二次元コードに含まれることで、サーバ１１０側では、決済ＩＤに紐づけて、割り勘対象ユーザのアカウント認証、残高確認、割り勘処理、決済処理を一貫して管理することが可能になる。

また、ステップＳ７０４とステップＳ７３０において表示される二次元コードは、異なる二次元コードでもよい。これにより、割り勘用の二次元コードと、決済用の二次元コードとを明確に分けることができる。また、二次元コードのワンタイム性を採用し、セキュリティを向上させることができる。

また、ステップＳ７１０、Ｓ７１６において、支払額がサーバ１１０に送信されてもよく、この場合、サーバ１１０側で割り勘額の算出が可能になる。例えば、サーバ１１０の決済事前処理部３０６は、所定時間内に受信した送信リクエストの数に基づいて、割り勘対象ユーザの総数を算出し、支払額を総数で除算することで割り勘額を算出する。サーバ１１０の通信部３０４は、割り勘額を端末１２０Ａに送信する。端末１２０Ａの取得部５１０は、サーバ１１０により処理された決済事前処理に基づき算出された割り勘額を取得する。これにより、端末１２０Ａのアプリケーション側の処理を減らすことができる。

なお、ステップＳ７０２では、支払額がユーザにより入力されているが、ＰＯＳ端末１３０などの二次元コードを読み取って支払額が入力されるようにしてもよい。これにより、ユーザによる支払額の誤入力を防止することができる。

＜第１実施形態の端末に関する店舗読取型コード決済時の表示態様＞
図８は、第１実施形態に係る端末１２０に表示される画面の一例を示す図である。図８（Ａ）は、二次元コードを生成するための補助画面の一例を示している。図８（Ａ）に示す補助画面は、支払額の入力欄、及び割り勘の選択ボタンを少なくとも含む。図８（Ａ）に示す補助画面は、例えば、図７に示すステップＳ７０２の処理で表示される画面に対応する。

図８（Ｂ）は、生成された二次元コードを表示する画面の一例を示している。図８（Ｂ）に示す画面は、端末１２０の生成部５０６により生成された二次元コードを含む。図８（Ｂ）に示す画面は、例えば、図７に示すステップＳ７０６の処理で表示される画面に対応する。

図８（Ｃ）は、割り勘対象ユーザの総数を調整する画面の一例を示している。図８（Ｃ）に示す画面は、割り勘対象ユーザの総数を増減させるためのボタンや、割り勘額の表示欄、割り勘額の確認ボタンを含む。割り勘対象ユーザの総数の増減に応じて、取得部５１０などの処理により、割り勘額が変更される。図８（Ｃ）に示す画面は、例えば、図７に示すステップＳ７２０の処理で表示される画面に対応する。図８（Ｃ）に示す画面において、ユーザが「ＹＥＳ」ボタンを押下すると、ステップＳ７２４が処理される。

図８（Ｄ）は、割り勘対象ユーザのアカウント認証、残高確認リクエストを送信したことを示している。図８（Ｄ）に示す画面は、図７に示すステップＳ７２４の処理が行われた後、ステップＳ７２８の結果を受信するまで、又は所定時間経過するまで、端末１２０Ａの表示画面に表示されてもよい。

図８（Ｅ）は、割り勘対象ユーザのアカウント認証、残高確認が完了したことを示している。図８（Ｅ）に示す画面は、全ての割り勘対象ユーザのアカウント認証が成功し、残高が割り勘額以上有る場合に表示される。図８（Ｅ）に示す画面は、図７に示すステップＳ７２８の処理が行われた後、端末１２０の表示画面に表示されてもよい。

図８（Ｆ）は、決済が完了したことを示している。図８（Ｆ）に示す画面は、例えば、支払額や決済完了の表示を含む。図８（Ｆ）に示す画面は、図７に示すステップＳ７４０の処理が行われた後、端末１２０の表示画面に表示されてもよい。

＜＜第１Ａ実施例＞＞
第１実施形態の第１Ａ実施例は、割り勘対象ユーザと支払い対象ユーザとの所定の関係が判定され、所定の関係がない場合には割り勘処理が行われない実施例である。「所定の関係がある」とは、例えば、友達、大学、家族などの所定のグループ内に、割り勘対象ユーザと支払対象ユーザと入っていることを条件とする。

＜＜第１Ａ実施例の効果＞＞
本実施例によれば、支払い対象ユーザと、割り勘対象ユーザとの所定の関係を判断するため、支払い対象ユーザと全く関係のないユーザに対して、割り勘処理を実行させてしまうことを防止することができる。

＜＜第１Ａ実施例の動作処理＞＞
図９は、本実施例に係るサーバ１１０と端末１２０との処理のシーケンスの一例を示す図である。図９に示す例は、ユーザが、割り勘処理を行うための二次元コードを生成し、各割り勘対象ユーザの端末１２０に二次元コードを読み取らせた後、サーバ１１０がユーザの所定の関係を判定し、所定の関係がある場合に、割り勘処理が行われる場合を想定したシーケンスである。

図９に示すステップＳ９０２、Ｓ９０４、Ｓ９０６、及びＳ９０８の処理は、図７に示すステップＳ７０４、Ｓ７０６、Ｓ７０８、及びＳ７１０それぞれの処理と同様であるため、説明を省略する。なお、ステップＳ９０２において、生成部５０６は、オンラインショッピングなどの決済画面から支払額と店舗ＩＤを含む二次元コードを生成してもよい。

図９に示すステップＳ９１０で、サーバ１１０の決済事前処理部３０６は、ユーザ間の所定の関係を判定する。例えば、決済事前処理部３０６は、支払い対象ユーザと、割り勘対象ユーザとに所定の関係があるか否かを、関連管理ＤＢに問い合わせる。具体的には、決済事前処理部３０６は、支払い対象ユーザのユーザＩＤと、割り勘対象ユーザのユーザＩＤとが関連管理ＤＢ内の同一グループに含まれているか否かを判定する。同一グループ内に両ＩＤが含まれていれば、「関連有り」と判定され、同一グループ内に両ＩＤが含まれていなければ、「関連無し」と判定される。

ステップＳ９１２で、サーバ１１０の通信部３０４は、所定の関係の判定結果を端末１２０Ａに送信する。

ステップＳ９１４で、端末１２０Ａの表示制御部５０８は、サーバ１１０から受信した判定結果を表示画面に表示するよう制御する。例えば、表示画面には、端末１２０Ａを利用する第１ユーザと、各情報処理装置を利用する他の各ユーザとに所定の関係がある場合に、この所定の関係があるユーザの情報の少なくとも一部が、所定の関係がないユーザの情報の少なくとも一部とは異なる態様で表示される。限定でなく例として、所定の関係があるユーザのユーザＩＤと、所定の関係がないユーザのユーザＩＤとの文字の色、文字サイズ、及び文字のフォント等の少なくとも１つを異ならせる。また、他の例として、表示画面には、ユーザ情報に関連づけて「関連有」、又は「関連無」が表示されてもよい。

ステップＳ９１６で、端末１２０Ａの決済制御部５１４は、決済リクエストをサーバ１１０に送信する。決済リクエストには、支払い対象ユーザのユーザＩＤ、割り勘対象ユーザのユーザＩＤ、及び支払額が含まれる。

ステップＳ９１８で、サーバ１１０の割り勘処理部３０８及び決済処理部３１０は、上述した割り勘処理及び決済処理を行う。なお、割り勘処理部３０８は、割り勘対象ユーザの総数及び支払額が分かるので、割り勘額の算出を行ってもよい。

ステップＳ９２０で、サーバ１１０は、割り勘処理および／または決済処理の完了通知を端末１１０Ａに送信する。

図９に示す割り勘処理では、アカウント認証や残高確認を行わない簡易の割り勘処理を示しているが、図７において説明したアカウント認証や残高確認が行われてもよい。また、ステップＳ９１６の後に、端末１２０Ａは、決済用の二次元コード（第２情報コード）を表示画面に表示制御し、この二次元コードを読み取ったＰＯＳ端末１３０等により決済リクエストを送信させるようにしてもよい。また、図９に示す例では、サーバ１１０が関連管理ＤＢを記憶するようにしたが、各端末で記憶するようにしてもよい。この場合、各端末は、サーバ１１０から他の端末のアカウント情報を受信し、他のアカウント情報に基づいて、自端末で所定の関係があるか否かを判定してもよい。

＜＜第２Ａ実施例＞＞
第１実施形態の第２Ａ実施例は、割り勘ではなく、支払うべきユーザと所定の関係のある他人が、支払うべきユーザに代わって支払う処理（以下、「代理支払い処理」とも言う。）にも適用することが可能である。例えば、子供が使用する端末１２０の表示画面に二次元コードが表示され、表示された二次元コードを親の端末１２０が読み取り、親子の関係が承認された場合に、親が子に代わって代理支払い処理を行う。

＜＜第２Ａ実施例の効果＞＞
本実施例によれば、支払うべきユーザに代わって、支払うべきユーザと所定の関係を有するユーザが支払額の全額を払うことが可能になる。

＜＜第２Ａ実施例の動作処理＞＞
図９に示すシーケンスを用いて、本実施例を説明すると、例えば、端末１２０Ａが子供の端末とし、端末１２０Ｂを親の端末とする。ステップＳ９０２で、端末１２０Ａの生成部５０６は、代理支払い用の二次元コードを生成する。

ステップＳ９１２、Ｓ９１４、Ｓ９１６、及びＳ９２０では、処理対象が、子供の端末１２０Ａから親の端末１２０Ｂに代わる。また、ステップＳ９１８で、割り勘処理は実行されず、決済処理が実行される。これにより、親のアカウントから支払額の全額が引き出され、店舗側の口座等に振り込まれる。また、子供の端末１２０Ａ、又は親の端末１２０Ｂが決済用の二次元コードを表示画面に表示させ、この二次元コードを読み取ったＰＯＳ端末１３０等に決済リクエストを送信させるようにしてもよい。

＜＜第３Ａ実施例＞＞
第１実施形態の第３Ａ実施例は、支払額を割り勘対象の総数で割り切れないとき、各割り勘対象ユーザの割り勘額に対する端数処理が行われる。端数処理は、割り切れない小数点以下の余り部分について、誰に、小数点以下部分をどのように割り振るか等を決めておく処理である。

＜＜第３Ａ実施例の効果＞＞
第３Ａ実施例により、割り勘額を算出する際に、割り切れない小数点以下の部分の処理を設定しておくので、任意の支払額、および、割り勘対象ユーザの任意の総数について割り勘処理を適切に実行することが可能になる。

端数処理は、サーバ１１０の決済事前処理部３０６、または端末１２０の取得部５１０などにより実行される。また、端数処理は、数種類の端数処理を含み、支払額が総数で割り切れなかった場合に、一つの端数処理が予め決定されていてもよいし、数種類の処理の中から１つをユーザに決定させるようにしてもよい。なお、端数処理は、上述又は後述する実施形態又は実施例に適用可能である。

（端数処理１）
端数処理１では、各ユーザの割り算結果（商）の端数を、切り上げ又は切り捨てることにより、各ユーザの割り勘額を決定する。例えば、支払額が１００００円であり、割り勘対象ユーザの総数が３人であるとする。この場合、割り勘額の商の余り（小数点以下）を四捨五入すると、一人あたり３３３３円になるが、割り勘額の合計が、支払額から１円足りなくなる。したがって、３人の割り勘対象ユーザのうち、２人は小数点以下を切り捨て、１人は小数点以下を切り上げるようにする。端数処理では、所定の条件に従って、小数点以下を切り上げる割り勘対象ユーザの一人を決定するようにしておく。例えば、支払い対象ユーザに予め設定されたり、サーバで初めに受信されたアカウント情報を有するユーザに設定されたり、支払い対象ユーザが決定したりするようにしてもよい。

（端数処理２）
端数処理２は、各割り勘対象ユーザの商の端数を切り捨てて、各ユーザの割り勘額を決定する処理を含む。サーバ１１０は、支払額から、各割り勘対象ユーザの割り勘額の合計を減算した金額を、支払額から割り引く処理を実行する。例えば、支払額が１００００円であり、割り勘対象ユーザの総数が３人であるとする。この場合、割り勘額の商の余りを切り捨てると、一人あたり３３３３円になるが、割り勘額の合計が、支払額から１円足りなくなる。端数処理２では、サーバ１１０が、支払額から１円割り引く処理を実行する。なお、余りを切り捨てることで不足する不足額について、決済事業者又は店舗が負担するようにしてもよい。

（端数処理３）
端数処理３は、各割り勘対象ユーザの商の端数を切り上げて、各割り勘対象ユーザの割り勘額を決定する処理を含む。サーバ１１０は、各割り勘対象ユーザの割り勘額の合計から支払額を減算した金額を決済業者に支払う処理を実行する。例えば、支払額が１００００円であり、割り勘対象ユーザの総数が３人であるとする。この場合、割り勘額の商の余りを切り上げると、一人あたり３３３４円になるが、割り勘額の合計が、支払額より２円多くなる。端数処理３では、サーバ１１０が、支払額より多い２円を決済事業者に支払う処理を実行する。上述した端数処理１〜３について、商の端数の切り捨て、切り上げの位は、小数点以下だけではなく、一の位や十の位でもよい。

（Ｂ）ユーザ読取型コード決済における端末の機能構成
次に、ユーザ読取型コード決済における端末の機能構成について説明する。以下、ユーザ読取型コード決済における端末の機能と、店舗読取型コード決済における端末の機能とが同様である場合は、説明を省略する。

通信部５０４は、店舗に対応づけられた二次元コード（例えば、店舗に掲示された二次元コード、又は店舗に設置されている端末に表示された二次元コード）に含まれる決済情報、自端末１２０を利用するユーザのアカウント情報などをサーバ１１０に送信する送信部（第４Ｂ送信部）として機能する。決済情報は、限定でなく例として、少なくとも店舗ＩＤを含み、さらに支払額を含んでもよい。例えば、決済情報は、二次元コードがテーブルチェックインなどで用いられる場合には、店舗ＩＤを含み、二次元コードがＰＯＳ端末１３０での支払いなどに用いられる場合には、店舗ＩＤ及び支払額を含む。アカウント情報は、限定でなく例として、二次元コードを読み取った端末１２０を利用する割り勘対象ユーザのユーザＩＤ及びパスワードを含む。

また、通信部５０４は、二次元コードを読み取った各端末１２０によって送信されたアカウント情報を受信したサーバ１１０により処理される決済事前処理に基づき、各アカウント情報の総数を用いて決済情報に関連づけられた支払額を除算した割り勘額を受信する受信部（第４Ｂ受信部）としても機能する。サーバ１１０の決済事前処理部３０６は、受信したアカウント情報の総数と、支払額とを用いて割り勘額を算出することが可能である。

また、通信部５０４は、割り勘額を含む決済リクエストをサーバに１１０に送信する送信部（第５Ｂ送信部）として機能してもよい。また、決済リクエストには、店舗ＩＤが含まれてもよい。

また、通信部５０４は、サーバ１１０から、決済の完了通知を受信する受信部（第５Ｂ受信部）として機能してもよい。

取得部５１０は、二次元コードを読み取った各端末１２０によって送信されたアカウント情報を受信したサーバ１１０により処理される決済事前処理に基づき、各アカウント情報に基づく割り勘対象ユーザの総数を用いて、決済情報に関連付けられる支払額を除算した割り勘額を取得する。なお、取得部５１０は、サーバ１１０から受信された割り勘額を取得してもよいし、店舗読取型コード決済同様、取得したアカウント総数から支払額を除算して算出してもよい。

読み取り部５１６は、店舗に対応づけられた二次元コード（例えば、店舗に掲示された二次元コードや、店舗に設置されている端末に表示されている二次元コード）を読み取る。読み取り部５１６により読み取られた情報は、サーバ１１０に送信されたり、各種処理に用いられたりする。

＜第１実施形態におけるユーザ読取型コード決済時の動作処理＞
図１０を参照し、第１実施形態に係る通信システム１のユーザ読取型コード決済時の処理について説明する。図１０は、第１実施形態に係る通信システム１が行うユーザ読取型コード決済時の処理手順のシーケンスの一例を示す図である。図１０に示す例は、ＰＯＳ端末１３０に表示された二次元コードを、各割り勘対象ユーザが利用する各端末１２０で読み取って割り勘処理を行う場合を想定したシーケンスである。

ステップＳ１００２で、ＰＯＳ端末１３０は、決済用の二次元コードを表示画面に表示する。この二次元コードには、限定でなく例として、支払額、及び店舗ＩＤなどの情報が変換されて含まれる。なお、支払額は、ユーザ側で入力されてもよい。

ステップＳ１００４で、端末１２０Ａの読み取り部５１６は、ＰＯＳ端末１３０に表示されている二次元コードを読み取る。

ステップＳ１００６で、端末１２０Ａの通信部５０４は、端末１２０ＡのユーザＡのアカウント情報、二次元コードから読み取った、またはユーザにより入力された支払額、店舗ＩＤ等をサーバ１１０に送信する。

ステップＳ１００８で、端末１２０Ｂの読み取り部５１６は、ＰＯＳ端末１３０に表示されている二次元コードを読み取る。

ステップＳ１０１０で、端末１２０Ｂの通信部５０４は、端末１２０ＢのユーザＢのアカウント情報、二次元コードから読み取った支払額、店舗ＩＤ等をサーバ１１０に送信する。

ステップＳ１０１２で、端末１２０Ｃの読み取り部５１６は、ＰＯＳ端末１３０に表示されている二次元コードを読み取る。

ステップＳ１０１４で、端末１２０Ｃの通信部５０４は、端末１２０ＣのユーザＣのアカウント情報、二次元コードから読み取った支払額、店舗ＩＤ等をサーバ１１０に送信する。

ステップＳ１０１６で、サーバ１１０の決済事前処理部３０６は、例えば、所定時間内に、同じ店舗ＩＤ、及び同じ支払額とともに送信されるアカウント情報の総数をカウントする。また、サーバ１１０の決済事前処理部３０６は、支払額を総数で除算し、割り勘額を算出する。なお、この時点で、サーバ１１０側でアカウント認証が行われてもよい。また、アカウント認証に失敗したユーザがいる場合、サーバ１１０は、アカウント情報の再入力をユーザにリクエストしてもよい。このとき、サーバ１１０は、割り勘対象ユーザを集めるための所定時間を延長してもよい。

また、サーバ１１０の決済事前処理部３０６は、割り勘額の算出後、各割り勘対象ユーザのアカウントの残高を参照し、残高確認処理を行ってもよい。この場合、各割り勘対象ユーザに対する残高確認処理の結果は、各割り勘対象ユーザに通知される。

ステップＳ１０１８で、サーバ１１０の通信部３０４は、算出された割り勘額を端末１２０Ａに通知する。

ステップＳ１０２０で、サーバ１１０の通信部３０４は、算出された割り勘額を端末１２０Ｂに通知する。

ステップＳ１０２２で、サーバ１１０の通信部３０４は、算出された割り勘額を端末１２０Ｃに通知する。

ステップＳ１０２４で、端末１２０Ａの表示制御部５０８は、割り勘額を表示するよう制御した後、端末１２０Ａの決済制御部５１４は、決済リクエストをサーバ１１０に送信するよう通信部５０４に指示する。

ステップＳ１０２６、端末１２０Ｂの表示制御部５０８は、割り勘額を表示するよう制御した後、端末１２０Ｂの決済制御部５１４は、決済リクエストをサーバ１１０に送信するよう通信部５０４に指示する。

ステップＳ１０２８、端末１２０Ｃの表示制御部５０８は、割り勘額を表示するよう制御した後、端末１２０Ｃの決済制御部５１４は、決済リクエストをサーバ１１０に送信するよう通信部５０４に指示する。

ステップＳ１０３０で、サーバ１１０の割り勘処理部３０８は、決済リクエストに応じて、各割り勘対象ユーザのアカウントに関連付けられる各残高から、割り勘額を引き出す。次に、決済処理部３１０は、引き出した各割り勘額の総額（支払額）を、決済情報に関連付けられる店舗ＩＤに示される店舗側に支払う処理を実行する。なお、割り勘処理部３０８は決済処理部３１０に含まれてもよく、この場合、決済処理部３１０は、ユーザＡ、Ｂ、Ｃの残高から割り勘額を引き出し、引き出した割り勘額の合計（支払額）を外部システム１４０（図７に不図示）に登録されている店舗の口座に振り込むようにしてもよい。

ステップＳ１０３２で、サーバ１１０の通信部３０４は、割り勘処理、又は決済処理が完了した後、完了通知を端末１２０Ａに送信する。

ステップＳ１０３４で、サーバ１１０の通信部３０４は、割り勘処理、又は決済処理が完了した後、完了通知を端末１２０Ｂに送信する。

ステップＳ１０３６で、サーバ１１０の通信部３０４は、割り勘処理、又は決済処理が完了した後、完了通知を端末１２０Ｃに送信する。

ステップＳ１０３８で、サーバ１１０の通信部３０４は、割り勘処理、又は決済処理が完了した後、完了通知をＰＯＳ端末１３０に送信する。

＜＜第１Ｂ実施例＞＞
第１実施形態の第１Ｂ実施例は、割り勘対象ユーザが、先に二次元コードを読み取ってチェックインし、支払額が決定した後に、割り勘処理を行って決済を済ませる実施例である。第１Ｂ実施例の具体例として、レストランなどでテーブルに二次元コードを掲示しておき、または、テーブルに設置された端末に表示された二次元コードを、そのテーブルに座った各ユーザ（各割り勘対象ユーザ）がそれぞれの端末１２０で読み取ってチェックイン処理を行う。次に、各ユーザは、料理等を注文し、全ての注文が確定した後、支払額が決定する。その後、テーブルの端末、又は店舗のレジ端末から支払額がサーバに送信され、サーバは、割り勘処理や決済処理を実行する。支払額は、決済ＩＤなどに関連付けられると、事前に送信された決済情報との関連付けが容易になる。

＜＜第１Ｂ実施例の効果＞＞
本実施例によれば、事前に割り勘対象ユーザの総数や、各割り勘対象ユーザのアカウント認証処理等を済ませておくことができるので、割り勘時に迅速に処理を完了させることが可能になる。例えば、レストランにおいて、ユーザのテーブル着席時等に、各端末１２０が二次元コードを読み取ってチェックインを済ませ、注文が完了するまでの間に割り勘対象人数の総数やアカウント認証をサーバ１１０側で済ませておき、支払額が決定した後で、速やかに割り勘処理及び決済処理を実行することが可能になる。また、ユーザは、テーブルでチェックアウト処理を行うことができるので、レジに向かうことなく退店することが可能になる。

＜＜第１Ｂ実施例の動作処理＞＞
図１１は、本実施例に係る通信システム１の処理のシーケンスの一例を示す図である。図１１に示すシーケンスを用いて、本実施例を説明すると、例えば、端末１２０Ｃがレストランのテーブルに設置された端末とする。この端末１２０Ｃに表示された二次元コードをユーザの端末１２０Ａや端末１２０Ｂが読み取ってチェックイン処理を行う。また、各ユーザは、端末１２０Ｃを用いてメニューの注文をしたり、注文の完了を指示したり、支払額の確認をしたり、決済処理を指示したりすることが可能である。

ステップＳ１１０２で、端末１２０Ｃは、決済用の二次元コードを表示画面に表示する。この二次元コードには、限定でなく例として、店舗ＩＤ、テーブルＩＤ、決済ＩＤまたはいずれかの組み合わせが変換されて含まれる。端末１２０Ｃは、例えば、レストランのテーブルなどに置いてある注文可能な端末である。

ステップＳ１１０４で、端末１２０Ａの読み取り部５１６は、端末１２０Ｃに表示されている二次元コードを読み取る。

ステップＳ１１０６で、端末１２０Ａの通信部５０４は、端末１２０ＡのユーザＡのアカウント情報、二次元コードから読み取った店舗ＩＤ等（決済情報）をサーバ１１０に送信する。なお、この時点で、サーバ１１０は、ユーザＡのアカウント認証を行ってもよい。店舗ＩＤは、この店舗を支払先とする支払先識別情報としての役割を果たしてもよい。

ステップＳ１１０８で、端末１２０Ｂの読み取り部５１６は、端末１２０Ｃに表示されている二次元コードを読み取る。

ステップＳ１１１０で、端末１２０Ｂの通信部５０４は、端末１２０ＢのユーザＢのアカウント情報、二次元コードから読み取った店舗ＩＤ等をサーバ１１０に送信する。なお、この時点で、サーバ１１０は、ユーザＢのアカウント認証を行ってもよい。

ステップＳ１１１２で、端末１２０Ｃは、ユーザＡ、または、ユーザＢによる支払ボタン等の押下により、ユーザＡ、または、ユーザＢにより注文されたメニューの合計金額である支払額を決定する。

ステップＳ１１１４で、端末１２０Ｃは、ユーザＡ、または、ユーザＢによる支払額の確認ボタン等の押下により、支払リクエストをサーバ１１０に送信する。支払いリクエストには、限定でなく例として、店舗ＩＤや支払額の情報が含まれる。

ステップＳ１１１６で、サーバ１１０の決済事前処理部３０６は、支払いリクエストの受信に応じて、例えば、事前にチェックインしていたユーザの総数をカウントする。なお、事前にユーザの総数は算出されていてもよい。また、サーバ１１０の決済事前処理部３０６は、支払額を総数で除算し、割り勘額を算出する。なお、この時点で、ユーザＡ、および／または、ユーザＢのアカウント認証が行われていなければ、サーバ１１０は、ユーザの未実行のアカウント認証を行ってもよい。また、アカウント認証に失敗したユーザがいる場合、サーバ１１０は、アカウント情報の再入力をユーザにリクエストしてもよい。

ステップＳ１１１８で、サーバ１１０の通信部３０４は、算出された割り勘額を端末１２０Ａに通知する。

ステップＳ１１２０で、サーバ１１０の通信部３０４は、算出された割り勘額を端末１２０Ｂに通知する。

ステップＳ１１２２で、端末１２０Ａの表示制御部５０８は、割り勘額を表示するよう制御した後、端末１２０Ａの決済制御部５１４は、決済リクエストをサーバ１１０に送信するよう通信部５０４に指示する。

ステップＳ１１２４、端末１２０Ｂの表示制御部５０８は、割り勘額を表示するよう制御した後、端末１２０Ｂの決済制御部５１４は、決済リクエストをサーバ１１０に送信するよう通信部５０４に指示する。

ステップＳ１１２６で、サーバ１１０の割り勘処理部３０８は、決済リクエストに応じて、各割り勘対象ユーザのアカウントに関連付けられる各残高から、割り勘額を引き出す。次に、決済処理部３１０は、引き出した各割り勘額の総額（支払額）を、決済情報に関連付けられる店舗ＩＤに示される店舗側に支払う処理を実行する。なお、割り勘処理部３０８は決済処理部３１０に含まれてもよく、この場合、決済処理部３１０は、ユーザＡ、Ｂの残高から割り勘額を引き出し、引き出した割り勘額の合計（支払額）を外部システム１４０（図７に不図示）に登録されている店舗の口座に振り込むようにしてもよい。

ステップＳ１１２８で、サーバ１１０の通信部３０４は、割り勘処理、又は決済処理が完了した後、完了通知をユーザＡの端末１２０Ａに送信する。

ステップＳ１０３０で、サーバ１１０の通信部３０４は、割り勘処理、又は決済処理が完了した後、完了通知をユーザＢの端末１２０Ｂに送信する。

ステップＳ１１３２で、サーバ１１０の通信部３０４は、割り勘処理、又は決済処理が完了した後、完了通知を店舗側の端末１２０Ｃに送信する。

＜＜第２Ｂ実施例＞＞
第１実施形態の第２Ｂ実施例は、第１実施例Ｂにおいて、割り勘対象ユーザが、割り勘額を確認することなく、サーバ１１０は、割り勘処理及び決済処理を行うようにしてもよい。例えば、図１１に示すシーケンスにおいて、ステップＳ１１１８〜Ｓ１１２４が省略されてもよい。

＜＜第２Ｂ実施例の効果＞＞
本実施例によれば、チェックアウト処理において、少なくとも１人のユーザからの決済リクエストが送信されないことによる、決済忘れ、または決済処理の中断を防止することができる。特に、割り勘対象の人数が多い場合に、第２Ｂ実施例は有効である。

＜第２実施形態＞
第２実施形態は、割り勘対象ユーザが決済サービス上で所定の関係がないユーザであっても、支払い対象ユーザは、自身との距離を用いて生成された候補者リストの中から、割り勘対象ユーザを選択することができ、割り勘処理をスムーズに行うとともに、割り勘処理の対象を広げることができる例を示す実施形態である。

第２実施形態において、限定でなく例として、端末１２０は、自端末１２０を利用する第１ユーザから割り勘リクエストを受け付けた場合、第１ユーザとの距離を用いて生成された、割り勘対象ユーザの候補者リストを表示する。端末１２０は、候補者リストの中から、実際に割り勘する第２ユーザの選択を受け付ける。第１ユーザの端末１２０は、選択された第２ユーザの端末１２０に、割り勘処理を行ってよいかの確認リクエストを送信し、確認リクエストを送信した端末１２０から確認結果を受信する。第１ユーザの端末１２０は、第２ユーザから割り勘処理が許可されていれば、割り勘処理や決済処理が実行されるようサーバ１１０に決済リクエストを送信し、決済が完了した場合、決済完了通知を受信する。

＜第２実施形態の効果＞
第２実施形態によれば、支払い対象ユーザと所定の関係を有していないユーザであっても、支払い対象ユーザとの距離を用いて生成された候補者リストを受け取るので、その場で割り勘対象ユーザが選択され、選択された割り勘対象ユーザのアカウントから割り勘額を決済させることが可能になる。例えば、飲み会の幹事が、その飲み会で初めて知り合ったメンバーを、候補者リストの中から容易に選択することができるため、スムーズに割り勘処理や決済処理を実行することが可能になる。

＜第２実施形態のＨＷ構成＞
（１）ＨＷ構成
第２実施形態におけるサーバ１１０、情報処理端末１２０、およびＰＯＳ端末１３０のＨＷ構成は、第１実施形態におけるサーバ１１０、情報処理端末１２０、およびＰＯＳ端末１３０のＨＷ構成と同等であるので、ここでの詳細な説明は省略する。

＜第２実施形態の機能構成＞
（１）サーバの機能構成
図１２は、第２実施形態におけるサーバ１１０の機能構成の一例を示す図である。図１２に開示の機能部は、情報処理装置２００が備えるプロセッサ２０１と、メモリ２０２と、ストレージ２０３と、入出力Ｉ／Ｆ２０４と、通信Ｉ／Ｆ２０５との協働により実現される。

サーバ１１０は、例えば、入出力部１２０２と、通信部１２０４と、決済事前処理部１２０６と、割り勘処理部１２０８と、決済処理部１２１０と、位置特定部１２１２と、リスト作成部１２１４と、記憶部１２１６とを有する。第２実施形態において追加された位置特定部１２１２と、リスト作成部１２１４とは、プロセッサ２０１が、記憶部３１２に格納されているプログラムを読み出して実行することで実現される。第２実施形態におけるサーバ１１０の機能構成において、特に言及しない点は第１実施形態における機能と同一でもよい。

通信部１２０４は、端末１２０から、候補者リストの検索リクエストを受信する受信部として機能する。また、通信部１２０４は、各端末１２０の位置情報を受信する受信部として機能する。また、通信部１２０４は、リスト作成部１２１４にて作成された、ユーザＡの近傍にいるユーザを含む候補者リストを端末１２０に送信する送信部として機能する。また、通信部１２０４は、端末１２０の位置情報として、端末１２０が受信した近距離無線識別子を受信する受信部として機能してもよい。

位置特定部１２１２は、各端末１２０から通知された各端末１２０の位置情報に基づいて、各端末１２０の位置を特定する。例えば、位置特定部１２１２は、端末１２０Ａから、端末１２０Ａの位置を直接示す位置情報（例えば緯度及び経度）を取得した場合、当該位置情報で示される位置を、端末１２０Ａの位置として特定する。

リスト作成部１２１４は、位置特定部１２１２が特定した各端末１２０の位置情報と、各端末１２０のユーザＩＤとを取得し、割り勘対象ユーザの候補者リストを作成する。候補者リストは、取得された位置情報に対応するユーザＩＤ、又はユーザＩＤに関連付けられるニックネームなどを含む。また、リスト作成部１２１４は、限定でなく例として、端末１２０Ａに近い端末１２０を利用するユーザが上から順に画面に表示されるように候補者リストを生成してもよい。また、リスト作成部１２１４は、リスト内のユーザを選択可能にして候補者リストを作成する。リスト作成部１２１４は、作成した候補者リストを、検索リクエストを送信した端末１２０Ａに送信するよう、通信部１２０４に指示する。この指示に応じて、通信部１２０４は、候補者リストを端末１２０Ａに送信する。

（２）端末の機能構成
図１３は、第２実施形態における端末１２０の機能構成の一例を示す図である。図１３に開示の機能部は、情報処理装置２００が備えるプロセッサ２０１と、メモリ２０２と、ストレージ２０３と、入出力Ｉ／Ｆ２０４と、通信Ｉ／Ｆ２０５との協働により実現される。

端末１２０は、入出力部１３０２と、通信部１３０４と、読取部１３０６と、表示制御部１３０８と、決済制御部１３１０と、位置情報測定部１３１２と、リスト作成部１３１４とを有する。第２実施形態において追加された位置情報測定部１３１２と、リスト作成部１３１４とは、プロセッサ２０１が、記憶部１３１６に格納されているプログラムを読み出して実行することで実現される。なお、第２実施形態における端末１２０の機能構成において、特に言及しない点は第１実施形態における機能と同一でもよい。

通信部１３０４は、位置情報測定部１３１２で測定した端末１２０の位置情報を送信する送信部として機能する。また、通信部１３０４は、サーバ１１０から、候補者リストを受信する受信部として機能する。また、通信部１３０４は、他の端末１２０との近距離無線通信を確立するための無線識別子を送信する送信部として機能してもよい。通信部１３０４は、他の端末１２０から無線識別子を受信する受信部として機能してもよい。なお、近距離の無線識別子は、限定ではなく例として、ＢＬＥ（Bluetooth Low Energy）装置が送信するビーコンに含まれるビーコンＩＤ、ＷｉＦｉ（登録商標）装置が送信する無線信号に含まれるＳＳＩＤ、超音波に含まれる任意の識別情報を含んでもよい。

表示制御部１３０８は、通信部１３０４で受信された、又はリスト作成部１３１４で作成された候補者リストを画面に表示する機能を有する。また、表示制御部１３０８は、候補者リスト内のユーザを選択可能に表示するよう制御する。

位置情報測定部１３１２は、端末１２０の現在位置の位置情報を測定する機能を備える。位置情報測定部１３１２は、限定でなく例として、ＧＰＳ（ＧｌｏｂａｌＰｏｓｉｔｉｏｎｉｎｇＳｙｓｔｅｍ）を用いて、端末１２０の現在位置の位置情報として、該端末１２０の緯度および経度を測定する。なお、位置情報測定部１３１２による端末１２０の位置情報の測定は、端末１２０の位置情報を測定できれば、どのような方法を用いてもよい。限定でなく例として、位置情報測定部１３１２は、ＩＭＥＳ（ＩｎｄｏｏｒＭＥｓｓａｇｉｎｇＳｙｓｔｅｍ）、Ｗｉ−Ｆｉ、ＲＦＩＤ（ＲａｄｉｏＦｒｅｑｕｅｎｃｙＩｄｅｎｔｉｆｉｅｒ）、ＮＦＣ（ＮｅａｒＦｉｅｌｄＣｏｍｍｕｎｉｃａｔｉｏｎ）、ＢＬＥ（ＢｌｕｅｔｏｏｔｈＬｏｗＥｎｅｒｇｙ）、超音波などの近距離無線通信、ＬＴＥやＣＤＭＡなどの移動体通信システムなどを利用して、端末１２０の位置情報を測定してもよい。

リスト作成部１３１４は、通信部１３０４により無線通信が確立された他の端末１２０との位置情報に基づいて、割り勘対象ユーザの候補者リストを作成する。候補者リストは、取得された無線識別子に対応するユーザＩＤ、又はユーザＩＤに関連付けられるニックネームなどを含む。また、リスト作成部１３１４は、限定でなく例として、端末１２０Ａに近い端末１２０を利用するユーザが上から順に画面に表示されるように候補者リストを生成してもよい。また、リスト作成部１３１４は、リスト内のユーザを選択可能にして候補者リストを作成する。リスト作成部１３１４は、端末１２０同士の近さの判断について、無線通信の信号強度を用いる。例えば、リスト作成部１３１４は、確立された無線通信の信号強度が大きければ大きいほど、その端末同士は近いと判断可能である。

＜第２実施形態の動作処理＞
図１４を参照し、第２実施形態に係る通信システム１の処理について説明する。図１４は、第２実施形態に係る通信システム１が行う処理手順のシーケンスの一例を示す図である。図１４に示す処理は、ＧＰＳなどの端末１２０の位置情報を用いて、ユーザ同士、又は端末１２０同士の位置関係が把握される例である。

ステップＳ１４０２で、端末１２０Ａの入出力部５０２は、ユーザから、決済画面において割り勘を選択するボタンの押下（タップ）を受け付ける。

ステップＳ１４０４で、端末１２０Ａの位置情報測定部１３１２は、自身の位置情報を測定する。端末１２０Ａの位置情報測定部１３１２は、サーバ１１０に位置情報の検索リクエストを送信するよう通信部１３０４に指示する。検索リクエストは、例えば端末１２０Ａの位置情報とともに送信されてもよいし、それぞれは別々に送信されてもよい。

ステップＳ１４０６で、端末１１０Ｂの位置情報測定部１３１２は、自身の位置情報を測定し、測定した位置情報と、端末１１０Ｂを利用するユーザのユーザＩＤとをサーバ１１０に送信するよう通信部１３０４に指示する。

ステップＳ１４０８で、端末１１０Ｃの位置情報測定部１３１２は、自身の位置情報を測定し、測定した位置情報と、端末１１０Ｃを利用するユーザのユーザＩＤとをサーバ１１０に送信するよう通信部１３０４に指示する。なお、ステップＳ１４０４、Ｓ１４０６、Ｓ１４０８で送信される位置情報は、定期的に各端末１２０からサーバ１１０に送信されるようにしてもよいし、サーバ１１０からの指示に基づき、位置情報が各端末１２０からサーバ１１０に送信されるようにしてもよい。

ステップＳ１４１０で、サーバ１１０のリスト作成部１２１４は、各端末１２０から取得した位置情報に基づき、割り勘対象ユーザの候補者リストを作成する。例えば、サーバ１１０のリスト作成部１２１４は、端末１２０Ａの位置に近い順に、ユーザＩＤ、又はユーザＩＤに関連付けられるニックネームなどを含むようにする。

ステップＳ１４１２で、サーバ１１０の通信部１２０４は、リスト作成部１２１４により作成された候補者リストを、検索リクエスト送信した端末１２０Ａに送信する。

ステップＳ１４１４で、端末１２０Ａの表示制御部１３０８は、サーバ１１０から取得された候補者リストを、表示画面に表示するよう制御する。このとき、候補者リスト内の各ユーザは、選択可能に表示される。

ステップＳ１４１６で、端末１２０Ａの入出力部１３０２は、候補者リストの表示画面から、割り勘対象ユーザを選択する指示を受け付ける。例えば、候補者リスト内のユーザにラジオボタンなどの選択可能なＵＩ（User Interface）部品が表示される場合、ユーザＡが、実際の割り勘対象ユーザについて、ＵＩ部品を押下するなどして選択することを、入出力部１３０２が受け付ける。なお、この例では、ユーザＢが割り勘対象として選択されたとする。

ステップＳ１４１８で、端末１２０Ａの通信部１３０４は、候補者リスト内でユーザＡにより選択された割り勘対象ユーザ（図１４に示す例ではユーザＢ）に、割り勘リクエストを送信する。

ステップＳ１４２０で、端末１２０Ｂの表示制御部１３０８は、割り勘リクエストの受信に応じて、割り勘を許可するか拒否するかの選択画面を表示画面に表示するよう制御する。

ステップＳ１４２２で、端末１２０Ｂの通信部１３０４は、ユーザＢが選択画面から許可を選択したことに応じて、許可通知をサーバ１１０に送信する。これにより、ユーザＢの許可通知をユーザＢの端末１２０Ｂからサーバ１１０に送信することで、許可の信憑性を高めることができる。なお、ユーザＢが割り勘を拒否した場合は、ユーザＡ単独の決済処理や他のユーザとの割り勘処理が行われる（図１４に不図示）。

ステップＳ１４２４で、サーバ１１０は、ユーザＢが割り勘を許可したことを検知すると、ユーザＢの許可通知を、端末１２０Ａに送信する。

ステップＳ１４２６で、端末１２０Ａの通信部１３０４は、ユーザＢからの許可通知を受信すると、決済リクエストをサーバ１１０に送信する。決済リクエストは、割り勘額又は支払額、及び支払先である店舗ＩＤを含み、割り勘の対象となるユーザＡのユーザＩＤとユーザＢのユーザＩＤとをさらに含んでもよい。なお、割り勘額は端末１２０Ａを使用するユーザＡによって、ユーザ毎に設定されても良い。

ステップＳ１４２８で、サーバ１１０の割り勘処理部１２０８及び決済処理部１２１０は、決済リクエストに含まれる情報に基づいて、支払先を特定し、上述したユーザＡとユーザＢとの割り勘処理、店舗等への決済処理を実行する。ステップＳ１４２８では、割り勘処理と、決済処理との順序は問わない。例えば、先に、ユーザＢのアカウントから割り勘額を引き出し、ユーザＡの残高に振り込んだ後で、ユーザＡから支払額を店舗の口座に振り込んでもよい。また、先に、ユーザＡのアカウントから支払額を店舗の口座に振り込んだ後で、ユーザＢの残高から割り勘額を減算し、ユーザＡの残高に加算するようにしてもよい。

ステップＳ１４３０で、サーバ１１０の決済処理部１２１０は、支払先である店舗ＩＤに関連付けられる店舗口座を保持する外部システム１４０に、支払額を支払う処理を行う。

ステップＳ１４３２で、外部システム１４０は、支払いが完了すると、支払い完了通知をサーバ１１０に送信する。

ステップＳ１４３４で、サーバ１１０の通信部１２０４は外部システム１４０から支払完了通知を受信すると、端末１２０Ａに決済完了通知を送信する。

ステップＳ１４３６で、サーバ１１０の通信部１２０４は外部システム１４０から支払完了通知を受信すると、端末１２０Ｂに決済完了通知を送信する。ステップＳ１４３４、及びＳ１４３６は、その順序について問わない。

なお、ステップＳ１４２２の許可通知は、端末１２０Ｂから端末１２０Ａに送信されてもよい。この場合、ステップＳ１４２４は不要であり、ステップＳ１４２６において決済リクエストに、許可をした割り勘対象ユーザのユーザＩＤが含まれる。これにより、サーバ１１０を介するステップを減らすことで、より迅速な割り勘処理を実現することが可能になる。

なお、ステップＳ１４０４からステップＳ１４１４までの候補者リスト生成処理及び表示処理は、Ｓ１４５０として表記される。このステップＳ１４５０の別の処理について、図１５を用いて説明する。

図１５は、第２実施形態に係る各端末１２０が行う候補者リストの作成および表示に関する処理手順のシーケンスの一例を示す図である。図１５に示す処理は、各端末１２０が近距離無線通信を用いて、ユーザ同士、又は端末１２０同士の位置関係が把握される例である。図１５に示す例では、限定でなく例として、ＢＬＥを用いてセッションを確立するが、超音波、Ｗｉ−Ｆｉなどのその他の無線通信を用いてセッションが確立されてもよい。

ステップＳ１５０２で、端末１２０Ａの通信部１３０４は、ＢＬＥを用いて、通信可能な範囲内に存在する端末１２０Ｂとセッションを確立する。

ステップＳ１５０４で、端末１２０Ａの通信部１３０４は、ＢＬＥを用いて、通信可能な範囲内に存在する端末１２０Ｃとセッションを確立する。

ステップＳ１５０６で、端末１２０Ａのリスト作成部１３１４は、端末１２０Ａとセッションを確立した各端末に基づいて、割り勘対象ユーザの候補者リストを作成する。例えば、端末１２０Ａのリスト作成部１３１４は、端末１２０Ａとの無線通信における信号強度を用いて、信号強度が強いほど、端末１２０Ａに近いと判断し、端末１２０Ａに近い順に候補者リストを作成してもよい。また、端末１２０Ａのリスト作成部１３１４は、候補者リストに、ユーザＩＤ、又はユーザＩＤに関連付けられるニックネームなど（以下、ユーザＩＤ等とも称す。）を含むようにしてもよい。

ステップＳ１５０８で、端末１２０Ａの表示制御部１３０８は、リスト作成部１３１４が作成した候補者リストを、表示画面に表示するよう制御する。このとき、候補者リスト内の各ユーザは、選択可能に表示される。以降の処理は、図１４に示すステップＳ１４１６と同様である。

これにより、近距離無線通信を用いても、ユーザＡの近傍にいる割り勘対象のユーザを含む候補者リストの作成が可能になる。ＧＰＳを用いて位置情報が取得できない場合等に、本実施例では近距離無線通信を用いることで、適切に候補者リストを作成することができる。

なお、図１４に示すＧＰＳを用いた各端末の位置情報の取得と、近距離無線通信を用いた各端末の位置情報の取得とを適宜組み合わせてもよい。限定でなく例として、ＧＰＳを用いた位置情報の取得が優先的に行われ、候補者リストが生成される。次に、ユーザＡが、候補者リスト内にいるはずのユーザ（例、ユーザＢ）がいないことに気づいた場合、近距離無線通信による候補者リスト作成を指示する。例えば、候補者リストの表示画面内に、近距離無線通信の実行ボタン等が設けられれば良い。また、候補者リスト内にいるはずのユーザとは、例えば、ユーザＡは、同席しているユーザＢの存在に気付いているが、候補者リスト内にユーザＢが含まれていないことをいう。この状況は、各端末のユーザが、アプリケーションの設定においてＧＰＳの位置情報を出力することを許可していない場合等に起こりうる。

ユーザＡが、候補者リストの表示画面等から近距離無線通信の実行を指示すると、端末１２０Ａの入出力部１３０２が近距離無線通信の実行を検知し、端末１２０Ａの通信部１３０４により近距離無線通信が実行される。このとき、端末１２０Ａのリスト作成部１３１４は、近距離無線通信を用いて新たにユーザＩＤ等を取得した場合、候補者リスト内に、取得された新たなユーザＩＤ等を追加する。端末１２０Ａのリスト作成部１３１４は、既に候補者リストに含まれるユーザＩＤ等を再度取得した場合、一方を破棄するようにすればよい。

これにより、ＧＰＳを用いた位置情報の取得と、近距離無線通信を用いた位置情報の取得とを組み合わせることで、候補者リスト内に、より適切に割り勘対象ユーザを含めることができるようになる。

＜第２実施形態の端末に係るコード決済時の表示態様＞
図１６は、第２実施形態に係る端末１２０Ａに表示される画面の一例を示す図である。図１６（Ａ）は、支払額及び割り勘選択ボタンを含む決済画面の一例を示している。図１６（Ａ）に示す決済画面は、支払額の表示項目、及び割り勘の選択ボタンを少なくとも含む。図１６（Ａ）に示す決済画面は、例えば、図１４に示すステップＳ１４０２の処理で表示される画面に対応する。図１６（Ａ）に示す画面で、ユーザがＹＥＳを押下した場合、図１４に示すステップＳ１４０４の処理が実行され、ユーザがＮＯを押下した場合、単独での決済リクエストがサーバ１１０に送信される（図１４に不図示）。

図１６（Ｂ）は、候補者リストを表示する画面の一例を示している。図１６（Ｂ）に示す画面は、サーバ１１０のリスト作成部１２１４、または端末１２０Ａのリスト作成部１３１４により作成された候補者リストを含む。図１６（Ｂ）に示す例では、ユーザＢとユーザＣとが候補者リスト内に表示され、それぞれ選択可能なラジオボタンＲが表示される。候補者リスト内に表示される名称は、ユーザがアプリケーションで設定しているニックネームや、ユーザＩＤ、氏名等、ユーザ管理ＤＢに登録されているユーザを識別できる情報であればよい。図１６（Ｂ）に示す画面は、例えば、図１４に示すステップＳ１４１４の処理で表示される画面に対応する。

図１６（Ｃ）は、割り勘許可の待ち画面の一例を示している。図１６（Ｃ）に示す画面は、ユーザＢが割り勘を未だ許可していない状況を示す。例えば、図１６（Ｃ）に示す画面は、図１４に示すステップＳ１４１８からＳ１４２２までの間に、端末１２０Ａに表示される画面に対応する。

図１６（Ｄ）は、割り勘許可の通知画面の一例を示している。図１６（Ｄ）に示す画面は、図１４に示すステップＳ１４２４で端末１２０Ａの通信部１３０４が許可通知を受信した後、端末１２０Ａの表示制御部１３０８が、図１６（Ｄ）に示す画面を表示するよう制御する。図１６（Ｄ）に示す画面で、ユーザＡがＹＥＳを押下した場合、ステップＳ１４２６の処理が実行され、ユーザＡがＮＯを押下した場合、所定の処理に戻ってもよい。所定の処理とは、限定でなく例として、ステップＳ１４１４における候補者リスト選択などである。図１６（Ｄ）に示す画面は、例えば、図１４に示すステップＳ１４２４の処理の後に表示される画面に対応する。

図１６（Ｅ）は、決済完了画面の一例を示している。図１６（Ｅ）に示す画面は、店舗への支払いと、割り勘とが完了したことをユーザＡに通知する画面の例である。図１６（Ｅ）に示す画面は、図１４に示すステップＳ１４３４の処理が行われた後、端末１２０Ａの表示画面に表示されてもよい。

＜＜第１実施例＞＞
第２実施形態の第１実施例は、候補者リストの表示について、支払対象ユーザの位置と候補者リスト内のユーザの位置とに応じて、支払い対象ユーザを中心に、同心円状にリスト内のユーザを表示する。例えば、サーバ１１０のリスト作成部１２１４は、位置特定部１２１２により特定された各端末１２０の位置情報を用いて、同心円状に、各端末１２０の位置に基づいて各ユーザを配置する。候補者リスト表示は、ＧＰＳを用いた位置情報が取得される場合に適用可能である。

＜＜第１実施例の効果＞＞
本実施例によれば、ユーザは、候補者リストを見る際に、どの位置にどのユーザがいるかを、実際のユーザの着席位置に対応して容易に把握することができ、候補者リストの中から割り勘対象ユーザを容易に特定することができる。

＜＜第１実施例の端末に係る候補者リストの表示態様＞＞
図１７は、第１実施例に係る端末１２０Ａに表示される候補者リストの表示画面の一例を示す図である。図１７に示す例では、支払い対象ユーザＵＡを中心に、同心円状に候補者リスト内の各位置にユーザ（例、ユーザＢ、ユーザＣ、ユーザＤ）が表示される。なお、図１７に示す放射線状に表示される点線の円は、所定距離ごとに表示される。例えば、所定距離は、設定画面などから、３ｍ、５ｍなどの距離をユーザが適宜変更できるように設計される。また、図１７に示す候補者リストは、ドラッグなどのユーザ操作により、マップ操作のように位置をずらしたり、ピンチアウトなどのユーザ操作により、縮尺を変更したりして表示されてもよい。

＜＜第２実施例＞＞
第２実施形態の第２実施例は、支払い対象ユーザＡの端末１２０Ａの決済制御部１３１０が、サーバ１１０に決済リクエストを送信する際に、ユーザごとに、ユーザＩＤと割り勘額とを含む決済リクエストを送信する。サーバ１１０の通信部１２０４が、ユーザごとの決済リクエストを受信し、決済処理部１２１０及び決済処理部１２１０が、ユーザごとに、店舗の口座に割り勘額を支払う処理を実行する。サーバ１１０は、決済完了を通知する際には、領収書としての形式にしたがって、各ユーザの端末１２０に決済完了の通知を行う。領収書としての形式とは、限定でなく例として、日付、宛名、金額、但し書き、店名、店の押印などの項目を含む。

＜＜第２実施例の効果＞＞
本実施例によれば、各ユーザは、自身の領収書を受領することができるため、割り勘額を経費として支出することが可能になる。

＜＜第２実施例の端末に係る決済完了通知の表示態様＞＞
図１８は、第２実施例に係る端末１２０に表示される決済完了通知の表示画面の一例を示す図である。図１８（Ａ）に示す例では、ユーザＡの決済完了通知が端末１２０Ａの表示画面に表示される。図１８（Ａ）に示す決済完了通知は、限定でなく例として、日付、宛名、金額、但し書き、店名などを含む。

図１８（Ｂ）に示す例では、ユーザＢの決済完了通知が端末１２０Ｂの表示画面に表示される。図１８（Ｂ）に示す決済完了通知は、限定でなく例として、日付、宛名、金額、但し書き、店名などを含む。

また、この決済完了通知には、店舗の印鑑を示す電子スタンプが付与されてもよい。電子スタンプについては、サーバ１１０が、店舗ＩＤなどに関連付けて保持しておく。サーバ１１０は、外部システム１４０から支払の完了通知を受信した際に、この電子スタンプを読みだして、決済完了通知に付与してもよい。

また、宛名については、ユーザごとに事前にサーバ１１０に登録されていてもよい。例えば、ユーザ管理ＤＢのユーザＩＤごとに、決済完了通知用の宛名の項目を設け、氏名や会社名などを事前にユーザに登録させておいてもよい。また、決済リクエストを通知する際、または割り勘処理を許可する際などに、宛名、および／または但し書きを、その都度ユーザに入力させるようにしてもよい。各端末１２０の表示制御部１３０８は、宛名、および／または但し書きを入力するためのＵＩ部品を表示画面に表示し、このＵＩ部品に入力された宛名、および／または、但し書きを、決済ＩＤなどに関連付けてサーバ１１０に送信する。サーバ１１０は、受信した宛名、および／または、但し書きを保持しておき、決済完了通知を各端末１２０に送信する際、保持しておいた宛名、および／または、但し書きを決済完了通知に含める。これにより、各ユーザは、領収書にもなりうる決済完了通知を受領することが可能になる。

＜＜第３実施例＞＞
第２実施形態の第３実施例は、サーバ１１０が候補者リストを作成する際に、割り勘対象ユーザに対して、ユーザ情報（例、ユーザＩＤなど）の送信可否を確認するようにする。例えば、サーバ１１０は、割り勘対象ユーザの候補者リストを作成する前に、ユーザ情報の送信の可否を、割り勘対象ユーザに問い合わせるようにする。例えば、サーバ１１０は、図１４に示すステップＳ１４０６、およびステップＳ１４０８の処理の後に、各端末（例、端末１２０Ｂおよび端末１２０Ｃ）に、ユーザ情報の送信の可否を問い合わせる。サーバ１１０のリスト作成部１２１４は、各端末からユーザ情報の送信の可否を取得し、送信許可がなされたユーザを候補者リストに含めるようにする。

＜＜第３実施例の効果＞＞
本実施例によれば、各ユーザは、自身のユーザ情報を他のユーザに教えるか否かを決定することができるので、無断でユーザ情報が他の端末に送信されることを防止することができ、セキュリティの向上を図ることができる。なお、各ユーザは、アプリケーションの設定画面などで、自身のユーザ情報を許可なしで送信する、その都度送信の可否を問い合わせる、または、ユーザ情報の送信を許可しない、を事前に選択しておいてもよい。これにより、ユーザ情報の送信の可否、および／または、問い合わせタイミングをユーザの希望に合わせることが可能になる。サーバ１１０は、事前に設定された、ユーザ情報の送信設定を、ユーザ管理ＤＢのユーザＩＤに関連付けて記憶しておいてもよい。

１通信システム、１００通信システム、１１０サーバ、１１０Ａサーバ、１１０Ｂサーバ、１２０端末、１２０Ａ端末、１２０Ｂ端末、１２０Ｃ端末、１２０Ｘ端末、１３０端末、１３０ＡＰＯＳ端末、１３０ＢＰＯＳ端末、２００情報処理装置、２０１プロセッサ、２０２メモリ、２０３ストレージ、２０４入出力インタフェース（入出力Ｉ／Ｆ）、２０５通信インタフェース（通信Ｉ／Ｆ）、３０２入出力部、３０４通信部、３０６決済事前処理部、３０８割り勘処理部、３１０決済処理部、３１２記憶部、５０２入出力部、５０４通信部、５０６生成部、５０８表示制御部、５１０取得部、５１２調整部、５１４決済制御部、５１６読み取り部

Claims

情報処理装置に、
支払額を含む第１情報コードを表示画面に表示制御するステップと、
前記第１情報コードを読み取った各情報処理装置によって送信されたアカウント情報を受信したサーバにより処理される決済事前処理に基づき、受信された各アカウント情報の数に基づき算出された割り勘対象ユーザの総数と前記支払額の少なくとも一部とを用いて算出された割り勘額を取得するステップと、
前記割り勘額を用いる割り勘処理を含む決済処理を前記サーバに実行させる契機となる第２情報コードであって、前記第１情報コードと同一の前記第２情報コード又は前記第１情報コードとは異なる前記第２情報コードを前記表示画面に表示制御するステップと、
前記決済処理又は前記割り勘処理の完了通知を前記サーバから受信するステップと、を実行させるプログラム。
前記情報処理装置に、
前記サーバの前記決済事前処理に応じて送信された各アカウント情報を受信するステップをさらに実行させ、
前記割り勘額を取得するステップは、
受信された前記各アカウント情報に基づいて前記割り勘対象ユーザの総数を算出するステップと、
前記支払額の少なくとも一部と前記総数とを用いて前記割り勘額を算出するステップと、を含む、請求項１に記載のプログラム。
前記情報処理装置に、
前記第１情報コードの生成補助画面を前記表示画面に表示制御するステップと、
前記生成補助画面に対するユーザ操作に基づいて、前記支払額の入力を受け付けるステップと、
入力された前記支払額を含む前記第１情報コードを生成するステップと、をさらに実行させ、
前記第１情報コードを表示制御するステップは、
生成された前記第１情報コードを前記表示画面に表示制御するステップを含む、請求項１又は２に記載のプログラム。
前記情報処理装置に、
前記総数を調整する調整画面を前記表示画面に表示制御するステップと、
前記調整画面に対するユーザ操作に基づいて、調整された総数を受け付けるステップと、をさらに実行させ、
前記割り勘額を取得するステップは、
前記調整された総数と前記支払額の少なくとも一部とを用いて割り勘額を算出するステップを含む、請求項１から３のいずれか一項に記載のプログラム。
前記情報処理装置に、
前記割り勘額の取得後に、割り勘対象ユーザの残高が前記割り勘額以上であるか否かを確認する確認リクエストを前記サーバに送信するステップと、
前記サーバから、前記確認リクエストに対する確認結果を受信するステップと、をさらに実行させる、請求項１から４のいずれか一項に記載のプログラム。
前記情報処理装置に、
前記情報処理装置を利用する第１ユーザと、前記各情報処理装置を利用する他の各ユーザとに所定の関係がある場合に、当該所定の関係があるユーザの情報の少なくとも一部を、当該所定の関係がないユーザの情報の少なくとも一部とは異なる態様で、前記表示画面に表示制御するステップと、をさらに実行させる、請求項１に記載のプログラム。
前記決済処理が、前記割り勘処理よりも後に実行される場合、
前記完了通知を受信するステップは、
前記割り勘処理の完了通知を受信するステップと、
前記割り勘処理の完了通知の受信後に、前記決済処理の完了通知を受信するステップと、を含む、請求項１から６のいずれか一項に記載のプログラム。
前記決済処理が、前記割り勘処理よりも前に実行される場合、
前記完了通知を受信するステップは、
前記決済処理の完了通知を受信するステップと、
前記決済処理の完了通知の受信後に、前記割り勘処理の完了通知を受信するステップと、を含む、請求項１から６のいずれか一項に記載のプログラム。
前記第１情報コードと前記第２情報コードとは、同一の情報コードである、請求項１から８のいずれか一項に記載のプログラム。
情報処理装置に、
店舗に対応づけられた決済情報を含む情報コードを読み取るステップと、
前記情報コードに含まれる前記決済情報と、前記情報処理装置を利用する第１ユーザのアカウント情報とをサーバに送信するステップと、
前記情報コードを読み取った各情報処理装置によって送信されたアカウント情報を受信したサーバにより処理される決済事前処理に基づき、受信された各アカウント情報に基づき算出された総数と前記決済情報に関連づけられた支払額の少なくとも一部とを用いた算出された割り勘額を取得するステップと、
前記割り勘額を用いる割り勘処理を含む決済処理をリクエストする決済リクエストを前記サーバに送信するステップと、
前記決済処理又は前記割り勘処理の完了通知を前記サーバから受信するステップと、を実行させるプログラム。
前記割り勘額を取得するステップは、
前記サーバにより算出された前記割り勘額を受信するステップを含み、
前記割り勘額は、前記情報処理装置に表示された前記情報コードを読み取った前記各情報処理装置のアカウント情報の数に基づき算出された前記総数と前記情報コードに含まれる前記支払額の少なくとも一部とを用いて算出される、請求項１０に記載のプログラム。
前記決済情報は、前記店舗を支払先とする支払先識別情報を含み、
前記情報処理装置に、
前記情報コードに含まれる前記支払先識別情報と、前記情報処理装置を利用する第１ユーザのアカウント情報とを前記サーバに送信するステップをさらに実行させ、
前記割り勘額を取得するステップは、
前記情報処理装置から支払額を含む支払リクエストを受信した前記サーバから、前記支払額に基づいて算出された割り勘額を受信するステップを含む、請求項１０に記載のプログラム。
前記割り勘額を取得するステップは、
前記支払額を前記総数で割り切れないとき、各ユーザの割り勘額に対する端数処理を実行するステップを含む、請求項１又は１０に記載のプログラム。
前記端数処理は、
前記支払額を前記総数で割り切れないときの各ユーザの商の端数を、切り上げ又は切り捨てることにより、各ユーザの割り勘額を決定する処理を含む、請求項１３に記載のプログラム。
前記端数処理は、
前記支払額を前記総数で割り切れないときの各ユーザの商の端数を切り捨てて各ユーザの割り勘額を決定する処理を含み、
前記サーバにより、前記支払額から前記各ユーザの前記割り勘額の合計を減算した金額を、前記支払額から割り引く処理が実行される、請求項１３に記載のプログラム。
前記端数処理は、
前記支払額を前記総数で割り切れないときの各ユーザの商の端数を切り上げて各ユーザの割り勘額を決定する処理を含み、
前記サーバにより、前記各ユーザの前記割り勘額の合計から前記支払額を減算した金額を決済業者に支払う処理が実行される、請求項１３に記載のプログラム。
支払額を含む情報コードを読み取った各情報処理装置から送信された各アカウント情報を受信する第１受信部と、
前記各アカウント情報の受信に応じて、前記各アカウント情報の総数と前記支払額の少なくとも一部とに基づく割り勘額を決定するための決済事前処理を行う決済事前処理部と、
少なくとも１つの前記情報処理装置に表示された前記情報コードを読み取った情報読取装置によって送信された決済リクエストを受信する第２受信部と、
前記決済リクエストに含まれる店舗情報に示される店舗に前記支払額を、前記決済リクエストを送信した前記情報処理装置を利用する第１ユーザのアカウントから支払う決済処理を行う決済処理部と、
前記第１ユーザのユーザ情報以外の各アカウント情報に関連付けられる各ユーザのアカウントから、前記割り勘額を、前記第１ユーザに支払う処理を行う割り勘処理部と、
前記決済処理が完了した場合、前記決済処理の完了通知を前記第１ユーザの前記情報処理装置に送信する送信部と、を備えるサーバ。
サーバが実行する情報処理方法であって、
支払額を含む情報コードを読み取った各情報処理装置から送信された各アカウント情報を受信するステップと、
前記各アカウント情報に受信に応じて、前記各アカウント情報の総数と前記支払額の少なくとも一部とに基づく割り勘額を決定するためのアカウント処理を行うステップと、
少なくとも１つの前記情報処理装置に表示された前記情報コードを読み取った情報処理装置によって送信された決済リクエストを受信するステップと、
前記決済リクエストに含まれる店舗情報に示される店舗に前記支払額を、前記決済リクエストを送信した前記情報処理装置を利用する第１ユーザのアカウントから支払う決済処理を行うステップと、
前記第１ユーザのユーザ情報以外の各アカウント情報に関連付けられる各ユーザのアカウントから、前記割り勘額を、前記第１ユーザに支払う処理を行うステップと、
前記決済処理が完了した場合、前記決済処理の完了通知を前記第１ユーザの前記情報処理装置に送信するステップと、を含む情報処理方法。
店舗に対応づけられた決済情報を含む情報コードを読み取った各情報処理装置によって送信されたアカウント情報を受信する第１受信部と、
前記各アカウント情報に受信に応じて、前記各アカウント情報の総数と前記決済情報に関連付けられる支払額の少なくとも一部とに基づく割り勘額を決定するための決済事前処理を行う決済事前処理部と、
前記情報処理装置から送信された前記支払額及び前記店舗の店舗情報を含む決済リクエスト、又は前記情報処理装置から送信された前記割り勘額及び前記店舗情報を含む決済リクエストを受信する第２受信部と、
前記決済リクエストに含まれる店舗情報に示される店舗に前記支払額を支払う決済処理と、前記各アカウント情報に関連付けられる各ユーザの前記割り勘額に対応する割り勘処理とを行う決済、割り勘処理部と、
前記決済処理又は割り勘処理が完了した場合、前記決済処理又は前記割り勘処理の完了通知を各情報処理装置に送信する送信部と、を備えるサーバ。
サーバが実行する情報処理方法であって、
店舗に対応づけられた決済情報を含む情報コードを読み取った各情報処理装置によって送信されたアカウント情報を受信するステップと、
前記各アカウント情報に受信に応じて、前記各アカウント情報の総数と前記決済情報に関連付けられる支払額の少なくとも一部とに基づく割り勘額を決定するための決済事前処理を行うステップと、
前記情報処理装置から送信された前記支払額及び前記店舗の店舗情報を含む決済リクエスト、又は前記情報処理装置から送信された前記割り勘額及び前記店舗情報を含む決済リクエストを受信するステップと、
前記決済リクエストに含まれる店舗情報に示される店舗に前記支払額を支払う決済処理と、前記各アカウント情報に関連付けられる各ユーザの前記割り勘額に対応する割り勘処理とを行うステップと、
前記決済処理又は割り勘処理が完了した場合、前記決済処理又は前記割り勘処理の完了通知を各情報処理装置に送信するステップと、を含む情報処理方法。