特許 7314169 不動産の融資、サービス、およびレポートのリアルータイムの動的管理のための方法および金融商品

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2023-07-14

(45)【発行日】2023-07-25

(54)【発明の名称】不動産の融資、サービス、およびレポートのリアルータイムの動的管理のための方法および金融商品

(51)【国際特許分類】

   G06Q 40/02 20230101AFI20230718BHJP

   G06Q 50/16 20120101ALI20230718BHJP

【ＦＩ】

G06Q40/02

G06Q50/16

【請求項の数】 16

(21)【出願番号】P 2020557137

(86)(22)【出願日】2019-01-08

(65)【公表番号】

(43)【公表日】2021-05-13

(86)【国際出願番号】 US2019012665

(87)【国際公開番号】W WO2019136430

(87)【国際公開日】2019-07-11

【審査請求日】2021-12-24

(31)【優先権主張番号】16/241,820

(32)【優先日】2019-01-07

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】62/614,720

(32)【優先日】2018-01-08

(33)【優先権主張国・地域又は機関】US

(73)【特許権者】

【識別番号】520249310

【氏名又は名称】ドモス，エルエルシー

(74)【代理人】

【識別番号】110000062

【氏名又は名称】弁理士法人第一国際特許事務所

(72)【発明者】

【氏名】ストルナド ザ セカンド， ジェームズ フランク

【審査官】速水 雄太

(56)【参考文献】

【文献】特表２０１２－５１５９８５（ＪＰ，Ａ）

【文献】米国特許出願公開第２０１７／０２４３２８７（ＵＳ，Ａ１）

【文献】韓国登録特許第１０－１８０７６５８（ＫＲ，Ｂ１）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｑ １０／００－９９／００

(57)【特許請求の範囲】

【請求項1】

不動産の融資、サービス、およびレポートをリアルータイムで動的に管理するためのコンピュータ実装方法であって、
プロセッサが、管理エンティティによって制御され、そして少なくとも住宅所有者と出資者がアクセス可能なウェブサイトに、住宅金融商品の取引に関する条件、前記住宅金融商品に関するデータパラメータ、および住宅融資アレンジメントの下で今後要求されるアクションの表示を、維持すること；
前記プロセッサが、少なくとも住宅金融商品データブロックチェーンを含む少なくと
も１つのブロックチェーンシステムに、前記住宅金融商品に関するデータを格納すること；
前記プロセッサが、バランシング機構の下で調整を実装するために、管理エンティティによって制御される少なくとも１つの処理サーバ上に、少なくとも１つの処理ユニット、少なくとも１つの受信ユニット、および少なくとも１つの送信ユニットで具体化されるバランシングエンジンを維持すること；
前記バランシングエンジンの受信ユニットが、前記管理エンティティまたはそれを表す人工知能エンティティからメッセージを周期的に受信して、前記住宅金融商品データブロックチェーンへのバランシングエントリを開始すること；
前記バランシングエンジンの送信ユニットが、バランシング計算に関連するデータに対する前記ブロックチェーンシステムのクエリを送信すること；
前記バランシングエンジンの受信ユニットが、当該データを受信すること；
直接アレンジメントの場合、
前記バランシングエンジンの処理ユニットが、少なくとも１つの残余口座の更新されたバランスを決定すること；
前記バランシングエンジンの送信ユニットが、前記計算の詳細と共に前記更新された残余口座バランスを、前記住宅金融商品データブロックチェーンに書き込むこと；
前記バランシングエンジンの処理ユニットと送信ユニットが、少なくとも住宅所有者と出資者がアクセス可能なウェブサイトを修正して、前記更新された残余口座バランスを表示すること；そして
前記バランシングエンジンの送信ユニットが、オフラインになっている可能性がある少なくとも住宅所有者および出資者に、携帯電話または他の受信デバイスにより、前記更新された残余口座バランスをアラートすること；
直接アレンジメントではないアレンジメントの場合、
前記バランシングエンジンの処理ユニットが、更新されたスケジュールされていない成果と、前記スケジュールされていない成果を入力として使用する、関連付けられている数量とを、決定すること；
前記バランシングエンジンの送信ユニットが、前記更新されたスケジュールされていない成果と関連付けられている数量とを、前記計算の詳細と共に、前記住宅金融商品データブロックチェーンに書き込むこと；
前記バランシングエンジンの処理ユニットと送信ユニットが、少なくとも住宅所有者、出資者、および残余バランシングポジション保有者がアクセス可能なウェブサイトを修正して、前記更新されたスケジュールされていない成果と関連付けられている数量とを表示すること；そして
前記バランシングエンジンの送信ユニットが、オフラインの可能性がある、少なくとも住宅所有者、出資者、および残りのバランシングポジション保有者に、携帯電話または他の受信デバイスにより、前記更新されたスケジュールされていない成果と関連付けられている数量とをアラートすることを、
備える方法。

【請求項2】

管理エンティティによって制御される少なくとも１つの処理サーバ上に、少なくとも１つの処理ユニット、少なくとも１つの受信ユニット、少なくとも１つの送信ユニット、および少なくとも１つのデータベースで具体化される少なくとも１つのデータエンジンを維持し、当該処理サーバが、少なくとも１つの前記住宅金融商品に関するデータパラメータの少なくとも１つの時系列を、作成、収集、更新、処理、格納、および通信することを、更に、備える、請求項１に記載の方法。

【請求項3】

少なくとも１つのデータエンジンの受信ユニットで、前記データエンジンによって生成された少なくとも１つのデータパラメータを計算するための入力データを備える第三者のデータを、受信すること；
前記データエンジンの処理ユニットが、追加されたデータをフォーマットし、そして前記データエンジンの同じ処理ユニットが、データベースを修正して、前記追加されたデータを組み込むこと；
前記データエンジンの処理ユニットが、前記データパラメータの少なくとも１つの非第三者バージョンを計算すること；
前記データエンジンの処理ユニットが、前記第三者および非第三者評価を使用して、前記データパラメータの単一の運用値を計算すること；
前記データエンジンの送信ユニットが、前記データパラメータの前記更新された運用値を、少なくとも、前記計算の日時スタンプと、前記第三者および非第三者の値と、住宅金融商品データブロックチェーンの運用値を計算するために使用される方法論とを含む前記計算のレコードと共に、書き込むこと；
前記データエンジンの処理ユニットと送信ユニットが、少なくとも住宅所有者と出資者がアクセス可能なウェブサイトを修正して、前記データパラメータの前記更新された運用値を表示し、そして一般的に、または前記データパラメータの特定の値が実現されたときに、何れかの当事者が、前記運用値の更新をリクエストしたときに、前記データエンジンの送信ユニットが、オフラインの可能性がある少なくとも住宅所有者および出資者に、携帯電話または他の受信デバイスにより、前記更新された運用値をアラートすることを、
更に、備える、請求項１に記載の方法。

【請求項4】

少なくとも１つの第三者の融資アレンジメントから出現する少なくとも１つのデータパラメータの少なくとも１つの時系列を、作成、収集、更新、処理、格納、および通信する目的で、前記管理エンティティによって制御される少なくとも１つの処理サーバ上に、少なくとも１つの処理ユニット、少なくとも１つの受信ユニット、少なくとも１つの送信ユニット、および少なくとも１つのデータベースで具体化された少なくとも１つの第三者データエンジンを、維持することを、
更に、備える、請求項１に記載の方法。

【請求項5】

前記管理エンティティによって制御される処理サーバ上で運用される少なくとも１つの第三者データエンジンの受信ユニットで、少なくとも１つの第三者金融アレンジメントに関するデータを、受信すること；
前記第三者データエンジンの処理ユニットが、住宅金融商品データブロックチェーンに記録されるべきデータの要素を識別すること；
記録されるべき前記データを適切なフォーマットに修正すること；
第三者データエンジンの送信ユニットが、住宅金融商品データブロックチェーンに、関連付けられている任意の計算のレコードと共に、データ要素を書き込むこと；
前記第三者データエンジンの受信ユニットが、前記住宅金融商品データブロックチェーンから、前記第三者の融資アレンジメントの前記現在のステータスと関連付けられている履歴とを記述するデータを、抽出すること；
前記第三者データエンジンの処理ユニットが、ウェブサイトの表示のために当該データを編成すること；
第三者データエンジンの処理ユニットと送信ユニットが、少なくとも住宅所有者と出資者がアクセス可能なウェブサイトを修正して、前記第三者の融資アレンジメントの前記更新データを表示すること；そして
もし、前記特定のデータパラメータの特定の値が実現されたことに基づいて、何れかの当事者が、更新されたこのような更新データを要求した場合、前記第三者データエンジンの送信ユニットが、オフラインの可能性がある、少なくとも、住宅所有者とオフラインの出資者に、携帯電話または他の受信デバイスにより、前記更新データをアラートすることを、
更に、備える、請求項１に記載の方法。

【請求項6】

少なくとも一人の住宅所有者と出資者との間の前記住宅融資アレンジメントを、開始、実装、実施、および更新するために、管理エンティティによって制御される少なくとも１つの処理サーバに、少なくとも１つの処理ユニット、少なくとも１つの受信ユニット、および少なくとも１つの送信ユニットで具体化された契約エンジンを、維持することを、
更に、備える、請求項１に記載の方法。

【請求項7】

管理エンティティによって制御される処理サーバ上で運用される契約エンジンの受信ユニットが、住宅融資アレンジメントを記述する初期契約データを受信すること；
処理ユニット要素が、住宅金融商品データブロックチェーンに記録されるべき前記初期契約データの要素を識別すること；
前記契約エンジンの処理ユニットが、適切なフォーマットに記録されるべき前記データを編成および修正すること；そして
前記契約エンジンの送信ユニットが、住宅金融商品データブロックチェーンに、前記必要なデータ要素を書き込むことを、
更に、備える、請求項１に記載の方法。

【請求項8】

管理エンティティによって制御されるウェブサイトまたは他の入力デバイス上に、前記住宅所有者から、新しい条件の少なくとも１つのオプションを指定する住宅融資アレンジメントの少なくとも１つの条件を変更するリクエストを、受信すること；そして
前記管理エンティティによって制御される処理サーバの送信ユニットが、前記管理エンティティによって制御される処理ユニットにより動作する契約エンジンの受信ユニットに、前記リクエストを送信することを、
更に、備える、請求項１に記載の方法。

【請求項9】

直接アレンジメントの場合、契約エンジンの受信ユニットが、前記住宅金融商品データブロックチェーンから、各オプションのリクエストされた変更を管理する必要な契約条項を、他の関連データと共に、抽出すること；
契約エンジンの処理ユニットが、各オプションのリクエストされた変更が前記住宅融資アレンジメント契約の下で許可されているか否かを、決定すること；
条件の変更が許可されている場合、前記住宅所有者以外の当事者による任意の承諾が要求されているか否かを決定すること；
少なくとも１つのオプションに基づく条件の変更が、許容される場合、承諾を要求する各オプションの承諾に承諾するまたはそれを拒否する必要性を、当該当事者の少なくとも１つの受信デバイスにより、少なくとも１つの関連する当事者にアラートすることにより、前記契約エンジンの送信ユニットが、各オプションに対して要求される任意の承諾を求めること；
応答を受け取った後、または応答期限が経過した後、前記契約エンジンの処理ユニットが、住宅所有者によって提案された各オプションが同意されているか拒否されているかを決定すること；
前記契約エンジンの送信ユニットが、前記住宅所有者がアクセス可能なウェブサイトを修正して、前記住宅所有者に各オプションが承認されているか拒否されているかを通知し、そして少なくとも１つのオプションが承認されている場合は、前記住宅所有者に、前記オプションの１つを受諾するまたはそれら全てを拒否することを確認するようにリクエストすること；
データエンジンの送信ユニットが、少なくともオフラインになっている可能性がある前記住宅所有者に、前記承認または拒否されたオプションを、携帯電話または他の受信デバイスによりアラートし、そして少なくとも１つのオプションが承認されると、前記住宅所有者に１つのオプションまたはそれら全ての拒否の確認をリクエストすること；
前記住宅所有者がオプションを確認したときに、前記契約エンジンの送信ユニットが、少なくとも条件の前記変更の発効日と時間を含む、前記受諾されたオプションを構成する関連データと共に、条件の変更を住宅金融商品データブロックチェーンに書き込むこと；
前記契約エンジンの処理ユニットと送信ユニットが、少なくとも住宅所有者と出資者がアクセス可能なウェブサイトを修正して、前記変更が有効であることを確認し、そして前記変更の有効な日時を表示し、そして前記新しい住宅融資アレンジメント条件を表示すること；そして
前記契約エンジンの送信ユニットが、携帯電話または他の受信デバイスにより、前記変更の有効な日時と共に、前記変更が有効であることを、オフラインの可能性がある少なくとも住宅所有者および出資者に、アラートすることを、
更に、備える、請求項１に記載の方法。

【請求項10】

直接アレンジメントではないアレンジメントの場合、第三者データエンジンの受信ユニットは、住宅データブロックチェーンから、少なくともデータを含む要求された変更を管理する必要な契約条項を、少なくとも、各オプションに関して前記住宅所有者へのオファーを生成するデータを含む、他の関連データと共に、抽出し、前記オファーには、前記リクエストの前記対象である前記条件以外の前記住宅融資アレンジメントの条件の変更が含まれていること；
契約エンジンの処理ユニットが、前記住宅所有者によって指定された条件変更オプションごとに、少なくとも１つのオファーを計算すること；
前記契約のエンジンの送信ユニットが、前記住宅所有者がアクセス可能なウェブサイトを修正して、前記住宅所有者に前記オファーを通知すること；
前記住宅所有者に、前記オファーの１つの受諾を確認する、または前記オファーの全ての拒否を確認することをリクエストすること；
前記契約エンジンの送信ユニットが、オフラインになっている可能性がある少なくとも前記住宅所有者に、携帯電話または他の受信デバイスにより、前記オファーと１つのオファーを受諾する、または前記オファーの全てを拒否する前記必要性とをアラートすること；
前記契約エンジンの処理ユニットが、少なくとも、前記オファーの前記コンテンツと前記オファー時の前記管理データパラメータの前記値（前記オファー条件を管理する値）とを含むオファーデータアンサンブルを作成すること；
前記契約エンジンの送信ユニットが、前記オファーデータアンサンブルを、前記住宅金融商品データブロックチェーンに書き込むこと；
前記住宅所有者がオファーを受諾すると、前記契約エンジンの受信ユニットが、前記住宅金融商品データブロックチェーンから前記オファーデータアンサンブルを抽出すること；
前記契約エンジンの処理ユニットが、前記オファーデータアンサンブルを使用して、前記既存の住宅融資アレンジメントを完了し、そしてそれを、前記受諾されたオファーで指定された前記条件を具体化した新しい住宅融資で置き換えるために要求される、少なくとも住宅所有者、前記出資者、および残余バランシングポジション保有者の間の前記調整を計算すること；
前記契約エンジンの送信ユニットが、要求されるステップを前記関連する当事者に通知するメッセージを、送信すること；
前記契約エンジンの受信ユニットが、当事者間で要求される任意の支払いを含む、前記要求されるステップが、既に、完了していることの検証を受け取ること；
前記契約エンジンの処理ユニットが、少なくとも前記既存の住宅融資アレンジメントを完了するために行われた前記調整を含む移行データパッケージ、前記新しい住宅融資アレンジメントの前記条件、および前記新しいアレンジメントが有効になる日時を、前記当事者の前記開始残余口座ポジションと共に、コンパイルすること；
前記契約エンジンの送信ユニットが、前記移行データを前記住宅金融商品データブロックチェーンに書き込んで、前記新しい住宅融資アレンジメントへのシフトを実行すること；
前記契約エンジンの処理ユニットが、関連する各当事者に適した前記移行データの別々の表示可能なバージョンを作成すること；
前記契約エンジンの処理ユニットと送信ユニットが、前記関連する当事者がアクセス可能なウェブサイトを修正して、前記ウェブサイトの別々の部分の別々のバージョンの前記移行データを、各別々の当事者に表示し、そして前記新しいアレンジメントを前記ウェブサイトの一般的にアクセス可能な領域に表示すること；そして
前記契約エンジンの送信ユニットが、オフラインになっている可能性がある前記関連する当事者のそれぞれに、その当事者に関連する前記移行データと、前記新しい住宅融資アレンジメントを記述する前記共通データとをアラートすることを、
更に、備える、請求項１に記載の方法。

【請求項11】

管理エンティティによって制御されるウェブサイトまたは他の入力デバイスで、住宅所有者から、残余口座ポジションを少なくとも１人の出資者に売却する、または、少なくとも１人の出資者から残余口座ポジションを購入するリクエストを受け取ること；および
前記管理エンティティによって制御される処理サーバの送信ユニットが、前記売却または購入リクエストを、前記管理エンティティによって制御される処理ユニットにより運用される契約エンジンの受信ユニットに、送信することを、
更に、備える、請求項１に記載の方法。

【請求項12】

直接アレンジメントの場合、契約エンジンの受信ユニットが、前記住宅金融商品データブロックチェーンから、リクエストされた売却または購入を管理する必要な契約条項を、少なくとも前記売却または購入の前記条件を決定するために要求されるデータを含む他の関連データと共に、抽出すること；
前記契約エンジンの処理ユニットが、前記リクエストされた売却または購入が、前記住宅融資アレンジメント契約の下で許可されているか否かを決定すること；
前記リクエストされた売却または購入が、前記住宅融資アレンジメント契約の下で許可されている場合、前記取引の反対側の前記出資者による承諾が要求されているか否かを決定すること；
前記契約エンジンの処理ユニットが、前記購入または売却の適用可能な条件を決定すること；
前記売却または購入が許容される場合、前記契約エンジンの送信ユニットが、要求に応じて、前記計算された条件に基づいて、各当該出資者の少なくとも１つの受信デバイスにより、前記出資者に、前記条件と承諾を承諾するまたは拒否する前記必要性をアラートすることにより、出資者の承諾を求めること；
応答を受け取った後、または応答の期限が経過した後、前記契約エンジンの処理ユニットが、前記計算された条件での前記売却または購入が、承認されているまたは拒否されているかを決定すること；
前記契約エンジンの送信ユニットが、前記住宅所有者がアクセス可能なウェブサイトを修正して、前記住宅所有者に承認または拒否を通知すること；
承認のために、前記計算された前記条件に基づいて受諾または拒否を確認するよう前記住宅所有者にリクエストすること；
前記契約エンジンの送信ユニットが、オフラインになっている可能性がある前記住宅所有者に、携帯電話または他の受信デバイスにより、同意または拒否をアラートすること；
承認のため、前記計算された条件に基づいて、前記住宅所有者に前記取引の同意または拒否を確認するようにリクエストすること；
前記住宅所有者が前記取引を確認すると、前記契約エンジンの送信ユニットが、要求されるステップを前記関連当事者または当事者に通知するメッセージを送信すること；
前記契約エンジンの受信ユニットが、当事者間の要求される支払いを含む、要求されるステップが、既に完了していることの確認を受け取ること；
前記契約エンジンの処理ユニットが、少なくとも前記取引の前記確認、前記取引の前記条件、前記取引が有効になった前記日時、および前記当事者の前記新しい残余口座のポジションを含む取引データパッケージを、コンパイルすること；
前記契約エンジンの送信ユニットが、前記契約エンジンの処理ユニットによるフォーマットの後、前記取引データを前記住宅金融商品データブロックチェーンに書き込むこと；
前記契約エンジンの処理ユニットと送信ユニットが、少なくとも住宅所有者と出資者がアクセス可能なウェブサイトを修正して、前記取引データの前記関連部分を表示するステップ、そして
前記契約エンジンの送信ユニットが、オフラインの可能性がある少なくとも住宅所有者と出資者に、携帯電話または他の受信デバイスにより、前記取引データの前記関連部分をアラートするステップを
更に、備える、請求項１に記載の方法。

【請求項13】

直接アレンジメントではないアレンジメントで、前記住宅金融商品データブロックチェーンから、前記第三者データエンジンの受信ユニットが、リクエストされた売却または購入を管理する必要な契約条項を、少なくとも、前記提案された売却または購入に関して前記住宅所有者へのオファーを生成するのに十分なデータを含む他の関連データと共に、抽出するステップであって、各オファーには、前記提案された売却または購入に伴う前記住宅融資アレンジメントの前記条件の変更が含まれる、こと；
前記契約エンジンの処理ユニットが、前記住宅所有者によって提案された前記売却または購入に関する少なくとも１つのオファーを計算すること；
前記契約エンジンの処理ユニットが、前記リクエストされた売却または購入が、前記住宅融資アレンジメント契約の下で許可されているか否かを決定すること；
前記リクエストされた売却または購入が、前記住宅融資アレンジメント契約の下で許可されている場合、前記取引の反対側の前記出資者による承諾が、要求されているか否かを決定すること；
前記契約エンジンの処理ユニットが、前記購入または売却の前記適用可能な条件および各オファーの前記条件を決定すること；
前記売却または購入が、許容される場合、前記送信ユニットが、各当該出資者の少なくとも１つの受信デバイスにより、前記出資者に、前記オファーおよび各オファーを承諾するまたはそれを拒否する前記必要性をアラートすることにより、前記計算された条件に基づいて、要求に応じて、各オファーに関する出資者の承諾を求めること；
応答を受け取った後、または応答の前記期限が経過した後、前記契約エンジンの処理ユニットが、各オファーが承認されたまたは拒否されたかを決定すること；
前記契約エンジンの送信ユニットが、前記住宅所有者がアクセス可能なウェブサイトを修正して、前記住宅所有者に各オファーの承認または拒否を知らせること；
少なくとも１つのオファーの承認のため、住宅所有者に、売却または購入の条件と共に１つのオファーの受諾を検証するか、または全てを拒否するようにリクエストすること；
前記契約エンジンの送信ユニットが、オフラインになっている可能性がある前記住宅所有者に、携帯電話または他の受信デバイスにより、各オファーの承認または拒否をアラートすること；
少なくとも１つのオファーの承認のため、前記売却または購入の条件と共に１つのオファーの受諾を確認する、またはそれら全てを拒否するかを、前記住宅所有者にリクエストすること；
前記契約エンジンの処理ユニットが、少なくとも、前記オファーの前記コンテンツ、前記売却または購入条件、および前記オファー時の前記管理データパラメータの前記値（前記オファー条件を管理する値）を含む、オファーデータアンサンブルを作成すること；
前記契約エンジンの送信ユニットが、前記オファーデータアンサンブルを前記住宅金融商品データブロックチェーンに書き込むこと；
前記住宅所有者が、前記売却または購入条件と共に、オファーを受諾すると、前記契約エンジンの受信ユニットが、前記住宅金融商品データブロックチェーンから前記オファーデータアンサンブルを抽出すること；
前記契約エンジンの処理ユニットが、前記オファーデータアンサンブルを使用して、少なくとも、住宅所有者、出資者、および残余バランシングポジション保有者の間の調整を計算し、前記残余バランシングポジション保有者が、前記既存の住宅融資アレンジメントを完了し、そしてそれを、前記受諾されたオファーで指定された前記条件を具体化する新しい住宅融資アレンジメントにより、置き換えることを要求されること；
前記契約エンジンの送信ユニットが、前記関連する当事者に、要求されるステップを通知するメッセージを送信すること；
前記契約エンジンの受信ユニットが、当事者間の要求される支払いを含む、前記要求されるステップが、既に完了していることの検証を受け取ること；
前記契約エンジンの処理ユニットが、少なくとも、前記既存の住宅融資アレンジメントを完了するために行われた前記調整、前記売却または購入の前記条件、前記当事者の前記開始残余口座のポジションを伴う前記新しい住宅融資アレンジメントの前記条件、および前記新しいアレンジメントが有効になった日時、を含む移行データパッケージをコンパイルすること；
前記契約エンジンの送信ユニットが、前記移行データを前記住宅金融商品データブロックチェーンに書き込むこと；
前記新しい住宅融資アレンジメントへのシフトを実行すること；
前記契約エンジンの処理ユニットが、前記関連付けられている各当事者に適した移行データの別々の表示可能なバージョンを作成すること；
前記契約エンジンの処理ユニットと送信ユニットが、前記関連する当事者がアクセス可能なウェブサイトを修正し、前記移行データを前記ウェブサイトの別々の部分に別々のバージョンで表示し、そして前記ウェブサイトの一般的にアクセス可能な領域に前記新しいアレンジメントを表示すること；そして
前記契約エンジンの送信ユニットが、オフラインになっている可能性がある関連当事者のそれぞれに、その当事者に関連付けられている移行データと、新しい住宅融資アレンジメントを説明する共通データとをアラートすることを、
更に、備える、請求項１に記載の方法。

【請求項14】

前記ブロックチェーンシステムが、
特定の住宅に融資する少なくとも１人の出資者と少なくとも１人の住宅所有者との間の少なくとも１つの住宅融資アレンジメントを指定する契約情報;
少なくとも１つの住宅融資アレンジメントの動的管理に関連する経済データパラメータの時系列；
前記融資負債またはエクイティの現在および過去の所有権のレコード；
少なくとも前記住宅所有者による出資者への支払いを含む取引のレコード；
前記住宅融資アレンジメントの任意の調整または変更のレコード；
前記住宅所有者と出資者の間の住宅融資アレンジメントをジョイントベンチャとして考慮し、そして前記当事者の前記純拠出を反映するために少なくとも１つの残余口座を調整して、少なくとも前記住宅所有者と出資者の純拠出を追跡するための少なくとも１つのバランシング機構の仕様；
１つ以上のバランシング機構に基づいて、少なくとも１つの残余アカウントの調整結果と共に、継続的に運用されるバランシングエンジンのデータと計算のレコード；
前記ブロックチェーンシステム内のデータへのアクセスの様々なレベル、および前記ブロックチェーンシステムに新しいデータを書き込むためのアクセス許可のレベルを規定するアクセスプロトコール；そして
前記住宅融資アレンジメントの前記対象となる住宅を記述するデータ
を備える、請求項１に記載の方法。

【請求項15】

不動産の融資、サービス、およびレポートをリアルータイムで動的に管理する方法であって、
住宅融資アレンジメントの下での、住宅金融商品の取引に関する条件、前記住宅金融商品に関するデータパラメータ、および今後のアクションを表示する、住宅所有者および出資者がアクセス可能なウェブサイトを維持すること；
前記住宅金融商品をブロックチェーンに格納すること；
バランシング機構の下で調整を実装すること；
前記住宅金融商品へのバランシングエントリを開始する管理エンティティから、メッセージを、周期的に、受信すること；
バランシング計算に関連するデータに対するクエリを前記ブロックチェーンに送信すること；
当該データを受け取ること；
更新されたバランスを決定すること；
前記住宅金融商品の計算の詳細と共に、更新された口座バランスを、前記ブロックチェーンに書き込むこと；
住宅所有者および出資者がアクセス可能なウェブサイトを修正して、前記更新された口座バランスを表示すること；そして
モバイルデバイスにより、前記更新された口座バランスを前記住宅所有者と出資者にアラートすること
を備える方法。

【請求項16】

取引データを容易にするためのシステムであって、
取引の第１の当事者として取引データを容易にするための、ユーザインターフェースを有する住宅所有者のコンピューティングデバイス；
前記取引の第２の当事者として取引データを容易にするための、ユーザインターフェースを有する出資者のコンピューティングデバイス；
コンピュータインターフェースを有する管理エンティティデバイスであって、前記管理エンティティが、
前記取引データに基づいて、バランシング機構の下で調整を実装するための少なくとも１つのバランシングエンジンデバイス；
前記取引データに基づいて、少なくとも１つの時系列を作成、収集、更新、処理、格納、および通信するための少なくとも１つのデータエンジンデバイス；そして
前記取引データに基づいて、少なくとも住宅所有者と出資者の間の住宅融資アレンジメントを開始、実装、実施、および更新するための少なくとも１つの契約エンジンデバイス
を備える、管理エンティティデバイス；
前記取引データに基づいて、関連する第三者の融資データを提供する、関連付けられているコンピュータインターフェースを有する複数の第三者デバイス；
前記住宅所有者の前記コンピューティングデバイスまたは前記出資者の前記コンピューティングデバイスが、前記取引に基づいて、購入オファーメッセージを送信できるようにするための中央取引エンジンデータベース；
前記取引データを容易にするために使用される機密データを安全に格納するための分散ブロックチェーンシステム；そして
前記住宅所有者の前記コンピューティングデバイス、出資者の前記コンピューティングデバイス、前記中央取引エンジンデータベース、前記複数の第三者デバイス、前記分散ブロックチェーンシステム、および前記管理エンティティデバイスの間でデータを受信、処理、および送信するアプリケーションレイヤー;
を備え、
前記取引に応じて、当該アプリケーションレイヤーが、前記住宅所有者と出資者がアクセス可能なウェブサイトを修正し；そして
当該アプリケーションレイヤーが、モバイルデバイスにより前記住宅所有者と出資者に前記取引をアラートする、
システム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、データ処理に関する。より詳細には、本発明は、不動産の融資、サービス、およびレポーティングをリアルータイムで動的管理するための方法および金融商品に関する。

【背景技術】

【0002】

コンピュータ技術は、消費者とプロバイダに対し、多くの商品およびサービスの統合された低コストの経験を提供する。例えば、出資サービスの消費者は、金融商品の売買ができる金融商品会社のウェブサイトにアクセスし、リアルータイムで彼らの口座を追跡し、毎月の明細書を受け取り、金融商品価格の見積もりを受け取り、証拠金借入を行って金融商品を購入し、金融商品を借りて空売りし、そして異なる機能を備えている、より高額なサービスと低額なサービスのレベル間を行き来することが出来る。コンピュータ技術は、取引環境、証拠金貸し付け、金融商品決済サービス、相場情報の提供等を含む、運用を行う他のサービスプロバイダとリアルータイムでリンクする。この結果、シームレスで包括的で低コストのプレゼンテーションが可能になるだけではなく、出資サービスの消費者および様々なサービスプロバイダの両方に対する実行が可能になる。特に、消費者は、通常、いくつかのＧＵＩに基づくページにより１つのウェブサイトで必要な全てのサービスに低コストでアクセスすることが出来、かつ様々なサービスプロバイダは、同じウェブサイトによって効率的に消費者と対話することが出来る。

【0003】

他の多くの業界と比較して、住宅不動産サービスおよび金融の分野における現在のコンピュータ技術では、住宅を購入しかつ所有する消費者、抵当権またはエクイティ資金を提供する出資者、および様々なサービスプロバイダに対するプレゼンテーションが、高コストで、分断化されている。様々な機能およびサービスが、オンラインで実装されているが、これらは統合されていない。現在のコンピュータ技術は、金融側の様々な関連する当事者間に適切な調整がなされていないので、全ての関連する当事者に高いコストを課す結果をもたらしている。この結果、消費者の体験は、サービスプロバイダが調整してシームレスに運用する出資サービスを利用することができ、消費者が別々にまたは全く対処する必要がないものには、ほど遠いものとなっている。以下の説明は、住宅用不動産サービスと金融の分野における現在のテクノロジに固有の分断化と連携の欠如を示している。

【0004】

住宅の購入、融資、および売却には、複数の行為者と複数の取引が関係する。主な当事者のいくつかは、（１）住宅所有者；（２）抵当権またはエクイティ融資を提供する出資者；（３）消費者と対話して抵当権またはエクイティ融資または借り換えを開始するオリジネータ；（４）住宅所有者からの支払いの回収、出資者への支払いの移転、および双方への情報の提供などの機能を実行する抵当権のサービサ；（５）抵当権の出資者から、１つまたは複数の費用が支払われないことに対し保険を引受ける抵当権保険会社；（６）抵当権または賃貸物件の出資プール；および（７）住宅の売買に参加する不動産業者等、である。

【0005】

分断化は、住宅所有者レベルで特に顕著である。住宅所有者は、異なる目的で別々のウェブサイトにアクセスする必要がある。住宅所有者は、抵当権の一連のウェブサイト（例、Rocket Mortgage）で抵当権または借り換えを申請することが出来る。住宅所有者は、サービサが提供する別々のポータルにアクセスして、彼らの抵当権に関する情報を受け取り、そして支払いを行うことが出来る。住宅購入者または住宅売却者は、評価を提供しかつリストされた資産を識別するさらに他のウェブサイト（例、ZillowやRedfin）にアクセスすることが出来る。不動産業者は、購入および売却サービスを提供するウェブサイト（例、Coldwell Banker）を有している。

【0006】

この分断化により、幾つかのサービスは、コンピュータ技術により統合された継続的なサービスに統合されずに、別々に行われるため、非常にコストがかかる。例えば、抵当権の借り換えには、多くの場合、ローン元本の２～３％のコストがかかる。この状況は、ほとんどまたは全く費用をかけずにオンラインで利用規約を変更できると言う、継続的な機能がある他の多くの消費者サービスとは、著しく対照的である。

【0007】

この分断化には、住宅所有者と彼らに関係する様々なサービスプロバイダの両方に対するコストを押し上げる連携の欠如が伴う。抵当権の扱いが、良い例である。抵当権は、通常、プールにパッケージ化されていて、そして出資者に売却される。金利が下がると、住宅所有者は、抵当権を前払いしそして借り換えを行う。これにより、既存の抵当権のプールの価値は下がる。出資者に対するこの前払いリスクにより、出資者は、貸し付けに、通常、住宅所有者が支払うより高い金利という形のプレミアムを要求する。借り換えは、既存の抵当権の修正ではなく、de novo取引であるので、住宅所有者は、通常、現在の抵当権のサービシングウェブサイトとは別のウェブサイトで、または完全にオフラインで金融機関または抵当権ブローカと、の何れかで、これを実行する。

【0008】

分断化と連携の欠如は、住宅エクイティと抵当権の出資者とに余分のコストをもたらすのみならず、主要な出資機会を排除してしまう。最も顕著なことは、所有者が占有する住宅に包括的に出資することが、非常に難しいことである。負債の構成要素である抵当権は、主要な出資ビークルである。シェアドアプリシエーションモーゲッジ（shared appreciation mortgage）の一部として、または直接（例、Unison）の何れかで、アプリシエーションエクイティに出資することも可能である。

【0009】

現在、所有者が占有している住宅からのリターン、つまり、暗黙の賃貸料と評価の両方を包括的に把握する方法はない。現在のビークルは、暗黙の賃貸料に全くアクセスしない。第三者が、所有者が占有する住宅に包括的に出資することができないことは、大きな損失である。住宅用不動産は、主要な資産クラスであり、２０１７年には米国で例えば、３１．８兆ドルに達し、これは米国のエクイティ時価総額を上回っている。この大部分は、所有者が占有している。

【0010】

賃貸住宅のポートフォリオ（例、American Homes for Rent）に出資することは可能であるが、これらの住宅は、所有者がテナントよりもより良好な世話をするので、所有者が占有する住宅よりも収益が低くなる傾向がある。

【0011】

分断化は、サービスプロバイダレベルにも存在する。抵当権プールまたは出資者に対する抵当権の引受およびマーケティングのような個々の機能は、別々のウェブサイトまたはポータルで行われる。これらの機能は、動的な方法で消費者に調整されていない。これらは、住宅所有者のステータスまたは住宅所有者が望む抵当権取引に変更があった場合に、手動で更新する必要がある別々のステップである。

【0012】

この分断化と連携の欠如の環境の背後にあるのは、単純な現実である。現在のコンピュ ータ技術は、通常、互いに調整されていない単一のビジネス手法または操作を採用していて、かつそれらを主にそのままオンラインで別々に適用している。例えば、紙のアプリケーションに記入する代わりに、主にその目的に特化されているウェブサイトで抵当権のアプリケーションにオンラインで記入することが行われている。統合された低コストのコンピュータ実装は、利用できない。

【先行技術文献】

【特許文献】

【0013】

【文献】米国特許第９,８７０,５６２号

【非特許文献】

【0014】

【文献】Alan Auerbach（AJ Auerbach、回顧的キャピタルゲイン課税、American Economic Review，vol．８１、pp．１６７-１７８（１９９１年３月）

【発明の概要】

【0015】

一実施形態によれば、不動産の金融、サービス、および報告をリアルータイムで動的管理するためのコンピュータ技術システムは、以下のこと：

管理エンティティによって制御され、そして少なくとも住宅所有者と出資者がアクセス可能なウェブサイトに、前記条件の表示、パラメータ値、および住宅融資アレンジメントに基づく今後要求されるアクションを、維持すること；

少なくとも住宅金融商品データブロックチェーンを含む少なくとも１つのブロックチェーンシステムに、特定の住宅に融資する少なくとも１人の住宅所有者と少なくとも１人の出資者との間の少なくとも１つの住宅融資アレンジメントを指定する契約情報;少なくとも１つの住宅融資アレンジメントの動的管理に関連する経済パラメータの時系列；前記融資負債またはエクイティの現在および過去の所有権のレコード；少なくとも前記住宅所有者による出資者への支払いを含む取引のレコード；前記住宅融資アレンジメントの任意の調整または変更のレコード；前記住宅所有者と出資者の間の住宅融資アレンジメントをジョイントベンチャとして考慮し、そして前記当事者の前記純拠出を反映するために少なくとも１つの残余口座を調整して、少なくとも前記住宅所有者と出資者の純拠出を追跡するための少なくとも１つのバランシング機構の仕様；１つ以上のバランシング機構に基づいて、少なくとも１つの残余アカウントの調整結果と共に、継続的に運用されるバランシングエンジンのデータと計算のレコード；前記ブロックチェーンシステム内のデータへのアクセスの様々なレベル、および前記ブロックチェーンシステムに新しいデータを書き込むためのアクセス許可のレベルを規定するアクセスプロトコール；そして前記住宅融資アレンジメントの前記対象となる住宅を記述するデータ、を格納すること；

前記プロセッサが、バランシング機構の下で調整を実装するために、管理エンティティによって制御される少なくとも１つのサーバ上に、少なくとも１つの処理ユニット、少なくとも１つの受信ユニット、および少なくとも１つの送信ユニットで具体化されるバランシングエンジンを維持すること；

前記バランシングエンジンの受信ユニットが、前記管理エンティティまたはそれを表す人工知能エンティティからメッセージを周期的に受信して、前記住宅金融商品データブロックチェーンへのバランシングエントリを開始すること；前記バランシングエンジンの送信ユニットが、バランシング計算に関連するデータに対する前記ブロックチェーンシステムのクエリを送信すること；前記バランシングエンジンの受信ユニットが、当該データを受信すること；

直接アレンジメントの場合、前記バランシングエンジンの処理ユニットが、少なくとも１つの残余口座の更新されたバランスを決定すること；前記バランシングエンジンの送信ユニットが、前記計算の詳細と共に前記更新された残余口座バランスを、前記住宅金融商品データブロックチェーンに書き込むこと；前記バランシングエンジンの処理ユニットと送信ユニットが、少なくとも住宅所有者と出資者がアクセス可能なウェブサイトを修正して、前記更新された残余口座バランスを表示すること；そして前記バランシングエンジンの送信ユニットが、オフラインになっている可能性がある少なくとも住宅所有者および出資者に、携帯電話または他の受信デバイスにより、前記更新された残余口座バランスをアラートすること；

直接アレンジメントの場合、前記バランシングエンジンの処理ユニットが、少なくとも１つの残余口座の更新されたバランスを決定すること；前記バランシングエンジンの送信ユニットが、前記計算の詳細と共に前記更新された残余口座バランスを、前記住宅金融商品データブロックチェーンに書き込むこと；前記バランシングエンジンの処理ユニットと送信ユニットが、少なくとも住宅所有者と出資者がアクセス可能なウェブサイトを修正して、前記更新された残余口座バランスを表示すること；そして前記バランシングエンジンの送信ユニットが、オフラインになっている可能性がある少なくとも住宅所有者および出資者に、携帯電話または他の受信デバイスにより、前記更新された残余口座バランスをアラートすること；

直接アレンジメントではないアレンジメントの場合、前記バランシングエンジンの処理ユニットが、更新されたスケジュールされていない成果と、前記スケジュールされていない成果を入力として使用する、関連付けられている数量とを、決定すること；前記バランシングエンジンの送信ユニットが、前記更新されたスケジュールされていない成果と関連付けられている数量とを、前記計算の詳細と共に、前記住宅金融商品データブロックチェーンに書き込むこと；前記バランシングエンジンの処理ユニットと送信ユニットが、少なくとも住宅所有者、出資者、および残余バランシングポジション保有者がアクセス可能なウェブサイトを修正して、前記更新されたスケジュールされていない成果と関連付けられている数量とを表示すること；そして前記バランシングエンジンの送信ユニットが、オフラインの可能性がある、少なくとも住宅所有者、出資者、および残りのバランシングポジション保有者に、携帯電話または他の受信デバイスにより、前記更新されたスケジュールされていない成果と関連付けられている数量とをアラートすること；

管理エンティティによって制御される少なくとも１つの処理サーバ上に、少なくとも１つの処理ユニット、少なくとも１つの受信ユニット、少なくとも１つの送信ユニット、および少なくとも１つのデータベースで具体化される少なくとも１つのデータエンジンを維持し、当該処理サーバが、少なくとも１つのデータパラメータの少なくとも１つの時系列を、作成、収集、更新、処理、格納、および通信すること；

少なくとも１つのデータエンジンの受信ユニットで、前記データエンジンによって生成された少なくとも１つのデータパラメータを計算するための入力データを備える第三者のデータを、受信すること；前記データエンジンの処理ユニットが、前記追加されたデータをフォーマットし、そして前記データエンジンの同じ処理ユニットが、データベースを修正して、前記追加されたデータを組み込むこと；前記データエンジンの処理ユニットが、前記データパラメータの少なくとも１つの非第三者バージョンを計算すること；前記データエンジンの処理ユニットが、前記第三者および非第三者評価を使用して、前記データパラメータの単一の運用値を計算すること；前記データエンジンの送信ユニットが、前記データパラメータの前記更新された運用値を、少なくとも、前記計算の日時スタンプと、前記第三者および非第三者の値と、住宅金融商品データブロックチェーンの運用値を計算するために使用される方法論とを含む前記計算のレコードと共に、書き込むこと；前記データエンジンの処理ユニットと送信ユニットが、少なくとも住宅所有者と出資者がアクセス可能なウェブサイトを修正して、前記データパラメータの前記更新された運用値を表示し、そして一般的に、または前記データパラメータの特定の値が実現されたときに、何れかの当事者が、前記運用値の更新をリクエストしたときに、前記データエンジンの送信ユニットが、オフラインの可能性がある少なくとも住宅所有者および出資者に、携帯電話または他の受信デバイスにより、前記更新された運用値アラートすること；

少なくとも１つの第三者の融資アレンジメントから出現する少なくとも１つのデータパラメータの少なくとも１つの時系列を、作成、収集、更新、処理、格納、および通信する目的で、前記管理エンティティによって制御される少なくとも１つの処理サーバ上に、少なくとも１つの処理ユニット、少なくとも１つの受信ユニット、少なくとも１つの送信ユニット、および少なくとも１つのデータベースで具体化された少なくとも１つの第三者データエンジンを、維持すること；

前記管理エンティティによって制御される処理サーバ上で運用される少なくとも１つの第三者データエンジンの受信ユニットで、少なくとも１つの第三者金融アレンジメントに関するデータを、受信すること；前記第三者データエンジンの処理ユニットが、住宅金融商品データブロックチェーンに記録されるべきデータの要素を識別すること；記録されるべき前記データを適切なフォーマットに修正すること；第三者データエンジンの送信ユニットが、住宅金融商品データブロックチェーンに、関連付けられている任意の計算のレコードと共に、データ要素を書き込むこと；前記第三者データエンジンの受信ユニットが、前記住宅金融商品データブロックチェーンから、前記第三者の融資アレンジメントの前記現在のステータスと関連付けられている履歴とを記述するデータを、抽出すること；前記第三者データエンジンの処理ユニットが、ウェブサイトの表示のために当該データを編成すること；第三者データエンジンの処理ユニットと送信ユニットが、少なくとも住宅所有者と出資者がアクセス可能なウェブサイトを修正して、前記第三者の融資アレンジメントの前記更新データを表示すること；そしてもし、一般にまたは前記特定のデータパラメータの特定の値が実現されたことに基づいて、何れかの当事者が、更新されたこのような更新データを要求した場合、前記第三者データエンジンの送信ユニットが、オフラインの可能性がある、少なくとも、所有者とオフラインの出資者に、携帯電話または他の受信デバイスにより、前記更新データをアラートすること；

少なくとも一人の住宅所有者と出資者との間の前記住宅融資アレンジメントを、開始、実装、実施、および更新するために、管理エンティティによって制御される少なくとも１つの処理サーバに、少なくとも１つの処理ユニット、少なくとも１つの受信ユニット、および少なくとも１つの送信ユニットで具体化された契約エンジンを、維持すること；

管理エンティティによって制御される処理サーバ上で運用される契約エンジンの受信ユニットが、住宅融資アレンジメントを記述する初期契約データを受信すること；処理ユニットが、住宅金融商品データブロックチェーンに記録されるべき前記初期契約データの要素を識別すること；前記契約エンジンの処理ユニットが、適切なフォーマットに記録されるべき前記データを編成および修正すること；そして前記契約エンジンの送信ユニットが、住宅金融商品データブロックチェーンに、前記必要なデータ要素を書き込むこと；

管理エンティティによって制御されるウェブサイトまたは他の入力デバイス上に、前記住宅所有者から、新しい条件の少なくとも１つのオプションを指定する住宅融資アレンジメントの少なくとも１つの条件を変更するリクエストを、受信すること；そして前記管理エンティティによって制御されるサーバの送信ユニットが、前記管理エンティティによって制御される処理ユニットにより動作する契約エンジンの受信ユニットに、前記リクエストを送信すること；

直接アレンジメントの場合、前記契約エンジンの受信ユニットが、前記住宅金融商品データブロックチェーンから、各オプションの前記リクエストされた変更を管理する必要な契約条項を、他の関連データと共に、抽出すること；前記契約エンジンの処理ユニットが、各オプションの要求された変更が前記住宅融資アレンジメント契約の下で許可されているか否かを、決定すること；条件の変更が許可されている場合、前記住宅所有者以外の当事者による任意の承諾が要求されているか否かを決定すること；少なくとも１つのオプションに基づく条件の変更が、許容される場合、承諾を要求する各オプションの承諾に承諾するまたはそれを拒否する必要性を、当該当事者の少なくとも１つの受信デバイスにより、少なくとも１つの関連する当事者にアラートすることにより、前記契約エンジンの送信ユニットが、各オプションに対して要求される任意の承諾を求めること；応答を受け取った後、または応答期限が経過した後、前記契約エンジンの処理ユニットが、住宅所有者によって提案された各オプションが同意されているか拒否されているかを決定すること；前記契約エンジンの送信ユニットが、前記住宅所有者がアクセス可能なウェブサイトを修正して、前記住宅所有者に各オプションが承認されているか拒否されているかを通知し、そして少なくとも１つのオプションが承認されている場合は、前記住宅所有者に、前記オプションの１つを受諾するまたはそれら全てを拒否することを確認するようにリクエストすること；前記データエンジンの送信ユニットが、少なくともオフラインになっている可能性がある前記住宅所有者に、前記承認または拒否されたオプションを、携帯電話または他の受信デバイスによりアラートし、そして少なくとも１つのオプションが承認されると、前記住宅所有者に１つのオプションまたはそれら全ての拒否の確認をリクエストすること；前記住宅所有者がオプションを確認したときに、前記契約エンジンの送信ユニットが、少なくとも条件の前記変更の発効日と時間を含む、前記受諾されたオプションを構成する関連データと共に、条件の変更を住宅金融商品データブロックチェーンに書き込むこと；前記契約エンジンの処理ユニットと送信ユニットが、少なくとも住宅所有者と出資者がアクセス可能なウェブサイトを修正して、前記変更が有効であることを確認し、そして前記変更の有効な日時を表示し、そして前記新しい住宅融資アレンジメント条件を表示すること；そして前記契約エンジンの送信ユニットが、携帯電話または他の受信デバイスにより、前記変更の有効な日時と共に、前記変更が有効であることを、オフラインの可能性がある少なくとも住宅所有者および出資者に、アラートすること；

直接アレンジメントではないアレンジメントの場合、前記第三者データエンジンの受信ユニットは、前記住宅データブロックチェーンから、少なくともデータを含む要求された変更を管理する必要な契約条項を、少なくとも、各オプションに関して前記住宅所有者へのオファーを生成するデータを含む、他の関連データと共に、抽出し、前記オファーには、前記リクエストの前記対象である前記条件以外の前記住宅融資アレンジメントの条件の変更が含まれていること；前記契約エンジンの処理ユニットが、前記住宅所有者によって指定された条件変更オプションごとに、少なくとも１つのオファーを計算すること；前記契約のエンジンの送信ユニットが、前記住宅所有者がアクセス可能なウェブサイトを修正して、前記住宅所有者に前記オファーを通知すること；前記住宅所有者に、前記オファーの１つの受諾を確認する、または前記オファーの全ての拒否を確認することをリクエストすること；前記契約エンジンの送信ユニットが、オフラインになっている可能性がある少なくとも前記住宅所有者に、携帯電話または他の受信デバイスにより、前記オファーと１つのオファーを受諾する、または前記オファーの全てを拒否する前記必要性とをアラートすること；前記契約エンジンの処理ユニットが、少なくとも、前記オファーの前記コンテンツと前記オファー時の前記管理データパラメータの前記値（前記オファー条件を管理する値）とを含むオファーデータアンサンブルを作成すること；前記契約エンジンの送信ユニットが、前記オファーデータアンサンブルを、前記住宅金融商品データブロックチェーンに書き込むこと；前記住宅所有者がオファーを受諾すると、前記契約エンジンの受信ユニットが、前記住宅金融商品データブロックチェーンから前記オファーデータアンサンブルを抽出すること；前記契約エンジンの処理ユニットが、前記オファーデータアンサンブルを使用して、前記既存の住宅融資アレンジメントを完了し、そしてそれを、前記受諾されたオファーで指定された前記条件を具体化した新しい住宅融資で置き換えるために要求される、少なくとも住宅所有者、前記出資者、および残余バランシングポジション保有者の間の前記調整を計算すること；前記契約エンジンの送信ユニットが、要求されるステップを前記関連する当事者に通知するメッセージを、送信すること；前記契約エンジンの受信ユニットが、当事者間で要求される任意の支払いを含む、前記必要とされるステップが、既に、完了していることの検証を受け取ること；前記契約エンジンの処理ユニットが、少なくとも前記既存の住宅融資アレンジメントを完了するために行われた前記調整を含む移行データパッケージ、前記新しい住宅融資アレンジメントの前記条件、および前記新しいアレンジメントが有効になる日時を、前記当事者の前記開始残余口座ポジションと共に、コンパイルすること；前記契約エンジンの送信ユニットが、前記移行データを前記住宅金融商品データブロックチェーンに書き込んで、前記新しい住宅融資アレンジメントへのシフトを実行すること；前記契約エンジンの処理ユニットが、関連する各当事者に適した前記移行データの別々の表示可能なバージョンを作成すること；前記契約エンジンの処理ユニットと送信ユニットが、前記関連する当事者がアクセス可能なウェブサイトを修正して、前記ウェブサイトの別々の部分の別々のバージョンの前記移行データを、各別々の当事者に表示し、そして前記ウェブサイトの一般的にアクセス可能な領域に前記新しいアレンジメントを表示すること；そして前記契約エンジンの送信ユニットが、オフラインになっている可能性がある前記関連する当事者のそれぞれに、その当事者に関連する前記移行データと、前記新しい住宅融資アレンジメントを記述する前記共通データとをアラートすること；

管理エンティティによって制御されるウェブサイトまたは他の入力デバイスで、住宅所有者から、残余口座ポジションを少なくとも１人の出資者に売却する、または、少なくとも１人の出資者から残余口座ポジションを購入するリクエストを受け取ること；および前記管理エンティティによって制御されるサーバの送信ユニットが、前記売却または購入リクエストを、前記管理エンティティによって制御される処理ユニットにより運用される契約エンジンの受信ユニットに、送信すること；

直接アレンジメントの場合、前記契約エンジンの受信ユニットが、前記住宅金融商品データブロックチェーンから、リクエストされた売却または購入を管理する必要な契約条項を、少なくとも前記売却または購入の前記条件を決定するために要求されるデータを含む他の関連データと共に、抽出すること；前記契約エンジンの処理ユニットが、前記リクエストされた売却または購入が、前記住宅融資アレンジメント契約の下で許可されているか否かを決定すること；前記リクエストされた売却または購入が、前記住宅融資アレンジメント契約の下で許可されている場合、前記取引の反対側の前記出資者による承諾が要求されているか否かを決定すること；前記契約エンジンの処理ユニットが、前記購入または売却の適用可能な条件を決定すること；前記売却または購入が許容される場合、前記契約エンジンの送信ユニットが、必要に応じて、前記計算された条件に基づいて、各当該出資者の少なくとも１つの受信デバイスにより、前記出資者に、前記条件と承諾を承諾するまたは拒否する前記必要性をアラートすることにより、出資者の承諾を求めること；応答を受け取った後、または応答の期限が経過した後、前記契約エンジンの処理ユニットが、前記計算された条件での前記売却または購入が、承認されているまたは拒否されているかを決定すること；前記契約エンジンの送信ユニットが、前記住宅所有者がアクセス可能なウェブサイトを修正して、前記住宅所有者に承認または拒否を通知すること；承認のために、前記計算された前記条件に基づいて受諾または拒否を確認するよう前記住宅所有者にリクエストすること；前記契約エンジンの送信ユニットが、オフラインになっている可能性がある前記住宅所有者に、携帯電話または他の受信デバイスにより、同意または拒否をアラートすること；承認のため、前記計算された条件に基づいて、前記住宅所有者に前記取引の同意または拒否を確認するようにリクエストすること；前記住宅所有者が前記取引を確認すると、前記契約エンジンの送信ユニットが、要求されるステップを前記関連当事者または当事者に通知するメッセージを送信すること；前記契約エンジンの受信ユニットが、当事者間の要求される支払いを含む、要求されるステップが、既に完了していることの確認を受け取ること；前記契約エンジンの処理ユニットが、少なくとも前記取引の前記確認、前記取引の前記条件、前記取引が有効になった前記日時、および前記当事者の前記新しい残余口座のポジションを含む取引データパッケージを、コンパイルすること；前記契約エンジンの送信ユニットが、前記契約エンジンの処理ユニットによるフォーマットの後、前記取引データを前記住宅金融商品データブロックチェーンに書き込むこと；前記契約エンジンの処理ユニットと送信ユニットが、少なくとも住宅所有者と出資者がアクセス可能なウェブサイトを修正して、前記取引データの前記関連部分を表示すること、そして前記契約エンジンの送信ユニットが、オフラインの可能性がある少なくとも住宅所有者と出資者に、携帯電話または他の受信デバイスにより、前記取引データの前記関連部分をアラートすること；

直接アレンジメントではないアレンジメントで、住宅データのブロックチェーンから、前記第三者データエンジンの受信ユニットが、リクエストされた売却または購入を管理する必要な契約条項を、少なくとも、前記提案された売却または購入に関して前記住宅所有者へのオファーを生成するのに十分なデータを含む他の関連データと共に、抽出するステップであって、各オファーには、前記提案された売却または購入に伴う前記住宅融資アレンジメントの前記条件の変更が含まれる、こと；前記契約エンジンの処理ユニットが、前記住宅所有者によって提案された前記売却または購入に関する少なくとも１つのオファーを計算すること；前記契約エンジンの処理ユニットが、前記リクエストされた売却または購入が、前記住宅融資アレンジメント契約の下で許可されているか否かを決定すること；前記リクエストされた売却または購入が、前記住宅融資アレンジメント契約の下で許可されている場合、前記取引の反対側の前記出資者による承諾が、要求されているか否かを決定すること；前記契約エンジンの処理ユニットが、前記購入または売却の前記適用可能な条件および各オファーの前記条件を決定すること；前記売却または購入が、許容される場合、前記送信ユニットが、各当該出資者の少なくとも１つの受信デバイスにより、前記出資者に、前記オファーおよび各オファーを承諾するまたはそれを拒否する前記必要性をアラートすることにより、前記計算された条件に基づいて、必要に応じて、各オファーに関する出資者の承諾を求めること；応答を受け取った後、または応答の前記期限が経過した後、前記契約エンジンの処理ユニットが、各オファーが承認されたまたは拒否されたかを決定すること；前記契約エンジンの送信ユニットが、前記住宅所有者がアクセス可能なウェブサイトを修正して、前記住宅所有者に各オファーの承認または拒否を知らせること；少なくとも１つのオファーの承認のため、住宅所有者に、売却または購入の条件と共に１つのオファーの受諾を検証するか、または全てを拒否するようにリクエストすること；前記契約エンジンの送信ユニットが、オフラインになっている可能性がある前記住宅所有者に、携帯電話または他の受信デバイスにより、各オファーの承認または拒否をアラートすること；少なくとも１つのオファーの承認のため、前記売却または購入の条件と共に１つのオファーの受諾を確認する、またはそれら全てを拒否するかを、前記住宅所有者にリクエストすること；前記契約エンジンの処理ユニットが、少なくとも、前記オファーの前記コンテンツ、前記売却または購入条件、および前記オファー時の前記管理データパラメータの前記値（前記オファー条件を管理する値）を含む、オファーデータアンサンブルを作成すること；前記契約エンジンの送信ユニットが、前記オファーデータアンサンブルを前記住宅金融商品データブロックチェーンに書き込むこと；前記住宅所有者が、前記売却または購入条件と共に、オファーを受諾すると、前記契約エンジンの受信ユニットが、前記住宅金融商品データブロックチェーンから前記オファーデータアンサンブルを抽出すること；前記契約エンジンの処理ユニットが、前記オファーアンサンブルデータを使用して、少なくとも、住宅所有者、出資者、および残余バランシングポジション保有者の間の調整を計算し、前記残余バランシングポジション保有者が、前記既存の住宅融資アレンジメントを完了し、そしてそれを、前記受諾されたオファーで指定された前記条件を具体化する新しい住宅融資アレンジメントにより、置き換えることを要求されること；前記契約エンジンの送信ユニットが、前記関連する当事者に、要求されるステップを通知するメッセージを送信すること；前記契約エンジンの受信ユニットが、当事者間の必要な支払いを含む、前記要求されるステップが、既に完了していることの検証を受け取ること；前記契約エンジンの処理ユニットが、少なくとも、前記既存の住宅融資アレンジメントを完了するために行われた前記調整、前記売却または購入の前記条件、前記当事者の前記開始残余口座のポジションを伴う前記新しい住宅融資アレンジメントの前記条件、および前記新しいアレンジメントが有効になった日時、を含む移行データパッケージをコンパイルすること；前記契約エンジンの送信ユニットが、前記移行データを前記住宅金融商品データブロックチェーンに書き込むこと；前記新しい住宅融資アレンジメントへのシフトを実行すること；前記契約エンジンの処理ユニットが、前記関連付けられている各当事者に適した移行データの別々の表示可能なバージョンを作成すること；前記契約エンジンの処理ユニットと送信ユニットが、前記関連する当事者がアクセス可能なウェブサイトを修正し、前記移行データを前記ウェブサイトの別々の部分に別々のバージョンで表示し、そして一般的にアクセス可能な領域に前記新しいアレンジメントを表示すること；そして前記契約エンジンの送信ユニットが、オフラインになっている可能性がある関連当事者のそれぞれに、その当事者に関連付けられている移行データと、新しい住宅融資アレンジメントを説明する共通データとをアラートすること、

を備える。

【図面の簡単な説明】

【0016】

【図1】例示的な実施形態に従って、住宅市場の状況を正確に反映して住宅融資取引を容易にしかつ統一されたユーザ体験を生み出す、最適化された動的データ構造を作成する、集中型および分散型コンピュータシステムを統合するマクロシステムアーキテクチャを示すブロック図である。

【図2】図１のバランシングエンジンを示すブロック図であり、このバランシングエンジンは、例示的な実施形態に従って、データ構造を管理し、住宅エクイティを残余口座に配分、そしてエクイティのリバランスを承認する。

【図3】図１のブロックチェーンシステムのブロック図であり、このブロックチェーンシステムは、例示的な実施形態に従って、ブロックチェーンデータベースとの間でデータを受信、処理、および送信する。

【図4】図１のアプリケーションレイヤーを示すブロック図であり、このアプリケーションレイヤーは、例示的な実施形態に従って、データを処理し、集中型データベースおよび分散型データベースにアクセスし、そして関与する当事者のためのユーザインターフェースをサポートするためのコンピュータキテクチャを提供する。

【図5】例示的な実施形態に従って、図４の処理サーバを使用して、エクイティリバランスリクエストを認可しかつ取引メッセージを発行するためのプロセスを示す流れ図である。

【図6】図１のデータエンジンの例示的な実施形態を示すブロック図であり、このデータエンジンは、例示的な実施形態に従って、システムが使用する１つ以上のパラメータ値を作成、更新、そして送信する。ここで、例示的な実施形態は、一連のアルゴリズムでデータ構造を変換して、集中型データベースおよび分散型データベース上の住宅エクイティの値と関連付けられているデータ構造とを計算する評価エンジンを備える。

【図7】例示的実施形態により、図６の処理サーバを使用してエクイティ評価リクエストを承認し、エクイティ評価を実行し、そして取引メッセージを発行するプロセスを示す流れ図である。

【図8】例示的な実施形態に従って、当事者間の契約のアレンジメントを管理、処理、および実行する図１の契約エンジンを示すブロック図である。

【図9】例示的な実施形態に従って、住宅所有者のリクエストを承認するプロセスを示す流れ図である。

【図10】例示的な実施形態に従って、暗号通過を売却しかつ住宅所有者のエクイティの売却に関連して取引ブロックチェインに書き込むためのプロセスを示す流れ図である。

【図11】例示的な実施形態に従って暗号通貨取引エンジンまたは暗号通貨ポートフォリオエンジンを示すブロック図である。

【図12】例示的な実施形態に従って、暗号通貨ポートフォリオブロックチェーンに書き込むためのプロセスを示す流れ図である。

【図13】例示的な実施形態に従って、図１のデータブロックチェーンシステムからデータアンサンブルを編成し、かつメッセージを送信するプロセスを示し流れ図である。

【図14】例示的な実施形態に従って、ブロックチェーンシステムに支払いデータを書き込みかつブロックチェーンシステムから更新データを抽出するプロセスを示す流れ図である。

【図15】例示的な実施形態に従って、ブロックチェーンシステムからの評価を要求しそして支払額をブロックチェーンに記録するためのプロセスを示す流れ図である。

【図16】例示的な実施形態に従って、支払いデータをブロックチェーンシステムに記録するため、または不適切な資金メッセージを配送する出資者のコンタクトを識別するためのブロックチェーンシステムを使用して契約条件を識別するためのプロセスを示す流れ図である。

【図17】例示的な実施形態に従って、ブロックチェーンによって取得されたデータを使用して受信されたデフォルト通知を処理し、そしてブロックチェーンシステムにおいて出資者の変化を決定および記録する流れ図である。

【図18】例示的な実施形態に従って、ブロックチェーンシステムから契約条項データを抽出し、支払いエンジンを起動させて支払いデータを生成しかつブロックチェーンシステムに書き込むためのプロセスを示す流れ図である。

【図19】例示的な実施形態に従って、初期化されたＥＢＰアレンジメントに関連してブロックチェーンシステムを更新するためのプロセスを示す流れ図である。

【図20】例示的な実施形態に従って、スケジュールされていない成果に関連して、バランシングエントリデータをブロックチェーンシステムに追加するプロセスを示す流れ図である。

【図21】例示的な実施形態に従って、ブロックチェーンシステムから契約データを抽出し、そして支払い変更リクエストに関連して、オファーデータアンサンブルをブロックチェーンシステムに書き込むプロセスを示す流れ図である。

【図22】例示的な実施形態に従って、要求される配分を計算して、銀行振込を実行させ、そして受諾された支払い提案に関連してブロックチェーンシステムを更新するプロセスを示す流れ図である。

【図23】例示的な実施形態に従う取引エンジンを示すブロック図である。

【図24】例示的な実施形態に従って、購入オファープロセス、および受け取られた購入オファーに関連して、ブロックチェーンシステムの更新を示す流れ図である。

【図25】いくつかの実施形態の特定の特徴を実装するために使用することができるコンピュータシステムのブロック図である。

【発明を実施するための形態】

【0017】

（動的住宅データ構造）
開示された様々な実施形態は、動的住宅金融商品の当事者間の関係のような、論理関係に影響を与える複数のデータストリームによって規定される条件のリアルータイム変動に適応するために複数のエンティティ間の論理関係を規定するデータ構造を動的に更新することに関する。より詳細には、本発明の実施形態は、ＤＯＯＲ金融商品の形のデータ構造に関する。ＤＯＯＲ(dynamic owner-occupied real estate)は「動的な所有者が占有する不動産」の略である。適切な基礎となる動的データ構造を作成する、つまり、適切なＤＯＯＲ金融商品を選択し、関連データを従来のデータベースと１つ以上の公的に検証可能なブロックチェーンとに格納し、ブロックチェーンベースの方法を使用して主要な取引コンポーネントを決済することにより、本発明の実施形態は、コンピュータが、ウェブページを動的に修正し、かつ住宅所有者とサービスプロバイダに、統合された透過的で低コストの経験を提供することができるグラフィカルユーザインターフェースをリアルータイムで作成することを可能にする。

【0018】

クラスとしてのＤＯＯＲ金融商品は、住宅所有者、抵当権者、およびエクイティ出資者に、所有者が占有する不動産に住みかつ出資するための新しい方法を提供する。本発明の実施形態は、当該不動産に関する権利および義務を規定する基準に影響を及ぼす、従って当該権利および義務をリアルータイムで動的に調整する、様々な要因を監視する特定のバランシングエンジンが中心である。このバランシングエンジンは、ＤＯＯＲ金融商品の１つの側面に過ぎない。他の側面には、ＤＯＯＲ金融商品を構成する動的データ構造をサポートする様々なデータエンジンが含まれるが、これらに限定されることはない。

【0019】

いくつかのＤＯＯＲ金融商品バランシングエンジンは、住宅所有者と住宅所有者に融資する出資者との間の商業的に価値のあるアレンジメントに直接変換される。このようないくつかの直接アレンジメントのバリアントは、以下の説明において理解しやすい実施形態を提供する。しかしながら、本発明はより一般的である。これは、住宅用不動産サービスと金融の分野でコンピュータ技術を現在特徴づけている分断化と連携の欠如をもたらす技術的問題を解決することができる特定セットのバランシングエンジンの使用を利用している。このような多くの場合、このバランシングエンジンで暗黙のうちに行われるアレンジメントは、住宅所有者および所有権に資金を提供する出資者が利用できるようになされた住宅アレンジメントではない。このバランシングエンジンは、バックグラウンドに存在し、住宅所有者とサービスプロバイダに、完全に異なるアレンジメントに関して統合された透過的で低コストの経験を提供するコンピュータ技術を作成する。

【0020】

本発明のより一般的なレベルを説明する前に、例として、および説明の目的で、ＤＯＯＲ金融商品が可能にするいくつかの直接アレンジメントおよび本発明がそれらのアレンジメントに対してどのように運用されるかを検討することは有用である。

【0021】

（住宅融資アレンジメントのＤＯＯＲ実装）
ＤＯＯＲ金融商品は、住宅所有者とエクイティ出資者の間の配分を可能にするデータ構造であり、そして非線形かつ動的であることが望ましい。ＤＯＯＲ金融商品の好ましい実施形態では、共有ルールは、様々な住宅の価値の範囲に渡る線形スケジュールよりもより一般的とし、そして動的とすることが出来る。つまり、このルール自体は、経済状況または住宅の価値の結果として変化することができるデータ構造である。このアプローチは、この共有ルールが、区分線形静的アプローチでは対応できない多くの問題に対処することを可能にする。これらの問題には、次のものが含まれるが、これらに限定されるものではない：（１）住宅を維持するための準最適な住宅所有者のインセンティブ；（２）賢明でない住宅所有者の金融戦略、例、資産の大部分を、実質的に、生涯の成果に相関する単一のレバレッジ資産に投入し、その結果、収入の減少または失業の発生と同時に住宅価値と総資産を急激に減少させる傾向となる；（３）出資者が、所有者が占有する住宅の収益を純粋で透明な形で受け取ることができない；（４）エクイティ金融商品の高額な借り換え費用無しに住宅に対する借入金を増やすことができない；（５）出資プールへの新しい出資を作成または受諾するために、金融商品を評価することが、容易ではない；（６）住宅価格が下落したときに、エクイティ金融商品を戦略的に借り換えるインセンティブの存在。これらの問題のいくつかの根底には、住宅融資とサービス機能との間の連携の欠如および分断化がある。これは、不動産の金融とサービスにおける現在のコンピュータ技術を特徴付けている。

【0022】

静的アプローチでは、経済状況が時間の経過と共に変化する際に、このアレンジメントが、住宅所有者または出資者のどちらかにより有利になってしまうことは、重要である。このアレンジメントが実行可能であるためには、住宅所有者の借り換えの機会に制限がある、または条件が出資者に有利である、の何れかである必要がある。ＤＯＯＲ金融商品の動的性質は、特定の実施形態の場合、住宅所有者に対してはより優れた取引をもたらし、出資者に対しては少なくとも市場リターン率を維持する方法でこれらの制限を回避し、そして前払いによる損失から出資者を解放することを可能にする。ＤＯＯＲアレンジメントは、通常、付随する住宅ローンにも拡大され、いくつかの変形例では、抵当権者／出資者に対する前払いのリスクが排除され、かつ住宅ローンの金利が下落したときに、住宅ローンを、自動的に、ほとんど費用をかけずに、かつオンラインで借り換えることが可能になる。

【0023】

本発明の実施形態は、住宅所有者と出資者との間の経済的バランスを継続して動的に維持するために、機械学習を適用して動的ＤＯＯＲ金融商品を作成するための非線形アルゴリズムのクラスの使用に関する。ＤＯＯＲバランシングエンジンは、アレンジメントをジョイントベンチャとして扱う際には、ベンチャに対する各当事者の純拠出を正確に捉える、エクイティシェアのまたは他の口座の変化を計算する分析マシンとして機能する。経済バランスが進行中である結果として、このアレンジメントは、それが、一方の当事者を他の当事者よりも有利にする状況をもたらさないという意味で中立であり、かつ各当事者が、このアレンジメントから受け取ったものおよびこのアレンジメントに出資したものを調整した後、市場レートのリターンを獲得する結果となる。何れの当事者に対しても、補助金または有利な市場のリターン率を追加することが可能であるが、そのような機能は、明示的で便利である（例、出資者が、補助金付きの住宅を市民または従業員に提供したい政府または民間企業である場合）。

【0024】

経済的バランスを目的としたＤＯＯＲアレンジメントでは、バランスを行うために１つ以上の残余口座が要求される。これらの残余口座は、エクイティシェア、住宅を担保とする負債または負債のような利息、当事者間の変動する支払い、現金または出資口座、暗号通貨の残高、または他のビークルで構成することができ、そして如何なる１つのアレンジメントも複数の残余口座を使用することができる。

【0025】

（議論）
本発明の実施形態は、コンピュータが、ウェブページを修正し、かつ住宅所有者およびサービスプロバイダに、住宅融資アレンジメントの統合された透明な低コスト実装を提供することができるグラフィカルユーザインターフェースを作成することを可能にする、適切な基礎となる動的データ構造の形でコンピュータ技術を作成する。

【0026】

以下の議論は、最初に、ＤＯＯＲ金融商品がこのアレンジメントでどのように機能するかを定性的に記述すると共に、特定の住宅アレンジメントを説明し、次いで、本発明の実装を説明するいくつかの例を含む。住宅融資アレンジメントの記述は、重要な用語の規定を可能にする。

【0027】

最初の例として記述される２つの住宅融資アレンジメントであるＭＭ－０およびＭＭ－１は、適切なＤＯＯＲ金融商品バランシングエンジンを使用することにより、直接アレンジメントとして実装させることが出来る。以下の例には、直接アレンジメントの実装ではないインスタンスが含まれる。全体としての住宅融資アレンジメントの例は、本明細書に開示される本発明の追加の実施形態を説明するための重要な背景を提供する。実施形態は、ＡＮＺＩＥ－ＤＯＯＲ（ＷＯ ２０１０／０８５４８１ Ａ１を参照）を含む、ＤＯＯＲ金融商品のバリアントの一般的に主張されるクラスから引き出される。不動産アレンジメントが、バランシングエンジンに固有の直接アレンジメントとは異なる場合であっても、このクラス内のいくつかのＤＯＯＲ金融商品のバリアントは、コンピュータが、ウェブページを修正することと、住宅所有者とサービスプロバイダとに、統合された透過的で低コストの経験を提供することができるグラフィカルユーザインターフェースを作成することとを、可能にするバランシングエンジンを、実装することに留意することが重要である。

【0028】

本発明の実施形態に関する以下の議論は、要求される技術環境のいくつかの態様の記述と、関連付けられている住宅融資アレンジメントおよび取引に関連するいくつかの当事者のリストとを提供するセクションから始まる。すぐに続くセクションは、以下を含む：
（ｉ）ＭＭ－０住宅融資アレンジメント、２人の当事者のみによるアレンジメント、住宅所有者と住宅融資を提供する出資者の記述；
（ｉｉ）ＭＭ-０の一実施形態が、本発明によってどのように実装されるかについての説明であり、これは、本発明を備えるコンピュータ技術が、直接アレンジメントに対し、現在のコンピュータ技術に固有の分断化および連携の欠如の問題をどのように解決するかを示す；
（ｉｉｉ）１つの特定の残余口座、獲得エクイティを使用し、そして関連付けられているバランシングエンジンを強調して、データ構造（ＤＯＯＲ金融商品）の主張されているクラスおよびその背後にある理論の記述；
（ｉｖ）獲得エクイティ以外の残余口座；複数の住宅所有者、出資者、または抵当権者；住宅所有者以外の当事者に流れる残余口座の下での発生；中立なＤＯＯＲ金融商品間でシームレスにシフトする能力、を含むアプリケーションを記述することによる、開示されたクラスの範囲の表示；
（ｖ）住宅所有者と住宅融資を提供する出資者に加えて、複数の独立したサービスプロバイダが関与しているので、ＭＭ－０とは異なるアレンジメントである、ＭＭ－１住宅融資アレンジメントの記述；
（ｖｉ）ＭＭ－１の実施形態が本発明によってどのように実装されるかについての説明で、これは、本発明を備えるコンピュータ技術が、このより複雑な直接アレンジメントに対して、現在のコンピュータ技術に固有の分断化および連携の欠如の問題を、どのように解決するかを示す；
（ｖｉｉ）直接アレンジメントとして実装することが出来ない、スケジュールされている獲得エクイティ住宅融資アレンジメントの記述；
（ｖｉｉｉ）スケジュールされた獲得エクイティ融資アレンジメントの一実施形態が、本発明によってどのように実装されるかについての説明で、これは、本発明を備えるコンピュータ技術が、直接アレンジメントでないアレンジメントに対して、現在のコンピュータ技術における分断化および連携の欠如の問題を、どのようにして解決するかを示す。

【0029】

これらのセクションの後には、本発明の追加の実施形態および態様を説明する他のセクションが続く。

【0030】

（様々な当事者および技術環境の側面）
複数の当事者が、購入時、売却時、および特定の住宅と住宅所有者の所有期間中に、関与する。この所有期間中、通常、少なくとも１人の住宅所有者と１人の融資当事者（「出資者」）が存在する。融資当事者が抵当権者の場合、抵当権保証人、抵当権保険会社、抵当権サービサ、および抵当権に関係する他の当事者が、存在し得る。保守サービスを提供する当事者との住宅保守契約が、存在する可能性もある。保守サービサまたは不動産鑑定者は、現在の状態に基づいて住宅の価値の査定を周期的に提供することができる。所有権アレンジメントの運用およびこれに関連付けられているコンピュータ技術を監督する管理エンティティも存在する。

【0031】

いくつかの実施形態では、出資者は、ファンドに持分を有している「ポートフォリオファンド出資者」のために、住宅のエクイティまたは負債利息のポートフォリオを保有するポートフォリオファンドとなることができる。追加の実施形態では、このポートフォリオは、取引可能な暗号通貨で実行させることも出来る（この場合、出資者が、「暗号通貨ポートフォリオファンド」である）。暗号通貨が関係するか否かにかかわらず、ポートフォリオファンドは、ポートフォリオファンドが保有するポートフォリオに随時追加のファンドを出資するポートフォリオファンド出資者から出資を集める、またはポートフォリオからファンドを引き出したりする（この結果、ポートフォリオは増額されたり減額されたりする）出資ファンドとして運用される。

【0032】

住宅所有者および出資者に加えて、様々な第三者が、存在し得る。「第三者金融エンティティ」は、出資者により提供される住宅融資を補完する「第三者住宅融資」を提供することができる。さらに、場合によっては、第三者金融エンティティとは異なる可能性があるエンティティは、出資者によって提供される融資、第三者金融エンティティによって提供される融資、またはその両方の何れかについてのサービスを提供する、少なくとも１つの「第三者サービスプロバイダ」である。例えば、もし、第三者の住宅融資が抵当権である場合、第三者の融資エンティティは抵当権者であり、そしてこの抵当権者とは別に、２つの第三者サービスプロバイダである、抵当権サービサおよび抵当権保険会社が存在し得る。

【0033】

本発明は、深いコンピューティングおよび通信環境を必要とし、かつそれを可能にする。各金融商品は、残余口座の価値、およびそのような口座とそれらに関連付けられている住宅持分における当事者間の様々なシェアが、継続的に、更新される。この結果、本発明の中心は、当事者のリアルータイムの決定と対話する、変動する経済変数に基づいて、価値とシェアを常に更新し、そして対応するユーザ体験を動的に生成する、動的データ構造である。抵当権の借り換え、支払い金額の変更、または該当するＤＯＯＲバリアント自体の変更などの様々なイベントには、関連する様々な当事者によるアクションまたは承諾が要求される。このようなイベントには、基礎となる資産の売買が含まれる。これらのイベントには、コンピューティングデバイスまたはタスク専用の他のデバイスの機能を有効化または改善するために、通信デバイスとソフトウェアの追加レイヤーが要求される。

【0034】

本発明を実施するには他の方法もあるが、ここでは、ブロックチェーン方法に依存し、かつ特定の購入パリティＤＯＯＲバリアント（後のセクションで規定されかつ記述される）の使用が要求される実装を、検討・説明する。ブロックチェーンは、データを不変としかつ検証可能にする方法を提供するので、本発明で具体化される技術的解決法を、基礎となる住宅アレンジメントに関係する様々な当事者が信頼することができるものにするための、重要なものとすることができる。

【0035】

ブロックチェーン元帳は、不変かつトランスペアレントな方法でデータを格納する。我々のイノベーションに利用可能なブロックチェーンを実装および使用するには、少なくとも次のような方法を含む多くの可能な方法がある：（１）ユーザとブロックチェーンの間のアプリケーションレイヤーを提供する第三者の方法を使用して、データをブロックチェーンに固定する集中型システム;（２）データを編成しそしてスマート契約の状態をパブリックブロックチェーンに格納することにより取引を容易にするスマート契約の使用；そして（３）カスタムのプライベートブロックチェーンの開発。以下の実施形態では、「ブロックチェーンシステム」は、ブロックチェーンとその実装方法の両方を意味する。

【0036】

以下の実施形態では、１つまたは複数のブロックチェーンシステムが、以下の目的で使用される：
（１）住宅金融商品のデータと履歴。 １つ以上の「住宅金融商品データブロックチェーン」には、各住宅金融商品のデータと履歴が、関連する経済変数の現在値と共に、不変形態で含まれている。関連付けられているブロックチェーンシステムは、様々なコンピューティングデバイスまたは通信デバイスを使用して、現在のＤＯＯＲ金融商品のシェア、価値、または他の要素に関する、出資者、住宅所有者、サービスエンティティ、他のブロックチェーンシステム、または他の当事者によるクエリに対し、トランスペアレントな基盤を形成する。
（２）取引データ。 １つ以上の「取引ブロックチェーンシステム」は、少なくとも、ＤＯＯＲ金融商品の基礎となる抵当権の借り換え、支払い率の変更、中立ＤＯＯＲ金融商品間のシフト、または関連付けられているＤＯＯＲ金融商品の付随する作成または廃止による、基礎となる住宅の売買を含む、特定の取引の一部または全てを、完了するために使用させることができるかもしれない。
（３）暗号通貨の運用。 １つまたは複数の「暗号通貨ブロックチェーン」は、そのような利益のポートフォリオを具体化する様々な暗号通貨が、保有する住宅の利益に関する経時的なデータを、含むかもしれない。購入パリティバリアントの使用は、異なる残余口座を使用しかつ他の点で異なる多種多様なＤＯＯＲ金融商品に渡って、出資者が、対象となる住宅について経済的リターンを正確に継続的に得ることができる資産を、結果的にもたらす。これらの金融商品は、ブロックチェーンシステムにより運用される暗号通貨の基礎として機能させることができる純粋な住宅リターンのポートフォリオを作成して、プールさせることが出来る。国の、地域の、または世界の住宅のリターンは、基礎となるプールによりシミュレートさせて、その結果、特定のタイプの住宅のリターンに裏打ちされたハード通貨とすることが出来る。ドルなどのソフト法定通貨は、このハード通貨に対して継続的に変動するであろう。

【0037】

ＤＯＯＲ金融商品を構成する動的データ構造を実装するためには、本発明の一部である様々なデバイス、ソフトウェア、およびブロックチェーンシステムが、基盤となるデバイスの技術的動作を有効化または強化する、巨大な協調通信およびコンピューティング環境が要求される。この側面をより具体的にするために、具体例を考えてみる。

【0038】

一実施形態が、多種多様なＤＯＯＲ金融商品の目的（１）および（２）に関し、それらのいくつかは、購入パリティ形式であり、そして他のものは、暗号通貨プールに含める（すなわち、目的（３））に適切であると仮定する。住宅所有者は、ＤＯＯＲ購入パリティの実施形態によりそれの資金を調達して、住宅を購入し、ＤＯＯＲ購入パリティの実施形態は、抵当権の支払い、追加の支払い、および住宅所有者に有利な獲得エクイティの発生に関与する。その後、住宅所有者は、追加の支払いが行われるレートを下げたいと考える。

【0039】

先ず、購入取引を検討する。購入を完了するには、潜在的な出資者および場合によっては潜在的な抵当権者にも照会をかけ、次いで、様々なアクションを実行し、そして複数の当事者からの様々な承諾を確保する必要がある。本発明で具体化される動的金融商品については、金融商品の条件は、関連する市場変数と共にリアルータイムで変化する。従って、最初の金融商品に対する建値の条件が、現在の市場状況との整合性から離れないようにするために、時間は本質的なものである。関連する当事者からの通知と安全な承諾を提供するためには、携帯電話のアプリケーションの様な、様々な通信デバイスとソフトウェアが要求される。さもないと、ＤＯＯＲシステムの中心となる基本的なコンピューティングおよび通信デバイスが効率的に機能することが出来ない。

【0040】

次に、住宅所有者が後で支払うレートについての減額を求める住宅所有者のリクエストを考察する。住宅購入と同様に、レートの変更には、相互の複雑な一連のアクションと承諾が要求される。住宅所有者が、レートの変更のリクエストを開始しなければならない。支払いレートは、獲得エクイティの累積に影響を与えるので、通常、金融商品の条件に基づく承諾が必要である。そして、住宅所有者が住宅を維持するための適切な強力なインセンティブを確保するために、金融商品には一定の最低レベルの獲得エクイティまたは獲得エクイティ未払金の発生を要求することができる。加えて、支払いレートの変更の承諾は、商品の出資者または出資者によって要求させることもできる。繰り返しになるが、変更される支払いレートは、市場の状況に応じた方法で、獲得エクイティの発生および住宅所有者のキャッシュフローに動的な影響を与えるので、時間は重要である。関連する当事者からの通知と安全な承諾を提供するため、および変更が金融商品の条件で許容されるか否かを決定するために、様々な通信デバイスおよび携帯電話のアプリケーションの様なソフトウェアが、要求される。

【0041】

最後に、暗号通貨は、目的（１）および（２）を実装する構造の上にある。もし、暗号通貨が、全国の住宅のバランスの取れたポートフォリオのようなインデックスのアイデアに基づいている場合、継続的な調整と、住宅所有者、出資者、および他のブロックチェーンとの対話とが、要求される。例えば、米国中の代表的な住宅のセットをカバーするＤＯＯＲ金融商品のプールによりカバーされている暗号通貨について考えてみよう。ＤＯＯＲ金融商品のプールは、実際には、米国の住宅インデックスを形成または複製する、基礎になる住宅のプールに対する住宅リターンのポートフォリオを作成する。もし、ＤＯＯＲ金融商品が、購入パリティＭＭ－０バリアントである場合、暗号通貨の基礎となるエクイティポジションは継続的に縮小し、そして相殺されるキャッシュフローが暗号通貨に発生する。加えて、基礎となる特定の住宅が売却され、基礎となるＤＯＯＲ金融商品のポジションが現金に変換される。暗号通貨は、米国全体でバランスの取れた住宅リターンの複製を目的としているため、暗号通貨をほぼ全て住宅に出資するのみならず、バランスの取れた状態で出資する、累積現金を有する、新しいＤＯＯＲ金融商品への出資を探す必要がある。例えば、いつでも、より多くの北東部の都市にある住宅への出資が、バランスを取り戻すために、要求されることがあり得る。バランスには、ＤＯＯＲ出資シェアの売却と購入が要求されるかもしれない。暗号通貨マネージャーまたはそれらを表す人工知能エンティティは、適切な購入候補を求めて１つ以上の他の住宅金融商品データブロックチェーンシステムにクエリを実行し、そして関連付けられている出資者にオファーを発行するかもしれない。それらは、また、ブロックチェーンシステム等により売却用の資産を提供するかもしれない。クエリは、即座に興味を示しかつ大量である購入者または売却者の存在を知らせるために、不動産業者または他の関連する当事者にまで拡張されるかもしれない。暗号通貨はリアルータイムで使用されるので、時間は重要であり、そして様々な通信デバイスおよび携帯電話のアプリケーションの様なソフトウェアが、購入または売却のオファーを行い、必要な取引を完了し、関連付けられている組織からの承諾を確保するために要求される。

【0042】

この説明的な例、および以下に提示されるより技術的な例は、本発明の技術的側面に関して網羅的というよりはむしろ例示的なものである。

【0043】

（ＭＭ－０住宅融資アレンジメント）
ＤＯＯＲ手段を使用して実装されている、単一の所有者が占有する資産の住宅融資アレンジメントは、複数の出資者、複数の住宅所有者、および資産を担保とする同じまたは異なる負債利益を保有する複数の抵当権者を含むことができる。１人以上の出資者または住宅所有者が、抵当権者である場合もある。さらに、利息の支払いを伴わないが、代わりに、バランス計算に入る同等のクレジットを伴う負債のような金融商品もある。

【0044】

まず、住宅融資アレンジメントの非常に単純なクラスであるＭＭ－０から始める：
（ｉ）抵当権は１つしかなくかつ負債のような金融商品は存在せず；
（ｉｉ）抵当権がある場合、出資者は、抵当権者も兼ねており、出資者としてエクイティを提供することによって住宅融資の全てを提供しかつこの住宅を担保として金を貸し;
（ｉｉｉ）もし、売却時のファンドが、要求される支払いを住宅所有者に行った後に、抵当権の支払期日までに元本を支払うには十分でない場合でも、この抵当権は、住宅所有者に対してノンリコースであり、住宅所有者に影響を与えない。従って、不足がある場合、抵当権者としての出資者が、単純に損失を吸収する；そして
（ｉｖ）このＤＯＯＲ金融商品バリアントは、ＤＯＯＲの「ＭＭ－０バリアント」であるＭＭ－０を直接実装するように適合化されている。

【0045】

ＭＭ－０住宅融資は、以下の運用上の特徴により特徴付けられている。
（１）ＤＯＯＲ 出資者が保有する従来のエクイティポジション。ＤＯＯＲ金融商品の出資者は、抵当権によって融資させることもできる住宅の従来のエクイティポジションに資金を供給する。もし、抵当権がある場合、ＤＯＯＲの出資者が抵当権の融資を提供する。もし、抵当権がない場合、ＤＯＯＲの出資者は全ての資金をエクイティとして提供する。
（２）住宅所有者の義務。住宅所有者は、抵当権の支払い（元金と利息の両方）、固定資産税、住宅の維持、およびおそらく、少なくとも部分的にＤＯＯＲ出資者の利益となるように累積されるスケジュールされた支払いを含む他の義務に対して、責任がある。抵当権がない場合、通常、スケジュールされた支払いがあるが、スケジュールされた支払いが抵当権の支払いを補っても良い。
（３）住宅所有者が保有する獲得エクイティ。住宅所有者は、ＤＯＯＲ出資者が、住宅の売却またはＤＯＯＲ金融商品の他の解約時に住宅所有者に支払う義務がある住宅価値の百分率である、獲得エクイティを得る。獲得エクイティは、動的アルゴリズム（つまり、経済バランスを生み出すエンジンのコア）によって指定される、ベンチャに対する住宅所有者の純拠出に基づいて累積される。この純拠出の主なプラス要素は、ローンの支払い、固定資産税の支払い、スケジュールされている支払い（ある場合）、および住宅の維持である。これの主なマイナス要素は、この住宅に居住することの帰属賃貸価値である。もし、住宅保有者による前渡金がある場合、これは、住宅価値に比例して直接獲得エクイティを増大させる。獲得エクイティは、この住宅のレバレッジされていないエクイティ持分、つまり、ある時点での全住宅価値の百分率である。獲得エクイティは、出資者が保有する負債およびエクイティ持分よりも優先して売却される。
（４）堅調な維持インセンティブ。 契約条件は、住宅を少なくとも購入時と同じ状態に維持できなかった場合は、完了時に住宅所有者に支払われるであろう獲得エクイティをドル対ドルで削減することを義務付ける。獲得エクイティのポジションは、住宅のレバレッジされていないエクイティを備えているので、住宅の価値が現在の抵当権負債より少ない状況でも、住宅所有者の維持インセンティブは引き続き堅調である。
（５）経済バランスを実施する周期的な調整。 ＤＯＯＲバランシングエンジンは、残余口座を継続的に調整して、純拠出をしている当事者を補償する分析エンジンである。ＭＭ－０の場合、残余口座は、住宅所有者の獲得エクイティであり、かつバランシング機構は、以下に記述する購入パリティ累積アルゴリズムに基づいている。バランシングエンジンは、各期間中の住宅所有者の純拠出を、獲得エクイティの適切な増加（つまり、現在の期間について見たときに、両当事者の期待を正確に補償する増加）に変換する。

【0046】

ＭＭ－０を含むＤＯＯＲ金融商品の条件は、市場の状況によって異なる。完全な動的金融商品には、金利、基礎となる住宅の価値、住宅の賃貸レート、住宅の減価償却率、固定資産税率、および他の変数のような、関連する全てのパラメータの現在値が組み込まれている。金融商品を完全に動的にすると、それらに関連付けられている特定のオプションが除去される。例えば、新しい金融商品の条件は、古いものと同じであるので、現在の市場価値を反映させて、完全に動的なＤＯＯＲ金融商品を借り換えることには価値がない。借り換えのオプションは、価値がない。これに対し、このオプションは、従来の抵当権契約の下では価値があり、そして抵当権レートが下がって、次のような結果；借入の初期価格がより高い場合、住宅所有者に対しいつ権利を行使するかというジレンマがあり、そして抵当権の評価は、それが前払いの振る舞いに依存するので、より困難となる、結果が生じたとき、抵当権者は、抵当権を前払いしそして借り換えをするインセンティブを有する。

【0047】

幾つかのＤＯＯＲ実装は、近似を使用する：このＤＯＯＲ契約は、他のものに対する近似を使用して、関連するパラメータのサブセットに関する正確なリアルータイムの市場価値を調整するのみである。この結果は、オプション価値のゼロ化を概算するのみの金融商品であるが、獲得エクイティのような数量についてより予測可能な結果をもたらすものである。他のＤＯＯＲ実装では、完全に動的なバージョンの金融商品にできる限り近づくことが、目標である。

【0048】

ＭＭ－０住宅融資アレンジメントは、抵当権の有無にかかわらず運用できることに留意すべきである。抵当権がない場合、住宅所有者から十分な純拠出を生み出して、重要な獲得エクイティを生成するために、通常、住宅所有者からベンチャへの、または出資者への直接の支払いが必要である。これらのスケジュールされた支払いは、住宅価値の関数とすることができ、獲得エクイティの目標レベルを達成および維持するために変動させることもでき、またはアレンジメントの性質に応じて他の方法で変更させることもできる。

【0049】

ＤＯＯＲ金融商品の動的な性質は、他の多くの機能の追加を可能とする。 ＭＭ－０または他のバリアントへの特に魅力的な追加には、次のようなものがある：
（Ａ）財政的に困窮した住宅所有者のためのオプションとしてまたは救済規定の根拠としての支払いレベルの削減。住宅所有者が財政難に陥った場合、ＤＯＯＲアレンジメントの規定は、住宅所有者に、スケジュールされた支払いまたは抵当権の支払いを一定の期間または総額まで猶予させることができる。支払額の減少は、獲得エクイティのより遅い発生または獲得エクイティの実際の減少により完全に相殺されるため、出資者に影響することはない。第三者の抵当権に関わるバリアントの場合（つまり、出資者が抵当権者でない場合）、出資者は、介入しそして住宅所有者が支払わない抵当権を支払う。繰り返しになるが、出資者は、売却時における出資者の獲得エクイティ義務の削減によって正確に補償される。支払いレベルを下げる可能性は、一般的であり、困窮状況に限定されず、そして住宅所有者のオプションとして含ませることが出来る。
（Ｂ）総資産有利子負債比率（「ＬＴＶ: Limit Loan to Value」）を制限するための抵当権の部分的なペイオフ、またはスケジュールされた支払いの同等の削減。ＤＯＯＲ契約の規定は、ＬＴＶ比率を制限するために、出資者が、住宅所有者の抵当権の義務を部分的に支払うまたは削減するよう要求することができる。獲得エクイティよりも優先度が高い第三者の抵当権がある場合、出資者の通常のエクイティが売却時の獲得エクイティを超えることを保証するように、ＬＴＶレベルを設定することができる。ＭＭ－０でのペイオフを構成する望ましい方法は、ローンの一部を削除して支払いを減らし、条件をそのままにして、実質的に元のローンの縮小バージョンを作成することである。ＬＴＶに上限がない場合、獲得エクイティは、価値の低い状況で非常に速く累積され、残りの利用可能な住宅エクイティを完全に飲み込む可能性がある。ローンの支払いを減らすと、正確に補償される態様で獲得エクイティが発生するレートが下がるので、ＤＯＯＲ機構は、ＤＯＯＲ出資者に、あらゆる支払いに対する正確な経済的補償を提供する。抵当権はないが、ＭＭ－０に基づく支払いがスケジュールされている場合、支払いは、獲得エクイティの発生において相殺を減少させた低価値の状況で、同等の方法で減らすことが出来る。
（Ｃ）住宅所有者の追加の支払い。 ＤＯＯＲアレンジメントは、住宅所有者が、出資者の利益のために、追加のオプションまたは周期的にスケジュールされた支払いを行うことを可能にする。これらの支払いは、それらをなす住宅所有者を正確に補償して、獲得エクイティを増大させる。
（Ｄ）目標となる獲得エクイティ。ＤＯＯＲアレンジメントは、住宅所有者の将来の純拠出がゼロとなるようその後の支払いを調整し、そしてこれによって追加の累積を未然に防いで、目標レベルまで獲得エクイティを累積することを含むことができる。長期的に目標を達成するために行われる継続的な支払いの調整により、または調整をすぐに実装するための何れかの方向の一括払いにより、住宅所有者が、一定の範囲内で獲得エクイティの目標額を上下に移動させることを、許可することができる。

【0050】

ＤＯＯＲバランシングエンジンが、ジョイントベンチャと見なされる、アレンジメントへの彼等らの拠出の如何なる変更に対しても、当事者を完全に補償する分析機構であるので、これらの機能および他の多くの機能は、簡単に追加される。可能な機能の多くは、アレンジメントの当事者に通知され、そしてリアルータイムで連動および相互に依存する決定を行うことを要求する。

【0051】

次のセクションは、コンピュータが、ＭＭ－０の代表的な実施形態を実装し、かつウェブページを修正し、そして住宅所有者およびサービスプロバイダに、統合されていて、低コストの経験（現在のテクノロジでは欠けているもの）を提供するグラフィカルユーザインターフェースを作成することを可能にするコンピュータ技術を、本発明が、どのようにして作成するかを示す。

【0052】

（ＭＭ－０住宅融資アレンジメントの実施形態の実装）
図１は、住宅市場の状況を正確に反映して、住宅融資取引を容易にしかつ統一されたユーザ体験を生み出す、最適化された動的データ構造を作成するために、集中型および分散型コンピュータシステムを統合するマクロシステムアーキテクチャを備えるシステム１００を示す。

【0053】

システム１００では、取引は、住宅所有者１０２のコンピューティングデバイスと出資者１０４との間で、発生させることができ、この取引は、住宅金融商品に組み込まれていて、そして管理エンティティ１０６および関連付けられている１つまたは複数のコンピュータインターフェースによって処理が促進される。この管理エンティティは、１つまたは複数のバランシングエンジン１０８、データエンジン１１０、および契約エンジン１１２を含む、いくつかのコンピュータシステムを管理することができる。多くの第三者１１４および関連付けられているコンピュータインターフェースも取引に関与することができる。このシステムは、データを受信、処理、および送信し、そして特定の取引に関与する当事者のユーザインターフェースを管理するために必要なコンピュータキテクチャを提供するアプリケーションレイヤー１１６を含むこともできる。このアプリケーションレイヤーは、また、１つ以上の取引エンジン１１８および／または１つ以上のブロックチェインシステム１２０と対話することができる。

【0054】

システム１００がどのように運用されるかを説明するために、ＭＭ－０住宅アレンジメントの実施形態の実装を検討する。我々は、所有期間に焦点を当て、そして住宅所有者１０２、単一の出資者１０４、および１００％のエクイティ融資という単純なケース（つまり、抵当権が無いケース）から始める。本発明の中核にあるのは、処理エンティティ２０６と、少なくとも１つの受信ユニット２０２と、管理エンティティによって処理サーバ上で運用される少なくとも１つの送信ユニット２０４とで運用されるバランシングエンジン１０８である。

【0055】

図２は、システム１００のバランシングエンジン１０８の実施形態を示す。バランシングエンジン１０２は、データベース２０８、１つ以上のネットワークによりデータを受信するように構成される受信ユニット２０２、本明細書に記述のバランシングエンジン１０８の機能を実行する処理ユニット２０６、および１つまたは複数のネットワークによりデータを送信するように構成されている送信ユニット２０４を含むことができる。

【0056】

バランシングエンジン１０８は、住宅所有者１０２および出資者１０４の間の住宅アレンジメントをジョイントベンチャとして考え、彼等の間の継続的な拠出を経時的に評価する。一実施形態では、出資者１０４は、最初、住宅全体にエクイティ融資で（すなわち、抵当権無しで）融資し、住宅所有者１０２は出資者１０４に支払いを行い、住宅所有者１０２は固定資産税を支払い、住宅所有者は住宅を維持し、そして住宅所有者は住宅に居住する。この実施形態では、住宅所有者１０２の純拠出は、（ｉ）出資者１０４への支払い、（ｉｉ）固定資産税の支払い、（ｉｉｉ）維持費用、および（ｉｖ）保険のような他の義務から、（ｖｉｉ）住宅に居住する価値である賃貸料（「暗黙の賃貸料」）として請求されるものを控除したものとなる。バランシング機構は、住宅所有者１０２と出資者１０４の利益を照合するために、集中型２０８または分散型データベース１２０に格納されている残余口座を必要とする。この実施形態では、残余口座は、住宅のレバレッジされていない利益から構成されていて、これは、出資者１０４が、住宅の売却時または融資アレンジメントの完了時に住宅所有者１０２に支払わなければならないもので、そしてこの支払いは、住宅所有者１０２の純拠出がプラスになるように設定される。レバレッジされていないエクイティは、住宅所有者の１０２の純拠出に基づいて発生するので、これを「獲得エクイティ」と呼ぶ。

【0057】

システム１００では、バランシングエンジン１０８に入力されるデータは、住宅金融商品データブロックチェーンシステム１２０に存在する。図３は、システム１００のデータブロックチェーンシステム１２０の実施形態を示す。このデータは、少なくとも住宅所有者１０２の出資者１０４への支払いを含む、全ての拠出要素の時系列を含む。住宅金融商品データブロックチェーンシステム１２０は、１つ以上のネットワークによりデータを受信するように構成されている受信ユニット３０２およびデータを格納するためのデータベース３０８を有する。ブロックチェーンシステム１２０は、また、アクセスプロトコールを備える処理ユニット３０６を含み、そして暗号化、状態チャネル並びに公開鍵及び秘密鍵のような当業者によく知られている方法を使用して、保護されかつ匿名化される。このアクセスプロトコールは、ブロックチェーンシステム１２０上のデータへのアクセスの様々なレベルと、ブロックチェーンシステム１２０に新しいデータを書き込むための許可のレベルとを、規定する。ブロックチェーンシステム１２０へのアクセスを求める人またはエンティティは、アクセスプロトコール、データへのアクセスレベル、およびその人またはエンティティに付与されているブロックチェーンへの書き込み機能の範囲を決定するアクセス承認データを提出する。住宅金融商品データブロックチェーンシステム１２０は、１つ以上のネットワークによりデータを送信するように構成されている送信ユニット３０４を有する。

【0058】

図４は、１つまたは複数のネットワークによりデータを受信するように設計されている受信ユニット４０２と、１つまたは複数のネットワークによりデータをブロードキャストする送信ユニット４０４と、関連する当事者のためのユーザインターフェースをサポートするコンピュータキテクチャを有する処理ユニット４０６と、データを格納するためのデータベース４０８とを備える、システム１００のアプリケーションレイヤー１１６の実施形態を示す。管理エンティティのコンピュータシステム１０６は、アプリケーションレイヤー１１６を介してブロックチェーンシステム１２０にデータを送信するバランシングエンジン１０８を制御する。

【0059】

一実施形態は、図５を参照して理解することができる。図５には、例示的な実施形態に従って、図４の処理サーバを使用して、エクイティのリバランスリクエストを実行し、かつ取引メッセージを発行するプロセスを示す流れ図（５００）が示されている。管理エンティティまたはそれを表す人工知能エンティティは、周期的に、バランシングエンジンの受信ユニットにメッセージを送信して、住宅金融商品データブロックチェーンへのバランシングエントリを開始する（５０２）。バランシングエンジンは、送信ユニットにより、抵当権データブロックチェーンシステムのクエリをアクセス承認データと共に送信し、拠出および他の要素に関する関連データを抽出する。他の要素には、それ自体は、住宅金融商品データブロックチェーン（５０４）にエンコードされている、住宅融資アレンジメントをカバーする契約の下で獲得エクイティを計算するための管理アルゴリズムが含まれる。住宅金融商品データブロックチェーンシステムは、そのアクセスプロトコールを実装して、バランシングエンジンが、リクエストされたデータにアクセス可能であるか否かを決定する。アクセスが認可されていることを検証した後、バランシングエンジンは、受信ユニットによりこのデータを受信し、そしてバランシングエンジンに関連付けられている処理ユニットが、住宅所有者の獲得エクイティバランス（残余口座）を更新する（５０６）。バランシングエンジンは、計算の詳細と共に、この更新されたバランスを送信ユニットに送信する。送信ユニットは、計算の詳細それ自体と共に、それを、住宅金融商品データブロックチェーンに書き込む（５０８）。バランシングエンジンは、送信ユニットにより、この更新された獲得エクイティ値を、住宅所有者および出資者がアクセス可能な、新しい値が報告されるウェブサイトに送信する（５１０）。バランシングエンジンは、送信ユニットにより、オフラインになっている可能性がある住宅所有者および出資者（または出資者を表す人工知能エンティティ）に、携帯電話または他の受信デバイスによるＥメールまたはＳＭＳメッセージを介して、更新された獲得エクイティ価値をアラートする（５１２）。

【0060】

システム１００では、バランシングエンジン１０８への入力データは、住宅商品データブロックチェーン１２０に存在し、そして管理エンティティ１０６によって制御される１つ以上のサーバに存在する複数のデータエンジン１１０によって、生成される。各データエンジン１１０は、少なくとも１つのデータパラメータの少なくとも１つの時系列を、作成、収集、更新、処理、格納、および通信する目的に対して、運用する。

【0061】

図６は、管理エンティティ１０６によって制御される処理サーバ上で運用される、システム１００のデータエンジン１１０の例示的な実施形態を提供する評価エンジンを示す。評価エンジン１１０は、住宅金融商品データブロックチェーン１２０に書き込むことによる融資に従う、住宅に対する時系列の住宅価値を、生成しかつ更新する。評価エンジン１１０の例示的な一実施形態は、１つまたは複数のネットワークによりデータを受信する受信ユニット６０２と、１つまたは複数のネットワークにより送信する送信ユニット６０４と、例示的な実施形態を実行するためのコンピュータキテクチャを有する処理ユニット６０６と、データを格納するためのデータベース６０８とを、有する。

【0062】

一実施形態は、図７を参照して理解することが出来る。図７には、例示的実施形態に従って、エクイティ評価リクエストを受信し、図６の処理サーバを使用してエクイティ評価を実行し、そして取引メッセージを発行するプロセスを示す流れ図（７００）が示されている。評価エンジンは、エクイティ評価リクエストに対応するデータリクエストを受け取る（７０２）。１つまたは複数の受信ユニットによって、評価エンジンは、クエリにより第三者評価を収集する（７０４）。評価エンジンは、データベース内のこれらの評価をエンコードする（７０６）。評価エンジンは、処理ユニットにより、該当する場合（７０８）に１つ以上の非第三者評価（７１０）を生成し、そして１つまたは複数の統計手続きを使用して、第三者評価と非第三者評価（７１２）の両方を、バランシングエンジンで使用される運用評価に組み合わせる。評価エンジンは、送信ユニットにより、タイムスタンプおよび計算のレコード（７１４）と共に、（第三者および非第三者評価、非第三者評価の計算に使用される方法論、および運用評価の計算に使用される方法論が含まれる）運用評価を、住宅金融商品データブロックチェーンに書き込む（７１６）。評価エンジンは、データメッセージ（７１８）を生成しそして送信ユニットにより（７２０）、第三者および非第三者評価と共に、新しい運用評価を、これらの評価が報告される、住宅所有者および出資者がアクセス可能なウェブサイトに送信する。もし、所有者と出資者が、運用評価の更新を既にリクエストしていた場合に、一般的に、または特定の値が実現されると、評価エンジンは、送信ユニットにより、オフラインになっている可能性がある所有者と出資者（または出資者を表す人工知能エンティティ）に、携帯電話または他の受信デバイスによる電子メールまたはＳＭＳメッセージを介して、新しい運用評価をアラートする。

【0063】

非第三者評価を計算するには、評価エンジンは、少なくとも住宅取引データを含む第三者のソースからのデータが必要である。評価エンジンの受信ユニットは、第三者プロバイダから、自動的に、または管理エンティティによって要求されたときに、データを受信する。評価エンジンは、このデータを適切にフォーマットし、そしてデータベース内のデータ構造と整合するように処理した後、このデータを住宅データベースに追加する。データは、融資を受けている住宅または他の住宅の価値の鑑定評価を含むことができる。

【0064】

少なくとも、暗黙の賃貸料、減価償却費、固定資産税を含む他のデータ要素は、評価エンジンと同様の方法で動作する他のデータエンジンによって、管理される。

【0065】

管理エンティティ１０６は、少なくとも住宅所有者１０２と出資者１０４との間の住宅融資アレンジメントを、開始、実施、実行そして更新する目的で、少なくとも１つの処理ユニット８０６、少なくとも１つの受信ユニット８０２、および少なくとも１つの送信ユニット８０４で具体化される契約エンジン１１２を、管理エンティティによって制御される少なくとも１つの処理サーバ上に、維持する。契約エンジン１１２の入力データは、住宅金融商品データブロックチェーンシステム１２０に存在する。

【0066】

図８は、１つまたは複数のネットワークによりデータを受信するように設計されている受信ユニット８０２と、１つまたは複数のネットワークによりデータをブロードキャストする送信ユニット８０４と、記述されている実施形態の例示的な機能の実行をサポートするコンピュータアーキテクチャを備える処理ユニット８０６と、データを格納するためのデータベース８０８とを備えるシステム１００の契約エンジン１１２の例示的な実施形態を示す。

【0067】

図９は、例示的な実施形態に従う、住宅所有者のリクエストを処理するプロセスを示す流れ図（９００）である。住宅所有者は、出資者への支払いのレベルを変更して、住宅融資アレンジメントを効果的に借り換えたいと思うかもしれない。

【0068】

住宅所有者は、管理エンティティによって運用されるウェブサイトにアクセスし、そして支払いのレベルの変更をリクエストして、管理エンティティによって制御される契約エンジンの受信ユニットに、送信ユニットにより送信される送信メッセージを生成する（９０２）。契約エンジン処理ユニットは、必要な契約情報を含む関連情報と、少なくとも獲得エクイティのレベルを含む他のデータとを、抽出するために、送信ユニットにより、アクセス承認データと共に、住宅金融商品データブロックチェーンシステムのクエリを送信する（９０４）。住宅金融商品データブロックチェーンシステムは、そのアクセスプロトコールを実装して、契約エンジンが、リクエストされたデータにアクセスすることが可能であるか否かを決定する。アクセスが許可されていることを検証した後、契約エンジンは、受信ユニットによりこのデータを受信し、そして契約エンジンに関連付けられている処理ユニットは、支払いの変更が、出資者の追加の同意なしにこの契約の下で許容可能であるか否かを決定する（９０６）。もし、この変更が、許可されない場合、契約エンジンは、同意または拒否メッセージを生成し（９０８）、そしてそれが表示されるウェブサイトにそれを送信する（９１０）。契約エンジンは、同時に、オフラインである可能性がある住宅所有者に、携帯電話または他の受信デバイスによる電子メールまたはＳＭＳメッセージを介して、支払いレベルの変更が、既に承諾されているまたは拒否されているかを住宅所有者に知らせるアラートを発し、そしてもし、承諾されている場合には、住宅所有者にこの変更の確認を依頼する（９１２）。もし、この変更が確認されると、確認メッセージが生成されて、ウェブサイトに関連付けられている送信ユニットにより、契約エンジンに関連付けられている受信ユニットにこれが送信される。契約エンジンは、送信ユニットにより、住宅金融商品データブロックチェーンシステムのクエリとアクセス承認データとを送信して、この変更が有効になる（９１４）日付と時刻を伴う、少なくとも支払いレベルの変更からなる変更を、住宅金融商品データブロックチェーンに書き込むための許可を確保する。住宅金融商品データブロックチェーンシステムは、そのアクセスプロトコールを実装して、契約エンジンが、要求される許可を有していることを検証する。受信ユニットが許可の検証を受信した後、契約エンジンは、送信ユニットにより変更データをブロックチェーンに書き込み、ブロックチェーン上に支払いレベルの変更のレコードを作成する（９１６）。

【0069】

契約エンジンは、送信ユニットにより、第２の確認メッセージを生成し（９１８）そして住宅所有者および出資者が見ることができるウェブページに送信し（９２０）そしてこのウェブページは、変更が指定された日時に有効であることを報告する。契約エンジンは、送信ユニットにより、同時に、オフラインになっている可能性がある住宅所有者と出資者に、電子メール、または携帯電話または他の受信デバイスからアクセス可能なＳＭＳメッセージを介して、変更が指定された日時に有効であることをアラートする。この構成は、住宅所有者が、支払額と獲得エクイティの累積を追跡することを可能にする同じウェブサイトにより、融資アレンジメントの条件に関する変更が、ほぼ瞬時で、低コストでなされるという結果をもたらす。獲得エクイティの累積の将来のイテレーションでは、バランシングエンジンは、様々な支払いレベルを考慮に入れ、この影響が、経済的に正確に住宅所有者と出資者の両方にとって適切なものとなるように、累積額を調整する。出資者は、融資条件の変更による正味の影響を受けない。何故ならば、獲得エクイティの累積率の調整が、支払いレベルの如何なる変更も正確に相殺するためである。

【0070】

別の実施形態の場合、融資アレンジメントには、抵当権の構成要素とエクイティの構成要素とがあり、出資者は、両方のポジションを保有し、そして住宅所有者から出資者への支払いの一部または全てが、抵当権の支払いである。この実施形態では、直前で説明した機構と同じ種類の機構を使用して、同じ結果を得ることができる。借り換えは、低コストでほぼ瞬時であり、そして出資者に実質的に如何なる経済的影響も与えることはない。

【0071】

一実施形態は、図１０を参照して理解することができる。図１０は、例示的な実施形態に従って、エクイティ調整の同意、および承認をリクエストする取引メッセージの発行および／または取引を検証する取引メッセージの発行のプロセスを示す流れ図である（１０００）。また、前述の実施形態を参照すると、住宅所有者は、出資者の追加の同意なしにそれを行う契約上の権利の下で、特定の法定通貨の形での収益と引き換えに、住宅所有者の獲得エクイティの一部を出資者に売却したい場合がある。特定の実施形態では、出資者は、管理エンティティと提携している暗号通貨ポートフォリオファンドであり、そしてこの暗号通貨ポートフォリオファンドは、特定の住宅の出資者側の住宅エクイティ持分を保有する。

【0072】

住宅所有者は、管理エンティティによって制御される「管理エンティティウェブサイト」にアクセスし、そしてエクイティを購入するまたは売却するリクエストを開始して、管理エンティティによって制御される契約エンジンの受信ユニットに、送信エンティティにより送信される送信メッセージを生成する。契約エンジンへの入力用のデータは、住宅金融商品データブロックチェーンにある。契約エンジンは、アクセス承認データと共に住宅金融商品データブロックチェーンシステムのクエリを、送信ユニットにより、送信して、ブロックチェーンに格納されている、該当する契約条件を含む関連データと、少なくとも現在の住宅の運用評価を含む関連パラメータの現在値とを抽出する（１００４）。住宅金融商品データブロックチェーンシステムは、そのアクセスプロトコールを実装して、契約エンジンが、リクエストされたデータにアクセス可能であるか否かを決定する。アクセスが許可されていることを検証した後、契約エンジンは、受信ユニットにより、その取引が許可されるか否かの質問に関係する契約データを含むデータを受信し（１００６）、そして契約エンジンに関連付けられている処理ユニットは、住宅金融商品データブロックチェーンから抽出された関連パラメータの現在値を前提として、リクエストされた取引が、出資者の追加の承諾なしに、契約に基づいて許可されるか否かを決定する（１００８）。もし、リクエストされた取引が、許可されない場合、取引エンジンに関連付けられている処理ユニットは、拒否メッセージ（１０１０）を生成し、そしてオフラインの可能性があるおよび出資者に、電子メール、ＳＭＳメッセージその他により拒否メッセージを送信する（１０１２）。

【0073】

この査定は、住宅所有者による獲得エクイティのリクエストされた売却が実行された後に、獲得エクイティの最低レベルが、住宅所有者の維持義務をサポートするのに十分なレベルにあるか否かを少なくとも決定することを含むタスクを備える。この査定の一部として、契約エンジンは、結果メッセージを生成し（１０１６）そして住宅所有者がリクエストしたエクイティの売却について、住宅金融商品データブロックチェーンから抽出された住宅価格に基づいて、（住宅価格の）百分率でのエクイティの金額に対応するドル金額を計算する（１０１８）。契約エンジンは、住宅所有者および出資者がアクセス可能な管理エンティティウェブサイトに、送信ユニットにより、リクエスト結果メッセージを送信する。リクエスト結果メッセージには、少なくとも以下を含むリクエスト結果データが含まれている：（ｉ）住宅所有者が出資者に売却することを提案している、獲得エクイティの百分率とドル価格；（ｉｉ）リクエストが同意されたか拒否されたか； （ｉｉｉ）拒否の場合、該当する拒否の理由；（ｉｖ）同意の場合、確認のリクエストと共に、住宅所有者による確認の期限および住宅所有者からの支払い受領の指示。

【0074】

管理エンティティウェブサイトは、グラフィックユーザインタフェースまたは他のアクセス可能な表示オプションにより、他の適用可能なリクエスト結果データと共に承諾または拒否を報告する。契約エンジンは、送信ユニットにより、オフラインである可能性がある住宅所有者および出資者（または出資者を表す人工知能エンティティ）に、電子メール、ＳＭＳメッセージ、または他の方法で、リクエストが同意されたか否かを、各当事者に関連するリクエスト結果データと共に、通知する。もし、リクエストが承諾された場合、住宅所有者への通知には、住宅所有者に売却取引の確認を求める確認リクエストが含まれる（１０２０）。契約エンジンが、一定時間内に住宅所有者から確認を受信しない場合、契約エンジンは、送信ユニットにより、住宅所有者がアクセス可能な管理エンティティウェブサイトに、確認リクエストデータと共に、少なくとも次を含む追加の確認リクエストメッセージを、周期的に送信する：（ｉ）住宅所有者が出資者に売却することを提案する獲得エクイティの割合とドルの価値；および（ｉｉ）住宅所有者からの確認と支払い受領の指示のリクエストと共に、住宅所有者による確認と支払いの期限。

【0075】

契約エンジンは、送信ユニットにより、オフラインである可能性がある住宅所有者に、電子メール、ＳＭＳメッセージ、または他の方法で、関連する確認リクエストデータと共に確認リクエストを通知する。もし、住宅所有者が、確認を拒否した場合、または確認の期間が経過した場合、契約エンジンは、住宅所有者および出資者がアクセス可能な管理エンティティウェブサイトに、住宅所有者が取引の確認を拒否したことまたはその確認期間が経過したことを報告するメッセージを、送信ユニットにより、送信する（１０２２）。管理エンティティウェブサイトは、グラフィックユーザインタフェースまたは他のアクセス可能な表示オプションにより、確認の拒否または確認期間の経過を報告する。契約エンジンは、送信ユニットにより、オフラインである可能性がある所有者と出資者（または出資者を表す人工知能エンティティ）に、電子メール、ＳＭＳメッセージ、またはそれ以外の方法で、確認の拒否または確認期間の経過を通知する。

【0076】

住宅所有者が、管理エンティティウェブサイトで取引を検証すると、ウェブサイトに関連付けられている送信ユニットは、確認を示すメッセージを、住宅所有者の支払い指示と共に、契約エンジンに関連付けられている受信ユニットに送信する。契約エンジンは、送信ユニットにより、暗号通貨ポートフォリオファンド１０４の受信ユニットに、少なくとも支払い額と住宅所有者からの支払い受領指示を含む支払いデータを送信する。この実施形態では、暗号通貨ポートフォリオは、不動産ポジションのみを保有しかつ現金は扱わないように設計されている。暗号通貨ポートフォリオファンドの処理ユニットは、住宅所有者によって提供されているエクイティを購入するための暗号通貨ポートフォリオには、現金が利用できないように設計することを決定する。この売却取引では住宅所有者に支払う現金がないため、暗号通貨ポートフォリオファンドの処理ユニットは、送信エンティティにより、融資リクエストメッセージを、管理エンティティが運用する暗号通貨取引エンジンに送信する（１０２４）。

【0077】

暗号通貨取引エンジン１１８の実施形態は、図１１を参照して理解することができる。融資リクエストメッセージは、少なくとも以下を含む融資リクエストデータを含む；（ｉ）発行する必要がある暗号通貨；（ｉｉ）発行額；（ｉｉｉ）収益に対して指定される法定通貨；（ｉｖ）住宅所有者からの支払い受領の指示。暗号通貨取引エンジンには、組み込まれている支払いネットワークとブロックチェーンベースの取引機構（１１０２、１１０４、１１０６および１１０８）とが含まれている。これにより、管理エンティティによって制御される銀行口座または他のリポジトリである、「管理エンティティ銀行口座」または略して「ＭＥＢＡ: managing entity bank account」で生じる適切な法定通貨の検証済みのクレジットまたはデビットにより、市場取引所をほぼ瞬時に監視するエンジンが、暗号通貨の購入と売却を開始することが可能になる。ＭＥＢＡは、第三者銀行または独自の取引所に保有されていて、そして完全に承認されていて、そして電子預金および送金を行うことができる。

【0078】

当業者は、このような支払いネットワークおよびブロックチェーンベースの取引機構を運用して、適切な検証方法を使用して、ほぼ瞬時に暗号通貨取引を実行する様々な方法を理解している（参照特許文献１）。暗号通貨取引エンジンは、送信ユニット１１０４により、関連する暗号通貨の新しく発行されたユニットを売却する注文を、暗号通貨が取引されている１つ以上の第三者または独自の取引所の受信ユニットに、送信する。実行後（１０２６）、取引所は、売却を確認し、そして（おそらく、取引で使用される中間暗号通貨を所望の法定通貨に変換する１つ以上の介在する取引の後）、資金を関連する法定通貨でＭＥＢＡに送信することを確認する。取引所は、取引確認メッセージを生成し、そしてそれを暗号通貨取引エンジンの受信ユニット１１０２に送信する。暗号通貨取引エンジンは、送信ユニットにより、住宅所有者が提出し、かつ暗号化取引エンジンが融資リクエストの一部として契約エンジンから受け取った支払い受領指示を含む支払いリクエストを、ＭＥＢＡに送って、住宅所有者への資金の発行をリクエストする。資金の発行と要求された銀行システムの確認の後、ＭＥＢＡは、支払い完了メッセージを、暗号通貨取引エンジンの受信ユニットに送信する。暗号通貨取引のデータは、暗号通貨取引ブロックチェーン１１０８に記録される。暗号通貨ブロックチェーンシステムから要求される許可を確保した後、暗号通貨取引エンジンは、送信ユニットにより、売却取引のデータを暗号通貨取引ブロックチェーンに書き込む（１０３０）。

【0079】

１つまたは複数のこのようなブロックチェーンシステムにより暗号通貨を扱う方法は、当業者には明らかであろう。暗号通貨取引エンジンは、処理ユニット１１０６により、取引完了メッセージを計算し（１０３２）そして、完了送信ユニットにより、契約データ完了エンジンの受信ユニットに送信する。取引完了メッセージには、少なくとも次を含む完了データが含まれている：（ｉ）取引が完了し、そして支払いが既になされていることの確認：（ｉｉ）住宅所有者が出資者に売却した獲得エクイティの割合とドルの価値；（ｉｉｉ）売却条件を設定するために使用された住宅の評価；（ｉｖ）売却が完了した日時。契約エンジンは、送信ユニットにより、住宅金融商品データブロックチェーンシステムのクエリを、アクセス承認データと共に送信して、完了データをブロックチェーンに書き込む許可を確保する。住宅金融商品データブロックチェーンシステムは、アクセスエンジンを実装して、契約エンジンが、要求される許可を有していることを検証する。確認後、契約エンジンは、送信ユニットにより、完了データをブロックチェーンに書き込んで、住宅所有者による出資者への獲得エクイティの売却のレコードを、ブロックチェーンに作成する（１０３４）。契約エンジンは、取引確認メッセージ（１０３６）を生成し、そして送信ユニットにより、少なくとも完了データを含む取引確認メッセージを、管理エンティティのウェブページに送信し（１０３８）、そして住宅所有者と出資者が見ることができる管理エンティティのウェブページは、関連する完了データと共に取引の確認を報告する。契約エンジンは、同時に、オフラインである可能性がある住宅所有者と出資者に、電子メールまたは携帯電話または他の受信デバイスからアクセス可能なＳＭＳメッセージを介して、関連する完了データと共に、取引が完了していることをアラートする。

【0080】

この構成により、住宅所有者が、支払われた金額および獲得された獲得エクイティを追跡することができる同じウェブサイトにより、融資額が、ほぼ瞬時に低コストで増加する結果が得られる。獲得エクイティの累積の将来のイテレーションの場合には、バランシングエンジンは、住宅所有者の獲得エクイティの一部を出資者に売却した結果の減少を考慮する。瞬時の実行と低コストは、既存の抵当権の借り換えまたは既存の抵当権に従属する新規の借り入れを要求するであろう従来の抵当権のアレンジメントにより調達される資金が、増大すること（つまり、通常、何週、場合によっては何月も必要とし、そしてしばしば、異種のウェブサイトへのアクセスと共に、オフラインの対話に関係する手順）とは全く対照的である。

【0081】

暗号通貨ポートフォリオのデータは、暗号通貨ポートフォリオのブロックチェーンに存在する。一実施形態は、図１２を参照して理解することができる。図１２は、例示的な実施形態に従って、データブロックチェーンシステム１１０８を更新し、そしてポートフォリオの評価に関する取引メッセージを送信するプロセスを示す流れ図である。

【0082】

ポートフォリオエンジン１１８は、処理ユニット１１０６と、少なくとも１つの受信ユニット１１０２と、暗号通貨ポートフォリオファンドによって処理サーバ上で運用される少なくとも１つの送信ユニット１１０４とにより具体化される。この実施形態では、管理エンティティ、または暗号通貨ポートフォリオファンドを表す人工知能エンティティに関連付けられている暗号通貨ポートフォリオファンドが、ポートフォリオエンジン１１０の送信ユニットにより、周期的に、アクセス承認データと共に、クエリを、住宅金融商品データブロックチェーンシステム１２０に送信して、そのエクイティポジションに関する関連データ、およびポートフォリオ内の住宅に関する最新の評価データ、および他の情報を抽出する。住宅金融商品データブロックチェーンシステムは、そのアクセスプロトコールを実装して、ポートフォリオエンジンが、リクエストされたデータにアクセス可能であるか否かを決定する。アクセスが許可されていることを検証した後、ポートフォリオエンジン１１０は、受信ユニットにより、関連データを受信する。ポートフォリオエンジンに関連付けられている処理ユニットは、暗号通貨ポートフォリオ（１２０４）とポートフォリオエンジンに関する情報を更新し、そして暗号通貨ブロックチェーンシステムから要求される許可を確保した後、送信ユニットは、更新された情報を暗号通貨ポートフォリオブロックチェーン（１２０６）に書き込む。ポートフォリオエンジンは、ポートフォリオ更新メッセージ（１２０８）を生成しそして送信ユニットにより、更新されたポートフォリオ情報を、暗号通貨ポートフォリオの出資者がアクセス可能なウェブサイトに送信する（１２１０）。この情報には、少なくとも１つまたは複数の特定の評価アプローチに基づくポートフォリオの評価と、暗号通貨の単位あたりの対応する価値とが含まれる。

【0083】

１つまたは複数の実施形態では、出資者の承諾手順のような他の機能を、住宅所有者が出資者に獲得エクイティを売却するプロセスに追加することができ、そして住宅所有者が、出資者にエクイティを売却する代わりに出資者からエクイティを購入する類似のプロセスを適用することも出来る。

【0084】

一実施形態は、図１３を参照して理解することができる。図１３の流れ図（１３００）は、例示的な実施形態に従って、図１の住宅金融商品データブロックチェーンシステムからデータアンサンブルを抽出および編成し、このデータアンサンブルを記録し、そしてデータ報告メッセージを発行するためのプロセスを示す。定期的に、それを表す管理エンティティまたは人工知能エンティティは、契約エンジンの受信ユニットにメッセージを送信して、住宅金融商品データブロックチェーンへのデータアンサンブル更新エントリを開始する。契約エンジンは、送信ユニットを介して住宅金融商品データブロックチェーンシステムのクエリを、アクセス許可データとともに送信し、少なくとも支払い率と条件、次の支払い日と金額を含む、各住宅金融商品の現在の状態を特徴付ける関連データを抽出する。このデータには、住宅所有者が獲得した株式の現在のレベル、少なくとも暗黙の家賃と住宅価格を含む主要なパラメータの現在のレベル、および住宅用機器の現在の状態を特徴付ける他のデータ（１３０２）が含まれる。住宅金融商品データブロックチェーンシステムは、契約エンジンが、要求されたデータにアクセスできるか否かを判断するために、そのアクセスプロトコールを実装する。アクセスが許可されていることを確認した後、連絡エンジンは、受信ユニットを介してこのデータを受信し、契約エンジンに関連付けられた処理ユニットが住宅金融商品のデータアンサンブルを更新します（１３０４）。契約エンジンは、この更新されたデータアンサンブルを送信ユニットに送信し、送信ユニットは、それを住宅金融商品データブロックチェーンに書き込む（１３０６）。契約エンジンは、更新されたデータアンサンブルを含むレポートメッセージを生成し（１３０８）、更新メッセージの値が報告される住宅所有者および投資家がアクセスできるウェブサイトに、送信ユニットを介して、レポートメッセージを送信する（１３１０）。

【0085】

住宅所有者または出資者は、いつでも管理エンティティウェブサイトにアクセスし、そして次の支払い日と金額を含む支払いレートと条件、住宅所有者の獲得エクイティの現在のレベル、少なくとも暗黙的な賃貸料と住宅価格を含む主要なパラメータの現在のレベル、および住宅金融商品の現在の状態を特徴付ける他のデータを観察することができる。この機能の背後には、少なくとも評価エンジンおよび管理エンティティにより維持されているコンタクトエンジンを含む、様々なデータおよびプロセスエンジンによって、それ自体が、継続的に更新されている、住宅金融商品データブロックチェーンを読み取ることにより、ウェブサイトネットワークが、ウェブサイト情報を継続的に更新していることがある。

【0086】

これまでの実施形態は、住宅所有者が、単一のウェブサイトと様々なＧＵＩベースのページにアクセスして、低コストでほぼ瞬時に、少なくとも、住宅金融商品についての獲得エクイティのレベルおよび現在のデータの監視、出資者への支払い、支払いレベルの変更または出資者が保有するエクイティの支払による借り換え、および獲得エクイティを出資者に売却することにより現在の市場条件での融資レベルを向上させること含む、多数の機能を扱うことが出来るシステムを記述している。このシステムにより、住宅融資に適用可能である従来技術を特徴付ける分断化、高コスト、連携の欠如が、解消される。システムの中核は、特定のバランシング機構である。

【0087】

（ＤＯＯＲ住宅金融商品の基礎となるバランシング機構）
各ＤＯＯＲバランシングエンジンは、特定のバランシング機構によって特徴付けられる。上述したＤＯＯＲ金融商品の例には、次のような状況が関わる：
（ｉ）住宅所有者は、一人である；
（ｉｉ）出資者は、一人である；
（ｉｉｉ）住宅アレンジメントが、ジョイントベンチャであるかのように分析された場合、住宅所有者は、正の純拠出を形成している；そして
（ｉｖ）住宅所有者は、ＤＯＯＲ契約の売却または完了時に、この住宅商品の存続期間中に行われた純拠出と引き換えに、獲得エクイティ（つまり、この住宅のレバレッジされていないエクイティ）を受け取る。

【0088】

ＤＯＯＲアレンジメントは、複数の住宅所有者、複数の出資者、住宅所有者に代えて出資者による純拠出、および純拠出を補うための獲得エクイティ以外の残余口座の使用に関与することができる。上記の制限（ｉ）～（ｉｖ）が適用される基本ケースから始めることにより、ＤＯＯＲバランシング機構を説明することは、容易である。この場合、ＤＯＯＲバランシング機構がどのように運用されるかを示した後には、イノベーションが、１つ以上の実施形態に従って、どのようにより一般的に適用されるかは、当業者には明らかであろう。後続のセクションは、いくつかの追加の議論および例示的な例により、その適用幅を示す。

【0089】

このセクションでは、基本ケースについて開示されている獲得エクイティの累積アルゴリズムのクラスについての記述から始まり、そのクラスで特に興味深い「購入パリティ」バリアントが指定され、そしてアルゴリズムのクラスと購入パリティバリアントの両方について理論的基礎が議論される。購入パリティ累積アルゴリズムは、前のセクションで説明したＭＭ－０の実施形態のバランシング機構の基礎になる。関連付けられているバランシング機構が、ＭＭ－０住宅アレンジメント自体を実装するので、この実施形態は直接アレンジメントである。後述する本発明の実施形態から明らかになるように、購入パリティ累積アルゴリズムを中心に構築される同じバランシング機構は、実施形態が直接アレンジメントではない多くの場合に有用である。クラスの他の累積アルゴリズムは、本発明の他の実施形態に適用可能な他のバランシング機構の基礎となる。

【0090】

我々は、住宅所有者の純拠出から始める。上述したように、主なプラス要素には、抵当権の支払いまたは出資者への他の支払、固定資産税の支払い、および維持出費が含まれる。主なマイナス要素は、住宅に居住することの暗黙の賃貸価値である。これらの要素は、全て、時間の経過と共に発生する連続的な流れである。フローの性質は、不動産が購入または売却されたときに、抵当権の支払いと固定資産税の負債を日割りで配分するという標準的な慣行から明らかである。

【0091】

純賃貸料のフロー率

【数1】

は、

【数2】

（家主の占有率の値である総賃貸料のフロー率）；

【数3】

（構造の減価償却率）;

【数4】

（固定資産税が発生する割合）、および

【数5】

（他の非融資費用のフロー率）により規定される。簡略化のために、住宅所有者の保守義務には、全ての減価償却費が含まれていると想定されている。純賃貸料には、抵当権または他の負債のような要素を処理するコストは含まれていない。従って、純賃貸料とは、資産のレバレッジされていない所有者に発生するであろうリターンのフロー：

【数6】

である。ここで、

【数7】

は年単位の時間を表し、この方程式の各フロー要素が、時間と共に変化し得ることを示す。時間

【数8】

における住宅価値を

【数9】

で除すと、住宅価値の割合として、純賃貸料発生のレート：

【数10】

が得られる。

【0092】

融資の要素に目を向けると、住宅所有者は、抵当権の拠出および／またはスケジュールされた支払いを次のレート：

【数11】

で行っている。ここで、抵当権の支払いの場合、

【数12】

は、元本拠出率、

【数13】

は、利息拠出率である。

【数14】

は、スケジュールされた支払いがある場合のレートである。融資の一部が、後述するように、住宅所有者によって暗黙的に（例、受託エクイティとして）提供される、（利息拠出が、支払われるのではなく帰属される）可能性があるので、支払いではなく拠出という用語が使用される。これらの融資拠出を住宅の価値により正規化すると、住宅の価値の割合として融資経費発生のレート：

【数15】

が得られる。

【0093】

従って、住宅価値の割合としての住宅所有者の年間の純拠出率は、次のとおり：

【数16】

である。

【0094】

時間

【数17】

での獲得エクイティ割合を、

【数18】

であるとする。次で、住宅所有者の総額の純拠出率を、次のように：

【数19】

規定する。

【0095】

これで、請求される獲得エクイティの累積アルゴリズムのクラスを規定することができる。金融商品は、期間

【数20】

の間保有されていると仮定する。この期間

【数21】

を、長さ

【数22】

の

【数23】

個の等しいサブ期間に分割する。獲得エクイティの割合について、次の離散近似：

【数24】

を検討する。ここで、

【数25】

は、期間

【数26】

が始まる時間、

【数27】

は、期間

【数28】

が終わる時間、

【数29】

は、重み関数である。この近似を削除すると、正確な連続時間の獲得エクイティの割合：

【数30】

が得られる。

【0096】

式（４）および（５）は、異なる重み付け関数

【数31】

によって規定されるクラスの異なるメンバーを有する累積アルゴリズムのクラスを規定する。この制限は、

【数32】

が、

【数33】

の関数であるので、単純に式（４）の要素をシフトする結果にはならない。離散的近似の場合、各時間周期ｉが、以前の時間周期の終端から

【数34】

の値を使用して

【数35】

を計算し、そして

【数36】

を再帰的に計算することが可能である。例えば、ＤＯＯＲバリアントの例の１つであるＡＮＺＩＥ－ＤＯＯＲは、次の重み関数：

【数37】

によって規定される。ここで、

【数38】

は、適切な長期リスクなしレート、

【数39】

は、住宅の予想される上昇率、そして

【数40】

は、上記の式（１）のように規定される。

【0097】

特定の重み関数

【数41】

を適用すると、次の獲得エクイティ累積アルゴリズム：

【数42】

によって規定される購入パリティＤＯＯＲバリアントが、生成される。ここで、

【数43】

【0098】

このバリアントは、獲得エクイティの累積が、各時点での純拠出フローが、その時点で存在する住宅価格で追加の住宅価値を購入するために使用されると仮定され場合と同じという特徴を有する。この点を検証するには、時点

【数44】

に対して：

【数45】

ここで、

【数46】

の高次のべきの重要でない項は無視されている。式（８）は、年の短い瞬間

【数47】

における獲得エクイティ部分の増加が、住宅価値に

【数48】

を乗算した割合としての年換算純寄与率であることを示す。住宅所有者は、住宅所有者の純拠出の正確な金額で、追加の住宅エクイティを効果的に購入する。従って、このバリアントの名前は「購入パリティ」である。

【0099】

このバリアントは魅力的な特性を有する。住宅所有者が、出資者からそのエクイティの市場価値で、住宅のエクイティを効果的に購入するので、両者とも、レバレッジされていないポジションについて住宅の経済的リターンを正確に獲得する。もし、何れかの当事者がレバレッジされている場合、その当事者は、同等のレバレッジされているリターンを獲得する。単一のＤＯＯＲ金融商品の場合、全ての融資は出資者によって提供され、その結果、出資者は、事実上レバレッジされず、そして出資者の結合されたポジションで住宅の経済的リターンを正確に獲得する。従って、単一のＤＯＯＲ出資をポートフォリオに組み合わせると、基礎となる住宅で、組み合わせた正確な経済的リターンを獲得するビークルが得られる。この特性により、単一のＤＯＯＲ金融商品は、地域、国、または世界全体で住宅のリターンを複製するポートフォリオ、およびポートフォリオ内の金融商品の基礎となる一連の住宅によって近似または作成された住宅インデックスの収益を効果的に複製するポートフォリオ、の作成に理想的なものとなる。

【0100】

購入パリティバリアントは、強い魅力を有し、かつ本発明の中心的な側面であるが、異なる重み付け関数によって規定される他のバリアントも、また、商業的用途に関連する。１より大きい加重関数は、購入パリティと比較してより高い額の獲得エクイティを作成し、そして１未満の加重関数は、購入パリティと比較してより低い額の獲得エクイティを作成する。これらの重み付け関数は、補助金を作成する手段、または拠出を行っている当事者によってなされた拠出またはその当事者によって累積されたポジションの計算に反映されないリスクまたは他の側面を調整する手段である。購入パリティバリアントの下では、購入者は、特定のポジションの購入後、そのポジションに固有の経済的リターンを獲得する。ここまでに考慮された唯一のポジションは、住宅でのレバレッジされていない持分である獲得エクイティであった。しかしながら、次のセクションで示すように、請求されているアプローチでは、獲得エクイティに加えて、またはそれに代えて、残余口座として、他の多くのポジションまたは調整が可能である。

【0101】

これまでのところ、請求されているクラスのＤＯＯＲバリアントは、少なくとも暗黙の賃貸料、減価償却費、固定資産税、および抵当権の支払いを含む、量の連続的なフローの観点から説明されて来た。時間

【数49】

での特定の支払い

【数50】

が、フローの一部ではなく離散的である場合、獲得エクイティの増加である

【数51】

は、

【数52】

となる。

【0102】

方程式（９）によって管理される離散要素を、方程式（４）および（５）によって記述される連続要素に追加することによって、離散要素をフロー要素に追加することができる。購入パリティの場合、離散部分とフロー部分の両方が、実勢住宅価格での獲得エクイティの直接購入として、計算される。

【0103】

近似の使用は可能である。例えば、ある

【数53】

の値に対する、

【数54】

の代わりに

【数55】

を使用することができるかもしれない。または、購入パリティのケースでは、フローの期間の途中の値を使用して各期間の拠出を合計し、そして期間の途中の住宅価格で除算することにより、合計純拠出度を計算することができるかもしれない。近似の使用は、本発明に含まれる。しかしながら、いくつかの場合には、それらが正確な解答に非常に近い場合を除いて、近似が不適切であることに注意することは重要である。例えば、購入パリティバリアントは、計算が正確である場合、出資者と住宅所有者の両方が、出資の増分ごとに事後的な住宅リターンを正確に獲得するという特性を有する。この特性は、住宅リターン指数に相当する、または住宅リターンを正確に捉えるＤＯＯＲ金融商品のポートフォリオを作成するために重要である。各期間の中間点でこれらの値を使用するような強力な近似方法でさえも、特に短い保有期間の場合、実際の値とは大きく異なる累積リターンを生成する場合がある。

【0104】

キャピタルゲインの課税に関する戦略的取引の問題と、出資者と住宅所有者の間で住宅アレンジメントをバランスさせる問題との間には類似性がある。キャピタルゲインの状況では、理想的な発生税は、ゲインに課税され、そして発生時に損失は許容される。同等のアプローチは、利益と損失の発生時に課税が評価され、そして資産が売却されたときに支払われるべき利益でそれらを累積させることである。これに代えて、もし、保有期間中の損益の履歴を考慮せずに、売却時の損益全体のみに課税および納税を行うと、問題が生じる。納税者は、資産を売却しないことによってゲインを先延ばし（「ロックイン」）する、または資産を売却して損失を実現させる（戦略的損失を取る）インセンティブを有する。何れの場合にも、政府は歳入を失い、そして出資者が、資産の期待される税引き前リターンではなく、税の適用可能性に基づいて資産を保有または売却すると言うように、出資者の行動は歪曲される。非特許文献１Alan Auerbach（AJ Auerbach、回顧的キャピタルゲイン課税、American Economic Review，vol．８１、pp．１６７-１７８（１９９１年３月）を参照）は、歪曲されたインセンティブを除去し、そして出資者が、他の資産との相対的な経済的リターンのみに基づいて資産を保有または売却するという意味で、経済的バランスを回復すると言う、売却時の税金対策に対するユニークな解決法を示している。時間０に購入されそして時間

【数56】

に売却された資産の場合、その時点での税、資産価値

【数57】

の割合は、次のとおり：

【数58】

である。ここで、

【数59】

は、税率、そして

【数60】

は、適切な無リスク金利である。

【0105】

住宅アレンジメントの問題は全く類似している。純拠出を行う当事者は、売却時に他の当事者に課される税金によって補償を受けることができる。一般性を失うことなく、住宅所有者を、他の当事者が出資者であるアレンジメントにおいて純拠出を行う当事者としよう。この場合、出資者は、税務状況では資産所有者のポジションにあり、そして住宅所有者は、政府のポジションにいる。住宅所有者の純拠出は、出資者に課税債務を生じさせる。税設定と同様に、課税債務を清算するには少なくとも３つの方法がある：
（１）出資者から住宅所有者への即時相殺支払いにより、その場で税金を支払う；
（２）税金の支払い期限に注意することにより、適切な利率で税額を累積できるようにし、そして出資者が累積金額を売却時に住宅所有者に支払うようにさせること；そして
（３）住宅所有者の資産の割合を積み立てておくことにより、売却時の資産に課税する。

【0106】

第３の解決策は、上述した獲得エクイティのアプローチに類似しており、そして住宅アレンジメントの場合にインセンティブを妨げないユニークな解決策は、式（１０）で表される解決策と同じ形式を有する。もし、住宅アレンジメントが、市場のディールに対して住宅所有者に多かれ少なかれ有利になり、それが出資者にとって不利になるときには、ディールを保有する、またはそれが他の方向に進みそして住宅所有者に不利になるときには、借り換えを行うと言う、不当な動機付けを住宅所有者に与える、問題のあるインセンティブが、発生する。この問題は、市場の状況により、住宅所有者が、投資家の不利益に借り換えをするインスタンスを相殺するように、住宅市場で住宅所有者が利用できる条件を、出資者により有利になるようにさせることを要求する。静的住宅アレンジメントに関するこの問題は、この出願のこれ以前で述べたものと同じである。

【0107】

方程式（１０）を、住宅アレンジメントに獲得エクイティを累積するためのユニークな解決法に変換するには、１つの要素、つまり税率が欠けている。明らかに、税率の一部となるであろう１つの要因は、式（１０）のコンテキストでレートとして表される、課税当事者の正の純拠出である。しかしながら、純拠出率は、リターン率で正規化する必要がある。この率は、課税当事者が拠出するリターン率の割合を反映している。つまり、この後で説明する要素のグロスアップを許可した後、税率は次の形式：

【数61】

になる。ここで、

【数62】

は、リターン率である。そして、式（１０）は、次の重み関数：

【数63】

を使用して式（４）および（５）に変換される。ここで、

【数64】

は

【数65】

と同等であり、同じ適切なリスクなしレートの異なる表記法である。上述したように、住宅アレンジメントの目的に応じて、

【数66】

、従って

【数67】

の選択は自由である。リスクや他の要因で計算に含まれない他の要因を調整する必要がなく、そして

【数68】

を使用して補助金を作成する必要がない場合、

【数69】

を選択するのは魅力的である：この選択の購入パリティ資産は、両当事者が受け取るまたは保有する利益に対して、両当事者の市場のリターンを作成する。

【0108】

純拠出をグロスアップする、つまり、

【数70】

の代わりに

【数71】

を使用する根拠は、Auerbachのアレンジメントにより明確であり、そして上記の式（８）の数学からも明らかである。Auerbachのアレンジメントでは、時間

【数72】

における資産保有者への任意の分配の割合

【数73】

は、これが、もし、資産が時間

【数74】

に売却された場合に課税される割合であるので、政府に適切に属する。同様に、資産保有者への政府による金額

【数75】

の拠出は、

【数76】

のジョイントベンチャへの拠出に相当し、すぐに政府に戻る金額

【数77】

がこれに続く。従って、ジョイントベンチャへの拠出は、Auerbachのアレンジメントで政府を信用するとき、または住宅アレンジメントで純拠出をする当事者が信用できるときに、グロスアップされるべきである。

【0109】

（開示されたクラスの範囲）
上記のセクションでは、獲得エクイティが、経済的バランスを維持する残余口座である、ＤＯＯＲ住宅アレンジメントの扱いについて詳しく説明した。当事者によるアレンジメントへの純拠出は、その当事者に有利な獲得エクイティの発生となる。前のセクションは、累積アルゴリズムがバランシング機構を規定する、累積アルゴリズムのクラスに対する発生の適切な発生率を説明した。

【0110】

他の可能な残余口座が多数あり、そして任意の所与のアレンジメントは、複数の口座を有することができる。前のセクションの分析を、獲得エクイティとは異なる、または獲得エクイティに加える残余口座に関与するアレンジメントに、拡張することは、購入パリティバリアントに対しては特に単純である。このイノベーションには、購入パリティバリアントから他の発生アレンジメントのバリアントへの拡張が含まれるが、我々は、購入パリティ資産を、プレゼンテーションを単純かつ明確にする、以下に示される規範と見なしている。

【0111】

受託エクイティ。受託エクイティは、保有者が、利息の支払いを受ける代わりに、純拠出アレンジメントのクレジットとして利息を得ることを除いた、第２の抵当権に似たポジションである。ＡＮＺＩＥ－ＤＯＯＲバリアントには、受託エクイティが含まれていた。このバリアントでは、頭金または抵当権の元本の支払い以外の全ての項目に基づく住宅所有者の純拠出は、獲得エクイティに換算される。これに対し、住宅所有者が行った如何なる頭金または抵当権の元金の支払いも、全て、ドル対ドルの受託エクイティとなった。例えば、ＡＮＺＩＥ－ＤＯＯＲアレンジメントが適用され、住宅が２００,０００ドルで購入され、ＤＯＯＲの出資者が＄４０,０００のエクイティを投入し、住宅所有者が頭金を払わず、そして住宅所有者が、利息と元金の両方を支払う＄１６０,０００の元金利息払抵当権があるとしよう。数年後、住宅所有者が元金の総額に対し＄１０,０００を支払い、抵当権の残高が＄１５０,０００になったとする。これで、住宅所有者は、１０,０００ドルの受託エクイティを持ち、そしてこの１０,０００ドルのポジションが、住宅所有者の継続中の純拠出の一部としてカウントされる適切な帰属率での利子を発生させる。もし、住宅が、この時点で売却されると、手続きは、第１に、＄１５０、０００を第１の抵当権バランスに、第２に、＄１０、０００を住宅所有者による獲得エクイティに、そして第３に、従来の獲得エクイティとして出資者に払う。例え、要求される獲得エクイティが、売却時に出資者が受け取る従来のエクイティを超えていても、出資者は、明らかに、住宅所有者に住宅所有者の獲得エクイティシェアを支払う義務がある。ＡＮＺＩＥ－ＤＯＯＲでは、頭金と抵当権の支払いは、ドル対ドルで受託エクイティに変換される。これは、上記の購入パリティアプローチに相当する受託エクイティの累積の処理であり、そして住宅所有者は、獲得エクイティを別々に発生させて、抵当権利息の支払い、固定資産税の支払い、住宅の維持、および他のソースから生じる純拠出を補償する。従って、ＡＮＺＩＥ－ＤＯＯＲは、受託エクイティと獲得エクイティの両方の残余口座が複数ある、ＤＯＯＲ金融商品の例である。

【0112】

確率的支払い。幾つかのアプリケーションでは、獲得エクイティの累積を修正または制限することが望ましい。そうするための１つの明白な方法は、住宅所有者、出資者、またはその両方によって行われる支払いを変えることである。もし、支払額が経済状況によって異なって、純拠出率がゼロに維持される場合、獲得エクイティ割合は、固定されたままになるであろう。この場合、確率的支払いは残余口座である。

【0113】

レバレッジされているエクイティ。上述のＭＭ－０アレンジメントと以下で説明するＭＭ－１アレンジメントでは、住宅所有者は、住宅のレバレッジされていない利息である獲得エクイティを累積する。獲得エクイティを残余口座として使用するのではなく、何らかの形のレバレッジされているエクイティを使用することもできる。このレバレッジされているエクイティは、出資者と住宅所有者が、住宅の従来のエクイティを共有している既存の抵当権に影響を与える可能性がある。住宅所有者のポジションが発生するにつれて、抵当権の義務に何が起こるかを知る必要があり、そしてこの義務が、抵当権者としての出資者に対するものであるのか、第三者に対するものであるのかが重要である。一実施形態では、出資者は抵当権者であり、そして出資者は、住宅所有者に有利な発生の部分としての、従来のエクイティスライスと共に、抵当権の対応する部分の責任を譲渡する。この譲渡された抵当権のスライスは、住宅所有者に対する償還である。別の実施形態では、もし、出資者の保有権利が、住宅所有者に対し抵当権が非遡求性であることを反映している場合、住宅所有者は、抵当権について適切な金利調整を行って、出資者から従来のエクイティを本質的に購入する。さらに別の実施形態では、住宅所有者は、純拠出と引き換えにアメリカンコールオプションポジションを獲得する。獲得エクイティではなくレバレッジされているエクイティが残余口座にある場合、レバレッジされているエクイティの発生を作成するための他の実施形態は、請求されたクラスの金融商品の、関連付けられている発生アルゴリズムと共に、実行される。

【0114】

別の累積口座。住宅における負債またはエクイティ持分を獲得する代わりに、純拠出は、別の口座に累積させることができる。この口座は、既定の金利を獲得する、市場金利から導出される金利を獲得する、または有価証券、インデックスファンド、または不動産ポートフォリオに裏打ちされた暗号通貨を含む他の資産に、出資させることもできる。分配に関するルールは、純拠出を行う当事者が、住宅の売却前に口座から引き出しを行うことが出来るか否か、または幾ら口座を現金化することができるかを決定する。これを実行する機能に制限を加えることは、アカウントを保有する当事者が、資産に関する保守義務を確実に実行すると言うような理由から、望ましい場合がある。ＳＡＶＩＮＧ－ＤＯＯＲは、別の累積口座を残余口座として使用するインスタンスである。

【0115】

他の多くの残余口座。このイノベーションには、住宅アレンジメントのバランスを取るために使用されるかもしれない他の多くの残余口座が含まれる。これらには、住宅におけるほぼ全ての種類の負債またはエクイティのポジション、および当事者間で居住するためにタイムシェアを配分するようなアレンジメントが含まれるが、これらに限定されるものではない。本発明は、経済バランスを達成することを目的とする全ての可能な残余口座をカバーする。

【0116】

金融商品の動的要素の重要な役割に再度注目することは価値がある。例えば、もし、住宅所有者の獲得エクイティポジションが、特定の値に固定されていて、そして住宅保有者による支払いが、契約の他の要素が、住宅所有者による支払いである場合、住宅所有者の支払いは、純拠出率をゼロに保つために変えなければならない。さもないと、このアレンジメントは、住宅所有者または出資者の何れかを優先し始め、そして中立ではなくなり、そして両方の当事者が、自分のポジションの市場リターン率を確実に獲得することが不可能となる。

【0117】

獲得エクイティ以外の残余口座の使用は別として、クレームされたクラスが、上述したおよび以下の様々な例よりも広い他の方法に、注目することは価値がある。他の側面の中で特に重要な２つの側面は、住宅所有者以外の当事者がプラスの純拠出を行うアレンジメントと、単一の住宅所有者、単一の出資者、または単一の抵当権者よりも多くの当事者がいるアレンジメントである。

【0118】

多くの実装では、住宅所有者ではなく出資者が、獲得エクイティまたは追加を他のいくつかの残余口座に発生させる。顕著な例は、ＣＯＺＩＥ－ＤＯＯＲで、これは、住宅所有者が、継続的に、または住宅の獲得エクイティまたは受託エクイティのポジションと引き換えに出資者から一括して、支払いを受け取る金融商品のクラスである。ＣＯＺＩＥ－ＤＯＯＲの１つのバージョンでは、出資者が、年金を住宅所有者に支払い、そして年金の支払いに伴って、獲得エクイティを得る。固定資産税、住宅保険、または他の支払いは、獲得エクイティのより多くのまたはより早い発生に対する補償としてアレンジメントに追加されるかもしれない。

【0119】

他の実装では、複数の出資者、複数の住宅所有者、または複数の抵当権者が存在し得る。場合によっては、これらの状況により、複数の当事者への獲得エクイティの発生または他の残余口座を促進する必要が生じる。このような各当事者は、他の当事者によって行われる拠出とは種類または金額が異なる別個の拠出を行っている可能性がある。当事者間の相対的な拠出は、経済変数の価値の変化に伴ってシフトさせることができる。

【0120】

中立ＤＯＯＲ金融商品のもう１つの特徴は、１つの金融商品の最終値をフリーズし、そしてすぐにこのバランスを新しい別の金融商品に挿入することにより、金融商品間をシームレスにシフトすることができることである。例えば、住宅所有者は、獲得エクイティを含むＭＭ－０のような金融商品から、レバレッジされているエクイティポジションを含むバリアントに移行するかもしれない。もし、出資者および／または潜在的な抵当権者が、このような柔軟性を許可するアレンジメントに同意する場合、何れの方向へのこの変更も、ほぼ瞬時にオンラインで行わせることができる。この種のアレンジメントは、ＩＳ－Ａ－ＤＯＯＲである。

【0121】

（ＭＭ－１住宅融資アレンジメント）
ＭＭ－０住宅融資アレンジメントは、単一の金融商品で具体化される。抵当権または他の種類の融資を提供する第三者はいない。これに対し、ＭＭ－１の住宅融資アレンジメントは、多角的金融商品を必要とする。第三者が抵当権を提供し、そしてＤＯＯＲ出資者が従来のエクイティ融資を提供する。この結果、住宅所有者または出資者が、追加の元金支払いを行う権利を有するというような従来の側面の理由のみならず、ＭＭ－１が抵当権をエクイティ金融商品にしっかりと結び付けているという理由により、ＭＭ－１は、抵当権をエクイティ金融商品および住宅所有者に連携させる必要性を導入する。

【0122】

ＭＭ－１バリアントは、いくつかの機能をＭＭ－０に追加する：
（１）ＤＯＯＲ出資者による抵当権の保証。第三者の抵当権は、抵当権の残高に関して、抵当権者に有利な保険のような保証を作成する、ＤＯＯＲ出資者に対する償還請求権である。ＤＯＯＲ出資者は、住宅所有者による獲得エクイティのより遅い発生によって、継続的に補償される。
（２）ＬＴＶ比率を制限するための抵当権の支払。 ＤＯＯＲ出資者は、低価値の状況にある抵当権を支払、ＬＴＶに上限を設ける義務がある。この上限は、売却時のＤＯＯＲ出資者のエクイティが、ＤＯＯＲ出資者が住宅所有者に支払うことを要求される獲得エクイティの支払いを超えることを保証し、これによりその義務が確実に履行されるように、設定されている。ＤＯＯＲ機構は、ＤＯＯＲ出資者に、如何なる支払に対しても正確な経済的補償を提供して、支払が必要になったときにアレンジメントに留まるという動機を出資者に想起させる。この補償は、従来のエクイティのポジションの強化と抵当権の総支払い額の減少という形で行われ、これは、出資者が、売却時に住宅所有者に支払わなければならない、獲得エクイティの発生が少なくなることを意味する。
（３）抵当権／エクイティ保険の保護。最も信用力のあるＤＯＯＲ出資者を除いて、保険会社は、ＤＯＯＲ出資者の抵当権の保証、抵当権の支払、および獲得エクイティの義務を支持する。ＤＯＯＲ出資者が、必要な抵当権の支払を怠った場合、ＤＯＯＲ金融商品は保険会社に没収され、そして保険会社は、支払を行うための補償的価値を受け取り、そのような措置が必要なときに動機を生み出す。

【0123】

ＭＭ－１のアレンジメントは、かなりの商業的可能性を有する。住宅所有者は、頭金をほとんどまたは全く支払わずに住宅を確保することができ、そしてもし、条件が適切に設定されている場合、数年の累積後の住宅の価値のかなりの割合となっている彼らの持分が、レバレッジされていないと言う性質は、価格が下がっても、彼らが市場に確実にいることを意味する。住宅の状態に持分を有する所有者が、それを占有しているという事実によって経済的リターンが、向上するので、出資者は、賃貸よりも優れた選択肢を手に入れる。

【0124】

ＭＭ－１のアレンジメントは、抵当権の階層化された強力な信用補完のセットを作成することにより、抵当権の債権者、抵当権のオリジネータ、抵当権を保証するＧＳＥ、および証券化された抵当権義務の購入者、に対するビジネスリスクを大幅に削減する：
（ｉ）価値の低い設定では、住宅所有者のレバレッジされていないエクイティ持分がドル対ドルにあるので、住宅を維持するという住宅所有者のインセンティブが、強固である；
（ｉｉ）同様に、支払いが、獲得エクイティの補償的な発生という結果になるので、抵当権の支払いを継続する住宅所有者のインセンティブは、低額の状況でも堅実なままである；
（ｉｉｉ）抵当権が、ＤＯＯＲ出資者によって保証されている；
（ｉｖ）ＤＯＯＲ出資者は、根底にある抵当権の義務よりも価値のない「価値が低下した」住宅から生じる問題を排除して、ＬＴＶの上限を維持するために抵当権の支払義務があり；そして
（ｖ）保険会社は、ＤＯＯＲ出資者の抵当権保証および支払義務を支援する。

【0125】

これらの階層化された信用補完（ＭＭ－１によって追加される最後の３つ）が、デフォルトと差し押さえのリスクを大幅に低減する。このアレンジメントは、ＬＴＶレベルを実質的に１００％未満に維持し、そして住宅の価値が大幅に低下した場合でも、住宅を維持し、かつ抵当権の支払いを継続する、住宅所有者の強力なインセンティブを生み出す。抵当権保険によって支えられているＤＯＯＲ出資者の抵当権保証により、抵当権の債権者は、住宅所有者の支払能力にほとんど依存しない。

【0126】

ＭＭ－１は、抵当権保険会社向けのゲームチェンジャーである。保険契約の条件は、ＤＯＯＲ出資者が要求される抵当権を支払うことができなかった場合に、ＤＯＯＲ出資者が、保険会社のためにＤＯＯＲ出資を没収することである。保険会社が、介入し、ＤＯＯＲ契約の当事者としてＤＯＯＲ出資者を置き換え、そして契約に基づいて要求される抵当権の支払いを行う。この支払いは、表面的には抵当権の保険金の支払いに似ている。しかし、ここには大きな違いがある：損失により単純に立ち往生する代わりに、保険会社は、資産を所有し、そして要求される抵当権を支払うことで、資産の価値が代償により正確に増加するという結果が得られる。資産は、支払前に価値を有していたので、貸借対照表への影響はプラスであり、そしてこの支払は完全に補償される。さらに、全国の住宅価格の一般的な低下による大量の支払義務の不履行に直面している保険会社は、住宅の幅広いポートフォリオでレバレッジされているエクイティポジションを保有しているので、回復時に急激に回復する資産を累積している。保険会社が、このポートフォリオ出資の役割およびそれに関連付けられる変動性を引き受けたくない場合は、保険会社は、ＤＯＯＲ金融商品を、それを行う意思がある第三者に売却することが出来、そして保険会社は、同時に、この金融商品に保険契約を結ぶことが出来る。正味の効果は、関連付けられている保険事業を維持しつつ、この金融商品を実行しない当事者から実行する当事者にシフトすることである。

【0127】

抵当権をエクイティ金融商品に結び付けるＭＭ－１アレンジメントのこれらの特徴は、住宅所有者、ＤＯＯＲ出資者、抵当権者、抵当権保険会社の間で要求される連動決定を実装するために、集中型かつ時間依存の通信を必要とする。例えば、住宅価格の低下は、出資者への通知、出資者のアクションのリクエスト、および出資者の行動の失敗に直面した場合の金融商品の移転を要求する支払機能をトリガーすることが出来る。この支払により、住宅所有者が、抵当権が減額された代替支払い方法の中から選択することできるようになり、これは、住宅所有者をループに巻き込む結果をもたらす可能性がある。そして、時間は、住宅所有者の獲得エクイティ支払いが保証されるという信頼性を維持するためには、本質的である。本発明は、これらの可能性の全てを提供する。

【0128】

（ＭＭ－１住宅融資アレンジメントの実装）
本発明がどのようにＭＭ－１住宅融資アレンジメントの実施形態を実装するかを説明するために、我々は、所有期間に焦点を当て、そして住宅所有者、単一の出資者、単一の抵当権者を有する単一の抵当権者、および単一の抵当権／エクイティ保険会社の単純なケースから始める。従って、抵当権は、第三者の住宅融資エンティティである抵当権者が提供する第三者の住宅融資であり、そして抵当権／エクイティ保険会社は、第三者のサービスプロバイダである。この実施形態では、抵当権者は、また、抵当権にサービスを提供して、支払いを収集し、そして抵当権設定者に情報を提供する。

【0129】

本発明の実装の中核にあるのは、処理ユニット、少なくとも１つの受信ユニット、および管理エンティティによって処理サーバ上で運用される少なくとも１つの送信ユニットで実施されるバランシングエンジンである。バランシングエンジンは、住宅所有者と出資者の間の住宅アレンジメントをジョイントベンチャと見なして、それらの継続的な拠出を長期にわたって評価する。一実施形態では、出資者と抵当権者は、最初、それぞれ、従来のレバレッジされているエクイティと抵当権で住宅全体に融資し、住宅所有者は抵当権の元本と利息を抵当権者に支払い、住宅所有者は固定資産税を支払い、住宅所有者は住宅を維持し、そして住宅所有者は住宅に居住する。この実施形態では、住宅所有者の純拠出は、（ｉ）抵当権の元本と抵当権者への利息の支払い、（ｉｉ）固定資産税の支払い、（ｉｉｉ）維持、および（ｉｖ）保険などの他の義務から、（ｖ）住宅に居住する価値となる賃貸料として請求されるであろうもの（「暗黙の賃貸料」）を差し引いたものに等しい。バランシング機構は、住宅所有者と出資者の利益を照合するために残余口座を必要とする。この実施形態では、残余口座は、獲得エクイティ、出資者が住宅の売却または融資アレンジメントの完了時に住宅所有者に支払わなければならない住宅のレバレッジされていない利息からなり、そして支払いは、住宅所有者の純拠出が正となるように設定される。

【0130】

この実施形態では、バランシングエンジンへの入力データは、住宅金融商品データブロックチェーンに存在する。このデータには、少なくとも住宅所有者の抵当権の出資者への支払いを含む、全ての拠出要素の時系列が含まれている。図５に示されるように、管理エンティティまたはそれを表す人工知能エンティティは、周期的に、バランシングエンジンの受信ユニットにメッセージを送信して、住宅金融商品データブロックチェーンへのバランシングエントリを開始する（５０２）。バランシングエンジンは、抵当権データブロックチェーンシステムのクエリを、アクセス承認データと共に送信ユニットにより送信して、拠出、および住宅融資アレンジメントをカバーする契約の下で獲得エクイティを計算する管理アルゴリズムを含む他の要素に関する関連データ（それ自体は、住宅金融商品データブロックチェーン（５０４）にエンコードされている）を抽出する。住宅金融商品データブロックチェーンシステムは、そのアクセスプロトコールを実装して、バランシングエンジンが、リクエストされたデータにアクセス可能であるか否かを決定する。アクセスの許可が検証された後、バランシングエンジンは、受信ユニットによりこのデータを受信し、そしてバランシングエンジンに関連付けられている処理ユニットは、住宅所有者の獲得エクイティバランスを更新する（５０６）。バランシングエンジンは、計算の詳細と共にこの更新されたバランスを送信ユニットに送信する。送信ユニットは、それ自体を、計算の詳細と共に住宅金融商品データブロックチェーンに書き込む（５０８）。バランシングエンジンは、送信ユニットにより、更新された獲得エクイティ値を、住宅所有者および出資者がアクセス可能な、この新しい値が報告されるウェブサイトに送信する（５１０）。バランシングエンジンは、送信ユニットを介して、オフラインになっている可能性がある住宅所有者および出資者（または出資者を表す人工知能エンティティ）に、携帯電話または他の受信デバイスによるＥメールまたはＳＭＳメッセージを介して、更新された獲得エクイティ価値をアラートする（５１２）。

【0131】

図１４を参照すると、実施形態を理解することができる。図１４は、例示的な実施形態に従って、ブロックチェーンシステムに支払いデータを書き込み、そしてブロックチェーンシステムから更新されたデータを抽出するプロセスを示す流れ図（１４００）である。

【0132】

バランシングの運用の入力データは、住宅金融商品データブロックチェーン上にあり、そして管理エンティティによって制御される１つ以上のサーバ上にある複数のデータエンジンによって生成および更新される。各データエンジンには、少なくとも１つの処理ユニット、少なくとも１つの受信ユニット、少なくとも１つの送信ユニット、および少なくとも１つのデータベースが含まれる。各データエンジンは、少なくとも１つのデータパラメータの少なくとも１つの時系列を作成、収集、更新、処理、格納、および通信する目的で、運用される。ＭＭ－１住宅融資アレンジメントを実装する場合、データエンジンには、少なくとも１つの第三者データエンジン、管理エンティティによって制御される１つまたは複数のサーバ上にあり、少なくとも１つの処理ユニットに組み込まれている抵当権データエンジン、少なくとも１つ受信ユニット、少なくとも１つの送信ユニット、および少なくとも１つのデータベースが、含まれる。抵当権データエンジンは、第三者の抵当権に関するデータを収集、格納、処理、および通信する目的で動作する。住宅所有者が抵当権の支払いを行うと、抵当権者の処理サーバの送信ユニットは、管理エンティティ（１４０２）によって制御される処理サーバで動作する抵当権データエンジンの受信ユニットに支払いメッセージを送信する。支払いメッセージには、少なくとも、（ｉ）支払い金額；（ｉｉ）元本と利子の間の内訳；および（ｉｉｉ）支払いの日時、を含む支払いデータが含まれる。抵当権データエンジンの処理ユニットは、このデータを住宅金融商品データブロックチェーン（１４０４）に適した形式に変更し、そして送信ユニットにより住宅金融商品データブロックチェーンシステムのクエリをアクセス承認データと共に送信して、支払いデータをブロックチェーンに書き込む許可を確保する。住宅金融商品データブロックチェーンシステムは、そのアクセスプロトコールを実装して、抵当権データエンジンが、要求される権限を有していることを検証する。受信ユニットにより検証の確認を受信した後、抵当権データエンジンは、送信ユニットにより、抵当権データブロックチェーンに支払いデータを書き込む（１４０６）。抵当権データエンジンは、送信ユニットにより、抵当権データブロックチェーンシステムのクエリをアクセス承認データと共に送信して、抵当権のステータスを更新するために、少なくとも、支払い履歴、最新の支払い後の現在の元本残高、および住宅用金融商品のデータブロックチェーンにある住宅の最新の運用評価に基づいたＬＴＶを含む適切なデータを抽出する（１４０８）。

【0133】

住宅金融商品データブロックチェーンシステムは、そのアクセスプロトコールを実装して、抵当権データエンジンがリクエストされたデータにアクセス可能であるか否かを決定する。アクセスの許可が検証された後、抵当権データエンジンは受信ユニット（１４１０）により関連データを受信し、そして抵当権データエンジンの処理ユニットが、この抵当権関連データ（１４１２）をウェブサイトの表示に適した形式に編成し、これは、結果的に表示可能な抵当権関連データのパッケージとなる。抵当権データエンジンは、送信ユニットにより、住宅所有者、出資者、抵当権者／エクイティ保険会社がアクセス可能なウェブサイト（ここでは、抵当権関連データは、受信された、表示可能な抵当権関連データを使用して更新される）に、表示可能な抵当権関連データを送信する（１４１４）。抵当権データエンジンは、送信ユニットを介して、住宅所有者、出資者（または出資者を表す人工知能エンティティ）、および抵当権者／エクイティ保険会社（または抵当権者／エクイティ保険会社を表す人工知能エンティティ）に、携帯電話または他の受信デバイスによる電子メールまたはＳＭＳメッセージを介して、更新された抵当権関連情報をアラートする。

【0134】

図７において、評価エンジンは、管理エンティティによって制御される処理サーバ上で運用されるデータエンジンであり、これは、住宅金融商品データブロックチェーンに書き込むことにより、融資を受ける住宅の住宅価値の時系列を作成および更新する。評価エンジンは、住宅評価リクエストに対応するデータリクエストを受け取る（７０２）。評価エンジンは、１つまたは複数の受信ユニットにより、クエリにより第三者評価を収集する（７０４）。評価エンジンは、送信ユニットにより、これらの評価をデータベースにエンコードする（７０６）。評価エンジンは、処理ユニットにより、該当する場合（７０８）１つ以上の非第三者評価（７１０）を生成し、そして１つ以上の統計手続きを使用して、第三者評価と非第三者評価（７１２）の両方を組み合わせて、バランシングエンジンと契約エンジンが使用する運用評価にする。評価エンジンは、送信ユニットにより、住宅金融商品データブロックチェーンシステムのクエリをアクセス承認データと共に送信して、評価データをブロックチェーンに書き込むための許可を確保する。住宅金融商品データブロックチェーンシステムは、そのアクセスエンジンを実装して、評価エンジンに要求される許可があることを検証する。受信ユニットにより検証の確認を受け取った後、評価エンジンは、送信ユニットにより、少なくとも第三者および非第三者評価、非第三者評価を計算するために使用される方法、および運用評価を計算するために使用される方法を含む、有効な評価を、タイムスタンプ（７１４）および計算のレコードと共に、住宅金融商品データブロックチェーンに書き込む（７１６）。評価エンジンは、データメッセージを生成し（７１８）そして送信ユニット（７２０）を介して、データメッセージ送信ユニットにより、少なくとも新しい運用評価を、第三者および非第三者評価と共に、これらの評価が報告される、住宅所有者および出資者がアクセス可能なウェブサイトに送信する。評価エンジンは、送信ユニットを介して、所有者と出資者（または出資者を表す人工知能エンティティ）に、彼らがオフラインになっている可能性がある場合には、携帯電話または他の受信デバイスによる電子メールまたはＳＭＳメッセージを介して、彼らが、既に、運用評価の更新をリクエストしていた場合、一般的に、または特定の値が実現されたときに、新しい運用評価をアラートする。

【0135】

少なくとも暗黙の賃貸料、減価償却、固定資産税の負債を含む他のデータ要素は、評価エンジンと同様の方法で動作する他のデータエンジンによって管理される。

【0136】

管理エンティティは、少なくとも住宅所有者と出資者の間の住宅融資アレンジメントを、開始、実装、実施、および、更新する目的のために、管理エンティティによって制御される少なくとも１つの処理サーバ上で、少なくとも１つの処理ユニット、少なくとも１つの受信ユニット、および少なくとも１つの送信ユニットで具体化される契約エンジンを維持する。契約エンジンの入力データは、住宅金融商品データブロックチェーンに存在する。

【0137】

一実施形態は、図１５を参照して理解することができる。図１５は、例示的な実施形態に従って、ブロックチェーンシステムからの評価をリクエストし、そしてブロックダウンに支払額を記録するためのプロセスを示す流れ図（１５００）である。評価エンジンは、送信ユニットにより、契約エンジンの受信ユニットにメッセージを送信する（１５０２）。このメッセージは、運用評価が、少なくとも新しい運用評価を含むデータと共に、既に更新されていることを示す。契約エンジンは、抵当権のデータブロックチェーンシステムのクエリを、アクセス承認データと共に、送信ユニットにより送信して、現在の抵当権の元本残高と、出資者により抵当権の支払が要求されているか否かを決定する管理アルゴリズムおよび要求される支払額とを含む他の要素とに、関係する関連データを抽出する（１５０４）。住宅金融商品データブロックチェーンシステムは、そのアクセスプロトコールを実装して、契約エンジンが、要求された許可を有していることを検証する。アクセスの許可が検証された後、契約エンジンは、受信ユニットにより、このデータを受信し、そして契約エンジンに関連付けられている処理ユニットが、出資者により抵当権の支払が要求されているか否か（１５０６）を、そして要求されている場合（１５０８）には、その要求額を決定する。もし、処理ユニットが、支払が必要であると決定した場合、契約エンジンは、送信ユニットにより、アクセス承認データと共に、住宅金融商品データブロックチェーンシステムのクエリを送信して、支払データをブロックチェーンに書き込む許可を確保する。住宅金融商品データブロックチェーンシステムは、そのアクセスエンジンを実装して、契約エンジンが、要求される許可を有していることを検証する。受信ユニットにより検証の確認を受信した後、契約エンジンは、送信ユニットにより、出資者への支払いが要求されているか否かの決定を、関連付けられている計算に関する情報と共に、住宅金融商品データブロックチェーン（１５１０）に記録する。契約エンジンは、少なくとも要求される支払額と支払い期限を含む抵当権の支払いデータを、出資者の処理サーバの受信ユニットに送信する。出資者の処理サーバは、送信ユニットにより、アクセス承認データと共に、住宅金融商品データブロックチェーンシステムのクエリを送信して、関連データを抽出して、支払いの必要性と金額を検証する。

【0138】

住宅金融商品データブロックチェーンシステムは、そのアクセスプロトコールを実装して、出資者が、リクエストされたデータにアクセス可能であるか否かを決定する。アクセスの許可が検証された後、出資者の処理サーバは、受信ユニットにより、リクエストされたデータを受信し、そして処理ユニットにより、支払がスケジュールされていることを検証する。検証後、一実施形態では、出資者の処理サーバは、送信ユニットにより、抵当権者の処理サーバの受信ユニットに支払いリクエストメッセージを送信する。このメッセージは、少なくとも、出資者資金のソース、支払い金額、およびそれが元本の追加の支払いとして適用される抵当権を指定する支払い指示を含む。第２の実施形態では、中間手順、すなわち出資者による同意がある。出資者の処理サーバは、データベースにアクセスして、同意を付与または拒否する権限を有する出資者として適切な人物または人口知能代表を決定する。出資者の処理サーバは、送信ユニットにより、同意または拒否のリクエストを、このような個人または人口知能担当者に関連付けられている、指定された処理サーバの受信ユニットに送信する。個人が決定権を有している場合、送信ユニットを介して、同時に、同意または拒否のリクエストを、指定された処理サーバに関してオフラインである可能性があるそのような人に、電子メール、ＳＭＳメッセージ、または他の方法により、送信する。同意または拒否のリクエストには、少なくとも次のものが含まれる：（ｉ）要求された支払い額；（ｉｉ）人が決定権限を有している場合、パスワードまたは他の保護によって保護され、かつ同意または拒否を示すことができる特定の処理サーバによって運用されるウェブサイトへのリンク。指定された処理サーバは、送信ユニットにより、同意または拒否を示すメッセージを出資者の処理サーバの受信ユニットに送信する。この指定された処理サーバは、送信ユニットにより、メッセージを出資者の処理サーバの受信ユニットに送信して、同意または拒否を示す。同意の場合、出資者の処理サーバは、送信ユニットにより抵当権者の処理サーバの受信ユニットに、支払いリクエストメッセージを送信する。このメッセージには、少なくとも、出資者の資金源、支払い額、およびそれが元金の追加支払いとして適用される抵当権を指定する支払いリクエストが含まれる。拒否の場合、出資者の処理サーバは、送信ユニットにより、契約エンジンの受信ユニットに拒否通知メッセージを送信する。

【0139】

一実施形態は、図１６を参照して理解することができる。図１６は、例示的な実施形態に従って、支払いデータをブロックチェーンシステムに記録するための、またはブロックチェーンシステムを使用して契約条件を識別するためのプロセスを示す流れ図（１６００）である。第１の実施形態または第２の実施形態の場合、そのように承諾する権限を有する人物または人口知能担当者によって既に支払いの承諾が示されている場合（１６０２）、抵当権者の処理サーバは、支払いリクエストメッセージを既に受け取っていて、そして当業者には明らかであろう方法により、支払い指示で指定された出資者の銀行口座から支払いを回収しようと試みる（１６０４）。もし、資金が全額をカバーするのに十分であり（１６０６）、そして全額が回収されるとすると、抵当権者の処理サーバの処理ユニットが、データベースに保有されている抵当権者のレコードを適切に更新した後、またはブロックチェーンに書き込まれた、要求される許可を受け取った後、抵当権者の処理サーバの送信ユニットは、支払いメッセージを、管理エンティティによって制御される処理サーバ上で運用される抵当権データエンジンの受信ユニットに送信する。この支払メッセージには、少なくとも、（ｉ）支払金額；（ｉｉ）支払日時；（ｉｉｉ）支払い後の毎月の支払い額を含む支払実行データが含まれる。抵当権データエンジンの処理ユニットは、この支払実行データを、住宅金融商品データブロックチェーンに適した形式に変更し、そして抵当権データエンジンは、送信ユニットにより、住宅認証データブロックチェーンシステムのクエリを、アクセス承認データと共に送信して、支払実行データをブロックチェーンに書き込むための許可を確保する（１６０８）。

【0140】

住宅金融商品データブロックチェーンシステムは、そのアクセスプロトコールを実装して、契約エンジンが、要求される許可を有していることを検証する。受信ユニットにより検証の確認を受信した後、抵当権データエンジンは、送信ユニットにより、抵当権データブロックチェーンに支払実行データを書き込む（１６１０）。抵当権データエンジンは、送信ユニットにより、住宅金融商品データブロックチェーンシステムのクエリを、アクセス承認データと共に送信して、住宅金融商品データブロックチェーンシステムに存在する住宅の最新の運用評価に基づいて、少なくとも、支払い履歴、現在の元本の残高、そして支払の毎月の支払額およびＬＴＶ比率を含む抵当権のステータスを更新するのに適切なデータを抽出する。住宅金融商品データブロックチェーンシステムは、そのアクセスプロトコールを実装して、抵当権データエンジンが、リクエストされたデータにアクセス可能であるか否かを決定する。アクセスの許可が検証された後、抵当権データエンジンは、受信ユニットにより、この抵当権関連データを受信し、そして抵当権データエンジンの処理ユニットは、この抵当権関連データを、表示可能な抵当権関連データのパッケージが得られるように、ウェブサイトの表示に適した形式に編成する。抵当権データエンジンは、送信ユニットにより、表示可能な抵当権関連データを、住宅所有者、出資者、抵当権者／エクイティ保険会社がアクセス可能なウェブサイトに送信する。ここで、この抵当権関連データは、受信された、表示可能な抵当権関連データを使用して更新される（１６１４）。抵当権データエンジンは、送信ユニットを介して、オフラインの可能性がある、住宅所有者、出資者（または出資者を表す人工知能エンティティ）、および抵当権者／エクイティ保険会社（または抵当権者／エクイティ保険会社を表す人工知能エンティティ）に、携帯電話または他の受信デバイスによる電子メールまたはＳＭＳメッセージを介して、更新された抵当権関連情報をアラートする。バランシングエンジンに組み込まれているバランシング機構は、出資者が、リスク調整ベースで支払に対する完全な経済的補償を受け取ることを保証し、さらに、出資者が，ポジションの損失（これは、もし、出資者が、支払をすることに失敗したときに、発生するであろう）を回避することを確保する。これらの２つの側面は、出資者が支払を行うための強力なインセンティブを作成することにより、支払取引を容易にする。

【0141】

もし、抵当権者の処理サーバが、この口座の資金が支払を完全にカバーするのに十分でないまたは他の理由（１６０６）により、支払の指示で指定された出資者の銀行口座から支払金額を回収することができない場合、抵当権者の処理サーバは、送信エンジンにより、資金不足の通知を契約エンジンの受信ユニットに送信する。契約エンジンは、送信ユニットにより、住宅金融商品データブロックチェーンシステムのクエリを、アクセス承認データと共に送信して、出資者が状況を修正するための期限を含む、不十分な資金状況をカバーする契約条項に関する関連データを抽出する（１６１６）。

【0142】

住宅金融商品データブロックチェーンシステムは、そのアクセスプロトコールを実装して、契約エンジンが、リクエストされたデータにアクセス可能であるか否かを決定する。アクセスの許可が検証された後、契約エンジンは、受信ユニットにより、このデータを受信し、そして契約エンジンに関連付けられている処理ユニットが、データベースにアクセスして、出資者によって指定された、資金不足の通知を受け取る出資者の担当者を決定する。契約エンジンは、資金不足の通知を生成し（１６２０）そして、送信ユニットにより、出資者の処理サーバの受信ユニットに、この資金不足の通知を送信し、そして同時に、送信ユニットを介して、資金不足の通知を、出資者の処理サーバに対しオフラインである可能性がある、出資者の指定された担当者に、電子メール、ＳＭＳメッセージ、または他の方法により、送信する（１６２２）。資金不足の通知には、少なくとも次のものが含まれる：（ｉ）未払い額；（ｉｉ）利用可能な資金の量；（ｉｉｉ）支払額の徴収を妨げる他の問題；（ｉｖ）残高を増やすため、または別の資金源を指定するための期限。契約エンジンは、住宅金融商品データブロックチェーンにエンコードされ、そしてそれからアクセスされる契約条項によって設定される期間内で、（ｉ）契約エンジンが支払通知を受け取る；（ｉｉ）不十分な資金問題を修正するための期限が経過するの何れかまで、同じ通知を、出資者の処理サーバを含む同じ当事者に、周期的に送信する（１６２４、１６２６）。

【0143】

一実施形態は、図１７を参照して理解することができる。図１７は、例示的な実施形態に従って、ブロックチェーンによって取得されたデータを使用して、受信したデフォルト通知（１７０２）を処理し、そしてブロックチェーンシステムにおいて出資者の変更を決定および記録する流れ図（１７００）である。もし、出資者が支払の承諾を拒否した、または十分でない資金状況を修正するための期限が過ぎてしまった場合、契約エンジンは、送信ユニットにより、アクセス承認データと共に、住宅金融商品データブロックチェーンシステムのクエリを送信して、出資者が支払義務を履行しない場合にとるべき措置についての関連契約データを抽出する（１７０４）。

【0144】

住宅金融商品データブロックチェーンシステムは、そのアクセスプロトコールを実装して、契約エンジンが、リクエストされたデータにアクセス可能であるか否かを決定する。アクセスの許可が検証された後、契約エンジンは、受信ユニットにより、このデータを受信し、そして契約エンジンは、送信ユニットにより、デフォルトの通知を、抵当権者／エクイティ保険会社が運用する処理サーバの受信ユニットに送信する（１７０６）。デフォルトの通知には、少なくとも以下を含むデフォルトのデータが含まれている：（ｉ）デフォルトの出資者の身元；（ｉｉ）要求される支払額；（ｉｉｉ）支払は、現在、抵当権者／エクイティ保険会社の義務であるとの通知；（ｉｖ）そのような支払いの要求と支払い方法の指示；（ｖ）出資者のＤＯＯＲ金融商品ポジションが、抵当権者／エクイティ保険会社に移管されるであろうとの通知；（ｖｉ）抵当権者／エクイティ保険会社が、抵当権データブロックチェーン上のこのポジションに関する適切なデータにアクセスするためのアクセス承認データ；（ｖｉｉ）出資者向けの情報を表示する管理エンティティウェブサイトへのアクセス。契約エンジンは、当業者には明らかな方法を使用して、支払エンジンが、抵当権者／エクイティ保険会社の支払い義務のステータスを監視し、保険会社が支払いを行うまで適切な通知を周期的に保険会社に送信し、支払が行われた後に支払いを確認し（１７１０）、そして送信ユニットにより支払い完了メッセージを生成し（１７１２）そして契約エンジンの受信ユニットに送信する（１７１４）ことを可能にする（１７０８）。支払メッセージには、少なくとも以下を含むデータが含まれる：（ｉ）支払の事実；（ｉｉ）関連付けられている検証データ；（ｉｉｉ）支払金額；（ｉｖ）支払日時；（ｖ）毎月の抵当権の支払レベルの変更（ある場合）：および（ｖｉ）住宅金融商品データブロックチェーンに保険会社を出資者として入力するために要求される抵当権者／エクイティ保険会社の識別情報。支払メッセージを受信した後（１７１０）、契約エンジンは、送信ユニットにより、住宅金融商品データブロックチェーンシステムのクエリを、アクセス承認データと共に、送信し、ブロックチェーンでカバーされる金融商品の出資者を変更する。住宅金融商品データブロックチェーンシステムは、そのアクセスプロトコールを実装して、契約エンジンが、そのような変更を行うために要求されるレベルの許可を有していることを検証する。検証後、契約エンジンは、ブロックチェーンに書き込んで、デフォルトの出資者を、該当する金融商品の該当する出資利益の所有者として、抵当権者／エクイティ保険会社に置き換える（１７１６）。契約エンジンは、所有権の交換が完了したことを示す交換メッセージを生成し（１７１８）そして送信ユニットにより、このメッセージを、抵当権者／エクイティ保険会社の処理サーバの受信ユニットに送信する（１７２０）。

【0145】

次に図１４を参照する。図１４に示すように、契約エンジンは、送信ユニットにより、支払メッセージを抵当権データエンジンの受信ユニットに送信する（１４０２）。この支払メッセージには、少なくとも以下を含む支払実行データが含まれる：（ｉ）支払金額；（ｉｉ）支払日時；（ｉｉｉ）支払い後の毎月の支払い額。抵当権データエンジンの処理ユニットは、この支払実行データを、住宅金融商品データブロックチェーンに適した形式に変更し（１４０４）、そして抵当権データエンジンは、送信ユニットにより、住宅金融商品データブロックチェーンシステムのクエリをアクセス承認データと共に送信して、支払実行データをブロックチェーンに書き込む権限を確保する。

【0146】

住宅金融商品データブロックチェーンシステムは、アクセスエンジンを実装して、契約エンジンが、要求される許可を有していることを検証する。受信ユニットにより検証の確認を受信した後、抵当権データエンジンは、送信ユニットにより、抵当権データブロックチェーンに支払実行データを書き込む（１４０６）。抵当権データエンジンは、送信ユニットにより、アクセス承認データと共に、住宅金融商品データブロックチェーンシステムのクエリを、送信して、少なくとも支払い履歴、現在の元本の残高、支払後の毎月の支払い額、および住宅金融商品データブロックチェーン上に存在する住宅の最新の運用評価に基づいたＬＴＶ比率を含む、抵当権のステータスを更新するのに適切なデータを、抽出する（１４０８）。住宅金融商品データブロックチェーンシステムは、そのアクセスプロトコールを実装して、抵当権データエンジンが、リクエストされたデータにアクセス可能であるか否かを決定する。アクセスの許可が検証された後、抵当権データエンジンは、受信ユニットにより、この抵当権関連データを受信し（１４１０）、そして抵当権データエンジンの処理ユニットは、この抵当権関連データをウェブサイトの表示に適した形式に編成し、これは、結果的に表示可能な抵当権関連データのパッケージとなる（１４１２）。抵当権データエンジンは、送信ユニットにより、表示可能な抵当権関連データを、住宅所有者、出資者、抵当権者／エクイティ保険会社がアクセス可能なウェブサイトに送信する（１４１４）。ここで、抵当権関連データは、受信された、表示可能な抵当権関連データを使用して更新される。抵当権データエンジンは、送信ユニットを介して、オフラインの可能性がある、住宅所有者、出資者（または出資者を表す人工知能エンティティ）、および抵当権者／エクイティ保険会社（または抵当権者／エクイティ保険会社を表す人工知能エンティティ）に、携帯電話または他の受信デバイスによる電子メールまたはＳＭＳメッセージを介して、更新された抵当権関連情報を、アラートする。バランシングエンジンに組み込まれているバランシング機構は、抵当権者／エクイティ保険会社が、デフォルトの出資者の代わりに、リスク調整ベースでなされた支払に対する完全な経済的補償を受け取り、さらに、抵当権者／エクイティ保険会社が、ボーナスとして、初期状態の出資者の全体の出資利子を得ることを確実にする。これら２つの要素は、抵当権者／エクイティ保険会社が、支払を行うための強力なインセンティブを作成することにより、支払取引を容易にする。

【0147】

図１８は、ブロックチェーンシステムから契約条項データを抽出し、そして支払いエンジンをアクティブにして、支払いデータを生成しかつブロックチェーンシステムに書き込むプロセスを示すフロー図（１８００）である。一実施形態では、もし、住宅所有者の維持義務に保証を提供する、住宅所有者の獲得エクイティポジションの少なくとも妥当性を含む特定の条件が、満たされた場合、住宅所有者が抵当権を支払えないことは、代わりに支払わなければならない義務を出資者に発生させる。抵当権の支払いが期限切れになると、抵当権者の処理サーバは、送信ユニットにより、契約エンジンが存在する管理エンティティによって運用される処理サーバの受信ユニットに、期限超過の支払い通知を送信する（１８０２）。通知を受け取ると、契約エンジンは、送信ユニットにより、住宅認証データブロックチェーンシステムのクエリをアクセス承認データと共に送信して、期限切れの支払い状況における出資者の義務をカバーする契約条項に関する、出資者が状況を修正する期限を含む関連データを抽出する（１８０４）。

【0148】

住宅金融商品データブロックチェーンシステムは、そのアクセスプロトコールを実装して、契約エンジンが、リクエストされたデータにアクセス可能であるか否かを決定する。アクセスが許可されていることを検証後、契約エンジンは、受信ユニットにより、このデータを受信する（１８０６）。契約エンジンは、このデータを使用して、出資者が抵当権の支払いを行う義務および条件、状況およびその義務のタイミングを検証する（１８０８）。契約エンジンは、送信ユニットにより、アクセス承認データと共に住宅金融商品データブロックチェーンシステムのクエリを送信して、もし、出資者が、住宅所有者に代って即座に抵当権の支払いを行った場合に生じるであろう住宅所有者の獲得エクイティポジションの削減に関する関連データを抽出する（１８１０）。住宅金融商品データブロックチェーンシステムは、そのアクセスプロトコールを実装して、契約エンジンが、リクエストされたデータにアクセス可能であるか否かを決定する。アクセスが許可されていることの検証後、契約エンジンは、受信ユニットにより、このデータを受信する。契約エンジンの処理ユニットは、出資者が、住宅保有者に代わり即座に支払いをした場合の獲得エクイティを計算し（１８１２）そして少なくとも以下を含む期限切れ支払い手続きデータを含む期限切れ支払い手続きメッセージを作成する（１８１４）：（ｉ）抵当権の支払い額；（ｉｉ）期限切れである事実；（ｉｉｉ）もし、住宅所有者が支払いを怠った場合に、出資者が支払いを行う義務；（ｉｖ）もし、出資者が住宅所有者に代わって即座に支払いを行った場合に生じる住宅所有者の獲得エクイティポジションの減少；（ｖ）出資者が支払わなければならない前に住宅所有者が支払いを行うための期限；（ｖｉ）この支払が出来なかったことによる獲得エクイティの減少を相殺するために、住宅所有者が将来追加支払いを行うことができるという事実；（ｖｉｉ）そのような将来の追加の支払いが、おそらく、異なる条件にあるであろうという理由により、住宅所有者の獲得エクイティポジションを、もし、住宅所有者が抵当権の支払いをしたならば、それが有していたであろうレベルまで復元するために必要な金額が、相殺される抵当権の支払いより概ね大となり得るという事実;（ｖｉｉｉ）もし、住宅所有者が、期限までに支払いを行う意思がない場合、住宅所有者が、管理エンティティおよび出資者に通知するリクエスト（これにより、将来の通信が回避されるであろう）；および（ｉＸ）住宅所有者の財政状況により、延滞した抵当権の支払いが将来に渡って困難であるか否か、また管理エンティティ、出資者、および住宅所有者が、（出資者が、長期にわたって住宅所有者の代わりに抵当権の支払いを行うことを含むかもしれない）対処計画を立てることができるか否かを、管理エンティティと話し合うための住宅所有者への招待。

【0149】

処理ユニットは、さらに、住宅所有者、出資者、および抵当権者／エクイティ保険会社それぞれに適した、期限切れの支払手続きデータの３つのウェブ表示可能なバージョンを作成する（１８１４）。契約エンジンは、送信ユニットにより、表示可能な３つのバージョンを、管理エンティティが運用するウェブサイトに送信し、各バージョンを、対応する当事者：住宅所有者、出資者、抵当権者／エクイティ保険会社がアクセスできるようにする（１８１６）。契約エンジンは、送信ユニットを介して、オフラインになっている可能性がある住宅所有者、出資者（または出資者を表す人工知能エンティティ）、および抵当権者／エクイティ保険会社（または抵当権者／エクイティ保険会社を表す人工知能エンティティ）に、携帯電話または他の受信デバイスによる電子メールまたはＳＭＳメッセージを介して、各当事者に適切なバージョンのデータをアラートする。

【0150】

契約エンジンは、支払いエンジンが、当業者に明らかとなるであろう方法を使用して、期限切れの抵当権支払いの状態を監視し、住宅所有者が、期限までに支払いを行わない意思を示しているか否かを出資者に通知し（１８２０）、住宅所有者と出資者の何れかが支払いを行うまで周期的に適切な通知を送信し、そして支払い完了メッセージ送信ユニットにより、契約エンジンの受信ユニットに送信する支払い完了メッセージを生成する（１８２２）ことを、可能にする（１８１８）。支払い完了メッセージは、少なくとも：（ｉ）支払いの事実；（ｉｉ）関連付けられている検証データ；（ｉｉｉ）支払額；（ｉｖ）支払いの日時；（ｖ）支払人の身元、を含む支払いデータを含む。支払いメッセージを受信した後、契約エンジンは、送信ユニットにより、ブロックチェーンに支払いデータを書き込むためのアクセス承認データと共に、住宅金融商品データブロックチェーンシステムのクエリを送信する。

【0151】

住宅金融商品データブロックチェーンシステムは、そのアクセスプロトコールを実装して、契約エンジンが、そのようなデータをブロックチェーンに書き込むために要求されるレベルの権限を有していることを検証する。検証後、契約エンジンの処理ユニットは、関連付けられている支払いデータを再定式化し、そして送信ユニットにより、それを住宅金融商品データブロックチェーンに書き込む（１８２４）。契約エンジンは、送信ユニットにより、アクセス承認データと共に住宅出資者データブロックチェーンシステムのクエリを送信して、抵当権の支払いを行う住宅所有者に対して、出資者から生じる住宅所有者の獲得エクイティポジションへの影響に関する関連データを抽出する（１８２６）。住宅金融商品データブロックチェーンシステムは、そのアクセスプロトコールを実装して、契約エンジンが、リクエストされたデータにアクセス可能であるか否かを決定する（１８２８）。アクセスが許可されていることを検証した後、契約エンジンは、受信ユニットを介して、このデータを受信し、そして契約エンジンに関連付けられている処理ユニットが、支払いを行う住宅所有者に対して、出資者による住宅所有者の獲得エクイティポジションへの影響を計算する。この計算が完了した後、契約エンジンは、処理ユニットにより、少なくとも以下を含む支払い完了データを作成する：（ｉ）抵当権の支払い金額；（ｉｉ）支払人の身元;（ｉｉｉ）住宅所有者が支払いをするまたは支払いをしないことによる住宅所有者の獲得エクイティ支払いへの影響；（ｉｖ）もし、住宅所有者が支払いをしなかった場合、住宅所有者が、将来、追加支払いをして、この支払をしなかったことによる獲得エクイティの減少を相殺することができるという事実；そして（ｖ）このような将来の追加の支払いが、異なる条件の下で行われるので、住宅所有者の獲得エクイティポジションを、もし、住宅所有者が抵当権の支払いを行った場合に有していたであろうレベルに復元するために必要な金額が、大概、支払われなかった抵当権の支払いより大となり得るという事実（１８３０）。処理ユニットは、さらに、住宅所有者、出資者、抵当権者／エクイティ保険会社にそれぞれ適した、３つのウェブ表示可能な支払い完了データのバージョンを作成する。契約エンジンは、送信ユニットにより、表示可能な３つのバージョンを、管理エンティティが運用するウェブサイトに送信し、各バージョンを対応する当事者（住宅所有者、出資者、抵当権／エクイティ保険会社）がアクセス可能となるようにする（１８３２）。契約エンジンは、送信ユニットを介して、オフラインになっている可能性がある、住宅所有者、出資者（または出資者を表す人工知能エンティティ）、および抵当権／エクイティ保険会社（または抵当権／エクイティ保険会社を表す人工知能エンティティ）に、携帯電話または他の受信デバイスによる電子メールまたはＳＭＳメッセージを介して、各当事者に適切なバージョンのデータを、アラートする。

【0152】

図１４に示されるように、契約エンジンは、送信ユニットにより、抵当権データエンジンの受信ユニットに支払い完了メッセージを送信する。このメッセージは、契約エンジンが、抵当権データブロックチェーンに抵当権支払いデータをすでに書き込んだという事実を含む。抵当権データエンジンは、送信ユニットにより、アクセス承認データと共に住宅金融商品データブロックチェーンシステムのクエリを送信して、少なくとも、支払い履歴、抵当権の支払い後の現在の元本の残高および毎月の支払い額、および住宅金融商品のデータブロックチェーンにある住宅の最新の運用評価に基づいたＬＴＶ比率のような、抵当権のステータスを更新するのに適切なデータを抽出する（１４０８）。

【0153】

住宅金融商品データブロックチェーンシステムは、そのアクセスプロトコールを実装して、抵当権データエンジンが、リクエストされたデータにアクセス可能であるか否かを決定する。アクセスが許可されていることを検証した後、抵当権データエンジンは、受信ユニットにより、このデータを受信し（１４１０）、そして抵当権データエンジンの処理ユニットが、この抵当権関連データを、ウェブサイトの表示に適した形式に編成して、表示可能な抵当権関連データのパッケージを作成する。抵当権データエンジンは、送信ユニットにより、表示可能な抵当権関連データを、住宅所有者、出資者、抵当権者／エクイティ保険会社がアクセス可能なウェブサイトに送信する（１４１２）。ここで、抵当権関連データは、受信された、表示可能な抵当権関連データを使用して更新される（１４１４）。抵当権データエンジンは、送信ユニットにより、住宅所有者、出資者（または出資者を表す人工知能エンティティ）、および抵当権者／エクイティ保険会社（または抵当権者／エクイティ保険会社を表す人工知能エンティティ）に、携帯電話または他の受信デバイスによる電子メールまたはＳＭＳメッセージを介して、更新された抵当権関連情報をアラートする。バランシングエンジンに組み込まれているバランシング機構は、もし、出資者が、住宅所有者が支払わなかった抵当権を支払わなければならない場合には、住宅所有者の獲得エクイティ（これ自体は、出資者の将来の義務）が、適切な額、削減されるであろうから、出資者が、完全な経済的補償を受け取ることを保証する。この要素は、出資者に、支払いを行うための適切なインセンティブを作成することにより、抵当権の支払いを容易にする。

【0154】

ここで説明したＭＭ－１住宅アレンジメントの実施形態は、複雑な取引に従事している複数の（住宅所有者と出資者ではない）第三者の環境であっても、本発明を備えるコンピュータ技術は、住宅所有者が、低コストでかつほぼ瞬時に、以下の多数の機能に従事するために、単一のウェブサイトと様々なＧＵＩに基づくページとにアクセスすることを可能にすることを示している：獲得エクイティレベルと管理している住宅金融商品に関する現在のデータの監視、基礎となる抵当権の状態の監視、支払いの不履行への対処、およびより一般的には、一連の財政的困難の間の支払いに対する救済の取得。これらの実施形態は、本発明を備えるコンピュータ技術が、どのように、第三者（上記の特定の例では、抵当権者／エクイティ保険会社と抵当権者）と住宅所有者および出資者が関与する複雑な対話を、単一のウェブサイトで低コストの統合プレゼンテーションを同時に可能にする態様で、促進するかを示す。本発明は、第三者が関与する複雑な補助機能が、効果的ではあるが目に見えない形で運用される、出資サービスウェブサイトでのプレゼンテーションの規模に匹敵する、住宅所有権のウェブプレゼンテーションを、可能にする。

【0155】

本発明が、ＭＭ-１構成および上記の例で提示されたものを超える第三者に関連する他の構成に対し、多くの他のタスクを可能にすることは、理解されるべきである。例えば、１つまたは複数の実施形態によれば、ＭＭ－１アレンジメントの場合、本発明を備えるコンピュータ技術は、低コストの統合されたウェブサイト表示を保証すると同時に、少なくとも以下を含む、ＭＭ－０に関する上記のタスクも可能にする：（ｉ）支払いレベルを変更することにより「借り換える」；（ｉｉ）出資者が保有するエクイティを返済することにより、融資の水準を下げる；（ｉｉｉ）獲得エクイティを出資者に売り戻すことにより、現在の市場条件での融資のレベルを上げる。住宅融資に適用可能な現在の技術を特徴付ける分断化、高コスト、及び連携の欠如は、ＭＭ－１住宅アレンジメント及び第三者を含む同様のアレンジメントの場合、並びにＭＭ－０の場合に、このシステムによって解決される。ＭＭ－０とＭＭ－１の両方のアレンジメントは、中立を実現するバランシング機構を組み込んだバランシングエンジンの出力から、直接、実装させることができる直接アレンジメントである。しかし、次の２つのセクションで示されるように、本発明は、より一般的である。

【0156】

（スケジュールされた獲得エクイティ住宅融資アレンジメント）
ＭＭ－０とＭＭ－１のアレンジメントは何れも、住宅所有者の獲得エクイティの結果を不確実なままにする。例えば、方程式（１）、（２）、（４）、および（５）から明らかなように、もし、住宅の暗黙の賃貸料が、住宅価格と比較して増加すると、住宅所有者は、百分率で低価格の獲得エクイティを得るであろう。別のアプローチは、獲得エクイティの発生スケジュールを事前に固定しておくことである。しかしながら、例えば、住宅所有者から出資者への支払いを変化させることにより、支払いのような別の残余口座が不確実性を取り上げない限り、獲得エクイティの発生について所望のスケジュールを作成しても、住宅融資アレンジメントは中立ではなくなるであろう。例えば、獲得エクイティの固定発生スケジュールが、純拠出要素の仮定値に基づいていて、そして賃貸料物価比率を除く全ての要素が、時間の経過に伴う仮定を満たしているとしよう。賃貸料物価比率が想定比率を上回る場合、契約は住宅所有者に有利になる。もし、賃貸料物価比率が想定比率を下回る場合、契約は出資者に有利になる。第１のケースでは、住宅所有者は、住宅にとどまり、今より市場を上回る取引を維持するインセンティブを有する。第２のケースでは、住宅所有者は、例えば、より有利な新しい固定された獲得エクイティ発生スケジュールを取得すると言うような、借り換えのインセンティブを有する。

【0157】

住宅所有者の前払いオプションによって生じるこの非対称性の問題は、住宅所有者が、それが出資者に有利な場合にはアレンジメントを捨て、しかしそれが住宅所有者に有利な場合にはアレンジメントを保有すると言うインセンティブを有していることを考慮して、出資者は、事前にプレミアムまたは解約手数料を請求する必要があることを意味する。住宅所有者は、状況が出資者に有利に振れる場合、状況と借り換えを監視しなければならない。中立性が失われるのは、市場の変動により、アレンジメントが住宅所有者または出資者の何れかに有利になり、前払いのオプションが重要な要素になるという結果が生じるためである。それにもかかわらず、リスクを嫌う何人かの住宅所有者にとって、獲得エクイティ発生スケジュールを修正することによってリスクを下げることの利点は、非対称性の問題に対処するために要求される追加の複雑さに関連する制限または料金を上回るであろう。

【0158】

このアレンジメントが中立ではないため、これは、ＭＭ－０またはＭＭ－１クラスの直接アレンジメントの場合のように、アレンジメントの結果を生成する中立バランシングエンジンを使用する直接アレンジメントとして実装することはできない。それにもかかわらず、本発明を備えるコンピュータ技術は、適切な中立バランシング機構を使用して、ＭＭ－０およびＭＭ－１の住宅融資アレンジメントの場合と同じ低コストの統合されたウェブサイトプレゼンテーションを作成することが出来る。

【0159】

住宅所有者が受け取る獲得エクイティの発生が、事前に、固定してスケジュールされていることを除いて、ＭＭ－０住宅融資アレンジメントの全ての基準を満たす、特定の住宅融資アレンジメントを検討しよう。住宅が売却され、そして契約が完了すると、このスケジュールされた成果は、ほとんどの場合、ＭＭ－０の基で住宅所有者に対してスケジュールされていない成果であったであろうものとは相違する。アレンジメントには、住宅所有者が受け取ったであろう金額から、住宅所有者が実際に受け取ったスケジュール金額を差し引いたものに等しいペイオフを得るポジションを取ることに同意する第三者が含まれているとしよう。一般に、このポジションは、これが、住宅所有者のスケジュールされていない残余額とスケジュールされた固定額のギャップをカバーするので、略して「残余バランシングポジション」または「ＲＢＰ: residual balancing position」と呼ばれることがある。ここでは、このアレンジメントの残余口座が、住宅のレバレッジされていないエクイティである獲得エクイティであるので、これを「エクイティバランシングポジション」または「ＥＢＰ: equity balancing position」と呼ぶ。ＥＢＰを保有する第三者は、住宅所有者が負担したであろう残余獲得エクイティ口座のリスクを吸収する。従って、このアレンジメントは、「ＥＢＰアレンジメント」と呼ばれる。

【0160】

ＥＢＰアレンジメントを説明するために、住宅所有者が、７年後に住宅を＄１００,０００で売却し、その時点で住宅所有者が獲得した、スケジュールされた獲得エクイティ額が２５％であるのに対し、スケジュールされていない額が３０％であったと仮定する。ＥＢＰには５％の差がある。住宅所有者は＄２５,０００を得、出資者は＄７０,０００、そしてＥＢＰを保有する第三者が＄５,０００を得る。もし、スケジュールされていない金額が３０％ではなく２３％であったとすると、住宅所有者は、＄２５,０００を得て、出資者は売り上げから＄７５,０００を受け取り、そしてＥＢＰを保有する第三者は、さらに＄２,０００ドルを出資者に支払い、出資者は＄７７,０００を得る。この場合、ＥＢＰを保有する第三者は、＄２,０００ドルの損失を被る。

【0161】

ＥＢＰアレンジメントは、次の特性によって規定される。
（１）スケジュールされていない獲得エクイティの結果は、ＭＭ－０の結果である。スケジュールされていない獲得エクイティの結果は、ＭＭ－０住宅融資アレンジメントの下で発生したであろう結果である。
（２）住宅所有者の獲得エクイティの結果は、スケジュールされている。住宅所有者は、保有期間に基づくスケジュールに従って、獲得エクイティの百分率を受け取る。このスケジュールは、住宅所有者と出資者の間の支払いのレベルの変更、住宅所有者による出資者からの追加のエクイティの購入、または住宅所有者による出資者への獲得エクイティの売却、のような如何なる変更もない場合の結果を決定する。
（３）ＥＢＰの結果は、住宅所有者の仮のスケジュールされていない獲得エクイティの結果から、スケジュールされた実際の結果を差し引いたものである。もし、スケジュールされていない成果が

【数78】

であり、スケジュールされた成果が百分率ポイントで

【数79】

であった場合、ＥＢＰを保有している第三者の結果は、百分率ポイントで

【数80】

になる。もし、結果が負である場合、ＥＢＰを保有する第三者は、対応する住宅価格の割合を売却時に出資者に支払う。もし、結果が正である場合、ＥＢＰを保有する第三者は、対応する売上高の割合を受け取る。
（４）出資者は、常にＭＭ－０（スケジュールされていない）の結果に等しい金額を受け取る。もし、ＥＢＰが売却時に正である場合、出資者は、ＭＭ－０アレンジメントの下で出資者が受け取ったであろう金額に等しい売却収益のシェアを受け取り、そしてＥＢＰを保有する第三者は、ＭＭ－０アレンジメントの下で住宅所有者のシェアであったであろう金額を住宅所有者と分け合う。もし、ＥＢＰが売却時に負の場合、住宅所有者は、スケジュールされていない量の獲得エクイティよりも多くを受け取り、残りの売却代金は、出資者に支払われる。ＥＢＰは、住宅所有者が、ＭＭ－０アレンジメントの下で受け取ったであろうスケジュールされていなかった金額を超える、住宅所有者が受け取った超過額に等しい金額を、出資者に支払う。この支払いと出資者の売り上げシェアとを組み合わせると、出資者が、ＭＭ－０アレンジメントの下で出資者が受け取っていたであろう金額を正確に受け取る結果が得られる。この特性は、もし、出資者の目標が、生の所有者が占有する不動産のリターン、住宅価格の上昇および純賃貸料のポートフォリオである場合、これは、ＭＭ－０アレンジメントで出資者のポジションが生み出すものであるので、非常に重要である。

【0162】

ＥＢＰアレンジメントは中立ではないので、このアレンジメントの実施形態は、通常、非対称性の問題（住宅所有者が、市場の変動によってアレンジメントが出資者により有利になる状況から借り換えを行う、そしてもし、それが住宅所有者に有利である場合、おそらくそれ以外の場合よりも長くアレンジメントを保有するインセンティブを有しているという事実）を緩和するいくつかの制限または料金により、最もうまく機能するであろう。ＥＢＰを保有する第三者は、２つのリスクを負っている。第１に、非対称問題から生じる「前払いリスク」がある。もし、市場の状況が、固定された獲得エクイティの発生がＥＢＰ保有者に有利になるという結果になる場合、住宅所有者は、アレンジメントを前払いして借り換えることができる。第２に、前払いがないと仮定しても、ＥＢＰは、獲得エクイティ発生率の変動に関連付けられているリスクを、住宅所有者から第三者のＥＢＰ保有者にシフトする。このアレンジメントの下で、住宅所有者は、獲得エクイティの累積の固定されたスケジュールを確保し、そしてＥＢＰは、それがなければ発生率の変動であったはずの「出資リスク」を正確に吸収する。もし、シフトされたリスクが、経済の系統的リスクと正の相関があるが、相関の方向とサイズは不明である場合、この出資リスクは、ＥＢＰを実行可能にするために何らかの形でプレミアムを要求することができる。

【0163】

非対称性の問題は、住宅所有者が取る可能性がある様々なアクションに関していくつかの問題を引き起こす。借り換えは明白なものである。ＥＢＰアレンジメントでは、借り換えは、出資者のエクイティポジションを買い取り、そしてこの買い取り金額を、新しいＥＢＰアレンジメント、従来の抵当権、その他に融資することと同じである。本発明を構成するコンピュータ技術によって可能になったＥＢＰを低コストでほぼ瞬時に借り換えることは、借り換えを非常に簡単かつ安価にすることにより、非対称性の問題（住宅所有者は、有利であるＥＢＰアレンジメントは保有しつつ、出資者に例え僅かでも有利であるＥＢＰアレンジメントを継続することを回避することが出来ること）を悪化させる。住宅所有者は、また、不利なＥＢＰアレンジメントを、別のＥＢＰアレンジメント以外の融資方法により置き換えることを選択することもできる。例えば、住宅所有者は、ＭＭ－０アレンジメントにシフトする、または出資者のエクイティを実質的に自己資金で購入した後、この住宅の全てのエクイティを保有することもできる。

【0164】

非対称性の問題の影響を受ける取引は、借り換えのみではない。獲得エクイティの発生の固定スケジュールが、想定パターンを仮定しているので、住宅所有者の拠出の当初の想定パターンを変更する如何なるアクションも、当初のＥＢＰアレンジメントを損なう。例えば、もし、住宅所有者が、出資者への支払いのレベルを下げることを選択した場合、獲得エクイティの発生率を下方に調整する必要があるであろう。既存の固定スケジュールは、置き換えなければならない。１つのアプローチは、既存のＥＢＰアレンジメントを単純に完了し、そして現在の市場状況に基づいて全く新しいものを作成することであろう。しかしながら、もし、市場のパラメータによって古いアレンジメントが出資者に有利になった場合、このシフトは、古いアレンジメントから抜け出すために戦略的に借り換えを行うことと同じである。第２の例は、住宅所有者が、出資者から追加のエクイティを購入することである。このアクションは、獲得エクイティ発生の既存の固定スケジュールの適用可能性を否定し、そしてＥＢＰアレンジメントを自己資金で部分的に置き換えることになり、これは、出資者に対して有利になるＥＢＰから、住宅所有者が、部分的に脱出することを可能にする。

【0165】

当業者には明らかになるであろう前払いリスクおよび出資リスクについてＥＢＰ保有者を補償するために、非対称問題に対処しそしてＥＢＰアレンジメント条件を調整する多くの方法がある。次のセクションで詳述する一実施形態は、別々にまたは組み合わせて使用することができる２つの方法を使用する。第１に、住宅所有者による幾つかのアクションは、一定額の獲得エクイティまたは現金の形をとることが出来る調整料という結果になる。例えば、住宅を売却する前に、現金化、それの借り換え、またはＥＢＰのポジションを調整することは、アクションの完了の一環として、住宅所有者の獲得エクイティの一部をＥＢＰ所有者に移管するという形の調整料金という結果になるかもしれない。請求額は、特定の住宅所有者の行動、ＥＢＰが作成されてからの時間、ＥＢＰがＥＢＰ保有者にとってどの程度有利であるかのような要因に依存させることができる。第３の要因に関しては、住宅所有者のアクションが、既に出資者に有利になっているＥＢＰアレンジメントの完了という結果になった時に、ＥＢＰ保有者が失う利益の一部または全てについて、住宅所有者がＥＢＰ所有者を補償するように、調整料を設定することができる。このように調整料を設定することは、ＥＢＰ保有者に対する対応する前払いリスクと共に、非対称性の問題の多くを解消することができる。

【0166】

第２の方法は、獲得エクイティの発生自体の固定スケジュールを調整することである。この方法は、住宅所有者が固定のスケジュールなしに直面したであろう稼得エクイティの発生率に関する不確実性を担うことから、ＥＢＰ保有者が直面する出資リスクに対処する上で特に価値がある。もし、出資リスクが、経済の系統的リスクと正の相関がある場合、それは、市場で価格設定され、そしてＥＢＰ出資者にはプレミアムを要求する。プレミアムを作成する１つの方法は、獲得エクイティのスケジュール率を下げることである。ＥＢＰ保有者は、スケジュールされていない成果からスケジュールされた成果を差し引いたものに等しい金額を認識し、そして今やスケジュールされた成果は低くなっているので、この削減は、ＥＢＰ保有者の期待リターンを増加させる。スケジュール率の低下は、期待リターンの増加が出資リスクの市場価格を正確にカバーするように、設定することができる。

【0167】

ベストプラクティスは、規制で要求されていない場合でも、どのようにしてそれらが計算されるかと共に、潜在的な調整料、そしてＥＢＰアレンジメントを確立する当初の契約条項の一部として、住宅所有者が獲得エクイティを獲得するための固定スケジュールを設定する方法を、開示することである。以下に詳述する実施形態では、これらの要素のデータは、本発明を備えるコンピュータ技術の動作を容易にするために、ブロックチェーンに記録されている。

【0168】

（獲得エクイティ発生がスケジュールされたＥＢＰ住宅融資アレンジメントの実装）
本発明がどのようにＥＢＰ住宅融資アレンジメントの実施形態を実装するかを説明するために、住宅所有者と、単一の出資者と、ＥＢＰを保有する単一の第三者とからなる単純なケースに焦点を当てる。本発明の実装の中核にあるのは、処理ユニットと、少なくとも１つの受信ユニットと、管理エンティティによって処理サーバ上で運用される少なくとも１つの送信ユニットとで実施されるバランシングエンジンである。バランシングエンジンは、住宅所有者と出資者の間の住宅アレンジメントをジョイントベンチャと見なして、それらの継続する拠出を、経時的に評価する。一実施形態では、出資者は最初に住宅全体に資金を提供し、住宅所有者は出資者に支払い、住宅所有者は固定資産税を支払い、住宅所有者はこの住宅を維持し、そして住宅所有者はこの住宅に居住する。

【0169】

この実施形態では、住宅所有者の純拠出額は、（ｉ）住宅所有者による出資者への利息の支払い、（ｉｉ）固定資産税の支払い、（ｉｉｉ）維持費用、および（ｉｖ）保険などの他の義務から、（ｖ）住宅に居住する価値である賃貸料（「暗黙の賃貸料」）として請求されるであろうものを差し引いたものになる。バランシング機構は、住宅所有者、出資者、およびＥＢＰ保有者の利益を照合するために残余口座を必要とする。この実施形態は、残余口座が、獲得エクイティと、ＭＭ－０アレンジメントの出資者が、住宅の売却または融資アレンジメントの完了に応じて、住宅所有者に支払われるであろう、住宅のレベレッジされていない利益とからなる、ＭＭ－０住宅融資アレンジメントに適切なバランシング機構を採用し、そしてこれらの支払いは、住宅所有者の純拠出が正になるように設定される。しかしながら、この実施形態は、ＭＭ－０住宅融資アレンジメントではない。これに代えて、住宅所有者は、事前に定められたスケジュールの下で、獲得エクイティを発生させる。住宅所有者の結果は、「スケジュールされた成果」、つまり、住宅売却収益に対する住宅所有者のシェアを表すある数の百分率ポイントである。バランシングエンジンの結果は、ＭＭ－０住宅融資アレンジメントにおける住宅所有者の実際の結果となるであろう百分率ポイントでの「スケジュールされていない成果」である。スケジュールされた成果とは異なり、スケジュールされていない成果は、事前にわかっていないが、契約期間中の様々な経済的パラメータの値に依存する。この実施形態では、スケジュールされていない成果は、ＥＢＰ保有者のリターンを計算するために使用される会計数量である。売却時、ＥＢＰ保有者は、もし、スケジュールされていない成果からスケジュールされた成果を引いた値が、ゼロ以上の場合に、住宅売却から、百分率ポイントで等しい収益を受け取る。代わりに、もし、スケジュールされた成果がスケジュールされていない成果よりも大きい場合、ＥＢＰは出資者に、スケジュールされた成果からスケジュールされていない成果を差し引いた百分率ポイントで等しい売上収益の割合を現金で支払う。

【0170】

この実施形態は、住宅所有者、出資者、およびＥＢＰ保有者の３つの当事者間の移行アレンジメントを含む。住宅所有者が、少なくとも以下を含む特定の変更を開始すると、移行アレンジメントが有効になる：（ｉ）住宅所有者が出資者に行う支払いのレベルを変更する；（ｉｉ）出資者からエクイティを購入する；（ｉｉｉ）出資者にエクイティを売却する；（ｉｖ）古いアレンジメントおよび住宅所有者の獲得エクイティ発生の、関連付けられている固定スケジュールを完了することにより、住宅所有者の獲得エクイティ発生の新規かつ異なった固定スケジュールを含む市場条件に基づく新しいＥＢＰアレンジメントに有利になるように、ＥＢＰアレンジメントを借り換える；または（ｖ）古いアレンジメントおよび住宅所有者の獲得エクイティ発生の、関連付けられている固定スケジュールを完了することにより、住宅所有者の獲得エクイティ発生スケジュールが固定されていないが、ＥＢＰアレンジメントの下でのスケジュールされていない成果となるであろうものに等しいＭＭ－０住宅融資アレンジメントに有利になるように、ＥＢＰアレンジメントを借り換える。これらの変更は、通常、既存のＥＢＰアレンジメントを完了し、あたかも住宅が売却されたかのようにエクイティを調整し、次で、ＥＢＰ保有者が保有するエクイティクレジットまたはデビットを閉じる現金取引が、出資者と住宅所有者に対するエクイティ調整を作成することを要求する。もし、ＥＢＰ保有者が、エクイティクレジットを保有している場合、ＥＢＰ保有者は、住宅の運用評価時に、対応するエクイティポジションを出資者に売却する。もし、ＥＢＰ保有者が、エクイティデビットを保有している場合、ＥＢＰ保有者は、住宅所有者にエクイティを支払う義務がある。この場合、ＥＢＰ保有者は、移行同意の目的で、住宅の運用評価時に出資者から必要なエクイティシェアを購入し、次いで、この必要なエクイティシェアを住宅所有者に譲渡する。住宅所有者と出資者に対するこのプロセスから生じるエクイティは、既存のＥＢＰアレンジメントを置き換える、新しいＥＢＰまたはＭＭ－０アレンジメントの基本エクイティになる。この移行同意は、当事者に、必要な移行現金およびエクイティ移転を行うことを義務付ける。この実施形態は、それらがほぼ瞬時になるであろうことを目標として、現金およびエクイティの移転を容易にするコンピュータ技術を含む。

【0171】

図１９は、開始されたＥＢＰアレンジメントに関連してブロックチェーンシステムを更新するためのプロセスを示す流れ図（１９００）である。この実施形態では、管理エンティティによって制御される処理サーバ上で運用される契約エンジンが、少なくとも住宅所有者、出資者、およびＥＢＰ保有者の間の住宅融資アレンジメントを、開始、実装、実施、および更新し、そしてＥＢＰ住宅融資アレンジメントを管理する契約情報の作成、更新、およびアクセスを含む機能を実行する。この契約エンジンは、少なくとも１つの処理ユニット、少なくとも１つの受信ユニット、および少なくとも１つの送信ユニットにより具体化される。この契約エンジンへの入力データは、少なくとも、ＥＢＰの住宅融資アレンジメントを管理する契約条項をエンコードするデータを含む、住宅金融商品データブロックチェーンに存在する。ＥＢＰ住宅アレンジメントが開始されると（１９０２）、管理エンティティは、初期契約データを契約エンジン処理サーバの受信ユニットに送信する。この初期契約データには、少なくとも、次の情報：（ｉ）契約の初期当事者の名前、住所、および連絡先情報；（ｉｉ）全ての契約条件；（ｉｉｉ）少なくとも、所有権と所有権保険の証拠を含む、住宅の購入または所有権に関する情報、が含まれる。

【0172】

契約条件には、少なくとも次のもの：（ｉ）住宅所有者に有利な、獲得エクイティ発生の初期の固定スケジュール；（ｉｉ）住宅所有者と出資者の初期のエクイティ保有；そして（ｉｉｉ）もし、住宅所有者が、少なくとも、アレンジメントの借り換え、出資者への支払いのレベルの変更、または出資者のエクイティの幾つかの購入を含むアクション行動をとった場合に適用される任意の調整料、が含まれる。契約エンジンは、処理ユニットにより、初期契約データを、住宅金融商品データブロックチェーンへの書き込みに適した形式にフォーマットする（１９０４）。契約エンジンは、送信ユニットにより、住宅金融商品データブロックチェーンシステムのクエリをアクセス承認データと共に送信して、フォーマットされた契約データをブロックチェーンに書き込む許可を確保する。住宅金融商品データブロックチェーンシステムは、そのアクセスエンジンを実装して、契約エンジンが、要求される許可を有していることを検証する。受信ユニットにより、検証の確認を受信した後、契約エンジンは、送信ユニットにより、初期契約データをブロックチェーンに書き込み、ブロックチェーンに新しい住宅融資アレンジメントのレコードを作成する（１９０６）。

【0173】

図２０は、スケジュールされていない成果に関連してバランシングエントリデータをブロックチェーンシステムに追加するプロセスを示すフロー図（２０００）である。実施形態では、管理エンティティによって制御される処理ユニットに存在するバランシングエンジンが、仮想のスケジュールされていない成果（ＭＭ－０住宅アレンジメントの下での住宅所有者の獲得エクイティの累積）の時系列を、作成および更新する。バランシングエンジンへの入力データは、住宅金融商品データブロックチェーンに存在する。このデータには、少なくとも、出資者への住宅所有者の支払いを含む全ての拠出要素の時系列が含まれている。管理エンティティまたはそれを表す人工知能エンティティは、周期的に、メッセージをバランシングエンジンの受信ユニットに送信して、現在のスケジュールされていない仮想の結果の、住宅金融商品データブロックチェーンへのバランシングエントリを開始する。バランシングエンジンは、送信ユニットにより、アクセス承認データと共に住宅金融商品データブロックチェーンシステムのクエリを送信して、仮想のＭＭ－０住宅融資アレンジメントの下で獲得エクイティを計算するための管理アルゴリズム（これ自体は、住宅金融商品データブロックチェーンにエンコードされている）を含む、出資および他の要素に関する関連データを抽出する（２００４）。

【0174】

住宅金融商品データブロックチェーンシステムは、そのアクセスプロトコールを実装して、バランシングエンジンが、リクエストされたデータにアクセス可能であることを検証する。検証後、バランシングエンジンは、受信ユニットにより、リクエストされたデータを受信し、そしてバランシングエンジンに関連付けられている処理ユニットは、スケジュールされていない成果、住宅所有者の仮想の獲得エクイティバランスを、関連付けられている数量と共に、更新する。関連付けられている数量は、もし、住宅が、住宅金融商品データブロックチェーンに記録されている現在の運用評価で売却された場合に、住宅所有者、出資者、およびＥＢＰ保有者が、実現するまたは支払うであろう百分率シェアと金額を、少なくとも含む、スケジュールされていない成果を入力として使用する（２００６）。バランシングエンジンは、送信ユニットにより、住宅金融商品データブロックチェーンシステムのクエリをアクセス承認データと共に送信して、更新された、スケジュールされていない成果に関連付けられている数量を、ブロックチェーンに書き込む許可を確保する。

【0175】

住宅金融商品データブロックチェーンシステムは、アクセスプロトコールを実装して、バランシングエンジンが、要求される許可を有していることを検証する。検証後、バランシングエンジンは、送信ユニットにより、更新されたスケジュールされていない成果と関連付けられている数量とを、住宅金融商品データブロックチェーンに書き込む（２００８）。バランシングエンジンは、送信ユニットにより、更新されたスケジュールされていない成果と関連付けられている数量とを、管理エンティティによって制御されそして住宅所有者、出資者、およびＥＢＰ所有者が、アクセス可能であるウェブサイトに、送信する。このウェブサイトでは、更新された値が、関連付けられている数量と共に報告される（２０１０）。バランシングエンジンは、送信ユニットを介して、オフラインになっている可能性がある住宅所有者、出資者（または出資者を表す人工知能エンティティ）、およびＥＢＰ所有者（またはＥＢＰ所有者を表す人工知能エンティティ）に、携帯電話または他の受信デバイスによる電子メールまたはＳＭＳメッセージを介して、更新されたスケジュールされていない成果および関連付けられている数量をアラートする。

【0176】

一実施形態は、図７を参照して理解することが出来る。スケジュールされていない成果の時系列の作成の基礎となるバランシングの運用のための入力データは、住宅金融商品データブロックチェーンに存在し、そして管理エンティティによって制御される１つ以上のサーバにある複数のデータエンジンによって、生成されそして更新される。各データエンジンは、少なくとも１つの処理ユニット、少なくとも１つの受信ユニット、少なくとも１つの送信ユニット、および少なくとも１つのデータベースを含む。各データエンジンは、少なくとも１つのデータパラメータの少なくとも１つの時系列を作成、収集、更新、処理、格納、および通信する目的で運用される。評価エンジンは、管理エンティティによって制御される処理サーバ上で運用されるデータエンジンであり、これは、住宅金融商品データブロックチェーンへの書き込みにより融資を受ける住宅の住宅価値の時系列を、作成および更新する。評価エンジンは、住宅評価リクエストに対応するデータリクエストを受信する（７０２）。この評価エンジンは、１つ以上の受信ユニットにより、第三者評価をクエリ（７０４）を介して収集する。評価エンジンは、送信ユニットにより、これらの評価をデータベースにエンコードする（７０６）。評価エンジンは、処理ユニットにより、適用出来る場合には（７０８）、１つ以上の非第三者評価（７１０）を生成し、そして１つ以上の統計手続きを使用して、第三者評価と非第三者評価の両方（７１２）をバランシングエンジンおよび契約エンジンで使用する運用評価に結合する。評価エンジンは、送信ユニットにより、アクセス承認データと共に、住宅金融商品データブロックチェーンシステムのクエリを送信して、更新された運用評価、計算方法、および他の更新された評価データをブロックチェーンに書き込むためのアクセス許可を確保する。

【0177】

住宅金融商品データブロックチェーンシステムは、そのアクセスプロトコールを実装して、バランシングエンジンが、要求される許可を有していることを検証する。検証後、評価エンジンは、送信ユニットにより、更新された運用評価を、タイムスタンプと計算のレコードと共に書き込む（７１４）。この運用評価は、少なくとも、第三者評価と非第三者評価、非第三者評価の計算に使用される方法論、および住宅金融商品のデータブロックチェーンに関する更新された運用評価および他の評価を計算するために使用される方法論を含む。評価エンジンは、データメッセージ（７１８）を生成しそして送信ユニットを介して、第三者および非第三者評価と共に、少なくとも新しい運用評価を、管理エンティティによって制御されそして住宅所有者、出資者、およびＥＢＰ所有者がアクセス可能なウェブサイトに送信する（７２０）。このウェブサイトでは、これらの評価が報告される。評価エンジンは、送信ユニットを介して、オフラインになっている可能性がある、住宅所有者、出資者（または出資者を表す人工知能エンティティ）、およびＥＢＰ所有者（またはＥＢＰ所有者を表す人工知能エンティティ）に、もし、彼らが、運用評価の更新を、一般的にまたは特定の値が実現されたときに、既にリクエストしていた場合、新しい運用評価を、携帯電話または他の受信デバイスによる電子メールまたはＳＭＳメッセージを介してアラートする。

【0178】

少なくとも暗黙の賃貸料、減価償却費、固定資産税の負債を含む他のデータ要素は、評価エンジンと同様の方法で運用される他のデータエンジンによって管理される。

【0179】

図２１を参照すると、実施形態を理解することが出来る。図２１は、例示的な実施形態に従って、支払い変更リクエストに関連して、ブロックチェーンシステムから契約データを抽出し、オファーデータアンサンブルを計算し、そして計算されたオファーデータアンサンブルをブロックチェーンシステムに書き込むプロセスを示す流れ図（２１００）である。住宅所有者は、出資者への支払いのレベルを変更して、住宅融資アレンジメントを効果的に借り換えたいと思うかもしれない。住宅所有者は、管理エンティティによって運用されているウェブサイトにアクセスし、そして１つ以上の潜在的な新しい支払いレベルを指定し、そして送信ユニットにより、管理エンティティによって制御される契約エンジンの受信ユニットに送信される、少なくともリクエストと潜在的な新しいレベルとを備えるメッセージを生成して、支払いレベルの変更をリクエストする（２１０２）。契約エンジン処理ユニットは、送信ユニットにより、アクセス承認データと共に、住宅金融商品データブロックチェーンシステムのクエリを送信して、住宅所有者が興味を有する新しい各支払いレベルに関連付けられている住宅所有者へのオファーを生成するための関連する基礎データを抽出する（２１０４）。関連付けられている基礎データは、少なくとも必要な契約情報と、スケジュールされていない成果の最新値と、スケジュールされた成果の最新値と、住宅の運用評価の最新値と、スケジュールされていない成果を更新するためにバランシング計算に入れられるパラメータの最新値とを、含む。必要な契約情報には、少なくとも、住宅所有者の獲得エクイティ発生の新しい固定スケジュールを計算するために必要なルールとアルゴリズム、および住宅所有者が提出する各潜在的な新しい支払いレベルに関連付けられている調整料の値が含まれる。

【0180】

住宅金融商品データブロックチェーンシステムは、そのアクセスプロトコールを実装して、契約エンジンが、リクエストされたデータにアクセス可能であることを検証する。検証後、契約エンジンは、受信ユニットを介して、このデータを受信し（２１０６）、そして契約エンジンに関連付けられている処理ユニットが、契約ルールとアルゴリズムを使用して、提案された新しい支払いレベルごとに、少なくとも住宅所有者の獲得エクイティ発生の新しい固定スケジュール、および任意の調整料、および支払レベルの変更に伴う、現在のＥＢＰアレンジメントからＭＭ－０アレンジメントへのシフトに対する調整料、から構成されるオファーデータを計算する（２１０８）。契約エンジンは、少なくともオファーデータと住宅所有者に対する応答リクエストを含むオファーメッセージを、生成し（２１１０）、そして送信ユニットにより、このオファーメッセージを、管理エンティティによって制御されかつオファーデータが表示される、住宅所有者がアクセス可能なウェブサイトに、送信する（２１１２）。この応答リクエストは、住宅所有者が提示された条件に応答する期限を示す。契約エンジンは、送信ユニットを介して、オフラインになっている可能性がある住宅所有者に、オファーと、応答の期限を含む応答のリクエストとを、携帯電話または他の受信デバイスによる電子メールまたはＳＭＳメッセージを介して、アラートする。契約エンジンは、処理ユニットにより、少なくとも以下：（ｉ）オファーデータ；（ｉｉ）オファーを生成するプロセスの第１の手順として、住宅金融商品データブロックチェーンから抽出された基礎データ；（ｉｉｉ）オファーが最初に公開された日付と時刻；（ｉｖ）オファーに対応するための期限の表示、から構成される住宅金融商品データブロックチェーンへの書き込みに適したオファーデータアンサンブルを計算する（２１１４）。契約エンジンは、送信ユニットにより、住宅金融商品データブロックチェーンのクエリをアクセス承認データと共に送信して、オファーデータアンサンブルをブロックチェーンに書き込むための許可を確保する。住宅金融商品データブロックチェーンシステムは、そのアクセスエンジンを実装して、契約エンジンが、要求される許可を有していることを検証する。検証後、契約エンジンは、送信ユニットにより、オファーデータアンサンブルを住宅金融商品データブロックチェーンに書き込む（２１１６）。

【0181】

図２２を参照すると、実施形態を理解することが出来る。図２２は、例示的な実施形態に従って、要求される配分を計算し、銀行振込を実行させ、そして受諾された支払いオファーに関連するブロックチェーンシステムを更新するプロセスを示す流れ図（２２００）である。もし、住宅所有者が、オファーの１つを受諾したい場合、住宅所有者は、管理エンティティが運用するウェブサイトにアクセスし、そして住宅所有者の所望のオファーの選択を示し、そして住宅所有者の身元を検証するセキュリティプロトコルを通過して、少なくとも、送信ユニットにより契約エンジンの受信ユニットに送信される、所望の選択の受諾の表示、身元の検証の確認、および受諾されたオファーの条件を備えるメッセージを生成する（２２０２）。契約エンジンは、処理エンジンにより、既存のＥＢＰアレンジメントの完了プロセスを開始する（２２０４）。最初の手順として、契約エンジン処理ユニットは、送信ユニットにより、住宅金融商品データブロックチェーンシステムのクエリをアクセス承認データと共に送信して、ブロックチェーンからオファーデータアンサンブルを抽出する（２２０６）。

【0182】

住宅金融商品データブロックチェーンシステムは、そのアクセスエンジンを実装して、契約エンジンが、リクエストされたデータにアクセス可能であることを検証する。検証後、契約エンジンは、受信ユニットを介して、オファーデータアンサンブルを受信する。オファーデータアンサンブルは、オファーの時点での変数の最新の値を含み、この実施形態では、これらの値が、受諾されたオファーの実装を決定する。

【0183】

この実施形態では、完了プロセスは、契約エンジンを用いて、処理ユニットによりＥＢＰアレンジメントを閉じ、あたかも住宅が売られたかのような配分を計算する。契約エンジンは、オファーデータアンサンブルのパラメータ値を使用して、仮想の売却に基づいて、いくつかの手順により、ＥＢＰ保有者のエクイティクレジットまたはデビットを計算する（２２０８）。最初に、契約エンジンは、オファーデータアンサンブルからのスケジュールされた成果とスケジュールされていない成果の値を比較する。もし、スケジュールされていない成果が、スケジュールされた成果よりも大きい場合、その差は、「ＥＢＰ超過」、つまり住宅が売却された場合の収益に対するＥＢＰ保有者のシェアを表す百分率ポイントの数である。もし、スケジュールされた成果が、スケジュールされていない成果よりも大きい場合、正の数値である差は、「ＥＢＰ赤字」であり、住宅所有者に対するＥＢＰ保有者のエクイティ義務を表す百分率ポイントの数である。また、住宅所有者がＥＢＰ保有者に支払うべきエクイティを表す数百分率のポイントである調整料もある可能性がある。もし、ＥＢＰ超過がある場合、ＥＢＰ超過と調整料金の合計は、「ＥＢＰエクイティクレジット」と等しくなる。もし、ＥＢＰの赤字は、あるが、それが調整手数料よりも少ない場合、調整料金からＥＢＰの赤字を差し引いた額が、ＥＢＰのエクイティクレジットに等しくなる。もし、調整料を超えるＥＢＰ不足がある場合、ＥＢＰ不足から調整料を差し引いた値が、正の数値である「ＥＢＰエクイティデビット」に等しくなる。

【0184】

完了プロセスから出現する新しい開始エクイティポジションは、（ｉ）住宅所有者の場合、オファーデータアンサンブルからのスケジュール結果から、オファーデータアンサンブルからの調整料を引いたものに等しい百分率ポイントの数；および（ｉｉ）出資者の場合、１００から、住宅所有者の百分率ポイントシェアを引いた数に等しい百分率ポイントの数である。この配分に到達するには、ＥＢＰエクイティクレジットまたはＥＢＰエクイティデビットを現金で決済する必要がある。

【0185】

もし、ＥＢＰエクイティクレジットがある場合、オファーデータアンサンブルに記録されている運用住宅評価で該当するエクイティを購入することによりＥＢＰエクイティクレジットを決済するために、契約エンジンは、処理ユニットにより、出資者がＥＢＰ保有者に支払う必要があるであろうバイアウト金額を計算する（２２１０）。契約エンジンは、少なくとも、（ｉ）出資者が購入している住宅エクイティの百分率シェア；（ｉｉ）住宅が評価される運用評価；（ｉｉｉ）バイアウト金額；（ｉｖ）ＥＢＰ所有者に支払う指示、を含むバイアウト請求データを含む出資者バイアウト請求メッセージを作成する。契約エンジンは、送信ユニットにより、出資者バイアウト要求メッセージを、出資者が事前に指定した支払いエンジンの受信ユニットに送信する（２２１２）。支払いエンジンは、出資者からＥＢＰエクイティ保有者の口座への銀行振込を作成し（２２１４）、そして支払い確認メッセージを生成し（２２１８）、そして支払い確認メッセージを送信ユニットにより契約エンジンの受信ユニットに送信する（２２２０）。この支払い確認メッセージは、少なくとも、契約エンジンが、当業者には周知の手続きにより支払いが既になされていることを確認するのに十分なデータを含む。処理エンジンを介した契約エンジンは、少なくとも以下を含む移行データのパッケージを準備する（２２１６）：（ｉ）データを伴うＥＢＰエクイティクレジット金額およびその計算に使用される方法論；（ｉｉ）出資者によるＥＢＰ保有者への支払いの事実と確認；（ｉｉｉ）完了プロセスから現れる出資者および住宅所有者の新しく開始されるエクイティポジション；（ｉｖ）既存のＥＢＰアレンジメントが完了し、そして新しいＥＢＰアレンジメントまたは新しいＭＭ－０アレンジメントが開始するという事実；（ｖ）移行の日時；（ｖｉ）もし、新しいアレンジメントがＥＢＰアレンジメントである場合、住宅所有者の獲得エクイティ発生の新しい固定スケジュールを含む、オファーデータアンサンブルに記述されている、対応するオファーと一致する新しいアレンジメントの仕様。契約エンジンは、送信ユニットにより、アクセス承認データと共にクエリを、住宅金融商品データブロックチェーンシステムに送信して、アレンジメントのシフトを実行しそしてブロックチェーンに移行データを書き込むための許可を確保する。

【0186】

住宅金融商品データブロックチェーンシステムは、そのアクセスプロトコールを実装して、契約エンジンが、要求される許可を有していることを検証する。検証後、契約エンジンは、送信ユニットにより、移行データを住宅金融商品データブロックチェーンに書き込んで（２２２２）、新しいアレンジメントへのシフトを実現する。契約エンジンは、住宅所有者、出資者、およびＥＢＰ保有者にそれぞれ適した、移行データの３つのウェブ表示可能バージョンを作成する（２２２４）。契約エンジンは、送信ユニットにより、３つの表示可能なバージョンを管理エンティティが運用するウェブサイトに送信して、対応する当事者（住宅所有者、出資者、およびＥＢＰ保有者）が各バージョンにアクセスできるようにする（２２２６）。契約エンジンは、送信ユニットを介して、オフラインになっている可能性がある住宅所有者、出資者（または出資者を表す人工知能エンティティ）、およびＥＢＰ所有者（またはＥＢＰ所有者を表す人工知能エンティティ）に、携帯電話または他の受信デバイスによる電子メールまたはＳＭＳメッセージを介して、各当事者に適するバージョンでデータをアラートする。契約エンジンは、送信ユニットにより、ウェブサイトの一般的にアクセス可能な領域とアクセスが制限された領域の両方をウェブサイトに更新させる命令と共に、移行データを、管理エンティティによって制御されかつ住宅所有者、出資者、およびＥＢＰ所有者がアクセス可能なウェブサイトに、送信して、移行データ内にエンコードされている新しいアレンジメントの詳細に基づいて、新しいアレンジメントを表示する。

【0187】

もし、ＥＢＰエクイティデビットがある場合、契約エンジンは、処理ユニットにより、オファーデータアンサンブルに記録されている運用住宅評価で、出資者から、関連付けられているエクイティを購入し、そしてそれを住宅所有者に移転することにより、ＥＢＰ保有者が、ＥＢＰエクイティデビットを決済するために出資者に支払う必要があるであろうバイアウト金額を計算する（２２１０）。契約エンジンは、少なくとも、（ｉ）ＥＢＰ保有者が購入している住宅エクイティの百分率シェア；（ｉｉ）住宅が評価される運用評価；（ｉｉｉ）バイアウト金額； （ｉｖ）出資者への支払い指示、を含むバイアウト請求データを含むＥＢＰバイアウト請求メッセージを作成する。契約エンジンは、送信ユニットにより、ＥＢＰバイアウト要求メッセージを、ＥＢＰ保有者が事前に指定した支払いエンジンの受信ユニットに送信する（２２１２）。支払いエンジンは、ＥＢＰ所有者から出資者の口座への銀行振込を作成し（２２１４）、支払い確認メッセージを生成し（２２１８）、そして支払い確認メッセージを、送信ユニットにより、契約エンジンの受信ユニットに送信する（２２２０）。この支払い確認メッセージは、少なくとも、契約エンジンが、当業者には周知の手続きにより支払いが既になされていることを確認するのに十分なデータを含む。契約エンジンは、処理ユニットにより、少なくとも以下を含む移行データのパッケージを準備する（２２１６）：（ｉ）データを伴うＥＢＰエクイティ負債金額およびその計算に使用される方法論；（ｉｉ）ＥＢＰ保有者による出資者への支払いの事実と確認；（ｉｉｉ）完了プロセスから現れる出資者および住宅所有者の新しく開始されるエクイティポジション；（ｉｖ）既存のＥＢＰアレンジメントが完了し、そして新しいＥＢＰアレンジメントまたは新しいＭＭ－０アレンジメントが開始するという事実；（ｖ）移行の日時；（ｖｉ）もし、新しいアレンジメントがＥＢＰアレンジメントである場合、住宅所有者の獲得エクイティ発生の新しい固定スケジュールを含む、オファーデータアンサンブルに記述されている、対応するオファーと一致する新しいアレンジメントの仕様。契約エンジンは、送信ユニットにより、アクセス承認データと共にクエリを、住宅金融商品データブロックチェーンシステムに送信して、アレンジメントのシフトを実行しそしてこのブロックチェーンに移行データを書き込むための許可を確保する。

【0188】

住宅金融商品データブロックチェーンシステムは、そのアクセスプロトコールを実装して、契約エンジンが、要求される許可を有していることを検証する。検証後、契約エンジンは、送信ユニットにより、移行データを住宅金融商品データブロックチェーンに書き込み（２２２２）、新しいアレンジメントへのシフトを実現する。契約エンジンは、住宅所有者、出資者、およびＥＢＰ保有者にそれぞれ適した、移行データの３つのウェブ表示可能なバージョンを作成する（２２２４）。契約エンジンは、送信ユニットにより、３つの表示可能なバージョンを管理エンティティが運用するウェブサイトに送信し、各バージョンを、対応する当事者（住宅所有者、出資者、およびＥＢＰ保有者）がアクセス可能となるようにする（２２２６）。契約エンジンは、送信ユニットを介して、オフラインになっている可能性がある、住宅所有者、出資者（または出資者を表す人工知能エンティティ）、およびＥＢＰ所有者（またはＥＢＰ所有者を表す人工知能エンティティ）に、携帯電話または他の受信デバイスによる電子メールまたはＳＭＳメッセージを介して、データを、各当事者に適切であるバージョンで、アラートする。契約エンジンは、送信ユニットにより、移行データにエンコードされた新しいアレンジメントの詳細に基づいて、新しいアレンジメントを表示するために、ウェブサイトに、一般的にアクセス可能な領域とアクセスが制限されている領域の両方を更新させる命令と共に、移行データを、管理エンティティによって制御されかつ住宅所有者、出資者、およびＥＢＰ所有者がアクセス可能なウェブサイトに、送信する。

【0189】

１つまたは複数の実施形態では、既存のＥＢＰアレンジメントの完了に関与する同様のプロセスおよび３つの当事者者（住宅所有者、出資者、およびＥＢＰ保有者）間の適切な移行アレンジメントを使用して、住宅所有者によりなされる出資者への支払いレベルの修正以外の、以下に挙げる変更を、住宅所有者に実行させることができる：（ｉ）出資者からエクイティを購入する；（ｉｉ）出資者にエクイティを売却する；（ｉｉｉ）住宅所有者が獲得した獲得エクイティ発生の新しくかつ異なる固定スケジュールに関与する市場条件に基づいて、新しいＥＢＰアレンジメントが有利になるように、古いアレンジメントおよび住宅所有者の獲得エクイティ発生の、関連付けられている、固定スケジュールを完了することにより、ＥＢＰアレンジメントを借り換える；または（ｉｖ）住宅所有者の獲得エクイティの発生スケジュールが、固定されてはいないが、ＥＢＰアレンジメントの下でスケジュールされていない成果となるであろうものと等しいＭＭ－０住宅融資アレンジメントが有利になるように、古いアレンジメントおよび住宅所有者の獲得エクイティ発生の、関連付けられている、固定スケジュールを完了することにより、ＥＢＰ合意を借り換える。一実施形態では、これらの変更は、既存のＥＢＰアレンジメントを完了し、住宅が売却されたかのようにエクイティシェアを調整し、そして次にＥＢＰ保有者が保有するエクイティクレジットまたはデビットを閉じる現金取引を調整し、住宅所有者と出資者に対するこのプロセスから生じるエクイティシェアが、既存のＥＢＰアレンジメントを置き換える新しいＥＢＰまたはＭＭ－０アレンジメントの基本エクイティシェアとなるように、住宅所有者と出資者に対して対応するエクイティ調整を作成する、手順と同じ手順を、必要とするであろう。

【0190】

今説明したＥＢＰ住宅アレンジメントの実施形態は、中立ではない住宅融資の場合でも、本発明を備えるコンピュータ技術により、住宅所有者が、単一のウェブサイトおよび様々なＧＵＩベースのページにアクセスして、以下を含む多数の機能を低コストでほぼ瞬時に処理することができることを示している：（ｉ）獲得エクイティレベルを監視し、そして獲得エクイティの将来の発生を管理する固定スケジュールを閲覧する；（ｉｉ）住宅の評価のようなパラメータをリアルータイムで監視する；（ｉｉｉ）出資者への支払いのレベルを変更する条件と結果について調査しかつ閲覧する；（ｉｖ）必要に応じて、このような変更を行う；（ｖ）少なくとも、以下：（a）出資者からエクイティを購入する；（b）出資者にエクイティを売却する；（ｃ）住宅所有者の獲得エクイティ発生の新規かつ異なった固定スケジュールに関与する市場条件に基づく新しいＥＢＰアレンジメントのために、古いアレンジメントおよび住宅所有者の獲得エクイティ発生の関連付けられている固定スケジュールを完了することにより、ＥＢＰアレンジメントを借り換える；または（ｄ）住宅所有者の獲得エクイティ発生スケジュールが、固定されていないが、ＥＢＰアレンジメントの下でのスケジュールされていない成果となるであろうものに等しいＭＭ－０住宅融資アレンジメントが有利になるように、古いアレンジメントと住宅所有者の獲得エクイティ発生の関連付けられている固定スケジュールとを完了することにより、ＥＢＰアレンジメントを借り換える、（ｖｉ）必要に応じて、このような変更を行う。これらの実施形態は、本発明を備えるコンピュータ技術が、如何にして、少なくとも１つの第三者（上記の特定の例では、ＥＢＰ保有者）並びに住宅所有者及び出資者が関与する複雑な対話を、同時に、単一のウェブサイトでの低コスト統合プレゼンテーションを可能にする方法で、実行するかを示す。本発明は、第三者が関与する複雑な補助機能が「内部で」運用する出資サービスのウェブサイトでのプレゼンテーションの範囲に匹敵する、住宅所有のウェブプレゼンテーションを可能にする。本発明は、ＥＢＰアレンジメントが中立ではなくかつ直接アレンジメントではない場合でも、バランシング機構が、住宅所有者、出資者、および住宅アレンジメントに参加している第三者の間の配分を直接作成するＭＭ－０およびＭＭ－１アレンジメントに対するその実装と同様の方法で同じことを行う。当業者には、本発明を備えるコンピュータ技術が、直接アレンジメントではなく、中立でない多種多様な他の住宅アレンジメントに対しても、同じ結果を達成できることは明らかであろう。

【0191】

（出資者間の取引）
一実施形態では、基礎となる住宅の所有権は、住宅所有者、パートナーシップ、または出資者が、所有権を持たないが、契約上のポジションを有する別の形態によって保有される。この実施形態では、出資者が、不動産自体の譲渡を必要とせずに、ポジションを互いに購入、売却および交換することが出来るように、契約上の権利を設定することができる。出資者の利益の単純な移転に加えて、この機能により、ポートフォリオファンド間の特定のポートフォリオバランシング取引を、出資者がより簡単に実行することが可能になる。出資者が、ポートフォリオのファンドであるか否かにかかわらず、本発明を備えるコンピュータ技術は、低コストでほぼ瞬時に多数の監視およびアクション機能を実行するために、本発明を備えるコンピュータ技術により提供される、住宅所有者が、単一のウェブサイトおよび様々なＧＵＩベースのページへのアクセスの中断を経験しない、住宅所有者による実質的な関与を必要とせずに、出資者間の低コストで効率的な移転を可能にすることができる。

【0192】

（出資者の取引プラットフォーム）
本発明が出資者取引プラットフォームの実施形態をどのように実装するかを説明するために、我々は、各住宅の可能な住宅融資アレンジメントを、単一の住宅所有者と単一の出資者がいて、それぞれがレバレッジされていないエクイティ持分を保有し、そして抵当権などの形での第三者の参加はないＭＭ－０アレンジメントに限定する。このイノベーションには、１つ以上の実施形態が含まれ、ここでは、この出資者取引プラットフォームは、ＭＭ－０アレンジメント以外の住宅融資アレンジメントに対し運用され、そして単一の住宅に対して複数の住宅所有者、単一の住宅に対して複数の出資者、または抵当権またはＥＢＰのような利益を保有する第三者が存在する。

【0193】

一実施形態では、住宅および適用可能なＤＯＯＲ金融商品の住宅アレンジメントを記述するデータは、住宅金融商品データブロックチェーンに存在する。データには、少なくとも次のものが含まれる：（ｉ）少なくとも、住所と、不動産リストに適した住宅の物理的特性の体系的な説明とを含む各住宅の特性；（ｉｉ）少なくとも住宅所有者から出資者への支払いのレベルを含む、このアレンジメントを管理する量的要素の現在値を伴う、ＤＯＯＲ金融商品の住宅融資アレンジメントの現在の契約条件；（ｉｉｉ）住宅の現在の運用評価、現在の運用帰属賃貸料率、および住宅に適用可能なＤＯＯＲ金融商品の住宅融資アレンジメントを実装するバランシング機構の入力として機能する他の全てのパラメータの現在の運用値;（ｉｖ）住宅における出資者の現在のエクイティ持分；（ｖ）ＤＯＯＲの住宅金融商品融資アレンジメントの価値と持分の進化の完全な履歴；（ｖｉ）出資者が、現在、出資者の全ての持分の一部を現在売りに出しているか否か、この場合、「アクティブ売却オファー」がある；（ｖｉｉ）アクティブ売却オファーがない場合に、出資者が、出資者の持分の一部または全部を売却する、望まないオファーにオープンであるか否か。この場合、出資者の持分は「購入オファーにオープン」である。

【0194】

この実施形態では、基礎となる住宅の所有権は、住宅所有者、パートナーシップ、または出資者が所有権を持たないが、契約上のポジションを有する別の形式によって保有され、ＤＯＯＲ金融商品住宅融資アレンジメントにおける契約上の権利は、出資者が、物件自体の譲渡を必要とせずに、互いにポジションを売買、交換することが出来、そしてＤＯＯＲ金融商品の住宅融資アレンジメントは、全て、ＭＭ－０出資と互換性があるように、設定される。

【0195】

管理エンティティが運用する出資者取引ウェブサイトは、承諾した既存の出資者と事前に承諾した潜在的出資者（総称して、「承諾済み出資者」）が、取引プラットフォームにより、ＤＯＯＲ金融商品の住宅融資アレンジメントにおける出資者の持分の購入または売却のオファーを行い、そしてオファーが受諾された場合、購入または売却を完了することを可能にする。ウェブサイトの取引プラットフォーム部分とそこで取引する能力は、既に同意されていて、かつその承諾されたステータスが、当業者に明らかであろう手続きの下で、現在のものである出資者のみが、アクセスすることが出来る。この手続きは、オンライン手順とオフライン手順の両方、および住宅金融商品のデータブロックチェーンに書き込まれるであろう成果と現在のステータスに関与できる。承諾された出資者は、当業者には周知であろうパスワードまたは他のプロトコルにより、ウェブサイト上の取引プラットフォームにアクセスする。取引プラットフォームは、出資者の持分のアクティブ売却オファーと、出資者の興味が購入のオファーにオープンである出資者の持分の詳細とを提示するウェブサイトのリスト部分にアクセスすることを可能にする。リスト部分は、不動産リストウェブサイトと同様の方法で編成されかつ表示される。もし、承諾された出資者が、特定の出資者の持分に興味を持つ場合、取引プラットフォームは、承諾された出資者と、出資の持分を積極的にオファーしているまたは購入のオファーにオープンである出資者との間のオンラインとオフラインの両方のコミュニケーションを容易にする。

【0196】

一実施形態は、図２４を参照して理解することができる。図２４は、例示的な実施形態に従って、受け取った購入オファーに関連する、購入オファープロセスおよびブロックチェーンシステムへの更新に関連するデータを示す流れ図（２４００）である。もし、承諾された出資者と、ＤＯＯＲ金融商品に出資者の持分を保有する出資者（オファーの「ターゲット出資者」）が、取引を完了する原則に合意した場合、承諾された出資者は、取引プラットフォームのウェブサイトにアクセスし、出資者の興味のある持分を特定し、そして１つ以上のＧＵＩベースのページで、ウェブサイトによって提供される電子フォームを使用してオファー条件を述べる。ウェブサイトは、送信ユニットにより、管理エンティティによって運用される取引エンジン１１８の受信ユニットに購入オファーメッセージを送信する（２４０２）。取引エンジンの実施形態は、それが、図１の取引エンジンであるので、図２３を参照して理解することができる。取引エンジン１１８の例示的な一実施形態は、1つまたは複数のネットワークを介してデータを受信する受信ユニット２３０２、1つまたは複数のネットワークを介して送信する送信ユニット２３０４、例示的な実施形態を実行するコンピュータアーキテクチャを備えた処理ユニット２３０６、および データを格納するためのデータベース２３０８を有する。購入オファーメッセージは、少なくとも：（ｉ）出資者の利益のある持分を識別する；（ｉｉ）購入オファーの条件とオファーを受諾する期限を指定する；（ｉｉｉ）承諾された出資者をメッセージの送信者として識別するのに適したセキュリティ情報を含む。取引エンジンは、送信ユニットにより、アクセス承認データと共に住宅金融商品データブロックチェーンシステムのクエリを送信して、購入オファーメッセージに関連するデータを抽出する。この購入オファーメッセージは、少なくとも、出資者の利益のある持分を保有する出資者のＩＤに関するデータ、持分が、アクティブ売却オファーの対象であるか否か、購入オファーにオープンであるか否か、および購入オファーメッセージを送信するための、承諾された出資者のＩＤと承諾ステータスを含む（２４０４）。

【0197】

住宅金融商品データブロックチェーンシステムは、そのアクセスエンジンを実装して、取引エンジンが、リクエストされたデータにアクセス可能であるか否かを決定する。アクセスの許可を検証した後、取引エンジンは、受信ユニットにより、住宅金融商品データブロックチェーンから関連データを受信し、そして取引エンジンに関連付けられている処理ユニットは、承諾された出資者の承諾ステータスをチェックし、そしてターゲット出資者と出資者の持分を照合する。もし、承諾ステータスが現在のものである場合、取引エンジンは、送信ユニットにより、少なくとも以下を含む購入オファーデータに関与すルータゲット出資者の受信ユニットに購入オファー通知を送信する（２４０６）：（ｉ）オファーを行う承諾済み出資者のＩＤと承諾済みステータス; （ｉｉ）オファーの条件；（ｉｉｉ）期限を徒過した後にオファーを受諾するための期限；（ｉｖ）取引エンジンの受信ユニットにオファーまたは拒否を伝えることによって、オファーを受諾するまたは拒否する方法。取引エンジンは、送信ユニットを介して、オフラインの可能性があるターゲット出資者（または出資者を表す人工知能エンティティ）に、携帯電話または他の受信デバイスによる電子メールまたはＳＭＳメッセージを介して、購入オファーと購入オファーデータをアラートする。もし、取引エンジンが、受信ユニットにより、ターゲット出資者からオファーを拒否するメッセージを受信した場合、取引エンジンは、送信ユニットにより、拒否の通知を、オファーを行う承諾された出資者の受信ユニットに送信し、そしてオフラインの可能性がある、承諾された出資者に、電話または他の受信デバイスによる電子メールまたはＳＭＳメッセージを介して、拒否をアラートする。もし、ターゲット出資者が、期限までにそれを受諾しなかったために、オファーが期限切れになった場合（２４０８）、取引エンジンは、オファー期限切れ通知を生成し（２４１０）、そして送信ユニットを介して、オファーの期限切れの通知を、オファーを行う承諾された出資者の受信ユニットとターゲット出資者の受信ユニットの両方に送信し（２４１２）、そしてオフラインの可能性がある当事者に、携帯電話または他の受信デバイスによる電子メールまたはＳＭＳメッセージを介して、オファーの有効期限が切れていることをアラートする。

【0198】

もし、取引エンジンが、受信ユニットにより、ターゲット出資者からオファーを受諾するメッセージを受信した場合（２４１４）、取引エンジンは、送信ユニットにより、受諾通知を、オファーを行う、承諾された出資者の受信ユニットに送信し、そしてオフラインである可能性がある、承諾された出資者に、携帯電話または他の受信デバイスによる電子メールまたはＳＭＳメッセージを介して、受諾をアラートする。取引エンジンは、処理ユニットにより、特定の承諾された出資者用に調整された、要求される完了ドキュメント、特定のターゲット出資者、および特定の出資者の持分、のセットを準備する（２４２０）。取引エンジンは、送信ユニットにより、アクセスが、パスワードプロトコルまたは当業者に周知である他のデバイスにより、出資者の購入と売却に限定されている取引プラットフォームのウェブサイトで、これらのフォームが、アクセス可能となるようにする。取引エンジンは、送信エンジンにより、購入および売却の出資者の受信ユニットに、実行手続き通知を送信し、そして携帯電話または他の受信デバイスによる電子メールまたはＳＭＳメッセージを介して、一方または両方がオフラインの可能性がある両方の出資者に、完了文書をオンラインで完成させ、そして要求される支払いを手配する必要性をアラートする。文書が、オンラインで両当事者によって完成され、そしてその処理エンジンにより、あらゆる点で完全であることが取引エンジンによって検証され、そして支払いが検証された後（２４２２）、取引エンジンは、住宅金融商品データブロックチェーンへの書き込みに適した形式で、取引データパッケージを作成および編成する（２４２４）。取引データパッケージには、少なくとも（ｉ）取引の当事者；（ｉｉ）取引条件；（ｉｉｉ）取引が有効になった日時；および（ｉｖ）完了文書の完全なセット、が含まれる。取引エンジンは、送信ユニットにより、アクセス承認データと共に、住宅金融商品データブロックチェーンシステムのクエリを送信して、取引データパッケージをブロックチェーンに書き込むための許可を確保する。

【0199】

住宅金融商品データブロックチェーンシステムは、そのアクセスエンジンを実装して、契約エンジンが、要求される許可を有していることを検証する。受信ユニットにより検証の確認を受信した後、取引エンジンは、送信ユニットにより、取引データパッケージをブロックチェーンに書き込み（２４２６）、ブロックチェーンに取引のレコードを作成し、そして移転を実行する。取引エンジンは、取引メッセージを生成し（２４２８）、そして送信ユニットにより、取引データパッケージの関連部分と共に、取引が完了したことの通知を、購入および売却の出資者のみがアクセス可能な取引プラットフォームウェブサイトの部分に、送信する。取引エンジンは、送信ユニットを介して、オフラインになっている可能性がある売買出資者に、携帯電話または他の受信デバイスによる電子メールまたはＳＭＳメッセージを介して、取引が完了し、そして関連する完了データが、取引プラットフォームウェブサイトで利用可能であることを、そのデータが存在するウェブサイトの一部にアクセスするための命令と共に、アラートする。

【0200】

ここで説明した出資者取引プラットフォームの実施形態は、本発明によって作成されたコンピュータ技術により、住宅所有者が関係する限り、ＤＯＯＲ金融商品住宅融資アレンジメントの出資者持分に関する出資者取引を、完全にバックグラウンドで実行することができることを示している。多数の監視機能およびアクション機能に対処するために、本発明を備えるコンピュータ技術によって実現される、低コストでかつほぼ瞬時に単一のウェブサイトおよび様々なＧＵＩベースのページに住宅所有者がアクセスする能力は、影響を受けない。抵当権者は、例えば、既存のテクノロジに基づいて抵当権者の利権が別の抵当権者に移転されるいくつかの例の場合のように、支払いまたは情報の受け取りのためにウェブサイトを切り替える必要は、全く無い。

【0201】

（出資者取引とポートフォリオバランスの調整）
一実施形態では、管理エンティティは、１つまたは複数の不動産ポートフォリオを出資者として運用し、そしてこれらのポートフォリオは、少なくとも、複製の自治体の、地方の、または全国の住宅指数を含む目標またはターゲットを有する。このようなポートフォリオのバランスをとるためには、少なくとも、住宅売却、獲得エクイティの住宅所有者による取得、出資者のエクイティの住宅所有者による購入、または該当する住宅融資アレンジメントの条件の基で住宅所有者から出資者への獲得エクイティの売却に関与する、ポートフォリオ回転率に直面して、ポートフォリオをターゲットと対比して軌道に保つために、出資者としての管理エンティティによる購入および売却活動が、要求される。

【0202】

これまでに説明した住宅融資アレンジメントを具体化するいくつかのＤＯＯＲ金融商品は、ＭＭ－０住宅融資アレンジメントに相当するポジションを、出資者に作成する。このポジションは、所有者が占有する住宅についての生のリターン（これは、住宅価格の上昇と経費控除後の帰属賃貸料の合計に等しい）を獲得するレバレッジされていないエクイティで構成される。これらの「ＭＭ－０出資互換金融商品」は、第三者または住宅所有者の扱いに関して異なる場合があるが、これらは、全て、住宅指数を追跡または作成するために設計されているポートフォリオに含めるのに適している。この結果、これらのポートフォリオには、ＭＭ－０アレンジメントを直接実装する金融商品のみならず、ＭＭ－０の出資に対応したフルクラスの金融商品を含めることができる。例えば、前述のＥＢＰアレンジメントのＤＯＯＲ金融商品実装のクラスは、出資者の成果がＭＭ－０アレンジメントの場合と同じであるので、ＭＭ－０出資互換金融商品から構成される。

【0203】

一実施形態では、出資者取引プラットフォームを簡単に変更して、少なくとも範囲をＭＭ－０住宅融資アレンジメントに制限し、そして異なるポートフォリオファンドの共通管理に基づいて取引手順を簡略化することにより、住宅所有者が実質状参加する必要なく、ポートフォリオが、住宅インデックスポートフォリオ資金間の購入と売却のバランスをとることを促進させることができる。この結果、住宅保有者は、本発明を備えるコンピュータ技術によって、住宅保有者が、多数の監視およびアクション機能に低コストでほぼ瞬時に対処することを可能にする、単一のウェブサイトおよび様々なＧＵＩベースのページに何の中断もなくアクセスすることができることを経験するであろう。購入と売却のバランスをとるポートフォリオの円滑化は、上記のように暗号通貨で実施されるポートフォリオファンドにとって特に価値がある。

【0204】

（購入、オリジネーション、売却要素の統合）
上記の実施形態は、本発明を備えるコンピュータ技術が、住宅所有者および他の関連する当事者が、低コストでほぼ瞬時に多数の機能に従事するために、単一のウェブサイトおよび様々なＧＵＩベースのページにアクセス可能なようにする方法を説明する。実施形態のいくつかは、本発明を備えるコンピュータ技術が、同時に、単一のウェブサイトで低コストの統合プレゼンテーションをサポートし続ける方法で、彼らの間での、または住宅所有者および出資者との、第三者が関与する複雑な対話を、どのように容易に行うかを示す。本発明は、第三者が関与する多くの複雑な補助タスクが、目に見えない方法でかつユーザに対してウェブサイトの機能を中断させない方法で運用される、出資サービスウェブサイトでのプレゼンテーションおよび機能の幅広い範囲に対応する、住宅所有のウェブプレゼンテーションを可能にする。

【0205】

上記の実施形態のほとんどは、基礎となる住宅融資アレンジメントの条件または当事者のポジションの変更のような、所有期間中の機能に関係していた。１つまたは複数の実施形態では、多くの購入、オリジネーション、および売却要素は、単一のウェブサイトに統合させることもできる。統合可能な要素には、少なくとも次のものが含まれる：（ｉ）住宅所有者による、ＤＯＯＲ金融商品住宅融資アレンジメントのオンライン申請；（ｉｉ）その申請に関する引受および信用分析；（ｉｉｉ）住宅融資アレンジメントに関する消費者教育および開示；（ｉｖ）クロージング文書を含む文書の公布；（ｖ）エスクローサービス；（ｖｉ）完了機能；（ｖｉｉ）関連する当事者とのコミュニケーションによるオンラインで実行できない機能の管理；（ｖｉｉｉ）取引を記録し、そして少なくとも、住宅金融商品データブロックチェーンを含む１つ以上のブロックチェーンに、関連するドキュメントをアーカイブする。管理エンティティが運用する少なくとも１つ以上の暗号通貨ベースの住宅ポートフォリオを含む特定の出資者は、ＤＯＯＲ金融商品の住宅融資と組み合わせて市場に住宅を提供する、または彼らの住宅の売却を希望するＤＯＯＲ金融商品住宅融資アレンジメントの住宅所有者を買収することをオファーすることができる。単一のウェブサイトを介したこれらの「システム内」の売却および購入は、売却および購入コストを節約し、そして要求されルータスクを合理化するための更なる範囲を形成する。

【0206】

（例示的な実施形態）
一実施形態によれば、不動産の金融、サービス、および報告をリアルータイムで動的管理するためのコンピュータ技術システムは、以下のこと：

管理エンティティによって制御され、そして少なくとも住宅所有者と出資者がアクセス可能なウェブサイトに、前記条件の表示、パラメータ値、および住宅融資アレンジメントに基づく今後要求されるアクションを、維持すること；

少なくとも住宅金融商品データブロックチェーンを含む少なくとも１つのブロックチェーンシステムに、特定の住宅に融資する少なくとも１人の住宅所有者と少なくとも１人の出資者との間の少なくとも１つの住宅融資アレンジメントを指定する契約情報;少なくとも１つの住宅融資アレンジメントの動的管理に関連する経済パラメータの時系列；前記融資負債またはエクイティの現在および過去の所有権のレコード；少なくとも前記住宅所有者による出資者への支払いを含む取引のレコード；前記住宅融資アレンジメントの任意の調整または変更のレコード；前記住宅所有者と出資者の間の住宅融資アレンジメントをジョイントベンチャとして考慮し、そして前記当事者の前記純拠出を反映するために少なくとも１つの残余口座を調整して、少なくとも前記住宅所有者と出資者の純拠出を追跡するための少なくとも１つのバランシング機構の仕様；１つ以上のバランシング機構に基づいて、少なくとも１つの残余アカウントの調整結果と共に、継続的に運用されるバランシングエンジンのデータと計算のレコード；前記ブロックチェーンシステム内のデータへのアクセスの様々なレベル、および前記ブロックチェーンシステムに新しいデータを書き込むためのアクセス許可のレベルを規定するアクセスプロトコール；そして前記住宅融資アレンジメントの前記対象となる住宅を記述するデータ、を格納すること；

前記プロセッサが、バランシング機構の下で調整を実装するために、管理エンティティによって制御される少なくとも１つのサーバ上に、少なくとも１つの処理ユニット、少なくとも１つの受信ユニット、および少なくとも１つの送信ユニットで具体化されるバランシングエンジンを維持すること；

前記バランシングエンジンの受信ユニットが、前記管理エンティティまたはそれを表す人工知能エンティティからメッセージを周期的に受信して、前記住宅金融商品データブロックチェーンへのバランシングエントリを開始すること；前記バランシングエンジンの送信ユニットが、バランシング計算に関連するデータに対する前記ブロックチェーンシステムのクエリを送信すること；前記バランシングエンジンの受信ユニットが、当該データを受信すること；

直接アレンジメントの場合、前記バランシングエンジンの処理ユニットが、少なくとも１つの残余口座の更新されたバランスを決定すること；前記バランシングエンジンの送信ユニットが、前記計算の詳細と共に前記更新された残余口座バランスを、前記住宅金融商品データブロックチェーンに書き込むこと；前記バランシングエンジンの処理ユニットと送信ユニットが、少なくとも住宅所有者と出資者がアクセス可能なウェブサイトを修正して、前記更新された残余口座バランスを表示すること；そして前記バランシングエンジンの送信ユニットが、オフラインになっている可能性がある少なくとも住宅所有者および出資者に、携帯電話または他の受信デバイスにより、前記更新された残余口座バランスをアラートすること；

直接アレンジメントの場合、前記バランシングエンジンの処理ユニットが、少なくとも１つの残余口座の更新されたバランスを決定すること；前記バランシングエンジンの送信ユニットが、前記計算の詳細と共に前記更新された残余口座バランスを、前記住宅金融商品データブロックチェーンに書き込むこと；前記バランシングエンジンの処理ユニットと送信ユニットが、少なくとも住宅所有者と出資者がアクセス可能なウェブサイトを修正して、前記更新された残余口座バランスを表示すること；そして前記バランシングエンジンの送信ユニットが、オフラインになっている可能性がある少なくとも住宅所有者および出資者に、携帯電話または他の受信デバイスにより、前記更新された残余口座バランスをアラートすること；

直接アレンジメントではないアレンジメントの場合、前記バランシングエンジンの処理ユニットが、更新されたスケジュールされていない成果と、前記スケジュールされていない成果を入力として使用する、関連付けられている数量とを、決定すること；前記バランシングエンジンの送信ユニットが、前記更新されたスケジュールされていない成果と関連付けられている数量とを、前記計算の詳細と共に、前記住宅金融商品データブロックチェーンに書き込むこと；前記バランシングエンジンの処理ユニットと送信ユニットが、少なくとも住宅所有者、出資者、および残余バランシングポジション保有者がアクセス可能なウェブサイトを修正して、前記更新されたスケジュールされていない成果と関連付けられている数量とを表示すること；そして前記バランシングエンジンの送信ユニットが、オフラインの可能性がある、少なくとも住宅所有者、出資者、および残りのバランシングポジション保有者に、携帯電話または他の受信デバイスにより、前記更新されたスケジュールされていない成果と関連付けられている数量とをアラートすること；

管理エンティティによって制御される少なくとも１つの処理サーバ上に、少なくとも１つの処理ユニット、少なくとも１つの受信ユニット、少なくとも１つの送信ユニット、および少なくとも１つのデータベースで具体化される少なくとも１つのデータエンジンを維持し、当該処理サーバが、少なくとも１つのデータパラメータの少なくとも１つの時系列を、作成、収集、更新、処理、格納、および通信すること；

少なくとも１つのデータエンジンの受信ユニットで、前記データエンジンによって生成された少なくとも１つのデータパラメータを計算するための入力データを備える第三者のデータを、受信すること；前記データエンジンの処理ユニットが、前記追加されたデータをフォーマットし、そして前記データエンジンの同じ処理ユニットが、データベースを修正して、前記追加されたデータを組み込むこと；前記データエンジンの処理ユニットが、前記データパラメータの少なくとも１つの非第三者バージョンを計算すること；前記データエンジンの処理ユニットが、前記第三者および非第三者評価を使用して、前記データパラメータの単一の運用値を計算すること；前記データエンジンの送信ユニットが、前記データパラメータの前記更新された運用値を、少なくとも、前記計算の日時スタンプと、前記第三者および非第三者の値と、住宅金融商品データブロックチェーンの運用値を計算するために使用される方法論とを含む前記計算のレコードと共に、書き込むこと；前記データエンジンの処理ユニットと送信ユニットが、少なくとも住宅所有者と出資者がアクセス可能なウェブサイトを修正して、前記データパラメータの前記更新された運用値を表示し、そして一般的に、または前記データパラメータの特定の値が実現されたときに、何れかの当事者が、前記運用値の更新をリクエストしたときに、前記データエンジンの送信ユニットが、オフラインの可能性がある少なくとも住宅所有者および出資者に、携帯電話または他の受信デバイスにより、前記更新された運用値アラートすること；

少なくとも１つの第三者の融資アレンジメントから出現する少なくとも１つのデータパラメータの少なくとも１つの時系列を、作成、収集、更新、処理、格納、および通信する目的で、前記管理エンティティによって制御される少なくとも１つの処理サーバ上に、少なくとも１つの処理ユニット、少なくとも１つの受信ユニット、少なくとも１つの送信ユニット、および少なくとも１つのデータベースで具体化された少なくとも１つの第三者データエンジンを、維持すること；

前記管理エンティティによって制御される処理サーバ上で運用される少なくとも１つの第三者データエンジンの受信ユニットで、少なくとも１つの第三者金融アレンジメントに関するデータを、受信すること；前記第三者データエンジンの処理ユニットが、住宅金融商品データブロックチェーンに記録されるべきデータの要素を識別すること；記録されるべき前記データを適切なフォーマットに修正すること；第三者データエンジンの送信ユニットが、住宅金融商品データブロックチェーンに、関連付けられている任意の計算のレコードと共に、データ要素を書き込むこと；前記第三者データエンジンの受信ユニットが、前記住宅金融商品データブロックチェーンから、前記第三者の融資アレンジメントの前記現在のステータスと関連付けられている履歴とを記述するデータを、抽出すること；前記第三者データエンジンの処理ユニットが、ウェブサイトの表示のために当該データを編成すること；第三者データエンジンの処理ユニットと送信ユニットが、少なくとも住宅所有者と出資者がアクセス可能なウェブサイトを修正して、前記第三者の融資アレンジメントの前記更新データを表示すること；そしてもし、一般にまたは前記特定のデータパラメータの特定の値が実現されたことに基づいて、何れかの当事者が、更新されたこのような更新データを要求した場合、前記第三者データエンジンの送信ユニットが、オフラインの可能性がある、少なくとも、所有者とオフラインの出資者に、携帯電話または他の受信デバイスにより、前記更新データをアラートすること；

少なくとも一人の住宅所有者と出資者との間の前記住宅融資アレンジメントを、開始、実装、実施、および更新するために、管理エンティティによって制御される少なくとも１つの処理サーバに、少なくとも１つの処理ユニット、少なくとも１つの受信ユニット、および少なくとも１つの送信ユニットで具体化された契約エンジンを、維持すること；

管理エンティティによって制御される処理サーバ上で運用される契約エンジンの受信ユニットが、住宅融資アレンジメントを記述する初期契約データを受信すること；処理ユニットが、住宅金融商品データブロックチェーンに記録されるべき前記初期契約データの要素を識別すること；前記契約エンジンの処理ユニットが、適切なフォーマットに記録されるべき前記データを編成および修正すること；そして前記契約エンジンの送信ユニットが、住宅金融商品データブロックチェーンに、前記必要なデータ要素を書き込むこと；

管理エンティティによって制御されるウェブサイトまたは他の入力デバイス上に、前記住宅所有者から、新しい条件の少なくとも１つのオプションを指定する住宅融資アレンジメントの少なくとも１つの条件を変更するリクエストを、受信すること；そして前記管理エンティティによって制御されるサーバの送信ユニットが、前記管理エンティティによって制御される処理ユニットにより動作する契約エンジンの受信ユニットに、前記リクエストを送信すること；

直接アレンジメントの場合、前記契約エンジンの受信ユニットが、前記住宅金融商品データブロックチェーンから、各オプションの前記リクエストされた変更を管理する必要な契約条項を、他の関連データと共に、抽出すること；前記契約エンジンの処理ユニットが、各オプションの要求された変更が前記住宅融資アレンジメント契約の下で許可されているか否かを、決定すること；条件の変更が許可されている場合、前記住宅所有者以外の当事者による任意の承諾が要求されているか否かを決定すること；少なくとも１つのオプションに基づく条件の変更が、許容される場合、承諾を要求する各オプションの承諾に承諾するまたはそれを拒否する必要性を、当該当事者の少なくとも１つの受信デバイスにより、少なくとも１つの関連する当事者にアラートすることにより、前記契約エンジンの送信ユニットが、各オプションに対して要求される任意の承諾を求めること；応答を受け取った後、または応答期限が経過した後、前記契約エンジンの処理ユニットが、住宅所有者によって提案された各オプションが同意されているか拒否されているかを決定すること；前記契約エンジンの送信ユニットが、前記住宅所有者がアクセス可能なウェブサイトを修正して、前記住宅所有者に各オプションが承認されているか拒否されているかを通知し、そして少なくとも１つのオプションが承認されている場合は、前記住宅所有者に、前記オプションの１つを受諾するまたはそれら全てを拒否することを確認するようにリクエストすること；前記データエンジンの送信ユニットが、少なくともオフラインになっている可能性がある前記住宅所有者に、前記承認または拒否されたオプションを、携帯電話または他の受信デバイスによりアラートし、そして少なくとも１つのオプションが承認されると、前記住宅所有者に１つのオプションまたはそれら全ての拒否の確認をリクエストすること；前記住宅所有者がオプションを確認したときに、前記契約エンジンの送信ユニットが、少なくとも条件の前記変更の発効日と時間を含む、前記受諾されたオプションを構成する関連データと共に、条件の変更を住宅金融商品データブロックチェーンに書き込むこと；前記契約エンジンの処理ユニットと送信ユニットが、少なくとも住宅所有者と出資者がアクセス可能なウェブサイトを修正して、前記変更が有効であることを確認し、そして前記変更の有効な日時を表示し、そして前記新しい住宅融資アレンジメント条件を表示すること；そして前記契約エンジンの送信ユニットが、携帯電話または他の受信デバイスにより、前記変更の有効な日時と共に、前記変更が有効であることを、オフラインの可能性がある少なくとも住宅所有者および出資者に、アラートすること；

直接アレンジメントではないアレンジメントの場合、前記第三者データエンジンの受信ユニットは、前記住宅データブロックチェーンから、少なくともデータを含む要求された変更を管理する必要な契約条項を、少なくとも、各オプションに関して前記住宅所有者へのオファーを生成するデータを含む、他の関連データと共に、抽出し、前記オファーには、前記リクエストの前記対象である前記条件以外の前記住宅融資アレンジメントの条件の変更が含まれていること；前記契約エンジンの処理ユニットが、前記住宅所有者によって指定された条件変更オプションごとに、少なくとも１つのオファーを計算すること；前記契約のエンジンの送信ユニットが、前記住宅所有者がアクセス可能なウェブサイトを修正して、前記住宅所有者に前記オファーを通知すること；前記住宅所有者に、前記オファーの１つの受諾を確認する、または前記オファーの全ての拒否を確認することをリクエストすること；前記契約エンジンの送信ユニットが、オフラインになっている可能性がある少なくとも前記住宅所有者に、携帯電話または他の受信デバイスにより、前記オファーと１つのオファーを受諾する、または前記オファーの全てを拒否する前記必要性とをアラートすること；前記契約エンジンの処理ユニットが、少なくとも、前記オファーの前記コンテンツと前記オファー時の前記管理データパラメータの前記値（前記オファー条件を管理する値）とを含むオファーデータアンサンブルを作成すること；前記契約エンジンの送信ユニットが、前記オファーデータアンサンブルを、前記住宅金融商品データブロックチェーンに書き込むこと；前記住宅所有者がオファーを受諾すると、前記契約エンジンの受信ユニットが、前記住宅金融商品データブロックチェーンから前記オファーデータアンサンブルを抽出すること；前記契約エンジンの処理ユニットが、前記オファーアンサンブルデータを使用して、前記既存の住宅融資アレンジメントを完了し、そしてそれを、前記受諾されたオファーで指定された前記条件を具体化した新しい住宅融資で置き換えるために要求される、少なくとも住宅所有者、前記出資者、および残余バランシングポジション保有者の間の前記調整を計算すること；前記契約エンジンの送信ユニットが、要求されるステップを前記関連する当事者に通知するメッセージを、送信すること；前記契約エンジンの受信ユニットが、当事者間で要求される任意の支払いを含む、前記必要とされるステップが、既に、完了していることの検証を受け取ること；前記契約エンジンの処理ユニットが、少なくとも前記既存の住宅融資アレンジメントを完了するために行われた前記調整を含む移行データパッケージ、前記新しい住宅融資アレンジメントの前記条件、および前記新しいアレンジメントが有効になる日時を、前記当事者の前記開始残余口座ポジションと共に、コンパイルすること；前記契約エンジンの送信ユニットが、前記移行データを前記住宅金融商品データブロックチェーンに書き込んで、前記新しい住宅融資アレンジメントへのシフトを実行すること；前記契約エンジンの処理ユニットが、関連する各当事者に適した前記移行データの別々の表示可能なバージョンを作成すること；前記契約エンジンの処理ユニットと送信ユニットが、前記関連する当事者がアクセス可能なウェブサイトを修正して、前記ウェブサイトの別々の部分の別々のバージョンの前記移行データを、各別々の当事者に表示し、そして前記新しいアレンジメントを前記ウェブサイトの一般的にアクセス可能な領域に表示すること；そして前記契約エンジンの送信ユニットが、オフラインになっている可能性がある前記関連する当事者のそれぞれに、その当事者に関連する前記移行データと、前記新しい住宅融資アレンジメントを記述する前記共通データとをアラートすること；

管理エンティティによって制御されるウェブサイトまたは他の入力デバイスで、住宅所有者から、残余口座ポジションを少なくとも１人の出資者に売却する、または、少なくとも１人の出資者から残余口座ポジションを購入するリクエストを受け取ること；および 前記管理エンティティによって制御されるサーバの送信ユニットが、前記売却または購入リクエストを、前記管理エンティティによって制御される処理ユニットにより運用される契約エンジンの受信ユニットに、送信すること；

直接アレンジメントの場合、前記契約エンジンの受信ユニットが、前記住宅金融商品データブロックチェーンから、リクエストされた売却または購入を管理する必要な契約条項を、少なくとも前記売却または購入の前記条件を決定するために要求されるデータを含む他の関連データと共に、抽出すること；前記契約エンジンの処理ユニットが、前記リクエストされた売却または購入が、前記住宅融資アレンジメント契約の下で許可されているか否かを決定すること；前記リクエストされた売却または購入が、前記住宅融資アレンジメント契約の下で許可されている場合、前記取引の反対側の前記出資者による承諾が要求されているか否かを決定すること；前記契約エンジンの処理ユニットが、前記購入または売却の適用可能な条件を決定すること；前記売却または購入が許容される場合、前記契約エンジンの送信ユニットが、必要に応じて、前記計算された条件に基づいて、各当該出資者の少なくとも１つの受信デバイスにより、前記出資者に、前記条件と承諾を承諾するまたは拒否する前記必要性をアラートすることにより、出資者の承諾を求めること；応答を受け取った後、または応答の期限が経過した後、前記契約エンジンの処理ユニットが、前記計算された条件での前記売却または購入が、承認されているまたは拒否されているかを決定すること；前記契約エンジンの送信ユニットが、前記住宅所有者がアクセス可能なウェブサイトを修正して、前記住宅所有者に承認または拒否を通知すること；承認のために、前記計算された前記条件に基づいて受諾または拒否を確認するよう前記住宅所有者にリクエストすること；前記契約エンジンの送信ユニットが、オフラインになっている可能性がある前記住宅所有者に、携帯電話または他の受信デバイスにより、同意または拒否をアラートすること；承認のため、前記計算された条件に基づいて、前記住宅所有者に前記取引の同意または拒否を確認するようにリクエストすること；前記住宅所有者が前記取引を確認すると、前記契約エンジンの送信ユニットが、要求されるステップを前記関連当事者または当事者に通知するメッセージを送信すること；前記契約エンジンの受信ユニットが、当事者間の要求される支払いを含む、要求されるステップが、既に完了していることの確認を受け取ること；前記契約エンジンの処理ユニットが、少なくとも前記取引の前記確認、前記取引の前記条件、前記取引が有効になった前記日時、および前記当事者の前記新しい残余口座のポジションを含む取引データパッケージを、コンパイルすること；前記契約エンジンの送信ユニットが、前記契約エンジンの処理ユニットによるフォーマットの後、前記取引データを前記住宅金融商品データブロックチェーンに書き込むこと；前記契約エンジンの処理ユニットと送信ユニットが、少なくとも住宅所有者と出資者がアクセス可能なウェブサイトを修正して、前記取引データの前記関連部分を表示すること、そして
前記契約エンジンの送信ユニットが、オフラインの可能性がある少なくとも住宅所有者と出資者に、携帯電話または他の受信デバイスにより、前記取引データの前記関連部分をアラートすること；

直接アレンジメントではないアレンジメントで、住宅データのブロックチェーンから、前記第三者データエンジンの受信ユニットが、リクエストされた売却または購入を管理する必要な契約条項を、少なくとも、前記提案された売却または購入に関して前記住宅所有者へのオファーを生成するのに十分なデータを含む他の関連データと共に、抽出するステップであって、各オファーには、前記提案された売却または購入に伴う前記住宅融資アレンジメントの前記条件の変更が含まれる、こと；前記契約エンジンの処理ユニットが、前記住宅所有者によって提案された前記売却または購入に関する少なくとも１つのオファーを計算すること；前記契約エンジンの処理ユニットが、前記リクエストされた売却または購入が、前記住宅融資アレンジメント契約の下で許可されているか否かを決定すること；前記リクエストされた売却または購入が、前記住宅融資アレンジメント契約の下で許可されている場合、前記取引の反対側の前記出資者による承諾が、要求されているか否かを決定すること；前記契約エンジンの処理ユニットが、前記購入または売却の前記適用可能な条件および各オファーの前記条件を決定すること；前記売却または購入が、許容される場合、前記送信ユニットが、各当該出資者の少なくとも１つの受信デバイスにより、前記出資者に、前記オファーおよび各オファーを承諾するまたはそれを拒否する前記必要性をアラートすることにより、前記計算された条件に基づいて、必要に応じて、各オファーに関する出資者の承諾を求めること；応答を受け取った後、または応答の前記期限が経過した後、前記契約エンジンの処理ユニットが、各オファーが承認されたまたは拒否されたかを決定すること；前記契約エンジンの送信ユニットが、前記住宅所有者がアクセス可能なウェブサイトを修正して、前記住宅所有者に各オファーの承認または拒否を知らせること；少なくとも１つのオファーの承認のため、住宅所有者に、売却または購入の条件と共に１つのオファーの受諾を検証するか、または全てを拒否するようにリクエストすること；前記契約エンジンの送信ユニットが、オフラインになっている可能性がある前記住宅所有者に、携帯電話または他の受信デバイスにより、各オファーの承認または拒否をアラートすること；少なくとも１つのオファーの承認のため、前記売却または購入の条件と共に１つのオファーの受諾を確認する、またはそれら全てを拒否するかを、前記住宅所有者にリクエストすること；前記契約エンジンの処理ユニットが、少なくとも、前記オファーの前記コンテンツ、前記売却または購入条件、および前記オファー時の前記管理データパラメータの前記値（前記オファー条件を管理する値）を含む、オファーデータアンサンブルを作成すること；前記契約エンジンの送信ユニットが、前記オファーデータアンサンブルを前記住宅金融商品データブロックチェーンに書き込むこと；前記住宅所有者が、前記売却または購入条件と共に、オファーを受諾すると、前記契約エンジンの受信ユニットが、前記住宅金融商品データブロックチェーンから前記オファーデータアンサンブルを抽出すること；前記契約エンジンの処理ユニットが、前記オファーアンサンブルデータを使用して、少なくとも、住宅所有者、出資者、および残余バランシングポジション保有者の間の調整を計算し、前記残余バランシングポジション保有者が、前記既存の住宅融資アレンジメントを完了し、そしてそれを、前記受諾されたオファーで指定された前記条件を具体化する新しい住宅融資アレンジメントにより、置き換えることを要求されること；前記契約エンジンの送信ユニットが、前記関連する当事者に、要求されるステップを通知するメッセージを送信すること；前記契約エンジンの受信ユニットが、当事者間の必要な支払いを含む、前記要求されるステップが、既に完了していることの検証を受け取ること；前記契約エンジンの処理ユニットが、少なくとも、前記既存の住宅融資アレンジメントを完了するために行われた前記調整、前記売却または購入の前記条件、前記当事者の前記開始残余口座のポジションを伴う前記新しい住宅融資アレンジメントの前記条件、および前記新しいアレンジメントが有効になった日時、を含む移行データパッケージをコンパイルすること；前記契約エンジンの送信ユニットが、前記移行データを前記住宅金融商品データブロックチェーンに書き込むこと；前記新しい住宅融資アレンジメントへのシフトを実行すること；前記契約エンジンの処理ユニットが、前記関連付けられている各当事者に適した移行データの別々の表示可能なバージョンを作成すること；前記契約エンジンの処理ユニットと送信ユニットが、前記関連する当事者がアクセス可能なウェブサイトを修正し、前記移行データを前記ウェブサイトの別々の部分に別々のバージョンで表示し、そして前記ウェブサイトの一般的にアクセス可能な領域に前記新しいアレンジメントを表示すること；そして前記契約エンジンの送信ユニットが、オフラインになっている可能性がある関連当事者のそれぞれに、その当事者に関連付けられている移行データと、新しい住宅融資アレンジメントを説明する共通データとをアラートすること、

を備える。

【0207】

（コンピュータシステム）
図２５は、いくつかの実施形態の特定の特徴を実装するために使用することができるコンピュータシステムのブロック図である。このコンピュータシステムは、サーバコンピュータ、クライアントコンピュータ、パーソナルコンピュータ（ＰＣ）、ユーザデバイス、タブレットＰＣ、ラップトップコンピュータ、携帯情報端末（ＰＤＡ）、携帯電話、アイフォン、アイパッド、ブラックベリー、プロセッサ、電話、ウェブアプライアンス、ネットワークルータ、スイッチまたはブリッジ、コンソール、ハンドヘルドコンソール、（ハンドヘルド）ゲームデバイス、音楽プレーヤ、ポータブル、モバイル、ハンド保有デバイス、ウェアラブルデバイス、またはそのマシンが実行するアクションを指定する一連の命令（順次または他）のセットを実行することができる任意のマシンとすることができる。

【0208】

コンピューティングシステム（２５００）は、１つまたは複数の中央処理ユニット（「プロセッサ」）（２５０５）、メモリ（２５１０）、入／出力デバイス（２５２５）（例、キーボードおよびポインティングデバイス、タッチデバイス、またはディスプレイデバイス）、ストレージデバイス（２５２０）（例、ディスクドライブ）、およびネットワークアダプタ（２５３０）（例、ネットワークインターフェース）を含むことができ、これらは、相互接続（２５１５）に接続されている。相互接続（２５１５）は、適切なブリッジ、アダプタ、またはコントローラによって接続されている、任意の１つまたは複数の別個の物理バス、ポイントツーポイント接続、またはその両方を表す抽象概念として、示されている。従って、相互接続（２５１５）は、例えば、システムバス、周辺機器相互接続（ＰＣＩ）バスまたはＰＣＩ－Ｅｘｐｒｅｓｓバス、ＨｙｐｅｒＴｒａｎｓｐｏｒｔまたは業界標準アーキテクチャ（ＩＳＡ）バス、小型コンピュータシステムインターフェース（ＳＣＳＩ）バス、ユニバーサルシリアルバス（ＵＳＢ）、ＩＩＣ（１２Ｃ）バス、または（Firewireとも呼ばれる）米国電気電子学会（ＩＥＥＥ）標準の１３９４バスを含むことができる。

【0209】

メモリ（２５１０）および格納デバイス（２５２０）は、様々な実施形態の少なくとも一部を実装する命令を格納することができるコンピュータ可読格納媒体である。さらに、データ構造およびメッセージ構造（例、通信リンク上の信号）は、データ伝送媒体により格納または送信させることができる。様々な通信リンク（例、インターネット、ローカルエリアネットワーク、ワイドエリアネットワーク、またはポイントツーポイントのダイヤルアップ接続）を使用することができる。従って、コンピュータ可読媒体は、コンピュータ可読格納媒体（例、非一時的なメディア）、およびコンピュータ可読伝送メディアを含むことが出来る。

【0210】

メモリ（２５１０）に格納された命令は、プロセッサ（２５０５）が上述のアクションを実行するようにプログラムするソフトウェアおよび／またはファームウェアとして実装させることができる。いくつかの実施形態では、このようなソフトウェアまたはファームウェアは、最初に、コンピューティングシステム（２５００）によりリモートシステムから（例、ネットワークアダプタ２５３０経由で）、それをダウンロードすることにより、処理システム（２５００）に提供させることができる。

【0211】

本明細書で紹介される様々な実施形態は、例えば、プログラム可能な回路（例、ソフトウェアまたはファームウェア、あるいはその両方でプログラムされた１つまたは複数のマイクロプロセッサ）、または完全に専用のハードワイヤード（プログラム不可能な）回路、またはこのような形式の組み合わせ、により実装させることが出来る。専用のハードワイヤード回路は、例えば、１つまたは複数のＡＳＩＣ、ＰＬＤ、ＦＰＧＡなどの形をとることができる。

【0212】

開示されたシステムおよび方法の様々な例示的な実施形態が、ここまで、説明されて来たが、これらは、限定するものではなく、例としてのみ提示されたことは、理解されるべきである。これは例示列挙であり、そして開示は、開示された正確な形式に限定されることはない。上記の教示に照らして、修正および変更が、可能であるし、また、本開示の実施から、幅も範囲も逸脱することなく、それらを取得することもできる。従って、本発明は、以下の請求項によってのみ限定される。

【0213】

（関連出願の相互参照）
この出願は、２０１８年１月８日に提出された米国仮特許出願s ／ n ６２ ／ ６１４,７２０および２０１９年１月７日に提出された米国仮特許出願s ／ n１６ ／ ２４１,８２０の優先権を主張し、その全体が、参照により本明細書に組み込まれている。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】

【図22】

【図23】

【図24】

【図25】