JP5150948B2 - 申請装置および方法 - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は例えば財務ローンの申請および承認を受ける等の財務特性の１つの団体から１以上の他の団体により行われた申請（application）を提出し考察する装置および方法に関する。
【０００２】
【従来の技術】
団体は以後、一方では申請者(applicant)と呼び、他方では（申請の）申請受者(recipient(of the application))と呼ぶ。例えば財務ローン申請のコンテキストでは申請受者は（銀行または他の財務機構のような）貸主であってもよい。さらに、本発明の多数のさらなる申請は基本的に、申請者により申請受者へ行われた申請の提出と、その後の評価と、承認または拒否を含むトランザクションで考慮される。
【０００３】
例えば（クレジットカード、個人ローン、自動車ローン、抵当等の形態の）金融の申請を実行するには通常、申請者が多くは自分でまたは電話によって例えば貸主の形態の申請受者と接触をもち、ローン申請を口答でまたは書類で申込むことにより完成し、その後で貸主により考慮されることを必要とする。貸主は実際に数人の貸主のうちの一人であってもよく、それによって申請者は可能なローンの価格および特徴を比較でき、或いは貸主が申請を拒否し、申請者に別のローンを探させる。これは特定の多額のローンを探す場合に特に望ましいことが多い。代わりに、この多数の貸主と相談する仕事は、申請者の代わりに有効な選択肢を比較する情報または財務ブローカーにより申請者の代わりに実行されることができる。
【０００４】
しかしながら、申請プロセスと必要な情報は各貸主で異なり、各貸主はいずれにしても返済可能ではない料金を有し、そのため申請者は共通して、可能ならば一人の（例えば推薦されたまたは過去に使用した）貸主と交渉を進める。結果として、申請者は選択した貸主（またはブローカー）と定期的に接触を維持し、典型的な手順を経て申請を完成する。これらは、申請様式(application form)の完成後の文書の編集、貸主との面接、提出された情報の具体化等を含んでいる。これらのステップは、多くの場合に申請者により与えられた多量の情報がその決定に直接的な関係がなくても、貸主の標準申請プロトコルの一部を形成し、クレジット決定が行われる前に貸主により完成されることが必要であり、貸主が情報または文書の標準的なアレイをリクエストする遅延を最小にし、これは実際には全てのケースで必要とされるわけではない。
【０００５】
しかしながら多くの状況では、特に多額のローンでは、申請の完成はそれ自体、貸主が申請の事項を理解しようとして全ての必要な情報を確認するので多くの反復を含んでいる。これは申請者へ数回または多数回戻すことを必要とする。これに対処するため、数人の貸主は複雑な申請を再検討するためにさらに熟練した保険業者を使用する。例えば自営業の借用人からの抵当申請は困難であると考慮され、熟練した人員の応対を必要とする。（ルールとして、ローンの大きさが小さい程、申請を評価するのに人間の関与が少ない）しかしながら、各申請には非常に多くの変形があり、結果として数百万の異なる申請プロフィールが存在するので、最も熟練した保険業者さえも通常クレジット決定を行う前に幾つかの明瞭にするまたは補足的な質問を尋ねる必要がある。
【０００６】
さらに、既存の紙面の申請様式はその利用性とフレキシブル性で限定を受け、１つの様式では全ての可能なシナリオをカバーできない。これは標準的な様式のストックを維持し、それぞれの場合に最も適切なものを選択することにより時折解決されるが、この方法は個々のケースが例えば多数のプロダクトおよび多数の貸主、さらに多数の申請者で生じるときにはすぐに限界に達する。
【０００７】
ローンが承諾されるならば、ローン勘定の規則的な維持は貸主とローン申請者（カスタマ）との間の書類または口答の通信を通常必要とする。
【０００８】
申請プロセスを自動化する試みが行われ、それによって必要とされる人間の関与が少なくなる。しかしながら典型的に、これは（インターネットのような）コンピュータネットワークによりアクセスされ、完成され、提出されることができる申請様式を貸主が準備することを含んでいる。申請プロセスはその後、伝統的なラインに沿って進行し、貸主が電子申請様式を幾らか予備的に考察した後、ローン申請者は接触をもたれ、前述したようにプロセスは進行する。
【０００９】
米国特許第5,870,721 号明細書（Affinity Technology Group 社）はこのプロセスをさらに自動化しようとする実時間のローン承認システムおよび方法を開示している。この明細書の発明にしたがって、ローン申請者はリクエストされたまたは必要な情報を遠隔インターフェース（好ましくはキオスク）で入力することによりローンの申請を提出する。情報はデータ処理手段へ送信され、そのデータ処理手段はクレジット代理店のような他のデータベースからさらに情報を獲得する。申請はその後、１つの保険されたスコアを計算し、そのスコアに基づいて申請を評価することにより人間の援助なしで評価される。結果はその後、申請者へ通報される。
【００１０】
しかしながら、このシステムおよび方法は保険されたスコアに基づく決定に適した簡単なローン申請に限定され、（このような自動化の他の試みに共通して）ローン申請が一人の貸主により考察される場合に関する。例えば多数の貸主の追加は、潜在的に非常に多くのローン選択基準のセットと、それ故申請者が回答しなくてはならない多数の質問のために、このシステムを非実用的にする。
【００１１】
豪州特許第687880号明細書（Jeffrey A. Norris ）は閉ループ財務トランザクション方法および装置を開示しており、米国特許第5,870,721 号明細書に関連する。しかしながら、この発明がどのように多数の貸主のコンテキストで使用されるかを開示しておらず、ローン申請者は厄介な量の情報を供給し、またはしばしば多数の不適切な質問を考慮することを必要とされる。
【００１２】
さらに、これらの特許またはその他の既存のシステムは一度承認されたローンが管理されまたは調節される手段を含んでいない。例えばカスタマは返済を増加したがり、これは料金を引くが、貸主からさらに承認が必要とされない。前述したように、既存のシステムは１つの申請が多数の貸主により考慮されることを可能にしない。またはこのような場合、これらの多数の貸主がこれに限定しない知識をもちながら申請に回答することを可能にする。
【００１３】
【発明が解決しようとする課題】
それ故、本発明の目的は、１以上の申請受者に必要な情報を獲得するために申請者に効果的に質問する能力を含んでいる、申請を受信し、評価する装置および方法を提供することである。
【００１４】
本発明のさらに別の目的は、最初の申請が与えられた後の申請の少なくとも幾つかの特徴を管理する装置および方法を提供することである。
【００１５】
本発明のさらに別の目的は、多数の申請受者が最初の申請が与えられた後の申請の少なくとも幾つかの特徴を管理することを可能にする装置および方法を提供することである。
【００１６】
【課題を解決するための手段】
それ故、本発明によって、申請者によって行われた申請を受信して評価する装置が与えられ、その装置は、
申請者に複数の申請様式を与えて申請者から一度完成された様式を受取り、申請を評価する計算手段と、
様式を完成させて計算手段に戻す申請者用の入力手段と、
申請の評価を申請者に通報または送信する通信手段とを具備し、
計算手段は、完成されて受信された様式で入力手段によって申請者により与えられた情報に基づいて複数の様式の第２およびそれに続く様式を順次構成するように構成またはプログラムされて申請を評価し、通信手段によって評価を通報する。
【００１７】
したがって各様式の内容は１以上の先の様式で与えられた情報に基づいて決定される。この方法で、次の様式が先の様式により冗長にされた質問を省略できるので、様式の総数または各様式の長さは減少または最小にされる。
【００１８】
幾つかの実施形態では、（恐らく申請者のリクエストで）申請者には複数のうちの１つの様式が複数回与えられるが、その様式が先に与えられた様式の後に提供された情報にしたがって、このような与えられた様式間でその様式が変更されてもよいことにも注意すべきである。それ故、このようなケースの別の観点から、この方法で１回よりも多数与えられるが、与えられた様式間で変更される様式は、実際には次が与えられるとき異なる様式である。例えば、様式はコンピュータスクリーン上で複数のタブ付けされた様式として申請者へ与えられ、それによって、申請者は自由に（タブを選択し、対応する様式を前面にすることにより）任意の様式によって開始することができるが、後に既に観察した様式へ戻す。
【００１９】
さらに、前記申請者により与えられた情報に基づいて第２およびそれに続く様式が順次構成されるが、用語“構成する”は既存の先行する様式が変更することなしに申請者へ与えられるべきであることを決定することを含むことができる。
【００２０】
好ましくは、前記評価は前記申請の承認および拒否を示す。さらに、前記評価は代わりに、申請が承認または拒否されることができる前に、さらに情報または人間の関与が必要とされることを示している。
【００２１】
したがって、評価は承認または拒否（不十分な情報が自動的な拒否につながる場合）を単に示し、または付加的な情報または人間の関与が必要とされる場合には第３の選択肢が含まれてもよい。本発明の申請では、用語“承認”は仮の承認または事前資格、即ち申請プロセス中に与えられた幾つかのまたは全ての情報の次の具体化に付随する承認を含んでいることにも注意すべきである。また、用語“申請者”は申請の１または複数の申請受者に実際に申請する人またはブローカーのような介在人を意味する。
【００２２】
複数の様式は、複数の様式の複数のグループの１つであってもよい。
【００２３】
したがって、必要な情報は関連する情報のグループに分割されてもよく、各グループ内で、第２のおよびそれに続く様式は、そのグループ内の、または幾つかの申請では、先のグループ内の１以上の先の様式から決定されてもよい。
【００２４】
計算手段は、前記様式の１以上のものとして受信された情報にしたがって、前記申請を評価するように構成またはプログラムされている。
【００２５】
したがって、申請受者の選択基準の全体に基づいて、申請者は残りの質問に回答するように尋ねられていなくても、受信された情報が申請が承認または拒否されるべきであることを示すとすぐに、申請処理は切取られて短くされてもよい。例えば、その様式で戻された情報がリクエストされたローンが申請受者（または貸主）の絶対的な貸し限度を超えていることを示しているならば、ローン申請は申請者が１つの様式だけを完成した後に拒否されてもよい。
【００２６】
装置は前記様式を提供するための表示手段を含んでもよい。好ましくは、前記計算手段は遠隔位置の表示手段に前記様式を表示するように動作可能である。遠隔表示手段は、コンピュータネットワークによって前記装置に接続されているコンピュータであってもよい。好ましくは、前記コンピュータネットワークはインターネット、ワールドワイドウエブ、商業的オンラインサービス、対話型放送、またはその他の電子オンライン手段である。
【００２７】
入力手段は、例えば任意の適切なコンピュータまたはコンピュータキーボード、またはコンピュータのマウス、または前記計算手段に接続された電子ペンのようなコンピュータ入力手段である。好ましくは、前記入力手段は、インターネット、ワールドワイドウエブ、商業的オンラインサービス、対話型放送、または他の電子オンライン手段のようなコンピュータネットワークによって前記装置に接続されているコンピュータであり、このようなコンピュータに接続されたコンピュータキーボードおよびマウスを含んでいる。
【００２８】
好ましくは前記通信手段は、電子メールまたはファイル転送システムのような電子情報転送システムである。好ましくは前記電子メールシステムはインターネットのようなコンピュータネットワークに接続され、またはそれをアクセスするように動作可能である。
【００２９】
好ましくは前記装置は、前記申請の評価において考慮するために外部データベースまたはその他の情報ソースから付加的な情報を得るための通信リンク手段を含んでいる。通信手段は通信リンク手段として動作可能であってもよい。
【００３０】
したがって、装置は例えば申請評価の一部として考慮するために申請者のクレジット報告を獲得することができる。通信手段と通信リンク手段の両者はその一部がインターネットであってもよい。
【００３１】
好ましくは、前記装置は、（不完全な、または、自己矛盾、申請者により与えられた他の情報との矛盾、意味のない等のために）前記申請者により先に戻された情報が１以上の欠陥を含むとき、１以上の付加的な様式を与えるように構成またはプログラムされている。前記付加的な様式は単に先に与えられた様式を繰返すか、または新しい様式であってもよい。
【００３２】
好ましくは前記装置は、前記申請者により先に戻された情報を訂正するように前記申請者により動作可能である。これは申請者が評価される前または評価された後に行われ、評価された後ならば、装置は申請を再度評価してもよい。
【００３３】
好ましくは、前記装置は、確実性の決定に対する予め設定された許容誤差に基づいて、典型的に人間の判断または統計的な解析に基づいて決定される前記欠陥の或るものを無効にするように構成またはプログラムされる。その代わりに前記装置は若干または全ての環境において重要ではないと見なされた或る情報をリクエストしないように構成またはプログラムされることができる。
【００３４】
好ましくは前記装置は、複数の申請受者の申請承認基準を含むかアクセスすることができ、前記複数の各申請受者の承認基準にしたがって前記申請をアクセスするのに十分な前記様式を与えるように構成またはプログラムされ、各前記申請受者の承認基準に対して前記申請を評価するように構成またはプログラムされ、それによって各前記複数の申請受者にそれぞれ別々の評価を形成する。
【００３５】
装置は、前記１以上の申請受者に対する多数の別々の承認基準にしたがって前記申請を評価するように構成またはプログラムされている。
【００３６】
したがって、ローン申請の場合、申請者は幾つかの貸主から申請の評価を受信でき、各１人よりも多数の各貸主からの１よりも多数の財務プロダクトでは、貸主プロダクトの組合わせを選択する。その代わりに、申請者は実際に異なる期間をリクエストするために１以上の様式を訂正し、それによって評価数を変更する。
【００３７】
好ましくは、前記装置は、前記複数の申請受者の１以上のものに１以上の前記評価を通信するように構成またはプログラムされている。さらに好ましくは前記装置は、それぞれの評価が承認を示している全ての前記複数の申請受者へ全ての前記評価を通信するように構成またはプログラムされている。
【００３８】
好ましくは前記装置は、前記申請者による選択を要求するために各申請受者の前記各承認基準を調節するために前記複数の申請受者のそれぞれによって動作可能である。
【００３９】
したがって、申請者は、承認が示されている最良または最も好ましい申請受者を受入れ、または申請者の嗜好に対応する最良の提案を有する申請受者へ“競売”されるように選択することができる。
【００４０】
好ましくは、前記申請が承認されたならば、前記装置は、前記申請の１以上のパラメータを調節またはその調節をリクエストするように前記申請者によって動作可能である。
【００４１】
これは承認後、申請者が申請の詳細の一部を変更することを可能にする。財務申請では、これは返済のサイズと頻度を含んでいる。
【００４２】
好ましくは前記装置は前記情報および，または前記申請の条件の一部または全部を前記申請者に表示しまたは送信するように前記申請者によって動作可能である．
したがって、装置は申請者（または後にカスタマ）が、（例えばローン申請：明細の発行、付加的な手形の振出、付加的な返済、銀行口座詳細の変更等の）承認前および、または承認後にそれらの申請の一部または全ての特徴を点検および、または管理することを可能にする。
【００４３】
好ましくは、前記装置は援助を要求する手段または援助を要求するように動作する手段を含み、またはアシスタントが前記申請者にアドバイスできるように前記申請の詳細をアシスタントに通報するように動作可能である。
【００４４】
好ましくは前記アシスタントは前記申請者によって完成される期間中に１以上の前記様式を観察することを可能にされている。
【００４５】
したがって、申請者がその１つの様式の一部分を理解することができないならば、申請者は援助を要求でき、アシスタントは完成した即座の条件でその様式を観察して、必要なときに申請者にアドバイスすることができる。
【００４６】
本発明は１以上の申請受者に対する申請者によって行なわれた申請を受信して評価する方法を提供し、
前記申請者に複数の申請様式を提供し、
前記申請者から一度完成された前記様式を受取り、
前記申請を評価し、
前記申請の前記評価を前記申請者に通報または送信し、
それにおいて、前記完成されて受信された様式で前記申請者によって与えられた情報に基づいて前記複数の様式の第２およびそれに続く様式を順次構成することを含んでいる。
【００４７】
好ましくは、前記方法は、前記１以上の申請受者に対する申請承認基準を集収し、互いに前記基準のそれぞれの依存性を決定し、内容が高いまたは最大の可能性で、遅れたクエッション冗長の数を有する内容の情報のリクエストを前記シーケンス様式で促進し、後続する様式から前記冗長クエッションを除去するステップを含んでいる。
【００４８】
したがって、問合わせプロセスの“総自由度”を順次減少することによって、様式の総数は減少され、または最小にされる。
【００４９】
好ましくは、方法は、初期の様式で任意のクエッションを提供し、それにおいて、前記各クエッションの場合に対する応答が申請のただちの拒否に導くことを含んでいる。
【００５０】
例えば、数人の申請受者は未成年者またはローン申請の例では、ある貸し限度外で行われた申請を承認しない。このような情報をリクエストする１以上の様式は様式のシーケンスの初期に申請者に与えられ、それによって申請者はできる限り少い数の様式を完成し、１０以上の様式を完成して年齢または生年月日を尋ねられ、その後未成年者からの申請は全ての他の考察と関係なく拒否されることを単に通知されることは申請者の時間を無駄にする。
【００５１】
好ましくは前記方法はそれにつづく前記シーケンスの調節を含んでいる。例えば、これは使用法の明瞭さまたは容易さを改良し、申請者の嗜好を反映し、または他の目的を実現するために行われてもよい。
【００５２】
したがって、その他の方法で、理想的なシーケンスは調節され、それによってシーケンスは幾らかの効率性を犠牲にしても、申請者の了解を得る。
【００５３】
本発明はさらに申請者によって行なわれた申請を受取って評価するための装置を提供し、前記装置は、
申請情報を受信し、前記申請を評価するように構成されプログラムされている計算手段を具備し、
前記装置は、複数の申請受者の申請承認基準を含み、或いはアクセスするこが可能であり、前記計算手段は、前記複数の申請受者のそれぞれの前記承認基準にしたがって前記申請を評価するように構成され、またはプログラムされ、それによって前記装置は前記複数の申請受者のぞれぞれに対してぞれぞれ別々の評価を形成できる。
好ましくは前記装置は、
前記計算手段に前記申請を入力するための申請者に対する入力手段と、
前記申請者に前記申請の前記評価を通報または送信する通信手段とを具備している。
好ましくは前記計算手段は、前記申請者に複数の申請様式を提供し、前記申請者から一度完成した前記様式を受取り、前記申請を評価するように構成またはプログラムされ、
前記計算手段は、前記完成されて受信された様式で前記入力手段によって申請者により与えられた情報に基づいて前記複数の様式の第２および後続する様式を順次構築して前記通信手段によって前記評価を通報するように構成またはプログラムされている。
【００５４】
本発明はさらに、申請者によって行なわれた申請を受取って評価するための方法を提供し、この方法は、
前記申請者から申請情報を受取り、
複数の申請受者のそれぞれの承認基準にしたがって前記申請を評価し、
前記複数の申請受者のそれぞれに対してそれぞれ別々の評価を形成することを含んでいる。
好ましくは前記方法は、前記申請者に対する前記申請の前記評価の通報または送信を含んでいる。
【００５５】
本発明はさらに申請者によって行なわれた申請を処理する方法を提供し、この方法は、
前記申請者から申請情報を受信し、
複数の申請受者に対して前記情報を提供し、
前記１以上の申請受者からの前記申請に対する１以上の要求を受信し、
前記１以上の要求のそれぞれの選択または拒否のために前記申請者に前記１以上の要求を転送することを含んでいる。
【００５６】
好ましくは前記方法は、前記複数の申請受者のそれぞれに対して前記申請のそれぞれ別々の評価を形成するステップを含んでいる。
【００５７】
好ましくは前記方法は、前記情報の調整の選択または拒否にしたがって前記各要求を調整するステップを含んでいる。
【００５８】
したがって、申請者は（申請情報で表される）申請者の嗜好に対応する最良の提案を有する申請受者に“競売”される。
【００５９】
本発明にしたがって、申請者によって行なわれた申請を処理する装置が与えられ、前記装置は、
前記申請者から申請情報を受信するように構成またはプログラムされ、前記情報を複数の申請受者に導き、１以上の前記申請受者から前記申請に対する１以上の要求を受信し、前記１以上の要求のそれぞれの選択または拒否のために前記申請者に前記１以上の要求を転送するように構成またはプログラムされた計算手段を具備している。
【００６０】
【発明の実施の形態】
本発明がさらに明白に認識されるように、好ましい実施形態を添付図面を参照して例示により説明する。
以下の本発明の好ましい実施形態は財務、特にローン申請分野であるが、本発明はこのような申請に限定されない。
【００６１】
本発明の好ましい実施形態にしたがって、インターネットでアクセスされることができるローン申請、承認および管理システムが与えられ、したがってオープンアーキテクチャを有するものと説明され、これは１以上の貸主の基準と、各貸主に対する１以上の財務資産に基づいて、申請の自動化された評価に必要な情報を捕捉する一連のカスタマ化された電子申請様式を申請者へ与える。申請者が承認（申請処理中に与えられる情報の確認）後、一度カスタマになり、これは（例えば法務官、見積もり者、クレジット預り所との）第３パーティの関係を含むと、好ましい実施形態はカスタマが人間の関与をもたずに進行中のビジネス関係を遠隔で管理することを可能にする。
【００６２】
「好ましい実施形態の要約」
システムは以下の特性を含んでいる。
・オープンアーキテクチャ：システムは専用のキオスクのような所有権を有するフロントエンドハードウェアまたは装置を使用せずに申請者／カスタマまたは第３パーティによりアクセスされることが可能であるが、インターネットを使用するオープンアーキテクチャ原理に基づいている。
・スーパーセット決定方法：全ての参加している貸主に対する全てのローンまたは財務資産基準を最初に集め、申請者が申請手順を進めるとき体系的に数学的な“自由度”を減少することに基づいた方法である。
・ダイナミック電子様式：申請者に１つの標準的な様式または様式のセット、或いは既存の様式のセットから単に選択された様式または様式のセットを与えるのではなく、申請者により与えられた情報に基づいて、順次およびインテリジェントに構成または組み立てられた一連の様式を申請者は与えられる。
・実時間援助：申請者はアシスタントとの実時間のメッセージ対話に加わり、そのアシスタントは申請者により現時点で完成された様式を観察できる。
・多数の資産／貸主における保険の自動化：システムは多数の資産および多数の貸主の承認基準にしたがって申請を自動的に評価できる。
・遠隔申請管理：システムは遠隔で実時間でユーザが彼等の申請の進行を進め、追跡し、通知されることを可能にする。
・自己サービス：一度、申請者、即ちカスタマになると、本発明は申請者が人間と関与せずに彼等のローン勘定を電子的に管理することを可能にする。
・介在システム：システムはまた例えばクライアントの代りに申請を預ける財務ブローカー、財務プランナー、販売者によりアクセスされることができる。
・ローン交換：システムまた種々の貸主が所望の申請を識別し、このような見込みのあるカスタマへ入札を行うことを可能にし、勝った入札者がビジネスを獲得する“オークション”システムとしても作用する。
【００６３】
［好ましい実施形態の詳細な説明］
好ましい実施形態を以下の例を参照することにより説明し、この例は家の抵当に関連する。例えばクレジットカードまたは小さい個人のローンと反対に、大きなサイズのローンのために、抵当は多数の確認（例えば副抵当、保証、借団体、収入源、雇用試験）を必要とし、最も複雑な個人の財務トランザクションに入ると考慮されている。
【００６４】
例で使用される申請者の詳細を以下示す。
説明 プロフィール 総額 月々の支払い
名称 ・1950年１月１日生まれの −
のMr.pat Hall
ローン目的 ・既存の抵当の
財務の立て直し
・他の未払いの
債務の統合
所有財産 ・２つの住宅資産 ＄350,000
（同一と仮定）
・１つの倉庫 ＄250,000
（産業区域）
現在の抵当 ・２つの住宅資産の ＄320,000 ＄1,750
１つの第１の抵当
現在の他の債務 ・クレジットカード ＄5,000 ＄150
・個人のローン ＄5,000 ＄200
・自動車ローン ＄7,500 ＄500
収入源 ・フルタイムの販売管理者 ＄50,000 −
（年間当り）
・組合からの固定収入 ＄5,000 −
（年間当り）
・組合の利益の25％ ＄10,000 −
・組合の全体的な現金
ではない出費＊ ＄5,000 −
＊現金ではない費用は組合により与えられる現金の流れを獲得するために利益に還元される必要がある。
【００６５】
以下のクレジット基準と、住宅抵当の収入と資産説明を有する３つの有効な貸主Ａ、Ｂ、Ｃが存在する。
【表１】

【００６６】
＊これらはローンのサービス能力の尺度であり、実質上の黒字は全てのローンのコミットメントと生活費用の見積もり（貸主の与えた公式に対応する）が合致された後に残る一任された収入を表しており、債務サービス比は全体的な総計の月毎の収入により割り算された全体的な月々の債務の支払いとして計算される。
＊＊最大のＬＶＲは抵当に可能とされている最大のローン対値比であり、例えば申請者がサービス能力に基づいて資格を与えられているならば、最大ＬＶＲが90％ならば＄200,000 財産の最大のローン額は＄180,000 である。
【００６７】
以下、システムは適切である、前述のシナリオを使用して説明される。
【００６８】
・オープンアーキテクチャ
図１は、システムが対話するシステム23に対して外部の素子に関連して、このましい実施形態のシステム23のコンポーネントを示したフローチャートである。システム23内では、種々の通信リンクが実線の矢印により示され、システム23は（破線の矢印により示されている）インターネット等の多数の既存の通信リンクを有効に使用する。
【００６９】
好ましい実施形態によれば、システム23への全てのアクセスはユーザのタイプまたはクラスに応じてコンピュータ３、４、19または20の１つを介する。コンピュータ３、４、19および20はインターネット（モデムまたは電話接続手段を含む）によってシステム23と通信するように動作可能であり、システム23はウェブブラウザによりアクセスされるように構成されている。システム23はハイパーテキストマークアップ言語等で情報を与える。代わりに、コンピュータ３、４、19および20はケーブルモデム、ＡＤＳＬ、フレームリレイ、ＩＳＤＮ、衛星とＴ１、Ｔ２、Ｔ３通信プラットフォームを含んだ任意の他の高い帯域幅のデータ転送手段を含む適切な代替によりシステム23と通信してもよい。
【００７０】
先に参照した４つのクラスのユーザは、財務資産に応じて、直接申請者５、介在（例えばブローカー、財務プランナー、販売人）２、１以上の貸主21、任意の必要な第３パーティのサービスプロバイダ１を含んでいる。システム23をアクセスするユーザは識別子とパスワードを提供させられる。
【００７１】
直接申請者５は直接申請者制御モジュール７をアクセスすることができ、またはアクセスすることを促進され、このモジュールは直接申請者５に関するアクティビティの範囲に対するメニューとして動作する。これらのアクティビティは以下のものを含んでいるが、それらに限定されない。
・資産の比較の作成、
・資産／貸主情報の獲得、
・オンラインの適用、
・支払いの実行、
・申請状態の追跡、
・アシスタントとのコンタクトおよび通信、
・ローン勘定の管理。
【００７２】
これらのアクティビティの幾つかをさらに以下詳細に説明する。
介在２は介在制御モジュール６をアクセスするかアクセスを促進することができ、このモジュールは介在２に関するアクティビティの範囲に対するメニューとして動作する。図１で示されている介在制御モジュール６は介在２のタイプに依存する多数の制御モジュールを表す。例えば介在２は財務ブローカー、不動産業者、財務プランナー、販売者またはビルダーである。特有の介在制御モジュール６はは各タイプの介在２に存在する。直接申請者に有効なアクティビティに加えて介在に有効なアクティビティは以下のものを含んでいるが、それらに限定されない。
・市場／産業情報のアクセス、
・介在２のコミュニティに関する討論フォーラムに参加、
・全ての進行中の申請の観察、
・介在２の組織のパフォーマンスの評価用ツール、
・コミットメント収入の管理。
【００７３】
幾つかのこれらのアクティビティはさらに以下説明するように別のモジュールのアクセスを含んでもよい。
【００７４】
第３パーティのサービスプロバイダ18は第３パーティの制御モジュール16にアクセスするかアクセスを促進することができ、このモジュールは第３パーティのサービスプロバイダ18に関するアクティビティの範囲に対するメニューとして動作する。図で示されている第３パーティの制御モジュール16は第３パーティのサービスプロバイダ18のタイプに基づいて多数の制御モジュールを表す。例えば第３パーティのサービスプロバイダ18は財産見積もり者、クレジット経歴預り所、タイトル検索会社または保険会社、商事代理である。特有の第３パーティの制御モジュール16は各タイプの第３パーティのサービスプロバイダ18に存在する。このようなアクティビティは以下のものを含んでいるが、それらに限定されない。
・見積もり報告の投函、
・タイトル検索の送信、
・勘定のノミネート、
・保険ポリシーの発行、
・送り状の提出。
【００７５】
幾つかのこれらのアクティビティはさらに以下説明するように別のモジュールのアクセスを含んでもよい。
【００７６】
貸主21は貸主制御モジュール17をアクセスするかアクセスを促進することができ、このモジュールは貸主21に関するアクティビティの範囲に対するメニューとして動作する。このようなアクティビティは以下のものを含んでいるが、それらに限定されない。
・資産情報の更新、
・貸し基準の変更、
・承認された申請の観察、
・資金支払いの実行、
・申請条件の追跡、
・オークション結果の観察、または
・アークション入札の提出。
【００７７】
幾つかのこれらのアクティビティはさらに以下説明するように別のモジュールのアクセスを含んでもよい。
【００７８】
申請者に与えられる情報の確認または契約の署名期間のようなローン申請の後の段では、システム23はユーザとの通信の補足手段として（典型的な転送１、22により示されている）既知の技術を使用してもよい。また、幾つかのケースでは、文書化は非常に豊富であり、電子データ転送は非常に長くかかり、または非常に多くのメモリを必要とし、それ故実用的ではない。伝統的な転送１、22は郵便またはクーリエサービスまたはファクシミリの使用を含んでいてもよい。典型的な転送１、22は法律的に必要であり、好ましく、さらに好都合で実用的であるとき、（コンピュータ３、４、19、20とシステム23間で）例えば電子メールの代わりに使用される。
【００７９】
システム23のオープンアーキテクチャは、例えばパーソナルコンピュータおよびインターネットアクセスにより人がシステムを使用できることを意味している。
【００８０】
・スーパーセット決定方法
システムは多数の別々の貸主に対しての複数の財務資産を自動的に保険できる。これはスーパーセット決定方法と呼ばれる方法を使用することによって行われる。この処理は任意のローン申請を保証することために必要とされる全ての関連情報を捕捉するための質問ラインを生成する。スーパーセット決定方法12は、
１．全ての参加している貸主と資産の決定基準のスーパーセットを集め、
２．決定基準のデータ要求を識別し、
３．依存レベル（即ち基準間のデータ関係）にしたがって基準をランクし、
４．尋ねられた総質問数を減少または最少にするために質問シーケンスを最適化し、
５．不確定性とオープンエンドされた質問を減少するために新しいデータ要求とデータ変形を導入し、
６．消費者の好みおよび他の目的のために最適なシーケンスを調節し、
７．人間の判断または統計的な解析に基づいて、決定の確実性の許容誤差を設定する。
【００８１】
この処理が一度完了されると、これはダイナミック電子様式８で実行され、（即ち必要な情報は申請者へ逐次的に与えられた様式でリクエストされ、情報が申請者により与えられたときに順次設計される）それによって特定の誤差の許容度内で多数の貸主に対しての種々の資産を保険する。スーパーセット決定方法12の例を既に与えたケーススタディを使用して説明する。
【００８２】
［スーパーセット決定方法の例］
前述したように、紙面の申請様式は自動的な保険には不適切である。抵当に対して適用する一人の申請者の例では、紙面の申請様式は３つの特性等の全ての可能なシナリオを予測することができない。また多くのケースの紙面の申請様式は全ての必要な収入情報が捕捉されることを可能にしない。これは申請が多数の資産をそれぞれ有する多数の貸主の基準、および幾つかまたはこれらの資産が複雑である場合、このような住宅抵当に対して評価されるとき、特に明白になる。
【００８３】
スーパーセットの決定方法12の原則は、これは全ての可能な関連する質問により開始され、その後、質問を尋ねる最適のシーケンスを決定することである。同様に重要なことは、方法12は管理された方法で質問をインテリジェントにシーケンスすることである。スーパー決定方法12の各ステップを以下説明する。
ステップ１．決定基準のスーパーセットが集められる。スーパーセットは特定の資産（前述の例では抵当資産）に対する全て貸主に対する全ての決定基準のユニオンまたはユニバースとして統計的に限定される。
【００８４】
例では、貸主Ｃは実質的な黒字基準をもたないことに留意する。しかしながら、これは貸主Ａ、Ｂにより必要とされる。それ故、これは決定基準のスーパーセットに含まれなければならない。それ故、この例では決定基準のスーパーセットは、ローン勘定、保証、実質的な黒字、債務サービス比、財務の立て直し限度を含んでいる。
【００８５】
スーパーセットの境界は決定基準のスーパーセットに対する全ての許可を与えられた応答の外部範囲限度を規定する。例えば、例の“ローン勘定”の境界はこれが貸主Ａと貸主Ｃに対する限度を表すとき“＄10,000よりも大きく、＄500,000 よりも少ない”。これらの境界値は他のステップで使用される。例に対する決定基準のサブセットとその境界は以下の表に要約されている。
決定基準のサブセット 境界
ローン勘定 ・＄10,000と＄500,000 の間
保証 ・−住宅
−田舎
の第１の抵当
実質上の黒字 ・適用可能ではない＊
債務サービス比 ・最大３５％
立て直し限度 ・境界なし
アイデンティティ ・法定年齢でなければならない
＊実質上の黒字は異なる貸主により異なって計算されるので、比較する可能性がないので均一な境界は存在しない。しかしながら論理的に、境界は貸主Ｂと貸主Ｃの２つの方法の最小を取ることにより規定されることができる。
【００８６】
ステップ２．決定基準のデータ要求、即ち決定基準の決定のため必要とされる情報を確認するために申請者からリクエストされるべきデータは識別される。例えば、実質上の黒字と債務サービス比を計算するために、収入の情報が必要とされる。この例の決定基準のデータ要求を要約しているチャートを以下に示す。この例が非常に簡単にされることを示すため、システム23の実用的な申請で非常に適用可能な幾つかの他のデータ要求は括弧内に表示されている。
【００８７】
決定基準 データ要求
ローン額 ・所望の額（遺産、未払いデフォルト、未払いの判定、
未決定の購入契約、未払いの税債務、レート）
保証 ・ゾーニング、価値、住所（タイトルタイプ、
特別な条件、財産の大きさ、財産の使用、
予測される販売時間、貸しの警戒、資金調達力比率
実質上の黒字 ・収入、収入のタイプ、生活費、利子＊、減価＊、
（生計費、学費、社会保証、扶養家族、結婚状況）
債務のサービス比 ・収入、収入のタイプ、流動債務、利子＊、減価＊、
（期間、先の雇用、支給額、就業時間）
立直し限度 ・流動債務、月々の支払い、（債務のタイプ、
記憶カード対クレジットカード、現在の未払い金、
現在の商談、設備の使用）
アイデンティティ ・名称、ＤＯＢ、（現住所、先の住所、現在の宛先、
先の宛先、親類、電話番号）
＊利子と減価は必要であり、これらは現金ではない費用であり、それ故、現金流を得るために実質上の利益へ還元されなければならない。
【００８８】
ステップ３．基準は依存度（データ要求）のレベルにしたがってランクされ、即ち決定基準は必要な情報量によりアレンジされる。指針として、これはデータ要求数に対応すべきである。例えば、これは以下の表に要約されている。
【００８９】
決定基準 依存レベル データ要求
ローン額 低 所望量
アイデンティティ 低 ・名称
・ＤＯＢ
立て直し限度 中 ・各債務に対して：
- 価値
- 月々の支払い
保証 中 ・保証数
・資産のゾーニング
・価値
・住所
債務サービス比 高 ・収入源
・収入のタイプ
・収入額
・利子額
・減価額
実質上の黒字 高 ・収入源
・収入のタイプ
・収入額
・利子額
・減価額
・結婚状況＊
・扶養家族数＊
＊実質上の黒字はローンコミットメントと生活費を差引いた後に預けることが可能な収入の計算であり、生活費はある家族構造が支出することを必要とされる予測額に基づいて計算され、家族構造は通常、世帯の収入と大人および扶養家族数に基づいている。
【００９０】
ステップ４．シーケンスは尋ねられた質問数を減少または最少にするように最適化される。目標は申請についての決定に迅速に到達することである。これは質問数、それ故、結果数が減少されるように順番に質問を尋ねることを含んでいる。
【００９１】
例の各決定基準の“境界”を考慮すると、所望のローン額が貸主の最大限度を超過したならば、質問を続ける必要はないので、収入の詳細を質問する前に最初所望のローン額の情報をリクエストすることが好ましい。通常、減少したまたは最少数の応答がリクエストされるように質問をアレンジするため、質問は最低から最高の依存度の順番にされる。この例では、このプロセスは以下の質問ラインである。
・所望のローン額は？
・お名前は？
・誕生日は（ＤＯＢ）？
・流動債務は？
・各抵当の保証人住所は？
・各債務の差引勘定および月々の支払いは？
・現在所有している全ての財産の住所は？
・所有する全ての財産の価値は？
・所有する全ての財産のゾーニングは？
・全ての収入源は？
・世帯構造は？
・扶養家族数は何人ですか？
しかしながら、時には、マーケティング目的でさらに情報を集収するために質問数を調節することが望ましい。例えば、所望のローン額が貸主の最大限度を超えるために申請者を不適格とすることによって、見込みのあるカスタマの人口統計データの集収を除外する。これはステップ６でさらに説明する。
【００９２】
ステップ５．新しいデータ要求とデータ変形が不確定とオープンエンド質問を減少するために導入される。ある環境では、付加的な質問を尋ねることは不確実を除去し、尋ねる必要のある付加的な質問を減少し、任意のオープンエンド質問を除去する。例えば“現在の債務は？”のような質問は曖昧であり、それ故オープンエンドである。これは実用的な理由では簡潔さを強調しすぎ、それ故しばしば申請者に難解な質問を与え回答が不適当であるので、共通の欠点である。それ故、申請者に債務に特定した情報を与える前に、紙面の申請様式の申請者が有する債務数を特定するように尋ねることは、この不確実さを除去する。他の質問は以下のものを含む。
・所有している財産数は？
・収入源の数は？
・第１（第２、第３等）の収入源の性質は？
時には、これらの新しく導入された質問は使用されることができるさらに別の依存度につながる。この場合、ステップ２とステップ３を反復することは賢明である。例えば申請者が所有する財産数は、所有する財産のゾーニングと関係を有する。申請者が、ただ１つの財産を所有し、ゾーニングがスーパーセットの境界内で受け入れ可能なゾーニングではないことを示したとき、申請は差引きにより拒否される。しかしながら、現在の質問のシーケンスは、ゾーニング質問がそのプロセスの半分まで質問されていないような効率的なものではない。それ故、財産数の依存度と、財産のゾーニングのために、財産のゾーニングに関する質問は優先的に進められることができる。
【００９３】
基準変換は既存のデータから得られた新しいデータの導入を意味する。これらの変換は質問ラインを非常に最適化することができる。この簡単な例では、貸主Ａ、Ｂ、Ｃの最大のＬＶＲ制約と、全ての住居財産値では、申請者は全ての他の債務を立て直すことができないことに注目する。申請者どうするべきか、およびどのローンを立て直すべきかを決定する。各債務の未払い額と月々の支払いは“＄１の未払い金当たりの価格”と呼ばれる新しいデータに変更されることができ、これは未払い額により月々の支払いを割り算することにより計算される。ユーザが申請のこの矛盾を認識しないならば、システムは、新しく変更された基準が最も高価な債務を表すとき、最高の値を有する新しく変更された基準により限定される最も高価な債務を立て直すようにデフォルトされる。
【００９４】
ステップ６．消費者の好みおよび他の目的の最適なシーケンスが調節される。例えば、現在の質問シーケンスは世帯構造についてを最後に尋ねる。これは、申請者の財務陳述についての非常に詳細な情報を確かめた後にこのような情報を尋ねるプロセスで厄介な点であるように見える。それ故、申請者からのアイデンティティの詳細を集めたときにこの質問を尋ねる方が適切である。このステップは非常に主観的であり、システム23のユーザにより与えられるフィードバックに基づいて順次決定される。新しいデータ要求を考慮し、消費者の好みのシーケンスを調節した後、この例の新しい質問ラインを以下示す。
・所望のローン額は？
・現在所有する財産数はどのくらいですか？
・所有する全ての財産のゾーニングは？
・名前は？
・誕生日（ＤＯＢ）は？
・世帯構造は？
・扶養家族数は？
・住所、それに伴う各財産のゾーニングおよび価値は？
・債務数は？
・これらの債務の中で、抵当数は？
・各抵当に関する差額、月々の支払い、財産は？
・他の債務の差額と、月々の支払いは？
・あなたの収入源の数は？
・第１（第２、第３等）の収入源の性質は？
・各収入源からの収入額と収入のタイプは？
ステップ４の最後の質問と比較してステップ５と６の結果としてさらに多くの質問が存在することに留意する。しかしながら、これらの新しいデータ要求と変換は、ステップ４の最後の質問に対する応答が申請者の自動的な保険を可能にしないとき必要である。例えば、この例では、申請者は固定収入、組合利益、支払い賃金から収入を獲得するとき、収入について尋ねられたときに何を入力してよいを知らない。１つの可能性として、申請者は全ての額の合計を入力するが、これは異なる貸主が自営業収入に対して異なる収入計算方法を使用するときに正確ではない。また各収入源に対して異なる税率である。
【００９５】
ステップ７．人間の判断または統計的解析に基づく決定の確実性の許容誤差が設定される。即ち、このような情報が評価の結果に影響する確率は最少または許容可能であると決定されているので、幾つかの情報がリクエストされない。前述の例では、申請者が一人および、結婚した申請者の場合、申請者が二人であるならば、扶養家族数が常にゼロであると想定されることが決定されてもよい。
【００９６】
全体が正確ではないが、この不確実の度合いは貸主が受け入れる準備がある危険性を示唆している。したがって、プロセスのこのステップは、システム所有者の所望の許容度に応じて、含まれるか除去されることができるデータ、或いは申請者がデータを提供しないか不完全に提供したならば無視されるデータを識別することを含んでいる。この例ではリクエストされたデータが除去されるものがないため、１００％の確実性を有している。
【００９７】
以下の表に要約されているのは、この例の各質問に対する可能な回答である。
質問 回答
所望のローン額は？ ＄315,000
現在所有する財産数は？ ３
所有する全ての財産のゾーニングは？ 住宅および産業地域
名前は？ Ｐａｔ Ｈａｌｌ
誕生日（ＤＯＢ）は？ 1950年１月１日
世帯構造は？ 一人住まい
扶養家族数は？ ０
住所は？、またそれに伴う Ａ．１ Apple Street；
各財産のゾーニングおよび価値は？ 住宅、＄175,000
Ｂ．２ Apple Street；
住宅、＄175,000
Ｃ．５ Industrial Lane ；
産業、＄250,000
債務数は？ ４
これらの債務の中で、抵当数は？ １
各抵当に関する差引き勘定、 ＄320.000 、＄1750；Ａ＆Ｂ
月々の支払い、財産は？
他の債務の差額と、月々の支払いは？ クレジットカード：＄5,000;＄150pm
個人ローン：＄5,000;＄200pm
自動ローン：＄ ,500;＄500pm
収入源の数は？ ２
第１の収入源の性質は？ フルタイム
第１の収入源からの収入額および ＄50,000；支払い賃金
収入タイプは？
第２の収入源の性質は？ 組合
固定収入で受ける額は？ ＄5,000
組合いのシェアは？ ２５％
組合い利益のシェアを表す額は？ ＄10,000
現金ではない組合の費用の総額は？ ＄5,000
最低の依存度（即ちローン額、ゾーニング、ＤＯＢ）を有する質問に対する回答は受け入れ可能であることに留意する。そうでなければ、残りの質問を進める必要はない。さらに重要なことに、自動的に申請を保証するのに必要な全ての関連情報が（後に説明するように）集められることである。
【００９８】
前述の例はスーパーセット決定方法を示すために非常に簡潔にされている。異なるシーケンスはローン目的（例えば家の改築、家の購入、現金の前払い）にしたがう。システムはかなり複雑な例に適合することができる。さらに現実的な条件で生じる複雑性は以下のものを含んでいる
・事実上のアレンジメントに住む２人の借用人ではどうか？
・借用者が３人、即ち１組の夫婦と１つの会社のエンティティではどうか？
・借用人が４人の受取人を有する家族契約ではどうか？
・申請者が貧弱なクレジット歴ではどうか？
・借用人が組合に２か月前に加わった場合ではどうか？
・組合が申請者が販売管理者をしている同一の産業である場合はどうか？
・組合がお金を失ったらどうか？
・申請者の以前の所在地は？
・既存のローン勘定に未払いのものがあるか？
・リースされた装置が新しいかまたは中古か？
・購入した自動車が個人またはビジネス用に使用されるか？
・リースを適用する会社は他の登録された請求を有するか？
・過去のローン勘定が未払いであるか？
・過去の未払いの理由は？
・申請者に対する未解決の判定はあるか？
・贈与資金からの購入積立金はあるか？
・財産は区域の他の財産と一貫するか？
・財産はオークションまたは個人販売で購入したのか？
・販売者の報酬は購入価格に含まれていたか？
さらに事柄を複雑にするために、異なる貸主21は、前述の各基準に関する異なるルールを有する。異なる条件と考察の組合わせ数は非常に多いので、１つの文書に含むことができず、または既存の技術により合理的な長さの時間で完了することができないことが明白である。
【００９９】
全てのステップが逐次的に実行される必要はなく、幾つかのステップは全く行われる必要がないことに注意すべきである。例えば、システム23の所有者またはオペレータが変換の導入を希望しないならば、ステップ５はスキップされることができる。
【０１００】
・ダイナミックな電子様式
財務申請に対する既存の市場の実際は、申請者が印刷された申請様式を完成することを必要とするか、またはそのコンピュータ化された等価物（多くの場合、単に紙面の申請様式を複写する）を必要とする。前述したように、このような申請は全てのタイプの申請者に対して決定を行うことに必要とされる全ての必要なデータを捕捉することはできない。
【０１０１】
さらに、既存の様式は申請者に混乱を生じる。簡単な例では、申請者には例えば住所の詳細に対して１つのスペースを有する様式（紙またはその他）が与えられる。しかしながら、幾人かの貸主は、申請者が現在の住所に２年よりも少ない年数しかいないならば、以前の住所の提供を必要とする。財務申請のダイナミック電子様式８のさらに複雑な例には収入情報のエントリが含まれている。前述の例で見られるように、申請者が唯一の経営者、組合の社員、または企業の出資者として自営業から収入を得るならば、異なる収入情報が捕捉される必要がある。
【０１０２】
システム23はダイナミック電子様式８を、実際的でユーザに親しめる方法で申請情報を捕捉するためスパーセット決定方法12により生成された実効的な情報シーケンシングと結合する。ダイナミック電子様式８は原則として、ユーザの順次の回答に基づいて、カスタマイズされた申請の生成を可能にするカスタマイズされたサブ形態の集収である。
【０１０３】
例を参照すると、システム23は１つの長い様式に全てのリクエストされた情報を与えない。代わりに、ダイナミック電子様式８は最終的に全部で８の様式（この数は最初に知られていないが）を与え、各様式は質問の論理的なサブセットをカバーしている。各様式に関連する質問は以下の表で要約され、図２ａ乃至図２ｈにそれぞれ示されている。“質問”列の参照符号はこれらの図面を参照している。
【表２】

例で示されているように、先の様式の回答は次の様式の内容を決定する。このイノベーションは財務外の産業への応用能力を有する。
【０１０４】
・実時間のオンライン援助
本発明のシステムの特徴は実時間援助モジュール９の使用である。これは介在制御モジュール６、直接申請者制御モジュール７、第３パーティのサービスプロバイダモジュール18または貸主制御モジュール17のいずれかを経てユーザによりアクセスされる。
【０１０５】
システムは、アシスタント（通常は人間であるが、幾つかの簡単なケースではコンピュータ化も可能）に援助のリクエストを通告するコンピュータスクリーン上のアイコンにより表された電子ベルをユーザが鳴らすことを可能にする。システムはアシスタントがユーザ／申請者と同一のスクリーンを観察し、実時間の数字文字のメッセージにより通信し、またはユーザがこのような装置を有するならばシステムとの既存の通信リンクによる音声通信によって通信する能力を有する。
【０１０６】
例えば、ローンを申請する直接申請者５が特定のダイナミック電子様式８の質問に加わるならば、ユーザは援助アイコンを選択できる。これは直接申請者５がアシスタントのコンピュータスクリーンを観察している現在のダイナミック電子様式８を送信する。その後、別々のスクリーンが現れ、これはアシスタントが直接申請者５と通信することを可能にする。前述したように、実時間援助モジュール９もまた介在２、第３パーティのサービスプロバイダ18、貸主21によりアクセスされることができる。
【０１０７】
前記の例の場合では、申請者が様式Ｎｏ．９に関する質問を有することを想定する。申請者は現金ではない費用に減価が含まれるべきであるか否かを知らない。Hall氏はスクリーン上の“ベル”アイコンを選択し、これは実時間援助モジュール９を付勢する。この結果、アシスタントは援助がリクエストされている迅速な注意を受信し、申請者が観察しているのと同一スクリーンがアシスタントのスクリーン上に表示される。その後、申請者とアシスタントが相互にメッセージをタイピングすることによって会話するとき、サブスクリーンが申請者とアシスタントのスクリーンに現れる。代わりに、申請者のコンピュータに音声技術が取付けられているならば、申請者はヘッドセットによりアシスタントと通信する。
【０１０８】
代わりに、システム23の全てのユーザが電話および書類またはファックスされた通信を含むさらに一般的な通信手段を使用してもよい。
【０１０９】
・多数のプロダクト／貸主の自動化された保証
申請者がダイナミック電子様式８を完成した後、申請は保険の準備がされる（即ち査定）。前述したように、システム23は申請が１人以上の貸主のクレジット基準にしたがって評価されることを可能にする。
【０１１０】
多数のプロダクト自動化された保証13は、申請情報の完全なセットが集められたときにのみ行われることができることに注意すべきである。システム23はこの条件が前述したようにダイナミック電子様式８とスーパーセット決定方法12により満たされることを確実にする。さらに、多数のプロダクト自動化された保証13は介在２または直接申請者５によりアクセスされることができ、ユーザは申請を評価すべき貸主21を（即ち貸し基準に対して）選択することができる。この嗜好は介在制御モジュール６または直接申請者制御モジュール７でユーザにより示される。しかしながら、選択を行うユーザが全てのプロダクトに対して評価された申請を有し、どれを遂行するかを決定することがさらに有効である。
【０１１１】
システムが異なる貸主の実効的に限定されていない数の基準とルールを有することができるとき、マルチプロダクト資格を実行でき、簡単にされたクレジットスコアリング（即ち、保険スコアに基づく申請の査定）に依存する必要はない。
【０１１２】
例では、多数のプロダクト自動化保険13は各貸主21の必要なクレジット基準を計算し、申請の資格を有するか否かをチェックする。多数のプロダクト自動化保証13はその後、以下の結果を生成する。
クレジット基準 貸主Ａ 貸主Ｂ 貸主Ｃ
ローン額 ・ＯＫ ・ＯＫ ・ＯＫ
保証 ・ＯＫ ・ＯＫ ・ＯＫ
実質上の黒字＊ − ・ＯＫ ・不履行
債務サービス比＊ ・ＯＫ − −
立て直し限度 ・ＯＫ ・ＯＫ ・ＯＫ
アイデンティティ ・ＯＫ ・ＯＫ ・ＯＫ
最終決定 ・承認 ・承認 ・拒否
この同時的なクレジット評価の結果は直接申請者制御モジュール７、好ましくはインターネットで送信される電子メールによってすぐに申請者へ通信される。この点で、Hall氏は貸主Ａと貸主Ｂの選択を行うことができ、または彼は“オークション”に入力することを選択できる（以下説明するローン交換を参照）。この簡単化された例では、申請者はその人のプロダクト嗜好を尋ねられない。実際には、申請者は、どのプロダクト特徴が好みであるかを示し、結果として、申請が申請者の基準外にあるプロダクトに対して承認されることが可能である。しかしながら、このような場合、申請者はその申請を断念するか、緩和するか、さもなければ申請者の嗜好の資格を得なければならない。
【０１１３】
・遠隔申請管理
システム23の重要な好ましい特徴は、申請プロセスが遠隔的に管理されることができる。システム機能の段階的な説明を以下行う。
【０１１４】
システムはインターネットのような既存の通信リンクによってコンピュータ３または５により介在２または直接申請者５によってアクセスされる。ユーザはユーザタイプにしたがって、介在制御モジュール６または直接申請者制御モジュール７に遭遇する。介在制御モジュール６と直接申請者制御モジュール７は、オープンアーキテクチャで説明したように介在２または直接申請者５に関する多数の選択肢を有する。申請を提出するために、ユーザはメニューからこの選択肢を選択する。
【０１１５】
ユーザは、スーパーセット決定方法12に依存するダイナミック電子様式８により表示された質問に回答するように進行する。申請プロセス中の任意の時間に、ユーザはアシスタントと接触するためにシステムの実時間援助９の特徴を使用してもよい。ダイナミック電子様式８を完了後、システムはユーザにより与えられた回答と好みにしたがって多数のプロダクト自動化保証を行うことができる。ユーザはその後、クレジット決定と、選択肢が何であるかを知る。
【０１１６】
この時点で、財務プロダクトと貸主の要求に基づいて、ユーザは１以上の以下の事項を行う必要がある。
・署名した文書の返送。ユーザが任意の署名文書を返送する必要があるならば、これらの文書は以下の方法、即ち必要な様式の電子ダウンロード、電子ファイル転送または典型的な転送１でユーザにより獲得されることができる。１例として、貸主は典型的にハードコピーの署名した申請様式が申請者から獲得されることを必要とする。
・支払いの実行。ユーザが支払いを行うことを必要とするならば、財務／支払いモジュール１１がアクセスされ、ユーザは幾つかの方法のうち１つの方法で支払いを行う能力を有する。ユーザがクレジットカードの詳細を電子様式に入力することによりクレジット／デビットカードによって、指定された勘定に直接預金することによって、勘定を差引きまたは請求するために書込まれた証明書を与えることによって（様式は同様の他の文書から検索されることができる）、または典型的な転送１による支払いを行うことによって支払いをする。支払いは例えば申請が抵当財務であるならば、評価を行う必要がある。
・他の支援文書化を行う。ユーザが他の支援文書化を供給する必要があるならば、これはリクエストされた文書を電子的に転送することにより、または典型的な転送１により実行されることができる。リース、抵当財務、商用財務のようなさらに複雑な財務トランザクションでは、多量の支援文書化が貸主21により必要とされる。
・第３パーティのサービスのアレンジ。ユーザが第３パーティのサービスのアレンジを必要とするならば、これは介在制御モジュール６または直接申請者制御モジュール７により電子的に実行されることができる。例えば抵当財務の場合に評価のスケジュール化が必要とされるならば、ユーザは介在制御モジュール６または直接申請者制御モジュール７からアクセスされる電子スケジュールにより好ましいアポイントメント時間を示すことができる。
【０１１７】
前述したように、幾つかの財務プロダクトの申請プロセスはある第３パーティの確認を含んでいる。この確認は第３パーティのサービスプロバイダ18またはユーザにより実行される。例えば、小さい差額のローン（例えばクレジットカード、個人ローン）では、クレジット情報保管（repository）による申請情報の確認は幾らかの貸主により十分であるように見える。さらに大きな差引勘定のローン、特に抵当では、申請情報は多数の第３パーティのサービスプロバイダ18（例えば土地名、評価者、ＣＲＡＡ）と申請者が与えた情報（例えば銀行の明細、給与明細スリップ）により確認される必要がある。
【０１１８】
第３パーティのサービスプロバイダ18は第３パーティ制御モジュール16をアクセスすることによりコンピュータ19によって任意の適切な通信リンクを介してシステムをアクセスし、サービスを提供できる。ここから、第３パーティのサービスプロバイダ18は実行された任意のサービスの結果を提供でき、これはその後、申請とその進行の全ての詳細を含んでいるデータベース14へ更新される。
【０１１９】
システム23の重要な好ましい特徴は、介在制御モジュール６と直接申請者制御モジュール７であり、これらはユーザ／申請者が（現在通常行われているように、問合わせに回答する必要のある情報を得るために内部の接触をチェックする貸主21に電話をするのではなく）実時間で申請の状態を追跡することを可能にする。
【０１２０】
しかしながら、システム23は、ユーザが介在２および直接申請者５の両者を含むそれぞれの制御モジュールの追跡申請選択肢を選択することによって申請の進行を観察することを可能にする。この選択肢は申請に関する全ての情報を含んだデータベース14をアクセスする。例えば、これは会計事務所により行われる全てのコメントと動作のノートブックであるダイアリーノートを含んでいる。
【０１２１】
したがって、ユーザは何の動作が特定のローン申請で行われていかを点検することができる。例えば、ユーザは受信されたおよび受信されていない支援文書を詳細に示したリストを点検することができる。ユーザは評価報告が含まれているならば、これを観察することができる。ユーザは申請に関して行われた任意の支払い歴を観察できる。勿論、ユーザは代わりに電話または書類またはファックスされた通信の伝統的な手段によって申請条件について問合わせることができる。
【０１２２】
システムの別の好ましい特徴は、申請のファイルまたはデータベース14に対する任意の変更または修正が所望の応答をトリガーすることである。例えば評価報告は第３パーティのサービスプロバイダ18から受信され、この報告がデータベース14に更新されるとき、システムは電子メールによって自動的に評価報告の受信をユーザへ通知するメッセージをユーザへ送信する。このメッセージは代わりに典型的な転送１により送信されてもよい。
【０１２３】
例を参照すると。以下の表は残りの実行されるべき確認作業と、申請者がシステム23によって回答する態様を要約している。
確認動作 方法
返送された署名 ・以下の１つの方法で予めファイルされた
申請 申請様式を受けることができる：
様式 −ダウンロード
−電子的な転送
−投函、ファックスまたはクーリエによる送信
・実際の署名またはファックされたコピーは返送
されなければならない
スケジュール評価 ・好ましい評価日付と時間を選択する
アポイントメント
評価に対する ・以下の任意の手段により支払いを実行できる
支払いの実行 −オンラインでクレジットカードによる支払い
−ファックス許可は勘定を差引き／請求するために
（ダウンロードまたは印刷されることができる）
−指定された銀行の口座へ直接預ける
−投函またはクーリエにより小切手を転送できる
・組合に戻される ・以下の任意の文書が以下の方法により送信される
税の提供 ことができる。
・給与明細スリップ −電子イメージ
またはグループ証明 −ファクシミリ、クーリエまたは投函
の提供
・最近の抵当明細
の提供
・最近のクレジット
カード明細の提供
・最近の個人ローン
明細の提供
・最近の自動ローン
明細の提供
この例では申請者は、任意の時間に申請の最近の展開を観察するために直接申請者制御モジュール７をアクセスすることができる。ここで、申請者は支払いが行われたとき全ての未払いの支援情報と、評価報告の結果と、予測された決算時間を観察できる。さらに、申請者は勘定に関する任意のダイアリーノートを再検討し、自動的にこの申請ファイルに対する変更を通告される。
【０１２４】
先の記述で説明され、例が示しているように、システム23はユーザが遠隔的に申請プロセスを管理することを可能にする。システム23は文書を処理し、受信し、送信し、通知書を送信し、財務プロダクトの申請の進行を追跡する。
【０１２５】
・自己サービス
ローン勘定を管理する現在の実際は人間の対話に依存している。例えばユーザが勘定の明細を必要とするならば、呼または書込まれたリクエストが貸し機関へ行われなければならない。しかしながら、システム23は、資金が財務／支払いモジュール11により支払われた後にユーザがローン勘定の業務を遠隔的に行うことを可能にする。
【０１２６】
介在２または直接申請者５は介在制御モジュール６または直接申請者制御モジュール７を通じてサービスモジュールをアクセスすることによりローン勘定を管理する。サービスモジュールはユーザが以下のことを電子的に行うことを可能にする。
・ローン勘定明細を観察し、印刷し、ダウンロードし、受信し、
・支払い日付を変更し、
・支払い額を変更し、
・指定された口座情報を変更し、
・コンタクト情報を修正し、
・支出総額を決定し、
・付加的な進行をリクエストし、または、
・ローン勘定に関する何らかのことについて問合わせる。
【０１２７】
ユーザはまた電話または書類またはファックスされた通信のさらに一般的な手段によりアシスタントと接触できる。しかしながら、この特徴は便利であり、申請者にサービスする価格を低下する。
【０１２８】
・介在システム
システム23のオープンアーキテクチャのために、これは財務ブローカー、財務プランナー、および会計士によりアクセスされることもできる。このようなサービスを求めるカスタマに対しては、これらの介在２は彼等に代わって申請を提供できる。
【０１２９】
ブローカー団体は全ての財務申請の１０％を超える役目を行う。システム23はまたこの産業に以下のものを含む特徴のアレイを提供する。
・販売強化管理ツール、
・生産性の見積もりおよび予算、
・進行中の全ての申請についての情報、
・全ての紹介されたカスタマについての情報、
・紹介されたビジネスの実行統計。
【０１３０】
このような特徴は必要なときに修正され増加されることができる。このような特徴はデータベース14から必要な情報を抽出して操作する介在制御モジュール６を介してアクセスされる。
【０１３１】
・ローン交換
システム23はローンのオークションとして動作する。このようなオークションを行うために、最小の合理的なレベルの参加者が存在しなければならない。それ故、システムが頑強なオークションを有するために必要な数の参加者を有することを想定するならば、システム23は適切に順番にオークションを行うことができる。
【０１３２】
オークション制御モジュール15はオークションシステムを統制する。ローンの競売を選択したユーザは彼等の好みを集収し、存在していれば、種々のカテゴリに分類する。例えば幾らかのユーザは報酬プログラムを有するクレジットカードだけを所望する。それ故、この好みは参加する貸主21の数を減少する。
【０１３３】
貸主21は貸主制御モジュール17によりオークション制御モジュール15にアクセスできる。貸主21は彼等が望む基準により入札するのに有効なローンを分類できる。本発明はスーパーセット決定方法12を使用するので、それらに関する全ての情報はデータベース14から検索され表示されることができる。
【０１３４】
例を参照すると、申請者は貸主Ａ、貸主Ｂにより抵当を承認された。申請者が望むならば、彼のビジネスを最低の入札者にするように選択できる。このオークション前に、申請者の申請は他のユーザの申請と共に、参加している貸主21により観察される。貸主21は申請のクレジット基準を再検討できる。例えば貸主21は所望ならば実質上の黒字により分類することができる。
【０１３５】
規則的な間隔で、オークション制御モジュール15は申請の参加している貸主21により提示された種々の入札を行うことを開始する。オークション制御モジュール15は最も適切な条件（例えば、オランダ人、盲人、最良の入札）に基づいて、種々のオークションスタイルを管理することができる。オークションのデッドラインで、貸主21は最低の利子率（または決定される他の尺度）を提供している貸主21がその申請の勝者である。
【０１３６】
申請者が貸主Ａにより６．２５％、貸主Ｂにより６．１５％の率を提供されるならば、申請者はおそらく貸主Ｂで進めるであろう。代わりに、オークション前に申請者がデータベース14により捕捉され、オークション制御モジュール15により管理される条件数を特定してもよい。例えば、申請者は６．００％の最低競売率を設定してもよい。この場合、ローンは任意の入札する貸主21へは行かない。申請者が緊急に財務を必要としないならば、このような方法は申請者により使用される。
【０１３７】
オークション制御モジュール15の別の使用例では、申請者は倉庫の抵当を獲得することを考えることができる。それ故、申請者は貸主21への１つの提供として彼の財務をまとめてもよい。この条件はオークション制御モジュール15により認識され、入札する貸主21へ通信されよう。
【０１３８】
・貸主アクセス
本発明は貸主制御モジュール17を介して貸主21によりアクセスされることもできる。ここで貸主21は、クレジット基準の変更、全ての資金申請の観察、先のオークション結果の再検討、新しいカスタマの見積もり数、プロダクトの分割、ビジネス全体のシェア等を含む多数の作業を行う能力を有するが、それらに限定されない。新しい特徴と強化は貸主の要求とフィードバックに基づいて付加されることができる。
【０１３９】
したがって、システム23は任意の直接申請者５または介在２が、幾つかの貸主により提供された幾つかのローンプロダクトの申請を同時に自動的に保証できるシステムを遠隔的にアクセスすることを可能にする。システム23はまたユーザが申請プロセスを遠隔で追跡し作業することを可能にし、申請者がカスタマになったならば、そのなったときに、ユーザがローン勘定を遠隔的に管理することを可能にする。さらに。システム23は最良の入札で貸主21へローン申請を競売することができる。システムはまた複数の価値が付加されたサービスを貸主21と他の第３パーティのサービスプロバイダ18へ提供する。
【０１４０】
本発明の技術的範囲内の変形が当業者により容易に行われる。それ故、本発明は前述の例により説明された特定の実施形態に限定されないことが理解されるであろう。
【図面の簡単な説明】
【図１】 本発明の好ましい実施形態にしたがったローン申請システムのステップおよびコンポーネントを示しているフローチャート。
【図２ａ】 図１のシステムにしたがった電子様式Ｎｏ．１を示す図。
【図２ｂ】 図１のシステムにしたがった電子様式Ｎｏ．２を示す図。
【図２ｃ】 図１のシステムにしたがった電子様式Ｎｏ．３を示す図。
【図２ｄ】 図１のシステムにしたがった電子様式Ｎｏ．４を示す図。
【図２ｅ】 図１のシステムにしたがった電子様式Ｎｏ．５を示す図。
【図２ｆ】 図１のシステムにしたがった電子様式Ｎｏ．６を示す図。
【図２ｇ】 図１のシステムにしたがった電子様式Ｎｏ．７を示す図。
【図２ｈ】 図１のシステムにしたがった電子様式Ｎｏ．８を示す図。

Claims (22)

1. 申請者によって行なわれた申請を受信して評価する装置において、
   前記装置は、
   前記申請者に複数の申請様式を与え、前記申請者から一度完成された前記申請様式を受取り、前記申請を評価するように構成されている計算手段と、
   前記申請者が前記申請様式を完成させて、前記申請様式を前記計算手段に戻すための入力手段と、
   前記申請の評価を前記申請者に通信または送信する通信手段と、
   を具備し、
   前記計算手段は、ダイナミック電子様式モジュールおよび評価モジュールを含み、
   前記ダイナミック電子様式モジュールは、
   （ｉ）一度完成されて前記申請者から受信された前記複数の申請様式のうちの第１の申請様式で前記申請者によって前記入力手段を用いて与えられた情報に基づいて、新しい申請様式である第２の申請様式を構成し、前記第２の申請様式を構成することは、一度完成されて受信された前記第１の申請様式で前記申請者によって与えられた情報に基づいて、前記第２の申請様式に含まれる１つ以上の質問を選択することを含み、
   （ｉｉ）前記複数の申請様式のうちの以前に完成されて受信された申請様式で前記申請者によって前記入力手段を用いて与えられた情報に基づいて、前記複数の申請様式のうちの任意の後続する申請様式を順次構成し、前記任意の後続する申請様式を順次構成することは、前記以前に完成されて受信された申請様式で前記申請者によって与えられた情報に基づいて、前記後続する申請様式の各々に含まれる１つ以上の質問を選択することを含む、
   ように構成されており、
   前記申請は、前記申請者から一度受信された前記複数の申請様式から構成され、
   前記評価モジュールは前記申請を評価するように構成され、
   前記計算手段は、前記通信手段によって、前記申請の評価の結果を通信するように構成されている、装置。
2. 前記評価は前記申請の承認または拒否を指示するか、あるいは前記申請の承認または拒否が可能になる前にさらに別の情報または人間の介在が必要とされることを指示する請求項１記載の装置。
3. 前記複数の申請様式は、複数の申請様式の複数のグループの１つである請求項１記載の装置。
4. 前記装置は前記申請様式を提供するための表示手段を含んでいる請求項１記載の装置。
5. 前記計算手段は遠隔表示手段に前記申請様式を表示することができる請求項１記載の装置。
6. 前記遠隔表示手段は、コンピュータネットワークによって前記装置に接続されているコンピュータである請求項５記載の装置。
7. 前記コンピュータネットワークはインターネット、ワールドワイドウエブ、商業的オンラインサービス、対話型放送、またはその他の電子オンライン手段である請求項６記載の装置。
8. 前記入力手段は、任意の適切なコンピュータまたはコンピュータ入力手段、またはコンピュータキーボード、またはコンピュータのマウス、または前記計算手段に接続された電子ペンである請求項１記載の装置。
9. 前記入力手段は、コンピュータネットワークによって前記装置に接続されている請求項１記載の装置。
10. 前記通信手段は、電子情報転送システムである請求項１記載の装置。
11. 前記装置は、前記申請の評価において考慮するために外部データベースまたはその他の情報ソースから付加的な情報を得るための通信リンク手段を含んでいる請求項１記載の装置。
12. 前記装置は、
    複数の申請受者の承認基準にしたがって前記申請を評価するために十分な前記複数の申請様式を前記申請者に与えるように構成またはプログラムされ、
    前記複数の申請受者のうちの各申請受者のそれぞれの承認基準に対して前記申請を評価し、それによって前記複数の申請受者のうちの各申請受者に対するそれぞれの別々の評価を形成するように構成またはプログラムされている請求項１記載の装置。
13. 前記装置は、前記複数の申請受者のうちの各申請受者に対する多数の別々の承認基準にしたがって前記申請を評価するように構成またはプログラムされている請求項１２記載の装置。
14. 前記装置は、前記複数の申請受者へ、複数のそれぞれの評価を通信するように構成またはプログラムされている請求項１２記載の装置。
15. 前記装置は、前記複数の申請受者のうちの各申請受者の前記それぞれの承認基準を調節することができる請求項１２記載の装置。
16. 前記装置は、前記情報および／または前記申請の状態の一部または全部を前記申請者に表示または送信することができる請求項１記載の装置。
17. 前記装置は、
    援助を要求することができ、
    アシスタントが前記申請者にアドバイスできるように前記申請の詳細を前記アシスタントに通信することができる請求項１記載の装置。
18. 前記アシスタントは、前記申請者によって完成される期間中に、前記申請様式のうちの１以上を見ることを可能にされている請求項１７記載の装置。
19. １以上の申請受者に対して申請者によって行なわれた申請を受信して評価する方法において、
    前記方法は、
    前記申請者に複数の申請様式を提供し、
    前記申請者から一度完成された前記申請様式を計算手段が受取り、
    前記計算手段により前記申請を評価することを含み、
    前記申請を受信して評価する方法はさらに、
    ｉ）前記計算手段により前記申請者に前記複数の申請様式のうちの第１の申請様式を与え、
    ii）前記計算手段は、前記申請者により入力手段を用いて前記第１の申請様式が完成されたとき、前記申請者から前記第１の申請様式を受信し、
    iii)前記第１の申請様式で前記申請者により与えられた情報に基づいて前記計算手段のダイナミック電子様式モジュールにより新しい申請様式である第２の申請様式を構成し、前記第２の申請様式を構成することは、一度完成されて受信された前記第１の申請様式で前記申請者によって与えられた情報に基づいて、前記第２の申請様式に含まれる１つ以上の質問を選択することを含み、
    iv）前記第２の申請様式を前記計算手段によって前記申請者に提供し、
    ｖ）前記計算手段は、前記申請者により前記入力手段を用いて前記第２の申請様式が完成されたとき、前記申請者から前記第２の申請様式を受信し、
    vi）前記複数の申請様式のうちの以前に完成されて受信された申請様式で前記申請者により与えられた情報に基づいて、前記ダイナミック電子様式モジュールによって前記複数の申請様式のうちの任意の後続する申請様式を順次構成し、前記任意の後続する申請様式を順次構成することは、前記以前に完成されて受信された申請様式で前記申請者によって与えられた情報に基づいて、前記後続する申請様式の各々に含まれる１つ以上の質問を選択することを含み、
    vii)前記計算手段の評価モジュールにより、前記申請者から一度受信された前記複数の申請様式から構成される前記申請を評価して前記申請の評価を形成し、
    viii)前記計算手段は、通信手段によって前記申請の評価の結果を通信することを含む、申請を受信して評価する方法。
20. 前記方法は、前記複数の申請様式を提供する順番を決定することを含み、
    前記複数の申請様式を提供する順番を決定することは、
    複数の申請承認基準を収集し、
    前記申請承認基準の相互の依存性を決定し、
    多数の質問を冗長にし得る情報を要求する申請様式を、前記順番の中の前の方に配置することを含んでいる請求項１９記載の方法。
21. 前記方法は、前記複数の申請様式を提供する順番を決定することを含み、
    前記複数の申請様式を提供する順番を決定することは、
    前記順番の中の前の方の部分の申請様式において、前記申請の拒否をもたらす可能性のある応答を伴う質問を提供することを含む請求項１９記載の方法。
22. 記録されたプログラムを有するコンピュータ読取り可能媒体において、
    前記プログラムは、請求項１９乃至２１のいずれか１項記載の方法をコンピュータに実行させる、コンピュータ読取り可能媒体。

Images