JP2019087023A - 情報処理プログラム、方法、装置、及びシステム - Google Patents

Abstract

【課題】改善された割り勘・費用分担に関する支払い処理技術及び管理制御技術を提供する。【解決手段】サーバ上で管理されるトークルームを介して会話可能に構成された第１情報処理端末に対応付けられた第１ユーザと、前記第１情報処理端末と前記トークルームを介して会話可能に構成された１以上の第２情報処理端末に対応付けられた１以上の第２ユーザとの間で支払いの調整を行うためのプログラムであって、前記第１情報処理端末に、前記第２情報処理端末への支払い依頼を要求させるステップと、前記第２情報処理端末からの応答を受信させるステップと、前記第２情報処理端末からの応答の受信によって、前記第２情報処理端末に対応付けられた１以上の第２ユーザの支払い方法及び支払期限を前記サーバに管理させるよう要求させるステップと、を実行する。【選択図】図４Ａ

Description

本発明は、広くネットワークを介してユーザからの集金処理やユーザ間の支払い処理等を行う情報処理プログラム、方法、装置、及びシステムに関し、より具体的には、電子的な決済を含めた電子バリューを制御することによって集金処理や支払処理等を管理制御するためのプログラム、方法、装置、及びシステムに関する。

近年、クレジットカードや電子マネー等の電子バリューを介した決済が普及している。例えば、クレジットカードを介して複数の者が共に食事をしたときなどに行う割り勘支払いなどを処理するものなどは、スプリット（Split the check）などと呼ばれ、米国等において広く普及している。電子バリューを介した決済は、これまで多種多様に発展してきた。

例えば、クレジットカードの仕組みを利用する前払型支払手段の発行者に損失が発生するリスクを軽減するシステムが提案されている（特許文献１）。

すなわち、特許文献１には、後払型支払手段の加盟店で利用可能な前払型支払手段を申請した複数のユーザから払い込まれたそれぞれの前払金額の範囲内で、各ユーザの利用限度額および保証金額を設定する決定部と、前記前払型支払手段の残額を超える金額の前記加盟店からの売上請求に対する支払いのために用いられ、前記複数のユーザの保証金の総額となるプール金額を記憶するプール記憶部と、前記決定部により保証金額が設定される度に、該保証金額を前記プール記憶部に記憶したプール金額に加算する変更部とを備える情報処理システムが開示されている。

また、ユーザが利用したいクレジットカードで利用料金を決済するための信用が予約時になかった場合であっても、信用が戻った場合にそのクレジットカードでの決済が可能となる予約を受け付けるシステムも提案されている（特許文献２）。

すなわち、特許文献２には、サービスの利用日以降にクレジットカードで利用料金が決済される予約の要求に対し、指定された前記クレジットカードの有効性を確認することができなかった場合、予約を受け付け、前記指定されたクレジットカードの情報を記憶手段に記憶させる予約手段と、前記予約手段により予約が受け付けられた後、前記記憶手段に記憶された前記情報に基づいて、前記指定されたクレジットカードの有効性を確認する確認手段と、前記確認手段により前記指定されたクレジットカードが有効であると確認することができた場合、決済方法を前記指定されたクレジットカードでの決済にすることを示す情報を出力し、前記確認手段により有効であると確認することができなかった場合、決済方法を前記指定されたクレジットカードでの決済とは異なる方法にすることを示す情報を出力する出力手段と、を備えることを特徴とする情報処理装置が開示されている。

また、ストアードバリュー型とサーバ管理型の決済システムを組み合わせることによりユーザの利便性を高める情報処理サーバも提案されている（特許文献３）。

すなわち、特許文献３には、第１の電子バリューを記憶し所定の金額変更情報を用いて当該第１の電子バリューの残高を増減する機能を有する貨幣端末と接続して、指定された決済金額分の決済処理を実行する情報処理サーバであって、前記貨幣端末から識別データを取得する識別データ取得手段と、前記取得した識別データに対応付けてサーバ側の記憶手段に記憶している第２の電子バリューにより前記指定された決済金額を決済するときに不足金額が生じると判定された場合に、前記第１の電子バリューの残高を少なくとも当該不足金額分だけ減額させるための金額変更情報を生成し前記貨幣端末に送信する不足金額減額手段と、を具備したことを特徴とする情報処理サーバが開示されている。

また、割り勘による支払いにおいて、支払いに関する責任の所在を明確にするために、代表者が各メンバーから支払いの決済のための情報を受信してこれを店舗に送信する際に、支払いの決済のための情報の内容が代表者に知られてしまう可能性を低下させるシステム等も提案されている（特許文献４）。

すなわち、特許文献４には、店舗端末１０から送られた合計額を代表者端末３０で代表者が分割することにより決定した割り勘額が各メンバー端末５０からクレジット会社サーバ７０へ支払額として通知されると、クレジット会社サーバ７０は、支払いの決済のための情報を保持すると共に、この情報を暗号化した暗号化情報を含む支払い許可情報６３を各メンバー端末５０に送信し、各メンバー端末５０は、支払い許可情報６３と同内容の支払い許可情報４３を代表者端末３０に送信し、代表者端末３０は、支払い許可情報４３を連結した支払い許可情報２３を店舗端末１０に送信するよう構成されたシステムが開示されている。

また、多段階の割り勘支払いを実現することができるクレジットカードシステムも提案されている（特許文献５）。

すなわち、特許文献５には、クレジットカードの会員によるクレジットカード支払額の一部を割り勘支払いすることを依頼するための依頼情報を、当該会員とは異なる会員に対して通知する通知手段と、前記通知手段による前記依頼情報の通知を受けた会員が前記クレジットカード支払額の一部についてクレジットカード支払いを行った場合に、割り勘元と割り勘先との対応関係及びそれぞれのクレジットカード支払額を含む割り勘情報を生成する割り勘情報生成手段とを備え、前記通知手段が、先行する割り勘支払いにおいて割り勘先となった会員によるクレジットカード支払額の一部を割り勘支払いすることを依頼するための依頼情報を、当該会員とは異なる他の会員に対して通知するように構成され、前記割り勘情報生成手段が、前記通知手段による前記依頼情報の通知を受けた前記他の会員が前記割り勘先となった会員によるクレジットカード支払額の一部についてクレジットカード支払いを行った場合に、割り勘元と割り勘先との対応関係及びそれぞれのクレジットカード支払額を含む割り勘情報を生成するように構成されているクレジットカードシステムが開示されている。

また、注文した単一品を複数の人で分け合った場合、当該単一品の金額を分け合った複数の人に分割して割り振るＳｈａｒｅｄ精算処理が可能な会計処理装置も提案されている（特許文献６）。

すなわち、特許文献６には、注文された商品の支払い金額に関する会計処理を行う会計処理装置において、複数の人からなるグループが１品からなる単一の商品を注文した場合に、注文された当該単一の商品の金額を、注文した複数の人に分割して割り振るＳｈａｒｅｄ精算処理を行うことを特徴とする会計処理装置が開示されている。
この会計処理装置では、複数の人による割り勘処理として各人が注文した商品ごとに個別に精算する場合、注文数量が複数の商品は１個ずつに分割した個別精算処理用の注文商品の一覧が表示され、さらに、単一品の金額を分割するＳｈａｒｅｄ精算処理も必要であれば、該当商品を選択するとともにＳｈａｒｅｄ精算対象の人数を登録して、該当商品を当該人数分だけ分割した形で画面表示した後、それぞれに該当する人を指定することによって、各人ごとに個別精算金額とＳｈａｒｅｄ精算金額とを集計した金額を算出して、画面表示することにより会計処理が行われる。

特許第５６７８２３５号明細書 特許第５２６９２２１号明細書 特許第５５９５４３４号明細書 特開２０１４−１１２２８６号公報 特開２０１３−１８６７３２号公報 特開２００８−６５５７４号公報

しかしながら、上述した従来技術においては、個人の電子決済についての工夫が中心であり、複数のメンバーで構成されるようなグループ内での電子決済等については改善の余地がある。確かに、割り勘やシェアに関する支払いを処理するためのシステム（特許文献４〜６）も提案されているが、事後決済、事後の集金等の処理や管理制御等についてはさらなる改善の余地がある。

さらに、これらのやりとりを円滑に進めることができる新しい技術（督促技術、インタフェース技術等）やバリエーション技術の提供が望まれる。

本発明の一実施形態に係る情報処理プログラムは、サーバ上で管理されるトークルームを介して会話可能に構成された第１情報処理端末に対応付けられた第１ユーザと、前記第１情報処理端末と前記トークルームを介して会話可能に構成された１以上の第２情報処理端末に対応付けられた１以上の第２ユーザとの間で支払いの調整を行うためのプログラムであって、前記第１情報処理端末に、前記第２情報処理端末への支払い依頼を要求させるステップと、前記第２情報処理端末からの応答を受信させるステップと、前記第２情報処理端末からの応答の受信によって、前記第２情報処理端末に対応付けられた１以上の第２ユーザの支払い方法及び支払期限を前記サーバに管理させるよう要求させるステップと、を実行することを特徴とする。

本発明によれば、改善された割り勘・費用分担に関する支払い処理技術及び／または管理制御技術を提供することができる。

本発明の一実施形態に係る情報処理システムの全体構成を説明する説明図である。 本発明の実施形態のバリエーションを示すシステムまたは装置等の構成例を説明する説明図である。 本発明の一実施形態に係るシステムまたは装置等における基本動作例を説明する説明図である。 本発明の一実施形態に係るシステム等における基本的な動作概念フローを説明するフローチャートである。 本発明の一実施形態に係るシステム等におけるより詳細な動作例を示すフローチャートである。 本発明の一実施形態に係るシステム等におけるより詳細な動作例を示すフローチャートである。 本発明の一実施形態に係るシステム等における動作の機能概念を説明する説明図である。 本発明の一実施形態に係るシステム等における装置または端末間の処理及びデータの流れを説明する説明図である。 本発明の一実施形態に係るシステム等における装置または端末上の画面表示例を説明する説明図である。 本発明の一実施形態に係るシステム等における装置または端末上の画面表示例を説明する説明図である。 本発明の一実施形態に係るシステム等における装置または端末上の画面表示例を説明する説明図である。 本発明の一実施形態に係るシステム等における装置または端末上の画面表示例を説明する説明図である。 本発明の一実施形態に係るシステム等における装置または端末上の画面表示例を説明する説明図である。 本発明の一実施形態に係るシステム等における装置または端末上の他の画面表示例を説明する説明図である。 本発明の他の実施形態に係るシステム等における動作例を示すフローチャートである。 本発明の他の実施形態に係るシステム等における動作例を示すフローチャートである。 本発明の他の実施形態に係るシステム等における動作例を示すフローチャートである。 本発明の他の実施形態に係るシステム等における装置または端末上の画面表示例を説明する説明図である。 本発明の他の実施形態に係るシステム等における装置または端末上の画面表示例を説明する説明図である。 本発明の他の実施形態に係るシステム等における装置または端末上の画面表示例を説明する説明図である。 本発明の他の実施形態に係るシステム等における装置または端末上の画面表示例を説明する説明図である。 本発明の他の実施形態に係るシステム等における装置または端末上の画面表示例を説明する説明図である。

＜通信の秘密の遵守＞
本明細書に記載の開示を実施する場合は、通信の秘密に係る法的事項を遵守の上で実施されるものであることに留意されたい。

本開示に係る情報処理システム等を実施するための実施形態について、図面を参照して説明する。

＜システム構成＞
図１は、本開示の一実施形態における情報処理システムの構成を示す図である。図１に示すように、情報処理システム１００では、ネットワーク１９９を介して１以上のサーバ（サーバ１１０、サーバ１２０）と、１以上の端末（端末１５１、端末１５２、端末１５３）とが接続される。サーバ１１０、１２０は、ユーザが所有する端末１５１〜１５３に対し、ネットワーク１９９を介して端末間でのメッセージの送受信を実現するサービスを提供する。なお、ネットワーク１９９に接続される端末の数は制限されない。また、サーバの数についても制限されない（必要に応じて機能を拡張するためのサーバを追加することができる。１のサーバによってサービス提供させてもよい）。

図１に示されるとおり、ネットワーク１９９は、１以上のサーバと１以上の端末とを接続する役割を担う。すなわち、ネットワーク１９９は、端末１５１〜１５３がサーバ１１０または１２０に接続した後、データを送受信することができるように接続経路を提供する通信網を意味する。

例えば、ネットワーク１９９のうちの１つまたは複数の部分は、有線ネットワークや無線ネットワークであってもよい。ネットワーク１９９は、アドホック・ネットワーク（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）、電子メールクライアントなど）、ウェアラブル端末（メガネ型デバイス、時計型デバイスなど）、または他種のコンピュータ、またはコミュニケーションプラットホームを含む。ただし、本開示において、端末１５１〜１５３は、これらに限定されない。また、端末１５１〜１５３は情報処理端末と表現されても良い。

端末１５１〜１５３の構成は基本的には同一であるため、以下の説明においては、代表して端末１５１について説明することとし、以下、必要に応じて端末１５２や端末１５３を他端末として説明する。また、サーバ１１０、１２０についても同様に、代表してサーバ１１０について説明する。

サーバ１１０は、端末１５１等に対して、所定のサービスを提供する機能を備える。サーバ１１０は、各実施形態において記載する機能を実現できる情報処理装置であればどのような装置であってもよい。サーバ１１０は、代表的にはサーバ装置であり、その他にコンピュータ（例えば、デスクトップ、ラップトップ、タブレットなど）、メディアコンピュータプラットホーム（例えば、ケーブル、衛星セットトップボックス、デジタルビデオレコーダ）、ハンドヘルドコンピュータデバイス（例えば、ＰＤＡ、電子メールクライアントなど）、あるいは他種のコンピュータ、またはコミュニケーションプラットホームを含む。ただし、本開示において、サーバ１１０は、これらに限定されない。また、サーバ１１０は情報処理装置と表現されても良い。

＜ハードウェア（HW）構成＞
図１を用いて、通信システムに含まれる各装置のHW構成について説明する。

（１）端末のHW構成

端末１５１は、制御装置１５１０（ＣＰＵ：central processing unit（中央処理装置））、記憶装置１５１５、通信Ｉ／Ｆ１５１６（インタフェース）、入出力装置１５１７、表示装置１５１８、マイク１５１９ａ、スピーカ１５１９ｂ、カメラ１５１９ｃを備える。端末１５１のHWの各構成要素は、例えば、バスB2を介して相互に接続される。

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

入出力装置１５１７は、端末１５１に対する各種操作を入力する装置、および、端末１５１で処理された処理結果を出力する装置を含む。入出力装置１５１７は、入力装置と出力装置とが一体化していても良いし、入力装置と出力装置とに分離していてもよい（後者の場合、一例として、タッチパネル入力センサ等の入力装置１５１７ａと、タッチパネル出力デバイス、バイブレーション駆動機構等の出力装置１５１７ｂとに分離される）。

入力装置は、ユーザからの入力を受け付けて、当該入力に係る情報を制御装置１５１０に伝達できる全ての種類の装置のいずれかまたはその組み合わせにより実現される。入力装置は、代表的にはタッチパネルなどにより実現され、ユーザの指やスタイラスなどの指示具による接触とその接触位置を検出し、当該接触位置の座標を制御装置１５１０に伝達する。一方で、入力装置は、タッチパネル以外の入力装置により実現されてもよい。入力装置は、例えば、キーボード等に代表されるハードウェアキーや、マウス等のポインティングデバイス、カメラ（動画像を介した操作入力）、マイク（音声による操作入力）を含む。ただし、本開示において、入力装置はこれらに限定されない。

出力装置は、制御装置１５１０で処理された処理結果を出力することができる全ての種類の装置のいずれかまたはその組み合わせにより実現される。出力装置は、代表的には、タッチパネルなどにより実現される。一方で、出力装置はタッチパネル以外の出力装置により実現されても良い。例えば、スピーカ（音声出力）、レンズ（例えば３Ｄ（three dimensions）出力や、ホログラム出力）、プリンターなどを含むことができる。ただし、本開示において、出力装置はこれらに限定されない。

表示装置１５１８は、フレームバッファ（不図示）に書き込まれた表示データに従って、表示することができる全ての種類の装置のいずれかまたはその組み合わせにより実現される。表示装置１５１８は、代表的にはモニタ（例えば、液晶ディスプレイやOELD（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）など各種の記憶媒体により実現される。ただし、本開示において、記憶装置１５１５はこれらに限定されない。

端末１５１は、プログラムＰを記憶装置１５１５に記憶し、このプログラムＰを実行することで、制御装置１５１０が、制御装置１５１０に含まれる各部としての処理を実行する。つまり、記憶装置１５１５に記憶されるプログラムＰは、端末１５１に、制御装置１５１０が実行する各機能を実現させる。

マイク１５１９ａは、音声データの入力に利用される。スピーカ１５１９ｂは、音声データの出力に利用される。カメラ１５１９ｃは、動画像データの取得に利用される。

（２）サーバのHW構成
サーバ１１０は、制御装置１１１０（ＣＰＵ）、記憶装置１１０５、入出力装置１１０６、ディスプレイ１１０７、通信Ｉ／Ｆ１１０８（インタフェース）を備える。サーバ１１０のHWの各構成要素は、例えば、バスB1を介して相互に接続される。

制御装置１１１０は、プログラム内に含まれたコードまたは命令によって実現する機能を実行するために物理的に構造化された回路を有し、例えば、ハードウェアに内蔵されたデータ処理装置により実現される。

制御装置１１１０は、代表的には中央処理装置（ＣＰＵ）、であり、その他にマイクロプロセッサ、プロセッサコア、マルチプロセッサ、ＡＳＩＣ、ＦＰＧＡであってもよい。ただし、本開示において、制御装置１１１０はこれらに限定されない。

記憶装置１１０５は、サーバが動作するうえで必要とする各種プログラムや各種データを記憶する機能を有する。記憶装置１１０５は、ＨＤＤ、ＳＳＤ、フラッシュメモリなど各種の記憶媒体により実現される。ただし、本開示において、記憶装置１１０５はこれらに限定されない。

入出力装置１１０６は、サーバ１１０に対する各種操作を入力する装置により実現される。入出力装置１１０６は、ユーザからの入力を受け付けて、当該入力に係る情報を制御装置１１１０に伝達できる全ての種類の装置のいずれかまたはその組み合わせにより実現される。入出力装置１１０６は、代表的にはキーボード等に代表されるハードウェアキーや、マウス等のポインティングデバイスで実現される。なお、入出力装置１１０６は、例えば、タッチパネルやカメラ（動画像を介した操作入力）、マイク（音声による操作入力）を含んでいてもよい。ただし、本開示において、入出力装置１１０６はこれらに限定されない。

ディスプレイ１１０７は、代表的にはモニタ（例えば、液晶ディスプレイやOELD（organic electroluminescence display））で実現される。なお、ディスプレイ１１０７は、ヘッドマウントディスプレイ（ＨＤＭ）などであってもよい。なお、これらのディスプレイ１１０７は、は、３Ｄで表示データを表示可能であってもよい。ただし、本開示において、ディスプレイ１１０７はこれらに限定されない。

通信Ｉ／Ｆ１１０８は、ネットワーク１９９を介して各種データの送受信を行う。当該通信は、有線、無線のいずれで実行されてもよく、互いの通信が実行できるのであれば、どのような通信プロトコルを用いてもよい。通信Ｉ／Ｆ１１０８は、ネットワーク１９９を介して、端末１５１との通信を実行する機能を有する。通信Ｉ／Ｆ１１０８は、各種データを制御装置１１１０からの指示に従って、端末１５１に送信する。また、通信Ｉ／Ｆ１１０８は、端末１５１から送信された各種データを受信し、制御装置１１１０に伝達する。
サーバ１１０は、プログラムＰを記憶装置１１０５に記憶し、このプログラムＰを実行することで、制御装置１１１０が、制御装置１１１０に含まれる各部としての処理を実行する。つまり、記憶装置１１０５に記憶されるプログラムＰは、サーバ１１０に、制御装置１１１０が実行する各機能を実現させる。

本発明の各実施形態においては、端末１５１等および／またはサーバ１１０等のＣＰＵがプログラムＰを実行することにより、実現するものとして説明する。

なお、端末１５１の制御装置１５１０、および／または、サーバ１１０の制御装置１１１０は、ＣＰＵだけでなく、集積回路（ＩＣ（Integrated Circuit）チップ、ＬＳＩ（Large Scale Integration））等に形成された論理回路（ハードウェア）や専用回路によって各処理を実現してもよい。また、これらの回路は、１または複数の集積回路により実現されてよく、各実施形態に示す複数の処理を１つの集積回路により実現されることとしてもよい。また、ＬＳＩは、集積度の違いにより、ＶＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩなどと呼称されることもある。

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

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

サーバ１１０および／または端末１５１は、例えば、記憶媒体に記憶されたプログラムＰを読み出し、読み出したプログラムＰを実行することによって、各実施形態に示す複数の機能部の機能を実現することができる。

また、本発明の一実施形態に係るプログラムＰは、当該プログラムを伝送可能な任意の伝送媒体(通信ネットワークや放送波等)を介して、サーバ１１０または端末１５１に提供されてもよい。サーバ１１０および／または端末１５１は、例えば、インターネット等を介してダウンロードしたプログラムＰを実行することにより、各実施形態に示す複数の機能部の機能を実現する。

また、本開示の各実施形態は、プログラムＰが電子的な伝送によって具現化された、搬送波に埋め込まれたデータ信号の形態でも実現され得る。
サーバ１１０および／または端末１５１における処理の少なくとも一部は、１以上のコンピュータにより構成されるクラウドコンピューティングにより実現されていてもよい。
端末１５１における処理の少なくとも一部を、サーバ１１０により行う構成としてもよい。この場合、例えば、端末１５１の制御装置１５１０の各機能部の処理のうち少なくとも一部の処理を、サーバ１１０で行う構成としてもよい。
サーバ１１０における処理の少なくとも一部を、端末１５１により行う構成としてもよい。この場合、例えば、サーバ１１０の制御装置１１１０の各機能部の処理のうち少なくとも一部の処理を、端末１５１で行う構成としてもよい。
本開示において、判定の構成は必須でなく、判定条件を満たした場合に所定の処理が動作されたり、判定条件を満たさない場合に所定の処理がされたりしても良いことは当然である。

なお、本開示のプログラムは、例えば、ActionScript、JavaScript(登録商標)などのスクリプト言語、Objective-C、Java(登録商標)などのオブジェクト指向プログラミング言語、HTML5などのマークアップ言語などを用いて実装できる。ただし本開示はこれらに限定されない。

＜システム構成のバリエーション＞
図２に、本発明の実施形態のバリエーションを示すシステムまたは装置等の構成例を示す。同図（及び図３）に示した構成での特徴的な処理動作は、本発明がネットワークを介したサーバや端末との連携動作によってのみ実現されるものでなく、必要に応じて端末単体上でも実現可能な点である。

図２に示されるように、情報処理システム２００は、その最小限の構成として、情報処理サーバ２１０と、ユーザが使用する各種情報処理端末（図において、例示的に、ＰＣ２２０及び２３０、携帯電話２４０、携帯情報端末またはタブレット端末２５０〜２５２が示されている。以下、総称して「端末」とも言う）とで構成され、サーバ及び各種端末間は、図２に示されるように専用回線やインターネット等の公衆回線（有線の回線として、２６０、２７０、２８０、２９０）で相互に通信可能に接続されている。また、回線は有線であっても無線であってもよく、無線の場合、携帯電話２４０及び携帯情報端末またはタブレット端末２５０は、無線で図示しない基地局や無線ルータ等を介してインターネット２９０に乗り入れ、更に回線２８０を介して情報処理サーバ２１０と相互に通信可能に接続されている。

なお、携帯電話や携帯情報端末またはタブレットは、パーソナルコンピュータ（ＰＣ）と同等の処理能力（通信処理速度や画像処理能力等）を備えているものも多く、小型のコンピュータとも言うべきものである。

また、本発明の実施に必要なプログラムまたはソフトウェアは、通常、ＰＣや携帯情報端末の記憶部におけるＨＤＤまたはＳＳＤ等にインストールまたは記憶され、プログラムまたはソフトウェアの実行時には、必要に応じて記憶部内のメモリにその全部又は一部のソフトウェアモジュールとして読み出され、ＣＰＵにおいて演算実行される。

なお、演算実行は必ずしもＣＰＵ等の中央処理部で行われる必要はなく、図示しないディジタルシグナルプロセッサ（ＤＳＰ）等の補助演算装置を用いることもできる。

また、情報処理サーバ２１０のハードウェア構成も、基本的にはＰＣを採用することができる。なお、本発明はこれに限定されるものではないが、情報処理サーバ２１０は、必要に応じてそのハードウェアスペックを上げるにあたり、複数のＰＣ（一例として、数十台〜数万台）を並列的に作動させることによって大規模データの処理に適した構成をとることもできる。

＜図示しない他のシステムとの連携＞
本発明の一実施形態に係る情報処理システムは、その特徴である決済や集金等の処理を完了するにあたり、必要に応じて図示しないクレジット会社サーバや金融機関サーバ、あるいは店舗サーバ（当該店舗に加盟する加盟店端末を含む）と適宜連携して決済等の処理を完了させることができる。その意味で、本発明の一実施形態に係る情報処理システムそれ自体の中で決済等の一連の処理の全てを完了させる必要はない。つまり、本発明の一実施形態に係る情報処理システムにおける処理は、少なくとも決済等の一連の処理を完結させるために必要となる帳簿データ等のデータを出力するところまでで足りる（もちろん、それ以上の処理を行うことも排除されない）。

＜動作形態の基本バリエーション＞
図３に、図１や図２を参照して例示した本発明の一実施形態に係るシステムまたは装置等における基本動作例を示す。ここで特に示したいことは、本発明の特徴的動作は、ネットワークを介したサーバや端末との連携動作によっても、あるいは、端末単体上や端末間同士上でもサーバ連携とは独立して実現可能な点である。

図３において、「ユーザ端末」は、図１における端末１５１〜１５３、図２における端末２２０、２３０、２４０、２５０〜２５２に対応し、「情報処理サーバ」は、図１におけるサーバ１１０、１２０、図２における情報処理サーバ２１０に対応する。また、図３中、ｔ１〜ｔ１０は時系列の流れを示し、経時的に後述する動作や処理が行われるものである。

なお、実施形態において例示される動作または処理時刻（ｔ１等）は、本発明の概念の理解の容易のために例示されたものであり、本発明が実施形態において例示される個別の時系列関係に制限されることはない。

まず、日時ｔ１において、ユーザは、ユーザ端末を介して情報処理サーバから自身のユーザ端末を本発明にかかる情報処理端末として動作させるためのアプリケーションソフトウェアをダウンロードする（ステップＳ３０１）。このアプリケーションソフトウェアは、本発明にかかるプログラムの一部又は全部を処理するためのクライアントソフトウェアまたはアプリケーションソフトウェアである。そして、ダウンロードしたアプリケーションソフトウェアをユーザ端末にインストールする（ステップＳ３０２）。このとき、時刻ｔ２において、ユーザ端末からは、必要に応じてユーザ登録としてユーザ自身のメールアドレスのほか、次表のようなプロフィール情報を情報処理サーバへアップロード（ステップＳ３０３）して登録管理させることもできる（ステップＳ３０４）。

以上のデータ項目は、ユーザデータとして情報処理サーバ上の記憶装置に保存される（ステップＳ３０５）。時刻ｔ３以降は、ユーザが情報処理端末を操作することによりアプリを開始する（サーバは端末に対してサービス提供を開始する）ことができる。

次に、ユーザ端末にアプリをダウンロード及びインストールしたユーザは、時刻ｔ４においてアプリケーションソフトウェアを起動する（ステップＳ３０６）。時刻ｔ４〜時刻ｔ５まで、例示的にユーザは情報処理端末で提供されるサービスに興じている。

時刻ｔ５になると、ユーザはいったん本発明の一実施形態にかかるアプリケーションソフトウェアを中断または終了する。このとき、必要に応じて、アプリケーションのステータス情報を情報処理サーバへ転送し（ステップＳ３０７）、サーバではこれを受信して当該ユーザのユーザ情報としてのステータス情報を更新（ステップＳ３０８）及び保存（ステップＳ３０９）する。図３においては、これらの処理は、時刻ｔ６までに完了している。

なお、本発明の一実施形態にかかるアプリケーションソフトウェアを情報処理端末にインストールした後は、端末上で完全にクローズドに実行可能な形態とすることももちろん可能であり、この場合は、上述のステップＳ３０４〜ステップＳ３０５、並びに、ステップＳ３０８〜ステップＳ３０９を省略することができ、必要な情報があれば端末上のメモリに保存管理される。

次に、図３において、時刻ｔ７〜時刻ｔ１０では、本発明の一実施形態にかかるアプリケーションソフトウェアの少なくとも一部を情報処理サーバにおいて実施する場合の実施形態を例示している。この場合、ユーザは、ログイン動作と、コマンド送信という２つの典型的なユーザ端末操作を行い、情報処理サーバから必要なデータ送信を受け、あるいは、サービス提供を受けることとなる。

例えば、図３において、時刻ｔ７においてユーザが自身の情報処理端末を介してサーバへのログイン処理を行う（ステップＳ３１０）と、情報処理サーバでは必要な認証処理が適宜行われ（ステップＳ３１１）、時刻ｔ８において、ユーザがサービス提供を受けるためのデータを送信する（ステップＳ３１２）。例えば、端末からのコマンドを受信可能に構成されたトップメニュー画面や、アプリケーションの起動画面等である。
時刻ｔ９において、ユーザは情報処理端末を介して何らかのコマンドを送信する（ステップＳ３１３）。このコマンドは、メニュー画面に表示されたメニューの選択でもよく、アプリケーション起動画面であれば、アプリケーションを開始するための開始コマンドの場合もある。サーバ側では、このコマンドを受けて、サービス処理を開始する（ステップＳ３１４）。そして、時刻ｔ１０において、サーバから端末の要求に応じたサービスが提供される（ステップＳ３１５）。

なお、図３には図示していないが、時刻ｔ１０以降も、端末からは随時コマンドを送信することができ（例えば、メッセージ送信コマンドやメニュー選択コマンドなど）、都度、サーバでは端末からのコマンド受信を受けてサービスを提供することができる（例えば、受信したメッセージを他端末に転送したり、メッセージ解析をしてその結果を返信したりするなど）。

また、本発明の一実施形態において、ユーザは、ユーザ端末から特定の相手もしくは特定多数の相手に向けてメッセージを送信することもできる（図３においては不図示）。このメッセージは、情報処理サーバにて中継され、特定の相手もしくは特定多数の相手に転送され相手方において受信される。また、送信したメッセージは自身の端末でも確認できる。
特にこれらのメッセージ処理は、サーバや端末に実装された後述する機能構成により実現される。

＜機能構成＞
（１）端末の機能構成
本発明の一実施形態においては、図１に示すように、端末１５１は、制御装置１５１０、並びに、記憶装置１５１５に記憶されたプログラム及びデータにより実現される機能として、トーク参加部１５１１とメッセージ処理部１５１２とを有する。
トーク参加部１５１１は、所望のトークルームへの参加のための処理を行う機能を有している。トークルームへは、個人単位で参加することができるとともに、グループ単位でも参加することができる。

なお、本発明の一実施形態においては、ＢＯＴサーバ（一例として、サーバ１１０、１２０、あるいはこれらと同等のサーバ）を設けることができ、このＢＯＴサーバについても、端末１５１を参照して例示する各機能を備えさせることにより、個人ユーザと同様にトークルームに参加させることができる（このとき、１ユーザとしてのＢＯＴには、人間のユーザと同様に、インスタントメッセンジャーサービスの１アカウントが付与される）。
また、トークルームを新たに生成することもできる。トークルームに参加した状態でメッセージを送信（発言）することで、サーバ１１０等を経由して、同じトークルームに参加している他の参加者端末２および／またはＢＯＴサーバ（トークルームに参加している１ユーザとしてのＢＯＴ）にメッセージが送信される。
なお、ＢＯＴは、ロボットに由来して命名された、人間に替わって作業等を行うコンピュータの総称であり、狭義には、自動チャットを行うプログラムである。
本発明の一実施形態において、ＢＯＴは、１ユーザまたは複数ユーザ、あるいは１以上のユーザが属するグループに紐付けて管理されることもできる。

メッセージ処理部１５１２は、トークルームでのメッセージの生成、送受信および送受信したメッセージの自端末での表示制御等の処理を行う機能を有している。典型的かつ基本的なメッセージ処理及び表示制御例としては、上から下に向かう時間軸に対し、左側に受信メッセージを表示させ、右側に送信メッセージを表示させるというものである。

表示処理部１５１３は、メッセージ処理１５１２が処理したメッセージデータを表示装置１５１８上に表示させる。表示処理部１５１３は、表示用データ（一例として、文字コード）を画素情報（一例として、フォントや絵文字等）に変換し、表示装置１５１８のフレームバッファ（不図示）に書き込む機能を有する。
また、ＢＯＴ処理部１５１４は、後述するサーバ１１０上のＢＯＴ処理部１１１６の一部又は全部の機能を担う。

（２）サーバの機能構成
本発明の一実施形態においては、図１に示すように、サーバ１１０は、制御装置１１１０、並びに、記憶装置１１０５に記憶されたプログラム及びデータにより実現される機能として、トークルーム管理部１１１１とメッセージ処理部１１１２と課金情報管理部１１１３と請求処理部１１１４と統計処理部１１１５とＢＯＴ処理部１１１６と有する。

トークルーム管理部１１１１は、トークルームの参加者等を管理する機能を有している。
メッセージ処理部１１１２は、特定のトークルームにおいて送信されたメッセージを端末１５１から受信した場合に、宛先としての他の参加者端末（例えば、端末１５２、１５３）、及び／または、ＢＯＴサーバ（例えば、サーバ１２０）に同メッセージを送信（転送）する機能を有している。

課金情報管理部１１１３は、課金対象となるメッセージ等の提供等に応じて例えばユーザ（ＢＯＴも含まれる）アカウント課金ための計算処理及び管理を行う。

請求処理部１１１４は、課金情報管理部１１１３で処理及び管理された課金情報に基づいて例えばユーザ（ＢＯＴも含まれる）アカウントごとの請求処理を行う。

統計処理部１１１５は、課金情報処理部１１１３及び／または請求処理部１１１４で処理されたデータをもとに様々な視点からの統計処理を行い保存管理する。

ＢＯＴ処理部１１１６は、ユーザ（人間）に代わって作業や判断、アドバイス等を行う処理を行う。本発明は、これらに限定されるものではないが、より詳細には、適切なデータを検索するための検索部１１１６ａ、送受信メッセージに含まれる言語（音声言語も含まれる）を処理するための言語処理部１１１６ｂ、処理された言語等の意味や価値を判断したり判断した結果の成否等に基づいて学習を行ったりするＡＩ処理部１１１６ｃ、与えられた画像を解析処理したり移り込んだ物体を認識処理等したりする画像処理部１１１６ｄ等の処理モジュールが含まれる。

上述したとおり、ＢＯＴサーバ（一例として、サーバ１１０，１２０、あるいはこれらと同等のサーバ）についても、端末１５１を参照して例示する各機能を備えることにより、個人ユーザと同様の機能を発揮させることもできる（このとき、１ユーザとしてのＢＯＴには、人間のユーザと同様に、インスタントメッセンジャーサービスの１アカウントが付与される）。そして、ＢＯＴサーバが機能させるアシスタントＢＯＴと、人間ユーザとは、人間ユーザ同士が行っているのと同様に、友達関係を結ぶ（アカウント同士を紐付ける）などして互いに所定の関係を築くことができる（かかる所定の関係は、適宜図示しないデータベースや関係テーブルに記述され管理される）。

＜第１実施形態＞
第１実施形態は、サーバ等（一例として、後述する「トークサーバ」）で運営されるトークルームに参加するユーザが端末を介してメッセージの送受信をしたり、トークルーム内でイベントページを作成したり、必要に応じて自身やグループのアシスタント（ＢＯＴ）とのやり取りを行ったり、アシスタント（ＢＯＴ）にやり取りを行わせたり、イベントページにて募ったグループメンバー間における勘定方法を選択したり、メンバー間の支払い処理をしたりするうえでの基本的な動作フローや、トークサーバの基本動作、並びに、トークルームに１ユーザ（１アカウント）として参加するＢＯＴサーバの基本動作について説明するものである（図４Ａ〜図６を参照して後述する）。
なお、第１実施形態に記載された内容の一部又は全部は、その特徴が相互に排他的である場合を除いて他の実施形態にも適用可能である。

図４Ａ〜図６に示される本発明の一実施形態において、基本的にメッセージングサービスを提供するサーバはトークサーバ（図１におけるサーバ１１０等がこれに対応する）が担う。また、本発明の一実施形態において、ユーザ端末と同様に１ユーザ（１アカウント）としてトークルームに参加するＢＯＴサーバ（図１におけるサーバ１１０等がこれに対応する）が導入される。

図４Ａは、本発明の一実施形態に係る情報システムを通じてトークルーム等のメンバーが飲食会等のイベントに参加し、その費用を精算する場合に生じる各処理の概要をまとめた基本動作フローである。図４Ａの前提として、動作フローの開始時にはメンバーの１人（例えば、グループ内のイベントの幹事や当該イベントに参加を希望する他のメンバーなど）がトークルームに適宜入退室する。トークルームでは、必要なメッセージ等がやり取りされる。

図４ＡのステップＳ４０１において、基本的な例示フローを開始すると、ステップＳ４０２進み、一例として幹事ユーザが自身の端末を介してイベントページを作成する。イベントページは基本的にサーバ上に独立して設けることができるが、本発明はこれに限定されることはなく、例えば、トークルームに紐付けて（あるいは、トークルーム内に）イベントページを設けることもできる。以下、本発明の理解の容易のために、イベントページはトークルームに紐付けて設置されるか、あるいは、トークルーム内に設置されるものとする。

ここで、幹事ユーザが自身の端末を介してイベントページを作成するためのイベント登録画面例を図７に示す。図７にはユーザ端末（端末の筺体部分は割愛し、ディスプレイ部分のみ示す。以下、同じ）の画面７００が示されており、画面７００上部には端末ステータス情報７０１が表示されるほか、イベント登録のための書誌事項として、開催日時入力欄７０２、イベント開催会場入力欄７０３、イベント予算入力欄７０４、及び事前参加者リスト作成欄７０５が表示されている。また、図７には示されていないがイベント名を別途入力することも可能である。

幹事ユーザは、図７に例示された画面７００を介してイベント登録を行い、図示しないイベントページをサーバ上等に作成し、トークルームを介した告知等によりイベントへの参加を呼び掛けることができる。

ステップＳ４０３では、前ステップでの処理によりイベント開催の告知等を受け他グループメンバーが当該イベントへの参加表明（あるいは、不参加表明）を行う。こうした、参加／不参加表明もユーザ端末及びトークルームを介して行うことができる。

ここで、グループメンバーが自身の端末を介してイベントへ参加／不参加表明を行うための連絡画面例を図８に示す。図８にはユーザ端末の画面８００が示されており、画面８００上部には端末ステータス情報８０１が表示されるほか、「参加／不参加表明」とのタイトル、イベント名表示欄８０２、イベント開催会場及び開催日時表示欄８０３、及びイベント予算表示欄８０４が表示されている。

グループメンバーは、図８に例示された画面８００を介してイベントへの参加／不参加等を表明する。例えば、予算について同意する／しない等の回答欄８０５、及び参加／不参加回答欄８０６への入力によって意思表明することができる。

より具体的には、予算について同意する場合にはチェックボタン８０５ａを押下し、同意しない場合にはチェックボタン８０５ｂを押下する。また、必要に応じて予算の希望金額入力を行うこともできる。この場合は、ボタン８０５ｃを押下し、図示しない画面にて希望金額の入力を行う。そして、イベントに参加する場合にはチェックボタン８０６ａを押下し、不参加の場合にはチェックボタン８０６ｂを押下する。回答内容は、サーバにアップロードされるなどして記録管理される。

［保証人設定］
本発明の一実施形態においては、例えばイベントへの参加／不参加表明時点で、支払についての保証人設定をすることができる。これは、先輩は後輩が支払いをできない場合にはその費用を持つとか、親は予め子の支払いを持つといった慣例等をシステムに柔軟に反映したものであり、図示しない依頼画面（依頼者側端末）を介した保証依頼、及び図示しない承諾画面（保証人側端末）を介した承諾処理を介して、これらの関係をサーバ等のデータベースまたは管理テーブルに紐付けることができる。
なお、「保証人」設定は、設定元のユーザからみて同じトークルームに登録されているユーザであっても、異なるトークルームに登録されているユーザであっても保証人として設定できる。

図９に、保証依頼を受けた保証人（ユーザ）側の端末上の通知画面例を示す。図９には、保証を依頼されたユーザ端末の画面９００が示されており、画面９００上部には端末ステータス９０１が表示されるほか、通知タイトル「保証許諾可否通知」、イベント名表示欄９０２、イベント開催会場及び開催日時表示欄９０３、及びイベント予算表示欄９０４が表示されている。
また、グループ内の他ユーザからイベント費用支払いの保証依頼があったことを知らせるメッセージ９０５も表示されている。

これを受信したユーザは、回答欄９０６を介して、依頼者の保証人として立替に同意するか否かの回答を行うことできる。具体的には、依頼者の保証人として立替に同意する場合にはチェックボタン９０６ａを押下し、同意しない場合にはチェックボタン９０６ｂを押下する。回答内容は、サーバにアップロードされるなどして記録管理される。

（保証人による立替方式のバリエーション）
なお、保証人としての立替方式には、上述したように、依頼元が支払うことが出来ない場合にその費用を事後的に立替えて支払いをする方式のほか、予め依頼元の費用分もまとめて保証側が支払う方式など種々のバリエーションがあり、こうした種別はフラグ等によってサーバ等にて記憶管理させることができる。

ふたたび図４Ａに戻り、ステップＳ４０３を終えると、図示しない日時に図示しない場所でイベント（食事会や行事、共有スペースでの稽古や練習などであって、各参加者に費用負担が発生する催し）が開催される。もちろん、この間もユーザ同士でトークルームを介したコミュニケーションは行われる。例えば、会場への行き方等の質疑応答であったり、近所に住む者同士が個別に待ち合わせを決めたりするなどである。

ステップＳ４０４ではイベントが終了し、会計作業に入るために一例として幹事が会場にてかかった費用が記載されたレシートや領収書を自端末（図示しないＣＭＯＳカメラ等が備えられている）にて撮影する。本発明はこれに限定されるものではないが、この時点で、費用は代表者（一例として幹事）によって一括カード支払いされるなどして立替えられている。そして、このレシートや領収書には、レストラン等での食事会であれば飲食内容の内訳と合計金額が記載されており、会場をレンタルしてメンバーで稽古等をした場合には会場使用料等の金額が記載されている。一般には印字されてものであるが、手書きのものを排除する趣旨ではない。

本発明の一実施形態において、ユーザ端末（幹事端末など）で撮影されたレシートまたは領収書は文字認識されて数値化され、ユーザ端末及び／またはサーバ上にて記憶管理される。

そして、レシートが複数枚ある場合や、予め不参加者等から寄付をもらっている（出資を受けている）場合には、集計作業が必要となるため、ステップＳ４０５においてユーザ端末及び／またはサーバ上にて総額（参加者が支払うべき金額の合計）の算出処理が行われる。

上記ステップＳ４０５での処理が不要な場合、あるいは、ステップＳ４０４にて総額がすでに判明している場合には、ステップＳ４０５は省略される。

次に、ステップＳ４０６に進み、イベント参加者（つまり、原則として支払い義務がある人）の中で支払い参加者を確定する。イベントに参加していても、先輩や親に費用負担してもらう人は上述した事前処理によって、除かれる。あるいは、イベントには不参加表明していたか、参加／不参加表明していなかった人が飛び入りで参加した人はこの時点で支払い参加者のリストに加えることができる。
こうして、幹事端末等を介して、支払い参加者リストを確定する。確定されたリストはユーザ端末及び／またはサーバ上にて記憶管理される。

ステップＳ４０７では、支払い参加者がどのような配分で支払いを負担するのかについての勘定方法が選択される。一番シンプルな支払方法は、いわゆる割り勘であるが、本発明は種々の支払い方法を分かりやすいインタフェースで柔軟に選択することができる（詳細は、後述する）。

次に、ステップＳ４０８へ進み、各支払い参加者の支払い金額が算出される。算出された結果は、サーバ上で記憶管理されるとともに、各支払い参加者の端末へ通知することができる。

ステップＳ４０９では、各支払い参加者の端末上にて支払い時期・支払方法等の選択受付が行われる。受け付けた内容は、サーバ上で記憶管理される。

ステップＳ４１０では、サーバ上で管理された個々の支払い関係に基づいて、個別に（ユーザ端末を介して）支払い処理が実施される。

図１０に、保証依頼を承諾した保証人（ユーザ）側の端末上の通知画面例を示す。図１０には、保証依頼を承諾したユーザ端末の画面１０００が示されており、画面１０００上部には端末ステータス１００１が表示されるほか、通知タイトル「保証人立替可否問い合わせ」、イベント名表示欄１００２、イベント開催会場及び開催日時表示欄１００３、及びイベント費用立替金表示欄１００４が表示されている。
また、グループ内の保証依頼を承諾した当該他のユーザが所定期間経過しても代金の支払いが未だなされていないことを知らせるメッセージ１００５も表示されている。

これを受信したユーザは、指示欄１００６を介して、依頼者の保証人として立替を実行するか否かの指示を行うことできる。具体的には、依頼者の保証人として立替を実行する場合にはチェックボタン１００６ａを押下し、実行しない場合にはチェックボタン１００６ｂを押下する。これらの指示コマンドは、サーバにアップロードされるなどして記録管理され、適宜図示しない決済サーバとの連携によって決済処理される。

［保証人以外の「友人」に対する支払い遅滞通知］
本発明の一実施形態においては、上述した保証人機能のほかに、支払についての保証はしないが、本人が支払を済ませていないこと（遅滞させていること）を通知する先の「友人」設定をすることができる。これは、メンバーが支払を済ませていない（遅滞させた）まま放置した場合に、当該本人がその事実を知られると困る相手（例えば、親や親友や恋人など）に対して遅滞通知を行うことで、当該本人の支払いまたは返済を促すことを狙ったものである。

かかる「友人」設定は、事前に互いにメンバー同士で設定することもできるし、過去に保証人になってくれた人を当該「友人」設定として引き継がせたり、トークルーム内でのコミュニケーション実績に基づいて特に親しい人同士を互いの遅滞通知先としての「友人」に自動登録したりすることによって、設定することができる。
なお、「友人」設定は、設定元のユーザからみて同じトークルームに登録されているユーザであっても、異なるトークルームに登録されているユーザであっても友人として設定できる。

図１１Ａに、上記遅滞通知先としての「友人」のユーザ端末上の通知画面例を示す。図１１Ａには、上記遅滞通知先のユーザ端末の画面１１００が示されており、画面１１００上部には端末ステータス１１０１が表示されるほか、通知タイトル「ご友人の未払い通知」、イベント名表示欄１１０２、イベント開催会場及び開催日時表示欄１１０３、及びイベント費用未払い金表示欄１１０４が表示されている。
また、当該未払いの友人ユーザが所定期間経過しても代金の支払いが未だなされていないことを知らせるメッセージ１１０５も表示されている。

これを受信した友人ユーザは、回答欄１１０６を介して、当該未払いの友人に自身が未払い通知を受けたことを連絡するか否かの回答を行うことできる。具体的には、未払い通知を受けたことを当該未払いの友人に連絡する場合にはチェックボタン１１０６ａを押下し、連絡しない場合にはチェックボタン１１０６ｂを押下する。これらの指示コマンドは、サーバにアップロードされるなどして記録管理され、例えば、チェックボタン１１０６ａが押下された場合には、サーバから通知を行ったり、あるいは、図示しない当人同士のトークルームへ自動的に移行させるなどして、当人同士が連絡をとれるように制御したりする。

［サーバ上での払い関係の管理等］
これまで説明した保証等の関係は、支払参加者リストに関連付けられ、例えば、図４ＡのステップＳ４０９が終了した時点で次表のとおり、サーバ上で管理されている。

本発明はこれらに限定されるものではないが、上表において、支払い参加者は「氏名（ニックネーム）」及び「会員番号（ＩＤ）」によって管理されている（当該支払い参加者に関する情報はこのＩＤに紐付けられる別テーブル等を参照することにより取得できる。以下、同様）。

「支払い額」欄には、例えば、図４ＡのステップＳ４０８において算出された金額が格納される。「保証人」欄には、上述して設定された保証人（当該支払い参加者の支払いを保証する者）のＩＤが格納される。保証人が存在しない場合にはヌル（null）等が挿入される。「友人」欄には、上述した友人のＩＤが格納される。「保証人への返済義務有無」欄には、保証人に立替えてもらう金額の返済義務の有無（返済要否フラグ）が格納される。この返済要否フラグは、図示しない画面入力欄等を介して保証人設定時等に設定することができる。「支払期限」欄には、支払い参加者による支払期限が格納される。この支払期限も、図示しない画面入力欄等を介して適宜設定することができる。そして、個々の支払期限はサーバによって管理され、この支払期限を過ぎても支払いがなされない参加者に対しては、後述する種々の督促処理がなされる。

図４Ｂは、本発明の一実施形態に係る情報システムを通じて、コミュニケーション手段の基本であるトークルーム等へ入室したり、メッセージを送受信したり、メッセージ受信時にＢＯＴが存在していた場合の処理等をより具体的に例示する基本動作フローである。

図４ＢのステップＳ４２１において、１ユーザ（ＢＯＴではない人間のユーザ）がユーザ端末を介してアプリを起動するなどしてトークルームに入室すると、ステップＳ４２２に進み、トークサーバからユーザ端末に読み込まれるか、あるいは、ユーザ端末それ自体の記憶装置等から読み込まれるかして、アプリを動作させるためのトークリスト等のステータス情報及び／または既読のメッセージ等の情報がユーザ端末内のメモリに読み込まれる。

なお、トークリストは、トークサーバにおいて複数運営されているトークルームのリストであり、一例として、ユーザがメンバーとなっているトークルームについては選択指示等によって当該トークルームに入室し、他のメンバーユーザとのグループトークを行うことができる。グループトークは、トークサーバが提供するメッセージングサービスを介してメンバーがメッセージを交換する（互いに送受信し合う）ことによって進行される。

図４Ｂにおいて、ステップＳ４２３〜ステップＳ４３１までのループは、コミュニケーションのための基本動作ループであり、ステップＳ４３１においてアプリを終了（つまり、トークルームから退出）しない限り、他のメンバーとのメッセージの送受信を継続することができる。また、基本動動作ループ内において、ユーザやグループにアシスタントＢＯＴ（いわゆるＡＩ機能を有するアドバイザープログラムであり、このＢＯＴそれ自体も１アカウントを有するユーザとしてトークルームに参加させることができる）が紐付けられている場合には、このアシスタントＢＯＴからユーザに対してアドバイスを行わせたり、他のユーザからの受信メッセージの少なくとも一部をトークサーバ等へ転送させたりすることができる。
この場合のユーザとアシスタントＢＯＴとの関係は、人間のユーザ同士の関係と同様である。

ステップＳ４２３において、図示しない操作によりユーザからメッセージ等の送信がある（Ｙｅｓ）と、ステップＳ４２４へ進み、トークサーバに対するメッセージ等の送信処理が行われる（ステップＳ４２３において、Ｎｏの場合はステップＳ４２５へ進む）。図４Ｂでは不図示であるが、ステップＳ４２４で送信されるメッセージ等の内容によって処理される基本動作例は次の（１）〜（３）のとおりである。

（１）ユーザ端末からトークサーバへユーザ自身のメッセージが送信された場合
トークサーバでは、受信したメッセージをトークルーム内の他メンバーに送信（転送）する。また、必要に応じて、受信したメッセージに関連する（つまり、受信メッセージに適切な応答が可能な）１以上のＢＯＴ候補を抽出してメッセージ送信元のユーザ及び／またはトークルーム内の他のメンバーに返信させることができる。

本発明の一実施形態において、これらＢＯＴ候補は、ＢＯＴに紐付けられたＢＯＴ＿ＩＤと各ＢＯＴを表わすキャラクタ画像及び／またはＢＯＴの発言であることを表わすメッセージとが含まれる。

（２）ユーザ端末からトークサーバへＢＯＴ＿ＩＤ（上述）が送信された場合
トークサーバでは、指定されたＢＯＴ＿ＩＤに基づいて対応するＢＯＴ（ＢＯＴサーバ）にリクエストを行うこともできる。本発明の一実施形態においては、トークサーバからＢＯＴサーバに対して当該ＢＯＴサーバが現時点で用意している（つまり、その時点でトークルームでの会話の流れに沿って提供可能な）コンテンツ候補のリクエストが行われる。
なお、一実施形態においては、ＢＯＴ＿ＩＤは、ユーザのメッセージとともに送信される場合もある。

（３）ユーザ端末からトークサーバへコンテンツが送信または指定された場合
トークサーバでは、ユーザから送信または指定されたコンテンツ（テキスト／音声情報や画像情報、その他特定サイト等へのリンク先などが挙げられる）をグループ内の他メンバーに送信（転送）する。

ステップＳ４２５において、ユーザに対するメッセージ等の受信がある（Ｙｅｓ）と、ステップＳ４２６へ進み、ユーザ（あるいは当該ユーザが参加しているトークグループ）にアシスタントＢＯＴが存在するか（つまり、紐付けられているか）どうかが判断され、Ｙｅｓの場合はステップＳ４２７ａに進み、メッセージ（ステップＳ４２５で既受信）のうちの一部または全部を選択する。そして、ステップＳ４２７ｂへ進み、アシスタントＢＯＴ経由でトークサーバへ転送され、ステップＳ４２８へ進む（ステップＳ４２６においてＮｏの場合は、直接ステップＳ４２８へ進む）。

なお、ステップＳ４２７ａ〜ステップＳ４２７ｂにおいて、受信メッセージのうちのどの程度のメッセージをアシスタントＢＯＴ経由でトークサーバへ転送させるかは、ユーザによる許可設定によって決まるが、後述する督促ＢＯＴについては非許可設定にはできないように（つまり、必ず許可させるように）運用することができる。

さらに、上記転送のタイミングは、一例として、（１）メッセージを受信するたびに当該メッセージの少なくとも一部をトークサーバへ転送する、（２）受信メッセージを端末上に表示させるたびに当該メッセージの少なくとも一部をトークサーバへ転送する、などのバリエーションを適用することができる。

また、上記転送のタイミングにおいて、受信メッセージの少なくとも一部をトークサーバへ転送する際に、当該一部のメッセージとともに、受信メッセージのうち端末には表示されていないメッセージとを合わせてトークサーバへ転送させるように制御することもできる。

ステップＳ４２８では、受信したメッセージ等がユーザ端末上に表示される。

ステップＳ４２９において、ユーザに対するオブジェクト表示の受信がある（Ｙｅｓ）と、ステップＳ４３０に進み、受信したオブジェクトの端末上での見せ方に関して適宜処理する。そして、ステップＳ４３１へ進む（ステップＳ４２９においてＮｏの場合は、直接ステップＳ４３１へ進む）。

ステップＳ４３１において、図示しないユーザ操作によりトークルーム退室指示がされると本フローとしては終了する（ステップＳ４３２）。ステップＳ４３１においてＮｏの場合は、ステップＳ４２３へ復帰する。

図４Ｃは、主にトークサーバの観点から示された基本動作フローである。
図４ＣのステップＳ４５１において、トークサーバが処理を開始すると、ステップＳ４５２に進み、トークルームを運営するための各種ステータス情報等がサーバ内のメモリに読み込まれる。

図５において、ステップＳ４５３〜ステップＳ４６１までのループは、ユーザ同士のコミュニケーションを運営するトークサーバの基本動作ループであり、トークサーバは、ステップＳ４６１において処理を終了しない限り、メッセージ等（典型的には、ＢＯＴ＿ＩＤが含まれるメッセージと含まれないメッセージとがある。また、ＢＯＴ＿ＩＤのみのメッセージもあり得る）あるいはコンテンツ（コンテンツそれ自体もしくはコンテンツを指定するための指定メッセージが含まれる）の到来を待つ。

ステップＳ４５３では、メッセージ等の受信があったどうかが判断され、Ｎｏの場合はステップＳ４５９へ進むが、Ｙｅｓの場合はさらにステップＳ４５４へ進み、受信したメッセージ等の中にＢＯＴ＿ＩＤが含まれるかどうかが判断される。ステップＳ４５４においてＮｏの場合は他ユーザからのメッセージ等の受信であるため、ステップＳ４５７へ進み、受信したメッセージ内容に沿った応答が可能なＢＯＴ（複数の場合も有り）を抽出または特定するための処理が行われる。一実施形態において、このＢＯＴの抽出または特定処理は、トークサーバからＢＯＴサーバ（群）への問い合わせ及び応答によって実現される。

そして、ステップＳ４５８では、前ステップで抽出または特定されたＢＯＴ候補をトークグループ内の他ユーザに送信し、ステップＳ４５９へ進む。
なお、ステップＳ４５７及びステップＳ４５８は、必須のステップではなく、適宜省略できる。

一方、ステップＳ４５４においてＹｅｓの場合は、典型的には受信したメッセージが（既に提示済の）ＢＯＴ候補に対する指定であるため、ステップＳ４５５へ進み、指定された特定のＢＯＴ（サーバ）に対し、コンテンツまたはコンテンツ候補のリクエストを送信する。次に、特定のＢＯＴ（サーバ）からコンテンツ候補が送信されてきた場合にはステップＳ４５６にて受信したコンテンツ候補をメッセージ送信元のユーザ端末へ送信するとともに、このユーザ端末を介して（あるいはこのユーザ端末を介することなく）上述のコンテンツ候補を他ユーザの端末にも送信し、コンテンツのリアルタイム共有を実現する。そして、ステップＳ４５９へ進む。

ステップＳ４５９では、コンテンツそれ自体あるいはコンテンツへの指定メッセージの受信があったかどうかが判断され、Ｙｅｓの場合はステップＳ４６０へ進み、コンテンツをグループ内の他ユーザへ送信する（ステップＳ４５９において、Ｎｏの場合はステップＳ４６１へ進む）。このとき、受信したメッセージがコンテンツへの指定メッセージ（一例として、ＵＲＬの特定によって入手可能なコンテンツ情報）である場合には必要に応じてトークサーバにおいて当該コンテンツを取得してこれをグループ内の他ユーザへ送信する。そして、ステップＳ４６１へ進む。

ステップＳ４６１では、トークサーバとしての動作を終了するかどうかが判断され、図示しない操作によりトークサーバの動作を終了する（ステップＳ４６１においてＹｅｓ）場合には、ステップＳ４６２へ進み、本フローとしては終了するが、ステップＳ４６１においてＮｏの場合には、ステップＳ４５３へ復帰する。

［支払い等の勘定フローを実行するための機能モジュールのまとめ］
図５に、本発明の一実施形態に係るシステム等における動作の機能概念を示す。特に、図２〜図４Ｃを参照して説明した各機能は、図１における制御装置１１１０（サーバ側）及び制御装置１５１０（端末側）での拡張された処理部を要求するものであるので、ここでは、それぞれの機能について説明する。

これまで説明したとおり、本発明の一実施形態に係るシステム等は、大きくは幹事者端末上での集金ＵＩ等提供機能５１０と参加者・保証人、その他の友人等の端末上での集金ＵＩ提供機能５２０とを含むものであるが、これらは適宜サーバ１１０等と連携あるいは同期され（これに伴い、幹事者端末と参加者等端末とが連携され）、それぞれの機能の実体は、記憶装置１１０５及び１５１５に記憶された各種プログラム及び各種データが、制御装置１１１０及び制御装置１５１０に適宜読み込まれて実行される諸機能として実現されるものである（以下に述べる下位機能についても同じ）。

図５において、幹事者端末上での集金ＵＩ等提供機能５１０は、大別すると、既に述べたとおり、領収書等の読み取り機能、金額確認（集計）機能、割り勘方法等選択機能、各種算出機能、各種通知機能を含むものであるが、より詳細には、集金リスト作成ＵＩ提供機能５１１と集金ＵＩ提供機能５１２とに区分され、それぞれ次表のとおりのサブ機能を有する。

また、参加者等端末上での集金ＵＩ等提供機能５２０も、大別すると、既に述べたとおり、領収書等の読み取り機能、金額確認（集計）機能、割り勘方法等選択機能、各種算出機能、各種通知機能を含むものであるが、より詳細には、参加者機能５２１と保証人機能５２２とに区分され、それぞれ次表のとおりのサブ機能を有する。

＜第２実施形態＞
第２実施形態は、複数のユーザ端末（一例として、幹事端末及び参加者端末Ａ〜Ｃ、参加者となる場合もある保証人端末、友人端末）の間の支払いやメッセージ等のやりとりをシステム全体の運用シーンとして説明するものである。トークルームの説明でも明らかなように、ユーザ端末間のメッセージ交換においてもサーバが関与するが、ここでは理解の容易のためにサーバの存在を割愛している（実際には、サーバは適宜関与する）。
なお、第２実施形態に記載された内容の一部又は全部は、その特徴が相互に排他的である場合を除いて他の実施形態にも適用可能である。
また、実施形態において例示される動作または処理時刻（ｔ１等）は、本発明の概念の理解の容易のために例示されたものであり、本発明が実施形態において例示される個別の時系列関係に制限されることはない（以下、時刻を明示して例示している実施形態において同様である）。また、人同士のやり取りのように記載されているところは、それぞれが所持する端末同士のやり取り、あるいは、サーバを介した端末同士のやり取りである。
以下、図６を参照して説明する。

図６に示される本発明の一実施形態において、時刻ｔ１までに幹事端末上でイベントページが作成され、予め招待する参加者リスト（事前参加者リスト）が作成されるなどして、招待メンバー（Ａ〜Ｃ）に対してイベント参加ＵＩが発信される（ステップＳ６０１）。次に、時刻ｔ２には、それぞれの端末からイベント参加表明が返信される（ステップＳ６０２）。なお、図６の時刻ｔ２においては、説明の便宜上、イベント参加表明を表わす矢印は１本のみであるが、複数の参加者の返信があるものとする（以下、後述する通知や支払等の各処理について、ステップＳ３０５で説明するような特段の断りがある場合を除き、同様）。

時刻ｔ３〜ｔ４まで、図示しない会場にてイベントが実施される。本発明の一実施形態において、参加者は自身の端末を持参してこのイベントに参加している。

次に、時刻ｔ５までにイベントに際して発生した費用につき、幹事から参加者へ支払い依頼が行われる（ステップＳ６０３）。本発明はこれに限定されるものではないが、ここでは、幹事がいったん一括立替支払いをする（そして、その後各参加者に請求する）こともできるし、幹事が一括支払いするために各端末から費用を徴収する（そして、その後一括支払いする）ように処理を進行させることもできる。

時刻ｔ６には、参加者Ａ〜Ｃより各自の端末から幹事端末へ支払い方法や支払時期（支払期限）についての通知がなされる（ステップＳ６０４）。これらの情報はサーバにも記録管理させることができる（以下、端末同士でやり取りされる情報について、同様）。
そして、ここからは、発明の理解のために参加者Ａ〜Ｃの対応（及び、参加者Ａ〜Ｃへの対応）を異ならしめており、それらの前提のもとに説明を続ける。

［参加者Ａの対応］
時刻ｔ７には、参加者Ａより幹事への支払いが行われる（ステップＳ６０５）。本発明の一実施形態においては、参加者Ａの端末より幹事端末へ電子バリューの送金（送信または移動）がなされるものであるが、本発明はこれに限定されるものではなく、最終的に決済等が行われるために必須となる情報処理であればよい。

［参加者Ｂ等への対応］
時刻ｔ８〜時刻ｔ１２までは、参加者Ｂ及び参加者Ｂの保証人への対応例を示す動作フローである。時刻ｔ８は、時刻ｔ６から既に所定期間が経過している。具体的には、参加者Ｂの幹事への支払い期限が（場合によっては大幅に）過ぎているなどである。時刻ｔ８では、まず、幹事から参加者Ｂへの支払いの督促通知が行われる（ステップＳ６０６）。この督促通知の発信元は必ずしも幹事端末である必要はなく、サーバの期限管理に基づいてサーバ主体で行われてもよい（以下、通知等の主体について同様）。

時刻ｔ９は、時刻ｔ８からさらに所定時間経過しているか、あるいは、時刻ｔ８の直後であってもよい。時刻ｔ９には、幹事端末（あるいは、サーバ）から参加者Ｂの保証人の端末に対し、参加者Ｂの未払い通知が行われる（ステップＳ６０７）。その通知画面例は、図示しないシンプルな未払い通知であっても良いが、本発明はこれに限定されることはなく、図１０を参照して例示したような立替可否問い合わせ通知であってもよい（本動作フローでは、保証人への立替可否問い合わせ通知とする）。
また、保証人への立替可否問い合わせ通知に先だって上述の未払い通知を行うようにしてもよい。

なお、ステップＳ６０６及びステップＳ６０７のアプリケーションとしての通知主体は、既述のＢＯＴによるものとしてもよい（いわゆる督促ＢＯＴによる督促処理）。
この場合、ＢＯＴには、ステップＳ６０６やステップＳ６０７における督促先及び／または通知先ユーザの不許可設定を乗り越えて督促及び／または通知を行わせることができる（督促先及び／または通知先ユーザの不許可設定により、当該ＢＯＴの連絡等が拒否されてしまうことを防止するためである）。

時刻ｔ１０には、参加者Ｂの保証人が参加者Ｂの費用の立替支払に同意し、保証人から幹事への立替支払処理がなされる（ステップＳ６０８）。これに限定されるものではないが、具体例として電子バリューによる支払いが行われる。

時刻ｔ１１には、参加者Ｂの保証人から参加者Ｂへの立替支払通知が行われ（ステップＳ６０９）、時刻ｔ１２には、参加者Ｂから参加者Ｂの保証人への支払い（いわゆる返済）が行われる（ステップＳ６１０）。本発明の一実施形態として、ステップＳ６１０にて返済が行われるのは、参加者Ｂと参加者Ｂの保証人との間の保証関係が立替時の返済義務ありとして登録あるいは設定されているからである。両者の間で返済義務なしの保証関係が結ばれている場合には、ステップＳ６１０は不要であり省略される。

［参加者Ｃへの対応］
時刻ｔ１３〜時刻ｔ１４までは、参加者Ｃ及び参加者Ｃの友人への対応例を示す動作フローである。時刻ｔ１３は、時刻ｔ６から既に所定期間が経過している。具体的には、参加者Ｃの幹事への支払い期限が過ぎているなどである。時刻ｔ１３では、まず、幹事から参加者Ｃの友人への未払い通知が行われる（ステップＳ６１１）。この未払い通知の発信元は必ずしも幹事端末である必要はなく、サーバの期限管理に基づいてサーバ主体で行われてもよい（以下、同様）。そして、参加者の友人への未払い通知の通知画面例は、図１１Ａを参照して説明したとおりである。

時刻ｔ１４には、参加者Ｃの友人が参加者Ｃへ支払いの督促を行う（ステップＳ６１２）。参加者Ｃは、幹事から督促されるよりも親しい友人に督促されるので、早急に幹事への支払いを行うことが期待される。

なお、ステップＳ６１１及びステップＳ６１２のアプリケーションとしての通知主体は、既述のＢＯＴによるものとしてもよい（いわゆる督促ＢＯＴによる督促処理）。
この場合、ＢＯＴには、ステップＳ６１１やステップＳ６１２における督促先及び／または通知先ユーザの不許可設定を乗り越えて督促及び／または通知を行わせることができる（督促先及び／または通知先ユーザの不許可設定により、当該ＢＯＴの連絡等が拒否されてしまうことを防止するためである）。

特に、図１１Ｂに、ＢＯＴによる第三者通知のバリエーションを行った場合の通知画面例を示す。図１１Ｂには、トークルームでのコミュニケーションを行っているユーザ端末の画面１１５０が示されており、画面１１５０上部には端末ステータス１５０１が表示されるほか、トークルーム画面内に種々のメッセージが時系列（上から下への流れ）で表示されている。

このトークルーム画面において、メッセージ１１６１、１１６２は、当該画面を表示しているユーザ端末以外のユーザ端末から送られてきたものであり、メッセージ１１６３、１１６４は、当該画面を表示しているユーザ端末から発信されたものである。
そして、メッセージ１１７０、１１８０は、上述のメッセージやり取りの流れを判断してＢＯＴが未払い者●●への督促あるいは通知を行うメッセージとなっている。

本発明の一実施形態として、メッセージ１１７０、１１８０が発生する条件は、次のようなものが考えられる。
（１）未払い者の支払い期限が経過してさらに一定の期間が経過したこと。
（２）トークルームに未払い者あるいは未払い者の友人もしくは保証人が参加中であること。

なお、図１１Ｂにおいては、立替の返済義務ありの場合の督促通知例を示したが、本発明はこれに限定されることはなく、立替の返済義務なしの場合の御礼督促通知をＢＯＴに行わせることもできる。この場合、メッセージ１１７０は「そういえば、●●さんは、△△さんに立替えてもらったお礼をまだ言ってないよ〜」などとなり、メッセージ１１８０は「●●さん！△△さんにお礼をいわなきゃ」などとされる。こうした御礼督促もソーシャルメッセージングにおけるマナー向上に寄与するものとなる。
もちろん、立替の返済義務なしの場合には、特にＢＯＴに督促通知を行わせないように運用することもできる。

＜第３実施形態＞
第３実施形態は、第三者からグループへ送金する本発明のバリエーションを説明するものである。このバリエーションによれば、例えば、イベントには参加しないが資金の提供（寄付）はしたいというグループ内外の第三者から、当該グループ（あるいは、イベントに参加するメンバーで構成されるサブグループ）への送金を実現することができる。また、本実施形態の送金方法は、近年普及しつつある電子紅包（情報処理端末を介して電子マネーを贈るオンラインお年玉）にも応用可能である。
なお、第３実施形態に記載された内容の一部又は全部は、その特徴が相互に排他的である場合を除いて他の実施形態にも適用可能である。

図１２に、基本動作フローを示す。図１２のステップＳ１２０１にて図示しない端末画面を介して送金予約設定処理が開始されると、ステップＳ１２０２へ進み、送金先グループが設定される。本発明の一実施形態においては、送金は自動的に行われ、そのための送金条件は、後続するステップＳ１２０３にて図示しない設定画面を介して設定される。

また、本発明の特徴として、送金先は複数の個人宛に設定できるのみならず、グループ単位でも設定することができる。複数の個人宛に設定した場合は、当該設定後の送金先は固定されてしまうが、グループ単位で設定した場合には、当該設定後にグループの構成メンバーが変化した場合にも送金が実施された時点での構成メンバーへの送金が可能となる（なお、ここでいう送金は、ここまで説明してきた電子バリューの送信あるいは端末間移動と同様の趣旨である。以下、同じ）。

このようなグループ単位での送金先設定ができることで、上述したイベント参加型のグループに対して出資や寄付をする場合にも、イベント開始にあたって、または、終了時に確定した参加メンバーに対して、正確かつ確実に出資あるいは寄付できることとなる。

ステップＳ１２０３では、送金条件が設定される。条件の設定は、送金タイミング及び送金時の分配について設定することができる。本発明はこれらに限定されるものではないが、送金タイミングについては、次のようなものが挙げられる。
（１）グループが取り組んでいる何らかの行事が完了したとき。
（２）送金者（または受信者）の取り組み（試験や競技など）でいい結果が出た時。

また、送金時の分配については、次のようなものが挙げられる。
（１）グループの代表者に預ける。
（２）グループメンバーへ均等割り。
（３）グループが取り組んでいる行事での各メンバーの達成度に応じて分配。

以上の送金条件設定が完了すると、ステップＳ１２０４へ進み、送金予約設定処理は完了する。

図１３に、図１２を参照して説明した送金（予約）者による送金予約設定が完了したあとに、サーバ（あるいは送金サーバ）側でどのような処理が行われるかを示す。

ステップＳ１３０１では、図１２において設定された送金条件（のうち、送金タイミングに関する条件）に基づき、イベントトリガあるいはイベントハンドラが開始されると、ステップＳ１３０２へ進み、送金条件（あるいは支払い条件）を見たすイベントが発生したかどうかが判断される。ステップＳ１３０２においてＮｏの場合は再びステップＳ１３０２へ戻る（いわゆるイベント待ちの状態となる）が、Ｙｅｓの場合はステップＳ１３０３へ進む。

ステップＳ１３０３では、送金先グループ情報が読み出される。このとき、この時点で所属しているメンバーが読み出されるので、あるグループにおいて特定のイベント参加グループを募った場合の特定参加グループへの送金は、この時点での参加者に対して割り振られることとなる。あるいは、本発明の他の実施形態として、常にグループ全体への積立金のように送金されてもよい。

ステップＳ１３０４では、送金対象となるグループのメンバーに対する送金割り当て処理が行われ、ステップＳ１３０５において、グループメンバーに対する送金処理が実施される。このとき、必要に応じて送金元（送金者）へ送金完了通知が行われてもよい。
そして、ステップＳ１３０６へ進み、送金処理は完了する。

＜第４実施形態＞
第４実施形態は、図６のステップＳ６０３における支払依頼のバリエーション例であり、集金開始から割り勘処理あるいは分担支払い処理までを詳細に説明するものである。以下、図１４を参照して説明する。
なお、第４実施形態に記載された内容の一部又は全部は、その特徴が相互に排他的である場合を除いて他の実施形態にも適用可能である。

図１４のステップＳ１４０１において処理を開始すると、ステップＳ１４０２へ進み、幹事端末においてイベント参加者の読み出しが行われる。この読み出しは、トークルームの登録メンバーを幹事端末において読み出させることとしても良いが、本発明は必ずしもこれに制限されることはなく、サーバ上で管理される何らかのグループに登録されたメンバーを読み出すように運用することもできる（つまり、第４実施形態以降の実施形態においては、イベント参加は必ずしもトークルームに登録されたメンバーである必要はない）。
なお、本発明の他の実施形態においては、本ステップは省略可である（この場合、ステップＳ１４０１からステップＳ１４０３へスキップする）。

ステップＳ１４０３では、幹事端末からその場（イベント会場など）に居合わせている参加者端末への支払いの呼び掛けが行われる。本発明の一実施形態においては、近接無線通信（ＮＦＣ）を使った集金通知が行われてもよい。

ステップＳ１４０４では、幹事端末において、集金通知を受けた参加者端末からの支払い応募を待つ（ステップＳ１４０４においてＮｏとなり、本ステップへ復帰するループ）。本発明の一実施形態においては、参加者端末の支払い応募は、近接無線通信（ＮＦＣ）によって行われる（伝達される）。あるいは、自端末をシェイク（Shake）することによって行われる（伝達される）。ここで、シェイク動作は、端末に内蔵された加速度センサ等によって端末の揺れとして検知され、これを集金通知への肯定的な応答とすることができる。
その他、参加者端末の支払い応募は、他の手段（音波、磁気による伝達手段）によって伝達されてもよい。
ステップＳ１４０４でＹｅｓとなれば、ステップＳ１４０５へ進む。

ステップＳ１４０５では、支払い応募者（支払いに応じる者）を支払メンバーに追加する。そして、ステップＳ１４０６へ進み、支払い応募（呼び掛け）を終了するかどうかが判断される。この判断は、呼び掛けた参加者全員の応答を待って終了するという基準を採用してもよいし、一定数以上の応募を以って幹事者端末側で打ち切ることとしてもよい。ステップＳ１４０６でＮｏの場合は、ステップＳ１４０４へ復帰するが、Ｙｅｓの場合はステップＳ１４０７へ進む。

ステップＳ１４０７では、支払メンバー内での支払い額の分担調整が行われる。本発明の一実施形態においては、均等割り処理が実施されるが本発明はこれに限定されることはなく、種々の調整が可能である。さらなるバリエーションについては、図１５等を参照して詳述する。

ステップＳ１４０８では、支払メンバー間あるいは支払メンバーとその他の参加者メンバーとの間での調整処理が行われる。例えば、支払メンバーＤ、Ｅ、Ｆがいたとして、ＤがＥ及びＦの分を立替えた場合には、後日Ｅ及びＦはＤへ立替え分を返済する。あるいは、先輩が立替えた分（一例として１００００円）の何割かは後日後輩達が支払う（一例として、一律１０００円）などである。

以上の処理を経て、本フローとしては終了する（ステップＳ１４０９）。

＜第５実施形態＞
第５実施形態は、ユーザ端末上での画面表示例にフォーカスして本発明の一実施形態における特徴を説明するものである。以下、図１５〜図１９を参照して説明する。
なお、第５実施形態に記載された内容の一部又は全部は、その特徴が相互に排他的である場合を除いて他の実施形態にも適用可能である。
特に、ユーザインタフェースに特化した第５実施形態は、必ずしもユーザ端末間あるいはサーバを介した電子バリューの送受信を伴う必要はなく、現金でのやり取りを行う際の割り勘アプリ、あるいは「見える費用負担調整アプリ」として様々なアプリケーションに採用することができる。

図１５（Ａ）に示される本発明の一実施形態において、端末１５００（筐体部等は不図示）の表示画面上には、端末ステータス１５０１が表示されるほか、友人あるいはイベント参加者リスト表示欄１５０２が表示されている。表示欄１５０２に該当者を表示させるためには、図１４において説明した呼び掛け及び（シェイク等による）応募を行ってもよいが、図１５（Ａ）の画面では必ずしもそれらは必要なく、既に登録されている友人リストやイベント参加者リストを端末上に呼び出す（読み出す）だけで足りる。
図１５（Ｂ）に表れたＭ１〜Ｍ９がそのリストである。Ｍ１〜Ｍ９は、個々の友人あるいはイベント参加者を表わす。

図１５（Ｂ）には、端末１５１０の表示画面上に、端末ステータス１５１１のほか、友人あるいはイベント参加者リスト表示欄１５１２に読み出された友人あるいはイベント参加者Ｍ１〜Ｍ９が表示されており、同画面上に「支払者をチェックして下さい」と案内されるように、この画面上で幹事等は支払いを行う者をタップするなどして指定することができる。この場合、食事会などのイベントの会場（レストラン等）では、幹事が実際に声をかけるなどして支払いに応募する者を確認すれば足りるので、必ずしも上述したＮＦＣ等による通信は必要ない（もちろん、ＮＦＣ通信等によって確認をとってもよい）。

本発明の一実施形態においては、Ｍ１〜Ｍ３、Ｍ５、Ｍ６が支払いに応じたので、表示欄１５１２中の参加者マーク（丸印）がそれぞれタップ等されてチェック印が入っている。

図１６に示される本発明の一実施形態においては、端末１６００の画面上に端末ステータス１６０１が表示されるほか、友人あるいはイベント参加者リスト表示欄１６０２が表示されている。説明の便宜上、図１５の続きとして説明をすると、表示欄１６０２には支払いに応じた参加者Ｍ１〜Ｍ３、Ｍ５、Ｍ６がチェック印入りで表示されている。ここでは、それぞれの支払い割合（支払額の分担）を決めるためのインタフェースが提供されている。

図１６においては、まず、図示されない選択メニューによって支払い割合の種別を決定する。一例として、次のようなものがある。
（１）均等割り
（２）段階負担（図１６に示されるような３段階負担など）及び段階数
（３）上記（２）の場合の各段階の金額（図１６に示されるように、１００００円、５０００円、３０００円など）

図１６においては、例示的に、上記（２）及び（３）での選択がなされ、３段階による負担が決定される。各段階の負担額は、大きい金額から１００００円、５０００円、３０００円となっている。かかる選択がなされると、一実施形態においては、同図に示されるように負担額アイコン（支払額エリアともいう）１６０５〜１６０７が表示される。

次に、支払に応じた参加者Ｍ１〜Ｍ３、Ｍ５、Ｍ６がそれぞれいくらの負担をするのかを決定するために、ドラックアンドドロップあるいはフリック操作等によって各人のアイコンを負担額アイコンへ移動させる。一実施形態において、同図では、Ｍ１は１００００円の負担となったのでＭ１アイコンは支払額エリア１６０５へ移動され、Ｍ２は５０００円の負担となったのでＭ２アイコンは支払額エリア１６０６へ移動され、Ｍ３は３０００円の負担となったのでＭ３アイコンは支払額エリア１６０７へ移動される（Ｍ５、Ｍ６についても負担額が決まった時点で移動される）。

なお、段階負担による負担額を決定する際には、負担額の一番少ない枠に総額のうちの端数を含めることができる。また、予め第三者等から出資あるいは寄付をもらっていた場合には、この時点で総額から予め出資分あるいは寄付分を指し引いてから負担割合決定処理を開始させることもできる。

図１７に、支払いに応じた者の間での支払額の他の決定方法を示す。同図には、端末１７００の画面上に端末ステータス１７０１が表示されるほか、友人あるいはイベント参加者リスト表示欄１７０２が表示されている。同図は、説明の便宜上、図１６と関連付けて（支払者が同じになるように）表現されているが、図１５の続きとして理解することもできる。

図１７（Ａ）には、表示欄１７０２に支払い者Ｍ１〜Ｍ３、Ｍ５、Ｍ６のアイコンが表示されているが、ここでは支払額を決定する前あるいは後に、次の操作によって負担者の調整処理を行うことができる。
（１）他の負担者の分も併せて負担する場合には、負担してもらう側の負担者アイコンを負担する側のアイコンに重ねる。
（２）上記（１）の操作は複数回（重ねて）実行できる。
なお、上記（１）や（２）の操作を統合操作あるいは総合処理ともいう。

図１７（Ａ）においては、例示的に、Ｍ１がＭ２、Ｍ５、Ｍ６の分も一緒に負担することとなったので、まず、Ｍ２アイコンがドラックアンドドロップあるいはフリック操作によってＭ１アイコン上に重ねられ、続いて、Ｍ５、Ｍ６アイコンがそれぞれＭ１アイコン上に重ねられる（それぞれ、統合される）。

そうすると、図１７（Ｂ）に示されるように、表示欄１７１２上には、実際の支払い者（支払窓口）として、Ｍ１とＭ３とが残り、Ｍ１アイコンの中には、Ｍ２、Ｍ５、Ｍ６の３人分の立替が含まれているという意味で、Ｍ１本人分と合わせて４人分を表わす「４」の数字が表示される。

サーバ等で管理される管理テーブルに対しても、データ構成上、図示しないレコードあるいはサブテーブルが拡張され、Ｍ１がＭ２、Ｍ５、Ｍ６の分も立替える旨（あるいは、Ｍ２、Ｍ５、Ｍ６は、それぞれＭ１に負担してもらう旨）のレコード等が追記される。
なお、１７１０、１７１１は、それぞれ１７００、１７０１に対応する。

図１８に、友人あるいはイベント参加者リストから無料の者（支払いを免除される者）を簡単に除外する操作方法を示す。なお、図１８に示されたインタフェース機能は、いったんは支払いに応じた者を除外または免除する操作としても使用できる。

同図には、端末１８００の画面上に端末ステータス１８０１が表示されるほか、友人あるいはイベント参加者リスト表示欄１８０２が表示されている。そして、表示欄１８０２には、メンバーＭ１〜Ｍ９のアイコンが表示されている。本発明の一実施形態において、ここから無料の者（支払いを免除される者）を除外するためには、該当者を所定の枠（図１８における枠１８０３）の外にドラックアンドドロップあるいはフリック操作すればよい。

本発明の一実施形態において、Ｍ４、Ｍ７〜Ｍ９が無料の者とされたので、それぞれのアイコンは、枠１８０３の外にフリックされている。この結果、管理テーブル上は、Ｍ４、Ｍ７〜Ｍ９の当該イベントの負担金額としてはゼロとして記録管理される。

図１９（Ａ）に、支払いに応じた者の支払いの進捗率を直観的に視認しやすいように構成したインタフェース例を示す。同図（Ａ）には、端末１９００の画面上に端末ステータス１９０１が表示されるほか、友人あるいはイベント参加者リスト表示欄１９０２が表示されている。そして、表示欄１９０２の中には、支払いに応じた者Ｍ１〜Ｍ３、Ｍ５、Ｍ６、及び支払完了確認枠１９０３が表示されている。
この支払完了確認枠は、支払いに応じる者の支払い状況を確認可能な確認領域である。

本発明の一実施形態においては、実際に支払いが終わった者については、該当アイコンを枠１９０２の中に順次フリックさせる。

そうすると、総額に対して集金できた達成率を同図（Ｂ）〜（Ｄ）のように視覚的に表示させることができる。同図（Ｂ）は総額に対して３０％徴収できた状態、同図（Ｃ）は総額に対して５０％徴収できた状態、同図（Ｄ）は１００％徴収できた状態を示す。
なお、本発明の一実施形態において、同図（Ｂ）〜（Ｄ）は、支払に応じる者の負担割合に応じた面積（あるいは、その時点での支払額合計）を表わす。その意味で、同図（Ｄ）に表された「１００％ Ｃｏｍｐｌｅｔｅ」の表示領域は、支払に応じる者の負担割合の合計に応じた面積であり、確認領域の総面積に一致する。

このように、図１９（Ａ）及び（Ｂ）に示されたインタフェースを採用することで、慌ただしい飲食店での集金会計もスムースに進行させることができ好適である。この場合、支払い方式はこれまで説明した電子バリューの端末間移動であってもよいし、あるいは現金でやり取りする場合であってもよい。いずれの場合においても、費用割合の分担や徴収がしやすくなるという効果を奏する。

本開示の実施形態を諸図面や実施例に基づき説明してきたが、当業者であれば本開示に基づき種々の変形や修正を行うことが容易であることに注意されたい。従って、これらの変形や修正は本開示の範囲に含まれることに留意されたい。例えば、各手段、各ステップ等に含まれる機能等は論理的に矛盾しないように再配置可能であり、複数の手段やステップ等を１つに組み合わせたり、或いは分割したりすることが可能である。また、各実施形態に示す構成を適宜組み合わせることとしてもよい。

１００、２００ 情報処理システム
１１０、１２０ 情報処理装置（サーバ）
１５１、１５２、１５３ 情報処理端末
１９９ ネットワーク
２１０ 情報処理サーバ
２２０、２３０ ＰＣ（情報処理端末）
２４０ 携帯電話（情報処理端末）
２５０、２５１、２５２ タブレット（情報処理端末）
２６０、２７０、２８０，２９０ ネットワーク

Claims (10)

1. サーバ上で管理されるトークルームを介して会話可能に構成された第１情報処理端末に対応付けられた第１ユーザと、前記第１情報処理端末と前記トークルームを介して会話可能に構成された１以上の第２情報処理端末に対応付けられた１以上の第２ユーザとの間で支払いの調整を行うためのプログラムであって、
   前記第１情報処理端末に、
   前記第２情報処理端末への支払い依頼を要求させるステップと、
   前記第２情報処理端末からの応答を受信させるステップと、
   前記第２情報処理端末からの応答の受信によって、前記第２情報処理端末に対応付けられた１以上の第２ユーザの支払い方法及び支払期限を前記サーバに管理させるよう要求させるステップと、を実行するプログラム。
2. 前記支払いの調整が行われる際には、前記第１情報処理端末に前記支払いの総額が記載されたレシートを読み取らせた後、前記第２情報処理端末への支払い依頼を要求させるステップをさらに実行する、
   請求項１に記載のプログラム。
3. 前記第２情報処理端末への支払い依頼を要求させるステップにおける支払依頼額は、前記総額を前記第１情報処理端末と前記第２情報処理端末の数の総和で割ったものである、
   請求項１に記載のプログラム。
4. 前記第２情報処理端末への支払い依頼を要求させるステップにおける支払依頼額は、前記第１情報処理端末の支払い額と異なる、
   請求項１に記載のプログラム。
5. 前記第２情報処理端末への支払い依頼を要求させるステップにおける前記支払い依頼要求先となる前記第２情報処理端末は、前記第１情報処理端末が調整する支払い参加者の端末である、
   請求項１に記載のプログラム。
6. 前記第２情報処理端末への支払い依頼を要求させるステップにおける前記支払い依頼要求先となる前記第２情報処理端末は複数であり、前記第２情報処理端末への支払い依頼額は不均等である、
   請求項５に記載のプログラム。
7. 前記サーバは、前記第１情報処理端末に、前記支払期限を経過した前記第２情報処理端末に対応付けられた第２ユーザに支払督促を要求させるステップをさらに実行する、
   請求項１に記載のプログラム。
8. 前記第１情報処理端末は、前記サーバに、前記支払期限を経過した前記第２情報処理端末に対応付けられた第２ユーザに支払督促を要求させるステップをさらに実行する、
   請求項１に記載のプログラム。
9. 前記第２情報処理端末からの応答は、当該第２情報処理端末と前記第１情報処理端末との間の近接無線通信によって伝達される、
   請求項１に記載のプログラム。
10. 前記第２情報処理端末からの応答は、前記第２のユーザによる前記第２情報処理端末に対するシェイク動作によってなされる、
    請求項１に記載のプログラム。