JP7448135B2 - プログラム、情報処理方法、サーバ - Google Patents

プログラム、情報処理方法、サーバ Download PDF

Info

Publication number
JP7448135B2
JP7448135B2 JP2019194779A JP2019194779A JP7448135B2 JP 7448135 B2 JP7448135 B2 JP 7448135B2 JP 2019194779 A JP2019194779 A JP 2019194779A JP 2019194779 A JP2019194779 A JP 2019194779A JP 7448135 B2 JP7448135 B2 JP 7448135B2
Authority
JP
Japan
Prior art keywords
user
amount
terminal
information
ratio
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2019194779A
Other languages
English (en)
Other versions
JP2020071881A (ja
JP2020071881A5 (ja
Inventor
壮一 高村
良 大野
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Line Pay Corp
Original Assignee
Line Pay Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Line Pay Corp filed Critical Line Pay Corp
Publication of JP2020071881A publication Critical patent/JP2020071881A/ja
Publication of JP2020071881A5 publication Critical patent/JP2020071881A5/ja
Application granted granted Critical
Publication of JP7448135B2 publication Critical patent/JP7448135B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Description

本発明は、情報処理装置、情報処理方法及び情報処理プログラムに関する。
従来から、従業員は、自身の作業内容を上長及び経理部等に報告している。その報告は１か月単位で締められるため、従業員は月末等にまとめて作業内容を入力することが多い。従業員が１か月分の作業内容をまとめて入力する場合、作業内容を詳細に思い出すことは困難であり、また作業内容の正確性に疑問が生じることになる。さらに、従業員は、作業内容の入力そのものを煩雑と感じることもある。
特許文献１に記載された技術は、プロジェクトの進捗を自動的に計測するようになっている。しかし、プロジェクトの進捗を自動的に計測する場合、プロジェクトの担当者が認識している工数と必ずしも対応しない可能性が発生し、担当者が不満を抱く可能性がある。
２０１３－１８６７６８号公報
情報処理装置は、複数の第１項目を表示する表示部と、表示部に表示される複数の第１項目それぞれについて比率が入力される比率入力部と、複数の第１項目と、比率入力部によって入力される比率とに基づいて、複数の第１項目それぞれの割合に関する割合情報を記憶する記憶部と、を備える。
情報処理装置では、表示部は、複数の第１項目と、第１項目の下位項目となる複数の第２項目とを表示し、比率入力部は、複数の第１項目それぞれについての比率としての第１の比率が入力されると共に、複数の第２項目それぞれについての比率としての第２の比率が入力され、記憶部は、複数の第１項目と第１の比率とに基づく複数の第１項目それぞれの割合と、複数の第２項目と第２の比率とに基づく複数の第２項目それぞれの割合とに関する割合情報を記憶することが好ましい。
情報処理装置では、第２項目は、複数の第１項目それぞれに応じて予め設定された項目であり、第１項目は、プロジェクトに関する項目であり、第２項目は、プロジェクト内の作業項目であることが好ましい。
情報処理装置は、割合情報を取得し、取得した割合情報について所定の処理を行って処理情報を生成し、処理情報に基づいて表示部に表示させる割合処理部をさらに備えることが好ましい。
情報処理装置は、記憶部に記憶された割合情報を外部端末に送信する送信部を備えることが好ましい。
情報処理装置は、割合処理部で生成された処理情報を外部端末に送信する送信部を備えることが好ましい。
情報処理装置は、処理情報に含まれる割合を変更するための割合変更指示情報を外部端末から受信する受信部と、受信部で受信した割合変更指示情報に基づいて、記憶部に記憶される処理情報に含まれる割合を変更する割合変更部と、を備えることが好ましい。
情報処理装置では、第１項目は複数のユーザ端末間にて共同で支払いをするにあたっての各端末での負担額に関する項目であり、複数のユーザ端末間にて共同で支払いをするにあたっての総負担額の入力を受け付ける総負担額処理部と、入力された比率および入力された総負担額に基づいて、複数のユーザ端末における精算額を計算する精算部と、精算部によって計算された精算額に基づいて、複数のユーザ端末に対して支払い請求を送信する通信部とを更に備えることが好ましい。
情報処理装置では、比率入力部は、その情報処理装置における入力のみでなく、複数のユーザ端末のうち少なくとも１のユーザ端末からの入力を通信部を通じて受けつけることが可能であることが好ましい。
情報処理装置では、総負担額処理部は、想定総負担額の入力を更に受け付け、精算部は、入力された比率および入力された想定総負担額に基づいて複数のユーザ端末における想定精算額を計算し、通信部は、精算部によって計算された想定精算額に基づいて、複数のユーザ端末のうち少なくとも１のユーザ端末に対し、想定支払い金額情報を送信することが好ましい。
情報処理装置では、総負担額処理部は、想定総負担額の入力を受け付け、精算部は、入力された比率および入力された想定総負担額に基づいて、複数のユーザ端末に対しての想定精算額を計算し、通信部は、精算部によって計算された想定精算額に基づいて、複数のユーザ端末に対し、仮支払い請求を送信することが好ましい。
情報処理装置では、通信部は、想定総負担額が総負担額と同等又は上回った場合であって、送信した仮支払い金額情報につき承認を得ているユーザ端末に対して、精算部によって計算された精算額に基づいて、精算指示を送信することが好ましい。
情報処理装置では、通信部が、複数のユーザ端末のうち少なくとも１のユーザ端末が送信された支払い請求に対応し、その支払い請求における負担額を上回る金額について支払い処理をした旨を受信した場合は、精算部は、その上回り分を考慮してそのユーザ端末以外の複数のユーザ端末のうち少なくとも１のユーザ端末についての精算額を再計算することが好ましい。
情報処理装置では、比率入力部は、複数のユーザ端末のうちの少なくとも１のユーザ端末についての負担金額の入力を更に受け付けることを可能とするよう構成されており、精算部は、そのユーザ端末について負担金額が入力された場合には、入力された負担金額を総負担額から差し引いた金額と、入力された負担割合に基づき、そのユーザ端末以外の複数のユーザ端末についての精算額を計算することが好ましい。
情報処理装置は、複数のユーザ端末のうちの１つであることが好ましい。
コンピュータが実行する情報処理方法は、複数の第１項目を表示部に表示することと、表示部に表示される複数の第１項目それぞれについて比率が比率入力部によって入力されることと、複数の第１項目と、比率入力部によって入力される比率とに基づいて、複数の第１項目それぞれの割合に関する割合情報を記憶部に記憶することと、を含む。
コンピュータによって実現される情報処理プログラムは、複数の第１項目を表示部に表示することと、表示部に表示される複数の第１項目それぞれについて比率が比率入力部によって入力されることと、複数の第１項目と、比率入力部によって入力される比率とに基づいて、複数の第１項目それぞれの割合に関する割合情報を記憶部に記憶することと、を含む。
本開示の全実施形態に係る通信システムの構成を示す。 第１実施形態に係る第１項目及び第２項目が表示される画面の一例について説明するための図である。 第１実施形態に係る情報処理装置の表示部で表示される画面の一例について説明するための第１の図である。 第１実施形態に係る情報処理装置の表示部で表示される画面の一例について説明するための第２の図である。 第１実施形態に係る情報処理方法について説明するためのフローチャートである。 第２実施形態に係る情報処理方法について説明するためのフローチャートである。 第２実施形態に係る第１項目が表示される画面の一例について説明するための図である。 図７に続く、想定総負担額を入力した図である。 図８の変形例１を示す図である。 図８の変形例２を示す図である。 図８に続く、総負担額を入力した図である。 図１１に、承認に有無が入力された図である。 第３実施形態に係る通信システム１の構成の一例を示す図である。 第３実施形態に係る端末の表示部に表示される画面の一例を示す図である。 第３実施形態に係る端末の表示部に表示される画面の一例を示す図である。 第３実施形態に係る端末の表示部に表示される画面の一例を示す図である。 第３実施形態に係る端末の表示部に表示される画面の一例を示す図である。 第３実施形態に係る端末の表示部に表示される画面の一例を示す図である。 第３実施形態に係る端末の表示部に表示される画面の一例を示す図である。 第３実施形態に係る端末の表示部に表示される画面の一例を示す図である。 第３実施形態に係る端末の表示部に表示される画面の一例を示す図である。 第３実施形態に係る端末の表示部に表示される画面の一例を示す図である。 第３実施形態に係る端末の表示部に表示される画面の一例を示す図である。 第３実施形態に係る端末の表示部に表示される画面の一例を示す図である。 第３実施形態に係る端末の表示部に表示される画面の一例を示す図である。 第３実施形態に係る端末の表示部に表示される画面の一例を示す図である。 第３実施形態に係る各装置が実行する処理の流れの一例を示すフローチャートである。 第３実施形態に係る各装置が実行する処理の流れの一例を示すフローチャートである。 第３実施形態の変形例に係る端末の表示部に表示される画面の一例を示す図である。 第３実施形態の変形例に係る端末の表示部に表示される画面の一例を示す図である。 第３実施形態の変形例に係る端末の表示部に表示される画面の一例を示す図である。 第３実施形態の変形例に係る端末の表示部に表示される画面の一例を示す図である。 第３実施形態の変形例に係る通信システム１の構成の一例を示す図である。
＜法的事項の遵守＞
本明細書に記載の開示は、通信の秘密など、本開示の実施に必要な実施国の法的事項遵守を前提とすることに留意されたい。
本開示に係る情報処理装置、情報処理方法及び情報処理プログラムを実施するための実施形態について、図面を参照して説明する。
＜システム構成＞
図１は、本開示の全実施形態に係る通信システム１の構成を示す。図１に開示されるように、通信システム１では、ネットワーク３０を介してサーバ１０と、端末２０（端末２０Ａ，端末２０Ｂ，端末２０Ｃ）とが接続される。サーバ１０は、ネットワーク３０を介してユーザが所有する端末２０に、端末２０間でのメッセージの送受信を実現するサービスを提供する。なお、ネットワーク３０に接続される端末２０の数は限定されない。
ネットワーク３０は、１以上の端末２０と、１以上のサーバ１０とを接続する役割を担う。すなわち、ネットワーク３０は、端末２０がサーバ１０に接続した後、データを送受信することができるように接続経路を提供する通信網を意味する。
ネットワーク３０のうちの１つまたは複数の部分は、有線ネットワークや無線ネットワークであってもよいし、そうでなくてもよい。ネットワーク３０は、限定でなく例として、アドホック・ネットワーク（ad hoc network）、イントラネット、エクストラネット、仮想プライベート・ネットワーク（virtual private network：ＶＰＮ）、ローカル・エリア・ネットワーク（local area network：ＬＡＮ）、ワイヤレスＬＡＮ（wireless LAN：ＷＬＡＮ）、広域ネットワーク（wide area network：ＷＡＮ）、ワイヤレスＷＡＮ（wireless WAN：ＷＷＡＮ）、大都市圏ネットワーク（metropolitan area network：ＭＡＮ）、インターネットの一部、公衆交換電話網（Public Switched Telephone Network：ＰＳＴＮ）の一部、携帯電話網、ＩＳＤＮ（integrated service digital networks）、無線ＬＡＮ、ＬＴＥ（long term evolution）、ＣＤＭＡ（code division multiple access）、ブルートゥース（Bluetooth（登録商標））、衛星通信など、または、これらの２つ以上の組合せを含むことができる。ネットワーク３０は、１つまたは複数のネットワーク３０を含むことができる。
端末２０（端末２０Ａ，端末２０Ｂ，端末２０Ｃ）は、各実施形態において記載する機能を実現できる情報処理端末であればどのような端末であってもよい。端末２０は、限定ではなく例として、スマートフォン、携帯電話（フィーチャーフォン）、コンピュータ（限定でなく例として、デスクトップ、ラップトップ、タブレットなど）、メディアコンピュータプラットホーム（限定でなく例として、ケーブル、衛星セットトップボックス、デジタルビデオレコーダ）、ハンドヘルドコンピュータデバイス（限定でなく例として、ＰＤＡ・（personal digital assistant）、電子メールクライアントなど）、ウェアラブル端末（メガネ型デバイス、時計型デバイスなど）、または他種のコンピュータ、またはコミュニケーションプラットホームを含む。また、端末２０は情報処理端末と表現されてもよい。
端末２０Ａ、端末２０Ｂおよび端末２０Ｃの構成は基本的には同一であるため、以下の説明においては、端末２０について説明する。また、必要に応じて、ユーザＸが利用する端末を端末２０Ｘと表現し、ユーザＸまたは端末２０Ｘに対応づけられた、所定のサービスにおけるユーザ情報をユーザ情報Ｘと表現する。なお、ユーザ情報とは、所定のサービスにおいてユーザが利用するアカウントに対応付けられたユーザの情報である。ユーザ情報は、限定でなく例として、ユーザにより入力される、または、所定のサービスにより付与される、ユーザの名前、ユーザのアイコン画像、ユーザの年齢、ユーザの性別、ユーザの住所、ユーザの趣味趣向、ユーザの識別子などのユーザに対応づけられた情報を含み、これらのいずれか一つまたは、組み合わせであってもよいし、そうでなくてもよい。
サーバ１０は、端末２０に対して、所定のサービスを提供する機能を備える。サーバ１０は、各実施形態において記載する機能を実現できる情報処理装置であればどのような装置であってもよい。サーバ１０は、限定でなく例として、サーバ装置、コンピュータ（限定でなく例として、デスクトップ、ラップトップ、タブレットなど）、メディアコンピュータプラットホーム（限定でなく例として、ケーブル、衛星セットトップボックス、デジタルビデオレコーダ）、ハンドヘルドコンピュータデバイス（限定でなく例として、ＰＤＡ、電子メールクライアントなど）、あるいは他種のコンピュータ、またはコミュニケーションプラットホームを含む。また、サーバ１０は情報処理装置と表現されてもよい。サーバ１０と端末２０とを区別する必要がない場合は、サーバ１０と端末２０とは、それぞれ情報処理装置と表現されてもよいし、されなくてもよい。
＜ハードウェア（ＨＷ）構成＞
図１を用いて、通信システム１に含まれる各装置のＨＷ構成について説明する。
（１）端末のＨＷ構成
端末２０は、制御部２１（ＣＰＵ：central processing unit（中央処理装置））、記憶部２８、通信Ｉ／Ｆ２２（インタフェース）、入出力部２３、表示部２４、マイク２５、スピーカ２６、カメラ２７を備える。端末２０のＨＷの各構成要素は、限定でなく例として、バスＢを介して相互に接続される。なお、端末２０のＨＷ構成として、すべての構成要素を含むことは必須ではない。限定ではなく例として、端末２０は、マイク２５、カメラ２７等、個々の構成要素、または複数の構成要素を取り外すような構成であってもよいし、そうでなくてもよい。
通信Ｉ／Ｆ２２は、ネットワーク３０を介して各種データの送受信を行う。当該通信は、有線、無線のいずれで実行されてもよく、互いの通信が実行できるのであれば、どのような通信プロトコルを用いてもよい。通信Ｉ／Ｆ２２は、ネットワーク３０を介して、サーバ１０との通信を実行する機能を有する。通信Ｉ／Ｆ２２は、各種データを制御部２１からの指示に従って、サーバ１０に送信する。また、通信Ｉ／Ｆ２２は、サーバ１０から送信された各種データを受信し、制御部２１に伝達する。また、通信Ｉ／Ｆ２２を単に通信部と表現する場合もある。また、通信Ｉ／Ｆ２２が物理的に構造化された回路で構成される場合には、通信回路と表現する場合もある。
入出力部２３は、端末２０に対する各種操作を入力する装置、および、端末２０で処理された処理結果を出力する装置を含む。入出力部２３は、入力部と出力部が一体化していてもよいし、入力部と出力部に分離していてもよいし、そうでなくてもよい。
入力部は、ユーザからの入力を受け付けて、当該入力に係る情報を制御部２１に伝達できる全ての種類の装置のいずれかまたはその組み合わせにより実現される。入力部は、限定でなく例として、タッチパネル、タッチディスプレイ、キーボード等のハードウェアキーや、マウス等のポインティングデバイス、カメラ（動画像を介した操作入力）、マイク（音声による操作入力）を含む。
出力部は、制御部２１で処理された処理結果を出力することができる全ての種類の装置のいずれかまたはその組み合わせにより実現される。出力部は、限定でなく例として、 タッチパネル、タッチディスプレイ、スピーカ（音声出力）、レンズ（限定でなく例として３Ｄ（three dimensions）出力や、ホログラム出力）、プリンターなどを含む。
表示部２４は、フレームバッファに書き込まれた表示データに従って、表示することができる全ての種類の装置のいずれかまたはその組み合わせにより実現される。表示部２４は、限定でなく例として、タッチパネル、タッチディスプレイ、モニタ（限定でなく例として、液晶ディスプレイやＯＥＬＤ（organic electroluminescence display））、ヘッドマウントディスプレイ（ＨＤＭ：Head Mounted Display）、プロジェクションマッピング、ホログラム、空気中など（真空であってもよいし、そうでなくてもよい）に画像やテキスト情報等を表示可能な装置を含む。なお、これらの表示部２４は、３Ｄで表示データを表示可能であってもよいし、そうでなくてもよい。
入出力部２３がタッチパネルの場合、入出力部２３と表示部２４とは、略同一の大きさおよび形状で対向して配置されていてもよい。
制御部２１は、プログラム内に含まれたコードまたは命令によって実現する機能を実行するために物理的に構造化された回路を有し、限定でなく例として、ハードウェアに内蔵されたデータ処理装置により実現される。そのため、制御部２１は、制御回路と表現されてもよいし、されなくてもよい。
制御部２１は、限定でなく例として、中央処理装置（ＣＰＵ）、マイクロプロセッサ（microprocessor）、プロセッサコア（processor core）、マルチプロセッサ（multiprocessor）、ＡＳＩＣ（application-specific integrated circuit）、ＦＰＧＡ（field programmable gate array）を含む。
記憶部２８は、端末２０が動作するうえで必要とする各種プログラムや各種データを記憶する機能を有する。記憶部２８は、限定でなく例として、ＨＤＤ（hard disk drive）、ＳＳＤ（solid state drive）、フラッシュメモリ、ＲＡＭ（random access memory）、ＲＯＭ（read only memory）など各種の記憶媒体を含む。また、記憶部２８は、メモリ（memory）と表現されてもよいし、されなくてもよい。
端末２０は、プログラムＰを記憶部２８に記憶し、このプログラムＰを実行することで、制御部２１が、制御部２１に含まれる各部としての処理を実行する。つまり、記憶部２８に記憶されるプログラムＰは、端末２０に、制御部２１が実行する各機能を実現させる。また、このプログラムＰは、プログラムモジュールと表現されてもよいし、されなくてもよい。
マイク２５は、音声データの入力に利用される。スピーカ２６は、音声データの出力に利用される。カメラ２７は、動画像データの取得に利用される。
（２）サーバのＨＷ構成
サーバ１０は、制御部１１（ＣＰＵ）、記憶部１５、通信Ｉ／Ｆ１４（インタフェース）、入出力部１２、ディスプレイ１３を備える。サーバ１０のＨＷの各構成要素は、限定でなく例として、バスＢを介して相互に接続される。なお、サーバ１０のＨＷは、サーバ１０のＨＷの構成として、全ての構成要素を含むことは必須ではない。限定ではなく例として、サーバ１０のＨＷは、ディスプレイ１３を取り外すような構成であってもよいし、そうでなくてもよい。
制御部１１は、プログラム内に含まれたコードまたは命令によって実現する機能を実行するために物理的に構造化された回路を有し、限定でなく例として、ハードウェアに内蔵されたデータ処理装置により実現される。
制御部１１は、代表的には中央処理装置（ＣＰＵ）、であり、その他にマイクロプロセッサ、プロセッサコア、マルチプロセッサ、ＡＳＩＣ、ＦＰＧＡであってもよいし、そうでなくてもよい。本開示において、制御部１１は、これらに限定されない。
記憶部１５は、サーバ１０が動作するうえで必要とする各種プログラムや各種データを記憶する機能を有する。記憶部１５は、ＨＤＤ、ＳＳＤ、フラッシュメモリなど各種の記憶媒体により実現される。ただし、本開示において、記憶部１５は、これらに限定されない。また、記憶部１５は、メモリ（memory）と表現されてもよいし、されなくてもよい。
通信Ｉ／Ｆ１４は、ネットワーク３０を介して各種データの送受信を行う。当該通信は、有線、無線のいずれで実行されてもよく、互いの通信が実行できるのであれば、どのような通信プロトコルを用いてもよい。通信Ｉ／Ｆ１４は、ネットワーク３０を介して、端末２０との通信を実行する機能を有する。通信Ｉ／Ｆ１４は、各種データを制御部１１からの指示に従って、端末２０に送信する。また、通信Ｉ／Ｆ１４は、端末２０から送信された各種データを受信し、制御部１１に伝達する。また、通信Ｉ／Ｆ１４を単に通信部と表現する場合もある。また、通信Ｉ／Ｆ１４が物理的に構造化された回路で構成される場合には、通信回路と表現する場合もある。
入出力部１２は、サーバ１０に対する各種操作を入力する装置により実現される。入出力部１２は、ユーザからの入力を受け付けて、当該入力に係る情報を制御部１１に伝達できる全ての種類の装置のいずれかまたはその組み合わせにより実現される。入出力部１２は、代表的にはキーボード等に代表されるハードウェアキーや、マウス等のポインティングデバイスで実現される。なお、入出力部１２、限定でなく例として、タッチパネルやカメラ（動画像を介した操作入力）、マイク（音声による操作入力）を含んでいてもよいし、そうでなくてもよい。ただし、本開示において、入出力部１２は、これらに限定されない。
ディスプレイ１３は、代表的にはモニタ（限定でなく例として、液晶ディスプレイやＯＥＬＤ（organic electroluminescence display））で実現される。なお、ディスプレイ１３は、ヘッドマウントディスプレイ（ＨＤＭ）などであってもよいし、そうでなくてもよい。なお、これらのディスプレイ１３は、３Ｄで表示データを表示可能であってもよいし、そうでなくてもよい。ただし、本開示において、ディスプレイ１３は、これらに限定されない。
サーバ１０は、プログラムＰを記憶部１５に記憶し、このプログラムＰを実行することで、制御部１１が、制御部１１に含まれる各部としての処理を実行する。つまり、記憶部１５に記憶されるプログラムＰは、サーバ１０に、制御部１１が実行する各機能を実現させる。このプログラムＰは、プログラムモジュールと表現されてもよいし、されなくてもよい。
本開示の各実施形態においては、端末２０および／またはサーバ１０のＣＰＵがプログラムＰを実行することにより、実現するものとして説明する。
なお、端末２０の制御部２１、および／または、サーバ１０の制御部１１は、制御回路を有するＣＰＵだけでなく、集積回路（ＩＣ（Integrated Circuit）チップ、ＬＳＩ（Large Scale Integration））等に形成された論理回路（ハードウェア）や専用回路によって各処理を実現してもよいし、そうでなくてもよい。また、これらの回路は、１または複数の集積回路により実現されてよく、各実施形態に示す複数の処理を１つの集積回路により実現されることとしてもよいし、そうでなくてもよい。また、ＬＳＩは、集積度の違いにより、ＶＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩなどと呼称されることもある。そのため、制御部２１は、制御回路と表現されてもよいし、されなくてもよい。
また、本開示の各実施形態のプログラムＰ（限定ではなく、例として、ソフトウェアプログラム、コンピュータプログラム、またはプログラムモジュール）は、コンピュータに読み取り可能な記憶媒体に記憶された状態で提供されてもよいし、されなくてもよい。 記憶媒体は、「一時的でない有形の媒体」に、プログラムＰを記憶可能である。また、プログラムＰは、本開示の各実施形態の機能の一部を実現するためのものであってもよいし、そうでなくてもよい。さらに、本開示の各実施形態の機能を記憶媒体にすでに記録されているプログラムＰとの組み合わせで実現できるもの、いわゆる差分ファイル（差分プログラム）であってもよいし、そうでなくてもよい。
記憶媒体は、１つまたは複数の半導体ベースの、または他の集積回路（ＩＣ）（限定でなく例として、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）または特定用途向けＩＣ（ＡＳＩＣ）など）、ハード・ディスク・ドライブ（ＨＤＤ）、ハイブリッド・ハード・ドライブ（ＨＨＤ）、光ディスク、光ディスクドライブ（ＯＤＤ）、光磁気ディスク、光磁気ドライブ、フロッピィ・ディスケット、フロッピィ・ディスク・ドライブ（ＦＤＤ）、磁気テープ、固体ドライブ（ＳＳＤ）、ＲＡＭドライブ、セキュア・デジタル・カード、またはドライブ、任意の他の適切な記憶媒体、またはこれらの２つ以上の適切な組合せを含むことができる。記憶媒体は、適切な場合、揮発性、不揮発性、または揮発性と不揮発性の組合せでよい。なお、記憶媒体はこれらの例に限られず、プログラムＰを記憶可能であれば、どのようなデバイスまたは媒体であってもよい。また、記憶媒体をメモリ（memory）と表現されてもよいし、されなくてもよい。
サーバ１０および／または端末２０は、記憶媒体に記憶されたプログラムＰを読み出し、読み出したプログラムＰを実行することによって、各実施形態に示す複数の機能部の機能を実現することができる。
また、本開示のプログラムＰＤＤは、当該プログラムを伝送可能な任意の伝送媒体(通信ネットワークや放送波等)を介して、サーバ１０および／または端末２０に提供されてもよいし、されなくてもよい。サーバ１０および／または端末２０は、限定でなく例として、インターネット等を介してダウンロードしたプログラムＰを実行することにより、各実施形態に示す複数の機能部の機能を実現する。
また、本開示の各実施形態は、プログラムＰが電子的な伝送によって具現化された、搬送波に埋め込まれたデータ信号の形態でも実現され得る。
サーバ１０および／または端末２０における処理の少なくとも一部は、１以上のコンピュータにより構成されるクラウドコンピューティングにより実現されていてもよいし、そうでなくてもよい。
端末２０における処理の少なくとも一部を、サーバ１０により行う構成としてもよいし、そうでなくてもよい。この場合、端末２０の制御部２１の各機能部の処理のうち少なくとも一部の処理を、サーバ１０で行う構成としてもよいし、そうでなくてもよい。
サーバ１０における処理の少なくとも一部を、端末２０により行う構成としてもよいし、そうでなくてもよい。この場合、サーバ１０の制御部１１の各機能部の処理のうち少なくとも一部の処理を、端末２０で行う構成としてもよいし、そうでなくてもよい。
明示的な言及のない限り、本開示の実施形態における判定の構成は必須でなく、判定条件を満たした場合に所定の処理が動作されたり、判定条件を満たさない場合に所定の処理がされたりしてもよいし、そうでなくてもよい。
なお、本開示のプログラムは、限定でなく例として、ActionScript、JavaScript（登録商標）などのスクリプト言語、Objective-C、Java（登録商標）などのオブジェクト指向プログラミング言語、HTML5などのマークアップ言語などを用いて実装される。
＜第１実施形態＞
第１実施形態は、情報処理装置を用いてプロジェクト管理を行う形態である。
第１実施形態に記載の内容は、他の各実施形態のいずれにも適用可能である。
図２は、第１実施形態に係る第１項目及び第２項目が表示される画面の一例について説明するための図である。図３は、第１実施形態に係る情報処理装置の表示部で表示される画面の一例について説明するための第１の図である。図４は、第１実施形態に係る情報処理装置の表示部で表示される画面の一例について説明するための第２の図である。
＜第１実施形態の構成＞
情報処理装置は、上述した端末２０によって実現することが可能である。このため、以下では、情報処理装置を端末２０として説明する。
図１に示す端末２０は、上述した表示部２４と、比率入力部２１０と、上述した記憶部２８と、割合処理部２１１と、割合警告部２１２と、を備える。
表示部２４は、複数の第１項目を表示する。また、表示部２４は、第１項目の下位項目となる複数の第２項目を表示する。第２項目は、複数の第１項目それぞれに応じて予め設定された項目である。すなわち、第２項目は、上位項目である第１項目毎に、適宜設定される項目である。例えば、端末２０がプロジェクトの進捗等の管理に用いられる場合、第１項目は、プロジェクトに関する項目となる。具体例としては、プロジェクトに関する項目は、プロジェクト名である。また、第２項目は、プロジェクト内の作業項目である。具体例としては、プロジェクト内の作業項目は、「研究開発」、「社内会議」、「クライアントとの会議」及び「イベント」等である。
端末２０（２０Ａ）の表示部２４に表示される第１項目及び第２項目は、プロジェクトの管理者等が他の端末２０Ｂ，２０Ｃ又はサーバ１０を操作することに基づいて、他の端末２０Ｂ，２０Ｃ又はサーバ１０によって予め設定される。又は、第１項目及び第２項目は、サーバ１０等に予め登録された複数の項目の中から、ユーザが自身に適するものを適宜選択することにより設定することも可能である。第１項目及び第２項目は、複数のユーザ（複数の端末２０）それぞれで異なってもよい。
比率入力部２１０は、表示部２４に表示される複数の第１項目それぞれにユーザの工数比率が入力される。また、比率入力部２１０は、複数の第１項目それぞれについてのユーザの工数比率（第１の工数比率）を入力すると共に、複数の第２項目それぞれについてのユーザの工数比率（第２の工数比率）を入力する。
ユーザの工数比率とは、一例として、複数の第１項目それぞれの作業についてユーザがどれだけ時間（及び手間）等を費やしたかを示すものである。複数の第１項目それぞれにユーザの工数比率が入力されると、入力された工数比率に基づいて、複数の第１項目それぞれの間の割合が得られる。すなわち、比率入力部２１０は、複数の第１項目と、比率入力部２１０によって入力される工数比率とを対応付けることに基づいて、複数の第１項目の割合に関する割合情報を得る。
同様に、ユーザの工数比率とは、一例として、複数の第２項目それぞれの作業についてユーザがどれだけ時間（及び手間）等を費やしたかを示すものである。複数の第２項目それぞれにユーザの工数比率が入力されると、入力された工数比率に基づいて、複数の第２項目それぞれの間の割合が得られる。すなわち、比率入力部２１０は、複数の第１項目と第１の工数比率とを対応付ける共に、複数の第２項目と第２の工数比率とを対応付けることに基づいて、複数の第１項目の割合及び第２項目の割合に関する割合情報を得る。
「工数比率」とは、ユーザが考える第１項目及び第２項目に対する「割合」、「比率」又は「度合い」であり、また、第１項目及び第２項目の「個別の比率の入力値」である。
図２に一例を示すように、表示部２４には、第１項目３０１Ａに隣接して第１の工数比率の入力欄３０１Ｂが表示されると共に、第２項目３０２Ａに隣接して第２の工数比率の入力欄３０２Ｂが表示される。なお、第１項目３０１Ａ、第２項目３０２Ａ及び入力欄３０１Ｂ，３０２Ｂの表示データは、例えば、端末２０の記憶部２８又はサーバ１０の記憶部１５等に記憶される。その表示データがサーバ１０の記憶部１５に記憶される場合、端末２０がサーバ１０にアクセスすることにより、第１項目３０１Ａ、第２項目３０２Ａ及び入力欄３０１Ｂ，３０２Ｂを表示することができる。入出力部２３が操作されることにより、入力欄３０１Ｂ，３０２Ｂの左右にある「＋」又は「－」が押下（タップ）されることによって、入力欄３０１Ｂ，３０２Ｂに工数比率が入力される。入力される工数比率は、例えば、第１項目３０１Ａの場合には各プロジェクトの工数の比率であり、第２項目３０２Ａの場合には１のプロジェクト内の工数の比率である。その「工数の比率」とは、例えば、ユーザが１か月中に各項目についてどれだけ時間をかけたと感じている比率（又は、割合、度合い）である。
比率入力部２１０は、工数比率が入力されると、入力された工数比率を受け付ける。比率入力部２１０は、受け付けた工数比率に基づいて計算を行い、複数の第１項目それぞれの間の比率の合計が１００％となるよう計算を行うと共に、１つの第１項目の下位項目となる複数の第２項目それぞれの間の比率が合計で１００％となるよう計算を行う。
図１に示す記憶部２８は、複数の第１項目と、比率入力部２１０によって入力される工数比率とを対応付けて得られる、第１項目の割合に関する割合情報を記憶する。また、記憶部２８は、複数の第１項目と第１の工数比率とを対応付ける共に、複数の第２項目と第２の工数比率とを対応付けて得られる複数の第１項目の割合及び第２項目の割合に関する割合情報を記憶する。
一例として、記憶部２８は、「第１項目Ａ」の工数比率は「２」及び「第１項目Ｂ」の工数比率は「７」という関係に基づいて、「第１項目Ａ」の割合は「２２％」及び「第１項目Ｂ」の割合は「７８％」という関係を記憶する。なお、記憶部２８は、第１項目の割合と共に、工数比率も記憶することが可能である。
また、一例として、記憶部２８は、「第２項目Ｃ」の工数比率は「０」、「第２項目Ｄ」の工数比率は「１」、「第２項目Ｅ」の工数比率は「２」及び「第２項目Ｆ」の工数比率は「０」という関係に基づいて、「第２項目Ｃ」の割合は「０％」、「第２項目Ｄ」の割合は「３３％」、「第２項目Ｅ」の割合は「６７％」及び「第２項目Ｆ」の割合は「０％」という関係を記憶する。なお、記憶部２８は、第２項目の割合と共に、工数比率も記憶することが可能である。
割合処理部２１１は、割合情報を取得し、取得した割合情報について所定の処理を行って処理情報を生成し、処理情報に基づいて表示部２４に表示させる。
割合処理部２１１は、所定の処理の一例として、記憶部２８に記憶される割合情報を視覚的にわかりやすく表示部２４に表示させる処理（表示に関する処理）を行う。割合処理部２１１は、例えば、記憶部２８に記憶される割合情報に基づいて、端末２０のユーザの全作業内容の工数（工数比率又は割合）をグラフおよび／または数値で表示部２４に表示させる、又は、端末２０のユーザが従事するプロジェクトのプロジェックト毎にグラフおよび／または数値で表示部２４に表示させる等の処理を行う。グラフは、一例として、円グラフ又は棒グラフ等である。表示に関する処理の場合、表示部２４に表示されるグラフおよび／または数値の表示データが処理情報になる。
また、割合処理部２１１は、割合情報と、その割合情報以外の他の情報と組み合わせて処理（所定の処理）を行うことにより、処理情報を生成してもよい。他の情報は、一例として、端末２０の記憶部２８、他の端末２０Ｂ，２０Ｃの記憶部２８及びサーバ１０の記憶部２８に記憶される、従業員の勤怠情報である。勤怠情報は、従業員の出勤時間及び退勤時間等が記録される。割合処理部２１１は、勤怠情報を取得し、勤怠情報に記録される従業員の出勤時間及び退勤時間に基づいて、従業員の勤務時間を取得する。割合処理部２１１は、取得した従業員の勤務時間と、取得した割合情報とに基づいて、第１項目及び第２項目それぞれの作業に費やした作業時間を取得する。すなわち、割合処理部２１１は、第１項目の割合及び第２項目の割合それぞれに応じて勤務時間を割り当てることにより、端末２０のユーザが行った各作業（第１項目及び第２項目）に対する作業時間を取得して、処理情報を生成する。
割合処理部２１１は、生成した処理情報に基づいて、図３に一例を示すように、各作業に対する作業時間を１本の棒グラフにして表示部２４に表示させる。また、割合処理部２１１は、生成した処理情報に基づいて、図４に一例を示すように、各作業に対する作業時間を項目毎に棒グラフにして表示部２４に表示させてもよい。
また、割合処理部２１１は、複数の第１項目又は複数の第２項目いずれかの項目についての個別の作業時間が予め取得されている場合には、その個別の作業時間を、端末２０のユーザが行った項目に割り当てることにより、処理情報を生成することが可能である。一例として、外部のスケジュール管理システムにおいて、ユーザが２時間の打ち合わせに参加したことが分かっている場合がある。これを、ユーザが工数比率に含めるのではなく、参加情報を自動的に取得し、実働時間より差し引くことで、第１項目の入力から省くことができ、ユーザの手間を減らすことが可能になる。
また、端末２０は、ユーザが所属する組織（プロジェクトや会社）の売上管理にも利用することができる。すなわち、割合処理部２１１は、他の情報として、端末２０の記憶部２８、他の端末２０Ｂ，２０Ｃの記憶部２８及びサーバ１０の記憶部２８に記憶される、端末２０のユーザについての売上額を示す売上情報を取得することが可能である。この場合、割合処理部２１１は、売上情報と、割合情報とに基づいて、複数の第１項目及び複数の第２項目それぞれの項目で生じた費用（売上）を計算し、計算結果としての処理情報を生成することが可能である。これにより、端末２０は、ユーザごとの売上額や人件費が明らかになるので、プロジェクト毎の売上額や人件費の管理を行うことが可能になり、会社の売上額や人件費の管理も行うことが可能になる。
割合警告部２１２は、割合情報に含まれる割合が予め定められた値を超える場合、入力された工数比率に関しての入力間違いの可能性、又は、第１項目又は第２項目の作業が適切に行われていない可能性が有るとして、表示部２４に警告表示を行う。例えば、割合警告部２１２は、割合情報が記憶部２８に記憶される際に、割合情報を確認し、端末２０のユーザに対しての警告表示を行う。
一例として、１つの第１項目の下位項目となる複数の第２項目のうち、いずれか１つの第２項目の割合が１００％となる場合等、割合警告部２１２は、端末２０のユーザに確認を求める画像（確認画像）を表示部２４に表示させる。ユーザに警告を行うための割合の閾値は、例えば、プロジェクトの管理者等によって適宜設定される。割合警告部２１２は、一例として、確認を求める旨の文書と共に、確認画像をポップアップにより表示部２４に表示させてもよい。又は、割合警告部２１２は、一例として、工数比率を入力する入力欄を含む画面を表示部２４に表示させて、入力欄を背景と異なる色に着色した警告表示を行ってもよい。
＜第１実施形態の情報処理方法＞
次に、第１実施形態の情報処理方法について説明する。
図５は、第１実施形態に係る情報処理方法について説明するためのフローチャートである。
ステップＳＴ１１において、表示部２４は、複数の第１項目及び複数の第２項目を表示する。第２項目は、各第１項目の下位項目である。複数の第２項目の内容は、上位項目となる第１項目に応じて異なる場合がある。表示部２４は、第１項目及び第２項目と共に、工数比率（第１の工数比率及び第２の工数比率）が入力される入力欄も表示する。
ステップＳＴ１２において、比率入力部２１０は、ステップＳＴ１１で表示部２４に表示された入力欄に工数比率が入力された場合、その工数比率の入力を受け付ける。「工数比率」は、例えば、「比率」、「割合」又は「度合い」等と言うことが可能である。比率入力部２１０は、工数比率の入力を受け付けると、入力された工数比率に基づいて複数の第１項目間の割合及び複数の第２項目間の割合を取得する。比率入力部２１０は、複数の第１項目及び複数の第２項目と、それぞれの項目に対する割合とを関連付けた割合情報を記憶部２８に記憶する処理を行う。
ステップＳＴ１３において、割合警告部２１２は、ステップＳＴ１２において入力された工数比率について警告が必要か否かを判断する。ステップＳＴ１３の判断処理は、一例として、割合情報が記憶部２８に記憶されるときに行われる。警告が必要な場合（Ｙｅｓ）、処理はステップＳＴ１４に進む。警告が不要な場合（Ｎｏ）、処理はステップＳＴ１６に進む。
ステップＳＴ１４において、割合警告部２１２は、表示部２４に警告表示を行う。この場合、表示部２４は、工数比率を再入力させるため、第１項目及び第２項目と共に工数比率（第１の工数比率及び第２の工数比率）の入力欄を表示する。
ステップＳＴ１５において、比率入力部２１０は、ステップＳＴ１４で表示部２４に表示された入力欄に工数比率が入力された場合、その工数比率の再入力を受け付ける。ステップＳＴ１５の後、処理は、ステップＳＴ１３に戻る。
なお、ステップＳＴ１３、ステップＳＴ１４及びステップＳＴ１５の処理は、上述したように行われてもよいし、行われなくてもよい。
ステップＳＴ１６の処理は、ＳＴ１３において警告が不要と判断された場合に行われる。すなわち、ステップＳＴ１６において、記憶部２８は、ステップＳＴ１２の記憶処理が実行されることにより、割合情報を記憶する。
ステップＳＴ１７において、割合処理部２１１は、ステップＳＴ１６において記憶した割合情報を記憶部２８から読み出し、その割合情報について所定の処理を実行する。割合処理部２１１は、例えば、割合情報について視覚的に理解しやすくするために、割合情報に基づいてグラフ等を作成し、表示部２４に表示させる。また、割合処理部２１１は、例えば、割合情報と、他の情報（一例として、勤怠情報又は売上情報等）とを組み合わせて、項目毎の作業時間又は項目毎の売上（費用）を取得する処理を行い、処理の結果を表示部２４に表示させる。ステップＳＴ１７において、割合処理部２１１は、所定の処理の結果を上述したように表示部２４に表示させてもよく、表示させなくてもよい。また、ステップＳＴ１７において、割合処理部２１１は、所定の処理の結果を記憶部２８に記憶させてもよく、記憶させなくてもよい。
ステップＳＴ１７の後、処理は終了する。
＜第１実施形態の効果＞
次に、第１実施形態の情報処理装置（端末２０）は、以下の効果を奏する。
情報処理装置（端末２０）は、表示部２４に表示される複数の第１項目それぞれについて工数比率が入力される比率入力部２１０と、複数の第１項目と、比率入力部２１０によって入力される工数比率に基づいて得らえる割合情報を記憶する記憶部２８と、を備える。
情報処理装置は、ユーザの感覚を考慮して、複数の第１項目それぞれのユーザの工数比率（作業の程度）を入力することができる。また、情報処理装置は、ユーザの工数比率（割合／比率／度合い）を入力するので、入力に手間がかかるのを抑制することができ、ユーザが入力について煩雑と感じる可能性を抑えることができる。
第１項目それぞれの作業時間をユーザが入力する従来の方法では、ユーザが作業時間そのものを思い出すことが煩雑で、さらに不正確になる場合がある。ユーザが第１項目それぞれの作業の比率を入力する本実施形態の方法であれば、ユーザの感覚として作業に費やしたエネルギの割合がどれくらいだったのかを考慮して入力できるので、よりユーザの時間に合った入力とすることができる。
情報処理装置（端末２０）では、表示部２４は、複数の第１項目と、第１項目の下位項目となる複数の第２項目とを表示する。この場合、比率入力部２１０は、複数の第１項目それぞれの間のユーザが費やした工数比率としての第１の工数比率が入力されると共に、複数の第２項目それぞれの間のユーザが費やした工数比率としての第２の工数比率が入力される。記憶部２８は、複数の第１項目と第１の工数比率とに基づいて得られる複数の第１項目の割合と、複数の第２項目と第２の工数比率とに基づいて得られる複数の第２項目の割合とに関する割合情報を記憶する。
情報処理装置は、入力すべき項目（第１項目及び第２項目）が多くなった場合でも、それぞれの項目についてユーザの工数比率（作業の程度）で入力することができるため、入力に手間がかかるのを抑制することができる。
情報処理装置（端末２０）では、第２項目は、複数の第１項目それぞれに応じて予め設定された項目である。この場合、第１項目は、プロジェクトに関する項目である。第２項目は、プロジェクト内の作業項目である。
情報処理装置は、ユーザに作業工数を記載させることができる。情報処理装置は、第１項目に応じて第２項目が予め設定されているため、プロジェクトの管理者等が従業員の作業内容を適切に管理することができ、また従業員が報告する作業内容で迷うことを防ぐことができる。
また、情報処理装置は、作業毎にユーザが費やした工数比率（作業の程度）を入力させるため、従業員が作業内容を正確に思い出す必要がなく、また、従業員の認識に基づいて入力される割合なので、作業工数の正確性に疑問が生じることを抑えることができる。
情報処理装置（端末２０）は、割合情報を取得し、取得した割合情報について表示に関する所定の処理を行って処理情報を生成し、処理情報に基づいて表示部２４に表示させる割合処理部２１１をさらに備える。
情報処理装置は、割合情報と他の情報とを連携させることにより、より利用価値の高い情報を得ることができる。
＜第１実施形態の変形例＞
なお、第１実施形態では、１つの端末２０で処理を行う例について説明した。しかし、本発明は、この例に限定されることはない。
例えば、１つの端末２０で割合情報が生成された場合、１つの端末２０は、通信Ｉ／Ｆ２２（送信部）を用いて、生成した割合情報をサーバ１０（又は、他の端末２０Ｂ，２０Ｃ）に送信してもよい。また、例えば、１つの端末２０は、通信Ｉ／Ｆ２２（送信部）を用いて、記憶部２８に記憶される割合情報をサーバ１０（又は、他の端末２０Ｂ，２０Ｃ）に送信してもよい。この場合、サーバ１０（又は、他の端末２０Ｂ，２０Ｃ）は、複数の端末２０から送信された割合情報を記憶する。サーバ１０（又は、他の端末２０Ｂ，２０Ｃ）は、複数の割合情報を表示部２４の１つの画面に表示させることができる。また、サーバ１０（又は、他の端末２０Ｂ，２０Ｃ）は、上記と同様に、複数の割合情報と、他の情報（一例として、勤怠情報又は売上情報）とに基づいて、処理情報を生成することが可能である。
又は、１つの端末２０で処理情報が生成された場合、１つの端末２０は、通信Ｉ／Ｆ２２（送信部）を用いて、生成した処理情報をサーバ１０（又は、他の端末２０Ｂ，２０Ｃ）に送信してもよい。この場合、サーバ１０（又は、他の端末２０Ｂ，２０Ｃ）は、複数の端末２０から送信された処理情報を記憶し、複数の処理情報に基づく画像を表示部２４に表示してもよい。
また、サーバ１０（又は、他の端末２０Ｂ，２０Ｃ）は、送信された割合情報及び処理情報に含まれる割合が不自然な場合、制御部１１又は制御部２１の制御処理によって、ディスプレイ１３又は表示部２４に警告表示を行ってもよい。この場合、端末２０Ａでは、割合警告部２１２による警告表示を行わなくてもよく、警告表示を行ってもよい。
すなわち、サーバ１０（又は、他の端末２０Ｂ，２０Ｃ）は、割合情報又は処理情報に含まれる割合が予め定められた値を超える場合、端末２０Ａで入力された工数比率に関しての入力間違いの可能性、又は、第１項目又は第２項目の作業が適切に行われていない可能性が有るとして、ディスプレイ１３又は表示部２４に警告表示を行う。
この警告表示は、プロジェクトの上長等によって確認される。警告表示を確認した上長は、例えば、端末２０のユーザに対して、入力された工数比率に関して確認を取ることができる。
＜第２実施形態＞
第２実施形態は、情報処理装置（端末２０）を用いて支払いの管理を行う形態である。
具体例として、第２実施形態では、食事会等に参加した複数のメンバに対して、食事代の支払いを求める場合（割り勘処理）に用いられる情報処理装置（端末２０）の一例について説明する。
＜第２実施形態の構成＞
情報処理装置（端末２０）は、比率入力部２１０と、総負担額処理部と、精算部と、通信部（通信Ｉ／Ｆ２２）と、を備える。総負担額処理部及び精算部は、後述する割合処理部２１１の一機能として実現されてもよいし、別機能として実現されてもよい。割り勘対象である各ユーザは、端末２０（ユーザ端末）を有している。情報処理装置（端末２０）は、複数の端末２０（ユーザ端末）のうちの１つである。なお、食事会等に参加したメンバのうちの一部は、端末２０を有していない場合、又は、割り勘のためのアプリを端末にインストールしていない場合がある。この場合、情報処理装置（端末２０）は、一部のユーザのために予め固定値（所定の金額）が設定されると、食事会の費用からその固定値を差し引いた金額について後述する割り勘処理を行ってもよい。
複数の第１項目は、複数の端末２０間にて共同で支払いをするにあたっての各端末２０での負担額に関する項目である。複数の第１項目は、例えば、食事会等に参加したメンバの名前等である。ユーザの負担比率（負担の程度）は、食事会等の費用を按分するために入力される数値である。例えば、比率は、会社内のメンバで食事会等に行った場合、上長が高く、年少者が低くされる等、端末２０（２０Ａ）のユーザによって適宜入力される値である。この比率の入力は、幹事のみが入力可能としても良いし、幹事のみでなく、端末２０を有する各参加者も入力可能としてもよい。「負担比率」は、「比率」、「割合」又は「度合い」と言うことが可能である。
なお、複数の第１項目は、上記の一例に限定されることはなく、例えば、ある商品を複数のメンバで共同購入する場合の共同メンバの名前等であってもよい。
総負担額処理部は、複数の端末２０（ユーザ端末）間にて共同で支払いをするにあたっての総負担額の入力を受け付ける。精算部は、入力された比率および入力された総負担額に基づいて、複数の端末２０（ユーザ端末）における精算額を計算する。通信Ｉ／Ｆ２２は、精算部によって計算された精算額に基づいて、複数の端末２０（ユーザ端末）に対して支払い請求を送信する。
比率入力部２１０は、情報処理装置（端末２０）における入力のみでなく、複数のユーザ端末（端末２０）のうち少なくとも１の端末２０からの入力を、通信Ｉ／Ｆ２２を通じて受け付ける。
上述した総負担額処理部は、想定総負担額の入力を更に受け付けることが好ましい。この場合、精算部は、入力された比率及び入力された想定総負担額に基づいて複数の端末２０における想定精算額を計算する。また、通信Ｉ／Ｆ２２は、精算部により計算された想定精算額に基づいて、複数の端末２０のうち少なくとも１の端末２０に対し、想定支払い金額情報を送信してもよい。又は、通信Ｉ／Ｆ２２は、精算部によって計算された想定精算額に基づいて、複数の端末２０に対し、仮支払い請求を送信してもよい。
この仮支払い請求とは、受信した端末２０において当該仮支払い請求に基づく想定精算額の支払いを行うことにつき承認を得た場合に、例えば、当該想定精算額と同額又は下回る額の精算についての精算指示を受信したときは、端末２０が自動的にその精算処理を行うことを可能とするものや、当該仮支払い請求に基づく想定精算額について支払うことにつき同意が取れたことを端末２０が自動的に情報処理装置に通知することを可能とするものである。
通信Ｉ／Ｆ２２は、想定総負担額が総負担額と同等又は上回った場合であって、送信した仮支払い請求につき承認を得ている端末２０に対して、精算部によって計算された精算額に基づいて、精算指示を送信することが可能である。
また、通信Ｉ／Ｆ２２が、複数の端末２０のうち少なくとも１の端末２０が送信された支払い請求に対応し、その支払い請求における負担額を上回る金額について支払い処理をした旨を受信した場合は、精算部は、その上回り分を考慮してその端末２０以外の複数の端末２０のうち少なくとも１の端末２０についての精算額を再計算してもよい。
例えば、上長の端末２０Ａに、５０００円の支払い請求が来た場合に、上長が８０００円の支払い処理を行ったときには、上回り分の３０００円を総負担額から除いて、上長の端末２０Ａ以外の他の端末２０についての精算額の再計算を行うことにより、他の端末２０については負担額の減額になる。
なお、再計算を行うのは、他の端末２０のうちの少なくとも１の端末２０についてであればよい。即ち、上長の端末２０Ａ以外の他の端末２０のすべてについて再計算を行ってもよく（この場合には、上回り分の３０００円÷端末数が、他の端末２０について減額される）、あるいは、最年少のユーザが所有する端末２０についてのみ再計算を行ってもよい（この場合には、上回り分の３０００円が、最年少のユーザが所有する端末２０について減額される）。
また、比率入力部は、複数の端末２０のうちの少なくとも１の端末２０についての負担金額の入力を更に受け付けることを可能とするよう構成されてもよい。この場合、精算部は、その端末２０について負担金額が入力された場合には、入力された負担金額を総負担額から差し引いた金額と、入力された負担割合に基づき、その端末２０以外の複数の端末２０についての精算額を計算することが好ましい。
これは、上述したように、例えば食事会等に参加したメンバのうちの一部が、割り勘のためのアプリを端末２０にインストールしていない場合のために設けられた処理である。なお、メンバのうちの一部（例えばＡ）が、そもそも端末２０を有していない場合にも、この処理（即ち、入力された負担金額差し引いた、各端末２０及びＡについての精算額の計算）は適用可能であり、この場合には、端末２０を所有していない当該メンバ（例えばＡ）に対して、口頭などで精算額を伝達すれば良い。
また、情報処理装置（端末２０）は、複数の第１項目を表示する表示部２４と、複数の第１項目それぞれについてユーザの負担比率が入力される比率入力部２１０と、複数の第１項目とユーザの負担比率とに基づいた割合情報を記憶する記憶部２８と、割合処理部２１１と、通信Ｉ／Ｆ２２と、を備えていてもよい。上述した総負担額処理部及び精算部は、割合処理部２１１の一機能として実現されてもよいし、別機能として実現されてもよい。
割合処理部２１１は、割合情報を取得し、取得した割合情報について所定の処理を行って処理情報を生成し、処理情報に基づいて表示部２４に表示させる。すなわち、割合処理部２１１は、割合情報と、食事会等の費用である金額情報とを取得し、メンバ毎の割合に基づいて費用を割り当てて、メンバそれぞれの負担金額を算出する。このメンバ毎の負担金額が処理情報となる。割合処理部２１１は、処理情報を記憶部２８に記憶する。
なお、割合情報は、不図示のサーバに記憶されてもよい。割合処理部２１１は、サーバに記憶される割合情報にアクセスして所定の処理を行い、処理情報を生成してもよい。処理情報は、サーバに記憶されてもよいし、端末２０に記憶されてもよい。
通信Ｉ／Ｆ２２（送信部）は、処理情報を外部端末（他の複数の端末２０Ｂ，２０Ｃ）に送信する。すなわち、通信Ｉ／Ｆ２２は、第１項目として登録されたメンバのあて先が指定されることにより、処理情報を他の複数の端末２０Ｂ，２０Ｃ（メンバ宛）に送信する。
ここで、他の端末２０Ｂ，２０Ｃは、処理情報を受信すると、ユーザの操作に基づいて、受信した処理情報に含まれる割合を変更することが可能である。この場合、他の端末２０Ｂ，２０Ｃは、処理情報に含まれる割合を変更するため、ユーザ間の負担比率を変更して割合を再生成することが可能である。他の端末２０Ｂ，２０Ｃは、再生成した割合に基づいて割合変更指示情報を生成し、その割合変更指示情報を端末２０に送信することが可能である。
なお、他の端末２０Ｂ，２０Ｃは、自身のユーザの設定された割合（負担金額）を超える負担金額を支払うことが可能である。他の端末２０Ｂ，２０Ｃは、自身のユーザの（割合）負担金額を超える（割合）負担金額を再設定した場合、負担金額を再計算し、処理情報を生成する。
一方、他の端末２０Ｂ，２０Ｃは、自身のユーザの設定された割合（負担金額）よりも少ない負担金額の支払いで済ませることは不可能であり、仮に他の端末２０Ｂ，２０Ｃで、自身のユーザの（割合）負担金額よりも少ない（割合）負担金額を再設定しようとすると、エラーとなる。このような再設定を認めると、他のユーザの不利益になるからである。
端末２０の通信Ｉ／Ｆ２２（受信部）は、割合情報に含まれる割合を変更するための割合変更指示情報を他の端末２０Ｂ，２０Ｃから受信する。
割合変更部２１３は、通信Ｉ／Ｆ２２で受信した割合変更指示情報に基づいて、記憶部２８に記憶される処理情報に含まれる割合を変更する。割合変更部２１３は、割合変更指示情報には食事会等に参加したメンバ（第１項目）の割合について変更した割合が記録されているため、割合変更指示情報に記録された割合に基づいて、記憶部２８に記憶される処理情報の割合を変更する。
端末２０は、記憶部２８に記憶される処理情報の割合を変更した場合、通信Ｉ／Ｆ２２を用いて変更後の処理情報を他の複数の端末２０に送信することが可能である。
他の端末２０Ｂ，２０Ｃは、変更後の処理情報を受信すると、受信した処理情報に基づき、他の端末２０Ｂ，２０Ｃに予め搭載される支払機能（図示せず）により、各ユーザに応じた負担金額を支払うことが可能である。
この割合情報変更指示情報は、例えば、他の端末２０Ｂのユーザが、手持ち金が少ない場合に、割合の減少（負担金額の減額）を求めて、幹事や上長等の権限の有るユーザの端末２０（例えば、主端末２０Ａとする）に対して送信することが考えられ、主端末２０Ａのユーザは、それを承認することにより、変更後の割合（負担金額）が適用される。
ここで、第２実施形態の具体例を示すと、図７に示すように、主端末２０Ａの表示部２４には、複数（本例では４つ）の端末２０Ａ，２０Ｂ，２０Ｃ，２０Ｄの各々に対応する入力領域として、比率入力部７０１である複数の比率入力領域７０１Ａ，７０１Ｂ，７０１Ｃ，７０１Ｄと、第１項目７０２である複数のユーザ名入力領域７０２Ａ，７０２Ｂ，７０２Ｃ，７０２Ｄと、負担金額入力部７０３である複数の負担金額入力領域７０３Ａ，７０３Ｂ，７０３Ｃ，７０４Ｄが設けられる。
また、表示部２４には、１の想定総負担額入力部７１１と、１の総負担額入力部７２１が設けられると共に、複数の端末２０Ａ～２０Ｄの各々に対応する処理情報の表示領域として、比率入力領域７０１Ａ～７０１Ｄに入力された比率に基づく各端末２０の割合情報を表示する割合情報表示領域７０３Ａ，７０３Ｂ，７０３Ｃ，７０３Ｄと、想定総負担額入力部７１１に入力された想定総負担額に基づく想定精算額を表示する想定精算額表示領域７１１Ａ，７１１Ｂ，７１１Ｃ，７１１Ｄと、総負担額入力部７２１に入力された総負担額に基づく精算額を表示する精算額表示領域７２１Ａ，７２１Ｂ，７２１Ｃ，７２１Ｄが設けられ、さらに、複数の端末２０Ａ～２０Ｄの各々に対応して、各想定精算額表示領域７１１Ａ～７１１Ｄに示す想定精算額の支払い承認の有無を示す支払い承認表示領域７１２Ａ，７１２Ｂ，７１２Ｃ，７１２Ｄが設けられる。ここで想定総負担額入力部７１１及び総負担額入力部７２１が、前記総負担額処理部を構成する。
この主端末２０Ａの所有者（本例では、上長）は、まず第１項目７０２である複数のユーザ名入力領域７０２Ａ～７０２Ｄに、食事会の参加メンバの名前（本例では、上長Ａ，中堅Ｂ，中堅Ｃ，新人Ｄ）を入力する。この入力は、上長の手入力でもよく、また各メンバが所有する端末２０Ａ～２０Ｄから受信した情報（例えば電話番号等の、各メンバの識別情報）に基づく自動入力でもよく、あるいは手入力と自動入力の組み合わせでもよい。
次に上長は、比率入力部７０１である複数の比率入力領域７０１Ａ～７０１Ｄに、各メンバの負担比率（本例では、３：２：２：１）を入力する。この入力は、上長の手入力でもよく、あるいは他の情報に基づく自動入力でもよい。例えば、各メンバが所有する端末２０Ａ～２０Ｄから受信した各メンバの属性情報（例えば、年齢、性別等）に基づいて負担比率が自動入力されてもよい。例えば、年齢の高いメンバは、年齢の低いメンバよりも高い負担比率が入力されるようにしてもよい。この自動入力によれば、手入力に比べて手間が軽減され、また他の情報に基づく客観的な負担比率が入力されることにより、入力者の恣意が排除される。例えば、上長ではなく、部下が幹事を務めて負担比率を決定する場合などにも有効である。
このメンバ名及び負担比率の入力が終了した後に、割合計算の操作（例えば、決定ボタンの押下）を行うと、割合処理部２１１により各メンバの負担割合が計算されて、計算された負担割合が記憶部に記憶される。本例では、メンバ４人の負担比率が３：２：２：１なので、メンバ４人の負担割合は３７．５％：２５％：２５％：１２．５％となり、該負担割合が割合情報表示領域７０３Ａ，７０３Ｂ，７０３Ｃ，７０３Ｄに表示される。なお、負担割合を、整数とするか、小数点以下何桁まで許容するかは、任意に設定可能である。
次に上長は、図８に示すように、想定総負担額入力部７１１に、想定総負担額を入力し、想定精算額計算の操作（例えば、決定ボタンの押下）を行うと、入力された想定総負担額と、前記負担割合とに基づいて、精算部により各メンバの想定精算額が計算されて、計算された想定精算額が各想定精算額表示領域７１１Ａ～７１１Ｄに表示される。例えば、想定総負担額が４００００円である場合には、メンバ４人の負担比率は３：２：２：１なので、メンバ４人の想定精算額は、１５０００円：１００００円：１００００円：５０００円となる。
なお、上長の手入力、又は各端末から受信した情報に基づく自動入力により、負担金額入力領域７０４Ａ，７０４Ｂ，７０４Ｃ，７０４Ｄのいずれかに負担金額が入力された場合には、その入力された負担金額を除いて、精算部により各メンバ（負担金額を直接入力した対象となるユーザの端末２０は除く）の想定精算額が計算されて、計算された想定精算額が各想定精算額表示領域７１１Ａ～７１１Ｄに表示される。
例えば、図９に示すように、負担金額入力領域７０４Ｂに１２０００円が入力された場合（即ち、Ｂさんが元々の想定精算額１００００円よりも多く負担する場合）には、想定総負担額入力部７１１に入力された４００００円から想定精算額表示領域７１１Ｂに入力された１２０００円を除いた２８０００円を、残りのメンバ３人Ａ，Ｃ，Ｄの負担比率に基づいて３：２：１で按分し、メンバ３人Ａ，Ｃ，Ｄの想定精算額は、１４０００円：９３３３円：４６６７円となる。
また、図１０に示すように、負担金額入力領域７０４Ｂに５０００円が入力された場合（即ち、Ｂさんが元々の想定精算額１００００円よりも少なく負担する場合）には、想定総負担額入力部７１１に入力された４００００円から想定精算額表示領域７１１Ｂに入力された５０００円を除いた３５０００円を、残りのメンバ３人Ａ，Ｃ，Ｄの負担比率に基づいて３：２：１で按分し、メンバ３人Ａ，Ｃ，Ｄの想定精算額は、１７５００円：１１６６７円：５８３３円となる。
なお、複数の負担金額入力領域に負担金額が入力された場合にも、それらの入力された負担金額の合算額を除いて、精算部により各メンバの想定精算額が計算される。また、負担金額の入力は、想定総負担額の入力前に行われてもよく、後述する総負担額の入力前に行われてもよい。この図９及び図１０に示す例によれば、１以上のメンバについて、負担割合とは別途の負担金額が設定されることにより、負担割合が変更されていることになる。
こうして計算及び表示された各メンバの想定精算額は、主端末２０Ａから他の端末２０Ｂ，２０Ｃ，２０Ｄに対して送信され、具体的には、端末２０Ｂには領域７３１Ｂの内容，端末２０Ｃには領域７３１Ｃの内容，端末２０Ｄには領域７３１Ｄの内容が送信される。ここで想定精算額を送信するのは、他の端末のすべてではなく、少なくとも１の端末であっても良い。このように、想定精算額が送信されることにより、送信されたメンバは想定精算額を把握することができ、さらには最終的な精算額をイメージすることができる。
次に上長は、図１１に示すように、総負担額が確定すると、総負担額入力部７１２に、総負担額を入力し、精算額計算の操作（例えば、決定ボタンの押下）を行うと、該入力された総負担額と、前記負担割合とに基づいて、精算部により各メンバの精算額が計算されて、該計算された精算額が各精算額表示領域７１２Ａ～７１２Ｄに表示される。例えば、総負担額が３８４００円である場合には、メンバ４人の負担比率は３：２：２：１なので、メンバ４人の精算額は、１４４００円：９６００円：９６００円：４８００円となる。
なお、前記負担金額入力領域７０３Ａ，７０３Ｂ，７０３Ｃ，７０４Ｄのいずれかに負担金額が入力された場合には、図示しないが、前記想定精算額を計算した場合と同様に、入力された負担金額を除いて、精算部により各メンバの精算額が計算されて、計算された精算額が各精算額表示領域７１２Ａ～７１２Ｄに表示される。
そして、計算された精算額に基づいて、主端末２０Ａから他の端末２０Ｂ，２０Ｃ，２０Ｄに対して、支払い請求が送信され、主端末２０Ａ及び支払い請求を受信した他の端末２０Ｂ，２０Ｃ，２０Ｄが、それぞれの精算額の支払い処理を行うことにより、一連の決済処理が終了する。この支払い処理は、主端末２０Ａが他の端末２０Ｂ，２０Ｃ，２０Ｄから精算額の支払いを受け付けることであるが、端末を所持していないメンバや端末に支払いアプリがインストールされていないメンバに関しては、主端末２０Ａのユーザが、現金で精算額の支払いを受け付けることになる。この場合、主端末２０Ａでは、現金での精算額の支払いが行われたことに基づく所定の入力操作が完了したことを、支払い処理が行われたこととして判定してもよい。例えば、主端末２０Ａでは、現金での支払いを行ったメンバの負担金額入力領域に、支払われた金額を入力することにより、そのメンバに関する精算額の支払い処理が行われたと判定する。
なお、前記計算された想定精算額に基づいて、主端末２０Ａから他の端末２０Ｂ，２０Ｃ，２０Ｄに対して、仮支払い請求が送信されるようにしても良い。主端末２０Ａは、前記図８に示す想定総負担額の入力及び各メンバの想定精算額の計算を行った後、仮支払い請求を送信し、この仮支払い請求を受信した他の端末２０Ｂ，２０Ｃ，２０Ｄから、仮支払い請求を承認する旨を受信すると、図１２に示すように、仮支払い請求を受信した端末に対応する支払い承認表示領域（７１２Ａ，７１２Ｂ，７１２Ｃ，７１２Ｄ）に、承認を示す「有」を表示する。一方、仮支払い請求を承認する旨を受信しないと、非承認を示す「無」を表示する。
そして、すべての端末について「有」が記録されている場合には、主端末２０Ａは、精算額が計算された後に、各端末に対して、精算指示を送信し、精算指示を受信した各端末が、当該精算額の支払い処理を行うことにより、一連の決済処理が終了する。これにより、スムーズな決済を行うことができる。一方、「無」が記録されている端末が存在する場合（仮支払い請求を承認しないメンバが居る場合）には、前記負担金額入力領域７０３Ａ，７０３Ｂ，７０３Ｃ，７０３Ｄのいずれかに負担金額を入力することにより、負担金額の割合を変更したり、又は、比率入力領域７０１への手入力により、負担比率を変更したりしてもよい。あるいは、次に述べる図６に示すように、割合変更指示情報を受け付けても良い。
＜第２実施形態の情報処理方法＞
次に、第２実施形態の情報処理方法について説明する。
なお、第２実施形態の情報処理方法の説明では、第１実施形態と同様の部分の説明を省略する。図５に示すステップＳＴ１１～ＳＴ１７の処理については、第２実施形態の処理（一例として、割り勘処理）にも適用することができる。以下では、第２実施形態で特徴的な部分について説明する。
図６は、第２実施形態に係る情報処理方法について説明するためのフローチャートである。
ステップＳＴ２１において、通信Ｉ／Ｆ２２（送信部）は、割合処理部２１１で生成された処理情報を他の複数の端末２０（２０Ｂ，２０Ｃ）に送信する。他の端末２０Ｂ，２０Ｃは、例えば、第１項目として登録されたメンバが所有する端末２０である。
ステップＳＴ２２において、割合変更部２１３は、通信Ｉ／Ｆ２２（受信部）によって、他の複数の端末２０（２０Ｂ，２０Ｃ）のいずれかから割合を変更するための割合変更指示情報を受信したか判断する。割合変更指示情報を受信した場合（Ｙｅｓ）、処理はステップＳＴ２３に進む。割合変更指示情報を受信していない場合（Ｎｏ）、処理はステップＳＴ２５に進む。
ステップＳＴ２３において、割合変更部２１３は、割合変更指示情報に基づいて、記憶部２８に記憶される処理情報に含まれる割合を変更する。
一例として、処理情報に含まれる割合は、「第１項目（メンバＡ）」の負担比率が「１」、「第１項目（メンバＢ）」の負担比率が「１」及び「第１項目（メンバＣ）」の負担比率が「２」であることに基づいて得られるとする。そして、割合変更指示情報に含まれる割合の変更の指示が、「第１項目（メンバＡ）」の負担比率が「０」、「第１項目（メンバＢ）」の負担比率が「１」及び「第１項目（メンバＣ）」の負担比率が「３」であることに基づいた割合であったとする。この場合、割合変更部２１３は、割合変更指示情報に基づいて割合を変更する。さらに、割合変更部２１３は、既に取得している食事会等の費用を示す金額情報に基づいて、メンバ毎の割合に基づいて費用を割り当ててメンバそれぞれの負担金額を再度計算し、処理情報を再生成する。
割合変更部２１３は、割合変更指示情報に基づいて処理情報を変更した場合、変更した処理情報を記憶部２８に記憶する。
ステップＳＴ２４において、通信Ｉ／Ｆ２２（送信部）は、ステップＳＴ２３において変更された処理情報を、ステップＳＴ２１で送信した他の複数の端末２０（２０Ｂ，２０Ｃ）と同一の端末２０（２０Ｂ，２０Ｃ）に送信する。
ステップＳＴ２５において、制御部２１は、ステップＳＴ２４で送信した処理情報に基づいた負担金額を他の複数の端末２０（２０Ｂ，２０Ｃ）それぞれから支払いを受け付ける。
ステップＳＴ２５の後、処理は終了する。
＜第２実施形態の効果＞
次に、第２実施形態の情報処理装置（端末２０）は、以下の効果を奏する。
情報処理装置（端末２０）は、割合処理部２１１で生成された処理情報を他の端末２０Ｂ，２０Ｃに送信する送信部を備える。
これにより情報処理装置は、一例として、食事会等の参加者（メンバ）が割り勘処理をする時など、負担金額の情報を他の端末２０Ｂ，２０Ｃに送信することができる。
情報処理装置は、負担割合の設定を、幹事が全額を店に対して支払うタイミングより前に行えることとしてもよいし、支払うタイミングよりも後に行えることとしてもよい。
情報処理装置に対し、負担割合の設定が幹事による店に対しての支払いタイミングより前に行われる場合、その設定された負担割合に基づいて、幹事による店への支払いが完了したとの確認がなされたら、店への支払金額に基づいて食事会等のメンバ（端末２０）に負担金額の要求を自動的に行うこととしてもよい。また、情報処理装置は、支払い要求を行う代わりに固定された負担割合に基づいて自動的に精算させるよう、精算要求を送信することとしてもよい。この場合、情報処理装置には、好ましくは、幹事は想定される精算金額を把握して、前もって想定精算金額の情報を入力しておき、その想定精算金額によって定まる想定負担金額情報を少なくとも１の端末２０に送信しておくこととしてもよい。更に好ましくは、実際の精算額を超える金額を想定精算金額として設定しておき、情報処理装置に入力しておき、その想定精算金額によって定まる想定負担金額情報を各端末２０に送信し、その想定負担金額情報について支払うことにつき承諾する旨の情報を予め得ておくことで、実際の精算金額による精算として、各端末２０における支払いを自動的に行わせることとしてもよい。こうすることで、より効率的な割り勘処理を行うことができる。すなわち、情報処理端末は、想定総負担額が総負担額と同等又は上回った場合であって、送信した仮支払い金額情報につき承認を得ている他の端末２０Ｂ，２０Ｃに対して、精算部によって計算された精算額に基づいて、精算指示を他の端末２０Ｂ，２０Ｃに送信してもよい。
負担割合の設定が幹事による店に対する支払いのタイミングより後に行われる場合、例えば、食事会等の幹事がまず全額の支払いを店に対して行い、食事会等を解散した後に、情報処理装置は、実際の精算金額に基づいて各端末２０に対して負担金額情報を送信し、それぞれの負担金額を幹事に支払わせる（送金する）ことで、割り勘が成立させることとしてもよい。すなわち、情報処理装置は、食事会等の場所及び時間において割り勘処理を行う必要がない。
支払いにおいては、幹事がいったん食事会等を行った店にて総額の支払いを行い、その後、幹事に対して各メンバから負担金額を送金する方法や、食事会等を行った店にて複数者によるクレジットカード支払いによる割り勘を成立させる方法などが挙げられるが、これらに限られるものではない。
また、食事会等を行う場合、その食事会等の費用の総額が予めある程度の精度で分かっている場合がある。この場合には、情報処理装置（端末２０）は、想定金額が入力されると、割合情報に基づいて計算された想定負担金額を全てまたは一部の各端末２０に送信し、食事会等の参加者に負担金額のおおよその規模を認識してもらうことができる。さらに、情報処理装置は、実際の負担金額が想定負担金額以下であれば、自動的に精算してもよいことについて参加者の承認を予め受けている場合には、実際の負担金額についての支払い請求の情報を各端末２０に送信するとともに、その負担金額について自動的に精算するよう精算指示を送信することとしてもよい。
また、情報処理装置では、割合の代わりに実際の負担金額が入力されることも可能である。この場合、情報処理装置（端末２０）は、食事会等の費用の総額から負担金額を差し引いた金額と、負担割合に基づいて各端末２０（負担金額を直接入力した対象となるユーザの端末２０は除く）についての負担額を計算し、各端末２０に支払い請求を送信することとしてもよい。
また、端末２０において、支払い請求を受信したことを受けて、ユーザ（メンバ）はその支払い請求に対応する負担金額を超える金額について支払いを行うことを可能としてもよい。こうすることにより、その支払い処理に関する情報を受信した情報処理装置は、送信した支払い請求に対応する負担金額を上回った分を考慮して、まだ支払い処理が完了していない残りの端末２０における負担金額を再計算し、その再計算結果に基づいて改めて端末２０に支払い請求を送信することとしてもよい。
情報処理装置（端末２０）は、処理情報に含まれる割合を変更するための割合変更指示情報を他の端末２０Ｂ，２０Ｃから受信する通信Ｉ／Ｆ２２（受信部）と、割合変更指示情報に基づいて、記憶部２８に記憶される処理情報に含まれる割合を変更する割合変更部２１３と、を備える。
これにより、情報処理装置は、処理情報に含まれる割合を変更することができる。
なお、上記の効果等は、情報処理装置が備える、総負担額処理部及び精算部等の処理により奏されてもよい。
＜第２実施形態の変形例＞
なお、第２実施形態では、ステップＳＴ２１～ステップＳＴ２５の処理を実行する例で説明した。しかし、第２実施形態は、この一例に限定されることはない。
すなわち、ステップＳＴ２１で通信Ｉ／Ｆ２２（送信部）が処理情報を他の端末２０Ｂ，２０Ｃに送信した場合、他の端末２０Ｂ，２０Ｃで割合処理情報に含まれる割合が変更されると、変更後の処理情報は第１項目に登録されるメンバが所有する端末２０全てに送信されてもよい。この場合、処理情報を変更した他の端末２０Ｂ，２０Ｃは、変更後の処理情報を自身に送信しなくてもよいし、自身に送信してもよい。そして、情報処理装置（端末２０）は、ステップＳＴ２４の処理を省略してもよいし、省略しなくてもよい。
＜第３実施形態＞
第３実施形態は、第２実施形態で説明した、割り勘処理に用いられる情報処理装置（端末２０）の具体的な適用例ついて説明する。
本実施形態は、イベントの企画、告知、代金徴収および決済について、サーバ１０が、端末２０または端末２０を使用するユーザに、割り勘処理に基づくイベント管理サービスを提供することで実現を行うものである。
本実施形態では、イベントの代金徴収および決済において、端末２０または端末２０のユーザは、電子マネーと、電子ポイントとを用いて支払い（送金）を行う。
ここで、「電子マネー」とは、物理的貨幣と区別される電子的な貨幣であって、後述するアプリケーション（メッセージングアプリケーション、イベント企画サブプログラム）において管理される端末２０または端末２０のユーザが所有する電子的な貨幣のことを意味する。電子マネーは、「電子貨幣」と表現してもよいし、しなくてもよい。
「電子ポイント」とは、電子マネーの使用に伴い付与される電子的な特典である。本実施形態では、電子ポイントは、電子マネーを用いた支払いに充当して使用可能な貨幣価値を持つこととする。また、電子ポイントを、電子マネーの一つの形態としてもよいし、そのようにしなくてもよい。
本実施形態では、電子ポイントは、支払い（送金）において、端末２０または端末２０のユーザにより明示的に使用を選択されない限り使用（支払いに充当）されず、電子マネー残高から優先的に支払いが行われることとする。すなわち、電子ポイントは、電子マネーに比べて高い貯蓄性を有する。
なお、端末２０または端末２０のユーザの選択によらず、電子ポイントが使用されるようにしてもよいし、しなくてもよい。
＜第３実施形態の構成＞
図１３は、第３実施形態に係る通信システム１の構成の一例を示す図である。
第３実施形態に係る通信システム１では、端末２０（端末２０Ａ，端末２０Ｂ，端末２０Ｃ，２０Ｄ）は、図１に示す第１実施形態に係る端末２０と比べて、位置検出部２９１と、時計部２９２とをさらに備える。
時計部２９２は、端末２０の内蔵時計であり、時刻情報（計時情報）を出力する。時計部２９２は、限定ではなく例として、水晶発振器を利用したクロック等を有して構成される。時計部２９２は、限定ではなく例として、計時部や時刻情報検出部と表現することもできる。
なお、時計部２９２は、ＮＩＴＺ（Network Identity and Time Zone）規格等を適用したクロックを有していてもよいし、有していなくてもよい。
位置検出部２９１は、制御部２１が自己の端末２０の位置を算出（測定）するために必要な情報（以下、「位置算出用情報」と称する。）を検出（計測）する機能部である。位置検出部２９１は、限定ではなく例として、位置算出用センサ部と表現することもできる。
位置検出部２９１は、限定ではなく例として、ＧＰＳ（Global Positioning System）等の衛星測位システムを利用して端末２０の位置を算出するためのセンサやユニットである衛星測位センサ（衛星測位ユニット）や、慣性航法システムを利用して端末２０の位置を算出するためのセンサやユニットである慣性計測センサ（慣性計測ユニット（ＩＭＵ（Inertial Measurement Unit）））等を含む。
衛星測位ユニットは、限定ではなく例として、不図示のアンテナで受信される測位用衛星から発信されている測位用衛星信号を含むＲＦ（Radio Frequency）信号をデジタル信号に変換するＲＦ受信回路や、ＲＦ受信回路から出力されるデジタル信号に対して相関演算処理等を行って測位用衛星信号を捕捉し、測位用衛星信号から取り出した衛星軌道データや時刻データ等の情報を、位置算出用情報として出力するベースバンド処理回路等を有する。
慣性計測ユニットは、慣性航法演算によって端末２０の位置を算出するために必要な情報を検出するセンサである慣性センサを有する。慣性センサには、限定ではなく例として、３軸の加速度センサや３軸のジャイロセンサが含まれ、加速度センサによって検出された加速度と、ジャイロセンサによって検出された角速度とを、位置算出用情報として出力する。
＜機能構成＞
本実施例において、サーバ１０の記憶部１５には、サーバ１０のメイン処理として実行されるサーバメイン処理プログラムの他、限定ではなく例として、メッセージングアプリケーション管理処理として実行されるメッセージングアプリケーション管理処理プログラムが記憶される。
メッセージングアプリケーション管理処理プログラムは、後述のイベント企画サブプログラムをサブルーチンプログラムとして含む。
また、記憶部１５には、データとして、限定ではなく例として、メッセージングアプリケーションユーザ登録データと、イベント管理データベースと、ユーザ管理データとが記憶される。
メッセージングアプリケーションユーザ登録データは、メッセージングアプリケーションによるサービスを利用する端末２０または端末２０のユーザの登録データであり、限定ではなく例として、ユーザ名と、端末電話番号と、端末メールアドレスと、メッセージングアプリケーションＩＤと、認証パスワードと、その他登録情報とが関連付けて記憶される。
ユーザ名は、メッセージングアプリケーションによるサービスを利用する端末２０のユーザの名称であり、例えば、端末２０のユーザがメッセージングアプリケーションを最初に利用する際に登録する名称が記憶される。
端末電話番号は、このユーザ名のユーザの端末２０の電話番号であり、例えば、端末２０のユーザがメッセージングアプリケーションを利用する際に最初に登録する端末２０の電話番号が記憶される。
端末メールアドレスは、このユーザ名のユーザの端末２０のメールアドレスであり、例えば、端末２０のユーザがメッセージングアプリケーションを利用する際に最初に登録する端末２０のメールアドレスが記憶される。
端末電話番号や端末メールアドレスは、端末２０を識別するための識別情報の一例である。
メッセージングアプリケーションＩＤは、端末２０または端末２０のユーザを識別するための識別情報として機能するＩＤであり、例えばサーバ１０によって、メッセージングアプリケーションを利用する端末２０毎または端末２０のユーザ毎に固有に設定されるＩＤである。
認証パスワードは、このユーザ名のユーザの端末２０において、メッセージングアプリケーションの機能として設けられた各種の機能を利用する際に実行する認証処理で、端末２０に入力を要求する認証用のパスワードであり、例えばユーザによって設定されたパスワードが記憶される。
その他登録情報は、このユーザ名のユーザのその他の登録情報であり、限定ではなく例として、メッセージングアプリケーションにおいてユーザが使用するアイコンの画像データであるユーザアイコン用の画像等の情報がこれに含まれる。
なお、上記の各種のユーザ情報は、サーバ１０が提供可能な他のアプリケーション（例えば、イベント企画サブプログラムと連携して動作する電子マネーによる支払いアプリケーション）とメッセージングアプリケーションとで共通のユーザ情報としてサーバ１０で記憶・管理するようにしてもよいし、別のユーザ情報としてサーバ１０で記憶・管理するようにしてもよい。
イベント管理データベースは、イベント管理サービスでイベントの管理にあたり利用されるデータベースであり、イベント管理データベースには、イベント管理サービスを利用したイベントごとの管理データとしてイベント管理データが記憶される。
イベント管理データには、限定ではなく例として、イベントＩＤと、イベントタイトルと、イベント日時と、頭割りイベント会費と、イベントメンバデータとが記憶される。
イベントＩＤは、端末２０を使用するユーザによって企画されるイベントを識別するための識別情報として機能するＩＤである。イベントＩＤには、例えばサーバ１０によってイベント毎に固有に設定されるＩＤが記憶される。
イベントタイトルは、イベントの識別を容易にするためのタイトル（表題）である。イベントタイトルには、例えば端末２０を使用するユーザによってイベント企画時に入力されるイベントのタイトルが記憶される。
イベント日時は、企画されるイベントを実行する予定の日時に関する情報である。イベント日時には、例えば端末２０を使用するユーザによって設定される、イベントを行う予定の日付ならびに開始予定時刻・終了予定時刻が記憶される。
頭割りイベント会費は、均等割りを行った場合における、ユーザがイベントへ参加する際に必要な一人当たりの金額である。頭割りイベント会費には、例えば端末２０を使用するユーザによって設定される金額が記憶される。
イベントメンバデータは、イベント管理サービスにおける、このイベントの参加メンバに関するデータであり、限定ではなく例として、メッセージングアプリケーションＩＤと、ユーザ名と、分担割合情報と、寄付金額情報と、参加状況とが関連付けて記憶される。
メッセージングアプリケーションＩＤと、ユーザ名とは、このイベントに招待する、または招待されるユーザを識別するための情報であり、例えば端末２０または端末２０のユーザのメッセージングアプリケーションＩＤと、ユーザ名とが関連付けて記憶される。
分担割合情報は、このイベントで発生するトータルの会費について、招待する、または招待される各ユーザがどのような割合で分担し、負担するのかについて記述される情報である。分担割合情報には、例えば端末２０を使用するユーザによって設定される分担割合が記憶される。
寄付金額情報は、このイベントの寄付依頼に対する寄付金額をユーザごとに記憶する情報である。寄付金額情報には、例えば端末２０または端末２０のユーザが、ユーザの分担割合ごとに計算される会費（参加費）の他に、追加でこのイベントに対して寄付を行った場合の寄付金額が、電子マネーおよび電子ポイントに分けて記憶される。
参加状況は、このイベントに招待されるユーザの出欠に関する状況フラグである。参加状況には、例えば端末２０または端末２０のユーザによって入力される、このイベントにユーザが参加するか、不参加か、もしくは参加を保留するかの情報が記憶される。
ユーザ管理データは、メッセージングアプリケーションユーザ登録データに登録されているユーザ、および、メッセージングアプリケーションを提供する事業者と提携する店舗における電子マネーによる支払い（送金）に関する管理データである。
ユーザ管理データには、限定ではなく例として、端末２０の識別子（限定ではなく例として、メッセージングアプリケーションＩＤ、イベント企画サブプログラム内で用いられるＩＤ、端末電話番号または端末メールアドレス）または店舗の識別子（限定ではなく例として、店舗名、サーバ１０によって店舗毎に固有に設定される店舗ＩＤ、住所、電話番号またはメールアドレス）と関連付けられた、電子マネー口座残高および電子ポイント口座残高を含むデータが記憶される。
＜表示画面例＞
本実施例におけるイベント管理サービスを利用したイベントの企画、告知、代金徴収および決済について、端末２０の表示画面例を参照して説明する。
本実施例では、端末２０が、表示部２４として機能する縦長のディスプレイを有するスマートフォンである場合について説明する。スマートフォンには、入力部として機能するタッチパネルが、そのディスプレイと対向して配置される。
図１４は、端末２０で実行されるメッセージングアプリケーションにおいて表示部２４に表示されるアプリケーション画面の一例を示す図である。
ここで、メッセージングアプリケーションには、限定ではなく例として、メッセージングサービスの一種であるインスタントメッセージングサービス（ＩＭＳ（Instant Messaging Service））の機能が含まれる。
この場合、限定ではなく例として、ＩＭＳの機能に基づき、参加者のアカウントによって、イベントに関するトークルーム画面が表示部２４に表示される。
メッセージングアプリケーションは、限定ではなく例として、参加が認められたユーザによって発せされたメッセージ、アイコンおよび画像などがその発信元とともに時系列順に表示されるトークルームを提供する。トークルームへの参加は、限定ではなく例として、そのトークルームにすでに参加しているユーザによって認められる。トークルームに参加するユーザは、共通の嗜好を有していたり、友人同士であったり、家族であったりする。
本実施例では、ユーザＡ．Ａ、Ｂ．Ｂ、Ｃ．ＣおよびＤ．Ｄの４人の参加者がそれぞれ有する端末２０Ａ、２０Ｂ、２０Ｃおよび２０Ｄにおいて、メッセージングアプリケーションが動作している。端末２０Ａ、２０Ｂ、２０Ｃおよび２０Ｄでは、それぞれユーザＡ．Ａ、Ｂ．Ｂ、Ｃ．ＣおよびＤ．Ｄのアカウントによってメッセージングアプリケーションにログインされるトークルーム画面が表示部２４に表示される。そのトークルームには、限定ではなく例として、定期的に食事会を開催する友人同士のユーザＡ．Ａ、Ｂ．Ｂ、Ｃ．ＣおよびＤ．Ｄの４人の参加が認められていることとする。
図１４に示すアプリケーション画面は、ユーザＡ．Ａの端末２０Ａにおける表示部２４に表示される、メッセージングアプリケーションのアプリケーション画面である。
このアプリケーション画面は、タイトルバー領域２４１と、グループ名表示領域２４２と、ワーク領域２４４とを含む。
タイトルバー領域２４１は、最上段に位置し、このメッセージングアプリケーションのアプリケーション名である「Ｍｅｓｓａｇｉｎｇ Ａｐｐ」と、そのアプリケーション名の右側に位置するアイコンとが表示される。このアイコンは、限定ではなく例として、このメッセージングアプリケーションにログインしているユーザのシンボルとして、そのユーザのアカウントに登録される。以下、このアイコンのことをユーザアイコンとも称する。
ユーザアイコンは、限定ではなく例として、ユーザ自身によって作成されたり、複数のアイコン画像の候補の中からユーザ自身によって選択されたりしたものであり、ユーザごとに異なる図柄を有する。つまり、ユーザアイコンの図柄によってユーザを識別することができる。なお、ユーザアイコンは、サーバ１０によって自動的に作成される構成であってもよいし、そのようにしなくてもよい。本実施例では、ユーザＡ．Ａのユーザアイコンがアプリケーション名の右側に表示される。
グループ名表示領域２４２は、タイトルバー領域２４１の下側に位置し、このメッセージングアプリケーションが提供するトークルームのグループ名が表示される。本実施例では、ユーザＡ．Ａ、Ｂ．Ｂ、Ｃ．ＣおよびＤ．Ｄが参加するトークルームのグループ名である「グルメサークル」と、トークルームの参加ユーザ数を表す「（４）」とが表示される。
なお、タイトルバー領域２４１およびグループ名表示領域２４２は、メッセージングアプリケーションが動作する端末２０の表示部２４において、共通して表示される。
ワーク領域２４４は、グループ名表示領域２４２の下側に位置する。ワーク領域２４４には、トークルーム画面２４６１と、サブプログラム選択画面２４７１とが表示される。トークルーム画面２４６１には、メッセージングアプリケーションが提供するトークルームへの参加が認められたユーザ、またはサーバ１０によって発せされたメッセージおよび画像、ならびにそのメッセージの発信元としてのユーザアイコンなどが、上側から下側へ向かって時系列順になるように表示される。
具体的には、トークルーム画面２４６１には、限定ではなく例として、端末２０ＡのユーザＡ．Ａが発するメッセージは、画面右側から発せられるように表示された吹き出しに含まれる。一方、端末２０Ａのユーザでないユーザ（限定ではなく例として、ユーザＢ．Ｂ、ユーザＣ．ＣおよびユーザＤ．Ｄ）が発するメッセージは、画面左側に位置し、そのメッセージを発したユーザのユーザアイコンから発せられるように表示された吹き出しに含まれる。ユーザＤ．Ｄが時刻「１１：０９」に「秋の食事会はどうしましょうか？」のメッセージを発したのに対して、ユーザＡ．Ａが時刻「１１：１７」に「おすすめのレストランがあるので私が幹事をしますね」のメッセージで返答する。つまり、ユーザＡ．Ａが、幹事となり、端末２０を操作することによってサーバ１０が提供するイベント管理サービスを利用し、イベントの立案、メンバの招集、予算設定および会計などを行うものとして説明する。
サブプログラム選択画面２４７１は、トークルーム画面２４６１の下側に表示され、メッセージングアプリケーションの中で利用可能なプログラム（以下では、サブプログラムとも称する。）を起動するためのアイコンが表示される。本実施例では、サブプログラム選択画面２４７１には、「ファイル」のアイコンと、「連絡先」のアイコンと、「位置情報」のアイコンと、「ギフト」のアイコンと、「送金」のアイコンと、「パーティー」のアイコンと、が表示される。なお、サブプログラム選択画面２４７１は、限定ではなく例として、左上に位置する×印のアイコンをタッチすることで、最小化することができる。
図１５は、図１４に示すアプリケーション画面において「パーティー」のアイコンがタッチされた場合に表示されるアプリケーション画面の一例を示す図である。このアプリケーション画面は、タイトルバー領域２４１と、グループ名表示領域２４２と、進行状況表示領域２４３と、ワーク領域２４４とを含む。
進行状況表示領域２４３は、グループ名表示領域２４２とワーク領域２４４との間に位置する。進行状況表示領域２４３には、限定ではなく例として、サブプログラムが段階的に画面を表示させるプログラムである場合において、そのサブプログラムの進行段階が表示される。本実施例では、進行状況表示領域２４３には、「パーティー」のアイコンによって起動されるサブプログラム（以下、イベント企画サブプログラムとも称する。）の現在実行中の段階として、新規イベントの概要を決定する段階を示す「新規イベント」が表示される。なお、限定ではなく例として、「新規イベント」の右側に位置する×印のアイコンをタッチすることで、イベント企画サブプログラムを中止することができる。
本実施例では、ワーク領域２４４には、新規イベント企画画面２４８１が表示される。新規イベント企画画面２４８１の最上部には、タイトル入力欄が配置される。タイトル入力欄では、限定ではなく例として、このイベントのシンボルとして機能するイベント画像アイコン、新規イベントのタイトル名（限定でなく例として、「秋のお食事会」）、およびそのイベントについてのコメントの入力を受け付ける。
タイトル入力欄の下側には、日時入力欄が配置される。日時入力欄では、限定ではなく例として、イベントを行う予定の日付ならびに開始予定時刻および終了予定時刻の入力を受け付ける。本実施例では、イベントを行う予定の日付の入力は、限定ではなく例として、カレンダーアイコンをタッチすることで行われる。イベントの開始予定時刻および終了予定時刻の入力は、限定ではなく例として、時計アイコンをタッチすることで行われる。
日時入力欄の下側には、１人あたりの予算を入力するための予算入力欄が配置される。本実施例では、ユーザがインクリメントボタンおよびデクリメントボタンを操作することで、これらのボタンの右側に位置する予算表示ボックスに表示される予算額が増減する。１人あたりの予算額は、下側の店舗検索ボタンが押されたときに予算表示ボックスに表示された金額に設定される。
予算設定欄の下側には、参加予定メンバを設定するためのメンバ設定欄が配置される。メンバ設定欄の右側には、＋印を有する招待ボタンが表示される。限定ではなく例として、招待ボタン２４８１ｊの左側には、参加予定のユーザのユーザアイコン群（以下、参加予定ユーザアイコン群とも称する。）が表示される。本実施例では、ユーザＡ．Ａ、Ｂ．Ｂ、Ｃ．ＣおよびＤ．Ｄのユーザアイコンが、ユーザ名とともに表示される。なお、幹事であるユーザＡ．Ａのユーザアイコンには、幹事マークが左下に付される。また、各ユーザアイコンの右上には、デフォルトで出席確定マークが付される。
限定ではなく例として、メンバの追加方法は、参加予定ユーザアイコン群２４８１ｋには、初期画面では、幹事であるユーザＡ．Ａのユーザアイコンのみが表示される。ユーザが招待ボタンをタッチする操作をすると、トークルームに参加が認められている、ユーザのユーザアイコンがユーザ名ととともに別ウィンドウに表示される。そして、ユーザが、そのユーザアイコンを選択して決定する操作を行うと、その選択されたユーザのユーザアイコンが参加予定ユーザアイコン群に加えられる。
メンバ設定欄の下側には、店舗を検索する条件を設定するための検索条件設定欄が配置される。検索条件設定欄では、検索条件のユーザによる入力を受け付ける。検索条件は、イベント会場を検索したいエリアまたは最寄り駅、フランス料理、イタリア料理、日本料理、スペイン料理または中華料理などの料理の種別、およびレストラン名である。
検索条件設定欄の下側には、検索条件設定欄で設定した検索条件で店舗検索するための店舗検索ボタンが配置される。
図１６は、図１５に示すアプリケーション画面において店舗検索ボタンがタッチされた場合に表示されるアプリケーション画面の一例を示す図である。このアプリケーション画面は、タイトルバー領域２４１と、グループ名表示領域２４２と、進行状況表示領域２４３と、ワーク領域２４４とを含む。
本実施例では、進行状況表示領域２４３には、イベント企画サブプログラムの現在実行中の段階として、招待するユーザへ送信すべき招待状の作成段階を示す「招待状の作成」が表示される。
本実施例では、ワーク領域２４４には、招待状作成画面２４８２が表示される。招待状作成画面２４８２の最上部には、イベント概要が表示されたイベント概要表示欄が配置される。イベント概要は、検索結果である店舗名、店舗の位置および提供されるサービス、イベントのタイトル、イベントの開催日時ならびに１人当たりの予算を含む。
なお、イベント概要表示欄の右上に位置する、－印の折りたたみボタンをタッチすることで、イベント概要表示欄が最小化される。また、イベント概要表示欄の右側に位置するマップ表示ボタンをタッチすることで、検索された店舗（限定ではなく例として、「レストラン ナーダ」）の周辺の地図が表示される。
イベント概要表示欄の下側には、このイベントの会費の総額を表示するための会費表示欄が配置される。本実施例では、会費表示欄には、限定ではなく例として、参加人数である４人に、４，０００円／人を乗じた「１６，０００円」が「総支払予定金額」として表示される。
会費表示欄の下側には、会費内訳表示欄が配置される。会費内訳表示欄には、限定ではなく例として、このイベントに招待する予定のユーザのユーザアイコンを縦に並べて表示した参加予定ユーザアイコン群が左側に表示される。本実施例では、参加予定ユーザアイコン群には、限定ではなく例として、ユーザＡ．Ａ、Ｂ．Ｂ、Ｃ．ＣおよびＤ．Ｄのユーザアイコンが、この順番でユーザ名とともに縦に並べられる。なお、幹事であるユーザＡ．Ａのユーザアイコンには、幹事マークが左下に付される。
参加予定ユーザアイコン群の右側には、このイベントの会費についてのユーザの分担割合を、そのユーザのユーザアイコンに対応して配置され、その分担割合に応じた横方向の長さを有する表示バーで表示した分担割合表示バー群が配置される。この表示バーには、限定ではなく例として、網掛けが施されている。本実施例では、ユーザＡ．Ａの分担割合と、ユーザＢ．Ｂの分担割合と、ユーザＣ．Ｃの分担割合と、ユーザＤ．Ｄの分担割合との比は、デフォルトで３：１：１：３に設定されている。つまり、ユーザＡ．Ａのユーザアイコンの右側に位置する表示バーの横方向の長さと、ユーザＢ．Ｂのユーザアイコンの右側に位置する表示バーの横方向の長さと、ユーザＣ．Ｃのユーザアイコンの右側に位置する表示バーの横方向の長さと、ユーザＤ．Ｄのユーザアイコンの右側に位置する表示バーの横方向の長さとの比が、３：１：１：３に設定されている。
分担割合表示バー群の右側には、このイベントの会費の総額に、そのユーザの分担割合を乗じて得た額を表示した会費予定額表示欄がユーザアイコンに対応して配置される。本実施例では、限定ではなく例として、このイベントの「総支払予定金額」である「１６，０００円」に、ユーザＡ．Ａに設定された分担割合である３／８を乗じた額の「６，０００円」が、そのユーザのユーザアイコンの右側に位置する会費予定額表示欄に表示される。同様に、「１６，０００円」に、ユーザＢ．Ｂに設定された分担割合である１／８を乗じた額の「２，０００円」が、そのユーザのユーザアイコンの右側に位置する会費予定額表示欄に表示される。同様に、「１６，０００円」に、ユーザＣ．Ｃに設定された分担割合である１／８を乗じた額の「２，０００円」が、そのユーザのユーザアイコンの右側に位置する会費予定額表示欄に表示される。同様に、「１６，０００円」に、ユーザＤ．Ｄに設定された分担割合である３／８を乗じた額の「６，０００円」が、そのユーザのユーザアイコンの右側に位置する会費予定額表示欄に表示される。
幹事であるユーザＡ．Ａのユーザアイコンの右側に位置する会費予定額表示欄の右側には、幹事以外の者であるユーザＢ．Ｂ、Ｃ．ＣおよびＤ．Ｄの少なくともいずれか１人が参加しない場合に、幹事であるユーザＡ．Ａが支払うべき会費の最大額を表示した最大会費予定額表示欄が配置される。本実施例では、限定ではなく例として、ユーザＢ．ＢおよびＣ．Ｃは、「総支払予定金額」である「１６，０００円」を参加人数の４で除した額である４０００円以下の会費を払うため、ユーザＢ．ＢおよびＣ．Ｃの少なくともいずれか１人が参加しない場合、幹事であるユーザＡ．Ａが支払うべき会費は、「６，０００円」より少なくなる。一方、ユーザＤ．Ｄは、「総支払予定金額」である「１６，０００円」を参加人数の４で除した額である４０００円より多い会費を払うため、ユーザＤ．Ｄが参加しない場合、幹事であるユーザＡ．Ａが支払うべき会費は、元々支払うべき会費である６０００円に、ユーザＤ．Ｄが余分に分担している２０００円を加えた「８，０００円」が、最大会費予定額表示欄に表示される。
会費内訳表示欄の下側には、このイベントに参加予定のユーザの分担割合を変更するための分担割合変更ボタンが配置される。分担割合変更ボタンの下側には、このイベントに参加予定のユーザへ招待状のメッセージを送信するための招待状送付ボタンが配置される。
図１７は、図１６に示すアプリケーション画面において分担割合変更ボタンがタッチされた場合に表示されるアプリケーション画面の一例を示す図である。このアプリケーション画面は、タイトルバー領域２４１と、グループ名表示領域２４２と、進行状況表示領域２４３と、ワーク領域２４４とを含む。
本実施例では、進行状況表示領域２４３には、イベント企画サブプログラムの現在実行中の段階として、参加予定のユーザの分担割合を変更する段階を示す「分担割合の変更」が表示される。
本実施例では、ワーク領域２４４には、分担割合変更画面２４８３が表示される。分担割合変更画面２４８３には、円グラフ２４８３ａが配置される。円グラフ２４８３ａは、このイベントに招待する予定のユーザの人数分の扇形部と、その円グラフの中心に位置し、円形を有する中心部とを含む。
本実施例では、円グラフ２４８３ａは、限定ではなく例として、ユーザＡ．Ａ、Ｂ．Ｂ、Ｃ．ＣおよびＤ．Ｄにそれぞれ対応する扇形部２４８３ｂ、２４８３ｃ、２４８３ｄおよび２４８３ｅと、中心部２４８３ｆとを含む。中心部２４８３ｆには、このイベントの「総支払予定金額」である「１６，０００円」が表示される。
扇形部２４８３ｂ、２４８３ｃ、２４８３ｄおよび２４８３ｅの中心角の和は、３６０°である。扇形部２４８３ｂ、２４８３ｃ、２４８３ｄおよび２４８３ｅの各々の中心角の大きさは、デフォルトでは、３６０°に、対応のユーザの分担割合を乗じた角度である。
具体的には、限定ではなく例として、扇形部２４８３ｂの中心角の大きさは、デフォルトでは、３６０°に、ユーザＡ．Ａの分担割合である３／８を乗じた１３５°である。扇形部２４８３ｃの中心角の大きさは、デフォルトでは、３６０°に、ユーザＢ．Ｂの分担割合である１／８を乗じた４５°である。扇形部２４８３ｄの中心角の大きさは、図１７に示す場合と異なるが、デフォルトでは、３６０°に、ユーザＣ．Ｃの分担割合である１／８を乗じた４５°である。扇形部２４８３ｅの中心角の大きさは、図１７に示す場合と異なるが、デフォルトでは、３６０°に、ユーザＤ．Ｄの分担割合である３／８を乗じた１３５°である。
そして、扇形部２４８３ｂ、２４８３ｃ、２４８３ｄおよび２４８３ｅは、限定ではなく例として、この順で周方向に連続するように時計回りに並べられて表示される。
扇形部２４８３ｂには、デフォルトでは、ユーザＡ．Ａのユーザアイコンと、ユーザＡ．Ａの会費予定額である「６，０００円」とが表示される。扇形部２４８３ｃには、デフォルトでは、ユーザＢ．Ｂのユーザアイコンと、ユーザＢ．Ｂの会費予定額である「２，０００円」とが表示される。扇形部２４８３ｄには、図１７に示す場合と異なるが、デフォルトでは、ユーザＣ．Ｃのユーザアイコンと、ユーザＣ．Ｃの会費予定額である「２，０００円」とが表示される。扇形部２４８３ｅには、図１７に示す場合と異なるが、デフォルトでは、ユーザＤ．Ｄのユーザアイコンと、ユーザＤ．Ｄの会費予定額である「６，０００円」とが表示される。
以下では、扇形部２４８３ｂと、扇形部２４８３ｃとの境界のことを境界線２４８３ｇとも称する。扇形部２４８３ｃと、扇形部２４８３ｄとの境界のことを境界線２４８３ｈとも称する。扇形部２４８３ｄと、扇形部２４８３ｅとの境界のことを境界線２４８３ｉとも称する。扇形部２４８３ｅと、扇形部２４８３ｂとの境界のことを境界線２４８３ｊとも称する。
限定ではなく例として、ユーザが、境界線２４８３ｇ、２４８３ｈ、２４８３ｉおよび２４８３ｊのいずれかをドラッグすることで、その境界線を挟んで位置する２つの扇形部にそれぞれ対応する２人のユーザの分担割合を変更することができる。
本実施例では、限定ではなく例として、ユーザが、ユーザＣ．Ｃに対応する扇形部２４８３ｃと、ユーザＤ．Ｄに対応する扇形部２４８３ｅとの境界線２４８３ｉをタッチすると、境界線２４８３ｉ上に円形のカーソル２４８３ｋが表示される。ユーザが、カーソル２４８３ｋをドラッグして周方向に沿って動かすことで、扇形部２４８３ｂの中心角および扇形部２４８３ｃの中心角が維持されたまま、カーソル２４８３ｋの動きに応じて、扇形部２４８３ｄの中心角および扇形部２４８３ｅの中心角を変更することができる。
具体的には、限定ではなく例として、ユーザが、カーソル２４８３ｋをドラッグして周方向に沿って反時計回りに動かすと、カーソル２４８３ｋの動きに応じて、扇形部２４８３ｄの中心角が減少するととともに、扇形部２４８３ｄの中心角の減少分が、扇形部２４８３ｅの中心角に加算されてその中心角が増加する。このとき、扇形部２４８３ｂの中心角および扇形部２４８３ｃの中心角が維持される。
一方、ユーザが、カーソル２４８３ｋをドラッグして周方向に沿って時計回りに動かすと、カーソル２４８３ｋの動きに応じて、扇形部２４８３ｄの中心角が増加するととともに、扇形部２４８３ｄの中心角の増加分が、扇形部２４８３ｅの中心角から減算されてその中心角が減少する。このとき、扇形部２４８３ｂの中心角および扇形部２４８３ｃの中心角が維持される。
図１７に示す例では、ユーザが、カーソル２４８３ｋをドラッグして周方向に沿って時計回りに動かすことで、扇形部２４８３ｄの中心角がデフォルトの４５°から９０°に増加するととともに、扇形部２４８３ｅの中心角が、デフォルトの１３５°から、扇形部２４８３ｄの中心角の増加分である４５°だけ減少して９０°となる。
ここで、反時計回りにドラッグして動かす場合、および時計回りにドラッグして動かす場合の両方において、中心角または金額が所定の刻み幅の数値（例えば、中心角であれば９０°、１８０°など、金額であれば４，０００円、５,０００円など）に設定しやすくなるよう、動かしているカーソル位置に対応する数値が所定の数値の近辺（例えば、中心角であれば±２°の範囲以内、金額であれば±３％の範囲以内）である時は、当該所定の数値に扇形部の境界線が吸い付く形で収束するよう、自動的にカーソル位置を調整することとしてもよい。
ユーザが、ドラッグを終了し、入出力部２３から手を離すと、扇形部２４８３ｄの中心角および扇形部２４８３ｅの中心角は、ドラッグが終了したタイミングにおける中心角に変更される。本実施例では、扇形部２４８３ｄの中心角および扇形部２４８３ｅの中心角は、ともに９０°に変更される。
そして、限定ではなく例として、変更後の扇形部２４８３ｂ、２４８３ｃ、２４８３ｄおよび２４８３ｅの各中心角に基づき、参加予定のユーザの分担割合が再計算される。具体的には、扇形部に対応するユーザの分担割合が、その扇形部の中心角を３６０°で除した値に変更される。本実施例では、限定ではなく例として、扇形部２４８３ｄに対応するユーザＣ．Ｃの分担割合が、扇形部２４８３ｄの中心角である９０°を３６０°で除した値である１／４すなわち２／８に変更される。同様に、限定ではなく例として、扇形部２４８３ｅに対応するユーザＤ．Ｄの分担割合が、扇形部２４８３ｅの中心角である９０°を３６０°で除した値である１／４すなわち２／８に変更される。一方、ユーザＡ．Ａの分担割合およびユーザＢ．Ｂの分担割合は、それぞれ３／８および１／８に維持される。つまり、ユーザＡ．Ａの分担割合と、ユーザＢ．Ｂの分担割合と、ユーザＣ．Ｃの分担割合と、ユーザＤ．Ｄの分担割合との比は、３：１：２：２に再設定される。
このように、円グラフにおける扇形の中心角の大きさで各ユーザの分担割合を表示することで、各ユーザの分担割合を視覚的に分かりやすく表現し、幹事であるユーザに各ユーザの分担割合を直感的に理解させることができる。また、扇形の中心角の大きさを画面上で変更し、その扇形に対応するユーザの分担割合を、その中心角の大きさに応じて変更する構成とすることで、幹事であるユーザは、各ユーザの分担割合を直感的に理解しながら簡易に変更することができる。
円グラフ２４８３ａの下側には、円グラフ２４８３ａに基づき各ユーザの分担割合を変更するための分担割合変更決定ボタンが配置される。
図１８は、図１７に示すアプリケーション画面において分担割合変更決定ボタン２４８３ｌがタッチされた場合に表示されるアプリケーション画面の一例を示す図である。このアプリケーション画面は、タイトルバー領域２４１と、グループ名表示領域２４２と、進行状況表示領域２４３と、ワーク領域２４４とを含む。
本実施例では、分担割合変更決定ボタンがタッチされると、変更後の各ユーザの分担割合が反映された、イベント企画サブプログラムの「招待状の作成」の作成段階に戻る。この場合、タイトルバー領域２４１、グループ名表示領域２４２および進行状況表示領域２４３に表示された内容は、図１６に示すタイトルバー領域２４１、グループ名表示領域２４２および進行状況表示領域２４３にそれぞれ表示された内容と同一である。
また、ワーク領域２４４における表示内容は、各ユーザの分担割合の変更内容が反映される。具体的には、本実施例では、限定ではなく例として、ユーザＡ．Ａの分担割合と、ユーザＢ．Ｂの分担割合と、ユーザＣ．Ｃの分担割合と、ユーザＤ．Ｄの分担割合との比が、３：１：２：２に再設定されたので、会費内訳表示欄に表示された分担割合表示バー群における各表示バーの横方向の長さが再設定される。具体的には、限定ではなく例として、ユーザＡ．Ａのユーザアイコンの右側に位置する表示バーの横方向の長さと、ユーザＢ．Ｂのユーザアイコンの右側に位置する表示バーの横方向の長さと、ユーザＣ．Ｃのユーザアイコンの右側に位置する表示バーの横方向の長さと、ユーザＤ．Ｄのユーザアイコンの右側に位置する表示バーの横方向の長さとの比が、３：１：２：２に再設定される。
ユーザＡ．Ａのユーザアイコンの右側に位置する会費予定額表示欄、およびユーザＢ．Ｂのユーザアイコンの右側に位置する会費予定額表示欄に表示された会費は、それぞれ「６，０００円」および「２，０００円」に維持される。一方、ユーザＣ．Ｃのユーザアイコンの右側に位置する会費予定額表示欄には、１６，０００円に、そのユーザに再設定された分担割合である２／８を乗じた額の「４，０００円」が表示される。同様にユーザＤ．Ｄのユーザアイコンの右側に位置する会費予定額表示欄には、１６，０００円に、そのユーザに再設定された分担割合である２／８を乗じた額の「４，０００円」が表示される。
この場合、ユーザＢ．Ｂ、Ｃ．ＣおよびＤ．Ｄの各々が支払うべき会費は、すべて、「総支払予定金額」である「１６，０００円」を参加人数の４で除した額である４０００円以下であるため、ユーザＢ．Ｂ、Ｃ．ＣおよびＤ．Ｄの少なくともいずれか１人が参加しない場合、幹事であるユーザＡ．Ａが支払うべき会費は、「６，０００円」以下となる。このため、「６，０００円」が、最大会費予定額表示欄に表示される。
図１９は、図１８に示すアプリケーション画面において招待状送付ボタンがタッチされた場合に、ユーザＢ．Ｂの端末２０Ｂの表示部２４に表示されるアプリケーション画面の一例を示す図である。このアプリケーション画面は、タイトルバー領域２４１と、グループ名表示領域２４２と、ワーク領域２４４とを含む。
タイトルバー領域２４１の表示内容は、ユーザＢ．Ｂのユーザアイコンが表示されている点を除き、図１４に示すタイトルバー領域２４１の表示内容と同様である。グループ名表示領域２４２の表示内容は、図１４に示すグループ名表示領域２４２の表示内容と同一である。
本実施例では、限定ではなく例として、端末２０Ｂのワーク領域２４４には、トークルーム画面２４６２と、サブプログラム選択画面２４７２とが表示される。サブプログラム選択画面２４７２は、最小化されているが、左側に位置する＋印のアイコンをタッチすることで、元のサイズ（限定ではなく例として、図１４に示すサブプログラム選択画面２４７１のサイズ）に拡大することができる。
トークルーム画面２４６２には、限定ではなく例として、端末２０ＢのユーザＢ．Ｂが発するメッセージは、画面右側から発せられるように表示された吹き出しに含まれる。一方、端末２０Ｂのユーザでないユーザ（限定ではなく例として、ユーザＡ．Ａ、ユーザＣ．ＣおよびユーザＤ．Ｄ）が発するメッセージは、画面左側に位置し、そのメッセージを発したユーザのユーザアイコンから発せられるように表示された吹き出しに含まれる。
本実施例では、ユーザＡ．Ａが、限定ではなく例として、上記のように時刻「１１：１７」に「おすすめのレストランがあるので私が幹事をしますね」のメッセージを発したのに対して、ユーザＢ．Ｂが時刻「１１：２０」に「お願いします！楽しみですね」のメッセージで返答する。その後、幹事であるユーザＡ．Ａからメッセージを受信し、そのメッセージの内容が吹き出し２４６２ａに表示される。
具体的には、吹き出し２４６２ａには、イベント概要と、ユーザＢ．Ｂに対して設定された会費とが表示される告知情報表示欄２４６２ｄが配置される。
なお、告知情報表示欄２４６２ｄには、ユーザＢ．Ｂに対して設定された会費に加えて、他のユーザ（限定ではなく例として、ユーザＡ．Ａ、Ｃ．ＣおよびＤ．Ｄ）にそれぞれ設定された会費を表示する構成にしてもよいし、そのようにしなくてもよい。
告知情報表示欄２４６２ｄの下側には、参加する意向を示すメッセージを幹事であるユーザＡ．Ａの端末２０Ａに表示させるための参加ボタンと、参加を保留する意向を示すメッセージを端末２０Ａに表示させるための保留ボタンと、参加をしない意向を示すメッセージを端末２０Ａに表示させるための不参加ボタンとがこの順に上側から並んで配置される。
図２０は、図１９に示すアプリケーション画面において参加ボタンがタッチされた場合に表示されるアプリケーション画面の一例を示す図である。このアプリケーション画面は、タイトルバー領域２４１と、グループ名表示領域２４２と、ワーク領域２４４とを含む。
本実施例では、限定ではなく例として、ワーク領域２４４には、トークルーム画面２４６３と、サブプログラム選択画面２４７３とが表示される。トークルーム画面２４６３には、参加ボタン２４６２ｇがタッチされたことによって、吹き出し２４６２ａに重複するように、寄付依頼ボックス２４６３ａが配置される。寄付依頼ボックス２４６３ａの最上部には、寄付依頼情報表示欄が配置される。寄付依頼情報表示欄には、イベントのタイトル名と、寄付の依頼として「寄付金のご協力をお願いします」の文字列とが表示される。
寄付依頼情報表示欄の下側には、現金金額での寄付金額を入力するための寄付金額入力欄が配置される。なお、現金金額とは、電子マネーのうち、電子ポイントによる貨幣価値を含まない金額を指す。例えば、電子ポイントの単位が「ｐｔ」である場合、現金金額とは、「ｐｔ」を除外した単位（例えば「円」）で表現される金額のことである。
本実施例では、ユーザがインクリメントボタンおよびデクリメントボタンを操作することで、これらのボタンの右側に位置する寄付金額表示ボックスに表示される寄付金額が増減する。寄付金額は、下側のＯＫボタンを押したときに寄付金額表示ボックスに表示された金額に設定される。寄付金額表示ボックスには、デフォルトで初期設定額（限定ではなく例として、ゼロ円）が表示される。
寄付金額入力欄の下側には、電子マネーに充当可能な電子ポイントでの寄付ポイント額を入力するための寄付ポイント額入力欄が配置される。本実施例では、ユーザがインクリメントボタンおよびデクリメントボタンを操作することで、これらのボタンの右側に位置する寄付ポイント額表示ボックスに表示される寄付ポイント額が増減する。寄付ポイント額は、下側のＯＫボタンを押したときに寄付ポイント額表示ボックスに表示されたポイント額に設定される。寄付ポイント額表示ボックスには、デフォルトで初期設定額（限定ではなく例として、ゼロｐｔ）が表示される。
なお、本実施例では、１電子ポイント（１ｐｔ）が現金金額０．５円分に換算される。また、ユーザは、寄付金額および寄付ポイント額の両方をゼロに設定してもよいし、そのようにしなくてもよい。
寄付金額入力欄の下側には、寄付金額および寄付ポイント額を決定し、その寄付金額および寄付ポイント額ならびに会費の合計を電子マネーで送金するためのＯＫボタン（決定ボタン）が配置される。
このように、会費に加えて、寄付金額または寄付ポイント額を電子マネーで送金する構成により、他のユーザの会費を減ずることができるので、参加を保留している他のユーザ（限定ではなく例として、ユーザＤ．Ｄ）の参加を促すことができる。
図２１は、図１８に示すアプリケーション画面において招待状送付ボタンがタッチされた場合に、ユーザＣ．Ｃの端末２０Ｃの表示部２４に表示されるアプリケーション画面の一例を示す図である。このアプリケーション画面は、タイトルバー領域２４１と、グループ名表示領域２４２と、ワーク領域２４４とを含む。
タイトルバー領域２４１の表示内容は、ユーザＣ．Ｃのユーザアイコンが表示されている点を除き、図１４に示すタイトルバー領域２４１の表示内容と同様である。グループ名表示領域２４２の表示内容は、図１４に示すグループ名表示領域２４２の表示内容と同一である。
本実施例では、限定ではなく例として、端末２０Ｃのワーク領域２４４には、トークルーム画面２４６４と、サブプログラム選択画面２４７４とが表示される。
トークルーム画面２４６４には、限定ではなく例として、「会費」が「￥４，０００」となっている点を除き、図１９に示す吹き出し２４６２ａの内容と同一の内容を有する吹き出し２４６４ａと、吹き出し２４６４ａの参加ボタンがタッチされたことによって、吹き出し２４６４ａに重複するように配置された寄付依頼ボックス２４６４ｂとが表示される。
寄付依頼ボックス２４６４ｂには、図２０に示す寄付依頼ボックス２４６３ａと同様に、寄付依頼情報表示欄、寄付金額入力欄、寄付ポイント額入力欄およびＯＫボタンが配置される。
本実施例では、ユーザＣ．Ｃの操作によって、寄付金額入力欄にはゼロ円が表示され、寄付ポイント額入力欄には２０００ポイントが表示される。なお、ユーザは、寄付金額および寄付ポイント額の両方をゼロに設定してもよいし、そのようにしなくてもよい。
図２２は、図１８に示すアプリケーション画面において招待状送付ボタンがタッチされた場合に、ユーザＤ．Ｄの端末２０Ｃの表示部２４に表示されるアプリケーション画面の一例を示す図である。このアプリケーション画面は、タイトルバー領域２４１と、グループ名表示領域２４２と、ワーク領域２４４とを含む。
タイトルバー領域２４１の表示内容は、ユーザＤ．Ｄのユーザアイコンが表示されている点を除き、図１４に示すタイトルバー領域２４１の表示内容と同様である。グループ名表示領域２４２の表示内容は、図１４に示すグループ名表示領域２４２の表示内容と同一である。
本実施例では、限定ではなく例として、端末２０Ｄのワーク領域２４４には、トークルーム画面２４６５と、サブプログラム選択画面２４７５とが表示される。
トークルーム画面２４６５には、限定ではなく例として、「会費」が「￥４，０００」となっている点を除き、図１９に示す吹き出し２４６２ａの内容と同一の内容を有する吹き出し２４６５ａと、「参加を保留する」のメッセージを含む吹き出し２４６５ｂと、ユーザＤ．Ｄによって入力された「バイト代が入ったら参加します」のメッセージを含む吹き出し２４６５ｃとが表示される。
本実施例では、限定ではなく例として、吹き出し２４６５ａの保留ボタンがユーザＣ．Ｃによってタッチされたことによって、吹き出し２４６５ｂに含まれる「参加を保留する」のメッセージが自動的に発せられる。
図２３は、ユーザＡ．Ａの端末２０Ａにおける表示部２４に表示される、メッセージングアプリケーションのアプリケーション画面の一例を示す図である。本実施例では、限定ではなく例として、ユーザＢ．Ｂは、会費２０００円に加えて、５００円の寄付金額を支払うことに合意して、図２０に示すアプリケーション画面におけるＯＫボタンをタッチする。ユーザＣ．Ｃは、会費４０００円に加えて、２０００ポイントの寄付ポイント額を支払うことに合意して、図２１に示すアプリケーション画面におけるＯＫボタンをタッチする。ユーザＤ．Ｄは、上述したように、図２２に示すアプリケーション画面における保留ボタンをタッチする。
図２３に示すアプリケーション画面は、ユーザＢ．Ｂ、Ｃ．ＣおよびＤ．Ｄによってこれらの操作が行われた後に、端末２０Ａにおける表示部２４に表示されるアプリケーション画面である。このアプリケーション画面は、タイトルバー領域２４１と、グループ名表示領域２４２と、進行状況表示領域２４３と、ワーク領域２４４とを含む。
タイトルバー領域２４１およびグループ名表示領域２４２の表示内容は、図１４に示すタイトルバー領域２４１およびグループ名表示領域２４２の表示内容とそれぞれ同一である。
本実施例では、進行状況表示領域２４３には、イベント企画サブプログラムの現在実行中の段階として、「秋のお食事会」のイベントを管理する段階を示す「秋のお食事会」が表示される。
ワーク領域２４４には、イベント管理画面２４８５が表示される。イベント管理画面２４８５の最上部には、イベント概要表示欄が配置される。
イベント概要表示欄の下側には、このイベントの会費の総額を表示するための会費表示欄が配置される。
会費表示欄の下側には、このイベントに参加するユーザが支払う金額であって、確定した金額を表示するための受取確定額表示欄が配置される。本実施例では、ユーザＢ．Ｂが２５００円（５００円の寄付金額を含む。）を支払うことに合意し、かつユーザＣ．Ｃが、５０００円（１０００円に相当する２０００ポイント分の電子ポイントを含む。）を支払うことに合意しているため、受取確定額表示欄には、２５００円と５０００円とを合計した「７，５００円／２，０００ｐｔ含む」が「受取確定額」として表示される。
受取確定額表示欄の下側には、会費内訳管理表示欄が配置される。会費内訳管理表示欄には、限定ではなく例として、このイベントでの管理対象のユーザのユーザアイコンを縦に並べて表示した管理対象ユーザアイコン群が左側に表示される。本実施例では、管理対象ユーザアイコン群には、限定ではなく例として、ユーザＡ．Ａ、Ｂ．Ｂ、Ｃ．ＣおよびＤ．Ｄのユーザアイコンが、この順番でユーザ名とともに縦に並べられる。なお、幹事であるユーザＡ．Ａのユーザアイコンには、幹事マークが左下に付される。また、イベントへの参加が確定しているユーザＡ．Ａ、Ｂ．ＢおよびＣ．Ｃのユーザアイコンの右上には、参加確定マークが付される。一方、イベントへの出席を保留しているユーザＤ．Ｄのユーザアイコンの右上には、参加保留マークが付される。なお、イベントへの不参加が確定しているユーザのユーザアイコンの右上には、不参加確定マークを付してもよいし、そのようにしなくてもよい。
管理対象ユーザアイコン群の右側には、分担割合表示バー群が配置される。分担割合表示バー群の表示内容は、ユーザＡ．Ａの分担割合と、ユーザＢ．Ｂの分担割合と、ユーザＣ．Ｃの分担割合と、ユーザＤ．Ｄの分担割合との比が３：１：２：２に再設定された、図１８に示す分担割合表示バー群の表示内容と同一である。
分担割合表示バー群の右側には、会費予定額表示欄がユーザアイコンに対応して配置される。幹事であるユーザＡ．Ａのユーザアイコンの右側に位置する会費予定額表示欄の右側には、最大会費予定額表示欄が配置される。
現金金額を寄付したユーザＢ．Ｂのユーザアイコンの右側に位置する会費予定額表示欄の右側には、現金金額寄付額表示欄が配置される。
電子ポイントを寄付したユーザＣ．Ｃのユーザアイコンの右側に位置する会費予定額表示欄の右側には、電子ポイント寄付額表示欄が配置される。
本実施例では、限定ではなく例として、ユーザＢ．Ｂの支払額が、会費２０００円と、寄付金額の５００円とが確定しているので、ユーザＢ．Ｂのユーザアイコンの右側に位置し、金額の確定を意味する太線で囲われた会費予定額表示欄に「２，０００円」が表示される。そして、その会費予定額表示欄の右側に位置する寄付額表示欄には、「寄付金額」の「５００円」が表示される。
同様に、ユーザＣ．Ｃの支払額が、会費４０００円と、寄付ポイント額の２０００ポイントとが確定しているので、ユーザＣ．Ｃのユーザアイコンの右側に位置し、金額の確定を意味する太線で囲われた会費予定額表示欄に「４，０００円」が表示される。そして、その会費予定額表示欄の右側に位置する寄付額表示欄には、「寄付ポイント額」の「２，０００ｐｔ」が表示される。
一方、ユーザＡ．Ａの支払額と、ユーザＤ．Ｄの支払額とが確定していないため、寄付金額の５００円と、１０００円に相当する寄付ポイント額の２０００ポイントとに基づき、これらの支払額が再計算される。具体的には、限定ではなく例として、寄付に相当する金額である１５００円（寄付金額５００円に、１０００円に相当する２０００ポイントを加えたもの）が、ユーザＡ．Ａの分担割合と、ユーザＤ．Ｄの分担割合との比である３：２で分配される。つまり、寄付に相当する金額である１５００円が、ユーザＡ．Ａへの減額対象分である９００円と、ユーザＤ．Ｄへの減額対象分である６００円とに分配される。
限定ではなく例として、このイベントの「総支払予定金額」である「１６，０００円」に、ユーザＡ．Ａに設定された分担割合である３／８を乗じた額の６０００円から減額対象分である９００円を差し引いた「５，１００円」が、ユーザＡ．Ａのユーザアイコンの右側に位置する会費予定額表示欄に表示される。
同様に、限定ではなく例として、このイベントの「総支払予定金額」である「１６，０００円」に、ユーザＤ．Ｄに設定された分担割合である２／８を乗じた額の４０００円から減額対象分である６００円を差し引いた「３，４００円」が、ユーザＤ．Ｄのユーザアイコンの右側に位置する会費予定額表示欄に表示される。
この場合、ユーザＢ．ＢおよびＣ．Ｃは、イベントへ出席するか否かに関わらず、確定した会費および寄付金額・寄付ポイント額を前払いで支払うため、ユーザＤ．Ｄが参加しない場合、幹事であるユーザＡ．Ａが支払うべき会費は、「５，１００円」以下となる。このため、「５，１００円」が、最大会費予定額表示欄に表示される。
会費内訳管理表示欄の下側には、このイベントでの管理対象のユーザの分担割合を変更するための分担割合変更ボタンが配置される。この場合、限定ではなく例として、ユーザＢ．ＢおよびＣ．Ｃの支払額が確定しているので、分担割合変更ボタンをタッチすることで、ユーザＢ．ＢおよびＣ．Ｃの支払額を固定した状態で、管理対象のユーザの分担割合を変更することができる。
図２４は、図１３に示すアプリケーション画面において支払額の再計算が行われた後に、ユーザＤ．Ｄの端末２０Ｃの表示部２４に表示されるアプリケーション画面の一例を示す図である。このアプリケーション画面は、タイトルバー領域２４１と、グループ名表示領域２４２と、ワーク領域２４４とを含む。
タイトルバー領域２４１およびグループ名表示領域２４２の表示内容は、図２２に示タイトルバー領域２４１およびグループ名表示領域２４２の表示内容とそれぞれ同一である。
本実施例では、限定ではなく例として、端末２０Ｄのワーク領域２４４には、トークルーム画面２４６６と、サブプログラム選択画面２４７６とが表示される。
トークルーム画面２４６６には、限定ではなく例として、告知情報表示欄２４６２ｄの表示内容が異なっている点を除き、図２２に示す吹き出し２４６５ａの内容と同一の内容を有する吹き出し２４６６ａが表示される。吹き出し２４６６ａにおける告知情報表示欄２４６２ｄには、ユーザＤ．Ｄにこのイベントを思い出させるための「リマインド」の文字列が表示される。そして、告知情報表示欄２４６２ｄには、４０００円から６００円減額された「会費」として「￥３，４００」が表示されるとともに、減額分を割合で示した「１５％ＯＦＦ」を表示する。このように、会費が低下したことを表示してユーザＤ．Ｄにリマインドとして通知することで、ユーザＤ．Ｄの参加を効果的に促すことができる。
告知情報表示欄２４６２ｄの下側には、参加ボタンと、保留ボタンと、不参加ボタンとがこの順に上側から並んで配置される。本実施例では、限定ではなく例として、ユーザＤ．Ｄは、図２２に示すアプリケーション画面における保留ボタンをタッチして、イベントへの参加を一度保留したため、ユーザＤ．Ｄが、参加ボタンを仮にタッチしても、寄付依頼ボックス（限定ではなく例として、図２０に示す寄付依頼ボックスまたは図２１に示す寄付依頼ボックスに相当するもの）が端末２０Ｄの表示部２４に表示されない。なお、ユーザＤ．Ｄが、イベントへの参加を一度保留しても、後に参加ボタンをタッチすると、寄付依頼ボックスが端末２０の表示部２４に表示される構成にしてもよいし、そのようにしなくてもよい。
なお、ユーザによって不参加ボタンが選択された場合であっても、保留ボタンが選択された場合と同様に、そのユーザの端末２０にリマインドが通知されるようにしてもよいし、そのようにしなくてもよい。
また、保留ボタンおよび不参加ボタンに関しては、保留ボタンを設けずに不参加ボタンのみを設けもよく、不参加ボタンを設けずに保留ボタンのみを設けてもよい。
図２５は、ユーザＡ．Ａの端末２０Ａにおける表示部２４に表示される、メッセージングアプリケーションのアプリケーション画面の一例を示す図である。本実施例では、限定ではなく例として、ユーザＤ．Ｄは、会費３４００円を支払うことに合意して、図２４に示すアプリケーション画面における参加ボタンをタッチする。幹事であるユーザＡ．Ａは、支払金額である１６０００円の電子マネーを「レストラン ナーダ」の電子マネー口座へ送金するための操作を端末２０Ａに対して行う。なお、幹事であるユーザＡ．Ａの電子マネーの送金操作は、ユーザＤ．Ｄの参加を確認する前に行ってもよいし、ユーザＤ．Ｄの参加を確認した後に行ってもよい。
図２５に示すアプリケーション画面は、ユーザＡ．ＡおよびＤ．Ｄによってこれらの操作が行われた後に、端末２０Ａにおける表示部２４に表示されるアプリケーション画面である。このアプリケーション画面は、タイトルバー領域２４１と、グループ名表示領域２４２と、進行状況表示領域２４３と、ワーク領域２４４とを含む。
タイトルバー領域２４１およびグループ名表示領域２４２の表示内容は、図１４に示すタイトルバー領域２４１およびグループ名表示領域２４２の表示内容とそれぞれ同一である。進行状況表示領域２４３の表示内容は、図２３に示す進行状況表示領域２４３の表示内容と同一である。
ワーク領域２４４には、イベント管理画面２４８６が表示される。イベント管理画面２４８６の最上部には、イベント概要表示欄が配置される。
イベント概要表示欄の下側には、会費表示欄が配置される。本実施例では、会費表示欄には、限定ではなく例として、電子マネーの送信が完了した後なので、確定した「支払金額」である「１６，０００円」と、支払が確定したことを示すチェックマークとが表示される。
会費表示欄の下側には、還元額表示欄２４８６ａが配置される。本実施例では、１６０００円の支払いに対し、支払額の２．５％に相当する４００円分の還元金額（キャッシュバック金額）と、支払額の５％に相当する８００ポイント分の還元ポイント（発生ポイント）とが発生することとする。還元額表示欄２４８６ａには、限定ではなく例として、そのキャッシュバック金額と、その発生ポイントとが表示される。
還元額表示欄２４８６ａの下側には、還元額管理表示欄２４８６ｊが配置される。還元額管理表示欄２４８６ｊには、限定ではなく例として、管理対象ユーザアイコン群が左側に表示される。本実施例では、管理対象ユーザアイコン群には、限定ではなく例として、ユーザＡ．Ａ、Ｂ．Ｂ、Ｃ．ＣおよびＤ．Ｄのユーザアイコンが、この順番でユーザ名とともに縦に並べられる。幹事であるユーザＡ．Ａのユーザアイコンには、幹事マークが左下に付される。なお、ユーザＡ．Ａ、Ｂ．Ｂ、Ｃ．ＣおよびＤ．Ｄのすべての参加が確定しているので、ユーザアイコンには、参加確定マーク、参加保留マークおよび不参加確定マークのいずれも付されない。
管理対象ユーザアイコン群の右側には、分担割合表示バー群が配置される。分担割合表示バー群の表示内容は、ユーザＡ．Ａの分担割合と、ユーザＢ．Ｂの分担割合と、ユーザＣ．Ｃの分担割合と、ユーザＤ．Ｄの分担割合との比が３：１：２：２に再設定された、図１８に示す分担割合表示バー群の表示内容と同一である。
分担割合表示バー群の右側には、還元金額表示欄２４８６ｂ、２４８６ｃ、２４８６ｄおよび２４８６ｅが配置される。還元金額表示欄２４８６ｂ、２４８６ｃ、２４８６ｄおよび２４８６ｅの右側には、還元ポイント表示欄２４８６ｆ、２４８６ｇ、２４８６ｈおよび２４８６ｉがそれぞれ配置される。
還元金額および還元ポイントは、限定ではなく例として、各ユーザの分担割合に応じて分配される。具体的には、限定ではなく例として、還元金額表示欄２４８６ｂには、４００円に、ユーザＡ．Ａに再設定された分担割合である３／８を乗じた額の「１５０円」が表示される。同様に、還元金額表示欄２４８６ｃと、還元金額表示欄２４８６ｄと、還元金額表示欄２４８６ｅとには、４００円に、ユーザＢ．Ｂに再設定された分担割合である１／８を乗じた額の「５０円」と、４００円に、ユーザＣ．Ｃに再設定された分担割合である２／８を乗じた額の「１００円」と、４００円に、ユーザＤ．Ｄに再設定された分担割合である２／８を乗じた額の「１００円」とがそれぞれ表示される。
還元ポイント表示欄２４８６ｆには、８００ポイントに、ユーザＡ．Ａに再設定された分担割合である３／８を乗じたポイント額の「３００ｐｔ」が表示される。同様に、還元還元ポイント表示欄２４８６ｇと、還元ポイント表示欄２４８６ｈと、還元ポイント表示欄２４８６ｉとには、８００ポイントに、ユーザＢ．Ｂに再設定された分担割合である１／８を乗じたポイント額の「１００ｐｔ」と、８００ポイントに、ユーザＣ．Ｃに再設定された分担割合である２／８を乗じたポイント額の「２００ｐｔ」と、８００ポイントに、ユーザＤ．Ｄに再設定された分担割合である２／８を乗じたポイント額の「２００ｐｔ」とがそれぞれ表示される。
還元額管理表示欄２４８６ｊの下側には、このイベントでの管理対象のユーザの分担割合を変更するための分担割合変更ボタンが配置される。この場合、限定ではなく例として、分担割合変更ボタンをタッチすることで、還元金額および還元ポイントの分配に用いる管理対象のユーザの分担割合を変更することができる。なお、還元金額の分配に用いる管理対象のユーザの分担割合と、還元ポイントの分配に用いる管理対象のユーザの分担割合とを別個に変更することができる構成としてもよいし、そのようにしなくてもよい。
分担割合変更ボタンの下側には、決定した還元金額分の電子マネーと、還元ポイント分の電子ポイントを、このイベントでの管理対象のユーザの電子マネー口座と電子ポイント口座とへそれぞれ送信するための配分ボタンが配置される。
図２６は、図２５に示すアプリケーション画面において配分ボタンがタッチされた場合に、ユーザＢ．Ｂの端末２０Ｂの表示部２４に表示されるアプリケーション画面の一例を示す図である。このアプリケーション画面は、タイトルバー領域２４１と、グループ名表示領域２４２と、ワーク領域２４４とを含む。
タイトルバー領域２４１およびグループ名表示領域２４２の表示内容は、図１９に示すタイトルバー領域２４１およびグループ名表示領域２４２の表示内容とそれぞれ同一である。
本実施例では、限定ではなく例として、端末２０Ｂのワーク領域２４４には、トークルーム画面２４６７と、サブプログラム選択画面２４７７とが表示される。
トークルーム画面２４６７には、幹事であるユーザＡ．Ａからのメッセージの内容を含む吹き出し２４６７ａが表示される。吹き出し２４６７ａには、イベント概要と、「キャッシュバック・ポイントが配分されました。」の告知の文字列と、確定した支払金額である「２，０００円」の文字列とが表示される告知情報表示欄２４６２ｄが配置される。なお、「２，０００円」の文字列の右側には、支払が確定したことを示すチェックマークが表示される。
告知情報表示欄２４６２ｄの下側には、還元金額および還元ポイントの内訳を含む還元情報表示欄２４６７ｂが配置される。還元情報表示欄２４６７ｂには、ユーザＢ．Ｂに対する「キャッシュバック金額」である「￥５０」と、「ポイント還元」である「１００ｐｔ」とが表示される。
＜処理＞
図２７および図２８は、本実施例における各装置が実行する処理の流れの一例を示すフローチャートである。
これらの図では、左側から順に、ユーザＡ．Ａの端末２０Ａの制御部２１が実行するパーティー処理、ユーザＢ．Ｂの端末２０Ｂの制御部２１が実行するパーティー処理、ユーザＤ．Ｄの端末２０Ｄの制御部２１が実行するパーティー処理、サーバ１０の制御部１１が実行するパーティー管理処理の一例をそれぞれ示している。
なお、図２７および図２８では、ユーザＣ．Ｃの端末２０Ｃの制御部２１が実行するパーティー処理が省略されているが、そのパーティー処理は、ユーザＢ．ＢまたはユーザＤ．Ｄの端末２０の制御部２１が実行するパーティー処理と同様である。
フローチャートの各ステップは、それぞれの装置のＣＰＵが記憶部からプログラムを読み出して実行することにより実現される。
なお、以下説明するフローチャートは、本開示の手法を実現するための処理の手順を例示したものに過ぎない。このため、本開示の手法を実現するための処理は、以下説明するフローチャートに従って実行される処理に限定されず、一部のステップを省略したり、他のステップを追加したりすることも可能である。
最初に、端末２０Ａの制御部２１は、新規パーティー作成処理を行う（Ａ１１０）。具体的には、制御部２１は、限定ではなく例として、図１４に示すアプリケーション画面を端末２０Ａの表示部２４に表示させ、幹事であるユーザＡ．Ａがパーティーのアイコンをタッチする操作を行うと、図１５に示すアプリケーション画面を端末２０Ａの表示部２４に表示させる。
制御部２１は、ユーザＡ．Ａが、新規パーティーに関する事項（限定ではなく例として、イベント（限定でなく例として、パーティー）のタイトル名、コメント、開催日時、１人あたりの予算額、ユーザアイコン、店舗の検索条件など）を入出力部２３に入力する操作に基づき、ユーザＡ．Ａによって入力された内容を表示部２４に表示させる。
ユーザＡ．Ａが、店舗検索ボタンをタッチすると、制御部２１は、表示部２４に表示された内容に基づき、新規パーティーに関する事項を含む新規パーティー情報を、通信Ｉ／Ｆ２２によってサーバ１０へ送信する。
サーバ１０の制御部１１は、端末２０Ａから受信した新規パーティー情報に基づき、店舗の検索ならびに総支払予定金額およびユーザごとの会費予定額（最大会費予定額を含む。）の算出を行い、検索結果および算出結果を含む結果情報を端末２０Ａへ送信する。
端末２０Ａの制御部２１は、通信Ｉ／Ｆ２２によってサーバ１０から結果情報を受信すると、結果情報に基づき、図１６に示すアプリケーション画面を表示部２４に表示させる。ユーザＡ．Ａが、図１６に示すアプリケーション画面における分担割合変更ボタンをタッチする操作を行うと、制御部２１は、パーティー代金分担割合設定処理を行う（Ａ１２０）。
具体的には、制御部２１は、図１７に示すアプリケーション画面を表示部２４に表示させ、ユーザＡ．Ａの入出力部２３に対する入力操作（限定ではなく例として、表示部２４に表示された円グラフに対するドラッグ操作）に基づき、そのドラッグ操作が反映された円グラフを表示部２４に表示させる。
ユーザＡ．Ａが、分担割合変更決定ボタンをタッチすると、制御部２１は、表示部２４に表示された円グラフに基づき、各ユーザの分担割合を再設定し、再設定後の各ユーザの分担割合を含む分担割合情報を通信Ｉ／Ｆ２２によってサーバ１０へ送信する。
サーバ１０は、分担割合情報に基づき、各ユーザの分担割合を変更し、変更後の各ユーザの分担割合に基づき、ユーザごとの会費予定額（最大会費予定額を含む）を算出する。サーバ１０は、算出結果を含む再算出結果情報を端末２０Ａへ送信する。
端末２０Ａの制御部２１は、通信Ｉ／Ｆ２２によってサーバ１０から再算出結果情報を受信すると、再算出結果情報に基づき、図１８に示すアプリケーション画面を表示部２４に表示させる。
ユーザＡ．Ａが、図１８に示すアプリケーション画面の招待状送付ボタンをタッチする操作を行うと、端末２０Ａの制御部２１は、招待状の送付を依頼する招待状送付依頼情報を通信Ｉ／Ｆ２２によってサーバ１０へ送信する。
サーバ１０の制御部１１は、通信Ｉ／Ｆ１４によって端末２０Ａから招待状送付依頼情報を受信すると、招待状送付依頼情報に基づき、幹事以外のユーザの端末２０（限定ではなく例として、端末２０Ｂおよび２０Ｄ）へ送信すべきパーティー招待情報を作成する。このパーティー招待情報には、イベントの概要および送信対象のユーザの会費予定額が含まれる。制御部１１は、端末２０Ｂおよび２０Ｄへ送信すべきパーティー招待情報を、通信Ｉ／Ｆ１４によって端末２０Ｂおよび２０Ｄへそれぞれ送信する（Ｄ１１０）。
端末２０Ｂの制御部２１は、通信Ｉ／Ｆ２２によってサーバ１０からパーティー招待情報を受信すると、パーティー招待情報に基づき、図１９に示すアプリケーション画面を表示部２４に表示させる（Ｂ１１０）。
次いで、ユーザＢ．Ｂが、図１９に示すアプリケーション画面を見て、限定ではなく例として、参加ボタンをタッチすると、端末２０Ｂの制御部２１は、図２０に示すアプリケーション画面を表示部２４に表示させる。
ユーザＢ．Ｂが、図２０にアプリケーション画面を見て、寄付金額または寄付ポイント額を入力する操作を入出力部２３に対して行うと、制御部２１は、操作結果に基づき、その寄付金額または寄付ポイント額を図２０に示すアプリケーション画面を表示部２４に表示させる。
ユーザＢ．Ｂが、ＯＫボタンをタッチすると、端末２０Ｂの制御部２１は、パーティーへの出席、ならびに寄付金額および寄付ポイント額を示すパーティー出席情報を、通信Ｉ／Ｆ２２によってサーバ１０へ送信する（Ｂ１２０）。
次いで、端末２０Ｄの制御部２１は、通信Ｉ／Ｆ２２によってサーバ１０からパーティー招待情報を受信すると、パーティー招待情報に基づき、図２２に示すアプリケーション画面を表示部２４に表示させる（Ｃ１１０）。
次いで、ユーザＤ．Ｄが、図２２に示すアプリケーション画面を見て、限定ではなく例として、保留ボタンをタッチすると、端末２０Ｄの制御部２１は、パーティーへの保留を示すパーティー出席保留情報を、通信Ｉ／Ｆ２２によってサーバ１０へ送信する（Ｃ１２０）。
サーバ１０の制御部１１は、通信Ｉ／Ｆ１４によって端末２０Ｂおよび２０Ｄからパーティー出席情報およびパーティー出席保留情報をそれぞれ受信すると、パーティー出席情報およびパーティー出席保留情報に基づき出欠管理処理を行う（Ｄ１２０）。
具体的には、制御部１１は、限定ではなく例として、各ユーザの出席、欠席または保留、ならびに寄付金額および寄付ポイント額を確認し、パーティーへの参加を確定したユーザ（限定ではなく例として、ユーザＢ．Ｂ）の支払額を確定する。一方、制御部１１は、寄付金額および寄付ポイント額を、各ユーザの分担割合で、パーティーへの参加が確定していないユーザ（限定ではなく例として、Ｄ．Ｄ）と幹事であるユーザＡ．Ａとに分配し、これらのユーザの支払額を減額する。制御部１１は、イベントの概要、参加予定のユーザの識別子、およびユーザごとの変更後の会費予定額を含むパーティー出欠情報を、通信Ｉ／Ｆ１４によって端末２０Ａへ送信する（Ｄ１２０）。
端末２０Ａの制御部２１は、通信Ｉ／Ｆ２２によってサーバ１０からパーティー出欠情報を受信すると、パーティー出欠情報に基づき、図２３に示すアプリケーション画面を表示部２４に表示させる（Ａ１３０）。
次いで、ユーザＡ．Ａが、図２３に示すアプリケーション画面における分担割合変更ボタンをタッチする操作を行うと、制御部２１は、パーティー代金分担割合変更処理を行う（Ａ１４０）。
具体的には、制御部２１は、図１７に示すアプリケーション画面と同様のアプリケーション画面を表示部２４に表示させ、ユーザＡ．Ａの入出力部２３に対する入力操作（限定ではなく例として、表示部２４に表示された円グラフに対するドラッグ操作）に基づき、支払額が確定しているユーザＢ．Ｂの分担割合を固定したまま、ユーザＡ．ＡおよびＤ．Ｄの分担割合の変更が反映された円グラフを表示部２４に表示させる。
なお、サーバ１０では、寄付金額および寄付ポイント額が、各ユーザの分担割合で、パーティーへの参加が確定していないユーザＤ．Ｄと幹事であるユーザＡ．Ａとに割り当てられたが、ユーザＡ．ＡおよびＤ．Ｄの分担割合の変更が変更されることで、寄付金額および寄付ポイント額に加えて、現金金額も新たな分担割合でユーザＡ．ＡおよびＤ．Ｄに割り当てられる。
つまり、幹事であるユーザＡ．Ａは、自身の支払額における現金金額の負担を引き上げることで、ユーザＤ．Ｄの支払額における現金金額の負担を軽減することができるので、ユーザＤ．Ｄのパーティーへの参加を効果的に促すことができる。
ユーザＡ．Ａが、分担割合変更決定ボタンをタッチすると、制御部２１は、表示部２４に表示された円グラフに基づき、各ユーザの分担割合を再設定し、再設定後の各ユーザの分担割合を含む分担割合変更情報を通信Ｉ／Ｆ２２によってサーバ１０へ送信する。
なお、ユーザＡ．Ａは、限定ではなく例として、サーバ１０によって設定された支払額に不満がない場合、図２３に示すアプリケーション画面における分担割合変更ボタンをタッチする操作を行わなくてもよい。この場合、分担割合変更情報は、端末２０Ａからサーバ１０へ送信されない。もしくは、端末２０Ａの制御部２１は、サーバ１０から受信したパーティー出欠情報に基づいた分担割合を、変更せずにそのまま分担割合変更情報としてサーバ１０へ送信してもよい。
サーバ１０の制御部１１は、限定ではなく例として、パーティーの開催日の所定時間前（限定ではなく例として、その開催日の３日前）に、パーティーへの出席を保留しているユーザが存在するか否かを判定する（Ｄ１３０）。
パーティーへの出席を保留しているユーザが存在していない場合には（Ｄ１３０：Ｎｏ）、Ｄ１７０に処理を進める。
パーティーへの出席を保留しているユーザが存在している場合には（Ｄ１３０：Ｙｅｓ）、端末２０Ａから分担割合変更情報を受信しているか否かを確認し、分担割合変更情報を受信している場合、分担割合変更情報に基づきパーティー代金再計算処理を行う（Ｄ１４０）。
具体的には、サーバ１０は、限定ではなく例として、パーティーへの参加を確定したユーザ（限定ではなく例として、ユーザＢ．Ｂ）の支払額を維持したまま、総支払額から、確定した支払額、寄付金額および寄付ポイント額を差し引いた残りの額を、分担割合変更情報に含まれる再設定後の、パーティーへの参加が確定していないユーザ（限定ではなく例として、Ｄ．Ｄ）、および幹事であるユーザＡ．Ａの分担割合で分配し、ユーザＡ．ＡおよびＤ．Ｄの支払額を再計算する。
次いで、サーバ１０の制御部１１は、限定ではなく例として、イベントの概要およびパーティーへの参加が確定していないユーザ（限定ではなく例として、Ｄ．Ｄ）の会費予定額を含むパーティー招待確認情報を、通信Ｉ／Ｆ１４により端末２０Ｄへ送信する（Ｄ１５０）。
なお、制御部１１は、限定ではなく例として、パーティーの開催日の所定時間前（限定ではなく例として、その開催日の３日前）までに端末２０Ａから分担割合変更情報を受信していない場合、パーティー代金再計算処理（Ｄ１４０）を行わず、イベントの概要と、出欠管理処理（Ｄ１２０）において算出された、パーティーへの参加が確定していないユーザ（限定ではなく例として、Ｄ．Ｄ）の会費予定額とを含むパーティー招待確認情報を、通信Ｉ／Ｆ１４により端末２０Ｄへ送信する。
端末２０Ｄの制御部２１は、通信Ｉ／Ｆ２２によってサーバ１０からパーティー招待確認情報を受信すると、パーティー招待確認情報に基づき、図２４に示すアプリケーション画面を表示部２４に表示させる（Ｃ１３０）。
次いで、ユーザＤ．Ｄが、図２４に示すアプリケーション画面を見て、限定ではなく例として、参加ボタンをタッチすると、端末２０Ｄの制御部２１は、パーティーへの出席を示すパーティー出欠確認情報を、通信Ｉ／Ｆ２２によってサーバ１０へ送信する（Ｃ１４０）。
サーバ１０の制御部１１は、通信Ｉ／Ｆ１４によって端末２０Ｄからパーティー出欠確認情報を受信すると、パーティー出欠確認情報に基づき、各ユーザの出席または欠席が確定したことを確認する最終出欠管理処理を行う（Ｄ１６０）。
次いで、サーバ１０の制御部１１は、寄付金額および寄付ポイント額、ならびに各ユーザの支払い額を確定するパーティー代金確定処理を行う。そして、サーバ１０は、確定した各ユーザの出欠、寄付金額および寄付ポイント額、ならびに支払い額を含むパーティー代金分担金額情報を、通信Ｉ／Ｆ１４により端末２０Ａへ送信する（Ｄ１７０）。
端末２０Ａの制御部２１は、通信Ｉ／Ｆ２２によってサーバ１０からパーティー代金分担金額情報を受信すると、パーティー代金分担金額情報の内容を含むアプリケーション画面（不図示）を表示部２４に表示させる（Ａ１５０）。
サーバ１０の制御部１１は、パーティーに参加する、幹事以外のユーザ（限定ではなく例として、ユーザＢ．ＢおよびＤ．Ｄ）に対し、確定した支払額を電子マネーで徴収するパーティー代金徴収処理を行う（Ｄ１８０）。
具体的には、制御部１１は、確定した支払額の電子マネーでの支払いの了承を求めるパーティー代金要求情報を、通信Ｉ／Ｆ１４によって端末２０Ｂおよび２０Ｄへそれぞれ送信する。
パーティー代金徴収処理は、パーティーの開始予定時刻より前に行われる。これにより、パーティーに参加した参加者が、パーティー後に代金を支払わないなどのトラブルの発生を抑制することができる。なお、パーティー代金徴収処理は、パーティー中、またはパーティーの終了後に行われてもよいし、そのようにしなくてもよい。
端末２０Ｂの制御部２１は、通信Ｉ／Ｆ２２によってサーバ１０からパーティー代金要求情報を受信すると、確定した支払額を電子マネーで幹事であるユーザＡ．Ａへ送金するパーティー代金送金処理を行う（Ｂ１３０）。
具体的には、制御部２１は、限定ではなく例として、パーティー代金要求情報に基づき、支払額の電子マネーでの支払いの了承をユーザに求める支払い了承ボタンを含むアプリケーション画面を表示部２４に表示させる。ユーザＢ．Ｂが、その支払い了承ボタンをタッチする操作を行うと、制御部２１は、電子マネーでの支払いを了承した旨を示す支払い了承情報を、通信Ｉ／Ｆ２２によってサーバ１０へ送信する。
次いで、端末２０Ｄの制御部２１は、通信Ｉ／Ｆ２２によってサーバ１０からパーティー代金要求情報を受信すると、確定した支払額を電子マネーで幹事であるユーザＡ．Ａへ送金するパーティー代金送金処理を行う（Ｃ１５０）。
具体的には、制御部２１は、限定ではなく例として、パーティー代金要求情報に基づき、支払い了承ボタンを含むアプリケーション画面を表示部２４に表示させる。ユーザＤ．Ｄが、その支払い了承ボタンをタッチする操作を行うと、制御部２１は、電子マネーでの支払いを了承した旨を示す支払い了承情報を、通信Ｉ／Ｆ２２によってサーバ１０へ送信する。
サーバ１０の制御部１１は、通信Ｉ／Ｆ１４によって端末２０Ｂおよび２０Ｄからそれぞれ支払い了承情報を受信すると、これらの支払い了承情報に基づきパーティー集金額送金処理を行う（Ｄ１９０）。
本実施例では、電子マネーによる送金は、各ユーザの端末２０の識別子または店舗の識別子に関連付けられたユーザ管理データの電子マネー口座残高の増減によって実現される。
具体的には、端末２０Ｂの識別子に関連付けられたユーザ管理データの電子マネー口座残高から、確定した支払額（ユーザＢ．Ｂが支払うべき会費）のうちの現金金額分を減額し、その減額分を、端末２０Ａの識別子に関連付けられたユーザ管理データの電子マネー口座残高に加えることで、ユーザＢ．ＢからユーザＡ．Ａへの電子マネーの送金が実現される。
また、電子ポイントによる送金も、電子マネーによる送金と同様に、各ユーザの端末２０の識別子または店舗の識別子に関連付けられたユーザ管理データの電子ポイント口座残高の増減によって実現される。具体的には、制御部２１は、限定ではなく例として、ユーザＢ．Ｂの電子ポイント口座残高から、確定した支払額（ユーザＢ．Ｂが支払うべき会費）のうちの電子ポイント分を減額し、その減額分を、ユーザＡ．Ａの電子ポイント口座残高に加える。
同様に、制御部１１は、限定ではなく例として、ユーザＤ．Ｄの電子マネー口座残高および電子ポイント口座残高から、確定した支払額（ユーザＤ．Ｄが支払うべき会費）のうちの現金金額分および電子ポイント分をそれぞれ減額し、それらの減額分を、ユーザＡ．Ａの電子マネー口座残高および電子ポイント口座残高に加える。
サーバ１０の制御部１１は、限定ではなく例として、パーティーの開始時刻より前のタイミング（限定ではなく例として、パーティー代金徴収処理の直後のタイミング）において、ユーザＢ．ＢおよびＤ．Ｄが支払うべき会費が、ユーザＡ．Ａの電子口座へ電子マネーで送金された旨と、事前決済の了承を求める旨とを示す送金完了情報を、通信Ｉ／Ｆ１４によって端末２０Ａへ送信する。
このように、パーティーの開始時刻より前に事前決済を求めることで、店舗側は、パーティーの開始時刻より前にパーティー代金を確保することができるので、パーティーが直前になってキャンセルされたり、各ユーザがパーティー会場に現れなかったりする場合であっても、店舗側の損害を抑制することができる。
端末２０Ａの制御部２１は、通信Ｉ／Ｆ２２によってサーバ１０から送金完了情報を受信すると、限定ではなく例として、送金完了情報に基づき、ユーザＢ．ＢおよびＤ．Ｄからの会費の徴収が完了した旨を含むアプリケーション画面を表示部２４に表示させる。
また、制御部２１は、送金完了情報に基づき、事前決済の了承をユーザに求める事前決済了承ボタンを含むアプリケーション画面を表示部２４に表示させる。
ユーザＡ．Ａが、事前決済了承ボタンをタッチする操作を行うと、制御部２１は、事前決済が了承された旨を示す店舗決済情報を、通信Ｉ／Ｆ２２によってサーバ１０へ送信する（Ａ１６０）。
サーバ１０の制御部１１は、通信Ｉ／Ｆ１４によって端末２０Ａから店舗決済情報を受信すると、店舗決済情報に基づき店舗決済処理を行う（Ｄ２００）。
具体的には、サーバ１０の制御部１１は、限定ではなく例として、店舗決済情報に基づき、ユーザＡ．Ａの電子マネー口座残高から、総支払予定金額のうちの現金金額分を減額し、その減額分を、パーティーが行われる店舗（限定ではなく例として、レストラン ナーダ）の識別子と関連付けられた電子マネー口座残高に加える。
なお、サーバ１０の運営会社は、限定ではなく例として、総支払予定金額のうちの現金金額分から手数料分を徴収してもよい。このとき、その店舗の識別子と関連付けられた電子マネー口座には、総支払予定金額のうちの現金金額分から手数料分が差し引かれた電子マネーが送金される。また、その手数料分の電子マネーは、その運営会社の識別子に関連付けられた電子マネー口座に送金される。
また、制御部１１は、店舗決済情報に基づき、ユーザＡ．Ａの電子ポイント口座残高から、総支払予定金額のうちのポイント分を減額し、その減額分を、パーティーが行われる店舗（限定ではなく例として、レストラン ナーダ）の識別子と関連付けられた電子ポイント口座残高に加える
次いで、サーバ１０の制御部１１は、限定ではなく例として、パーティーの終了予定時刻が経過すると、支払金額に基づき、総還元金額および総還元ポイント額を算出する。そして、制御部１１は、総還元金額および総還元ポイント額ならびに各ユーザの分担割合に基づき、ユーザごとの還元金額および還元ポイント額を算出し、イベントの概要および算出結果を含む決済還元情報を、通信Ｉ／Ｆ１４によって端末２０Ａへ送信する（Ｄ２１０）。
端末２０Ａの制御部２１は、通信Ｉ／Ｆ２２によってサーバ１０から決済還元情報を受信すると、決済還元情報に基づき、図２５に示すアプリケーション画面を表示部２４に表示させる（Ａ１７０）。
次いで、ユーザＡ．Ａが、図２５に示すアプリケーション画面における分担割合変更ボタンをタッチする操作を行うと、制御部２１は、パーティー代金還元割合変更処理を行う（Ａ１７０）。
具体的には、制御部２１は、図１７に示すアプリケーション画面と同様のアプリケーション画面を表示部２４に表示させ、ユーザＡ．Ａの入出力部２３に対する入力操作（限定ではなく例として、表示部２４に表示された円グラフに対するドラッグ操作）に基づき、ユーザＡ．Ａ、Ｂ．ＢおよびＤ．Ｄの分担割合の変更が反映された円グラフを表示部２４に表示させる。
ユーザＡ．Ａが、分担割合変更決定ボタンをタッチすると、制御部１１は、表示部２４に表示された円グラフに基づき、再設定後の各ユーザの分担割合を含む還元額分担割合変更情報を通信Ｉ／Ｆ２２によってサーバ１０へ送信する。
サーバ１０は、還元額分担割合情報に基づき、各ユーザの分担割合を変更し、変更後の各ユーザの分担割合に基づき、ユーザごとの還元金額および還元ポイント額を再計算し、算出結果を含む還元額再算出結果情報を端末２０Ａへ送信する。
端末２０Ａの制御部２１は、通信Ｉ／Ｆ２２によってサーバ１０から還元額再算出結果情報を受信すると、還元額再算出結果情報に基づき、還元金額および還元ポイント額の再計算結果が反映された、図２５に示すアプリケーション画面を表示部２４に表示させる。
ユーザＡ．Ａが、図２５に示すアプリケーション画面の配分ボタンをタッチする操作を行うと、端末２０Ａの制御部２１は、還元金額および還元ポイント額を了承した旨を示す還元額了承情報を、通信Ｉ／Ｆ２２によってサーバ１０へ送信する。
サーバ１０の制御部１１は、通信Ｉ／Ｆ１４によって端末２０Ａから還元額了承情報を受信すると、還元額了承情報に基づき決済還元分配処理を行う（Ｄ２２０）。
具体的には、制御部１１は、ユーザごとに、還元額再算出結果情報に基づき、サーバ１０の運営会社の識別子に関連付けられた電子マネー口座残高から、そのユーザに対する還元金額分を減額し、その減額分を、そのユーザの電子マネー口座残高に加える。
同様に、制御部１１は、ユーザごとに、還元額再算出結果情報に基づき、サーバ１０の運営会社の識別子に関連付けられた電子ポイント口座残高から、そのユーザに対する還元ポイント額分を減額し、その減額分を、そのユーザの電子ポイント口座残高に加える。
そして、制御部１１は、各ユーザの端末２０（限定ではなく例として、端末２０Ａ、２０Ｂおよび２０Ｄ）へ送信すべき決済還元受け取り情報を作成する。この決済還元受け取り情報には、イベントの概要、送信対象のユーザの支払額ならびに送信対象のユーザの還元金額および還元ポイント額を含む。制御部１１は、端末２０Ａ、２０Ｂおよび２０Ｄへ送信すべき決済還元受け取り情報を、通信Ｉ／Ｆ１４によって端末２０Ａ、２０Ｂおよび２０Ｄへそれぞれ送信する。
端末２０Ｂの制御部２１は、通信Ｉ／Ｆ２２によってサーバ１０から決済還元受け取り情報を受信すると、決済還元受け取り情報に基づき、図２６に示すアプリケーション画面を表示部２４に表示させる決済還元受け取り処理を行う（Ｂ１４０）。
次いで、端末２０Ａの制御部２１は、通信Ｉ／Ｆ２２によってサーバ１０から決済還元受け取り情報を受信すると、決済還元受け取り情報の内容を含むアプリケーション画面を表示部２４に表示させる決済還元受け取り処理を行う（Ａ１８０）。
次いで、端末２０Ｄの制御部２１は、通信Ｉ／Ｆ２２によってサーバ１０から決済還元受け取り情報を受信すると、決済還元受け取り情報の内容を含むアプリケーション画面を表示部２４に表示させる決済還元受け取り処理を行う（Ｃ１６０）。
なお、上記のフローチャートでは、端末２０ＢにおけるＢ１１０およびＢ１２０の処理のステップが行われた後、端末２０ＤにおけるＣ１１０およびＣ１２０の処理のステップが行われる構成について説明したが、端末２０ＢにおけるＢ１１０およびＢ１２０の処理のステップと、端末２０ＣにおけるＣ１１０およびＣ１２０の処理のステップとは、独立しているので、Ｂ１１０の処理の後にＢ１２０の処理が行われ、かつＣ１１０の処理の後にＣ１２０の処理が行われる順番が守られる限り、Ｂ１１０およびＢ１２０ならびにＣ１１０およびＣ１２０の各処理の順序は入れ換えられてもよい。
また、上記のフローチャートでは、端末２０ＢにおけるＢ１３０の処理のステップが行われた後、端末２０ＤにおけるＣ１５０の処理のステップが行われる構成について説明したが、Ｂ１３０の処理およびＣ１５０の処理の順序は入れ換えられてもよい。
また、上記のフローチャートでは、端末２０ＢにおけるＢ１４０の処理のステップが行われ、端末２０ＡにおけるＡ１８０の処理のステップが行われた後、端末２０ＤにおけるＣ１６０の処理のステップが行われる構成について説明したが、Ｂ１４０の処理、Ａ１８０の処理およびＣ１６０の処理の順序は入れ換えられてもよい。
＜変形例（１）＞
上記の実施例では、還元金額および還元ポイントが各ユーザの分担割合に応じて分配される構成について説明したが、還元金額および還元ポイントが、ユーザの要望が反映された割合に応じて分配される構成であってもよいし、そうでなくてもよい。
図２９は、図１９に示すアプリケーション画面の変形例を示す図である。このアプリケーション画面は、図１８に示すアプリケーション画面において招待状送付ボタンがタッチされた場合に、ユーザＢ．Ｂの端末２０Ｂの表示部２４に表示される。
本変形例では、トークルーム画面２４６２において、告知情報表示欄２４６２ｄと、参加ボタンとの間に、キャッシュバック重視ラジオボタン２４６２ｊと、ポイント還元重視ラジオボタン２４６２ｋとが配置される。キャッシュバック重視ラジオボタン２４６２ｊおよびポイント還元重視ラジオボタン２４６２ｋは、デフォルトでは選択されていない。本変形例では、キャッシュバック重視ラジオボタン２４６２ｊおよびポイント還元重視ラジオボタン２４６２ｋは、限定ではなく例として、排他的に動作する。具体的には、キャッシュバック重視ラジオボタン２４６２ｊおよびポイント還元重視ラジオボタン２４６２ｋのいずれか一方がユーザによってタッチされて選択状態へ遷移すると、他方は、非選択状態へ遷移するか、または非選択状態を維持する。図２９に示すアプリケーション画面では、キャッシュバック重視ラジオボタン２４６２ｊが選択状態にある一方、ポイント還元重視ラジオボタン２４６２ｋが非選択状態にある。
限定ではなく例として、キャッシュバック重視ラジオボタン２４６２ｊが選択状態にあるときに、参加ボタンがタッチされた場合、図２５に示すアプリケーション画面での還元金額および還元ポイントの分配は、ユーザＢ．Ｂへ配分されるべき１００ポイントの還元ポイントが、現金金額に変換されたと仮定して、ユーザＢ．Ｂへ配分されるべき還元金額（限定ではなく例として、５０円）に加えられる。つまり、ユーザＢ．Ｂへ配分されるべき還元金額および還元ポイントが、それぞれ１５０円およびゼロポイントとなる。
ユーザＢ．Ｂに１５０円の還元金額を配分するには、ユーザＢ．Ｂ以外のユーザすなわちユーザＡ．Ａ、Ｃ．ＣおよびＤ．Ｄから１００円を拠出させなければならない。
限定ではなく例として、仮にユーザＣ．Ｃがポイント重視である場合、ユーザＣ．Ｃへ配分されるべき１００円の還元金額がユーザＢ．Ｂへ配分されるとともに、ユーザＢ．Ｂへ配分されるべき１００ポイントの還元ポイントがユーザＣ．Ｃへ配分される。つまり、ユーザＣ．Ｃへ配分されるべき還元金額および還元ポイントが、それぞれゼロ円および３００ポイントとなる。
なお、ユーザＢ．Ｂ以外のユーザの中にポイント重視のユーザが存在しない場合、限定ではなく例として、ユーザＡ．Ａ、Ｃ．ＣおよびＤ．Ｄへ配分されるべき現金金額から分担割合に応じて合計１００円が徴収されるとともに、ユーザＢ．Ｂへ配分されるべき１００ポイントを分担割合に応じて分割し、ユーザＡ．Ａ、Ｃ．ＣおよびＤ．Ｄへ配分される。
このように、還元金額および還元ポイントが、ユーザの要望が反映された割合に応じて分配されることで、還元金額または還元ポイントを受けることによるお得感がさらに強調され、イベント管理サービスを利用するユーザの満足度を高めることができる。
具体的には、限定ではなく例として、使用用途の多い電子マネーの還元を優先的に受けることで、ユーザのショッピングの利便性を高めることができる。一方、使用の用途がある程度制限される電子ポイントの還元ポイントを優先的に受けることで、電子ポイントの無駄遣いを抑制することができるので、ユーザの貯蓄を補助することができる。
＜変形例（２）＞
上記の実施例では、還元金額および還元ポイントが各ユーザの分担割合に応じて分配される構成について説明したが、還元金額および還元ポイントが、店舗におけるユーザの滞在時間の長さに応じて分配される構成であってもよいし、そうでなくてもよい。
制御部２１は、限定ではなく例として、時計部２９２から時刻情報を定期的に取得する。制御部２１は、イベントの開始予定時刻が到来すると、位置検出部２９１から位置算出用情報を定期的に取得し、位置算出用情報に基づき自己の端末２０の位置を算出する。制御部２１は、この位置を含む位置情報と時刻情報とを関連付けた行動情報を定期的に生成し、サーバ１０へ送信する。制御部２１による行動情報の生成および送信は、限定ではなく例として、少なくともイベントの終了予定時刻まで継続する。
なお、行動情報の生成において、制御部２１は、限定ではなく例として、店舗等に設置されるビーコン（近接無線技術を利用した電波標識）から店舗の位置情報を含むビーコン信号を受信することにより、自端末の位置を算出してもよい。
サーバ１０の制御部１１は、通信Ｉ／Ｆ１４によって端末２０から行動情報を定期的に受信し、受信した行動情報を、端末２０の識別子に関連付けて記憶部１５に記憶させる。この識別子は、限定ではなく例として、端末２０で動作するメッセージングアプリケーションもしくイベント企画サブプログラムのアプリケーションＩＤ、端末電話番号または端末メールアドレスなどである。
サーバ１０の制御部１１は、限定ではなく例として、イベント企画サブプログラムの要求に応じて、記憶部１５に蓄積した行動情報に基づきユーザごとの滞在時間を集計し、集計結果を含む集計情報を作成する。
制御部１１は、限定ではなく例として、Ｄ２１０の処理のステップ（図２８参照）において、決済還元情報とともに集計情報を、通信Ｉ／Ｆ１４によって端末２０Ａへ送信する。
端末２０Ａの制御部２１は、限定ではなく例として、通信Ｉ／Ｆ２２によってサーバ１０から決済還元情報および集計情報を受信すると、決済還元情報および集計情報に基づき、図３０に示すアプリケーション画面を表示部２４に表示させる。
図３０は、図２５に示すアプリケーション画面の変形例を示す図である。このアプリケーション画面は、タイトルバー領域２４１と、グループ名表示領域２４２と、進行状況表示領域２４３と、ワーク領域２４４とを含む。
本変形例では、ワーク領域２４４に表示されるイベント管理画面２４８６の最上部には、＋印を有する展開ボタンが表示され、最小化されたイベント概要表示欄２４８６ｌが配置される。限定ではなく例として、展開ボタンがタッチされると、イベント概要表示欄２４８６ｌが展開し、イベント概要表示欄２４８６ｌには、イベント概要が表示される（図１６参照）。
イベント概要表示欄２４８６ｌの下側には、滞在時間表示欄２４８６ｎが配置される。本変形例では、滞在時間表示欄２４８６ｎには、限定ではなく例として、各ユーザが店舗に滞在した時間を示すグラフが表示される。本変形例では、ユーザＡ．Ａ、Ｂ．Ｂ、Ｃ．ＣおよびＤ．Ｄのそれぞれのユーザ名である「Ａ．Ａ」、「Ｂ．Ｂ」、「Ｃ．Ｃ」および「Ｄ．Ｄ」の文字列が、この順番で縦に並べられる。なお、幹事であるユーザＡ．Ａの文字列には、幹事マークが左側に付される。
各ユーザ名の文字列の右側には、そのユーザ名に対応して配置される４つの滞在時間表示バーが表示される。各滞在時間表示バーは、横方向の同じ長さを有するが、対応のユーザ名のユーザが店舗に滞在している時間は、黒の塗りつぶしで表示され、そのユーザが店舗に滞在していない時間は、白抜きで表示される。
具体的には、限定ではなく例として、ユーザＡ．ＡおよびＤ．Ｄは、イベントの開始時刻である「１９：００」から終了時刻である「２１：００」まで店舗に滞在したため、「Ａ．Ａ」および「Ｄ．Ｄ」の文字列の右側に位置する滞在時間表示バーは、１９：００～２１：００まで黒の塗りつぶしで表示される。
ユーザＢ．Ｂは、イベントの開始時刻から３０分経過した「１９：３０」から終了時刻である「２１：００」まで店舗に滞在したため、「Ｂ．Ｂ」の文字列の右側に位置する滞在時間表示バーは、１９：００～１９：３０まで白抜きで表示され、１９：３０～２１：００まで黒の塗りつぶしで表示される。
ユーザＣ．Ｃは、イベントの開始時刻である「１９：００」から終了時刻の１時間前である「２０：００」まで店舗に滞在したため、「Ｃ．Ｃ」の文字列の右側に位置する滞在時間表示バーは、１９：００～２０：００まで黒の塗りつぶしで表示され、０：００～２１：００まで白抜きで表示される。
各滞在時間表示バーの右側には、その滞在時間表示バーに対応して配置され、そのユーザが店舗に滞在した時間の合計である滞在時間が表示される。
具体的には、限定ではなく例として、ユーザＡ．ＡおよびＤ．Ｄは、「１９：００」か「２１：００」まで店舗に滞在したため、滞在時間として「１２０分」の文字列が表示される。
ユーザＢ．Ｂは、「１９：３０」から「２１：００」まで店舗に滞在したため、滞在時間として「９０分」の文字列が表示される。ユーザＣ．Ｃは、「１９：００」から「２０：００」まで店舗に滞在したため、滞在時間として「６０分」の文字列が表示される。なお、ユーザＢ．ＢおよびＣ．Ｃは、イベントの開始時刻から終了時刻まで継続して店舗に滞在していなかったため、遅刻または早退を意味する、時計を模したマークが、滞在時間の文字列の右側に表示される。
本変形例では、還元金額および還元ポイントは、限定ではなく例として、各ユーザの分担割合および各ユーザの店舗における滞在時間に応じて分配される。具体的には、限定ではなく例として、上述したように、ユーザＡ．Ａ、Ｂ．Ｂ、Ｃ．ＣおよびＤ．Ｄの店舗における滞在時間は、それぞれ１２０分、９０分、６０分および１２０分である。サーバ１０の制御部１１は、この滞在時間の逆数の比として、１／１２０：１／９０：１／６０：１／１２０、すなわち１：４／３：２：１を、ユーザＡ．Ａ、Ｂ．Ｂ、Ｃ．ＣおよびＤ．Ｄの還元率係数比として算出する。そして、制御部１１は、この還元率係数比に、各ユーザの分担割合の比である３：１：２：２を乗じることで、３：４／３：４：２すなわち９：４：１２：６の新たな分担割合の比（以下、滞在時間反映還元比とも称する。）として算出する。
具体的には、限定ではなく例として、還元額管理表示欄２４８６ｊでは、管理対象ユーザアイコン群において、イベントの開始時刻から終了時刻まで継続して店舗に滞在していなかったユーザＢ．ＢおよびＣ．Ｃのユーザアイコンの右側には、時計を模したマークが付される。
管理対象ユーザアイコン群の右側に配置される分担割合表示バー群では、元々の各ユーザの分担割合の比すなわち３：１：２：２で、網掛けが施された表示バーが表示される。そして、滞在時間反映還元比すなわち３：４／３：４：２によって、ユーザＢ．ＢおよびＣ．Ｃに増額される分が、白抜きの表示バーによって表示される。
そして、幹事であるユーザＡ．Ａに対応する還元金額表示欄２４８６ｂには、４００円に、滞在時間反映還元比に基づくユーザＡ．Ａの還元割合である９／３１を乗じた額の「１１６円」が表示される。還元ポイント表示欄２４８６ｆには、８００ポイントに、その還元割合である９／３１を乗じた額の「２３２ポイント」が表示される。
同様に、限定ではなく例として、ユーザＢ．Ｂに対応する還元金額表示欄２４８６ｃには、４００円に、滞在時間反映還元比に基づくユーザＢ．Ｂの還元割合である４／３１を乗じた額の「５２円」が表示される。還元ポイント表示欄２４８６ｇには、８００ポイントに、その還元割合である４／３１を乗じた額の「１０３ポイント」が表示される。
同様に、限定ではなく例として、ユーザＣ．Ｃに対応する還元金額表示欄２４８６ｄには、４００円に、滞在時間反映還元比に基づくユーザＣ．Ｃの還元割合である１２／３１を乗じた額の「１５５円」が表示される。還元ポイント表示欄２４８６ｈには、８００ポイントに、その還元割合である１２／３１を乗じた額の「３１０ポイント」が表示される。
同様に、限定ではなく例として、ユーザＤ．Ｄに対応する還元金額表示欄２４８６ｅには、４００円に、滞在時間反映還元比に基づくユーザＤ．Ｄの還元割合である６／３１を乗じた額の「７７円」が表示される。還元ポイント表示欄２４８６ｉには、８００ポイントに、その還元割合である６／３１を乗じた額の「１５５ポイント」が表示される。
このように、滞在時間の少ないユーザに対して、還元金額および還元ポイントを多めに付与することで、イベントで提供されるサービスの低下分を、還元金額および還元ポイントで補うことができるので、イベントに遅れて参加したり、イベントを早退したりするユーザの不満を緩和させることができる。これにより、イベント管理サービスを利用するユーザの満足度を高めることができる。
なお、本変形例では、還元金額および還元ポイントが、店舗におけるユーザの滞在時間の長さに応じて分配される構成について説明したが、還元金額および還元ポイントが、店舗におけるユーザの滞在時間帯に応じて分配される構成であってもよいし、そうでなくてもよい。
具体的には、限定ではなく例として、イベントが、早期の時間帯（限定ではなく例として、開始時刻から３０分が経過するまで。）に多くの料理が提供されるパーティーである場合、パーディーの開始時刻から３０分が経過するまでに滞在していなかったユーザに対して、還元金額および還元ポイントが多めに割り当てられる。この場合、パーディーの開始時刻から３０分が経過したタイミング以降に早退するユーザに対しては、還元金額および還元ポイントが多めに割り当てられない。
一方、限定ではなく例として、イベントが、早期の時間帯（限定ではなく例として、開始時刻から３０分が経過するまで。）に多くの料理が提供されないパーティーである場合、パーディーの開始時刻から３０分が経過したタイミング以降に早退するユーザに対しては、還元金額および還元ポイントが多めに割り当てることも可能である。
＜変形例（３）＞
上記の実施例では、現金金額および電子ポイントが還元の対象となる構成について説明したが、電子クーポンが還元の対象として加えられる構成、または電子クーポンが還元の対象となる構成であってもよいし、そうでなくてもよい。本変形例では、限定ではなく例として、ユーザＡ．Ａ、Ｂ．Ｂ、Ｃ．ＣおよびＤ．Ｄが「レストラン ナーダ」で食事を終えた後、「レストラン ナーダ」から、支払金額の１０％に相当する１６００円分の電子クーポンを含むメッセージが、幹事であるユーザＡ．Ａの端末２０Ａに送信されることとする。
図３１は、ユーザＡ．Ａの端末２０Ａにおける表示部２４に表示される、メッセージングアプリケーションのアプリケーション画面の一例を示す図である。このアプリケーション画面は、電子クーポンを含むメッセージが端末２０Ａによって受信された後に、端末２０Ａにおける表示部２４に表示されるアプリケーション画面である。このアプリケーション画面は、タイトルバー領域２４１と、グループ名表示領域２４２と、進行状況表示領域２４３と、ワーク領域２４４とを含む。
タイトルバー領域２４１およびグループ名表示領域２４２の表示内容は、図１４に示すタイトルバー領域２４１およびグループ名表示領域２４２の表示内容とそれぞれ同一である。進行状況表示領域２４３の表示内容は、図２３に示す進行状況表示領域２４３の表示内容と同一である。
ワーク領域２４４には、イベント管理画面２４８８が表示される。イベント管理画面２４８８の最上部には、＋印を有する展開ボタンが表示され、最小化されたイベント概要表示欄２４８６ｌが配置される。
イベント概要表示欄２４８６ｌの下側には、電子クーポン表示欄が配置される。本変形例では、電子クーポン表示欄には、限定ではなく例として、利用金額から１６００円を値引きすることが可能な、「レストラン ナーダ」からの電子クーポンの画像が表示される。
電子クーポン表示欄の下側には、会費表示欄が配置される。本変形例では、会費表示欄の表示内容は、図２５に示す会費表示欄の表示内容と同一である。
会費表示欄の下側には、クーポン金額表示欄が配置される。クーポン金額表示欄には、限定ではなく例として、上述したように、１６００円分の電子クーポンのクーポン金額が表示される。
クーポン金額表示欄の下側には、クーポン額管理表示欄２４８８ａが配置される。クーポン額管理表示欄２４８８ａには、限定ではなく例として、管理対象ユーザアイコン群が左側に表示される。本変形例では、管理対象ユーザアイコン群には、限定ではなく例として、ユーザＡ．Ａ、Ｂ．Ｂ、Ｃ．ＣおよびＤ．Ｄのユーザアイコンが、この順番でユーザ名とともに縦に並べられる。幹事であるユーザＡ．Ａのユーザアイコンには、幹事マークが左下に付される。なお、ユーザＡ．Ａ、Ｂ．Ｂ、Ｃ．ＣおよびＤ．Ｄのすべての参加が確定しているので、ユーザアイコンには、参加確定マーク、参加保留マークおよび不参加確定マークのいずれも付されない。
管理対象ユーザアイコン群の右側には、分担割合表示バー群が配置される。分担割合表示バー群の表示内容は、ユーザＡ．Ａの分担割合と、ユーザＢ．Ｂの分担割合と、ユーザＣ．Ｃの分担割合と、ユーザＤ．Ｄの分担割合との比が３：１：２：２に再設定された、図１８に示す分担割合表示バー群の表示内容と同一である。
分担割合表示バー群の右側には、このイベントでの管理対象のユーザのユーザアイコンに対応して配置され、そのユーザに分配されるべき電子クーポンの金額に応じた枚数の電子クーポン券（限定ではなく例として、額面が１００円の電子クーポン券）の画像を表示したクーポン券画像群が配置される。電子クーポンは、限定ではなく例として、各ユーザの分担割合に応じて分配される。具体的には、ユーザＡ．Ａには、１６００円分の電子クーポン金額に、ユーザＡ．Ａに再設定された分担割合である３／８を乗じた額である６００円分の電子クーポンが分配されるため、電子クーポン券６枚分の画像が、ユーザＡ．Ａのユーザアイコンに対応して表示される。
同様に、ユーザＢ．Ｂには、１６００円分の電子クーポン金額に、ユーザＢ．Ｂに再設定された分担割合である１／８を乗じた額である２００円分の電子クーポンが分配されるため、電子クーポン券２枚分の画像が、ユーザＢ．Ｂのユーザアイコンに対応して表示される。ユーザＣ．ＣおよびＤ．Ｄには、１６００円分の電子クーポン金額に、ユーザＣ．ＣおよびＤ．Ｄに再設定された分担割合である４／８を乗じた額である４００円分の電子クーポンが分配される。このため、電子クーポン券４枚分の画像が、ユーザＣ．ＣおよびＤ．Ｄのユーザアイコンにそれぞれ対応して表示される。
クーポン券画像群の右側には、クーポン配分額表示欄２４８８ｅ、２４８８ｆ、２４８８ｇおよび２４８８ｈが、ユーザＡ．Ａ、Ｂ．Ｂ、Ｃ．ＣおよびＤ．Ｄにそれぞれ対応するように配置される。上述したように、ユーザＡ．Ａ、Ｂ．Ｂ、Ｃ．ＣおよびＤ．Ｄにそれぞれ配分される電子クーポン金額は、６００円、２００円、４００円および４００円である。このため、クーポン配分額表示欄２４８８ｅ、２４８８ｆ、２４８８ｇおよび２４８８ｈには、「６００円」、「２００円」、「４００円」および「４００円」がそれぞれ表示される。
クーポン額管理表示欄２４８８ａの下側には、このイベントでの管理対象のユーザの分担割合を変更するための分担割合変更ボタンが配置される。この場合、限定ではなく例として、分担割合変更ボタンをタッチすることで、電子クーポンの分配に用いる管理対象のユーザの分担割合を変更することができる。
分担割合変更ボタンの下側には、決定した電子クーポン金額を含むメッセージを、このイベントでの管理対象のユーザへ送信するための配分ボタンが配置される。
図３２は、図３１に示すアプリケーション画面において配分ボタンがタッチされた場合に、ユーザＢ．Ｂの端末２０Ｂの表示部２４に表示されるアプリケーション画面の一例を示す図である。このアプリケーション画面は、タイトルバー領域２４１と、グループ名表示領域２４２と、ワーク領域２４４とを含む。
タイトルバー領域２４１およびグループ名表示領域２４２の表示内容は、図１９に示すタイトルバー領域２４１およびグループ名表示領域２４２の表示内容とそれぞれ同一である。
本変形例では、限定ではなく例として、端末２０Ｂのワーク領域２４４には、トークルーム画面２４６９と、サブプログラム選択画面２４７９とが表示される。
トークルーム画面２４６９には、図２６に示す、幹事であるユーザＡ．Ａからのメッセージの内容を含む吹き出し２４６７ａが表示される。吹き出し２４６７ａの表示内容は、図２６に示す吹き出し２４６７ａの表示内容と同一である。
吹き出し２４６７ａの下側には、電子クーポン券画像が表示される。電子クーポン券画像は、吹き出し２４６７ａに続くメッセージとしてトークルーム画面２４６９に配置され、ユーザＢ．Ｂに対する電子クーポン金額である「２００円」が表示される。
＜変形例（４）＞
上記の実施例では、幹事（限定ではなく例として、ユーザＡ．Ａ）が、パーティー代金について店舗と決済する前に、幹事以外のユーザ（限定ではなく例として、ユーザＢ．ＢおよびＤ．Ｄ）が、自身の支払額を幹事へ送金する構成すなわち前払いの構成について説明したが、幹事以外のユーザは、パーティー代金について幹事が店舗と決済した後に、自身の支払額を幹事へ送金する構成すなわち後払いの構成であってもよいし、そうでなくてもよい。
しかしながら、幹事以外のユーザが後払いする場合、幹事は、店舗側にユーザ全員分の代金を支払ったにも関わらず、後払いのユーザからそのユーザ分の代金を得ることができなくなるリスクを負うことになる。
本変形例では、幹事は、限定ではなく例として、図３１に示すアプリケーション画面での電子クーポンの分配において、前払いのユーザを後払いのユーザより優遇する。
具体的には、幹事であるユーザＡ．Ａは、図３１に示すアプリケーション画面における分担割合変更ボタンをタッチする操作を行う。制御部２１は、ユーザＡ．Ａの操作に応じて、図１７に示すアプリケーション画面と同様のアプリケーション画面を表示部２４に表示させる。
ユーザＡ．Ａは、限定ではなく例として、入出力部２３に対する入力操作（限定ではなく例として、表示部２４に表示された円グラフに対するドラッグ操作）によって、前払いのユーザの分担割合を大きくしながら、後払いのユーザの分担割合を小さくする。
これにより、前払いのユーザに対しては電子クーポン券が多めに分配されるのに対して、後払いのユーザに対しては電子クーポン券を少なめに分配される。
なお、本変形例では、ユーザの操作によって、前払いのユーザの分担割合を大きくしながら、後払いのユーザの分担割合を小さくする処理が行われる構成について説明したが、サーバ１０の制御部１１が、この処理を行う構成であってもよいし、そのようにしなくてもよい。
具体的には、制御部１１は、限定ではなく例として、パーティーの終了予定時刻が経過したタイミングで、店舗決済処理（Ｄ２００）が完了している場合、各ユーザの分担割合に基づき、ユーザごとの電子クーポン券の配分を算出する。このとき、制御部１１は、代金の未徴収のユーザが存在するか否かを確認する。制御部１１は、代金未徴収のユーザの存在を確認すると、そのユーザの分担割合を引き下げ、その引き下げた分を他のユーザに割り当てる。これにより、前払いのユーザに対しては電子クーポン券が多めに分配されるのに対して、後払いのユーザに対しては電子クーポン券を少なめに分配される。
また、本変形例では、前払いのユーザに対しては電子クーポン券が多めに分配されるのに対して、後払いのユーザに対しては電子クーポン券を少なめに分配される構成について説明したが、後払いのユーザに対しては電子クーポン券を少なめに分配せずに、後払いのユーザに分配すべき電子クーポン券を、前払いのユーザに分配する構成でであってもよいし、そのようにしなくてもよい。
＜変形例（４）の効果＞
このように、電子クーポン券の配分において、前払いのユーザを後払いのユーザより優遇することで、ユーザに前払いの利点を認識させることができるので、パーティーに参加するユーザの前払いを促進することができる。これにより、店舗側に参加ユーザ全員分の代金を支払ったにも関わらず、後払いのユーザからそのユーザ分の代金を得ることができなくなる幹事のリスクを低減することができる。
＜変形例（５）＞
上記の実施例では、１つのサーバ１０が、トークルーム画面におけるメッセージの管理処理を行うとともに、イベントの支払いなどを管理するイベント管理処理を行う構成について説明したが、メッセージ管理処理を行うサーバと、イベント管理処理を行うサーバとが、別個のサーバとなる構成であってもよいし、そのようにしなくてもよい。
図１３は、第３実施形態の変形例に係る通信システム１の構成の一例を示す図である。
第３実施形態の変形例に係る通信システム１では、サーバ１０は、イベント管理処理を行う支払い管理サーバ１０Ａと、メッセージ管理処理を行うメッセージングサーバ１０Ｂとを含む。
具体的には、支払い管理サーバ１０Ａは、限定ではなく例として、端末２０Ａにおいて動作するイベント企画サブプログラムと情報のやり取りを行い、イベントの企画受付、告知、代金徴収および決済などのイベント管理処理を行う。
メッセージングサーバ１０Ｂは、限定ではなく例として、端末２０Ａ、２０Ｂ、２０Ｃおよび２０Ｄの各々において動作するメッセージングアプリケーションと情報のやり取りを行い、イベントの告知内容、予算、出欠確認、会計結果などを含むメッセージの端末２０間でのやり取りを管理する。
１ 通信システム
１０ サーバ
２０ 端末
２１ 制御装置
２２ 通信Ｉ／Ｆ
２４ 表示装置
２８ 記憶装置
２１０ 比率入力部
２１１ 割合処理部
２１２ 割合警告部
２１３ 割合変更部

Claims (12)

  1. 支払金額に関連付けられた第１ユーザの第１端末と、前記支払金額に関連付けられた第２ユーザの第２端末と、第３ユーザの第３端末と通信するサーバによって実行されるプログラムであって、
    前記第３端末から、前記支払金額のうちの前記第１ユーザの負担に関する前記第１ユーザへの第１送金依頼と、前記支払金額のうちの前記第２ユーザの負担に関する前記第２ユーザへの第２送金依頼とを前記サーバの通信部によって受信することと、
    前記第１送金依頼を前記第１端末に前記通信部によって送信し、前記第２送金依頼を前記第２端末に前記通信部によって送信することと、
    前記第１送金依頼に基づき、前記第１ユーザから前記第３ユーザに送金する金額の情報を含む第１金額情報を前記第１端末から前記通信部によって受信することと、
    前記第１金額情報に基づき、前記第２ユーザに送信された前記第２送金依頼から変更された、前記支払金額のうちの前記第２ユーザの負担に関する第３送金依頼を前記第２端末に前記通信部によって送信することとが前記サーバによって実行される。
  2. 請求項１に記載のプログラムであって、
    前記第１送金依頼は、前記第３ユーザに送金する金額の情報である第２金額情報を含み、
    前記第１金額情報は、前記第２金額情報よりも高い金額の情報を含む。
  3. 請求項２に記載のプログラムであって、
    前記第３送金依頼は、前記第２金額情報の金額と前記第１金額情報の金額との差額に基づいて決定される。
  4. 請求項３に記載のプログラムであって、
    前記第３送金依頼は、前記差額と、前記第２ユーザと、前記第３ユーザとに基づいて決定される。
  5. 請求項１に記載のプログラムであって、
    前記第１金額情報は、前記第１送金依頼に含まれる前記第３ユーザに送金する金額の情報と、ポイントの情報とを含む。
  6. 請求項５に記載のプログラムであって、
    前記第３送金依頼は、前記ポイントの情報に基づいて決定される。
  7. 請求項１から請求項６のいずれか一項に記載のプログラムであって、
    前記第３送金依頼は、前記第２ユーザを含むチャットルームに表示される。
  8. 請求項７に記載のプログラムであって、
    前記第３送金依頼は、前記第２送金依頼に含まれる金額の情報から減額された金額の情報を含む。
  9. 請求項１から請求項８のいずれか一項に記載のプログラムであって、
    前記第３ユーザによる前記第３端末に対する入力に基づいて、前記第３送金依頼を前記第２端末に前記通信部によって送信することが前記サーバによって実行される。
  10. 請求項１から請求項９のいずれか一項に記載のプログラムであって、
    前記第１送金依頼に含まれる金額の情報と、前記第２送金依頼に含まれる金額の情報とは、前記第３ユーザによる前記第３端末への入力に基づいて決定される。
  11. 支払金額に関連付けられた第１ユーザの第１端末と、前記支払金額に関連付けられた第２ユーザの第２端末と、第３ユーザの第３端末と通信するサーバの情報処理方法であって、
    前記第３端末から、前記支払金額のうちの前記第１ユーザの負担に関する前記第１ユーザへの第１送金依頼と、前記支払金額のうちの前記第２ユーザの負担に関する前記第２ユーザへの第２送金依頼とを前記サーバの通信部によって受信することと、
    前記第１送金依頼を前記第１端末に前記通信部によって送信し、前記第２送金依頼を前記第２端末に前記通信部によって送信することと、
    前記第１送金依頼に基づき、前記第１ユーザから前記第３ユーザに送金する金額の情報を含む第１金額情報を前記第１端末から前記通信部によって受信することと、
    前記第１金額情報に基づき、前記第２ユーザに送信された前記第２送金依頼から変更された、前記支払金額のうちの前記第２ユーザの負担に関する第３送金依頼を前記第２端末に前記通信部によって送信することとを含む。
  12. 支払金額に関連付けられた第１ユーザの第１端末と、前記支払金額に関連付けられた第２ユーザの第２端末と、第３ユーザの第３端末と通信するサーバであって、
    前記第３端末から、前記支払金額のうちの前記第１ユーザの負担に関する前記第１ユーザへの第１送金依頼と、前記支払金額のうちの前記第２ユーザの負担に関する前記第２ユーザへの第２送金依頼とを受信し、前記第１送金依頼を前記第１端末に送信し、前記第２送金依頼を前記第２端末に送信し、前記第１送金依頼に基づき、前記第１ユーザから前記第３ユーザに送金する金額の情報を含む第１金額情報を前記第１端末から受信する通信部と、
    前記第１金額情報に基づき、前記第２ユーザに送信された前記第２送金依頼から変更された、前記支払金額のうちの前記第２ユーザの負担に関する第３送金依頼を前記第２端末に前記通信部によって送信する制御を行う制御部とを備える。
JP2019194779A 2018-10-26 2019-10-25 プログラム、情報処理方法、サーバ Active JP7448135B2 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2018202023 2018-10-26
JP2018202023 2018-10-26

Publications (3)

Publication Number Publication Date
JP2020071881A JP2020071881A (ja) 2020-05-07
JP2020071881A5 JP2020071881A5 (ja) 2022-11-01
JP7448135B2 true JP7448135B2 (ja) 2024-03-12

Family

ID=70547917

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2019194779A Active JP7448135B2 (ja) 2018-10-26 2019-10-25 プログラム、情報処理方法、サーバ

Country Status (1)

Country Link
JP (1) JP7448135B2 (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7317393B2 (ja) * 2021-01-20 2023-07-31 株式会社Psi 情報処理装置

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007172358A (ja) 2005-12-22 2007-07-05 Ntt Docomo Inc 受領端末、送金端末、送金決済システム、受領方法、及び送金方法
JP2017531866A (ja) 2014-10-27 2017-10-26 フェイスブック，インク． メッセージベースのコンテキスト・プロンプトを使用した支払いの送信および受信の促進
JP2018097808A (ja) 2016-12-16 2018-06-21 グローリー株式会社 自動精算システム、自動精算装置および自動精算方法
JP2018124626A (ja) 2017-01-30 2018-08-09 株式会社三井住友銀行 方法、プログラム、携帯端末装置、及び記憶媒体
WO2018150487A1 (ja) 2017-02-15 2018-08-23 Ｌｉｎｅ株式会社 プログラム、情報処理方法、及び情報処理端末
JP2019061524A (ja) 2017-09-27 2019-04-18 株式会社日本総合研究所 情報システム、第一端末、第二端末、サーバ、入金処理方法、およびプログラム

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007172358A (ja) 2005-12-22 2007-07-05 Ntt Docomo Inc 受領端末、送金端末、送金決済システム、受領方法、及び送金方法
JP2017531866A (ja) 2014-10-27 2017-10-26 フェイスブック，インク． メッセージベースのコンテキスト・プロンプトを使用した支払いの送信および受信の促進
JP2018097808A (ja) 2016-12-16 2018-06-21 グローリー株式会社 自動精算システム、自動精算装置および自動精算方法
JP2018124626A (ja) 2017-01-30 2018-08-09 株式会社三井住友銀行 方法、プログラム、携帯端末装置、及び記憶媒体
WO2018150487A1 (ja) 2017-02-15 2018-08-23 Ｌｉｎｅ株式会社 プログラム、情報処理方法、及び情報処理端末
JP2019061524A (ja) 2017-09-27 2019-04-18 株式会社日本総合研究所 情報システム、第一端末、第二端末、サーバ、入金処理方法、およびプログラム

Also Published As

Publication number Publication date
JP2020071881A (ja) 2020-05-07

Similar Documents

Publication Publication Date Title
US20120010912A1 (en) Systems and methods for optimizing the scheduling of resources on an airplane
US20220353640A1 (en) System and Method for Appointment Scheduling
US20140249878A1 (en) Appointment scheduling
US9934536B2 (en) Interactive map for grouped activities within a financial and social management system
US20070094065A1 (en) Activity planning method and system
US20220004938A1 (en) Location-based activity computer systems
US20160300192A1 (en) Communication device interface alerts from a service provider server on detection of prior scheduled events
US20120010911A1 (en) Systems and methods for optimizing the scheduling of resources on an airplane
US20160117650A1 (en) Payment system
US20140074744A1 (en) System for move management
US11436936B2 (en) Platform for managing activities
US20200185096A1 (en) System and Method for Monitoring Engagement
KR102194683B1 (ko) 법률 상담 스케쥴 관리 방법 및 장치
US20120010910A1 (en) Systems and methods for optimizing the scheduling of resources on an airplane
US20200258075A1 (en) Closed loop multi-party feedback
KR20200012567A (ko) 여행 공유 서비스 시스템 및 방법
JP7448135B2 (ja) プログラム、情報処理方法、サーバ
US11132692B2 (en) Shared voting for accounting
CA3163116A1 (en) Transaction linking to a merchant chat with vicinity resident
CN113379084A (zh) 一种机票改期方法及机票改期装置
US11455342B2 (en) Systems and methods for service opportunity management and volunteer management
US11037076B1 (en) Method and system for distributing electronic ticket status information for a live event over a network to a remote subscriber portable computing device
US20120239478A1 (en) Systems and Methods for Employee Rewards
US20160086139A1 (en) Method for Scheduling and Managing Appointments Between Multiple Unaffiliated Parties
US8326668B2 (en) Managing encounters with persons

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20221024

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20221024

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20230913

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20231017

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20231215

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20240130

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20240220

R150 Certificate of patent or registration of utility model

Ref document number: 7448135

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150