JP2021125263A - 金融商品取引システム、プログラム及び金融商品取引方法 - Google Patents

Abstract

【課題】電子有価財をユーザに即座に受け渡すことで即時に金融商品の換金を可能とする金融商品取引システムとそれに用いられるプログラム及び金融商品取引方法の提供する。
【解決手段】ユーザ端末３０と情報処理装置（投信取引サーバ４０、電子マネー会社サーバ６０）を備えた投信取引システムであって、投信取引サーバは、ユーザ端末における操作に基づいて、ユーザが保有する投資信託の換金の申込みを受け付ける申込受付部４０２と、申込受付部により投資信託の換金の申込みを受け付けた場合に、前記申込みを受け付けたときより前の時点における基準価額を取引基準価格として決定する取引基準価格決定部４０６と、取引基準価格決定部により決定した基準価額に基づいて投資信託の対価を算出する対価算出部４０３と、対価算出部により算出した対価に相当する電子マネー等を投資信託の換金の代金としてユーザに受け渡す処理を実行する代金受渡部と、を備える。
【選択図】図９

Description

本発明は、金融商品の取引に関する処理を実行する金融商品取引システムと、それに用いられるプログラム及び金融商品取引方法に関する。

従来から、株式、ＦＸ（Foreign Exchange：外国為替証拠金取引）、債券、投資信託、不動産、先物、金相場、預金及び外貨預金等の金融商品（以下、「商品」ともいう）が知られている。
例えば、投資信託は、投資信託委託会社（以下、「委託会社」という）が、投資家から集めた資金を基に株式、債権、不動産等への投資・運用を行い、これにより得られた利益を投資家に還元する仕組みとなっている。
また、投資信託では、投資家は、商品である投資信託受益証券（受益権ともいう）を任意のタイミングで換金することができる。
以下、換金の手順を説明する。なお、「換金」には、証券会社などの販売会社に投資信託受益証券を買い取ってもらう「買取」による方法と、販売会社を通して、信託財産の一部を解約する「解約」による方法とがある。ここでは、「解約」による方法を例示して説明するが、「買取」による方法もほぼ同様の手順であることから詳細な説明は省略する。
（ａ）投資家が、販売会社に換金を申し込む。
（ｂ）販売会社は、商品（投資信託受益証券）の換金申込みがあった場合、投資信託受益証券の発行者である委託会社に一部解約の連絡をする。ただし、解約代金の確定値の連絡は、解約基準価額の算定日（約定日）の翌営業日になる。（投資信託の解約基準価額は、投資家の換金の申込日又はその翌営業日の基準価額を時価として算出する。投資家の換金額（解約代金）は、解約基準価額により算出される。）
（ｃ）委託会社は、販売会社から一部解約の連絡を受け付けると、解約代金の計算をした上で信託銀行（受託会社）に一部解約の指図を行う。ただし、指図を行うのは、解約基準価額の算定日（約定日）の翌営業日になる。
（ｄ）受託会社は、受け付けた一部解約の指図に係る支払い開始日に、解約代金を投資信託の信託口座から委託会社の口座に振り替える。
（ｅ）委託会社は、（ｄ）で振り替えられた解約代金を、販売会社に送金し、販売会社が投資家の指定口座に解約代金を振り込む等により換金処理が終了する。
例えば、特許文献１には、投資信託の解約に関する各種処理を行うシステムが開示されている。

特開２００５−２６６８８９号公報

しかしながら、従来のシステムでは、以下の理由から換金に時間が掛かっていた。
具体的には、委託会社は、投資家から（販売会社を通じて）解約の申込みを受け付けた場合、解約代金の支払開始日に当該解約代金を（販売会社を通じて）支払うことになるが、そのためには、投資信託の信託財産から解約代金相当額を出金する必要がある。
具体的には、投資信託の信託財産は、運用方針に従い投資対象である資産（主に有価証券）を保有しており、解約の申込みを受け付けた場合は、保有する資産を売却して現金化する必要がある。
そのため、保有資産の売却に必要な期間を考慮して解約代金の支払い開始日が設定されているために時間が掛かっていた。
特に、主要投資先が海外の場合、海外市場の休業日も考慮されて支払開始日が設定される。また、時差の関係により、解約申込日における投資信託が保有する資産の海外市場の時価の取り込みが翌営業日になることから、翌営業日の基準価額を当該解約申込日の時価として採用するため、主要投資先が国内の場合に比べ１営業日余計に掛かる。
このため、主要投資先が海外の場合、実際には、以下に示すように、「解約申込日（Ｔ日）」から「支払開始日」までには、最低５営業日掛かっていた。
Ｔ日：顧客の申込日（解約申込日）
Ｔ＋１営業日：解約基準価額の算出日（約定日）
Ｔ＋２営業日：解約代金の確定、保有資産の売却の発注（２〜３営業日）
Ｔ＋５営業日：保有資産の受渡し、支払い開始日

また、この種の金融商品の取引には多くの機関が関与しており、上記（ａ）〜（ｅ）に示すように、各機関における処理を順序通り直列的に行う結果、一連の換金処理を完了するのに相当の期間を要していた。

また、投資信託の換金の申込みには締め切り時刻（多くは１５:００）が設定されており、その日の基準価額は、締め切り後の夜間に算出されるため、ユーザは、正確な基準価額を把握せずに売買の申込みを行わなければならなかった（ブラインド方式）。
ブラインド方式は、基準価額が確定・公表された後に投資信託の取引ができるとすると、投資信託を保有している投資家の利益が阻害されるおそれがあることから、これを防止するため、すなわち、公平性確保のために採用されている方式である。
しかしながら、ブラインド方式を採用するゆえに、申込後にすぐに対価の算出など取引内容を確定することができず、このことも出金処理を遅らせる原因にもなっていた。

本発明は、以上のような従来の技術が有する課題を解決するために提案されたものであり、投資信託などの金融商品の換金において、換金申込時における直前の既知の時価に基づいて商品の対価を即座に算出するとともに、現金の代わりに電子マネーなどの電子有価財をユーザに即座に受け渡すことで、即時の換金を可能とする金融商品取引システムとそれに用いられるプログラム及び金融商品取引方法の提供を目的とする。

上記目的を達成するため、本発明の金融商品取引システムは、ユーザ端末と情報処理装置とを備えた金融商品取引システムであって、前記情報処理装置は、前記ユーザ端末における操作に基づいて、ユーザが保有する金融商品の換金の申込みを受け付ける申込受付部と、前記申込受付部により金融商品の換金の申込みを受け付けた場合に、前記申込みを受け付けたときより前の時点における時価を取引基準価格として決定する取引基準価格決定部と、前記取引基準価格決定部により決定した取引基準価格に基づいて前記金融商品の対価を算出する対価算出部と、前記対価算出部により算出した対価に相当する所定の電子有価財を、前記金融商品の換金の代金として前記ユーザに受け渡す処理を実行する代金受渡部と、を備えた構成としてある。

また、本発明は、上記のような本発明に情報処理装置で実行されるプログラムとして構成することができる。
さらに、本発明は、上記のような本発明に係る情報処理装置によって実施可能な金融商品取引方法として構成することもできる。

本発明によれば、投資信託等の金融商品を換金する場合の代金を即時にユーザに受け渡すことができる。

資金運用支援システムの全体構成を示す図である。 家計簿サーバ装置及び資金運用支援サーバ装置のハードウェア構成を示す図である。 ユーザ端末のハードウェア構成を示す図である。 資金運用支援システムを実現する機能構成を示すブロック図である。 蓄積されている差額の一例を示す図である。 表示された承諾要求の一例を示す図である。 表示された差額の履歴の一例を示す図である。 本発明の金融商品取引システムの一実施形態に係る投信取引システムの全体構成を示す図である。 投信取引システムを実現する機能構成を示すブロック図である。 ユーザ情報ＤＢの一例を示す図表である。 口座情報ＤＢの一例を示す図表である。 基準価額ＤＢの一例を示す図表である。 ホーム画面の一例である。 出金方法選択画面の一例である。 出金内容入力画面の一例である。 出金内容確認画面の一例である。 出金手続完了画面の一例である。 ギフトＩＤ通知画面の一例である。 第１電子マネーの専用サイトのチャージ画面の第１の例である。 第１電子マネーの専用サイトのチャージ画面の第２の例である。 電子チャージ出金による換金処理を時系列に表したチャート図である。 従来の出金方法（現金による出金方法）と、本発明の出金方法（電子チャージによる出金方法）とを、時系列で比較できるように表した比較図である。 電子チャージ出金後の後処理等を説明するための図である。

以下、本発明の金融商品取引システムの実施形態について、図面を参照しつつ説明する。
ここで、金融商品取引システムは、プログラム（ソフトウェア）の命令によりコンピュータで実行される処理，手段，機能によって実現される。プログラムは、コンピュータの各構成要素に指令を送り、以下に示す本発明に係る所定の処理や機能等を行わせることができる。すなわち、本発明における各処理や手段，機能は、プログラムとコンピュータとが協働した具体的手段によって実現される。

なお、プログラムの全部又は一部は、例えば、磁気ディスク，光ディスク，半導体メモリ，その他任意のコンピュータで読取り可能な記録媒体により提供され、記録媒体から読み出されたプログラムがコンピュータにインストールされて実行される。また、プログラムは、記録媒体を介さず、通信回線を通じて直接にコンピュータにロードし実行することもできる。また、本発明に係る金融商品取引システムは、単一の情報処理装置（例えば１台のパーソナルコンピュータ等）で構成することもでき、複数の情報処理装置（例えば複数台のサーバコンピュータ群等）で構成することもできる。
以下、本発明の具体的な実施例について説明するが、本発明は、その技術的思想に含まれるものであれば種々変形、変更することが可能であり、以下の実施例に限定されるものではない。

説明の便宜上、まず、金融商品取引システムと連携する資金運用支援システムについて説明し、その後に、金融商品取引システムについて説明する。

［資金運用支援システム］
図１は資金運用支援システムの全体構成を示す図である。
資金運用支援システム１は、商取引（買い物）においてユーザがお金を支払った際に生じるお釣りを資金運用に充てることを支援するシステムである。ここでいうユーザは、お釣りを資金運用に充てるお釣り運用サービスを利用するユーザであり、資金運用支援システム１において登録されているユーザである。
ユーザの登録は、例えば、所定のアプリ又はウェブサイトから所定のユーザ情報（所望のユーザＩＤ及びパスワードなど）の入力等の申込みを行うことで実行される。
つまり、資金運用支援システム１におけるユーザ登録を行うことで、お釣り運用サービスのユーザとして登録が行われる。
資金運用支援システム１は、このお釣り運用サービスを提供する事業者が中心となって運用されている。

資金運用とは、利益を得る目的で資金を運用することであり、具体的には、株式、ＦＸ、債券、投資信託、不動産、先物、金相場、預金及び外貨預金等の金融商品に資金を投資することにより行われる。

商取引におけるお金の支払いとは、例えば店舗等で商品を購入する際に行われる支払いであるが、それ以外にも、電車の切符の購入、病院での治療費の支払い、光熱費や通信費のような毎月の使用料金の支払い及び住宅ローンのような分割払い等も含められる。なお、お釣り運用サービスとは関係なくユーザ自身が独自に行った資金運用のための支払い（例えばユーザが証券会社の金融商品を独自に購入する際に行う支払い）も、前述した「商取引におけるお金の支払い」に含めてもよい。

また、お釣り運用サービスにおける前記商取引におけるお金の支払いには、クレジットカード、電子マネー及び口座からの引き落とし等、１円単位で支払うため通常はお釣りが生じない決済手段によるものが含まれるが、お釣り運用サービスは、これらの支払いについても、仮に現金で１００円単位や１０００円単位で支払われたとしたら生じると想定されるお釣り（端数）を資金運用に充てることができるように各決済手段と連携がなされているものとする。
また、これらの決済手段は、クレジットカード会社、電子マネー会社、銀行の違いから様々あるが、これらのうち、上記連携によりお釣りを資金運用（投資）に充てる決済手段をユーザが登録できるものとする。
具体的には、ユーザは、お釣りを認識する決済手段を自身が使用するユーザ端末３０のアプリに登録することができる。

資金運用支援システム１は、ネットワーク２と、決済代行サーバ３と、銀行サーバ４と、銀行サーバ５と、資金運用サーバ装置６と、家計簿サーバ装置１０と、資金運用支援サーバ装置２０と、ユーザ端末３０とを備える。ネットワーク２は、移動体通信網及びインターネット等を含む通信システムであり、自システムに接続される装置同士のデータのやり取りを仲介する。ネットワーク２には、ユーザ端末３０以外の各装置が有線通信で接続されており、ユーザ端末３０が無線通信で接続されている。なお、ネットワーク２との接続は有線通信及び無線通信のどちらでもよい。

決済代行サーバ３は、商取引で発生する決済処理を代行する決済代行会社が運用するサーバである。
銀行サーバ４及び銀行サーバ５は、銀行の口座を管理する（詳細には口座に収められているお金を管理する）サーバであり、口座への入金処理及び口座からの出金処理を行う。
本実施形態において、銀行サーバ４は、ユーザが利用する銀行でユーザの利用可能なお金が収められた口座を管理するサーバであり、銀行サーバ５は、委託会社の運用のもと、投資の資金を管理する信託銀行の投信口座を管理するサーバであるものとする。

ここでいう「ユーザの利用可能なお金」とは、「お釣り運用サービス」において運用される資金の元手となり得るお金のことである。ユーザの利用可能なお金が収められた口座は、ユーザが開設した口座に限らない。例えばユーザが利用する証券会社、通信事業者、電力会社、ガス会社、決済代行会社、通信販売会社及びＣ２Ｃ（Consumer to Consumer）サービス会社等が利用する、ユーザが支払ったお金を収めるための口座であってもよい。また、ポイントサービスを提供している事業者がユーザに付与したポイントに相当するお金を収めている口座であってもよい。

各事業者との取り決めにより、ユーザがそれらの口座に支払額以上のお金を収めておくことで、余ったお金を資金運用に充てることができる。それらの場合、事業者の口座を保有する銀行の銀行サーバ、又は、各事業者がその口座を管理するために設けたサーバが、ユーザの利用可能なお金が収められた口座を管理するサーバとして用いられる。資金運用サーバ装置６は、銀行サーバ５が管理する投信口座の資金を運用する処理及び運用実態を資金運用支援サーバ装置２０に提供する処理等を実行する。

家計簿サーバ装置１０は、ユーザの家計情報を蓄積する装置である。家計情報には、少なくともユーザの支出を示す支出情報が含まれる。支出情報は、食費、被服費、娯楽費、医療費、交際費、教育費、車両費、光熱費及び住居費等を示す情報である。これらの支出には、厳密には家族などユーザと家計をともにする者の支出も含まれているが、本実施例では、そのような支出もユーザの支出として捉えるものとする。家計簿サーバ装置１０は、これらの支出情報を、ユーザ端末３０から取得したり、金融機関が提供する個人向けサイト（ユーザの口座を用いた取引の履歴が掲載されたサイト。例えばインターネットバンキングのサイト）から取得したりする。

資金運用支援サーバ装置２０は、お釣り運用サービスをユーザに提供するための処理を行う情報処理装置である。資金運用支援サーバ装置２０は、家計簿サーバ装置１０から支出情報を取得する処理、お釣りを算出する処理、お釣りを資金運用に充てることの承諾をユーザに要求する処理、及び、承諾が得られたお釣りと同等の金額をユーザ口座から資金運用用の投信口座に移すための処理等を行う。

ユーザ端末３０は、ユーザが利用する端末装置であり、例えばスマートフォン、タブレット端末又はパーソナルコンピュータ等である。ユーザ端末３０は、家計簿サーバ装置１０にアクセスする操作（ユーザＩＤ、パスワードの入力操作）の受け付け、ユーザの家計情報（特に支出情報）の入力操作の受付、蓄積された家計情報の表示、資金運用支援サーバ装置２０からの上記要求の表示、その要求に対して承諾・拒否のいずれかを回答する操作の受け付け、及び、回答結果の通知処理等を行う。

図２は家計簿サーバ装置１０及び資金運用支援サーバ装置２０のハードウェア構成を示す図である。
これらの装置は、いずれも、プロセッサ１１と、メモリ１２と、ストレージ１３と、通信装置１４と、入力装置１５と、出力装置１６とを備えるコンピュータである。プロセッサ１１は、オペレーティングシステムを動作させてコンピュータ全体を制御する。プロセッサ１１は、周辺装置とのインターフェース、制御装置、演算装置及びレジスタ等を含む中央処理装置（ＣＰＵ）を備える。

プロセッサ１１は、プログラム（プログラムコード）、ソフトウェアモジュール及びデータ等を、ストレージ１３や通信装置１４からメモリ１２に読み出し、これらに従って各種の処理を実行する。メモリ１２は、コンピュータが読み取り可能な記録媒体であり、例えば、ＲＯＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ及びＲＡＭ等である。

ストレージ１３は、コンピュータが読み取り可能な記録媒体であり、例えば、ハードディスクドライブ、フレキシブルディスク及びフラッシュメモリ等である。ストレージ１３は、補助記憶装置と呼ばれてもよい。通信装置１４は、有線及び／又は無線ネットワークを介してコンピュータ間の通信を行うためのハードウェア（送受信デバイス）であり、例えばネットワークデバイス、ネットワークコントローラ、ネットワークカード、通信モジュールなどともいう。

入力装置１５は、外部からの入力を受け付ける入力デバイス（例えば、キーボード、マウス、マイクロフォン、スイッチ、ボタン、センサなど）である。出力装置１６は、外部への出力を実施する出力デバイス（例えば、ディスプレイ、表示パネル、スピーカー、ＬＥＤランプなど）である。なお、入力装置１５及び出力装置１６は、一体となった構成（例えば、タッチスクリーン）であってもよい。

なお、一切の物理的な入力を待たず自律的かつ定期的に実行される処理（いわゆるバッチ処理）がこの入力に置き換わってもよいし、ユーザ端末３０がＧＰＳ（Global Positioning System）等の測位手段を備えている場合に、特定の位置が測定されたときに実行される処理がこの入力に置き換わってもよい。また、ワイヤレスネットワークに接続された物理ボタンが用いられてもよい（この物理ボタンを押すと貯まっているお釣りを資金運用に充てることの承諾を一括で行うなど）。また、上記のハードウェア構成は、仮想化されたリソースで提供されてもよい（各サーバ装置がクラウドコンピューティングシステム上に構築される場合など）。

図３はユーザ端末３０のハードウェア構成を示す図である。
ユーザ端末３０は、プロセッサ３１と、メモリ３２と、ストレージ３３と、通信装置３４と、入力装置３５と、出力装置３６と、撮像装置３７とを備えるコンピュータである。プロセッサ３１から出力装置３６までは、図２に示す同名の各装置と共通するハードウェアである。撮像装置３７は、レンズ及び撮像素子等を備え、レンズから入射する光が表す周囲の人物や光景を撮影する。撮像装置３７は、撮影した画像を示す画像データをプロセッサ３１に供給する。なお、ディスプレイ、表示パネルなどの表示デバイスを表示部３６とも称する。

資金運用支援システム１が備える各装置のプロセッサがプログラムを実行して各部を制御することで、以下に述べる機能が実現される。
図４は資金運用支援システム１が実現する機能構成を示す図である。

家計簿サーバ装置１０は、収入情報取得部１０１と、支出情報取得部１０２と、家計情報蓄積部１０３とを備える。
資金運用支援サーバ装置２０は、支払額取得部２０１と、差額算出部２０２と、差額取得部２０３と、差額蓄積部２０４と、要求時期判断部２０５と、承諾要求部２０６と、承諾可否受付部２０７と、撤回受付部２０８と、資金移動時期判断部２０９と、移動指示処理実行部２１０とを備える。
ユーザ端末３０は、レシート読取部３０１と、支出情報送信部３０２と、承諾要求表示部３０３と、承諾可否操作受付部３０４と、承諾可否通知部３０５と、履歴表示部３０６と、撤回操作受付部３０７と、撤回通知部３０８とを備える。

家計簿サーバ装置１０の収入情報取得部１０１は、ユーザの収入情報を取得する。本実施例では、口座の取引履歴を掲載した個人向けサイトへのアクセスに用いる情報（ＵＲＬ、ユーザＩＤ、パスワード等）を家計簿サーバ装置１０にユーザが予め登録しておく。

個人向けサイトでは、取引日、取引の種類（カード引き出し、カード預け入れ、振り込み及び引き落とし等）、取引先及び取引金額等の取引履歴が掲載されている。収入情報取得部１０１は、登録された情報を用いてユーザの取引履歴を読み出し、入金を示す取引履歴のうち決められた項目（「給料」及び「賞与」等）のものを、ユーザの収入情報として取得する。収入情報取得部１０１は、取得した収入情報を、ユーザのユーザＩＤとともに家計情報蓄積部１０３に供給する。

このユーザＩＤは、資金運用支援システム１で割り当てられているものであり、個人向けサイトへのアクセス用のユーザＩＤ及び家計簿サーバ装置１０にアクセスするためのユーザＩＤとは通常は異なっている。ただし、お釣り運用サービスを提供する事業者が家計簿サーバ装置１０も運用する場合やユーザ自身がユーザＩＤを決定する方法が採用されている場合などに、共通のユーザＩＤが用いられてもよい。

家計簿サーバ装置１０の支出情報取得部１０２は、ユーザの支出情報を取得する。支出情報取得部１０２は、例えば、上記の個人向けサイトから取引履歴を読み出し、出金を示す取引履歴のうち決められた項目（「引き落し」及び「振り込み」等）のものを、ユーザの支出情報として取得する。また、支出情報取得部１０２は、ユーザ端末３０から次のように送信されてくる情報を支出情報として取得する。

ユーザ端末３０のレシート読取部３０１は、自装置の撮像手段（撮像装置３７）でレシートを撮影することで、そのレシートに記載された支出情報を読み取る。レシート読取部３０１は、レシートに含まれるテキストのパターン（「領収証」、「合計」、「お預り」及び「お釣り」等）を予め記憶しておき、撮影した画像に写ったテキストを認識してそれらのパターンが含まれている場合にレシートが撮影されていると判断する。レシート読取部３０１は、この判断を行うと、撮影されているレシートに記載されている日時、商品名、価格、価格の合計、消費税額、支払額及びお釣り等を支出情報として読み取る。レシート読取部３０１は、読み取った支出情報を支出情報送信部３０２に供給する。なお、この画像認識プロセスは、外部装置に対して画像データを送信し、その外部装置により読み取られた文字情報をユーザ端末３０に返却することにより実現されてもよい。

支出情報送信部３０２は、家計簿サーバ装置１０の宛先（ＩＰ（Internet Protocol）アドレス等）を記憶しておき、供給された支出情報をその宛先（すなわち家計簿サーバ装置１０）に送信する。支出情報取得部１０２は、こうして送信されてきたレシートから読み取られた支出情報を取得する。支出情報取得部１０２は、上記のとおり取得した支出情報を、ユーザのユーザＩＤとともに家計情報蓄積部１０３に供給する。

家計簿サーバ装置１０の家計情報蓄積部１０３は、上記のとおり取得された収入情報及び支出情報をユーザの家計情報として蓄積する。家計情報蓄積部１０３は、供給された収入情報及び支出情報を、ともに供給されたユーザＩＤに対応付けて記憶することでこの蓄積を行う。以上で述べた収入情報及び支出情報の取得及び蓄積は定期的に（例えば毎日。支出情報についてはユーザがレシートを撮影する操作を行ったときにも）行われ、なるべく新しい家計情報が蓄積されるようになっている。

資金運用支援サーバ装置２０の支払額取得部２０１は、上述した商取引における支払額を記憶する記憶装置からその支払額を取得する。商取引における支払額は、支出情報が示す出金の金額及びレシートに記載された価格の合計と消費税額を合わせた金額等によって表される。支払額取得部２０１は、その支出情報を記憶する家計簿サーバ装置１０（本実施例における記憶装置）に支出情報を要求する。家計簿サーバ装置１０の家計情報蓄積部１０３は、この要求を受け取ると、蓄積している支出情報及びそれに対応付けたユーザＩＤを資金運用支援サーバ装置２０に送信する。

このとき、家計情報蓄積部１０３は、今までに資金運用支援サーバ装置２０に送信したことがない支出情報（つまり前回支出情報を送信した後に新たに蓄積された支出情報）を送信する。支払額取得部２０１は、送信されてきた支出情報及びユーザＩＤを受け取ることで、そのユーザＩＤのユーザが商取引の際に支払った支払額を取得する。支払額取得部２０１は、取得した支払額を示す支出情報を対応するユーザＩＤ（その額を支払ったユーザのユーザＩＤ）に対応付けて差額算出部２０２に供給する。

差額算出部２０２は、支払額取得部２０１により取得された支払額とその支払額を切り上げた額との差額を算出する。差額算出部２０２は、例えばユーザによってお釣り運用サービスの利用開始時に設定された単位（５０円単位、１００円単位、５００円単位又は１０００円単位等）で支払額を切り上げる。この切り上げ単位は、お釣り運用サービスの利用開始後も変更可能である。
差額算出部２０２は、支払額が３２５円の場合に、切り上げ単位として１００円単位が設定されている場合、３２５円を１００円単位で切り上げた４００円から３２５円を減算して得られる７５円を差額として算出し、切り上げ単位として５０円単位が設定されている場合、３２５円を５０円単位で切り上げた３５０円から３２５円を減算して得られる２５円を差額として算出する。差額算出部２０２は、こうして算出した差額を対応するユーザＩＤ（その差額が算出される支払いを行ったユーザのユーザＩＤ）及び支出情報に対応付けて差額取得部２０３に供給する。

差額取得部２０３は、商取引における支払額とその支払額を切り上げた額との差額を取得する。差額取得部２０３は、本実施例では、差額取得部２０３により算出された差額を取得する。差額取得部２０３は、取得した差額を、その差額に対応付けて供給されたユーザＩＤ及び支出情報とともに差額蓄積部２０４に供給する。
差額蓄積部２０４は、差額取得部２０３により取得された差額を、対応するユーザＩＤ等に対応付けて記憶する。
図５は蓄積されている差額の一例を示す図である。図５の例では、差額蓄積部２０４は、ユーザＩＤと、支払日と、差額と、差額ＩＤと、ステータスとを対応付けて記憶している。支払日は、差額が算出された支払額の商取引が行われた日を表し、支出情報により示される。差額ＩＤは、各差額を識別する情報である。ステータスは、蓄積されている差額を資金運用に充てることについての承諾をユーザに要求した場合に承諾が得られた状況、又は、拒否された状況を表す。

また、ステータスは、承諾要求がまだなされていない未要求の状況、又は、承諾された後に口座の移動まで済んでいる移動済みの状況を表す。図５の例では、支払日が１２／２２から１２／３１までの差額には「移動済み」という状況が、支払日が１／１から１／７までの差額には「拒否」という状況が、支払日が１／８から１／１４までの差額には「承諾」という状況が、支払日が１／１５から１／２１までの差額には「未要求」という状況がそれぞれ対応付けられている。

この承諾要求及び口座の移動についてはこの後で詳しく説明する。以上で述べた支払額の取得から差額の蓄積までの動作は定期的に（例えば毎日）行われ、なるべく最新の商取引における差額が蓄積されるようになっている。本実施例では、説明を分かり易くするために、毎日その日に行われた商取引における差額が差額取得部２０３によって取得され、差額蓄積部２０４に蓄積されるものとする。

資金運用支援サーバ装置２０の要求時期判断部２０５は、前述した承諾要求を行う時期、すなわち、差額蓄積部２０４に蓄積されている差額を資金運用に充てることについての承諾をユーザに要求する要求時期になったか否かを判断する。要求時期判断部２０５は、承諾を要求する相手となる要求先ユーザが定めた基準日から定められた第１の期間が経過するごとに、要求時期になったと判断する。

本実施例では、基準日として月初めの日が定められ、第１の期間として１週間、又は、月末最後の期間が１週間に満たない場合は、その前週と合わせた期間を第１の期間とする。つまり、第１の期間は、１週間又は１週間＋月末の数日間である。この定め方をすれば、どの月も４回の第１の期間を含むことになる。例えば１月であれば、月初めの１／１（１月１日）が基準日となり、１／１から１／７まで、１／８から１／１４まで、１／１５から１／２１まで、１／２２から１／３１までという４回の第１の期間が定められる。

要求時期判断部２０５は、第１の期間が経過した次の日になったときに要求時期になったと判断する。例えば上記の４回の第１の期間については、１／８、１／１５、１／２２及び２／１になったときに要求時期になったと判断する。要求時期判断部２０５は、要求時期になったと判断すると、要求先ユーザのユーザＩＤに対応付けて蓄積されている差額のうちステータスが「未要求」であるものを、対応する差額ＩＤ及び支払日とともに差額蓄積部２０４から読み出し、要求先ユーザのユーザＩＤとともに承諾要求部２０６に供給する。

承諾要求部２０６は、第１の期間が経過するごとに、その第１の期間になされた１以上の商取引における差額を資金運用に充てることについての承諾をユーザに要求する。例えば、ユーザ端末３０の承諾要求表示部３０３が、自機能を実現するためのプログラムが起動されたとき又は定期的に、自装置を利用するユーザのユーザＩＤを資金運用支援サーバ装置２０に送信するとともに、表示すべき承諾要求が有るか否かを資金運用支援サーバ装置２０に問い合わせる。

承諾要求部２０６は、要求時期判断部２０５から供給されたユーザＩＤとユーザ端末３０から送信されてきたユーザＩＤとが一致する場合、そのユーザＩＤとともに供給された差額、差額ＩＤ及び支払日を用いて、例えばそれらの差額を資金運用に充てることについての承諾を要求する旨を表す文字列と、供給された差額ＩＤ、差額及び支払日とを示す要求データを生成する。
承諾要求部２０６は、生成した要求データを、問い合わせ元のユーザ端末３０に対して送信する。承諾要求部２０６は、この要求データをユーザ端末３０に送信することで、資金運用の承諾をユーザに要求する。

以上のとおり、本実施例では、ユーザ端末３０からの問い合わせを受けて資金運用の承諾が要求されるという、いわゆるプル型での承諾要求が行われる。なお、これに限らず、ユーザ端末３０からの問い合わせがなくても、要求時期判断部２０５により第１の期間が経過したと判断されたときに、承諾要求部２０６が資金運用の承諾を要求するという、いわゆるプッシュ型での承諾要求が行われてもよい。

ユーザ端末３０の承諾要求表示部３０３は、資金運用支援サーバ装置２０から差額を資金運用に充てることについての承諾を要求された場合に、その承諾要求を表示する。承諾要求表示部３０３は、資金運用支援サーバ装置２０から送信された要求データを受け取ると、その要求データが示す文字列等を、資金運用支援サーバ装置２０からの承諾要求としてアプリ画面又はウェブブラウザの画面に表示する。

図６は表示された承諾要求の一例を示す図である。図６の例では、承諾要求表示部３０３は、「Ａさんに以下のお釣りの資金運用が提案されました。」という文字列と、商取引の支払日と、その商取引における差額と、選択された差額の合計金額（この例では「１４６８円」）とを示す文字列とを、承諾要求Ａ１として出力装置３６の表示部に表示している。また、承諾要求表示部３０３は、「選択したものを承諾」と書かれた承諾ボタンＢ１と、拒否ボタンＢ２と、全選択ボタンＢ３と、複数の個別選択ボタンＢ４（「○」は選択することを示し、「×」は選択しないことを示す）とを表示している。

承諾要求表示部３０３は、これらのボタンの表示領域を示す情報を承諾可否操作受付部３０４に供給する。承諾可否操作受付部３０４は、承諾要求に対する承諾の可否を示すユーザの操作を受け付ける。承諾可否操作受付部３０４は、承諾ボタンＢ１をタップする操作（マウスでクリックする操作でもよい）を、選択された差額の合計金額として表示されている資金の資金運用をユーザが承諾する操作として受け付け、拒否ボタンＢ２をタップする操作を、ユーザが資金運用を拒否する操作として受け付ける。

また、承諾可否操作受付部３０４は、全選択ボタンＢ３をタップする操作を、資金運用に充てる資金として全ての差額を選択する操作として受け付け、個別選択ボタンＢ４をタップする操作を、各差額の選択の有無を切り替える操作（タップする度に「○」と「×」が切り替わる）として受け付ける。承諾可否操作受付部３０４は、受け付けた操作結果を示す操作結果情報を承諾可否通知部３０５に供給する。

操作結果情報は、例えば、選択された差額の差額ＩＤ、選択されなかった差額の差額ＩＤ及び選択された差額の合計金額を示す情報である。なお、拒否ボタンＢ２が操作された場合には、選択された状態の差額があったとしても、全ての差額の差額ＩＤが選択されなかった差額の差額ＩＤとして示され、且つ、合計金額として０円が示される操作結果情報が承諾可否通知部３０５に供給される。

承諾可否通知部３０５は、承諾可否操作受付部３０４による操作結果を資金運用支援サーバ装置２０に通知する。承諾可否通知部３０５は、資金運用支援サーバ装置２０の宛先を示す宛先情報（ＩＰアドレス等）を予め記憶しておく。承諾可否通知部３０５は、承諾可否操作受付部３０４から操作結果情報が供給されると、供給された操作結果情報と、自装置のユーザのユーザＩＤとを対応付けた操作結果データを、記憶している宛先情報が示す宛先（つまり資金運用支援サーバ装置２０）に送信する。

承諾可否通知部３０５は、この操作結果データを送信することで、資金運用支援サーバ装置２０に対して、承諾要求が表示されて資金運用を承諾する操作が行われた場合にはその操作結果データが示す合計金額の資金運用が承諾された旨を通知し、資金運用を拒否する操作が行われた場合にはその旨を通知する。
また、承諾可否通知部３０５は、こうして資金運用を承諾又は拒否した差額の履歴が後から確認できるように、操作結果データ及びその操作結果データの送信日時を互いに対応付けて記憶しておく。この操作結果データは、資金運用を承諾する操作が受け付けられた場合におけるその資金運用に充てられる資金を示す情報である。

承諾可否通知部３０５は、例えば、操作結果データを受信した際の資金運用支援サーバ装置２０のローカル時間（世界標準時からの時差により算出される日時、日本なら＋９時間）を、操作結果データの送信日時として記憶する。これにより、ユーザ端末３０が海外から資金運用支援サーバ装置２０にアクセスする場合でも、日本時間で送信日時が記憶される。

資金運用支援サーバ装置２０の承諾可否受付部２０７は、承諾要求部２０６が要求した承諾の可否を受け付ける。承諾可否受付部２０７は、ユーザ端末３０から送信されてきた操作結果データを受け取ると、その操作結果データが１円以上の合計金額を示す場合には、その操作結果データが示す合計金額による資金運用が承諾されたことを受け付け、その操作結果データが合計金額として０円を示す場合には、資金運用が拒否されたことを受け付ける。

承諾可否受付部２０７は、承諾の可否を受け付けると、差額蓄積部２０４に対して、操作結果データが示すユーザＩＤ及び差額ＩＤに対応付けられている差額のステータスを受け付けた承諾の可否のとおりに変更するよう指示する。差額蓄積部２０４は、この指示を受け取ると、指示されたとおりに、承諾要求がされた差額のステータスを「未要求」から「承諾」又は「拒否」に変更する。

ユーザ端末３０の履歴表示部３０６は、過去に資金運用が承諾された差額の履歴を表示する。履歴表示部３０６は、承諾された差額の履歴を表示する操作がユーザにより行われると、記憶されている操作結果データ及びその操作結果データの送信日時を承諾可否通知部３０５から取得する。なお、本実施例では、拒否された差額の履歴を表示する操作は用意されておらず、一度拒否された差額の履歴は表示されないものとする。履歴表示部３０６は、取得した操作結果データが示す差額ＩＤの差額と、それらの差額の合計金額と、その合計金額の資金運用が過去（操作結果データの送信日時）に承諾された旨を示す文字列とを前述した差額の履歴として表示する。

図７は表示された差額の履歴の一例を示す図である。図７の例では、履歴表示部３０６は、「以下のお釣りの資金運用を１／２２に承諾しています。」という文字列と、商取引の支払日と、その商取引における差額と、選択された差額の合計金額（この例では「１４６８円」）とを示す文字列とを、差額の履歴Ｃ１として出力装置３６の表示部に表示している。また、承諾要求表示部３０３は、複数の個別選択ボタンＢ４と、変更の反映ボタンＢ５と、承諾の撤回ボタンＢ６とを表示している。

履歴表示部３０６は、各ボタンの表示領域を示す情報と取得した操作結果データとを撤回操作受付部３０７に供給する。撤回操作受付部３０７は、過去に行った資金運用の承諾の撤回を示すユーザの撤回操作を受け付ける。撤回操作受付部３０７は、承諾の撤回ボタンＢ６をタップする操作が行われると、その操作を、全ての差額についての承諾を撤回する撤回操作として受け付ける。
また、撤回操作受付部３０７は、個別選択ボタンＢ４をタップする操作を、図６の例と同様に各差額の選択の有無を切り替える操作として受け付け、その操作により或る差額について選択の有無を「○」から「×」に切り替えた後に変更の反映ボタンＢ５をタップする操作を、その差額についての承諾を撤回する撤回操作として受け付ける。撤回操作受付部３０７は、いずれかの撤回操作を受け付けると、承諾が撤回された差額の差額ＩＤを撤回通知部３０８に供給する。

撤回通知部３０８は、撤回操作受付部３０７から差額ＩＤが供給されると、それらの差額ＩＤの差額について資金運用の承諾が撤回された旨を資金運用支援サーバ装置２０に通知する。撤回通知部３０８は、供給された差額ＩＤと承諾が撤回された旨と自装置のユーザのユーザＩＤとを示す撤回通知データを資金運用支援サーバ装置２０に送信することでこの通知を行う。

資金運用支援サーバ装置２０の撤回受付部２０８は、撤回通知部３０８から通知された資金運用の承諾の撤回を受け付ける。撤回受付部２０８は、ユーザ端末３０から送信されてきた撤回通知データを受け取ると、承諾の撤回がされたものと判断し、その撤回通知データが示すユーザＩＤ及び差額ＩＤに対応付けられている差額のステータスを承諾から拒否に変更するよう差額蓄積部２０４に指示する。差額蓄積部２０４は、この指示を受け取ると、指示されたとおりに、それらの差額のステータスを「承諾」から「拒否」に変更する。

資金運用支援サーバ装置２０の資金移動時期判断部２０９は、資金運用の承諾を得られた差額の累積額をユーザの資金が収められているユーザ名義の普通口座（以下、ユーザ口座という）から、投信口座に移動する移動時期を判断する。
本実施形態では、銀行サーバ４がユーザ口座のお金を管理しており、信託銀行の銀行サーバ５が投信口座を管理している。

資金移動時期判断部２０９は、上述した基準日（要求先ユーザが定めた日。資金運用支援サーバ装置２０のローカル時間で判断される）から、上述した第１の期間を複数含む第２の期間が経過すると、移動時期になったと判断する。本実施例では、上述したようにどの月も４回の第１の期間を含むように基準日及び第１の期間が定められており、それら４回の第１の期間を含む期間を第２の期間として定めるものとする。この定め方をすれば、１月から１２月までの各月がそれぞれ第２の期間となる。

資金移動時期判断部２０９は、第２の期間が終了してから、最後の第１の期間についての資金運用の承諾のために設けられた期間が経過したときに、資金移動時期になったと判断する。例えば承諾のための期間を３日間とすると、資金移動時期判断部２０９は、１／３１に第２の期間が終了し、２／１から２／３までの３日間が経過した次の日である２／４になったときに、資金移動時期になったと判断する。

資金移動時期判断部２０９は、資金移動時期になったと判断すると、要求先ユーザのユーザＩＤに対応付けて蓄積されている差額のうち、ステータスが「承諾」であるものを差額ＩＤとともに差額蓄積部２０４から読み出し、読み出した差額及び差額ＩＤを要求先ユーザのユーザＩＤとともに移動指示処理実行部２１０に供給する。

移動指示処理実行部２１０は、上述した第２の期間が経過すると、承諾を得られた差額の累積額のユーザ口座から投信口座への移動を指示する移動指示処理を実行する。ここでいう承諾を得られた差額には、承諾が撤回された差額は含まれない。つまり、移動指示処理実行部２１０は、承諾が得られてから移動指示処理を実行する前にその承諾の撤回が撤回受付部２０８により受け付けられた場合、その承諾が撤回された差額を累積額から減じて移動指示処理を実行する。

移動指示処理実行部２１０は、資金移動時期判断部２０９から資金運用が承諾された差額及び差額ＩＤが供給されると、その差額を合計した金額を累積額として算出する。移動指示処理実行部２１０は、算出した累積額と同じ額をユーザ口座から投信口座に移動させることを要求する要求データを図１に表す決済代行サーバ３に送信する処理を、移動指示処理として実行する。

決済代行サーバ３は、この要求データを受け取ると、ユーザ口座を管理する銀行サーバ４に対してそのユーザ口座から銀行サーバ５が管理する投信口座に対して累積額と同じ額を移動させるよう要求する。
銀行サーバ４がこの要求に基づいて累積額と同じ額をユーザ口座から投信口座に振り込む処理を行い、銀行サーバ５が振り込まれた金額を投信口座に入金する処理を行うことで、資金の移動が完了する。

なお、要求データの送信先、すなわち、口座間の資金の移動の要求先は、決済代行サーバ３ではなく銀行サーバ４であってもよいし、プリペイドカード、ポイントエクスチェンジ及び携帯キャリア決済代行等の決済機関であってもよい。要するに、資金運用のために口座間の資金の移動がなされれば、要求先がどこであってもよい。また、結果として口座間の資金の移動がなされれば、移動指示処理実行部２１０は、どのような処理を移動指示処理（差額の累積額のユーザ口座から投信口座への移動を指示する処理）として実行してもよい。

以上のように、お釣り運用サービスにおいては、ユーザが買い物の際に生じたお釣りを投信口座に入金することにより、そのお金を資金として委託会社が、投資信託への投資を行うようにしている。
お釣り運用サービスのユーザは、この投資信託への投資により生じた利益を得ることができるほか、任意のタイミングで投資信託を解約等により換金することができる。
このような投資信託の換金については、従来のシステムで対応できるものの、上記［発明が解決しようとする課題］において説明したように、ユーザが投資信託の換金を申し込んでから解約代金（以下、「代金」という）である現金がユーザに受け渡されるまでに時間が掛かるという課題に対処できていなかった。
これに対し、本発明の一実施形態に係る投信取引システムＳは、投資信託の換金の申込時における既知の時価に基づいて対価をすぐに算出し、電子マネーなどの電子有価財を用いて代金をユーザにすぐに受け渡すことで前記課題を解決するものである。
以下、投信取引システムＳについて説明する。

（投信取引システム）
図８は本発明の金融商品取引システムの一実施形態に係る投信取引システムＳの全体構成を示す図である。
図８に示すように、投信取引システムＳは、投資信託上の受益者であるユーザが使用するユーザ端末３０、投資信託上の委託者である委託会社において管理される投信取引サーバ４０、投資信託の取引業務の支援を行う業務支援サーバ５０、及び所定の電子マネーサービスを運営する電子マネー会社において管理される電子マネー会社サーバ６０等によって構成され、これら各装置と、資金運用支援システム１の各装置とがネットワーク２を介して通信可能に接続されている。

なお、投信取引サーバ４０、業務支援サーバ５０、及び電子マネー会社サーバ６０は情報処理装置であり、ハードウェア構成は、前述した資金運用支援システム１における家計簿サーバ装置、資金運用支援サーバ装置と同じ構成であるため、詳細な説明を省略する（図２参照）。
また、ユーザ端末３０は、資金運用支援システム１におけるユーザ端末３０と同じであり、お釣り運用サービスのユーザが使用する端末装置であるとともに、投信取引システムＳにおけるユーザが使用する端末装置でもある。
ただし、これらは必ずしも同じ端末装置でなくてもよい。

図９は、投信取引システムＳの機能構成を示す図である。
図９に示すように、ユーザ端末３０は、ログイン部３１１、及び換金申込部３１２を備える。
投信取引サーバ４０は、投資信託の取引に係る各種処理を行う装置であり、認証部４０１、申込受付部４０２、対価算出部４０３、手数料算出部４０４、課税額算出部４０５、取引基準価格決定部４０６、電子マネー発注部４０７、及び現金処理部４０８を備える。

業務支援サーバ５０は、投信取引サーバ４０における投資信託の取引処理を支援する装置であり、ユーザ情報ＤＢ５０１、口座情報ＤＢ５０２、及び基準価額ＤＢ５０３を備える。
電子マネー会社サーバ６０は、所定の電子マネーサービスを提供可能な装置であり、電子マネー処理部６０１を備える。
本実施形態の電子マネー会社サーバ６０は、少なくとも、「前払式支払手段」に該当する電子マネー（以下、第１電子マネーと称する）のサービスと、「資金移動」に該当する電子マネー（以下、第２電子マネーと称する）のサービスと、を提供可能に構成されている。
第１電子マネーに係る「前払式支払手段」は、記録媒体であるカードや携帯電話に金銭的価値としての電子マネーをチャージすることで、その残高を増やすことができるものであり、残高の範囲内において商品やサービスを購入できるようになっている。
例えば、第１電子マネーには、所定のギフトサービスがあり、ギフトＩＤ発行者が発行する金銭的価値に相当するギフトＩＤを電子マネーサービスの会員に送り、当該会員が、受け取ったギフトＩＤや会員番号等を専用サイトにおいて入力することでもチャージ可能になっている。
便宜上、第１電子マネーにおいて、カードや携帯電話などの記録媒体を「ｎカード等」と称し、ギフトサービスを「ｎギフト」と称する。
第２電子マネーに係る「資金移動」は、犯罪収益移転防止法にて取引時確認をしなければならない取引と定められている。
例えば、第２電子マネーは、本人情報で本人確認を行った上で、Ｗｅｂサイト上に設けた会員の電子マネー口座（単に口座ともいう）に金銭的価値としての電子マネーを直接的にチャージできるようになっており、会員は、自身の口座の残高の範囲内において商品やサービスを購入できるようになっている。
なお、電子マネー会社サーバ６０は、上記電子マネーに限らず様々なタイプの電子マネーを提供可能に構成することができる。
また、電子マネー会社サーバ６０は、第１電子マネー（ｎギフト含む）と第２電子マネーの２つの電子マネーサービスを１台の装置で統括的に運営する態様でもよく、２台の装置でそれぞれ独立して運営する態様でもよい。
また、電子マネー会社サーバ６０は、第１電子マネー及び第２電子マネーの運営の委託を受けた外部機関が運営する装置であってもよい。

投信取引システムＳにおいては、上記各装置のプロセッサがプログラムを実行して各部を制御することで、各種機能が実現される。

まず、業務支援サーバ５０が備える各種データベース（ユーザ情報ＤＢ５０１、口座情報ＤＢ５０２、基準価額ＤＢ５０３）について説明する。
図１０は、ユーザ情報ＤＢの一例であり、図１１は、口座情報ＤＢの一例であり、図１２は、基準価額ＤＢの一例である。
ユーザ情報ＤＢ５０１は、お釣り運用サービスのユーザのアカウント情報（ユーザＩＤ、パスワード）により構成されるデータベースである。
図１０に示すように、ユーザ情報ＤＢ５０１には、ユーザが第１電子マネーや第２電子マネーの会員でもある場合には、それぞれのサービスを利用する際に必要な情報（アカウント情報等）を紐付けて登録しておくこともできる。
例えば、第１電子マネーを利用する場合には、会員の会員番号とパスワードが求められるが、そのうちの会員番号を紐付けて登録することができる（図１０参照）。
また、第２電子マネーを利用する場合には、会員の口座番号や本人情報（ユーザ名等）が求められるが、そのうちの口座番号を紐付けて登録しておくことができる。
なお、パスワード（第１電子マネーの場合）や本人情報（第２電子マネーの場合）を登録することもできる。

図１１に示すように、口座情報ＤＢ５０２は、お釣り運用サービスのユーザの投信口座に関する情報により構成されるデータベースであり、具体的には、銘柄、口数等とユーザＩＤとが対応付けて構成されている。
図１２に示すように、基準価額ＤＢ５０３は、委託会社によって毎日算出される投資信託の社内時価である基準価額のデータベースであり、基準価額と日付けとが対応付けて構成されている。

投信取引システムＳの機能及び動作について図９等を参照しながら説明する。

ユーザ端末３０のログイン部３１１は、所定のログイン操作に基づいて、投信取引サーバ４０に対しログイン情報を送信する。
具体的には、ユーザのアプリ操作により、ユーザ端末３０の表示部３６にログインページ（図示省略）を表示させ、当該ログインページに設けられたログイン情報入力欄にログイン情報（お釣り運用サービスのユーザＩＤ及びパスワード等）を入力する。
これにより、ログイン部３１１は、入力されたログイン情報を投信取引サーバ４０の認証部４０１に送信する。

投信取引サーバ４０の認証部４０１は、ログイン情報を受信すると、業務支援サーバ５０にログイン情報を送信することで、当該ログイン情報とユーザ情報ＤＢ５０１（図１０）に記憶されているアカウント情報とを照合させる。
照合の結果、一致が確認された場合、ユーザ端末３０は、ログイン画面として、図１３に示すホーム画面（アプリ画面）を表示部３６に表示する。
これにより、ユーザは、ホーム画面に設けられた各メニューのサービスを利用できるようになる。
例えば、ホーム画面の各メニューの中から「各種設定」ボタンを選択することで、ユーザのアカウント情報を表示部３６に表示することができ、当該アカウント情報を確認したり、変更することができる。

電子マネーサービス（第１電子マネー又は第２電子マネー）との連携処理を行う場合には、その都度、その電子マネーサービスを利用する際に必要な情報（電子マネーサービスのアカウント情報）の入力を求め、入力された情報を電子マネー会社サーバ６０に送信して認証することができる。
例えば、第１電子マネーでのチャージ（以下、ｎチャージという）が選択された場合には、アプリ画面上に会員番号及びパスワードなどの入力を求め、入力された情報が認証された場合に「ｎチャージ」を実行できるようにすることができる。
同様に、第２電子マネーのチャージ（以下、ｄチャージという）が選択された場合には、アプリ画面上に口座番号及び本人情報（会員のユーザ名等）などの入力を求め、入力された情報が認証された場合に「ｄチャージ」を実行できるようにすることができる。
なお、一度連携処理が行われると、アカウント情報をサーバ側で保持するようにして、一定期間はアカウント情報の入力を不要にすることもできる。

ユーザ端末３０の換金申込部３１２は、所定操作に基づいてユーザが保有する投資信託の換金の申し込み処理を行う。
具体的には、ホーム画面（図１３参照）の各メニューの中から「出金」を選択する。
なお、「出金」と「換金」とは同義であるが、主にアプリ上の用語として「出金」を用いる。
ホーム画面において「出金」を選択すると、図１４に示す出金方法選択画面に遷移する。
出金方法選択画面には、現金による出金を選択する場合の操作手段として「現金で出金」ボタンｂ１が設けられており、電子マネーやポイントなどの電子有価財による出金（以下、電子チャージ出金という）を選択可能な操作手段として、「ｎチャージ」ボタンｂ２及び「ｄチャージ」ボタンｂ３が設けられている。

「ｎチャージ」は、第１電子マネーにおけるｎギフトを用いたチャージによる出金方法であって、金額に対応したギフトＩＤをユーザ宛に送ることで、ユーザのｎカード等にその金額の電子マネーをチャージ可能にするものである。
「ｄチャージ」は、第２電子マネーによる出金方法であって、ユーザの電子マネー口座に直接的に電子マネーをチャージするものである。
なお、第１電子マネーや第２電子マネー以外の他の電子マネーやポイントを用いた電子チャージ出金方法を採用することもできる。これについては、後記「応用例・変形例」において説明する。
このように、投資信託の換金の申込みとして、電子有価財での受渡しを求める申込み（第１申込み）と、現金での受渡しを求める申込み（第２申込み）とがあり、このうちのいずれかを選択して申込みできるようになっている。

ここで、「電子有価財」は、電子マネーを含む概念である。
「電子マネー」は、現金の代替となる支払手段（決済手段）の一種であり、決済の手段（現金や預金など）を電子化したものと、決済の方法（振込、口座振替、小切手、クレジットカードなど）だけを電子化したものとがあり、本発明の電子マネーはその両方を含む概念である。
「電子マネー」は、それ自体が価値を有する決済手段であるもの（決済手段性あり）と、それ自体が価値を有する決済手段ではないもの（決済手段性なし）に分けることもできる。
決済手段性があるものには、ネットワーク型の電子決済のシステムにおいて、金銭情報などの電子データをＷｅｂ上のサーバで管理するサーバ型電子マネーなどがあり、本発明の第１電子マネーはこのタイプに該当する。
第１電子マネーは、ギフトＩＤ自体が価値を有することから決済手段性を有しており、ギフトＩＤ自体が電子マネーに相当するともいえる。
決済手段性がないものには、預金通貨の移転を電子的に指示する仕組みを用いた支払手段を用いた支払指示型電子マネーがあり、第２電子マネーのほか、ドコモ（登録商標）口座、PayPay（登録商標）などのデポジット型電子マネーを例示することができる。

また、「電子有価財」には、各種ポイントサービス（ポイントプログラム）において付与されるポイントを概念に含む。
「ポイント」は、各種の商品・サービスの購入金額あるいは来店回数等に応じて、一定の条件で計算されユーザに付与される点数のことをいう。ユーザは、獲得したポイントを商品・サービスの購入代金の一部に充当したり、商品・サービスと交換することができる。
また、ポイントサービスの中には、ポイントを現金に交換できるサービスもあり、この場合、ポイントは、電子マネーにも該当し得る。
上記例以外の電子マネー及びポイントについては、後記「応用例・変形例」において説明する。

図１４は、出金方法選択画面の一例である。

ユーザ端末３０の換金申込部３１２は、「電子チャージ出金」が選択された場合、すなわち、出金方法選択画面において「ｎチャージ」又は「ｄチャージ」が選択された場合、所定の換金申込情報を投信取引サーバ４０の申込受付部４０２に送信する。
「換金申込情報」には、「電子チャージ出金が選択されたことを示す情報」及び「ｎチャージかｄチャージかを特定可能な情報」からなる「電子チャージ選択情報」と、「ユーザＩＤ」とが含まれる。

投信取引サーバ４０の申込受付部４０２は、ユーザが保有する投資信託の換金の申込みを受け付ける。
具体的には、申込受付部４０２は、ユーザ端末３０から換金申込情報を受信することに基づいて投資信託の換金の申込みを受け付ける。
このとき、申込受付部４０２は、換金申込情報に電子チャージ選択情報が含まれていることに基づき電子マネーの受け渡しを求める第１申込みを受け付ける。

また、申込受付部４０２は、換金申込情報を受信した日を「申込日」として特定し、当該申込日と、電子チャージ選択情報とを対価算出部４０３に出力する。
また、申込受付部４０２は、ユーザＩＤをキーとして業務支援サーバ５０に口数残高要求情報を送信することにより、口座情報ＤＢ５０２（図１１）からユーザが保有する投資信託の現在の口数残高を取得し、これを応答情報に含めてユーザ端末３０に送信する。
ユーザ端末３０の換金申込部３１２は、投信取引サーバ４０から応答情報を受信すると、図１５に示す出金内容入力画面を表示部３６に表示する。
これにより、表示部３６の画面は、出金方法選択画面（図１４）から出金内容入力画面（図１５）に遷移する。

図１５に示すように、出金内容入力画面には口数入力欄ｃ１が設けられており、この口数入力欄ｃ1に任意の換金口数を入力できるようになっている。
また、出金内容入力画面には、ユーザが保有する投資信託の現在の口数残高が表示される（領域ｃ２参照）。
これにより、ユーザは、自身が保有する投資信託の口数残高を把握することでき、この口数残高の範囲内で円滑に換金口数を入力することができる。
ユーザ端末３０の換金申込部３１２は、出金内容入力画面において換金口数が入力されると、当該入力された換金口数の情報を投信買取サーバ４０の申込受付部４０２に送信する。

投信取引サーバ４０の申込受付部４０２は、ユーザ端末３０から換金口数の情報を受信すると、当該換金口数を対価算出部４０３に出力する。
対価算出部４０３は、申込受付部４０２から「申込日」及び「電子チャージ選択情報」を入力すると、取引基準価格決定部４０６に対し「申込日」の前営業日の基準価額を取引基準価格とする情報の問い合わせを行う。
取引基準価格決定部４０６は、問い合わせに応じ、申込みを受け付けたときより前の時点における時価を取引基準価格として決定する。
具体的には、業務支援サーバ５０の基準価額ＤＢ５０３（図１２）にアクセスし、当該基準価額ＤＢ５０３に記憶されている過去の基準価額の中から申込日の前営業日の基準価額を抽出し取引基準価格として決定する。
なお、本実施形態では、申込日の前営業日の基準価額を取引基準価格としているが、これに限らず、例えば、申込日の２営業日前の基準価額を取引基準価格とすることもでき、申込日の過去の営業日における基準価額であれば、取引基準価格とすることができる。
取引基準価格決定部４０６は、決定した取引基準価格を対価算出部４０３に出力する。

対価算出部４０３は、取引基準価格決定部４０６により決定した取引基準価格に基づいて、投資信託の対価を算出する。
具体的には、取引基準価格決定部４０６から入力した基準価額（申込日の前営業日の基準価額）と、申込受付部４０２から入力した換金口数とに基づいて、換金対象の投資信託の対価を算出する。

また、対価算出部４０３は所定の手数料を加味して出金額を算出することもできる。
具体的には、対価算出部４０３の手数料算出部４０４が、手数料を算出する。
例えば、前営業日の基準価額が１０，６７４円／１万口で、換金口数が３０００口の場合、スプレッド（手数料５％）を控除した買取価額１０，１４０円となるため、換金対象の投資信託の対価は３，０４２円と算出される。
つまり、元の対価（３，２０２円）から１６０円の手数料が控除された額（３，０４２円）が投資信託の対価として算出される。

ところで、投信取引サーバ４０は、所定の手数料を設定することが可能な手数料設定部を備えている（図示商略）。
手数料設定部においては、以下の（ｉ）〜（ｉｉ）の事項を加味して手数料を設定することができる。
（ｉ）基準価額の変動リスクに対する委託会社のコスト負担
電子チャージ出金は、委託会社がユーザの保有する受益権（投資信託）の対価相当分の電子マネーをユーザに受け渡すことの引き換えに、ユーザが保有する受益権を委託会社が受け取ることで実現している。
つまり、委託会社が、ユーザが保有する受益権をユーザから買い取る形をとっている。
また、委託会社は、ユーザから買い取った受益権をその後に売却することで、電子マネーの購入、すなわち、受益権の買取りに要した費用を回収するようにしている。
このような仕組みでは、受益権を買い取ったときの基準価額と、買い取った受益権をその後に売却するときの基準価額との変動がある場合には、委託会社がその変動に伴うコスト（変動リスク）を負担しなければならない。
しかも、この変動リスクは、従来のブラインド方式においては、ユーザが負担していたものである。

このような理由から、手数料設定部は、上記基準価額の変動リスクに対応した費用や料率を設定するなど、上記変動リスクを加味した手数料を設定することができる。
具体的には、手数料設定部は、ユーザが保有する金融商品としての投資信託を委託者が購入したときの時価と、委託者がユーザから購入した投資信託を換金するときの時価との変動を加味して手数料を設定することができる。

（ｉｉ）即時出金可能としたことによる付加価値及びコスト
従来の方式（現金での出金）では、換金の申込みから代金の受渡しまでに時間が掛かるところ、電子チャージ出金にすることで、申込み時に即時に代金をユーザに受渡すことを可能としている。
これにより、利便性が向上するなど付加価値の高いサービスを実現していることでユーザに利益を与えている。
また、このようなサービスを実現するための諸々のコストがかかっている。

このような理由から、手数料設定部は、上記利益及びコストに対応した費用や料率を設定するなど、上記利益及びコストを加味して手数料を設定することができる。
具体的には、手数料設定部は、申込受付部４０２が、電子マネー等の電子有価財での受渡しを求める第１申込みを受け付けた場合、電子マネー等をユーザが受け取ることによるユーザの利益を加味して手数料を設定することができる。

対価算出部４０３は、これらの算出結果に基づき、ユーザに受け渡す代金である出金額を算出する。
また、対価算出部４０３は、課税額を加味して出金額を算出することもできる。
課税額は、課税額算出部４０５により算出することができる。
具体的には、前営業日の個別元本を用いて譲渡損益を算出する。算出した譲渡損益と年間の累計譲渡損益から、所得税及び住民税の源泉徴収額又は還付額を算出する。

例えば、前営業日の個別元本が９，６４０円、譲渡損益は１５０円（譲渡益）、年間の累計譲渡損益の値が正の場合、譲渡益１５０円は全て源泉徴収対象となり、所得税及び住民税の合計は２９円となる。
このため、投資信託の対価が３，０４２円、源泉徴収額が２９円の場合、出金額は３，０１３円と算出される。
対価算出部４０３は、算出した出金額の情報をメモリ等の記憶手段に一時的に記憶させるとともに、上記各算出結果の情報をユーザ端末３０に送信する。

ユーザ端末３０は、対価算出部４０３から受信した各算出結果を表示部３６に表示する。
具体的には、図１６の出金内容確認画面に示すように、「即時出金額」として出金額（３，０１３円）が表示され、「即時出金における取引価格」として換金対象の投資信託の対価（３，２０２円）が表示され、「源泉徴収（還付）」（−２９円）が表示されるとともに、即時出金額（出金額）が、換金対象の投資信託の対価から源泉徴収を差し引いた金額であることを把握可能に表示される。
なお、本実施形態では、手数料込みで出金額を表示する表示態様を採用しているが（図１６参照）、手数料を外だし表示することで、手数料がいくらかわかるようにすることもできる。

ここで、出金内容確認画面の下部に設けられている「出金」ボタンｂ４が選択されると、出金手続きが完了する。
出金手続きが完了すると、ユーザ端末３０は、図１７に示すように、出金手続きが完了した旨のメッセージを含む出金手続完了画面を表示部３６にすることができる。
また、ユーザ端末３０は、出金手続きの操作に応じ、出金を実行する旨の情報を投信取引サーバ４０の対価算出部４０３に送信する。

投信取引サーバ４０の対価算出部４０３は、ユーザ端末３０から出金を実行する旨の情報を受信すると、メモリに記憶している出金額の情報と、電子チャージ選択情報とを電子マネー発注部４０７に出力する。

電子マネー発注部４０７は、電子マネー会社サーバ６０に対し、対価算出部４０３により算出した対価に相当する電子マネーに関する発注処理を行う。
電子マネー発注部４０７は、具体的には、以下の処理を実行する。

電子チャージ選択情報に基づき、出金方法として「ｎチャージ」が選択されていることが判定された場合、電子マネー発注部４０７は、第１電子マネーを運営する電子マネー会社サーバ６０が提供するＡＰＩ（以下、ｎ−ＡＰＩという）を呼び出す。
電子マネー発注部４０７は、ｎ−ＡＰＩを呼び出すと、メモリから出金額の情報を取出し、これを発注額として当該ＡＰＩに入力するとともに、ユーザの会員番号等をユーザ情報ＤＢ５０１から取り出して当該ＡＰＩに入力する。

なお、このように会員番号等を自動的に入力するのではなく、ユーザに入力させることもできる。
これにより、電子マネー会社サーバ６０は、電子マネー処理部６０１が、代金受渡部として、対価算出部４０３により算出した対価に相当する所定の電子有価財を、投資信託の代金としてユーザに受け渡す処理を実行する。具体的には、以下の処理を実行する。

電子マネー処理部６０１は、ｎ−ＡＰＩ経由で会員番号等や発注額の情報を受け取ると、会員番号等の認証を行い、認証が得られた場合に、発注額に相当する電子マネーを発行する。
具体的には、発注額に相当するギフトＩＤを発行し、当該ギフトＩＤを投信取引サーバ４０に送信する。

投信取引サーバ４０は、電子マネー会社サーバ６０から受信したギフトＩＤをユーザ端末３０に送信する。
ユーザ端末３０は、ギフトＩＤを受信すると、当該ギフトＩＤを表示部３６に表示することができる。
具体的には、図１８に示すギフトＩＤ通知画面に示すように、ギフトＩＤをアプリ画面で表示することができる。
これにより、ユーザは、ギフトＩＤを知ることができるため、例えば、ユーザ端末３０で第１電子マネーの専用サイト（チャージ画面）にアクセスし、当該専用サイトでギフトＩＤ、会員番号等の入力などを行うことで、自身のｎカード等に換金額相当の電子マネーをチャージすることができる。
つまり、「ｎチャージ」においては、委託会社が運営する投信取引サーバ４０において、ギフトＩＤを購入し、当該購入したギフトＩＤをユーザに通知するようにしており、これにより、電子マネーを投資信託の換金の代金としてユーザに受け渡すようにしている。

なお、図１９に示すように、ギフトＩＤの受信に応じ、アプリ上に第１電子マネーの専用サイトのチャージ画面を連動して表示させ、当該画面に設けられたＩＤ入力欄にギフトＩＤの入力を促すようにすることもできる。
このようにすると、ユーザは、運用サイトを表示させる手間が省けるため、容易に電子マネーをチャージさせることができる。

また、図２０に示すように、既にＩＤ入力欄内にギフトＩＤが入力された状態で専用サイトのチャージ画面を表示させることで、ギフトＩＤを入力するユーザの手間も省けるため、さらに、電子マネーのチャージを容易にすることもできる。
さらに、ギフトＩＤをユーザ端末３０に送信せず、第１電子マネーを運営するサーバ側で内部的にチャージ処理することによって、ユーザに確認や操作を課すことなく、電子マネーをチャージするようにもできる。
この場合でも、ギフトＩＤをアプリ画面上に表示する等してユーザが確認できるようにすることもできる。
これにより、ギフトＩＤをユーザに共有させることができ、履歴として記録を残すことができる。

また、ギフトＩＤを投信取引サーバ４０を経由してユーザ側に通知するのではなく、電子マネー会社サーバ６０から直接通知することもできる。
また、ギフトＩＤをユーザが所持するユーザ端末３０を介してユーザに通知するのではなく、外部の端末装置（例えば、コンビニエンスストアのサービス端末や店員用端末など）を介してユーザに通知することもできる。

電子チャージ選択情報に基づき、出金方法として「ｄチャージ」が選択されていることが判定された場合は、電子マネー発注部４０７は、第２電子マネーを運営する電子マネー会社サーバ６０が提供するＡＰＩ（以下、ｄ−ＡＰＩという）を呼出す。
電子マネー発注部４０７は、ｄ−ＡＰＩを呼び出すと、メモリから出金額の情報を取出し、これを発注額として当該ＡＰＩに入力するとともに、ユーザの口座番号等をユーザ情報ＤＢ５０１から取り出して当該ＡＰＩに入力する。
なお、このように口座番号等を自動的に入力するのではなく、ユーザに入力させることもできる。

電子マネー会社サーバ６０は、ｄ−ＡＰＩ経由で口座番号等や発注額の情報を受け取ると、口座番号等の認証を行い、認証が得られた場合、発注額分の金銭をその口座番号の口座に送金（チャージ）する。
つまり、「ｄチャージ」の場合、ユーザの電子マネー口座に直接チャージが行われ、これにより、投資信託の換金の代金をユーザに受け渡すことができる。

出金方法選択画面において「現金での出金」が選択された場合、従来通り、投資信託の代金を現金でユーザに受け渡す処理を行う。
現金での出金は、従来からの方法を採用するため、詳細な説明は省略するが、電子チャージでの出金との主な相異点について以下に説明する。

出金方法選択画面の出金メニューにおいて「現金での出金」が選択されると、ユーザ端末３０の換金申込部３１２は、「出金方法として現金での出金が選択されたことを示す情報（現金選択情報）」を含む換金申込情報を投信取引サーバ４０の申込受付部に送信する。
投信取引サーバ４０の申込受付部４０２は、ユーザ端末３０から換金申込情報を受信すると、換金申込情報を受信した日を「申込日」として特定し、当該申込日の情報と前記現金選択情報とを対価算出部４０３に出力する。
なお、申込受付部４０２は、換金申込情報を受信することに基づいて換金の申込みを受け付けるが、換金申込情報に現金選択情報が含まれていることに基づき現金での代金受け渡しを求める第２申込みを受け付ける。

対価算出部４０３は、現金選択情報を入力することに基づいて、以下の処理を行う。
具体的には、換金対象の投資信託が国内商品の場合、申込日の翌営業日まで待って、申込日の基準価額を基準価額ＤＢ５０３から取得して、対価を算出する。
また、対価算出部４０３は、換金対象の投資信託が海外商品の場合、申込日の翌々営業日まで待って、申込日の翌営業日の基準価額を基準価額ＤＢ５０３から取得して、対価を算出する。従来のブラインド方式を採用するものである。

対価算出部４０３は、算出した対価の情報を現金受渡部４０８に出力する。
現金処理部４０８は、代金受渡部として機能することで、対価算出部４０３により算出された対価の現金をユーザに受け渡す処理を行う。
具体的には、投信口座を管理する銀行サーバ５に対し、対象の投資信託を売却する指図の情報（売却指図情報）を送信する。
銀行サーバ５は、投信取引サーバ４０から売却指図情報を受信すると、当該売却指図情報に示される内容に基づき換金対象の投資信託について売却処理を行うとともに、売却により得られた現金（代金）を信託口座から委託会社の口座に振り替える。
そして、振り替えられた代金を、投資家の指定口座に振り込む処理を行う。
これにより、投信取引システムＳとして、現金を投資信託の代金としてユーザに受け渡す処理が完了する。

このように、本発明の投信取引システムＳにおいては、電子マネーなどの電子有価財での代金受渡しを求む申込みを受け付けた場合、申込みを受け付けたときより前の時点における時価に基づいて算出した対価に相当する電子有価財を金融商品の換金の代金としてユーザに受け渡す処理を実行し、現金での代金受渡しを求む申込みを受け付けた場合、申込みを受け付けたときより後の時点における時価に基づいて算出した対価に相当する現金を金融商品の換金の代金としてユーザに受け渡す処理を実行するようにしている。
このため、ユーザは、自身がどちらの代金受渡し方法が良いかを考慮したうえで換金の申込みを行うことができる。

次に、本発明の金融商品取引方法に係る電子チャージ出金による換金処理の手順について図２１を参照しながら説明する。
図２１は、電子チャージ出金による換金処理を時系列に表したチャート図である。
図２１に示すように、電子チャージ出金に基づく換金処理では、まず、ユーザ端末３０において投資信託の換金の申込みを行う（Ｓ１０１）。
具体的には、出金方法選択画面（図１４）において「ｎチャージで出金」か「ｄチャージで出金」を選択する。

投信取引サーバ４０は、投資信託の換金の申込みを受け付ける（Ｓ１０２）と、申込みを受け付けた日の前営業日の基準価額を採用し（Ｓ１０３）、即時に対価・代金の算出を行う（１０４）。具体的には、基準価額と申込口数（換金口数）に基づき対価を算出し、算出結果に手数料及び課税額を控除した額を代金として算出することができる。
次に、投信取引サーバ４０は、電子マネー会社サーバ６０に対し、電子マネーの発注を行う（Ｓ１０５）。
具体的には、Ｓ１０４において算出した代金に相当する電子マネーに関する発注処理を行う。

そして、電子マネー会社サーバ６０は、発注額に対応するギフトＩＤの発行又はチャージを行う（Ｓ１０６）。
例えば、ｎチャージが選択された場合、Ｓ１０４において算出された代金のギフトＩＤを発行するとともに、当該ギフトＩＤをユーザ端末３０に送信する。

これにより、ユーザは、ユーザ端末３０を介して自身のｎカード等に代金額をチャージすることができる。
また、ｄチャージが選択された場合、Ｓ１０４において算出した代金の金銭がユーザの電子マネー口座にチャージされる。
このような手順に基づいて、投資信託の換金の代金としての電子マネーをユーザに受け渡すことができる。

以上のように、本発明の金融商品取引システム（投信取引システムＳ）は、ユーザ端末３０における操作に基づいて、ユーザが保有する金融商品（投資信託）の換金の申込みを受け付ける申込受付部と、申込受付部により金融商品の換金の申込みを受け付けた場合に、申込みを受け付ける前の時価（申込日の前営業日の基準価額）を取引基準価格として決定する取引基準価格決定部と、取引基準価格決定部により決定した取引基準価格に基づいて金融商品の対価を算出する対価算出部と、対価算出部により算出した対価に相当する所定の電子有価財（電子マネー）を金融商品の換金の代金としてユーザに受け渡す処理を実行する代金受渡部と、を備えている。

このような構成からなる本発明の投信取引システムＳによれば、投資信託の換金の申込みがあった場合にはその投資信託の換金の代金を即時にユーザに受け渡すことが可能になる。
このため、投資信託の取引を迅速に行うことができ、ユーザの利便性を向上することができる。
特に、図２２に示すように、従来の換金方法に比べ出金までの時間を大幅に短縮することができる。
図２２は、従来の換金方法（現金による出金方法）と、本発明の換金方法（電子チャージ出金方法）とを、時系列で比較できるように表した比較図である。
なお、便宜上、換金対象の投資信託は海外商品であるものとする。

図２２に示すように、従来の換金方法（現金での出金）では、換金の申込みがあった日（申込日）から、約定、対価・代金の算出、解約指図、を経てユーザ口座に現金が振り込まれる（受渡日）までに５営業日を要していた。また、ユーザ口座に資金移動業者を利用して振り込む場合、振込先金融機関に応じてさらに１営業日〜３営業日を要していた。
これに対し、本発明の換金方法である電子チャージ出金においては、従来の換金方法で行われる「解約指図」や「現金の振り込み」を必要としていない。
つまり、本発明においては、「解約指図」、解約指図に基づく保有資産の売却、当該売却で得た現金を用いた「現金の振り込み」を省くことができることに加え、対価・代金の算出、電子マネーの購入・チャージといった各処理をすべて即時に行われる結果、即時に出金を完了することができる。
このように、従来の換金では、複数の処理工程を一連に直列的に行っていたところ、本発明においては、その一部の処理工程を除外する（後処理に回す）ことで、迅速化を図っている。

また、本発明は、代金の受渡方法として電子マネーなどの電子有価財を採用している。
これにより、営業日か休日かを問わず、常時、換金処理を実行することができる。
また、ＡＰＩを活用することで、電子マネー会社サーバ６０とは、即時に電子マネーの購入及び受渡し（ギフトＩＤの送信、口座への送金等）ができるようになっている。
また、換金申込時に即時に対価を算出することで即時出金に貢献している。
具体的には、申込時に既知の直前（申込日の前営業日）の基準価額を採用することで、対価・代金の算出を即時に実行できるようにしている。
これに対し、従来では、ブラインド方式のもと、対価の算出を翌営業日まで待って（国内商品の場合）又は翌々営業日まで待って（海外商品の場合）行わざるを得なかった。
このため、本発明によれば、従来に比べ極めて迅速に換金を完了することができ、換金を望むユーザの利便を向上させることができる。

この他、本発明の投信取引システムＳは、以下の（１）〜（４）の特徴を有している。
（１）電子チャージ出金だけでなく、現金での出金を選択できるようにしている。
これにより、ユーザの好みで出金方法を選ぶことができるようになっている。
また、この点に関し、投信法第８条第１項には、「委託者指図型投資信託（主として換価の容易な資産に対する投資として運用することを目的とする投資信託であって受益者の保護に欠けるおそれがないものとして政令で定めるものを除く。）は、金銭信託でなければならない。」と定められているところ、本発明は、電子チャージ出金を選択肢で提示しているのみで、常に「現金で出金」を選択できるようにしているため、上記投信法に抵触しない。
つまり、単に現金での出金を電子チャージ出金に代えただけでは、上記投信法に抵触するおそれのあるところ、本発明では、電子チャージ出金と現金での出金を選択可能な構成にすることで、この問題を回避している。

（２）ブラインド方式を採用しないことでも他の投資家（他の受益者）に損害を与えない構成にしている。
ブラインド方式は投資家間の公平性の確保のためであるところ、電子チャージ出金の際に行われる受益権の売買は、ユーザと委託会社との間で個別に行われる相対取引である。
なお、委託会社は、ユーザから買い取った受益権は、後に売却するなど、自身の裁量で処理することになる（後記「後処理について」参照）。
このため、ブラインド方式を採用しない本発明の電子チャージ出金であっても、信託財産からの資金の流出を伴うものではなく、他の受益者に対して損害を与えることはない。
つまり、単にブラインド方式を採用しないだけでは他の受益者に損害を与えるおそれのあるところ、本発明では、そのような問題が生じないよう必要な措置を施している。

（３）前営業日の基準価額を採用することで、ユーザは解約代金を正確に把握したうえで換金の申込みができる。
（４）様々な要素を加味した手数料を設定可能である（前記（ｉ）〜（ｉｉ）及び後記「手数料について」参照）。

（応用例・変形例）
以下、応用例・変形例等について説明する。

（他の電子マネー等について）
上述の実施形態においては、第１電子マネーと第２電子マネーの２つの電子マネーを用いた代金の受渡方法について詳細に説明したが、これに限らず、他の電子有価財を用いることもできる。
例えば、nanaco（登録商標）などの第１電子マネーは、前払式支払手段としての共通型の電子マネー（プリペイド型電子マネー）であるが、スターバックス（登録商標）カードなどハウス型の電子マネーを本発明に適用することもできる。
この場合も、ｎチャージと同様、金額に紐付いたＩＤを、ユーザ端末３０を介してユーザに知らせるなどによりユーザのアカウントにその金額分の電子マネーをチャージすることができる。
また、他の共通型の電子マネー（例えば、Ｅｄｙ（登録商標）など）やギフトＩＤと同様のギフトコードを採用するamazon（登録商標）についても、勿論、本発明に適用することができる。
また、上述の実施形態において、第１電子マネー（前払式支払手段）については、ギフトＩＤを介した方法によりチャージすることについて説明したが、第１電子マネーにおいて、ギフトＩＤを介さず、第２電子マネー（資金移動）と同様に、サーバの電子マネー口座に直接チャージするようにもできる。

また、ドコモ口座などの第２電子マネー（資金移動）は、資金決済法を利用した送金機能（本人確認をすることで資金の移動が可能な機能）を備えた所謂電子ウォレットサービスであるが、この種の他の電子マネーサービス（例えば、ＬＩＮＥ（登録商標）Ｐａｙなど）を本発明に適用することもできる。
つまり、ＬＩＮＥ Ｐａｙにも本人確認に係る処理を予め行っておくことで、指定口座に送金することができるため、ドコモ口座と同様に換金の代金をユーザ口座に直接チャージすることができる。

また、Ｔポイント（登録商標）やFiNC（登録商標）ポイントなどのポイントサービスがあるが、この種のポイントサービスを本発明に適用することもできる。
例えば、Ｆｉｎｃポイントは、有効期限６ヶ月未満の場合には現金化ができ、現金での購入もできる。
このため、購入したポイントを対価としてユーザのアカウントに追加するといった実施形態をとることができる。
なお、ポイントは本発明の電子有価財の一例であるが、Ｆｉｎｃポイントのように現金化できるものは電子マネーにも該当する。
現金化できないポイントサービスであっても、商品・サービスの購入代金の一部に充当したり、商品・サービスと交換することが可能なポイントであれば、当然に本発明の電子有価財に該当する。

（手数料について）
電子チャージ出金における手数料は上記（ｉ）〜（ｉｉ）の他、様々な要素に基づいて設定することができる。
例えば、対象の電子マネーでの買い物／決済を一定期間内に一定回数又は一定金額以上した場合に手数料を低くすることができる。
「対象の電子マネー」は、例えば、電子チャージ出金に用いる電子マネーサービス（例えば第１電子マネーや第２電子マネー）とすることができる。
このようにすると、電子チャージ出金を利用するほど手数料を抑えることができるため電子チャージ出金の利用を促すことができる。
また、電子マネーの利用が促され、電子マネー会社にとっても他の電子マネーサービスよりも優位に事業を進めることができる。
委託会社にとっても、自身が運営する投信取引システムＳの活性化を促すことができる。

また、「対象の電子マネー」をお釣り運用サービスと連携している決済手段としての電子マネーにすることができる。
つまり、「対象の電子マネー」でお買い物をするユーザに対しては手数料を低く設定することができる。
また、「対象の電子マネー」でのお買い物の金額や頻度が多いほど手数料が低くなるように設定することもできる。
このようにすると、お買い物をするほどお釣りが増えるので、手数料を低減することができるとともに、お釣り運用サービスにおけるお釣りによる投資を増やすことができる。

また、お釣り運用サービスの登録を、対象の電子マネーのアプリやウェブサイトから行ったユーザに対しては手数料を低くすることができる。
例えば、電子マネーのアプリ画面において登録サイトのＵＲＬをリンク表示したり、電子マネー会社のウェブ画面においてお釣り運用サービスのバナーを表示させる。
そして、リンク又はバナーの選択により表示される登録サイトからユーザ登録を行ったユーザに対しては、手数料を低くする。

また、お釣り運用サービスにおけるお釣りによる投資額が、過去一定期間において一定の金額以上のユーザに対しては手数料を低くすることができる。
また、お釣り運用サービスにおけるお釣りによる投資総額が、一定の金額以上のユーザに対しては手数料を低くすることができる。
また、お釣り運用サービスの投信口座の残高の多寡に応じ、手数料を変動することもできる。
例えば、投信口座の残高が多いほど、手数料を低く設定することができる。
これにより、投資信託サービスの利用を促すとともに、電子マネーの利用を促すことができる。
なお、このような手数料の設定は、お釣り運用サービスだけでなく、通常の投資信託、その他の投資サービスにおいて適用することもできる。

（後処理について）
委託会社は、電子マネー会社に対し、ユーザに受け渡すために購入した電子マネーの代金の支払いを、電子チャージ出金後に行うようにしている。
この他、委託会社は、電子チャージ出金後の後処理として、ユーザから買い取った投資信託（受益権）を従来の投資信託上の慣習ルールに則って売却することができる。
図２３は、ユーザから買い取った受益権を売却する処理を説明するための図である。
なお、ユーザから買い取った受益権の売却の申込みを、電子チャージ出金が行われた日の翌営業日（Ｔ日とする）に行うものとする。

ここで、投信取引システムＳは、投資信託の取引に応じて金融商品取引法に従い顧客帳票（取引報告書等）を作成する。
従来の株式投信の換金取引では、投信取引システムＳで作成される顧客帳票は「申込日」、「約定日」及び「受渡日」が異なる日付となる。
従来の換金方法とはまったく異なる取引態様である電子チャージ出金では、これらの日付がすべて同じ日になるが、従来の投信取引システムではこれは想定されていない。

このため、投信取引システムＳにおいては、電子チャージ出金において、便宜上、後処理における「申込日」、「約定日」及び「受渡日」を適用して顧客帳票（取引報告書等）を作成することとした。
そうすると、後処理における買取受益権の解約処理は、従来の換金方式において行われるため、いわゆる投信窓販システムの機能により自動的に顧客帳票を作成することができる。
具体的にはユーザの換金リクエストを販売会社が受付けた日をＴ日とすると、顧客帳票に記載される「申込日」はＴ＋１営業日、「約定日」はＴ＋２営業日、「受渡日」はＴ＋６営業日となる。
ただし、顧客帳票の日付項目の読替え方法を帳票上で案内したり、実際の日付を設定するよう投信取引システムを改修したりもできる。
なお、振替機関（証券保管振替機構）は、図２３に示すように、ユーザに対する換金と引き換えに受益権がユーザから販売会社に移転するが、振替機構向けには即時出金後の翌々営業日に、顧客口から自己口への振替および自己口の抹消の申請を行い、受渡日に振替機関にて振替および抹消の処理を行う。

（即時出金の別の態様について）
前述した実施形態では、予め所得税及び住民税の源泉徴収額又は還付額を算出し、当該算出した源泉徴収額又は還付額を控除又は加算して出金する即時出金の態様について説明したが、これに限らず、即時出金時に多めに源泉徴収しておき、後に源泉徴収額又は還付額が確定した後に差額を追加出金する態様とすることもできる。
例えば、解約申込日をＴ日とした場合において、以下の（１）〜（４）のフローが想定される。
（１）Ｔ日：「買取約定金額」、「譲渡損益額」及び「即時出金額」を算出し、電子マネーにて出金。
・譲渡損益額＞０円の場合
「買取約定金額」＝出金口数×社内時価÷計算口数
「源泉徴収額」＝譲渡益×住民税率＋譲渡益×所得税率
「即時出金額」＝買取約定金額−源泉徴収額
なお、「社内時価」とは、即時出金日（解約申込日）の前営業日の基準価額からスプレッド（手数料）を控除した額のことをいう。
・譲渡損益額≦０円の場合
「買取約定金額」＝出金口数×社内時価÷計算口数
「源泉徴収額」＝０円
「即時出金額」＝買取約定金額
（２）Ｔ＋１日：投信窓販システムに買取注文ファイルを接続
（３）Ｔ＋２日：投信窓販システムが買取約定計算を実施。これにより、源泉徴収額又は還付額が確定。
（４）Ｔ＋３日：確定した源泉徴収額又は還付額に応じて次の通り電子マネーにて出金
・譲渡損益額＞０円の場合
出金額＝Ｔ日の源泉徴収額−確定した源泉徴収額
・譲渡損益額≦０円の場合
出金額＝確定した還付額
このように、本発明においては、即時出金時に予め源泉徴収額又は還付額を加味して出金する態様や、段階的に出金する態様など、複数の出金態様を選択的に採用することができる。

以上、本発明について、好ましい実施形態を示して説明したが、本発明は、上述した実施形態に限定されるものではなく、本発明の範囲で種々の変更実施が可能であることは言うまでもない。
例えば、上述した実施形態は、本発明をお釣り運用サービスにおける投資信託の換金処理に適用した一例であるが、本発明を通常の投資信託の換金処理に適用することは当然にできる。
また、この場合、電子チャージ出金において設けられる手数料を、上記「手数料について」にて説明した内容と同様に様々な観点で設定することもできる。
例えば、投資総額や投信口座の残高に応じ手数料を変動することができる。

また、本発明を、他の金融商品の取引に適用することができる。
例えば、定期的に金利が変わる金利変動型の定期預金など、時価変動型の金融商品を途中解約する場合に、手数料を差し引かれたり金利が下げられるタイプの金融商品がある。
この種の金融商品において、任意のタイミングでの換金が可能である場合には、過去の直近の時価に基づいて商品の対価を算出し、算出された額の電子マネーをユーザに受け渡すようにすることができる。
また、金融商品の換金だけでなく、金融商品の購入にも本発明を適用することができる。
例えば、金融商品の購入申込時の直前の既知の時価に基づいてその商品の購入額を算出し、当該購入額の電子マネーを購入して販売先に受け渡すことと引き換えにユーザが金融商品を取得できるようにすることができる。

また、投信取引サーバ４０が認証部４０１を備えることで、投信取引システムＳとしてユーザ認証機能を備えているが、必ずしも、投信取引サーバ４０が認証部４０１を備える必要もなく、他の装置に認証部を備える態様であってもよい。
さらには、投信取引サーバ４０や投信取引システムＳがユーザ認証機能を有する必要はなく、例えば、資金運用システム１の装置等、ネットワークでつながれた外部装置にユーザ認証機能があれば、投信取引システムＳは、その機能を利用することで足りる。

また、図１５に示すように、前述の実施形態では、出金の際、ユーザ端末３０の操作画面にユーザの口数残高を表示し、当該残高口数の範囲内で口数を入力することで、当該入力された口数の解約によって、当該解約口数に対応する金額の電子マネーがチャージされるようにしたが、このような方法に限るものではない。
例えば、チャージしたい金額を入力するようにもできる。
この場合、ユーザ端末３０の操作画面に金額入力欄を設けることで、チャージしたい金額を金額入力欄に入力できるようにできる。
なお、金額入力欄と共に口座残高（金額）を表示するようにして、チャージ可能な金額をユーザに示すこともできる。
金額が入力されると、投信取引サーバ４０において、直近の基準価額、手数料、税金調整額を求め、これらを加味した口数を算出する。
具体的には、入力金額を超える最小の口数を算出することができる。
より具体的には、下記式の算出結果を超える最小の口数を算出する。
[（入力金額＋税金調整額）／(１−手数料率)］／前営業日の基準価額
例えば、入力金額が３０００円、前営業日の基準価額が１２０００円／１万口、手数料率が５％、課税額が１００円とすると、［（３０００＋１００）／（１−０．０５）］／１．２＝２７１９．３という算出結果になることから、２７２０が口数として算出される。
そして、この結果、３２６４円（≒２７２０×１．２）から手数料（１６３円）及び課税額（１００円）が引かれた３００１円分の電子マネーがチャージされることになる。
このような方法によれば、ユーザは、まさに使いたい金額を入力することができるため、出金時の利便性をさらに向上させることができる。
なお、口数の算出においては、上述した「入力金額を超える最小の口数」以外にも、例えば「入力金額を超えない最大の口数（前述の例の場合２７１９口）」や「入力金額に最も近い口数」を採用してもよく、これらを選択的（例えばユーザに選択させるなど）に採用することもできる。また、「超える」、「超えない」の代わりに「以上」、「以下」であってもよい。

本発明は、投資信託などの金融商品の取引において好適に利用することができる。

Ｓ 投信取引システム
３０ ユーザ端末
３１２ 換金申込部
４０ 投信取引サーバ
４０２ 申込受付部
４０３ 対価算出部
４０４ 手数料算出部
４０６ 取引基準価格決定部
４０７ 電子マネー発注部
５０ 業務支援サーバ
６０ 電子マネー会社サーバ
６０１ 電子マネー処理部（代金受渡部）

Claims (10)

1. ユーザ端末と情報処理装置とを備えた金融商品取引システムであって、
   前記情報処理装置は、
   前記ユーザ端末における操作に基づいて、ユーザが保有する金融商品の換金の申込みを受け付ける申込受付部と、
   前記申込受付部により金融商品の換金の申込みを受け付けた場合に、前記申込みを受け付けたときより前の時点における時価を取引基準価格として決定する取引基準価格決定部と、
   前記取引基準価格決定部により決定した取引基準価格に基づいて前記金融商品の対価を算出する対価算出部と、
   前記対価算出部により算出した対価に相当する所定の電子有価財を、前記金融商品の換金の代金として前記ユーザに受け渡す処理を実行する代金受渡部と、を備えた
   ことを特徴とする金融商品取引システム。
2. 前記電子有価財には、所定の電子マネーが含まれる
   ことを特徴とする請求項1に記載の金融商品取引システム。
3. 前記電子有価財には、所定のポイントサービスにおいて付与されるポイントが含まれる
   ことを特徴とする請求項１又は２に記載の金融商品取引システム。
4. 前記金融商品には、投資信託が含まれ、
   前記取引基準価格決定部は、前記申込受付部により前記投資信託の換金の申込みを受け付けた場合、申込みを受け付けた日の前営業日の基準価額を前記取引基準価格として決定する
   ことを特徴とする請求項１〜３のいずれか一項に記載の金融商品取引システム。
5. 所定操作に基づいて、ユーザが保有する金融商品の換金の申込みとして、前記電子有価財の受渡しを求める第１申込みと、現金の受渡しを求める第２申込みとを行うことが可能な換金申込部を備え、
   前記代金受渡部は、前記申込受付部において前記第１申込みを受け付けた場合、前記申込みを受け付けたときより前の時点における時価に基づいて算出した対価に相当する電子有価財を前記金融商品の換金の代金として前記ユーザに受け渡す処理を実行し、前記申込受付部において前記第２申込みを受け付けた場合、前記申込みを受け付けたときより後の時点における時価に基づいて算出した対価に相当する現金を前記金融商品の換金の代金として前記ユーザに受け渡す処理を実行する
   ことを特徴とする請求項１〜４のいずれか一項に記載の金融商品取引システム。
6. 所定の手数料を設定する手数料設定部を備え、
   前記代金受渡部は、前記対価算出部により算出した対価から前記手数料を減じた額に基づく額の電子有価財を前記金融商品の換金の代金として前記ユーザに受け渡す処理を実行し、
   前記手数料設定部は、前記申込受付部において前記第１申込みを受け付けた場合、前記電子有価財を前記ユーザが受け取ることによるユーザの利益を加味して前記手数料を設定可能である
   ことを特徴とする請求項５に記載の金融商品取引システム。
7. 前記手数料設定部は、ユーザが保有する金融商品を委託者が購入したときの時価と、委託者がユーザから購入した前記金融商品を換金するときの時価との変動を加味して前記手数料を設定可能である
   ことを特徴とする請求項６に記載の金融商品取引システム。
8. 情報処理装置を、
   ユーザ端末における操作に基づいて、ユーザが保有する金融商品の換金の申込みを受け付ける申込受付部、
   前記申込受付部により金融商品の換金の申込みを受け付けた場合に、前記申込みを受け付けたときより前の時点における時価を取引基準価格として決定する取引基準価格決定部、
   前記取引基準価格決定部により決定した取引基準価格に基づいて前記金融商品の対価を算出する対価算出部、
   前記対価算出部により算出した対価に相当する所定の電子有価財を、前記金融商品の換金の代金として前記ユーザに受け渡す処理を実行する代金受渡部、として機能させる
   ことを特徴とするプログラム。
9. 情報処理装置が、
   前記ユーザ端末における操作に基づいて、ユーザが保有する金融商品の換金の申込みを受け付ける第１ステップと、
   前記第１ステップにより金融商品の換金の申込みを受け付けた場合に、前記申込みを受け付けたときより前の時点における時価を取引基準価格として決定する第２ステップと、
   前記第２ステップにより決定した取引基準価格に基づいて前記金融商品の対価を算出する第３ステップと、
   前記第３ステップにより算出した対価に相当する所定の電子有価財を、前記金融商品の換金の代金として前記ユーザに受け渡す処理を実行する第４ステップと、を有する
   ことを特徴とする金融商品取引方法。
10. 前記金融商品を売却する処理を前記第４ステップより後に行う
    ことを特徴とする請求項９に記載の金融商品取引方法。

Images