JP2017123029A - 情報通知装置、情報通知方法及び情報通知プログラム - Google Patents

Abstract

【課題】ディストラクションの発生を抑制すること。【解決手段】情報通知装置１０は、通知制御部１８でユーザ通知を受け付ける処理と、カメラ１１により撮像される画像を用いて視線検出部１５で視線検出を実行する処理と、視線検出の結果として得られる視線方向から所定の領域を注視する注視度を注視度算出部１６で算出する処理とを行う。注視度が第１の閾値以上である場合には、注視度が第１の閾値未満である場合に実行される第１の通知形態よりも質または量が下げられた第２の通知形態で、ユーザ通知を実行する処理を行う。【選択図】図１

Description

本発明は、情報通知装置、情報通知方法及び情報通知プログラムに関する。

ＩＣＴ（Information and Communication Technology）利用の進化、あるいは自動車のスマート化と共に、各種の車載装置の高機能化および多機能化が進展している。このような状況の下、スマートフォンやそれに接続された車載装置等でＳＮＳ（Social Networking Service）等を介して受信されるメッセージが車内に表示される場合がある。

ところが、ドライバの運転負荷、いわゆるワークロードが高い状況でメッセージが表示されると、ドライバがその表示に気をとられて運転への注意が散漫する結果、いわゆるディストラクションが発生し、運転に悪影響を与える場合もある。

かかるディストラクションへの対策の一例として、下記の情報表示システムが提案されている。この情報表示システムでは、車内ＬＡＮ（Local Area Network）を介して車両制御系ＥＣＵ（Engine Control Unit）群やナビゲーションＥＣＵ等から取得される情報を用いて、運転負荷の大小を判定する負荷判定処理を実行する。例えば、後退中、コーナリング中、右左折中、車線変更中、あるいは加減速中である場合に運転負荷が大きいと判定したり、狭い道、スクールゾーン、カーブ、交差点／合流点、踏切、車間短い、混雑、視界不良である場合に運転負荷が大きいと判定したりする。

また、ドライバの負荷状態を測定する技術の一例として、発呼タイミング制御装置も提案されている。この発呼タイミング制御装置は、ドライバへの電話等の発呼タイミングを制御するものであるが、発呼タイミングの制御に下記２つのワークロードの測定方法が用いられる。

例えば、１つ目のワークロードの測定方法では、視線センサおよび車両センサにて取得したデータからワークロードを求めるための定量化モデルを生成しておき、定量化モデルに視線センサおよび車両センサにて取得したデータを適用してワークロードを計算する。この定量化モデルは、様々な状況（例えば、交差点、追い越し、オーディオ操作等）において視線センサや車両センサで得られる検知データと当該状況におけるワークロードの値の関係を、例えば、線形重回帰分析、主成分分析、因子分析などの統計的手法を用いて求めることにより作成される。さらに、様々な状況におけるワークロードの値は、例えば、事前に、ドライバに対して当該状況において感じるワークロードの値を評価してもらい、その評価値に基づいて決定される。また、ワークロードの値は、ドライバの主観的な評価に基づくのではなく、様々な状況においてドライバの生体信号（例えば、心拍数、血圧、呼吸の速さ等）を取得し、生体信号からワークロードの値が決定される。

また、２つ目のワークロードの測定方法では、視線センサ、車両センサ、道路属性解析部にて取得したデータをワークロードのデータに換算するためのワークロード換算テーブルを参照して、各センサで取得したデータをワークロードのデータに換算する。このワークロード換算テーブルには、運転操作、道路属性、機器操作、聴覚コンテンツや視線動作に対応するワークロードのデータが格納される。

特開２０１４−９１４４０号公報 特開２０１０−２８２５９２号公報 特開２００４−０７０９５号公報 特開２０００−２１１５４３号公報 特開２００８−２４１３０９号公報 特開平１０−２４４８９２号公報 特開２０１０−２３７９５４号公報

しかしながら、上記の技術では、ディストラクションの発生を抑制できない場合がある。

例えば、上記の情報表示システムでは、運転負荷が高い場面であるか否かが負荷判定処理で判定されるが、運転負荷が高い場面を事前に漏れなく列挙することは困難であり、負荷判定処理で挙げられた場面以外の場面ではディストラクションの発生を抑制できない。

また、上記の発呼タイミング制御装置が用いる１つ目のワークロードの測定方法では、次のような理由で適用場面が限定される。すなわち、ドライバには、個人差があるので、個々のドライバごとにモデルを推定する必要があるが、ドライバごとに主観評価値や生体信号データを収集することは非効率であり、汎用性に欠けるので、適用可能な場面が限定される。

また、上記の発呼タイミング制御装置が用いる２つ目のワークロードの測定方法では、各センサで取得されるデータをワークロードへ換算するのにワークロード換算テーブルが用いられる。このワークロード換算テーブルには、視線動作のデータをワークロードのデータに変換するものも含まれるが、当該ワークロード換算テーブルでは、一側面として、「まっすぐ前を見る」という視線動作には他の視線動作よりも低いワークロードが設定されている。ところが、ドライバが前方を見ているからといって必ずしもワークロードが低いとは限らない。なぜなら、ドライバが前方を見ている場合でも、先行車両がブレーキをかけるケースなどのように、前方を注視した方がよい場面、すなわちワークロードが高い場面が存在するからである。加えて、上述の通り、運転負荷が高い場面を事前に漏れなく列挙することは困難であり、ワークロード換算テーブルで挙げられた場面以外の場面ではディストラクションの発生を抑制できない。

１つの側面では、本発明は、ディストラクションの発生を抑制できる情報通知装置、情報通知方法及び情報通知プログラムを提供することを目的とする。

一態様では、情報通知装置は、ユーザ通知を受け付ける受付部と、カメラにより撮像される画像に視線検出を実行する視線検出部と、前記視線検出の結果として得られる視線方向から所定の領域を注視する注視度を算出する注視度算出部と、前記注視度が第１の閾値以上である場合に、前記注視度が第１の閾値未満である場合に実行される第１の通知形態よりも質または量が下げられた第２の通知形態で前記ユーザ通知を実行する通知制御部とを有する。

ディストラクションの発生を抑制できる。

図１は、実施例１に係る情報通知装置の機能的構成を示すブロック図である。 図２は、実施例１に係る前方注視度の算出処理の手順を示すフローチャートである。 図３は、実施例１に係る通知制御処理の手順を示すフローチャートである。 図４は、実施例２に係る情報通知装置及び分析サーバを含むデータ分析システムの構成例を示す図である。 図５は、実施例２に係るデータ分析処理の手順を示すフローチャートである。 図６は、実施例３に係る情報通知装置及び分析サーバを含むデータ分析システムの構成例を示す図である。 図７は、前方注視度のヒストグラムの一例を示す図である。 図８は、実施例１〜実施例３に係る情報通知プログラムを実行するコンピュータのハードウェア構成例を示す図である。

以下に添付図面を参照して本願に係る情報通知装置、情報通知方法及び情報通知プログラムについて説明する。なお、この実施例は開示の技術を限定するものではない。そして、各実施例は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。

図１は、実施例１に係る情報通知装置の機能的構成を示すブロック図である。図１に示す情報通知装置１０は、車載装置の一種であり、ＳＮＳ（Social Networking Service）サーバ３０等の通信サービスを介して携帯端末装置２０が受信する着信メッセージを通知する情報通知サービスを提供するものである。かかる情報通知サービスの一環として、情報通知装置１０は、着信メッセージの通知によりディストラクションが発生するのを抑制する通知制御を実現する。

図１に示すように、情報通知装置１０は、携帯端末装置２０と接続される。これら情報通知装置１０及び携帯端末装置２０は、有線または無線の任意の形態で接続することができる。例えば、情報通知装置１０及び携帯端末装置２０を有線で接続する場合、ＵＳＢ（Universal Serial Bus）やＨＤＭＩ（登録商標）（High-Definition Multimedia Interface）を介して接続される。また、情報通知装置１０及び携帯端末装置２０を無線で接続する場合、ＢＬＥ（Bluetooth（登録商標） Low Energy）などの近距離無線通信の他、Ｗｉ−Ｆｉ（登録商標）などの無線ＬＡＮ（Local Area Network）を介して接続される。

さらに、携帯端末装置２０は、ネットワーク５を介してＳＮＳサーバ３０と接続される。かかるネットワーク５には、有線または無線を問わず、インターネット（Internet）、ＬＡＮやＶＰＮ（Virtual Private Network）などの任意の種類の通信網を採用できる。

ＳＮＳサーバ３０は、ソーシャルネットワーキングサービスを提供するサービス提供者によって運営されるサーバ装置である。

一実施形態として、ＳＮＳサーバ３０は、ソーシャルネットワーキングサービスの提供を受けるクライアント側のコミュニケーションアプリケーションがインストールされた携帯端末装置２０に対し、各種のサービスを提供する。以下では、コミュニケーションアプリケーションのことを「コミュニケーションアプリ」と略記する場合がある。例えば、ＳＮＳサーバ３０は、チャット形式のメッセージ交換サービスを始め、自分のプロフィールやアバターなどを公開するマイページ機能、ＳＮＳ上で交流のある友人や知人を登録するアドレス帳の機能、マイページを訪問したユーザの履歴を参照できる訪問履歴の参照機能、ブログのように簡単にエントリを更新できる日記帳の機能などを提供できる。

携帯端末装置２０は、可搬型の情報処理装置である。

一実施形態として、携帯端末装置２０には、スマートフォン、携帯電話機やＰＨＳ（Personal Handyphone System）などの移動体通信端末のみならず、タブレット端末やスレート端末などを採用できる。例えば、携帯端末装置２０には、各種のＳＮＳのサービス事業者により提供されるクライアント用のコミュニケーションアプリがインストールされる。このようにコミュニケーションアプリが動作する環境が携帯端末装置２０に用意された環境の下、携帯端末装置２０は、一例として、ＳＮＳサーバ３０が提供するメッセージ交換サービスを通じて、ＳＮＳを利用する他のユーザなどとの間でメッセージを送受信できる。

ここで、情報通知装置１０は、上記の携帯端末装置２０が接続されることにより、携帯端末装置２０が提供する機能の一部または全部を利用することができる。例えば、情報通知装置１０は、携帯端末装置２０から情報通知装置１０へ出力される画像データや音声データを情報通知装置１０の表示部１３やスピーカ１２に表示出力または音声出力させることができる。この一環として、情報通知装置１０は、ＳＮＳのユーザ間で上記のメッセージ交換サービスを通じて授受されるメッセージ、すなわち携帯端末装置２０がＳＮＳサーバ３０を介して送受信する発信情報や着信情報などを通知することができる。

なお、以下では、あくまで一例として、ＳＮＳの着信メッセージの通知によりディストラクションが発生するのを抑制する通知制御について例示するが、上記の通知制御の適用範囲がこれに限定される訳ではない。すなわち、情報通知装置１０が搭載される車両のドライバを始めとする乗員に対する通知であればよく、その通知の全般に上記の通知制御を適用できる。例えば、ＳＮＳの着信メッセージでなく、キャリア通信による着信メッセージを通知する場合にも、上記の通知制御を適用できる。また、上記の通知制御の適用範囲は、携帯端末装置２０から供給される通知にも限定されない。例えば、図示しない他の車載装置、例えばナビゲーション装置やＥＣＵ（Engine Control Unit）などから出力される通知にも、上記の通知制御を適用できる。この場合、必ずしも情報通知装置１０が携帯端末装置２０に接続されずともかまわない。

［情報通知装置１０の構成］
図１に示すように、情報通知装置１０は、カメラ１１と、スピーカ１２と、表示部１３と、受付部１４と、視線検出部１５と、注視度算出部１６と、視認判定部１７と、通知制御部１８とを有する。なお、図１には、データの入出力の関係を表す実線が示されているが、これは、説明の便宜上、最小限の部分について示されているに過ぎない。すなわち、各処理部に関するデータの入出力は、図示の例に限定されず、図示以外のデータの入出力、例えば処理部及び処理部の間、並びに、処理部及び外部装置の間のデータの入出力が行われることとしてもかまわない。

カメラ１１は、ＣＣＤ（Charge Coupled Device）やＣＭＯＳ（Complementary Metal Oxide Semiconductor）などの撮像素子を搭載する撮像デバイスである。

一実施形態として、カメラ１１は、視線検出用の画像を撮像するのに用いられる。例えば、カメラ１１は、視線検出の目標とする乗員、例えばドライバの顔の目の部分、すなわち角膜反射および瞳孔を所定の画素以上で撮像できる位置に設置される。このような設置状況の下、カメラ１１は、カメラ１１の近傍に配置された光源を制御することによって被写体に赤外線を照射させ、被写体からの反射光を受光した上でデジタル信号に変換された被写体の画像を後述の視線検出部１５へ出力する。このとき、被写体に利用者の眼球が含まれる場合には、眼球からの光の反射がカメラ１１によって捉えられ、眼球の瞳孔部分と、角膜反射が他の部分よりも明るく写った画像を得ることができる。

スピーカ１２は、音声出力装置の一種である。

一実施形態として、スピーカ１２は、１つまたは複数のスピーカを含むスピーカユニットとして実装することができる。このスピーカ１２は、携帯端末装置２０や他の車載装置から出力される音声データ、例えば着信音等を含む効果音、楽曲、案内音声などを音声出力することができる。なお、ここでは、音声出力装置の一例としてスピーカを例示したが、チャイムやベル等の他の音声出力装置で代用することもできる。

表示部１３は、各種の情報を表示する表示デバイスである。

一実施形態として、表示部１３には、投影により表示を実現するプロジェクタの他、発光により表示を実現する液晶ディスプレイや有機ＥＬ（electroluminescence）ディスプレイなどを採用することができる。ここでは、一例として、ドライバの前方の視野、例えば情報通知装置１０が搭載される車両のフロントガラス等の任意のスクリーンに画像を投影することにより表示を実現するＨＵＤ（Head-Up Display）が表示部１３として実装される場合を想定する。

受付部１４は、各種の通知を受け付ける処理部である。

一実施形態として、受付部１４は、携帯端末装置２０がＳＮＳサーバ３０からメッセージを受信した場合、携帯端末装置２０から携帯端末装置２０で受信された着信メッセージの通知を受け付けることができる。ここでは、あくまで一例として、ＳＮＳの着信メッセージの通知を受け付ける場合を例示したが、これに限定されず、携帯端末装置２０からキャリア通信による着信メッセージの通知を受け付けることとしてもよい。この他、受付部１４は、図示しない他の車載装置、例えばナビゲーション装置やＥＣＵなどから各種の通知を受け付けることもできる。

視線検出部１５は、視線検出を実行する処理部である。

一実施形態として、視線検出部１５は、カメラ１１から画像が取得される度に、当該画像に角膜反射法などのアルゴリズムを適用し、楕円状の眼球の瞳孔の中心位置及び角膜の曲率中心を結ぶ視線方向を検出する。ここでは、あくまで一例として、角膜反射法を用いて視線検出を実現する場合を例示したが、これ以外の方法を用いて視線検出を実現することもできる。例えば、視線検出部１５は、フロントガラスを分割し、分割した領域を見る眼の形状を学習しておき、カメラ１１から入力される被写体の画像から検出される眼の形状とテンプレートマッチングを実行することによって視線方向を検出することもできる。また、視線検出部１５は、ドライバが装着するヘッドセットによって検出された視線方向を取得することとしてもかまわない。

注視度算出部１６は、所定の領域への注視度を算出する処理部である。ここでは、一例として、ドライバの前方の注視度を算出する場合を想定する。ここで言う「前方」とは、情報通知装置１０が搭載される車両が走行する車線の進行方向を指す。

一実施形態として、注視度算出部１６は、視線検出部１５により視線検出が実行される度に、視線検出部１５により検出された視線方向がドライバの視野の前方に規定される前方領域内に含まれるか否かを判定する。例えば、視線検出の結果として眼球の瞳孔の中心位置及び角膜の曲率中心を結ぶ視線ベクトルが得られるとしたとき、注視度算出部１６は、視線ベクトルと所定の前方直進ベクトルとがなす角度が所定の範囲内であるか否かを判定する。ここで言う「前方直進ベクトル」とは、情報通知装置１０が搭載される車両が前方へ直進する方向であり、かつ水平面と平行な方向を持つベクトルを指す。

ここで、視線ベクトルと前方直進ベクトルとがなす角度が所定の範囲内である場合、視線検出部１５により視線検出が実行された画像がカメラ１１により撮像された時点でドライバが前方を視認していると判断できる。この場合、注視度算出部１６は、視線検出部１５により視線検出が実行された画像を前方視認画像へ分類する。一方、視線ベクトルと前方直進ベクトルとがなす角度が所定の範囲内でない場合、視線検出部１５により視線検出が実行された画像がカメラ１１により撮像された時点でドライバが前方を視認していないと判断できる。この場合、注視度算出部１６は、視線検出部１５により視線検出が実行された画像を前方視認画像へ分類しない。

このような分類の後、注視度算出部１６は、過去の所定期間に対応するフレーム数あたりで前方視認画像に分類された画像のフレーム数の割合、すなわち「前方視認画像に分類されたフレーム数／所定期間に対応するフレーム数」を計算する。これによって、注視度算出部１６は、「前方注視度」を算出する。ここで言う「所定期間」は、一例として、１度のわき見の所要時間を基準に設定することができる。例えば、１度のわき見時間は、２秒〜４秒と言われるので、所定期間を２秒〜４秒とすることができる。また、わき見時間は、走行環境や車速によって変わる。このため、車載のＥＣＵ等から走行環境や車速などの情報を取得できる場合、走行環境や車速に応じて２秒〜４秒を伸縮させることにより、所定期間を補正することもできる。このように前方注視度が算出される度、最新の前方注視度が図示しない内部メモリのワークエリアに更新して保存される。

視認判定部１７は、表示部１３の表示が視認されたか否かを判定する処理部である。

一実施形態として、視認判定部１７は、後述の通知制御部１８により着信メッセージが表示された後、視線検出部１５により視線検出が実行される度に、当該着信メッセージが表示されてから所定時間、例えば１分間以内に着信メッセージが視認されたか否かを監視する。例えば、視認判定部１７は、視線検出部１５による視線検出の結果として眼球の瞳孔の中心位置及び角膜の曲率中心を結ぶ視線ベクトルが得られる場合、当該視線ベクトルと情報通知装置１０が搭載される車両のフロントガラスにより形成される面とが交わることを拘束条件とし、ドライバの注視点を算出する。その上で、視認判定部１７は、表示部１３がフロントガラス上に投影する着信メッセージの表示エリア内に視線ベクトルから算出されたドライバの注視点が含まれるか否かを判定する。このとき、所定時間が経過するまで着信メッセージの表示エリアにドライバの注視点が含まれなかった場合、ドライバにより着信メッセージが視認されていないと判断できる。

通知制御部１８は、表示部１３による表示出力およびスピーカ１２による音声出力のうち少なくともいずれか１つによる通知を制御する処理部である。

一実施形態として、通知制御部１８は、受付部１４により着信メッセージが受け付けられた場合、注視度算出部１６により内部メモリに保存された前方注視度を参照する。その上で、通知制御部１８は、前方注視度と、２つの閾値Ｔ１及びＴ２のうち少なくともいずれか１つの閾値とを比較することにより、当該前方注視度が「低」、「中」及び「高」の３つのレベルのうちいずれかのレベルに属するのかを判定する。

これを具体的に説明すると、通知制御部１８は、内部メモリに保存された前方注視度が閾値Ｔ１未満であるか否かを判定する。かかる閾値Ｔ１には、一例として、交差点や合流点などで左右または後方などの確認が行われた公算が高いと推定できる程度の値が設定される。このとき、通知制御部１８は、前方注視度が閾値Ｔ１未満である場合、前方注視度をレベル「低」に分類する。このように、前方注視度がレベル「低」に分類される場合、ドライバは、周囲確認に迫られた状態であることから、運転負荷、いわゆるワークロードが高い状態であると推認できる。この場合、通知制御部１８は、受付部１４により着信メッセージが受け付けられたからといって着信メッセージを直ちに表示部１３に表示させずに保留する。

一方、通知制御部１８は、前方注視度が閾値Ｔ１以上である場合、当該前方注視度が閾値Ｔ１よりも大きい閾値Ｔ２以上であるか否かをさらに判定する。かかる閾値Ｔ２には、一例として、情報通知装置１０が搭載される車両よりも前を先行して走行する先行車両の挙動が注視されている公算が高いと推定できる程度の値が設定される。このとき、前方注視度が閾値Ｔ２以上である場合には、前方注視度がレベル「高」に分類される一方で、前方注視度が閾値Ｔ２未満である場合には、前方注視度がレベル「中」に分類される。

ここで、前方注視度がレベル「中」に分類された場合、ドライバは、周囲確認に迫られておらず、また、先行車両の挙動を注視する状況にも迫られていない状態であることから、ワークロードが高い状態ではないと推認できる。この場合、通知制御部１８は、着信メッセージに関する第１の通知、例えば携帯端末装置２０で実施される通常形態の通知を実施する。例えば、通知制御部１８は、着信メッセージを表示部１３に表示出力させると共に当該着信メッセージの着信音をスピーカ１２に音声出力させる。

一方、前方注視度がレベル「高」に分類された場合、ドライバは、先行車両の挙動を注視する状況に迫られた状態であることから、ワークロードが高い状態であると推認できる。この場合、前方注視度がレベル「低」に分類された場合と同様に、着信メッセージの表示を保留することもできるが、ここでは、一例として、上記の第１の通知よりも表示出力または音声出力の質または量が抑えられた第２の通知を実施する。例えば、通知制御部１８は、第１の通知形態であれば着信音もスピーカ１２から音声出力されるが、これは実施せずに、着信メッセージを表示部１３に表示出力させる第２の通知を実行する。これによって、着信メッセージの通知を控えめに実施する。

このように、通知制御部１８は、前方注視度がレベル「中」またはレベル「高」であるのかにより、着信メッセージを通知したり、あるいは控えめに通知を行ったりといった多段階の通知制御を実現できる。それ故、上記の発呼タイミング制御装置が用いる２つ目のワークロードの測定方法のように、ドライバが前方を視認しているからといってワークロードが低いとの判断を画一的に行うことを抑制できる。この結果、一側面として、ドライバが前方を視認している場合にディストラクションが発生するのを抑制できる。加えて、通知制御部１８は、視線検出の結果から求まる前方注視度をレベル分けすることにより通知形態を切り替えるので、上記の背景技術で述べた各装置のように、ワークロードが高い場面を列挙せずとも通知制御を実現できる。それ故、通知制御部１８が実現する通知制御は、上記の背景技術で述べた各装置ほど適用場面が限定されず、汎用性を高めることもできる。

また、通知制御部１８は、第２の通知を実行した後、視認判定部１７により所定時間内に着信メッセージの表示エリアが視認されなかったと判定された場合、着信メッセージの通知形態を第２の通知から第１の通知へ切り替える。これによって、着信メッセージの確認漏れを抑制できる。

なお、上記の受付部１４、視線検出部１５、注視度算出部１６、視認判定部１７及び通知制御部１８などの処理部は、次のようにして実装できる。例えば、ＣＰＵ（Central Processing Unit）などの中央処理装置に、上記の各処理部と同様の機能を発揮するプロセスをメモリ上に展開して実行させることにより実現できる。これらの処理部は、必ずしも中央処理装置で実行されずともよく、ＭＰＵ（Micro Processing Unit）に実行させることとしてもよい。また、上記の各処理部は、ハードワイヤードロジックによっても実現できる。

また、上記の各処理部がワークエリアとして参照する主記憶装置には、一例として、各種の半導体メモリ素子、例えばＤＲＡＭ（Dynamic Random Access Memory）、ＳＲＡＭ（Static Random Access Memory）やフラッシュメモリを採用できる。また、上記の各処理部が参照する記憶装置は、必ずしも主記憶装置でなくともよく、補助記憶装置であってもかまわない。この場合、ＨＤＤ（Hard Disk Drive）、光ディスクやＳＳＤ（Solid State Drive）などを採用できる。

［処理の流れ］
次に、本実施例に係る情報通知装置１０の処理の流れについて説明する。なお、ここでは、情報通知装置１０が実行する（１）前方注視度の算出処理を説明した後に、（２）通知制御処理について説明することとする。

（１）前方注視度の算出処理
図２は、実施例１に係る前方注視度の算出処理の手順を示すフローチャートである。この処理は、一例として、カメラ１１から画像が取得される限り、繰り返し実行される。図２に示すように、カメラ１１から取得された画像を内部メモリに蓄積し（ステップＳ１０１）、視線検出部１５は、ステップＳ１０１で内部メモリに蓄積された画像から視線方向を検出する（ステップＳ１０２）。

このとき、ステップＳ１０２で検出された視線方向がドライバの視野の前方に規定される前方領域内に含まれる場合（ステップＳ１０３Ｙｅｓ）、ステップＳ１０２で視線検出が実行された画像が前方視認画像へ分類される。この場合、注視度算出部１６は、前方視認画像のフレーム数をカウントするカウンタｋの値を１つインクリメントすると共に、内部メモリに蓄積される画像のフレーム数をカウントするカウンタｍの値を１つインクリメントする（ステップＳ１０４及びステップＳ１０５）。

一方、ステップＳ１０２で検出された視線方向がドライバの視野の前方に規定される前方領域内に含まれない場合（ステップＳ１０３Ｎｏ）、ステップＳ１０２で視線検出が実行された画像は前方視認画像へ分類されない。この場合、注視度算出部１６は、前方視認画像のフレーム数をカウントするカウンタｋの値はインクリメントせずに、内部メモリに蓄積される画像のフレーム数をカウントするカウンタｍの値を１つインクリメントする（ステップＳ１０５）。

その後、注視度算出部１６は、内部メモリに蓄積された画像のフレーム数、すなわちカウンタｍの値が所定期間に対応するフレーム数Ｎであるか否かを判定する（ステップＳ１０６）。なお、内部メモリに蓄積された画像のフレーム数が所定期間に対応するフレーム数Ｎでない場合（ステップＳ１０６Ｎｏ）、図２に示す処理が起動されてから所定期間が経過していないことがわかる。この場合、ステップＳ１０１の処理に移行する。

一方、内部メモリに蓄積された画像のフレーム数が所定期間に対応するフレーム数Ｎである場合（ステップＳ１０６Ｙｅｓ）、注視度算出部１６は、次のような処理を実行する。すなわち、注視度算出部１６は、所定期間に対応するフレーム数Ｎあたりで前方視認画像に分類された画像のフレーム数ｋの割合、すなわちｋ／Ｎを計算することにより「前方注視度」を算出する（ステップＳ１０７）。

続いて、注視度算出部１６は、ステップＳ１０７で算出された前方注視度を内部メモリに上書き更新する（ステップＳ１０８）。さらに、注視度算出部１６は、内部メモリに蓄積された画像のうち撮像時刻が最も古い画像を削除し（ステップＳ１０９）、内部メモリに蓄積される画像のフレーム数をカウントするカウンタｍの値を１つデクリメントする（ステップＳ１１０）。

このとき、ステップＳ１０９で削除された画像が前方視認画像である場合（ステップＳ１１１Ｙｅｓ）、注視度算出部１６は、前方視認画像のフレーム数をカウントするカウンタｋの値を１つデクリメントし（ステップＳ１１２）、ステップＳ１０１の処理へ移行する。なお、ステップＳ１０９で削除された画像が前方視認画像でない場合（ステップＳ１１１Ｎｏ）、カウンタｋの値は更新せずに、ステップＳ１０１の処理へ移行する。

（２）通知制御処理
図３は、実施例１に係る通知制御処理の手順を示すフローチャートである。この処理は、一例として、受付部１４により着信メッセージなどの通知が受け付けられた場合に実行される。

図３に示すように、着信メッセージなどの通知が受け付けられると（ステップＳ３０１）、通知制御部１８は、注視度算出部１６により内部メモリに保存された前方注視度を参照する（ステップＳ３０２）。

続いて、通知制御部１８は、ステップＳ３０２で参照された前方注視度が閾値Ｔ１未満であるか否かを判定する（ステップＳ３０３）。このとき、前方注視度が閾値Ｔ１未満である場合（ステップＳ３０３Ｙｅｓ）、前方注視度がレベル「低」に分類される。このように、前方注視度がレベル「低」に分類される場合、ドライバは、周囲確認に迫られた状態であることから、ワークロードが高い状態であると推認できる。この場合、ステップＳ３０１で着信メッセージが受け付けられたからといって着信メッセージを直ちに表示部１３に表示させずに保留し、ステップＳ３０２の処理へ戻り、図２に示したステップＳ１０８で更新される前方注視度を改めて参照する。

一方、前方注視度が閾値Ｔ１以上である場合（ステップＳ３０３Ｎｏ）、通知制御部１８は、当該前方注視度が閾値Ｔ１よりも大きい閾値Ｔ２以上であるか否かをさらに判定する（ステップＳ３０４）。このとき、前方注視度が閾値Ｔ２以上である場合（ステップＳ３０４Ｙｅｓ）には、前方注視度がレベル「高」に分類される一方で、前方注視度が閾値Ｔ２未満である場合（ステップＳ３０４Ｎｏ）には、前方注視度がレベル「中」に分類される。

ここで、前方注視度がレベル「高」に分類された場合（ステップＳ３０４Ｙｅｓ）、ドライバは、先行車両の挙動を注視する状況に迫られた状態であることから、ワークロードが高い状態であると推認できる。この場合、通知制御部１８は、着信メッセージの着信音をスピーカ１２から音声出力させるのを控え、着信メッセージを表示部１３に表示出力させるに留める第２の通知を実行する。これによって、着信メッセージの通知を控えめに実施する（ステップＳ３０５）。

その後、所定時間内に着信メッセージの表示エリアが視認されなかった場合（ステップＳ３０６Ｎｏ）、通知制御部１８は、着信メッセージの着信音をスピーカ１２から音声出力させると共に着信メッセージを表示部１３に表示出力させることにより、着信メッセージの通知形態を第２の通知から第１の通知へ切り替える（ステップＳ３０７）。なお、所定時間内に着信メッセージの表示エリアが視認された場合（ステップＳ３０６Ｙｅｓ）、着信メッセージの通知形態を第２の通知から第１の通知へ切り替えずにそのまま処理を終了する。

一方、前方注視度がレベル「中」に分類された場合（ステップＳ３０４Ｎｏ）、ドライバは、周囲確認に迫られておらず、また、先行車両の挙動を注視する状況にも迫られていない状態であることから、ワークロードが高い状態ではないと推認できる。この場合、通知制御部１８は、着信メッセージを表示部１３に表示出力させると共に当該着信メッセージの着信音をスピーカ１２に音声出力させる第１の通知を実行し（ステップＳ３０７）、そのまま処理を終了する。

［効果の一側面］
上述してきたように、本実施例に係る情報通知装置１０は、ドライバが撮像された画像に対する視線検出で得た視線方向から求まる前方注視度が所定の閾値以上である場合に着信メッセージ等のユーザ通知を控えめに行う通知制御を実現する。したがって、本実施例に係る情報通知装置１０によれば、ディストラクションの発生を抑制できる。

さて、本実施例では、前方注視度のデータ分析サービスをさらに提供する場合について説明する。図４は、実施例２に係る情報通知装置４０及び分析サーバ５０を含むデータ分析システム２の構成例を示す図である。図４に示すように、データ分析システム２は、情報通知装置４０とネットワーク５を介して接続される分析サーバ５０を有すると共に、情報通知装置４０がアップロード部４１をさらに有する点が図１に示した例と異なる。なお、図４では、図１に示した機能部と同一の機能を発揮する機能部に同一の符号を付し、その説明を省略する。

アップロード部４１は、情報通知装置４０から分析サーバ５０へデータをアップロードする処理部である。

一実施形態として、アップロード部４１は、注視度算出部１６により算出される前方注視度を分析サーバ５０へアップロードする。このとき、アップロード部４１は、注視度算出部１６により前方注視度が算出される度に前方注視度をアップロードすることもできるし、所定の定期時刻になることを条件にそれまでに蓄積された前方注視度をアップロードすることもできる。また、アップロード部４１は、前回のアップロードが行われてから所定の周期、例えば１分間などが経過することを条件に、前回にアップロードが行われてからこれまでに蓄積された前方注視度をアップロードすることもできる。

なお、以下では、あくまで一例として、注視度算出部１６により前方注視度が算出される度にアップロードが実行される場合を想定して以下の説明を行う。

分析サーバ５０は、上記のデータ分析サービスを情報通知装置４０へ提供するサーバ装置である。

一実施形態として、分析サーバ５０は、パッケージソフトウェアやオンラインソフトウェアとして上記のデータ分析サービスを実現する分析プログラムを所望のコンピュータにインストールさせることによって実装できる。例えば、分析サーバ５０は、上記のデータ分析サービスを提供するＷｅｂサーバとして実装することとしてもよいし、アウトソーシングによって上記のデータ分析サービスを提供するクラウドとして実装することとしてもかまわない。

図５は、実施例２に係るデータ分析処理の手順を示すフローチャートである。この処理は、一例として、情報通知装置４０から前方注視度がアップロードされた場合に実行される。図５に示すように、アップロード部４１からアップロードされた前方注視度を受信すると（ステップＳ５０１）、分析サーバ５０は、ステップＳ５０１が行われた時点から遡って所定の分析期間、例えば１分間に渡って受信された前方注視度ごとに、当該前方注視度の値が「低」、「中」及び「高」の３つのレベルのうち該当するレベルの度数を累計する（ステップＳ５０２）。

続いて、分析サーバ５０は、「低」、「中」及び「高」の３つのレベルごとに、当該レベルの度数が所定の分析期間に受信された前方注視度の総数に占める割合を算出する（ステップＳ５０３）。

その後、分析サーバ５０は、レベル「中」の度数の割合がレベル「低」の度数の割合未満であるか否かを判定する（ステップＳ５０４）。ここで、レベル「中」の度数の割合がレベル「低」の度数の割合未満である場合（ステップＳ５０４Ｙｅｓ）、次のような判断が可能となる。すなわち、適正な運転がなされている場合、レベル「中」の度数の割合はレベル「低」の度数の割合よりも高くなる公算が高いので、レベル「中」の度数の割合がレベル「低」の度数の割合未満である場合、ドライバがわき見しがちな傾向にあると推認できる。

この場合、分析サーバ５０は、ＳＮＳサーバ３０を制御し、わき見に関する注意を喚起するメッセージをＳＮＳサーバ３０から情報通知装置４０へ送信させ（ステップＳ５０５）、処理を終了する。

また、レベル「中」の度数の割合がレベル「低」の度数の割合未満でない場合（ステップＳ５０４Ｎｏ）、分析サーバ５０は、レベル「中」の度数の割合がレベル「高」の度数の割合未満であるか否かを判定する（ステップＳ５０６）。

ここで、レベル「中」の度数の割合がレベル「高」の度数の割合未満である場合（ステップＳ５０６Ｙｅｓ）、次のような判断が可能となる。すなわち、適正な運転がなされている場合、レベル「中」の度数の割合はレベル「高」の度数の割合よりも高くなる公算が高いので、レベル「中」の度数の割合がレベル「高」の度数の割合未満である場合、ドライバが周囲確認を行わずに前方を注視しすぎている傾向にあると推認できる。

この場合、分析サーバ５０は、ＳＮＳサーバ３０を制御し、周囲確認を喚起するメッセージをＳＮＳサーバ３０から情報通知装置４０へ送信させ（ステップＳ５０７）、処理を終了する。

なお、レベル「中」の度数の割合がレベル「低」の度数の割合未満でなく、かつレベル「中」の度数の割合がレベル「高」の度数の割合未満でない場合（ステップＳ５０４ＮｏかつステップＳ５０６Ｎｏ）、これはレベル「中」の度数の割合が最高であることを意味する。この場合、適正な運転がなされている公算が高いので、わき見や周囲確認を喚起するメッセージは通知せず、ステップＳ５０１の処理へ戻り、以降の処理を繰り返す。

［効果の一側面］
上述してきたように、本実施例に係る分析サーバ５０は、レベル「中」の度数の割合がレベル「低」の度数の割合未満である場合にわき見注意を促す分析結果を情報通知装置４０へ提供する一方で、レベル「中」の度数の割合がレベル「高」の度数の割合未満である場合に周囲確認を促す分析結果を情報通知装置４０へ提供する。したがって、本実施例に係る分析サーバ５０によれば、ドライバへの運転支援を実現することが可能になる。

さて、これまで開示の装置に関する実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下では、本発明に含まれる他の実施例を説明する。

［アップロード情報］
上記の実施例２では、情報通知装置４０から分析サーバ５０へ前方注視度がアップロードされる場合を例示したが、これはアップロードが行われる情報の種類を限定するものではない。例えば、情報通知装置は、前方注視度以外にも、他の車載装置、例えばナビゲーション装置やＥＣＵなどにより出力されるデータをアップロードすることもできる。

図６は、実施例３に係る情報通知装置６０及び分析サーバ７０を含むデータ分析システム３の構成例を示す図である。図６に示すように、データ分析システム３は、図４に示したデータ分析システム２と比べて、情報通知装置６０がＣＡＮ（Controller Area Network）・位置取得部６１をさらに有する点と、分析サーバ７０により実行される分析内容が異なる。なお、図６では、図４に示した機能部と同一の機能を発揮する機能部に同一の符号を付し、その説明を省略する。

ＣＡＮ・位置取得部６１は、ＣＡＮデータや位置データを取得する処理部である。

一実施形態として、ＣＡＮ・位置取得部６１は、ＣＡＮ等の車載ネットワークを介して接続されるＥＣＵから車速等の車両データを取得することができる。この他、ＣＡＮ・位置取得部６１は、ナビゲーション装置等に搭載されるＧＰＳ（Global Positioning System）受信機により測定される位置データを取得することもできる。

分析サーバ７０は、ＣＡＮ・位置取得部６１からアップロード部４１を介してアップロードされる車両データや位置データを用いることにより、次のような分析が可能になる。

図６には、１つの情報通知装置６０が分析サーバ７０に収容される場合が図示されているが、図示の例に限定されず、実際には、分析サーバ７０は多数の情報通知装置６０を収容することができる。このように多数の情報通知装置６０が分析サーバ７０に収容される場合、分析サーバ７０では、上記の車両データ及び上記の位置データを含むビッグデータを多数の情報通知装置６０から取得することも可能である。ここでは、一例として、車速の時系列データ、例えば時間および車速が対応付けられたデータが車両データとして取得されると共に、位置の時系列データ、例えば時間および位置（所定の座標系における座標、例えば緯度および経度など）が対応付けられたデータが位置データとして取得される場合を想定する。

これら車両データ及び位置データが取得された状況の下、分析サーバ７０は、走行中にわき見が多発する地点を割り出すことができる。具体的には、分析サーバ７０は、車両データに含まれる車速が所定値以上である場合、車両が走行中であると判断し、当該走行中である期間を識別する。続いて、分析サーバ７０は、情報通知装置６０からアップロードされる前方注視度のうち走行中である期間に算出された前方注視度ごとに当該前方注視度が「低」に分類される時刻にわき見のラベルを割り当てる。そして、分析サーバ７０は、位置データに含まれる位置のうちわき見のラベルが割り当てられた時刻に対応する位置をわき見イベントの発生地点と識別する。その上で、分析サーバ７０は、先に識別されたわき見イベントの発生地点を蓄積することにより次のようなサービスを提供することが可能になる。例えば、分析サーバ７０は、各情報通知装置６０からアップロードされた情報から割り出されたわき見イベントの発生地点を道路地図上にマッピングすることにより、道路地図における路線のわき見状況を把握させることができる。さらに、分析サーバ７０は、所定数以上のわき見イベントが発生しているノードやリンクをわき見イベントの多発地点として道路地図上にマッピングすることにより、道路地図上におけるわき見の多発地点を把握させることもできる。

また、図６では、情報通知装置６０から分析サーバ７０へ車両データや位置データがアップロードされる場合を例示したが、視認判定部１７による判定結果をアップロードさせることもできる。例えば、情報通知装置６０は、ＳＮＳサーバ３０から情報通知装置６０へ送信された広告メッセージがドライバにより視認されたか否かを判定する。これによって、ドライバのその広告に対する興味関心を分析することができる。

［閾値の設定方法］
図６に示す通り、前方注視度に加え、車両データや位置データが分析サーバ７０へ収集される場合、分析サーバ７０は、前方注視度、車両データ及び位置データを用いて、各実施例に示す情報通知装置１０、４０及び６０の通知制御部１８が前方注視度の分類に用いる閾値Ｔ１および閾値Ｔ２を設定することもできる。ここでは、車両データの一例として、車間距離の時系列データ、例えば時間および車間距離が対応付けられたデータが車両データとしてアップロードされる場合を想定して説明を行う。

例えば、分析サーバ７０は、レベル「高」、「中」および「低」に対応する場面のデータサンプルごとに前方注視度のヒストグラムを生成する。具体的は、分析サーバ７０は、位置データのサンプルのうち位置が図示しない道路ネットワークデータに含まれるノードの中でも交差点に対応する位置を含むサンプルを判別する。そして、分析サーバ７０は、先に判別された位置データのサンプルに含まれる時刻を検索キーとし、情報通知装置６０からアップロードされる前方注視度のサンプルのうち検索キーとする時刻に算出された前方注視度のサンプルを抽出する。その上で、分析サーバ７０は、先に抽出された前方注視度のサンプルから「交差点」に関する前方注視度のヒストグラムを生成する。

さらに、分析サーバ７０は、車両データのサンプルのうち車間距離が所定値以内であるサンプルを判別する。そして、分析サーバ７０は、先に判別された車両データのサンプルに含まれる時刻を検索キーとし、情報通知装置６０からアップロードされる前方注視度のサンプルのうち検索キーとする時刻に算出された前方注視度のサンプルを抽出する。その上で、分析サーバ７０は、先に抽出された前方注視度のサンプルから「先行車両有り」に関する前方注視度のヒストグラムを生成する。

また、分析サーバ７０は、情報通知装置６０からアップロードされる前方注視度のサンプルのうち、「交差点」に関する前方注視度のヒストグラム及び「先行車両有り」に関する前方注視度のヒストグラムのいずれのヒストグラムの生成にも使用されなかったサンプルを抽出する。その上で、分析サーバ７０は、先に抽出された前方注視度のサンプルから「交差点以外かつ先行車両無し」に関する前方注視度のヒストグラムを生成する。

これら３つの前方注視度のヒストグラムを用いて、分析サーバ７０は、前方注視度を３つのレベル「高」、「中」および「低」へ分類する閾値Ｔ１及び閾値Ｔ２を算出することができる。図７は、前方注視度のヒストグラムの一例を示す図である。図７の上段には、「交差点」に関する前方注視度のヒストグラム（Ａ）が示されると共に、図７の中段には、「交差点以外かつ先行車両無し」に関する前方注視度のヒストグラム（Ｂ）が示されている。さらに、図７の下段には、「先行車両有り」に関する前方注視度のヒストグラム（Ｃ）が示されている。

図７に示す通り、「交差点」に関する前方注視度のヒストグラム（Ａ）は、交差点であるので、周囲確認が必要な高負荷状態の典型であり、「先行車両有り」に関する前方注視度のヒストグラム（Ｃ）は先行車が存在するので、前方注視が必要な高負荷状態の典型である。また、「交差点以外かつ先行車両無し」に関する前方注視度のヒストグラム（Ｂ）はそれ以外の場合であるから、蓄積することで平均的な（高負荷でない）状態の度数分布になる。よって、（Ａ）、（Ｂ）及び（Ｃ）の度数分布は、最頻値がそれぞれ異なる。つまり、これらの度数分布を重ねると、３つの山ができる。

そこで、分析サーバ７０は、先述の２つの閾値Ｔ１及び閾値Ｔ２の決定方法として、３つの山により形成される、２つの谷の値を閾値Ｔ１及び閾値Ｔ２として設定することができる。例えば、図７の中段には、「交差点以外かつ先行車両無し」に関する前方注視度のヒストグラム（Ｂ）が実線で示される一方で、「交差点」に関する前方注視度のヒストグラム（Ａ）が一点鎖線で示されると共に、「先行車両有り」に関する前方注視度のヒストグラム（Ｃ）が破線で示されている。これら３つのヒストグラムの下、分析サーバ７０は、「交差点」に関する前方注視度のヒストグラム（Ａ）の曲線と、「交差点以外かつ先行車両無し」に関する前方注視度のヒストグラム（Ｂ）の曲線とが交わる交点を閾値Ｔ１に設定する。さらに、分析サーバ７０は、「交差点以外かつ先行車両無し」に関する前方注視度のヒストグラム（Ｂ）の曲線と、「先行車両有り」に関する前方注視度のヒストグラム（Ｃ）の曲線とが交わる交点を閾値Ｔ２に設定する。このように設定された閾値Ｔ１及び閾値Ｔ２は、前方注視度の送信元の情報通知装置６０へ送信された上で、通知制御部１８が前方注視度の分類を参照する内部メモリのワークエリアへ設定される。

このように、上記３つのヒストグラムを用いて閾値Ｔ１及び閾値Ｔ２を設定する場合、個人特性に合わせて前方注視度を分類する閾値を設定できる結果、疲労や緊張等に伴うわき見や過剰な周囲確認などをより精度良く判定できる。

［通知形態］
上記の実施例１及び２では、第１の通知を着信メッセージの表示出力＋効果音の音声出力とし、第２の通知を着信メッセージの表示出力とすることにより、第１の通知および第２の通知の差別化を実現する場合を例示したが、他の方法により、両者の差別化を実現することもできる。例えば、第１の通知を詳細表示とし、第２の通知を簡略表示とすることにより、第１の通知および第２の通知の差別化を実現することもできる。この場合、第１の通知では、例えば、着信メッセージの内容、例えばタイトルや本文を全て表示する一方で、第２の通知では、例えば、タイトルだけを表示したり、本文の一部だけを表示したり、未読の着信メッセージの存在を表すマークだけを表示したりすることができる。

［通知内容］
上記の実施例１及び２では、着信メッセージを通知する場合について説明したが、通知内容はメッセージに限定されず、メッセージ以外の表示出力にも上記の通知制御を適用できる。例えば、マークによる通知が行われる場合にも上記の通知制御を適用できる。この場合、マークのサイズを第１の通知よりも小さくすることにより第２の通知を実現したり、マークの色を第１の通知よりも彩度等を下げることにより第２の通知を実現することができる。この他、必ずしも表示出力による通知に限定されず、音声出力による通知にも上記の通知制御を適用できる。例えば、通知の音量を第１の通知よりも小さくすることにより第２の通知を実現したり、通知のテンポを第１の通知よりも遅くすることにより第２の通知を実現したり、あるいは通知音の周波数を下げることにより第２の通知を実現したりすることができる。

［スタンドアローン］
上記の実施例２及び３では、分析サーバ５０及び７０が上記のデータ分析サービスを情報通知装置４０または６０へ提供する場合を例示したが、データ分析サービスは必ずしもクライアントサーバシステムで提供されずともかまわない。すなわち、情報通知装置４０または６０は、実施例２及び３で説明したデータ分析サービスをスタンドアローンで実行することもできる。

［分散および統合］
また、図示した各装置の各構成要素は、必ずしも物理的に図示の如く構成されておらずともよい。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。例えば、受付部１４、視線検出部１５、注視度算出部１６、視認判定部１７又は通知制御部１８を情報通知装置１０、４０または６０の外部装置としてネットワーク経由で接続するようにしてもよい。また、受付部１４、視線検出部１５、注視度算出部１６、視認判定部１７又は通知制御部１８を別の装置がそれぞれ有し、ネットワーク接続されて協働することで、上記の情報通知装置１０、４０または６０の機能を実現するようにしてもよい。

［情報通知プログラム］
また、上記の実施例で説明した各種の処理は、予め用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータで実行することによって実現することができる。そこで、以下では、図８を用いて、上記の実施例と同様の機能を有する情報通知プログラムを実行するコンピュータの一例について説明する。

図８は、実施例１〜実施例３に係る情報通知プログラムを実行するコンピュータのハードウェア構成例を示す図である。図８に示すように、コンピュータ１００は、操作部１１０ａと、スピーカ１１０ｂと、カメラ１１０ｃと、ディスプレイ１２０と、通信部１３０とを有する。さらに、このコンピュータ１００は、ＣＰＵ１５０と、ＲＯＭ１６０と、ＨＤＤ１７０と、ＲＡＭ１８０とを有する。これら１１０〜１８０の各部はバス１４０を介して接続される。

ＨＤＤ１７０には、図８に示すように、上記の実施例１〜３で示した受付部１４、視線検出部１５、注視度算出部１６、視認判定部１７及び通知制御部１８と同様の機能を発揮する情報通知プログラム１７０ａが記憶される。この情報通知プログラム１７０ａは、図１、図４または図６に示した受付部１４、視線検出部１５、注視度算出部１６、視認判定部１７及び通知制御部１８の各構成要素と同様、統合又は分離してもかまわない。すなわち、ＨＤＤ１７０には、必ずしも上記の実施例１〜３で示した全てのデータが格納されずともよく、処理に用いるデータがＨＤＤ１７０に格納されればよい。

このような環境の下、ＣＰＵ１５０は、ＨＤＤ１７０から情報通知プログラム１７０ａを読み出した上でＲＡＭ１８０へ展開する。この結果、情報通知プログラム１７０ａは、図８に示すように、情報表示プロセス１８０ａとして機能する。この情報表示プロセス１８０ａは、ＲＡＭ１８０が有する記憶領域のうち情報表示プロセス１８０ａに割り当てられた領域にＨＤＤ１７０から読み出した各種データを展開し、この展開した各種データを用いて各種の処理を実行する。例えば、情報表示プロセス１８０ａが実行する処理の一例として、図２、図３や図５に示す処理などが含まれる。なお、ＣＰＵ１５０では、必ずしも上記の実施例１で示した全ての処理部が動作せずともよく、実行対象とする処理に対応する処理部が仮想的に実現されればよい。

なお、上記の情報通知プログラム１７０ａは、必ずしも最初からＨＤＤ１７０やＲＯＭ１６０に記憶されておらずともかまわない。例えば、コンピュータ１００に挿入されるフレキシブルディスク、いわゆるＦＤ、ＣＤ−ＲＯＭ、ＤＶＤディスク、光磁気ディスク、ＩＣカードなどの「可搬用の物理媒体」に情報通知プログラム１７０ａを記憶させる。そして、コンピュータ１００がこれらの可搬用の物理媒体から情報通知プログラム１７０ａを取得して実行するようにしてもよい。また、公衆回線、インターネット、ＬＡＮ、ＷＡＮなどを介してコンピュータ１００に接続される他のコンピュータまたはサーバ装置などに情報通知プログラム１７０ａを記憶させておき、コンピュータ１００がこれらから情報通知プログラム１７０ａを取得して実行するようにしてもよい。

以上の実施例を含む実施形態に関し、さらに以下の付記を開示する。

（付記１）ユーザ通知を受け付ける受付部と、
カメラにより撮像される画像に視線検出を実行する視線検出部と、
前記視線検出の結果として得られる視線方向から所定の領域を注視する注視度を算出する注視度算出部と、
前記注視度が第１の閾値以上である場合に、前記注視度が第１の閾値未満である場合に実行される第１の通知形態よりも質または量が下げられた第２の通知形態で前記ユーザ通知を実行する通知制御部と
を有することを特徴とする情報通知装置。

（付記２）前記通知制御部は、前記注視度が前記第１の閾値よりも小さい第２の閾値未満である場合に、前記ユーザ通知を前記第２の通知形態で実行することを特徴とする付記１に記載の情報通知装置。

（付記３）前記通知制御部は、前記ユーザ通知を表示出力により実行することを特徴とする付記１または２に記載の情報通知装置。

（付記４）前記視線検出の結果に基づいて、前記第２の通知形態で表示出力されたユーザ通知が視認されたか否かを判定する視認判定部をさらに有し、
前記通知制御部は、所定の時間にわたって前記第２の通知形態で表示出力されたユーザ通知が視認されなかった場合、前記ユーザ通知の表示出力を前記第２の通知形態から前記第１の通知形態へ切り替えることを特徴とする付記３に記載の情報通知装置。

（付記５）前記通知制御部は、前記第１の閾値以上の注視度が算出される頻度が所定値以上である場合に、周囲確認を促す通知をさらに実行することを特徴とする付記１〜４のいずれか１つに記載の情報通知装置。

（付記６）前記通知制御部は、前記第２の閾値未満の注視度が算出される頻度が所定値以上である場合に、わき見注意を喚起する通知をさらに実行することを特徴とする付記２に記載の情報通知装置。

（付記７）前記注視度算出部により算出された注視度のうち前記注視度算出部による算出が行われた時点の位置が交差点である注視度を第１のグループに分類し、前記注視度算出部による算出が行われた時点の車間距離が所定値未満である注視度を第２のグループに分類し、前記第１のグループ及び前記第２のグループに分類されない注視度を第３のグループに分類し、前記第１のグループ、前記第２のグループ及び前記第３のグループごとに注視度のヒストグラムを生成し、前記第１のグループ、前記第２のグループ及び前記第３のグループに関する３つの注視度のヒストグラムを用いて、前記第１の閾値および前記第２の閾値を設定することを特徴とする付記２に記載の情報通知装置。

（付記８）前記第１のグループに関する注視度のヒストグラムと、前記第３のグループに関する注視度のヒストグラムとの分布曲線の交点により定まる注視度の階級値を前記第２の閾値に設定すると共に、前記第２のグループに関する注視度のヒストグラムと、前記第３のグループに関する注視度のヒストグラムのとの分布曲線の交点により定まる注視度の階級値を前記第１の閾値に設定することを特徴とする付記７に記載の情報通知装置。

（付記９）前記第２の通知形態は、前記ユーザ通知の保留であることを特徴とする付記１〜８のいずれか１つに記載の情報通知装置。

（付記１０）ユーザ通知を受け付ける処理と、
カメラにより撮像される画像に視線検出を実行する処理と、
前記視線検出の結果として得られる視線方向から所定の領域を注視する注視度を算出する処理と、
前記注視度が第１の閾値以上である場合に、前記注視度が第１の閾値未満である場合に実行される第１の通知形態よりも質または量が下げられた第２の通知形態で前記ユーザ通知を実行する処理と
がコンピュータにより実行されることを特徴とする情報通知方法。

（付記１１）ユーザ通知を受け付ける処理と、
カメラにより撮像される画像に視線検出を実行する処理と、
前記視線検出の結果として得られる視線方向から所定の領域を注視する注視度を算出する処理と、
前記注視度が第１の閾値以上である場合に、前記注視度が第１の閾値未満である場合に実行される第１の通知形態よりも質または量が下げられた第２の通知形態で前記ユーザ通知を実行する処理と
をコンピュータに実行させることを特徴とする情報通知プログラム。

１０ 情報通知装置
１１ カメラ
１２ スピーカ
１３ 表示部
１４ 受付部
１５ 視線検出部
１６ 注視度算出部
１７ 視認判定部
１８ 通知制御部
２０ 携帯端末装置
３０ ＳＮＳサーバ

Claims (9)

1. ユーザ通知を受け付ける受付部と、
   カメラにより撮像される画像に視線検出を実行する視線検出部と、
   前記視線検出の結果として得られる視線方向から所定の領域を注視する注視度を算出する注視度算出部と、
   前記注視度が第１の閾値以上である場合に、前記注視度が第１の閾値未満である場合に実行される第１の通知形態よりも質または量が下げられた第２の通知形態で前記ユーザ通知を実行する通知制御部と
   を有することを特徴とする情報通知装置。
2. 前記通知制御部は、前記注視度が前記第１の閾値よりも小さい第２の閾値未満である場合に、前記ユーザ通知を前記第２の通知形態で実行することを特徴とする請求項１に記載の情報通知装置。
3. 前記通知制御部は、前記ユーザ通知を表示出力により実行することを特徴とする請求項１または２に記載の情報通知装置。
4. 前記視線検出の結果に基づいて、前記第２の通知形態で表示出力されたユーザ通知が視認されたか否かを判定する視認判定部をさらに有し、
   前記通知制御部は、所定の時間にわたって前記第２の通知形態で表示出力されたユーザ通知が視認されなかった場合、前記ユーザ通知の表示出力を前記第２の通知形態から前記第１の通知形態へ切り替えることを特徴とする請求項３に記載の情報通知装置。
5. 前記通知制御部は、前記第１の閾値以上の注視度が算出される頻度が所定値以上である場合に、周囲確認を促す通知をさらに実行することを特徴とする請求項１〜４のいずれか１つに記載の情報通知装置。
6. 前記通知制御部は、前記第２の閾値未満の注視度が算出される頻度が所定値以上である場合に、わき見注意を喚起する通知をさらに実行することを特徴とする請求項２に記載の情報通知装置。
7. 前記第２の通知形態は、前記ユーザ通知の保留であることを特徴とする請求項１または２に記載の情報通知装置。
8. ユーザ通知を受け付ける処理と、
   カメラにより撮像される画像に視線検出を実行する処理と、
   前記視線検出の結果として得られる視線方向から所定の領域を注視する注視度を算出する処理と、
   前記注視度が第１の閾値以上である場合に、前記注視度が第１の閾値未満である場合に実行される第１の通知形態よりも質または量が下げられた第２の通知形態で前記ユーザ通知を実行する処理と
   がコンピュータにより実行されることを特徴とする情報通知方法。
9. ユーザ通知を受け付ける処理と、
   カメラにより撮像される画像に視線検出を実行する処理と、
   前記視線検出の結果として得られる視線方向から所定の領域を注視する注視度を算出する処理と、
   前記注視度が第１の閾値以上である場合に、前記注視度が第１の閾値未満である場合に実行される第１の通知形態よりも質または量が下げられた第２の通知形態で前記ユーザ通知を実行する処理と
   をコンピュータに実行させることを特徴とする情報通知プログラム。

Images