IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 株式会社野村総合研究所の特許一覧 ▶ TORANOTEC株式会社の特許一覧

特許7160969金融商品取引システム、プログラム及び金融商品取引方法
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2022-10-17
(45)【発行日】2022-10-25
(54)【発明の名称】金融商品取引システム、プログラム及び金融商品取引方法
(51)【国際特許分類】
   G06Q 40/06 20120101AFI20221018BHJP
   G06Q 20/36 20120101ALI20221018BHJP
【FI】
G06Q40/06
G06Q20/36
【請求項の数】 9
(21)【出願番号】P 2021016145
(22)【出願日】2021-02-03
(65)【公開番号】P2021125263
(43)【公開日】2021-08-30
【審査請求日】2021-02-10
(31)【優先権主張番号】P 2020017228
(32)【優先日】2020-02-04
(33)【優先権主張国・地域又は機関】JP
(73)【特許権者】
【識別番号】000155469
【氏名又は名称】株式会社野村総合研究所
(73)【特許権者】
【識別番号】516308478
【氏名又は名称】TORANOTEC株式会社
(74)【代理人】
【識別番号】110002354
【氏名又は名称】弁理士法人平和国際特許事務所
(72)【発明者】
【氏名】中澤 剛太
(72)【発明者】
【氏名】竹内 祐介
(72)【発明者】
【氏名】武藤 史弥
(72)【発明者】
【氏名】三谷 祐介
【審査官】青柳 光代
(56)【参考文献】
【文献】特開2015-014897(JP,A)
【文献】特開2019-095899(JP,A)
【文献】特開2002-041798(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
G06Q 10/00 - 99/00
G16H 10/00 - 80/00
(57)【特許請求の範囲】
【請求項1】
ユーザ端末と情報処理装置とを備えた金融商品取引システムであって、
前記情報処理装置は、
日毎に変動する金融商品の基準価格を、日毎に記憶する基準価格記憶手段と、
前記ユーザ端末における操作に基づいて、ユーザが保有する金融商品の換金の申込みを受け付ける申込受付部と、
前記申込受付部により金融商品の換金の申込みを受け付けたことに応じて前記基準価格記憶手段に記憶されている、前記申込みを受け付けた日の前営業日の基準価格を取引基準価格として決定する取引基準価格決定部と、
前記取引基準価格決定部が取引基準価格を決定したことに応じて、当該決定した取引基準価格に基づいて前記金融商品の対価を算出する対価算出部と、
前記対価算出部が対価を算出したことに応じて、当該算出した対価に相当する電子マネーを、前記申込受付部により金融商品の換金の申込みを受け付けたタイミングで、前記ユーザが管理する記録媒体又は口座に加算した態様で記憶する代金受渡部と、を備えた
ことを特徴とする金融商品取引システム。
【請求項2】
前記代金受渡部は、
遅くとも、前記申込受付部により金融商品の換金の申込みを受け付けた日に、前記対価算出部が対価を算出した対価に相当する電子マネーを、前記ユーザが管理する記録媒体又は口座に加算した態様で記憶可能である
ことを特徴とする請求項1に記載の金融商品取引システム。
【請求項3】
前記申込受付部は、
所定操作に基づいて、ユーザが保有する金融商品の換金の申込みとして、前記電子マネーの受渡しを求める第1申込みと、現金の受渡しを求める第2申込みとを行うことが可能であり、
前記取引基準価格決定部は、
前記第1申込みを受け付けた場合、前記申込みを受け付けたタイミングで、当該受け付けた日の前営業日の基準価格を取引基準価格として決定し、前記第2申込みを受け付けた場合、前記申込みを受け付けた日の後に、当該受け付けた日の基準価格を取引基準価格として決定する
ことを特徴とする請求項1又は2に記載の金融商品取引システム。
【請求項4】
前記金融商品には、投資信託が含まれ、
前記申込受付部により前記投資信託の換金の申込みを受け付けたことに応じて、前記申込みを受け付けた日の前営業日の基準価額を取引基準価格として決定する
ことを特徴とする請求項1~3のいずれか1項に記載の金融商品取引システム。
【請求項5】
即時に出金する場合のコストに対応した手数料を設定可能な手数料設定部を備え、
前記代金受渡部は、前記対価算出部により算出した対価から前記手数料を減じた額に基づく額の電子マネーを、前記申込受付部により金融商品の換金の申込みを受け付けたタイミングで、前記ユーザが管理する記録媒体又は口座に加算した態様で記憶可能である
ことを特徴とする請求項1~4のいずれか1項に記載の金融商品取引システム。
【請求項6】
前記手数料設定部は、前記申込受付部により金融商品の換金の申込みを受け付けたときにユーザが保有する金融商品を委託者が購入したときの基準価格と、前記申込みを受け付けた後で委託者がユーザから購入した前記金融商品を換金するときの基準価格との変動に対応した前記手数料を設定可能である
ことを特徴とする請求項5に記載の金融商品取引システム。
【請求項7】
前記代金受渡部は、
前記対価算出部が対価を算出したことに応じて、当該算出した対価に相当するポイントを、前記申込受付部により金融商品の換金の申込みを受け付けたタイミングで、前記ユーザが管理する記録媒体又は口座に加算した態様で記憶する
ことを特徴とする請求項1~6のいずれか1項に記載の金融商品取引システム。
【請求項8】
情報処理装置を、
日毎に変動する金融商品の基準価格を、日毎に記憶する基準価格記憶手段、
ユーザ端末における操作に基づいて、ユーザが保有する金融商品の換金の申込みを受け付ける申込受付部、
前記申込受付部により金融商品の換金の申込みを受け付けたことに応じて前記基準価格記憶手段に記憶されている、前記申込みを受け付けた日の前営業日の基準価格を取引基準価格として決定する取引基準価格決定部、
前記取引基準価格決定部が取引基準価格を決定したことに応じて、当該決定した取引基準価格に基づいて前記金融商品の対価を算出する対価算出部、
前記対価算出部が対価を算出したことに応じて、当該算出した対価に相当する電子マネーを、前記申込受付部により金融商品の換金の申込みを受け付けたタイミングで、前記ユーザが管理する記録媒体又は口座に加算した態様で記憶する代金受渡部、として機能させる
ことを特徴とするプログラム。
【請求項9】
日毎に変動する金融商品の基準価格を、日毎に記憶する情報処理装置が、
ーザ端末における操作に基づいて、ユーザが保有する金融商品の換金の申込みを受け付ける第1ステップと、
前記第1ステップにより金融商品の換金の申込みを受け付けたことに応じて前記基準価格記憶手段に記憶されている、前記申込みを受け付けた日の前営業日の基準価格を取引基準価格として決定する第2ステップと、
前記第2ステップにより前記取引基準価格決定部が取引基準価格を決定したことに応じて、当該決定した取引基準価格に基づいて前記金融商品の対価を算出する第3ステップと、
前記第3ステップにより前記対価算出部が対価を算出したことに応じて、当該算出した対価に相当する電子マネーを、前記申込受付部により金融商品の換金の申込みを受け付けたタイミングで、前記ユーザが管理する記録媒体又は口座に加算した態様で記憶する第4ステップと、を有する
ことを特徴とする金融商品取引方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、金融商品の取引に関する処理を実行する金融商品取引システムと、それに用いられるプログラム及び金融商品取引方法に関する。
【背景技術】
【0002】
従来から、株式、FX(Foreign Exchange:外国為替証拠金取引)、債券、投資信託、不動産、先物、金相場、預金及び外貨預金等の金融商品(以下、「商品」ともいう)が知られている。
例えば、投資信託は、投資信託委託会社(以下、「委託会社」という)が、投資家から集めた資金を基に株式、債権、不動産等への投資・運用を行い、これにより得られた利益を投資家に還元する仕組みとなっている。
また、投資信託では、投資家は、商品である投資信託受益証券(受益権ともいう)を任意のタイミングで換金することができる。
以下、換金の手順を説明する。なお、「換金」には、証券会社などの販売会社に投資信託受益証券を買い取ってもらう「買取」による方法と、販売会社を通して、信託財産の一部を解約する「解約」による方法とがある。ここでは、「解約」による方法を例示して説明するが、「買取」による方法もほぼ同様の手順であることから詳細な説明は省略する。
(a)投資家が、販売会社に換金を申し込む。
(b)販売会社は、商品(投資信託受益証券)の換金申込みがあった場合、投資信託受益証券の発行者である委託会社に一部解約の連絡をする。ただし、解約代金の確定値の連絡は、解約基準価額の算定日(約定日)の翌営業日になる。(投資信託の解約基準価額は、投資家の換金の申込日又はその翌営業日の基準価額を時価として算出する。投資家の換金額(解約代金)は、解約基準価額により算出される。)
(c)委託会社は、販売会社から一部解約の連絡を受け付けると、解約代金の計算をした上で信託銀行(受託会社)に一部解約の指図を行う。ただし、指図を行うのは、解約基準価額の算定日(約定日)の翌営業日になる。
(d)受託会社は、受け付けた一部解約の指図に係る支払い開始日に、解約代金を投資信託の信託口座から委託会社の口座に振り替える。
(e)委託会社は、(d)で振り替えられた解約代金を、販売会社に送金し、販売会社が投資家の指定口座に解約代金を振り込む等により換金処理が終了する。
例えば、特許文献1には、投資信託の解約に関する各種処理を行うシステムが開示されている。
【先行技術文献】
【特許文献】
【0003】
【文献】特開2005-266889号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
しかしながら、従来のシステムでは、以下の理由から換金に時間が掛かっていた。
具体的には、委託会社は、投資家から(販売会社を通じて)解約の申込みを受け付けた場合、解約代金の支払開始日に当該解約代金を(販売会社を通じて)支払うことになるが、そのためには、投資信託の信託財産から解約代金相当額を出金する必要がある。
具体的には、投資信託の信託財産は、運用方針に従い投資対象である資産(主に有価証券)を保有しており、解約の申込みを受け付けた場合は、保有する資産を売却して現金化する必要がある。
そのため、保有資産の売却に必要な期間を考慮して解約代金の支払い開始日が設定されているために時間が掛かっていた。
特に、主要投資先が海外の場合、海外市場の休業日も考慮されて支払開始日が設定される。また、時差の関係により、解約申込日における投資信託が保有する資産の海外市場の時価の取り込みが翌営業日になることから、翌営業日の基準価額を当該解約申込日の時価として採用するため、主要投資先が国内の場合に比べ1営業日余計に掛かる。
このため、主要投資先が海外の場合、実際には、以下に示すように、「解約申込日(T日)」から「支払開始日」までには、最低5営業日掛かっていた。
T日:顧客の申込日(解約申込日)
T+1営業日:解約基準価額の算出日(約定日)
T+2営業日:解約代金の確定、保有資産の売却の発注(2~3営業日)
T+5営業日:保有資産の受渡し、支払い開始日
【0005】
また、この種の金融商品の取引には多くの機関が関与しており、上記(a)~(e)に示すように、各機関における処理を順序通り直列的に行う結果、一連の換金処理を完了するのに相当の期間を要していた。
【0006】
また、投資信託の換金の申込みには締め切り時刻(多くは15:00)が設定されており、その日の基準価額は、締め切り後の夜間に算出されるため、ユーザは、正確な基準価額を把握せずに売買の申込みを行わなければならなかった(ブラインド方式)。
ブラインド方式は、基準価額が確定・公表された後に投資信託の取引ができるとすると、投資信託を保有している投資家の利益が阻害されるおそれがあることから、これを防止するため、すなわち、公平性確保のために採用されている方式である。
しかしながら、ブラインド方式を採用するゆえに、申込後にすぐに対価の算出など取引内容を確定することができず、このことも出金処理を遅らせる原因にもなっていた。
【0007】
本発明は、以上のような従来の技術が有する課題を解決するために提案されたものであり、投資信託などの金融商品の換金において、換金申込時における直前の既知の時価に基づいて商品の対価を即座に算出するとともに、現金の代わりに電子マネーなどの電子有価財をユーザに即座に受け渡すことで、即時の換金を可能とする金融商品取引システムとそれに用いられるプログラム及び金融商品取引方法の提供を目的とする。
【課題を解決するための手段】
【0008】
上記目的を達成するため、本発明の金融商品取引システムは、ユーザ端末と情報処理装置とを備えた金融商品取引システムであって、前記情報処理装置は、日毎に変動する金融商品の基準価格を、日毎に記憶する基準価格記憶手段と、前記ユーザ端末における操作に基づいて、ユーザが保有する金融商品の換金の申込みを受け付ける申込受付部と、前記申込受付部により金融商品の換金の申込みを受け付けたことに応じて前記基準価格記憶手段に記憶されている、前記申込みを受け付けた日の前営業日の基準価格を取引基準価格として決定する取引基準価格決定部と、前記取引基準価格決定部が取引基準価格を決定したことに応じて、当該決定した取引基準価格に基づいて前記金融商品の対価を算出する対価算出部と、前記対価算出部が対価を算出したことに応じて、当該算出した対価に相当する電子マネーを、前記申込受付部により金融商品の換金の申込みを受け付けたタイミングで、前記ユーザが管理する記録媒体又は口座に加算した態様で記憶する代金受渡部と、を備えた構成としてある。
【0009】
また、本発明は、上記のような本発明に情報処理装置で実行されるプログラムとして構成することができる。
さらに、本発明は、上記のような本発明に係る情報処理装置によって実施可能な金融商品取引方法として構成することもできる。
【発明の効果】
【0010】
本発明によれば、投資信託等の金融商品を換金する場合の代金を即時にユーザに受け渡すことができる。
【図面の簡単な説明】
【0011】
図1】資金運用支援システムの全体構成を示す図である。
図2】家計簿サーバ装置及び資金運用支援サーバ装置のハードウェア構成を示す図である。
図3】ユーザ端末のハードウェア構成を示す図である。
図4】資金運用支援システムを実現する機能構成を示すブロック図である。
図5】蓄積されている差額の一例を示す図である。
図6】表示された承諾要求の一例を示す図である。
図7】表示された差額の履歴の一例を示す図である。
図8】本発明の金融商品取引システムの一実施形態に係る投信取引システムの全体構成を示す図である。
図9】投信取引システムを実現する機能構成を示すブロック図である。
図10】ユーザ情報DBの一例を示す図表である。
図11】口座情報DBの一例を示す図表である。
図12】基準価額DBの一例を示す図表である。
図13】ホーム画面の一例である。
図14】出金方法選択画面の一例である。
図15】出金内容入力画面の一例である。
図16】出金内容確認画面の一例である。
図17】出金手続完了画面の一例である。
図18】ギフトID通知画面の一例である。
図19】第1電子マネーの専用サイトのチャージ画面の第1の例である。
図20】第1電子マネーの専用サイトのチャージ画面の第2の例である。
図21】電子チャージ出金による換金処理を時系列に表したチャート図である。
図22】従来の出金方法(現金による出金方法)と、本発明の出金方法(電子チャージによる出金方法)とを、時系列で比較できるように表した比較図である。
図23】電子チャージ出金後の後処理等を説明するための図である。
【発明を実施するための形態】
【0012】
以下、本発明の金融商品取引システムの実施形態について、図面を参照しつつ説明する。
ここで、金融商品取引システムは、プログラム(ソフトウェア)の命令によりコンピュータで実行される処理,手段,機能によって実現される。プログラムは、コンピュータの各構成要素に指令を送り、以下に示す本発明に係る所定の処理や機能等を行わせることができる。すなわち、本発明における各処理や手段,機能は、プログラムとコンピュータとが協働した具体的手段によって実現される。
【0013】
なお、プログラムの全部又は一部は、例えば、磁気ディスク,光ディスク,半導体メモリ,その他任意のコンピュータで読取り可能な記録媒体により提供され、記録媒体から読み出されたプログラムがコンピュータにインストールされて実行される。また、プログラムは、記録媒体を介さず、通信回線を通じて直接にコンピュータにロードし実行することもできる。また、本発明に係る金融商品取引システムは、単一の情報処理装置(例えば1台のパーソナルコンピュータ等)で構成することもでき、複数の情報処理装置(例えば複数台のサーバコンピュータ群等)で構成することもできる。
以下、本発明の具体的な実施例について説明するが、本発明は、その技術的思想に含まれるものであれば種々変形、変更することが可能であり、以下の実施例に限定されるものではない。
【0014】
説明の便宜上、まず、金融商品取引システムと連携する資金運用支援システムについて説明し、その後に、金融商品取引システムについて説明する。
【0015】
[資金運用支援システム]
図1は資金運用支援システムの全体構成を示す図である。
資金運用支援システム1は、商取引(買い物)においてユーザがお金を支払った際に生じるお釣りを資金運用に充てることを支援するシステムである。ここでいうユーザは、お釣りを資金運用に充てるお釣り運用サービスを利用するユーザであり、資金運用支援システム1において登録されているユーザである。
ユーザの登録は、例えば、所定のアプリ又はウェブサイトから所定のユーザ情報(所望のユーザID及びパスワードなど)の入力等の申込みを行うことで実行される。
つまり、資金運用支援システム1におけるユーザ登録を行うことで、お釣り運用サービスのユーザとして登録が行われる。
資金運用支援システム1は、このお釣り運用サービスを提供する事業者が中心となって運用されている。
【0016】
資金運用とは、利益を得る目的で資金を運用することであり、具体的には、株式、FX、債券、投資信託、不動産、先物、金相場、預金及び外貨預金等の金融商品に資金を投資することにより行われる。
【0017】
商取引におけるお金の支払いとは、例えば店舗等で商品を購入する際に行われる支払いであるが、それ以外にも、電車の切符の購入、病院での治療費の支払い、光熱費や通信費のような毎月の使用料金の支払い及び住宅ローンのような分割払い等も含められる。なお、お釣り運用サービスとは関係なくユーザ自身が独自に行った資金運用のための支払い(例えばユーザが証券会社の金融商品を独自に購入する際に行う支払い)も、前述した「商取引におけるお金の支払い」に含めてもよい。
【0018】
また、お釣り運用サービスにおける前記商取引におけるお金の支払いには、クレジットカード、電子マネー及び口座からの引き落とし等、1円単位で支払うため通常はお釣りが生じない決済手段によるものが含まれるが、お釣り運用サービスは、これらの支払いについても、仮に現金で100円単位や1000円単位で支払われたとしたら生じると想定されるお釣り(端数)を資金運用に充てることができるように各決済手段と連携がなされているものとする。
また、これらの決済手段は、クレジットカード会社、電子マネー会社、銀行の違いから様々あるが、これらのうち、上記連携によりお釣りを資金運用(投資)に充てる決済手段をユーザが登録できるものとする。
具体的には、ユーザは、お釣りを認識する決済手段を自身が使用するユーザ端末30のアプリに登録することができる。
【0019】
資金運用支援システム1は、ネットワーク2と、決済代行サーバ3と、銀行サーバ4と、銀行サーバ5と、資金運用サーバ装置6と、家計簿サーバ装置10と、資金運用支援サーバ装置20と、ユーザ端末30とを備える。ネットワーク2は、移動体通信網及びインターネット等を含む通信システムであり、自システムに接続される装置同士のデータのやり取りを仲介する。ネットワーク2には、ユーザ端末30以外の各装置が有線通信で接続されており、ユーザ端末30が無線通信で接続されている。なお、ネットワーク2との接続は有線通信及び無線通信のどちらでもよい。
【0020】
決済代行サーバ3は、商取引で発生する決済処理を代行する決済代行会社が運用するサーバである。
銀行サーバ4及び銀行サーバ5は、銀行の口座を管理する(詳細には口座に収められているお金を管理する)サーバであり、口座への入金処理及び口座からの出金処理を行う。
本実施形態において、銀行サーバ4は、ユーザが利用する銀行でユーザの利用可能なお金が収められた口座を管理するサーバであり、銀行サーバ5は、委託会社の運用のもと、投資の資金を管理する信託銀行の投信口座を管理するサーバであるものとする。
【0021】
ここでいう「ユーザの利用可能なお金」とは、「お釣り運用サービス」において運用される資金の元手となり得るお金のことである。ユーザの利用可能なお金が収められた口座は、ユーザが開設した口座に限らない。例えばユーザが利用する証券会社、通信事業者、電力会社、ガス会社、決済代行会社、通信販売会社及びC2C(Consumer to Consumer)サービス会社等が利用する、ユーザが支払ったお金を収めるための口座であってもよい。また、ポイントサービスを提供している事業者がユーザに付与したポイントに相当するお金を収めている口座であってもよい。
【0022】
各事業者との取り決めにより、ユーザがそれらの口座に支払額以上のお金を収めておくことで、余ったお金を資金運用に充てることができる。それらの場合、事業者の口座を保有する銀行の銀行サーバ、又は、各事業者がその口座を管理するために設けたサーバが、ユーザの利用可能なお金が収められた口座を管理するサーバとして用いられる。資金運用サーバ装置6は、銀行サーバ5が管理する投信口座の資金を運用する処理及び運用実態を資金運用支援サーバ装置20に提供する処理等を実行する。
【0023】
家計簿サーバ装置10は、ユーザの家計情報を蓄積する装置である。家計情報には、少なくともユーザの支出を示す支出情報が含まれる。支出情報は、食費、被服費、娯楽費、医療費、交際費、教育費、車両費、光熱費及び住居費等を示す情報である。これらの支出には、厳密には家族などユーザと家計をともにする者の支出も含まれているが、本実施例では、そのような支出もユーザの支出として捉えるものとする。家計簿サーバ装置10は、これらの支出情報を、ユーザ端末30から取得したり、金融機関が提供する個人向けサイト(ユーザの口座を用いた取引の履歴が掲載されたサイト。例えばインターネットバンキングのサイト)から取得したりする。
【0024】
資金運用支援サーバ装置20は、お釣り運用サービスをユーザに提供するための処理を行う情報処理装置である。資金運用支援サーバ装置20は、家計簿サーバ装置10から支出情報を取得する処理、お釣りを算出する処理、お釣りを資金運用に充てることの承諾をユーザに要求する処理、及び、承諾が得られたお釣りと同等の金額をユーザ口座から資金運用用の投信口座に移すための処理等を行う。
【0025】
ユーザ端末30は、ユーザが利用する端末装置であり、例えばスマートフォン、タブレット端末又はパーソナルコンピュータ等である。ユーザ端末30は、家計簿サーバ装置10にアクセスする操作(ユーザID、パスワードの入力操作)の受け付け、ユーザの家計情報(特に支出情報)の入力操作の受付、蓄積された家計情報の表示、資金運用支援サーバ装置20からの上記要求の表示、その要求に対して承諾・拒否のいずれかを回答する操作の受け付け、及び、回答結果の通知処理等を行う。
【0026】
図2は家計簿サーバ装置10及び資金運用支援サーバ装置20のハードウェア構成を示す図である。
これらの装置は、いずれも、プロセッサ11と、メモリ12と、ストレージ13と、通信装置14と、入力装置15と、出力装置16とを備えるコンピュータである。プロセッサ11は、オペレーティングシステムを動作させてコンピュータ全体を制御する。プロセッサ11は、周辺装置とのインターフェース、制御装置、演算装置及びレジスタ等を含む中央処理装置(CPU)を備える。
【0027】
プロセッサ11は、プログラム(プログラムコード)、ソフトウェアモジュール及びデータ等を、ストレージ13や通信装置14からメモリ12に読み出し、これらに従って各種の処理を実行する。メモリ12は、コンピュータが読み取り可能な記録媒体であり、例えば、ROM、EPROM、EEPROM及びRAM等である。
【0028】
ストレージ13は、コンピュータが読み取り可能な記録媒体であり、例えば、ハードディスクドライブ、フレキシブルディスク及びフラッシュメモリ等である。ストレージ13は、補助記憶装置と呼ばれてもよい。通信装置14は、有線及び/又は無線ネットワークを介してコンピュータ間の通信を行うためのハードウェア(送受信デバイス)であり、例えばネットワークデバイス、ネットワークコントローラ、ネットワークカード、通信モジュールなどともいう。
【0029】
入力装置15は、外部からの入力を受け付ける入力デバイス(例えば、キーボード、マウス、マイクロフォン、スイッチ、ボタン、センサなど)である。出力装置16は、外部への出力を実施する出力デバイス(例えば、ディスプレイ、表示パネル、スピーカー、LEDランプなど)である。なお、入力装置15及び出力装置16は、一体となった構成(例えば、タッチスクリーン)であってもよい。
【0030】
なお、一切の物理的な入力を待たず自律的かつ定期的に実行される処理(いわゆるバッチ処理)がこの入力に置き換わってもよいし、ユーザ端末30がGPS(Global Positioning System)等の測位手段を備えている場合に、特定の位置が測定されたときに実行される処理がこの入力に置き換わってもよい。また、ワイヤレスネットワークに接続された物理ボタンが用いられてもよい(この物理ボタンを押すと貯まっているお釣りを資金運用に充てることの承諾を一括で行うなど)。また、上記のハードウェア構成は、仮想化されたリソースで提供されてもよい(各サーバ装置がクラウドコンピューティングシステム上に構築される場合など)。
【0031】
図3はユーザ端末30のハードウェア構成を示す図である。
ユーザ端末30は、プロセッサ31と、メモリ32と、ストレージ33と、通信装置34と、入力装置35と、出力装置36と、撮像装置37とを備えるコンピュータである。プロセッサ31から出力装置36までは、図2に示す同名の各装置と共通するハードウェアである。撮像装置37は、レンズ及び撮像素子等を備え、レンズから入射する光が表す周囲の人物や光景を撮影する。撮像装置37は、撮影した画像を示す画像データをプロセッサ31に供給する。なお、ディスプレイ、表示パネルなどの表示デバイスを表示部36とも称する。
【0032】
資金運用支援システム1が備える各装置のプロセッサがプログラムを実行して各部を制御することで、以下に述べる機能が実現される。
図4は資金運用支援システム1が実現する機能構成を示す図である。
【0033】
家計簿サーバ装置10は、収入情報取得部101と、支出情報取得部102と、家計情報蓄積部103とを備える。
資金運用支援サーバ装置20は、支払額取得部201と、差額算出部202と、差額取得部203と、差額蓄積部204と、要求時期判断部205と、承諾要求部206と、承諾可否受付部207と、撤回受付部208と、資金移動時期判断部209と、移動指示処理実行部210とを備える。
ユーザ端末30は、レシート読取部301と、支出情報送信部302と、承諾要求表示部303と、承諾可否操作受付部304と、承諾可否通知部305と、履歴表示部306と、撤回操作受付部307と、撤回通知部308とを備える。
【0034】
家計簿サーバ装置10の収入情報取得部101は、ユーザの収入情報を取得する。本実施例では、口座の取引履歴を掲載した個人向けサイトへのアクセスに用いる情報(URL、ユーザID、パスワード等)を家計簿サーバ装置10にユーザが予め登録しておく。
【0035】
個人向けサイトでは、取引日、取引の種類(カード引き出し、カード預け入れ、振り込み及び引き落とし等)、取引先及び取引金額等の取引履歴が掲載されている。収入情報取得部101は、登録された情報を用いてユーザの取引履歴を読み出し、入金を示す取引履歴のうち決められた項目(「給料」及び「賞与」等)のものを、ユーザの収入情報として取得する。収入情報取得部101は、取得した収入情報を、ユーザのユーザIDとともに家計情報蓄積部103に供給する。
【0036】
このユーザIDは、資金運用支援システム1で割り当てられているものであり、個人向けサイトへのアクセス用のユーザID及び家計簿サーバ装置10にアクセスするためのユーザIDとは通常は異なっている。ただし、お釣り運用サービスを提供する事業者が家計簿サーバ装置10も運用する場合やユーザ自身がユーザIDを決定する方法が採用されている場合などに、共通のユーザIDが用いられてもよい。
【0037】
家計簿サーバ装置10の支出情報取得部102は、ユーザの支出情報を取得する。支出情報取得部102は、例えば、上記の個人向けサイトから取引履歴を読み出し、出金を示す取引履歴のうち決められた項目(「引き落し」及び「振り込み」等)のものを、ユーザの支出情報として取得する。また、支出情報取得部102は、ユーザ端末30から次のように送信されてくる情報を支出情報として取得する。
【0038】
ユーザ端末30のレシート読取部301は、自装置の撮像手段(撮像装置37)でレシートを撮影することで、そのレシートに記載された支出情報を読み取る。レシート読取部301は、レシートに含まれるテキストのパターン(「領収証」、「合計」、「お預り」及び「お釣り」等)を予め記憶しておき、撮影した画像に写ったテキストを認識してそれらのパターンが含まれている場合にレシートが撮影されていると判断する。レシート読取部301は、この判断を行うと、撮影されているレシートに記載されている日時、商品名、価格、価格の合計、消費税額、支払額及びお釣り等を支出情報として読み取る。レシート読取部301は、読み取った支出情報を支出情報送信部302に供給する。なお、この画像認識プロセスは、外部装置に対して画像データを送信し、その外部装置により読み取られた文字情報をユーザ端末30に返却することにより実現されてもよい。
【0039】
支出情報送信部302は、家計簿サーバ装置10の宛先(IP(Internet Protocol)アドレス等)を記憶しておき、供給された支出情報をその宛先(すなわち家計簿サーバ装置10)に送信する。支出情報取得部102は、こうして送信されてきたレシートから読み取られた支出情報を取得する。支出情報取得部102は、上記のとおり取得した支出情報を、ユーザのユーザIDとともに家計情報蓄積部103に供給する。
【0040】
家計簿サーバ装置10の家計情報蓄積部103は、上記のとおり取得された収入情報及び支出情報をユーザの家計情報として蓄積する。家計情報蓄積部103は、供給された収入情報及び支出情報を、ともに供給されたユーザIDに対応付けて記憶することでこの蓄積を行う。以上で述べた収入情報及び支出情報の取得及び蓄積は定期的に(例えば毎日。支出情報についてはユーザがレシートを撮影する操作を行ったときにも)行われ、なるべく新しい家計情報が蓄積されるようになっている。
【0041】
資金運用支援サーバ装置20の支払額取得部201は、上述した商取引における支払額を記憶する記憶装置からその支払額を取得する。商取引における支払額は、支出情報が示す出金の金額及びレシートに記載された価格の合計と消費税額を合わせた金額等によって表される。支払額取得部201は、その支出情報を記憶する家計簿サーバ装置10(本実施例における記憶装置)に支出情報を要求する。家計簿サーバ装置10の家計情報蓄積部103は、この要求を受け取ると、蓄積している支出情報及びそれに対応付けたユーザIDを資金運用支援サーバ装置20に送信する。
【0042】
このとき、家計情報蓄積部103は、今までに資金運用支援サーバ装置20に送信したことがない支出情報(つまり前回支出情報を送信した後に新たに蓄積された支出情報)を送信する。支払額取得部201は、送信されてきた支出情報及びユーザIDを受け取ることで、そのユーザIDのユーザが商取引の際に支払った支払額を取得する。支払額取得部201は、取得した支払額を示す支出情報を対応するユーザID(その額を支払ったユーザのユーザID)に対応付けて差額算出部202に供給する。
【0043】
差額算出部202は、支払額取得部201により取得された支払額とその支払額を切り上げた額との差額を算出する。差額算出部202は、例えばユーザによってお釣り運用サービスの利用開始時に設定された単位(50円単位、100円単位、500円単位又は1000円単位等)で支払額を切り上げる。この切り上げ単位は、お釣り運用サービスの利用開始後も変更可能である。
差額算出部202は、支払額が325円の場合に、切り上げ単位として100円単位が設定されている場合、325円を100円単位で切り上げた400円から325円を減算して得られる75円を差額として算出し、切り上げ単位として50円単位が設定されている場合、325円を50円単位で切り上げた350円から325円を減算して得られる25円を差額として算出する。差額算出部202は、こうして算出した差額を対応するユーザID(その差額が算出される支払いを行ったユーザのユーザID)及び支出情報に対応付けて差額取得部203に供給する。
【0044】
差額取得部203は、商取引における支払額とその支払額を切り上げた額との差額を取得する。差額取得部203は、本実施例では、差額取得部203により算出された差額を取得する。差額取得部203は、取得した差額を、その差額に対応付けて供給されたユーザID及び支出情報とともに差額蓄積部204に供給する。
差額蓄積部204は、差額取得部203により取得された差額を、対応するユーザID等に対応付けて記憶する。
図5は蓄積されている差額の一例を示す図である。図5の例では、差額蓄積部204は、ユーザIDと、支払日と、差額と、差額IDと、ステータスとを対応付けて記憶している。支払日は、差額が算出された支払額の商取引が行われた日を表し、支出情報により示される。差額IDは、各差額を識別する情報である。ステータスは、蓄積されている差額を資金運用に充てることについての承諾をユーザに要求した場合に承諾が得られた状況、又は、拒否された状況を表す。
【0045】
また、ステータスは、承諾要求がまだなされていない未要求の状況、又は、承諾された後に口座の移動まで済んでいる移動済みの状況を表す。図5の例では、支払日が12/22から12/31までの差額には「移動済み」という状況が、支払日が1/1から1/7までの差額には「拒否」という状況が、支払日が1/8から1/14までの差額には「承諾」という状況が、支払日が1/15から1/21までの差額には「未要求」という状況がそれぞれ対応付けられている。
【0046】
この承諾要求及び口座の移動についてはこの後で詳しく説明する。以上で述べた支払額の取得から差額の蓄積までの動作は定期的に(例えば毎日)行われ、なるべく最新の商取引における差額が蓄積されるようになっている。本実施例では、説明を分かり易くするために、毎日その日に行われた商取引における差額が差額取得部203によって取得され、差額蓄積部204に蓄積されるものとする。
【0047】
資金運用支援サーバ装置20の要求時期判断部205は、前述した承諾要求を行う時期、すなわち、差額蓄積部204に蓄積されている差額を資金運用に充てることについての承諾をユーザに要求する要求時期になったか否かを判断する。要求時期判断部205は、承諾を要求する相手となる要求先ユーザが定めた基準日から定められた第1の期間が経過するごとに、要求時期になったと判断する。
【0048】
本実施例では、基準日として月初めの日が定められ、第1の期間として1週間、又は、月末最後の期間が1週間に満たない場合は、その前週と合わせた期間を第1の期間とする。つまり、第1の期間は、1週間又は1週間+月末の数日間である。この定め方をすれば、どの月も4回の第1の期間を含むことになる。例えば1月であれば、月初めの1/1(1月1日)が基準日となり、1/1から1/7まで、1/8から1/14まで、1/15から1/21まで、1/22から1/31までという4回の第1の期間が定められる。
【0049】
要求時期判断部205は、第1の期間が経過した次の日になったときに要求時期になったと判断する。例えば上記の4回の第1の期間については、1/8、1/15、1/22及び2/1になったときに要求時期になったと判断する。要求時期判断部205は、要求時期になったと判断すると、要求先ユーザのユーザIDに対応付けて蓄積されている差額のうちステータスが「未要求」であるものを、対応する差額ID及び支払日とともに差額蓄積部204から読み出し、要求先ユーザのユーザIDとともに承諾要求部206に供給する。
【0050】
承諾要求部206は、第1の期間が経過するごとに、その第1の期間になされた1以上の商取引における差額を資金運用に充てることについての承諾をユーザに要求する。例えば、ユーザ端末30の承諾要求表示部303が、自機能を実現するためのプログラムが起動されたとき又は定期的に、自装置を利用するユーザのユーザIDを資金運用支援サーバ装置20に送信するとともに、表示すべき承諾要求が有るか否かを資金運用支援サーバ装置20に問い合わせる。
【0051】
承諾要求部206は、要求時期判断部205から供給されたユーザIDとユーザ端末30から送信されてきたユーザIDとが一致する場合、そのユーザIDとともに供給された差額、差額ID及び支払日を用いて、例えばそれらの差額を資金運用に充てることについての承諾を要求する旨を表す文字列と、供給された差額ID、差額及び支払日とを示す要求データを生成する。
承諾要求部206は、生成した要求データを、問い合わせ元のユーザ端末30に対して送信する。承諾要求部206は、この要求データをユーザ端末30に送信することで、資金運用の承諾をユーザに要求する。
【0052】
以上のとおり、本実施例では、ユーザ端末30からの問い合わせを受けて資金運用の承諾が要求されるという、いわゆるプル型での承諾要求が行われる。なお、これに限らず、ユーザ端末30からの問い合わせがなくても、要求時期判断部205により第1の期間が経過したと判断されたときに、承諾要求部206が資金運用の承諾を要求するという、いわゆるプッシュ型での承諾要求が行われてもよい。
【0053】
ユーザ端末30の承諾要求表示部303は、資金運用支援サーバ装置20から差額を資金運用に充てることについての承諾を要求された場合に、その承諾要求を表示する。承諾要求表示部303は、資金運用支援サーバ装置20から送信された要求データを受け取ると、その要求データが示す文字列等を、資金運用支援サーバ装置20からの承諾要求としてアプリ画面又はウェブブラウザの画面に表示する。
【0054】
図6は表示された承諾要求の一例を示す図である。図6の例では、承諾要求表示部303は、「Aさんに以下のお釣りの資金運用が提案されました。」という文字列と、商取引の支払日と、その商取引における差額と、選択された差額の合計金額(この例では「1468円」)とを示す文字列とを、承諾要求A1として出力装置36の表示部に表示している。また、承諾要求表示部303は、「選択したものを承諾」と書かれた承諾ボタンB1と、拒否ボタンB2と、全選択ボタンB3と、複数の個別選択ボタンB4(「○」は選択することを示し、「×」は選択しないことを示す)とを表示している。
【0055】
承諾要求表示部303は、これらのボタンの表示領域を示す情報を承諾可否操作受付部304に供給する。承諾可否操作受付部304は、承諾要求に対する承諾の可否を示すユーザの操作を受け付ける。承諾可否操作受付部304は、承諾ボタンB1をタップする操作(マウスでクリックする操作でもよい)を、選択された差額の合計金額として表示されている資金の資金運用をユーザが承諾する操作として受け付け、拒否ボタンB2をタップする操作を、ユーザが資金運用を拒否する操作として受け付ける。
【0056】
また、承諾可否操作受付部304は、全選択ボタンB3をタップする操作を、資金運用に充てる資金として全ての差額を選択する操作として受け付け、個別選択ボタンB4をタップする操作を、各差額の選択の有無を切り替える操作(タップする度に「○」と「×」が切り替わる)として受け付ける。承諾可否操作受付部304は、受け付けた操作結果を示す操作結果情報を承諾可否通知部305に供給する。
【0057】
操作結果情報は、例えば、選択された差額の差額ID、選択されなかった差額の差額ID及び選択された差額の合計金額を示す情報である。なお、拒否ボタンB2が操作された場合には、選択された状態の差額があったとしても、全ての差額の差額IDが選択されなかった差額の差額IDとして示され、且つ、合計金額として0円が示される操作結果情報が承諾可否通知部305に供給される。
【0058】
承諾可否通知部305は、承諾可否操作受付部304による操作結果を資金運用支援サーバ装置20に通知する。承諾可否通知部305は、資金運用支援サーバ装置20の宛先を示す宛先情報(IPアドレス等)を予め記憶しておく。承諾可否通知部305は、承諾可否操作受付部304から操作結果情報が供給されると、供給された操作結果情報と、自装置のユーザのユーザIDとを対応付けた操作結果データを、記憶している宛先情報が示す宛先(つまり資金運用支援サーバ装置20)に送信する。
【0059】
承諾可否通知部305は、この操作結果データを送信することで、資金運用支援サーバ装置20に対して、承諾要求が表示されて資金運用を承諾する操作が行われた場合にはその操作結果データが示す合計金額の資金運用が承諾された旨を通知し、資金運用を拒否する操作が行われた場合にはその旨を通知する。
また、承諾可否通知部305は、こうして資金運用を承諾又は拒否した差額の履歴が後から確認できるように、操作結果データ及びその操作結果データの送信日時を互いに対応付けて記憶しておく。この操作結果データは、資金運用を承諾する操作が受け付けられた場合におけるその資金運用に充てられる資金を示す情報である。
【0060】
承諾可否通知部305は、例えば、操作結果データを受信した際の資金運用支援サーバ装置20のローカル時間(世界標準時からの時差により算出される日時、日本なら+9時間)を、操作結果データの送信日時として記憶する。これにより、ユーザ端末30が海外から資金運用支援サーバ装置20にアクセスする場合でも、日本時間で送信日時が記憶される。
【0061】
資金運用支援サーバ装置20の承諾可否受付部207は、承諾要求部206が要求した承諾の可否を受け付ける。承諾可否受付部207は、ユーザ端末30から送信されてきた操作結果データを受け取ると、その操作結果データが1円以上の合計金額を示す場合には、その操作結果データが示す合計金額による資金運用が承諾されたことを受け付け、その操作結果データが合計金額として0円を示す場合には、資金運用が拒否されたことを受け付ける。
【0062】
承諾可否受付部207は、承諾の可否を受け付けると、差額蓄積部204に対して、操作結果データが示すユーザID及び差額IDに対応付けられている差額のステータスを受け付けた承諾の可否のとおりに変更するよう指示する。差額蓄積部204は、この指示を受け取ると、指示されたとおりに、承諾要求がされた差額のステータスを「未要求」から「承諾」又は「拒否」に変更する。
【0063】
ユーザ端末30の履歴表示部306は、過去に資金運用が承諾された差額の履歴を表示する。履歴表示部306は、承諾された差額の履歴を表示する操作がユーザにより行われると、記憶されている操作結果データ及びその操作結果データの送信日時を承諾可否通知部305から取得する。なお、本実施例では、拒否された差額の履歴を表示する操作は用意されておらず、一度拒否された差額の履歴は表示されないものとする。履歴表示部306は、取得した操作結果データが示す差額IDの差額と、それらの差額の合計金額と、その合計金額の資金運用が過去(操作結果データの送信日時)に承諾された旨を示す文字列とを前述した差額の履歴として表示する。
【0064】
図7は表示された差額の履歴の一例を示す図である。図7の例では、履歴表示部306は、「以下のお釣りの資金運用を1/22に承諾しています。」という文字列と、商取引の支払日と、その商取引における差額と、選択された差額の合計金額(この例では「1468円」)とを示す文字列とを、差額の履歴C1として出力装置36の表示部に表示している。また、承諾要求表示部303は、複数の個別選択ボタンB4と、変更の反映ボタンB5と、承諾の撤回ボタンB6とを表示している。
【0065】
履歴表示部306は、各ボタンの表示領域を示す情報と取得した操作結果データとを撤回操作受付部307に供給する。撤回操作受付部307は、過去に行った資金運用の承諾の撤回を示すユーザの撤回操作を受け付ける。撤回操作受付部307は、承諾の撤回ボタンB6をタップする操作が行われると、その操作を、全ての差額についての承諾を撤回する撤回操作として受け付ける。
また、撤回操作受付部307は、個別選択ボタンB4をタップする操作を、図6の例と同様に各差額の選択の有無を切り替える操作として受け付け、その操作により或る差額について選択の有無を「○」から「×」に切り替えた後に変更の反映ボタンB5をタップする操作を、その差額についての承諾を撤回する撤回操作として受け付ける。撤回操作受付部307は、いずれかの撤回操作を受け付けると、承諾が撤回された差額の差額IDを撤回通知部308に供給する。
【0066】
撤回通知部308は、撤回操作受付部307から差額IDが供給されると、それらの差額IDの差額について資金運用の承諾が撤回された旨を資金運用支援サーバ装置20に通知する。撤回通知部308は、供給された差額IDと承諾が撤回された旨と自装置のユーザのユーザIDとを示す撤回通知データを資金運用支援サーバ装置20に送信することでこの通知を行う。
【0067】
資金運用支援サーバ装置20の撤回受付部208は、撤回通知部308から通知された資金運用の承諾の撤回を受け付ける。撤回受付部208は、ユーザ端末30から送信されてきた撤回通知データを受け取ると、承諾の撤回がされたものと判断し、その撤回通知データが示すユーザID及び差額IDに対応付けられている差額のステータスを承諾から拒否に変更するよう差額蓄積部204に指示する。差額蓄積部204は、この指示を受け取ると、指示されたとおりに、それらの差額のステータスを「承諾」から「拒否」に変更する。
【0068】
資金運用支援サーバ装置20の資金移動時期判断部209は、資金運用の承諾を得られた差額の累積額をユーザの資金が収められているユーザ名義の普通口座(以下、ユーザ口座という)から、投信口座に移動する移動時期を判断する。
本実施形態では、銀行サーバ4がユーザ口座のお金を管理しており、信託銀行の銀行サーバ5が投信口座を管理している。
【0069】
資金移動時期判断部209は、上述した基準日(要求先ユーザが定めた日。資金運用支援サーバ装置20のローカル時間で判断される)から、上述した第1の期間を複数含む第2の期間が経過すると、移動時期になったと判断する。本実施例では、上述したようにどの月も4回の第1の期間を含むように基準日及び第1の期間が定められており、それら4回の第1の期間を含む期間を第2の期間として定めるものとする。この定め方をすれば、1月から12月までの各月がそれぞれ第2の期間となる。
【0070】
資金移動時期判断部209は、第2の期間が終了してから、最後の第1の期間についての資金運用の承諾のために設けられた期間が経過したときに、資金移動時期になったと判断する。例えば承諾のための期間を3日間とすると、資金移動時期判断部209は、1/31に第2の期間が終了し、2/1から2/3までの3日間が経過した次の日である2/4になったときに、資金移動時期になったと判断する。
【0071】
資金移動時期判断部209は、資金移動時期になったと判断すると、要求先ユーザのユーザIDに対応付けて蓄積されている差額のうち、ステータスが「承諾」であるものを差額IDとともに差額蓄積部204から読み出し、読み出した差額及び差額IDを要求先ユーザのユーザIDとともに移動指示処理実行部210に供給する。
【0072】
移動指示処理実行部210は、上述した第2の期間が経過すると、承諾を得られた差額の累積額のユーザ口座から投信口座への移動を指示する移動指示処理を実行する。ここでいう承諾を得られた差額には、承諾が撤回された差額は含まれない。つまり、移動指示処理実行部210は、承諾が得られてから移動指示処理を実行する前にその承諾の撤回が撤回受付部208により受け付けられた場合、その承諾が撤回された差額を累積額から減じて移動指示処理を実行する。
【0073】
移動指示処理実行部210は、資金移動時期判断部209から資金運用が承諾された差額及び差額IDが供給されると、その差額を合計した金額を累積額として算出する。移動指示処理実行部210は、算出した累積額と同じ額をユーザ口座から投信口座に移動させることを要求する要求データを図1に表す決済代行サーバ3に送信する処理を、移動指示処理として実行する。
【0074】
決済代行サーバ3は、この要求データを受け取ると、ユーザ口座を管理する銀行サーバ4に対してそのユーザ口座から銀行サーバ5が管理する投信口座に対して累積額と同じ額を移動させるよう要求する。
銀行サーバ4がこの要求に基づいて累積額と同じ額をユーザ口座から投信口座に振り込む処理を行い、銀行サーバ5が振り込まれた金額を投信口座に入金する処理を行うことで、資金の移動が完了する。
【0075】
なお、要求データの送信先、すなわち、口座間の資金の移動の要求先は、決済代行サーバ3ではなく銀行サーバ4であってもよいし、プリペイドカード、ポイントエクスチェンジ及び携帯キャリア決済代行等の決済機関であってもよい。要するに、資金運用のために口座間の資金の移動がなされれば、要求先がどこであってもよい。また、結果として口座間の資金の移動がなされれば、移動指示処理実行部210は、どのような処理を移動指示処理(差額の累積額のユーザ口座から投信口座への移動を指示する処理)として実行してもよい。
【0076】
以上のように、お釣り運用サービスにおいては、ユーザが買い物の際に生じたお釣りを投信口座に入金することにより、そのお金を資金として委託会社が、投資信託への投資を行うようにしている。
お釣り運用サービスのユーザは、この投資信託への投資により生じた利益を得ることができるほか、任意のタイミングで投資信託を解約等により換金することができる。
このような投資信託の換金については、従来のシステムで対応できるものの、上記[発明が解決しようとする課題]において説明したように、ユーザが投資信託の換金を申し込んでから解約代金(以下、「代金」という)である現金がユーザに受け渡されるまでに時間が掛かるという課題に対処できていなかった。
これに対し、本発明の一実施形態に係る投信取引システムSは、投資信託の換金の申込時における既知の時価に基づいて対価をすぐに算出し、電子マネーなどの電子有価財を用いて代金をユーザにすぐに受け渡すことで前記課題を解決するものである。
以下、投信取引システムSについて説明する。
【0077】
(投信取引システム)
図8は本発明の金融商品取引システムの一実施形態に係る投信取引システムSの全体構成を示す図である。
図8に示すように、投信取引システムSは、投資信託上の受益者であるユーザが使用するユーザ端末30、投資信託上の委託者である委託会社において管理される投信取引サーバ40、投資信託の取引業務の支援を行う業務支援サーバ50、及び所定の電子マネーサービスを運営する電子マネー会社において管理される電子マネー会社サーバ60等によって構成され、これら各装置と、資金運用支援システム1の各装置とがネットワーク2を介して通信可能に接続されている。
【0078】
なお、投信取引サーバ40、業務支援サーバ50、及び電子マネー会社サーバ60は情報処理装置であり、ハードウェア構成は、前述した資金運用支援システム1における家計簿サーバ装置、資金運用支援サーバ装置と同じ構成であるため、詳細な説明を省略する(図2参照)。
また、ユーザ端末30は、資金運用支援システム1におけるユーザ端末30と同じであり、お釣り運用サービスのユーザが使用する端末装置であるとともに、投信取引システムSにおけるユーザが使用する端末装置でもある。
ただし、これらは必ずしも同じ端末装置でなくてもよい。
【0079】
図9は、投信取引システムSの機能構成を示す図である。
図9に示すように、ユーザ端末30は、ログイン部311、及び換金申込部312を備える。
投信取引サーバ40は、投資信託の取引に係る各種処理を行う装置であり、認証部401、申込受付部402、対価算出部403、手数料算出部404、課税額算出部405、取引基準価格決定部406、電子マネー発注部407、及び現金処理部408を備える。
【0080】
業務支援サーバ50は、投信取引サーバ40における投資信託の取引処理を支援する装置であり、ユーザ情報DB501、口座情報DB502、及び基準価額DB503を備える。
電子マネー会社サーバ60は、所定の電子マネーサービスを提供可能な装置であり、電子マネー処理部601を備える。
本実施形態の電子マネー会社サーバ60は、少なくとも、「前払式支払手段」に該当する電子マネー(以下、第1電子マネーと称する)のサービスと、「資金移動」に該当する電子マネー(以下、第2電子マネーと称する)のサービスと、を提供可能に構成されている。
第1電子マネーに係る「前払式支払手段」は、記録媒体であるカードや携帯電話に金銭的価値としての電子マネーをチャージすることで、その残高を増やすことができるものであり、残高の範囲内において商品やサービスを購入できるようになっている。
例えば、第1電子マネーには、所定のギフトサービスがあり、ギフトID発行者が発行する金銭的価値に相当するギフトIDを電子マネーサービスの会員に送り、当該会員が、受け取ったギフトIDや会員番号等を専用サイトにおいて入力することでもチャージ可能になっている。
便宜上、第1電子マネーにおいて、カードや携帯電話などの記録媒体を「nカード等」と称し、ギフトサービスを「nギフト」と称する。
第2電子マネーに係る「資金移動」は、犯罪収益移転防止法にて取引時確認をしなければならない取引と定められている。
例えば、第2電子マネーは、本人情報で本人確認を行った上で、Webサイト上に設けた会員の電子マネー口座(単に口座ともいう)に金銭的価値としての電子マネーを直接的にチャージできるようになっており、会員は、自身の口座の残高の範囲内において商品やサービスを購入できるようになっている。
なお、電子マネー会社サーバ60は、上記電子マネーに限らず様々なタイプの電子マネーを提供可能に構成することができる。
また、電子マネー会社サーバ60は、第1電子マネー(nギフト含む)と第2電子マネーの2つの電子マネーサービスを1台の装置で統括的に運営する態様でもよく、2台の装置でそれぞれ独立して運営する態様でもよい。
また、電子マネー会社サーバ60は、第1電子マネー及び第2電子マネーの運営の委託を受けた外部機関が運営する装置であってもよい。
【0081】
投信取引システムSにおいては、上記各装置のプロセッサがプログラムを実行して各部を制御することで、各種機能が実現される。
【0082】
まず、業務支援サーバ50が備える各種データベース(ユーザ情報DB501、口座情報DB502、基準価額DB503)について説明する。
図10は、ユーザ情報DBの一例であり、図11は、口座情報DBの一例であり、図12は、基準価額DBの一例である。
ユーザ情報DB501は、お釣り運用サービスのユーザのアカウント情報(ユーザID、パスワード)により構成されるデータベースである。
図10に示すように、ユーザ情報DB501には、ユーザが第1電子マネーや第2電子マネーの会員でもある場合には、それぞれのサービスを利用する際に必要な情報(アカウント情報等)を紐付けて登録しておくこともできる。
例えば、第1電子マネーを利用する場合には、会員の会員番号とパスワードが求められるが、そのうちの会員番号を紐付けて登録することができる(図10参照)。
また、第2電子マネーを利用する場合には、会員の口座番号や本人情報(ユーザ名等)が求められるが、そのうちの口座番号を紐付けて登録しておくことができる。
なお、パスワード(第1電子マネーの場合)や本人情報(第2電子マネーの場合)を登録することもできる。
【0083】
図11に示すように、口座情報DB502は、お釣り運用サービスのユーザの投信口座に関する情報により構成されるデータベースであり、具体的には、銘柄、口数等とユーザIDとが対応付けて構成されている。
図12に示すように、基準価額DB503は、委託会社によって毎日算出される投資信託の社内時価である基準価額のデータベースであり、基準価額と日付けとが対応付けて構成されている。
【0084】
投信取引システムSの機能及び動作について図9等を参照しながら説明する。
【0085】
ユーザ端末30のログイン部311は、所定のログイン操作に基づいて、投信取引サーバ40に対しログイン情報を送信する。
具体的には、ユーザのアプリ操作により、ユーザ端末30の表示部36にログインページ(図示省略)を表示させ、当該ログインページに設けられたログイン情報入力欄にログイン情報(お釣り運用サービスのユーザID及びパスワード等)を入力する。
これにより、ログイン部311は、入力されたログイン情報を投信取引サーバ40の認証部401に送信する。
【0086】
投信取引サーバ40の認証部401は、ログイン情報を受信すると、業務支援サーバ50にログイン情報を送信することで、当該ログイン情報とユーザ情報DB501(図10)に記憶されているアカウント情報とを照合させる。
照合の結果、一致が確認された場合、ユーザ端末30は、ログイン画面として、図13に示すホーム画面(アプリ画面)を表示部36に表示する。
これにより、ユーザは、ホーム画面に設けられた各メニューのサービスを利用できるようになる。
例えば、ホーム画面の各メニューの中から「各種設定」ボタンを選択することで、ユーザのアカウント情報を表示部36に表示することができ、当該アカウント情報を確認したり、変更することができる。
【0087】
電子マネーサービス(第1電子マネー又は第2電子マネー)との連携処理を行う場合には、その都度、その電子マネーサービスを利用する際に必要な情報(電子マネーサービスのアカウント情報)の入力を求め、入力された情報を電子マネー会社サーバ60に送信して認証することができる。
例えば、第1電子マネーでのチャージ(以下、nチャージという)が選択された場合には、アプリ画面上に会員番号及びパスワードなどの入力を求め、入力された情報が認証された場合に「nチャージ」を実行できるようにすることができる。
同様に、第2電子マネーのチャージ(以下、dチャージという)が選択された場合には、アプリ画面上に口座番号及び本人情報(会員のユーザ名等)などの入力を求め、入力された情報が認証された場合に「dチャージ」を実行できるようにすることができる。
なお、一度連携処理が行われると、アカウント情報をサーバ側で保持するようにして、一定期間はアカウント情報の入力を不要にすることもできる。
【0088】
ユーザ端末30の換金申込部312は、所定操作に基づいてユーザが保有する投資信託の換金の申し込み処理を行う。
具体的には、ホーム画面(図13参照)の各メニューの中から「出金」を選択する。
なお、「出金」と「換金」とは同義であるが、主にアプリ上の用語として「出金」を用いる。
ホーム画面において「出金」を選択すると、図14に示す出金方法選択画面に遷移する。
出金方法選択画面には、現金による出金を選択する場合の操作手段として「現金で出金」ボタンb1が設けられており、電子マネーやポイントなどの電子有価財による出金(以下、電子チャージ出金という)を選択可能な操作手段として、「nチャージ」ボタンb2及び「dチャージ」ボタンb3が設けられている。
【0089】
「nチャージ」は、第1電子マネーにおけるnギフトを用いたチャージによる出金方法であって、金額に対応したギフトIDをユーザ宛に送ることで、ユーザのnカード等にその金額の電子マネーをチャージ可能にするものである。
「dチャージ」は、第2電子マネーによる出金方法であって、ユーザの電子マネー口座に直接的に電子マネーをチャージするものである。
なお、第1電子マネーや第2電子マネー以外の他の電子マネーやポイントを用いた電子チャージ出金方法を採用することもできる。これについては、後記「応用例・変形例」において説明する。
このように、投資信託の換金の申込みとして、電子有価財での受渡しを求める申込み(第1申込み)と、現金での受渡しを求める申込み(第2申込み)とがあり、このうちのいずれかを選択して申込みできるようになっている。
【0090】
ここで、「電子有価財」は、電子マネーを含む概念である。
「電子マネー」は、現金の代替となる支払手段(決済手段)の一種であり、決済の手段(現金や預金など)を電子化したものと、決済の方法(振込、口座振替、小切手、クレジットカードなど)だけを電子化したものとがあり、本発明の電子マネーはその両方を含む概念である。
「電子マネー」は、それ自体が価値を有する決済手段であるもの(決済手段性あり)と、それ自体が価値を有する決済手段ではないもの(決済手段性なし)に分けることもできる。
決済手段性があるものには、ネットワーク型の電子決済のシステムにおいて、金銭情報などの電子データをWeb上のサーバで管理するサーバ型電子マネーなどがあり、本発明の第1電子マネーはこのタイプに該当する。
第1電子マネーは、ギフトID自体が価値を有することから決済手段性を有しており、ギフトID自体が電子マネーに相当するともいえる。
決済手段性がないものには、預金通貨の移転を電子的に指示する仕組みを用いた支払手段を用いた支払指示型電子マネーがあり、第2電子マネーのほか、ドコモ(登録商標)口座、PayPay(登録商標)などのデポジット型電子マネーを例示することができる。
【0091】
また、「電子有価財」には、各種ポイントサービス(ポイントプログラム)において付与されるポイントを概念に含む。
「ポイント」は、各種の商品・サービスの購入金額あるいは来店回数等に応じて、一定の条件で計算されユーザに付与される点数のことをいう。ユーザは、獲得したポイントを商品・サービスの購入代金の一部に充当したり、商品・サービスと交換することができる。
また、ポイントサービスの中には、ポイントを現金に交換できるサービスもあり、この場合、ポイントは、電子マネーにも該当し得る。
上記例以外の電子マネー及びポイントについては、後記「応用例・変形例」において説明する。
【0092】
図14は、出金方法選択画面の一例である。
【0093】
ユーザ端末30の換金申込部312は、「電子チャージ出金」が選択された場合、すなわち、出金方法選択画面において「nチャージ」又は「dチャージ」が選択された場合、所定の換金申込情報を投信取引サーバ40の申込受付部402に送信する。
「換金申込情報」には、「電子チャージ出金が選択されたことを示す情報」及び「nチャージかdチャージかを特定可能な情報」からなる「電子チャージ選択情報」と、「ユーザID」とが含まれる。
【0094】
投信取引サーバ40の申込受付部402は、ユーザが保有する投資信託の換金の申込みを受け付ける。
具体的には、申込受付部402は、ユーザ端末30から換金申込情報を受信することに基づいて投資信託の換金の申込みを受け付ける。
このとき、申込受付部402は、換金申込情報に電子チャージ選択情報が含まれていることに基づき電子マネーの受け渡しを求める第1申込みを受け付ける。
【0095】
また、申込受付部402は、換金申込情報を受信した日を「申込日」として特定し、当該申込日と、電子チャージ選択情報とを対価算出部403に出力する。
また、申込受付部402は、ユーザIDをキーとして業務支援サーバ50に口数残高要求情報を送信することにより、口座情報DB502(図11)からユーザが保有する投資信託の現在の口数残高を取得し、これを応答情報に含めてユーザ端末30に送信する。
ユーザ端末30の換金申込部312は、投信取引サーバ40から応答情報を受信すると、図15に示す出金内容入力画面を表示部36に表示する。
これにより、表示部36の画面は、出金方法選択画面(図14)から出金内容入力画面(図15)に遷移する。
【0096】
図15に示すように、出金内容入力画面には口数入力欄c1が設けられており、この口数入力欄c1に任意の換金口数を入力できるようになっている。
また、出金内容入力画面には、ユーザが保有する投資信託の現在の口数残高が表示される(領域c2参照)。
これにより、ユーザは、自身が保有する投資信託の口数残高を把握することでき、この口数残高の範囲内で円滑に換金口数を入力することができる。
ユーザ端末30の換金申込部312は、出金内容入力画面において換金口数が入力されると、当該入力された換金口数の情報を投信買取サーバ40の申込受付部402に送信する。
【0097】
投信取引サーバ40の申込受付部402は、ユーザ端末30から換金口数の情報を受信すると、当該換金口数を対価算出部403に出力する。
対価算出部403は、申込受付部402から「申込日」及び「電子チャージ選択情報」を入力すると、取引基準価格決定部406に対し「申込日」の前営業日の基準価額を取引基準価格とする情報の問い合わせを行う。
取引基準価格決定部406は、問い合わせに応じ、申込みを受け付けたときより前の時点における時価を取引基準価格として決定する。
具体的には、業務支援サーバ50の基準価額DB503(図12)にアクセスし、当該基準価額DB503に記憶されている過去の基準価額の中から申込日の前営業日の基準価額を抽出し取引基準価格として決定する。
なお、本実施形態では、申込日の前営業日の基準価額を取引基準価格としているが、これに限らず、例えば、申込日の2営業日前の基準価額を取引基準価格とすることもでき、申込日の過去の営業日における基準価額であれば、取引基準価格とすることができる。
取引基準価格決定部406は、決定した取引基準価格を対価算出部403に出力する。
【0098】
対価算出部403は、取引基準価格決定部406により決定した取引基準価格に基づいて、投資信託の対価を算出する。
具体的には、取引基準価格決定部406から入力した基準価額(申込日の前営業日の基準価額)と、申込受付部402から入力した換金口数とに基づいて、換金対象の投資信託の対価を算出する。
【0099】
また、対価算出部403は所定の手数料を加味して出金額を算出することもできる。
具体的には、対価算出部403の手数料算出部404が、手数料を算出する。
例えば、前営業日の基準価額が10,674円/1万口で、換金口数が3000口の場合、スプレッド(手数料5%)を控除した買取価額10,140円となるため、換金対象の投資信託の対価は3,042円と算出される。
つまり、元の対価(3,202円)から160円の手数料が控除された額(3,042円)が投資信託の対価として算出される。
【0100】
ところで、投信取引サーバ40は、所定の手数料を設定することが可能な手数料設定部を備えている(図示商略)。
手数料設定部においては、以下の(i)~(ii)の事項を加味して手数料を設定することができる。
(i)基準価額の変動リスクに対する委託会社のコスト負担
電子チャージ出金は、委託会社がユーザの保有する受益権(投資信託)の対価相当分の電子マネーをユーザに受け渡すことの引き換えに、ユーザが保有する受益権を委託会社が受け取ることで実現している。
つまり、委託会社が、ユーザが保有する受益権をユーザから買い取る形をとっている。
また、委託会社は、ユーザから買い取った受益権をその後に売却することで、電子マネーの購入、すなわち、受益権の買取りに要した費用を回収するようにしている。
このような仕組みでは、受益権を買い取ったときの基準価額と、買い取った受益権をその後に売却するときの基準価額との変動がある場合には、委託会社がその変動に伴うコスト(変動リスク)を負担しなければならない。
しかも、この変動リスクは、従来のブラインド方式においては、ユーザが負担していたものである。
【0101】
このような理由から、手数料設定部は、上記基準価額の変動リスクに対応した費用や料率を設定するなど、上記変動リスクを加味した手数料を設定することができる。
具体的には、手数料設定部は、ユーザが保有する金融商品としての投資信託を委託者が購入したときの時価と、委託者がユーザから購入した投資信託を換金するときの時価との変動を加味して手数料を設定することができる。
【0102】
(ii)即時出金可能としたことによる付加価値及びコスト
従来の方式(現金での出金)では、換金の申込みから代金の受渡しまでに時間が掛かるところ、電子チャージ出金にすることで、申込み時に即時に代金をユーザに受渡すことを可能としている。
これにより、利便性が向上するなど付加価値の高いサービスを実現していることでユーザに利益を与えている。
また、このようなサービスを実現するための諸々のコストがかかっている。
【0103】
このような理由から、手数料設定部は、上記利益及びコストに対応した費用や料率を設定するなど、上記利益及びコストを加味して手数料を設定することができる。
具体的には、手数料設定部は、申込受付部402が、電子マネー等の電子有価財での受渡しを求める第1申込みを受け付けた場合、電子マネー等をユーザが受け取ることによるユーザの利益を加味して手数料を設定することができる。
【0104】
対価算出部403は、これらの算出結果に基づき、ユーザに受け渡す代金である出金額を算出する。
また、対価算出部403は、課税額を加味して出金額を算出することもできる。
課税額は、課税額算出部405により算出することができる。
具体的には、前営業日の個別元本を用いて譲渡損益を算出する。算出した譲渡損益と年間の累計譲渡損益から、所得税及び住民税の源泉徴収額又は還付額を算出する。
【0105】
例えば、前営業日の個別元本が9,640円、譲渡損益は150円(譲渡益)、年間の累計譲渡損益の値が正の場合、譲渡益150円は全て源泉徴収対象となり、所得税及び住民税の合計は29円となる。
このため、投資信託の対価が3,042円、源泉徴収額が29円の場合、出金額は3,013円と算出される。
対価算出部403は、算出した出金額の情報をメモリ等の記憶手段に一時的に記憶させるとともに、上記各算出結果の情報をユーザ端末30に送信する。
【0106】
ユーザ端末30は、対価算出部403から受信した各算出結果を表示部36に表示する。
具体的には、図16の出金内容確認画面に示すように、「即時出金額」として出金額(3,013円)が表示され、「即時出金における取引価格」として換金対象の投資信託の対価(3,202円)が表示され、「源泉徴収(還付)」(-29円)が表示されるとともに、即時出金額(出金額)が、換金対象の投資信託の対価から源泉徴収を差し引いた金額であることを把握可能に表示される。
なお、本実施形態では、手数料込みで出金額を表示する表示態様を採用しているが(図16参照)、手数料を外だし表示することで、手数料がいくらかわかるようにすることもできる。
【0107】
ここで、出金内容確認画面の下部に設けられている「出金」ボタンb4が選択されると、出金手続きが完了する。
出金手続きが完了すると、ユーザ端末30は、図17に示すように、出金手続きが完了した旨のメッセージを含む出金手続完了画面を表示部36にすることができる。
また、ユーザ端末30は、出金手続きの操作に応じ、出金を実行する旨の情報を投信取引サーバ40の対価算出部403に送信する。
【0108】
投信取引サーバ40の対価算出部403は、ユーザ端末30から出金を実行する旨の情報を受信すると、メモリに記憶している出金額の情報と、電子チャージ選択情報とを電子マネー発注部407に出力する。
【0109】
電子マネー発注部407は、電子マネー会社サーバ60に対し、対価算出部403により算出した対価に相当する電子マネーに関する発注処理を行う。
電子マネー発注部407は、具体的には、以下の処理を実行する。
【0110】
電子チャージ選択情報に基づき、出金方法として「nチャージ」が選択されていることが判定された場合、電子マネー発注部407は、第1電子マネーを運営する電子マネー会社サーバ60が提供するAPI(以下、n-APIという)を呼び出す。
電子マネー発注部407は、n-APIを呼び出すと、メモリから出金額の情報を取出し、これを発注額として当該APIに入力するとともに、ユーザの会員番号等をユーザ情報DB501から取り出して当該APIに入力する。
【0111】
なお、このように会員番号等を自動的に入力するのではなく、ユーザに入力させることもできる。
これにより、電子マネー会社サーバ60は、電子マネー処理部601が、代金受渡部として、対価算出部403により算出した対価に相当する所定の電子有価財を、投資信託の代金としてユーザに受け渡す処理を実行する。具体的には、以下の処理を実行する。
【0112】
電子マネー処理部601は、n-API経由で会員番号等や発注額の情報を受け取ると、会員番号等の認証を行い、認証が得られた場合に、発注額に相当する電子マネーを発行する。
具体的には、発注額に相当するギフトIDを発行し、当該ギフトIDを投信取引サーバ40に送信する。
【0113】
投信取引サーバ40は、電子マネー会社サーバ60から受信したギフトIDをユーザ端末30に送信する。
ユーザ端末30は、ギフトIDを受信すると、当該ギフトIDを表示部36に表示することができる。
具体的には、図18に示すギフトID通知画面に示すように、ギフトIDをアプリ画面で表示することができる。
これにより、ユーザは、ギフトIDを知ることができるため、例えば、ユーザ端末30で第1電子マネーの専用サイト(チャージ画面)にアクセスし、当該専用サイトでギフトID、会員番号等の入力などを行うことで、自身のnカード等に換金額相当の電子マネーをチャージすることができる。
つまり、「nチャージ」においては、委託会社が運営する投信取引サーバ40において、ギフトIDを購入し、当該購入したギフトIDをユーザに通知するようにしており、これにより、電子マネーを投資信託の換金の代金としてユーザに受け渡すようにしている。
【0114】
なお、図19に示すように、ギフトIDの受信に応じ、アプリ上に第1電子マネーの専用サイトのチャージ画面を連動して表示させ、当該画面に設けられたID入力欄にギフトIDの入力を促すようにすることもできる。
このようにすると、ユーザは、運用サイトを表示させる手間が省けるため、容易に電子マネーをチャージさせることができる。
【0115】
また、図20に示すように、既にID入力欄内にギフトIDが入力された状態で専用サイトのチャージ画面を表示させることで、ギフトIDを入力するユーザの手間も省けるため、さらに、電子マネーのチャージを容易にすることもできる。
さらに、ギフトIDをユーザ端末30に送信せず、第1電子マネーを運営するサーバ側で内部的にチャージ処理することによって、ユーザに確認や操作を課すことなく、電子マネーをチャージするようにもできる。
この場合でも、ギフトIDをアプリ画面上に表示する等してユーザが確認できるようにすることもできる。
これにより、ギフトIDをユーザに共有させることができ、履歴として記録を残すことができる。
【0116】
また、ギフトIDを投信取引サーバ40を経由してユーザ側に通知するのではなく、電子マネー会社サーバ60から直接通知することもできる。
また、ギフトIDをユーザが所持するユーザ端末30を介してユーザに通知するのではなく、外部の端末装置(例えば、コンビニエンスストアのサービス端末や店員用端末など)を介してユーザに通知することもできる。
【0117】
電子チャージ選択情報に基づき、出金方法として「dチャージ」が選択されていることが判定された場合は、電子マネー発注部407は、第2電子マネーを運営する電子マネー会社サーバ60が提供するAPI(以下、d-APIという)を呼出す。
電子マネー発注部407は、d-APIを呼び出すと、メモリから出金額の情報を取出し、これを発注額として当該APIに入力するとともに、ユーザの口座番号等をユーザ情報DB501から取り出して当該APIに入力する。
なお、このように口座番号等を自動的に入力するのではなく、ユーザに入力させることもできる。
【0118】
電子マネー会社サーバ60は、d-API経由で口座番号等や発注額の情報を受け取ると、口座番号等の認証を行い、認証が得られた場合、発注額分の金銭をその口座番号の口座に送金(チャージ)する。
つまり、「dチャージ」の場合、ユーザの電子マネー口座に直接チャージが行われ、これにより、投資信託の換金の代金をユーザに受け渡すことができる。
【0119】
出金方法選択画面において「現金での出金」が選択された場合、従来通り、投資信託の代金を現金でユーザに受け渡す処理を行う。
現金での出金は、従来からの方法を採用するため、詳細な説明は省略するが、電子チャージでの出金との主な相異点について以下に説明する。
【0120】
出金方法選択画面の出金メニューにおいて「現金での出金」が選択されると、ユーザ端末30の換金申込部312は、「出金方法として現金での出金が選択されたことを示す情報(現金選択情報)」を含む換金申込情報を投信取引サーバ40の申込受付部に送信する。
投信取引サーバ40の申込受付部402は、ユーザ端末30から換金申込情報を受信すると、換金申込情報を受信した日を「申込日」として特定し、当該申込日の情報と前記現金選択情報とを対価算出部403に出力する。
なお、申込受付部402は、換金申込情報を受信することに基づいて換金の申込みを受け付けるが、換金申込情報に現金選択情報が含まれていることに基づき現金での代金受け渡しを求める第2申込みを受け付ける。
【0121】
対価算出部403は、現金選択情報を入力することに基づいて、以下の処理を行う。
具体的には、換金対象の投資信託が国内商品の場合、申込日の翌営業日まで待って、申込日の基準価額を基準価額DB503から取得して、対価を算出する。
また、対価算出部403は、換金対象の投資信託が海外商品の場合、申込日の翌々営業日まで待って、申込日の翌営業日の基準価額を基準価額DB503から取得して、対価を算出する。従来のブラインド方式を採用するものである。
【0122】
対価算出部403は、算出した対価の情報を現金受渡部408に出力する。
現金処理部408は、代金受渡部として機能することで、対価算出部403により算出された対価の現金をユーザに受け渡す処理を行う。
具体的には、投信口座を管理する銀行サーバ5に対し、対象の投資信託を売却する指図の情報(売却指図情報)を送信する。
銀行サーバ5は、投信取引サーバ40から売却指図情報を受信すると、当該売却指図情報に示される内容に基づき換金対象の投資信託について売却処理を行うとともに、売却により得られた現金(代金)を信託口座から委託会社の口座に振り替える。
そして、振り替えられた代金を、投資家の指定口座に振り込む処理を行う。
これにより、投信取引システムSとして、現金を投資信託の代金としてユーザに受け渡す処理が完了する。
【0123】
このように、本発明の投信取引システムSにおいては、電子マネーなどの電子有価財での代金受渡しを求む申込みを受け付けた場合、申込みを受け付けたときより前の時点における時価に基づいて算出した対価に相当する電子有価財を金融商品の換金の代金としてユーザに受け渡す処理を実行し、現金での代金受渡しを求む申込みを受け付けた場合、申込みを受け付けたときより後の時点における時価に基づいて算出した対価に相当する現金を金融商品の換金の代金としてユーザに受け渡す処理を実行するようにしている。
このため、ユーザは、自身がどちらの代金受渡し方法が良いかを考慮したうえで換金の申込みを行うことができる。
【0124】
次に、本発明の金融商品取引方法に係る電子チャージ出金による換金処理の手順について図21を参照しながら説明する。
図21は、電子チャージ出金による換金処理を時系列に表したチャート図である。
図21に示すように、電子チャージ出金に基づく換金処理では、まず、ユーザ端末30において投資信託の換金の申込みを行う(S101)。
具体的には、出金方法選択画面(図14)において「nチャージで出金」か「dチャージで出金」を選択する。
【0125】
投信取引サーバ40は、投資信託の換金の申込みを受け付ける(S102)と、申込みを受け付けた日の前営業日の基準価額を採用し(S103)、即時に対価・代金の算出を行う(104)。具体的には、基準価額と申込口数(換金口数)に基づき対価を算出し、算出結果に手数料及び課税額を控除した額を代金として算出することができる。
次に、投信取引サーバ40は、電子マネー会社サーバ60に対し、電子マネーの発注を行う(S105)。
具体的には、S104において算出した代金に相当する電子マネーに関する発注処理を行う。
【0126】
そして、電子マネー会社サーバ60は、発注額に対応するギフトIDの発行又はチャージを行う(S106)。
例えば、nチャージが選択された場合、S104において算出された代金のギフトIDを発行するとともに、当該ギフトIDをユーザ端末30に送信する。
【0127】
これにより、ユーザは、ユーザ端末30を介して自身のnカード等に代金額をチャージすることができる。
また、dチャージが選択された場合、S104において算出した代金の金銭がユーザの電子マネー口座にチャージされる。
このような手順に基づいて、投資信託の換金の代金としての電子マネーをユーザに受け渡すことができる。
【0128】
以上のように、本発明の金融商品取引システム(投信取引システムS)は、ユーザ端末30における操作に基づいて、ユーザが保有する金融商品(投資信託)の換金の申込みを受け付ける申込受付部と、申込受付部により金融商品の換金の申込みを受け付けた場合に、申込みを受け付ける前の時価(申込日の前営業日の基準価額)を取引基準価格として決定する取引基準価格決定部と、取引基準価格決定部により決定した取引基準価格に基づいて金融商品の対価を算出する対価算出部と、対価算出部により算出した対価に相当する所定の電子有価財(電子マネー)を金融商品の換金の代金としてユーザに受け渡す処理を実行する代金受渡部と、を備えている。
【0129】
このような構成からなる本発明の投信取引システムSによれば、投資信託の換金の申込みがあった場合にはその投資信託の換金の代金を即時にユーザに受け渡すことが可能になる。
このため、投資信託の取引を迅速に行うことができ、ユーザの利便性を向上することができる。
特に、図22に示すように、従来の換金方法に比べ出金までの時間を大幅に短縮することができる。
図22は、従来の換金方法(現金による出金方法)と、本発明の換金方法(電子チャージ出金方法)とを、時系列で比較できるように表した比較図である。
なお、便宜上、換金対象の投資信託は海外商品であるものとする。
【0130】
図22に示すように、従来の換金方法(現金での出金)では、換金の申込みがあった日(申込日)から、約定、対価・代金の算出、解約指図、を経てユーザ口座に現金が振り込まれる(受渡日)までに5営業日を要していた。また、ユーザ口座に資金移動業者を利用して振り込む場合、振込先金融機関に応じてさらに1営業日~3営業日を要していた。
これに対し、本発明の換金方法である電子チャージ出金においては、従来の換金方法で行われる「解約指図」や「現金の振り込み」を必要としていない。
つまり、本発明においては、「解約指図」、解約指図に基づく保有資産の売却、当該売却で得た現金を用いた「現金の振り込み」を省くことができることに加え、対価・代金の算出、電子マネーの購入・チャージといった各処理をすべて即時に行われる結果、即時に出金を完了することができる。
このように、従来の換金では、複数の処理工程を一連に直列的に行っていたところ、本発明においては、その一部の処理工程を除外する(後処理に回す)ことで、迅速化を図っている。
【0131】
また、本発明は、代金の受渡方法として電子マネーなどの電子有価財を採用している。
これにより、営業日か休日かを問わず、常時、換金処理を実行することができる。
また、APIを活用することで、電子マネー会社サーバ60とは、即時に電子マネーの購入及び受渡し(ギフトIDの送信、口座への送金等)ができるようになっている。
また、換金申込時に即時に対価を算出することで即時出金に貢献している。
具体的には、申込時に既知の直前(申込日の前営業日)の基準価額を採用することで、対価・代金の算出を即時に実行できるようにしている。
これに対し、従来では、ブラインド方式のもと、対価の算出を翌営業日まで待って(国内商品の場合)又は翌々営業日まで待って(海外商品の場合)行わざるを得なかった。
このため、本発明によれば、従来に比べ極めて迅速に換金を完了することができ、換金を望むユーザの利便を向上させることができる。
【0132】
この他、本発明の投信取引システムSは、以下の(1)~(4)の特徴を有している。
(1)電子チャージ出金だけでなく、現金での出金を選択できるようにしている。
これにより、ユーザの好みで出金方法を選ぶことができるようになっている。
また、この点に関し、投信法第8条第1項には、「委託者指図型投資信託(主として換価の容易な資産に対する投資として運用することを目的とする投資信託であって受益者の保護に欠けるおそれがないものとして政令で定めるものを除く。)は、金銭信託でなければならない。」と定められているところ、本発明は、電子チャージ出金を選択肢で提示しているのみで、常に「現金で出金」を選択できるようにしているため、上記投信法に抵触しない。
つまり、単に現金での出金を電子チャージ出金に代えただけでは、上記投信法に抵触するおそれのあるところ、本発明では、電子チャージ出金と現金での出金を選択可能な構成にすることで、この問題を回避している。
【0133】
(2)ブラインド方式を採用しないことでも他の投資家(他の受益者)に損害を与えない構成にしている。
ブラインド方式は投資家間の公平性の確保のためであるところ、電子チャージ出金の際に行われる受益権の売買は、ユーザと委託会社との間で個別に行われる相対取引である。
なお、委託会社は、ユーザから買い取った受益権は、後に売却するなど、自身の裁量で処理することになる(後記「後処理について」参照)。
このため、ブラインド方式を採用しない本発明の電子チャージ出金であっても、信託財産からの資金の流出を伴うものではなく、他の受益者に対して損害を与えることはない。
つまり、単にブラインド方式を採用しないだけでは他の受益者に損害を与えるおそれのあるところ、本発明では、そのような問題が生じないよう必要な措置を施している。
【0134】
(3)前営業日の基準価額を採用することで、ユーザは解約代金を正確に把握したうえで換金の申込みができる。
(4)様々な要素を加味した手数料を設定可能である(前記(i)~(ii)及び後記「手数料について」参照)。
【0135】
(応用例・変形例)
以下、応用例・変形例等について説明する。
【0136】
(他の電子マネー等について)
上述の実施形態においては、第1電子マネーと第2電子マネーの2つの電子マネーを用いた代金の受渡方法について詳細に説明したが、これに限らず、他の電子有価財を用いることもできる。
例えば、nanaco(登録商標)などの第1電子マネーは、前払式支払手段としての共通型の電子マネー(プリペイド型電子マネー)であるが、スターバックス(登録商標)カードなどハウス型の電子マネーを本発明に適用することもできる。
この場合も、nチャージと同様、金額に紐付いたIDを、ユーザ端末30を介してユーザに知らせるなどによりユーザのアカウントにその金額分の電子マネーをチャージすることができる。
また、他の共通型の電子マネー(例えば、Edy(登録商標)など)やギフトIDと同様のギフトコードを採用するamazon(登録商標)についても、勿論、本発明に適用することができる。
また、上述の実施形態において、第1電子マネー(前払式支払手段)については、ギフトIDを介した方法によりチャージすることについて説明したが、第1電子マネーにおいて、ギフトIDを介さず、第2電子マネー(資金移動)と同様に、サーバの電子マネー口座に直接チャージするようにもできる。
【0137】
また、ドコモ口座などの第2電子マネー(資金移動)は、資金決済法を利用した送金機能(本人確認をすることで資金の移動が可能な機能)を備えた所謂電子ウォレットサービスであるが、この種の他の電子マネーサービス(例えば、LINE(登録商標)Payなど)を本発明に適用することもできる。
つまり、LINE Payにも本人確認に係る処理を予め行っておくことで、指定口座に送金することができるため、ドコモ口座と同様に換金の代金をユーザ口座に直接チャージすることができる。
【0138】
また、Tポイント(登録商標)やFiNC(登録商標)ポイントなどのポイントサービスがあるが、この種のポイントサービスを本発明に適用することもできる。
例えば、Fincポイントは、有効期限6ヶ月未満の場合には現金化ができ、現金での購入もできる。
このため、購入したポイントを対価としてユーザのアカウントに追加するといった実施形態をとることができる。
なお、ポイントは本発明の電子有価財の一例であるが、Fincポイントのように現金化できるものは電子マネーにも該当する。
現金化できないポイントサービスであっても、商品・サービスの購入代金の一部に充当したり、商品・サービスと交換することが可能なポイントであれば、当然に本発明の電子有価財に該当する。
【0139】
(手数料について)
電子チャージ出金における手数料は上記(i)~(ii)の他、様々な要素に基づいて設定することができる。
例えば、対象の電子マネーでの買い物/決済を一定期間内に一定回数又は一定金額以上した場合に手数料を低くすることができる。
「対象の電子マネー」は、例えば、電子チャージ出金に用いる電子マネーサービス(例えば第1電子マネーや第2電子マネー)とすることができる。
このようにすると、電子チャージ出金を利用するほど手数料を抑えることができるため電子チャージ出金の利用を促すことができる。
また、電子マネーの利用が促され、電子マネー会社にとっても他の電子マネーサービスよりも優位に事業を進めることができる。
委託会社にとっても、自身が運営する投信取引システムSの活性化を促すことができる。
【0140】
また、「対象の電子マネー」をお釣り運用サービスと連携している決済手段としての電子マネーにすることができる。
つまり、「対象の電子マネー」でお買い物をするユーザに対しては手数料を低く設定することができる。
また、「対象の電子マネー」でのお買い物の金額や頻度が多いほど手数料が低くなるように設定することもできる。
このようにすると、お買い物をするほどお釣りが増えるので、手数料を低減することができるとともに、お釣り運用サービスにおけるお釣りによる投資を増やすことができる。
【0141】
また、お釣り運用サービスの登録を、対象の電子マネーのアプリやウェブサイトから行ったユーザに対しては手数料を低くすることができる。
例えば、電子マネーのアプリ画面において登録サイトのURLをリンク表示したり、電子マネー会社のウェブ画面においてお釣り運用サービスのバナーを表示させる。
そして、リンク又はバナーの選択により表示される登録サイトからユーザ登録を行ったユーザに対しては、手数料を低くする。
【0142】
また、お釣り運用サービスにおけるお釣りによる投資額が、過去一定期間において一定の金額以上のユーザに対しては手数料を低くすることができる。
また、お釣り運用サービスにおけるお釣りによる投資総額が、一定の金額以上のユーザに対しては手数料を低くすることができる。
また、お釣り運用サービスの投信口座の残高の多寡に応じ、手数料を変動することもできる。
例えば、投信口座の残高が多いほど、手数料を低く設定することができる。
これにより、投資信託サービスの利用を促すとともに、電子マネーの利用を促すことができる。
なお、このような手数料の設定は、お釣り運用サービスだけでなく、通常の投資信託、その他の投資サービスにおいて適用することもできる。
【0143】
(後処理について)
委託会社は、電子マネー会社に対し、ユーザに受け渡すために購入した電子マネーの代金の支払いを、電子チャージ出金後に行うようにしている。
この他、委託会社は、電子チャージ出金後の後処理として、ユーザから買い取った投資信託(受益権)を従来の投資信託上の慣習ルールに則って売却することができる。
図23は、ユーザから買い取った受益権を売却する処理を説明するための図である。
なお、ユーザから買い取った受益権の売却の申込みを、電子チャージ出金が行われた日の翌営業日(T日とする)に行うものとする。
【0144】
ここで、投信取引システムSは、投資信託の取引に応じて金融商品取引法に従い顧客帳票(取引報告書等)を作成する。
従来の株式投信の換金取引では、投信取引システムSで作成される顧客帳票は「申込日」、「約定日」及び「受渡日」が異なる日付となる。
従来の換金方法とはまったく異なる取引態様である電子チャージ出金では、これらの日付がすべて同じ日になるが、従来の投信取引システムではこれは想定されていない。
【0145】
このため、投信取引システムSにおいては、電子チャージ出金において、便宜上、後処理における「申込日」、「約定日」及び「受渡日」を適用して顧客帳票(取引報告書等)を作成することとした。
そうすると、後処理における買取受益権の解約処理は、従来の換金方式において行われるため、いわゆる投信窓販システムの機能により自動的に顧客帳票を作成することができる。
具体的にはユーザの換金リクエストを販売会社が受付けた日をT日とすると、顧客帳票に記載される「申込日」はT+1営業日、「約定日」はT+2営業日、「受渡日」はT+6営業日となる。
ただし、顧客帳票の日付項目の読替え方法を帳票上で案内したり、実際の日付を設定するよう投信取引システムを改修したりもできる。
なお、振替機関(証券保管振替機構)は、図23に示すように、ユーザに対する換金と引き換えに受益権がユーザから販売会社に移転するが、振替機構向けには即時出金後の翌々営業日に、顧客口から自己口への振替および自己口の抹消の申請を行い、受渡日に振替機関にて振替および抹消の処理を行う。
【0146】
(即時出金の別の態様について)
前述した実施形態では、予め所得税及び住民税の源泉徴収額又は還付額を算出し、当該算出した源泉徴収額又は還付額を控除又は加算して出金する即時出金の態様について説明したが、これに限らず、即時出金時に多めに源泉徴収しておき、後に源泉徴収額又は還付額が確定した後に差額を追加出金する態様とすることもできる。
例えば、解約申込日をT日とした場合において、以下の(1)~(4)のフローが想定される。
(1)T日:「買取約定金額」、「譲渡損益額」及び「即時出金額」を算出し、電子マネーにて出金。
・譲渡損益額>0円の場合
「買取約定金額」=出金口数×社内時価÷計算口数
「源泉徴収額」=譲渡益×住民税率+譲渡益×所得税率
「即時出金額」=買取約定金額-源泉徴収額
なお、「社内時価」とは、即時出金日(解約申込日)の前営業日の基準価額からスプレッド(手数料)を控除した額のことをいう。
・譲渡損益額≦0円の場合
「買取約定金額」=出金口数×社内時価÷計算口数
「源泉徴収額」=0円
「即時出金額」=買取約定金額
(2)T+1日:投信窓販システムに買取注文ファイルを接続
(3)T+2日:投信窓販システムが買取約定計算を実施。これにより、源泉徴収額又は還付額が確定。
(4)T+3日:確定した源泉徴収額又は還付額に応じて次の通り電子マネーにて出金
・譲渡損益額>0円の場合
出金額=T日の源泉徴収額-確定した源泉徴収額
・譲渡損益額≦0円の場合
出金額=確定した還付額
このように、本発明においては、即時出金時に予め源泉徴収額又は還付額を加味して出金する態様や、段階的に出金する態様など、複数の出金態様を選択的に採用することができる。
【0147】
以上、本発明について、好ましい実施形態を示して説明したが、本発明は、上述した実施形態に限定されるものではなく、本発明の範囲で種々の変更実施が可能であることは言うまでもない。
例えば、上述した実施形態は、本発明をお釣り運用サービスにおける投資信託の換金処理に適用した一例であるが、本発明を通常の投資信託の換金処理に適用することは当然にできる。
また、この場合、電子チャージ出金において設けられる手数料を、上記「手数料について」にて説明した内容と同様に様々な観点で設定することもできる。
例えば、投資総額や投信口座の残高に応じ手数料を変動することができる。
【0148】
また、本発明を、他の金融商品の取引に適用することができる。
例えば、定期的に金利が変わる金利変動型の定期預金など、時価変動型の金融商品を途中解約する場合に、手数料を差し引かれたり金利が下げられるタイプの金融商品がある。
この種の金融商品において、任意のタイミングでの換金が可能である場合には、過去の直近の時価に基づいて商品の対価を算出し、算出された額の電子マネーをユーザに受け渡すようにすることができる。
また、金融商品の換金だけでなく、金融商品の購入にも本発明を適用することができる。
例えば、金融商品の購入申込時の直前の既知の時価に基づいてその商品の購入額を算出し、当該購入額の電子マネーを購入して販売先に受け渡すことと引き換えにユーザが金融商品を取得できるようにすることができる。
【0149】
また、投信取引サーバ40が認証部401を備えることで、投信取引システムSとしてユーザ認証機能を備えているが、必ずしも、投信取引サーバ40が認証部401を備える必要もなく、他の装置に認証部を備える態様であってもよい。
さらには、投信取引サーバ40や投信取引システムSがユーザ認証機能を有する必要はなく、例えば、資金運用システム1の装置等、ネットワークでつながれた外部装置にユーザ認証機能があれば、投信取引システムSは、その機能を利用することで足りる。
【0150】
また、図15に示すように、前述の実施形態では、出金の際、ユーザ端末30の操作画面にユーザの口数残高を表示し、当該残高口数の範囲内で口数を入力することで、当該入力された口数の解約によって、当該解約口数に対応する金額の電子マネーがチャージされるようにしたが、このような方法に限るものではない。
例えば、チャージしたい金額を入力するようにもできる。
この場合、ユーザ端末30の操作画面に金額入力欄を設けることで、チャージしたい金額を金額入力欄に入力できるようにできる。
なお、金額入力欄と共に口座残高(金額)を表示するようにして、チャージ可能な金額をユーザに示すこともできる。
金額が入力されると、投信取引サーバ40において、直近の基準価額、手数料、税金調整額を求め、これらを加味した口数を算出する。
具体的には、入力金額を超える最小の口数を算出することができる。
より具体的には、下記式の算出結果を超える最小の口数を算出する。
[(入力金額+税金調整額)/(1-手数料率)]/前営業日の基準価額
例えば、入力金額が3000円、前営業日の基準価額が12000円/1万口、手数料率が5%、課税額が100円とすると、[(3000+100)/(1-0.05)]/1.2=2719.3という算出結果になることから、2720が口数として算出される。
そして、この結果、3264円(≒2720×1.2)から手数料(163円)及び課税額(100円)が引かれた3001円分の電子マネーがチャージされることになる。
このような方法によれば、ユーザは、まさに使いたい金額を入力することができるため、出金時の利便性をさらに向上させることができる。
なお、口数の算出においては、上述した「入力金額を超える最小の口数」以外にも、例えば「入力金額を超えない最大の口数(前述の例の場合2719口)」や「入力金額に最も近い口数」を採用してもよく、これらを選択的(例えばユーザに選択させるなど)に採用することもできる。また、「超える」、「超えない」の代わりに「以上」、「以下」であってもよい。
【産業上の利用可能性】
【0151】
本発明は、投資信託などの金融商品の取引において好適に利用することができる。
【符号の説明】
【0152】
S 投信取引システム
30 ユーザ端末
312 換金申込部
40 投信取引サーバ
402 申込受付部
403 対価算出部
404 手数料算出部
406 取引基準価格決定部
407 電子マネー発注部
50 業務支援サーバ
60 電子マネー会社サーバ
601 電子マネー処理部(代金受渡部)
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13
図14
図15
図16
図17
図18
図19
図20
図21
図22
図23