ホーム > 特許ランキング > ＬＩＮＥ Ｐａｙ株式会社
知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-10-18
(45)【発行日】2024-10-28
(54)【発明の名称】情報処理プログラム、方法、装置、及びシステム
(51)【国際特許分類】
G06Q 20/10 20120101AFI20241021BHJP
【ＦＩ】
G06Q20/10 300
【請求項の数】
9
(21)【出願番号】P 2022171838
(22)【出願日】2022-10-26
(62)【分割の表示】P 2017214764の分割
【原出願日】2017-11-07
(65)【公開番号】P2023002761
(43)【公開日】2023-01-10
【審査請求日】2022-11-24
(73)【特許権者】
【識別番号】518179254
【氏名又は名称】ＬＩＮＥ Ｐａｙ株式会社
(74)【代理人】
【識別番号】100093687
【弁理士】
【氏名又は名称】富崎 元成
(74)【代理人】
【識別番号】100168468
【弁理士】
【氏名又は名称】富崎 曜
(74)【代理人】
【識別番号】100166176
【弁理士】
【氏名又は名称】加美山 豊
(74)【代理人】
【識別番号】110001759
【氏名又は名称】弁理士法人よつ葉国際特許事務所
(72)【発明者】
【氏名】久保 渓
(72)【発明者】
【氏名】佐藤 良男
(72)【発明者】
【氏名】岡田 知拓
(72)【発明者】
【氏名】房安 陽平
【審査官】青柳 光代
(56)【参考文献】
【文献】特表２０１７－５３１８６６（ＪＰ，Ａ）
【文献】特開２０１５－０５６７２０（ＪＰ，Ａ）
【文献】特開２０１７－１５１９８７（ＪＰ，Ａ）
【文献】特開２００７－１７２３５８（ＪＰ，Ａ）
【文献】特開２００８－１０７８７４（ＪＰ，Ａ）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｇ０６Ｑ １０／００ － ９９／００
(57)【特許請求の範囲】
【請求項1】
第１ユーザと第２ユーザとが参加するトークルームに表示される情報に関する処理を行うサーバによって実行されるプログラムであって、前記第２ユーザに支払を依頼する第１金額と、前記第１金額の第１支払期限とを、前記サーバの制御部によって取得することと、
前記第１金額の支払を依頼する第１表示を前記トークルームに表示させるための第１制御を前記制御部によって実行することと、
前記第１支払期限に前記第１金額が支払われなかったことに基づいて、前記第１金額の支払いを督促する第２表示を前記トークルームに表示させるための第２制御を前記制御部によって実行することと、を含むプログラム。
【請求項2】
請求項１に記載のプログラムであって、前記第２ユーザが前記第１支払期限に前記第１金額を支払わなかったことに基づく情報を、前記第１ユーザの端末から前記制御部によって取得したことに基づいて、前記第２制御を前記制御部によって実行するプログラム。
【請求項3】
請求項１に記載のプログラムであって、前記第２ユーザが前記第１支払期限に前記第１金額を支払わなかったことを前記制御部によって判定したことに基づいて、前記第２制御を前記制御部によって実行するプログラム。
【請求項4】
請求項３に記載のプログラムであって、前記第２制御は、前記第２表示をＢＯＴのアカウントに関連付けて前記トークルームに表示させるための制御を含むプログラム。
【請求項5】
請求項１から請求項４の何れか１項に記載のプログラムであって、前記トークルームは、第３ユーザが参加するトークルームであり、
前記第３ユーザに支払を依頼する第２金額と、前記第２金額の第２支払期限とを、前記制御部によって取得することと、
前記第２金額の支払を依頼する第３表示を前記トークルームに表示させるための第３制御を前記制御部によって行うことと、
前記第２支払期限に前記第２金額が支払われなかったことに基づいて、前記第２金額の支払いを督促する第４表示を前記トークルームに表示させるための第４制御を前記制御部によって行うことと、を含むプログラム。
【請求項6】
請求項５に記載のプログラムであって、前記第１金額と、前記第２金額とは、前記第１ユーザの端末の撮像部によって撮像された画像の認識結果に基づいて算出される、プログラム。
【請求項7】
請求項１から請求項６の何れか１項に記載のプログラムであって、前記第１金額の支払が行われていないことを通知する第５表示を、前記第２ユーザとは異なる第４ユーザが参加するトークルームに表示させるための第５制御を前記制御部によって実行することを含むプログラム。
【請求項8】
第１ユーザと第２ユーザとが参加するトークルームに表示される情報に関する処理を行うサーバの情報処理方法であって、前記第２ユーザに支払を依頼する第１金額と、前記第１金額の第１支払期限とを、前記サーバの制御部によって取得することと、
前記第１金額の支払を依頼する第１表示を前記トークルームに表示させるための第１制御を前記制御部によって行うことと、
前記第１支払期限に前記第１金額が支払われなかったことに基づいて、前記第１金額の支払いを督促する第２表示を前記トークルームに表示させるための第２制御を前記制御部によって行うことと、を含む情報処理方法。
【請求項9】
第１ユーザと第２ユーザとが参加するトークルームに表示される情報に関する処理を行うサーバであって、前記第２ユーザに支払を依頼する第１金額と、前記第１金額の第１支払期限とを取得し、前記第１金額の支払を依頼する第１表示を前記トークルームに表示させるための第１制御を行う制御部を備え、
前記制御部は、前記第１支払期限に前記第１金額が支払われなかったことに基づいて、前記第１金額の支払いを督促する第２表示を前記トークルームに表示させるための第２制御を行う、サーバ。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、広くネットワークを介してユーザからの集金処理やユーザ間の支払い処理等
を行う情報処理プログラム、方法、装置、及びシステムに関し、より具体的には、電子的
な決済を含めた電子バリューを制御することによって集金処理や支払処理等を管理制御す
るためのプログラム、方法、装置、及びシステムに関する。
を行う情報処理プログラム、方法、装置、及びシステムに関し、より具体的には、電子的
な決済を含めた電子バリューを制御することによって集金処理や支払処理等を管理制御す
るためのプログラム、方法、装置、及びシステムに関する。
【背景技術】
【0002】
近年、クレジットカードや電子マネー等の電子バリューを介した決済が普及している。
例えば、クレジットカードを介して複数の者が共に食事をしたときなどに行う割り勘支払
いなどを処理するものなどは、スプリット（Split the check）などと呼ばれ、米国等に
おいて広く普及している。電子バリューを介した決済は、これまで多種多様に発展してき
た。
例えば、クレジットカードを介して複数の者が共に食事をしたときなどに行う割り勘支払
いなどを処理するものなどは、スプリット（Split the check）などと呼ばれ、米国等に
おいて広く普及している。電子バリューを介した決済は、これまで多種多様に発展してき
た。
【0003】
例えば、クレジットカードの仕組みを利用する前払型支払手段の発行者に損失が発生す
るリスクを軽減するシステムが提案されている（特許文献１）。
るリスクを軽減するシステムが提案されている（特許文献１）。
【0004】
すなわち、特許文献１には、後払型支払手段の加盟店で利用可能な前払型支払手段を申
請した複数のユーザから払い込まれたそれぞれの前払金額の範囲内で、各ユーザの利用限
度額および保証金額を設定する決定部と、前記前払型支払手段の残額を超える金額の前記
加盟店からの売上請求に対する支払いのために用いられ、前記複数のユーザの保証金の総
額となるプール金額を記憶するプール記憶部と、前記決定部により保証金額が設定される
度に、該保証金額を前記プール記憶部に記憶したプール金額に加算する変更部とを備える
情報処理システムが開示されている。
請した複数のユーザから払い込まれたそれぞれの前払金額の範囲内で、各ユーザの利用限
度額および保証金額を設定する決定部と、前記前払型支払手段の残額を超える金額の前記
加盟店からの売上請求に対する支払いのために用いられ、前記複数のユーザの保証金の総
額となるプール金額を記憶するプール記憶部と、前記決定部により保証金額が設定される
度に、該保証金額を前記プール記憶部に記憶したプール金額に加算する変更部とを備える
情報処理システムが開示されている。
【0005】
また、ユーザが利用したいクレジットカードで利用料金を決済するための信用が予約時
になかった場合であっても、信用が戻った場合にそのクレジットカードでの決済が可能と
なる予約を受け付けるシステムも提案されている（特許文献２）。
になかった場合であっても、信用が戻った場合にそのクレジットカードでの決済が可能と
なる予約を受け付けるシステムも提案されている（特許文献２）。
【0006】
すなわち、特許文献２には、サービスの利用日以降にクレジットカードで利用料金が決
済される予約の要求に対し、指定された前記クレジットカードの有効性を確認することが
できなかった場合、予約を受け付け、前記指定されたクレジットカードの情報を記憶手段
に記憶させる予約手段と、前記予約手段により予約が受け付けられた後、前記記憶手段に
記憶された前記情報に基づいて、前記指定されたクレジットカードの有効性を確認する確
認手段と、前記確認手段により前記指定されたクレジットカードが有効であると確認する
ことができた場合、決済方法を前記指定されたクレジットカードでの決済にすることを示
す情報を出力し、前記確認手段により有効であると確認することができなかった場合、決
済方法を前記指定されたクレジットカードでの決済とは異なる方法にすることを示す情報
を出力する出力手段と、を備えることを特徴とする情報処理装置が開示されている。
済される予約の要求に対し、指定された前記クレジットカードの有効性を確認することが
できなかった場合、予約を受け付け、前記指定されたクレジットカードの情報を記憶手段
に記憶させる予約手段と、前記予約手段により予約が受け付けられた後、前記記憶手段に
記憶された前記情報に基づいて、前記指定されたクレジットカードの有効性を確認する確
認手段と、前記確認手段により前記指定されたクレジットカードが有効であると確認する
ことができた場合、決済方法を前記指定されたクレジットカードでの決済にすることを示
す情報を出力し、前記確認手段により有効であると確認することができなかった場合、決
済方法を前記指定されたクレジットカードでの決済とは異なる方法にすることを示す情報
を出力する出力手段と、を備えることを特徴とする情報処理装置が開示されている。
【0007】
また、ストアードバリュー型とサーバ管理型の決済システムを組み合わせることにより
ユーザの利便性を高める情報処理サーバも提案されている（特許文献３）。
ユーザの利便性を高める情報処理サーバも提案されている（特許文献３）。
【0008】
すなわち、特許文献３には、第１の電子バリューを記憶し所定の金額変更情報を用いて
当該第１の電子バリューの残高を増減する機能を有する貨幣端末と接続して、指定された
決済金額分の決済処理を実行する情報処理サーバであって、前記貨幣端末から識別データ
を取得する識別データ取得手段と、前記取得した識別データに対応付けてサーバ側の記憶
手段に記憶している第２の電子バリューにより前記指定された決済金額を決済するときに
不足金額が生じると判定された場合に、前記第１の電子バリューの残高を少なくとも当該
不足金額分だけ減額させるための金額変更情報を生成し前記貨幣端末に送信する不足金額
減額手段と、を具備したことを特徴とする情報処理サーバが開示されている。
当該第１の電子バリューの残高を増減する機能を有する貨幣端末と接続して、指定された
決済金額分の決済処理を実行する情報処理サーバであって、前記貨幣端末から識別データ
を取得する識別データ取得手段と、前記取得した識別データに対応付けてサーバ側の記憶
手段に記憶している第２の電子バリューにより前記指定された決済金額を決済するときに
不足金額が生じると判定された場合に、前記第１の電子バリューの残高を少なくとも当該
不足金額分だけ減額させるための金額変更情報を生成し前記貨幣端末に送信する不足金額
減額手段と、を具備したことを特徴とする情報処理サーバが開示されている。
【0009】
また、割り勘による支払いにおいて、支払いに関する責任の所在を明確にするために、
代表者が各メンバーから支払いの決済のための情報を受信してこれを店舗に送信する際に
、支払いの決済のための情報の内容が代表者に知られてしまう可能性を低下させるシステ
ム等も提案されている（特許文献４）。
代表者が各メンバーから支払いの決済のための情報を受信してこれを店舗に送信する際に
、支払いの決済のための情報の内容が代表者に知られてしまう可能性を低下させるシステ
ム等も提案されている（特許文献４）。
【0010】
すなわち、特許文献４には、店舗端末１０から送られた合計額を代表者端末３０で代表
者が分割することにより決定した割り勘額が各メンバー端末５０からクレジット会社サー
バ７０へ支払額として通知されると、クレジット会社サーバ７０は、支払いの決済のため
の情報を保持すると共に、この情報を暗号化した暗号化情報を含む支払い許可情報６３を
各メンバー端末５０に送信し、各メンバー端末５０は、支払い許可情報６３と同内容の支
払い許可情報４３を代表者端末３０に送信し、代表者端末３０は、支払い許可情報４３を
連結した支払い許可情報２３を店舗端末１０に送信するよう構成されたシステムが開示さ
れている。
者が分割することにより決定した割り勘額が各メンバー端末５０からクレジット会社サー
バ７０へ支払額として通知されると、クレジット会社サーバ７０は、支払いの決済のため
の情報を保持すると共に、この情報を暗号化した暗号化情報を含む支払い許可情報６３を
各メンバー端末５０に送信し、各メンバー端末５０は、支払い許可情報６３と同内容の支
払い許可情報４３を代表者端末３０に送信し、代表者端末３０は、支払い許可情報４３を
連結した支払い許可情報２３を店舗端末１０に送信するよう構成されたシステムが開示さ
れている。
【0011】
また、多段階の割り勘支払いを実現することができるクレジットカードシステムも提案
されている（特許文献５）。
されている（特許文献５）。
【0012】
すなわち、特許文献５には、クレジットカードの会員によるクレジットカード支払額の
一部を割り勘支払いすることを依頼するための依頼情報を、当該会員とは異なる会員に対
して通知する通知手段と、前記通知手段による前記依頼情報の通知を受けた会員が前記ク
レジットカード支払額の一部についてクレジットカード支払いを行った場合に、割り勘元
と割り勘先との対応関係及びそれぞれのクレジットカード支払額を含む割り勘情報を生成
する割り勘情報生成手段とを備え、前記通知手段が、先行する割り勘支払いにおいて割り
勘先となった会員によるクレジットカード支払額の一部を割り勘支払いすることを依頼す
るための依頼情報を、当該会員とは異なる他の会員に対して通知するように構成され、前
記割り勘情報生成手段が、前記通知手段による前記依頼情報の通知を受けた前記他の会員
が前記割り勘先となった会員によるクレジットカード支払額の一部についてクレジットカ
ード支払いを行った場合に、割り勘元と割り勘先との対応関係及びそれぞれのクレジット
カード支払額を含む割り勘情報を生成するように構成されているクレジットカードシステ
ムが開示されている。
一部を割り勘支払いすることを依頼するための依頼情報を、当該会員とは異なる会員に対
して通知する通知手段と、前記通知手段による前記依頼情報の通知を受けた会員が前記ク
レジットカード支払額の一部についてクレジットカード支払いを行った場合に、割り勘元
と割り勘先との対応関係及びそれぞれのクレジットカード支払額を含む割り勘情報を生成
する割り勘情報生成手段とを備え、前記通知手段が、先行する割り勘支払いにおいて割り
勘先となった会員によるクレジットカード支払額の一部を割り勘支払いすることを依頼す
るための依頼情報を、当該会員とは異なる他の会員に対して通知するように構成され、前
記割り勘情報生成手段が、前記通知手段による前記依頼情報の通知を受けた前記他の会員
が前記割り勘先となった会員によるクレジットカード支払額の一部についてクレジットカ
ード支払いを行った場合に、割り勘元と割り勘先との対応関係及びそれぞれのクレジット
カード支払額を含む割り勘情報を生成するように構成されているクレジットカードシステ
ムが開示されている。
【0013】
また、注文した単一品を複数の人で分け合った場合、当該単一品の金額を分け合った複
数の人に分割して割り振るＳｈａｒｅｄ精算処理が可能な会計処理装置も提案されている
（特許文献６）。
数の人に分割して割り振るＳｈａｒｅｄ精算処理が可能な会計処理装置も提案されている
（特許文献６）。
【0014】
すなわち、特許文献６には、注文された商品の支払い金額に関する会計処理を行う会計
処理装置において、複数の人からなるグループが１品からなる単一の商品を注文した場合
に、注文された当該単一の商品の金額を、注文した複数の人に分割して割り振るＳｈａｒ
ｅｄ精算処理を行うことを特徴とする会計処理装置が開示されている。
この会計処理装置では、複数の人による割り勘処理として各人が注文した商品ごとに個
別に精算する場合、注文数量が複数の商品は１個ずつに分割した個別精算処理用の注文商
品の一覧が表示され、さらに、単一品の金額を分割するＳｈａｒｅｄ精算処理も必要であ
れば、該当商品を選択するとともにＳｈａｒｅｄ精算対象の人数を登録して、該当商品を
当該人数分だけ分割した形で画面表示した後、それぞれに該当する人を指定することによ
って、各人ごとに個別精算金額とＳｈａｒｅｄ精算金額とを集計した金額を算出して、画
面表示することにより会計処理が行われる。
処理装置において、複数の人からなるグループが１品からなる単一の商品を注文した場合
に、注文された当該単一の商品の金額を、注文した複数の人に分割して割り振るＳｈａｒ
ｅｄ精算処理を行うことを特徴とする会計処理装置が開示されている。
この会計処理装置では、複数の人による割り勘処理として各人が注文した商品ごとに個
別に精算する場合、注文数量が複数の商品は１個ずつに分割した個別精算処理用の注文商
品の一覧が表示され、さらに、単一品の金額を分割するＳｈａｒｅｄ精算処理も必要であ
れば、該当商品を選択するとともにＳｈａｒｅｄ精算対象の人数を登録して、該当商品を
当該人数分だけ分割した形で画面表示した後、それぞれに該当する人を指定することによ
って、各人ごとに個別精算金額とＳｈａｒｅｄ精算金額とを集計した金額を算出して、画
面表示することにより会計処理が行われる。
【先行技術文献】
【特許文献】
【0015】
【文献】特許第５６７８２３５号明細書
【文献】特許第５２６９２２１号明細書
【文献】特許第５５９５４３４号明細書
【文献】特開２０１４－１１２２８６号公報
【文献】特開２０１３－１８６７３２号公報
【文献】特開２００８－６５５７４号公報
【発明の概要】
【発明が解決しようとする課題】
【0016】
しかしながら、上述した従来技術においては、個人の電子決済についての工夫が中心で
あり、複数のメンバーで構成されるようなグループ内での電子決済等については改善の余
地がある。確かに、割り勘やシェアに関する支払いを処理するためのシステム（特許文献
４～６）も提案されているが、事後決済、事後の集金等の処理や管理制御等についてはさ
らなる改善の余地がある。
あり、複数のメンバーで構成されるようなグループ内での電子決済等については改善の余
地がある。確かに、割り勘やシェアに関する支払いを処理するためのシステム（特許文献
４～６）も提案されているが、事後決済、事後の集金等の処理や管理制御等についてはさ
らなる改善の余地がある。
【0017】
さらに、これらのやりとりを円滑に進めることができる新しい技術（督促技術、インタ
フェース技術等）やバリエーション技術の提供が望まれる。
フェース技術等）やバリエーション技術の提供が望まれる。
【課題を解決するための手段】
【0018】
本発明の一実施形態に係る情報処理プログラムは、サーバ上で管理されるトークルーム
を介して会話可能に構成された第１情報処理端末に対応付けられた第１ユーザと、前記第
１情報処理端末と前記トークルームを介して会話可能に構成された１以上の第２情報処理
端末に対応付けられた１以上の第２ユーザとの間で支払いの調整を行うためのプログラム
であって、前記第１情報処理端末に、前記第２情報処理端末への支払い依頼を要求させる
ステップと、前記第２情報処理端末からの応答を受信させるステップと、前記第２情報処
理端末からの応答の受信によって、前記第２情報処理端末に対応付けられた１以上の第２
ユーザの支払い方法及び支払期限を前記サーバに管理させるよう要求させるステップと、
を実行することを特徴とする。
を介して会話可能に構成された第１情報処理端末に対応付けられた第１ユーザと、前記第
１情報処理端末と前記トークルームを介して会話可能に構成された１以上の第２情報処理
端末に対応付けられた１以上の第２ユーザとの間で支払いの調整を行うためのプログラム
であって、前記第１情報処理端末に、前記第２情報処理端末への支払い依頼を要求させる
ステップと、前記第２情報処理端末からの応答を受信させるステップと、前記第２情報処
理端末からの応答の受信によって、前記第２情報処理端末に対応付けられた１以上の第２
ユーザの支払い方法及び支払期限を前記サーバに管理させるよう要求させるステップと、
を実行することを特徴とする。
【発明の効果】
【0019】
本発明によれば、改善された割り勘・費用分担に関する支払い処理技術及び／または管
理制御技術を提供することができる。
理制御技術を提供することができる。
【図面の簡単な説明】
【0020】
【図1】本発明の一実施形態に係る情報処理システムの全体構成を説明する説明図である。
【図2】本発明の実施形態のバリエーションを示すシステムまたは装置等の構成例を説明する説明図である。
【図3】本発明の一実施形態に係るシステムまたは装置等における基本動作例を説明する説明図である。
【図4A】本発明の一実施形態に係るシステム等における基本的な動作概念フローを説明するフローチャートである。
【図4B】本発明の一実施形態に係るシステム等におけるより詳細な動作例を示すフローチャートである。
【図4C】本発明の一実施形態に係るシステム等におけるより詳細な動作例を示すフローチャートである。
【図5】本発明の一実施形態に係るシステム等における動作の機能概念を説明する説明図である。
【図6】本発明の一実施形態に係るシステム等における装置または端末間の処理及びデータの流れを説明する説明図である。
【図7】本発明の一実施形態に係るシステム等における装置または端末上の画面表示例を説明する説明図である。
【図8】本発明の一実施形態に係るシステム等における装置または端末上の画面表示例を説明する説明図である。
【図9】本発明の一実施形態に係るシステム等における装置または端末上の画面表示例を説明する説明図である。
【図10】本発明の一実施形態に係るシステム等における装置または端末上の画面表示例を説明する説明図である。
【図11A】本発明の一実施形態に係るシステム等における装置または端末上の画面表示例を説明する説明図である。
【図11B】本発明の一実施形態に係るシステム等における装置または端末上の他の画面表示例を説明する説明図である。
【図12】本発明の他の実施形態に係るシステム等における動作例を示すフローチャートである。
【図13】本発明の他の実施形態に係るシステム等における動作例を示すフローチャートである。
【図14】本発明の他の実施形態に係るシステム等における動作例を示すフローチャートである。
【図15】本発明の他の実施形態に係るシステム等における装置または端末上の画面表示例を説明する説明図である。
【図16】本発明の他の実施形態に係るシステム等における装置または端末上の画面表示例を説明する説明図である。
【図17】本発明の他の実施形態に係るシステム等における装置または端末上の画面表示例を説明する説明図である。
【図18】本発明の他の実施形態に係るシステム等における装置または端末上の画面表示例を説明する説明図である。
【図19】本発明の他の実施形態に係るシステム等における装置または端末上の画面表示例を説明する説明図である。
【発明を実施するための形態】
【0021】
＜通信の秘密の遵守＞
本明細書に記載の開示を実施する場合は、通信の秘密に係る法的事項を遵守の上で実施
されるものであることに留意されたい。
本明細書に記載の開示を実施する場合は、通信の秘密に係る法的事項を遵守の上で実施
されるものであることに留意されたい。
【0022】
本開示に係る情報処理システム等を実施するための実施形態について、図面を参照して
説明する。
説明する。
【0023】
＜システム構成＞
図１は、本開示の一実施形態における情報処理システムの構成を示す図である。図１に
示すように、情報処理システム１００では、ネットワーク１９９を介して１以上のサーバ
（サーバ１１０、サーバ１２０）と、１以上の端末（端末１５１、端末１５２、端末１５
３）とが接続される。サーバ１１０、１２０は、ユーザが所有する端末１５１～１５３に
対し、ネットワーク１９９を介して端末間でのメッセージの送受信を実現するサービスを
提供する。なお、ネットワーク１９９に接続される端末の数は制限されない。また、サー
バの数についても制限されない（必要に応じて機能を拡張するためのサーバを追加するこ
とができる。１のサーバによってサービス提供させてもよい）。
図１は、本開示の一実施形態における情報処理システムの構成を示す図である。図１に
示すように、情報処理システム１００では、ネットワーク１９９を介して１以上のサーバ
（サーバ１１０、サーバ１２０）と、１以上の端末（端末１５１、端末１５２、端末１５
３）とが接続される。サーバ１１０、１２０は、ユーザが所有する端末１５１～１５３に
対し、ネットワーク１９９を介して端末間でのメッセージの送受信を実現するサービスを
提供する。なお、ネットワーク１９９に接続される端末の数は制限されない。また、サー
バの数についても制限されない（必要に応じて機能を拡張するためのサーバを追加するこ
とができる。１のサーバによってサービス提供させてもよい）。
【0024】
図１に示されるとおり、ネットワーク１９９は、１以上のサーバと１以上の端末とを接
続する役割を担う。すなわち、ネットワーク１９９は、端末１５１～１５３がサーバ１１
０または１２０に接続した後、データを送受信することができるように接続経路を提供す
る通信網を意味する。
続する役割を担う。すなわち、ネットワーク１９９は、端末１５１～１５３がサーバ１１
０または１２０に接続した後、データを送受信することができるように接続経路を提供す
る通信網を意味する。
【0025】
例えば、ネットワーク１９９のうちの１つまたは複数の部分は、有線ネットワークや無
線ネットワークであってもよい。ネットワーク１９９は、アドホック・ネットワーク（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 te
rm evolution）、ＣＤＭＡ（code division multiple access）、ブルートゥース（Bluet
ooth（登録商標））、衛星通信など、または、これらの２つ以上の組合せを含むことがで
きる。ただし、本開示において、ネットワーク１９９は、これらに限定されない。また、
ネットワーク１９９は、１つまたは複数のネットワークを含むことができる。
線ネットワークであってもよい。ネットワーク１９９は、アドホック・ネットワーク（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 te
rm evolution）、ＣＤＭＡ（code division multiple access）、ブルートゥース（Bluet
ooth（登録商標））、衛星通信など、または、これらの２つ以上の組合せを含むことがで
きる。ただし、本開示において、ネットワーク１９９は、これらに限定されない。また、
ネットワーク１９９は、１つまたは複数のネットワークを含むことができる。
【0026】
端末（端末１５１、端末１５２、端末１５３）は、各実施形態において記載する機能を
実現できる情報処理端末であればどのような端末であってもよい。端末１５１～１５３は
、代表的にはスマートフォンであり、その他に携帯電話（例えば、フィーチャーフォン）
、コンピュータ（例えば、デスクトップ、ラップトップ、タブレットなど）、メディアコ
ンピュータプラットホーム（例えば、ケーブル、衛星セットトップボックス、デジタルビ
デオレコーダ）、ハンドヘルドコンピュータデバイス（例えば、ＰＤＡ（personal digit
al assistant）、電子メールクライアントなど）、ウェアラブル端末（メガネ型デバイス
、時計型デバイスなど）、または他種のコンピュータ、またはコミュニケーションプラッ
トホームを含む。ただし、本開示において、端末１５１～１５３は、これらに限定されな
い。また、端末１５１～１５３は情報処理端末と表現されても良い。
実現できる情報処理端末であればどのような端末であってもよい。端末１５１～１５３は
、代表的にはスマートフォンであり、その他に携帯電話（例えば、フィーチャーフォン）
、コンピュータ（例えば、デスクトップ、ラップトップ、タブレットなど）、メディアコ
ンピュータプラットホーム（例えば、ケーブル、衛星セットトップボックス、デジタルビ
デオレコーダ）、ハンドヘルドコンピュータデバイス（例えば、ＰＤＡ（personal digit
al assistant）、電子メールクライアントなど）、ウェアラブル端末（メガネ型デバイス
、時計型デバイスなど）、または他種のコンピュータ、またはコミュニケーションプラッ
トホームを含む。ただし、本開示において、端末１５１～１５３は、これらに限定されな
い。また、端末１５１～１５３は情報処理端末と表現されても良い。
【0027】
端末１５１～１５３の構成は基本的には同一であるため、以下の説明においては、代表
して端末１５１について説明することとし、以下、必要に応じて端末１５２や端末１５３
を他端末として説明する。また、サーバ１１０、１２０についても同様に、代表してサー
バ１１０について説明する。
して端末１５１について説明することとし、以下、必要に応じて端末１５２や端末１５３
を他端末として説明する。また、サーバ１１０、１２０についても同様に、代表してサー
バ１１０について説明する。
【0028】
サーバ１１０は、端末１５１等に対して、所定のサービスを提供する機能を備える。サ
ーバ１１０は、各実施形態において記載する機能を実現できる情報処理装置であればどの
ような装置であってもよい。サーバ１１０は、代表的にはサーバ装置であり、その他にコ
ンピュータ（例えば、デスクトップ、ラップトップ、タブレットなど）、メディアコンピ
ュータプラットホーム（例えば、ケーブル、衛星セットトップボックス、デジタルビデオ
レコーダ）、ハンドヘルドコンピュータデバイス（例えば、ＰＤＡ、電子メールクライア
ントなど）、あるいは他種のコンピュータ、またはコミュニケーションプラットホームを
含む。ただし、本開示において、サーバ１１０は、これらに限定されない。また、サーバ
１１０は情報処理装置と表現されても良い。
ーバ１１０は、各実施形態において記載する機能を実現できる情報処理装置であればどの
ような装置であってもよい。サーバ１１０は、代表的にはサーバ装置であり、その他にコ
ンピュータ（例えば、デスクトップ、ラップトップ、タブレットなど）、メディアコンピ
ュータプラットホーム（例えば、ケーブル、衛星セットトップボックス、デジタルビデオ
レコーダ）、ハンドヘルドコンピュータデバイス（例えば、ＰＤＡ、電子メールクライア
ントなど）、あるいは他種のコンピュータ、またはコミュニケーションプラットホームを
含む。ただし、本開示において、サーバ１１０は、これらに限定されない。また、サーバ
１１０は情報処理装置と表現されても良い。
【0029】
＜ハードウェア（HW）構成＞
図１を用いて、通信システムに含まれる各装置のHW構成について説明する。
図１を用いて、通信システムに含まれる各装置のHW構成について説明する。
【0030】
（１）端末のHW構成
【0031】
端末１５１は、制御装置１５１０（ＣＰＵ：central processing unit（中央処理装置
））、記憶装置１５１５、通信Ｉ／Ｆ１５１６（インタフェース）、入出力装置１５１７
、表示装置１５１８、マイク１５１９ａ、スピーカ１５１９ｂ、カメラ１５１９ｃを備え
る。端末１５１のHWの各構成要素は、例えば、バスB2を介して相互に接続される。
））、記憶装置１５１５、通信Ｉ／Ｆ１５１６（インタフェース）、入出力装置１５１７
、表示装置１５１８、マイク１５１９ａ、スピーカ１５１９ｂ、カメラ１５１９ｃを備え
る。端末１５１のHWの各構成要素は、例えば、バスB2を介して相互に接続される。
【0032】
通信Ｉ／Ｆ１５１６は、ネットワーク１９９を介して各種データの送受信を行う。当該
通信は、有線、無線のいずれで実行されてもよく、互いの通信が実行できるのであれば、
どのような通信プロトコルを用いてもよい。通信Ｉ／Ｆ１５１６は、ネットワーク１９９
を介して、サーバ１１０との通信を実行する機能を有する。通信Ｉ／Ｆ１５１６は、各種
データを制御装置１５１０からの指示に従って、サーバ１１０に送信する。また、通信Ｉ
／Ｆ１５１６は、サーバ１１０から送信された各種データを受信し、制御装置１５１０に
伝達する。
通信は、有線、無線のいずれで実行されてもよく、互いの通信が実行できるのであれば、
どのような通信プロトコルを用いてもよい。通信Ｉ／Ｆ１５１６は、ネットワーク１９９
を介して、サーバ１１０との通信を実行する機能を有する。通信Ｉ／Ｆ１５１６は、各種
データを制御装置１５１０からの指示に従って、サーバ１１０に送信する。また、通信Ｉ
／Ｆ１５１６は、サーバ１１０から送信された各種データを受信し、制御装置１５１０に
伝達する。
【0033】
入出力装置１５１７は、端末１５１に対する各種操作を入力する装置、および、端末１
５１で処理された処理結果を出力する装置を含む。入出力装置１５１７は、入力装置と出
力装置とが一体化していても良いし、入力装置と出力装置とに分離していてもよい（後者
の場合、一例として、タッチパネル入力センサ等の入力装置１５１７ａと、タッチパネル
出力デバイス、バイブレーション駆動機構等の出力装置１５１７ｂとに分離される）。
５１で処理された処理結果を出力する装置を含む。入出力装置１５１７は、入力装置と出
力装置とが一体化していても良いし、入力装置と出力装置とに分離していてもよい（後者
の場合、一例として、タッチパネル入力センサ等の入力装置１５１７ａと、タッチパネル
出力デバイス、バイブレーション駆動機構等の出力装置１５１７ｂとに分離される）。
【0034】
入力装置は、ユーザからの入力を受け付けて、当該入力に係る情報を制御装置１５１０
に伝達できる全ての種類の装置のいずれかまたはその組み合わせにより実現される。入力
装置は、代表的にはタッチパネルなどにより実現され、ユーザの指やスタイラスなどの指
示具による接触とその接触位置を検出し、当該接触位置の座標を制御装置１５１０に伝達
する。一方で、入力装置は、タッチパネル以外の入力装置により実現されてもよい。入力
装置は、例えば、キーボード等に代表されるハードウェアキーや、マウス等のポインティ
ングデバイス、カメラ（動画像を介した操作入力）、マイク（音声による操作入力）を含
む。ただし、本開示において、入力装置はこれらに限定されない。
に伝達できる全ての種類の装置のいずれかまたはその組み合わせにより実現される。入力
装置は、代表的にはタッチパネルなどにより実現され、ユーザの指やスタイラスなどの指
示具による接触とその接触位置を検出し、当該接触位置の座標を制御装置１５１０に伝達
する。一方で、入力装置は、タッチパネル以外の入力装置により実現されてもよい。入力
装置は、例えば、キーボード等に代表されるハードウェアキーや、マウス等のポインティ
ングデバイス、カメラ（動画像を介した操作入力）、マイク（音声による操作入力）を含
む。ただし、本開示において、入力装置はこれらに限定されない。
【0035】
出力装置は、制御装置１５１０で処理された処理結果を出力することができる全ての種
類の装置のいずれかまたはその組み合わせにより実現される。出力装置は、代表的には、
タッチパネルなどにより実現される。一方で、出力装置はタッチパネル以外の出力装置に
より実現されても良い。例えば、スピーカ（音声出力）、レンズ（例えば３Ｄ（three di
mensions）出力や、ホログラム出力）、プリンターなどを含むことができる。ただし、本
開示において、出力装置はこれらに限定されない。
類の装置のいずれかまたはその組み合わせにより実現される。出力装置は、代表的には、
タッチパネルなどにより実現される。一方で、出力装置はタッチパネル以外の出力装置に
より実現されても良い。例えば、スピーカ（音声出力）、レンズ（例えば３Ｄ（three di
mensions）出力や、ホログラム出力）、プリンターなどを含むことができる。ただし、本
開示において、出力装置はこれらに限定されない。
【0036】
表示装置１５１８は、フレームバッファ（不図示）に書き込まれた表示データに従って
、表示することができる全ての種類の装置のいずれかまたはその組み合わせにより実現さ
れる。表示装置１５１８は、代表的にはモニタ（例えば、液晶ディスプレイやOELD（orga
nic electroluminescence display））で実現される。表示装置１５１８は、ヘッドマウ
ントディスプレイ（ＨＤＭ：Head Mounted Display）であってもよい。また、表示装置１
５１８は、プロジェクションマッピング、ホログラム、空気中など（真空であってもよい
）に画像やテキスト情報等を表示可能な装置により実現されてもよい。なお、これらの表
示装置１５１８は、３Ｄで表示データを表示可能であってもよい。ただし、本開示におい
て、表示装置１５１８はこれらに限定されない。
、表示することができる全ての種類の装置のいずれかまたはその組み合わせにより実現さ
れる。表示装置１５１８は、代表的にはモニタ（例えば、液晶ディスプレイやOELD（orga
nic electroluminescence display））で実現される。表示装置１５１８は、ヘッドマウ
ントディスプレイ（ＨＤＭ：Head Mounted Display）であってもよい。また、表示装置１
５１８は、プロジェクションマッピング、ホログラム、空気中など（真空であってもよい
）に画像やテキスト情報等を表示可能な装置により実現されてもよい。なお、これらの表
示装置１５１８は、３Ｄで表示データを表示可能であってもよい。ただし、本開示におい
て、表示装置１５１８はこれらに限定されない。
【0037】
入出力装置１５１７がタッチパネルの場合、一例として、入出力装置１５１７及び表示
装置１５１８は、略同一の大きさおよび形状のものとして構成され、互いに対向して配置
されていても良い。
装置１５１８は、略同一の大きさおよび形状のものとして構成され、互いに対向して配置
されていても良い。
【0038】
制御装置１５１０は、プログラム内に含まれたコードまたは命令によって実現する機能
を実行するために物理的に構造化された回路を有し、例えば、ハードウェアに内蔵された
データ処理装置により実現される。
を実行するために物理的に構造化された回路を有し、例えば、ハードウェアに内蔵された
データ処理装置により実現される。
【0039】
制御装置１５１０は、代表的には中央処理装置（ＣＰＵ）、であり、その他にマイクロ
プロセッサ（microprocessor）、プロセッサコア（processor core）、マルチプロセッサ
（multiprocessor）、ＡＳＩＣ（application-specific integrated circuit）、ＦＰＧ
Ａ（field programmable gate array）であってもよい。ただし、本開示において、制御
装置１５１０はこれらに限定されない。
プロセッサ（microprocessor）、プロセッサコア（processor core）、マルチプロセッサ
（multiprocessor）、ＡＳＩＣ（application-specific integrated circuit）、ＦＰＧ
Ａ（field programmable gate array）であってもよい。ただし、本開示において、制御
装置１５１０はこれらに限定されない。
【0040】
記憶装置１５１５は、端末１５１が動作するうえで必要とする各種プログラムや各種デ
ータを記憶する機能を有する。記憶装置１５１５は、ＨＤＤ（hard disk drive）、ＳＳ
Ｄ（solid state drive）、フラッシュメモリ、ＲＡＭ（random access memory）、ＲＯ
Ｍ（read only memory）など各種の記憶媒体により実現される。ただし、本開示において
、記憶装置１５１５はこれらに限定されない。
ータを記憶する機能を有する。記憶装置１５１５は、ＨＤＤ（hard disk drive）、ＳＳ
Ｄ（solid state drive）、フラッシュメモリ、ＲＡＭ（random access memory）、ＲＯ
Ｍ（read only memory）など各種の記憶媒体により実現される。ただし、本開示において
、記憶装置１５１５はこれらに限定されない。
【0041】
端末１５１は、プログラムＰを記憶装置１５１５に記憶し、このプログラムＰを実行す
ることで、制御装置１５１０が、制御装置１５１０に含まれる各部としての処理を実行す
る。つまり、記憶装置１５１５に記憶されるプログラムＰは、端末１５１に、制御装置１
５１０が実行する各機能を実現させる。
ることで、制御装置１５１０が、制御装置１５１０に含まれる各部としての処理を実行す
る。つまり、記憶装置１５１５に記憶されるプログラムＰは、端末１５１に、制御装置１
５１０が実行する各機能を実現させる。
【0042】
マイク１５１９ａは、音声データの入力に利用される。スピーカ１５１９ｂは、音声デ
ータの出力に利用される。カメラ１５１９ｃは、動画像データの取得に利用される。
ータの出力に利用される。カメラ１５１９ｃは、動画像データの取得に利用される。
【0043】
（２）サーバのHW構成
サーバ１１０は、制御装置１１１０（ＣＰＵ）、記憶装置１１０５、入出力装置１１０
６、ディスプレイ１１０７、通信Ｉ／Ｆ１１０８（インタフェース）を備える。サーバ１
１０のHWの各構成要素は、例えば、バスB1を介して相互に接続される。
サーバ１１０は、制御装置１１１０（ＣＰＵ）、記憶装置１１０５、入出力装置１１０
６、ディスプレイ１１０７、通信Ｉ／Ｆ１１０８（インタフェース）を備える。サーバ１
１０のHWの各構成要素は、例えば、バスB1を介して相互に接続される。
【0044】
制御装置１１１０は、プログラム内に含まれたコードまたは命令によって実現する機能
を実行するために物理的に構造化された回路を有し、例えば、ハードウェアに内蔵された
データ処理装置により実現される。
を実行するために物理的に構造化された回路を有し、例えば、ハードウェアに内蔵された
データ処理装置により実現される。
【0045】
制御装置１１１０は、代表的には中央処理装置（ＣＰＵ）、であり、その他にマイクロ
プロセッサ、プロセッサコア、マルチプロセッサ、ＡＳＩＣ、ＦＰＧＡであってもよい。
ただし、本開示において、制御装置１１１０はこれらに限定されない。
プロセッサ、プロセッサコア、マルチプロセッサ、ＡＳＩＣ、ＦＰＧＡであってもよい。
ただし、本開示において、制御装置１１１０はこれらに限定されない。
【0046】
記憶装置１１０５は、サーバが動作するうえで必要とする各種プログラムや各種データ
を記憶する機能を有する。記憶装置１１０５は、ＨＤＤ、ＳＳＤ、フラッシュメモリなど
各種の記憶媒体により実現される。ただし、本開示において、記憶装置１１０５はこれら
に限定されない。
を記憶する機能を有する。記憶装置１１０５は、ＨＤＤ、ＳＳＤ、フラッシュメモリなど
各種の記憶媒体により実現される。ただし、本開示において、記憶装置１１０５はこれら
に限定されない。
【0047】
入出力装置１１０６は、サーバ１１０に対する各種操作を入力する装置により実現され
る。入出力装置１１０６は、ユーザからの入力を受け付けて、当該入力に係る情報を制御
装置１１１０に伝達できる全ての種類の装置のいずれかまたはその組み合わせにより実現
される。入出力装置１１０６は、代表的にはキーボード等に代表されるハードウェアキー
や、マウス等のポインティングデバイスで実現される。なお、入出力装置１１０６は、例
えば、タッチパネルやカメラ（動画像を介した操作入力）、マイク（音声による操作入力
）を含んでいてもよい。ただし、本開示において、入出力装置１１０６はこれらに限定さ
れない。
る。入出力装置１１０６は、ユーザからの入力を受け付けて、当該入力に係る情報を制御
装置１１１０に伝達できる全ての種類の装置のいずれかまたはその組み合わせにより実現
される。入出力装置１１０６は、代表的にはキーボード等に代表されるハードウェアキー
や、マウス等のポインティングデバイスで実現される。なお、入出力装置１１０６は、例
えば、タッチパネルやカメラ（動画像を介した操作入力）、マイク（音声による操作入力
）を含んでいてもよい。ただし、本開示において、入出力装置１１０６はこれらに限定さ
れない。
【0048】
ディスプレイ１１０７は、代表的にはモニタ（例えば、液晶ディスプレイやOELD（orga
nic electroluminescence display））で実現される。なお、ディスプレイ１１０７は、
ヘッドマウントディスプレイ（ＨＤＭ）などであってもよい。なお、これらのディスプレ
イ１１０７は、は、３Ｄで表示データを表示可能であってもよい。ただし、本開示におい
て、ディスプレイ１１０７はこれらに限定されない。
nic electroluminescence display））で実現される。なお、ディスプレイ１１０７は、
ヘッドマウントディスプレイ（ＨＤＭ）などであってもよい。なお、これらのディスプレ
イ１１０７は、は、３Ｄで表示データを表示可能であってもよい。ただし、本開示におい
て、ディスプレイ１１０７はこれらに限定されない。
【0049】
通信Ｉ／Ｆ１１０８は、ネットワーク１９９を介して各種データの送受信を行う。当該
通信は、有線、無線のいずれで実行されてもよく、互いの通信が実行できるのであれば、
どのような通信プロトコルを用いてもよい。通信Ｉ／Ｆ１１０８は、ネットワーク１９９
を介して、端末１５１との通信を実行する機能を有する。通信Ｉ／Ｆ１１０８は、各種デ
ータを制御装置１１１０からの指示に従って、端末１５１に送信する。また、通信Ｉ／Ｆ
１１０８は、端末１５１から送信された各種データを受信し、制御装置１１１０に伝達す
る。
サーバ１１０は、プログラムＰを記憶装置１１０５に記憶し、このプログラムＰを実行
することで、制御装置１１１０が、制御装置１１１０に含まれる各部としての処理を実行
する。つまり、記憶装置１１０５に記憶されるプログラムＰは、サーバ１１０に、制御装
置１１１０が実行する各機能を実現させる。
通信は、有線、無線のいずれで実行されてもよく、互いの通信が実行できるのであれば、
どのような通信プロトコルを用いてもよい。通信Ｉ／Ｆ１１０８は、ネットワーク１９９
を介して、端末１５１との通信を実行する機能を有する。通信Ｉ／Ｆ１１０８は、各種デ
ータを制御装置１１１０からの指示に従って、端末１５１に送信する。また、通信Ｉ／Ｆ
１１０８は、端末１５１から送信された各種データを受信し、制御装置１１１０に伝達す
る。
サーバ１１０は、プログラムＰを記憶装置１１０５に記憶し、このプログラムＰを実行
することで、制御装置１１１０が、制御装置１１１０に含まれる各部としての処理を実行
する。つまり、記憶装置１１０５に記憶されるプログラムＰは、サーバ１１０に、制御装
置１１１０が実行する各機能を実現させる。
【0050】
本発明の各実施形態においては、端末１５１等および／またはサーバ１１０等のＣＰＵ
がプログラムＰを実行することにより、実現するものとして説明する。
がプログラムＰを実行することにより、実現するものとして説明する。
【0051】
なお、端末１５１の制御装置１５１０、および／または、サーバ１１０の制御装置１１
１０は、ＣＰＵだけでなく、集積回路（ＩＣ（Integrated Circuit）チップ、ＬＳＩ（La
rge Scale Integration））等に形成された論理回路（ハードウェア）や専用回路によっ
て各処理を実現してもよい。また、これらの回路は、１または複数の集積回路により実現
されてよく、各実施形態に示す複数の処理を１つの集積回路により実現されることとして
もよい。また、ＬＳＩは、集積度の違いにより、ＶＬＳＩ、スーパーＬＳＩ、ウルトラＬ
ＳＩなどと呼称されることもある。
１０は、ＣＰＵだけでなく、集積回路（ＩＣ（Integrated Circuit）チップ、ＬＳＩ（La
rge Scale Integration））等に形成された論理回路（ハードウェア）や専用回路によっ
て各処理を実現してもよい。また、これらの回路は、１または複数の集積回路により実現
されてよく、各実施形態に示す複数の処理を１つの集積回路により実現されることとして
もよい。また、ＬＳＩは、集積度の違いにより、ＶＬＳＩ、スーパーＬＳＩ、ウルトラＬ
ＳＩなどと呼称されることもある。
【0052】
また、本開示の各実施形態のプログラムＰ（ソフトウェアプログラム／コンピュータプ
ログラム）は、コンピュータに読み取り可能な記憶媒体に記憶された状態で提供されても
よい。記憶媒体は、「一時的でない有形の媒体」に、プログラムを記憶可能である。
ログラム）は、コンピュータに読み取り可能な記憶媒体に記憶された状態で提供されても
よい。記憶媒体は、「一時的でない有形の媒体」に、プログラムを記憶可能である。
【0053】
記憶媒体は適切な場合、１つまたは複数の半導体ベースの、または他の集積回路（ＩＣ
）（例えば、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）または特定用途
向けＩＣ（ＡＳＩＣ）など）、ハード・ディスク・ドライブ（ＨＤＤ）、ハイブリッド・
ハード・ドライブ（ＨＨＤ）、光ディスク、光ディスクドライブ（ＯＤＤ）、光磁気ディ
スク、光磁気ドライブ、フロッピィ・ディスケット、フロッピィ・ディスク・ドライブ（
ＦＤＤ）、磁気テープ、固体ドライブ（ＳＳＤ）、ＲＡＭドライブ、セキュア・デジタル
・カードもしくはドライブ、任意の他の適切な記憶媒体、またはこれらの２つ以上の適切
な組合せを含むことができる。記憶媒体は、適切な場合、揮発性、不揮発性、または揮発
性と不揮発性の組合せでよい。なお、記憶媒体はこれらの例に限られず、プログラムＰを
記憶可能であれば、どのようなデバイスまたは媒体であってもよい。
）（例えば、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）または特定用途
向けＩＣ（ＡＳＩＣ）など）、ハード・ディスク・ドライブ（ＨＤＤ）、ハイブリッド・
ハード・ドライブ（ＨＨＤ）、光ディスク、光ディスクドライブ（ＯＤＤ）、光磁気ディ
スク、光磁気ドライブ、フロッピィ・ディスケット、フロッピィ・ディスク・ドライブ（
ＦＤＤ）、磁気テープ、固体ドライブ（ＳＳＤ）、ＲＡＭドライブ、セキュア・デジタル
・カードもしくはドライブ、任意の他の適切な記憶媒体、またはこれらの２つ以上の適切
な組合せを含むことができる。記憶媒体は、適切な場合、揮発性、不揮発性、または揮発
性と不揮発性の組合せでよい。なお、記憶媒体はこれらの例に限られず、プログラムＰを
記憶可能であれば、どのようなデバイスまたは媒体であってもよい。
【0054】
サーバ１１０および／または端末１５１は、例えば、記憶媒体に記憶されたプログラム
Ｐを読み出し、読み出したプログラムＰを実行することによって、各実施形態に示す複数
の機能部の機能を実現することができる。
Ｐを読み出し、読み出したプログラムＰを実行することによって、各実施形態に示す複数
の機能部の機能を実現することができる。
【0055】
また、本発明の一実施形態に係るプログラムＰは、当該プログラムを伝送可能な任意の
伝送媒体(通信ネットワークや放送波等)を介して、サーバ１１０または端末１５１に提供
されてもよい。サーバ１１０および／または端末１５１は、例えば、インターネット等を
介してダウンロードしたプログラムＰを実行することにより、各実施形態に示す複数の機
能部の機能を実現する。
伝送媒体(通信ネットワークや放送波等)を介して、サーバ１１０または端末１５１に提供
されてもよい。サーバ１１０および／または端末１５１は、例えば、インターネット等を
介してダウンロードしたプログラムＰを実行することにより、各実施形態に示す複数の機
能部の機能を実現する。
【0056】
また、本開示の各実施形態は、プログラムＰが電子的な伝送によって具現化された、搬
送波に埋め込まれたデータ信号の形態でも実現され得る。
サーバ１１０および／または端末１５１における処理の少なくとも一部は、１以上のコ
ンピュータにより構成されるクラウドコンピューティングにより実現されていてもよい。
端末１５１における処理の少なくとも一部を、サーバ１１０により行う構成としてもよ
い。この場合、例えば、端末１５１の制御装置１５１０の各機能部の処理のうち少なくと
も一部の処理を、サーバ１１０で行う構成としてもよい。
サーバ１１０における処理の少なくとも一部を、端末１５１により行う構成としてもよ
い。この場合、例えば、サーバ１１０の制御装置１１１０の各機能部の処理のうち少なく
とも一部の処理を、端末１５１で行う構成としてもよい。
本開示において、判定の構成は必須でなく、判定条件を満たした場合に所定の処理が動
作されたり、判定条件を満たさない場合に所定の処理がされたりしても良いことは当然で
ある。
送波に埋め込まれたデータ信号の形態でも実現され得る。
サーバ１１０および／または端末１５１における処理の少なくとも一部は、１以上のコ
ンピュータにより構成されるクラウドコンピューティングにより実現されていてもよい。
端末１５１における処理の少なくとも一部を、サーバ１１０により行う構成としてもよ
い。この場合、例えば、端末１５１の制御装置１５１０の各機能部の処理のうち少なくと
も一部の処理を、サーバ１１０で行う構成としてもよい。
サーバ１１０における処理の少なくとも一部を、端末１５１により行う構成としてもよ
い。この場合、例えば、サーバ１１０の制御装置１１１０の各機能部の処理のうち少なく
とも一部の処理を、端末１５１で行う構成としてもよい。
本開示において、判定の構成は必須でなく、判定条件を満たした場合に所定の処理が動
作されたり、判定条件を満たさない場合に所定の処理がされたりしても良いことは当然で
ある。
【0057】
なお、本開示のプログラムは、例えば、ActionScript、JavaScript(登録商標)などのス
クリプト言語、Objective-C、Java(登録商標)などのオブジェクト指向プログラミング言
語、HTML5などのマークアップ言語などを用いて実装できる。ただし本開示はこれらに限
定されない。
クリプト言語、Objective-C、Java(登録商標)などのオブジェクト指向プログラミング言
語、HTML5などのマークアップ言語などを用いて実装できる。ただし本開示はこれらに限
定されない。
【0058】
＜システム構成のバリエーション＞
図２に、本発明の実施形態のバリエーションを示すシステムまたは装置等の構成例を示
す。同図（及び図３）に示した構成での特徴的な処理動作は、本発明がネットワークを介
したサーバや端末との連携動作によってのみ実現されるものでなく、必要に応じて端末単
体上でも実現可能な点である。
図２に、本発明の実施形態のバリエーションを示すシステムまたは装置等の構成例を示
す。同図（及び図３）に示した構成での特徴的な処理動作は、本発明がネットワークを介
したサーバや端末との連携動作によってのみ実現されるものでなく、必要に応じて端末単
体上でも実現可能な点である。
【0059】
図２に示されるように、情報処理システム２００は、その最小限の構成として、情報処
理サーバ２１０と、ユーザが使用する各種情報処理端末（図において、例示的に、ＰＣ２
２０及び２３０、携帯電話２４０、携帯情報端末またはタブレット端末２５０～２５２が
示されている。以下、総称して「端末」とも言う）とで構成され、サーバ及び各種端末間
は、図２に示されるように専用回線やインターネット等の公衆回線（有線の回線として、
２６０、２７０、２８０、２９０）で相互に通信可能に接続されている。また、回線は有
線であっても無線であってもよく、無線の場合、携帯電話２４０及び携帯情報端末または
タブレット端末２５０は、無線で図示しない基地局や無線ルータ等を介してインターネッ
ト２９０に乗り入れ、更に回線２８０を介して情報処理サーバ２１０と相互に通信可能に
接続されている。
理サーバ２１０と、ユーザが使用する各種情報処理端末（図において、例示的に、ＰＣ２
２０及び２３０、携帯電話２４０、携帯情報端末またはタブレット端末２５０～２５２が
示されている。以下、総称して「端末」とも言う）とで構成され、サーバ及び各種端末間
は、図２に示されるように専用回線やインターネット等の公衆回線（有線の回線として、
２６０、２７０、２８０、２９０）で相互に通信可能に接続されている。また、回線は有
線であっても無線であってもよく、無線の場合、携帯電話２４０及び携帯情報端末または
タブレット端末２５０は、無線で図示しない基地局や無線ルータ等を介してインターネッ
ト２９０に乗り入れ、更に回線２８０を介して情報処理サーバ２１０と相互に通信可能に
接続されている。
【0060】
なお、携帯電話や携帯情報端末またはタブレットは、パーソナルコンピュータ（ＰＣ）
と同等の処理能力（通信処理速度や画像処理能力等）を備えているものも多く、小型のコ
ンピュータとも言うべきものである。
と同等の処理能力（通信処理速度や画像処理能力等）を備えているものも多く、小型のコ
ンピュータとも言うべきものである。
【0061】
また、本発明の実施に必要なプログラムまたはソフトウェアは、通常、ＰＣや携帯情報
端末の記憶部におけるＨＤＤまたはＳＳＤ等にインストールまたは記憶され、プログラム
またはソフトウェアの実行時には、必要に応じて記憶部内のメモリにその全部又は一部の
ソフトウェアモジュールとして読み出され、ＣＰＵにおいて演算実行される。
端末の記憶部におけるＨＤＤまたはＳＳＤ等にインストールまたは記憶され、プログラム
またはソフトウェアの実行時には、必要に応じて記憶部内のメモリにその全部又は一部の
ソフトウェアモジュールとして読み出され、ＣＰＵにおいて演算実行される。
【0062】
なお、演算実行は必ずしもＣＰＵ等の中央処理部で行われる必要はなく、図示しないデ
ィジタルシグナルプロセッサ（ＤＳＰ）等の補助演算装置を用いることもできる。
ィジタルシグナルプロセッサ（ＤＳＰ）等の補助演算装置を用いることもできる。
【0063】
また、情報処理サーバ２１０のハードウェア構成も、基本的にはＰＣを採用することが
できる。なお、本発明はこれに限定されるものではないが、情報処理サーバ２１０は、必
要に応じてそのハードウェアスペックを上げるにあたり、複数のＰＣ（一例として、数十
台～数万台）を並列的に作動させることによって大規模データの処理に適した構成をとる
こともできる。
できる。なお、本発明はこれに限定されるものではないが、情報処理サーバ２１０は、必
要に応じてそのハードウェアスペックを上げるにあたり、複数のＰＣ（一例として、数十
台～数万台）を並列的に作動させることによって大規模データの処理に適した構成をとる
こともできる。
【0064】
＜図示しない他のシステムとの連携＞
本発明の一実施形態に係る情報処理システムは、その特徴である決済や集金等の処理を
完了するにあたり、必要に応じて図示しないクレジット会社サーバや金融機関サーバ、あ
るいは店舗サーバ（当該店舗に加盟する加盟店端末を含む）と適宜連携して決済等の処理
を完了させることができる。その意味で、本発明の一実施形態に係る情報処理システムそ
れ自体の中で決済等の一連の処理の全てを完了させる必要はない。つまり、本発明の一実
施形態に係る情報処理システムにおける処理は、少なくとも決済等の一連の処理を完結さ
せるために必要となる帳簿データ等のデータを出力するところまでで足りる（もちろん、
それ以上の処理を行うことも排除されない）。
本発明の一実施形態に係る情報処理システムは、その特徴である決済や集金等の処理を
完了するにあたり、必要に応じて図示しないクレジット会社サーバや金融機関サーバ、あ
るいは店舗サーバ（当該店舗に加盟する加盟店端末を含む）と適宜連携して決済等の処理
を完了させることができる。その意味で、本発明の一実施形態に係る情報処理システムそ
れ自体の中で決済等の一連の処理の全てを完了させる必要はない。つまり、本発明の一実
施形態に係る情報処理システムにおける処理は、少なくとも決済等の一連の処理を完結さ
せるために必要となる帳簿データ等のデータを出力するところまでで足りる（もちろん、
それ以上の処理を行うことも排除されない）。
【0065】
＜動作形態の基本バリエーション＞
図３に、図１や図２を参照して例示した本発明の一実施形態に係るシステムまたは装置
等における基本動作例を示す。ここで特に示したいことは、本発明の特徴的動作は、ネッ
トワークを介したサーバや端末との連携動作によっても、あるいは、端末単体上や端末間
同士上でもサーバ連携とは独立して実現可能な点である。
図３に、図１や図２を参照して例示した本発明の一実施形態に係るシステムまたは装置
等における基本動作例を示す。ここで特に示したいことは、本発明の特徴的動作は、ネッ
トワークを介したサーバや端末との連携動作によっても、あるいは、端末単体上や端末間
同士上でもサーバ連携とは独立して実現可能な点である。
【0066】
図３において、「ユーザ端末」は、図１における端末１５１～１５３、図２における端
末２２０、２３０、２４０、２５０～２５２に対応し、「情報処理サーバ」は、図１にお
けるサーバ１１０、１２０、図２における情報処理サーバ２１０に対応する。また、図３
中、ｔ１～ｔ１０は時系列の流れを示し、経時的に後述する動作や処理が行われるもので
ある。
末２２０、２３０、２４０、２５０～２５２に対応し、「情報処理サーバ」は、図１にお
けるサーバ１１０、１２０、図２における情報処理サーバ２１０に対応する。また、図３
中、ｔ１～ｔ１０は時系列の流れを示し、経時的に後述する動作や処理が行われるもので
ある。
【0067】
なお、実施形態において例示される動作または処理時刻（ｔ１等）は、本発明の概念の
理解の容易のために例示されたものであり、本発明が実施形態において例示される個別の
時系列関係に制限されることはない。
理解の容易のために例示されたものであり、本発明が実施形態において例示される個別の
時系列関係に制限されることはない。
【0068】
まず、日時ｔ１において、ユーザは、ユーザ端末を介して情報処理サーバから自身のユ
ーザ端末を本発明にかかる情報処理端末として動作させるためのアプリケーションソフト
ウェアをダウンロードする（ステップＳ３０１）。このアプリケーションソフトウェアは
、本発明にかかるプログラムの一部又は全部を処理するためのクライアントソフトウェア
またはアプリケーションソフトウェアである。そして、ダウンロードしたアプリケーショ
ンソフトウェアをユーザ端末にインストールする（ステップＳ３０２）。このとき、時刻
ｔ２において、ユーザ端末からは、必要に応じてユーザ登録としてユーザ自身のメールア
ドレスのほか、次表のようなプロフィール情報を情報処理サーバへアップロード（ステッ
プＳ３０３）して登録管理させることもできる（ステップＳ３０４）。
ーザ端末を本発明にかかる情報処理端末として動作させるためのアプリケーションソフト
ウェアをダウンロードする（ステップＳ３０１）。このアプリケーションソフトウェアは
、本発明にかかるプログラムの一部又は全部を処理するためのクライアントソフトウェア
またはアプリケーションソフトウェアである。そして、ダウンロードしたアプリケーショ
ンソフトウェアをユーザ端末にインストールする（ステップＳ３０２）。このとき、時刻
ｔ２において、ユーザ端末からは、必要に応じてユーザ登録としてユーザ自身のメールア
ドレスのほか、次表のようなプロフィール情報を情報処理サーバへアップロード（ステッ
プＳ３０３）して登録管理させることもできる（ステップＳ３０４）。
【表1】
【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】
「支払い額」欄には、例えば、図４ＡのステップＳ４０８において算出された金額が格
納される。「保証人」欄には、上述して設定された保証人（当該支払い参加者の支払いを
保証する者）のＩＤが格納される。保証人が存在しない場合にはヌル（null）等が挿入さ
れる。「友人」欄には、上述した友人のＩＤが格納される。「保証人への返済義務有無」
欄には、保証人に立替えてもらう金額の返済義務の有無（返済要否フラグ）が格納される
。この返済要否フラグは、図示しない画面入力欄等を介して保証人設定時等に設定するこ
とができる。「支払期限」欄には、支払い参加者による支払期限が格納される。この支払
期限も、図示しない画面入力欄等を介して適宜設定することができる。そして、個々の支
払期限はサーバによって管理され、この支払期限を過ぎても支払いがなされない参加者に
対しては、後述する種々の督促処理がなされる。
納される。「保証人」欄には、上述して設定された保証人（当該支払い参加者の支払いを
保証する者）のＩＤが格納される。保証人が存在しない場合にはヌル（null）等が挿入さ
れる。「友人」欄には、上述した友人のＩＤが格納される。「保証人への返済義務有無」
欄には、保証人に立替えてもらう金額の返済義務の有無（返済要否フラグ）が格納される
。この返済要否フラグは、図示しない画面入力欄等を介して保証人設定時等に設定するこ
とができる。「支払期限」欄には、支払い参加者による支払期限が格納される。この支払
期限も、図示しない画面入力欄等を介して適宜設定することができる。そして、個々の支
払期限はサーバによって管理され、この支払期限を過ぎても支払いがなされない参加者に
対しては、後述する種々の督促処理がなされる。
【0121】
図４Ｂは、本発明の一実施形態に係る情報システムを通じて、コミュニケーション手段
の基本であるトークルーム等へ入室したり、メッセージを送受信したり、メッセージ受信
時にＢＯＴが存在していた場合の処理等をより具体的に例示する基本動作フローである。
の基本であるトークルーム等へ入室したり、メッセージを送受信したり、メッセージ受信
時にＢＯＴが存在していた場合の処理等をより具体的に例示する基本動作フローである。
【0122】
図４ＢのステップＳ４２１において、１ユーザ（ＢＯＴではない人間のユーザ）がユー
ザ端末を介してアプリを起動するなどしてトークルームに入室すると、ステップＳ４２２
に進み、トークサーバからユーザ端末に読み込まれるか、あるいは、ユーザ端末それ自体
の記憶装置等から読み込まれるかして、アプリを動作させるためのトークリスト等のステ
ータス情報及び／または既読のメッセージ等の情報がユーザ端末内のメモリに読み込まれ
る。
ザ端末を介してアプリを起動するなどしてトークルームに入室すると、ステップＳ４２２
に進み、トークサーバからユーザ端末に読み込まれるか、あるいは、ユーザ端末それ自体
の記憶装置等から読み込まれるかして、アプリを動作させるためのトークリスト等のステ
ータス情報及び／または既読のメッセージ等の情報がユーザ端末内のメモリに読み込まれ
る。
【0123】
なお、トークリストは、トークサーバにおいて複数運営されているトークルームのリス
トであり、一例として、ユーザがメンバーとなっているトークルームについては選択指示
等によって当該トークルームに入室し、他のメンバーユーザとのグループトークを行うこ
とができる。グループトークは、トークサーバが提供するメッセージングサービスを介し
てメンバーがメッセージを交換する（互いに送受信し合う）ことによって進行される。
トであり、一例として、ユーザがメンバーとなっているトークルームについては選択指示
等によって当該トークルームに入室し、他のメンバーユーザとのグループトークを行うこ
とができる。グループトークは、トークサーバが提供するメッセージングサービスを介し
てメンバーがメッセージを交換する（互いに送受信し合う）ことによって進行される。
【0124】
図４Ｂにおいて、ステップＳ４２３～ステップＳ４３１までのループは、コミュニケー
ションのための基本動作ループであり、ステップＳ４３１においてアプリを終了（つまり
、トークルームから退出）しない限り、他のメンバーとのメッセージの送受信を継続する
ことができる。また、基本動動作ループ内において、ユーザやグループにアシスタントＢ
ＯＴ（いわゆるＡＩ機能を有するアドバイザープログラムであり、このＢＯＴそれ自体も
１アカウントを有するユーザとしてトークルームに参加させることができる）が紐付けら
れている場合には、このアシスタントＢＯＴからユーザに対してアドバイスを行わせたり
、他のユーザからの受信メッセージの少なくとも一部をトークサーバ等へ転送させたりす
ることができる。
この場合のユーザとアシスタントＢＯＴとの関係は、人間のユーザ同士の関係と同様で
ある。
ションのための基本動作ループであり、ステップＳ４３１においてアプリを終了（つまり
、トークルームから退出）しない限り、他のメンバーとのメッセージの送受信を継続する
ことができる。また、基本動動作ループ内において、ユーザやグループにアシスタントＢ
ＯＴ（いわゆるＡＩ機能を有するアドバイザープログラムであり、このＢＯＴそれ自体も
１アカウントを有するユーザとしてトークルームに参加させることができる）が紐付けら
れている場合には、このアシスタントＢＯＴからユーザに対してアドバイスを行わせたり
、他のユーザからの受信メッセージの少なくとも一部をトークサーバ等へ転送させたりす
ることができる。
この場合のユーザとアシスタントＢＯＴとの関係は、人間のユーザ同士の関係と同様で
ある。
【0125】
ステップＳ４２３において、図示しない操作によりユーザからメッセージ等の送信があ
る（Ｙｅｓ）と、ステップＳ４２４へ進み、トークサーバに対するメッセージ等の送信処
理が行われる（ステップＳ４２３において、Ｎｏの場合はステップＳ４２５へ進む）。図
４Ｂでは不図示であるが、ステップＳ４２４で送信されるメッセージ等の内容によって処
理される基本動作例は次の（１）～（３）のとおりである。
る（Ｙｅｓ）と、ステップＳ４２４へ進み、トークサーバに対するメッセージ等の送信処
理が行われる（ステップＳ４２３において、Ｎｏの場合はステップＳ４２５へ進む）。図
４Ｂでは不図示であるが、ステップＳ４２４で送信されるメッセージ等の内容によって処
理される基本動作例は次の（１）～（３）のとおりである。
【0126】
（１）ユーザ端末からトークサーバへユーザ自身のメッセージが送信された場合
トークサーバでは、受信したメッセージをトークルーム内の他メンバーに送信（転送）
する。また、必要に応じて、受信したメッセージに関連する（つまり、受信メッセージに
適切な応答が可能な）１以上のＢＯＴ候補を抽出してメッセージ送信元のユーザ及び／ま
たはトークルーム内の他のメンバーに返信させることができる。
トークサーバでは、受信したメッセージをトークルーム内の他メンバーに送信（転送）
する。また、必要に応じて、受信したメッセージに関連する（つまり、受信メッセージに
適切な応答が可能な）１以上のＢＯＴ候補を抽出してメッセージ送信元のユーザ及び／ま
たはトークルーム内の他のメンバーに返信させることができる。
【0127】
本発明の一実施形態において、これらＢＯＴ候補は、ＢＯＴに紐付けられたＢＯＴ＿Ｉ
Ｄと各ＢＯＴを表わすキャラクタ画像及び／またはＢＯＴの発言であることを表わすメッ
セージとが含まれる。
Ｄと各ＢＯＴを表わすキャラクタ画像及び／またはＢＯＴの発言であることを表わすメッ
セージとが含まれる。
【0128】
（２）ユーザ端末からトークサーバへＢＯＴ＿ＩＤ（上述）が送信された場合
トークサーバでは、指定されたＢＯＴ＿ＩＤに基づいて対応するＢＯＴ（ＢＯＴサーバ
）にリクエストを行うこともできる。本発明の一実施形態においては、トークサーバから
ＢＯＴサーバに対して当該ＢＯＴサーバが現時点で用意している（つまり、その時点でト
ークルームでの会話の流れに沿って提供可能な）コンテンツ候補のリクエストが行われる
。
なお、一実施形態においては、ＢＯＴ＿ＩＤは、ユーザのメッセージとともに送信され
る場合もある。
トークサーバでは、指定されたＢＯＴ＿ＩＤに基づいて対応するＢＯＴ（ＢＯＴサーバ
）にリクエストを行うこともできる。本発明の一実施形態においては、トークサーバから
ＢＯＴサーバに対して当該ＢＯＴサーバが現時点で用意している（つまり、その時点でト
ークルームでの会話の流れに沿って提供可能な）コンテンツ候補のリクエストが行われる
。
なお、一実施形態においては、ＢＯＴ＿ＩＤは、ユーザのメッセージとともに送信され
る場合もある。
【0129】
（３）ユーザ端末からトークサーバへコンテンツが送信または指定された場合
トークサーバでは、ユーザから送信または指定されたコンテンツ（テキスト／音声情報
や画像情報、その他特定サイト等へのリンク先などが挙げられる）をグループ内の他メン
バーに送信（転送）する。
トークサーバでは、ユーザから送信または指定されたコンテンツ（テキスト／音声情報
や画像情報、その他特定サイト等へのリンク先などが挙げられる）をグループ内の他メン
バーに送信（転送）する。
【0130】
ステップＳ４２５において、ユーザに対するメッセージ等の受信がある（Ｙｅｓ）と、
ステップＳ４２６へ進み、ユーザ（あるいは当該ユーザが参加しているトークグループ）
にアシスタントＢＯＴが存在するか（つまり、紐付けられているか）どうかが判断され、
Ｙｅｓの場合はステップＳ４２７ａに進み、メッセージ（ステップＳ４２５で既受信）の
うちの一部または全部を選択する。そして、ステップＳ４２７ｂへ進み、アシスタントＢ
ＯＴ経由でトークサーバへ転送され、ステップＳ４２８へ進む（ステップＳ４２６におい
てＮｏの場合は、直接ステップＳ４２８へ進む）。
ステップＳ４２６へ進み、ユーザ（あるいは当該ユーザが参加しているトークグループ）
にアシスタントＢＯＴが存在するか（つまり、紐付けられているか）どうかが判断され、
Ｙｅｓの場合はステップＳ４２７ａに進み、メッセージ（ステップＳ４２５で既受信）の
うちの一部または全部を選択する。そして、ステップＳ４２７ｂへ進み、アシスタントＢ
ＯＴ経由でトークサーバへ転送され、ステップＳ４２８へ進む（ステップＳ４２６におい
てＮｏの場合は、直接ステップＳ４２８へ進む）。
【0131】
なお、ステップＳ４２７ａ～ステップＳ４２７ｂにおいて、受信メッセージのうちのど
の程度のメッセージをアシスタントＢＯＴ経由でトークサーバへ転送させるかは、ユーザ
による許可設定によって決まるが、後述する督促ＢＯＴについては非許可設定にはできな
いように（つまり、必ず許可させるように）運用することができる。
の程度のメッセージをアシスタントＢＯＴ経由でトークサーバへ転送させるかは、ユーザ
による許可設定によって決まるが、後述する督促ＢＯＴについては非許可設定にはできな
いように（つまり、必ず許可させるように）運用することができる。
【0132】
さらに、上記転送のタイミングは、一例として、（１）メッセージを受信するたびに当
該メッセージの少なくとも一部をトークサーバへ転送する、（２）受信メッセージを端末
上に表示させるたびに当該メッセージの少なくとも一部をトークサーバへ転送する、など
のバリエーションを適用することができる。
該メッセージの少なくとも一部をトークサーバへ転送する、（２）受信メッセージを端末
上に表示させるたびに当該メッセージの少なくとも一部をトークサーバへ転送する、など
のバリエーションを適用することができる。
【0133】
また、上記転送のタイミングにおいて、受信メッセージの少なくとも一部をトークサー
バへ転送する際に、当該一部のメッセージとともに、受信メッセージのうち端末には表示
されていないメッセージとを合わせてトークサーバへ転送させるように制御することもで
きる。
バへ転送する際に、当該一部のメッセージとともに、受信メッセージのうち端末には表示
されていないメッセージとを合わせてトークサーバへ転送させるように制御することもで
きる。
【0134】
ステップＳ４２８では、受信したメッセージ等がユーザ端末上に表示される。
【0135】
ステップＳ４２９において、ユーザに対するオブジェクト表示の受信がある（Ｙｅｓ）
と、ステップＳ４３０に進み、受信したオブジェクトの端末上での見せ方に関して適宜処
理する。そして、ステップＳ４３１へ進む（ステップＳ４２９においてＮｏの場合は、直
接ステップＳ４３１へ進む）。
と、ステップＳ４３０に進み、受信したオブジェクトの端末上での見せ方に関して適宜処
理する。そして、ステップＳ４３１へ進む（ステップＳ４２９においてＮｏの場合は、直
接ステップＳ４３１へ進む）。
【0136】
ステップＳ４３１において、図示しないユーザ操作によりトークルーム退室指示がされ
ると本フローとしては終了する（ステップＳ４３２）。ステップＳ４３１においてＮｏの
場合は、ステップＳ４２３へ復帰する。
ると本フローとしては終了する（ステップＳ４３２）。ステップＳ４３１においてＮｏの
場合は、ステップＳ４２３へ復帰する。
【0137】
図４Ｃは、主にトークサーバの観点から示された基本動作フローである。
図４ＣのステップＳ４５１において、トークサーバが処理を開始すると、ステップＳ４
５２に進み、トークルームを運営するための各種ステータス情報等がサーバ内のメモリに
読み込まれる。
図４ＣのステップＳ４５１において、トークサーバが処理を開始すると、ステップＳ４
５２に進み、トークルームを運営するための各種ステータス情報等がサーバ内のメモリに
読み込まれる。
【0138】
図５において、ステップＳ４５３～ステップＳ４６１までのループは、ユーザ同士のコ
ミュニケーションを運営するトークサーバの基本動作ループであり、トークサーバは、ス
テップＳ４６１において処理を終了しない限り、メッセージ等（典型的には、ＢＯＴ＿Ｉ
Ｄが含まれるメッセージと含まれないメッセージとがある。また、ＢＯＴ＿ＩＤのみのメ
ッセージもあり得る）あるいはコンテンツ（コンテンツそれ自体もしくはコンテンツを指
定するための指定メッセージが含まれる）の到来を待つ。
ミュニケーションを運営するトークサーバの基本動作ループであり、トークサーバは、ス
テップＳ４６１において処理を終了しない限り、メッセージ等（典型的には、ＢＯＴ＿Ｉ
Ｄが含まれるメッセージと含まれないメッセージとがある。また、ＢＯＴ＿ＩＤのみのメ
ッセージもあり得る）あるいはコンテンツ（コンテンツそれ自体もしくはコンテンツを指
定するための指定メッセージが含まれる）の到来を待つ。
【0139】
ステップＳ４５３では、メッセージ等の受信があったどうかが判断され、Ｎｏの場合は
ステップＳ４５９へ進むが、Ｙｅｓの場合はさらにステップＳ４５４へ進み、受信したメ
ッセージ等の中にＢＯＴ＿ＩＤが含まれるかどうかが判断される。ステップＳ４５４にお
いてＮｏの場合は他ユーザからのメッセージ等の受信であるため、ステップＳ４５７へ進
み、受信したメッセージ内容に沿った応答が可能なＢＯＴ（複数の場合も有り）を抽出ま
たは特定するための処理が行われる。一実施形態において、このＢＯＴの抽出または特定
処理は、トークサーバからＢＯＴサーバ（群）への問い合わせ及び応答によって実現され
る。
ステップＳ４５９へ進むが、Ｙｅｓの場合はさらにステップＳ４５４へ進み、受信したメ
ッセージ等の中にＢＯＴ＿ＩＤが含まれるかどうかが判断される。ステップＳ４５４にお
いてＮｏの場合は他ユーザからのメッセージ等の受信であるため、ステップＳ４５７へ進
み、受信したメッセージ内容に沿った応答が可能なＢＯＴ（複数の場合も有り）を抽出ま
たは特定するための処理が行われる。一実施形態において、このＢＯＴの抽出または特定
処理は、トークサーバからＢＯＴサーバ（群）への問い合わせ及び応答によって実現され
る。
【0140】
そして、ステップＳ４５８では、前ステップで抽出または特定されたＢＯＴ候補をトー
クグループ内の他ユーザに送信し、ステップＳ４５９へ進む。
なお、ステップＳ４５７及びステップＳ４５８は、必須のステップではなく、適宜省略
できる。
クグループ内の他ユーザに送信し、ステップＳ４５９へ進む。
なお、ステップＳ４５７及びステップＳ４５８は、必須のステップではなく、適宜省略
できる。
【0141】
一方、ステップＳ４５４においてＹｅｓの場合は、典型的には受信したメッセージが（
既に提示済の）ＢＯＴ候補に対する指定であるため、ステップＳ４５５へ進み、指定され
た特定のＢＯＴ（サーバ）に対し、コンテンツまたはコンテンツ候補のリクエストを送信
する。次に、特定のＢＯＴ（サーバ）からコンテンツ候補が送信されてきた場合にはステ
ップＳ４５６にて受信したコンテンツ候補をメッセージ送信元のユーザ端末へ送信すると
ともに、このユーザ端末を介して（あるいはこのユーザ端末を介することなく）上述のコ
ンテンツ候補を他ユーザの端末にも送信し、コンテンツのリアルタイム共有を実現する。
そして、ステップＳ４５９へ進む。
既に提示済の）ＢＯＴ候補に対する指定であるため、ステップＳ４５５へ進み、指定され
た特定のＢＯＴ（サーバ）に対し、コンテンツまたはコンテンツ候補のリクエストを送信
する。次に、特定のＢＯＴ（サーバ）からコンテンツ候補が送信されてきた場合にはステ
ップＳ４５６にて受信したコンテンツ候補をメッセージ送信元のユーザ端末へ送信すると
ともに、このユーザ端末を介して（あるいはこのユーザ端末を介することなく）上述のコ
ンテンツ候補を他ユーザの端末にも送信し、コンテンツのリアルタイム共有を実現する。
そして、ステップＳ４５９へ進む。
【0142】
ステップＳ４５９では、コンテンツそれ自体あるいはコンテンツへの指定メッセージの
受信があったかどうかが判断され、Ｙｅｓの場合はステップＳ４６０へ進み、コンテンツ
をグループ内の他ユーザへ送信する（ステップＳ４５９において、Ｎｏの場合はステップ
Ｓ４６１へ進む）。このとき、受信したメッセージがコンテンツへの指定メッセージ（一
例として、ＵＲＬの特定によって入手可能なコンテンツ情報）である場合には必要に応じ
てトークサーバにおいて当該コンテンツを取得してこれをグループ内の他ユーザへ送信す
る。そして、ステップＳ４６１へ進む。
受信があったかどうかが判断され、Ｙｅｓの場合はステップＳ４６０へ進み、コンテンツ
をグループ内の他ユーザへ送信する（ステップＳ４５９において、Ｎｏの場合はステップ
Ｓ４６１へ進む）。このとき、受信したメッセージがコンテンツへの指定メッセージ（一
例として、ＵＲＬの特定によって入手可能なコンテンツ情報）である場合には必要に応じ
てトークサーバにおいて当該コンテンツを取得してこれをグループ内の他ユーザへ送信す
る。そして、ステップＳ４６１へ進む。
【0143】
ステップＳ４６１では、トークサーバとしての動作を終了するかどうかが判断され、図
示しない操作によりトークサーバの動作を終了する（ステップＳ４６１においてＹｅｓ）
場合には、ステップＳ４６２へ進み、本フローとしては終了するが、ステップＳ４６１に
おいてＮｏの場合には、ステップＳ４５３へ復帰する。
示しない操作によりトークサーバの動作を終了する（ステップＳ４６１においてＹｅｓ）
場合には、ステップＳ４６２へ進み、本フローとしては終了するが、ステップＳ４６１に
おいてＮｏの場合には、ステップＳ４５３へ復帰する。
【0144】
［支払い等の勘定フローを実行するための機能モジュールのまとめ］
図５に、本発明の一実施形態に係るシステム等における動作の機能概念を示す。特に、
図２～図４Ｃを参照して説明した各機能は、図１における制御装置１１１０（サーバ側）
及び制御装置１５１０（端末側）での拡張された処理部を要求するものであるので、ここ
では、それぞれの機能について説明する。
図５に、本発明の一実施形態に係るシステム等における動作の機能概念を示す。特に、
図２～図４Ｃを参照して説明した各機能は、図１における制御装置１１１０（サーバ側）
及び制御装置１５１０（端末側）での拡張された処理部を要求するものであるので、ここ
では、それぞれの機能について説明する。
【0145】
これまで説明したとおり、本発明の一実施形態に係るシステム等は、大きくは幹事者端
末上での集金ＵＩ等提供機能５１０と参加者・保証人、その他の友人等の端末上での集金
ＵＩ提供機能５２０とを含むものであるが、これらは適宜サーバ１１０等と連携あるいは
同期され（これに伴い、幹事者端末と参加者等端末とが連携され）、それぞれの機能の実
体は、記憶装置１１０５及び１５１５に記憶された各種プログラム及び各種データが、制
御装置１１１０及び制御装置１５１０に適宜読み込まれて実行される諸機能として実現さ
れるものである（以下に述べる下位機能についても同じ）。
末上での集金ＵＩ等提供機能５１０と参加者・保証人、その他の友人等の端末上での集金
ＵＩ提供機能５２０とを含むものであるが、これらは適宜サーバ１１０等と連携あるいは
同期され（これに伴い、幹事者端末と参加者等端末とが連携され）、それぞれの機能の実
体は、記憶装置１１０５及び１５１５に記憶された各種プログラム及び各種データが、制
御装置１１１０及び制御装置１５１０に適宜読み込まれて実行される諸機能として実現さ
れるものである（以下に述べる下位機能についても同じ）。
【0146】
図５において、幹事者端末上での集金ＵＩ等提供機能５１０は、大別すると、既に述べ
たとおり、領収書等の読み取り機能、金額確認（集計）機能、割り勘方法等選択機能、各
種算出機能、各種通知機能を含むものであるが、より詳細には、集金リスト作成ＵＩ提供
機能５１１と集金ＵＩ提供機能５１２とに区分され、それぞれ次表のとおりのサブ機能を
有する。
たとおり、領収書等の読み取り機能、金額確認（集計）機能、割り勘方法等選択機能、各
種算出機能、各種通知機能を含むものであるが、より詳細には、集金リスト作成ＵＩ提供
機能５１１と集金ＵＩ提供機能５１２とに区分され、それぞれ次表のとおりのサブ機能を
有する。
【表3】
【0147】
また、参加者等端末上での集金ＵＩ等提供機能５２０も、大別すると、既に述べたとお
り、領収書等の読み取り機能、金額確認（集計）機能、割り勘方法等選択機能、各種算出
機能、各種通知機能を含むものであるが、より詳細には、参加者機能５２１と保証人機能
５２２とに区分され、それぞれ次表のとおりのサブ機能を有する。
り、領収書等の読み取り機能、金額確認（集計）機能、割り勘方法等選択機能、各種算出
機能、各種通知機能を含むものであるが、より詳細には、参加者機能５２１と保証人機能
５２２とに区分され、それぞれ次表のとおりのサブ機能を有する。
【表4】
【0148】
＜第２実施形態＞
第２実施形態は、複数のユーザ端末（一例として、幹事端末及び参加者端末Ａ～Ｃ、参
加者となる場合もある保証人端末、友人端末）の間の支払いやメッセージ等のやりとりを
システム全体の運用シーンとして説明するものである。トークルームの説明でも明らかな
ように、ユーザ端末間のメッセージ交換においてもサーバが関与するが、ここでは理解の
容易のためにサーバの存在を割愛している（実際には、サーバは適宜関与する）。
なお、第２実施形態に記載された内容の一部又は全部は、その特徴が相互に排他的であ
る場合を除いて他の実施形態にも適用可能である。
また、実施形態において例示される動作または処理時刻（ｔ１等）は、本発明の概念の
理解の容易のために例示されたものであり、本発明が実施形態において例示される個別の
時系列関係に制限されることはない（以下、時刻を明示して例示している実施形態におい
て同様である）。また、人同士のやり取りのように記載されているところは、それぞれが
所持する端末同士のやり取り、あるいは、サーバを介した端末同士のやり取りである。
以下、図６を参照して説明する。
第２実施形態は、複数のユーザ端末（一例として、幹事端末及び参加者端末Ａ～Ｃ、参
加者となる場合もある保証人端末、友人端末）の間の支払いやメッセージ等のやりとりを
システム全体の運用シーンとして説明するものである。トークルームの説明でも明らかな
ように、ユーザ端末間のメッセージ交換においてもサーバが関与するが、ここでは理解の
容易のためにサーバの存在を割愛している（実際には、サーバは適宜関与する）。
なお、第２実施形態に記載された内容の一部又は全部は、その特徴が相互に排他的であ
る場合を除いて他の実施形態にも適用可能である。
また、実施形態において例示される動作または処理時刻（ｔ１等）は、本発明の概念の
理解の容易のために例示されたものであり、本発明が実施形態において例示される個別の
時系列関係に制限されることはない（以下、時刻を明示して例示している実施形態におい
て同様である）。また、人同士のやり取りのように記載されているところは、それぞれが
所持する端末同士のやり取り、あるいは、サーバを介した端末同士のやり取りである。
以下、図６を参照して説明する。
【0149】
図６に示される本発明の一実施形態において、時刻ｔ１までに幹事端末上でイベントペ
ージが作成され、予め招待する参加者リスト（事前参加者リスト）が作成されるなどして
、招待メンバー（Ａ～Ｃ）に対してイベント参加ＵＩが発信される（ステップＳ６０１）
。次に、時刻ｔ２には、それぞれの端末からイベント参加表明が返信される（ステップＳ
６０２）。なお、図６の時刻ｔ２においては、説明の便宜上、イベント参加表明を表わす
矢印は１本のみであるが、複数の参加者の返信があるものとする（以下、後述する通知や
支払等の各処理について、ステップＳ３０５で説明するような特段の断りがある場合を除
き、同様）。
ージが作成され、予め招待する参加者リスト（事前参加者リスト）が作成されるなどして
、招待メンバー（Ａ～Ｃ）に対してイベント参加ＵＩが発信される（ステップＳ６０１）
。次に、時刻ｔ２には、それぞれの端末からイベント参加表明が返信される（ステップＳ
６０２）。なお、図６の時刻ｔ２においては、説明の便宜上、イベント参加表明を表わす
矢印は１本のみであるが、複数の参加者の返信があるものとする（以下、後述する通知や
支払等の各処理について、ステップＳ３０５で説明するような特段の断りがある場合を除
き、同様）。
【0150】
時刻ｔ３～ｔ４まで、図示しない会場にてイベントが実施される。本発明の一実施形態
において、参加者は自身の端末を持参してこのイベントに参加している。
において、参加者は自身の端末を持参してこのイベントに参加している。
【0151】
次に、時刻ｔ５までにイベントに際して発生した費用につき、幹事から参加者へ支払い
依頼が行われる（ステップＳ６０３）。本発明はこれに限定されるものではないが、ここ
では、幹事がいったん一括立替支払いをする（そして、その後各参加者に請求する）こと
もできるし、幹事が一括支払いするために各端末から費用を徴収する（そして、その後一
括支払いする）ように処理を進行させることもできる。
依頼が行われる（ステップＳ６０３）。本発明はこれに限定されるものではないが、ここ
では、幹事がいったん一括立替支払いをする（そして、その後各参加者に請求する）こと
もできるし、幹事が一括支払いするために各端末から費用を徴収する（そして、その後一
括支払いする）ように処理を進行させることもできる。
【0152】
時刻ｔ６には、参加者Ａ～Ｃより各自の端末から幹事端末へ支払い方法や支払時期（支
払期限）についての通知がなされる（ステップＳ６０４）。これらの情報はサーバにも記
録管理させることができる（以下、端末同士でやり取りされる情報について、同様）。
そして、ここからは、発明の理解のために参加者Ａ～Ｃの対応（及び、参加者Ａ～Ｃへ
の対応）を異ならしめており、それらの前提のもとに説明を続ける。
払期限）についての通知がなされる（ステップＳ６０４）。これらの情報はサーバにも記
録管理させることができる（以下、端末同士でやり取りされる情報について、同様）。
そして、ここからは、発明の理解のために参加者Ａ～Ｃの対応（及び、参加者Ａ～Ｃへ
の対応）を異ならしめており、それらの前提のもとに説明を続ける。
【0153】
［参加者Ａの対応］
時刻ｔ７には、参加者Ａより幹事への支払いが行われる（ステップＳ６０５）。本発明
の一実施形態においては、参加者Ａの端末より幹事端末へ電子バリューの送金（送信また
は移動）がなされるものであるが、本発明はこれに限定されるものではなく、最終的に決
済等が行われるために必須となる情報処理であればよい。
時刻ｔ７には、参加者Ａより幹事への支払いが行われる（ステップＳ６０５）。本発明
の一実施形態においては、参加者Ａの端末より幹事端末へ電子バリューの送金（送信また
は移動）がなされるものであるが、本発明はこれに限定されるものではなく、最終的に決
済等が行われるために必須となる情報処理であればよい。
【0154】
［参加者Ｂ等への対応］
時刻ｔ８～時刻ｔ１２までは、参加者Ｂ及び参加者Ｂの保証人への対応例を示す動作フ
ローである。時刻ｔ８は、時刻ｔ６から既に所定期間が経過している。具体的には、参加
者Ｂの幹事への支払い期限が（場合によっては大幅に）過ぎているなどである。時刻ｔ８
では、まず、幹事から参加者Ｂへの支払いの督促通知が行われる（ステップＳ６０６）。
この督促通知の発信元は必ずしも幹事端末である必要はなく、サーバの期限管理に基づい
てサーバ主体で行われてもよい（以下、通知等の主体について同様）。
時刻ｔ８～時刻ｔ１２までは、参加者Ｂ及び参加者Ｂの保証人への対応例を示す動作フ
ローである。時刻ｔ８は、時刻ｔ６から既に所定期間が経過している。具体的には、参加
者Ｂの幹事への支払い期限が（場合によっては大幅に）過ぎているなどである。時刻ｔ８
では、まず、幹事から参加者Ｂへの支払いの督促通知が行われる（ステップＳ６０６）。
この督促通知の発信元は必ずしも幹事端末である必要はなく、サーバの期限管理に基づい
てサーバ主体で行われてもよい（以下、通知等の主体について同様）。
【0155】
時刻ｔ９は、時刻ｔ８からさらに所定時間経過しているか、あるいは、時刻ｔ８の直後
であってもよい。時刻ｔ９には、幹事端末（あるいは、サーバ）から参加者Ｂの保証人の
端末に対し、参加者Ｂの未払い通知が行われる（ステップＳ６０７）。その通知画面例は
、図示しないシンプルな未払い通知であっても良いが、本発明はこれに限定されることは
なく、図１０を参照して例示したような立替可否問い合わせ通知であってもよい（本動作
フローでは、保証人への立替可否問い合わせ通知とする）。
また、保証人への立替可否問い合わせ通知に先だって上述の未払い通知を行うようにし
てもよい。
であってもよい。時刻ｔ９には、幹事端末（あるいは、サーバ）から参加者Ｂの保証人の
端末に対し、参加者Ｂの未払い通知が行われる（ステップＳ６０７）。その通知画面例は
、図示しないシンプルな未払い通知であっても良いが、本発明はこれに限定されることは
なく、図１０を参照して例示したような立替可否問い合わせ通知であってもよい（本動作
フローでは、保証人への立替可否問い合わせ通知とする）。
また、保証人への立替可否問い合わせ通知に先だって上述の未払い通知を行うようにし
てもよい。
【0156】
なお、ステップＳ６０６及びステップＳ６０７のアプリケーションとしての通知主体は
、既述のＢＯＴによるものとしてもよい（いわゆる督促ＢＯＴによる督促処理）。
この場合、ＢＯＴには、ステップＳ６０６やステップＳ６０７における督促先及び／ま
たは通知先ユーザの不許可設定を乗り越えて督促及び／または通知を行わせることができ
る（督促先及び／または通知先ユーザの不許可設定により、当該ＢＯＴの連絡等が拒否さ
れてしまうことを防止するためである）。
、既述のＢＯＴによるものとしてもよい（いわゆる督促ＢＯＴによる督促処理）。
この場合、ＢＯＴには、ステップＳ６０６やステップＳ６０７における督促先及び／ま
たは通知先ユーザの不許可設定を乗り越えて督促及び／または通知を行わせることができ
る（督促先及び／または通知先ユーザの不許可設定により、当該ＢＯＴの連絡等が拒否さ
れてしまうことを防止するためである）。
【0157】
時刻ｔ１０には、参加者Ｂの保証人が参加者Ｂの費用の立替支払に同意し、保証人から
幹事への立替支払処理がなされる（ステップＳ６０８）。これに限定されるものではない
が、具体例として電子バリューによる支払いが行われる。
幹事への立替支払処理がなされる（ステップＳ６０８）。これに限定されるものではない
が、具体例として電子バリューによる支払いが行われる。
【0158】
時刻ｔ１１には、参加者Ｂの保証人から参加者Ｂへの立替支払通知が行われ（ステップ
Ｓ６０９）、時刻ｔ１２には、参加者Ｂから参加者Ｂの保証人への支払い（いわゆる返済
）が行われる（ステップＳ６１０）。本発明の一実施形態として、ステップＳ６１０にて
返済が行われるのは、参加者Ｂと参加者Ｂの保証人との間の保証関係が立替時の返済義務
ありとして登録あるいは設定されているからである。両者の間で返済義務なしの保証関係
が結ばれている場合には、ステップＳ６１０は不要であり省略される。
Ｓ６０９）、時刻ｔ１２には、参加者Ｂから参加者Ｂの保証人への支払い（いわゆる返済
）が行われる（ステップＳ６１０）。本発明の一実施形態として、ステップＳ６１０にて
返済が行われるのは、参加者Ｂと参加者Ｂの保証人との間の保証関係が立替時の返済義務
ありとして登録あるいは設定されているからである。両者の間で返済義務なしの保証関係
が結ばれている場合には、ステップＳ６１０は不要であり省略される。
【0159】
［参加者Ｃへの対応］
時刻ｔ１３～時刻ｔ１４までは、参加者Ｃ及び参加者Ｃの友人への対応例を示す動作フ
ローである。時刻ｔ１３は、時刻ｔ６から既に所定期間が経過している。具体的には、参
加者Ｃの幹事への支払い期限が過ぎているなどである。時刻ｔ１３では、まず、幹事から
参加者Ｃの友人への未払い通知が行われる（ステップＳ６１１）。この未払い通知の発信
元は必ずしも幹事端末である必要はなく、サーバの期限管理に基づいてサーバ主体で行わ
れてもよい（以下、同様）。そして、参加者の友人への未払い通知の通知画面例は、図１
１Ａを参照して説明したとおりである。
時刻ｔ１３～時刻ｔ１４までは、参加者Ｃ及び参加者Ｃの友人への対応例を示す動作フ
ローである。時刻ｔ１３は、時刻ｔ６から既に所定期間が経過している。具体的には、参
加者Ｃの幹事への支払い期限が過ぎているなどである。時刻ｔ１３では、まず、幹事から
参加者Ｃの友人への未払い通知が行われる（ステップＳ６１１）。この未払い通知の発信
元は必ずしも幹事端末である必要はなく、サーバの期限管理に基づいてサーバ主体で行わ
れてもよい（以下、同様）。そして、参加者の友人への未払い通知の通知画面例は、図１
１Ａを参照して説明したとおりである。
【0160】
時刻ｔ１４には、参加者Ｃの友人が参加者Ｃへ支払いの督促を行う（ステップＳ６１２
）。参加者Ｃは、幹事から督促されるよりも親しい友人に督促されるので、早急に幹事へ
の支払いを行うことが期待される。
）。参加者Ｃは、幹事から督促されるよりも親しい友人に督促されるので、早急に幹事へ
の支払いを行うことが期待される。
【0161】
なお、ステップＳ６１１及びステップＳ６１２のアプリケーションとしての通知主体は
、既述のＢＯＴによるものとしてもよい（いわゆる督促ＢＯＴによる督促処理）。
この場合、ＢＯＴには、ステップＳ６１１やステップＳ６１２における督促先及び／ま
たは通知先ユーザの不許可設定を乗り越えて督促及び／または通知を行わせることができ
る（督促先及び／または通知先ユーザの不許可設定により、当該ＢＯＴの連絡等が拒否さ
れてしまうことを防止するためである）。
、既述のＢＯＴによるものとしてもよい（いわゆる督促ＢＯＴによる督促処理）。
この場合、ＢＯＴには、ステップＳ６１１やステップＳ６１２における督促先及び／ま
たは通知先ユーザの不許可設定を乗り越えて督促及び／または通知を行わせることができ
る（督促先及び／または通知先ユーザの不許可設定により、当該ＢＯＴの連絡等が拒否さ
れてしまうことを防止するためである）。
【0162】
特に、図１１Ｂに、ＢＯＴによる第三者通知のバリエーションを行った場合の通知画面
例を示す。図１１Ｂには、トークルームでのコミュニケーションを行っているユーザ端末
の画面１１５０が示されており、画面１１５０上部には端末ステータス１５０１が表示さ
れるほか、トークルーム画面内に種々のメッセージが時系列（上から下への流れ）で表示
されている。
例を示す。図１１Ｂには、トークルームでのコミュニケーションを行っているユーザ端末
の画面１１５０が示されており、画面１１５０上部には端末ステータス１５０１が表示さ
れるほか、トークルーム画面内に種々のメッセージが時系列（上から下への流れ）で表示
されている。
【0163】
このトークルーム画面において、メッセージ１１６１、１１６２は、当該画面を表示し
ているユーザ端末以外のユーザ端末から送られてきたものであり、メッセージ１１６３、
１１６４は、当該画面を表示しているユーザ端末から発信されたものである。
そして、メッセージ１１７０、１１８０は、上述のメッセージやり取りの流れを判断し
てＢＯＴが未払い者●●への督促あるいは通知を行うメッセージとなっている。
ているユーザ端末以外のユーザ端末から送られてきたものであり、メッセージ１１６３、
１１６４は、当該画面を表示しているユーザ端末から発信されたものである。
そして、メッセージ１１７０、１１８０は、上述のメッセージやり取りの流れを判断し
てＢＯＴが未払い者●●への督促あるいは通知を行うメッセージとなっている。
【0164】
本発明の一実施形態として、メッセージ１１７０、１１８０が発生する条件は、次のよ
うなものが考えられる。
（１）未払い者の支払い期限が経過してさらに一定の期間が経過したこと。
（２）トークルームに未払い者あるいは未払い者の友人もしくは保証人が参加中であるこ
と。
うなものが考えられる。
（１）未払い者の支払い期限が経過してさらに一定の期間が経過したこと。
（２）トークルームに未払い者あるいは未払い者の友人もしくは保証人が参加中であるこ
と。
【0165】
なお、図１１Ｂにおいては、立替の返済義務ありの場合の督促通知例を示したが、本発
明はこれに限定されることはなく、立替の返済義務なしの場合の御礼督促通知をＢＯＴに
行わせることもできる。この場合、メッセージ１１７０は「そういえば、●●さんは、△
△さんに立替えてもらったお礼をまだ言ってないよ～」などとなり、メッセージ１１８０
は「●●さん！△△さんにお礼をいわなきゃ」などとされる。こうした御礼督促もソーシ
ャルメッセージングにおけるマナー向上に寄与するものとなる。
もちろん、立替の返済義務なしの場合には、特にＢＯＴに督促通知を行わせないように
運用することもできる。
明はこれに限定されることはなく、立替の返済義務なしの場合の御礼督促通知をＢＯＴに
行わせることもできる。この場合、メッセージ１１７０は「そういえば、●●さんは、△
△さんに立替えてもらったお礼をまだ言ってないよ～」などとなり、メッセージ１１８０
は「●●さん！△△さんにお礼をいわなきゃ」などとされる。こうした御礼督促もソーシ
ャルメッセージングにおけるマナー向上に寄与するものとなる。
もちろん、立替の返済義務なしの場合には、特にＢＯＴに督促通知を行わせないように
運用することもできる。
【0166】
＜第３実施形態＞
第３実施形態は、第三者からグループへ送金する本発明のバリエーションを説明するも
のである。このバリエーションによれば、例えば、イベントには参加しないが資金の提供
（寄付）はしたいというグループ内外の第三者から、当該グループ（あるいは、イベント
に参加するメンバーで構成されるサブグループ）への送金を実現することができる。また
、本実施形態の送金方法は、近年普及しつつある電子紅包（情報処理端末を介して電子マ
ネーを贈るオンラインお年玉）にも応用可能である。
なお、第３実施形態に記載された内容の一部又は全部は、その特徴が相互に排他的であ
る場合を除いて他の実施形態にも適用可能である。
第３実施形態は、第三者からグループへ送金する本発明のバリエーションを説明するも
のである。このバリエーションによれば、例えば、イベントには参加しないが資金の提供
（寄付）はしたいというグループ内外の第三者から、当該グループ（あるいは、イベント
に参加するメンバーで構成されるサブグループ）への送金を実現することができる。また
、本実施形態の送金方法は、近年普及しつつある電子紅包（情報処理端末を介して電子マ
ネーを贈るオンラインお年玉）にも応用可能である。
なお、第３実施形態に記載された内容の一部又は全部は、その特徴が相互に排他的であ
る場合を除いて他の実施形態にも適用可能である。
【0167】
図１２に、基本動作フローを示す。図１２のステップＳ１２０１にて図示しない端末画
面を介して送金予約設定処理が開始されると、ステップＳ１２０２へ進み、送金先グルー
プが設定される。本発明の一実施形態においては、送金は自動的に行われ、そのための送
金条件は、後続するステップＳ１２０３にて図示しない設定画面を介して設定される。
面を介して送金予約設定処理が開始されると、ステップＳ１２０２へ進み、送金先グルー
プが設定される。本発明の一実施形態においては、送金は自動的に行われ、そのための送
金条件は、後続するステップＳ１２０３にて図示しない設定画面を介して設定される。
【0168】
また、本発明の特徴として、送金先は複数の個人宛に設定できるのみならず、グループ
単位でも設定することができる。複数の個人宛に設定した場合は、当該設定後の送金先は
固定されてしまうが、グループ単位で設定した場合には、当該設定後にグループの構成メ
ンバーが変化した場合にも送金が実施された時点での構成メンバーへの送金が可能となる
（なお、ここでいう送金は、ここまで説明してきた電子バリューの送信あるいは端末間移
動と同様の趣旨である。以下、同じ）。
単位でも設定することができる。複数の個人宛に設定した場合は、当該設定後の送金先は
固定されてしまうが、グループ単位で設定した場合には、当該設定後にグループの構成メ
ンバーが変化した場合にも送金が実施された時点での構成メンバーへの送金が可能となる
（なお、ここでいう送金は、ここまで説明してきた電子バリューの送信あるいは端末間移
動と同様の趣旨である。以下、同じ）。
【0169】
このようなグループ単位での送金先設定ができることで、上述したイベント参加型のグ
ループに対して出資や寄付をする場合にも、イベント開始にあたって、または、終了時に
確定した参加メンバーに対して、正確かつ確実に出資あるいは寄付できることとなる。
ループに対して出資や寄付をする場合にも、イベント開始にあたって、または、終了時に
確定した参加メンバーに対して、正確かつ確実に出資あるいは寄付できることとなる。
【0170】
ステップＳ１２０３では、送金条件が設定される。条件の設定は、送金タイミング及び
送金時の分配について設定することができる。本発明はこれらに限定されるものではない
が、送金タイミングについては、次のようなものが挙げられる。
（１）グループが取り組んでいる何らかの行事が完了したとき。
（２）送金者（または受信者）の取り組み（試験や競技など）でいい結果が出た時。
送金時の分配について設定することができる。本発明はこれらに限定されるものではない
が、送金タイミングについては、次のようなものが挙げられる。
（１）グループが取り組んでいる何らかの行事が完了したとき。
（２）送金者（または受信者）の取り組み（試験や競技など）でいい結果が出た時。
【0171】
また、送金時の分配については、次のようなものが挙げられる。
（１）グループの代表者に預ける。
（２）グループメンバーへ均等割り。
（３）グループが取り組んでいる行事での各メンバーの達成度に応じて分配。
（１）グループの代表者に預ける。
（２）グループメンバーへ均等割り。
（３）グループが取り組んでいる行事での各メンバーの達成度に応じて分配。
【0172】
以上の送金条件設定が完了すると、ステップＳ１２０４へ進み、送金予約設定処理は完
了する。
了する。
【0173】
【0174】
ステップＳ１３０１では、図１２において設定された送金条件（のうち、送金タイミン
グに関する条件）に基づき、イベントトリガあるいはイベントハンドラが開始されると、
ステップＳ１３０２へ進み、送金条件（あるいは支払い条件）を見たすイベントが発生し
たかどうかが判断される。ステップＳ１３０２においてＮｏの場合は再びステップＳ１３
０２へ戻る（いわゆるイベント待ちの状態となる）が、Ｙｅｓの場合はステップＳ１３０
３へ進む。
グに関する条件）に基づき、イベントトリガあるいはイベントハンドラが開始されると、
ステップＳ１３０２へ進み、送金条件（あるいは支払い条件）を見たすイベントが発生し
たかどうかが判断される。ステップＳ１３０２においてＮｏの場合は再びステップＳ１３
０２へ戻る（いわゆるイベント待ちの状態となる）が、Ｙｅｓの場合はステップＳ１３０
３へ進む。
【0175】
ステップＳ１３０３では、送金先グループ情報が読み出される。このとき、この時点で
所属しているメンバーが読み出されるので、あるグループにおいて特定のイベント参加グ
ループを募った場合の特定参加グループへの送金は、この時点での参加者に対して割り振
られることとなる。あるいは、本発明の他の実施形態として、常にグループ全体への積立
金のように送金されてもよい。
所属しているメンバーが読み出されるので、あるグループにおいて特定のイベント参加グ
ループを募った場合の特定参加グループへの送金は、この時点での参加者に対して割り振
られることとなる。あるいは、本発明の他の実施形態として、常にグループ全体への積立
金のように送金されてもよい。
【0176】
ステップＳ１３０４では、送金対象となるグループのメンバーに対する送金割り当て処
理が行われ、ステップＳ１３０５において、グループメンバーに対する送金処理が実施さ
れる。このとき、必要に応じて送金元（送金者）へ送金完了通知が行われてもよい。
そして、ステップＳ１３０６へ進み、送金処理は完了する。
理が行われ、ステップＳ１３０５において、グループメンバーに対する送金処理が実施さ
れる。このとき、必要に応じて送金元（送金者）へ送金完了通知が行われてもよい。
そして、ステップＳ１３０６へ進み、送金処理は完了する。
【0177】
＜第４実施形態＞
第４実施形態は、図６のステップＳ６０３における支払依頼のバリエーション例であり
、集金開始から割り勘処理あるいは分担支払い処理までを詳細に説明するものである。以
下、図１４を参照して説明する。
なお、第４実施形態に記載された内容の一部又は全部は、その特徴が相互に排他的であ
る場合を除いて他の実施形態にも適用可能である。
第４実施形態は、図６のステップＳ６０３における支払依頼のバリエーション例であり
、集金開始から割り勘処理あるいは分担支払い処理までを詳細に説明するものである。以
下、図１４を参照して説明する。
なお、第４実施形態に記載された内容の一部又は全部は、その特徴が相互に排他的であ
る場合を除いて他の実施形態にも適用可能である。
【0178】
図１４のステップＳ１４０１において処理を開始すると、ステップＳ１４０２へ進み、
幹事端末においてイベント参加者の読み出しが行われる。この読み出しは、トークルーム
の登録メンバーを幹事端末において読み出させることとしても良いが、本発明は必ずしも
これに制限されることはなく、サーバ上で管理される何らかのグループに登録されたメン
バーを読み出すように運用することもできる（つまり、第４実施形態以降の実施形態にお
いては、イベント参加は必ずしもトークルームに登録されたメンバーである必要はない）
。
なお、本発明の他の実施形態においては、本ステップは省略可である（この場合、ステ
ップＳ１４０１からステップＳ１４０３へスキップする）。
幹事端末においてイベント参加者の読み出しが行われる。この読み出しは、トークルーム
の登録メンバーを幹事端末において読み出させることとしても良いが、本発明は必ずしも
これに制限されることはなく、サーバ上で管理される何らかのグループに登録されたメン
バーを読み出すように運用することもできる（つまり、第４実施形態以降の実施形態にお
いては、イベント参加は必ずしもトークルームに登録されたメンバーである必要はない）
。
なお、本発明の他の実施形態においては、本ステップは省略可である（この場合、ステ
ップＳ１４０１からステップＳ１４０３へスキップする）。
【0179】
ステップＳ１４０３では、幹事端末からその場（イベント会場など）に居合わせている
参加者端末への支払いの呼び掛けが行われる。本発明の一実施形態においては、近接無線
通信（ＮＦＣ）を使った集金通知が行われてもよい。
参加者端末への支払いの呼び掛けが行われる。本発明の一実施形態においては、近接無線
通信（ＮＦＣ）を使った集金通知が行われてもよい。
【0180】
ステップＳ１４０４では、幹事端末において、集金通知を受けた参加者端末からの支払
い応募を待つ（ステップＳ１４０４においてＮｏとなり、本ステップへ復帰するループ）
。本発明の一実施形態においては、参加者端末の支払い応募は、近接無線通信（ＮＦＣ）
によって行われる（伝達される）。あるいは、自端末をシェイク（Shake）することによ
って行われる（伝達される）。ここで、シェイク動作は、端末に内蔵された加速度センサ
等によって端末の揺れとして検知され、これを集金通知への肯定的な応答とすることがで
きる。
その他、参加者端末の支払い応募は、他の手段（音波、磁気による伝達手段）によって
伝達されてもよい。
ステップＳ１４０４でＹｅｓとなれば、ステップＳ１４０５へ進む。
い応募を待つ（ステップＳ１４０４においてＮｏとなり、本ステップへ復帰するループ）
。本発明の一実施形態においては、参加者端末の支払い応募は、近接無線通信（ＮＦＣ）
によって行われる（伝達される）。あるいは、自端末をシェイク（Shake）することによ
って行われる（伝達される）。ここで、シェイク動作は、端末に内蔵された加速度センサ
等によって端末の揺れとして検知され、これを集金通知への肯定的な応答とすることがで
きる。
その他、参加者端末の支払い応募は、他の手段（音波、磁気による伝達手段）によって
伝達されてもよい。
ステップＳ１４０４でＹｅｓとなれば、ステップＳ１４０５へ進む。
【0181】
ステップＳ１４０５では、支払い応募者（支払いに応じる者）を支払メンバーに追加す
る。そして、ステップＳ１４０６へ進み、支払い応募（呼び掛け）を終了するかどうかが
判断される。この判断は、呼び掛けた参加者全員の応答を待って終了するという基準を採
用してもよいし、一定数以上の応募を以って幹事者端末側で打ち切ることとしてもよい。
ステップＳ１４０６でＮｏの場合は、ステップＳ１４０４へ復帰するが、Ｙｅｓの場合は
ステップＳ１４０７へ進む。
る。そして、ステップＳ１４０６へ進み、支払い応募（呼び掛け）を終了するかどうかが
判断される。この判断は、呼び掛けた参加者全員の応答を待って終了するという基準を採
用してもよいし、一定数以上の応募を以って幹事者端末側で打ち切ることとしてもよい。
ステップＳ１４０６でＮｏの場合は、ステップＳ１４０４へ復帰するが、Ｙｅｓの場合は
ステップＳ１４０７へ進む。
【0182】
ステップＳ１４０７では、支払メンバー内での支払い額の分担調整が行われる。本発明
の一実施形態においては、均等割り処理が実施されるが本発明はこれに限定されることは
なく、種々の調整が可能である。さらなるバリエーションについては、図１５等を参照し
て詳述する。
の一実施形態においては、均等割り処理が実施されるが本発明はこれに限定されることは
なく、種々の調整が可能である。さらなるバリエーションについては、図１５等を参照し
て詳述する。
【0183】
ステップＳ１４０８では、支払メンバー間あるいは支払メンバーとその他の参加者メン
バーとの間での調整処理が行われる。例えば、支払メンバーＤ、Ｅ、Ｆがいたとして、Ｄ
がＥ及びＦの分を立替えた場合には、後日Ｅ及びＦはＤへ立替え分を返済する。あるいは
、先輩が立替えた分（一例として１００００円）の何割かは後日後輩達が支払う（一例と
して、一律１０００円）などである。
バーとの間での調整処理が行われる。例えば、支払メンバーＤ、Ｅ、Ｆがいたとして、Ｄ
がＥ及びＦの分を立替えた場合には、後日Ｅ及びＦはＤへ立替え分を返済する。あるいは
、先輩が立替えた分（一例として１００００円）の何割かは後日後輩達が支払う（一例と
して、一律１０００円）などである。
【0184】
以上の処理を経て、本フローとしては終了する（ステップＳ１４０９）。
【0185】
＜第５実施形態＞
第５実施形態は、ユーザ端末上での画面表示例にフォーカスして本発明の一実施形態に
おける特徴を説明するものである。以下、図１５～図１９を参照して説明する。
なお、第５実施形態に記載された内容の一部又は全部は、その特徴が相互に排他的であ
る場合を除いて他の実施形態にも適用可能である。
特に、ユーザインタフェースに特化した第５実施形態は、必ずしもユーザ端末間あるい
はサーバを介した電子バリューの送受信を伴う必要はなく、現金でのやり取りを行う際の
割り勘アプリ、あるいは「見える費用負担調整アプリ」として様々なアプリケーションに
採用することができる。
第５実施形態は、ユーザ端末上での画面表示例にフォーカスして本発明の一実施形態に
おける特徴を説明するものである。以下、図１５～図１９を参照して説明する。
なお、第５実施形態に記載された内容の一部又は全部は、その特徴が相互に排他的であ
る場合を除いて他の実施形態にも適用可能である。
特に、ユーザインタフェースに特化した第５実施形態は、必ずしもユーザ端末間あるい
はサーバを介した電子バリューの送受信を伴う必要はなく、現金でのやり取りを行う際の
割り勘アプリ、あるいは「見える費用負担調整アプリ」として様々なアプリケーションに
採用することができる。
【0186】
図１５（Ａ）に示される本発明の一実施形態において、端末１５００（筐体部等は不図
示）の表示画面上には、端末ステータス１５０１が表示されるほか、友人あるいはイベン
ト参加者リスト表示欄１５０２が表示されている。表示欄１５０２に該当者を表示させる
ためには、図１４において説明した呼び掛け及び（シェイク等による）応募を行ってもよ
いが、図１５（Ａ）の画面では必ずしもそれらは必要なく、既に登録されている友人リス
トやイベント参加者リストを端末上に呼び出す（読み出す）だけで足りる。
図１５（Ｂ）に表れたＭ１～Ｍ９がそのリストである。Ｍ１～Ｍ９は、個々の友人ある
いはイベント参加者を表わす。
示）の表示画面上には、端末ステータス１５０１が表示されるほか、友人あるいはイベン
ト参加者リスト表示欄１５０２が表示されている。表示欄１５０２に該当者を表示させる
ためには、図１４において説明した呼び掛け及び（シェイク等による）応募を行ってもよ
いが、図１５（Ａ）の画面では必ずしもそれらは必要なく、既に登録されている友人リス
トやイベント参加者リストを端末上に呼び出す（読み出す）だけで足りる。
図１５（Ｂ）に表れたＭ１～Ｍ９がそのリストである。Ｍ１～Ｍ９は、個々の友人ある
いはイベント参加者を表わす。
【0187】
図１５（Ｂ）には、端末１５１０の表示画面上に、端末ステータス１５１１のほか、友
人あるいはイベント参加者リスト表示欄１５１２に読み出された友人あるいはイベント参
加者Ｍ１～Ｍ９が表示されており、同画面上に「支払者をチェックして下さい」と案内さ
れるように、この画面上で幹事等は支払いを行う者をタップするなどして指定することが
できる。この場合、食事会などのイベントの会場（レストラン等）では、幹事が実際に声
をかけるなどして支払いに応募する者を確認すれば足りるので、必ずしも上述したＮＦＣ
等による通信は必要ない（もちろん、ＮＦＣ通信等によって確認をとってもよい）。
人あるいはイベント参加者リスト表示欄１５１２に読み出された友人あるいはイベント参
加者Ｍ１～Ｍ９が表示されており、同画面上に「支払者をチェックして下さい」と案内さ
れるように、この画面上で幹事等は支払いを行う者をタップするなどして指定することが
できる。この場合、食事会などのイベントの会場（レストラン等）では、幹事が実際に声
をかけるなどして支払いに応募する者を確認すれば足りるので、必ずしも上述したＮＦＣ
等による通信は必要ない（もちろん、ＮＦＣ通信等によって確認をとってもよい）。
【0188】
本発明の一実施形態においては、Ｍ１～Ｍ３、Ｍ５、Ｍ６が支払いに応じたので、表示
欄１５１２中の参加者マーク（丸印）がそれぞれタップ等されてチェック印が入っている
。
欄１５１２中の参加者マーク（丸印）がそれぞれタップ等されてチェック印が入っている
。
【0189】
図１６に示される本発明の一実施形態においては、端末１６００の画面上に端末ステー
タス１６０１が表示されるほか、友人あるいはイベント参加者リスト表示欄１６０２が表
示されている。説明の便宜上、図１５の続きとして説明をすると、表示欄１６０２には支
払いに応じた参加者Ｍ１～Ｍ３、Ｍ５、Ｍ６がチェック印入りで表示されている。ここで
は、それぞれの支払い割合（支払額の分担）を決めるためのインタフェースが提供されて
いる。
タス１６０１が表示されるほか、友人あるいはイベント参加者リスト表示欄１６０２が表
示されている。説明の便宜上、図１５の続きとして説明をすると、表示欄１６０２には支
払いに応じた参加者Ｍ１～Ｍ３、Ｍ５、Ｍ６がチェック印入りで表示されている。ここで
は、それぞれの支払い割合（支払額の分担）を決めるためのインタフェースが提供されて
いる。
【0190】
図１６においては、まず、図示されない選択メニューによって支払い割合の種別を決定
する。一例として、次のようなものがある。
（１）均等割り
（２）段階負担（図１６に示されるような３段階負担など）及び段階数
（３）上記（２）の場合の各段階の金額（図１６に示されるように、１００００円、５０
００円、３０００円など）
する。一例として、次のようなものがある。
（１）均等割り
（２）段階負担（図１６に示されるような３段階負担など）及び段階数
（３）上記（２）の場合の各段階の金額（図１６に示されるように、１００００円、５０
００円、３０００円など）
【0191】
図１６においては、例示的に、上記（２）及び（３）での選択がなされ、３段階による
負担が決定される。各段階の負担額は、大きい金額から１００００円、５０００円、３０
００円となっている。かかる選択がなされると、一実施形態においては、同図に示される
ように負担額アイコン（支払額エリアともいう）１６０５～１６０７が表示される。
負担が決定される。各段階の負担額は、大きい金額から１００００円、５０００円、３０
００円となっている。かかる選択がなされると、一実施形態においては、同図に示される
ように負担額アイコン（支払額エリアともいう）１６０５～１６０７が表示される。
【0192】
次に、支払に応じた参加者Ｍ１～Ｍ３、Ｍ５、Ｍ６がそれぞれいくらの負担をするのか
を決定するために、ドラックアンドドロップあるいはフリック操作等によって各人のアイ
コンを負担額アイコンへ移動させる。一実施形態において、同図では、Ｍ１は１００００
円の負担となったのでＭ１アイコンは支払額エリア１６０５へ移動され、Ｍ２は５０００
円の負担となったのでＭ２アイコンは支払額エリア１６０６へ移動され、Ｍ３は３０００
円の負担となったのでＭ３アイコンは支払額エリア１６０７へ移動される（Ｍ５、Ｍ６に
ついても負担額が決まった時点で移動される）。
を決定するために、ドラックアンドドロップあるいはフリック操作等によって各人のアイ
コンを負担額アイコンへ移動させる。一実施形態において、同図では、Ｍ１は１００００
円の負担となったのでＭ１アイコンは支払額エリア１６０５へ移動され、Ｍ２は５０００
円の負担となったのでＭ２アイコンは支払額エリア１６０６へ移動され、Ｍ３は３０００
円の負担となったのでＭ３アイコンは支払額エリア１６０７へ移動される（Ｍ５、Ｍ６に
ついても負担額が決まった時点で移動される）。
【0193】
なお、段階負担による負担額を決定する際には、負担額の一番少ない枠に総額のうちの
端数を含めることができる。また、予め第三者等から出資あるいは寄付をもらっていた場
合には、この時点で総額から予め出資分あるいは寄付分を指し引いてから負担割合決定処
理を開始させることもできる。
端数を含めることができる。また、予め第三者等から出資あるいは寄付をもらっていた場
合には、この時点で総額から予め出資分あるいは寄付分を指し引いてから負担割合決定処
理を開始させることもできる。
【0194】
図１７に、支払いに応じた者の間での支払額の他の決定方法を示す。同図には、端末１
７００の画面上に端末ステータス１７０１が表示されるほか、友人あるいはイベント参加
者リスト表示欄１７０２が表示されている。同図は、説明の便宜上、図１６と関連付けて
（支払者が同じになるように）表現されているが、図１５の続きとして理解することもで
きる。
７００の画面上に端末ステータス１７０１が表示されるほか、友人あるいはイベント参加
者リスト表示欄１７０２が表示されている。同図は、説明の便宜上、図１６と関連付けて
（支払者が同じになるように）表現されているが、図１５の続きとして理解することもで
きる。
【0195】
図１７（Ａ）には、表示欄１７０２に支払い者Ｍ１～Ｍ３、Ｍ５、Ｍ６のアイコンが表
示されているが、ここでは支払額を決定する前あるいは後に、次の操作によって負担者の
調整処理を行うことができる。
（１）他の負担者の分も併せて負担する場合には、負担してもらう側の負担者アイコンを
負担する側のアイコンに重ねる。
（２）上記（１）の操作は複数回（重ねて）実行できる。
なお、上記（１）や（２）の操作を統合操作あるいは総合処理ともいう。
示されているが、ここでは支払額を決定する前あるいは後に、次の操作によって負担者の
調整処理を行うことができる。
（１）他の負担者の分も併せて負担する場合には、負担してもらう側の負担者アイコンを
負担する側のアイコンに重ねる。
（２）上記（１）の操作は複数回（重ねて）実行できる。
なお、上記（１）や（２）の操作を統合操作あるいは総合処理ともいう。
【0196】
図１７（Ａ）においては、例示的に、Ｍ１がＭ２、Ｍ５、Ｍ６の分も一緒に負担するこ
ととなったので、まず、Ｍ２アイコンがドラックアンドドロップあるいはフリック操作に
よってＭ１アイコン上に重ねられ、続いて、Ｍ５、Ｍ６アイコンがそれぞれＭ１アイコン
上に重ねられる（それぞれ、統合される）。
ととなったので、まず、Ｍ２アイコンがドラックアンドドロップあるいはフリック操作に
よってＭ１アイコン上に重ねられ、続いて、Ｍ５、Ｍ６アイコンがそれぞれＭ１アイコン
上に重ねられる（それぞれ、統合される）。
【0197】
そうすると、図１７（Ｂ）に示されるように、表示欄１７１２上には、実際の支払い者
（支払窓口）として、Ｍ１とＭ３とが残り、Ｍ１アイコンの中には、Ｍ２、Ｍ５、Ｍ６の
３人分の立替が含まれているという意味で、Ｍ１本人分と合わせて４人分を表わす「４」
の数字が表示される。
（支払窓口）として、Ｍ１とＭ３とが残り、Ｍ１アイコンの中には、Ｍ２、Ｍ５、Ｍ６の
３人分の立替が含まれているという意味で、Ｍ１本人分と合わせて４人分を表わす「４」
の数字が表示される。
【0198】
サーバ等で管理される管理テーブルに対しても、データ構成上、図示しないレコードあ
るいはサブテーブルが拡張され、Ｍ１がＭ２、Ｍ５、Ｍ６の分も立替える旨（あるいは、
Ｍ２、Ｍ５、Ｍ６は、それぞれＭ１に負担してもらう旨）のレコード等が追記される。
なお、１７１０、１７１１は、それぞれ１７００、１７０１に対応する。
るいはサブテーブルが拡張され、Ｍ１がＭ２、Ｍ５、Ｍ６の分も立替える旨（あるいは、
Ｍ２、Ｍ５、Ｍ６は、それぞれＭ１に負担してもらう旨）のレコード等が追記される。
なお、１７１０、１７１１は、それぞれ１７００、１７０１に対応する。
【0199】
図１８に、友人あるいはイベント参加者リストから無料の者（支払いを免除される者）
を簡単に除外する操作方法を示す。なお、図１８に示されたインタフェース機能は、いっ
たんは支払いに応じた者を除外または免除する操作としても使用できる。
を簡単に除外する操作方法を示す。なお、図１８に示されたインタフェース機能は、いっ
たんは支払いに応じた者を除外または免除する操作としても使用できる。
【0200】
同図には、端末１８００の画面上に端末ステータス１８０１が表示されるほか、友人あ
るいはイベント参加者リスト表示欄１８０２が表示されている。そして、表示欄１８０２
には、メンバーＭ１～Ｍ９のアイコンが表示されている。本発明の一実施形態において、
ここから無料の者（支払いを免除される者）を除外するためには、該当者を所定の枠（図
１８における枠１８０３）の外にドラックアンドドロップあるいはフリック操作すればよ
い。
るいはイベント参加者リスト表示欄１８０２が表示されている。そして、表示欄１８０２
には、メンバーＭ１～Ｍ９のアイコンが表示されている。本発明の一実施形態において、
ここから無料の者（支払いを免除される者）を除外するためには、該当者を所定の枠（図
１８における枠１８０３）の外にドラックアンドドロップあるいはフリック操作すればよ
い。
【0201】
本発明の一実施形態において、Ｍ４、Ｍ７～Ｍ９が無料の者とされたので、それぞれの
アイコンは、枠１８０３の外にフリックされている。この結果、管理テーブル上は、Ｍ４
、Ｍ７～Ｍ９の当該イベントの負担金額としてはゼロとして記録管理される。
アイコンは、枠１８０３の外にフリックされている。この結果、管理テーブル上は、Ｍ４
、Ｍ７～Ｍ９の当該イベントの負担金額としてはゼロとして記録管理される。
【0202】
図１９（Ａ）に、支払いに応じた者の支払いの進捗率を直観的に視認しやすいように構
成したインタフェース例を示す。同図（Ａ）には、端末１９００の画面上に端末ステータ
ス１９０１が表示されるほか、友人あるいはイベント参加者リスト表示欄１９０２が表示
されている。そして、表示欄１９０２の中には、支払いに応じた者Ｍ１～Ｍ３、Ｍ５、Ｍ
６、及び支払完了確認枠１９０３が表示されている。
この支払完了確認枠は、支払いに応じる者の支払い状況を確認可能な確認領域である。
成したインタフェース例を示す。同図（Ａ）には、端末１９００の画面上に端末ステータ
ス１９０１が表示されるほか、友人あるいはイベント参加者リスト表示欄１９０２が表示
されている。そして、表示欄１９０２の中には、支払いに応じた者Ｍ１～Ｍ３、Ｍ５、Ｍ
６、及び支払完了確認枠１９０３が表示されている。
この支払完了確認枠は、支払いに応じる者の支払い状況を確認可能な確認領域である。
【0203】
本発明の一実施形態においては、実際に支払いが終わった者については、該当アイコン
を枠１９０２の中に順次フリックさせる。
を枠１９０２の中に順次フリックさせる。
【0204】
そうすると、総額に対して集金できた達成率を同図（Ｂ）～（Ｄ）のように視覚的に表
示させることができる。同図（Ｂ）は総額に対して３０％徴収できた状態、同図（Ｃ）は
総額に対して５０％徴収できた状態、同図（Ｄ）は１００％徴収できた状態を示す。
なお、本発明の一実施形態において、同図（Ｂ）～（Ｄ）は、支払に応じる者の負担割
合に応じた面積（あるいは、その時点での支払額合計）を表わす。その意味で、同図（Ｄ
）に表された「１００％ Ｃｏｍｐｌｅｔｅ」の表示領域は、支払に応じる者の負担割合
の合計に応じた面積であり、確認領域の総面積に一致する。
示させることができる。同図（Ｂ）は総額に対して３０％徴収できた状態、同図（Ｃ）は
総額に対して５０％徴収できた状態、同図（Ｄ）は１００％徴収できた状態を示す。
なお、本発明の一実施形態において、同図（Ｂ）～（Ｄ）は、支払に応じる者の負担割
合に応じた面積（あるいは、その時点での支払額合計）を表わす。その意味で、同図（Ｄ
）に表された「１００％ Ｃｏｍｐｌｅｔｅ」の表示領域は、支払に応じる者の負担割合
の合計に応じた面積であり、確認領域の総面積に一致する。
【0205】
このように、図１９（Ａ）及び（Ｂ）に示されたインタフェースを採用することで、慌
ただしい飲食店での集金会計もスムースに進行させることができ好適である。この場合、
支払い方式はこれまで説明した電子バリューの端末間移動であってもよいし、あるいは現
金でやり取りする場合であってもよい。いずれの場合においても、費用割合の分担や徴収
がしやすくなるという効果を奏する。
ただしい飲食店での集金会計もスムースに進行させることができ好適である。この場合、
支払い方式はこれまで説明した電子バリューの端末間移動であってもよいし、あるいは現
金でやり取りする場合であってもよい。いずれの場合においても、費用割合の分担や徴収
がしやすくなるという効果を奏する。
【0206】
本開示の実施形態を諸図面や実施例に基づき説明してきたが、当業者であれば本開示に
基づき種々の変形や修正を行うことが容易であることに注意されたい。従って、これらの
変形や修正は本開示の範囲に含まれることに留意されたい。例えば、各手段、各ステップ
等に含まれる機能等は論理的に矛盾しないように再配置可能であり、複数の手段やステッ
プ等を１つに組み合わせたり、或いは分割したりすることが可能である。また、各実施形
態に示す構成を適宜組み合わせることとしてもよい。
基づき種々の変形や修正を行うことが容易であることに注意されたい。従って、これらの
変形や修正は本開示の範囲に含まれることに留意されたい。例えば、各手段、各ステップ
等に含まれる機能等は論理的に矛盾しないように再配置可能であり、複数の手段やステッ
プ等を１つに組み合わせたり、或いは分割したりすることが可能である。また、各実施形
態に示す構成を適宜組み合わせることとしてもよい。
【符号の説明】
【0207】
１００、２００ 情報処理システム
１１０、１２０ 情報処理装置（サーバ）
１５１、１５２、１５３ 情報処理端末
１９９ ネットワーク
２１０ 情報処理サーバ
２２０、２３０ ＰＣ（情報処理端末）
２４０ 携帯電話（情報処理端末）
２５０、２５１、２５２ タブレット（情報処理端末）
２６０、２７０、２８０，２９０ ネットワーク
１１０、１２０ 情報処理装置（サーバ）
１５１、１５２、１５３ 情報処理端末
１９９ ネットワーク
２１０ 情報処理サーバ
２２０、２３０ ＰＣ（情報処理端末）
２４０ 携帯電話（情報処理端末）
２５０、２５１、２５２ タブレット（情報処理端末）
２６０、２７０、２８０，２９０ ネットワーク
【図1】
【図2】
【図3】
【図4A】
【図4B】
【図4C】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11A】
【図11B】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
