JP2014051156A - 車載装置 - Google Patents

Abstract

【課題】携帯端末装置からの映像を車載装置に表示する際、利便性と安全性を両立する。
【解決手段】受信部１０は、携帯端末装置から表示データを受信する。判定部３０は、表示データを画像解析して、走行中に非表示とすべき情報が含まれるか否か判定する。画像合成部６０は、非表示とすべき情報を含む領域をマスキング処理する。例えば、表示データ内に、設定されたサイズ以下の文字が含まれる場合、その文字を含む領域をマスキングする。
【選択図】図１

Description

本発明は、スマートフォンなどの端末装置と連携する車載装置に関する。

近年、スマートフォンの画面を外部機器に表示させるミラーリングが普及してきている。例えば、スマートフォンと車載装置（例えば、ディスプレイオーディオ、カーナビゲーション装置）を接続し、スマートフォンの画面を車載装置のディスプレイに表示させる。一般に車載装置の画面サイズはスマートフォンの画面サイズより大きく、車載装置は運転者から比較的見やすい位置に設置されているため、スマートフォンと車載装置を連携してのミラーリング機能は便利な機能である。

ただし走行中に車載装置に映し出されるスマートフォンの画面を、運転者が見入ってしまうと危険である。そこで走行中はスマートフォンからの映像を表示しないようにすることが考えられる（例えば、特許文献１参照）。

特開２００９−３５０２４号公報

しかしながら走行中において、スマートフォンなどの携帯端末装置からの映像を車載装置に表示することを一律に禁止するのは利便性が低下する。安全とみなせる映像であれば、その表示を許容するのが利便性向上につながる。

本発明はこうした状況に鑑みなされたものであり、その目的は、携帯端末装置からの映像を車載装置に表示する際、利便性と安全性を両立する技術を提供することにある。

本発明のある態様の車載装置は、車載装置であって、携帯端末装置から表示データを受信する受信部と、前記表示データを画像解析して、走行中に非表示とすべき情報が含まれるか否か判定する判定部と、前記非表示とすべき情報を含む領域をマスキングするマスキング処理部と、を備える。

なお、以上の構成要素の任意の組み合わせ、本発明の表現を方法、装置、システム、記録媒体、コンピュータプログラムなどの間で変換したものもまた、本発明の態様として有効である。

本発明によれば、携帯端末装置からの映像を車載装置に表示する際、利便性と安全性を両立できる。

本発明の実施の形態１に係る車載装置の構成を示す図である。 判定パラメータ保持部に保持される判定パラメータを規定したテーブルの一例を示す図である。 判定パラメータ保持部に保持される判定パラメータを規定したテーブルの別の例を示す図である。 アプリ履歴保持部に保持されるテーブルの一例を示す図である。 画像解析および規制判定処理のタイミングチャートを示す図である。 図６（ａ）−（ｃ）は、インターネットラジオの表示画面の規制例を示す図である。 図７（ａ）−（ｄ）は、マスキングの具体的な表示方法について説明する図である。 図８（ａ）−（ｃ）は、音楽再生アプリケーションの表示画面の規制例を示す図である。 図９（ａ）−（ｃ）は、動画投稿アプリケーションの表示画面の規制例を示す図である。 本発明の実施の形態１に係る車載装置の動作を示すフローチャートである。 本発明の実施の形態２に係る車載装置の構成を示す図である。 図１２（ａ）−（ｂ）は、インターネットラジオの表示画面の文字変換例を示す図である。

図１は、本発明の実施の形態１に係る車載装置１００の構成を示す図である。車載装置１００はカーナビゲーション装置、ディスプレイオーディオなどが該当する。本実施の形態に係る車載装置１００は携帯端末装置と連携して動作する。当該携帯端末装置はスマートフォン、携帯電話機、タブレット、ＰＤＡ、携帯型音楽プレーヤ、携帯型ゲーム機などが該当する。車載装置１００と当該携帯端末装置とは、ＵＳＢ、ＨＤＭＩ（登録商標）などの有線通信、Bluetooth（登録商標）、Ｗｉ−Ｆｉ（登録商標）などの短距離無線通信により接続される。

当該携帯端末装置は、システムプログラムまたはアプリケーションプログラムを実行し、その表示データおよび音声データを、自己のディスプレイおよびスピーカに出力するとともに車載装置１００に送信する。本実施の形態では表示データについて注目するため音声データについては無視して考える。

車載装置１００は、受信部１０、制御部２０、表示部８０、操作部９０を備える。受信部１０は上記携帯端末装置から送信される表示データを受信する。受信部１０は受信した表示データを制御部２０に出力する。表示部８０は制御部２０から供給される表示データを表示する。操作部９０はユーザからの操作を受け付け、その操作内容に応じた指示信号を生成する。操作部９０は生成した指示信号を制御部２０に出力する。

制御部２０は車載装置１００全体を制御する。制御部２０は、判定部３０、アプリ履歴保持部４０、判定パラメータ保持部５０、画像合成部６０を含む。判定部３０は、走行状態判定部３２、アプリ特定部３４、画像解析部３６、規制判定部３８を含む。本実施の形態では走行規制処理に注目するため、走行規制処理に関連する構成のみを描いている。

上述の制御部２０の構成は、ハードウェア的には、任意のコンピュータのプロセッサ、メモリ、その他のＬＳＩで実現でき、ソフトウェア的にはメモリにロードされたプログラムなどによって実現されるが、ここではそれらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックがハードウェアのみ、ソフトウェアのみ、またはそれらの組み合わせによっていろいろな形で実現できることは、当業者には理解されるところである。

判定部３０は、上記携帯端末装置から受信した表示データを画像解析して、走行中に非表示とすべき情報が含まれるか否か判定する。画像合成部６０は、上記携帯端末装置から受信した表示データのうち、判定部３０により非表示とすべき情報を含む領域をマスキングする。以下、より具体的に説明する。

走行状態判定部３２は、車載装置１００が設置されている車両が走行中であるか否かを判定する。例えば、加速度センサまたは角速度センサを搭載してもよいし、車両内の各種計器（例えば、速度計）またはＥＣＵと接続してもよい。

アプリ特定部３４は、上記携帯端末装置から受信した表示データが、いずれのアプリケーションプログラムの表示データであるか特定する。上記携帯端末装置は、生成した表示データが、いずれのアプリケーションプログラムの表示データであるかを少なくとも先頭フレームのヘッダに書き込む。アプリ特定部３４は、その情報を参照してアプリケーションプログラムを特定できる。

画像解析部３６は、上記携帯端末装置から受信した表示データを画像解析する。画像解析部３６はＯＣＲ（Optical Character Recognition）機能を備え、表示データにより形成される画像内から文字を検出する。また画像解析部３６は、表示データにより形成される画像内から動画領域を検出する。

規制判定部３８は車両走行中に、上記携帯端末装置から受信した表示データに形成される画像内に、表示すべきでない文字および／または動画領域が含まれるか否か判定する。走行中に表示すべきでない文字および／または動画領域であるか否かは、運転中の運転者が表示部８０に表示される画像を見た際に、一定時間以上画面を見入る（以下本明細書では、注視という）可能性が高いか否かにより判断される。画面を注視する可能性が高い文字または動画の場合はその表示を禁止する。一方、画面を注視する可能性が低い文字または動画の場合はその表示を許容する。

文字の場合、小さな文字または込み入った文字は視認性が低いため運転者が注視する可能性が高いと考えられる。また長い文字列も運転者が注視する可能性が高いと考えられる。動画の場合、基本的に注視する可能性が高いと考えられる。車載装置メーカの中には走行中に、表示部８０にナビゲーション画面以外の動画（例えば、ＴＶやＤＶＤの映像）が映らないように規制しているメーカもある。ただし、ナビゲーション画面以外の動画を一律に規制するのは、運転者の利便性を犠牲にしている面もある。例えば、描画更新回数が少なかったり、アニメーションの領域が画面全体に比して小さかったりして、運転者が注視する可能性が低い映像であれば、動画であっても表示を許容してもよい場合があると考えられる。

規制判定部３８は車両走行中に、非表示とすべき文字または動画領域が含まれるか否かを、判定パラメータ保持部５０に保持される判定パラメータを用いて判定する。当該判定パラメータは、設計者による実験またはシミュレーションにもとづき決定された値に設定される。なお当該判定パラメータの値は、保守作業員による操作またはオンライン配布により事後的にアップデートすることが可能である。また当該判定パラメータの値は、ユーザにより変更が可能な設計であってもよい。

図２は、判定パラメータ保持部５０に保持される判定パラメータを規定したテーブル５０ａの一例を示す。図２では走行時の規制判定パラメータとして４種類のパラメータを挙げている。文字の大きさ、文字の長さ、動画領域の画面全体に対する占有率、動画領域の動きの速さである。それぞれの規制判定パラメータのしきい値として、２０ポイント以下、１０文字以上、１／４以上、１コマ／秒以上と設定されている。これは規制対象となる文字および動画を規定したものである。これらの条件を満たさない文字および動画は、規制対象から外れる。

即ち、画像解析部３６による画像解析の結果、上記携帯端末装置から受信した表示データにより形成される画面内に、設定された大きさ（図２の例では２０ポイント）以下の文字が含まれる場合、規制判定部３８はその文字を規制対象と判定する。規制判定部３８は、その文字をマスキングするよう画像合成部６０に指示し、画像合成部６０は当該画面内のその文字を含む領域をマスキングする。

また画像解析部３６による画像解析の結果、上記携帯端末装置から受信した表示データにより形成される画面内に、設定された文字数（図２の例では１０文字）以上の文字列が含まれる場合、規制判定部３８はその文字列を規制対象と判定する。規制判定部３８はその文字列をマスキングするよう画像合成部６０に指示し、画像合成部６０は当該画面内のその文字列を含む領域をマスキングする。

また画像解析部３６による画像解析の結果、上記携帯端末装置から受信した表示データにより形成される画面内に、設定された画面占有率（図２の例では１／４）以上の動画領域が含まれる場合、規制判定部３８はその動画領域を規制対象と判定する。規制判定部３８はその動画領域をマスキングするよう画像合成部６０に指示し、画像合成部６０は当該画面内のその動画領域を含む領域をマスキングする。

画面占有率が低い動画は、コンテンツそのものではなく、装飾、演出、効果を狙った簡易アニメーションまたは動的アイコンであることが多い。これらの簡易アニメーションまたは動的アイコンは基本的に意味を伝達するものではなく、運転者が注視する可能性が低いと考えられる。なお「処理中」、「受信中」などのステータスを示す動的アイコンは、文字ではなくシンボルで意味を伝達するものであるが、アイコンは小さな文字と異なり、運転者は瞬時にその形およびその意味を把握できるため注視する可能性が低いと考えられる。

また画像解析部３６による画像解析の結果、上記携帯端末装置から受信した表示データにより形成される画面内に、設定された速度（図２の例では１コマ／秒）以上で変化する動画領域が含まれる場合、規制判定部３８はその動画領域を規制対象と判定する。規制判定部３８はその動画領域をマスキングするよう画像合成部６０に指示し、画像合成部６０は当画面内のその動画領域を含む領域をマスキングする。

この規制により、テレビ放送、映画配信アプリケーション、動画投稿アプリケーションのような一般的な動画コンテンツは表示禁止になる。音楽再生アプリケーションの再生位置を示すインジケータ表示、時計アプリケーションなど、一定周期で更新され、一般的な動画コンテンツに比べ変化が少ない動画は表示禁止の対象としない。このような変化が少ない動画は、ほぼ静止画とみなすことができるためである。

なお「処理中」、「受信中」などのステータスを示す動的アイコンは、１コマ／秒以上の速さで変化するものもある。このような動的アイコンを規制対象から外すために、設定された画面占有率（例えば、１／１６）以下の動画領域については、設定された速度（図２の例では１コマ／秒）以上で変化していても、表示を許容するという例外条件を設けてもよい。

図３は、判定パラメータ保持部５０に保持される判定パラメータを規定したテーブル５０ｂの別の例を示す。図３に示すテーブル５０ｂは、図２に示すテーブル５０ａの文字に関する判定パラメータをより細分化して規定したテーブルである。

図３に示すテーブル５０ｂでは文字の大きさに関するパラメータのしきい値を、文字の書体（フォント）の種別に応じて異なる値に設定している。見やすい書体ほどしきい値を小さく、見にくい書体ほどしきい値を大きく設定する。図３に示すテーブル５０ｂではゴシック体の場合は２０ポイント以下、明朝体および行書体の場合は３０ポイント以下を規制対象としている。ゴシック体は線の太さがほぼ均一であり比較的見やすい書体である。一方、明朝体および行書体は線の太さが不均一であり比較的見にくい書体である。

図３に示すテーブル５０ｂでは文字の長さに関するパラメータのしきい値を、条件に応じて異なる値に設定している。まず図２に示すテーブル５０ａでは文字の長さを文字数のみで特定したが、文字列が描かれている領域の幅方向のドット数でも特定する。図３に示すテーブル５０ｂではそのドット数が１００ドット以上の文字列が規制対象となる。

また図３に示すテーブル５０ｂでは文字の長さに関するパラメータのしきい値を、文字コードの種別に応じて異なる値に設定している。見やすい文字コードほどしきい値を大きく（長く）、見にくい文字コードほどしきい値を小さく（短く）設定する。図３に示すテーブル５０ｂでは、検出される文字がＡＳＣＩＩ（American standard code for information interchange）コードの場合は２０文字以上、ひらがな及びカタカナの場合は１５文字以上、ＪＩＳ第１水準漢字の場合は１５文字以上、ＪＩＳ第２水準漢字の場合は１５文字以上を規制対象としている。

日本語の文字の形状は、ＡＳＣＩＩコードに規定されるアルファベットおよび数字の形状より複雑であることに鑑み、日本語の文字のほうを厳しい基準としている。なお、ひらがな及びカタカナと漢字を比較すると、形状は漢字のほうが複雑である。ただし表意文字である漢字は、表音文字であるひらがな及びカタカナより漢字圏の人間にとっては認識スピードが速いという面もある。そこで図３に示す例では両者の間でしきい値に軽重をつけていないが、両者の間でしきい値に軽重をつけてもよい。

また図３に示すテーブル５０ｂでは文字の長さに関するパラメータのしきい値を、言語の種別に応じて異なる値に設定している。見やすい文字の言語ほどしきい値を大きく（長く）、見にくい文字の言語ほどしきい値を小さく（短く）設定する。図３に示すテーブル５０ｂでは、検出される文字が日本語の場合は１５文字以上、繁体字中国語の場合は１５文字以上、簡体字中国語の場合は２０文字以上を規制対象としている。繁体字中国語の文字の形状は、簡体字中国語の文字の形状より複雑であるため繁体字中国語のほうの基準を厳しくしている。

図３に示すテーブル５０ｂを使用したほうが図２に示すテーブル５０ａを使用する場合より、きめ細かな処理が可能となるが、文字の種類および書体を厳密に特定する必要がある。したがって高度なＯＣＲ機能を搭載する必要がある。一方、図２に示すテーブル５０ａを使用する場合、画像内のオブジェクトが文字であることさえ特定できればよく、文字の種別および書体を厳密に特定する必要がない。例えば、カタカナの「ハ」と漢字の「八」を厳密に区別する必要もない。したがって簡易なＯＣＲ機能を搭載すれば足りる。設計者は必要に応じて両者を使い分ければよい。

図１に戻る。画像解析部３６は、上記携帯端末装置から受信した表示データの画像解析を、全フレームに対して実行してもよいし、定期的に実行してもよいし、最初だけ実行してもよい。画像解析を全フレームについてリアルタイムに行うには、高度なハードウェアスペックが必要となる。例えば、画像解析専用のＡＳＩＣを搭載する必要がある。この場合、全フレームについて非表示とすべき領域が特定できるため、画像合成部６０は、非表示とすべき文字または動画領域のみをピンポイントにマスキングできる。

画像解析を定期的（例えば、１分に１回）に行う場合、ソフトウェア処理も可能である。今回の画像解析から次回の画像解析までの間に、画面の構図が更新される可能性がある。したがって今回の画像解析により特定された、非表示とすべき文字または動画領域の存在または位置が、次回の画像解析までの間に消去または移動される可能性がある。この可能性に鑑み、画面内に非表示とすべき文字または動画領域が含まれる場合、画像合成部６０は画面全体をマスキングしてもよい。また画面の構図は頻繁に変わらないという経験則に鑑み、画像合成部６０は非表示とすべき文字または動画表示領域のみをマスキングしてもよい。

画面の構図は頻繁に変わらないという経験則を重視すると、アプリケーションプログラムが実行された後、最初の数フレームのみを画像解析するという手法も考えられる。この場合、ハードウェア資源に与える負荷を最小化できる。最初の数フレームのみを画像解析する場合においても、画像合成部６０は画面全体をマスキングしてもよいし、非表示とすべき文字または動画領域のみをマスキングしてもよい。

以下さらに処理負荷を軽減する手法について説明する。規制判定部３８は、画像解析部３６により走行中に非表示とすべき文字または動画領域を含まないと判定された表示データが、いずれのアプリケーションプログラムの表示データであるかをアプリ履歴保持部４０に履歴として格納する。具体的には、走行規制が不要と判定されたアプリケーションプログラムの識別情報を履歴として格納する。

アプリ履歴保持部４０に保持される走行規制が不要と判定されたアプリケーションプログラムの表示データが再度受信された場合、規制判定部３８は、画像解析部３６によるその表示データの画像解析をスキップさせる。即ち、新たな画像解析をせずに走行中における当該アプリケーションプログラムの表示データの表示を許可する。

図４は、アプリ履歴保持部４０に保持されるテーブル４０ａの一例を示す図である。当該テーブル４０ａにはアプリＩＤ、アプリ名、走行時の規制判定フラグが含まれる。このテーブル４０ａには、車載装置１００が新たなアプリケーションプログラムの表示データを受信する度、履歴データが追加される。図４に示すように各種のアプリケーションプログラムについて、画像解析の結果にもとづき走行規制が必要か否か登録される。

処理負荷の軽減の観点からは、対象のアプリケーションプログラムの表示データに走行中に非表示とすべき文字または動画領域を含まないと一度、判定されれば、その判定結果を次回以降使用し続けることが有効である。しかしながら、アップデートにより当該アプリケーションプログラムの表示画面の構図が変更される場合がある。また最初に画像解析部３６が文字または動画領域を誤認識する可能性もある。そこで当該アプリケーションプログラムが実行された場合において、前回の実行から一定の期間（例えば、１ヶ月）が経過している場合、画像解析をスキップせずに再度、行ってもよい。

上述したように画像解析部３６が文字または動画領域を誤認識する可能性がある。また上述の条件に当てはめると規制対象となる文字列または動画であっても、人間の感覚では必ずしも安全性を損なう文字列または動画ではないと判断できるものもある。またその逆の場合も考えられる。

そこでユーザが操作部９０を操作して、アプリ履歴保持部４０に保持される履歴データの内容を編集できるように設計されていてもよい。例えば、「規制なし」と判定されたアプリケーションプログラムであっても、ユーザが安全性を損なう文字列または動画が含まれると判断した場合、ユーザがそのアプリケーションプログラムの規制判定フラグを「規制あり」に書き換えることができる。

また運転者が運転中、アプリケーションプログラムの表示画面を見たとき、その表示画面が規制されるべきものか否か判断に悩む場合がある。そこで表示画面を保存する機能を設けてもよい。操作部９０に保存キーを設け、保存キーが押下されると、規制判定部３８はその時点で表示されている表示画面を、図示しないフレームバッファに保存する。運転者は運転終了後に操作部９０を操作して、当該フレームバッファに保存された表示画面を読み出し、表示部８０に表示させる。これにより運転者であるユーザは、そのアプリケーションプログラムの表示画面が規制されるべきか否かじっくり検討できる。

一般的にアプリケーションプログラムは、ユーザによる実行開始操作がなされてから、実際に実行可能な状態になるまで時間がかかる。通常、プログラムおよびデータは外部メモリに格納されているため内部メモリに読み込む時間が必要となる。この立ち上がり時間中、何らかのアニメーションまたは動的アイコンが表示されることが多い。

したがって上記携帯端末装置から受信部１０がアプリケーションプログラムの実行開始信号を受信して直ぐに、画像解析部３６が画像解析を開始すると、このアニメーションまたは動的アイコンを動画として認識する可能性がある。そして規制判定部３８が非表示とすべき動画を含む表示データを生成するアプリケーションプログラムと判定してしまう可能性がある。またアプリケーションプログラムが完全に起動する前は、背景にメニュー画面が表示されていることが多いため、画像解析部３６はメニュー画面からアプリ画面への遷移を、動画と認識する可能性がある。

そこで上記携帯端末装置から受信部１０がアプリケーションプログラムの実行開始信号を受信してから所定の設定期間、画像解析部３６は上記携帯端末装置から受信した表示データの画像解析を保留する。当該設定期間経過後から、画像解析部３６は当該表示データの画像解析を開始する。これにより、アプリケーションプログラム以外の表示データにより、当該アプリケーションプログラムの規制判定がなされることを回避できる。

図５は、画像解析および規制判定処理のタイミングチャートの一例を示す。このタイミングチャートでは、ユーザ操作により特定のアプリケーションプログラムの起動が開始してから０．５秒間、画像解析および規制判定処理を保留する。０．５秒経過後、画像解析処理および規制判定処理を実行する。当該処理は、リアルタイムに実行されてもよいし、定期的に実行されてもよいし、最初の１回だけ実行されてもよい。

以下、具体的なアプリケーションプログラムの表示画面の規制例を示す。図６（ａ）−（ｃ）は、インターネットラジオの表示画面の規制例を示す。図６（ａ）はオリジナルの表示画面を示す。インターネットラジオの表示画面には主に、放送局名、放送時間、番組情報が表示される。図６（ａ）を参照すると「番組情報」、「21:30-22:00」、「番組メールアドレス：」、「[email protected]」、「xxxxxxxハッシュタグは「#xxxx」」、「xxxxxxxアカウントは「@xxxxxx」」の各文字列はサイズが小さく、規制判定部３８は表示禁止と判定する。また「xxxxxxxハッシュタグは「#xxxx」」及び「xxxxxxxアカウントは「@xxxxxx」」の各文字列は２０文字以上であり、規制判定部３８は文字数の条件からも表示禁止と判定する。

図６（ａ）に示すような小さな文字で描かれたメールアドレス、ハッシュタグ、ＳＮＳのアカウントなどが走行中に表示されると、それを見た運転者はその内容を把握しようと、意識的または無意識的に注視してしまう可能性がある。そこで画像合成部６０は、それらの文字列をマスキングする。図６（ｂ）は、それらの文字列のみをマスキングした表示画面を示す。図６（ｃ）は、画面全体をマスキングした表示画面を示す。

ここでマスキングの方法について説明する。図７（ａ）−（ｄ）はマスキングの具体的な表示方法について説明する図である。図７（ａ）が元の表示画面であったとすると、図７（ｂ）は図６（ｂ）と同様にベタ塗りによるマスキング、図７（ｃ）は文字列を表示せずに文字列のあった部分に下線を表示することによるマスキング、図７（ｄ）は文字列を表示せず透明化するマスキングを示している。これ以外にも様々なマスキング方法が考えられるが、本実施の形態では以下ベタ塗りをするものとして記載する。

図８（ａ）−（ｃ）は、音楽再生アプリケーションの表示画面の規制例を示す。図８（ａ）はオリジナルの表示画面を示す。音楽再生アプリケーションの表示画面には主に、アーティスト名、曲名、アルバム／シングルタイトル、再生インジケータ、ジャケット写真が表示される。図８（ａ）を参照するとアーティスト名を示す「Xxxxx Xxxxxxx」、曲名を示す「What the Xxxx」、シングルタイトルを示す「What the Xxxx-Single」、再生インジケータｉｎ１の付加情報を示す「1:48」及び「-1:51」、再生トラック情報を示す「40of43」の各文字列はサイズが小さい。規制判定部３８は表示禁止と判定する。

再生インジケータｉｎ１は、再生位置を示すシンボルマーク（図８（ａ）では丸型であるが、バー型でもよい）が楽曲の進行とともに右に移動する。したがって再生インジケータｉｎ１は動画のカテゴリに含まれるが、その移動速度が１コマ／秒未満である。よって再生インジケータｉｎ１は表示が許可される。ジャケット写真は静止画であるため表示が許可される。

図８（ａ）に示すような小さな文字で描かれたアーティスト名、曲名などが走行中に表示されると、それを見た運転者はその内容を把握しようと、意識的または無意識的に注視してしまう可能性がある。そこで画像合成部６０は、それらの文字列をマスキングする。なお再生インジケータｉｎ１はマスキングしない。図８（ｂ）は、それらの文字列のみをマスキングした表示画面を示す。図８（ｃ）は、画面全体をマスキングした表示画面を示す。

図９（ａ）−（ｃ）は、動画投稿アプリケーションの表示画面の規制例を示す。図９（ａ）はオリジナルの表示画面を示す。動画投稿アプリケーションの表示画面には主に、動画領域Ｖ１、操作領域が含まれる。画面全体に対する動画領域Ｖ１が占める割合が１／４以上であるため、規制判定部３８は表示禁止と判定する。また動画領域Ｖ１の動きの速度は、通常１コマ／秒以上であるため、規制判定部３８はその条件からも表示禁止と判定する。

図９（ａ）に示すような動画領域Ｖ１は、運転者はその動画を意識的または無意識的に注視してしまう可能性がある。そこで画像合成部６０は、動画領域Ｖ１をマスキングする。図９（ｂ）は、動画領域Ｖ１のみをマスキングした表示画面を示す。図９（ｃ）は、画面全体をマスキングした表示画面を示す。

図１０は、本発明の実施の形態１に係る車載装置１００の動作を示すフローチャートである。まず受信部１０は、上記携帯端末装置から特定のアプリケーションプログラムの表示データを受信する（Ｓ１０）。アプリ特定部３４は、当該表示データを生成しているアプリケーションプログラムを特定する（Ｓ１１）。アプリ特定部３４は、特定したアプリケーションプログラムの情報を規制判定部３８に渡す。

規制判定部３８はアプリ履歴保持部４０を参照し、当該アプリケーションプログラムの規制判定履歴を探索する（Ｓ１２）。規制判定履歴が存在しないか、または規制判定履歴が存在してもその規制判定履歴が走行規制ありの場合（Ｓ１２のＮ）、規制判定部３８は画像解析部３６に画像解析を指示する。

画像解析部３６は、受信された表示データを画像解析する（Ｓ１３）。画像解析部３６はその解析結果を規制判定部３８に渡す。規制判定部３８は当該表示データ内に規制すべき文字または動画領域を含むか否か判定する（Ｓ１４）。含む場合（Ｓ１４のＹ）、規制判定部３８は画像合成部６０にマスキングを指示する。画像合成部６０は、規制すべき文字または動画領域を含む領域をマスキングする（Ｓ１５）。表示部８０はマスキングされた画像を表示する（Ｓ１６）。

ステップＳ１４にて当該表示データ内に規制すべき文字または動画領域を含まない場合（Ｓ１４のＮ）、ステップＳ１５をスキップする。表示部８０はマスキングされていない画像を表示する（Ｓ１６）。

ステップＳ１２にて当該アプリケーションプログラムの規制判定履歴がアプリ履歴保持部４０に存在し、かつその規制判定履歴が走行規制なしの場合（Ｓ１２のＹ）、ステップＳ１３〜ステップＳ１５をスキップする。表示部８０はマスキングされていない画像を表示する（Ｓ１６）。

以上説明したように実施の形態１によれば、携帯端末装置からの映像を車載装置に表示する際に、表示禁止すべき情報をマスキングすることにより、利便性と安全性を両立できる。走行中であっても運転者が注視する可能性が低い映像内容であれば、その表示を許容することにより、運転者の利便性を向上できる。一方、運転者が注視する可能性が高い映像内容については、その表示を禁止することにより安全性を向上できる。

また本実施の形態では表示データを画像解析することにより、表示禁止すべきオブジェクトが画面内に含まれるか否か判定する。したがって画面全体のマスキングではなく、表示禁止すべきオブジェクトのみのマスキングも可能となる。また汎用性が高い走行規制処理を実現できる。アプリケーションプログラムごとに上記携帯端末装置から車載装置に表示を許可するか禁止するかを指示する信号を送る手法では、新たな通信規則を設定する必要があり汎用性が低い。

またその手法では事前に全てのアプリケーションプログラムについて走行規制するか否か判定しなければならず、車載装置メーカ以外のメーカまたはベンダに、煩雑な負担を強いることになる。この点、本実施の形態では車載装置メーカのテリトリで走行規制処理を完結させることができる。

図１１は、本発明の実施の形態２に係る車載装置１００の構成を示す図である。実施の形態２に係る車載装置１００は、図１に示した実施の形態１に係る車載装置１００の制御部２０に文字変換部７０が追加された構成である。

文字変換部７０は相対的に見にくい文字を相対的に見やすい文字に変換する。例えば、以下の変換処理を行う。書体（フォント）を相対的に見やすいものに変換する。旧漢字を新漢字に変換する。中国語の繁体字を中国語の簡体字に変換する。ひらがな及びカタカナを漢字に変換する。

画像解析部３６は、上記携帯端末装置から受信した表示データから、変換すべき文字を検出する。文字変換部７０は、検出された文字を、図示しない変換テーブルを参照して相対的に見やすい文字に変換する。なお当該変換テーブルには、変換すべき文字および変換後の文字が関連づけられて登録されている。画像合成部６０は、表示データ内の変換すべき文字を変換後の文字で上書きする。具体的には、表示データ内の変換すべき文字が存在する位置に、変換後の文字を描いたイメージデータを貼り付ける。

この文字変換処理により、文字のサイズまたは文字列の長さが変わる場合がある。例えば、ひらがな及びカタカナを漢字に変換すると通常、文字数が少なくなる。したがって文字変換前は走行規制条件に該当していたが、文字変換後は走行規制条件に該当しなくなるケースも発生する。そこで規制判定部３８は、少なくとも文字に関する走行規制判定を、文字変換部７０による文字変換後に実行する。その他の処理は、実施の形態１と同じであるため説明を省略する。

図１２（ａ）−（ｂ）は、インターネットラジオの表示画面の文字変換例を示す。図１２（ａ）はオリジナルの表示画面を示す。図１２（ａ）に示す表示画面には出演者名として「澤 榮子」と明朝体の文字で描かれている。またメッセージとして「おたよりおくってください。」と明朝体の文字で描かれている。

文字変換部７０は旧漢字の文字列「澤 榮子」を新漢字の文字列「沢 栄子」に変換する。また文字変換部７０は、ひらがなのみの文字列「おたよりおくってください。」を、漢字かな混じりの文字列「お便り送って下さい。」に変換する。また文字変換部７０は変換後のそれらの文字列の書体を、明朝体からゴシック体に変換する。なお上述しように画像合成部６０は、表示禁止すべきサイズの小さな文字列をマスキングする。

図１２（ｂ）は文字変換およびマスキング後の表示画面を示す。図１２（ａ）と図１２（ｂ）を比較すると、表示画面が見やすくなったことが分かる。なお出演者名などの有益な情報が残るため、運転者の利便性向上に資する。

以上説明したように実施の形態２によれば、実施の形態１と同様の効果を奏するとともに、表示を許容する文字をより見やすくできる。したがって安全性をより高めることができる。

以上、本発明を実施の形態をもとに説明した。こられ実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。

１００ 車載装置、 １０ 受信部、 ２０ 制御部、 ３０ 判定部、 ３２ 走行状態判定部、 ３４ アプリ特定部、 ３６ 画像解析部、 ３８ 規制判定部、 ４０ アプリ履歴保持部、 ５０ 判定パラメータ保持部、 ６０ 画像合成部、 ７０ 文字変換部、 ８０ 表示部、 ９０ 操作部。

Claims (6)

1. 車載装置であって、
   携帯端末装置から表示データを受信する受信部と、
   前記表示データを画像解析して、走行中に非表示とすべき情報が含まれるか否か判定する判定部と、
   前記非表示とすべき情報を含む領域をマスキングするマスキング処理部と、
   を備えることを特徴とする車載装置。
2. 前記マスキング処理部は、前記表示データ内に、設定されたサイズ以下の文字が含まれる場合、その文字を含む領域をマスキングすることを特徴とする請求項１に記載の車載装置。
3. 前記マスキング処理部は、前記表示データ内に、設定された文字数以上の文字列が含まれる場合、その文字列を含む領域をマスキングすることを特徴とする請求項１または２に記載の車載装置。
4. 前記マスキング処理部は、前記表示データ内に、設定された画面占有率以上の動画領域が含まれる場合、その動画領域を含む領域をマスキングし、設定された画面占有率未満の動画領域が含まれる場合、その動画領域をマスキングしないことを特徴とする請求項１から３のいずれかに記載の車載装置。
5. 前記マスキング処理部は、前記表示データ内に、設定された速度以上で動く動画領域が含まれる場合、その動画領域を含む領域をマスキングし、設定された速度未満で動く動画領域が含まれる場合、その動画領域をマスキングしないことを特徴とする請求項１から４のいずれかに記載の車載装置。
6. 前記判定部により走行中に非表示とすべき情報を含まないと判定された表示データが、いずれのアプリケーションプログラムの表示データであるかを履歴として保持する履歴保持部を、さらに備え、
   前記判定部は、前記履歴保持部に保持されるアプリケーションプログラムの表示データが受信されると、その表示データの画像解析をスキップすることを特徴とする請求項１から５のいずれかに記載の車載装置。

Images