知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2022044581
(43)【公開日】2022-03-17
(54)【発明の名称】情報処理装置、情報処理方法、及びプログラム
(51)【国際特許分類】
G06Q 40/06 20120101AFI20220310BHJP
【ＦＩ】
G06Q40/06
【審査請求】未請求
【請求項の数】6
【出願形態】ＯＬ
(21)【出願番号】P 2021145730
(22)【出願日】2021-09-07
(31)【優先権主張番号】P 2020149692
(32)【優先日】2020-09-07
(33)【優先権主張国・地域又は機関】JP
(31)【優先権主張番号】P 2020186369
(32)【優先日】2020-11-09
(33)【優先権主張国・地域又は機関】JP
(71)【出願人】
【識別番号】516035910
【氏名又は名称】株式会社ＦＯＬＩＯ
(74)【代理人】
【識別番号】100205659
【弁理士】
【氏名又は名称】齋藤 拓也
(74)【代理人】
【識別番号】100154748
【弁理士】
【氏名又は名称】菅沼 和弘
(72)【発明者】
【氏名】高山 智史
【テーマコード（参考）】
5L055
【Ｆターム（参考）】
5L055BB57
(57)【要約】
【課題】金融機関個社における複数の運用サービスについて、同時運用が実現可能とすること。
【解決手段】所定対象を管理する管理者の装置のうち、所定対象が管理される管理単位において、第１種管理単位と第２種管理単位とを区別管理している別情報処理装置と少なくとも通信をするサービス提供者サーバ１であって、バーチャル口座管理部５１は、第１種管理単位の枠内で運営されるＮ個（Ｎは、１以上の整数値）のサービスの夫々に対して、サービス提供者サーバ１内における第１種管理単位がＮ個に区分された結果得られるＮ個の個別単位の夫々を対応付けて、Ｎ個の個別単位を管理する処理を実行する。
【選択図】図８
【解決手段】所定対象を管理する管理者の装置のうち、所定対象が管理される管理単位において、第１種管理単位と第２種管理単位とを区別管理している別情報処理装置と少なくとも通信をするサービス提供者サーバ１であって、バーチャル口座管理部５１は、第１種管理単位の枠内で運営されるＮ個（Ｎは、１以上の整数値）のサービスの夫々に対して、サービス提供者サーバ１内における第１種管理単位がＮ個に区分された結果得られるＮ個の個別単位の夫々を対応付けて、Ｎ個の個別単位を管理する処理を実行する。
【選択図】図８
【特許請求の範囲】
【請求項1】
所定対象を管理する管理者の装置のうち、所定対象が管理される管理単位において、第１種管理単位と第２種管理単位とを区別管理している別情報処理装置と少なくとも通信をする情報処理装置であって、
前記第１種管理単位の枠内で運営されるＮ個（Ｎは、１以上の整数値）のサービスの夫々に対して、前記情報処理装置内における前記第１種管理単位が前記Ｎ個に区分された結果得られる前記Ｎ個の個別単位の夫々を対応付けて、当該Ｎ個の当該個別単位を管理する処理を実行する個別単位管理手段
を備える情報処理装置。
前記第１種管理単位の枠内で運営されるＮ個（Ｎは、１以上の整数値）のサービスの夫々に対して、前記情報処理装置内における前記第１種管理単位が前記Ｎ個に区分された結果得られる前記Ｎ個の個別単位の夫々を対応付けて、当該Ｎ個の当該個別単位を管理する処理を実行する個別単位管理手段
を備える情報処理装置。
【請求項2】
前記所定対象は資産であり、
前記管理単位は、エンドユーザの取引口座であり、
前記第１種管理単位は、前記エンドユーザの投資一任契約管理下の資産である一任資産であり、
前記第２種管理単位は、エンドユーザの当該投資一任契約管理外の資産である非一任資産であり、
前記サービスは、運用サービスであり、
前記個別単位は、バーチャル口座であり、
前記個別単位管理手段は、
前記一任資産の枠内で運営される前記Ｎ個の前記運用サービスの夫々に対して、前記情報処理装置内における前記一任資産が前記Ｎ個に区分された結果得られる前記Ｎ個の前記バーチャル口座の夫々を対応付け、当該Ｎ個の当該バーチャル口座を管理する、
請求項１に記載の情報処理装置。
前記管理単位は、エンドユーザの取引口座であり、
前記第１種管理単位は、前記エンドユーザの投資一任契約管理下の資産である一任資産であり、
前記第２種管理単位は、エンドユーザの当該投資一任契約管理外の資産である非一任資産であり、
前記サービスは、運用サービスであり、
前記個別単位は、バーチャル口座であり、
前記個別単位管理手段は、
前記一任資産の枠内で運営される前記Ｎ個の前記運用サービスの夫々に対して、前記情報処理装置内における前記一任資産が前記Ｎ個に区分された結果得られる前記Ｎ個の前記バーチャル口座の夫々を対応付け、当該Ｎ個の当該バーチャル口座を管理する、
請求項１に記載の情報処理装置。
【請求項3】
前記個別単位管理手段は、
バックオフィスシステムで発生した前記エンドユーザの前記一任資産に関わる全てのトランザクションの処理を実行することで、前記バックオフィスシステム内の前記一任資産と前記情報処理装置内の前記一任資産の一致の状態を維持するように管理する一任資産一致管理手段と、
前記一致の状態を前提として、前記Ｎ個の運用サービス毎に、夫々対応付けられた前記バーチャル口座を用いたトランザクションの処理を実行することで、前記Ｎ個のバーチャル口座を管理する個別単位管理手段と、
を有する請求項２に記載の情報処理装置。
バックオフィスシステムで発生した前記エンドユーザの前記一任資産に関わる全てのトランザクションの処理を実行することで、前記バックオフィスシステム内の前記一任資産と前記情報処理装置内の前記一任資産の一致の状態を維持するように管理する一任資産一致管理手段と、
前記一致の状態を前提として、前記Ｎ個の運用サービス毎に、夫々対応付けられた前記バーチャル口座を用いたトランザクションの処理を実行することで、前記Ｎ個のバーチャル口座を管理する個別単位管理手段と、
を有する請求項２に記載の情報処理装置。
【請求項4】
前記個別単位管理手段は、
前記Ｎ個の運用サービスのうち所定運用サービスについての前記トランザクションの処理として、前記エンドユーザの操作に基づくトランザクションの処理を実行するエンドユーザトランザクション実行手段と、
所定運用サービスについての前記トランザクションの処理として、前記バックオフィスシステムで発生した前記トランザクションのうち前記所定運用サービスに係るトランザクションの処理を実行するバックオフィス発生トランザクション実行手段と、
を含む請求項３に記載の情報処理装置。
前記Ｎ個の運用サービスのうち所定運用サービスについての前記トランザクションの処理として、前記エンドユーザの操作に基づくトランザクションの処理を実行するエンドユーザトランザクション実行手段と、
所定運用サービスについての前記トランザクションの処理として、前記バックオフィスシステムで発生した前記トランザクションのうち前記所定運用サービスに係るトランザクションの処理を実行するバックオフィス発生トランザクション実行手段と、
を含む請求項３に記載の情報処理装置。
【請求項5】
所定対象を管理する管理者の装置のうち、所定対象が管理される管理単位において、第１種管理単位と第２種管理単位とを区別管理している別情報処理装置と少なくとも通信をする情報処理装置が実行する情報処理方法であって、
前記第１種管理単位の枠内で運営されるＮ個（Ｎは、１以上の整数値）のサービスの夫々に対して、前記情報処理装置内における前記第１種管理単位が前記Ｎ個に区分された結果得られる前記Ｎ個の個別単位の夫々を対応付けて、当該Ｎ個の当該個別単位を管理する処理を実行する個別単位管理ステップ
を含む情報処理方法。
前記第１種管理単位の枠内で運営されるＮ個（Ｎは、１以上の整数値）のサービスの夫々に対して、前記情報処理装置内における前記第１種管理単位が前記Ｎ個に区分された結果得られる前記Ｎ個の個別単位の夫々を対応付けて、当該Ｎ個の当該個別単位を管理する処理を実行する個別単位管理ステップ
を含む情報処理方法。
【請求項6】
所定対象を管理する管理者の装置のうち、所定対象が管理される管理単位において、第１種管理単位と第２種管理単位とを区別管理している別コンピュータと少なくとも通信をするコンピュータに、
前記第１種管理単位の枠内で運営されるＮ個（Ｎは、１以上の整数値）のサービスの夫々に対して、前記コンピュータ内における前記第１種管理単位が前記Ｎ個に区分された結果得られる前記Ｎ個の個別単位の夫々を対応付けて、当該Ｎ個の当該個別単位を管理する処理を実行する個別単位管理ステップ
を含む制御処理を実行するプログラム。
前記第１種管理単位の枠内で運営されるＮ個（Ｎは、１以上の整数値）のサービスの夫々に対して、前記コンピュータ内における前記第１種管理単位が前記Ｎ個に区分された結果得られる前記Ｎ個の個別単位の夫々を対応付けて、当該Ｎ個の当該個別単位を管理する処理を実行する個別単位管理ステップ
を含む制御処理を実行するプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、情報処理装置、情報処理方法、及びプログラムに関する。
【背景技術】
【0002】
従来、金融資産の管理として、投資先の提案や管理をする技術が存在する（例えば、特許文献１参照）。
【先行技術文献】
【特許文献】
【0003】
【特許文献1】特開２０１６－０９５７２４号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
上述の特許文献１を含む従来技術では、金融機関個社における複数の運用サービスについて、同時運用が求められているが、出来ない状況であった。
【0005】
本発明は、このような状況に鑑みてなされたものであり、金融機関個社における複数の運用サービスについて、同時運用が実現可能とすることを目的とする。
【課題を解決するための手段】
【0006】
上記目的を達成するため、本発明の一態様の情報処理装置は、
所定対象を管理する管理者の装置のうち、所定対象が管理される管理単位において、第１種管理単位と第２種管理単位とを区別管理している別情報処理装置と少なくとも通信をする情報処理装置であって、
前記第１種管理単位の枠内で運営されるＮ個（Ｎは、１以上の整数値）のサービスの夫々に対して、前記情報処理装置内における前記第１種管理単位が前記Ｎ個に区分された結果得られる前記Ｎ個の個別単位の夫々を対応付けて、当該Ｎ個の当該個別単位を管理する処理を実行する個別単位管理手段
を備える。
所定対象を管理する管理者の装置のうち、所定対象が管理される管理単位において、第１種管理単位と第２種管理単位とを区別管理している別情報処理装置と少なくとも通信をする情報処理装置であって、
前記第１種管理単位の枠内で運営されるＮ個（Ｎは、１以上の整数値）のサービスの夫々に対して、前記情報処理装置内における前記第１種管理単位が前記Ｎ個に区分された結果得られる前記Ｎ個の個別単位の夫々を対応付けて、当該Ｎ個の当該個別単位を管理する処理を実行する個別単位管理手段
を備える。
【0007】
本発明の一態様の上記情報処理装置に対応する情報処理方法及びプログラムも、本発明の一態様の情報処理方法及びプログラムとして提供される。
【発明の効果】
【0008】
本発明によれば、金融機関個社における複数の運用サービスについて、同時運用が実現可能とすることができる。
【図面の簡単な説明】
【0009】
【図1】本発明の第１実施形態と比較するための従来の手法を説明するための図であって、個社バックオフィスシステムの区別管理の概要を示す図である。
【図2】本発明の第１実施形態と比較するための従来の手法を説明するための図であって、一任資産を管理する箱を拡張する形式の概要を示す図である。
【図3】本発明の第１実施形態と比較するための従来の手法の課題を説明するための図であって、サブアカウント方式における同時運用の課題の概要を示す図である。
【図4】本発明の第１実施形態と比較するための従来の手法の課題を説明するための図であって、サブアカウント方式における同時運用の課題の概要を示す図である。
【図5】本発明の第１実施形態と比較するための従来の手法の課題を説明するための図であって、専用商品方式における同時運用の課題の概要を示す図である。
【図6】本発明の第１実施形態のサービス提供者サーバを含む情報処理システムの構成を示す図である。
【図16】第１実施形態のサービス提供者サーバ１が奏することが可能な効果の具体例として、本格的なゴールベース運用の提供の例を示す図である。
【図18】本発明の第２実施形態と比較するための従来の手法を、サブアカウント方式を例として説明する図である。
【図20】本発明の第２実施形態と比較するための従来の手法の課題として、媒介送客の課題について説明する図である。
【図21】本発明の第２実施形態のサービス提供者サーバを含む情報処理システムの構成を示す図である。
【図23】投資運用業者が運用する運用サービスについての投資一任契約の契約状態の管理手法の概要を示す図である。
【図24】エンドユーザによる、投資運用業者との投資一任契約の申込みの流れの概要を示す図である。
【図25】エンドユーザによる、投資運用業者との投資一任契約の解約の流れの概要を示す図である。
【図27】運用サービスデータに対するアクセス制御に必要な、運用サービスと投資運用業者との紐付けの概要を示す図である。
【図28】運用サービスデータに対するアクセス制御の概要を示す図である。
【図29】エンドユーザデータの取得及び管理の概要を示す図である。
【図30】エンドユーザデータに対するアクセス制御の概要を示す図である。
【図31】金融機関個社と投資運用業者のハブ機能の概要を示す図である。
【図35】運用サービスの概要を示す図である。
【図36】投資一任契約書面のテンプレートの一例を示す図である。
【図37】運用サービスと運用サービスＩＤの関係性を示す図である。
【図38】エンドユーザと口座の関係性を示す図である。
【図39】総合口座と取引口座の関係性を示す図である。
【図40】総合口座と口座区分の管理の一例を示す図である。
【図41】ファンド口座とバーチャル口座コードの関係性を示す図である。
【図42】投資対象の取り扱いの一例を示す図である。
【図43】新規拠出の流れの一例を示す図である。
【図44】リバランスの流れを示す図である。
【図45】ポータビリティとコマンドの関係を示す図である。
【図46】投資一任契約の締結および付随する機能のプラグイン化を示す図である。
【図47】書面の電子交付の接続方式の例を示す図である。
【発明を実施するための形態】
【0010】
［第１実施形態］
以下、本発明の第１実施形態について図面を用いて説明する。
以下、本発明の第１実施形態について図面を用いて説明する。
【0011】
先ず、本発明の第１実施形態について説明する前に、従来手法とその課題について説明する。
図１は、本発明の第１実施形態と比較するための従来の手法を説明するための図であって、個社バックオフィスシステムの区別管理の概要を示す図である。
図１は、本発明の第１実施形態と比較するための従来の手法を説明するための図であって、個社バックオフィスシステムの区別管理の概要を示す図である。
【0012】
投資一任契約管理外の資産（以下、「非一任資産」と呼ぶ）を管理している金融機関個社において新たに運用サービスを開始するためには、投資一任契約管理下の資産（以下、「一任資産」と呼ぶ）を区別管理する必要がある。
一任資産と非一任資産の区別管理は、個社が保有する個社バックオフィスシステムで行なわれる。
区別管理する方法は、取引口座に紐づく一任資産を管理するサブアカウントを開設する方法（以下、「サブアカウント方式」と呼ぶ）、及び一任資産の専用商品を用意する方法（以下、「専用商品方式」と呼ぶ）の２つが存在する。
複数の投資一任契約を同時に締結したいとなった場合、従来手法として個社バックオフィスシステム内で一任資産を管理する箱を拡張する形式が取られていた。
区別管理とは、投資一任契約に基づき投資運用業者に運用が一任されている資産について、エンドユーザが投資運用業者のあずかり知らぬところで、売買や出金を行ってしまわないよう、制限を設けることを指す。
サブアカウント方式と専用商品方式の違いは現金の取り扱いによるものである（サブアカウント方式では現金は現金のまま取り扱う、専用商品方式では現金相当の証券（例えばＭＲＦ）に変換して取り扱う）。
一任資産と非一任資産の区別管理は、個社が保有する個社バックオフィスシステムで行なわれる。
区別管理する方法は、取引口座に紐づく一任資産を管理するサブアカウントを開設する方法（以下、「サブアカウント方式」と呼ぶ）、及び一任資産の専用商品を用意する方法（以下、「専用商品方式」と呼ぶ）の２つが存在する。
複数の投資一任契約を同時に締結したいとなった場合、従来手法として個社バックオフィスシステム内で一任資産を管理する箱を拡張する形式が取られていた。
区別管理とは、投資一任契約に基づき投資運用業者に運用が一任されている資産について、エンドユーザが投資運用業者のあずかり知らぬところで、売買や出金を行ってしまわないよう、制限を設けることを指す。
サブアカウント方式と専用商品方式の違いは現金の取り扱いによるものである（サブアカウント方式では現金は現金のまま取り扱う、専用商品方式では現金相当の証券（例えばＭＲＦ）に変換して取り扱う）。
【0013】
ここで、エンドユーザは総合口座を保有する名義人をいう。なお、名義人は、自然人または法人である。
エンドユーザが行う所定の行為の主体、通常エンドユーザであるが、エンドユーザから委託された他の者によるものであるものも含む。
委託された他の者には例えば、保護者、未成年後見人、成年後見人、運用サービスの販売会社の営業担当者などがある。
運用サービスの販売会社は金融機関個社の場合もあれば、金融機関個社へ媒介または代理する仲介業者などがある。
エンドユーザが行う所定の行為の主体、通常エンドユーザであるが、エンドユーザから委託された他の者によるものであるものも含む。
委託された他の者には例えば、保護者、未成年後見人、成年後見人、運用サービスの販売会社の営業担当者などがある。
運用サービスの販売会社は金融機関個社の場合もあれば、金融機関個社へ媒介または代理する仲介業者などがある。
【0014】
図２は、本発明の第１実施形態と比較するための従来の手法を説明するための図であって、一任資産を管理する箱を拡張する形式の概要を示す図である。
【0015】
複数の投資一任契約を同時に締結したいとなった場合、従来手法として個社バックオフィスシステム内で一任資産を管理する箱を拡張する形式が取られていた。
この従来手法では、複数の運用サービスを一つの取引口座で同時に運用するという点（以下、「同時運用」と呼ぶ）に関して課題があった。
以下ではサブアカウント方式、専用商品方式における同時運用の課題を述べる。
この従来手法では、複数の運用サービスを一つの取引口座で同時に運用するという点（以下、「同時運用」と呼ぶ）に関して課題があった。
以下ではサブアカウント方式、専用商品方式における同時運用の課題を述べる。
【0016】
図３は、本発明の第１実施形態と比較するための従来の手法の課題を説明するための図であって、サブアカウント方式における同時運用の課題の概要を示す図である。
【0017】
サブアカウント方式では、複数の運用サービスを導入している既存サービスが存在する。
それら既存サービスでは、ファンド口座におけるバーチャル口座コードに相当する概念（例えば部店など）を使って、運用サービスの申し込みを受けてサブアカウントの開設を行なっている。
しかしながらこの手法では、バーチャル口座コードに相当する情報を事前に定義して、サブアカウントの開設を行なう必要があり、「任意の数の同時運用」を提供しているサービスは存在しない。
それら既存サービスでは、ファンド口座におけるバーチャル口座コードに相当する概念（例えば部店など）を使って、運用サービスの申し込みを受けてサブアカウントの開設を行なっている。
しかしながらこの手法では、バーチャル口座コードに相当する情報を事前に定義して、サブアカウントの開設を行なう必要があり、「任意の数の同時運用」を提供しているサービスは存在しない。
【0018】
図４は、本発明の第１実施形態と比較するための従来の手法の課題を説明するための図であって、サブアカウント方式における同時運用の課題の概要を示す図である。
【0019】
これは、個社バックオフィスシステムがその責務である様々な処理（例えば、譲渡益税の源泉徴収など）のために、次の第１処理乃至第３処理という流れを実装する必要がある。
第１処理とは、複数のサブアカウントを含む取引口座全体で発生したトランザクションや資産状況の把握のためのデータの集約の処理である。
第２処理とは、集約した取引口座全体のトランザクションやデータの処理（トランザクション作成）である。
第３処理とは、取引口座全体に対して作成されたトランザクションを、非一任資産や各サブアカウントに対するトランザクションとして分割、再作成し、実行する処理（適用）である。
このような第１処理乃至第３処理という集約と分割の流れを実装する必要がある理由は、取引口座とファンド口座という異なる粒度の処理を一つのシステムで表現することの難しさによるものである。
このシステム的な難度（コスト）からビジネス的に一定規模以上の販売が必要で、事前設定による運用サービスの同時運用を提供しているサービスは大手金融機関個社に限定されている状況である。
第１処理とは、複数のサブアカウントを含む取引口座全体で発生したトランザクションや資産状況の把握のためのデータの集約の処理である。
第２処理とは、集約した取引口座全体のトランザクションやデータの処理（トランザクション作成）である。
第３処理とは、取引口座全体に対して作成されたトランザクションを、非一任資産や各サブアカウントに対するトランザクションとして分割、再作成し、実行する処理（適用）である。
このような第１処理乃至第３処理という集約と分割の流れを実装する必要がある理由は、取引口座とファンド口座という異なる粒度の処理を一つのシステムで表現することの難しさによるものである。
このシステム的な難度（コスト）からビジネス的に一定規模以上の販売が必要で、事前設定による運用サービスの同時運用を提供しているサービスは大手金融機関個社に限定されている状況である。
【0020】
図５は、本発明の第１実施形態と比較するための従来の手法の課題を説明するための図であって、専用商品方式における同時運用の課題の概要を示す図である。
【0021】
専用商品方式での同時運用の実現には、夫々の運用サービス毎の資産を区別管理するために異なる投資対象を用意する必要があった。
しかしながら、任意の数の運用サービスに対して異なる投資対象を用意しようとすることは、以下のような第１理由及び第２理由から現実的に不可能である。
第１理由とは、上場証券（例えば個別株やＥＴＦなど）は投資対象が自由に組成できないという理由である。
第２理由とは、非上場証券（例えば国内非上場投信など）はある程度のレベルまで組成が可能だが、組成のための期間と大きなコストを要するという理由である。
そのため、専用商品方式で複数の運用サービスの同時運用を提供している既存サービスは存在しない。
専用商品方式で複数種類の運用サービスを提供しているところはあるが、排他的であったり、取引口座の制約があったりして、同一取引口座で複数の運用サービスの同時運用が可能な既存サービスは存在していない状況である。
しかしながら、任意の数の運用サービスに対して異なる投資対象を用意しようとすることは、以下のような第１理由及び第２理由から現実的に不可能である。
第１理由とは、上場証券（例えば個別株やＥＴＦなど）は投資対象が自由に組成できないという理由である。
第２理由とは、非上場証券（例えば国内非上場投信など）はある程度のレベルまで組成が可能だが、組成のための期間と大きなコストを要するという理由である。
そのため、専用商品方式で複数の運用サービスの同時運用を提供している既存サービスは存在しない。
専用商品方式で複数種類の運用サービスを提供しているところはあるが、排他的であったり、取引口座の制約があったりして、同一取引口座で複数の運用サービスの同時運用が可能な既存サービスは存在していない状況である。
【0022】
次に、上述の従来手法が有する課題を解決可能な、本発明の第１実施形態について説明する。
【0023】
図６は、本発明の第１実施形態のサービス提供者サーバを含む情報処理システムの構成を示す図である。
【0024】
図６に示す情報処理システムは、サービス提供者により管理されるサービス提供者サーバ１と、金融機関個社Ｋにより管理される個社バックオフィスシステム２及び個社運用サーバ３と、エンドユーザにより管理されるエンドユーザ端末４とを含むように構成されている。
サービス提供者サーバ１、個社バックオフィスシステム２及び個社運用サーバ３、並びに、エンドユーザ端末４は、所定のネットワークＮを介して相互に接続されている。なお、ネットワークＮは、本実施形態ではインターネットとされるが、その形態は特に限定されず、その他例えば、Ｂｌｕｅｔｏｏｔｈ（登録商標）、Ｗｉ－Ｆｉ、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）等を採用することができる。
サービス提供者サーバ１、個社バックオフィスシステム２及び個社運用サーバ３、並びに、エンドユーザ端末４は、所定のネットワークＮを介して相互に接続されている。なお、ネットワークＮは、本実施形態ではインターネットとされるが、その形態は特に限定されず、その他例えば、Ｂｌｕｅｔｏｏｔｈ（登録商標）、Ｗｉ－Ｆｉ、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）等を採用することができる。
【0025】
図７は、図６の情報処理システムのうちサービス提供者サーバ１のハードウェア構成の一例を示すブロック図である。
サービス提供者サーバ１は、ＣＰＵ１１と、ＲＯＭ１２と、ＲＡＭ１３と、バス１４と、入出力インターフェース１５と、出力部１６と、入力部１７と、記憶部１８と、通信部１９と、ドライブ２０と、を備えている。
サービス提供者サーバ１は、ＣＰＵ１１と、ＲＯＭ１２と、ＲＡＭ１３と、バス１４と、入出力インターフェース１５と、出力部１６と、入力部１７と、記憶部１８と、通信部１９と、ドライブ２０と、を備えている。
【0026】
ＣＰＵ１１は、ＲＯＭ１２に記録されているプログラム、又は、記憶部１８からＲＡＭ１３にロードされたプログラムに従って各種の処理を実行する。
ＲＡＭ１３には、ＣＰＵ１１が各種の処理を実行する上において必要なデータ等も適宜記憶される。
ＲＡＭ１３には、ＣＰＵ１１が各種の処理を実行する上において必要なデータ等も適宜記憶される。
【0027】
ＣＰＵ１１、ＲＯＭ１２及びＲＡＭ１３は、バス１４を介して相互に接続されている。このバス１４にはまた、入出力インターフェース１５も接続されている。入出力インターフェース１５には、出力部１６、入力部１７、記憶部１８、通信部１９及びドライブ２０が接続されている。
【0028】
出力部１６は、ディスプレイやスピーカ等で構成され、各種情報を画像や音声として出力する。
入力部１７は、キーボードやマウス等で構成され、各種情報を入力する。
入力部１７は、キーボードやマウス等で構成され、各種情報を入力する。
【0029】
記憶部１８は、ハードディスクやＤＲＡＭ（Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）等で構成され、各種データを記憶する。
通信部１９は、インターネットを含むネットワークＮを介して他の装置（図６の例では、個社バックオフィスシステム２、個社運用サーバ３、及びエンドユーザ端末４）との間で通信を行う。
通信部１９は、インターネットを含むネットワークＮを介して他の装置（図６の例では、個社バックオフィスシステム２、個社運用サーバ３、及びエンドユーザ端末４）との間で通信を行う。
【0030】
ドライブ２０には、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリ等よりなる、リムーバブルメディア３１が適宜装着される。ドライブ２０によってリムーバブルメディア３１から読み出されたプログラムは、必要に応じて記憶部１８にインストールされる。
また、リムーバブルメディア３１は、記憶部１８に記憶されている各種データも、記憶部１８と同様に記憶することができる。
また、リムーバブルメディア３１は、記憶部１８に記憶されている各種データも、記憶部１８と同様に記憶することができる。
【0031】
【0032】
次に、図８を参照して、図７に示すハードウェア構成を有するサービス提供者サーバ１の機能的構成について説明する。
図８は、本発明の情報処理装置の第１実施形態に係る図７に示すサービス提供者サーバの機能的構成の一例を示す機能ブロック図である。
図８は、本発明の情報処理装置の第１実施形態に係る図７に示すサービス提供者サーバの機能的構成の一例を示す機能ブロック図である。
【0033】
【0034】
【0035】
上述の図１乃至図５を参照して説明した従来手法の課題を解決し、同時運用を実現するための、本発明の第１実施形態の基本方針は次の方針１及び方針２である。
即ち、方針１とは、図９に示すように、個社バックオフィスシステム２で非一任資産と一任資産の区別がなされることである。
方針２とは、図９に示すように、運用サービス毎の一任資産を細分化したファンド口座（以下、「バーチャル口座」とも適宜呼ぶ）の管理システムがサービス提供者サーバ１に設けられる（個社バックオフィスシステム２からみたら外付けになる）ことである。
この方針２の「運用サービス毎の一任資産を細分化したファンド口座の管理システム」が、バーチャル口座管理部５１である。
即ち、方針１とは、図９に示すように、個社バックオフィスシステム２で非一任資産と一任資産の区別がなされることである。
方針２とは、図９に示すように、運用サービス毎の一任資産を細分化したファンド口座（以下、「バーチャル口座」とも適宜呼ぶ）の管理システムがサービス提供者サーバ１に設けられる（個社バックオフィスシステム２からみたら外付けになる）ことである。
この方針２の「運用サービス毎の一任資産を細分化したファンド口座の管理システム」が、バーチャル口座管理部５１である。
【0036】
上記方針１は、専用商品方式、サブアカウント方式のいずれかを採用することで、ほとんどの個社バックオフィスシステム２において実現が可能である。
よって、方針２を実現可能なバーチャル口座管理部５１を採用することにより、ほとんどの個社バックオフィスシステム２において複数の運用サービスの同時運用が可能となる。
よって、方針２を実現可能なバーチャル口座管理部５１を採用することにより、ほとんどの個社バックオフィスシステム２において複数の運用サービスの同時運用が可能となる。
【0037】
換言すると、エンドユーザの資産を管理する金融機関個社Ｋの装置のうち、個社バックオフィスシステム２が、エンドユーザの取引口座において、エンドユーザの投資一任契約管理下の資産である一任資産と、エンドユーザの当該投資一任契約管理外の資産である非一任資産とを区別管理していることを前提とする（上記方針１）。
バーチャル口座管理部５１は、通信部１９を介して個社バックオフィスシステム２と通信をして、次のような管理を実行する。
バーチャル口座管理部５１は、一任資産の枠内で運営されるＮ個（Ｎは、１以上の整数値）の運用サービスの夫々に対して、サービス提供者サーバ１における一任資産がＮ個に区分された結果得られるＮ個のファンド口座（図９の例では４個の一任資産Ａ乃至Ｄ）の夫々を対応付けて、当該Ｎ個のファンド口座を管理する処理を実行する。
バーチャル口座管理部５１は、通信部１９を介して個社バックオフィスシステム２と通信をして、次のような管理を実行する。
バーチャル口座管理部５１は、一任資産の枠内で運営されるＮ個（Ｎは、１以上の整数値）の運用サービスの夫々に対して、サービス提供者サーバ１における一任資産がＮ個に区分された結果得られるＮ個のファンド口座（図９の例では４個の一任資産Ａ乃至Ｄ）の夫々を対応付けて、当該Ｎ個のファンド口座を管理する処理を実行する。
【0038】
具体的には、バーチャル口座管理部５１には、一任資産一致管理部６１と、個別管理部６２とが設けられている。
図１０は、バーチャル口座管理部における、一任資産一致管理部と個別管理部との概要について、図４の従来の手法と比較して説明する図である。
個社バックオフィスシステム２において、一任資産と非一任資産とが区別管理されている点は、図４の従来の手法と同様である。
しかしながら、図４の従来の手法では、個社バックオフィスシステム２の取引口座の枠組内で、運用サービス毎にサブアカウントが設定されて管理されていた。
これに対して、本発明の第１実施形態では、個社バックオフィスシステム２の取引口座においては、一任資産と非一任資産とが単に区別管理されているだけである。運用サービス毎の管理は、サービス提供者サーバ１内において運用サービス毎のファンド口座（図１０の例ではファンド口座Ａ乃至Ｃ）により個別に行われるのである。
このような管理を行う機能ブロックが、バーチャル口座管理部５１である。
具体的には、ステップＳＡにおいて、一任資産一致管理部６１は、個社バックオフィスシステム２との間でトランザクションの共有を図る。
ステップＳＢにおいて、個別管理部６２は、ファンド口座毎にトランザクションの適用を図る。ここで、トランザクションの適用とは、取引口座全体に対するトランザクションをファンド口座単位に分割、再構成し、ファンド口座毎に個別のトランザクションの処理を実行することを意味する。
図１０は、バーチャル口座管理部における、一任資産一致管理部と個別管理部との概要について、図４の従来の手法と比較して説明する図である。
個社バックオフィスシステム２において、一任資産と非一任資産とが区別管理されている点は、図４の従来の手法と同様である。
しかしながら、図４の従来の手法では、個社バックオフィスシステム２の取引口座の枠組内で、運用サービス毎にサブアカウントが設定されて管理されていた。
これに対して、本発明の第１実施形態では、個社バックオフィスシステム２の取引口座においては、一任資産と非一任資産とが単に区別管理されているだけである。運用サービス毎の管理は、サービス提供者サーバ１内において運用サービス毎のファンド口座（図１０の例ではファンド口座Ａ乃至Ｃ）により個別に行われるのである。
このような管理を行う機能ブロックが、バーチャル口座管理部５１である。
具体的には、ステップＳＡにおいて、一任資産一致管理部６１は、個社バックオフィスシステム２との間でトランザクションの共有を図る。
ステップＳＢにおいて、個別管理部６２は、ファンド口座毎にトランザクションの適用を図る。ここで、トランザクションの適用とは、取引口座全体に対するトランザクションをファンド口座単位に分割、再構成し、ファンド口座毎に個別のトランザクションの処理を実行することを意味する。
【0039】
さらに以下、一任資産一致管理部６１及び個別管理部６２の夫々について、その順番に個別に説明する。
【0040】
図１１は、図８のバーチャル口座管理部のうち一任資産一致管理部の説明をする図である。
図１１に示すように、一任資産一致管理部６１は、個社バックオフィスシステム２で発生した一任資産に関わる全てのトランザクションを取り込み、同等の処理を行なうことで、図１０のステップＳＡのトランザクションの共有を図る。
これにより、図１１に示すように、個社バックオフィスシステム２内の一任資産全体と、サービス提供者サーバ１（バーチャル口座管理部５１）内の一任資産全体との一致が得られる。その結果、個社バックオフィスシステム２は、必要な処理（例えば、譲渡益税計算等）の実施にあたり、ファンド口座内の区別を把握することは不要で、一任資産の合計を把握すれば十分となる。
なお、以下、個社バックオフィスシステムとサービス提供者サーバ１（バーチャル口座管理部５１）の一任資産全体の一致の状態を「一任資産レプリケーション」と呼ぶ。
即ち、一任資産一致管理部６１は、一任資産レプリケーションを維持する機能を有している。
図１１に示すように、一任資産一致管理部６１は、個社バックオフィスシステム２で発生した一任資産に関わる全てのトランザクションを取り込み、同等の処理を行なうことで、図１０のステップＳＡのトランザクションの共有を図る。
これにより、図１１に示すように、個社バックオフィスシステム２内の一任資産全体と、サービス提供者サーバ１（バーチャル口座管理部５１）内の一任資産全体との一致が得られる。その結果、個社バックオフィスシステム２は、必要な処理（例えば、譲渡益税計算等）の実施にあたり、ファンド口座内の区別を把握することは不要で、一任資産の合計を把握すれば十分となる。
なお、以下、個社バックオフィスシステムとサービス提供者サーバ１（バーチャル口座管理部５１）の一任資産全体の一致の状態を「一任資産レプリケーション」と呼ぶ。
即ち、一任資産一致管理部６１は、一任資産レプリケーションを維持する機能を有している。
【0041】
一方、個別管理部６２は、サービス提供者サーバ１（バーチャル口座管理部５１）内でのファンド口座の取り扱いを管理する機能を有する。
即ち、個別管理部６２は、一任資産一致管理部６１による一任資産レプリケーションを前提として、サービス提供者サーバ１（バーチャル口座管理部５１）内で一任資産をより細分化したファンド口座を取り扱う機能を有する。
即ち、個別管理部６２は、一任資産一致管理部６１による一任資産レプリケーションを前提として、サービス提供者サーバ１（バーチャル口座管理部５１）内で一任資産をより細分化したファンド口座を取り扱う機能を有する。
【0042】
ここで、サービス提供者サーバ１（バーチャル口座管理部５１）内で個社バックオフィスシステム２よりも詳細なファンド口座を取り扱うことができるように、個別管理部６２では、トランザクションの取り扱いが重要視されている。
即ち、運用サービスで発生するトランザクションは、大きく以下の３種類が存在する。
即ち、運用サービスで発生するトランザクションは、大きく以下の３種類が存在する。
【0043】
１種類目のトランザクションは、エンドユーザによるトランザクションである。
このトランザクションは、例えば、ユーザ注文（新規拠出、追加拠出、部分解約、全部解約、投資スタイル変更、積立入金等）に伴うものである。
この１種類目のトランザクションをサービス提供者サーバ１（バーチャル口座管理部５１）内で実行させる制御を行う機能ブロックが、エンドユーザトランザクション実行部７１である。
このトランザクションは、例えば、ユーザ注文（新規拠出、追加拠出、部分解約、全部解約、投資スタイル変更、積立入金等）に伴うものである。
この１種類目のトランザクションをサービス提供者サーバ１（バーチャル口座管理部５１）内で実行させる制御を行う機能ブロックが、エンドユーザトランザクション実行部７１である。
【0044】
２種類目のトランザクションは、個社バックオフィスシステム２が生成したトランザクションである。
この２種類目のトランザクションをサービス提供者サーバ１（バーチャル口座管理部５１）内で実行させる制御を行う機能ブロックが、バックオフィス発生トランザクション実行部７２である。
この２種類目のトランザクションをサービス提供者サーバ１（バーチャル口座管理部５１）内で実行させる制御を行う機能ブロックが、バックオフィス発生トランザクション実行部７２である。
【0045】
３種類目のトランザクションは、サービス提供者サーバ１（バーチャル口座管理部５１）が生成したトランザクション（例えば、リバランスに係るトランザクション）である。
このトランザクションは、例えば、執行注文とその約定（サービス提供者サーバ１－執行注文 ―＞ 個社バックオフィスシステム２－約定 －＞サービス提供者サーバ１）や、運用報酬徴収等に伴うものである。
また例えば、このトランザクションは、執行注文、即ち、投資対象の証券の買付、売付のためにサービス提供者サーバ１が生成する注文である。
この３種類目のトランザクションをサービス提供者サーバ１（バーチャル口座管理部５１）内で実行させる制御を行う機能ブロックが、自身生成トランザクション実行部７３である。
このトランザクションは、例えば、執行注文とその約定（サービス提供者サーバ１－執行注文 ―＞ 個社バックオフィスシステム２－約定 －＞サービス提供者サーバ１）や、運用報酬徴収等に伴うものである。
また例えば、このトランザクションは、執行注文、即ち、投資対象の証券の買付、売付のためにサービス提供者サーバ１が生成する注文である。
この３種類目のトランザクションをサービス提供者サーバ１（バーチャル口座管理部５１）内で実行させる制御を行う機能ブロックが、自身生成トランザクション実行部７３である。
【0046】
さらに以下、エンドユーザトランザクション実行部７１、及びバックオフィス発生トランザクション実行部７２の夫々について、その順番に個別に説明する。
【0047】
【0048】
運用サービスを提供するために、エンドユーザからの申込、搬出、解約等のトランザクションを、エンドユーザトランザクション実行部７１は受付ける必要がある。
この種のトランザクションに対しては、エンドユーザトランザクション実行部７１は、バーチャル口座コードの情報を付与して、連携する。
この種のトランザクションに対しては、エンドユーザトランザクション実行部７１は、バーチャル口座コードの情報を付与して、連携する。
【0049】
例えば、エンドユーザが運用サービスＡの新規申し込みをするものとする。この場合、次のような一連の処理を実行する。
先ず、エンドユーザが、エンドユーザ端末４を操作することで、例えば個社運用サーバ３により管理される個社運用サービスページにおいて、運用サービスＡの「新規申し込み」を押下したものとする。この場合、ファンド口座開設指示が出されて、バーチャル口座コードＡがサービス提供者サーバ１に連携される。ファンド口座開設指示には、エンドユーザの取引口座ＩＤが含まれる。
エンドユーザトランザクション実行部７１は、ファンド口座Ａ（運用サービスＡについてのバーチャル口座コードＡのバーチャル口座）を開設する。
以降はサブアカウント方式の場合かつ初回のみであるが、一任資産一致管理部６１は、個社バックオフィスシステム２とサブアカウント開設指示を連携させる処理を実行する。その結果、個社バックオフィスシステム２でサブアカウントが開設される。
先ず、エンドユーザが、エンドユーザ端末４を操作することで、例えば個社運用サーバ３により管理される個社運用サービスページにおいて、運用サービスＡの「新規申し込み」を押下したものとする。この場合、ファンド口座開設指示が出されて、バーチャル口座コードＡがサービス提供者サーバ１に連携される。ファンド口座開設指示には、エンドユーザの取引口座ＩＤが含まれる。
エンドユーザトランザクション実行部７１は、ファンド口座Ａ（運用サービスＡについてのバーチャル口座コードＡのバーチャル口座）を開設する。
以降はサブアカウント方式の場合かつ初回のみであるが、一任資産一致管理部６１は、個社バックオフィスシステム２とサブアカウント開設指示を連携させる処理を実行する。その結果、個社バックオフィスシステム２でサブアカウントが開設される。
【0050】
【0051】
次に、図１２に示す申し込みを完了した運用サービスＡに対して、エンドユーザが非一任資産を使った拠出を行なうものとする。
この場合、次のような一連の処理を実行する。
即ち、先ず、エンドユーザが、エンドユーザ端末４を操作することで、例えば個社運用サーバ３により管理される個社運用サービスページにおいて、運用サービスＡの「拠出」を実行したものとする。この場合、搬出指示が出されるので、バーチャル口座コードがサービス提供者サーバ１において連携される。拠出指示には拠出金額とともに取引口座ＩＤが含まれる。
一任資産一致管理部６１は、当該搬出指示を個社バックオフィスシステム２と連携させる制御を実行する。個社バックオフィスシステム ２においては、サブアカウント方式であれば振替の指示が、専用商品方式であれば現金相当資産の買付の指示がなされることになる。
個社バックオフィスシステム２は、拠出指示に従って、非一任資産から一任資産へ拠出する。
一任資産一致管理部６１は、個社バックオフィスシステム２からサービス提供者サーバ１へ拠出完了の連携を制御する。
エンドユーザトランザクション実行部７１は、ファンド口座Ａへの拠出処理を行う。
この場合、次のような一連の処理を実行する。
即ち、先ず、エンドユーザが、エンドユーザ端末４を操作することで、例えば個社運用サーバ３により管理される個社運用サービスページにおいて、運用サービスＡの「拠出」を実行したものとする。この場合、搬出指示が出されるので、バーチャル口座コードがサービス提供者サーバ１において連携される。拠出指示には拠出金額とともに取引口座ＩＤが含まれる。
一任資産一致管理部６１は、当該搬出指示を個社バックオフィスシステム２と連携させる制御を実行する。個社バックオフィスシステム ２においては、サブアカウント方式であれば振替の指示が、専用商品方式であれば現金相当資産の買付の指示がなされることになる。
個社バックオフィスシステム２は、拠出指示に従って、非一任資産から一任資産へ拠出する。
一任資産一致管理部６１は、個社バックオフィスシステム２からサービス提供者サーバ１へ拠出完了の連携を制御する。
エンドユーザトランザクション実行部７１は、ファンド口座Ａへの拠出処理を行う。
【0052】
【0053】
サービス提供者サーバ１では、金融機関個社が必要に応じて作成した任意のバーチャル口座コードに従ってファンド口座を開設することができる。
事前に定義のないバーチャル口座コードが連携された場合も同じ流れでファンド口座開設が可能である。ここで、「任意の数」とはシステムリソースなどのハードウェア的な制約を除き、原理的には無制限であることを指す。
そのため、金融機関個社のニーズに応じて任意の数のファンド口座の開設ができ、夫々のファンド口座で資産の区別管理を行なうことで「任意の数の同時運用」が可能となる。
即ち、先ず、エンドユーザが、エンドユーザ端末４を操作することで、例えば個社運用サーバ３により管理される個社運用サービスページにおいて、運用サービスＡとは異なる運用サービスＢの「新規申し込み」を押下したものとする。
この場合、ファンド口座開設指示が出されるので、バーチャル口座コードＢがサービス提供者サーバ１に連携される。ファンド口座開設指示には、エンドユーザの取引口座ＩＤが含まれる。
エンドユーザトランザクション実行部７１は、ファンド口座Ｂ（運用サービスＢについてのバーチャル口座コードＢのバーチャル口座）を開設する。
このように、２つ目以上のファンド口座開設時は、個社バックオフィスシステム２側はすでに開設済みのサブアカウントが共有されるため、新たなサブアカウント開設は必要ない。
事前に定義のないバーチャル口座コードが連携された場合も同じ流れでファンド口座開設が可能である。ここで、「任意の数」とはシステムリソースなどのハードウェア的な制約を除き、原理的には無制限であることを指す。
そのため、金融機関個社のニーズに応じて任意の数のファンド口座の開設ができ、夫々のファンド口座で資産の区別管理を行なうことで「任意の数の同時運用」が可能となる。
即ち、先ず、エンドユーザが、エンドユーザ端末４を操作することで、例えば個社運用サーバ３により管理される個社運用サービスページにおいて、運用サービスＡとは異なる運用サービスＢの「新規申し込み」を押下したものとする。
この場合、ファンド口座開設指示が出されるので、バーチャル口座コードＢがサービス提供者サーバ１に連携される。ファンド口座開設指示には、エンドユーザの取引口座ＩＤが含まれる。
エンドユーザトランザクション実行部７１は、ファンド口座Ｂ（運用サービスＢについてのバーチャル口座コードＢのバーチャル口座）を開設する。
このように、２つ目以上のファンド口座開設時は、個社バックオフィスシステム２側はすでに開設済みのサブアカウントが共有されるため、新たなサブアカウント開設は必要ない。
【0054】
以上、図８の個別管理部６２のうちエンドユーザトランザクション実行部７１について説明した。次に、個別管理部６２のうちバックオフィス発生トランザクション実行部７２について説明する。
図１５は、図８のバーチャル口座管理部の個別管理部のうち、バックオフィス発生トランザクション実行部の機能の一例を説明する図である。
図１５は、図８のバーチャル口座管理部の個別管理部のうち、バックオフィス発生トランザクション実行部の機能の一例を説明する図である。
【0055】
例えば、一任資産の残高および売買にともない、個社バックオフィスシステム２内でトランザクションが発生したものとする。
個社バックオフィスシステム２内で発生するトランザクションは例えば以下のものがあげられる。
１つ目のトランザクションは、一任資産で保有する証券の配当金または分配金（以下、「配当金／分配金」と呼ぶ）である。
２つ目のトランザクションは、売却益に対する譲渡益税源泉徴収である。
一任資産レプリケーションの状態を維持するためには、これらのトランザクションをサービス提供者サーバ１に取り込む必要がある。
しかしながら、個社バックオフィスシステム２は取引口座全体に対する処理を担うため、サービス提供者サーバ１が管理するファンド口座とは粒度が異なり、変換が必要となる。
このような変換を行い、ファンド口座を単位とするトランザクションを実行する機能ブロックが、バックオフィス発生トランザクション実行部７２である。
個社バックオフィスシステム２内で発生するトランザクションは例えば以下のものがあげられる。
１つ目のトランザクションは、一任資産で保有する証券の配当金または分配金（以下、「配当金／分配金」と呼ぶ）である。
２つ目のトランザクションは、売却益に対する譲渡益税源泉徴収である。
一任資産レプリケーションの状態を維持するためには、これらのトランザクションをサービス提供者サーバ１に取り込む必要がある。
しかしながら、個社バックオフィスシステム２は取引口座全体に対する処理を担うため、サービス提供者サーバ１が管理するファンド口座とは粒度が異なり、変換が必要となる。
このような変換を行い、ファンド口座を単位とするトランザクションを実行する機能ブロックが、バックオフィス発生トランザクション実行部７２である。
【0056】
例えば配当金／分配金の例であれば以下のような流れで処理が行われる。
ステップＳＣ１において、個社バックオフィスシステム２は、投資対象証券からの配当金、分配金情報を登録する。
ステップＳＣ２において、個社バックオフィスシステム２は、一任資産分の配当金／分配金を入金するトランザクション（以下手順では「配当金／分配金トランザクション」と呼ぶ）を作成する。ここで、配当金／分配金トランザクションに含まれる情報は、取引口座ＩＤ，証券ＩＤ，支払額，残高参照日，支払日，総権利保有数量等が存在する。
ステップＳＣ３において、個社バックオフィスシステム２は、一任資産に配当金／分配金トランザクションの処理を実行（適用）する。
ステップＳＣ４において、サービス提供者サーバ１の一任資産一致管理部６１は、サービス提供者サーバ１において配当金／分配金トランザクションを連携させる制御を実行する。
ステップＳＣ５において、バックオフィス発生トランザクション実行部７２は、配当金／分配金トランザクションと各ファンド口座の残高参照日の証券残高から、ファンド口座毎の支払額を算出する。算出の方法としては、例えば支払額を残高参照日における各ファンド口座の証券残高で按分する方法を採用することができる。
ステップＳＣ６において、バックオフィス発生トランザクション実行部７２は、各ファンド口座に入金する。
ステップＳＣ１において、個社バックオフィスシステム２は、投資対象証券からの配当金、分配金情報を登録する。
ステップＳＣ２において、個社バックオフィスシステム２は、一任資産分の配当金／分配金を入金するトランザクション（以下手順では「配当金／分配金トランザクション」と呼ぶ）を作成する。ここで、配当金／分配金トランザクションに含まれる情報は、取引口座ＩＤ，証券ＩＤ，支払額，残高参照日，支払日，総権利保有数量等が存在する。
ステップＳＣ３において、個社バックオフィスシステム２は、一任資産に配当金／分配金トランザクションの処理を実行（適用）する。
ステップＳＣ４において、サービス提供者サーバ１の一任資産一致管理部６１は、サービス提供者サーバ１において配当金／分配金トランザクションを連携させる制御を実行する。
ステップＳＣ５において、バックオフィス発生トランザクション実行部７２は、配当金／分配金トランザクションと各ファンド口座の残高参照日の証券残高から、ファンド口座毎の支払額を算出する。算出の方法としては、例えば支払額を残高参照日における各ファンド口座の証券残高で按分する方法を採用することができる。
ステップＳＣ６において、バックオフィス発生トランザクション実行部７２は、各ファンド口座に入金する。
【0057】
例えば譲渡益税の源泉徴収についても同様に、以下のような流れで処理が行われる。
ステップＳＤ１において、個社バックオフィスシステム２は、売却約定を登録する。
ステップＳＤ２において、個社バックオフィスシステム２は、売却損益と通算損益から譲渡益税の源泉徴収トランザクション（以下手順では「徴収トランザクション」と呼ぶ）を作成する。ここで、徴収トランザクションに含まれる情報は、取引口座ＩＤ、売却約定日、徴収／還付の別、精算額等が含まれる。
ステップＳＤ３において、個社バックオフィスシステム２は、一任資産に徴収トランザクションの処理を実行（適用）する。
ステップＳＤ４において、サービス提供者サーバ１の一任資産一致管理部６１は、サービス提供者サーバ１において徴収トランザクションを連携させる制御を実行する。
ステップＳＤ５において、バックオフィス発生トランザクション実行部７２は、徴収トランザクションと各ファンド口座の売却約定から、ファンド口座毎の精算額を算出する。精算額の算出の方法としては、各ファンド口座の売却約定代金で按分する等の方法を採用することができる。
ステップＳＤ６において、バックオフィス発生トランザクション実行部７２は、各ファンド口座から精算額を徴収／還付する。
ステップＳＤ１において、個社バックオフィスシステム２は、売却約定を登録する。
ステップＳＤ２において、個社バックオフィスシステム２は、売却損益と通算損益から譲渡益税の源泉徴収トランザクション（以下手順では「徴収トランザクション」と呼ぶ）を作成する。ここで、徴収トランザクションに含まれる情報は、取引口座ＩＤ、売却約定日、徴収／還付の別、精算額等が含まれる。
ステップＳＤ３において、個社バックオフィスシステム２は、一任資産に徴収トランザクションの処理を実行（適用）する。
ステップＳＤ４において、サービス提供者サーバ１の一任資産一致管理部６１は、サービス提供者サーバ１において徴収トランザクションを連携させる制御を実行する。
ステップＳＤ５において、バックオフィス発生トランザクション実行部７２は、徴収トランザクションと各ファンド口座の売却約定から、ファンド口座毎の精算額を算出する。精算額の算出の方法としては、各ファンド口座の売却約定代金で按分する等の方法を採用することができる。
ステップＳＤ６において、バックオフィス発生トランザクション実行部７２は、各ファンド口座から精算額を徴収／還付する。
【0058】
上述の配当金／分配金と譲渡益税の源泉徴収の流れの通り、以下の２点が重要である。
１点目の重要な点は、一任資産に対するトランザクションがサービス提供者サーバ１に連携される点である。
２点目の重要な点は、サービス提供者サーバ１において保有するファンド口座毎のデータで按分可能である点である。
この２点が満たされることで、任意の数のファンド口座が存在したとしても、個社バックオフィスシステム２で発生したトランザクションを、サービス提供者サーバ１内で管理するファンド口座レベルのトランザクションへの適切な変換が可能となる。
１点目の重要な点は、一任資産に対するトランザクションがサービス提供者サーバ１に連携される点である。
２点目の重要な点は、サービス提供者サーバ１において保有するファンド口座毎のデータで按分可能である点である。
この２点が満たされることで、任意の数のファンド口座が存在したとしても、個社バックオフィスシステム２で発生したトランザクションを、サービス提供者サーバ１内で管理するファンド口座レベルのトランザクションへの適切な変換が可能となる。
【0059】
以上まとめると、第１実施形態のサービス提供者サーバ１は、個社バックオフィスシステム２と通信をする。この個社バックオフィスシステム２は、エンドユーザの取引口座において、一任資産と非一任資産とを区別管理する。
この場合、サービス提供者サーバ１のバーチャル口座管理部５１は、一任資産の枠内で運営されるＮ個（Ｎは、１以上の整数値）の運営サービスの夫々に対して、サービス提供者サーバ１内における一任資産がＮ個に区分された結果得られるＮ個のバーチャル口座（ファンド口座）の夫々を対応付けて、当該Ｎ個のバーチャル口座を管理する。
この場合、サービス提供者サーバ１のバーチャル口座管理部５１は、一任資産の枠内で運営されるＮ個（Ｎは、１以上の整数値）の運営サービスの夫々に対して、サービス提供者サーバ１内における一任資産がＮ個に区分された結果得られるＮ個のバーチャル口座（ファンド口座）の夫々を対応付けて、当該Ｎ個のバーチャル口座を管理する。
【0060】
バーチャル口座管理部５１は、一任資産一致管理部６１と、個別管理部６２とを有する。
一任資産一致管理部６１は、個社バックオフィスシステム２で発生したエンドユーザの一任資産に関わる全てのトランザクションの処理を実行することで、個社バックオフィスシステム２内の一任資産とサービス提供者サーバ１内の一任資産の一致の状態を維持するように管理する。
個別管理部６２は、上述の一致の状態を前提として、Ｎ個の運用サービス毎に、夫々対応付けられたバーチャル口座を用いたトランザクションの処理を実行することで、Ｎ個のバーチャル口座を管理する。
一任資産一致管理部６１は、個社バックオフィスシステム２で発生したエンドユーザの一任資産に関わる全てのトランザクションの処理を実行することで、個社バックオフィスシステム２内の一任資産とサービス提供者サーバ１内の一任資産の一致の状態を維持するように管理する。
個別管理部６２は、上述の一致の状態を前提として、Ｎ個の運用サービス毎に、夫々対応付けられたバーチャル口座を用いたトランザクションの処理を実行することで、Ｎ個のバーチャル口座を管理する。
【0061】
個別管理部６２は、エンドユーザトランザクション実行部７１と、バックオフィス発生トランザクション実行部７２と自身生成トランザクション実行部７３とを有する。
エンドユーザトランザクション実行部７１は、Ｎ個の運用サービスのうち所定運用サービスについてのトランザクションの処理として、エンドユーザの操作に基づくトランザクションの処理を実行する。
バックオフィス発生トランザクション実行部７２は、所定運用サービスについてのトランザクションの処理として、個社バックオフィスシステム２で発生したトランザクションのうち所定運用サービスに係るトランザクションの処理を実行する。
エンドユーザトランザクション実行部７１は、Ｎ個の運用サービスのうち所定運用サービスについてのトランザクションの処理として、エンドユーザの操作に基づくトランザクションの処理を実行する。
バックオフィス発生トランザクション実行部７２は、所定運用サービスについてのトランザクションの処理として、個社バックオフィスシステム２で発生したトランザクションのうち所定運用サービスに係るトランザクションの処理を実行する。
【0062】
このような構成の第１実施形態のサービス提供者サーバ１は、いかに示す各種各様な効果を奏することが可能である。
即ち、第１実施形態のサービス提供者サーバ１の適用により、任意の数のファンド口座開設と運用サービスの紐付けが可能になる。
即ち、第１実施形態のサービス提供者サーバ１の適用により、任意の数のファンド口座開設と運用サービスの紐付けが可能になる。
【0063】
具体的には例えば、図１６に示すように、第１実施形態のサービス提供者サーバ１の適用により、例えば本格的なゴールベース運用の提供が考えられる。
図１６は、第１実施形態のサービス提供者サーバ１が奏することが可能な効果の具体例として、本格的なゴールベース運用の提供の例を示す図である。
図１６は、第１実施形態のサービス提供者サーバ１が奏することが可能な効果の具体例として、本格的なゴールベース運用の提供の例を示す図である。
【0064】
即ち、エンドユーザＭは、エンドユーザ端末４を操作することで、画面Ｇ１において、新しいゴールの登録を開始する。
エンドユーザＭは、エンドユーザ端末４を操作することで、画面Ｇ２において、ゴール名、期間、運用開始額とともに、運用を一任する運用サービスを選択して申し込みをする。
金融機関個社Ｋ（個社運用サーバ３により管理される個社運用サービスページ）は、申し込みと同時にバーチャル口座コードを発行し、サービス提供者サーバ１に対してファンド口座開設指示及びバーチャル口座コードを連携させる。
サービス提供者サーバ１は、指示を受けて、ファンド口座を開設する。
エンドユーザＭと投資運用業者Ｔとの間とで投資一任契約が締結される。
個社バックオフィスシステム２は、取引口座の非一任資産から一任資産へ現金を振替える。
サービス提供者サーバ１は、ファンド口座に新規拠出注文を登録する。
これにより、投資運用業者Ｔがファンド口座の資産の運用を開始することができる。即ち、エンドユーザ端末４には画面Ｇ３が表示される。
エンドユーザＭは、エンドユーザ端末４を操作することで、画面Ｇ２において、ゴール名、期間、運用開始額とともに、運用を一任する運用サービスを選択して申し込みをする。
金融機関個社Ｋ（個社運用サーバ３により管理される個社運用サービスページ）は、申し込みと同時にバーチャル口座コードを発行し、サービス提供者サーバ１に対してファンド口座開設指示及びバーチャル口座コードを連携させる。
サービス提供者サーバ１は、指示を受けて、ファンド口座を開設する。
エンドユーザＭと投資運用業者Ｔとの間とで投資一任契約が締結される。
個社バックオフィスシステム２は、取引口座の非一任資産から一任資産へ現金を振替える。
サービス提供者サーバ１は、ファンド口座に新規拠出注文を登録する。
これにより、投資運用業者Ｔがファンド口座の資産の運用を開始することができる。即ち、エンドユーザ端末４には画面Ｇ３が表示される。
【0065】
【0066】
即ち、例示するシナリオとして、あるエンドユーザがすでに３つのファンド口座（老後資金、教育費積立（長男）、海外旅行積立２０２１年）を運用している状況において、新たに２０２２年の海外旅行用積立を一任運用ではじめるケースを想定する。
【0067】
このときの流れは以下のようになる。
ステップＳＥ１において、エンドユーザは、エンドユーザ端末４の操作により、複数ある運用サービスから一つを選択して、新たな積立運用を申し込みする。
ステップＳＥ２において、個社運用サーバ３は、申し込みを行うと、新たな運用向けにバーチャル口座コードＤを付与し、サービス提供者サーバ１にファンド口座開設指示を行う。
ステップＳＥ３において、サービス提供者サーバ１は、個社バックオフィスシステム２に運用開始額の拠出指示を行う。拠出指示を受けた個社バックオフィスシステム２は、非一任資産から一任資産へ拠出金額の資金振替を行う。
ステップＳＥ４において、拠出完了後にサービス提供者サーバ１は、バーチャル口座コードＤに紐づく新たなファンド口座を開設し、運用を開始する。
ステップＳＥ１において、エンドユーザは、エンドユーザ端末４の操作により、複数ある運用サービスから一つを選択して、新たな積立運用を申し込みする。
ステップＳＥ２において、個社運用サーバ３は、申し込みを行うと、新たな運用向けにバーチャル口座コードＤを付与し、サービス提供者サーバ１にファンド口座開設指示を行う。
ステップＳＥ３において、サービス提供者サーバ１は、個社バックオフィスシステム２に運用開始額の拠出指示を行う。拠出指示を受けた個社バックオフィスシステム２は、非一任資産から一任資産へ拠出金額の資金振替を行う。
ステップＳＥ４において、拠出完了後にサービス提供者サーバ１は、バーチャル口座コードＤに紐づく新たなファンド口座を開設し、運用を開始する。
【0068】
また例えば、第１実施形態のサービス提供者サーバ１の適用により、開発難易度およびそれに起因するコストの低減が可能になる。
従来手法の課題で述べた通り、従来は単一のシステムで粒度の異なる処理を実装することの困難さが存在していた。
第１実施形態のサービス提供者サーバ１の適用により、取引口座全体のデータ処理を個社バックオフィスシステム２が担当し、ファンド口座へのデータ配布をサービス提供者サーバ１が担当することが可能になる。
第１実施形態のサービス提供者サーバ１を適用することで、以下の２点から、従来手法と比較して開発の難易度が低減されていると言え、コスト面での優位性が認められる。
１点目は、取引口座とファンド口座という対象の粒度（階層）違いでシステムが分割されている点である。
２点目は、個社バックオフィスシステム２にて、運用サービスを個別に（例えば１つのみ）運用する機能が活用可能である（再利用性の向上）点である。
従来手法の課題で述べた通り、従来は単一のシステムで粒度の異なる処理を実装することの困難さが存在していた。
第１実施形態のサービス提供者サーバ１の適用により、取引口座全体のデータ処理を個社バックオフィスシステム２が担当し、ファンド口座へのデータ配布をサービス提供者サーバ１が担当することが可能になる。
第１実施形態のサービス提供者サーバ１を適用することで、以下の２点から、従来手法と比較して開発の難易度が低減されていると言え、コスト面での優位性が認められる。
１点目は、取引口座とファンド口座という対象の粒度（階層）違いでシステムが分割されている点である。
２点目は、個社バックオフィスシステム２にて、運用サービスを個別に（例えば１つのみ）運用する機能が活用可能である（再利用性の向上）点である。
【0069】
本発明が適用される情報処理装置は、第１実施形態のサービス提供者サーバ１に特に限定されず、各種各様な実施の形態を取ることが可能になる。
具体的には例えば、本発明が適用される情報処理装置として、
所定対象を管理する管理者の装置のうち、所定対象が管理される管理単位において、第１種管理単位と第２種管理単位とを区別管理している別情報処理装置と少なくとも通信をする情報処理装置であって、
前記第１種管理単位の枠内で運営されるＮ個（Ｎは、１以上の整数値）のサービスの夫々に対して、前記情報処理装置内における前記第１種管理単位が前記Ｎ個に区分された結果得られる前記Ｎ個の個別単位の夫々を対応付けて、当該Ｎ個の当該個別単位を管理する処理を実行する個別単位管理手段
を備える情報処理装置を採用することができる。
具体的には例えば、本発明が適用される情報処理装置として、
所定対象を管理する管理者の装置のうち、所定対象が管理される管理単位において、第１種管理単位と第２種管理単位とを区別管理している別情報処理装置と少なくとも通信をする情報処理装置であって、
前記第１種管理単位の枠内で運営されるＮ個（Ｎは、１以上の整数値）のサービスの夫々に対して、前記情報処理装置内における前記第１種管理単位が前記Ｎ個に区分された結果得られる前記Ｎ個の個別単位の夫々を対応付けて、当該Ｎ個の当該個別単位を管理する処理を実行する個別単位管理手段
を備える情報処理装置を採用することができる。
【0070】
ここで、第１実施形態のサービス提供者サーバ１に対応付けるならば、
前記所定対象は資産であり、
前記管理単位は、エンドユーザの取引口座であり、
前記第１種管理単位は、前記エンドユーザの一任資産であり、
前記第２種管理単位は、エンドユーザの非一任資産であり、
前記サービスは、運用サービスであり、
前記個別単位は、バーチャル口座である。
前記所定対象は資産であり、
前記管理単位は、エンドユーザの取引口座であり、
前記第１種管理単位は、前記エンドユーザの一任資産であり、
前記第２種管理単位は、エンドユーザの非一任資産であり、
前記サービスは、運用サービスであり、
前記個別単位は、バーチャル口座である。
【0071】
ただし、繰り返しになるが、このような構成の情報処理装置は、第１実施形態のサービス提供者サーバ１に特に限定されない。
即ち、このような構成の情報処理装置の実施形態を適宜変更することで、例えば次のような適用範囲の拡張が考えられる。
例えば、非一任資産の資産マイグレーションにより、証券口座全体のバーチャル口座導入が可能である。
例えば、第１実施形態のサービス提供者サーバ１についても、投資委任契約の有無を必須としておらず、この点は他の実施形態でも同様である。
したがって、例えば一任資産レプリケーションを拡張して取引口座レプリケーションを維持することで、取引口座への拡張が可能となる。
例えば、取引口座レプリケーションとしては、一任資産のトランザクションのみならず、取引口座全体のトランザクションをサービス提供者サーバ１に連携して処理することもできる。
例えば、証券以外の資産への拡張もできる。
例えば、第１実施形態のサービス提供者サーバ１についても、トランザクションはその種類を限定しておらず、この点は他の実施形態でも同様である。
したがって、例えばトランザクションを現金やセキュリティトークン、暗号資産などへの拡張が考えられる。
即ち、このような構成の情報処理装置の実施形態を適宜変更することで、例えば次のような適用範囲の拡張が考えられる。
例えば、非一任資産の資産マイグレーションにより、証券口座全体のバーチャル口座導入が可能である。
例えば、第１実施形態のサービス提供者サーバ１についても、投資委任契約の有無を必須としておらず、この点は他の実施形態でも同様である。
したがって、例えば一任資産レプリケーションを拡張して取引口座レプリケーションを維持することで、取引口座への拡張が可能となる。
例えば、取引口座レプリケーションとしては、一任資産のトランザクションのみならず、取引口座全体のトランザクションをサービス提供者サーバ１に連携して処理することもできる。
例えば、証券以外の資産への拡張もできる。
例えば、第１実施形態のサービス提供者サーバ１についても、トランザクションはその種類を限定しておらず、この点は他の実施形態でも同様である。
したがって、例えばトランザクションを現金やセキュリティトークン、暗号資産などへの拡張が考えられる。
【0072】
［第２実施形態］
次に、本発明の第２実施形態について図面を用いて説明する。
次に、本発明の第２実施形態について図面を用いて説明する。
【0073】
先ず、本発明の第２実施形態について説明する前に、従来手法とその課題について説明する。
【0074】
図１８は、本発明の第２実施形態と比較するための従来の手法を、サブアカウント方式を例として説明する図である。
【0075】
資産運用として広く利用されている投資信託は、数多くの投資信託委託会社が関与し、用途に合わせて組成を行なっている。
一方で従来の運用サービスへの投資運用業者Ｔとしての参加は基本１社による提供がほとんどである。
これはエンドユーザから見ると、口座と運用サービスがバンドリングされた状態（以下、「バンドリング」と呼ぶ）である。
このバンドリングのため、選択圧が発生せず、コストの低減や運用力の向上といったサービスの進化が促されにくい状況となっている。
第１実施形態で述べた通り、自社口座を使った運用サービスの提供は現状数の制約がある。
以下は、図１８に示す第１実施形態で述べた従来手法のサブアカウント方式をベースに記載する。
限られた枠であることから、複数の投資運用業者Ｔを組み入れるインセンティブが乏しく既存サービスが存在していない。
インセンティブが乏しい理由の１つは、サブアカウント追加開設のコストが大きいことである。
サブアカウント追加開設のコストが高いため、経済合理性の維持のために金融機関個社自身またはグループ会社が投資運用業者となるケースが多い。
一方で従来の運用サービスへの投資運用業者Ｔとしての参加は基本１社による提供がほとんどである。
これはエンドユーザから見ると、口座と運用サービスがバンドリングされた状態（以下、「バンドリング」と呼ぶ）である。
このバンドリングのため、選択圧が発生せず、コストの低減や運用力の向上といったサービスの進化が促されにくい状況となっている。
第１実施形態で述べた通り、自社口座を使った運用サービスの提供は現状数の制約がある。
以下は、図１８に示す第１実施形態で述べた従来手法のサブアカウント方式をベースに記載する。
限られた枠であることから、複数の投資運用業者Ｔを組み入れるインセンティブが乏しく既存サービスが存在していない。
インセンティブが乏しい理由の１つは、サブアカウント追加開設のコストが大きいことである。
サブアカウント追加開設のコストが高いため、経済合理性の維持のために金融機関個社自身またはグループ会社が投資運用業者となるケースが多い。
【0076】
【0077】
それ以外には、図１９に示すように、システム提供業者またはそのグループ会社が投資運用業者Ｔ１，Ｔ２となるケースがある。
このケースはシステム提供業者がサブアカウント追加開設コストを負担することで、金融機関個社ＫＡ，ＫＢへの負担が発生しないことがあり得る。
しかしながら、負担回収の主体がシステム提供業者に変わっただけで、本質的なインセンティブ構造は同じである。
インセンティブが乏しい理由の２つめは、新しい投資運用業者Ｔ１，Ｔ２の組み入れコストが発生することである。
従来手法では、金融機関個社が投資運用業者と直接接続するケースがほとんどである。
例えば、投資運用業者Ｔ１と投資運用業者Ｔ２が金融機関個社ＫＡと金融機関個社ＫＢに運用サービスを提供しようとすると、金融機関個社ＫＡ－投資運用業者Ｔ１，金融機関個社ＫＢ－投資運用業者Ｔ１，金融機関個社ＫＡ－投資運用業者Ｔ２，金融機関個社ＫＢ－投資運用業者Ｔ２の４つの接続が必要となる。
これは金融機関個社ＫＡ，ＫＢ、投資運用業者Ｔ１，Ｔ２の数が増えると、掛け算で接続が増えることを意味し、その接続のコストがバンドリング排除の障害の一つとなっている。
このケースはシステム提供業者がサブアカウント追加開設コストを負担することで、金融機関個社ＫＡ，ＫＢへの負担が発生しないことがあり得る。
しかしながら、負担回収の主体がシステム提供業者に変わっただけで、本質的なインセンティブ構造は同じである。
インセンティブが乏しい理由の２つめは、新しい投資運用業者Ｔ１，Ｔ２の組み入れコストが発生することである。
従来手法では、金融機関個社が投資運用業者と直接接続するケースがほとんどである。
例えば、投資運用業者Ｔ１と投資運用業者Ｔ２が金融機関個社ＫＡと金融機関個社ＫＢに運用サービスを提供しようとすると、金融機関個社ＫＡ－投資運用業者Ｔ１，金融機関個社ＫＢ－投資運用業者Ｔ１，金融機関個社ＫＡ－投資運用業者Ｔ２，金融機関個社ＫＢ－投資運用業者Ｔ２の４つの接続が必要となる。
これは金融機関個社ＫＡ，ＫＢ、投資運用業者Ｔ１，Ｔ２の数が増えると、掛け算で接続が増えることを意味し、その接続のコストがバンドリング排除の障害の一つとなっている。
【0078】
図２０は、本発明の第２実施形態と比較するための従来の手法の課題として、媒介送客の課題について説明する図である。
【0079】
バンドリングの課題を解消する方法として媒介送客がある。
媒介送客とは、例えば運用サービスを実施している金融機関個社ＫＡが、運用サービスを行なっている別の金融機関個社ＫＢにエンドユーザＭを紹介する方式を指す。
媒介送客であっても、以下の第１乃至第３のハードルが存在する。
第１のハードルとは、送客元の金融機関個社ＫＡにおける預り残高流出（資産流出）の忌避というハードルである。
第２のハードルとは、送客先との接続コストというハードルである。
第３のハードルとは、（自社サービスを含めた）もっとも利益率の高い運用サービスを推奨するバイアスがあるというハードルである。
このような第１乃至第３のハードルがあるという理由から、媒介送客でバンドリングの課題を一部解決するものの十分とは言えない。
媒介送客とは、例えば運用サービスを実施している金融機関個社ＫＡが、運用サービスを行なっている別の金融機関個社ＫＢにエンドユーザＭを紹介する方式を指す。
媒介送客であっても、以下の第１乃至第３のハードルが存在する。
第１のハードルとは、送客元の金融機関個社ＫＡにおける預り残高流出（資産流出）の忌避というハードルである。
第２のハードルとは、送客先との接続コストというハードルである。
第３のハードルとは、（自社サービスを含めた）もっとも利益率の高い運用サービスを推奨するバイアスがあるというハードルである。
このような第１乃至第３のハードルがあるという理由から、媒介送客でバンドリングの課題を一部解決するものの十分とは言えない。
【0080】
次に、上述の従来手法が有する課題を解決可能な、本発明の第２実施形態について説明する。
【0081】
図２１は、本発明の第２実施形態のサービス提供者サーバを含む情報処理システムの構成を示す図である。
【0082】
図２１に示す情報処理システムは、サービス提供者により管理されるサービス提供者サーバ１と、ｐ（ｐは１以上の整数値）の金融機関個社Ｋ１乃至Ｋｐの夫々により管理される個社バックオフィスシステム２－１乃至２－ｐ及び個社運用サーバ３－１乃至３－ｋと、ｑ（ｑは１以上の整数値）のエンドユーザＭ１乃至Ｍｑの夫々により管理されるエンドユーザ端末４－１乃至４－ｑと、ｒ（ｒは１以上の整数値）の投資運用業者Ｔ１乃至Ｔｒの夫々により管理される投資運用業者端末５－１乃至５－ｒとを含むように構成されている。
【0083】
なお、以下、金融機関個社Ｋ１乃至Ｋｐを個々に区別する必要ない場合、これらをまとめて、「金融機関個社Ｋ」と呼ぶ。また、金融機関個社Ｋと呼んでいる場合、個社バックオフィスシステム ２－１乃至２－ｐをまとめて「個社バックオフィスシステム ２」と呼び、個社運用サーバ３－１乃至３－ｋをまとめて「個社運用サーバ３」と呼ぶ。
また、エンドユーザＭ１乃至Ｍｑを個々に区別する必要ない場合、これらをまとめて、「エンドユーザＭ」と呼ぶ。また、エンドユーザＭと呼んでいる場合、エンドユーザ端末４－１乃至４－ｑをまとめて「エンドユーザ端末４」と呼ぶ。
また、投資運用業者Ｔ１乃至Ｔｒを個々に区別する必要ない場合、これらをまとめて「投資運用業者Ｔ」と呼ぶ。また、投資運用業者Ｔと呼んでいる場合、投資運用業者端末５－１乃至５－ｒをまとめて、「投資運用業者端末５」と呼ぶ。
また、エンドユーザＭ１乃至Ｍｑを個々に区別する必要ない場合、これらをまとめて、「エンドユーザＭ」と呼ぶ。また、エンドユーザＭと呼んでいる場合、エンドユーザ端末４－１乃至４－ｑをまとめて「エンドユーザ端末４」と呼ぶ。
また、投資運用業者Ｔ１乃至Ｔｒを個々に区別する必要ない場合、これらをまとめて「投資運用業者Ｔ」と呼ぶ。また、投資運用業者Ｔと呼んでいる場合、投資運用業者端末５－１乃至５－ｒをまとめて、「投資運用業者端末５」と呼ぶ。
【0084】
サービス提供者サーバ１、個社バックオフィスシステム ２及び個社運用サーバ３と、エンドユーザ端末４、並びに投資運用業者端末５は、所定のネットワークＮを介して相互に接続されている。なお、ネットワークＮは、本実施形態ではインターネットとされるが、その形態は特に限定されず、その他例えば、Ｂｌｕｅｔｏｏｔｈ（登録商標）、Ｗｉ－Ｆｉ、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）等を採用することができる。
【0085】
なお、図示はしないが、第２実施形態の図２１の情報処理システムのうち、サービス提供者サーバ１、個社バックオフィスシステム２、個社運用サーバ３、エンドユーザ端末４、及び投資運用業者端末５も、第１実施形態の図７のサービス提供者サーバ１に示すハードウェア構成を有している。
【0086】
次に、図２２を参照して、図７に示すハードウェア構成を有する第２実施形態のサービス提供者サーバ１の機能的構成について説明する。
図２２は、本発明の情報処理装置の第２実施形態に係る図７に示すサービス提供者サーバの機能的構成の一例を示す機能ブロック図である。
図２２は、本発明の情報処理装置の第２実施形態に係る図７に示すサービス提供者サーバの機能的構成の一例を示す機能ブロック図である。
【0087】
サービス提供者サーバ１のＣＰＵ１１においては、図２２に示すように、バーチャル口座管理部５１が設けられている。
第２実施形態のバーチャル口座管理部５１には、第１実施形態と同様の一任資産一致管理部６１、個別管理部６２、及びユーザインタフェース制御部６３に加えてさらに、アクセス制御部６４と、エンドユーザ管理部６５と、運用サービス管理部６６と、投資運用業者管理部６７とが設けられている。
また、サービス提供者サーバ１の記憶部１８には、エンドユーザＤＢ８１、運用サービスＤＢ８２、及び投資運用業者ＤＢ８３が設けられている。
第２実施形態のバーチャル口座管理部５１には、第１実施形態と同様の一任資産一致管理部６１、個別管理部６２、及びユーザインタフェース制御部６３に加えてさらに、アクセス制御部６４と、エンドユーザ管理部６５と、運用サービス管理部６６と、投資運用業者管理部６７とが設けられている。
また、サービス提供者サーバ１の記憶部１８には、エンドユーザＤＢ８１、運用サービスＤＢ８２、及び投資運用業者ＤＢ８３が設けられている。
【0088】
ここで、上述の図１８乃至図２０を参照して説明した従来手法の課題を解決するための、本発明の第２実施形態の基本方針は次の方針１及び方針２である。
基本方針１とは、複数の金融機関個社（図２０の例に対応させると金融機関個社ＫＡ，ＫＢ）が複数の運用サービスの同時運用を安価に実現できるという方針である。
基本方針２とは、複数の投資運用業者（図２０の例に対応させると投資運用業者Ｔ１，Ｔ２）との接続を共通化し、これらの複数の投資運用業者が安価に組み込めるという方針である。
基本方針１の同時運用は、第１実施形態で実現可能になった取引口座への任意の数のバーチャル口座の手法をそのまま適用すればよい。このため、第２実施形態のサービス提供者サーバ１は、原則として第１実施形態のサービス提供者サーバ１が有する機能的構成、即ち第１実施形態と同様の一任資産一致管理部６１、個別管理部６２、及びユーザインタフェース制御部６３をそのまま有している。
そこで、以下の説明では、基本方針２を実現させるための機能的構成として、適宜図２３乃至図３０を参照しながら、第１実施形態との差分である、アクセス制御部６４と、エンドユーザ管理部６５と、運用サービス管理部６６と、投資運用業者管理部６７とについて説明する。
基本方針１とは、複数の金融機関個社（図２０の例に対応させると金融機関個社ＫＡ，ＫＢ）が複数の運用サービスの同時運用を安価に実現できるという方針である。
基本方針２とは、複数の投資運用業者（図２０の例に対応させると投資運用業者Ｔ１，Ｔ２）との接続を共通化し、これらの複数の投資運用業者が安価に組み込めるという方針である。
基本方針１の同時運用は、第１実施形態で実現可能になった取引口座への任意の数のバーチャル口座の手法をそのまま適用すればよい。このため、第２実施形態のサービス提供者サーバ１は、原則として第１実施形態のサービス提供者サーバ１が有する機能的構成、即ち第１実施形態と同様の一任資産一致管理部６１、個別管理部６２、及びユーザインタフェース制御部６３をそのまま有している。
そこで、以下の説明では、基本方針２を実現させるための機能的構成として、適宜図２３乃至図３０を参照しながら、第１実施形態との差分である、アクセス制御部６４と、エンドユーザ管理部６５と、運用サービス管理部６６と、投資運用業者管理部６７とについて説明する。
【0089】
先ず、基本方針２を実現するためには、エンドユーザＭと投資運用業者との間の投資一任契約が前提となる。そこで、投資運用業者との投資一任契約について、契約状態の管理、申込及び解約について、図２３乃至図２５を参照して説明する。
【0090】
図２３は、投資運用業者が運用する運用サービスについての投資一任契約の契約状態の管理手法の概要を示す図である。
【0091】
前提として、運用サービス毎に投資一任契約がなされる。この投資一任契約は、エンドユーザＭと投資運用業者Ｔとの間で締結されるものである。
ただし、金融機関個社Ｋが有価証券の預かりや買い付けや売りつけを行なうことから、投資一任契約の書面は連名で作成されるケースがある。
投資一任契約は、運用サービス毎に「投資一任契約書面テンプレートセット」（以下、「テンプレートセット」と呼ぶ）として管理される。
複数の投資一任契約を実現するために、図２３に示すように、サービス提供者サーバ１のバーチャル口座管理部５１は、投資一任契約を構成するテンプレートセットを管理サービス毎に区別して、管理画面やＡＰＩを通して、投資運用業者Ｔがテンプレートセットの管理を行なえるようにしている。
ただし、金融機関個社Ｋが有価証券の預かりや買い付けや売りつけを行なうことから、投資一任契約の書面は連名で作成されるケースがある。
投資一任契約は、運用サービス毎に「投資一任契約書面テンプレートセット」（以下、「テンプレートセット」と呼ぶ）として管理される。
複数の投資一任契約を実現するために、図２３に示すように、サービス提供者サーバ１のバーチャル口座管理部５１は、投資一任契約を構成するテンプレートセットを管理サービス毎に区別して、管理画面やＡＰＩを通して、投資運用業者Ｔがテンプレートセットの管理を行なえるようにしている。
【0092】
図２３のような投資一任契約の契約状態の管理手法を実現するために機能する機能ブロックは、運用サービス管理部６６とユーザインタフェース制御部６３である。
運用サービス管理部６６は、所定運用サービスについてのエンドユーザＭと投資運用業者Ｔとの投資一任契約についてのテンプレートセットを含む当該所定運用サービスに紐づくデータを運用サービスデータとして管理する。なお、テンプレートセット以外の運用サービスデータについては後述する。運用サービスデータは、複数の運用サービス毎に運用サービスＤＢ８２に格納される。
具体的には例えば、運用サービス管理部６６は、当該運用サービスデータ（図２３の例ではテンプレートセットのみ図示）と、当該所定運用サービスを識別可能な運用サービスＩＤと、当該所定運用サービス（それと対応付けられたとファンド口座）とを紐付けて、Ｎ個の運用サービス（図２３の例では３個の運用サービスＡ，Ｂ，Ｃ）毎に管理する。
ユーザインタフェース制御部６３は、所定運用サービスの投資一任契約の締結時、契約中、又は解約時における、エンドユーザＭ又は投資運用業者Ｔが利用するユーザインタフェース（図２３の例では管理画面やＡＰＩ）を、エンドユーザ端末４又は投資運用業者端末５に対して提供する。
運用サービス管理部６６は、所定運用サービスについてのエンドユーザＭと投資運用業者Ｔとの投資一任契約についてのテンプレートセットを含む当該所定運用サービスに紐づくデータを運用サービスデータとして管理する。なお、テンプレートセット以外の運用サービスデータについては後述する。運用サービスデータは、複数の運用サービス毎に運用サービスＤＢ８２に格納される。
具体的には例えば、運用サービス管理部６６は、当該運用サービスデータ（図２３の例ではテンプレートセットのみ図示）と、当該所定運用サービスを識別可能な運用サービスＩＤと、当該所定運用サービス（それと対応付けられたとファンド口座）とを紐付けて、Ｎ個の運用サービス（図２３の例では３個の運用サービスＡ，Ｂ，Ｃ）毎に管理する。
ユーザインタフェース制御部６３は、所定運用サービスの投資一任契約の締結時、契約中、又は解約時における、エンドユーザＭ又は投資運用業者Ｔが利用するユーザインタフェース（図２３の例では管理画面やＡＰＩ）を、エンドユーザ端末４又は投資運用業者端末５に対して提供する。
【0093】
次に、エンドユーザＭによる、投資運用業者Ｔとの投資一任契約の申込みの流れについて説明する。
図２４は、エンドユーザによる、投資運用業者との投資一任契約の申込みの流れの概要を示す図である。
図２４は、エンドユーザによる、投資運用業者との投資一任契約の申込みの流れの概要を示す図である。
【0094】
サービス提供者サーバ１のバーチャル口座管理部５１は、投資一任契約の契約状態の管理については、ファンド口座と運用サービスの組み合わせ毎に実施する。
例えば契約申込みの流れは以下の通りである。
即ち、ステップＳＦ１において、エンドユーザＭは、エンドユーザ端末４を操作して、金融機関個社Ｋ（個社運用サーバ３により管理される個社運用サービスページ）において、運用サービスを導入したいファンド口座を選択する。
なお、以下、エンドユーザＭが、エンドユーザ端末４を操作して、金融機関個社Ｋ（個社運用サーバ３により管理される個社運用サービスページ）において所定行為を行うことを、単に、「エンドユーザＭが、所定行為を行う」と略記する。
ステップＳＦ２において、エンドユーザＭは、ファンド口座の運用を一任する運用サービスを選択する。
ステップＳＦ３において、エンドユーザＭは、運用サービスを申込む。その際に、契約締結前交付書面等の確認と同意がなされる。
ステップＳＦ４において、サービス提供１の運用サービス管理部６６は、投資一任契約を申し込み中として運用サービスＤＢ８２に登録する。
ステップＳＦ５において、投資運用業者Ｔは、投資運用業者端末５を操作することで、申し込み中の投資一任契約（データセット等の運用サービスデータ）を全て取得する。
ステップＳＦ６において、投資運用業者Ｔが、投資運用業者端末５を操作することで、申込みを承諾する。
ステップＳＦ７において、サービス提供者サーバ１の運用サービス管理部６６は、申し込み承諾を受けて、投資一任契約（データセット等の運用サービスデータ）を締結済みとして運用サービスＤＢ８２に登録する。
ステップＳＦ８において、サービス提供者サーバ１の一任資産一致管理部６１は、金融機関個社Ｋの個社バックオフィスシステム２へ締結情報を連携させる制御を実行する。
ステップＳＦ９において、金融機関個社Ｋ（個社運用サーバ３により管理される個社運用サービスページ）は、エンドユーザ端末４を介してエンドユーザＭへ投資一任契約が締結されたことを通知する。なお、投資一任契約が締結されたことは、エンドユーザ端末４を介さず、電子メールや郵送により、エンドユーザＭへ通知されてもよい。
例えば契約申込みの流れは以下の通りである。
即ち、ステップＳＦ１において、エンドユーザＭは、エンドユーザ端末４を操作して、金融機関個社Ｋ（個社運用サーバ３により管理される個社運用サービスページ）において、運用サービスを導入したいファンド口座を選択する。
なお、以下、エンドユーザＭが、エンドユーザ端末４を操作して、金融機関個社Ｋ（個社運用サーバ３により管理される個社運用サービスページ）において所定行為を行うことを、単に、「エンドユーザＭが、所定行為を行う」と略記する。
ステップＳＦ２において、エンドユーザＭは、ファンド口座の運用を一任する運用サービスを選択する。
ステップＳＦ３において、エンドユーザＭは、運用サービスを申込む。その際に、契約締結前交付書面等の確認と同意がなされる。
ステップＳＦ４において、サービス提供１の運用サービス管理部６６は、投資一任契約を申し込み中として運用サービスＤＢ８２に登録する。
ステップＳＦ５において、投資運用業者Ｔは、投資運用業者端末５を操作することで、申し込み中の投資一任契約（データセット等の運用サービスデータ）を全て取得する。
ステップＳＦ６において、投資運用業者Ｔが、投資運用業者端末５を操作することで、申込みを承諾する。
ステップＳＦ７において、サービス提供者サーバ１の運用サービス管理部６６は、申し込み承諾を受けて、投資一任契約（データセット等の運用サービスデータ）を締結済みとして運用サービスＤＢ８２に登録する。
ステップＳＦ８において、サービス提供者サーバ１の一任資産一致管理部６１は、金融機関個社Ｋの個社バックオフィスシステム２へ締結情報を連携させる制御を実行する。
ステップＳＦ９において、金融機関個社Ｋ（個社運用サーバ３により管理される個社運用サービスページ）は、エンドユーザ端末４を介してエンドユーザＭへ投資一任契約が締結されたことを通知する。なお、投資一任契約が締結されたことは、エンドユーザ端末４を介さず、電子メールや郵送により、エンドユーザＭへ通知されてもよい。
【0095】
次に、エンドユーザＭによる、投資運用業者Ｔとの投資一任契約の解約の流れについて説明する。
図２５は、エンドユーザによる、投資運用業者との投資一任契約の解約の流れの概要を示す図である。
図２５は、エンドユーザによる、投資運用業者との投資一任契約の解約の流れの概要を示す図である。
【0096】
サービス提供者サーバ１のバーチャル口座管理部５１は、投資一任契約の解除については申込みと同様に、ファンド口座と運用サービスの組み合わせ毎に実施する。
例えば契約解除の流れは以下の通りである。
即ち、ステップＳＧ１において、エンドユーザＭは、エンドユーザ端末４を操作して、金融機関個社Ｋ（個社運用サーバ３により管理される個社運用サービスページ）において、運用サービスの解約申し込みをする。
なお、以下、エンドユーザＭが、エンドユーザ端末４を操作して、金融機関個社Ｋ（個社運用サーバ３により管理される個社運用サービスページ）において所定行為を行うことを、単に、「エンドユーザＭが、所定行為を行う」と略記する。
ステップＳＧ２おいて、金融機関個社ＫＡは、サービス提供者サーバ１に対して、対象の運用サービスの投資一任契約を指定して解約申し込みをする。この場合、ファンド口座と運用サービスで一意に投資一任契約が特定される。
ステップＳＧ３において、サービス提供１の運用サービス管理部６６は、解約申し込みを受けて、契約を解約中として運用サービスＤＢ８２に登録する。
ステップＳＧ４において、運用サービス管理部６６は、運用サービスが解約中の状態の契約の一覧を運用サービスＤＢ８２から取得する。
ステップＳＧ５において、運用サービス管理部６６は、解約中の契約に紐づくファンド口座の資産について、資産売却指示を作成する。
ステップＳＧ６において、サービス提供者サーバ１の一任資産一致管理部６１は、金融機関個社Ｋの個社バックオフィスシステム２へ、資産売却指示を連携させる制御を実行する。
ステップＳＧ７において、一任資産一致管理部６１は、金融機関個社Ｋの個社バックオフィスシステム２からの売却指示に伴う約定を連携させる制御を実行する。
ステップＳＧ８において、運用サービス管理部６６は、資産の売却にともなう全ての約定の受け渡し完了をもって、ステップＳＧ９において、投資一任契約を解約済みとして運用サービスＤＢ８２に登録する。
例えば契約解除の流れは以下の通りである。
即ち、ステップＳＧ１において、エンドユーザＭは、エンドユーザ端末４を操作して、金融機関個社Ｋ（個社運用サーバ３により管理される個社運用サービスページ）において、運用サービスの解約申し込みをする。
なお、以下、エンドユーザＭが、エンドユーザ端末４を操作して、金融機関個社Ｋ（個社運用サーバ３により管理される個社運用サービスページ）において所定行為を行うことを、単に、「エンドユーザＭが、所定行為を行う」と略記する。
ステップＳＧ２おいて、金融機関個社ＫＡは、サービス提供者サーバ１に対して、対象の運用サービスの投資一任契約を指定して解約申し込みをする。この場合、ファンド口座と運用サービスで一意に投資一任契約が特定される。
ステップＳＧ３において、サービス提供１の運用サービス管理部６６は、解約申し込みを受けて、契約を解約中として運用サービスＤＢ８２に登録する。
ステップＳＧ４において、運用サービス管理部６６は、運用サービスが解約中の状態の契約の一覧を運用サービスＤＢ８２から取得する。
ステップＳＧ５において、運用サービス管理部６６は、解約中の契約に紐づくファンド口座の資産について、資産売却指示を作成する。
ステップＳＧ６において、サービス提供者サーバ１の一任資産一致管理部６１は、金融機関個社Ｋの個社バックオフィスシステム２へ、資産売却指示を連携させる制御を実行する。
ステップＳＧ７において、一任資産一致管理部６１は、金融機関個社Ｋの個社バックオフィスシステム２からの売却指示に伴う約定を連携させる制御を実行する。
ステップＳＧ８において、運用サービス管理部６６は、資産の売却にともなう全ての約定の受け渡し完了をもって、ステップＳＧ９において、投資一任契約を解約済みとして運用サービスＤＢ８２に登録する。
【0097】
【0098】
投資運用業者ＴＸ，ＴＹは、投資一任契約を適切に履行するため、例えば以下のような第１乃至第３業務を行う必要がある。
第１業務とは、運用責任者の責務としての運用状況のモニタリングである。
第２業務とは、契約締結の主体の責務としての、契約の適切性の定期的なチェック（例えばアンチマネーロンダリングに関わるチェック）である。
第３業務とは、カスタマーサポートである。
投資運用業者ＴＸ，ＴＹは、これらの第１乃至第３業務の遂行のためには、サービス提供１が保有するデータ、顧客情報や契約データや運用情報等を把握する必要がある。
当然ながら、投資運用業者ＴＸが提供する運用サービスのデータを、別の運用サービスを提供する投資運用業者ＴＹが参照することはＮＧである。逆に、投資運用業者ＴＹが提供する運用サービスのデータを、別の運用サービスを提供する投資運用業者ＴＸが参照することはＮＧである。
一方で、金融機関個社ＫＸが運用サービスを提供するにあたっては、運用サービス全体のデータを参照する必要がある。
以上のことから、複数の投資運用業者ＴＸ，ＴＹが運用サービスに参加するには、金融機関個社ＫＡと投資運用業者ＴＸ，ＴＹからのデータへのアクセスを適切に制御する仕組みを作ることが必要である。このようなアクセスの適切な制御の仕組み又は処理が、アクセス制御である。
アクセス制御は、図２２のアクセス制御部６４によって実行される。
第１業務とは、運用責任者の責務としての運用状況のモニタリングである。
第２業務とは、契約締結の主体の責務としての、契約の適切性の定期的なチェック（例えばアンチマネーロンダリングに関わるチェック）である。
第３業務とは、カスタマーサポートである。
投資運用業者ＴＸ，ＴＹは、これらの第１乃至第３業務の遂行のためには、サービス提供１が保有するデータ、顧客情報や契約データや運用情報等を把握する必要がある。
当然ながら、投資運用業者ＴＸが提供する運用サービスのデータを、別の運用サービスを提供する投資運用業者ＴＹが参照することはＮＧである。逆に、投資運用業者ＴＹが提供する運用サービスのデータを、別の運用サービスを提供する投資運用業者ＴＸが参照することはＮＧである。
一方で、金融機関個社ＫＸが運用サービスを提供するにあたっては、運用サービス全体のデータを参照する必要がある。
以上のことから、複数の投資運用業者ＴＸ，ＴＹが運用サービスに参加するには、金融機関個社ＫＡと投資運用業者ＴＸ，ＴＹからのデータへのアクセスを適切に制御する仕組みを作ることが必要である。このようなアクセスの適切な制御の仕組み又は処理が、アクセス制御である。
アクセス制御は、図２２のアクセス制御部６４によって実行される。
【0099】
サービス提供１内で保有するデータは、以下の３種類が存在する
１種類目のデータは、運用サービスに紐づくデータである。
２種類目のデータは、エンドユーザＭに紐づくデータである。
３種類目のデータは、その他のデータである。
１種類目のデータは、運用サービスに紐づくデータである。
２種類目のデータは、エンドユーザＭに紐づくデータである。
３種類目のデータは、その他のデータである。
【0100】
１種類目の運用サービスに紐づくデータが、運用サービスデータである。
即ち、運用サービスデータには、図２３に示されるようなテンプレートセットの他、例えば、契約に関する情報や、ファンド口座内の運用情報が含まれる。
運用サービスデータは、上述したように、運用サービス毎に、図２２の運用サービスＤＢ８２に格納されて、運用サービス管理部６６により管理される。即ち、運用サービスには、それを識別可能な運用サービスＩＤが付されており、当該運用サービスＩＤが運用サービスデータに紐づけられて管理されている。
即ち、運用サービスデータには、図２３に示されるようなテンプレートセットの他、例えば、契約に関する情報や、ファンド口座内の運用情報が含まれる。
運用サービスデータは、上述したように、運用サービス毎に、図２２の運用サービスＤＢ８２に格納されて、運用サービス管理部６６により管理される。即ち、運用サービスには、それを識別可能な運用サービスＩＤが付されており、当該運用サービスＩＤが運用サービスデータに紐づけられて管理されている。
【0101】
２種類目のエンドユーザＭに紐づくデータ（以下、「エンドユーザデータ」と呼ぶ）は例えば、エンドユーザＭの氏名や住所などの顧客情報（いわゆる個人情報）である。
エンドユーザデータは、図２２のエンドユーザＤＢ８１に格納され、エンドユーザ管理部６５により管理される。即ち、エンドユーザＭには、それを識別可能なエンドユーザＩＤが付されており、当該エンドユーザＩＤがエンドユーザデータに紐づけられて管理されている。
エンドユーザデータは、図２２のエンドユーザＤＢ８１に格納され、エンドユーザ管理部６５により管理される。即ち、エンドユーザＭには、それを識別可能なエンドユーザＩＤが付されており、当該エンドユーザＩＤがエンドユーザデータに紐づけられて管理されている。
【0102】
３種類目のその他のデータは例えば、銘柄マスタや各種設定などが挙げられる。
また、投資運用業者Ｔに関するデータ（以下、「投資運用業者データ」と呼ぶ）もその他のデータの一例である。投資運用業者データは、図２２の投資運用業者ＤＢ８３に格納され、投資運用業者管理部６７により管理される。即ち、投資運用業者Ｔには、それを識別可能な投資運用業者ＩＤが付されており、当該投資運用業者ＩＤが投資運用業者データに紐づけられて管理されている。
また、投資運用業者Ｔに関するデータ（以下、「投資運用業者データ」と呼ぶ）もその他のデータの一例である。投資運用業者データは、図２２の投資運用業者ＤＢ８３に格納され、投資運用業者管理部６７により管理される。即ち、投資運用業者Ｔには、それを識別可能な投資運用業者ＩＤが付されており、当該投資運用業者ＩＤが投資運用業者データに紐づけられて管理されている。
【0103】
アクセス制御は、１種類目の運用サービスデータと、２種類目のエンドユーザデータに対して必要である。
そこで、以下、運用サービスデータ、及びエンドユーザデータの夫々に対するアクセス制御について説明する。
そこで、以下、運用サービスデータ、及びエンドユーザデータの夫々に対するアクセス制御について説明する。
【0104】
図２７は、運用サービスデータに対するアクセス制御に必要な、運用サービスと投資運用業者との紐付けの概要を示す図である。
【0105】
運用サービスデータに対するアクセス制御の準備として、投資運用業者Ｔと、当該投資運用業者Ｔが提供する１以上の運用サービスの夫々との紐付けを管理するため、サービス提供者サーバ１は、まず運用サービスＩＤと投資運用業者ＩＤとの紐付けを行なう。
これにより、運用サービスデータと、投資運用業者Ｔとの紐付けが可能となる。
これにより、運用サービスデータと、投資運用業者Ｔとの紐付けが可能となる。
【0106】
図２８は、運用サービスデータに対するアクセス制御の概要を示す図である。
【0107】
例えば金融機関個社ＫＡが提供する運用サービスのテンプレートセットのアクセス権限の有無を判定するおおよその流れは以下の通りである。
ステップＳＨ１において、アクセス制御部６４は、担当者が所属するロールを取得する。
図２８の例では、投資運用業者ＴＸの担当者ＴＸＴのロール、投資運用業者ＴＹの担当者ＴＹＴのロール、又は金融機関ＫＡの担当者ＫＡＴのロールが取得される。
ステップＳＨ２において、アクセス制御部６４は、取得したロールが金融機関個社ＫＡの担当者ＫＡＴのものである場合には、処理をステップＳＨ２－ａに進め、それ以外の場合（投資運用業者Ｔの担当者のものである場合）、処理をステップＳＨ３に進める。
ステップＳＨ２－ａにおいて、アクセス制御部６４は、金融機関担当者ＫＡＴに対して全てのテンプレートセットＸ－１，Ｘ－２へのアクセス権限を与える。これにより、アクセス制御の処理は終了となる。
これに対して、ロールが投資運用業者Ｔの担当者のものである場合、ステップＳＨ３において、アクセス制御部６４は、ロールが示す担当者が所属する投資運用業者Ｔの投資運用業者ＩＤを取得する。
ステップＳＨ４において、アクセス制御部６４は、各運用サービスの運用サービスＩＤの夫々と対応付けられた投資運用業者ＩＤを取得する。
ステップＳＨ５において、アクセス制御部６４は、ステップＳＨ３及びステップＳＨ４の夫々で取得された投資運用業者ＩＤとが一致していれば、当該ステップＳＨ４で取得された投資運用業者ＩＤに対応付けられている運用サービスＩＤで特定されるテンプレートセットへのアクセス権限を、担当者に対して与える。
なお、ステップＳＨ５において、不一致ならアクセス権限なしと判断される。
また、実際には実務におけるロール（リーガル担当か運用責任者かなど）に従って、参照権限の有無、更新権限の有無、削除権限の有無などのアクセス権限（ＣＲＵＤ）は細かく制御される。
ステップＳＨ１において、アクセス制御部６４は、担当者が所属するロールを取得する。
図２８の例では、投資運用業者ＴＸの担当者ＴＸＴのロール、投資運用業者ＴＹの担当者ＴＹＴのロール、又は金融機関ＫＡの担当者ＫＡＴのロールが取得される。
ステップＳＨ２において、アクセス制御部６４は、取得したロールが金融機関個社ＫＡの担当者ＫＡＴのものである場合には、処理をステップＳＨ２－ａに進め、それ以外の場合（投資運用業者Ｔの担当者のものである場合）、処理をステップＳＨ３に進める。
ステップＳＨ２－ａにおいて、アクセス制御部６４は、金融機関担当者ＫＡＴに対して全てのテンプレートセットＸ－１，Ｘ－２へのアクセス権限を与える。これにより、アクセス制御の処理は終了となる。
これに対して、ロールが投資運用業者Ｔの担当者のものである場合、ステップＳＨ３において、アクセス制御部６４は、ロールが示す担当者が所属する投資運用業者Ｔの投資運用業者ＩＤを取得する。
ステップＳＨ４において、アクセス制御部６４は、各運用サービスの運用サービスＩＤの夫々と対応付けられた投資運用業者ＩＤを取得する。
ステップＳＨ５において、アクセス制御部６４は、ステップＳＨ３及びステップＳＨ４の夫々で取得された投資運用業者ＩＤとが一致していれば、当該ステップＳＨ４で取得された投資運用業者ＩＤに対応付けられている運用サービスＩＤで特定されるテンプレートセットへのアクセス権限を、担当者に対して与える。
なお、ステップＳＨ５において、不一致ならアクセス権限なしと判断される。
また、実際には実務におけるロール（リーガル担当か運用責任者かなど）に従って、参照権限の有無、更新権限の有無、削除権限の有無などのアクセス権限（ＣＲＵＤ）は細かく制御される。
【0108】
【0109】
エンドユーザＭに関するデータは、口座開設等を通して金融機関個社ＫＡが受領して、保管している。
サービス提供者サーバ１は、エンドユーザＭのエンドユーザデータとして、投資一任契約の締結、維持に必要な個人情報を、以下の流れで金融機関個社ＫＡから受け取って保管する。
ステップＳＩ１において、エンドユーザＭは、エンドユーザ端末４を操作して、金融機関個社ＫＡ（個社運用サーバ３により管理される個社運用サービスページ）において、運用サービスの投資一任契約の申し込みをする。
なお、以下、エンドユーザＭが、エンドユーザ端末４を操作して、金融機関個社ＫＡ（個社運用サーバ３により管理される個社運用サービスページ）において所定行為を行うことを、単に、「エンドユーザＭが、所定行為を行う」と略記する。上述したように、「エンドユーザＭが、所定行為を行う」には、エンドユーザＭと対面営業する営業員がエンドユーザＭの所定行為を代理（委託）する場合を含まれる。
ステップＳＩ２において、サービス提供者サーバ１の一任資産一致管理部６１は、金融機関個社ＫＡにおいて顧客情報が付加された投資一任契約申し込み指示を連携させる制御を実行する。
ステップＳＩ３において、サービス提供者サーバ１のユーザインタフェース制御部６３は、契約申し込みＵＩをエンドユーザ端末４に表示させる。
ステップＳＩ４において、エンドユーザＭは、契約申し込みＵＩから申し込みに同意する。
ステップＳＩ５において、サービス提供者サーバ１のエンドユーザ管理部６５は、申し込みに同意したエンドユーザＭの顧客情報８１と契約情報８２とをエンドユーザデータとして取得して、エンドユーザＤＢ８１に保存する。
ステップＳＩ６において、一任資産一致管理部６１は、（契約締結後、一定期間毎に）金融機関個社ＫＡとの間でエンドユーザデータ（顧客情報）を連携させる制御を実行する。
ステップＳＩ７において、エンドユーザ管理部６５は、ステップＳＩ６の連携内容に応じて、エンドユーザデータ（顧客情報）を更新する。
サービス提供者サーバ１は、エンドユーザＭのエンドユーザデータとして、投資一任契約の締結、維持に必要な個人情報を、以下の流れで金融機関個社ＫＡから受け取って保管する。
ステップＳＩ１において、エンドユーザＭは、エンドユーザ端末４を操作して、金融機関個社ＫＡ（個社運用サーバ３により管理される個社運用サービスページ）において、運用サービスの投資一任契約の申し込みをする。
なお、以下、エンドユーザＭが、エンドユーザ端末４を操作して、金融機関個社ＫＡ（個社運用サーバ３により管理される個社運用サービスページ）において所定行為を行うことを、単に、「エンドユーザＭが、所定行為を行う」と略記する。上述したように、「エンドユーザＭが、所定行為を行う」には、エンドユーザＭと対面営業する営業員がエンドユーザＭの所定行為を代理（委託）する場合を含まれる。
ステップＳＩ２において、サービス提供者サーバ１の一任資産一致管理部６１は、金融機関個社ＫＡにおいて顧客情報が付加された投資一任契約申し込み指示を連携させる制御を実行する。
ステップＳＩ３において、サービス提供者サーバ１のユーザインタフェース制御部６３は、契約申し込みＵＩをエンドユーザ端末４に表示させる。
ステップＳＩ４において、エンドユーザＭは、契約申し込みＵＩから申し込みに同意する。
ステップＳＩ５において、サービス提供者サーバ１のエンドユーザ管理部６５は、申し込みに同意したエンドユーザＭの顧客情報８１と契約情報８２とをエンドユーザデータとして取得して、エンドユーザＤＢ８１に保存する。
ステップＳＩ６において、一任資産一致管理部６１は、（契約締結後、一定期間毎に）金融機関個社ＫＡとの間でエンドユーザデータ（顧客情報）を連携させる制御を実行する。
ステップＳＩ７において、エンドユーザ管理部６５は、ステップＳＩ６の連携内容に応じて、エンドユーザデータ（顧客情報）を更新する。
【0110】
図３０は、エンドユーザデータに対するアクセス制御の概要を示す図である。
【0111】
金融機関個社ＫＡ及び投資運用業者ＴＸ，ＴＹの担当者の夫々によるエンドユーザデータ（顧客情報）へのアクセスは、以下の流れで権限判定される。
即ち、ステップＳＴ１において、アクセス制御部６４は、担当者が所属するロールを取得する。
図３０の例では、投資運用業者ＴＸの担当者ＴＸＴのロール、投資運用業者ＴＹの担当者ＴＹＴのロール、又は金融機関ＫＡの担当者ＫＡＴのロールが取得される。
ステップＳＴ２において、アクセス制御部６４は、取得したロールが金融機関個社ＫＡの担当者ＫＡＴのものである場合には、処理をステップＳＴ２－ａに進め、それ以外の場合（投資運用業者Ｔの担当者のものである場合）、処理をステップＳＴ３に進める。
ステップＳＴ２－ａにおいて、アクセス制御部６４は、金融機関担当者ＫＡＴに対してエンドユーザデータのアクセス権限を与える。これにより、アクセス制御の処理は終了となる。
これに対して、ロールが投資運用業者Ｔの担当者のものである場合、ステップＳＴ３において、アクセス制御部６４は、ロールが示す担当者が所属する投資運用業者Ｔの投資運用業者ＩＤを取得する。
ステップＳＴ４において、アクセス制御部６４は、エンドユーザＭが申し込み済み（契約中含む、解約済みは含まない）の１以上の運用サービスの夫々の運用サービスＩＤを全て取得する。
ステップＳＴ５において、アクセス制御部６４は、ステップＳＴ４で取得した申し込み済みの１以上の運用サービスＩＤに夫々紐づく１以上の投資運用業者ＩＤを全て取得する。
ステップＳＴ６において、アクセス制御部６４は、ステップＳＨ３で取得された投資運用業者ＩＤが、ステップＳＨ５で取得された投資運用業者ＩＤに含まれていれば、当該ステップＳＨ３で取得された投資運用業者ＩＤで特定される投資運用業者の担当者に対してアクセス権限を与える。
具体的には例えば、エンドユーザＭが運用サービスＸ－１のみ申し込み済みで、他の運用サービスは未申し込みまたは解約済みの場合、投資運用業者ＴＸの担当者ＴＸＴに対してはエンドユーザＭのエンドユーザデータ（顧客情報）へのアクセス権限が与えられる。これに対して、投資運用業者ＴＹの担当者ＴＹＴ対してアクセス権限は与えられない。
以上のアクセス制御の実行により、運用サービスを提供する金融機関個社ＫＡ及び複数の投資運用業者Ｔ（本例では投資運用業者ＴＸ，ＴＹ）が参加する状況でのデータの保護が可能となる。
即ち、ステップＳＴ１において、アクセス制御部６４は、担当者が所属するロールを取得する。
図３０の例では、投資運用業者ＴＸの担当者ＴＸＴのロール、投資運用業者ＴＹの担当者ＴＹＴのロール、又は金融機関ＫＡの担当者ＫＡＴのロールが取得される。
ステップＳＴ２において、アクセス制御部６４は、取得したロールが金融機関個社ＫＡの担当者ＫＡＴのものである場合には、処理をステップＳＴ２－ａに進め、それ以外の場合（投資運用業者Ｔの担当者のものである場合）、処理をステップＳＴ３に進める。
ステップＳＴ２－ａにおいて、アクセス制御部６４は、金融機関担当者ＫＡＴに対してエンドユーザデータのアクセス権限を与える。これにより、アクセス制御の処理は終了となる。
これに対して、ロールが投資運用業者Ｔの担当者のものである場合、ステップＳＴ３において、アクセス制御部６４は、ロールが示す担当者が所属する投資運用業者Ｔの投資運用業者ＩＤを取得する。
ステップＳＴ４において、アクセス制御部６４は、エンドユーザＭが申し込み済み（契約中含む、解約済みは含まない）の１以上の運用サービスの夫々の運用サービスＩＤを全て取得する。
ステップＳＴ５において、アクセス制御部６４は、ステップＳＴ４で取得した申し込み済みの１以上の運用サービスＩＤに夫々紐づく１以上の投資運用業者ＩＤを全て取得する。
ステップＳＴ６において、アクセス制御部６４は、ステップＳＨ３で取得された投資運用業者ＩＤが、ステップＳＨ５で取得された投資運用業者ＩＤに含まれていれば、当該ステップＳＨ３で取得された投資運用業者ＩＤで特定される投資運用業者の担当者に対してアクセス権限を与える。
具体的には例えば、エンドユーザＭが運用サービスＸ－１のみ申し込み済みで、他の運用サービスは未申し込みまたは解約済みの場合、投資運用業者ＴＸの担当者ＴＸＴに対してはエンドユーザＭのエンドユーザデータ（顧客情報）へのアクセス権限が与えられる。これに対して、投資運用業者ＴＹの担当者ＴＹＴ対してアクセス権限は与えられない。
以上のアクセス制御の実行により、運用サービスを提供する金融機関個社ＫＡ及び複数の投資運用業者Ｔ（本例では投資運用業者ＴＸ，ＴＹ）が参加する状況でのデータの保護が可能となる。
【0112】
次に、第２実施形態のサービス提供者サーバの適用で可能になる、金融機関個社Ｋと投資運用業者Ｔのハブ機能について説明する。
図３１は、金融機関個社と投資運用業者のハブ機能の概要を示す図である。
図３１は、金融機関個社と投資運用業者のハブ機能の概要を示す図である。
【0113】
従来手法では、金融機関個社ＫＡ，ＫＢ，ＫＣが投資運用業者ＴＸと直接接続するケースがほとんどなことから、掛け算で接続が増えることによる接続コストがハードルの１つとなっていた。
このハードルを解消するため、第２実施形態サービス提供者サーバ１で金融機関個社ＫＡ，ＫＢ，ＫＣと投資運用業者ＴＸをつなぐハブ機能について説明する。
まず以前に定義した金融機関個社Ｋを特定可能な金融機関個社ＩＤや、投資運用業者Ｔを特定可能な投資運用業者ＩＤを、グローバルに一意な値となるように定義する。
グローバルに一意とは、サービス提供者サーバ１が管理する範囲内で同一の金融機関個社ＩＤ及び投資運用業者ＩＤを持つ金融機関個社Ｋ又は投資運用業者Ｔが存在しないことをいう。
次に投資運用業者Ｔから各金融機関個社Ｋｎ（ｎは任意の値であり、図３１の例ではＡ，Ｂ，Ｃのうちの何れか）の夫々に対応付けられたバーチャル口座管理部５１ｎにアクセスするためのプロキシ部５２が、サービス提供者サーバ１において機能するように用意される。
即ち、バーチャル口座管理部５１は金融機関個社Ｋ毎に用意される。各金融機関個社Ｋのバーチャル口座管理部５１は、サービス提供者サーバ１として別々の装置に設けられる場合もある。このため、投資運用業者Ｔが、金融機関個社Ｋ毎のバーチャル口座管理部５１との接続を個別に確立するとコストが高くハードルとなる。
そこで、プロキシ部５２は、金融機関個社Ｋ毎に用意されるバーチャル口座管理部５１を透過的に扱うために用意される。
このハードルを解消するため、第２実施形態サービス提供者サーバ１で金融機関個社ＫＡ，ＫＢ，ＫＣと投資運用業者ＴＸをつなぐハブ機能について説明する。
まず以前に定義した金融機関個社Ｋを特定可能な金融機関個社ＩＤや、投資運用業者Ｔを特定可能な投資運用業者ＩＤを、グローバルに一意な値となるように定義する。
グローバルに一意とは、サービス提供者サーバ１が管理する範囲内で同一の金融機関個社ＩＤ及び投資運用業者ＩＤを持つ金融機関個社Ｋ又は投資運用業者Ｔが存在しないことをいう。
次に投資運用業者Ｔから各金融機関個社Ｋｎ（ｎは任意の値であり、図３１の例ではＡ，Ｂ，Ｃのうちの何れか）の夫々に対応付けられたバーチャル口座管理部５１ｎにアクセスするためのプロキシ部５２が、サービス提供者サーバ１において機能するように用意される。
即ち、バーチャル口座管理部５１は金融機関個社Ｋ毎に用意される。各金融機関個社Ｋのバーチャル口座管理部５１は、サービス提供者サーバ１として別々の装置に設けられる場合もある。このため、投資運用業者Ｔが、金融機関個社Ｋ毎のバーチャル口座管理部５１との接続を個別に確立するとコストが高くハードルとなる。
そこで、プロキシ部５２は、金融機関個社Ｋ毎に用意されるバーチャル口座管理部５１を透過的に扱うために用意される。
【0114】
例えば投資運用業者ＴＸが複数の金融機関個社ＫＡ，ＫＢ，ＫＣの中からアクセス可能なバーチャル口座管理部５１を見つける流れは以下のようになる。
ステップＳＴＵ１において、投資運用業者ＴＸは、投資運用業者端末５を操作して、自身の投資運用業者ＩＤ（Ｘ）でプロキシ部５２に接続する。
ステップＳＴＵ２において、プロキシ部５２は、事前に登録された各金融機関個社ＫＡ，ＫＢ，ＫＣの夫々に紐づくバーチャル口座管理部５１Ａ，５１Ｂ，５１Ｃの夫々に対して、投資運用業者ＩＤ（Ｘ）がアクセス可能か否かを問い合わせる。
ステップＳＴＵ３において、各金融機関個社ＫＡ，ＫＢ，ＫＣの夫々に紐づくバーチャル口座管理部５１Ａ，５１Ｂ，５１Ｃの夫々は、ステップＳＴＵ２において問い合わせがあった投資運用業者ＩＤ（Ｘ）がアクセス可能か否かを判定し、その判定結果をプロキシ部５２に返却する。
ステップＳＴＵ４において、プロキシ部５２は、各金融機関個社ＫＡ，ＫＢ，ＫＣの夫々に紐づくバーチャル口座管理部５１Ａ，５１Ｂ，５１Ｃの夫々からの判定結果を集約して、投資運用業者ＴＸがアクセス可能なバーチャル口座管理部５１を取得する。
ステップＳＴＵ１において、投資運用業者ＴＸは、投資運用業者端末５を操作して、自身の投資運用業者ＩＤ（Ｘ）でプロキシ部５２に接続する。
ステップＳＴＵ２において、プロキシ部５２は、事前に登録された各金融機関個社ＫＡ，ＫＢ，ＫＣの夫々に紐づくバーチャル口座管理部５１Ａ，５１Ｂ，５１Ｃの夫々に対して、投資運用業者ＩＤ（Ｘ）がアクセス可能か否かを問い合わせる。
ステップＳＴＵ３において、各金融機関個社ＫＡ，ＫＢ，ＫＣの夫々に紐づくバーチャル口座管理部５１Ａ，５１Ｂ，５１Ｃの夫々は、ステップＳＴＵ２において問い合わせがあった投資運用業者ＩＤ（Ｘ）がアクセス可能か否かを判定し、その判定結果をプロキシ部５２に返却する。
ステップＳＴＵ４において、プロキシ部５２は、各金融機関個社ＫＡ，ＫＢ，ＫＣの夫々に紐づくバーチャル口座管理部５１Ａ，５１Ｂ，５１Ｃの夫々からの判定結果を集約して、投資運用業者ＴＸがアクセス可能なバーチャル口座管理部５１を取得する。
【0115】
なお、ステップＳＴＵ２及び３については、上述のように都度問い合わせではなく、事前にプロキシ部５２と各バーチャル口座管理部５１との間で投資運用業者ＩＤの情報を共有する方式もあり得る。
アクセス可能なバーチャル口座管理部５１が判明したあとは、プロキシ部５２は、投資運用業者ＴＸからのアクセスをバーチャル口座管理部５１に中継することで、上述のアクセス制御等で説明した手順でバーチャル口座管理部５１が保有するデータへのアクセスが可能となる。
このような金融機関個社Ｋと投資運用業者Ｔのハブ機能の採用により、金融機関個社Ｋと投資運用業者Ｔは、バーチャル口座管理部５１またはプロキシ部５２へ接続を一度確立するだけで、データへの適切なアクセスが可能となり、コスト低減の効果が実現できる。
アクセス可能なバーチャル口座管理部５１が判明したあとは、プロキシ部５２は、投資運用業者ＴＸからのアクセスをバーチャル口座管理部５１に中継することで、上述のアクセス制御等で説明した手順でバーチャル口座管理部５１が保有するデータへのアクセスが可能となる。
このような金融機関個社Ｋと投資運用業者Ｔのハブ機能の採用により、金融機関個社Ｋと投資運用業者Ｔは、バーチャル口座管理部５１またはプロキシ部５２へ接続を一度確立するだけで、データへの適切なアクセスが可能となり、コスト低減の効果が実現できる。
【0116】
以上まとめると、第２実施形態のサービス提供者サーバ１は、自身の資産を用いてＮ個（Ｎは、１以上の整数値）の運用サービスの提供を受けるエンドユーザＭにより管理されるエンドユーザ端末４と、エンドユーザＭの資産を取引口座で管理する金融機関個社Ｋにより管理される個社バックオフィスシステム２等と、エンドユーザＭと契約をすることにより、Ｎ個の運用サービスのうち少なくとも一部の運用を行うＭ（Ｍは、１以上の整数値）の投資運用業者Ｔの夫々により管理されるＭの投資運用業者端末５と、夫々通信をする。
運用サービス管理部６６は、例えば図２３に示すように、所定運用サービスについてのエンドユーザＭと投資運用業者Ｔとの契約の状態を示す契約状態データ（例えば図２３のテンプレートセット）を含む当該所定運用サービスに紐づくデータを運用サービスデータとして、当該運用サービスデータと、当該所定運用サービスを識別可能な運用サービスＩＤと、当該所定運用サービスに対応付けられたファンド口座とを紐付けて、Ｎ個の運用サービス毎に管理する。
ユーザインタフェース制御部６３は、所定運用サービスの契約の締結時、契約中、又は解約時における、エンドユーザＭ又は投資運用業者Ｔが利用するユーザインタフェースを、エンドユーザ端末４又は投資運用業者端末５に対して提供する。
この場合、バーチャル口座管理部５１は、エンドユーザＭ又は投資運用業者Ｔのユーザインタフェースを用いた所定運用サービスに対する操作に基づいて、所定運用サービスＩＤに対応付けられたファンド口座において、運用サービスデータを用いた処理を実行する。
運用サービス管理部６６は、例えば図２３に示すように、所定運用サービスについてのエンドユーザＭと投資運用業者Ｔとの契約の状態を示す契約状態データ（例えば図２３のテンプレートセット）を含む当該所定運用サービスに紐づくデータを運用サービスデータとして、当該運用サービスデータと、当該所定運用サービスを識別可能な運用サービスＩＤと、当該所定運用サービスに対応付けられたファンド口座とを紐付けて、Ｎ個の運用サービス毎に管理する。
ユーザインタフェース制御部６３は、所定運用サービスの契約の締結時、契約中、又は解約時における、エンドユーザＭ又は投資運用業者Ｔが利用するユーザインタフェースを、エンドユーザ端末４又は投資運用業者端末５に対して提供する。
この場合、バーチャル口座管理部５１は、エンドユーザＭ又は投資運用業者Ｔのユーザインタフェースを用いた所定運用サービスに対する操作に基づいて、所定運用サービスＩＤに対応付けられたファンド口座において、運用サービスデータを用いた処理を実行する。
【0117】
また、第２実施形態のサービス提供者サーバ１は、次のようにして、図２６に示すような運用者サービスデータに対するアクセス制御を実行することができる。
即ち、投資運用業者管理部６７は、Ｎ個の運用サービスのうち、所定投資運用業者ＴがエンドユーザＭと契約を締結した１以上の運用サービスの夫々の運用サービスＩＤと、当該所定投資運用業者Ｔの投資運用業者ＩＤとの対応付けを、Ｍの資産運用事業者毎に管理する。
アクセス制御部６４は、Ｍの投資運用業者Ｔのうち所定投資運用業者Ｔｋからユーザインタフェースを用いた操作があった合、当該所定投資運用業者Ｔｋの資産運用事業者ＩＤと対応付けられた１以上の運用サービス識別子の夫々により識別される１以上の運用サービスデータへのアクセスを許可する。
バーチャル口座管理部５１は、アクセスが許可された運用サービスデータを用いた処理を実行する。
即ち、投資運用業者管理部６７は、Ｎ個の運用サービスのうち、所定投資運用業者ＴがエンドユーザＭと契約を締結した１以上の運用サービスの夫々の運用サービスＩＤと、当該所定投資運用業者Ｔの投資運用業者ＩＤとの対応付けを、Ｍの資産運用事業者毎に管理する。
アクセス制御部６４は、Ｍの投資運用業者Ｔのうち所定投資運用業者Ｔｋからユーザインタフェースを用いた操作があった合、当該所定投資運用業者Ｔｋの資産運用事業者ＩＤと対応付けられた１以上の運用サービス識別子の夫々により識別される１以上の運用サービスデータへのアクセスを許可する。
バーチャル口座管理部５１は、アクセスが許可された運用サービスデータを用いた処理を実行する。
【0118】
また、第２実施形態のサービス提供者サーバ１は、次のようにして、図２７に示すようなエンドユーザデータに対するアクセス制御を実行することができる。
即ち、エンドユーザ管理部６５は、エンドユーザＭに紐づくデータをエンドユーザデータ（個人情報たる顧客情報）として管理する。
アクセス制御部６４は、所定投資運用業者Ｔからユーザインタフェースを用いた操作があった場合、当該所定投資運用業者Ｔが運用するＭの運用サービスの中に、エンドユーザＭと契約を締結した状態のものがあるか否かを判定し、あると判定したときにはエンドユーザＭのエンドユーザデータへのアクセスを許可する一方、ないと判定したときにはエンドユーザデータへのアクセスを禁止する。
即ち、エンドユーザ管理部６５は、エンドユーザＭに紐づくデータをエンドユーザデータ（個人情報たる顧客情報）として管理する。
アクセス制御部６４は、所定投資運用業者Ｔからユーザインタフェースを用いた操作があった場合、当該所定投資運用業者Ｔが運用するＭの運用サービスの中に、エンドユーザＭと契約を締結した状態のものがあるか否かを判定し、あると判定したときにはエンドユーザＭのエンドユーザデータへのアクセスを許可する一方、ないと判定したときにはエンドユーザデータへのアクセスを禁止する。
【0119】
また、第２実施形態のサービス提供者サーバ１は、次のようにして、図３１に示すような金融機関個社Ｋと投資運用業者Ｔのハブ機能を実現することができる。
即ち、Ｐ（Ｐは１以上の整数値）の金融機関個社Ｋ毎に、夫々専用のバーチャル口座管理部５１が備えられている。
プロキシ部５２は、所定投資運用業者Ｔの投資運用業者端末５からアクセスの依頼があった場合、所定投資運用業者Ｔと紐づけられた１以上の金融機関個社Ｋの夫々の専用のバーチャル口座管理部５１と、当該所定投資運用業者Ｔの投資運用業者端末５との接続を行う。
即ち、Ｐ（Ｐは１以上の整数値）の金融機関個社Ｋ毎に、夫々専用のバーチャル口座管理部５１が備えられている。
プロキシ部５２は、所定投資運用業者Ｔの投資運用業者端末５からアクセスの依頼があった場合、所定投資運用業者Ｔと紐づけられた１以上の金融機関個社Ｋの夫々の専用のバーチャル口座管理部５１と、当該所定投資運用業者Ｔの投資運用業者端末５との接続を行う。
【0120】
このような構成の第２実施形態のサービス提供者サーバ１は、以下に示す各種各様な効果を奏することが可能である。
即ち、第２実施形態のサービス提供者サーバ１の適用により、バンドリングのハードルが解消され、複数の投資運用業者Ｔによる任意の数の運用サービスの提供が可能な状態となる。
以下、この状態を、金融機関個社Ｋを市場、投資運用業者Ｔを商品を販売するテナントとみなし、「運用サービスのバザール化」と呼ぶ。
即ち、第２実施形態のサービス提供者サーバ１を適用することで、運用サービスのバザール化が実現可能になり、その結果、図３２や図３３に示すようなサービスの提供が可能となる。
即ち、第２実施形態のサービス提供者サーバ１の適用により、バンドリングのハードルが解消され、複数の投資運用業者Ｔによる任意の数の運用サービスの提供が可能な状態となる。
以下、この状態を、金融機関個社Ｋを市場、投資運用業者Ｔを商品を販売するテナントとみなし、「運用サービスのバザール化」と呼ぶ。
即ち、第２実施形態のサービス提供者サーバ１を適用することで、運用サービスのバザール化が実現可能になり、その結果、図３２や図３３に示すようなサービスの提供が可能となる。
【0121】
図３２は、図２２のサービス提供者サーバ１による運用サービスのバザール化によって提供可能となるサービスのうち、選択型運用サービスの具体例を示す図である。
サービス提供者サーバ１は、第１実施形態で上述したように、任意のファンド口座を開設し、夫々運用サービスを紐づけることができる。これを拡張して、運用カテゴリーと運用サービスをエンドユーザＭに選択させるサービスが実現可能になる。以下、このようなサービスを「選択型運用サービス」と呼ぶ。
サービス提供者サーバ１は、第１実施形態で上述したように、任意のファンド口座を開設し、夫々運用サービスを紐づけることができる。これを拡張して、運用カテゴリーと運用サービスをエンドユーザＭに選択させるサービスが実現可能になる。以下、このようなサービスを「選択型運用サービス」と呼ぶ。
【0122】
選択型運用サービスの具体的な流れは以下の通りになる。
即ちステップＳＫ１において、エンドユーザＭは、エンドユーザ端末４を操作して、画面Ｇ１０において、ゴール登録時に運用カテゴリーを選択して、「運用サービスの選択に進む」を押下する。
ステップＳＫ２において、運用カテゴリーに属する運用サービスと指標の一覧を示す画面Ｇ１１が、エンドユーザ端末４に表示される。画面Ｇ１１において、指標は、エンドユーザＭが選択の際に基準として用いられる。具体的には例えば、指標として、シャープレシオや年率リターン、レーティング等が挙げられる。
ステップＳＫ３において、エンドユーザＭは、エンドユーザ端末４を操作して、画面Ｇ１１において、一覧から投資一任契約を申し込みたい運用サービスを選択し、「運用サービスを申し込む」を押下する。これにより、エンドユーザ端末４に表示される画面は、画面Ｇ１１から画面Ｇ１２に進む。
ステップＳＫ４において、エンドユーザＭは、エンドユーザ端末４を操作して、画面Ｇ１２において、投資一任契約前書面の「開く」を押下する。これにより図示はしないが、運用サービス「スマートファンド」の投資運用業者ＴであるＹ投資顧問が事前に登録した最新の書面がエンドユーザ端末４に表示される。
ステップＳＫ５において、エンドユーザＭは、契約締結前交付書面等を確認し、エンドユーザ端末４を操作して、画面Ｇ１２において「同意して申し込む」を押下する。
ステップＳＫ６において、サービス提供者サーバ１のバーチャル口座管理部５１は、エンドユーザＭが運用サービス「スマートファンド」を申し込み済というトランザクションを生成し、顧客情報のデータベースを更新する。
即ちステップＳＫ１において、エンドユーザＭは、エンドユーザ端末４を操作して、画面Ｇ１０において、ゴール登録時に運用カテゴリーを選択して、「運用サービスの選択に進む」を押下する。
ステップＳＫ２において、運用カテゴリーに属する運用サービスと指標の一覧を示す画面Ｇ１１が、エンドユーザ端末４に表示される。画面Ｇ１１において、指標は、エンドユーザＭが選択の際に基準として用いられる。具体的には例えば、指標として、シャープレシオや年率リターン、レーティング等が挙げられる。
ステップＳＫ３において、エンドユーザＭは、エンドユーザ端末４を操作して、画面Ｇ１１において、一覧から投資一任契約を申し込みたい運用サービスを選択し、「運用サービスを申し込む」を押下する。これにより、エンドユーザ端末４に表示される画面は、画面Ｇ１１から画面Ｇ１２に進む。
ステップＳＫ４において、エンドユーザＭは、エンドユーザ端末４を操作して、画面Ｇ１２において、投資一任契約前書面の「開く」を押下する。これにより図示はしないが、運用サービス「スマートファンド」の投資運用業者ＴであるＹ投資顧問が事前に登録した最新の書面がエンドユーザ端末４に表示される。
ステップＳＫ５において、エンドユーザＭは、契約締結前交付書面等を確認し、エンドユーザ端末４を操作して、画面Ｇ１２において「同意して申し込む」を押下する。
ステップＳＫ６において、サービス提供者サーバ１のバーチャル口座管理部５１は、エンドユーザＭが運用サービス「スマートファンド」を申し込み済というトランザクションを生成し、顧客情報のデータベースを更新する。
【0123】
図３３は、図３２の画面例で示す選択型運用サービスの裏側での投資一任契約申し込みに関わる流れの一例を示す図である。
本例では、エンドユーザＭが申し込む運用サービスの一任資産は金融機関個社ＫＡにより管理され、その処理は運用サービス提供者サーバ１の専用のバーチャル口座管理部５１Ａによりなされるものとする。
本例では、エンドユーザＭが申し込む運用サービスの一任資産は金融機関個社ＫＡにより管理され、その処理は運用サービス提供者サーバ１の専用のバーチャル口座管理部５１Ａによりなされるものとする。
【0124】
ステップＳＬ１において、投資運用業者ＴＸは、投資運用業者端末５を操作して、テンプレートセットを入稿する。
ステップＳＬ２において、エンドユーザＭは、エンドユーザ端末４を操作して、運用サービスを申し込む。
ステップＳＬ３において、バーチャル口座管理部５１Ａは、契約締結前交付書面等の交付用データを作成し、契約状態を申し込み済みとして登録する。このステップＳＬ３の間、エンドユーザＭにとっては図３２のステップＳＫ４乃至ＳＫ６が行われていることになる。
ステップＳＬ４において、投資運用業者ＴＸは、投資運用業者端末５を操作して、申し込み内容の確認を行う。
ステップＳＬ５において、投資運用業者ＴＸは、投資運用業者端末５を操作して、申し込みの承諾を行う。
ステップＳＬ６において、バーチャル口座管理部５１Ａは、契約締結時交付書面の交付用データを作成し、契約状態を締結済みに更新する。
以降、運用の流れは、任意のファンド口座の開設、夫々運用サービスの紐づけを行う第１実施形態の説明として上述した通りである。
ステップＳＬ２において、エンドユーザＭは、エンドユーザ端末４を操作して、運用サービスを申し込む。
ステップＳＬ３において、バーチャル口座管理部５１Ａは、契約締結前交付書面等の交付用データを作成し、契約状態を申し込み済みとして登録する。このステップＳＬ３の間、エンドユーザＭにとっては図３２のステップＳＫ４乃至ＳＫ６が行われていることになる。
ステップＳＬ４において、投資運用業者ＴＸは、投資運用業者端末５を操作して、申し込み内容の確認を行う。
ステップＳＬ５において、投資運用業者ＴＸは、投資運用業者端末５を操作して、申し込みの承諾を行う。
ステップＳＬ６において、バーチャル口座管理部５１Ａは、契約締結時交付書面の交付用データを作成し、契約状態を締結済みに更新する。
以降、運用の流れは、任意のファンド口座の開設、夫々運用サービスの紐づけを行う第１実施形態の説明として上述した通りである。
【0125】
【0126】
運用サービスのバザール化が進んだ際には、選択肢が増えることによって、エンドユーザＭに決定回避の法則が働きやすくなる課題が生じ得る。
例えば投資信託の場合、金融機関個社で多いところでは１０００種類以上の運用サービスの購入が可能である。
投資信託の選び方を紹介するサイトが多数検索されることから、投資信託の売買では決定回避の法則が働いていると考えられる。
このような課題を解決可能なサービスが、「バスケット型運用サービス」である。
例えば投資信託の場合、金融機関個社で多いところでは１０００種類以上の運用サービスの購入が可能である。
投資信託の選び方を紹介するサイトが多数検索されることから、投資信託の売買では決定回避の法則が働いていると考えられる。
このような課題を解決可能なサービスが、「バスケット型運用サービス」である。
【0127】
バスケット型運用サービスの具体的な流れは以下の通りになる。
即ちステップＳＭ１において、エンドユーザＭは、エンドユーザ端末４を操作して、画面Ｇ２０１において、ゴール登録時に運用カテゴリーを選択して、「運用サービスバスケットの選択に進む」を押下する。
ステップＳＭ２において、運用カテゴリーに属する運用サービスと指標の一覧を示す画面Ｇ２０２が、エンドユーザ端末４に表示される。
ステップＳＭ３において、エンドユーザＭは、エンドユーザ端末４を操作して、画面Ｇ２０２において、一覧から運用サービスバスケットに組み込みたい運用サービスを選択し、「運用サービスバスケットを申し込む」を押下する。これにより、エンドユーザ端末４に表示される画面は、画面Ｇ２０２から画面Ｇ２０３に進む。
ステップＳＭ４において、図示はしないが、運用サービスバスケットに含まれる、全ての運用サービスに関わる契約締結前交付書面等が交付（エンドユーザ端末４に表示）される。
ステップＳＭ５において、エンドユーザＭは、全ての契約締結前交付書面等を確認し、エンドユーザ端末４を操作して、画面Ｇ２０２において、「同意して申し込む」を押下する。
即ちステップＳＭ１において、エンドユーザＭは、エンドユーザ端末４を操作して、画面Ｇ２０１において、ゴール登録時に運用カテゴリーを選択して、「運用サービスバスケットの選択に進む」を押下する。
ステップＳＭ２において、運用カテゴリーに属する運用サービスと指標の一覧を示す画面Ｇ２０２が、エンドユーザ端末４に表示される。
ステップＳＭ３において、エンドユーザＭは、エンドユーザ端末４を操作して、画面Ｇ２０２において、一覧から運用サービスバスケットに組み込みたい運用サービスを選択し、「運用サービスバスケットを申し込む」を押下する。これにより、エンドユーザ端末４に表示される画面は、画面Ｇ２０２から画面Ｇ２０３に進む。
ステップＳＭ４において、図示はしないが、運用サービスバスケットに含まれる、全ての運用サービスに関わる契約締結前交付書面等が交付（エンドユーザ端末４に表示）される。
ステップＳＭ５において、エンドユーザＭは、全ての契約締結前交付書面等を確認し、エンドユーザ端末４を操作して、画面Ｇ２０２において、「同意して申し込む」を押下する。
【0128】
これにより、運用サービスのバザール化により運用サービスの数が増えたとしても、エンドユーザＭに単一の選択を迫ることが不要となる。
また、運用サービスバスケットの拡張として、シャープレシオや年率リターンなどの運用サービスの指標を元に、定期的に傾斜配分を調整することが考えられる。
調整は金融機関からエンドユーザＭへの助言、またはエンドユーザＭからの委託を受けて金融機関が調整を行なうことが考えられる。
こういった各種サービス（調整の仕組み）により、より良い運用サービスが選択される選択圧がかかり、運用サービスの改善につながることが期待される。
また、運用サービスバスケットの拡張として、シャープレシオや年率リターンなどの運用サービスの指標を元に、定期的に傾斜配分を調整することが考えられる。
調整は金融機関からエンドユーザＭへの助言、またはエンドユーザＭからの委託を受けて金融機関が調整を行なうことが考えられる。
こういった各種サービス（調整の仕組み）により、より良い運用サービスが選択される選択圧がかかり、運用サービスの改善につながることが期待される。
【0129】
以上、本発明の第２実施形態について説明した。
【0130】
【0131】
図３５は、運用サービスの概要を示す図である。
【0132】
図３５に示すように、運用サービスとは、エンドユーザＭが投資運用業者Ｔと特定の投資一任契約を締結し、エンドユーザＭの資産の運用を投資運用業者Ｔに一任する場を提供する一連の役務やそのためのシステムをいう。また、投資運用業者ＩＤとは投資運用業者Ｔを一意に特定するためのものである。
即ち、図３５に示すように、投資運用業者ＩＤが付された投資運用業者Ｔ及びエンドユーザＭは、投資一任契約締結前書面、投資一任契約締結時交付書面、投資一任資産の授受を、運用サービスにより提供される場を介してやり取りするものである。
即ち、図３５に示すように、投資運用業者ＩＤが付された投資運用業者Ｔ及びエンドユーザＭは、投資一任契約締結前書面、投資一任契約締結時交付書面、投資一任資産の授受を、運用サービスにより提供される場を介してやり取りするものである。
【0133】
図３６は、投資一任契約書面のテンプレートセットの一例を示す図である。
【0134】
図３６に示すように、本サービスにより、投資一任契約書面のバージョン毎のテンプレートセットが管理される。
ここで、「投資一任契約締結前書面等」には、例えば以下のような文書が含まれることがある。
１．投資一任契約締結前書面
２．個人情報の第三者提供に係る同意書
３．電磁的交付に係る同意書
４．投資信託契約締結前書面
５．投資一任契約約款
また、「投資一任契約締結前書面等」は、全部または一部をまとめた書面の集合体として管理される場合もあれば、全て別々に管理される場合もある。
以下、本実施形態では、「投資一任契約締結前書面等」は、全部を一つの書面の集合体として管理されるものとして説明する。
投資一任契約には、投資一任契約前交付書面等と投資一任契約時交付書面が紐づけられて管理される。
投資一任契約前交付書面等と、投資一任契約時交付書面の夫々はバージョン管理され、その履歴や差分をまとめて「投資一任契約書面テンプレートセット」として管理される。
ここで、「投資一任契約締結前書面等」には、例えば以下のような文書が含まれることがある。
１．投資一任契約締結前書面
２．個人情報の第三者提供に係る同意書
３．電磁的交付に係る同意書
４．投資信託契約締結前書面
５．投資一任契約約款
また、「投資一任契約締結前書面等」は、全部または一部をまとめた書面の集合体として管理される場合もあれば、全て別々に管理される場合もある。
以下、本実施形態では、「投資一任契約締結前書面等」は、全部を一つの書面の集合体として管理されるものとして説明する。
投資一任契約には、投資一任契約前交付書面等と投資一任契約時交付書面が紐づけられて管理される。
投資一任契約前交付書面等と、投資一任契約時交付書面の夫々はバージョン管理され、その履歴や差分をまとめて「投資一任契約書面テンプレートセット」として管理される。
【0135】
図３７は、運用サービスと運用サービスＩＤの関係性を示す図である。
【0136】
図３７に示すように、運用サービスと運用サービスＩＤとは、対応付けられたものである。
即ち、運用サービスＩＤは、運用サービスを一意に特定するものである。
また、運用サービスは、投資一任契約を根拠として構築される。したがって、運用サービス及び投資一任契約書面テンプレートセットは、１対１に対応する。
即ち、運用サービスＩＤは、運用サービスを一意に特定するものである。
また、運用サービスは、投資一任契約を根拠として構築される。したがって、運用サービス及び投資一任契約書面テンプレートセットは、１対１に対応する。
【0137】
図３８は、エンドユーザと口座の関係性を示す図である。
【0138】
金融機関ＫＸには、当該金融機関ＫＸを特定する金融機関個社ＩＤが付される。
エンドユーザＭは、金融機関ＫＸで証券口座（総合口座）を開設する。
エンドユーザＭには、金融機関ＫＸ内でエンドユーザＭと保有する総合口座を特定するものとして、エンドユーザＩＤが付される。
このように、エンドユーザＫＸの金融機関ＫＸにおける総合口座は、金融機関個社ＩＤとエンドユーザＩＤにより特定される。
エンドユーザＭは、金融機関ＫＸで証券口座（総合口座）を開設する。
エンドユーザＭには、金融機関ＫＸ内でエンドユーザＭと保有する総合口座を特定するものとして、エンドユーザＩＤが付される。
このように、エンドユーザＫＸの金融機関ＫＸにおける総合口座は、金融機関個社ＩＤとエンドユーザＩＤにより特定される。
【0139】
図３９は、総合口座と取引口座の関係性を示す図である。
【0140】
図３９に示すように、総合口座に属するものとして、実際に取引を管理する取引口座が管理される。ここで、１つの総合口座に対して複数（図３９の例においてはＮ個）の取引口座が属する。
例えば、一般口座や特定口座、ＮＩＳＡ口座は、取引口座の一例である。
例えば、一般口座や特定口座、ＮＩＳＡ口座は、取引口座の一例である。
【0141】
図４０は、総合口座と口座区分の管理の一例を示す図である。
【0142】
図３９とは異なり、図４０に示すように、総合口座と口座区分（特定口座ｏｒ一般口座）の組合せを用いて、一般口座と特定口座を表現することもできる。これは、取引口座の表現の一例である。したがって、上述の本サービスを実現可能であれば、総合口座と取引口座は、何れの表現方法を用いて管理されていてもよい。
なお、投資一任運用の資産は、取引口座内で管理される。
なお、投資一任運用の資産は、取引口座内で管理される。
【0143】
図４１は、ファンド口座とバーチャル口座コードの関係性を示す図である。
【0144】
図４１に示すように、１つの取引口座内において複数の投資一任運用を管理するため、投資一任運用の資産は、バーチャル口座コードを用いて管理される。
取引口座ＩＤとバーチャル口座コードの組み合わせを用いて、一つの投資一任運用の資産を管理する仮想的な口座、即ち、ファンド口座が特定される。
なお、バーチャル口座コードは、個社が任意の数を定義することができる。
取引口座ＩＤとバーチャル口座コードの組み合わせを用いて、一つの投資一任運用の資産を管理する仮想的な口座、即ち、ファンド口座が特定される。
なお、バーチャル口座コードは、個社が任意の数を定義することができる。
【0145】
以上、本発明の一実施形態について説明したが、本発明は、上述の実施形態に限定されるものではなく、本発明の目的を達成できる範囲での変形、改良等は本発明に含まれるものである。
【0146】
例えば、上述の実施形態では、個社バックオフィスシステム２は、投資対象証券からの配当金、分配金情報を登録するものとしたが、投資対象の取り扱いは以下のようなものとすることができる。
【0147】
図４２は、投資対象の取り扱いの一例を示す図である。
【0148】
図４２に示すように、複数の運用サービス（図４２の例では運用サービスＡ及びＢ）と投資対象を異ならせることができる。
バーチャル口座管理部５１における、取引口座への任意の数のバーチャル口座の説明において、区別管理のための手法として、専用商品方式を改善するものとして説明した。その結果、運用を行なう単位であるファンド口座の資産の区別管理が可能となり、運用サービスごとに専用商品の用意は、不要となった。
換言すると、第２実施形態の効果により運用サービスが増えたとしても、投資対象を比例して増やす必要がなくなった。これにより、以下のような効果を奏する。
バーチャル口座管理部５１における、取引口座への任意の数のバーチャル口座の説明において、区別管理のための手法として、専用商品方式を改善するものとして説明した。その結果、運用を行なう単位であるファンド口座の資産の区別管理が可能となり、運用サービスごとに専用商品の用意は、不要となった。
換言すると、第２実施形態の効果により運用サービスが増えたとしても、投資対象を比例して増やす必要がなくなった。これにより、以下のような効果を奏する。
【0149】
第１に、上場有価証券のような専用商品の準備ができないものを取り扱うことが可能となる。
具体的には例えば、一つの企業を複数のテーマに出現させる、テーマ投資ができる。
具体的には例えば、一つの企業を複数のテーマに出現させる、テーマ投資ができる。
【0150】
第２に、投資信託のような専用商品の準備が可能なものであっても、組成コストを抑えることができる。
具体的には例えば、ＴＯＰＩＸやＳ＆Ｐ５００など、メジャーなインデックスへの投資は、共通化させることができる。
即ち、図４２に示すように、投資信託ｂは、運用サービスＡ，Ｂの両方で投資対象に含まれている一方で、投資信託ａ，ｃは、夫々運用サービスＡ，Ｂでのみ投資対象とされる。
具体的には例えば、ＴＯＰＩＸやＳ＆Ｐ５００など、メジャーなインデックスへの投資は、共通化させることができる。
即ち、図４２に示すように、投資信託ｂは、運用サービスＡ，Ｂの両方で投資対象に含まれている一方で、投資信託ａ，ｃは、夫々運用サービスＡ，Ｂでのみ投資対象とされる。
【0151】
以下、共有された投資対象の取り扱いについて、具体例を用いて説明する。
ここで、前提として、投資一任契約の締結は完了済みである。また、個社バックオフィスシステム２内での一任資産の区別管理は、サブアカウント方式であるものとする。また、現金留保が発生しないものとする。
ここで、前提として、投資一任契約の締結は完了済みである。また、個社バックオフィスシステム２内での一任資産の区別管理は、サブアカウント方式であるものとする。また、現金留保が発生しないものとする。
【0152】
図４３は、新規拠出の流れの一例を示す図である。
【0153】
上述の運用サービスＡ，Ｂに対して、同時に新規拠出を行うケースを用いて説明する。
まず、ステップＳＮ１において、エンドユーザＭは、ファンド口座Ｋで運用サービスＡに１００万円、ファンド口座Ｌで運用サービスＢに１５０万円の新規拠出を申し込む。
次に、ステップＳＮ２において、サービス提供者サーバ１から個社バックオフィスシステム２へ、非一任資産から一任資産へ２５０万円の振り替えが指示される。具体的には例えば、専用商品方式の場合は、現金相当物の購入が指示される。
次に、ステップＳＮ３において、個社バックオフィスシステム２にて、非一任資産から一任資産へ２５０万円の振り替えが実施される。
次に、ステップＳＮ４において、サービス提供者サーバ１にて、ファンド口座Ｋ，Ｌで投資対象の買付金額（以下、「運用指図」とよぶ）が計算される。
具体的には例えば、ファンド口座Ｋは運用サービスＡに従い、投資信託ａにおいて４０万円、投資信託ｂにおいて６０万円、投資信託ｃにおいて０円が計算される。
また例えば、ファンド口座Ｌは運用サービスＢに従い、投資信託ａにおいて０円、投資信託Ｂにおいて１００万円、投資信託ｃにおいて５０万円が計算される。
次に、ステップＳＮ５において、サービス提供者サーバ１から執行担当者ＫＡＴへ運用指図が連携される。
次に、ステップＳＮ６において、執行担当者ＫＡＴにて、運用指図を元に買付注文が執行され約定処理が実施される。
次に、ステップＳＮ７において、執行担当者ＫＡＴにより個社バックオフィスシステム２に約定内容が登録される。
次に、ステップＳＮ８において、執行担当者ＫＡＴからサービス提供者サーバ１に買付指示で発生した約定内容が連携される。
次に、ステップＳＮ９において、サービス提供者サーバ１にて、ファンド口座Ｋ，Ｌごとに約定処理が実施され、残高が更新される。
まず、ステップＳＮ１において、エンドユーザＭは、ファンド口座Ｋで運用サービスＡに１００万円、ファンド口座Ｌで運用サービスＢに１５０万円の新規拠出を申し込む。
次に、ステップＳＮ２において、サービス提供者サーバ１から個社バックオフィスシステム２へ、非一任資産から一任資産へ２５０万円の振り替えが指示される。具体的には例えば、専用商品方式の場合は、現金相当物の購入が指示される。
次に、ステップＳＮ３において、個社バックオフィスシステム２にて、非一任資産から一任資産へ２５０万円の振り替えが実施される。
次に、ステップＳＮ４において、サービス提供者サーバ１にて、ファンド口座Ｋ，Ｌで投資対象の買付金額（以下、「運用指図」とよぶ）が計算される。
具体的には例えば、ファンド口座Ｋは運用サービスＡに従い、投資信託ａにおいて４０万円、投資信託ｂにおいて６０万円、投資信託ｃにおいて０円が計算される。
また例えば、ファンド口座Ｌは運用サービスＢに従い、投資信託ａにおいて０円、投資信託Ｂにおいて１００万円、投資信託ｃにおいて５０万円が計算される。
次に、ステップＳＮ５において、サービス提供者サーバ１から執行担当者ＫＡＴへ運用指図が連携される。
次に、ステップＳＮ６において、執行担当者ＫＡＴにて、運用指図を元に買付注文が執行され約定処理が実施される。
次に、ステップＳＮ７において、執行担当者ＫＡＴにより個社バックオフィスシステム２に約定内容が登録される。
次に、ステップＳＮ８において、執行担当者ＫＡＴからサービス提供者サーバ１に買付指示で発生した約定内容が連携される。
次に、ステップＳＮ９において、サービス提供者サーバ１にて、ファンド口座Ｋ，Ｌごとに約定処理が実施され、残高が更新される。
【0154】
なお、ステップＳＮ５の運用指図連携には、ファンド口座Ｋ，Ｌの運用指図を集約する方式と、運用指示を集約しない方式が存在する。
具体的には例えば、夫々の方式において執行担当者ＫＡＴに連携される内容は以下の通りとなる。
即ち、集約する方式においては、投資信託ａにおいて４０万円買付、投資信託ｂにおいて１６０万円買付、投資信託ｃにおいて５０万円買付、の内容が連携される。
また、集約しない方式においては、投資信託ａにおいて４０万円買付、投資信託ｂにおいて６０万円買付の内容が連携されると共に、投資信託ｂにおいて１００万円買付、投資信託ｃにおいて５０万円買付、の内容が連携される。
具体的には例えば、夫々の方式において執行担当者ＫＡＴに連携される内容は以下の通りとなる。
即ち、集約する方式においては、投資信託ａにおいて４０万円買付、投資信託ｂにおいて１６０万円買付、投資信託ｃにおいて５０万円買付、の内容が連携される。
また、集約しない方式においては、投資信託ａにおいて４０万円買付、投資信託ｂにおいて６０万円買付の内容が連携されると共に、投資信託ｂにおいて１００万円買付、投資信託ｃにおいて５０万円買付、の内容が連携される。
【0155】
図４４は、リバランスの流れを示す図である。
【0156】
上述の運用サービスＡ，Ｂにおいて、以下に示す前提のように基準価額が変化し、それに伴うリバランスが行われるものとして説明する。
即ち、前提として、各投資信託の基準価額が、以下のように変化したものとする。
投資信託ａの基準価格が１０，０００円から１０，０００円（変わりなし）となり、投資信託ｂの基準価格が１０，０００円から１５，０００円（＋５０％）となり、投資信託ｃの基準価格が１０，０００円から１２，０００円（＋２０％）となったとする。
この場合、基準価額の変動に伴い各投資一任サービスの組入比率が変化したため当初の比率に戻すように、以下のようにリバランスが行われる。
即ち、運用サービスＡの比率は投資信託ａ：投資信託ｂ＝４：６となり、運用サービスＢの比率は、投資信託ｂ：投資信託ｃ＝２：１、となる。
即ち、前提として、各投資信託の基準価額が、以下のように変化したものとする。
投資信託ａの基準価格が１０，０００円から１０，０００円（変わりなし）となり、投資信託ｂの基準価格が１０，０００円から１５，０００円（＋５０％）となり、投資信託ｃの基準価格が１０，０００円から１２，０００円（＋２０％）となったとする。
この場合、基準価額の変動に伴い各投資一任サービスの組入比率が変化したため当初の比率に戻すように、以下のようにリバランスが行われる。
即ち、運用サービスＡの比率は投資信託ａ：投資信託ｂ＝４：６となり、運用サービスＢの比率は、投資信託ｂ：投資信託ｃ＝２：１、となる。
【0157】
具体的には、以下に示す各ステップによりリバランスが行われる。
即ち、ステップＳＯ１において、サービス提供者サーバ１にてファンド口座Ｋ，Ｌのリバランス運用指図が作成される。
具体的には例えば、ファンド口座Ｋは運用サービスＡに従い、投資信託ａ＝１２万円買付、投資信託ｂ＝１２万円解約、投資信託ｃ＝０円（売買なし）とする。また、ファンド口座Ｌは運用サービスＢに従い、投資信託ａ＝０円（売買なし）、投資信託ｂ＝１０万円解約、投資信託ｃ＝１０万円買付とする。
次に、ステップＳＯ２において、サービス提供者サーバ１から執行担当者ＫＡＴへ運用指図が連携される。
次に、ステップＳＯ３において、執行担当者ＫＡＴにて、運用指図を元にリバランス注文を執行し約定処理が実施される。
次に、ステップＳＯ４において、執行担当者ＫＡＴが個社バックオフィスシステム２に約定内容が登録される。
次に、ステップＳＯ５において、執行担当者ＫＡＴからサービス提供者サーバ１にリバランスで発生した約定内容が連携される。
次に、ステップＳＯ６において、サービス提供者サーバ１にて、ファンド口座Ｋ，Ｌごとに約定処理が実施され、残高が更新される。
即ち、ステップＳＯ１において、サービス提供者サーバ１にてファンド口座Ｋ，Ｌのリバランス運用指図が作成される。
具体的には例えば、ファンド口座Ｋは運用サービスＡに従い、投資信託ａ＝１２万円買付、投資信託ｂ＝１２万円解約、投資信託ｃ＝０円（売買なし）とする。また、ファンド口座Ｌは運用サービスＢに従い、投資信託ａ＝０円（売買なし）、投資信託ｂ＝１０万円解約、投資信託ｃ＝１０万円買付とする。
次に、ステップＳＯ２において、サービス提供者サーバ１から執行担当者ＫＡＴへ運用指図が連携される。
次に、ステップＳＯ３において、執行担当者ＫＡＴにて、運用指図を元にリバランス注文を執行し約定処理が実施される。
次に、ステップＳＯ４において、執行担当者ＫＡＴが個社バックオフィスシステム２に約定内容が登録される。
次に、ステップＳＯ５において、執行担当者ＫＡＴからサービス提供者サーバ１にリバランスで発生した約定内容が連携される。
次に、ステップＳＯ６において、サービス提供者サーバ１にて、ファンド口座Ｋ，Ｌごとに約定処理が実施され、残高が更新される。
【0158】
なお、ステップＳＯ２の運用指図連携には、ファンド口座Ｋ，Ｌの運用指図を集約する方式と、運用指示を集約しない方式が存在する。
具体的には例えば、夫々の方式において執行担当者ＫＡＴに連携される内容は以下の通りとなる。
即ち、集約する方式においては、投資信託ａにおいて１２万円買付、投資信託ｂにおいて２２万円解約、投資信託ｃにおいて１０万円買付の内容が連携される。
また、集約しない方式においては、投資信託ａにおいて１２万円買付、投資信託ｂにおいて１２万円解約ノン内容が連携されると共に、投資信託ｂにおいて１０万円解約、投資信託ｃにおいて１０万円買付、の内容が連携される。
具体的には例えば、夫々の方式において執行担当者ＫＡＴに連携される内容は以下の通りとなる。
即ち、集約する方式においては、投資信託ａにおいて１２万円買付、投資信託ｂにおいて２２万円解約、投資信託ｃにおいて１０万円買付の内容が連携される。
また、集約しない方式においては、投資信託ａにおいて１２万円買付、投資信託ｂにおいて１２万円解約ノン内容が連携されると共に、投資信託ｂにおいて１０万円解約、投資信託ｃにおいて１０万円買付、の内容が連携される。
【0159】
図４５は、ポータビリティとコマンドの関係を示す図である。
【0160】
ここで、図４５の説明に用いる各用語について補足説明する。
即ち、ポータビリティとは、特定の会社のシステムだけでなく、別の会社の同種類のシステムへの接続が可能となることをいう。即ち、複数の金融機関個社Ｋの夫々に対して接続が可能となることをいう。
個社とは、本サービスを導入する第一種金融商品取引業社や登録金融機関のことをいう。
また、副作用とは、投資一任運用に関わる何らかの処理に関連して発生する、本サービスに保有されるデータに対する作成、更新、削除などの変化のことをいう。
即ち、ポータビリティとは、特定の会社のシステムだけでなく、別の会社の同種類のシステムへの接続が可能となることをいう。即ち、複数の金融機関個社Ｋの夫々に対して接続が可能となることをいう。
個社とは、本サービスを導入する第一種金融商品取引業社や登録金融機関のことをいう。
また、副作用とは、投資一任運用に関わる何らかの処理に関連して発生する、本サービスに保有されるデータに対する作成、更新、削除などの変化のことをいう。
【0161】
これにより、以下の示す関係性がある。
即ち、証券口座の管理は複雑で、一般的にシステムの数が多くかつそれぞれが密に結合して作られているケースが多かった。これにより、証券口座管理に必須なバックオフィスシステムを中心としたラインナップが構築され、同一機能であっても他社サービスとの組み合わせが可能なことは稀な状況であった。
本サービスは、本サービスは投資一任運用を管理するシステムにおいて、個社バックオフィスシステム２との密結合を排除し、任意のシステムとの接続を可能とするポータビリティを有するものであると言える。
即ち、証券口座の管理は複雑で、一般的にシステムの数が多くかつそれぞれが密に結合して作られているケースが多かった。これにより、証券口座管理に必須なバックオフィスシステムを中心としたラインナップが構築され、同一機能であっても他社サービスとの組み合わせが可能なことは稀な状況であった。
本サービスは、本サービスは投資一任運用を管理するシステムにおいて、個社バックオフィスシステム２との密結合を排除し、任意のシステムとの接続を可能とするポータビリティを有するものであると言える。
【0162】
具体的には、本サービスには、高いポータビリティ性能を実現するための工夫として、以下の３つのポイントが導入されている。
即ち、第１に、本サービスが持つデータへの副作用は全てコマンドを起因としている。具体的には例えば、コマンドが生成された経路（＝生成主体）と副作用とが独立となっている。
また、第２に、コマンドの生成経路を個社バックオフィスシステム２、バーチャル口座管理部５１のどちらでも可能なよう切り替えを可能としている。
具体的には例えば、個社バックオフィスシステム２の作りに合わせて、個社側仕様の取り込みとバーチャル口座管理部５１の仕様での計算、個社仕様のレプリケーションなど、様々な方法が選択可能となった。
第３に、個社バックオフィスシステム２のデータからコマンドを生成する層が設けられている。
具体的には、各金融機関個社ＫＸの仕様の差異を吸収する層を設けることで、様々なバックオフィスシステムとのつなぎ込みを可能としている。
即ち、第１に、本サービスが持つデータへの副作用は全てコマンドを起因としている。具体的には例えば、コマンドが生成された経路（＝生成主体）と副作用とが独立となっている。
また、第２に、コマンドの生成経路を個社バックオフィスシステム２、バーチャル口座管理部５１のどちらでも可能なよう切り替えを可能としている。
具体的には例えば、個社バックオフィスシステム２の作りに合わせて、個社側仕様の取り込みとバーチャル口座管理部５１の仕様での計算、個社仕様のレプリケーションなど、様々な方法が選択可能となった。
第３に、個社バックオフィスシステム２のデータからコマンドを生成する層が設けられている。
具体的には、各金融機関個社ＫＸの仕様の差異を吸収する層を設けることで、様々なバックオフィスシステムとのつなぎ込みを可能としている。
【0163】
図４６は、投資一任契約の締結および付随する機能のプラグイン化を示す図である。
【0164】
ここで、図４６の説明に用いる各用語について補足説明する。
コンポーネントとは、本サービスのうち、契約の締結から解約、削除までの投資一任契約管理機能を提供するものである。
個社とは、本サービスを導入する第一種金融商品取引業社や登録金融機関のことをいう。
エンドユーザＭとは、投資一任契約を締結し資産の運用を一任する、個人または法人をいう。
投資一任契約のライフサイクル、契約ライフサイクルとは、個社による投資一任契約の締結の代理から始まり、契約内容変更時の差分同意や解約および解約後のデータ削除までの契約に係る一連の流れをいう。
コンポーネントとは、本サービスのうち、契約の締結から解約、削除までの投資一任契約管理機能を提供するものである。
個社とは、本サービスを導入する第一種金融商品取引業社や登録金融機関のことをいう。
エンドユーザＭとは、投資一任契約を締結し資産の運用を一任する、個人または法人をいう。
投資一任契約のライフサイクル、契約ライフサイクルとは、個社による投資一任契約の締結の代理から始まり、契約内容変更時の差分同意や解約および解約後のデータ削除までの契約に係る一連の流れをいう。
【0165】
これにより、以下の示す効果を奏する。
即ち、これまでの投資一任契約の締結および付随する機能を提供するシステムは、オンラインと対面のどちらの形式のサービスであっても販売画面と密に依存するものであり、契約ライフサイクルに係る機能を任意の販売画面に提供できる形式のものは存在していなかった。
しかしながら、本サービスにより、契約ライフサイクルに係る機能を販売画面から分離、任意の販売画面への組み込みが可能となった。
即ち、これまでの投資一任契約の締結および付随する機能を提供するシステムは、オンラインと対面のどちらの形式のサービスであっても販売画面と密に依存するものであり、契約ライフサイクルに係る機能を任意の販売画面に提供できる形式のものは存在していなかった。
しかしながら、本サービスにより、契約ライフサイクルに係る機能を販売画面から分離、任意の販売画面への組み込みが可能となった。
【0166】
具体的には、本サービスには、契約ライフサイクルに係る機能を販売画面から分離、任意の販売画面への組み込みを可能とするため、以下の３つのポイントが導入されている。
即ち、第１に、投資一任契約のライフサイクルに係るサイト作成機能の分離がなされている。具体的には、金融機関個社ＫＸは注文、コンポーネントは契約ライフサイクルとそれぞれの責務を担うことが可能となった。
第２に、個社サイトおよびコンポーネントサイト間の遷移を転送方式としている。具体的には、コンポーネントがホスティングを担うことで、運用の独立性からのポータビリティの向上がなされている。
第３に、投資一任契約のライフサイクルに係るデータ保管機能が分離されている。具体的には、コンポーネントが保管し金融機関個社が参照するというそれぞれの責務を担うことが可能になった。
即ち、第１に、投資一任契約のライフサイクルに係るサイト作成機能の分離がなされている。具体的には、金融機関個社ＫＸは注文、コンポーネントは契約ライフサイクルとそれぞれの責務を担うことが可能となった。
第２に、個社サイトおよびコンポーネントサイト間の遷移を転送方式としている。具体的には、コンポーネントがホスティングを担うことで、運用の独立性からのポータビリティの向上がなされている。
第３に、投資一任契約のライフサイクルに係るデータ保管機能が分離されている。具体的には、コンポーネントが保管し金融機関個社が参照するというそれぞれの責務を担うことが可能になった。
【0167】
図４７は、書面の電子交付の接続方式の例を示す図である。
即ち、図４７に示すように、エンドユーザＭが交付書面の表示をリクエストした場合、認証認可後にリクエストされた交付書面のデータを連携し、リクエストされた書面が表示される。この時、コンポーネントにおいて、投資一任契約に関する書面の補完機能が提供される。
即ち、図４７に示すように、エンドユーザＭが交付書面の表示をリクエストした場合、認証認可後にリクエストされた交付書面のデータを連携し、リクエストされた書面が表示される。この時、コンポーネントにおいて、投資一任契約に関する書面の補完機能が提供される。
【0168】
また、図７に示すハードウェア構成は、本発明の目的を達成するための例示に過ぎず、特に限定されない。
【0169】
また、図８及び図２２に示す機能ブロック図は、例示に過ぎず、特に限定されない。即ち、上述した一連の処理を全体として実行できる機能が情報処理システムに備えられていれば足り、この機能を実現するためにどのような機能ブロックを用いるのかは、特に図８及び図２２の例に限定されない。
【0170】
また、機能ブロックの存在場所も、図８及び図２２に限定されず、任意でよい。
また、１つの機能ブロックは、ハードウェア単体で構成してもよいし、ソフトウェア単体で構成してもよいし、それらの組み合わせで構成してもよい。
また、１つの機能ブロックは、ハードウェア単体で構成してもよいし、ソフトウェア単体で構成してもよいし、それらの組み合わせで構成してもよい。
【0171】
各機能ブロックの処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが、コンピュータ等にネットワークや記録媒体からインストールされる。
コンピュータは、専用のハードウェアに組み込まれているコンピュータであってもよい。また、コンピュータは、各種のプログラムをインストールすることで、各種の機能を実行することが可能なコンピュータ、例えばサーバの他汎用のスマートフォンやパーソナルコンピュータであってもよい。
コンピュータは、専用のハードウェアに組み込まれているコンピュータであってもよい。また、コンピュータは、各種のプログラムをインストールすることで、各種の機能を実行することが可能なコンピュータ、例えばサーバの他汎用のスマートフォンやパーソナルコンピュータであってもよい。
【0172】
このようなプログラムを含む記録媒体は、各ユーザにプログラムを提供するために装置本体とは別に配布される、リムーバブルメディアにより構成されるだけではなく、装置本体に予め組み込まれた状態で各ユーザに提供される記録媒体等で構成される。
【0173】
なお、本明細書において、記録媒体に記録されるプログラムを記述するステップは、その順序に添って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的或いは個別に実行される処理をも含むものである。
【0174】
また、本明細書において、システムの用語は、複数の装置や複数の手段等より構成される全体的な装置を意味するものである。
【0175】
以上まとめると、本発明が適用される情報処理装置は、次のような構成を取れば足り、各種各様な実施形態を取ることができる。
【0176】
即ち、本発明が適用される情報処理装置（例えば、図８のサービス提供者サーバ１）は、
所定対象を管理する管理者の装置のうち、所定対象が管理される管理単位において、第１種管理単位と第２種管理単位とを区別管理している別情報処理装置と少なくとも通信をする情報処理装置であって、
前記第１種管理単位の枠内で運営されるＮ個（Ｎは、１以上の整数値）のサービスの夫々に対して、前記情報処理装置内における前記第１種管理単位が前記Ｎ個に区分された結果得られる前記Ｎ個の個別単位の夫々を対応付けて、当該Ｎ個の当該個別単位を管理する処理を実行する個別単位管理手段（例えば、図８のバーチャル口座管理部５１）
を備えれば足りる。
所定対象を管理する管理者の装置のうち、所定対象が管理される管理単位において、第１種管理単位と第２種管理単位とを区別管理している別情報処理装置と少なくとも通信をする情報処理装置であって、
前記第１種管理単位の枠内で運営されるＮ個（Ｎは、１以上の整数値）のサービスの夫々に対して、前記情報処理装置内における前記第１種管理単位が前記Ｎ個に区分された結果得られる前記Ｎ個の個別単位の夫々を対応付けて、当該Ｎ個の当該個別単位を管理する処理を実行する個別単位管理手段（例えば、図８のバーチャル口座管理部５１）
を備えれば足りる。
【0177】
これにより、任意の数のファンド口座開設と運用サービスの紐付けが可能になる。また、任意の数のファンド口座の開設と運用が可能になる。
【0178】
さらに、
前記所定対象は資産であり、
前記管理単位は、エンドユーザの取引口座であり、
前記第１種管理単位は、前記エンドユーザの投資一任契約管理下の資産である一任資産であり、
前記第２種管理単位は、エンドユーザの当該投資一任契約管理外の資産である非一任資産であり、
前記サービスは、運用サービスであり、
前記個別単位は、バーチャル口座であり、
前記個別単位管理手段は、
前記一任資産の枠内で運営される前記Ｎ個の前記運用サービスの夫々に対して、前記情報処理装置内における前記一任資産が前記Ｎ個に区分された結果得られる前記Ｎ個の前記バーチャル口座の夫々を対応付け、当該Ｎ個の当該バーチャル口座を管理する、
ことができる。
前記所定対象は資産であり、
前記管理単位は、エンドユーザの取引口座であり、
前記第１種管理単位は、前記エンドユーザの投資一任契約管理下の資産である一任資産であり、
前記第２種管理単位は、エンドユーザの当該投資一任契約管理外の資産である非一任資産であり、
前記サービスは、運用サービスであり、
前記個別単位は、バーチャル口座であり、
前記個別単位管理手段は、
前記一任資産の枠内で運営される前記Ｎ個の前記運用サービスの夫々に対して、前記情報処理装置内における前記一任資産が前記Ｎ個に区分された結果得られる前記Ｎ個の前記バーチャル口座の夫々を対応付け、当該Ｎ個の当該バーチャル口座を管理する、
ことができる。
【0179】
さらに、
前記個別単位管理手段は、
前記バックオフィスシステムで発生した前記エンドユーザの前記一任資産に関わる全てのトランザクションの処理を実行することで、前記バックオフィスシステム内の前記一任資産と前記情報処理装置内の前記一任資産の一致の状態を維持するように管理する一任資産一致管理手段（例えば、図８の一任資産一致管理部６１）と、
前記一致の状態を前提として、前記Ｎ個の運用サービス毎に、夫々対応付けられた前記バーチャル口座を用いたトランザクションの処理を実行することで、前記Ｎ個のバーチャル口座を管理する個別単位管理手段（例えば、図８の個別管理部６２）と、
を有することができる。
前記個別単位管理手段は、
前記バックオフィスシステムで発生した前記エンドユーザの前記一任資産に関わる全てのトランザクションの処理を実行することで、前記バックオフィスシステム内の前記一任資産と前記情報処理装置内の前記一任資産の一致の状態を維持するように管理する一任資産一致管理手段（例えば、図８の一任資産一致管理部６１）と、
前記一致の状態を前提として、前記Ｎ個の運用サービス毎に、夫々対応付けられた前記バーチャル口座を用いたトランザクションの処理を実行することで、前記Ｎ個のバーチャル口座を管理する個別単位管理手段（例えば、図８の個別管理部６２）と、
を有することができる。
【0180】
さらに、前記個別単位管理手段は、
前記Ｎ個の運用サービスのうち所定運用サービスについての前記トランザクションの処理として、前記エンドユーザの操作に基づくトランザクションの処理を実行するエンドユーザトランザクション実行手段（例えば、図８のエンドユーザトランザクション実行部７１）と、
所定運用サービスについての前記トランザクションの処理として、前記バックオフィスシステムで発生した前記トランザクションのうち前記所定運用サービスに係るトランザクションの処理を実行するバックオフィス発生トランザクション実行手段（例えば、図８のバックオフィス発生トランザクション実行部７２）と、
を含むことができる。
前記Ｎ個の運用サービスのうち所定運用サービスについての前記トランザクションの処理として、前記エンドユーザの操作に基づくトランザクションの処理を実行するエンドユーザトランザクション実行手段（例えば、図８のエンドユーザトランザクション実行部７１）と、
所定運用サービスについての前記トランザクションの処理として、前記バックオフィスシステムで発生した前記トランザクションのうち前記所定運用サービスに係るトランザクションの処理を実行するバックオフィス発生トランザクション実行手段（例えば、図８のバックオフィス発生トランザクション実行部７２）と、
を含むことができる。
【0181】
また、本発明が適用される情報処理装置（例えば、図２２のサービス提供者サーバ１）は、
自身の資産を用いてＮ個（Ｎは、１以上の整数値）の運用サービスの提供を受けるエンドユーザにより管理されるエンドユーザ装置（例えば、図２１のエンドユーザ端末４）と、
前記エンドユーザの資産を所定の管理単位で管理する資産管理者により管理される資産管理者装置（例えば、図２１の個社バックオフィスシステム２）と、
前記エンドユーザと契約をすることにより、前記Ｎ個の運用サービスのうち少なくとも一部の運用を行うＭ（Ｍは、１以上の整数値）の運用者の夫々により管理される前記Ｍの運用者装置（例えば、図２１の投資運用業者端末５）と、
夫々通信をする情報処理装置であって、
前記エンドユーザについて、前記管理単位の枠内で運営される前記Ｎ個の運用サービスの夫々に対して、前記情報処理装置内における前記管理単位が前記Ｎ個に区分された結果得られる前記Ｎ個の個別単位の夫々を対応付けて、当該Ｎ個の当該個別単位を管理する処理を実行する個別単位管理手段（例えば、図２２のバーチャル口座管理部５１）を備え、
前記個別単位管理手段は、
所定運用サービスについての前記エンドユーザと前記運用管理者との前記契約の状態を示す契約状態データを含む当該所定運用サービスに紐づくデータを運用サービスデータとして、当該運用サービスデータと、当該所定運用サービスを識別可能な運用サービス識別子と、当該所定運用サービスに対応付けられた前記個別単位とを紐付けて、前記Ｎ個の運用サービス毎に管理する運用サービス管理手段（例えば、図２２の運用サービス管理部６６）と、
前記所定運用サービスの前記契約の締結時、契約中、又は解約時における、前記エンドユーザ又は前記運用者が利用するユーザインタフェースを、前記エンドユーザ装置又は前記運用者装置に対して提供するユーザインタフェース手段（例えば、図２２のユーザインタフェース制御部６３）と、
を含み、
前記個別単位管理手段は、前記エンドユーザ又は前記運用者の前記ユーザインタフェースを用いた前記所定運用サービスに対する操作に基づいて、当該所定運用サービス識別子に対応付けられた前記個別単位において、前記運用サービスデータを用いた処理を実行すれば足りる。
自身の資産を用いてＮ個（Ｎは、１以上の整数値）の運用サービスの提供を受けるエンドユーザにより管理されるエンドユーザ装置（例えば、図２１のエンドユーザ端末４）と、
前記エンドユーザの資産を所定の管理単位で管理する資産管理者により管理される資産管理者装置（例えば、図２１の個社バックオフィスシステム２）と、
前記エンドユーザと契約をすることにより、前記Ｎ個の運用サービスのうち少なくとも一部の運用を行うＭ（Ｍは、１以上の整数値）の運用者の夫々により管理される前記Ｍの運用者装置（例えば、図２１の投資運用業者端末５）と、
夫々通信をする情報処理装置であって、
前記エンドユーザについて、前記管理単位の枠内で運営される前記Ｎ個の運用サービスの夫々に対して、前記情報処理装置内における前記管理単位が前記Ｎ個に区分された結果得られる前記Ｎ個の個別単位の夫々を対応付けて、当該Ｎ個の当該個別単位を管理する処理を実行する個別単位管理手段（例えば、図２２のバーチャル口座管理部５１）を備え、
前記個別単位管理手段は、
所定運用サービスについての前記エンドユーザと前記運用管理者との前記契約の状態を示す契約状態データを含む当該所定運用サービスに紐づくデータを運用サービスデータとして、当該運用サービスデータと、当該所定運用サービスを識別可能な運用サービス識別子と、当該所定運用サービスに対応付けられた前記個別単位とを紐付けて、前記Ｎ個の運用サービス毎に管理する運用サービス管理手段（例えば、図２２の運用サービス管理部６６）と、
前記所定運用サービスの前記契約の締結時、契約中、又は解約時における、前記エンドユーザ又は前記運用者が利用するユーザインタフェースを、前記エンドユーザ装置又は前記運用者装置に対して提供するユーザインタフェース手段（例えば、図２２のユーザインタフェース制御部６３）と、
を含み、
前記個別単位管理手段は、前記エンドユーザ又は前記運用者の前記ユーザインタフェースを用いた前記所定運用サービスに対する操作に基づいて、当該所定運用サービス識別子に対応付けられた前記個別単位において、前記運用サービスデータを用いた処理を実行すれば足りる。
【0182】
これにより、バンドリングのハードルが解消され、複数の投資運用業者Ｔによる任意の数の運用サービスの提供が可能な状態となる。
【0183】
さらに、
前記個別単位管理手段は、
前記Ｎ個の運用サービスのうち、所定運用管理者が前記エンドユーザと前記契約を締結した１以上の運用サービスの夫々の前記運用サービス識別子と、当該所定運用者を識別可能な運用者識別子との対応付けを、前記Ｍの運用者毎に管理する運用者管理手段（例えば、図２２の投資運用業者管理部６７）と、
前記Ｍの運用者のうち前記所定運用者から前記ユーザインタフェースを用いた操作があった合、当該所定運用者の前記運用者識別子と対応付けられた１以上の前記運用サービス識別子の夫々により識別される前記１以上の運用サービスデータへのアクセスを許可するアクセス制御手段（例えば、図２２のアクセス制御部６４）と、
をさらに含み、
前記個別単位管理手段は、アクセスが許可された前記運用サービスデータを用いた処理を実行する、
ことができる。
前記個別単位管理手段は、
前記Ｎ個の運用サービスのうち、所定運用管理者が前記エンドユーザと前記契約を締結した１以上の運用サービスの夫々の前記運用サービス識別子と、当該所定運用者を識別可能な運用者識別子との対応付けを、前記Ｍの運用者毎に管理する運用者管理手段（例えば、図２２の投資運用業者管理部６７）と、
前記Ｍの運用者のうち前記所定運用者から前記ユーザインタフェースを用いた操作があった合、当該所定運用者の前記運用者識別子と対応付けられた１以上の前記運用サービス識別子の夫々により識別される前記１以上の運用サービスデータへのアクセスを許可するアクセス制御手段（例えば、図２２のアクセス制御部６４）と、
をさらに含み、
前記個別単位管理手段は、アクセスが許可された前記運用サービスデータを用いた処理を実行する、
ことができる。
【0184】
さらに、
前記個別単位管理手段は、
前記エンドユーザに紐づくデータをエンドユーザデータとして管理するエンドユーザ管理手段（例えば、図２２のエンドユーザ管理部６５）、
をさらに備え、
前記アクセス制御手段は、
前記Ｍの運用者のうち前記所定運用者から前記ユーザインタフェースを用いた操作があった場合、前記所定運用者が運用する前記Ｍの前記運用サービスの中に、前記エンドユーザと前記契約を締結した状態のものがあるか否かを判定し、あると判定したときには前記エンドユーザデータへのアクセスを許可する一方、ないと判定したときには前記エンドユーザデータへのアクセスを禁止する、
ことができる。
前記個別単位管理手段は、
前記エンドユーザに紐づくデータをエンドユーザデータとして管理するエンドユーザ管理手段（例えば、図２２のエンドユーザ管理部６５）、
をさらに備え、
前記アクセス制御手段は、
前記Ｍの運用者のうち前記所定運用者から前記ユーザインタフェースを用いた操作があった場合、前記所定運用者が運用する前記Ｍの前記運用サービスの中に、前記エンドユーザと前記契約を締結した状態のものがあるか否かを判定し、あると判定したときには前記エンドユーザデータへのアクセスを許可する一方、ないと判定したときには前記エンドユーザデータへのアクセスを禁止する、
ことができる。
【0185】
さらに、
Ｐ（Ｐは１以上の整数値）の前記資産運用者毎に、夫々専用の前記個別単位管理手段を備え、
所定運用者の前記運用者装置からアクセスの依頼があった場合に、当該所定運用者と紐づけられた１以上の前記資産管理者の夫々の専用の前記個別単位管理手段と、当該所定運用者の前記運用者装置との接続を行う接続手段（例えば、図３１のプロキシ部５２）
をさらに備えることができる。
Ｐ（Ｐは１以上の整数値）の前記資産運用者毎に、夫々専用の前記個別単位管理手段を備え、
所定運用者の前記運用者装置からアクセスの依頼があった場合に、当該所定運用者と紐づけられた１以上の前記資産管理者の夫々の専用の前記個別単位管理手段と、当該所定運用者の前記運用者装置との接続を行う接続手段（例えば、図３１のプロキシ部５２）
をさらに備えることができる。
【符号の説明】
【0186】
１・・・サービス提供者サーバ、２・・・個社バックオフィスシステム、３・・・個社運用サーバ、４・・・エンドユーザ端末、５・・・投資運用業者端末、１１・・・ＣＰＵ、２０・・・ドライブ、３１・・・リムーバブルメディア、５１，５１Ａ，５１Ｂ，５１Ｃ，５１ｎ・・・バーチャル口座管理部、５２・・・プロキシ部、６１・・・一任資産一致管理部、６２・・・個別管理部、６３・・・ユーザインタフェース制御部、６４・・・アクセス制御部、６５・・・エンドユーザ管理部、６６・・・運用サービス管理部、６７・・・投資運用業者管理部、７１・・・エンドユーザトランザクション実行部、７２・・・バックオフィス発生トランザクション実行部、７３・・・自身生成トランザクション実行部、８１・・・エンドユーザＤＢ、８２・・・運用サービスＤＢ、８３・・・投資運用業者ＤＢ
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】
【図25】
【図26】
【図27】
【図28】
【図29】
【図30】
【図31】
【図32】
【図33】
【図34】
【図35】
【図36】
【図37】
【図38】
【図39】
【図40】
【図41】
【図42】
【図43】
【図44】
【図45】
【図46】
【図47】