<法的事項の遵守>
本明細書に記載の開示は、通信の秘密など、本開示の実施に必要な実施国の法的事項遵守を前提とすることに留意されたい。
本開示に係るプログラム、情報処理方法、端末、サーバ等を実施するための実施形態について、図面を参照して説明する。
<概要>
近年、ネットワークサービスに関連するアプリケーション(アプリケーションソフトウェア)として、電子貨幣による支払いを行うためのアプリケーション(支払いアプリケーション)、電子貨幣による決済を行うためのアプリケーション(決済アプリケーション)、電子貨幣による送金/受取を行うためのアプリケーション(送金アプリケーション)といったアプリケーションや、これらのアプリケーションの一部の機能または全部の機能を集約したアプリケーションが普及しつつあり、端末20のユーザが、これらのアプリケーションを用いて、電子貨幣に関する各種のサービスを受けることが可能になってきている。
「電子貨幣」とは、物理的貨幣と区別される電子的な貨幣であって、上記の各種のアプリケーションにおいて管理される端末20、または端末20のユーザが所有する電子的な貨幣を意味する。
なお、電子貨幣は、「電子マネー」や「デジタル通貨(デジタル貨幣)」と表現してもよいし、そのようにしなくてもよい。
また、「電子貨幣(電子マネー)」や「デジタル通貨(デジタル貨幣)」として、法定通貨を用いてもよいし、仮想通貨を用いてもよい。
また、「電子貨幣(電子マネー)」や「デジタル通貨(デジタル貨幣)」には、暗号通貨(暗号資産)を含めてもよい。
また、仮想通貨には、クーポンなどの物的貨幣を含めてもよい。
本明細書では、適宜「通信I/Fによって」という表現を使用する。これは、装置が、限定ではなく例として、制御部(プロセッサー等)の制御に基づいて、通信I/Fを介して(通信部を介して)、各種の情報やデータを送受信することを示す。
また、本明細書において、「決済」とは、電子的な決済(電子決済)のことを意味する。この一例は、上記の電子貨幣を用いた電子決済である。
以下の実施例では、この決済の一種として「買い物決済」を例示する。買い物決済は、商品の購入やサービスの提供等の対価としての支払いを行うための決済であり、端末20のユーザによる決済(端末20のユーザによって行われた決済)の一例である。
また、買い物決済履歴は、端末20のユーザによる決済に関する処理(上記の端末20のユーザによる決済について端末20によって実行された処理)に基づく決済情報の一例である。
「決済に関する処理」とは、限定ではなく例として、端末20が実行する買い物決済に関する処理であって、買い物決済を行うためのコード情報をサーバ等から取得する処理(コード情報の生成をサーバ等に依頼する処理や、生成されたコード情報をサーバ等から受信する処理を含む。)、取得したコード情報を表示する処理、買い物決済の決済結果(決済通知を含む。)をサーバ等から取得する処理などの、買い物決済を行う上で何らかの関連のある処理、より具体的には、買い物決済を行う上で関連のある処理として端末20で実行される処理全般を含むものである。
「コード情報」とは、コード画像や、コード画像に格納される情報(格納情報、エンコード情報)を含むものである。
また、本明細書において、「割り勘」とは、1または複数の買い物決済履歴に基づく支払い済み金額を、複数の端末20のユーザで負担することを意味する。
また、本明細書における割り勘は、必ずしも複数の端末20のユーザで金額を等分することに限らず、複数の端末20のユーザで金額を案分(按分)する場合も含むものとする。「等分」を同じ割合で分けることを意味するものとし、「案分」を異なる割合で分けることを意味するものとする。
また、割り勘の金銭を精算することを「割り勘精算」と称し、この割り勘精算を実現するための処理のことを「割り勘精算処理」と称する。
なお、割り勘精算は、割り勘の決済という意味で「割り勘決済」と表現してもよく、割り勘精算処理は「割り勘決済処理」と表現してもよいし、そのようにしなくてもよい。
また、本明細書において、端末20が情報を送信することには、異なる端末20に情報を送信することの他、サーバ10やメッセージングサーバ40等のサーバに情報を送信することも含まれるものとする。
<第1実施例>
第1実施例は、2人のユーザの端末20間で、いずれか一方の端末20のユーザによる買い物決済の決済金額の割り勘を実現するための実施例である。
第1実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
[システム構成]
本実施例に係る通信システムでは、限定ではなく例として、ネットワーク(インターネット等)を介して、少なくとも複数の端末20(端末20A,端末20B,端末20C,・・・)が接続される。
端末20(端末20A,端末20B,端末20C,・・・)(限定ではなく、端末、情報処理装置の一例)は、各実施形態において記載する機能を実現できる情報処理端末であればどのような端末であってもよい。端末20は、限定ではなく例として、スマートフォン、携帯電話(フィーチャーフォン)、コンピュータ(限定ではなく例として、デスクトップ、ラップトップ、タブレットなど)、メディアコンピュータプラットホーム(限定ではなく例として、ケーブル、衛星セットトップボックス、デジタルビデオレコーダ)、ハンドヘルドコンピュータデバイス(限定ではなく例として、PDA・(personal digital assistant)、電子メールクライアントなど)、ウェアラブル端末(メガネ型デバイス、時計型デバイスなど)、または他種のコンピュータ、またはコミュニケーションプラットホームを含む。また、端末20は情報処理端末と表現されてもよい。
端末20A、端末20Bおよび端末20Cの構成は基本的には同一であるため、以下の説明では端末20について説明する。
また、第2実施例以降で図示・詳細に説明するが、端末20の制御部を制御部21とし、端末20の通信部を通信I/F(インタフェース)22として説明する。
図1は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。
左側から順に、端末A(限定ではなく例として、ユーザA.Aの端末20)の制御部21が実行する割り勘処理、端末B(限定ではなく例として、ユーザB.Bの端末20)の制御部21が実行する割り勘処理の一例をそれぞれ示している。以下では、端末Aのユーザを「ユーザA.A」と称し、端末Bのユーザを「ユーザB.B」と称して説明する。
この例では、ユーザA.Aによる買い物決済履歴(より具体的には買い物決済金額)を、ユーザB.Bとの間で割り勘する場合を例に挙げて説明する。
買い物決済履歴には、買い物決済金額の他、限定ではなく例として、商品を購入した店舗やサービスの提供を受けた店舗の名称(店舗名)、購入した商品や提供されたサービスの名称や種類、決済を行った日時(買い物決済日時)、決済を行った金額(買い物決済金額)といった複数の情報を含めることができる。
また、買い物決済履歴は、買い物決済履歴情報と表現することもできる。
まず、端末Aの制御部21は、第1の買い物決済履歴選択処理を実行する(A10)。具体的には、端末Aの制御部21は、限定ではなく例として、端末Aの記憶部28に記憶された、ユーザA.Aによる複数の買い物決済履歴の中から、入出力部23に対する買い物決済履歴を選択する操作入力に基づいて、少なくとも1つの買い物決済履歴を選択する。本実施例における買い物決済履歴は、端末のユーザによる第1決済に関する処理に基づく第1決済情報の一例である。
その後、端末Aの制御部21は、A10で選択された買い物決済履歴を、通信I/F22によって端末Bに送信する(A20)。具体的には、限定ではなく例として、入出力部23に対する買い物決済履歴を送信する操作入力に基づいて、A10で選択された買い物決済履歴を送信する。
この場合、送信する買い物決済履歴には、限定ではなく例として、少なくとも買い物決済金額の情報を含めるようにすることができる。買い物決済金額とは、買い物決済で実際に決済された金額(買い物決済でユーザが実際に支払った金額)である。
端末Aから買い物決済履歴を受信すると(B20)、端末Bの制御部21は、割り勘における過不足の金額(以下、「過不足金額」と称する。)を計算する(B30)。具体的には、端末Aから受信した買い物決済履歴の買い物決済金額に基づいて、限定ではなく例として、ユーザB.Bの過不足金額(この例ではユーザB.BがユーザA.Aに送金する金額)を計算する。
ここで、ユーザが買い物決済で支払い済みの金額を、そのユーザの「支払い済み金額」と称する。割り勘対象とされた買い物決済履歴の決済を行ったユーザについては、その買い物決済履歴の買い物決済金額が支払い済み金額となる。複数の買い物決済履歴が割り勘対象とされた場合は、それらの買い物決済履歴の買い物決済金額を合計した金額が支払い済み金額となる。
一方、その買い物決済履歴の決済を行っていないユーザについては、支払い済み金額は「0円」となる。
本実施例では、ユーザB.Bは買い物決済履歴を割り勘対象として登録せず、ユーザA.Aのみが買い物決済履歴を割り勘対象として登録する場合を考え、ユーザA.Aの支払い済み金額を、ユーザB.Bと均等割で割り勘する場合を考える。
この場合、1人あたりの負担額(以下、「1人あたり金額」と称する。)を「割り勘対象とされた支払い済み金額(この例ではユーザA.Aの支払い済み金額)÷割り勘を行う人数(この例では2人)」として計算する。
この場合、B30では、ユーザの過不足金額を、限定ではなく例として、「そのユーザの過不足金額=そのユーザの支払い済み金額−1人あたり金額」として計算する。計算された過不足金額が正の値である場合は、そのユーザは金銭を受け取る側(受取)であることを意味し、計算された過不足金額が負の値である場合は、そのユーザは金銭を支払う側(支払い)であることを意味する。
限定ではなく例として、ユーザA.Aが買い物決済によって支払った支払い済み金額(=買い物決済金額)を「1,000円」とし、これをユーザB.Bと均等割で割り勘する場合を考える。ユーザB.Bの支払い済み金額は「0円」であり、1人あたり金額は「1,000円÷2人=500円」となるため、ユーザB.Bの過不足金額は「0円−500円=−500円」、つまり「500円 支払い」として計算される。
なお、これはあくまでも一例であり、これに限定されない。
B30において、ユーザB.Bの過不足金額ではなく、ユーザA.Aの過不足金額を計算するようにしてもよいし、そのようにしなくてもよい。この場合、上記の例では、ユーザA.Aの支払い済み金額は「1,000円」であり、1人あたり金額は「500円」であるため、ユーザA.Aの過不足金額は「1,000円−500円=+500円」、つまり「500円 受取」として算出される。
また、B30において、ユーザA.Aの過不足金額とユーザB.Bの過不足金額との両方の金額を計算するようにしてもよいし、そのようにしなくてもよい。
また、割り勘の割合は、上記のように均等割(等分)としてもよいし、異なる割合(案分)としてもよい。
その後、端末Bの制御部21は、B30で計算された過不足金額の情報(以下、「過不足金額情報」と称する。)を通信I/F22によって端末Aに送信する(B40)。
ここで、端末Aに送信する過不足金額情報は、ユーザB.Bの過不足金額の情報としてもよいし、ユーザA.Aの過不足金額の情報としてもよいし、ユーザA.AとユーザB.Bとの両方の過不足金額の情報としてもよい。
割り勘精算を行う場合、金額を支払う側のユーザの端末20は、そのユーザの過不足金額を電子貨幣によって相手方のユーザの端末20に送金する送金処理を行う。一方、金銭を受け取る側のユーザの端末20は、相手方のユーザの端末20からそのユーザの過不足金額分の金銭を電子貨幣によって受け取る受取処理を行う。
端末20のユーザが異なる端末20のユーザに金銭を送ること(または端末20が異なる端末20に金銭を送ること)を「送金」と称し、この送金を実現するための処理を「送金処理」と称する。
それに対し、端末20のユーザが異なる端末20のユーザから送金された金銭を受け取ること(または端末20が異なる端末20から送金された金銭を受け取ること)を「受取」と称し、この受取を実現するための処理を「受取処理」と称する。
なお、「受取」、「受取処理」は、金銭を受け取るという意味で、それぞれ「受金」、「受金処理」のように表現することもできる。
端末Bから過不足金額情報を受信すると(A40)、端末Aの制御部21は、端末Bの制御部21との間で、割り勘精算処理を行う(A50、B50)。具体的には、限定ではなく例として、端末Bの制御部21は、ユーザB.Bの過不足金額を通信I/F22によって端末Aに送金する。一方、端末Aの制御部21は、通信I/F22によって端末BからユーザB.Bの過不足金額に相当する金銭を受け取る。
本実施例における割り勘精算処理は、端末20の制御部21によって実行される送金処理/受取処理の一例である。
1つの手法として、割り勘精算処理は、端末Aと端末Bとの間で、限定ではなく例として、インターネットバンキング(オンラインバンキング)等を利用して行うようにすることができる。
また、他の手法として、割り勘精算処理は、後述する支払いサービス(支払いアプリケーション)等の電子貨幣に関するサービスを利用して行うようにすることもできる。
その後、端末Aの制御部21は、割り勘精算の結果(以下、「割り勘精算結果」と称する。)を表示部24に表示させる(A60)。具体的には、限定ではなく例として、受取処理で受け取った受取金額(または送金処理で相手方から送金された送金金額)を表示部24に表示させる。
その後、端末Aの制御部21は、処理を終了するか否かを判定し(A90)、処理を継続すると判定したならば(A90:NO)、A10に処理を戻す。一方、処理を終了すると判定したならば(A90:YES)、割り勘処理を終了する。
同様に、端末Bの制御部21は、割り勘精算結果を表示部24に表示させる(B60)。具体的には、限定ではなく例として、送金処理で送金した送金金額(または受取処理で相手方が受け取る金額)を表示部24に表示させる。
その後、端末Bの制御部21は、処理を終了するか否かを判定し(B90)、処理を継続すると判定したならば(B90:NO)、B20に処理を戻す。一方、処理を終了すると判定したならば(B90:YES)、割り勘処理を終了する。
<送金処理/受取処理の関係>
基本的には、上記のように、買い物決済履歴を送信する端末20のユーザ(第1のユーザ)が、買い物決済によって金額を支払い済みのユーザであり、割り勘を依頼する側であるため、第1のユーザの端末20は受取処理を実行することになる。それに対し、買い物決済履歴を受信する端末20のユーザ(第2のユーザ)は、割り勘を依頼される側であるため、第2のユーザの端末20は送金処理を実行することになる。
しかし、詳細は後述するが、限定ではなく例として、本開示の手法では、第1のユーザによる買い物決済履歴ばかりでなく第2のユーザによる買い物決済履歴も、一緒に割り勘対象にするといったことも可能である。このような場合、第1のユーザの端末20が送金処理を実行し、第2のユーザの端末20が受取処理を実行することとなる場合もあり得る。このため、端末20は、送金処理と受取処理とのうちのいずれかの処理を実行することになる。
<第1実施例の効果>
第1実施例は、端末20が、端末20のユーザによる端末20に対する操作入力(限定ではなく、端末のユーザによる端末に対する入力の一例)に基づいて、買い物決済履歴(限定ではなく、第1決済情報の一例)を通信I/F22(限定ではなく、端末の通信部の一例)によって異なる端末20に送信する。また、端末20は、送信した買い物決済履歴に基づく過不足金額(限定ではなく、第1決済情報に基づく、端末のユーザが送金、または受け取る第1金額と、端末とは異なる端末のユーザが送金、または受け取る第2金額とのうち、少なくとも第1金額の一例)の情報を通信I/F22によって異なる端末20から受信する。そして、端末20は、過不足金額に基づき、割り勘精算処理(限定ではなく、第1金額に基づく送金処理、または受取処理の一例)を制御部21(限定ではなく、端末の制御部の一例)によって実行する構成を示している。
このような構成により得られる効果の一例として、端末は、端末のユーザによる第1決済に関する処理に基づく第1決済情報を送信したことに基づいて、第1金額に基づく送金処理、または受取処理を制御部によって実行して、金銭を簡単に送金する、または受け取ることが可能となり、ユーザの利便性を向上させることができる。
また、第1実施例は、端末20の制御部21は、メモリに記憶されたプログラムを読み出し、このプログラムに基づく処理を実行するプロセッサを備える。プロセッサは、端末20のユーザによる端末20に対する操作入力(限定ではなく、端末のユーザによる端末に対する入力の一例)に基づいて、買い物決済履歴(限定ではなく、端末のユーザによる第1決済に関する処理に基づく第1決済情報の一例)を通信I/F22(限定ではなく、端末の通信部の一例)によって異なる端末20に送信する。また、プロセッサは、送信した買い物決済履歴に基づく過不足金額(限定ではなく、第1決済情報に基づく、端末のユーザが送金、または受け取る第1金額と、端末とは異なる端末のユーザが送金、または受け取る第2金額とのうち、少なくとも第1金額の一例)の情報を通信I/F22によって異なる端末20から受信する。そして、プロセッサは、過不足金額に基づき、割り勘精算処理(限定ではなく、第1金額に基づく送金処理、または受取処理の一例)を実行する構成を示している。
このような構成によっても、上記と同様の効果を得ることができる。
また、第1実施例は、上記の送金処理、または受取処理は、異なる端末20のユーザ(限定ではなく、異なる端末のユーザの一例)への送金、または受け取りを含む処理である構成を示している。
このような構成により、異なる端末のユーザへの送金、または異なる端末のユーザからの金銭の受け取りを簡単に実現することができる。
また、第1実施例は、買い物決済履歴は、買い物決済金額の情報(限定ではなく、端末のユーザによる第1決済の金額の情報の一例)を含む構成を示している。
このような構成により得られる効果の一例として、端末は、端末のユーザによる第1決済の金額の情報を含む第1決済情報を送信することによって、少なくとも第1金額の情報を受信して取得することができる。
また、第1実施例は、買い物決済履歴は、買い物決済の決済履歴(限定ではなく、第1決済の決済履歴の一例)である構成を示している。
このような構成により得られる効果の一例として、端末は、第1決済の決済履歴を送信することによって、少なくとも第1金額の情報を受信して取得することができる。
また、第1実施例は、端末20が、自己の端末20のユーザによる複数の買い物決済履歴(限定ではなく、複数の決済情報の一例)のうち、自己の端末20のユーザによって選択された買い物決済履歴(限定ではなく、第1決済情報の一例)を通信I/F22(限定ではなく、端末の通信部の一例)によって異なる端末20に送信する。また、端末20は、送信された買い物決済履歴に基づく過不足金額(限定ではなく、第1決済情報に基づく、端末のユーザが送金、または受け取る第1金額と、端末とは異なる端末のユーザが送金、または受け取る第2金額とのうち、少なくとも第1金額の一例)の情報を通信I/F22によって端末20から受信する。そして、端末20は、過不足金額に基づき、割り勘精算処理(限定ではなく、第1金額に基づく送金処理、または受取処理の一例)を制御部21(限定ではなく、端末の制御部の一例)によって実行する構成を示している。
このような構成により得られる効果の一例として、端末は、端末のユーザによる決済に関する複数の決済情報のうち、第1決済情報を通信部によって送信したことに基づいて、その第1決済情報に基づく第1金額の情報に基づく送金処理、または受取処理を制御部によって実行して、金銭を簡単に送金する、または受け取ることができる。
また、第1実施例は、端末20は、メモリに記憶されたプログラムを読み出し、このプログラムに基づく処理を実行するプロセッサを備える。プロセッサは、自己の端末20のユーザによる複数の買い物決済履歴(限定ではなく、複数の決済情報の一例)のうち、自己の端末20のユーザによって選択された買い物決済履歴(限定ではなく、第1決済情報の一例)を通信I/F22(限定ではなく、端末の通信部の一例)によって異なる端末20に送信することと、送信された買い物決済履歴に基づく過不足金額(限定ではなく、第1決済情報に基づく、端末のユーザが送金、または受け取る第1金額と、端末とは異なる端末のユーザが送金、または受け取る第2金額とのうち、少なくとも第1金額の一例)の情報を通信I/F22によって異なる端末20から受信することと、過不足金額に基づき、割り勘精算処理(限定ではなく、第1金額に基づく送金処理、または受取処理の一例)とを実行する構成を示している。
このような構成によっても、上記と同様の効果を得ることができる。
<第1変形例(1)>
第1実施例において、一の端末20が他の端末20に割り勘対象とする買い物決済履歴を送信する場合に(図1の処理のA20)、買い物決済金額に加えて、その買い物決済履歴に対応する買い物決済で購入された商品に関する情報や、その買い物決済履歴に対応する買い物決済で提供されたサービスに関する情報を含めて送信するようにしてもよいし、そのようにしなくてもよい。
この場合、買い物決済で購入された商品に関する情報には、限定ではなく例として、購入された商品そのものを識別するための商品IDや、購入された商品の種別を識別するための商品種別ID、購入された商品の数等の情報を含めることができる。
また、買い物決済で提供されたサービスに関する情報には、限定ではなく例として、提供されたサービスそのものを識別するためのサービスIDや、提供されたサービスの種別を識別するためのサービス種別ID、そのサービスが提供された人数等の情報を含めることができる。
この場合、他の端末20は、一の端末20から受信された買い物決済履歴に含まれる商品に関する情報やサービスに関する情報を表示部24に表示することで、その他の端末20のユーザに、一の端末20のユーザから要求された割り勘の詳細な内容を報知することができる。
本変形例は、買い物決済履歴は、買い物決済で購入された商品に関する情報(限定ではなく、第1決済で購入された商品に関する情報の一例)、または買い物決済で提供されたサービスに関する情報(限定ではなく、第1決済で提供されたサービスに関する情報の一例)を含む構成を示している。
このような構成により得られる効果の一例として、端末は、第1決済で購入された商品、または第1決済で提供されたサービスに関する情報を含む第1決済情報を送信することによって、端末と、異なる端末を含む複数の端末とのうち、各々が送金、または受け取る金額の情報を受信して取得することができる。
<第1変形例(2)>
第1実施例では、端末のユーザによる端末に対する入力を、端末のユーザによる端末に対する操作入力としたが、これに限定されない。
限定ではなく例として、端末のユーザによる端末に対する入力を、端末のユーザによる端末に対する音声入力を含む音入力としてもよいし、そのようにしなくてもよい。限定ではなく例として、端末のユーザによる音声入力に従って、買い物決済履歴の選択や、買い物決済履歴の送信等の処理を行うようにしてもよいし、そのようにしなくてもよい。
これは、以下説明する実施例においても同様である。
このような構成により得られる効果の一例として、端末に対する入力を、音入力という簡単な方法によって実現することができる。
<第2実施例>
第2実施例は、端末20が、支払いアプリケーションを利用して、サーバ10を介して送金処理/受取処理を行う実施例である。第1実施例とは、サーバ10が構成要件として追加された点が異なる。
第2実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
以下では、支払いアプリケーションによる支払いサービスを提供する事業者のことを「支払いサービスの事業者」と称する。
なお、支払いサービスの事業者は、支払いアプリケーションを提供する事業者や、サーバ10の事業者と表現することもできる。
また、決済サービスを提供する事業者という意味で、決済サービスの事業者と表現することもできる。
また、以下では、支払いサービスの事業者によって、サーバ10が運用・管理されることとして説明する。また、以下では、支払いアプリケーションの名称を、適宜「Payment App」と称して図示・説明する。
また、支払いアプリケーションは、いわゆるメッセージングサービス(MS:Messaging Service)の機能を有さない単体のアプリケーションとしてサーバ10によって提供されるようにしてもよいし、MSの機能を有する複合的なアプリケーションとしてサーバ10によって提供されるようにしてもよい。また、メッセージングサービスには、端末20間での簡単なメッセージ等のコンテンツの送受信を可能とするインスタントメッセージングサービス(IMS:Instant Messaging Service)を含めてもよいし、含めなくてもよい。
また、支払いアプリケーションは、いわゆるソーシャルネットワーキングサービス(SNS:Social Networking Service)の機能を有さない単体のアプリケーションとしてサーバ10によって提供されるようにしてもよいし、SNSの機能を有する複合的なアプリケーションとしてサーバ10によって提供されるようにしてもよい。
なお、MS(IMSを含む。)は、SNSの1つの形態(一形態)と考えることもできる。このため、MSとSNSとは区別してもよいし、区別しなくてもよい。
<システム構成>
図2−1は、本実施例における通信システム1Aのシステム構成の一例を示す図である。
通信システム1Aでは、限定ではなく例として、ネットワーク30を介して、サーバ10と、複数の端末20(端末20A,端末20B,端末20C,・・・)とが接続される。
サーバ10は、ネットワーク30を介して、ユーザが所有する端末20に支払いサービスを提供する機能を有する。サーバ10は、支払いサービスサーバや、支払い管理サーバ、決済サービスサーバ、決済管理サーバ等のように表現することもできる。
なお、ネットワーク30に接続されるサーバ10の数や端末20の数は限定されない。
ネットワーク30は、1以上の端末20と、1以上のサーバ10とを接続する役割を担う。すなわち、ネットワーク30は、上記の各種の装置が接続した後、データを送受信することができるように接続経路を提供する通信網を意味する。
ネットワーク30のうちの1つまたは複数の部分は、有線ネットワークや無線ネットワークであってもよいし、そうでなくてもよい。ネットワーク30は、限定ではなく例として、アドホック・ネットワーク(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)の一部、携帯電話網、ISDN(integrated service digital networks)、無線LAN、LTE(long term evolution)、CDMA(code division multiple access)、ブルートゥース(Bluetooth(登録商標))、衛星通信など、または、これらの2つ以上の組合せを含むことができる。ネットワーク30は、1つまたは複数のネットワーク30を含むことができる。
サーバ10(限定ではなく、サーバ、情報処理装置、情報管理装置の一例)は、端末20に対して、所定のサービス(本実施例では支払いサービス)を提供する機能を備える。サーバ10は、各実施形態において記載する機能を実現できる情報処理装置であればどのような装置であってもよい。サーバ10は、限定ではなく例として、サーバ装置、コンピュータ(限定ではなく例として、デスクトップ、ラップトップ、タブレットなど)、メディアコンピュータプラットホーム(限定ではなく例として、ケーブル、衛星セットトップボックス、デジタルビデオレコーダ)、ハンドヘルドコンピュータデバイス(限定ではなく例として、PDA、電子メールクライアントなど)、あるいは他種のコンピュータ、またはコミュニケーションプラットホームを含む。また、サーバ10は情報処理装置と表現されてもよい。サーバ10と端末20とを区別する必要がない場合は、サーバ10と端末20とは、それぞれ情報処理装置と表現されてもよいし、されなくてもよい。
[各装置のハードウェア(HW)構成]
通信システム1に含まれる各装置のHW構成について説明する。
(1)端末のHW構成
図2−1には、端末20のHW構成の一例を示している。
端末20は、制御部21(CPU:central processing unit(中央処理装置))、記憶部28、通信I/F22(インタフェース)、入出力部23、表示部24、マイク25、スピーカ26、カメラ27、時計部29A、位置算出用情報検出部29Bを備える。端末20のHWの各構成要素は、限定ではなく例として、バスBを介して相互に接続される。なお、端末20のHW構成として、すべての構成要素を含むことは必須ではない。限定ではなく例として、端末20は、マイク25、カメラ27等、個々の構成要素、または複数の構成要素を取り外すような構成であってもよいし、そうでなくてもよい。
通信I/F22は、ネットワーク30を介して各種データの送受信を行う。通信は、有線、無線のいずれで実行されてもよく、互いの通信が実行できるのであれば、どのような通信プロトコルを用いてもよい。通信I/F22は、ネットワーク30を介して、サーバ10等の各種装置との通信を実行する機能を有する。通信I/F22は、各種データを制御部21からの指示に従って、サーバ10等の各種装置に送信する。また、通信I/F22は、サーバ10等の各種装置から送信された各種データを受信し、制御部21に伝達する。また、通信I/F22を単に通信部と表現する場合もある。また、通信I/F22が物理的に構造化された回路で構成される場合には、通信回路と表現する場合もある。
入出力部23は、端末20に対する各種操作を入力する装置、および、端末20で処理された処理結果を出力する装置を含む。入出力部23は、入力部と出力部が一体化していてもよいし、入力部と出力部に分離していてもよいし、そうでなくてもよい。
入力部は、ユーザからの入力を受け付けて、入力に係る情報を制御部21に伝達できる全ての種類の装置のいずれかまたはその組み合わせにより実現される。入力部は、限定ではなく例として、タッチパネル、タッチディスプレイ、キーボード等のハードウェアキーや、マウス等のポインティングデバイス、カメラ(動画像を介した操作入力)、マイク(音声による操作入力)を含む。
出力部は、制御部21で処理された処理結果を出力することができる全ての種類の装置のいずれかまたはその組み合わせにより実現される。出力部は、限定ではなく例として、 タッチパネル、タッチディスプレイ、スピーカ(音声出力)、レンズ(限定ではなく例として3D(three dimensions)出力や、ホログラム出力)、プリンターなどを含む。
表示部24は、フレームバッファに書き込まれた表示データに従って、表示することができる全ての種類の装置のいずれかまたはその組み合わせにより実現される。表示部24は、限定ではなく例として、タッチパネル、タッチディスプレイ、モニタ(限定ではなく例として、液晶ディスプレイやOELD(organic electroluminescence display))、ヘッドマウントディスプレイ(HDM:Head Mounted Display)、プロジェクションマッピング、ホログラム、空気中など(真空であってもよいし、そうでなくてもよい)に画像やテキスト情報等を表示可能な装置を含む。なお、これらの表示部24は、3Dで表示データを表示可能であってもよいし、そうでなくてもよい。
入出力部23がタッチパネルの場合、入出力部23と表示部24とは、略同一の大きさおよび形状で対向して配置されていてもよい。
時計部29Aは、端末20の内蔵時計であり、時刻情報(計時情報)を出力する。時計部29Aは、限定ではなく例として、水晶発振器を利用したクロック等を有して構成される。時計部29Aは、限定ではなく例として、計時部や時刻情報検出部と表現することもできる。
なお、時計部29Aは、NITZ(Network Identity and Time Zone)規格等を適用したクロックを有していてもよいし、有していなくてもよい。
位置算出用情報検出部29Bは、制御部21が自己の端末20の位置を算出(測定)するために必要な情報(以下、「位置算出用情報」と称する。)を検出(計測)する機能部である。位置算出用情報検出部29Bは、限定ではなく例として、位置算出用センサ部と表現することもできる。
位置算出用情報検出部29Bは、限定ではなく例として、GPS(Global Positioning System)等の衛星測位システムを利用して端末20の位置を算出するためのセンサやユニットである衛星測位センサ(衛星測位ユニット)や、慣性航法システムを利用して端末20の位置を算出するためのセンサやユニットである慣性計測センサ(慣性計測ユニット(IMU(Inertial Measurement Unit)))等を含む。
衛星測位ユニットは、限定ではなく例として、不図示のアンテナで受信される測位用衛星から発信されている測位用衛星信号を含むRF(Radio Frequency)信号をデジタル信号に変換するRF受信回路や、RF受信回路から出力されるデジタル信号に対して相関演算処理等を行って測位用衛星信号を捕捉し、測位用衛星信号から取り出した衛星軌道データや時刻データ等の情報を、位置算出用情報として出力するベースバンド処理回路等を有する。
慣性計測ユニットは、慣性航法演算によって端末20の位置を算出するために必要な情報を検出するセンサである慣性センサを有する。慣性センサには、限定ではなく例として、3軸の加速度センサや3軸のジャイロセンサが含まれ、加速度センサによって検出された加速度と、ジャイロセンサによって検出された角速度とを、位置算出用情報として出力する。
制御部21は、限定ではなく例として、位置算出用情報検出部29Bによって検出された位置算出用情報に基づいて、定期的なタイミングや特定のタイミングで、自己の端末20の位置を算出する。端末の位置を「端末位置」と称し、算出された端末位置を「算出端末位置」と称する。そして、制御部21は、算出端末位置を、その算出端末位置を算出した日時と関連付けて、算出端末位置履歴データとして記憶部28に記憶させる。
制御部21は、プログラム内に含まれたコードまたは命令によって実現する機能を実行するために物理的に構造化された回路を有し、限定ではなく例として、ハードウェアに内蔵されたデータ処理装置により実現される。そのため、制御部21は、制御回路と表現されてもよいし、されなくてもよい。
制御部21は、限定ではなく例として、中央処理装置(CPU)、マイクロプロセッサ(microprocessor)、プロセッサコア(processor core)、マルチプロセッサ(multiprocessor)、ASIC(application-specific integrated circuit)、FPGA(field programmable gate array)を含む。
記憶部28は、端末20が動作するうえで必要とする各種プログラムや各種データを記憶する機能を有する。記憶部28は、限定ではなく例として、HDD(hard disk drive)、SSD(solid state drive)、フラッシュメモリ、RAM(random access memory)、ROM(read only memory)など各種の記憶媒体を含む。また、記憶部28は、メモリ(memory)と表現されてもよいし、されなくてもよい。
端末20は、プログラムPを記憶部28に記憶し、このプログラムPを実行することで、制御部21が、制御部21に含まれる各部としての処理を実行する。つまり、記憶部28に記憶されるプログラムPは、端末20に、制御部21が実行する各機能を実現させる。また、このプログラムPは、プログラムモジュールと表現されてもよいし、されなくてもよい。
マイク25は、音声データの入力に利用される。スピーカ26は、音声データの出力に利用される。カメラ27は、動画像データの取得に利用される。
(2)サーバのHW構成
図2−1には、サーバ10のHW構成の一例を示している。
サーバ10は、制御部11(CPU)、記憶部15、通信I/F14(インタフェース)、入出力部12、ディスプレイ13、時計部19を備える。サーバ10のHWの各構成要素は、限定ではなく例として、バスBを介して相互に接続される。なお、サーバ10のHWは、サーバ10のHWの構成として、全ての構成要素を含むことは必須ではない。限定ではなく例として、サーバ10のHWは、ディスプレイ13を取り外すような構成であってもよいし、そうでなくてもよい。
制御部11は、プログラム内に含まれたコードまたは命令によって実現する機能を実行するために物理的に構造化された回路を有し、限定ではなく例として、ハードウェアに内蔵されたデータ処理装置により実現される。
制御部11は、代表的には中央処理装置(CPU)、であり、その他にマイクロプロセッサ、プロセッサコア、マルチプロセッサ、ASIC、FPGAであってもよいし、そうでなくてもよい。本開示において、制御部11は、これらに限定されない。
記憶部15は、サーバ10が動作するうえで必要とする各種プログラムや各種データを記憶する機能を有する。記憶部15は、HDD、SSD、フラッシュメモリなど各種の記憶媒体により実現される。ただし、本開示において、記憶部15は、これらに限定されない。また、記憶部15は、メモリ(memory)と表現されてもよいし、されなくてもよい。
通信I/F14は、ネットワーク30を介して各種データの送受信を行う。通信は、有線、無線のいずれで実行されてもよく、互いの通信が実行できるのであれば、どのような通信プロトコルを用いてもよい。通信I/F14は、ネットワーク30を介して、端末20等の各種装置との通信を実行する機能を有する。通信I/F14は、各種データを制御部11からの指示に従って、端末20等の各種装置に送信する。また、通信I/F14は、端末20等の各種装置から送信された各種データを受信し、制御部11に伝達する。また、通信I/F14を単に通信部と表現する場合もある。また、通信I/F14が物理的に構造化された回路で構成される場合には、通信回路と表現する場合もある。
入出力部12は、サーバ10に対する各種操作を入力する装置により実現される。入出力部12は、ユーザからの入力を受け付けて、入力に係る情報を制御部11に伝達できる全ての種類の装置のいずれかまたはその組み合わせにより実現される。入出力部12は、代表的にはキーボード等に代表されるハードウェアキーや、マウス等のポインティングデバイスで実現される。なお、入出力部12、限定ではなく例として、タッチパネルやカメラ(動画像を介した操作入力)、マイク(音声による操作入力)を含んでいてもよいし、そうでなくてもよい。ただし、本開示において、入出力部12は、これらに限定されない。
ディスプレイ13は、代表的にはモニタ(限定ではなく例として、液晶ディスプレイやOELD(organic electroluminescence display))で実現される。なお、ディスプレイ13は、ヘッドマウントディスプレイ(HDM)などであってもよいし、そうでなくてもよい。なお、これらのディスプレイ13は、3Dで表示データを表示可能であってもよいし、そうでなくてもよい。本開示において、ディスプレイ13は、これらに限定されない。
時計部19は、サーバ10の内蔵時計であり、時刻情報(計時情報)を出力する。時計部19は、限定ではなく例として、ハードウェアクロックとしてのRTC(Real Time Clock)やシステムクロック等を有して構成される。時計部19は、限定ではなく例として、計時部や時刻情報検出部と表現することもできる。
(3)その他
サーバ10は、プログラムPを記憶部15に記憶し、このプログラムPを実行することで、制御部11が、制御部11に含まれる各部としての処理を実行する。つまり、記憶部15に記憶されるプログラムPは、サーバ10に、制御部11が実行する各機能を実現させる。このプログラムPは、プログラムモジュールと表現されてもよいし、されなくてもよい。
他の装置についても同様である。
本開示の各実施形態においては、端末20および/またはサーバ10のCPUがプログラムPを実行することにより、実現するものとして説明する。
他の装置についても同様である。
なお、端末20の制御部21、および/または、サーバ10の制御部11は、制御回路を有するCPUだけでなく、集積回路(IC(Integrated Circuit)チップ、LSI(Large Scale Integration))等に形成された論理回路(ハードウェア)や専用回路によって各処理を実現してもよいし、そうでなくてもよい。また、これらの回路は、1または複数の集積回路により実現されてよく、各実施形態に示す複数の処理を1つの集積回路により実現されることとしてもよいし、そうでなくてもよい。また、LSIは、集積度の違いにより、VLSI、スーパーLSI、ウルトラLSIなどと呼称されることもある。そのため、制御部21は、制御回路と表現されてもよいし、されなくてもよい。
他の装置についても同様である。
また、本開示の各実施形態のプログラムP(限定ではなく例として、ソフトウェアプログラム、コンピュータプログラム、またはプログラムモジュール)は、コンピュータに読み取り可能な記憶媒体に記憶された状態で提供されてもよいし、されなくてもよい。 記憶媒体は、「一時的でない有形の媒体」に、プログラムPを記憶可能である。また、プログラムPは、本開示の各実施形態の機能の一部を実現するためのものであってもよいし、そうでなくてもよい。さらに、本開示の各実施形態の機能を記憶媒体にすでに記録されているプログラムPとの組み合わせで実現できるもの、いわゆる差分ファイル(差分プログラム)であってもよいし、そうでなくてもよい。
記憶媒体は、1つまたは複数の半導体ベースの、または他の集積回路(IC)(限定ではなく例として、フィールド・プログラマブル・ゲート・アレイ(FPGA)または特定用途向けIC(ASIC)など)、ハード・ディスク・ドライブ(HDD)、ハイブリッド・ハード・ドライブ(HHD)、光ディスク、光ディスクドライブ(ODD)、光磁気ディスク、光磁気ドライブ、フロッピィ・ディスケット、フロッピィ・ディスク・ドライブ(FDD)、磁気テープ、固体ドライブ(SSD)、RAMドライブ、セキュア・デジタル・カード、またはドライブ、任意の他の適切な記憶媒体、またはこれらの2つ以上の適切な組合せを含むことができる。記憶媒体は、適切な場合、揮発性、不揮発性、または揮発性と不揮発性の組合せでよい。なお、記憶媒体はこれらの例に限られず、プログラムPを記憶可能であれば、どのようなデバイスまたは媒体であってもよい。また、記憶媒体をメモリ(memory)と表現されてもよいし、されなくてもよい。
サーバ10および/または端末20は、記憶媒体に記憶されたプログラムPを読み出し、読み出したプログラムPを実行することによって、各実施形態に示す複数の機能部の機能を実現することができる。
他の装置についても同様である。
また、本開示のプログラムPは、プログラムを伝送可能な任意の伝送媒体(通信ネットワークや放送波等)を介して、サーバ10および/または端末20に提供されてもよいし、されなくてもよい。サーバ10および/または端末20は、限定ではなく例として、インターネット等を介してダウンロードしたプログラムPを実行することにより、各実施形態に示す複数の機能部の機能を実現する。
他の装置についても同様である。
また、本開示の各実施形態は、プログラムPが電子的な伝送によって具現化されたデータ信号の形態でも実現され得る。
サーバ10および/または端末20における処理の少なくとも一部は、1以上のコンピュータにより構成されるクラウドコンピューティングにより実現されていてもよいし、そうでなくてもよい。
端末20における処理の少なくとも一部を、サーバ10により行う構成としてもよいし、そうでなくてもよい。この場合、端末20の制御部21の各機能部の処理のうち少なくとも一部の処理を、サーバ10で行う構成としてもよいし、そうでなくてもよい。
サーバ10における処理の少なくとも一部を、端末20により行う構成としてもよいし、そうでなくてもよい。この場合、サーバ10の制御部11の各機能部の処理のうち少なくとも一部の処理を、端末20で行う構成としてもよいし、そうでなくてもよい。
明示的な言及のない限り、本開示の実施形態における判定の構成は必須でなく、判定条件を満たした場合に所定の処理が動作されたり、判定条件を満たさない場合に所定の処理がされたりしてもよいし、そうでなくてもよい。
なお、本開示のプログラムは、限定ではなく例として、ActionScript、JavaScript(登録商標)などのスクリプト言語、Objective-C、Java(登録商標)などのコンパイラ言語、HTML5などのマークアップ言語などを用いて実装される。
<機能構成>
(1)サーバの機能構成
図2−2は、本実施例におけるサーバ10の制御部11により実現される機能の一例を示す図である。
サーバ10は、制御部11により実現される機能として、限定ではなく例として、支払いアプリケーション管理処理部111を有する。
支払いアプリケーション管理処理部111は、記憶部15に記憶されている支払いアプリケーション管理処理プログラム151に従って、端末20で実行される支払いアプリケーションに関する各種の情報・データの管理や、端末20または端末20のユーザの電子貨幣による決済を管理するための処理を実行する機能を有している。
図2−3は、本実施例におけるサーバ10の記憶部15に記憶される情報の一例を示す図である。
記憶部15には、プログラムとして、限定ではなく例として、制御部11により読み出され、支払いアプリケーション管理処理として実行される支払いアプリケーション管理処理プログラム151が記憶される。
また、記憶部15には、データとして、限定ではなく例として、支払いアプリケーションユーザ登録データ153と、ユーザ管理データベース155とが記憶される。
支払いアプリケーションユーザ登録データ153は、支払いアプリケーションを利用する端末20、またはその端末20のユーザに関する登録データであり、そのデータ構成の一例を図2−4に示す。
支払いアプリケーションユーザ登録データ153には、限定ではなく例として、ユーザ名と、支払いアプリケーションIDと、端末電話番号と、その他登録情報とが関連付けて記憶される。
ユーザ名は、支払いアプリケーションを利用する端末20のユーザの名称であり、限定ではなく例として、端末20のユーザが支払いアプリケーションを利用する際に登録する名称が記憶される。
支払いアプリケーションIDは、支払いアプリケーションのアカウント(アカウント情報)であって、端末20、または端末20のユーザを識別可能とするIDである。この支払いアプリケーションIDは、限定ではなく例として、サーバ10によって固有のIDが設定されて記憶される。
端末電話番号は、このユーザ名のユーザの端末20の電話番号であり、限定ではなく例として、端末20のユーザが支払いアプリケーションを利用する際に登録する端末20の電話番号が記憶される。
その他登録情報には、限定ではなく例として、このユーザ名のユーザの端末20のメールアドレス(端末メールアドレス)、支払いアプリケーションにおける各種の認証に利用される認証パスワード等の認証情報、このユーザが使用するアイコンの画像データ(アイコン画像)、ユーザのプロフィール(ユーザプロフィール)等を含めるようにすることができる。
ただし、これらの情報は必須ではない。
ユーザ管理データベース155は、支払いアプリケーションユーザ登録データ153に記憶されたアカウント(アカウント情報)に基づくユーザの管理用のデータベースであり、その一例である第1のユーザ管理データベース155Aの構成例を図2−5に示す。
第1のユーザ管理データベース155Aには、支払いアプリケーションユーザ登録データ153に記憶された支払いアプリケーションIDごとの管理データとして、ユーザ管理データが記憶される。
各ユーザ管理データには、限定ではなく例として、支払いアプリケーションIDと、電子マネー口座残高と、買い物決済履歴データとが記憶される。
電子マネー口座残高は、この支払いアプリケーションIDに関連付けられた、支払いサービスで利用可能な電子貨幣の口座の残高である。電子マネー口座残高は、電子マネー口座残高と表現することもできる。
買い物決済履歴データは、この支払いアプリケーションIDに関連付けられた買い物決済履歴(買い物決済履歴情報)のデータであり、限定ではなく例として、買い物決済履歴をユニークに識別するためのIDである買い物決済IDと、買い物決済がされた店舗をユニークに識別するためのIDである店舗IDと、その店舗IDの店舗の店舗名と、買い物決済日時と、買い物決済金額とが関連付けて記憶される。
(2)端末の機能構成
図2−6は、本実施例における端末20の制御部21により実現される機能の一例を示す図である。
端末20は、制御部21により実現される機能として、限定ではなく例として、支払いアプリケーション処理部211を有する。
支払いアプリケーション処理部211は、記憶部28に記憶されている支払いアプリケーションプログラム281に従って、支払いアプリケーション処理を実行する機能を有している。
図2−7は、本実施例における端末20の記憶部28に記憶される情報の一例を示す図である。
記憶部28には、プログラムとして、限定ではなく例として、制御部21により読み出され、支払いアプリケーション処理として実行される支払いアプリケーションプログラム281が記憶される。
また、記憶部28には、データとして、限定ではなく例として、支払いアプリケーションのアカウントのデータである支払いアプリケーションアカウントデータ283が記憶される。
<表示画面例>
以下の例では、ユーザA.Aが「割り勘マスター(割り勘依頼主)」となって、他のユーザとの間で割り勘を行う場合を例示する。
なお、割り勘マスターとは、限定ではなく例として、最初に割り勘を行うことを提案したユーザを意味するものとする。
図2−8は、本実施例における支払いアプリケーションのメニュー画面の一例を示す図であり、ユーザA.Aの端末20の表示部24に表示される画面の一例を示している。
このメニュー画面には、画面上部に「Payment App」の文字が表示され、その横に、自己の端末20のユーザのユーザ名(この例では「ユーザA.A」)が表示されている。
また、その下には、このユーザ名のアカウントに関連付けてサーバ10で記憶・管理されている電子マネー口座残高と、電子マネー口座に電子貨幣をチャージするためのチャージボタンとを含む電子マネー口座表示領域が設けられている。
また、電子マネー口座表示領域の下には、支払いアプリケーションの機能として設けられた複数の機能に基づく処理を実行させるための、複数の機能それぞれに対応する機能アイコンを含む機能アイコン表示領域が設けられている。
機能アイコン表示領域には、限定ではなく例として、入金を行うための「入金アイコン」、端末20の表示部24に表示されるコード(一次元コードや二次元コード等)を用いて支払いを行うための「コード支払いアイコン」、商品の購入やサービスの提供を受けるために店舗に設置されるコード(一次元コードや二次元コード等)を読み取って支払いを行うための「コードリーダアイコン」、他の端末20のユーザ(他のアカウント)に送金を行うための「送金アイコン」、他の端末20のユーザ(他のアカウント)との間で割り勘を行うための「割り勘アイコン」等の複数の機能アイコンが含まれる。
図2−9は、上記のメニュー画面において割り勘アイコンが操作(限定ではなく例としてタッチ操作)されたことに基づいて表示される割り勘メンバー選択画面の一例を示す図である。
割り勘メンバー選択画面は、割り勘メンバーを選択するための画面である。
割り勘メンバーとは、割り勘に参加するユーザのことであり、本明細書では、割り勘マスターも割り勘メンバーに含まれることとして説明する。
図2−9の割り勘メンバー選択画面は、割り勘マスター(この例ではユーザA.A)が、自分以外の割り勘メンバーを選択するための画面である。
初期状態では、自分以外の割り勘メンバーが選択されていないため、限定ではなく例として、「割り勘をするメンバーがいません」の文字が画面に表示されている。
画面下部には、割り勘メンバーを検索するための「検索アイコン」が表示されており、この検索アイコンを操作することで、割り勘メンバーを検索することが可能に構成されている。
図2−10は、上記の割り勘メンバー選択画面において検索アイコンが操作(限定ではなく例としてタッチ操作)されたことに基づいて表示される割り勘メンバー検索画面の一例を示す図である。
この割り勘メンバー検索画面は、割り勘マスターが自分以外の割り勘メンバーを検索するための画面であり、限定ではなく例として、「電話番号を入力して検索してください」の文字が表示されている。また、その下には、電話番号を入力するための電話番号入力欄とともに、入力された電話番号の端末20(その端末20のユーザ)を検索するための検索実行ボタンが表示されている。
この例では、「080XXXXXXXX」という電話番号が電話番号入力欄に入力されて表示されている。そして、検索実行ボタンが実行されることにより、サーバ10によって検索が行われ、検索結果として「ユーザB.B」が得られた状態が示されている。
また、検索結果の下には、検索結果として得られたユーザを割り勘メンバーに追加するための「追加アイコン」が表示されており、この追加アイコンが操作されることで、検索結果として得られたユーザが、サーバ10によって割り勘メンバーに追加される。
図2−11は、上記の割り勘メンバー検索画面での検索によって割り勘メンバーが追加されたことに基づいて表示される割り勘メンバー選択画面の一例を示す図である。
この割り勘メンバー選択画面は図2−9の画面に対応しており、上記の検索結果に基づいて、割り勘メンバーの候補(以下、「割り勘メンバー候補」と称する。)として追加されたユーザの一覧が表示されている。この例では、「ユーザB.B」、「ユーザC.C」、「ユーザD.D」、「ユーザE.E」が割り勘メンバー候補として追加された状態が示されている。
また、それぞれの割り勘メンバー候補にはチェックボックスが関連付けて表示されており、初期状態では、全ての割り勘メンバー候補のチェックが「ON」とされている。
対応するチェックボックスを操作することで、チェックの「ON/OFF」を切り替えることが可能に構成されており、チェックを「OFF」とすることで、その割り勘メンバー候補を割り勘メンバーから除外することが可能に構成されている。
また、この例では、図2−9に示した検索アイコンに加えて、ユーザA.Aが自分の買い物決済履歴を割り勘対象として登録するための、限定ではなく例として「支払い分を登録」と示された買い物決済履歴登録アイコンが表示されている。
図2−12は、図2−11の割り勘メンバー選択画面において買い物決済履歴登録アイコンが操作(限定ではなく例としてタッチ操作)されたことに基づいて表示される買い物決済履歴選択画面の一例を示す図である。
この買い物決済履歴選択画面には、この端末20のユーザについての複数の買い物決済履歴が表示されている。具体的には、限定ではなく例として、買い物決済履歴として、買い物決済日時と、店舗名と、買い物決済金額とが表示されている。この例では、「AAレンタサイクル」、「BBスーパー」、「CC弁当」等の、複数の店舗の買い物決済履歴が表示されている。
また、それぞれの買い物決済履歴にはチェックボックスが関連付けて設けられており、対応するチェックボックスを操作することで、チェックの「ON/OFF」を切り替えることが可能に構成されている。1つの買い物決済履歴に限らず、複数の買い物決済履歴のチェックを「ON」とすることが可能であり、チェックが「ON」とされている買い物決済履歴を割り勘対象として、割り勘の依頼・リクエスト(以下、「割り勘リクエスト」と称する。)を行うことが可能に構成されている。
より具体的には、チェックが「ON」とされた買い物決済履歴を割り勘対象として割り勘リクエストを行うための、限定ではなく例として「割り勘依頼を送る」と示された割り勘リクエストアイコンが画面下部に表示されている。そして、この割り勘リクエストアイコンが操作されると、先に選択された割り勘メンバーの端末20に、サーバ10を介して、自己の端末20から割り勘リクエストを送信することが可能に構成されている。
この例では、「AAレンタサイクル」と「BBスーパー」の2つの買い物決済履歴のチェックが「ON」とされ、この2つの買い物決済履歴を割り勘対象とすることがユーザA.Aによって選択された状態が示されている。この場合、ユーザA.Aの支払い済み金額は、「AAレンタサイクル」の買い物決済金額「1,500円」と、「BBスーパー」の買い物決済金額「3,000円」とを合計した金額である「4,500円」となり、このユーザA.Aの支払い済み金額「4,500円」を割り勘することになる。
図2−13は、図2−12の買い物決済履歴選択画面において割り勘リクエストアイコンが操作(限定ではなく例としてタッチ操作)されたことに基づいて、ユーザA.A以外の割り勘メンバーの端末20の表示部24に表示される割り勘リクエスト通知画面の一例を示す図である。
この割り勘リクエスト通知画面は、ユーザA.Aが割り勘メンバーとして選択したユーザB.Bの端末20の表示部24に表示される画面であって、この端末20で実行される支払いアプリケーション内の画面の一例である。
この例では、限定ではなく例として、「A.Aさんから割り勘の依頼が届きました」の文字が表示され、その下に、ユーザB.Bの過不足金額が表示される過不足金額表示領域が設けられている。本実施例において、各々の割り勘メンバーの過不足金額は、後述するようにサーバ10によって計算される。
過不足金額表示領域には、限定ではなく例として、ユーザB.Bの過不足金額とともに、その過不足金額の種別(受取/支払い)を識別可能とするためのマークが表示されている。この例では、「¥900 支払い」と表示されており、ユーザB.BはユーザA.Aに対して「900円」を支払う必要があることが示されている。
過不足金額の種別(受取/支払い)は、前述したように、計算される過不足金額の正負の符号によって決定される。
「支払い」と表現しているのは、過不足金額を電子貨幣で支払う場合の他、詳細は後述するが、過不足金額を現金で支払う場合も想定されるためである。つまり、「支払い」には、電子貨幣での支払い(=送金)と、現金での支払い(=現金払い)とが含まれる。
なお、現金払いを考えず、「支払い」に代えて「送金」としてもよいし、そのようにしなくてもよい。
画面下部には、上記の過不足金額に基づき割り勘精算を行うための、限定ではなく例として「精算」と示された「精算アイコン」と、割り勘リクエストを拒否するための、限定ではなく例として「割り勘を断る」と示された「拒否アイコン」とが表示されている。
精算アイコンが操作された場合、そのユーザの過不足金額の種別が「支払い」である場合は、その過不足金額が、そのユーザの端末20から送金先のユーザの端末20に送金される。
一方、そのユーザの過不足金額の種別が「受取」である場合は、その過不足金額が、そのユーザの端末20で受け取られる。
ただし、本実施例における送金/受取は、サーバ10によって、そのユーザの支払いアプリケーションIDに関連付けられた電子マネー口座残高が更新されることによって実現される。つまり、そのユーザの過不足金額の種別が「支払い」である場合は、そのユーザの支払いアプリケーションIDに関連付けられた電子マネー口座残高から過不足金額に相当する金額が減算・更新される。一方、そのユーザの過不足金額の種別が「受取」である場合は、そのユーザの支払いアプリケーションIDに関連付けられた電子マネー口座残高に過不足金額に相当する金額が加算・更新される。
この例では、ユーザB.Bは金額を支払う側であるため、精算アイコンが操作されると、900円が電子貨幣によってユーザA.Aの端末20に送金される。より具体的には、サーバ10によって、ユーザB.Bの支払いアプリケーションIDの電子マネー口座残高から900円が減算・更新される。
なお、実際には、サーバ10によって、減算された900円の金額がユーザA.Aの支払いアプリケーションIDの電子マネー口座残高に加算・更新されるのであるが、本実施例において、このユーザA.Aの電子マネー口座残高の更新は、ユーザA.Aの端末20において精算アイコンが操作されたことに基づいて、サーバ10によって実行されるものとする。
図2−14は、図2−12の買い物決済履歴選択画面において割り勘リクエストアイコンが操作(限定ではなく例としてタッチ操作)されたことに基づいてユーザA.Aの端末20の表示部24に表示される過不足金額表示画面の一例を示す図である。
この例では、限定ではなく例として、「過不足金額の計算が行われました」の文字が表示され、その下に、ユーザA.Aの過不足金額が表示される過不足金額表示領域が設けられている。この例では、ユーザA.Aの過不足金額として「3,600円 受取」が表示されている。つまり、ユーザA.Aは、他の割り勘メンバーから総額として「3,600円」を受け取ることが表示されている。
この例では、ユーザA.Aは金銭を受け取る側であるため、精算アイコンが操作されると、「3,600円」の金額がユーザA.Aの端末20で受け取られる。具体的には、他の各々の割り勘メンバーの電子マネー口座残高から減額された金額の合計である3,600円が、サーバ10によって、ユーザA.Aの支払いアプリケーションIDに関連付けられた電子マネー口座残高に加算・更新されることになる。
図2−15は、ユーザA.Aの端末20の表示部24に表示される受取通知画面の一例を示す図である。
この受取通知画面には、自分以外の割り勘メンバー(この例では「ユーザB.B」、「ユーザC.C」、「ユーザD.D」、「ユーザE.E」の4名)ごとに、そのメンバーからの送金金額と、送金が行われた日時(送金日時)とが関連付けられた受取完了通知が表示されている。
図2−16は、図2−15の受取通知画面に表示される割り勘完了通知の一例を示す図である。
限定ではなく例として、図2−15の受取通知画面の表示領域がユーザの指でタッチされた後、上方向にスクロールする操作が行われると、画面下部に表示されていた割り勘完了通知が表示領域に現れる。この例では、「割り勘完了」の文字とともに、精算結果(この例では「3,600円」 受取 自分の支払い済み金額「4,500円」、全員の支払い合計額「4,500円」、1人あたりの金額「900円」)を含む割り勘完了通知が表示されている。
<処理>
図2−17〜図2−19は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。左側から順に、端末A(限定ではなく例として、ユーザA.Aの端末20)の制御部21が実行する割り勘処理、端末B(限定ではなく例として、ユーザB.Bの端末20)の制御部21が実行する割り勘処理、サーバ10の制御部11が実行する割り勘管理処理の一例をそれぞれ示している。
一例として、割り勘マスターの端末20をユーザA.Aの端末20(端末A)とし、割り勘マスターから割り勘を依頼されるユーザの端末20をユーザB.Bの端末20(端末B)として説明する。実際には、割り勘マスターから割り勘を依頼されるユーザの端末20は1つとは限らないが、端末Bと同様の処理となるため、図示を省略する。
なお、この処理は、本開示の手法を実現するための処理の一例に過ぎず、この処理に限定されるものではない。この処理に、別のステップを追加してもよいし、一部のステップを省略(削除)してもよい。
なお、これは、各実施例で説明する処理について同様である。
まず、端末Aの制御部21は、割り勘メンバーの情報(割り勘メンバー情報)を要求するメンバー要求情報を、通信I/F22によってサーバ10に送信する(A110)。通信I/F14によって端末Aからメンバー要求情報を受信すると(S110)、サーバ10の制御部11は、要求を受けたメンバー情報を検索して、通信I/F14によって端末Aに送信する(S120)。
通信I/F22によってサーバ10からメンバー情報を受信すると(A120)、端末Aの制御部21は、受信されたメンバー情報に基づき、割り勘メンバー候補を表示部24に表示させる。そして、端末Aの制御部21は、入出力部23に対する割り勘メンバーの選択操作に基づき、割り勘メンバーを選択する第1のメンバー選択処理を実行する(A130)。そして、端末Aの制御部21は、割り勘メンバーの選択結果を含むメンバー選択情報を、通信I/F22によってサーバ10に送信する(A140)。サーバ10は、通信I/F14によって端末Aからメンバー選択情報を受信する(S140)。
その後、端末Aの制御部21は、入出力部23に対する操作に従って、自己の端末20のユーザによる買い物決済に対応する買い物決済履歴を要求する買い物決済履歴要求情報を、通信I/F22によってサーバ10に送信する(A150)。
ここで、本実施例において、各々の端末20のユーザの買い物決済履歴は、前述したようにサーバ10の記憶部15で記憶・管理されており、端末20の記憶部28には記憶されていない。これは、端末20側で買い物決済履歴が改ざん等されることを防止するためである。このため、A150では、端末20で買い物決済履歴を表示するために、端末20からサーバ10に対して買い物決済履歴を要求する。
端末Aから買い物決済履歴要求情報を受信すると(S150)、制御部11は、ユーザ管理データベース155に含まれるユーザ管理データのうち、ユーザA.Aの支払いアプリケーションIDのユーザ管理データの買い物決済履歴データに含まれる複数の買い物決済履歴を、通信I/F22によって端末Aに送信する(S160)。
サーバ10から買い物決済履歴を受信すると(A160)、端末Aの制御部21は、第2の買い物決済履歴選択処理を行う(A170)。具体的には、限定ではなく例として、受信された複数の買い物決済履歴を表示部24に一覧表示する。そして、入出力部23に対する選択操作に従って、少なくとも1つの買い物決済履歴を選択する。
その後、端末Aの制御部21は、限定ではなく例として、買い物決済履歴選択情報を、通信I/F22によってサーバ10に送信する(A180)。
ここで、端末20からサーバ10に送信する買い物決済履歴選択情報は、選択した買い物決済履歴をサーバ10側で特定可能な情報とすればよい。具体的には、一例として、選択した買い物決済履歴に対応する買い物決済IDを送信するようにすることができる。また、別例として、選択した買い物決済履歴そのものを送信するようにすることもできる。
端末Aから買い物決済履歴選択情報を受信すると(S180)、制御部11は、S140で受信されたメンバー選択情報と、S180で受信された買い物決済履歴選択情報とに基づいて、各々の割り勘メンバーの過不足金額を計算する(S190)。
その後、制御部11は、S190で計算した過不足金額を含む割り勘精算依頼通知を、通信I/F14によって端末Aおよび端末Bそれぞれに送信する(S210)。
サーバ10から割り勘精算依頼通知を受信すると(A210)、端末Aの制御部21は、限定ではなく例として、割り勘精算依頼通知に含まれる過不足金額を表示部24に表示させる。そして、端末Aの制御部21は、入出力部23に対する操作に従って、割り勘精算を承認することを通知するための割り勘精算承認通知を、通信I/F22によってサーバ10に送信する(A230)。
一方、サーバ10から割り勘精算依頼通知を受信すると(B210)、端末Bの制御部21は、限定ではなく例として、割り勘精算依頼通知に含まれる過不足金額を表示部24に表示させる。そして、端末Aの制御部21は、ユーザB.Bが割り勘に同意したか否かを判定する(B220)。具体的には、限定ではなく例として、割り勘に同意する意思を示す操作(限定ではなく例として、前述した「精算アイコン」に対する操作)がなされたか否かを判定する。割り勘を拒否する意思を示す操作(限定ではなく例として、前述した「拒否アイコン」に対する操作)がなされた場合は、割り勘に同意しないと判定する。
割り勘に同意すると判定したならば(B220:YES)、端末Bの制御部21は、割り勘精算を承認することを通知するための割り勘精算承認通知を、通信I/F22によってサーバ10に送信する(B230)。一方、割り勘に同意しないと判定したならば(B220:NO)、端末Bの制御部21は、割り勘精算を承認しないこと(割り勘精算を拒否すること)を通知するための割り勘精算拒否通知を、通信I/F22によってサーバ10に送信する(B240)。
S210の後、制御部11は、第1の割り勘承認管理処理を実行する(S230)。
図2−20は、第1の割り勘承認管理処理の流れの一例を示すフローチャートである。
本処理において、割り勘精算通知は、前述した「割り勘精算承認通知」と、「割り勘精算拒否通知」とのうちのいずれかの通知である。
制御部11は、端末20から割り勘精算通知を受信すると(S2310)、受信された割り勘精算通知が「割り勘精算拒否通知」であるか否かを判定する(S2320)。割り勘精算拒否通知であると判定したならば(S2320:YES)、制御部11は、割り勘不成立と判定して(S2330)、第1の割り勘承認管理処理を終了する。
一方、受信された割り勘精算通知が「割り勘精算拒否通知」ではない(「割り勘精算承認通知」である)と判定したならば(S2320:NO)、制御部11は、全ての対象端末から割り勘精算承認通知を受信したか否かを判定する(S2340)。
ここで、「対象端末」は、サーバ10が割り勘精算通知を受信することが予定されている端末20である。この例では、端末Aおよび端末Bの両方が対象端末となる。
基本的には、全ての割り勘メンバーの端末20が対象端末となるが、割り勘メンバーであっても対象端末から除外される場合がある。これについては、後述する実施例で詳細に説明する。
少なくとも1つの対象端末から割り勘精算承認通知を受信していないと判定したならば(S2340:NO)、制御部11は、S2310に処理を戻す。
一方、全ての対象端末から割り勘精算承認通知を受信したと判定したならば(S2340:YES)、制御部11は、各々の対象端末について、その対象端末のユーザが割り勘で支払う金額が、そのユーザの支払いアプリケーションIDに関連付けて記憶された電子マネー口座残高以上であるか否かを判定する(S2350)。この条件を満たさない場合(S2350:NO)、制御部11は、S2330に処理を移す。
一方、S2350の条件を満たすと判定した場合(S2350:YES)、制御部11は、割り勘成立と判定する(S2360)。つまり、全ての対象端末のユーザの電子マネー口座残高がマイナスとならない場合に、割り勘成立と判定する。そして、制御部11は、第1の割り勘承認管理処理を終了する。
図2−18の処理に戻り、第1の割り勘承認管理処理で割り勘成立と判定したならば(S310:YES)、制御部11は、通信I/F22によって割り勘成立通知を端末A及び端末Bそれぞれに送信する(S310)。
一方、第1の割り勘承認管理処理で割り勘不成立と判定したならば(S310:NO)、制御部11は、通信I/F22によって割り勘不成立通知を端末A及び端末Bそれぞれに送信する(S250)。
A230の後、端末Aの制御部21は、通信I/F22によってサーバ10から割り勘不成立通知を受信したか否かを判定する(A250)。
同様に、B240の後、端末Bの制御部21は、通信I/F22によってサーバ10から割り勘不成立通知を受信したか否かを判定する(B250)。
A250でサーバ10から割り勘不成立通知を受信しなかった場合(A250:NO)、端末Aは、サーバ10から割り勘成立通知を受信することになる(A310)。この場合、端末Aの制御部21は、割り勘精算を要求する情報(以下、「割り勘精算要求情報」と称する。)を通信I/F22によってサーバ10に送信する割り勘精算要求処理を実行する(A320)。
同様に、B250においてサーバ10から割り勘不成立通知を受信しなかった場合(A250:NO)、端末Bは、サーバ10から割り勘成立通知を受信することになる(B310)。この場合、端末Bの制御部21は、割り勘精算要求情報を通信I/F22によってサーバ10に送信する(B320)。
端末Aおよび端末Bからそれぞれ割り勘精算要求情報を受信すると(S320)、制御部11は、割り勘精算処理を実行する(S330)。具体的には、限定ではなく例として、そのユーザに関連付けられた支払いアプリケーションIDの電子マネー口座残高に、そのユーザの過不足金額に相当する金額を加算(金銭を受け取る場合)/減算(金銭を支払う場合)する。
本実施例における割り勘精算処理は、サーバ10の制御部11によって実行される送金処理/受取処理の一例である。
その後、制御部11は、割り勘精算結果を通信I/F14によって端末Aおよび端末Bそれぞれに送信する(S340)。
端末20は、通信I/F22によってサーバ10から割り勘精算結果を受信する割り勘精算結果受信処理を実行する。
具体的には、通信I/F22によってサーバ10から割り勘精算結果を受信すると(A340)、端末Aの制御部21は、受信された割り勘精算結果を表示部24に表示させる(A350)。
同様に、通信I/F22によってサーバ10から割り勘精算結果を受信すると(B340)、端末Bの制御部21は、受信された割り勘精算結果を表示部24に表示させる(B350)。
ここで、割り勘精算結果には、限定ではなく例として、前述した受取完了通知と、割り勘完了通知とのうちの少なくともいずれかが含まれる。
受取完了通知と割り勘完了通知との両方を割り勘精算結果としてもよいし、いずれか一方のみを割り勘完了通知としてもよい。
本実施例において、割り勘精算要求処理や割り勘精算結果受信処理は、端末20の制御部21によって実行される送金処理/受取処理の一例である。
その後、端末Aの制御部21は、処理を終了するか否かを判定し(A390)、処理を継続すると判定したならば(A390:NO)、A110に処理を戻す。また、処理を終了すると判定したならば(A390:YES)、端末Aの制御部21は、割り勘処理を終了する。
同様に、端末Bの制御部21は、処理を終了するか否かを判定し(B390)、処理を継続すると判定したならば(B390:NO)、B110に処理を戻す。また、処理を終了すると判定したならば(B390:YES)、端末Bの制御部21は、割り勘処理を終了する。
同様に、制御部11は、処理を終了するか否かを判定し(S390)、処理を継続すると判定したならば(S390:NO)、S110に処理を戻す。また、処理を終了すると判定したならば(S390:YES)、制御部11は、割り勘管理処理を終了する。
なお、本実施例では、サーバ10によって割り勘精算処理が実行されるため、端末20が直接的に金銭の送金/受取を行っているわけではないが、端末20が割り勘精算要求処理を実行したことに基づいてサーバ10によって割り勘精算処理が実行されるため、端末20が金銭の送金処理/受取処理を実行していると言うこともできる。
<第2実施例の効果>
第2実施例は、端末20は、自己の端末20のユーザによる自己の端末20に対する入力(限定ではなく、端末に対する入力の一例)に基づいて、買い物決済履歴(買い物決済履歴選択情報)(限定ではなく、第1決済情報の一例)を通信I/F22(限定ではなく、端末の通信部の一例)によってサーバ10に送信する。また、端末20は、送信した買い物決済履歴に基づく各々のユーザの過不足金額(限定ではなく、第1決済情報に基づく、端末のユーザが送金、または受け取る第1金額と、端末とは異なる端末のユーザが送金、または受け取る第2金額とのうち、少なくとも第1金額の一例)の情報を通信I/F22によってサーバ10から受信する。そして、端末20は、過不足金額に基づき、割り勘精算要求処理や割り勘精算結果受信処理(限定ではなく、第1金額に基づく送金処理、または受取処理の一例)を制御部21(限定ではなく、端末の制御部の一例)によって実行する構成を示している。
このような構成により得られる効果の一例として、端末は、端末のユーザによる第1決済に関する処理に基づく第1決済情報を送信したことに基づいて、第1金額に基づく送金処理、または受取処理を制御部によって実行して、金銭を簡単に送金する、または受け取ることが可能となり、ユーザの利便性を向上させることができる。
また、第2実施例は、上記の第1金額に基づく送金処理、または受取処理は、異なる端末20のユーザ(支払いアプリケーションにおける異なるアカウント)(限定ではなく、異なる端末のユーザの一例)への送金、または異なる端末20のユーザ(支払いアプリケーションにおける異なるアカウント)からの受け取りを含む処理である構成を示している。
このような構成により、異なる端末のユーザへの送金、または異なる端末のユーザからの金銭の受け取りを実現することができる。
また、第2実施例は、過不足金額(限定ではなく、第1金額、第2金額の一例)は、端末20のユーザによって選択された買い物決済履歴(限定ではなく、第1決済情報の一例)に基づいて、サーバ10(限定ではなく、第1決済に関する決済処理を実行するサーバの一例)によって決定される構成を示している。
このような構成により得られる効果の一例として、第1金額と第2金額とを端末で決定せずに済むため、端末の処理負荷を軽減することができる。
また、第2実施例は、サーバ10は、受信された買い物決済履歴に基づいて、その送信元のユーザである割り勘マスターの端末20(限定ではなく、端末の一例)と、他の割り勘メンバーの端末20(限定ではなく、異なる端末の一例)を含む複数の端末20とのうち、各々が送金、または受け取る金額を決定する構成を示している。
このような構成により得られる効果の一例として、端末は、第1決済情報を送信することによって、端末と、異なる端末を含む複数の端末とのうち、各々が送金、または受け取る金額をサーバに決定させることができる。
また、第2実施例は、サーバ10は、端末20のユーザによる端末20に対する入力(限定ではなく、端末に対する入力の一例)に基づいて、買い物決済履歴(買い物決済履歴選択情報)を通信I/F14によって端末20から受信する。また、サーバ10は、受信された買い物決済履歴に基づき、少なくとも第1過不足金額(限定ではなく、第1決済情報に基づく、端末のユーザが送金、または受け取る第1金額の一例)の情報を端末20に通信I/F14によって送信し、少なくとも第2過不足金額(限定ではなく、第1決済情報に基づく、端末とは異なる端末のユーザが送金、または受け取る第2金額の一例)の情報を異なる端末20に通信I/F14によって送信する。そして、サーバ10は、第1の過不足金額および第2の過不足金額に基づく割り勘精算処理(限定ではなく、第1金額に基づく送金処理、または受取処理と、第2金額に基づく送金処理、または受取処理との一例)を実行する構成を示している。
このような構成により得られる効果の一例として、サーバは、端末のユーザによる第1決済に関する処理に基づく第1決済情報を受信したことに基づいて、第1金額に基づく送金処理、または受取処理と、第2金額に基づく送金処理、または受取処理とを制御部によって実行して、端末に金銭を簡単に送金する、または受け取らせることが可能となる。
また、第2実施例は、端末20が、自己の端末20のユーザによる複数の買い物決済履歴(限定ではなく、複数の決済情報の一例)のうち、自己の端末20のユーザによって選択された買い物決済履歴(限定ではなく、第1決済情報の一例)を通信I/F22(限定ではなく、端末の通信部の一例)によってサーバ10に送信する。また、端末20は、送信された買い物決済履歴に基づく過不足金額(限定ではなく、第1決済情報に基づく、端末のユーザが送金、または受け取る第1金額と、端末とは異なる端末のユーザが送金、または受け取る第2金額とのうち、少なくとも第1金額の一例)の情報を通信I/F22によってサーバ10から受信する。そして、端末20は、過不足金額に基づき、割り勘精算要求処理や割り勘精算結果受信処理(限定ではなく、第1金額に基づく送金処理、または受取処理の一例)を制御部21(限定ではなく、端末の制御部の一例)によって実行する構成を示している。
このような構成により得られる効果の一例として、端末は、端末のユーザによる決済に関する複数の決済情報のうち、第1決済情報を通信部によって送信したことに基づいて、その第1決済情報に基づく第1金額の情報に基づく送金処理、または受取処理を制御部によって実行して、金銭を簡単に送金する、または受け取ることができる。
<第2変形例(1)>
第2実施例では、買い物決済履歴がサーバ10の記憶部15に記憶・管理されていることとしたが、これに限定されない。第1実施例と同様に、端末20の記憶部28に買い物決済履歴を記憶させておくようにすることもできる。
限定ではなく例として、サーバ10によって買い物決済処理が行われた場合、その買い物決済情報を端末20に送信するようにする。そして、端末20は、サーバ10から受信した買い物決済情報を買い物決済履歴として記憶部28に記憶させる。
この場合、端末20は、記憶部28に記憶された買い物決済履歴の中から選択された買い物決済履歴をサーバ10に送信するようにすることができる。
これは、サーバ10を構成要件として含む各実施例について同様である。
<第2変形例(2)>
第2実施例では、サーバ10の制御部11によって割り勘精算処理が行われることとしたが、これに限定されない。
具体的には、限定ではなく例として、第1実施例と同様に、割り勘精算処理が端末20の制御部21によって実行されるようにしてもよいし、そのようにしなくてもよい。
これは、サーバ10を構成要件として含む各実施例について同様である。
<第2変形例(3)>
サーバ10において、各々のユーザ管理データに含まれる買い物決済履歴データに、その買い物決済の具体的な内容(以下、「買い物決済内容」と称する。)を含めて管理するようにしてもよいし、そのようにしなくてもよい。
図2−21は、本変形例におけるユーザ管理データベース155の別例である第2のユーザ管理データベース155Bのデータ構成例を示す図である。
この例では、買い物決済履歴データには、買い物決済IDと、店舗IDと、買い物決済日時とに加えて、買い物決済内容が関連付けて記憶されている。
買い物決済内容には、限定ではなく例として、その店舗IDの店舗で購入された商品に関する情報や、その店舗IDの店舗で提供されたサービスに関する情報が含まれる。
この場合、購入された商品に関する情報には、限定ではなく例として、購入された商品そのものを識別するための商品IDや、購入された商品の種別を識別するための商品種別ID、購入された商品の数等の情報を含めることができる。
また、提供されたサービスに関する情報には、限定ではなく例として、提供されたサービスそのものを識別するためのサービスIDや、提供されたサービスの種別を識別するためのサービス種別ID、そのサービスが提供された人数等の情報を含めることができる。
このようにすることで、限定ではなく例として、端末20から受信した買い物決済内容の照会要求に従って、サーバ10の制御部11は、買い物決済内容を端末20に開示することができる。
<第2変形例(4)>
第2実施例に示した表示画面やユーザインタフェース(UI)は、あくまでも一例に過ぎず、これらに限定されない。
図2−22は、図2−13の割り勘リクエスト通知画面の別例を示す図であり、ユーザB.Bの端末20の表示部24に表示される画面の一例を示している。
この割り勘リクエスト通知画面は、図2−15の割り勘リクエスト通知画面に対応するが、過不足金額表示領域が操作(限定ではなく例としてタッチ操作)されることで、割り勘マスターによって依頼された割り勘の内訳が表示されるように構成されている。
この例では、割り勘の内訳として、「AAレンタサイクル 1,500円」と、「BBスーパー 3,000円」とが表示されるとともに、それらの合計金額「4,500円」と、1人あたり金額として「4,500円÷5人=900円」が表示されている。
この例では、ユーザA.Aが買い物決済によって支払った支払い済み金額を、5人のユーザで割り勘する場合を示している。ユーザA.Aの支払い済み金額は「4,500円」であり、割り勘する人数は「5人」であるため、1人あたり金額は「4,500円÷5人=900円」となる。
具体的には、端末20の制御部21は、過不足金額表示領域が操作されたことに基づいて、割り勘の内訳の照会要求をサーバ10に送信する。サーバ10は、第1のユーザ管理データベース155A(図2−5参照)のうち、割り勘マスターの支払いアプリケーションIDが記憶されたユーザ管理データに含まれる買い物決済履歴データに基づき、店舗名、買い物決済日時、買い物決済金額の情報を端末20に送信する。そして、端末20の制御部21は、受信された情報に基づき、割り勘の内訳を表示させる。
なお、端末20の制御部21が、過不足金額表示領域が操作されたことに基づいて、前述した買い物決済内容の照会要求を端末20からサーバ10に送信するようにすることもできる。この場合、サーバ10は、第2のユーザ管理データベース155B(図2−21参照)のうち、割り勘マスターの支払いアプリケーションIDが記憶されたユーザ管理データに含まれる買い物決済履歴データに基づき、店舗名、買い物決済日時、買い物決済金額に加えて、買い物決済内容を端末20に送信する。そして、端末20の制御部21は、受信された情報に基づき、買い物決済内容を含む割り勘の内訳を表示させる。
図2−23は、図2−15に示した受取通知画面の別例を示す図であり、ユーザA.Aの端末20の表示部24に表示される画面を一例として示している。
この受取通知画面では、図2−15の受取通知画面とは異なり、ユーザA.Aが受け取った電子マネーの金額の総額(この例では「3600円」)とともに、「割り勘メンバーから送金がありました。」の文字と、自分以外の割り勘メンバーのアイコン画像(この例では「ユーザB.B」、「ユーザC.C」、「ユーザD.D」、「ユーザE.E」の4名のアイコン画像)を含む受取通知が表示されている。また、受取通知の下には、図2−16に示した割り勘完了通知と同様の割り勘完了通知が表示されている。
このような表示を行うことで、割り勘マスターのユーザは、自身に送金された金額の総額と、自身に送金を行った割り勘メンバーとを一見して把握することが可能となる。
<第2変形例(5)>
割り勘リクエストを行ったにも関わらず送金を行わないユーザの端末20に対して、割り勘マスターの端末20からサーバ10を介して催促を行うようにしてもよいし、そのようにしなくてもよい。
図2−24は、本実施例における割り勘催促通知画面の一例を示す図であり、ユーザB.Bの端末20の表示部24に表示される画面の一例を示している。
この割り勘催促通知画面には、「A.Aさんから割り勘の催促が届きました」という文字が表示され、その下に、割り勘リクエスト通知画面と同様に、ユーザB.Bの過不足金額を含む過不足金額表示領域が表示されている。
このような表示を行うことで、割り勘を依頼されたユーザが精算を忘れた(または忘れている)場合であっても、確実に精算を行わせることが可能となる。
<第2変形例(6)>
第2実施例では、全ての対象端末のユーザの電子マネー口座残高がマイナスとならない場合に、割り勘成立と判定することとして説明した。
これに関して、限定ではなく例として、電子マネー口座残高がマイナスとなる対象端末のユーザが存在する場合に、サーバ10によって(支払いアプリケーションの事業者によって)、不足分の金額を立て替えるなどして電子マネー口座に補充して、割り勘成立と判定するようにしてもよい。この場合、立て替えた金額は、ユーザに後で精算してもらうようにすればよい。
<第3実施例>
第3実施例は、各々の割り勘メンバーが、自分の過不足金額ばかりでなく、他の割り勘メンバーの過不足金額を自分の端末20で確認することを可能とする実施例である。
第3実施例は、第2実施例の処理に、端末20が、サーバ10から少なくとも割り勘メンバー各々の過不足金額の情報を受信して表示部24に表示させる処理を追加した実施例である。
第3実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
<表示画面例>
図3−1は、本実施例における買い物決済履歴選択画面の一例を示す図であり、ユーザA.Aの端末20の表示部24に表示される画面の一例を示している。
この買い物決済履歴選択画面では、図2−12の買い物決済履歴選択画面と同様に、自己の端末20のユーザについての複数の買い物決済履歴が表示されている。この例では、「AAレンタサイクル」と「BBスーパー」の買い物決済履歴のチェックが「ON」とされた状態が示されている。
また、図3−1の買い物決済履歴選択画面は、図2−12の買い物決済履歴選択画面とは、画面下部に表示されるアイコンが異なっている。具体的には、図2−12の買い物決済履歴選択画面では、割り勘リクエストアイコンが画面下部に表示されていたが、図3−1の買い物決済履歴選択画面では、割り勘リクエストアイコンに代えて、割り勘の内容を確認するための、限定ではなく例として「割り勘内容を確認」と示された割り勘内容確認アイコンが表示されている。
図3−2は、図3−1の買い物決済履歴選択画面において割り勘内容確認アイコンが操作(限定ではなく例としてタッチ操作)されたことに基づいて表示される割り勘内容確認画面の一例を示す図である。
この割り勘内容確認画面には、自己の端末20のユーザを含む各々の割り勘メンバーについて、支払い済み金額を表示するための支払い済み金額一覧表示領域と、過不足金額を表示するための過不足金額一覧表示領域とが設けられている。
この例では、支払い済み金額一覧表示領域には、自己の端末20のユーザ(ユーザA.A)は「4,500円」が支払い済み金額として表示され、それ以外の割り勘メンバーのユーザ(ユーザB.B、ユーザC.C、ユーザD.D、ユーザE.E)は「0円」が支払い済み金額として表示されている。
また、この例では、1人あたり金額が「900円」であることから、過不足金額一覧表示領域には、自己の端末20のユーザ(ユーザA.A)は「3600円 受取」が過不足金額として表示され、それ以外の割り勘メンバーのユーザ(ユーザB.B、ユーザC.C、ユーザD.D、ユーザE.E)は「900円 支払い」が過不足金額として表示されている。
また、支払い済み金額一覧表示領域および過不足金額一覧表示領域の下には、1人あたり金額が表示される1人あたり金額表示領域が設けられており、この例では、「900円」が1人あたり金額として表示されている。
また、1人あたり金額表示領域の下には、コメントを入力するためのコメント入力領域が設けられている。この例では、割り勘マスターであるユーザA.Aによって、「先日の旅行での支払いの割り勘です。」という内容のコメントが入力されて表示された状態が示されている。
また、この割り勘内容確認画面には、図2−12の買い物決済履歴選択画面に表示されていた「割り勘リクエストアイコン」が画面下部に表示されている。この割り勘リクエストアイコンが操作されることで、割り勘リクエストが他の割り勘メンバーの端末20に送信される。
上記の各種の情報は、限定ではなく例として、割り勘確認情報がサーバ10から端末20に送信されることで表示される。この例において、割り勘確認情報には、登録された買い物決済履歴に基づく支払い済み金額の情報と、各々の割り勘メンバーの過不足金額の情報と、登録されたコメントの情報とを含めることができる。
なお、必ずしも上記の全ての情報を割り勘確認情報に含めなければならないわけではなく、その一部の情報を割り勘確認情報に含めるようにしてもよい。限定ではなく例として、各々の割り勘メンバーの過不足金額の情報を割り勘確認情報に含めるようにし、各々の割り勘メンバーの過不足金額の情報を端末20で確認できるようにしてもよい。
図3−3は、図3−2の割り勘内容確認画面において割り勘リクエストアイコンが操作(限定ではなく例としてタッチ操作)されたことに基づいてユーザB.Bの端末20の表示部24に表示される割り勘リクエスト通知画面の一例を示す図である。
この割り勘リクエスト通知画面では、図2−13の割り勘リクエスト通知画面とは異なり、過不足金額表示領域の下に、割り勘マスターであるユーザA.Aによって入力されたコメントが表示されている。この例では、ユーザA.Aのアイコン画像およびユーザ名と関連付けて、「先日の旅行での支払いの割り勘です。」のコメントが吹き出しで表示されている。
また、図3−3の割り勘リクエスト通知画面では、図2−13の割り勘リクエスト通知画面とは異なり、精算内容の詳細を確認するための、限定ではなく例として「精算内容を確認する」と示された精算内容確認アイコンが表示されている。
図3−4は、図3−3の割り勘リクエスト通知画面において精算内容確認アイコンが操作(限定ではなく例としてタッチ操作)された場合に表示される精算内容確認画面の一例を示す図である。
この精算内容確認画面では、上から順に、自己の端末20のユーザであるユーザB.Bと、割り勘マスターであるユーザA.Aと、それ以外の割り勘メンバー(ユーザC.C、ユーザD.D、ユーザE.E)とのアイコン画像およびユーザ名が表示されている。また、各々の割り勘メンバーと関連付けて、支払い済み金額一覧表示領域にはその割り勘メンバーの支払い済み金額が表示され、過不足金額一覧表示領域にはその割り勘メンバーの過不足金額が表示されている。
図3−5は、図3−4の精算内容確認画面において支払い済み金額一覧表示領域が操作(限定ではなく例としてタッチ操作)された場合の表示の一例を示す図である。
支払い済み金額一覧表示領域のうち、一のユーザの支払い済み金額の表示領域が操作されると、その支払い済み金額に対応する支払い内容、つまり、割り勘の内訳が確認可能に構成されている。この例では、支払い済み金額一覧表示領域のうち、割り勘マスターであるユーザA.Aに関連付けられた支払い済み金額(この例では「4,500円」)の表示領域がユーザB.Bによってタッチ操作されたことに基づいて、その支払い済み金額に対応する支払い内容がポップアップ形式で表示されている。
<処理>
図3−6は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。
この処理は、図2−17〜図2−19の処理のうちの図2−17の処理部分に、端末Aの処理としてA410、A420のステップを追加し、サーバ10の処理としてS410のステップを追加した処理である。
S180、S190の後、サーバ10の制御部11は、前述した割り勘確認情報を通信I/F14によって端末Aに送信する(S410)。そして、制御部11は、図2−18のS210に処理を移す。
通信I/F22によってサーバ10から割り勘確認情報を受信すると(A410)、端末Aの制御部21は、受信された割り勘確認情報を表示部24に表示させる(A420)。これにより、前述した過不足金額の情報等を含む各種の情報が表示部24に表示される。そして、端末Aの制御部21は、図2−18のA210に処理を移す。
<第3実施例の効果>
第3実施例は、端末20が、自己の端末20のユーザによる買い物決済履歴に基づく、少なくとも、自己の端末20のユーザの過不足金額(限定ではなく、第1金額の一例)の情報と、異なる端末20のユーザの過不足金額(限定ではなく、第2金額の一例)の情報とを含む割り勘確認情報(限定ではなく、金額情報の一例)を通信I/F22によってサーバ10から受信する。そして、端末20は、受信された割り勘確認情報を表示部24に表示する構成を示している。
このような構成により得られる効果の一例として、少なくとも第1金額の情報と第2金額の情報とを含む金額情報を、端末のユーザが確認できるようにすることができる。
<第3変形例(1)>
第3実施例において、各々の割り勘メンバーの過不足金額に基づく割り勘精算の状況(以下、「割り勘精算状況」と称する。)を端末20のユーザが確認できるようにすることも可能である。
図3−7は、本変形例における割り勘内容確認画面の一例を示す図であり、ユーザB.Bの端末20の表示部24に表示される画面の一例を示している。
この割り勘内容確認画面には、限定ではなく例として、各々の割り勘メンバーのアイコン画像と関連付けて、その割り勘メンバーの過不足金額と、その割り勘メンバーの割り勘精算状況とが表示されている。
割り勘マスター(ユーザA.A)の欄には、割り勘精算状況として、限定ではなく例として、割り勘マスターの過不足金額(受け取るべき金額)と、他の割り勘メンバーからの金銭の受け取りの状況(受取済/未受取)とが表示される。他の割り勘メンバーのうちの一部の割り勘メンバーから金銭を受け取り済みである場合は、受け取った金額とともに、「受取済」が表示される。
また、割り勘マスター以外の割り勘メンバー(この例では自分(ユーザB.B)、ユーザC.C、ユーザD.D、ユーザE.E)の欄には、割り勘精算状況として、限定ではなく例として、その割り勘メンバーの過不足金額(支払うべき金額)と、その割り勘メンバーの金額の支払いの状況(精算済み/未精算)とが表示される。
また、割り勘精算状況の表示領域の下には、限定ではなく例として、この割り勘精算状況を最新の状態に更新するための、限定ではなく例として、更新マークと、「更新する」の文字とを含む割り勘精算状況更新アイコンが設けられている。この割り勘精算状況更新アイコンが操作されると、最新の割り勘精算状況がサーバ10から端末20に送信されて、表示が更新される。
この例では、自分(ユーザB.B)の割り勘精算状況として、「900円 支払い」および「未精算」が表示されている。
また、割り勘マスター(ユーザA.A)および自分(ユーザB.B)以外の割り勘メンバーの割り勘精算状況として、ユーザC.Cには「900円 支払い」および「未精算」が、ユーザD.Dには「900円 支払い」および「精算済み」が、ユーザE.Eには「900円 支払い」、「未精算」がそれぞれ表示されている。
また、ユーザD.Dが精算済みであり、割り勘マスター(ユーザA.A)はユーザD.Dから「900円」を受け取り済みであることから、割り勘マスター(ユーザA.A)の割り勘精算状況として、「3,600円 受取」および「900円 受取済」が表示されている。
このような表示を行うことで、各々の端末20のユーザは、自分以外のユーザの精算状況を確認することができるため、ユーザの利便性を向上させることができる。
<第3変形例(2)>
各々の割り勘メンバーが割り勘で負担する金額、または金額を負担する割合を、端末20のユーザによる入力に基づいて変更することを可能としてもよい。
図3−8は、割り勘内容確認画面の別例を示す図であり、ユーザA.Aの端末20の表示部24に表示される画面の一例を示している。
この割り勘内容確認画面では、限定ではなく例として、図3−5の割り勘内容確認画面における1人あたり金額表示領域の横に、各々の割り勘メンバーの割り勘での金額の負担の割合(以下、「割り勘割合」と称する。)を表示するための、限定ではなく例として「分担割合を確認」と示された割り勘割合確認アイコンが設けられている。
なお、この表示画面例では、割り勘割合を「分担割合」として表示している。
図3−9は、図3−8の割り勘内容確認画面において割り勘割合確認アイコンが操作(限定ではなく例としてタッチ操作)されたことに基づいて表示される割り勘割合確認画面の一例を示す図である。
この割り勘割合確認画面には、「割り勘の分担割合を確認してください」の文字が表示され、その下に、買い物決済による支払い金額の総額(支払総額)が表示される支払総額表示領域が設けられている。
ここで、「支払総額」とは、各々の割り勘メンバーが登録した買い物決済履歴に基づく支払い済み金額を総計した金額である。
本実施例では、ユーザA.Aのみが買い物決済履歴を登録することにしているため、「ユーザA.Aの支払い済み金額=支払総額」となる。その結果、この例では、支払総額として「4,500円」が表示されている。
なお、この例のように一人のユーザのみが買い物決済履歴を登録する場合、支払総額の表示は、そのユーザの支払い済み金額の表示としてもよい。
また、その下には、各々の割り勘メンバーのアイコン画像と関連付けて、過不足金額のうちの精算済みの金額をグラフで表示するためのグラフ表示領域が設けられている。この例では、グラフ表示領域には、精算済みの金額に応じて長さが変化する横方向の棒グラフが表示されている。
具体的には、この例では、割り勘マスター(ユーザA.A)が買い物決済で「4,500円」を支払い済みであり、他のいずれの割り勘メンバーからも未だ金銭を受け取っていないため、ユーザA.Aのアイコン画像の横には「4,500円」に相当する長さの棒グラフが表示されている。また、他の割り勘メンバーは、いずれも未だユーザA.Aに金額を支払っておらず、棒グラフの長さが“0”であるため、ユーザA.A以外の割り勘メンバーのアイコン画像と関連付けて、破線で囲われた「0円」が表示されている。
この状態において、割り勘メンバーの誰かがユーザA.Aに金銭を送金すると、その割り勘メンバーに関連付けられた棒グラフの長さが、ユーザA.Aに送金した金額に相当する長さに更新されて表示される。
また、グラフ表示領域の横には、各々の割り勘メンバーの過不足金額が表示されている。この例では、割り勘マスター(ユーザA.A)には過不足金額として「3,600円、受取」が表示され、他の割り勘メンバーには過不足金額として「900円 支払い」が表示されている。
また、画面下部には、割り勘割合を変更するための、限定ではなく例として「分担割合を変更する」と示された割り勘割合変更アイコンが表示されている。
図3−10は、図3−9の割り勘割合確認画面において割り勘割合変更アイコンが操作(限定ではなく例としてタッチ操作)されたことに基づいて表示される割り勘割合変更画面の一例を示す図であり、ユーザA.Aの端末20の表示部24に表示される画面の一例を示している。
この割り勘割合変更画面には、各々の割り勘メンバーの割り勘割合を変更するための割り勘割合変更用グラフが表示されている。この例では、割り勘割合変更用グラフとして、ドーナツ形状のグラフ(以下、「ドーナツグラフ」と称する。)で表されるグラフが表示されている。このドーナツグラフは、円グラフの中心部に穴が開いた形状のグラフであり、この例では、中心部の穴が開いた領域に支払総額が表示されている。
また、ドーナツグラフは、各々の割り勘メンバーに対応する複数の領域を有しており、各々の割り勘メンバーのアイコン画像と関連付けて、その割り勘メンバーの割り勘割合と、その割り勘割合と支払総額とに基づき計算される過不足金額(=支払総額×割り勘割合)とが表示されている。
各々の割り勘メンバーの割り勘割合は、ドーナツグラフのうちのその割り勘メンバーに対応する表示領域とそれに隣接する割り勘メンバーに対応する表示領域との境界部分をいずれかの方向にスワイプ操作することで変更可能に構成されている。
限定ではなく例として、ドーナツグラフのうち、ユーザB.Bの表示領域とユーザC.Cの表示領域との境界部分が指でタッチされ、その後、ユーザB.B側、またはユーザC.C側に指を移動させる操作が行われることで、ユーザB.BおよびユーザC.Cの割り勘割合が変更される。
具体的には、限定ではなく例として、ユーザB.B側に指を移動させると、ドーナツグラフのうちのユーザB.Bの表示領域が占める割合が減少し、ユーザB.Bの割り勘割合が減少してユーザC.Cの割り勘割合が増加する。一方、ユーザC.C側に指を移動させると、ドーナツグラフのうちのユーザB.Bの表示領域が占める割合が増加し、ユーザB.Bの割り勘割合が増加してユーザC.Cの割り勘割合が減少する。この場合、他の割り勘メンバーの割り勘割合は変わらない。
なお、この例では、ドーナツグラフを用いて割り勘割合を変更する場合を例示したが、棒グラフ、円グラフ、帯グラフといったドーナツグラフ以外のグラフを用いて割り勘割合を変更するようにしてもよいし、そのようにしなくてもよい。また、割り勘割合を数値で入力して変更するようにしてもよいし、そのようにしなくてもよい。
また、割り勘割合に代えて、同様の手法に従って、過不足金額を変更するようにしてもよいし、そのようにしなくてもよい。
図3−11は、本変形例における各装置が実行する処理の流れの一例を示すフローチャートである。
この処理は、図3−6の処理に、端末Aの処理としてA430、A440のステップを、サーバ10の処理としてS440のステップを追加した処理である。
A420の後、端末Aの制御部21は、限定ではなく例として、入出力部23に対して割り勘割合変更操作が入力されたか否かに基づいて、割り勘割合を変更するか否かを判定する(A430)。
割り勘割合を変更すると判定したならば(A430:YES)、端末Aの制御部21は、限定ではなく例として、割り勘割合変更操作によって指定された割り勘割合を含む割り勘変更依頼情報を、通信I/F22によってサーバ10に送信した後(A440)、A410に処理を戻す。
一方、割り勘割合を変更しないと判定したならば(A430:NO)、端末Aの制御部21は、図2−18のA210に処理を移す。
S410の後、制御部11は、通信I/F14によって端末Aから割り勘変更依頼情報を受信したか否かを判定し(S440)、受信したと判定したならば(S440:YES)、S190に処理を戻す。つまり、端末Aから受信された割り勘変更依頼情報に含まれる割り勘割合に基づいて、過不足金額を再計算する。
制御部11は、端末20から割り勘変更依頼情報を受信しなくなるまで(S440:NO)、S190、S410の処理を繰り返す。そして、端末20から割り勘変更依頼情報を受信しなくなったと判定したならば(S440:NO)、制御部11は、図2−18のS210に処理を移す。
本変形例によれば、端末は、第1金額の情報と第2金額の情報とのうちの少なくともいずれかを変更するための情報を送信することで、第1金額の情報と第2金額の情報とのうちの少なくともいずれかを簡単に変更させることができる。
<第4実施例>
第4実施例は、自己の端末20のユーザによる買い物決済履歴と、異なる端末20のユーザによる買い物決済履歴とに基づいて、過不足金額を計算する実施例である。
第1実施例〜第3実施例とは、端末20のユーザ、または異なる端末20のユーザにより、買い物決済履歴を追加して登録することが可能に構成されている点が異なる。
第4実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
<表示画面例>
図4−1は、本実施例における割り勘内容確認画面の一例を示す図であり、ユーザB.Bの端末20の表示部24に表示される画面の一例を示している。
本実施例では、第1のユーザが割り勘対象とする買い物決済履歴を登録済みの状態で、さらに、第1のユーザとは異なる第2のユーザが割り勘対象とする買い物決済履歴を追加して登録することが可能に構成されている。ここでは、先に例示したように、ユーザA.Aによって自身の買い物決済履歴が登録された状態で、ユーザB.Bが自身の買い物決済履歴を追加して登録する場合を例示する。
この割り勘内容確認画面は、図3−4の割り勘内容確認画面とほぼ同様であるが、画面下部に表示されるアイコンが異なっている。具体的には、限定ではなく例として「精算する」と示された精算アイコンに加えて、自分(ユーザB.B)の買い物決済履歴を追加登録するための、限定ではなく例として「支払い分を追加」と示された買い物決済履歴追加アイコンが表示されている。
図4−2は、図4−1の割り勘内容確認画面において買い物決済履歴追加アイコンが操作(限定ではなく例としてタッチ操作)されたことに基づいて表示される買い物決済履歴選択画面の一例を示す図である。
この買い物決済履歴選択画面には、ユーザB.Bによる複数の買い物決済履歴が表示されている。この例では、「DDカフェ」、「EEレストラン」、「FFコンビニエンス」等の、複数の店舗での買い物決済履歴が表示されている。画面下部には、選択された買い物決済履歴を登録するための、限定ではなく例として「登録」と示された買い物決済履歴登録アイコンが表示されている。
図4−3は、図4−2の買い物決済履歴選択画面において買い物決済履歴登録アイコンが操作(限定ではなく例としてタッチ操作)されたことに基づいてユーザB.Bの端末20の表示部24に表示される割り勘内容確認画面の一例を示す図である。
この例では、ユーザA.Aによって先に登録されていた「4,500円」分の買い物決済履歴に加えて、ユーザB.Bによって「5,500円」分の買い物決済履歴が追加登録された状態が示されている。また、その結果、支払い済み金額一覧表示領域には、自分(ユーザB.B)のアイコン画像と関連付けて支払い済み金額「5,500円」が表示され、ユーザA.Aのアイコン画像と関連付けて支払い済み金額「4,500円」が表示されている。
ここで、前述したように、各々の割り勘メンバーが登録した買い物決済履歴に基づく支払い済み金額を総計した金額を「支払総額」とする。そして、本実施例では、「1人あたり金額=支払総額÷割り勘を行う人数」として計算する。
この例では、ユーザA.AとユーザB.Bとがそれぞれ買い物決済履歴を登録しているため、「ユーザA.Aの支払い済み金額+ユーザB.Bの支払い済み金額=支払総額」となる。ユーザA.Aの支払い済み金額は「4,500円」であり、ユーザB.Bの支払い済み金額は「5,500円」であるため、支払総額は「4,500円+5,500円=10,000円」となる。割り勘を行う人数は「5人」であるため、「1人あたり金額=10,000÷5人=2,000円」となる。その結果、1人あたり金額として「2,000円」が表示されている。
また、過不足金額一覧表示領域には、各々のユーザの支払い済み金額と、1人あたり金額とに基づき計算された過不足金額が表示されている。具体的には、自分(ユーザB.B)の過不足金額として「5,500円−2,000円=+3,500円(3,500円 受取)」が表示され、ユーザA.Aの過不足金額として「4,500円−2,000円=+2,500円(2,500円 受取)」が表示され、それ以外の割り勘メンバーの過不足金額として「0円−2,000円=−2,000円(2,000円 支払い)」が表示されている。
図4−4は、図4−3の割り勘内容確認画面において精算アイコンが操作(限定ではなく例としてタッチ操作)されたことに基づいてユーザB.Bの端末20の表示部24に表示される割り勘リクエスト通知画面の一例を示す図である。
この割り勘リクエスト通知画面では、ユーザB.Bの過不足金額として「3,500円 受取」が過不足金額表示領域に表示されている。
また、過不足金額表示領域が操作されると、その下に。ユーザA.Aのコメントと、割り勘の内訳とが表示される。この例では、割り勘の内訳として、ユーザA.Aによって登録された買い物決済履歴と、ユーザB.Bによって登録された買い物決済履歴とが表示されており、合計金額として「10,000円」が、1人あたり金額として「2,000円」が表示されている。また、この例では、「EEレストラン」の買い物決済履歴がユーザB.Bによって新しく登録された買い物決済履歴であることを示すため表示として、「EEレストラン」の買い物決済履歴に関連付けられたユーザB.Bのアイコン画像の左上に「N(New)」のマークが付されて表示されている。
図4−5は、図4−3の割り勘内容確認画面において精算アイコンが操作(限定ではなく例としてタッチ操作)されたことに基づいてユーザA.Aの端末20の表示部24に表示される割り勘リクエスト通知画面の一例を示す図である。
この割り勘リクエスト通知画面では、ユーザA.Aの過不足金額として「2,500円 受取」が過不足金額表示領域に表示されている。
また、過不足金額表示領域が操作されると、その下に、自分(ユーザA.A)のコメントと、割り勘の内訳とが表示される。表示されるコメントおよび割り勘の内訳は、図4−4と同様である。
<機能構成>
図4−6は、本実施例においてサーバ10の記憶部15に記憶される情報の一例を示す図である。
記憶部15には、支払いアプリケーション管理処理プログラム151と、支払いアプリケーションユーザ登録データ153と、ユーザ管理データベース155とに加えて、限定ではなく例として、割り勘管理データベース157が記憶される。
割り勘管理データベース157は、サーバ10が端末20のユーザによる割り勘を管理するためのデータベースであり、その一例である第1の割り勘管理データベース157Aの構成例を図4−7に示す。
第1の割り勘管理データベース157Aには、割り勘ごとの管理データとして、割り勘管理データが記憶される。
各割り勘管理データには、限定ではなく例として、割り勘管理IDと、割り勘マスターIDと、割り勘メンバーIDと、買い物決済履歴管理データとが記憶される。
割り勘管理IDには、その割り勘を固有に識別するためのID(識別情報)が記憶される。限定ではなく例として、複数のユーザのグループで割り勘を行うことが決定された場合、そのグループ内での割り勘を1つの単位として、固有のIDがサーバ10によって設定されて記憶される。
割り勘マスターIDには、限定ではなく例として、割り勘マスターの支払いアプリケーションIDが記憶される。
割り勘メンバーIDには、各々の割り勘メンバーの支払いアプリケーションIDが記憶される。
買い物決済履歴管理データは、割り勘対象とされた1以上の買い物決済履歴を管理するためのデータであり、限定ではなく例として、決済者IDと、買い物決済IDと、割り勘対象金額とが関連付けて記憶される。
決済者IDには、その買い物決済履歴について決済を行ったユーザの支払いアプリケーションIDが記憶される。この決済者IDには、割り勘マスターIDに限らず、割り勘メンバーIDに含まれる各々のユーザのIDも記憶され得る。つまり、割り勘マスターが登録した買い物決済履歴に限らず、割り勘マスター以外の割り勘メンバーが登録した買い物決済履歴も、買い物決済履歴管理データに記憶される。
買い物決済IDには、ユーザ管理データベース155に含まれる、その決済者IDのユーザの支払いアプリケーションIDに対応するユーザ管理データにおいて、買い物決済履歴データに含まれる買い物決済履歴の買い物決済IDのうち、その決済者IDのユーザによって登録された買い物決済履歴に対応する買い物決済IDが記憶される。
割り勘対象金額には、その買い物決済IDに対応する買い物決済履歴の買い物決済金額を上限とする金額であって、割り勘対象とする金額として、その決済者IDのユーザによって指定された金額が記憶される。
なお、割り勘メンバーIDについて、割り勘マスター以外の割り勘メンバーの支払いアプリケーションIDを記憶させるようにしてもよいし、そのようにしなくてもよい。つまり、割り勘マスターIDを割り勘メンバーIDの欄から除外するようにしてもよいし、そのようにしなくてもよい。
<処理>
図4−8は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。
図4−8の処理は、図2−16〜図2−18の処理のうちの図2−18の処理部分において、端末Aの処理としてA530のステップを追加し、端末Bの処理としてA530のステップを追加し、サーバ10の処理としてS530〜S570のステップを追加した処理である。
なお、既出の処理と同一のステップについては同一の符号を付して再度の説明を省略する。
A210の後、端末Aの制御部21は、割り勘追加登録処理を実行する(A530)。同様に、B210の後、端末Bの制御部21は、割り勘追加登録処理を実行する(A530)。
図4−9は、割り勘追加登録処理の流れの一例を示すフローチャートである。
制御部21は、自己の端末20のユーザが割り勘に同意したか否かを判定する(A5310)。具体的には、限定ではなく例として、割り勘に同意する意思を示すための操作が入出力部23に入力されたか否かを判定する。
割り勘に同意しないと判定した場合(A5310:NO)、制御部21は、買い物決済履歴を追加するか否かを判定する(A5320)。具体的には、限定ではなく例として、買い物決済履歴を追加するための操作が入出力部23に入力されたか否かを判定する。
買い物決済履歴を追加すると判定したならば(A5320:YES)、制御部21は、割り勘精算追加処理を実行する(A5330)。そして、制御部21は、限定ではなく例として、追加する買い物決済履歴の買い物決済IDを含む割り勘精算追加通知を、通信I/F22によってサーバ10に送信する(A5340)。
一方、買い物決済履歴を追加しないと判定したならば(A5320:NO)、制御部21は、割り勘精算拒否通知を通信I/F22によってサーバ10に送信する(A5350)。
また、割り勘に同意すると判定したならば(A5310:YES)、制御部21は、割り勘精算承認通知を通信I/F22によってサーバ10に送信する(A5360)。
A5340、A5350またはA5360の後、制御部21は、通信I/F22によってサーバ10から割り勘変更通知を受信したか否かを判定し(A5370)、受信したと判定したならば(A5370:YES)、受信された割り勘変更通知を表示部24に表示させる(A5380)。そして、制御部21は、A5310に処理を戻す。
一方、割り勘変更通知を受信しなかったと判定したならば(A5370:NO)、制御部21は、割り勘追加登録処理を終了する。
S210の後、サーバ10の制御部11は、第2の割り勘承認管理処理を実行する(S530)。
図4−10は、第2の割り勘承認管理処理の流れの一例を示すフローチャートである。
この処理は、第1の割り勘承認管理処理(図2−20参照)におけるS2310のステップをS5310に置き換えるとともに、S5320〜S5340のステップを追加した処理である。本処理において、割り勘精算通知は、前述した「割り勘精算承認通知」と、「割り勘精算拒否通知」と、「割り勘精算追加通知」とのうちのいずれかの通知である。
なお、既出の処理と同一のステップについては同一の符号を付して再度の説明を省略する。
制御部11は、端末20から割り勘精算通知を受信すると(S5310)、受信された割り勘精算通知が「割り勘精算追加通知」であるか否かを判定する(S5320)。受信された割り勘精算通知が割り勘精算追加通知ではないと判定したならば(5320:NO)、制御部11は、S2320に処理を移す。
一方、受信された割り勘精算通知が割り勘精算追加通知であると判定したならば(S5320:YES)、制御部11は、第1の割り勘管理データベース157Aのうちの、対応する割り勘管理データにおける買い物決済履歴管理データを更新する。そして、制御部11は、受信された割り勘精算追加通知に含まれる買い物決済IDによって識別される買い物決済履歴に基づいて、過不足金額を計算する(S5330)。
その後、制御部11は、計算した過不足金額に基づいて、割り勘内容を変更する(S5340)。そして、制御部11は、第2の割り勘承認管理処理を終了する。
図4−8に戻り、制御部11は、第2の割り勘承認管理処理で割り勘内容が変更されたか否かを判定し(S550)、変更されたと判定したならば(S550:YES)、割り勘変更通知を、通信I/F14によって端末Aおよび端末Bそれぞれに送信する(S570)。そして、制御部11は、S530に処理を戻す。
一方、第2の割り勘承認管理処理で割り勘内容が変更されなかったと判定したならば(S550:NO)、制御部11は、S240に処理を移す。
A530の後、端末Aの制御部21は、A250に処理を移す。同様に、A530の後、端末Bの制御部21は、B250に処理を移す。
<第4実施例の効果>
第4実施例は、各々の割り勘メンバーの過不足金額(限定ではなく、第1金額、第2金額の一例)は、一の端末20のユーザとは異なる割り勘メンバーによる買い物決済履歴(限定ではなく、異なる端末のユーザによる第2決済に関する第2決済情報の一例)と、一のユーザによる買い物決済履歴(限定ではなく、第1決済情報の一例)とに基づいて決定される構成を示している。
このような構成により得られる効果の一例として、第1決済情報ばかりでなく、異なる端末のユーザによる第2決済に関する第2決済情報も考慮して、第1金額と第2金額とを決定させることができるため、ユーザの利便性を向上させることができる。
<第4変形例(1)>
第4実施例において、割り勘マスターのユーザが、他の割り勘メンバーによる買い物決済履歴の追加の許可/禁止の設定を行うことができるようにしてもよいし、そのようにしなくてもよい。
図4−11は、本変形例において、図3−1の買い物決済履歴選択画面において割り勘内容確認アイコンが操作されたことに基づいて、割り勘マスターであるユーザA.Aの端末20の表示部24に表示される割り勘内容確認画面の一例を示す図である。
この割り勘内容確認画面では、支払い済み金額表示領域において、自分(ユーザA.A)以外の割り勘メンバーのアイコン画像およびユーザ名と関連付けて、その割り勘メンバーが自身の買い物決済履歴を追加するための、限定ではなく例として「追加依頼」と示された買い物決済履歴追加依頼アイコンが表示されている。割り勘マスターであるユーザA.Aは、限定ではなく例として、各々の割り勘メンバーに関連付けられた買い物決済履歴追加依頼アイコンをタッチ操作することで、その割り勘メンバーによる買い物決済履歴の追加の許可/禁止の設定を行うことが可能に構成されている。
、
買い物決済履歴追加依頼アイコンは、限定ではなく例として、買い物決済履歴の追加が許可された割り勘メンバーについてはアクティブ状態で表示され、買い物決済履歴の追加が禁止された割り勘メンバーについては非アクティブ状態で表示される。この例では、割り勘マスターであるユーザA.Aによって、ユーザE.Eによる買い物決済履歴の追加を禁止する設定が行われ、これにより、ユーザE.Eに関連付けられた追加依頼アイコンが非アクティブ状態で表示されている。
これは、ユーザA.A〜ユーザE.Eのグループで旅行に行った際の買い物決済履歴を割り勘することをユーザA.Aが提案した場合、限定ではなく例として、この旅行に関して、ユーザE.Eが「1円」も金銭を支払っていないことをユーザA.Aが覚えており、ユーザE.Eが買い物決済履歴を追加することはあり得ない(またはユーザE.Eが買い物決済履歴を追加することを認めない)とユーザA.Aが判断したような場合である。
これはあくまでも一例であるが、割り勘マスターが、特定の割り勘メンバーについて、買い物決済履歴が追加されることはないと判断した場合や、買い物決済履歴を追加することを認めないと判断したような場合に、その割り勘メンバーによる買い物決済履歴の追加を禁止するようにすることができる。
図4−12は、この例においてユーザE.Eの端末20の表示部24に表示される割り勘内容確認画面の一例を示す図である。
この割り勘内容確認画面では、買い物決済履歴を追加登録するための買い物決済履歴追加アイコンが画面下部に設けられている。しかし、上記のように、ユーザE.Eによる買い物決済履歴の追加が禁止されたことで、買い物決済履歴追加アイコンが非アクティブ状態で表示されており、この買い物決済履歴追加アイコンに対する操作が無効化される(操作が行われても買い物決済履歴の追加に関する処理を実行しない)ようになっている。
この場合は、割り勘マスターの端末20から、サーバ10を介して、少なくとも買い物決済履歴の追加を禁止した割り勘メンバーの端末20に、買い物決済履歴の追加を禁止するための買い物決済履歴追加禁止情報を送信する。そして、買い物決済履歴追加禁止情報を受信した端末20は、買い物決済履歴追加禁止の設定を行い、買い物決済履歴の追加操作を無効化するようにすればよい。
なお、上記の例では、買い物決済履歴の追加登録の許可/禁止の設定を行う主体を割り勘マスターとしたが、これに限定されず、割り勘マスターに加えて、または割り勘マスターに代えて、割り勘マスター以外の割り勘メンバーが、買い物決済履歴の追加登録の許可/禁止の設定を行うことができるようにしてもよいし、そのようにしなくてもよい。
<第5実施例>
第5実施例は、メッセージングサービスを利用して、複数の端末20のユーザ間で割り勘を行う実施例である。
第5実施例は、第1実施例〜第4実施例の構成に、メッセージングサービスに関する構成が追加された実施例である。
第5実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
<システム構成>
図5−1は、本実施例における通信システム1Bのシステム構成の一例を示す図である。なお、通信システム1Aと同様の構成については同一の符号を付して、再度の説明を省略する。
通信システム1Bでは、限定ではなく例として、ネットワーク30を介して、サーバ10と、メッセージングサーバ40と、複数の端末20(端末20A,端末20B,端末20C,・・・)とが接続される。
メッセージングサーバ40(限定ではなく、サーバ、情報処理装置、情報管理装置の一例)は、端末20に対して、メッセージングサービスを提供する機能を有する。
メッセージングサーバ40は、メッセージングサービスに関する機能を実現できる情報処理装置であればどのような装置であってもよい。メッセージングサーバ40は、限定ではなく例として、サーバ装置、コンピュータ(限定ではなく例として、デスクトップ、ラップトップ、タブレットなど)、メディアコンピュータプラットホーム(限定ではなく例として、ケーブル、衛星セットトップボックス、デジタルビデオレコーダ)、ハンドヘルドコンピュータデバイス(限定ではなく例として、PDA、電子メールクライアントなど)、あるいは他種のコンピュータ、またはコミュニケーションプラットホームを含む。
メッセージングサーバ40は、制御部41(CPU)、記憶部45、通信I/F44(インタフェース)、入出力部42、ディスプレイ43、時計部49を備える。メッセージングサーバ40のHWの各構成要素は、限定ではなく例として、バスBを介して相互に接続される。なお、メッセージングサーバ40のHWは、メッセージングサーバ40のHWの構成として、全ての構成要素を含むことは必須ではない。限定ではなく例として、メッセージングサーバ40のHWは、ディスプレイ43を取り外すような構成であってもよいし、そうでなくてもよい。
制御部41は、プログラム内に含まれたコードまたは命令によって実現する機能を実行するために物理的に構造化された回路を有し、限定ではなく例として、ハードウェアに内蔵されたデータ処理装置により実現される。
制御部41は、代表的には中央処理装置(CPU)、であり、その他にマイクロプロセッサ、プロセッサコア、マルチプロセッサ、ASIC、FPGAであってもよいし、そうでなくてもよい。本開示において、制御部41は、これらに限定されない。
記憶部45は、メッセージングサーバ40が動作するうえで必要とする各種プログラムや各種データを記憶する機能を有する。記憶部45は、HDD、SSD、フラッシュメモリなど各種の記憶媒体により実現される。ただし、本開示において、記憶部45は、これらに限定されない。また、記憶部45は、メモリ(memory)と表現されてもよいし、されなくてもよい。
通信I/F44は、ネットワーク30を介して各種データの送受信を行う。通信は、有線、無線のいずれで実行されてもよく、互いの通信が実行できるのであれば、どのような通信プロトコルを用いてもよい。通信I/F44は、ネットワーク30を介して、端末20等の各種装置との通信を実行する機能を有する。通信I/F44は、各種データを制御部41からの指示に従って、端末20等の各種装置に送信する。また、通信I/F44は、端末20等の各種装置から送信された各種データを受信し、制御部41に伝達する。また、通信I/F44を単に通信部と表現する場合もある。また、通信I/F44が物理的に構造化された回路で構成される場合には、通信回路と表現する場合もある。
入出力部42は、メッセージングサーバ40に対する各種操作を入力する装置により実現される。入出力部42は、ユーザからの入力を受け付けて、入力に係る情報を制御部41に伝達できる全ての種類の装置のいずれかまたはその組み合わせにより実現される。入出力部42は、代表的にはキーボード等に代表されるハードウェアキーや、マウス等のポインティングデバイスで実現される。なお、入出力部42、限定ではなく例として、タッチパネルやカメラ(動画像を介した操作入力)、マイク(音声による操作入力)を含んでいてもよいし、そうでなくてもよい。ただし、本開示において、入出力部42は、これらに限定されない。
ディスプレイ43は、代表的にはモニタ(限定ではなく例として、液晶ディスプレイやOELD(organic electroluminescence display))で実現される。なお、ディスプレイ43は、ヘッドマウントディスプレイ(HDM)などであってもよいし、そうでなくてもよい。なお、これらのディスプレイ43は、3Dで表示データを表示可能であってもよいし、そうでなくてもよい。本開示において、ディスプレイ43は、これらに限定されない。
時計部49は、メッセージングサーバ40の内蔵時計であり、時刻情報(計時情報)を出力する。時計部49は、限定ではなく例として、ハードウェアクロックとしてのRTC(Real Time Clock)やシステムクロック等を有して構成される。時計部49は、限定ではなく例として、計時部や時刻情報検出部と表現することもできる。
<表示画面例>
図5−2は、本実施例におけるトークルーム画面の一例を示す図であり、ユーザA.Aの端末20の表示部24に表示される画面の一例を示している。
このトークルーム画面は、端末20で実行されるメッセージングアプリケーションを利用して、ユーザA.AがユーザB.Bとトークを行うための画面の一例である。トークはチャットの一例であり、トークルームはチャットルームの一例である。
ここで、「チャット」とは、コンピュータネットワーク上のデータ通信回線を用いて端末20のユーザ同士がコミュニケーションを行うための手段であり、「チャットルーム」は、このチャットを行うための仮想的な部屋である。チャットには、メッセージングサービスMS(インスタントメッセージングサービス(IMS)を含む。)、ソーシャルネットワーキングサービスSNSを利用するものを含む。また、限定ではなく例として、いわゆるショートメッセージサービスを利用するものを含めてもよい。
本実施例において、チャットには、メッセージングサービスを利用したトークが含まれ、チャットルームには、トークを行うためのトークルームが含まれる。トークルームには、本実施例のように、一対一でユーザがトークを行うためのトークルームの他、後述するように、メッセージングサービスにおいて形成された複数のユーザを含むグループでトークを行うためのグループトークルームが含まれる。
限定ではなく例として、画面向かって右側には、ユーザA.Aから発信されたメッセージが吹き出しで表示される。
一方、画面向かって左側には、トーク相手であるユーザB.Bのアイコン画像と関連付けて、ユーザB.Bから発信されたメッセージ(限定ではなく、コンテンツの一例)が吹き出しで表示される。
メッセージを送信した後、送信先の端末20でメッセージングアプリケーションのトークルーム画面が開かれると、送信したメッセージが相手方のユーザによって読まれたことになる。そして、送信元の端末20のトークルーム画面では、サーバ10の制御に基づき、送信したメッセージと関連付けて「既読」の文字が表示される。
なお、送信先の端末20でメッセージングアプリケーションのトークルーム画面が開かれるまでの間は「既読」の文字が表示されないようにすることができる。このようにすることで、「未読」の状態であることを送信元の端末20のユーザが認識できるようにすることができる。
この例では、ユーザA.AからユーザB.Bに対して、先の旅行で使った金額の割り勘をリクエストするメッセージが表示されており、ユーザB.Bからの返信のメッセージとして、割り勘の依頼に承認するメッセージが表示されている。
また、画面下部には、メッセージングアプリケーションの機能として備えられた複数の機能に対応する機能アイコンが表示されている。この機能アイコンには、割り勘を行うための割り勘アイコンが含まれる。
図5−3は、図5−2のトークルーム画面において割り勘アイコンが操作(限定ではなく例としてタッチ操作)されたことに基づいて表示される買い物決済履歴選択画面の一例を示す図である。
この買い物決済履歴選択画面の構成は、先の実施例で示した買い物決済履歴選択画面とほぼ同様であるが、メッセージングアプリケーションの機能として表示される画面である点が異なる。この買い物決済履歴選択画面には、先の実施例で示した例と同様に、「AAレンタサイクル」、「BBスーパー」、「CC弁当」等の、複数の店舗での買い物決済履歴が表示されるとともに、各々の買い物決済履歴と関連付けて、その買い物決済履歴を割り勘対象とするためのチェックボックスが設けられている。
また、画面下部には、ユーザA.Aの端末20からユーザB.Bの端末20に割り勘リクエストを送信するための、限定ではなく例として「割り勘リクエストを送る」と示された割り勘リクエストアイコンが表示されている。
図5−4は、図5−3の買い物決済履歴選択画面において割り勘リクエストアイコンが操作されたことに基づいてユーザB.Bの端末20の表示部24に表示されるトークルーム画面の一例を示す図である。
このトークルーム画面には、図5−3のトークルーム画面におけるユーザB.BからユーザA.Aに対する割り勘の依頼に承認するメッセージの下に、メッセージングアプリケーションを利用して端末20間で送受信されるコンテンツの一例であって、割り勘リクエスト通知に相当するメッセージである「割り勘リクエストメッセージ」が、ユーザA.Aのアイコン画像と関連付けて吹き出しで表示されている。
ここで、割り勘リクエストメッセージは、単純なテキストばかりでなく、画像(静止画像、動画像等を含む。)、操作用情報(ボタン、アイコン等を含む。)、通信用情報やアクセス用情報(URI、URL等を含む。)など、送受信可能な各種の情報を含む広義の意味でのメッセージである。
なお、通常のテキストのメッセージと区別するために、割り勘リクエストメッセージではなく、割り勘リクエストコンテンツ等のように表現してもよいし、そのようにしなくてもよい。
この割り勘リクエストメッセージには、限定ではなく例として、支払いアプリケーションの名称(この例では「Payment App」)とともに、割り勘がリクエストされた旨と、ユーザB.Bの過不足金額と、割り勘の対象とされた買い物決済履歴の詳細とが含まれる。この例では、ユーザB.Bの過不足金額として「2,250円 支払い」が表示されている。
また、割り勘リクエストメッセージには、限定ではなく例として、ユーザB.BがユーザA.Aに対して過不足金額分の金銭を送金して精算を行うための精算アイコンと、割り勘を拒否するための拒否アイコンとが含まれる。
図5−5は、図5−4のトークルーム画面において精算アイコンが操作されたことに基づいて表示されるトークルーム画面の一例を示す図であり、ユーザB.Bの端末20の表示部24に表示される画面の一例を示している。
このトークルーム画面では、限定ではなく例として、精算アイコンが操作されたことに基づいて、ユーザB.BからユーザA.Aに対するメッセージとして「精算する」というメッセージが吹き出しで表示されるとともに、支払いアプリケーションを利用してユーザB.BからユーザA.Aに対して過不足金額(この例では「2,250円」)を送金したことを示す送金完了メッセージが表示されている。
<データ構成>
図5−6は、本実施例においてメッセージングサーバ40の制御部41によって実現される機能の一例を示す図である。
制御部41は、限定ではなく例として、記憶部45に記憶されているメッセージングアプリケーション管理処理プログラム451に従ってメッセージングアプリケーション管理処理を実行するためのメッセージングアプリケーション管理処理部411を有する。
図5−7は、本実施例においてメッセージングサーバ40の記憶部45に記憶される情報の一例を示す図である。
記憶部45には、プログラムとして、限定ではなく例として、メッセージングアプリケーション管理処理プログラム451が記憶される。
また、記憶部45には、データとして、限定ではなく例として、メッセージングアプリケーションユーザ登録データ453と、割り勘管理データベース457とが記憶される。
メッセージングアプリケーションユーザ登録データ453は、メッセージングアプリケーションを利用する端末20、またはその端末20のユーザに関する登録データであり、そのデータ構成の一例を図5−8に示す。
メッセージングアプリケーションユーザ登録データ453には、限定ではなく例として、ユーザ名と、メッセージングアプリケーションIDと、端末電話番号と、その他登録情報とが関連付けて記憶される。
ユーザ名は、メッセージングアプリケーションを利用する端末20のユーザの名称であり、限定ではなく例として、端末20のユーザがメッセージングアプリケーションを利用する際に登録する名称が記憶される。
メッセージングアプリケーションIDは、メッセージングアプリケーションのアカウント(アカウント情報)であって、端末20、または端末20のユーザを識別可能とするIDである。このメッセージングアプリケーションIDは、限定ではなく例として、メッセージングサーバ40によって固有のIDが設定されて記憶される。
端末電話番号は、このユーザ名のユーザの端末20の電話番号であり、限定ではなく例として、端末20のユーザがメッセージングアプリケーションを利用する際に登録する端末20の電話番号が記憶される。
その他登録情報には、限定ではなく例として、このユーザ名のユーザの端末20のメールアドレス(端末メールアドレス)や、メッセージングアプリケーションにおける各種の認証に利用される認証パスワード、このユーザが使用するアイコンの画像データ(ユーザアイコン画像)、ユーザのプロフィール(ユーザプロフィール)等を含めるようにすることができる。
ただし、これらの情報は必須ではない。
割り勘管理データベース457は、メッセージングサーバ40が端末20のユーザ間での割り勘を管理するためのデータベースであり、その一例である第3の割り勘管理データベース457Aの構成例を図5−9に示す。
第3の割り勘管理データベース457Aには、割り勘ごとの管理データとして、割り勘管理データが記憶される。
各割り勘管理データには、限定ではなく例として、割り勘管理IDと、割り勘マスターIDと、割り勘メンバーIDと、買い物決済履歴管理データとが記憶される。
割り勘管理ID、割り勘マスターID、割り勘メンバーIDは、前述した割り勘管理データベース157と同様である。
買い物決済履歴管理データには、限定ではなく例として、決済者IDと、割り勘対象金額と、店舗名と、買い物決済日時と、その他情報とが関連付けて記憶される。
<処理>
図5−10〜図5−12は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。
左側から順に、端末Aの制御部21が実行するメッセージング割り勘処理(以下、「MSG割り勘処理」と称する。)、端末Bの制御部21が実行するMSG割り勘処理、メッセージングサーバ40の制御部41が実行するメッセージング割り勘管理処理(以下、「MSG割り勘管理処理」と称する。)、サーバ10の制御部11が実行する割り勘精算管理処理をそれぞれ示している。
最初に、端末Aの制御部21は、通信I/F22によって割り勘開始通知をメッセージングサーバ40に送信する(A610)。通信I/F44によって端末Aから割り勘開始通知を受信すると(M610)、メッセージングサーバ40の制御部41は、端末Aのユーザによる買い物決済履歴を要求する買い物決済履歴要求情報を通信I/F44によってサーバ10に送信する(M620)。
通信I/F14によってメッセージングサーバ40から買い物決済履歴要求情報を受信すると(S620)、サーバ10の制御部11は、端末Aのユーザの支払いアプリケーションIDに関連付けられた買い物決済履歴を、通信I/F14によってメッセージングサーバ40に送信する(S630)。
通信I/F44によってサーバ10から買い物決済履歴を受信すると(M630)、制御部41は、受信された買い物決済履歴を、通信I/F44によって端末Aに送信する(M640)。
通信I/F22によってメッセージングサーバ40から買い物決済履歴を受信すると(A640)、端末Aの制御部21は、第2の買い物決済履歴選択処理を実行する(A650)。具体的には、端末Aの制御部21は、限定ではなく例として、端末Aの記憶部28に記憶された、ユーザA.Aによる複数の買い物決済履歴の中から、入出力部23に対する選択操作に基づいて、少なくとも1つの買い物決済履歴を選択する。
次いで、端末Aの制御部21は、A650の処理結果に基づき、買い物決済履歴選択情報を通信I/F22によってメッセージングサーバ40に送信する(A660)。
通信I/F44によって端末Aから買い物決済履歴選択情報を受信すると(M660)、制御部41は、受信された買い物決済履歴選択情報に基づいて、第3の割り勘管理データベース457Aのうちの、対応する割り勘管理データにおける買い物決済履歴管理データを更新する。そして、制御部41は、受信された買い物決済履歴選択情報に基づいて過不足金額を計算する(M670)。
その後、制御部41は、計算した過不足金額に基づき、割り勘精算依頼通知を通信I/F44によって端末Aおよび端末Bにそれぞれ送信する(M710)。
通信I/F22によってメッセージングサーバ40から割り勘精算依頼通知を受信すると(A710)、端末Aの制御部21は、入出力部23に対する操作入力に基づいて、割り勘に同意するか否かを判定する(A720)。
割り勘に同意すると判定したならば(A720:YES)、端末Aの制御部21は、通信I/F22によって割り勘精算承認通知をメッセージングサーバ40に送信する(A730)。
それに対し、割り勘に同意しないと判定したならば(A720:NO)、端末Aの制御部21は、通信I/F22によって割り勘精算拒否通知をメッセージングサーバ40に送信する(A740)。
端末Bの制御部21は、端末AのA710〜A740と同様の処理を行う(B710〜B740)。
M710の後、制御部41は、メッセージング割り勘承認管理処理(以下、「MSG割り勘承認管理処理」と称する。)を実行する(S)。
図5−13は、MSG割り勘承認管理処理の流れの一例を示すフローチャートである。
このMSG割り勘承認管理処理は、第1の割り勘承認管理処理(図2−20参照)と同様である。つまり、制御部41は、第1の割り勘承認管理処理のS2310〜S2360と同様の処理を行う(M7310〜M7360)。
図5−11に戻り、MGS割り勘承認管理処理で割り勘不成立と判定したならば(M740:NO)、制御部41は、通信I/F44によって割り勘不成立通知を端末Aおよび端末Bにそれぞれ送信する(M750)。
通信I/F22によってメッセージングサーバ40から割り勘不成立通知を受信すると(A750)、端末Aの制御部21は、受信された割り勘不成立通知を表示部24に表示させる(A760)。そして、端末Aの制御部21は、A890に処理を移す。
同様に、通信I/F22によってメッセージングサーバ40から割り勘不成立通知を受信すると(B750)、端末Bの制御部21は、受信された割り勘不成立通知を表示部24に表示させる(B760)。そして、端末Bの制御部21は、B890に処理を移す。
一方、MGS割り勘承認管理処理で割り勘成立と判定したならば(M740:YES)、制御部41は、通信I/F44によって割り勘成立通知を端末Aおよび端末Bにそれぞれ送信する(M810)。
通信I/F22によってメッセージングサーバ40から割り勘成立通知を受信すると(A810)、端末Aの制御部21は、割り勘精算要求情報を通信I/F22によってメッセージングサーバ40に送信する(A820)。
同様に、通信I/F22によってメッセージングサーバ40から割り勘成立通知を受信すると(B810)、端末Bの制御部21は、割り勘精算要求情報を通信I/F22によってメッセージングサーバ40に送信する(B820)。
通信I/F44によって端末Aおよび端末Bからそれぞれ割り勘精算要求情報を受信すると(M820)、制御部41は、割り勘精算要求情報を通信I/F44によってサーバ10に送信する(M830)。
通信I/F14によってメッセージングサーバ40から割り勘精算要求情報を受信すると(S830)、サーバ10の制御部11は、割り勘精算処理を行う(S840)。
次いで、制御部11は、通信I/F14によって割り勘精算結果をメッセージングサーバ40に送信する(B850)。
その後、制御部11は、処理を終了するか否かを判定し(S890)、処理を継続すると判定したならば(S890:NO)、S620に処理を戻す。一方、処理を終了すると判定したならば(S890:YES)、制御部11は、割り勘精算管理処理を終了する。
通信I/F44によってサーバ10から割り勘精算結果を受信すると(M850)、制御部41は、受信された割り勘精算結果を通信I/F44によって端末Aおよび端末Bにそれぞれ送信する(M860)。
その後、制御部41は、処理を終了するか否かを判定し(M890)、処理を継続すると判定したならば(M890:NO)、M610に処理を戻す。一方、処理を終了すると判定したならば(M890:YES)、制御部41は、MSG割り勘管理処理を終了する。
通信I/F22によってメッセージングサーバ40から割り勘精算結果を受信すると(A860)、端末Aの制御部21は、受信された割り勘精算結果を表示部24に表示させる(A870)。
同様に、通信I/F22によってメッセージングサーバ40から割り勘精算結果を受信すると(B860)、端末Bの制御部21は、受信された割り勘精算結果を表示部24に表示させる(B870)。
その後、端末Aの制御部21は、処理を終了するか否かを判定し(A890)、処理を継続すると判定したならば(A890:NO)、A610に処理を戻す。一方、処理を終了すると判定したならば(A890:YES)、端末Aの制御部21は、割り勘処理を終了する。
同様に、端末Bの制御部21は、処理を終了するか否かを判定し(B890)、処理を継続すると判定したならば(B890:NO)、B610に処理を戻す。一方、処理を終了すると判定したならば(B890:YES)、端末Bの制御部21は、割り勘処理を終了する。
<第5実施例の効果>
第5実施例は、端末20が、自己の端末20のユーザと、異なる端末20のユーザとを含み、自己の端末20から異なる端末20に送信されたメッセージ等(限定ではなく、コンテンツの一例)と、異なる端末20から自己の端末20に送信されたメッセージ等とを含むトークルーム(限定ではなく、チャットルームの一例)をメッセージングアプリケーションの画面に表示する。この場合、少なくとも自己の端末20のユーザの過不足金額の情報(限定ではなく、第1金額の情報の一例)が、トークルームに表示される構成を示している。
このような構成により得られる効果の一例として、第1金額の情報をチャットルームでユーザに確認させることができる。
また、第5実施例は、異なる端末20のユーザは、端末20のユーザによって選択されたトークルームに基づいて選択される構成を示している。
このような構成により得られる効果の一例として、端末のユーザによって選択されたチャットルームに基づいて、異なる端末のユーザを簡単に選択することができる。
また、第5実施例は、端末20が、自己の端末20のユーザと、異なる端末20のユーザとを含み、自己の端末20から異なる端末20に送信されたメッセージ(限定ではなく、コンテンツの一例)と、異なる端末20から自己の端末20に送信されたメッセージ(限定ではなく、コンテンツの一例)とを含むトークルーム(限定ではなく、チャットルームの一例)を表示部24に表示する。そして、端末20は、割り勘リクエストメッセージ(限定ではなく、第1決済情報に基づく、少なくとも端末と異なる端末との送金処理、または受取処理のリクエストに関する通知の一例)をトークルームに表示する構成を示している。
このような構成により得られる効果の一例として、少なくとも端末と異なる端末との送金処理、または受取処理のリクエストに関する通知を、チャットルームへの表示という分かり易い形で、ユーザに報知することができる。
また、第5実施例は、端末20が、自己の端末20のユーザを少なくとも含み、自己の端末20から送信されたメッセージ(限定ではなく、コンテンツの一例)を含むトークルーム(限定ではなく、チャットルームの一例)を表示部24に表示する。そして、端末20は、割り勘リクエストメッセージ(限定ではなく、第1決済情報の送信に関する通知の一例)をトークルームに表示する構成を示している。
このような構成により得られる効果の一例として、第1決済情報の送信に関する通知を、チャットルームへの表示という分かり易い形で、ユーザに報知することができる。
<第5変形例(1)>
第5実施例において、メッセージングアプリケーションにおいて、端末20が、送金処理、または受取処理に関するサービスを提供する企業のアカウントから発信されるメッセージ等のコンテンツをトークルームに表示するようにすることもできる。
図5−14は、本変形例におけるトークルーム画面の一例を示す図であり、ユーザB.Bの端末20の表示部24に表示される画面の一例を示している。
このトークルーム画面は、図5−5のトークルーム画面とほぼ同様であるが、トークルームに表示されるユーザB.Bのトーク相手が、ユーザA.Aではなく、支払いアプリケーションの公式アカウント(限定ではなく、送金処理、または受取処理に関するサービスを提供する企業のアカウントの一例)である点が異なる。この例において、ユーザB.Bは、メッセージングアプリケーションにおいて、あらかじめ支払いアプリケーションの公式アカウントを友だち登録しておく。
この場合、ユーザB.BからユーザA.Aへの送金が完了すると、ユーザB.Bの端末20のメッセージングアプリケーションのトークルーム画面に、限定ではなく例として、支払いアプリケーションの公式アカウントのアイコン画像(この例では「Pay」)と関連付けて、支払いアプリケーションの公式アカウント(より具体的にはサーバ10)から発信されたメッセージとして、ユーザA.Aのユーザへの送金を完了したことを示す送金完了メッセージが表示されている。この送金完了メッセージは、送金完了通知に相当するメッセージであり、限定ではなく例として、支払いアプリケーションの名称(この例では「Payment App」)とともに、支払いアプリケーションを利用してユーザB.BからユーザA.Aに対して過不足金額(この例では「2,250円」)を送金したことを示す内容が含まれる。
また、送金完了メッセージの下には、同じく支払いアプリケーションの公式アカウントから発信されたメッセージとして、割り勘完了メッセージが表示されている。
本変形例は、メッセージングアプリケーションのトークルーム画面は、端末20のユーザと、支払いサービスの公式アカウント(限定ではなく、送金処理、または受取処理に関するサービスを提供する企業のアカウントの一例)とを含む構成を示している。
このような構成により得られる効果の一例として、送金処理、または受取処理に関するサービスを提供する企業のアカウントから配信される情報を、チャットルームへの表示という分かり易い形でユーザに報知することができる。
<第5変形例(2)>
第5実施例において、限定ではなく例として、割り勘リクエストが行われた後、割り勘メンバーが割り勘の精算をしばらくの間行わなかったような場合に、割り勘マスターの端末20から、メッセージングサーバ40を介して割り勘の催促やリマインドを行うようにすることもできる。
図5−15は、図5−4においてユーザB.BがユーザA.Aに対する返信を行わずに一定時間が経過した場合にユーザB.Bの端末20の表示部24に表示される割り勘リクエストリマインド通知の一例を示す図である。
この例では、端末20のOS標準の待機画面に、限定ではなく例として、メッセージングサーバ40からのプッシュ通知であって、ユーザA.Aから割り勘リクエストのリマインドがあったことを通知するための割り勘リクエストリマインド通知として、「Messaging App A.A:割り勘のリクエストがあります」の文字とともに、メッセージングアプリケーションを起動するための、限定ではなく例として「開く」と示された起動アイコンが表示されている。
図5−16は、図5−15において起動アイコンが操作されたことに基づいてユーザB.Bの端末20の表示部24に表示されるトークルーム画面の一例を示す図である。
このトークルーム画面には、図5−4のトークルーム画面における割り勘リクエストメッセージの下に、メッセージングアプリケーションを利用して端末20間で送受信されるコンテンツの一例であって、割り勘の再確認(リマインド)をユーザに促すための割り勘リマインド通知の一種である割り勘リマインドメッセージが表示されている。
この割り勘リマインドメッセージには、限定ではなく例として、「リマインド」の文字および支払いアプリケーションの名称「Payment App」とともに、図5−4のトークルーム画面における割り勘リクエストメッセージと同様の内容が表示されている。この割り勘リマインドメッセージを確認することで、ユーザB.Bは、忘れずに割り勘の精算を行うことができる。
図5−17は、この場合におけるトークルーム画面の別例を示す図である。
このトークルーム画面は、図5−14と同様に、ユーザB.Bと支払いアプリケーションの公式アカウントとの間で行われるトークの画面の一例を示す図である。
この例では、支払いアプリケーションの公式アカウントから発信されたメッセージとして、図5−16と同様の割り勘リマインドメッセージが、公式アカウントのアイコン画像と関連付けて表示されている。
<第6実施例>
第6実施例は、メッセージングアプリケーション内で形成される複数の端末20のユーザ(複数のアカウント)を含むグループ内で割り勘を行うための実施例である。
第6実施例は、第5実施例にグループの概念が追加された実施例である。
第6実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
<表示画面例>
図6−1は、本実施例におけるメッセージングアプリケーションによるグループトークルーム画面の一例を示す図である。
このグループトークルーム画面は、限定ではなく例として、5人のユーザ(ユーザA.A〜ユーザE.E)を含むグループ(この例では「旅行サークル」のグループ)でグループトークを行うためのトークルーム画面を示しており、ユーザA.Aの端末20の表示部24に表示されるグループトークルーム画面の一例を示している。グループトークはチャットの一例であり、グループトークルームはチャットルームの一例である。
このグループトークルーム画面では、限定ではなく例として、画面向かって右側に、自分(ユーザA.A)から発信されたメッセージが表示され、画面向かって左側に、他のユーザ(ユーザB.B〜ユーザE.E)から発信されたメッセージが表示される。
この例では、ユーザA.Aから発信された、先の旅行で使った金銭の割り勘をリクエストするメッセージが表示されており、ユーザB.Bから発信されたユーザA.Aのリクエストを承認するメッセージとともに、ユーザD.Dから発信された、また旅行に行くことを提案するメッセージが表示されている。
画面下部には、メッセージングアプリケーションの複数の機能それぞれに対応する機能アイコンが表示されており、この例では、右下に表示された「割り勘アイコン」がユーザA.Aによってタッチ操作された状態が示されている。
図6−2は、図6−1のグループトークルーム画面において割り勘アイコンが操作されたことに基づいて端末20の表示部24に表示される買い物決済履歴選択画面の一例を示す図である。
この買い物決済履歴選択画面には、自分(ユーザA.A)による複数の買い物決済履歴が表示されている。この例では、「AAレンタサイクル」、「BBスーパー」、「CC弁当」等の、複数の買い物決済履歴が表示されている。
図6−3は、図6−2の買い物決済履歴選択画面において割り勘リクエストアイコンが操作されたことに基づいて端末20の表示部24に表示されるグループトークルーム画面の一例を示す図であり、ユーザB.Bの端末20の表示部24に表示される画面の一例を示している。
このグループトークルーム画面では、ユーザA.Aからの割り勘リクエストメッセージとして、支払いアプリケーションの名称(この例では「Payment App」)と、ユーザB.Bの過不足金額(この例では「900円 支払い」)と、各割り勘メンバーの割り勘の内容(割り勘の内訳)とを含むメッセージが表示されている。また、割り勘リクエストメッセージには、限定ではなく例として、精算を行うための精算アイコンと、自分の買い物決済履歴による支払い分を登録するための買い物決済履歴登録アイコンと、割り勘リクエストを断るための拒否アイコンとが含まれる。
<データ構成>
図6−4は、本実施例においてサーバ10の記憶部15に記憶される情報の一例を示す図である。
記憶部15には、限定ではなく例として、メッセージングアプリケーション管理処理プログラム451と、メッセージングアプリケーションユーザ登録データ453と、割り勘管理データベース457とに加えて、グループ管理データベース459が記憶される。
図6−5は、本実施例における割り勘管理データベース457の一例である第4の割り勘管理データベース457Bのデータ構成例を示す図である。
第4の割り勘管理データベース457Bでは、各割り勘管理データにおいて、第3の割り勘管理データベース457A(図5−9参照)の各割り勘管理データにおける割り勘メンバーIDに代えて割り勘グループIDが記憶される。
割り勘グループIDには、このグループについて、グループ管理データベース459に記憶されているグループIDが記憶される。
また、各々の割り勘管理データには、割り勘メンバーIDが記憶される。割り勘メンバーIDには、割り勘グループIDによって識別されるグループに含まれるユーザのメッセージングアプリケーションIDが記憶される。
なお、本実施例では、割り勘グループIDによって識別されるグループに含まれる全てのユーザのメッセージングアプリケーションIDが割り勘メンバーIDに含まれることとするが、これに限定されない。
限定ではなく例として、グループに含まれる全てのユーザではなく、グループに含まれる一部のユーザを割り勘メンバーとすることもできる。この場合は、グループに含まれるユーザのうち、割り勘メンバーとして選択されたユーザのメッセージングアプリケーションIDを、割り勘メンバーIDの欄に記憶させるようにすればよい。
図6−6は、グループ管理データベース459のデータ構成の一例を示す図である。
グループ管理データベース459には、グループごとに生成されるグループ管理データが記憶される。
各グループ管理データには、限定ではなく例として、グループIDと、グループ名と、グループメンバーデータとが記憶される。
グループメンバーデータには、限定ではなく例として、このグループに含まれるユーザのユーザ名と、このユーザのメッセージングアプリケーションIDとが関連付けて記憶される。
<処理>
図6−7は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。
この処理は、図5−10〜図5−12の処理のうちの図5−10の処理部分に、端末Aの処理としてA910のステップ、メッセージングサーバ40の処理としてMSG割り勘管理処理910のステップ、サーバ10の処理としてS620、S630のステップを追加した処理である。
最初に、端末Aの制御部21は、グループでの割り勘の開始を要求するためのグループ割り勘開始通知を、通信I/F22によってメッセージングサーバ40に送信する(A910)。そして、端末Aの制御部21は、A640に処理を移す。
通信I/F44によって端末Aからグループ割り勘開始通知を受信すると(M910)、メッセージングサーバ40の制御部41は、M620に処理を移す。
<第6実施例の効果>
第6実施例は、端末20は、グループトークルーム(限定ではなく、チャットルームの一例)は、割り勘マスター以外の複数の割り勘メンバーを含み、割り勘マスターの過不足金額の情報(限定ではなく、第1金額の情報の一例)と、割り勘マスター以外の各々の割り勘メンバーの過不足金額の情報(限定ではなく、第1決済情報に基づく、複数のユーザの各々が送金、または受け取る金額の情報の一例)とを含む過不足金額情報をグループトークルームに表示する構成を示している。
このような構成により得られる効果の一例として、端末のユーザが送金、または受け取る第1金額と、異なる端末のユーザを含む複数のユーザの各々が送金、または受け取る金額とを、チャットルームへの表示という分かりやすい形でユーザに報知することができる。
<第6変形例(1)>
第6実施例において、グループに含まれる複数のユーザのうちの少なくとも一人のユーザを割り勘メンバーから除外する処理を行うようにしてもよいし、そのようにしなくてもよい。
図6−8は、端末20の表示部24に表示される割り勘対象メンバーを選択(設定)するための割り勘対象メンバー選択画面の一例を示す図であり、ユーザA.Aの端末20の表示部24に表示される画面の一例を示している。
この割り勘対象メンバー選択画面では、割り勘を行うグループ(この例では「旅行サークル」のグループ)(以下、「対象グループ」と称する。)に含まれる自分以外のメンバー(ユーザB.B〜ユーザE.E)のアイコン画像およびユーザ名と関連付けて、チェックボックスが設けられている。
限定ではなく例として、初期状態では、全員のチェックボックスにチェックが入れられているが、チェックを外す操作を行うことにより、そのチェックを外したユーザを割り勘メンバーから除外することができるように構成されている。この例では、ユーザB.B、ユーザD.D、ユーザE.Eにはチェックが入れられているが、ユーザC.Cのチェックは外された状態が示されている。
また、画面下部には、割り勘対象メンバーとして現在設定されているユーザ(チェックボックスにチェックが入れられているユーザ)が表示される割り勘対象メンバー表示領域が設けられている。割り勘対象メンバー表示領域には、限定ではなく例として、割り勘対象メンバーとして現在設定されているユーザのアイコン画像およびユーザ名が表示されている。また、アイコン画像の右上には「×マーク」が表示されており、この「×マーク」を操作することで、そのユーザを割り勘対象メンバーから除外することができるように構成されている。この例では、ユーザB.B、ユーザD.D、ユーザE.Eが割り勘対象メンバーとして設定された状態が示されている。
図6−9は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。
この処理は、図6−7の処理に、端末Aの処理としてA920〜A940のステップを追加し、メッセージングサーバ40の処理としてM920、M940のステップを追加した処理である。
M910の後、メッセージングサーバ40の制御部41は、そのグループに含まれるメンバーの情報(以下、「グループメンバー情報」と称する。)を、通信I/F44によって端末Aに送信する(M920)。
通信I/F22によってメッセージングサーバ40からグループメンバー情報を受信すると(A920)、端末Aの制御部21は、第2のメンバー選択処理を実行する(A930)。具体的には、限定ではなく例として、図6−8のような割り勘メンバー選択画面を表示部24に表示させ、入出力部23に対する選択操作に基づいて、割り勘をリクエストするメンバーを選択する。
その後、端末Aの制御部21は、A930で選択したメンバーに関するメンバー選択情報を、通信I/F22によってメッセージングサーバ40に送信する(A940)。そして、端末Aの制御部21は、A640に処理を移す。
通信I/F44によって端末Aからメンバー選択情報を受信すると(M940)、制御部41は、受信されたメンバー選択情報に基づくユーザを割り勘メンバーに追加/割り勘メンバーから削除した後、M620に処理を移す。
本変形例は、一の端末20が、グループトークルーム(限定ではなく、チャットルームの一例)に含まれる、複数のユーザの中から少なくとも一人のユーザを割り勘メンバーから削除する処理を実行する構成を示している。
このような構成により得られる効果の一例として、チャットルームに含まれる、異なる端末のユーザを含む複数のユーザから、少なくとも一人のユーザを削除する処理を実行することで、限定ではなく例として、任意のユーザを割り勘の対象から除外することができる。
<第6変形例(2)>
第6実施例において、限定ではなく例として、割り勘マスターの端末20で、グループトークルームに含まれないユーザ(以下、「グループ外メンバー」と称する。)を割り勘メンバーに追加する処理を行うようにしてもよいし、そのようにしなくてもよい。
図6−10は、本変形例における割り勘対象メンバー選択画面の一例を示す図である。
この割り勘対象メンバー選択画面では、図6−8の割り勘対象メンバー選択画面とは異なり、対象グループに含まれるユーザ以外のユーザの中から割り勘メンバー候補を追加するための、限定ではなく例として「グループ以外の友だちを追加」と示された追加アイコンが設けられている。
図6−11は、図6−10の割り勘対象メンバー選択画面において追加アイコンが操作されたことに基づいて表示される画面の一例を示す図である。
この画面では、画面中央部に、友だち登録されているユーザの中から割り勘対象メンバー候補を選択・設定するための友だち一覧表示領域が設けられている。友だち一覧表示領域には、対象グループに含まれる割り勘メンバーとは異なるユーザであって、ユーザA.Aが友だち登録しているユーザのアイコン画像とユーザ名とが一覧表示されている。この例では、ユーザX.X、ユーザY.Y、ユーザZ.Z等が一覧表示されており、ユーザZ.Zのチェックが「ON」とされた状態が示されている。
また、図6−8、図6−9と同様に、画面下部には、割り勘対象メンバー表示領域が設けられている。この例では、ユーザB.B、ユーザD.D、ユーザE.Eに加えて、ユーザZ.Zが割り勘対象メンバー候補として設定された状態が示されている。
また、画面下部には「OKアイコン」が表示されており、このOKアイコンが操作されることで、現在設定されているユーザで割り勘対象メンバーを確定させることができるように構成されている。
図6−12は、図6−11の割り勘対象メンバー選択画面においてOKアイコンが操作されたことに基づいて表示される割り勘対象メンバー選択画面の一例を示す図である。
この割り勘対象メンバー選択画面では、グループメンバーとして、対象グループに含まれるユーザの一覧が表示されており、その下に、友だちとして、図6−11の画面において割り勘対象メンバーとして加えたグループ外メンバーであるユーザZ.Zのアイコン画像およびユーザ名が表示されている。この例では、対象グループに含まれるユーザのうち、ユーザB.B、ユーザD.D、ユーザE.Eの3人のチェックが「ON」とされるとともに、追加されたユーザZ.Zのチェックが「ON」とされた状態が示されている。
また、画面下部の割り勘対象メンバー表示領域には、ユーザB.B、ユーザD.D、ユーザE.Eに加えて、ユーザZ.Zが割り勘対象メンバー候補として設定された状態が示されている。
図6−13は、図6−6の割り勘対象メンバー選択画面において買い物決済履歴登録アイコンが操作されたことに基づいて表示される買い物決済履歴選択画面の一例を示す図である。
この買い物決済履歴選択画面は、図6−2の買い物決済履歴選択画面に対応しており、この例では、画面下部の割り勘リクエストアイコンがユーザA.Aによって操作された状態が示されている。
図6−14は、図6−13の買い物決済履歴選択画面において割り勘リクエストアイコンが操作されたことに基づいて端末20の表示部24に表示されるグループトークルーム画面の一例を示す図であり、ユーザZ.Zの端末20の表示部24に表示される画面の一例を示している。
このグループトークルーム画面では、図6−3と同様に、ユーザA.Aからの割り勘リクエストメッセージが表示されている。そして、この例では、割り勘リクエストメッセージに含まれる買い物決済履歴登録アイコンがユーザZ.Zによって操作された状態が示されている。
図6−15は、図6−14のグループトークルーム画面において買い物決済履歴登録アイコンが操作されたことに基づいて表示される買い物決済履歴選択画面の一例を示す図であり、ユーザZ.Zの端末20の表示部24に表示される画面の一例を示している。
この買い物決済履歴選択画面には、限定ではなく例として、ユーザZ.Zによる買い物決済履歴として、「HHスーパー」、「IIカフェ」、「JJ電器」等の、複数の買い物決済履歴が表示されている。そして、この例では、「IIカフェ」の買い物決済履歴にチェックが入れられた状態が示されている。
図6−16は、図6−15の買い物決済履歴選択画面において登録アイコンが操作されたことに基づいて表示されるグループトークルーム画面の一例を示す図であり、ユーザA.Aの端末20の表示部24に表示される画面の一例を示している。
このグループトークルーム画面には、限定ではなく例として、ユーザZ.Zに関連付けられた割り勘リクエストメッセージとして、ユーザA.Aによって登録された買い物決済履歴に基づく割り勘内容と、ユーザZ.Zによって登録された買い物決済履歴に基づく割り勘内容とを含む割り勘リクエストメッセージが表示されている。
図6−17は、端末20の表示部24に表示される割り勘メンバー選択画面の別例を示す図である。
この割り勘メンバー選択画面では、図6−10の割り勘メンバー選択画面とは異なり、対象グループに含まれるユーザ以外のユーザを割り勘メンバー候補として追加するための、限定ではなく例として「グループ以外の友だちを追加」と示された領域に、メッセージングアプリケーションにおいて友だち登録されているユーザの中から割り勘メンバー候補とするユーザを選択するための、限定ではなく例として「友だちから追加」と示された第1追加アイコンと、電話番号を入力して割り勘メンバー候補とするユーザを選択するための、限定ではなく例として「電話番号で検索」と示された第2追加アイコンとが表示されている。
図6−18は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。
この処理は、図6−9の処理に、端末Aの処理としてA950のステップを追加し、メッセージングサーバ40の処理としてM950のステップを追加した処理である。
M940の後、端末Aの制御部21は、限定ではなく例として、図6−10、図6−11のような割り勘メンバー選択画面を表示部24に表示させ、入出力部23に対する選択操作に基づいて、グループ外メンバーを選択する。そして、端末Aの制御部21は、選択したグループ外メンバーに関するグループ外メンバー選択情報を、通信I/F22によってメッセージングサーバ40に送信する(A950)。そして、端末Aの制御部21は、A640に処理を移す。
通信I/F44によって端末Aからグループ外メンバー選択情報を受信すると(M950)、制御部41は、受信されたグループ外メンバー選択情報に基づくグループ外メンバーを割り勘メンバーに追加した後、M620に処理を移す。
本変形例は、一の端末20が、グループトークルーム(限定ではなく、チャットルームの一例)に含まれないユーザを割り勘メンバーとして追加する処理を実行する。そして、端末20は、グループトークルームに追加されたユーザの過不足金額(限定ではなく、チャットルームに含まれない追加されたユーザが送金、または受け取る第3金額の一例)の情報と、一の端末20のユーザの過不足金額(限定ではなく、第1金額の一例)の情報と、グループに含まれる他の端末20のユーザの過不足金額(限定ではなく、第2金額の一例)の情報とを含む過不足金額情報をサーバ10から通信I/F22によって受信する。そして、端末20は、受信された過不足金額情報をグループトークルームに表示する構成を示している。
このような構成により得られる効果の一例として、チャットルームに含まれないユーザを追加した上で、第1金額および第2金額ばかりでなく、追加されたユーザが送金、または受け取る第3金額も考慮した金額情報を、チャットルームへの表示という分かりやすい形でユーザに報知することができる。
また、本変形例は、上記の第1金額と、第2金額と、第3金額とは、グループトークルームに含まれない追加されたユーザによる買い物決済履歴と、割り勘マスターによる買い物決済履歴とに基づいて決定される構成を示している。
このような構成により得られる効果の一例として、第1金額と、第2金額と、第3金額とが、チャットルームに含まれない追加されたユーザによる第3決済に関する処理に基づく第3決済情報と、第1決済情報とに基づいて、適切に決定されるようにすることができる。
<第6変形例(3)>
第6実施例において、ユーザによっては、他のユーザに割り勘をリクエストすることに気まずさを感じ、割り勘をリクエストすることを躊躇する場合もあると考えられる。
そこで、限定ではなく例として、グループ名に基づいて、割り勘リクエスト通知を端末20の表示部24に表示させるようにしてもよいし、そのようにしなくてもよい。
図6−19は、本変形例において端末20の表示部24の待機画面に表示される割り勘リクエスト通知の一例を示す図であり、ユーザB.Bの端末20の表示部24に表示される画面の一例を示している。
この待機画面には、限定ではなく例として、メッセージングアプリケーションと関連付けられたプッシュ通知であって、割り勘リクエストがあったことを通知するための割り勘リクエスト通知として、「Messaging App 旅行サークル 割り勘のリクエストがあります」の文字とともに、メッセージングアプリケーションを起動するための、限定ではなく例として「開く」と示された起動アイコンが表示されている。
図5−15に示した待機画面における割り勘リクエスト通知のように、割り勘マスターのユーザからの割り勘リクエストとするのではなく、割り勘マスターが割り勘をリクエストしたグループ(この例では、グループ名「旅行サークル」のグループ)からの割り勘リクエストとして表示している点が、図5−15の割り勘リクエスト通知とは異なる。
図6−20は、図6−19の待機画面において起動アイコンが操作されたことに基づいてユーザB.Bの端末20の表示部24に表示されるトークルーム画面の一例を示す図である。
このトークルーム画面には、「旅行サークル」のグループからの割り勘リクエストとして、このグループのアイコン画像およびグループ名と関連付けて、割り勘リクエストメッセージが表示されている。
本変形例は、端末20が、自己の端末20のユーザと、異なる端末20のユーザとを含み、自己の端末20から異なる端末20に送信されたメッセージと、異なる端末20から自己の端末20に送信されたメッセージとを含むグループトークルームを表示部24に表示する。そして、端末20は、異なる端末20から割り勘リクエスト通知を通信I/F22によって受信した場合、このグループトークルームのグループ名に基づき、割り勘リクエスト通知をグループトークルームに表示する構成を示している。
このような構成により得られる効果の一例として、異なる端末から、決済に関する決済情報に基づく、送金処理、または受取処理のリスクエストの通知を通信部によって受信した場合、チャットルームのグループ名に基づき、リクエストの通知をチャットルームに表示するため、異なる端末からのリクエストの通知であることを秘匿することができる。その結果、他のユーザにリクエストを行う心理的な負担を軽減することができる。
<第7実施例>
第7実施例は、異なる端末20のユーザが割り勘メンバーを追加する実施例である。
第7実施例は、上記の実施例に、異なる端末20のユーザが割り勘メンバーを追加する構成を追加した実施例である。
第7実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
<表示画面例>
図7−1は、本実施例における割り勘内容確認画面の一例を示す図であり、ユーザB.Bの端末20の表示部24に表示される画面の一例を示している。
この割り勘内容確認画面の構成は、限定ではなく例として、図3−2とほぼ同様であるが、表示が一部異なっている。具体的には、この割り勘内容確認画面には、限定ではなく例として、精算を実行させるための精算アイコンと、買い物決済履歴を追加するための買い物決済履歴追加アイコンと、割り勘メンバーを追加するための割り勘メンバー追加アイコンとが画面下部に表示されている。
図7−2は、図7−1の割り勘内容確認画面において割り勘メンバー追加アイコンが操作されたことに基づいて表示される割り勘メンバー検索画面の一例を示す図である。
この割り勘メンバー検索画面には、「電話番号を入力して検索してください」の文字とともに、入力された電話番号が表示される電話番号表示欄が設けられている。電話番号表示欄の右には、入力された電話番号のユーザを検索するための検索ボタンが設けられており、この検索ボタンが操作されたことに基づいて、入力された電話番号のユーザが検索される。この例では、検索結果として「ユーザF.F」が得られ、ユーザF.Fのアイコン画像とユーザ名とが表示された状態が示されている。
また、検索結果の下には、検索結果として得られたユーザを割り勘メンバーに追加するための、限定ではなく例として「メンバーに追加」と示された割り勘メンバー追加アイコンが表示されている。
図7−3は、図7−2の割り勘メンバー検索画面において割り勘メンバー追加アイコンが操作されたことに基づいて表示される割り勘内容確認画面の一例を示す図である。
この割り勘内容確認画面には、図7−2において検索結果として得られたユーザF.Fが割り勘メンバーとして追加された結果、自分(ユーザB.B)、ユーザA.A、ユーザC.C、ユーザD.D、ユーザE.Eに加えて、ユーザF.Fのアイコン画像およびユーザ名が関連付けられた支払い済み金額一覧表示領域および過不足金額一覧表示領域が表示されている。
<第7実施例の効果>
第7実施例は、割り勘マスターとは異なる割り勘メンバーの端末20(限定ではなく、第1端末の一例)によって、当初設定された割り勘メンバーとは異なる端末20(限定ではなく、第2端末の一例)のユーザを追加する処理が実行される。そして、この場合における過不足金額情報には、追加されたユーザの過不足金額(限定ではなく、第4金額)の情報が含まれる構成を示している。
このような構成により得られる効果の一例として、第1端末とは異なる第2端末のユーザを追加した上で、追加された第2端末のユーザが送金、または受け取る第4金額の情報を取得することができる。
<第8実施例>
第8実施例は、端末20が、自己の端末20のユーザによる複数の買い物決済履歴の中から、割り勘対象とする買い物決済履歴を自動的に選択する実施例である。
端末20のユーザによっては、割り勘対象とする買い物決済履歴を自分で検索して選択するのが面倒な場合がある。これは、買い物決済履歴の数が多い場合に顕著である。
第8実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
本実施例では、端末20の制御部21が、自己の端末20のユーザのユーザ情報に基づいて、買い物決済履歴を自動選択する。本実施例では、自己の端末20のユーザのユーザ情報を、限定ではなく例として、自己の端末20、または自己の端末20のユーザに関する位置の情報とする場合を例示する。
買い物決済履歴の自動選択とは、自動的に選択した買い物決済履歴を割り勘対象として最終決定すること(最終決定して登録すること)を含む他、自動的に選択した買い物決済履歴を割り勘対象の候補として提案(サジェストとも言う。)することも含まれる。後者の場合は、制御部21によって自動選択されて提案された買い物決済履歴の中から、ユーザが手動で買い物決済履歴を選択して最終決定することになる。
これは、後述する実施例においても同様である。
<表示画面例>
図8−1は、本実施例における買い物決済履歴選択画面の一例を示す図であり、ユーザA.Aの端末20の表示部24に表示される画面の一例を示している。
この買い物決済履歴選択画面では、割り勘対象とする買い物決済履歴を自動的に選択するための、限定ではなく例として「支払い候補を検索」と示された検索アイコンが表示されている。
図8−2は、図8−1の買い物決済履歴選択画面において検索アイコンが操作されたことに基づいて表示される表示例を示す図である。
この画面では、図8−1の買い物決済履歴選択画面における複数の買い物決済履歴のうち、「AAレンタサイクル」の買い物決済履歴と、「BBスーパー」の買い物決済履歴とが選択された状態の表示(以下、「選択表示」と称する。)として、他の買い物決済履歴(限定ではなく例として「CC弁当」の買い物決済履歴)とは異なる態様で表示されている。この選択表示された買い物決済履歴は、端末20の制御部21によって自動選択されて提案(サジェスト)された買い物決済履歴である。
なお、選択表示は、非選択の買い物決済履歴と異なる態様の表示とすることができる。
限定ではなく例として、選択された買い物決済履歴の表示領域に特定の色(青色、緑色、赤色等)やハッチング(網掛け等)を施した態様、選択された買い物決済履歴の表示領域の枠(外枠)に特定の色を施す態様、選択された買い物決済履歴の表示領域の枠(外枠)を点滅させた態様、選択された買い物決済履歴の文字のフォントを特殊なフォントで表した態様、といった複数の態様のうちのいずれかの態様を、選択表示の態様として適用することができる。
このように、少なくとも1つの買い物決済履歴が選択表示された状態で、画面下部の割り勘リクエストアイコンが操作されると、選択表示された買い物決済履歴を割り勘対象として登録することが可能となる。
<データ構成>
図8−3は、本実施例においてサーバ10の記憶部15に記憶されるユーザ管理データベース155の一例である第3のユーザ管理データベース155Cの一例を示す図である。
この第3のユーザ管理データベース155Cの各ユーザ管理データには、限定ではなく例として、支払いアプリケーションIDと、電子マネー口座残高と、買い物決済履歴データとが記憶される。
買い物決済履歴データには、限定ではなく例として、買い物決済IDと、店舗IDと、店舗名と、買い物決済日時と、買い物決済金額と、買い物決済内容と、買い物決済位置情報とが関連付けて記憶される。
買い物決済ID〜買い物決済内容は、前述した通りである。
買い物決済位置情報には、限定ではなく例として、買い物決済が行われた際の端末20、または端末20のユーザの位置情報が記憶される。
なお、買い物決済位置情報には、2次元の位置情報を記憶させるようにしてもよいし、3次元の位置情報を記憶させるようにしてもよい。
この場合、1つの手法として、定期的なタイミングや、端末20に決済を行う操作がなされたタイミングで、端末20からサーバ10に対して、算出端末位置の情報を送信するようにすることができる。そして、サーバ10は、買い物決済処理において、端末20から受信した最新の算出端末位置の情報を買い物決済位置情報として、他の情報と関連付けてユーザ管理データに記憶させるようにすることができる。
なお、ユーザが忘れずに端末20を所持しているのであれば、端末20の位置は、その端末20のユーザの位置と同じとなる。このため、算出端末位置は、算出された端末20の位置であるとともに、算出された端末20のユーザの位置とも言える。
本実施例では、限定ではなく例として、端末20のユーザによる登録操作に従って、端末20のユーザの居住地(またはその周辺エリア)、端末20のユーザの勤務地(またはその周辺エリア)、端末20のユーザの親族や友人の居住地(またはその周辺エリア)、端末20のユーザが頻繁に訪れる場所等の、端末20のユーザの日常の生活範囲や活動範囲として想定される位置情報を、特定位置情報としてあらかじめ支払いアプリケーション等において登録しておくこととする。
なお、特定位置情報は、サーバ10の記憶部15に記憶されて管理されるようにしてもよいし、端末20の記憶部28に記憶されて管理されるようにしてもよい。または、サーバ10と端末20との両方に記憶されて管理されるようにしてもよい。
<処理>
図8−4は、本実施例において各々の装置が実行する処理の流れの一例を示す図である。
この処理は、図2−17〜図2−19の処理のうちの図2−17の処理部分について、端末Aの処理として、A170のステップをA175のステップに置き換えた処理である。
S150の後、サーバ10の制御部11は、端末Aのユーザに関連付けられた複数の買い物決済履歴(買い物決済位置情報を含む。)を、通信I/F14によって端末20に送信する(S160)。
通信I/F22によってサーバ10から買い物決済履歴(買い物決済位置情報を含む。)を受信すると(A160)、端末Aの制御部21は、買い物決済履歴自動選択処理を実行する(A175)。具体的には、限定ではなく例として、複数の買い物決済履歴のうち、その買い物決済位置が、あらかじめ登録された特定位置情報に対応する特定位置から設定距離以上(または設定距離超)、距離が離れている買い物決済履歴を特定する。そして、特定した買い物決済履歴を、割り勘対象とする買い物決済履歴として選択する。
このようにして買い物決済履歴を自動選択したならば、端末Aの制御部21は、限定ではなく例として、自動選択した買い物決済履歴を割り勘対象の候補としてピックアップ表示するなどして、端末20のユーザに提案(サジェスト)する。そして、端末Aの制御部21は、A180に処理を移す。
このようにすることで、端末20のユーザの日常の生活範囲や活動範囲として登録された位置から大きく離れた位置で行われた買い物決済に対応する買い物決済履歴を自動選択することができる。
なお、選択した買い物決済履歴を端末20のユーザに提案する処理は必須ではなく、この処理は省略してもよい。
また、ここでは、端末20の制御部21が、図2−17の処理における第2の買い物決済履歴選択処理に代えて、買い物決済履歴自動選択処理を実行する場合を例示したが、これに限定されない。限定ではなく例として、端末20の制御部21が、図1の処理における第1の買い物決済履歴選択処理に代えて、買い物決済履歴自動選択処理を実行するようにしてもよいし、そのようにしなくてもよい。
<第8実施例の効果>
第8実施例は、端末20が、自己の端末20のユーザによる複数の買い物決済履歴(限定ではなく、複数の決済情報の一例)のうち、自動選択した買い物決済履歴(限定ではなく、第1決済情報の一例)を通信I/F22(限定ではなく、端末の通信部の一例)によってサーバ10に送信する。また、端末20は、送信された買い物決済履歴に基づく過不足金額(限定ではなく、第1決済情報に基づく、端末のユーザが送金、または受け取る第1金額と、端末とは異なる端末のユーザが送金、または受け取る第2金額とのうち、少なくとも第1金額の一例)の情報を通信I/F22によってサーバ10から受信する。そして、端末20は、過不足金額に基づき、割り勘精算要求処理や割り勘精算結果受信処理(限定ではなく、第1金額に基づく送金処理、または受取処理の一例)を制御部21(限定ではなく、端末の制御部の一例)によって実行する構成を示している。
このような構成により得られる効果の一例として、端末は、端末のユーザによる決済に関する複数の決済情報のうち、第1決済情報を通信部によって送信したことに基づいて、その第1決済情報に基づく第1金額の情報に基づく送金処理、または受取処理を制御部によって実行して、金銭を簡単に送金する、または受け取ることが可能となり、ユーザの利便性を向上させることができる。
また、第8実施例は、端末20は、メモリに記憶されたプログラムを読み出し、このプログラムに基づく処理を実行するプロセッサを備える。プロセッサは、自己の端末20のユーザによる複数の買い物決済履歴(限定ではなく、複数の決済情報の一例)のうち、自動選択した買い物決済履歴(限定ではなく、第1決済情報の一例)を通信I/F22(限定ではなく、端末の通信部の一例)によってサーバ10に送信することと、送信された買い物決済履歴に基づく過不足金額(限定ではなく、第1決済情報に基づく、端末のユーザが送金、または受け取る第1金額と、端末とは異なる端末のユーザが送金、または受け取る第2金額とのうち、少なくとも第1金額の一例)の情報を通信I/F22によってサーバ10から受信することと、過不足金額に基づき、割り勘精算要求処理や割り勘精算結果受信処理(限定ではなく、第1金額に基づく送金処理、または受取処理の一例)とを実行する構成を示している。
このような構成によっても、上記と同様の効果を得ることができる。
また、第8実施例は、端末20は、買い物決済履歴を、端末20のユーザのユーザ情報に基づいて選択する構成を示している。
このような構成により得られる効果の一例として、端末は、端末のユーザに則した第1決済情報を選択することができる。
また、第8実施例は、上記のユーザ情報は、算出端末位置(限定ではなく、端末、または端末のユーザに関する位置の一例)の情報を含む構成を示している。
このような構成により得られる効果の一例として、端末は、端末、または端末のユーザに関する位置を考慮して、第1決済情報を適切に選択することができる。
<第8変形例(1)>
第8実施例で説明した買い物決済履歴自動選択処理における買い物決済履歴の選択方法はあくまでも一例であり、これに限定されない。
限定ではなく例として、端末20のユーザの居住地等がある都道府県や市町村をあらかじめ登録しておくようにし、登録された都道府県とは異なる都道府県で決済された買い物決済履歴を選択したり、登録された市町村とは異なる市町村で決済された買い物決済履歴を選択するようにしてもよいし、そのようにしなくてもよい。
また、あらかじめ有名な観光地の位置情報を地図データと関連付けて記憶部28に記憶しておく。そして、制御部21は、記憶部28に記憶されている観光地に対応する位置で決済された買い物決済履歴を選択するようにしてもよいし、そのようにしなくてもよい。
<第8変形例(2)>
第8実施例では、自己の端末20のユーザ情報を位置に関する情報として説明したが、これに限定されない。
限定ではなく例として、端末20のユーザのスケジュール情報をユーザ情報に含めるようにし、端末20の制御部21が、端末20のユーザのスケジュール情報に基づいて買い物決済履歴を選択するようにしてもよいし、そのようにしなくてもよい。
図8−5は、本変形例における買い物決済履歴選択画面の一例を示す図であり、ユーザA.Aの端末20の表示部24に表示される画面の一例を示している。
この買い物決済履歴選択画面では、買い物決済履歴検索アイコンが操作されたことに基づいて、「“Payment App”がカレンダーへのアクセスを求めています アクセスを許可すると、カレンダーから候補日を検索することができます。」の文字とともに、「許可しない」のボタンと、「OK」のボタンとが、画面中央部にポップアップ形式で表示されている。
この場合、「OK」のボタンが操作されると、限定ではなく例として、端末20のOS標準の機能として備えられたカレンダー機能によって登録されたユーザのスケジュール情報が、制御部21によって参照される。そして、制御部21によって、参照されたスケジュール情報に含まれるイベント情報に基づいて、買い物決済履歴が選択される。
なお、端末20のOS標準のカレンダー機能によって登録されたユーザのスケジュール情報に代えて、またはこれに加えて、支払いアプリケーションやメッセージングアプリケーションのカレンダー機能によって登録されたユーザのスケジュール情報を参照するようにしてもよいし、そのようにしなくてもよい。
カレンダー機能によって登録されたユーザのスケジュール情報には、限定ではなく例として、端末20のユーザによって入力されたイベント情報を含めることができる。
1つの手法として、制御部21は、ユーザのスケジュール情報の中から、旅行、バーベキュー、飲み会といった、複数のユーザの参加が想定されるイベント情報を特定する。そして、複数の買い物決済履歴の中から、特定したイベント情報に関連付けられた日時(イベントの開催日時)に近い日付(限定ではなく例として、過去1週間以内の日付)に決済された買い物決済履歴を選択する。
また、他の手法として、制御部21は、ユーザのスケジュール情報の中から、旅行、バーベキュー、飲み会といった、複数のユーザの参加が想定されるイベント情報を特定する。そして、複数の買い物決済履歴の中から、特定したイベント情報に関連する商品が購入された買い物決済履歴を選択する。限定ではなく例として、「バーベキュー」のイベントを特定した場合、バーベキューに関連する商品を買い物決済内容に含む買い物決済履歴を選択する。
この場合、制御部21は、限定ではなく例として、炭や着火剤、軍手といった着火に必要な商品を買い物決済内容に含む買い物決済履歴、包丁、ナイフ、まな板といった調理に必要な商品を買い物決済内容に含む買い物決済履歴、肉(牛肉、豚肉、鶏肉等)、野菜、魚介類、調味料といった食材となる商品を買い物決済内容に含む買い物決済履歴、等の買い物決済履歴を、手動選択買い物決済履歴と関連する買い物決済履歴として選択する。
また、これらを組み合わせて、制御部21が、特定したイベント情報の開催日時に近い日付(限定ではなく例として、過去1週間以内の日付)に決済された買い物決済履歴であり、かつ、特定したイベント情報に関連する商品を買い物決済内容に含む買い物決済履歴を選択するようにしてもよいし、そのようにしなくてもよい。
また、上記の他にも、限定ではなく例として、端末20のユーザがメッセージングアプリケーション等を利用して送信したメッセージに関する情報をユーザ情報に含めるようにし、端末20の制御部21が、このメッセージに関する情報に基づいて買い物決済履歴を選択するようにしてもよいし、そのようにしなくてもよい。
図8−6は、本変形例における買い物決済履歴選択画面の一例を示す図であり、ユーザA.Aの端末20の表示部24に表示される画面の一例を示している。
この買い物決済履歴選択画面では、買い物決済履歴検索アイコンが操作されたことに基づいて、「チャット履歴から支払い候補を検索しますか? 以前のチャット履歴から支払い候補の提案をおこないます。」の文字とともに、「検索する」のボタンと、「今はしない」のボタンとが、画面中央部にポップアップ形式で表示されている。
この場合、「検索する」のボタンが操作されると、限定ではなく例として、メッセージングアプリケーションのトークルームのメッセージの履歴が、制御部21によって参照される。そして、制御部21によって、参照されたメッセージの内容に基づいて、買い物決済履歴が選択される。
1つの手法として、制御部21は、限定ではなく例として、端末20のユーザが送信した過去のメッセージの中から、限定ではなく例として、割り勘を提案する内容のメッセージや、割り勘を示唆する内容のメッセージを検索する。限定ではなく例として、制御部21は、相手に割り勘を求めるメッセージ(限定ではなく例として「割り勘をしませんか」、「割り勘をお願いします」等のメッセージ)を検索する。そして、その検索結果として得られたメッセージ中に、またはそのメッセージとは別のメッセージ中に、割り勘対象とする買い物決済履歴を推定可能な情報があるか否かを判定する。限定ではなく例として、日付や日時の情報が含まれるのであれば、その日付や日時に対応する買い物決済日時が含まれる買い物決済履歴を、提案する買い物決済履歴として選択することができる。
また、他の手法として、制御部21は、メッセージングアプリケーション内で形成されたグループの中から、そのグループ名に、割り勘を示唆する名称が付けられたグループを特定する。限定ではなく例として、「割り勘」、「わりかん」、「精算」、「せいさん」、「決済」、「けっさい」、「支払い」、「しはらい」、「送金」、「そうきん」等の用語をグループ名に含むグループを特定する。そして、特定したグループについて、そのグループトークルームに含まれるメッセージの内容に基づいて、上記と同様にして、提案する買い物決済履歴として選択する。
本変形例は、ユーザ情報は、端末20のユーザのスケジュール情報を含み、買い物決済履歴は、スケジュール情報に含まれるイベント情報に基づいて選択される構成を示している。
このような構成により得られる効果の一例として、端末は、端末のユーザのスケジュール情報に含まれるイベント情報に基づき、端末のユーザが参加したイベントを考慮して、第1決済情報を適切に選択することができる。
また、本変形例は、ユーザ情報は、端末20のユーザから発信されたメッセージに関する情報を含み、買い物決済履歴は、このメッセージに関する情報に基づいて選択される構成を示している。
このような構成により得られる効果の一例として、端末は、端末のユーザに基づいて送信されたメッセージに関する情報に基づいて、第1決済情報を適切に選択することができる。
なお、上記の他にも、限定ではなく例として、自己の端末20のユーザの性別、年齢、職業等の属性情報をユーザ情報に含めるようにし、端末20の制御部21が、これらの属性情報に基づいて、買い物決済履歴を選択するようにしてもよいし、そのようにしなくてもよい。
具体的には、限定ではなく例として、自己の端末20のユーザの性別、年齢、職業等の属性情報のうちの少なくとも1つの情報に基づいて、自己の端末20のユーザの参加が想定されるイベントを推定する。そして、その推定結果に基づいて、自己の端末20のユーザの買い物決済履歴の中から、推定したイベントに関連する買い物決済履歴を選択する。
<第8変形例(3)>
第8実施例では、端末20の制御部21が買い物決済履歴自動選択処理を実行することとしたが、これに限定されない。
各々の端末20のユーザの買い物決済履歴のデータは、サーバ10の記憶部15に記憶・管理されている。このため、端末20の制御部21に代えて、サーバ10の制御部11が買い物決済履歴自動選択処理を実行するようにしてもよいし、そのようにしなくてもよい。
これは、以下説明する実施例においても同様である。
図8−7は、本変形例において各装置が実行する処理の流れの一例を示すフローチャートである。
この処理は、図2−17〜図2−19の処理のうちの図2−17の処理部分について、端末Aの処理として、A150のステップをA151のステップに置き換え、A160のステップをA163のステップに置き換え、A170のステップを削除した処理である。また、サーバ10の処理として、S150のステップをS151のステップに置き換え、S161のステップを追加し、S160のステップをS163のステップに置き換えた処理である。
A130の後、端末Aの制御部21は、限定ではなく例として、買い物決済履歴の選択を要求する買い物決済履歴選択要求情報を、通信I/F22によってサーバ10に送信する(A151)。
通信I/F14によって端末Aから買い物決済履歴選択要求情報を受信すると(S151)、サーバ10の制御部11は、買い物決済履歴自動選択処理を実行する(S161)。
この処理における買い物決済履歴の選択方法としては、前述した端末20の制御部21による選択方法と同様の方法を適用することが可能である。
その後、制御部11は、買い物決済履歴の選択結果を含む買い物決済履歴自動選択情報を、通信I/F14によって端末Aに送信する(S163)。
通信I/F22によってサーバ10から買い物決済履歴自動選択情報を受信したならば(A163)、端末Aの制御部21は、限定ではなく例として、サーバ10によって選択された買い物決済履歴を割り勘対象の候補としてピックアップ表示するなどして、端末20のユーザに提案(サジェスト)する。そして、端末Aの制御部21は、A180に処理を移す。
なお、サーバ10によって選択された買い物決済履歴を端末20のユーザに提案する処理は必須ではなく、この処理は省略してもよい。
本変形例によれば、サーバ10が、端末20のユーザによる決済に関する複数の買い物決済履歴のうち、一の買い物決済履歴を選択する処理を制御部11によって実行する。サーバ10は、選択した位置の買い物決済履歴に基づく、少なくとも一の端末20のユーザの過不足金額(限定ではなく、第1金額)の情報を一の端末20に送信し、少なくとも他の端末20のユーザの過不足金額(限定ではなく、第2金額)の情報を他の端末20に通信I/F14によって送信する。そして、サーバ10は、割り勘精算処理(限定ではなく、第1金額に基づく、端末に対する送金処理、または受取処理と、第2金額に基づく、異なる端末に対する送金処理、または受取処理との一例)を制御部11によって実行する構成を示している。
このような構成により得られる効果の一例として、サーバによって、端末のユーザによる決済に関する複数の決済情報のうち、第1決済情報を選択する処理が実行され、その結果に基づいて、第1金額に基づく、端末に対する送金処理、または受取処理と、第2金額に基づく、異なる端末に対する送金処理、または受取処理とがサーバの制御部によって実行されるため、端末の処理負荷を軽減しつつ、端末に対する金額の送金、または受取と、異なる端末に対する送金、または受取とを実現することができ、ユーザの利便性を向上させることができる。
<第9実施例>
第9実施例は、第8実施例と同様に、端末20が、自己の端末20のユーザによる複数の買い物決済履歴の中から、割り勘対象とする買い物決済履歴を自動的に選択する実施例である。
第9実施例は、第8実施例とは異なり、端末20が、自己の端末20のユーザによる買い物決済履歴に関連する情報に基づいて買い物決済履歴を選択する点が異なる。
第9実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
本実施例において、端末20の制御部21は、買い物決済履歴に関連する情報に基づいて、買い物決済履歴を自動的に選択する。
この買い物決済履歴に関連する情報には、限定ではなく例として、端末20のユーザによって手動で選択された買い物決済履歴(以下、「手動選択買い物決済履歴」と称する。)とは異なる買い物決済履歴の日付、時刻、日時等の時間に関する情報が含まれる。
具体的には、制御部21は、限定ではなく例として、手動選択買い物決済履歴と決済された日付が同じである買い物決済履歴を特定する。そして、特定した買い物決済履歴を、提案する買い物決済履歴として選択する。これは、手動選択買い物決済履歴と決済された日付が同じである買い物決済履歴も、手動選択買い物決済履歴と同様に、割り勘の対象とされる可能性が高いと考えられるためである。
<表示画面例>
図9−1は、本実施例における買い物決済履歴選択画面の一例を示す図である、ユーザA.Aの端末20の表示部24に表示される画面の一例を示している。
この買い物決済履歴選択画面では、「AAレンタサイクル」、「BBスーパー」、「CC弁当」等の複数の買い物決済履歴のうち、ユーザA.Aの操作に従って、「BBスーパー」の買い物決済履歴のチェックが「ON」とされた状態が示されている。
図9−2は、図9−1の買い物決済履歴選択画面において検索アイコンが操作されたことに基づいて表示される画面の一例を示す図である。
この買い物決済履歴選択画面では、図9−1でチェックが「ON」とされた「BBスーパー」の買い物決済履歴と同じ日付に決済が行われた買い物決済履歴である「AAレンタサイクル」が、他の買い物決済履歴とは異なる態様で表示されている。
なお、上記とは異なり、限定ではなく例として、制御部21が、手動選択買い物決済履歴と決済された曜日が同じである買い物決済履歴を選択するようにしてもよいし、そのようにしなくてもよい。
また、限定ではなく例として、制御部21が、手動選択買い物決済履歴と決済された時刻や時間帯が同じである買い物決済履歴を選択するようにしてもよいし、そのようにしなくてもよい。
<第9実施例の効果>
第9実施例は、端末20が、買い物決済履歴に関連する情報に基づいて、割り勘対象とする買い物決済履歴を選択する構成を示している。
このような構成により得られる効果の一例として、端末は、決済情報に関連する情報に基づいて、第1決済情報を適切に選択することができる。
また、第9実施例は、上記の買い物決済履歴に関連する情報は、手動選択買い物決済履歴とは異なる買い物決済履歴の日付、または時刻に関する情報を含む構成を示している。
このような構成により得られる効果の一例として、端末は、第1決済情報とは異なる第2決済情報の日付、または時刻に関する情報に基づいて、第1決済情報を適切に選択することができる。
<第9変形例(1)>
第9実施例において、端末20の制御部21が、手動選択買い物決済履歴とは異なる買い物決済履歴に含まれる商品情報やサービス情報に基づいて、買い物決済履歴を選択するようにしてもよいし、そのようにしなくてもよい。
具体的には、制御部21は、限定ではなく例として、手動選択買い物決済履歴の買い物決済内容に基づいて、購入された商品や提供されたサービスを特定する。そして、特定した商品やサービスの内容に基づき、その手動選択買い物決済履歴に対応する買い物決済に関連するイベント(その買い物決済を行う必要が生じたイベント)を推定する。そして、制御部21は、推定したイベントと、他の買い物決済履歴の買い物決済内容とに基づいて、買い物決済履歴を選択する。
限定ではなく例として、手動選択買い物決済履歴の買い物決済内容にグリル・コンロや鉄板・プレート・網、トング等の機材の商品が含まれる場合は、制御部21は、これらの商品の内容に基づいて、その決済を行う必要が生じたイベントを「バーベキュー」と推定する。そして、その推定結果に基づいて、限定ではなく例として、その手動選択買い物決済履歴と決済が行われた日付が近い買い物決済履歴のうち、バーベキューに関連する商品を買い物決済内容に含む買い物決済履歴を選択する。
この場合、制御部21は、限定ではなく例として、炭や着火剤、軍手といった着火に必要な商品を買い物決済内容に含む買い物決済履歴、包丁、ナイフ、まな板といった調理に必要な商品を買い物決済内容に含む買い物決済履歴、肉(牛肉、豚肉、鶏肉等)、野菜、魚介類、調味料といった食材となる商品を買い物決済内容に含む買い物決済履歴、等の買い物決済履歴を、手動選択買い物決済履歴と関連する買い物決済履歴として選択する。
また、第9実施例において、端末20の制御部21が、手動選択買い物決済履歴とは異なる買い物決済履歴に含まれる店舗情報に基づいて、買い物決済履歴を選択するようにしてもよいし、そのようにしなくてもよい。
具体的には、制御部21は、限定ではなく例として、手動選択買い物決済履歴に含まれる店舗名に基づいて、その手動選択買い物決済履歴に対応する買い物決済履歴に関連するイベント(その買い物決済を行う必要が生じたイベント)を推定する。そして、推定したイベントと、他の買い物決済履歴に含まれる店舗名とに基づいて、買い物決済履歴を選択する。
限定ではなく例として、手動選択買い物決済履歴に含まれる店舗名が、観光地に存在する店舗の名称(限定ではなく例として、「お土産屋」の店舗名)である場合、制御部21は、その店舗名に基づいて、その決済を行う必要が生じたイベントを「旅行」と推定する。そして、その推定結果に基づいて、限定ではなく例として、その手動選択買い物決済履歴と決済が行われた日付が近い買い物決済履歴のうち、旅行に関連する商品やサービスを取り扱う店舗の店舗名を含む買い物決済履歴を選択する。
本変形例は、端末20が、手動選択買い物決済履歴とは異なる買い物決済履歴に含まれる商品情報に基づいて、割り勘対象とする買い物決済履歴を選択する構成を示している。
このような構成により得られる効果の一例として、端末は、第1決済情報とは異なる第2決済情報に含まれる商品情報に基づいて、第1決済情報を適切に選択することができる。
また、本変形例は、端末20が、手動選択買い物決済履歴とは異なる買い物決済履歴に含まれる店舗情報に基づいて、割り勘対象とする買い物決済履歴を選択する構成を示している。
このような構成により得られる効果の一例として、端末は、第1決済情報とは異なる第2決済情報に含まれる店舗情報に基づいて、第1決済情報を適切に選択することができる。
<第9変形例(2)>
第9実施例において、第8変形例(3)と同様に、端末20の制御部21が買い物決済履歴自動選択処理を実行するようにするのではなく、サーバ10の制御部11が買い物決済履歴自動選択処理を実行するようにしてもよいし、そのようにしなくてもよい。
<第10実施例>
第10実施例は、第8実施例や第9実施例と同様に、端末20が、自己の端末20のユーザによる複数の買い物決済履歴の中から、割り勘対象とする買い物決済履歴を自動的に選択する実施例である。
第10実施例は、第8実施例、第9実施例とは異なり、端末20が、自己の端末20とは異なる端末20のユーザの情報に基づいて、買い物決済履歴を選択する。
第10実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
本実施例において、端末20の制御部21は、自己の端末20のユーザによって割り勘メンバーとして選択されたユーザの情報(他の割り勘メンバーの情報)に基づいて、買い物決済履歴を選択する。
この場合における他の割り勘メンバーの情報には、限定ではなく例として、他の割り勘メンバーのユーザにより決済された買い物決済履歴の情報を含めることができる。
本実施例では、制御部21が、他の割り勘メンバーにより決済された買い物決済履歴の情報に基づいて、自己の端末20の買い物決済履歴を選択する場合を例示する。
図10は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。
この処理は、図8−4の処理において、端末Aの処理におけるA150のステップをA153のステップに置き換え、A160のステップをA165のステップに置き換え、サーバ10の処理におけるS150のステップをS153のステップに置き換え、S160のステップをS165のステップに置き換えた処理である。
A140の後、端末Aの制御部21は、第2の買い物決済履歴要求情報を通信I/F22によってサーバ10に送信する(A153)。具体的には、限定ではなく例として、自己の端末20のユーザの買い物決済履歴と、A130で選択した割り勘メンバーの買い物決済履歴とをサーバ10に要求する処理を実行する。
通信I/F14によって端末Aから第2の買い物決済履歴要求情報を受信すると(S153)、サーバ10の制御部11は、受信された買い物決済履歴要求情報の送信元の端末20のユーザの買い物決済履歴と、端末Aによって選択された割り勘メンバーの買い物決済履歴とをユーザ管理データベース155から読み出して、第2の買い物決済履歴として通信I/F14によって端末Aに送信する(S165)。
通信I/F22によってサーバ10から第2の買い物決済履歴を受信すると(A165)、端末Aの制御部21は、A175へと処理を移す。
この場合、A175の買い物決済履歴自動選択処理では、端末Aの制御部21は、自己の端末20のユーザの買い物決済履歴の買い物決済日時と、選択された割り勘メンバーの買い物決済履歴の買い物決済日時とを参照し、限定ではなく例として、同時期に行われた買い物決済履歴を選択する。これは、同時期に買い物決済が行われた場合、自己の端末20のユーザと選択された割り勘メンバーとが行動を共にしていた可能性があるためである。
なお、これに限らず、自己の端末20のユーザの買い物決済履歴と、選択された割り勘メンバーの買い物決済履歴とで、限定ではなく例として、同じ種類の商品やサービス、相互に関連する商品やサービスが買い物決済内容に含まれる買い物決済履歴を選択するようにしてもよい。
第10実施例は、端末20が、自己の端末20のユーザとは異なる端末20のユーザの情報に基づいて、割り勘対象とする買い物決済履歴を選択する構成を示している。
このような構成により得られる効果の一例として、端末は、異なる端末のユーザの情報に基づいて、第1決済情報を適切に選択することができる。
また、第10実施例は、端末20が、自己の端末20のユーザとは異なる端末20のユーザによる買い物決済履歴(限定ではなく、第3決済情報の一例)に基づいて、割り勘対象とする買い物決済履歴を選択する構成を示している。
このような構成により得られる効果の一例として、端末は、異なる端末のユーザによる決済に関する第3決済情報に基づいて、第1決済情報を適切に選択することができる。
<第10変形例(1)>
第10実施例において、端末20の制御部21が、自己の端末20のユーザによる複数の買い物決済履歴のうち、それらの複数の買い物決済履歴の各々に関連付けられた、自己の端末20のユーザによって入力された情報に基づいて、割り勘対象とする買い物決済履歴を選択するようにしてもよいし、そのようにしなくてもよい。
具体的には、端末20の制御部21は、複数の買い物決済履歴のそれぞれについて、入出力部23に対する操作に従って、メモやタグを設定する。メモは、その買い物決済履歴がどのような買い物の決済履歴であるかをユーザが後で確認できるようにするためのものであり、限定ではなく例として、決済で購入した商品の用途等をメモとして入力・設定しておくようにすることができる。
また、タグは、買い物決済履歴を種類や目的ごとに分類するためのもの(情報を分類するための札、ラベル)である。
タグとしては、限定ではなく例として、「買い物」、「仕事」、「デート」、「旅行」、「贈り物」、「その他」といった複数の種類を用意しておくことができ、端末20のユーザが、各々の買い物決済履歴について、その種類や目的に応じたタグを選択・設定しておくようにすることができる。
この場合、制御部21は、複数の買い物決済履歴の各々に関連付けられたメモの内容を参照し、割り勘が発生し得るイベントに関連する内容を直接的に示すメモ、または示唆するメモが関連付けられた買い物決済履歴を特定して選択する。
また、制御部21は、限定ではなく例として、複数の買い物決済履歴の各々に関連付けられたタグを参照し、割り勘が発生し得るイベントに関連するタグ、限定ではなく例として、買い物、旅行等のタグが関連付けられた買い物決済履歴を特定して選択する。
なお、メモやタグについては、後述する実施例でより詳細に説明する。
<第10変形例(2)>
他の割り勘メンバーのユーザの情報には、限定ではなく例として、端末20のユーザのユーザ情報と同様に、他の割り勘メンバーのユーザの性別、年齢、職業等の属性情報を含めるようにすることができる。そして、これらの割り勘メンバーの属性情報に基づいて、買い物決済履歴を自動選択するようにしてもよいし、そのようにしなくてもよい。
具体的には、限定ではなく例として、他の割り勘メンバーの性別、年齢、職業等の属性情報のうちの少なくとも1つの情報に基づいて、他の割り勘メンバーの参加が想定されるイベントを推定する。そして、その推定結果に基づいて、自己の端末20のユーザの買い物決済履歴の中から、推定したイベントに関連する買い物決済履歴を選択する。
<第10変形例(3)>
第10実施例において、第8変形例(3)と同様に、端末20の制御部21が買い物決済履歴自動選択処理を実行するようにするのではなく、サーバ10の制御部11が買い物決済履歴自動選択処理を実行するようにしてもよいし、そのようにしなくてもよい。
また、この場合、サーバ10の制御部11は、限定ではなく例として、端末20の位置情報と、この端末20のユーザによって割り勘メンバーとして選択されたユーザの端末20の位置情報とを参照する。そして、端末20のユーザと他の割り勘メンバーとで、相互に近い位置で決済が行われた買い物決済履歴を検索し、その検索結果として得られた買い物決済履歴を選択するなどすることができる。
<第11実施例>
第11実施例は、端末20が、自己の端末20以外の割り勘メンバーを自動的に選択する実施例である。
端末20のユーザによっては、割り勘メンバーを自分で調べて選択するのは面倒な場合がある。これは、割り勘を希望するユーザの数が多い場合に顕著である。
第11実施例は、第8実施例〜第10実施例とは、端末20が選択する対象が買い物決済履歴ではなく割り勘メンバーである。
第11実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
本実施例では、端末20の制御部21は、限定ではなく例として、サーバ10を介さない、端末20同士の通知(いわゆるピアツーピア方式による通信)を行って、自己の端末20の近くに位置する端末20を検索する。そして、検索結果として得られた端末20のユーザを、割り勘メンバー候補として選択する。
<表示画面例>
図11−1は、本実施例における割り勘メンバー選択画面の一例を示す図であり、ユーザA.Aの端末20の表示部24に表示される画面の一例を示している。
この割り勘メンバー選択画面では、未だ割り勘メンバーは選択されておらず、割り勘メンバーが1人もいない状態である。
画面下部には、割り勘メンバーを電話番号で検索するための、限定ではなく例として「電話番号で検索」と示された第1検索アイコンと、割り勘メンバーを位置情報に基づいて検索するための、限定ではなく例として「ちかくの人を検索」と示された第2検索アイコンとが表示されている。
図11−2は、図11−1の割り勘メンバー選択画面において第2検索アイコンが操作されたことに基づいて表示される画面の一例を示す図である。
第2検索アイコンが表示されたことに基づいて、限定ではなく例として、自己の端末20が近くに位置する端末20との通信(ピアツーピア通信)を試行し、通信に成功した端末20から取得した情報に基づいて、その端末20のユーザを割り勘メンバー候補として提案(サジェスト)する。この例では、近くにいる人(ユーザ)として、ユーザB.B、ユーザB.C、ユーザD.D、ユーザE.Eの4人が検索結果として得られ、限定ではなく例として、色が付された状態で表示されている。
また、検索結果として得られた各々のユーザには、そのアイコン画像およびユーザ名と関連付けて、チェックボックスが設けられている。自己の端末20のユーザは、チェックボックスのチェックを「OFF」とすることで、そのユーザを割り勘メンバーから除外することができる。この例では、ユーザB.Cに関連付けられたチェックボックスのチェックが「OFF」とされ、ユーザB.Cが割り勘メンバーから除外された状態が示されている。
<第11実施例の効果>
第11実施例は、割り勘マスター以外の割り勘メンバー候補(限定ではなく、異なる端末のユーザの一例)は、割り勘マスターの端末20の位置情報と、異なる端末20の位置情報とに基づいて選択される構成を示している。
このような構成により得られる効果の一例として、異なる端末のユーザを、端末の位置情報と、異なる端末の位置情報とに基づいて簡単に選択することができる。
<第11変形例(1)>
第11実施例において、割り勘メンバー候補とするユーザの検索を、端末20ではなくサーバ10が実行するようにしてもよいし、そのようにしなくてもよい。
具体的には、限定ではなく例として、端末20において割り勘メンバーの検索操作がなされたことを検知した場合、端末20の制御部21は、通信I/F22によってユーザ検索要求をサーバ10に送信する。
端末20からユーザ検索要求を受信すると、サーバ10の制御部11は、限定ではなく例として、ユーザ検索要求の送信元の端末20の最新の算出端末位置と、データベースで記憶・管理している各々の端末20の最新の算出端末位置とに基づいて、ユーザ検索要求の送信元の端末20の最新の算出端末位置との間の距離が設定距離以下(または設定距離未満)である端末20を検索する。設定距離は、限定ではなく例として「10メートル」程度の距離とすることができる。そして、検索結果として得られた端末20のユーザを、割り勘メンバー候補として提案(サジェスト)する。
なお、この場合に、支払いアプリケーションを利用する全ての端末20を対象として割り勘メンバー候補を検索しようとすると、サーバ10の処理量が増大するという問題がある。そこで、サーバ10が、検索範囲を設定して割り勘メンバー候補を検索するようにすることもできる。
この場合、端末20のユーザがメッセージングアプリケーションを登録しているのであれば、サーバ10は、メッセージングサーバ40と通信を行い、ユーザ検索要求の送信元の端末20のユーザが友だち登録しているユーザの情報を取得する。そして、取得されたユーザの情報に基づき、ユーザ検索要求の送信元の端末20のユーザが友だち登録しているユーザを検索対象として、前述したように端末20の位置情報に基づいて、割り勘メンバー候補とするユーザを検索する。
<第11変形例(2)>
第11変形例(1)において、サーバ10が、限定ではなく例として、端末20のユーザによって入力された日付の情報と、入力された日付の自己の端末20の位置情報と、入力された日付の異なる端末20の位置情報とに基づいて、割り勘メンバー候補とするユーザを検索するようにしてもよいし、そのようにしなくてもよい。
具体的には、限定ではなく例として、端末20の制御部21は、割り勘メンバーを検索する際に、日付を入力するようにユーザに促す。そして、制御部21は、入力された日付の情報を含むユーザ検索要求を、通信I/F22によってサーバ10に送信する。
端末20からユーザ検索要求を受信すると、サーバ10の制御部11は、限定ではなく例として、受信されたユーザ検索要求に含まれる日付に基づき、そのユーザ検索要求の送信元の端末20のその日付における算出端末位置の履歴と、データベースで記憶・管理している各々の端末20のその日付における算出端末位置の履歴とに基づいて、割り勘メンバー候補を検索する。具体的には、限定ではなく例として、異なる端末20のうち、その日付における同じ時間帯に、ユーザ検索要求の送信元の端末20の近くに位置していた端末20のユーザを、割り勘メンバー候補とするユーザとして選択する。
本変形例は、割り勘マスター以外の割り勘メンバー候補(限定ではなく、異なる端末のユーザの一例)は、入力された日付の割り勘マスターの端末20の位置情報と、入力された日付の割り勘マスターの端末20とは異なる端末20の位置情報とに基づいて選択される構成を示している。
このような構成により得られる効果の一例として、端末のユーザによって入力された日付の情報を考慮して、異なる端末のユーザを、端末の位置情報と、異なる端末の位置情報とに基づいて簡単に選択することができる。
<第11変形例(3)>
第11実施例において、端末20の制御部21が、自己の端末20のユーザと、異なる端末20のユーザとの通話履歴に基づいて、割り勘メンバー候補を選択するようにしてもよいし、そのようにしなくてもよい。
具体的には、制御部21は、限定ではなく例として、自己の端末20の通話機能(電話機能)によって通話された他の端末20のユーザとの通話履歴の情報を参照する。そして、制御部21は、限定ではなく例として、手動選択買い物決済履歴の買い物決済日時と同じ日付や同じ時間帯に自己の端末20のユーザと通話した端末20のユーザを特定して、割り勘メンバー候補として選択する。
本変形例は、割り勘メンバー候補は、自己の端末20のユーザとの通話履歴に基づいて選択される構成を示している。
このような構成により得られる効果の一例として、端末のユーザとの通話履歴に基づいて、異なる端末のユーザを適切に選択することができる。
<第11変形例(4)>
第11実施例において、端末20の制御部21が、メッセージングアプリケーションを利用して送受信されたコンテンツ(メッセージや画像情報を含む。)に基づいて、割り勘メンバー候補を選択するようにしてもよいし、そのようにしなくてもよい。
限定ではなく例として、自己の端末20のメッセージングアプリケーションを利用して送受信されたコンテンツを参照し、限定ではなく例として、手動選択買い物決済履歴の買い物決済日時と同じ日付や同じ時間帯にコンテンツを送受信したユーザを特定して、割り勘メンバー候補として選択する。
また、端末20のカメラ27によって撮像された撮像画像や、いわゆるライブビュー機能によって画面に映し出されたライブビュー画像を対象として、画像認識処理を実行する。そして、画像認識処理によって認識されたユーザを、割り勘メンバー候補として選択するようにしてもよいし、そのようにしなくてもよい。
<第12実施例>
第12実施例は、割り勘メンバーに含まれる少なくとも一人のユーザについて、電子マネーによる割り勘ではなく、現金での割り勘を実現する実施例である。
ユーザによっては、電子マネーによる送金を希望せず、現金で渡す(現金で支払う)ことを希望する場合がある。
第12実施例は、上記の実施例とは、現金での割り勘を実現するための処理が追加されている点が異なる。
第12実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
本実施例において、端末20の制御部21は、割り勘メンバーを選択する際に、ユーザ操作に従って、割り勘メンバーと関連付けて、電子マネーによる割り勘と、現金での割り勘とのいずれを要求するかの割り勘種別を選択する。そして、選択した買い物決済履歴と、選択した割り勘メンバーと、選択した割り勘種別とを含む買い物決済履歴選択情報を、通信I/F22によってサーバ10に送信する。
通信I/F14によって端末20から買い物決済履歴選択情報を受信すると、サーバ10の制御部11は、受信された買い物決済履歴選択情報に基づいて、各々の割り勘メンバーについて、その割り勘メンバーに関連付けられた割り勘種別と、選択された買い物決済履歴とに基づいて、過不足金額を計算する。
<表示画面例>
図12−1は、本実施例における割り勘メンバー選択画面の一例を示す図であり、ユーザA.Aの端末20の表示部24に表示されるメッセージングアプリケーションの画面の一例を示している。この例では、メッセージングアプリケーションにおいて形成された、ユーザA.A、ユーザB.B、ユーザC.C、ユーザD.D、ユーザE.Eの5名のユーザで構成される旅行サークルのグループで割り勘を行う場合を例示する。
この割り勘メンバー選択画面では、割り勘メンバー候補とする各々のユーザのアイコン画像およびユーザ名と関連付けて、チェックボックスに加えて、割り勘種別を「現金」とするための、いわゆるラジオボタンに類する円形の割り勘種別選択ボタンが設けられている。割り勘種別選択ボタンは、各々の割り勘メンバー候補について「ON/OFF」を切り替えることが可能に構成されている。
限定ではなく例として、初期状態において、割り勘種別選択ボタンは「OFF」の状態(割り勘種別が「電子マネー」)となっており、割り勘種別選択ボタンがタッチ操作されると、割り勘種別選択ボタンの円の内部に黒丸が付されて「ON」の状態とされ、割り勘種別が「現金」に変更される。この例では、割り勘メンバー候補のうちのユーザC.Cに関連付けられた割り勘種別選択ボタンのチェックが「ON」とされた状態が示されている。
図12−2は、図12−1の割り勘メンバー選択画面において登録アイコンが操作されたことに基づいて表示される割り勘リクエスト通知画面の一例を示す図であり、割り勘メンバーの1人であるユーザC.Cの端末20の表示部24に表示される画面の一例を示している。
この割り勘リクエスト通知画面は、上記の旅行サークルのグループにおけるグループトークルーム画面であり、割り勘マスターであるユーザA.Aから発信された割り勘リクエストメッセージが表示されている。
割り勘リクエストメッセージには、ユーザC.Cの過不足金額として、その金額の値(この例では「900円」)とともに、ユーザC.Cの割り勘種別を示す「現金支払い」が表示されている。
また、その下に表示される割り勘の内容の表示欄において、ユーザB.B、ユーザD.D、ユーザE.Eの3名については、割り勘種別として「電子マネー」が選択されたため、過不足金額の欄に「900円 支払い」と表示されている。それに対し、ユーザC.Cについては、割り勘種別として「現金」が選択されたため、過不足金額の欄に「900円 支払い」の表示とともに、過不足金額を現金で支払う(過不足金額を現金で渡す)ことを示す「紙幣のマーク」と関連付けて、現金で支払う金額(この例では「900円」)が表示されている。
本実施例において、端末20の制御部21は、限定ではなく例として、選択した割り勘メンバーを識別するための情報と、各々の割り勘メンバーについて選択した割り勘種別を識別するための情報とを含むメンバー選択情報を、通信I/F22によってサーバ10に送信する。そして、サーバ10は、メンバー選択情報に含まれる割り勘メンバーの情報と、それに関連付けられた割り勘種別の情報とに基づいて、過不足金額を計算する。
なお、本実施例では、割り勘メンバーのうちの少なくとも一人のユーザについて、割り勘種別を「現金」として設定することができればよいのであって、割り勘対象とする買い物決済履歴として選択される買い物決済履歴は、1つであってもよいし、複数(2以上)であってもよい。
また、前述したように、一の買い物決済履歴を選択して登録した後に、他の買い物決済履歴を選択して追加で登録するようにしてもよいし、そのようにしなくてもよい。
<第12実施例の効果>
第12実施例は、端末20が、自己の端末20のユーザによる複数の買い物決済履歴のうち、選択された一の買い物決済履歴(限定ではなく、第1決済情報の一例)を通信I/F22によってサーバ10に送信する。そして、サーバ10は、この一の買い物決済履歴に基づく、少なくとも、割り勘種別として現金が選択された端末20の割り勘メンバー(限定ではなく、第2端末のユーザの一例)が自己の端末20のユーザに現金で渡す金額(限定ではなく、第4金額)の情報を通信I/F22によってサーバ10から受信する。そして、端末20は、受信された金額(第4金額)と、割り勘種別として現金が選択された割り勘メンバーが自己の端末20のユーザに渡す金額を紙幣のマークとともに示した情報(限定ではなく、第2端末のユーザが現金で渡す、または現金で貰う金額に関する情報の一例)を、表示部24に表示する構成を示している。
このような構成により得られる効果の一例として、端末は、複数の決済情報のうち、第1決済情報を送信することによって、端末および第1端末(端末とは異なる端末)とは異なる第2端末のユーザが現金で渡す、または現金で貰う金額である第4金額の情報を受信することができる。そして、この第4金額と、第2端末のユーザが現金で渡す、または現金で貰う金額に関する情報とを端末の表示領域に表示することによって、ユーザに報知することができる。
また、第12実施例は、端末20が、自己の端末20のユーザによる複数の買い物決済履歴のうち、選択された一の買い物決済履歴(限定ではなく、第1決済情報の一例)と、選択された他の買い物決済履歴(限定ではなく、第5決済情報の一例)とを通信I/F22によってサーバ10に送信する。そして、サーバ10は、一の買い物決済履歴と他の買い物決済履歴とに基づく、少なくとも、割り勘種別として現金が選択された端末20の割り勘メンバー(限定ではなく、第2端末のユーザの一例)が自己の端末20のユーザに現金で渡す金額(限定ではなく、第4金額)の情報を通信I/F22によってサーバ10から受信する。そして、端末20は、受信された金額(第4金額)と、割り勘種別として現金が選択された割り勘メンバーが自己の端末20のユーザに渡す金額を紙幣のマークとともに示した情報(限定ではなく、第2端末のユーザが現金で渡す、または現金で貰う金額に関する情報の一例)を、表示部24に表示する構成を示している。
このような構成により得られる効果の一例として、端末は、複数の決済情報のうち、第1決済情報と、第1決済情報とは異なる第5決済情報とを送信することによって、端末および第1端末とは異なる第2端末のユーザが現金で渡す、または現金で貰う金額である第4金額の情報を受信することができる。そして、この第4金額と、第2端末のユーザが現金で渡す、または現金で貰う金額に関する情報とを、端末の表示領域に表示することによって、ユーザに報知することができる。
また、第12実施例は、端末20が、自己の端末20に対する自己の端末20のユーザによる操作に基づいて、選択した買い物決済履歴と、選択した割り勘メンバーと、選択した割り勘種別とを含む買い物決済履歴選択情報(限定ではなく、第2端末のユーザが現金で渡す、または現金で貰うことを示す情報の一例)を通信I/F22によってサーバ10に送信する構成を示している。
このような構成により得られる効果の一例として、端末は、端末のユーザによる入力に基づいて、第2端末のユーザが現金で渡す、または現金で貰うことを外部に通知することができる。
<第12変形例>
第12実施例において、割り勘種別が「現金」であるユーザについて、割り勘マスターがそのユーザから現金を受け取った場合に、現金の受取確認を行うようにすることもできる。
図12−3は、本変形例におけるグループトークルーム画面の一例を示す図であり、割り勘マスターであるユーザA.Aの端末20の表示部24に表示される画面の一例を示している。
このグループトークルーム画面では、ユーザA.Aから発信されたメッセージとして、割り勘リクエストメッセージが、画面向かって右側に表示されている。この例では、ユーザA.Aが割り勘をリクエストしたユーザであり、他の割り勘メンバーから金銭を受け取る側であるため、割り勘リクエストメッセージには、ユーザA.Aの過不足金額として「3,600円 受取」が表示されている。
また、その下には、図12−2における割り勘リクエスト通知と同様に、自分を含む各割り勘メンバーの支払い済み金額および過不足金額が一覧表示されている。図12−2と同様に、ユーザB.B、ユーザD.D、ユーザE.Eの3名については、割り勘種別として「電子マネー」が選択されたため、過不足金額の欄に「900円 支払い」と表示されている。それに対し、ユーザC.Cについては、割り勘種別として「現金」が選択されたため、過不足金額の欄に「900円 支払い」の表示とともに、過不足金額を現金で支払う(過不足金額を現金で渡す)ことを示す「紙幣マーク」と関連付けて、現金で支払う金額(この例では「900円」)が表示されている。
また、割り勘種別が「現金」であるユーザ(この例ではユーザC.C)の欄には、ユーザC.Cからの現金の受け取り確認を行うための、限定ではなく例として「現金受取確認」と示された現金受取確認アイコンが設けられている。この現金受取確認アイコンが操作されると、そのユーザから現金を受け取ったことがサーバ10に通知され、過不足金額がサーバ10によって再計算される。
図12−4は、図12−3のグループトークルーム画面において現金受取確認アイコンが操作されたことに基づいて表示される画面の一例を示す図である。
ユーザA.Aによって、ユーザC.Cに関連付けられた現金受取確認アイコンが操作されたことに基づいて、ユーザA.AがユーザC.Cから現金を受け取ったことがサーバ10に通知され、過不足金額がサーバ10によって再計算される。その結果、ユーザA.Aの過不足金額には、ユーザC.CからユーザA.Aに現金で支払われた「900円」が「3,600円」から減算され、「2,700円 受取」と表示されている。
また、ユーザC.Cに関連付けられた現金受取確認アイコンの表示について、その文字が「現金受取確認」から「確認済み」に変更され、その色が反転して表示(反転表示)されている。また、ユーザC.Cに関連付けられた紙幣マークとともに表示される現金の支払い金額(この例では「900円」)の右側にチェックが付されて表示されている。
<第13実施例>
第13実施例は、端末20で買い物決済履歴を修正し、修正した買い物決済履歴を割り勘対象として割り勘を行う実施例である。
買い物決済履歴のうちの一部の商品を割り勘対象から除外したい場合など、買い物決済履歴の修正をユーザが希望する場合がある。
第13実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
本実施例において、端末20の制御部21は、自己の端末20のユーザによって選択された買い物決済履歴を修正する処理を実行する。
修正対象とする買い物決済履歴は、
(1)自己の端末20のユーザによる買い物決済履歴
(2)他の端末20のユーザによる買い物決済履歴
のいずれかとすることができる。
以下では、修正対象とされた買い物決済履歴を「元買い物決済履歴」(修正対象買い物決済履歴と言ってもよい。)と称し、修正された買い物決済履歴を「修正買い物決済履歴」と称する。元買い物決済履歴は、第1決済情報の一例であり、修正買い物決済履歴は、第2決済情報の一例である。
なお、おおもとの買い物決済履歴に限らず、少なくとも1回修正された後の買い物決済履歴(修正買い物決済履歴)を元買い物決済履歴として、買い物決済履歴を修正する処理を実行するようにすることも可能である。
<処理>
(1)自己の端末20のユーザによる買い物決済履歴の修正
図13−1は、本実施例において端末Aと端末Bとの間で行われる割り勘処理の流れの一例を示すフローチャートである。
この処理は、図1の処理に、端末Aの処理として、A15のステップを追加し、A20のステップをA22に置き換えるとともに、端末Bの処理として、B20のステップをB22に置き換えた処理である。
A10の後、端末Aの制御部21は、A10で選択した買い物決済履歴を修正する買い物決済履歴修正処理を行う(A15)。具体的には、制御部21は、限定ではなく例として、入出力部23に対する修正操作に従って、A10で選択した買い物決済履歴に含まれる決済内容を修正して、記憶部28に更新記憶させる。
その後、端末Aの制御部21は、修正された買い物決済履歴(以下、「修正買い物決済履歴」と称する。)を、通信I/F22によって端末Bに送信する(A22)。そして、端末Aの制御部21は、A40に処理を移す。
端末Bは、通信I/F22によって端末Aから修正買い物決済履歴を受信する(A22)。そして、端末Bの制御部21は、B30に処理を移す。
(2)他の端末20のユーザによる買い物決済履歴の修正
図13−2は、本変形例において端末Aと端末Bとの間で行われる割り勘処理の流れの一例を示すフローチャートである。
この処理は、図1の処理に、端末Aの処理として、A12、A15、A24のステップを追加し、端末Bの処理として、B10、B12、B24のステップを追加した処理である。
端末Bの制御部21は、第1の買い物決済履歴選択処理を実行する(B10)。具体的には、端末Bの制御部21は、限定ではなく例として、端末Bの記憶部28に記憶された、ユーザB.Bによる複数の買い物決済履歴の中から、入出力部23に対する選択操作に基づいて、少なくとも1つの買い物決済履歴を選択する。
その後。端末Bの制御部21は、B10で選択した買い物決済履歴を、通信I/F22によって端末Aに送信する(B12)。通信I/F22によって端末Bから買い物決済履歴を受信すると(A12)、端末Aの制御部21は、買い物決済履歴修正処理を実行する(A15)。この買い物決済履歴修正処理における修正の手法は、図13−1の処理と同様であるが、修正の対象が、自身による買い物決済履歴ではなく、他の端末20のユーザによる買い物決済履歴である点が異なる。
次いで、端末Aの制御部21は、A15での買い物決済履歴の修正の内容を含む買い物決済履歴修正情報を、通信I/F22によって端末Bに送信する(A24)。そして、端末Aの制御部21は、A40に処理を移す。
B12の後、端末Bは、通信I/F22によって端末Aから買い物決済履歴修正情報を受信する(B24)。そして、端末Bの制御部21は、B30に処理を移す。
<第13実施例の効果>
第13実施例は、端末20が、自己の端末20のユーザによる修正操作(限定ではなく、端末のユーザによる端末に対する入力の一例)に基づいて、元買い物決済履歴(限定ではなく、第1決済に関する処理に基づく第1決済情報の一例)を修正買い物決済履歴(限定ではなく、第2決済情報の一例)に修正する買い物決済履歴修正処理を制御部21によって実行する。端末20は、修正買い物決済履歴に基づく、自己の端末20のユーザの過不足金額(限定ではなく、第1金額の一例)と、他の端末20のユーザの過不足金額(限定ではなく、第2金額の一例)とのうち、少なくとも自己の端末20のユーザの過不足金額の情報を通信I/F22によって他の端末20から受信する。そして、端末20は、自己の端末20のユーザの過不足金額に基づく送金処理、または受取処理を制御部21によって実行する構成を示している。
このような構成により得られる効果の一例として、端末は、第1決済に関する処理に基づく第1決済情報を第2決済情報に修正した上で、この第2決済情報に基づいて、送金処理、または受取処理を実行することができる。また、第1決済情報を修正することができるため、ユーザの利便性を向上させることができる。
また、第13実施例は、端末20は、メモリに記憶されたプログラムを読み出し、読み出したプログラムに基づく処理を実行するプロセッサを備える。このプロセッサは、自己の端末20のユーザによる修正操作(限定ではなく、端末のユーザによる端末に対する入力の一例)に基づいて、元買い物決済履歴(限定ではなく、第1決済に関する処理に基づく第1決済情報の一例)を修正買い物決済履歴(限定ではなく、第2決済情報の一例)に修正する買い物決済履歴修正処理を実行し、修正買い物決済履歴に基づく、自己の端末20のユーザの過不足金額(限定ではなく、第1金額の一例)と、他の端末20のユーザの過不足金額(限定ではなく、第2金額の一例)とのうち、少なくとも自己の端末20のユーザの過不足金額の情報を通信I/F22によって他の端末20から受信し、自己の端末20のユーザの過不足金額に基づく送金処理、または受取処理を実行する構成を示している。
このような構成によっても、上記と同様の効果を得ることができる。
また、第13実施例は、元買い物決済履歴は、自己の端末20のユーザによる買い物決済の履歴である構成を示している。
このような構成により得られる効果の一例として、端末のユーザによる決済に関する処理に基づく第1決済情報を第2決済情報に修正することができる。
また、第13実施例は、修正買い物決済履歴を、通信I/F22によって異なる端末に送信する構成を示している。
このような構成により得られる効果の一例として、修正結果として得られた第2決済情報を外部に送信することができる。
また、第13実施例は、元買い物決済履歴は、異なる端末20のユーザによる買い物決済の履歴である構成を示している。
このような構成により得られる効果の一例として、異なる端末のユーザによる決済に関する処理に基づく第1決済情報を第2決済情報に修正することができる。
<第13変形例(1)>
第13実施例では、端末20が、修正された買い物決済履歴(修正買い物決済履歴)を異なる端末20に送信することとしたが、これに限定されない。
この場合、限定ではなく例として、一の端末20と、異なる端末20とで、各々の端末20のユーザの買い物決済履歴のデータを共有しておく。そして、買い物決済履歴を修正した場合に、修正された買い物決済履歴そのものを異なる端末20に送信するのではなく、修正した箇所や修正した内容の情報、つまり、元買い物決済履歴と修正買い物決済履歴との差分の情報を、異なる端末20に送信するようにしてもよいし、そのようにしなくてもよい。
また、元買い物決済履歴が選択された場合に、この選択された買い物決済履歴を通信I/F22によって異なる端末20に送信する。そして、その後に、端末20が、自己の端末20のユーザによる修正操作に基づいて、送信した買い物決済履歴を修正する買い物決済履歴修正処理を実行するようにしてもよいし、そのようにしなくてもよい。この場合、買い物決済履歴修正処理を実行した後は、修正買い物決済履歴そのものを異なる端末20に送信するようにしてもよいし、先に送信した元買い物決済履歴と修正買い物決済履歴との差分の情報を異なる端末20に送信するようにしてもよい。
本変形例は、端末20が、元買い物決済履歴と修正買い物決済履歴との差分の情報を、通信I/F22によって異なる端末20に送信する構成を示している。
このような構成により得られる効果の一例として、第2決済情報を送信する場合と比べて、端末の通信量を削減することができる。
また、本変形例は、端末20が、元買い物決済履歴を通信I/F22によって異なる端末20に送信する。そして、元買い物決済履歴が送信された後、自己の端末20のユーザによる修正操作に基づいて、送信した元買い物決済履歴が修正買い物決済履歴に修正される構成を示している。
このような構成により得られる効果の一例として、第1決済情報を送信した後に、第1決済情報を第2決済情報に修正することで、修正対象とする第1決済情報をあらかじめ外部に送信しておくことができる。
<第13変形例(2)>
第13実施例において、端末20の制御部21が買い物決済履歴修正処理を実行するのではなく、サーバ10の制御部11が買い物決済履歴修正処理を実行するようにすることもできる。つまり、買い物決済履歴を修正する処理(第1決済情報を第2決済情報に修正する処理)の実行主体は、端末20の制御部21であってもよいし、サーバ10の制御部11であってもよい。この詳細については、以降の実施例で説明する。
<第14実施例>
第14実施例は、端末20がサーバ10と通信を行って、買い物決済履歴を修正する実施例である。第13実施例と同様に、買い物決済履歴の修正をユーザが希望する場合がある。
第14実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
<表示画面例>
図14−1は、本実施例における買い物決済履歴選択画面の一例を示す図であり、ユーザA.Aの端末20の表示部24に表示される画面の一例を示している。
この買い物決済履歴選択画面には、ユーザA.Aによる買い物決済に対応する買い物決済履歴として複数の買い物決済履歴が表示されている。また、前述したように、各々の買い物決済履歴と関連付けてチェックボックスが設けられており、チェックボックスのチェックマークがONとされた買い物決済履歴を割り勘対象とすることができるように構成されている。
これに加えて、本実施例では、各々の買い物決済履歴と関連付けて、その詳細を入力するための、限定ではなく例として「詳細」と示された詳細アイコンが設けられている。
図14−2は、図14−1の買い物決済履歴選択画面において詳細アイコンが操作されたことに基づいて表示される詳細入力画面の一例を示す図である。
この詳細入力画面では、「割り勘をする支払いの詳細を入力してください」の文字とともに、図14−1の買い物決済履歴選択画面で選択された「BBスーパー」での買い物決済履歴の買い物決済日時、店舗名、買い物決済金額等の情報が表示されている。
また、その下には、この買い物決済履歴の支払い明細として、購入された商品の名称およびその商品の単価が一覧表示される商品一覧表示領域と、商品の購入数が一覧表示される購入数一覧表示領域とが設けられている。購入数一覧表示領域には、デフォルトとして、この買い物決済履歴に対応する商品の購入数が入力されている。
商品一覧表示領域に含まれる一の商品に対応する表示領域を操作(限定ではなく例としてタッチ操作)すると、この商品に関連付けられた第2商品表示領域に表示されている購入数を0個にリセットすることができるように構成されている。
また、購入数一覧表示領域には、各々の商品と関連付けて、その購入数を増加修正するための上ボタンと、その購入数を減少修正するための下ボタンとが表示されており、これらのボタンを操作することで、その購入数を修正することが可能に構成されている。
この例では、商品一覧表示領域のうちの商品名「温泉まんじゅう」に対応する表示領域が操作されたことに基づいて、この表示領域に色が付されて表示されるとともに、その購入数が1個から0個にリセットされている。
図14−3は、図14−2の詳細入力画面において登録アイコンが操作されたことに基づいて表示される買い物決済履歴選択画面の一例を示す図である。
この買い物決済履歴選択画面では、図14−2の詳細入力画面において商品名「温泉まんじゅう」の購入数が1個から0個に修正されたことで、「単価600円×1個=600円」の金額が買い物決済金額から減額され、その結果、「BBスーパー」の買い物決済履歴における買い物決済金額が「2,400円」に修正されている。また、買い物決済金額と関連付けて、その買い物決済金額が修正されたことを示す修正マークが表示されている。
<データ構成>
図14−4は、本実施例においてサーバ10の記憶部15に記憶される情報の一例を示す図である。
記憶部15には、支払いアプリケーション管理処理プログラム151と、支払いアプリケーションユーザ登録データ153と、ユーザ管理データベース155と、割り勘管理データベース157とに加えて、買い物細目管理データベース159が記憶されている。
図14−5は、本実施例における割り勘管理データベース157の一例である第2の割り勘管理データベース157Bの一例を示す図である。
第2の割り勘管理データベース157Bに含まれる各割り勘管理データには、限定ではなく例として、割り勘管理IDと、割り勘マスターIDと、割り勘メンバーIDと、買い物決済履歴管理データとが記憶される。
また、買い物決済履歴データには、限定ではなく例として、決済者IDと、買い物決済IDと、割り勘対象金額と、割り勘対象の細目(以下、「割り勘細目」と称する。)とが関連付けて記憶される。
割り勘細目には、その買い物決済IDによって識別される買い物決済履歴について、割り勘細目として、購入された商品の名称や数等の基本的な情報が記憶される。
買い物細目管理データベース159は、買い物の細目(以下、「買い物細目」と称する。)を管理するためのデータベースであり、そのデータ構成の一例を図14−6に示す。
買い物細目管理データベース159には、買い物決済IDごとのデータとして、買い物細目管理データが記憶される。
各買い物細目管理データには、限定ではなく例として、買い物決済IDと、買い物細目データとが記憶される。
買い物細目データには、買い物細目として、限定ではなく例として、商品名と、購入数と、単価と、購入金額(=単価×購入数)とが関連付けて記憶される。
<処理>
図14−7は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。
この処理は、図2−17の処理において、端末Aの処理としてA170のステップを追加し、A180のステップをA185に置き換えた処理である。また、サーバ10の処理としてS180のステップをS185に置き換えた処理である。
A170の後、端末Aの制御部21は、買い物決済履歴修正処理を実行する(A175)。具体的には、入出力部23に対する修正操作に従って、買い物決済履歴のうち、商品名、購入数の少なくともいずれかを修正する。
その後、端末Aの制御部21は、ユーザA.Aの支払いアプリケーションIDと、修正した買い物決済履歴の買い物決済IDと、その修正内容とを含む修正済み買い物決済履歴選択情報を通信I/F22によってサーバ10に送信する(A185)。
S160の後、通信I/F14によって端末Aから修正済み買い物決済履歴選択情報を受信すると(S185)、サーバ10の制御部11は、受信された修正済み買い物決済履歴選択情報に含まれる支払いアプリケーションIDと、買い物決済IDと、修正内容とに基づいて、第2の割り勘管理データベース157Bのうちの、対応する割り勘管理データを更新する。具体的には、商品名が修正された場合は、買い物決済履歴管理データのうちの対応する割り勘細目の欄を更新する。また、購入数が修正された場合は、買い物決済履歴管理データのうちの割り勘細目および割り勘対象金額の欄を更新する。
また、制御部11は、同様にして、買い物細目管理データベース159のうちの、対応する買い物細目管理データを更新する。具体的には、商品名が修正された場合は、買い物細目データのうちの商品名の欄を更新する。また、購入数が修正された場合は、買い物細目データのうちの購入数の欄を更新する。
これらの処理は、サーバ10の制御部11によって実行される第1決済情報を第2決済情報に修正する処理の一例とも言える。
その後、制御部11は、S190に処理を移す。
<第14実施例の効果>
第14実施例は、端末20が、買い物決済履歴修正処理において、元買い物決済履歴のうちの購入された商品の情報を修正する構成を示している。
このような構成により得られる効果の一例として、第1決済情報のうち購入された商品の情報を修正することができる。
また、第14実施例は、買い物決済履歴修正処理において購入された商品の情報が削除され、その結果、買い物決済金額が減額される構成を示している。
このような構成により得られる効果の一例として、第1決済情報のうち購入された商品の情報が削除され、決済金額が減額されるため、限定ではなく例として、割り勘対象とする商品を除外して、決済金額を所望の金額に修正することができる。
また、第14実施例は、サーバ10が、端末20のユーザによる修正操作(限定ではなく、端末のユーザによる端末に対する入力の一例)に基づいて、元買い物決済履歴(限定ではなく、第1決済に関する処理に基づく第1決済情報の一例)を修正買い物決済履歴(限定ではなく、第2決済情報の一例)に修正する買い物決済履歴修正処理を制御部11によって実行する。サーバ10は、少なくとも一の端末20のユーザの過不足金額(限定ではなく、第1金額の一例)の情報を一の端末20に通信I/F14によって送信し、少なくとも他の端末20のユーザの過不足金額(限定ではなく、第2金額の一例)の情報を他の端末20に通信I/F14によって送信する。そして、サーバ10は、割り勘精算処理(限定ではなく、第1金額に基づく、端末に対する送金処理、または受取処理と、第2金額に基づく、異なる端末に対する送金処理、または受取処理との一例)を制御部11によって実行する構成を示している。
このような構成により得られる効果の一例として、サーバは、第1決済に関する処理に基づく第1決済情報を第2決済情報に修正した上で、この第2決済情報に基づいて、端末に対する送金処理、または受取処理と、異なる端末に対する送金処理、または受取処理とを実現することができる。また、これらの処理を端末側で行わずに済むため、端末の処理負荷を軽減することができる。
<第14変形例(1)>
買い物決済を行ったことに基づいて、商品等を購入した店舗から特典として付与されるポイント(限定ではなく、還元情報の一例)に基づいて、買い物決済履歴を修正するようにしてもよいし、そのようにしなくてもよい。
図14−8は、本変形例における買い物決済履歴選択画面の一例を示す図である。
この買い物決済履歴選択画面では、「BBスーパー」の買い物決済履歴と関連付けて、「BBスーパー」から特典として付与されたポイントがあることを示すポイントアイコンが表示されている。ポイントアイコンが操作されることで、付与されたポイントを確認することが可能となる。
図14−9は、図14−8の買い物決済履歴選択画面においてポイントアイコンが操作されたことに基づいて表示されるポイント確認画面の一例を示す図である。
このポイント確認画面では、「利用可能なポイントがあります」の文字が表示され、その下に、「BBスーパー」の買い物決済履歴の情報が表示されている。また、その下には、ポイント発生額を買い物決済金額から差し引くか否かを選択するための「ON/OFF」を切替可能なポイント利用設定ボタンが表示されている。
また、その下には、付与されたポイントが表示されており、この例では、「10%還元 300pt(300円相当)発生」の文字を含むポイント情報が表示されている。この例では、ポイント利用設定ボタンが「ON」に設定されたことで、ポイント情報の下に、買い物決済金額からポイント発生額を差し引いた金額(この例では3,000円−300円=2,700円)が修正された金額として表示されている。
なお、還元情報には、ポイントに限らず、いわゆる電子クーポン(モバイルクーポン)等を含めることもできる。
本変形例は、買い物決済履歴は、買い物決済を行った店舗から付与されるポイント等(限定ではなく、還元情報の一例)に基づいて修正される構成を示している。
このような構成により得られる効果の一例として、端末は、端末のユーザが第1決済を行った店舗の還元情報に基づいて、第1決済情報を第2決済情報に修正することができる。
また、本変形例は、端末20は、ポイント利用設定ボタン(限定ではなく、還元情報に基づく修正を行うための第1表示の一例)を表示部24に表示し、買い物決済履歴は、ポイント利用設定ボタンに対するユーザの切替操作(限定ではなく、第1表示に対する端末のユーザの入力の一例)に基づいて修正される構成を示している。
このような構成により得られる効果の一例として、還元情報に基づく修正を行うための、端末のユーザが入力可能な第1表示が端末の表示領域に表示されるため、ユーザの利便性を向上させることができる。
<第14変形例(2)>
第14実施例において、前述したメモやタグを、買い物決済履歴に関連付けて設定するようにしてもよいし、そのようにしなくてもよい。
図14−10は、本変形例における買い物決済履歴選択画面の一例を示す図である。
この買い物決済履歴選択画面は、図14−2の買い物決済履歴選択画面とほぼ同様であるが、画面下部にメモが関連付けて設定されている点が異なる。具体的には、自己の端末20のユーザ(ユーザA.A)によって入力されたメモとして、「自分のお土産に買った温泉まんじゅう代(600円)を引いてあります」という内容のメモが入力されて表示されている。このようにすることで、他の割り勘メンバーは、温泉まんじゅうの購入数が“0”に修正されたこと、および、その結果として割り勘対象とする金額が減額されたことを簡単に知ることができる。
<第15実施例>
第15実施例は、端末20がサーバ10と通信を行って、買い物決済履歴を修正する実施例である。第15実施例は、第14実施例とは異なり、端末20のユーザによる修正操作に基づいて、買い物決済金額を修正する。
また、第15実施例では、買い物決済履歴ごとに、割り勘メンバーを変更することを可能とする。
第15実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
<表示画面例>
図15−1は、本実施例における買い物決済履歴選択画面の一例を示す図であり、ユーザA.Aの端末20の表示部24に表示される画面の一例を示している。
この買い物決済履歴選択画面には、ユーザA.Aによる買い物決済に対応する買い物決済履歴として複数の買い物決済履歴が表示されている。また、前述したように、各々の買い物決済履歴と関連付けてチェックボックスが設けられており、チェックボックスのチェックマークがONとされた買い物決済履歴を割り勘対象とすることができるように構成されている。
これに加えて、本実施例では、各々の買い物決済履歴と関連付けて、その詳細を入力するための、限定ではなく例として「詳細」と示された詳細アイコンが設けられている。
図15−2は、図15−1の買い物決済履歴選択画面において詳細アイコンが操作(限定ではなくタッチ操作)されたことに基づいて表示される詳細入力画面の一例を示す図であり、図15−1の買い物決済履歴選択画面における「BBスーパー」の買い物決済履歴に関連付けられた詳細アイコンが操作された場合の画面の一例を示している。
この詳細入力画面では、「割り勘をする支払いの詳細を入力してください」の文字とともに、図15−1の買い物決済履歴選択画面で選択された「BBスーパー」での買い物決済履歴における買い物決済金額が表示されている。
また、その下には、この買い物決済金額を上限金額として、割り勘対象とする金額を修正するための金額修正欄が設けられている。金額修正欄には、割り勘対象とする金額を増額修正するための上ボタンと、割り勘対象とする金額を減額修正するための下ボタンとが関連付けて設けられており、この上ボタン/下ボタンが操作されることで、金額を増額/減額させるように修正することが可能に構成されている。この金額の修正は、買い物決済履歴の買い物決済金額の修正と言うこともできる。
金額修正欄の下には、割り勘メンバーの一覧が表示される割り勘メンバー一覧表示領域が設けられており、各々の割り勘メンバーのアイコン画像と関連付けて、その割り勘メンバーが割り勘メンバー候補として設定されていか否かを示すチェックが表示されている。限定ではなく例として、割り勘メンバーのアイコン画像を操作することで、チェックのON/OFFを切り替えることができ、チェックがOFFとされたユーザは、割り勘メンバー候補から除外される。この例では、ユーザC.CのチェックがOFFとされており、ユーザC.Cが割り勘メンバー候補から除外された状態が示されている。
また、割り勘メンバー一覧表示領域の下には、選択されている買い物決済履歴にタグを設定するためのタグ表示領域が設けられており、複数種類のタグの候補が表示されている。タグの候補には、限定ではなく例として、「買い物」、「仕事」、「デート」、「旅行」、「贈り物」、「その他」等の複数の候補が含まれる。この複数種類のタグの候補のうちのいずれかのタグに対する操作を行うことで、そのタグを、この買い物決済履歴に関連付けて設定することができる。この例では、「旅行」のタグが操作されたことによって、「旅行」のタグが「BBスーパー」での買い物決済履歴に関連付けて設定された状態が示されている。
また、タグ表示領域の下には、端末20のユーザがメモを記載するためのメモ欄が設けられている。この例では、「C.Cさんはスーパーで買い物をしなかった 個人的に購入した飲み物代(400円)を引いておきます」というメモが記載されている。このメモの内容から、上記のように、ユーザC.Cが割り勘メンバーから除外された理由、および、金額が「3,000円」から「2,600円」に修正された理由が分かる。
また、画面下部には、この買い物決済履歴の修正内容を登録するための、限定ではなく例として「登録」と示された登録アイコンが表示されている。
図15−3は、詳細入力画面の別例を示す図である。
この詳細入力画面の構成は、図15−2の詳細入力画面とほぼ同様であるが、「割り勘をする支払いの詳細を入力してください」の文字とともに、買い物決済が行われたイベントの名称(イベント名)が表示されている。この例では、イベント名として「GG公園の入場料」が表示されている。
図15−4は、図15−2、図15−3の詳細入力画面での入力の結果として表示される買い物決済履歴選択画面の一例を示す図である。
この買い物決済履歴選択画面では、図15−1の買い物決済履歴選択画面と同様に、ユーザA.Aによる買い物決済に対応する買い物決済履歴として複数の買い物決済履歴が表示されているが、その表示が一部異なっている。
具体的には、限定ではなく例として、図15−2の「BBスーパー」での買い物決済履歴に関する修正に伴い、「BBスーパー」の買い物決済履歴の表示欄に、修正された割り勘メンバーのアイコン画像(上記の例ではユーザC.Cが除外されたため他の4人のユーザのアイコン画像)と、設定されたタグ(上記の例では「旅行」のタグ)の画像とが表示されている。また、割り勘対象とする金額として、金額が修正されたことを示す「修正」のマークとともに、修正後の金額である「2,600円」が表示されている。
また、その横には、この買い物決済履歴と関連付けて設定されたメモを確認するためのメモアイコンが表示されている。このメモアイコンが操作されると、この買い物決済履歴と関連付けて設定されたメモが、限定ではなく例として、ポップアップ形式や、別のページに表示される。
また、限定ではなく例として、図15−3のイベント名「GG公園の入場料」での買い物決済履歴に関する修正に伴い、「GG公園の入場料」の買い物決済履歴の表示欄に、設定されたタグ(上記の例では「旅行」のタグ)の画像が表示されている。
図15−5は、コード画像に基づく決済を行うためのコード画面の一例を示す図である。
このコード画面は、買い物決済に利用されるコード支払い用のコード画像であって端末20の表示部24に表示されるコード画像(以下、「支払いコード画像」と称する。)を含む画面の一例であり、決済方法(電子マネー口座残高を含む。)と、この端末20のユーザが所有しているポイント(決済時におけるポイントの優先使用の有無(ON/OFF))とともに、限定ではなく例としてバーコードで表される一次元の支払いコード画像と、限定ではなく例としてQRコード(登録商標)で表される二次元の支払いコード画像とが表示されている。
また、このコード画面の下部には、前述したタグ表示領域が設けられている。このタグ表示領域には、前述したように、複数種類のタグの候補が表示されている。そして、支払いコード画像を店舗のコードリーダ、または店舗のコードリーダ装置(以下、包括的に「店舗コードリーダ装置」と称する。)に読み取らせて買い物決済を行う際、あらかじめ指定しておいたタグを、その買い物決済の買い物決済履歴に関連付けて設定することが可能となる。この例では、「旅行」のタグが指定された状態が示されており、この状態で支払いコード画像を用いて買い物決済を行うと、その買い物決済の買い物決済履歴に「旅行」のタグが関連付けられることになる。
より具体的には、端末20から送信されるコード生成依頼情報に基づいて、サーバ10はコード生成処理を実行する。具体的には、限定ではなく例として、ランダムなトークン情報(ランダムな番号を含む。)を発生させ、発生させたトークン情報を、この端末20のユーザの支払いアプリケーションIDに関連付けて記憶させる。そして、発生させたトークン情報をエンコードした支払いコード画像を生成して端末20に送信する。端末20は、サーバ10から受信したコード画像と、複数種類のタグの候補とを含むコード画面を表示部24に表示させる。
ユーザ操作に従って複数種類のタグの候補の中から少なくとも1つのタグを選択すると、端末20は、そのタグの選択情報をサーバ10に送信する。
一方、店舗コードリーダ装置によって支払いコード画像が読み取られると、この支払いコード画像に格納されているトークン情報が店舗コードリーダ装置によってデコードによって取得され、決済予定金額とともに店舗コードリーダ装置からサーバ10に送信される。
サーバ10は、店舗コードリーダ装置から受信したトークン情報が、いずれの支払いアプリケーションIDに関連付けられているかを判定する。そして、判定した支払いアプリケーションIDの電子マネー口座から決済予定金額を決済する。そして、端末20から別途受信したタグの選択情報に基づき、その買い物決済履歴にタグを関連付けて設定する。
なお、同様の手法によって、タグに代えて、またはこれに加えて、買い物決済履歴にメモを関連付けるようにしてもよいし、そのようにしなくてもよい。
<データ構成>
図15−6は、本実施例においてサーバ10の記憶部15に記憶される割り勘管理データベース157の一例である第3の割り勘管理データベース157Cのデータ構成例を示す図である。
第3の割り勘管理データベース157Cの各割り勘管理データには、限定ではなく例として、割り勘管理IDと、割り勘マスターIDと、割り勘メンバーIDと、買い物決済履歴管理データとが記憶される。
買い物決済履歴管理データには、限定ではなく例として、決済者IDと、買い物決済IDと、割り勘対象金額と、割り勘対象メンバーと、メモと、タグとが関連付けて記憶される。
決済者ID〜割り勘対象金額は、第1の割り勘管理データベース157Aと同様である。
割り勘対象メンバーには、割り勘メンバーIDにIDが記憶された割り勘メンバーのうち、その買い物決済IDによって識別される買い物決済履歴(その割り勘対象金額)を割り勘するメンバーとして、その決済者IDのユーザによって選択・登録された割り勘メンバー(以下、「割り勘対象メンバー」と称する。)の支払いアプリケーションIDが記憶される。
割り勘メンバーは、割り勘管理IDによって識別される1つの単位としての割り勘を行うメンバーとして設定される固定的なメンバーであるのに対し、割り勘対象メンバーは、割り勘を行う対象として選択・登録された買い物決済履歴ごとに設定されるメンバーである点が異なる。
メモには、その買い物決済IDによって識別される買い物決済履歴に関連付けるメモとして、限定ではなく例として、その決済者IDのユーザの端末20で入力されたメモが記憶される。
タグには、その買い物決済IDによって識別される買い物決済履歴に関連付けるタグとして、限定ではなく例として、その決済者IDのユーザの端末20で入力されたタグが記憶される。
<処理>
本実施例において、端末20の制御部21は、図14−7の処理における買い物決済履歴修正処理において(A175)、自己の端末20のユーザによる買い物決済金額の修正操作に従って、買い物決済金額、割り勘メンバー候補、メモ、タグのうちの少なくともいずれか1つを修正する。そして、制御部21は、自己のユーザの支払いアプリケーションIDと、修正した買い物決済履歴の買い物決済IDと、修正内容とを含む修正済み買い物決済履歴選択情報を、通信I/F22によってサーバ10に送信する(A185)。
通信I/F14によって端末20から修正済み買い物決済履歴選択情報を受信すると(S185)、サーバ10の制御部11は、受信された修正済み買い物決済履歴選択情報に含まれる支払いアプリケーションIDと、買い物決済IDと、修正内容とに基づいて、第3の割り勘管理データベース157Cのうちの対応する割り勘管理データを更新する。具体的には、買い物決済金額が修正された場合は、買い物決済履歴管理データのうちの対応する割り勘対象金額の欄を更新する。割り勘メンバー候補が修正された場合は、買い物決済管理データのうちの対応する割り勘対象メンバーの欄を更新する。メモが追加・修正された場合は、買い物決済履歴管理データのうちの対応するメモの欄を更新する。また、タグが追加・修正された場合は、買い物決済履歴管理データのうちの対応するタグの欄を更新する。
<第15実施例の効果>
第15実施例は、端末20は、買い物決済履歴修正処理において、自己の端末20のユーザの修正操作に基づいて、買い物決済金額を修正する構成を示している。
このような構成により得られる効果の一例として、端末のユーザの入力に従って、第1決済情報の決済金額を所望の金額に修正することができる。
また、第15実施例は、端末20が、自己の端末20のユーザによる選択操作に基づいて、元買い物決済履歴(限定ではなく、第1決済情報の一例)および修正買い物決済履歴(限定ではなく、第2決済情報の一例)とは異なる買い物決済履歴(限定ではなく、第3決済情報の一例)を入力する処理を制御部21によって実行する構成を示している。
このような構成により得られる効果の一例として、第1決済情報および第2決済情報とは異なる第3決済情報を入力する処理を制御部によって実行することで、限定ではなく例として、割り勘対象とする決済情報を追加することができる。
また、第15実施例は、買い物決済履歴は、複数の決済情報の各々に関連付けられたタグ等(限定ではなく、端末のユーザによって入力された情報の一例)に基づいて選択される構成を示している。
このような構成により得られる効果の一例として、複数の決済情報の各々に関連付けられた、端末のユーザによって入力された情報に基づいて、第1決済情報を適切に選択することができる。
また、第15実施例は、端末20が、複数の買い物決済履歴のうち、一の買い物決済履歴(限定ではなく、第1決済情報の一例)と、他の買い物決済履歴(限定ではなく、第4決済情報の一例)とを通信I/F22によってサーバ10に送信する。端末20は、自己の端末20のユーザの過不足金額(限定ではなく、第1金額の一例)と、第1の端末20の割り勘メンバーの過不足金額(限定ではなく、第2金額の一例)と、第2の端末20の割り勘メンバーの過不足金額(限定ではなく、第3金額の一例)とを通信I/F22によってサーバ10から受信する。この場合、自己の端末20のユーザの過不足金額は、一の買い物決済履歴と他の買い物決済履歴とに基づいて決定されるが、第1の端末20の割り勘メンバーの過不足金額は、一の買い物決済履歴に基づいて決定され、第2の端末20の割り勘メンバーの過不足金額は、他の買い物決済履歴に基づいて決定される構成を示している。
このような構成により得られる効果の一例として、端末は、異なる決済情報に基づいて決定された、端末のユーザが送金、または受け取る第1金額と、第1端末のユーザが送金、または受け取る第2金額と、端末および第1端末とは異なる第2端末のユーザが送金、または受け取る第3金額とを、受信することができる。
<第16実施例>
第16実施例は、元買い物決済履歴と、修正買い物決済履歴とを、表示態様を変えて(表示態様を異ならせて)表示する実施例である。第13実施例〜第15実施例に示したように買い物決済履歴を修正した場合、その修正箇所が分かりづらい場合がある。
第16実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
<表示画面例>
図16−1は、本実施例における買い物決済履歴選択画面の一例を示す図である。
この買い物決済履歴選択画面では、「BBスーパー」の買い物決済履歴と関連付けて、この買い物決済履歴が修正されたことを示す修正マークに加えて、買い物決済金額が減額修正されたことを示す下三角形のマークが表示されている。
図16−2は、本実施例における割り勘リクエスト通知画面の一例を示す図であり、ユーザB.Bの端末20の表示部24に表示される画面の一例を示している。
この割り勘リクエスト通知画面において、ユーザB.Bの過不足金額を示す過不足金額表示領域がユーザB.Bによって操作されると、その割り勘の内訳が表示される。この割り勘の内訳における「BBスーパー」の買い物決済履歴には、図16−1と同様に、買い物決済金額が減額修正されたことを示す下三角形のマークが表示されている。
図16−3は、本実施例における買い物決済履歴選択画面の別例を示す図であり、図16−1と同様の画面であるが、その内容が一部異なっている。
この買い物決済履歴選択画面では、「BBスーパー」の買い物決済履歴と関連付けて、この買い物決済履歴が修正されたことを示す修正マークに加えて、買い物決済金額が増額修正されたことを示す上三角形のマークが表示されている。
図16−4は、本実施例における割り勘リクエスト通知画面の別例を示す図であり、図16−2と同様の画面であるが、その内容が一部異なっている。
この割り勘リクエスト通知画面では、割り勘の内訳における「BBスーパー」の買い物決済履歴には、図16−3と同様に、買い物決済金額が増額修正されたことを示す上三角形のマークが表示されている。
<第16実施例の効果>
第16実施例は、端末20が、修正買い物決済履歴(限定ではなく、修正された第2決済情報の一例)と、元買い物決済履歴(限定ではなく、修正されていない決済情報の一例)とで表示態様を異ならせて表示部24に表示する構成を示している。
このような構成により得られる効果の一例として、決済情報が修正されたことや、決済情報のうちの修正された情報を、端末のユーザが容易に把握可能とすることができる。
また、第16実施例は、端末20が、買い物決済履歴の買い物決済金額が減額修正された場合、第1表示態様で表示部24に表示し、買い物決済履歴の買い物決済金額が増額修正された場合、第2態様で表示部24に表示する構成を示している。
このような構成により得られる効果の一例として、第2決済情報の決済金額が増額と減額のいずれに修正されたかを、端末のユーザが容易に把握可能とすることができる。
<第16変形例>
第16実施例において、端末20が、修正買い物決済履歴に対する自己の端末20のユーザによる入力に基づいて、修正買い物決済履歴の修正内容を表示するようにすることもできる。
図16−5は、本変形例における詳細入力画面の一例を示す図であり、ユーザA.Aの端末20の表示部24に表示される画面の一例を示している。
この詳細入力画面では、「BBスーパー」の買い物決済履歴の詳細が表示されており、画面中央部の支払い明細の欄において、商品名およびその商品名の商品の単価と関連付けて、変更前の購入数と、変更後の購入数とが表示されている。
図16−6は、本変形例における割り勘リクエスト通知画面を示す図であり、ユーザB.Bの端末20の表示部24に表示される画面の一例を示している。
この割り勘リクエスト通知画面において、過不足金額表示領域の下には、割り勘マスターであるユーザA.Aのアイコン画像およびユーザ名と関連付けて、ユーザA.Aによって入力されたメモが表示されている。また、その下には、割り勘の内訳が表示されている。割り勘の内訳には、登録されている各々の買い物決済履歴が含まれている。この例では、「AAレンタサイクル」、「BBスーパー」等の複数の買い物決済履歴が含まれ、「BBスーパー」の買い物決済履歴には、買い物決済金額が減額修正されたことを示す減額マークが関連付けて表示されている。
限定ではなく例として、この「BBスーパー」の買い物決済履歴の表示領域が操作されると、その修正内容がポップアップ形式で表示される。この例では、買い物決済金額が修正されたことを示す「金額修正」の文字と、買い物決済金額が「3,000円」から「2,600円」に減額修正されたことを示す情報と、修正を行ったユーザのアイコン画像(この例ではユーザA.Aのアイコン画像)とを含む内容がポップアップ形式で表示されている。
本変形例は、端末20は、自己の端末20の表示部24に表示された修正買い物決済履歴に対する端末20のユーザの操作(限定ではなく、端末のユーザによる入力の一例)に基づいて、修正買い物決済履歴の修正内容を表示する構成を示している。
このような構成により得られる効果の一例として、端末のユーザが自己の端末に対する入力を行うことで、第2決済情報の修正内容を確認できるようにすることができる。
<第17実施例>
第17実施例は、端末20で修正された修正買い物決済履歴に対して、異なる端末20のユーザが修正提案を行うことを可能とする実施例である。修正された買い物決済履歴に対して、割り勘メンバーが異議を申し立てることを希望する場合がある。
以下の実施例では、端末20のユーザが、割り勘対象として登録した自分の買い物決済履歴を修正することを「修正」と称し、端末20のユーザが、割り勘対象として登録された異なる端末20のユーザの買い物決済履歴を修正するように提案することを「修正提案」と称する。
第17実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
<表示画面例>
図17−1は、本実施例における割り勘内容確認画面の一例を示す図であり、ユーザB.Bの端末20の表示部24に表示される画面の一例を示している。
この割り勘内容確認画面には、限定ではなく例として、支払い済み金額一覧表示領域について、自分(この例ではユーザB.B)のアイコン画像およびユーザ名と関連付けて自身が登録した買い物決済履歴を修正するための「修正」と示された修正マークが表示されている。また、自分以外の割り勘メンバーのアイコン画像およびユーザ名と関連付けて、その割り勘メンバーが登録した買い物決済履歴の修正を提案するための「修正提案」と示された修正提案マークが表示されている。
図17−2は、図17−1の割り勘内容確認画面においてユーザA.Aに関連付けられた修正提案マークがユーザB.Bによって操作されたことに基づいて表示される買い物決済履歴修正提案画面の一例を示す図である。
この買い物決済履歴修正提案画面には、「修正提案したい支払い履歴を選んでください」の文字とともに、ユーザA.Aが登録した買い物決済履歴が一覧表示されている。この例では、ユーザA.Aが登録した買い物決済履歴として「AAレンタサイクル」の買い物決済履歴と「BBスーパー」の買い物決済履歴とが表示され、各々の買い物決済履歴と関連付けて、その買い物決済履歴の修正提案を行うためのチェックボックスが設けられている。この例では、「BBスーパー」の買い物決済履歴に関連付けられたチェックボックスのチェックがONとされた状態が示されている。
また、画面下部には、チェックボックスのチェックがONとされた買い物決済履歴について、その買い物決済金額の修正を提案するための、限定ではなく例として「金額修正提案」と示された金額修正提案アイコンと、その買い物決済履歴の取り下げを提案するための、限定ではなく例として「取り下げ提案」と示された取り下げ提案アイコンとが表示されている。
図17−3は、図17−2の買い物決済履歴修正提案画面において金額修正提案アイコンが操作されたことに基づいて表示される修正提案内容入力画面の一例を示す図である。
この修正提案内容入力画面には、「修正提案の内容を入力してください」の文字とともに、チェックボックスのチェックがONとされた「BBスーパー」の買い物決済履歴と、修正を提案する金額(以下、「修正提案金額」と称する。)を入力するための修正提案金額入力欄とが設けられている。修正提案金額入力欄には、上ボタンとした下ボタンとが関連付けて設けられており、上ボタンが操作されることで修正提案金額が増額され、下ボタンが操作されることで修正提案金額が減額されるように構成されている。
この例では、「BBスーパー」の買い物決済金額(修正買い物決済履歴)として、ユーザA.Aによって修正されたことを示す修正マークと、減額修正されたことを示す下三角形のマークと、修正された買い物決済金額である「2,400円」とが表示されている。また、ユーザB.Bによって入力された修正提案金額として「3,000円」が表示されている。
また、修正提案金額入力欄の下には、修正買い物決済履歴に対する修正提案コメントを入力するための修正提案コメント入力欄が設けられており、ユーザB.Bが修正提案コメントを入力することが可能に構成されている。この例では、「スーパーでの買い物代は3,000円だったと思います」という修正提案コメントが入力されている。つまり、ユーザB.Bによって、ユーザA.Aによって修正された買い物決済金額の「2,400円」は誤りで、本当は「3,000円」ではないかと異議を申し立てる修正提案コメントが入力された状態が示されている。
また、画面下部には、入力した内容で修正提案を行うための、限定ではなく例として「修正を提案」と示された修正提案実行アイコンが設けられている。
図17−4は、図17−3の修正提案内容入力画面において修正提案実行アイコンが操作されたことに基づいてユーザA.Aの端末20の表示部24に表示される画面の一例を示す図である。
この修正提案画面には、「B.Bさんから割り勘の修正提案がありました」の文字とともに、ユーザA.Aが登録した「B.Bスーパー」の修正買い物決済履歴の詳細とともに、ユーザB.Bによって修正提案された内容の詳細が表示されている。具体的には、ユーザB.Bのアイコン画像と関連付けて、修正提案があったことを示す「修正提案」の文字と、修正提案金額(この例では「3,000円」)とが表示されている。また、その下には、ユーザB.Bのアイコン画像およびユーザ名と関連付けて、ユーザB.Bによって入力された修正提案コメント(この例では「スーパーでの買い物代は3,000円だったと思います」)が表示されている。
また、画面下部には、上記の修正提案内容に対する回答のコメントを入力するための回答コメント入力欄が設けられており、この例では、ユーザA.Aによって「お土産の温泉まんじゅう代を引きました。」という回答コメントが入力された状態が示されている。この回答コメント入力欄の横には、入力された回答コメントをユーザB.Bの端末20に送信するための送信ボタンが設けられている。
図17−5は、図17−4の修正提案画面において送信ボタンが操作されたことに基づいてユーザB.Bの端末20の表示部24に表示される修正提案画面の一例を示す図である。
この修正提案画面には、自分が発信した修正提案コメントと、ユーザA.Aから発信された回答コメントとが表示されている。
また、図17−4の修正提案画面と同様に、画面下部には、回答コメント入力欄が設けられており、この例では、ユーザB.Bによって「みんなでシェアしたので、温泉まんじゅう代も割り勘にしましょう!」という回答コメントが入力された状態が示されている。この回答コメント入力欄の横には、入力された回答コメントをユーザA.Aの端末20に送信するための送信ボタンが設けられている。
図17−6は、図17−5の修正提案画面において送信ボタンが操作されたことに基づいてユーザA.Aの端末20の表示部24に表示される修正提案画面の一例を示す図である。
この修正提案画面には、ユーザB.Bから発信された回答コメントが表示されている。また、回答コメント入力欄には、ユーザA.Aによって「では、そうさせてもらいますね。」という回答コメントが入力された状態が示されている。
図17−7は、図17−6の修正提案画面において送信ボタンが操作されたことに基づいてユーザB.Bの端末20の表示部24に表示される修正提案画面の一例を示す図である。
この修正提案画面には、「B.Bスーパー」の買い物決済履歴と関連付けて、ユーザB.Bによって修正提案された内容の詳細の下に、ユーザA.Aによって修正提案が承諾されたことを示す「提案承諾」の文字と、買い物決済金額が増額修正されたことを示す上三角形のマークと、修正結果の金額(この例では「3,000円」)とが表示されている。
また、自分(ユーザB.B)が発信した回答コメントの下に、ユーザA.Aから発信された回答コメント(この例では「では、そうさせてもらいますね。」)が表示されている。
また、画面下部には、割り勘精算処理の結果として精算された金額(精算金額)を確認するための、限定ではなく例として「精算金額を確認する」と示された精算金額確認アイコンが表示されている。
図17−8は、図17−7の修正提案画面において精算金額確認アイコンが操作されたことに基づいてユーザB.Bの端末20の表示部24に表示される割り勘リクエスト通知画面の一例を示す図である。
この割り勘リクエスト通知画面では、過不足金額表示領域に、ユーザB.Bの過不足金額(この例では「3,500円 受取」)が表示されている。
図17−9は、図17−8の割り勘リクエスト通知画面において過不足金額表示領域が操作されたことに基づいて表示される画面の一例を示す図である。
図17−8の割り勘リクエスト通知画面において過不足金額表示領域が操作されると、ユーザB.Bが修正提案を行ったことに基づいて、ユーザB.Bの過不足金額が、当初の過不足金額に対して増加/減少のいずれに変化したかを示す情報が表示される。この例では、過不足金額表示領域において、過不足金額「3,500円 受取」の横に、ユーザB.Bが受け取る金額が減少したことを示す下三角形のマークが表示されている。
図17−10は、ユーザB.Bの端末20の表示部24に表示される買い物決済履歴選択画面の一例を示している。
この例では、ユーザB.Bが登録した買い物決済履歴として、「EEレストラン」の買い物決済履歴が表示されており、チェックボックスのチェックがONとされた状態が示されている。画面下部には、この買い物決済履歴の金額を修正するための金額修正アイコンと、この買い物決済履歴を割り勘対象から取り下げるための(この買い物決済履歴の登録を解除するための)取り下げアイコンとが表示されている。
図17−11は、図17−10の買い物決済履歴選択画面において取り下げアイコンが操作されたことに基づいてユーザB.Bの端末20の表示部24に表示される修正提案画面の一例を示す図である。
この修正提案画面では、ユーザB.Bが取り下げを希望する「EEレストラン」の買い物決済履歴とともに、ユーザB.Bによって入力されたコメントが表示されている。この例では、「旅行の日程を私に合わせてもらったので、レストランでの食事はおごります!」というコメントが表示されている。
<処理>
図17−12は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。
図17−12の処理は、図2−16〜図2−18の処理のうちの図2−18の処理部分において、端末Aの処理としてA540のステップを追加し、端末Bの処理としてA540のステップを追加し、サーバ10の処理としてS540〜S580のステップを追加した処理である。
なお、既出の処理と同一のステップについては同一の符号を付して再度の説明を省略する。
A210の後、端末Aの制御部21は、割り勘修正処理を実行する(A540)。同様に、B210の後、端末Bの制御部21は、割り勘修正処理を実行する(A540)。
図17−13は、割り勘修正処理の流れの一例を示すフローチャートである。
この処理は、図4−9の割り勘追加登録処理のA5320〜A5340のステップをA5420〜A5440にそれぞれ置き換えるとともに、A5370、A5380のステップをA5470、A5480のステップにそれぞれ置き換えた処理である。
A5310において割り勘に同意しないと判定した場合(A5310:NO)、制御部21は、割り勘内容を修正するための操作が入出力部23に対して入力されたか否かに基づいて、割り勘内容を修正するか否かを判定する(A5420)。割り勘内容を修正しないと判定したならば(A5420:NO)、制御部21は、A5350に処理を移す。
一方、割り勘内容を修正すると判定したならば(A5420:YES)、制御部21は、割り勘精算修正処理を実行する(A5430)。具体的には、入出力部23に対する修正操作に従って買い物決済履歴を修正する。この「修正」には、限定ではなく例として、買い物決済履歴の修正(または修正提案)をサーバ10に依頼するために、端末20側で修正対象・修正内容(または修正提案対象・修正提案内容)を決定することが含まれる。
その後、制御部21は、限定ではなく例として、修正対象(または修正提案対象)の買い物決済履歴の買い物決済IDと、修正内容(または修正提案内容)とを含む割り勘精算修正依頼通知を、通信I/F22によってサーバ10に送信する(A5440)。
次いで、制御部21は、通信I/F22によってサーバ10から割り勘修正確認通知を受信したか否かを判定し(A5470)、受信したと判定したならば(A5470:YES)、受信された割り勘精算確認通知を表示部24に表示した後(A5480)、A5310に処理を戻す。
一方、割り勘修正確認通知を受信しなかったと判定したならば(A5470:NO)、制御部21は、割り勘修正処理を終了する。
ここで、修正対象の買い物決済履歴が自己の端末20のユーザによる買い物決済履歴である場合は「修正」となるが、修正対象の買い物決済履歴が異なる端末20のユーザによる買い物決済履歴である場合は「修正提案」となる。
修正提案を行うユーザの端末20の制御部21は、A5430において、ユーザによって入力された修正提案内容を判定し、A5440において、修正提案対象の買い物決済履歴の買い物決済IDと、修正提案内容とを含む割り勘精算修正依頼通知をサーバ10に送信する。つまり、修正提案を行うユーザの端末20では、買い物決済履歴は修正されない。
割り勘精算修正依頼通知がサーバ10に送信されたことに基づき、サーバ10から割り勘修正確認通知が対象端末に送信されるが、この割り勘修正確認通知に基づいて、修正提案された端末20で、買い物決済履歴が修正される(A5470:YES→A5480→A5310:NO→A5420:YES、A5430)。
なお、これとは異なり、修正提案を行うユーザの端末20で、買い物決済履歴を修正できるようにしてもよいし、そのようにしなくてもよい。
図17−12に戻り、S210の後、サーバ10の制御部11は、第3の割り勘承認管理処理を実行する(S540)。
図17−14は、第3の割り勘承認管理処理の流れの一例を示すフローチャートである。
この処理は、第1の割り勘承認管理処理(図2−20参照)におけるS2310のステップをS5410に置き換えるとともに、S5420〜S5440のステップを追加した処理である。本処理において、割り勘精算通知は、前述した「割り勘精算承認通知」と、「割り勘精算拒否通知」と、「割り勘精算修正依頼通知」とのうちのいずれかの通知である。
なお、既出の処理と同一のステップについては同一の符号を付して再度の説明を省略する。
制御部11は、端末20から割り勘精算通知を受信すると(S5410)、受信された割り勘精算通知が「割り勘精算修正依頼通知」であるか否かを判定する(S5420)。受信された割り勘精算通知が割り勘精算修正依頼通知ではないと判定したならば(5420:NO)、制御部11は、S2320に処理を移す。
一方、受信された割り勘精算通知が割り勘精算修正依頼通知であると判定したならば(S5420:YES)、制御部11は、受信された割り勘精算修正依頼通知に含まれる買い物決済IDによって識別される買い物決済履歴について、同じく受信された割り勘精算修正依頼通知に含まれる修正内容に基づいて、過不足金額を計算(再計算)する(S5430)。
その後、制御部11は、計算した過不足金額に基づいて、割り勘内容を変更する(S5440)。この割り勘内容の変更の処理は、サーバ10の制御部11によって実行される第1決済情報を第2決済情報に修正する処理の一例とも言える。
そして、制御部11は、第3の割り勘承認管理処理を終了する。
図17−12に戻り、制御部11は、第3の割り勘承認管理処理で割り勘内容が変更されたか否かを判定し(S550)、変更されたと判定したならば(S550:YES)、割り勘修正確認通知を、通信I/F14によって端末Aおよび端末Bそれぞれに送信する(S580)。そして、制御部11は、S540に処理を戻す。
一方、第3の割り勘承認管理処理で割り勘内容が変更されなかったと判定したならば(S550:NO)、制御部11は、S240に処理を移す。
A540の後、端末Aの制御部21は、A250に処理を移す。同様に、A540の後、端末Bの制御部21は、B250に処理を移す。
<第17実施例の効果>
第17実施例は、一のユーザの端末20で修正された修正買い物決済履歴は、異なる端末20のユーザによる、この修正買い物決済履歴に対するコメントを含む構成を示している。
このような構成により得られる効果の一例として、異なる端末のユーザが、一の端末で修正された第2決済情報に対してコメントを付すことを可能とすることができる。
また、第17実施例は、一のユーザの端末20で修正された修正買い物決済履歴は、この修正買い物決済履歴を通信I/F22によってサーバ10に送信した後、異なる端末20のユーザの修正提案に基づいて修正される構成を示している。
このような構成により得られる効果の一例として、異なる端末のユーザが、一の端末で修正された第2決済情報を、この第2決済情報とは異なる第4決済情報にさらに修正することを可能とすることができる。
<第17変形例>
第17実施例では、修正提案があった場合に、各々の割り勘メンバーの端末20に、サーバ10から割り勘修正確認通知が送信されることとしたが、これに限定されない。具体的には、修正提案されたユーザの端末20に対してのみ、サーバ10から割り勘修正確認通知が送信されるようにしてもよいし、そのようにしなくてもよい。
また、修正/修正提案による買い物決済履歴の修正に伴い、損失が生ずる(損をする)ユーザの端末20に対して、サーバ10から割り勘修正確認通知が送信されるようにしてもよいし、そのようにしなくてもよい。
図17−15は、本変形例における過不足金額の変動を説明するための図であり、限定ではなく例として、操作種別と、操作内容と、過不足金額変動とを関連付けたテーブルを一例として示している。
操作種別は、買い物決済履歴の修正に関して操作者によって行われる操作であり、行われた操作が修正操作であることを示す「修正」と、行われた操作が修正提案操作であることを示す「修正提案」とがこれに含まれる。
操作内容は、その操作種別に従って、買い物決済履歴をどのように修正する操作が行われたかの内容である。
過不足金額変動は、各々の割り勘メンバーの過不足金額の変動であり、操作者の欄と、被操作者の欄と、その他割り勘メンバーの欄とがこれに含まれる。
操作者は、対応する操作種別の操作を行ったユーザである。
被操作者は、買い物決済履歴を登録したユーザである。操作種別「修正」は、操作者が自分の買い物決済履歴を修正する場合であるため、被操作者は存在しない。つまり、被操作者は、操作種別「修正提案」について、買い物決済履歴を登録したユーザであって、操作者によってその買い物決済履歴の修正提案を受けるユーザである。
その他割り勘メンバーは、割り勘メンバーのうち、操作者および被操作者を除外したユーザである。
過不足金額変動に含まれる各々の欄には、「増額」と、「減額」と、「増減なし(−)」とのうちのいずれかが定められている。
「増額」は、過不足金額の種別が「受取」である場合は、そのユーザが受け取る金額が増え、過不足金額の種別が「支払い」である場合は、そのユーザが支払う金額が減ることを意味している。
「減額」は、過不足金額の種別が「受取」である場合は、そのユーザが受け取る金額が減り、過不足金額の種別が「支払い」である場合は、そのユーザが支払う金額が増えることを意味している。
(1)操作種別「修正」
操作種別「修正」には、2種類の操作内容が定められている。
1つ目の操作内容は「買い物決済履歴追加/買い物決済金額上方修正」であり、これは、買い物決済履歴を追加する操作、または、買い物決済金額を上方修正する操作を意味する。
この場合、過不足金額変動として、操作者には「増額」が、その他割り勘メンバーには「減額」がそれぞれ定められている。
2つ目の操作内容は「買い物決済履歴取り下げ/買い物決済金額下方修正」であり、これは、買い物決済履歴を取り下げる操作、または、買い物決済金額を下方修正する操作を意味する。
この場合、過不足金額変動として、操作者には「減額」が、その他割り勘メンバーには「増額」がそれぞれ定められている。
(2)操作種別「修正提案」
操作種別「修正提案」にも、2種類の操作内容が定められている。
1つ目の操作内容は「買い物決済履歴追加提案/買い物決済金額上方修正提案」であり、これは、買い物決済履歴を追加する提案操作、または、買い物決済金額を上方修正する提案操作を意味する。
この場合、過不足金額変動として、操作者には「減額」が、被操作者には「増額」が、その他割り勘メンバーには「減額」がそれぞれ定められている。
2つ目の操作内容は「買い物決済履歴取り下げ提案/買い物決済金額下方修正提案」であり、これは、買い物決済履歴を取り下げる提案操作、または、買い物決済金額を下方修正する提案操作を意味する。
この場合、過不足金額変動として、操作者には「増額」が、被操作者には「減額」が、その他割り勘メンバーには「増額」がそれぞれ定められている。
図17−16は、本変形例における割り勘修正確認通知の送信の要否を説明するための図であり、限定ではなく例として、操作種別と、操作内容と、割り勘修正確認通知送信要否とを関連付けたテーブルを一例として示している。
操作種別および操作内容は、図17−15のテーブルにそれぞれ対応している。
割り勘修正確認通知送信要否は、割り勘修正確認通知のサーバ10からの送信の要否であり、被操作者と、その他割り勘メンバーとがこれに含まれる。割り勘修正確認通知の送信が必要であるユーザ(そのユーザの端末20)には「要」が、割り勘修正確認通知の送信が不要であるユーザ(そのユーザの端末20)には「不要」がそれぞれ定められている。
(1)操作種別「修正」
操作内容「買い物決済履歴追加/買い物決済金額上方修正」において、割り勘修正確認通知送信要否のうち、その他割り勘メンバーには「要」が定められている。これは、図17−15のテーブルに示したように、この操作内容では、その他割り勘メンバーの過不足金額変動は「減額」であり、修正によって、その他割り勘メンバーが受け取る金額が減る、またはその他割り勘メンバーが支払う金額が増えることになる。これは、言うなれば、修正によって、その他割り勘メンバーは損をする(損失がある)ことになる。このため、割り勘修正確認通知の送信を「要」とし、修正を行うためには、その他割り勘メンバーの許可が必要となるようにしている。
操作内容「買い物決済履歴取り下げ/買い物決済金額下方修正」において、割り勘修正確認通知送信要否のうち、その他割り勘メンバーには「不要」が定められている。これは、図17−15のテーブルに示したように、この操作内容では、その他割り勘メンバーの過不足金額変動は「増額」であり、修正によって、その他割り勘メンバーが受け取る金額が増える、またはその他割り勘メンバーが支払う金額が減ることになる。これは、言うなれば、修正によって、その他割り勘メンバーは得をすることになる。このため、割り勘修正確認通知の送信を「不要」とし、修正を行うために、その他割り勘メンバーの許可が不要となるようにしている。
(2)操作種別「修正提案」
操作内容「買い物決済履歴追加提案/買い物決済金額上方修正提案」において、割り勘修正確認通知送信要否のうち、被操作者には「不要」が、その他割り勘メンバーには「要」がそれぞれ定められている。これは、図17−15のテーブルに示したように、この操作内容では、被操作者の過不足金額変動は「増額」であり、修正によって得をすることになるが、その他割り勘メンバーの過不足金額変動は「減額」であり、修正によって損をすることになるためである。
操作内容「買い物決済履歴取り下げ提案/買い物決済金額下方修正提案」において、割り勘修正確認通知送信要否のうち、被操作者には「要」が、その他割り勘メンバーには「不要」がそれぞれ定められている。これは、図17−15のテーブルに示したように、この操作内容では、被操作者の過不足金額変動は「減額」であり、修正によって損をすることになるが、その他割り勘メンバーの過不足金額変動は「増額」であり、修正によって得をすることになるためである。
この場合、サーバ10の制御部11は、図17−12の処理のS580において、割り勘修正確認通知を送信する必要あり(「要」)と判定された端末20を対象端末として、対象端末にのみ割り勘修正確認通知を送信する。つまり、割り勘修正確認通知を送信する必要なし(「不要」)と判定された端末20は、対象端末から除外され、この端末20には割り勘修正確認通知が送信されない。
このようにすることで、割り勘修正確認通知を送信する必要あり(「要」)と判定された端末20には、サーバ10から割り勘修正確認通知が送信され、その端末20において割り勘修正処理が実行される(図17−12のS580→A540)。この場合、割り勘修正処理(図17−13参照)において、その端末20のユーザが修正内容に同意し、結果的に割り勘に同意すると判定された場合は(図17−13のA5310:YES)、割り勘精算承認通知が端末20からサーバ10に送信されることになる(図17−13のA5360)。一方、その端末20のユーザが修正内容に同意せず、結果的に割り勘に同意しないと判定された場合は(図17−13のA5310:NO、A5420:NO)、割り勘精算拒否通知が端末20からサーバ10に送信されることになる(図17−13のA5350)。
その一方、割り勘修正確認通知を送信する必要なし(「不要」)と判定された端末20には、サーバ10から割り勘修正確認通知が送信されないため、その端末20において割り勘修正処理は実行されない。このため、その端末20において、修正内容に同意するか否かの確認は行われない。
本変形例は、修正買い物決済履歴は、異なる端末20のユーザによる修正の許可に基づいて修正される構成を示している。
このような構成により得られる効果の一例として、異なる端末のユーザによる修正の許可がなければ、第1決済情報が第2決済情報に修正されないため、異なる端末のユーザに不利益が生ずることを防止できる。
また、本変形例は、異なる端末20のユーザによって修正された修正買い物決済履歴は、自己の端末20のユーザによる修正の許可に基づいて、さらに修正される構成を示している。
このような構成により得られる効果の一例として、端末のユーザによる修正の許可がなければ、第2決済情報が第4決済情報に修正されないため、端末のユーザに不利益が生ずることを防止できる。
<第18実施例>
第18実施例は、端末20が、選択した買い物決済履歴に基づいて第1送金処理/第1受取処理を行った後に、その買い物決済履歴が修正され、この修正された買い物決済履歴に基づいて、第2送金処理/第2受取処理を実行する実施例である。選択した買い物決済履歴に基づいて一旦割り勘を行ったものの、ユーザが後から間違いに気づくような場合がある。
第18実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
<処理>
図18−1は、本実施例において端末20が実行する割り勘処理の流れの一例を示すフローチャートである。
この処理は、図1の処理に、端末Aの処理としてA65〜A75のステップを追加し、端末Bの処理としてB75のステップを追加した処理である。
A60の後、端末Aの制御部21は、入出力部23に対して買い物決済履歴の修正を要求する操作が入力されたか否かに基づいて、A10で選択した買い物決済履歴について修正を行うか否かを判定する(A65)。修正を行うと判定したならば(A65:YES)、端末Aの制御部21は、買い物決済履歴修正処理を実行する(A70)。具体的には、限定ではなく例として、入出力部23に対する修正操作に基づいて、A10で選択した買い物決済履歴を修正する。
その後、端末Aの制御部21は、買い物決済履歴の修正内容を含む買い物決済履歴修正情報を、通信I/F22によって端末Bに送信する(A75)。そして、端末Aの制御部21は、A40に処理を戻す。
この場合、買い物決済履歴修正情報には、限定ではなく例として、修正前の買い物決済金額と修正後の買い物決済金額との差額の情報を含めるようにすることができる。
そして、この場合、端末Bの制御部21は、端末Aから受信された買い物決済履歴修正情報に基づいて、修正前の買い物決済金額と修正後の買い物決済金額との差額から、端末20のユーザが追加で送金すべき金額、または端末20のユーザが追加で受け取るべき金額を計算するようにすることができる。
なお、これとは異なり、限定ではなく例として、修正後の買い物決済金額の情報を買い物決済履歴修正情報に含めるようにし、修正後の買い物決済金額に基づいて割り勘精算処理を実行するようにしてもよいし、そのようにしなくてもよい。
この場合は、限定ではなく例として、修正前の買い物決済金額に基づく割り勘精算処理で金額を受け取ったユーザから金額を回収し、金額を支払ったユーザに返金するなどして、割り勘精算を行う前の状態に戻す処理(ロールバック処理、リセット処理)を実行する。そして、修正後の買い物決済金額に基づく割り勘精算処理を実行するようにしてもよいし、そのようにしなくてもよい。
B60の後、端末Bの制御部21は、通信I/F22によって端末Aから買い物決済履歴修正情報を受信したか否かを判定し(B75)、受信したと判定したならば(B75:YES)、B30に処理を戻す。
A65において修正を行わないと判定したならば(A65:NO)、端末Aの制御部21は、割り勘処理を終了する。
また、B75において買い物決済履歴修正情報を受信しなかったと判定したならば(B75:NO)、端末Bの制御部21は、割り勘処理を終了する。
<第18実施例の効果>
第18実施例は、端末20は、自己の端末20のユーザによる自己の端末20に対する入力に基づいて、自己の端末20のユーザによる買い物決済情報を通信I/F22によって異なる端末20に送信する。端末20は、少なくとも自己の端末20の過不足金額の情報を通信I/F22によって異なる端末20から受信する。端末20は、受信された過不足金額に基づく割り勘精算処理(割り勘精算処理)(限定ではなく、第1送金処理、または第1受取処理の一例)を制御部21によって実行する。そして、上記の買い物決済情報が修正された場合、端末20は、修正買い物決済履歴に基づいて、割り勘精算処理(限定ではなく、第2送金処理、または第2受取処理の一例)を制御部21によって実行する構成を示している。
このような構成により得られる効果の一例として、第1金額に基づく第1送金処理、または第1受取処理を実行した後、第1決済情報から第2決済情報に修正された場合であっても、第2送金処理、または第2受取処理を実行して、精算した金額を事後的に調整することができる。
また、第18実施例は、端末20は、メモリに記憶されたプログラムを読み出し、読み出したプログラムに基づく処理を実行するプロセッサを備える。プロセッサは、自己の端末20のユーザによる自己の端末20に対する入力に基づいて、自己の端末20のユーザによる買い物決済情報を通信I/F22によって異なる端末20に送信することと、少なくとも自己の端末20の過不足金額の情報を通信I/F22によって異なる端末20から受信することと、受信された過不足金額に基づく割り勘精算処理(割り勘精算処理)(限定ではなく、第1送金処理、または第1受取処理の一例)を実行することと、上記の買い物決済情報が修正された場合、修正買い物決済履歴に基づいて、割り勘精算処理(限定ではなく、第2送金処理、または第2受取処理の一例)を実行する構成を示している。
このような構成によっても、上記と同様の効果を得ることができる。
また、第18実施例は、買い物決済履歴を修正した後の割り勘精算処理(限定ではなく、第2送金処理、または第2受取処理の一例)は、修正買い物決済履歴の買い物決済金額と元買い物決済履歴の買い物決済金額との差額に基づいて実行される構成を示している。
このような構成により得られる効果の一例として、第2決済情報と第1決済情報との差額に基づき、精算した金額を事後的に正しく調整することができる。
<第18変形例>
第18実施例において割り勘精算を行う際に、異なる端末20、または異なる端末20のユーザの許可を必要としてもよいし、そのようにしなくてもよい。
図18−2は、本変形例において端末20が実行する割り勘処理の流れの別例を示すフローチャートである。
この処理は、図1の処理に、端末Aの処理としてA80〜A86のステップを追加し、端末Bの処理としてB80〜B86のステップを追加した処理である。
A60の後、端末Aの制御部21は、買い物決済履歴の事後修正を行うか否かを判定する(A80)。事後修正を行わないと判定したならば(A80:NO)、端末Aの制御部21は、A90に処理を移す。
一方、事後修正を行うと判定したならば(A80:YES)、端末Aの制御部21は、買い物決済履歴修正処理を実行する(A82)。そして、端末Aの制御部21は、買い物決済履歴修正情報を、通信I/F22によって端末Bに送信する。
B60の後、端末Bの制御部21は、通信I/F22によって端末Aから買い物決済履歴修正情報を受信したか否かを判定する(B80)。受信しなかったと判定したならば(B80:NO)、端末Bの制御部21は、B90に処理を移す。
一方、買い物決済履歴修正情報を受信したと判定したならば(B80:YES)、端末Bの制御部21は、その買い物決済履歴修正情報に基づき、自己の端末20のユーザが修正に同意したか否かを判定する(B82)。
修正に同意したと判定したならば(B82:YES)、端末Bの制御部21は、B40に処理を戻す。一方、修正に同意しなかったと判定したならば(B82:NO)、端末Bの制御部21は、修正拒否通知を通信I/F22によって端末Aに送信する(B86)。そして、端末Bの制御部21は、B90に処理を移す。
A84の後、端末Aの制御部21は、通信I/F22によって端末Bから修正拒否通知を受信したか否かを判定する(A86)。受信しなかったと判定したならば(A86:NO)、端末Aの制御部21は、A40に処理を戻す。
一方、修正拒否通知を受信したと判定したならば(A86:YES)、端末Aの制御部21は、A90に処理を移す。
本変形例は、買い物決済履歴の修正後の割り勘精算処理は、異なる端末20から修正拒否通知を受信しない場合に実行される構成を示している。
このような構成により得られる効果の一例として、異なる端末、または異なる端末のユーザの許可に基づいて、精算金額を事後的に調整することができる。
なお、上記の処理において、修正買い物決済履歴が、元買い物決済履歴よりも買い物決済金額が減額されるように修正されたものである場合、異なる端末20、または異なる端末20のユーザによる許可なく、端末20の制御部21が、割り勘精算処理を実行するようにしてもよいし、そのようにしなくてもよい。
限定ではなく例として、割り勘マスターによって、元買い物決済履歴よりも買い物決済金額が減額されるように修正された場合、他の割り勘メンバーには、その割り勘メンバーが最初に送金した金額のうちの一部の金額が返金されることになる。言うなれば、他の割り勘メンバーは得をすることになるため、割り勘精算に許可は不要と考えられる。
一方、限定ではなく例として、割り勘マスター以外の割り勘メンバーによって、元買い物決済履歴よりも買い物決済金額が減額されるように修正された場合は、その割り勘メンバーの意思で買い物決済履歴が修正されたことになる。このため、この場合も、割り勘精算に許可は不要と考えられる。
本変形例は、買い物決済履歴の修正後の割り勘精算処理は、修正買い物決済履歴が元買い物決済履歴よりも決済金額が減額された場合、異なる端末20、または異なる端末20のユーザの許可なく実行される構成を示している。
このような構成により得られる効果の一例として、第1決済情報の修正によって異なる端末のユーザが金額的に得をする場合や、異なる端末のユーザに金額的な損失がない場合に、異なる端末、または異なる端末のユーザの許可を不要として第2送金処理、または第2受取処理を行うことができる。
<第19実施例>
第19実施例は、端末20がサーバ10と通信を行って、修正した買い物決済履歴に基づく精算金額の事後的な調整を行う実施例である。
第19実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
<処理>
図19は、本実施例において各装置が実行する処理の流れの一例を示すフローチャートである。
この処理は、図2−19の処理部分におけるA350、B350、S340から開始される処理であり、割り勘精算が実行された後に、割り勘修正処理を実行する処理である。
この処理では、A350の後、端末Aの制御部21は、割り勘修正処理を実行する(A540)。この割り勘修正処理は、図17−13と同じである。
同様に、B350の後、端末Bの制御部21は、割り勘修正処理を実行する(A540)。
一方、S340の後、サーバ10の制御部11は、第3の割り勘承認管理処理を実行する(S540)。この第3の割り勘承認管理処理は、図17−14と同じである。
割り勘内容が変更されなかったと判定したならば(S550:NO)、制御部11は、割り勘修正が成立したか否かを判定する(S960)。割り勘修正が成立したと判定したならば(S960:YES)、制御部11は、図2−19のS310に処理を移す。
一方、割り勘修正が成立しなかったと判定したならば(S960:NO)、制御部11は、割り勘修正が成立しなかったことを通知するための割り勘修正不成立通知を、通信I/F14によって対象端末(この例では端末Aおよび端末B)それぞれに送信する(S970)。そして、制御部11は、S390に処理を移す。
A540の後、端末Aの制御部21は、通信I/F22によってサーバ10から割り勘修正不成立通知を受信したか否かを判定し(A970)、受信しなかったと判定したならば(A970:NO)、図2−19のA310に処理を移す。
一方、割り勘修正不成立通知を受信したと判定したならば(A970:YES)、端末Aの制御部21は、受信された割り勘修正不成立通知を表示部24に表示させる(A980)。そして、端末Aの制御部21は、A390に処理を移す。
A540の後、端末Bも、同様の処理を行う(B970、B980)。
<第19実施例の効果>
第19実施例は、端末20が、元買い物決済履歴に基づく、自己の端末20のユーザの過不足金額(限定ではなく、第3金額の一例)と、自己の端末20とは異なる端末20のユーザを含む複数の端末20の各々のユーザの過不足金額とのうち、少なくとも自己の端末20のユーザの過不足金額の情報を通信I/F22によってサーバ10から受信する。端末20は、受信された過不足金額に基づき、割り勘精算要求処理や割り勘精算結果受信処理(限定ではなく、第3金額に基づく第3送金処理、または第3受取処理の一例)を制御部21によって実行する。元買い物決済履歴が修正された場合、端末20は、修正買い物決済履歴に基づいて、割り勘精算要求処理や割り勘精算結果受信処理(限定ではなく、第4送金処理、または第4受取処理の一例)を制御部21によって実行する。そして、修正買い物決済履歴に基づく割り勘精算要求処理は、複数の端末20の各々のユーザの許可に基づいて実行される。
このような構成により得られる効果の一例として、異なる端末のユーザを含む複数の端末の各々のユーザの許可に基づいて、精算金額を事後的に調整することができる。
また、第19実施例は、端末20のユーザによる買い物決済履歴は、異なる端末20のユーザによって修正提案(限定ではなく、修正依頼の一例)される構成を示している。
このような構成により得られる効果の一例として、異なる端末のユーザによる修正依頼に基づいて、第1決済情報を第2決済情報に修正することができる。
また、第19実施例は、割り勘精算処理は、端末20から送信される割り勘精算承認通知(限定ではなく、端末のユーザの許可の一例)と、異なる端末20から送信される割り勘精算承認通知(限定ではなく、異なる端末のユーザの許可の一例)とに少なくとも基づいて、サーバ10によって実行される構成を示している。
このような構成により得られる効果の一例として、端末のユーザの許可と、異なる端末のユーザの許可とに少なくとも基づいて、第1送金処理、または第1受取処理が実行されるため、少なくとも端末のユーザと異なる端末のユーザとの同意なく、第1送金処理、または第1受取処理が実行されないようにすることができる。
また、第19実施例は、サーバ10が、端末20のユーザによる端末20に対する入力に基づいて、端末20のユーザによる買い物決済履歴を通信I/F14によって端末20から受信する。サーバ10は、受信された買い物決済履歴に基づく、少なくとも端末20のユーザの過不足金額(限定ではなく、第1金額の一例)の情報を端末20に通信I/F14によって送信し、少なくとも異なる端末20のユーザの過不足金額(限定ではなく、第2金額の一例)の情報を異なる端末20に通信I/F14によって送信する。サーバ10は、割り勘精算処理(限定ではなく、第1金額に基づく、端末に対する第1送金処理、または第1受取処理と、第2金額に基づく、異なる端末に対する第2送金処理、または第2受取処理との一例)を制御部11によって実行する。また、サーバ10は、割り勘精算修正依頼通知(限定ではなく、第1決済情報から第2決済情報に修正することに関する情報の一例)を通信I/F14によって端末20から受信する。そして、サーバ10は、買い物決済履歴(限定ではなく、第1決済情報の一例)が修正された場合、修正買い物決済履歴(限定ではなく、第2決済情報の一例)に基づいて、割り勘精算処理(限定ではなく、端末に対する第3送金処理、または第3受取処理と、異なる端末に対する第4送金処理、または第4受取処理との一例)を制御部11によって実行する構成を示している。
このような構成により得られる効果の一例として、第1金額に基づく第1送金処理、または第1受取処理を実行した後、第1決済情報から第2決済情報に修正された場合であっても、第2送金処理、または第2受取処理を実行して、精算した金額を事後的に調整することができる。また、端末でこれらの処理を実行せずに済むため、端末の処理負荷を軽減することができる。
<第19変形例>
第19実施例において、各々の割り勘メンバーのうち、買い物決済履歴が修正されることで損失があるユーザの許可を必要として、精算金額を事後的に調整するようにしてもよいし、そのようにしなくてもよい。
この場合は、図17−15および図17−16で説明した手法を同様の手法によって、割り勘修正確認通知送信要否を判定する。そして、サーバ10の制御部11は、図19の処理のS580において、割り勘修正確認通知を送信する必要あり(「要」)と判定された端末20を対象端末とし、対象端末にのみ割り勘修正確認通知を送信する。これは、前述した通りである。
本変形例は、割り勘精算要求処理は、自己の端末20とは異なる端末20のユーザを含む複数の端末20の各々のユーザのうち、元買い物決済履歴が修正されることで損失があるユーザの許可に基づいて実行される構成を示している。
このような構成により得られる効果の一例として、第4送金処理、または第4受取処理が、端末とは異なる端末のユーザを含む複数の端末の各々のユーザのうち、第1決済情報から第2決済情報に修正されることで損失があるユーザの許可に基づいて実行されるようにすることで、損失があるユーザの確認を求めることができる。
<第20実施例>
第20実施例は、自己の端末20のユーザによる買い物決済履歴と、異なる端末20のユーザによる買い物決済履歴とに基づく割り勘精算が行われた後、異なる端末20のユーザによる買い物決済履歴を修正提案によって修正する実施例である。
第20実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
先の実施例で説明したように、本開示の手法によれば、一の端末20のユーザによる買い物決済履歴に加えて、異なる端末20のユーザの買い物決済履歴も、一緒に割り勘対象に含めることができる。この場合、一の端末20のユーザによって登録された買い物決済履歴の買い物決済金額と、異なる端末20のユーザによって登録された買い物決済履歴の買い物決済金額とに基づいて、サーバ10によって過不足金額が計算されることになる。
図20は、本実施例において端末20からサーバ10に送信される割り勘精算通知種別を説明するための図であり、操作種別と、精算種別と、割り勘精算通知種別とが関連付けられたテーブルを示している。
操作種別には、「修正」と「修正提案」とが含まれる。
精算種別には、「元精算」と「事後精算」とが含まれる。
「元精算」は、おおもとの割り勘精算(1回目の割り勘精算)である。第1送金処理、または第1受取処理を実行することが、これに相当する。
「事後精算」は、先の割り勘精算で精算された金額を事後的に調整する精算(2回目以降の精算)である。前述したように、第1送金処理、または第1受取処理を実行した後、第1決済情報から第2決済情報に修正されたことに基づき、第2送金処理、または第2受取処理を実行することが、これに相当する。
割り勘精算通知種別には、図17−13の割り勘修正処理で端末20がサーバ10に送信する割り勘精算通知の種別が定められている。
このテーブルによれば、操作種別「修正」、「修正提案」のいずれであるかに依らず、また、精算種別「元精算」、「事後精算」のいずれであるかに依らず、割り勘精算通知種別として「割り勘精算修正依頼通知」が定められている。つまり、修正と修正提案とのいずれを行う場合であっても、また、元精算と事後精算とのいずれを行う場合であっても、割り勘精算通知として割り勘精算修正依頼通知を端末20からサーバ10に送信することが定められている。
本実施例では、上記のようにして計算された過不足金額に基づき、サーバ10によって割り勘精算処理が実行される。その後、限定ではなく例として、端末20の制御部21は、自己の端末20のユーザによって、異なる端末20のユーザによって登録された買い物決済履歴の「修正提案」を行う操作がなされた場合、図17−13の割り勘修正処理において、上記のように割り勘精算修正依頼通知を通信I/F22によってサーバ10に送信する。
なお、上記とは異なり、操作種別「修正」と、操作種別「修正提案」とで、異なる種別の割り勘精算通知を端末20からサーバ10に送信するようにしてもよいし、そのようにしなくてもよい。
同様に、精算種別「元精算」と、精算種別「事後精算」とで、異なる種別の割り勘精算通知を端末20からサーバ10に送信するようにしてもよいし、そのようにしなくてもよい。
<第20実施例の効果>
第20実施例は、端末20は、自己の端末20のユーザによる買い物決済履歴(限定ではなく、第1決済情報の一例)と、異なる端末20のユーザによる買い物決済履歴(限定ではなく、異なる端末のユーザによる第2決済に関する処理に基づく第3決済情報の一例)とに基づく、自己の端末20のユーザの過不足金額(限定ではなく、第5金額の一例)と、異なる端末20のユーザの過不足金額(限定ではなく、第6金額の一例)とのうち、少なくとも自己の端末20のユーザの過不足金額の情報を通信I/F22によって受信する。端末20は、受信された自己の端末20のユーザの過不足金額に基づく割り勘精算要求処理や割り勘精算結果受信処理を制御部21によって実行する。そして、端末20は、異なる端末20のユーザによる買い物決済履歴の修正依頼を求める割り勘精算修正依頼通知(限定ではなく、第3決済情報から第4決済情報に修正することに関する情報の一例)を通信I/F22によってサーバ10に送信する構成を示している。
このような構成により得られる効果の一例として、端末のユーザによる第1決済に関する処理に基づく第1決済情報と、異なる端末のユーザによる第2決済に関する処理に基づく第3決済情報とに基づき、第5送金処理、または第5受取処理を実行した後、限定ではなく例として、第3決済情報から第4決済情報に修正することを、異なる端末のユーザに提案することができる。
また、第20実施例は、端末20が、異なる端末20のユーザによる買い物決済履歴(限定ではなく、第3決済情報の一例)が修正された場合、この修正された買い物決済履歴(限定ではなく、第4決済情報の一例)に基づいて、割り勘精算要求処理や割り勘精算結果受信処理(限定ではなく、第6送金処理、または第6受取処理の一例)を制御部21によって実行する構成を示している。
このような構成により得られる効果の一例として、第3決済情報から第4決済情報に修正された場合、第4決済情報に基づいて、第6送金処理、または第6受取処理を制御部によって実行することで、一旦精算を行った後に異なる端末のユーザによる決済情報が修正された場合であっても、精算金額を事後的に調整することができる。
<第21実施例>
第21実施例は、端末20が、自己の端末20のユーザによる買い物決済履歴について割り勘精算が行われた後、自己の端末20のユーザによる買い物決済履歴を修正し、その修正内容に基づいて、精算金額を事後的に調整する実施例である。
第21実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
<表示画面例>
図21−1は、本実施例におけるメッセージングアプリケーションのトークルーム画面に表示される割り勘完了通知の一例を示す図であり、ユーザA.Aの端末20の表示部24に表示される画面の一例を示している。
このトークルーム画面には、ユーザB.Bが割り勘精算を行うことに同意したことに基づいて、ユーザB.BからユーザA.Aに過不足金額(この例では「2,250円)が送金され、その結果として、割り勘が完了したことを示す割り勘完了通知のメッセージが表示されている。
割り勘完了通知のメッセージには、限定ではなく例として、精算結果とともに、精算内容を修正するための、限定ではなく例として「精算内容の修正」と示された精算内容修正アイコンが含まれる。
図21−2は、図21−1において精算内容修正アイコンが操作されたことに基づいてユーザA.Aの端末20の表示部24に表示される精算内容修正画面の一例を示す図である。
この精算内容修正画面には、限定ではなく例として、「割り勘の精算内容を確認してください」の文字が表示され、その下に、ユーザA.AおよびユーザB.Bそれぞれの支払い済み金額が表示される支払い済み金額一覧表示領域と、ユーザA.AおよびユーザB.Bそれぞれの精算金額が表示される精算金額一覧表示領域とが設けられている。
この例では、ユーザA.Aの支払い済み金額として「4,500円」が、ユーザB.Bの支払い済み金額として「0円」がそれぞれ表示されている。また、ユーザA.AおよびユーザB.Bの精算金額として、それぞれ「2,250円」が表示されている。
支払い済み金額表示領域において、ユーザA.Aの欄には、ユーザA.Aの支払い済み金額に対してユーザA.Aが修正を行うための「修正」と示された修正アイコンが表示されている。また、ユーザB.Bの欄には、ユーザB.Bの支払い済み金額に対してユーザA.Aが修正提案を行うための「修正提案」と示された修正提案アイコンが表示されている。
図21−3は、図21−2においてユーザA.Aが修正アイコンを操作したことに基づいて表示される修正対象買い物決済履歴選択画面の一例を示す図である。
この修正対象買い物決済履歴選択画面は、ユーザA.Aが修正対象とする買い物決済履歴を選択するための画面であり、ユーザA.Aが登録済みの買い物決済履歴として、「AAレンタサイクル」の買い物決済履歴と、「BBスーパー」の買い物決済履歴とが表示されている。また、この例では、ユーザA.Aによって、「BBスーパー」に関連付けられたチェックボックスのチェックが「ON」とされた状態が示されている。
画面下部には、買い物決済履歴を追加して登録するため「支払い分を追加」と示された買い物決済履歴追加アイコンと、修正対象として選択された買い物決済履歴の買い物決済金額を修正するための「金額修正」と示された金額修正アイコンと、登録済みの買い物決済履歴を取り下げるための「取り下げ」と示された取り下げアイコンとが表示されている。この例では、ユーザA.Aによって金額修正アイコンが操作された状態が示されている。
図21−4は、この例においてユーザB.Bの端末20の表示部24に表示されるトークルーム画面の一例を示す図である。
このトークルーム画面では、画面向かって左側に、ユーザA.Aからのメッセージとして、精算済みの買い物決済履歴を事後的に修正したことを示すメッセージが表示されている。この例では、ユーザA.Aによる「BBスーパー」の買い物決済履歴のうち、購入された商品である温泉まんじゅうの代金を減額する修正が行われたことが示されている。
具体的には、「BBスーパー」の買い物決済履歴における買い物決済金額が「3,000円→2,400円」に減額され、これにより、「AAレンタサイクル」の買い物決済履歴の買い物決済金額「1,500円」との合計金額が、「4,500円→3,900円」に減額されている。そして、その結果、1人あたり金額が「2,250円→1,950円」に減額されたことが示されている。ユーザB.Bは、ユーザA.Aに「2,250円」を送金済みであるが、この修正にユーザB.Bが承諾すると、差額である「300円」がユーザA.AからユーザB.Bに返金されることになる。このため、ユーザB.Bの過不足金額として「300円 受取」が表示されている。
また、メッセージの下部には、上記の修正を承諾するための、限定ではなく例として「承諾する」と示された承諾アイコンと、上記の修正を却下するための、限定ではなく例として「却下する」と示された却下アイコンとが表示されている。
図21−5は、図21−4のトークルーム画面においてユーザB.Bによって承諾アイコンが操作されたことに基づいてユーザB.Bの端末20の表示部24に表示されるトークルーム画面の一例を示す図である。
承諾アイコンが操作されたことに基づいて、「承諾する」というメッセージがユーザA.Aの端末20に送信される。そして、ユーザA.Aが自分の端末20で精算を実行する操作を行ったことに基づき、ユーザA.Aの端末20から「精算する」というメッセージがユーザB.Bの端末20に送信されて表示される。その後、ユーザA.Aの端末20からユーザB.Bの端末20に、修正に伴うユーザB.Bの過不足金額(この例では「300円」)が送金され、その結果、「A.Aさんから300円を受け取りました」という文字を含む受取完了通知が表示される。また、その下には、買い物決済履歴の修正に伴う、割り勘精算結果が表示される。
<処理>
この場合の処理の流れについて、図19の処理等を参照して説明する。本処理は、限定ではなく例として、図19の処理に、メッセージングサーバ40の処理を追加することによって実現される。
割り勘の精算が完了した後、サーバ10が、割り勘精算結果をメッセージングサーバ40に送信する(図19のS340に相当)。そして、メッセージングサーバ40が、サーバ10から受信された割り勘精算結果を端末Aおよび端末Bに送信する。
買い物決済履歴を登録した端末Aの制御部21は、メッセージングサーバ40から受信された割り勘精算結果を、メッセージングアプリケーションのトークルームに表示させる(図19のA350に相当)。
その後、端末Aの制御部21は、限定ではなく例として、ユーザA.Aによって精算内容を修正する操作が入出力部23に対して入力されたことに基づいて、割り勘修正処理を実行する(図19のA540に相当)。そして、制御部21は、割り勘精算修正依頼通知を、メッセージングサーバ40を介してサーバ10に送信する(図17−13のA5440に相当)。
この場合、サーバ10は、第3の割り勘承認管理処理を実行する(図19のS540に相当)。この例では、ユーザA.Aによって精算内容が修正されたため(図19のS550:YESに相当)、サーバ10は、割り勘修正確認通知を、メッセージングサーバ40を介して端末Aおよび端末Bに送信する(図19のS580に相当)。
端末Bの制御部21は、メッセージングサーバ40から受信された割り勘修正確認通知を、メッセージングアプリケーションのトークルームに表示させる。そして、端末Bの制御部21は、ユーザB.Bによって、ユーザA.Aによる修正を承認してその内容で割り勘に同意する操作が入出力部23に入力されたことに基づいて、割り勘精算承認通知を、メッセージングサーバ40を介してサーバ10に送信する(図17−13のA5360)。
これにより、サーバ10の制御部11は、ユーザB.Bによって割り勘に同意されたと判定し、割り勘精算処理を実行する(図2−19のS330に相当)。そして、制御部11は、割り勘精算結果を、メッセージングサーバ40を介して端末Aおよび端末Bに送信する(図2−19のS340に相当)。
端末Aの制御部21は、メッセージングサーバ40から受信された割り勘精算結果を、メッセージングアプリケーションのトークルームに表示させる(図2−19のA340、A350に相当)。
同様に、端末Bの制御部21は、メッセージングサーバ40から受信された割り勘精算結果を、メッセージングアプリケーションのトークルームに表示させる(図2−19のB340、B350に相当)。
なお、上記では、メッセージングアプリケーションを利用して、端末20が、自己の端末20のユーザによる買い物決済履歴を修正し、その修正に基づいて、精算金額を事後的に調整することとしたが、メッセージングアプリケーションは必須ではなく、メッセージングアプリケーションおよびメッセージングサーバ40を構成要件から除外してもよいし、除外しなくてもよい。
<第21実施例の効果>
第21実施例は、端末20が、割り勘完了通知(限定ではなく、第1送金処理、または第1受取処理の完了に関する通知の一例)を表示部24に表示する構成を示している。
このような構成により得られる効果の一例として、端末は、第1送金処理、または第1受取処理が完了したことを端末のユーザに報知することができる。
また、第21実施例は、端末20は、表示した割り勘完了通知に対する自己の端末20のユーザの操作に基づいて、元買い物決済履歴を修正することに関する処理を制御部21によって実行する構成を示している。
このような構成により得られる効果の一例として、第1送金処理、または第1受取処理の完了に関する通知に対する入力を行うことで、端末のユーザは、第1決済情報から第2決済情報に決済情報を修正させることができる。
また、第21実施例は、割り勘完了通知は、端末20のユーザと、異なる端末20のユーザとを含むトークルーム(限定ではなく、チャットルームの一例)に表示される構成を示している。
このような構成により得られる効果の一例として、端末のユーザと、異なる端末のユーザとを含み、端末から異なる端末に送信されたコンテンツと、異なる端末から端末に送信されたコンテンツとを含むチャットルームへの表示という分かり易い形で、第1送金処理、または第1受取処理の完了をユーザに報知することができる。
<第22実施例>
第22実施例は、端末20が、異なる端末20のユーザによる買い物決済履歴について割り勘精算が行われた後、その異なる端末20のユーザによる買い物決済履歴に対して修正提案を行い、その修正提案による修正内容に基づいて、精算金額を事後的に調整する実施例である。
第22実施例は、異なる端末20のユーザによる買い物決済履歴に対して修正提案を行って、精算金額を事後的に調整する点が第21実施例とは異なる。
第22実施例に記載の内容は、他の各実施例や他の各変形例のいずれにも適用可能である。
また、既出の構成要素と同一の構成要素については同一の符号を付して、再度の説明を省略する。
<表示画面例>
図22−1は、本実施例におけるメッセージングアプリケーションのトークルーム画面に表示される割り勘完了通知の一例を示す図であり、ユーザB.Bの端末20の表示部24に表示される画面の一例を示している。
このトークルーム画面には、ユーザB.Bが割り勘精算を行うことに同意したことに基づいて、ユーザB.BからユーザA.Aに過不足金額(この例では「2,250円)が送金され、その結果として、割り勘が完了したことを示す割り勘完了通知のメッセージが表示されている。
割り勘完了通知のメッセージには、限定ではなく例として、精算結果とともに、精算内容を修正するための、限定ではなく例として「精算内容の修正」と示された精算内容修正アイコンが含まれる。
図22−2は、図21−1において精算内容修正アイコンが操作されたことに基づいてユーザB.Bの端末20の表示部24に表示される精算内容修正画面の一例を示す図である。
この精算内容修正画面には、限定ではなく例として、「割り勘の精算内容を確認してください」の文字が表示され、その下に、ユーザA.AおよびユーザB.Bそれぞれの支払い済み金額が表示される支払い済み金額一覧表示領域と、ユーザA.AおよびユーザB.Bそれぞれの精算金額が表示される精算金額一覧表示領域とが設けられている。
この例では、ユーザA.Aの支払い済み金額として「4,500円」が、ユーザB.Bの支払い済み金額として「0円」がそれぞれ表示されている。また、ユーザA.AおよびユーザB.Bの精算金額として、それぞれ「2,250円」が表示されている。
支払い済み金額表示領域において、ユーザA.Aの欄には、ユーザA.Aの支払い済み金額に対してユーザB.Bが修正提案を行うための「修正提案」と示された修正提案アイコンが表示されている。また、ユーザB.Bの欄には、ユーザB.Bの支払い済み金額に対してユーザB.Bが修正を行うための「修正」と示された修正アイコンが表示されている。
図22−3は、図22−2においてユーザB.Bが修正提案アイコンを操作したことに基づいて表示される修正対象買い物決済履歴選択画面の一例を示す図である。
この修正対象買い物決済履歴選択画面は、ユーザB.Bが修正提案対象とする買い物決済履歴を選択するための画面であり、ユーザA.Aが登録済みの買い物決済履歴として、「AAレンタサイクル」の買い物決済履歴と、「BBスーパー」の買い物決済履歴とが表示されている。また、この例では、ユーザB.Bによって、「BBスーパー」に関連付けられたチェックボックスのチェックが「ON」とされた状態が示されている。
画面下部には、買い物決済履歴の追加を提案するための「支払い分の追加提案」と示された買い物決済履歴追加提案アイコンと、修正提案対象として選択された買い物決済履歴の買い物決済金額の修正提案を行うための「金額修正提案」と示された金額修正提案アイコンと、登録済みの買い物決済履歴を取り下げる提案を行うための「取り下げ提案」と示された取り下げ提案アイコンとが表示されている。この例では、ユーザB.Bによって金額修正提案アイコンが操作された状態が示されている。
図22−4は、この例においてユーザA.Aの端末20の表示部24に表示されるトークルーム画面の一例を示す図である。
このトークルーム画面では、画面向かって左側に、ユーザB.Bからのメッセージとして、ユーザA.Aが登録した買い物決済履歴の修正を提案するメッセージが表示されている。この例では、ユーザA.Aによる「BBスーパー」の買い物決済履歴について、ユーザA.AがBBスーパーで自分用のお土産を購入しており、その分の金額を減額すべきではないかとの提案がユーザB.Bによってなされた状態が示されている。
具体的には、「BBスーパー」の買い物決済履歴における買い物決済金額が「3,000円→2,400円」に減額され、その結果、「AAレンタサイクル」の買い物決済履歴の買い物決済金額「1,500円」との合計金額が、「4,500円→3,900円」に減額される。そして、その結果、1人あたり金額が「2,250円→1,950円」に減額されることが示されている。ユーザB.Bは、既に「2,250円」を送金済みであるが、ユーザA.Aによって修正提案が承諾されると、差額である「300円」がユーザA.AからユーザB.Bに返金されることになる。このため、ユーザA.Aの過不足金額として「300円 支払い」が表示されている。
また、メッセージの下部には、上記の修正提案を承諾するための、限定ではなく例として「承諾する」と示された承諾アイコンと、上記の修正提案を却下するための、限定ではなく例として「却下する」と示された却下アイコンとが表示されている。
図22−5は、図22−4のトークルーム画面においてユーザA.Aによって承諾アイコンが操作されたことに基づいてユーザA.Aの端末20の表示部24に表示されるトークルーム画面の一例を示す図である。
承諾アイコンが操作されたことに基づいて、「承諾する」というメッセージがユーザB.Bの端末20に送信される。その後、ユーザA.Aの端末20からユーザB.Bの端末20に、修正に伴う過不足金額(この例では「300円」)が送金され、その結果、「B.Bさんに300円を送金しました」という文字を含む送金完了通知が表示される。
<処理>
この場合の処理の流れについて、図19の処理等を参照して説明する。
本処理は、限定ではなく例として、図19の処理に、メッセージングサーバ40の処理を追加することによって実現される。
割り勘の精算が完了した後、サーバ10が、割り勘精算結果をメッセージングサーバ40に送信する(図19のS340に相当)。そして、メッセージングサーバ40が、サーバ10から受信された割り勘精算結果を端末Aおよび端末Bに送信する。
買い物決済履歴を登録した端末Bの制御部21は、メッセージングサーバ40から受信された割り勘精算結果を、メッセージングアプリケーションのトークルームに表示させる(図19のB350に相当)。
その後、端末Bの制御部21は、限定ではなく例として、ユーザB.Bによって精算内容の修正提案を行う操作が入出力部23に対して入力されたことに基づいて、割り勘修正処理を実行する(図19のB540に相当)。そして、端末Bの制御部21は、割り勘精算修正依頼通知を、メッセージングサーバ40を介してサーバ10に送信する(図17−13のA5440に相当)。
この場合、サーバ10は、第3の割り勘承認管理処理を実行する(図19のS540に相当)。この例では、ユーザB.Bによって精算内容の修正提案が行われたため(図19のS550:YESに相当)、サーバ10は、割り勘修正確認通知を、メッセージングサーバ40を介して端末Aおよび端末Bに送信する(図19のS580に相当)。
端末Aの制御部21は、メッセージングサーバ40から受信された割り勘修正確認通知を、メッセージングアプリケーションのトークルームに表示させる。そして、端末Aの制御部21は、ユーザA.Aによって、ユーザB.Bからの修正提案を承認してその内容で割り勘に同意する操作が入出力部23に入力されたことに基づいて、割り勘精算承認通知を、メッセージングサーバ40を介してサーバ10に送信する(図17−13のA5360に相当)。
これにより、サーバ10の制御部11は、ユーザA.Aによって割り勘が同意されたと判定し、割り勘精算処理を実行する(図2−19のS330に相当)。そして、制御部11は、割り勘精算結果を、メッセージングサーバ40を介して端末Aおよび端末Bに送信する(図2−19のS340に相当)。
端末Aの制御部21は、メッセージングサーバ40から受信された割り勘精算結果を、メッセージングアプリケーションのトークルームに表示させる(図2−19のA340、A350に相当)。
同様に、端末Bの制御部21は、メッセージングサーバ40から受信された割り勘精算結果を、メッセージングアプリケーションのトークルームに表示させる(図2−19のB340、B350に相当)。
なお、上記では、メッセージングアプリケーションを利用して、端末20が、自己の端末20のユーザによる買い物決済履歴を修正し、その修正に基づいて、精算金額を事後的に調整することとしたが、メッセージングアプリケーションは必須ではなく、メッセージングアプリケーションおよびメッセージングサーバ40を構成要件から除外してもよい。
<第22実施例の効果>
第22実施例は、端末20が、自己の端末20のユーザと、異なる端末20のユーザとを含むトークルーム(限定ではなく、チャットルームの一例)を表示部24に表示する。そして、端末20は、異なる端末20のユーザによる買い物決済履歴(限定ではなく、第2決済情報の一例)の修正提案(限定ではなく、修正提案の一例)をトークルームに表示する構成を示している。
このような構成により得られる効果の一例として、第2決済情報の修正依頼をチャットルームへの表示という分かり易い形で異なる端末のユーザに報知することができる。
また、第22実施例は、買い物決済履歴の修正提案は、異なる端末20から自己の端末20に送信される。そして、修正買い物決済履歴に基づく割り勘精算要求処理は、修正提案に対するユーザの操作に基づいて実行される構成を示している。
このような構成により得られる効果の一例として、異なる端末から送信される修正依頼に対する端末のユーザによる入力に基づいて、第2送金処理、または第2受取処理を行って、精算した金額を事後的に調整することができる。