特許 6795575 送金管理システム、送金管理方法、及びプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6795575

(24)【登録日】2020年11月16日

(45)【発行日】2020年12月2日

(54)【発明の名称】送金管理システム、送金管理方法、及びプログラム

(51)【国際特許分類】

   G06Q 20/08 20120101AFI20201119BHJP

   G06Q 20/06 20120101ALI20201119BHJP

【ＦＩ】

   G06Q20/08 300

   G06Q20/06

【請求項の数】18

【全頁数】27

(21)【出願番号】特願2018-245388(P2018-245388)

(22)【出願日】2018年12月27日

(65)【公開番号】特開2020-107088(P2020-107088A)

(43)【公開日】2020年7月9日

【審査請求日】2018年12月27日

(73)【特許権者】

【識別番号】510247995

【氏名又は名称】楽天銀行株式会社

(74)【代理人】

【識別番号】110000154

【氏名又は名称】特許業務法人はるか国際特許事務所

(72)【発明者】

【氏名】三井 諒

【審査官】 渡邉 加寿磨

(56)【参考文献】

【文献】 特開２０１４−１１２２８６（ＪＰ，Ａ）

【文献】 特開２００５−２６７０１２（ＪＰ，Ａ）

【文献】 特開２００７−２９９０８３（ＪＰ，Ａ）

【文献】 特開２０１３−１８６７３２（ＪＰ，Ａ）

【文献】 特開２００４−２８０３１８（ＪＰ，Ａ）

【文献】 米国特許第９９９０６２１（ＵＳ，Ｂ１）

【文献】 ”メッセージ感覚でお金を送れる。スマホアプリ 「pring」がキャッシュレス社会実現に果たす役割とは？”，[online]，株式会社ブラーブメディア，２０１８年 ３月 ９日，検索日:2020.8.5，ＵＲＬ，https://ampmedia.jp/2018/03/09/pring/

【文献】 鴨沢 浅葱，”割り勘の気まずさを解消、マネーツリーがiMessageアプリ「ワリカン」”，[online]，株式会社 日経BP，２０１６年 ９月１５日，検索日:2020.8.5，ＵＲＬ，https://xtech.nikkei.com/it/atcl/news/16/091502699/

【文献】 ”スマホ＆タブレットを使い倒す！ 便利アプリ活用法”，日経ＰＣ２１，日本，日経ＢＰ社，２０１７年 ２月２４日，第22巻第5号，p.118-121，ISSN:1341-9900

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｑ １０／００ − ９９／００

Ｇ１６Ｈ １０／００ − ８０／００

(57)【特許請求の範囲】

【請求項1】

複数人で代金を負担し合う支払方法における代表者の操作に基づいて、少なくとも参加者が代金を負担し合う支払イベントを作成する作成手段と、
前記支払イベントに前記参加者を登録する登録手段と、
前記支払イベントごとに、前記参加者から前記代表者への送金状況を取得する取得手段と、
前記支払イベントごとに、前記送金状況の管理画面を表示させる表示制御手段と、
を含み、
前記参加者は、利用登録したユーザ同士で送金可能なサービスを含む複数の送金方法のうちの何れかを利用して、前記代表者に送金し、
前記表示制御手段は、前記管理画面において、前記参加者が前記サービスのユーザであるか否かを識別可能に表示させる、
ことを特徴とする送金管理システム。

【請求項2】

複数人で代金を負担し合う支払方法における代表者の操作に基づいて、少なくとも参加者が代金を負担し合う支払イベントを作成する作成手段と、
複数の候補者の中から前記参加者を選択するための選択画面において、各候補者が、利用登録したユーザ同士で送金可能なサービスのユーザであるか否かを識別可能に表示させる表示制御手段と、
前記複数の候補者の中から、前記代表者により指定された候補者を前記参加者として前記支払イベントに登録する登録手段と、
を含むことを特徴とする送金管理システム。

【請求項3】

複数人で代金を負担し合う支払方法における代表者の操作に基づいて、少なくとも参加者が代金を負担し合う支払イベントを作成する作成手段と、
前記支払イベントに前記参加者を登録する登録手段と、
前記支払イベントごとに、前記参加者から前記代表者への送金状況を取得する取得手段と、
前記送金状況に基づいて、前記参加者から前記代表者への送金額の過不足が生じているか否かを判定する過不足判定手段と、
前記支払イベントごとに、前記送金状況の管理画面に、前記過不足判定手段の判定結果を表示させる表示制御手段と、
を含むことを特徴とする送金管理システム。

【請求項4】

複数人で代金を負担し合う支払方法における代表者の操作に基づいて、少なくとも参加者が代金を負担し合う支払イベントを作成する作成手段と、
前記支払イベントに前記参加者を登録する登録手段と、
前記作成手段により作成された支払イベントを複製し、新たな支払イベントを作成する複製手段と、
を含むことを特徴とする送金管理システム。

【請求項5】

複数人で代金を負担し合う支払方法における代表者の操作に基づいて、少なくとも参加者が代金を負担し合う支払イベントを作成する作成手段と、
前記支払イベントに前記参加者を登録する登録手段と、
前記支払イベントごとに、前記代表者による、前記参加者から前記代表者への送金の過不足に関する情報の入力を受け付ける入力受付手段と、
前記支払イベントごとに、管理画面に前記情報を表示させる表示制御手段と、
を含むことを特徴とする送金管理システム。

【請求項6】

前記支払イベントに対応する画面で所定の操作が行われた場合に、利用登録したユーザ同士で送金可能なメッセージアプリを利用する前記参加者に対し、前記メッセージアプリを利用して、前記支払イベントに関するメッセージを送信する送信手段、
を更に含むことを特徴とする請求項１〜５の何れかに記載の送金管理システム。

【請求項7】

コンピュータが、
複数人で代金を負担し合う支払方法における代表者の操作に基づいて、少なくとも参加者が代金を負担し合う支払イベントを作成する作成ステップと、
前記支払イベントに前記参加者を登録する登録ステップと、
前記支払イベントごとに、前記参加者から前記代表者への送金状況を取得する取得ステップと、
前記支払イベントごとに、前記送金状況の管理画面を表示させる表示制御ステップと、
を実行し、
前記参加者は、利用登録したユーザ同士で送金可能なサービスを含む複数の送金方法のうちの何れかを利用して、前記代表者に送金し、
前記表示制御ステップは、前記管理画面において、前記参加者が前記サービスのユーザであるか否かを識別可能に表示させる、
ことを特徴とする送金管理方法。

【請求項8】

コンピュータが、
複数人で代金を負担し合う支払方法における代表者の操作に基づいて、少なくとも参加者が代金を負担し合う支払イベントを作成する作成ステップと、
複数の候補者の中から前記参加者を選択するための選択画面において、各候補者が、利用登録したユーザ同士で送金可能なサービスのユーザであるか否かを識別可能に表示させる表示制御ステップと、
前記複数の候補者の中から、前記代表者により指定された候補者を前記参加者として前記支払イベントに登録する登録ステップと、
を実行することを特徴とする送金管理方法。

【請求項9】

コンピュータが、
複数人で代金を負担し合う支払方法における代表者の操作に基づいて、少なくとも参加者が代金を負担し合う支払イベントを作成する作成ステップと、
前記支払イベントに前記参加者を登録する登録ステップと、
前記支払イベントごとに、前記参加者から前記代表者への送金状況を取得する取得ステップと、
前記送金状況に基づいて、前記参加者から前記代表者への送金額の過不足が生じているか否かを判定する過不足判定ステップと、
前記支払イベントごとに、前記送金状況の管理画面に、前記過不足判定ステップの判定結果を表示させる表示制御ステップと、
を実行することを特徴とする送金管理方法。

【請求項10】

コンピュータが、
複数人で代金を負担し合う支払方法における代表者の操作に基づいて、少なくとも参加者が代金を負担し合う支払イベントを作成する作成ステップと、
前記支払イベントに前記参加者を登録する登録ステップと、
前記作成ステップにより作成された支払イベントを複製し、新たな支払イベントを作成する複製ステップと、
を実行することを特徴とする送金管理方法。

【請求項11】

コンピュータが、
複数人で代金を負担し合う支払方法における代表者の操作に基づいて、少なくとも参加者が代金を負担し合う支払イベントを作成する作成ステップと、
前記支払イベントに前記参加者を登録する登録ステップと、
前記支払イベントごとに、前記代表者による、前記参加者から前記代表者への送金の過不足に関する情報の入力を受け付ける入力受付ステップと、
前記支払イベントごとに、管理画面に前記情報を表示させる表示制御ステップと、
を実行することを特徴とする送金管理方法。

【請求項12】

前記コンピュータが、
前記支払イベントに対応する画面で所定の操作が行われた場合に、利用登録したユーザ同士で送金可能なメッセージアプリを利用する前記参加者に対し、前記メッセージアプリを利用して、前記支払イベントに関するメッセージを送信する送信ステップ、
を更に実行することを特徴とする請求項７〜１１の何れかに記載の送金管理方法。

【請求項13】

複数人で代金を負担し合う支払方法における代表者のコンピュータを、
前記代表者の操作に基づいて作成された、少なくとも参加者が代金を負担し合う支払イベントごとに、前記参加者から前記代表者への送金状況の管理画面を表示させる表示制御手段、
として機能させるためのプログラムであって、
前記参加者は、利用登録したユーザ同士で送金可能なサービスを含む複数の送金方法のうちの何れかを利用して、前記代表者に送金し、
前記表示制御手段は、前記管理画面において、前記参加者が前記サービスのユーザであるか否かを識別可能に表示させる、
プログラム。

【請求項14】

複数人で代金を負担し合う支払方法における代表者のコンピュータを、
前記代表者の操作に基づいて作成された、少なくとも参加者が代金を負担し合う支払イベントごとに、複数の候補者の中から前記参加者を選択するための選択画面において、各候補者が、利用登録したユーザ同士で送金可能なサービスのユーザであるか否かを識別可能に表示させる表示制御手段、
として機能させるためのプログラム。

【請求項15】

複数人で代金を負担し合う支払方法における代表者のコンピュータを、
前記代表者の操作に基づいて作成された、少なくとも参加者が代金を負担し合う支払イベントごとに、前記参加者から前記代表者への送金状況の管理画面に、前記参加者から前記代表者への送金額の過不足が生じているか否かの判定結果を表示させる表示制御手段、
として機能させるためのプログラム。

【請求項16】

複数人で代金を負担し合う支払方法における代表者のコンピュータを、
前記代表者の操作に基づいて作成された、少なくとも参加者が代金を負担し合う支払イベントを複製し、新たな支払イベントを作成する複製手段、
として機能させるためのプログラム。

【請求項17】

複数人で代金を負担し合う支払方法における代表者のコンピュータを、
前記代表者の操作に基づいて作成された、少なくとも参加者が代金を負担し合う支払イベントごとに、前記代表者による、前記参加者から前記代表者への送金の過不足に関する情報の入力を受け付ける入力受付手段、
前記支払イベントごとに、管理画面に前記情報を表示させる表示制御手段、
として機能させるためのプログラム。

【請求項18】

前記コンピュータを、
前記支払イベントに対応する画面で所定の操作が行われた場合に、利用登録したユーザ同士で送金可能なメッセージアプリを利用する前記参加者に対し、前記メッセージアプリを利用して、前記支払イベントに関するメッセージを送信する送信手段、
として更に機能させるための請求項１３〜１７の何れかに記載のプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、送金管理システム、送金管理方法、及びプログラムに関する。

【背景技術】

【0002】

従来、複数人で代金を負担し合う支払方法（例えば、割り勘）が知られている。例えば、特許文献１には、電子マネーを利用する複数の利用者から構成されるグループが店舗で買い物をするときに、何れかの利用者が金額を入力すると、グループ内の他の利用者の人数に応じて均等割りした金額を計算するシステムが記載されている。このシステムでは、グループ内の他の利用者の全員が割り勘の承認をした場合に、均等割りされた金額を各自の電子マネーから引くことで、電子マネーを利用した割り勘によって商品が購入される。

【先行技術文献】

【特許文献】

【0003】

【特許文献1】特開第２０１３−２５４２７９号公報

【発明の概要】

【発明が解決しようとする課題】

【0004】

しかしながら、特許文献１の技術では、他の利用者の全員が割り勘の承認をする必要があり、全員の承認を得られるまでは、決済をすることができず、商品を購入することもできない。この点、グループ内の何れかの利用者が代表して決済し、他の利用者に、立て替え分を送金させることも考えられるが、各自の送金状況を把握するのは非常に手間がかかる。

【0005】

本発明の目的は、複数人で代金を負担し合う支払方法において、参加者から代表者への送金状況を容易に管理することが可能な送金管理システム、送金管理方法、及びプログラムを提供することである。

【課題を解決するための手段】

【0006】

上記課題を解決するために、本発明に係る送金管理システムは、複数人で代金を負担し合う支払方法における代表者の操作に基づいて、少なくとも参加者が代金を負担し合う支払イベントを作成する作成手段と、前記支払イベントに前記参加者を登録する登録手段と、前記支払イベントごとに、前記参加者から前記代表者への送金状況を取得する取得手段と、前記支払イベントごとに、前記送金状況の管理画面を表示させる表示制御手段と、を含むことを特徴とする。

【図面の簡単な説明】

【0007】

【図1】実施形態に係る送金管理システムの一例を示す図である。

【図2】代表者端末に表示される画面の一例を示す図である。

【図3】代表者端末に表示される画面の一例を示す図である。

【図4】代表者端末に表示される画面の一例を示す図である。

【図5】参加者端末に表示される詳細画面の一例を示す図である。

【図6】代表者端末に表示される画面を示す図である。

【図7】代表者端末に表示される画面を示す図である。

【図8】本実施形態において実現される機能を示す機能ブロック図である。

【図9】ユーザデータベースのデータ格納例を示す図である。

【図10】割勘データベースのデータ格納例を示す図である。

【図11】本実施形態において実行される処理のフロー図である。

【発明を実施するための形態】

【0008】

［１．送金管理システムの全体構成］
以下、本発明に係る実施形態の例について図面に基づき詳細に説明する。図１は、実施形態に係る送金管理システムの一例を示す図である。図１に示すように、例えば、送金管理システム１は、銀行サーバ１０、メッセージサーバ２０、代表者端末３０、及び参加者端末４０を含み、これらは、インターネットなどのネットワークＮに接続可能である。なお、図１では、銀行サーバ１０、メッセージサーバ２０、代表者端末３０、及び参加者端末４０の各々を１台ずつ示しているが、これらは複数台あってもよい。

【0009】

銀行サーバ１０は、銀行が管理するサーバコンピュータであり、例えば、制御部１１、記憶部１２、及び通信部１３を含む。なお、本実施形態で単に「銀行」と記載した場合、特に明記した場合を除いて、銀行サーバ１０を管理する銀行を指すものとする。例えば、銀行は、オンラインバンキング等の種々の金融サービスを利用するためのアプリケーション（以降、銀行アプリと記載する。）を口座開設者に提供する。

【0010】

制御部１１は、例えば、少なくとも１つのマイクロプロセッサを含む。記憶部１２は、例えば、ＲＡＭ等の主記憶部やハードディスク等の補助記憶部を含む。制御部１１は、記憶部１２に記憶されたプログラムやデータに従って処理を実行する。通信部１３は、有線通信又は無線通信用の通信インタフェースを含む。通信部１３は、インターネットやＬＡＮなどのネットワークを介して外部機器とのデータ送受信が可能である。

【0011】

メッセージサーバ２０は、メッセージアプリの提供会社が管理するサーバコンピュータであり、例えば、制御部２１、記憶部２２、及び通信部２３を含む。制御部２１、記憶部２２、及び通信部２３のハードウェア構成は、それぞれ制御部１１、記憶部１２、及び通信部１３と同様であってよい。

【0012】

メッセージアプリは、ユーザ間でメッセージを送信するためのアプリケーションであり、ユーザ間のコミュニケーションツールである。メッセージアプリは、チャットアプリとも呼ばれる。メッセージアプリをダウンロードして利用登録したユーザは、他のユーザを友人として連絡先に追加し、メッセージを送信する。メッセージは、テキスト、絵文字、画像、又はスタンプといった種々の媒体を利用可能である。

【0013】

本実施形態では、メッセージアプリを利用してユーザ間で送金するサービス（以降、単にアプリ送金と記載する。）が提供される。例えば、メッセージアプリのユーザが、メッセージアプリと銀行口座又は銀行アプリを連携させると、当該銀行口座の残高を利用して他のユーザに送金することができる。また例えば、ユーザが他のユーザからの送金を受けた場合に、上記銀行口座を利用して他のユーザからの送金を受け取ることができる。

【0014】

なお、送金サービスは、メッセージアプリを利用したタイプや銀行口座と連携するタイプに限られず、種々のタイプのサービスを適用可能である。例えば、ユーザのアカウントに関連付けられた残高をチャージしたうえで送金するタイプであってもよい。このタイプの場合、ユーザは、クレジットカードや銀行振込等を利用して自身のアカウントの残高にチャージしたうえで他のユーザに送金する。他にも例えば、ユーザのアカウントと電子バリュー（例えば、電子マネー又はポイント）を関連付けておき、当該電子バリューを利用して送金するタイプであってもよい。このタイプの場合、ユーザは、自身のアカウントに関連付けられた電子バリューにチャージしたうえで他のユーザに送金する。送金サービスは、ユーザ間の送金以外にも、商品の購入や公共料金の支払い等の種々の目的で利用可能である。

【0015】

代表者端末３０は、複数人で代金を負担しあう支払方法における代表者が操作するコンピュータであり、例えば、パーソナルコンピュータ、携帯電話（スマートフォンを含む）、又は携帯情報端末（タブレット型端末を含む）である。

【0016】

本実施形態では、上記支払方法を割勘と記載するが、折半、頭割り、又は相持ち等の他の名称で呼ばれてもよい。割勘は、全員が均等割りで支払う場合と、均等割りでなく各自に応じた負担金が設定される場合（自分と他人の負担額が異なる場合）と、の両方を含む意味である。割勘における支払対象は、任意の対象であってよく、例えば、商品、飲食物、チケット、又はサービス等が購入される。

【0017】

代表者は、割勘において代表して支払いを行う者である。例えば、代表者は、代金を立て替えて支払いをした後に参加者から集金したり、参加者から予め集金したうえで代金を支払ったりする。参加者は、割勘に参加する者であり、代表者に自身の負担金を支払う者である。代表者は、参加者の一員となることもあるし、参加者の一員とはならないこともある。代表者が参加者の一員にならない場合には、代表者は代金を支払うだけであり、代表者の実質的な負担金は発生しない。

【0018】

代表者端末３０は、制御部３１、記憶部３２、通信部３３、操作部３４、及び表示部３５を含む。制御部３１、記憶部３２、及び通信部３３のハードウェア構成は、それぞれ制御部１１、記憶部１２、及び通信部１３と同様であってよい。操作部３４は、入力デバイスであり、例えば、タッチパネルやマウスなどのポインティングデバイス又はキーボードである。表示部３５は、例えば、液晶ディスプレイ又は有機ＥＬディスプレイである。

【0019】

参加者端末４０は、参加者が操作するコンピュータであり、例えば、パーソナルコンピュータ、携帯電話（スマートフォンを含む）、又は携帯情報端末（タブレット型端末を含む）である。参加者端末４０は、制御部４１、記憶部４２、通信部４３、操作部４４、及び表示部４５を含む。制御部４１、記憶部４２、通信部４３、操作部４４、及び表示部４５のハードウェア構成は、それぞれ制御部１１、記憶部１２、通信部１３、操作部３４、及び表示部３５と同様であってよい。

【0020】

なお、記憶部１２，２２，３２，４２に記憶されるものとして説明するプログラムやデータは、コンピュータ読み取り可能な情報記憶媒体（例えば、ＵＳＢメモリ又はＳＤカード）に記憶されたものが各コンピュータに供給されるようにしてもよいし、ネットワークを介して各コンピュータに供給されるようにしてもよい。また、上記説明した各コンピュータのハードウェア構成は、上記の例に限られず、例えば、情報記憶媒体を読み取る読取部（例えば、ＳＤカードスロット）、又は、外部機器と直接的に通信するための入出力部（例えば、ＵＳＢ端子）が備えられていてもよい。

【0021】

［２．送金管理システムの概要］
送金管理システム１では、割勘の参加者から代表者への送金を支援するサービス（以降、割勘サービスと記載する。）が提供される。本実施形態では、代表者が代金を立て替えて支払いをした後に、参加者から各自の負担金を回収する場合の処理を一例として説明する。代表者と参加者は、店舗等で一緒に商品等を購入してもよいが、本実施形態では、代表者が支払いをする時点では、参加者は離れた場所にいるものとする。また、本実施形態では、銀行が割勘サービスを提供する場合を説明するが、割勘サービスは、任意の者が提供すればよく、例えば、メッセージアプリの提供会社、通信事業者、電子マネーの取扱会社、又はＳＮＳの提供会社が割勘サービスの提供者となってもよい。

【0022】

本実施形態では、代表者は、銀行口座の開設、銀行アプリの利用登録、メッセージアプリの利用登録、及びアプリ送金の連携を全て済ませているものとする。代表者が代表者端末３０を操作して銀行アプリの割勘サービス機能を起動すると、割勘サービスのトップ画面が表示部３５に表示される。なお、以降説明する画面は、銀行アプリ上の画面として表示されてもよいし、ブラウザ上で表示されてもよい。

【0023】

図２−図４は、代表者端末３０に表示される画面の一例を示す図である。図２に示すように、トップ画面Ｇ１には、アプリ送金との連携の有無等の情報とともに、割勘イベントを作成するためのボタンＢ１０と、作成済みの割勘イベントを管理するためのボタンＢ１１と、が表示される。割勘イベントは、個々の割勘の単位である。なお、アプリ送金との連携を済ませていなければ、トップ画面Ｇ１から連携のための操作を可能としてもよい。代表者がボタンＢ１０を選択すると、割勘イベントを作成するためのイベント作成画面Ｇ２が表示部３５に表示される。

【0024】

イベント作成画面Ｇ２には、イベント名を入力するための入力フォームＦ２０、合計金額を入力するための入力フォームＦ２１、参加者宛てのメッセージを入力するための入力フォームＦ２２、及び次の画面に遷移するためのボタンＢ２３が表示される。合計金額は、代表者が代表して支払う金額である。合計金額は、上限値と下限値が設定されていてもよい。代表者が、入力フォームＦ２０〜Ｆ２２に、イベント名、合計金額、及びメッセージを入力してボタンＢ２３を選択すると、参加者を登録するための参加者登録画面Ｇ３が表示部３５に表示される。

【0025】

参加者登録画面Ｇ３には、割勘の参加人数を入力するための入力フォームＦ３０、参加人数を増減させるためのボタンＢ３１、代表者を参加者に含めるか否かを入力するためのチェックボックスＢ３２、参加者の名前に敬称を付けるか否かを入力するためのチェックボックスＢ３３、メッセージアプリの連絡先から参加者を追加するためのボタンＢ３４、参加者を入力するための入力フォームＦ３５、参加人数を追加するためのボタンＢ３６、及び次の画面に遷移するためのボタンＢ３７が表示される。連絡先は、メッセージアプリにおける友人の一覧である。なお、代表者がメッセージアプリを利用していない場合には、ボタンＢ３４は表示されない。

【0026】

代表者は、参加人数を示す数値を入力フォームＦ３０に入力したり、ボタンＢ３１を選択したりすることによって、参加人数を入力する。参加人数は、上限値と下限値が設定されていてもよい。代表者が入力した参加人数は、入力フォームＦ３５の数に反映される。代表者がチェックボックスＢ３２にチェックを入れると、自身を参加者の一員として含めることができ、自身の名前が入力フォームＦ３５の何れかに表示される。代表者の氏名は、直接入力されてもよいし、自身の銀行口座の口座名義人又はメッセージアプリのアカウント名等から取得されてもよい。代表者がチェックボックスＢ３３にチェックを入れると、入力フォームＦ３５の後に敬称が表示される。代表者がボタンＢ３４を選択すると、メッセージアプリの連絡先から参加者を登録するための連絡先選択画面Ｇ４が表示部３５に表示される。なお、連絡先は、代表者端末３０内のメッセージアプリから読み出されてもよいし、メッセージサーバ２０から取得されてもよい。

【0027】

連絡先選択画面Ｇ４には、連絡先に登録された友人名の一覧等とともに、友人を検索するためのボタンＢ４０、友人を参加者として選択するためのボタンＢ４１、友人のアイコンＩ４２、及び選択した友人を参加者として登録するためのボタンＢ４３が表示される。代表者がボタンＢ４０を選択して文字列等の任意の検索条件を入力すると、検索条件にヒットする友人が連絡先選択画面Ｇ４に表示される。

【0028】

本実施形態では、アプリ送金の利用登録の有無と、銀行口座又は銀行アプリとの連携の有無と、がアイコンＩ４２の色によって識別可能となっている。例えば、アプリ送金に利用登録済みの友人（図２の例では「佐藤次郎」）のアイコンＩ４２は、第１の色（例えば、紫）で表示される。また例えば、連携も済ませている友人（図２の例では「山田太郎」、「鈴木花子」）のアイコンＩ４２は、第１の色及び第２の色（例えば、オレンジ）で表示される。また例えば、アプリ送金に利用登録をしていない友人（図２の例では「上本大介」）のアイコンＩ４２は、第３の色（例えば、灰色）で表示される。なお、図２のアイコンＩ４２は、網点の濃淡によって模式的に色を表現している。

【0029】

代表者は、割勘の合計人数を上回らない範囲で、参加者にしたい友人のボタンＢ４１を、選択する。その後、代表者がボタンＢ４３を選択すると、図３に移り、参加者登録画面Ｇ３に示すように、代表者が選択した友人が参加者として登録され、友人の名前が入力フォームＦ３５に表示される。メッセージアプリから引用された名前は、入力フォームＦ３５から変更できるようにしてもよい。連絡先に登録していない者やメッセージアプリを利用していない者を参加者に含める場合には、代表者は、入力フォームＦ３５に、参加者の名前を直接入力する。代表者がボタンＢ３６を選択すると、参加人数が増加して入力フォームＦ３５が増える。代表者がボタンＢ３７を選択すると、参加者の負担金を入力するための金額入力画面Ｇ５が表示部３５に表示される。

【0030】

金額入力画面Ｇ５には、合計金額と平均額が表示領域Ａ５０に表示され、負担金の調整単位を指定するためのボタンＢ５１、負担金を入力するための入力フォームＦ５２、負担金を調整するためのボタンＢ５３、次の画面に進むためのボタンＢ５４、及び金額をリセットするためのボタンＢ５５が表示される。平均額は、合計金額を参加者の人数で割った値である。なお、合計金額と、入力フォームＦ５２に入力された金額の総計と、に差が生じている場合には、差額が表示されてもよい。

【0031】

代表者は、ボタンＢ５１を選択して、ボタンＢ５３を選択した場合の調整金額の単位を指定する。代表者は、入力フォームＦ５２に負担金を示す数値を直接入力してもよいし、ボタンＢ５３を選択して負担金を調整してもよい。負担金は、上限値と下限値が設定されていてもよい。代表者がボタンＢ５４を選択すると、割勘イベントの内容を確認するための確認画面Ｇ６が表示される。なお、代表者がボタンＢ５５を選択すると、入力フォームＦ５２に入力された各参加者の負担金がリセットされる。

【0032】

確認画面Ｇ６には、割勘イベントのイベント名等の情報とともに、アプリ送金と連携している参加者であることを示すアイコンＩ６０と、割勘イベントを確定させるためのボタンＢ６１と、が表示される。なお、確認画面Ｇ６における参加者名は、特にソートされなくてもよいし、負担金等の条件に基づいてソートされてもよい。また、アプリ送金と連携していない参加者については、アイコンＩ６０は表示されない。代表者がボタンＢ６１を選択すると、割勘イベントが作成され、割勘イベントの作成が完了したことを示す完了画面Ｇ７が表示される。

【0033】

完了画面Ｇ７には、割勘イベントの作成が完了したことを示すメッセージ及びイベント名とともに、後述する送信画面に遷移するためのボタンＢ７０、後述するイベント一覧画面又は管理画面に遷移するためのボタンＢ７１、及びトップ画面Ｇ１に戻るためのボタンＢ７２が表示される。代表者がボタンＢ７０を選択すると、図４に移り、割勘イベントに関するメッセージを送信するための送信画面Ｇ８が表示部３５に表示される。

【0034】

本実施形態では、代表者は、メッセージアプリ又は外部ツールを利用してメッセージを送信することができる。外部ツールは、メッセージアプリ以外のメッセージの送信媒体であり、例えば、電子メール、ＳＮＳ、メッセンジャー、又はショートメッセージサービスである。図４に示すように、送信画面Ｇ８には、割勘イベントのイベント名等の情報とともに、メッセージアプリを利用してメッセージを送信するためのボタンＢ８０、外部ツールを利用してメッセージを送信するためのボタンＢ８１、及びトップ画面Ｇ１に戻るためのボタンＢ８２が表示される。

【0035】

代表者がボタンＢ８０を選択すると、メッセージアプリを利用する参加者に対し、メッセージが送信される。メッセージは、自動的に送信されてもよいし、メッセージアプリが起動した後に代表者が所定の送信操作をすることで送信されてもよい。メッセージが送信されると、代表者のメッセージアプリの画面であるメッセージアプリ画面Ｇ９には、参加者に送信されたメッセージが表示される。メッセージアプリ画面Ｇ９に示すように、例えば、メッセージには、イベント名等の情報とともに、割勘イベントの詳細を表示させるためのボタンＢ９０が表示される。同様のメッセージは、参加者のメッセージアプリ画面Ｇ９にも表示される。

【0036】

一方、送信画面Ｇ８から代表者がボタンＢ８１を選択すると、外部ツールが起動し、外部ツールを利用してメッセージを送信するための外部ツール画面Ｇ１０が表示部３５に表示される。ここでは、外部ツールの一例として電子メールを説明する。メッセージには、イベント名等の情報とともに、割勘イベントの詳細を表示させるためのリンクＬ１００が含まれている。代表者は、外部ツール画面Ｇ１０から参加者のメールアドレスを入力してメッセージを送信する。

【0037】

参加者は、代表者からのメッセージを受信すると、メッセージ内のボタンＢ９０やリンクＬ１００を選択して割勘イベントの詳細を確認する。参加者が参加者端末４０を操作してボタンＢ９０又はリンクＬ１００を選択すると、割勘イベントの詳細を示す詳細画面が表示部４５に表示される。

【0038】

図５は、参加者端末４０に表示される詳細画面の一例を示す図である。図５に示すように、詳細画面Ｇ１１には、イベント名等の割勘イベントの詳細が表示される。参加者がアプリ送金を利用している場合、図５の左側の詳細画面Ｇ１１に示すように、アプリ送金を利用して送金するためのボタンＢ１１０，Ｂ１１１と、詳細画面Ｇ１１を閉じるためのボタンＢ１１２と、が表示される。参加者がボタンＢ１１０，Ｂ１１１を選択すると、アプリ送金を利用して代表者に送金することができる。例えば、参加者がボタンＢ１１０，Ｂ１１１を選択すると、送金金額の入力画面が表示されて、参加者が入力した金額が代表者に送金される。

【0039】

一方、参加者がアプリ送金を利用していない場合、図５の右側の詳細画面Ｇ１１に示すように、アプリ送金の利用登録をするためのボタンＢ１１３、自身の銀行口座から送金するためのボタンＢ１１４、及び銀行口座を開設するためのボタンＢ１１５が表示される。参加者が銀行口座を開設済みであり、かつ、メッセージアプリの利用登録をしていれば、ボタンＢ１１３を選択することでアプリ送金に利用登録することができる。参加者は、銀行口座を開設済みであれば、ボタンＢ１１４を選択することで、オンラインバンキングサービスを利用して代表者の受取口座に送金できる。参加者は、銀行口座を未開設であれば、ボタンＢ１１５を選択することで、銀行口座を開設することができる。

【0040】

なお、参加者は、他の方法を利用して代表者に送金してもよい。例えば、参加者は、割勘サービスを提供する銀行以外の銀行口座から代表者の受取口座に送金してもよいし、電子バリューを利用して送金してもよい。他にも例えば、電子的な送金に限られず、参加者は、現金書留を利用して代表者に送金してもよいし、代表者に負担金を直接手渡ししてもよい。

【0041】

本実施形態では、各参加者の送金状況を代表者が容易に管理できるような画面が用意されている。例えば、代表者がトップ画面Ｇ１のボタンＢ１１又は完了画面Ｇ７のボタンＢ７１を選択すると、自身が作成した割勘イベントの一覧を示すイベント一覧画面が表示部３５に表示される。

【0042】

図６−図７は、代表者端末３０に表示される画面を示す図である。図６に示すように、イベント一覧画面Ｇ１２には、代表者が作成した割勘イベントを示すリストＬ１２０が表示される。リストＬ１２０には、イベント名及び割勘イベントの作成日とともに、割勘イベント全体のステータスが表示される。ここでは、割勘イベント全体のステータスとして、送金が完了していない参加者がいることを示す「未精算」と、全ての参加者の送金が完了したことを示す「完了」と、の２つのステータスが用意されている。代表者がリストＬ１２０の中の割勘イベントを選択すると、当該選択された割勘イベントの管理画面Ｇ１３が表示部３５に表示される。

【0043】

図６に示すように、管理画面Ｇ１３には、代表者が選択した割勘イベントのイベント名等の情報とともに、割勘イベント全体のステータスを示すアイコンＩ１３０、各参加者のアプリ送金の利用登録の有無を示すアイコンＩ１３１、各参加者の送金状況を示すボタンＢ１３２、メッセージアプリを利用してメッセージを送信するためのボタンＢ１３３、外部ツールを利用してメッセージを送信するためのボタンＢ１３４、受取口座への入金の履歴を確認するためのボタンＢ１３５、割勘イベントを複製して新たな割勘イベントを作成するためのボタンＢ１３６、及び割勘イベントを削除するためのボタンＢ１３７が表示される。アプリ送金を利用していない参加者については、アイコンＩ１３１は表示されない。

【0044】

ボタンＢ１３２には、参加者の個別のステータスが表示される。ここでは、送金が行われていないことを示す「未済」、送金額が不足していることを示す「不足」、送金額が過剰であることを示す「過剰」、及び送金が完了したことを示す「完了」の４つのステータスが用意されている。図６の画面例は、まだ誰も代表者に送金をしていない場合を示しており、全てのボタンＢ１３２は「未済」となっている。

【0045】

本実施形態では、銀行サーバ１０は、メッセージサーバ２０と連携しており、アプリ送金であれば、参加者から代表者への送金を検知できる。図６の画面例であれば、「山田太郎」、「佐藤次郎」、及び「鈴木花子」の３人は、アプリ送金に利用登録済みなので、アプリ送金を利用して代表者に送金すれば、銀行サーバ１０は送金を検知できる。参加者がアプリ送金を利用して送金した場合に、参加者の送金額に基づいて、「不足」、「過剰」、又は「完了」の何れのステータスに属するかが自動的に判定されて、ボタンＢ１３２の表示に反映され、その付近にアプリ送金の送金額が表示される。

【0046】

例えば、図７の左側の管理画面Ｇ１３に示すように、「山田太郎」がアプリ送金を利用して送金したが、送金額が不足している場合には、ボタンＢ１３２が示すステータスは「不足」となる。また例えば、「佐藤次郎」がアプリ送金を利用して負担額を送金した場合には、ボタンＢ１３２が示すステータスは「完了」となる。また例えば、「鈴木花子」がアプリ送金を利用して送金したが、送金額が過剰であった場合には、ボタンＢ１３２が示すステータスは「過剰」となる。図７に示すように、参加者の負担額と、実際の送金額と、は互いに対比可能に表示され、「不足」又は「過剰」であった場合には、どの程度差額が生じているかを把握しやすくなっている。

【0047】

一方、参加者が他の送金方法で送金した場合、本実施形態では、銀行サーバ１０は送金を検知できないので、代表者は、ボタンＢ１３２を選択して、手動でステータスを変化させる。例えば、代表者は、自身の銀行口座に対する入金履歴を確認したり、電子バリューによる送金履歴を確認したりして、「不足」、「過剰」、又は「完了」の何れのステータスに属するかを自分で判定し、ボタンＢ１３２を押してステータスを変化させる。なお、アプリ送金によって自動的に「完了」になったボタンＢ１３２については、代表者がボタンＢ１３２を押してもステータスが変化しないようにロックされる。これとは逆に、代表者がボタンＢ１３２を押して手動でステータスを変化させた後に、アプリ送金が行われた場合には、自動的にステータスが上書きされる。

【0048】

例えば、図７の右側の管理画面Ｇ１３に示すように、全ての参加者のボタンＢ１３２が示すステータスが「完了」になった場合、アイコンＩ１３０が示す割勘イベント全体のステータスは「完了」となる。なお、この場合、割勘イベントが完了して参加者にメッセージを送信する必要がなくなるので、ボタンＢ１３３，Ｂ１３４がグレーアウトして選択できないようにしてもよい。また、全体ステータスが「完了」になった後に、代表者がボタンＢ１３２を選択してステータスを「不足」等に変更した場合には、全体ステータスは「未精算」に戻る。

【0049】

以上のように、本実施形態の送金管理システム１は、主に、各参加者の送金状況を管理画面Ｇ１３に表示させ、参加者から代表者への送金状況を容易に管理する構成を有している。以降、送金管理システム１の構成の詳細について説明する。

【0050】

［３．本実施形態において実現される機能］
図８は、本実施形態において実現される機能を示す機能ブロック図である。ここでは、銀行サーバ１０において主な機能が実現される場合を説明する。図８に示すように、銀行サーバ１０では、データ記憶部１００、登録部１０１、作成部１０２、送信部１０３、要求受付部１０４、実行部１０５、入力受付部１０６、取得部１０７、制限部１０８、過不足判定部１０９、完了判定部１１０、表示制御部１１１、及び複製部１１２が実現される。データ記憶部１００は記憶部１２を主として実現され、他の各機能は制御部１１を主として実現される。

【0051】

［データ記憶部］
データ記憶部１００は、割勘サービスを実現するために必要なデータを記憶する。ここでは、データ記憶部１００が記憶するデータの一例として、ユーザデータベースＤＢ１と、割勘データベースＤＢ２と、を説明する。

【0052】

図９は、ユーザデータベースＤＢ１のデータ格納例を示す図である。図９に示すように、ユーザデータベースＤＢ１は、銀行アプリのユーザに関する情報が格納されるデータベースである。例えば、ユーザデータベースＤＢ１には、ユーザを一意に識別するユーザＩＤ、ユーザの銀行口座の口座情報、アプリ送金との連携の有無を示す連携有無情報、及びメッセージアプリのアカウントが格納される。

【0053】

本実施形態では、代表者は、銀行アプリに利用登録済みなので、ユーザＩＤを保有している。参加者は、銀行アプリに利用登録済みであればユーザＩＤを保有しているが、他行の銀行口座を利用しており銀行アプリに利用登録をしていなければユーザＩＤを保有していない。口座情報は、銀行口座を識別するための情報であればよく、例えば、支店名、口座番号、及び口座名義人である。

【0054】

連携有無情報は、アプリ送金と連携していることを示す第１の値、又は、アプリ送金と連携していないことを示す第２の値の何れかをとる。銀行アプリとメッセージアプリの両方を使用するユーザが、銀行アプリ又はメッセージアプリ上から連携させるための所定の操作を行うと、連携有無情報は第１の値から第２の値に変化し、メッセージアプリのアカウントが格納される。メッセージアプリのアカウントは、代表者端末３０又は参加者端末４０から取得されてもよいし、メッセージサーバ２０から取得されてもよい。

【0055】

図１０は、割勘データベースＤＢ２のデータ格納例を示す図である。図１０に示すように、割勘データベースＤＢ２は、割勘イベントに関する情報が格納されるデータベースである。例えば、割勘データベースＤＢ２には、割勘イベントを一意に識別するイベントＩＤ、代表者のユーザＩＤ、イベント名、割勘イベントの全体ステータス、代表者が入力したメッセージ、作成日、合計金額、参加者の人数、参加者名、負担金、メッセージアプリのアカウント、アプリ送金との連携の有無を示す情報、参加者の個別ステータス、及び代表者の銀行口座（送金の受取口座）が格納される。

【0056】

代表者が割勘イベントを作成すると、割勘データベースＤＢ２に新たなレコードが作成される。代表者が作成した割勘イベントを示すイベントＩＤが発行され、当該作成されたレコードに格納される。イベントＩＤは、所定のＩＤ発行ルールに基づいて発行されるようにすればよく、他の割勘イベントと重複しないようにして発行されるようにすればよい。そして、イベント作成画面Ｇ２から入力されたイベント名、合計金額、及びメッセージと、参加者登録画面Ｇ３から入力された参加者名と、金額入力画面Ｇ５から入力された負担金と、が上記作成されたレコードに格納される。

【0057】

全体ステータスの初期値は「未精算」となり、個別ステータスの初期値は「未済」となる。作成日には、割勘イベントが作成された日付が格納され、連絡先選択画面Ｇ４から登録した参加者については、メッセージアプリのアカウントと、連携有無情報と、が格納される。メッセージアプリのアカウントは、代表者端末３０から取得されてもよいし、メッセージサーバ２０に問い合わせたうえで取得されてもよい。連携有無情報は、ユーザデータベースＤＢ１が参照されることによって取得される。

【0058】

なお、データ記憶部１００が記憶するデータは、上記の例に限られない。例えば、データ記憶部１００は、銀行口座に関する情報が格納される口座データベースを記憶してもよい。口座データベースには、銀行の支店名、口座を識別する口座番号、口座名義人、残高情報、暗証番号、及び入出金明細情報が格納される。暗証番号は、口座の暗証番号であり、口座開設時等に指定された暗証番号である。入出金明細情報は、口座の入出金の履歴を示す情報であり、例えば、日付、入出金額、及び入出金者といった情報が格納される。割勘イベントは、代表者の入出金明細を利用して作成されてもよく、割勘の合計金額は代表者の入金額が流用されてもよい。

【0059】

［登録部］
登録部１０１は、支払イベントに参加者を登録する。登録とは、参加者に関する情報をイベントＩＤに関連付けて割勘データベースＤＢ２に登録することである。本実施形態では、代表者が支払イベントを作成するときに参加者を指定するので、登録部は、支払イベントが作成される場合に、代表者により指定された者を参加者として登録する。本実施形態では、銀行サーバ１０によって登録部１０１が実現されるので、登録部１０１は、代表者端末３０から、代表者が指定した参加者を識別する参加者識別情報を受信することによって、参加者の指定を受け付けて登録する。参加者識別情報は、参加者を識別可能な情報であればよく、例えば、参加者の名前、銀行アプリのユーザＩＤ、メッセージアプリのアカウント、又は電子メールアドレスといった情報である。

【0060】

登録部１０１は、少なくとも１人の参加者を登録する。参加者の人数は、任意であってよく、２名であってもよいし、３名以上であってもよい。なお、代表者は、参加者を１名だけ指定してもよく、この場合、当該指定された１名の参加者と代表者を含む合計２名の参加者による割勘が行われる。

【0061】

本実施形態では、メッセージアプリの連絡先の中から参加者を選択可能なので、連絡先に登録された友人は、割勘の候補者ということができる。登録部１０１は、複数の候補者の中から、代表者により指定された候補者を参加者として登録する。代表者端末３０には、候補者の一覧が表示され、代表者は、その中から参加者を指定する。登録部１０１は、代表者端末３０から、複数の候補者の中から代表者が参加者として選択した候補者を識別する情報を受信する。

【0062】

なお、候補者は、メッセージアプリの連絡先に登録された友人に限られない。候補者は、予め定められた者であればよく、代表者と何かしらのつながりがある者であればよい。例えば、候補者は、代表者端末３０又はクラウドサーバ等に記憶された代表者のアドレス帳に登録された者であってもよい。また例えば、銀行アプリにおいて、送金したことのある他のユーザやメッセージを送ったことのある他のユーザを登録可能とする場合には、候補者は、銀行アプリで登録された他のユーザであってもよい。また例えば、ＳＮＳと連携する場合には、候補者は、ＳＮＳでつながりのある他のユーザであってもよい。

【0063】

また、本実施形態では、代表者が参加者を指定する場合を説明するが、代表者ではない者が自分から参加者になることを申請してもよい。例えば、代表者端末３０に支払イベントのイベントＩＤを含む二次元コードを表示させ、参加者端末４０で読み取った場合に、参加者端末４０を操作する者に関する情報（例えば、氏名など）が銀行サーバ１０に送信され、参加者として登録されてもよい。この場合、参加者端末４０を操作する者がメッセージアプリを利用していれば、メッセージアプリのアカウントなどの情報も一緒に銀行サーバ１０に送信されて登録されてもよい。二次元コードを利用する以外にも、代表者から電子メールやメッセージアプリでのメッセージを受信した者が、メッセージ内のリンクを選択した場合に参加者として登録されてもよいし、割勘イベントを示すウェブサイトを作成し、当該ウェブサイトから参加者として参加する旨の操作が行われた場合に参加者として登録されてもよい。

【0064】

［作成部］
作成部１０２は、複数人で代金を負担し合う支払方法における代表者の操作に基づいて、少なくとも参加者が代金を負担し合う割勘イベントを作成する。割勘イベントを作成するとは、データ記憶部１００上に割勘イベントに関するデータを登録することであり、例えば、割勘データベースＤＢ２に新たなレコードを作成すること、割勘イベントのイベントＩＤを発行すること、又は代表者が入力したイベント名等の情報を割勘データベースＤＢ２に登録することである。割勘イベントは、支払イベントの一例であり、支払方法に応じた名前で呼ばれるようにすればよい。

【0065】

本実施形態では、代表者端末３０は、確認画面Ｇ６のボタンＢ６１が選択されると、銀行サーバ１０に対し、割勘イベントの作成要求を送信する。作成要求は、割勘イベントを作成する旨を示す識別子を含む所定形式のデータが送信されることによって行われるようにすればよく、例えば、代表者が入力したイベント名等の各種情報（割勘データベースＤＢ２のレコードに格納される情報）を含む。作成部１０２は、作成要求を受信すると、割勘イベントを作成し、作成要求とともに受信した情報を格納する。

【0066】

［送信部］
送信部１０３は、割勘イベントに関するメッセージを参加者に送信するための画像が選択された場合に、メッセージを参加者に送信する。当該画像は、任意の画像であってよく、本実施形態では、送信画面Ｇ８のボタンＢ８０，Ｂ８１、又は、管理画面Ｇ１３のボタンＢ１３３，Ｂ１３４である。送信部１０３は、これらのボタンが選択されたことに応じてメッセージを送信してもよいし、その後に表示される画面における代表者の操作に応じてメッセージを送信してもよい。その後に表示される画面は、例えば、メッセージアプリ画面Ｇ９又は外部ツール画面Ｇ１０等であり、当該画面でメッセージを編集可能としてもよい。

【0067】

例えば、銀行アプリがメッセージの送信機能を有する場合には、送信部１０３は、銀行アプリのメッセージ送信機能を利用して、参加者にメッセージを送信してもよい。また例えば、送信部１０３は、メッセージサーバ２０、電子メールサーバ、又はソーシャルネットワークサーバ等に対し、メッセージの送信を依頼することで、参加者にメッセージを送信してもよい。メッセージの内容は、図４を参照して説明した通りである。

【0068】

［要求受付部］
本実施形態では、代表者と少なくとも１人の参加者は、利用登録したユーザ同士で送金可能なサービスのユーザであり、要求受付部１０４は、参加者によるサービスを利用した送金要求を、割勘イベントの識別情報とともに受け付ける。本実施形態では、当該サービスの一例として、アプリ送金を説明するが、電子的な送金を可能とするサービスであればよく、他の任意のサービスを適用可能である。例えば、メールアドレスと銀行口座を関連付けておき、メールアドレスを指定することで銀行口座が特定されて送金が実行されるサービスであってもよい。また例えば、ＳＮＳのアカウントと銀行口座を連携させて送金が実行されるサービスであってもよいし、先述したような予め残高にチャージするタイプや電子バリューを利用して送金するタイプであってもよい。

【0069】

割勘イベントの識別情報は、割勘イベントを識別可能な情報であればよく、本実施形態ではイベントＩＤを例に挙げるが、イベント名等の他の情報であってもよい。本実施形態では、参加者は詳細画面Ｇ１１のボタンＢ１１０，Ｂ１１１を選択することで送金を行うが、これらのボタンにイベントＩＤが埋め込まれているものとする。なお、参加者は、代表差が送信したメッセージから送金を行うことができてもよく、この場合には、メッセージ中のボタンＢ９０又はリンクＬ１００にイベントＩＤが埋め込まれているものとする。

【0070】

本実施形態では、銀行サーバ１０によって要求受付部１０４が実現されるので、要求受付部１０４は、参加者端末４０から、イベントＩＤとともに送金要求を受信する。例えば、参加者がボタンＢ１１０，Ｂ１１１を選択すると、参加者端末４０は、銀行サーバ１０に、イベントＩＤとともに送金要求を送信する。

【0071】

送金要求は、送金処理の実行を要求する旨を示す識別子を含む所定形式のデータが送信されることによって行われるようにすればよく、例えば、参加者が選択したボタンＢ１１０，Ｂ１１１に埋め込まれたイベントＩＤ、参加者が入力した送金額、参加者のユーザＩＤ、参加者名、及びメッセージアプリの参加者のアカウント等が含まれていてもよい。なお、これらの情報は、送金要求とは別データとして送信されてもよい。

【0072】

［実行部］
実行部１０５は、送金要求に基づいて、参加者から代表者への送金処理を実行する。実行部１０５は、送金要求を受信したことに応じて送金処理を実行する。送金処理は、銀行サーバ１０が単独で実行してもよいし、銀行サーバ１０とメッセージサーバ２０とが協力して実行してもよい。本実施形態では、送金要求にイベントＩＤが含まれているので、実行部１０５は、割勘データベースＤＢ２を参照し、当該イベントＩＤが格納されたレコードを特定する。実行部１０５は、当該レコードに格納された代表者のアカウント又は受取口座を送金先として特定する。本実施形態では、参加者が送金額を指定するので、実行部１０５は、送金要求に含まれる送金額に基づいて、送金処理を実行する。なお、参加者は特に送金額をしていしなくてもよく、この場合、実行部１０５は、上記特定したレコードに格納された参加者の負担額を送金額として特定し、送金処理を実行する。

【0073】

送金処理自体は、種々の処理を適用可能であり、参加者の支払方法に応じた処理が実行されるようにすればよい。例えば、アプリ送金であれば、実行部１０５は、参加者のメッセージアプリのアカウントと連携する銀行口座の残高を減少させ、代表者の銀行口座の残高を増加させる。これら減少量及び増加量は、送金額と同じであってもよいし、所定の手数料を考慮した額であってもよい。他にも例えば、代表者に所定の受取操作をさせる場合には、代表者が受取操作をした場合に送金処理が実行されてもよい。他にも例えば、アカウントに関連付けられた残高をチャージしたうえで送金するタイプであれば、実行部１０５は、参加者の残高を減少させ、代表者の残高を増加させる。他の支払方法についても同様に、実行部１０５は、参加者が指定した支払方法に応じた処理を実行すればよい。

【0074】

［入力受付部］
入力受付部１０６は、代表者による送金状況の入力を受け付ける。本実施形態では、銀行サーバ１０によって入力受付部１０６が実現されるので、入力受付部１０６は、代表者端末３０から、代表者が入力した送金状況を受信することによって、送金状況の入力を受け付ける。代表者端末３０では、代表者が操作部３４から送金状況を入力すると、当該入力された送金状況を銀行サーバ１０に送信する。入力受付部１０６は、当該送信された送金状況を受信することによって、送金状況の入力を受け付ける。本実施形態では、送金状況は、「未済」、「完了」、「不足」、又は「過剰」の４つのステータスによって表されるので、入力受付部１０６は、管理画面Ｇ１３のボタンＢ１３２から代表者が入力したステータスを受信することによって、送金状況の入力を受け付けることになる。

【0075】

［取得部］
取得部１０７は、割勘イベントごとに、参加者から代表者への送金状況を取得する。取得部１０７は、個々の割勘イベント内での各参加者の送金状況を取得する。本実施形態では、１つの割勘イベントにつき２人以上の参加者を指定可能なので、取得部１０７は、各参加者の送金状況を取得することになる。なお、送金状況は、送金が行われたか否かを意味してもよいし、送金額が足りているか否かを意味してもよい。他にも例えば、送金状況は、参加者の個別ステータスを意味してもよい。

【0076】

銀行サーバ１０は、後述する実行部１０５の送金処理については検知できるので、取得部１０７は、送金処理が実行された場合に、送金処理が実行されたことを送金状況として取得する。例えば、取得部１０７は、送金元、送金先、及び送金額を取得して、参加者から代表者への送金が行われたか否かを判定し、参加者の送金処理が実行されていなければ、個別ステータスを初期値である「未済」のままとする。また例えば、取得部１０７は、参加者の送金額が負担額と一致していれば、個別ステータスを「完了」とする。また例えば、取得部１０７は、参加者の送金額が負担額よりも少なければ、個別ステータスを「不足」とする。また例えば、取得部１０７は、参加者の送金額が負担額よりも多ければ、「過剰」のステータスとする。

【0077】

一方、銀行サーバ１０が検知できない送金方法（例えば、銀行振込や手渡し等）については、取得部１０７は、代表者による入力に基づいて、送金状況を取得する。取得部１０７は、代表者による入力が受け付けられた場合には、代表者により入力された送金状況を取得し、送金処理が実行された場合には、送金処理が実行されたことを送金状況として取得することになる。即ち、代表者が手動でステータスを入力する場合には、取得部１０７は、入力受付部１０６が受け付けた入力結果を送金状況として取得する。

【0078】

［制限部］
制限部１０８は、送金処理が実行された後に、代表者の入力により送金状況が変化することを制限する。本実施形態では、メッセージアプリのアプリ送金によって送金処理が実行され、ステータスが「完了」になった場合には、制限部１０８は、代表者の操作によってステータスを変更できないようにロックする。例えば、制限部１０８は、代表者端末３０から管理画面Ｇ１３のボタンＢ１３２が選択されたことを受信しても、ステータスを変化させないように制限する。他にも例えば、制限部１０８は、ボタンＢ１３２をグレーアウト等させたりボタンＢ１３２を消去したりして、代表者が選択できないようにしてもよい。

【0079】

［過不足判定部］
過不足判定部１０９は、送金状況に基づいて、参加者から代表者への送金額の過不足が生じているか否かを判定する。本実施形態では、アプリ送金を利用した送金処理が実行された場合には、実際の送金額が送金状況として取得されるので、過不足判定部１０９は、参加者の送金額と、割勘データベースＤＢ２に格納された当該参加者の負担額と、を比較して、過不足が生じているか否かを判定する。過不足判定部１０９は、送金額が負担額よりも多ければ過剰であると判定し、送金額が負担額よりも少なければ不足であると判定する。

【0080】

また、本実施形態では、代表者が手動でステータスを入力可能なので、過不足判定部１０９は、代表者の入力結果に基づいて、送金額の過不足が生じているか否かを判定してもよい。例えば、過不足判定部１０９は、管理画面Ｇ１３のボタンＢ１３２から代表者が「過剰」を選択した場合には、送金額が過剰であると判定し、管理画面Ｇ１３のボタンＢ１３２から代表者が「不足」を選択した場合には、送金額が不足であると判定する。

【0081】

［完了判定部］
完了判定部１１０は、各参加者の送金状況に基づいて、割勘イベントが完了したか否かを判定する。例えば、完了判定部１１０は、送金が完了していない参加者が存在する場合に割勘イベントが完了したと判定せず、全ての参加者の送金が完了した場合に割勘イベントが完了したと判定する。本実施形態では、参加者の送金額が負担額と一致し、ステータスが「完了」になった場合に送金が完了するので、完了判定部１１０は、ステータスが「完了」になっていない参加者が存在する場合に割勘イベントが完了したと判定せず、全ての参加者のステータスが「完了」になった場合に、割勘イベントが完了したと判定する。

【0082】

［表示制御部］
表示制御部１１１は、割勘イベントごとに、送金状況の管理画面Ｇ１３を表示させる。表示制御部１１１は、個々の割勘イベント内での管理画面Ｇ１３を表示させる。表示制御部１１１は、割勘データベースＤＢ２に基づいて、管理画面Ｇ１３を表示させる。本実施形態では、表示制御部１１１が銀行サーバ１０において実現されるので、表示制御部１１１は、代表者端末３０に管理画面Ｇ１３の表示データを送信することによって、管理画面Ｇ１３を代表者端末３０に表示させる。

【0083】

本実施形態では、実行部１０５によって送金処理が実行されるので、表示制御部１１１は、管理画面Ｇ１３に、送金処理が実行されたことを通知する。表示制御部１１１は、各参加者の送金処理の実行の有無を示す画像を表示させたり、送金処理によって送金が完了したか否かを示す画像を表示させたりする。表示制御部１１１は、管理画面Ｇ１３のボタンＢ１３２によって、送金処理が実行されたことを通知したり、管理画面Ｇ１３に送金処理による送金額を表示させることによって送金処理が実行されたことを通知したりする。

【0084】

本実施形態では、複数の参加者の少なくとも１人は、アプリ送金のユーザであり、各参加者は、アプリ送金を含む複数の送金方法のうちの何れかを利用して、代表者に送金するので、表示制御部１１１は、管理画面Ｇ１３において、各参加者がアプリ送金のユーザであるか否かを識別可能に表示させる。表示制御部１１１は、ユーザデータベースＤＢ１に格納された連携有無情報を参照し、連携有りの参加者についてはアプリ送金のユーザであると判定し、連携無しの参加者についてはアプリ送金のユーザであると判定しない。

【0085】

表示制御部１１１は、アプリ送金のユーザであると判定された参加者に関連付けてアイコンＩ１３１を表示させ、アプリ送金のユーザであると判定されない参加者にはアイコンＩ１３１を表示させない。なお、表示制御部１１１は、他の方法を利用してアプリ送金のユーザであるか否かを識別可能としてもよく、例えば、アプリ送金のユーザであるか否かを示す文字列を表示させてもよい。他にも例えば、表示制御部１１１は、参加者名の表示態様や参加者の顔写真等のアイコンの表示態様によって識別可能としてもよい。表示態様とは、画像の見た目であり、例えば、画像の色、輝度、模様、又はサイズ等である。

【0086】

また例えば、表示制御部１１１は、複数の候補者の中から参加者を選択するための連絡先選択画面Ｇ４において、各候補者がアプリ送金のユーザであるか否かを識別可能に表示させる。例えば、表示制御部１１１は、アプリ送金のユーザであるか否かによってアイコンＩ４２の表示態様を変化させる。アイコンＩ４２の表示態様については、先述した通りであり、本実施形態では、色によって表現されるが、輝度、模様、又はサイズ等によって、アプリ送金のユーザであるか否かが識別されるようにしてもよい。他にも例えば、表示制御部１１１は、アプリ送金のユーザであると判定された参加者には、その旨のアイコンを表示させ、アプリ送金のユーザであると判定されない参加者には、アイコンを表示させないようにしてもよい。また例えば、表示制御部１１１は、アプリ送金のユーザであるか否かを示す文字列を表示させてもよい。

【0087】

また例えば、表示制御部１１１は、代表者による送金状況の入力が受け付けられた場合には、代表者により入力された送金状況を表示させ、送金処理が実行された場合には、送金処理が実行されたことを通知する。表示制御部１１１は、代表者によりステータスが入力された場合には、当該ステータスをボタンＢ１３２に表示させ、送金処理が実行された場合には、送金処理の実行結果をボタンＢ１３２に表示させる。本実施形態では、代表者による入力や送金処理の実行結果が割勘データベースＤＢ２の個別ステータスに反映されるので、表示制御部１１１は、個別ステータスを参照し、ボタンＢ１３２の表示を決定する。

【0088】

また例えば、表示制御部１１１は、管理画面Ｇ１３に、過不足判定部１０９の判定結果を表示させる。表示制御部１１１は、送金が過剰であること、又は、送金が不足していることを示す画像を管理画面Ｇ１３に表示させる。例えば、表示制御部１１１は、送金が過剰であると判定された場合には「過剰」を示すボタンＢ１３２を表示させ、送金が不足していると判定された場合には「不足」を示すボタンＢ１３２を表示させる。なお、過不足判定部１０９の判定結果は、ボタンＢ１３２以外によって表示されてもよく、例えば、表示制御部１１１は、過不足を示す文字列を表示させてもよいし、アイコンによって表示させてもよい。他にも例えば、表示制御部１１１は、参加者の名前や顔写真等のアイコンの表示態様を、過不足判定部１０９の判定結果に基づいて決定してもよい。

【0089】

また例えば、表示制御部１１１は、管理画面Ｇ１３において、割勘イベントに関するメッセージを参加者に送信するための画像を表示させる。本実施形態では、当該画像は、管理画面Ｇ１３のボタンＢ１３３，Ｂ１３４であるが他の画像であってもよい。先述したように、当該画像が選択されたことに応じてメッセージが送信されてもよいし、当該画像が選択された後にメッセージアプリ画面Ｇ９又は外部ツール画面Ｇ１０が表示され、代表者がメッセージを編集したり送信したりするための操作が行われたことに応じてメッセージが送信されてもよい。

【0090】

また例えば、表示制御部１１１は、管理画面Ｇ１３に、完了判定部１１０の判定結果を表示させる。表示制御部１１１は、送金が完了していること、又は、送金が完了していないことを示す画像を管理画面Ｇ１３に表示させる。例えば、表示制御部１１１は、送金が完了していると判定された場合には「完了」を示すボタンＢ１３２を表示させ、送金が完了していると判定されない場合には「未済」、「過剰」、又は「不足」を示すボタンＢ１３２を表示させる。なお、過不足判定部１０９の判定結果は、ボタンＢ１３２以外によって表示されてもよく、例えば、表示制御部１１１は、送金完了又は未完了を示す文字列を表示させてもよいし、アイコンによって表示させてもよい。他にも例えば、表示制御部１１１は、参加者の名前や顔写真等のアイコンの表示態様を、完了判定部１１０の判定結果に基づいて決定してもよい。

【0091】

［複製部］
複製部１１２は、作成部１０２により作成された割勘イベントを複製し、新たな割勘イベントを作成する。複製とは、作成済みの割勘イベントの情報の一部又は全部を利用することである。本実施形態では、管理画面Ｇ１３のボタンＢ１３６が選択された場合に、複製部１１２は、管理画面Ｇ１３に表示中の割勘イベントを複製し、新たな割勘イベントを作成する。例えば、ボタンＢ１３６が選択された後に、イベント作成画面Ｇ２が表示され、入力フォームＦ２０〜Ｆ２２の各々に、複製元の割勘イベントのイベント名、合計金額、及びメッセージがデフォルトで入力されていてもよい。また例えば、参加者登録画面Ｇ３の入力フォームＦ３０，Ｆ３５の各々に、複製元の割勘イベントの人数と参加者名がデフォルトで入力されてもよい。また例えば、金額入力画面Ｇ５の入力フォームＦ５２に、複製元の割勘イベントの金額がデフォルトで入力されてもよい。代表者は、これらの情報をそのまま利用して新たな割勘イベントを作成してもよいし、これらの情報の一部を変更したうえで新たな割勘イベントを作成してもよい。

【0092】

［４．本実施形態において実行される処理］
図１１は、本実施形態において実行される処理のフロー図である。図１１に示す処理は、制御部１１，３１，４１の各々が記憶部１２，３２，４２に記憶されたプログラムに従って動作することによって実行される。これらの処理は、各機能ブロックが実行する処理の一例である。

【0093】

図１１に示すように、まず、銀行サーバ１０と代表者端末３０との間で、割勘イベントの作成処理が実行される（Ｓ１）。Ｓ１においては、図２−図４を参照して説明した流れに沿って、割勘イベントが作成され、参加者の登録などが行われる。代表者端末３０は、確認画面Ｇ６のボタンＢ６１が選択されると、それまでに入力されたイベント名等の情報を含む割勘イベントの作成要求を送信し、銀行サーバ１０は、作成要求を受信すると、イベントＩＤを発行して当該情報とともに割勘データベースＤＢ２に格納する。

【0094】

なお、トップ画面Ｇ１が表示されるにあたり、代表者は銀行サーバ１０にログインしており、銀行サーバ１０は、代表者のユーザＩＤを特定可能なものとする。また、割勘データベースＤＢ２に格納される全体ステータスは「未精算」が初期値として格納され、作成日は現在の日付が格納されるものとする。また、銀行サーバ１０は、メッセージアプリを利用する参加者については、メッセージサーバ２０又は代表者端末３０内の連絡先からアカウントを取得し、割勘データベースＤＢ２に格納し、個別ステータスは「未済」が初期値として格納される。受取口座は、ユーザデータベースＤＢ１に格納された代表者の口座が格納される。

【0095】

割勘イベントが生成されると、参加者端末４０は、代表者が送信したメッセージを受信し、制御部４１は、参加者がメッセージ内のボタンＢ９０又はリンクＬ１００を選択したことに応じて、銀行サーバ１０に対し、詳細画面Ｇ１１の表示要求を送信する（Ｓ２）。ボタンＢ９０及びリンクＬ１００の各々にはイベントＩＤが埋め込まれており、Ｓ２においては、制御部４１は、当該イベントＩＤを含む表示要求を送信する。これにより、銀行サーバ１０は、どの割勘イベントの表示要求であるかを特定可能となる。

【0096】

銀行サーバ１０においては、表示要求を受信すると、制御部１１は、割勘データベースＤＢ２に基づいて、詳細画面Ｇ１１の表示データを送信する（Ｓ３）。Ｓ３においては、制御部１１は、表示要求に含まれるイベントＩＤを参照し、当該イベントＩＤが格納された割勘データベースＤＢ２のレコードに基づいて、詳細画面Ｇ１１の表示データを生成する。表示データは、任意のデータ形式であればよく、例えば、ブラウザ上で詳細画面Ｇ１１を表示させるのであればＨＴＭＬデータであり、銀行が提供するアプリケーション上で詳細画面Ｇ１１を表示させるのであればアプリの画面フレームにはめ込むテキストや画像等である。

【0097】

参加者端末４０においては、表示データを受信すると、制御部４１は、詳細画面Ｇ１１を表示部４５に表示させる（Ｓ４）。Ｓ４においては、制御部４１は、参加者がメッセージアプリのアプリ送金を利用している場合には、図５の左側に示す詳細画面Ｇ１１を表示させ、参加者がアプリ送金を利用していない場合には、図５の右側に示す詳細画面Ｇ１１を表示させる。ここでは、参加者がメッセージアプリのアプリ送金を利用しており、当該アプリ送金を利用して送金する場合の処理を説明する。参加者がメッセージアプリのアプリ送金を利用していない場合には、参加者は、銀行口座から送金したり、他の方法によって送金したりする。

【0098】

制御部４１は、参加者がボタンＢ１１０，Ｂ１１１を選択して送金額を入力すると、銀行サーバ１０に対し、送金要求を送信する（Ｓ５）。ボタンＢ１１０，Ｂ１１１の各々にはイベントＩＤと、アカウント又は参加者名と、が埋め込まれているものとする。Ｓ５においては、制御部４１は、当該イベントＩＤ、アカウント又は参加者名、及び入力された送金額を含む送金要求を送信する。これにより、銀行サーバ１０は、どの割勘イベントにおけるどの参加者の送金要求であるかを特定可能となる。

【0099】

銀行サーバ１０においては、送金要求を受信すると、制御部１１は、当該受信した送金要求及び割勘データベースＤＢ２に基づいて、参加者から代表者への送金処理を実行する（Ｓ６）。Ｓ６においては、制御部１１は、送金要求に含まれる送金額に基づいて、送金処理を実行する。送金処理が実行されると、参加者の銀行口座の残高が送金額に応じた額だけ減少し、代表者が送金を受け取れる状態となる。なお、代表者は、送金を受け取るための操作をしてもよいし、特に当該操作を要することなく、代表者の受取口座の残高が増加してもよい。

【0100】

制御部１１は、参加者が入力した送金額と負担額に基づいて、参加者の個別ステータスを更新する（Ｓ７）。Ｓ７においては、制御部１１は、送金額と負担額が一致していれば、個別ステータスを「完了」とする。制御部１１は、送金額が負担額よりも少なければ、個別ステータスを「不足」とする。制御部１１は、送金額が負担額よりも多ければ、個別ステータスを「過剰」とする。なお、全ての参加者の個別ステータスが「完了」となっていれば、全体ステータスは「完了」となる。

【0101】

一方、代表者端末３０においては、代表者がトップ画面Ｇ１のボタンＢ１１又は完了画面Ｇ７のボタンＢ７１を選択すると、制御部３１は、銀行サーバ１０に対し、イベント一覧画面Ｇ１２の表示要求を送信する（Ｓ８）。銀行サーバ１０においては、表示要求を受信すると、制御部１１は、割勘データベースＤＢ２に基づいて、イベント一覧画面Ｇ１２の表示データを送信する（Ｓ９）。Ｓ９においては、制御部１１は、割勘データベースＤＢ２を参照し、表示要求を送信した代表者の代表者ＩＤが格納されたレコードに基づいて、イベント一覧画面Ｇ１２の表示データを生成する。なお、代表者ＩＤは、代表者端末３０が何らかの要求を送信する場合に一緒に送信されるものとする。

【0102】

代表者端末３０においては、表示データを受信すると、制御部３１は、当該受信した表示データに基づいて、イベント一覧画面Ｇ１２を表示部３５に表示させる（Ｓ１０）。制御部３１は、代表者がリストＬ１２０から割勘イベントを選択すると、当該選択された割勘イベントの管理画面Ｇ１３の表示要求を送信する（Ｓ１１）。リストＬ１２０にはイベントＩＤが埋め込まれており、Ｓ１１においては、制御部３１は、当該イベントＩＤを含む表示要求を送信する。これにより、銀行サーバ１０は、どの割勘イベントの表示要求であるかを特定可能となる。

【0103】

銀行サーバ１０においては、表示要求を受信すると、制御部１１は、割勘データベースＤＢ２に基づいて、管理画面Ｇ１３の表示データを送信する（Ｓ１２）。Ｓ１２においては、制御部１１は、割勘データベースＤＢ２を参照し、表示要求に含まれるイベントＩＤが格納されたレコードに基づいて、管理画面Ｇ１３の表示データを生成する。例えば、制御部１１は、全体ステータスに基づいてアイコンＩ１３０の表示を決定し、各参加者の個別ステータスに基づいてボタンＢ１３２の表示を決定する。また例えば、制御部１１は、ユーザデータベースＤＢ１を参照し、各参加者の連携有無情報に基づいて、アイコンＩ１３１を表示させるか否かを決定する。

【0104】

代表者端末３０においては、表示データを受信すると、制御部３１は、当該受信した表示データに基づいて、管理画面Ｇ１３を表示部３５に表示させる（Ｓ１３）。制御部３１は、操作部３４の検出信号に基づいて、ボタンＢ１３２が選択されたか否かを判定する（Ｓ１４）。

【0105】

ボタンＢ１３２が選択されたと判定された場合（Ｓ１４；Ｙ）、制御部３１は、当該選択されたボタンＢ１３２の表示を変更し（Ｓ１５）、ステータスの変更要求を送信する（Ｓ１６）。Ｓ１６においては、変更要求には、代表者が入力したステータスの識別情報が含まれているものとする。銀行サーバ１０においては、変更要求を受信すると、制御部１１は、代表者が選択したボタンＢ１３２が示す参加者のステータスを変更し、割勘データベースＤＢ２を更新する（Ｓ１７）。

【0106】

一方、Ｓ１４において、ボタンＢ１３２が選択されたと判定されない場合（Ｓ１４；Ｎ）、本処理は終了する。この場合、代表者がボタンＢ１３３〜Ｂ１３７の何れかを選択した場合には、当該選択されたボタンに応じた処理が実行される。各ボタンが選択された場合に実行される処理については、先述した通りである。

【0107】

送金管理システム１によれば、割勘イベントごとに参加者の送金状況を取得して、割勘イベントごとに管理画面Ｇ１３を表示させることで、参加者から代表者への送金状況を容易に管理することができる。例えば、代表者が参加者の送金状況を把握することで、負担金をもらい忘れることを防止することができる。また例えば、管理画面Ｇ１３において、メッセージの送信有無を表示させるようにした場合には、代表者が参加者にメッセージを連絡済みであるかといったことも把握しやすくなる。

【0108】

また、代表者と少なくとも１人の参加者とがアプリ送金のユーザである場合に、当該アプリ送金を利用して割勘イベントの送金処理が実行されることで、送金の手続きを簡易化することができる。また、アプリ送金は銀行サーバ１０で検知可能なので、管理画面Ｇ１３における送金状況に自動的に反映し、最新の送金状況を管理することができる。

【0109】

また、管理画面Ｇ１３において、各参加者がアプリ送金のユーザであるか否かを示すアイコンＩ１３１が表示されるので、代表者は、参加者がアプリ送金を利用して送金する可能性があるかを容易に判断することができる。代表者は、アプリ送金を利用した送金の可能性を事前に把握することで、自身の銀行口座の振込履歴を何度も確認したり、参加者に不要な催促をしたりすることを防止することができる。

【0110】

また、連絡先選択画面Ｇ４において、連絡先の友人がアプリ送金のユーザであるか否かが識別可能に表示されるので、代表者は、参加者がアプリ送金を利用して送金する可能性があるかを容易に判断することができる。このため、代表者は、参加者に対してどのようなメッセージを送ったらよいかを決めやすくなる。

【0111】

また、アプリ送金によって送金処理が実行され、参加者の個別ステータスが自動的に設定された場合に、代表者の入力によって個別ステータスが変化することが制限されるので、代表者の誤入力によって、送金が完了済みの参加者が未済等のステータスになってしまうことを防止することができる。

【0112】

また、管理画面Ｇ１３において、各参加者の送金の過不足を表示させることで、参加者から代表者への送金状況をより容易に管理することができる。

【0113】

また、管理画面Ｇ１３から各参加者にメッセージを送信可能とすることで、送金を完了していない参加者に催促する手間を軽減したり、送金の過不足が生じている参加者に今後の対応を相談する手間を軽減したりすることができる。

【0114】

また、管理画面Ｇ１３から割勘イベントの複製を可能とすることで、割勘イベントを新たに作成する手間を省くことができる。

【0115】

また、管理画面Ｇ１３において、割勘イベント全体の完了の有無を表示させることで、割勘イベントをより容易に管理することができる。また、代表者が割勘イベントの参加者を指定することで、誤って関係のない者が参加者として登録されてしまうことを防止できる。

【0116】

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

【0117】

例えば、銀行サーバ１０が検知可能な送金方法として、アプリ送金を説明したが、銀行サーバ１０は、他の送金方法を検知して割勘イベントのステータスに反映してもよい。例えば、銀行サーバ１０は、自身に開設された銀行口座への振込又は当該銀行口座からの振込においてイベントＩＤが指定された場合に、送金を検知してステータスに反映してもよい。また例えば、銀行サーバ１０は、電子バリューを利用した送金やＳＮＳを利用した送金を検知してステータスに反映してもよい。

【0118】

また例えば、代表者が、銀行口座を開設済みであり、かつ、アプリ送金との連携も済ませている場合を説明したが、代表者は、特に銀行口座を開設していなくてもよいし、アプリ送金との連携を済ませていなくてもよい。また例えば、割勘イベントは、有効期限が設定されていてもよく、例えば、作成日から所定日数（例えば、数日〜数か月程度）が経過した割勘イベントは無効とされてもよい。また例えば、個別ステータスとして「未済」、「不足」、「過剰」、及び「完了」の４つを説明したが、任意のステータスを設定可能であり、これらのうちの２つ又は３つだけであってもよいし、「その他」、「連絡済」、「保留」といった他のステータスが存在してもよい。全体ステータスについても同様であり、他のステータスが存在してもよい。

【0119】

また例えば、銀行サーバ１０において図８に示す各機能が実現される場合を説明したが、他のコンピュータによって各機能が実現されてもよい。例えば、データ記憶部１００は、銀行サーバ１０とは別のデータベースサーバで実現されてもよい。また例えば、登録部１０１及び入力受付部１０６が代表者端末３０において実現され、操作部３４が代表者の操作を受け付けることが参加者の指定及び送金状況の入力を受け付けることに相当してもよい。また例えば、取得部１０７及び表示制御部１１１が代表者端末３０において実現され、代表者端末３０が銀行サーバ１０から送金状況を取得して管理画面Ｇ１３の表示データを生成してもよい。また例えば、代表者端末３０の表示制御部１１１は、銀行サーバ１０から送金状況を取得するのではなく、銀行サーバ１０が生成した表示データを受信して管理画面Ｇ１３を表示させてもよい。この場合、代表者端末３０に記憶されたアプリケーションは、代表者の操作に基づいて作成された、少なくとも参加者が代金を負担し合う支払イベントごとに、参加者から代表者への送金状況の管理画面を表示させる表示制御部１１１として機能させることになる。また例えば、要求受付部１０４が参加者端末４０において実現され、操作部４４が参加者の操作を受け付けることが送金要求を受け付けることに相当してもよい。また例えば、メッセージサーバ２０において実行部１０５が実現され、メッセージサーバ２０が主体となって送金処理が実行されてもよい。また例えば、制限部１０８が代表者端末３０において実現され、代表者端末３０がボタンＢ１３２をグレーアウトしたり消去したりしてもよい。また例えば、送信部１０３が代表者端末３０において実現され、代表者端末３０から参加者端末４０にメッセージが送信されてもよい。他にも例えば、各機能は、他のコンピュータで実現されてもよいし、複数のコンピュータで分担されてもよい。

【符号の説明】

【0120】

１ 送金管理システム、Ｎ ネットワーク、１０ 銀行サーバ、１１ 制御部、１２ 記憶部、１３ 通信部、２０ メッセージサーバ、２１ 制御部、２２ 記憶部、２３ 通信部、３０ 代表者端末、３１ 制御部、３２ 記憶部、３３ 通信部、３４ 操作部、３５ 表示部、４０ 参加者端末、４１ 制御部、４２ 記憶部、４３ 通信部、４４ 操作部、４５ 表示部、Ｇ１ トップ画面、Ｇ２ イベント作成画面、Ｇ３ 参加者登録画面、Ｇ４ 連絡先選択画面、Ｇ５ 金額入力画面、Ｇ６ 確認画面、Ｇ７ 完了画面、Ｇ８ 送信画面、Ｇ９ メッセージアプリ画面、Ｇ１０ 外部ツール画面、Ｇ１１ 詳細画面、Ｇ１２ イベント一覧画面、Ｇ１３ 管理画面、１００ データ記憶部、１０１ 登録部、１０２ 作成部、１０３ 送信部、１０４ 要求受付部、１０５ 実行部、１０６ 入力受付部、１０７ 取得部、１０８ 制限部、１０９ 過不足判定部、１１０ 完了判定部、１１１ 表示制御部、１１２ 複製部。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】