JPWO2005069675A1 - 運転中における電話使用時の電話対策装置及び電話対策方法 - Google Patents

Abstract

【課題】ドライバの通話のみを自動的に抑制するのに好適な運転中電話対策装置及び運転中電話対策方法を提供する。【解決手段】データベース３とドライバ判定部とモード切り替え部が設けられ、データベース３には、ドライバごとに、そのドライバの顔データ３−１と該ドライバが使用する携帯電話７の電話番号３−２が登録され、ドライバ判定部では、顔面認証によりデータベース３の中から現在の車輌のドライバを特定し、モード切り替え部では、その特定したドライバが使用する携帯電話７の電話番号３−２をデータベース３から抽出し、その電話番号を用いて当該ドライバの携帯電話７を留守番モードなどのドライブモードに切り替えるものとする。【選択図】図１

Description

本発明は、車内での通話を自動で抑制するようにした運転中電話対策装置及び運転中電話対策方法に関する。

近年、携帯電話の普及に伴い、ドライバによる運転中の通話が問題となっている。この問題に鑑み、運転中の携帯電話による通話は法律で禁止されたが、法律を遵守しないドライバも少なくない。このような問題を解決する方法として、運転中であることを検知した場合に、予め登録された携帯電話を自動的に留守番モードに切り替える発明が出願されている（例えば特許文献１参照）。また、車内での通話を防止するために、妨害電波を車内に出す発明も出願されている（例えば特許文献２参照）。

しかしながら、上記従来方法では、ドライバのみならず車内の同乗者の通話も抑制されるおそれがある。車内での通話を抑制する必要があるのはドライバの通話のみであり、同乗者の通話を抑制する必要はない。また、携帯電話の番号を登録したドライバが助手席等に乗っている場合も、その電話機の通話を抑制する必要はない。

特開２００１−１９７５５６号公報

国際公開第０１／０８３２８号パンフレット

本発明は上述の事情に鑑みてなされたもので、その目的とするところは、ドライバの通話のみを自動で有効に抑制するのに好適な運転中電話対策装置及び運転中電話対策方法を提供することにある。

上記目的を達成するために、本発明は、ドライバの顔データと該ドライバが使用する携帯通信機器の識別情報をドライバごとに登録したデータベースと、顔面認証により上記データベースの中から現在の車輌のドライバを特定するドライバ特定手段と、上記ドライバ特定手段により特定したドライバが使用する携帯通信機器の識別情報を上記データベースから抽出し、その識別情報を用いて当該ドライバの携帯通信機器をドライブモードに切り替えるモード切り替え手段とを具備することを特徴とする。

本発明では、顔面認証によりデータベースの中から現在の車輌のドライバが特定されるとともに、この特定されたドライバが使用する携帯通信機器の識別情報が同データベースから抽出され、この抽出した識別情報を用いて当該ドライバの携帯電話が留守番モードなどのドライブモードに切り替えられる。従って、ドライバの携帯通信機器が自動的に運転時に留守番モードなどのドライブモードに移行するため、ドライバによる運転中の通話を有効に抑制することができる。さらに、データベースにドライバとして登録されている者であっても、車輌の運転を行っていない場合は自己の携帯通信機器を自由に使用することができ、ドライバとして実際に車輌を運転するときだけ自己の携帯通信機器が自動的に留守番モードなどのドライブモードに切り替えられ、その通話が抑制される。

また、本発明では、携帯通信機器が自動的に留守番モードなどのドライブモードに切り替えられ、その通話が抑制された後に、一定時間を越えてドライバを特定できなくなった際に、ドライバが下車したなどとして、携帯通信機器のドライブモードを解除することにより、ドライブモードを設定する以前の状態に戻すようにしてもよい。これにより携帯通信機器を通常に使用することが可能となる。つまり、ドライバの携帯電話による通話が禁止されるのは運転中の通話だけなので、車輌が停止している場合においては留守番モードなどのドライブモードを解除する。

信号で停止するたびにドライブモードの解除が繰り返されると、信号待ちの状態で通話が開始される可能性がある。単に車輌が停止したことだけを条件としてドライブモードを解除するのではなく、車輌の停車時間が一定時間以上継続した場合、エンジンが停止した場合、ドアが開いた場合等から条件を選択してドライブモードの解除を行う構成としてもよい。

上記「ドライブモード」には、留守番モードとハンズフリーモードが含まれ、これらは必要に応じて適宜自動的に選択される。「留守番モード」には、指定された携帯電話にメールや通話呼び出しがかかった場合であっても、当該携帯電話に接続せず、メールを電話局あるいはメールセンタ内等に一時的に留め置くようにすること、若しくは、当該携帯電話を呼び出した者に対して携帯電話のユーザが対応できない旨を伝えるようにすること等が含まれる。また、これらのモード以外に、通話やメールの送受信によるドライバの片手運転等不完全な状態での運転を抑制しうるモードも「ドライブモード」に含まれる。

上記「ハンズフリーモード」とは、手を使わずに携帯電話で通話をするモードという意味に解釈される。例えば、ドライバの通話音声を車内のマイクなどで拾ってドライバの携帯電話に伝えるとともに、電話相手方の通話音声を車内のスピーカから流すように設定されるものや、これ以外に手を使わずにドライバが携帯電話で通話できるように設定されるものは、ハンズフリーモードとしてよい。

車輌にハンズフリー機能が装備されていない場合は、ハンズフリーモードへの切り替えは行われない。また、ハンズフリー機能が装備されている場合は、ハンズフリーモードへの切り替えと留守番モードへの切り替えを選択可能とする。この選択はドライバがスイッチなどにより切り替える方式のほか、カメラにより車内全体を撮影し、その撮影画像に基づきドライバしかいないと判断した場合に、ハンズフリーモードへの切り替えが選択されるように設定することもできる。

上記「ドライバの顔データ」とは、データベース内にドライバ顔データとして登録されているドライバの顔特徴量データ等のように、ドライバの顔を特定するデータである。

上記「顔面認証により上記データベースの中から現在の車輌のドライバを特定する」ことには、カメラ等で撮影したドライバの顔撮影画像の中から顔領域を検出するとともに、その検出結果に基づいて当該ドライバの顔の特徴点を抽出し、この特徴点のデータを、データベース内にドライバ顔データとして登録されているドライバの顔特徴量データと順次比較して、予め定めた類似度を越えた者の中で最も一致したドライバを現在の車輌のドライバであると判定すること、を含む。従って、一定以下の類似度のドライバは現在の車輌のドライバ候補から除かれる。その上で更に複数のドライバ候補が存在する場合は類似度の高い方を選択して現在の車輌のドライバと判断する。

上記「携帯通信機器」には、携帯電話、ＰＨＳ、ＰＤＡの他、これら以外の携帯可能な通信機器が含まれる。

上記「携帯通信機器の識別情報」は携帯電話などの電話番号を含む。この場合、前記データベースには電話番号が登録され、その電話番号を用いてドライバの携帯電話をドライブモードに切り替えるが、このドライブモードへの切り替えは電話番号以外の識別番号を用いることもできる。この場合、データベースには電話番号に代えて携帯電話などの識別番号を登録する。また、短距離通信手段としてのブルーツゥースやＵＷＢ等を用いて携帯電話と車輌の間で直接通信を行いドライブモードに切り替える場合等は、その通信手段で使用する識別子を上記データベースに登録する。

上記ドライバの携帯通信機器がドライブモードに切り替えられた際に、その携帯通信機器のキーボードの操作を不可とし、その携帯通信機器の表示画面を無効状態とするように構成してもよい。この構成によると、法律や危険性を無視して携帯電話を使用しようとする悪意の利用者がドライブモードへの設定変更を手動で解除する等、不正な行為を効果的に防止することができ、ドライバによる運転中の携帯電話の利用を確実に防止しうる。

本発明にあっては、上記構成の採用により以下の効果が得られる。
（１）ドライバの携帯通信機器のみが自動的に運転時に留守番モードなどのドライブモードに移行するため、ドライバによる運転中の通話を有効に抑制しうる。
（２）運転をしない者であるにもかかわらず、その者の携帯電話が留守番モードなどのドライブモードに入るという不都合もなく、実際に運転をするドライバの携帯電話だけをドライブモードに切り替えることが可能となる。

以下、本発明を実施するための最良の形態について、添付した図面を参照しながら詳細に説明する。

本実施形態の運転中電話対策装置は、図１に示したように、カメラ１、照明２、データベース３、画像処理ユニット４、車輌コントローラユニット５、通信装置６等を含む。

上記カメラ１は、画像処理ユニット４側に接続されていて、その画像処理ユニット４内のカメラ制御部４−４（図２参照）により制御され、運転席に着座しているドライバの顔とその周辺部を撮影する。従って、このカメラ１はドライバの顔を撮影できる位置、例えば運転席の正面側に配置される。

上記照明２は、画像処理ユニット４に接続されていて、その画像処理ユニット４内の照明制御部４−５（図２参照）により制御され、ドライバの撮影時にドライバの顔を照らして好適な撮影条件が得られるようにする。

上記データベース３は、不揮発性メモリ上に存在する、あるいはハードディスク（ＨＤＤ）上に存在するものであって、画像処理ユニット４や車輌コントローラユニット５からアクセスすることができるように、画像処理ユニット４に接続されている。このデータベース３には、登録されたドライバごとに、そのドライバの顔データ３−１とそのドライバが使用する携帯電話７の電話番号３−２が登録される。データベース３に登録されている上記ドライバの顔データ３−１は、画像処理ユニット４における後述のドライバ特定処理において、現在の車輌のドライバを特定する際に使用され、また、データベース３内に登録されている上記電話番号３−２は、車輌コントローラユニット５における後述のドライブモードへの切り替え処理において、ドライバの携帯電話７を留守番モードに切り替える際に使用される。

図１のデータベース３では、１つの顔データ３−１に対して１つの電話番号が対応して登録される方式となっているが、１人のドライバが複数の携帯電話を所持している場合もあり、このような場合を想定して、図１のデータベース３には１つの顔データ３−１に対して複数の電話番号が対応して登録されるように構成してもよい。

上記データベース３に登録されるドライバの顔データ３−１の中には顔特徴量データが含まれている。この顔特徴量データは、ドライバの特定に必要となるものであって、ドライバの顔の原画像から抽出した目、鼻、口等の器官の中心や端点の位置を示すデータからなる。これ以外の他の観点から顔の特徴を示すデータを使用することもできる。

画像処理ユニット４は、図２に示したようにＣＰＵ４−１、ＲＡＭ４−２、ＲＯＭ４−３、図１のカメラ１を制御するカメラ制御部４−４および図１の照明２を制御する照明制御部４−５等のハードウエア資源を用いて構成される。ＲＡＭ４−２は、ＣＰＵ４−１の処理の際に、変数の値などを記憶するほか、カメラ１が撮影した画像データを記憶等する。ＲＯＭ４−３内には画像処理用のプログラム等が格納されている。ＣＰＵ４−１はＲＯＭ４−３内のプログラムを実行する。これにより、画像処理ユニット４は、図３に示すようにカメラからの画像の読み取りを行う画像読み取り部４Ａや、顔面認証により現在の車輌のドライバを特定するドライバ判定部４Ｂなどを有する装置として機能する。

画像処理ユニット４の画像読み取り部４Ａは、カメラ制御部４−４を介しカメラ１と、照明制御部４−５を介して照明２を制御し、該カメラ１で撮影したドライバの顔画像をデータとしてＲＡＭ４−２内に取り込む。ここで取り込んだドライバの顔撮影画像はドライバ判定部４Ｂでドライバを特定する際に使用される。

画像処理ユニット４のドライバ判定部４Ｂでは、ドライバの顔を認識する顔認識と、その認識したドライバの顔に基づき現在の車輌のドライバを特定する処理を行う。

上記ドライバ判定部４Ｂにおける顔認識では、カメラ１で撮影したドライバの顔撮影画像の中から顔領域を検出し、その検出結果に基づいて当該ドライバの顔の特徴点を抽出する。

顔領域の検出方式としては人間の顔型のグラフを用いる方式がある。この方式は、上記グラフを拡大、縮小しながらドライバの顔撮影画像を走査し、その顔撮影画像上で該グラフが適合する箇所をドライバの顔領域として検出する。これ以外の検出方式で顔領域を検出してもよい。

顔の特徴点は、上記のようにして検出された顔領域の範囲内で目、鼻、口等の器官抽出を行い、その各器官の中心や端点の位置に関連するデータとして算出される。

上記ドライバ判定部４Ｂにおけるドライバの特定は、前の処理で認識したドライバの顔に該当する者がデータベース３にドライバとして登録されているかどうかを判断する処理であり、この処理は、具体的には、前の処理で抽出した顔の特徴点のデータを、データベース３内にドライバ顔データ３−１として登録されているドライバの顔特徴量データと順次比較して、予め定めた類似度を越えた者の中で最も一致したドライバを現在の車輌のドライバであると判定する。ドライバを特定できなかった場合は、撮影状況が悪かったためであるとも考えられるので、上記のような顔認識からドライバ特定までの一連の処理を数回（例えば３回）繰り返す。

車輌コントローラユニット５は、図４に示したようにＣＰＵ５−１、ＲＡＭ５−２、ＲＯＭ５−３並びにＩ／Ｆユニット５−４等のハードウエア資源を用いて構成される。この車輌コントローラユニット５のＲＯＭ５−３には、車輌の制御に関する一般的なプログラムに加え、さらに図７（ａ）に示す電話モード設定処理および同図（ｂ）に示すモード解除処理のプログラムが格納されている。また、この車輌コントローラユニット５のＣＰＵ５−１は、上記ＲＯＭ５−３内の一般的なプログラムを実行するとともに、同ＲＯＭ５−３内の電話モード設定処理およびモード解除処理のプログラムも実行する。また、車輌コントローラユニット５のＲＡＭ５−２には、ＣＰＵ５−１の処理の際に、変数の値などを記憶する。

車輌コントローラユニット５は、そのＣＰＵ５−１によるプログラムの実行により、図５に示すように車輌情報取得部５Ａ、処理開始判断部５Ｂ、モード切り替え部５Ｃ、処理終了判断部５Ｄなどを有する装置として機能する。

車輌コントローラユニット５の車輌情報取得部５Ａは、車輌コントローラユニット５に接続されたセンサ類８から出力される信号や、同車輌コントローラユニット５に接続された制御コントローラ類９から、シートベルトの着脱、車輌ドアの開閉、サイドブレーキの状態、ミッションの位置、車輌速度などの車輌情報を取得する。また、ハンズフリー機能の有無も車輌情報として取得する。従って、この車輌情報の取得との関係から、上記センサ類８の中には、少なくとも、シートベルトの着脱を検出するセンサ、車輌ドアの開閉を検出するセンサ、サイドブレーキの状態を検出するセンサ、ミッションの位置を検出するセンサ、車輌速度を検出するセンサ等が含まれているものとされる。尚、ミッションの位置情報については、トランスミッションの制御コントローラから得られる場合もあり、この場合は当該制御コントローラからミッションの位置情報を取得してもよい。このトランスミッションの制御コントローラは、車輌のコントローラ類９の中に含まれている。

車輌コントローラユニット５の処理開始判断部５Ｂは、車輌情報取得部５Ａで取得した車輌情報を基に、車輌コントローラユニット５において本運転中電話対策装置に係わる処理（以下「本処理」という。）を開始するかどうかを判断する。この判断は、具体的には車輌コントローラユニット５のＣＰＵ５−１の処理として行われる。また、この判断の基本的な考え方としては、車輌情報取得部５Ａにおいてドライバのシートベルト着用が検知されると、車輌コントローラユニット５のＣＰＵ５−１が本処理を開始すべきものと判断する。この判断により図７（ａ）の電話モード設定処理が開始される。従って、ドライバのシートベルト着用時が電話モード設定処理の処理開始条件になる。また、この処理開始判断部５Ｂは、電話モード設定処理の処理開始条件が満たされると、画像処理ユニット４に対して画像読み取り開始を指示する。この指示は、具体的には、車輌コントローラユニット５のＣＰＵ５−１が、Ｉ／Ｆユニット５−５を通じて、画像処理ユニット４に対して指示を与えるものである。

図７（ａ）の電話モード設定処理が開始されると、カメラによるドライバの顔の撮影が行われ、現在の車輌のドライバを特定する処理が行われるが、ドライバの特定が済んでしまえば、カメラでドライバを観察する必要はないので、実際に車輌を運転しようとしているドライバが確定する時点でドライバを撮影し判定すればよい。このため、本実施形態では、上記の如くドライバのシートベルト着用時を図７（ａ）の電話モード設定処理の処理開始条件と考えた。しかしながら、シートベルトを着用しないドライバも存在するため、エンジンが始動し、サイドブレーキが解放され、かつ、ミッションが入ったことを車輌情報取得部５Ａが検知した場合に、同図（ａ）の電話モード設定処理の処理開始と判断することもできる。また、以上のような処理開始条件以外に車輌のドライバが確定する要素を処理開始条件としてもよい。

ところで、上記の如くエンジンの始動も処理開始条件の一要素としたのは、仮にサイドブレーキの解放とミッションの位置のみを処理開始条件とすると、例えば、雪国の場合のように、サイドブレーキを引かずにミッションを入れた状態で停車している場合でも、図７（ａ）の電話モード設定処理が開始されてしまうため、このような事態の発生を防止するものである。

また、以上説明した電話モード設定処理の処理開始条件は一例であり、これら以外に運転開始の蓋然性が高い状況を条件として図７（ａ）の電話モード設定処理を開始してもよい。

車輌コントローラユニット５のモード切り替え部５Ｃは、前記ドライバ判定部４Ｂで特定したドライバ、すなわちデータベース３に登録されているドライバの中から現在車輌を運転する者として特定したドライバを対象とし、このドライバが使用する携帯電話７を留守番モードかハンズフリーモード等のドライブモードに切り替える。この切り替えは、具体的には、車輌コントローラユニット５のＣＰＵ５−１の処理として実行される。尚、車輌情報取得部５Ａでハンズフリー機能が装備されていないことを検知した場合には、ハンズフリーモードへの切り替え処理は行われない。

現在の車輌のドライバが使用する携帯電話７を留守番モードに切り替えようとする場合は、そのドライバが使用する携帯電話７の電話番号を特定しなければならないが、その電話番号は登録されたドライバごとに上記データベース３に登録されているので、モード切り替え部５Ｃでは、データベース３から当該ドライバが使用する携帯電話７の電話番号３−２を指定することができる。

電話番号を特定した後に、その電話番号の携帯電話を留守番モードに切り替える方式については、簡単に説明すると、以下の（１）（２）（３）の手法が考えられる。

（１）車輌コントローラユニット５のＣＰＵ５−１が、車輌に装備された通信装置６を用い、留守番モードに切り替えようとする携帯電話７の電話番号をデータとして電話局１０側に送信し、電話局１０側が、送信されてきた電話番号に基づき対応する携帯電話７を留守番モードにする。

（２）電話局１０の代りに、留守番モードへの切り替えをサービスとして提供するＡＳＰ（Application Service provider）に対して電話番号を通知することにより、その電話番号に対応する携帯電話７を留守番モードにする。

（３）車輌コントローラユニット５のＣＰＵ５−１が、車輌に装備された通信装置６を利用して、車輌と携帯電話７との間で通信を行って携帯電話７を留守番モードにする。

上記（１）から（３）の方法を詳細に説明すると、以下の通りである。

上記（１）の方法は、車輌の通信装置６が、電話局１０と通信を行い、データベース３に登録されたドライバと対応する携帯電話７の識別子（電話番号）を電話局１０側に送信する。それに応じ、電話局１０側においては、送信されてきた識別子に基づき指定された携帯電話にメールや通話呼び出しがかかった場合であっても、当該携帯電話７には接続せず、メールを電話局１０内に一時的に留め置く、若しくは、当該携帯電話７を呼び出した者に対して携帯電話７のユーザが対応できない旨を伝えることにより、留守番モードを実現する。

さらに、携帯電話７側からの発信を抑制するために、電話局１０は、携帯電話７側に対して、留守番モードに移行したことを示すデータを送信し、携帯電話７側は、この信号を受けて留守番モードに移行し、発信やメールの作成を抑制するために携帯電話７の操作部７−１（図６参照）からの入力信号を停止するなどの処理を行う。

つまり、留守番モードに移行すると、携帯電話７の操作部７−１を通じてメールを作成し送信することや、受信メールを表示すること等もできなくなり、メールの利用が抑制される。

通常、携帯電話７は電話局１０と電波を用いて通信を行っている。携帯電話７は、図６に示したように、アンテナ７−２で受信した電話局１０からの電波を受信回路７−３によって検波などを行い、搬送波から通信信号を取り出す。また、この携帯電話７において、通信モード切替機７−４は、受信回路７−３から受取った通信信号の内容に従い、音声通信かデータ通信かの切り替えを行う。そして、音声通信の場合は、通信信号を音声入出力部７−５に接続し、呼び出し音を発生するなどして会話を開始する。一方、データ通信の場合は、通信信号を制御回路７−６側に接続し、表示装置７−７に表示するなどして通信を行う。

電話局１０側が留守番モードに移行した際には、電話局１０から、まず、データ通信である旨の信号を送信し、それに続き、留守番モードに移行したことを示すデータを送信する。携帯電話７側は、これらのデータに従い、データモードに切り替えた後、留守番モードに切り替えた旨を表示装置７−７において表示する。更に、モードが切り替わったことをドライバであるユーザに知らせるために、音声入出力部７−５のスピーカにより音を発することもできる。

上記（２）の方法の場合は、基本的に上記（１）と同様であり、サービスの主体が異なる。

上記（３）の方法は、車輌に搭載された通信装置６と携帯電話７が直接通信することにより、留守番モードに移行するものである。具体的には、ブルーツゥース等の近距離用の通信装置若しくは回路を車輌側と携帯電話側に設け、この近距離通信装置若しくは回路により通信を行い、携帯電話７を留守番モードに移行させる。この場合、携帯電話７は、車輌側から発せられた電波を、携帯電話７側の近距離通信用アンテナ７−８で受信し、この受信信号を近距離通信回路７−９により検波などの処理を行い、取り出した通信信号を制御回路７−６に送る。制御回路７−６は受信した通信信号に基づき携帯電話７を留守番モードに切り替える。この際、車内に複数の携帯電話が存在することが当然に考えられるので、電話局経由で通信を行うのと同様に、データベース３から得た識別子を用いて通信をすることが必要である。

本実施例においては、近距離通信用アンテナ７−８を別途設けたが、電話局１０との通信周波数などにより、電話局１０側との通信アンテナ７−２と共用することを否定するものではない。

以上のモード切り替え手法は一例であり、それら以外の手法で携帯電話７を留守番モードに切り替えてもよい。

留守番モードに切り替えるかハンズフリーモードに切り替えるかの選択は、車内の状況に応じて決定される。すなわち、ドライバが一人で運転をする場合は、ハンズフリーモードへの切り替えが選択される。かかる場合は、同乗者がいないので車内に電話相手方の通話音声を流しても、電話相手方の通話を第三者に聞かれるといったおそれがないからである。それ以外の場合は、留守番モードへの切り替えが選択される。同乗者の有無を検出する方式としては、図１のカメラ１により車内全体を撮影し、その撮影画像に基づき同乗者の有無を検出する方式のほか、例えば、車内の座席に着座したことを検知する着座センサで同乗者の有無を検出する方式等を採用してもよく、同乗者の有無を検出できるものであればその方式を問わずに採用することができる。

本実施例においては、ドライバ以外の第三者が存在する場合は、ハンズフリーモードに切り替えないこととした。しかし、通話内容によっては乗車している者が通話に参加した方がよい場合があるため、ドライバの選択によりハンズフリーモードを選択できる構成としてもよい。

車輌コントローラユニット５の処理終了判断部５Ｄは、車輌情報取得部５Ａで取得した車輌情報を基に、車輌コントローラユニット５における本処理を終了すべきか否かを判断する。この判断は、具体的には車輌コントローラユニット５のＣＰＵ５−１の処理として行われる。また、この判断は、車輌情報取得部５Ａにおいてドライバによるシートベルト解放および車輌の停車を検知した場合に、車輌コントローラユニット５における本処理を終了と判断するものである。従って、ドライバにおけるシートベルト解放時と車輌停車時という２つの条件が満たされることが本処理の処理終了条件となる。シートベルトを着用しないドライバの存在も想定されるので、イグニッションキーがＯＦＦ若しくは抜かれた場合を処理終了条件としてもよい。

ここで、上記「車輌停車時」とは、エンジンが停止した場合、または、サイドブレーキが引かれ、かつミッションがニュートラルとなった場合等のように、車輌が直ちに再び走行し始めるという懸念が殆どない状況を意味するものと解釈される。かかる懸念がなくなれば、携帯電話での通話を抑制する必要がないからである。

ドライバがデータベース３に登録されている者であると否とにかかわらず、運転開始の時点で、車輌コントローラユニット５における本処理はその殆どが終了する。残された処理は、ドライバが車輌から降りる時点で、そのドライバの携帯電話７が図７（ａ）の電話モード設定処理によってドライブモードとしての留守番モードに設定されていれば、それを通常の元のモードに戻す復旧処理である。従って、上記のような処理終了条件が満たされた場合であって、かつ、同図（ａ）の電話モード設定処理によりドライバの携帯電話７が留守番モードに切り替えられていたときは、かかるドライブモードを解除する処理として、同図（ｂ）のモード解除処理を実行し、そのドライバの携帯電話７を通常の元のモードに復旧させた後に、本処理を終了する。

図１３は図１に示す通信装置６の構成図である。この通信装置６は、バス６−１にＣＰＵ６−２、ＲＡＭ６−３、ＲＯＭ６−４、近距離通信部６−５、遠距離通信部６−６等のハードウエア資源が接続される構成となっている。この構成において、近距離通信部６−５は近距離通信手段としてのブルーツゥースとして機能する。遠距離通信部６−６は、例えば（１）運転席に着座しているドライバと携帯電話との対応関係が不明な場合に、外部に問い合わせをしたり、（２）車輌コントローラユニット５等の車載器が把握した事実を外部のセンタに通知したりする等、外部と情報のやり取りを行う手段として機能する。尚、遠距離通信部６−６を利用しない場合は、それを省略してもよい。

遠距離通信部６−５による外部の問い合わせ先としては、下記（Ａ）（Ｂ）（Ｃ）（Ｄ）が考えられるが、これらに限定されることはない。

（Ａ） ドライバの自宅に設置された通信可能なパーソナルコンピュータ
（Ｂ） 携帯電話サービス局またはセンタ
（Ｃ） インターネットサービスプロバイダ（ＡＰＳ）
上記ＡＰＳには、サービスを専業としている場合のみならず、自社の社員のデータを管理している場合、データの内容を特定せず、データを保管している、いわゆるストレージサービスも含む。
（Ｄ） 他の車輌に搭載されている本装置であって、同装置内のデータベースに顔データと携帯電話の電話番号とを一対のデータとして登録済みのもの。

上記（１）の問い合わせ機能の採用により、顔データの登録を重複して行うことなく、本装置が搭載された車輌を運転する際に、運転する車輌そのものにドライバの顔データとドライバに対応する携帯電話の情報がない場合であっても、外部から情報を入手することによって、ハンズフリーを実現することが可能となる。

上記（２）の通知機能の採用により、誰がどの携帯電話をハンズフリーでいつ使用したかといった通話状態の記録を、外部のセンタで集計することが可能となる。他の手段、例えば指紋認証を用いてドライバを特定する方式では、その認証操作忘れなどが発生する可能性があるが、本装置によると、ドライバの顔を自動的に認識するので認証操作忘れが発生する余地はなく、自動的にハンズフリーモード等とすることが可能となるため、上記集計の結果はその信頼性が高い。また、通話状態の記録がセンタに集計されれば、事故発生時にドライバが携帯電話で通話をしていたかどうか、若しくは、ハンズフリーモードで通話をしていたかどうかといった事実を証明することが可能となる。また、多くのドライバが所属する運輸業などにおいては、ドライバごとに運転中の携帯電話使用の管理が可能となる等の効果が得られる。

次に、図７（ａ）の電話モード設定処理と同図（ｂ）のモード解除処理を用いて本実施形態の運転中電話対策装置における全体的な処理の流れを説明する。

ドライバがシートベルトを着用するなど、本処理の処理開始条件が満たされると、図７（ａ）の電話モード設定処理が開始される（ステップ１００）。この処理開始条件が満たされたかどうかは、図５に示した車輌コントローラユニット５の車輌情報取得部５Ａで取得した車輌情報に基づき、車輌コントローラユニット５の処理終了判断部５Ｄで判断される。

そうすると、ドライバの顔認識を行い（ステップ１０１−１）、次にその認識したドライバの顔を基に図１のデータベース３内から該当するドライバを特定する。すなわち、認識したドライバの顔がデータベース３に登録されているドライバの顔と一致するか否かを判断し（ステップ１０１−２）、一致すれば、そのドライバに対応する携帯電話７の電話番号をデータベース３から抽出して番号変数にセットし（ステップ１０１−３）、処理ループを抜け（ステップ１０１−４）、ステップ１０２の処理に移行する。一致しなければ、このステップ１０１−１とステップ１０１−２からなる一連の処理を再実行する（ステップ１０１）。この一連の処理を数回（例えば３回）繰り返しても、データベース３内から該当するドライバを特定することができなかった場合であっても、ステップ１０２の処理に移行する。上記のようなドライバの顔認識とドライバの特定に関わる処理は、図５等に示した画像処理ユニット４のドライバ判定部４Ｂで行われる。尚、上記の如く携帯電話７の電話番号がセットされる番号変数の記憶領域は、車輌コントローラユニット５のＲＡＭ５−２上に設けられる。

ステップ１０２では、上記番号変数に携帯電話７の電話番号がセットされたか否かを判定し、セットされていれば、さらにハンズフリー機能が存在するか否かを判定し（ステップ１０３）、ハンズフリー機能が存在しないならば、そのドライバの携帯電話７を留守番モードに切り替え（ステップ１０４）、処理を終了する（ステップ１０８）。この一方、ハンズフリー機能が存在するならば、ドライバが一人で運転しているか否かを判定する（ステップ１０５）。そして、ドライバが一人で運転しているならば、そのドライバの携帯電話７をハンズフリーモードというドライブモードに切り替え（ステップ１０６）、処理を終了する（ステップ１０８）。ドライバが一人で運転していないならば、そのドライバの携帯電話７を留守番モードというドライブモードに切り替え（ステップ１０７）、処理を終了する（ステップ１０８）。

ハンズフリー機能が存在するか否かの上記判定は、図５に示した車輌コントローラユニット５の車輌情報取得部５Ａで取得したハンズフリー機能の有無情報に基づき、車輌コントローラユニット５のモード切り替え部５Ｃで行なわれる。また、ドライバが一人で運転しているか否かの上記判定も、車輌コントローラユニット５のモード切り替え部５Ｃで行なわれるが、この判定を行うには、車輌コントローラユニット５において同乗者の有無の情報を取得することが必要となる。この点については、例えば、車内の座席に着座したことを検知する着座センサで同乗者の有無を検出する方式の場合、車輌コントローラユニット５では、その車輌情報取得部５Ａで着座センサから同乗者の有無情報を取得し、この同乗者の有無情報に基づきドライバが一人で運転しているか否かを判定する。また、上記のような留守番モードへの切り替え処理や、ハンズフリーモードへの切り替え処理は、車輌コントローラユニット５のモード切り替え部５Ｃで行なわれる。

尚、ステップ１０２における判定時に、番号変数に携帯電話の電話番号がセットされていない場合、すなわちドライバを特定できなかった場合、そのまま処理を終了する（ステップ１０８）。

ドライバにおけるシートベルト解放と車輌停車という条件が満たされるなど、本処理の処理終了条件が満たされると、ドライブモードを解除する処理として、図７（ｂ）のモード解除処理が開始される（ステップ２００）。この処理終了条件が満たされたかどうかは、図５に示した車輌コントローラユニット５の車輌情報取得部５Ａで取得した車輌情報に基づき、車輌コントローラユニット５の処理終了判断部５Ｄで判断される。

図７（ｂ）のモード解除処理が開始されると、最初に、前の電話モード設定処理により番号変数に携帯電話の電話番号がセットされたか否かを判定し（ステップ２０１）、セットされたならば、その電話番号の携帯電話７、すなわち前記電話モード設定処理により留守番モードに切り替えられたドライバの携帯電話７を通常の元のモードに切り替え（ステップ２０２）、処理を終了する（ステップ２０３）。セットされなかったならば、そのまま処理を終了する（ステップ２０３）。この元のモードへの切り替え処理も、図５に示した車輌コントローラユニット５におけるＣＰＵ５−１の処理として行なわれる。

上記実施形態においては、ドライバにおけるシートベルト解放時と車輌停車時という２つの条件が満たされること、または、イグニッションキーがＯＦＦ若しくは抜かれたことを、本処理すなわち車輌コントローラユニット５における本運転中電話対策装置に係わる処理の終了条件とし、かつ、当該ドライバの携帯電話７が留守番モード等のドライブモードに切り替えられた後で、この終了条件が満たされた場合に、そのドライブモードを解除する、すなわちドライバの携帯電話７を、ドライブモードを設定する以前の状態に戻すという構成を採用した。これとは別に、画像処理ユニット４のドライバ判定部４Ｂにおいて一定時間を越えてドライバを特定できなくなったことを、本処理の処理終了条件として用いて、上記のようなドライブモードの解除を行うように構成してもよい。このような構成を採用する場合には、例えば、ドライバの特定後も、継続的にカメラ１でドライバを観察するとともに、画像処理ユニット４のドライバ判定部４Ｂにおいて、定期的にドライバを特定する処理が行われるようにする。そして、このような定期的なドライバの特定処理において、ドライバを特定することができない状態が継続し、ドライバ特定不可状態の時間が一定時間を越えたならば、ドライバが下車したなどとして、携帯電話７のドライブモードを解除する。この構成において、上記一定時間は、予め実験等により決められ、データとして画像処理ユニット４のＲＯＭ４−３等に格納される。また、一定時間を越えてドライバを特定できなかったかどうかの判定は、画像処理ユニット４のＣＰＵ４−１による処理として実行される。そして、一定時間を越えてドライバを特定できなかった場合に、その旨の情報が画像処理ユニット４から車輌コントローラユニット５側に送出され、また車輌コントローラユニット５は、かかる情報を取得した場合に、上記のようなドライブモードの解除を行うものとする。

本実施例においては、データベース３が車輌内に存在するとして説明したが、何者かによるデータの読み出し若しくは書き換えがより困難となるように、かかるデータベース３を車外に設け、通信によりその車外のデータベースからデータを呼び出してドライバを特定する構成としてもよい。この場合においては、通信時のデータが盗聴される事も考えられるので、通信データを暗号化することが望ましい。

また、データベースを車内に設置する場合であっても、顔データや携帯電話番号データを暗号化するなど、データの保護対策を講じることが望ましい。

ところで、上記のようにデータベース３を車外に設ける場合は情報漏洩の問題に留意しなければならない。図１に示したように、データベース３にはドライバの顔データ３−１と携帯電話番号３−２とが一対として登録されている。このようなデータベース３を車外に設ける場合は、その顔データ３−１や携帯電話番号３−２といった個人情報は分割しておいた方がよい。情報が漏洩した際の被害を軽減することができるからである。

図１４は、図１に示したデータベース３のドライバの顔データ３−１と携帯電話番号３−２を分割して設ける場合の説明図である。この図の例では、個人を特定するＩＤとその個人に対応する顔データとを一対として構成される顔データ対応表、ならびに、これとは別のデータとして、個人を特定するＩＤとその個人が使用する携帯電話を特定するための識別子（本例では電話番号）とを一対として構成される携帯電話番号対応表を、図示しない車外のデータベースに保有させるものとしている。そして、運転席に着座したドライバの顔を撮影し、データベース３を検索しても当該ドライバの顔データが存在しなかったときは、遠距離通信部６−６を通じて外部に接続し、当該ドライバの顔データに対応する個人のＩＤを検索するとともに、この検索によって求められたＩＤに基づき、上記車外のデータベースを検索するのが望ましい。このような構成を採用した場合には、個人の顔データと携帯電話の識別子が別々のデータとして分割保管されるので、情報漏洩による被害の軽減を図れる。尚、上記検索により得られた顔データと携帯電話の識別子を一対のデータとして上記データベース３に登録してもよい。この場合、上記一対のデータは、当該ドライバの携帯電話を復帰する処理、すなわち、通常の元のモードに切り替える処理が行われるまでの間だけ一時的に上記データベース３に登録保管されるものとしてもよい。

以上説明した実施例における構成では、ドライバが認識されるとそのドライバの携帯電話が留守番モードまたはハンズフリーモード等のドライブモードに設定されるが、その携帯電話の操作によりドライブモードを解除したり通話したりすることが可能になってしまう。つまり、当該携帯電話は、操作できる状態であって、かつ、その画面が表示された状態となっている。従って、運転中においても、当該携帯電話の操作は可能で、その画面を見ることも可能であるため、安全に十分配慮した動作にはなっていない。

上記実施例における構成によると、法律を遵守しようとする利用者にとっては運転席に乗れば自動的に留守番モード等のドライブモードに設定変更され、運転席以外に乗れば普通に通話できる通常モードで携帯電話を使えるので便利である。しかし、法律や危険性を無視して携帯電話を使用しようとする利用者にとっては、そのドライブモードへの設定変更を容易に回避できる対策にしかなっていないので、ドライバによる運転中の携帯電話の利用を確実に防止することはできない。運転中にドライバが携帯電話を操作して留守番モード等のドライブモードになっている携帯電話を通常モードに戻して、ハンズフリー装置を使わずに当該携帯電話を利用することは、普通に携帯電話を使う操作よりも遥かにドライバの運転上の注意力を散漫にさせる。留守番モード等の解除操作は一般に複雑だからである。

上記のような不具合を解決しドライバによる運転中の携帯電話の利用を確実に防止する手段としては、顔認識手段がドライバの顔画像を使ってドライバを認証したとき、すなわち、ドライバ判定部４Ｂで顔面認証により現在の車輌のドライバを特定したときに、そのドライバの携帯電話に対して運転中制限状態に移行する指示を送ることで、この指示に基づき当該携帯電話が運転中制御状態になるように構成すればよい。「運転中制御状態」とは携帯電話のキーボードの操作ができなくなり、その携帯電話の表示画面に見るべき情報が表示されない状態等、その表示画面が無効状態となるものである。そして、車輌停車時や駐車中等、通話をしても支障のない安全な状態を認識したときに、上記運転中制限状態は解除されるものとしてよい。通話をしても支障のない安全な状態か否かは、車輌コントローラユニット５のＣＰＵ５−１が、車輌情報取得部５Ａで取得した車輌情報を基に判断する。

運転中制御状態は、上記のように、運転者が運転以外に操作に集中したり、操作をしたり、携帯電話を手に取ったり、するような動作を禁止することを意味する。

禁止すべきものとしては、たとえば、ゲームアプリの起動、テレビ放送の表示、目覚し時計のアラームなどが在る。これらは、操作しなくても起動されるからである。

ＦＭ放送を聞く場合や、携帯電話の中にある音楽を聞くなど、手に取った操作や画面の注視を必要としないもので、ボイスコマンドなどハンズフリーで実行できるものを除外してもよい。

図９は、留守番モードへの切り替え処理を示したフローチャートである。このフローチャートによると、最初に、ドライバの携帯電話を留守番モードに切り替える（ステップ９−１）。そして、車輌にハンズフリー装置が搭載されているか否かを判断し（ステップ９−２）、それが搭載されていないときは（ステップ９−２のＮＯ）、当該ドライバの携帯電話に対して運転中制限状態に移行する指示を送ることにより、その携帯電話でのメールやアプリケーションプログラムの利用を禁止し（ステップ９−３）、その携帯電話のキーボードをロックし（ステップ９−４）、さらに、その携帯電話の画面表示を無効状態とする（ステップ９−５）。尚、車輌にハンズフリー装置が搭載されているときは（ステップ９−２のＹＥＳ）、上記ステップ９−３〜９−５をスキップする。

以上説明した図９の留守番モードへの切り替え処理によると、ドライバの携帯電話が留守番モードに切り替わったときに、その携帯電話でのメールやアプリケーションプログラムの利用が禁止されるとともに、その携帯電話のキーボードがロックされ、その携帯電話の表示画面が無効状態になるから、ドライバによる運転中の携帯電話の利用を確実に防止することができる。

図１０は、ブルーツゥースでハンズフリーモードに切り替える際の切り替え処理を示したフローチャートである。このフローチャートによると、最初に、携帯電話の音声入力と出力をブルーツゥース経由に切り替える（ステップ１０−１）。そして、ブルーツゥース対応のハンズフリー装置が車輌に搭載されているか否かを判断し（ステップ１０−２）、それが搭載されているときは（ステップ１０−２のＹＥＳ）、当該ドライバの携帯電話に対して運転中制限状態に移行する指示を送ることにより、その携帯電話のキーボードをロックし（ステップ１０−３）、その携帯電話の画面表示を無効状態とする（ステップ１０−４）。尚、ブルーツゥース対応のハンズフリー装置が車輌に搭載されていないときは（ステップ１０−２のＮＯ）、ステップ１０−３と１０−４の処理をスキップする。

以上説明した図１０のハンズフリーモードへの切り替え処理によると、ドライバの携帯電話がハンズフリーモードに切り替わったときに、その携帯電話のキーボードがロックされ、かつ、当該携帯電話の表示画面が無効状態になるから、ドライバによる運転中の携帯電話の利用を確実に防止することができる。

また、上記実施例では、ドライバが使用する携帯電話７の情報（図１の例では携帯電話の電話番号３−２）とドライバの顔データ３−１とがドライバごとにデータベース３に登録され、この登録された情報を基に運転中電話対策として留守番モード等のドライブモードへの設定変更がなされる構成を採用している。このため、データベース３への情報の登録をしないか、あるいは、真実とは違う情報の登録がなされた場合は、ドライブモードへの設定変更がなされず、運転中にドライバが携帯電話を使用できるようになってしまう。特に、意図的に事実と異なる情報をデータベース３に登録することで、ドライブモードへの設定変更を不正に回避しようとする不正利用を有効に防止することができない。

上記のように携帯電話７の情報が登録されていないときの未登録の問題に対する対策としては、以下の対策Ａ、Ｂ、Ｃが考えられる。尚、この対策においては搭乗者（ドライバを含む。以下同様である。）の携帯電話を検出するが、その検出方法としては、ブルーツゥース等の近距離通信手段で携帯電話から電話番号または携帯電話を識別するＩＤを取得して携帯電話を特定し、その携帯電話が車輌と一緒に移動しているときには、搭乗者の携帯電話と判定すればよい。

＜対策Ａ＞
搭乗者がドライバ１人で携帯電話が１台である場合には、その携帯電話はドライバの携帯電話とみなして、その携帯電話を上述の運転中制限状態に設定する。

＜対策Ｂ＞
運転開始前にあらかじめ自動的に登録モード、すなわち、データベース３にドライバの使用する携帯電話７の電話番号３−２を登録させるモードに移行し、その登録を促す。これにより、ドライバが携帯電話を持っていてデータベース３への登録がなされた場合には、上記未登録の問題は解消する。一方、ドライバが携帯電話を持っていて登録モードに移行したにもかかわらずベータベース３への登録がなされない場合には、当該ドライバの携帯電話を上述の運転中制限状態に設定し、その携帯電話の使用を禁止する。ドライバ以外の搭乗者が携帯電話を持っている場合には、以下のような構成を採用するとよい。

携帯電話を持っている搭乗者が家族などであり、その者が携帯電話の情報登録をした場合には、上記未登録の問題は解消し、その者は運転席に座っていないので、携帯電話を普通に利用することができるものとする。助手席で携帯電話の情報登録をした搭乗者が、次に運転席に座った場合には、自動的にハンズフリーモードまたは留守番モード等のドライブモードに移行するものとする。携帯電話の情報登録をしなかった場合は、その登録を促す。登録された場合は、ハンズフリーモードまたは留守番モードなどのドライブモードに移行する。登録しない場合は、その未登録の携帯電話を運転中制御状態とし、携帯電話のキーボードの操作ができなくなり、表示画面に見るべき情報が表示されない状態等、その表示画面が無効状態となって、携帯電話が使用不可になるものとする。

＜対策Ｃ＞
ゲストとして一時的に携帯電話の情報登録ができるように構成する。この場合も、携帯電話の情報登録をしないと、上記のように携帯電話が使用不可になるものとする。ゲストとしての携帯電話の登録については有効期間などを設けて自動的に消去されるように構成してもよい。

上記実施例では、携帯電話がハンズフリー機能をもっていても、また携帯型ハンズフリー装置があっても、それらを有効に使用することができない。この問題を解決する方法としては、（Ａ）操作をしなければよいので、近距離通信手段を介して操作を検出し、操作がない通話については許可する、あるいは、（Ｂ）携帯電話とペアリングされている携帯型ハンズフリー装置がある場合には、近距離無線のリンクを行わないようにすればよい。

図８は、ブルーツゥースとして機能する近距離通信部６−５で携帯電話をハンズフリーとする際の携帯電話の動作を示したフローチャートである。このフローチャートの例においては、最初にブルーツゥースでブルーツゥース対応のハンズフリー装置を探索する（ステップ８０１）。ここで、ハンズフリー装置を発見できなかったときには（ステップ８０１のＮＯ）、ステップ８００に戻る。一方、ハンズフリー装置を発見できたときには（ステップ８０２のＹＥＳ）、ブルーツゥースでハンズフリー装置との接続を試みる（ステップ８０３）。その接続の許可がとれないときには（ステップ８０４のＮＯ）、ステップ８００に戻り、接続の許可がとれたならば（ステップ８０４のＹＥＳ）、携帯電話の現在のモードを確認する（ステップ８０５）。ここで、当該モードが留守番モードでなく（ステップ８０６のＮＯ）、ハンズフリーモードであるときには（ステップ８０７のＹＥＳ）、携帯電話の通話方式をハンズフリーモードに切り替える（ステップ８０８）。この一方、当該モードが留守番モードであるならば（ステップ８０６のＹＥＳ）、携帯電話の通話方式を留守番モードに切り替える（ステップ８０９）。

以上のようにして携帯電話の通話方式をハンズフリーモードまたは留守番モードに切り替えた後は、ブルーツゥースの接続解除を確認する（ステップ８１０）。ここで、ブルーツゥースの接続解除を確認できたときは（ステップ８１１のＹＥＳ）、携帯電話の通話方式を普通に通話可能な通常モードに戻す（ステップ８１２）。一方、その接続解除を確認できないときは（ステップ８１１のＮＯ）、ステップ８１０に戻り、その接続解除待ちの状態になる。

尚、上記ステップ８０５におけるモードの確認の際に、そのモードが留守番モードでなく（ステップ８０６のＮＯ）、ハンズフリーモードでもない（ステップ８０７のＮＯ）ときは、ブルーツゥースの接続を解除し（ステップ８１３）、ブルーツゥースで他のハンズフリー装置を探索して（ステップ８１４）、ステップ８００に戻る。

図１１と図１２は、複数の携帯電話が車輌内に存在し、それをブルーツゥースで検出してモードを切り替える場合の処理内容を示したフローチャートであり、このうち、図１１のフローチャートは、車輌コントローラユニット５における顔認証と登録確認の処理動作を示したものであり、また、図１２のフローチャートは、近距離通信手段（ブルーツゥース）として機能する近距離通信部６−５の制御動作を示したものである。

尚、図１１の顔認証と登録確認の各処理動作と図１２の近距離通信部６−５の制御動作とは、並列に実行される。また、以下の説明で、「顔認識起動条件」とは、エンジンが起動され、シートベルトが締められた等、顔面認証を開始するための条件を意味する。

図１１のフローチャートの例では、最初に顔認識起動条件を確認する（ステップ１１−１）。顔認識起動条件を満たしている場合には（ステップ１１−２のＹＥＳ）、ドライバの顔認識を行い（ステップ１１−３）、その認識したドライバの顔データが車輌内のデータベース３に登録されているドライバの顔データと一致するか否かを判断する（ステップ１１−４）。ここで、その両顔データが一致した場合には（ステップ１１−４のＹＥＳ）、その顔データに対応する携帯電話の電話番号を上記データベース３から抽出して番号変数にセットする（ステップ１１−５）。一方、その両顔データが一致しなかった場合には（ステップ１１−４のＮＯ）、遠距離通信部６−６を用いて顔データの登録があるかどうかについて外部に確認をする（ステップ１１−６）。そして、遠距離通信部６−６を用いて図示しない外部のデータベースを検索し、その外部のデータベースに登録されている顔データと上記認識したドライバの顔データとが一致するか否かを判断する（ステップ１１−７）。ここで、その両顔データが一致した場合には（ステップ１１−７のＹＥＳ）、その顔データに対応する携帯電話の電話番号を当該外部のデータベースから抽出する等して番号変数にセットする（ステップ１１−５）。一方、その両顔データが一致しなかった場合には（ステップ１１−７のＮＯ）、番号変数をリセットする（ステップ１１−８）。

以上のようにして番号変数に携帯電話の電話番号がセットされるか、または番号変数がリセットされた後は、再度、顔認識起動条件を確認し（ステップ１１−９）、顔認識起動条件を満たしていれば（ステップ１１−１０のＹＥＳ）、ステップ１１−３に戻り、顔認識のループを繰り返す。これは、番号変数に携帯電話の電話番号が設定された後でも、ドライバが変わる可能性があるので、顔認識起動条件を満たす限り、顔認識のループを繰り返すようにしたものである。顔認識のループの繰り返し中に、顔認識起動条件を満たさなくなった場合には（ステップ１１−１０のＮＯ）、車輌のイグニッションスイッチ（電源）がオフか否かを調べ（ステップ１１−１１）、オフならば（ステップ１１−１１のＹＥＳ）、この処理を終了するが、オフでないときは（ステップ１１−１１のＮＯ）、オフ待ちとなり、オフになった時点でこの処理を終了する。

顔認識起動条件を満たしていない場合には（ステップ１１−２のＮＯ）、再度、顔面認識起動条件を確認するためにステップ１１−１に戻る。

図１２のフローチャートの例では、最初にブルーツゥースで接続できる携帯電話を探索する（ステップ１２−１）。ここで、接続できる携帯電話がないときは（ステップ１２−２のＮＯ）、ステップ１２−１に戻る。一方、接続できる携帯電話があるときは（ステップ１２−２のＹＥＳ）、その携帯電話の電話番号と上記番号変数にセットされた電話番号とを比較し（ステップ１２−３）、ドライバが情報登録した携帯電話であるか否かを判断する（ステップ１２−４）。ここで、上記比較の結果、上記両電話番号が一致しているときは、ドライバによる情報登録済みの携帯電話であるものとみなし（ステップ１２−４のＹＥＳ）、ハンズフリーモードとなるようにその携帯電話に指令を与える（ステップ１２−５）。この一方、上記比較の結果、上記両電話番号が一致していないときは、ドライバによる情報登録済みの携帯電話ではないものとみなし（ステップ１２−４のＮＯ）、この携帯電話の情報登録をするかどうかについてその携帯電話利用者に確認を求める（ステップ１２−６）。この登録確認の求めに応じて携帯電話の情報登録が行われる場合には（ステップ１２−７のＹＥＳ）、さらに、その携帯電話利用者に対して一時的な情報登録かどうかの問い合わせをする（ステップ１２−８）。その問い合わせにより、一時的な情報登録をするとの確認がとれたときには（ステップ１２−９のＹＥＳ）、前記ステップ１２−５に移行して、ハンズフリーモードとなるようにその携帯電話に指令を与える。この一方、一時的な情報登録でなく恒久的な情報登録をするとの確認がとれたときには（ステップ１２−９のＮＯ）、その携帯電話の情報（図１の例では携帯電話の電話番号）をデータベース３に登録し（ステップ１２−１０）、前記ステップ１２−５に移行して、ハンズフリーモードとなるようにその携帯電話に指令を与える。尚、上記ステップ１２−６において、携帯電話の登録確認を求めたが、その求めに応じないとき、すなわち、携帯電話利用者がその携帯電話の情報登録を拒否した場合には（ステップ１２−７のＮＯ）、留守番モードとなるようにその携帯電話に指令を与え（ステップ１２−１１）、ブルーツゥースで接続できる他の携帯電話を探索し（ステップ１２−１２）、最初のステップ１２−１に戻る。

上記ステップ１２−５における指令で携帯電話がハンズフリーモードに設定変更された後は、ブルーツゥースが切断されたか否かを判断し（ステップ１２−１３）、ブルーツゥースが切断されているときは（ステップ１２−１３のＹＥＳ）、ステップ１２−１に戻り、以上説明した近距離通信手段（ブルーツゥース）として機能する近距離通信部６−５の制御動作を繰り返す。一方、ブルーツゥースがまだ切断されていないときには（ステップ１２−１３のＮＯ）、車輌のイグニッションスイッチがオフかどうかを調べ（ステップ１２−１４）、オフであるならば（ステップ１２−１４のＹＥＳ）、この処理を終了するが、オフでないときには（ステップ１２−１４のＮＯ）、オフ待ちとなり、オフになった時点でこの処理を終了する。ところで、車輌のイグニッションスイッチがオフになると、これに連動して近距離通信部６−５の電源もオフになるので、携帯電話側でブルーツゥースの切断（接続解除）を検出し、その切断を確認した後に、携帯電話は普通に通話できる通常モードに復帰する。

上記のような携帯電話の一時的な登録、すなわち一時利用であっても、所定の時間、その携帯電話の登録データを保持しておく構成を採用してもよい。例えば、高速道路の走行中にサービスエリアで一旦止まった後、また走り始めた時に、再度一時的に登録をするかどうかを問われることを防止できるからである。

ブルーツゥースのみでは通信相手の携帯電話が車輌内に存在するか車外に存在するかの判断ができないので、走行時にもブルーツゥースで接続が可能であれば、車輌内に携帯電話が存在すると判断するように構成してもよい。このように構成すると、車外の近隣に存在する携帯電話とブルーツゥースで接続した場合に、この接続は走行の開始により切断されるので、走行の開始で接続の切断があったことをもって、その携帯電話は車外にあったものと推定できるからである。

また、車輌内に存在する携帯電話であっても、電波状態によってブルーツゥースでの接続が偶然切断される場合も考えられるが、そのように切断されたとしても、前述した図８や図１４のフローチャートの例では、再度、携帯電話の探索が行われる構成が採用されているので、切断による問題は生じない。

図１２のフローチャートで示した処理構成は、携帯電話の情報登録なしで不正に利用しようとする者を考慮した構成であるので、情報登録をした携帯電話はハンズフリーモードでのみ使えるような仕様としている。この仕様において、携帯電話の情報登録をするときに留守番モードで使うかどうかを確認して、留守電モードで使うように設定できる処理構成としてもよい。

図７のＰＡＤで示した処理構成では運転席に座っている人以外は通常に携帯電話が使えたが、これと比較をすると、図１２のフローチャートで示した処理構成はやや不便な構成となっている。そこで、その利便性の向上を図るためには、図１２のフローチャートで示した処理構成の一部を以下のように変更構成するとよい。

＜変更構成例＞
図１２で示すフローチャートの処理構成のうち、ステップ１２−４の判断、すなわち「ドライバが情報登録した携帯電話であるか否か」という判定を、「ドライバあるいはドライバ以外の者が情報登録した携帯電話であるか否か」という判定に変更する。そして、ステップ１２−１０において、データベース３への登録が行われたか、あるいは上記変更後のステップ１２−４でＹＥＳと判定された後に、ドライバの携帯電話かどうかを判定するというステップを挿入して、ドライバの携帯電話であれば、ステップ１２−５のステップに進み、ハンズフリーモードになるように携帯電話に指令し、一方、ドライバの携帯でなければ最初のステップである１２−１に戻るようにする。

以上のような変更後の処理構成によると、ドライバではない者が登録した携帯電話は普通に利用できるようになる。

上記変更構成例以外に利便性の向上を図る手段として、以下の構成を採用することもできる。
＜構成例１＞
運転席以外の助手席や後部座席に座っている人の顔を検出してドライバではないと判定し、通常の通話モードでそのまま通話できるように構成する。
＜構成例２＞
子供や免許を持っていないなどの理由で運転しない者については、データベースにその者は運転しない旨の情報を登録しておいて、その者の携帯電話は普通に使えるように構成する。
＜構成例３＞
データベースに使いたいモードを登録しておいて、個人の好みに応じて自動的にその登録したモードに携帯電話が設定されるように構成する。

これまでに示した対策を行っても、図７のＰＡＤで示した処理構成例や上記変更構成例においては、例えば、ドライバが子供の携帯電話を借りて操作するような不正は起こりうる。

そのような不正を防止するためには、運転者の生体個人識別情報を使って携帯電話を直接操作して使っている人物を特定して、その人物が運転席に着座して顔が検出された場合には走行中制限状態にするような構成とすることで対応できる。携帯電話を直接操作している人が誰であるかは、例えば以下のようにすれば検出できる。

携帯電話のカメラで撮影した利用者の顔画像を使って携帯電話の操作を行っている人を特定する。顔の認証は携帯電話において行っても、車載機で行ってもよいし、それ以外の装置やネットワークで接続された装置で行ってもよい。

運転している顔の人と同じ人の指紋認証がハンズフリーモード以外の操作可能なモードで検出されたら、その携帯電話を走行中制限状態にするような構成を採用することによっても、上記のような不正を防止することができる。

また、上記のような不正を防止する構成として、運転席で顔が検出された人のＩＤがネットワーク上で利用されたら、そのときに使っている通信装置を特定し、この特定した通信装置が車輌内の携帯電話であった場合には、その携帯電話を走行中制限状態にするような構成を採用してもよい。

さらに、運転席で携帯電話を使っている画像が検出されたら、ブルーツゥースで接続しその携帯電話を特定して運転中制限状態とするようにしてもよい。そうすることで、上記のような不正が防止できる。

本発明の一実施形態である運転中電話対策装置の全体構成図。 図１の装置で用いた画像処理ユニットのハードウエア構成図。 図１の装置で用いた画像処理ユニットの機能ブロック図。 図１の装置で用いた車輌コントローラユニットのハードウエア構成図。 図１の装置で用いた車輌コントローラユニットの機能ブロック図。 携帯電話の機能ブロック図。 図７（ａ）は、図１の装置で実行される電話モード設定処理の流れを示したＰＡＤ（Problem Analysis Diagram；問題分析図）、図７（ｂ）は、同装置で実行されるモード解除処理の流れを示したＰＡＤである。 ブルーツゥースで携帯電話をハンズフリーとする際の携帯電話の動作を示したフローチャートの図。 留守番モードへの切り替え処理を示したフローチャート（Flow chart；流れ図）。 ブルーツゥースでハンズフリーモードに切り替える際の切り替え処理を示したフローチャート。 複数の携帯電話が車輌内に存在し、それをブルーツゥースで検出してモードを切り替える場合の処理内容として、車輌コントローラユニットにおける顔認証と登録確認の処理動作を示したフローチャート。 複数の携帯電話が車輌内に存在し、それをブルーツゥースで検出してモードを切り替える場合の処理内容として、ブルーツゥースとして機能する近距離通信部の制御動作を示したフローチャート。 図１に示した通信装置の構成図。 図１に示したデータベース中のドライバの顔データと携帯電話番号を分割して設ける場合の説明図。

符号の説明

１ カメラ
２ 照明
３ データベース
３−１ 顔データ
３−２ 電話番号
４ 画像処理ユニット
４−１ ＣＰＵ
４−２ ＲＡＭ
４−３ ＲＯＭ
４−４ カメラ制御部
４−５ 照明制御部
４Ａ 画像読み取り部
４Ｂ ドライバ判定部
５ 車輌コントローラユニット
５Ａ 車輌情報取得部
５Ｂ 処理開始判断部
５Ｃ モード切り替え部
５Ｄ 処理終了判断部
６ 通信装置
７ 携帯電話
７−１ 操作部
７−２ アンテナ
７−３ 受信回路
７−４ 通信モード切替機
７−５ 音声入出力部
７−６ 制御回路
７−７ 表示装置
７−８ 近距離通信用アンテナ
７−９ 近距離通信回路
８ センサ類
９ コントローラ類
１０ 電話局

Claims (14)

1. ドライバの顔データと該ドライバが使用する携帯通信機器の識別情報をドライバごとに登録したデータベースと、
   顔面認証により上記データベースの中から現在の車輌のドライバを特定するドライバ特定手段と、
   上記ドライバ特定手段により特定したドライバが使用する携帯通信機器の識別情報を上記データベースから抽出し、その識別情報を用いて当該ドライバの携帯通信機器をドライブモードに切り替えるモード切り替え手段とを具備すること
   を特徴とする運転中電話対策装置。
2. 留守番モード、ハンズフリーモードのうちの少なくとも一つのモードをドライブモードとして備え、上記モード切り替え手段は、ドライバの携帯通信機器をドライブモード以前の状態からドライブモードに切り替えることを特徴とする請求項１に記載の運転中電話対策装置。
3. ドライバの顔データと該ドライバが使用する携帯通信機器の識別情報をドライバごとに登録したデータベースと、
   顔面認証により上記データベースの中から現在の車輌のドライバを特定するドライバ特定手段とを有し、
   上記ドライバ特定手段により特定したドライバが使用する携帯通信機器の識別情報を上記データベースから抽出し、その識別情報を用いて当該ドライバの携帯通信機器をドライブモードに切り替えた後において、上記ドライバ特定手段によりドライバを一定時間を越えて特定できなくなった際に、上記携帯通信機器のドライブモードを解除すること
   を特徴とする運転中電話対策装置。
4. ドライバの顔データと該ドライバが使用する携帯通信機器の識別情報をドライバごとに登録したデータベースと、
   顔面認証により上記データベースの中から現在の車輌のドライバを特定するドライバ特定手段とを用い、
   上記ドライバ特定手段により特定したドライバが使用する携帯通信機器の識別情報を上記データベースから抽出し、その識別情報を用いて当該ドライバの携帯通信機器をドライブモードに切り替えること
   を特徴とする運転中電話対策方法。
5. ドライバの顔データと該ドライバが使用する携帯通信機器の識別情報をドライバごとに登録したデータベースと、
   顔面認証により上記データベースの中から現在の車輌のドライバを特定するドライバ特定手段とを用い、
   上記ドライバ特定手段により特定したドライバが使用する携帯通信機器の識別情報を上記データベースから抽出し、その識別情報を用いて当該ドライバの携帯通信機器をドライブモードに切り替えた後において、上記ドライバ特定手段によりドライバを特定できなくなった際に、上記携帯通信機器のドライブモードを解除すること
   を特徴とする運転中電話対策方法。
6. 上記ドライバの携帯通信機器がドライブモードに切り替えられた際に、その携帯通信機器を運転中制御状態とすること
   を特徴とする請求項１、２又は３のいずれかに記載の運転中電話対策装置。
7. 上記ドライバの携帯通信機器がドライブモードに切り替えられた際に、その携帯通信機器を運転中制御状態とすること
   を特徴とする請求項４又は５のいずれかに記載の運転中電話対策方法。
8. 顔面認証のために認識したドライバの顔データが、本装置のデータベース内に存在しなかった場合、遠距離通信装置を用いて、外部のデータベースから認識したドライバに対応する携帯電話を特定する情報を調べ、上記携帯電話を特定することができた場合は、その携帯電話をドライブモードにすること
   を特徴とする運転中電話対策装置。
9. 顔面認証のために認識したドライバの顔データが、本装置のデータベース内に存在しなかった場合、遠距離通信装置を用いて、外部のデータベースから認識したドライバに対応する携帯電話を特定する情報を調べ、上記携帯電話を特定することができない場合は、対応する携帯電話の情報登録を求めること
   を特徴とする運転中電話対策装置。
10. 顔面認証のために認識したドライバの顔データが、本装置のデータベース内に存在しなかった場合、遠距離通信装置を用いて、外部のデータベースから認識したドライバに対応する携帯電話を特定する情報を調べ、上記携帯電話を特定することができず、該携帯電話の情報登録がなされない場合は、上記携帯電話を運転中制御状態とすること
    を特徴とする運転中電話対策装置。
11. 顔画像によってドライバを特定した場合に、そのドライバが携帯通信装置を使用することを防ぐシステム。
12. 顔画像によってドライバを特定した場合に、そのドライバが携帯通信装置を使用することを防ぐシステムに適用される車戴装置であって、顔画像によって特定されたドライバの携帯通信装置を利用制限状態にする車戴装置。
13. 顔画像によってドライバを特定した場合に、そのドライバが携帯通信装置を使用することを防ぐシステムに適用される携帯通信装置であって、顔画像によって特定されたドライバが特定されて、そのドライバが使用しないように指令を受けて利用制限状態になる携帯通信装置。
14. 顔画像によってドライバを特定した場合に、そのドライバが携帯通信装置を使用することを防ぐシステムに適用される携帯通信装置であって、顔画像によってドライバを特定するために、顔情報を提供する外部装置。

Images