(57)【要約】【課題】多様化するアプリケーションプログラムの実行方式に対応し適切に走行規制機能を提供する車載端末を実現すること。【解決手段】車載端末１０は、車両２０の走行状態を判定する走行状態判定部１１０と、アプリケーションプログラムを所定の実行方式で実行するアプリ実行部１００（２３２，２３４，２３６）と、アプリケーションプログラムを実行する際、走行状態判定部の判定結果に応じて所定の規制ルールに基づき走行規制を加えるアプリ制御部２３０と、を備える。規制ルールとして、アプリケーションプログラムの実行方式に固有の規制ルール２２２，２２４，２２６と、アプリケーションプログラムの実行方式に関係しない共通の規制ルール２２０とを保持し、実行するアプリケーションプログラムに応じて、アプリ管理ＤＢ２１８を参照しいずれかの規制ルールを適用する。【選択図】図２
2015014956.tif 000002
【特許請求の範囲】
【請求項１】
外部情報機器から入力されたアプリケーションプログラムを車両の走行状態に応じて規制を加えて実行する車載端末であって、
前記車両の走行状態を判定する走行状態判定部と、
前記アプリケーションプログラムを所定の実行方式で実行するアプリ実行部と、
前記アプリケーションプログラムを実行する際、前記走行状態判定部の判定結果に応じて所定の規制ルールに基づき走行規制を加えるアプリ制御部と、を備え、
前記規制ルールとして、アプリケーションプログラムの実行方式に固有の規制ルールと、アプリケーションプログラムの実行方式に関係しない共通の規制ルールとを保持し、実行するアプリケーションプログラムに応じていずれかの規制ルールを適用することを特徴とする車載端末。
【請求項２】
請求項１に記載の車載端末であって、
前記共通の規制ルールとは、前記車両の走行状態が走行中の場合、前記アプリケーションプログラムが実行する機能を全て無効にするものであることを特徴とする車載端末。
【請求項３】
請求項１または２に記載の車載端末であって、
アプリケーションプログラム毎に、当該アプリケーションプログラムを実行する実行方式と適用する規制ルールを定めたデータベースを有することを特徴とする車載端末。
【請求項４】
請求項３に記載の車載端末であって、
アプリケーションプログラムを実行する際、外部情報機器に接続して当該アプリケーションプログラムに適用する最新の規制ルールを取得し、前記データベースの内容を更新または追加することを特徴とする車載端末。
【請求項５】
請求項４に記載の車載端末であって、
前記データベースと前記外部情報機器のいずれからも当該アプリケーションプログラムに適用する規制ルールを取得できない場合は、前記共通の規制ルールを適用することを特徴とする車載端末。
【請求項６】
請求項１に記載の車載端末であって、
前記アプリケーションプログラムが当該アプリケーションプログラムに適用する規制ルールを内蔵している場合、前記アプリ実行部は、前記内蔵された規制ルールに基づく規制用アプリケーションプログラムを並行して実行し、
前記アプリ制御部は、前記走行状態判定部の判定結果に応じて、前記アプリケーションプログラムによる出力に前記規制用アプリケーションプログラムによる出力を合成することで走行規制を加えることを特徴とする車載端末。
【請求項７】
請求項６に記載の車載端末であって、
前記走行状態が走行中のとき、前記規制用アプリケーションプログラムにより出力される表示画面の内容を、前記外部情報機器により変更可能であることを特徴とする車載端末。
【請求項８】
請求項１乃至７のいずれかに記載の車載端末は、携帯電話の基本構成を含む情報処理装置により実現したことを特徴とする車載端末。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、カーナビゲーション機能を提供する車載端末に関するものである。
【背景技術】
【０００２】
近年のカーナビゲーション等の車載端末は、３Ｇ（3rd Generation）回線網やＬＴＥ（Long Term Evolution）回線網などの移動体通信網に接続するための通信機能、無線ＬＡＮ（Local Area Network）に接続するための通信機能、ＵＳＢ（Universal Serial Bus）やＢｌｕｅｔｏｏｔｈ（登録商標）などの機器間通信で携帯電話と接続して携帯電話経由でデータ通信を行う機能を備える。これにより、Ｗｅｂからデータを取得し、取得したデータを車載端末のアプリケーションプログラムやＷｅｂブラウザ等に入力して実行することができる。
【０００３】
また、スマートフォン等の携帯電話側でアプリケーションプログラムを実行し、ＨＤＭＩ（High-Definition Multimedia Interface、登録商標）やＭｉｒｒｏｒＬｉｎｋ（登録商標）等により、携帯電話で実行中のアプリケーションプログラムの画面を車載端末に送信して表示することもできる。このように、車載端末では多様な形態で情報が提供される。
【０００４】
一方、車載端末は運転者を含む車載端末のユーザに対して、動画、画像、音声、文字等を含んだ多くの情報を提供する。これらの提供する情報が切り替わると、運転者は車載端末に表示される情報や車載端末の操作に気を取られて車両の運転動作が疎かになり、安全性に支障をきたす恐れがある。これに対応するために、従来の車載端末では運転者の安全を妨げないよう、走行中は車載端末の表示や操作を規制する機能（以下、走行規制機能）が搭載されている。
【０００５】
車載端末において走行規制を実現する技術として、特許文献１には、コンテンツ（アプリケーションプログラム）毎に車両の状態に応じた動作の可否を制御するものが開示されている。該文献では、コンテンツの属性と車両が走行中であるか否かといった外部の状態とに基づき、コンテンツの入力や出力、ユーザ操作の情報を制御している。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２０１１−０７０６８９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
上記特許文献１の技術では、アプリケーションプログラムは車載端末上で動作する単一の実行方式を対象にしており、走行規制機能は、単一の実行方式の内部で提供される。しかしながら、近年の車載端末の情報提供の形態は、車載端末上で動作するアプリケーションプログラムの他に、ＨＴＭＬ（Hyper Text Markup Language）コンテンツを表示するＷｅｂブラウザや、携帯電話で実行されるアプリケーションプログラムの表示など、実行方式は多様化している。特許文献１の技術では、このように多様化するアプリケーションプログラムの実行方式に対して、どのように走行規制機能を提供するかについては開示されていない。よって、このような対象外の実行方式で動作するアプリケーションプログラムについては、走行中には全く実行できないものとすれば、ユーザの利便性を損なうことになる。
【０００８】
本発明の目的は、多様化するアプリケーションプログラムの実行方式に対応し適切に走行規制機能を提供する車載端末を実現することである。
【課題を解決するための手段】
【０００９】
本発明は、外部情報機器から入力されたアプリケーションプログラムを車両の走行状態に応じて規制を加えて実行する車載端末であって、車両の走行状態を判定する走行状態判定部と、アプリケーションプログラムを所定の実行方式で実行するアプリ実行部と、アプリケーションプログラムを実行する際、走行状態判定部の判定結果に応じて所定の規制ルールに基づき走行規制を加えるアプリ制御部と、を備え、規制ルールとして、アプリケーションプログラムの実行方式に固有の規制ルールと、アプリケーションプログラムの実行方式に関係しない共通の規制ルールとを保持し、実行するアプリケーションプログラムに応じていずれかの規制ルールを適用することを特徴とする。
【発明の効果】
【００１０】
本発明によれば、多様化するアプリケーションプログラムの実行方式に対応し適切に走行規制機能を提供できるので、ユーザの安全性と利便性を確保することができる。
【図面の簡単な説明】
【００１１】
【図１】実施例１にかかる車載端末の全体構成を示す図。
【図２】アプリ実行部１００の内部構成を示す図。
【図３】アプリ制御部２３０の内部構成を示す図。
【図４】ネイティブアプリ実行部２３２の内部構成を示す図。
【図５】ブラウザ２３４の内部構成を示す図。
【図６】携帯電話クライアント２３６の内部構成を示す図。
【図７】規制パターン格納部２１４の格納データを示す図。
【図８】アプリ管理ＤＢ２１８の格納データを示す図。
【図９】アプリ共通規制ルール２２０の例を示す図。
【図１０】ネイティブアプリ規制ルール２２２の例を示す図。
【図１１】ブラウザ規制ルール２２４の例を示す図。
【図１２】携帯電話クライアント規制ルール２２６の例を示す図。
【図１３】走行規制設定の手順を示すフローチャート。
【図１４】走行規制処理のシーケンスを示す図。
【図１５】実施例２にかかる車載端末の構成を示す図。
【図１６】アプリ管理ＤＢ２１８の格納データを示す図。
【図１７】規制ルールの更新処理の手順を示すフローチャート。
【図１８】実施例３における規制ルールの適用処理の手順を示すフローチャート。
【図１９】実施例４にかかる車載端末の構成を示す図。
【図２０】規制アプリ３３を使用した走行規制の適用画面の例。
【図２１】規制パターン格納部２１４の格納データを示す図。
【図２２】アプリ管理ＤＢ２１８の格納データを示す図。
【図２３】アプリ内蔵規制ルール３２を用いた走行規制処理のシーケンスを示す図。
【図２４】規制アプリの表示内容を携帯電話３０により更新する処理を示す図。
【図２５】実施例５にかかる情報処理装置の構成を示す図。
【発明を実施するための形態】
【００１２】
以下、本発明のいくつかの実施の形態を図面を用いて説明する。以下の説明では、車載端末にて使用するアプリケーションプログラムや表示する情報を、単に「アプリケーション」と呼ぶことにする。
【実施例１】
【００１３】
図１は、実施例１にかかる車載端末の全体構成を示す図である。車載端末１０は、車両２０に搭載されるカーナビゲーション等の情報処理端末である。本実施例の車載端末１０は、携帯電話３０やサーバ４０などの外部情報機器に接続し、アプリケーションプログラムや情報（以下、アプリケーション）を取得して運転者を含む車載端末のユーザに提供する機能を持つ。携帯電話３０はスマートフォンを含む情報処理端末であり、３Ｇ回線網やＬＴＥ回線網などの移動体通信網への接続機能を有する。またサーバ４０は、車載端末１０に対してＷｅｂサービスや情報を提供する。外部情報機器はこれらに限定せず、接続可能な任意の機器を対象とする。
【００１４】
携帯電話３０との接続は、機器間通信部１４０が行う。ここでいう機器間通信は、ＵＳＢ、Ｂｌｕｅｔｏｏｔｈ（登録商標）といった、車載端末１０や携帯電話３０が一般的に有している機器間での通信機能である。サーバ４０との接続は、移動体通信部１４２および無線ＬＡＮ１４４が行う。移動体通信部１４２は、３Ｇ回線網やＬＴＥ回線網などの移動体通信網に接続するための通信機能である。無線ＬＡＮ１４４はＩＥＥＥ８０２．１１規格を使用した通信機能である。携帯電話３０はサーバ４０にも接続し、サーバ４０から取得した情報を機器間通信部１４０を介して車載端末１０に提供する。不揮発性メモリ１４６はフラッシュメモリやＳＤカード（登録商標）であり、車載端末１０で使用するアプリケーション、および携帯電話３０やサーバ４０から取得したアプリケーションが格納される。
【００１５】
アプリ実行部１００は、携帯電話３０やサーバ４０から取得したアプリケーション、および不揮発性メモリ１４６に格納されたアプリケーションを用いて、運転者を含む車載端末１０のユーザに対するサービスや情報を提供する。その際、走行状態判定部１１０から受信する車両走行状態の判定結果に応じて、ユーザに提供するサービスや情報の走行規制を行う。
【００１６】
走行状態判定部１１０は、ＣＡＮ情報取得部１２２、車両信号取得部１２４、車載端末センサ１２６からの情報を用いて、車両２０が停止中であるか走行中であるか、また走行中であれば前進／後退の区別や走行速度などの走行状態を判定する。走行状態の判定結果は、逐次アプリ実行部１００に対して送信する。
【００１７】
ＣＡＮ情報取得部１２２は、車両２０のＣＡＮ（Controller Area Network）２１に接続され、車両２０の操作情報であるブレーキの操作情報、ハンドルの操舵情報、速度情報、加速度情報、ヨー情報、燃費情報等を取得する。車両信号取得部１２４は、車両２０の車速を示す車速パルス２２、パーキングブレーキの状態を示すパーキングブレーキ信号２３、車両２０がバックをしているかを示すバック信号２４等、車両の状態を示す信号を取得する。車載端末センサ１２６は、ＧＰＳ（Global Positioning System）やジャイロスコープ等の、車載端末１０に具備されてカーナビゲーション機能における車両２０の位置特定および経路案内に使用される機能である。
【００１８】
表示管理部１５０は、アプリ実行部１００から出力された表示情報を表示装置１５２に出力する。その際、表示するアプリケーションの優先度を判定する。操作管理部１６０は、タッチパネルやボタン、ステアリングコントローラなどの操作装置１６２を介しユーザが行った操作情報をアプリ実行部１００に出力する。その際、操作するアプリケーションの優先度を判定し、操作情報を伝達すべきアプリケーション先を特定する。音声管理部１７０は、アプリ実行部１００が出力した音声情報をスピーカ１７２へ出力し、またマイク１７４が取得した音声情報をアプリ実行部１００へ出力する。その際、出力する音声のアプリケーションについて優先度を判定し、マイク１７４から取得した音声情報を伝達すべきアプリケーション先を特定する。
【００１９】
以下、各部の構成を詳細に説明する。
図２は、アプリ実行部１００の内部構成を示す図である。アプリ実行部１００は、アプリ実行方式選択部２１０とアプリ制御部２３０を中心に構成される。
【００２０】
アプリ実行方式選択部２１０は、機器間通信部１４０、移動体通信部１４２、無線ＬＡＮ１４４、および不揮発性メモリ１４６と接続し、これらから様々なアプリケーション（アプリケーションプログラムや情報）を入力する。そして、入力したアプリケーションに付加される識別子から当該アプリケーションが動作するアプリ実行方式を決定し、該当するアプリ実行方式に対しアプリケーションを送信する。また、アプリ実行方式選択部２１０は、規制パターン判定部２１２と規制パターン格納部２１４、およびアプリ管理データベース（ＤＢ）２１８と接続し、アプリケーションの起動開始時に走行規制が必要であるか不要であるか、また走行規制ではどの規制ルールを適用するかを判定する。
【００２１】
本実施例では、アプリ実行方式としてネイティブアプリ実行部２３２、ブラウザ２３４、携帯電話クライアント２３６の３通りを備える。入力したアプリケーションは、これらのいずれかのアプリ実行方式で実行され、アプリ制御部２３０を介して、表示管理部１５０、操作管理部１６０、音声管理部１７０との間で、表示情報や操作情報や音声情報の入出力を行う。
【００２２】
走行規制機能を行うため、ネイティブアプリ実行部２３２、ブラウザ２３４、携帯電話クライアント２３６は、それぞれアプリケーション固有の規制ルールであるネイティブアプリ規制ルール２２２、ブラウザ規制ルール２２４、携帯電話クライアント規制ルール２２６を保持する。以下、これらの固有の規制ルールをアプリ別規制ルールと呼ぶ。一方アプリ制御部２３０は、アプリ実行方式とは関係なく適用する共通の規制ルールであるアプリ共通規制ルール２２０を保持する。このように本実施例では、アプリ別規制ルールとアプリ共通規制ルールを備え、入力するアプリケーションに応じて適切な規制ルールを適用して走行規制を行う。
【００２３】
図３は、アプリ制御部２３０の内部構成を示す図である。アプリ制御部２３０は、アプリ入出力部３１０とアプリ制御部規制部３００を有する。
アプリ入出力部３１０は、ネイティブアプリ実行部２３２、ブラウザ２３４、携帯電話クライアント２３６から入力した様々な情報を、表示管理部１５０、操作管理部１６０、音声管理部１７０に出力する。また、操作管理部１６０や音声管理部１７から入力した情報を、操作管理部１６０や音声管理部１７０が指定するアプリケーション実行方式、即ちネイティブアプリ実行部２３２、ブラウザ２３４、携帯電話クライアント２３６のいずれかに出力する。
【００２４】
アプリ制御部規制部３００は、アプリ入出力部３１０と、表示管理部１５０、操作管理部１６０、音声管理部１７０の間で入出力する情報を、走行状態判定部１１０の判定結果に応じて規制する。特に、アプリケーションの規制ＩＤが“０２”の場合には、アプリ共通規制ルール２２０を適用し、アプリケーションとは無関係に共通の走行規制を実行する。
【００２５】
図４は、ネイティブアプリ実行部２３２の内部構成を示す図である。ネイティブアプリ制御部３３０は、車載端末１０に搭載されたＯＳ（Operating System）上で動作するアプリケーションを実行する機能である。ネイティブアプリ規制部３２０は、走行状態判定部１１０の情報およびネイティブアプリ規制ルール２２２に従い、アプリケーション固有の走行規制を実行する。
【００２６】
図５は、ブラウザ２３４の内部構成を示す図である。ブラウザ制御部３５０は、サーバ４０やインターネットから取得したＨＴＭＬ（Hyper Text Markup Language）やＸＭＬ（Extensible Markup Language）で記述される、ＷｅｂページやＷｅｂアプリケーション、画像、動画、音声等の情報を閲覧、操作するための機能である。ブラウザ規制部３４０は、走行状態判定部１１０の情報およびブラウザ規制ルール２２４に従い、アプリケーション固有の走行規制を実行する。
【００２７】
図６は、携帯電話クライアント２３６の内部構成を示す図である。携帯電話クライアント制御部３７０は、携帯電話３０で実行中のアプリケーションを、ＨＤＭＩやＭｉｒｒｏｒＬｉｎｋ等を介して車載端末１０に表示するとともに、車載端末１０で表示している携帯電話３０で実行中のアプリケーションに対して車載端末１０から操作情報を提供する機能である。携帯電話クライアント規制部３６０は、走行状態判定部１１０の情報および携帯電話クライアント規制ルール２２６に従い、アプリケーション固有の走行規制を実行する。
【００２８】
以下、各アプリケーションを実行する際、どのような走行規制を適用するかを説明する。走行規制の判定は、アプリ実行方式選択部２１０や規制パターン判定部２１２が、規制パターン格納部２１４やアプリ管理ＤＢ２１８を参照して決定する。
【００２９】
図７は、規制パターン格納部２１４の格納データを示す図である。規制ＩＤ４００は、走行規制のパターンを示す識別子であり、“０１”〜“０３”の３通り設定している。規制要否４０１は、アプリケーションに対して走行規制が必要か不要かの設定値である。走行中使用可否４０２は、アプリケーションが走行中に使用可能か使用不可かの設定値である。適用する規制ルール４０３は、アプリ共通規制ルールを適用するか、アプリ別規制ルールを適用するかの設定値である。
【００３０】
規制ＩＤが“０１”の場合、走行規制は不要である。規制ＩＤが“０２”の場合、規制が必要で走行中に使用不可であり、アプリ共通規制ルールを適用する。規制ＩＤが“０３”の場合、規制が必要であるが走行中に使用可能であり、アプリ別規制ルールを適用する。
【００３１】
図８は、アプリ管理ＤＢ２１８の格納データを示す図である。アプリＩＤ４１０はアプリケーションの識別子である。アプリ実行方式４１１は、アプリケーションが実行される方式を示し、本実施例では、ネイティブアプリ実行部２３２、ブラウザ２３４、携帯電話クライアント２３６の３方式に区分される。バージョン４１２はアプリケーションのバージョンを示す。作成者４１３はアプリケーションの作成者を示す。最終実行日４１４はアプリケーションの最終実行日を示す。規制ＩＤ４１５は、アプリケーション実行時の規制パターン（規制ＩＤ）を示し、図７の規制パターン格納部２１４に格納される規制ＩＤ４００の識別子に対応する。アプリ別規制ルール格納先４１６は、アプリケーション毎に有する固有の走行規制ルールの格納先（不揮発性メモリ１４６内のアドレス）を示す。
【００３２】
図７と図８を参照することで、実行しようとするアプリケーションに対するアプリ実行方式、走行規制のパターン、および適用する規制ルールを判定する。以下、規制ルール（アプリ共通規制ルール、アプリ別規制ルール）の具体例を説明する。
【００３３】
図９は、アプリ共通規制ルール２２０の例を示す図である。これは、規制ＩＤが“０２”、即ち起動したアプリケーションが走行中使用不可の場合、アプリ制御部２３０のアプリ制御部規制部３００が適用する。規制対象５００は、規制する対象が表示（表示管理部１５０）、操作（操作管理部１６０）、音声（音声管理部１７０）のいずれであるかを示す。規制機能５０１は規制を実施する機能を、規制内容５０２は走行規制の実施形態を示す。
【００３４】
例えば、規制対象５００が“表示”、規制機能５０１が“画面マスク”、規制内容５０２が“走行中マスク画像．ｂｍｐ”の場合、アプリ入出力部３１０は表示管理部１５０に対して、走行中はアプリ実行方式から受信した画像ではなく、走行中マスク画像．ｂｍｐを出力する。また、規制対象５００が“操作”、規制機能５０１が“タッチパネル”、規制内容５０２が“無効”の場合、アプリ入出力部３１０はアプリ実行方式に対して、操作管理部１６０から受信したタッチパネルの操作情報を送信せずに破棄する。このようにアプリ共通規制ルール２２０では、アプリケーションの実質的な機能を全て無効とし、走行時のユーザの安全性を確保するものである。
【００３５】
図１０は、ネイティブアプリ規制ルール２２２の例を示す図である。これは、規制ＩＤが“０３”、即ち起動したアプリケーションが走行中使用可能の場合に、ネイティブアプリ実行部２３２にて適用する。対象オブジェクト５２０は、規制対象となるネイティブアプリ実行部２３２が提供するアプリケーションの機能である。規制内容５２１は、対象オブジェクト５２０に対する走行規制の実施形態を示す。例えば、対象オブジェクト５２０が“文字入力”で規制内容５２１が“無効”である場合、走行中には文字入力の機能を無効化する。
【００３６】
図１１は、ブラウザ規制ルール２２４の例を示す図である。また図１２は、携帯電話クライアント規制ルール２２６の例を示す図である。これらは、規制ＩＤが“０３”であり、起動したアプリケーションが走行中使用可能の場合に、ブラウザ２３４および携帯電話クライアント２３６が適用する。これらの具体的内容の説明は省略する。
【００３７】
図１０〜図１２に示されるアプリ別規制ルール（ネイティブアプリ規制ルール２２２、ブラウザ規制ルール２２４、携帯電話クライアント規制ルール２２６）では、アプリケーションの有する一部の機能が無効になっている。なお、各アプリケーションの実行方式が異なるため、走行規制の対象や規制内容が異なっている。
【００３８】
図１３は、実施例１における走行規制設定の手順を示すフローチャートである。アプリ実行方式選択部２１０は、アプリケーションの起動開始時に走行規制が必要であるか否か、また走行規制でどの規制ルールを適用するかを決定する。
【００３９】
アプリ実行方式選択部２１０は、アプリケーションが起動されるのを待ち（Ｓ６００）、アプリケーションが起動されると、アプリケーションに付加されたアプリＩＤを取得する（Ｓ６０１）。次に、アプリ管理ＤＢ２１８（図８）を参照し、アプリＩＤ４１０に対応するアプリ実行方式４１１と規制ＩＤ４１５を取得する（Ｓ６０２）。また、規制パターン格納部２１４（図７）を参照し、規制ＩＤがどの規制パターンに該当するかを確認する（Ｓ６０３）。
【００４０】
次に、取得した規制ＩＤは規制が必要かどうかを判定する（Ｓ６０４）。規制ＩＤが“０１”であれば規制が不要であり（Ｓ６０７）、起動したアプリケーションは規制なしで実行する。規制ＩＤが“０２”または“０３”であれば規制が必要であり、走行中使用可能かどうかを判定する（Ｓ６０５）。規制ＩＤが“０３”であれば走行中使用可能なアプリケーションであり、アプリ別規制ルールに基づく走行規制を適用する（Ｓ６０６）。規制ＩＤが“０２”であれば走行中使用不可のアプリケーションであり、アプリＩＤ４１０とアプリ別規制ルール格納先４１６をアプリ制御部２３０に送信する（Ｓ６０８）。アプリ制御部２３０はアプリ共通規制ルール２２０に基づく走行規制を適用する（Ｓ６０９）。現在のアプリケーションが終了したら、次のアプリケーションが起動されるのを待つ（Ｓ６１０）。
【００４１】
図１４は、走行規制処理のシーケンスを示す図であり、ここでは規制ＩＤが“０２”でアプリ共通規制ルール２２０を適用する場合（図１３のＳ６０９の場合）について示す。また、起動したアプリケーションは、アプリ管理ＤＢ２１８（図８）のアプリＩＤ“００２”とする。
【００４２】
アプリ実行方式選択部２１０はアプリ制御部２３０に対して、規制ＩＤ（“０２”）、アプリＩＤ（“００２”）およびアプリ別規制ルール格納先（“１ＡＡＡ”）を送信する（Ｓ７０１）。アプリ制御部２３０内のアプリ制御部規制部３００は、受信した規制ＩＤが“０２”であることから、アプリ共通規制ルール２２０（図９）を取得する（Ｓ７０２）。続いて、アプリＩＤが“００２”のアプリケーションに対する規制の準備を行い、準備を完了するとアプリ実行方式選択部２１０に通知する（Ｓ７０３）。
【００４３】
アプリ実行方式選択部２１０は、アプリ制御部規制部３００から規制準備完了の通知を受信すると、アプリＩＤ“００２”のアプリ実行方式である携帯電話クライアント２３６に対してアプリケーションを送信する（Ｓ７０４）。携帯電話クライアント２３６は、アプリＩＤ“００２”のアプリケーションの実行を開始する（Ｓ７０５）。
【００４４】
走行状態が停止中の場合（Ｓ７０６）、携帯電話クライアント２３６とアプリ入出力部３１０の間で、走行規制がない状態で、画面の表示（Ｓ７０７、Ｓ７０８）やユーザによる入力操作（Ｓ７０９、Ｓ７１０）が実行される。そのときアプリ制御部規制部３００は、携帯電話クライアント２３６上で動作するアプリケーションの実行に介在しない。
【００４５】
走行状態が停止中から走行中に切り替わると（Ｓ７１１）、アプリ制御部規制部３００はアプリ入出力部３１０に対して、Ｓ７０２で取得したアプリ共通規制ルールを設定する（Ｓ７１２）。以降、アプリ入出力部３１０はアプリ共通規制ルールに基づき、走行中の画面表示（Ｓ７１３、Ｓ７１４）やユーザからの入力操作（Ｓ７１５、Ｓ７１６）を規制する。
【００４６】
走行状態が走行中から停止中に切り替わると（Ｓ７１７）、アプリ制御部規制部３００は、アプリ入出力部３１０に対し設定したアプリ共通規制ルールを解除する（Ｓ７１８）。
このようにしてアプリ制御部規制部３００は、走行状態の変化に応じて、前記規制ルールの設定（Ｓ７１２）と規制ルールの解除（Ｓ７１８）を繰り返す。
【００４７】
実施例１によれば、アプリ実行方式単位でそれぞれ個別に走行規制するためのアプリ別規制ルールと、アプリ実行方式とは関係なく共通の走行規制を行うためのアプリ共通規制ルールを保持し、アプリケーションごとに予め定めた規制パターンにより、いずれの規制ルールを適用するかを決定する。よって、多様化するアプリケーションの実行方式に対応し適切に走行規制機能を提供することができる。
【実施例２】
【００４８】
実施例２は、実施例１の構成に規制ルールを更新するための機能を追加したものである。
図１５は、実施例２にかかる車載端末の構成を示す図で、アプリ実行部１００の内部構成を示す。実施例１（図１、図２）の構成に対し、アプリ実行部１００内に規制ルール更新部２４０を追加し、外部には規制ルール配信サーバ５０を接続している。規制ルール更新部２４０は、移動体通信部１４２や無線ＬＡＮ１４４を介して外部の規制ルール配信サーバ５０に接続する。規制ルールの更新がある場合には、規制ルール配信サーバ５０から新たな規制ルールを取得する。取得した規制ルールの種別に応じて、アプリ共通規制ルール２２０、ネイティブアプリ規制ルール２２２、ブラウザ規制ルール２２４、携帯電話クライアント規制ルール２２６に保存する。
【００４９】
図１６は、実施例２におけるアプリ管理ＤＢ２１８の格納データを示す図である。規制ルールの更新に対応するために、アプリ別規制ルールバージョン４１７の項目を追加している。規制ルール配信サーバ５０に現在のアプリ別規制ルールバージョン４１７よりも新しいバージョンが存在する場合は、規制ルールの更新があるとみなして規制ルールの更新を行う。
【００５０】
図１７は、規制ルールの更新処理の手順を示すフローチャートである。規制ルール更新部２４０は、規制ルール配信サーバ５０に接続可能か否かを確認する（Ｓ７０１）。規制ルール配信サーバ５０に接続できたら、規制ルール配信サーバ５０に対して規制ルールの更新有無の確認を要求する（Ｓ７０２）。この時規制ルール更新部２４０は、確認のためにアプリ管理ＤＢ２１８のデータリスト（アプリＩＤ４１０、バージョン４１２、規制ＩＤ４１５、アプリ別規制ルールバージョン４１７）を送信する。規制ルール配信サーバ５０は、規制ルールの更新有無の確認要求を受信すると、アプリＩＤとバージョンの対に対して、規制ＩＤおよびアプリ別規制ルールバージョンが一致するか否かで更新有無を判定する（Ｓ７０３）。規制ＩＤとアプリ別規制ルールバージョンがともに一致する場合は、更新なしと判定して処理を終了する。規制ＩＤが一致しない場合は、規制内容が変更され規制ルールが更新されたと判定する。またアプリ別規制ルールバージョン４１７に新しいバージョンが存在する場合も、規制ルールが更新されたと判定する（Ｓ７０４）。
【００５１】
更新ありの場合、規制ルール配信サーバ５０は更新された規制ルールを送信し、規制ルール更新部２４０はこれを取得する。なお、規制ＩＤが変更された場合には、新たな規制ＩＤも送信しこれを取得する（Ｓ７０５）。規制ルール更新部２４０は、取得した規制ＩＤと規制ルールを所定の位置に保存し（Ｓ７０６）、アプリ管理ＤＢ２１８の該当するアプリＩＤ４１０のアプリ別規制ルールバージョン４１７を書換える。さらに規制ＩＤが変更された場合には規制ＩＤ４１５を、アプリ別規制ルール格納先が変更された場合にはアプリ別規制ルール格納先４１６も合わせて書換える（Ｓ７０７）。以上により、アプリ別規制ルールの更新や変更に対応する。
【００５２】
実施例２によれば、最新の規制ルールを随時取得して更新することで、走行規制機能の信頼性と安全性を維持することができる。
【実施例３】
【００５３】
実施例３は、起動したアプリケーションに対する管理情報がアプリ管理ＤＢ２１８に存在せず、また実施例２における規制ルール配信サーバ５０から当該アプリケーションに対する規制ルールを取得できない場合を想定する。この場合には、当該アプリケーションに適用する走行規制が定められていないので、安全性を考慮し、走行規制が必要でかつ走行中使用不可なアプリケーションとみなして、規制ＩＤが“０２”に対応するアプリ共通規制ルール２２０を適用する。
【００５４】
図１８は、実施例３における規制ルールの適用処理の手順を示すフローチャートである。
アプリ実行方式選択部２１０は、起動したアプリケーションのアプリＩＤでアプリ管理ＤＢ２１８を検索し、該当するアプリＩＤが存在しない場合（Ｓ８０１）、規制ルール配信サーバ５０に接続可能か否かを確認する（Ｓ８０２）。規制ルール配信サーバ５０に接続できない場合は、規制必要でかつ走行中使用不可なアプリケーションとみなして、規制ＩＤが“０２”でアプリ共通規制ルール２２０に基づく走行規制を適用する（Ｓ８０３）。
【００５５】
規制ルール配信サーバ５０に接続可能であれば、該当するアプリＩＤのアプリ管理情報とアプリ別規制ルールを取得する（Ｓ８０４、Ｓ８０５）。取得した規制ルールを所定の格納部に保存し（Ｓ８０６）、アプリ管理ＤＢ２１８にアプリ管理情報を追加する（Ｓ８０７）。以降、取得したアプリ管理情報を参照し、図１３の手順に従って走行規制を適用する。
【００５６】
実施例３によれば、実行しようとするアプリケーションの管理情報がアプリ管理ＤＢ２１８に事前に登録されていない場合でも、安全で適切な走行規制を提供することができる。
【実施例４】
【００５７】
実施例４は、アプリケーション自身がアプリ別規制ルールを内蔵している場合の走行規制の実現方法について述べる。
図１９は、実施例４にかかる車載端末の構成を示す図である。この例では、携帯電話３０で実行されるアプリケーションである携帯電話アプリ（携帯アプリ）３１は、アプリ別規制ルールであるアプリ内蔵規制ルール３２を内蔵している。車載端末１０のアプリ実行部１００において、携帯電話クライアント２３６は携帯電話３０の携帯アプリ３１を実行する。一方ブラウザ２３４は、携帯アプリ３１に内蔵されたアプリ内蔵規制ルール３２に基づく規制用のアプリケーション（規制アプリ３３）を並行して実行する。このように、携帯アプリ３１と規制アプリ３３の実行方式を分離することで、走行状態に応じた規制の切り替えが容易で規制ルールの変更に柔軟に対応できる。
【００５８】
図２０は、規制アプリ３３を使用した走行規制の適用画面の例である。携帯アプリ３１として音楽再生アプリを例とする。携帯電話クライアント２３６は、携帯アプリ３１から得た携帯アプリ画面１０１０をアプリ制御部２３０に出力する。一方ブラウザ２３４は、アプリ内蔵規制ルール３２に基づき規制アプリ３３にて生成した規制アプリ画面１０２０をアプリ制御部２３０に出力する。規制アプリ画面１０２０は、携帯アプリ画面１０１０の画像を透過するが操作不可能な領域１０２１と、携帯アプリ画面１０１０の画像をマスクし異なる操作画面を表示してタッチパネル等により操作可能な領域１０２２とで構成される。
【００５９】
アプリ制御部２３０は、携帯電話クライアント２３６からの携帯アプリ画面１０１０と、ブラウザ２３４からの規制アプリ画面１０２０を受け取り、走行状態に応じて表示を切り替える。車両が停止中の表示画面１０３０は、携帯アプリ画面１０１０をそのまま表示する。一方車両が走行中の表示画面１０４０は、携帯アプリ画面１０１０の上に規制アプリ画面１０２０を重ね合わせた合成画面を表示する。その結果走行中表示画面１０４０は、携帯アプリ画面１０１０の画像が表示されるが操作できない領域１０１１と、新たなタッチパネルが表示され操作可能な領域１０２２とで構成される。
【００６０】
この例では、規制アプリ３３により、走行中には視認性が高く操作が容易であるタッチパネル、即ち大きなソフトウェアボタン（“前”、“停止”、“次”）に切り替えることにより、運転中のユーザ操作に関し利便性と安全性の両立を図ることができる。
【００６１】
図２１は、実施例４における規制パターン格納部２１４の格納データを示す図である。規制パターン格納部２１４には、アプリケーション自身が内蔵しているアプリ別規制ルールを使用する場合を追加している。即ち規制ＩＤ４００として“０４”を追加し、規制要否４０１は“必要”、走行中使用可否４０２は“可能”、適用する規制ルール４０３は“規制アプリ使用”と設定する。
【００６２】
図２２は、実施例４におけるアプリ管理ＤＢ２１８の格納データを示す図である。例えばアプリＩＤ４１０が“００２”のアプリケーションは、その規制ＩＤ４１５が“０４”であることから、アプリケーション自身がアプリ別規制ルールを内蔵していることを示す。
【００６３】
図２３は、アプリ内蔵規制ルール３２を用いた走行規制処理のシーケンスを示す図である。ここでは図１９のように、携帯電話３０の携帯アプリ３１がアプリ内蔵規制ルール３２を内蔵し、これを使用するものとする。
【００６４】
携帯電話３０は携帯アプリ３１を起動し（Ｓ９０１）、アプリＩＤとアプリ内蔵規制ルール３２を車載端末１０に送信する（Ｓ９０２）。車載端末１０のアプリ実行方式選択部２１０は、取得したアプリＩＤを用いてアプリ管理ＤＢ２１８を確認し、規制ＩＤが“０４”、即ちアプリ内蔵規制ルール３２を用いた走行規制を行うことを決定する（Ｓ９０３）。続いて、アプリ制御部２３０に対して規制ＩＤ“０４”とアプリ内蔵規制ルール３２を送信する（Ｓ９０４）。
【００６５】
アプリ制御部２３０は規制ＩＤ“０４”を受信すると、ブラウザ２３４に対し規制アプリ３３を起動させアプリ内蔵規制ルール３２を送信する（Ｓ９０５）。ブラウザ２３４は受信したアプリ内蔵規制ルール３２に基づき規制アプリ３３を実行し（Ｓ９０６）、生成した規制アプリ画面１０２０をアプリ制御部２３０に出力する（Ｓ９０７）。
【００６６】
一方アプリ実行方式選択部２１０は、携帯電話３０に対して画面の出力を要求し（Ｓ９０８）、携帯電話３０は画面を出力し（Ｓ９０９）、アプリ実行方式選択部２１０を経由して携帯電話クライアント２３６に送信する（Ｓ９１０）。携帯電話クライアント２３６は携帯アプリ画面１０１０としてアプリ制御部２３０に送信し（Ｓ９１１）、アプリ制御部２３０はこれを表示管理部１５０に表示させる（Ｓ９１２）。
【００６７】
走行状態が停止中の場合は走行規制が適用されず、アプリ制御部２３０は携帯電話クライアント２３６が提供する機能をそのまま有効とし、停止中表示画面１０３０を表示する。またユーザによる操作情報は、携帯電話クライアント２３６を経由して携帯電話３０に送信される（Ｓ９１３、Ｓ９１４）。
【００６８】
走行状態が停止中から走行中に切り替わると、アプリ制御部２３０は、携帯アプリ画面１０１０と規制アプリ画面１０２０を重ね合わせて合成した走行中表示画面１０４０を表示する（Ｓ９１５）。走行中に操作可能な領域は１０２２の領域のみで、ここは規制アプリ３３が動作するブラウザ２３４が管理する領域である。よってユーザによる操作は、ブラウザ２３４を経由して携帯電話３０に送信される（Ｓ９１６、Ｓ９１７）。さらに、図２０の音楽再生アプリの例では、ユーザにより領域１０２２の“停止”ボタンが押されたら、“停止”ボタンの箇所を“再生”ボタンに切り替えてユーザの次の操作を待つようにする。その場合、ブラウザ２３４の規制アプリ３３はソフトウェアボタンの内容を更新して出力し、領域１０２２の表示を更新する（Ｓ９１８、Ｓ９１９）。
【００６９】
走行中から停止中に切り替わると、携帯電話クライアント２３６単独の処理に戻り、停止中表示画面１０３０に切り替える（Ｓ９２０）。そして、ユーザによる操作情報は、携帯電話クライアント２３６を経由して携帯電話３０に送信される（Ｓ９２１、Ｓ９２２）。このように、走行状態の変化に対応して上記処理を繰り返す（Ｓ９１５〜Ｓ９２０）。
【００７０】
実施例４によれば、アプリケーション自身が走行規制ルールを内蔵している場合にも、内蔵する規制ルールを分離し車載端末内で規制アプリとして並行して実行することで、アプリケーション本体の負担を軽減し、かつ所望の走行規制機能を簡単に実現することができる。
【００７１】
なお、本実施例では、アプリ内蔵規制ルール３２は、携帯電話３０で実行される携帯アプリ３１に内蔵される場合を説明したが、ブラウザ２３４やネイティブアプリ実行部２３２で実行されるアプリケーションプログラムに内蔵される場合でも同様である。また、規制アプリ３３をブラウザ２３４で実行したが、ネイティブアプリ実行部２３２で実行してもよい。
【００７２】
実施例４の変形例として、走行中に規制アプリの表示内容を更新するとき、ブラウザ２３４の代わりに携帯電話３０が指定する内容に更新することも可能である。
図２４は、走行中の規制アプリの表示内容を携帯電話３０により更新する処理のシーケンスであり、図２３のシーケンスに対し処理Ｓ９３０を追加している。走行中に操作情報が携帯電話３０に送信されると（Ｓ９１７）、携帯電話３０は規制アプリ３３に対するレスポンスとして、規制アプリ３３の内容を更新して送信する（Ｓ９３０）。ブラウザ２３４は更新された規制アプリの内容をアプリ制御部２３０に出力し（Ｓ９１８）、更新された表示画面が表示される（Ｓ９１９）。このように携帯電話３０から規制アプリの更新内容を指定することで、走行状態に応じてより適切な制御を行うことができる。
【実施例５】
【００７３】
実施例５は、車載端末を携帯電話の基本構成を含む情報処理装置により実現する場合である。携帯電話などの情報処理装置は、各種アプリケーションを実行可能であるとともにサーバなどの外部情報機器とも通信可能であるから、これに車両の走行状態判定機能等を付加することで、カーナビゲーション機能を有する車載端末として使用することができる。
【００７４】
図２５は、実施例５にかかる情報処理装置の構成を示す図であり、携帯電話６０を用いて走行規制する場合を示す。
本実施例の携帯電話６０は、機器間通信部１４０により車両２０の車両機器間通信部２５と接続する。携帯電話６０のＣＡＮ情報取得部１２２は、車両２０のＣＡＮ２１からの情報を取得し、携帯電話６０の車両信号取得部１２４は、車両２０の車速パルス２２、パーキングブレーキ２３、バック信号２４からの情報を取得する。携帯電話センサ１２８は、ＧＰＳやジャイロスコープ、加速度センサ等の携帯電話６０に具備されるセンサである。走行状態判定部１１０は、ＣＡＮ情報取得部１２２、車両信号取得部１２４、および携帯電話センサ１２８から情報を取得し、車両の走行状態の判定を行う。
【００７５】
携帯電話６０の行う走行規制機能は前記実施例１〜４と同様であり、説明を省略する。本実施例では、携帯電話６０などの情報処理装置を用いて走行規制機能を提供できるので、携帯電話６０本来の機能と走行規制機能を一体化してより効率的に処理できるメリットがある。
【符号の説明】
【００７６】
１０…車載端末、２０…車両、３０…携帯電話、３１…携帯電話アプリ、３２…アプリ内蔵規制ルール、３３…規制アプリ、４０…サーバ、５０…規制ルール配信サーバ、６０…情報処理装置（携帯電話）、１００…アプリ実行部、１１０…走行状態判定部、１４０…機器間通信部、１４２…移動体通信部、１４４…無線ＬＡＮ、１５０…表示管理部、１６０…操作管理部、１７０…音声管理部、２１０…アプリ実行方式選択部、２１２…規制パターン判定部、２１４…規制パターン格納部、２１８…アプリ管理ＤＢ、２２０…アプリ共通規制ルール、２２２…ネイティブアプリ規制ルール、２２４…ブラウザ規制ルール、２２６…携帯電話クライアント規制ルール、２３０…アプリ制御部、２３２…ネイティブアプリ実行部、２３４…ブラウザ、２３６…携帯電話クライアント、２４０…規制ルール更新部、３００…アプリ制御部規制部、３１０…アプリ入出力部、４００，４１５…規制ＩＤ、４１０…アプリＩＤ、１０１０…携帯アプリ画面、１０２０…規制アプリ画面、１０３０…停止中表示画面、１０４０…走行中表示画面。
【図１】
2015014956.tif 000003
【図２】
2015014956.tif 000004
【図３】
2015014956.tif 000005
【図４】
2015014956.tif 000006
【図５】
2015014956.tif 000007
【図６】
2015014956.tif 000008
【図７】
2015014956.tif 000009
【図８】
2015014956.tif 000010
【図９】
2015014956.tif 000011
【図１０】
2015014956.tif 000012
【図１１】
2015014956.tif 000013
【図１２】
2015014956.tif 000014
【図１３】
2015014956.tif 000015
【図１４】
2015014956.tif 000016
【図１５】
2015014956.tif 000017
【図１６】
2015014956.tif 000018
【図１７】
2015014956.tif 000019
【図１８】
2015014956.tif 000020
【図１９】
2015014956.tif 000021
【図２０】
2015014956.tif 000022
【図２１】
2015014956.tif 000023
【図２２】
2015014956.tif 000024
【図２３】
2015014956.tif 000025
【図２４】
2015014956.tif 000026
【図２５】
2015014956.tif 000027