JP2001202459A

JP2001202459A - 自動口座開設システムおよび方法、ならびに自動口座開設システムおよび方法を使用するための場所

Info

Publication number: JP2001202459A
Application number: JP2000353444A
Authority: JP
Inventors: Anthony Michael Jabbour; マイケルジャボアアンソニー; Brian Michael Cassidy; マイケルキャシディーブライアン
Original assignee: Canadian Imperial Bank of Commerce
Current assignee: Canadian Imperial Bank of Commerce
Priority date: 1999-11-20
Filing date: 2000-11-20
Publication date: 2001-07-27
Also published as: EP1102224A3; EP1102224A2

Abstract

(57)【要約】（修正有）【課題】預金口座申し込み処理ネットワークを提供す
る。【解決手段】申込者システムは、申込者情報を預金口
座申し込みデータに変換する。預金口座申し込み処理ネ
ットワークは、預金口座申し込みデータを処理する申し
込み処理システムを備え、預金製品に対する資格が申込
者にあるか否かを判定する資格付与要求を作成するため
に、申し込みデータを受け取るシステムを有する。この
処理システムは、資格付与要求に対する応答を受け取る
ためのシステム、資格付与要求に対応して所望の預金製
品を承認するためのシステム、および承認された預金製
品について申込者がアクセスできる預金口座を開設する
ためのシステムをさらに有する。資格付与要求は第三者
システムあるいは処理システムそれ自体によって処理さ
れる。申込者システムは、ＡＴＭ、インターネット端
末、および電話を備えたキオスクの一部であってもよ
い。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明の分野は、一般に、預
金口座を開設するためのシステムおよび方法に関する。

【０００２】

【従来の技術】現在金融サービス業界は、かなりの窮境
にさらされている。顧客は自分の金銭を管理する時間が
ますます少なくなりつつある。同時に、連邦預金保険公
社（ＦＤＩＣ）または他の管轄権内にある同様の委託預
金保険からの連邦預金保険によってカバーされた、銀
行、貯蓄、信託、および他の預託機関などの預金預かり
機関（deposit taking institution）は、潜在的な顧客
基盤が伸び悩む一方で、市場への新規参入者との競争、
および証券会社など金融サービスの代替形式が増えつつ
あるという事態に直面している。

【０００３】従来の支店およびその営業時間の拡大は顧
客側からすれば望ましいことであるが、預金預かり機関
にとっては、費用が法外に高いだけである。たとえば、
各銀行支店が認証を必要とし、関連する規定権限の莫大
な要件を満たさなければならない。これらの費用は、製
品保有者がサービス料および製品に関する収益率を下げ
ることによって支えられる。

【０００４】預金預かり機関は、インターネットバン
ク、テレフォンバンキング、および現金自動預け払い機
（ＡＴＭ）を含む、機関への代替アクセスモードを開発
してきた。銀行の場合、従来の銀行支店で開始された取
引の処理費用は、ＡＴＭまたはインターネットバンキン
グ取引の費用よりも多くかかる。１９９６年７月に出版
された「ＣｏｎｓｕｍｅｒＤｅｍａｎｄｆｏｒＩ
ｎｔｅｒｎｅｔＢａｎｋｉｎｇ」と題するＢｏｏｚ
Ａｌｌｅｎ＆Ｈａｍｉｌｔｏｎによる米国研究の結
論によれば、銀行支店が銀行取引を完了させるための費
用が平均で＄１．０７であるのに対して、ＡＴＭによる
取引は＄０．２７、インターネットによる取引は＄０．
０１である。これらは非常に役立つツールであるが、顧
客が預金預かり機関の支店での受け取りに使用している
便利さを提供するものではない。

【０００５】これについては、銀行で預金口座を開設す
るための手続きを参照しながら例示することができる。
銀行は、異なるタイプの銀行サービスを提供できる製品
を顧客に提供する。たとえば銀行は、預金引出の量、頻
度、およびタイプに制限があり、適度なサービス料を有
する基本的な貯蓄預金製品、および異なる制限およびア
クセス権のある当座預金製品を提供することができる。

【０００６】従来、銀行口座を開設するためには、申込
者が銀行の支店へ出向き、適切な銀行員と取引をしなけ
ればならない。銀行員は申込者に対して銀行が提供して
いる製品について説明し、申込者が１つまたは２つ以上
の所望の製品を選択する。申し込み用紙の記入が完了す
ると、銀行がこの申し込みを処理する。

【０００７】処理時には、通常、申し込みが要求された
製品を保持するのに必要な基準を満たしているか否かを
判定するために、申し込みをいくつかの基準に照らして
評価する。たとえば、超過引出し保護を備えた預金口座
を開設する場合、銀行は口座開設前に、申込者が優良な
信用履歴（credit history）および最低額の資金を有す
ることを要求する。申込者の状況は、申込者が利用でき
る製品のタイプにも影響する場合がある。たとえば、申
込者の年令および所在地（管轄区の内部または外部）に
よって、申込者が利用できる製品のタイプに影響を与え
る場合がある。

【０００８】厳密に言えば、預金口座を持つためには、
申込者に関する信用報告書は必要ない場合がある。ただ
し、封をした封筒をＡＴＭに入れることで預金が可能で
あり、超過引出（overdraft）しまたはマイナス残高（n
egative balance）が許容される預金口座の場合、申込
者の超過引出しを供給することの好適性に関する情報を
信用報告書が提供する。したがって慎重な銀行は、口座
を開設する際に申込者の信用報告書を利用する。

【０００９】申込者の信用報告書は、Ｅｑｕｉｆａｘ
（商標）などの、第三者の信用調査所から得ることがで
きる。申込者に対してどの製品を使用できるようにする
べきかを判定するために、銀行員は申込者に関する他の
情報を備えた信用報告書を使用することができる。

【００１０】銀行員は所望の製品を承認するかまたは断
り、銀行は承認された製品を開設する。適切な銀行通
帳、小切手、クレジットカード、デビットカード、およ
びアクセスカードが申込者用に注文される。

【００１１】銀行の中には、このプロセスを改善しよう
と試みたものもある。たとえば、「Ｉｎｔｅｇｒａｔｅ
ｄＦｕｌｌＳｅｒｖｉｃｅＣｏｎｓｕｍｅｒＢ
ａｎｋｉｎｇＳｙｓｔｅｍａｎｄＳｙｓｔｅｍ
ａｎｄＭｅｔｈｏｄｆｏｒＯｐｅｎｉｎｇａｎ
Ａｃｃｏｕｎｔ」と題する米国特許第５８６６８８９
号が、１９９９年２月２日付で、Ｗｅｉｓｓ等に対して
発行された。この特許では、個人銀行業者が、対面セッ
ションで特定の顧客について推奨された製品を識別する
ため、および口座開設プロセスを支援するために、銀行
の支店で使用する販売ツールについて記載している。

【００１２】

【発明が解決しようとする課題】上記手順では、申込者
が既存の支店に出向いて製品を開設する必要がある。支
店は広く行き渡っているがどこにでもあるという訳では
ないという場合もある。さらにその営業時間により、多
くの潜在的な新製品の申込者にとって支店が近づきにく
いものになっている場合がある。

【００１３】現金自動預け払い機（ＡＴＭ）は、従来の
銀行支店に関連付けられた範囲の間接費なしで、銀行製
品保有者の口座への制限付きアクセスを提供する。一般
にＡＴＭでは、引出し、預入れ、請求書の支払い、およ
び振替えを行うことができる。ＡＴＭは、食品雑貨店な
ど、従来とは異なる便利な場所に数多く配置され、２４
時間年中無休で稼動することができる。ただし、ＡＴＭ
を使用して口座を開設することはできない。

【００１４】テレフォンバンキングおよびインターネッ
トバンキングの場合、銀行は、製品の資格を申込者に与
えるのに必要な金融情報および他の情報を収集してこれ
らを識別するが、申込者に用紙が送付され、これを機関
が受け取り、必要なチェックが実行され、機関の職員に
よって製品が承認されるまで、製品の権利は活動化され
ない（また関連する口座にもアクセスできない）。

【００１５】預金預かり口座を開設するための代替のシ
ステムおよび方法が望ましい。

【００１６】

【課題を解決するための手段】本発明は第１の態様で、
申込者識別情報を含む預金口座申し込み情報および支店
以外の場所で申込者から申込者が所望する預金製品を受
け取るための申込者システムを備えた、預金口座申し込
み処理ネットワークを提供する。さらに申込者システム
は、申込者情報をコンピュータ読取り可能預金口座申し
込みデータに変換する。預金口座申し込み処理ネットワ
ークは、申込者システムからコンピュータ読取り可能預
金口座申し込みデータを処理するための、自動申し込み
処理システムも含む。自動申し込み処理システムは、所
望の預金製品に対する資格が申込者にあるか否かを判定
するコンピュータ読取り可能資格付与要求を作成するた
めに受け取った申し込みデータを処理するための自動シ
ステム、資格付与要求に対するコンピュータ読取り可能
応答を処理するための自動システム、資格付与要求への
応答に基づいて預金製品を承認するための自動システ
ム、および承認された預金製品について申込者によりア
クセスできる預金口座を開設するための自動システムを
有する。

【００１７】申込者システムは、検証済みの識別情報を
含む申し込み情報を入力する場合に、支店以外の場所に
ある端末を使用することができる。この端末は、識別情
報を検証する係員が操作することができる。

【００１８】申し込みシステムはキオスク内に収容する
ことができる。キオスクは、預金口座向けの預金を受け
取るためのＡＴＭおよび電話を含むことができる。申し
込みシステムは、開設された預金口座にアクセスするた
めの、テレフォンバンキングインタフェースを含むこと
ができる。キオスクはインターネット端末を含むことも
可能であって、処理システムは、開設された預金口座に
アクセスするためのインターネットバンキングインタフ
ェースを有する。キオスクは食品雑貨店など系列販売店
内に設置することができる。

【００１９】資格付与要求に対する応答を処理するため
の自動システムは、申込者に関する信用履歴情報を取得
し評価することができる。資格付与要求に対する応答を
処理するための自動システムは、不正使用要素（fraud
parameters）に対して申し込み情報を評価することがで
きる。

【００２０】あるいは、申込者システムは、預金口座申
し込み情報を入力するために支店以外の場所に提供され
た端末を有することが可能であり、申込者が端末で入力
した申込者の識別情報を検証するために自動システムが
提供される。

【００２１】預金口座は銀行の預金口座であってもよ
い。処理ネットワークは、支店以外の場所を含むことが
できる。

【００２２】本発明の第２の態様では、前述の自動申し
込み処理システムが提供される。この処理システムは、
支店以外の場所にいる申込者から預金口座申し込み情報
を受け取る申し込みシステムに関連して使用される。

【００２３】本発明の第３の態様では、預金口座申し込
みを自動的に処理するための方法を提供する。この方法
は、支店以外の場所にいる申込者から、預金製品に関す
る顧客申し込み要求を受け取ることを備える。顧客申し
込み要求を受け取ることには、申し込み識別情報および
申込者所望の預金製品を受け取ることが含まれる。受け
取られた要求は、コンピュータ読取り可能預金口座申し
込みデータに変換される。顧客申し込み要求は、コンピ
ュータ読取り可能預金口座申し込みデータを処理するこ
とによって、自動的に資格を与えられる。顧客申し込み
要求に自動的に資格を与える方法は、申込者が所望の預
金製品に対する資格を与えられるか否かを判定するため
に資格付与システムが実行する自動処理用のコンピュー
タ読取り可能資格付与要求を自動的に作成すること、資
格付与要求に対するコンピュータ読取り可能応答を自動
的に受け取ること、および資格付与要求に対する応答に
基づいて所望の預金製品を自動的に承認することを含
み、次いで承認された預金製品に対して、申込者がアク
セスできる預金口座を自動的に開設する。

【００２４】本発明の第４の態様では、自動資格付与お
よび前の態様に続くステップを提供する。

【００２５】本発明の他の態様では、前述の態様の種々
の組み合わせおよびサブセットを提供する。

【００２６】本発明についてよりよく理解し、どのよう
に実行できるかをより明確に示すために、本発明の好ま
しい実施形態を示す添付の図面を例に挙げて参照する
が、この図面では同様の要素が同様の参照番号を有する
（また個々の要素には固有の英字接尾辞が添えられ
る）。

【００２７】

【発明の実施の形態】図４を参照すると、受託（deposi
tory）システム６０は支店を必要としない。後に詳細に
拡大してあるように、受託システム６０はすべての日常
の預金機能を実行し、貸方および借方が預金口座に登記
され、利子計算および信用貸しが実行され、クライアン
トの記録が維持される。受託システム６０にアクセスす
るために、いくつかのインタフェース６４が提供され
る。一部のインタフェース６４は、他のインタフェース
よりも多くの機能を有する。受託システム６０は、クラ
イアントが認証を受けた支店を訪れることなく、単一の
セッションで預金口座を開設できるようにする。申込者
は、認証を受けた支店でないキオスク（３０、図３およ
び図４）を訪れたときに預金口座にアクセスすること
で、預金口座を開設することができる。

【００２８】預金（deposit）とは、事前に通知なく要
求があり次第口座保有者に支払い可能な、預金預かり機
関の債務である。預金は貸付ではない。預金預かり機関
以外の者が預金を預かることは違法である。特に、すべ
ての預金預かり機関は、預金に関するＦＤＩＣ保険、ま
たは他の管轄権内にある同様の委託預金保険を有するも
のでなければならない。預金口座は、機関が債務を負っ
ている預金額と口座の保有者とを結びつける。預金口座
は、預金の利子支払いまたは預入れや引出しに加えて信
用貸しを受け入れる機能など、種々の特徴を有すること
ができる。たとえば銀行口座は、普通預金、当座預金、
または超過引出し保護を備えた当座預金であってもよ
い。

【００２９】預金預かり機関が預金製品以外の製品、た
とえばクレジットカード製品を提供できることが理解さ
れよう。好ましい実施形態はこのような非預金製品に関
連して使用することができるが、預金口座の定義内に入
るものではなく、結果的に預金の預かりに関する厳密な
認証要件にはならない。したがってこのような非預金預
かり口座（non-deposit taking accounts）は、好まし
い実施形態から預金口座ほど多くの利益が導出されると
はみなさない。

【００３０】預金口座は、申込者が預金口座への預入れ
および預金口座からの引出しが可能なときに、申込者へ
アクセスするために開設される。このような預入れおよ
び引出しは、必ずしも現金でなくてよい。預入れおよび
引出しは、預金預かり機関が提供する他の製品に関連し
て実行することができる。たとえば、請求書支払いの実
行要求には預金口座からの引出しを含むことができる。

【００３１】受託システム６０に関連付けられたデータ
ベース（７０、図５）は、受託システム６０のクライア
ントおよびクライアント向け製品に関する情報をストア
する。以下の部分では、銀行、銀行口座、および銀行預
金について単独で参照しながら説明する。当分野の技術
者であれば、他の預金預かり機関にも等しく適用される
ことを理解されよう。

【００３２】図１を参照すると、銀行クライアント用の
顧客情報ファイル（ＣＩＦ）１０の一部がレポート形式
で示されている。ＣＩＦ１０には、たとえば名前１
２、クライアント番号１４、および電話番号１６を含む
クライアントに関する情報を含んだフィールドがある。
ＣＩＦ１０は、受託システム６０に関連付けられたデ
ータベース（７０、図５）から生成される。

【００３３】クライアントの場合、自分が管理する銀行
製品に関係する情報をＣＩＦ１０に関連付けることが
できる。図２を参照すると、製品情報ファイル２０がＣ
ＩＦ１０に関連付けられている。製品情報ファイル２０
は、製品タイプ２２および製品パラメータ２６を含む、
クライアントが口座内に保有している製品に関する情報
を含むフィールドを有する。この例では、クライアント
は貯蓄製品と、満期日が２００１年１月１日の預金証書
を有する。ＣＩＦ１０および製品情報ファイル２０に
は、受託システム６０を利用している特定機関の要件に
従って、異なるフィールドまたは追加のフィールドを含
めることができることを理解されよう。

【００３４】図３を参照すると、クライアントは、受託
システム６０と通信するための独立型キオスク３０を介
して、受託システム６０のクライアント口座にアクセス
することができる。キオスク３０は典型的なステーショ
ンを表すもので、たとえば系列販売店に、またはこれに
隣接した便利な場所に配置することができる。キオスク
３０は、食品雑貨店やその他の小売店内など、従来の銀
行サイト以外の場所に設置して、クライアントおよび潜
在的なクライアントが日常的に訪れる場所で、銀行製品
へのアクセスを提供することができる。したがって、銀
行および小売店の両方が、１箇所の「ワンストップ（on
e-stop）ショッピング」で利用できるどちらのサービス
も備えた便利さから利益を得ることができる。キオスク
３０の操作および保守は、銀行支店よりも柔軟性が高く
コストを低くすることができる。キオスク３０は、銀行
支店に比べてコストがかからずアクセスしやすい現場
で、製品保有者に幅広いサービスを提供することができ
る。「キオスク」という用語は、一般に預金口座へのア
クセスを提供するステーションを言い表すものであるこ
とを理解されよう。

【００３５】キオスク３０は、銀行サービスを提供する
機関の販売を促進するために商標を付けるか、あるいは
まったく異なる名前、たとえば特定の小売店に関連付け
られた、または関連付けられることになる名前を使って
商標を付けることができる。小売店に関連付けられた名
前の商標をキオスク３０に付けることで、小売店の信用
を利用して新しい顧客を引きつけ、預金機関が利益を得
ることになる。この例では、符号３１が「ＡＢＣ銀行キ
オスク」としてキオスク３０を識別している。預金機関
は、単に大量に行き来する顧客の流れを生み出す場所に
設置されることからも利益を得る。

【００３６】キオスク３０にあるいくつかの端末３２、
３４、３６は、顧客が自分の口座にアクセスするための
異なる方法を提供する。それぞれのアクセス方法は、口
座に対してさまざまなアクセス機能を提供することがで
きる。ＡＴＭ端末３２は、クライアントが周知の方法で
預金口座から預入れ、引出し、振替え、および請求書支
払いを実行できるようにするものである。インターネッ
ト端末３４は、銀行のインターネットｗｅｂサイト（６
４（ｉ）、図５）を介した銀行口座へのアクセスをクラ
イアントに提供する。インターネット端末３４は、明細
書の再検討、請求書支払い、取引履歴の再検討、電子メ
ールインタフェース、口座一覧（account summary）、
資金振替え、および報告書などの機能を提供する。一般
的には、インターネット端末３４は、インターネットに
アクセスするための通信ハードウェアおよびソフトウェ
ア（図示せず）を有するパーソナルコンピュータを備え
る。インターネット端末３４の一例は、インターネット
へのインタフェースを提供するためにＮｅｔｓｃａｐｅ
Ｎａｖｉｇａｔｏｒ（商標）がインストールされた５
６Ｋのモデムを介してインターネットに接続される、Ｄ
ｅｌｌ（商標）のパーソナルコンピュータである。端末
３４には他の構成も使用できることが、当分野の技術者
であれば理解されよう。電話端末３６は、クライアント
が製品取引および製品情報要求を処理するためにテレフ
ォンバンキング呼出しセンター（７８、図５）にアクセ
スできるようにするものである。

【００３７】端末３２、３４、および３６は、接続３８
（１）、３８（２）．．．３８（ｎ）を介して受託シス
テム６０と通信する。接続３８（１）．．．３８（ｎ）
は単一の接続にまとめてもよいことが理解されよう。

【００３８】スタンドアロン型のＡＴＭ３２、インター
ネット端末３４、および電話３６をどこに設置しても、
受託システム６０へのアクセスに使用できることが理解
されよう。

【００３９】さらにキオスク３０は、新しいクライアン
トが、受託システム６０からの承認を受け取ると同時
に、製品用の新しい口座に即時にアクセスできるように
するものでもある。図３では、新しいクライアント４０
が係員４２を通じて新しい製品を要求する。係員４２
は、接続３８のうちの１つによって受託システム６０に
接続されている端末４４を介して、製品要求を処理す
る。

【００４０】好ましい実施形態では、端末４４は、ＴＣ
Ｐ／ＩＰ接続を介して受託システム６０に接続された、
比較的低機能のクライアント端末４４である。比較的低
機能のクライアント端末４４であるため、典型的なパー
ソナルコンピュータよりは経費が少なく保守が簡単であ
る。また端末４４上で実行されるキオスク端末ソフトウ
ェア４４の発生元は受託システム６０である。したがっ
て、ネットワークセキュリティは受託システム６０を介
して調整することができる。ただし、端末４４は、キオ
スク端末ソフトウェア４５がローカルに動作する典型的
なパーソナルコンピュータであってもよい。この実施形
態では、キオスク端末ソフトウェア４５が受託システム
６０と通信し、受託システム６０が取引を処理する。本
発明の好ましい実施形態では、キオスク端末ソフトウェ
ア４５は、Ｗｉｎｄｏｗｓ（商標）と互換性がある印象
を持つ表示インタフェースを有する。他の表示インタフ
ェーススタイルを使用して、本明細書で必要とされる機
能を提供することもできる。キオスク端末ソフトウェア
４５の態様に関する詳細については、後で説明する。好
ましい実施形態では、キオスク３０の端末３２、３４、
および３６は、受託システム６０の口座開設部分にはア
クセスしない。

【００４１】さらにキオスク３０では、カードリーダ／
ライタ４６が新しいクライアントカードのＰＩＮ番号の
プログラミングを提供する。

【００４２】新しい口座が開設されると、受託システム
６０によって、製品の口座へのアクセス承認が与えられ
る。したがってキオスク係員４２には、製品申し込みの
承認、拒否、または修正を行う権限は必要ない。また係
員４２は、顧客のどんな銀行取引または作業も、銀行に
委託することはできない。さらに係員４２は、銀行の資
金を取り扱うことはできず、銀行とクライアントの間で
の、顧客の預入れ、引出し、または貸付け支払い取引の
実行に関して何の役割も果たさない。代わりにこれらの
機能は、端末３２、３４、３６を介して提供される。

【００４３】米国連邦銀行監視団体である通貨監督庁
（ＯＣＣ）は、キオスク３０での係員４２の制限付き権
限および端末３２、３４、および３６の定義済み機能に
よって、キオスク３０を銀行の支店とはみなしていな
い。Ｕ．Ｓ．Ｃ．３６（ｊ）の第１２章では、銀行の支
店を以下のように定義している。

【００４４】本項で使用される「支店」という用語は、
預金が受け取られ、手形が支払われ、あるいは金銭が貸
し付けられる、すべての支店銀行、支店事務所、支店代
理店、追加事務所、またはすべての支店営業所を含むよ
うに適用されるべきである。本項で使用される「支店」
という用語は、現金自動預け払い機または遠隔サービス
ユニットを含むものではない。

【００４５】したがって、各キオスクサイトには、１２
Ｕ．Ｓ．Ｃ．３６の下でのＯＣＣの承認は不要であ
り、キオスクサイトを設立するための経費および時間の
問題を合理化している。同様の支店の定義および認証要
件が、他の管轄地区でも適用される。

【００４６】ＡＴＭ３２、インターネット端末３４、
電話３６、および端末４４を使用すれば、口座保有者４
０は、銀行の支店に出向くことなく製品の銀行口座にア
クセスできることを理解されよう。銀行製品へのアクセ
スには、預入れ、引出し、資金振替え、口座照会、およ
び請求書支払いの実行を含むことができることを理解さ
れよう。

【００４７】図４は、受託システム６０を備えたキオス
ク３０の接続および取引の態様を示す図である。受託シ
ステム６０の中心部は処理システム６２であり、これが
クライアントおよびその製品に関する情報を維持し、製
品取引要求を処理する。

【００４８】ＡＴＭ端末３２、インターネット端末３
４、電話３６、および係員端末４４は、それぞれ接続３
８（１）．．．３８（ｍ）を介して受託システム６０に
接続される。各端末タイプ（ＡＴＭ３２、インターネッ
ト３４、電話３６、および係員端末４４）は、関連付け
られた異なる物理的および論理的なインタフェース問題
を有する。たとえば、電話３６から取引を受け取って処
理するための要件は、ＡＴＭ端末３２からの取引を処理
するための要件とは異なる。したがって、各端末タイプ
が、特定の取引インタフェースユニット６４
（１）．．．６４（ｎ）を介して処理システム６２と通
信する。各取引インタフェースユニット６４は、それぞ
れが接続された端末３２、３４、３６、または４４から
受け取った取引要求を処理し、承認された場合は、承認
された取引の実行およびデータベースの更新を処理シス
テム６２に実行させる。各取引インタフェースユニット
６４は、提供された製品またはインタフェース用の通信
の性質によって必要となる特殊な機能を提供する、関連
付けられた別々の補助ユニットを有することができる。
異なる端末タイプからの取引要求を実行するために、処
理システム６２を備えた他のインタフェース機構が使用
できることを理解されよう。

【００４９】端末４４は、申込者からの情報を、受託シ
ステム６０用のコンピュータ読取り可能データに変換す
る。

【００５０】図５を参照すると、処理システム６２の中
心はメインフレーム６６であり、これが最終的に受託シ
ステム６０に関するすべての取引を処理または制御す
る。メインフレームソフトウェア６７がメインフレーム
６６上で動作する。好ましい実施形態では、メインフレ
ーム６６がＦｉｓｅｒｖ，ＩｎｃのＣｏｍｐｒｅｈｅｎ
ｓｉｖｅＢａｎｋｉｎｇＳｙｓｔｅｍを含む。理解
できるように、メインフレームソフトウェア６７とキオ
スク端末ソフトウェア４５とは区別される。キオスク端
末ソフトウェア４５は、端末３４からメインフレーム６
７へのデータ入力を可能にし処理要求を実行可能にする
ものであるが、メインフレーム６６およびメインフレー
ムソフトウェア６７は、口座データの実際の処理を実行
する。処理システム６２は、いくつかの異なる都市に機
能構成要素を備えた分散型システムである。処理システ
ム６２の一部またはすべての態様が、非分散型システム
でも実施できることが理解できよう。

【００５１】メインフレーム６６は、アイテム処理ユニ
ット６８およびデータ格納ユニット７０に接続される。
アイテム処理ユニット６８は、連邦準備銀行および地方
の手形交換所からの受入手形額アイテム、例外アイテム
処理（資金不足（ＮＳＦ）、高額取引）、明細書提出
（手形保管）、および文書宅配サービスを処理する。本
発明の好ましい実施形態では、項目処理ユニット６８は
Ｆｉｓｅｒｖ（商標）の項目処理である。

【００５２】データ格納ユニット７０は、本発明の好ま
しい実施形態で、メインフレーム６６にクライアント情
報に関するデータ保持を提供する。取引を処理するのに
必要な操作データが、データ格納ユニット７０にストア
される。

【００５３】データ倉庫７１は、メインフレーム６６に
非操作データの保持を提供する。データ倉庫７１は、メ
インフレーム６６の補助格納システムである。

【００５４】バックオフィスユニット７２は、製品処理
項目の検証、製品システムの釣り合い、製品の追跡、デ
ータのアーカイブ、製品の調整、放棄された製品の処
理、および種々の規定関連機能を提供する。

【００５５】他の補助ユニットは、カード／明細書処理
ユニット７４を含む処理システム６２とインタフェース
をとることができる。各補助ユニットは、追加の金融製
品または製品機能を受託システム６０に提供できること
が理解されよう。各補助ユニットを含めることで受託シ
ステム６０の製品領域が機能強化されるが、補助ユニッ
トは基本的な銀行サービスをクライアントに提供する必
要のない場合がある。本発明の好ましい実施形態では、
カード／明細書処理ユニット７４をＰｅｒｓｏｎｉｘ
（商標）が操作する。

【００５６】図示されていない他のシステムは、他の金
融サービスまたはデータ処理サービスを提供するため
に、処理システム６２とインタフェースをとることがで
きる。他のシステムには、Ｖｉｓａ（商標）処理ユニッ
トおよび抵当処理ユニット（mortgage processing uni
t）を含むことができる。抵当処理ユニットの一例がＩ
ｏｗｎ．ｃｏｍである。処理システム６２の要素は、よ
り大規模な機能要素または分散型ネットワークと同じ機
能を提供する単一のシステムに統合されながらも、処理
システム６２の機能属性内に収めることができる。

【００５７】本発明の好ましい実施形態で、受託システ
ム６０に接続された種々の端末３２、３４、３６、４４
の場合、端末３２、３４、３６、４４と処理システム６
２との間の通信は、別々の取引インタフェースユニット
６４を介して実行される。インターネット端末３４は、
取引インタフェースユニット６４（１）に接続され、電
話３６は取引インタフェースユニット６４（２）に接続
され、係員端末４４は取引インタフェースユニット６４
（３）に接続され、ＡＴＭ３２は取引インタフェース
ユニット６４（４）に接続される。本発明の好ましい実
施形態では、取引インタフェースユニット６４（４）が
Ｆｉｓｅｒｖ（商標）サーバである。

【００５８】本発明の好ましい実施形態では、インター
ネット端末３４用の取引インタフェースユニット６４
（１）がインタフェースを提供する。取引インタフェー
ス６４（１）は、振替えおよび製品照会、請求書支払い
サイクルの確立、カスタマイズされた製品口座の報告
書、および端末３４への取引記録のダウンロードなどの
取引要求を、クライアントが実行できるようにするもの
である。

【００５９】本発明の好ましい実施形態では、電話３６
用の取引インタフェースユニット６４（２）が２つのサ
ブシステムを含む。第１のサブシステムは、人間の代行
を利用せずに取引要求の自動処理を提供する、音声応答
ユニット（ＶＲＵ）７６である。ＶＲＵ７６は、任意
の電話からクライアント製品への、２４時間年中無休の
アクセスを提供する。本発明の好ましい実施形態では、
ＶＲＵ７６が、許可された製品記号、請求書支払い、
支払い許可および借方記入、口座振替え、および他のサ
ービスを提供する。すべての要求は、口座保有者がＶＲ
Ｕ７６にアクセスするときに使用される電話３６のキ
ーパッド上で実行された入力を介して、口座保有者によ
って実行される。ＶＲＵ７６の他の実施形態では、音
声認識ユニットが口座保有者の要求を処理することがで
きる。

【００６０】どんな場合でも、ＶＲＵ７６を使用する
クライアントは、呼出しセンター７８へのアクセスを有
する。製品保有者は呼出しセンター７８を使用して、取
引を処理する呼出しセンター７８の代行者に口頭で要求
することができる。本発明の好ましい実施形態では、呼
出しセンター７８がＳｐｒｉｎｔ／Ｒｏｃｋｗｅｌｌ
（商標）システムを備える。Ｒｏｃｋｗｅｌｌシステム
は、呼出し側と銀行の電話代行者との間の電話呼出し管
理を提供する電話交換を含む。Ｉｎｔｅｒｖｏｉｃｅ
Ｉｎｖｉｓｉｏｎｓ（商標）システムは、呼出し取引を
処理する。呼出しセンター７８は、インターネットパス
ワード保守を提供する端末８０（１）、製品の取引およ
び照会を処理する端末８０（２）、およびデビットカー
ド／チェックカードの保守サービスを提供する端末８０
（３）を有する。図５に示すように、ＶＲＵ７６は呼
出しセンター７８の近くに配置されるが、ＶＲＵ７６
は電話取引を処理するのに好適に接続されれば、どこに
でも配置できることが理解されよう。

【００６１】本発明の好ましい実施形態では、端末４４
用の取引インタフェースユニット６４（３）はサーバ８
２を備える。本発明の好ましい実施形態では、サーバは
Ｆｉｓｅｒｖ，Ｉｎｃによって提供される。好ましい実
施形態で集合的に表示されているサーバ８２は、受託シ
ステム６０内で異なる担当者によって使用される特殊な
ソフトウェアパッケージを提供する。サーバ８２は、特
定のタスクを実行するためのサブモジュールを備える。
サブモジュールは、ローカルなバックオフィス８４の担
当者が銀行取引を処理するために使用するＦＡＳＴＴ
ｅｌｌｅｒ（商標）と、銀行口座を開設するための申し
込みを処理するＦＡＳＴＡｄｍｉｎｉｓｔｒａｔｉｏ
ｎ（商標）と、クライアント単独では「セルフサービ
ス」できない取引でクライアントを補助するＣＳＣＳ
（顧客サービス呼出しセンターソリューション）システ
ムとを含む。

【００６２】申込者４０がキオスク３０で新しい製品を
要求すると、その申し込みは取引インタフェースユニッ
ト６４（３）で処理および対処される。申し込みプロセ
スの一態様は、受託システム６０に提供された情報に基
づいて、申込者４０の信頼性の査定（assessment）を取
得することである。本発明の好ましい実施形態では、申
込者信頼性評点システム８６が使用される。本発明の好
ましい実施形態では、第三者の信用報告事務所であるＥ
ｑｕｉｆａｘ（商標）が、情報を提供し、申込者信頼性
評点システム８６の決定機能を実行する。評点システム
８６の詳細については、後で説明する。別々の申込者信
頼性評点システム８６の代わりに、あるいはこれに加え
て、取引インタフェースシステム６４（３）は第三者か
らの報告を必要としない内部評点システムを利用するこ
とができる。内部評点システムは図示されていないが、
処理システム６２からの内部データに依拠するか、また
は申込者４０の信用査定を組み込んだ任意の好適なｈｅ
ｕｒｅｓｔｉｃ方法であってもよい。好ましい実施形態
では、申込者信頼性評点システム８６が、要求された製
品の承認に関するすべての決定を提供する。

【００６３】ローカルのバックオフィス８４は、取引イ
ンタフェースユニット６４（３）に、ファイル処理、シ
ステム保守、および特別なクライアント要求を含む管理
サポートを提供する。ローカルのバックオフィス８４で
は、信用専門家および取引職員が、訴求および特別な取
引要求を含む、特別な要求を処理するためにサーバ８２
にアクセスする。

【００６４】図６は、申込者信頼性評点システム８６の
詳細を示す。好ましい実施形態に関連して使用される申
込者信頼性評点システム８６は、第１の要素９０および
第２の要素９２という２つの要素を含む。申込者信頼性
評点システム８６は、申込者４０に関する情報を提供す
る取引インタフェースユニット６４（３）に報告書を提
供する。新しい申込者に関する報告書が第１の要素９０
から使用できない場合、第１の要素９０は第２の要素９
２からの報告書を要求する。接続９４は、第１の要素９
０と第２の要素９２との間でデータを転送できるように
するものである。好ましい実施形態では、第１の要素９
０がＥｑｕｉｆａｘ（商標）によって提供され、第２の
要素であるＣｈｅｘＳｙｓｔｅｍ（商標）がＤｅｌｕ
ｘ（商標）によって提供される。他の実施形態は、１つ
だけまたは２つ以上の査定システムで動作可能であるこ
とを理解されたい。申込者信頼性評点システム８６から
の承認は、通信リンク９６を介して取引インタフェース
ユニット６４（３）に通信される。どんな信頼性報告書
でも、取引インタフェースユニット６４（３）がすべて
の製品タイプから申込者４０が開設できる製品を識別す
るために使用できることを理解されたい。本発明の好ま
しい実施形態では、信頼性報告書には信用評価報告書お
よび不正使用評価報告書が含まれる。本発明の範囲内に
ある他の商業申し込みを処理するために、他の報告書タ
イプを使用することができる。

【００６５】本発明の好ましい実施形態では、第１の要
素９０から適切な信用報告書が取得された後に、申込者
４０に関する不正使用報告書が取得される。この不正使
用報告書は、取引インタフェースユニット６４（３）に
よって処理される。不正使用報告書は、情報または申込
者４０の信頼性に関して、申し込みまたは申込者４０の
異常を識別する。本発明の好ましい実施形態では、不正
使用報告書には、申込者４０に関する信用報告書と共に
Ｅｑｕｉｆａｘによって提供される、Ｆｒａｕｄｓｃａ
ｎ（商標）報告書およびＳａｆｅｓｃａｎ（商標）報告
書が含まれる。

【００６６】不正使用報告書は一連のデータフィールド
を含み、そのそれぞれが潜在的な問題を識別できる項目
を識別する。たとえば、不正使用報告書は、申込者の電
話番号、住所、社会保障番号、生年月日、破産状況、お
よび運転免許証などの態様を追跡することができる。た
とえば、不正使用報告書が申込者４０が無効なまたは取
り外された電話番号を有することを見つけた場合、不正
使用報告書は、この事実を潜在的問題として識別するこ
とができる。各フィールドには、フィールドのリスクの
程度を示す評点を割り当てることができる。一般に、フ
ィールドには３段階のリスクレベルのうち１つが割り当
てられる。第１レベルは、そのフィールドには不正使用
がないことを示す。第２レベルは、そのフィールドに重
大な警告がないことを示す。係員４２は、受託システム
６０によって、そのフィールドの重大でない警告につい
て知らされる。重大でない警告が、端末４４への情報の
入力ミスによって生じたものである場合、入力ミスを訂
正することができる。また、これらの重大でない警告を
係員４２が無視することもできる。第３レベルは、その
フィールドのより重大な問題を示す。係員４２がそのフ
ィールドに関するデータを明白にするかどうかを尋ねら
れるか、またはセッションを終了して申込者４０には製
品が提供されない。

【００６７】申込者４０に関する信用報告書および不正
使用報告書が最低限のしきい値を満たしている場合、受
託システム６０は、信用および不正使用報告書からの結
果を使用して、申込者４０が開設することが承認された
製品のマトリックスを識別する。このマトリックスは、
申込者４０が開設することを受託システム６０により承
認された、銀行によって提出された製品群からの製品の
選択を識別することができる。各製品に対して特定額を
有する信用限度（lines of credit）および超過引出し
保護などの追加製品も、申込者４０が使用できるように
委託システム６０により承認されることができる。好ま
しい実施形態では、マトリックスは申込者信頼性評点シ
ステム８６で使用される。

【００６８】係員４２は、申込者４０に対して承認され
たすべての製品、および申込者４０の要求を受託システ
ム６０を介して申込者４０に提供できる任意の承認済み
製品を識別する。

【００６９】申込者４０が断られたすべての製品につい
て、受託システム６０によって適切な断り状が生成さ
れ、申込者４０に提供される。これは法的な要件であ
る。したがって、取引インタフェースユニット６４
（３）は合理化されたシステムを提供し、これが必要な
法的通知を申込者４０に対して自動的に提供する。

【００７０】図７は、本発明の好ましい実施形態にした
がった預託ネットワーク１００を示す。預託ネットワー
ク１００は、従来の銀行支店のない従来の銀行サービス
を製品保有者に提供し、自動製品情報処理、顧客情報フ
ァイル処理、取引預金、総合貸付け、見返り処理、金融
取引管理、項目処理、一般元帳処理、製品調整、および
報告書生成を提供することができる。

【００７１】預託ネットワーク１００は、キオスク３０
（１）．．．３０（ｍｍ）、ＡＴＭ３２（１）．．．３
２（ｎｎ）、インターネット端末３４（１）．．．３４
（ｏｏ）、および電話３６（１）．．．３６（ｐｐ）を
含む種々の端末への接続を備えた、前述のような受託シ
ステム６０を含む。各キオスク３０または端末３２、３
４、３６は、異なるサイトに配置し、適切な取引インタ
フェースユニット６４（ｎ）に独立して接続することが
できる。預託ネットワーク１００は、従来のどんな「煉
瓦とモルタル」の銀行支店も含む必要がないことがわか
る。したがって、預託ネットワーク１００は、銀行支店
を設立して保守する際の関連する経費および問題を負担
する必要がない。これらの経費および問題には、規定要
件、人員配置要件、高騰する賃借料、および建物ならび
に機器の保守が含まれる。ただし、希望すれば、従来の
「煉瓦とモルタル」の支店に預託ネットワーク１００を
組み込めることが理解できよう。

【００７２】本発明の好ましい実施形態での動作流れを
示す詳細な態様が、以下の例の文章および図８〜１３に
示される。

【００７３】図８は、新しい申込者がキオスク３０で預
託ネットワーク１００を介して口座を開設することを要
求したとき、係員が行う動作の好ましい流れの一例を示
す。

【００７４】本発明の好ましい実施形態では、製品の開
設に関連するエンティティは４つあり、すなわち顧客２
００、パビリオン２０２（キオスク係員端末４４）、Ｆ
ＡＳＴステーション２０４（取引インタフェースユニッ
ト６４（３））、およびバックオフィス２０８（ローカ
ルのバックオフィス８４）である。処理流れのイベント
は幾何学的な形状で囲まれており、それぞれが流れの方
向を示す矢印でリンクされている。顧客２００の列、パ
ビリオン２０２の列、ＦＡＳＴステーション２０４の
列、またはバックオフィス２０６の列のうちの１つにイ
ベントが配置されていれば、それぞれのエンティティが
そのイベントに関連付けられていることを示す。発生す
るイベントには、次のものが含まれる。０．新しい製品の要求（２０８）１．顧客情報の定義（２１０）２．顧客の資格付与（２１２）３．製品の定義（２１４）４．製品への電子アクセスの確立（２１６）５．製品文書のアセンブル（２１８）６．文書の検証（２２０）新しい製品の要求（２０８）

【００７５】第１のイベントは、申込者４０がキオスク
３０の係員４２に接近し、製品用の口座開設に関して問
い合わせることに関する。係員４２は、端末４４上で動
作しているキオスクの端末ソフトウェア４５を使用して
要求を処理する。この例の場合、申込者４０の名前はＣ
ｈｒｉｓｔｉｎｅＣｏｎｄｒｅｎであり、フロリダ州
Ｌａｋｅｌａｎｄに住んでいる。彼女は無金利の小切手
振り出し製品を開設することを望んでいる。もちろん係
員４２も申込者４０に新しい口座を開設するように勧誘
することができる。

【００７６】顧客情報の定義（２１０）図９は、受託システム６０を使用する顧客を定義するた
めの、本発明の好ましい実施形態に関連付けられたプロ
セス流れを示す。このプロセスは２３０から始まり、こ
こでは申込者４０が自分の名前を係員４２に提供する。

【００７７】銀行の既存の顧客はすべて、受託システム
６０に関連付けられた（図１および図２からの）顧客情
報ファイル（ＣＩＦ）１０を有している。イベント２３
２から始まりイベント２３４まで、係員４２は、申込者
４０の既存のＣＩＦ１０について、取引インタフェー
スユニット６４（３）に照会する。ＣＩＦ１０がすで
に存在する場合、新しいタイプの製品が要求されない限
りこの申し込みは重複する。イベント２３６を参照のこ
と。

【００７８】図１０は、既存の顧客が新しい製品を要求
したときの、本発明の好ましい実施形態に関連付けられ
たプロセスの流れを示す。第１に、受託システム６０は
既存のクライアントを認証しなければならない。イベン
ト２６０から始まり、係員４２は申込者４０が電子銀行
カードを持っているかどうかを判定する。申込者４０が
カードを持っている場合はカードリーダ４６に通し、カ
ードが損傷していなければ、申込者４０は（一般的には
カードリーダ４６を介して）自分のＰＩＮを受託システ
ム６０に入力する。イベント２６０、２６２、２６４、
および２６６を参照のこと。

【００７９】ＰＩＮが有効であれば、申込者４０は受託
システム６０によって認証されており、申し込みプロセ
スは後述の顧客への資格付与を続行する。イベント２６
８および２７０を参照のこと。

【００８０】申込者４０がカードを持っていないかまた
はカードが損傷している、あるいはカードには無効なＰ
ＩＮを入力した場合、係員４２がサーバ８２にアクセス
して、申込者４０に関する連絡履歴データを表示させ
る。イベント２７２を参照のこと。履歴データが警告状
況を表示しない場合、係員４２は手作業で申込者４０の
認証を実行する。これには、申込者４０から十分な身分
証明（運転免許証など）を取得すること、および申込者
４０から伝記的情報を得てこれを認証することが含まれ
る。イベント２７８で認証が合格すると、新しいカード
および新しいＰＩＮが提供され（どちらも必要な場合）
（イベント２８０、２８２、およびイベント２８４、２
８６に図示）、顧客に資格を付与する手続きがイベント
２７０に続く。連絡履歴で警告が示されるか、または申
込者４０が手作業の認証手続きに合格しない場合、銀行
製品は申込者４０に与えられない。係員４２は申込者４
０に申し込み拒否を伝え、申込者４０の要求があれば、
申込者４０に関する認証失敗ケースのバックオフィス処
理を開始することができる。イベント２８８および２９
０を参照のこと。

【００８１】図９のイベント２３４に戻り、申込者４０
に既存のＣＩＦ１０がない場合、申込者４０は受託シ
ステム６０にとって新しいクライアントである。したが
って、受託システム６０は新しいＣＩＦ１０を作成
し、処理しなければならない。係員４２は、イベント２
３８に示すように申込者４０から顧客情報を取得する。
申込者４０が十分な個人識別（運転免許証など）を持っ
ていない場合、申し込みは拒否され、申し込み処理は終
了される。イベント２４０、２４２、および２４４を参
照のこと。

【００８２】申込者４０から適切な識別が提供された場
合、イベント２４６に示すようにその情報を預託システ
ム６０に提供し、イベント２４８に示すように申込者４
０による入力の正確さが検証される。識別および入力情
報の正確さをチェックすると、検証された申込者識別情
報の１つの形式が提供される。当分野の技術者であれ
ば、他の検証形式も実行可能であることが明らかであろ
う。これらのうち少なくとも１つについて、後で説明す
る。申込者４０が他の申込者４０（２）との共同口座を
申し込んでいる場合は、申込者４０（２）に関する情報
が取得される。イベント２５０を参照し、イベント２３
０に進む。共同口座申し込みに関する処理についての詳
細は、後で説明する。

【００８３】仮の申し込み情報が受託システム６０に提
供された後、イベント２５２に示すように申込者に資格
を付与することによって、申し込み処理が続行される。

【００８４】図１４〜１６は、上記プロセス時に、具体
的には新しい申込者が新しい口座の開設を希望したとき
に、キオスク端末ソフトウェア４５によって端末４４上
に表示される、選択されたコンピュータスクリーンショ
ットを示す。図１４は、係員４２が取引インタフェース
ユニット６４（３）で申込者の既存のＣＩＦ１０を検
索するときに表示される、コンピュータ表示画像を示
す。（特に記載のない限り、すべてのコンピュータ表示
画像はキオスク端末ソフトウェア４５によって生成さ
れ、端末４４上に表示される。）ダイアログボックス６
００が表示され、係員４２は申込者４０の姓を名前フィ
ールド６０２に入力して、マウス（図示せず）またはキ
ーボードなどの適切な入力装置を使用して、ＯＫボタン
６０４をアクティブな状態にする。

【００８５】図１５は、照会の検索結果を格納したＣｕ
ｓｔｏｍｅｒＳｅｌｅｃｔｉｏｎ（顧客選択）応答ボ
ックスを示す。取引インタフェースユニット６４（３）
内に申込者４０の記録がない場合、申込者４０の名前は
ＣｕｓｔｏｍｅｒＳｅｌｅｃｔｉｏｎボックスの結果
フィールド６１０に表示されない。

【００８６】申込者４０に関する既存のＣＩＦ１０が
ない場合、キオスク端末ソフトウェア４５を使用してそ
のＣＩＦ１０を作成しなければならない。図１６は、
ＣＩＦ１０を開始するのに使用される、Ｐｒｏｄｕｃ
ｔＳａｌｅｓ（製品販売）スクリーン６２２のＮａｍ
ｅａｎｄＡｄｄｒｅｓｓ（氏名および住所）スクリ
ーン６２０のスクリーンショットを示す。Ｐｒｏｄｕｃ
ｔＳａｌｅｓスクリーン６２２には種々のタブ６２４
があり、係員４２はタブそれ自体をマウスポインタでク
リックすることによってアクセスできる。各タブ６２４
は、製品処理に異なる機能を提供する異なるスクリーン
に関連付けられている。

【００８７】図１６を参照すると、係員４２がＮａｍｅ
ａｎｄＡｄｄｒｅｓｓスクリーン６２０のフィール
ド６２６に、氏名、住所、および電話番号を含む、申込
者４０から取得した種々の情報を入力する。銀行規定に
よって要求される他の情報も、この時点で端末４４に入
力することができる。

【００８８】次に、申込者４０は係員４２に適切な識別
を提供し、イベント２３４に示されるように端末４４に
入力しなければならない。図１７は、手順内のこの時点
での、キオスク端末ソフトウェア４５のスクリーンショ
ットを示す。端末４４を使用して、適切なデータが受託
システム６０に入力される。係員４２が申込者４０に関
する識別情報を取引インタフェースユニット６４（３）
に入力するために使用するスクリーンである、ＩＤｉ
ｎｆｏｒｍａｔｉｏｎ（識別情報）スクリーン６３０が
表示される。係員４２は、申込者４０からの適切な識別
を検査することによって、申込者４０のＩＤを検証す
る。たとえば、申込者４０が自分の運転免許証を提示し
た場合、この情報がフィールド６６２に入力される。特
に、保留フィールド６３４内への入力は、申込者４０が
証明されたかまたは非居住の外国人であるかを示すのに
使用される。この指定によって、どの製品および信用制
限（credit limits）が申込者４０に使用できるかに影
響を与える。

【００８９】顧客の資格付与（２１２）次に、取引インタフェースユニット６４（３）は、預金
および信用製品に対する適格性を判定するために、申込
者４０に資格を付与しなければならない。

【００９０】図１１は、本発明の好ましい実施形態につ
いて顧客に資格を与えるためのプロセスを示す流れ。プ
ロセスはイベント３００の「信用検証要求を送信する」
で始まる。Ｅｑｕｉｆａｘが、要求された最初の信用報
告書である。Ｅｑｕｉｆａｘ内に申込者４０に関する情
報がない場合は、申込者４０の信用チェックを実行しな
ければならない。Ｅｑｕｉｆａｘシステムが使用可能で
あれば、受託システム６０はこれに報告書を要求する。
イベント３０２、３０４、および３０６を参照のこと。
現在Ｅｑｕｉｆａｘの結果が申込者４０のファイル上に
あるが、その結果が使用できない（たとえば、結果が古
すぎる）場合、以前と同様に新しいＥｑｕｉｆａｘ報告
書を取得しなければならない。イベント３０２、３０
８、３０４、および３０６を参照のこと。

【００９１】既存のＥｑｕｉｆａｘの結果が使用できる
場合、受託システム６０は既存のＥｑｕｉｆａｘ結果を
使用して、申込者４０が開設の許可を与えられている製
品のマトリックスを判定する。許可された口座および補
助製品のパラメータ、たとえば信用限度なども、Ｅｑｕ
ｉｆａｘの結果に基づいて開設を許可することができ
る。プロセスは申込者４０が許可された製品の選択を再
検討することで続行され、任意の許可された製品を受け
入れる。イベント３１０および３１２を参照のこと。

【００９２】Ｅｑｕｉｆａｘ報告書を取得しなければな
らず、Ｅｑｕｉｆａｘが使用できない場合、申し込みプ
ロセスは終了する。イベント３０４および３１４を参照
のこと。

【００９３】Ｅｑｕｉｆａｘが使用可能であり、申込者
４０に関する情報がない場合（「ヒット」と言う）、第
２のシステムからの信用チェックが要求される。本発明
の好ましい実施形態では、第２のシステムはＣｈｅｘ
Ｓｙｓｔｅｍ（商標）である。さらに、申込者４０が非
預金製品（信用製品など）を要求した場合、キオスク端
末ソフトウェア４５によって「ヒットなし」のメッセー
ジが端末４４上に表示され、申し込みが断られて、申し
込みプロセスは終了する。イベント３１６、３１８、３
２０、および３２２を参照のこと。

【００９４】預金製品のみが要求された場合、受託シス
テム６０によってＣｈｅｘＳｙｓｔｅｍ（商標）報告
書が要求される。イベント３１６および６２４を参照の
こと。第２の信用チェックの結果の処理が、イベント３
２６から開始される。

【００９５】第２の信用チェックによって何の警告問題
も示されなかった場合、端末４４上に「ヒットなし」の
メッセージが表示され、申し込みプロセスは続行され
て、受託システム６０が非信用製品の開設に対する承認
を与える。イベント３２６、３２８、および３３０を参
照のこと。

【００９６】第２の信用チェックが警告問題を示した場
合、端末４４上に警告メッセージが表示され、申し込み
は拒否されて手順が終了する。イベント３２６、３６
２、３３４、および３３６を参照のこと。

【００９７】Ｅｑｕｉｆａｘからの結果が使用可能な場
合、受託システム６０はこれを処理する。端末４４では
報告書の結果がイベント３３８で使用可能である。次に
前述の不正使用報告書が取得される。本発明の好ましい
実施形態では、不正使用報告書の結果を使用する３つの
パスのうちの１つに従って、申し込みプロセスを実行す
ることができる。

【００９８】第１のパスの場合、不正使用報告書が何の
問題も示さなければ（「情報応答（Ｉｎｆｏｒｍａｔｉ
ｏｎＲｅｓｐｏｎｓｅ）」）、申込者４０は、イベン
ト３４０から３１０に従って口座の選択を開設する許可
が与えられる。

【００９９】第２のパスの場合、不正使用報告書が申込
者４０の情報に注意問題があることを示していれば、係
員４２が申込者４０に申し込み情報を確認する。訂正が
必要であればそれを実行し、信用チェックが開始され
る。イベント３４０、３４２、３４４、３４６、および
３４８を参照のこと。情報が正しければ、イベント３５
０で申し込みに関する査定が実行される。十分な条件が
満たされていれば、申し込み手順はイベント３１０に進
む。

【０１００】第１のパスおよび第２のパスがイベント３
１０まで進むと、受託システム６０は既存のＥｑｕｉｆ
ａｘ結果を使用して、申込者４０が開設を承認された製
品のマトリックスを判定する（前述のとおり）。信用限
度などの、許可された口座および補助製品のパラメータ
も、Ｅｑｕｉｆａｘ結果に基づいて開設を承認すること
ができる。プロセスは申込者４０が承認された製品の選
択を再検討することで続行され、任意の承認された製品
を受け入れる。イベント３１０および３１２を参照のこ
と。

【０１０１】イベント３５０で、十分な条件が満たされ
ていない場合、申し込みは断られ、イベント３５０、３
５２、および３３６に従って申し込みプロセスが終了す
る。

【０１０２】第３のパスの場合、不正使用チェックで重
大な問題があること（問題停止（ＳｔｏｐＩｓｓｕｅ
ｓ））が不正使用報告書によって示されると、係員４２
は申込者４０に対して申し込み情報を検証する。修正が
必要であればそれを実行し、他の不正使用チェックが開
始される。イベント３５４、３５６、３４６、および３
４８を参照のこと。情報が正しければ、イベント３５
６、３５８、および３３６に従って申し込みが断られ
る。

【０１０３】イベント３１２では、申込者４０によって
使用可能な預金口座および信用勘定を識別するために、
受託システム６０がすでに申込者４０の信用報告書の評
価を実行している。承認された預金口座がない場合、イ
ベント３１２、３６２、および３３６に従って申し込み
は断られ、承認プロセスが終了する。承認された製品が
ある場合、申し込みはイベント３１２および３６０に従
って任意の口座を開設する。

【０１０４】口座を開設するための承認を提供する場
合、受託システム６０は信用報告書および申込者４０が
提供した他の情報を使用して、申込者４０による開設が
承認された口座のアスペクトをカスタマイズする。たと
えば、受託システム６０は、申込者４０による開設が許
可された製品に対して、特定の超過引出しレベルおよび
信用限度を提供することができる。受託システム６０
は、人間によって申し込みを査定する必要がなく申込者
４０が開設することのできる口座のすべての分析および
評価を提供する。

【０１０５】本発明の場合、「開設」および「口座開
設」という用語は、申込者４０により開設できることが
すでに受託システム６０によって承認された口座の開設
を表すものである。

【０１０６】申込者４０は訴求（appeal）プロセスを使
用して、申込者４０の製品へのアクセス可能性をさらに
査定することができる。係員４２は、申込者４０によっ
て要求された場合に、訴求プロセスを開始するだけであ
る。この例では、申込者４０がキオスク３０で係員４２
に訴求を要求する。係員４２は、端末４４を介してキオ
スク端末ソフトウェア４５への訴求申し込みを開始す
る。訴求申し込みのプロセスは、ローカルバックオフィ
ス８４で発生する。訴求に必要な他の任意の文書は、申
込者４０から係員４２に提供され、次に係員がその文書
をローカルバックオフィス８４に提供する。ローカルバ
ックオフィス８４では訴求代理人が、信用履歴結果、申
込者４０に関する生物学的情報、および他の情報を使用
して、訴求申し込みを再検討する。訴求代理人が申込者
４０から他の情報を要求する場合、訴求代理人は申込者
４０に対して適切な照会を実行する。訴求代理人は訴求
申し込みに関する決定を行い、受託システム６０内の記
録が決定を反映するように適切に更新し、その結果に応
じて申込者４０に報告する。訴求が許可されると、申込
者４０はキオスク３０を再訪して、口座申し込みのプロ
セスを続行する。したがって、本発明の好ましい実施形
態は、人間の入力から大量の決定をすることなく、最初
の拒否に対して要求された法的書類を生成するための系
統的なプロセスを提供する。

【０１０７】図１８〜２０は、資格付与プロセス中に端
末４４に表示される選択されたスクリーンショットを示
す。図１８を参照すると、係員４２は申込者４０に資格
を与える準備が整ったときに、ＶｅｒｉｆｙＣｒｅｄ
ｉｔ（信用検証）ボタン６４４をアクティブな状態にす
ることによって、申込者４０に関する取引インタフェー
スユニット６４への信用および不正使用報告書要求を開
始する。受託システム６０は、図１９に示されるＶｅｒ
ｉｆｙＣｒｅｄｉｔスクリーン６４８に応答する。こ
のとき申込者４０は、開設したい製品タイプを係員４２
に知らせることができる。一般に、係員４２は、申込者
４０に関するすべての製品タイプの申し込みを処理する
ために、取引インタフェースユニット６４への要求を開
始する。これは、ボタン６５０（ａ）を選択することで
実行される。ただし、特定の製品に関する要求は、他の
適切なボタン６５０を選択することによって要求するこ
ともできる。

【０１０８】係員４２は、職業および収入の情報を取得
し、これを図１９の適切なフィールド６５２ｂに入力す
る。すべての関連フィールドが完了した後、係員４２は
Ｓｅｎｄ（送信）ボタン６５４をアクティブな状態にす
ることによって、信用および不正使用要求を開始する。

【０１０９】ＣｈｒｉｓｔｉｎｅＣｏｎｄｒｅｎの例
の場合、図２０は、査定システム７６が信用および不正
使用報告書を取引インタフェースユニット６４（３）に
提供するときに表示される、Ｒｅｓｕｌｔ（結果）スク
リーン６６０のスクリーンショットである。フィールド
６６２には、信用報告書に関するメッセージが含まれ
る。この例では、信用報告書が以下のメッセージを生成
する。

【０１１０】「ＣＬＥＡＲＷＡＲＮＩＮＧＳＡＮＤ
ＲＥＳＵＢＭＩＴＯＲＤＯＮＯＴＯＰＥＮＰ
ＲＯＤＵＣＴ（警告を解決して再提出しなければ製品は
開設しない）」：信用報告書によって、申込者４０の信
用貸しの価値に関する重大な問題、または申込者４０に
関連付けられた潜在的な使用不正問題を突きとめられ
た。取引インタフェースユニット６４（３）は、申込者
４０に提供された情報によって、この申込者４０に対し
て製品を開設することはできない。係員４２は申込者４
０によって提供された情報を検証し、提供された情報に
関連付けられた何らかの書き誤りまたは管理誤りがある
かどうかを知ることができる。

【０１１１】残りのエントリは、信用報告書に関する特
定項目の問題に関するものである。「ＰＨＥＭＰＴ
Ｙ」：信用報告書には、申込者４０の電話番号に関する
空白フィールドがあり、係員４２が図１６のフィールド
６２６（ａ）に電話番号を入力しなかったことを示す。
好ましい実施形態では、電話番号は、信用評価システム
がその電話番号のアスペクトと申込者４０とを相関させ
るために使用されるので、必須である。たとえば以下の
相関関係の算定が実行できる。（ｉ）電話番号が今でも
使用されているか。（ｉｉ）電話番号は自宅のものか職
場のものか。あるいは（ｉｉｉ）電話番号が申込者４０
のものであるか。当分野の技術者であれば代替の設計が
明らかであろう。

【０１１２】「ＰＨＺＩＰＥＭＰＴＹ」：申込者４０
の住所の郵便番号が空白であり、係員４２が図１６のフ
ィールド６２６ｂのいずれかに入力しなかったことを示
す。

【０１１３】「ＡＤＮＯＴＨＩＧＨＲＩＳＫ」：
申込者４０が提供した住所がハイリスクでない。ハイリ
スクな住所には刑務所が含まれる場合がある。「ＡＤＩＮＶＡＬＩＤ」：提供された住所が無効であ
る。「ＳＳＮＤＥＣＥＡＳＥＤ」：提供された社会保障番
号が故人のものである。「ＳＳＮＩＳＳＵＥＤＰＲＩＯＲＴＯＤＯ
Ｂ」：提供された社会保障番号が、申込者４０から提供
された生年月日情報よりも前に発行されたものである。「ＳＳＮＶＡＬＩＤ」：上記フラグを除き、社会保障
番号それ自体は有効な番号である。

【０１１４】「ＢＫＮＯＮＥ」：申込者４０が破産を
言明していなかった。「ＤＬＥＭＰＴＹ」：運転免許証情報が提供されなか
った。係員４２が図１７のフィールド６６２に適切な情
報を入力しなかった可能性がある。

【０１１５】図２０に示された報告書では、申込者４０
の信用および不正使用チェックが失敗した。前述のよう
に、係員４２は、信用および不正使用報告書によって問
題が発生した申込者４０の申し込み情報を検証および補
正し、信用および不正使用チェック要求を再提出する。

【０１１６】ただし、申し込み情報に顕著な変更がない
場合、その申し込みプロセスは終了する。したがって、
取引インタフェースユニット６４（３）が、信用チェッ
クに伴う問題を概説した適切な情報通知状を生成し、申
込者４０に提供することができる。図２１は、係員４２
に報告書を印刷するか否かのプロンプトを出すスクリー
ン６７０を示す。ほとんどの環境では、係員４２は報告
書を印刷することになる。ただし、信用を断る場合は、
一般的な断り報告書が印刷されて提供される。

【０１１７】製品の定義（２１４）図１１に示すように、申込者４０が開設を希望する、受
託システム６０によって識別された承認済みの各口座を
開設するためのプロセスが提供される。各製品タイプに
ついて、申込者４０に関する基本情報を製品に関連付
け、適当であればチェックを発行し、文書に署名をしな
ければならない。イベントの流れが４００に示されてい
る。

【０１１８】４０２から始まり、係員４２は特定の製品
タイプを開設するために、承認済みリストから申込者４
０に製品の１つを選択させる。選択された製品タイプに
ついて、イベント４０４で、基本的な個人情報がキオス
ク端末ソフトウェア４５に入力される。製品のチェック
が必要な場合は、イベント４０６および４０８で指示す
る。製品の定義を完了させるのに必要な任意の他の情報
が、イベント４１０でキオスク端末ソフトウェア４５に
入力される。入力された情報は、イベント４１２で係員
４２によって申込者４０に関して検証され、イベント４
１４で取引インタフェースユニット６４（３）にアップ
ロードされる。

【０１１９】ここで、申込者４０が承認された任意の他
の製品が申込者４０に提示され、いずれかが選択された
場合は、イベント４２０で他の製品に関するプロセスが
再開される。申込者４０が取引口座を持っている場合
は、それが承認された製品のリストから選択され、その
取引口座に関する基本情報が受託システム６０に入力さ
れる。イベント４２０、４２２、および４２４を参照の
こと。申込者４０に関連付けられた取引口座がない場
合、イベント４０２が実行され、申込者４０は自分の承
認済み口座のリストから次の口座を選択する。

【０１２０】承認された預金製品の申し込みが処理され
た後、信用限度などの信用製品が処理される。信用限度
口座が開設されない場合、係員４２は、申込者４０が預
金証書（ＣＤ）口座の開設を承認されているか否かを受
託システム６０からチェックする。イベント４２４およ
び４２６を参照のこと。申込者４０がＣＤ口座の開設を
承認されていてもこれを開設することを望まない場合、
イベント４２８および４３０で補助的な事務処理が実行
される。係員４２は申し込み文書を申込者４０用の好適
な文書キット内に集める。必要な規定の開示も提供され
る。このキットが申込者４０に提示され、再検討され
る。申し込みプロセスが続行され、イベント４６２で電
子アクセスがセットアップされる。

【０１２１】受託システム６０によってＣＤ口座が承認
され、申込者４０によって要求された場合、その額をカ
バーするのに十分な資金を申込者４０から受け取ると同
時に、ＣＤ口座が受託システム６０によって使用可能に
されることになる。イベント４３４を参照のこと。信用
限度が開設されると、係員４２によってキオスク端末ソ
フトウェア４５に対する収入の検証が開始される。これ
によって、ローカルバックオフィス８４で対応する収入
検証要求が開始され、処理される。イベント４３６およ
び４３８を参照のこと。収入の検証が開始された後、イ
ベント４２６でＣＤ申し込み（あれば）が処理され、前
述したイベント４２６に続いて記述されたイベントが続
行される。

【０１２２】最終的な文書処理は、申し込みプロセスの
他のイベントで実行される場合があることを理解された
い。

【０１２３】図２２〜２４は、申し込みの製品定義段階
で、キオスク端末ソフトウェア４５の選択されたスクリ
ーンショットを示す。図２２は、信用チェックが完了
し、申込者４０がチェックに合格した後の、Ｓａｌｅｓ
Ｐｒｏｆｉｌｅスクリーン６８０を示す。キオスク端
末ソフトウェア４５は、要求された製品に関連付けられ
たフィールドのカラーを変えることによって、承認され
た製品を申込者４０が使用できるようになったことを係
員４２に伝える。フィールド６８２、６８４、６８６、
および６８８のカラーは、キオスク端末ソフトウェア４
５によって暗くされている。したがって、申込者４０は
貯蓄製品、預金証書製品、１２ヶ月ジャンボ証券の開設
が承認された。申込者４０には、超過引出し保護、Ｖｉ
ｓａ（商標）チェックカード、および個人信用限度の資
格が与えられていない。したがって、フィールド６９０
および６９２のカラーは変更されないままである。どの
製品が承認されどの製品が承認されないかを表示するの
には、異なる視覚的機構および報告機構が使用できるこ
とが理解されよう。

【０１２４】特定の申込者に関する承認済み製品の選択
を識別するプロセスには、リスク査定の専門知識が必要
であることが理解されよう。受託システム６０はこのよ
うな問題のプロセスを組み込んでいるため、係員４２は
この査定を実行しなくてもよい。

【０１２５】ここで、係員４２は、要求されたリストか
ら承認済み製品を選択するように申込者４０に薦めるこ
とができる。この例では、申込者４０は無金利の小切手
振り出し製品を選択した。図２２を参照すると、係員４
２はフィールド６８２にある製品の隣のボックス６４６
をアクティブな状態にすることで、その製品を選択す
る。キオスク端末ソフトウェア４５は、フィールド６８
２の背景のカラーを変えることで、その製品が選択され
ていることを端末４４上に示す。本発明の実施形態で
は、ブルーになっている。続行するには、Ｏｐｅｎ（開
設）ボタン６９４を選択する。

【０１２６】図２３を参照すると、係員４２はタブ７０
０を使用して、製品販売に関連付けられた種々のスクリ
ーンにアクセスすることができる。この特定のインスタ
ンスでは、ＢａｓｉｃＩｎｆｏ（基本情報）スクリー
ン７０２にアクセスしている。ＢａｓｉｃＩｎｆｏス
クリーン７０２にはフィールド７０４を有し、申込者４
０が必要な他の情報を入力して、製品の申し込みを完了
させることができる。すべての関連フィールドの入力が
完了すると、係員４２はＯＫボタン７０６をアクティブ
な状態にする。

【０１２７】選択した製品に預入れ伝票または勘定書が
必要な場合、係員４２は取引インタフェースユニット６
４（３）に対してそれに関する適切な要求を行う（図１
１のイベント４０８に対応）。図２４は、Ｃｈｅｃｋ
Ｏｒｄｅｒ（ＣｈｋＯｒｄｅｒ）（チェック指示）ス
クリーン７１０のスクリーンショットである。他のスク
リーンと同様に、種々のフィールド７１２に情報が入力
され、ＯＫボタン７１４をアクティブな状態にして、取
引インタフェースユニット６４（３）へのチェック要求
を処理する。

【０１２８】申し込み情報を取引インタフェースユニッ
ト６４（３）に伝送するにあたって、この情報は送信前
に係員４２によって検証される。製品文書などの法的文
書は署名され、申込者４０の識別のコピーがとられる。

【０１２９】資格付与段階を完了するために、係員４２
は、図１１のイベント２７２に対応して、承認済み製品
に関する任意の情報を申込者４０に提示する場合があ
る。したがって、取引インタフェースユニット６４
（３）は、すべての使用可能な製品タイプを係員４２が
確実に識別するための、合理化されたプロセスを提供す
る。この例では、申込者４０は無金利の小切手振り出し
製品（non-interest checking product）を希望してい
るだけであるが、貯蓄製品および任意の預金証書製品を
開設する資格を与えられている。これは、図２２でこれ
らの製品のフィールド６８４、６８６、および６８８が
暗くなっていることでわかる。

【０１３０】したがって、本発明の好ましい実施形態
が、新しい申込者が銀行支店に出向くことなく銀行製品
を開設できるようにする受託システム６０を提供するこ
とが理解されよう。さらに、受託システム６０を使用す
れば、申し込みを処理する係員４２は、申し込みの金融
アスペクトに関する判断を下さなくてもよくなる。合理
化された処理では、人間が査定せずに、カスタマイズさ
れたオプションを使用して製品の適切な選択を識別する
ための方法を提供する。したがって、キオスク３０の係
員４２は、新しい製品について新しい申込者を査定する
ために、金融および信用問題に関して広範囲にわたる訓
練を受けている必要はない。さらに、受託システム６０
が申込者４０に法的な通知を提供するので、係員４２は
新しい製品の処理に関連付けられた法的な問題について
詳細なアスペクトを知っている必要がない。最も重要な
ことは、キオスク３０が銀行の支店ではないことであ
る。

【０１３１】電子アクセスの確立（２１６）および製品
文書のアセンブル（２１８＋２２０）申込者４０のため
に使用可能にされたそれぞれのタイプの製品について、
係員４２は適切な電子的デビットカードおよびチェック
カードを申込者４０に発行する。図１３は、種々の製品
に対する電子的アクセスを確立するのに使用される本発
明の好ましい実施形態のプロセスを示す流れ図を示す。

【０１３２】申込者４０が口座への電子アクセスをすで
に有している場合、新しく開設された口座は適切な電子
アクセスシステムにリンクされる。電子アクセスシステ
ムには、銀行カード、チェッキングカード、デビットカ
ード、ＡＴＭカード、インターネットアクセスシステ
ム、および電話アクセスシステムが含まれる。イベント
５００、５０２、および５０４を参照のこと。

【０１３３】申込者４０が自分の製品への電子アクセス
を持っていない場合、係員４２はキオスク３０にあるカ
ードの在庫からブランクのアクセスカードを取り出し、
キオスク端末ソフトウェア４５およびカードリーダ４６
を使用して、申込者４０が自分のカードに関するＰＩＮ
をプログラムできるようにする。ＰＩＮオフセット計算
およびＶＲＵアクセスを含むＰＩＮ処理は、係員４２に
よってキオスク端末ソフトウェア４５で処理される。イ
ベント５０６、５０８、５１０、５１２、および５１４
を参照のこと。

【０１３４】申込者４０は、イベント５１６で適切なＶ
ＲＵパスワードおよびアクセスを確立することができ
る。必要であれば、イベント５１８および５２０でチェ
ックカードアクセスが確立される。ＡＴＭアクセスは、
イベント５２２で検証される。ローカルバックオフィス
８４処理には、イベント５２４で適切なウェルカムキッ
トをインターネット口座に提供すること、およびイベン
ト５２６で個人別に区別されたチェッキングカードを提
供することが含まれる。プロセスは、イベント５２８に
示したように次の段階に続く。

【０１３５】受託システム６０に製品を確立するための
主なステップが完了した。承認された製品はアクティブ
であり、特定の製品に適切なすべての制約に従ってお
り、申込者４０は製品に関連付けられた任意のアクセス
システムを介して自分の製品にアクセスすることができ
る。申込者４０に個人信用限度（ＰＬＣ）が与えられる
場合、この時点でＰＬＣが開設されるが、初期時には関
連付けられた信用がない。ローカルバックオフィス８４
の信用貸しの専門家がいったん申込者４０の収入を検証
すれば、承認された信用貸し額がＰＬＣに提供される。

【０１３６】開設された口座への電子アクセスがいった
ん完了すると、申込者４０はキオスク３０を離れる。開
設された口座の処理を完了するには、係員４２がすべて
のオリジナル申し込み文書をまとめて、処理および格納
するために取引インタフェースユニット６４（３）のロ
ーカルバックオフィス８４に転送する。これで係員４２
は新しい製品に関する申し込み処理のすべてのステップ
を完了し、他の申込者４０からの新しい照会および申し
込みに応じることができる。図８のイベント２１８
（１）、２１８（２）、および２１８（３）を参照のこ
と。

【０１３７】バックオフィスでは文書を受け取ると、イ
ベント２２０で受託システム６０内の情報に照らして検
証する。必要に応じてファイルの補正が実行される。受
託システム６０は申込者４０に関する申し込み処理を完
了する。

【０１３８】以下に、本発明の好ましい実施形態に関す
る、取引インタフェースユニット６４（３）による申し
込み処理について、より詳細に説明する。申込者４０が
使用可能な製品は、標準、学生、青年、および非居住者
の４つのプロセッシングパスのうちの１つに従う。標準
パスはデフォルト値のパスである。学生パスは、現在高
校終了後全日制教育機関に在籍している申込者に使用さ
れる。青年パスは、１９歳に達していない申込者に使用
されるが、この年令は調整可能である。非居住者パス
は、米国内に定住住所を持たない申込者用のパスであ
る。他の分類、または異なる分類を作成または使用でき
ることが理解できよう。

【０１３９】それぞれのパスは同じ処理順序を使用し
て、申込者４０がどの製品を使用できるかを判定する。
ただし、各パスには、製品のタイプごとに使用可能な区
別されたしきい値および製品のタイプ内で使用できるオ
プションがある。それぞれのパスで、申し込みを分析す
るのに決定マトリックスが使用される。表１は、各パス
で使用可能な製品の例を示すものである。

【０１４０】

【表１】表１：製品パスに対して許可された製品チェッキングチェッキングチェッキングチェッキングチェックカードチェックカードチェックカードチェックカード超過引出し超過引出し超過引出し信用限度

【０１４１】本発明の好ましい実施形態では、取引イン
タフェースユニット６４（３）が、申込者４０のＣＩＦ
１０からの年令、住所、および状況情報から、適切な
パスを識別する。申込者４０がそのパスで使用できない
製品タイプを要求すると、処理は終了してエラーメッセ
ージが端末４４に送信される。共同製品申し込みの場
合、係員４２はそれぞれの申込者４０が要求した製品が
同一であることを確認しなければならない。

【０１４２】申し込み処理時に、取引インタフェースユ
ニット６４（３）が信用および不正使用報告書の結果を
使用して、製品があればどの製品を申込者４０に提示す
るべきか、制約があればどの制約を製品に与えるか、お
よび信用限度があればどの信用限度が申込者４０に使用
できるかを査定する。

【０１４３】信用報告書を使用して、取引インタフェー
スユニット６４（３）は、申込者４０に関連付けられた
マイナスの信用イベントを処理する除外基準評点を作成
する。これには、破産の記録（現役、解雇、または免
職）、先取特権、受け戻し権喪失、徴収記録、債権差し
押さえ、死亡、または他の通告可能イベントが含まれ
る。これらのイベントには評点が付けられ、評点には申
込者４０が使用可能な製品の選択を識別するための他の
項目が添えられる。

【０１４４】さらに、信用報告書からのアスペクトを使
用して、各承認済み製品タイプにどの特定パラメータが
承認されるかを判定するための決定マトリックスが使用
される。図２５は、標準製品パス用の模擬決定マトリッ
クスの一部を示すものである。以下のフィールドが決定
マトリックスを含む。

【０１４５】

【表２】

【０１４６】この例の場合、受託システム６０が申込者
４０の信用報告書の結果を使用して、申込者４０を６３
点と判定したと想定する。したがって、この申し込みは
８０８に示される３行目に当てはまる。３行目の場合、
決定フィールドはこのカテゴリに当てはまる申込者に次
のような決定を与える。チェッキング製品は承認され
（ＤＤ＝Ｙ）、チェックカードは承認され（ＣＫ＝
Ｙ）、ＶＩＰアクセス２が与えられ（ＶＰ＝２）、＄２
００の超過引出し保護が許可され（ＯＤ＝２００）、＄
１００の信用限度が与えられる（ＬＣ＝１００）。

【０１４７】学生、青年、および非居住者パス用の決定
マトリックスは、それぞれ同様のフィールドを有する
が、各申込者のカテゴリに異なる信用リスク戦略を適応
させるために、それぞれのフィールドに異なる入力をす
ることができることが理解できよう。各フィールドの内
容は異なっても決定マトリックスの構造は同じでもよい
ことがわかる。決定マトリックスにアクセスしこれを利
用するためのプロセスは、各パスで同じであることが理
解できよう。さらに、マトリックスを使用する代わりに
１つまたは一連の決定式を使用して、任意のまたはすべ
てのパスの特定の申込者４０に対して、適切な製品、超
過引出し限度、および信用限度を識別できることも理解
できよう。

【０１４８】取引インタフェースユニット６４（３）
は、決定フィールドの結果８１０を係員４２の端末４４
に送信する。キオスク端末ソフトウェア４５は、図２０
に示されるように、この結果を適切なスクリーン上に表
示する。その後、係員４２は申し込みの処理を続行し、
申込者４０に承認された製品と任意のパラメータ制約を
識別させる。

【０１４９】共同口座の場合、取引インタフェースユニ
ット６４（３）によって共同製品の各メンバーが査定さ
れる。取引インタフェースユニット６４（３）が、各申
込者４０に許可された製品のセットを評価し、最良の申
込者４０の結果に基づいて、許可された製品の単一のセ
ットが生成される。

【０１５０】共同製品を申し込む場合、リスト１には係
員４２が製品グループから製品を選択するのに使用でき
るアルゴリズムが含まれる。

【０１５１】リスト１１．チェッキング製品がすべての申込者に承認された場
合、ステップ２へ進む。さもなければ、チェッキング製
品が誰にも承認されない場合、共同製品として使用可能
な製品はない。処理を中止する。さもなければ、チェッ
キング製品に１人が承認された場合、チェッキング製品
用の共同製品を承認する。処理を中止する。２．チェックカードが両方の申込者に承認されるか、ど
ちらの申込者にも承認されない場合、ステップ３に進
む。さもなければ、チェックカードの承認を返す。処理
を中止する。３．ＶＩＰコードがどちらの申込者についても同じであ
る場合、ステップ４に進む。さもなければ、高い方のＶ
ＩＰコードの承認を返す。処理を中止する。４．超過引出し保護レベルがどちらの申込者についても
同じである場合、ステップ５に進む。さもなければ、申
込者の高い方の超過引出し額の承認を返す。処理を中止
する。５．信用限度がどちらの申込者についても同じである場
合、この額を返す。処理を中止する。さもなければ、申
込者の高い方の信用限度の承認を返す。処理を中止す
る。信用限度は別の計算によって上書きすることができ
る。このリストは取引インタフェースユニット６４
（３）の処理に組み込めることが理解されよう。

【０１５２】上記の説明から、申込者４０に対して預金
口座を識別および開設するためのプロセスが合理化され
たことが理解されよう。申し込みを処理する係員４２
は、申込者４０の金融状況の査定方法について広範囲に
わたる訓練を受ける必要がない。

【０１５３】さらに、本発明は、係員４２がいずれの決
定にも関与せず、遠隔端末から預金口座を自動的に処理
して開設することができるシステムを備えることも理解
できよう。

【０１５４】図２６は、家庭でインターネット端末３４
を使用して銀行製品を申し込む申込者４０を示す。接続
３８が端末３４を受託システム６０にリンクする。この
環境で預金口座を申し込むプロセスは、前述のようなキ
オスク３０で銀行製品を申し込むためのプロセス流れと
同様である。ただし、（前述のように、係員４２が申込
者４０の運転免許証の事項を取得して入力するのと同様
の機能を提供して）申込者４０のＩＤについて適切な検
証を実行するために、申込者４０はデジタル証明書を使
用することができる。申込者４０が受託システム６０に
適切なデジタル証明書を提供し、信頼される第三者によ
って申込者４０を明確に識別するものであることが検証
されると、受託システム６０は、キオスクを通じて申し
込みが処理されるのと同じ方法で、任意の預金口座を自
動的に処理および承認することができる。この実施形態
では、キオスク３０の必要性がなくなる可能性がある。

【０１５５】特許請求の範囲に定義された本発明の精神
および範囲を逸脱することなく、本明細書に記載の好ま
しい実施形態に対して詳細な種々の修正が実行可能であ
ることを、当分野の技術者であれば留意されたい。

【図面の簡単な説明】

【図１】本発明の好ましい実施形態で使用されるデータ
ベース内の、顧客情報ファイルの報告書を表す概略図で
ある。

【図２】図１の顧客情報ファイルに関連付けられた銀行
製品のリストを表す概略図である。

【図３】本発明の好ましい実施形態の預託システムに関
連付けられたキオスクを表す絵画図である。

【図４】本発明の好ましい実施形態の預託システムに接
続された図３のキオスクを示す概略図である。

【図５】図４の預託システムを示す構成図である。

【図６】図５の預託システムが使用する申込者信頼性評
点システムを示すブロック図である。

【図７】本発明の好ましい実施形態の預託ネットワーク
を示す構成図である。

【図８】図５の好ましい実施形態に関連付けられた預金
預かり口座を開設する際に発生するイベントを示す流れ
図である。

【図９】図８の流れ図で、顧客を定義するイベントを詳
細に示す流れ図である。

【図１０】図９の流れ図で、既存の顧客を認証するイベ
ントを詳細に示す流れ図である。

【図１１】図８の流れ図で、顧客に資格を付与するイベ
ントを詳細に示す流れ図である。

【図１２】図８の流れ図で、口座を定義するイベントを
詳細に示す流れ図である。

【図１３】図８の流れ図で、電子アクセスをセットアッ
プするイベントを詳細に示す流れ図である。

【図１４】図９で使用される顧客記録について顧客情報
ファイルを検索するための顧客照会で、図３のキオスク
で使用される端末の表示スクリーンを表す図である。

【図１５】図１４の顧客照会の結果を示す顧客選択形式
の表示スクリーンを表す図である。

【図１６】図９で使用される顧客情報を入力するための
表示スクリーンを表す図である。

【図１７】図９で使用される追加の顧客情報を入力する
ための表示スクリーンを表す図である。

【図１８】図１１で使用される信用検証用のすべての製
品を示す表示スクリーンを表す図である。

【図１９】図１１で使用される信用検証要求を示す表示
スクリーンを表す図である。

【図２０】図１１で使用される結果をまとめた図であ
る。

【図２１】図１１で使用されるヒットなしメッセージを
示す表示スクリーンを表す図である。

【図２２】図１１で使用される推奨される製品リストで
ある。

【図２３】図１２で使用される基本情報タブである。

【図２４】図１２で使用されるチェック指示タブであ
る。

【図２５】図５の預託システムで使用される決定マトリ
ックスの抽出を表す図である。

【図２６】本発明の実施形態を家庭で使用している申込
者を表す絵画図である。

─────────────────────────────────────────────────────

【手続補正書】

【提出日】平成１３年１月２２日（２００１．１．２
２）

【手続補正１】

【補正対象書類名】図面

【補正対象項目名】図１１

【補正方法】変更

【補正内容】

【図１１】 ─────────────────────────────────────────────────────

【手続補正書】

【提出日】平成１３年３月２２日（２００１．３．２
２）

【手続補正１】

【補正対象書類名】図面

【補正対象項目名】図１

【補正方法】変更

【補正内容】

【図１】

【手続補正２】

【補正対象書類名】図面

【補正対象項目名】図２

【補正方法】変更

【補正内容】

【図２】

【手続補正３】

【補正対象書類名】図面

【補正対象項目名】図３

【補正方法】変更

【補正内容】

【図３】

【手続補正４】

【補正対象書類名】図面

【補正対象項目名】図４

【補正方法】変更

【補正内容】

【図４】

【手続補正５】

【補正対象書類名】図面

【補正対象項目名】図５

【補正方法】変更

【補正内容】

【図５】

【手続補正６】

【補正対象書類名】図面

【補正対象項目名】図６

【補正方法】変更

【補正内容】

【図６】

【手続補正７】

【補正対象書類名】図面

【補正対象項目名】図７

【補正方法】変更

【補正内容】

【図７】

【手続補正８】

【補正対象書類名】図面

【補正対象項目名】図１４

【補正方法】変更

【補正内容】

【図１４】

【手続補正９】

【補正対象書類名】図面

【補正対象項目名】図１５

【補正方法】変更

【補正内容】

【図１５】

【手続補正１０】

【補正対象書類名】図面

【補正対象項目名】図１６

【補正方法】変更

【補正内容】

【図１６】

【手続補正１１】

【補正対象書類名】図面

【補正対象項目名】図１７

【補正方法】変更

【補正内容】

【図１７】

【手続補正１２】

【補正対象書類名】図面

【補正対象項目名】図１８

【補正方法】変更

【補正内容】

【図１８】

【手続補正１３】

【補正対象書類名】図面

【補正対象項目名】図１９

【補正方法】変更

【補正内容】

【図１９】

【手続補正１４】

【補正対象書類名】図面

【補正対象項目名】図２０

【補正方法】変更

【補正内容】

【図２０】

【手続補正１５】

【補正対象書類名】図面

【補正対象項目名】図２１

【補正方法】変更

【補正内容】

【図２１】

【手続補正１６】

【補正対象書類名】図面

【補正対象項目名】図２２

【補正方法】変更

【補正内容】

【図２２】

【手続補正１７】

【補正対象書類名】図面

【補正対象項目名】図２３

【補正方法】変更

【補正内容】

【図２３】

【手続補正１８】

【補正対象書類名】図面

【補正対象項目名】図２４

【補正方法】変更

【補正内容】

【図２４】

【手続補正１９】

【補正対象書類名】図面

【補正対象項目名】図２５

【補正方法】変更

【補正内容】

【図２５】

【手続補正２０】

【補正対象書類名】図面

【補正対象項目名】図２６

【補正方法】変更

【補正内容】

【図２６】

───────────────────────────────────────────────────── フロントページの続き (71)出願人 500534810 ＣｏｍｍｅｒｃｅＣｏｕｒｔＷｅｓｔ，15ｔｈＦｌｏｏｒ，Ｔｏｒｏｎｔｏ，Ｏｎｔａｒｉｏ，ＣａｎａｄａＭ５Ｌ１Ａ２ (72)発明者アンソニーマイケルジャボアアメリカ合衆国 32746 フロリダ州ヒースローストーンフィールドループ 696 (72)発明者ブライアンマイケルキャシディーカナダエル６ジェイ４ピー６オンタリオ州オークビルアシュロード 387

Claims

【特許請求の範囲】

【請求項１】預金口座申込処理ネットワークであっ
て、支店以外の場所で、申込者から申込者識別情報および申
込者の所望する預金製品を含む預金口座申込情報を受け
取るため、および前記申込者の情報をコンピュータ読取
り可能預金口座申込データに変更するための申込者シス
テムと、前記申込者システムからのコンピュータ読取り可能預金
口座申込データを処理するための、自動申込処理システ
ムとを備え、該自動申込処理システムは、前記申込者が所望の預金製品の資格を与えられているか
否かを判定するためのコンピュータ読取り可能資格付与
要求を作成するために、受け取った申込データを処理す
るための自動手段と、前記資格付与要求に対するコンピュータ読取り可能応答
を処理するための自動手段と、前記資格付与要求に対する応答に基づいて前記預金製品
を承認するための自動手段と、前記申込者によりアクセス可能な承認済み預金製品に関
する預金口座のための自動手段とをさらに備えたことを
特徴とする預金口座申込処理ネットワーク。
【請求項２】前記申込者システムは、検証された識別
情報を含む申込情報を入力するための、支店以外の場所
にある端末をさらに備えたことを特徴とする請求項１に
記載の預金口座申込処理ネットワーク。
【請求項３】前記端末は識別情報を検証する係員によ
って操作されることを特徴とする請求項２に記載の預金
口座申込処理ネットワーク。
【請求項４】前記申込者システムはキオスク内に収容
されることを特徴とする請求項２に記載の預金口座申込
処理ネットワーク。
【請求項５】前記キオスクは、預金口座用の預金を受
け取るためのＡＴＭおよび電話をさらに含み、前記申込
者システムは、開設された預金口座にアクセスするため
のテレフォンバンキングインタフェースをさらに備えた
ことを特徴とする請求項４に記載の預金口座申込処理ネ
ットワーク。
【請求項６】前記キオスクは、前記申込者により使用
されるインターネット端末をさらに含み、前記処理シス
テムは、開設された預金口座にアクセスするためのイン
ターネットバンキングインタフェースをさらに備えたこ
とを特徴とする請求項４に記載の預金口座申込処理ネッ
トワーク。
【請求項７】前記キオスクは、系列販売店内に配置さ
れることを特徴とする請求項４に記載の預金口座申込処
理ネットワーク。
【請求項８】前記資格付与要求に対する応答を処理す
るための自動手段は、前記申込者に関する信用履歴情報
を取得して評価することを特徴とする請求項１に記載の
預金口座申込処理ネットワーク。
【請求項９】前記資格付与要求に対する応答を処理す
るための自動手段は、不正使用パラメータに照らして前
記申込者情報を評価することを特徴とする請求項８に記
載の預金口座申込処理ネットワーク。
【請求項１０】前記申込者システムは、預金口座申込
情報を入力するための支店以外の場所にある端末と、該
端末で申込者が入力した申込者の識別情報を検証するた
めの自動手段とをさらに備えたことを特徴とする請求項
１に記載の預金口座申込処理ネットワーク。
【請求項１１】前記預金口座は銀行預金口座であるこ
とを特徴とする請求項１に記載の預金口座申込処理ネッ
トワーク。
【請求項１２】支店以外の場所をさらに備えたことを
特徴とする請求項１に記載の預金口座申込処理ネットワ
ーク。
【請求項１３】預金口座を開設するための自動申込処
理システムであって、申込者識別情報および所望の預金
製品を含む預金口座申込情報を支店以外の場所で申込者
から受け取って申込者情報をコンピュータ読取り可能預
金口座データに変換する申込者システムに関連付けて使
用され、該処理システムは、前記申込者システムから、コンピュータ処理された預金
口座申込データを受け取るための入力と、前記申込者が所望の預金口座に対して資格を与えられて
いるか否かを判定するためのコンピュータ処理された資
格付与要求を作成するために、前記受け取った申込デー
タを処理するための自動手段と、前記資格付与要求に対する応答を処理するための自動手
段と、前記資格付与要求に対する応答に基づいて、前記申込者
に所望の預金口座を許可するための自動手段と、前記申込者によるアクセスが許可された預金口座を開設
するための自動手段とを備えたことを特徴とする処理シ
ステム。
【請求項１４】預金口座申込を処理するための方法で
あって、申込者の識別情報および申込者の所望の預金製品を含む
顧客申込要求を、支店以外の場所で申込者から受け取る
ステップと、申込者の情報をコンピュータ読取り可能預金口座申込デ
ータに変換するステップと、前記コンピュータ処理された預金口座申込データを処理
することによって、顧客申込要求に自動的に資格を付与
するステップであって、前記申込者が所望の預金製品に対して資格を付与されて
いるか否かを判定するために、コンピュータ読取り可能
資格付与要求を自動的に作成するステップと、前記資格付与要求に対するコンピュータ読取り可能応答
を自動的に処理するステップと、前記資格付与要求に対する応答に基づいて所望の預金製
品を自動的に承認するステップとを備えたステップと、前記申込者によりアクセスできる承認された預金製品の
ための預金口座を自動的に開設するステップとを備えた
ことを特徴とする方法。
【請求項１５】前記顧客申込に資格付与するステップ
は、申込者に関する信用履歴情報を取得して評価するス
テップを備えたことを特徴とする請求項１６に記載の預
金口座申込を自動的に処理するための方法。
【請求項１６】預金口座申込を処理するための方法で
あって、所望の預金製品を開設するために、申込者への申込要求
を受け取るステップと、コンピュータ読取り可能預金口座申込データを処理する
ことによって、支店以外の場所にいる申込者へのコンピ
ュータ読取り可能預金口座申込要求に自動的に資格を付
与するステップであって、該顧客申込要求に自動的に資
格付与するステップは、前記申込者が所望の預金製品に対して資格を付与されて
いるか否かを判定するために、コンピュータ読取り可能
資格付与要求を自動的に作成するステップと、前記資格付与要求に対するコンピュータ読取り可能応答
を自動的に受け取るステップと、前記資格付与要求に対する応答に基づいて所望の預金製
品を自動的に承認するステップとを備えたステップと、前記申込者によりアクセス可能な、承認された預金製品
のための預金口座を自動的に開設するステップとを備え
たことを特徴とする方法。