(57)【要約】【課題】交通事故防止のために運転者個々の特徴に合わせた適切な警告を行うための情報処理技術を提供すること。【解決手段】システム利用者の個別の特性であるユーザ属性を取得し、また、システム利用者の現在又は通行予定の位置情報を取得する。事故現場の位置情報と当該位置情報に関連付けられた事故当事者の属性情報とを含む交通事故情報データベースの情報を、システム利用者の現在又は通行予定の位置情報と取得されたユーザ属性とを用いて検索する。検索により交通事故情報が抽出された場合には、抽出された交通事故情報を絞込み情報記憶部に格納する。これにより、運転者個々の特徴に合わせた事故情報を抽出することが可能となる。【選択図】　図１
2004094444.tif 000002
【特許請求の範囲】
【請求項１】
交通事故防止のための情報処理方法であって、
システム利用者の個別の特性であるユーザ属性を取得し、記憶装置に格納するユーザ属性取得ステップと、
前記システム利用者の現在又は通行予定の位置情報を取得し、記憶装置に格納する位置情報取得ステップと、
事故現場の位置情報と当該位置情報に関連付けられた事故当事者の属性情報とを含む交通事故情報データベースの情報を、前記システム利用者の現在又は通行予定の位置情報と前記ユーザ属性とを用いて検索する検索ステップと、
前記検索により交通事故情報が抽出された場合には、当該抽出された交通事故情報を絞込み情報記憶部に格納するステップと、
を含む交通事故防止のための情報処理方法。
【請求項２】
車種情報と渋滞情報と気象情報と日時の情報とのうち少なくとも１つを取得し、記憶装置に格納するステップをさらに含み、
前記検索ステップにおいて前記車種情報と前記渋滞情報と前記気象情報と前記日時の情報とのうちの少なくとも１つをさらに用いて検索することを特徴とする請求項１記載の交通事故防止のための情報処理方法。
【請求項３】
前記絞込み情報記憶部に格納された情報を用いて警告メッセージを生成し、記憶装置に格納するステップをさらに含む請求項１又は２記載の交通事故防止のための情報処理方法。
【請求項４】
前記記憶装置に格納された警告メッセージを前記システム利用者の端末に送信するステップをさらに含む請求項３記載の交通事故防止のための情報処理方法。
【請求項５】
前記ユーザ属性取得ステップが、前記システム利用者の端末からユーザＩＤを受信した場合にはユーザ属性を登録してあるデータベースを前記ユーザＩＤを用いて検索して前記システム利用者のユーザ属性を抽出するステップを含む請求項１乃至４のいずれか１つ記載の交通事故防止のための情報処理方法。
【請求項６】
前記システム利用者がゲストユーザかどうか判断するステップをさらに含み、前記システム利用者がゲストユーザであると判断された場合には、前記ユーザ属性取得ステップにおいて、前記ユーザ属性として性別と年齢と免許年数とのうち少なくとも１つの情報を取得し記憶装置に格納することを特徴とする請求項１乃至４のいずれか１つ記載の交通事故防止のための情報処理方法。
【請求項７】
ナビゲーションシステムにより生成された目的地までのルート上における所定間隔の位置情報を前記位置情報取得ステップにおいて取得した場合には、前記検索ステップを前記取得した所定間隔の位置情報の各々について実行することを特徴とする請求項１又は２記載の交通事故防止のための情報処理方法。
【請求項８】
前記絞込み情報記憶部に格納されている交通事故情報により特定される危険位置を回避するように目的地までのルートを生成するステップをさらに含む請求項７記載の交通事故防止のための情報処理方法。
【請求項９】
請求項１乃至８のいずれか１つ記載の交通事故防止のための情報処理方法をコンピュータに実行させるためのプログラム。
【請求項１０】
交通事故防止のための情報処理装置であって、
システム利用者の個別の特性であるユーザ属性を取得し、記憶装置に格納する手段と、
前記システム利用者の現在又は通行予定の位置情報を取得し、記憶装置に格納する手段と、
事故現場の位置情報と当該位置情報に関連付けられた事故当事者の属性情報とを含む交通事故情報データベースの情報を、前記システム利用者の現在又は通行予定の位置情報と前記ユーザ属性とを用いて検索する手段と、
前記検索により交通事故情報が抽出された場合には、当該抽出された交通事故情報を絞込み情報記憶部に格納する手段と、
を有する交通事故防止のための情報処理装置。
【請求項１１】
事故現場の位置情報と当該位置情報に関連付けられた事故当事者の属性情報とを含む交通事故情報データベースと、
利用者の個別の特性であるユーザ属性を格納しているメモリカードから前記ユーザ属性を読出し、記憶装置に格納するメモリインタフェース手段と、
少なくとも現在の位置情報を取得し、記憶装置に格納する手段と、
前記交通事故情報データベースの情報を前記利用者の位置情報と前記ユーザ属性とを用いて検索する検索手段と、
前記検索手段により交通事故情報が抽出された場合には、当該抽出された交通事故情報を用いて警告メッセージを生成し、記憶装置に格納する手段と、
前記記憶装置に格納された警告メッセージを前記利用者に対して出力する手段と、
を有する車載機。
【発明の詳細な説明】
【０００１】
【発明が属する技術分野】
本発明は、交通事故防止のための情報の処理技術に関する。
【０００２】
【従来の技術】
例えば特開平１１−１２０４７８号公報には以下のような技術が開示されている。すなわち、交通事故の予測は、過去の履歴情報を交通事故管理センタのデータベースに蓄積しておき、逐次交信される車両情報（場所・地形・走行速度・交通量・季節・時刻・天候・温度・湿度等）とを比較・分析し、交通事故が起きる確率を算出し、状況に応じた警告情報（＝交通事故予測情報）を音声又は画像にて通知するようにし、交通事故の発生を未然に防ぐ。
【０００３】
交通事故に遭遇した場合は、警察官の現場検証の際に走行中の車両の履歴情報をＩＣカードの内容から読み取ることで、事故状況の把握が可能になる。その際に免許証情報とリンクさせることで、免許証点数の減点計算及び反則金・罰金の徴収、免許証点数等の運転資格の管理も可能とする。
【０００４】
【発明が解決しようとする課題】
一方で、交通事故の発生原因は、運転者の性別、年齢、運転免許保有日数等の運転者属性にも深く関連があり、適切な警告情報を提供するためには運転者属性を考慮する必要がある。しかしながら従来においては、車両の状況に加え、運転者属性に応じた交通事故危険情報を提供するという観点は示されていない。
【０００５】
従って本発明の目的は、交通事故防止のために運転者個々の特徴に合わせた適切な警告を行うための情報処理技術を提供することである。
【０００６】
【課題を解決するための手段】
本発明の第１の態様に係る、交通事故防止のための情報処理方法は、システム利用者の個別の特性であるユーザ属性を取得し、記憶装置に格納するユーザ属性取得ステップと、システム利用者の現在又は通行予定の位置情報を取得し、記憶装置に格納する位置情報取得ステップと、事故現場の位置情報と当該位置情報に関連付けられた事故当事者の属性情報とを含む交通事故情報データベースの情報を、システム利用者の現在又は通行予定の位置情報と取得されたユーザ属性とを用いて検索する検索ステップと、検索により交通事故情報が抽出された場合には、抽出された交通事故情報を絞込み情報記憶部に格納するステップとを含む。これにより、システム利用者毎に当該システム利用者に適合した交通事故に関連する情報の取得・提供が可能となる。
【０００７】
また、本発明の第１の態様において、車種情報と渋滞情報と気象情報と日時の情報とのうち少なくとも１つを取得し、記憶装置に格納するステップをさらに含み、上で述べた検索ステップにおいて車種情報と渋滞情報と気象情報と日時の情報とのうちの少なくとも１つをさらに用いて検索するような構成であってもよい。ユーザ属性に加えて車両の状況や環境を考慮した検索を行うことにより、より確度の高い事故の可能性を示す情報の取得・提供が可能となる。
【０００８】
また、本発明の第１の態様において、上で述べた絞込み情報記憶部に格納された情報を用いて警告メッセージを生成し、記憶装置に格納するステップをさらに含むような構成であってもよい。よりわかりやすく簡潔なメッセージにより、事故を回避させることができるようになる。
【０００９】
さらに、上で述べた記憶装置に格納された警告メッセージをシステム利用者の端末に送信するステップを含むような構成であってもよい。このようにシステム利用者から離れたサーバにおいて検索処理を行うような構成の他、システム利用者の保持する又はシステム利用者の車両に備えられた機器において検索処理を行ってもよい。
【００１０】
また、本発明の第１の態様において、上で述べたユーザ属性取得ステップが、システム利用者の端末からユーザＩＤを受信した場合には、ユーザ属性を登録してあるデータベースをユーザＩＤを用いて検索してシステム利用者のユーザ属性を抽出するステップを含むような構成であってもよい。毎回全てのユーザ属性を送信する必要がなくなり、通信処理が効率的になる。また一方で、毎回全てのユーザ属性を送信するような構成であってもよく、この場合にはユーザ属性の抽出処理を省略できる。
【００１１】
また、本発明の第１の態様において、システム利用者がゲストユーザかどうか判断するステップをさらに含み、システム利用者がゲストユーザであると判断された場合には、上で述べたユーザ属性取得ステップにおいて、ユーザ属性として性別と年齢と免許年数とのうち少なくとも１つの情報を取得し記憶装置に格納するような構成であってもよい。例えば利用頻度が少ないゲストユーザが利用する場合には、より少ないユーザ属性情報での処理が可能となる。
【００１２】
また、本発明の第１の態様において、ナビゲーションシステムにより生成された目的地までのルート上における所定間隔の位置情報を上で述べた位置情報取得ステップにおいて取得した場合には、上で述べた検索ステップを、取得した所定間隔の位置情報の各々について実行するような構成であってもよい。生成されたルート上の危険位置が特定可能となる。
【００１３】
さらに、上で述べた絞込み情報記憶部に格納されている交通事故情報により特定される危険位置を回避するように目的地までのルートを生成するステップを含むような構成であってもよい。システム利用者は、再生成されたルートに従うことによって、交通事故に遭遇する可能性の少ない道を通って目的地に向かうことが可能となる。
【００１４】
本発明の第２の態様に係る車載機は、事故現場の位置情報と当該位置情報に関連付けられた事故当事者の属性情報とを含む交通事故情報データベースと、利用者の個別の特性であるユーザ属性を格納しているメモリカードからユーザ属性を読出し、記憶装置に格納するメモリインタフェース手段と、少なくとも現在の位置情報を取得し、記憶装置に格納する手段と、交通事故情報データベースの情報を利用者の位置情報とユーザ属性とを用いて検索する検索手段と、検索手段により交通事故情報が抽出された場合には、抽出された交通事故情報を用いて警告メッセージを生成し、記憶装置に格納する手段と、記憶装置に格納された警告メッセージを利用者に対して出力する手段とを有する。このような車載機を利用することにより、システム利用者は利用者自身がおかれている状況に合わせた適切な情報の提供を受けることが可能になり、より安全な車両の運行がなされるようになる。
【００１５】
本発明に係る情報処理方法をコンピュータに実行させるためのプログラムを作成することも可能であって、当該プログラムは、例えばフレキシブル・ディスク、ＣＤ−ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディスク等の記憶媒体又は記憶装置に格納される。また、ネットワークを介して頒布される場合もある。なお、処理途中のデータについては、コンピュータのメモリに一時保管される。
【００１６】
【発明の実施の形態】
［実施の形態１］
本発明の第１の実施の形態に係るシステム構成図を図１に示す。自動車１３００には、例えばカーナビゲーション機能とネットワーク１１との通信機能とウェブ（Ｗｅｂ）ブラウザ機能とを有する車載機１３が設けられている。なおこの車載機１３は必ずしも自動車に搭載されている必要はなく、携帯情報端末のように歩行者が持ち歩いて利用する形態のものであってもよい。車載機１３には、表示装置１３４と、車載機ハードディスクドライブ（ＨＤＤ）１３１と、ＧＰＳ（Ｇｌｏｂａｌ　Ｐｏｓｉｔｉｏｎｉｎｇ　Ｓｙｓｔｅｍ）衛星１７からの信号を受信するためのＧＰＳアンテナ１３５と、ＩＣカード１３３０に対するインターフェースであるＩＣカード・リーダライタ１３３とが接続されている。また、ＶＩＣＳ（Ｖｉｅｃｌｅ　Ｉｎｆｏｒｍａｔｉｏｎａｎｄ　Ｃｏｍｍｕｎｉｃａｔｉｏｎ　Ｓｙｓｔｅｍ）等の渋滞情報を受信するための渋滞情報受信アンテナ１３７や天候情報を受信するための気象情報受信アンテナ１３９が接続されている場合もある。
【００１７】
また、車載機ＨＤＤ１３１には、カーナビゲーション機能を実現するための地図情報や音声情報その他のデータが格納されている。ＩＣカード・リーダライタ１３３は、接触型又は非接触型のＩＣカード１３３０からデータを読み出し、またデータを書き込む機能を有する。また、ＩＣカードではなく他の規格の記録媒体であってもよい。なお、本願ではＩＣカードを記録媒体の総称として用いるものとする。ＩＣカード１３３０には、保持者の属性（ユーザ属性）についてのデータが格納されている。ユーザ属性の内容としては、例えばユーザＩＤ、性別、年齢、住所、夜間視力、免許保持年数、週間運転日数、週間運転距離、過去の事故歴及び過去の交通違反（以下、違反）歴等が含まれる。
【００１８】
なお、ユーザ属性についてのデータを車載機ＨＤＤ１３１やその他の通信可能なサーバに格納しておき、ＩＣカード１３３０にはユーザＩＤ等の識別情報のみを格納しておくような構成でもよい。利用者は自動車を運転する際には、自己のＩＣカード１３３０を車載機１３に接続されたＩＣカード・リーダライタ１３３にセットする。また、運転者が代わる場合にはＩＣカード１３３０が差し替えられ、ＩＣカード・リーダライタ１３３は、ＩＣカード１３３０から次のユーザ属性データを読み出す。
【００１９】
例えばインターネットであるネットワーク１１には、１又は複数の気象情報会社サーバ１１１と、１又は複数の渋滞情報サーバ１９と、１又は複数の保険会社サーバ１５とが接続されている。また、１又は複数の車載機１３も無線又は有線にてネットワーク１１に接続する。車載機１３は通信機能を有するものとするが、携帯電話機等他の通信装置と接続して通信機能を実現するようにしてもよい。また、気象情報会社サーバ１１１と渋滞情報サーバ１９は、少なくとも保険会社サーバ１５と車載機１３とのいずれかに通信可能な構成となっている。保険会社サーバ１５には事故情報データベース（ＤＢ）１５５が接続され、事故情報ＤＢ１５５には過去の事故現場の位置情報と当事者の属性情報等が関連付けられて格納されている。なお、事故情報ＤＢ１５５は必ずしも保険会社サーバ１５に接続されている必要はなく、事故情報を保持しサービスが提供可能な専門のセンタ・サーバ等に接続されているような構成であってもよい。また、全ての過去の事故情報が登録されているわけではなく、頻度が高いもの等、後の事故防止につなげられるような事故情報のみが登録される。
【００２０】
また、図示していないが、自動車１３００には外気温や湿度等のセンサの値から天候状態を把握する機能が付属される等、気象情報会社サーバ１１１からの信号を必要としない場合や、磁気や走行距離等から現在位置が把握できる等、ＧＰＳ衛星１７からの信号を必要としない場合があってもよい。また、磁気等とＧＰＳ衛星１７からの信号とを組合せて利用する場合があってもよい。
【００２１】
以下、事故情報ＤＢ１５５のテーブル構成及びフラグ属性について、図２乃至図２２を用いて説明する。
【００２２】
図２に示す事故情報テーブルの例には、事故情報番号（ＮＯ．）の列２０、場所ＮＯ．の列２０５０、住所属性の列２０６０、性別の列２０７０、年齢の列２０８０、車種の列２０９０、夜間視力の列２１００、免許年数の列２１１０、週間日数の列２１２０、週間距離の列２１３０、事故歴の列２１４０、違反歴の列２１５０、季節の列２１６０、曜日の列２１７０、天候の列２１８０、時間帯の列２１９０、渋滞状況の列２２００、進行方向の列２２１０、進行予定の列２２２０及びメッセージの列２０４０が含まれている。本テーブルは、主キーであるＮＯ．の列２０と後で説明する各テーブルの外部キーとフラグとで構成されている。更新時の整合性が維持できるのであれば、検索処理を早くするために他のテーブルと結合して非正規化してもよい。テーブルの内容としては、位置、ユーザ属性、車種、天候、渋滞状況及び進行状況によって特定される事故パターンに対するメッセージが関連付けられた構成となっている。
【００２３】
図３に示すユーザ属性テーブルの例には、ユーザＩＤ（ＮＯ．）の列３０、性別の列３１０、年齢の列３２０、住所の列３２５、車種の列３３０、夜間視力の列３４０、免許年数の列３５０、週間日数の列３６０、週間距離の列３７０、事故歴の列３８０及び違反歴の列３９０が含まれている。本テーブルは主キーがユーザＩＤであるＮＯ．の列３０であり、住所の列３２５以外は後で説明する各テーブルの外部キーとフラグとで構成されている。テーブルの内容としては、ユーザ固有の情報のうち、事故に関連する可能性の高い属性が含まれている。
【００２４】
なお、車種の列３３０に登録される車種の情報は、ユーザ自身の属性情報ではないが、ユーザに関連する属性情報であるから本願ではユーザ属性テーブル（図３）にて管理するものとする。
【００２５】
また、住所の列３２５にはユーザが通行し慣れている地域が登録される。ユーザ属性テーブル（図３）の例ではユーザの住所がある市町村名がそのまま登録されるようになっているが、市町村コードやエリア・コードなど、地域が特定できるような構成であればよい。ここで登録される住所データは、ある事故情報において近隣の住民による事故が少ない傾向がある場合に、ユーザが近隣住民であるかどうかを確認するために用いられる。慣れた場所を通行するユーザにとって余分な警告メッセージを出力しないようにするためである。また、仕事において車で営業する地域や過去に住んでいたことがある地域等、住所以外にも通行し慣れている地域がある場合もあり、図示していないが、住所２の列等が含まれるような構成であってもよい。
【００２６】
図４に示すメッセージ・テーブルの例には、メッセージ番号（ＮＯ．）の列４０及びメッセージの列４７０が含まれている。メッセージの列４７０には、様々な条件で共通で使用できるようなメッセージが登録されており、各レコードは事故情報テーブル（図２）のメッセージの列２０４０に関連付けられている。
【００２７】
図５に示す事故多発場所テーブルの例には、場所番号（ＮＯ．）の列５０、場所名の列５２及び位置の列５４が含まれており、事故が多い場所についての情報が登録されている。場所名の列５２は警告メッセージの生成時にも使用でき、例えば、「１００ｍ先の○○交差点では…」というメッセージの「○○交差点」の部分に使用する。また、位置の列５４はＧＰＳ衛星１７等から取得した位置情報との比較に使用する。
【００２８】
図６に示す住所属性フラグ・テーブルの例では、過去の事故情報において事故現場と当事者の住所との間に関連性が見られるかどうかを表すフラグを住所属性フラグとして定義している。住所属性フラグは事故情報テーブル（図２）の住所属性の列２０６０において使用され、例えばある場所の事故発生の傾向として、地域住民でない人、すなわちその場所を通行し慣れていない人の事故が多ければ、住所属性を参酌すべきであることを表すためにフラグを１にセットしておく。一方、当事者の慣れに関係なく事故が発生している場合には、住所属性を参酌する必要がないためフラグを０にセットしておく。
【００２９】
図７に示す性別フラグ・テーブルの例では、男女の別を表すフラグを定義している。性別フラグはユーザ属性テーブル（図３）と事故情報テーブル（図２）とで使用する。この性別フラグはユーザ属性テーブル（図３）では性別の列３１０において使用され、ユーザが男性ならフラグを１とし、女性ならフラグを２としてテーブルに登録しておく。事故情報テーブル（図２）では性別の列２０７０で使用され、例えばある場所の事故発生の傾向として男性の事故が多ければフラグを１にセットしておく。同様に女性が多ければフラグを２にセットしておき、当事者の性別に関係なく事故が発生している場合には性別と事故発生には関連性がないことを表すためフラグを０にセットしておく。
【００３０】
図８に示す年齢テーブルの例には、年齢番号（ＮＯ．）の列８０及び年齢の列８２が含まれており、年代別に年齢番号が登録されている。各レコードはユーザ属性テーブル（図３）及び事故情報テーブル（図２）に関連付けられている。ユーザ属性テーブル（図３）では、レコードを登録する際に、年齢の列３２０にユーザの年齢に従った年齢番号が登録される。例えば２５歳なら２０代なので、”０２”と登録される。また、事故情報テーブル（図２）では、例えばある場所での交通事故の傾向として事故当事者の年齢に１０代が多ければ、年齢の列２０８０には”０１”と登録しておく。また、当事者の年齢に関係なく事故が発生している場合には、年齢と事故発生には関連性がないことを表すため、”００”を事故情報テーブル（図２）のレコードに登録しておく。
【００３１】
図９に示す車種テーブルの例には、車種番号（ＮＯ．）の列９０及び車種の列９２が含まれており、車の大きさや種類によって予め対応付けられた車種番号が登録されている。各レコードはユーザ属性テーブル（図３）及び事故情報テーブル（図２）に関連付けられている。ユーザ属性テーブル（図３）では、レコードを登録する際に、車種の列３３０に、ユーザが使用する車種によって対応する車種番号が登録される。例えばＲＶ車なら”０２”と登録される。また、事故情報テーブル（図２）では、例えばある場所での交通事故の傾向として事故を起こした車種としてトラックが多ければ、車種の列２０９０には”０１”を登録しておく。また、車種に関係なく事故が発生している場合には、車種と事故発生には関連性がないことを表すため、”００”を事故情報テーブル（図２）のレコードに登録しておく。この属性は、車種によって運転者からの視界が違ったり、最小回転半径が違ったりする等の車種による特性と交通事故の発生とを関連付けている。
【００３２】
図１０に示す夜間視力フラグ・テーブルの例では、夜間の視力を表すフラグを定義している。夜間視力フラグはユーザ属性テーブル（図３）と事故情報テーブル（図２）とで使用する。この夜間視力フラグはユーザ属性テーブル（図３）では夜間視力の列３４０で使用され、ユーザが夜間は視力が弱まり周りが見えにくくなるならフラグを１とし、大丈夫ならフラグを０としてテーブルに登録しておく。事故情報テーブル（図２）では夜間視力の列２１００で使用され、例えばある場所の事故発生の傾向として夜間視力が落ちる人の事故が多ければフラグを１にセットしておき、当事者の夜間視力に関係なく事故が発生している場合には夜間視力と事故発生には関連性がないことを表すためフラグを０にセットしておく。
【００３３】
図１１に示す免許年数テーブルの例には、免許取得後年数番号（ＮＯ．）の列１１０及び年数の列１１２が含まれており、年数の範囲別に対応付けられた免許取得後年数番号が登録されている。各レコードはユーザ属性テーブル（図３）及び事故情報テーブル（図２）に関連付けられている。ユーザ属性テーブル（図３）では、レコードを登録する際に、免許年数の列３５０に、ユーザの免許取得後年数に従った免許取得後年数番号が登録される。例えば２年なら１〜５年なので”０２”と登録される。また、事故情報テーブル（図２）では、例えばある場所での交通事故の傾向として事故当事者の免許取得後年数に１年未満の初心者が多ければ、免許年数の列２１１０には”０１”と登録される。また、当事者の免許取得後年数に関係なく事故が発生している場合には、免許取得後年数と事故発生には関連性がないことを表すため、”００”を事故情報テーブル（図２）のレコードに登録しておく。
【００３４】
図１２に示す週間運行日数テーブルの例には、週間運行日数番号（ＮＯ．）の列１２０、運行日数の列１２２が含まれており、所定の日数別に対応付けられた週間運行日数番号が登録されている。この日数は１週間のうち運転する平均日数であり、運転の頻度を表している。各レコードはユーザ属性テーブル（図３）及び事故情報テーブル（図２）に関連付けられている。ユーザ属性テーブル（図３）では、レコードを登録する際に、週間日数の列３６０に、ユーザの週間運行日数に従った週間運行日数番号が登録される。例えば週末しか運転しないのなら週２日以内なので”０１”と登録される。また、事故情報テーブル（図２）では、例えばある場所での交通事故の傾向として週間運行日数が毎日である事故当事者が多ければ、週間日数の列２１２０には”０３”と登録しておく。また、当事者の週間運行日数に関係なく事故が発生している場合には、週間運行日数と事故発生には関連性がないことを表すため、”００”を事故情報テーブル（図２）のレコードに登録しておく。
【００３５】
図１３に示す週間運行距離フラグ・テーブルの例では、１週間に運行する平均距離を表すフラグを定義している。週間運行距離フラグはユーザ属性テーブル（図３）と事故情報テーブル（図２）とで使用する。この週間運行距離フラグはユーザ属性テーブル（図３）では週間距離の列３７０において使用され、ユーザが１週間あたり平均して５０ｋｍ以上運行するならフラグを２とし、５０ｋｍ未満の運行であればフラグを１としてテーブルに登録しておく。事故情報テーブル（図２）では週間距離の列２１３０で使用され、例えばある場所の事故発生の傾向として当事者の週間運行距離が５０ｋｍ未満である場合に事故が多ければフラグを１にセットしておく。同様に当事者の週間運行距離が５０ｋｍ以上である場合に事故が多ければフラグを２にセットしておき、当事者の週間運行距離に関係なく事故が発生している場合には、週間運行処理と事故発生には関連性がないことを表すためフラグを０にセットしておく。
【００３６】
図１４に示す事故歴フラグ・テーブルの例では、過去３年間の事故歴を表すフラグを定義している。事故歴フラグはユーザ属性テーブル（図３）と事故情報テーブル（図２）とで使用する。この事故歴フラグはユーザ属性テーブル（図３）では事故歴の列３８０において使用され、ユーザが過去３年間で無事故ならフラグを０とし、過去３年間に１回事故を経験していればフラグを１とし、過去３年間に複数回事故を経験してればフラグを２としてテーブルに登録しておく。事故情報テーブル（図２）では事故歴の列２１４０で使用され、例えばある場所の事故発生の傾向として当事者の過去３年間の事故歴が複数回である場合に事故が多ければフラグを２にセットしておく。同様に当事者の過去３年間の事故歴が１回である場合に事故が多ければフラグを１にセットしておき、当事者の過去３年間の事故歴に関係なく事故が発生している場合には、事故歴と事故発生には関連性がないことを表すためフラグを０にセットしておく。
【００３７】
なお、上に述べたように、事故歴フラグ０はユーザ属性テーブル（図３）においては過去３年間無事故を意味し、事故情報テーブル（図２）では指定なしを意味する。これは、過去３年間無事故の当事者による事故が発生しやすい傾向になるとは通常考えられないためであり、もし現実に起こり得るのであればフラグを追加するような構成であってもよい。
【００３８】
図１５に示す違反歴フラグ・テーブルの例では、過去３年間の違反歴を表すフラグを定義している。違反歴フラグはユーザ属性テーブル（図３）と事故情報テーブル（図２）とで使用する。この違反歴フラグはユーザ属性テーブル（図３）では違反歴の列３９０において使用され、ユーザが過去３年間で無違反ならフラグを０とし、過去３年間に速度超過の違反を経験していればフラグを１とし、過去３年間に速度超過以外の違反を経験してればフラグを２としてテーブルに登録しておく。事故情報テーブル（図２）では違反歴の列２１５０で使用され、例えばある場所の事故発生の傾向として過去３年間に速度超過の違反をしたことのある当事者に事故が多ければフラグを１にセットしておく。同様に当事者の過去３年間の違反歴が速度超過以外の違反である場合の事故が多ければフラグを２にセットしておき、当事者の過去３年間の違反歴に関係なく事故が発生している場合には、違反歴と事故発生には関連性がないことを表すためフラグを０にセットしておく。
【００３９】
なお、上に述べたように、違反歴フラグ０はユーザ属性テーブル（図３）においては過去３年間無違反を意味し、事故情報テーブル（図２）では指定なしを意味する。これは、過去３年間無違反の当事者による事故が発生しやすい傾向になるとは通常考えられないためであり、もし現実に起こり得るのであればフラグを追加するような構成であってもよい。
【００４０】
図１６に示す季節テーブルの例には、季節番号（ＮＯ．）の列１６０、期間始の列１６２、期間終の列１６４及び季節の列１６６が含まれており、一年を複数の期間に区分して各期間に対応付けられた季節番号が登録されている。各レコードは事故情報テーブル（図２）に関連付けられている。期間始の列１６２には期間の開始日が登録され、同じく期間終の列１６４には期間の終了日が登録される。また、季節の列１６６には期間の季節名が登録されている。事故情報テーブル（図２）では、例えばある場所での交通事故の傾向として７月２１日から８月３１日までの夏休み期間に事故発生数が多ければ、季節の列２１６０には”０５”と登録しておく。また、季節に関係なく年間を通して平均的に事故が発生している場合には、季節と事故発生には関連性がないことを表すため、”００”を事故情報テーブル（図２）のレコードに登録しておく。
【００４１】
図１７に示す曜日テーブルの例には、曜日番号（ＮＯ．）の列１７０及び曜日の列１７２が含まれており、曜日に対応付けられた曜日番号が登録されている。各レコードは事故情報テーブル（図２）に関連付けられている。事故情報テーブル（図２）では、例えばある場所での交通事故の傾向として休日又は祝日の事故が多ければ、曜日の列２１７０には”０４”と登録しておく。また、曜日に関係なく事故が発生している場合には、曜日と事故発生には関連性がないことを表すため、”００”を事故情報テーブル（図２）のレコードに登録しておく。
【００４２】
図１８に示す天候テーブルの例には、天候番号（ＮＯ．）の列１８０及び天候の列１８２が含まれており、天候に対応した天候番号が登録されている。各レコードは事故情報テーブル（図２）に関連付けられている。事故情報テーブル（図２）では、例えばある場所での交通事故の傾向として雨の日の事故が多ければ、天候の列２１８０には”０３”と登録しておく。また、天候に関係なく事故が発生している場合には、天候と事故発生には関連性がないことを表すため、”００”を事故情報テーブル（図２）のレコードに登録しておく。
【００４３】
図１９に示す時間帯テーブルの例には、時間帯番号（ＮＯ．）の列１９０、始の列１９２、終の列１９４及び時間帯の列１９６が含まれており、１日を複数の時間帯に区分し、各時間帯に対応付けられた時間帯番号が登録されている。各レコードは事故情報テーブル（図２）に関連付けられている。始の列１９２には時間帯の開始時刻が登録され、同じく終の列１９４には時間帯の終了時刻が登録される。また、時間帯の列１９６には時間帯の名称が登録されている。事故情報テーブル（図２）では、例えばある場所での交通事故の傾向として朝７：３０から８：３０までの登校・通勤時間帯に事故発生数が多ければ、時間帯の列２１９０には”０２”と登録しておく。また、時間帯に関係なく１日を通して平均的に事故が発生している場合には、時間帯と事故発生には関連性がないことを表すため、”００”を事故情報テーブル（図２）のレコードに登録しておく。
【００４４】
図２０に示す渋滞状況フラグ・テーブルの例では、渋滞の状況を表すフラグを定義している。渋滞状況フラグは事故情報テーブル（図２）の渋滞状況の列２２００で使用される。例えばある場所の事故発生の傾向として渋滞中の事故が多ければフラグを１にセットしておき、渋滞がなくても事故が発生している場合には、渋滞と事故発生には関連性がないことを表すためフラグを０にセットしておく。これは、渋滞中の方が渋滞していない時よりも事故が発生しやすくなると判断した場合の構成であり、例えば渋滞中よりも渋滞していない時の方がスピードの出し過ぎ等によって事故が発生しやすい傾向があったりするのであれば、フラグを追加するような構成であってもよい。
【００４５】
図２１に示す進行方向テーブルの例には、進行方向番号（ＮＯ．）の列２１０及び進行方向の列２１２が含まれており、方角別に進行方向番号が登録されている。各レコードは事故情報テーブル（図２）に関連付けられている。事故情報テーブル（図２）では、例えばある場所での交通事故の傾向として、北へ向かっていた車両の事故が多ければ、進行方向の列２２１０には”０４”と登録しておく。また、進行方向に関係なく事故が発生している場合には、進行方向と事故発生には関連性がないことを表すため、”００”を事故情報テーブル（図２）のレコードに登録しておく。
【００４６】
図２２に示す進行予定テーブルの例には、進行予定番号（ＮＯ．）の列２２０及び進行予定の列２２２が含まれており、右左折等の進路別に進行予定番号が登録されている。各レコードは事故情報テーブル（図２）に関連付けられている。事故情報テーブル（図２）では、例えばある場所での交通事故の傾向として右折していた車両の事故が多ければ、進行予定の列２２２０には”０２”と登録しておく。また、進行予定に関係なく事故が発生している場合には、進行予定と事故発生には関連性がないことを表すため、”００”を事故情報テーブル（図２）のレコードに登録しておく。
【００４７】
以下、図１に示すシステムの処理内容を図２３乃至図３１を用いて説明する。
【００４８】
なお、図２３に示す処理は本実施の形態１と後に述べる実施の形態２との共通の処理概要であり、実施の形態１では保険会社サーバ１５が主要な処理を実行し、実施の形態２では車載機１３が主要な処理を実行する。
【００４９】
ここでは、実施の形態１における全体的な処理概要を図２３を用いて説明する。
【００５０】
まず保険会社サーバ１５は、利用者による入力又はＩＣカード１３３０からの読み出しにより車載機１３が取得したユーザ属性と車種情報とを、車載機１３との通信により取得する（ステップＳ１）。
【００５１】
次に、ＧＰＳアンテナ１３５を介してＧＰＳ衛星１７から車載機１３が取得した現在の車両１３００の位置情報を、保険会社サーバ１５は車載機１３との通信により取得する（ステップＳ３）。なお、位置の履歴情報を車載機１３との通信により取得する場合もある。
【００５２】
続いて保険会社サーバ１５は、渋滞情報と気象情報とを、ネットワーク１１経由で又はその他の通信手段で渋滞情報サーバ１９と気象情報会社サーバ１１１とから受信することにより取得する（ステップＳ５及びステップＳ７）。また、車載機１３が渋滞情報受信アンテナ１３７と気象情報受信アンテナ１３９とを有している場合には車載機１３との通信により取得するような構成であってもよい。渋滞情報と気象情報とのいずれかを車載機１３から取得する場合もある。
【００５３】
保険会社サーバ１５は、上で述べた処理により取得したユーザ属性、車種情報、位置情報、渋滞情報及び気象情報等を検索条件として、事故パターンのデータが予め登録されている事故情報ＤＢ１５５を検索する（ステップＳ９）。
【００５４】
事故情報ＤＢ１５５の検索結果として該当するデータ（事故パターン）が存在するかどうか判定し（ステップＳ１１）、存在しない場合は位置情報の取得ステップ（ステップＳ３）に戻る。該当するデータが存在した場合にはメッセージ生成・出力処理を行う（ステップＳ１３）。メッセージは、位置情報と、メッセージ・テーブル（図４）のメッセージの列４７０の値とを合成することにより生成される。保険会社サーバ１５は当該メッセージを車載機１３に送信し、車載機１３はメッセージを受信し、警告情報として利用者に対して文字や画像や音声等により出力する。
【００５５】
以上説明した処理の終了後、システムが稼動している間は位置情報取得ステップ（ステップＳ３）に戻って処理を繰り返す（ステップＳ１５）。
【００５６】
次に図２４を用いて保険会社サーバ１５と車載機１３との通信を含むシステムの詳細処理内容を説明する。
【００５７】
まず、利用者は自己のＩＣカード１３３０を車載機１３に接続されたＩＣカード・リーダライタ１３３にセットする。そうすると、ＩＣカード・リーダライタ１３３はＩＣカード１３３０からデータを読み出し、車載機１３は読み出したデータをユーザ属性として記憶装置に格納する（ステップＳ１７）。また、読み出したデータに車種情報が含まれていない場合には、車載機１３の処理装置は、自動車１３００の図示しない内部システム又は車載機ＨＤＤ１３１から車種情報を取得し、記憶装置に格納する。
【００５８】
続いて車載機１３は、車載機１３に接続されているＧＰＳアンテナ１３５を介して受信したＧＰＳ衛星１７からの信号に基づき現在の車両の位置情報を取得し、記憶装置に格納する（ステップＳ１９）。そして、これまでに取得したユーザ属性、車種情報及び位置情報を保険会社サーバ１５に送信する（ステップＳ２１）。ここで送信されるユーザ属性は、利用者が登録ユーザの場合にはユーザＩＤである。また、利用者がゲストユーザの場合には例えば性別、年齢、車種及び免許年数である。
【００５９】
なお、上で述べた車載機１３が送信する位置情報には、現在位置及び直近の位置の履歴情報が含まれている場合もある。但し、位置の履歴情報を保険会社サーバ１５にて保持するような構成とすることも可能である。また、図示していないが、ナビゲーション機能を使ってルート設定がなされている場合は、ルート設定中フラグ等のルート設定の状態を示す情報と例えば１００ｍ先までの右左折等の進行予定の情報とをステップＳ２１で合わせて送信する。
【００６０】
また、車載機１３に渋滞情報受信アンテナ１３７及び気象情報受信アンテナ１３９を接続し、渋滞情報サーバ１９及び気象情報会社サーバ１１１から提供されている渋滞情報及び気象情報を、各アンテナを介して車載機１３で取得して、ユーザ属性、車種情報及び位置情報とともに保険会社サーバ１５に送信するような構成であってもよい。
【００６１】
これに対して保険会社サーバ１５は、ユーザ属性、車種情報及び位置情報を車載機１３から受信し、受信した各情報を記憶装置に格納する（ステップＳ２３）。なお、位置の履歴情報を受信しなかった場合には、ユーザＩＤにより過去の位置情報を読み出す。また、車載機１３からの情報に渋滞情報と気象情報とが含まれていない場合には、ネットワーク１１経由で又はその他の通信手段で渋滞情報サーバ１９と気象情報会社サーバ１１１とから提供されている渋滞情報及び気象情報を取得して記憶装置に格納する（ステップＳ２５及びステップＳ２７）。
【００６２】
保険会社サーバ１５は、上で述べた処理により取得したユーザ属性、車種情報、位置情報、渋滞情報及び気象情報を検索条件として、予め登録されている事故情報ＤＢ１５５を検索する（ステップＳ２９）。この処理については後に詳述する。検索結果として条件に該当するデータがあるかどうかの判断を行い（ステップＳ３１）、あった場合には警告メッセージを生成し、記憶装置に格納する（ステップＳ３３）。該当するデータがない場合には空警告メッセージの生成及び格納処理を行う（ステップＳ３５）。そして格納された警告メッセージ又は空警告メッセージを車載機１３に送信する（ステップＳ３７）。空警告メッセージは例えば警告なしを表す情報である。
【００６３】
車載機１３は、保険会社サーバ１５から警告メッセージ又は空警告メッセージを受信し、警告情報として利用者に対して文字や画像や音声等で警告メッセージを出力する（ステップＳ３９）。なお、空警告メッセージを受信した場合には、特に何も出力しない。
【００６４】
メッセージを出力し終わった車載機１３は、一定時間経過後に位置情報取得ステップ（ステップＳ１９）に戻って処理を繰り返す（ステップＳ４１）。
【００６５】
このようにすれば、事故情報は事故情報ＤＢ１５５にて一括管理することができ、データの追加・更新があっても、常に最新のデータを使用して利用者の属性及び利用者が現在おかれている状況に適合した情報を提供できるようになる。また、車載機１３の記憶容量や処理の能力は比較的小さいものであっても済むようになっている。
【００６６】
次に、上で述べた事故情報ＤＢ１５５の検索処理（ステップＳ２９）についての詳細と警告メッセージ生成・格納処理についての詳細とを図２５乃至図３１を用いて説明する。
【００６７】
なお、事故情報ＤＢ１５５の検索処理と警告メッセージ生成・格納処理との２つの処理は本実施の形態１と後に述べる実施の形態２との共通のサブルーチン処理であり、実施の形態１では保険会社サーバ１５が実行し、実施の形態２では車載機１３が実行する。
【００６８】
まず、事前の処理により予め受信して記憶装置に格納されているＧＰＳの位置情報を用いて、事故多発場所テーブル（図５）の位置の列５４のデータを検索する（ステップＳ６９）。ＧＰＳの位置情報と事故多発場所テーブル（図５）の位置の列５４のデータとを比較して、ＧＰＳの位置情報から例えば１００ｍ以内のデータが存在するかどうか判定し（ステップＳ７１）、存在しない場合は処理を終了する。該当するデータが存在する場合はレコードを特定する（ステップＳ７３）。次に特定されたレコードの場所番号（ＮＯ．）の列５０の値を検索条件として事故情報テーブル（図２）の場所ＮＯ．の列２０５０を検索する（ステップＳ７５）。一致するレコードが１つ以上存在すれば（ステップＳ７７）、事故情報テーブル（図２）の該当レコードを特定し、絞込み情報記憶部に格納する（ステップＳ７９）。この時、絞込み情報記憶部にデータが残っていた場合には、上書き若しくは一旦クリアしてから新たに格納する。以下、特に明示しない限り、絞込み情報記憶部へのデータ格納は上書き処理とする。また、一致するレコードがなければ処理を終了する。その際、絞込み情報記憶部にデータが残っていた場合には、データをクリアしてから処理を終了する。以下、特に明示しない限り、該当データがなく処理を終了する場合には、絞込み情報記憶部のデータもクリアされるものとする。
【００６９】
ここまでの処理は、利用者の現在位置が、登録してある事故多発場所から例えば１００ｍ圏内である場合には、当該１００ｍ圏内の事故多発場所における事故情報を抽出する処理である。
【００７０】
次に、事前の処理により予め記憶装置に格納されている当該ユーザのＧＰＳの履歴情報から進行方向テーブル（図２１）の該当レコードを特定する（ステップＳ８１）。現時位置の情報とＧＰＳの履歴情報とから利用者がどの方角に向かっているか特定し、一致する進行方向の列２１２を含むレコードを特定する。進行方向テーブル（図２１）のレコードが特定されると、その進行方向番号（ＮＯ．）の列２１０の値を検索条件として、ステップＳ７９の処理によって絞込み情報記憶部に格納されているレコードをさらに絞込み検索する（ステップＳ８３）。すなわち、特定された進行方向番号と同じ値を進行方向の列２２１０に含むレコードを抽出する。なお、絞込み情報記憶部に格納されているレコードの進行方向の列２２１０の値が”００”の場合には、事故の発生と進行方向とに関連性がない場合であるためそのまま抽出対象に含める。該当するレコードの存在を判定し（ステップＳ８５）、１つ以上存在する場合には、抽出されたレコードを絞込み情報記憶部に格納する（ステップＳ８７）。また、該当するレコードがなかった場合にはそのまま処理を終了する。
【００７１】
処理は端子Ａを介して図２５の処理に移行する。次に、ナビゲーション機能によるルートが設定されているかどうかを判定する（ステップＳ８９）。本実施の形態１において車載機１３から受信したルート設定の有無を表す情報に基づきルートが設定されていると判断される場合又は実施の形態２において車載機１３の設定に基づきルート設定がなされていると判断される場合には、利用者のこの先例えば１００ｍ以内の右左折等の進行予定情報を取得し、進行予定テーブル（図２２）の該当レコードを特定する（ステップＳ９１）。進行予定の情報から利用者がどのように進むか判断し、進行予定テーブル（図２２）において一致する進行予定の情報を含むレコードを特定する。進行予定の情報は、実施の形態１では車載機１３から受信し、実施の形態２では自身のナビゲーション処理部から取得する。進行予定テーブル（図２２）のレコードが特定されると、その進行予定番号（ＮＯ．）の列２２０の値を検索条件として、ステップＳ８７の処理によって絞込み情報記憶部に格納されているレコードをさらに絞込み検索する（ステップＳ９３）。すなわち、特定されたレコードの進行予定番号と同じ値が進行予定の列２２２０に格納されたレコードを抽出する。なお、絞込み情報記憶部に格納されているレコードの進行予定の列２２２０の値が”００”の場合には、事故の発生と進行方向とに関連性がない場合であるためそのまま抽出対象に含める。該当するレコードの存在を判定し（ステップＳ９５）、１つ以上存在する場合には、抽出されたレコードを絞込み情報記憶部に格納する（ステップＳ９７）。また、該当するレコードがなかった場合には、そのまま処理を終了する。一方、ナビゲーション機能によるルートが設定されていない場合（ルート設定無しの情報を受信した場合又はナビゲーション処理部にルート設定がなされていないと判断される場合）には、上で述べたステップＳ９１からステップＳ９７までの処理をスキップする。
【００７２】
次に、システム日付から日付、曜日及び時刻を取得し、その情報を用いて季節テーブル（図１６）、曜日テーブル（図１７）及び時間帯テーブル（図１９）の各テーブルの該当レコードを特定する（ステップＳ９９）。まず季節テーブル（図１６）で、日付の情報からどの季節に当てはまるかを判定し、季節番号（ＮＯ．）の列１６０の値が”００”以外のレコードを特定する。また、曜日テーブル（図１７）で、日付の情報からどの曜日区分に当てはまるかを判定し、曜日番号（ＮＯ．）の列１７０の値が”００”以外のレコードを特定する。さらに、時間帯テーブル（図１９）で、システム時刻の情報からどの時間帯に当てはまるかを判定し、時間帯番号（ＮＯ．）の列１９０の値が”００”以外のレコードを特定する。
【００７３】
季節テーブル（図１６）、曜日テーブル（図１７）及び時間帯テーブル（図１９）のレコードが特定されると、当該特定されたレコードの季節番号（ＮＯ．）の列１６０、曜日番号（ＮＯ．）の列１７０及び時間帯番号（ＮＯ．）の列１９０の各値を検索条件として、ステップＳ９７又はステップＳ８７の処理によって絞込み情報記憶部に格納されているレコードをさらに絞込み検索する（ステップＳ１０１）。すなわち、特定されたレコードの季節番号（ＮＯ．）の列１６０の値と同じ値が季節の列２１６０に格納され且つ特定されたレコードの曜日番号（ＮＯ．）の列１７０の値と同じ値が曜日の列２１７０に格納され且つ特定されたレコードの時間帯番号（ＮＯ．）の列１９０の値と同じ値が時間帯の列２１９０に格納されたレコードを抽出する。なお、絞込み情報記憶部に格納されているレコードの季節の列２１６０の値が”００”の場合には、事故の発生と季節とに関連性がない場合であるため季節番号（ＮＯ．）の列１６０による絞込みは行わない。曜日の列２１７０、時間帯の列２１９０についても同様に、レコードの値が”００”の場合には、曜日番号（ＮＯ．）の列１７０及び時間帯番号（ＮＯ．）の列１９０の値による絞込みは行わない。該当するレコードの存在を判定し（ステップＳ１０３）、１つ以上存在する場合には、抽出されたレコードを絞込み情報記憶部に格納する（ステップＳ１０５）。また、該当するレコードがなかった場合には、そのまま処理を終了する。
【００７４】
処理は端子Ｂを介して図２７の処理に移行する。次に、事前の処理により予め取得され記憶装置に格納されている渋滞情報を用いて、渋滞フラグを特定する（ステップＳ１０７）。渋滞状況一覧等の一時テーブル（図示せず）を作成するなどして、位置と渋滞フラグとの対応付けを行っておき、ある位置が渋滞しているかどうか即座に判定できるようにしておいてもよい。なお、渋滞情報には少なくとも位置の情報と当該位置における渋滞の有無の情報とが含まれており、ＶＩＣＳ等から得られる渋滞情報をそのまま保持しておいてもよいし、ＧＰＳの位置情報を用いて利用者の現在位置から例えば１００ｍ圏内の渋滞情報を抽出して保持しておいてもよい。
【００７５】
渋滞フラグが特定されると、ステップＳ１０５の処理によって絞込み情報記憶部に格納されているレコードをさらに絞込み検索する（ステップＳ１０９）。すなわち、絞込み情報記憶部に格納されているレコードの渋滞状況の列２２００の値が”０”、又は渋滞状況の列２２００の値が”１”且つ当該レコードの場所ＮＯ．の列２０５０の値から導出される位置と同じ位置の渋滞情報（一時テーブル等）が渋滞中を示しているレコードを抽出する。ここでは、渋滞中に起こりやすい事故の情報があった場合、現実には渋滞していなければ当該事故情報を抽出対象から外す処理を行っている。該当するレコードの存在を判定し（ステップＳ１１１）、１つ以上存在する場合には、抽出されたレコードを絞込み情報記憶部に格納する（ステップＳ１１３）。また、該当するレコードがなかった場合には、そのまま処理を終了する。
【００７６】
次に、事前の処理により予め取得され記憶装置に格納されている気象情報から天候テーブル（図１８）の該当レコードを特定する（ステップＳ１１５）。気象情報から利用者の現在位置から例えば１０ｋｍ圏内の天候を判断し、一致する値が格納された天候の列１８２を含むレコードを特定する。なお、気象情報には少なくとも位置の情報と当該位置における天候の情報とが含まれており、気象情報会社サーバ１１１等から得られる気象情報をそのまま保持しておいてもよいし、ＧＰＳの位置情報を用いて利用者の現在位置から例えば１０ｋｍ圏内の気象情報を抽出して保持しておいてもよい。天候テーブル（図１８）のレコードが特定されると、その天候番号（ＮＯ．）の列１８０の値を検索条件として、ステップＳ１１３の処理によって絞込み情報記憶部に格納されているレコードをさらに絞込み検索する（ステップＳ１１７）。すなわち、特定された天候番号と同じ値を天候の列２１８０に含むレコードを抽出する。なお、絞込み情報記憶部に格納されているレコードの天候の列２１８０の値が”００”の場合には、事故の発生と天候とに関連性がない場合であるためそのまま抽出対象に含める。該当するレコードの存在を判定し（ステップＳ１１９）、１つ以上存在する場合には、抽出されたレコードを絞込み情報記憶部に格納する（ステップＳ１２１）。また、該当するレコードがなかった場合には、そのまま処理を終了する。
【００７７】
処理は端子Ｃを介して図２８の処理に移行する。次に、事前の処理により予め取得され記憶装置に格納されているユーザの情報から、利用者が登録されているユーザ（登録ユーザ）か、ゲストユーザかを判定する（ステップＳ１２３）。予め、システム利用開始時に車載機１３の表示装置１３４に登録ユーザかゲストユーザかの選択入力を促す選択画面を表示し、利用者が入力した情報を受信して識別情報として保持しておくような構成であってもよいし、ＩＣカード１３３０に格納されているユーザＩＤを取得し、登録されているかどうか検索して判断するような構成であってもよい。登録ユーザであった場合には、ユーザＩＤからユーザ属性テーブル（図３）を検索して該当レコードを特定する。すなわち、ユーザＩＤ（ＮＯ．）の列３０の値が利用者のユーザＩＤと同じであるレコードを抽出する。レコードが特定されると、当該レコードの全ての列（３１０乃至３９０）の値を読込む（ステップＳ１２７）。また、利用者がゲストユーザであった場合には、例えば性別、年齢、車種及び免許年数等の最小限のユーザ属性が、事前の処理によって予め取得されているため、これらの値を読込む（ステップＳ１２９）。なお、ユーザ属性は時々刻々と変化するものではないため一連の処理において繰返し使用でき、必ずしも毎回検索処理を行う必要はない。例えば、あるユーザが目的地まで車を運転する場合など、一度ユーザ属性を取得しておけば、当該ユーザが目的地に着いて車の運転を終了するまでは同じデータを使用できる。そのため、ステップＳ１２３の処理が２回目以降である場合、ステップＳ１２５乃至ステップＳ１２９の処理をスキップするような構成であってもよい。
【００７８】
次に、ユーザ属性による該当レコード抽出を行う。まずは取得済みのユーザ属性から性別フラグを特定する（ステップＳ１３１）。登録ユーザの場合はユーザ属性テーブル（図３）の該当レコードの性別の列３１０のフラグであり、ゲストユーザの場合は性別フラグ・テーブル（図７）から該当するフラグ値を特定する。性別フラグが特定されると、ステップＳ１２１の処理によって絞込み情報記憶部に格納されているレコードをさらに絞込み検索する（ステップＳ１３３）。すなわち、性別の列２０７０のフラグが、ステップＳ１３１で特定されたフラグと同じものを含むレコードを抽出する。なお、絞込み情報記憶部に格納されているレコードの性別の列２０７０の値が”０”の場合には、事故の発生と性別とに関連性がない場合であるためそのまま抽出対象に含める。該当するレコードの存在を判定し（ステップＳ１３５）、１つ以上存在する場合には、抽出されたレコードを絞込み情報記憶部に格納する（ステップＳ１３７）。また、該当するレコードがなかった場合には、そのまま処理を終了する。
【００７９】
次に、取得済みのユーザ属性から年齢番号（年齢テーブルの該当レコード）を特定する（ステップＳ１３９）。登録ユーザの場合はユーザ属性テーブル（図３）の該当レコードの年齢の列３２０の値であり、ゲストユーザの場合は年齢テーブル（図８）から該当する年齢番号を特定する。年齢番号が特定されると、ステップＳ１３７の処理によって絞込み情報記憶部に格納されているレコードをさらに絞込み検索する（ステップＳ１４１）。すなわち、年齢の列２０８０の値が、ステップＳ１３９で特定された年齢番号と同じものを含むレコードを抽出する。なお、絞込み情報記憶部に格納されているレコードの年齢の列２０８０の値が”００”の場合には、事故の発生と年齢とに関連性がない場合であるためそのまま抽出対象に含める。該当するレコードの存在を判定し（ステップＳ１４３）、１つ以上存在する場合には、抽出されたレコードを絞込み情報記憶部に格納する（ステップＳ１４５）。また、該当するレコードがなかった場合には、そのまま処理を終了する。
【００８０】
処理は端子Ｄを介して図２９の処理に移行する。次に、登録ユーザの場合はユーザ属性テーブル（図３）の該当レコードの車種の列３３０の値（車種番号）を、ゲストユーザの場合は車種テーブル（図９）から該当する車種番号を特定する（ステップＳ１４７）。車種番号が特定されると、ステップＳ１４５の処理によって絞込み情報記憶部に格納されているレコードをさらに絞込み検索する（ステップＳ１４９）。すなわち、車種の列２０９０の値が、ステップＳ１４７で特定された車種番号と同じものを含むレコードを抽出する。なお、絞込み情報記憶部に格納されているレコードの車種の列２０９０の値が”００”の場合には、事故の発生と車種とに関連性がない場合であるためそのまま抽出対象に含める。該当するレコードの存在を判定し（ステップＳ１５１）、１つ以上存在する場合には、抽出されたレコードを絞込み情報記憶部に格納する（ステップＳ１５３）。また、該当するレコードがなかった場合には、そのまま処理を終了する。
【００８１】
次に、取得済みのユーザ属性から免許取得後年数番号（免許年数テーブルの該当レコード）を特定する（ステップＳ１５５）。登録ユーザの場合はユーザ属性テーブル（図３）の該当レコードの免許年数の列３５０の値であり、ゲストユーザの場合は免許年数テーブル（図１１）から該当する免許取得後年数番号を特定する。免許取得後年数番号が特定されると、ステップＳ１５３の処理によって絞込み情報記憶部に格納されているレコードをさらに絞込み検索する（ステップＳ１５７）。すなわち、免許年数の列２１１０の値が、ステップＳ１５５で特定された免許取得後年数番号と同じものを含むレコードを抽出する。なお、絞込み情報記憶部に格納されているレコードの免許年数の列２１１０の値が”００”の場合には、事故の発生と免許取得後年数とに関連性がない場合であるためそのまま抽出対象に含める。該当するレコードの存在を判定し（ステップＳ１５９）、１つ以上存在する場合には、抽出されたレコードを絞込み情報記憶部に格納する（ステップＳ１６１）。また、該当するレコードがなかった場合には、そのまま処理を終了する。
【００８２】
処理は端子Ｅを介して図３０の処理に移行する。そして再度利用者がゲストユーザであるかどうか判定し（ステップＳ１６３）、ゲストユーザである場合には、以下に説明するステップＳ１６５乃至ステップＳ１７１をスキップしてサブルーチンを終了する。この際、絞込み情報記憶部に格納されているデータはクリアしない。また、利用者が登録ユーザである場合には、ユーザ属性テーブルにおける該当レコードの各列の値を特定する（ステップＳ１６５）。住所の列３２５については、例えば市町村名が登録されており、当該市町村名を特定する。その他の各列には番号又はフラグが登録されている。次に、ステップＳ１６５で特定された値を用いて、ステップＳ１６１の処理によって絞込み情報記憶部に格納されているレコードをさらに絞込み検索する（ステップＳ１６７）。住所以外の属性については、上で述べた例えば性別フラグについてのステップＳ１３３の処理や、車種番号についてのステップＳ１４９の処理と同様の処理を行う。なお、絞込み情報記憶部に格納されているレコードの各列の値が”００”又は”０”の場合には、事故の発生と当該列におけるユーザ属性とに関連性がない場合であるためそのまま抽出対象に含める。住所については、絞込み情報記憶部に格納されているレコードのうち、住所属性の列２０６０の値が”０”である場合、又は住所属性の列２０６０の値が”１”であり且つ場所ＮＯ．の列２０５０の値及び事故多発場所テーブル（図５）から導出される位置の列５４の値が例えば住所の列３２５の市町村以外である場合のレコードを抽出する。ここでは、住所属性を参酌する必要がない場合と、住所属性を参酌する必要があり且つユーザが当該市町村民でない（又はその地域に不案内である）場合とを抽出対象にしている。地域住民であるかどうかの判断については、市町村民の他にも近隣の市町村民を含めるような構成であってもよい。なお、位置の列５４の値がどこの市町村であるかを判定する処理については、本発明の重要な要素ではないためここでは詳述しないが、例えば市町村コードや住所ＤＢ（図示せず）などを用いて位置の値の範囲と地域とを対応付けておき、位置の列５４の値で検索を行うような構成であってもよい。
【００８３】
ステップＳ１６７の絞込み検索処理が全て終了したら、該当するレコードの存在を判定し（ステップＳ１６９）、１つ以上存在する場合には、抽出されたレコードを絞込み情報記憶部に格納し（ステップＳ１７１）、本サブルーチンを終了する。また、該当するレコードがなかった場合には、そのまま処理を終了する。
【００８４】
以上の処理により、事故情報テーブル（図２）から、利用者の属性及び現在の運行環境に対応したレコードを抽出することが可能となる。
【００８５】
続いて警告メッセージ生成・格納処理についての詳細を図３１を用いて説明する。
【００８６】
まず、事前の処理によって絞込み情報記憶部に格納されているレコードの場所ＮＯ．の列２０５０の値を検索条件として事故多発場所テーブル（図５）を検索し、該当レコードを抽出して記憶装置に格納する（ステップＳ１７３）。また同様に、絞込み情報記憶部に格納されているレコードのメッセージの列２０４０の値を検索条件としてメッセージ・テーブル（図４）を検索し、該当レコードを抽出して記憶装置に格納する（ステップＳ１７５）。ここで、ステップＳ１７３の処理によって特定された事故多発場所テーブル（図５）のレコードの場所名の列５２の値と、ステップＳ１７５の処理によって特定されたメッセージ・テーブル（図４）のレコードのメッセージの列４７０の値とから、警告メッセージを生成し、記憶装置に格納する（ステップＳ１７９）。この際、位置の情報を用いて例えば「１００ｍ先の」等のメッセージを追加するような構成であってもよい。以上の処理を絞込み情報記憶部に格納されている全レコードに対して行い（ステップＳ１７９）、サブルーチンを終了する。
【００８７】
このようにして、警告メッセージを生成・格納する。最終的に利用者に提供される警告メッセージは例えば「この先の××交差点は、右折する際に事故が多いので注意して通行してください。」のような形になる。今回は２つのテーブルの値を用いて生成したが、事故情報テーブル（図２）に警告メッセージが直接登録してあるような構成であってもよい。
【００８８】
以上説明したように、車載機１３と保険会社サーバ１５との通信により、事故情報ＤＢ１５５においてデータの追加・更新があっても、常に最新のデータを使用して利用者の属性及び利用者が現在おかれている状況に適合した情報を提供できるようになる。また、保険会社サーバが主要な処理を実行するため、車載機１３では事故情報の検索処理や管理は行わず、記憶容量や処理の能力は比較的小さいものであっても済むようになっている。
【００８９】
［実施の形態２］
本発明の第２の実施の形態に係るシステム構成図を図３２に示す。自動車２３００には、例えばカーナビゲーション機能とネットワーク２１との通信機能とＷｅｂブラウザ機能とを有する車載機２３が設けられている。なおこの車載機２３は必ずしも自動車に搭載されている必要はなく、携帯情報端末のように歩行者が持ち歩いて利用する形態のものであってもよい。車載機２３には、表示装置２３４と、車載機ＨＤＤ２３１と、ＧＰＳ衛星２７からの信号を受信するためのＧＰＳアンテナ２３５と、ＩＣカード２３３０に対するインターフェースであるＩＣカード・リーダライタ２３３とが接続されている。さらにはＶＩＣＳ等の渋滞情報を受信するための渋滞情報受信アンテナ２３７及び天候情報を受信するための気象情報受信アンテナ２３９が接続されている。
【００９０】
また車載機ＨＤＤ２３１には、後で説明する事故情報ＤＢ２５５にある全部又は一部の事故情報が格納されており、カーナビゲーション機能を実現するための地図情報や音声情報その他のデータも格納されている。ＩＣカード・リーダライタ２３３は、接触型又は非接触型のＩＣカード２３３０からデータを読み出し、またデータを書き込む機能を有する。また、ＩＣカードではなく他の規格の記録媒体であってもよい。ＩＣカード２３３０には、保持者の属性（ユーザ属性）についてのデータが格納されている。ユーザ属性の内容としては、例えばユーザＩＤ、性別、年齢、住所、夜間視力、免許保持年数、週間運転日数、週間運転距離、過去の事故歴及び過去の違反歴等が含まれる。
【００９１】
なお、ユーザ属性についてのデータを車載機ＨＤＤ２３１やその他の通信可能なサーバに格納しておき、ＩＣカード２３３０にはユーザＩＤ等の識別情報のみを格納しておくような構成でもよい。利用者は自動車を運転する際には、自己のＩＣカード２３３０を車載機２３に接続されたＩＣカード・リーダライタ２３３にセットする。
【００９２】
例えばインターネットであるネットワーク２１には、１又は複数の保険会社サーバ２５が接続されている。また、１又は複数の気象情報会社サーバ２１１と、１又は複数の渋滞情報サーバ２９とは、放送事業者等により管理される通信タワー２１３等に接続されており、気象情報や渋滞情報が当該通信タワー２１３から放送される。また、１又は複数の車載機２３も無線又は有線にてネットワーク２１に接続する。車載機２３は通信機能を有するものとするが、携帯電話機等他の通信装置と接続して通信機能を実現するようにしてもよい。また、車載機２３は接続されている各アンテナを介して、気象情報会社サーバ２１、渋滞情報サーバ２９及びＧＰＳ衛星からの情報を受信可能な構成となっている。保険会社サーバ２５には事故情報ＤＢ２５５が接続され、事故情報ＤＢ２５５には過去の事故現場の位置情報と当事者の属性情報等が関連付けられて格納されている。なお、事故情報ＤＢ２５５は必ずしも保険会社サーバ２５に接続されている必要はなく、事故情報を保持しサービスが提供可能な専門のセンタ・サーバ等に接続されているような構成であってもよい。また、全ての過去の事故情報が登録されているわけではなく、頻度が高いもの等、後の事故防止につなげられるような事故情報のみが登録される。また、上で述べたとおり、事故情報の全部又は一部は車載機ＨＤＤ２３１にも複製されており、例えば、自動車２３００の運行範囲の事故情報のみが格納されるような形であってもよい。
【００９３】
また、図示していないが、自動車２３００には外気温や湿度等のセンサの値から天候状態を把握する機能が付属される等、気象情報会社サーバ２１１からの情報を必要としない場合や、磁気や走行距離等から現在位置が把握できる等、ＧＰＳ衛星２７からの信号を必要としない場合があってもよい。また、磁気等とＧＰＳ衛星２７からの信号とを組合せて利用する場合があってもよい。
【００９４】
この実施の形態２と実施の形態１との違いは、車載機２３が渋滞情報と気象情報とを各情報提供サーバから直接受信できる構成になっていること及び車載機ＨＤＤ２３１にも事故情報が記録されていることである。
【００９５】
以下、図３２に示すシステムの処理内容を図３３を用いて説明する。なお、取得する情報や処理結果の出力等の全体的な処理概要については、上で述べた実施の形態１においての処理と同様である。また、詳細なサブルーチン処理である事故情報ＤＢの検索処理及び警告メッセージ生成・格納処理についても、実施の形態１においての処理と同様である。大きく異なる点として、実施の形態１では保険会社サーバ１５が主要な処理を実行するのに対し、実施の形態２では車載機２３が主要な処理を実行する。すなわち、実施の形態１では保険会社サーバ１５と車載機１３とが常に通信して最新の情報を提供するオンライン型の処理を行うのに対し、実施の形態２では通信回数を減らしたバッチ型の処理を行うような構成となっている。
【００９６】
まず車載機２３は、任意のタイミングで（例えば周期的に若しくは利用者の指示に従って）車載機ＨＤＤ２３１に保持してある事故情報を最新のものにするため、事故情報ＤＢ差分情報取得要求を保険会社サーバ２３に送信する（ステップＳ４２）。なおこの要求は、最終更新日時等、車載機ＨＤＤ２３１に現在格納されている事故情報のバージョンが判別できる情報を含んでいる。
【００９７】
保険会社サーバは、車載機２３から事故情報ＤＢ差分情報取得要求を受信し、事故情報ＤＢ２５５から差分情報を検出し（ステップＳ４５）、検出した差分情報を車載機２３に送信する（ステップＳ４７）。差分情報がない場合は、その旨を表すコード等を送信する。
【００９８】
車載機２３は、保険会社サーバ２３から事故情報ＤＢ差分情報を受信し、車載機ＨＤＤ２３１に現在格納されている事故情報に差分情報を加え、最新の状態に更新する（ステップＳ４９）。
【００９９】
なお、以上の処理は必ずしも毎回行う必要はない。また、初めて本システムを使用する場合には、予め車載機ＨＤＤ２３１にその時点での最新の事故情報を格納しておいたり、事故情報を記録したＤＶＤ−ＲＯＭ等の媒体をユーザに配布して車載機ＨＤＤ２３１に事故情報の格納をさせたりするような構成であってもよい。また、事故情報ＤＢ２５５に格納されている全ての情報を複製するには車載機ＨＤＤ２３１の容量が足りない可能性もあり、そのような場合には、例えば全国版だけでなく地方版などを設定し、普段使用しない情報は車載機ＨＤＤ２３１に記録しないような構成であってもよい。またこのような構成の場合、上で述べたステップＳ４２乃至ステップＳ４９の処理において、通信量の削減が期待できる。
【０１００】
次に、利用者は自己のＩＣカード２３３０を車載機２３に接続されたＩＣカード・リーダライタ２３３にセットする。そうすると、ＩＣカード・リーダライタ２３３がＩＣカード２３３０からデータを読み出し、車載機２３は読み出したデータをユーザ属性として記憶装置に格納する（ステップＳ５１）。また、読み出したデータに車種情報が含まれていない場合には、車載機２３の処理装置は、自動車２３００の図示しない内部システム又は車載機ＨＤＤ２３１から車種情報を取得し、記憶装置に格納する。ここで格納されるユーザ属性は、利用者が登録ユーザの場合には、ＩＣカード２３３０から読み出したデータ又はユーザＩＤを用いて車載機ＨＤＤ２３１から読み出したデータに、車種情報を合わせたものである。すなわち、ユーザ属性テーブル（図３）の１レコード分の情報である。また、利用者がゲストユーザの場合には例えば性別、年齢、車種及び免許年数の入力を促し、格納する。
【０１０１】
続いて車載機２３は、車載機２３に接続されているＧＰＳアンテナ２３５を介して受信したＧＰＳ衛星２７からの信号に基づき現在の車両の位置情報を取得し、記憶装置に格納する（ステップＳ５３）。ここで位置情報としては、現在位置の情報が蓄積されており、従って位置の履歴情報を取得できるようになっている。また、図示していないが、ナビゲーション機能を使ってルートを設定してある場合は、例えば１００ｍ先までの右左折等の進行予定の情報をステップＳ５３で合わせて格納する。
【０１０２】
次に、車載機２３は渋滞情報受信アンテナ２３７及び気象情報受信アンテナ１３９を介して、渋滞情報サーバ２１１及び気象情報会社サーバ２９が通信タワー２１３から放送する渋滞情報及び気象情報を受信し、記憶装置に格納する（ステップＳ５５及びステップＳ５７）。
【０１０３】
車載機２３は、上で述べた処理により取得したユーザ属性、車種情報、位置情報、渋滞情報及び気象情報を検索条件として、車載機ＨＤＤ２３１に登録されている事故情報を検索する（ステップＳ５９）。この処理は図２５乃至図３０に示した事故情報ＤＢ検索処理と同様の処理である。次に検索結果として条件に該当するデータがあるかどうかの判断を行い（ステップＳ６１）、あった場合には警告メッセージを生成し、記憶装置に格納する（ステップＳ６３）。この処理も図３１に示した処理と同様であり、ここでは説明を省略する。該当するデータがない場合にはステップＳ６３及び次のステップＳ６５をスキップする。
【０１０４】
警告メッセージを生成した車載機２３は、警告情報として利用者に対して文字や画像や音声等でメッセージを出力する（ステップＳ６５）。
【０１０５】
メッセージを出力し終わった車載機２３は、一定時間経過後に位置情報取得ステップ（ステップＳ５３）に戻って処理を繰り返す（ステップＳ６７）。
【０１０６】
このようにすれば、保険会社サーバ２５と常に通信する必要がなくなり、通信回数を減らして、交通事故に関連する情報を利用者の属性及び利用者が現在おかれている状況に適合した形で提供することが可能となる。
【０１０７】
［実施の形態３］
次に、本発明の第３の実施の形態に係る処理内容を図３４乃至図３７を用いて説明する。システムの構成としては、実施の形態１と実施の形態２とのいずれか１つの構成と同様でよいが、サーバと端末との通信処理は必要ないため、実施の形態２での構成を前提に説明する。なお、各処理において詳細が上で述べた処理と同様の場合は、詳細な説明や注釈については省略する。
【０１０８】
まず、ＩＣカード２３３０やユーザからの入力等から、車載機２３はユーザ属性及び車種情報を取得し（ステップＳ１８１）、さらにシステム日付（ステップＳ１８３）、渋滞情報及び気象情報を取得し（ステップＳ１８５）、記憶装置に格納する。また、現在の車両の位置情報及びユーザの指定に基づき目的地を取得し、記憶装置に格納する（ステップＳ１８７）。ここで格納されるユーザ属性は、利用者が登録ユーザの場合には、ＩＣカード２３３０から読み出したデータ又はユーザＩＤを用いて車載機ＨＤＤ２３１から読み出したデータに、車種情報を合わせたものである。すなわち、ユーザ属性テーブル（図３）の１レコード分の情報である。また、利用者がゲストユーザの場合には例えば性別、年齢、車種及び免許年数の入力を促し、格納する。
【０１０９】
次に、１回目のナビゲーションルート生成処理かどうか判定し（ステップＳ１８９）、１回目であれば標準機能を使ってナビゲーションルートを生成する（ステップＳ１９１）。２回目以降（ｎ回目）であれば、ｎ−１回目までの処理で格納されている迂回場所記憶部から、迂回すべき位置情報を読込み（ステップＳ１９３）、当該位置を迂回するナビゲーションルートを生成する（ステップＳ１９５）。具体的には、事故多発場所テーブル（図５）のレコードを抽出した結果が格納されている迂回場所記憶部のデータから、位置の列５４の値が示す位置を特定し、その場所を迂回するルートを生成する処理である。
【０１１０】
次に、ステップＳ１９１又はステップＳ１９５において生成したルート上における所与の間隔の位置情報を取得し、事故多発場所テーブル（図５）の位置の列５４の値との突合せを行う（ステップＳ１９７）。該当データがあるかどうか判定し（ステップＳ１９９）、該当データがなければ、後で説明する端子Ｏを介して図３１の処理へ進む。該当データがあれば、事故多発場所テーブルの該当レコードを特定し（ステップＳ２０１）、当該レコードの事故多発場所番号（ＮＯ．）の列５０の値を検索条件として、事故情報テーブル（図２）の場所ＮＯ．の列２０５０を検索する（ステップＳ２０３）。一致するレコードが１つ以上存在すれば（ステップＳ２０５）、事故情報テーブル（図２）の該当レコードを特定し、絞込み情報記憶部に格納する（ステップＳ２０７）。この時、絞込み情報記憶部にデータが残っていた場合には、上書き若しくは一旦クリアしてから新たに格納する。以下、特に明示しない限り、絞込み情報記憶部へのデータ格納は上書き処理とする。また、一致するレコードがなければ端子Ｏを介して図３７の処理へ進む。その際、絞込み情報記憶部にデータが残っていた場合には、データをクリアしてから端子Ｏを介して図３７の処理へ進む。以下、特に明示しない限り、該当データがなく端子Ｏを介して図３７の処理へ進む場合には、絞込み情報記憶部のデータもクリアされるものとする。
【０１１１】
以下、取得済みの各条件を用いて絞込み情報記憶部のレコードを検索して絞込んでいく。検索キーや使用するテーブル等の詳細は上で述べた事故情報ＤＢ検索処理と同様であり、各検索ステップにおいて事故情報テーブル（図２）の列の値が”０”又は”００”の場合はそのまま抽出対象に含める。
【０１１２】
まず、ステップＳ１９１又はステップＳ１９５で生成したナビゲーションルートの情報から進行予定を特定し、当該特定された進行予定の情報による検索・絞込みを行い（ステップＳ２０９）、該当するレコードの存在を判定する（ステップＳ２１１）。レコードが存在しない場合には端子Ｏを介して図３７の処理へ進み、レコードが存在した場合には抽出されたレコードを絞込み情報記憶部に格納する（ステップＳ２１３）。
【０１１３】
次に、ステップＳ１８３で取得した情報を用いて日時（季節、曜日及び時間帯）による検索・絞込みを行い（ステップＳ２１５）、該当するレコードの存在を判定する（ステップＳ２１７）。レコードが存在しない場合には端子Ｏを介して図３７の処理へ進み、レコードが存在した場合には抽出されたレコードを絞込み情報記憶部に格納する（ステップＳ２１９）。
【０１１４】
次に、ステップＳ１８５で取得した情報を用いて渋滞情報及び天候情報による検索・絞込みを行い（ステップＳ２２１）、該当するレコードの存在を判定する（ステップＳ２２３）。レコードが存在しない場合には端子Ｏを介して図３７の処理へ進み、レコードが存在した場合には抽出されたレコードを絞込み情報記憶部に格納する（ステップＳ２２５）。
【０１１５】
次に、ステップＳ１８１で取得した情報を用いてユーザ属性及び車種による検索・絞込みを行い（ステップＳ２２７）、該当するレコードの存在を判定する（ステップＳ２２９）。レコードが存在しない場合には端子Ｏを介して図３７の処理へ進み、レコードが存在した場合には抽出されたレコードを絞込み情報記憶部に格納する（ステップＳ２３１）。
【０１１６】
次に、ここまでの処理が１回目のルート設定処理かどうか判定し（ステップＳ２３３）、１回目であれば例えば「ルート上に事故多発場所が存在するので、迂回ルートを設定しますか？」というメッセージを利用者に対して出力し（ステップＳ２３５）、２回目以降であれば例えば「ルート上に事故多発場所が存在するので、再度迂回ルートを設定しますか？」というメッセージを出力し（ステップＳ２３７）、利用者の判断を促す。
【０１１７】
利用者が迂回ルート生成を選択したか判定し（ステップＳ２３９）、迂回ルート生成を選択しなかった場合には端子Ｏを介して図３７の処理へ進む。迂回ルート生成を選択した場合には絞込み情報記憶部のレコードの場所ＮＯ．の列２０５０の値を用いて事故多発場所テーブル（図５）を検索し、該当レコードを迂回場所記憶部に追加格納して（ステップＳ２４１）、ステップＳ１８９からの処理を繰り返す。
【０１１８】
また、端子Ｏを介して遷移した処理については、迂回ルートの生成によって危険な場所が存在しなくなったか、危険な場所があってもよいと利用者が判断した場合である。まずは生成したナビゲーションルートを表示し（ステップＳ２４３）、生成したルートに従ったナビゲーションを開始する（ステップＳ２４５）。なお、迂回場所記憶部のデータは、この時点でクリアする。
【０１１９】
ナビゲーション開始後も、一定時間毎に位置、渋滞及び天候の情報を取得し、ユーザ属性及び車種情報とあわせて事故情報を検索し、必要に応じて警告メッセージを出力する（ステップＳ２４７）。すなわち、実施の形態２で説明した処理を実行する。
【０１２０】
このようにすると、利用者が目的地を設定してナビゲーションルートの生成を要求した場合に、標準機能で生成したルート上に、利用者に対して警告メッセージを出力すべき場所がある場合には、利用者に通知することが可能となる。また、利用者にとって危険な場所を迂回するルートを生成しなおすことが可能となる。
【０１２１】
以上本発明の一実施の形態を説明したが、本発明はこれに限定されるものではない。例えば、図１及び図３２に示したシステム構成は一例であって他の構成であっても図１及び図３２に示した各実施パターンを実現することができればよい。例えば気象情報、渋滞情報を受信するまでの仕組みとして、衛星放送等を利用したものであってもよい。また、ＤＢ構成についても一例であって同様のデータを格納するためであれば、非正規化するなど別の構成を採用するようにしてもよい。
【０１２２】
また、各ＤＢテーブルに格納されるデータも一例であって、変更や追加等があってもよい。例えば、図１３に示した週間運行距離テーブルの例において、格納されるデータを細分化して、「２０ｋｍ未満」、「２０ｋｍ〜５０ｋｍ」、「５０ｋｍ〜１００ｋｍ」及び「１００ｋｍ以上」とするような構成であってもよい。また、図１４及び図１５に示した事故歴フラグ・テーブル及び違反歴フラグ・テーブルの例では、過去３年間における事故歴又は違反歴についての判定条件を含んでいるが、過去３年間というのは一例であって、何年間に設定してもよい。また、図１５に示した違反歴フラグ・テーブルの例において、格納されるデータを細分化して、「無違反」、「速度超過あり」、「信号無視あり」、「追い越し違反あり」、「進路変更禁止違反あり」及び「その他違反あり」とするような構成であってもよい。
【０１２３】
また、図４に示したメッセージ・テーブルの例では、メッセージの列４７０には音声出力用のデータが含まれるような構成となっているが、メッセージを文字データで格納する列又は別のテーブルを設け、警告時に画面表示させるような構成であってもよい。この場合、例えば「落輪注意」等、簡潔なメッセージを格納しておけば、運転者は一瞬表示装置を参照するだけで、メッセージを理解できるようになる。なお、フロントガラスの一部に短時間メッセージを表示して注意を呼びかけるような構成でもよい。
【０１２４】
また、図１６に示した季節テーブルの例において、「ゴールデン・ウイーク（４月２９日前後〜５月６日前後）」、「お盆の帰省ラッシュ時（８月１２日前後及び８月１５日前後）」及び「年末年始の帰省ラッシュ時（１２月３０日前後及び１月３日前後）」を含めるような構成であってもよい。なお、これらの日付は年によって変動するため、管理者等によって少なくとも１年に１回、日付データが登録し直されるような構成であってもよい。同様に、図１９に示した時間帯テーブルの例において、「薄暮時」を含めるような構成であってもよい。なお、この時間帯は地域や季節によって変動するため、例えば地域別にテーブルを分け、管理者等によって例えば３ヶ月に１回、時間帯データが登録し直されるような構成であってもよい。
【０１２５】
また、ユーザ属性やその他の事故情報検索条件についても一例であって、事故に関連する要素が他にあれば検索条件に追加するようにしてもよい。例えば、走行速度や停車時の車体の向きに関する情報を取得し、停車時や減速時において追突されやすい条件に合致する場合には、その旨をメッセージ出力するような構成であってもよい。同様に、走行車線に関する情報を取得し、事故が起こりやすい条件に合致する場合には、その旨をメッセージ出力するような構成であってもよい。
【０１２６】
また、車載機についての実施の態様を説明したが車載機に限定されるものではなく、徒歩や自転車で使用できるような携帯情報端末等であってもよい。この場合は車種テーブル（図９）に徒歩や自転車のレコードを追加する。また、情報を提供する各サーバは１台に限らず、複数台による構成であってもよい。例えば保険会社サーバ１５（又は２５）が数台あってもよいし、渋滞情報サーバ１９（又は２９）が数台あるような構成でもよい。
【０１２７】
【発明の効果】
以上述べたように、本発明によれば、交通事故防止のための情報処理技術を提供することができた。
【図面の簡単な説明】
【図１】本発明の一実施の形態におけるシステム概要図である。
【図２】事故情報テーブルの構成及び格納されるデータの一例を示す図である。
【図３】ユーザ属性テーブルの構成及び格納されるデータの一例を示す図である。
【図４】メッセージ・テーブルの構成及び格納されるデータの一例を示す図である。
【図５】事故多発場所テーブルの構成及び格納されるデータの一例を示す図である。
【図６】住所属性フラグ・テーブルの構成及び格納されるデータの一例を示す図である。
【図７】性別フラグ・テーブルの構成及び格納されるデータの一例を示す図である。
【図８】年齢テーブルの構成及び格納されるデータの一例を示す図である。
【図９】車種テーブルの構成及び格納されるデータの一例を示す図である。
【図１０】夜間視力テーブルの構成及び格納されるデータの一例を示す図である。
【図１１】免許年数テーブルの構成及び格納されるデータの一例を示す図である。
【図１２】週間運行日数テーブルの構成及び格納されるデータの一例を示す図である。
【図１３】週間運行距離テーブルの構成及び格納されるデータの一例を示す図である。
【図１４】事故歴フラグ・テーブルの構成及び格納されるデータの一例を示す図である。
【図１５】違反歴フラグ・テーブルの構成及び格納されるデータの一例を示す図である。
【図１６】季節テーブルの構成及び格納されるデータの一例を示す図である。
【図１７】曜日テーブルの構成及び格納されるデータの一例を示す図である。
【図１８】天候テーブルの構成及び格納されるデータの一例を示す図である。
【図１９】時間帯テーブルの構成及び格納されるデータの一例を示す図である。
【図２０】渋滞状況フラグ・テーブルの構成及び格納されるデータの一例を示す図である。
【図２１】進行方向テーブルの構成及び格納されるデータの一例を示す図である。
【図２２】進行予定テーブルの構成及び格納されるデータの一例を示す図である。
【図２３】本発明の実施の形態１における概要処理フローを示す図である。
【図２４】本発明の実施の形態１における処理フローを示す図である。
【図２５】事故情報ＤＢ検索における処理フロー（その１）を示す図である。
【図２６】事故情報ＤＢ検索における処理フロー（その２）を示す図である。
【図２７】事故情報ＤＢ検索における処理フロー（その３）を示す図である。
【図２８】事故情報ＤＢ検索における処理フロー（その４）を示す図である。
【図２９】事故情報ＤＢ検索における処理フロー（その５）を示す図である。
【図３０】事故情報ＤＢ検索における処理フロー（その６）を示す図である。
【図３１】警告メッセージ生成・格納処理における処理フローを示す図である。
【図３２】本発明の実施の形態２におけるシステム概要図である。
【図３３】本発明の実施の形態２における処理フローを示す図である。
【図３４】本発明の実施の形態３における処理フロー（その１）を示す図である。
【図３５】本発明の実施の形態３における処理フロー（その２）を示す図である。
【図３６】本発明の実施の形態３における処理フロー（その３）を示す図である。
【図３７】本発明の実施の形態３における処理フロー（その４）を示す図である。
【符号の説明】
１１，２１　ネットワーク　　１３，２３　車載機
１５，２５　保険会社サーバ　　１７，２７　ＧＰＳ衛星
１９，２９　渋滞情報サーバ　　２０　事故情報番号の列
３０　ユーザＩＤの列　　４０　メッセージ番号の列
５０　事故多発場所番号の列　　５２　場所名の列
５４　位置の列　　８０　年齢番号の列　　８２　年齢の列
９０　車種番号の列　　９２　車種の列
１１０　免許年数番号の列　　１１１，２１１　気象情報会社サーバ
１１２　年数の列　　１２０　週間運行日数番号の列
１２２　運行日数の列　　１３１，２３１　車載機ＨＤＤ
１３３　ＩＣカードリーダ・ライタ　　１３４，２３４　表示装置
１３５，２３５　ＧＰＳアンテナ　　１３７，２３７　渋滞情報受信アンテナ
１３９，２３９　気象情報受信アンテナ　１５５，２５５　事故情報ＤＢ
１６０　季節番号の列　　１６２　期間始の列　　１６４　期間終の列
１６６　季節の列　　１７０　曜日番号の列　　１７２　曜日の列
１８０　天候番号の列　　１８２　天候の列　　１９０　時間帯番号の列
１９２　始の列　　１９４　終の列　　１９６　時間帯の列
２１０　進行方向番号の列　　２１２　進行方向の列
２２０　進行予定番号の列　　２２２　進行予定の列
３１０　性別の列　　３２０　年齢の列　　３２５　住所の列
３３０　車種の列　　３４０　夜間視力の列　　３５０　免許年数の列
３６０　週間日数の列　　３７０　週間距離の列　　３８０　事故歴の列
３９０　違反歴の列　　４７０　メッセージの列
１３００，２３００　自動車　　１３３０，２３３０　ＩＣカード
２０５０　場所ＮＯ．の列　　２０６０　住所属性の列
２０７０　性別の列　　２０８０　年齢の列　　２０９０　車種の列
２１００　夜間視力の列　　２１１０　免許年数の列
２１２０　週間日数の列　　２１３０　週間距離の列
２１４０　事故歴の列　　２１５０　違反歴の列　　２１６０　季節の列
２１７０　曜日の列　　２１８０　天候の列　　２１９０　時間帯の列
２２００　渋滞状況の列　　２２１０　進行方向の列
２２２０　進行予定の列　　２０４０メッセージの列
【図１】
2004094444.tif 000003
【図２】
2004094444.tif 000004
【図３】
2004094444.tif 000005
【図４】
2004094444.tif 000006
【図５】
2004094444.tif 000007
【図６】
2004094444.tif 000008
【図７】
2004094444.tif 000009
【図８】
2004094444.tif 000010
【図９】
2004094444.tif 000011
【図１０】
2004094444.tif 000012
【図１１】
2004094444.tif 000013
【図１２】
2004094444.tif 000014
【図１３】
2004094444.tif 000015
【図１４】
2004094444.tif 000016
【図１５】
2004094444.tif 000017
【図１６】
2004094444.tif 000018
【図１７】
2004094444.tif 000019
【図１８】
2004094444.tif 000020
【図１９】
2004094444.tif 000021
【図２０】
2004094444.tif 000022
【図２１】
2004094444.tif 000023
【図２２】
2004094444.tif 000024
【図２３】
2004094444.tif 000025
【図２４】
2004094444.tif 000026
【図２５】
2004094444.tif 000027
【図２６】
2004094444.tif 000028
【図２７】
2004094444.tif 000029
【図２８】
2004094444.tif 000030
【図２９】
2004094444.tif 000031
【図３０】
2004094444.tif 000032
【図３１】
2004094444.tif 000033
【図３２】
2004094444.tif 000034
【図３３】
2004094444.tif 000035
【図３４】
2004094444.tif 000036
【図３５】
2004094444.tif 000037
【図３６】
2004094444.tif 000038
【図３７】
2004094444.tif 000039