JP2011505047A - 自動請求処理システム - Google Patents

Abstract

本発明は、保険契約または債務保護契約の下で発せられた請求の妥当性を評価する、コンピュータシステムベースの自動損失検証システムを提供する。請求者に、保険会社または貸手にコンタクトを取り、請求を発して当該損失事象の完全な文書証明を提供するよう要求することに代えて、システムは、予測モデリングと複数の見込みリスク要因に基づくリスク評価ツールを用いて、当該請求の相対的リスクを事前にスコア化する。関連する自動損失検証ツールは、このリスクスコアおよび前記請求に接続された他の情報を用いて、当該請求が判定プロセスを介して承認される前に満たされなければならない相対的確実性レベルを割り当て、システムが当該請求を検証するため自動的にアクセスする、サードパーティーが提供する証明ソースまたは証明ソースの組合せを割り当てる。
【選択図】図２

Description

関連出願への相互参照
この出願は、２００７年１１月２８日に出願された、米国仮出願第６１／００４，５８７号に基づく優先権を主張し、この文献は、参照によって、その全体が本願に組み込まれる。

本発明は全般に、保険契約顧客が送信した保険請求の処理に関連し、より具体的には、請求の信頼性についてサードパーティーが供給するデータに依拠する検証処理を介して、保険会社がそのような請求を自動的に処理するシステムに関する。

保険は、様々な状況における経済的な損失に対する保護を提供する手段を意味する。例えば生命保険は、稼ぎ手である親が死亡した場合に、家族が収入損失を埋め合わせることを手助けする。健康保険は、稼ぎ手や家族の一員が病気になったとき、医療費を支払うことを手助けする。火災保険は、保険契約者の家または建物が火災によって破壊されたときに、損失の全部または一部を補償する。自動車または海上保険は、自動車または船舶事故に起因する損失のコストを負担することを手助けする。

保険は、人々の間で損失を分担共有する原則の下に成り立つ。特定種類の損失に対して保険をかけることを望む人々は、保険会社に通常の保険料を支払うことに同意し、保険会社はその見返りに、「保険契約」と呼ばれる契約を提供する。要するに、保険会社は保険契約者に、当該保険契約内で特定される種類の損失に対してある量の金銭を支払うことを約束する。保険会社は、保険料を、株式購入、債券、抵当、政府債券、その他収益を生む投資に用い、全ての保険契約者から集めた保険料と組み合わせて、保険契約の下で責任を負う全ての集合的給付または請求に対する支払いを行うための追加的金銭を生み出す。

保険は、大規模ながら予想できない損失が発生した場合に補填する（すなわち支払う）ことになる、契約上の保証に対する保険料支払の形態で、小さいながらも確実に発生する損失を取引することを、保険契約者が厭わずに行うから成立している。保険契約者は、保険契約の下で保険会社から何の利益も受け取らないかもしれないが、保険契約は保険契約者に安心感を与えるので、保険料は無駄にはならない。したがって保険契約者は、リスクが内在している場合であっても、生じ得る経済的損失を心配することなく、資産を所有し、車を運転し、ビジネスを運営し、その他多くの活動に専念することができる。

多くの雇用者が被用者に伝統的に提供する重要利益は、身体傷害保険である。このような身体傷害保険は、「雇用者が提供する保険」または「団体保険」の形態をとり、その根拠となっている保険会社は、被用者が身体に障害を受けて仕事ができないか、または通常より短い時間しか働くことができない間、当該被用者の逸失収入の一部を支払う。身体障害は、典型的には、被用者が病気または障害に起因して、通常業務の実体的および実質的な責務を果たすことが制約されているという性質を有し、同病気または障害に起因する月収の損失をともなう。団体障害保険も、被用者が、初期給付期間の後、有給の研修、教育、および／または体験中に身体障害を受けた場合、通常職務から得るべき収入の損失を補償する。保険契約は、被用者の短い初期期間の身体障害（短期障害）、または被用者の身体障害が特定の「除外期間」、例えば９０日間継続した後のより長い期間の身体障害（長期障害）を補償することができる。除外期間が経過しても当該被用者が依然として身体障害を負っている場合、当該被用者は典型的には、身体障害の期間を上限量として、障害を負う前に稼いでいた月収の所定割合（例えば６０％）の支払いを受ける。しかし、身体傷害保険契約は、リスクを緩和するため、給付支払期間に上限を設けることもできる。

生命、火災、身体障害保険の他、顧客が求めるリスク保護補償の他形態には、失業保険と「債務保護」が含まれる。失業保険契約は、非自発的失業時において、個人および受給者に金銭を支払う。簡単にいうと、債務保護は、生命、身体障害、非自発的失業保険の与信に似ている。しかし、債務保護は、保険契約なのではなく、与信契約書の補正であるといえる。すなわち、貸手は料金を支払って、借手が死亡し、身体障害を受け、または非自発的失業状態となったとき、債務の全部または一部を保留し、またはキャンセルすることができる。また、休職に対する補償も存在する。これは、産休を取らなければならないとき、債務が部分的に延期され、またはキャンセルされる、というものである。

保険会社と貸手は、一般に、保険または保護プログラム契約によって補償される状況の下、保険契約者と受給者に、保険契約またはプログラムの条項および条件によって特定される給付を支払う準備をしており、かつ進んでその給付を行う。しかし、そのような約束を守る前に、保険業者および貸手は同様に、保険契約者または受給者が報告した事象の状況が真に発生しており、かつ保険または契約の条項の範囲に合致しているかを検証しなければならない。これは、保険会社または貸手が保険または契約に対して課す料金が、保険契約者の実体験とそれが起こる確率の法則に基づいて、補償すべき発生事象のリスクを反映するように、元々調整されているからである。保険契約が補償する限度内で、死亡し、身体障害を受け、非自発的失業状態となり、といったことが起きそうな保険契約者に対して支払うことになる可能性のある給付量に結び付けて、保険会社または貸手は、そのような損失を補償する保険契約の価格を定め、保険会社が事業を運営するコストを補償し、株主（または相互保険会社の保険契約者）に妥当な利益を提供することができる。しかし、支払いが詐欺または保険補償の誤った請求に基づいてなされた場合、保険プログラムの支払能力は、顧客に課される料金を増やす必要が結果として生じるというリスクにさらされる。

したがって、保険業者および貸手は同様に、保険契約者が発した請求を検証する手続きを開発してきた。このような業界の損失検証手続きは典型的に、事象の性質を判定し、当該事象が実際に発生していることを検証する、いくつかのデータ収集ステップで構成されている。保険契約提供業者は典型的に、請求者に対して、請求フォームを受け取るための郵送情報を提供するため、ある電話番号に電話するよう要求する。請求者は、その請求フォーム内に説明されている様々な質問に答えなければならない。保険契約提供業者はまた、請求者に対して、補償すべき事象が実際に起こったという証明を提供するよう要求する。例えば、生命保険契約の下における死亡の場合、請求者は、死亡証明書または解剖報告書のコピーを要求されるかもしれない。身体障害の場合、請求者は、補償を受ける者が身体障害を受け、または働くことができない旨を述べる医師の書面を提供するよう求められるかもしれない。失業については、補償を受ける者は、地方行政府の職業斡旋所に請求した旨の証明を提供するよう要求されるかもしれない。

このような、補償すべき事象の証明を提出するよう要求することは、典型的には、詐欺または顧客の誤謬の実リスクを問わず、全ての顧客に対してなされる。保険会社または貸手は単に、全ての請求者が、請求する全ての給付を受けるのに適格であることを証明しようとする。もちろん、この検証プロセスは、書面手続に集中しており、請求者に給付を支払うか否かを決定する前に保険会社の社員が追跡調査をすることを要求する。これはまた管理的観点からコスト高であり、したがって、既に医療費と薬剤費からの継続的な上昇圧力を受けているヘルスケア費用と保険費用をさらに増やしている。保険業界が、承認から１０日以内に請求に対して支払うよう努力している一方で、請求の調査と検証のプロセスに３０日かかることは、まれなことではない。請求者が、損失事象の後に請求を報告するのを３０〜６０日間待機したという事実を仮定すると、請求者の感覚からすれば、保険会社が支払いをするのに７０〜１００日間かかったことになり、これは確かに長いように思える。さらに、保険会社が亡くなった被保険者の喪失感に苦しんでいる受給者に対して証拠となる証明を強く求めることは、過度に過ぎ、必須なことではないように思える。

保険業界内において、保険受給者からのまたは保険受給者に代わる支払請求を検査し判定する管理プロセスを簡素化するための、様々な努力がなされてきた。例えばヘルスケア業界内では、ヘルスケア業者は、患者に提供された医療サービスと供給品に対する患者の保険会社からの支払いを要求する。このような支払要求を保険会社が管理する処理は、次第に自動化され、ヘルスケア業者のオフィスの技術者は、医療保険請求を電子的に作成して中央処理システムへ送信する。医師、患者、医療サービス、保険業者、などを識別する情報は、典型的には医療保険請求の一部として含まれている。中央処理システムは、医師、患者、保険業者が、実際に請求処理システムに参加していることを検証する。このような自動化された検証ステップの後、中央処理システムは、医療保険請求を特定の保険会社用の適切なフォーマットに変換し、その請求を当該保険業者に転送する。保険会社の従業員が手動で当該請求を判定し承認すると、保険業者は当該ヘルスケア業者の銀行口座に対する電子送金を開始する。これについては例えば、Ｄｒｅｎｎａｎが出願した、米国公開特許第２００３／０１８７６９５号を参照されたい。

しかしながら、保険業者にとって、中央処理システムから医療保険請求を受け取った後にこれを検査して承認するのは、いまだ多大な時間と費用を要する。手動の検査と判定はコスト高であるので、保険業者はこれに代えて、最小限度検査〜検査なしで多数の請求を単純に支払うことを選ぶかもしれない。しかしこの選択肢は、詐欺または誤謬請求の犠牲になる可能性があるので、次善策である。

Ｂｅａｌｋｅ等が出願した、米国公開特許第２００５／００７５９１２号は、関係者（すなわち保険業者および請求者）に対し、これらの者が請求処理の進捗を監視できるようにするための電子的アクセスを提供する、電子保険請求調停システムを開示している。支払いは、請求が承認されると即座に請求者へ電子送金されるが、この承認決定のための検査プロセスもまた、本質的に手動である。Ｐｅｔｅｒｓｏｎ等に特許された米国特許第６，３４３，２７１号は、請求が手動検査されるか、または保険業者によって略式で支払われるかをヘルスケア業者に示唆するため、請求がヘルスケア業者によって送信される前に、請求を「事前判定」する電子システムを提供する。この手法によれば、ヘルスケア業者は、保険業者による略式支払を得る見込みを向上させるため、医療保険請求を調整し、これにより支払受領を早めることができる。これについては、Ｐｅｔｅｒｓｏｎ等によって出願された、米国公開特許第２００２／００１９７５４号を参照されたい。

請求検査プロセスのいくつかの側面を部分的に自動化する他の電子システムが、保険業界内で知られている。例えば、Ｓｏｈｒ等によって出願された、米国公開特許第２００７／００５０２１９号は、二重支払を防止するため、請求者に以前に支払われた請求に対する保険請求をチェックするシステムを教示している。Ｔｈｏｌｌによって出願された、米国公開特許第２００６／０１４９７８４号は、保険請求が関連する保険契約によって補償されているか否かを判定するため、手動判定に先立って保険請求を事前検査するシステムを記載している。一方、ＲｏｗｅIII等によって出願された、米国公開特許第２００４／００７８２４７号は、完全性と一貫性のため、手動判定に先立って請求を事前検査する、電子請求処理システムを開示している。不完全な、または内部的に一貫性のない請求は、手動請求判定者の時間を節約し、拒否される請求の数を減らすため、システムによって請求者へ見直しのため差し戻すことができる。これについては、Ｈｏｆｆｎｅｒ等によって出願された、米国公開特許第２００７／００３８４８４号を参照されたい。

保険会社が保険業者と請求者の関係の効率を改善することを手助けする、他の電子システムが存在する。例えば、Ｋｅｎｎｅｄｙ等によって出願された、米国公開特許第２００７／０００５４０２号は、保険業者または患者が医療保険契約の条項の下で請求に対して支払うか否かを判定するために医師が用いるシステムを教示している。医師は、この情報を用いて、請求書を適切に発行し、患者の医療費貯蓄口座が開いていれば、そこからリアルタイムで支払いを受けることができる。にもかかわらず、請求は依然として保険業者が判定しなければならない。したがって保険会社は、この判定ステップを支援する技術ソリューションを実装してきた。

Ｇａｎｄｅｅ等によって出願された、米国公開特許第２００５／００３８６８２号は、保険会社が、検査を対面で行うため査定人を送る必要なく、請求された災害損失を遠隔から検査することができるようにする、双方向映像／音声通信を開示している。Ｆｒｅｅｄｍａｎ等によって出願された、米国公開特許第２００２／０００２４７５号は、査定人が詐欺請求を見抜くために必要な請求情報と映像イメージを取り込むために車両保険会社が用いるシステムを提供する。Ｃｒａｉｎによって出願された、米国公開特許第２００４／０１１７３２９号は、破損した荷物に対する請求を判定するため郵便局が使用する同様のシステムを開示している。Ｃａｄｉｇａｎ等によって出願された、米国公開特許第２００４／００９３２４２号は、保険請求処理に関連する複数の機能を実行し、査定人が請求を判定するために必要なデータをトラッキングするモジュールを有する電子システムを記載している。

しかしこれら従来技術のシステムは全て、保険請求の手動判定が必要となり、手動判定プロセスにおける効率を高めるために必要な情報を取り込んで管理するのみである。Ｍｅｎｅｎｄｅｚに特許された米国特許第７，２０３，６５４号は、キーワード検索、請求履歴データ、および請求量を請求と比較し、いずれの請求サブセットが、特に手動精査と判定の精度を保証する際の詐欺または誤謬のより高いリスクによって特徴付けられるかを判定する、電子システムを提供することによって、さらに一歩進もうとしている。他の全ての請求は、精査と判定なしに、保険業者によって自動的に支払われる。これについては、Ｍｅｎｅｎｄｅｚによって出願された、米国公開特許第２００７／０１５０３１９号を参照されたい。

実際は、全ての請求が保険会社を誤謬や詐欺の行為に同じ程度だけさらしているわけではない。したがって、全ての請求者が論理的に同じ程度の検証を要すべきであるわけではない。特定ケースの事情は、請求に関する詐欺または誤謬のより高いリスクまたは低いリスクを示唆するかもしれない。例えば、２０年以上保険料を支払い、死亡時に８０歳であったと報告され、見込み総受給額が５００ドルである保険契約者の死亡に対する生命保険契約の下に請求された損失請求は、保険料を支払っている期間が１ヶ月のみであり、死亡時に２５歳であったと報告され、見込み総受給額が１００，０００ドルである保険契約者の死亡に対する請求と、同じ程度のリスクを表しているわけではない。８０歳の者が死亡する可能性は、２５歳の者が死亡する可能性よりも高い。請求者が５００ドルの給付支払いに対して詐欺を犯す可能性は、他の要因を考慮すると、１００，０００ドル給付に対する詐欺を犯す可能性よりも小さい。さらに、顧客との関係の長さは、詐欺の可能性に影響を与える。

請求者グループのなかには、その請求が、当該業界によって請求を検証するため用いられる手続きにおける判定ステップの全セットをいったん通過したのであれば、承認されるべき、また承認されるであろうと思われる、サブグループが存在する。同時に、残りの請求者は、従来の検証プロセスを進めると、その請求は拒否されるべきであり、また拒否されることになるであろう。残念ながら、請求が承認されるべき請求者サブグループを事前に予測することは非常に難しい。Ｍｅｎｅｎｄｅｚの「全てか全くなしか」の判定システムは、「完全判定」と「判定なし」の間の中間地点がないので、保険業者にとってあまり魅力的でない。統計的な可能性によると、よりわずかな金額ではあるかもしれないが、無判定請求の一部は、後に詐欺であることが判明することになる。したがって、保険会社と貸手は、全ての請求者に、論理的に少数の請求者にのみ適用すべきものと同程度の綿密な審査を受忍させる傾向にある。一方、保険会社と貸手は、この厳格な請求検査手続きに関する多大なコストを被っており、これにより保険料金が上昇圧力にさらされる。

したがって、請求者が保険会社または貸手にコンタクトをとり、損失情報を提供して、保険会社または貸手から、あるレベルの審査と判定に基づき、請求者の請求に対して支払いを行うことの確認と迅速な決定を受け取ることができる、簡略化された請求処理システムは、保険会社または銀行などにとっても、請求者にとっても、ともに有益である。このようなシステムは、理想的には、典型的に要求される、補償すべき事象の請求者による文書化された証明を、少なくとも高リスク請求者についてのものを除いて不要とし、代わりに、サードパーティーのデータソースが提供する、容易にアクセスすることができる証明に基づく審査および判定プロセスに依拠する。

本発明は、保険契約または債務保護契約の下における請求の妥当性を評価する、コンピュータシステムに基づく自動損失検証システムを提供する。請求を発行した請求者に、保険会社または貸手に対して請求損失の妥当性を証明する完全な文書を提供するよう要求することに代えて、システムは、予測モデルと複数の見込みリスク要因に基づくリスク評価ツールを用いて、請求の相対的リスクを事前にスコア化する。これには、請求量、損失の性質と可能性、当該保険または契約についての当該請求者の履歴、および保険会社のまたは貸手の同様請求に関する履歴が含まれるが、これらに限られるものではない。関連する自動損失検証ツールは、このリスクスコアと当該請求に結びついた他の関連する情報を用いて、自動判定プロセスを介して損失が検証される前に満たされなければならない、妥当損失の証明の相対的な確実性レベルを割り当てる。システムはまた、システムが請求を検証するため自動的にアクセスすることができる、サードパーティーが提供する証明ソースまたは証明ソースの組合せを割り当てる。請求が詐欺または無効であることについての相対的リスクを解決するために必要な、要求される証明を得ることができれば、請求は承認され、これにより請求者が文書証拠を提供するためさらに努力する必要性を回避することができる。このようにして、本発明に係る自動損失検証システムは、保険業界標準によって非常に手早く請求を評価し、承認することができる。これは、２営業日以内に、好ましくは請求者が電話、インターネットＷｅｂサイト、またはＩＶＲポータルによって請求を発してから２時間以内に、さらに好ましくは請求者が請求を発してからリアルタイムに、なされる。このとき請求者は、請求する損失の文書証明を、独自に調達して提供するよう要求されることはない。このようなシステムは、保険会社または貸手の請求判定プロセスの効率を向上させ、一方で請求者にとっては、請求体験を改善させるものである。

本発明に係る自動請求処理システムの周辺環境の概略図である。 自動請求処理システムのコンピュータによる実施形態の概略図である。 自動請求処理システムのフローチャートである。 自動請求処理システムのリスク評価ツールおよび自動損失検証ツール部分のハードウェア構成図である。 自動損失検証システムを生命保険契約に適用した図である。 自動損失検証システムを非自発的失業保険契約に適用した図である。 自動損失検証システムを身体障害保険契約に適用した図である。 自動請求処理システムのフローチャートである。 自動請求処理システムのフローチャートである。 自動請求処理システムのフローチャートである。 自動損失検証システムのリスク評価プロセス部分の概略図である。 自動損失検証システムのリスク評価プロセス部分の概略図である。 自動損失検証システムの管理コンソール部分の機能を表すスクリーンショットである。 自動損失検証システムの管理コンソール部分の機能を表すスクリーンショットである。 自動損失検証システムの管理コンソール部分の機能を表すスクリーンショットである。 自動損失検証システムの管理コンソール部分の機能を表すスクリーンショットである。 自動損失検証システムの管理コンソール部分の機能を表すスクリーンショットである。 自動損失検証システムの管理コンソール部分の機能を表すスクリーンショットである。 自動損失検証システムの管理コンソール部分の機能を表すスクリーンショットである。 自動損失検証システムの管理コンソール部分の機能を表すスクリーンショットである。 自動損失検証システムの管理コンソール部分の機能を表すスクリーンショットである。 自動損失検証システムの管理コンソール部分の機能を表すスクリーンショットである。 自動損失検証システムの管理コンソール部分の機能を表すスクリーンショットである。 自動損失検証システムの管理コンソール部分の機能を表すスクリーンショットである。 自動損失検証システムの管理コンソール部分の機能を表すスクリーンショットである。 本発明に係る制御テスト環境モジュールの概略図である。

本発明は、給付補償契約の下で、請求者に対し支払いについての迅速なコミュニケーションまたは給付決定を提供し、請求者に最小限の証明証拠を要求する、簡略化された自動システムおよび請求処理方法を提供する。本発明は、請求の性質を判定し、検証と給付補償契約内で定められたルールに基づき、請求に対して支払いを行うか否か、または他の給付が提供されるか否かについての最終決定を請求者に通知するために必要な情報を請求者から受け取る、自動請求処理システムの形態をとる。請求処理システムは、請求者が補償すべき事象に関して提供した情報に基づき、請求の詳細な要約を作成する。次にリスク評価ツールが適用され、詐欺または誤謬請求のリスクを定義するため、請求者と請求に起因するスコアを算出する。システムは次に、自動損失検証ツールを適用し、請求の性質と、請求判定が生じる前に参考にされるべき１以上の独立データ検証ソースとに基づいて、支払いまたは他の給付を承認するために必要な、相対的確実性レベルを割り当てる。単一のまたは組み合わされたこれら独立データソースは、請求検証の基準を定立し、これは、請求者と給付補償契約保険会社の社員が手動で検証する必要なしに、システムが支払いまたは他の給付を承認する肯定決定につながる。

本発明において、「給付補償契約」は、例えば死亡、身体障害、火災、または失業のような、契約上補償される事象が発生した結果として、支払いまたは他の給付を個人が受け取る、契約上の権利のことである。このような給付補償契約の例には、保険契約または債務保護商品が含まれるが、これに限られるものではない。

本発明において、「保険契約」は、会社または相互保険会社が、補償すべき事象の発生によって生じる経済損失に対して、個人またはグループに個別保護を提供する、契約上の合意のことである。この事象には、死亡、身体障害、病気または傷害、火災、不動産または個人資産への損失が含まれるが、これらに限られるものではない。したがって保険は、短期または長期身体障害保険、健康保険、重病保険、歯科保険、定期生命保険、終身生命保険、貯蓄型生命保険または変額生命保険、年金、火災保険、住宅所有者保険、竜巻または台風保険、洪水保険、自動車保険、海上保険、その他形態の財産または災害保険を含むが、これらに限られるものではない。

本発明において、「債務保護商品」は、借手と金融機関の間において、借手に与信を与え、これによる代償として、金融機関が与信取引の上で要求された月極元金支払または利息支払を延期することに同意し、あるいはさらに、借手が、死亡、身体障害、または失業のような生活事象に遭遇し、債務に対して支払義務を履行することが困難になった場合において、元金支払義務の全部または一部を免除する、契約上の同意のことである。

本出願において、「金融機関」は、商業的、非営利、政府機関その他の、顧客に商品／サービス小売取引のための必要な資金を提供し、顧客が取引のために現金を支払う必要がなくなるようにする、事業体のことである。このような金融機関の例には、銀行、貯蓄貸付機関、信用組合、小売商人の与信機関が含まれるが、これに限られるものではない。

本出願において用いられるとき、「身体障害」は、個人が、病気または傷害により、通常業務における物質的および実体的な責務を果たす際に制約を受け、その病気または傷害によって当該個人の月収について最小所定割合の損失を引き起こすことをいう。

本発明において、「引受人」は、保険会社、金融機関、またはサードパーティー管理者の内部において、様々な種類の給付補償契約についての保険料率と、各契約について保険会社または金融機関が想定すべきリスクの量と程度を定めるべき者である。

本出願において用いられるとき、「受給者」は、給付補償契約において、当該契約の下で支払いまたは他の給付を受け取るよう指名された者である。受給者は、個人の保険契約者または契約所有者であって、例えば生命保険、補完身体障害保険、住宅所有者保険、または自動車保険の形態で、保険または債務保護補償を契約する者、または個人のグループであって、例えば身体傷害保険、健康保険、歯科保険、または生命保険の形態で、雇用者保険契約者のグループ保険契約補償によって補償されるグループをいう。

本発明において、「請求者」は、保険会社が保険または債務保護商品の請求を支払い、または金融機関が貸付期間を修正するよう請求する者をいう。多くの場合、請求者は当該給付補償契約における受給者である。

図１は、本発明に係る自動請求処理システム１０を示す。顧客コミュニケーションセンター１２は、保険会社または金融機関１４によって、請求受給者１６と、保険契約の下で当該請求者が送信した請求について連絡を取り合うために運営される。顧客コミュニケーションセンター１２は、請求者１６と連絡を取り合うためのインターフェース１８を有し、このインターフェース１８は、電話、ＦＡＸ、またはメールによって連絡を取ることができる請求窓口であってもよい。これに代えて、インターフェース１８は、受給者がインターネットＷｅｂサイトまたはＩＶＲ応答システムを介して自ら請求を発し、または成り行きを見届けることができるようにすることができる。誰が最初に請求を発するかによらず、請求処理システム１０は同様に動作する。

図２の実施形態例を参照すると、自動請求処理システム１０は、中央処理装置（ＣＰＵ）２４を有する汎用プログラム可能コンピュータ２２を備え、ＣＰＵ２４は、メモリ部２６、記憶部２８、入力／出力（Ｉ／Ｏ）制御部３０、および少なくとも１つのモニタ３２を制御する。コンピュータ２２は、データベース４０に動作可能に接続され、データベース４０は、例えば給付補償契約のレコード、請求者データ、請求データを格納する。コンピュータ２２はまた、リスク評価ツール３６と自動損失検証ツール３８に動作可能に接続されている。これらについては後により詳しく説明する。コンピュータ２２はまた、クロック回路、データインターフェース、ネットワークコントローラ、内部バスを備えていてもよい。当業者は、例えばプリンタ、ドライブ、キーボード、マウス、などの他の周辺機器をプログラム可能コンピュータ２２とともに用いることができることを理解するであろう。さらに当業者は、プログラム可能コンピュータ２２が、記憶部と、自動請求処理システム１０内のデータおよび他の情報の操作を最適化するために、様々なコンピュータ要素のハードウェア、ソフトウェア、その他の周知な構成を利用できることを理解するであろう。

ソフトウェアプログラム３４は、コード化された言語の命令セットをまとめた表現として設計することができる。これら命令は、請求情報を取り込み、請求に関連するリスクを評価し、詐欺または誤謬に対して請求を検証することを促進するようにプログラムされている。

システムが配置されるコンピュータシステムは、通常ＰＣ、ラップトップ、メインフレーム、携帯無線機器、その他移植可能な構成要素の進行を監視するソフトウェアを実行することができる任意の自動データ処理機器であってもよい。ＣＰＵはコンピュータシステムを制御し、メモリ内に格納されているシステムを実行することができる。メモリは、例えばＲＡＭおよび／またはＲＯＭのような内部メモリ、ＣＤ−ＲＯＭ、ＤＶＤ、フラッシュドライブ、その他現存しまたは将来のデータ記憶手段のような外部メモリを含む。クロック回路は、現在時刻および／または日付を示す情報を生成することができるに似の回路を含むことができる。クロック回路はまた、所定のまたは設定された時間の量をカウントするようプログラムすることができる。

データインターフェースは、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）、その他任意種類の、請求を処理する各関係者を接続する１以上のネットワーク間の通信を可能にする。例えばラップトップと無線機器のような異なるコンピュータシステムは、典型的には異なるプロトコル（すなわち異なる言語）を用いる。異種機器が通信できるようにするため、データインターフェースは、データ変換プログラムまたは機器を備え、またはこれと通信し、データを交換する。データインターフェースはまた、異種機器が公衆交換電話網（ＰＳＴＮ）、インターネット、およびプライベートまたは準プライベートネットワークを介して通信することを可能にする。図２を参照すると、自動請求処理システム１０は、複数のグラフィックユーザインターフェース（ＧＵＩ）を有するソフトウェアプログラム３４を備え、ＧＵＩは、テキストまたは画像の形態でユーザに表示され、給付補償契約保有者に関するデータ、給付補償契約の損失事象、および請求に内在する他の事実を入力できるようにする。ＧＵＩはまた、保険会社または金融機関社員のみならず、請求顧客に対しても、請求の状態を表示するために用いることができる。

ソフトウェアプログラム３４はまた、この情報を文書化する一連のレポートを生成し印刷することができる。最後に、ソフトウェアプログラム３４は、保険会社または金融機関の請求に関する決定を、請求者に通知する。

図３〜図４は、本発明に係る自動請求処理システム１０をより詳細に示す。「発信フェーズ」５０において、請求者１６は、自動請求処理システム１０の運用者が保守する外部Ｗｅｂサイト５２またはＩＶＲ電話入力サイト５４を介する通信を経由して、または運用者の電話請求窓口コールセンター５６を介して、新たな請求を発し、または既存の請求の状態をチェックすることができる。インターフェース１８において、システム１０は、請求者１６に、新たな請求の発行／有効化、継続給付の要求、または既存の請求のチェック／有効化の中から選択するように促す。

システム１０は次に、給付補償契約について請求者１６からキーデータを要求する処理を開始する。この請求者を識別するキーデータは、請求者の姓と郵便番号、給付補償契約の口座番号、請求者の生年月日、有効化／請求番号のうち１以上を含む。これらデータ要素は、システム１０が、商品種別（すなわち、保険契約または債務保護契約）、商品、請求者、またはこれらの組合せに基づいて、事前に選択することができる。データが不完全であると、請求者はシステム１０の処理を進めることができない。

請求者１６からのこの入力データに基づいて、請求処理システム１０は、入力された情報と合致する、保険会社または金融機関の情報を有しているか否かを判定する。データは、セキュリティのため、保険会社または金融機関が保守しているレコード情報と正確に一致する必要がある。システム１０は、追加のセキュリティ安全対策として、請求者１６に、保険契約または債務保護家契約レコードのパスワードをメンテナンスするよう促す。

システム１０は、「権利付与フェーズ」６０に進む。本フェーズの間、システム１０は、給付システム６４に提供された、請求者が入力したデータ６２を取得し、これをシステムデータベースに格納されている登録データ６６および登録ルール６８と自動的に比較し、送信された損失事象について受給者を補償する、適用可能な保険契約または債務保護契約が、損失の請求日より前に存在するか否かを判定する。この権利付与フェーズ６０の間、追加データ要素が請求者から収集され、「セットアップフェーズ」７０を初期化する。請求者１６が、請求／有効化番号を入力することによって、保険契約の下で継続給付を受け取る権利をチェックすることができるのは、この権利付与フェーズ６０の間である。システムは、保険契約の条項を記述する、格納済みの権利付与ルール６８に基づいて、回答を提供する。

次に、自動請求処理システム１０は、「セットアップフェーズ」７０の間、給付補償契約および請求基盤を形成する損失事象を記述した関連情報を定義する請求レコードを生成する。このレコードは、後続の「リスク評価フェーズ」８０および「自動損失検証フェーズ」９０の間に、システムによって評価され、後述するように自動的に請求が判定される。

新たな請求について、補償が見つからない場合、システム１０は、請求者１６が入力した情報を再確認し、改めて送信することを要求する。２回目の試行が失敗した後、請求者は、保険または契約と補償の種類についていくつかの質問を受ける。入力された情報に基づき、システムが用いるインターフェース１８の媒体に依拠して（ｗｅｂ、ＩＶＲ、電話、など）、応答は以下のようになる。

・Ｗｅｂ：システムは請求者に、請求についてさらに支援を得るための、請求無料問合せ番号を提供する。この無料電話番号は、ＩＶＲを飛び越え、十分な知識のある請求担当者に直接つながる。
・ＩＶＲ：システムは請求者を、十分な知識のある請求担当者へ転送する。
・電話：請求担当者は、追加情報を要求して、請求者の補償を確認するよう試みる。
・郵送／ＦＡＸ：請求担当者は、請求者の補償を確認するよう試みる。確認できない場合は、請求者にレターおよび追加指示とともに記入フォームが返送される。

補償が見つかった場合は、システムは請求者に損失発生日を要求し、損失発生日を補償する全てのオプションを表示する。請求者は、損失種別を選択し、セットアップフェーズ７０に移動する。

システムが、損失種別と損失発生日に合致する複数の補償レコードを見つけた場合、請求者はいずれの給付について請求を有効化／送信するかを選択するよう促される。請求者が選択すると、権利付与フェーズ６０は終了し、セットアップフェーズ７０が開始する。このセットアップフェーズにおいて、請求／有効化レコードを成立させるために必要な全ての情報が、システムによって収集され、検証される。

複数の補償レコードが見つかったが、いずれも損失発生日および／または損失種別に合致しない場合、請求者は自分が所有している補償について、要約され、顧客が理解し易い文言と条件を用いた通知を受ける。

補償が見つかったが、待機期間または他の要件のため請求者が給付を受けるのに適していない場合は、請求者はその事実について通知を受け、入力した情報を保存するよう促される。情報を保存するためには、請求者は電子メールまたは居住場所のアドレスを入力しなければならない。システムは、情報を保存し、（権利付与フェーズの間に入力された情報に基づいて）待機期間の要求が満たされた時点で、請求者に電子メール／レターを送る。請求者は、要件が満たされると、入力した情報にアクセスすることができるようになる発信番号を与えられる。

この情報は、要件が満たされた後、システム１０内で９０日間保守されるべきである。９０日後に請求者が請求センター１２にコンタクトを取っていない場合、請求者に最終通知が送られ、１２０日目で当該情報は削除される。

請求者が既存の請求／有効化番号を入力すると、システム１０は請求の状態を表示する。請求者は、情報を検証し、本発明に係る自動請求処理システムの「リスク評価」フェーズ８０に進む。

セットアップフェーズ７０の間、請求有効化レコードを成立させるために要求される全ての情報が、リスク評価フェーズ８０、「自動損失検証」フェーズ９０、および「判定」フェーズ１００に進む前に、システム１０によって収集され、検証される。請求者は、権利付与フェーズ６０の間に入力された、例えば請求者／保険業者の名前、住所、電話番号、電子メールアドレス、選択された損失種別、損失発生日のような情報を検証する。このフェーズの間、請求者は、発行した請求に対する支払いに関する判定結果をシステムが送信する通信種別を選択するよう促される。デフォルトは電子メールであるが、他のオプションには郵便と口頭連絡が含まれる。

この通信種別の選択がＩＶＲリンクを介してなされた場合、システムは選択のログを保持し、これを顧客レコードに添付する。この選択が請求担当者と電話している間になされた場合、請求担当者は許可を録音する。録音された許可には、これが将来取得されるときのため、請求者レコードに添付される確認番号を与えられる。

通信種別「口頭のみ」は、請求者が口頭通知を受け入れ、電話発信の結果としてのｗｅｂまたは紙による通信を受け入れない、ということである。このオプションは、請求者が電話を介して請求担当者と連絡を取っている場合に限り表示される。このオプションが選択されると、請求者は請求担当者に、「文書による」確認を送信しないことを許可していることになる。この通信種別が選択された場合、例えばＷｅｂ／ＩＶＲのような、電話でない取引のための追加種別が要求される。

請求者は、セットアップ確認ボタンをクリックすることによってセットアップされた請求を確定する。このときシステム１０は、請求を初期化することに関する制約を表示する。例えば以下のようなものが含まれる。

・クレジットカード利用制約（請求者は、有効化の間、クレジットカードを使うことができない）
・有効化の間の待機期間（請求が承認されると、請求者は現在の請求の日付を経て最後の支払いから３０日後まで、新たな請求を発することができない）

請求者は、開始したくない補償レコードの選択を解除する機会を与えられる。システム１０は、選択されたレコードおよび選択されていないレコードの取引の下で、レコードを保持する。

請求者は請求を確定し、システム１０は、請求者に「選択した補償レコードについての請求レコードをセットアップしてもよろしいですか？」と尋ねるポップアップ画面を提供する。請求者が「いいえ」を選択した場合、手続きは終了し、取引レコードが蓄積される。請求者が「はい」を選択した場合、請求者はセキュリティレベルをセットアップする機会を与えられる。

請求者のセットアップに基づき（全ての請求者がこのオプションを選択するわけではない）、請求者はセキュリティ質問／パスワードをセットアップする機会を与えられる。このパスワードは蓄積され、この請求者アカウントについての情報を入手する全ての人に要求される。

図４に示す請求処理システム１０は、内在するプロセスのリスク評価フェーズ８０を実施するリスク評価プロセスモジュール８２を備える。リスク評価プロセスモジュール８２に関連付けられているのは、給付補償請求が詐欺または誤った申し立てである相対的リスクを予測するためのモデル８４である。システムデータベースに格納されているビジネスルールのセット８４は、システム１０がモデル８２を用いてリスク評価プロセスモジュールを起動するために用いる。リスクスコアテーブル８６もリスク評価プロセス８２に関連付けられており、リスクスコアテーブル８６は、モデル８２のリスク予測出力に対する応答において、数字によるリスク評価スコアを給付補償契約請求に割り当てる。監査ログ８８は、問題になっている請求に類似する以前の給付補償契約請求の現実リスク結果についてのデータを蓄積する。この情報を用いて、システム１０の運用者は、予測モデル８２を改修し、できる限り正確にすることができる。

リスク評価フェーズ８０において、発信フェーズ、権利付与フェーズ、およびセットアップフェーズの間に入力された情報は、請求が詐欺である相対的リスクを評価し、リスクスコアを割り当てるため、口座残高、顧客与信スコア、年齢、などの他の情報と組み合わされる。請求処理システム１０のリスク評価フェーズ８０は、保険会社が請求に関連する相対的リスクを評価することができるようにするため、高度なモデル化技術に基づくツールを利用する。

統計的モデリングは、特定請求に関連するリスクを評価するための自動リスク評価ツール（ＲＡＴ）３６（図３参照）を開発するため、全ての被保険者のデータ属性を利用する。結果として得られるモデル（図４内）は、請求を評価し、関連する見込みリスクをモデル化するため、変数の中の可能性のある傾向を全て考慮する。

保険請求に関連する異なるリスク要因の例を、下記表１に示す。

ＲＡＴ３６モデルは、期間ベースに基づいて（例えば日毎、週毎、月毎）全被保険者を事前にスコア化する。各被保険者は、複数の事前スコアを、商品／補償レベルで有する。事前スコアは、システム１０が保守するｏｒａｃｌｅデータウェアハウス内に蓄積されている。

特定の保険請求が到着すると、発信フェーズ５０、権利付与フェーズ６０、およびセットアップフェーズ７０の間に入力された情報は、各個人請求をリアルタイムで再スコア化するため、事前スコア化プロセス内で用いられる情報と組み合わされる。これに対して、継続給付に対する要求は、継続請求のみのために調整された異なるＲＡＴモジュールを経由することに留意されたい。

これを行なう際に、請求者はリスクプロファイルによって最高ランクから最低ランクまでにランク付けされる。これら請求者は、リスクカテゴリによってグループ化することができる。このカテゴリを用いて、保険業者と貸手は、判定プロセスの一部として特定請求に検証ステップを適用すべき程度を判定することができる。いずれのソースを用いるかの決定もまたモデル駆動型であり、各データソースについての確実性レベルは、様々な統計モデル技術を用いて判定される。例えば、先に説明した死亡請求の説明においては、２つの請求は、請求に関する高リスクまたは低リスクを受け取る場合がある。８０歳の被保険者が関連する死亡例では、モデルはリスクが低いものとしてプロファイルする。１００，０００ドル請求の例では、モデルは請求を高リスクに分類する。これらカテゴリに応じて、保険会社は、低レベルの確実性を提供する検証技術を用いるプロセス内で、低リスク請求に対して手早く承認決定することができる。さらに、保険会社は、高レベルの確実性を提供する、損失検証のためのさらなる情報を受け取った後に初めて、高リスク請求を承認することを選択できる。例えば、１番目のケースでは、保険会社は承認のための死亡証明として、死亡告示を受け入れることができる。２番目のケースでは、保険会社は承認のための請求証明として、地方自治体からの死亡証明書を要求することができる。

ＲＡＴ３６は、システム１０に内在するコンピュータ２２、または請求検証を手動で実施する給付補償契約会社従業員が利用することができる、検索テーブルを備えていることが望ましい。このような検索テーブルは、表２の形態を採用することができる。表２において、ある請求の相対的リスクレベルは、その請求に関連するリスクのレベルが与えられると、保険会社または金融機関が請求を承認するために要求される確実性（すなわち証明）の概略レベルに変換される。

したがって、スコア「４」は、取引が高リスクであり、支払いまたは延期が許可される前に、完全文書の形態で、１００％の確実性レベルを提供するものと判定されたデータソースを介して、または総合的に１００％の確実性レベルを提供する組合せデータソースによる検証を必要とする旨を判定する。これに対して、低スコア「１」は、より少ない文書要件を生じさせることができる。非常に低いスコア「０」は、承認のためにデータソースを介して検証することを要求しないよう促す。

本発明に係る自動請求処理システム１０の妥当性にとって、ＲＡＴツール３６および関連するモデル８２に内在する高度な予測モデルを、請求者が発した請求の妥当性についての実際の結果に対して定期的にチェックすることは、重要である。したがって、データソースは、請求を発した請求者のランダム提供サンプル８９によって制御され、監視され、検証される。提供サンプル８９は、ｎ番目毎に顧客を選択することによってランダムに生成される。提供サンプル８９は、ＲＡＴツール３６によってスコア化され、１以上の自動損失検証（ＡＬＶ）データソースによって検証される。システム１０が動作している最大の確実性が望まれる場合は、全ての入手可能なデータソースによって検証されることが望ましい。システムは、各データソース検証の結果を、請求者が提供した損失評価の結果と比較し、ＡＬＶシステムモジュールが適切に動作しているかを判定する。例えばこれまで損失評価を提供したことのない顧客（自己却下）のような傾向は、データソースに変更を加える（例：確実性レベルを調整する）必要があるかを判定するため、解析され、追跡調査される。

保険会社または金融機関が、非常に低リスク（例えばリスクレベル「０」）な請求について検証を要求しないことはあり得る。表面上は妥当であるように思われ、あるいは問題になっている請求の量が検証プロセスのコストを保証するには小さすぎるからである。このような場合、請求処理システム１０は、請求者に対する支払いの肯定的決定を通知するため、この請求を判定フェーズ１００（図３参照）へ直接送信するように構成される。

ＲＡＴモデルとテーブル駆動値のパラメータは、管理コンソール内で保守される。この管理コンソールによって、データ要素のスコア化、係数、データソース、確実性レベルを変更／調整することができる。仮説のテストを、管理コンソールを用いて制御された環境内で実施することができる。その管理レベルで、理論をテストすることが許容される。ユーザがテストに基づいて判定を下すため、一般的なビジネス用語でレポートが作成される。

リスク評価フェーズ８０の下で、０％超の要求確実性レベルの量を検索テーブルが決定付けた場合、システムは自動損失検証フェーズ９０へ進む。自動損失検証または「ＡＬＶ」は、損失種別に依拠して様々なデータソースに接続される、テーブル駆動ツール３８である。ＡＬＶツールの仕事は、リスクスコアと、商品、商品種別、顧客、および／または状態（あるいはこれら任意の組合せ）に基づいて確実性レベル要件を割り当てることにより、検証プロセスを自動化することである。次に、当該請求について特定された確実性レベル要件に基づいて、別の検索テーブルは、リスクスコアに基づき請求を検証するために要求される、独立データソースまたは独立データソースの組合せを特定する。表３は、その検索テーブルを示す。

これに代えて、ソフトウェア３４内に格納されているアルゴリズムまたは基本ロジックは、システムが用いるデータソースの順番を決定付けることができる。これら特定された独立データソースそれぞれは、次に請求損失を検証するため、システム１０によって自動的に調査される。

表４は、請求を検証するために入手可能な独立サードパーティーソースの例示リスト、および各ソースに起因する相対的確実性レベルを示す。

ＡＬＶテーブル、アルゴリズム、または基本ロジック駆動ツール３８は、損失種別に依拠して様々なデータソースに接続される。ＡＬＶツールの仕事は、リスクスコアと、保険商品、商品種別、顧客、および／または状態、あるいはこれら任意の組合せに基づいて、請求に確実性レベル要件を割り当てることにより、検証プロセスを自動化することである。ＡＬＶツールは、異なるデータソースから情報を取得し、各データソースから取得した情報に基づいて、ポイント／確実性レベルを蓄積することができる。請求の確実性レベル要件に基づいて、確実性レベルを達成するのに必要な各データソースは、自動的に損失を検証するため問い合わせを受ける。データソースの中には、入手できる検証種別に応じて異なる確実性レベルを有するものもある。例えば、ＳＳＤＩの場合において、Ｐの死亡確認は１００％の確実性レベルを獲得し、Ｖの死亡確認は５０％のスコアのみを獲得するかもしれない。各データソースは、１または多数の損失種別に結びついており、ＡＬＶレベルのセットアップに基づき、商品種別、商品、顧客、状態、損失種別、および／またはこれらの組合せに依拠する異なる確実性レベルを有する場合がある。

本発明に係る自動損失検証ツールの好ましい実施形態において、システムは、当該請求に割り当てられたリスクスコアに対応する特定の給付補償契約請求を検証するため、要求される目標確実性レベル（ＴＣＬ）を割り当てる。リスクスコアが、請求経験や引受契約に基づいて保険契約または債務保護契約を許可した保険会社または金融機関によって設定され得るように、保険会社または金融機関は、許容し得るリスク志向に基づいて、自らの要求ＴＣＬを選択できることに留意されたい。ある保険会社または金融機関は、詐欺またはさもなくば不正確な請求である可能性がある請求について、より高いリスクレベルを受け入れ、したがって、自動損失検証ツールの下で請求を検証するため、より低いＴＣＬを要求するかもしれない。このより低いＴＣＬ値によれば、本発明に係る自動損失検証ツールを利用することにより、請求検証プロセスに関連する管理コストを削減することができる。これに対して、他の保険会社または金融機関は、許容されるリスクが小レベルであることに起因して、請求を検証するためのより高いＴＣＬ値を要求するかもしれない。これは、自動損失検証ツールを用いて請求を検証するために用いられる補完的データソースへの参照の組合せがより多くなることになる。

各補完データソースは、請求の信憑性を成立させるための相対的確実性レベルに比例する、寄与的検証スコアを割り当てる。例えば、生命保険契約者の死亡に関して顧客が提供した情報は、４０％のみの確実性レベルで特徴付けられるかもしれない。一方、新聞の死亡記事は、６０％の確実性レベルを提供するかもしれない。新聞は、独立ソースであり、論理的に、請求者自身よりも信憑性が高いと言い得る。しかし、新聞記者はミスを犯すことが分かっている。一方で、社会保障死亡記録内の死亡者リストは、給付支払を開始する前に死亡を検証するため社会保障庁に採用されている文書検証プロセスに起因して、８０％の確実性レベルを有し得る。最後に、地方行政府によって発行された死亡証明は、死亡事実について１００％の確実性レベルを成立させる。

保険会社または金融機関は、自らの請求検証体験およびリスク容認プロファイルに基づいて各補完データソースに割り当てた、自らの確実性スコアを判定できることに留意されたい。

本発明に係るシステムは、請求を検証するため入手可能な補完データソースを利用する目的で、以下の繰り返し計算を実施する。

継続請求についてのＡＬＶプロセスは、対応する商品／顧客の暫定期間を超過した場合のみ開始される。対応する給付期間がまだ有効であれば、ＡＬＶプロセスは利用するべきではない。これに代えて、請求処理は判定フェーズに直接進むべきである。給付補償契約の下での損失証明が、請求者によって提供された場合、ＡＬＶプロセスも同様に省略される。最後に、請求は、ＡＬＶプロセスを開始する前に権利付与フェーズを通過しなければならない。

複数の特定ルールが、ＡＬＶプロセスの管理のため適用される。１番目に、補完データソース、あるいは外部ソースデータベースは、ＴＣＬが達成可能で、かつ対応する事業分野（商品／顧客要素）についての検証ソースとして割り当てられている場合に限り、アクセスされる。補完データソースは、ＡＬＶシステムの運用者が保守する内部データベースであってもよい。したがって、ＭＶＶ≧ＴＣＬである。

２番目に、補完データソースは、日付に関する検証ソースとして示される場合を除き、または以前のデータベース検索試行が合致を得られなかった場合、請求の判定の間、一度のみ用いられる。

３番目に、請求に合致する検索結果として得られた各補完データソースの確実性スコアは、ＡＶＶに追加される。これにより、ＡＶＶスコアは、当該請求についての現在の蓄積された検証スコアを表すことになる。

４番目に、各補完データソース検索の後、ＡＶＶスコアは、ＴＣＬスコアが当該請求について達成されたか否かを判定するため、当該請求の要求ＴＣＬ値と比較される。ＴＣＬスコアが達成されていれば、ＡＬＶプロセスは終了し、請求処理システム１０は当該請求の判定フェーズ１００に進む。当該請求についてＴＣＬスコアがまだ達成されていなければ、ＡＬＶプロセスは、残存する未チェックの補完データソースのＰＶＶによって当該請求のＲＶＶ値（ＴＣＬ−ＡＶＶ）が達成可能な場合に限り、当該請求について入手可能な残存する補完データソースの調査を続ける。これら残存する未チェック補完データソースのＰＶＶ値が当該請求のＲＶＶスコアを超過していない場合は、ＡＬＶプロセスは終了し、請求処理システム１０は、判定フェーズ１００に到達する前に、請求の「顧客が提供する損失検証」に進むべきである。

実施形態１
図５は、本発明に係るＡＬＶ処理ツールを生命保険契約請求に適用した例を示す。生命保険契約請求１５０について、ＡＬＶプロセスは２つの補完データソースを事前に割り当てている。連邦社会保障庁が管理する社会保障死亡記録（ＳＳＤＩ）１５２、および死亡索引１５４である。

ＡＬＶプロセスツールのルールエンジンは、生命保険契約を発行した保険会社によって事前に作成されたＴＣＬ変換テーブル１５６を有している。このテーブルは、給付請求の主題になっている種別の生命保険契約について、値が１であるリスク評価スコア（ＲＡＳ）１５８は、被請求損失を検証するため３０％のＴＣＬスコア１５９が要求されることを示す。一方、値が２であるＲＡＳは、４０％のＴＣＬスコアを要求する。ＲＡＳ値３、４、５はそれぞれ、例示するＡＬＶプロセスの下、要求ＴＣＬスコア７５％、８５％、１００％に対応する。

ルールエンジンに基づき、ＡＬＶプロセスは最初に、オンラインでアクセス可能なＳＤＤＩを調査する。死亡者の社会保障番号と、請求者が提供する死亡日およびＳＳＤＩレコードとの間に合致するものがあれば、事前に割り当てられた確実性値５０が、このデータ合致の結果としてＡＶＶスコアに加えられる。したがって、自動請求検証処理のＡＶＶ＝５０％となる。この場合、ＡＶＶ≧ＴＣＬであるので、１または２のＲＡＳスコアとその結果であるＴＣＬ要件３０％または４０％を有する請求は、妥当であることが確認できる。このような請求は、判定フェーズに移動する。

しかし、３、４、５のＲＡＳスコアとこれに対応するＴＣＬスコア７５％、８５％、１００％をそれぞれ有する請求については、ＡＬＶプロセスに進まなければならない。この場合、ＳＳＤＩを参照したときのＳＳＤＩ返信コードが調査される。返信コードが「Ｐ」値を有する場合、これは死亡者の死亡証明が死亡証明書の形態で既に社会保障庁に提供されていることを意味し、事前に割り当てられた追加の確実性値５０％がＡＶＶスコアに加えられて、ＡＶＶ＝１００％となる。この場合、ＲＡＳ値３、４、５を有する全ての請求は、妥当であることが確認される。これに対して、死亡者の死亡が死亡証明書なしに社会保障庁へ電話で告げられたのみであれば、ＳＳＤＩ返信コードは「Ｖ」となり、この場合、事前に割り当てられた追加の確実性値２５％がＡＶＶスコアに加えられ、ＡＶＶ＝７５％となる。この事象において、ＲＡＳ値が３である請求は妥当であることが確認できるが、ＲＡＳ値が４または５である請求については、追加の証明が要求される。

ＳＳＤＩレコードが、請求者が報告した死亡者の社会保障番号と合致したが、死亡日が合致しない場合、ＡＬＶプロセスは、ＳＳＤＩ死亡日と請求内で報告された死亡日の間の差異の判定へ進む。差異が２日間以内であれば、当該請求のＡＶＶは４０％となる。この場合、ＲＡＳスコア１または２を有する請求は妥当であることが確認できるが、ＲＡＳスコア３、４、５を有する請求は妥当であることが確認できない。一方、報告された死亡日と請求者された死亡日の間の差異が７日間未満であれば、ＳＳＤＩを参照して得られるＡＶＶ値は３０％のみであり、ＲＡＳ値が１である請求のみが、妥当であることが確認できる。

ＳＳＤＩレコードによって妥当性を確認することができなかった請求については、ＡＬＶプロセスは死亡記録データベース１５４の調査に進む。当該請求内の情報と比較して、当該死亡者について合致する、同名、同死亡日、同地区、同市の死亡レコードが見つかった場合、追加の５０％が当該請求についてのＡＶＶスコアに加えられる。未検証請求についてのＲＶＶがＳＳＤＩレコード使用後に≦５０％である場合は、その請求は合致する死亡記録データベースによって検証される。

実施形態２
図６は、本発明に係るＡＬＶプロセスを非自発的失業保険（ＩＵＩ）請求に適用した例を示す。ルールエンジンは、ＴＡＬＸ ＴＰＡ 職業検証データベース１７２を、ＩＵＩ請求を検証するための補完データソースとして事前に割り当てる。このデータベースは、失業請求を発した全ての顧客によってアクセスされる。全ての雇用者がこのデータベースの対象であるわけではないので、ＡＬＶプロセスは最初に、雇用者の名称についてＴＡＬＸ ＴＰＡ 職業検証をチェックする。合致するものが見つかっても当該請求についてのＡＶＶの確実性レベルには寄与しないが、その代わりにＡＬＶプロセスを進めることができる。

次に、ＡＬＶプロセスは、当該失業者の氏名、社会保障番号、解雇日について、ＴＡＬＸ ＴＰＡ データベースをチェックする。データベースレコード内のこの情報が、請求者が提供した情報と合致する場合、ＡＬＶプロセスは当該請求についてのＡＶＶスコアに１００％の確実性値を与える。この場合、当該請求は、ＡＶＶ≧ＴＣＬスコア１７８となるので、ＲＡＳスコア１７６によらず検証される。

ＴＡＬＸ ＴＰＡ データベース内で報告される解雇日が、請求者が提供した解雇日と合致しない場合は、これら日付間の差異がＡＬＶプロセスの下で計算されなければならない。この差異が７日間を超過しない場合は、７５％の確実性値がＡＶＶに与えられる。このＡＶＶスコアは、ＲＡＳスコアが１、２、３である全てのＩＵＩ請求の妥当性を確認することができる。これに対し、リスクスコアが４、５であるＩＵＩ請求は、追加の補完データソース証明を要求する。この補完データソース証明は、地方行政府の失業証明１８０、または以前の雇用者１８２から直接提供された検証情報の形態であってもよい。差異が７日間を超過するが３０日間未満である場合は、４０％の確実性値のみが当該請求のＡＶＶスコアに与えられる。

実施形態３
図７は、本発明に係るＡＬＶプロセスを身体傷害保険請求に適用した例を示す。身体障害保険請求１９０は、所定のＲＡＳスコア１９４および関連するＴＣＬ値１９６を有する検索テーブル１９２に関連付いている。様々な補完データソース１９８が、ＡＬＶプロセスの下で身体傷害保険請求を検証する目的のため、保険会社によって提供される。

例えば、医療機関リストデータベース２００は、患者にサービスを提供する医師および他の医療サービス提供者についてアクセスされる。医療サービス提供者の名前と電話番号が、請求者が提供する情報と合致すれば、３０％の確実性レベルが当該請求についてのＡＶＶスコアに与えられる。この場合、ＲＡＳスコアの値が１である請求は妥当であることが確認されるが、一方でＲＡＳスコアが２〜５である請求は、その信憑性について追加の補完ソース証明が要求される。

ＩＣＤ９診断／専門データベース２０２は、医療サービス専門分野および当該専門分野に関連する典型的な診断のリストを有する。身体障害保険請求によって提供された診断と医療機関リストデータベース２００によって既に検証された医療サービス提供者の専門分野が合致すると、確実性値２０％が与えられ、ＡＶＶ＝５０％となる。これにより、ＲＡＳスコアが２である身体障害保険が妥当であることを確認することができる。

ＡＬＶプロセスは、薬剤適応データベース２０４の照会に進む。このデータベースは、薬剤名とそれが典型的に処方される医療診断のリストを有する。薬剤適応データベース内で、薬剤処方と、請求者が提供した医療診断情報とが合致する場合、２０％の確実性値が当該請求についてのＡＶＶスコアに加えられる。この場合、結果として得られる７０％のＡＶＶスコアはＲＡＳスコア３〜５の請求の妥当性を確認できない。

保険会社が医療レコードを検証するためのＨＩＰＡＡの下における請求者の承認（２０６）があると、この特定補完データソースによって追加の５％の確実性値が提供される。当該請求についてのＡＶＶは７５％となる。これは、ＲＡＳスコアが３である身体障害保険請求の正当性を立証するが、ＲＡＳスコア４〜５の請求については立証しない。

ＩＣＤ９データベース２０８は、対応する診断に割り当てられたＩＣＤ９コードのリストを有する。このデータベースが請求内で提供されたＩＣＤ９コードと合致すれば、２５％の確実性レベルが当該請求についてのＡＣＣスコアに与えられる。この場合、結果として得られる１００％のＡＶＶスコアは、ＲＡＳスコア４〜５の全ての請求の妥当性を立証することができる。しかし、医療機関リストデータベース２００において合致する医療サービス専門家の名前が見つからなかった場合は、ＩＣＤ９専門分野データベース２０２はいずれの確実性ポイントも与えることができない。この場合、薬剤適応データベース２０４、ＨＩＰＡＡ認証許可２０６、およびＩＣＤ９データベースを用いて合致するものが見つかれば、総ＡＶＶ値は５０％となり、ＲＡＳ１〜２の請求のみが妥当性を立証される。

処方履歴データベース２１０は、特定患者に処方された薬剤のリストを有する。処方履歴データベース２１０内の社会保障番号、損失発生日、および氏名のレコードが請求内の情報に合致し、処方名が請求内で識別される処方と合致すれば、この特定補完データソースを用いると、２５％の確実性値が初期身体障害保険契約請求に与えられ、継続請求に１００％の確実性値が与えられる。これは、当該請求について要求されるＴＣＬスコアを上回るのに十分なＡＶＶスコアを生成する。

したがって、ＲＶＶとＰＶＶの計算値は、各補完データソースがＡＬＶ検証プロセス３８内で用いられた後、請求について再帰的に再計算される。このプロセスは、当該請求について要求されるＴＣＬ値が請求の妥当性を立証するまでに達したか、または請求者から要求された追加データが識別された場合においてＡＬＶプロセスが他の補完データソースを照会し続ける必要があるか否か、について判定する。

サードパーティーデータソースのコストはシステム１０の経済性に影響を与えるので、請求意思決定プロセスに必要な確実性レベルを提供する最もコスト効率のよいソースまたはソースの組合せを利用することが重要である。本発明に係る自動損失検証ツール９０は、最低確実性レベルから最高確実性レベルまで連続して各独立データソースを調査する。したがって、顧客が提供した損失情報が、要求される確実性レベルを満たすため請求を補完する場合、システムは判定フェーズ１００に準じて決定点に進む。要求される確実性レベルが満たされていない場合、システムは、当該請求についてＡＶＶ≧ＴＣＬになるまで、連続する補完データソースの検索を進める。請求のリスクに依拠して、システムは、２以上の独立データソースの組合せによってのみ満たされる非常に高い確実性レベルを設定することもできる。

要求される確実性レベルが達成されると、ＡＬＶフェーズ９０は完了し、請求／有効化は判定フェーズ１００に移動する。確実性レベルが達成されない場合は、ＡＬＶフェーズ９０は完了し、要求される確実性レベルと達成される確実性レベルが記録され、請求／有効化は顧客が提供する損失証明プロセスに移動する。

したがって、当該分野で用いられている、保険会社と金融機関が事象の妥当性を立証するために要求される情報を提供するタスクを顧客に課す従来の請求処理システムとは異なり、本発明に係るシステム１０は、多くの場合においてこの負荷から請求者を救う。例えば、従来のアプローチの下では、死亡請求を発する受給者は、請求承認前に保険会社に死亡証明書を提供するよう求められる。身体障害請求を発する被保険者は、身体障害と働くことができない旨を立証する医師のサインフォームを提供するよう要求される。この証明を提供するステップは、顧客に時間と金銭の双方のコストを課す。さらに、保険会社の資源に、情報要求を文書化し、要求を追跡調査し、受け取った情報を処理し、将来の参照のため情報を保持するコストを課す。また、給付を顧客に対して履行するのに必要なサイクルの時間を増やす。

請求者に損失証明を求めることは、本発明の下では、標準的ではなく、望ましくない検証手法である。リスク／確実性レベルが満たされていないことに起因して、または顧客／商品／状態に起因して、自動損失検証にふさわしくない請求／有効化は、この要件の契機になる。

請求者は、一定の情報を全て入力し、および／または要求された文書を添付するよう促される（ｗｅｂ）。例えば、診断内容明細書（ＡＰＳ）が要求される。診断内容証明書または他のフォームが要求される場合、顧客は当該文書を印刷し、または印刷された文書を郵送するよう要求し（ｗｅｂ経由）、または郵送された文書がバーコードで、適切な請求レコードに関連付けるよう促される。

添付された文書（ｗｅｂのみ）は、審査者の審査および判定のため、適切な審査者の作業キューに送信される。請求者は、文書が審査のため転送された旨、および通知が５〜１０営業日以内（表示される日数は顧客の設定に依拠する）に届く（電子メールまたは郵送を介して）旨を知らされる。この時点で請求者は、選択した通信方法を思い出し、提供した情報を更新または変更する機会を与えられる。このフェーズで請求者は、請求／有効化が承認される（または顧客の設定に基づく任意の手続き要件）まで支払いを続けることを思い出す。文書が添付されていない場合、請求者は、商品、顧客、状態など、通信を促すテーブルエントリに基づき、電子メール／郵送による保留文書の通知を定期的に受け取る。

いくつかの場合において、請求者が口頭で検証することは、請求する損失事象の妥当性を立証する目的のための十分な補完データソースとして作用することに留意されたい。これは主に、詐欺もしくは誤謬請求の相対的リスク、または請求者が提供する事実記述が、コストおよび顧客がＡＬＶプロセスと本発明のシステムを含む環境下でさらに問い合わせを行う関連負担に鑑みて妥当でない、非常に低リスクの事象において発生する。

本発明に係るＡＬＶシステムの先行記述は、「２ステップ」プロセスに焦点を当てている。（１）ＲＡＴを用いて、請求された損失に対してリスク評価スコアを割り当て、請求された損失の妥当性を検証するために達成されなければならないＴＣＬ値を選択する。（２）請求された損失を検証するためシステムが検索するＴＣＬスコアの達成に対して所定の確実性スコアを与える、１以上の補完データソースを繰り返し選択する。本発明の好ましい実施形態において、「１ステップ」のＡＬＶシステムモデルは、分析論を用いて生成される。この実施形態において、請求者、請求された損失事象、および入手可能な補完データソースを特徴付ける全てのデータは、選択された検証ソースを用いた請求承認と関連付けられた確実性レベルを表す単一の総合的スコアを提供する統計技術を用いてモデルを生成するため、結合される。このシステムは、請求の組合せと、システム内で成立する最小閾値を提供する補完データソースを見つけるために動作する。データソースに関連するコストは、ＡＬＶプロセスを動作させるコストを最適化するため、モデル内で考慮されるべきである。

自動または顧客が提供する損失情報による検証プロセスに準じて、受け取った検証結果、および判定フェーズ１００（および状態例外）などの下における商品、顧客、状態、またはこれらの任意の組合せによって成立したルールに基づき、決定が下される。この判定フェーズでは、給付期間（適用可能であれば）および支払い量が決定され、請求者に開示される。

継続給付については、自動化された給付期間モデルは、請求承認がいったん許可されると、請求給付の承認の期間を判定するルールを保持する。複数の要因が、このルールによって解決され、このルールには、医療診断、雇用種別、住所が含まれる（例えば、失業事象、自然災害）。このようにして、請求された給付期間は、より汎用的な万能サイズルールに代えて、請求者の特定の損失条件に関連付けられる。

請求／有効化が承認されると、請求者は承認に関連する全ての情報を閲覧する。例えば、支払いまたは延期の量、または量が分からなければ、月毎のもしくは単なる「あなたの所有物の置き換えが承認されました」という宣告文である。表示される詳細は、ルールエンジン内のテーブルエントリによって定められる。

顧客／商品の設定に依拠して、システムの自動化されたモデルは、以下を判定する。

・どこで／どのようにして、要求された情報を取得するか（自動データ取得ｖｓ．請求書要求）
・適切な支払い計算方法
・適用可能な支払利息
・追加給付（すなわち、生命保険契約に基づく追加の事故死給付）
・請求種別が関連する期間モデルを有しているか

請求書データは、顧客の設定に基づき、支払い量を決定するため自動的に取得される。いくつかの手法が可能である。顧客のデータへの接続；巡回手法を利用して顧客から請求センターへデータを供給する；など。システムはまた、要求により、請求書データを保険会社から探す。請求書情報が自動的に入手できない場合は、給付／支払い量を判定するための準自動化されたプロセス、および推奨度の低い手動プロセスも存在する。ユーザは、将来の通知について知らされ、準自動化または手動プロセスが開始する。

保険会社と金融機関は、請求書情報について給付／支払い量を判定するよう要求されている請求／有効化を表示するｗｅｂツールにログインする。保険会社または金融機関は、必要な情報を入力し、要求されたデータを請求者コミュニケーションセンター１２へ送信する。システムは、自動的に給付／支払い量を判定し、請求者に通知する。

請求者（ｗｅｂ）は、請求書のコピーを添付することを選択するかもしれない。請求者がＩＶＲを介して請求／有効化を発している場合は、ｗｅｂを介して、要求された文書を郵送または電子メールするよう通知される。

あまり好ましくはないが、システムの運用者は、請求者から直接、請求書添付を求めてもよい。請求書添付は、給付／支払い量を判定するため、適切な審査者作業キューに送信される。給付／支払い量の通知は、好ましくは２営業日またはＡＬＶシステム内の顧客設定によって定められる数日以内に（電子メールまたは郵送により）送信される。

顧客が提供する損失検証プロセスが必要であるとき、審査者は、段階的な文書審査プロセスを用いる。システムは、顧客、給付構造、などの観点から、各保険商品についての許容可能な文書要件を特定する。審査者が文書を審査するにつれ、システムは審査者に質問し、または順番にプロセスを実施させる。

例えば、事故死請求において、死亡証明書（ＣＤＣ）が必要である。システムは、審査者に以下を促す。

・ＣＤＣを持っているか？
・死亡原因は事故によるものか？
・損失発生日は？
・第１カード保有者についてのものか？

審査者が応答を入力／選択すると、意思決定プロセスは終了する。

各決定は、請求者が選択した通信方法（ｗｅｂ、電子メール、ＩＶＲ、レター、請求関連スクリプト）を介して請求者に通知される用語に関連付けられている。追加文書の要求は全ての要求される文書をリストし、拒否リストは全ての拒否理由をリストし、承認リストは支払日、方法、および次に何を期待すべきかの詳細を提供する。全ての用語を保持しているこのモジュールは、テーブル駆動であり、ユーザによって保守される。このモジュールにより、保険会社または金融機関は、商品／請求者／給付／状態などによって、用語をセットアップすることができる。審査者は、請求者に発する前に（プロセスがＡＩＺによって駆動されている場合）、用語を閲覧し、承認または修正することができる。

このフェーズにおいて、支払いがなされるべきであれば、請求者は支払い方法を選択する（チェック、ＡＣＨなど）。支払い方法は、テーブルに蓄積され、顧客／商品の設定に基づいて表示される。ユーザが支払い方法を選択すると、システムは、例えば支払いが到達する予想日などを、選択された方法および顧客／商品の設定に基づいて通知する。

支払い選択がなされると、請求者は情報を保存し（ＡＩＺ／ｗｅｂユーザ）、または印刷する（ｗｅｂ）よう促される。請求者は、請求／有効化番号を思い出し、８００＃を提供される（またはインターネットユーザについてはｗｅｂアドレス）。この時点において、セッションは終了する。

請求／有効化が拒否されると、商品、顧客、状態など、ルールに基づいて、拒否理由が表示される。請求者は、拒否された場合、条項または条件を閲覧し、または選択したアドレスへコピーを郵送／電子メール送信するオプションを有する。この段階で、請求無料問い合わせ番号を提供することもできる（ｗｅｂ）。拒否レコードは、請求者通知のレコードとともに保守される。請求者は、書面の通知を受け取るか否かを選択することができる。この時点において、セッションは終了する。全ての決定スクリプトは、テーブル駆動である。請求者が見聞きすることは、顧客／商品／状態の設定に依拠する。

したがって、本発明に係る自動請求処理システム１０に基づいて、請求者が詳細な請求フォームに漏れなく記入し、補償すべき事象を証明するための補完文書を入手して提供する負担を負うことなしに、請求は素早く効率的に審査される。このような、サードパーティーまたは所有者から入手できる証拠文書を取得することによって、保険会社または金融機関は、許容可能なリスクレベルに合致する請求を判定しつつ、管理コストを節約し、審査と判定の期間を１ヶ月以上から短期間にまで削減することができる。本発明の目的において、「短期間」は、２日間、好ましくは２時間、さらに好ましくは、請求者が保険会社または金融機関の顧客サービス担当者と電話で話している間、またはｗｅｂサイトもしくはＩＶＲポータル請求有効化システムに接続している間にリアルタイムで、ということを意味する。さらに、請求者は、顧客サービスの１例として、簡略化された請求処理システムを必ず歓迎するであろう。

図８〜図１０は、請求処理システム１０のＡＬＶプロセス部３８のアーキテクチャを示す。給付補償契約請求が、発信フェーズ５０、権利付与フェーズ６０、セットアップフェーズ７０、リスク評価フェーズ８０に進むと、ＡＬＶシステム３８の開始点２３０に到達する。ステップ１において、システムは顧客のＡＬＶフラグの状態をチェックする（ステップ２３２）。データベース２３４は、会社が複数顧客の請求を処理するシステムを運用する場合において、本発明に係るシステムの請求処理システム１０と自動検証システム３８がサービスを提供する、保険会社および金融機関の全ての顧客のリストを格納する。顧客のフラグが「ｏｎ」にセットされているとき、ＡＬＶシステムはステップ２のＡＬＶ構成ステップ２３４に進む。ＡＬＶフラグがセットされていなければ、システムは監査ログデータベースを更新してこの事実を反映し（ステップ２３８）、給付補償契約請求の、顧客が提供した損失検証に進む。データベース２４０は、各顧客のＡＬＶシステム３８の特定構成を格納する。このデータは、ＡＬＶシステムが請求された損失を検証するために用いられるべきか否か、ＡＬＶシステムがカバーすべき請求パラメータ、ＡＬＶシステムをどの程度頻繁にテストするか、ＡＬＶシステムに内在するルールまたはアルゴリズムモデル、請求のリスク評価スコア、請求について要求されるＴＣＬ値、請求された損失事象を補完するための許容可能な独立データソース、および各データソースに対応する相対的確実性レベルを含む。構成が見つからない場合、監査ログ２４４は、この事実を反映するためシステムによって更新され、システムは、当該請求についての顧客が提供した損失検証に進む。

ステップ３のＡＬＶプロセス審査ステップ２４２は、各顧客、あるいは当該顧客の特定商品について必要なデータを格納するデータベース２４６によって採用される。基本的に顧客は、各保険または債務保護契約種別または給付種別についてルールセットを個別調整し、より多くの作業および時間を要する、顧客が提供する損失検証プロセスに代えて、請求検証プロセスの一部として請求を自動検証するため、ＡＬＶシステム３８を有効化するか否かを定めることができる。特定種別の商品、請求、または給付は、請求検証をＡＬＶプロセスに委譲すると顧客に対して格別高いリスクを与える場合がある。データベース２４６内に格納されているルールが、ＡＬＶプロセスを用いるべきでない旨を示唆する場合は、この事実を反映するため監査ログ２４８が更新され、システムは、顧客が提供する損失検証プロセスに進む。

ルールが、請求の妥当性を評価し検証するためＡＬＶプロセスを用いるべきである旨を示唆する場合、システムは、構成種別が、ＲＡＳ値が既に計算されシステム内に格納されているモデル種別であるか否かの判定（ステップ２５０）へ進む。構成種別がそのモデル種別である場合、システムはステップ４のリスク評価判定２５２へ進む。この給付補償契約についてのリスク評価スコア（ＲＡＳ）は、データベース２５４内に格納される。ステップ４において、システムは、請求の上記のようなＲＡＳとともに、提供サンプルの指標をデータベース２５４内で検索する（ステップ２５２）。一方、構成種別がルール駆動である場合、システムはデータベース２５８内に格納されているルールを実行し（ステップ２５６）、当該請求についてのＲＡＳをリアルタイムで計算する。このＲＡＳ計算は、保険会社または金融機関の顧客のプロファイルの許容可能な特定リスクに対して調整されており、したがって同種の請求について顧客間で大きく可変することに留意されたい。当該請求についてＲＡＳを計算するため必要なルールが入手できる場合、システムはノード２５８に進む。上記のようなルールが入手できない場合は、請求を検証するためにシステムがＡＬＶプロセスを動作させるＲＡＳを計算することができない。代わりに、監査ログ２６０が当該請求についての未知のＲＡＳを反映するため更新され、システムは、顧客が提供する損失検証プロセスに進む。

当該請求について所定のＲＡＳがデータベース２５４内で見つかった場合、システムはＲＡＳを修正するビジネスルールが存在するか否かを判定する。顧客の標準ＲＡＳの修正により、郵便番号検証が必要でない災害地域のような特定状況に適合することができる。このプロセスは、データベース２６４内に格納されているルールとデータを利用する。以下に説明する、提供サンプル分析からの学習を利用して、モデルは以前の請求体験から「学習」し、当該請求が詐欺または誤謬をもたらす真のリスクをできる限り正確に特徴付けるために必要な、当該請求についての所定のＲＡＳを調整することができる。システムは、修正されたＲＡＳを用いて、ＡＬＶプロセスのノード２５８に進む。

ノード２５８においてＲＡＳを見つけ、修正し、または計算した後、システムは、ＲＡＳに関連付けられたＴＣＬがステップ２６６で取得される、ステップ６に進む。このＴＣＬは、典型的には「検索テーブル」を介して、データベース２６８内に格納される。上述の通り、このＴＣＬスコア、または「総合確実性レベル」スコアは、ＡＬＶプロセスを介して請求を検証するための補完文書または口頭独立データソースの集合体と合致することによって満たされなければならない、特定の認容閾値を判定する。より高いＲＡＳ値は、詐欺または誤謬について請求者が保険会社または金融機関に対して与えるより高レベルのリスクを反映するため、より高いＴＣＬスコアを要求する。これに対し、より低リスクの請求は、より低いＴＣＬスコアを要求する。これにより、より少ない補完データソースとの合致に基づいて、ＡＬＶプロセスを介して請求を検証することができる。当該請求についてシステムがＴＣＬを見つけられなかった場合、監査ログ２７０がこの事実を反映するため更新され、システムは、当該請求についての顧客が提供する損失検証プロセスに進む。

ステップ６において、当該請求についてシステムがＴＣＬスコアを見つけた場合、システムは、必要であればデータベース２７２内に格納されているルールを適用し、ＴＣＬスコアを修正する（ステップ２７４）。ここでも、ＡＬＶプロセスのこの特徴により、当該請求が詐欺または誤謬であることによってもたらされる真の相対的リスクをできる限り正確に特徴付けるため、以前の請求体験に基づいて、ＴＣＬスコアを修正することができる。したがって、本発明に係るＡＬＶシステム３８により、多数の保険会社の保険契約または金融機関の債務保護契約について、ＲＡＳスコアとＴＣＬスコアを事前計算および蓄積し、システムが蓄積されたルールを利用してＲＡＳスコアおよびＴＣＬスコアをリアルタイムで正確性のために修正することができるという事実に対する信頼の下で、保険契約または債務保護契約の下における請求の自動請求処理を加速することができる。

ＡＬＶプロセスのステップ８において、システムは自動損失評価プロセス２７６を開始する。このプロセスは、データベース２７８内に格納されているデータに適用され、このデータには、様々な補完データソース、請求検証のための特定補完データソースの割当、各補完データソースについて事前に割り当てられた確実性レベルスコア、必要な検索データ要素、補完データソースを当該請求について顧客が送信した情報と比較するためのルール、登録時および以前の請求レコードに格納されている情報が含まれる。請求が「継続」請求である場合（例えば、以前に検証された身体障害給付請求であって、請求者が保険契約の下でさらなる期間の給付を請求したもの）、システムは、請求を検証するため以前に利用され、現在は複数ヒットデータソースではない、補完データソースを除外する。

ステップ９において、ＡＬＶシステム３８は、当該請求についてＲＶＶを計算し（２８０）、このＲＶＶは上述の通り、集合ＴＣＬ値から差し引かれる、当該請求についてのＡＶＶを表す。このＲＶＶスコアは、補完データソース取得の最初の繰り返しおよび請求セットアップ情報に対するマッチングの前に、当該請求のＴＣＬ値と等しく初期設定されていることに留意されたい。

システム３８は、当該請求についてのＭＶＶ値がステップ２８２で計算されるステップ１０に進む。このステップは、当該請求の検証のため事前に割り当てられた特定の補完データソースについて、データベース２８４内に格納されている情報を利用する。上述の通り、全ての補完データソースについての確実性レベルは、ＭＶＶまたは「最大検証値」を生成するため、結合される。当該請求の検証のため要求されるＴＣＬスコアがこのＭＶＶ値を超過している場合、この事実が更新された監査ログ２８６内に反映され、システムは、当該請求についての顧客が提供する損失検証プロセスに進む。事前に割り当てられた全ての補完データソースが当該請求内に含まれる情報と合致しても、ＴＣＬ要件を満たす集約確実性値を生成することができないので、当該請求の検証のため入手できるようになった追加の補完データソースが存在しない下で、ＡＬＶシステム３８の当該請求への適用に進む点が存在しない。

当該請求の検証のため入手可能な、組み合わされた補完データソースについてのＭＶＶ値が、ステップ１１において、当該請求の検証のため要求されるＴＣＬスコアを超過していると判定された場合、システム３８は、ステップ１２に進む。ステップ１２において、システムは、まだ当該請求の検証のため取得されておらず、当該繰り返しにおいて請求された損失を検証するため入手可能な、当該請求についての全ての補完データソースのＰＶＶ値を計算する（２８８）。補完データソースを取得する毎に、当該請求に対して事前に割り当てられた、残存している補完データソースについての組合せＰＶＶ値は、必然的に減少することに留意されたい。

データベース２９０は、事前に割り当てられた必要な補完データソース、その補完データソースの確実性レベル、およびＰＶＶを計算するためのルールを有する。データベース２９０はまた、現在の経過状態においてＰＶＶ計算から省くことができるようにするため既に取得され、適用された補完データソースをトラッキングしている。

ステップ１２において、システムは、ＡＬＶＳプロセスについて「実行中見込み検証値」（ＲＰＶＶ）集計値を計算する。

ＲＰＶＶ＝ＲＰＶＶ＋ＰＶＶ

このＲＰＶＶ集計値は、現在の検証繰り返し（ＰＶＶ）についての補完データソースからの確実性ポイント値と組み合わされた、以前の検証繰り返し（ＲＰＶＶ）からの補完データソースについての全ての確実性ポイント値を、トラッキングする。

ステップ１３において、システム３８は、ＰＶＶ＞０であるか否かを判定する。ＰＶＶ値が０を超過しないのは、全ての事前に割り当てられた補完データソースが、請求を検証するためシステムによって取得され、適用された場合、またはデータソースが入手できない場合に限られる。この場合、要求されたＴＣＬ値を満たすため、現在入手できる補完データソースを用いて当該請求を検証することはできないので、システムは以後のＡＬＶプロセスの適用を中断し、ノード２９２に進む。

一方、ＰＶＶ＞０である場合、システム３８はステップ１４に進み、要因の数に基づき、いずれの補完データソースをデータベース２９０から取得（２９４）すべきかを判定する。１番目に、データベース２９０内に格納されているルールは、当該請求を検証するための補完データソースのサブセットに事前に割り当てられる必要がある、特定の補完データソースを選択するための基本的ロジックを定義する。２番目に、各データソースは、関連付けられたコストを有する。補完データソースの提供者のなかには、システムがそのデータソースの利用を要求する毎に、料金を請求するものもある。この料金が大きい場合もある。他の場合において、保険会社または金融機関は、独自のデータソースを生成することもあり、データソース開発コストを取り戻しサードパーティーデータソースの料金増加を回避するため、請求を検証する際にそのデータソースを優先的に使用する。

３番目に、全てのデータソースが、請求の検証への寄与因子に同じ請求情報合致成功率を提供しているわけではない。ヒット率を考慮して、データソースへアクセスするコストがその価値を超えない限り、より高い「ヒット率」を有するデータソースが優先されるべきである。

４番目に、当該請求を検証するため満たす必要があるＲＶＶ値（すなわち、ＡＶＶ−ＴＣＬ）は、入手可能な１つまたは複数のデータソースの取得および適用を介して、達成できる場合がある。多数の安価な独立データソースに代えて、所望の検証結果を達成するため少数のデータソースを利用することは、より理にかなっている。したがって、データソース選択ステップ２９４のルールは、本発明にかかるＡＬＶプロセスの現在の状態に対して柔軟に反応する。

ＡＬＶプロセスのステップ１５において、特定のデータソースが取得され、当該請求内で提供された情報に適用される（ステップ２９６）。データベース２９８内に格納されているデータソースルールとデータルール要素は、このプロセスの動作を促進する。データソースは、内部データソース３００と、外部のサードパーティーが提供したデータソース３０２の双方に由来している。関連するデータソースについての検証ルールが請求情報に合致しない場合、当該請求についてのＡＶＶスコアに確実性レベルポイントは与えられない。一方、データソースが請求情報と合致する場合は、請求が補完され、ステップ１６において、事前に割り当てられた確実性レベルポイントが、当該請求についての実行中のＡＶＶ集計値に加えられる。

ステップ１７において、当該請求についてのＲＶＶスコアは、更新されたＡＶＶ集計値を、当該請求を検証するために要求されるＴＣＬ値から差し引くことによって、再計算される（ステップ３０６）。この時点において、更新されたＡＶＶスコアとＲＶＶスコアは、当該請求と合致した補完データソースの識別子と併せて、データベース３１０に格納されている情報とともに、監査ログ３０８に加えられる。

次に、ＡＬＶプロセスはステップ１９に進み、ステップ１９において、更新されたＡＶＶスコアは当該請求についてのＴＣＬスコアと比較される（ステップ３１２）。ＡＶＶ≧ＴＣＬであれば、要求されたＴＣＬ閾値はＡＬＶプロセスによって満たされており、この情報が監査ログ３１４内に記録される。妥当性が検証された請求は、ＡＬＶシステムによって判定フェーズ１００に送信される（図３参照）。

しかし、当該請求についてＡＶＶ＜ＴＣＬである場合、当該請求の妥当性はまだ検証されていない。ステップ２０において、システムは、ステップ１４のルールと基本ロジック（ステップ２９４）に基づき、追加の補完データソースを取得し当該請求に適用することができるか否かを判定する（ステップ３１６）。補完データソースがそれ以上入手できない場合、ＡＬＶプロセスと実装システムは、ノード２９２に進む。

図１０に戻って、補完データソース３００、３０２をそれ以上入手できない請求は、ステップ２１へ進む。このＡＬＶプロセスにおいて、システムは、ＲＶＶ＞ＭＶＶ−ＲＰＶＶであるか否かを判定する（ステップ３２０）。当該条件を満たす場合、システムは監査ログ３２２を更新して、要求されたＴＣＬスコアが達成できない旨の事実を反映する。システムは、未検証の請求とともにポータルへ戻る。

一方、ＲＶＶ＝ＭＶＶ−ＲＰＶＶである場合、システムはステップ２２へ進み、いずれの補完データソースが、データベース３２５に格納されている基本ロジックまたは優先度に基づき合致するかを判定する（ステップ３２４）。これら追加の補完データ要素は、ステップ２３に続いて請求者から要求されなければならない（ステップ３２８）。要求フェーズはデータベース３３０によって提供され、監査ログ３３２が更新される。１以上の補完データソースが質問に対する請求者の回答に続いて入手可能になる場合、要求されるＴＣＬスコアが達成されるので、システムはポータルに戻り、この追加情報を顧客から要求する（ステップ３３４）。顧客から入手する新たなデータ（ステップ３３８）は、２番目の段階３４０（図９参照）において、ＰＶＶ計算ステップ２８８（ステップ１２）から開始する請求検証のための再帰的照会プロセスを再度開始するため、システムによって利用される。

実施形態４
図８〜図１０に記載されている、ＡＬＶＳプロセスの例を、以下に記載する。

・請求検証のために要求されるＴＣＬ：７０％
・ＭＶＶ＝９０％
・補完データソース：
○ＳＳＮデータベース＝２０％
○死亡日データベース＝３０％
○公開死亡記録データベース＝３０％
○口頭確認＝１０％
・１番目の繰り返し：
○ＳＳＮと死亡日データソースのみが入手可能。
○ＲＶＶ＝ＴＣＬ＝９０％（ステップ９）。
○ＭＶＶ＝９０％（ステップ１０）
○ＴＣＬ≦ＭＶＶなので、プロセスを進める（ステップ１１）。
○ＰＶＶ＝２０％＋３０％＝５０％（ステップ１２）
○ＲＰＶＶ＝ＲＰＶＶ＋ＰＶＶ（ステップ１２）
ＲＰＶＶ＝０％＋５０％
ＲＰＶＶ＝５０％
○ＰＶＶ＞０なので、プロセスを進める（ステップ１３）。
○システムは、ＳＮＮと死亡日ソースの双方について、検索ヒットを得る（ステップ１４〜１５）。
○ＡＶＶ＝２０％＋３０％＝５０％（ステップ１６）
○ＲＶＶ＝ＴＣＬ−ＡＶＶ（ステップ１７）
ＲＶＶ＝７０％−５０％＝２０％
○ＡＶＶ≦ＴＣＬなので、２番目の繰り返しに進む（ステップ１９）。
○新たな死亡記録データソースが入手可能となる（ステップ２０）。
○ＲＶＶ＞ＭＶＶ−ＲＰＶＶ？（ステップ２１）
２０％≦９０％−５０％
２０％≦４０％なので、プロセスを進める。
・２番目の繰り返し：
○死亡記録データベースは、確実性ポイント３０に値する。
○ＰＶＶ＝３０％（ステップ１２）
○ＲＰＶＶ＝ＲＰＶＶ＋ＰＶＶ（ステップ１２）
ＲＰＶＶ＝５０％＋３０％
ＲＰＶＶ＝８０％
○ＰＶＶ＝３０％＞０なので、プロセスを進める（ステップ１３）。
○システムは、合致するものを得られない（ステップ１４〜１５）。
○まだ、ＡＶＶ＝５０％である（ステップ１６）
○ＲＶＶ＝ＴＣＬ−ＡＶＶ（ステップ１７）
ＲＶＶ＝７０％−５０％
ＲＶＶ＝２０％
○ＡＶＶ≦ＴＣＬなので、３番目の繰り返しに進む（ステップ１９）。
・３番目の繰り返し：
○新たな口頭データソースが入手可能である（ステップ２０）。
○ＲＶＶ＞ＭＶＶ−ＲＰＶＶ？（ステップ２１）
２０％＞９０％−８０％
２０％＜１０％であり、１０−口頭データソースポイントが残存するＴＣＬギャップを満たすのに不十分であるので、ＡＬＶＳプロセスを終了する。

したがって、当該請求はＡＬＶＳプロセスによって妥当性を立証することができない。

本発明に係るＡＬＶプロセスとシステム３８の重要な要素は、様々な請求についてＲＡＳを定義するためのプロセスである。図１１に示すように、リスク評価プロセス（ＲＡＰ）３６は定期的な日付ベースまたは時間ベースで自動的に実行される（ステップ３５２）。このＲＡＳは、いくつかのデータベースからのデータ入力を利用して、プログラムされたコンピュータサーバ実行プロセス（ステップ３５４）を介して計算される。ＣＤＳデータベース３５６は、未確定の保険契約と債務保護契約についての登録データを格納するとともに、それら保険または契約の下における未確定の請求のレコードと、請求に対して支払いを履行しなければならない保険会社または金融機関のリスクを弱めるためにその保険と契約の下で支払われる保険料金のレコードを格納している。ＣＭＳデータベース３５８は、全ての登録ステージング、未確定請求活動ステージング、および保険料金ステージングについてのデータを有する。最後に、データベース３６０は、グループベースで、例えば湯便番号またはブロックグループの観点で、保険および契約保有者識別データを格納している。

ＡＬＶプロセスの運用者は、リスク評価ツール３６４の手動実行を実施するよう選択する（ステップ３６２）こともできることに留意されたい。運用者の意思決定科学市場アナリスト３６６は、未確定請求についてのＲＡＳが正確性のため更新される必要があると考える場合に、これを実施する。

リスク評価ツール３６をコンピュータサーバ上で実行すると、様々な保険および契約についての一連のＲＡＳが得られる（ステップ３７０）。このＴＳスコア化アプリケーションは、誤謬についてチェックされる。誤謬がない場合、科学チームはその旨を通知される（ステップ３７２）。ＲＡＰモデルに対する修正がなされ（ステップ３７４）、ステップ３５０に続いてモデルが再実行される。

ＲＡＴモデル内に誤謬が検出されなかった場合、意思決定科学チームは、更新したＲＡＳファイルをサーバに送信する（ステップ３７６）。データウェアハウス３７８は、ＲＡＳテーブルを更新するため、現在のＲＡＳを請求処理システム１０にエクスポートする（ステップ３８０）。システム１０は、周期的（例えば週毎）ＲＡＴ３６ファイルの実行が成功した旨を通知するため、適当な科学チームメンバーに電子メールを送信する。

図１２は、ＡＬＶシステム３８がリスク評価ツール３６を使用する詳細を示す。請求者は、給付補償契約の下でなされた請求を特徴付ける必要な情報を提供する（ステップ４００）。顧客は、この請求情報を要約する確認ページを検討し（ステップ４０２）、請求を送信する（ステップ４０４）。

ＡＬＶシステム３８は、当該請求者と、請求された損失種別について関連付けられたＲＡＳを取得するよう要求する（ステップ４０６）。請求者の氏名とＲＡＳが見つからなければ（ステップ４０８）、この事実を反映するため監査ログが更新される（ステップ４１０）。一方、システムが請求者氏名とＲＡＳを見つけると（ステップ４１２）、顧客（保険会社または金融機関）がＲＡＰスコアを修正する（ステップ４１８）ための特定ルールを成立させているか否かを判定するため（ステップ４１６）、関連するルールエンジンがチェックされる（ステップ４１４）。監査ログは、日付、時刻、請求者、保険または契約番号を識別するため、更新される（ステップ４２０）。元のＲＡＳと修正されたＲＡＳも記録される。

システムは、請求の判定の間にＡＬＶプロセスを回避すべきか否かを判定する（ステップ４２２）ため保険会社または金融機関が成立させたルールをチェックする。ＡＬＶプロセスを回避すべきである旨をルールが規定する場合（例えば、損失の性質により事故死請求について死亡証明書のような文書証明が要求される場合、または永久身体障害請求について社会保障身体障害の文書が要求される場合）、請求は、保険契約または債務保護契約の条項の下、判定ステップ４２４に直接進む。

一方、請求はＡＬＶプロセスに服すべきである旨をルールが規定する場合、当該請求についてのＲＡＳに基づき、ＡＬＶ検証ステップ４２６に進む。本発明の重要な側面において、複数の請求がランダムに「提供サンプル」として指定される（ステップ４２８）。これは、ＡＬＶプロセス３８によって検証され、本発明に基づき判定されることに加えて、請求結果は、将来において、実際に保険または契約の条項の下で正当であるか否か、または詐欺もしくは誤謬であるか否かに関し、追跡調査されることを意味する。提供サンプルの実際の結果を、ＲＡＴおよびＡＬＶ検証プロセスによって予測された結果と比較することにより、システム運用者は任意の不一致を識別することができる。このようにして、ＲＡＴおよびＡＬＶプロセスの予測正確性を向上させるために必要であれば、ＲＡＴおよびＡＬＶプロセスパラメータを修正することができる。

本発明の非常に重要な他の側面は、ＡＬＶシステム３８の管理コンソールである。管理コンソールは、ソフトウェアプログラムと関連するグラフィカルユーザインターフェース（ＧＵＩ）を備え、これにより、保険会社、金融機関、または他のシステム運用者は、ＡＬＶプロセス３８を動作させるためのパラメータをセットアップし、保守することができる。

図１３は、ＡＬＶシステム３８のログイン画面４５０を示す。ログイン画面４５０は、ＡＬＶ管理コンソールが存在するサーバに対してユーザが割り当てられた識別名を入力するユーザＩＤフィールド４５２を有する。ユーザはまた、セキュリティのため所定のパスワードをフィールド３５４に入力しなければならない。「ログイン」アイコン４５６をクリックした後、システムは、正確に合致した場合のみユーザにＡＬＶ管理コンソールへのアクセスを提供するため、ユーザＩＤと関連するパスワードの名簿をチェックする。ユーザがパスワードを忘れた場合は、「パスワードを忘れた」ハイパーリンク４５８をクリックすることができる。この場合、システム管理者は、コンピュータ技術において知られているように、代わりのパスワードを電子メールで送信する。

図１４は、本発明に係るＡＬＶ管理コンソールのホームページ４６０を示す。ホームページ上には、一連のアイコンが配置されている。ＲＡＳ／ＴＣＬ４６２、データソース４６４、データ要素４６６、顧客構成４６８、検索４７０、テスト４７２、レポート４７４である。これらアイコンの機能を以下に説明する。

ＲＡＳ／ＴＣＬアイコン４６２をクリックすることにより、図１５に示すようにＧＵＩ４８０が呼び出され、システム運用者は、特定の保険会社または金融機関について、リスク評価スコア（ＲＡＳ）の値を追加または削除し、総合確実性レベル（ＴＣＬ）値を追加または削除することができる。ＲＡＳ値は、小数点のない数値である。この数値は、−９９９〜９９９の間の値をとることができる。ＴＣＬ値は、０以上かつ９９９未満の小数点のない数値である。ＲＡＳおよびＴＣＬ値は、１以上のシステムデータベース内に格納される。

現在のＲＡＳ値は、フィールド４８２に表示されている。ラジオボタン４８４をクリックすることにより、「挿入」ハイパーリンク４８６をクリックして対応するＲＡＳ値を編集することができる。

現在のＴＣＬ値は、フィールド４８７に表示されている。ラジオボタン４８８をクリックすることにより、「挿入」ハイパーリンク４８９をクリックして対応するＴＣＬ値を編集することができる。

図１６に示すデータソースＧＵＩ４９０は、「データソース」アイコン４６４をクリックすることによりアクセスできる。この画面により、システム運用者は、請求検証のため用いられるＡＬＶシステム３８のため補完データソースをセットアップすることができる。このセッションにおける設定は、補完データソースに適用される。

フィールド４９２により、フィールド４９４に入力された正式名を用いてデータソースを識別することができる。データソースのコスト基準（例えば、無料、一律料金、ヒット毎）がフィールド４９６に入力される。データソースの使用による実際のコストは、フィールド４９８に入力される。複数ヒットフィールド５００は、「はい」「いいえ」エントリによって、損失事象を検証する目的のため特定データソースを複数回呼び出すことができるか否かを示す。例えば、図１６内で「はい」にチェックされている処方履歴データベースは、日付駆動データベースであり、したがって請求検証プロセスを通して更新済みの検証情報を複数回提供することができる。これに対して、専門医データベースは、当該請求に対して常時単一のデータポイントを提供する。したがってシステムは、請求検証プロセスの間に一度だけ、この専門医データベースを調査すべきである。

各補完データソースの「ヒット率」は、妥当なヒット総数をヒット総数で除算することによって計算される。この値はパーセントで表され、請求を検証するためのデータソースの有用度を特徴付け、フィールド５０２に入力される。ヒット率値は、システム運用者が手動入力することもできる。これに代えて、「計算」ラジオボタン５０４がチェックされた場合は、システムが自動的に計算することもできる。「オフィス」フィールド５０６と「地域」フィールド５０８は、特定の補完データソースが請求情報を検証する地理的能力を示す。「オフィス」は、顧客の活動国を示す。「地域」は、当該国内の州または行政区分を示す。データソースのデータエントリまたは改訂版の有効日は、フィールド５０９内でシステムによって認識される。

地球シンボル５１０をクリックすると、地域を選択する（全地域または選択した地域）ポップアップウインドウ５１２が開く。「データ要素」アイコン４６６をクリックすることにより、コンピュータＡＬＶＳシステム３８は、図１７に示すＧＵＩ５２０を呼び出す。この画面により、システム運用者は、全ての補完データソースについてのデータ要素を入力することができる。この画面における設定は、全ての顧客構成に適用される。

「フィールドソース」ドロップダウンボックス５２２または「検索フィールド」ドロップダウンボックス５２４により、補完データ要素をフィルタリングすることができる。この画面により、データ要素名をフィールド５２６内で修正し、データ要素がフィールド検索可能であるか否かをフィールド５２８内で確定することができる。データ要素名は、５０個超の文字を有することができない。データ要素の「検索フィールド」定義子は、データ検証のルールセットを介して使用されるか否か、および請求者が当該要素の情報を提供しなければならないか否かを示す。アプリケーションは、追加質問を判定するためにこのフィールドを用いる。

認証と同意は、データ要素であると考えられる。したがって、データソースがヒット前に認証を要する場合、その認証はデータ要素としてセットされる。

フィールド５３０は、各データソースについて検索可能な特定要素を定義する。社会保障死亡記録５３２については、これは死亡者の姓または名である。死亡記録データベースについては、これは死亡者の死亡日５３４である。データソースエントリの有効日は、フィールド５３６内でシステムによって識別される。

図１８は、アイコン４６８をクリックすることによってアクセスできるＡＬＶ顧客構成ＧＵＩ５４０を示す。このＡＬＶ顧客構成は、同一のオフィス（例えば、米国、カナダ、プエルトリコ）、事業分野（例えば、保険、債務保護）、商品群、顧客、および構成要素に分類される、全ての構成を収集する。ＡＬＶシステム３８は、給付請求を検証するためにいずれの補完データソースおよびルールを採用すべきかを判定するため、この構成を用いる。

ＧＵＩ画面５４０は、現存するＡＬＶシステム顧客構成を表示する。ＧＵＩ画面５４０により、「新たな構成を追加するにはここをクリックしてください」ハイパーリンク５４２をクリックして、新たな顧客構成を作成することができる。現存する顧客構成を編集することもできる。

顧客構成エントリは、容易に検索することができる。例えば、保険会社または金融機関の米国オフィスについての全ＡＬＶ構成を取得するためには、「米国」を「オフィス」フィールド５４４に入力し、「検索」ボタン５４６をクリックする。顧客Ａについての全ての構成を取得するためには、「顧客Ａ」を「顧客」フィールド５４８に入力し、検索ボタン５４６を有効化する。顧客構成についての他の検索可能フィールドには、「構成ＩＤ」フィールド５５０、「商品群」フィールド５５２、「事業分野」フィールド５４４、「構成要素」フィールド５５６が含まれる。特定の顧客構成についての関連する全てのフィールド情報は、要約ボックス５５８内に表示される。「リセット」ボタン５５９により、新たな検索を開始することができる。

図１９は、新たな顧客構成を作成するＧＵＩ５６０を示す。これは、ＧＵＩ５４０内でハイパーリンク５４２をクリックすることによりアクセスできる。ＡＬＶシステム３８は、フィールド５６２内に「構成ＩＤ」を割り当てる。これは、構成番号、文字、またはこれらの組合せによりなる。ドロップダウンボックスは、システム運用者に、オフィス（５６４）、顧客（５６８）、商品群（５７０）、および構成要素（５７２）についての関連識別情報を入力する便宜な手段を提供する。構成の状態（すなわち、有効、無効、テスト中）も、ドロップダウンボックス５７４に入力することができる。給付補償契約の種別（例えば、保険、債務保護）は、ドロップダウンボックス５７６に入力される。最後に、当該顧客構成に関するコメントは、システム運用者がフィールド５７８に容易に入力することができる。

「次へ」ボタン５８０をクリックすると、システム運用者に、ルールエンジン１０８から当該顧客構成に適用されるべきルールセットを選択するための、図２０に示すＧＵＩ５９０が提供される。これらは、ＡＬＶシステムが特定の顧客構成エントリの保険契約または債務保護契約について、事前に割り当てられたリスク評価スコア（ＲＡＳ）を修正するために適用する、リスク評価プロセス（ＲＡＰ）ルールである。この画面により、ＲＡＰルールビットを挿入し、更新し、削除することができる。ＲＡＰルールビットはフィールドに入力され、入力カラム５９４内のラジオボタン５９５をクリックすると、現存するＲＡＰルールエントリを編集することができる。「次に」ボタン５９６により、システム運用者は、図２１に示すＧＵＩ６００に進むことができる。「前に」ボタン５９８により、ＧＵＩ５６０を再訪問することができる。ＧＵＩ６００は、ＡＬＶシステム３８がＲＡＳをＡＬＶ目標確実性レベル（ＴＣＬ）に変換するために用いる変換テーブルを提供する。入手可能なＲＡＳ値が、ドロップダウンボックス６０４の支援によってＲＡＳフィールド６０２に入力される。次に、保険会社または金融機関が特定のＲＡＳスコアについて選択したＴＣＬ値は、ドロップダウンボックス６０８の支援によってフィールド６０６に入力される。ＲＡＳスコアが事前に割り当てられていない場合において、保険契約または債務保護契約についてＲＡＳスコアを計算するために選択されたルールセットは、ドロップダウンボックスの支援によってフィールド６１０に入力される。最後に、変換テーブル６１４の結果として得られるＴＣＬ値を修正するためのルールセットは、ドロップダウンボックス６１２に入力される。「次に」ボタンにより、システムは図２２に示すＧＵＩ６２０へ進む。

ＧＵＩ６２０により、補完データソースとそれぞれの確実性レベルを入力することができる。これらデータソースは、上述のように、ＡＬＶシステム３８が請求を検証するために用いられる。この画面を介して、データソースを挿入し、削除し、または更新することができる。データソースの識別子は、ドロップダウンボックスの支援によってフィールド６２２に入力される。ドロップダウンボックスは、当該種別の保険契約または債務保護契約について入手可能な関連する補完データソースのみを示す。例えば、生命に関するデータソース（例えば、社会保障死亡記録、死亡記録データベース）のみが、生命保険契約について表示される。システムはまた、当該データソースについてセットされたオフィスを考慮に入れる。

「優先度」フィールド６２４は、０〜９９の数値であり、データソースエントリを作成するためには要求されない。「状態」フィールド６２６は、有効、無効、テスト中の選択肢を提供するドロップダウンボックスである。

「確実性値」フィールド６２８は、保険会社または金融機関が各データソースに割り当てた相対的確実性レベルのリポジトリである。これは典型的には、０〜１００の間のパーセントである。各補完データソースは、関連するアクセスコストを有する。このコスト数値は、フィールド６３０に入力されるコスト種別（例えば、一律料金、ヒット毎、無料）とともに、フィールド６２８に入力される。「ヒット率」６３２は、デフォルト、要計算、要割当の３つのオプションを有するドロップダウンボックスである。「デフォルト」は、データソース画面に入力されたヒット率が用いられることを意味する。「要計算」は、システムが下記計算式にしたがって自動的に値を計算することを意味する。

ヒット率＝（当該構成についての妥当なヒット総数）／（当該構成についてのヒット総数）

「要割当」は、システム運用者が値を手動で入力することを意味する。

「複数ヒット」フィールド６３４により、はい、いいえ、デフォルトの選択肢を入力することができる。これは、システムが同一請求についてデータソースを複数回ヒットし得るか否かを判定する。「デフォルト」が選択された場合、データソース画面から取り込まれた情報が用いられる。

「次に」ボタン６３６をクリックすることにより、上述のように請求情報を検証するため様々なデータソースに適用するルールセットを特定するための、図２３に示すＧＵＩ６４０にアクセスすることができる。ＧＵＩ６４０により、確実性値およびルールセット内の各ルールの状態をセットすることができる。

現在の構成における各データソースについてのタブ６４２が存在する。各データソースは、少なくとも１つのルールセット６４４を有さなければならない。ルールセットは、ルールエンジン内で割り当てられたルールセットＩＤである。データソースの確実性値はフィールド６４６に入力され、関連するルールの状態（有効、無効、テスト中）はフィールド６４８に表示される。

あるデータソースについての全てのルールの確実性値の合計は、当該データソースに割り当てられた確実性値を超過してはならない。アプリケーションは、システム運用者が「完了」ボタン６４９をクリックしたとき、構成を保存する。情報を保存する前に、ソフトウェアアプリケーションは、同じ設定を有する２つの構成が存在しない旨を確認する。

図２４は、ＡＬＶシステム３８によって処理された請求を検索するためのＧＵＩ６５０を示す。この画面は、処理された請求のレポートとしては動作しない。「検索」アイコン４７０をクリックすることにより、この画面にアクセスできる。

ＧＵＩ６５０により、以下の要素の組合せをもって請求を検索することができる。

・オフィス（６５２）：オフィスのリストを有するドロップダウン。オプション「全て」も可能。
・事業分野（６５４）：選択されたオフィスに依拠する値を有するドロップダウン。オプション「全て」も可能。
・顧客（６５６）：顧客リストを有するドロップダウン。このリストは、選択されたオフィスと事業分野に依拠する。オプション「全て」も可能。
・商品群（６５８）：選択されたオフィス、事業分野、顧客に依拠する商品群。オプション「全て」も可能。
・構成要素（６６０）：選択されたオフィス、事業分野、顧客、商品群に依拠する構成要素。オプション「全て」も可能。
・給付番号（６６２）：給付番号を入力するテキストボックス。
・シーケンス（６６４）：給付番号に依拠するシーケンス番号を有するドロップダウン。
・ＲＡＳ（６６６）：見込みリスクスコアを有するドロップダウン。オプション「全て」も可能。
・ＴＣＬ（６６８）：見込みＴＣＬ値を有するドロップダウン。オプション「全て」も可能。
・データソース（６７０）：データソースのリストを有するドロップダウン。このリストは、選択された構成要素に基づきフィルターする。
・初回／継続（６７２）：「全て」「初回」「継続」の３つのオプションを有するドロップダウン。
・構成（６７４）：ＡＬＶ顧客構成ＩＤを入力するテキストボックス。
・提供サンプル（６７６）：「全て」「はい」「いいえ」の３つのオプションを有するドロップダウン。
・給付開始日（６７８）：日付を入力するテキストボックス。
・給付終了日（６８０）：日付を入力するテキストボックス。

検索は、選択された条件に合致するレコードを返す。以下のフィールドが表示される。

・給付番号
・シーケンス番号
・ＡＬＶが給付を検証した日付
・オフィス
・事業分野
・商品群
・構成要素
・顧客
・ＲＡＳ
・ＴＣＬ
・データソース
・提供サンプル
・状態

「検索」アイコン６８２をクリックすると、処理された請求エントリが引き出され、ボックス６８４内で要約される。「リセット」ボタン６８６により、他の検索を開始することができる。

図２５に示すＧＵＩ６９０は、選択された処理済みＡＬＶシステム検証の全ての詳細を示す。上部フィールド６９２内では、給付番号６９４、請求者氏名６９６、オフィス６９８、事業分野７００、商品群７０２、顧客７０４、構成要素７０６、損失発生日７０８、初回または継続給付状態７１０、ＡＬＶ顧客構成ＩＤ７１２、ＡＬＶ状態７１４、ＲＡＳスコア７１６、ＴＣＬスコア７１８、ＭＶＶ値７２０、および提供サンプル７２２が表示されている。この情報は、システムによってデータベースに引き出される。本画面はまた、テーブル７２４内において、ＡＬＶ検証プロセスを進めるべきであるか否かを判定するためＡＬＶシステム３８によって実行されたルールセットを表示する。

最後に、ＧＵＩ６９０は、テーブル７２６内において、請求を検証するため利用された全てのデータソースと、その結果として得られた、ＰＶＶ７２８、ＲＰＶＶ７３０、達成された値７３２、ＡＶＶ７３４、ＲＶＶ７３６、データソース優先度７３８、データソース状態７４０、および情報を検証するため用いられたルールセットを表示する。追加の情報が請求者から要求された場合、その事実はフィールド７４２に反映される。ＡＬＶ状態は、データソースの各繰り返し利用について、フィールド７４４内に表示される。

本発明に係る自動損失検証ツール３８の他の重要な特徴は、「制御テスト環境」モジュール８００である。図２６に示すように、制御テスト環境モジュール８００は、パラレルルールエンジン８０２、データベース８０４、およびＡＬＶ管理コンソールの「テスト」アイコン４７２によってアクセスされる（図１４参照）管理制御ＧＵＩ８０６のセットを備える。この制御テスト環境モジュールは、製品システムに組み込まれる前に、ＡＬＶ構成またはルールに対して提示された変更をテストするために用いられる。ルールエンジン１０８、関連するデータベース６２、６６、６８、８２、８４、８６、および製品システムの管理制御ＧＵＩ４５０は、既に上述した。補完データソース１１０、１１２は、製品システムと制御テスト環境システムの双方をサポートする。独自のルールエンジン８０２と関連するデータベース８０４を有することにより、テストデータを、請求見通し製品データベース８１０に格納されている過去の請求、または請求見通しテストデータベース８０８を介して手動入力された過去の請求のいずれからも得ることができる。

このようにして、システム運用者は、ＡＬＶシステムに対する重要な入力変数、例えば請求のＲＡＳ値、請求に要求されるＴＣＬ値、補完データソース（内部または外部の双方）に割り当てられた確実性ポイント値、新たな内部または外部の補完データソース、特定の請求された損失を検証するために割り当てられた補完データソースの組合せ、当該請求に割り当てられたその補完データソース組合せを照会する順序、などを修正して、制御されたテスト環境内で、ＡＬＶシステム３８の実行結果を判定することができる。システム運用者は、修正が実際に製品システムのルールエンジンおよびデータベースに組み込まれる前に、ＡＬＶシステムパラメータに対する提案された変更が、テストしている請求損失を正確に検証する給付結果を生成することを確実にしたい。したがって、この制御テスト環境モジュール８００により、必要に応じて、ＡＬＶシステム３８を検証し、保守し、調整し、システム３８を確実に最適化することができる。

さらなる実施形態
以下の３つの例は、保険会社が請求者から独立しているソースにより請求の妥当性を検証しようとする例を示す。

実施形態５
顧客は死亡請求を発し、その請求は低リスクであるとスコア付けされる。承認検証のための代替の最小限の許容可能な方法は、以下を含む。（ａ）公開されている死亡記録を審査する；（ｂ）その者が死亡した旨の政府機関からの確認を取得する；または（ｃ）死亡証明書を取得する。この例において、システムは自動的に、信頼できるオンラインニュースサービスで公開された購入済みの死亡記録データベースを検索し、受給者が提供した事実に合致する個人を探す。ｗｅｂは、公式のニュースサイトでない限り、死亡記録についての妥当なソースではない。合致するものがあれば、請求は自動的に承認される。合致するものが見つからなければ、システムは自動的に社会保障データベースを検索し、受給者が提供した事実に合致する、死亡したと報告されている個人を探す。合致するものがあれば、請求は自動的に承認される。合致するものが見つからなければ、システムは顧客に、死亡証明書を送付することによって証明を提供しなければならない旨を通知する。

実施形態６
顧客は死亡請求を発し、その請求は中リスクであるとスコア付けされる。承認検証のための代替の最小限の方法は、以下を含む。（ａ）政府機関から確認を取得する；または（ｂ）死亡証明書を取得する。この例において、システムは自動的に、社会保障データベースを検索し、受給者が提供した事実に合致する、死亡したと報告されている個人を探す。合致するものが見つかれば、請求は承認される。合致するものが見つからなければ、顧客は死亡証明書のコピーを提供するよう通知される。

実施形態７
顧客は死亡請求を発し、その請求は高リスクであるとスコア付けされる。承認検証のための許容可能な方法は、死亡証明書のみである。顧客は、死亡証明書を提供するよう求められる。

実施形態１および２では、プロセスが自動的に様々なソースを検索し、請求者の助けを得ることなく事象（死亡）を確認する状況を説明した。これらの例では、システムがある独立検証代替手段を介して死亡を確認することができた場合、顧客が提供する検証手段を必要とせずに、顧客は即座に、損失が検証された旨を通知される。その利点は、顧客が負担から解放され、請求がより速く承認され、保険会社または貸手が取引をより効率的に完了することができる点である。

以下の例では、保険会社または貸手が、請求者の主張の確実性を増すため、様々なソースからの情報を個別に収集することによって請求を検証する状況を説明する。

実施形態８
請求者は、身体障害請求を発する。請求者は、最近の心臓発作の結果、働くことができなくなった。顧客は、身体障害請求を発するため、保険会社に電話をかける。会社は、当該事象に関連する情報を集める。この情報は、心臓発作日、担当医、処方された薬剤、病院滞在期間を含む。システムは自動的に、顧客が指定した医師が心臓専門医である旨を確認する。システムはまた、識別された薬剤が心臓発作患者に処方される典型的なものである旨を確認する。システムはまた、処方データベースサービスに対して、顧客が処方薬剤を心臓発作後に受領した旨を自動的に確認する。検証情報のこれらのポイントの組合せを用いて、システムは請求を承認する。

実施形態９
顧客は、身体障害請求を発する。顧客は、背部傷害により働くことができなくなった。顧客は、身体障害請求を発するため、保険会社に電話をかける。会社は、当該事象に関連する情報を集める。システムは自動的に、請求者が傷害の結果として服用するよう請求した薬剤が、その種の傷害に対して示唆されていることを確認する。システムは、担当医として識別された医師がライセンスを有する専門家であることを確認する。システムは、当該医師の訪問と、身体障害を受け働くことができない旨を主張する顧客についての自動電子メール確認状を生成し、提供された情報が正確でない場合、医師が即座に返信するよう要求する。２日間の保留の後、システムはさらに動作することなく、自動的に請求を承認する。

上述の説明、例、データは、本発明に係る自動損失検証システムおよび関連する方法の完全な記述を提供する。本発明の多くの実施形態を本発明の要旨と範囲から逸脱することなく提供することができるので、本発明は以下に添付する特許請求の範囲に属する。

Claims (16)

1. 保険会社または金融機関によって発行された給付補償契約の下で請求を処理するための情報のデータベースを有する自動システムであって、
   （ａ）前記給付補償契約と、前記給付補償契約の下において請求された被請求損失事象を特徴付ける事実を識別する手段、
   （ｂ）保険会社または金融機関が、前記給付補償契約の下で、前記請求が詐欺または誤謬であるリスクを、統計モデル技術を用いて特徴付けるため、統計モデルまたはビジネスルールを介して前記請求に対してリスク評価スコアを割り当てる手段、
   （ｃ）前記損失事象を検証するため、前記請求についての前記リスク評価スコアを、前記保険会社または金融機関が要求する総合確実性レベル（ＴＣＬ）値に関連付ける手段、
   （ｄ）前記保険会社または金融機関によって選択され、または統計的にモデル化された、前記被請求損失事象を検証する能力についての確実性レベル値によってそれぞれ特徴付けられる、複数の補完データソースを事前に選択する手段、
   （ｅ）前記補完データソースの１つを、その情報コンテンツが前記被請求損失事象について請求者によって提供された情報に合致するか否かを判定し、合致した場合に限り、前記事前に割り当てられた前記補完データソースの確実性レベル値を、前記請求についての蓄積検証値（ＡＶＶ）スコアに追加するため、自動的に調査する手段、
   （ｆ）前記ＡＶＶスコアを前記ＴＣＬ値から減算することにより、前記被請求損失事象を検証するため要求される残存検証値（ＲＶＶ）を決定する（すなわち、ＲＶＶ＝ＴＣＬ−ＡＶＶ）手段、
   （ｇ）前記ＲＶＶ値が前記ＴＣＬ値より小さい場合に、連続する前記補完データソースを用いて、ステップ（ｅ）と（ｆ）を繰り返す手段、
   （ｈ）前記請求についての前記ＡＶＶ値が、少なくとも前記要求されるＴＣＬ値と等しい場合に、前記給付補償契約のルールに基づいて、最終処分として、前記請求の妥当性が確認されたものとして取り扱う手段、
   （ｉ）前記ＡＶＶ値が、前記要求されるＴＣＬ値と等しいかまたは超過しており、前記システムによって調査されたとき前記ＡＶＶ値と要求されたＴＣＬ値の間の差異を埋めるのに十分な、事前に割り当てられた確実性レベル値を有する他の補完データソースが入手できない場合に、前記請求の妥当性が確認されなかったものとして取り扱う手段、
   を備えることを特徴とする自動請求処理システム。
2. 補完データベースを用いてステップ（ｅ）と（ｆ）を繰り返し利用する前に、前記請求者が前記給付補償契約の下で給付を請求する権利を有する旨を確認する手段を備える
   ことを特徴とする請求項１記載の自動請求処理システム。
3. 少なくとも、補完データベースを用いてステップ（ｅ）と（ｆ）の１回目の繰り返し利用を実施した後に、前記請求者が前記給付補償契約の下で給付を請求する権利を有する旨を確認する手段を備える
   ことを特徴とする請求項１記載の自動請求処理システム。
4. 前記請求の前記最終処分は、妥当性が確認された前記被請求損失事象に準じて、前記給付補償契約のルールに基づいて、前記請求を前記請求者に対して支払うことを含む
   ことを特徴とする請求項１記載の自動請求処理システム。
5. 前記請求の前記最終処分は、前記補完データソースを用いた自動検証プロセスを前記請求に適用した後に、妥当性を確認することができなかった被請求損失事象に準じて、前記被請求損失事象について顧客が提供する損失検証を要求することを含む
   ことを特徴とする請求項１記載の自動請求処理システム。
6. 少なくとも１つの追加の補完データソースが、前記請求を処理している間に、前記システムが自動的に調査するため入手可能になった場合において、
   （ｊ）前記請求を処理している間に入手可能な全ての前記補完データソースについて最大検証値（ＭＶＶ）を計算する手段、
   （ｋ）ステップ（ｅ）と（ｆ）の現在の繰り返し実行の間に入手可能な特定の補完データソースについての集約確実性ポイント値として現行検証値（ＰＶＶ）を計算する手段、
   （ｌ）ステップ（ｆ）と（ｇ）の現在の繰り返し実行の間に入手可能な補完データソースについて、実行中現行検証値（ＲＰＶＶ）を、以前のＲＰＶＶ値と前記ＰＶＶ値の和として計算する手段（すなわち、ＲＰＶＶ＝ＲＰＶＶ＋ＰＶＶ）、
   （ｍ）ＰＶＶ＞０である場合に限りステップ（ｆ）と（ｇ）の繰り返しを進める手段、
   （ｎ）ＲＶＶ＞ＭＶＶ−ＲＰＶＶである場合に限り、前記入手可能なデータソースについてステップ（ｆ）と（ｇ）の繰り返しを進める手段、
   を備えることを特徴とする請求項１記載の自動請求処理システム。
7. 前記給付補償契約は保険契約を含むことを特徴とする、請求項１記載の自動請求処理システム。
8. 前記保険契約は、短期または長期身体傷害保険、健康保険、重病保険、歯科保険、定期生命保険、終身生命保険、貯蓄型または変動性生命保険、年金、火災保険、住宅保有者保険、竜巻または台風保険、洪水保険、自動車保険、海上保険、および他の形態の財産または災害保険のグループから選択される
   ことを特徴とする請求項５記載の自動請求処理システム。
9. 前記給付補償契約は債務保護契約を含むことを特徴とする、請求項１記載の自動請求処理システム。
10. 前記被請求損失事象の情報と合致する前記補完データソースを、コスト効率のよい方法で、前記損失事象を検証する適性に基づいて自動的に選択するためのルールセットを備える
    ことを特徴とする請求項１記載の自動請求処理システム。
11. 前記補完データソースの前記適性は、アクセスコストを含む
    ことを特徴とする請求項８記載の自動請求処理システム。
12. 前記補完データソースの前記適性は、ヒット率を含む
    ことを特徴とする請求項８記載の自動請求処理システム。
13. 前記補完データソースの前記適性は、前記補完データソースの確実性レベル値と、前記請求についての前記ＲＶＶ値との比較結果を含む
    ことを特徴とする請求項８記載の自動請求処理システム。
14. 前記補完データソースは、前記保険会社、前記金融機関、またはシステム運用者が保守する内部データベースである
    ことを特徴とする請求項１記載の自動請求処理システム。
15. 前記補完データソースは、サードパーティーから供給される外部データベースである
    ことを特徴とする請求項１記載の自動請求処理システム。
16. 保険会社または金融機関によって発行された給付補償契約の下で請求を処理するための情報のデータベースを有する自動システムであって、
    （ａ）前記給付補償契約と、前記給付補償契約の下において請求された被請求損失事象を特徴付ける事実を識別する手段、
    （ｂ）前記請求が詐欺または誤謬でないという確実性レベルを表す統計モデル技術を用いて、請求者、前記被請求損失事象、および１以上の事前に割り当てられた補完データソースの相対的リスク評価を結合する単一のスコアを割り当てる手段、
    （ｃ）１以上の前記補完データソースを自動的に調査して、その情報コンテンツが前記被請求損失事象の請求者によって提供された情報と合致するか否かを判定する手段、
    （ｄ）合致した場合のみ、前記給付補償契約のルールに基づいて、最終処分として、前記請求の妥当性が確認されたものとして取り扱う手段、
    （ｅ）合致するものがなかった場合、前記請求の妥当性が確認されなかったものとして取り扱う手段、
    を備えることを特徴とする自動請求処理システム。

Images