JP2011018351A - アプリケーション装置および方法 - Google Patents

Abstract

【課題】アプリカントにより行われるアプリケーションの受信および評価用装置および方法を提供する。
【解決手段】アプリカント５に複数のアプリケーション形態を与えてアプリカント５から一度完成された前記形態を受取り、アプリケーションを評価するように構成またはプログラムされた計算手段と、形態を完成させて計算手段に戻すアプリカント５用の入力手段と、アプリケーションの評価を前記アプリカント５に通報または送信する通信手段とを具備し、前記計算手段は、完成されて受信された形態で入力手段によってアプリカントにより与えられた情報に基づいて複数の形態の第２およびそれに続く形態を順次構成するように構成またはプログラムされてアプリケーションを評価し、通信手段によって評価を通報する。
【選択図】図１

Description

本発明は例えば財務ローンの申請および承認を受ける等の財務特性の１つの団体から１以上の他の団体により行われたアプリケーションを提出し考察する装置および方法に関する。

団体は以後、一方ではアプリカントと呼び、他方では（アプリケーションの）レシピエントと呼ぶ。例えば財務ローンアプリケーションのコンテキストではレシピエントは（銀行または他の財務機構のような）貸主であってもよい。さらに、本発明の多数のさらなるアプリケーションは基本的に、アプリカントによりレシピエントへ行われたアプリケーションの提出と、その後の評価と、承認または拒否を含むトランザクションで考慮される。

例えば（クレジットカード、個人ローン、自動車ローン、抵当等の形態の）金融の申請を実行するには通常、アプリカントが多くは自分でまたは電話によって例えば貸主の形態のレシピアントと接触をもち、ローンアプリケーションを口答でまたは書類で申込むことにより完成し、その後で貸主により考慮されることを必要とする。貸主は実際に数人の貸主のうちの一人であってもよく、それによってアプリカントは可能なローンの価格および特徴を比較でき、或いは貸主がアプリケーションを拒否し、アプリカントに別のローンを探させる。これは特定の多額のローンを探す場合に特に望ましいことが多い。代わりに、この多数の貸主と相談する仕事は、アプリカントの代わりに有効な選択肢を比較する情報または財務ブローカーによりアプリカントの代わりに実行されることができる。

しかしながら、アプリケーションプロセスと必要な情報は各貸主で異なり、各貸主はいずれにしても返済可能ではない料金を有し、そのためアプリカントは共通して、可能ならば一人の（例えば推薦されたまたは過去に使用した）貸主と交渉を進める。結果として、アプリカントは選択した貸主（またはブローカー）と定期的に接触を維持し、典型的な手順を経てアプリケーションを完成する。これらは、アプリケーション形態の完成後の文書の編集、貸主との面接、提出された情報の具体化等を含んでいる。これらのステップは、多くの場合にアプリカントにより与えられた多量の情報がその決定に直接的な関係がなくても、貸主の標準アプリケーションプロトコルの一部を形成し、クレジット決定が行われる前に貸主により完成されることが必要であり、貸主が情報または文書の標準的なアレイをリクエストする遅延を最小にし、これは実際には全てのケースで必要とされるわけではない。

しかしながら多くの状況では、特に多額のローンでは、アプリケーションの完成はそれ自体、貸主がアプリケーションの事項を理解しようとして全ての必要な情報を確認するので多くの反復を含んでいる。これはアプリカントへ数回または多数回戻すことを必要とする。これに対処するため、数人の貸主は複雑なアプリケーションを再検討するためにさらに熟練した保険業者を使用する。例えば自営業の借用人からの抵当アプリケーションは困難であると考慮され、熟練した人員の応対を必要とする。（ルールとして、ローンの大きさが小さい程、アプリケーションを評価するのに人間の関与が少ない）しかしながら、各アプリケーションには非常に多くの変形があり、結果として数百万の異なるアプリケーションプロフィールが存在するので、最も熟練した保険業者さえも通常クレジット決定を行う前に幾つかの明瞭にするまたは補足的な質問を尋ねる必要がある。

さらに、既存の紙面のアプリケーション形態はその利用性とフレキシブル性で限定を受け、１つの形態では全ての可能なシナリオをカバーできない。これは標準的な形態のストックを維持し、それぞれの場合に最も適切なものを選択することにより時折解決されるが、この方法は個々のケースが例えば多数のプロダクトおよび多数の貸主、さらに多数のアプリカントで生じるときにはすぐに限界に達する。

ローンが承諾されるならば、ローン勘定の規則的な維持は貸主とローンアプリカント（カスタマ）との間の書類または口答の通信を通常必要とする。

アプリケーションプロセスを自動化する試みが行われ、それによって必要とされる人間の関与が少なくなる。しかしながら典型的に、これは（インターネットのような）コンピュータネットワークによりアクセスされ、完成され、提出されることができるアプリケーション形態を貸主が準備することを含んでいる。アプリケーションプロセスはその後、伝統的なラインに沿って進行し、貸主が電子アプリケーション形態を幾らか予備的に考察した後、ローンアプリカントは接触をもたれ、前述したようにプロセスは進行する。

米国特許第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 (41)

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. 前記方法は、前記１以上のレシピエントに対するアプリケーション承認基準を集収し、互いに前記基準のそれぞれの依存性を決定し、内容が高いまたは最大の可能性で、遅れたクエッション冗長の数を有する情報のリクエストを前記シーケンス形態で促進し、後続する形態から前記冗長クエッションを除去するステップを含んでいる請求項２４記載の方法。
26. 前記方法は、初期の形態で任意のクエッションを提供し、それにおいて、前記各クエッションの場合に対する応答がアプリケーションのただちの拒否に導く請求項２４記載の方法。
27. 前記方法は、前記シーケンスを続いて調節するステップを含んでいる請求項２６記載の方法。
28. アプリカントによって行なわれたアプリケーションを受取って評価するための装置において、
    アプリケーション情報を受信し、前記アプリケーションを評価するように構成されたはプログラムされている計算手段を具備し、
    前記装置は、複数のアプリケーションレシピエントのアプリケーション承認基準を含み、或いはアクセスし、
    前記計算手段は、複数のアプリケーションレシピエントのそれぞれの前記承認基準にしたがって前記アプリケーションを評価するように構成され、またはプログラムされ、それによって前記装置は前記複数のレシピエントのそれぞれに対してそれぞれ別々の評価を形成することを特徴とする装置。
29. 前記装置は、前記アプリカントに対してシーケンスで多数のクエッションまたは多数のセットのクエッションを提供し、前記アプリカントからの前記クエッションに対する応答を受信し、前記アプリケーション情報は、前記応答を構成し、或いは前記応答から決定され、前記装置は、前記クエッションまたはクエッションのセットの数を減少または最小にしてシーケンスを最適にするように構成またはプログラムされている請求項２８記載の装置。
30. 前記装置は、前記計算手段に前記アプリケーションを入力するためのアプリカントに対する入力手段と、
    前記アプリカントに前記アプリケーションの評価を通報または送信する通信手段とを具備している請求項２８記載の装置。
31. 前記計算手段は、前記アプリカントに複数のアプリケーション形態を提供し、前記アプリカントから一度完成した前記形態を受取り、前記アプリケーションを評価するように構成またはプログラムされ、
    前記計算手段は、前記完成されて受信された形態で前記入力手段によってアプリカントにより与えられた情報に基づいて前記複数の形態の第２および後続する形態を順次構築して前記通信手段によって前記評価を通報するように構成され、プログラムされている請求項２８記載の装置。
32. アプリカントによって行なわれたアプリケーションを受取って評価するための方法において、
    前記アプリカントからアプリケーション情報を受取り、
    複数のアプリケーションレシピエントのそれぞれの承認基準にしたがって前記アプリケーションを評価し、
    前記複数のアプリケーションレシピエントのそれぞれに対してそれぞれ別々の評価を形成することを特徴とする方法。
33. 前記アプリカントに対して多数のクエッションまたは多数のクエッションのセットをシーケンスで与え、
    前記アプリカントから前記クエッションに対する応答を受信し、前記アプリケーション情報は前記応答から構成され、或いは前記応答から決定され、
    多数のクエッションまたは多数のクエッションのセットを減少させ、または最小にするようにシーケンスを最適化するステップを含んでいる請求項３２記載の方法。
34. 前記方法は、前記アプリケーションの前記評価を前記アプリカントに通報または送信するステップを含んでいる請求項３２記載の方法。
35. アプリカントによって行なわれたアプリケーションを処理する方法において、
    前記アプリカントからアプリケーション情報を受信し、
    複数のアプリケーションレシピエントに対して前記情報を提供し、
    前記１以上のレシピエントからの前記アプリケーションに対する１以上の要求を受信し、
    前記１以上の要求のそれぞれの選択または拒否のために前記アプリカントに前記１以上の要求を転送することを特徴とする方法。
36. 前記複数のレシピエントのそれぞれに対して前記アプリケーションのそれぞれ別々の評価を形成するステップを含んでいる請求項３５記載の方法。
37. 前記方法は、前記情報の調整の選択または拒否にしたがって前記各要求を調整するステップを含んでいる請求項３５記載の方法。
38. アプリカントによって行なわれたアプリケーションを処理する装置において、
    前記アプリカントからアプリケーション情報を受信するように構成またはプログラムされ、前記情報を複数のアプリケーションレシピエントに導き、１以上の前記レシピエントから前記アプリケーションに対する１以上の要求を受信し、前記１以上の要求のそれぞれの選択または拒否のために前記アプリカントに前記１以上の要求を転送するように構成またはプログラムされた計算手段を具備していることを特徴とする装置。
39. コンピュータの内部メモリにロード可能なプログラム製品において、
    前記製品がコンピュータにおいて動作されるとき請求項２４乃至２７または３２乃至３７のいずれか１項記載の方法のステップを実行するためのソフトウエアコード部分を具備していることを特徴とする装置。
40. コンピュータの使用可能な媒体に記憶されているコンピュータプログラム製品において、
    請求項２４乃至２７または３２乃至３７のいずれか１項記載の方法のステップをコンピュータに実行させるためのコンピュータの読取り可能なプログラム手段を含んでいることを特徴とするプログラム製品。
41. 記録されたプログラムを有するコンピュータの読取り可能な媒体において、
    前記プログラムは、請求項２４乃至２７または３２乃至３７のいずれか１項記載の方法をコンピュータに実行させるためのプログラムであることを特徴とするコンピュータ読取り可能な媒体。

Images