JP2020071817A - 情報処理方法、情報処理装置及びプログラム - Google Patents

Abstract

【課題】ユーザがチャージを行う際に事業者が負担する手数料を軽減することが可能な技術を提供すること。【解決手段】情報処理装置が行う情報処理方法であって、ユーザごとに、残高を含むアカウント情報と、ユーザの銀行口座からの未集金額とを記憶部に記憶するステップと、所定のユーザからチャージ額を指定するチャージ要求を受け付けるステップと、受け付けたチャージ額を、所定のユーザのアカウントの残高と未集金額との各々に加算するステップと、所定のユーザの銀行口座からの引落しに関する所定の条件を満たす場合に、所定のユーザの未集金額を銀行口座から引き落とすステップと、を含む情報処理方法を提供する。【選択図】図６

Description

本開示は、情報処理方法、情報処理装置及びプログラムに関する。

支払いに関するサービスとして、事前にチャージした金額内で決済を行うことが可能なプリペイド決済サービスが提供されている。プリペイド決済サービスには様々な方法が存在するが、例えば、国際的なクレジットカードブランドによるプリペイド決済サービスや、ＱＲコード（登録商標）決済と呼ばれるプリペイド決済サービス等が挙げられる。特許文献１には、ＱＲコード（登録商標）を利用してより簡便に商品の費用を決済することを可能とする技術が開示されている。

特表２０１６−５３４４５３号公報

プリペイド決済サービスを提供する事業者は、ユーザが要求するチャージ額をユーザの銀行口座から引き落とす際、銀行に手数料を支払う必要がある。この手数料は、ユーザに請求するのではなく事業者側が負担しているのが一般的である。銀行に支払う手数料の額は、引き落とす金額の大きさよりも引落し回数に依存することが多いにもかかわらず、プリペイド決済サービスでは少額のチャージが何度も行われることが多いことから、事業者にとって手数料の負担は大きい。

本開示は、ユーザがチャージを行う際に事業者が負担する手数料を軽減することが可能な情報処理方法、情報処理装置及びプログラムを提供することを目的とする。

本開示の一実施形態に係る情報処理方法は、情報処理装置が行う情報処理方法であって、ユーザごとに、残高を含むアカウント情報と、ユーザの銀行口座からの未集金額とを記憶部に記憶するステップと、所定のユーザからチャージ額を指定するチャージ要求を受け付けるステップと、受け付けたチャージ額を、所定のユーザのアカウントの残高と未集金額との各々に加算するステップと、所定のユーザの銀行口座からの引落しに関する所定の条件を満たす場合に、所定のユーザの未集金額を銀行口座から引き落とすステップと、を含む。

本開示の他の実施形態に係る情報処理方法は、情報処理装置が行う情報処理方法であって、ユーザからチャージ額を指定するチャージ要求を受け付けるステップと、複数のユーザから受け付けたチャージ要求を所定の条件に従ってマッチングさせることで、一括して口座引落しを行うチャージ要求の組を作成するステップと、チャージ要求の組に含まれるチャージ要求を行ったユーザの中から、銀行口座からの引落しを行うユーザを選択するステップと、チャージ要求の組に含まれるチャージ額の合計額を、選択されたユーザの銀行口座から引き落とすステップと、チャージ要求の組に含まれる各ユーザのアカウントの残高に、各ユーザが要求したチャージ額を加算するステップと、銀行口座からの引き落としが行われることで発生する複数のユーザ間での金銭の貸し借りを管理するステップと、を含む。

実施形態の一態様に係る通信システムの構成を示す図である。 本開示に係る情報処理装置のハードウェア構成の一例を示す図である。 第１実施形態に係る情報処理装置の機能的な構成を示すブロック図の一例を示す図である。 第１実施形態に係るアカウント管理ＤＢの一例を示す図である。 第１実施形態に係る口座管理ＤＢの一例を示す図である。 第１実施形態に係る通信システムの処理のシーケンスの一例を示す。 第２実施形態に係る情報処理装置の機能的な構成を示すブロック図の一例を示す図である。 第２実施形態に係るアカウント管理ＤＢの一例を示す図である。 第２実施形態に係る口座管理ＤＢの一例を示す図である。 第２実施形態に係る通信システムの処理のシーケンスの一例を示す図である。 第２実施形態に係るチャージ残高及び未集金額／余剰集金額の計算例を示す図である。

＜法令遵守＞
本明細書に記載の開示は、実施される場合、本開示を実施する各国の法令を遵守のうえで実施される。また、本明細書に記載の開示は、各国の法令を遵守するために必要な、当業者が成し得る全ての変更、置換、変形、改変、および修正をもって実施される。

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

＜システム構成＞
図１は、本開示の一実施形態に係る通信システム１の構成を示す。図１に開示されるように、通信システム１では、ネットワーク１３０を介してサーバ１１０Ａ、サーバ１１０Ｂと、端末１２０Ａ、端末１２０Ｂ、端末１２０Ｃと、銀行システム（単に「銀行」とも称する。）１４０とが接続される。

本開示において、サーバ１１０Ａと、サーバ１１０Ｂとをそれぞれ区別する必要がない場合は、サーバ１１０Ａとサーバ１１０Ｂとは、それぞれサーバ１１０と表現されてもよい。

本開示において、端末１２０Ａと、端末１２０Ｂと、端末１２０Ｃとをそれぞれ区別する必要がない場合は、端末１２０Ａと端末１２０Ｂと端末１２０Ｃとは、それぞれ端末１２０と表現されてもよい。

本開示において、サーバ１１０と、端末１２０とをそれぞれ区別する必要がない場合は、サーバ１１０と端末１２０とは、それぞれ情報処理装置２００と表現されてもよい。なお、ネットワーク１３０に接続される情報処理装置２００の数は限定されない。

サーバ１１０は、ネットワーク１３０を介してユーザが利用する端末１２０に、所定のサービスを提供する。所定のサービスは、限定でなく例として、決済サービス、金融サービス、電子商取引サービス、インスタントメッセンジャーを代表とするSNS（Social Networking Service）、楽曲・動画・書籍などのコンテンツ提供サービス等を含む。ユーザが端末１２０を介して所定のサービスを利用することで、サーバ１１０は１以上の端末１２０に所定のサービスを提供することができる。

本開示において、決済サービスとは１以上のユーザが金銭または金銭相当物の授受ができるサービスを意味する。限定でなく例として、一次元コード（バーコードなど）、二次元コード（QRコード（登録商標）など）、近距離無線通信（NFC (Near Field Communication)、BLE (Bluetooth（登録商標） Low Energy)、WI-FI（登録商標）、超音波通信、赤外線通信など）（以下で「二次元コード等」または「コード」と称する。）を利用して決済を行うサービスを含む。また、代金の支払いを行うユーザ（支払者）の端末１２０が二次元コード等を読み取ることで決済を行うことを「ユーザ読取型コード決済」または「MPM（Merchant Presented Mode）」と表現し、支払いを行うユーザの端末１２０Ａが二次元コード等を表示し、表示された二次元コード等を、代金を請求する店舗側等のユーザ（販売者、請求者）の端末１２０が読み取ることで決済を行うことを「店舗読取型コード決済」または「CPM（Consumer Presented Mode）」と表現する。なお、MPMおよびCMPは、動的であってもよいし、静的であってもよい。

必要に応じて、ユーザＸが利用する端末を端末１２０Ｘと表現し、ユーザＸまたは端末１２０Ｘに対応づけられた、所定のサービスにおけるユーザ情報をユーザ情報Ｘと表現する。なお、ユーザ情報とは、所定のサービスにおいてユーザが利用するアカウントに対応付けられたユーザの情報である。ユーザ情報は、限定でなく例として、ユーザにより入力される、または、所定のサービスにより付与される、ユーザの名前、ユーザのアイコン画像、ユーザの年齢、ユーザの性別、ユーザの住所、ユーザの趣味趣向、ユーザの識別子などのユーザに対応づけられた情報、ユーザに対応付けられた電子バリュー（電子マネー）の残高情報、ユーザに対応付けられたクレジットカード情報（クレジットカード番号など）を含み、これらのいずれか一つまたは、組み合わせであってもよい。

ネットワーク１３０は、２以上の情報処理装置２００を接続する役割を担う。ネットワーク１３０は、端末１２０がサーバ１１０に接続した後、データを送受信することができるように接続経路を提供する通信網を意味する。

ネットワーク１３０のうちの１つまたは複数の部分は、有線ネットワークや無線ネットワークであってもよい。ネットワーク１３０は、限定でなく例として、アドホック・ネットワーク（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）、電子メールクライアントなど）、ウェアラブル端末（限定でなく例として、メガネ型デバイス、時計型デバイスなど）、他種のコンピュータ、またはコミュニケーションプラットホームを含む。

＜ハードウェア（ＨＷ）構成＞
図２を用いて、通信システム１に含まれる情報処理装置２００のＨＷ構成について説明する。

情報処理装置２００は、プロセッサ２０１と、メモリ２０２と、ストレージ２０３と、入出力インタフェース（入出力Ｉ／Ｆ）２０４と、通信インタフェース（通信Ｉ／Ｆ）２０５とを含む。情報処理装置２００のＨＷの各構成要素は、限定でなく例として、バスＢを介して相互に接続される。

情報処理装置２００は、プロセッサ２０１と、メモリ２０２と、ストレージ２０３と、入出力Ｉ／Ｆ２０４と、通信Ｉ／Ｆ２０５との協働により、本開示に記載される機能および方法を実現する。

プロセッサ２０１は、ストレージ２０３に記憶されるプログラムに含まれるコードまたは命令によって実現する機能および方法を実行する。プロセッサ２０１は、限定でなく例として、中央処理装置（ＣＰＵ）、ＭＰＵ（Micro Processing Unit）、ＧＰＵ（Graphics Processing Unit）、マイクロプロセッサ（microprocessor）、プロセッサコア（processor core）、マルチプロセッサ（multiprocessor）、ＡＳＩＣ（Application-Specific Integrated Circuit）、ＦＰＧＡ（Field Programmable Gate Array）等を含み、集積回路（ＩＣ（Integrated Circuit）チップ、ＬＳＩ（Large Scale Integration））等に形成された論理回路（ハードウェア）や専用回路によって各実施形態に開示される各処理を実現してもよい。また、これらの回路は、１または複数の集積回路により実現されてよく、各実施形態に示す複数の処理を１つの集積回路により実現されることとしてもよい。また、ＬＳＩは、集積度の違いにより、ＶＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩなどと呼称されることもある。

メモリ２０２は、ストレージ２０３からロードしたプログラムを一時的に記憶し、プロセッサ２０１に対して作業領域を提供する。メモリ２０２には、プロセッサ２０１がプログラムを実行している間に生成される各種データも一時的に格納される。メモリ２０２は、限定でなく例として、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）などを含む。

ストレージ２０３は、プログラムを記憶する。ストレージ２０３は、限定でなく例として、ＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）、フラッシュメモリなどを含む。

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

入出力Ｉ／Ｆ２０４は、情報処理装置２００に対する各種操作を入力する入力装置、および、情報処理装置２００で処理された処理結果を出力する出力装置を含む。入出力Ｉ／Ｆ２０４は、入力装置と出力装置が一体化していてもよいし、入力装置と出力装置とに分離していてもよい。

入力装置は、ユーザからの入力を受け付けて、当該入力に係る情報をプロセッサ２０１に伝達できる全ての種類の装置のいずれか、または、その組み合わせにより実現される。入力装置は、限定でなく例として、タッチパネル、タッチディスプレイ、キーボード等のハードウェアキーや、マウス等のポインティングデバイス、カメラ（画像を介した操作入力）、マイク（音声による操作入力）を含む。

出力装置は、プロセッサ２０１で処理された処理結果を出力することができる全ての種類の装置のいずれか、または、その組み合わせにより実現される。当該処理結果を映像または動画像として出力する場合、出力装置は、フレームバッファに書き込まれた表示データに従って、当該表示データを表示することができる全ての種類の装置のいずれかまたはその組み合わせにより実現される。出力装置は、限定でなく例として、タッチパネル、タッチディスプレイ、モニタ（限定でなく例として、液晶ディスプレイ、ＯＥＬＤ（Organic Electroluminescence Display）など）、ヘッドマウントディスプレイ（ＨＤＭ：Head Mounted Display）、プロジェクションマッピング、ホログラム、空気中など（真空であってもよい）に画像やテキスト情報等を表示可能な装置、スピーカ（音声出力）、プリンターなどを含む。なお、これらの出力装置は、３Ｄで表示データを表示可能であってもよい。

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

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

また、本開示のプログラムは、当該プログラムを伝送可能な任意の伝送媒体（通信ネットワークや放送波等）を介して、情報処理装置２００に提供されてもよい。

また、本開示の各実施形態は、プログラムが電子的な伝送によって具現化された、搬送波に埋め込まれたデータ信号の形態でも実現され得る。

なお、本開示のプログラムは、限定でなく例として、ＪａｖａＳｃｒｉｐｔ（登録商標）、Ｐｙｔｈｏｎなどのスクリプト言語、Ｃ言語、Ｇｏ言語、Ｓｗｉｆｔ、Ｋｏｌｔｉｎ、Ｊａｖａ（登録商標）などを用いて実装される。

情報処理装置２００おける処理の少なくとも一部は、１以上のコンピュータにより構成されるクラウドコンピューティングにより実現されていてもよい。

情報処理装置２００における処理の少なくとも一部を、他の情報処理装置により行う構成としてもよい。この場合、プロセッサ２０１により実現される各機能部の処理のうち少なくとも一部の処理を、他の情報処理装置で行う構成としてもよい。

＜その他＞
明示的な言及のない限り、本開示の実施形態における判定の構成は必須でなく、判定条件を満たした場合に所定の処理が動作されたり、判定条件を満たさない場合に所定の処理がされたりしてもよい。

本開示では、明記されていない限り、または文脈によって示されない限り、「AおよびBの少なくとも一方」は、「Ａ、Ｂ、またはその両方」を意味する。さらに、明記されない限り、または文脈によって示されない限り、「ａ」、「ａｎ」、または「ｔｈｅ」は「１つまたは複数」を意味するものとする。したがって、本明細書では、別段に明記されない限り、または文脈によって示されない限り、「ａｎ Ａ」または「ｔｈｅ Ａ」は「１つまたは複数のＡ」を意味する。

本開示は、本開示の実施形態および実施例に対して、当業者が成し得る全ての変更、置換、変形、改変、または修正を包含する。また、添付の特許請求の範囲は、本開示の実施形態および実施例に対して、当業者が成し得る全ての変更、置換、変形、改変、または修正を包含する。さらに、本開示は、当業者が成し得る、本開示における実施形態または実施例の１以上の特徴と、本開示における他の実施形態または実施例の１以上の特徴との任意の組合せを包含する。

加えて、特定の機能を実施するように適合される、配置される、能力を有する、構成される、使用可能である、動作可能である、または動作できる装置またはシステムあるいは装置またはシステムの構成要素に対する添付の特許請求の範囲での参照は、その装置、システム、または構成要素がそのように適合される、配置される、能力を有する、構成される、使用可能にされる、動作可能にされる、または動作できる限り、その装置、システム、構成要素またはその特定の機能がアクティベートされ、オンにされ、またはロック解除されているか否かに関わらず、その装置、システム、構成要素を包含する。

本開示は、明示されない限り、いずれの実施形態または実施例を実施するに際して、事前に、または、実施の直前にユーザからの同意を取得してもよい。また、取得する同意は、包括的なものでもよく、都度取得するものでもよい。

＜第１実施形態＞
第１実施形態は、決済サービスを提供する事業者が、ユーザからチャージ要求を受け付ける度にユーザの銀行口座から引き落とすのではなく、所定の条件を満たす場合に、複数のチャージ要求額を当該ユーザの銀行口座から一括して引き落とす処理を行う実施形態である。

第１実施形態によれば、ユーザの銀行口座からの引落し回数を削減することができるため、ユーザがチャージを行う際に事業者が負担する手数料を軽減することが可能になるという効果が得られる。

また、第１実施形態によれば、銀行口座からの引落し処理を一括して行うことから、チャージ残高を管理する事業者のサーバと銀行システムとの間のトランザクション数を削減することができると共に、サーバの処理負荷も軽減することが可能になるという効果が得られる。

また、第１実施形態によれば、事後的に口座引落しが行われることでユーザの信用スコアが蓄積されることになるため、信用スコアを用いた新たなサービスの展開につながる等、なめらかな社会の創造に寄与することができるという効果が得られる。

＜第１実施形態の機能構成＞
図３を用いてサーバ１１０および端末１２０の機能構成を説明する。図３に開示の機能部は、情報処理装置２００が備えるプロセッサ２０１と、メモリ２０２と、ストレージ２０３と、入出力Ｉ／Ｆ２０４と、通信Ｉ／Ｆ２０５との協働により実現される。

（１）サーバの機能構成
サーバ１１０は、入出力Ｉ／Ｆ３１１と、通信Ｉ／Ｆ３１２と、制御部３１３と、記憶部３１４とを有する。入出力Ｉ／Ｆ３１１と、通信Ｉ／Ｆ３１２とは、それぞれ、図２の入出力Ｉ／Ｆ２０４と、通信Ｉ／Ｆ２０５とに対応する。制御部３１３は、同意処理部３１５と、チャージ受付部３１６と、チャージ管理部３１７と、口座管理部３１８と、引落し処理部３１９とを含む。なお、各機能部の機能または処理は、実現可能な範囲において、機械学習またはＡＩ（Ａｒｔｉｆｉｃａｌ Ｉｎｔｅｌｌｉｇｅｎｃｅ）により実現されてもよい。

記憶部３１４は、プログラムとアカウント管理ＤＢ（DataBase）と口座管理ＤＢとを記憶する。図４は、第１実施形態に係るアカウント管理ＤＢの一例を示す図である。アカウント管理ＤＢは、サーバ１１０が提供する決済サービスを利用するユーザのアカウントを管理するデータベースである。「ユーザＩＤ」には、ユーザを一意に識別する識別子が格納される。「チャージ残高」には、ユーザがチャージしたチャージ額の残高が格納される。チャージ残高は、ユーザがチャージを行う度に加算され、ユーザが決済を行う度に減算される。「チャージ履歴」には、ユーザがチャージを行った日時及びチャージ額の履歴が格納される。

図５は、第１実施形態に係る口座管理ＤＢの一例を示す図である。口座管理ＤＢは、ユーザが、チャージ額の引落しに利用する銀行口座に関する各種の情報を管理するデータベースである。「ユーザＩＤ」には、ユーザを一意に識別する識別子が格納される。「未集金額」には、チャージされた金額のうち銀行口座から引落しされていない金額（以下、「未集金額」と言う。）が格納される。「引落し口座」には、チャージ額又は未集金額を引き落とす際に用いられるユーザの銀行口座の銀行名や口座番号等が格納される。「同意フラグ」には、ユーザが、銀行口座からの引落し処理を一括して行うこと（つまり、銀行口座からの引落し処理を、チャージ要求を受け付けた時とは異なるタイミングでまとめて実行すること）に同意しているか否かを示すフラグが格納される。ユーザが同意している場合にはフラグがセットされ、同意していない場合にはフラグがセットされない。なお、「引落し口座」には複数の銀行口座が、優先度とともに格納されていてもよい。

図３に戻り、同意処理部３１５は、銀行口座からの引落しを、銀行口座からの引落し処理を一括して行うことについての同意をユーザから得る処理を行う。また、同意処理部３１５は、ユーザから同意を得る際に、ユーザの端末１２０に、銀行口座からの引落し処理を一括して行う場合の条件（銀行口座からの引落しに関する所定の条件）を通知する。以下、銀行口座からの引落しを一括して行う場合の条件を、便宜上「引落し条件」と言う。

なお、同意処理部３１５は、ユーザから、引落し条件の指定（選択）を受け付けるようにしてもよい。

チャージ受付部３１６は、ユーザからチャージ要求を受け付ける機能を有する。チャージ要求には、ユーザが要求するチャージ額が含まれる。

チャージ管理部３１７は、ユーザから受け付けたチャージ額を、アカウント管理ＤＢに格納されている当該ユーザのチャージ残高（ユーザのアカウントの残高）に加算する。

口座管理部３１８は、ユーザが、銀行口座からの引落し処理を一括して行うことに同意している場合、チャージ受付部３１６で受け付けたチャージ額を、口座管理ＤＢに格納されている当該ユーザの未集金額に加算する。

引落し処理部３１９は、引落し条件を満たす場合に、当該ユーザの未集金額を銀行口座から引き落とす処理を行う。また、引落し処理部３１９は、引落し条件を満たしており、かつ、ユーザが、銀行口座からの引落し処理を一括して行うことに同意している場合に、当該ユーザの未集金額を銀行口座から引き落とす処理を行う。一方、引落し処理部３１９は、銀行口座からの引落し処理を一括して行うことに同意していないユーザについては、チャージ要求を受けた時点で、要求されたチャージ額をユーザの銀行口座から引き落とす処理を行う。

なお、引落し処理部３１９は、ユーザから要求があった場合、引落し条件が満たされるよりも前に、当該ユーザの要求に基づいてユーザの未集金額を銀行口座から引き落とすようにしてもよい。

（２）端末の機能構成
端末１２０は、入出力Ｉ／Ｆ３２１と、通信Ｉ／Ｆ３２２と、制御部３２３と、記憶部３２４と、とを有する。入出力Ｉ／Ｆ３２１と、通信Ｉ／Ｆ３２２とは、それぞれ、図２の入出力Ｉ／Ｆ２０４と、通信Ｉ／Ｆ２０５とに対応する。制御部３２３は、通信部３２５と、ＵＩ（UserInterface）部３２６とを含む。記憶部３２４は、プログラムを記憶する。

なお、各機能部の機能または処理は、実現可能な範囲において、機械学習またはＡＩ（Ａｒｔｉｆｉｃａｌ Ｉｎｔｅｌｌｉｇｅｎｃｅ）により実現されてもよい。

通信部３２５は、サーバ１１０との間で、サーバ１１０が提供する決済サービスに関する各種の情報を送受信する機能を有する。また、通信部３２５は、銀行口座からの引落し処理を一括して行う処理について、引落し条件（銀行口座からの引落しに関する所定の条件）を示す情報を、サーバ１１０から受信する。なお、通信部３２５は、更に、受信処理を行う受信部と、送信処理を行う送信部とを含んでいてもよい。

ＵＩ部３２６は、サーバ１１０が提供する決済サービスに関する各種の画面を端末１２０のディスプレイに表示する機能を有する。また、当該決済サービスに関する各種の入力をユーザから受け付ける機能を有する。また、ＵＩ部３２６は、銀行口座からの引落しが行われる場合の条件をディスプレイに表示すると共に、チャージ要求を受け付けた際とは異なるタイミングで銀行口座からの引落しを実行する処理について同意するか否かをユーザから受け付ける。ユーザから受け付けた結果（同意するか否か）を示す情報は、通信部３２５を介してサーバ１１０に送信される。ＵＩ部３２６は、更に、表示処理を行う表示部と、ユーザからの操作を受け付ける受付部とを含んでいてもよい。

通信部３２５及びＵＩ部３２６は、決済サービスに関するＷｅｂページを表示するＷｅｂブラウザが備える機能であってもよい。若しくは、通信部３２５及びＵＩ部３２６は、決済サービスを提供するための専用のプログラムにより提供される機能であってもよい。

＜第１実施形態の動作処理＞
図６を参照し、実施形態に係る通信システム１の処理について説明する。図６は、第１実施形態に係る通信システム１の処理のシーケンスの一例を示す。

ステップＳ１００で、端末１２０Ａの通信部３２５は、ユーザＡの操作に応答して、サーバ１１０が提供する決済サービスの利用申し込みを依頼するメッセージをサーバ１１０に送信する。

ステップＳ１０１で、サーバ１１０の同意処理部３１５は、決済サービスの利用申し込みを依頼するメッセージを受信すると、決済サービスの利用に必要な各種情報の入力をユーザＡに促すメッセージを端末１２０Ａに送信する。このとき、当該メッセージには引落し条件を示す情報が含まれる。端末１２０ＡのＵＩ部３２６は、決済サービスの利用に必要な各種情報（氏名、年齢、ログインパスワード、引落し口座の口座番号等）の入力を促す画面を表示する。また、ＵＩ部３２６は、引落し条件を表示すると共に、銀行口座からの引落し処理を一括して行うことについて同意するか否かについてユーザＡの選択を促す画面を表示する。

ステップＳ１０２で、端末１２０Ａの通信部３２５は、ユーザＡが入力した決済サービスの利用に必要な各種情報と、銀行口座からの引落し処理を一括して行うことについて同意するか否かの選択結果を示す情報とをサーバ１１０に送信する。

ステップＳ１０３で、サーバ１１０の同意処理部３１５は、アカウント管理ＤＢ及び口座管理ＤＢにユーザＡに関する新たなレコードを追加すると共に、口座管理ＤＢの同意フラグに、ユーザＡの選択結果をセットする。なお、以下の説明では、ユーザＡが、銀行口座からの引落し処理を一括して行うことについて同意したと仮定して説明を続ける。

ステップＳ１０４で、端末１２０の通信部３２５は、チャージ要求メッセージをサーバ１１０に送信する。チャージ要求メッセージには、ユーザＡが要求するチャージ額（１，０００円）が含まれる。サーバ１１０の口座管理部３１８は、受け付けたチャージ額（１，０００円）を口座管理ＤＢの未集金額に加算する。

ステップＳ１０５で、サーバ１１０の引落し処理部３１９は、ユーザＡの銀行口座から未集金額を引き落とすのか否かを判定する。引落し条件を満たす場合、引落し処理部３１９は、ユーザＡの銀行口座から未集金額を引き落とす処理を行い、口座管理部３１８は、口座管理ＤＢにおけるユーザＡの未集金額を０円に更新する（未集金額をリセットする）。一方、引落し条件を満たさない場合、引落し処理部３１９は、銀行口座からの引落しは行わずに処理を終了する。ここでは、引落し条件を満たさなかったと仮定する。

ステップＳ１０６で、サーバ１１０のチャージ管理部３１７は、アカウント管理ＤＢにおけるユーザＡのチャージ残高に、ステップＳ１０４で要求された要求されたチャージ額（１，０００円）を加算し、チャージ履歴を更新する。

ステップＳ１０７で、サーバ１１０のチャージ管理部３１７は、端末１２０Ａに、チャージ処理が完了したことを通知するメッセージを送信する。

ステップＳ１０８で、端末１２０の通信部３２５は、チャージ要求メッセージをサーバ１１０に送信する。チャージ要求メッセージには、ユーザが要求するチャージ額（２，０００円）が含まれる。サーバ１１０の口座管理部３１８は、受け付けたチャージ額（２，０００円）を、口座管理ＤＢの未集金額に加算する。この時点で未集金額には３，０００円が格納されていることになる。

ステップＳ１０９で、サーバ１１０の引落し処理部３１９は、ユーザＡの銀行口座から、未集金額を引き落とすのか否かを判定する。ここでは、引落し条件を満たしたと仮定する。

ステップＳ１１０で、サーバ１１０の引落し処理部３１９は、口座管理ＤＢにおけるユーザＡの引落し口座に格納されている銀行口座（口座Ａ）に対して、未集金額に格納されている金額（３，０００円）を口座Ａから引き落として事業者Ｚの口座に入金するように依頼する。

ステップＳ１１１で、口座Ａから３，０００円が引き落とされ、３，０００円から手数料を差し引いた金額が事業者Ｚの口座に入金される。

ステップＳ１１２で、銀行１４０は、引落し処理が完了したことをサーバ１１０に通知する。

ステップＳ１１３で、サーバ１１０のチャージ管理部３１７は、アカウント管理ＤＢにおけるユーザＡのチャージ残高に、ステップＳ１０８で要求されたチャージ額（２，０００円）を加算し、チャージ履歴を更新する。また、口座管理部３１８は、口座管理ＤＢにおけるユーザＡの未集金額を０円に更新する。

ステップＳ１１４で、サーバ１１０のチャージ管理部３１７は、端末１２０Ａに、チャージ処理が完了したことを通知するメッセージを送信する。

以上説明した処理手順のステップＳ１００〜ステップＳ１０２において、銀行口座からの引落し処理を一括して行うことについての同意確認を、決済サービスの利用申し込み時に行うようにしたが、これに限定されない。限定でなく例として、ユーザからチャージ要求を受け付ける際に都度行うようにしてもよいし、最初にチャージ要求を受け付ける際に包括的に同意を得るようにしてもよいし、チャージ要求を受ける前の任意のタイミングで事前に同意を得るようにしてもよい。

＜引落し条件＞
次に、引落し条件について、複数の具体例を説明する。

引落し条件１は、前回、銀行口座から引落しが行われた時点からの経過時間が所定の時間以上である場合であってもよい。所定の時間は、任意であるが、限定でなく例として、１週間や１ヵ月等であってもよい。

引落し条件２は、前回、銀行口座から引落しが行われた以降にチャージ要求を受けた回数が、所定の回数以上である場合であってもよい。例えば所定の回数が４回である場合、３回目までのチャージ要求では引落しは行われず、４回目のチャージ要求にて、１〜４回目までのチャージ要求に含まれるチャージ額の合計額が一括して銀行口座から引き落とされることになる。

引落し条件３は、未集金額が所定の金額以上である場合であってもよい。所定の金額は、任意であるが、限定でなく例として、５，０００円や１０，０００円などであってもよい。

引落し条件は、以上列挙した引落し条件１〜３のうち２以上を組み合わせたものであってもよい。また、引落し条件は、ユーザの信用スコアに応じて緩和されてもよい。例えば、信用スコアが高いユーザについては、引落し条件１における所定の時間を長くするようにしてもよいし、引落し条件２における所定の回数を多くしてもよいし、引落し条件３における所定の金額を高額にするようにしてもよい。また、信用スコアごとに、引落し条件１における所定の時間や、引落し条件２における所定の回数や、引落し条件３における所定の金額が別個に設定されていてもよい。ここで、ユーザの信用スコアとは、ユーザ個人の信用力を示す指標であり、ユーザ情報や、ユーザの行動によって変動しうる。第１実施形態では、銀行口座からの引落しが成功した回数が多いほど信用スコアが高くなるようにしてもよい。なお、引落し条件を満たす以前に、ユーザからの要求に応答して、引き落とし処理を実行させてもよいし、引落し条件をユーザが選択できるようにしてもよい。加えて、引落し条件を設定したユーザに特典を付与するようにしてもよい。

＜＜第１実施例＞＞
第１実施形態では、各ユーザが決済を行った場合、各ユーザの未集金額については、事業者が一時的に負担することになる。例えば、図６において、ステップＳ１１１の処理が行われる前にユーザＡが決済サービスの加盟店にて１，０００円分の決済を行った場合、事業者Ｚは、当該決済で支払われた金額１，０００円から加盟店手数料を引いた額を一時的に負担することになる。ユーザ数が多いと、事業者Ｚの金銭的負担も大きくなる。

そこで、サーバ１１０は、事業者に資金提供したユーザを管理し、資金提供したユーザに対しては何らかのインセンティブを付与するようにしてもよい。インセンティブは、限定でなく例として、提供した資金の額に応じたポイントであってもよいし、利子に相当する金銭であってもよい。また、資金を提供したユーザは、上述した信用スコアが高くなるようにしてもよい。

これにより、事業者の金銭的負担が軽減されると共に、ユーザにとってもインセンティブが付与されるというメリットを享受することが可能になる。

＜第２実施形態＞
第２実施形態では、決済サービスを多くのユーザが利用しており、サーバ１１０は、様々なユーザから多数のチャージ要求を受けているような状況を想定する。決済サービスを提供するサーバ１１０は、ユーザからチャージ要求を受け付ける際、予め定められたマッチング条件に従って複数のチャージ要求を束ねることでチャージ要求の組を作成し、当該チャージ要求の組に含まれるチャージ額の合計額を、当該チャージ要求の組に含まれるユーザの中から選択された１のユーザの銀行口座から一括して引き落とす処理を行う。

チャージ要求の組に含まれるチャージ額の合計額を一人のユーザの銀行口座から引き落とすことから、当該ユーザの銀行口座からは、ユーザが要求したチャージ額以上の金額が引き落とされることになる。つまり、第２実施形態に係る決済サービスでは、決済サービスを利用するユーザ間でチャージ額に対応する銀行口座の金額の貸し借りを行うことになる。

第２実施形態によれば、ユーザの銀行口座からの引落し回数を削減することができるため、ユーザがチャージを行う際に事業者が負担する手数料を軽減することが可能になるという効果が得られる。

また、第２実施形態によれば、銀行口座からの引落し処理を一括して行うことから、チャージ残高を管理する事業者のサーバと、銀行システム間のトランザクション数を削減することができると共に、サーバの処理負荷も軽減することが可能になるという効果が得られる。

また、第２実施形態によれば、事業者の手数料負担が軽減されることで新たなサービス創造につながり、その結果決済の利用率が更に高まるなど、なめらかな社会の創造に寄与することができるという効果が得られる。

＜第２実施形態の機能構成＞
図７を用いてサーバ１１０および端末１２０の機能構成を説明する。図７に開示の機能部は、情報処理装置２００が備えるプロセッサ２０１と、メモリ２０２と、ストレージ２０３と、入出力Ｉ／Ｆ２０４と、通信Ｉ／Ｆ２０５との協働により実現される。

（１）サーバの機能構成
サーバ１１０は、入出力Ｉ／Ｆ３１１と、通信Ｉ／Ｆ３１２と、制御部３１３と、記憶部３１４とを有する。入出力Ｉ／Ｆ３１１と、通信Ｉ／Ｆ３１２とは、それぞれ、図２の入出力Ｉ／Ｆ２０４と、通信Ｉ／Ｆ２０５とに対応する。制御部３１３は、同意処理部３３１と、チャージ受付部３３２と、チャージ管理部３３３と、口座管理部３３４と、マッチング処理部３３５と、ユーザ選択部３３６と、引落し処理部３３７とを含む。なお、各機能部の機能または処理は、実現可能な範囲において、機械学習またはＡＩ（Ａｒｔｉｆｉｃａｌ Ｉｎｔｅｌｌｉｇｅｎｃｅ）により実現されてもよい。

記憶部３１４は、プログラムとアカウント管理ＤＢ（DataBase）と口座管理ＤＢとを記憶する。図８は、第２実施形態に係るアカウント管理ＤＢの一例を示す図である。第２実施形態に係るアカウント管理ＤＢには、第１実施形態に係るアカウント管理ＤＢに加えて「位置情報」と「関係情報」とが格納される。位置情報には、端末１２０の現在位置が格納される。関係情報には、ユーザ間における所定の関係（以下、便宜上「友達関係」と言う。）に関する情報が格納される。

ここで、所定の関係とは、サーバ１１０が、２以上のユーザ間の所定の関係を記憶していることを意味する。限定でなく例として、所定の関係は、相互に関係構築を承認した関係、少なくとも一方が関係構築を申し入れた関係、ユーザ情報に基づき構築された関係、ユーザ行動に基づき構築された関係、所定の条件が満たされたことにより関係構築がなされた状態を含んでもよい。なお、ユーザ情報に基づき構築された関係とは、１以上の同一または類似するユーザ情報を有するユーザ同士を関係づけた関係を含んでもよいし、ユーザ行動に基づき構築された関係とは、１以上の同一または類似するユーザ行動を有するユーザ同士を関係づけた関係を含んでもよい。

また、ユーザと所定の関係にあるユーザは、限定ではなく例として、ユーザと所定の関係にある全てのユーザでもよいし、予め定められた所定の人数のユーザであってもよいし、親密度が所定の度合い以上のユーザであってもよい。

ここで、親密度とは、所定の期間内（１か月間や２か月間などの予め固定された期間でもよいし、所定の関係を構築してから現在までの期間でもよい）においてユーザとの間で送受信したメッセージの送受信量が多い順に親密度が高くなるように決定される度合いであってもよい。また、所定の期間内においてユーザ間で行われた取引（商品の売買や、資産の送受信・両替等などを含む）の回数が多い順に親密度が高くなるように決定される度合いでもよい。

また、親密度とは、所定の関係が構築されてから現在までの期間の長さが長いほど親密度が高くなるように決定される度合いであってもよい。所定の関係を構築してから現在までの期間の長さは、絶対値であってもよいし、ユーザと所定の関係にある１以上のユーザの中での相対値であってもよい。

また、親密度とは、ユーザと所定の関係にある複数の他のユーザについて、他のユーザがユーザの位置から所定の範囲内にいる時間の長さが長いほど、親密度が高くなるように決定される度合いであってもよい。また、親密度とは、ユーザと所定の関係にある複数のユーザについて、所定の関係が構築されてから現在までの期間と、各ユーザの位置情報とに基づいて推定される関係性（例えば家族関係にあると推定される等が高いほど親密度が高くなるように決定される度合いであってもよい。

また、親密度とは、ユーザと所定の関係にある複数の他のユーザについて、ユーザと共通のユーザの数（共通の友達の人数）が多いほど親密度が高くなるように決定される度合いであってもよい。

また、親密度とは、ユーザとコミュニケーションをとっているユーザと所定の関係を構築しているユーザのうち、ユーザ自身と所定の関係にあるユーザの数が多いほど親密度が高くなるように決定される度合いであってもよい。

また、親密度とは、ユーザ自身の属性と、ユーザと所定の関係にある複数のユーザの各々の属性との間における類似度が高いほど親密度が高くなるように決定される度合いであってもよい。ユーザの属性とは、限定ではなく例として、興味又は関心であってもよい。

図９は、第２実施形態に係る口座管理ＤＢの一例を示す図である。「未集金額／余剰集金額」には、チャージ額のうち銀行口座から引落しされていない金額、又は、余分に引落しされた金額が格納される。「引落し履歴」には、銀行口座から引落しが行われた日時及び引落し金額の履歴が格納される。

図９では、説明の便宜上、未集金額はプラスの金額で表現し、余剰集金額はマイナスの金額で表現する。例えば、チャージ額は１，０００円であるにも関わらず、他のユーザのチャージ額２，０００円と合わせて銀行口座から引き落とされたケースでは、余剰集金額には「−２，０００円」が格納される。

なお、第２実施形態の場合、未集金額は、自身の銀行口座に代えて他のユーザの銀行口座から引き落とされた金額に該当する。従って、未集金額は、他のユーザから借りている金銭の額と表現することができる。同様に、余剰集金額は、他のユーザの銀行口座から引き落とされるべきところ、自身の銀行口座から代わりに支払った（立て替えた）金額に該当する。従って、余剰集金額は、他のユーザに貸している金銭の額と表現することができる。

同意処理部３３１は、銀行口座からの引落しを、他のユーザのチャージ要求と一括して実行することについての同意をユーザから得る機能を有する。また、同意処理部３３１は、ユーザから同意を得る際に、ユーザの端末１２０に、チャージ要求の組を作成する際のマッチング条件（所定の条件）を通知する。

チャージ受付部３３２は、ユーザからチャージ要求を受け付ける機能を有する。

チャージ管理部３３３は、マッチング処理部３３５で作成されたチャージ要求の組に含まれる各ユーザのチャージ残高（各ユーザのアカウントの残高）に、各ユーザが要求したチャージ額を加算する機能を有する。

口座管理部３３４は、チャージ要求の組に含まれるユーザの中から選択された、１のユーザの銀行口座からの引き落としが行われることで発生する、複数のユーザ間での金銭の貸し借りを管理する機能を有する。具体的には、口座管理部３３４は、チャージ要求の組に含まれる各ユーザのチャージ額と、選択されたユーザの銀行口座からの引落し額とに基づいて、口座管理ＤＢにおける各ユーザの「未集金額／余剰集金額」を更新する処理を行う。

マッチング処理部３３５は、複数のユーザから受け付けたチャージ要求を、マッチング条件（所定の条件）に従ってマッチングさせることで、一括して口座引落しを行うチャージ要求の組を作成する機能を有する。マッチング条件の具体例については後述する。

ユーザ選択部３３６は、マッチング処理部３３５により作成されたチャージ要求の組に含まれるユーザの中から、銀行口座からの引落しを行うユーザを選択する機能を有する。

引落し処理部３３７は、チャージ要求の組に含まれる複数のチャージ額の合計額を、ユーザ選択部３３６で選択されたユーザの銀行口座から引き落とす機能を有する。

また、引落し処理部３３７は、銀行口座からの引落しを他のユーザのチャージ要求と一括して実行することに同意していないユーザについては、チャージ要求を受けた時点で、チャージ額をユーザの銀行口座から引き落とす処理を行う。

（２）端末の機能構成
端末１２０は、入出力Ｉ／Ｆ３２１と、通信Ｉ／Ｆ３２２と、制御部３２３と、記憶部３２４と、とを有する。入出力Ｉ／Ｆ３２１と、通信Ｉ／Ｆ３２２とは、それぞれ、図２の入出力Ｉ／Ｆ２０４と、通信Ｉ／Ｆ２０５とに対応する。制御部３２３は、通信部３４１と、ＵＩ（UserInterface）部３４２と、位置情報測定部３４３とを含む。記憶部３２４は、プログラムを記憶する。

なお、各機能部の機能または処理は、実現可能な範囲において、機械学習またはＡＩ（Ａｒｔｉｆｉｃａｌ Ｉｎｔｅｌｌｉｇｅｎｃｅ）により実現されてもよい。

通信部３４１は、サーバ１１０との間で、サーバ１１０が提供する決済サービスに関する各種の情報を送受信する機能を有する。また、通信部３４１は、銀行口座からの引落しを他のユーザのチャージ要求と一括して実行する処理について、チャージ要求の組を作成する際のマッチング条件（所定の条件）を示す情報を、サーバ１１０（残高を含むアカウント情報とユーザの銀行口座からの未集金額又は余剰集金額とをユーザごとに管理する情報処理装置）から受信する機能を有する。また、通信部３４１は、ＵＩ部３４２がユーザから受け付けた、銀行口座からの引落しを他のユーザのチャージ要求と一括して実行することに同意するか否かを示す情報をサーバ１１０に送信する機能を有する。なお、通信部３２５は、更に、受信処理を行う受信部と、送信処理を行う送信部とを含んでいてもよい。

ＵＩ部３４２は、サーバ１１０が提供する決済サービスに関する各種の画面を端末１２０のディスプレイに表示する機能を有する。また、当該決済サービスに関する各種の入力をユーザから受け付ける機能を有する。また、ＵＩ部３４２は、マッチング条件をディスプレイに表示すると共に、銀行口座からの引落しを他のユーザのチャージ要求と一括して実行することに同意するか否かの選択をユーザから受け付ける。ユーザから受け付けた結果（同意するか否か）を示す情報は、通信部３４１を介してサーバ１１０に送信される。ＵＩ部３４２は、更に、表示処理を行う表示部と、ユーザからの操作を受け付ける受付部とを含んでいてもよい。

通信部３４１及びＵＩ部３４２は、決済サービスに関するＷｅｂページを表示するＷｅｂブラウザが備える機能であってもよい。若しくは、通信部３４１及びＵＩ部３４２は、決済サービスを提供するための専用のプログラムにより提供される機能であってもよい。

位置情報測定部３４３は、端末１２０の現在位置の位置情報を測定し、測定した現在位置をアカウント管理ＤＢの「位置情報」に格納する機能を備える。位置情報測定部３４３は、限定でなく例として、ＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）を用いて、端末１２０の現在位置の位置情報として、該端末１２０の緯度および経度を測定する。なお、位置情報測定部３４３による端末１２０の位置情報の測定は、端末１２０の位置情報を測定できれば、どのような方法を用いてもよい。限定でなく例として、位置情報測定部３４３は、ＩＭＥＳ（Ｉｎｄｏｏｒ ＭＥｓｓａｇｉｎｇ Ｓｙｓｔｅｍ）、Ｗｉ−Ｆｉ（登録商標）、ＲＦＩＤ（Ｒａｄｉｏ Ｆｒｅｑｕｅｎｃｙ Ｉｄｅｎｔｉｆｉｅｒ）、ＮＦＣ（Ｎｅａｒ Ｆｉｅｌｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）、ＢＬＥ（Ｂｌｕｅｔｏｏｔｈ Ｌｏｗ Ｅｎｅｒｇｙ）、超音波などの近距離無線通信、ＬＴＥやＣＤＭＡなどの移動体通信システムなどを利用して、端末１２０の位置情報を測定してもよい。

＜第２実施形態の動作処理＞
図１０を参照し、実施形態に係る通信システム１の処理について説明する。図１０は、第２実施形態に係る通信システム１の処理のシーケンスの一例を示す。

ステップＳ２００で、端末１２０の通信部３４１は、ユーザの操作に応答して、サーバ１１０が提供する決済サービスの利用申し込みを依頼するメッセージをサーバ１１０に送信する。

ステップＳ２０１で、サーバ１１０の同意処理部３３１は、決済サービスの利用申し込みを依頼するメッセージを受信すると、決済サービスの利用に必要な各種情報の入力をユーザに促すメッセージを端末１２０に送信する。このとき、当該メッセージにはマッチング条件を示す情報が含まれる。端末１２０のＵＩ部３４２は、決済サービスの利用に必要な各種情報（氏名、年齢、ログインパスワード、引落し口座の口座番号等）の入力を促す画面を表示する。また、ＵＩ部３４２は、マッチング条件を表示すると共に、銀行口座からの引落しを他のユーザのチャージ要求と一括して実行することについて同意するか否かの選択をユーザに促す画面を表示する。

ステップＳ２０２で、端末１２０の通信部３４１は、ユーザが入力した決済サービスの利用に必要な各種情報と、銀行口座からの引落しを他のユーザのチャージ要求と一括して実行することについて同意するか否かの選択結果を示す情報とをサーバ１１０に送信する。

ステップＳ２０３で、サーバ１１０の同意処理部３３１は、アカウント管理ＤＢ及び口座管理ＤＢにユーザに関する新たなレコードを追加すると共に、口座管理ＤＢの同意フラグに、ユーザの選択結果をセットする。

以上説明したステップＳ２００〜ステップＳ２０３の処理手順は、決済サービスの利用を希望するユーザ毎に繰り返し行われる。以下で説明するステップＳ２０４以降の処理手順は、銀行口座からの引落しを他のユーザのチャージ要求と一括して実行することについて同意したユーザがチャージ要求を行う前提で説明を続ける。

ステップＳ２０４で、各端末１２０の通信部３４１は、チャージ要求メッセージをサーバ１１０に送信する。チャージ要求メッセージには、ユーザが要求するチャージ額が含まれる。

ステップＳ２０５で、サーバ１１０のマッチング処理部３３５は、ステップＳ２０４で受信した複数のチャージ要求の中から、マッチング条件に該当するチャージ要求を組みわせることで、チャージ要求の組を作成する。また、ユーザ選択部３３６は、チャージ要求の組に含まれるユーザの中から、口座引落しを行うユーザを選択する。ここではユーザＡが選択されたと仮定する。

ステップＳ２０６で、サーバ１１０の引落し処理部３３７は、口座管理ＤＢにおけるユーザＡの引落し口座に格納されている銀行口座（口座Ａ）から引き落とす金額を算出する。例えば、引落し処理部３３７は、チャージ要求の組に含まれる各チャージ額の合計を、口座Ａから引き落とす金額とする。また、引落し処理部３３７は、算出した金額を、口座Ａから引き落として事業者Ｚの口座に入金するように銀行１４０に依頼する。

ステップＳ２０７で、口座Ａから所定の金額が引き落とされ、手数料を差し引いた金額が事業者Ｚの口座に入金される。

ステップＳ２０８で、銀行１４０は、引落し処理が完了したことをサーバ１１０に通知する。

ステップＳ２０９で、サーバ１１０のチャージ管理部３３３は、アカウント管理ＤＢにおける、チャージ要求の組に含まれる各ユーザのチャージ残高に、各ユーザが要求したチャージ額を加算すると共に、各ユーザのチャージ履歴を更新する。また、口座管理部３３４は、チャージ要求の組に含まれる各ユーザのチャージ額と口座Ａからの引落し額とに基づいて、口座管理ＤＢにおける各ユーザの「未集金額／余剰集金額」に格納すべき金額を算出して更新する。

なお、口座管理ＤＢにおける各ユーザの「未集金額／余剰集金額」を更新した際に、未集金額が所定の金額以上であるユーザが存在する場合、引落し処理部３３７は、当該ユーザから当該未集金額を強制的に銀行口座から引落すようにしてもよい。これにより、未払い額が大きいユーザについては自動的に銀行口座からの引落しを実行することができる。

ステップＳ２１０で、サーバ１１０のチャージ管理部３３３は、各端末１２０に、チャージ処理が完了したことを通知するメッセージを送信する。

以上説明した処理手順において、銀行口座からの引落しを他のユーザのチャージ要求と一括して実行することについての同意を、決済サービスの利用申し込み時に行うようにしたが、これに限定されない。限定でなく例として、ユーザからチャージ要求を受け付ける際に都度行うようにしてもよいし、最初にチャージ要求を受け付ける際に包括的に同意を得るようにしてもよいし、チャージ要求を受ける前の任意のタイミングで事前に同意を得るようにしてもよい。

＜マッチング条件＞
続いて、マッチング処理部３３５が、複数のユーザから受け付けたチャージ要求をマッチングさせる際のマッチング条件について、複数の具体例を説明する。なお、マッチングは、銀行口座からの引落しを他のユーザのチャージ要求と一括して実行することに同意しているユーザのチャージ要求の中で行われる。

なお、マッチング条件は、以下に説明するマッチング条件１〜６のうち２以上を組み合わせたものであってもよい。また、マッチング条件１は必須とし、マッチング条件１とそれ以外のマッチング条件２〜６の中から１以上を組み合わせたものであってもよい。また、マッチング条件１及び２は必須とし、マッチング条件１及び２とそれ以外のマッチング条件３〜６の中から１以上を組み合わせたものであってもよい。

（マッチング条件１）
マッチング条件１は、マッチングさせるチャージ要求に含まれるチャージ額の合計額が所定の金額以上であることであってもよい。例えば、ユーザＡ、ユーザＢ、ユーザＣ及びユーザＤのチャージ要求がそれぞれ１，０００円、１，０００円、２，０００円及び３，０００円であり、所定の金額が４０００円以上であると仮定する。この場合、マッチング処理部３３５は、ユーザＡ、ユーザＢ、ユーザＣ及びユーザＤをマッチングさせるようにしてもよいし、ユーザＡ、ユーザＣ及びユーザＤをマッチングさせるようにしてもよいし、ユーザＡ、ユーザＢ及びユーザＤをマッチングさせるようにしてもよいし、ユーザＢ、ユーザＣ及びユーザＤをマッチングさせるようにしてもよいし、ユーザＡ、ユーザＢ及びユーザＣをマッチングさせるようにしてもよいし、ユーザＣ及びユーザＤをマッチングさせるようにしてもよい。

なお、マッチング条件１には、更に、マッチングさせるチャージ額の合計額に上限が設定されていてもよい。例えば、上限額が５０００円に設定されている場合、マッチング処理部３３５は、ユーザＡ、ユーザＢ及びユーザＣをマッチングさせるようにしてもよいし、ユーザＡ、ユーザＢ及びユーザＤをマッチングさせるようにしてもよいし、ユーザＣ及びユーザＤをマッチングさせるようにしてもよい。

これにより、銀行口座からの引落し額をある程度高額にすることができ、事業者の手数料負担を効果的に軽減することが可能になる。

（マッチング条件２）
マッチング条件２は、銀行口座からの未集金額が存在するユーザのチャージ要求と、銀行口座からの余剰集金額が存在するユーザのチャージ要求とをマッチングさせることであってもよい。例えば、口座管理ＤＢに図９に示すデータが格納されていると仮定する。この場合、マッチング処理部３３５は、ユーザＡとユーザＢをマッチングさせるようにしてもよいし、ユーザＢとユーザＣをマッチングさせるようにしてもよいし、ユーザＡ、ユーザＢ及びユーザＣをマッチングさせるようにしてもよい。

なお、マッチング条件２には、更に、未集金額が存在するユーザのチャージ要求の数と、余剰集金額が存在するユーザのチャージ要求の数とが同一になるようにするとの条件が含まれていてもよい。若しくは、マッチング条件２には、更に、マッチングさせるユーザの未集金額の絶対値と余剰集金額の絶対値との差が所定の差額以下であるとする条件が含まれていてもよい。

これにより、マッチングが繰り返されることで各ユーザの未集金額と余剰集金額とが平準化されることになり、ユーザ間で未集金額や余剰集金額に偏りが出てしまうことを抑制することができる。

（マッチング条件３）
マッチング条件３は、マッチングさせるチャージ要求の各ユーザの現在地（ユーザが利用する端末１２０の現在位置）が所定の範囲内であることであってもよい。例えば所定の範囲を１ｋｍの円とした場合、マッチング処理部３３５は、アカウント管理ＤＢの「位置情報」に格納されている現在地が所定の１ｋｍの円の中に含まれるユーザをピックアップし、ピックアップした複数のユーザの各々のチャージ要求を、チャージ要求の組とするようにしてもよい。

（マッチング条件４）
マッチング条件４は、マッチングさせるチャージ要求のユーザ間で、所定の関係（友達関係）が構築されていることであってもよい。例えば、ユーザＡ〜Ｃがいる場合において、ユーザＡ及びユーザＢの間は所定の関係を構築しているが、ユーザＣはユーザＡ及びユーザＢとの間で所定の関係を構築していないと仮定する。この場合、マッチング処理部３３５は、ユーザＡ及びユーザＢをマッチングするようにしてもよい。

（マッチング条件５）
マッチング条件５は、チャージ要求を受け付けたタイミングが所定の時間内であることであってもよい。所定の時間は、任意であるが、限定でなく例として５分や１０分といった時間であってもよい。

（マッチング条件６）
マッチング条件６は、マッチングさせるチャージ要求の数（つまり、チャージ要求の組に含まれるチャージ要求の数）が、所定の数以下であることであってもよい。これにより、大量のチャージ要求が１つのチャージ要求の組に含まれてしまうことにより、銀行口座からの引落し額が高額になってしまう可能性を抑制することができる。

＜ユーザ選択条件＞
ユーザ選択部３３６は、マッチング処理部３３５によりマッチングが行われることで生成されたチャージ要求の組の中から、銀行口座からの引落しを行う１のユーザを選択する。以下、ユーザ選択条件の具体例を説明する。なお、ユーザ選択条件は、以下に説明するユーザ選択条件１〜４のうち２以上を組み合わせたものであってもよい。

（ユーザ選択条件１）
ユーザ選択部３３６が選択するユーザは、チャージ要求の組に含まれるユーザのうち未集金額が最も大きいユーザであってもよい。未集金額が最も大きいユーザとすることで、ユーザ間に生じる不公平感を抑制することができる。

（ユーザ選択条件２）
チャージ要求の組に含まれるユーザの中に、未集金額を有するユーザが存在しない場合、ユーザ選択部３３６は、余剰集金額が最も小さいユーザを選択するようにしてもよい。ユーザ間に生じる不公平感を抑制することができる。

（ユーザ選択条件３）
ユーザ選択部３３６が選択するユーザは、チャージ要求の組に含まれるユーザのうち未集金額を有するユーザであって、口座管理ＤＢが現在の未集金額に更新されてからの期間が最も長いユーザであってもよい。払い過ぎの状態が継続することを抑制することができる。

（ユーザ選択条件４）
ユーザ選択部３３６が選択するユーザは、チャージ要求額が最も大きいユーザであってもよい。

（ユーザ選択条件５）
チャージ要求の組に含まれる全てのユーザが第２実施形態に係る決済サービスを初めて利用するユーザである場合、ユーザ選択部３３６は、信用スコアが高いユーザを選択するようにしてもよい。信用スコアは、限定でなく例として、決済サービスとは異なるサービスの利用履歴等に基づいて決定されたスコアであってもよい。

＜チャージ残高及び未集金額／余剰集金額の計算例＞
図１１は、第２実施形態に係るチャージ残高及び未集金額／余剰集金額の計算例を示す図である。図１１では、説明を簡略化するため、ユーザＡ及びユーザＢのみがチャージ要求を行う前提とする。また、ユーザＡ及びユーザＢ共にチャージ残高は０円であり、未集金額及び余剰集金額は無い（０円）であるものとする。この状態で、ユーザＡが１，０００円のチャージ要求を行い、ユーザＢが２，０００円のチャージ要求を行い、これらのチャージ要求がマッチングされたとする。また、銀行口座からの引落しを行うユーザとしてユーザＢが選択されたとする。

この場合、ユーザＡのチャージ残高には、ユーザＡが要求したチャージ額１，０００円が加算され、ユーザＢのチャージ残高には、ユーザＢが要求したチャージ額２，０００円が加算される。すなわち、ユーザＡのチャージ残高は１，０００円になり、ユーザＢのチャージ残高は２，０００円になる。

次に、ユーザＢの銀行口座から、ユーザＡのチャージ額とユーザＢのチャージ額の合計３，０００円が引落しされる。

次に、ユーザＡのチャージ額は１，０００円であるが、ユーザＡの銀行口座からは引き落とされていないことから、ユーザＡの「未集金額／余剰集金額」には、ユーザＡのチャージ額（１，０００）から、銀行口座から引き落とされた額（０円）を引いた額である「＋１，０００円（１，０００円−０円）」が加算される。すなわち、ユーザＡの「未集金額／余剰集金額」は＋１，０００円になる。

同様に、ユーザＢのチャージ額は２，０００円であるが、ユーザＢの銀行口座からは３，０００円が引き落とされたことから、ユーザＢの「未集金額／余剰集金額」には、ユーザＢのチャージ額（２，０００）から、銀行口座から引き落とされた額（３，０００円）を引いた額である「−１，０００円（２，０００円−３，０００円）」が加算される。すなわち、ユーザＢの「未集金額／余剰集金額」は−１，０００円になる。

次に、ユーザＡが４，０００円のチャージ要求を行い、ユーザＢが４，０００円のチャージ要求を行い、これらのチャージ要求がマッチングされたとする。また、銀行口座からの引落しを行うユーザとして、未集金額が最も大きいユーザＡが選択されたとする。

この場合、ユーザＡのチャージ残高には、ユーザＡが要求したチャージ額４，０００円が加算され、ユーザＢのチャージ残高には、ユーザＢが要求したチャージ額４，０００円が加算される。すなわち、ユーザＡのチャージ残高は５，０００円になり、ユーザＢのチャージ残高は６，０００円になる。

次に、ユーザＡの「未集金額／余剰集金額」には、ユーザＡのチャージ額（４，０００）から、銀行口座から引き落とされた額（８，００００円）を引いた額である「−４，０００円（４，０００円−８，０００円）」が加算される。すなわち、ユーザＡの「未集金額／余剰集金額」は−３，０００円になる。

また、ユーザＢの「未集金額／余剰集金額」には、ユーザＢのチャージ額（４，０００）から、銀行口座から引き落とされた額（０円）を引いた額である「４，０００円（４，０００円−０円）」が加算される。すなわち、ユーザＢの「未集金額／余剰集金額」は３，０００円になる。

＜＜第１実施例＞＞
サーバ１１０の口座管理部３３４は、各ユーザの余剰集金額の大きさに応じて特典を付与することとしてもよい。特定は、限定でなく例として、利子であってもよいし、クーポンであってもよいし、ポイントであってもよい。若しくは、ユーザの信用スコアの向上であってもよい。第１実施例によれは、本来支払うべき金額以上に銀行口座から引き落とされているユーザが抱く不公平感を抑制することが可能になる。

＜＜第２実施例＞＞
チャージ要求の数が少ない場合など、状況によってはマッチングに時間を要し、すぐにチャージがなされない可能性がある。そこで、第２実施例では、サーバ１１０のチャージ管理部３３３及び引落し処理部３３７は、追加手数料を支払ったユーザに対してはマッチングをすることなく、銀行口座からチャージ要求額を引き落としてチャージを完了させるようにしてもよい。第２実施例によれば、早急にチャージを行いたいユーザに対して、迅速にチャージを完了させることができる。

＜付記＞
（付記１−１）
情報処理装置（１１０）が行う情報処理方法であって、
ユーザごとに、残高を含むアカウント情報と、前記ユーザの銀行口座からの未集金額とを記憶部に記憶するステップ（３１４）と、
所定のユーザからチャージ額を指定するチャージ要求を受け付けるステップ（３１６）と、
受け付けたチャージ額を、前記所定のユーザのアカウントの残高と未集金額との各々に加算するステップ（３１７）と、
前記所定のユーザの銀行口座からの引落しに関する所定の条件を満たす場合に、前記所定のユーザの未集金額を前記銀行口座から引き落とすステップ（３１９）と、を含む情報処理方法。

（付記１−２）
前記銀行口座からの引落しを一括して実行することについての同意を前記所定のユーザから得るステップ（３１５）と、
前記銀行口座から引落すステップ（３１９）は、前記同意を前記所定のユーザから得た場合に、前記所定のユーザの未集金額を前記銀行口座から引き落とす、
付記１−１に記載の情報処理方法。

（付記１−３）
前記同意を前記所定のユーザから得るステップ（３１５）は、前記所定のユーザから前記同意を得る際に、前記所定のユーザの端末に前記所定の条件を通知する、
付記１−２に記載の情報処理方法。

（付記１−４）
前記所定の条件は、
前回前記銀行口座から引落しが行われた時点からの経過時間が所定の時間以上である場合、
前回前記銀行口座から引落しが行われた以降に前記チャージ要求を受けた回数が、所定の回数以上である場合、または、
前記未集金額が所定の金額以上である場合、のうち少なくとも１つを含む、
付記１−１〜１−３のいずれか一項に記載の情報処理方法。

（付記１−５）
前記所定の条件が満たされるよりも前に、前記所定のユーザの要求に基づいて前記所定のユーザの未集金額を前記銀行口座から引き落とすステップをさらに含む、
付記１−１〜１−４のいずれか一項に記載の情報処理方法。

（付記１−６）
前記所定の条件は、前記ユーザにより指定されるステップを更に含む、
付記１−１〜１−５のいずれか一項に記載の情報処理方法。

（付記１−７）
ユーザごとに、残高を含むアカウント情報と、前記ユーザの銀行口座からの未集金額とを記憶する記憶部（３１４）と、
所定のユーザからチャージ額を指定するチャージ要求を受け付ける受付部（３１６）と、
受け付けたチャージ額を、前記所定のユーザのアカウントの残高と未集金額との各々に加算するチャージ管理部（３１７）と、
前記所定のユーザの銀行口座からの引落しに関する所定の条件を満たす場合に、前記所定のユーザの未集金額を前記銀行口座から引き落とす引落し処理部（３１９）と、を含む情報処理装置（１１０）。

（付記１−８）
情報処理装置（１１０）に、
ユーザごとに、残高を含むアカウント情報と、前記ユーザの銀行口座からの未集金額とを記憶部に記憶するステップ（３１４）と、
所定のユーザからチャージ額を指定するチャージ要求を受け付けるステップ（３１６）と、
受け付けたチャージ額を、前記所定のユーザのアカウントの残高と未集金額との各々に加算するステップ（３１７）と、
前記所定のユーザの銀行口座からの引落しに関する所定の条件を満たす場合に、前記所定のユーザの未集金額を前記銀行口座から引き落とすステップ（３１９）と、を実行させるプログラム。

（付記１−９）
情報処理装置（１２０）に、
銀行口座からの引落しを一括して実行する処理について、前記銀行口座からの引落しを実行するための所定の条件を示す情報を、残高を含むアカウント情報とユーザの銀行口座からの未集金額とをユーザごとに管理する情報処理装置（１１０）から受信するステップと（３２５）、
前記所定の条件に基づいて前記銀行口座からの引落しを一括して実行する処理について同意するか否かをユーザから受け付けるステップ（３２６）と、
前記ユーザから受け付けた、前記処理に同意するか否かを示す情報を前記情報処理装置（１１０）に送信するステップ（３２５）と、を実行させるプログラム。

（付記１−１０）
前記所定の条件は、
前回前記銀行口座から引落しが行われた時点からの経過時間が所定の時間以上である場合、
前回前記銀行口座から引落しが行われた以降にチャージ要求を受けた回数が、所定の回数以上である場合、又は、
前記未集金額が所定の金額以上である場合、のうち少なくとも１つを含む、
付記１−９に記載のプログラム。

（付記１−１１）
銀行口座からの引落しを一括して実行する処理について、前記銀行口座からの引落しを実行するための所定の条件を示す情報を、残高を含むアカウント情報とユーザの銀行口座からの未集金額とをユーザごとに管理する他の情報処理装置（１１０）から受信する受信部（３２５）と、
前記所定の条件に基づいて前記銀行口座からの引落しを一括して実行する処理について同意するか否かをユーザから受け付ける受付部（３２６）と、
前記ユーザから受け付けた、前記処理に同意するか否かを示す情報を前記他の情報処理装置（１１０）に送信する送信部（３２５）と、を有する情報処理装置（１２０）。

（付記１−１２）
情報処理装置（１２０）が行う情報処理方法であって、
銀行口座からの引落しを一括して実行する処理について、前記銀行口座からの引落しを実行するための所定の条件を示す情報を、残高を含むアカウント情報とユーザの銀行口座からの未集金額とをユーザごとに管理する他の情報処理装置（１１０）から受信するステップ（３２５）と、
前記所定の条件に基づいて前記銀行口座からの引落しを一括して実行する処理について同意するか否かをユーザから受け付けるステップ（３２６）と、
前記ユーザから受け付けた、前記処理に同意するか否かを示す情報を前記他の情報処理装置（１１０）に送信するステップ（３２５）と、を含む情報処理方法。

（付記２−１）
情報処理装置（１１０）が行う情報処理方法であって、
ユーザからチャージ額を指定するチャージ要求を受け付けるステップ（３３２）と、
複数のユーザから受け付けたチャージ要求を所定の条件に従ってマッチングさせることで、一括して口座引落しを行うチャージ要求の組を作成するステップ（３３５）と、
前記チャージ要求の組に含まれるチャージ要求を行ったユーザの中から、銀行口座からの引落しを行うユーザを選択するステップ（３３６）と、
前記チャージ要求の組に含まれるチャージ額の合計額を、選択されたユーザの銀行口座から引き落とすステップ（３３７）と、
前記チャージ要求の組に含まれる各ユーザのアカウントの残高に、各ユーザが要求したチャージ額を加算するステップ（３３３）と、
前記銀行口座からの引き落としが行われることで発生する前記複数のユーザ間での金銭の貸し借りを管理するステップ（３３４）と、を含む情報処理方法。

（付記２−２）
前記銀行口座からの引落しを、他のユーザのチャージ要求と一括して実行することについての同意を所定のユーザから得るステップ（３３１）と、
前記チャージ要求の組を作成するステップ（３３５）は、前記同意を得たユーザから受け付けたチャージ要求の中からマッチングを行う、
付記２−１に記載の情報処理方法。

（付記２−３）
前記同意をユーザから得るステップ（３３１）は、前記所定のユーザから前記同意を得る際に、前記所定のユーザの端末に前記所定の条件を通知する、
付記２−２に記載の情報処理方法。

（付記２−４）
前記所定の条件は、マッチングさせるチャージ要求に含まれるチャージ額の合計額が所定の金額以上であること、を含む、
付記２−１〜２−３のいずれか一項に記載の情報処理方法。

（付記２−５）
前記所定の条件は、銀行口座からの未集金額が存在するユーザのチャージ要求と、銀行口座からの余剰集金額が存在するユーザのチャージ要求とをマッチングさせること、を含む、
付記２−１〜２−４のいずれか一項に記載の情報処理方法。

（付記２−６）
前記所定の条件は、
前記ユーザの位置情報と、マッチングさせるユーザの位置情報とが所定の範囲内であること、
前記ユーザと、マッチングさせるユーザとが所定の関係を構築していること、または、
マッチングさせるチャージ要求を受け付けたタイミングが所定の時間内であること、のうち少なくとも１つを含む、
付記２−１〜２−５のいずれか一項に記載の情報処理方法。

（付記２−７）
ユーザからチャージ額を指定するチャージ要求を受け付ける受付部（３３２）と、
複数のユーザから受け付けたチャージ要求を所定の条件に従ってマッチングさせることで、一括して口座引落しを行うチャージ要求の組を作成するマッチング処理部（３３５）と、
前記チャージ要求の組に含まれるチャージ要求を行ったユーザの中から、銀行口座からの引落しを行うユーザを選択する選択部（３３６）と、
前記チャージ要求の組に含まれるチャージ額の合計額を、選択されたユーザの銀行口座から引き落とす引落し処理部（３３７）と、
前記チャージ要求の組に含まれる各ユーザのアカウントの残高に、各ユーザが要求したチャージ額を加算するチャージ管理部（３３３）と、
前記銀行口座からの引き落としが行われることで発生する前記複数のユーザ間での金銭の貸し借りを管理する口座管理部（３３４）と、を含む情報処理装置（１１０）。

（付記２−８）
情報処理装置（１１０）に、
ユーザからチャージ額を指定するチャージ要求を受け付けるステップ（３３２）と、
複数のユーザから受け付けたチャージ要求を所定の条件に従ってマッチングさせることで、一括して口座引落しを行うチャージ要求の組を作成するステップ（３３５）と、
前記チャージ要求の組に含まれるチャージ要求を行ったユーザの中から、銀行口座からの引落しを行うユーザを選択するステップ（３３６）と、
前記チャージ要求の組に含まれるチャージ額の合計額を、選択されたユーザの銀行口座から引き落とすステップ（３３７）と、
前記チャージ要求の組に含まれる各ユーザのアカウントの残高に、各ユーザが要求したチャージ額を加算するステップ（３３３）と、
前記銀行口座からの引き落としが行われることで発生する前記複数のユーザ間での金銭の貸し借りを管理するステップ（３３４）と、を実行させるプログラム。

（付記２−９）
情報処理装置（１２０）に、
銀行口座からの引落しを他のユーザのチャージ要求と一括して実行する処理について、複数のユーザから受け付けたチャージ要求をマッチングさせることでチャージ要求の組を作成する際の所定の条件を示す情報を、残高を含むアカウント情報とユーザの銀行口座からの未集金額又は余剰集金額とをユーザごとに管理する情報処理装置（１１０）から受信するステップ（３４１）と、
前記所定の条件に基づいて銀行口座からの引落しを他のユーザのチャージ要求と一括して実行する処理について同意するか否かをユーザから受け付けるステップ（３４２）と、
前記ユーザから受け付けた、前記処理に同意するか否かを示す情報を前記情報処理装置（１１０）に送信するステップ（３４１）と、を実行させるプログラム。

（付記２−１０）
前記所定の条件は、マッチングさせるチャージ要求に含まれるチャージ額の合計額が所定の金額以上であること、を含む、
付記２−８に記載のプログラム。

（付記２−１１）
前記所定の条件は、銀行口座からの未集金額が存在するユーザのチャージ要求と、銀行口座からの余剰集金額が存在するユーザのチャージ要求とをマッチングさせること、を含む、
付記２−８又は９に記載のプログラム。

（付記２−１２）
前記所定の条件は、
前記ユーザの位置情報と、マッチングさせるチャージ要求のユーザの位置情報とが所定の範囲内であること、
前記ユーザと、マッチングさせるチャージ要求のユーザが所定の関係を構築していること、または、
マッチングさせるチャージ要求を受け付けたタイミングが所定の時間内であること、のうち少なくとも１つを含む、
付記２−８〜２−１０のいずれか一項に記載のプログラム。

（付記２−１３）
コンピュータに、
銀行口座からの引落しを他のユーザのチャージ要求と一括して実行する処理について、複数のユーザから受け付けたチャージ要求をマッチングさせることでチャージ要求の組を作成する際の所定の条件を示す情報を、残高を含むアカウント情報とユーザの銀行口座からの未集金額又は余剰集金額とをユーザごとに管理する他の情報処理装置（１１０）から受信する受信部（３４１）と、
前記所定の条件に基づいて銀行口座からの引落しを他のユーザのチャージ要求と一括して実行する処理について同意するか否かをユーザから受け付ける受付部（３４２）と、
前記ユーザから受け付けた、前記処理に同意するか否かを示す情報を前記他の情報処理装置（１１０）に送信する送信部（３４１）と、を有する情報処理装置（１２０）。

（付記２−１４）
情報処理装置（１２０）が行う情報処理方法であって、
銀行口座からの引落しを他のユーザのチャージ要求と一括して実行する処理について、複数のユーザから受け付けたチャージ要求をマッチングさせることでチャージ要求の組を作成する際の所定の条件を示す情報を、残高を含むアカウント情報とユーザの銀行口座からの未集金額又は余剰集金額とをユーザごとに管理する他の情報処理装置（１１０）から受信するステップ（３４１）と、
前記所定の条件に基づいて銀行口座からの引落しを他のユーザのチャージ要求と一括して実行する処理について同意するか否かをユーザから受け付けるステップ（３４２）と、
前記ユーザから受け付けた、前記処理に同意するか否かを示す情報を前記他の情報処理装置（１１０）に送信するステップ（３４１）と、を含む情報処理方法。

１ 通信システム
１１０ サーバ
１２０ 端末
１３０ ネットワーク
１４０ 銀行
２００ 情報処理装置
２０１ プロセッサ
２０２ メモリ
２０３ ストレージ
２０４ 入出力インタフェース（入出力Ｉ／Ｆ）
２０５ 通信インタフェース（通信Ｉ／Ｆ）
３１３ 制御部
３１４ 記憶部
３１５ 同意処理部
３１６ チャージ受付部
３１７ チャージ管理部
３１８ 口座管理部
３１９ 引落し処理部
３２３ 制御部
３２４ 記憶部
３２５ 通信部
３２６ ＵＩ部
３３１ 同意処理部
３３２ チャージ受付部
３３３ チャージ管理部
３３４ 口座管理部
３３５ マッチング処理部
３３６ ユーザ選択部
３３７ 引落し処理部
３４１ 通信部
３４２ ＵＩ部
３４３ 位置情報測定部

Claims (1)

1. 明細書に記載の発明。