JP7247008B2 - 第１のサーバの制御方法、端末の情報処理方法、第２のサーバの制御方法、プログラム、第１のサーバ、端末、第２のサーバ - Google Patents

Description

本開示は、第１のサーバの制御方法等の技術に関する。

昨今、スマートフォン等の端末で実行可能なアプリケーションによって、端末または端末のユーザの電子マネーの管理や、電子マネーによる決済等を実現するサービスが普及しつつある。例えば特許文献１には、商品の購買金額の決済を行う技術が開示されている。また、電子マネーに関するサービスとして、端末のユーザ間での電子マネーの送金（いわゆる個人間送金）を実現するサービスも提供されている。しかしながら、このサービスは、あくまでも個人間送金を実現するものに過ぎず、汎用性に欠けるという問題がある。

特開２００２－１７６６７１号公報

本発明の第１の態様は、第１のサーバの通信部によって、ＡＰＩ(Application Programming Interface)を介して、電子マネーの送金の条件に関する情報を第２のサーバに送信することと、第１のサーバの通信部によって、ＡＰＩを介して、識別子によって特定される第１のアカウントへ電子マネーを送金の条件に従って、第２のアカウントの指示によって送金することと、を含む第１のサーバの制御方法である。

実施形態の一態様における通信システムの構成の一例を示す図。 実施形態の一態様における送金指示サーバの構成の一例を示す図。 実施例に係るサーバの制御部により実現される機能の一例を示す図。 実施例に係るサーバの記憶部に記憶される情報の一例を示す図。 実施例に係る支払いアプリケーションユーザ登録データの一例を示す図。 実施例に係る送金サービスアカウントデータの一例を示す図。 実施例に係る送金者登録データの一例を示す図。 実施例に係る送金者管理データベースのデータ構成の一例を示す図。 実施例に係るユーザ管理データベースのデータ構成の一例を示す図。 実施例に係る送金指示サーバの制御部により実現される機能の一例を示す図。 実施例に係る送金指示サーバの記憶部に記憶される情報の一例を示す図。 実施例に係る端末の制御部により実現される機能の一例を示す図。 実施例に係る端末の記憶部に記憶される情報の一例を示す図。 実施例に係る端末の表示部に表示される表示画面の一例を示す図。 実施例に係る端末の表示部に表示される表示画面の一例を示す図。 実施例に係る端末の表示部に表示される表示画面の一例を示す図。 実施例に係る端末の表示部に表示される表示画面の一例を示す図。 実施例に係る端末の表示部に表示される表示画面の一例を示す図。 実施例に係る端末の表示部に表示される表示画面の一例を示す図。 実施例に係る端末の表示部に表示される表示画面の一例を示す図。 実施例に係る送金指示サーバのディスプレイに表示される表示画面の一例を示す図。 実施例に係る送金指示サーバのディスプレイに表示される表示画面の一例を示す図。 実施例に係る送金指示サーバのディスプレイに表示される表示画面の一例を示す図。 実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。 実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。 実施例に係る各装置が実行する処理の流れの一例を示すフローチャート。 変形例に係る送金者登録データの一例を示す図。

＜法的事項の遵守＞
本明細書に記載の開示は、通信の秘密など、本開示の実施に必要な実施国の法的事項遵守を前提とすることに留意されたい。

本開示に係る第１のサーバの制御方法等を実施するための実施形態について、図面を参照して説明する。

［システム構成］
図１は、本開示の一実施形態に係る通信システム１の構成の一例を示す図である。
図１に開示されるように、通信システム１では、ネットワーク３０を介してサーバ１０と、端末２０（端末２０Ａ，端末２０Ｂ，端末２０Ｃ，・・・）と、送金指示サーバ４０（送金指示サーバ４０Ａ，送金指示サーバ４０Ｂ，送金指示サーバ４０Ｃ，・・・）と、銀行サーバ６０（銀行サーバ６０Ａ，銀行サーバ６０Ｂ，銀行サーバ６０Ｃ，・・・）とが接続される。

サーバ１０は、ユーザが所有する端末２０に、ネットワーク３０を介して、所定のサービスを提供する。具体的には、例えば、サーバ１０は、端末２０または端末２０のユーザの電子マネーの管理や電子マネーの支払い等に関するサービスを提供する。
なお、ネットワーク３０に接続される端末２０の数は限定されない。

ネットワーク３０は、１以上の端末２０と、１以上のサーバ１０と、１以上の送金指示サーバ４０と、１以上の銀行サーバ６０とを接続する役割を担う。すなわち、ネットワーク３０は、上記の各種の装置が接続した後、データを送受信することができるように接続経路を提供する通信網を意味する。

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

端末２０Ａ、端末２０Ｂおよび端末２０Ｃの構成は基本的には同一であるため、以下の説明においては、端末２０について説明する。なお、ユーザ情報とは、所定のサービスにおいてユーザが利用するアカウントに対応付けられたユーザの情報である。ユーザ情報は、限定ではなく例として、ユーザにより入力される、または、所定のサービスにより付与される、ユーザの名前、ユーザのアイコン画像、ユーザの年齢、ユーザの性別、ユーザの住所、ユーザの趣味趣向、ユーザの識別子などのユーザに対応付けられた情報を含み、これらのいずれか一つまたは、組み合わせであってもよいし、そうでなくてもよい。

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

［各装置のハードウェア（ＨＷ）構成］
通信システム１に含まれる各装置のＨＷ構成について説明する。

（１）端末のＨＷ構成
図１には、端末２０のＨＷ構成の一例を示している。
端末２０は、制御部２１（ＣＰＵ：central processing unit（中央処理装置））、記憶部２８、通信Ｉ／Ｆ２２（インタフェース）、入出力部２３、表示部２４、マイク２５、スピーカ２６、カメラ２７を備える。端末２０のＨＷの各構成要素は、限定ではなく例として、バスＢを介して相互に接続される。なお、端末２０のＨＷ構成として、すべての構成要素を含むことは必須ではない。限定ではなく例として、端末２０は、マイク２５、カメラ２７等、個々の構成要素、または複数の構成要素を取り外すような構成であってもよいし、そうでなくてもよい。

通信Ｉ／Ｆ２２は、ネットワーク３０を介して各種データの送受信を行う。通信は、有線、無線のいずれで実行されてもよく、互いの通信が実行できるのであれば、どのような通信プロトコルを用いてもよい。通信Ｉ／Ｆ２２は、ネットワーク３０を介して、サーバ１０等の各種装置との通信を実行する機能を有する。通信Ｉ／Ｆ２２は、各種データを制御部２１からの指示に従って、サーバ１０等の各種装置に送信する。また、通信Ｉ／Ｆ２２は、サーバ１０等の各種装置から送信された各種データを受信し、制御部２１に伝達する。また、通信Ｉ／Ｆ２２を単に通信部と表現する場合もある。また、通信Ｉ／Ｆ２２が物理的に構造化された回路で構成される場合には、通信回路と表現する場合もある。

入出力部２３は、端末２０に対する各種操作を入力する装置、および、端末２０で処理された処理結果を出力する装置を含む。入出力部２３は、入力部と出力部が一体化していてもよいし、入力部と出力部に分離していてもよいし、そうでなくてもよい。

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

出力部は、制御部２１で処理された処理結果を出力することができる全ての種類の装置のいずれかまたはその組み合わせにより実現される。出力部は、限定ではなく例として、 タッチパネル、タッチディスプレイ、スピーカ（音声出力）、レンズ（限定ではなく例として３D（three dimensions）出力や、ホログラム出力）、プリンターなどを含む。

表示部２４は、フレームバッファに書き込まれた表示データに従って、表示することができる全ての種類の装置のいずれかまたはその組み合わせにより実現される。表示部２４は、限定ではなく例として、タッチパネル、タッチディスプレイ、モニタ（限定ではなく例として、液晶ディスプレイやOELD（organic electroluminescence display））、ヘッドマウントディスプレイ（ＨＤＭ：Head Mounted Display）、プロジェクションマッピング、ホログラム、空気中など（真空であってもよいし、そうでなくてもよい）に画像やテキスト情報等を表示可能な装置を含む。なお、これらの表示部２４は、３Ｄで表示データを表示可能であってもよいし、そうでなくてもよい。

入出力部２３がタッチパネルの場合、入出力部２３と表示部２４とは、略同一の大きさおよび形状で対向して配置されていてもよい。

制御部２１は、プログラム内に含まれたコードまたは命令によって実現する機能を実行するために物理的に構造化された回路を有し、限定ではなく例として、ハードウェアに内蔵されたデータ処理装置により実現される。そのため、制御部２１は、制御回路と表現されてもよいし、されなくてもよい。

制御部２１は、限定ではなく例として、中央処理装置（ＣＰＵ）、マイクロプロセッサ（microprocessor）、プロセッサコア（processor core）、マルチプロセッサ（multiprocessor）、ＡＳＩＣ（application-specific integrated circuit）、ＦＰＧＡ（field programmable gate array）を含む。

記憶部２８は、端末２０が動作するうえで必要とする各種プログラムや各種データを記憶する機能を有する。記憶部２８は、限定ではなく例として、ＨＤＤ（hard disk drive）、ＳＳＤ（solid state drive）、フラッシュメモリ、ＲＡＭ（random access memory）、ＲＯＭ（read only memory）など各種の記憶媒体を含む。また、記憶部２８は、メモリ(memory)と表現されてもよいし、されなくてもよい。

端末２０は、プログラムＰを記憶部２８に記憶し、このプログラムＰを実行することで、制御部２１が、制御部２１に含まれる各部としての処理を実行する。つまり、記憶部２８に記憶されるプログラムＰは、端末２０に、制御部２１が実行する各機能を実現させる。また、このプログラムＰは、プログラムモジュールと表現されてもよいし、されなくてもよい。

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

（２）サーバのＨＷ構成
図１には、サーバ１０のＨＷ構成の一例を示している。
サーバ１０は、制御部１１（ＣＰＵ）、記憶部１５、通信Ｉ／Ｆ１４（インタフェース）、入出力部１２、ディスプレイ１３を備える。サーバ１０のＨＷの各構成要素は、限定ではなく例として、バスＢを介して相互に接続される。なお、サーバ１０のＨＷは、サーバ１０のＨＷの構成として、全ての構成要素を含むことは必須ではない。限定ではなく例として、サーバ１０のＨＷは、ディスプレイ１３を取り外すような構成であってもよいし、そうでなくてもよい。

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

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

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

通信Ｉ／Ｆ１４は、ネットワーク３０を介して各種データの送受信を行う。通信は、有線、無線のいずれで実行されてもよく、互いの通信が実行できるのであれば、どのような通信プロトコルを用いてもよい。通信Ｉ／Ｆ１４は、ネットワーク３０を介して、端末２０等の各種装置との通信を実行する機能を有する。通信Ｉ／Ｆ１４は、各種データを制御部１１からの指示に従って、端末２０等の各種装置に送信する。また、通信Ｉ／Ｆ１４は、端末２０等の各種装置から送信された各種データを受信し、制御部１１に伝達する。また、通信Ｉ／Ｆ１４を単に通信部と表現する場合もある。また、通信Ｉ／Ｆ１４が物理的に構造化された回路で構成される場合には、通信回路と表現する場合もある。

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

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

（３）送金指示サーバの構成
図２には、送金指示サーバ４０のＨＷ構成の一例を示している。
送金指示サーバ４０は、制御部４１（ＣＰＵ）、記憶部４５、通信Ｉ／Ｆ４４（インタフェース）、入出力部４２、ディスプレイ４３を備える。送金指示サーバ４０のＨＷの各構成要素は、限定ではなく例として、バスＢを介して相互に接続される。なお、送金指示サーバ４０のＨＷは、送金指示サーバ４０のＨＷの構成として、全ての構成要素を含むことは必須ではない。限定ではなく例として、送金指示サーバ４０のＨＷは、ディスプレイ４３を取り外すような構成であってもよいし、そうでなくてもよい。

なお、送金指示サーバ４０の各機能部を構成する部品や回路等は、限定ではなく例として、サーバ１０と同様とすることができるため、説明を省略する。

（４）その他
銀行サーバ６０のＨＷ構成や、各機能部を構成する部品や回路等は、限定ではなく例として、サーバ１０や送金指示サーバ４０と同様に構成することができるため、説明を省略する。

サーバ１０は、プログラムＰを記憶部１５に記憶し、このプログラムＰを実行することで、制御部１１が、制御部１１に含まれる各部としての処理を実行する。つまり、記憶部１５に記憶されるプログラムＰは、サーバ１０に、制御部１１が実行する各機能を実現させる。このプログラムＰは、プログラムモジュールと表現されてもよいし、されなくてもよい。
他の装置についても同様である。

本開示の各実施形態においては、端末２０および／またはサーバ１０のＣＰＵがプログラムＰを実行することにより、実現するものとして説明する。
他の装置についても同様である。

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

また、本開示の各実施形態のプログラムＰ(限定ではなく例として、ソフトウェアプログラム、コンピュータプログラム、またはプログラムモジュール)は、コンピュータに読み取り可能な記憶媒体に記憶された状態で提供されてもよいし、されなくてもよい。 記憶媒体は、「一時的でない有形の媒体」に、プログラムＰを記憶可能である。また、プログラムＰは、本開示の各実施形態の機能の一部を実現するためのものであってもよいし、そうでなくてもよい。さらに、本開示の各実施形態の機能を記憶媒体にすでに記録されているプログラムPとの組み合わせで実現できるもの、いわゆる差分ファイル（差分プログラム）であってもよいし、そうでなくてもよい。

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

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

また、本開示のプログラムＰは、プログラムを伝送可能な任意の伝送媒体(通信ネットワークや放送波等)を介して、サーバ１０および／または端末２０に提供されてもよいし、されなくてもよい。サーバ１０および／または端末２０は、限定ではなく例として、インターネット等を介してダウンロードしたプログラムＰを実行することにより、各実施形態に示す複数の機能部の機能を実現する。
他の装置についても同様である。

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

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

＜実施例＞
近年、ネットワークサービスに関連するアプリケーション（アプリケーションソフトウェア）として、電子マネーによる電子決済用のアプリケーション（決済アプリケーション）、電子マネーの送金用のアプリケーション（送金アプリケーション）といったアプリケーションや、これらのアプリケーションの一部の機能または全部の機能を集約した支払いアプリケーションが普及しつつあり、端末２０のユーザが、これらのアプリケーションを用いて、電子マネーに関する各種のサービスを受けることが可能になってきている。

以下説明する実施例は、限定ではなく例として、端末２０または端末２０のユーザのアカウントへ、送金者のアカウントの指示（または送金指示サーバ４０の指示）によって電子マネーを送金するサービス（以下、簡単に「送金サービス」と称す。）によって、電子マネーを送金する実施例である。以下では、送金サービスを提供する事業者のことを「送金サービスの事業者」と称する。

なお、送金サービスの事業者は、支払いアプリケーションの事業者や、サーバ１０の事業者と表現してもよいし、しなくてもよい。また、送金者のアカウントは、送金者に関連付けられたアカウントとしてもよいし、送金指示サーバ４０に関連付けられたアカウントとしてもよい。以下では、これらを包括的に「送金者のアカウント」と称する。

また、本実施例では、支払いアプリケーション内で送金サービスを含む各種のサービスが提供されることとし、送金サービスの事業者によって、サーバ１０が運用・管理されることとして説明する。以下では、一例として、支払いアプリケーションの名称を「Ｐａｙｍｅｎｔ Ａｐｐ」と称して図示・説明する。

また、本実施例では、後述する送金サービスを利用する法人や企業として送金サービスの事業者と提携している法人や企業を「送金者」と称し、図１では「送金者Ｓ１」、「送金者Ｓ２」、・・・、のように示している。
なお、後述する送金サービスでＡＰＩを介して送金を行う送金者は、個人事業主や個人であっても構わない。

また、限定ではなく例として、送金サービスの事業者と提携している銀行を、図１では「銀行Ｂ１」、「銀行Ｂ２」、・・・のように示している。

送金サービスは、送金サービスの事業者と提携している法人や企業による端末２０のユーザへの電子マネーの送金を可能とするサービスであるため、「法人送金サービス」や「企業送金サービス」と表現することもできる。また、送金サービスは、送金者から端末２０のユーザの残高に電子マネーを付与するサービスであるため、「残高付与サービス」と表現することもできる。

また、本実施例では、送金サービスを、送金サービスの事業者が、送金者に代わって端末２０または端末２０のユーザのアカウントへ電子マネーを送金し（一時的に送金し）、送金した電子マネーの金額を事後的に精算して、送金者に請求するサービスとして説明する。

本実施例において、「電子マネー」とは、物理的貨幣と区別される電子的な貨幣であって、支払いアプリケーションにおいて管理される端末２０または端末２０のユーザが所有する電子的な貨幣であるとともに、支払いアプリケーションのソフトウェアに関連付けられたＡＰＩを介して、送金者のアカウントの指示によって端末２０のユーザ（または端末２０）に送金される電子的な貨幣のことを意味する。電子マネーは、「電子貨幣」と表現してもよいし、しなくてもよい。

また、本実施例における「ＡＰＩ」とは、限定ではなく例として、送金サービスによる電子マネーの送金の機能を外部装置（本実施例では送金指示サーバ４０）で利用可能とするために、サーバ１０（送金サービスの事業者）によって公開される、プログラムコンポーネントにデータを送信する際のデータ構造や、プログラムコンポーネントで処理を行う際の命令方法等が記述されたものである。例えば、電子マネーの送金の命令をサーバ１０に送信したり、電子マネーの送金に関する情報をサーバ１０から受信したりするためのデータ構造や命令方法等がこれに含まれる。

本実施例における送金サービスの用途や、送金サービスを利用して送金者からユーザに電子マネーを送金する目的としては、例えば以下のようなものが挙げられる。
（１）報酬の支払い（アンケートの報酬など）
（２）アフィリエイトの代金の支払い
（３）商品の買取代金の支払い
（４）払い戻し金額の支払い
（５）キャンペーン等の当選金、キャッシュバック等の支払い
（６）交通費や謝礼の支払い
（７）福利厚生費の支払い
（８）フリマアプリなどの売上金の支払い
（９）保険金や保険の返戻金の支払い
（１０）配当金の支払い
（１１）給料の前払い（給料の一部／全部）

＜機能構成＞
（１）サーバの機能構成
図３－１は、本実施例におけるサーバ１０の制御部１１により実現される機能の一例を示す図である。
制御部１１は、主要な機能部として、限定ではなく例として、支払いアプリケーション管理処理部１１１を含む。

支払いアプリケーション管理処理部１１１は、記憶部１５に記憶されている支払いアプリケーション管理処理プログラム１５１に従って、端末２０で実行される支払いアプリケーションに関するデータ等を管理する支払いアプリケーション管理処理を実行する機能を有している。

支払いアプリケーション管理処理部１１１は、限定ではなく例として、識別子によって特定される端末２０または端末２０のユーザのアカウントへ、送金者のアカウントの指示によって電子マネーを送金する、送金サービスによる送金／着金を管理する送金サービス管理処理部１１１１と、端末２０または端末２０のユーザに関連付けられた電子マネーを管理する電子マネー管理処理部１１１３とを機能部として含む。

図３－２は、本実施例におけるサーバ１０の記憶部１５に記憶される情報の一例を示す図である。
記憶部１５には、サーバ１０のメイン処理として実行されるサーバメイン処理プログラムの他、限定ではなく例として、支払いアプリケーション管理処理として実行される支払いアプリケーション管理処理プログラム１５１が記憶される。
支払いアプリケーション管理処理プログラム１５１は、送金サービス管理処理として実行される送金サービス管理処理プログラム１５１１をサブルーチンプログラムとして含む。

また、記憶部１５には、支払いアプリケーションユーザ登録データ１５３と、送金サービスアカウントデータ１５４と、送金者登録データ１５５と、送金者管理データベース１５７と、ユーザ管理データベース１５９とが記憶される。

支払いアプリケーションユーザ登録データ１５３は、支払いアプリケーションによるサービスを利用する端末２０または端末２０のユーザの登録データであり、そのデータ構成の一例を図３－３に示す。
支払いアプリケーションユーザ登録データ１５３には、限定ではなく例として、ユーザ名と、端末電話番号と、端末メールアドレスと、支払いアプリケーションＩＤと、認証パスワードと、アカウント有無と、その他登録情報とが関連付けて記憶される。

ユーザ名は、支払いアプリケーションによるサービスを利用する端末２０のユーザの名称であり、例えば、端末２０のユーザが支払いアプリケーションを最初に利用する際に登録する名称が記憶される。

端末電話番号は、このユーザ名のユーザの端末２０の電話番号であり、例えば、端末２０のユーザが支払いアプリケーションを利用する際に最初に登録する端末２０の電話番号が記憶される。
端末メールアドレスは、このユーザ名のユーザの端末２０のメールアドレスであり、例えば、端末２０のユーザが支払いアプリケーションを利用する際に最初に登録する端末２０のメールアドレスが記憶される。
端末電話番号や端末メールアドレスは、端末２０を識別するための識別情報（以下、「端末識別情報」と称す。）の一例である。

支払いアプリケーションＩＤは、端末２０または端末２０のユーザを識別するための識別情報として機能するＩＤであり、サーバ１０によって、支払いアプリケーションを利用する端末２０毎または端末２０のユーザ毎に固有に設定されるＩＤである。

認証パスワードは、このユーザ名のユーザの端末２０において、支払いアプリケーションの機能として設けられた各種の機能を利用する際に実行する認証処理で、端末２０に入力を要求する認証用のパスワードであり、例えばユーザによって設定されたパスワードが記憶される。

アカウント有無は、支払いアプリケーション内で送金サービスを利用することを希望する端末２０または端末２０のユーザに付与される送金サービス用のアカウントの有無である。以下では、送金サービスを利用する端末２０または端末２０のユーザに付与されるアカウントのことを、単に「アカウント」と称する。
アカウント有無には、アカウントを取得済みである場合は「有」が記憶され、アカウントを取得していない場合は「無」が記憶される。

本実施例では、所定の桁数（例えば１０桁～１２桁のいずれかの桁数）のユニーク（固有）な番号が「アカウント番号」（限定ではなく、識別子の一例）としてサーバ１０によって生成され、このアカウント番号によって、端末２０または端末２０のユーザのアカウントが特定（識別）される。

その他登録情報は、このユーザ名のユーザのその他の登録情報であり、限定ではなく例として、支払いアプリケーションにおいてユーザが使用するアイコンの画像データであるユーザアイコン画像等の情報がこれに含まれる。

なお、上記の各種のユーザ情報は、サーバ１０が提供可能な他のアプリケーションと支払いアプリケーションとで共通のユーザ情報としてサーバ１０で記憶・管理するようにしてもよいし、別のユーザ情報としてサーバ１０で記憶・管理するようにしてもよい。

送金サービスアカウントデータ１５４は、上記のアカウントの管理データであり、そのデータ構成の一例を図３－４に示す。
送金サービスアカウントデータ１５４には、限定ではなく例として、支払いアプリケーションＩＤと、アカウント番号と、アカウント種別とが関連付けて記憶される。

支払いアプリケーションＩＤには、支払いアプリケーションユーザ登録データ１５３においてアカウント有無に「有」が記憶されているＩＤが記憶される。

アカウント番号には、前述したアカウントを特定（識別）するための番号が記憶される。

アカウント種別は、このアカウントの種別であり、限定ではなく例として、キャッシュアカウント「キャッシュ」と、マネーアカウント「マネー」との２つの種別がこれに含まれる。

キャッシュアカウントは、端末２０のユーザが本人であるか否かの確認（以下、「本人確認」と称す。）を行っていないユーザに設定されるアカウントである。
それに対し、マネーアカウントは、本人確認を行ったユーザに設定されるアカウントである。

アカウントが当初設定される際には、本人確認を行っていない状態であるため、アカウント種別には「キャッシュ」が記憶されるが、その後、本人確認が行われることで、アカウント種別が「キャッシュ」から「マネー」に変更（更新）される。

本人確認は、限定ではなく例として、端末２０のユーザが、支払いアプリケーション内で自身の銀行口座を登録することによって行うようにすることができる。具体的には、端末２０でユーザの銀行口座の情報が入力され、入力された銀行口座の情報が、銀行が有するサーバ（銀行サーバ６０）に送信され、銀行サーバ６０において、ユーザによって入力された情報と予め銀行に登録された情報との照合が行われる。その照合結果をサーバ１０が銀行サーバ６０から取得して、取得した照合結果が、ユーザによって入力された情報と予め銀行に登録された情報とが同一であるという結果を示す場合に、本人確認が行われたとすることができる。

なお、端末２０でユーザの銀行口座の情報が入力され、入力された銀行口座の情報がサーバ１０に送信され、サーバ１０において端末２０または端末２０のユーザと関連付けて銀行口座が登録されることで、本人確認が行われるように構成しても構わない。

本実施例において、キャッシュアカウントとマネーアカウントとの違いは、支払いアプリケーションの機能に基づく、サーバ１０で管理している端末２０または端末２０のユーザの電子マネーの口座（以下、「電子マネー口座」と称す。）の電子マネーの一部の用途が制限されるか否かの違いである。

本実施例では、電子マネー口座の電子マネー（より具体的には、電子マネー口座の電子マネーの残高）の用途として、「決済」、「送金」、「出金」、「外貨両替」の４つの用途があることとして説明する。なお、例えば、外貨両替はサービスとして提供しなくても構わない。

「決済」は、店舗で販売される商品を購入したり、店舗で提供されるサービスを受ける際に、電子マネー口座の電子マネーによって支払い額を決済させる機能である。

例えば、端末２０のユーザが店舗で商品を購入する場合に、支払額が「１０，０００円」であったとすると、端末２０は、その支払額の決済をサーバ１０に依頼する。この場合、サーバ１０は、その端末２０のユーザの電子マネー口座の残高から「１０，０００円」を減算することで決済する。決済された金額は、その後に送金サービスの事業者から店舗に支払われる。

「送金」は、例えば、支払いアプリケーション内で「友だち」として登録されている他のユーザのアカウントに送金させる機能である。「友だち」とは、二次元コードや電話番号を介して、他のユーザのアカウントを登録した、各ユーザのリストを指す。

ただし、ここでは言う「送金」とは、本実施例の送金サービスにおける「送金」とは異なり、支払いアプリケーションを利用して、友だち登録されている一の端末２０のユーザのアカウントから他の端末２０のユーザのアカウントへ電子マネーを送金すること（個人間送金）を意味する。

なお、友だちとして登録していないユーザに送金できるように構成しても構わない。具体的にはメールや他のＳＮＳ、二次元コードや電話番号で特定して電子マネーを送金できるように構成しても構わない。

例えば、一のユーザにより、端末２０を用いて、送金先となる他のユーザを選択する操作と、送金額として「１０，０００円」を選択する操作とが行われると、サーバ１０は、一のユーザの電子マネー口座の残高から「１０，０００円」を減算するとともに、他のユーザの電子マネーの口座の残高に「１０，０００円」を加算する。

「出金」は、送金サービスの事業者と提携している銀行であって、端末２０のユーザが利用する銀行としてサーバ１０に登録されている銀行の銀行サーバ６０が管理する銀行口座に電子マネーを出金させる機能である。

サーバ１０で管理されるユーザの電子マネー口座は、そのユーザの銀行口座と関連付けられており、端末２０のユーザは、限定ではなく例として、銀行口座の残高を使用して、電子マネー口座への電子マネーのチャージを行うことができる。例えば、ユーザにより、端末２０を用いて、電子マネーのチャージ額として「１０，０００円」を選択する操作が行われると、サーバ１０は、そのユーザの銀行口座の残高から「１０，０００円」を減算するとともに、そのユーザの電子マネー口座の残高に「１０，０００円」を加算する。

また、端末２０のユーザは、限定でなく例として、電子マネー口座の電子マネーを銀行口座に出金させることができる。
ここで、「出金」とは、電子マネー口座の残高を減算して、その減算分の金額を、銀行口座の残高に加算させることを意味する。

例えば、ユーザにより、端末２０を用いて、そのユーザの電子マネー口座の電子マネーの出金額として「１０，０００円」を選択する操作が行われると、サーバ１０は、そのユーザの電子マネー口座の残高から「１０，０００円」を減算するとともに、銀行サーバ６０と通信を行って、そのユーザの銀行口座の残高に「１０，０００円」を加算させる。

「外貨両替」は、電子マネー口座の残高を用いて、国内の貨幣を外国の貨幣に両替する機能である。

このように、電子マネー口座の電子マネーは、限定でなく例として、ユーザが、その電子マネーの残高の範囲内で制約なく、自由に決済、送金、出金等することができる電子マネーである。

電子マネー口座の電子マネーは、サーバ１０によって、銀行サーバ６０を介して銀行口座に出金することができ（電子マネーの残高が銀行口座の残高に変換され）、銀行口座の残高は、現金自動預け払い機（ＡＴＭ（Automatic Teller Machine））等により紙幣または硬貨として端末２０のユーザが引き出す（受け取る）ことができる。

なお、銀行口座で管理される貨幣は、限定ではなく例として、デジタル情報で管理される貨幣という意味で、デジタル貨幣（デジタル通貨）と表現することができる。

また、本実施例では、本人確認を行っていないキャッシュアカウントのユーザは、上記の機能のうちの「決済」の機能のみを利用することができ、本人確認を行ったマネーアカウントのユーザは、上記の機能のうちの「決済」、「送金」、「出金」、「外貨両替」の全ての機能を利用することができることとする。なお、例えば、キャッシュアカウントも送金機能を利用できるように構成しても構わない。

また、支払いアプリケーションと関連付けてサーバ１０で管理されている電子マネー口座の全ての電子マネーの用途を制限するようにするのではなく、例えば、支払いアプリケーションにおいて送金サービスによってユーザに送金された電子マネーのみを対象として、その用途を制限するようにしてもよい。

送金者登録データ１５５は、送金サービスの事業者と送金者として提携している法人や企業等に関する登録データであり、そのデータ構成の一例を図３－５に示す。前述した用途（例えば、前述した（１）～（１１）の用途）で送金サービスを利用したい法人や企業等が、送金サービスの事業者に対して送金者登録を申請し、送金者登録が許可された法人や企業等に関する登録データが、送金者登録データ１５５に記憶される。

送金者登録データ１５５には、限定ではなく例として、区分と、送金者名称と、送金者連絡先情報と、送金者ＩＤと、その他登録情報とが関連付けて記憶される。

区分は、その送金者の区分であり、例えば、私法人／公法人、営利法人／非営利法人、会社の種類（有限会社／株式会社等）、お店の業態・業種といった、送金者として登録された法人や企業をカテゴリに分類するための情報が記憶される。

送金者名称は、その送金者の名称である。
送金者連絡先情報は、その送金者の連絡先の情報であり、例えば、その送金者の電話番号やメールアドレス、ウェブページのＵＲＬ等の情報がこれに含まれる。

送金者ＩＤは、送金サービスを利用する登録をサーバ１０に行った送金者に付与される識別情報としてのＩＤである。この送金者ＩＤが付与された送金者は、サーバ１０によって配布・提供される送金サービスに関連付けられたＡＰＩを、その送金者が運用する送金指示サーバ４０に組み込み、組み込んだＡＰＩを介して、送金サービスに関連する各種の情報をサーバ１０との間で送受信することが可能となる。

この送金者ＩＤは、限定ではなく例として、送金指示サーバ４０からＡＰＩによってサーバ１０にアクセスするために必要なＩＤであって、サーバ１０によるＡＰＩの管理単位とされるＩＤであるチャンネルＩＤとすることができる。

送金者ＩＤ（例えばチャンネルＩＤ）は、前述したアカウントとは異なるものとも言えるが、同じ送金サービスの枠内で送金指示サーバ４０または送金者に付与される、サービスを利用するための情報という意味では、端末２０または端末２０のユーザのアカウントと同様に、送金者ＩＤ（チャンネルＩＤ）も「アカウント」と言うことができる。端末２０または端末２０のユーザのアカウントは「第１のアカウント」の一例であり、送金者ＩＤは「第２のアカウント」の一例である。

また、本実施例の送金サービスにおける「送金」とは、サーバ１０が、アカウント番号によって特定されるアカウントへ、送金者のアカウントの指示によって電子マネーを送金することを意味する。
なお、本実施例の送金サービスにおける電子マネーの送金は、送金者（または送金指示サーバ４０）から端末２０のユーザ（または端末２０）への電子マネーの送金と言うこともできる。

その他登録情報は、その送金者に関する他の各種の登録情報である。

送金者管理データベース１５７は、送金者登録データ１５５に登録されている送金者に関する管理データを蓄積したデータベースであり、そのデータ構成の一例を図３－６に示す。
送金者管理データベース１５７には、送金者登録データ１５５に記憶されている送金者ごとの管理データとして送金者管理データが記憶される。

各送金者管理データには、限定ではなく例として、送金者ＩＤと、保証金と、送金可能額と、単位送金限度額と、送金履歴データとが記憶される。

保証金は、送金者から送金サービスの事業者に預けられる保証金の金額である。
前述したように、本実施例の送金サービスでは、送金サービスの事業者が送金者に代わって電子マネーを送金し、送金した電子マネーの金額を事後的に精算して、送金者に請求する。そして、送金者は、請求額の金銭を送金サービスの事業者に支払って返済する。

そこで、送金者は、限定ではなく例として、一定期間（例えば、ひと月の期間）に送金するであろう金額（一定期間に送金する金額として想定する金額）を、保証金として、銀行振込等によって事前に送金サービスの事業者に入金して預ける。このようにして送金サービスの事業者に預けられた保証金の金額が、保証金の欄に記憶される。期間内に請求額の金銭が返済されない場合は、保証金から回収される。

なお、保証金は入金を確認してから手動で各送金者管理データの保証金の欄を変更する構成に限らず、例えば銀行が提供するＡＰＩ等により送金者からの入金を定期的に確認し、各送金者管理データの保証金の欄を自動的に更新するように構成しても構わない。

以下、請求額を精算する単位周期を「精算周期」と称す。ただし、「精算」とは、金額を計算すること（または金額を細かく計算すること）を意味する。なお、「精算周期」は、請求額の金銭を返済する単位周期という意味で「返済周期」と表現してもよい。

送金可能額は、送金者から現在送金することのできる電子マネーの金額である。最新の送金可能額と言うこともできる。
この送金可能額は、保証金の金額から、精算周期の期間内に送金済みの金額を減算することで算出されて、送金可能額の欄に記憶される。
送金可能額は、端末２０のユーザの電子マネー口座の残高に付与可能な金額とも言えるため、「残高付与可能額」と表現することもできる。また、送金可能額は、送金者の与信の金額とも言えるため、「与信額」と表現することもできる。

単位送金限度額は、送金者から１回に送金することのできる電子マネーの金額（１回あたりの送金限度額）である。たとえ送金可能額の範囲内の金額であったとしても、単位送金限度額よりも多い金額を送金することはできない。単位送金限度額には、限定ではなく例として、その国の法律に基づき設定される金額（例えば、日本では「１００万円」）を記憶させておくことができる。

上記の保証金、送金可能額、単位送金限度額の情報は、送金者が端末２０のユーザ宛に電子マネーを送金する場合の条件を示す情報である。このため、これらの金額の情報は、電子マネーの送金の条件に関する情報（以下、「送金条件情報」と称す。）の一種と言える。

ここで、精算周期は、上記の一定期間（例えば、ひと月）に対応する周期とすることもできるが、そのようにしないようにすることもできる。
本実施例の送金サービスでは、送金サービスの事業者が電子マネーの送金金額を立て替えるため、例えば、送金者からひと月分の保証金を預かるようにする場合、精算周期もひと月に１回の周期としてしまうと、保証金の金額を超える送金が行われたような場合に、その超えた分の金額を送金サービスの事業者が回収できなくなるリスクが生ずる。

そこで、例えばひと月分の保証金を預かる場合には、限定ではなく例として、精算周期を半月に１回の周期（月に２回）として設定する。そして、その精算周期内に送金を許可する上限の金額を、例えば、保証金の金額の１／２（保証金の金額の半分）の金額として設定しておくようにすることができる。この場合、上記の送金可能額は、「保証金の金額×１／２－半月の期間に送金済みの金額」として算出することができる。

なお、当然ではあるが、精算周期を、上記の一定期間に対応する周期とすることもできる。また、精算周期を、例えば、ひと月に３回以上の周期とすることもできる。
さらに、保証金が適用される一定期間も、ひと月に限らず、例えば半月やふた月以上の期間としてもよい。

送金履歴データは、送金サービスにおける、この送金者の送金履歴に関するデータであり、限定ではなく例として、送金した日時である送金日時と、送金先のアカウント番号である送金先アカウント番号と、送金した金額である送金金額とが関連付けて記憶される。

ユーザ管理データベース１５９は、支払いアプリケーションユーザ登録データ１５３に登録されているユーザに関する管理データを蓄積したデータベースであり、そのデータ構成の一例を図３－７に示す。
ユーザ管理データベース１５９には、支払いアプリケーションユーザ登録データ１５３に登録されているユーザに関する管理データとしてユーザ管理データが記憶される。

各ユーザ管理データには、限定ではなく例として、支払いアプリケーションＩＤと、アカウント有無と、アカウント番号と、アカウント種別と、電子マネー口座残高と、着金履歴データとが記憶される。

支払いアプリケーションＩＤ～アカウント種別は、前述した通りである。
電子マネー口座残高は、この支払いアプリケーションＩＤのユーザの電子マネーの口座の残高の金額である。

着金履歴データは、送金サービスにおける、このアカウント番号のアカウントへの着金履歴のデータであり、限定ではなく例として、着金した日時である着金日時と、電子マネーの送金元の送金者の送金者ＩＤである送金元送金者ＩＤと、着金した金額である着金金額とが関連付けて記憶される。

（２）送金指示サーバの機能構成
図３－８は、本実施例における送金指示サーバ４０の制御部４１により実現される機能の一例を示す図である。
制御部４１は、主要な機能部として、限定ではなく例として、送金用ＡＰＩ処理部４１２を含む。

送金用ＡＰＩ処理部４１２は、記憶部４５に記憶されている送金用ＡＰＩプログラム４５２に従って、サーバ１０との間で電子マネーの送金に関する情報を送受信して、送金サービスによる電子マネーの送金を行うための送金用ＡＰＩ処理を実行する機能を有している。

図３－９は、本実施例における送金指示サーバ４０の記憶部４５に記憶される情報の一例を示す図である。
記憶部４５には、限定ではなく例として、送金指示サーバメイン処理として実行される送金指示サーバメイン処理プログラム４５１と、送金用ＡＰＩ処理として実行される送金用ＡＰＩプログラム４５２とが記憶される。

送金用ＡＰＩプログラム４５２は、前述したＡＰＩに基づき、サーバ１０を介して、電子マネーを送金するためのプログラムである。

また、記憶部４５には、限定ではなく例として、送金者ＩＤデータ４５３と、送金先ユーザデータ４５５と、送金条件データ４５７と、送金者ウェブページデータベース４５９とが記憶される。

送金者ＩＤデータ４５３は、サーバ１０によって付与された送金者ＩＤ（例えばチャンネルＩＤ）が記憶されたデータである。

送金先ユーザデータ４５５は、送金サービスによって電子マネーを送金する端末２０のユーザとしてあらかじめ登録されたユーザに関するデータであり、限定ではなく例として、送金先のユーザの端末２０の電話番号やメールアドレス、住所等の情報がこれに含まれる。

なお、本実施例では、送金先ユーザデータ４５５には、前述した支払いアプリケーションＩＤやアカウント番号といった、アカウントに関する情報は記憶されておらず、送金者側では、これらの情報を管理していないこととして説明する。

端末２０または端末２０のユーザのアカウントには、前述したように、「キャッシュアカウント」と「マネーアカウント」との２つの種別が存在する。しかし、これら異なる種別のアカウントが同じ送金サービス内で併存しているため、送金者は、同じ仕組みで電子マネーを送金することができる。

また、本実施例では、送金者側では送金先のアカウントの種別に関する情報を管理していない。よって、送金者は、電子マネーの送金先の端末２０または端末２０のユーザのアカウントの種別が「キャッシュアカウント」と「マネーアカウント」とのいずれの種別のアカウントであるかを意識することなく、サーバ１０に電子マネーの送金を依頼する。

送金条件データ４５７は、前述した電子マネーの送金条件情報が記憶されたデータであり、限定ではなく例として、前述した保証金、送金可能額、単位送金限度額等の情報がこれに含まれる。これらの情報は、送金指示サーバ４０が、ＡＰＩを介して、送金条件情報の送信をサーバ１０に要求する送金条件情報リクエストを送信し、そのレスポンスとしてサーバ１０から受信することで取得可能である。

送金者ウェブページデータベース４５９は、送金者がインターネット上に掲載するウェブページやウェブサイトの表示用データである。限定ではなく例として、顧客である端末２０のユーザがお金の受け取り方法や受け取りに必要な情報を入力して受け取りを送金者に申請するための受取申請ページ等のウェブページの表示用データがこれに含まれる。受取申請ページ等の送金サービスに関連するウェブページは、送金者側で独自に作成される。

（３）端末の機能構成
図３－１０は、本実施例における端末２０の制御部２１により実現される機能の一例を示す図である。
制御部２１は、主要な機能部として、限定ではなく例として、支払いアプリケーション処理部２１１を含む。

支払いアプリケーション処理部２１１は、記憶部２８に記憶されている支払いアプリケーションプログラム２８７に従って、支払いアプリケーションの各種の機能に基づく処理を行う機能を有している。

図３－１１は、本実施例における端末２０の記憶部２８に記憶される情報の一例を示す図である。
記憶部２８には、限定ではなく例として、端末メイン処理として実行される端末メイン処理プログラム２８１と、支払いアプリケーション処理として実行される支払いアプリケーションプログラム２８７と、支払いアプリケーションデータ２８９とが記憶される。
文中の支払いアプリケーションとは、この支払いアプリケーションプログラム２８７を意味する。なお、支払いアプリケーションは、メッセージングサービス（ＭＳ）の機能を有さない単体のアプリケーションとして提供されても構わないし、ＭＳの機能を有する複合的なアプリケーションとして提供されても構わない。

支払いアプリケーションデータ２８９は、支払いアプリケーションの各種の機能を実現するためのデータであり、限定ではなく例として、支払いアプリケーションＩＤのデータである支払いアプリケーションＩＤデータ２８９１と、送金サービスのアカウントのデータであるアカウントデータ２８９３と、送金サービスによって着金した電子マネーの履歴データである着金履歴データ２８９５とがこれに含まれる。

＜表示画面例＞
本実施例における送金サービスを利用した電子マネーの送金について表示画面例を参照して説明する。

（１）端末の表示画面
図３－１２は、端末２０で実行される支払いアプリケーションにおいて表示部２４に表示されるアプリケーション画面の一例を示す図である。このアプリケーション画面は、支払いアプリケーションにおいて、送金サービスのアカウントを取得する操作がなされ、サーバ１０によって、アカウントが付与された場合に表示される画面の一例である。

このアプリケーション画面には、支払いアプリケーション「Ｐａｙｍｅｎｔ Ａｐｐ」において付与される送金サービスのアカウント番号であることを示す「アカウント番号」の文字が表示され、その下に、この端末２０のユーザに付与されたアカウント番号の数字が表示されている。この例では、アカウント番号として１１桁の番号が付与されている。なお、この図では、便宜的に数字の一部を「Ｘ」で示しているが、実際には「Ｘ」の部分は数字で表示される。

アカウント番号の下には、送金サービスやアカウント番号の使い方を説明するための説明文と、送金サービスの利用方法を説明するための画像とが表示されている。この画像は、ユーザを示す画像と送金者を示す画像とを含む、これらの画像間を結び矢印によって、「ステップ１．ユーザから送金者に入金を要請する」、「ステップ２．入金された金銭をＰａｙｍｅｎｔ Ａｐｐで受け取る」が示されている。ただし、ここで言う「入金の要請」とは、金銭の払い込みを送金者に求めることを意味する。

また、その下には、上記の「ステップ１」および「ステップ２」の詳細な説明が表示されている。具体的には、「ステップ１」の詳細な説明として、送金者のウェブページ（例えば、後述する受取申請ページ）でアカウント番号および電話番号（本実施例では携帯電話番号）の下４桁を入力すること、送金者によっては電話番号の入力が要求されない場合があること、が示されている。
また、「ステップ２」の詳細な説明として、入金された金額を「Ｐａｙｍｅｎｔ Ａｐｐ」で確認することが示されている。

図３－１３～図３－１６は、送金者が作成するウェブページの一例であって、端末２０のユーザがお金の受け取りを申請するための受取申請ページの一例を示す図である。端末２０は、これらのウェブページにブラウザまたは支払いアプリケーションの内蔵ブラウザによってアクセスする。
この受取申請ページは、送金者の一例である「洋服買い取り専門の店舗（○○店）」によって作成された受取申請ページであり、この受取申請ページにユーザが自身の端末２０からアクセスした場合に表示部２４に表示される受取申請ページ画面を示したものである。また、ここでは、端末２０のユーザが、この店舗に事前に洋服の買い取りを依頼しており、見積り等を経て、買い取りの契約が成立していることとする。

この受取申請ページ画面には、画面上部に店舗の名称が表示され、その下に、現在の進行状況を示す画像（「お客様情報入力」、「お申し込み内容確認」、「お受け取り方法選択」、「お申し込み完了」）が表示されている。図３－１３は、「お申し込み内容確認」に対応する申し込み内容の確認画面であり、画面中央部に、申込日と、受付番号と、買取代金とが表示されている。また、その下には、「上記の内容でよろしいでしょうか？」というメッセージとともに、受取方法選択画面に移動するための「お受け取り方法選択へ」のボタンと、１つ前の画面に戻るための「戻る」のボタンとが表示されている。例えば、この画面において「お受け取り方法選択へ」のボタンがタッチされると、図３－１４に示すような受取方法選択画面が表示される。

この受取方法選択画面には、端末２０のユーザが買取代金を受け取る方法として、銀行振込によって買取代金を受け取るための「銀行振込」のボタンと、支払いアプリケーションの送金サービスを利用して買取代金を受け取るための「Ｐａｙｍｅｎｔ Ａｐｐ」のボタンとが表示されている。例えば、この画面において「Ｐａｙｍｅｎｔ Ａｐｐ」のボタンがタッチされると、図３－１５に示すようなアカウント番号入力画面が表示される。

このアカウント番号入力画面は、端末２０のユーザが支払いアプリケーションで取得した送金サービスのアカウント番号を入力するための画面であり、画面中央部に「アカウント番号を入力してください。」というメッセージと、下部のテンキーによって入力されたアカウント番号が表示されるアカウント番号表示欄とが表示されている。このアカウント番号入力画面において番号が入力され、「完了」のボタンがタッチされると、図３－１６に示すような追加認証情報入力画面が表示される。

この追加認証情報入力画面は、端末２０のユーザが追加認証情報を入力するための画面であり、ここでは、サーバ１０に登録している携帯電話番号の下４桁の情報を追加認証情報として入力させる例を示している。具体的には、画面中央部に「登録している携帯電話の番号下４桁を入力してください。」というメッセージと、下部のテンキーによって入力された下４桁の番号が表示される下４桁番号表示欄とが表示されている。この追加認証情報入力画面において番号が入力され、「完了」のボタンがタッチされると、申し込み完了画面（不図示）が表示される。

図３－１７は、上記の受取申請画面において買取代金の受け取り申請を行ったユーザの端末２０の表示部２４に表示される通知画面の一例を示す図である。
買取代金の受け取り申請が完了すると、アカウント番号から特定されるアカウントへ、買取代金を電子マネーによって送金する依頼が、送金指示サーバ４０からＡＰＩを介してサーバ１０に行われる。すると、サーバ１０により、そのアカウントの電子マネー口座の残高に、買取金額に相当する金額が加算されて更新される。そして、サーバ１０によって、そのアカウントの端末２０に通知がなされる。

具体的には、端末２０の待ち受け画面において、「Ｐａｙｍｅｎｔ Ａｐｐ 送金者からの入金があります。」というメッセージと関連付けて、支払いアプリケーション「Ｐａｙｍｅｎｔ Ａｐｐ」を起動させるための「開く」のアイコンが表示されている。

ここで、支払いアプリケーションには、限定ではなく例として、メッセージングサービスの一種であるインスタントメッセージングサービス（ＩＭＳ（Instant Messaging Service））の機能を含めるようにすることもできる。この場合、限定ではなく例として、ＩＭＳの機能に基づき、送金サービスのアカウント（限定ではなく、第１のアカウントの一例）、または支払いアプリケーションのアカウント（限定ではなく、第１のアカウントと関連付けられたアカウントの一例）によって、電子マネーに関する履歴情報を表示するためのトークルーム画面を表示部２４に表示させるようにすることができる。

図３－１８は、上記の通知画面において「開く」のアイコンがタッチされた場合に表示される表示画面の一例を示す図である。
「開く」のアイコンがタッチされると、限定ではなく例として、支払いアプリケーションが端末２０で起動され、電子マネーに関する履歴情報を表示するためのトークルーム画面が表示される。このトークルーム画面では、画面下部に、「Ｐａｙｍｅｎｔ Ａｐｐ」のアイコン画像が表示され、このアイコン画像と関連付けて、送金者からの入金（送金）に関する情報が吹き出しで表示されている。

この例では、「送金者から上記の金額が入金されました。」のメッセージとともに、入金（送金）された金額を示す「チャージ ３，０００円」の文字が表示されている。また、その下には、入金（送金）の詳細を確認するための「詳細を確認」の文字が示された操作用画像が表示されている。

（２）送金指示サーバの表示画面
図３－１９～図３－２１には、送金指示サーバ４０のディスプレイ４３に表示される送金サービスに関連する情報が表示される表示画面の一例を示している。以下では、限定ではなく例として、「Ｐａｙｍｅｎｔ Ａｐｐ 送金者管理ツール」という名称の管理ツールによって表示される管理ツール画面を例示する。

図３－１９は、管理ツールのうちの送金条件情報確認画面の一例を示す図である。
この送金条件情報確認画面は、送金者側で送金条件情報を確認するための画面である。
管理ツール画面から、送金条件情報を要求する操作がなされると、ＡＰＩによって、送金指示サーバ４０から送金条件情報リクエストがサーバ１０に送信される。そして、そのレスポンスとして、送金指示サーバ４０は、ＡＰＩによって、サーバ１０から送金条件情報レスポンスを受信し、受信した送金条件情報レスポンスに基づいて、送金条件情報確認画面を表示する。

この送金条件情報確認画面では、限定ではなく例として、画面中央部に、「送金条件情報」の文字とともに、保証金と、送金可能額と、１回あたりの送金限度額（単位送金限度額）とが表示されている。ここでは、保証金として「１００，０００，０００円」が、送金可能額として「３０，０００，０００円」が、単位送金限度額として「１，０００，０００円」がそれぞれ表示された状態が例示されている。

例えば、前述したように、精算周期として半月に１回の周期（月に２回）が設定されている場合、送金者が保証金として「１００，０００，０００円」を送金サービスの事業者に預けたとすると、この精算周期内に送金が許可される金額は、保証金の金額の１／２の金額、つまり「５０，０００，０００円」となる。この表示画面例では、そのうちの「２０，０００，０００円」が既に送金に使用されたことで、送金可能額として「５０，０００，０００円－２０，０００，０００円＝３０，０００，０００円」が表示された状態が示されている。

図３－２０は、管理ツールのうちの送金完了画面の一例を示す図である。
この送金完了画面は、送金者側で送金の完了を確認するための画面である。
管理ツール画面から、送金を依頼する操作がなされると、ＡＰＩによって、送金指示サーバ４０から送金リクエストがサーバ１０に送信される。そして、サーバ１０によって送金が実行されると、送金指示サーバ４０は、ＡＰＩによって、サーバ１０から送金完了（送金成功）に関する送金レスポンスを受信し、受信した送金レスポンスに基づいて、送金完了画面を表示する。

この送金完了画面では、限定ではなく例として、画面中央部に、「送金完了」の文字とともに、「送金が完了しました。」というメッセージと、送金先として指定したアカウント番号と、送金指示サーバ４０が発行して送金リクエストに含めてサーバ１０に送信した注文ＩＤとしての送金依頼ＩＤと、サーバ１０が送金した金額である送金額とが、ポップアップ形式で表示されている。

図３－２１は、管理ツールのうちの送金エラー画面の一例を示す図である。
この送金エラー画面は、送金者側で送金エラーを確認するための画面である。
管理ツール画面から、送金を依頼する操作がなされると、ＡＰＩによって、送金指示サーバ４０から送金リクエストがサーバ１０に送信される。しかし、何らかの原因により、サーバ１０が送金を実行することができなかった場合、送金指示サーバ４０は、ＡＰＩによって、サーバ１０から送金エラー（送金失敗）に関する送金レスポンスを受信し、受信した送金レスポンスに基づいて、送金エラー画面を表示する。

なお、管理ツールは提供しないように構成しても構わない。この場合は、送金サービスに係る全ての操作がＡＰＩを介してのみ行われる。

この送金エラー画面では、限定ではなく例として、画面中央部に、「送金エラー」の文字とともに、「エラーが発生しました。」というメッセージと、発生したエラーの種類に応じたエラーコードと、送金の失敗の理由とが、ポップアップ形式で表示されている。ここでは、送金の失敗の理由として、送金可能額を超えていることを示す「送金可能額を超えています。」というメッセージが表示された状態が示されている。

＜処理＞
図３－２２～図３－２４は、本実施例における各装置が実行する処理の流れの一例を示すフローチャートである。
これらの図では、左側から順に、端末２０の制御部２１が実行する端末メイン処理、サーバ１０の制御部１１が実行する支払いアプリケーション管理処理、送金指示サーバ４０の制御部４１が実行する送金指示サーバメイン処理の一例をそれぞれ示している。
フローチャートの各ステップは、それぞれの装置のＣＰＵが記憶部からプログラムを読み出して実行することにより実現される。

なお、以下説明するフローチャートは、本開示の手法を実現するための処理の手順を例示したものに過ぎない。このため、本開示の手法を実現するための処理は、以下説明するフローチャートに従って実行される処理に限定されず、一部のステップを省略したり、他のステップを追加することも可能である。

最初に、端末２０の制御部２１は、自己の端末２０において支払いアプリケーションが実行中であるか否かを判定する（Ａ１）。実行中であると判定したならば（Ａ１：ＹＥＳ）、支払いアプリケーション処理部２１１が、支払いアプリケーション内で、入出力部２３に対して、送金サービスのアカウントを取得する操作がなされたか否かを判定する（Ａ３）。

アカウントを取得する操作がなされたと判定したならば（Ａ３：Ｙｅｓ）、支払いアプリケーション処理部２１１は、支払いアプリケーションＩＤを含むアカウント取得要求情報を、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ５）。

サーバ１０の支払いアプリケーション管理処理部１１１は、通信Ｉ／Ｆ１４によって端末２０からアカウント取得要求情報を受信したか否かを判定する（Ｂ１）。受信したと判定したならば（Ｂ１：Ｙｅｓ）、送金サービス管理処理部１１１１が、アカウント生成処理を行う（Ｂ３）。

具体的には、限定ではなく例として、ランダムな番号を発生させるアルゴリズムに従って所定の桁数のランダムな番号を発生させ、これをアカウント番号とする。そして、支払いアプリケーションユーザ登録データ１５３のうちの、端末２０から受信したアカウント取得情報に含まれる支払いアプリケーションＩＤに関連付けられたアカウント有無を「有」に更新する。また、生成したアカウント番号と、アカウント種別（初期設定では「キャッシュアカウント」）とを、支払いアプリケーションＩＤと関連付けて、送金サービスアカウントデータ１５４に記憶させる。

なお、Ｂ１とＢ３ではアカウント取得要求が行われることでアカウント番号を生成する構成としたが、取得要求が行われる前に予め全てのユーザのアカウント番号を生成しておくように構成しても構わない。

次いで、送金サービス管理処理部１１１１は、生成したアカウント番号を、通信Ｉ／Ｆ１４によって端末２０に送信する（Ｂ５）。通信Ｉ／Ｆ２２によってサーバ１０からアカウント番号を受信すると（Ａ７）、支払いアプリケーション処理部２１１は、受信したアカウント番号を表示部２４に表示させる（Ａ９）。

送金指示サーバ４０の制御部４１は、入出力部４２に対して、送金条件情報の送信をサーバ１０に要求する操作がなされたか否かを判定する（Ｃ１）。そして、なされたと判定したならば（Ｃ１：ＹＥＳ）、送金用ＡＰＩ処理部４１２が、送金用ＡＰＩプログラム４５２に従い、チャンネルＩＤを用いてＡＰＩによってサーバ１０にアクセスして、送金条件情報リクエストをサーバ１０に送信する（Ｃ３）。

送金サービス管理処理部１１１１は、通信Ｉ／Ｆ１４によって、ＡＰＩを介して、送金指示サーバ４０から送金条件情報リクエストを受信したか否かを判定し（Ｂ７）、受信したと判定したならば（Ｂ７：ＹＥＳ）、送金条件情報の送信の可否（送信の是非）を判定する送金条件情報送信可否判定処理を行う（Ｂ９）。

その後、送金サービス管理処理部１１１１は、通信Ｉ／Ｆ１４によって、ＡＰＩを介して、送金条件情報レスポンスを送金指示サーバ４０に送信する（Ｂ１１）。

具体的には、Ｂ９で送金条件情報を送信可能と判定した場合は、送金者管理データベース１５７のうちの、サーバ１０へのアクセスに使用されたチャンネルＩＤに対応する送金者ＩＤが記憶されている送金者管理データから、送金条件データに含まれる送金条件情報（保証金、送金可能額、単位送金限度額）を取得する。そして、限定ではなく例として、送信ＯＫ（成功）を示すリターンコード（例えば「００００」）と、送信ＯＫである旨の返答メッセージと、取得した送金条件情報（保証金、送金可能額、単位送金限度額）とを含む送金条件情報レスポンスを、ＡＰＩを介して、送金指示サーバ４０に送信する。

一方、送金条件情報が送信不可と判定した場合は、限定ではなく例として、送信ＮＧ（失敗）を示すリターンコードと、送信ＮＧの理由（失敗の理由）とを含む送金条件情報レスポンスを、ＡＰＩを介して、送金指示サーバ４０に送信する。

ここで、送信ＮＧ（失敗）を示すリターンコードは、送信ＮＧの理由（失敗の理由）に応じて異なる数字のコードとすることができる。送金条件情報の送信が不可となる理由としては、例えば、送金条件情報をリクエストした企業や法人等が送金者として正式に登録されている企業や法人等ではないこと、送金条件情報をリクエストした企業や法人等が何らかの理由で送金サービスを利用できない状態となっていること、送金条件情報リクエストの情報に誤りがあること（例えばヘッダ情報エラー）、サーバ１０の内部エラー、といった複数の理由が想定される。これら複数の理由それぞれに関連付けて異なる数字のリターンコードを設定しておき、対応する理由に応じたリターンコードを含めて送金条件情報レスポンスを送信するとよい。

送金用ＡＰＩ処理部４１２は、通信Ｉ／Ｆ１４によって、ＡＰＩを介して、サーバ１０から送金条件情報レスポンスを受信すると（Ｃ５）、受信した送金条件情報レスポンスに基づく情報をディスプレイ４３に表示させる（Ｃ７）。

具体的には、送信ＯＫ（成功）を示すリターンコード（例えば「００００」）を含む送金条件情報レスポンスを受信した場合は、この送金条件情報レスポンスに含まれる送金条件情報（保証金、送金可能額、単位送金限度額）をディスプレイ４３に表示させる。一方、送信ＮＧ（失敗）を示すリターンコードを含む送金条件情報レスポンスを受信した場合は、この送金条件情報レスポンスに含まれる送信ＮＧの理由（失敗の理由）をディスプレイ４３に表示させる。

Ａ９の後、または、Ａ１において支払いアプリケーション実行中ではないと判定した場合（Ａ１：ＮＯ）、制御部２１は、入出力部２３に対して、送金者によって提供されるウェブサイトの一例である受取申請ページにアクセスする操作がなされたか否かを判定する（Ａ１１）。そして、なされたと判定したならば（Ａ１１：ＹＥＳ）、制御部２１は、通信Ｉ／Ｆ２２によって、送金者の受取申請ページにアクセスする（Ａ１３）。

制御部４１は、端末２０から受取申請ページへのアクセスがあったか否かを判定し（Ｃ９）、あったと判定したならば（Ｃ９：ＹＥＳ）、通信Ｉ／Ｆ４４によって受取申請ページの表示用情報を端末２０に送信する（Ｃ１１）。これを受けて、受取申請ページが端末２０の表示部２４に表示される（Ａ１５）。

次いで、制御部２１は、受取申請ページにおいて入出力部２３を介して端末２０のユーザによって入力された入力情報を、通信Ｉ／Ｆ２２によって送金指示サーバ４０に送信する（Ａ１７）。ここで、入力情報には、少なくとも、Ａ７で受信したアカウント番号（識別子）が含まれる。つまり、受取申請ページにおいてユーザによって入力されたアカウント番号が、端末２０から送金指示サーバ４０に送信される。

なお、表示画面例で説明したように、アカウント番号に加えて、アカウント番号とは異なる情報、例えば、ユーザの端末２０の端末電話番号の下４桁等の追加認証情報を入力情報に含めて、端末２０から送金指示サーバ４０に送信するようにしてもよい。

通信Ｉ／Ｆ４４によって端末２０から入力情報を受信すると（Ｃ１３）、送金用ＡＰＩ処理部４１２が、送金用ＡＰＩプログラム４５２に従い、チャンネルＩＤを用いてＡＰＩによってサーバ１０にアクセスして、送金リクエストをサーバ１０に送信する（Ｃ１５）。ここで、送金リクエストには、限定ではなく例として、端末２０から受信した入力情報（アカウント番号は必須。追加認証情報は任意。）と、サーバ１０に送金を依頼する金額（以下、「送金依頼金額」と称す。）と、通貨コードと、送金者側でユニークに生成した送金依頼ＩＤ（注文ＩＤと表現してもよい。）とを含む送金リクエストをサーバ１０に送信する（Ｃ１５）。

送金サービス管理処理部１１１１は、通信Ｉ／Ｆ１４によって、ＡＰＩを介して、送金指示サーバ４０から送金リクエストを受信したか否かを判定し（Ｂ２１）、受信したと判定したならば（Ｂ２１：ＹＥＳ）、送金可否判定処理を行う（Ｂ２３）。

送金可否判定処理について詳細に説明する。
（Ａ）第１に、送金条件情報に基づく送金可否を判定する。
具体的には、送金者管理データベース１５７のうちの、サーバ１０へのアクセスに使用されたチャンネルＩＤに対応する送金者ＩＤが記憶されている送金者管理データを読み出す。そして、読み出した送金者管理データに含まれる送金条件情報と、受信した送金リクエストに含まれる送金依頼金額とに基づいて、電子マネーの送金が可能であるか否かを判定する。

（２）第２に、アカウントに基づく送金可否を判定する。
まず、受信した送金リクエストに含まれる入力情報に基づき、電子マネーの送金先のアカウントを判定する。具体的には、入力情報にアカウント番号のみが含まれる場合は、送金サービスアカウントデータ１５４を参照し、そのアカウント番号と一致するアカウント番号が存在するか否かを判定する。一致するアカウント番号が存在する場合は「送金可能」と判定し、そのアカウント番号から特定されるアカウントを、電子マネーの送金先のアカウントと判定する。一方、一致するアカウント番号が存在しない場合は「送金不可」と判定する。

また、入力情報にアカウント番号と追加認証情報とが含まれる場合は、最初に、送金サービスアカウントデータ１５４を参照し、そのアカウント番号と一致するアカウント番号が存在するか否かを判定する。一致するアカウント番号が存在する場合は、そのアカウント番号に関連付けて記憶されている支払いアプリケーションＩＤを特定する。続けて、支払いアプリケーションユーザ登録データ１５３を参照し、特定した支払いアプリケーションＩＤに関連付けて記憶されている情報に基づき、追加認証情報が一致するか否かを判定する。例えば、追加認証情報が端末電話番号の下４桁の数字である場合は、その数字が、特定した支払いアプリケーションＩＤに関連付けて記憶されている端末電話番号の下４桁の数字と一致するか否かを判定する。そして、一致する場合は「送金可能」と判定し、そのアカウント番号から特定されるアカウントを、電子マネーの送金先のアカウントと判定する。このようにしているのは、送金者の受取申請ページにおいて、ユーザによって情報が誤入力され、その結果、他のアカウントに電子マネーが送金されてしまうなどの問題が生ずる可能性があるためである。

一方、一致するアカウント番号は存在するが、追加認証情報が一致しない場合は「送金不可」と判定する。これは、ユーザが追加認証情報を誤入力したか、ユーザがアカウント番号を誤入力し、それが他のユーザのアカウント番号と偶然に一致した可能性があるためである。

また、一致するアカウント番号は存在しないが、支払いアプリケーションユーザ登録データ１５３において一致する追加認証情報が存在する場合も「送金不可」と判定する。これは、ユーザがアカウント番号を誤入力したか、そもそも送金サービスのアカウントを取得していないユーザが受け取りを申請した可能性があるためである。

また、一致するアカウント番号と一致する追加認証情報の両方が存在しない場合も「送金不可」と判定する。ユーザが両方の情報を誤入力した可能性もあるが、いたずら等によって第三者によって受け取りが申請された可能性が高いと考えられるためである。

送金可否判定処理で送金が可能であると判定したならば（Ｂ２５：ＹＥＳ）、送金サービス管理処理部１１１１は、送金処理を行う（Ｂ２７）。具体的には、ユーザ管理データベース１５９のうちの、Ｂ２３で判定したアカウントのアカウント番号が記憶されているユーザ管理データを読み出す。そして、読み出したユーザ管理データの電子マネー口座残高に、受信した送金リクエストに含まれる送金依頼金額を送金金額として加算して更新する。また、そのユーザ管理データの着金履歴データを更新する。

その後、送金サービス管理処理部１１１１は、Ｂ２３で読み出した送金者管理データを更新する（Ｂ２９）。具体的には、送金条件データの送金可能額から送金金額を減算して更新する。また、その送金者管理データの送金履歴データを更新する。

次いで、送金サービス管理処理部１１１１は、アカウント番号から特定されるアカウントに着金があったことを通知するための着金通知情報を、通信Ｉ／Ｆ１４によって端末２０に送信する（Ｂ３１）。

通信Ｉ／Ｆ２２によってサーバ１０から着金通知情報を受信すると（Ａ２１）、制御部２１は、支払いアプリケーションを実行中であるか否かを判定する（Ａ２３）。支払いアプリケーションを実行中ではないと判定したならば（Ａ２３：ＮＯ）、制御部２１は、着金プッシュ通知処理を行う（Ａ２５）。具体的には、着金があった旨を報知するための着金プッシュ通知を、表示部２４の端末メイン画面に表示させる。

その後、制御部２１は、着金の詳細を確認するための着金プッシュ通知に対する操作がなされたか否かを判定し（Ａ２７）、なされたと判定したならば（Ａ２７：ＹＥＳ）、支払いアプリケーションを起動させる（Ａ２９）。そして、支払いアプリケーション処理部２１１が、着金情報等を含むトークルーム画面を表示部２４に表示させる（Ａ３１）。

一方、Ａ２３において支払いアプリケーションを実行中であると判定したならば（Ａ２３：ＹＥＳ）、支払いアプリケーション処理部２１１が、アプリ内着金通知処理を行う（Ａ３３）。具体的には、着金があった旨を報知するための着金通知を、表示部２４の支払いアプリケーション画面の所定領域に表示させる。

その後、支払いアプリケーション処理部２１１は、着金の詳細を確認するための操作がなされたか否かを判定し（Ａ３５）、なされたと判定したならば（Ａ３５：ＹＥＳ）、Ａ３１へと処理を移す。

ここで、Ａ３１では、限定ではなく例として、図３－１８に例示したようなトークルーム画面を表示部２４に表示させるようにすることができる。ただし、本実施例では、支払いアプリケーション内で送金サービスが提供されるため、このトークルーム画面は、支払いアプリケーションのアカウント（例えば支払いアプリケーションＩＤ）に基づいて表示部２４に表示されるとも言えるし、送金サービスのアカウント（例えばアカウント番号によって特定されるアカウント）に基づいて表示部２４に表示されるとも言える。

Ｂ３１の後、または、送金可否判定処理で送金が不可であると判定した場合（Ｂ２５：ＮＯ）、送金サービス管理処理部１１１１は、通信Ｉ／Ｆ２２によって、ＡＰＩを介して、送金レスポンスを送金指示サーバ４０に送信する（Ｂ３３）。

具体的には、送金に成功した場合は、限定ではなく例として、送金ＯＫ（成功）を示すリターンコード（例えば「００００」）と、送金ＯＫの旨の返答メッセージと、サーバ１０側でユニークに生成したトランザクションＩＤとを含む送金レスポンスを、ＡＰＩを介して、送金指示サーバ４０に送信する。

一方、送金に失敗した場合は、限定ではなく例として、送金ＮＧ（失敗）を示すリターンコードと、送金ＮＧの理由（送金失敗の理由）と、サーバ１０側でユニークに生成したトランザクションＩＤとを含む送金レスポンスを、ＡＰＩを介して、送金指示サーバ４０に送信する。

ここで、送金ＮＧ（失敗）を示すリターンコードは、送金ＮＧの理由（失敗の理由）に応じて異なる数字のコードとすることができる。送金が不可となる理由としては、例えば、入力情報（送金先のユーザのアカウント番号と追加認証情報とのうちの少なくともいずれか）が誤っていること、送金先のユーザのステータスや残高制限等の理由で送金することができないこと、送金依頼金額の情報がエラーであること、送金依頼金額が送金可能額を超えていること、といった複数の理由が想定される。これら複数の理由それぞれに関連付けて異なる数字のリターンコードを設定しておき、対応する理由に応じたリターンコードを含めて送金条件情報レスポンスを送信するとよい。

Ａ３１の後、または、Ａ３５において表示しないと判定した場合（Ａ３５：ＮＯ）、制御部２１は、支払いアプリケーションを実行中であるか否かを判定する（Ａ４１）。そして、実行中であると判定したならば（Ａ４１：ＹＥＳ）、支払いアプリケーション処理部２１１が、「出金」の機能が選択されたか否かを判定する（Ａ４３）。この場合、端末２０のユーザは、限定ではなく例として、ＡＴＭの表示画面に表示される「スマートフォンでの取引」のアイコンをタップする。

「出金」の機能が選択されたと判定したならば（Ａ４３：ＹＥＳ）、支払いアプリケーション処理部２１１は、銀行・銀行口座を選択させるための画面（不図示）や、出金額を入力させるための画面（不図示）を表示部２４に表示させる。そして、これらの画面において入力された情報を出金用情報として、通信Ｉ／Ｆ２２によってサーバ１０に送信する（Ａ４５）。

通信Ｉ／Ｆ１４によって端末２０から出金用情報を受信すると（Ｂ４１）、サーバ１０の電子マネー管理処理部１１１３は、出金可否判定処理を行う（Ｂ４３）。具体的には、限定ではなく例として、出金用情報の送信元の端末２０または端末２０のユーザのアカウントのアカウント種別が「マネーアカウント」であるか否かを判定する。また、この端末２０または端末２０のユーザの電子マネー口座残高が出金額よりも多いか否かを判定する。そして、これらの条件を満たす場合、「出金可能」と判定する。

出金可能と判定したならば（Ｂ４５：ＹＥＳ）、電子マネー管理処理部１１１３は、出金処理を行う（Ｂ４７）。具体的には、銀行サーバ６０と通信を行い、電子マネー口座から出金額を減算して銀行口座残高に加算させる。また、電子マネー管理処理部１１１３は、限定ではなく例として、現金の引き出しの取引に必要な情報（以下、「取引用情報」と称す。）を、通信Ｉ／Ｆ１４によって銀行サーバ６０に送信する。この場合、銀行サーバ６０は、ＡＴＭと通信を行い、限定ではなく例として、現金の引き出しの取引用のコード画像（以下、「取引用コード画像」と称す。）をＡＴＭのディスプレイに表示させる。

ここで、取引用コード画像は、限定ではなく例として、二次元コード（例えばＱＲコード（登録商標））の画像とすることができる。また、取引用コード画像には、限定ではなく例として、上記の取引用情報を取引用コード情報として含めるようにしてもよいし、サーバ１０と通信を行って取引用情報を取得するための情報を取引用コード情報として含めるようにしてもよい。

Ａ４５の後、支払いアプリケーション処理部２１１は、支払いアプリケーションの機能として備えられたコードリーダ（以下、「アプリケーションコードリーダ」と称す。）を起動させる（Ａ４７）。

アプリケーションコードリーダによって、ＡＴＭのディスプレイに表示された取引用コード画像が読み取られると（Ａ４９：ＹＥＳ）、支払いアプリケーション処理部２１１は、読み取られた取引用コード画像に含まれる取引用コード情報を、デコードによって取得する（Ａ５１）。

その後、支払いアプリケーション処理部２１１は、取得した取引用コード情報に基づき、現金を引き出すために必要な情報（例えば、送金サービスの事業者を識別するための事業者番号や認証番号）を表示部２４に表示させる（Ａ５３）。この場合、端末２０のユーザは、表示部２４に表示された情報をＡＴＭに入力して、銀行口座から現金を引き出す。

なお、取引用情報が取引用コード画像にエンコードされている場合は、デコードによって直接的に取得した取引用情報に基づき、現金を引き出すために必要な情報を表示部２４に表示させればよい。また、サーバ１０と通信を行って取引用情報を取得するための情報が取引用コード画像にエンコードされている場合は、デコードによって取得した情報に基づきサーバ１０から取引用情報を取得する処理を実行し、この処理によって取得した取引用情報に基づいて、現金を引き出すために必要な情報を表示部２４に表示させればよい。

なお、ここでは送金者から受けとった電子マネーを「出金」する場合の処理を示した。それに加えて送金者から受けとった電子マネーを「決済」、「送金」、「外貨両替」のための電子マネーとしても活用することができる。これらの処理の詳細な説明は省略する。

Ａ５３の後、制御部２１は、処理を終了するか否かを判定し（Ａ５９）、処理を継続すると判定したならば（Ａ５９：ＮＯ）、Ａ１に処理を戻す。一方、処理を終了すると判定したならば（Ａ５９：ＹＥＳ）、端末メイン処理を終了する。

Ｂ４７の後、支払いアプリケーション管理処理部１１１は、処理を終了するか否かを判定し（Ｂ５９）、処理を継続すると判定したならば（Ｂ５９：ＮＯ）、Ｂ１に処理を戻す。一方、処理を終了すると判定したならば（Ｂ５９：ＹＥＳ）、支払いアプリケーション管理処理を終了する。

Ｃ２３の後、制御部４１は、処理を終了するか否かを判定し（Ｃ５９）、処理を継続すると判定したならば（Ｃ５９：ＮＯ）、Ｃ１に処理を戻す。一方、処理を終了すると判定したならば（Ｃ５９：ＹＥＳ）、送金指示サーバメイン処理を終了する。

＜実施例の効果＞
本実施例は、サーバ１０（限定ではなく、第１のサーバの一例）が、通信Ｉ／Ｆ１４（限定ではなく、第１のサーバの通信部の一例）によって、ＡＰＩ(Application Programming Interface)を介して、送金条件情報（限定ではなく、電子マネーの送金の条件に関する情報の一例）を送金指示サーバ４０（限定ではなく、第２のサーバの一例）に送信する。また、サーバ１０は、通信Ｉ／Ｆ１４によって、ＡＰＩを介して、アカウント番号（限定ではなく、識別子の一例）によって特定されるアカウント（限定ではなく、第１のアカウントの一例）へ送金者のアカウント（例えばチャンネルＩＤ）（限定ではなく、第２のアカウントの一例）の指示によって、電子マネーを送金の条件に従って送金する構成を示している。
このような構成により得られる効果の一例として、第１のサーバは、ＡＰＩを介して、電子マネーの送金の条件に関する情報を第２のサーバに通知することができる。また、第１のサーバは、ＡＰＩを介して、識別子によって特定される第１のアカウントへ第２のアカウントの指示によって電子マネーを送金の条件に従って送金することができる。

例えば、第１のアカウントは、第１のサーバを運用する事業者が提供するサービスを利用する端末または端末のユーザのアカウントとすることができる。また、例えば、第２のサーバは、企業や法人等が運用するサーバとすることができ、第２のアカウントは、第２のサーバまたは企業や法人等のアカウントとすることができる。このようにすることで、ＡＰＩを介して、企業や法人等から端末のユーザ宛の電子マネーの送金を実現することが可能となり、電子マネーの送金の汎用性を高めることができる。

また、本実施例は、電子マネーの送金の条件は、ＡＰＩを介して、アカウント番号によって特定されるアカウントへ送金者のアカウントの指示によって送金可能な送金可能額（限定ではなく、送金可能な電子マネーの金額に関する条件の一例）を含む構成を示している。
このような構成により得られる効果の一例として、送金可能な電子マネーの金額に関する条件に従って、ＡＰＩを介して、第１のアカウントへ第２のアカウントの指示によって電子マネーを送金することができる。

また、本実施例は、サーバ１０は、電子マネーを送金した場合、通信Ｉ／Ｆ１４によって、アカウント番号から特定されるアカウントに通知を行う構成を示している。
このような構成により得られる効果の一例として、電子マネーが送金されたことを第１のアカウントに通知するため、電子マネーが送金されたことを第１のアカウントのユーザは知ることができ、至便である。

また、本実施例は、サーバ１０は、通信Ｉ／Ｆ１４によって、ＡＰＩを介して、追加認証情報（限定ではなく、識別子とは異なる情報の一例）を送金指示サーバ４０から受信する。そして、サーバ１０は、通信Ｉ／Ｆ１４によって、ＡＰＩを介して、アカウント番号と、追加認証情報とによって特定されるアカウントへ電子マネーを送金する構成を示している。
このような構成により得られる効果の一例として、識別子ばかりでなく、ＡＰＩを介して、第２のサーバから受信した識別子とは異なる情報によって電子マネーを送金する第１のアカウントを特定することで、例えば、送金予定のアカウントとは異なるアカウントへ電子マネーを送金してしまうような事態が発生することを防止できる。

また、本実施例は、サーバ１０は、記憶部１５で、アカウント番号から特定されるアカウントの電子マネー口座の残高に、電子マネーの送金依頼金額（限定ではなく、送金する電子マネーの金額の一例）を関連付けて記憶させる構成を示している。
このような構成により得られる効果の一例として、第１のサーバの記憶部で、第１のアカウントの電子マネー口座の残高に、送金する電子マネーの金額を関連付けて記憶させるため、電子マネーの金額を第１のサーバで管理することができる。

また、本実施例は、サーバ１０は、電子マネーによる決済のみが可能なキャッシュアカウント（限定ではなく、電子マネーの一部の用途が制限される制限アカウントの一例）と、電子マネーによる決済、送金、出金、外貨両替が可能なマネーアカウント（限定ではなく、電子マネーの一部の用途が制限されない非制限アカウントの一例）とのいずれかのアカウントによって、アカウントを管理する構成を示している。
このような構成により得られる効果の一例として、電子マネーの一部の用途が制限される制限アカウントと、電子マネーの一部の用途が制限されない非制限アカウントとのいずれかのアカウントによって、第１のアカウントを管理することができるため、電子マネーの用途に応じた適切なアカウントで電子マネーを管理することができる。

また、本実施例は、サーバ１０は、キャッシュアカウントと、マネーアカウントとのいずれかのアカウントの電子マネー口座の残高に、送金する電子マネーの金額を関連付けて記憶させるため、送金する電子マネーの金額を、アカウントの種類に応じて適切に関連付けることができる。

また、本実施例は、ＡＰＩを介した送金指示サーバ４０との通信に基づき、アカウント番号によって特定されるアカウントへ送金者のアカウントの指示によって電子マネーを送金したことを示す通知（通知情報）を、端末２０が、通信Ｉ／Ｆ２２によってサーバ１０から受信する。そして、端末２０は、受信した通知に基づく表示を、表示部２４に行う構成を示している。
このような構成により得られる効果の一例として、ＡＰＩを介した第２のサーバとの通信に基づき、識別子によって特定される第１のアカウントへ第２のアカウントの指示によって電子マネーが送金されたことを、端末のユーザに報知することができる。

また、本実施例は、端末２０が、送金サービスのアカウント（限定ではなく、第１のアカウントの一例）、または支払いアプリケーションのアカウント（限定ではなく、第１のアカウントと関連付けられたアカウントの一例）によって端末２０で実行される支払いアプリケーションのトークルーム画面（限定ではなく、メッセージングアプリケーションの表示領域の一例）に、着金情報等を表示させる構成を示している。
このような構成により得られる効果の一例として、第１のサーバから受信した、電子マネーを送金したことを示す情報に基づく表示を、第１のアカウント、または第１のアカウントと関連付けられたアカウントによって端末で実行されるメッセージングアプリケーションの表示領域に行うため、電子マネーが送金されたことを、分かり易い形で端末のユーザに報知することができる。

また、本実施例は、端末２０が、アプリケーションコードリーダ（限定ではなく、端末のコードリーダの一例）を制御して、ＡＴＭ（限定ではなく、現金自動支払機の一例）に表示される取引用コード画像（限定ではなく、第１のサーバによって管理される第１のアカウントに関連付けられた電子マネーの残高に基づき、銀行口座から現金を引き出すための現金自動支払機に表示されるコード画像の一例）を読み取る。そして、端末２０は、読み取られた取引用コード画像に含まれる取引用コード情報（限定ではなく、コード情報の一例）に基づいて、現金を引き出すために必要な情報をサーバ１０から取得する処理（限定ではなく、現金自動支払機から現金を引き出すための処理の一例）や、現金を引き出すために必要な情報を表示部２４に表示させる処理（限定ではなく、現金自動支払機から現金を引き出すための処理の一例）を実行する構成を示している。
このような構成により得られる効果の一例として、端末のユーザは、送金された電子マネーの金額を、自身の銀行口座から簡単に引き出すことができる。

また、本実施例は、送金指示サーバ４０が、通信Ｉ／Ｆ４４によって、ＡＰＩを介して、電子マネーの送金条件情報をサーバ１０から受信する。そして、送金指示サーバ４０が、通信Ｉ／Ｆ４４によって、ＡＰＩを介して、アカウント番号によって特定されるアカウントへ送金者のアカウントの指示によって電子マネーを送金の条件に従って送金するための送金依頼情報をサーバ１０に送信する構成を示している。
このような構成により得られる効果の一例として、第２のサーバは、ＡＰＩを介して、電子マネーの送金の条件に関する情報を第１のサーバから取得することができる。また、第２のサーバは、ＡＰＩを介して、識別子によって特定される第１のアカウントへ第２のアカウントの指示によって電子マネーを送金の条件に従って送金するための情報を第１のサーバに送信することによって、電子マネーを送金させることができる。

また、本実施例は、電子マネーの送金の条件は、ＡＰＩを介して、アカウント番号によって特定されるアカウントへ送金者のアカウントの指示によって送金可能な送金可能額（限定ではなく、送金可能な電子マネーの金額に関する条件の一例）を含む構成を示している。
このような構成により得られる効果の一例として、送金可能な電子マネーの金額に関する条件に従って、ＡＰＩを介して、第１のアカウントへ第２のアカウントの指示によって電子マネーを送金することができる。

また、本実施例は、送金指示サーバ４０は、送金条件情報確認画面の表示（限定ではなく、送金の条件に関する情報に基づく表示の一例）を、ディスプレイ４３に行う構成を示している。
このような構成により得られる効果の一例として、電子マネーの送金の条件に関する情報を、表示によって第２のサーバの管理者等に報知することができる。

＜変形例＞
以下、上記の実施例の変形例について説明する。

＜変形例（１）＞
上記の実施例では、サーバ１０上の口座で管理される貨幣を「電子マネー（電子貨幣）」とし、銀行サーバ６０（銀行）の口座で管理される貨幣を「デジタル通貨（デジタル貨幣）」として区別した。しかしながら、両者を区別せず、両方とも「電子マネー」としてもよいし、両方とも「デジタル通貨（デジタル貨幣）」としてもよい。

また、「電子マネー」または「デジタル通貨」として、法定通貨を用いてもよいし、仮想通貨を用いてもよい。また、「電子マネー」または「デジタル通貨」には、暗号通貨を含めてもよいし、含めなくてもよい。また、仮想通貨には、クーポンなどの物的貨幣を含めてもよいし、含めなくてもよい。

＜変形例（２）＞
上記の実施例で説明した通信システム１の構成は、適宜変更可能である。例えば、送金者と、送金サービスの事業者との間に、金銭の振り込みを代行する振込代行業者を介在させるようにし、サーバ１０や送金指示サーバ４０の他に、振込代行業者が運用・管理するサーバを設けるようにしてもよい。

＜変形例（３）＞
送金者のアカウントの指示によって電子マネーを送金する送金先の端末２０または端末２０のユーザのアカウントを、限定するようにしてもよいし、そのようにしなくてもよい。この場合、限定ではなく例として、送金者の意向に応じて、サーバ１０側でその設定を行うようにすることができる。

図３－２５は、この場合にサーバ１０の記憶部１５に記憶される送金者登録データ１５５Ｂのデータ構成の一例を示す図である。送金者登録データ１５５Ｂは、送金者登録データ１５５（図３－５参照）と同様に、サーバ１０で送金者の登録情報を管理するためのデータであるが、データ構成が一部異なっている。

具体的には、送金者登録データ１５５Ｂには、区分、送金者名称、送金者連絡先情報、送金者ＩＤ、その他登録情報に加えて、送金先限定設定が関連付けて記憶されている。

送金先限定設定は、電子マネーの送金先のアカウント種別を限定する（絞り込む）か否かに関する設定である。例えば、送金先限定設定が「ＯＮ」に設定されている送金者は、電子マネーの送金先のアカウント種別が「マネーアカウント」に限定される。つまり、送金先限定設定が「ＯＮ」に設定されている送金者は、アカウント種別が「マネーアカウント」であるユーザ宛の電子マネーの送金は許可されるが、アカウント種別が「キャッシュアカウント」であるユーザ宛の電子マネーの送金は禁止される。

この場合、サーバ１０の制御部１１は、限定ではなく例として、支払いアプリケーション管理処理（図３－２２～図３－２４）の送金可否判定処理（Ｂ２３）において、送金者登録データ１５５Ｂを参照し、送金リクエストの送信元の送金指示サーバ４０の送金者ＩＤに関連付けて記憶されている送金先限定設定を判定する。

送金先限定設定が「ＯＦＦ」である場合、制御部１１は、「送金可能」と判定する。一方、送金先限定設定が「ＯＮ」である場合、制御部１１は、送金サービスアカウントデータ１５４を参照し、送金指示サーバ４０から受信した送金リクエストの入力情報に含まれるアカウント番号（電子マネーの送金先のアカウントのアカウント番号）に関連付けて記憶されているアカウント種別を判定する。

関連付けて記憶されているアカウント種別が「マネー」である場合、制御部１１は、「送金可能」と判定する。一方、アカウント種別が「キャッシュ」である場合、制御部１１は、「送金不可」と判定する。

本変形例は、サーバ１０が、送金者のアカウント（限定ではなく、第２のアカウントの一例）が、電子マネーの送金先を限定する（絞り込む）設定がなされたアカウントであるか否かを判定する。そして、サーバ１０は、電子マネーの送金先を限定する設定がなされたアカウントである場合、マネーアカウントへの送金者のアカウントの指示に基づく電子マネーの送金を許可し、キャッシュアカウントへの送金者のアカウントの指示に基づく電子マネーの送金を禁止する。
このような構成により得られる効果の一例として、特定の送金用途で送金する場合に送金先の本人確認が必須である法律や規則が存在する場合に、キャッシュアカウントへの送金者のアカウントの指示に基づく電子マネーの送金を禁止することで、法律や規則への対応を実現することができる。

＜変形例（４）＞
上記の実施例では、送金サービスを、送金者から送金サービスの事業者に保証金を事前に預け入れ、送金サービスの事業者が、送金した電子マネーの金額を事後精算して送金者に請求して返済してもらうサービスとしたが、これに限定されない。

限定ではなく例として、送金者から送金サービスの事業者に送金用の金銭を事前に預けておき、送金サービスの事業者が、事前に預けられた金銭の残高の範囲内で、電子マネーを送金するサービスとすることもできる。

この場合、サーバ１０は、送金実行前に、送金依頼金額が残高の範囲内であるか否かを判定し、残高の範囲内である場合に、送金を実行するようにすればよい。また、この場合、サーバ１０が、送金実行前に、現在の残高を送金指示サーバ４０に送信して、送金者に通知するようにしてもよい。

また、限定ではなく例として、資金移動残高を送金指示サーバ４０で記憶・管理するようにし、送金指示サーバ４０が、サーバ１０を介して、資金移動残高から限度額分の電子マネーを送金することを可能とするシステムを構成してもよい。

＜変形例（５）＞
上記の実施例では、端末２０または端末２０のユーザのアカウントを「キャッシュアカウント」と「マネーアカウント」とに区別したが、これらを区別しないようにしてもよい。すなわち、全てのユーザの本人確認を必須として全てのユーザをマネーアカウントとするか、または本人確認はできないようにして全てのユーザをキャッシュアカウントとしてもよい。

また、上記の実施例では、「キャッシュアカウント」と「マネーアカウント」とのうちのいずれか一方のアカウントのみを端末２０または端末２０のユーザが所有することとしてが、これに代えて、「キャッシュアカウント」と「マネーアカウント」との両方のアカウントを端末２０または端末２０のユーザが所有することができるようにしてもよい。

また、アカウントの種別に応じて、送金者から送金可能な電子マネーの金額を制限するようにしてもよい。例えば、「キャッシュアカウント」に対する電子マネーの送金の上限額は「１０万円」に設定し、「マネーアカウント」に対する電子マネーの送金の上限額は「１００万円」に設定するなどしてもよい。

＜変形例（６）＞
上記の実施例では、受取申請ページにおいて端末２０のユーザによって受け取りが申請されるごとに、電子マネーを送金する都度送金（都度払い）の手法を説明したが、これに限定されない。

具体的には、例えば、給料の支払いなど、定期的なタイミングで送金を行うユーザについては、送金指示サーバ４０が、送金日や送金する金額等の情報をサーバ１０に事前に登録しておくようにする。そして、サーバ１０が、事前に登録された情報に基づいて、定期的なタイミングで電子マネーを送金するようにしてもよい。つまり、定期送金（定期払い）の手法を適用してもよい。

＜変形例（７）＞
上記の実施例では、追加認証情報を端末電話番号下４桁として例示したが、追加認証情報はこれに限られない。サーバ１０で取得・把握することのできる端末２０または端末２０のユーザに関する情報であって、アカウント番号と異なる情報であれば、どのような情報を追加認証情報としてもよい。

例えば、端末２０のユーザに、秘密の質問に対する答えを入力させ、その情報をサーバ１０で登録しておく。そして、送金者の受取申請ページにおいて、追加認証情報として秘密の質問の答えを入力させるようにし、サーバ１０が、送金指示サーバ４０から受信した秘密の質問の答えと、登録している秘密の質問の答えとに基づいて、追加認証を行うようにしてもよい。

あるいは送金者のウェブページにアクセス後に所定のボタンを押下すると端末２０で支払いアプリケーションが起動し、起動した支払いアプリケーションから取得したトークンを、送金者を介してサーバ１０に送信することで、送金先のユーザを特定するように構成しても構わない。

＜変形例（８）＞
上記の実施例で説明した送金条件情報はあくまでも一例に過ぎず、これに限定されない。例えば、送金者が一定期間（１日、３日、１週間等）に送金することのできる電子マネーの金額、例えば、１日あたりの送金限度額、３日の期間の送金限度額、１週間の期間の送金限度額といった、一定期間の送金限度額の情報を、サーバ１０または送金指示サーバ４０で送金条件情報に含めて設定するようにしてもよい。そして、一定期間の送金限度額の情報を送金指示サーバ４０やサーバ１０に表示させるなどして報知したり、一定期間の送金限度額を超えない範囲での送金を許可する処理（または、一定期間の送金限度額を超える範囲での送金を禁止する処理）を送金指示サーバ４０側やサーバ１０側で行うようにしてもよい。

＜変形例（９）＞
上記の実施例において、サーバ１０が、前述したＩＭＳ等のメッセージングサービスを提供する機能と、支払いアプリケーションによって各種のサービスを提供する機能とを有するようにしてもよい。この場合、限定ではなく例として、ＩＭＳアプリケーション内で、支払いアプリケーションのサービスや、送金サービスを提供するようにしてもよい。

また、メッセージングサービスを提供する機能を有するサーバと、支払いアプリケーションによる各種のサービスを提供する機能を有するサーバとを別体とし、メッセージングサービスサーバと、支払いサービスサーバとの２つのサーバを構成するようにしてもよい。

１ 通信システム
１０ サーバ
２０ 端末
３０ ネットワーク
４０ 送金指示サーバ
６０ 銀行サーバ

Claims (7)

1. 第１のサーバの通信部によって、ＡＰＩ(Application Programming Interface)を介して、電子マネーの送金の条件に関する情報を第２のサーバに送信することと、
   前記第１のサーバの通信部によって、ＡＰＩを介して、識別子によって特定される第１のアカウントへ電子マネーを前記送金の条件に従って、第２のアカウントの指示によって送金することと、を含み、
   前記送金することは、前記第１のサーバの記憶部で、前記第１のアカウントの電子マネーの残高に、送金する電子マネーの金額を関連付けて記憶させることを含み、
   電子マネーの一部の用途が制限される制限アカウントと、電子マネーの一部の用途が制限されない非制限アカウントとのいずれかのアカウントによって、前記第１のアカウントを管理することと、
   前記第２のアカウントが、電子マネーの送金先を限定するアカウントであるか否かを判定することと、
   電子マネーの送金先を限定するアカウントである場合、前記非制限アカウントへの電子マネーの送金を許可し、前記制限アカウントへの電子マネーの送金を禁止することと、を含む、
   前記第１のサーバの制御方法。
2. 請求項１に記載の制御方法であって、
   前記記憶させることは、前記制限アカウントと、前記非制限アカウントとのいずれかのアカウントの電子マネーの残高に、送金する電子マネーの金額を関連付けて記憶させることを含む、
   制御方法。
3. 請求項１または請求項２に記載の制御方法であって、
   前記送金の条件は、送金可能な電子マネーの金額に関する条件を含む、
   制御方法。
4. 請求項１から請求項３のいずれか一項に記載の制御方法であって、
   前記電子マネーを送金した場合、前記第１のサーバの通信部によって、前記第１のアカウントに通知を行うことを含む、
   制御方法。
5. 請求項１から請求項４のいずれか一項に記載の制御方法であって、
   前記第１のサーバの通信部によって、ＡＰＩを介して、前記識別子とは異なる情報を前記第２のサーバから受信することを含み、
   前記送金することは、前記第１のサーバの通信部によって、ＡＰＩを介して、前記識別子と、前記異なる情報とによって特定される第１のアカウントへ電子マネーを送金することを含む、
   制御方法。
6. 第１のサーバの通信部によって、ＡＰＩを介して、電子マネーの送金の条件に関する情報を第２のサーバに送信することと、
   前記第１のサーバの通信部によって、ＡＰＩを介して、識別子によって特定される第１のアカウントへ電子マネーを前記送金の条件に従って、第２のアカウントの指示によって送金することと、を含み、
   前記送金することは、前記第１のサーバの記憶部で、前記第１のアカウントの電子マネーの残高に、送金する電子マネーの金額を関連付けて記憶させることを含み、
   電子マネーの一部の用途が制限される制限アカウントと、電子マネーの一部の用途が制限されない非制限アカウントとのいずれかのアカウントによって、前記第１のアカウントを管理することと、
   前記第２のアカウントが、電子マネーの送金先を限定するアカウントであるか否かを判定することと、
   電子マネーの送金先を限定するアカウントである場合、前記非制限アカウントへの電子マネーの送金を許可し、前記制限アカウントへの電子マネーの送金を禁止することと、
   を前記第１のサーバに実行させるためのプログラム。
7. 記憶部と、
   ＡＰＩを介して、電子マネーの送金の条件に関する情報を第２のサーバに送信する通信部と、
   ＡＰＩを介して、識別子によって特定される第１のアカウントへ電子マネーを前記送金の条件に従って、第２のアカウントの指示によって、前記記憶部で、前記第１のアカウントの電子マネーの残高に、送金する電子マネーの金額を関連付けて記憶させる制御部と、を備え、
   前記制御部は、
   電子マネーの一部の用途が制限される制限アカウントと、電子マネーの一部の用途が制限されない非制限アカウントとのいずれかのアカウントによって、前記第１のアカウントを管理し、
   前記第２のアカウントが、電子マネーの送金先を限定するアカウントであるか否かを判定し、
   電子マネーの送金先を限定するアカウントである場合、前記非制限アカウントへの電子マネーの送金を許可し、前記制限アカウントへの電子マネーの送金を禁止する、
   第１のサーバ。

Images