JP2010529562A - 走行距離に基づく自動車保険の既経過保険料を査定するためのシステム及び方法 - Google Patents

Abstract

走行距離による保険契約のための既経過保険料を算出及び査定するためのシステム及び方法が開示される。該システムは、契約開始からの事前に選択された距離単位数に対する補償内容によって部分的には定義される保険契約の保険期間に対して顧客に保険料を請求し、契約開始から経過した距離単位数を判断し、経過した距離単位の該保険契約で保険がかけられている距離単位に対する比率に基づいて、既経過保険料を請求した保険料に対して査定する。

Description

本発明は、走行距離に基づく自動車保険用の既経過(earned)保険料を査定するためのシステム及び方法に関する。

従来例の自動車保険の価格の設定及び販売は、期間（例：数ヶ月や数年）すなわち期限を通常は基準にしていた。年齢、性別、居所、運転歴等の申込者データが他の要因と組み合わされて、アクチュアリアル等級（actuarial class：保険数理による等級）が生成され、それによって価格が決定する。そして、この価格がエクスポージャ（exposure：損害の可能性）の単位と関連付けられる。従来の保険では、エクスポージャの単位は期間（期限）である。保険契約は主にエクスポージャの単位を基にして定義されるので、従来の保険契約は主に期限によって定義されている。しかしながら、このような従来の保険契約では、車の多様な使用パターンに対して費用が固定されてしまう。とりわけ、このアプローチは走行距離の少ない顧客にとって不利益である。
従って、上記に記載の及びそれに関連する問題に対して、改良されたシステム及び方法が望まれている。

走行距離に基づく自動車保険の査定、価格の設定、及び提供を行うための方法の一実施形態に係るフロー図である。 図１の方法が実行されるシステムの一実施形態に係る図である。 図２のシステムを用いるための方法の一実施形態に係るフロー図である。 図２のシステムに係るディスプレィを示すスクリーンショットの図である。 図２のシステムに係るディスプレィを示すスクリーンショットの図である。 図２のシステムに係るディスプレィを示すスクリーンショットの図である。 図２のシステムに係るディスプレィを示すスクリーンショットの図である。 図２のシステムに係るディスプレィを示すスクリーンショットの図である。 紹介（問い合わせ）に対してクレジットを算出し且つ付与する方法の一実施形態に係るフロー図である。 保険契約が失効間近であるかを判断し且つ顧客に失効が切迫していることを通知する方法の一実施形態にかかわるフロー図である。 図１０の方法によって生成されるフロントガラス用ステッカーの例を示す図である。 図１０の方法が実行されるシステムの一実施形態に係る図である。 失効した保険契約に基づく保険金支払請求の手続を実行する際に用いられる保険料（プレミアム）を算出する方法の一実施形態に係るフロー図である。 走行距離を基にした保険契約の一実施形態の一部に係る図である。 調整型期間保険の一実施形態の一部に係る図である。 走行距離に基づく自動車保険の査定、価格の設定、及び提供を行うための別の方法の一実施形態に係るフロー図である。 図２のシステム又は本発明による別のシステムによって実行可能なディスプレィを示すスクリーンショットの図である。 図２のシステム又は本発明による別のシステムによって実行可能なディスプレィを示すスクリーンショットの図である。 図２のシステム又は本発明による別のシステムによって実行可能なディスプレィを示すスクリーンショットの図である。 図２のシステム又は本発明による別のシステムによって実行可能なディスプレィを示すスクリーンショットの図である。 図２のシステム又は本発明による別のシステムによって実行可能なディスプレィを示すスクリーンショットの図である。 図２のシステム又は本発明による別のシステムによって実行可能なディスプレィを示すスクリーンショットの図である。 オドメータ値を格納するためのシステムの一実施形態を示す、エンティティ関係図である。 顧客に自己申告のオドメータ値を入力させるシステム機能に対応するスクリーンショットの図である。 走行距離を基にした保険における更新や車両の入替に対処するための１方法に対応するフロー図である。 更新する保険契約のための、オドメータ値の受け取りに対応するスクリーンショットの図である。 未使用マイルの繰越を伴う保険契約の更新に対応するスクリーンショットの図である。 売買又は入替された車のための、オドメータ値の受け取りに対応するスクリーンショットの図である。 更新する保険契約のための、一部が事前に記載されているフォームに対応するスクリーンショットの図である。 複数の既経過保険料記録においての想定できる関係を示す図である。 保険料及び別のデータを格納する１方法を示すエンティティ関係図である。 保険料の算出を実行する方法例を示すフロー図である。 保険料の算出を実行する別の方法例を示すフロー図である。

本発明は、走行距離に基づく自動車保険の査定、価格の設定、及び提供をするためのシステム及び方法に関する。しかしながら、以下に記載の本発明の開示においては、さまざまな実施形態や実施例が示される。構成要素及び変形の具体的な実施例が以下で説明されるが、これらは本発明を平易に開示するためである。すなわち、これらは単なる例示であって、限定を意図するものではない。さらに、本発明の開示において、参照番号及び／又は参照文字は、さまざまな実施例で繰り返し使用されている。これは、簡易明瞭にするために繰り返し使用するのであって、これによって本発明のさまざまな実施形態及び／又は構成間の関係性に影響を与えるものではない。

図１を参照すると、一実施形態において、方法１００を実行するコンピュータが、走行距離を基にした保険をユーザ（例：顧客）に提供するために用いられる。以下で詳述されるが、走行距離を基にした保険によって、変動的な使用状況に対して変動的な価格を組み合わせることが可能となる。これは、変動的な使用状況に対して固定料金が組み合わされている、従来の期限単位の保険と対照的である。つまり、方法１００によって、走行距離を基にした保険は実用品のように購入及び用いられることが可能となり、使用状況を正確に反映する料金になり、非効率な価格の設定作業が排除されて、消費者から選ばれることになる。

走行距離を基にした保険はまた、顧客に対する価格の設定を、将来の保険金支払請求を予測するのに最良の材料である車の走行距離と連携させることによって、保険業者のリスク管理能力を向上させる。年間走行距離と保険金支払請求の関係に係る広範囲の調査によれば、他のリスク要素（運転者の年齢、地域、車の使用状況等）が一定であれば、事故の危険性は、走行距離とほぼ直線関係で増大する傾向にある。走行距離を基にした保険は低走行距離（即ち低リスク）の運転者に最も有利に働くことにより、有益なリスクプールの選択を促進するものである。

事故のリスクは走行距離とともに直線的に増加する傾向にあるが、実用的見地から、時間的制約も考慮に入れる必要がある。例えば、保険契約が満了するまで何年もかかるような多数のマイルを被保険者が購入する状態は理想的と言えない。多様な保険品目に対して現在提示されている料率は、市場動向及びその他の出来事によって変動する場合がある。保険業者は、消費者に単一の保険契約を提供しながらも、より正確には時間ベースで考察できるリスクに対するエクスポージャを、より正確に説明することを望んでいる。（例：総合車両補償及び衝突車両補償）。距離単位当たりの保険として販売及び価格の設定がされているとしても、さまざまな懸念に対処するためには時間的制約も保険契約に課される。このような場合、被保険者は、本明細書に記載のように予定されたマイル数に対する保険が提供される。しかしながら、保険満了日も保険証券に記載されることになる。このように、保険期間の失効は、保険をかけたマイル数の全てを走行した時、又は保険契約満了日とで、どちらか早いほうとなる。以下でさらに詳細されるように、保険契約が満了するまでに走行されなかったマイル数に対処するためのオプションも多数ある。

再び図１を参照すると、方法１００はステップ１０２で開始し、顧客及び車両の識別情報を受け取る。顧客識別情報には、運転免許証番号、年齢、性別、住所等が含まれる。車両識別情報には、ナンバープレート番号、車両識別番号（ＶＩＮ）、車両製造元、型式、製造年等の情報が含まれる。ステップ１０４において、車の現在オドメータ値を受け取る。オドメータ単位（例：マイル又はキロメータ）は、その車や製造元の属する場所等の要因によって異なる。さらに、保険業者によるオドメータの監査や検証は、方法１００では実行されないことが本実施形態で示される。顧客が入力するオドメータ値が、現在オドメータ値として用いられる。

いくつかの実施形態では、補償範囲を開始あるいは継続するためには顧客が提供するオドメータ値のみが必要であるが、別の情報源からのオドメータ値が、有効化、検証、あるいはその他の目的のために用いられる。別の情報源には、車検記録、所有者又は登記の記録、販売の記録、私的データベースのデータ、内部データベースのデータ、及び他の情報源等が含まれる。

ステップ１０６では、複数の補償タイプが顧客に提示される。補償タイプの例には、推奨タイプ、経済的タイプ、最低補償タイプが挙げられる。補償タイプのいくつかの観点は、適用される国の規定によって制御される。ステップ１０８で、補償タイプの１つを選択する入力を受け取ると、顧客には少なくとも１つの見積書が提示される。見積書には、顧客及び車両の識別情報を基にして、距離単位当たりの料金（例：０．０５ドル／マイル）を示す保険料率が含まれる。従って、マイル当たりの料金には、リスクの査定に基づく多様な要因が含まれている。

ステップ１１０で、見積書に基づいて、事前に算出された複数のアイテム（項目）が顧客に提示される。各事前に算出されたアイテムには、その保険料率で購入できる距離単位の総数が含まれる。例えば、２５０ドルで５０００マイルの補償範囲（すなわち、０．０５ドル×５０００）を提供するアイテムもあれば、３００ドルで６０００マイルの補償範囲（すなわち、０．０５ドル×６０００）を提供するアイテムもある。追加的な保険マイルの購入に対するインセンティブを与える等の目的で、顧客に提示する算定を多様に変更させることもできる。例えば、１０，０００マイルを購入すると、保険料率が０．０４９ドルに減額されるとしてもよい。ステップ１１２で、顧客が購入するアイテムを選択して入力すると、保険契約の購入取引が実行される。保険契約には、現在オドメータ値及び選択したアイテムに含まれる総距離単位数との合計によって規定される、保険満了オドメータ値が含まれる。したがって、方法１００では、走行距離を基にした自動車保険契約を購入する際に、保険業者が事前にオドメータ値を実際に点検することが不要となり、またオドメータの監査や検証、車に設置される任意のタイプの追跡デバイスも不要である。

いくつかの実施形態においては、本発明の開示による方法は、実際のオドメータ検査、監査、あるいは追跡デバイスを不要にすることによって、顧客の利便性を向上させることができるものであるが、有効化や検証などの目的で車検記録等の情報源からのオドメータ値を利用することを必ずしも排除するものではない。一実施形態では、顧客によって提供されたオドメータ値は、外部の情報源に対して整合性をチェックされる。例えば、所定の車に対して顧客から提供されたオドメータ値が、以前の車検あるいは同様の検査で取得されたオドメータ値を下回っていれば、それは顧客が間違えたか、保険会社に対して詐欺を企てているか、又はオドメータ詐欺の被害者であることを示すことになる。顧客が提供したオドメータ値を他の情報源で確認することによって、このような問題に適切に対処できる。実施形態によっては、顧客にオドメータ値の不一致が通知される。顧客が意図的にオドメータ値を改竄したことが明らかな場合は、補償範囲がが解除される。また、顧客がオドメータ詐欺に気づいて、補償範囲の延長や継続が判断される場合もある。さらに、外部の情報源から入手したオドメータ値によって、顧客の保険契約がすでに失効していることがわかる場合もある。この場合は、顧客に通知されて契約更新の機会が与えられる可能性がある。上記に記載のように、この追加的なデータは、顧客の保険の補償が失効間近となる時期をより正確に予測するために利用される。ひいては、より正確に補償範囲の失効が切迫している旨の警告を顧客に通知することができる。

図２を参照すると、システム２００によって、走行距離を基にした自動車保険を提供するために用いられるシステムの一実施形態が示されている。例えば、図１の方法１００はシステム２００において実行される。本実施例では、システム２００はキオスク２０２を含み、そこでユーザ（不図示）は走行距離を基にした保険について、価格の判断、アイテムの選択、及び購入を実行する。別のシステム（例：ウェブサイト）が同様の機能を果たすこともできる。キオスク２０２は、ユーザに情報を提供し、かつユーザの入力を受信処理する。例えばキオスク２０２は、メモリユニット２０６と接続している中央演算処理装置（ＣＰＵ）２０４、入力／出力（Ｉ／Ｏ）装置２０８、ネットワークインターフェース２１０、プリンタ２１２、及び磁気ストライプリーダ（ＭＳＲ）２１４を具える。例えば、ネットワークインターフェースは、モデム（例：Ｖ．９０モデム）及び／又は、媒体アクセス制御（ＭＡＣ）アドレスでそれぞれが使用される１又は複数のネットワークインターフェースカード（ＮＩＣｓ）である。ネットワークインターフェース２１０は、ＴＣＰ／ＩＰ及び／又はブルートゥース（Bluetooth）等の任意の多様な有線及び無線ネットワーク技術と互換性がある。構成要素２０２、２０４、２０６、２０８、２１０及び２１２はバスシステム２１６によって、相互に接続されており、それは無線及び／又は有線の通信路を含んでいる。

これら構成要素は、キオスク２０２で単独の記憶装置内に置かれているが、多くの異なる方法でコンフィギュレーションが可能である。例えば、ＣＰＵ２０４、メモリユニット２０６、Ｉ／Ｏ装置２０８、及びネットワークインターフェース２１０は、キオスク２０２で１つのコンピュータ内に配置され、プリンタ２１２及びＭＳＲ２１４は、周辺機器として構成されてもよい。さらに、各構成要素が、実際は複数の異なる構成要素を兼ねている場合もある。例えば、ＣＰＵ２０４はマルチプロセッサ又は分散処理システムであり、メモリユニット２０６は異なるレベルのキャッシュ記憶、メインメモリ、ハードディスク、及び遠隔記憶ロケーションを具え、Ｉ／Ｏ装置２０８はモニタ、キーボード、タッチ画面ディスプレィ等を具えてもよい。プリンタ２１２は１又は複数のプリンタであり、感熱式印刷又は他の適宜の印刷技術を用いる。例えば、プリンタ２１２はビニル印刷紙用の感熱式プリンタ及び、別のコート紙用の感熱式プリンタである。

ネットワークインターフェース２１０はネットワーク２１８に接続されている。例えば、ネットワーク２１８は、ローカルエリアネットワークのサブネット、社内イントラネット、及びインターネットのうちの少なくとも１つである。ネットワークインターフェース２１０はネットワーク２１８に接続されているため、構成要素によっては、時には別のコンピュータ（不図示）と共有使用される場合がある。それゆえ、キオスク及びその構成要素のコンフィギュレーションにおいては、広範にわたる柔軟性が期待される。さらに、いくつかの実装においては、ＣＰＵ２０４が別のコンピュータに対してサーバの役割を果たしている。

ネットワーク２１８を介してキオスク２０２と接続しているのが、サーバ２２０である。サーバ２２０は複数のサーバの１つであって、ルータ（不図示）等のネットワーク装置からの特定のユーザの要求を処理するために選択されている。ルータは、ラウンドロビン方式を用いて（又は別のアロケーション／ロードバランシングプロセスを用いて）サーバ間の全ての通信要求を処理する。サーバ２２０は、データベース２２４に格納されている情報を利用するアクチュアリアルエンジン（保険統計エンジン）２２２と接続されているか、又はそれを具えている。アクチュアリアルエンジン２２２及びデータベース２２４は、後述されるように、顧客のアクチュアリアル等級及び関連するマイル当たりの料金を決定するために用いられる。
サーバは、プロセッサ及びメモリ（不図示）を具えており、アクチュアリアルエンジン２２２及びデータベース２２４へのアクセスに必要なソフトウェアインストラクションを実行し、またＣＰＵ２０４と通信する。いくつかの実施形態では、サーバ２２０は、全て又は一部のウェブサイトをホストするホストコンピュータであり、該ウェブサイトは、本実施例と同様の機能を提供するための多様なウェブページ及び／又は実行コードを具えている。

ＣＰＵ２０４は、複数のソフトウェアインストラクションを有しており、それによって周辺機器通信やネットワーク通信を処理し、かつ顧客が利用するためのローカルポイントオブセール（販売時点管理：ＰＯＳ）アプリケーションをホストするシステムを操作する。ＣＰＵ２０４及びそれに関連する構成要素は、顧客の情報及び選択の全てをネットワーク２１８を介してサーバ２２０に通信するか、又はＣＰＵ２０４自身が処理機能の一部あるいは全てを実行する。

操作においては、顧客はタッチ画面ディスプレィ２０８を介してキオスク２０２と情報のやりとりを行うことで、データの閲覧及び入力ができる（入力には、画面上のキーボードを利用する）。ＰＯＳアプリケーションによって運転免許証情報を尋ねられた時に、顧客はＭＳＲ２１４に運転免許証を通す（運転免許証情報を含む磁器ストライプが運転免許証に含まれている場合）。ＰＯＳアプリケーションによってクレジットカード情報を尋ねられた時に、顧客はＭＳＲ２１４にクレジットカードを通す。顧客が保険契約に同意すれば、プリンタ２１２が、保険契約者の車のフロントガラス用にビニル製の静電気式リマインダステッカーを印刷する。さらに、プリンタ２１２は顧客用に２枚の保険証券をコート紙に印刷する。

いくつかの実施形態では、キオスクが、顧客の携帯電話と情報交換ができるワイヤレス（例：ブルートゥース）機能を具えている。例えば、購入プロセスの支払いステップにおいて、顧客が携帯電話を介して保険を購入する選択をしたとする。携帯電話は、一意的な識別番号を有しており（例：国際移動電話加入者識別（ＩＭＳＩ）番号）、それによって自身の携帯電話ネットワークへの帰属を可能にしている。この番号は、支払い取引のための一意な識別番号としても用いられる。例えば、顧客が購入した保険の支払いを、携帯電話料金の請求書に加算することができる。携帯電話を利用することで、顧客は電子クーポンの申込をキオスクに送信することも可能となる。このようなクーポンの申込はより大規模なマーケティングキャンペーンの一環となり、顧客は、参加している業者で保険のクーポン／クレジットを受け取ることができる。

携帯電話を利用することでまた、顧客は紹介者（例：今回の購入に対して、今回の顧客を紹介した別の顧客）の電話番号を容易に送信することができる。そして電話番号が、紹介クレジットのための一意識別子（ＵＩＤ）として用いられる。例えば、顧客は自分の携帯電話の住所録から、自分にキオスク２０２を紹介した人物の名前を検索する。各住所エントリの隣には、電話番号登録エントリを「保険の紹介者」として選択するためのキーパッドオプションがある。ユーザが携帯電話のキーパッドで選択した品目を押すと、表示されている住所エントリに関連する電話番号が、キオスク２０２に送信される。キオスク２０２は、ネットワークを介して紹介者の電話番号の受領を認証するように構成される。

図３を参照すると（図４〜８も併せて参照）、方法３００によって、顧客が図２に示されるシステム２００等のインタラクティブシステムを利用して、どのような手順で距離を基にした自動車保険を購入するかについて、より詳細な例が示されている。本実施例における顧客は、既存の保険契約者／顧客によって紹介された新規顧客のことである。

ステップ３０２において（図４のスクリーンショット４００も参照）、顧客はキオスク２０２に行き、運転免許証をＭＳＲ２１４に通すか、又はタッチ画面２０８での手入力によって、運転免許証番号を入力する。システム２００は運転免許証番号を用いて、顧客の氏名、年齢、住所、運転歴、登録車両、等の情報を検索する。これはまた、限定された犯罪歴チェックにも用いられる。顧客に以前の利用経験がある場合は、前回の保険契約情報の全てが免許証番号及び確認キーを基にしてロードされるので、顧客は任意の既存の情報及び選択を修正する。ステップ３０４で、顧客は保険をかけたい車両のナンバープレート番号を入力する。ナンバープレート番号は、車両識別番号（ＶＩＮ）、車両の製造元、型式、色、製造年を検索するために利用される。この番号はまた、運転免許証情報と車両登録情報との間に違いが生じていないかを判断するためにも利用される。ＶＩＮは車歴を確認するために利用される。

ステップ３０６で、顧客は車両の現在オドメータ値を入力するが、その値が補償範囲の起算点となる（保険契約が購入された場合）。ステップ３１０において、１又は複数の第２運転者がいる場合（ステップ３０８で決定）、顧客は第２運転者の運転免許証番号を入力する。顧客の運転免許証番号と同様にして、この番号は、第２運転者の氏名、年齢、住所、運転歴、及び登録車両の検索のために、また限定された犯罪歴チェックのために使用される。本実施例では、第２運転手の登録住所の記載が第１運転者（例：顧客）のものと異なることは許可されない。

ステップ３１２において（図５のスクリーンショット５００も参照）、顧客は、３つの補償商品（例：「推奨」「経済的」「最低限」）から、ラジオボタン装置を用いて選択をすることになる。本実施例では、補償商品の選択肢を３つにすることで、取引速度が向上し、顧客が手続作業を直感的に理解でき、リスクプールの管理が簡易になっている。また、補償商品の選択肢の数を調整して用いることも、各補償内容の複雑さを調整して用いることもできる。ステップ３１４において、顧客はまた追加的なオプション補償（例：「衝突車両補償」「総合車両補償」「ロードサイドアシスタンス」を、図５のチェックボックスを使用して選択する。これらのオプション補償は法的に加入が義務付けられてはいないが、先取特権者によっては車両担保を保護するために加入を要求する場合もある。補償商品及びオプション補償の両方に対して、マイル当たりの料金が顧客に示される。マイル当たりの料金は、入力済の顧客及び車両の情報と、コンピュータ（例：図２のサーバ２２０）によって顧客が該当するとされたアクチュアリアル料率等級に基づいている。本実施例におけるアクチュアリアル料率等級は、年齢、場所（例：居所又は運転地域）、及び車両タイプのみから成るが、別の要因が用いられる場合もある。

ステップ３１６において（図６のスクリーンショット６００も参照）、保険契約の見積りが＜通貨単位＞／＜距離単位＞の形式で顧客に提示される。本実施例では、０．０５６ドル／マイルという見積りであるが、これは顧客が「推奨」の補償商品を選択し、さらにオプション補償の「衝突車両補償」「総合車両補償」を選択した場合の合計である（図５にある値段で）。顧客は、事前に算出された品目のリストから選択することで、保険料の総額を選ぶ。例えば、図６の事前に算出された品目は、２８０ドルで５０００マイル（０．０５６ドル／マイル）の保険を提示している。他のメニュー品目（不図示だが、図６の上下矢印で選択可能である）は、所定の増分で契約可能の最大マイル数まで提示される（例：１０００マイルが２５０００マイルまで増分していく）。このアプローチによって、期間を基にした保険プランと比較してコストが抑えられることを、顧客は確認できる。また、今後の走行距離を抑えることがコストに直接的な影響を与えることも確認できる。この事前の算出はまた、ユーザインターフェースとして非常に便利でかつ直感的に理解しやすいものである。

ステップ３１８において（図７のスクリーンショット７００も参照）、顧客には電子支払い画面が提示され、顧客はクレジットカードをＭＳＲ２１４に通すか、タッチ画面２０８を介してクレジットカード情報を入力する。これによって、支払い情報が提供されるだけでなく、運転免許証あるいは顧客から提供されたクレジットカード発行者の記録による住所／氏名情報の組み合わせを、有効化するための最終確認が実行される。有効化に成功すると支払いが顧客から速やかに受領され、現金や個人小切手の決済／取り扱いの費用が発生することはない。

本明細書に記載のシステム及び方法を利用する全ての顧客が、保険に加入する権利を有しているわけではない。例えば、過去に飲酒運転や酩酊状態での運転をしたことが判明すれば、保険に加入する資格がないとされる。いくつかの実施形態では、１８歳未満の運転者、車を所有していない運転者、特定の州で居住かつ／又は就労していない運転者、無免許、または免許の有効期限が切れている運転者、悪質な保険金請求歴（adverse prior claims history）のある運転者、商用で自分の車を使用している運転者もまた、保険にか加入する権利がない。当業者によってもまた、本明細書で開示されたシステム及び方法を利用して保険に加入する資格を運転者から剥奪するような、他のリスクとなる要因、環境、法的考慮が明らかとされるであろう。

同様に、状況によっては、保険業者が本発明によるシステム及び方法を用いる際に、実在の代表者や代理人に特殊なケースを査定してもらう必要がある場合もある。これらの特殊なケースは、本発明による自動システム及び方法で対応できる範疇に入らないが、最終的には再査定によって保険が提供される。このような場合、査定には本発明による自動システム及び方法によって取得された情報が利用される。別の実施形態では、該取得された情報は、実在の代表者や代理人から取得された追加的な情報によって補足されたり、それと入れ替えられたりする。このような例外的ケースで保険が認められた場合、顧客は引き続き実在の代理人を通すか、あるいは本発明による自動システム及び方法に戻って手続をする。

再び図３を参照すると、ステップ３２０で、顧客が既存の顧客に紹介されたのかが判断される。紹介者がいる場合は、ステップ３２２で、顧客は紹介者の紹介ＵＩＤを入力する。後に詳細するように、紹介ＵＩＤは紹介者へのクレジット（credit）を算出するために使用される。

ステップ３２４において（図８も参照）、顧客は金融取引を完了する。プリンタ２１２を使用して、紙の印刷用カードに２つの保険証券が印刷される。保険証券は認証キーを有しており、それは既存の保険契約データをロードすることによって今後の取引を迅速にするために用いられる。別のプリンタは、保険証券の印刷と同時に静電気式フロントガラス用リマインダステッカー（図１１）をビニルの印刷用紙に印刷するために用いられる。もしくは、第１プリンタで保険証券を印刷した後に、リマインダ用ステッカーを印刷してもよい。その後顧客は印刷物を取って、キオスク２０２での手続を終了する。

次に図９を参照すると、別の実施形態における方法９００は、新規顧客を紹介した既存の顧客（紹介者）のクレジット（例：追加のマイル）を算出し、算出値を紹介者のアカウントにクレジットの付与をするために使用される。ステップ９０２及び９０４では、図３に関して詳細に先述されたようにして、顧客の保険契約購入要求及び支払情報が受領される。ステップ９０６で紹介者のＵＩＤが受信され、ステップ９０８で新規顧客の支払いが実行される。ステップ９１０で、紹介者のＵＩＤは紹介者のアカウントと新規顧客のアカウントを結びつけるために使用される。

ステップ９１２において、紹介者のアカウントに加算されるべきクレジットが算出される。本実施例では、クレジットは走行距離として支払われ、紹介者の現存の保険契約に追加の補償範囲のマイルが加算される。クレジットは、「紹介者の保険契約にクレジットとして付与されるマイル数＝（（パーセント）×（新規顧客による購入のドル価値）／（紹介者のマイル当たりの保険料）という式を用いて算出される。例えば、パーセントが０．０２、新規顧客による購入のドル価値が２８０ドル、紹介者のマイル当たりの保険料が０．０５ドルの場合、紹介者のクレジットは、１１２マイルとなる。本実施形態では、付与されたクレジットは換金できず、また新規顧客の初回購入時においてのみ、紹介クレジットを受け取ることができる。既存の顧客が複数の新規顧客の初回購入を紹介すれば、複数の累積されたクレジットを受け取ることになる。ステップ９１４で、紹介者のアカウントに算出されたマイル数がクレジットとして付与される。実施形態のいくつかでは、該クレジットは紹介者である顧客の現保険契約がすでに終了している場合は、その元顧客のために「取り置き」される。紹介者が再び保険に加入すると、上記のクレジットがアカウントに付与される。この制度を用いることで、例えば、紹介を促進し且つ元顧客が再び保険契約を購入するのを促進することにもなる。

次に図１０を参照すると、方法１０００によって、保険契約満了／更新のリマインダ通知を生成するプロセスの一実施形態が説明される。方法１０００は、収集したオドメータ値、価格設定乗数（pricing multipliers）、双方向リマインダ、及び静電気式フロントガラス用ステッカーの使用を含む。上記の全てが必ずしも用いられるわけではなく、また別のもが加えられてもよい。

いくつかの実施形態では、走行距離を基準とする保険の購入によって、走行距離を限定する契約が成立する（例：オドメータ値５０００マイルから、オドメータ値７５００マイル以下の走行距離）。従って、意図せずに保険の補償範囲を超えて運転するのを防止するために、保険契約者に契約失効が間近に迫っていることを注意喚起することが望まれる。さらに、多くの顧客が先取特権の助けで車を購入しており、先取特権者は担保を保護するために、車の保険の補償範囲を要求することが多い。

ステップ１００２において（図１１も参照）、顧客が距離を基準とした保険契約を購入する際に静的傾向フロントガラス(static-cling windshield)用のステッカー１１００が作成される（図３のステップ３２４参照）。図１１に示されるように、ステッカーには、被保険車の契約開始及び終了のオドメータ値及び、更新にまつわる情報の問合せ先電話番号等の情報が含まれている。

後述するが、窓用ステッカーに加えて、又はその代わりに、例えば予定走行距離を基にして顧客にリマインダを送付することもできる。ステップ１００４では、保険契約購入時の開始オドメータ値によって、ベースライン(baseline:基準線)が設定される。ステップ１００６で、所定の期間単位に対する顧客の平均走行距離（例：マイル）を用いて、保険契約満了日が推定される。例えば、保険契約が１２０００マイル分で、運転者の１ヶ月あたりの平均走行距離が１０００マイルであれば、保険契約満了日は、保険契約の購入日から１２ヶ月後と推定される。この推定された走行率は、所有者記録（ownership record）を用いても算出される。例えば、対象車が２年前に保険契約者に購入されて、その時点のオドメータ値が３００００マイルであったが、現在のオドメータ値が７８０００マイルであるならば、保険契約者は１ヶ月あたり約２０００マイルを走行したことになる。より正確な走行率が存在しなければ、デフォルトの走行率が適用される。

ステップ１００８において、エミッション・テスト、保守、販売、購入、登録、事故証明書等の情報源から、任意のオドメータ値が収集された場合、推定契約満了日が更新される。この収集された任意のオドメータ値によって、対象となる顧客のより正確な走行率を推定することが可能となる。

ステップ１０１２において、保険契約満了日が近づいていれば（これはステップ１０１０で判断される）、顧客には保険契約失効の切迫（期間及び走行距離のいずれかで判断される）を通知するリマインダ（例：手紙又はＥメールや携帯電話のメール等の電子的なリマインダ通知）が送付される。このリマインダによって、顧客は通信デバイス（例：携帯電話、ポケットベル、携帯情報端末）を用いるか、又はウェブサイト、キオスク、その他双方向的な通信の可能な場所で、現在オドメータ値を入力するように指示される。入力されたオドメータ値は、ステップ１０１４で、走行率及びそれに伴う契約満了日を推定するプロセスをより精密にするために用いられる。時が経つにつれ、方法１０００は各保険契約者に対してより個別な走行率を提供できるようになる。オドメータ値の入力回数が少ないと、通知には大きな誤差が生じる可能性があり（例：契約満了までの時間がより長い）。オドメータ値の入力回数が多いと、それゆえ値が正確となるので、通知に誤差が生じる可能性が少なくなる（例：契約終了までの時間がより短い）。

図１２を参照すると、システム１２００によって、携帯電話を介して顧客に電子リマインダを送信するためのシステムの一実施形態が示されている。政府筋（例：州による記録、国が管理する情報）からの多様なデータベース及び記録数値１２０２、民間企業による記録１２０４、及び車の所有者が報告したオドメータ値１２０６が、中央データ格納庫１２０８で混合され、メインキーとして車両識別番号（ＶＩＮｓ）が設定される。さらに、記録された各オドメータ値が１つのデータに関連づけられる。保険契約者及び被保険車に関するデータベース１２１０は、オドメータ値のデータベース１２０８と結び付けられる。

サーバ１２１４で実行される、サーバソフトウェアプロセス１２１２（例：保険契約の失効を予測するために走行距離を推定するプロセスを意味するソフトウェアインストラクション）は、保険契約者の車に関する全てのオドメータ値を分析する。プロセス１２１２によって、保険契約の失効が近づいていると認識されれば、リモートサーバプロセス１２１６に保険契約者と通信させる。本実施例では、リモートサーバプロセス１２１６は、標準的セルラーネットワーク１２１８を介して、保険契約者の携帯電話１２２０にメッセージを送信する。

保険契約者の携帯電話１２２０はメッセージを受信し、それはローカルソフトウェアプロセス１２２２（保険契約者によって事前にインストールされている）によって解析される。すると、携帯電話は保険契約者にクエリを発信し、電話のキーパッドを使用して対象車の現在オドメータ値を入力するよう顧客に要求する画面を表示する。保険契約者がオドメータ値を入力すると、ローカルソフトウェアプロセス１２２２は顧客に対し、すぐに保険契約の更新をするよう推奨するか、又は更新を待つよう推奨するかのいずれかを実行する。

更新を推奨する場合は、ローカルソフトウェアプロセス１２２２は、保険の追加の補償範囲のマイルが購入できる画面を開く。保険契約者は、購入数及び方法（例：登録してあるクレジットカードを介して、又は携帯電話の請求書を介して）を選択する。更新を待つよう勧める場合は、ローカルソフトウェアプロセス１２２２はオドメータ値をリモートサーバプロセス１２１６に送信し、そこからデータベースを更新するために情報が伝えられる。いくつかの実施形態では、ローカルソフトウェアプロセス１２２２は、更新を待つことを推奨する場合には保険契約者にクエリを発信しない。さらにいくつかの実施形態では、ローカルソフトウェアプロセス１２２２はリモートサーバプロセス１２１６が判断した推奨をそのまま伝えるだけである。
システム１２００は、図２のシステム２００等の別のシステムと接続しているか、又はその一部になっている。例えばサーバ１２１４は、図２のサーバ２２０であるか、又はサーバ２２０と通信していることになる。

次に図１３を参照すると、別の実施形態において、方法１３００によって保険契約者は、保険契約失効時点から保険金支払請求の時点までの補償範囲のエクスポージャに対して遡及して値段をつけることで、失効した保険契約を更新できる。補償範囲の失効を想定した場合の関係者は、通常は、規制当局(state regulator)、保険契約者、先取特権者の３者である。規制当局は、法的要件を満たすために、保険契約者が補償範囲を維持することを必要とする。先取特権者は、補償範囲によって、担保（車）の保護が維持されることを必要とする。保険契約者は、法と先取特権者となりえる者に従うために、且つ被る可能性のある経済的損失を最小限にとどめるために、補償範囲を維持する必要がある。

走行距離を基にした保険における問題点の１つは、保険契約者が車の補償範囲のオドメータ値をオーバーして運転してしまい、保険契約が失効してしまうことである。方法１３００は、保険契約者による同様の使用パターン（契約失効の発生等）に対処するために使用され、規制当局、先取特権者、保険契約者による失効期間なく補償範囲が維持されるべきという要求のバランスを取ることができ、保険商品自体に経済的又は操作上の負担をかけることもない。

ステップ１３０２において、保険金の支払請求を保険契約者から受け取る。ステップ１３０４において、保険金の支払請求に対する保険契約が終了しているかどうかを判断する。例えば、請求に含まれるオドメータ値が保険契約失効のオドメータ値と比較される。保険契約が失効していない場合はステップ１３１２に移行し、保険金の支払請求が処理される。

保険契約が失効している場合はステップ１３０６に移行し、プレミアム(premium:割増保険料)が算出される。保険契約者は、保険契約で規定のオドメータ値の限度をオーバーしていても、確かに任意の保険金支払請求／関連性（involvements）に対してカバーされるが、その場合、保険契約者は割増料金で保険料を請求されることになる。なによりの利点は、金銭面とリスク面の利害が一致するため、プレミアムの存在によって保険契約者は保険契約を常に維持しておくようになることである。

プレミアムは、プレミアム＝「（現在オドメータ値）−（保険契約失効となるオドメータ値限度）×（保険料率）×（乗数）」という式で計算される。「プレミアム」は、保険契約が失効してから関与/保険金支払請求がなされた時点のオドメータ値までの間の対象車の使用に対して、保険契約者に請求される料金である。「現在オドメータ値」は、対象車の現在のオドメータ値である。「保険失効となるオドメータ値限度」は、保険契約の補償範囲の上限値である。（例：契約開始オドメータ値が９０，０００マイルで、５，０００マイルの補償範囲を購入した場合、保険契約は９５，０００マイルで終了する。）「保険料率」は、所定の車及び補償内容に対して保険契約者にかかる通常のコストである（例：０．０５ドル／マイル）。「乗数」は、プレミアムが通常の料率をいくら上回るかを示す数字である。

このようにして、失効している保険契約に対して保険金支払請求がなされた場合には、失効期間の車の使用に対してプレミアムが課される。例えば、保険契約が９５，０００マイルで終了した保険契約者が、１００，０００マイルの走行距離である場合でも、保険金の支払請求を選択できる。保険金の請求をした場合、９５，０００マイルから１００，０００マイルまでの合計５，０００マイル分の潜在的な保険に対して保険料を支払う必要がある。この５，０００マイル分の補償範囲には、当人の通常の料率の倍数にあたる料金がかかる。例えば、当人の通常の料率が０．０５ドル／マイルであれば、０．２５ドル／マイルを支払うことになる（乗数が５の場合）。すなわち、１，２５０ドルを支払わねばならない（通常の料率の２５０ドルではなく）。

ステップ１３０８において、保険契約者が更新を望んでいるかが判断される。本実施形態では、プレミアムが保険契約者に対して表示されるが、別の実施形態では、保険契約者は更新の選択が与えられるだけで、プレミアムは保険契約者の現在の所定の保険契約に従って請求されることが通知される。保険契約者が更新を望まない場合は、方法１３００は終了する。保険契約者が更新を望む場合は、ステップ１３１０で保険契約者による支払いが受け付けられ、ステップ１３１２で保険金支払請求が実行される。このように、方法１３００は、走行距離を基にした保険を常に維持することを可能にするための「遡及補償」（"retroactive coverage"）を提供する。さらに、プレミアムによって、保険契約者が、更新、延長、又は最初の購入マイル数を増やす等をして、保険契約の維持に努めるよう動機づけることができる。

別の実施形態では、グレースピリオドや遡及補償は提供されていない。このような実施形態では、保険契約の走行距離や期限を超過した場合は、顧客は契約失効後に発生した事象に関して提出された任意の保険金支払請求に対して、補償を受けることができない。以下でさらに詳細されるように、所定の期間や走行距離の限度を超過する前に、保険契約が失効する場合もある。

所定の保険契約に有効期限があるかどうかにかかわらず、未使用の走行距離（マイル）は、失効（走行距離あるいは期限による）の前の更新で使用することができる。一実施形態では、現保険契約で利用可能な補償範囲のマイル数が、新規すなわち更新した保険契約に追加される。この実施形態では、新規保険契約の値段が減額されることはないが、別の方法も可能である。顧客は、更新時に購入するマイル数を減らすことで、新規保険契約にかかるコストを効果的に低減することができる。時間の経過と共に、顧客自身も、また本システムによっても、一年の所定の期間に実際に必要となるマイル数をより正確に推定できるようになる。一年の所定の期間に必要となるマイル数を区別することもまた可能である。例えば、ある運転者は、夏季や冬季の間はより多くのマイル数を走行している。この情報は、保険契約の更新、マイルの追加、又はリマインダ通知の作成が行われる際に、考慮に入れられる。

次に図２５を参照すると、更新及び車両入替を扱うためのプロセスフローの実施形態が示されている。プロセスフロー２５００によって示される方法は、本発明によるシステムで動作可能な一方法を示しているだけであり、本発明の範囲においてさらに多くの方法が実行可能である。例えば、方法２５００は、図２のシステムにおいて用いることもできる。ステップ２５１０において、顧客はＶＩＮ又はナンバープレート番号を入力し、それが内部の記録又はデータベースでチェックされる。例えば、これは図４で示された初期データ収集ステップの一部である。ＶＩＮ又はナンバープレート番号に対応する車に、まだ保険が掛けられていない場合は、ステップ２５１４において、本明細書に記載の保険を引き受けるために、必要となる運転者及び車の情報が入手される。それから、ステップ２５３２で新規保険証券が発行される。

ＶＩＮ又はナンバープレート番号が既に保険が掛けられている、すなわち保険契約でカバーされている車に対応する場合は、ステップ２５１６で既存の保険契約のアカウントにログインするように指示される。インターネットや本明細書に記載の別の方法によって、アカウントに直接ログインすることも可能である。さらに、この文脈では、顧客がアカウントにログインするのは保険契約の更新が目的となるが、ログインすれば、実際には顧客はたくさんの選択肢を有している。例えば、保険金の支払請求や事故の報告、解約の要求、カスタマーサービス係への質問、別の取引等を行うことができる。さらに、顧客は１つのユーザ名とパスワード、すなわちログイン・セッションによって、複数の保険契約にアクセスすなわち支払いをすることが可能である。これは、顧客が複数の車を所有しており、それぞれに異なる保険契約をしている場合に生じる。

上記のことから、ステップ２５１０は、すでに保険でカバーされている車に対して新規保険証券が誤って発行されないようにするためのバックアップチェックすなわち有効化ステップの役割を果たしていると言える。顧客がログインすなわちシステムで認証されると、ステップ２５１８において顧客からオドメータ値が取得される。図２６は、どのようにオドメータ値がステップ２５１８で取得されるかを示すスクリーンショット例である。このオドメータ値は、既存の保険契約での補償範囲が残っているかを判断し、残っているマイルを新規すなわち更新の保険契約に繰越できるかを判断するために必要とされる。さらに、提供された任意のオドメータ値は、以下で詳細されるように、使用目的によっては有効化及び／又は検証が必要とされる。

ステップ２５１８で、現在の既存保険契約についての情報が示される。これには、保険の対象となっている運転者及び車、提供される補償のタイプ、補償限度、及び現在の保険料が含まれる。この情報は、ユーザすなわち顧客に、なじみのある又は便利な形式で表示される。図５は、この情報を表示する方法の一例である。ステップ２５２０で、保険契約の変更が実行される。図５と同様の形式がこのステップにおいても使用され、現在の保険契約パラメータを基に既に提供されているデフォルトの選択を、ユーザは変更することができる。ステップ２５２２において、新規の選択が引き受けられるか、または以前のすなわちデフォルトの選択が承認される。

いくつかの例では、現在の保険契約における全てのマイルが失効する。これはステップ２５２４で判断される。未使用のマイルがない場合は（つまり、全てのマイル数が走行されたか、契約期限が失効したかのいずれか）、ステップ２５３２において、新規保険証券が発行される。いくつかの実施形態では、新規保険契約は、ステップ２５１８で提供された新規オドメータ値に基づくことになる。別の実施形態では、ユーザは失効した保険契約のオリジナルのオドメータ値に基づいて支払いをすることが求められる。別の実施形態では、新規オドメータ値は、更新の保険契約の基準となる値として使用を許される前に、検証されるか、又は信頼できる情報源からの値であることが要求される。信頼できるオドメータ値及び信頼できないオドメータ値に関しては、以下で詳細される。

ステップ２５２４において、新規すなわち更新の保険契約に繰越が可能な未使用マイルがあることが判断される。この場合、ステップ２５２６において、料率の見直しが必要か否かを判断する。料率の見直しは、居所の変更、超過の保険金支払請求、走行中の交通違反、保険契約への運転者の追加、その他、以前の保険契約と異なる補償内容を選択した等の理由から、行われる。料率の見直しの必要性及び新規料率は、ステップ２５２２からの情報を基準にして判断される。いくつかの実施形態では、料率の見直しは自動的に又は保険業者によるオプションで発生する。場合によっては、保険業者が料率表を改定したことによって、顧客が補償内容すなわち保険契約を変更していなくても、保険料が異なることもある。また、料率の見直しが自動で行われる場合、旧契約及び新規契約のどちらにおいても、マイル当たりの料金が最終的に同じになることもある。

次にステップ２５２８にすすむと、料率の見直しが必要な場合においては、旧保険契約と新規保険契約では、補償範囲のマイルに対するマイル当たりのコストに差異が生じている。このような場合、未使用マイルを新規すなわち更新の保険契約に繰り越すためには、未使用マイルについて、旧料率と新規料率の差額を購入者が支払う必要がある。場合によっては、被保険者は、新規マイルを購入して旧マイルすなわち未使用マイルを廃棄するのではなく、未使用マイルを新規保険契約に繰り越すことを保険業者から要求される。図２７は、料率の見直しの情報が顧客に通信される１方法を示すスクリーンショット例である。新規料率のマイル当たりの新規料金が、今回購入する保険のマイル数で乗じられたものが顧客に提示される。未使用マイルに対してすでに支払った値段と、新規料率の差額も提示される。この差額は、新規保険契約に繰越をするマイル数と乗じられて、新規マイルの購入に対する値段に加算され、更新の保険契約を購入するのにかかる値段の総額となる。

いくつかの実施形態では、前の保険契約と更新の保険契約との間で、マイル当たりの料金に差額が生じていない。ステップ２５３０で示されるように、そのまま繰り越されることになる。以前のマイルは、更新の保険契約に繰り越されるが、追加料金はかからない。更新の保険契約と前保険契約の間で料率の見直しがなかったためか、料率の見直しをしても、結果としてマイル当たりの料金が同じであったために差額が生じていない。別の実施形態では、新規保険契約の方が、現在の契約に比べてマイル当たりの料金が実際のところ安くなっている。このようなケースにおいて、保険業者は、未使用マイルに対して以前に支払った、割高な保険料に対して、コストクレジット（cost credit）を付与するというオプションを有する。料率の見直しの有無にも、マイル当たりの料金についての変更の有無にも関わらず、有効期限日が設定されている実施形態においては、繰り越された未使用マイルに関して、新規保険契約の新規有効期限を獲得できるというメリットがある。図２５に示されるように、最後にステップ２５３２で新規保険証券が発行される。本実施形態では、ステップ２５３２で発行された新規保険証券は、任意の以前に発行された保険証券に優先する。このように、保険業者が本明細書に記載の方法を使用すれば、任意の一台の車には、１つの保険契約しか掛けられないことになる。

顧客が未使用マイルを更新の際に別の保険契約に繰り越す場合に加えて、売買、廃車、又はその他の方法で車両の入替がされた場合も、新規保険契約にマイルを繰り越すことができる。プロセスは、図２５に示されるものと同様である。顧客は自身のアカウントにログインし（ステップ２５１６）、オドメータ値を提供する（ステップ２５１８）。図２８の画面例は、売買又は何らかの方法で入替された保険車のオドメータ値を受け取るために使用できるインターフェースの一例である。ステップ２５２０で、残存する保険契約関連データが顧客に提示される。保険契約データの一部には変更がないので（例：氏名、誕生日）、図２９の画面例に示されるように、あらかじめ記載されている情報もある。この時点から、前述されたプロセスが実行される。これには、新規保険契約でカバーされる新規の車に対応する、少なくとも１つのオドメータ値を取得することが含まれる。未使用マイルは、以前に支払った料金と今回提示される料金の差額を支払うことで、新規保険契約に繰り越される。

契約期間内に保険契約が解除されると（被保険者又は保険業者によって）、なんらかの保険料の払い戻しが発生する場合がある。この場合、保険契約期間は、契約の履行から失効日までの期間（そのように規定されていれば）又は契約したマイルを走行し終えるまでの期間と考えられる。いくつかの実施形態では、保険業者による解約の場合を除いて、未使用マイルや未経過保険料に対する払戻金は発行されない。別の実施形態では、全額の払い戻しや、マイル当たりの料金の減額や、使用したマイルや保険契約の期限失効日を基に比例按分する等、別の取り決めも可能である。

次に図１４及び図１５を参照すると、別の実施形態において、走行距離を基にした保険契約のバリエーションが使用されている。例えば、走行距離を基にした保険契約のタイプとして、ピュア距離ベース保険（a pure distance-based policy）、ハイブリッド保険（hybrid policy）、調整型期間保険（an adjusted term policy）の３タイプがあげられる。ピュア距離ベース保険（一部が図１４に図示あり）は、契約の開始と終了がオドメータ値のみに基づいて決められる。この保険契約は保険車のオドメータ値が所定のバリューレンジにある間のみ有効である。ハイブリッド保険は、期間を基準とする総合車両補償と、距離を基準とする賠償責任/衝突車両補償が組み合わされている。総合車両補償の部分は、２つの日付で区切られて、保険契約期間が設定される。賠償責任/衝突車両補償の部分は、２つのオドメータ値で区切られて、保険契約距離が設定される。調整型期間保険（一部が図１５に図示あり）は、契約期間における実際の使用（例：走行距離に基づいて）に対して、年間のクレジット／デビットを付与する。クレジット／デビットは収集されたオドメータ値に基づく。顧客が、契約期間終了時に、契約で規定される走行距離を下回っている場合、未使用マイルの分のクレジットを保険料率で受け取ることになる。顧客が規定の走行距離を超過している場合は、超過分のデビットを保険料率で支払うことになる。

上記の実施形態は、オドメータ値の監査や検証が行われていないが、さまざまな手段が詐欺から保護するために実行されている。例えば、保険契約を購入する時点での契約希望者に対する加入審査（スクリーニング）、保険金支払請求時点でのオドメータ値に対する監査、及び保険金支払請求時点での全国規模の保険金支払請求に対する審査のうち、少なくとも１つが用いられる。こういった手段のいくつか又は全てが、上記に記載の実施例及びシステム２００で実行される。

保険契約を購入する時点での契約希望者に対する審査（例：運転免許証番号、ナンバープレート番号、クレジットカード）を用いて、保険業者は、契約希望者に関する多数の確認情報を収集する。その情報を車両登録記録、所有者記録、犯罪記録、登録住所、保険金請求データベース等でダブルチェックすることにより、保険証券の発行を控える必要を示す矛盾点や他の「目印」(“flag”：注目すべき箇所)が確認される。いくつかの実施形態では、このような目印が発見されると、その契約希望者に対して保険業者と連絡をとるよう要求するか、又は保険業者に対してカスタマーサポート係りに契約希望者と連絡をとるよう通知する結果となる。

保険金支払請求時点でのオドメータ値に対する監査には、公的及び私的データベース（車両登録、排ガス検査、オイルサービス、所有者報告等）でのチェックを含む。例えば、対象車に事故歴があれば、担当した警察官がオドメータ値を記録している。対象車が修理工場に送られていれば、その業者がオドメータ値を記録している。オドメータ値の記録に不審な点があれば、保険金支払請求は受理されないか又は調査の対象とされる。

保険金支払請求時点での、全国規模の保険金請求に対する審査は、販売時点での保険契約希望者／保険金支払請求の審査の代わりに用いられるか、又はそれと併用される。例えば、保険業者は全ての保険金支払請求を、専門業者による詐欺発見及び防止データベースサービス（fraud discovery and prevention database services）でスクリーニングする。

次に図２３を参照すると、エンティティ関係図によって、オドメータ値のデータを格納するシステムの一実施形態が示される。図２３は、上述した多様な情報源からの多様なオドメータ値を区別を実行する方法にも対応している。別の実施形態は、異なる実行方法で構成されるが、図２３に示すように、多くのオドメータ値がそれぞれの車及び／又はアカウントのために取得及び格納される。このデータは、１又は複数の電子データベースに格納され、そのデータベースは例えば図２のようなシステムの一部となっている。

一実施形態では、１つのオドメータ値に関する記録は、そのトランザクション又は読み取りに対して一意の識別子を提供する。そのオドメータ値に対応する車の照会、関連するアカウントの照会、走行距離や別の距離に関する記録、タイムスタンプ、情報源すなわち信頼度が、その記録の一部を形成する。
上述したように、オドメータ値は複数の情報源から収集されている。ある情報源からのオドメータ値が、別の所からの値よりも信頼性があることもある。例えば、公式な車検によるオドメータ値は、顧客から提供された値よりも信頼性が高い。従って、一実施形態では各オドメータ値が信頼度と関連付けられている。この信頼度はまた、上述したオドメータ値の記録に関連付けられたり記録されたりする。

一実施形態では、オドメータ値は、信頼できるか信頼できないかを主たる基準として識別されている。信頼できるタイプの値であるか信頼できないタイプの値であるかもまた、判断及び／又は格納される。例えば、保険契約の見積りのために顧客から提供された値は、「信頼できない−見積り」と分類される。解約のための値は、「信頼できない−解約」となる。「信頼できない−下取り」は、自分の車を下取りに出した顧客から提供された値と関連づけられる。

値の多くは、少なくとも最初は信頼できないタイプの値である。保険証券の発行、保険契約期間の設定、払戻金の発行、保険金の支払い等の行為は、信頼できるオドメータ値を必要とする場合の例である。ある種の信頼できない値が、信頼できる値に変わる場合もある。例えば、「信頼できない−見積り」のオドメータ値が、保険証券が発行されると「信頼できる−購入」のオドメータ値になる。この時点で、「信頼できない−見積り」の値を信頼できる分類に昇格することに関しては、なんらかの安全対策（セーフガード）が存在する。例えば、消費者は、提供した値が正確であると証明する法的拘束力のある保険契約を結んでいる必要がある。別のタイプの信頼できる値には、以下に詳細される「信頼できる−自己申告」及び「信頼できる−検証済-データベース」の値を含む。

「信頼できる−検証済−データベース」の値は、信頼できるデータベースで確認されたオドメータ値である。例えば、車両関連を扱う部局（ＤＭＶ）のデータベースによる、売買時における車の走行距離の表示は、信頼できるオドメータ値である。保険金支払請求が行われた際に保険査定員によって記録される値は、それが支払いの基準となるので信頼できる値である。

本発明における走行距離を基にした保険の実施において、車内にモニタ装置を用いる必要はない顧客が改竄したオドメータ値の情報によって、経済的な恩恵を受けようとする場合は、確認されたオドメータ値が要求される。例えば、車が下取りに出されるか、又は保険契約が解除される時（それぞれ「信頼できない−下取り」、「信頼できない−解約」の値に対応する）、顧客は、実際より少なく走行距離を報告することで、金融利益を得ようとする可能性がある。払戻金が発行されたり、保険金が支払われたりする前に、信頼できる値を要求することで、保険業者は走行距離を基にした保険に対する詐欺から保護される。信頼できるオドメータ値は、多くの場合は法的書類、保証書(warranties)、又は金銭上の約因と関連している。

任意のオドメータ値は、任意のデータベースに入力又は格納される前又は保険業者によって使用される前に、有効化される必要がある。オドメータ値が入力されると、ポジティブ数であることを保証するために又は数字の範囲が妥当かを確かめるために、チェックされる。例えば、新車は走行距離が少ないはずであるし、５年たった車が走行距離１０，０００マイル以下というのは珍しい。いくつかの例では、有効化に失敗したオドメータ値は、人間のオペレータによって無効化される。

オドメータ値は車両識別番号（ＶＩＮ）及び／又は保険証券番号と関連付けられている。任意の提供されたオドメータ値は、その値が妥当であると保証するために、内部及び／又は外部のデータベースに対してチェックされることでさらに有効とされる。例えば、すでにＤＭＶに報告あるいは記録された値よりも低いオドメータ値は使用されない。また、顧客が、同じ車に対して、以前報告していた値よりも低いオドメータ値を提供することはできない。チェックは、車歴や走行距離の情報を提供する民間すなわち第三者のデータベースに対しても実行される。

次に図２４を参照すると、顧客が自己申告のオドメータ値を入力できるようにするシステム機能に対応するスクリーンショットの例が示されている。これは、例えば図２のシステムや別の適宜のシステムで実行が可能である。図２４のスクリーンショットにおいて、顧客は自己申告のオドメータ値を提供できる。この方法で取得された値は、「信頼できる−自己申告」と表示される。一実施形態では、「信頼できる−自己申告」の値は、本発明によるシステム及び方法によって保険を掛けられている車の走行距離を追跡するために、既存の顧客から提供される。

「信頼できる−自己申告」の値は、上述したように、有効化が必要である。 該値は自己申告で顧客のみによって提供されたものであっても、信頼できる値と称される。なぜならば、顧客が実際より少なく走行距離を報告するインセンティブを有するような、任意の金融取引の基準値として、保険業者がこの値を使用することはないからである。例えば、「信頼できる−自己申告」の値は、顧客の保険契約が失効に近づいた時に、リマインダ通知を生成するために利用される。いくつかの実施形態では、顧客から提供される自己申告の値の数が制限されている。（例：２４時間につき１つ以下）。

「信頼できる−自己申告」の値は、更新時に顧客が購入する必要があるマイル数を、より正確に推定するためにも利用される。多数のオドメータ値が収集されるにつれて、保険業者は、特定の顧客が必要とするマイル数における季節による変化を予測することも可能になる。例えば、ある顧客が夏季により多くのマイル数を走行しているとする。この情報は、更新時期に顧客にもフィードバックされ、次回の保険購入に関して、顧客が充分な情報を得た上で決断できるようにする。

「信頼できる−自己申告」の値は、本発明の範囲において別の利用例を見出すこともできる。例えば、「信頼できる−自己申告」の値は所定の保険契約における既経過保険料のマイル数を追跡することにも利用できる。詐欺の検出にも応用できる。例えば、１又は複数の「信頼できる−自己申告」の値が、外部情源からの確認済みの値を下回っていれば、顧客は意図的に走行距離を実際より少なく報告したことになる。上述したように、「信頼できる−自己申告」の値は、払戻金や保険金の支払いの基準値としては使用されない。しかしながら、不正確な「信頼できる−自己申告」の値によって、保険業者は顧客が誠実な対応をしていないことがわかる。「信頼できる−自己申告」の値の効用を向上させるために、顧客が図２又は同様のシステムを利用して支払いをする度に、このような値を要求することができる。

次に図１６を参照すると、走行距離に基づく自動車保険の査定、価格の設定、及び提供をするための別の方法に係る一実施形態のフロー図が示されている。図１７〜２２も参照すると、これらは、図２のシステム又は本発明に係る別のシステムによって実行される多様なディスプレィを示す画面例である。ステップ１６１０で、顧客情報が顧客によって提供される。次に図１７も参照すると、顧客情報には名前、苗字、誕生日、性別、州及びＺＩＰコードなどの多数の品目が含まれている。運転者の情報に加えて、車両の情報もステップ１６１０で収集される。車両情報には、車両識別番号及び現在のオドメータ値が含まれる。本実施形態では、車両識別番号がナンバープレート番号の代わりに用いられる。本実施形態において、上記の顧客情報は、前述された運転免許証番号及び関連するデータベースの代わりに使用される。

ステップ１６１０でオドメータ値が提供される度に、内部又は外部データベースに対して整合性がチェックされる。内部データベースは、保険査定員、車検、別の信頼できる情報源等からの、信頼できるオドメータ値に基づいて維持されている。いくつかの実施形態では、可能であれば車両識別番号又はナンバープレート番号をキーとして使用して、オドメータ値が第三者のデータベースに対してチェックされる。顧客から提供されたオドメータ値が、既知であり且つ／又は信頼できるデータによれば不可能である場合、顧客は正確なオドメータ値を入力する機会を再び与えられ、また、偽りのオドメータ値による任意の保険契約は無効になることが警告される。現在の保険契約の開始及び終了点（例：走行距離）は、顧客による正確なオドメータ値の入力を待つ間に、車の現在の走行距離に関する既知の情報を反映させるためにアップデートされる。別の実施形態では、１又は複数の偽りであると判明したオドメータ値を提供した顧客は、ブラックリストに掲載され、保険契約を結ぶことは一切できなくなる。

図１７から、さらに、顧客が対象車に対して追加的な運転手を追加するオプションを有することが理解される。図１６のステップ１６１２に示されるように、該システムは、顧客によって選択された入力に基づいて、追加的な運転者が保険でカバーされるかどうかを判断する。追加的な運転者が入力されると、該プロセスはステップ１６１３に進み、追加的な運転者の情報が入力される。本実施形態では、追加的な運転者の情報が提供される場合、追加的な情報は入力済の車両識別番号及びオドメータ値に対応している必要がある。上記プロセスは、ステップ１６１２に戻り、追加的な運転者がカバーされるべきかを判断する。

ステップ１６１２で追加的な運転者の全員の情報が入力されるか、又は運転者が一人のみであれば、ステップ１６１４で顧客は補償額を選択する。ここで図１８も参照すると、多数の基本的な補償の選択肢が顧客に提示されている。前述したように、提示される料金は、選択した賠償責任補償の限度、及び保険でカバーされる車及び運転者に対応しており、アクチュアリアルによる方式に基づいている。図１８で示される基本的な補償に加えて、他の補償内容も顧客は選択できる。これらの追加的な保険には、物的損害、レッカー移動及びレンタカー、無保険運転者、人身傷害補償が含まれているが、それに限定するものではない。図１８に示されるように、基本的な補償及び追加的な補償のそれぞれについて、距離単位当たりの料金が記されている。さらに、保険契約の管理に対する契約手数料が距離単位当たりで算出される。本実施形態では、契約手数料の料率は、他の保険の選択肢と一緒に提示され、合計金額に含まれることになる。

ステップ１６１６において、顧客は現時点で購入を希望する保険のマイル数を選択する。ここで図１９も参照すると、マイル（距離単位）当たりの合計金額が表示される。これは前で選択された保険の合計金額に契約手数料を加えたものに対応している。本実施形態では、顧客は補償のマイルの購入の際に、１，０００から６，０００のレンジにおいて１，０００単位で購入するよう制限されている。別の実施形態では、顧客はより多くのマイルを購入したり、より少ないマイルを購入することも可能であるし、また顧客が必要なマイル数を選択することも可能である。

さらに図１９に示されるように、本実施形態による保険契約では有効期限日を提供している。一実施形態では、有効期限日は購入日から６ヶ月であるが、別の実施形態では、別の有効期間であってもよい。上述したように、全ての実施形態で有効期限日のある保険契約を提供するわけではない。図１９には示されていないが、いくつかの実施形態では、以前の一月当たりの走行距離データ等の追加的な情報を画面上で提供している。購入するマイル数が、顧客の現在の保険期間に適していると推測されるかを示す予測も提供される。徐々に、この予測の少なくとも一部は、前述した「信頼できる−自己申告」の値に基づくようになる。また、車検機関や販売及び所有権の記録等の、第三者からの別の値に基づく予測も可能である。民間のデータベースを含む第三者のデータベースも、必要となるマイル数を推定するために用いられる。

ステップ１６１８において、図２０に示されるような１又は複数の確認ページ（画面）が顧客に提供される。図２０は確認画面の一例であって、別の形式や表示であってもよい。確認画面に現れる情報には、被保険者及び被保険車両、顧客が選択した現在の補償内容及び制限、マイル当たりの料金で示される保険料率、顧客が選択した購入予定マイルの総数、及び保険契約の総費用が含まれるが、これらに限定するわけではない。確認画面では、保険契約期間もまた判断すなわち確定される。いくつかの実施形態では、顧客は特定の補償内容に対して、申込をしない場合は電子的にイニシャルで署名をするが必要となる。図２０の例では、顧客は人身傷害補償を申し込まないことに対して、イニシャルで署名することが求められる。また、図２０に示されるように、対象車に先取特権者が関係しているか否かを記す必要がある。関係しているならば、追加のフォーム（不図示）に顧客は先取特権者の情報を入力する必要がある。

ステップ１６１８における確認に続いて、ステップ１６２０において、図２１に示されるように表明・保証条項が提供される。この時点で、多数の言明、表明、保証及び／又は他の声明が、顧客には必要となる。図２１に示されるように、このような案件や声明には、特定の州の免許や、刑事責任、走行中の交通違反、被保険車の用途、及び別のデータ等が含まれる。顧客は、図２１に示されるように、提示された全ての情報を注意深く読んだ後に電子的に書面にイニシャル署名をするよう要求され、そうすることで記載の事実の全てを表明及び保証することになる。

別の実施形態では、ステップ１６２０の表明・保証条項の一部として、オドメータ値が要求される。該オドメータ値は、ステップ１６１０のオドメータ値に追加されるか、又は代わりにとなる。ここで要求されるオドメータ値は、前述した、最初の「信頼できる−自己申告」の値である。顧客から提供された全てのオドメータ値と同様に、ステップ１６２０で表明・保証条項の一部として提供されるオドメータ値も、内部又は外部のデータベースに対してチェックされる。別の実施形態では、ステップ１６２０ではオドメータ値が提供されずに、ステップ１６１０で取得した値がこの時点で検証される。

前述のように、既知であり且つ／又は信頼できるデータによれば不可能であるオドメータ値を顧客が提供した場合、顧客は正しいオドメータ値を入力する機会を再び与えられ、また、偽りのオドメータ値による任意の保険契約は無効になることが警告される。現在の保険契約の開始及び終了点（例：走行距離）は、顧客による正確なオドメータ値の入力を待つ間に、車の現在の走行距離に関する既知の情報を反映させるためにアップデートされる。いくつかの実施形態では、１又は複数の偽りであると判明したオドメータ値を提供した顧客は、ブラックリストに掲載され、保険契約の提供は一切行われなくなる。

ステップ１６２０の表明・保証条項に続いて、ステップ１６２２では、課金データが顧客から提供される。ここで図２２も参照すると、課金情報を入力するフォームの一例が示されている。ご覧のように、クレジットカード番号及び該カードの請求先住所が提供される。別の実施形態では、当座預金口座からの振替等の別の支払方法が用いられる。本実施形態では、このステップにおいて、存在する保険の要求事項を満たすために、対象車のための実際の駐車場住所を入力する。保険契約は以前に取得されている情報（例：ＺＩＰコード）のみで見積もられるが、それでも顧客は実際の所在地住所の入力を要求される。任意の被保険車の駐車場住所は、保険契約を車両の住所に拘束するために要求される。ステップ１６２２での課金データの入力に続いて、ステップ１６２４で、州法によって要求されるように、賠償責任の保険証券を印刷するオプションを選択できる。別の実施形態では、顧客は賠償責任の保険証券を自分の住所に郵送してもらうように要求することもできる。

本発明によるシステム及び方法の多様な実施形態を利用することで、保険が走行距離を基にして提供され、それに加えて有効期限を考慮にいれる保険も、考慮に入れない保険も提供できる。いくつかの実施形態では、保険会社及び保険業界における他の提供者が既経過保険料及び他の料金を算出する方法に対して該システム及び方法が、どのような影響を与えるかも考慮している。

算出方法の一例によると、保険料は保険業者が保険契約に基づいて収集する収入であり、手数料の正味は別のカテゴリーに分類される（例：契約手数料、防犯登録料（theft fee）等）保険業界では、保険料は、保険業者が被保険者に代わって引き受けるリスクと関連付けられる。保険料と関連するリスクが負担された時に、保険料は「既経過」となる。同様に、保険料と関連するリスクが保険業者によって負担されるまでは、保険料は「未経過」である。実際には保険料の全てが既経過になる前に、保険料の全額が既に収集されている場合もある。保険料が収集されても未経過である場合は、解約時に顧客は未経過保険料の払戻しを受ける権利を有する時もある（おそらく、正味の解約手数料や最低既経過保険料要件（minimum earned premium requirement）に従って）。

既経過保険料を追跡することは、前述したリマインダ通知を生成するためにはとりわけ重要である。リマインダ通知の生成及び発送は、既経過保険料又は保険契約に残存する未経過保険料の金額と結び付けられている。既経過(earned)／未経過(unearned)保険料がトリガポイントに到達すると、顧客は自分の保険契約すなわち補償の失効が近いことを通知される。一例を挙げると、３０日分又は５００マイル分の未経過保険料しか残存していない場合、紙の又は電子的な通知が顧客に発送される。同様に、全ての保険料が既経過保険料になると、顧客は補償範囲が終了したことを通知される。

ここで図３０を参照すると、複数の既経過保険料記録の可能な関係を示す図が示されている。一実施形態では、保険業者が既経過保険料を査定する必要があると判断すると、その度に既経過保険料記録がデータベースに生成される。例えば、これは図２のデータベース２２４である。図３０に示されるように、各保険契約は保険料総額を有しており、これは以前の既経過保険料記録に未経過保険料を加えたものである。保険業者が所定の保険契約に対する保険料総額を超える既経過保険料を請求することは通常できない。未経過保険料は保険料総額からデータベースにある全ての既経過保険料記録の合計を差し引いた金額と定義される。

一実施形態では、既経過保険料は、既経過保険料を算出する２つの別個の方法で大きい値となった方と定義される。第１の方法では、保険契約開始からの経過日数の合計（被除数）が保険契約で購入した補償日数の合計（除数）で除算される。算出された商は、保険料総額で積算されて、時間計算を基にして既経過保険料が求められる。すなわち、既経過保険料＝経過日数／契約日数×保険料総額となる。既経過保険料を算出する第２の方法は、走行マイル数（被除数）を所定の保険契約のために購入したマイル数（除数）で除算することで達成される。算出された商は、次に保険料総額で積算されて、走行距離を基にして既経過保険料が求められる。すなわち、既経過保険料＝走行マイル数／購入マイル数×保険料総額となる。なお、走行距離を基にして既経過保険料を算出するには、検証されたオドメータ値が必要となる。

ここで図３１を参照すると、エンティティ関係図によって、既経過保険料のデータを格納する方法の一つが示される。図３１で示されるように、１つの保険契約が複数の既経過保険料記録を有する。既経過保険料記録は関係するデータベースに格納され、既経過保険料記録ＩＤ、保険契約ＩＤ、金額、既経過保険料記録がいつ生成されたかを反映するタイムスタンプを含む、複数のフィールドを有する。別の実施形態では、既経過保険料記録に含まれる情報が、本明細書に記載されているものと相異していてもよい。

図３１に示されるように、各保険契約が複数の手数料に関する事柄すなわち手数料記録を有する。一実施形態では、手数料は既経過保険料に基づいて算出される。手数料記録は既経過保険料記録から直接的に生成される。売上手数料の金額は、既経過保険料記録にある対応する既経過保険料の金額に基づいている。

ここで図３２を参照すると、既経過保険料の算出を実行する方法例を示すフロー図が示されている。一実施形態では、保険契約の既経過保険料を算出するためのプロセスが毎日実行される。しかしながら、１又は複数日の間、既経過保険料の算出を実行しないことも可能である。従って、ステップ３２１０では、最後の既経過保険料の算出からの経過日数が計算される。いくつかの実施形態では、安全対策（セーフガード）として、最後の既経過保険料の算出から少なくとも一日は経過しているかがステップ３２１２で判断される。ステップ３２１２では、日数がゼロ以下ならば、本保険契約に対する既経過保険料の算出が実行されてから一日が経過していないので、別の既経過保険料の算出は必要とされないという事実を反映して、プロセスを終了する。本実施形態では、既経過保険料は経過日数を基に算出されるので、既経過保険料の算出は、一日に一回以上は実行されない。しかしながら、別の実施形態では、既経過保険料は一日一回よりも頻度を多くすることも少なくすることも可能であり、そして同じことが図３２で概略されるプロセスにも反映される。

ステップ３２１２で最後の既経過保険料の算出から少なくとも一日が経過していることが判断されると、プロセスは３２１４に進み、日割りの保険料が計算される。日割りの保険料は、所定の保険契約において、一日に経過した保険料の金額と定義される。一実施形態では、保険契約に対する保険料総額を保険契約期間の日数で除算することで計算される。ステップ３２１６で、日割り保険料は最後の既経過保険料の算出から経過した日数で積算されて、算出された現時点の保険料となる。しかしながら、前述したように、既経過保険料合計が、所定の保険契約で既経過にできる保険料の金額を超過することは決してない。従って、ステップ３２１８では、残存する保険料が判断される。一実施形態では、残存の保険料は所定の保険契約に対する保険料総額から既経過保険料を差し引いた金額と定義される。この情報は、データベースに格納されている既経過保険料記録に基づいて計算される。

ステップ３２２０では、ステップ３２１６で計算された現時点の保険料の方が、ステップ３２１８で判断された残存の保険料よりも大きい値かどうかが判断される。ステップ３２２２で示すように、現時点の保険料算出値の方が残存の保険料よりも小さい値の場合には現時点の保険料算出値が用いられる。しかしながら、現時点の保険料算出値の方が、残存の保険料よりも大きい値の場合、ステップ３２２４で示すように、残存の保険料が査定の対象の上限となる。ステップ３２２２又は３２２４に続いて、ステップ３２２６で既経過保険料記録が生成され、手数料が算出される。

既経過保険料記録に関する一実施形態が前述されたが、既経過保険料記録はユーザ及び該システムの特定のニーズに答えられるよう構成されてもよい。手数料の算出は、既経過保険料の算出を直接的に基準としている。例えば、手数料は既経過保険料の割合に基づくとすると、その場合は既経過保険料の算出による金額が手数料の割合で積算されて、手数料金額となる。この金額は、図３１で示されたように、手数料記録に記録される。

次に図３３を参照すると、既経過保険料の算出を実行する別の方法例を示すフロー図が示されている。図３３の方法は、一実施形態においては、購入時又はオドメータ値の取得による既経過保険料の算出に対応する。このプロセスは、図３１に関する記載であって、オドメータ値又は別の出来事によって既経過保険料の算出がトリガされるかとは無関係に日割り保険料の算出を反映するものとは対照をなしている。一実施形態では、図３３の既経過保険料の算出は、オドメータ値が取得される度に実行される。別の実施形態では、検証済みのオドメータ値が取得された時のみ、このプロセスがトリガされる。一実施形態では、保険業者は、走行したマイル数に関連する保険料及び経過した期間に関連する保険料のうち、いずれか大きい値の方を取得する。

まず、ステップ３３１０で、所定の保険契約で未経過保険料が残存するか否かが判断される。未経過保険料が残存しなければ、経過する保険料の最大値は保険契約に対して支払われた保険料総額であるので、プロセスは終了する。未経過保険料が残存するなら、プロセスはステップ３３１２にすすみ、期間を基にした既経過保険料の算出が実行される。前述のように、これは最後の既経過保険料の算出からの経過日数（被除数）を、保険契約期間の総日数（除数）で除算し、算出された商を保険料総額で積算することで計算される。

次のステップ３３１４で、走行距離を基にした算出が実行される。前述のように、走行距離を基にした既経過保険料の算出は、オドメータ値から読み取れる（例：最後にチェックされたオドメータ値以降の）走行したマイル数（被除数）を、保険契約において購入した総マイル数（除数）で除算することで計算される。算出された商は、保険契約に対する保険料総額で積算されて、走行距離を基にした既経過保険料となる。

この時点では、２つの既経過保険料の算出が実行されている。１つはステップ３３１２における経過した期間に基づく算出で、１つはステップ３３１４における走行したマイル数に基づく算出である。場合によっては、この２つの算出の結果が異なることがある。従って、ステップ３３１６では、走行距離による算出結果が期間による算出結果より大きいかを判断する。走行距離による算出結果の方が大きい値の場合は、この値が既経過保険料として以降のステップでは使用され、ステップ３３１８に進む。しかしながら、期間による算出結果の方が大きい値の場合は、この値が以降のステップでは使用され、ステップ３３２０に進む。

前述の実施形態にあるように、いずれの計算方法でも、保険業者は所定の保険契約で規定された保険料以上の金額を請求することはできない。従って、ステップ３３２２では、ステップ３３１６で選択された保険料の金額が、保険契約において残存している未経過保険料の合計を上回っているか否かが判断される。算出された既経過保険料が、保険契約に対する未経過保険料を上回っていれば、ステップ３３２４で、残存の保険料を査定する必要がある。しかしながら、算出された既経過保険料が未経過保険料を下回っていれば、ステップ３３２４を省略して次のステップ３３２６に進み、既経過保険料記録を生成し、且つ手数料を算出する。その結果、既経過保険料記録及び可能であれば手数料記録が生成される。

一実施形態では、既経過保険料に関して、期間による算出と距離による算出の両方が一定間隔（例：毎日）で繰り返されるか、又は特定のイベント（例：オドメータ値の取得）が発生した時に繰り返される。既経過保険料は負担されるリスクと関連しているので、任意の以前に行われた既経過保険料の査定を考慮に入れて、既経過保険料が実際には負担されていないリスクに対して査定されたものでないことを確かめる必要がある。つまり、保険契約下における総走行距離又は総経過時間に基づいて査定された既経過保険料は、保険契約に対して以前に実行された既経過保険料の全査定の合計によって、低減される必要がある。おなじ保険契約上で、距離ベース及び時間ベースの既経過保険料の算出の両方が査定されるが、既経過保険料の全査定の合計は、今日まで負担したリスクに基づいて既経過にできる保険料の合計を超過することはできない。いくつかの実施形態では、今日までに負担したリスクは経過した期間及び走行したマイルのいずれか一方に基づいている。

同様のルールに従って手数料も算出されるので、既経過保険料に基づく手数料は、所定の保険契約で獲得できる手数料の合計を超過することはない。

いくつかの実施形態が先行する記述で示されたが、本発明の精神及び範囲から逸脱することなく、形式及び詳細における多様な変更を行うことができることが、当業者には理解されるであろう。例えば、本明細書に記載した方法における多様なステップは、異なる順序で実行されてもよいし、あるいは、連続して、組み合わせて、さらに分割して、代替となるステップで置き換えて、又は完全に削除して実行することもできる。加えて、本発明の明細書に記載の方法や記述において示された多様な機能は、追加的かつ／又は代替となる機能を提供できるように組み合わせて構成されてもよい。記述されたように、各方法におけるいくつかの又は全てのステップは、コンピュータで実行可能なソフトウェアインストラクションという形式で実行される。さらに、該ソフトウェアインストラクションは、多くの異なるクライアントとアクセス可能なサーバに位置することも、一人のユーザが使用可能な１つのコンピュータに位置することも、違う場所に位置することも可能である。それゆえ、特許請求の範囲は、本発明の開示に従いながら、広義で解釈される必要がある。本発明を開示するために、多様な実施形態が説明されたが、幾多の変更及び修正が当業者には明白であろう。そのような変更及び修正は、本明細書における特許請求の範囲で定義される本発明の技術的思想に包含される。

Claims (20)

1. 自動車保険契約の既経過保険料を査定するシステムにおいて、該システムは、
   プロセッサで実行可能なインストラクションであって、
   保険契約の開始から経過した距離単位の、保険契約によって保険がかけられている距離単位に対する比率を基にして、第１の既経過保険料を判断し、
   保険契約の開始から経過した時間単位の、保険契約が有効である時間単位に対する比率を基にして、第２の既経過保険料を判断し、
   少なくとも第１の既経過保険料及び第２の既経過保険料の間で、最大となる既経過保険料を判断する
   ためのインストラクションを記憶したメモリと、
   該メモリに記憶されたインストラクションを実行するプロセッサと
   を備えていることを特徴とするシステム。
2. 請求項１記載のシステムにおいて、最大となる既経過保険料を判断するためのプロセッサで実行可能なインストラクションは、少なくとも第１の既経過保険料、第２の既経過保険料、及び最大許容既経過保険料の間で、最大となる既経過保険料を判断するためのプロセッサで実行可能なインストラクションであり、最大許容既経過保険料は、保険契約のための保険料総額から任意の以前の既経過保険料査定の合計金額を差し引いた料金であることを特徴とするシステム。
3. 請求項１記載のシステムにおいて、該システムはさらに、判断された最大となる既経過保険料を格納するための、関係データベースを備えていることを特徴とするシステム。
4. 請求項１記載のシステムにおいて、メモリはさらに、最大となる既経過保険料の割合に応じて手数料を判断するための、プロセッサで実行可能なインストラクションを含むことを特徴とするシステム。
5. 請求項１記載のシステムはさらに、該保険契約で保険がかけられる車両のオドメータ値を取得するための手段を備え、該オドメータ値は第１の既経過保険料の算出に用いられることを特徴とするシステム。
6. 既経過保険料を算出する方法において、該方法は、
   契約開始からの、事前に選択された距離単位数に対する補償内容によって部分的には定義される保険契約の保険期間に対して、顧客に保険料を請求するステップと、
   契約開始から経過した距離単位数を判断するステップと、
   経過した距離単位の、該保険契約で保険がかけられている距離単位に対する比率に基づいて、請求された保険料に対する既経過保険料を査定するステップと
   を備えることを特徴とする方法。
7. 請求項６記載の方法において、該方法はさらに、既経過保険料の割合に応じて、売上手数料を算出するステップを具えることを特徴とする方法。
8. 請求項７記載の方法において、該方法ははさらに、売上手数料を関係データベース記録に格納するステップを備えることを特徴とする方法。
9. 請求項６記載の方法において、該方法はさらに、既経過保険料を関係データベースに格納するステップを備えることを特徴とする。
10. 請求項６記載の方法において、該方法はさらに、最後の既経過保険料請求から経過した距離単位の、該保険契約で保険がかけられている距離単位に対する比率に基づいて、請求された保険料に対する第２の既経過保険料を請求するステップを備えることを特徴とする方法。
11. 請求項６記載の方法において、該方法はさらに、既経過保険料の査定に先立ち、既経過保険料の方が該保険契約の下で獲得可能な未経過保険料よりも少ないことを確認するステップを備えることを特徴とする方法。
12. 請求項６記載の方法において、経過した距離単位は、保険契約で保険がかけられる車両のオドメータ値を用いて判断されることを特徴とする方法。
13. 請求項１２記載の方法において、オドメータ値は、公的な州文書によって確認され、公的な文書は現存の保険契約と一致している特定の車両の、売買、下取り、又は廃車の１つに対応していることを特徴とする方法。
14. 自動車保険契約の既経過保険料を査定する方法において、該方法は、
    保険契約の開始から経過した距離単位の、保険契約によって保険がかけられている距離単位に対する比率を基にして、第１の既経過保険料を判断するステップと、
    保険契約の開始から経過した時間単位の、保険契約が有効である時間単位に対する比率を基にして、第２の既経過保険料を判断するステップと、
    少なくとも第１の既経過保険料及び第２の既経過保険料の間で、最大となる既経過保険料を判断するステップと、
    保険契約に対する最大既経過保険料を査定するステップと
    を備えることを特徴とする方法。
15. 請求項１４記載の方法において、最大となる既経過保険料を判断するステップはさらに、少なくとも第１の既経過保険料、第２の既経過保険料、及び残存する未経過保険料の間で、最大となる既経過保険料を判断するステップを備えることを特徴とする方法。
16. 請求項１５記載の方法において、残存する未経過保険料は、保険契約のための保険料総額から任意の以前の既経過保険料査定の合計金額を差し引いた料金であることを特徴とする方法。
17. 請求項１４記載の方法において、該方法はさらに、関係データベースに既経過保険料記録を生成するステップを備え、既経過保険料記録は、少なくとも最大既経過保険料を含むことを特徴とする方法。
18. 請求項１４記載の方法において、該方法はさらに、最大既経過保険料の割合を基にして、売上手数料を算出するステップを備えることを特徴とする方法。
19. 請求項１８記載の方法において、該方法はさらに、関係データベースに売上手数料記録を生成するステップを備え、売上手数料記録は少なくとも算出された手数料を含むことを特徴とする方法。
20. 請求項１４記載の方法において、該方法はさらに、複数のオドメータ値を用いて、保険契約の開始から経過した距離単位を判断するステップを備えることを特徴とする方法。

Images