JP7208866B2 - コンテントの提示制御装置、提示制御方法及び提示制御プログラム - Google Patents

Description

本発明は、コンテントの提示制御装置、提示制御方法及び提示制御プログラムに関する。

例えば車両に設置されている表示装置に表示されるコンテントや音声出力装置から音声出力されるコンテントは多岐にわたる。この種のコンテントとしては、車両走行に関係する走行系のコンテント、車両走行に関係しない非走行系のコンテント等がある。走行系のコンテントとしては、例えば車速、エンジン回転数、シフトポジション、燃料の残量等が挙げられる。非走行系のコンテントとしては、例えばナビゲーション用の地図情報、オーディオ情報、電話情報等が挙げられる。

コンテントは、アプリケーションからコンテントの提示要求が発生することに応じて提示される。即ち、表示コンテントは、アプリケーションから表示要求が発生することに応じて表示され、音声出力コンテントは、アプリケーションから音声出力要求が発生することに応じて音声出力される。この場合、一のアプリケーションのコンテントを提示中に他のアプリケーションからコンテントの提示要求が発生すると、何れのコンテントを優先して提示するかの調停を行う。例えば特許文献１には、何れのコンテントを優先して提示するかの調停を行う手法が開示されている。

特許第５７４２７９９号公報

コンテントの提示制御装置では、コンテントの提示中に外部装置から提示停止指令を受信すると、コンテントの提示を停止する。例えばコンテントの提示制御装置がマルチメディア機器（以下、ＭＭ機器と称する）であり、外部装置がメータ機器である場合に、メータ機器は、警報音声出力のコンテントの提示要求が発生すると、コンテントの提示停止指令をＭＭ機器に送信する。ＭＭ機器は、コンテントの提示中にメータ機器から提示停止指令を受信すると、メータ機器がどのような理由で提示停止指令を送信したかに拘らず、又、自己がどのような状態であるかに拘らず、コンテントの提示を停止する。

しかしながら、このようにコンテントの提示制御装置がコンテントの提示を一律的に停止する構成では、コンテントの提示制御装置と外部機器とを含むシステム全体の中で優先度が他よりも高いコンテントを提示せず、優先度が他よりも低いコンテントを優先して提示してしまうことが懸念される。

本発明は、上記した事情に鑑みてなされたもので、その目的は、コンテントの提示制御装置と外部機器とを含むシステム全体の中で優先度が他よりも高いコンテントを適切に優先して提示することができるコンテントの提示制御装置、提示制御方法及び提示制御プログラムを提供することにある。

請求項１に記載した発明によれば、アプリケーション記憶部（１５）は、コンテントの提示要求を発生するアプリケーションを記憶可能である。ルール定義記憶部（１７）は、制約式を含むルール定義を記憶する。状態取得部（１８）は、外部機器の状態を取得する。調停部（１９）は、アプリケーションからのコンテントの提示要求と、状態取得部により取得された外部機器の状態とについて、ルール定義記憶部に記憶されているルール定義に基づいて何れのコンテントを優先して提示するかの調停を行う。提示制御部（２０）は、調停部が行った調停結果にしたがってコンテントの提示を制御する。

アプリケーションからのコンテントの提示要求と、外部機器の状態とについて、ルール定義に基づいて何れのコンテントを優先して提示するかの調停を行うようにした。何れのコンテントを優先して提示するかの調停を自己だけで行うのではなく、自己と外部機器とが連携して両者の間で跨って行うことで、コンテントの提示制御装置と外部機器とを含むシステム全体の中で優先度が他よりも高いコンテントを適切に優先して提示することができる。

一実施形態における提示制御システムの構成を示す機能ブロック図 優先度調停を示す図 後勝ち調停を示す図 エリアのＺオーダーと優先度との関係を示す図 コンテントと状態とエリアの関係性を示す図 述語論理式の構文を示す図 調停ロジックの全体処理を示すフローチャート 制御実行処理を示すフローチャート プロパティを定義しない場合の通信インタフェースを示す図 プロパティを定義する場合の通信インタフェースを示す図 プロパティを定義しない場合のルール定義を示す図 プロパティを定義する場合のルール定義を示す図 プロパティを定義しない場合の信号を送受信する態様を示す図 プロパティを定義する場合の信号を送受信する態様を示す図

以下、一実施形態について図面を参照して説明する。図１に示すように、提示制御システム１は、マルチメディア機器（以下、ＭＭ機器）１１（コンテントの提示制御装置に相当する）と、メータ機器２１（外部機器に相当する）とが車載ネットワーク３１を介してデータ通信可能に接続されて構成されている。車載ネットワーク３１は、例えばＣＡＮ（Controller Area Network、登録商標）等である。ＭＭ機器１１及びメータ機器２１は、車載ネットワーク３１を介して各種ＥＣＵ３２、各種センサ３３、各種スイッチ３４、自動運転制御装置３５等と接続されている。

マルチメディア機器１１には、第１表示装置１２と第１音声出力装置１３とが接続されている。第１表示装置１２は、例えばフルカラーの液晶表示装置から構成されるディスプレイであり、基本的に車両走行に関係しない非走行系のコンテントを表示する表示部として機能する。非走行系のコンテントは、例えばナビゲーション用の地図情報、オーディオ情報、電話情報等である。第１音声出力装置１３は、一又は複数のスピーカーから構成され、非走行系のコンテントを音声出力する音声出力部として機能する。メータ機器２１には、第２表示装置２２と第２音声出力装置２３とが接続されている。第２表示装置２２は、例えばフルカラーの液晶表示装置から構成されるディスプレイであり、基本的に車両走行に関係する走行系のコンテントを表示する表示部として機能する。走行系のコンテントは、例えば車速、エンジン回転数、シフトポジション、燃料の残量等である。第２音声出力装置２３は、一又は複数のスピーカーから構成され、走行系のコンテントを音声出力する音声出力部として機能する。各表示装置１２，２２にコンテントが表示され、各音声出力装置１３，２３からコンテントが音声出力されることで、走行系のコンテントや非走行系のコンテントから構成される各種情報が乗員に提供される。

ＭＭ機器１１は、制御部１４と、アプリケーション記憶部１５と、入出力Ｉ／Ｆ１６とを有する。アプリケーション記憶部１５には複数のアプリケーションＡ，Ｂが予め記憶されている。各アプリケーションＡ，Ｂは、一又は複数のコンテントの提示要求が発生すると、提示対象、エリアやゾーン及びコンテントを示す提示要求を制御部１４に割り込み出力する。即ち、各アプリケーションＡ，Ｂは、第１表示装置１２へのコンテントの表示要求が発生すると、表示対象、エリア及びコンテントを示す提示要求を制御部１４に割り込み出力する。エリアとは、コンテントを表示する際に割り当てる領域である。又、各アプリケーションＡ，Ｂは、第１音声出力装置１３へのコンテントの音声出力要求が発生すると、音声出力対象、ゾーン及びコンテントを示す提示要求を制御部１４に割り込み出力する。ゾーンとは、コンテントを音声出力する際に割り当てる領域である。

制御部１４は、ＣＰＵ（Central Processing Unit）、ＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）、Ｉ／Ｏ（Input／Output）等を含むマイクロコンピュータを有し、非遷移的実体的記憶媒体に格納されている提示制御プログラムを実行し、ＭＭ機器１１の動作を制御する。制御部１４は、ルール定義記憶部１７と、状態取得部１８と、調停部１９と、提示制御部２０とを有する。

ルール定義記憶部１７にはルール定義が記憶されている。ルール定義は、コンテントをエリアやゾーンに割り当てる場合の基本的な調停を定義した調停ポリシーと、制約式とを含んで構成されている。調停ポリシーは、後述するように優先度調停／後勝ち調停／価値ベース調停の何れかで必ず設定される。制約式は、１つに限定されることはなく、記述者の意図に応じて設けられない場合もあるし複数設けられる場合もある。

状態取得部１８は、メータ機器２１の状態を当該メータ機器２１から車載ネットワーク３１及び入出力Ｉ／Ｆ１６を介して取得する。調停部１９は、ルール定義記憶部１７に記憶されているルール定義に基づいて提示領域に割り当てるコンテントの調停を行う。調停部１９は、複数の異なるアプリケーションが同時に提示要求を割り込み出力する場合があり、このような場合は何れのコンテントを優先して提示するかの調停を行う。ここでいう「同時」とは時間的に同時という意味ではなく、一のアプリケーションがコンテントを提示中に他のアプリケーションからコンテントの提示要求が発生した状態、即ち、２つ以上のアプリケーションが提示要求を同時に割り込み出力した状態を意味する。提示制御部２０は、コンテントの調停が調停部１９により行われると、その調停により割り当てられたコンテントを所定エリアに表示したり所定ゾーンから音声出力したりする。

メータ機器２１は、基本的にＭＭ機器１１と同等の構成であり、制御部２４と、アプリケーション記憶部２５と、入出力Ｉ／Ｆ２６とを有する。アプリケーション記憶部２５には複数のアプリケーションＸ，Ｙが予め記憶されている。各アプリケーションＸ，Ｙは、一又は複数のコンテントの提示要求が発生すると、提示対象、エリアやゾーン及びコンテントを示す提示要求を制御部２４に割り込み出力する。即ち、各アプリケーションＸ，Ｙは、第２表示装置２２へのコンテントの表示要求が発生すると、表示対象、エリア及びコンテントを示す提示要求を制御部２４に割り込み出力する。又、各アプリケーションＸ，Ｙは、第２音声出力装置２３へのコンテントの音声出力要求が発生すると、音声出力対象、ゾーン及びコンテントを示す提示要求を制御部２４に割り込み出力する。

制御部２４は、ＣＰＵ、ＲＯＭ、ＲＡＭ、Ｉ／Ｏ等を含むマイクロコンピュータを有し、非遷移的実体的記憶媒体に格納されている提示制御プログラムを実行し、メータ機器２１の動作を制御する。制御部２４は、ルール定義記憶部２７と、状態取得部２８と、調停部２９と、提示制御部３０とを有する。ルール定義記憶部２７にはルール定義が記憶されている。ルール定義は、コンテントをエリアやゾーンに割り当てる場合の基本的な調停を定義した調停ポリシーと、制約式とを含んで構成されている。調停ポリシーは、後述するように優先度調停／後勝ち調停／価値ベース調停の何れかで必ず設定される。制約式は、１つに限定されることはなく、記述者の意図に応じて設けられない場合もあるし複数設けられる場合もある。

状態取得部２８は、ＭＭ機器１１の状態を当該ＭＭ機器１１から車載ネットワーク３１及び入出力Ｉ／Ｆ２６を介して取得する。調停部２９は、ルール定義記憶部２７に記憶されているルール定義に基づいて提示領域に割り当てるコンテントの調停を行う。調停部２９は、複数の異なるアプリケーションが同時に提示要求を割り込み出力する場合があり、このような場合は何れのコンテントを優先して提示するかの調停を行う。ここでいう「同時」とは時間的に同時という意味ではなく、一のアプリケーションがコンテントを提示中に他のアプリケーションからコンテントの提示要求が発生した状態、即ち、２つ以上のアプリケーションが提示要求を同時に割り込み出力した状態を意味する。提示制御部３０は、コンテントの調停が調停部２９により行われると、その調停により割り当てられたコンテントを所定エリアに表示したり所定ゾーンから音声出力したりする。

以下、ルールベース調停について説明する。尚、ここでは、コンテントをエリアに表示する場合について説明するが、コンテントをゾーンから音声出力する場合についても基本的な考え方は同様である。
（１）ルールベース調停

ルールベース調停は、与えられた一定のルールに基づいてコンテントを調停して任意のエリアに割り当てる調停方法を記述している。ルールベース調停におけるルールの定義としては、エリア定義、コンテント定義、制約式が必要である。

（１－１）エリア定義
エリア定義では、表示場所、表示場所の価値、調停ポリシーが定義される。エリア毎に調停が行われるので、エリア毎に調停ポリシーを定義する。
エリアでは、表示装置１２，２２の表示画面にコンテントを表示させる枠を定義する。１つのエリアには１つのコンテントのみが割り当てられる。
エリアは、以下の定義とする。
・エリアは、割り当てられたコンテントを表示する。
・エリアは、調停ポリシーを持つ。
・エリアは、表示可能なコンテントを参照する。
・エリアは、１つ以上のサイズを持つ。
各エリアは、プロパティを有している。プロパティとして、優先度、Ｚオーダー、調停ポリシー、サイズが設定されている。

（ａ）優先度
優先度は、エリア自体の価値を示す値（０～１００％）である。優先度の値が大きいエリアから順に調停を行う。
（ｂ）Ｚオーダー
Ｚオーダーは、高さに関する座標である。Ｚオーダーの値が高いほど前面に表示される。優先度が同じエリアがある場合には、Ｚオーダーの値が高い順に調停を行う。

（ｃ）調停ポリシー
調停ポリシーは、優先度調停、後勝ち調停、価値ベース調停の何れかである。
（ｃ－１）優先度調停
優先度調停は、エリア単位の調停ポリシーであり、図２に示すように、エリアに表示可能なコンテントの中で最も優先度の高いコンテントを表示する調停である。
（ｃ－２）後勝ち調停
後勝ち調停は、エリア単位の調停ポリシーであり、図３に示すように、エリアで最後に要求が発生したコンテントを表示し、そのコンテントの表示が終了した場合は残っている中で最後に要求が発生したコンテントを表示する調停である。
（ｃ－３）価値ベース調停
価値ベース調停は、エリア全体での調停ポリシーであり、コンテントの価値を数値化した数値とエリアの価値を数値化した数値とを乗じた演算値が最大となるコンテントを表示する調停である。

（ｄ）サイズ
サイズは、エリアのサイズで縦×横となる。複数定義されている場合には、コンテントのサイズに応じて決定される。エリアのＺオーダーと優先度との関係は、図４に示すようになる。

（１－２）コンテント定義
コンテント定義では、表示可能エリア、コンテントの状態、コンテントの状態の価値が定義される。コンテントは、状態を複数持つことが可能であり、コンテントがエリアに割り当てられ、コンテントの状態が表示される。コンテントは、自分が表示可能なエリアを定義して参照する。
コンテントでは、表示装置１２，２２の表示画面に定義されたエリアに表示するコンテントを定義する。１つのエリアには１つのコンテントのみが割り当てられる。
コンテントは、以下の定義とする。
・コンテントは、エリアに対して割り当てられる。
・コンテントは、自らが表示可能なエリアを１つ以上参照する。
・コンテントは、必ず１つ以上の状態を持つ。
・コンテントは、１つ以上のサイズを持つ。

表示可能なエリアが複数ある場合には、何れかも表示可能であることを示し、１つのコンテントを複数エリアに同時に表示することもできる。１つのコンテントに複数の状態を持つことができ、複数持っている場合、それぞれの状態は排他的であり必ず１つの状態でしか一度に表示できない。コンテントはサイズを複数持つことができ、複数ある場合には、表示先のエリアのサイズに応じて最も近いサイズを表示させる。コンテントと状態とエリアの関係性は、図５に示すように紐づけられる。
コンテントは、プロパティを有しており、プロパティとして、優先度、サイズ、調停負けしたときに提示要求を取り下げる（キャンセルする）又は取り下げない（待機する）の何れかを示す属性が設定されている。

（ａ）優先度
優先度は、エリアの調停ポリシーが「優先度調停」の場合に使われる値であり、優先度の高いコンテントが先にエリアに割り当てられる。
（ｂ）サイズ
サイズは、コンテントの表示のサイズで縦×横となる。複数定義されていた場合は、エリアのサイズに応じて決定される。

（１－３）制約式
制約式は、調停中又は調停後において、例外的に満たすべき性質を記述したルールである。調停の状態を制約式で抑制することで、そのままの調停ポリシーでは表現しきれない状態を表したり、調停後の調停結果の判定に用いたりすることができる。即ち、例えば車両の走行状態等の状況に応じては、調停ポリシーにて割り当てられたコンテントであっても表示しない方が良い場合があるためである。制約式では、調停結果が満たすべき条件であるコンテント抑制やエリア抑制の条件が定義される。

制約式で扱える論理式は、コンテントの状態、エリアの状態、エリアに表示中のコンテント、エリアとコンテントの集合、シーンの状態、論理演算、量化記号である。シーンとは、例えば手動運転シーン又は自動運転装置３５による自動運転シーンであり、自動運転シーンでは手動運転用コンテントグループのコンテントは表示しないという表示制御が可能となる。
（ａ）コンテントの状態は、アクティブ／非アクティブ、表示中／非表示中の何れかである。
（ｂ）エリアの状態は、表示中／非表示中の何れかである。
（ｃ）論理演算は、ＮＯＴ（！）、ＡＮＤ、ＯＲ、含意（－＞）、等号（＝）である。
量化記号は、∀（Ｆｏｒ Ａｌｌ：集合の要素全てに対して条件が成立する）、∃（Ｅｘｉｓｔｓ：集合に条件を満たす要素が少なくとも一つ存在する）である。

（ｄ）制約式
制約式は、調停ロジックの結果に影響を及ぼし、調停ロジックは全ての制約を満たすように振る舞う。

（１－４）コンテント抑制
例えばコンテントｃ１の表示中はコンテントｃ２を表示しないという制約式として、「中心エリア.displaying Content()=c1 -> !c2.is Visible()」を例示する。この制約式は、中心エリアにコンテントｃ１を表示していれば、コンテントｃ２を表示しないという抑制を記述している。

（１－５）優先度調停と後勝ち調停
優先度調停と後勝ち調停とが混在する場合は、エリアの調停ポリシーを後勝ちにしておき、優先度が関わるコンテント間の関係のみを制約式で記述することで対応可能である。

このような制約式として、「電話.is Active() -> For All MM系割り込み（電話以外）{x|!x.is Visible()}」を例示する。調停ポリシーが後勝ち調停のエリアであるが、この制約式を加えることで電話という優先度の高いコンテントがアクティブであれば、全てのＭＭ系割り込み（電話以外）を表示しないという抑制を記述している。

（２）調停ロジック
調停ロジックは、与えられたルールに基づき、エリアの調停ポリシーに基づいた形で制約式を満たすようにコンテントを割り当てる方法を定義したアルゴリズムである。基本的にはエリア毎に優先度順に調停を行う。調停ロジックには、エリア内の調停とエリア全体の調停とがある。

（２－１）エリア内の調停
（ａ）エリア内の調停は、優先度調停及び後勝ち調停のエリアを優先度の高い順に調停する。
（ｂ）各エリアについて以下を評価する。
最も優先されるコンテントを仮に割り当て、制約式の評価結果が真（TRUE）であれば、仮に割り当てたコンテントを確定する。制約式の評価結果が偽（FALSE）であれば、次に優先されるコンテントを再評価する。制約式を満たすコンテントがなければ、そのエリアにはコンテントを表示しない。

（２－２）エリア全体の調停
エリア全体の調停（価値ベース調停）は、ベストフィットロジック及びワンパスロジックがある。
（ａ）ベストフィットロジックは、制約式を満たすコンテントとエリアとの全ての組み合わせの中から価値の総和が最も高いものを選択する。
（ｂ）ワンパスロジックは、優先度の高いエリアから順に優先度の高いコンテントをエリアに割り当て、既に他のエリアに割り当てられたコンテントは対象外にする。本実施形態ではワンパスロジックを採用するが、ベストフィットロジックを採用しても良い。

従来のルールベース調停では、機器内での調停を行うが、複数の機器が連携して両者の間で跨って調停を行うことはない。そのため、ＭＭ機器１１とメータ機器２１との間において、メータ機器２１は、例えば警報音声出力のコンテントの提示要求が発生すると、コンテントの提示停止指令をＭＭ機器１１に送信する。ＭＭ機器１１は、コンテントの提示中にメータ機器２１からコンテントの提示停止指令を受信すると、メータ機器１１がどのような理由で提示停止指令を送信したかに拘らず、又、自己がどのような状態であるかに拘らず、コンテントの提示を停止する。しかしながら、このような構成では、提示制御システム１のシステム全体の中で優先度が他よりも高いコンテントを提示せず、優先度が他よりも低いコンテントを優先して提示してしまうことが懸念される。このような事情から、本実施形態では、以下に示す構成を採用している。

提示制御システム１では、ＭＭ機器１１とメータ機器２１とは、図６に示すように、両者が連携して調停を行うための述語論理式の構文を用いる。「IF実行式」は、Bool式が真（TRUE）の場合にアクションを実行することを意味する。「IF-THEN-ELSE実行式」は、Bool式が真の場合にTHEN節のアクションを実行し、Bool式が偽（FALSE）の場合にELSE節のアクションを実行することを意味する。「シーンのオン」は、シーンを有効にすることを意味する。「シーンのオフ」は、シーンを無効にすることを意味する。「プロパティ値の設定」は、シーンのプロパティに値を設定することを意味する。調停部１９，２９は、調停処理で結果を確定した後に制御実行式を実行する。以下、調停部１９，２９が行う調停ロジックの全体処理及び制御実行処理について説明する。

（１）調停ロジックの全体処理
調停部１９，２９は、図７に示すように、調停ロジックの全体処理を行う。調停部１９，２９は、一のアプリケーションのコンテントを提示中に他のアプリケーションからの提示要求を受付けると、調停処理を行い、提示領域にコンテントを割り当てる（Ｓ１）。調停部１９，２９は、負け時アクション判定処理を行い、調停負けしたコンテントが待機するかキャンセルするかを決定し、要求の状態を変化させる（Ｓ２）。即ち、調停部１９，２９は、「待機」を「キャンセル」に変更する必要があるか否かを判定し、変更する必要がないと判定すると、「待機」のままとし、変更する必要があると判定すると、「待機」を「キャンセル」に変更する。調停部１９，２９は、制御実行処理を行い、制御実行式で定義された処理を実行する（Ｓ３）。

（２）制御実行処理
調停部１９，２９は、制御実行処理を行い、制御実行式があるか否かを判定する（Ｓ１１）。調停部１９，２９は、制御実行式がないと判定すると、ループ終了とする。調停部１９，２９は、制御実行式があると判定すると、制御実行式の左辺を評価し（Ｓ１２）、評価結果を判定する（Ｓ１３）。調停部１９，２９は、評価結果が「TRUE」であり、左辺を満たしたと判定すると（Ｓ１３：ＹＥＳ）、制御実行式の右辺の処理を実行する（Ｓ１４）。調停部１９，２９は、評価結果が「FALSE」であり、左辺を満たしていないと判定すると（Ｓ１３：ＮＯ）、制御実行式の右辺の処理を実行しない。調停部１９，２９は、次の制御実行式について上記した処理を繰り返す（Ｓ１５）。

ＭＭ機器１１とメータ機器２１とが連携して両者の間で跨って調停を行う場合には、シーン情報を送受信する。シーン情報はオンとオフの２つの状態を持ち、シーン情報を条件に制約式を記述して調停することができる。例えば情報の受信側は、シーン情報がオンならば自己の基本音声をアッテネートする、という制約式を記述することができる。
（例１）「プリクラッシュ警報音声が吹鳴中ならば基本音声をアッテネートする」の制約式は、
{PCS.isOn() -> Base.isAttenuated()}
となる。又、情報の送信側は、シーン情報をオンにして通知する条件を記述することができる。
（例２）「プリクラッシュ警報が出力中はプリクラッシュ警報音声がオンであることを通知する」の制約式は、
{PCS警報.isSounding() => PCS.on()}
となる。

又、シーン情報にはプロパティ情報を任意で定義することができる。プロパティ情報には名前があり、値（整数）をセットする。１つのシーンに対して複数のプロパティ情報をセットすることができる。プロパティ情報を定義することで、シーン情報の受信側は、プロパティ情報の値を閾値の条件判定に使う等してルールを抽象的に表現することができる。

シーン情報を送受信する場合には、機器間の通信インタフェースを定義する必要がある。プロパティ情報を定義しない場合は、図９に示すように、プリクラッシュ警報音声はオンかオフの２つの状態であるので、「PCS : (1bit)」という信号を定義する。同様に、クリアランスソナー警報音声はオンかオフの２つの状態であるので、「クリアランスソナー : (1bit)」という信号を定義する。一方、プロパティ情報を定義する場合は、図１０に示すように、「MET : (1 bit) risk_level : (4 bit)」という信号を定義する。この場合、メータ機器２１は、例えば「プリクラッシュ警報がオンならばrisk_levelは１０」、「クリアランスソナー警報がオンならばrisk_levelは７」をルール定義で規定する。プロパティ情報を定義することで多様なシーンを表現することができ、機器間の通信インタフェースの変更頻度を抑えつつ、ソフト開発工数の増大を防ぐことができる。

次に、ＭＭ機器１１とメータ機器２１とが連携して行う調停について説明する。尚、ここでは、ＭＭ機器１１において、アプリケーションＡを基本音声とし、アプリケーションＢを割り込み音声とし、メータ機器２１において、アプリケーションＸをメータ吹鳴とする。

図１１及び図１２に示すように、ＭＭ機器１１のルール定義ファイルとメータ機器２１のルール定義ファイルとでは、「Scene MET{}」を定義し、同じシーンを定義する。プロパティを定義しない場合は、図１１に示すように、メータ機器２１のルール定義ファイルでは、シーン情報をＭＭ機器１１に送信するための制御実行式を定義する。ＭＭ機器１１のルール定義ファイルでは、メータ機器２１から受信したシーン情報に基づいた調停仕様を定義する。プロパティを定義する場合は、図１２に示すように、メータ機器２１のルール定義ファイルでは、シーン情報及びプロパティ情報をＭＭ機器１１に送信するための制御実行式を定義する。ＭＭ機器１１のルール定義ファイルでは、メータ機器２１から受信したシーン情報及びプロパティ情報に基づいた調停仕様を定義する。

メータ機器２１は、アプリーションＸから提示要求を入力していない状態では、「メータ吹鳴なし」をＭＭ機器１１に定期的に送信する（ｔ１）。ＭＭ機器１１は、メータ機器２１から「メータ吹鳴なし」を定期的に受信している状態でアプリケーションＡから基本音声の「提示要求」が発生すると（ｔ２）、調停処理を行い（Ｓ１）、「出力指令」をアプリケーションＡに出力し（ｔ３）、アプリケーションＡのコンテントの音声出力を開始させる。

ＭＭ機器１１は、アプリケーションＡによる音声出力を開始させた後に、アプリケーションＢから割り込み音声の「提示要求」が発生すると（ｔ４）、アプリケーションＡのコンテントとアプリケーションＢのコンテントとで調停処理を行う（Ｓ２）。ＭＭ機器１１は、アプリケーションＢのコンテントを調停勝ちとし、アプリケーションＡのコンテントを調停負けとすると、「アッテネート指令」をアプリケーションＡに出力し（ｔ５）、アプリケーションＡのコンテントの音声出力をアッテネートさせ、「出力指令」をアプリケーションＢに出力し（ｔ６）、アプリケーションＢのコンテントの音声出力を開始させる。

メータ機器２１は、アプリケーションＸからメータ吹鳴の「提示要求」が発生すると（ｔ７）、調停処理を行い（Ｓ１１）、「メータ吹鳴中」をＭＭ機器１１に送信する（ｔ８）。この場合、メータ機器２１は、プロパティを定義しない場合は、図１３に示すように、「メータ吹鳴中」をＭＭ機器１１に送信し、プロパティを定義する場合は、図１４に示すように、「メータ吹鳴中」をＭＭ機器１１に送信すると共に、「risk_level : 10」のプロパティ情報をＭＭ機器１１に送信する。又、メータ機器２１は、「出力指令」をアプリケーションＸに出力し（ｔ９）、アプリケーションＸのコンテントの音声出力を開始させる。

ＭＭ機器１１は、メータ機器２１から「メータ吹鳴中」を受信すると（状態取得手順、状態取得処理に相当する）、調停処理を行う（Ｓ３、調停手順に相当する）。ＭＭ機器１１は、メータ吹鳴情報を調停勝ちとし、アプリケーションＡのコンテント及びアプリケーションＢのコンテントを調停負けとすると、「アッテネート指令」をアプリケーションＡに出力し（ｔ１０、調停制御手順、調停制御処理に相当する）、アプリケーションＡのコンテントの音声出力をアッテネートのままとし、「待機指令」をアプリケーションＢに出力し（ｔ１１、調停制御手順、調停制御処理に相当する）、アプリケーションＢのコンテントの音声出力を中断させて待機させる。

メータ機器２１は、アプリケーションＸからメータ吹鳴の「提示停止要求」が発生すると（ｔ１２）、調停処理を行い（Ｓ１２）、「メータ吹鳴なし」をＭＭ機器１１に送信する（ｔ１３）。又、メータ機器２１は、「出力停止指令」をアプリケーションＸに出力し（ｔ１４）、アプリケーションＸのコンテントの音声出力を終了させる。

ＭＭ機器１１は、メータ機器２１から「メータ吹鳴なし」を受信すると、調停処理を行う（Ｓ４）。ＭＭ機器１１は、アプリケーションＢのコンテントを調停勝ちとし、アプリケーションＡのコンテントを調停負けとすると、「アッテネート指令」をアプリケーションＡに出力し（ｔ１５）、アプリケーションＡのコンテントの音声出力をアッテネートのままとし、「出力指令」をアプリケーションＢに出力し（ｔ１６）、アプリケーションＢのコンテントの音声出力を再開させる。

このようにＭＭ機器１１とメータ機器２１とが連携して調停を行うことで、アプリケーションＡからの「提示要求」、アプリケーションＢからの「提示要求」、アプリケーションＸからの「提示要求」が同時に発生している場合に、アプリケーションＸのコンテントの音声出力を優先することができる。

以上は、ＭＭ機器１１において、メータ機器２１から「メータ吹鳴中」を受信することで、ルールで定義した情報をメータ機器２１から取得する場合を説明したが、メータ機器２１において調停を行った調停結果をメータ機器２１から取得しても良い。即ち、メータ機器２１は、アプリケーションＸのコンテントとアプリケーションＹのコンテントとで調停処理を行う場合に、その調停結果をＭＭ機器１１に送信し、ＭＭ機器１１は、メータ機器２１から調停結果を受信すると、アプリケーションＡ，Ｂと、そのメータ機器２１から受信した調停結果とについて、調停処理を行っても良い。

以上に説明したように本実施形態によれば、次のような作用効果を得ることができる。
ＭＭ機器１１において、アプリケーションＡ，Ｂからのコンテントの提示要求と、メータ機器２１の状態とについて、ルール定義に基づいて何れのコンテントを優先して提示するかの調停を行うようにした。何れのコンテントを優先して提示するかの調停を自己だけで行うのではなく、自己とメータ機器２１とが連携して両者の間で跨って行うことで、システム全体の中で優先度が他よりも高いコンテントを適切に優先して提示することができる。

ＭＭ機器１１において、メータ機器２１と連携して調停を行う場合に、シーン情報及びプロパティ情報を送受信するようにした。プロパティ情報を定義することで多様なシーンを表現することができ、機器間の通信インタフェースの変更頻度を抑えつつ、ソフト開発工数の増大を防ぐことができる。

本開示は、実施形態に準拠して記述されたが、当該実施形態や構造に限定されるものではないと理解される。本開示は、様々な変形例や均等範囲内の変形をも包含する。加えて、様々な組み合わせや形態、更には、それらに一要素のみ、それ以上、或いはそれ以下を含む他の組み合わせや形態をも、本開示の範疇や思想範囲に入るものである。

車両用に限らず、車両用以外の用途のコンテントの提示制御装置に適用しても良い。
ＭＭ機器１１において、アプリケーションＡ，Ｂからのコンテントの提示要求とメータ機器２１の状態とについて調停を行う場合を例示したが、ＭＭ機器１１とメータ機器２１との立場が反対でも良い。即ち、メータ機器２１において、アプリケーションＸ，Ｙからのコンテントの提示要求とＭＭ機器１１の状態とについて調停を行っても良い。

本開示に記載の制御部及びその手法は、コンピュータプログラムにより具体化された一つ乃至は複数の機能を実行するようにプログラムされたプロセッサ及びメモリを構成することにより提供された専用コンピュータにより実現されても良い。或いは、本開示に記載の制御部及びその手法は、一つ以上の専用ハードウェア論理回路によりプロセッサを構成することにより提供された専用コンピュータにより実現されても良い。若しくは、本開示に記載の制御部及びその手法は、一つ乃至は複数の機能を実行するようにプログラムされたプロセッサ及びメモリと一つ以上のハードウェア論理回路により構成されたプロセッサとの組み合わせにより構成された一つ以上の専用コンピュータにより実現されても良い。又、コンピュータプログラムは、コンピュータにより実行されるインストラクションとして、コンピュータ読み取り可能な非遷移有形記録媒体に記憶されていても良い。

図面中、１はコンテントの提示制御システム、１１はマルチメディア機器（コンテントの提示制御装置）、１３はアプリケーション記憶部、１７はルール定義記憶部、１８は状態取得部、１９は調停部、２０は提示制御部、２１はメータ機器（外部機器）である。

Claims (10)

1. コンテントの提示要求を発生するアプリケーションを記憶可能なアプリケーション記憶部（１５）と、
   制約式を含むルール定義を記憶するルール定義記憶部（１７）と、
   外部機器の状態を取得する状態取得部（１８）と、
   アプリケーションからのコンテントの提示要求と、前記状態取得部により取得された外部機器の状態とについて、前記ルール定義記憶部に記憶されているルール定義に基づいて何れのコンテントを優先して提示するかの調停を行う調停部（１９）と、
   前記調停部が行った調停結果にしたがってコンテントの提示を制御する提示制御部（２０）と、を備えるコンテントの提示制御装置（１１）。
2. 前記状態取得部は、コンテントの提示制御を行う前記外部機器の状態を取得する請求項１に記載したコンテントの提示制御装置。
3. 前記状態取得部は、外部機器の状態として、前記外部機器においてルールで定義した情報を取得する請求項１又は２に記載したコンテントの提示制御装置。
4. 前記状態取得部は、外部機器の状態として、前記外部機器において調停を行った調停結果を取得する請求項１又は２に記載したコンテントの提示制御装置。
5. 前記状態取得部は、外部機器の状態として、シーン情報を取得する請求項１から４の何れか一項に記載したコンテントの提示制御装置。
6. 前記状態取得部は、外部機器の状態として、シーン情報及びプロパティ情報を取得する請求項１から４の何れか一項に記載したコンテントの提示制御装置。
7. 外部機器の状態を取得する状態取得手順と、
   アプリケーションからのコンテントの提示要求と、前記状態取得手順により取得した外部機器の状態とについて、制約式を含むルール定義に基づいて何れのコンテントを優先して提示するかの調停を行う調停手順と、
   前記調停手順により行った調停結果にしたがってコンテントの提示を制御する提示制御手順と、を行うコンテントの提示制御方法。
8. 前記状態取得手順は、コンテントの提示制御を行う前記外部機器の状態を取得する請求項７に記載したコンテントの提示制御方法。
9. コンテントの提示制御装置（１１）に、
   外部機器の状態を取得する状態取得処理と、
   アプリケーションからのコンテントの提示要求と、前記状態取得処理により取得した外部機器の状態とについて、制約式を含むルール定義に基づいて何れのコンテントを優先して提示するかの調停を行う調停処理と、
   前記調停処理により行った調停結果にしたがってコンテントの提示を制御する提示制御処理と、を実行させるコンテントの提示制御プログラム。
10. 前記状態取得処理は、コンテントの提示制御を行う前記外部機器の状態を取得する請求項９に記載したコンテントの提示制御プログラム。

Images