JP6800513B2 - 金融資産管理システムと連携したサービスを提供するサービス提供システム - Google Patents

Description

本発明は、金融資産管理システムと連携したサービスを提供する技術に関する。

銀行、証券、保険などの各種の金融機関の口座情報を集約して、個人の資産を一元的に管理するＰＦＭ（Personal Financial Management：個人金融資産管理）システムが普及している。特許文献１には、ＰＦＭシステムに関する技術が開示されている。ＰＦＭシステムを用いると、個人の資産を正確に把握することができる。

また、ＰＦＭに類似したシステムとして、企業の収支、財務状況、資産状況を一元的に管理する会計システムも既に存在する。

特開２０１６−１４９１０３号公報

ＰＦＭシステム又は会計システムで得られた情報を用いた新しいサービスについては、これまで提案がなされていない。

本発明の一実施形態に係るサービス提供システムは、複数の種類の金融情報を集約した金融資産情報を管理する金融資産管理システムから、ユーザ又は企業の金融資産情報を取得する取得部と、前記金融資産情報に基づいて、貸し手のユーザと借り手のユーザとをマッチングさせるマッチング部とを有する。

本発明によれば、ＰＦＭシステム又は会計システムで得られた情報を用いた新しいサービスを提供することができる。

サービス提供システムを含む全体のシステム構成の一例を示す図である。 ユーザ端末で表示される画面の一例を示す図である。 ＰＦ情報の一例を示す図である。 ユーザ端末で表示される画面の一例を示す図である。 マイクロファイナンスのコンセプトの例を示す図である。 貸し手ユーザと受け手ユーザとをマッチングさせる例を説明する図である。 セグメント化の一例を示す図である。 マッチング処理の一例を示すフローチャートである。 貸し手のユーザ端末の表示部で表示される画面一例を示す図である。 リスクプレミアムを説明する図である。 情報提供部によって公開される情報の一例を示す図である。 情報公開の例を示す図である。

以下、図面を参照しながら本発明の実施形態について詳細に説明する。なお、以下の実施形態において説明する構成は一例に過ぎず、本発明は図示された構成に限定されるものではない。

＜＜用語の説明＞＞
まず、最初に本明細書で用いる用語について説明する。

ＰＦＭ（Personal Financial Management）：銀行、クレジット会社、証券、保険などの各種の金融機関の口座情報を集約して、個人の資産を一元的に管理することである。

ＰＦ（Personal Financial）情報：ＰＦＭを行うＰＦＭシステムにおいて得られる情報である。ＰＦＭシステムは、各種の金融機関のサーバと連携して情報を集約（アグリゲート）しており、ＰＦ情報は、このように複数の種類の金融機関から得られる情報が集約された情報のことを指す。ＰＦ情報には、例えば、日々の家計などの入出金情報が含まれる。この入出金情報には、使途、明細などの詳細事項が含まれる。また、ＰＦ情報には、預金、株式、投資信託などの各種の金融資産の情報が含まれる。

レンディング：お金を貸したい（投資したい）人および企業などと、お金を借りたい人および企業などとを結びつけることをいう。

ロボ・アドバイザー：コンピュータが、投資家（貸し手）のプロファイルに応じて自動的に資産運用を行うサービスのことをいう。一般に、投資家（貸し手）が複数の設問に回答することで、投資家（貸し手）のプロファイルが決定される。

サービス提供システム：本明細書で説明する主なサービスを提供するシステムのことである。例えば、レンディングや、ロボ・アドバイザーなどのサービスが提供される。

お金を貸す：サービス提供システムが提供するサービス（レンディング、ロボ・アドバイザー）に関して資金を供給することを示す。本明細書では、類似の表現として、出資、投資、貸出、貸付、資金提供、債権購入など、シーンに応じて様々な表現を用いる場合がある。

お金を借りる：サービス提供システムによって提供されるサービスによって上記の資金の供給を受けることを示す。

貸し手ユーザｎ：お金を貸したいユーザの集合、あるいは、既にお金を貸し付けたユーザの集合のことである。単に「貸し手ユーザ」と表記する場合には、単数の貸し手ユーザの場合もあれば、複数の貸し手ユーザの場合もある。

借り手ユーザｍ：お金を借りたいユーザの集合、あるいは、既にお金の貸付を受けたユーザの集合のことである。単に「借り手ユーザ」と表記する場合には、単数の借り手ユーザの場合もあれば、複数の借り手ユーザの場合もある。

＜＜目次＞＞
以下、本明細書の目次を記載する。

＜１．システム構成＞
＜２．ＰＦＭシステム／会計システムから得られる情報＞
＜２−１．貸し手に関する情報＞
＜２−２．借り手に関する情報＞
＜２−３．貸し手または借り手に関する推測情報＞
＜３．レンディング＞
＜３−１．借り手のセグメント化＞
＜３−１−１．マイクロファイナンス＞
＜３−１−２．マッチングの例＞
＜３−１−３．セグメント化の例＞
＜３−１−４．マッチングの処理シーケンス＞
＜３−１−５．マッチングのＵＩ画面＞
＜３−１−６．期待収益率＞
＜３−２．貸し手のセグメント化＞
＜３−３．目的別のレンディング（貸し手側）＞
＜３−４．目的別のレンディング（借り手側）＞
＜３−５．借り手の返済状況の管理＞
＜３−６．条件設定（貸し手側）＞
＜３−７．条件設定（借り手側）＞
＜３−８．マッチング＞
＜３−９．借り手（単数、複数） 対 貸し手（単数、複数）＞
＜３−１０．公開制度＞
＜３−１１．ＡＩへの適用＞
＜４．ロボ・アドバイザー＞
＜４−１．余剰資産の選別＞
＜４−２．ＡＩへの適用＞
＜４−３．金利情報に連動した助言＞
＜４−４．表示機能＞
上記の目次に従って、以下の実施形態を記載する。ここで、ＰＦＭシステムを用いた構成を説明するが、ＰＦＭシステムの代わりに会計システムを用いたシステムも同様に構成することができる。会計システムでは、請求書・見積書作成、売掛・買掛管理、消込処理、会計分析レポート出力、会計帳簿等の機能を有する。

＜１．システム構成＞
図１は、本実施形態に係るサービス提供システム１００を含む全体のシステム構成の一例を示す図である。このシステムは、サービス提供システム１００と、ＰＦＭシステム１５０と、ユーザ端末１６０と、金融機関サーバ１８０とを有する。

サービス提供システム１００は、各種の通信ネットワークを介してＰＦＭシステム１５０およびユーザ端末１６０と接続される。図示していないがサービス提供システム１００は、金融機関サーバ１８０と通信ネットワークを介して接続されてもよい。サービス提供システム１００の構成については後述する。

ＰＦＭシステム１５０は、ＰＦＭサービスを提供するシステムであり、ＰＦＭに関する各種のデータベースやサーバなどを総称したものである。ＰＦＭシステム１５０は、銀行、クレジット会社、証券会社などの各種の金融機関のサーバである金融機関サーバ１８０と通信ネットワークを介して接続されている。ＰＦＭシステム１５０は、ユーザからの依頼により、ユーザに成り代わって金融機関サーバ１８０のそれぞれからユーザの入出金情報や金融資産情報を取得する。ＰＦＭシステム１５０は、取得した各種の入出金情報や金融資産情報を統合する。そして、統合した情報（ＰＦ情報）をユーザ端末１６０からの要求に応じてユーザ端末１６０に送信する。また、本実施形態においては、ＰＦＭシステム１５０は、ユーザ端末１６０からの指示により、あるいは、サービス提供システム１００からの指示に応じて、ＰＦ情報をサービス提供システム１００に送信する。

ユーザ端末１６０は、貸し手のユーザおよび借り手のユーザが使用する端末の総称である。なお、貸し手のユーザが、ある場面のおいては借り手のユーザにある場合もあれば、借り手のユーザが、ある場面においては貸し手のユーザとなる場合もある。複数のユーザが一台のユーザ端末１６０を共用する場合もあれば、一人のユーザが複数のユーザ端末１６０を用いることもあり得る。ユーザ端末１６０は、パーソナルコンピュータ、タブレット、モバイル端末など任意の種類の端末であってよい。サービス提供システム１００およびＰＦＭシステム１５０は、ユーザをログイン管理しており、ログインしたユーザに固有のサービスを提供する。

金融機関サーバ１８０は、前述のように、各種の金融機関のサーバである。金融機関サーバ１８０は、多種多様の金融機関のサーバを総称したものである。

本実施形態におけるサービス提供システム１００、ＰＦＭシステム１５０、金融機関サーバ１８０は、情報処理装置として実現することができる。情報処理装置は、ＣＰＵ、メモリ、ＨＤＤ、及びネットワークインタフェースを有してよい。各システム（およびサーバ、以下同様）で行われる各種の処理は、例えば各システムのＨＤＤに格納されたプログラムが一時的にメモリに読み出され、ＣＰＵがメモリに読み出されたプログラムを実行することで実現されることができる。

次に、サービス提供システム１００の構成を説明する。サービス提供システム１００は、制御部１０１、ＰＦ情報取得部１０２、資産特定部１０３、判定部１０４、マッチング部１０５、分類部１０６、管理部１０７、指示送信部１０８、指示受信部１０９、情報提供部１１１、契約処理部１１２、モデル構築部１１３、学習モデル１１４、および資産運用サポート処理部１１５を有する。

図１に示すサービス提供システム１００の各部は、上述したように、サービス提供システム１００の図示しないＨＤＤに格納されたプログラムが一時的にメモリに読み出され、制御部１０１を構成するＣＰＵが制御部１０１を構成するメモリに読み出されたプログラムを実行することで、ＣＰＵが図１に示す各部として機能してよい。また、図１に示す各部のうちの少なくとも一部が、各種のネットワークを介して相互に接続された複数の情報処理装置によって実現されてよい。また、図１に示す各部のうちの少なくとも一部は、複数の情報処理装置による分散処理によって実現されてよい。また、情報処理装置は、図示しないクラウドサーバなどからダウンロードしたプログラムに従って処理を実行してもよい。図１は構成の一例を示したものに過ぎず、他の構成を含んでもよい。また、図１に記載された構成の全てが必須の要件であるとは限らない。

制御部１０１は、サービス提供システム１００の各種の制御を行う。制御部は、サービス提供システム１００の各部に情報やデータを伝達したり、サービス提供システム１００の全体的な処理の制御を行ったりするなどの処理を行う。

ＰＦ情報取得部１０２は、ＰＦＭシステム１５０からＰＦ情報を取得する。ＰＦＭシステム１５０からは、ユーザ端末１６０からの指示に応じて各ユーザのＰＦ情報が送られてよい。あるいは、ユーザ端末１６０からサービス提供システム１００にユーザがログイン処理を行い、そのユーザの権限をサービス提供システム１００に移譲させ、ＰＦ情報取得部１０２が、そのユーザに成り代わってＰＦＭシステム１５０にアクセスして、そのユーザのＰＦ情報を取得してもよい。取得されるＰＦ情報は、貸し手ユーザのＰＦ情報である場合もあれば、借り手ユーザのＰＦ情報である場合もある。

資産特定部１０３は、ＰＦ情報取得部１０２で取得されるＰＦ情報に基づいて資産を特定する。資産特定部１０３は、ＰＦ情報から直接的に得られる情報に基づいて資産を特定してもよいし、ＰＦ情報から間接的に得られる情報（例えば推測される情報）に基づいて資産を特定してもよい。

判定部１０４は、各種の判定処理を行う。

マッチング部１０５は、借り手ユーザと貸し手ユーザとを結びつける処理を行う。マッチング部１０５は、各種の条件に従って、借り手ユーザと貸し手ユーザとを結びつけることができる。詳細は後述する。

分類部１０６は、各種の分類（セグメント化ともいう）を行う。例えば、借り手ユーザをセグメント化したり、貸し手ユーザをセグメント化したりすることができる。あるいは、分類部１０６は、ユーザの資産を分類してもよい。

管理部１０７は、各種の管理を行う。例えば、管理部１０７は、各ユーザの管理を行う。また、管理部１０７は、レンディングで結びつけた貸し手と借り手との間の契約を管理する。また、管理部１０７は、レンディングに用いられる各種の資金を管理する。このように、管理部１０７は、各種のデータや情報の管理を行う。

指示送信部１０８は、ＰＦＭシステム１５０、ユーザ端末１６０、および金融機関サーバ１８０などに対する指示を送信する。

指示受信部１０９は、ＰＦＭシステム１５０、ユーザ端末１６０、および金融機関サーバ１８０などからの指示を受信する。

情報提供部１１１は、貸し手ユーザおよび借り手ユーザのユーザ端末１６０に各種の情報を提供する。貸し手ユーザおよび借り手ユーザのユーザ端末１６０からの要求に応じて情報を送信してもよい。また、情報提供部１１１は、各種の通知をユーザ端末１６０に通知してもよい。

契約処理部１１２は、契約を締結したり、変更したりした場合の各種の処理を行う。

モデル構築部１１３は、各種のデータに基づいて学習モデル１１４を構築する。

学習モデル１１４は、モデル構築部１１３によって構築される。構築された学習モデル１１４に各種のデータを入力すると、入力されたデータに対応するデータが出力される。

資産運用サポート処理部１１５は、資産運用をサポートする処理を行う。例えば、ロボ・アドバイザーのサービスを実行する。

なお、以降では、ユーザが、ユーザ端末１６０を用いてサービス提供システム１００に各種の指示を送ったり、ユーザが、ユーザ端末１６０を通じてサービス提供システム１００から各種の情報やデータの提供を受けたりする形態を前提に説明する。以降では、内容の説明に重点を置き、記載を簡略化して説明する場合がある。したがって、例えば「ユーザが、サービス提供システム１００に指示をする」「ユーザが、サービス提供システム１００に指示を送る」といった表現は、「ユーザがユーザ端末１６０に指示を入力し、指示を入力されたユーザ端末１６０が、その指示をサービス提供システム１００に送信する」という意味を含むものとする。また、「ユーザが、サービス提供システム１００（または、サービス提供システムに含まれる各部）から情報やデータの提供を受ける」といった表現は、「ユーザが使用するユーザ端末１６０に対してサービス提供システム１００から情報が送られ、ユーザ端末１６０の表示画面に表示された情報やデータをユーザが確認する」という意味を含むものとする。同様に、「ユーザが、資金を提供する」という表現も、「ユーザが、ユーザ端末１６０に資金を提供する指示を入力し、ユーザ端末１６０がその指示をサービス提供システム１００に送信し、サービス提供システム１００が指示に応じて資金を提供する処理を行う」という意味を含むものである。その他、「ユーザが、債権を譲渡する」などの処理も同様である。

＜２．ＰＦＭシステムから得られる情報＞
次にＰＦＭシステム１５０から得られる情報について説明する。すなわち、ＰＦ情報取得部１０２が取得するＰＦ情報について説明する。

＜２−１．貸し手に関する情報＞
ＰＦ情報取得部１０２は、ユーザ端末１６０のユーザに関するＰＦ情報を取得する。例えば、ユーザＡは、ユーザ端末１６０を通じてＰＦＭシステム１５０に対して、サービス提供システム１００にユーザＡのＰＦ情報を送信するように指示する。ＰＦＭシステム１５０は、この指示に応じてユーザＡのＰＦ情報をサービス提供システム１００に送信する。ＰＦ情報取得部１０２は、このようにして送信されたＰＦ情報を取得することができる。あるいは、ユーザＡは、ユーザＡのＰＦＭシステム１５０に対する権限をサービス提供システム１００に移譲し、ＰＦ情報取得部１０２が、ユーザＡに成り代わってユーザＡのＰＦ情報の送信要求をＰＦＭシステム１５０に送信してもよい。

ＰＦ情報取得部１０２は、ユーザのＰＦ情報が取得できればよく、詳細な情報を取得しなくてよい。例えば、銀行名、口座番号、クレジットカード番号、電話番号、生年月日、住所など、個人が特定できるような情報は、ＰＦＭシステム１５０から取得しなくてよい。ＰＦＭシステム１５０から得られる情報に、これらの情報が含まれている場合には、ＰＦ情報取得部１０２は、適宜マスク処理を施すなどした上で、これらの情報を取得してもよい。また、ＰＦ情報の中の入出金情報では、例えばＡＡＡ店などのように、店舗名が含まれる場合がある。このような情報からも、個人が特定される場合がある。そこで、ＰＦ情報取得部１０２は、カテゴリ名（例えばレストラン）に置き換えた情報を取得してもよい。このような情報の書き換えは、ＰＦＭシステム１５０で行われてもよいし、サービス提供システム１００側（例えばＰＦ情報取得部１０２）で行われてもよい。

図２は、ユーザＡが、ユーザ端末１６０を用いてサービス提供システム１００にログインした際に表示される画面２００の例を示している。例えば、ユーザＡのログイン要求指示が、ユーザ端末１６０からサービス提供システム１００に送られる。指示受信部１０９は、このログイン要求指示を受信する。制御部１０１は、管理部１０７に管理されているユーザであると特定できた場合、図２に示すような画面を、情報提供部１１１を通じてユーザ端末１６０に送信する。ユーザＡは、ユーザ端末１６０に表示される各操作ボタンをクリックないしタップする（以下、総称して押下すると呼ぶ）などによって選択することで、操作ボタンに対応する指示が、ユーザ端末１６０からサービス提供システム１００に送信されることになる。そして、その指示に応じた画面が、情報提供部１１１からユーザ端末１６０に送信され表示されることになる。画面２００においてボタン２１０がユーザによって選択された場合、余剰資産の確認処理がサービス提供システム１００において実行される。

余剰資産の確認指示が指示受信部１０９で受信されると、制御部１０１は、資産特定部１０３に資産を特定する処理を行わせる。資産特定部１０３は、ログインしているユーザＡのＰＦ情報をＰＦ情報取得部１０２から取得する。そして、取得したＰＦ情報に基づいてユーザＡの余剰資産を特定する。

図３は、ＰＦ情報の一例を示す図である。図３に示すように、ＰＦ情報には、日常的な入出金の履歴（ＰＦ情報Ｉ１）が含まれる。ＰＦ情報１の中には、詳細な明細（例えば、購入店舗名など）が含まれている場合もある。また、ＰＦ情報には、入出金の履歴だけではなく、貯金、株式、投資信託などのユーザＡが保有する各種の金融資産の情報（ＰＦ情報Ｉ２）が含まれる。資産特定部１０３は、このようなＰＦ情報を用いて余剰資産を特定することができる。ＰＦ情報によれば、ユーザの資産のほか、日常的な収支を特定することができるので、ユーザ毎の余剰資産を正確に特定することができる。情報提供部１１１は、資産特定部１０３によって特定された資産を示す情報を、ユーザＡのユーザ端末１６０に送信することができる。

図４は、ユーザ端末１６０で表示される画面の一例を示す図である。例えば、情報提供部１１１は、図４に示すように、月々の余剰資産を特定してユーザに通知したり、他の月に比べて特別な臨時収入があった月であるので、今月の余剰資産は増えていることをユーザに通知したりすることができる。これにより、ユーザＡは、自身の余剰資産を客観的に把握することができる。

＜２−２．借り手に関する情報＞
ＰＦ情報は、前述のとおり、借り手ユーザについても貸し手ユーザについても得られる情報である。借り手ユーザに対する観点から見ると、借り手ユーザは、借りたお金を返済する立場であるので、その返済を考慮した出費が行われていることが好ましい。ＰＦ情報を用いることで、借り手ユーザの返済が適切に行われているか、あるいは行うことができそうか、といったことを判定することができる。すなわち、判定部１０４は、ＰＦ情報取得部１０２で取得したＰＦ情報を、必要に応じて参照して、好ましくない状態が発生しているかを判定することができる。例えば、借金の返済のために借り手ユーザになるということは好ましくない。したがって、判定部１０４は、ＰＦ情報を参照して、借金の返済が多数あるようなユーザに対しては、借り手ユーザとは認められないと判定することができる。

＜２−３．貸し手または借り手に関する推測情報＞
資産特定部１０３は、ＰＦ情報を参照して、ＰＦ情報に含まれていない資産を特定することもできる。例えば、不動産や自動車などといった資産を特定することができる。ＰＦ情報は、入出金の明細が含まれている。この明細を参照して例えば、ユーザＡが固定資産税を支払っているような場合には、資産特定部１０３は、ユーザＡが不動産を保有していると推定できる。また、ユーザＡが自動車税を支払っているような場合には、資産特定部１０３は、ユーザＡが自動車を保有していると推定できる。また、その支払い額によって、大まかな資産も推測できる。このように、資産特定部１０３はＰＦ情報に含まれている各種の情報を用いることで、ユーザＡの余剰資産を特定することができる。

この余剰資産は、例えばユーザＡが貸し手となる場合に、無理なく出資（投資、貸金）できる金額である。また、例えばユーザＡが借り手となる場合に、不可なく返済することができる金額でもある。ここでは、画一的に余剰資産として表示する例を示しているが、ユーザＡが借り手となるのか貸し手となるかに応じて、異なる額の余剰資産を表示してもよい。

このように、ＰＦ情報に基づいて余剰資産が特定されるので、ユーザは、どの程度の額を貸したり、あるいは借りたりすることができるのかを容易に確認することができる。特に、ＰＦ情報を用いることで日々の生活の収支が正確に把握できるので、適切な余剰資金を特定することができる。例えば、ある収入が定期的な収入であるのか臨時収入であるか、などは、ＰＦ情報から特定することができる。

＜３．レンディング＞
上記で説明したように、ＰＦ情報を用いることでユーザの収支を、ユーザ自身及びサービス提供システム１００のいずれにおいても正確に把握することができる。この結果、新たなサービスの提供が可能となる。例えば、今まで投資などに興味を有していない潜在的なユーザを呼び込むことができる。また、ＰＦ情報を用いることで、余裕を持って投資などを行うことができる金額（余剰資金）を、ユーザ毎に提示することができる。このような余剰資金は、その性質上、既存の金融サービスに提供される資金とは異なる性質を有する。具体的には、余剰資金は、極端な例においては、ユーザが無くなってしまってもよいと考える性質の資金である。このような余剰資金を用いることで、様々なサービスを提供することが可能となる。

以下では、サービス提供システム１００が、お金を貸したい人および企業等と、お金を借りたい人および企業等とを結びつけるレンディングサービスを行う形態について説明する。お金を貸したいユーザは、図２のボタン２２０を押下することで、以降で貸し手ユーザとして説明する各種の処理の主体となる。お金を借りたい借り手ユーザは、図２のボタン２３０を押下することで、以降で借り手ユーザとして説明する各種の処理の主体となる。なお、図２の画面は一例に過ぎず、これに限られるものではない。

＜３−１．借り手のセグメント化＞
まず、借り手ユーザのセグメント化について説明する。セグメント化とは、ある種の単位に分類することである。本実施形態において分類部１０６は、ＰＦ情報を用いて、管理部１０７で管理されているユーザを分類（セグメント化）する。ＰＦ情報を用いることで、例えば堅実な生活支出をしているユーザであるか否かといったタイプや、不動産を保有しているか否かといったタイプなど、様々なタイプにユーザを分類することができる。堅実な生活支出をしているユーザや、不動産を保有しているユーザは、借り手になった場合に返済する可能性が高い。すなわち、借金を返済せずに踏み倒してしまう可能性が低い。このように、返済する可能性に応じて借り手をセグメント化し、そのセグメントに応じて利息を設定することができる。

貸し手ユーザは、お金を貸し出す際に、任意のセグメントを指定して、そのセグメントに属する借り手に貸すことを決めてもよい。貸し手がセグメントを指定した場合、マッチング部１０５がマッチング処理を行い、そのセグメントに属する借り手（お金を借りたいと希望しているユーザ）とのマッチングを行う。マッチングが成立した場合、マッチング部１０５は、貸し手と借り手とを結びつける。すなわち、マッチング部１０５は、契約処理部１１２にマッチングが成立した貸し手と借り手の情報を送る。契約処理部１１２は、マッチングが成立し貸し手ユーザＡと借り手ユーザＢとの間での金銭の貸借を仲介する。

なお、金銭の貸借は、様々な手法で実現することができる。例えば、サービス提供システム１００が、貸し手ユーザＡに成り代わって、貸し手ユーザＡの口座が存在する金融機関サーバ１８０から、借り手ユーザＢの口座が存在する金融機関サーバ１８０に送金処理を行ってもよい。あるいは、サービス提供システム１００が、貸し手ユーザＡの金融機関サーバ１８０から貸金を受け取ってもよい。つまり、一旦、サービス提供システム１００に資金を移動させてもよい。そして、サービス提供システム１００から、借り手ユーザＢの金融機関サーバ１８０に送金処理を行ってもよい。あるいは、サービス提供システム１００は、ＰＦＭシステム１５０を通じて上述した送金処理を行わせてもよい。本実施形態においては、任意の形態で金銭の貸借が行われよい。

＜３−１−１．マイクロファイナンス＞
次に、セグメント化の詳細例について説明する。先に説明したように、ＰＦ情報を用いることで、既存の投資ユーザのみならず、今まで投資を考えたことがないようなユーザであっても投資の意欲が出てくることが想定される。つまり、投資を行うユーザの裾野が広がる。なぜならば、日常の収支から、いわば無くなっても影響が大きくない程度の額を、各ユーザが把握できるからである。これまでは、比較的資産を有しているユーザが投資などを行う場合が多かったが、自身の資産を適切に把握できれば、比較的資産を有していないユーザであっても、少額投資を行う額を把握できる。

ここで、サービス提供システム１００のマッチング部１０５による処理に従えば、様々な条件でのマッチングが可能になる。例えば、少額の資金を大口で集めることも可能である。いわゆるマイクロファイナンス（小規模金融）を行うことが可能である。マイクロファイナンスは、貧困層に対する融資という意味合いで用いられることもあるが、本実施形態においては、単純に、少額の資金を用いた金融という意味で用いる。例えば、これまで百万円の出資を行うことができるユーザは限られた存在であったが、マイクロファイナンスを用いると、例えば千円の出資をするユーザが千人集まれば、同様の金額の出資を行うことが可能となる。しかも、このような少額の資金を用いる出資というものは、一人のユーザが出資をする場合に比べて様々なメリットがあることになる。以下、詳細に説明する。

図５は、マイクロファイナンスのコンセプトの例を示す図である。図５（ａ）は、横軸が投資額であり、縦軸が許容できるデフォルトリスク（債務不履行リスク）を示している。図５（ｂ）は、横軸が投資額であり、縦軸が、貸し手ユーザが出資したくなるリスクプレミアムを示している。リスクプレミアムとは、リスクを含む投資に対してそのリスク分に対して求める超過収益（上乗せ収益）のことである。

図５（ａ）は、投資額が大きくなるほど、許容できるデフォルトリスクは低くなることを示している。すなわち、貸し手ユーザは、大金を投資する以上、返済されない可能性が低い案件に投資する心理が働くことを示している。つまり、端的に言えば、大金を投資するのであれば、返済される蓋然性が高い案件に投資したいという心理が働くことになる。これに対して、少額を投資するような場合には、貸し手ユーザは、返済されない可能性が高い案件に投資しても構わないという心理が働く。例えば、百円や千円といった少額であれば、極端な例では、そのまま返済されなくてもよいという心理が働くことになる。

図５（ｂ）は、投資額が高いほど、出資したくなるリスクプレミアムが高くなることを示している。つまり、大金を出資する以上、出資した金額に対する上積みが高くなることを期待する貸し手ユーザの心理を示している。一方、投資額が少ない少額投資をする場合、出資した金額に対する上積みがそれ程大きくなくても構わないという貸し手ユーザの心理を示している。例えば、百円や千円といった少額を出資した場合、その出資金額に対するリスクプレミアムが３％であっても５％であっても１０％であっても、貸し手ユーザは気にしない。一方で、百万円や一千万円といった大金を出資した場合、その貸し手ユーザにとってリスクプレミアムは投資に対する重要なファクターとなる。このように、仮に、同一人であっても許容できるデフォルトリスクおよび出資したくなるリスクプレミアムというものは、投資額によって異なることになる。

典型的な例として、単独のユーザが１千万円を投資する場合と、マイクロファイナンスで多数（例えば千人）から集めた１千万円を投資する場合とを考える。マイクロファイナンスで多数から集めた資金は、その出資者にとってもいわば無くなってもよいと考えた少額資金の総計額である。無くなってもよいような額であるので、マイクロファイナンスで集めた資金に対するリスクプレミアムは低く設定することができる。一方、単独のユーザにとって大型投資となるので、図５（ｂ）に示すようにリスクプレミアムを高く設定しないと、つまり、上積み収益を高く設定しないと出資する意味（すなわち、利息分などによる利益）が出てこなくなる。

以上を整理すると、マイクロファイナンスで集めた少額資金は、無くなっても構わない資金となる。このような無くなっても構わない少額資金であっても、多数から集めることで大型投資を行うことが可能となる。無くなっても構わない大型投資であれば、リスクプレミアムを既存の金融機関等よりも低く設定しても問題がない。つまり、借り手ユーザに資金を貸し出す場合、マイクロファイナンスで集められた資金の金利などを、既存の金融機関が設定する金利などよりも低く設定することができる。借り手ユーザからすれば、マイクロファイナンスで集められた資金を借りる方が、既存の金融機関から資金を借りるよりも低い金利などで借りることが可能である。このように、マイクロファイナンスを用いることで、新しい金融サービスの提供が可能となる。

＜３−１−２．マッチングの例＞
図６を用いて、貸し手ユーザｎと受け手ユーザｍとをマッチングさせる例を説明する。なお、貸し手ユーザｎは、先に説明したように、マイクロファイナンスで集めた資金を貸すユーザの集合である。例えば貸し手ユーザＡ１、Ａ２・・・Ａｎという具合に、ｎ人で一つの集団を構成することができる。なお、ここでは説明の便宜上、集団を構成すると説明しているが、貸し手の個々のユーザＡ１、Ａ２・・・Ａｎは、他の貸し手ユーザの情報を知る必要はない。ユーザの管理やマッチングは、サービス提供システム１００の管理部１０７やマッチング部１０５が行う。

図６に示すように、本項の借り手ユーザは、各種の資金を取り扱う会社、団体などとすることができる。つまり、借り手ユーザのユーザ端末１６０は、これらの各種の資金を取り扱う会社、団体などのサーバであってよい。

図６を用いて、借り手ユーザとなり得る例を説明する。もちろん、図６に示す例に限定されるものではない。借り手ユーザは、特定の種類の債権などを引き渡し、代わりに資金を得る企業、機関、団体などが考えられる。サービス提供システム１００の分類部１０６は、これらの特定の種類ごとに借り手を分類（セグメント化）することができる。なお、後述する図７で説明するセグメント化と区別して、特定の種類毎に借り手を分類することを第一のセグメント化と呼ぶ。以降で詳細を説明するように、貸し手ユーザｎは、既存の金融機関などよりも有利な条件で（例えば安い金利で）債権を受け取り、資金を提供することができる。したがって、新しい金融サービス、あるいは既存の金融機関などから置き換わるような金融サービスを、サービス提供システム１００が提供することが可能となる。

借り手ユーザの一例として、例えば電子債権の保有者を例に挙げる。電子債権は、でんさいネット上などで流通するもので、手形の一種である。手形は、期限が到来したら現金に換金することができる。その一方で、手形の振出元が、例えば倒産するなどして債務不履行になった場合、その手形を換金することができない。つまり、手形には、このようなデフォルトリスクが存在する。既存の金融機関（例えば銀行）では、このようなリスクを考慮した手形の割引率（手形の現在価値）を設定したうえで、その手形を支払期日前に買い取ることが行われている。これに対して、マイクロファイナンスの貸し手ユーザｎは、先に説明したように、リスクプレミアムを低く設定することができるので、既存の金融機関が設定する割引率よりも低く割引率を設定することができる。この理由は、＜３−１−１．マイクロファイナンス＞で説明したように、いわばマイクロファイナンスの貸し手ユーザｎは、無くなっても構わない少額投資のユーザの集合体であるので、同一金額に対して金融機関などが設定するリスクプレミアムよりも低いリスクプレミアムであっても出資意欲があるからである。

例えば、ある電子債権に対して、支払期日前に既存の銀行が額面の９０パーセントの金額で債権を買い取るような場合に、マイクロファイナンスの貸し手ユーザｎであれば、例えば額面の９５パーセントの金額でその債権を買い取ることができる。つまり、借り手（電子債権の債権者）にすれば、マイクロファイナンスの貸し手ユーザｎの方が、より高い金額で電子債権を引き取ってもらえることになる。

なお、債権を引き取った場合、名義の書き換えが行われる。本実施形態では、例えばサービス提供システム１００の管理部１０７が仮想口座や仮想名義などを管理しているものとする。そして引き取った債権の名義を、このサービス提供システム１００の仮想名義に書き換えることができる。この仮想名義には、その債権の引き取りに際して出資したユーザ、つまり、貸し手ユーザｎのそれぞれが対応付けられる。このように、実際に資金を提供した貸し手ユーザｎの名義ではなく、サービス提供システム１００に関連する名義に変更することで、後述するように貸し手ユーザｎの一部のユーザに変更が生じるような場合などにおいて、さらなる名義変更を行わずに済む。しかしながらこの例に限られるものではない。引き取った債権を、貸し手ユーザｎのそれぞれの共同名義に書き換える形態でもよい。

次に、借り手ユーザが、金融機関や奨学金などのローンを借りようとしている形態を説明する。先に説明したように、本実施形態のマイクロファイナンスの貸し手ユーザｎは、通常の金融機関などよりもリスクプレミアムが低くても投資したいという心理を有する。したがって、金銭消費貸借契約を結んでお金を借りたいという借り手ユーザは、既存の金融機関などよりも低い金利が設定されている、本実施形態のマイクロファイナンスの貸し手ユーザｎから資金を借りることができる。

次に、クレジットカードの利用形態を説明する。クレジットカードのカード利用者は、店舗等においてカードで商品等の支払を行う。この場合、店舗等は、クレジットカード会社に対する債権を有することになる。そして、店舗等は、一定の期日後に、カード会社から金銭の支払いを受ける。このとき、一般に店舗等はカード会社に手数料を支払う。本実施形態においては、このカードの債権を、マイクロファイナンスの貸し手ユーザｎが引き受ける形態を採用することができる。先に説明したように、本実施形態のマイクロファイナンスの貸し手ユーザｎは、通常の金融機関などよりもリスクプレミアムが低くても投資したいという心理を有する。したがって、既存のクレジットカード会社よりも安い利用料を設定することが可能であるので、クレジットカードの加盟店舗は、本実施形態のマイクロファイナンスの貸し手ユーザｎに債権を譲渡することも考えられる。つまり、いわばマイクロファイナンスの貸し手ユーザｎが、カード会社の役割を引き受けることも可能である。

次に、社債の利用形態を説明する。例えば、社債を発行して資金を調達しようと考えている会社がある。本実施形態のマイクロファイナンスの貸し手ユーザｎであれば、一般的な市場で要求される利回りよりも低い利回りで、その社債を引き受けることができる。したがって、引き受け手が見つからないような場合であっても、本実施形態のマイクロファイナンスの貸し手ユーザｎであれば、そのような引き受け手となることができる。

次に、投資信託の利用形態を説明する。本実施形態のマイクロファイナンスの貸し手ユーザｎは、先に説明したように、少額資金を用いることになる。したがって、例えば従来であれば１口１万円で運用しているような状態であるところを、１口１００円で運用することができる。一般に、リスクとリターンとは、比例関係がある。つまり、リスクが高ければ上がればリターンが増える。リスクが下がればリターンも減る。本実施形態のマイクロファイナンスの貸し手ユーザｎは、少額資金を用いた運用をすることができるので、高いリスクを採ることができる。つまり、無くなっても構わない金額なので、リスクが高くても気にしない傾向がある。したがって、少額資金を多数で集めて、期待利回りが高い投資信託を行うことができる。

以上説明したように図６で示す電子債権、ローン、クレジットカード、社債、投資信託などのように、借り手の種類をセグメント化することができる（第一のセグメント化）。また、図６に示す例に限られることはなく、任意のセグメントを設けることができる。

＜３−１−３．セグメント化の例＞
図６では、借り手ユーザの種類を説明した。貸し手は、貸し出し先の特定の種類の借り手ユーザを決定して、その特定の種類の借り手ユーザに出資をしてもよい。つまり、借り手ユーザの種類（例えば電子債権）を指定して出資をしてもよい。しかしながら、ある特定の種類に貸し手が出資すると、出資するタイミングによって不公平が生じる可能性がある。例えば、マッチング部１０５が、申込みが行われた順番で個別にマッチングをすると、当たり外れが出てしまうことがある。つまり、貸し手ユーザＡ１はきっちり返済される債権に当たったが、貸し手ユーザＡ２は不良債権に当たってしまうこともある。これを解消するために、テーマ毎にカテゴリを作ることができる。テーマ毎にカテゴリを作ることを第二のセグメント化と呼ぶ。

なお、セグメント化とは、ある分類毎に分かれていればよいので、先に説明したように、借り手ユーザの種類毎に分かれていてもよいし、これから説明するように特定のカテゴリ別に分かれていてもよい。つまり、セグメント化には、第一のセグメント化および第二のセグメント化が含まれる。

図７は、セグメント化（第二のセグメント化）の一例を示す図である。この例では、カテゴリとして「地域振興（日本）」、「進学・留学」、および「スポーツ」の３つのカテゴリを設定している例を示している。「地域振興（日本）」のカテゴリの中には、ある地域Ｒ１の会社の社債であったり、その地域Ｒ１の電子債権であったり、その地域Ｒ１のクレジットカードの加盟店などの債権が含まれている。「進学・留学」のカテゴリの中には、あるユーザのローン債権などが含まれている。「スポーツ」のカテゴリの中には、あるスポーツＳ１に関する用具代の債権や、そのスポーツＳ１に関するスポーツ留学を目的とするローン債権や、そのスポーツＳ１のプロスポーツチームの運営費などが含まれている。なお、図７で示すようなカテゴリは、例えば予め分類部１０６によって作成されている。あるいは、借り手ユーザまたは貸し手ユーザがサービス提供システム１００にアクセスして、任意のカテゴリを作成してもよい。

図７の例においては、「地域振興（日本）」のカテゴリに対して複数のユーザから成る貸し手ユーザｎが出資をしている例を示している。図７では簡略的に２人を例に示しているが、例えば２００人や２０００人といったように、多数のユーザから成る貸し手ユーザｎによる出資が行われてもよい。

本実施形態においては、この「地域振興（日本）」のように、あるカテゴリに含まれる各債権を集合債権として扱う。そして、貸し手ユーザｎを構成するそれぞれのユーザは、不可分債権を有することになる。それぞれのユーザが分割債権を有することとしても良い。貸し手ユーザｎは、「地域振興（日本）」のカテゴリに対して出資を行う。つまり、貸し手ユーザｎは、「地域振興（日本）」に含まれる個々の債権を具体的に指定して出資を行うわけではない。このようにセグメント化をすることで、ある種の曖昧さが醸成されることになる。このため、例えば「地域振興（日本）」に含まれる個々の債権のうち、返済がなされるものものあれば、返済がなされないものもあり得るが、貸し手ユーザｎを構成するそれぞれのユーザが不公平感を感じることを低減できる。

図８は、図７で示すカテゴリに対して出資が行われる場合のマッチング部１０５によるマッチング処理の一例を示すフローチャートである。

ステップＳ８１０において、マッチング部１０５は、所定のカテゴリｋについての債権Ｙ（ｊ）円を仮取得する。具体的には、カテゴリｋは、図７の「地域振興（日本）」の例であるものとして説明をする。図７の「地域振興（日本）」では、３つの債権が含まれているので、ｊ＝１，２，３となる。つまり、ステップＳ８１０では、所定のカテゴリｋに属するそれぞれの債権を仮取得する。

ステップＳ８２０において、マッチング部１０５は、所定のカテゴリｋについて、貸し手ユーザｉから出資Ｘ（ｉ）を受け付ける。ここでは一口１００円であるものとする。

ステップＳ８３０において、マッチング部１０５は、ステップＳ８２０で受け付けた出資総額が、ステップＳ８１０で仮取得した債権の債権額に達した場合、契約処理部１１２に通知する。ここで、出資総額は、１００（円／口）＊ｓｕｍ Ｘ（ｉ）（ｉ＝１〜ｎ）（口）である。また、仮取得した債権の債権額Ｙ（ｊ）＋α円に達した場合、契約処理部１１２に通知してもよい。ここで、α円は、解約率ｒ(%)を想定したもので、（Ｙ（ｊ）＋α）＊（１００−r）／１００＝Ｙ（ｊ）である。

契約処理部１１２は、この通知を受けて、その債権を本取得する。すなわち、でんさいネット上などで、その債権の名義書換を実行する。なお、先に説明したように、名義の書き換えは、管理部１０７で管理する仮想口座、仮想名義（仮の名義）に変更する形態でもよいし、貸し手ユーザの共同名義に書き換える形態でもよい。仮想名義に変更しておくと、それぞれのユーザが分割債権を有し、出資途中で貸し手ユーザが変更になった場合においても、でんさいネット上で、都度債権者の変更処理をせずに済む。契約処理部１１２は、契約の変更を実行する処理を行う。例えば、金融機関サーバなどに所定の通知を送ってもよい。このステップＳ８３０は、例えば１日単位で繰り返し行われてもよい。つまり、１日単位で出資額を受け付け、本取得できない場合には、契約が不成立となり、翌日に再度、ステップＳ８１０において債権を仮取得する処理を行ってもよい。

ステップＳ８４０において、契約処理部１１２は、ステップＳ８３０で本取得した債権に集合債権を設定する。この債権額Ｓ（ｋ）は、[ｓｕｍ Ｙ（ｊ）（Ｊ＝１〜ｍ）]円となる。すなわち、図７の「地域振興（日本）」の場合であれば、ｍ＝３で、３つの債権の総額が集合債権となる。例えば、債権ｅ１ａが１万円、債権ｅ１ｂが１０万円、債権ｅ１ｃが３千円とする。すると、これらの合計の１１万３千円が集合債権となる。

ステップＳ８５０は、その後の返済を含む、収益が得られた場合の処理である。ステップＳ８５０において管理部１０７は、得られた収益を持分に応じてそれぞれのユーザに分配する。例えば、ステップＳ８４０で設定した債権額Ｓ（ｋ）をそれぞれのユーザが出資した債権の口数で割る。すなわち、ステップＳ８４０においては、それぞれのユーザ自身が出資した金額の比率に応じて分配がされる。例えば、債権ｅ１ｂが返済不能となった場合、債権ｅ１ｂは回収不能金になる。債権ｅ１ａが満期になっており、債権ｅ１ｂは割引率に応じたプレミアム（利息）が加算されて回収される。債権ｅ１ｃは期限が未到来であるので、債権ｅ１ｃは回収されない。このような場合、債権ｅ１ａに関する分配が、そのカテゴリｋに出資したユーザに対してなされることになる。

マッチング部１０５は、このような処理を、カテゴリごとに対して行う。

以上のように、複数のカテゴリにセグメント化を行い、そのカテゴリに対して出資する形態を採用することにより、貸し手ユーザの不公平感を緩和することができる。カテゴリとして、特定の目的や特定の種類に特化したカテゴリを設けることで、貸し手ユーザｎは、自分の希望するカテゴリに積極的に出資することができる。例えば、スポーツが好きな貸し手ユーザは、半ば寄付のような気持ちで「スポーツ」のカテゴリに出資することもできる。

図９は、貸し手のユーザ端末１６０で表示される画面９００の一例を示す図である。図９では、各カテゴリ別に、出資額と回収額とをグラフ表示するとともに、その額を数字で表示している。また、各フラグは、凡例９１０に示すように、「回収期限未到来」のものと「回収不能」のものと「回収済」のものとが分かるように、色、濃度、パターンなどが変更して表示される。また、トータルの額を示す領域が表示されている。図９に示すような画面を用いることで、貸し手は、自身の出資している額と回収した額とを、カテゴリ別に確認することができる。また、複数のカテゴリに出資している場合には、そのトータルの出資額と回収額とを確認することができる。貸し手は、「追加出資」ボタン９２０を押下することで、所望のカテゴリに追加出資することができる。また、「カテゴリを追加」ボタン９３０を押下することで、カテゴリを追加できる。カテゴリが追加される場合、追加されるカテゴリが既存の表示されているカテゴリの上下左右のいずれかに追加されてよい。

図９の画面９００に表示される画像は、出資決定機能、出資金決定機能、期待収益率表示機能、回収金表示機能、または出資カテゴリ追加機能を有する電子計算機で表示される画像である。また、図９の画像は、情報入力操作用画像、機能実行操作用画像、情報閲覧表示用画像、または複合画像である。

また、画像の各カテゴリには、期待収益率が表示されても良い。その場合、貸し手は、出資するか否かの判断基準の一つとして期待収益率を用いることができる。

＜３−１−６．期待収益率＞
次に、期待収益率の算出モデルの例を説明する。ここでは、期待収益率をＲ（ｋ）（ｔ）と表す。ここで、ｋは、先に説明したように、カテゴリである。ｔは、日時である。つまり、期待収益率Ｒ（ｋ）（ｔ）は、カテゴリごとに異なるものであり、また、日時に応じても異なるものである。期待収益率は、以下の式（１）で表すことができる。

期待収益率R(k)(t)=[1/(1-割引率r(k)(t))]*(1-デフォルト率D(k)(t))*100(%)
式（１）
ここで、割引率r(k)(t)は、以下の式（２）で求められる。

割引率r(k)(t)=無リスク金利r0(t)+リスクプレミアムp(k)(t) 式（２）
この無リスク金利r0(t)は、例えば国債の金利を用いることができる。

また、デフォルト率D(k)(t)は、以下の式（３）で求められる。
デフォルト率D(k)(t)=Average(D(k)(t)(t=1,…t-1)) 式（３）

つまり、デフォルト率は、そのカテゴリの過去の平均値を用いることができる。式（１）から式（３）に示すように、期待収益率Ｒ（ｋ）（ｔ）は、リスクプレミアムｐ（ｋ）（ｔ）に依存することが分かる。

ここで、リスクプレミアムp(k)(t)については、たとえば、以下の式（４）の関係が成り立つように設定することができる。

△|出資額X(k)(t)-(申込)債権額Y(k)(t)|/△リスクプレミアムp(k)(t)=0 式（４）

図１０は、上記の式（４）を説明する図である。つまり、リスクプレミアムが高ければ、出資（貸す）側は貸す額が増える。その一方、借りる側が借りる額は減る。逆に、リスクプレミアムが低ければ、出資（貸す）側は貸す額が減る。その一方、借りる側が借りる額は増える。このように、リスクプレミアムは、貸す側と借りる側との間ではトレードオフの関係になっている。そして、貸す側と借りる側との間で釣り合う部分が、設定すべき好適なリスクプレミアムであると考えることができ、上記の式（４）は、この考えにしたがっている。このような好適な値は、たとえば過去のそのカテゴリの出資金と債権額との関係から求められる。あるいは実証実験などを通じて得たデータを教師データとして、ＡＩなどを用いて求めても良い。

割引率r(k)(t)の別の例は、以下の式（５）で求められる。

割引率r(k)(t)=Average(r(k)(t)(t=1,…t-1)) 式（５）

割引率r(k)(t)のさらに別の例は、借り手が割引率を提示して借入を申し込むことを前提に、カテゴリkに属する(申込)債権jについて提示された割引率r(k)(t)(j)の平均として、以下の式（６）で求められる。

割引率r(k)(t)=Average(r(k)(t)(j)(j_∈k)) 式（６）

なお、＜３−１−１．マイクロファイナンス＞の項で説明したように、マイクロファイナンスの貸し手ｎの所望するリスクプレミアムは、既存の金融機関や市場のリスクプレミアムよりも低くなることが想定される。したがって、例えばサービス提供システムのプラットフォーム利用料を上乗せしたとしても、既存の金融機関や市場のリスクプレミアムよりも低い額で運用することが可能である。

＜３−２．貸し手のセグメント化＞
上記の＜３−１＞の項目では、借り手ユーザのセグメント化について説明してきた。本項目においては、貸し手ユーザのセグメント化を説明する。本実施形態においては、分類部１０６が貸し手ユーザを分類してセグメント化をする。例えば、貸し出す際の利息などの貸し出し条件や、貸し手ユーザの余剰資産の額など、様々な条件で貸し手ユーザを分類する。そして、マッチング部１０５は、同じ分類（セグメント）に属する貸し手ユーザｎ（個々の貸し手ユーザの集合）を、借り手ユーザとマッチングさせる。似たような貸し出し条件のユーザをセグメント化することができるので、貸し手ユーザｎのうちの例えばユーザＡ３が急遽資金が必要になったので、資金を引き上げたいような場合にも、マッチング部１０５は、同じセグメントに属する別の貸し手ユーザＡＸに資金の提供の意思があるかを速やかに確認することができる。打診を受けた貸し手ユーザＡＸは、貸し出し条件などは、基本的に自身が希望するものと同等の内容であるので、意思決定が迅速に行われる。この貸し手ユーザＡＸに資金の提供の意思があれば、契約処理部１１２が速やかに貸主を変更することができる。

＜３−３．目的別のレンディング（貸し手側）＞
次に、借り手ユーザが使用目的を明示し、それに応じて貸し手ユーザがお金を貸す例を説明する。なお、＜３−１＞で説明したセグメント化と部分的に似た内容ではあるものの、本項では、借り手ユーザは、複数の借り手ユーザの集合である必要はない。本項では、単独の借り手ユーザの場合を例に挙げて説明する。

本項の形態では、情報提供部１１１が、借り手ユーザの情報を公開する。例えば、借り手は、特定の資金目的をサービス提供システム１００に登録しておき、情報提供部１１１は、この情報を公開する。貸し手ユーザは、情報提供部１１１によって公開されている情報に基づいて、特定の資金目的を有する借り手ユーザを見つけ出す。

図１１は、情報提供部１１１によって公開される情報の一例を示す図である。借り手ユーザは、自身が資金を借りたい目的を登録している。図１１は、このように登録された情報がリスト化された例を示している。貸し手ユーザの中には、特定の資金目的のユーザを応援したいという気持ちを持つユーザもいる。そこで、貸し手ユーザは、このような特定の目的のユーザに資金を提供する旨の指示をサービス提供システム１００に送信する。マッチング部１０５は、この指示に基づいてマッチングを行い、契約処理部１１２が契約を行う。

このような特定目的で資金を借りた場合、サービス提供システム１００は、借り手ユーザのＰＦ情報のうち、その特定目的に関連する項目の一部を抜粋して貸し手ユーザに対して、情報公開してもよい。図１２は、このような情報公開の例を示す図である。この例では、借り手ユーザＸＸＸ１が気象予報士の資格の取得を目的として資金の提供を受け付けた場合の例である。このとき、情報提供部１１１は、その借り手ユーザＸＸＸ１のＰＦ情報Ｉ３の中から、資格取得に関連しそうな項目のうち、個人が特定される恐れのある情報をマスクして、貸し手ユーザに公開する。図１２の例では、資格講座に振り込みをしたという内容と、書籍を購入したという情報とが貸し手ユーザに公開されている。詳細な日時や購入店舗の情報は公開されない。貸し手ユーザの立場から見ると、自身が提供した資金がその目的に使用されていることがわかるので、安心感が得られる。また、このような特定目的で使用する場合には、貸し手ユーザは、借り手ユーザの後援者のような気分を味わうことができる。したがって、例えば、借り手ユーザの個人情報を知ることはないものの、その借り手ユーザの努力、成長、目標達成などを共有することができる。したがって、貸し手ユーザに対して、単にお金を貸し出すというだけではなく、借り手ユーザを応援するなどといった感情移入を喚起させることもできる。

上記の例は、借り手ユーザが個人の目的の場合を例に挙げて説明したが、会社、団体などの各種の組織、事業体などが特定の目的を有する借り手ユーザとなってもよい。

また、借り手ユーザの目的によっては、金利を変動金利にしてもよい。例えば、特定の目的が事業資金の場合には、成功報酬型にしてもよい。つまり、貸し手の元本を保証した上で、貸出期間の間、借り手ユーザである会社の営業利益×所定率を金利としてもよい。

また、特定の目的の中には、サービス提供システム１００を通じて、他のユーザに資金を貸し出す目的も含まれる。つまり、借り手ユーザは、自身が貸し手ユーザとなるために資金を借りる目的であってもよい。

例えば、借り手ユーザＢ３は、過去に複数回、資金を借りており、常に滞りなく返済を行う、信頼性の高いユーザであると想定する。信頼性が高いユーザは、例えば後述するように、金利を安く設定することもできる。ここでは、この借り手ユーザＢ３が、貸し手ユーザＡ３から金利３％で１００万円を借りたと想定する。借り手ユーザＢ３は、今度は自身が貸し手となり、例えば別の借り手である借り手ユーザＣ３に対して、金利５％で１００万円を貸し出してもよい。つまり、借り手ユーザＢ３は、金利３％で資金を借り、自身が貸し手ユーザとなって金利５％で貸し出すといったことも可能である。なお、この場合、借り手ユーザＢ３は、自己資金の１００万円に、貸し手ユーザＡ３からの１００万円を加え、合計２００万円を借り手ユーザＤ３に貸し出してもよい。

＜３−４．目的別のレンディング（借り手側）＞
上記の＜３−３＞においては、借り手ユーザが目的を公開して、その目的に賛同を示す貸し手ユーザが資金を貸し出す例を説明した。本項においては、貸し手ユーザが資金を貸し出したい目的を公開する。借り手ユーザは、その目的に応じて資金を借りることができる。

例えば、貸し手は、自分が行きたい店に行って、指定する料理を食べて写真を撮って欲しいと考えている場合、その条件を公開する。借り手は、公開されている条件を確認し、引き受ける場合には、その旨を、ユーザ端末１６０を通じて指示する。マッチング部１０５は、指示受信部１０９で受信した指示に基づいて、マッチングを行う。借り手ユーザは、その後、その使用目的を遂行する。ここで、借り手ユーザのＰＦ情報は、情報提供部１１１によって貸し手ユーザに公開されてもよい。なお、全てのＰＦ情報が公開されるのではなく、使用目的に関連する項目が、個人を特定しないような態様で公開されてもよい。借り手ユーザの生活収支はＰＦ情報で正確にわかるので、借り手ユーザが実際に使用目的を遂行したか否かは、ＰＦ情報に基づいて判断できる。例えば、情報提供部１１１が、借り手から受け取った飲食写真の証拠画像を貸し手に送信するような場合、貸し手ユーザは、ＰＦ情報を参照することで、確かにその店で飲食した写真であることを、貸し手ユーザが判断できる。例えば、ネット上の画像を合成して嘘をついていないかなどを確認することができる。

なお、ここでは、ＰＦ情報が貸し手ユーザに公開され、貸し手ユーザが使用目的を遂行したかを判断する形態を説明したが、サービス提供システム１００の判定部１０４が判定を行ってもよい。すなわち、契約設定された使用目的と、借り手ユーザのＰＦ情報とに基づいて、判定部１０４が、使用目的が遂行されたであろう度合いを判定し、情報提供部がその情報を貸し手ユーザに公開してもよい。

なお、貸し手ユーザは、資金の目的に、希望返済率を併せて公開してもよい。つまり、貸し手ユーザが所望する目的を達成してもらえるのであれば、元本を返済されなくてもよいと考えるユーザもいる。したがって、目的の達成度に応じて返済額を変えるように構成してもよいし、その情報を公開してもよい。

＜３−５．借り手の返済状況の管理＞
次に、借り手ユーザの返済状況の管理について説明する。主に管理部１０７で行われる処理となる。管理部１０７は、日々、借り手ユーザとなっているユーザのＰＦ情報を取得する。ＰＦ情報を参照することで、借り手ユーザの生活の実体を把握することができる。例えば、出費が継続的に高まっているような場合には、情報提供部１１１が借り手ユーザに注意、あるいは改善を促すメッセージを通知する。なお、返済のために他の金融機関から借りるのは好ましくない。したがって、ＰＦ情報に基づいて、他の金融機関とのやり取りが増えた場合には、借り手ユーザに警告を出してもよい。

なお、管理部１０７は、警告を出すとともに、契約処理部１１２に返済がされない可能性があることを知らせる。このように返済が困難になっているような状況においては、契約処理部１１２が契約の変更可能性を検討し、契約を変更してもよい。つまり、借り手ユーザと貸し手ユーザとの仲裁を行う。例えば、追加手数料（所定額や金利追加）を借り手ユーザが負担することで返済計画を見直すことができる（１か月保留や返済期間の延長）。このとき、仲裁が上手くいかない場合には、契約処理部１１２は、新規の貸し手ユーザの参加を募り、参加を表明した貸し手ユーザを当事者として参加させてよい。契約処理部１１２は、借り手ユーザに代わり新規の貸し手ユーザに現在の貸し手ユーザに対する全額返済を行わせる。新規の貸し手ユーザは、現在の貸し手ユーザから債権を譲渡して貰う。なお、借り手ユーザ側が新規の貸し手ユーザとのマッチングをマッチング部１０５に依頼する指示を送り、マッチング部１０５が新規の貸し手ユーザを見つけ出す処理を行ってもよい。

また、契約の中には、所定時期に全額を返済する一括返済を採る場合もあれば、毎月一定程度返済する方法も採る場合もある。毎月返済の場合には、貸し手側に金利が上乗せされた資金が振り込まれることになるが、この返済金を同一の借り手にそのまま貸し出してもよい。これにより、実質的に返済期間を猶予することになる。

＜３−６．条件設定（貸し手側）＞
借り手ユーザは、資金を借りる際に、各種の条件を設定することができる。例えば、返済条件、担保条件などである。これらの条件は、情報提供部１１１によって、個人が特定されない形態で公開される。貸し手ユーザは、公開情報を見て、所望する借り手ユーザを決定することができる。

＜３−７．条件設定（借り手側）＞
貸し手ユーザは、資金を貸す際に、各種の条件を設定することができる。貸し手は、貸金の対象として、過去の返済実績がある借り手や、過去の返金遅延がない借り手などの条件を設定できる。また、貸金の上限、借り手ユーザの学歴、年齢などを設定することもできる。また、例えば、貸し手ユーザは、借り手ユーザの生活状態を貸金の条件に含めてもよい。例えば、ギャンブルをしていないや、不必要な高級品を購入などである。これらの情報は、ＰＦ情報から特定することができるので、判定部１０４は、このような条件に合致するのか否かを判定することができる。なお、これら条件は情報提供部１１１によって、個人を特定しない形態で公開される。借り手は、公開情報を見て、貸し手を決めてよい。つまり、ＰＦＭシステムや会計システムからの情報を分析することで、個人特性や企業特性を把握した上で、借り手を特定又は決定することを容易に行うことができる。

＜３−８．マッチング＞
マッチング部１０５は、上記で示したようなマッチングを行うことができる。例えば貸し手ユーザの条件と借り手ユーザの条件とが一致した場合に、両者をマッチングする。そして、契約処理部１１２に通知する。マッチング部１０５は、先に説明したように、様々な情報に基づいて行うことができる。また、マッチング部１０５は、設定された各種の条件に基づいて、お勧めの相手ユーザや、お勧めのプランなどを各ユーザに提供してもよい。

＜３−９．借り手（単数、複数） 対 貸し手（単数、複数）＞
これまで説明したように、本実施形態においては、様々な形態の契約が成り立つ。例えば、以下の通りである。
（１）借り手ユーザが単数：貸し手ユーザが単数
（２）借り手ユーザが複数：貸し手ユーザが単数
（３）借り手ユーザが単数：貸し手ユーザが複数
（４）借り手ユーザが複数：貸し手ユーザが複数
このうち、貸し手ユーザが複数の場合に、市場の活性化が期待できる。つまり、先に説明したように、貸し手ユーザが複数（多数）であれば、個々のユーザが少額の出資をしたとしても、その総額は非常に大きくなる場合がある。また、このような少額を出資することは、個々のユーザの負担が小さい。これまでも特定の目的に対して寄付ないし出資をすることは行われているが、個々のユーザはどの程度の出資額であれば負荷がないのか、あるいは適切な出資額なのかが正しく把握できず、かつ、出資の敷居も高かった。しかしながら、本実施形態のサービス提供システムを用いると、個々のユーザのＰＦ情報から適切な金額をユーザは把握することができる。また、希望する出資先を容易に探し出すことができる。したがって、これまで金融資産の活用が十分にされていない層のユーザを掘り起こすことができ、金融資産の流動性を高めることができる。

また、貸し手が複数人からなるグループを構成する場合に、複数の方法が考えられる。一の貸し手が他の貸し手を募集したり、招集したりすることができる。一の貸し手が他の貸し手を検索する場合には、これまでの実績を見て抽出することができる。例えば、過去の貸し出し実績件数が所定件数以上であり、且つ、回収率が１０５％を超えているなどである。実績件数、回収率、完済件数、未完済件数、完済率、未完済率を抽出条件とすることができる。このようにグループを構成して、グループで一又は複数の借り手に融資することで、全体で融資額を増額することができると共に、リスクを分散することができる。グループで借り手を特定する手法としては、グループのリーダー若しくは各メンバーが候補となる借り手を見つけ、他のメンバーに紹介することで借り手を追加する。

＜３−１０．公開制度＞
情報提供部１１１は、借り手ユーザや貸し手ユーザの各種の条件を広く公開する例を説明した。また、借り手ユーザや貸し手ユーザの契約の相手方の情報を、特定の目的に応じて相手方ユーザに公開する例を説明した。

情報提供部１１１は、特定の目的に依らず、借り手ユーザのＰＦ情報を貸し手ユーザに公開してもよい。公開するレベルは、個人が特定されないレベルの情報を公開する。そうでない情報は、例えばチェーン店名プラス店舗名のような支出が記載されている場合、単に「レストラン」とカテゴリ名を表示させるなどの工夫をした上で、公開してもよい。日々の状況を適宜確認することができるので、貸し手ユーザにとってみると、借り手ユーザの日々の生活、成長などの垣間見ることができるので、あたかも借り手ユーザを育成しているかのような疑似体験をすることもできる。また、このような情報を公開する代わりに、金利を安く設定するなどしてもよい。

また、貸し手ユーザを積極的に広く公開してもよい。例えば、社会貢献が大きい貸し手ユーザ、例えば、金額を多く貸している貸し手ユーザ、あるいは、多数の人に貸し付けを行っている貸し手ユーザを、公開してもよい。

＜３−１１．ＡＩへの適用＞
サービス提供システム１００で行われる各種のサービスのデータを用いてモデル構築部１１３が学習モデル１１４を構築してもよい。つまり、いわゆる人工知能にこれまでのデータを覚え込ませてもよい。例えば、サービス提供システム１００が行っている金銭の貸し出し情報に関する情報（例えば、適切な返済をするのか、返済が遅れるのか、返済できないのかなど）と、ＰＦ情報から得られる支出情報（生活支出）とを用いて学習モデル１１４を構築してもよい。このように構築された学習モデル１１４にＰＦ情報を入力すると、返済の可能性を示すデータが学習モデル１１４から出力される。判定部１０４は、この結果に基づいて、返済の可能性を判定し、返済が滞りそうな場合には、情報提供部１１１に通知させてもよい。

＜＜４．ロボ・アドバイザー＞＞
これまでは、サービス提供システム１００がレンディングのサービスを提供する形態を説明した。本項以降では、サービス提供システム１００がロボ・アドバイザーのサービスを提供する形態を説明する。例えば、図２のボタン２４０を押下することで、ユーザは以降で説明するロボ・アドバイザーのサービスの提供を受けることができる。

なお、サービス提供システム１００の構成は、図１に示したレンディングのサービスを提供する構成と同様とすることができる。

＜４−１．余剰資産の選別＞
先に説明したように、ＰＦＭシステム１５０から得られるＰＦ情報を用いることで、余剰資金を特定することができる。資産特定部１０３は、余剰資産を特定する。分類部１０６は、特定した資産をさらに分類することができる。例えば、余剰資金のうち、老後に備える長期的な観点の資金、旅行資金に用いる短期的な観点の資金、あるいは、完全な余剰といった将来的な観点がない資金などに分類することができる。資産運用サポート処理部１１５は、この分類結果に従って、資産運用を行うことができる。例えば、長期的な観点の資金は、安定的な長期運用に回す一方、将来的な観点がない資金は、リスクが高い投資運用に回すなど、柔軟な資産運用を行うことができる。なお、日々の生活に応じて余剰は変動し得るものである。したがって、ＰＦ情報に基づいて適宜分類される資金が変動する。資産運用サポート処理部１１５は、変動する資金に応じて運用を適宜変更してもよい。

＜４−２．ＡＩへの適用＞
本項においては、モデル構築部１１３は、例えば著名な投資家やレビュー数の多いユーザの学習モデル１１４を構築する。資産運用サポート部は、このように構築された学習モデルを用いて資産運用を行ってもよい。例えば、ユーザは、著名な投資家のうちの所望する投資家の学習モデル１１４を選択する指示を、ユーザ端末を介して送ってもよい。

＜４−３．金利情報に連動した助言＞
資産運用サポート処理部１１５は、各種の金利情報と連動して、ユーザに助言のメッセージを送信してもよい。例えば、金利が非常に低いような場合には、お金を借りてでも投資をすることを助言してもよい。

＜４−４．表示機能＞
自身が保有する資産に関連するようなニュースがあった場合、資産運用画面中において表示する（あるいはリンクを張る）処理をしてよい。資産運用画面に併せて関連するニュースを表示させることで、ユーザは様々な情報を得ることができるので、適切な投資判断を行うことができる。

以上の例においては、サービス提供システム１００がレンディングサービスを行う場合や、ロボ・アドバイザーを行う場合を説明した。サービス提供システム１００は、これらの両方を実行してもよいし、いずれかを実行してもよい。

上述した実施形態の機能を実現するための各部は、例えばハードウェアまたはソフトウェアによって実装することができる。ソフトウェアによって実装される場合、ハードウェアを制御するプログラムコードをＣＰＵ、ＭＰＵなどの各種のプロセッサによって実行されてもよい。プログラムコードの機能を実現するための回路等のハードウェアを設けてもよい。プログラムコードの一部をハードウェアで実現し、残りの部分を各種プロセッサが実行してもよい。

また、前記実施形態においては、日本円の賃借を例示として示しているが、日本円以外の外貨を取引対象とすることもできる。さらに、特に、明示していないが、貸し手、借り手共に、日本人でも、外国人でもよく、日本在住者でも、海外在住者であってもよい。

また、借り手が返済不可能（デフォルト）となった場合に備え、システム運用者若しくは第三者が貸し手を保護すべく、保証手数料（金利の一部等）を支払っている場合には、デフォルト時に返金されなかった元本部分を借り手に代わって貸し手に支払う仕組みを適用させてもよい。

１００…サービス提供システム、１０１…制御部、１０２…情報取得部、１０３…資産特定部、１０４…判定部、１０５…マッチング部、１０６…分類部、１０７…管理部、１０８…指示送信部、１０９…指示受信部、１１１…情報提供部、１１２…契約処理部、１１３…モデル構築部、１１４…学習モデル、１１５…資産運用サポート処理部、１５０…システム、１６０…ユーザ端末、１８０…金融機関サーバ

Claims (3)

1. 複数の種類の金融情報を集約した金融資産情報であって、ユーザにおける日常的な入出金の履歴の情報と、前記ユーザが保有する金融資産の情報と、の少なくとも何れかを含む前記金融資産情報を管理する金融資産管理システムから、前記金融資産情報を取得する取得部と、
   前記金融資産情報に基づいて、前記ユーザの余剰資産を特定する資産特定部と、
   を備えるサービス提供システム。
2. 前記資産特定部で特定された前記余剰資産に関する情報に基づいて、借り手となる前記ユーザを、返済に関するタイプごとに分類する分類部と、
   前記タイプに応じて利息を設定する利息設定部と、
   をさらに有する請求項１に記載のサービス提供システム。
3. 前記金融資産情報は、借り手となる前記ユーザの資金を借りたい目的に関する情報を含み、
   前記取得部は、貸し手となる前記ユーザから、所定の目的で資金を提供する旨の提供指示を取得し、
   前記資金を借りたい目的と、前記所定の目的と、に基づいて、前記借り手となるユーザと、前記貸し手となるユーザと、をマッチングさせるマッチング部と、
   前記マッチング部でマッチングされた前記貸し手となるユーザに対して、前記借り手となるユーザの前記借りたい目的に関連する情報を提供する情報提供部と、
   をさらに備える請求項１又は２に記載のサービス提供システム。