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

Description

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

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

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

ルールベース調停では、例えば提示候補となるコンテントが複数ある場合、ルール定義に基づいて調停を行い、優先して提示するコンテントを決定する。調停負けしたコンテントは、調停勝ちしたコンテントの提示が終了した後に提示されるためには、提示要求を取り下げない「待機」として振る舞う必要があり、提示されないためには、提示要求を取り下げる「キャンセル」として振る舞う必要がある。

従来のルールベース調停では、調停負けしたコンテントの振る舞いは自己に依存しており、「待機」又は「キャンセル」の何れで振る舞うかを選択不可となっている。しかしながら、調停負けしたコンテントの振る舞いが自己に依存して選択不可となっている構成では、以下に示す不都合がある。

例えばナビゲーション機能に関するナビコンテントの調停負けしたときの振る舞いが「待機」である場合について説明する。ナビコンテントの音声出力中にＥＴＣ（Electronic Toll Collection）機能に関するＥＴＣコンテントの音声出力要求が割り込みで発生すると、ナビコンテントが調停負けし、調停負けしたナビコンテントは音声出力要求を待機する。即ち、ナビコンテントの音声出力を中断し、ＥＴＣコンテントの音声出力が終了した後に、ナビコンテントの音声出力を再開する。又、ナビコンテントの音声出力中に電話機能に関する電話コンテントの音声出力要求が割り込みで発生すると、この場合も、ナビコンテントが調停負けし、調停負けしたナビコンテントは音声出力要求を待機する。即ち、ナビコンテントの音声出力を中断し、電話コンテントの音声出力が終了した後に、ナビコンテントの音声出力を再開する。

ここで、例えばナビコンテントとして交差点の右折ガイダンスを音声出力中に電話コンテントの音声出力要求が割り込みで発生すると、右折ガイダンスの音声出力を中断し、電話コンテントの音声出力が終了した後に、右折ガイダンスの音声出力を再開する。ここで、電話コンテントの音声出力時間が長くなり、電話コンテントの音声出力が終了する前に車両が右折を完了してしまうと、右折ガイダンスの音声出力を再開することで不適切な情報をユーザに与えてしまうことになる。

このような事情から、調停負けしたコンテントの振る舞いを、調停相手のコンテント、即ち、調停勝ちしたコンテントに応じて変更可能とすることが望まれている。この場合、調停負けしたコンテントの振る舞いを、調停を行うコンテント同士の組み合わせにしたがってマトリックス状で定義する手法が考えられる。しかしながら、このようなマトリックス状で定義する手法では、コンテントの数が多くなると、組み合わせのパターンが多くなり、振る舞いの全てを定義することは困難となる。

一方、例えば特許文献１には、音声出力コンテントの時間特性を用い、調停勝ちしたコンテントの音声出力時間が調停負けしたコンテントの有効期限よりも長い場合に、調停負けしたコンテントをキャンセルする手法が開示されている。

特開２０１４－１３７７９０号公報

しかしながら、特許文献１に開示されている手法では、音声出力コンテントの個々に対して音声出力時間や有効期限等の時間パラメータを細かく定義する必要があり、ルール定義の保守性を著しく低下させてしまう問題がある。このような事情から、ルール定義の保守性を低下させることなく、調停負けしたコンテントの振る舞いを自在に変更する手法が望まれている。

本発明は、上記した事情に鑑みてなされたもので、その目的は、ルール定義の保守性を低下させることなく、調停負けしたコンテントの振る舞いを自在に変更することができるコンテントの提示制御装置、提示制御方法及び提示制御プログラムを提供することにある。

請求項１に記載した発明によれば、アプリケーション記憶部（１３）は、コンテントの提示要求を発生するアプリケーションを記憶可能である。ルール定義記憶部（１５）は、提示要求を取り下げるキャンセル又は提示要求を取り下げない待機の何れかを定義したコンテントの属性と、調停負けしたコンテントの振る舞いを待機又はキャンセルの何れかとする例外ルールを定義した制約式とを含むルール定義を記憶する。調停部（１６）は、一のアプリケーションのコンテントを提示中に他のアプリケーションからコンテントの提示要求が発生すると、ルール定義記憶部に記憶されているルール定義に基づいて何れのコンテントを優先して提示するかの調停を行う。提示制御部（１７）は、調停部が調停を行ったコンテントを提示領域に提示させる。

提示要求を取り下げるキャンセル又は提示要求を取り下げない待機の何れかを定義したコンテントの属性と、調停負けしたコンテントの振る舞いを待機又はキャンセルの何れかとする例外ルールを定義した制約式とを含むルール定義を記憶するようにした。一のアプリケーションのコンテントを提示中に他のアプリケーションからコンテントの提示要求が発生すると、ルール定義に基づいて何れのコンテントを優先して提示するかの調停を行うようにした。調停負けしたコンテントの振る舞いとして、デフォルトの振る舞いをコンテントの属性で定義し、例外的な振る舞いを制約式で定義することで、調停負けしたコンテントの振る舞いを自在に変更することができる。この場合、例外ルールだけを制約式で定義すれば良いので、ルール定義の保守性の低下を回避することができる。これにより、ルール定義の保守性を低下させることなく、調停負けしたコンテントの振る舞いを自在に変更することができる。

一実施形態における提示制御装置の構成を示す機能ブロック図 車室内を示す斜視図 優先度調停を示す図 後勝ち調停を示す図 エリアのＺオーダーと優先度との関係を示す図 コンテントと状態とエリアの関係性を示す図 仕様を示す図 述語論理式の構文を示す図 仕様を示す図 仕様を示す図 仕様を示す図 調停ロジックの全体処理を示すフローチャート 後処理を示すフローチャート 後処理を示すフローチャート 変更前の仕様を示す図 変更後の仕様を示す図 変更前の仕様を示す図 変更後の仕様を示す図 変更前の仕様を示す図 変更後の仕様を示す図

以下、一実施形態について図面を参照して説明する。図２に示すように、車両の車室１内には運転席２と助手席３とが配置されており、それらの前方にインストルメントパネル４が配置されている。インストルメントパネル４の前端にはフロントガラス５が立ち上がるように実装されている。インストルメントパネル４には第１表示装置６及び第２表示装置７が配置され、フロントガラス５には第３表示装置８が配置されている。

第１表示装置６は、例えばフルカラーの液晶表示装置から構成されるセンターディスプレイであり、基本的に車両走行に関係しない非走行系のコンテントを表示する表示部として機能する。非走行系のコンテントは、例えばナビゲーション用の地図情報、オーディオ情報、電話情報等である。又、第１表示装置６は、車両の後進時にリアカメラにより撮像された車両後方の映像を表示する表示部としても機能する。第２表示装置７は、例えばフルカラーの液晶表示装置から構成されるメータディスプレイであり、基本的に車両走行に関係する走行系のコンテントを表示する表示部として機能する。走行系のコンテントは、例えば車速、エンジン回転数、シフトポジション、燃料の残量等である。第３表示装置８は、インストルメントパネル４に配置されている表示ユニット９からフロントガラス５に映像が投影されるヘッドアップディスプレイであり、第２表示装置７と同様に、基本的に走行系のコンテントを表示する表示部として機能する。各表示装置６～８にはコンテントを表示するエリアが１つ又は複数設定されている。

車室１内の所定位置には音声出力装置１０（図１参照）が配置されている。音声出力装置１０は、一又は複数のスピーカーから構成され、走行系のコンテントや非走行系のコンテントを音声出力する音声出力部として機能する。このような構成では、各表示装置６～８にコンテントが表示され、音声出力装置１０からコンテントが音声出力されることで、走行系のコンテントや非走行系のコンテントから構成される各種情報が乗員に提供される。

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

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

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

調停部１６は、ルール定義記憶部１５に記憶されているルール定義に基づいて提示領域に割り当てるコンテントの調停を行う。調停部１６は、複数の異なるアプリケーションが同時に提示要求を割り込み出力する場合があり、このような場合は何れのコンテントを優先して提示するかの調停を行う。ここでいう「同時」とは時間的に同時という意味ではなく、一のアプリケーションがコンテントを提示中に他のアプリケーションからコンテントの提示要求が発生した状態、即ち、２つ以上のアプリケーションが提示要求を同時に割り込み出力した状態を意味する。

提示制御部１７は、入出力Ｉ／Ｆ１４を介して各種ＥＣＵ１８、各種センサ１９、各種スイッチ２０、自動運転制御装置２１等と車載ネットワーク２２を介して接続されている。車載ネットワーク２２は、例えばＣＡＮ（Controller Area Network、登録商標）等である。提示制御部１７は、コンテントの調停が調停部１６により行われると、その調停により割り当てられたコンテントを所定エリアに表示したり所定ゾーンから音声出力したりする。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

従来のルールベース調停では、調停負けしたコンテントの振る舞いは自己に依存しており、「待機」及び「キャンセル」の何れで振る舞うかを選択不可となっている。即ち、調停負けしたコンテントの振る舞いを調停勝ちしたコンテントに応じて選択不能である。このような事情から、従来のルールベース調停では、図７に示す仕様を成立させることできない。具体的には、調停負けしたナビコンテントの振る舞いは、調停負けした相手がＥＴＣコンテントのときは「待機」とし、調停負けした相手が電話コンテントのときは「キャンセル」とすることができない。この場合、調停負けしたコンテントの振る舞いを、調停を行うコンテント同士の組み合わせにしたがってマトリックス状で定義する手法では、コンテントの数が多くなると、組み合わせのパターンが多くなり、振る舞いの全てを定義することは困難となる。このような事情から、本実施形態では、以下に示す構成を採用している。

図８に示すように、調停負け時待機キャンセル判定処理で、調停結果とコンテントの振舞いを表す述語論理式の構文を用い、調停負け時待機キャンセル判定処理の制約式を作成する。
調停負けした場合の待機キャンセル判定処理の制約式の記述例を以下に示す。
（例１）「コンテントAはコンテントBに調停負けしたらコンテントAの提示要求をキャンセルする」の制約式は、
{コンテントA.isDefeatedBy(コンテントB) -> コンテントA.isCanceled()}
となる。
（例２）「コンテントAはコンテントBに調停負けしたらコンテントAの提示要求を待機する」の制約式は、
{コンテントA.isDefeatedBy(コンテントB) ->! コンテントA.isCanceled()}
となる。
（例３）「コンテントAはコンテントB又はコンテントCの何れか一方のみに調停負けしたらコンテントAの提示要求を待機する」の制約式は、
{コンテントA.isDefeatedBy(コンテントB) XOR コンテントA.isDefeatedBy(コンテントC) ->! コンテントA.isCanceled()}
となる。

上記した制約式において、「IsDefeatedBy」は「defeats」に置き換えることができる。（例１）の制約式は、
{コンテントB.defeats(コンテントA) -> コンテントA.isCanceled()}
と同義であり、（例２）の制約式は、
{コンテントB.defeats(コンテントA) ->! コンテントA.isCanceled()}
と同義である。

具体的には、図７に示した仕様では、「ナビコンテントは電話コンテントに調停負けしたらナビコンテントの提示要求をキャンセルする」の制約式は、
{Navi.isDefeatedBy(TEL) -> Navi.isCanceled()}
となる。
「ナビコンテントはＥＴＣコンテントに調停負けしたらナビコンテントの提示要求を待機する」の制約式は、
{Navi.isDefeatedBy(ETC) ->! Navi.isCanceled()}
となる。

調停負けしたときの基本ルールについて説明する。コンテントが調停負けしたときの振舞いは、デフォルト値（基本ルール）を記述し、デフォルト値を、
{GoodLoser : [true/false]}
という構文で記述する。

図９に示すように、ナビコンテント、ＥＴＣコンテント、電話コンテントにおいて、調停負けしたときの基本ルールが「待機」の場合、ルール定義は、
Navi {GoodLoser : false}
ETC {GoodLoser : false }
TEL {GoodLoser : false }
となる。

基本ルールが「キャンセル」のコンテントを含む場合には、ルール定義を変更する。図１０に示す仕様であれば、ルール定義は、
Navi {GoodLoser : true}
ETC {GoodLoser : false }
TEL {GoodLoser : false }
となる。

基本ルールだけで表現しきれない例外ルールがある場合には、例外ルールとして制約式を記述する。図１１に示す仕様であれば、ルール定義は、
Navi {GoodLoser : false}
ETC {GoodLoser : false }
TEL {GoodLoser : false }
となり、制約式は、
{Navi.isDefeatedBy(TEL) -> Navi.isCanceled()}
となる。

調停ロジックでゾーンにコンテントを割り当てる調停処理をした後に、要求の状態、即ち、調停負けしたコンテントの振る舞いを変化させるための後処理として調停負け時待機キャンセル判定処理を行う。後処理において、調停負け時待機キャンセル判定処理の制約式の評価を行い、コンテントの要求の状態を変化させる。

次に、調停部１６が行う調停ロジックの全体処理及び後処理について説明する。尚、ここでは、全てのコンテントにおいて、
{GoodLoser : false}
とし、調停負けしたときの振る舞いの基本ルールが「待機」である場合について説明する。

（１）調停ロジックの全体処理
調停部１６は、図１２に示すように、調停ロジックの全体処理を行う。調停部１６は、一のアプリケーションのコンテントを提示中に他のアプリケーションからコンテントの提示要求を受付けると（提示要求受付手順、提示要求受付処理に相当する）、調停処理を行い、提示領域にコンテントを割り当てる（Ｓ１、調停手順、調停処理に相当する）。調停部１６は、全ての制約式を評価し、調停処理に成功したか否かを判定する（Ｓ２）。調停部１６は、全ての制約式を満たしたと判定し、調停処理に成功したと判定すると（Ｓ３：ＹＥＳ）、結果に調停成功を設定し、コンテントの割り当てを確定する（Ｓ４）。調停部１６は、全ての制約式を満たしていないと判定し、調停処理に失敗したと判定すると（Ｓ３：ＮＯ）、結果に調停失敗を設定し、コンテントの割り当てを確定しない（Ｓ５）。調停部１６は、後処理を行い、コンテントの要求の状態を変化させる（Ｓ６）。即ち、調停部１６は、後処理において、「待機」を「キャンセル」に変更する必要があるか否かを判定し、変更する必要がないと判定すると、「待機」のままとし、変更する必要があると判定すると、「待機」を「キャンセル」に変更する。

（２）後処理
調停部１６は、図１３及び図１４に示すように、後処理（例外ルール評価手順、例外ルール評価処理に相当する）を行う。調停部１６は、要求があり非提示のコンテントを後処理対象コンテントとする（Ｓ１１）。調停部１６は、後処理対象のコンテントがあるか否かを判定する（Ｓ１２）。調停部１６は、後処理対象のコンテントがないと判定すると、ループ終了とする。

調停部１６は、後処理では、制約式の評価としてコンテントの要求を「待機」と「キャンセル」の両方を評価し、後処理制約式を満たした方の結果を採用する。調停部１６は、何れも同じ結果になった場合、即ち、「待機」と「キャンセル」の両方が「TRUE」又は両方が「FALSE」の場合には、コンテントの属性（GoodLoser）で判定する。尚、調停部１６は、正しい制約式であれば、「待機」と「キャンセル」の両方が「FALSE」の場合はあり得ないが、異常処理として行う。以下、具体的に説明する。

調停部１６は、後処理対象のコンテントがあると判定すると、待機確認として、コンテントの要求を待機に仮設定し（Ｓ１３）、後処理制約式を評価する（Ｓ１４）。調停部１６は、キャンセル確認として、コンテントの要求をキャンセルに仮設定し（Ｓ１５）、後処理制約式を評価する（Ｓ１６）。

調停部１６は、待機確認の後処理制約式を満たしたか否かを判定する（Ｓ１７）。調停部１６は、待機確認の後処理制約式が「TRUE」であると判定し、待機確認の後処理制約式を満たしたと判定すると（Ｓ１７：ＹＥＳ）、キャンセル確認の後処理制約式を満たしたか否かを判定する（Ｓ１８）。調停部１６は、キャンセル確認の後処理制約式が「FALSE」であると判定し、キャンセル確認の後処理制約式を満たしていないと判定すると（Ｓ１８：ＮＯ）、コンテントの要求をキャンセルせずに待機のままとする。即ち、調停部１６は、調停負けしたコンテントの振る舞いを基本ルールとし、「待機」のままとする。

調停部１６は、キャンセル確認の後処理制約式が「TRUE」であると判定し、キャンセル確認の後処理制約式を満たしたと判定すると（Ｓ１８：ＹＥＳ）、コンテントがGoodLoserであるか否かを判定する（Ｓ１９）。調停部１６は、コンテントがGoodLoserでないと判定すると（Ｓ１９：ＮＯ）、この場合も、コンテントの要求をキャンセルせずに待機のままとする。即ち、調停部１６は、調停負けしたコンテントの振る舞いを基本ルールとし、「待機」のままとする。

調停部１６は、コンテントがGoodLoserであると判定すると（Ｓ１９：ＹＥＳ）、コンテントの要求をキャンセルする（Ｓ２０）。即ち、調停部１６は、調停負けしたコンテントの振る舞いを例外ルールとし、「待機」を「キャンセル」に変更する。

調停部１６は、待機確認の後処理制約式が「FALSE」であると判定し、待機確認の後処理制約式を満たしていないと判定すると（Ｓ１７：ＮＯ）、キャンセル確認の後処理制約式を満たしたか否かを判定する（Ｓ２１）。調停部１６は、キャンセル確認の後処理制約式が「TRUE」であると判定し、キャンセル確認の後処理制約式を満たしたと判定すると（Ｓ２１：ＹＥＳ）、コンテントの要求をキャンセルする（Ｓ２２）。即ち、調停部１６は、この場合も、調停負けしたコンテントの振る舞いを例外ルールとし、「待機」を「キャンセル」に変更する。

調停部１６は、キャンセル確認の後処理制約式が「FALSE」であると判定し、キャンセル確認の後処理制約式を満たしていないと判定すると（Ｓ２１：ＮＯ）、コンテントがGoodLoserであるか否かを判定する（Ｓ２３）。調停部１６は、コンテントがGoodLoserであると判定すると（Ｓ２３：ＹＥＳ）、コンテントの要求をキャンセルする（Ｓ２４）。即ち、調停部１６は、この場合も、調停負けしたコンテントの振る舞いを例外ルールとし、「待機」を「キャンセル」に変更する。

調停部１６は、コンテントがGoodLoserでないと判定すると（Ｓ２３：ＮＯ）、コンテントの要求をキャンセルせずに待機のままとする。即ち、調停部１６は、調停負けしたコンテントの振る舞いを基本ルールとし、「待機」のままとする。調停部１６は、次の後処理対象コンテントについて上記した処理を繰り返す（Ｓ２５）。上記した処理では、調停負けしたときの振る舞いの基本ルールが「待機」である場合について説明したが、調停負けしたときの振る舞いの基本ルールが「キャンセル」である場合についても同様である。

以上は、コンテントを単位として例外ルールの制約式を定義する場合を説明したが、複数のコンテントをグループ化し、グループを単位として例外ルールの制約式を定義しても良い。複数のコンテントをグループ化する場合としては、例えば有効期限を有する特性のコンテント（有効期限付きコンテント）をグループ化する場合、処理時間が他よりも長い特性のコンテント（処理時間長コンテント）をグループ化する場合がある。

有効期限を有する特性のコンテントをグループ化する場合について図１５及び図１６を参照して説明する。図１５に示すように、有効期限を有する特性のコンテントがナビコンテント及びＥＴＣコンテントであり、ナビコンテント及びＥＴＣコンテントについて電話コンテントに調停負けした場合に自己の提示要求を取り下げることを例外ルールとする仕様を例示する。

この場合、グループを単位とせずに例外ルールの制約式を定義すると、
「ナビコンテントは電話コンテントに調停負けしたらナビコンテントの提示要求をキャンセルする」の制約式は、
{Navi.isDefeatedBy(TEL) -> Navi.isCanceled()}
となり、
「ＥＴＣコンテントは電話コンテントに調停負けしたらＥＴＣコンテントの提示要求をキャンセルする」の制約式は、
{ETC.isDefeatedBy(TEL) -> ETC.isCanceled()}
となる。即ち、ナビコンテント及びＥＴＣコンテントの個々について２つの制約式を記述する必要がある。

一方、グループを単位として例外ルールの制約式を定義すると、グループの定義として、
有効期限付きコンテント群{Navi、ETC}
を定義し、グループに適用する例外ルールの定義として、
「有効期限付きコンテント群は電話コンテントに調停負けしたら有効期限付きコンテント群をキャンセルする」の制約式は、
{For-All有効期限付きコンテント群{x|x.isDefeatedBy(TEL) -> x.isCanceled()}
となる。即ち、ナビコンテント及びＥＴＣコンテントに共通する１つの制約式を記述すれば良い。

この状態から仕様変更により、図１６に示すように、ナビコンテント及びＥＴＣコンテントに加え、音声認識コンテント及び標識認識コンテントについても電話コンテントに調停負けした場合に自己の提示要求を取り下げることを例外ルールとする場合を説明する。グループを単位とせずに例外ルールの制約式を定義すると、仕様の変更後では、上記した仕様の変更前の２つの制約式に加え、以下の２つの制約式を追加して記述する必要がある。
「音声認識コンテントは電話コンテントに調停負けしたら音声認識コンテントの提示要求をキャンセルする」
{音声認識.isDefeatedBy(TEL) -> 音声認識.isCanceled()}
「標識認識コンテントは電話コンテントに調停負けしたら標識認識コンテントの提示要求をキャンセルする」
{標識認識.isDefeatedBy(TEL) -> 標識認識.isCanceled()}

一方、グループを単位として例外ルールの制約式を定義すると、仕様の変更後では、グループの定義として、
有効期限付きコンテント群{Navi、ETC、音声認識、標識認識}
を定義すれば良く、グループに適用する例外ルールの定義として、
「有効期限付きコンテント群は電話コンテントに調停負けしたら有効期限付きコンテント群をキャンセルする」
{For-All有効期限付きコンテント群{x|x.isDefeatedBy(TEL) -> x.isCanceled()}
を変更せずにそのまま適用すれば良い。

即ち、有効期限付きコンテントをグループ化し、「For-All」を含む制約式を使用することで、集合の要素の全てが条件を満たす制約式を定義することができる。コンテントをグループ化することで制約式を抽象的に記述することができ、仕様変更によりコンテントが増える場合にグループの定義を編集するだけで対応することができる。

次に、処理時間が他よりも長い特性のコンテントをグループ化する場合について図１７及び図１８を参照して説明する。図１７に示すように、処理時間が他よりも長い特性のコンテントが電話コンテントであり、電話コンテントについてナビコンテントに調停勝ちした場合に相手の提示要求を取り下げさせることを例外ルールとする仕様を例示する。

この場合、グループを単位とせずに例外ルールの制約式を定義すると、
「ナビコンテントは電話コンテントに調停負けしたらナビコンテントの提示要求をキャンセルする」の制約式は、
{Navi.isDefeatedBy(TEL) -> Navi.isCanceled()}
となる。

一方、グループを単位として例外ルールの制約式を定義すると、グループの定義として、
処理時間長コンテント群{TEL}
を定義し、グループに適用する例外ルールの定義として、
「ナビコンテントは処理時間長コンテント群の何れかに調停負けしたらキャンセルする」の制約式は、
{Exists 処理時間長コンテント群{x|Navi.isDefeatedBy(x)}-> Navi.isCanceled()}
となる。

この状態から仕様変更により、図１８に示すように、電話コンテントに加え、音声認識コンテント及び標識認識コンテントについてもナビコンテントに調停勝ちした場合に相手の提示要求を取り下げさせることを例外ルールとする場合を説明する。グループを単位とせずに例外ルールの制約式を定義すると、仕様の変更後では、上記した仕様の変更前の１つの制約式に加え、以下の２つの制約式を追加して記述する必要がある。
「ナビコンテントは音声認識コンテントに調停負けしたらナビコンテントの提示要求をキャンセルする」
{Navi.isDefeatedBy(音声認識) -> Navi.isCanceled()}
「ナビコンテントは標識認識コンテントに調停負けしたらナビコンテントの提示要求をキャンセルする」
{Navi.isDefeatedBy(標識認識) -> Navi.isCanceled()}

一方、グループを単位として例外ルールの制約式を定義すると、仕様の変更後では、グループの定義として、
処理時間長コンテント群{TEL、音声認識、標識認識}
を定義すれば良く、グループに適用する例外ルールの定義として、
「ナビコンテントは処理時間長コンテント群の何れかに調停負けしたらキャンセルする」
{Exists 処理時間長コンテント群{x|Navi.isDefeatedBy(x)} ->Navi.isCanceled()}
を変更せずにそのまま適用すれば良い。

即ち、処理時間長コンテントをグループ化し、「Exists」を含む制約式を使用することで、集合の要素の何れかが条件を満たす制約式を定義することができる。この場合も、コンテントをグループ化することで制約式を抽象的に記述することができ、仕様変更によりコンテントが増える場合にグループを編集するだけで対応することができる。

次に、有効期限を有する特性のコンテントをグループ化し、且つ処理時間が他よりも長い特性のコンテントをグループ化する場合について図１９及び図２０を参照して説明する。この場合は、図１５及び図１６に示した仕様と、図１７及び図１８に示した仕様とを組み合わせた場合と同等である。図１９に示すように、有効期限を有する特性のコンテントがナビコンテント及びＥＴＣコンテントであり、ナビコンテント及びＥＴＣコンテントについて電話コンテントに調停負けした場合に自己の提示要求を取り下げ、且つ処理時間が他よりも長い特性のコンテントが電話コンテントであり、電話コンテントについてナビコンテントに調停勝ちした場合に相手の提示要求を取り下げさせることを例外ルールとする仕様を例示する。

この場合、グループを単位とせずに例外ルールの制約式を定義すると、
「ナビコンテントは電話コンテントに調停負けしたらナビコンテントの提示要求をキャンセルする」の制約式は、
{Navi.isDefeatedBy(TEL) -> Navi.isCanceled()}
となり、
「ＥＴＣコンテントは電話コンテントに調停負けしたらＥＴＣコンテントの提示要求をキャンセルする」の制約式は、
{ETC.isDefeatedBy(TEL) -> ETC.isCanceled()}
となる。即ち、ナビコンテント及びＥＴＣコンテントの個々について２つの制約式を記述する必要がある。

一方、グループを単位として例外ルールの制約式を定義すると、グループの定義として、
有効期限付きコンテント群{Navi、ETC}
処理時間長コンテント群{TEL}
を定義し、グループに適用する例外ルールの定義として、
「有効期限付きコンテント群は処理時間長コンテント群の何れかに調停負けしたらキャンセルする」の制約式は、
For-All 負け時キャンセルコンテント群
{x|Exists 勝ち時相手キャンセルコンテント群{y|x.isDefeatedBy(y)} -> x.isCanceled()}
となる。

この状態から仕様変更により、図２０に示すように、ナビコンテント及びＥＴＣコンテントに加え、音声認識コンテント及び標識認識コンテントについても電話コンテントに調停負けした場合に自己の提示要求を取り下げ、且つ電話コンテントに加え、音声認識コンテント及び標識認識コンテントについてもナビコンテントに調停勝ちした場合に相手の提示要求を取り下げさせることを例外ルールとする場合を説明する。グループを単位とせずに例外ルールの制約式を定義すると、仕様の変更後では、上記した仕様の変更前の２つの制約式に加え、以下の４つの制約式を追加して記述する必要がある。
「ナビコンテントは音声認識コンテントに調停負けしたらナビコンテントの提示要求をキャンセルする」
{Navi.isDefeatedBy(音声認識) -> Navi.isCanceled()}
「ナビコンテントは標識認識コンテントに調停負けしたらナビコンテントの提示要求をキャンセルする」
{Navi.isDefeatedBy(標識認識) -> Navi.isCanceled()}
「ＥＴＣコンテントは音声認識コンテントに調停負けしたらＥＴＣコンテントの提示要求をキャンセルする」
{ETC.isDefeatedBy(音声認識) -> ETC.isCanceled()}
「ＥＴＣコンテントは標識認識コンテントに調停負けしたらＥＴＣコンテントの提示要求をキャンセルする」
{ETC.isDefeatedBy(標識認識) -> ETC.isCanceled()}

一方、グループを単位として例外ルールの制約式を定義すると、仕様の変更後では、グループの定義として、
有効期限付きコンテント群{Navi、ETC}
処理時間長コンテント群{TEL、音声認識、標識認識}
を定義すれば良く、グループに適用する例外ルールの定義として、
For-All 負け時キャンセルコンテント群
{x|Exists 勝ち時相手キャンセルコンテント群{y|x.isDefeatedBy(y)} -> x.isCanceled()}
を変更せずにそのまま適用すれば良い。

即ち、有効期限付きコンテントと処理時間が他よりも長い特性のコンテントとを同時にグループ化する場合でも、「For-All」及び「Exists」を含む制約式を使用することで、制約式を抽象的に記述することができ、仕様変更によりコンテントが増える場合にグループの定義を編集するだけで対応することができる。

以上に説明したように本実施形態によれば、次のような作用効果を得ることができる。
提示制御装置１１において、提示要求を取り下げるキャンセル又は提示要求を取り下げない待機の何れかを定義したコンテントの属性と、調停負けしたコンテントの振る舞いを待機又はキャンセルの何れかとする例外ルールを定義した制約式とを含むルール定義を記憶するようにした。一のアプリケーションのコンテントを提示中に他のアプリケーションからコンテントの提示要求が発生すると、ルール定義に基づいて何れのコンテントを優先して提示するかの調停を行うようにした。

調停負けしたコンテントの振る舞いとして、デフォルトの振る舞いをコンテントの属性で定義し、例外的な振る舞いを制約式で定義することで、調停負けしたコンテントの振る舞いを自在に変更することができる。この場合、例外ルールだけを制約式で定義すれば良いので、ルール定義の保守性の低下を回避することができる。これにより、ルール定義の保守性を低下させることなく、調停負けしたコンテントの振る舞いを自在に変更することができる。

提示制御装置１１において、複数のコンテントをグループ化し、グループを単位として例外ルールの制約式を定義するようにした。振る舞いを規定するコンテントが増える場合にグループの定義を編集するだけで適切且つ容易に対応することができる。

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

車両用に限らず、車両用以外の用途のコンテントの提示制御装置に適用しても良い。
コンテントとして、ナビコンテント、ＥＴＣコンテント、電話コンテント、音声認識コンテント、標識認識コンテントを例示したが、他のアプリケーションを提供するコンテントを含んでも良い。
グループ化するコンテントとして、有効期限を有する特性のコンテント、処理時間が他よりも長い特性のコンテントを例示したが、他の特性を有するコンテントを含んでも良い。

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

図面中、１１は提示制御装置（コンテントの提示制御装置）、１３はアプリケーション記憶部、１５はルール定義記憶部、１６は調停部、１７は提示制御部である。

Claims (12)

1. コンテントの提示要求を発生するアプリケーションを記憶可能なアプリケーション記憶部（１３）と、
   提示要求を取り下げるキャンセル又は提示要求を取り下げない待機の何れかを定義したコンテントの属性と、調停負けしたコンテントの振る舞いを待機又はキャンセルの何れかとする例外ルールを定義した制約式とを含むルール定義を記憶するルール定義記憶部（１５）と、
   一のアプリケーションのコンテントを提示中に他のアプリケーションからコンテントの提示要求が発生すると、前記ルール定義記憶部に記憶されているルール定義に基づいて何れのコンテントを優先して提示するかの調停を行う調停部（１６）と、
   前記調停部が調停を行ったコンテントを提示領域に提示させる提示制御部（１７）と、を備えるコンテントの提示制御装置（１１）。
2. 前記調停部は、調停負けしたコンテントに対し、例外ルールを評価する請求項１に記載したコンテントの提示制御装置。
3. 前記調停部は、調停負けしたコンテントの振る舞いを待機とした場合と、調停負けしたコンテントの振る舞いをキャンセルとした場合との両方について、例外ルールを評価する請求項２に記載したコンテントの提示制御装置。
4. 前記調停部は、例外ルールの評価結果として例外ルールに該当する場合には、例外ルールを適用する請求項３に記載したコンテントの提示制御装置。
5. 前記調停部は、例外ルールの評価結果として例外ルールに該当しない場合には、コンテントの属性を適用する請求項３に記載したコンテントの提示制御装置。
6. 前記ルール定義記憶部は、複数のコンテントをグループ化したグループを単位とし、例外ルールを定義した制約式を含むルール定義を記憶する請求項１から５の何れか一項に記載したコンテントの提示制御装置。
7. 前記ルール定義記憶部は、有効期限を有する特性のコンテントをグループ化したグループを単位とし、例外ルールを定義した制約式を含むルール定義を記憶する請求項６に記載したコンテントの提示制御装置。
8. 前記ルール定義記憶部は、処理時間が他よりも長い特性のコンテントをグループ化したグループを単位とし、例外ルールを定義した制約式を含むルール定義を記憶する請求項６に記載したコンテントの提示制御装置。
9. 一のアプリケーションのコンテントを提示中に他のアプリケーションからコンテントの提示要求を受付ける提示要求受付手順と、
   提示要求を取り下げるキャンセル又は提示要求を取り下げない待機の何れかを定義したコンテントの属性と、調停負けしたコンテントの振る舞いを待機又はキャンセルの何れかとする例外ルールを定義した制約式とを含むルール定義に基づいて何れのコンテントを優先して提示するかの調停を行う調停手順と、
   前記調停手順により調停を行ったコンテントを提示領域に提示させる提示制御手順と、を行うコンテントの提示制御方法。
10. 調停負けしたコンテントに対し、例外ルールを評価する例外ルール評価手順を行う請求項９に記載したコンテントの提示制御方法。
11. コンテントの提示制御装置（１１）に、
    一のアプリケーションのコンテントを提示中に他のアプリケーションからコンテントの提示要求を受付ける提示要求受付処理と、
    提示要求を取り下げるキャンセル又は提示要求を取り下げない待機の何れかを定義したコンテントの属性と、調停負けしたコンテントの振る舞いを待機又はキャンセルの何れかとする例外ルールを定義した制約式とを含むルール定義に基づいて何れのコンテントを優先して提示するかの調停を行う調停処理と、
    前記調停処理により調停を行ったコンテントを提示領域に提示させる提示制御処理と、を実行させるコンテントの提示制御プログラム。
12. 調停負けしたコンテントに対し、例外ルールを評価する例外ルール評価処理を行う請求項１１に記載したコンテントの提示制御プログラム。

Images