(57)【要約】【課題】信託サービスに係るキャッシュフローを改善することができるようにする。【解決手段】信託支援装置２０の入金処理部２２２は、消費者１から信託機関３に商品の支払がなされたことを検知し、信託会計管理部２１１は支払金額を受益額とした信託設定に係る処理を行い、入金処理部２２２は、ＥＣ事業者２が有する受益権を担保にして融資機関４からＥＣ事業者２に融資が行われるように指示する支払完了通知を融資機関４に送信する。これにより、信託支援装置２０は商品の売買代金の保全を目的としたエスクローサービスを支援する。【選択図】図１
2014099050.tif 000002
【特許請求の範囲】
【請求項１】
商品の売買代金の保全を目的とした信託を支援するシステムであって、
前記商品の購入者から信託機関に前記商品の支払がなされたことの入力を受け付ける支払入力部と、
前記支払の金額を受益額とした信託設定に係る処理を行う信託処理部と、
前記信託設定に基づき前記商品の販売者が有する受益権を担保にして融資機関から前記販売者に融資が行われるように指示する融資要求を前記融資機関に送信する融資要求送信部と、
を備えることを特徴とする信託支援システム。
【請求項２】
請求項１に記載の信託支援システムであって、
前記販売者から前記購入者への前記商品の引渡しが完了したことの入力を受け付ける引渡し入力部と、
前記引渡しの完了に応じて、前記販売者が前記受益権をもって前記融資についての代物弁済を前記融資機関に行うべく、前記受益権を前記融資機関に譲渡することを承認したことの入力を受け付ける代物弁済承認入力部と、
前記承認に応じて、前記購入者からの前記受益額を前記融資機関に送金する償還処理部と、
をさらに備えることを特徴とする信託支援システム。
【請求項３】
請求項１または２に記載の信託支援システムであって、
前記引渡しが行われなかったことを前記引渡し入力部が受け付けた場合に、前記融資を回収するように指示する回収要求を前記融資機関に送信する回収要求送信部をさらに備えること、
を特徴とする信託支援システム。
【請求項４】
請求項１ないし３のいずれか１項に記載の信託支援システムであって、
前記販売者に対する前記融資機関からの与信額を記憶する与信額記憶部と、
前記融資要求に応じて、前記融資に係る融資金額を含む、前記融資機関から前記販売者への前記融資が行われたことを示す融資情報を受信し、受信した前記融資情報に含まれる前記融資金額を前記与信額から減算する融資情報受信部と、
をさらに備え、
前記融資要求送信部は、前記与信額に応じて前記融資が可能か否かを判断し、前記融資が可能であると判断した場合にのみ前記融資要求を送信すること、
を特徴とする信託支援システム。
【請求項５】
請求項１に記載の信託支援システムであって、
前記販売者に対する前記融資機関からの与信額を記憶する与信額記憶部と、
前記融資要求に応じて、前記融資に係る融資金額を含む、前記融資機関から前記販売者への前記融資が行われたことを示す融資情報を受信し、受信した前記融資情報に含まれる前記融資金額を前記与信額から減算する融資情報受信部と、
前記販売者から前記購入者への前記商品の引渡しが完了したことの入力を受け付ける引渡し入力部と、
前記引渡しの完了に応じて、前記販売者が前記受益権をもって前記融資についての代物弁済を前記融資機関に行うべく、前記受益権を前記融資機関に譲渡することを承認したことの入力を受け付ける代物弁済承認入力部と、
前記承認に応じて、前記購入者からの前記受益額を前記融資機関に送金し、前記受益額を前記与信額に加算する償還処理部と、
をさらに備え、
前記融資要求送信部は、前記与信額に応じて前記融資が可能か否かを判断し、前記融資が可能であると判断した場合にのみ前記融資要求を送信すること、
をさらに備えることを特徴とする信託支援システム。
【請求項６】
請求項５に記載の信託支援システムであって、
前記融資金額に金利が含まれている場合に、前記融資機関が前記販売者から前記金利を回収したことの入力を受け付け、前記金利を前記与信額に加算する金利回収入力部をさらに備えること、
を特徴とする信託支援システム。
【請求項７】
商品の売買代金の保全を目的とした信託を支援する方法であって、
コンピュータが、
前記商品の購入者から信託機関に前記商品の支払がなされたことの入力を受け付けるステップと、
前記支払の金額を受益額とした信託設定に係る処理を行うステップと、
前記信託設定に基づき前記商品の販売者が有する受益権を担保にして融資機関から前記販売者に融資が行われるように指示する融資要求を前記融資機関に送信するステップと、
を実行することを特徴とする信託支援方法。
【請求項８】
商品の売買代金の保全を目的とした信託を支援するプログラムであって、
コンピュータに、
前記商品の購入者から信託機関に前記商品の支払がなされたことの入力を受け付けるステップと、
前記支払の金額を受益額とした信託設定に係る処理を行うステップと、
前記信託設定に基づき前記商品の販売者が有する受益権を担保にして融資機関から前記販売者に融資が行われるように指示する融資要求を前記融資機関に送信するステップと、
を実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、信託支援システム、信託支援方法およびプログラムに関する。
【背景技術】
【０００２】
近年の電子商取引（ＥＣ；Electronic Commerce）において、取引の安全を図るべくエスクロー（第三者預託）サービスが提供されている。エスクローサービスでは、サービスの提供者が商品の販売者と購入者との間に入り、購入者からの支払を一時的に預かり、販売者から購入者に商品が配送されたことを確認して販売者への支払が行われる。エスクローサービスは、信託業法などの規定の下、たとえば信託銀行などの信託機関により行われている（たとえば非特許文献１参考）。
【先行技術文献】
【非特許文献】
【０００３】
【非特許文献１】"エスクロー信託（資金保全目的の信託）スキームのご案内"、[online]、三菱ＵＦＪ信託銀行株式会社、[平成２４年８月２０日検索]、インターネット<URL:http://www.tr.mufg.jp/houjin/shisan/escrow.html>
【発明の概要】
【発明が解決しようとする課題】
【０００４】
エスクローサービスを利用する場合、商品の販売者は、商品が実際に購入者に配送されるまでは支払を受けることができず、商品が発送されても購入者が商品を受け取るまでに時間がかかってしまうようなときなどには、販売者のキャッシュフローが滞ってしまうことがある。
【０００５】
本発明は、このような背景を鑑みてなされたものであり、信託サービスに係るキャッシュフローを改善することのできる、信託支援システム、信託支援方法およびプログラムを提供することを目的とする。
【課題を解決するための手段】
【０００６】
上記課題を解決するための本発明の主たる発明は、商品の売買代金の保全を目的とした信託を支援するシステムであって、前記商品の購入者から信託機関に前記商品の支払がなされたことの入力を受け付ける支払入力部と、前記支払の金額を受益額とした信託設定に係る処理を行う信託処理部と、前記信託設定に基づき前記商品の販売者が有する受益権を担保にして融資機関から前記販売者に融資が行われるように指示する融資要求を前記融資機関に送信する融資要求送信部と、を備えることとする。
【０００７】
また、本発明の信託支援システムは、前記販売者から前記購入者への前記商品の引渡しが完了したことの入力を受け付ける引渡し入力部と、前記引渡しの完了に応じて、前記販売者が前記受益権をもって前記融資についての代物弁済を前記融資機関に行うべく、前記受益権を前記融資機関に譲渡することを承認したことの入力を受け付ける代物弁済承認入力部と、前記承認に応じて、前記購入者からの前記受益額を前記融資機関に送金する償還処理部と、をさらに備えるようにしてもよい。
【０００８】
また、本発明の信託支援システムは、前記引渡しが行われなかったことを前記引渡し入力部が受け付けた場合に、前記融資を回収するように指示する回収要求を前記融資機関に送信する回収要求送信部をさらに備えるようにしてもよい。
【０００９】
また、本発明の信託支援システムは、前記販売者に対する前記融資機関からの与信額を記憶する与信額記憶部と、前記融資要求に応じて、前記融資に係る融資金額を含む、前記融資機関から前記販売者への前記融資が行われたことを示す融資情報を受信し、受信した前記融資情報に含まれる前記融資金額を前記与信額から減算する融資情報受信部と、をさらに備え、前記融資要求送信部は、前記与信額に応じて前記融資が可能か否かを判断し、前記融資が可能であると判断した場合にのみ前記融資要求を送信するようにしてもよい。
【００１０】
また、本発明の信託支援システムは、前記販売者に対する前記融資機関からの与信額を記憶する与信額記憶部と、前記融資要求に応じて、前記融資に係る融資金額を含む、前記融資機関から前記販売者への前記融資が行われたことを示す融資情報を受信し、受信した前記融資情報に含まれる前記融資金額を前記与信額から減算する融資情報受信部と、前記販売者から前記購入者への前記商品の引渡しが完了したことの入力を受け付ける引渡し入力部と、前記引渡しの完了に応じて、前記販売者が前記受益権をもって前記融資についての代物弁済を前記融資機関に行うべく、前記受益権を前記融資機関に譲渡することを承認したことの入力を受け付ける代物弁済承認入力部と、前記承認に応じて、前記購入者からの前記受益額を前記融資機関に送金し、前記受益額を前記与信額に加算する償還処理部と、をさらに備え、前記融資要求送信部は、前記与信額に応じて前記融資が可能か否かを判断し、前記融資が可能であると判断した場合にのみ前記融資要求を送信するようにしてもよい。
【００１１】
また、本発明の信託支援システムは、前記融資金額に金利が含まれている場合に、前記融資機関が前記販売者から前記金利を回収したことの入力を受け付け、前記金利を前記与信額に加算する金利回収入力部をさらに備えるようにしてもよい。
【００１２】
また、本発明の他の態様は商品の売買代金の保全を目的とした信託を支援する方法であって、コンピュータが、前記商品の購入者から信託機関に前記商品の支払がなされたことの入力を受け付けるステップと、前記支払の金額を受益額とした信託設定に係る処理を行うステップと、前記信託設定に基づき前記商品の販売者が有する受益権を担保にして融資機関から前記販売者に融資が行われるように指示する融資要求を前記融資機関に送信するステップと、を実行することとする。
【００１３】
また、本発明の他の態様は、商品の売買代金の保全を目的とした信託を支援するプログラムであって、コンピュータに、前記商品の購入者から信託機関に前記商品の支払がなされたことの入力を受け付けるステップと、前記支払の金額を受益額とした信託設定に係る処理を行うステップと、前記信託設定に基づき前記商品の販売者が有する前記信託設定に基づく受益権を担保にして融資機関から前記販売者に融資が行われるように指示する融資要求を前記融資機関に送信するステップと、を実行させることとする。
【００１４】
その他本願が開示する課題やその解決方法については、発明の実施形態の欄及び図面により明らかにされる。
【発明の効果】
【００１５】
本発明によれば、信託サービスに係るキャッシュフローを改善することができる。
【図面の簡単な説明】
【００１６】
【図１】本実施形態に係るエスクローサービスの概要を説明する図である。
【図２】受益権を担保にした融資を用いない場合のエスクローサービスにおいて、商品が配送されたときのサービスの流れを説明する図である。
【図３】受益権を担保にした融資を用いない場合のエスクローサービスにおいて、商品が配送されなかったときのサービスの流れを説明する図である。
【図４】受益権を担保にした融資を用いた場合のエスクローサービスにおいて、商品が配送されなかったときのサービスの流れを説明する図である。
【図５】受益権を担保にした融資を用いた場合のエスクローサービスにおいて、商品が配送されたときのサービスの流れを説明する図である。
【図６】本発明の一実施形態に係る信託支援装置２０を含むエスクローシステムの構成例を示す図である。
【図７】信託支援装置２０のハードウェア構成例を示す図である。
【図８】信託支援装置２０のソフトウェア構成例を示す図である。
【図９】融資限度額管理テーブル２３１に記憶される与信限度額管理データの構成例を示す図である。
【図１０】信託金管理テーブル２３２に記憶される信託金管理データの構成例を示す図である。
【図１１】商品管理テーブル２３３に記憶される商品管理データの構成例を示す図である。
【図１２】融資管理テーブル２３４に記憶される融資管理データの構成例を示す図である。
【図１３】受益権管理テーブル２３５に記憶される受益権管理データの構成例を示す図である。
【図１４】信託支援装置２０により行われる処理の流れを説明する図である。
【図１５】入金処理部２２２による入金処理の流れを示す図である。
【図１６】配送処理部２２３による配送完了処理の流れを示す図である。
【図１７】配送処理部２２３による配送未着処理の流れを示す図である。
【図１８】配送処理部２２３による未配送承認処理の流れを示す図である。
【図１９】代物弁済処理部２２７による代物弁済処理の流れを示す図である。
【図２０】償還処理部２２８による償還処理の流れを示す図である。
【発明を実施するための形態】
【００１７】
＝＝概要＝＝
以下、本発明の一実施形態に係る信託支援装置２０を含むエスクローシステムにおいて提供されるエスクローサービスについて説明する。図１は、本実施形態に係るエスクローサービスの概要を説明する図である。本実施形態のエスクローサービスでは、ＥＣ事業者２（以下、店舗ともいう。）から消費者１が商品を購入することを想定する。
【００１８】
商品の購入者である消費者１は、ＥＣ事業者２に商品を注文した後、その購入代金を信託機関３に預託する。信託機関３は、たとえば信託会社や信託銀行などであり、消費者２からＥＣ事業者２に対する購入代金を一時的に管理する。通常のエスクローサービスでは、ＥＣ事業者２から消費者１に商品が配送された後で、信託機関３からＥＣ事業者２に上記預託に係る受益権の償還がなされるところ、本実施形態のエスクローシステムでは、商品の配送完了前に、銀行等の融資機関４から上記受益権を担保とした融資が行われるようにしている。これにより、ＥＣ事業者２のキャッシュフローを改善することができる。そして、商品の配送後、上記受益権が代物弁済により融資機関４に支払われ、信託機関３から融資機関４に受益権の償還がなされる。なお、融資機関は、融資に係る金利は別途ＥＣ事業者２から徴収することになる。
【００１９】
＝＝エスクローサービスの流れ１（融資なし、正常時）＝＝
図２は、受益権を担保にした融資を用いない場合のエスクローサービスにおいて、商品が配送されたときのサービスの流れを説明する図である。
【００２０】
まず、消費者１がＥＣ事業者２に商品の注文を行う（Ｓ４０１）。消費者１は消費者端末１１を用いてＥＣサーバ１２にアクセスして商品の注文を行うことができる。ＥＣ事業者２は、注文された商品に関するデータ（以下、注文データという。）を信託機関３に送信するとともに（Ｓ４０２）、消費者１に対して当該商品の購入代金の請求を行う（Ｓ４０３）。ＥＣ事業者２は、事業者端末１３を操作してＥＣサーバ１２から注文データを信託支援装置２０に送信させる。購入代金の請求は、たとえばＥＣサーバ１２から行うようにすることができる。  
消費者１は、購入代金に請求に応じてこれを信託機関３に支払う（Ｓ４０４）。たとえばＥＣサーバ１２が、消費者１からの指示に応じて支払先を信託機関３に設定してクレジットカードによる決済を行うようにしてもよいし、消費者１から信託機関３の口座に振込や振替などによる送金を行うようにしてもよい。  
信託機関３は、消費者１から注文データに対応する支払を受けると、支払が完了した旨の通知（以下、支払完了通知という。）をＥＣ事業者２に送信する（Ｓ４０５）。この支払完了通知に応じてＥＣ事業者２は商品を配送する（Ｓ４０６）。ＥＣ事業者２は商品の配送が完了した旨の通知（以下、配送完了通知という。）を信託機関３に送信する（Ｓ４０７）。なお、ＥＣ事業者２は、消費者１からの商品の受領証のコピーを添付して信託機関３に配送完了通知を送信するものとする。配送業者から商品の配送完了通知を信託機関３に送信するようにしてもよい。  
商品が配送されると、消費者１の受益権は消滅し、ＥＣ事業者２のみが受益権を有することになるので、信託機関３は、商品の配送完了通知を受けると、ＥＣ事業者２に対して受益権の償還を行い（Ｓ４０８）、これにより信託機関３が消費者１から受託した購入代金がＥＣ事業者２に支払われる。なお、受益権の償還は、銀行振込などの送金により行われる。  
以上のようにして、商品が配送された場合には、消費者１から支払われた購入代金は信託機関３を介してＥＣ事業者２に支払われることになる。
【００２１】
＝＝エスクローサービスの流れ２（融資なし、異常時）＝＝
図３は、受益権を担保にした融資を用いない場合のエスクローサービスにおいて、商品が配送されなかったときのサービスの流れを説明する図である。図３に示す場合も、ステップＳ４２１〜Ｓ４２５までは図２のステップＳ４０１〜Ｓ４０５までの処理と同様である。  
ここで、支払が完了したにも拘らず、消費者１に商品が届かなかった場合、消費者１は商品が届かない旨の通知（以下、商品未着通知という。）を信託機関３に送信する（Ｓ４２６）。信託機関３は、商品未着通知をＥＣ事業者２に送信する（Ｓ４２７）。  
商品が予定日までに届かなかったことにより、ＥＣ事業者２の受益権は消滅し、消費者１のみが受益権を有することになるので、信託機関３は、消費者１に対して受益権の償還を行う（Ｓ４２８）。  
以上のようにして、商品が届かなかった場合には、消費者１が支払った購入代金が返金されることになる。
【００２２】
＝＝エスクローサービスの流れ３（融資あり、正常時）＝＝
図４は、受益権を担保にした融資を用いた場合のエスクローサービスにおいて、商品が配送されたときのサービスの流れを説明する図である。図４に示す場合も、ステップＳ４４１〜Ｓ４４５までは図２のステップＳ４０１〜Ｓ４０５までの処理と同様である。
【００２３】
信託機関３は、支払完了通知を融資機関４にも送信する（Ｓ４４６）。なお、支払完了通知には支払金額も含まれるものとする。融資機関４は、ＥＣ事業者２に対して、支払完了通知に応じてＥＣ事業者２の受益権を担保として支払金額に応じた融資を行う（Ｓ４４７）。本実施形態では、支払金額に消費税を加えたものが融資金額であるものとする。融資機関４は、融資が完了した旨を示す通知（以下、融資完了通知という。）を信託機関３に送信する（Ｓ４４８）。  
一方、ＥＣ事業者２は、支払完了通知を受けて商品を発送する（Ｓ４４９）。また、ＥＣ事業者２は、図２のステップＳ４０７と同様に配送完了通知を信託機関３に送信する（Ｓ４５０）。信託機関３は、ＥＣ事業者２からの配送完了通知に応じて、融資機関４に配送完了通知を送信する（Ｓ４５１）。  
ＥＣ事業者２は、受益権で融資の代物弁済を行うように、受益権の譲渡を承認する通知（以下、承認通知という。）を信託機関３に送信する（Ｓ４５２）。信託機関３はこの承認通知を受けて、融資機関４に対して受益権の償還を行う（Ｓ４５３）。  
融資機関４は、ステップＳ４４７において融資を行った時点から、受益権による代物弁済を受けるまでの金利をＥＣ事業者２から回収する（Ｓ４５４）。融資機関４は、金利を回収した旨の通知（以下、回収完了通知という。）を信託機関３に送信する（Ｓ４５５）。後述するように、信託機関３では、融資機関４からＥＣ事業者２への融資限度額残高を管理しており、融資完了通知に応じて融資限度額残高を減額し、受益権を償還した場合と、回収完了通知を受信した場合に融資限度額残高を増額する。  
以上のようにして、商品配送前に受益権を担保とした融資が行われ、商品が配送された場合には、消費者１から支払われた購入代金は信託機関３を介して上記融資の弁済とされることになる。
【００２４】
＝＝エスクローサービスの流れ４（融資あり、異常時）＝＝
図５は、受益権を担保にした融資を用いた場合のエスクローサービスにおいて、商品が配送されなかったときのサービスの流れを説明する図である。図５に示す場合も、ステップＳ４６１〜Ｓ４６８までは図４のステップＳ４４１〜Ｓ４４８までの処理と同様である。
【００２５】
ここで、支払が完了したにも拘らず、消費者１に商品が届かなかった場合、消費者１は商品未着通知を信託機関３に送信する（Ｓ４６９）。信託機関３は、商品未着通知をＥＣ事業者２に送信するとともに（Ｓ４７０）、融資機関４にも商品未着通知を送信する（Ｓ４７１）。なお、商品が未配送であることをＥＣ事業者２が確認した場合にのみ商品未着通知を融資機関４に送信するようにしてもよい。  
商品が予定日までに届かなかったことにより、ＥＣ事業者２の受益権は消滅し、消費者１のみが受益権を有することになるので、信託機関３は、消費者１に対して受益権の償還を行う（Ｓ４７２）。  
一方、上記融資の担保であるＥＣ事業者２の受益権が消滅したことから、融資機関４はＥＣ事業者２から融資に関する弁済を受ける（Ｓ４７３）。融資機関４は、ＥＣ事業者２から融資金額を回収したことを示す通知（以下、上記金利を回収した旨を示す通知とあわせて回収完了通知という。）を信託機関３に送信する（Ｓ４７４）。  
以上のようにして、商品が届かなかった場合には、消費者１が支払った購入代金が返金
され、ＥＣ事業者２への融資に関しては融資機関４から回収がなされる。
【００２６】
＝＝システム構成＝＝
図６は、本発明の一実施形態に係る信託支援装置２０を含むエスクローシステムの構成例を示す図である。本実施形態のエスクローシステムは、消費者端末１１、ＥＣサーバ１２、事業者端末１３、融資機関サーバ１４および信託支援装置２０を含んで構成される。消費者端末１１、ＥＣサーバ１２、事業者端末１３、融資機関サーバ１４および信託支援装置２０は互いに通信可能に通信ネットワーク３０に接続される。本実施形態では、通信ネットワーク３０はインターネットを想定する。通信ネットワーク３０は、公衆電話回線網、携帯電話回線網、無線通信網、イーサネット（登録商標）などにより構築される。
【００２７】
ＥＣサーバ１２は、たとえばオンラインショッピングサービスやオークションサービスなどの電子商取引（ＥＣ）サービスを行う、パーソナルコンピュータやワークステーションなどのコンピュータである。ＥＣサーバ１２において行われる電子商取引は一般的なものを想定し、説明を省略する。
【００２８】
消費者端末１１は、商品の購入者である消費者１が操作する、たとえば携帯電話やスマートフォン、タブレットコンピュータ、パーソナルコンピュータなどのコンピュータである。消費者１は消費者端末１１を操作して、ＥＣサーバ１２にアクセスし、ＥＣ事業者２が販売する商品を購入する。なお、消費者端末１１を用いた商品の購入処理についても一般的なものを想定し、説明を省略する。
【００２９】
事業者端末１３は、ＥＣ事業者２が操作する、たとえば携帯電話やスマートフォン、タブレットコンピュータ、パーソナルコンピュータなどのコンピュータである。ＥＣ事業者２は、事業者端末１３を操作してＥＣサーバ１２にアクセスし、消費者１からの注文を確認し、その他ＥＣサーバ１２における電子商取引に関する各種の操作を行う。また、後述するように、ＥＣ事業者２は事業者端末１３を操作して、エスクローサービスに関する情報を信託支援装置２０との間でやりとりする。
【００３０】
融資機関サーバ１４は、受益権を担保としてＥＣ事業者２に融資を行う融資機関４のサーバである。
【００３１】
信託支援装置２０は、信託機関３が操作する、たとえばパーソナルコンピュータやワークステーションなどのコンピュータである。信託支援装置２０は、エスクローサービスの支援を行う。信託支援装置２０は、ＥＣ事業者２に対して融資機関４が与えた与信枠を管理し、与信可能である場合には融資機関４からＥＣ事業者２に対して融資が行われるように融資機関サーバ１４に通知し、また商品の配送が完了して受益権による代物弁済が指示された場合には、受益権による代物弁済により貸金弁済がなされるように融資機関サーバ１４に通知する。
【００３２】
＝＝ハードウェア構成＝＝
図７は、信託支援装置２０のハードウェア構成例を示す図である。信託支援装置２０は、ＣＰＵ２０１、メモリ２０２、記憶装置２０３、通信インタフェース２０４、入力装置２０５、出力装置２０６を備える。記憶装置２０３は、各種のデータやプログラムを記憶する、例えばハードディスクドライブやソリッドステートドライブ、フラッシュメモリなどである。ＣＰＵ２０１は記憶装置２０３に記憶されているプログラムをメモリ２０２に読み出して実行することにより各種の機能を実現する。通信インタフェース２０４は、通信ネットワーク３０に接続するためのインタフェースであり、例えば、イーサネット（登録商標）に接続するためのアダプタ、公衆電話回線網に接続するためのモデム、無線通信網に接続するための無線通信機などである。入力装置２０５は、データの入力を受け付ける、例えばキーボードやマウス、トラックボール、タッチパネル、マイクロフォンなどである。出力装置２０６は、データを出力する、例えばディスプレイやプリンタ、スピーカなどである。信託支援装置２０は複数の入力装置２０５及び出力装置２０６を備えるようにすることもできる。
【００３３】
＝＝ソフトウェア構成＝＝
図８は、信託支援装置２０のソフトウェア構成例を示す図である。信託支援装置２０は、信託会計管理部２１１、送金管理部２１２、エスクロー管理部２１３の各機能部と、融資限度額管理テーブル２３１、信託金管理テーブル２３２、商品管理テーブル２３３、融資管理テーブル２３４、受益権管理テーブル２３５の各記憶部とを備える。なお、上記各機能部は、信託支援装置２０が備えるＣＰＵ２０１が記憶装置２０３に記憶されているプログラムをメモリ２０２に読み出して実行することにより実現され、上記各記憶部は、信託支援装置２０が備えるメモリ２０２および記憶装置２０３が提供する記憶領域の一部として実現される。
【００３４】
＝＝信託支援装置２０の記憶部＝＝
融資限度額管理テーブル２３１（本発明の与信額記憶部に該当する。）は、ＥＣ事業者２に対して融資機関４が設定した与信額に関する情報（以下、融資限度額管理データという。）を記憶する。図９は、融資限度額管理テーブル２３１に記憶される融資限度額管理データの構成例を示す図である。融資限度額管理データには、融資機関４を特定するファンドＩＤと、ＥＣ事業者２を特定する店舗ＩＤとに対応付けて、当該ＥＣ事業者２に対して当該融資機関４が設定した与信額（融資限度額）と、現時点で融資機関４からＥＣ事業者２に融資可能な金額（融資限度額残高）と、融資機関４からＥＣ事業者２に対する融資にかかる金利（金利年率）とが含まれる。融資限度額残高は、当初融資限度額と一致しており、融資機関４からＥＣ事業者２に融資が行われるたびに融資額が減額されていき、融資機関４がＥＣ事業者２から弁済を受けるたびに弁済額が増額されていく。後述するように、融資限度額管理テーブル２３１に店舗に対応するデータが登録されていた場合に、消費者１からの支払額（すなわち、エスクローサービスにおける信託の対象となる金額）が融資限度額残高以下である場合にのみ、融資が行われることになる。
【００３５】
信託金管理テーブル２３２は、エスクローサービスに係る信託金に関する情報（以下、信託金管理データという。）を記憶する。図１０は、信託金管理テーブル２３２に記憶される信託金管理データの構成例を示す図である。信託金管理データには、消費者１からＥＣ事業者２に対しての注文を特定する注文ＩＤに対応付けて、当該ＥＣ事業者２を示す店舗ＩＤ、信託設定金額、信託残高、信託残高更新日、譲渡可能区分、譲渡可能日が含まれる。信託設定金額は、信託設定された金額であり、本実施形態では、消費者１が支払った全額が信託設定されるものとする。なお、信託機関３による手数料を減額した金額を信託設定金額としてもよい。信託残高は、償還されていない信託金の残高である。消費者１からの支払を受けて信託設定された場合、信託残高には信託設定金額が設定され、商品が配達されてＥＣ事業者２もしくは融資機関４に受益権が償還され、または商品が配送されずに受益権が消費者１に償還された場合、信託残高からは償還額が減額される。本実施形態では、償還される金額は信託設定金額と同額であるものとし、受益権の償還後は信託残高には０（ゼロ）が設定されるものとする。信託残高更新日は、信託残高を更新した日を示す。譲渡可能区分は、受益権の譲渡または償還が可能であるか否かを示す。譲渡可能区分には「０」または「１」が設定され、「１」が設定された場合、当該信託金に関する受益権を譲渡したり償還したりすることが可能であることを示し、「０」が設定された場合には、受益権の譲渡や償還はできないことを示すものとする。譲渡可能日は、受益権の譲渡や償還が可能となる日である。本実施形態では、商品がＥＣ事業者２から消費者１に配送された場合に、たとえば欠品や内容間違いなどが発生する可能性を考慮し、配送完了日から４日後を譲渡可能日として設定する。なお、配送完了日を譲渡可能日としてもよいし、配送完了日から４日に限らず所定の日数後の日付を譲渡可能日としてもよい。
【００３６】
商品管理テーブル２３３は、注文された商品に関する情報（以下、商品管理データという。）を記憶する。図１１は、商品管理テーブル２３３に記憶される商品管理データの構成例を示す図である。商品管理データには、商品を特定する商品ＩＤに対応付けて、注文ＩＤ、当該商品を販売したＥＣ事業者２を示す店舗ＩＤ、当該商品の商品代金および消費税、注文日時、配送区分、配送予定日、配送完了日、支払区分、支払完了日が含まれる。注文ＩＤは、当該商品に対応する注文を示す。１回に複数の商品が注文された場合には、１つの注文について複数の商品管理データが商品管理テーブル２３３に登録される。配送区分は、当該商品の配送の状態を示す。配送区部には「０」「１」「−１」のいずれかが設定される。配送区分が「０」であれば、消費者１が商品の配送を待っている配送待ちの状態を示し、配送区分が「１」であれば、商品の配送が完了した状態を示す。配送区分が「−１」であれば、商品の配送がされなかったことを示す。支払区分は、消費者１から信託機関３への支払がなされたか否かを示す。支払区分には「０」または「１」が設定される。支払区分が「０」であれば支払はなされておらず、支払区分が「１」であれば支払が完了していることを示す。
【００３７】
融資管理テーブル２３４は、融資機関４からＥＣ事業者２への融資に関する情報（以下、融資管理データという。）を記憶する。図１２は、融資管理テーブル２３４に記憶される融資管理データの構成例を示す図である。融資管理データには、当該融資の契機となった商品の注文を示す注文ＩＤに対応付けて、融資機関４を特定するファンドＩＤ、ＥＣ事業者２を特定する店舗ＩＤ、融資金額、消費税、金利、融資日、融資残高、融資残高更新日、融資区分が含まれる。融資残高には当初融資金額が設定され、融資機関４がＥＣ事業者２から融資金を回収するたびに、回収額が融資残高から減算される。融資区分は、融資に関する状況を示す。融資区分には「０」「１」「２」「３」のいずれかが設定される。融資区分が「０」の場合、融資機関４からＥＣ事業者２への融資が行われていないことを示し、融資区分が「１」の場合、融資が完了したことを示す。融資区分が「２」の場合、受益権を用いた代物弁済によって融資の元本が弁済されたことを示し、融資区分が「３」の場合、融資機関４がＥＣ事業者２から融資金額の全額が回収されたことを示す。
【００３８】
受益権管理テーブル２３５は、受益権に関する情報（以下、受益権管理データという。）を記憶する。図１３は、受益権管理テーブル２３５に記憶される受益権管理データの構成例を示す図である。受益権管理データには、信託受益権を特定する受益権ＩＤに対応付けて、注文ＩＤ、ファンドＩＤ、店舗ＩＤ、譲渡先ＩＤ、譲渡金額、償還に係る振込手数料、譲渡予定日、承認区分（ファンド）、承認区分（ＥＣ事業者）、償還区分、償還日を含む。注文ＩＤは当該受益権を発生させた信託に関する注文を示す。本実施形態では、注文単位で信託が行われるものとし、受益権も注文単位で発生するものとする。したがって、１回の注文で複数の商品が販売された場合であっても、１つの注文について受益権管理データは１つのみが登録されることになる。ファンドＩＤは受益権を担保にした融資を行った融資機関４を示す。なお、融資が行われなかった場合には、ファンドＩＤには何も設定されない。店舗ＩＤは注文先のＥＣ事業者２を示す。譲渡先ＩＤは受益権の償還先を示す。譲渡先ＩＤには、消費者１を特定する消費者ＩＤ、ＥＣ事業者２を特定する店舗ＩＤおよび融資機関４を特定するファンドＩＤのいずれかが設定される。なお、消費者１による支払完了後、商品の配送または未着の確定前の期間には、譲渡先ＩＤには何も設定されない。譲渡金額は償還する金額である。譲渡予定日は償還を行う予定の日である。承認区分（ファンド）は、受益権を譲渡すること、または商品が未着であることに関する融資機関４の承認状況を示す。承認区分（ファンド）には「０」「１」「２」のいずれかが設定される。承認区分（ファンド）が「１」である場合、信託支援装置２０から融資機関４に対して、受益権が譲渡される旨の通知（以下、受益権譲渡通知という。）または商品未着通知を送信したことを示し、承認区分（ファンド）が「２」である場合は、受益権譲渡通知または商品未着通知に対して融資機関４が承認したことを示す。承認区分（ファンド）が「０」である場合には、このいずれでもないことを示す。承認区分（ＥＣ事業者）は、受益権を譲渡すること、または商品が未着であることに関するＥＣ事業者２の承認状況を示す。承認区分（ＥＣ事業者）には「０」「１」「２」のいずれかが設定される。承認区分（ＥＣ事業者）が「１」である場合、信託支援装置２０からＥＣ事業者２に対して受益権譲渡通知または商品未着通知を送信したことを示し、承認区分（ＥＣ事業者）が「２」である場合は、受益権譲渡通知または商品未着通知に対してＥＣ事業者２が承認したことを示す。承認区分（ＥＣ事業者）が「０」である場合には、このいずれでもないことを示す。
【００３９】
＝＝信託支援装置２０の機能部＝＝
信託会計管理部２１１（本発明の信託処理部に該当する。）は、信託会計に関する処理を行う。なお、信託会計管理部２１１は、一般的な信託に関する会計処理を行うものとし、ここでは説明を省略する。
【００４０】
送金管理部２１２は、送金に関する処理を行う。なお、送金管理部２１２は、一般的な銀行振込などによる送金に関する処理を行うものとし、ここでは説明を省略する。
【００４１】
＝＝エスクロー管理部２１３＝＝
エスクロー管理部２１３は、エスクローサービスに関する処理を行う。エスクロー管理部２１３は、注文処理部２２１、入金処理部２２２、配送処理部２２３、融資処理部２２４、承認処理部２２５、回収処理部２２６、代物弁済処理部２２７、償還処理部２２８を備える。
【００４２】
注文処理部２２１は、商品の注文に関する処理を行う。注文処理部２２１は、ＥＣ事業者２が消費者１から受けた商品の注文に関する注文データをＥＣサーバ１２から受信し、注文データに基づいて信託金管理データおよび商品管理データを作成し、作成した信託金管理データおよび商品管理データを信託金管理テーブル２３２および商品管理テーブル２３３に登録する。
【００４３】
入金処理部２２２（本発明の支払入力部および融資要求送信部に該当する。）は、消費者１から信託機関３への支払を検知する。また、入金処理部２２２は、融資限度額管理テーブル２３１の融資限度額管理データを参照して、融資機関４からＥＣ事業者２に融資が可能か否かを判定する。さらに、入金処理部２２２は、融資が可能である場合には融資管理データを作成して融資管理テーブル２３４に登録し、融資機関４の融資機関サーバ１４に対して支払完了通知（本願発明の融資要求に該当する。）を送信して、融資機関４に融資を行わせる。また、入金処理部２２２は、ＥＣ事業者２の事業者端末１３に対して支払完了通知を送信し、ＥＣ事業者２に対して商品を発送させる。
【００４４】
配送処理部２２３（本発明の引渡し入力部および回収要求送信部に該当する。）は、商品の配送に関する処理を行う。配送処理部２２３は、ＥＣ事業者２の事業者端末１３から配送完了通知を受信すると、商品管理テーブル２３３に登録されている商品管理データの配送区分を「１」に更新し、信託金管理テーブル２３２に登録されている信託金管理データの譲渡可能日を配送完了日の所定の日数（本実施形態では４日とするが、任意の日数とすることができる。）後に設定する。また、配送処理部２２３は、融資管理データが融資管理テーブル２３４に登録されている場合（すなわち、融資が行われた場合）には、譲渡先ＩＤとして融資機関４を示すファンドＩＤを設定し、登録されていない場合には譲渡先ＩＤとしてＥＣ事業者２を示す店舗ＩＤを設定した受益権管理データを作成して、受益権管理テーブル２３５に登録する。
【００４５】
また、配送処理部２２３は、消費者１の消費者端末１１から商品未着通知を受信すると、商品管理テーブル２３３の商品管理データの配送区分に、商品の配送がされなかった旨を示す「−１」を設定するとともに、信託金管理テーブル２３２の信託金管理データの譲渡可能区分に、受益権の譲渡または償還が可能である旨を示す「１」を設定して、譲渡先に消費者１を示す消費者ＩＤを設定した受益権管理データを作成し、受益権管理テーブル２３５に登録する。
【００４６】
さらに、配送処理部２２３は、商品未着通知を消費者１から受信して、譲渡先ＩＤに消費者１を示す消費者ＩＤが設定された受益権管理データに基づいて、ＥＣ事業者２に商品未着通知を送信して、ＥＣ事業者２からの承認を受ける。また、配送処理部２２３は、融資が行われている場合には、融資機関４にも商品未着通知（本発明の回収要求に該当する。）を送信して、融資機関４がＥＣ事業者２から貸付金の回収を行うようにする。
【００４７】
融資処理部２２４（本発明の融資情報受信部に該当する。）は、融資機関４からＥＣ事業者２への融資に関する処理を行う。融資処理部２２４は、融資機関４の融資機関サーバ１４から融資完了通知を受信すると、融資管理テーブル２３４の融資管理データの融資区分を、融資が完了した旨を示す「１」に更新し、融資限度額管理テーブル２３１の融資限度額管理データの融資限度額残高から融資金額を減算する。また、融資処理部２２４は、日次で発生する金利を計算して、融資管理データの金利を更新する。
【００４８】
承認処理部２２５は、ＥＣ事業者２および融資機関４による商品未着通知または受益権譲渡通知についての承認に関する処理を行う。ＥＣ事業者２の事業者端末１３または融資機関４の融資機関サーバ１４から、商品未着通知または受益権譲渡通知に対する承認通知を受信した場合、受益権管理テーブル２３５に登録されている受益権管理データの承認区分（ＥＣ事業者）または承認区分（ファンド）に、ＥＣ事業者２または融資機関４が承認をした旨を示す「２」を設定する。
【００４９】
回収処理部２２６は、融資機関４によるＥＣ事業者２からの融資金の回収に関する処理を行う。回収処理部２２６は、融資機関４の融資機関サーバ１４から回収完了通知を受信すると、融資管理テーブル２３４の融資管理データの融資残高に回収額を加算し、融資区分に、融資の回収が完了した旨を示す「３」を設定する。
【００５０】
代物弁済処理部２２７（本発明の代物弁済承認入力部に該当する。）は、受益権による代物弁済に関する処理を行う。代物弁済処理部２２７は、受益権譲渡通知をＥＣ事業者２の事業者端末１３および融資機関４の融資機関サーバ１４に送信して、受益権管理テーブル２３５に登録されている受益権管理データの承認区分（ＥＣ事業者）および承認区分（ファンド）に、受益権譲渡通知を送信した旨を示す「１」を設定する。
【００５１】
償還処理部２２８は、受益権の償還に関する処理を行う。償還処理部２２８は、信託金管理テーブル２３２から譲渡可能区分が「１」である信託金管理データを抽出し、これに対応する受益権管理データのうち、譲渡先ＩＤがＥＣ事業者２を示すもの、譲渡先ＩＤが消費者１を示し、ＥＣ事業者２の承認がある（承認区分（ＥＣ事業者）に「２」が設定されている）もの、ならびに、譲渡先ＩＤが融資機関４を示し、ＥＣ事業者２および融資機関４の承認がある（承認区分（ＥＣ事業者）に「２」が設定され、承認区分（ファンド）にも「２」が設定されている）ものを受益権管理テーブル２３５から抽出して、これらの譲渡先ＩＤが示す消費者１、ＥＣ事業者２または融資機関４への送金を行い、信託金管理テーブル２３２の信託金管理データに含まれる信託残高から償還した金額を減算するとともに、信託会計管理部２１１に依頼して信託金額を減額するように設定処理を行う。
【００５２】
＝＝信託支援装置２０の処理＝＝
以下、信託支援装置２０により行われる処理について説明する。図１４は、信託支援装置２０により行われる処理の流れを説明する図である。なお、図１４に示す処理は、信託支援装置２０により連続的にあるいは所定の時間ごとに実行される。
【００５３】
＝＝注文関連処理＝＝
注文処理部２２１がＥＣサーバ１２から注文データを受信すると（Ｓ５０１：ＹＥＳ）、注文データに基づいて商品管理データを作成する（Ｓ５０２）。注文データには、ＥＣ事業者２を示す店舗ＩＤおよび注文日時と、注文を受けた商品のそれぞれについての、商品を示す商品ＩＤ、販売額および消費税とが含まれているものとする。なお、注文データには配送予定日が含まれるようにしてもよい。注文処理部２２１は、注文データに含まれている各商品について、新たな商品管理データを作成し、注文データに含まれている商品ＩＤと上記店舗ＩＤとを設定し、商品の販売額を商品代金に設定し、消費税を設定し、注文データの注文日時を設定し、配送区分に「０」を設定し、支払区分に「０」を設定し、配送予定日、配送完了日および支払完了日にｎｕｌｌ値を設定する。注文処理部２２１は、上記のようにして作成した商品管理データを商品管理テーブル２３３に登録する（Ｓ５０３）。注文データに配送予定日が含まれていた場合、注文処理部２２１は、注文データに含まれる配送予定日を信託金管理データに設定するようにしてもよい。  
なお、注文データはＥＣサーバ１２から消費者１の消費者端末１１にも送信されており、消費者１は、これに応じて信託機関３への支払を行うことができる。
【００５４】
＝＝入金処理＝＝
入金処理部２２２が消費者１からの支払を検知すると（Ｓ５０４：ＹＥＳ）、図１５に示す入金処理を行う（Ｓ５０５）。なお、入金処理部２２２は、たとえば、クレジットカード決済による支払の通知をクレジットカード会社のシステムから受信したり、銀行振込による銀行口座への入金を銀行のオンラインバンキングサーバにアクセスして確認したりすることにより、消費者１からの支払を受け付けたことを検出することができる。また、入金処理部２２２は、たとえば、クレジットカードの支払の対象となる注文ＩＤをクレジットカード会社のシステムやＥＣサーバ１２から取得し、あるいは信託機関３の銀行口座への入金額と消費者１の氏名等に基づいて名寄せを行って注文ＩＤを特定するなどの処理により、消費者１からの支払の対象となる注文を示す注文ＩＤを特定可能であるものとする。
【００５５】
入金処理部２２２は、注文ＩＤに対応する商品管理データの支払区分を「１」に更新し（Ｓ５４１）、当該商品管理データの支払完了日を現在の日付に更新する（Ｓ５４２）。入金処理部２２２は、信託会計管理部２１１を起動して、注文ＩＤに対応する信託金管理データに基づいて信託の設定処理を行わせる（Ｓ５４３）。なお、信託会計管理部２１１による信託設定処理には、一般的なエスクローサービスにおける信託会計処理を用いるものとする。入金処理部２２２は、新たに信託金管理データを作成して注文ＩＤを設定し、商品管理データに含まれている商品代金を合計して信託設定金額に設定し、信託残高にも信託設定金額を設定し、信託残高更新日に現在の日付を設定し、譲渡可能区分に「０」を設定し、譲渡可能日にｎｕｌｌ値を設定し、当該信託金管理データを信託金管理テーブル２３２に登録する（Ｓ５４４）。
【００５６】
入金処理部２２２は、信託金管理データの店舗ＩＤに対応する融資限度額管理データが融資限度額管理テーブル２３１に登録されている場合（Ｓ５４５：ＹＥＳ）、信託金管理データの店舗ＩＤに対応する融資限度額管理データを融資限度額管理テーブル２３１から読み出し（Ｓ５４６）、商品管理テーブル２３３から、当該店舗ＩＤに対応し、支払区分が「１」であり、かつ配送区分が「０」である商品管理データを読み出し（Ｓ５４７）、商品代金の合計と消費税の合計とを合計して融資金額とする（Ｓ５４８）。
【００５７】
入金処理部２２２は、融資金額が融資限度額管理データの融資限度額残高以下である場合には（Ｓ５４９：ＹＥＳ）、新たに融資管理データを作成し、融資管理データに上記注文ＩＤ、ファンドＩＤ、店舗ＩＤ、融資金額、消費税、金利を設定し、融資日にｎｕｌｌ値を設定し、融資残高にも融資金額を設定し、融資残高更新日に現在の日付を設定し、融資区分に「０」を設定する（Ｓ５５０）。入金処理部２２２は、融資管理データを融資管理テーブル２３４に登録する（Ｓ５５１）。入金処理部２２２は、融資金額と店舗ＩＤとを含む支払完了通知を融資機関４の融資機関サーバ１４に送信する（Ｓ５５２）。この支払完了通知に応じて、融資機関４では店舗ＩＤが示すＥＣ事業者２に対して、融資金額の融資が行われる。
【００５８】
一方、融資金額が融資限度額残高より大きかった場合には（Ｓ５４９：ＮＯ）、入金処理部２２２は、融資が出来ない旨をＥＣ事業者２の事業者端末１３に送信する（Ｓ５５３）。
【００５９】
入金処理部２２２は、注文ＩＤ、各商品ＩＤおよび消費者１を示す消費者ＩＤを設定した支払完了通知をＥＣ事業者２の事業者端末１３に送信する（Ｓ５５４）。この支払完了通知に応じて、ＥＣ事業者２から消費者１に商品の発送が行われる。
【００６０】
＝＝融資関連処理＝＝
図１４に戻り、融資処理部２２４が融資機関４の融資機関サーバ１４から、注文ＩＤを含む融資完了通知を受信すると（Ｓ５０６：ＹＥＳ）、注文ＩＤに対応する融資管理データの融資区分に「１」を設定するように融資管理テーブル２３４を更新し（Ｓ５０７）、当該融資管理データに含まれるファンドＩＤおよび店舗ＩＤに対応する融資限度額管理データの融資限度額残高から、当該融資管理データに含まれる融資金額を減額するように融資限度額管理テーブル２３１を更新する（Ｓ５０８）。
【００６１】
＝＝配送完了処理＝＝
配送処理部２２３がＥＣ事業者２の事業者端末１３から配送完了通知を受信すると（Ｓ５０９：ＹＥＳ）、図１６に示す配送完了処理を行う（Ｓ５１０）。なお、本実施形態では、説明を簡単にするために、１回の注文に含まれる商品は全て同時に配送されるものとし、複数便に分けて配送することはないものとし、配送完了通知には、配送に関連する注文ＩＤと、商品が配送された日付（配送完了日）とが含まれているものとする。また、配送完了通知は配送業者のシステムや、ＥＣサーバ１２から受信するようにしてもよい。
【００６２】
配送処理部２２３は、配送完了通知に含まれている注文ＩＤに対応する商品管理データの配送区分に「１」を設定するように商品管理テーブル２３３を更新し（Ｓ５６１）、配送完了通知に含まれている配送完了日から所定の日数（本実施形態では４日とするが、任意の日数とすることができる。）後の日付を、当該注文ＩＤに対応する信託金管理データの譲渡可能日に設定するように信託金管理テーブル２３２を更新する（Ｓ５６２）。また、配送処理部２２３は、注文ＩＤに対応する融資管理データが融資管理テーブル２３４に登録されている場合には（Ｓ５６３：ＹＥＳ）、当該融資管理データのファンドＩＤを譲渡先ＩＤとし（Ｓ５６４）、融資管理データのファンドＩＤをファンドＩＤとして決定する（Ｓ５６５）。配送処理部２２３は、注文ＩＤに対応する融資管理データが登録されていない場合には（Ｓ５６３：ＮＯ）、信託金管理データの店舗ＩＤを譲渡先ＩＤとし（Ｓ５６６）、ファンドＩＤには値無し（ｎｕｌｌ値）を設定する（Ｓ５６７）。配送処理部２２３は、新たに割り当て受益権ＩＤを割り当て（Ｓ５６８）、信託金管理データの信託設定金額を譲渡金額とし（Ｓ５６９）、所定の手数料を振込手数料とし（Ｓ５７０）、承認区分（ファンド）を「０」とし（Ｓ５７１）、承認区分（ＥＣ事業者）を「０」とし（Ｓ５７２）、償還区分を「０」とし（Ｓ５７３）、償還日を値無し（ｎｕｌｌ値）として（Ｓ５７４）、受益権ＩＤ、配送完了通知に含まれる注文ＩＤ、ファンドＩＤ、信託金管理データの店舗ＩＤ、譲渡先ＩＤ、譲渡金額、振込手数料、承認区分（ファンド）、承認区分（ＥＣ事業者）、償還区分および償還日を設定した受益権管理データを作成し（Ｓ５７５）、作成した受益権管理データを受益権管理テーブル２３５に登録する（Ｓ５７６）。
【００６３】
以上のようにして、配送完了通知に応じてＥＣ事業者２を受益者とする受益権についての受益権管理データが受益権管理テーブル２３５に登録される。また、融資機関４からＥＣ事業者２に融資が行われている場合には、代物弁済により当該受益権が譲渡される先となる融資機関４についても譲渡先ＩＤとして受益権管理データに設定される。
【００６４】
＝＝配送未着処理＝＝
図１４に戻り、配送処理部２２３が消費者１の消費者端末１１から配送未着通知を受信すると（Ｓ５１１：ＹＥＳ）、図１７に示す配送未着処理を行う（Ｓ５１２）。なお、配送未着通知にも配送に関連する注文ＩＤと消費者１を示す消費者ＩＤとが含まれるものとする。
【００６５】
配送処理部２２３は、配送未着通知に含まれている注文ＩＤに対応する信託金管理データを信託金管理テーブル２３２から読み出し（Ｓ５８１）、読み出した信託金管理データの譲渡可能日が設定されている（ｎｕｌｌ値でない）場合には（Ｓ５８２：ＹＥＳ）、当該譲渡可能日を比較日とし（Ｓ５８３）、信託金管理データに譲渡可能日が設定されていない場合には（Ｓ５８２：ＮＯ）、注文ＩＤに対応する商品管理データを商品管理テーブル２３３から読み出して（Ｓ５８４）、商品管理データの配送予定日に値が設定されている（ｎｕｌｌ値でない）場合（Ｓ５８５：ＹＥＳ）、商品管理データの配送予定日を比較日とし（Ｓ５８６）、商品管理データの配送予定日に値が設定されていない（ｎｕｌｌ値である）場合は（Ｓ５８５：ＹＥＳ）、現在の日次から所定の日数（本実施形態では１４日とするが、任意の日数とすることができる。）後の日付を比較日とする（Ｓ５８７）。なお、本実施形態では、説明を簡単にするために、複数の商品のうち一部のみが配送されるような状況は存在しないものとし、注文ＩＤが同じ商品については同じ配送予定日であるものとする。
【００６６】
配送処理部２２３は、配送未着通知の受信日（現在の日付としてもよい。）が比較日より後であれば（Ｓ５８８：ＹＥＳ）、上記注文ＩＤに対応する商品管理データの配送区分に、商品が届かなかったことを示す「−１」を設定するように商品管理テーブル２３３を更新し（Ｓ５８９）、上記注文ＩＤに対応する信託金管理データの譲渡可能区分に、償還が可能になった旨を示す「１」を設定するように信託金管理テーブル２３２を更新する（Ｓ５９０）。
【００６７】
配送処理部２２３は、注文ＩＤに対応する融資管理データが融資管理テーブル２３４に登録されている場合には（Ｓ５９１：ＹＥＳ）、融資管理データのファンドＩＤを、配送未着通知に含まれている消費者ＩＤとし（Ｓ５９２）、ファンドＩＤを融資管理データのファンドＩＤとし（Ｓ５９３）、注文ＩＤに対応する融資管理データが登録されていない場合には（Ｓ５９１：ＮＯ）、配送未着通知に含まれている消費者ＩＤを譲渡先ＩＤとし（Ｓ５９４）、ファンドＩＤは値無し（ｎｕｌｌ値）とする（Ｓ５９５）。配送処理部２２３は、新たに受益権ＩＤを割り当て（Ｓ５９６）、信託金管理データの信託設定金額を譲渡金額とし（Ｓ５９７）、所定の手数料を振込手数料とし（Ｓ５９８）、承認区分（ファンド）を「０」とし（Ｓ５９９）、承認区分（ＥＣ事業者）を「０」とし（Ｓ６００）、償還区分を「０」とし（Ｓ６０１）、償還日を値無し（ｎｕｌｌ値）として（Ｓ６０２）、受益権ＩＤ、配送完了通知に含まれる注文ＩＤ、ファンドＩＤ、信託金管理データの店舗ＩＤ、譲渡先ＩＤ、譲渡金額、振込手数料、承認区分（ファンド）、承認区分（ＥＣ事業者）、償還区分および償還日を設定した受益権管理データを作成し（Ｓ６０３）、作成した受益権管理データを受益権管理テーブル２３５に登録する（Ｓ６０４）。
【００６８】
一方、配送未着通知の受信日が比較日以前であれば（Ｓ５８８：ＮＯ）、配送処理部２２３返金はまだ出来ない旨を示すメッセージを送信して（Ｓ６０５）、処理を終了する。
【００６９】
以上のようにして、配送未着処理に応じて、受信日が譲渡可能日あるいは配送予定日を過ぎている場合には、消費者１を受益者とする受益権についての受益権管理データが受益権管理テーブル２３５に登録される。
【００７０】
＝＝承認関連処理＝＝
図１４に戻り、承認処理部２２５がＥＣ事業者２の事業者端末１３または融資機関４の融資機関サーバ１４から、注文ＩＤを含む承認通知を受信した場合（Ｓ５１３：ＹＥＳ）、承認処理部２２５は、注文ＩＤに対応する受益権管理データについて、事業者端末１３から承認通知を受信したときには承認区分（ＥＣ事業者）に、融資機関サーバ１４から受信したときには承認区分（ファンド）に「２」を設定するように受益権管理テーブル２３５を更新する（Ｓ５１４）。
【００７１】
＝＝金利更新処理＝＝
融資処理部２２４は、融資管理テーブル２３４に登録されている融資管理データのうち、融資残高更新日が本日より前（昨日以前）の融資管理データを検索し（Ｓ５１５）、検索した融資管理データのそれぞれについて、店舗ＩＤおよびファンドＩＤに対応する融資限度額管理データを融資限度額管理テーブル２３１から読み出して利率とし（Ｓ５１６）、融資残高更新日から現在までの日数を計算する（Ｓ５１７）。融資処理部２２４は、融資残高に利率を乗じた値を現在の年の日数（３６５または３６６）で割った日次の金利に、上記日数を乗じたものを金利に加算し（Ｓ５１８）、融資残高更新日を現在の日付にするように（Ｓ５１９）、融資管理テーブル２３４を更新する。以上の処理を各融資管理データについて行うことにより、融資残高に応じた日次の金利が、融資管理データの金利に加算されていく。
【００７２】
＝＝回収関連処理＝＝
回収処理部２２６が融資機関４の融資機関サーバ１４から、注文ＩＤおよび回収額を含む回収完了通知を受信した場合には（Ｓ５２０：ＹＥＳ）、回収処理部２２６は、回収完了通知に含まれる注文ＩＤに対応する融資管理データの金利が、回収完了通知に含まれる回収額よりも大きい場合には（Ｓ５２１：ＮＯ）、当該融資管理データの金利から回収額を減算するように融資管理テーブル２３４を更新する（Ｓ５２２）。一方、金利が回収額以下であれば（Ｓ５２１：ＹＥＳ）、回収処理部２２６は、上記融資管理データの融資残高に金利を加算して回収額を減じ（Ｓ５２３）、金利に「０」を設定するように（Ｓ５２４）、融資管理テーブル２３４を更新する。また、回収処理部２２６は、上記融資管理データの融資残高が「０」となった場合には（Ｓ５２５：ＹＥＳ）、当該融資管理データの融資区分に、融資の回収が完了した旨を示す「３」を設定するように融資管理テーブル２３４を更新する（Ｓ５２６）。
【００７３】
なお、ＥＣ事業者２から消費者１に商品が配送されなかった場合、後述する未配送処理によって商品未着通知が融資機関４に送信され、融資機関４はＥＣ事業者２への融資金額の全額が回収されることになり、この融資金額が回収額として通知されることになる。
【００７４】
一方、ＥＣ事業者２から消費者１に商品が配送された場合には、後述する代物弁済処理によって受益権により譲渡金額が弁済されることになる。譲渡金額は、商品の販売額の合計額（あるいはそこから手数料を減額した金額）であるので、融資機関４はＥＣ事業者２から金利等を代物弁済でまかなえなかったものとして追徴し、その追徴に係る回収額が通知されることになる。
【００７５】
＝＝定期処理＝＝
配送処理部２２３は、譲渡可能日が本日（またはそれ以前）であり、かつ、譲渡可能区分が「０」である信託金管理データについて、譲渡可能区分に「１」を設定するように信託金管理テーブル２３２を更新する（Ｓ５２７）。  
なお、ステップＳ５１８の処理は、所定の時刻にのみ行われるようにしてもよい。
【００７６】
＝＝未配送承認処理＝＝
配送処理部２２３は、図１８に示す未配送承認処理を行う（Ｓ５２８）。  
まず、配送処理部２２３は、商品未着通知をＥＣ事業者２に送信していない注文についての受益権管理データを読み出す。すなわち、配送処理部２２３は、受益権管理テーブル２３５に記憶されている受益権管理データのうち、注文ＩＤに対応する信託金管理データの譲渡可能区分が「１」であり、償還区分が「０」であり、譲渡先ＩＤには消費者１を示す消費者ＩＤが設定されており、かつ、承認区分（ＥＣ事業者）が「０」であるものを読み出す（Ｓ６２１）。なお、譲渡先ＩＤには消費者ＩＤ、店舗ＩＤまたはファンドＩＤが設定されうるが、譲渡先ＩＤが消費者１を示すか、ＥＣ事業者２を示すか、融資機関４を示すかは設定されたデータ自体から判別可能であるものとする。たとえば、上１桁が「１」であれば消費者ＩＤであり、上１桁が「２」であれば店舗ＩＤであり、上１桁が「３」であればファンドＩＤというように設定することができる。
【００７７】
配送処理部２２３は、読み出した受益権管理データのそれぞれについて、受益権管理データの注文ＩＤを設定した商品未着通知を、受益権管理データの店舗ＩＤが示すＥＣ事業者２の事業者端末１３に送信し（Ｓ６２２）、受益権管理データの承認区分（ＥＣ事業者）に、商品未着通知を送信した旨を示す「１」を設定するように受益権管理テーブル２３５を更新する（Ｓ６２３）。なお、商品未着通知は、たとえば電子メールとして送信するようにすることができる。この場合、店舗ＩＤに対応するメールアドレスを記憶装置２０３などに記憶しておくようにし、配送処理部２２３は、このメールアドレスに宛てた電子メールに注文ＩＤと、商品が未着である旨を示すメッセージとを記載して送信することができる。また、商品未着通知には、受益権管理データに含まれる項目、受益権管理データの注文ＩＤに対応する信託金管理データに含まれる項目、受益権管理データの注文ＩＤに対応する商品管理データに含まれる項目などから任意の項目を含めるようにすることもできる。
【００７８】
次に、配送処理部２２３は、商品未着通知を融資機関４に送信していない注文についての受益権管理データを読み出す。すなわち、配送処理部２２３は、受益権管理テーブル２３５に記憶されている受益権管理データのうち、注文ＩＤに対応する信託金管理データの譲渡可能区分が「１」であり、償還区分が「０」であり、譲渡先ＩＤには消費者１を示す消費者ＩＤが設定されており、承認区分（ＥＣ事業者）が「２」であり、かつ、承認区分（ファンド）が「０」であるものを読み出す（Ｓ６２４）。配送処理部２２３は、読み出した受益権管理データのそれぞれについて、受益権管理データの注文ＩＤに対応する融資管理データが融資管理テーブル２３４に登録されている場合にのみ（Ｓ６２５：ＹＥＳ）、受益権管理データのファンドＩＤが示す融資機関４の融資機関サーバ１４に対して、受益権管理データの注文ＩＤを含む商品未着通知を送信し（Ｓ６２６）、受益権管理データの承認区分（ファンド）に、商品未着通知を送信した旨を示す「１」を設定するように受益権管理テーブル２３５を更新する（Ｓ６２７）。なお、融資機関４に対する商品未着通知についても、たとえば電子メールで送信することができる。この場合、ファンドＩＤに対応するメールアドレスを記憶装置２０３に記憶しておき、配送処理部２２３は、このメールアドレスに対して注文ＩＤと、商品が未着であり、ＥＣ事業者２もそのことを承認している旨を示すメッセージを記載した電子メールを送信することができる。また、融資機関４に対する商品未着通知についても、上記ＥＣ事業者２に対する商品未着通知と同様の項目を含めるようにすることができる。融資機関４は、融資機関サーバ１４が当該商品未着通知を受信し、これに応じて承認通知を送信したことを契機としてＥＣ事業者２から貸付金の回収を行うことができる。
【００７９】
以上のようにして、消費者１から配送未着通知を受けて譲渡先ＩＤに消費者ＩＤが設定された受益権管理データについて、ＥＣ事業者２に対して商品未着通知が送信され、これに対してＥＣ事業者２から承認通知を受けて承認区分（ＥＣ事業者）に「２」が設定された受益権管理データについて、融資機関４に対して商品未着通知が送信される。
【００８０】
＝＝代物弁済処理＝＝
図１４に戻り、代物弁済処理部２２７は、図１９に示す代物弁済処理を行う（Ｓ５２９）。  
まず、代物弁済処理部２２７は、融資が行われ、配送が完了したものの、受益権による代物弁済の承認をＥＣ事業者２から受けていない受益権管理データを抽出する。すなわち、代物弁済処理部２２７は、受益権管理テーブル２３５に記憶されている受益権管理データのうち、注文ＩＤに対応する信託金管理データの譲渡可能区分が「１」であり、償還区分が「０」であり、譲渡先ＩＤには融資機関４を示すファンドＩＤが設定されており、かつ、承認区分（ＥＣ事業者）が「０」であるものを読み出す（Ｓ６４１）。代物弁済処理部２２７は、読み出した受益権管理データのそれぞれについて、受益権管理データの注文ＩＤを含む受益権譲渡通知を、受益権管理データの店舗ＩＤが示すＥＣ事業者２の事業者端末１３に送信し（Ｓ６４２）、受益権管理データの承認区分（ＥＣ事業者）に、受益権譲渡通知を送信した旨を示す「１」を設定するように受益権管理テーブル２３５を更新する（Ｓ６４３）。
【００８１】
次に、代物弁済処理部２２７は、受益権譲渡通知を融資機関４に送信していない注文についての受益権管理データを読み出す。すなわち、代物弁済処理部２２７は、受益権管理テーブル２３５に記憶されている受益権管理データのうち、注文ＩＤに対応する信託金管理データの譲渡可能区分が「１」であり、償還区分が「０」であり、譲渡先ＩＤには融資機関４を示すファンドＩＤが設定されており、承認区分（ＥＣ事業者）が「２」であり、かつ、承認区分（ファンド）が「０」であるものを読み出す（Ｓ６４４）。代物弁済処理部２２７は、読み出した受益権管理データのそれぞれについて、受益権管理データのファンドＩＤが示す融資機関４の融資機関サーバ１４に対して、受益権管理データの注文ＩＤを含む受益権譲渡通知を送信し（Ｓ６４５）、受益権管理データの承認区分（ファンド）に、受益権譲渡通知を送信した旨を示す「１」を設定するように受益権管理テーブル２３５を更新する（Ｓ６４６）。
【００８２】
なお、ＥＣ事業者２および融資機関４に対する受益権譲渡通知についても、たとえば電子メールで送信することができる。また、受益権譲渡通知にも、上述した商品未着通知と同様の項目を含めるようにすることができる。
【００８３】
以上のようにして、配送完了通知を受けて譲渡先ＩＤにファンドＩＤが設定された受益権管理データについて、ＥＣ事業者２に対して受益権譲渡通知が送信され、これに対してＥＣ事業者２から承認通知を受けて承認区分（ＥＣ事業者）に「２」が設定された受益権管理データについて、融資機関４に対して受益権譲渡通知が送信される。
【００８４】
＝＝償還処理＝＝
図１４に戻り、償還処理部２２８は、図２０に示す償還処理を行う（Ｓ５３０）。  
償還処理部２２８は、譲渡可能区分に「１」が設定されている信託金管理データを信託金管理テーブル２３２から読み出し（Ｓ６６１）、読み出した信託金管理データのそれぞれについて以下の処理を行う。
【００８５】
償還処理部２２８は、配送が完了してＥＣ事業者２が受益者となっている取引に係る受益権管理データと、配送がされず、ＥＣ事業者２もそれを承認して消費者１が受益者となっている取引に係る受益権管理データと、配送が完了して融資機関４に代物弁済がなされた取引に係る受益権管理データとを抽出する。すなわち、償還処理部２２８は、注文ＩＤが信託金管理データの注文ＩＤに一致し、償還区分が「０」であり、かつ、譲渡先ＩＤにＥＣ事業者２を示す店舗ＩＤが設定されている受益権管理データを受益権管理テーブル２３５から読み出し（Ｓ６６２）、注文ＩＤが信託金管理データの注文ＩＤに一致し、償還区分が「０」であり、譲渡先ＩＤに消費者１を示す消費者ＩＤが設定されており、かつ、承認区分（ＥＣ事業者）が「２」である受益権管理データを受益権管理テーブル２３５から読み出し（Ｓ６６３）、注文ＩＤが信託金管理データの注文ＩＤに一致し、償還区分が「０」であり、譲渡先ＩＤに融資機関４を示すファンドＩＤが設定されており、承認区分（ＥＣ事業者）が「２」であり、かつ、承認区分（ファンド）が「２」である受益権管理データを受益権管理テーブル２３５から読み出す（Ｓ６６４）。償還処理部２２８は、ステップＳ６６２〜Ｓ６６４で読み出した受益権管理データのそれぞれについて、以下の処理を行う。
【００８６】
償還処理部２２８は、受益権管理データの譲渡先ＩＤが示す消費者１、ＥＣ事業者２または融資機関４に対して譲渡金額を送信するように送金管理部２１２に指示を行うことにより受益権の償還を行う（Ｓ６６５）。送金管理部２１２はたとえば銀行口座からの振込処理などの一般的な処理により送金を行うものとする。送金管理部２１２はたとえば、消費者ＩＤ、店舗ＩＤおよびファンドＩＤに対応付けて銀行口座の口座番号やクレジットカード番号などを記憶しておき、銀行口座やクレジットカードなどに対して送金を行うようにすることができる。
【００８７】
償還が完了すると、償還処理部２２８は、受益権管理データの償還区分に「１」を設定するように受益権管理テーブル２３５を更新し（Ｓ６６６）、信託金管理データの信託残高から送金額（譲渡金額）を減額するように信託金管理テーブル２３２を更新し（Ｓ６６７）、これに合わせて信託金を減額するように信託会計管理部２１１に指示する（Ｓ６７８）。信託会計管理部２１１は、一般的な信託会計処理により信託金を減額する処理を行うものとする。
【００８８】
償還処理部２２８は、譲渡先ＩＤが融資機関４を示すファンドＩＤである場合には（Ｓ６６９：ＹＥＳ）、受益権管理データの注文ＩＤに対応する融資管理データの融資区分に、融資の元本が弁済されたことを示す「２」を設定し（Ｓ６７０）、当該融資管理データの融資残高から送金額を減額するように（Ｓ６７１）、融資管理テーブル２３４を更新する。
【００８９】
以上の処理を各受益権管理データおよび各信託金管理データについて繰り返すことにより、受益権の償還が行われる。
【００９０】
＝＝効果＝＝
以上説明したように、本実施形態のエスクローシステムでは、商品の配送前に受益権を担保にして融資を行うことができる。一般的なエスクローサービスでは、商品が配送されるまでの間は受益権が償還されず、さらには商品が配送されても、配送された商品に間違いがないか否かを消費者１が検品することができる期間を設けることがあり、この期間が経過するまで受益権が償還されないこともあるところ、本実施形態のエスクローシステムでは、商品の配送前に融資機関４からＥＣ事業者２に融資がなされるため、ＥＣ事業者２のキャッシュフローが改善する。その一方で、融資期間４からＥＣ事業者２への融資は、信託機関３による信託は設定されたままで融資が行われるため、消費者１の受益権は商品の配送完了まで消滅することなく、存続させることができる。
【００９１】
また、本実施形態のエスクローシステムでは、ＥＣ事業者２に対する融資機関４の与信額（融資限度額）の範囲内でのみ融資を行うが、融資限度額残高が少ない場合には、通常のエスクローサービスと同様に、配送後に受益権を償還するようにすることができる。したがって、ＥＣ事業者２は、融資機関４からの与信額の範囲内では融資を受けつつ、与信額の範囲外では通常のエスクローサービスを利用することができる。よって、与信枠が小さなＥＣ事業者２であっても、消費者１に対する安心感を与えるエスクローサービスのメリットを最大限に享受しつつ、キャッシュフローを改善することができる。
【００９２】
また、本実施形態のエスクローシステムでは、消費者１から配送未着通知を受けた場合には、ＥＣ事業者２に対して商品未着通知を送信して、商品未着の確認を促すことができる。
【００９３】
＝＝変形例＝＝
なお、本実施形態では、融資機関４からＥＣ事業者２への融資金額は、消費者１からの支払金額に消費税と金利とを加算したものとしたが、これに限らず、たとえば消費者１からの支払金額を融資金額として、消費税や金利は融資金額に含めないようにしてもよい。また、たとえば、融資金額を支払金額よりも少なくしてもよい。この場合には、信託機関３は、商品の配送完了時に、融資額（金利を加算してもよい。）を融資機関に償還した後に、差額をＥＣ事業者２に償還するようにすることができる。
【００９４】
また、本実施形態では、融資機関サーバ１４が信託支援装置２０から支払完了通知を受信したことを契機として融資機関４はＥＣ事業者２に融資を行うものとしたが、これに限らず、たとえば、信託支援装置２０が注文データを受けたときに融資機関サーバ１４に通知し、これを契機として融資を行うようにしてもよい。
【００９５】
また、本実施形態では、融資機関サーバ１４が信託支援装置２０から商品未着通知を受信し、これに承認通知を送信したことを契機としてＥＣ事業者２から貸付金の回収を行うものとしたが、これに限らず、たとえば商品未着通知を受信したことを契機として回収を行うものとし、商品未着通知を送信した場合には融資機関４からの承認区分（ファンド）を管理しないようにしてもよい。
【００９６】
また、本実施形態では、配送完了通知を受信し、譲渡可能日になった後、さらにＥＣ事業者２からの承認通知を受信した後に、融資機関４への受益権の償還を行うものとしたが、これに限らず、予めＥＣ事業者２からの承諾を得ておき、譲渡可能日となったところで償還を行うようにしてもよい。
【００９７】
また、本実施形態では、消費者１への償還については、ＥＣ事業者２の承認があれば融資機関４の承認は問わずに償還処理を行うものとしたが（図２０のステップＳ６６３）、融資を行った場合（注文ＩＤに対応する融資管理データが融資管理テーブル２３４に登録されている場合）には、融資機関４からの承認を受けて承認区分（ファンド）が「２」となったものについて償還処理を行うようにしてもよい。
【００９８】
また、本実施形態では、融資機関４からＥＣ事業者２に対する与信額とは別に融資限度額残高を記憶し、融資が行われ、また受益権が償還されるたびに融資限度額を増減させるものとしたが、これに限らず、与信額のみを記憶しておき、与信額を増減させるようにしてもよい。
【００９９】
以上、本実施形態について説明したが、上記実施形態は本発明の理解を容易にするためのものであり、本発明を限定して解釈するためのものではない。本発明は、その趣旨を逸脱することなく、変更、改良され得ると共に、本発明にはその等価物も含まれる。
【０１００】
たとえば、本実施形態では、信託支援装置２０は１台のコンピュータであるものとしたが、複数台のコンピュータで実現することもできる。たとえば、信託支援装置２０の信託会計管理部２１１および送金管理部２１２の少なくともいずれかを別のコンピュータで実現させ、これに対して信託設定や送金の指示を行うコマンドを送信するようにすることもできるし、エスクロー管理部２１３の各記憶部を信託支援装置２０とは異なるデータベースサーバに実現させ、データベースサーバにアクセスするようにしてもよい。
【符号の説明】
【０１０１】
１  消費者
２  ＥＣ事業者
３  信託機関
４  融資機関
１１  消費者端末
１２  ＥＣサーバ
１３  事業者端末
１４  融資機関サーバ
２０  信託支援装置
２１１  信託会計管理部
２１２  送金管理部
２１３  エスクロー管理部
２２１  注文処理部
２２２  入金処理部
２２３  配送処理部
２２４  融資処理部
２２５  承認処理部
２２６  回収処理部
２２７  代物弁済処理部
２２８  償還処理部
２３１  融資限度額管理テーブル
２３２  信託金管理テーブル
２３３  商品管理テーブル
２３４  融資管理テーブル
２３５  受益権管理テーブル
【図１】
2014099050.tif 000003
【図２】
2014099050.tif 000004
【図３】
2014099050.tif 000005
【図４】
2014099050.tif 000006
【図５】
2014099050.tif 000007
【図６】
2014099050.tif 000008
【図７】
2014099050.tif 000009
【図８】
2014099050.tif 000010
【図９】
2014099050.tif 000011
【図１０】
2014099050.tif 000012
【図１１】
2014099050.tif 000013
【図１２】
2014099050.tif 000014
【図１３】
2014099050.tif 000015
【図１４】
2014099050.tif 000016
【図１５】
2014099050.tif 000017
【図１６】
2014099050.tif 000018
【図１７】
2014099050.tif 000019
【図１８】
2014099050.tif 000020
【図１９】
2014099050.tif 000021
【図２０】
2014099050.tif 000022