<法令遵守>
本明細書に記載の開示は、実施される場合、本開示を実施する各国の法令を遵守のうえで実施される。また、本明細書に記載の開示は、各国の法令を遵守するために必要な、当業者が成し得る全ての変更、置換、変形、改変、および修正をもって実施される。
本開示に係るプログラム、情報処理方法、および情報処理装置を実施するための形態について、図面を参照して説明する。
<システム構成>
図1は、本開示の一実施形態に係る通信システム1の構成を示す。図1に開示されるように、通信システム1では、ネットワーク125を介してサーバ110A、サーバ110Bと、端末120A、端末120B、端末120Cと、POS(Point of Sales)端末130A、POS端末130Bと、外部システム140とが接続される。外部システム140は、限定でなく例として、他の事業者(金融機関、クレジットカード会社など)や他の事業部門によって運営されるサーバなどによって構築される。
本開示において、サーバ110Aと、サーバ110Bとをそれぞれ区別する必要がない場合は、サーバ110Aとサーバ110Bとは、それぞれサーバ110と表現されてもよい。
本開示において、端末120Aと、端末120Bと、端末120Cとをそれぞれ区別する必要がない場合は、端末120Aと端末120Bと端末120Cとは、それぞれ端末120と表現されてもよい。
本開示において、サーバ110と、端末120とをそれぞれ区別する必要がない場合は、サーバ110と端末120とは、それぞれ情報処理装置200と表現されてもよい。なお、ネットワーク125に接続される情報処理装置200の数は限定されない。
サーバ110は、ネットワーク125を介してユーザが利用する端末120に、所定のサービスを提供する。所定のサービスは、限定でなく例として、決済サービス、金融サービス、電子商取引サービス、インスタントメッセンジャーを代表とするSNS(Social Networking Service)、楽曲・動画・書籍などのコンテンツ提供サービス等を含む。ユーザが端末120を介して所定のサービスを利用することで、サーバ110は1以上の端末120に所定のサービスを提供することができる。
本開示において、決済サービスとは1以上のユーザが金銭または金銭相当物の授受ができるサービスを意味する。限定でなく例として、一次元コード(バーコードなど)、二次元コード(QRコード(登録商標)など)、近距離無線通信(NFC、BLE、WI-FI、超音波など)を利用して決済を行うサービスを含む。また、必要に応じて一次元コード、または、二次元コードなどの情報コードを利用した決済において、支払いを行うユーザが情報コードを読み取ることで決済を行うことを「ユーザ読取型コード決済」と表現し、支払いを行うユーザが情報コードを表示し、それを請求ユーザ(または店舗)が読み取ることで決済を行うことを「店舗読取型コード決済」と表現する。
必要に応じて、ユーザXが利用する端末を端末120Xと表現し、ユーザXまたは端末120Xに対応づけられた、所定のサービスにおけるユーザ情報をユーザ情報Xと表現する。なお、ユーザ情報とは、所定のサービスにおいてユーザが利用するアカウントに対応付けられたユーザの情報である。ユーザ情報は、限定でなく例として、ユーザにより入力される、または、所定のサービスにより付与される、ユーザの名前、ユーザのアイコン画像、ユーザの年齢、ユーザの性別、ユーザの住所、ユーザの趣味趣向、ユーザの識別子などのユーザに対応づけられた情報、ユーザに対応付けられた電子バリュー(電子マネー)の残高情報、ユーザに対応付けられたクレジットカード情報(クレジットカード番号など)を含み、これらのいずれか一つまたは、組み合わせであってもよい。
ネットワーク125は、2以上の情報処理装置200を接続する役割を担う。ネットワーク125は、端末120がサーバ110に接続した後、データを送受信することができるように接続経路を提供する通信網を意味する。
ネットワーク125のうちの1つまたは複数の部分は、有線ネットワークや無線ネットワークであってもよい。ネットワーク125は、限定でなく例として、アドホック・ネットワーク(Ad Hoc Network)、イントラネット、エクストラネット、仮想プライベート・ネットワーク(Virtual Private Network:VPN)、ローカル・エリア・ネットワーク(Local Area Network:LAN)、ワイヤレスLAN(Wireless LAN:WLAN)、広域ネットワーク(Wide Area Network:WAN)、ワイヤレスWAN(Wireless WAN:WWAN)、大都市圏ネットワーク(Metropolitan Area Network:MAN)、インターネットの一部、公衆交換電話網(Public Switched Telephone Network:PSTN)の一部、携帯電話網、ISDNs(Integrated Service Digital Networks)、無線LANs、LTE(Long Term Evolution)、CDMA(Code Division Multiple Access)、ブルートゥース(Bluetooth(登録商標))、衛星通信など、または、これらの2つ以上の組合せを含むことができる。ネットワーク125は、1つまたは複数のネットワーク125を含むことができる。
情報処理装置200は、本開示に記載される機能、および/または、方法を実現できる情報処理装置であればどのような情報処理装置であってもよい。
情報処理装置200は、限定ではなく例として、スマートフォン、携帯電話(フィーチャーフォン)、コンピュータ(限定でなく例として、デスクトップ、ラップトップ、タブレットなど)、サーバ装置、メディアコンピュータプラットホーム(限定でなく例として、ケーブル、衛星セットトップボックス、デジタルビデオレコーダなど)、ハンドヘルドコンピュータデバイス(限定でなく例として、PDA(Personal Digital Assistant)、電子メールクライアントなど)、ウェアラブル端末(限定でなく例として、メガネ型デバイス、時計型デバイスなど)、他種のコンピュータ、またはコミュニケーションプラットホームを含む。
POS端末130は、店舗にて、ユーザ(顧客)からの支払いを受け取るユーザ(店員等)が利用する端末であり、二次元コードリーダーを備えており、読み取った二次元コードをサーバ110に送信する機能を有している。二次元コードリーダーは、一次元コードリーダーや、三次元コードリーターでもよい。また、一次元コード、及び二次元コード、三次元コードを含む多次元コードは、本開示において情報コードと呼ばれてもよい。
<ハードウェア(HW;HardWare)構成>
図2を用いて、通信システム1に含まれる情報処理装置200及びPOS端末130のHW構成について説明する。
情報処理装置200は、プロセッサ201と、メモリ202と、ストレージ203と、入出力インタフェース(入出力I/F)204と、通信インタフェース(通信I/F)205とを含む。情報処理装置200のHWの各構成要素は、限定でなく例として、バスBを介して相互に接続される。
情報処理装置200は、プロセッサ201と、メモリ202と、ストレージ203と、入出力I/F204と、通信I/F205との協働により、本開示に記載される機能、および/または、方法を実現する。
プロセッサ201は、ストレージ203に記憶されるプログラムに含まれるコードまたは命令によって実現する機能、および/または、方法を実行する。プロセッサ201は、限定でなく例として、中央処理装置(CPU)、MPU(Micro Processing Unit)、GPU(Graphic s Processing Unit)、マイクロプロセッサ(microprocessor)、プロセッサコア(processor core)、マルチプロセッサ(multiprocessor)、ASIC(Application-Specific Integrated Circuit)、FPGA(Field Programmable Gate Array)等を含み、集積回路(IC(Integrated Circuit)チップ、LSI(Large Scale Integration))等に形成された論理回路(ハードウェア)や専用回路によって各実施形態に開示される各処理を実現してもよい。また、これらの回路は、1または複数の集積回路により実現されてよく、各実施形態に示す複数の処理を1つの集積回路により実現されることとしてもよい。また、LSIは、集積度の違いにより、VLSI、スーパーLSI、ウルトラLSIなどと呼称されることもある。
メモリ202は、ストレージ203からロードしたプログラムを一時的に記憶し、プロセッサ201に対して作業領域を提供する。メモリ202には、プロセッサ201がプログラムを実行している間に生成される各種データも一時的に格納される。メモリ202は、限定でなく例として、RAM(Random Access Memory)、ROM(Read Only Memory)などを含む。
ストレージ203は、以下に開示する機能、および/または、方法を実行するためのプログラムを記憶する。ストレージ203は、限定でなく例として、HDD(Hard Disk Drive)、SSD(Solid State Drive)、フラッシュメモリなどを含む。
通信I/F205は、ネットワーク125を介して各種データの送受信を行う。当該通信は、有線、無線のいずれで実行されてもよく、互いの通信が実行できるのであれば、どのような通信プロトコルを用いてもよい。通信I/F205は、ネットワーク125を介して、他の情報処理装置との通信を実行する機能を有する。通信I/F205は、各種データをプロセッサ201からの指示に従って、他の情報処理装置に送信する。また、通信I/F205は、他の情報処理装置から送信された各種データを受信し、プロセッサ201に伝達する。
入出力I/F204は、情報処理装置200に対する各種操作を入力する入力装置、および、情報処理装置200で処理された処理結果を出力する出力装置を含む。入出力I/F204は、入力装置と出力装置が一体化していてもよいし、入力装置と出力装置とに分離していてもよい。
入力装置は、ユーザからの入力を受け付けて、当該入力に係る情報をプロセッサ201に伝達できる全ての種類の装置のいずれか、または、その組み合わせにより実現される。入力装置は、限定でなく例として、タッチパネル、タッチディスプレイ、キーボード等のハードウェアキーや、マウス等のポインティングデバイス、カメラ(画像を介した操作入力)、マイク(音声による操作入力)を含む。
出力装置は、プロセッサ201で処理された処理結果を出力することができる全ての種類の装置のいずれか、または、その組み合わせにより実現される。当該処理結果を映像、および/または、動画像として出力する場合、出力装置は、フレームバッファに書き込まれた表示データに従って、当該表示データを表示することができる全ての種類の装置のいずれかまたはその組み合わせにより実現される。出力装置は、限定でなく例として、タッチパネル、タッチディスプレイ、モニタ(限定でなく例として、液晶ディスプレイ、OELD(Organic Electroluminescence Display)など)、ヘッドマウントディスプレイ(HDM:Head Mounted Display)、プロジェクションマッピング、ホログラム、空気中など(真空であってもよい)に画像やテキスト情報等を表示可能な装置、スピーカ(音声出力)、プリンターなどを含む。なお、これらの出力装置は、3Dで表示データを表示可能であってもよい。
本開示の各実施形態のプログラムは、コンピュータに読み取り可能な記憶媒体に記憶された状態で提供されてもよい。 記憶媒体は、「一時的でない有形の媒体」に、プログラムを記憶可能である。プログラムは、限定でなく例として、ソフトウェアプログラムやコンピュータプログラムを含む。
記憶媒体は適切な場合、1つまたは複数の半導体ベースの、または他の集積回路(IC)(限定でなく例として、フィールド・プログラマブル・ゲート・アレイ(FPGA)、特定用途向けIC(ASIC)など)、ハード・ディスク・ドライブ(HDD)、ハイブリッド・ハード・ドライブ(HHD)、光ディスク、光ディスクドライブ(ODD)、光磁気ディスク、光磁気ドライブ、フロッピィ・ディスケット、フロッピィ・ディスク・ドライブ(FDD)、磁気テープ、固体ドライブ(SSD)、RAMドライブ、セキュア・デジタル・カードもしくはドライブ、任意の他の適切な記憶媒体、またはこれらの2つ以上の適切な組合せを含むことができる。記憶媒体は、適切な場合、揮発性、不揮発性、または揮発性と不揮発性の組合せでよい。
また、本開示のプログラムは、当該プログラムを伝送可能な任意の伝送媒体(通信ネットワークや放送波等)を介して、情報処理装置200に提供されてもよい。
また、本開示の各実施形態は、プログラムが電子的な伝送によって具現化された、搬送波に埋め込まれたデータ信号の形態でも実現され得る。
なお、本開示のプログラムは、限定でなく例として、JavaScript(登録商標)、Pythonなどのスクリプト言語、C言語、Go言語、Swift,Koltin、Java(登録商標)などを用いて実装される。
情報処理装置200おける処理の少なくとも一部は、1以上のコンピュータにより構成されるクラウドコンピューティングにより実現されていてもよい。
情報処理装置200における処理の少なくとも一部を、他の情報処理装置により行う構成としてもよい。この場合、プロセッサ201により実現される各機能部の処理のうち少なくとも一部の処理を、他の情報処理装置で行う構成としてもよい。
<その他>
明示的な言及のない限り、本開示の実施形態における判定の構成は必須でなく、判定条件を満たした場合に所定の処理が動作されたり、判定条件を満たさない場合に所定の処理がされたりしてもよい。
本開示では、明記されない限り、または文脈によって示されない限り、「または」は排他的ではなく包含的な意味である。したがって、本開示では、明記されていない限り、または文脈によって示されない限り、「AまたはB」は「A、B、またはその両方」を意味する。さらに、「AおよびBの少なくとも一方」は、「A、B、またはその両方」を意味する。さらに、明記されない限り、または文脈によって示されない限り、「a」、「an」、または「the」は「1つまたは複数」を意味するものとする。したがって、本明細書では、別段に明記されない限り、または文脈によって示されない限り、「an A」または「the A」は「1つまたは複数のA」を意味する。
本開示は、本開示の実施形態、および/または、実施例に対して、当業者が成し得る全ての変更、置換、変形、改変、および修正を包含する。同様に、適切な場合、添付の特許請求の範囲は、本開示の実施形態、および/または、実施例に対して、当業者が成し得る全ての変更、置換、変形、改変、および修正を包含する。さらに、本開示は、当業者が成し得る、本開示における実施形態、および/または、実施例の1つまたは複数の特徴と、本開示における他の実施形態、および/または、実施例の1つまたは複数の特徴との任意の組合せを包含する。
加えて、特定の機能を実施するように適合される、配置される、能力を有する、構成される、使用可能である、動作可能である、または動作できる装置またはシステムあるいは装置またはシステムの構成要素に対する添付の特許請求の範囲での参照は、その装置、システム、または構成要素がそのように適合される、配置される、能力を有する、構成される、使用可能にされる、動作可能にされる、または動作できる限り、その装置、システム、構成要素またはその特定の機能がアクティベートされ、オンにされ、またはロック解除されているか否かに関わらず、その装置、システム、構成要素を包含する。
本開示は、明示されない限り、いずれの実施形態または実施例を実施するに際して、事前に、または、実施の直前にユーザからの同意を取得してもよい。また、取得する同意は、包括的なものでもよく、都度取得するものでもよい。
<第1実施形態>
第1実施形態は、ユーザが端末120を用いて、ネットワーク125経由によるオンライン処理で、情報コードによる決済サービスを受ける際に、割り勘処理を可能とする実施形態である。
情報コードは、一次元コード、二次元コード、三次元コードなどの多次元コードを含むコードである。なお、一次元コードは、限定でなく例として、バーコードであってもよい。また、二次元コードは、限定でなく例として、QRコード(登録商標)、AztecCode、PDF417等であってもよい。三次元コードは、限定でなく例として、QRコード(登録商標)に色を組み合わせたPMコード(登録商標)等であってもよい。以下の説明では、説明の便宜上、二次元コードによる決済を行う前提で説明するが、第1実施形態及び第2実施形態は、一次元コードまたは三次元コードを含む多次元コードによる決済にも適用することが可能である。
第1実施形態における店舗読取型コード決済の一側面では、支払い対象ユーザの端末120に表示された二次元コードを、割り勘対象ユーザの端末120が読み取ってサーバ110に送信する。支払い対象ユーザの端末120が、サーバ110から送信される割り勘対象ユーザのアカウント情報に基づいて割り勘対象の総数を取得する。支払い対象ユーザの端末120は、取得した総数を用いて、割り勘額を取得し、割り勘額を含む決済リクエストをサーバ110に送信する。これにより、ユーザに煩雑な手続きを行わせることなく、割り勘処理を容易に実行することが可能になる。
また、第1実施形態における店舗読取型コード決済の一側面では、割り勘対象ユーザが、支払い対象ユーザと所定の関係がある場合に、割り勘処理を実行する。また、本側面において、支払い対象ユーザと所定の関係がある他のユーザに、支払額の全額を代理で払ってもらうことも可能である。これにより、関係のない他人に無断等で、支払い対象ユーザの支払額の一部、または全部を支払わせることを防止することが可能になり、セキュリティの向上を図ることができる。
また、第1実施形態におけるユーザ読取型コード決済の一側面では、支払い対象ユーザの端末120が、店舗等に掲載された二次元コードや、POS端末130等に表示された二次元コードを読み取り、読み取った二次元コードに基づいて割り勘用の二次元コードを生成し、生成した二次元コードを画面に表示する。後の処理は店舗読取型コード決済の処理と同様であり、割り勘対象ユーザの端末120が、支払い対象ユーザの端末120に表示された二次元コードを読み取ることで、割り勘処理や決済処理が行われる。これにより、煩雑な手続きをユーザが行うことなく、割り勘処理を容易に行うことが可能になる。
また、第1実施形態におけるユーザ読取型コード決済の一側面では、店舗等に掲示された二次元コードや、POS端末130等に表示された二次元コードを、割り勘を行う各ユーザの端末120が読み取り、読み取った二次元コードに含まれる情報や各ユーザのアカウント情報などをサーバ110に送信する。サーバ110は、受信した情報に基づいて、割り勘対象ユーザの総数や割り勘額を算出し、算出した情報を各端末120に送信する。これにより、ユーザ読取型コード決済の場合でも、煩雑な手続きをユーザが行うことなく、割り勘処理を容易に実行することが可能になる。また、端末120側は、二次元コードの読み取り、割り勘額の表示、決済処理のリクエストの送信を行えばよく、実体的な計算処理が不要になるため、端末120の処理速度の向上を図ることが可能になる。
また、第1実施形態の開示技術は、店舗側の既存のシステムや、既に掲示している二次元コードを変更しなくても導入可能であるため、店舗側にとっても、本開示の技術を容易に適用することが可能になる。
<第1実施形態の機能構成>
(1)サーバの機能構成
図3は、第1実施形態におけるサーバ110の機能構成の一例を示す図である。図3に開示の機能部は、情報処理装置200が備えるプロセッサ201と、メモリ202と、ストレージ203と、入出力I/F204と、通信I/F205との協働により実現される。
サーバ110は、例えば、入出力部302と、通信部304と、決済事前処理部306と、割り勘処理部308と、決済処理部310と、記憶部312とを有する。入出力部302は、例えば、入出力I/F204を用いて実現されうる。また、通信部304は、例えば、通信I/F205を用いて実現されうる。決済事前処理部306と、割り勘処理部308と、決済処理部310とは、プロセッサ201が、記憶部312に格納されているプログラムを読み出して実行することで実現されうる。記憶部312は、メモリ202および/またはストレージ203を用いて実現される。
記憶部312は、第1の実施形態に係るサーバ110が実行するプログラムと、二次元コード決済を利用するユーザのアカウント情報を管理するユーザ管理DB(DataBase)と、ユーザ同士の所定の関係を管理する関連管理DBと、ユーザが行った決済処理の履歴を管理する決済管理DBとを格納する。図4は、各管理DBの一例を示す図である。
図4(A)は、ユーザ管理DBの一例を示す。ユーザ管理DBには、決済事業者により作成された各ユーザのアカウントに関する情報が管理される。「ユーザID」には、サーバ110がユーザを一意に識別するためのユーザ識別情報(ID:Identifier)が格納される。「パスワード」には、ユーザ認証を行うためのパスワードが格納される。「残高」には、ユーザが保有する金銭の残高が格納される。なお、図4(A)に図示していないが、ユーザ管理DBは、ユーザの端末120により発行された二次元コードの情報を一時的に格納するようにしてもよい。二次元コードの情報は、限定でなく例として、二次元コードを識別するコード識別情報や、二次元コードの有効期限などを含んでもよい。ユーザ管理DBで管理されている情報の一部又は全部を、アカウント情報とも称す。
図4(B)は、関連管理DBの一例を示す。「グループID」には、ユーザの所定の関係を識別するための識別情報が格納される。「ユーザID」には、所定の関係を有するユーザのユーザ識別情報が格納される。
所定の関係とは、サーバ110が、2以上のユーザ間の所定の関係を記憶していることを意味する。限定でなく例として、所定の関係は、相互に関係構築を承認した関係、少なくとも一方が関係構築を申し入れた関係、ユーザ情報に基づき構築された関係、ユーザ行動に基づき構築された関係、所定の条件が満たされたことにより関係構築がなされた状態を含んでもよい。なお、ユーザ情報に基づき構築された関係とは、1以上の同一または類似するユーザ情報を有するユーザ同士を関係づけた関係を含んでもよいし、ユーザ行動に基づき構築された関係とは、1以上の同一または類似するユーザ行動を有するユーザ同士を関係づけた関係を含んでもよい。
また、ユーザと所定の関係にあるユーザは、限定ではなく例として、ユーザと所定の関係にある全てのユーザでもよいし、予め定められた所定の人数のユーザであってもよいし、親密度が所定の度合い以上のユーザであってもよい。
ここで、親密度とは、所定の期間内(1か月間や2か月間などの予め固定された期間でもよいし、所定の関係を構築してから現在までの期間でもよい)においてユーザとの間で送受信したメッセージの送受信量が多い順に親密度が高くなるように決定される度合いであってもよい。また、所定の期間内においてユーザ間で行われた取引(商品の売買や、資産の送受信・両替等などを含む)の回数が多い順に親密度が高くなるように決定される度合いでもよい。
また、親密度とは、所定の関係が構築されてから現在までの期間の長さが長いほど親密度が高くなるように決定される度合いであってもよい。所定の関係を構築してから現在までの期間の長さは、絶対値であってもよいし、ユーザと所定の関係にある1以上のユーザの中での相対値であってもよい。
また、親密度とは、ユーザと所定の関係にある複数の他のユーザについて、他のユーザがユーザの位置から所定の範囲内にいる時間の長さが長いほど、親密度が高くなるように決定される度合いであってもよい。また、親密度とは、ユーザと所定の関係にある複数のユーザについて、所定の関係が構築されてから現在までの期間と、各ユーザの位置情報とに基づいて推定される関係性(例えば家族関係にあると推定される等が高いほど親密度が高くなるように決定される度合いであってもよい。
また、親密度とは、ユーザと所定の関係にある複数の他のユーザについて、ユーザと共通のユーザの数(共通の友達の人数)が多いほど親密度が高くなるように決定される度合いであってもよい。
また、親密度とは、ユーザとコミュニケーションをとっているユーザと所定の関係を構築しているユーザのうち、ユーザ自身と所定の関係にあるユーザの数が多いほど親密度が高くなるように決定される度合いであってもよい。
また、親密度とは、ユーザ自身の属性と、ユーザと所定の関係にある複数のユーザの各々の属性との間における類似度が高いほど親密度が高くなるように決定される度合いであってもよい。ユーザの属性とは、限定ではなく例として、興味又は関心であってもよい。
限定でなく例として、図4(B)に示すグループID「G01」は、家族を表しており、ユーザID「U01」、「U03」、「U05」が示すユーザ達は、みんな1つの家族の構成員であることを表す。関連管理DBは、このデータベースを管理する管理者により新規のグループ及びユーザ達が登録されてもよい。
図4(C)は、決済管理DBの一例を示す図である。「日時」には、二次元コード決済が完了した日時が格納される。「店舗ID」には、二次元コード決済が行われた店舗の店舗情報(店舗IDとも称す)が格納される。なお、店舗IDは、店舗に複数のPOS端末130がある場合は、POS端末130のIDでもよい。「支払額」には、二次元コード決済が行われた際の支払額が格納される。また、決済管理DBは、決済を識別する情報である決済IDなどがある場合は、決済IDを管理するようにしてもよい。これにより、決済情報の検索が容易になる。
入出力部302は、入出力I/F204を介して各種データの入力を受け付ける処理、及び、入出力I/F204を介して各種のデータを出力する処理を行う機能を有する。
通信部304は、通信I/F205を介して端末120及びPOS端末130から各種データを受信する処理、及び、通信I/F205を用いて各種のデータを端末120及びPOS端末130に送信する処理を行う機能を有する。
決済事前処理部306は、各ユーザの端末120から送信されたアカウント情報に基づいて、決済を行うための事前処理を行う機能を有する。決済事前処理は、割り勘額を取得するための処理であり、各種処理を含む。例えば、決済事前処理部306は、端末120からアカウント情報の送信リクエストに対して、ユーザのアカウント情報を所定の端末120に送信したりする。また、決済事前処理部306は、送信された各ユーザのアカウント情報に基づいて、割り勘対象のユーザの総数を求めたり、又は支払額からユーザの総数を除算して割り勘額を求めたりしてもよい。
割り勘処理部308は、支払いにおいて立て替えてもらったユーザの残高から割り勘額を減算し(引き出し)、支払いを行ったユーザの残高に加算する(振り込む)処理を行う機能を有する。また、割り勘処理部308は、割り勘額の引き出し及び振り込みの処理を、後述する決済処理の後に行っても、前に行ってもよい。
決済処理部310は、二次元コード決済を実行するための各種の処理を行う機能を有する。具体的には、決済処理部310は、決済リクエストに含まれる情報に基づいて決済処理を行う。決済処理は、支払い対象のユーザの残高から支払額を減算し、決済リクエストなどから特定される店舗の口座に支払額を振り込む処理を含む。ここで、店舗の口座とは、店舗が所有しているアカウントを含む。店舗の口座に支払額を振り込む(預け入れる)/引き出すとは、店舗のアカウントの残高に支払額を加算する/減算することを含む。
次に、二次元コード決済における店舗読取型コード決済と、ユーザ読取型コード決済との場合に分けて、通信部304、決済事前処理部306、割り勘処理部308、及び決済処理部310の具体的な機能について説明する。
(A)店舗読取型コード決済におけるサーバの機能構成
通信部304は、支払い対象ユーザ(例、ユーザA)の端末120に表示された二次元コードを読み取った各端末120から、割り勘対象ユーザのアカウント情報、及び支払い対象ユーザのユーザIDなどを受信する受信部(第1A受信部)として機能する。二次元コードには、例えば、この二次元コードを生成した支払い対象ユーザA、および/または、支払額を含む。アカウント情報は、限定でなく例として、二次元コードを読み取った端末120を利用する割り勘対象ユーザ(例えば、ユーザB、ユーザC)のユーザID及びパスワードを含む。また、通信部304は、受信した割り勘対象ユーザのアカウント情報及び支払い対象ユーザのユーザIDに基づく決済事前処理の結果などを、支払い対象ユーザの端末120に送信する送信部(第1A送信部)としても機能する。
また、通信部304は、支払い対象ユーザの端末120から、各割り勘対象ユーザのアカウント認証及び残高確認リクエストを受信する受信部(第2A受信部)として機能してもよい。アカウント認証及び残高確認リクエストには、例えば、割り勘対象ユーザのアカウント情報、及び割り勘額が含まれる。また、通信部304は、支払い対象ユーザの端末120に、各割り勘対象ユーザのアカウント認証及び残高確認の結果を送信する送信部(第2A送信部)として機能してもよい。アカウント認証及び残高確認の結果には、例えば、割り勘対象ユーザのユーザID及びパスワードに基づくアカウント認証の成否、並びに割り勘対象ユーザのアカウントに関連付けられる残高が割り勘額以上であるか否かの結果が含まれる。
また、通信部304は、支払い対象ユーザの端末120に表示された二次元コードを読み取ったPOS端末130から、店舗側に支払額を支払うための決済リクエストを受信する受信部(第3A受信部)として機能してもよい。決済リクエストには、例えば、二次元コードを読み取ったPOS端末130に関連付けられる店舗ID、支払額、及び支払い対象ユーザのユーザIDなどが含まれる。また、通信部304は、POS端末130、および/または、支払い対象ユーザの端末120に、決済の完了通知を送信する送信部(第3A送信部)として機能してもよい。
決済事前処理部306は、第1A受信部により受信された割り勘対象ユーザのアカウント情報及び支払い対象ユーザのユーザID等に基づいて、決済を行うための事前処理を行う。決済事前処理部306は、例えば、支払い対象ユーザのユーザIDから支払い対象ユーザを特定する。次に、決済事前処理部306は、割り勘対象ユーザのアカウント情報を、第1A送信部を介して支払い対象ユーザの端末120に送信するよう指示する。また、決済事前処理部306は、支払額を取得できる場合は、所定期間内に受信したアカウント情報の総数に応じて割り勘額を算出し、割り勘額を支払い対象ユーザの端末120に送信するようにしてもよい。この場合、割り勘額の算出については、支払い対象ユーザの端末120から割り勘額の算出リクエストを受信したときに算出するようにしてもよい。これにより、割り勘の人数が決まった後に、適切な割り勘額が算出されるようになる。
また、決済事前処理部306は、第2A受信部により受信された割り勘対象ユーザのアカウント認証及び残高確認リクエストに応じて、アカウント認証処理及び残高確認処理を行う。決済事前処理部306は、アカウント認証処理として、第2A受信部により受信されたアカウント情報を基にユーザ管理DBに問い合わせ、割り勘対象ユーザの認証が成功したか否かを判定する。また、決済事前処理部306は、残高確認処理として、第2A受信部により受信された割り勘額を基にユーザ管理DBに問い合わせ、割り勘対象ユーザの残高が割り勘額以上であるか否かを判定する。また、決済事前処理部306は、アカウント認証の結果、及び残高確認の結果を、第2A送信部を介して支払い対象ユーザの端末120に送信するよう指示する。
割り勘処理部308は、第3A受信部により受信された決済リクエストに応じて、支払い対象ユーザ以外の割り勘対象の各ユーザのアカウントを特定し、特定されたアカウントに紐づけられた各ユーザの残高から割り勘額を減算し、支払い対象ユーザの残高に加算する割り勘処理を行う。また、割り勘処理部308は、割り勘処理の完了通知を、第3A送信部を介して、支払い対象ユーザの端末120に送信する。
決済処理部310は、第3A受信部により受信された決済リクエストに応じて、店舗IDに関連付けられる店舗の口座に、支払い対象ユーザの残高から減算した支払額を支払う決済処理を行う。決済処理は、外部システム140を用いて行われる。また、決済処理部310は、決済処理の完了通知を、第3A送信部を介して、二次元コードを読み取ったPOS端末130、および/または、支払い対象ユーザの端末120に送信する。なお、上述したとおり、割り勘処理及び決済処理の順序は問わず、どちらが先に行われてもよいが、支払い対象ユーザが割り勘額を回収し損ねることを防ぐために、本開示では、割り勘処理を先に実行する例を説明する。
また、決済事前処理部306は、二次元コードを表示した端末120のユーザと、この二次元コードを読み取った端末120のユーザとの所定の関係に応じて、割り勘処理を実行するか否かを判定してもよい。この場合、決済事前処理部306は、第1A受信部により受信された支払い対象ユーザのユーザIDと、アカウント情報に含まれるユーザIDとが所定の関係を有するかを関連管理DBに問い合わせる。決済事前処理部306は、問い合わせ結果を取得し、ユーザ間の所定の関係を示す判定結果を、第1A送信部を介して支払い対象ユーザの端末120に送信する。例えば、支払い対象ユーザと、割り勘対象ユーザとが所定の関係(例えば、家族、大学の友人等)を有する場合に、割り勘処理を実行することが可能になる。これにより、所定の関係のないユーザとの割り勘処理を防ぐことができ、セキュリティの向上を図ることができる。
また、割り勘処理以外にも、二次元コードを表示した端末120のユーザの代わりに、この二次元コードを読み取った端末120のユーザに全額支払ってもらうような処理にも、本開示の技術は適用可能である。例えば、子供であるユーザAの決済を、ユーザAの親であるユーザBが行う場合に、割り勘ではなく代理支払いであることを示す代理情報を含む二次元コードが、ユーザAの端末120Aに表示される。このとき、ユーザBの端末120Bが二次元コードを読み取って、二次元コードに含まれる代理情報及びユーザAのユーザIDと、端末120B側で追加されたユーザBのアカウント情報とがサーバ110に送信される。決済事前処理部306は、ユーザAのユーザIDと、ユーザBのアカウント情報に含まれるユーザBのユーザIDとに基づいて、ユーザ間の所定の関係を判定する。決済事前処理部306は、ユーザ間の所定の関係がある場合に、代理支払いを行うことを許可する。これにより、所定の関係のないユーザによる代理支払いを防止することができ、セキュリティの向上を図ることができる。
(B)ユーザ読取型コード決済におけるサーバの機能構成
通信部304は、店舗に対応付けられた二次元コード(例えば、店舗の所定位置に掲示された、またはPOS端末130に表示された二次元コード)を読み取った各端末120から、この二次元コードに含まれる決済情報、及び、二次元コードを読み取った端末120のユーザのアカウント情報などを受信する受信部(第1B受信部)として機能する。決済情報は、例えば支払額などを含む。また、通信部304は、受信された各アカウント情報に基づく決済事前処理の結果を、決済情報を送信した各端末120に送信する送信部(第1B送信部)としても機能する。決済事前処理の結果は、例えば、受信された各アカウント情報に関連付けられるユーザの総数を用いて支払額を除算した割り勘額を含んでもよい。また、通信部304は、各端末120から決済リクエストを受信する受信部(第2B受信部)としても機能する。また、通信部304は、決済リクエストに応じて処理された割り勘処理、および/または、決済処理の完了通知を、二次元コードを表示したPOS端末130、および/または、二次元コードを読み取った各端末120に送信する送信部(第2B送信部)としても機能する。
なお、ユーザ読取型コード決済において、POS端末130に表示された二次元コードを、支払い対象ユーザの端末120が読み取り、この端末120が、割り勘処理用の二次元コードを生成し、生成した二次元コードを割り勘対象ユーザの各端末120に読み取らせてもよい。この場合、以降のサーバ110側の機能は、店舗読取型コード決済の場合の機能と同様であるが、決済リクエストは、支払い対象ユーザの端末120から送信されてもよい。よって、以下では、POS端末130等に表示された二次元コードを、割り勘対象ユーザの各端末120が読み取ることを例にして説明する。
決済事前処理部306は、決済事前処理として、第1B受信部により受信された各アカウント情報に関連付けられるユーザ(割り勘対象ユーザ)の総数を求め、この総数と支払額の少なくとも一部を用いて割り勘額を算出する。例えば、決済事前処理部306は、支払額を総数で除算して算出した割り勘額を含む決済事前処理の結果を、第1B送信部を介して各ユーザの端末120に送信する。これにより、サーバ側で割り勘額を算出するため、端末120側の処理負荷を減らすことができる。
また、決済事前処理部306は、決済事前処理として、割り勘対象ユーザの総数を、第1B送信部を介して各ユーザの端末120に送信するようにしてもよい。この場合、端末120側で割り勘額の算出が行われるため、各端末120は、支払額をサーバ110側に送信しなくてもよい。
割り勘処理部308は、第2B受信部により受信された決済リクエストに応じて、決済リクエストを送信した各端末120を利用する割り勘対象の各ユーザの残高から、決済事前処理部306により算出された割り勘額を減算して引き出す。
決済処理部310は、割り勘処理部308により減算された各割り勘額を、決済リクエストに含まれる店舗IDに関連付けられる店舗の口座に支払う決済処理を行う。また、決済処理部310は、決済処理の完了通知を、第2B送信部を介して、二次元コードを表示したPOS端末130、および/または、二次元コードを読み取った各端末120に送信する。
なお、ユーザ読取型コード決済の場合、割り勘処理部308及び決済処理部310は、上述した割り勘額の引き出しから、店舗口座への預け入れまでを協働して行ってもよい。また、割り勘額が端末120側で算出される場合、端末120から送信される決済リクエストには、割り勘額が含まれてもよい。この場合、割り勘処理部308は、第2受信部により受信された決済リクエストに含まれる割り勘額を、割り勘対象の各ユーザの残高から減算して引き出すようにしてもよい。
ユーザ読取型コード決済における他の例として、事前チェックインが考えられる。例えば、レストランの各テーブルに、このテーブルまたはレストランを識別するための識別情報(以下、支払先IDとも称す)が変換された二次元コードが掲示されたり、テーブルに設置された端末120の画面に表示されたりする。そのテーブルに座る各ユーザは、自分の端末120を用いて二次元コードを読み取って、チェックイン処理を行う。チェックイン処理において、各端末120は、読み取った支払先ID、及びユーザのアカウント情報をサーバ110に送信する。
次に、店舗側において、このテーブルでの注文が全て完了したのち、ユーザからの指示に応じて、チェックアウト処理が行われる。チェックアウト処理において、例えば、ユーザが、テーブルに設置された端末120上で、注文完了を指示すると、この端末120から、支払先ID及び支払額がサーバ110に送信される。サーバ110の決済事前処理部306は、支払額を取得すると、チェックインしたユーザ(割り勘対象ユーザ)の数と支払額の少なくとも一部を用いて割り勘額を算出する。以降の処理は、上述したユーザ読取型コード決済の処理と同様である。これにより、ユーザは、支払いのためにレジなどに並ぶ必要がなく、迅速に支払いを済ませることができる。
(2)端末の機能構成
図5を用いて端末120の機能構成を説明する。図5に開示の機能部は、情報処理装置200が備えるプロセッサ201と、メモリ202と、ストレージ203と、入出力I/F204と、通信I/F205との協働により実現される。
端末120は、入出力部502と、通信部504と、生成部506と、表示制御部508と、取得部510と、調整部512と、決済制御部514と、読み取り部516と、記憶部518を有する。入出力部502と、通信部504と、生成部506と、表示制御部508と、取得部510と、調整部512と、決済制御部514と、読み取り部516とは、プロセッサ201が、記憶部518に格納されているプログラムを読み出して実行することで実現される。記憶部518は、メモリ202および/またはストレージ203を用いて実現される。上述したとおり、二次元コード決済は、店舗読取型コード決済と、ユーザ読取型コード決済とを含むため、まずは店舗読取型コード決済における端末120の機能構成について説明し、次に、ユーザ読取型コード決済における端末120の機能構成について説明する。
(A)店舗読取型コード決済における端末の機能構成
入出力部502は、入出力I/F204を介して各種データの入力を受け付ける処理、及び、入出力I/F204を介して各種のデータを出力する処理を行う機能を有する。
通信部504は、通信I/F205を介してサーバ110から各種データを受信する処理、及び、通信I/F205を用いて各種のデータをサーバ110に送信する処理を行う機能を有する。通信部504は、割り勘対象ユーザのアカウント情報、及び支払い対象ユーザのユーザIDなどを受信したサーバ110により処理される決済事前処理に基づき、割り勘対象ユーザの各アカウント情報を受信する受信部(第4A受信部)として機能する。アカウント情報は、限定でなく例として、二次元コードを読み取った端末120を利用する割り勘対象ユーザのユーザID及びパスワードを含む。
また、通信部504は、各割り勘対象ユーザのアカウント認証及び残高確認リクエストを、サーバ110に送信する送信部(第4A送信部)として機能してもよい。アカウント認証及び残高確認リクエストには、例えば、割り勘対象ユーザのアカウント情報、及び割り勘額が含まれる。また、通信部504は、サーバ110から、各割り勘対象ユーザのアカウント認証及び残高確認の結果を受信する受信部(第5A受信部)として機能してもよい。アカウント認証及び残高確認の結果には、例えば、割り勘対象ユーザのユーザID及びパスワードに基づくアカウント認証の成否、及び割り勘対象ユーザのアカウントに関連付けられる残高が割り勘額以上であるか否かの結果が含まれる。
また、通信部504は、支払い対象ユーザの端末120に表示された二次元コードを読み取ったPOS端末130に、店舗側に支払額を支払うための決済リクエストを送信する送信部(第5A送信部)として機能してもよい。決済リクエストは、例えば、二次元コードに含まれてもよい。また、通信部504は、サーバ110から、決済の完了通知を受信する受信部(第5A受信部)として機能してもよい。
生成部506は、支払い対象ユーザの端末120に表示するための二次元コードの生成を補助する。具体的には、生成部506は、二次元コードを生成するための補助画面を表示画面に表示するよう表示制御部508に指示する。補助画面は、例えば、支払額の入力欄や、割り勘にするか否かの選択欄を含む。生成部506は、入出力部502を介して、補助画面に入力された情報に基づいて、割り勘用の二次元コードを生成する。割り勘用の二次元コードは、第1情報コードとも称される。
表示制御部508は、端末120の表示画面への表示を制御する。例えば、表示制御部508は、生成部506により指示された補助画面を表示画面に表示するよう制御したり、生成部506により生成された二次元コードを表示画面に表示するよう制御したりする。また、表示制御部508は、後述する調整部512により指示された調整画面を表示画面に表示するよう制御する。なお、補助画面や調整画面は、表示画面の画面全体として実装されたり、表示画面のユーザインターフェースの一部として実装されたりしてもよい。
取得部510は、二次元コードを読み取った各端末120によって送信されたアカウント情報を受信したサーバ110により処理される決済事前処理に基づき、各アカウント情報に基づく割り勘対象ユーザの総数と、支払額の少なくとも一部とを用いて算出された割り勘額を取得する。
図6は、第1実施形態に係る取得部510の機能の一例を示すブロック図である。図6に示すように、取得部510は、限定でなく例として、総数算出部602と、割り勘額算出部604とを有する。
総数算出部602は、取得されたアカウント情報の数に基づいて、割り勘対象ユーザの総数を算出する。例えば、総数算出部602は、取得されたアカウント情報が3つである場合、アカウント情報の数(3)に支払い対象ユーザの数(1)を加算して、総数(4)を算出する。
割り勘額算出部604は、総数算出部602により算出された総数と、生成部506における補助画面内で入力された支払額の少なくとも一部とを用いて、割り勘額を算出する。例えば、割り勘額算出部604は、支払額が12,000円であり、総数が4である場合、支払額(12,000円)を総数(4)で除算して、割り勘額(3,000円)を算出する。なお、取得部510は、決済事前処理部306により割り勘額が算出される場合は、サーバ110側で算出された割り勘額を取得する。
図5に戻り、調整部512は、割り勘の人数を調整するための調整画面を表示画面に表示するよう表示制御部508に指示する。調整部512は、例えば、プラスボタン、マイナスボタンを用いることで、割り勘対象人数を調整できるようにする。これにより、例えば、端末120を持っていないユーザが、割り勘対象に含まれる場合、このユーザを割り勘対象ユーザに含めることができるようになる。また、誤って割り勘対象に含まれたユーザを割り勘対象ユーザから外すため、割り勘対象ユーザの総数から人数を減らすことができるようになる。
決済制御部514は、決済処理および/または割り勘処理の実行を制御する機能を有する。決済制御部514は、限定でなく例として、各割り勘対象ユーザのアカウント認証及び残高確認リクエストをサーバ110に送信するよう通信部504に指示する。この場合、決済制御部514は、残高確認リクエストに、取得部510で取得された割り勘額や、各割り勘対象ユーザのアカウント情報(ユーザID及びパスワード)を含めてもよい。
また、決済制御部514は、サーバ110から残高確認結果を取得すると、所定のユーザの残高が割り勘額未満の場合、割り勘処理を停止したり、表示画面に警告を出すように表示制御部508に指示したりする。また、残高確認結果が、全割り勘対象ユーザの残高が割り勘額以上であることを示す場合、決済制御部514は、支払額を含む二次元コードを表示画面に表示するよう表示制御部508に指示する。また、二次元コードには支払対象ユーザのユーザIDが含められてもよい。決済用の二次元コードは、第2情報コードとも称される。
読み取り部516は、二次元コードを読み取るリーダーの機能を有する。例えば、読み取り部516は、店舗に掲示されている二次元コード、POS端末130に表示されている二次元コード、または端末120の表示画面に表示されている二次元コードを読み取る。読み取り部516により読み取られた情報は、サーバ110に送信されたり、各種処理に用いられたりする。
記憶部518は、第1の実施形態に係る端末120が実行するプログラムを格納する。このプログラムは、限定でなく例として、開示の二次元コード決済における割り勘処理を実行するためのプログラムである。
<第1実施形態における店舗読取型コード決済時の動作処理>
図7を参照し、第1実施形態に係る通信システム1の店舗読取型コード決済時の処理について説明する。図7は、第1実施形態に係る通信システム1が行う店舗読取型コード決済時の処理手順のシーケンスの一例を示す図である。図7に示す例は、ユーザが、割り勘処理を行うための二次元コード(第1情報コード)を生成し、各割り勘対象ユーザに二次元コードを読み取らせて割り勘処理を行う場合を想定したシーケンスである。
ステップS702で、端末120Aの入出力部502は、ユーザから、補助画面内の支払額の入力や、割り勘処理の選択を受け付ける。例えば、入出力部502は、二次元コード決済を行うアプリケーションにおいて、ユーザによる表示画面上のソフトテンキーなどを用いての支払額の入力や、割り勘処理を行うためのボタンの押下を受け付ける。
ステップS704で、端末120Aの生成部506は、入出力部502による支払額の入力や、割り勘処理の選択に基づいて、割り勘用の二次元コードを生成する。割り勘処理用の二次元コードは、支払額の情報や、端末120Aを利用する支払い対象ユーザのユーザID等が変換されて含まれる。また、二次元コードは、割り勘処理を実行することを示す情報が変換されて含まれてもよい。これにより、この二次元コードを読み取った各端末120は、割り勘処理であることを迅速に認識することが可能になる。
ステップS706で、端末120Aの表示制御部508は、生成部506により生成された二次元コードを表示画面に表示するよう制御する。
ステップS708で、端末120Bの読み取り部516は、端末120Aに表示されている二次元コードを読み取る。
ステップS710で、端末120Bの通信部504は、端末120BのユーザBのアカウント情報を端末120Aに送信するための送信リクエストをサーバ110に送信する。例えば、送信リクエストには、端末120Bを利用するユーザBにより入力されたアカウント情報や、端末120Aを利用するユーザAのユーザIDが含まれる。
ステップS712で、サーバ110の通信部304は、ユーザBのアカウント情報を端末120Aに送信する。サーバ110は、例えば、ユーザAのユーザIDに基づいて、アカウント情報の送信先の端末120Aを特定可能である。
ステップS714で、端末120Cの読み取り部516は、端末120Aに表示されている二次元コードを読み取る。
ステップS716で、端末120Cの通信部504は、端末120CのユーザCのアカウント情報を端末120Aに送信するための送信リクエストをサーバ110に送信する。例えば、送信リクエストには、端末120Cを利用するユーザCにより入力されたアカウント情報や、端末120Aを利用するユーザAのユーザIDが含まれる。
ステップS718で、サーバ110の通信部304は、ユーザCのアカウント情報を端末120Aに送信する。サーバ110は、例えば、ユーザAのユーザIDに基づいて、アカウント情報の送信先の端末120Aを特定可能である。
ステップS720で、端末120Aの調整部512は、総数算出部602により算出された割り勘対象の総数を調整する。例えば、総数算出部602は、受信された2つのアカウント情報から、割り勘対象ユーザが2人であることを特定し、この2人に支払い対象ユーザの1人を足して、総数は3人であると特定する。次に、調整部512は、調整画面などを用いて、入出力部502により入力された総数に対するユーザからの調整指示を取得する。例えば、ユーザが「+」のボタンを1回押下すると、調整部512は、総数を1つ増加させ、ユーザが「−」のボタンを1回押下すると、調整部512は、総数を1つ減少させる。また、調整部512は、各ユーザが負担する金額を調整できてもよい。これにより、より柔軟な割り勘を行うことができる。なお、調整部512は、必ずしも必要な構成ではないが、この機能を設けることにより、現金で払いたいユーザなどがいる場合に割り勘対象の総数を調整することが可能になる。また、割り勘額は端末120Aを使用するユーザAによって、ユーザ毎に設定されても良い。
ステップS722で、端末120Aの取得部510は、割り勘額を決定する。例えば、取得部510の割り勘額算出部604は、ステップS702で入力された支払額を、総数算出部602により決定された総数、又は調整部512により調整された総数で除算し、支払額を算出する。
ステップS724で、端末120Aの通信部504は、サーバ110に、割り勘対象のユーザBとユーザCのアカウント認証及び残高確認リクエストを送信する。アカウント認証及び残高確認リクエストには、限定でなく例として、割り勘対象ユーザのアカウント情報、割り勘額が含まれる。
ステップS726で、サーバ110の決済事前処理部306は、割り勘対象ユーザのアカウント認証と、残高確認を行う。アカウント認証について、サーバ110の決済事前処理部306は、受信したアカウント情報に含まれるユーザID及びパスワードが、ユーザ管理DBに登録されているユーザID及びパスワードと一致するか否かを判定する。ユーザID及びパスワードが一致する場合は認証成功を表し、ユーザID及びパスワードが一致しない場合は認証失敗を表す。
また、残高確認について、サーバ110の決済事前処理部306は、ユーザ管理DBに保持されている各割り勘対象ユーザの残高が、受信された割り勘額以上であるか否かを判定する。残高が割り勘額以上であれば、残高有りを表し、残高が割り勘額未満であれば、残高不足(残高無し)を表す。
ステップS728で、サーバ110の通信部304は、アカウント認証及び残高確認結果を端末120Aに送信する。アカウント認証及び残高確認結果には、例えば、アカウント認証の成否、残高の有無が含まれる。
ステップS730で、端末120Aの決済制御部514は、アカウント認証及び残高確認結果が、アカウント認証成功、及び残高有を示していれば、決済のための二次元コード(第2情報コード)を表示画面に表示するよう表示制御部508に指示する。これにより、表示画面には、二次元コードが表示される。二次元コードには、例えば、支払額、ユーザAのユーザIDなどが含まれてもよい。
ステップS732で、POS端末130は、端末120Aの表示画面に表示された二次元コードを読み取る。
ステップS734で、POS端末130は、支払額、ユーザAのユーザID、店舗IDなどを含む決済リクエストをサーバ110に送信する。
ステップS736で、サーバ110の割り勘処理部308及び決済処理部310は、割り勘処理及び決済処理を実行する。例えば、割り勘処理部308は、割り勘対象ユーザのユーザB及びユーザCの残高から割り勘額を減算し、引き出した金額を支払い対象ユーザのユーザAの残高に加算する。次に、決済処理部310は、ユーザAの残高から支払額を引き出し、引き出した支払額を外部システム140(図7に不図示)に登録されている店舗の口座に振り込む。支払い対象ユーザのユーザAの残高と、割り勘対象ユーザのユーザB及びユーザCの残高とから割り勘額を減算し、外部システム140(図7に不図示)に登録されている店舗の口座に振り込むように構成されてもよい。
ステップS738で、サーバ110の通信部304は、割り勘処理、及び決済処理が完了した後、完了通知をPOS端末130に送信する。
ステップS740で、サーバ110の通信部304は、割り勘処理、及び決済処理が完了した後、完了通知をPOS端末130に送信する。
なお、割り勘対象ユーザのアカウント認証については、ステップS710やステップS716の後に行われてもよい。この場合、ステップS712、S718では、アカウント認証結果が端末120Aに送信される。また、この場合、ステップS724、S726、S728では、アカウント認証に関する処理は行われない。これにより、割り勘処理の初期段階でアカウント認証処理が行われることで、アカウント認証できないユーザを、決済アプリケーションにおける割り勘処理から早期に排除することができる。
また、ステップS704とステップS730において表示される二次元コードは、同一の二次元コードでもよい。これにより、再度二次元コードを生成する処理を省くことができる。同一の二次元コードは、ユーザAのユーザID、支払額を含み、さらに、決済を識別するための決済IDを含んでもよい。決済IDが二次元コードに含まれることで、サーバ110側では、決済IDに紐づけて、割り勘対象ユーザのアカウント認証、残高確認、割り勘処理、決済処理を一貫して管理することが可能になる。
また、ステップS704とステップS730において表示される二次元コードは、異なる二次元コードでもよい。これにより、割り勘用の二次元コードと、決済用の二次元コードとを明確に分けることができる。また、二次元コードのワンタイム性を採用し、セキュリティを向上させることができる。
また、ステップS710、S716において、支払額がサーバ110に送信されてもよく、この場合、サーバ110側で割り勘額の算出が可能になる。例えば、サーバ110の決済事前処理部306は、所定時間内に受信した送信リクエストの数に基づいて、割り勘対象ユーザの総数を算出し、支払額を総数で除算することで割り勘額を算出する。サーバ110の通信部304は、割り勘額を端末120Aに送信する。端末120Aの取得部510は、サーバ110により処理された決済事前処理に基づき算出された割り勘額を取得する。これにより、端末120Aのアプリケーション側の処理を減らすことができる。
なお、ステップS702では、支払額がユーザにより入力されているが、POS端末130などの二次元コードを読み取って支払額が入力されるようにしてもよい。これにより、ユーザによる支払額の誤入力を防止することができる。
<第1実施形態の端末に関する店舗読取型コード決済時の表示態様>
図8は、第1実施形態に係る端末120に表示される画面の一例を示す図である。図8(A)は、二次元コードを生成するための補助画面の一例を示している。図8(A)に示す補助画面は、支払額の入力欄、及び割り勘の選択ボタンを少なくとも含む。図8(A)に示す補助画面は、例えば、図7に示すステップS702の処理で表示される画面に対応する。
図8(B)は、生成された二次元コードを表示する画面の一例を示している。図8(B)に示す画面は、端末120の生成部506により生成された二次元コードを含む。図8(B)に示す画面は、例えば、図7に示すステップS706の処理で表示される画面に対応する。
図8(C)は、割り勘対象ユーザの総数を調整する画面の一例を示している。図8(C)に示す画面は、割り勘対象ユーザの総数を増減させるためのボタンや、割り勘額の表示欄、割り勘額の確認ボタンを含む。割り勘対象ユーザの総数の増減に応じて、取得部510などの処理により、割り勘額が変更される。図8(C)に示す画面は、例えば、図7に示すステップS720の処理で表示される画面に対応する。図8(C)に示す画面において、ユーザが「YES」ボタンを押下すると、ステップS724が処理される。
図8(D)は、割り勘対象ユーザのアカウント認証、残高確認リクエストを送信したことを示している。図8(D)に示す画面は、図7に示すステップS724の処理が行われた後、ステップS728の結果を受信するまで、又は所定時間経過するまで、端末120Aの表示画面に表示されてもよい。
図8(E)は、割り勘対象ユーザのアカウント認証、残高確認が完了したことを示している。図8(E)に示す画面は、全ての割り勘対象ユーザのアカウント認証が成功し、残高が割り勘額以上有る場合に表示される。図8(E)に示す画面は、図7に示すステップS728の処理が行われた後、端末120の表示画面に表示されてもよい。
図8(F)は、決済が完了したことを示している。図8(F)に示す画面は、例えば、支払額や決済完了の表示を含む。図8(F)に示す画面は、図7に示すステップS740の処理が行われた後、端末120の表示画面に表示されてもよい。
<<第1A実施例>>
第1実施形態の第1A実施例は、割り勘対象ユーザと支払い対象ユーザとの所定の関係が判定され、所定の関係がない場合には割り勘処理が行われない実施例である。「所定の関係がある」とは、例えば、友達、大学、家族などの所定のグループ内に、割り勘対象ユーザと支払対象ユーザと入っていることを条件とする。
<<第1A実施例の効果>>
本実施例によれば、支払い対象ユーザと、割り勘対象ユーザとの所定の関係を判断するため、支払い対象ユーザと全く関係のないユーザに対して、割り勘処理を実行させてしまうことを防止することができる。
<<第1A実施例の動作処理>>
図9は、本実施例に係るサーバ110と端末120との処理のシーケンスの一例を示す図である。図9に示す例は、ユーザが、割り勘処理を行うための二次元コードを生成し、各割り勘対象ユーザの端末120に二次元コードを読み取らせた後、サーバ110がユーザの所定の関係を判定し、所定の関係がある場合に、割り勘処理が行われる場合を想定したシーケンスである。
図9に示すステップS902、S904、S906、及びS908の処理は、図7に示すステップS704、S706、S708、及びS710それぞれの処理と同様であるため、説明を省略する。なお、ステップS902において、生成部506は、オンラインショッピングなどの決済画面から支払額と店舗IDを含む二次元コードを生成してもよい。
図9に示すステップS910で、サーバ110の決済事前処理部306は、ユーザ間の所定の関係を判定する。例えば、決済事前処理部306は、支払い対象ユーザと、割り勘対象ユーザとに所定の関係があるか否かを、関連管理DBに問い合わせる。具体的には、決済事前処理部306は、支払い対象ユーザのユーザIDと、割り勘対象ユーザのユーザIDとが関連管理DB内の同一グループに含まれているか否かを判定する。同一グループ内に両IDが含まれていれば、「関連有り」と判定され、同一グループ内に両IDが含まれていなければ、「関連無し」と判定される。
ステップS912で、サーバ110の通信部304は、所定の関係の判定結果を端末120Aに送信する。
ステップS914で、端末120Aの表示制御部508は、サーバ110から受信した判定結果を表示画面に表示するよう制御する。例えば、表示画面には、端末120Aを利用する第1ユーザと、各情報処理装置を利用する他の各ユーザとに所定の関係がある場合に、この所定の関係があるユーザの情報の少なくとも一部が、所定の関係がないユーザの情報の少なくとも一部とは異なる態様で表示される。限定でなく例として、所定の関係があるユーザのユーザIDと、所定の関係がないユーザのユーザIDとの文字の色、文字サイズ、及び文字のフォント等の少なくとも1つを異ならせる。また、他の例として、表示画面には、ユーザ情報に関連づけて「関連有」、又は「関連無」が表示されてもよい。
ステップS916で、端末120Aの決済制御部514は、決済リクエストをサーバ110に送信する。決済リクエストには、支払い対象ユーザのユーザID、割り勘対象ユーザのユーザID、及び支払額が含まれる。
ステップS918で、サーバ110の割り勘処理部308及び決済処理部310は、上述した割り勘処理及び決済処理を行う。なお、割り勘処理部308は、割り勘対象ユーザの総数及び支払額が分かるので、割り勘額の算出を行ってもよい。
ステップS920で、サーバ110は、割り勘処理および/または決済処理の完了通知を端末110Aに送信する。
図9に示す割り勘処理では、アカウント認証や残高確認を行わない簡易の割り勘処理を示しているが、図7において説明したアカウント認証や残高確認が行われてもよい。また、ステップS916の後に、端末120Aは、決済用の二次元コード(第2情報コード)を表示画面に表示制御し、この二次元コードを読み取ったPOS端末130等により決済リクエストを送信させるようにしてもよい。また、図9に示す例では、サーバ110が関連管理DBを記憶するようにしたが、各端末で記憶するようにしてもよい。この場合、各端末は、サーバ110から他の端末のアカウント情報を受信し、他のアカウント情報に基づいて、自端末で所定の関係があるか否かを判定してもよい。
<<第2A実施例>>
第1実施形態の第2A実施例は、割り勘ではなく、支払うべきユーザと所定の関係のある他人が、支払うべきユーザに代わって支払う処理(以下、「代理支払い処理」とも言う。)にも適用することが可能である。例えば、子供が使用する端末120の表示画面に二次元コードが表示され、表示された二次元コードを親の端末120が読み取り、親子の関係が承認された場合に、親が子に代わって代理支払い処理を行う。
<<第2A実施例の効果>>
本実施例によれば、支払うべきユーザに代わって、支払うべきユーザと所定の関係を有するユーザが支払額の全額を払うことが可能になる。
<<第2A実施例の動作処理>>
図9に示すシーケンスを用いて、本実施例を説明すると、例えば、端末120Aが子供の端末とし、端末120Bを親の端末とする。ステップS902で、端末120Aの生成部506は、代理支払い用の二次元コードを生成する。
ステップS912、S914、S916、及びS920では、処理対象が、子供の端末120Aから親の端末120Bに代わる。また、ステップS918で、割り勘処理は実行されず、決済処理が実行される。これにより、親のアカウントから支払額の全額が引き出され、店舗側の口座等に振り込まれる。また、子供の端末120A、又は親の端末120Bが決済用の二次元コードを表示画面に表示させ、この二次元コードを読み取ったPOS端末130等に決済リクエストを送信させるようにしてもよい。
<<第3A実施例>>
第1実施形態の第3A実施例は、支払額を割り勘対象の総数で割り切れないとき、各割り勘対象ユーザの割り勘額に対する端数処理が行われる。端数処理は、割り切れない小数点以下の余り部分について、誰に、小数点以下部分をどのように割り振るか等を決めておく処理である。
<<第3A実施例の効果>>
第3A実施例により、割り勘額を算出する際に、割り切れない小数点以下の部分の処理を設定しておくので、任意の支払額、および、割り勘対象ユーザの任意の総数について割り勘処理を適切に実行することが可能になる。
端数処理は、サーバ110の決済事前処理部306、または端末120の取得部510などにより実行される。また、端数処理は、数種類の端数処理を含み、支払額が総数で割り切れなかった場合に、一つの端数処理が予め決定されていてもよいし、数種類の処理の中から1つをユーザに決定させるようにしてもよい。なお、端数処理は、上述又は後述する実施形態又は実施例に適用可能である。
(端数処理1)
端数処理1では、各ユーザの割り算結果(商)の端数を、切り上げ又は切り捨てることにより、各ユーザの割り勘額を決定する。例えば、支払額が10000円であり、割り勘対象ユーザの総数が3人であるとする。この場合、割り勘額の商の余り(小数点以下)を四捨五入すると、一人あたり3333円になるが、割り勘額の合計が、支払額から1円足りなくなる。したがって、3人の割り勘対象ユーザのうち、2人は小数点以下を切り捨て、1人は小数点以下を切り上げるようにする。端数処理では、所定の条件に従って、小数点以下を切り上げる割り勘対象ユーザの一人を決定するようにしておく。例えば、支払い対象ユーザに予め設定されたり、サーバで初めに受信されたアカウント情報を有するユーザに設定されたり、支払い対象ユーザが決定したりするようにしてもよい。
(端数処理2)
端数処理2は、各割り勘対象ユーザの商の端数を切り捨てて、各ユーザの割り勘額を決定する処理を含む。サーバ110は、支払額から、各割り勘対象ユーザの割り勘額の合計を減算した金額を、支払額から割り引く処理を実行する。例えば、支払額が10000円であり、割り勘対象ユーザの総数が3人であるとする。この場合、割り勘額の商の余りを切り捨てると、一人あたり3333円になるが、割り勘額の合計が、支払額から1円足りなくなる。端数処理2では、サーバ110が、支払額から1円割り引く処理を実行する。なお、余りを切り捨てることで不足する不足額について、決済事業者又は店舗が負担するようにしてもよい。
(端数処理3)
端数処理3は、各割り勘対象ユーザの商の端数を切り上げて、各割り勘対象ユーザの割り勘額を決定する処理を含む。サーバ110は、各割り勘対象ユーザの割り勘額の合計から支払額を減算した金額を決済業者に支払う処理を実行する。例えば、支払額が10000円であり、割り勘対象ユーザの総数が3人であるとする。この場合、割り勘額の商の余りを切り上げると、一人あたり3334円になるが、割り勘額の合計が、支払額より2円多くなる。端数処理3では、サーバ110が、支払額より多い2円を決済事業者に支払う処理を実行する。上述した端数処理1〜3について、商の端数の切り捨て、切り上げの位は、小数点以下だけではなく、一の位や十の位でもよい。
(B)ユーザ読取型コード決済における端末の機能構成
次に、ユーザ読取型コード決済における端末の機能構成について説明する。以下、ユーザ読取型コード決済における端末の機能と、店舗読取型コード決済における端末の機能とが同様である場合は、説明を省略する。
通信部504は、店舗に対応づけられた二次元コード(例えば、店舗に掲示された二次元コード、又は店舗に設置されている端末に表示された二次元コード)に含まれる決済情報、自端末120を利用するユーザのアカウント情報などをサーバ110に送信する送信部(第4B送信部)として機能する。決済情報は、限定でなく例として、少なくとも店舗IDを含み、さらに支払額を含んでもよい。例えば、決済情報は、二次元コードがテーブルチェックインなどで用いられる場合には、店舗IDを含み、二次元コードがPOS端末130での支払いなどに用いられる場合には、店舗ID及び支払額を含む。アカウント情報は、限定でなく例として、二次元コードを読み取った端末120を利用する割り勘対象ユーザのユーザID及びパスワードを含む。
また、通信部504は、二次元コードを読み取った各端末120によって送信されたアカウント情報を受信したサーバ110により処理される決済事前処理に基づき、各アカウント情報の総数を用いて決済情報に関連づけられた支払額を除算した割り勘額を受信する受信部(第4B受信部)としても機能する。サーバ110の決済事前処理部306は、受信したアカウント情報の総数と、支払額とを用いて割り勘額を算出することが可能である。
また、通信部504は、割り勘額を含む決済リクエストをサーバに110に送信する送信部(第5B送信部)として機能してもよい。また、決済リクエストには、店舗IDが含まれてもよい。
また、通信部504は、サーバ110から、決済の完了通知を受信する受信部(第5B受信部)として機能してもよい。
取得部510は、二次元コードを読み取った各端末120によって送信されたアカウント情報を受信したサーバ110により処理される決済事前処理に基づき、各アカウント情報に基づく割り勘対象ユーザの総数を用いて、決済情報に関連付けられる支払額を除算した割り勘額を取得する。なお、取得部510は、サーバ110から受信された割り勘額を取得してもよいし、店舗読取型コード決済同様、取得したアカウント総数から支払額を除算して算出してもよい。
読み取り部516は、店舗に対応づけられた二次元コード(例えば、店舗に掲示された二次元コードや、店舗に設置されている端末に表示されている二次元コード)を読み取る。読み取り部516により読み取られた情報は、サーバ110に送信されたり、各種処理に用いられたりする。
<第1実施形態におけるユーザ読取型コード決済時の動作処理>
図10を参照し、第1実施形態に係る通信システム1のユーザ読取型コード決済時の処理について説明する。図10は、第1実施形態に係る通信システム1が行うユーザ読取型コード決済時の処理手順のシーケンスの一例を示す図である。図10に示す例は、POS端末130に表示された二次元コードを、各割り勘対象ユーザが利用する各端末120で読み取って割り勘処理を行う場合を想定したシーケンスである。
ステップS1002で、POS端末130は、決済用の二次元コードを表示画面に表示する。この二次元コードには、限定でなく例として、支払額、及び店舗IDなどの情報が変換されて含まれる。なお、支払額は、ユーザ側で入力されてもよい。
ステップS1004で、端末120Aの読み取り部516は、POS端末130に表示されている二次元コードを読み取る。
ステップS1006で、端末120Aの通信部504は、端末120AのユーザAのアカウント情報、二次元コードから読み取った、またはユーザにより入力された支払額、店舗ID等をサーバ110に送信する。
ステップS1008で、端末120Bの読み取り部516は、POS端末130に表示されている二次元コードを読み取る。
ステップS1010で、端末120Bの通信部504は、端末120BのユーザBのアカウント情報、二次元コードから読み取った支払額、店舗ID等をサーバ110に送信する。
ステップS1012で、端末120Cの読み取り部516は、POS端末130に表示されている二次元コードを読み取る。
ステップS1014で、端末120Cの通信部504は、端末120CのユーザCのアカウント情報、二次元コードから読み取った支払額、店舗ID等をサーバ110に送信する。
ステップS1016で、サーバ110の決済事前処理部306は、例えば、所定時間内に、同じ店舗ID、及び同じ支払額とともに送信されるアカウント情報の総数をカウントする。また、サーバ110の決済事前処理部306は、支払額を総数で除算し、割り勘額を算出する。なお、この時点で、サーバ110側でアカウント認証が行われてもよい。また、アカウント認証に失敗したユーザがいる場合、サーバ110は、アカウント情報の再入力をユーザにリクエストしてもよい。このとき、サーバ110は、割り勘対象ユーザを集めるための所定時間を延長してもよい。
また、サーバ110の決済事前処理部306は、割り勘額の算出後、各割り勘対象ユーザのアカウントの残高を参照し、残高確認処理を行ってもよい。この場合、各割り勘対象ユーザに対する残高確認処理の結果は、各割り勘対象ユーザに通知される。
ステップS1018で、サーバ110の通信部304は、算出された割り勘額を端末120Aに通知する。
ステップS1020で、サーバ110の通信部304は、算出された割り勘額を端末120Bに通知する。
ステップS1022で、サーバ110の通信部304は、算出された割り勘額を端末120Cに通知する。
ステップS1024で、端末120Aの表示制御部508は、割り勘額を表示するよう制御した後、端末120Aの決済制御部514は、決済リクエストをサーバ110に送信するよう通信部504に指示する。
ステップS1026、端末120Bの表示制御部508は、割り勘額を表示するよう制御した後、端末120Bの決済制御部514は、決済リクエストをサーバ110に送信するよう通信部504に指示する。
ステップS1028、端末120Cの表示制御部508は、割り勘額を表示するよう制御した後、端末120Cの決済制御部514は、決済リクエストをサーバ110に送信するよう通信部504に指示する。
ステップS1030で、サーバ110の割り勘処理部308は、決済リクエストに応じて、各割り勘対象ユーザのアカウントに関連付けられる各残高から、割り勘額を引き出す。次に、決済処理部310は、引き出した各割り勘額の総額(支払額)を、決済情報に関連付けられる店舗IDに示される店舗側に支払う処理を実行する。なお、割り勘処理部308は決済処理部310に含まれてもよく、この場合、決済処理部310は、ユーザA、B、Cの残高から割り勘額を引き出し、引き出した割り勘額の合計(支払額)を外部システム140(図7に不図示)に登録されている店舗の口座に振り込むようにしてもよい。
ステップS1032で、サーバ110の通信部304は、割り勘処理、又は決済処理が完了した後、完了通知を端末120Aに送信する。
ステップS1034で、サーバ110の通信部304は、割り勘処理、又は決済処理が完了した後、完了通知を端末120Bに送信する。
ステップS1036で、サーバ110の通信部304は、割り勘処理、又は決済処理が完了した後、完了通知を端末120Cに送信する。
ステップS1038で、サーバ110の通信部304は、割り勘処理、又は決済処理が完了した後、完了通知をPOS端末130に送信する。
<<第1B実施例>>
第1実施形態の第1B実施例は、割り勘対象ユーザが、先に二次元コードを読み取ってチェックインし、支払額が決定した後に、割り勘処理を行って決済を済ませる実施例である。第1B実施例の具体例として、レストランなどでテーブルに二次元コードを掲示しておき、または、テーブルに設置された端末に表示された二次元コードを、そのテーブルに座った各ユーザ(各割り勘対象ユーザ)がそれぞれの端末120で読み取ってチェックイン処理を行う。次に、各ユーザは、料理等を注文し、全ての注文が確定した後、支払額が決定する。その後、テーブルの端末、又は店舗のレジ端末から支払額がサーバに送信され、サーバは、割り勘処理や決済処理を実行する。支払額は、決済IDなどに関連付けられると、事前に送信された決済情報との関連付けが容易になる。
<<第1B実施例の効果>>
本実施例によれば、事前に割り勘対象ユーザの総数や、各割り勘対象ユーザのアカウント認証処理等を済ませておくことができるので、割り勘時に迅速に処理を完了させることが可能になる。例えば、レストランにおいて、ユーザのテーブル着席時等に、各端末120が二次元コードを読み取ってチェックインを済ませ、注文が完了するまでの間に割り勘対象人数の総数やアカウント認証をサーバ110側で済ませておき、支払額が決定した後で、速やかに割り勘処理及び決済処理を実行することが可能になる。また、ユーザは、テーブルでチェックアウト処理を行うことができるので、レジに向かうことなく退店することが可能になる。
<<第1B実施例の動作処理>>
図11は、本実施例に係る通信システム1の処理のシーケンスの一例を示す図である。図11に示すシーケンスを用いて、本実施例を説明すると、例えば、端末120Cがレストランのテーブルに設置された端末とする。この端末120Cに表示された二次元コードをユーザの端末120Aや端末120Bが読み取ってチェックイン処理を行う。また、各ユーザは、端末120Cを用いてメニューの注文をしたり、注文の完了を指示したり、支払額の確認をしたり、決済処理を指示したりすることが可能である。
ステップS1102で、端末120Cは、決済用の二次元コードを表示画面に表示する。この二次元コードには、限定でなく例として、店舗ID、テーブルID、決済IDまたはいずれかの組み合わせが変換されて含まれる。端末120Cは、例えば、レストランのテーブルなどに置いてある注文可能な端末である。
ステップS1104で、端末120Aの読み取り部516は、端末120Cに表示されている二次元コードを読み取る。
ステップS1106で、端末120Aの通信部504は、端末120AのユーザAのアカウント情報、二次元コードから読み取った店舗ID等(決済情報)をサーバ110に送信する。なお、この時点で、サーバ110は、ユーザAのアカウント認証を行ってもよい。店舗IDは、この店舗を支払先とする支払先識別情報としての役割を果たしてもよい。
ステップS1108で、端末120Bの読み取り部516は、端末120Cに表示されている二次元コードを読み取る。
ステップS1110で、端末120Bの通信部504は、端末120BのユーザBのアカウント情報、二次元コードから読み取った店舗ID等をサーバ110に送信する。なお、この時点で、サーバ110は、ユーザBのアカウント認証を行ってもよい。
ステップS1112で、端末120Cは、ユーザA、または、ユーザBによる支払ボタン等の押下により、ユーザA、または、ユーザBにより注文されたメニューの合計金額である支払額を決定する。
ステップS1114で、端末120Cは、ユーザA、または、ユーザBによる支払額の確認ボタン等の押下により、支払リクエストをサーバ110に送信する。支払いリクエストには、限定でなく例として、店舗IDや支払額の情報が含まれる。
ステップS1116で、サーバ110の決済事前処理部306は、支払いリクエストの受信に応じて、例えば、事前にチェックインしていたユーザの総数をカウントする。なお、事前にユーザの総数は算出されていてもよい。また、サーバ110の決済事前処理部306は、支払額を総数で除算し、割り勘額を算出する。なお、この時点で、ユーザA、および/または、ユーザBのアカウント認証が行われていなければ、サーバ110は、ユーザの未実行のアカウント認証を行ってもよい。また、アカウント認証に失敗したユーザがいる場合、サーバ110は、アカウント情報の再入力をユーザにリクエストしてもよい。
また、サーバ110の決済事前処理部306は、割り勘額の算出後、各割り勘対象ユーザのアカウントの残高を参照し、残高確認処理を行ってもよい。この場合、各割り勘対象ユーザに対する残高確認処理の結果は、各割り勘対象ユーザに通知される。
ステップS1118で、サーバ110の通信部304は、算出された割り勘額を端末120Aに通知する。
ステップS1120で、サーバ110の通信部304は、算出された割り勘額を端末120Bに通知する。
ステップS1122で、端末120Aの表示制御部508は、割り勘額を表示するよう制御した後、端末120Aの決済制御部514は、決済リクエストをサーバ110に送信するよう通信部504に指示する。
ステップS1124、端末120Bの表示制御部508は、割り勘額を表示するよう制御した後、端末120Bの決済制御部514は、決済リクエストをサーバ110に送信するよう通信部504に指示する。
ステップS1126で、サーバ110の割り勘処理部308は、決済リクエストに応じて、各割り勘対象ユーザのアカウントに関連付けられる各残高から、割り勘額を引き出す。次に、決済処理部310は、引き出した各割り勘額の総額(支払額)を、決済情報に関連付けられる店舗IDに示される店舗側に支払う処理を実行する。なお、割り勘処理部308は決済処理部310に含まれてもよく、この場合、決済処理部310は、ユーザA、Bの残高から割り勘額を引き出し、引き出した割り勘額の合計(支払額)を外部システム140(図7に不図示)に登録されている店舗の口座に振り込むようにしてもよい。
ステップS1128で、サーバ110の通信部304は、割り勘処理、又は決済処理が完了した後、完了通知をユーザAの端末120Aに送信する。
ステップS1030で、サーバ110の通信部304は、割り勘処理、又は決済処理が完了した後、完了通知をユーザBの端末120Bに送信する。
ステップS1132で、サーバ110の通信部304は、割り勘処理、又は決済処理が完了した後、完了通知を店舗側の端末120Cに送信する。
<<第2B実施例>>
第1実施形態の第2B実施例は、第1実施例Bにおいて、割り勘対象ユーザが、割り勘額を確認することなく、サーバ110は、割り勘処理及び決済処理を行うようにしてもよい。例えば、図11に示すシーケンスにおいて、ステップS1118〜S1124が省略されてもよい。
<<第2B実施例の効果>>
本実施例によれば、チェックアウト処理において、少なくとも1人のユーザからの決済リクエストが送信されないことによる、決済忘れ、または決済処理の中断を防止することができる。特に、割り勘対象の人数が多い場合に、第2B実施例は有効である。
<第2実施形態>
第2実施形態は、割り勘対象ユーザが決済サービス上で所定の関係がないユーザであっても、支払い対象ユーザは、自身との距離を用いて生成された候補者リストの中から、割り勘対象ユーザを選択することができ、割り勘処理をスムーズに行うとともに、割り勘処理の対象を広げることができる例を示す実施形態である。
第2実施形態において、限定でなく例として、端末120は、自端末120を利用する第1ユーザから割り勘リクエストを受け付けた場合、第1ユーザとの距離を用いて生成された、割り勘対象ユーザの候補者リストを表示する。端末120は、候補者リストの中から、実際に割り勘する第2ユーザの選択を受け付ける。第1ユーザの端末120は、選択された第2ユーザの端末120に、割り勘処理を行ってよいかの確認リクエストを送信し、確認リクエストを送信した端末120から確認結果を受信する。第1ユーザの端末120は、第2ユーザから割り勘処理が許可されていれば、割り勘処理や決済処理が実行されるようサーバ110に決済リクエストを送信し、決済が完了した場合、決済完了通知を受信する。
<第2実施形態の効果>
第2実施形態によれば、支払い対象ユーザと所定の関係を有していないユーザであっても、支払い対象ユーザとの距離を用いて生成された候補者リストを受け取るので、その場で割り勘対象ユーザが選択され、選択された割り勘対象ユーザのアカウントから割り勘額を決済させることが可能になる。例えば、飲み会の幹事が、その飲み会で初めて知り合ったメンバーを、候補者リストの中から容易に選択することができるため、スムーズに割り勘処理や決済処理を実行することが可能になる。
<第2実施形態のHW構成>
(1)HW構成
第2実施形態におけるサーバ110、情報処理端末120、およびPOS端末130のHW構成は、第1実施形態におけるサーバ110、情報処理端末120、およびPOS端末130のHW構成と同等であるので、ここでの詳細な説明は省略する。
<第2実施形態の機能構成>
(1)サーバの機能構成
図12は、第2実施形態におけるサーバ110の機能構成の一例を示す図である。図12に開示の機能部は、情報処理装置200が備えるプロセッサ201と、メモリ202と、ストレージ203と、入出力I/F204と、通信I/F205との協働により実現される。
サーバ110は、例えば、入出力部1202と、通信部1204と、決済事前処理部1206と、割り勘処理部1208と、決済処理部1210と、位置特定部1212と、リスト作成部1214と、記憶部1216とを有する。第2実施形態において追加された位置特定部1212と、リスト作成部1214とは、プロセッサ201が、記憶部312に格納されているプログラムを読み出して実行することで実現される。第2実施形態におけるサーバ110の機能構成において、特に言及しない点は第1実施形態における機能と同一でもよい。
通信部1204は、端末120から、候補者リストの検索リクエストを受信する受信部として機能する。また、通信部1204は、各端末120の位置情報を受信する受信部として機能する。また、通信部1204は、リスト作成部1214にて作成された、ユーザAの近傍にいるユーザを含む候補者リストを端末120に送信する送信部として機能する。また、通信部1204は、端末120の位置情報として、端末120が受信した近距離無線識別子を受信する受信部として機能してもよい。
位置特定部1212は、各端末120から通知された各端末120の位置情報に基づいて、各端末120の位置を特定する。例えば、位置特定部1212は、端末120Aから、端末120Aの位置を直接示す位置情報(例えば緯度及び経度)を取得した場合、当該位置情報で示される位置を、端末120Aの位置として特定する。
リスト作成部1214は、位置特定部1212が特定した各端末120の位置情報と、各端末120のユーザIDとを取得し、割り勘対象ユーザの候補者リストを作成する。候補者リストは、取得された位置情報に対応するユーザID、又はユーザIDに関連付けられるニックネームなどを含む。また、リスト作成部1214は、限定でなく例として、端末120Aに近い端末120を利用するユーザが上から順に画面に表示されるように候補者リストを生成してもよい。また、リスト作成部1214は、リスト内のユーザを選択可能にして候補者リストを作成する。リスト作成部1214は、作成した候補者リストを、検索リクエストを送信した端末120Aに送信するよう、通信部1204に指示する。この指示に応じて、通信部1204は、候補者リストを端末120Aに送信する。
(2)端末の機能構成
図13は、第2実施形態における端末120の機能構成の一例を示す図である。図13に開示の機能部は、情報処理装置200が備えるプロセッサ201と、メモリ202と、ストレージ203と、入出力I/F204と、通信I/F205との協働により実現される。
端末120は、入出力部1302と、通信部1304と、読取部1306と、表示制御部1308と、決済制御部1310と、位置情報測定部1312と、リスト作成部1314とを有する。第2実施形態において追加された位置情報測定部1312と、リスト作成部1314とは、プロセッサ201が、記憶部1316に格納されているプログラムを読み出して実行することで実現される。なお、第2実施形態における端末120の機能構成において、特に言及しない点は第1実施形態における機能と同一でもよい。
通信部1304は、位置情報測定部1312で測定した端末120の位置情報を送信する送信部として機能する。また、通信部1304は、サーバ110から、候補者リストを受信する受信部として機能する。また、通信部1304は、他の端末120との近距離無線通信を確立するための無線識別子を送信する送信部として機能してもよい。通信部1304は、他の端末120から無線識別子を受信する受信部として機能してもよい。なお、近距離の無線識別子は、限定ではなく例として、BLE(Bluetooth Low Energy)装置が送信するビーコンに含まれるビーコンID、WiFi(登録商標)装置が送信する無線信号に含まれるSSID、超音波に含まれる任意の識別情報を含んでもよい。
表示制御部1308は、通信部1304で受信された、又はリスト作成部1314で作成された候補者リストを画面に表示する機能を有する。また、表示制御部1308は、候補者リスト内のユーザを選択可能に表示するよう制御する。
位置情報測定部1312は、端末120の現在位置の位置情報を測定する機能を備える。位置情報測定部1312は、限定でなく例として、GPS(Global Positioning System)を用いて、端末120の現在位置の位置情報として、該端末120の緯度および経度を測定する。なお、位置情報測定部1312による端末120の位置情報の測定は、端末120の位置情報を測定できれば、どのような方法を用いてもよい。限定でなく例として、位置情報測定部1312は、IMES(Indoor MEssaging System)、Wi−Fi、RFID(Radio Frequency Identifier)、NFC(Near Field Communication)、BLE(Bluetooth Low Energy)、超音波などの近距離無線通信、LTEやCDMAなどの移動体通信システムなどを利用して、端末120の位置情報を測定してもよい。
リスト作成部1314は、通信部1304により無線通信が確立された他の端末120との位置情報に基づいて、割り勘対象ユーザの候補者リストを作成する。候補者リストは、取得された無線識別子に対応するユーザID、又はユーザIDに関連付けられるニックネームなどを含む。また、リスト作成部1314は、限定でなく例として、端末120Aに近い端末120を利用するユーザが上から順に画面に表示されるように候補者リストを生成してもよい。また、リスト作成部1314は、リスト内のユーザを選択可能にして候補者リストを作成する。リスト作成部1314は、端末120同士の近さの判断について、無線通信の信号強度を用いる。例えば、リスト作成部1314は、確立された無線通信の信号強度が大きければ大きいほど、その端末同士は近いと判断可能である。
<第2実施形態の動作処理>
図14を参照し、第2実施形態に係る通信システム1の処理について説明する。図14は、第2実施形態に係る通信システム1が行う処理手順のシーケンスの一例を示す図である。図14に示す処理は、GPSなどの端末120の位置情報を用いて、ユーザ同士、又は端末120同士の位置関係が把握される例である。
ステップS1402で、端末120Aの入出力部502は、ユーザから、決済画面において割り勘を選択するボタンの押下(タップ)を受け付ける。
ステップS1404で、端末120Aの位置情報測定部1312は、自身の位置情報を測定する。端末120Aの位置情報測定部1312は、サーバ110に位置情報の検索リクエストを送信するよう通信部1304に指示する。検索リクエストは、例えば端末120Aの位置情報とともに送信されてもよいし、それぞれは別々に送信されてもよい。
ステップS1406で、端末110Bの位置情報測定部1312は、自身の位置情報を測定し、測定した位置情報と、端末110Bを利用するユーザのユーザIDとをサーバ110に送信するよう通信部1304に指示する。
ステップS1408で、端末110Cの位置情報測定部1312は、自身の位置情報を測定し、測定した位置情報と、端末110Cを利用するユーザのユーザIDとをサーバ110に送信するよう通信部1304に指示する。なお、ステップS1404、S1406、S1408で送信される位置情報は、定期的に各端末120からサーバ110に送信されるようにしてもよいし、サーバ110からの指示に基づき、位置情報が各端末120からサーバ110に送信されるようにしてもよい。
ステップS1410で、サーバ110のリスト作成部1214は、各端末120から取得した位置情報に基づき、割り勘対象ユーザの候補者リストを作成する。例えば、サーバ110のリスト作成部1214は、端末120Aの位置に近い順に、ユーザID、又はユーザIDに関連付けられるニックネームなどを含むようにする。
ステップS1412で、サーバ110の通信部1204は、リスト作成部1214により作成された候補者リストを、検索リクエスト送信した端末120Aに送信する。
ステップS1414で、端末120Aの表示制御部1308は、サーバ110から取得された候補者リストを、表示画面に表示するよう制御する。このとき、候補者リスト内の各ユーザは、選択可能に表示される。
ステップS1416で、端末120Aの入出力部1302は、候補者リストの表示画面から、割り勘対象ユーザを選択する指示を受け付ける。例えば、候補者リスト内のユーザにラジオボタンなどの選択可能なUI(User Interface)部品が表示される場合、ユーザAが、実際の割り勘対象ユーザについて、UI部品を押下するなどして選択することを、入出力部1302が受け付ける。なお、この例では、ユーザBが割り勘対象として選択されたとする。
ステップS1418で、端末120Aの通信部1304は、候補者リスト内でユーザAにより選択された割り勘対象ユーザ(図14に示す例ではユーザB)に、割り勘リクエストを送信する。
ステップS1420で、端末120Bの表示制御部1308は、割り勘リクエストの受信に応じて、割り勘を許可するか拒否するかの選択画面を表示画面に表示するよう制御する。
ステップS1422で、端末120Bの通信部1304は、ユーザBが選択画面から許可を選択したことに応じて、許可通知をサーバ110に送信する。これにより、ユーザBの許可通知をユーザBの端末120Bからサーバ110に送信することで、許可の信憑性を高めることができる。なお、ユーザBが割り勘を拒否した場合は、ユーザA単独の決済処理や他のユーザとの割り勘処理が行われる(図14に不図示)。
ステップS1424で、サーバ110は、ユーザBが割り勘を許可したことを検知すると、ユーザBの許可通知を、端末120Aに送信する。
ステップS1426で、端末120Aの通信部1304は、ユーザBからの許可通知を受信すると、決済リクエストをサーバ110に送信する。決済リクエストは、割り勘額又は支払額、及び支払先である店舗IDを含み、割り勘の対象となるユーザAのユーザIDとユーザBのユーザIDとをさらに含んでもよい。なお、割り勘額は端末120Aを使用するユーザAによって、ユーザ毎に設定されても良い。
ステップS1428で、サーバ110の割り勘処理部1208及び決済処理部1210は、決済リクエストに含まれる情報に基づいて、支払先を特定し、上述したユーザAとユーザBとの割り勘処理、店舗等への決済処理を実行する。ステップS1428では、割り勘処理と、決済処理との順序は問わない。例えば、先に、ユーザBのアカウントから割り勘額を引き出し、ユーザAの残高に振り込んだ後で、ユーザAから支払額を店舗の口座に振り込んでもよい。また、先に、ユーザAのアカウントから支払額を店舗の口座に振り込んだ後で、ユーザBの残高から割り勘額を減算し、ユーザAの残高に加算するようにしてもよい。
ステップS1430で、サーバ110の決済処理部1210は、支払先である店舗IDに関連付けられる店舗口座を保持する外部システム140に、支払額を支払う処理を行う。
ステップS1432で、外部システム140は、支払いが完了すると、支払い完了通知をサーバ110に送信する。
ステップS1434で、サーバ110の通信部1204は外部システム140から支払完了通知を受信すると、端末120Aに決済完了通知を送信する。
ステップS1436で、サーバ110の通信部1204は外部システム140から支払完了通知を受信すると、端末120Bに決済完了通知を送信する。ステップS1434、及びS1436は、その順序について問わない。
なお、ステップS1422の許可通知は、端末120Bから端末120Aに送信されてもよい。この場合、ステップS1424は不要であり、ステップS1426において決済リクエストに、許可をした割り勘対象ユーザのユーザIDが含まれる。これにより、サーバ110を介するステップを減らすことで、より迅速な割り勘処理を実現することが可能になる。
なお、ステップS1404からステップS1414までの候補者リスト生成処理及び表示処理は、S1450として表記される。このステップS1450の別の処理について、図15を用いて説明する。
図15は、第2実施形態に係る各端末120が行う候補者リストの作成および表示に関する処理手順のシーケンスの一例を示す図である。図15に示す処理は、各端末120が近距離無線通信を用いて、ユーザ同士、又は端末120同士の位置関係が把握される例である。図15に示す例では、限定でなく例として、BLEを用いてセッションを確立するが、超音波、Wi−Fiなどのその他の無線通信を用いてセッションが確立されてもよい。
ステップS1502で、端末120Aの通信部1304は、BLEを用いて、通信可能な範囲内に存在する端末120Bとセッションを確立する。
ステップS1504で、端末120Aの通信部1304は、BLEを用いて、通信可能な範囲内に存在する端末120Cとセッションを確立する。
ステップS1506で、端末120Aのリスト作成部1314は、端末120Aとセッションを確立した各端末に基づいて、割り勘対象ユーザの候補者リストを作成する。例えば、端末120Aのリスト作成部1314は、端末120Aとの無線通信における信号強度を用いて、信号強度が強いほど、端末120Aに近いと判断し、端末120Aに近い順に候補者リストを作成してもよい。また、端末120Aのリスト作成部1314は、候補者リストに、ユーザID、又はユーザIDに関連付けられるニックネームなど(以下、ユーザID等とも称す。)を含むようにしてもよい。
ステップS1508で、端末120Aの表示制御部1308は、リスト作成部1314が作成した候補者リストを、表示画面に表示するよう制御する。このとき、候補者リスト内の各ユーザは、選択可能に表示される。以降の処理は、図14に示すステップS1416と同様である。
これにより、近距離無線通信を用いても、ユーザAの近傍にいる割り勘対象のユーザを含む候補者リストの作成が可能になる。GPSを用いて位置情報が取得できない場合等に、本実施例では近距離無線通信を用いることで、適切に候補者リストを作成することができる。
なお、図14に示すGPSを用いた各端末の位置情報の取得と、近距離無線通信を用いた各端末の位置情報の取得とを適宜組み合わせてもよい。限定でなく例として、GPSを用いた位置情報の取得が優先的に行われ、候補者リストが生成される。次に、ユーザAが、候補者リスト内にいるはずのユーザ(例、ユーザB)がいないことに気づいた場合、近距離無線通信による候補者リスト作成を指示する。例えば、候補者リストの表示画面内に、近距離無線通信の実行ボタン等が設けられれば良い。また、候補者リスト内にいるはずのユーザとは、例えば、ユーザAは、同席しているユーザBの存在に気付いているが、候補者リスト内にユーザBが含まれていないことをいう。この状況は、各端末のユーザが、アプリケーションの設定においてGPSの位置情報を出力することを許可していない場合等に起こりうる。
ユーザAが、候補者リストの表示画面等から近距離無線通信の実行を指示すると、端末120Aの入出力部1302が近距離無線通信の実行を検知し、端末120Aの通信部1304により近距離無線通信が実行される。このとき、端末120Aのリスト作成部1314は、近距離無線通信を用いて新たにユーザID等を取得した場合、候補者リスト内に、取得された新たなユーザID等を追加する。端末120Aのリスト作成部1314は、既に候補者リストに含まれるユーザID等を再度取得した場合、一方を破棄するようにすればよい。
これにより、GPSを用いた位置情報の取得と、近距離無線通信を用いた位置情報の取得とを組み合わせることで、候補者リスト内に、より適切に割り勘対象ユーザを含めることができるようになる。
<第2実施形態の端末に係るコード決済時の表示態様>
図16は、第2実施形態に係る端末120Aに表示される画面の一例を示す図である。図16(A)は、支払額及び割り勘選択ボタンを含む決済画面の一例を示している。図16(A)に示す決済画面は、支払額の表示項目、及び割り勘の選択ボタンを少なくとも含む。図16(A)に示す決済画面は、例えば、図14に示すステップS1402の処理で表示される画面に対応する。図16(A)に示す画面で、ユーザがYESを押下した場合、図14に示すステップS1404の処理が実行され、ユーザがNOを押下した場合、単独での決済リクエストがサーバ110に送信される(図14に不図示)。
図16(B)は、候補者リストを表示する画面の一例を示している。図16(B)に示す画面は、サーバ110のリスト作成部1214、または端末120Aのリスト作成部1314により作成された候補者リストを含む。図16(B)に示す例では、ユーザBとユーザCとが候補者リスト内に表示され、それぞれ選択可能なラジオボタンRが表示される。候補者リスト内に表示される名称は、ユーザがアプリケーションで設定しているニックネームや、ユーザID、氏名等、ユーザ管理DBに登録されているユーザを識別できる情報であればよい。図16(B)に示す画面は、例えば、図14に示すステップS1414の処理で表示される画面に対応する。
図16(C)は、割り勘許可の待ち画面の一例を示している。図16(C)に示す画面は、ユーザBが割り勘を未だ許可していない状況を示す。例えば、図16(C)に示す画面は、図14に示すステップS1418からS1422までの間に、端末120Aに表示される画面に対応する。
図16(D)は、割り勘許可の通知画面の一例を示している。図16(D)に示す画面は、図14に示すステップS1424で端末120Aの通信部1304が許可通知を受信した後、端末120Aの表示制御部1308が、図16(D)に示す画面を表示するよう制御する。図16(D)に示す画面で、ユーザAがYESを押下した場合、ステップS1426の処理が実行され、ユーザAがNOを押下した場合、所定の処理に戻ってもよい。所定の処理とは、限定でなく例として、ステップS1414における候補者リスト選択などである。図16(D)に示す画面は、例えば、図14に示すステップS1424の処理の後に表示される画面に対応する。
図16(E)は、決済完了画面の一例を示している。図16(E)に示す画面は、店舗への支払いと、割り勘とが完了したことをユーザAに通知する画面の例である。図16(E)に示す画面は、図14に示すステップS1434の処理が行われた後、端末120Aの表示画面に表示されてもよい。
<<第1実施例>>
第2実施形態の第1実施例は、候補者リストの表示について、支払対象ユーザの位置と候補者リスト内のユーザの位置とに応じて、支払い対象ユーザを中心に、同心円状にリスト内のユーザを表示する。例えば、サーバ110のリスト作成部1214は、位置特定部1212により特定された各端末120の位置情報を用いて、同心円状に、各端末120の位置に基づいて各ユーザを配置する。候補者リスト表示は、GPSを用いた位置情報が取得される場合に適用可能である。
<<第1実施例の効果>>
本実施例によれば、ユーザは、候補者リストを見る際に、どの位置にどのユーザがいるかを、実際のユーザの着席位置に対応して容易に把握することができ、候補者リストの中から割り勘対象ユーザを容易に特定することができる。
<<第1実施例の端末に係る候補者リストの表示態様>>
図17は、第1実施例に係る端末120Aに表示される候補者リストの表示画面の一例を示す図である。図17に示す例では、支払い対象ユーザUAを中心に、同心円状に候補者リスト内の各位置にユーザ(例、ユーザB、ユーザC、ユーザD)が表示される。なお、図17に示す放射線状に表示される点線の円は、所定距離ごとに表示される。例えば、所定距離は、設定画面などから、3m、5mなどの距離をユーザが適宜変更できるように設計される。また、図17に示す候補者リストは、ドラッグなどのユーザ操作により、マップ操作のように位置をずらしたり、ピンチアウトなどのユーザ操作により、縮尺を変更したりして表示されてもよい。
<<第2実施例>>
第2実施形態の第2実施例は、支払い対象ユーザAの端末120Aの決済制御部1310が、サーバ110に決済リクエストを送信する際に、ユーザごとに、ユーザIDと割り勘額とを含む決済リクエストを送信する。サーバ110の通信部1204が、ユーザごとの決済リクエストを受信し、決済処理部1210及び決済処理部1210が、ユーザごとに、店舗の口座に割り勘額を支払う処理を実行する。サーバ110は、決済完了を通知する際には、領収書としての形式にしたがって、各ユーザの端末120に決済完了の通知を行う。領収書としての形式とは、限定でなく例として、日付、宛名、金額、但し書き、店名、店の押印などの項目を含む。
<<第2実施例の効果>>
本実施例によれば、各ユーザは、自身の領収書を受領することができるため、割り勘額を経費として支出することが可能になる。
<<第2実施例の端末に係る決済完了通知の表示態様>>
図18は、第2実施例に係る端末120に表示される決済完了通知の表示画面の一例を示す図である。図18(A)に示す例では、ユーザAの決済完了通知が端末120Aの表示画面に表示される。図18(A)に示す決済完了通知は、限定でなく例として、日付、宛名、金額、但し書き、店名などを含む。
図18(B)に示す例では、ユーザBの決済完了通知が端末120Bの表示画面に表示される。図18(B)に示す決済完了通知は、限定でなく例として、日付、宛名、金額、但し書き、店名などを含む。
また、この決済完了通知には、店舗の印鑑を示す電子スタンプが付与されてもよい。電子スタンプについては、サーバ110が、店舗IDなどに関連付けて保持しておく。サーバ110は、外部システム140から支払の完了通知を受信した際に、この電子スタンプを読みだして、決済完了通知に付与してもよい。
また、宛名については、ユーザごとに事前にサーバ110に登録されていてもよい。例えば、ユーザ管理DBのユーザIDごとに、決済完了通知用の宛名の項目を設け、氏名や会社名などを事前にユーザに登録させておいてもよい。また、決済リクエストを通知する際、または割り勘処理を許可する際などに、宛名、および/または但し書きを、その都度ユーザに入力させるようにしてもよい。各端末120の表示制御部1308は、宛名、および/または但し書きを入力するためのUI部品を表示画面に表示し、このUI部品に入力された宛名、および/または、但し書きを、決済IDなどに関連付けてサーバ110に送信する。サーバ110は、受信した宛名、および/または、但し書きを保持しておき、決済完了通知を各端末120に送信する際、保持しておいた宛名、および/または、但し書きを決済完了通知に含める。これにより、各ユーザは、領収書にもなりうる決済完了通知を受領することが可能になる。
<<第3実施例>>
第2実施形態の第3実施例は、サーバ110が候補者リストを作成する際に、割り勘対象ユーザに対して、ユーザ情報(例、ユーザIDなど)の送信可否を確認するようにする。例えば、サーバ110は、割り勘対象ユーザの候補者リストを作成する前に、ユーザ情報の送信の可否を、割り勘対象ユーザに問い合わせるようにする。例えば、サーバ110は、図14に示すステップS1406、およびステップS1408の処理の後に、各端末(例、端末120Bおよび端末120C)に、ユーザ情報の送信の可否を問い合わせる。サーバ110のリスト作成部1214は、各端末からユーザ情報の送信の可否を取得し、送信許可がなされたユーザを候補者リストに含めるようにする。
<<第3実施例の効果>>
本実施例によれば、各ユーザは、自身のユーザ情報を他のユーザに教えるか否かを決定することができるので、無断でユーザ情報が他の端末に送信されることを防止することができ、セキュリティの向上を図ることができる。なお、各ユーザは、アプリケーションの設定画面などで、自身のユーザ情報を許可なしで送信する、その都度送信の可否を問い合わせる、または、ユーザ情報の送信を許可しない、を事前に選択しておいてもよい。これにより、ユーザ情報の送信の可否、および/または、問い合わせタイミングをユーザの希望に合わせることが可能になる。サーバ110は、事前に設定された、ユーザ情報の送信設定を、ユーザ管理DBのユーザIDに関連付けて記憶しておいてもよい。