JP6826388B2 - 資産管理システム - Google Patents

Description

本発明は、資産管理の技術に関し、特に、被相続人となり得る者が行う相続等の資産移転に係る各種の処理を支援する資産管理システムに適用して有効な技術に関するものである。

ＩＴ技術の進展に伴い、例えば、ユーザの家計簿を生成・管理したり、銀行口座の情報を管理したりなど、個人の資産状況を管理する仕組みが提案されている。近年では、各ユーザが保有するスマートフォンなどの携帯端末を用いて手軽に情報の収集や閲覧を行う仕組みも提案されている。

例えば、特開２００１−３０６７９８号公報（特許文献１）には、デビットカードでの取引情報や金融機関の口座情報を含む収支情報をホストコンピュータから収集し、これに基づいて世帯の家計簿データを生成する家計簿データ作成システムに係る技術が記載されている。

また、特開２００５−３８１３０号公報（特許文献２）には、アグリゲーション用のＷｅｂサイトが、複数の金融機関の入出金明細を取得してまとめて表示することで、入出金明細を家計簿アプリケーションに一括して容易に取り込めるようにする技術が記載されている。

また、家計簿アプリケーションであるマネーフォワード（登録商標、非特許文献１）では、銀行や証券会社、クレジットカード会社等の複数の金融機関がそれぞれ提供するインターネットサービスと連携し、ユーザが保有する複数の口座やアカウントに係る情報を取得して自動的に家計簿を作成したり資産状況を確認したりすることができる。

一方、例えば、特開２０１５−１３２８８２号公報（特許文献３）には、相続税の試算の際に利用する家系図の作成において、ユーザから、法定相続人候補のアイコンや追加のアイコンの配置、配偶者や子の情報の入力等を受け付けることで操作性を向上させる技術が記載されている。

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

"全自動家計簿マネーフォワード"、［online］、株式会社マネーフォワード、［平成２８年６月１４日検索］、インターネット＜URL：https://moneyforward.com/＞

従来技術を利用することによって、主に個人が現在および将来における日々の生活を行うにあたって必要となる金融資産の把握・形成および管理を行うことができる。しかしながら、従来技術では、当該個人の金融資産としての管理にとどまる。したがって、例えば、主に相続を中心とした、当該個人の近親者等に対する余剰資産の分配やこれらの者の資産形成等、近親者や親族等の一定のグループにおける資産管理については全く考慮されていない。

そこで本発明の目的は、個人の金融資産の管理にとどまらず、相続を含む近親者等への資産の移転に係る各種の処理を支援する資産管理システムを提供することにある。

本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。

本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。

本発明の代表的な実施の形態による資産管理システムは、ユーザ端末を利用してネットワークを介して接続するユーザが保有する資産の管理を支援する資産管理システムであって、前記ユーザが保有する資産に係る情報を資産状況記録部に記録し、また、前記ユーザと他のユーザとの間の資産の移転に係る処理を行い、その内容を移転履歴記録部に記録する資産管理部と、前記ユーザが保有する資産につき、その少なくとも一部についての前記ユーザの生前もしくは死亡後における移転に係る処理を行う相続管理部と、を有する。

前記相続管理部は、さらに、第１のユーザの生前において、前記第１のユーザから所定の範囲の他の第２のユーザに対する生前贈与もしくは死因贈与の内容の登録を受け付けて、その内容を相続財産記録部に記録する贈与管理部と、前記第１のユーザの生前において、前記第１のユーザから遺言の内容の登録を受け付けて、その内容を遺言管理情報記録部に記録する遺言管理部と、前記第１のユーザの死亡後において、前記遺言管理情報記録部に記録された前記第１のユーザの遺言の内容を所定の範囲の前記第２のユーザに参照可能とし、前記第１のユーザが保有していた資産に係る前記第２のユーザへの移転に係る情報を受け付けて、その内容を前記相続財産記録部に記録する相続処理部と、を有し、前記資産管理部は、前記相続財産記録部に記録された資産の移転に係る内容が、移転の条件を充足している場合には、当該資産の移転に係る処理を行う。

本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下のとおりである。

すなわち、本発明の代表的な実施の形態によれば、個人の金融資産の管理にとどまらず、相続を含む近親者等への資産の移転に係る各種の処理を支援することが可能となる。

本発明の実施の形態１である資産管理システムの構成例について概要を示した図である。 本発明の実施の形態１における対象のユーザが生前において行う相続等に係る各種の処理を支援する流れの例について概要を示したフローチャートである。 本発明の実施の形態１における対象のユーザの死亡後において行う相続等に係る各種の処理を支援する流れの例について概要を示したフローチャートである。 （ａ）、（ｂ）は、本発明の実施の形態１におけるユーザＤＢのデータ構成の例について概要を示した図である。 本発明の実施の形態１における資産状況ＤＢのデータ構成の例について概要を示した図である。 本発明の実施の形態１における移転履歴ＤＢのデータ構成の例について概要を示した図である。 本発明の実施の形態１における相続財産ＤＢのデータ構成の例について概要を示した図である。 本発明の実施の形態１における遺言管理ＤＢのデータ構成の例について概要を示した図である。 （ａ）〜（ｄ）は、本発明の実施の形態２におけるユーザ端末に表示されるユーザインタフェースの例について概要を示した図である。 本発明の実施の形態２におけるユーザが家系図を作成する画面の例について概要を示した図である。 本発明の実施の形態２における資産管理の対象となる近親者が属する家系図情報を形成するためのデータ構成の例について概要を示した図である。 本発明の実施の形態２における近親者の情報に基づいて家系図情報を形成する処理の流れの例について概要を示した図である。 本発明の実施の形態２における近親者の情報に基づいて家系図情報を形成する処理の流れの例について概要を示した図である。 本発明の実施の形態２における家系図情報に基づいて近親者のグループとしてのバランスシートを表示する処理の流れの例について概要を示した図である。

以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一の符号を付し、その繰り返しの説明は省略する。一方で、ある図において符号を付して説明した部位について、他の図の説明の際に再度の図示はしないが同一の符号を付して言及する場合がある。

（実施の形態１）
＜システム構成＞
図１は、本発明の実施の形態１である資産管理システムの構成例について概要を示した図である。資産管理システム１は、例えば、サーバ機器やクラウドコンピューティングサービス上に構築された仮想サーバ等に実装された資産管理サーバにより構成される。この資産管理サーバ１０に対して、インターネット等のネットワーク２０を介して１つ以上のユーザ端末３０がクライアントとして接続される構成を有する。

資産管理サーバ１０は、ユーザ端末３０を介して、複数のユーザのそれぞれの資産管理および相続を含む近親者等への資産の移転に係る各種の処理を支援する機能を有するサーバシステムである。ここで、資産の移転に係る各種の処理には、相続人に対する相続としての資産の移転の他に、生前贈与、死因贈与、特定遺贈等、相続人以外に資産を移転することができる制度を含む。以下ではこれらの資産移転を広く「相続」と記載する場合がある。また、被相続人となり得る者から見て、（推定）相続人および相続人以外の資産を移転される可能性のある者を「近親者」と総称する場合がある。

資産管理サーバ１０は、例えば、図示しないＯＳ（Operating System）やＤＢＭＳ（DataBase Management System）、Ｗｅｂサーバプログラム等のミドルウェア上で稼働するソフトウェアとして実装されたユーザ管理部１１０、資産管理部１２０、相続管理部１３０、および外部サービスインタフェース（Ｉ／Ｆ）１４０などの各部を有する。これらのミドルウェアやソフトウェアを図示しないメモリ上に展開してＣＰＵ（Central Processing Unit）が実行することにより、後述するような各種機能やサービスを実現する。資産管理サーバ１０は、また、図示しないハードディスク等の記憶媒体上にデータベースやファイルテーブル等として実装されたユーザデータベース（ＤＢ）１５１、資産状況ＤＢ１５２、移転履歴ＤＢ１５３、相続財産ＤＢ１５４、および遺言管理ＤＢ１５５等の各データストアを有する。

ユーザ管理部１１０は、資産管理サーバ１０を利用して資産管理および相続等による資産の移転を行うユーザのアカウント情報を管理する機能を有する。具体的には、ユーザによりユーザ端末３０を介して登録されたアカウント情報をユーザＤＢ１５１に登録し、また、その参照や変更等の要求を受け付けて、ユーザＤＢ１５１に対して対応する処理を行う。本実施の形態では、被相続人となり得る者に限らず、これらの者からの資産移転の対象となる近親者の情報も可能な限り把握できていることが望ましい。したがって、本実施の形態では、推定相続人を含む近親者についても、アカウント情報の登録を行ってユーザとして資産管理システム１により資産管理を行うことができるものとする。あるユーザから見た近親者の情報は、例えば、対象のユーザを中心とした近親者のグループを構成することで管理することができる。

資産管理部１２０は、ユーザが保有する資産の状況を把握し、その管理を行うのに資する各種機能を提供する。例えば、従来技術のような一般的な資産管理・家計簿アプリケーションが有する機能と同様に、金融資産等の各種資産の状況を取得・収集して、資産状況ＤＢ１５２に登録する。また、これらの情報を適宜加工・集計等して、ユーザ端末３０を介して閲覧できるようにする。これらの情報を、自身以外の他のユーザ（親や配偶者、兄弟姉妹等、自身に対して被相続人もしくは相続人となり得る近親者等）にも閲覧可能なように開示するか否か等のアクセス制御をユーザが指定できるようにしてもよい。アクセス制御には、例えば、他のユーザへの開示を拒否する場合に、相続に係る処理においてシステムのみが参照することも拒否するか否かの指定や、他のユーザへ開示するとした場合の内容や範囲等の指定も含まれ得る。

なお、上記では、資産管理機能の例として一般的な資産管理・家計簿アプリケーションが有する機能と同様であるとしているが、あくまで一例であり、資産管理機能を提供することができるものであればどのような形態のものであってもよい。例えば、個人向けの銀行アプリケーションや証券アプリケーションが有する機能と同様のものであってもよい。また、これらのアプリケーション自体、さらにはＳＮＳ（Social Networking Service）やポータルサイトのメールシステム等の中に、本実施の形態の資産管理システム１における資産管理部１２０の機能が取り込まれ、もしくはこれらのサービスと連携して、本実施の形態における資産管理機能を提供する構成であってもよい。

状況を取得して管理の対象とする資産は、一般的な資産管理・家計簿アプリケーション等と同様な、預貯金や株式、年金、生命保険等の金融資産に限らず、例えば、不動産や、自動車、船舶、貴金属等の資産価値が高い動産も含む。また、住宅ローンや事業資金の融資等の債務や負債についてもマイナス資産として把握・管理する。相続の対象となり得るこれらの資産の特定、およびその資産状況の把握は、例えば、銀行等の金融機関や他の各種の事業者等が外部に公開・提供する情報処理システムやＷｅｂサイト等（図中では外部サービス４０として示す）から、外部サービスインタフェース（Ｉ／Ｆ）１４０を介して自動的に取得する。

例えば、定期的に、もしくは指示を受けて随時に、外部サービス４０のＷｅｂサイトからいわゆるＷｅｂスクレイピング技術等を利用して、ユーザの資産に係る情報を抽出・収集する。外部サービス４０の情報処理システムが外部に公開しているＡＰＩ（Application Programming Interface）をコールして情報を抽出・収集してもよい。自動的に取得・収集された資産を候補としてユーザ端末３０を介してユーザに提示し、候補の中からユーザが管理対象とする資産を取捨選択するようにしてもよい。また、自動的に把握できなかった資産についてはユーザが手動で入力してもよい。これにより、例えば、金融機関に保持している金融資産の情報を把握することができる。また、振込履歴や税金の支払い状況等の入出金の履歴に係る情報を参照・分析することで、例えば、仕向先や金額等の情報から、管理対象となり得る不動産や動産の存在を把握することも可能である。

資産管理部１２０は、他の各種の機能を実現するためさらに、資産移転部１２１、資産評価部１２２、予測処理部１２３等の各部を有する。

資産移転部１２１は、被相続人となるユーザから近親者に対する実際の資産の移転に係る処理を行う。近親者には、資産管理システム１のユーザである近親者だけでなく、アカウント登録を有さない近親者を含んでいてもよい。資産の移転は、対象のユーザの生前もしくは死亡後のいずれでも可能である。対象ユーザの生前には、例えば、不動産等の生前贈与など、相続の前倒しとしての資産移転に加えて、事業資金や結婚資金、住宅購入資金の援助等、相続としてではないが実際の相続時には考慮され得る資産移転が行われ得る。また、対象ユーザの死亡後には、後述する相続管理部１３０により確定された相続内容の実行としての資産移転が行われ得る。

資産移転部１２１は、例えば、資産状況ＤＢ１５２上において、対象のユーザのアカウントから対象の近親者のアカウントに対して移転対象の資産を移転させる機能を有する。例えば、資産移転部１２１が自動的に判断し、もしくはユーザから指示された資産移転につき、その移転の内容に基づいて、外部サービスＩ／Ｆ１４０を利用して、金融機関等の外部サービス４０に対して資産移転の内容を反映させるようにしてもよい。例えば、銀行口座間での送金や、不動産登記の移転（もしくは登録動産の名義変更）等を行うことができる。

金銭や動産の譲渡等、システム外で現実に行われた資産移転については、当該資産移転の結果の入力をユーザから受け付けて、その内容を資産状況ＤＢ１５２等に反映させるようにしてもよい。なお、実行した資産移転（特に生前のもの）の内容は、移転履歴ＤＢ１５３に、移転の理由（例えば、「結婚資金」や「事業資金」等）を付して記録しておく。また、例えば、契約書や登記移転の際の書類等、資産移転が実際に行われた際に発生した書類をスキャンしたデータ等を、証跡データとして記録するようにしてもよい。対象のユーザが死亡した後、これらの記録を参照することで、生前の資産の移転に係る無用な争いを防止することができる。

資産評価部１２２は、資産状況ＤＢ１５２への資産の登録や、資産移転部１２１による資産移転に際して、金銭以外の資産について金銭的評価を行う機能を有する。例えば、外部サービスＩ／Ｆ１４０を介して、金融資産の現在・将来の価値を評価するようなサービスを提供する外部サービス４０にアクセスし、評価結果を取得することができる。また、不動産や動産についての中古品市場を提供する外部サービス４０にアクセスし、同一物件や製品等に係る価格相場から金銭的評価を行うことも可能である。また、現在の資産内容をデータファイルやＰＤＦ（Portable Document Format）ファイル等に出力し、専門家宛に電子メールで送信して評価を受けることも可能である。

予測処理部１２３は、対象のユーザが死亡すると予想される時期までに必要となる生活資金等の必要費をシミュレーション等により予測する機能を有する。例えば、最も単純な予測モデルとして、対象ユーザの現在の年齢と性別毎の平均寿命から余命の長さを算出し、現在の単位期間あたりの必要費が余命の間継続すると仮定してこれを乗算し、さらに所望の余裕率を掛け合わせて算出することができる。これに対してさらに、例えば、退職までの給与収入やその後の年金収入、金融収入、医療費、住居費、教育費等、生活環境の変化に伴う収入と支出の将来予想、さらには居住地域の特性等を考慮して補正することができる。当該補正については、例えば、予め定めた所定のモデルを自動的に適用してもよいし、ユーザがモデルや予想値等を直接指定・入力するようにしてもよい。外部サービスＩ／Ｆ１４０を介して外部の専門家に問い合わせてもよい。

また、予測処理部１２３は、保有する資産についても、死亡予想時期における予想評価額をそれぞれ算出する。これについても、予め定めた所定のモデルを自動的に適用して算出してもよいし、ユーザが予想評価額を直接指定・入力するようにしてもよい。外部サービスＩ／Ｆ１４０を介して外部の専門家に問い合わせてもよい。得られた死亡予想時期における全資産の予想評価額の合計から、死亡予想時期までの必要費の総額を減算したものが、相続により近親者に移転させることが可能な資産の総額と仮定される。ユーザはこの移転可能資産総額を参考に、相続等による資産移転を設計・管理することができる。

相続管理部１３０は、対象ユーザの資産について、相続による資産移転の設計・管理および実行に資する各種機能を提供する。すなわち、対象ユーザの生前には、例えば、資産管理部１２０によって予測された移転可能資産総額の範囲内で、ユーザによる生前贈与を利用した資産移転の設計・管理や、その実行を支援する。また、遺言の作成による資産移転の設計、および遺言の管理を支援する。対象ユーザの死亡後には、相続人や遺言執行者による遺産や遺言の把握・管理、さらには遺言もしくは遺産分割による資産移転の設計・管理や、その実行を支援する。

相続管理部１３０は、上記の機能を実現するためさらに、贈与管理部１３１、遺言管理部１３２、相続処理部１３３等の各部を有する。

贈与管理部１３１は、近親者への贈与により資産移転を行う対象となる資産の登録・管理を行う機能を有する。例えば、ユーザ端末３０を介した対象ユーザからの指示により、資産状況ＤＢ１５２に登録されている資産の中から、生前贈与もしくは死因贈与の契約の成立により贈与対象となった資産とその内容を特定して、相続財産ＤＢ１５４に登録する。なお、本実施の形態において、贈与には、無負担の贈与の他に負担付贈与も含まれるものとする。また、その全部もしくは一部を低利もしくは無利息での貸与とする場合も含まれる。

生前贈与の場合は、対象ユーザからの指示により、もしくは指定された条件の成就を契機として、資産管理部１２０の資産移転部１２１を介して対象の資産が対象の近親者に贈与される。死因贈与の場合は、対象ユーザの死亡により、もしくは死亡後における指定された条件の成就を契機として、資産管理部１２０の資産移転部１２１を介して対象の資産が対象の近親者に贈与される。生前か死亡後かに関わらず、指定された条件の成就が契機となる場合、当該条件の内容に応じて、資産管理システム１が自動で検知することができる条件の場合は、これを検知した際に自動的に資産移転部１２１による贈与等の処理を行うことができる。自動で検知できない条件の場合も含めて、条件が成就したことを検知したユーザが、ユーザ端末３０を介してその旨を入力することにより検知するようにしてもよい。

どの資産を誰にどれだけ贈与するか、生前贈与した方がよいのか死因贈与もしくは遺贈とした方がよいのか等の判断をユーザが行うのに資する参考情報として、本実施の形態では、贈与税・相続税のシミュレーションを行う機能も有しているのが望ましい。贈与管理部１３１自身が、指定された資産についての贈与税・相続税を計算する手段を直接有していてもよい。もしくは、外部サービスＩ／Ｆ１４０を介して、シミュレーションサービスを提供する外部サービス４０にアクセスし、シミュレーション結果を取得する構成であってもよい。

また、贈与税・相続税のシミュレーションのみに限らず、例えば、贈与等による資産移転の金額や相手方の近親者自体の妥当性について評価・判定する機能を有していてもよい。例えば、移転可能資産総額の範囲内での贈与であっても、相手方である近親者の資産状況によっては贈与が不要・過剰である場合もあり得る。また、相手方である近親者の資産状況自体は対象のユーザからの贈与を必要とする状況であっても、そのような状況に至った経緯が無計画な浪費によるものであった場合等、贈与が不適切となる場合もあり得る。

資産移転を行おうとするユーザがその妥当性について評価・判定する際に、相手方である近親者のユーザが、資産状況の開示を許容している場合は、対象のユーザは、相手方である近親者のユーザの資産状況を参照することで、ある程度の判断を独自に行うことができる。一方で、相手方である近親者の資産状況を参照できたとしても、対象のユーザの知識等によっては客観的な妥当性の判断が難しい場合もあり得る。また、相手方である近親者を含む近親者グループの一部もしくは全部のユーザが資産状況の開示を拒否しており、その資産状況を参照することができない場合も、当該近親者に対して資産移転することの妥当性や、他のより適切な相手先の有無の判断が難しい場合がある。

そこで本実施の形態では、近親者グループに属する他の近親者のユーザが、自身に対する資産状況の開示を許容していない場合であっても、贈与管理部１３１等が資産状況ＤＢ１５２や移転履歴ＤＢ１５３等をシステム的に参照して、他の近親者のユーザの現在の資産状況や過去の資産移転の履歴等を総合的に判断するようにしてもよい。そして、当該近親者に対する資産移転の妥当性を評価・判定し、その結果を一意見やアドバイスとして対象のユーザに提示するようにしてもよい。

単純なモデルでは、例えば、相手方である近親者が住宅等を購入予定である場合に、その支出予定金額と現在の保有資産の金額との差分に基づいて必要額を評価し、必要額より多額の贈与を不要（もしくは減額する）と判定することができる。また、相手方である近親者の現在の保有資産の金額が少ない場合に、例えば、一般的な家計簿分析サービス等において行われているような消費行動履歴の分析を行い、無用な浪費が多いと判断される場合には、贈与を不要（もしくは減額する）と判定してもよい。

対象のユーザによる上記のような資産移転の妥当性等の検討は、対象のユーザが能動的に資産管理システム１にアクセスして行ってもよい。もしくは、近親者が資産の移転を明示的／黙示的に希望している状況を資産管理システム１が検知して、対象のユーザに検討を促す通知等を行い、これを契機として対象のユーザが行うようにしてもよい。

近親者が資産移転を希望している状況の検知は、例えば、当該近親者が住宅の購入や事業の開始等に際して資金の提供を必要とする旨を資産管理システム１にアクセスして入力し、これを資産管理システム１が検知するようにしてもよい。当該近親者が資金の提供を必要とする旨を入力する際、依頼先の候補となる１人以上のユーザ（例えば、自身に対する被相続人となり得るユーザ）を指定できるようにしてもよい。その際、当該近親者が、自身に対する被相続人となり得るユーザの資産状況を参照できるようにしてもよい。当該近親者の入力や指示によるのではなく、例えば、当該近親者が住宅の購入に関連する銀行取引や、各種シミュレーション等を行ったことを資産管理部１２０等により検知して、資金の提供を必要としている状況であることを自動的に判断するようにしてもよい。

遺言管理部１３２は、ユーザの生前における遺言の作成とその管理を支援する機能を有する。対象のユーザは、資産管理部１２０によって予測された移転可能資産総額や資産状況ＤＢ１５２に記録された個々の資産の内容を、ユーザ端末３０を介して参照しつつ、どの資産を誰にどれだけ移転させるかを決定し、遺言として登録することができる。ユーザが遺言を作成するにあたり、上述した贈与管理部１３１が有するような贈与税・相続税のシミュレーション機能や、個別の資産移転の妥当性評価機能を利用できるようにしてもよい。

例えば、遺言の内容として、法定相続分に従った場合をデフォルトとしつつ、資産移転の複数のパターン毎に贈与税・相続税の差分を算出して提示するのが望ましい。例えば、ユーザが任意に設定した資産移転のパターン間の比較に加えて、これらと、法定相続分に従った場合のデフォルトの資産移転のパターンとの間での比較も行うことも可能とする。なお、ユーザが任意に資産移転のパターンを設定する際は、例えば、法定相続分に従ったデフォルトの資産移転のパターンをベースに、ユーザがこれを修正して設定できるようにする。

また、資産移転のパターンを設計するにあたり、遺言管理部１３２が、各種のデータを斟酌して所定の条件により重み付け等の最適化を行い、各推定相続人の遺留分等も計算して考慮しつつ、１つ以上の候補パターン案を作成して提示するようにしてもよい。また、選択された候補パターンをベースに対象のユーザからの修正を受け付け、これに対して再計算した贈与税・相続税を提示することで、資産移転の内容を漸次改善することができるようにしてもよい。

斟酌するデータとしては、例えば、対象のユーザの生前における各近親者との間の資産移転の額や時期、およびその理由、各近親者が現在保有している資産の額や内容、各近親者の年齢や家族構成、職業、居住地等の情報が含まれ得る。対象のユーザとの同居や介護等の有無の情報を登録しておくことにより、これらの情報を斟酌することもできる（例えば、同居の近親者には現住する不動産を優先的に移転する等）。対象のユーザの資産内容をデータファイルやＰＤＦファイル等に出力し、専門家宛に電子メールで送信してアドバイスを受けることも可能である。

なお、上述の贈与も含めて、資産移転の対象とする近親者として、対象のユーザに対して資産状況を開示している近親者のみを対象とできるようにしてもよい（すなわち、資産状況を開示しない近親者は、例えば相続放棄したものと同様に取り扱う）。

登録された遺言は遺言管理ＤＢ１５５に記録される。また、ユーザは、生存中は遺言管理ＤＢ１５５に登録された遺言の内容を随時変更することができる。登録された遺言については、その内容を近親者が自由に参照できるようにしてもよいし、少なくとも一部の近親者については秘密として参照できないようにアクセス制御を行ってもよい。この場合、例えば、誰にどこまで開示するかを個別に設定し、その内容を遺言管理ＤＢ１５５に併せて登録できるようにする。推定相続人となる一部もしくは全ての近親者が遺言の内容を全て参照できるようにしてもよいし、相続全体に係る内容のみを参照できるようにしてもよい。各推定相続人が、自身の相続内容に係る部分のみ参照できるように制限してもよい。

また、対象のユーザが遺言内容を登録するに際して、自由意志に基づいて任意に内容を登録したことを証明できるような手段を設けてもよい。例えば、自由意思を証明するための認証情報として、遺言入力時の本人の映像や音声を、ユーザ端末３０が備える図示しないカメラやマイクにより録画・録音し、そのデータを遺言内容と併せて遺言管理ＤＢ１５５に登録しておくようにしてもよい。また、心拍数等、遺言時の精神状態を推認することができる生体情報を図示しないセンサ等により取得して登録しておいてもよい。また、手書きによる署名の画像データを、ユーザ端末３０が備えるタッチパネルでの手書き入力や、カメラでの撮影等により取得して登録しておいてもよい。また、立会人や証人の証明情報を登録できるようにしてもよい。

さらに、遺言内容を書面として印刷もしくはＰＤＦファイルにより出力し、公正証書遺言の基礎としてもよいし、可能な場合には、例えば、署名および／または捺印することでそのまま遺言として取り扱うようにしてもよい。また、可能な場合には、遺言管理ＤＢ１５５に登録された内容をそのまま遺言として取り扱うようにしてもよい。

相続処理部１３３は、対象のユーザの死亡後において、相続人もしくは遺言執行者等による相続に係る処理を支援する機能を有する。相続開始の契機となる対象のユーザの死亡という事象は、例えば、その旨の情報を相続人等がユーザ端末３０を介して指定することで検知することができる。もしくは、外部サービスＩ／Ｆ１４０を介して役所や医療機関、介護施設等のシステムから自動的に取得することで検知することも技術的には可能である。

遺言管理ＤＢ１５５に対象のユーザの遺言が登録されている場合は、例えば、資産管理部１２０の資産移転部１２１を介して、遺言内容に沿った資産移転を自動的に行うようにしてもよい。もしくは、遺言内容を相続人等に参照可能とし、システム外で手動により資産移転を行わせるようにして、その結果についてのみ入力を受け付けて履歴として移転履歴ＤＢ１５３等に記録するようにしてもよい。

また、対象のユーザの全部もしくは一部の資産について遺言による指定がされていない（遺言が登録されていない）場合には、相続人等から遺産分割協議等の結果の入力を受け付けて、その内容に沿った資産移転を自動的に行うようにしてもよい。もしくは、遺産分割協議等の結果に基づいてシステム外で手動により行われた資産移転の結果についてのみ入力を受け付けて、履歴として移転履歴ＤＢ１５３等に記録するようにしてもよい。

また、相続人が遺産分割協議を行うのに資する情報として、例えば、対象のユーザ（被相続人）の資産状況に係る情報を資産状況ＤＢ１５２から取得して提示するようにしてもよい。また、相続人が限定承認や相続放棄をした旨の入力を受け付けて、相続に係る自動処理もしくは相続人への情報提供の内容に反映させるようにしてもよい。また、遺産分割協議を行う前提として、対象のユーザが死亡して相続が開始した旨や、遺産分割協議を行うべき旨等を、近親者のユーザに通知するようにしてもよい。

また、どの資産を誰にどれだけ割り当てるかの判断を相続人が行うのに資する参考情報を提供するため、上記の贈与管理部１３１や遺言管理部１３２と同様に、贈与税・相続税のシミュレーションを行う機能や、個別の資産移転の妥当性評価機能を有しているのが望ましい。

この場合、例えば、法定相続分に従った場合をデフォルトとしつつ、遺産分割の複数のパターン毎に贈与税・相続税の差分を算出して提示するのが望ましい。また、遺産分割のパターンを設計するにあたり、相続処理部１３３が、各種のデータを斟酌して所定の条件により重み付け等の最適化を行い、各相続人の遺留分等も計算して考慮しつつ、１つ以上の候補パターン案を作成して提示するようにしてもよい。また、選択された候補パターンをベースに対象のユーザからの修正を受け付け、これに対して再計算した相続税を提示することで、遺産分割の内容を漸次改善することができるようにしてもよい。

斟酌するデータとしては、例えば、被相続人の生前における相続人との間の資産移転の額や時期、およびその理由、各相続人が現在保有している資産の額や内容、各相続人の年齢や家族構成、職業、居住地等の情報が含まれ得る。被相続人との同居や介護等の有無の情報を登録しておくことにより、これらの情報を斟酌することもできる。対象のユーザ（被相続人）の資産内容をデータファイルやＰＤＦファイル等に出力し、専門家宛に電子メールで送信してアドバイスを受けることも可能である。

ユーザ端末３０は、資産管理システム１により提供される資産管理サービスを利用するユーザが使用する情報処理端末であり、例えば、ＰＣ（Personal Computer）やタブレット端末、スマートフォン等の汎用の情報処理端末を利用することができる。情報処理機能を有する機器であれば特にこれらの情報処理端末に限定されず、テレビ等の家電であってもよい。本実施の形態では、相続等による資産移転を対象として含むことから、一般的なサービスと比較してユーザにおける高齢者の比率が高くなるものと考えられる。したがって、ユーザがその場で移動することなく、適時かつ容易に贈与や遺言の作成等の資産移転に係る処理や操作を行うことができるよう、タブレット端末やスマートフォン等の携帯端末によるタッチ操作での利用が主に想定される。

ユーザは、ユーザ端末３０に導入した図示しないクライアントアプリケーションやＷｅｂブラウザ等のソフトウェアを利用して、ネットワーク２０を介して資産管理サーバ１０の各部の機能にアクセスする。そして、ユーザがアプリケーション等を操作するインタフェースとしては、キーボードやマウス等の入力デバイスに加えて、タッチパネルによる操作や、マイクを介した音声認識による操作も含むことができる。上述したように、カメラ機能により撮影されたユーザの映像を入力データとすることもできる。

＜処理の流れ（生前）＞
図２は、対象のユーザが生前において行う相続等に係る各種の処理を支援する流れの例について概要を示したフローチャートである。生前における管理処理を行う前提として、対象のユーザは、資産管理システム１にユーザ登録することでユーザＤＢ１５１にアカウント情報が登録されているものとする。また、資産管理部１２０により自身の資産に係る情報を資産状況ＤＢ１５２に登録して管理しているものとする。

対象のユーザは、相続等による資産移転を設計するため、ユーザ端末３０を利用してネットワーク２０を介して資産管理サーバ１０にアクセスする。ユーザ端末３０を介したユーザからの指示を受けて、資産管理サーバ１０の資産管理部１２０は、資産状況ＤＢ１５２から対象ユーザに係る現在の資産の情報を取得してユーザ端末３０に出力する（Ｓ０１）。資産状況ＤＢ１５２の内容のみに限らず、ユーザからの指示等に応じて移転履歴ＤＢ１５３に記録された過去の資産移転の内容や、相続財産ＤＢ１５４に既に登録されている相続（予定）資産の内容、遺言管理ＤＢ１５５に既に登録されている遺言の内容を取得して応答してもよい。

ユーザが相続内容の設計をするにあたり移転可能資産総額を把握するために、ユーザ端末３０を介して資産等の将来予測が必要である旨の指示を受けた場合（Ｓ０２：Ｙｅｓ）、資産管理部１２０の予測処理部１２３は、対象のユーザの将来の死亡予想時期における全資産の予想評価額を算出してユーザ端末３０に出力する（Ｓ０３）。さらに、対象のユーザの死亡予想時期までに必要となる生活資金等の必要費の総額をシミュレーション等により予測して出力する（Ｓ０４）。ステップＳ０３で算出した全資産の予想評価額の合計から、ステップＳ０４で算出した必要費の総額を減算したものが移転可能資産総額と仮定される。

ステップＳ０２で資産等の将来予測が必要である旨の指示がされなかった場合（Ｓ０２：Ｎｏ）も含め、さらに、ユーザからの指示に応じて、資産移転の対象となり得る近親者（近親者グループに属するユーザ）の資産を資産状況ＤＢ１５２から取得してユーザ端末３０に出力する（Ｓ０５）。なお、このとき、近親者グループに含まれるユーザのうち、資産状況の開示を許容しているユーザについての資産状況のみを対象のユーザに開示するようアクセス制御する。対象のユーザは上記の一連の処理で得られた各種の情報を参照して、相続管理部１３０が有する贈与税や相続税のシミュレーション機能等も利用しつつ、誰にどの資産をどれくらい、いつどのように移転するかといった近親者の資産形成の設計を行う。

そして、対象のユーザから贈与を行う旨の指示を受けた場合（Ｓ０６：Ｙｅｓ）、相続管理部１３０の贈与管理部１３１は、相手方の近親者との間に成立した贈与契約の内容の入力をユーザから受けて、これを相続財産ＤＢ１５４に登録する（Ｓ０７）。複数の贈与契約がある場合は、これらをそれぞれ登録する。贈与契約の内容には、例えば、相手方、移転する資産の内容（金額や物件、持分等）、移転条件（一定の日付の到来やその他の条件の成就等）、相手方の負担の有無等が含まれ得る。

そして、移転条件等の内容に基づいて、各贈与が生前贈与であり、かつ移転の条件が成就していると判断された場合は（Ｓ０８：Ｙｅｓ）、ユーザからの指示に基づいて、資産管理部１２０の資産移転部１２１により、贈与対象の資産を相手方である近親者に贈与として移転する（Ｓ０９）。上述したように、システム外で行われた贈与の結果についての入力を受け付けて移転履歴ＤＢ１５３に登録するものであってもよい。移転により、これらの資産についての管理処理は終了する。

ステップＳ０８で各贈与が生前贈与であるものの移転の条件が未成就である、もしくは死因贈与であると判断された場合は（Ｓ０８：Ｎｏ）、これらの資産についての管理処理を終了する。なお、生前贈与であるが移転条件が未成就のものについては、例えば、贈与管理部１３１等により定期的に条件成就の有無を確認する。そして、成就したと判断された場合には、対象のユーザに通知して承諾・指示を得た上で、資産移転部１２１により移転処理を行うようにしてもよい。

一方、ステップＳ０６で対象のユーザから遺言を行う旨の指示を受けた場合（Ｓ０６：Ｎｏ）、相続管理部１３０の遺言管理部１３２は、ユーザ端末３０を介したユーザからの遺言内容の入力を受け付けて、これを遺言管理ＤＢ１５５に登録する（Ｓ１０）。遺言内容には、個々の資産の移転内容の情報に加えて、遺言内容の開示許否および開示するとした場合の対象や範囲の情報等のアクセス制御に係る情報も含まれる。

遺言内容の登録に加えて、さらに、対象のユーザが自由意志により任意に遺言内容を作成して入力していることを証明するための認証情報についても併せて取得・記録するのが望ましい（Ｓ１１）。認証情報には、例えば、上述したように、遺言登録時の映像や音声のデータ、署名データ、生体情報等が含まれ得る。さらに、例えば、ユーザから遺言内容を出力する旨の指示を受けた場合は、これを書面やＰＤＦファイル等のデータとして出力する（Ｓ１２）。これらの処理により、遺言についての管理処理は終了する。なお、遺言の内容は、生存中であれば対象のユーザが随時変更することができる。その場合は、上記のステップＳ１０以降の処理を繰り返せばよい。

＜処理の流れ（死亡後）＞
図３は、対象のユーザの死亡後において行う相続等に係る各種の処理を支援する流れの例について概要を示したフローチャートである。死亡後における管理処理を行う前提として、対象のユーザ（被相続人）が死亡して相続が開始したという事象は、自動もしくは手動により資産管理システム１に入力されているものとする。

資産管理サーバ１０の相続管理部１３０は、ユーザＤＢ１５１を参照して、対象のユーザ（被相続人）の近親者グループに属するユーザを、資産移転の対象となり得る者として抽出する（Ｓ２１）。ここでは、被相続人に対して資産状況の開示を許容しているユーザのみを対象の近親者として抽出するようにしてもよい。抽出したユーザに対しては、電子メールやユーザ端末３０へのプッシュ通知等により、相続が開始した旨を通知するようにしてもよい。その後、相続管理部１３０は、資産状況ＤＢ１５２を参照して、資産移転の対象となる全資産（遺産）を確定する（Ｓ２２）。

その後、相続処理部１３３は、相続財産ＤＢ１５４を参照し、生前に対象のユーザ（被相続人）により登録されている死因贈与の契約がある場合にはこれを取得して、ステップＳ２１で抽出した近親者が参照可能なように出力する（Ｓ２３）。例えば、各近親者がユーザ端末３０を介して参照できるように画面出力したり、印刷出力したりする。また同様に、遺言管理ＤＢ１５５を参照し、被相続人により登録されている遺言がある場合にはこれを取得して、近親者が参照可能なように出力する（Ｓ２４）。

近親者は、ステップＳ２３、Ｓ２４で出力された死因贈与や遺言の内容を参照して、遺産分割協議を行う。相続処理部１３３は、遺産分割協議の結果の内容の入力を受け付けて、誰にどの資産をどれくらいどのように移転するかの情報を相続財産ＤＢ１５４に登録する（Ｓ２５）。なお、遺産分割協議に資するため、上述したように、相続管理部１３０は、例えば、被相続人の資産状況に係る情報を資産状況ＤＢ１５２から取得して近親者に出力するようにしてもよい。また、相続人が限定承認や相続放棄をした旨の入力を受け付けて、相続に係る自動処理もしくは相続人への情報提供の内容に反映させるようにしてもよい。

また、贈与税や相続税のシミュレーションを行うことができるのが望ましい。この場合、例えば、法定相続分に従った場合をデフォルトとしつつ、遺産分割の複数のパターン毎に贈与税や相続税の差分を算出して提示するのが望ましい。また、遺産分割のパターンを設計するにあたり、相続処理部１３３が、各種のデータを斟酌して所定の条件により重み付け等の最適化を行い、各相続人の遺留分等も計算して考慮しつつ、１つ以上の候補パターン案を作成して提示するようにしてもよい。

その後、被相続人によって既に登録されている死因贈与や遺贈等と併せて、最終的に、被相続人の資産を移転する対象となる近親者および各近親者に対する資産移転の内容を確定し、相続財産ＤＢ１５４に登録・更新する（Ｓ２６、Ｓ２７）。そして、近親者や遺言執行者等からの指示により、もしくは自動で、資産管理部１２０の資産移転部１２１により、相続財産ＤＢ１５４の登録内容に従って資産の移転を行う（Ｓ２８）。システム外で行われた資産移転の結果についての入力を受け付けて移転履歴ＤＢ１５３に登録するものであってもよい。移転により、対象のユーザ（被相続人）に係る資産管理は終了する。

なお、上記のように、相続に伴う資産移転には、資産管理システム１自身が処理を実行（もしくは他の外部サービス４０等に依頼）することができるもの（単独移転可能行為）と、資産管理システム１自身では処理を実行することができないもの（単独移転不可行為）がある。単独移転可能行為には、例えば、被相続人の口座から一または複数の相続人の口座への現金振込等がある。また、単独移転不可行為には、例えば、被相続人の不動産の相続人への移転等がある。

単独移転可能行為については、例えば、相続人（もしくは被相続人の法定代理人や任意代理人、遺言執行者等）がユーザ端末３０を利用して資産管理システム１にアクセスして指示を入力し、その内容に基づいて資産管理システム１が実行するようにしてもよい。また、単独移転不可行為については、例えば、その行為内容を相続人（もしくは被相続人の法定代理人や任意代理人、遺言執行者等）のユーザ端末３０上にガイド的に表示したり印刷したりしてもよい。また、システム外で行われた処理結果の入力を受け付けて、その内容を表示したり印刷したりしてもよい。

また、単独移転可能行為および単独移転不可行為を区別することなく、単独移転可能行為および／または単独移転不可行為の移転の手続き内容を外部に出力する構成であってもよい。出力先は、相続人（もしくは被相続人の法定代理人や任意代理人、遺言執行者等）のユーザ端末３０の他、被相続人が設定した対象者のユーザ端末３０や外部サービス４０等であってもよい。対象者は、例えば、相続関連サービスを提供している銀行や証券会社等の事業者であってもよい。この場合、例えば、本実施の形態の資産管理システム１が、資産内容に係る情報をこれらの事業者に提供して手数料等の見積もりを依頼し、見積もり結果を受け付ける構成とすることもできる。さらに、相続関連サービスを提供しているこれらの事業者の報酬体系は、一般的に、相続財産額に応じた所定の報酬料率を乗算するものであることから、このような計算を資産管理システム１において計算して出力するようにしてもよい。

＜データ構成＞
図４は、資産管理サーバ１０が保持するユーザＤＢ１５１のデータ構成の例について概要を示した図である。ユーザＤＢ１５１は、資産管理システム１を利用するユーザ（資産移転を行う被相続人となり得る者に加えて資産移転を受け得る近親者となる者も含む）に係る情報を保持するテーブルであり、例えば、ユーザテーブル１５１ａ、近親者グループテーブル１５１ｂの２つのテーブルを有する。

図４（ａ）に示したユーザテーブル１５１ａは、各ユーザのアカウント情報や属性情報等を保持するマスタテーブルであり、例えば、ユーザＩＤ、認証情報、近親者グループＩＤ、氏名、生年月日、性別、住所、職業、健康状況、被相続人毎相続意思等の各項目を有する。

ユーザＩＤの項目は、対象のユーザを一意に識別するためのＩＤ情報を保持する。認証情報は、対象のユーザに係るパスワードや生体情報等の個人認証情報を保持する。近親者グループＩＤは、対象のユーザに係る近親者グループを一意に識別するＩＤ情報を保持する。近親者グループは、対象のユーザを中心として、対象のユーザからの生前・死亡後の資産移転の対象となり得る近親者のユーザからなるグループであり、メンバーの内容は図４（ｂ）に示す近親者グループテーブル１５１ｂに登録される。

氏名の項目は、対象のユーザの氏名の情報を保持する。生年月日、性別、住所、職業、および健康状況の各項目は、それぞれ、対象のユーザの属性情報としての生年月日、性別、住所、職業、および健康状況を示す情報を保持する。職業および健康状況についてはコード値等により指定するようにしてもよい。これらの属性情報は、例えば、相続処理部１３３が遺産分割のパターンの候補を作成する際に重み付けを行なって斟酌するパラメータとすることができる。また、属性情報はこれらの項目に限られず、属性情報を保持する項目を適宜追加・削除等してもよい。

被相続人毎相続意思の項目は、対象のユーザが資産移転を受け得る近親者となる場合に、被相続人となり得る者毎に、その相続人として相続財産の移転を受ける意思があるか否かを示すコード値等の情報を保持する。この情報は、対象のユーザが予め設定しておくことができる。この情報により、対象のユーザに対する被相続人となり得るユーザが相続による資産移転の設計をする際や、当該ユーザの死亡後の遺産分割の際に、対象のユーザを検討対象から除外することが可能となる。

図４（ｂ）に示した近親者グループテーブル１５１ｂは、ユーザ毎に、当該ユーザを中心とした近親者グループの構成に係る情報を保持するテーブルであり、例えば、近親者グループＩＤ、近親者ユーザＩＤ、続柄、開示許否、およびメモ等の各項目を有する。

近親者グループＩＤの項目は、各近親者グループを一意に識別するＩＤ情報を保持する。近親者グループは、対象のユーザからの生前・死亡後の資産移転の対象となり得る相続人等の近親者からなるグループである。近親者ユーザＩＤの項目は、対象の近親者グループに属する近親者を特定するユーザＩＤの情報を保持する。この近親者ユーザＩＤの値は、上記のユーザテーブル１５１ａのユーザＩＤの項目に登録されている値となる。

続柄の項目は、対象の近親者についての、対象の近親者グループにおける被相続人となるユーザとの間の続柄を示すコード値等の情報を保持する。開示許否の項目は、対象の近親者が、対象の近親者グループにおける被相続人に対して、自身の資産状況の内容についての開示を許容するか否かを示すコード値等の情報を保持する。開示を許否する旨を指定した近親者は、対象の被相続人からの相続を放棄したものとして取り扱ってもよい。メモの項目は、対象の近親者グループにおける被相続人が、対象の近親者に対する特記事項や注意事項等をフリーフォームで指定したテキストの内容を保持する。これにより、対象の近親者に対する被相続人の個人的・主観的な評価等を記録しておくことができる。

図５は、資産管理サーバ１０が保持する資産状況ＤＢ１５２のデータ構成の例について概要を示した図である。資産状況ＤＢ１５２は、資産管理システム１を利用する各ユーザが保有する資産の情報を保持するテーブルである。例えば、ユーザＩＤ、資産ＩＤ、資産名称、資産種別、情報取得方法、評価金額、評価基準日、共有持分、共有者等の各項目を有する。

ユーザＩＤの項目は、対象の資産を保有するユーザを特定するＩＤ情報を保持する。このユーザＩＤの値は、上記のユーザテーブル１５１ａのユーザＩＤの項目に登録されている値となる。なお、この項目により特定されるユーザは、資産移転を行う者（被相続人となり得る者）のみに限らず、資産移転を受ける者（近親者となり得る者）も全て含まれる。資産ＩＤの項目は、対象の資産を一意に識別するＩＤ情報を保持する。資産名称の項目は、対象の資産の表示名称の情報を保持する。資産種別の項目は、対象の資産の種別を特定するコード値等の情報を保持する。コード値には、例えば、預貯金や現金、土地、建物、自動車、貴金属、債務等を区別する値が設定される。

情報取得方法の項目は、対象の資産に係る情報を外部サービスＩ／Ｆ１４０を介して外部サービス４０から取得する必要がある場合に、その取得方法に係る情報を保持する。例えば、Ｗｅｂスクレイピングにより取得する場合の、アクセス先のＵＲＬ（Uniform Resource Locator）や、アクセス時に入力するＩＤやパスワード等の情報を保持する。ＡＰＩを呼び出す場合には、対象となるＡＰＩや指定するパラメータ等の情報を保持する。これらの情報を指定した取得方法を実際に実行するためのスクリプトやプログラム等を指定するものであってもよい。

評価金額および評価基準日の項目は、それぞれ、対象の資産についての金銭的評価の結果、および金銭的評価の基準日の情報を保持する。共有持分および共有者の項目は、それぞれ、対象の資産が対象のユーザ以外の他の者との共有に係る場合に、対象のユーザの共有持分の割合（もしくは金額）、および他の共有者を特定する情報（資産管理システム１のユーザである場合はユーザＩＤでもよい）を保持する。

図６は、資産管理サーバ１０が保持する移転履歴ＤＢ１５３のデータ構成の例について概要を示した図である。移転履歴ＤＢ１５３は、資産管理システム１を利用する各ユーザについての資産移転の履歴の情報を保持するテーブルである。例えば、ユーザＩＤ、資産移転日、供与／取得区分、移転資産ＩＤ、移転金額／割合、相手方ユーザＩＤ、資産移転理由等の各項目を有する。

ユーザＩＤの項目は、対象の資産移転を行ったユーザを特定するＩＤ情報を保持する。このユーザＩＤの値は、上記のユーザテーブル１５１ａのユーザＩＤの項目に登録されている値となる。資産移転日の項目は、対象の資産移転が行われた日付の情報を保持する。供与／取得区分の項目は、対象の資産移転について、対象のユーザが資産を供与したのか、取得したのかを区分するコード値等の情報を保持する。移転資産ＩＤの項目は、対象の資産移転において移転された資産を特定するＩＤ情報を保持する。この移転資産ＩＤの値は、上記の資産状況ＤＢ１５２の資産ＩＤの項目に登録されている値となる。

移転金額／割合の項目は、対象の資産移転において移転された資産の評価金額、もしくは資産が不可分の場合等にはその割合の情報を保持する。相手方ユーザＩＤの項目は、対象の資産移転における相手方のユーザを特定するＩＤ情報を保持する。このユーザＩＤの値は、上記のユーザテーブル１５１ａのユーザＩＤの項目に登録されている値となる。資産移転理由の項目は、対象の資産移転が行われた理由や付随する条件等の内容に係る情報をテキストやコード値等により保持する。例えば、結婚資金や事業資金等として贈与した旨や、負担付贈与とした場合の負担の内容等（例えば、同居義務や介護等）を記録しておくことができる。これにより、相続による近親者の資産形成を設計する際の参考情報とすることができる。

図７は、資産管理サーバ１０が保持する相続財産ＤＢ１５４のデータ構成の例について概要を示した図である。相続財産ＤＢ１５４は、資産管理システム１を利用する各ユーザを被相続人として、相続等により近親者に移転される資産（相続財産）の情報を保持するテーブルである。例えば、ユーザＩＤ、移転資産ＩＤ、移転対象者、移転金額／割合、移転区分、移転条件、移転状況等の各項目を有する。

ユーザＩＤの項目は、対象の相続財産に係る資産を保有するユーザを特定するＩＤ情報を保持する。このユーザＩＤの値は、上記のユーザテーブル１５１ａのユーザＩＤの項目に登録されている値となる。移転資産ＩＤの項目は、対象の相続財産に係る資産を特定するＩＤ情報を保持する。この移転資産ＩＤの値は、上記の資産状況ＤＢ１５２の資産ＩＤの項目に登録されている値となる。移転対象者の項目は、対象の相続財産が移転される近親者を特定する情報（資産管理システム１のユーザである場合はユーザＩＤでもよい）を保持する。

移転金額／割合の項目は、対象の相続財産に係る資産が移転される際の評価金額、もしくは資産が不可分の場合等にはその割合の情報を保持する。移転区分の項目は、対象の相続財産の移転が生前贈与、死因贈与、遺贈、遺産分割等による相続のいずれによるものかを区分するコード値等の情報を保持する。移転条件の項目は、対象の相続財産の移転に条件が付されている場合（例えば、相手方の結婚や住居購入、自身の要介護認定等）、その内容に係る情報をテキストやコード値等により保持する。移転状況の項目は、対象の相続財産の移転の状況（例えば、未移転、移転済み等）を示すコード値等を保持する。

図８は、資産管理サーバ１０が保持する遺言管理ＤＢ１５５のデータ構成の例について概要を示した図である。遺言管理ＤＢ１５５は、資産管理システム１を利用する各ユーザによる遺言の内容に係る情報を保持するテーブルである。例えば、ユーザＩＤ、遺言ＩＤ、遺言日時、遺言区分、認証日時、認証内容、開示区分、開示対象者、対象資産ＩＤ、移転対象者、移転金額／割合、移転条件等の各項目を有する。

ユーザＩＤの項目は、対象の遺言を行ったユーザを特定するＩＤ情報を保持する。このユーザＩＤの値は、上記のユーザテーブル１５１ａのユーザＩＤの項目に登録されている値となる。遺言ＩＤの項目は、対象の遺言を一意に識別するＩＤ情報を保持する。遺言日時の項目は、対象の遺言が作成（もしくは遺言管理ＤＢ１５５に登録）された日時の情報を保持する。

遺言区分の項目は、対象の遺言の区分（自筆証書遺言、公正証書遺言、秘密証書遺言、その他法定外の遺言等）を示すコード値等の情報を保持する。法定された自筆証書遺言や公正証書遺言の場合は、自筆もしくは公証人の筆記が必要であり、秘密証書遺言の場合も書面としての出力が必要となる。したがって、当該遺言管理ＤＢ１５５に登録された遺言の内容は、現行法では、これらの遺言の内容を示す、もしくはこれらの遺言の基礎となる情報となる。一方で、現行法の狭義の遺言としての様式を満たさなくても、例えば、遺産分割協議において被相続人の生前の意思を斟酌する広義の遺言として用いることは可能である。

認証日時の項目は、対象の遺言について、遺言を行ったユーザや公証人、立会人等が確認や認証を行った日時の情報を保持する。また、認証内容の項目は、対象の遺言について行われた認証の内容を特定するテキストやコード値等の情報を保持する。認証は、法的なものとして公証人や立会人等がシステム外で行ったものに限られない。上述したように、例えば、ユーザが遺言の内容を資産管理システム１に登録する際に、資産管理システム１が、内容が正しいこと、および本人の自由意志により登録したものであることを認証することも可能である。この場合の認証内容としては、例えば、ユーザ端末３０が備えるカメラやマイクによる録画・録音データや、センサにより取得した心拍数等の生体情報、手書きの署名の画像データ等が含まれ得る。

開示区分の項目は、対象の遺言を他の近親者等に開示するか否かを指定するコード値等の情報を保持する。また、開示対象者の項目は、対象の遺言を開示するとした場合において、その対象者を制限する場合に、開示する対象者を特定する情報（資産管理システム１のユーザである場合はユーザＩＤでもよい）を保持する。これらの情報により、遺言に対するアクセス制御を行うことができる。

対象資産ＩＤの項目は、対象の遺言において移転の対象となる資産を特定するＩＤ情報を保持する。この対象資産ＩＤの値は、上記の資産状況ＤＢ１５２の資産ＩＤの項目に登録されている値となる。複数の資産を登録できるようにしてもよい。移転対象者の項目は、対象の資産が移転される近親者等を特定する情報（資産管理システム１のユーザである場合はユーザＩＤでもよい）を保持する。移転金額／割合の項目は、対象の遺言によって移転する資産の金額、もしくは資産が不可分の場合等にはその割合の情報を保持する。移転条件の項目は、対象の資産を移転するにあたり、条件が付されている場合（例えば、遺贈において、結婚や事業開始等が条件とされている場合等）に、その内容を示すテキストやコード値等の情報を保持する。

なお、上述の図４〜図８で示した各テーブルのデータ構成（項目）はあくまで一例であり、同様のデータを保持・管理することが可能な構成であれば、他のテーブル構成やデータ構成であってもよい。

以上に説明したように、本発明の実施の形態１である資産管理システム１によれば、個人の金融資産の管理にとどまらず、相続を含む近親者等への資産の移転に係る各種の処理を支援することが可能である。

具体的には、個人の金融資産に限らず、不動産や動産等の、相続による資産移転の対象となり得る財産を、自動・手動により把握し、管理することができる。また、これらの資産の将来（死亡予想時期）における評価額を予想し、また、当該時期までに必要となる生活費等の必要費をシミュレーション等より予測することで、移転可能資産総額を算出する。これらにより、被相続人となり得るユーザが資産移転により近親者の資産形成を設計することが容易になるとともに、若年世代への早期の資産移転を促すことも可能となる。また、遺言の作成・管理も容易となる。

そして、ユーザが死亡して相続が開始した場合にも、遺産となり得る当該ユーザの資産や、遺言の内容の把握を容易にし、相続人等が遺産分割を含む資産移転を容易に行えるような情報やシミュレーション機能等を提供することが可能である。

（実施の形態２）
本発明の実施の形態２である資産管理システム１では、相続等により資産移転を行おうとするユーザが、どの近親者にどの資産をどれだけ移転するかを決定する際に、当該ユーザ個人の資産だけでなく、他の近親者の資産状況も含めた近親者グループ全体での資産状況を視覚的に把握しやすくするとともに、簡易な操作で資産移転の指定ができるようなユーザインタフェースを有するものである。資産管理システム１の基本的な構成や動作内容については、上述した実施の形態１と同様であるため、再度の説明は省略し、ユーザインタフェースの内容およびその実現方法について主に説明する。

＜バランスシートによる資産管理＞
図９は、本実施の形態におけるユーザ端末３０に表示されるユーザインタフェースの例について概要を示した図である。ここでは、ユーザ端末３０としてスマートフォンを例としており、タッチパネルからなるディスプレイに対して、スマートフォンに導入されたクライアントアプリケーションにより表示される画面の例を示している。図９では、対象のユーザについて、その近親者（親族・家族）の一部の資産も含んだ近親者グループとして管理可能な資産（すなわち、対象のユーザが「あてにできる」資産、同じ「財布」とみなせる資産）の状況について、バランスシートの形式で表示する例を示している。

図９（ａ）では、ユーザが指定した基準日における、対象のユーザの近親者グループとしての資産状況について、左側に借方（資産）、右側に貸方（負債＋純資産）のバランスシートの形で表示している。本実施の形態では、純資産に相当する部分が移転可能資産総額（図中では「可相続資産」）となる。すなわち、「可相続資産」は、現在保有する資産（図中では「預金」や「株式」、「不動産」等）の評価額の合計から、負債（図中では「住宅ローン」や「自動車ローン」の総額に「将来生活費」を加えたもの）を減算したものである。

なお、実施の形態１において示したように、移転可能資産総額（可相続資産）は、ユーザの死亡予想時期における全資産の予想評価額の合計から、死亡予想時期までの必要費の総額を減算したものである。したがって、例えば、株式や不動産等の資産の評価額は、死亡予想時期における予想評価額であることが望ましいが、現時点での評価額で簡略化してもよい。また、「将来生活費」は、死亡予想時期までに予想される支出（生活費や医療費等）の総額から、予想される収入（給与や株式配当等）の総額を減算したものである。

さらに、本実施の形態では、図９（ａ）に示すように、近親者グループの資産として、対象のユーザ本人の預金（「預金（本人）」）に加えて、妻の預金（「預金（妻）」）や父から贈与された（される）預金（「預金（from父）」）等、対象のユーザ以外の資産についても取り込んで表示している。これにより、ユーザは、近親者グループ内での資産状況を全体的に、かつ視覚的に把握して、資産移転の要否を決定することができる。なお、資産に限らず、負債についても同様に、対象のユーザ以外のものを取り込むことができる。

図９（ａ）の画面において、ユーザが、例えば、「基準日」欄の日付を将来の任意の日付に変更すると、図９（ｂ）に示すように、変更された基準日における資産の状況を再計算して、計算結果に基づいてバランスシートを更新する。なお、資産や負債に相当する項目の額は、図示するように時間の経過とともに変動するが、可相続資産の額は基本的には不変である。

また、図９（ａ）の画面において、ユーザが、バランスシートにおける資産の各項目を選択すると、選択された資産を管理する画面に遷移する。図９（ｃ）は、図９（ａ）の例においてユーザが「株式（本人）」の資産を選択した場合に表示される、株式を管理する画面の例を示している。この画面を介して、ユーザは、対象の資産（株式）を近親者に割り当てる（移転する）ことができる。

図９（ｃ）の例では、株式の銘柄毎に、保有数や時価等の情報が一覧表示されている。また、銘柄毎に、近親者のグループにおける情報の開示範囲の設定内容についても表示されている。そして、ユーザは、対象の銘柄の「割当」欄のボタンを押下することで表示されるポップアップ画面を介して、対象の銘柄を近親者に割り当てることができる。このとき、割り当てる対象の近親者の候補を、例えば、図９（ｃ）に示すようにプルダウンメニュー等から選択できるようにするのが望ましい。近親者の候補は、例えば、実施の形態１に示した近親者グループに属するユーザとしてもよいが、本実施の形態では、後述するように家系図の情報を参照して、さらに詳細な続柄単位で指定できるようにする。

資産を近親者に割り当てる（移転する）と、図９（ｄ）に示すように、バランスシートにその内容が反映される。図９（ｄ）の例では、「株式（本人）」の一部が、近親者のグループの資産として、子供に割り当てられたことを示している（「株式（to子供）」）。このように、ユーザは、可相続資産を含む近親者のグループでの資産の状況を視覚的に把握しながら、誰にどのくらいの資産を移転するかを容易に決定することができる。

＜家系図情報の形成＞
本実施の形態では、ユーザが親族等の近親者に対して資産の移転を行うことができるが、その決定の際に、上述したように、各近親者がユーザに対して資産状況の開示を許容する場合としない場合とがある。逆に、ユーザが各近親者に対して資産移転を行う候補とする場合と除外する場合とがある。このような事情に柔軟に対応できるようにするため、本実施の形態では、実施の形態１のように資産を移転する対象となる可能性のあるユーザを近親者グループとして一律に管理するのではなく、より詳細に続柄単位で管理することができるよう、家系図情報を形成して保持する。

図１０は、ユーザが家系図を作成する画面の例について概要を示した図である。ここでは、例えば、特許文献３に記載されたような技術を用いて、ユーザは、ユーザ端末３０上でアイコンをドラッグ＆ドロップする等の操作により家系図を構成することができる。また、贈与や相続による資産移転の対象の候補とするか否か、資産状況を他の近親者に開示するか否か等を、個別の近親者毎に設定することもできる。

図１１は、資産管理の対象となる近親者が属する家系図情報を形成するためのデータ構成の例について概要を示した図である。ここでは、管理対象の資産として、証券会社の口座に保有する株式や銀行口座に保有する預金等の金融資産を対象とした場合の例を示している。具体的には、例えば、図１におけるユーザＤＢ１５１に含まれるテーブルとして、ユーザテーブル１５１ａ、および近親者テーブル１５１ｃの各テーブルを有する。また、資産状況ＤＢ１５２に含まれるテーブルとして、口座テーブル１５２ａ、資産テーブル１５２ｂ、資産属性テーブル１５２ｃ、資産開示テーブル１５２ｄ、資産割当テーブル１５２ｅの各テーブルを有する。

ユーザテーブル１５１ａは、各ユーザのマスタ情報を有するテーブルであり、上述の図４（ａ）に示したものと概ね同様である。図１１の例では、簡略化してユーザＩＤ、および性別の各項目を有するものとしている。ユーザＩＤは、各ユーザを一意に識別するＩＤ情報を保持する。性別の項目は、対象のユーザの性別を示すコード値等の情報を保持する。

近親者テーブル１５１ｃは、近親者である１対のユーザ間の続柄を管理するテーブルであり、例えば、続柄ＩＤ、第１ユーザＩＤ、第２ユーザＩＤ、続柄、続柄名称、逆向レコード続柄ＩＤ、および表示有無等の各項目を有する。続柄ＩＤの項目は、各続柄（ユーザ間の関係を示す有向グラフ）を一意に識別するＩＤ情報を保持する。

第１ユーザＩＤの項目は、対象の続柄の有向グラフにおける元のノードにあたる者（例えば、「本人」）のユーザＩＤの情報を保持する。第２ユーザＩＤの項目は、対象の続柄の有向グラフにおける先のノードにあたる者（例えば、「妻」、「子供Ａ」等）のユーザＩＤの情報を保持する。続柄の項目は、対象の続柄を示す有向グラフの情報を保持する。例えば、第１ユーザＩＤの項目に対応するユーザから見た場合の「夫婦」や「親子」等を示す情報を保持する。家系図をｘｙ座標平面とした場合のベクトル等により表現してもよい。この場合、同世代はｘ軸方向、上下世代はｙ軸方向で表される。続柄名称の項目は、対象の続柄の表示名（「妻」、「子供Ａ」等）の情報を保持する。これらの情報は、例えば、特許文献３に記載されたような技術を用いた家系図作成手法により設定することができる。

逆向レコード続柄ＩＤの項目は、対象の続柄に係る有向グラフに対する逆向きの続柄のレコードに係る続柄ＩＤの情報を保持する。また、表示有無の項目は、家系図の表示の際に、対象の続柄に係る結線を表示するか否かを示すフラグやコード値等の情報を保持する。これらの項目は、後述する家系図の形成に係る処理における制御に用いられる情報である。

口座テーブル１５２ａは、管理対象の資産である株式を保有する証券会社等の口座のマスタ情報を保持するテーブルであり、例えば、口座ＩＤ、およびユーザＩＤ等の各項目を有する。口座ＩＤの項目は、対象の口座を一意に識別するＩＤ情報を保持する。ユーザＩＤの項目は、対象の口座を保有するユーザに係るユーザＩＤの情報を保持する。なお、口座の情報は、ユーザがユーザ端末３０を利用して登録する。

資産テーブル１５２ｂは、管理対象の資産に係る情報を保持するテーブルであり、例えば、資産ＩＤ、口座ＩＤ、銘柄コード、数量、および資産属性ＩＤ等の各項目を有する。資産ＩＤの項目は、対象の資産を一意に識別するＩＤ情報を保持する。口座ＩＤの項目は、対象の資産が保有されている口座に係る口座ＩＤの情報を保持する。銘柄コードの項目は、対象の資産である株式の銘柄コードの情報を保持する。数量の項目は、対象の資産である株式の保有数の情報を保持する。これらの項目の値は、例えば、図１における外部サービスＩ／Ｆ１４０により、金融機関のＷｅｂサイトやシステム等が提供するＡＰＩを呼び出して取得することができる。資産属性ＩＤの項目は、対象の資産の種別等の属性に係る資産属性ＩＤの情報を保持する。この値は、後述する資産属性テーブル１５２ｃに登録されている。

資産属性テーブル１５２ｃは、資産の種別等の属性に係るマスタ情報を保持するテーブルであり、例えば、資産属性ＩＤ、および資産属性名称等の各項目を有する。資産属性ＩＤの項目は、対象の属性を一意に識別するＩＤ情報を保持する。資産属性名称の項目は、対象の属性の表示名の情報を保持する。属性には、例えば、「預金」や「株式」等が含まれる。

資産開示テーブル１５２ｄは、ある続柄において特定の資産に係る情報を開示する（もしくはしない）旨の情報を保持するテーブルであり、例えば、資産ＩＤ、および続柄ＩＤの各項目を有する。資産ＩＤの項目は、開示する（もしくはしない）対象の資産を特定する資産ＩＤの情報を保持する。続柄ＩＤの項目は、対象の資産を開示する（もしくはしない）続柄を特定する続柄ＩＤの情報を保持する。続柄単位ではなく開示の相手方となるユーザ単位で指定するものとしてもよい。開示する（もしくはしない）旨の指定は、ユーザがユーザ端末３０を利用して上述の図９に示したような画面を用いて登録する。

資産割当テーブル１５２ｅは、ある続柄に係るユーザ間で特定の資産の割当が行われた場合の内容に係る情報を保持するテーブルであり、例えば、資産ＩＤ、続柄ＩＤ、および数量等の各項目を有する。資産ＩＤの項目は、割り当てられた資産を特定する資産ＩＤの情報を保持する。続柄ＩＤの項目は、資産割当が行われた続柄を特定する続柄ＩＤの情報を保持する。続柄ではなく割当の相手方のユーザを特定するユーザＩＤであってもよい。数量の項目は、割り当てられた資産の数量の情報を保持する。これらの項目の値は、ユーザがユーザ端末３０を利用して上述の図９に示したような画面を用いて登録する。

図１２、図１３は、近親者の情報に基づいて家系図情報を形成する処理の流れの例について概要を示した図である。ここでは、図１０に示したようなユーザインタフェースを用いて他の近親者のユーザが既に行っている近親者の登録情報（家系図情報）を利用して、本人に係る家系図情報を形成する例を示している。

家系図形成処理では、まず、図１１に示した近親者テーブル１５１ｃから、本人（Ｘ）であるユーザが第２ユーザＩＤ（有向グラフの先のユーザ）として既に設定されているレコードを抽出する（Ｓ３１）。図１２の右側には、具体例として、配偶者（Ｂ）→本人（Ｘ）、親（Ｃ）→本人（Ｘ）、および子供（Ａ）→本人（Ｘ）の各有向グラフに係るレコードが抽出されたことを示している。なお、図中の矢印およびｘ、−ｘやｙ、−ｙの記号は、家系図をｘｙ座標平面とした場合の有向グラフをベクトルで示しており、同一世代間はｘ（図中の右方向）、−ｘ（図中の左方向）で表し、上の世代へはｙ（図中の上方向）、下の世代へは−ｙ（図中の下方向）で表している。

次に、ステップＳ３１で抽出した各レコードについて、続柄を逆向きとした上で、本人（Ｘ）を第１ユーザＩＤとするレコードを作成する（Ｓ３２）。図１２の例では、本人（Ｘ）→配偶者（Ｂ）、本人（Ｘ）→親（Ｃ）、および本人（Ｘ）→子供（Ａ）の各有向グラフに係るレコードを新たに追加する。このとき、追加するレコードにおける「逆向レコード続柄ＩＤ」の項目の値を、ステップＳ３１で抽出した各レコードの続柄ＩＤとして追加する。また、ステップＳ３１で抽出した元のレコードにおける「逆向レコード続柄ＩＤ」の項目の値も、ステップＳ３２で追加する対応するレコードの続柄ＩＤに更新する。

その後、ステップＳ３２で作成された各レコードに係る続柄（有向グラフ）について、家系図の表示の際に、対象の続柄に係る結線を表示するか否かを、本人（Ｘ）であるユーザが決定し、ユーザ端末３０を介して入力する（Ｓ３３）。このとき、例えば、ステップＳ３２で作成されたレコードに係る暫定的な家系図の情報をユーザ端末３０上に表示し、これに対してユーザが指示できるようにする。

その後、ステップＳ３１とは逆に、近親者テーブル１５１ｃから、本人（Ｘ）が第１ユーザＩＤとして設定されているレコードの第２ユーザＩＤをそれぞれ抽出する（Ｓ３４）。図１２の例では、配偶者（Ｂ）、親（Ｃ）、および子供（Ａ）が抽出される。そして、抽出した第２ユーザＩＤが、第１ユーザＩＤ（有向グラフの元のユーザ）として設定されているレコードを抽出する（Ｓ３５）。このとき、本人（Ｘ）が第２ユーザＩＤとして設定されているものは除外する。図１２の例では、配偶者（Ｂ）、親（Ｃ）、子供（Ａ）がそれぞれ第１ユーザＩＤとして設定されているレコードに係る有向グラフを点線の矢印で示している。このうち、本人（Ｘ）が第２ユーザＩＤとして設定されていない親（Ｃ）→祖父（Ｄ）、配偶者（Ｂ）→親（Ｅ）、および配偶者（Ｂ）→子供（Ａ）の各有向グラフ（図中で実線枠で囲われたもの）のみが抽出されることになる。

図１３に移り、次に、ステップＳ３５で抽出したレコードの第２ユーザＩＤと、ステップＳ３４で抽出した第２ユーザＩＤとを比較して、重複しないものを抽出する（Ｓ３６）。このとき、重複しないユーザＩＤがない場合は（Ｓ３７：Ｎｏ）、家系図形成処理を終了する。図１２、図１３の例では、ステップＳ３５で抽出したレコードの第２ユーザＩＤである祖父（Ｄ）、親（Ｅ）、および子供（Ａ）と、ステップＳ３４で抽出した第２ユーザＩＤである配偶者（Ｂ）、親（Ｃ）、および子供（Ａ）とを比較すると、重複しないものとして祖父（Ｄ）、および親（Ｅ）が抽出される。したがって、家系図形成処理は終了しない。

ステップＳ３６において重複しないユーザＩＤが抽出された場合は（Ｓ３７：Ｙｅｓ）、当該ユーザＩＤを第２ユーザＩＤとし、本人（Ｘ）を第１ユーザとするレコードに係る続柄（有向グラフ）の情報を家系図上に表示する（Ｓ３８）。このとき、対象のレコードが存在しない場合は、作成した上で表示する。そして、表示された各続柄について、実際に家系図への表示を行うか否かを、本人（Ｘ）であるユーザが決定し、ユーザ端末３０を介して入力する（Ｓ３９）。図１３の例では、ステップＳ３８において新たに本人（Ｘ）→祖父（Ｄ）と本人（Ｘ）→親（Ｅ）の続柄が表示され、ステップＳ３９において本人（Ｘ）→親（Ｅ）の続柄は非表示とする決定がされたことを示している。

その後、図１２のステップＳ３４に戻り、ステップＳ３７で重複しないＩＤが抽出されなくなるまで一連の処理を繰り返す。以上のような処理により、他の近親者のユーザが既に行っている近親者の登録情報（家系図情報）を利用して、本人に係る家系図情報を容易に形成することができる。

図１４は、家系図情報に基づいて図９に示したような近親者のグループとしてのバランスシートを表示する処理の流れの例について概要を示した図である。処理を開始すると、まず、近親者テーブル１５１ｃから、本人が第１ユーザＩＤまたは第２ユーザＩＤとして設定されているレコードの続柄ＩＤを抽出する（Ｓ４１）。そして、資産割当テーブル１５２ｅから、ステップＳ４１で抽出した続柄ＩＤが設定されているレコードの資産ＩＤを抽出する（Ｓ４２）。資産割当テーブル１５２ｅにおいて続柄ＩＤではなくユーザＩＤにより割当が設定されている場合は、本人のユーザＩＤが設定されているレコードが対象となる。

一方、近親者テーブル１５１ｃから、本人が第２ユーザＩＤとして設定されているレコードの続柄ＩＤを抽出する（Ｓ４３）。そして、資産開示テーブル１５２ｄから、ステップＳ４３で抽出した続柄ＩＤが設定されているレコードの資産ＩＤを抽出する（Ｓ４４）。資産開示テーブル１５２ｄにおいて続柄ＩＤではなくユーザＩＤにより開示が設定されている場合は、本人のユーザＩＤが設定されているレコードが対象となる。

その後、資産テーブル１５２ｂから、ステップＳ４２、Ｓ４４で抽出した資産ＩＤが設定されているレコードの資産属性ＩＤと銘柄コードを抽出する（Ｓ４５）。そして、資産属性テーブル１５２ｃから、ステップＳ４５で抽出した資産属性ＩＤが設定されているレコードの資産属性名称を取得する（Ｓ４６）。また、外部サービスＩ／Ｆ１４０を介して、ステップＳ４５で抽出した銘柄コードをキーとして外部サービス４０から時価の情報を取得する（Ｓ４７）。

その後、ステップＳ４５で抽出した資産属性ＩＤ、およびステップＳ４１、Ｓ４３で抽出した続柄ＩＤ毎に、ステップＳ４７で取得した時価を集計する。そして、全体の額に占める割合が分かるバランスシート等の形式で、ステップＳ４６で取得した資産属性名称と併せてユーザ端末３０上に表示する（Ｓ４８）。さらに、以下の一連の処理によって続柄ＩＤに対応する続柄名称についてもユーザ端末３０上に表示して、処理を終了する。

具体的には、対象の資産について、近親者テーブル１５１ｃにおいて本人が第１ユーザＩＤとして設定されているレコードの続柄ＩＤに係るものであるか否かを判定する（Ｓ４９）。そして、本人が第１ユーザＩＤとして設定されているのではなく、第２ユーザＩＤとして設定されているレコードの続柄ＩＤに係るものである場合（Ｓ４９：Ｎｏ）、近親者テーブル１５１ｃから、当該続柄ＩＤが逆向レコード続柄ＩＤに設定されているレコードを特定し、そのレコードの続柄ＩＤの値を取得する（Ｓ５０）。

その後、ステップＳ４９にて本人が第１ユーザＩＤとして設定されているレコードの続柄ＩＤに係るものである場合は（Ｓ４９：Ｙｅｓ）、当該続柄ＩＤを対象の続柄ＩＤとし、本人が第２ユーザＩＤとして設定されているレコードの続柄ＩＤに係るものである場合は（Ｓ４９：Ｎｏ）、ステップＳ５０で取得した続柄ＩＤをそれぞれ対象の続柄ＩＤとする。そして、近親者テーブル１５１ｃから、対象の続柄ＩＤが設定されているレコードの続柄名称の値を取得して、ユーザ端末３０上に表示する（Ｓ５１）。

以上に説明したように、本発明の実施の形態２である資産管理システム１によれば、相続等により資産移転を行おうとするユーザが、どの近親者にどの資産をどれだけ移転するかを決定する際に、当該ユーザ個人の資産だけでなく、他の近親者の資産状況も含めた近親者グループ全体での資産状況をバランスシートとして視覚的に把握しやすくするとともに、簡易な操作で資産移転の指定ができるようなユーザインタフェースを実現することができる。

また、近親者のグループを特定するための家系図情報の形成と、これに基づいた近親者のグループとしての資産管理を容易に行うことができる。

以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は上記の実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。例えば、上記の実施の形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施の形態の構成の一部を他の実施の形態の構成に置き換えることが可能であり、また、ある実施の形態の構成に他の実施の形態の構成を加えることも可能である。また、各実施の形態の構成の一部について、他の構成の追加・削除・置換をすることが可能である。

例えば、上述した本発明の実施の形態１および２における資産管理システム１では、個人が資産管理を行う仕組みやサービスを対象として説明したが、これに限られない。例えば、資産管理システム１が保有する個人の資産管理に係る情報を、対象のユーザが特定されない形式で外部の第三者等に提供する機能を有していてもよい。そして、提供を受けた第三者が資産管理システム１を介して対象のユーザに対して何らかのマーケティングサービスを提供することができる構成であってもよい。なお、この場合、資産管理に係る情報を第三者に提供するには、対象のユーザから事前の同意・承諾を得た上で行う構成であることが望ましい。

また、上記の各構成、機能、処理部、処理手段等は、それらの一部または全部を、例えば、集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリやハードディスク、ＳＳＤ（Solid State Drive）等の記録装置、またはＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に置くことができる。

また、上記の各図において、制御線や情報線は説明上必要と考えられるものを示しており、必ずしも実装上の全ての制御線や情報線を示しているとは限らない。実際にはほとんど全ての構成が相互に接続されていると考えてもよい。

本発明は、被相続人となり得る者が行う相続等の資産移転に係る各種の処理を支援する資産管理システムに利用可能である。

１…資産管理システム、
１０…資産管理サーバ、２０…ネットワーク、３０…ユーザ端末、４０…外部サービス、
１１０…ユーザ管理部、１２０…資産管理部、１２１…資産移転部、１２２…資産評価部、１２３…予測処理部、１３０…相続管理部、１３１…贈与管理部、１３２…遺言管理部、１３３…相続処理部、１４０…外部サービスＩ／Ｆ、１５１…ユーザＤＢ、１５１ａ…ユーザテーブル、１５１ｂ…近親者グループテーブル、１５２…資産状況ＤＢ、１５３…移転履歴ＤＢ、１５４…相続財産ＤＢ、１５５…遺言管理ＤＢ

Claims (5)

1. ユーザ端末を利用してネットワークを介して接続するユーザが保有する資産の管理を支援する資産管理システムであって、
   前記ユーザが保有する資産に係る情報を資産状況記録部に記録し、また、前記ユーザと他のユーザとの間の資産の移転に係る処理を行い、その内容を移転履歴記録部に記録する資産管理部と、
   前記ユーザが保有する資産につき、その少なくとも一部についての前記ユーザの生前もしくは死亡後における移転に係る処理を行う相続管理部と、を有し、
   前記相続管理部は、さらに、
   第１のユーザの生前において、前記第１のユーザから所定の範囲の他の第２のユーザに対する生前贈与もしくは死因贈与の内容の登録を受け付けて、その内容を相続財産記録部に記録する贈与管理部と、
   前記第１のユーザの生前において、前記第１のユーザから遺言の内容の登録を受け付けて、その内容を遺言管理情報記録部に記録する遺言管理部と、
   前記第１のユーザの死亡後において、前記相続財産記録部に記録された前記第１のユーザの死因贈与の内容を所定の範囲の前記第２のユーザが参照可能なように出力し、前記遺言管理情報記録部に記録された前記第１のユーザの遺言の内容を所定の範囲の前記第２のユーザに参照可能なように出力し、前記第２のユーザによる入力を受け付けて、前記第１のユーザが保有していた資産に係る前記第２のユーザへの移転に係る情報として、誰がどの資産をどれくらいどのように移転するかの情報を前記相続財産記録部に記録する相続処理部と、を有し、
   前記資産管理部は、前記相続財産記録部に記録された資産の移転に係る内容が、移転の条件を充足している場合には、当該資産の移転に係る処理を行う、資産管理システム。
2. 請求項１に記載の資産管理システムにおいて、
   前記資産管理部は、前記第１のユーザの死亡予想時期における保有資産の評価金額の総額を予測した第１の結果と、前記第１のユーザが死亡予想時期までに必要とする資金の総額を予測した第２の結果との差分に基づいて移転可能資産総額を算出し、前記第１のユーザに対して出力する、資産管理システム。
3. 請求項２に記載の資産管理システムにおいて、
   前記資産管理部は、前記第１のユーザに係る前記第１の結果と、前記第２の結果と、前記移転可能資産総額と、に係る情報に基づいてバランスシートの情報を作成し、前記第１のユーザに対して出力する、資産管理システム。
4. 請求項２に記載の資産管理システムにおいて、
   前記資産管理部は、前記第１のユーザの保有資産および／または必要とする資金に対して、所定の範囲の他の第３のユーザに係る資産および／または必要とする資金に係る情報を含める、資産管理システム。
5. 請求項１に記載の資産管理システムにおいて、
   前記資産管理部は、前記第１のユーザから相続により資産を移転される可能性のある前記第２のユーザにつき、前記第１のユーザに対して前記第２のユーザの保有資産に係る情報の開示を許容している場合にのみ、前記第２のユーザの保有資産に係る情報を前記第１のユーザに対して参照可能とする、資産管理システム。