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

Abstract

【課題】決済額に基づく電子バリューを、他のユーザから簡単に受け取る仕組みを提供する。
【解決手段】情報処理装置が実行する情報処理方法であって、第１ユーザが利用する第１情報処理装置から、電子バリュー情報と送金リクエストとを取得するステップと、送金リクエストに応答して、第１ユーザに関連付けられた１又は複数のユーザの中から、所定の条件を満たす第２ユーザに対応付けられた制限情報と、電子バリュー情報とに基づいて、各第２ユーザに対応付ける電子バリューの値を決定するステップと、各第２ユーザのアカウントの残高から、決定された電子バリューの値をそれぞれ減算し、第１ユーザのアカウントの残高に電子バリューの値を加算する送金処理を実行するステップと、を含む。
【選択図】図５

Description

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

近年、商品やサービスを購入する商取引の際に、いわゆる電子マネーを用いて支払いを行うことができる決済サービスが普及している。当該決済サービスでは、ユーザが、所望金額の電子マネーを、専用または汎用の電子マネーカードや、ユーザに関連付けられた電子マネー口座などの電子バリューに予め入金（チャージ）しておき、その入金額を限度に、商取引における商品やサービスの購入時の支払いを電子マネーによって決済することができる。

特開２００８−２６９０６２

しかしながら、従来技術では、ユーザが他人から電子バリューを受け取る際に、ファミリー口座を設定する必要があり、そのファミリー口座へのチャージ手続き、ファミリー口座のパスワードの設定などの情報の煩雑な手続きが必要になる。

本開示は、ユーザが、他のユーザから電子バリューを容易に受け取れることを提供することを可能にする情報処理方法、情報処理装置、及びプログラムを提供することを目的とする。

本開示の一実施形態に係る情報処理装置が実行する情報処理方法は、第１ユーザが利用する第１情報処理装置から、電子バリュー情報と送金リクエストとを取得するステップと、前記送金リクエストに応答して、前記第１ユーザに関連付けられた１又は複数のユーザのうち所定の条件を満たす第２ユーザに対応付けられた制限情報と、前記電子バリュー情報とに基づいて、各第２ユーザに対応付ける電子バリューの値を決定するステップと、前記各第２ユーザのアカウントの残高から、決定された電子バリューの値をそれぞれ減算し、前記第１ユーザのアカウントの残高に前記電子バリューの値を加算する送金処理を実行するステップとを含む。

実施形態の一態様に係る通信システムの構成を示す。 本開示に係る情報処理装置のハードウェア構成の一例を示す。 実施形態に係る情報処理装置の機能的な構成を示すブロック図の一例を示す。 実施形態に係る各管理ＤＢの一例を示す。 実施形態に係る事前承認の場合における通信システムの処理のシーケンスの一例を示す。 実施形態に係る決済時承認の場合における通信システムの処理のシーケンスの一例を示す。 実施形態に係る送金要求画面の一例を示す。 実施形態に係る送金承認画面の一例を示す。 実施形態に係る送金完了通知画面の一例を示す。

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

本開示に係る情報処理方法、情報処理装置、及びプログラムを実施するための形態について、図面を参照して説明する。

＜システム構成＞
図１は、本開示の一実施形態に係る通信システム１の構成を示す。図１に開示されるように、通信システム１では、ネットワーク１３０を介してサーバ１１０Ａ、サーバ１１０Ｂと、端末１２０Ａ、端末１２０Ｂ、端末１２０Ｃと、外部システム１４０が接続される。外部システム１４０は、限定でなく例として、他の事業者（金融機関、クレジットカード会社など）や他の事業部門によって運営されるサーバなどによって構築される。

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

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

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

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

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

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

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

ネットワーク１３０のうちの１つまたは複数の部分は、有線ネットワークや無線ネットワークであってもよい。ネットワーク１３０は、限定でなく例として、アドホック・ネットワーク（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）、プロジェクションマッピング、ホログラム、空気中など（真空であってもよい）に画像やテキスト情報等を表示可能な装置、スピーカ（音声出力）、プリンターなどを含む。なお、これらの出力装置は、３Ｄで表示データを表示可能であってもよい。

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

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

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

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

なお、本開示のプログラムは、限定でなく例として、JavaScript（登録商標）、Pythonなどのスクリプト言語、Ｃ言語、Ｇｏ言語、Swift、Kotlin、Java（登録商標）などを用いて実装される。

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

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

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

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

本開示は、本開示の実施形態および実施例に対して、当業者が成し得る全ての変更、置換、変形、改変、または修正を包含する。また、添付の特許請求の範囲は、本開示の実施形態および実施例に対して、当業者が成し得る全ての変更、置換、変形、改変、または修正を包含する。さらに、本開示は、当業者が成し得る、本開示における実施形態または実施例の１以上の特徴と、本開示における他の実施形態または実施例の１以上の特徴との任意の組合せを包含する。加えて、特定の機能を実施するように適合される、配置される、能力を有する、構成される、使用可能である、動作可能である、または動作できる装置またはシステムあるいは装置またはシステムの構成要素に対する添付の特許請求の範囲での参照は、その装置、システム、または構成要素がそのように適合される、配置される、能力を有する、構成される、使用可能にされる、動作可能にされる、または動作できる限り、その装置、システム、構成要素またはその特定の機能がアクティベートされ、オンにされ、またはロック解除されているか否かに関わらず、その装置、システム、構成要素を包含する。

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

＜実施形態＞
実施形態は、ユーザが電子バリュー（例えば電子決済を行う際の決済額に基づく電子バリュー）を、このユーザに関連付けられた関連ユーザから、容易に受け取ることを可能にする実施形態である。例えば、サーバ１１０は、ユーザＡが利用する端末１２０Ａから、電子バリュー情報と送金リクエストとを受信する。そして、サーバ１１０は、受信した送金リクエストに応答して、ユーザＡに関連付けられた１又は複数の関連ユーザと、電子バリュー情報とに基づいて、各関連ユーザから送金される電子バリューの値を決定して、送金処理を行う。ここで、サーバ１１０は、情報処理装置の一例であり、端末１２０Ａは、第１情報処理装置の一例である。また、ユーザＡは、第１ユーザの一例であり、関連ユーザは、第２ユーザの一例である。

実施形態により、ユーザが、他のユーザから電子バリューを容易に受け取ることが可能になる。また、ユーザは送金リクエストを介して、関連ユーザから電子バリューを受け取ることができるため、手続等を簡素にするとともに、電子バリューを得るための処理に係る時間を短くすることができ、ユーザ利便性の向上を図ることができるという効果が得られる。

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

（１）サーバの機能構成
サーバ１１０は、入出力Ｉ／Ｆ３１１と、通信Ｉ／Ｆ３１２と、制御部３１３と、記憶部３１４と、表示制御部３１５と、通信部３１６と、要求処理部３１７と、送金処理部３１８を有する。なお、各機能部の機能または処理は、実現可能な範囲において、機械学習またはＡＩ（Artificial Intelligence）により実現されてもよい。

入出力Ｉ／Ｆ３１１は、例えば、入出力Ｉ／Ｆ２０４を用いて実現されうる。また、通信Ｉ／Ｆ３１２は、例えば、通信Ｉ／Ｆ２０５を用いて実現されうる。制御部３１３は、プロセッサ２０１が、記憶部３１４に格納されているプログラムを読み出して実行することで実現されうる。記憶部３１４は、メモリ２０２及び／又はストレージ２０３を用いて実現されうる。

記憶部３１４は、本実施形態に係るサーバ１１０が実行するプログラムと、決済事業者により提供される電子決済を利用するユーザのアカウント情報を管理するユーザ管理ＤＢ（Data Base）と、関連付けリクエストを行ったユーザに関連付けられたユーザの情報を管理する関連ユーザ管理ＤＢと、電子バリューの送金要求情報を管理する送金管理ＤＢと、を格納する。図４は、実施形態に係る各管理ＤＢの一例を示す図である。

図４（Ａ）は、ユーザ管理ＤＢの一例を示す。ユーザ管理ＤＢには、決済事業者により作成された各ユーザのアカウントに関する情報が含まれる。ここで、決済事業者は、電子決済サービスや送金サービスを実行可能な事業者である。「ユーザＩＤ」には、サーバ１１０がユーザを一意に識別するためのユーザ識別情報（ＩＤ：IDentifier）が含まれる。「パスワード」には、ユーザ認証を行うためのパスワードが含まれる。「残高」には、ユーザが保有するアカウントの電子バリュー（又は電子マネー）の残高が含まれる。

図４（Ｂ）は、関連ユーザ管理ＤＢの一例を示す。関連ユーザ管理ＤＢには、関連付けリクエストを行ったユーザに関連付けられたユーザ（関連ユーザ）に関する情報が含まれる。「要求元ユーザＩＤ」には、関連付けリクエストをしたユーザを一意に識別するためのユーザＩＤが含まれる。「関連ユーザＩＤ」には、要求元ユーザＩＤに関連付けられたユーザのユーザＩＤが含まれる。「制限情報」には、各関連ユーザが設定した、要求元ユーザＩＤへの送金に対する制限情報が含まれる。また、限定でなく例として、「制限情報」には、「承認の有無」、「送金上限」及び「送金回数」に係る情報が含まれてもよい。

「承認の有無」には、関連ユーザからの送金に対しての承認の有無情報が含まれる。ここで、「送金」は、後述する事前承認に基づく送金と、後述する決済時承諾に基づく送金との両方の意味を有する。また、事前承認に基づく送金は、事前承認の後から決済時までに発生する送金であってもよい。また、「承認の有無」には、サーバ１１０からの送金に関する事前承認の問い合わせに対して関連ユーザの承認の有無に係る情報（例えば後述する図５に示すステップＳ１２２での「承認通知」）と、サーバ１１０からの決済時の送金依頼情報に対して関連ユーザの承認の有無に係る情報（例えば後述する図６に示すステップＳ２４４での「承認情報」）とが含まれる。この「承認の有無」に係る情報は、決済時承認及び事前承認の場合に、関連ユーザを特定する際に用いられてもよい。また、この事前承認に係る「承認の有無」に基づいて、要求元ユーザが再度要求先ユーザを設定するときに、サーバ１１０は、再度設定された要求先ユーザが、前回の事前承認の設定を承諾したユーザであるか、又は前回の事前承諾の設定を拒否したユーザであるかを判断することができる。また、上限金額を示す「送金上限」、及び所定期間における要求元ユーザＩＤに対する送金回数の上限値を示す「送金回数」が含まれる。例えば、「送金上限」は、送金１回あたりの上限金額や、所定期間における送金の上限金額であってもよい。なお、関連ユーザが「送金上限」を設定しない場合には、「送金上限」は「無限（無制限）」として登録されてもよい。例えば、「送金回数」には、週、月又は年等の所定期間における送金できる上限回数、例えば、１回／週、４回／月、無限等が含まれる。なお、ここで「制限情報」は「送金上限」及び「送金回数」を含むデータとして説明したが、「送金上限」及び「送金回数」以外の制限情報を含めてもよい。例えば、送金できる時間制限（例えば、平日限定、週末限定等）などをさらに含めてもよい。

図４（Ｃ）は、送金管理ＤＢの一例を示す。送金管理ＤＢには、要求元のユーザが求める電子バリューの要求金額情報と、要求先の関連ユーザの送金に関する送金情報とが含まれる。「送金ＩＤ」には、送金リクエストを一意に識別するための送金リクエスト識別情報が含まれる。「要求元ユーザＩＤ」には、送金リクエストを送信した要求元ユーザのユーザＩＤが含まれる。「電子バリュー」には、要求元ユーザが求める電子バリューの要求金額情報が含まれる。「期限」には、要求元ユーザが求める電子バリューの要求金額を受け付ける期限が含まれる。「送金情報」には、各要求先のユーザＩＤと、各要求先のユーザが送金する、または、送金した電子バリューの値とが含まれる。この「送金情報」に係る情報は、後述する返済要求がある場合に利用されてもよい。また、図４（Ｃ）に図示していないが、送金管理ＤＢには、要求先のユーザのアカウントの残高や、パスワード等の情報が含まれてもよい。

図３に戻り、通信Ｉ／Ｆ３１２は、端末１２０からの関連付けリクエスト、送金リクエスト、承認通知または承認情報などを受信し、あるいは、端末１２０に、サーバ１１０で生成されたペアリング情報、送金依頼情報、送金完了通知または返済要求通知などを送信する。

入出力Ｉ／Ｆ３１１は、決済事業者の管理者等から、所定のデータの入力を受け付けたり、管理画面等の画面情報を出力したりする。

制御部３１３内の表示制御部３１５は、電子決済に関するサービスにおいて表示される表示画面などを生成する機能を有する。例えば、表示制御部３１５は、送金の要求元の端末１２０から電子バリュー情報と送金リクエストとを受けた場合には、送金リクエスト画面を生成し、この送金リクエスト画面の画面情報を要求元の端末１２０に送信するようにしてもよい。

通信部３１６は、通信Ｉ／Ｆ３１２を用いて、データの送受信を制御する機能を有する。例えば、通信部３１６は、他のサーバ１１０や他の端末１２０にデータを送信する送信部としての機能と、他のサーバ１１０や他の端末１２０からデータを受信する受信部としての機能とを有する。

例えば、通信部３１６の受信部は、要求元のユーザ（例えばユーザＡ）が利用する端末１２０（例えば端末１２０Ａ）から、電子バリュー情報（例えば電子決済における決済額）と送金リクエストとを受信する。ここで、電子バリュー情報は電子決済における決済額を例として説明するが、この例に限られない。例えば、電子バリュー情報は、電子決済における決済額とユーザＡのアカウントの残高との差額であってもよく、また、ユーザＡが指定した任意の金額であってもよい。さらに、送金リクエストは要求元ユーザが決済を行う時に送信される例として説明するが、この例に限られない。例えば、送金リクエストは要求元ユーザによって予めサーバ１１０に送信されていてもよい。換言すれば、要求元ユーザが事前に送金リクエストを設定しておいてもよい。またさらに、送金リクエストは、ユーザＡの指示により送信される例に限られない。例えば、送金リクエストは、ユーザＡのアカウントの残高が足りないときに、ユーザＡが利用する端末１２０Ａによって自動的に送信されてもよい。

また、通信部３１６の送信部は、送金リクエストを受信した後、１又は複数の関連ユーザが利用する端末１２０に、送金依頼情報を送信する。ここで、送金依頼情報は、例えば、要求金額と、この要求金額の支払期限等に関する情報とを含む。また、通信部３１６の受信部は、１又は複数の関連ユーザが利用する端末１２０から、送金依頼情報に対する承認情報を受信する。承認情報は、送金依頼情報に対する承認または否認の情報を含む。関連ユーザが利用する端末１２０が、事前の承認を行っている場合（つまり、関連ユーザの制限情報のうち承認の有無が有となっている場合）は、送金依頼情報は承認されるものとして送金依頼情報を送信しなくてもよい。

また、通信部３１６の送信部は、送金処理の終了後、関連ユーザが利用する各端末１２０に、サーバ１１０により決定された電子バリューの値が減算されたことの送金金額通知を送信してもよい。

また、通信部３１６の受信部は、ユーザＡが利用する端末１２０Ａから、ユーザの関連付けリクエストを受信する。通信部３１６の送信部は、このユーザＡと関連付けるための情報を含むペアリング情報を端末１２０Ａまたは、他の端末１２０（例えば端末１２０Ｂ〜１２０Ｄ）に送信する。ペアリング情報は、ユーザＡと他のユーザとを対応付けるための情報を含む。また、通信部３１６の受信部は、ペアリング情報を取得した他のユーザ（例えばユーザＢ〜Ｄ）が利用する端末１２０（例えば端末１２０Ｂ〜１２０Ｄ）から、ペアリング情報とユーザ識別情報（例えばユーザＢ〜ＤのユーザＩＤ）とを受信する。

また、通信部３１６の送信部は、関連ユーザが、送金リクエストに応答してユーザＡに送金した電子バリューに対して返済を求める場合、この返済要求をユーザＡが利用する端末１２０Ａに送信してもよい。

関連付け処理部３１７は、端末１２０からユーザの関連付けリクエストを受けた場合、関連付け処理を行い、要求元ユーザのユーザＩＤと要求先ユーザのユーザＩＤとを関連付ける。ここで、関連付け処理は、様々な方法を用いて行われることが可能であり、この関連付け処理の詳細については後述する。

また、要求処理部３１７は、ユーザＡに１又は複数の関連ユーザが関連付けられる場合、ユーザＡと１又は複数の関連ユーザとを上述の制限情報とともに、関連付けてもよい。

また、要求処理部３１７は、送金リクエストが受信された後、要求元のユーザＡに関連付けられた１又は複数の要求先の関連ユーザのうち所定の条件を満たす関連ユーザの数（例えばユーザＢ，Ｃ，Ｄの三人）を取得する。ここで、所定の条件は、関連ユーザに対応付けられた制限情報に基づいて設定されてもよい。例として、承認の有無が有であること、電子バリュー情報が送金上限以下であること、及び、送金リクエストに対して送金した回数が送金回数以下であることのうち少なくとも１つを含んでもよい。なお、これらの条件に優先度を設定し、優先度の高い条件の順に条件を設定してもよい。例として、承認の有無が有となっている関連ユーザ（送金依頼情報に対する承認が不要であるユーザ）の優先度を、承認の有無が無となっている関連ユーザの優先度よりも高く設定してもよい。

また、要求処理部３１７は、要求元のユーザＡに要求先のユーザＢ，Ｃ，Ｄを関連付ける場合、要求元のユーザＡへの送金に対して承認を与えたユーザ（例えばユーザＢ，Ｃ，Ｄ）を関連付けてもよい。すなわち、要求元のユーザＡへの送金依頼情報に対して、事前に承認した要求先ユーザを関連付けてもよい。

このような事前承認の場合において、要求処理部３１７は、関連付けリクエストを送信した要求元のユーザＡのユーザＩＤと、このユーザＩＤに関連付けられた関連ユーザ（ユーザＢ，Ｃ，Ｄ）のユーザＩＤと、各関連ユーザが設定した制限情報とを図４（Ｂ）に示す関連ユーザ管理ＤＢに記憶するようにしてもよい。これに対して、決済時承認の場合には、要求処理部３１７が、送金依頼情報に対する承認情報を受信した際に関連ユーザの承認の有無を、図４（Ｂ）に示す関連ユーザ管理ＤＢに記憶すればよい。

また、要求処理部３１７は、ユーザＡが利用する端末１２０Ａから電子決済処理に関する決済情報を受信している場合、この電子決済処理を送金処理部３１８に依頼する。このとき、要求処理部３１７は、決済情報に含まれる電子バリュー値を、ユーザが求める電子バリュー値とみなしてもよい。次に、要求処理部３１７は、この電子バリュー値と、関連ユーザの数（例えばユーザＢ，Ｃ，Ｄの三人）とを送金処理部３１８に出力する。なお、電子バリュー値は、決済額とユーザＡのアカウントの残高との差額であってもよい。

また、要求処理部３１７は、端末１２０Ａから要求元のユーザＡの電子バリュー情報と送金リクエストとを受けた場合、ユーザＡのユーザＩＤ、電子バリュー情報（例えば決済金額）を取得する。また、要求処理部３１７は、送金リクエストに他のリクエスト（支払期限設定リクエスト等）が含まれている場合は、他のリクエストを取得する。このとき、要求処理部３１７は、送金リクエストごとに送金ＩＤを付与して、決済金額に係る電子バリュー、支払期限及び送金情報を図４（Ｃ）に示す送金管理ＤＢに記憶するようにしてもよい。ここで、送金情報は、例えば、要求先ユーザのユーザＩＤと、各要求先ユーザが送金元ユーザに送金した送金金額とを含む。

また、要求処理部３１７は、関連付けリクエストによる関連付け以外にも、他の方法でユーザＡに他のユーザを関連付けてもよい。例えば、要求処理部３１７は、送金リクエストの受信後、サーバ１１０により抽出された他のユーザをユーザＡに関連付けてもよい。ここで、この関連付け処理は、様々な方法を用いて行われることが可能であり、この関連付け処理の詳細について後述する。

また、要求処理部３１７は、ユーザＡに対し、各関連ユーザから送金された電子バリューの返済を求める返済要求を生成してもよい。返済を求めるか否かは、関連ユーザにより設定されてもよい。また、要求処理部３１７は、送金処理部３１８によって決定された電子バリューの値と、制限情報に含まれる電子バリューの上限値（「閾値」とも称す）とを比較し、決定された電子バリューの値が閾値以上の場合において、ユーザＡに返済を求める返済要求を生成してもよい。

送金処理部３１８は、要求処理部３１７によって取得されたユーザＡに関連付けられた関連ユーザのうち上述の所定の条件を満たす関連ユーザに対応付けられた制限情報と、電子バリュー情報（例えば電子決済における決済額）とを用いて、各関連ユーザに要求する電子バリューの値を決定する。送金処理部３１８は、関連ユーザそれぞれのアカウントの残高から、決定された電子バリューの値を減算し、ユーザＡのアカウントの残高にこの電子バリューの値を加算する送金処理を実行する。

また、送金処理部３１８は、要求処理部３１７から受信した電子バリュー値と、関連ユーザの数とに基づいて、各関連ユーザに対応付ける電子バリューの値を決定してもよい。ここで、例えば、送金処理部３１８は、差額を関連ユーザの数に等分して、各関連ユーザに対応付ける電子バリューの値を決定してもよく、その他の分配方法に基づいて差額を各関連ユーザに分けてもよい。そして、送金処理部３１８は、送金処理の終了後、依頼された電子決済の決済処理を実行する。ここで、その他の分配方法は、どのようなものであってもよく、例えば、支払期限が短い場合に、送金処理部３１８は、送金依頼情報への承認が不要な関連ユーザに差額を送金してもらうようリクエストしてもよい。例えば、送金処理部３１８は、上述の優先度が高く設定された関連ユーザに差額を等分してもよい。また、ユーザＡが送金リクエストを送信する際に、送金してほしい関連ユーザを指定した場合に、送金処理部３１８は、ユーザＡが指定した関連ユーザに差額を等分してもよい。また、差額の分け方は、必ずしも関連ユーザの数に等分する必要がなく、例えば、ユーザＡが送金リクエストにて各関連ユーザの送金金額を指定した場合に、送金処理部３１８は、ユーザＡの指定に基づいて差額を分割して関連ユーザに分けてもよい。

また、送金処理部３１８は、決定された電子バリューの値を調整してもよい。送金処理部３１８は、電子バリューの値の調整について、関連ユーザのアカウントの残高、関連ユーザの制限情報等に基づいて行ってもよい。また、決定された各関連ユーザの電子バリューの合計値が電子決済における決済額が示す値に満たない場合、送金処理部３１８は、決済事業者のアカウントから不足分をユーザＡのアカウントの残高に加算してもよい。ここで、関連ユーザのアカウントの残高からの電子バリューの合計値が不足する場合に、送金処理部３１８は、決済事業者のアカウントから不足分を補充する処理として説明したが、これらの処理は逆であってもよい。すなわち、送金処理部３１８は、決済事業者のアカウントから予め定められた電子バリューをユーザＡのアカウントの残高に加算し、この予め定められた電子バリューが電子決済における決済額が示す値に満たない場合、送金処理部３１８は関連ユーザのアカウントの残高から不足分を補充してもよい。

また、送金処理部３１８は、ユーザＡから電子バリューの値が返済された後、関連ユーザそれぞれのアカウントの残高に、各ユーザが送金した電子バリューの値を加算して返済してもよい。

これにより、ユーザが、他のユーザから電子バリューを容易に受け取れることが可能になる。また、送金要求元のユーザのみならず、要求先のユーザの手続きも便利になり、送金処理及び決済処理を迅速かつ円滑に行うことができる。より詳細に説明すると、サーバ１１０の要求処理部３１７が実行する関連付け処理により、ＱＲコード等を取得するだけでユーザ同士の関連付けが可能となり、ユーザ同士を関連付けるために共通の口座を開き、関連付けのための入力及び設定等の煩雑な手続が必要なくなる。このように、ユーザ同士の関連付けは簡易な手続きによって実現することができ、ユーザの利便性の向上を図ることができる。また、サーバ１１０の送金処理部３１８が実行する電子バリューの値の決定処理により、要求元のユーザが要求先の関連ユーザごとの送金金額を決定することや、要求先の関連ユーザが送金金額の入力に係る操作を行う必要がなくなり、ユーザの利便性を向上することができる。

（２）端末の機能構成
端末１２０は、入出力Ｉ／Ｆ３２１と、通信Ｉ／Ｆ３２２と、制御部３２３と、記憶部３２４と、表示制御部３２５と、通信部３２６と、第１処理部３２７と、第２処理部３２８とを有する。なお、各機能部の機能または処理は、実現可能な範囲において、機械学習またはＡＩ（Artificial Intelligence）により実現されてもよい。また、図３に開示の端末１２０の各機能部は、情報処理装置２００が備えるプロセッサ２０１と、メモリ２０２と、ストレージ２０３と、入出力Ｉ／Ｆ２０４と、通信Ｉ／Ｆ２０５との協働により実現される。

入出力Ｉ／Ｆ３２１は、例えば、入出力Ｉ／Ｆ２０４を用いて実現されうる。また、通信Ｉ／Ｆ３２２は、例えば、通信Ｉ／Ｆ２０５を用いて実現されうる。制御部３２３は、プロセッサ２０１が、記憶部３２４に格納されているプログラムを読み出して実行することで実現されうる。記憶部３２４は、メモリ２０２及び／又はストレージ２０３を用いて実現されうる。

入出力Ｉ／Ｆ３２１は、所定の画面を表示し、また、端末１２０の画面に表示されたボタンや、端末１２０のタッチパネルなどを用いてユーザ操作を受け付けて、ユーザ操作の位置や操作時間などを制御部３２３に出力する。

通信Ｉ／Ｆ３２２は、サーバ１１０や他の端末１２０に、ユーザＩＤなどの所定のデータを送受信する。

記憶部３２４は、本実施形態に係る端末１２０が実行するプログラムを含む。

制御部３２３内の表示制御部３２５は、電子決済に関するサービスにおいて表示される表示画面などを表示装置（入出力Ｉ／Ｆ３２１）に表示制御する機能を有する。例えば、表示制御部３２５は、サーバ１１０から電子決済に関する所定画面（送金リクエスト画面、送金承認画面、送金完了通知画面など）の表示要求を受けた場合には、この所定画面を表す画面情報を入出力Ｉ／Ｆ３２１に出力するようにする。

通信部３２６は、通信Ｉ／Ｆ３２２を用いて、データの送受信を制御する機能を有する。例えば、通信部３２６は、他のサーバ１１０や他の端末１２０にデータを送信する送信部としての機能と、他のサーバ１１０や他の端末１２０からデータを受信する受信部としての機能とを有する。以下、端末１２０が送金の要求元の端末である場合と、要求先の端末である場合とに分けて説明する。

（端末１２０が要求元の端末である場合）
端末１２０Ａの通信部３２６の送信部は、要求元のユーザＡの操作に応答して、関連付けリクエストをサーバ１１０に送信する。このとき、関連付けリクエストは、ユーザＡのアカウント情報（例えばユーザＩＤ等）を含む。また、端末１２０Ａの通信部３１６の受信部は、サーバ１１０が生成したペアリング行われる情報（例えばＱＲコード）を受信する。そして、端末１２０Ａの通信部３２６の送信部は、受信したＱＲコードを関連ユーザが利用する関連端末（例えば端末Ｂ〜Ｄ）に送信してもよい。

また、端末１２０Ａの通信部３２６の受信部は、サーバ１１０からの関連付けに関する承認問い合わせを受信する。この問い合わせは、関連付けの可否を確認するために行われる。端末１２０Ａの通信部３２６の送信部は、承認問い合わせに対する承認通知をサーバ１１０に送信する。

また、端末１２０Ａの通信部３２６の送信部は、ユーザＡの操作に応答して、電子バリュー情報と送金リクエストとをサーバ１１０に送信する。また、端末１２０Ａの通信部３２６の送信部は、ユーザＡのアカウントの残高の不足情報に基づいて、電子バリュー情報と送金リクエストとをサーバ１１０に自動的に送信してもよい。この送金リクエストは、ユーザＡのアカウント情報（例えばユーザＩＤ、残高等）を含んでもよい。また、端末１２０Ａの通信部３２６の受信部は、サーバ１１０からの送金完了通知を受信する。なお、端末１２０Ａの通信部３２６の受信部は、サーバ１１０からの送金完了通知とともに、返済要求通知を受信してもよい。

（端末１２０が要求先の端末である場合）
図３において端末１２０Ａの機能を説明しているが、ここでは、要求先であるユーザが利用する端末の機能を説明するため、端末１２０Ａを端末１２０Ｂに置き換えて説明する。端末１２０Ｂの通信部３２６の送信部は、読み取ったＱＲコード（ペアリング情報）に含まれる関連付け情報、ユーザ識別情報（ユーザＢのユーザＩＤ）及びユーザＢが設定した制限情報に基づくユーザＡとの関連付けリクエストを、サーバ１１０に送信する。また、端末１２０Ｂの通信部３２６の受信部は、サーバ１１０から、送金に対する事前承認の問い合わせを受信する。そして、端末１２０Ｂの通信部３２６の送信部は、事前承認の問い合わせの受信に応答して、承認するか否かを示す承認の結果通知をサーバ１１０に送信する。

また、端末１２０Ｂの通信部３２６の受信部は、送金に対して決済時承認が行われる場合、サーバ１１０からの送金依頼情報を受信する。次に、端末１２０Ｂの通信部３２６の送信部は、送金依頼情報の受信に応答して、送金依頼情報に対する承認通知をサーバ１１０に送信してもよい。

また、端末１２０Ｂの通信部３２６の受信部は、サーバ１１０から、決定された電子バリューの値が減算されたことを通知するための送金金額通知を受信する。

次に、第１処理部３２７は、電子バリューを送金するための処理部である。第２処理部３２８は、送金に関する承認情報及び制限情報等の送金条件を設定するための処理部である。また、実施形態では、第１処理部３２７は、端末１２０が要求元の端末である場合に、電子バリューの要求元のユーザが電子バリューの送金を求める際に用いられる。第２処理部３２８は、端末１２０が要求先の端末である場合に、電子バリューの要求先のユーザが電子バリューを送金する際に用いられる。

（第１処理部）
第１処理部３２７は、第１要求部４０２と、第２要求部４０４とを有し、第１要求部４０２は関連付けをリクエストするための要求部としての機能を有し、第２要求部４０４は送金をリクエストするための要求部としての機能を有する。

第１要求部４０２は、ユーザの操作に応答して、他のユーザと関連付けるリクエストを、通信部３２６を介してサーバ１１０に送信する。また、第２要求部４０４は、ユーザの操作に応答して、要求する電子バリューの値を決定する。ユーザの操作とは、端末１２０の表示画面に表示された、送金要求画面（図７参照）に表示される要求金額入力欄や、支払期限の項目などを用いて、ユーザが電子バリュー情報を決定するための操作を示す。なお、第２要求部４０４は、ユーザＡのアカウントの残高の不足情報に基づいて、要求する電子バリューの値を自動的に決定してもよい。具体的には、第２要求部４０４は、決済額とユーザＡのアカウントの残高との差額を、要求する電子バリューの値として決定してもよい。

（第２処理部）
第２処理部３２８は、設定部５０２を有し、送金条件設定部としての機能を有する。
設定部５０２は、要求先の関連ユーザの操作に応答して、送金処理に関する所定の条件を設定する。例えば、所定の条件は、所定期間内の送金に対する上限値、所定期間内の送金回数に対する上限値、又は返済を求める条件（返済を求める否か、返済を求めるための金額の閾値、返済期間など）などである。ここで、関連ユーザの操作とは、端末１２０の表示画面に表示された画面（図８参照）に表示される返済要求入力欄や、送金に対して承認のＹＥＳ及びＮＯボタンなどを用いて、送金情報を確認、承認するための操作を含んでもよい。

＜実施形態の動作処理＞
（事前承認の場合）
図５を参照し、実施形態に係る、送金処理において事前承認を受ける通信システム１の処理について説明する。図５は、実施形態に係る通信システム１の処理のシーケンス（事前承認パターン）の一例を示す。なお、以下の説明では、関連ユーザは、ユーザＢ、ユーザＣ及びユーザＤとする。

ステップＳ１０２で、端末１２０Ａの通信部（送信部）３２６は、第１要求部４０２により生成された関連付けリクエストをサーバ１１０に送信する。

ステップＳ１０４で、サーバ１１０の通信部（受信部）３１６は、関連付けリクエストを受信し、要求処理部３１７は、ユーザ同士を関連付けるためのペアリング情報（例えばＱＲコード）を生成する。

ステップＳ１０６で、サーバ１１０の通信部（送信部）３１６は、要求処理部３１７により生成されたＱＲコードを端末１２０Ａに送信する。

ステップＳ１０８で、ユーザＢが利用する端末１２０Ｂの通信部（受信部）３２６は、端末１２０ＡからのＱＲコードに含まれる関連付けのための情報（例えばユーザＡのユーザＩＤ）を取得する。ここで、ＱＲコードの取得方法は、例えば、ユーザＢの操作に応答して、端末１２０Ｂのコードリーダー部が、直接端末１２０Ａの画面に表示されるＱＲコードをスキャンして読み取ってもよい。また、端末１２０Ｂは、端末１２０Ａから送信されるＱＲコードを受信してもよい。

ステップＳ１１０で、端末１２０Ｂの通信部（送信部）３２６は、取得したＱＲコードに含まれる情報、ユーザ識別情報（ユーザＢのユーザＩＤ）及びユーザＢが設定した制限情報に基づくユーザＡとの関連付けリクエストを、サーバ１１０に送信する。

ステップＳ１１２で、サーバ１１０の通信部（受信部）３１６は、端末１２０Ｂから、ユーザＡとの関連付けリクエストを受信し、要求処理部３１７は、ユーザＡのユーザＩＤとユーザＢのユーザＩＤとの関連付け設定に関する承認問い合わせを生成し、サーバ１１０の通信部（送信部）３１６は、生成された承認問い合わせを端末１２０Ａに送信する。

ステップＳ１１４で、ユーザＡが承認問い合わせを承認する操作に応答して、端末１２０Ａの通信部（送信部）３２６は、承認通知をサーバ１１０に送信する。

ステップＳ１１６で、サーバ１１０の通信部（受信部）３１６は、端末１２０Ａからの承認通知を受信し、要求処理部３１７は、ユーザＡのユーザＩＤとユーザＢのユーザＩＤとを関連付ける。

ステップＳ１１８で、端末１２０Ａの通信部（送信部）３２６は、ユーザＡのユーザＩＤとユーザＢのユーザＩＤとが関連付けられた場合、ユーザＡの操作に応答して、送金処理に対する事前承認の問い合わせをサーバ１１０に要求する。端末１２０Ａの第１処理部３２７の第１要求部４０２により生成された、ユーザＡへの送金に対して承認を与えるユーザＢを関連付けるための事前承認の関連付けリクエストをサーバ１１０に送信する。

ステップＳ１２０で、サーバ１１０の通信部（受信部）３１６は、事前承認の問い合わせリクエストを受信し、サーバ１１０の要求処理部３１７は、事前承認に関する問い合わせを生成し、サーバ１１０の通信部（送信部）３１６は、生成された事前承認に関する問い合わせを端末１２０Ｂに送信する。

ステップＳ１２２で、端末１２０Ｂの通信部（受信部）３２６は、事前承認に関する問い合わせを受信し、設定部５０２は、ユーザＢの操作に応答して事前承認の設定を行い、端末１２０Ｂの通信部（送信部）３２６は、承認通知をサーバ１１０に送信する。

ステップＳ１２４で、サーバ１１０の通信部（受信部）３１６は、端末１２０Ｂからの承認通知を受信し、要求処理部３１７は、ユーザＡへの送金に対して事前承認を与えたユーザＢを関連付ける。

ここで、ユーザＡのユーザＩＤとユーザＣのユーザＩＤとの関連付け及び事前承認の関連付け設定に係るステップＳ１２６〜Ｓ１４２までの処理、及びユーザＡのユーザＩＤとユーザＤのユーザＩＤとの関連付け及び事前承認の関連付け設定に係るステップＳ１４４〜Ｓ１６０までの処理は、上述したステップＳ１０８〜Ｓ１２４までの処理と同様であるため、それらの説明を省略する。ステップＳ１０８〜Ｓ１６０までの処理によって、ユーザＡのユーザＩＤは、ユーザＢのユーザＩＤ、ユーザＣのユーザＩＤ及びユーザＤのユーザＩＤそれぞれに関連付けられる。すなわち、ユーザＢ〜Ｄは、ユーザＡの関連ユーザとなる。

ステップＳ１６２で、端末１２０Ａの通信部（送信部）３２６は、第２要求部４０４により生成された電子バリュー情報と送金リクエストとをサーバ１１０に送信する。ここで、送金リクエストは、ユーザＡの操作によってユーザＡに対応付けられた関連ユーザの中から選択された所定の関連ユーザに係る情報等をさらに含めてもよい。

ステップＳ１６４で、サーバ１１０の通信部（受信部）３１６は、送金リクエストを受信し、サーバ１１０の要求処理部３１７は、関連ユーザから所定の条件を満たす関連ユーザの数（例えば、ユーザＢ〜Ｄの三人）と電子バリュー値とを取得し、サーバ１１０の送金処理部３１８は、関連ユーザの数及び電子バリュー値に基づいて、ユーザＢ〜Ｄの送金が必要となる電子バリューの値を決定する。次に、送金処理部３１８は、ユーザＢ〜Ｄそれぞれのアカウントの残高から決定された電子バリューの値を減算し、ユーザＡのアカウントの残高に電子バリューの値を加算する送金処理を実行する。ここで、利用可能な関連ユーザの数を取得するために、サーバ１１０の要求処理部３１７は、各関連ユーザのアカウントの残高、制限情報等を取得する。そして、要求処理部３１７は、取得した関連ユーザのアカウントの残高と、決定された電子バリューの値とを比較して利用可能（送金可能）な関連ユーザの数等の情報を取得する。また、決定された電子バリューの値は、送金処理部３１８が取得された電子決済における決済額を、ユーザＡに関連付けられる関連ユーザの数に等分して得られる値である。しかし、関連ユーザごとに、送金処理部３１８が所定条件に基づいて異なる電子バリューの値を決定してもよい。

ステップＳ１６６〜Ｓ１７０で、サーバ１１０の通信部（送信部）３１６は、送信処理の終了後、ユーザＢ〜Ｄが利用する各端末１２０（端末１２０Ｂ〜Ｄ）に、決定された電子バリューの値が減算されたことを通知するための送金金額通知を送信する。

ステップＳ１７２で、サーバ１１０の通信部（送信部）３１６は、送金完了通知を端末１２０Ａに送信する。なお、サーバ１１０の通信部（送信部）３１６は、要求処理部３１７により生成された返済要求を関連ユーザの端末１２０Ｂに送信してもよい。

以上のステップＳ１０２〜Ｓ１７２までの処理により、ユーザが、他のユーザから電子バリューを容易に受け取る簡便な仕組みを提供することが可能になる。例えば、ステップＳ１０２〜Ｓ１１６までの関連付け処理により、ＱＲコード等を取得するだけでユーザ同士の関連付けが可能となり、ユーザ同士を関連付けるために共通の口座（例えばファミリー口座等）を開き、関連付けのための入力及び設定等の煩雑な手続が必要なくなる。よって、ユーザ同士の関連付けは簡易な手続きによって実現することができ、ユーザの利便性の向上を図ることができる。また、ステップＳ１１８〜Ｓ１２４までの事前承認の設定処理により、送金処理が行われる前に要求先の関連ユーザからの事前承認を得たため、送金処理が行われる度に、関連ユーザごとに送金に対する承認を得る必要がなくなり、送金処理に係る時間を大幅に短縮することができよって、決済処理の迅速化を図ることができる。さらに、ステップＳ１６４に係る電子バリューの値の決定処理により、要求元のユーザが要求先の関連ユーザごとに送金金額を決定することや、要求先の関連ユーザが送金金額の入力に係る操作を行う必要がなくなり、ユーザの利便性を向上させることができる。

（決済時承認の場合）
続いて、図６を参照し、実施形態に係る、送金処理において決済時承認を受ける通信システム１の処理について説明する。図６は、実施形態に係る通信システム１の処理のシーケンス（決済時承認パターン）の一例を示す。なお、図６に示すステップＳ２０２〜Ｓ２１６までの処理は、図５に示すステップＳ１０２〜Ｓ１１６までの処理と同様であり、図６に示すステップＳ２１８〜Ｓ２２６と、ステップＳ２２８〜Ｓ２３６とまでの処理は、図５に示すステップＳ１０８〜Ｓ１１６までの処理と同様であるため、それらの処理の説明を省略する。また、図５に示す処理と同様の処理について説明を簡略する。

ステップＳ２３８で、端末１２０Ａの通信部（送信部）３２６は第２要求部４０４により生成された電子バリュー情報と送金リクエストとをサーバ１１０に送信する。

ステップＳ２４０で、サーバ１１０の通信部（受信部）３１６は、電子バリュー情報と送金リクエストを受信し、要求処理部３１７は、関連ユーザから所定の条件を満たす関連ユーザの数（例えば、ユーザＢ〜Ｄの三人）を取得し、送金処理部３１８は、関連ユーザの数及びユーザが電子バリュー（例えば電子決済における決済額）を用いて、ユーザＢ〜Ｄから送金され得る電子バリューの値を決定する。

ステップＳ２４２で、サーバ１１０の通信部（送信部）３１６は、関連ユーザであるユーザＢが利用する端末１２０Ｂに、送金依頼情報を送信する。ここで、送金依頼情報は、送金要求、要求金額、送金に対する承認情報等を含んでもよい。

ステップＳ２４４で、端末１２０Ｂの通信部（受信部）３２６は、送金依頼情報を受信し、ユーザＢの操作に応答して、設定部５０２は、送金に依頼情報対する承認情報を設定し、端末１２０Ｂの通信部（送信部）３２６は、設定された承認情報をサーバ１１０に送信する。ここで、承認情報は送金依頼情報に対する承認または否認の情報を含む。

サーバ１１０によるユーザＣの承認情報を取得する処理に係るステップＳ２４６及びＳ２４８と、サーバ１１０によるユーザＤの承認情報を取得する処理に係るＳ２５０及びＳ２５２との処理は、サーバ１１０によるユーザＢの承認情報を取得する処理に係るステップＳ２４２及びＳ２４４と同じであるため、それらの処理の説明を省略する。

ステップＳ２５４で、サーバ１１０の要求処理部３１７は、サーバ１１０の通信部（受信部）３１６は、全ての関連ユーザからの承認情報の受信を完了するまで、送金処理を行わず、待ち状態となる。なお、サーバ１１０の要求処理部３１７は、所定期間が経過するまで関連ユーザからの承認情報の受信を受け付けてもよく、所定期間内に承認情報を受信しなかった関連ユーザの承認情報を否認情報とみなしてもよい。

ステップＳ２５６で、サーバ１１０の要求処理部３１７は、サーバ１１０の通信部（受信部）３１６は全ての関連ユーザからの承認情報を受信した後、決済処理部３１８に送金処理を指示し、送金処理部３１８は、ユーザが求めた電子バリュー情報が示す値を関連ユーザの数で除算し、各関連ユーザの送金対象の電子バリューの値を決定する。また、送金処理部３１８は、ユーザが求める電子バリュー情報が、電子決済処理における決済額であれば、送金処理の終了後、決済処理を実行してもよい。また、送金処理部３１８は、送金対象の電子バリューの値を調整することにより、各関連ユーザの送金対象の電子バリューの合計値が、ユーザが求める電子バリュー情報が示す値に満たない場合、この不足分に対して、サーバ１１０を管理する決済事業者のアカウントから、ユーザＡのアカウントの残高に不足分を加算してもよい。なお、以下では、この不足分を加算する処理を「補充処理」と呼ぶことがある。

ステップＳ２５８で、サーバ１１０の要求処理部３１７は、送金完了通知（決済完了通知）及び返済要求通知を生成し、サーバ１１０の通信部（送信部）３１６は、送金完了通知及び返済要求通知を端末１２０Ａに送信する。ここで、返済要求通知は、返済が必要となる返済金額情報を含む。この返済金額は、送金管理ＤＢに格納されている各関連ユーザの送金金額であってもよい。なお、サーバ１１０の要求処理部３１７は、電子バリューの値が閾値以上である場合に、返済を求める要求を生成してもよい。

ステップＳ２６０、Ｓ２６２及びＳ２６４で、サーバ１１０の送金処理部３１８は、ユーザＡから電子バリューの値の返済後に、関連ユーザＢ〜Ｄそれぞれのアカウントの残高に、送金された電子バリューの値を加算して返済する。なお、返済が完了した場合において、サーバ１１０の通信部（送信部）３１６は、関連ユーザＢ〜Ｄが利用する端末１２０Ｂ〜Ｄ及び／又は端末１２０Ａに、返済完了通知を送信してもよい。

以上のステップＳ２０２〜Ｓ２６４までの処理により、図５に示す処理とは異なり、ステップＳ２４２、Ｓ２４４に係る決済時承認の設定処理により、要求先の関連ユーザが決済処理の際に送金依頼情報に応答して送金に係る制限条件を設定することができる。また、ステップＳ２５６に係る決定された関連ユーザの送金不足分の補充処理により、確実に要求元のユーザのアカウントに必要な電子バリューの値を加算することができ、要求元のユーザが不足分について他の手続きを行う必要がない。これにより、ユーザの利便性を向上させることができるとともに、送金処理及び決済処理の円滑性かつ迅速性を向上することができる。

＜実施形態の関連付け処理＞
実施形態の関連付け処理は、要求元ユーザと要求先ユーザとを関連付けることができる処理であれば、どのような処理であってもよい。例えば、関連付け処理では、サーバ１１０が、要求元ユーザのユーザＩＤと、要求先ユーザのユーザＩＤとを関連付けることができればよい。また、関連付け処理が行われるタイミングは、送金処理や決済処理の前であってもよく、決済処理の際に要求先ユーザの残高が不足しているときであってもよい。ここで、説明の便宜のために、送金処理や決済処理の前に行われる関連付け処理を「事前関連付け処理」と呼び、決済処理の際に行われる関連付け処理を「決済時関連付け処理」と呼ぶ。以下では、関連付け処理の一例である、ＱＲコード（登録商標）を用いる関連付け処理について、事前関連付け処理と、決済時関連付け処理とに場合分けして詳細に説明する。

（事前関連付け処理の場合）
まず、ＱＲコードを使用する事前関連付け処理について説明する。
要求処理部３１７は、決済処理の前に、すなわち図５に示すステップＳ１６２又は図６に示すステップＳ２３８の前に、端末１２０Ａからユーザの関連付けリクエストを受けた場合（図５に示すステップＳ１０２又は図６に示すステップＳ２０２）、ユーザ同士を関連付けるためのペアリング用のＱＲコードを生成する。次に、要求処理部３１７は、ＱＲコードを読み取った要求先のユーザ（例えばユーザＢ）が利用する端末１２０Ｂから、ＱＲコードに含まれるペアリング情報とユーザＢのユーザＩＤとを受けた場合、要求元のユーザＡのユーザＩＤと、要求先のユーザＢのユーザＩＤとを関連付ける。ＱＲコードを読み取った要求先のユーザが複数、例えば、ユーザＢのほか、ユーザＣ及びユーザＤがいる場合、要求処理部３１７は、上述した関連付け方法と同様の方法で、ユーザＡのユーザＩＤとユーザＣのユーザＩＤとを関連付け、ユーザＡのユーザＩＤとユーザＤのユーザＩＤとを関連付ける。これにより、ユーザＡのユーザＩＤと、ユーザＢ，Ｃ，ＤのそれぞれのユーザＩＤとが関連付けられる。すなわち、ユーザＢ，Ｃ，Ｄは、ユーザＡの関連ユーザとなる。

また、求処理部３１７は、決済処理の前に、すなわち図５に示すステップＳ１６２又は図６に示すステップＳ２３８の前に、端末１２０Ａからユーザの関連付けリクエストを受けた場合（図示せず）、所定の方法によって、ユーザＡに関連付けるための他のユーザを抽出する。次に、要求処理部３１７は、抽出された他のユーザ（例えばユーザＢ，Ｃ，Ｄ）のユーザＩＤをユーザＡのユーザＩＤに関連付ける。これにより、ユーザＢ，Ｃ，Ｄは、ユーザＡの関連ユーザとなる。

（決済時関連付け処理の場合）
続いて、決済時関連付け処理について説明する。
要求処理部３１７は、決済処理の際に、すなわち図５に示すステップＳ１６２又は図６に示すステップＳ２３８と同時に又は後に、端末１２０Ａからユーザの関連付けリクエストを受けた場合（図示せず）、所定の方法によって、ユーザＡに関連付けるための他のユーザを抽出する。次に、要求処理部３１７は、抽出された他のユーザ（例えばユーザＢ，Ｃ，Ｄ）のユーザＩＤをユーザＡのユーザＩＤに関連付ける。これにより、ユーザＢ，Ｃ，Ｄは、ユーザＡの関連ユーザとなる。

つまり、この決済時関連付け処理の場合では、サーバ１１０が、ユーザＡの送金リクエストを受信した後に、所定の方法によって抽出された他のユーザをユーザＡに関連付ける。この場合に係る送金リクエストは、上述した事前関連付け処理の場合の例とは異なる送金リクエストとしてサーバ１１０が認識可能にしておくとよい。また、事前関連付け処理の場合と異なり、決済時関連付け処理の場合に係る関連ユーザは、サーバ１１０によって選定された者である。すなわち、ユーザＡは、送金リクエストを送信する前に、ユーザを事前に関連付けておく処理をしなくてもよい。これにより、ユーザＡの利便性が向上される。

ここで、他のユーザを抽出するための所定の方法は、様々な方法を採用することが可能である。例えば、要求処理部３１７は、位置情報に基づいて、ユーザＡの位置情報を取得して、このユーザＡの位置に基づいて、ユーザＡの位置から所定距離以内にいる他のユーザを抽出して、他のユーザのユーザ情報（例えばユーザＩＤ、残高等）を取得する。そして、要求処理部３１７は、ユーザＡのユーザＩＤと他のユーザのユーザＩＤと関連付けてもよい。また、要求処理部３１７は、ランダムな抽出方法により、任意の他のユーザを抽出して、ユーザＡのユーザＩＤと他のユーザのユーザＩＤと関連付けてもよい。

＜実施形態の表示態様＞
次に、図７から１１を用いて、端末１２０の表示画面に表示されるユーザインターフェース（ＵＩ）について説明する。図７及び図９は、要求元のユーザＡの端末１２０Ａに表示される画面であり、図８は、要求先のユーザＢ〜Ｄ（関連ユーザ）の端末１２０Ｂ〜Ｄに表示される画面である。

図７は、実施形態に係る送金要求画面の一例を示す。端末１２０Ａの表示制御部３２５は、図５に示すステップＳ１６２または図６に示すステップＳ２３８において、要求元のユーザＡが利用する端末１１０Ａからの送金リクエストの操作に応答して、図７に示す画面を表示制御する。

図７に示す送金要求画面の例では、関連ユーザに送金を求める要求金額の入力欄と、この要求金額の支払期限を設定するための「あり」ボタン及び「なし」ボタンと、入力を完了する「終了」ボタンとを含む。

図７に示す例では、ユーザＡが要求金額の入力欄に金額（例えば１０００円）を入力した後に、支払期限を設定するための「あり」ボタンを押すと、支払期限の入力欄（図示せず）を含む画面に遷移する。ユーザＡが支払期限の入力欄に支払期限（例えば２０１８年１２月１０日１３時から３分以内）を入力した後に「終了」ボタンを押すと、ステップＳ１６２またはステップＳ２３８の処理が実行される。他方、ユーザＡが入力欄に金額を入力した後に、支払期限を設定しない場合「なし」ボタンを押すと、画面は遷移しない。この場合、ユーザＡが引き続き「終了」ボタンを押すと、ステップＳ１６２またはステップＳ２３８の処理が実行される。また、金額の入力欄には、電子決済処理における決済額が自動で入力されるようにしてもよい。

図８は、実施形態に係る送金承認画面の一例を示す。また、この送金承認画面は、決済時承認における処理（図６に係る処理）の場合に、要求先のユーザＢ〜Ｄ（関連ユーザ）の端末１２０Ｂ〜Ｄに表示される。要求先のユーザＢ〜Ｄの端末１２０Ｂ〜Ｄの表示制御部３２５は、図６に示すステップＳ２４４、Ｓ２４８及びＳ２５２において、図８に示す画面を表示制御し、ユーザからの送金承認操作を受け付ける。

図８に示す送金承認画面では、ステップＳ２４０でサーバ１１０の送金処理部３１８によって決定される関連ユーザごとの送金金額の表示と、この送金金額を要求元のユーザに返済させるための返済要求に係る「あり」ボタン及び「なし」ボタンと、承認操作を完了する「ＹＥＳ」ボタン及び「ＮＯ」ボタンとを含む。

図８に示す例では、各関連ユーザが、画面に表示される送金金額（例えば２００円）を確認し、この金額について要求元のユーザ（ユーザＡ）に返済を求める場合、要求元のユーザＡに返済させるための返済要求に係る「あり」ボタンを押すと、返済期限の入力欄（図示せず）を含む画面に遷移してもよい。関連ユーザが入力欄に支払期限（例えば２０１８年１２月２０日１３時から３日内）を入力した後に、送金金額を承認する「ＹＥＳ」ボタンを押すと、ステップＳ２４４、Ｓ２４８またはＳ２５２の処理が実行される。他方、ユーザＡが表示された送金金額を確認した後に、この金額について要求元のユーザ（ユーザＡ）に返済を求めない場合、返済要求に係る「なし」ボタンを押すと、画面は遷移しない。この場合、ユーザＡが引き続き送金金額を承認する「ＹＥＳ」ボタンを押すと、ステップＳ２４４、Ｓ２４８またはＳ２５２の処理が実行される。なお、ユーザＡが送金金額を承認しない場合、承認を拒否する「ＮＯ」ボタンを押すと、ステップＳ２４４、Ｓ２４８またはＳ２５２の処理が実行されず、送金処理が取り消される。

図９は、実施形態に係る送金完了通知の画面の一例を示す。また、この送金完了通知の画面は、事前承認における処理（図５に係る処理）の場合に、要求先のユーザＢ〜Ｄ（関連ユーザ）の端末１２０Ｂ〜Ｄに表示される。端末１２０Ａの表示制御部３２５は、図５に示すステップＳ１７２において、サーバ１１０の送金処理が完了した後で、図９に示す画面を表示制御する。

図９に示す送金完了通知の画面の例では、送金完了に係るメッセージ（例えば「１０００円の送金がありました！」）と、要求先から返済要求の有無を示す「あり」及び「なし」項目と、画面を閉じるための「終了」ボタンとを含む。ユーザＡが「終了」ボタンを押下することで、図９に示す送金完了通知画面が端末１２０Ａの表示画面から消える。

＜＜第１実施例＞＞
第１実施例は、要求元のユーザＡに関連付けられた関連ユーザが複数のグループで構成される場合において、サーバ１１０は、ユーザＡの選択操作に応答して選択された関連ユーザグループに対して送金処理を行う実施例である。

＜＜第１実施例の効果＞＞
第１実施例により、上述した実施形態と同様に、実施形態で上述した効果を有しつつ、送金処理の利用自由度を高めることができる。第１実施例ではユーザＡの関連ユーザは複数のグループに属しているものとして説明する。例えば、関連ユーザを、ユーザＡとの関係に基づいて「家族」、「友達」、「同僚」等のグループに分けてもよい。この場合において、ユーザＡは自分の都合や意思に沿って、決済額に基づく電子バリューを分け与えてもらいたい関連ユーザを選択することが可能となる。

＜＜第１実施例の機能構成＞＞
第１実施例に係るシステム構成、各サーバ及び各端末のハードウェア構成、並びに、各サーバ及び各端末の機能構成は、上述した実施形態と同様である。また、第１実施例では、実施形態と共通の機能、処理等についての記述を省略し、異なる点、すなわち、第１実施例では、図５に示すステップＳ１１４及びステップＳ１１６、または図６に示すステップＳ２１４及びステップＳ２１６で行われる関連ユーザグループの選択処理と、図５に示すステップＳ１６２または図６に示すステップＳ２３８で行われる選択された関連ユーザグループに対して送金を求める処理とを中心に説明する。

なお、ここで、例えば、ユーザＢはユーザＡの父であり、ユーザＣはユーザＡの母であり、ユーザＤはユーザＡの兄である。以下の説明では、関連ユーザグループのユーザＢを例として説明するが、ユーザＣ及びユーザＤに係る処理は、ユーザＢに係る処理と同じであるため、説明を省略する。なお、後述する第２〜第４実施例も同様とする。

＜＜第１実施例の動作処理＞＞
第１実施例は、図５に示すステップＳ１１４または図６に示すステップＳ２１４で、端末１１０Ａの通信部（送信部）３２６は、ユーザＡが関連付け設定に関する承認問い合わせを承認する場合に、ユーザＡの操作に応答して、関連ユーザグループの選択情報を含む承認通知をサーバ１１０に送信する。より詳細に例を挙げて説明すると、例えば、図５に示すステップＳ１１４または図６に示すステップＳ２１４で、端末１１０Ａの通信部（受信部）３２６は、サーバ１１０から、ユーザＢ（父）との関連付け設定の承認を求める問い合わせを受信する。そして、ユーザＡがユーザＢを「家族」グループに関連付ける選択指示に応答して、端末１１０Ａの第１要求部４０２は、関連付けリクエスト及び関連ユーザグループの選択情報を生成し、端末１１０Ａの通信部（送信部）３２６は、関連付けリクエスト及び関連ユーザグループの選択情報をサーバ１１０に送信する。

そして、図５に示すステップＳ１１６または図６に示すステップＳ２１６で、サーバ１１０の通信部（受信部）３１６は、関連付けリクエスト及び関連ユーザグループの選択情報を受信し、要求処理部３１７は、ユーザＢのユーザＩＤを家族グループの関連ユーザとしてユーザＡのユーザＩＤに関連付ける。

図５に示すステップＳ１６２または図６に示すステップＳ２３８で、端末１２０Ａの通信部（送信部）３２６は、端末１２０Ａの２要求部４０４により生成された電子バリュー情報と送金リクエストとをサーバ１１０に送信する。ここで、実施形態と異なり、送金リクエストは関連ユーザグループの選択情報も含む。例えば、ユーザＡが「家族」、「友達」、「同僚」から「家族」を選択する指示に応答して、端末１２０Ａの第２要求部４０４は、関連ユーザグループの選択情報を生成する。

そして、図５に示すステップＳ１６４または図６に示すステップＳ２４０で、サーバ１１０の通信部（受信部）３１６は、送金リクエストを受信し、サーバ１１０の要求処理部３１７は、選択された関連ユーザグループを抽出し、さらに抽出された関連ユーザグループから所定の条件を満たす関連ユーザの数（例えば、関連ユーザグループの全員）を取得する。次に、サーバ１１０の送金処理部３１８は、関連ユーザの数及びユーザが電子バリュー（例えば電子決済における決済額）を用いて、ユーザＢ〜Ｄの送金対象となる電子バリューの値を決定して、ユーザＢ〜Ｄそれぞれのアカウントの残高から決定された電子バリューの値を減算し、ユーザＡのアカウントの残高に電子バリューの値を加算する送金処理を実行する。

＜＜第２実施例＞＞
第２実施例は、ユーザＡが要求先の各関連ユーザに求める送金金額、又は各関連ユーザが要求される送金金額を調整する実施例である。

＜＜第２実施例の効果＞＞
第２実施例により、上述した実施形態と同様に、実施形態で上述した効果を有しつつ、ユーザ間の送金処理の自由度を高めることができる。第２実施例では、ユーザＡが要求先の各関連ユーザに求める送金金額を調整することができる。例えば、ユーザＡは、関連ユーザの収入情報に基づいて、各関連ユーザに求める送金金額を調整してもよい。この場合において、ユーザＡは、会社員であるユーザＢ（父）の送金金額を主婦であるユーザＣ（母）及び学生であるユーザＤ（兄）によりも高く設定してもよい。例えば、ユーザＡは、送金必要の金額に対して、ユーザＢ（父）の送金金額はこの送金必要の金額の６０％、ユーザＣ（母）の送金金額はこの送金必要の金額の２５％、ユーザＤ（兄）の送金金額はこの送金必要の金額の１５％に設定してもよい。これにより、要求金額を各関連ユーザが送金できる金額に近い金額に調整することができ、各関連ユーザを送金処理に協力させて、決済処理を円滑に行わせることが可能となる。また、各関連ユーザが、通知された送金金額を調整することを可能にしてもよい。例えば、ユーザＤ（兄）が、サーバ１１０により決定された送金金額を減らした場合に、減らされた額を、ユーザＢ（父）の送金金額に加算するようにしてもよい。これにより、関連ユーザが、自身の都合に応じて送金金額を調整することができるようになる。例えば、決済時承認における処理の場合、関連ユーザから送金に対する承認を得る可能性を高めることができ、送金処理の実行可能性を高めることができるという効果が得られる。

＜＜第２実施例の機能構成＞＞
第２実施例に係るシステム構成、各サーバのハードウェア構成、並びに、各サーバ及び各端末の機能構成は、上述した実施形態と同様である。また、第２実施例では、実施形態と共通の機能、処理等についての記述を省略し、異なる点、すなわち、第２実施例では、図５に示すステップＳ１６２または図６に示すステップＳ２３８で行われる関連ユーザの送金金額の調整リクエストに係る処理と、図５に示すステップＳ１６４または図６に示すステップＳ２４０で送金金額の調整リクエストに基づいて各関連ユーザの送金金額を決定する処理とを中心に説明する。

＜＜第２実施例の動作処理＞＞
第２実施例は、図５に示すステップＳ１６２または図６に示すステップＳ２３８で、端末１２０Ａの通信部（送信部）３２６は、端末１２０Ａの第１処理部３２７の第２要求部４０４により生成された電子バリュー情報と送金リクエストとをサーバ１１０に送信する。ここで、実施形態と異なり、送金リクエストは送金要求以外にも、関連ユーザの送金金額の調整リクエストに係る情報も含む。例えば、ユーザＡが、送金必要の金額に対して、関連ユーザの収入情報に基づいて、ユーザＢ（父）の送金金額はこの金額の６０％であり、ユーザＣ（母）の送金金額はこの金額の２５％であり、ユーザＤ（兄）の送金金額はこの金額の１５％であるように設定指示に応答して、端末１２０Ａの第１処理部３２７の第２要求部４０４は、送金金額の調整リクエストを生成する。

そして、図５に示すステップＳ１６４または図６に示すステップＳ２４０で、送金リクエストを受信し、サーバ１１０の要求処理部３１７は、関連ユーザから所定の条件を満たす関連ユーザの数（例えばユーザＢ〜Ｄの三人）を取得し、サーバ１１０の送金処理部３１８は、送金金額の調整リクエストに係る調整方法及び電子決済における決済額を用いて、ユーザＢ〜Ｄの送金が必要となる電子バリューの値を決定する。次に、送金処理部３１８は、ユーザＢ〜Ｄそれぞれのアカウントの残高から決定された電子バリューの値を減算し、ユーザＡのアカウントの残高に電子バリューの値を加算する送金処理を実行する。

なお、上記の第２実施例では、ユーザＡは、関連ユーザの収入情報に基づいて関連ユーザの送金金額の調整方法を設定した例として説明したが、関連ユーザの送金金額の調整方法をその他の情報（例えば、親密度や年齢情報等）に基づいて設定してもよい。また、関連ユーザ自身が、送金金額を画面操作等により調整してもよい。

＜＜第３実施例＞＞
第３実施例は、関連ユーザ全員からの送金に対する承認を受信した後に、サーバ１１０は、関連ユーザ全員によって承認された電子バリューの合計値を計算し、合計値が、電子バリュー情報が示す値に満たない場合、サーバ１１０は、この不足分に対して、サーバ１１０を管理する決済事業者のアカウントから不足分をユーザＡのアカウントの残高に加算する実施例である。

＜＜第３実施例の効果＞＞
第３実施例により、上述した実施形態と同様に、実施形態で上述した効果を有しつつ、決済処理における実行可能性を高めることができる。サーバ１１０は、サーバ１１０を管理する決済事業者のアカウントから不足分をユーザＡのアカウントの残高に加算する処理を行うことで、確実に要求元のユーザＡのアカウントに必要な電子バリューの値を加算することができ、ユーザＡが不足分について他の手続きを行う必要がなく、ユーザＡの利便性の向上することができるとともに、送金処理及び決済処理の円滑性かつ迅速性を向上することができるという効果が得られる。

＜＜第３実施例の機能構成＞＞
第３実施例に係るシステム構成、各サーバのハードウェア構成、並びに、各サーバ及び各端末の機能構成は、上述した実施形態と同様である。また、第３実施例では、実施形態と共通の機能、処理等についての記述を省略し、異なる点、すなわち、第３実施例では、図６に示すステップＳ２５６で行われる合計値の不足分の補充処理を中心に説明する。

＜＜第３実施例の動作処理＞＞
第３実施例は、図６に示すステップＳ２５６で、サーバ１１０の要求処理部３１７は、サーバ１１０の通信部（受信部）３１６は全ての関連ユーザからの承認情報を受信した後、待ち状態であった送金処理を送金処理部３１８に指示し、送金処理部３１８は、各関連ユーザからの電子バリューの合計値を取得し、この合計値が、電子バリュー情報が示す値を超えるか否かを判定し、超える場合は送金処理を実行する。また、この合計値が、電子バリュー情報が示す値未満の場合、サーバ１１０の送金処理部３１８は、この不足分に対して、サーバ１１０を管理する決済事業者のアカウントから、ユーザＡのアカウントの残高に不足分を加算する。

なお、以上の第３実施例の説明では、各関連ユーザから送金される電子バリューの合計値は、電子バリュー情報が示す値に満たさない場合において、サーバ１１０は、サーバ１１０を管理する決済事業者のアカウントから不足分をユーザＡのアカウントの残高に加算する処理として説明したが、この処理の順番を逆にしてもよい。例えば、図６に示すステップＳ２５６で、サーバ１１０の送金処理部３１８は、サーバ１１０を管理する決済事業者のアカウントからユーザＡとの契約に基づいて予め定めされた電子バリューの値をユーザＡのアカウントの残高に加算し、このサーバ１１０による加算値は電子バリュー情報が示す値に満たさない場合、この不足分に対して、承認を得た関連ユーザのアカウントの残高から決定された電子バリューの値をユーザＡのアカウントの残高に加算してもよい。

＜＜第４実施例＞＞
第４実施例において、サーバ１１０は、ユーザＡの選択操作に応答して、関連ユーザの中から選択された関連ユーザだけに対して送金処理を行う実施例である。

＜＜第４実施例の効果＞＞
第４実施例により、上述した実施形態と同様に、実施形態で上述した効果を有しつつ、送金処理の利用自由度を高めることができる。第４実施例では、ユーザＡが関連ユーザの中からさらに送金処理の要求先となる関連ユーザを選択してもよい。例えば、ユーザＡは、関連ユーザＢ〜Ｄを有する場合において、ユーザＡは、関連ユーザＢ及び関連ユーザＣだけを選択することができる。この場合において、ユーザＡは自分の都合や意思に沿って、決済額に基づく電子バリューを分け与えてもらいたい関連ユーザを選択することが可能となり、より簡単に各関連ユーザに送金処理に協力させることができ、送金処理及び決済処理を円滑に行わせることが可能となる。例えば、決済時承認における処理の場合、関連ユーザから送金に対する承認を得る可能性を高めることができ、送金処理に係る時間をさらに短縮化することができるという効果が得られる。

＜＜第４実施例の機能構成＞＞
第４実施例に係るシステム構成、各サーバの及び各端末のハードウェア構成、並びに、各サーバ及び各端末の機能構成は、上述した実施形態と同様である。また、第４実施例では、実施形態と共通の機能、処理等についての記述を省略し、異なる点、すなわち、第４実施例では、図５に示すステップＳ１６２または図６に示すステップＳ２３８で行われる関連ユーザの選択リクエストに係る処理と、図５に示すステップＳ１６４または図６に示すステップＳ２４０で行われる選択された関連ユーザに対して送金を求める処理とを中心に説明する。

＜＜第４実施例の動作処理＞＞
第４実施例は、図５に示すステップＳ１６２または図６に示すステップＳ２３８で、端末１２０Ａの通信部（送信部）３２６は、端末１２０Ａの第２要求部４０４により生成された電子バリュー情報と送金リクエストとをサーバ１１０に送信する。ここで、実施形態と異なり、送金リクエストは、送金要求以外にも、関連ユーザの選択リクエストに係る情報も含む。例えば、ユーザＡが、関連ユーザＢ〜Ｄから関連ユーザＢ及び関連ユーザＣだけを選択する設定指示に応答して、端末１２０Ａの第２要求部４０４は、関連ユーザの選択リクエストを生成する。

そして、図５に示すステップＳ１６４または図６に示すステップＳ２４０で、送金リクエストを受信し、サーバ１１０の要求処理部３１７は、選択された関連ユーザの数（例えばユーザＢ及びユーザＣの二人）を取得し、サーバ１１０の送金処理部３１８は、選択された関連ユーザの数及びユーザが電子バリュー（例えば電子決済における決済額）を用いて、ユーザＢ及びユーザＣの送金対象となる電子バリューの値を決定する。次に、送金処理部３１８は、ユーザＢ及びユーザＣそれぞれのアカウントの残高から決定された電子バリューの値を減算し、ユーザＡのアカウントの残高に電子バリューの値を加算する決済処理を実行する。

１ 通信システム、１００ 通信システム、１１０ サーバ、１２０ 端末、１２０Ａ 端末、１２０Ｂ 端末、１２０Ｃ 端末、１２０Ｘ 端末、１３０ 端末、２００ 情報処理装置、２０１ プロセッサ、２０２ メモリ、２０３ ストレージ、２０４ 入出力インタフェース（入出力Ｉ／Ｆ）、２０５ 通信インタフェース（通信Ｉ／Ｆ）、３１１ 入出力Ｉ／Ｆ、３１２ 通信Ｉ／Ｆ、３１３ 制御部、３１４ 記憶部、３１５ 表示制御部、３１６ 通信部、３１７ 要求処理部、３１８ 送金処理部、３２１ 入出力Ｉ／Ｆ、３２２ 通信Ｉ／Ｆ、３２３ 制御部、３２４ 記憶部、３２５ 表示制御部、３２６ 通信部、３２７ 第１処理部、３２８ 第２処理部、４０２ 第１要求部、４０４ 第２要求部、５０２ 設定部。

Claims (16)

1. 情報処理装置が実行する情報処理方法であって、
   第１ユーザが利用する第１情報処理装置から、電子バリュー情報と送金リクエストとを取得するステップと、
   前記送金リクエストに応答して、前記第１ユーザに関連付けられた１又は複数のユーザのうち所定の条件を満たす第２ユーザに対応付けられた制限情報と、前記電子バリュー情報とに基づいて、各第２ユーザに対応付ける電子バリューの値を決定するステップと、
   前記各第２ユーザのアカウントの残高から、決定された電子バリューの値をそれぞれ減算し、前記第１ユーザのアカウントの残高に前記電子バリューの値を加算する送金処理を実行するステップと、を含む情報処理方法。
2. 前記第１ユーザに前記１又は複数のユーザを関連付ける場合、事前に前記第１ユーザへの送金に対して承認を与えたユーザを関連付けるステップをさらに含み、
   前記所定の条件は、前記送金に対して、承認の有無が有であることを含む、請求項１に記載の情報処理方法。
3. 前記送金リクエストを取得した後に、前記１又は複数のユーザが利用する各情報処理装置に、送金依頼情報を送信するステップと、
   前記１又は複数のユーザが利用する各情報処理装置から、前記送金依頼情報に対する承認情報を受信するステップと、をさらに含み、
   前記所定の条件は、前記送金依頼情報に対して、承認の有無が有であることを含む、請求項１に記載の情報処理方法。
4. 前記第１ユーザに前記１又は複数のユーザが関連付けられる場合、前記第１ユーザと前記１又は複数のユーザとを前記制限情報とともに関連付け、
   前記制限情報は、前記送金に対しての承認の有無又は前記送金依頼情報に対しての承認の有無と、送金上限と、送金回数とのうち少なくとも１つを含み、
   前記所定の条件は、前記１又は複数のユーザに対応付けられた前記制限情報に基づいて設定され、前記送金に対しての承認の有無又は前記送金依頼情報に対しての承認の有無が有であることと、前記電子バリュー情報が前記送金上限以下であることと、前記送金リクエストの受信回数が前記送金回数以下であることとのうち少なくとも１つを含む、請求項１から３のいずれか一項に記載の情報処理方法。
5. 電子決済処理を依頼するステップをさらに含み、
   前記電子バリュー情報は、前記電子決済処理における決済額を示し、
   前記決定するステップは、前記電子バリュー情報と前記第１ユーザのアカウントの残高との差額と、前記所定の条件を満たす第２ユーザに対応付けられた制限情報とに基づいて、前記各第２ユーザに対応付ける電子バリューの値を決定する、請求項１から４のいずれか一項に記載の情報処理方法。
6. 前記各第２ユーザに対応付ける電子バリューの値を決定するステップは、前記各第２ユーザの数に基づいて、各第２ユーザに対応付ける電子バリューの値を決定するステップをさらに含む、請求項５に記載の情報処理方法。
7. 前記送金処理の終了後、依頼された前記電子決済処理の決済処理を実行するステップをさらに含む、請求項５又は６に記載の情報処理方法。
8. 前記送金処理の終了後、前記各第２ユーザが利用する各情報処理装置に、前記決定された電子バリューの値が減算されたことを通知するステップをさらに含む、請求項１から７のいずれか一項に記載の情報処理方法。
9. 前記決定するステップは、
   前記決定された電子バリューの値を調整するステップを含む、請求項１から８のいずれか一項に記載の情報処理方法。
10. 前記送金処理を実行するステップは、決定された前記各第２ユーザの電子バリューの合計値が、前記電子バリュー情報が示す値に満たない場合、決済事業者のアカウントから不足分を前記第１ユーザのアカウントの残高に加算するステップを含む、請求項１から９のいずれか一項に記載の情報処理方法。
11. 前記第１情報処理装置から、ユーザの関連付けリクエストを取得するステップと、
    前記関連付けリクエストを取得した後に、ユーザ同士を関連付けるためのペアリング情報を生成するステップと、
    前記ペアリング情報を前記第１情報処理装置に送信するステップと、
    前記１又は複数のユーザが利用する情報処理装置から、前記ペアリング情報とユーザ識別情報とを受信するステップと、
    前記第１ユーザのユーザ識別情報と、取得された前記ユーザ識別情報とを関連付けるステップと、を含む、請求項１から１０のいずれか一項に記載の情報処理方法。
12. 前記送金リクエストを取得した後、前記情報処理装置により抽出された前記１又は複数のユーザを前記第１ユーザに関連付けるステップをさらに含む、請求項１から１１のいずれか一項に記載の情報処理方法。
13. 前記電子バリューの値の返済を前記第１ユーザに求めるステップと、
    前記第１ユーザから前記電子バリューの値の返済後、前記第２ユーザそれぞれのアカウントの残高に、前記決定された電子バリューの値を加算して返済するステップと、をさらに含む、請求項１から１２のいずれか一項に記載の情報処理方法。
14. 前記求めるステップは、前記決定された電子バリューの値が閾値以上であれば実行される、請求項１３に記載の情報処理方法。
15. 第１ユーザが利用する第１情報処理装置から、電子バリュー情報と送金リクエストとを取得する取得部と、
    前記送金リクエストに応答して、前記第１ユーザに関連付けられた１又は複数のユーザの中から、所定の条件を満たす第２ユーザに対応付けられた制限情報と、前記電子バリュー情報とに基づいて、各第２ユーザに対応付ける電子バリューの値を決定する決定部と、
    前記各第２ユーザのアカウントの残高から、決定された電子バリューの値をそれぞれ減算し、前記第１ユーザのアカウントの残高に前記電子バリューの値を加算する送金処理を実行する実行部と、を備える情報処理装置。
16. 情報処理装置に、
    第１ユーザが利用する第１情報処理装置から、電子バリュー情報と送金リクエストとを取得するステップと、
    前記送金リクエストに応答して、前記第１ユーザに関連付けられた１又は複数のユーザの中から、所定の条件を満たす第２ユーザに対応付けられた制限情報と、前記電子バリュー情報とに基づいて、各第２ユーザに対応付ける電子バリューの値を決定するステップと、
    前記各第２ユーザのアカウントの残高から、決定された電子バリューの値をそれぞれ減算し、前記第１ユーザのアカウントの残高に前記電子バリューの値を加算する送金処理を実行するステップと、を実行させるプログラム。

Images