車載多機能装置、メタデータ
【課題】処理とユーザインターフェイスとを分離して、多様なシチュエーションにおいて適切なユーザインターフェイスを提供し、また、システムの拡張が容易な車載多機能装置及びメタデータを提供すること。
【解決手段】ユーザインターフェイス２，６、７を介してユーザからの入力を受け付け、出力装置６，７からユーザにサービスを提供する車載多機能装置１において、メタデータにより記述されたユーザインターフェイス及びサービスの内容を記憶したメタデータ記憶手段９と、メタデータを解釈してユーザインターフェイス又はサービスを生成する制御部２０と、を有することを特徴とする。
【解決手段】ユーザインターフェイス２，６、７を介してユーザからの入力を受け付け、出力装置６，７からユーザにサービスを提供する車載多機能装置１において、メタデータにより記述されたユーザインターフェイス及びサービスの内容を記憶したメタデータ記憶手段９と、メタデータを解釈してユーザインターフェイス又はサービスを生成する制御部２０と、を有することを特徴とする。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、車両においてユーザに様々なサービスを提供する車載多機能装置及びメタデータに関する。
【背景技術】
【０００２】
従来、車両には、カーナビゲーションシステムやラジオやテレビ、動画の再生など、マルチメディア機能が搭載されている（例えば、特許文献１参照。）。車両のマルチメディア機能は、ユーザとの対話に基づき処理を実行し、次の画面や処理結果を表示するものであるが、このようなコンピュータ上で提供されるシステムの実現方法としてＭＶＣ（Ｍｏｄｅｌ Ｖｉｅｗ Ｃｏｎｔｒｏｌｌｅｒ）アーキテクチャが知られている。
【０００３】
図１（ａ）はＭＶＣアーキテクチャの概念図を示す。ＭＶＣアーキテクチャでは、アプリケーションの構成要素を、処理（Ｍｏｄｅｌ）Ｍ、表示（Ｖｉｅｗ）Ｖ、入力（Ｃｏｎｔｒｏｌｌｅｒ）Ｃの３つで構成する。
【０００４】
Ｍｏｄｅｌはアプリケーションの処理を受け持つ部分であり、アプリケーションで必要となるデータを保持しており、入力Ｃからの入力に応じて処理を実行する。Ｖｉｅｗは、Ｍｏｄｅｌの状態を表示する部分であり、液晶などの表示装置上に表示されるウィンドウ等である。Ｖｉｅｗは、情報の配置又は配置の方法を規定するものであるので、頻繁に変更の要請が生じる。また、Ｃｏｎｔｒｏｌｌｅｒは、ユーザの入力、タッチパネルや押しボタン、音声などの入力を受け取り、入力内容を処理する。Ｃｏｎｔｒｏｌｌｅｒは、例えば、表示画面の更新を行う場合にはＶｉｅｗを呼び出したり、入力内容を適切に変換してＭｏｄｅｌに渡す。
【特許文献１】特開２００１−２３５３３４号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら、図１（ａ）のようなＭＶＣアーキテクチャでは、ＶｉｅｗとＭｏｄｅｌの依存関係が強いため、ユーザインターフェイスと処理を分離することが困難である。車両では多様なシチュエーションにおいてマルチメディア機能を利用することが想定されるため、車載されたマルチメディア機能は、ユーザと密接に関わるユーザインターフェイスを、車両のモデル・車種・ユーザの嗜好等に応じて拡張可能な仕組みが要請される。
【０００６】
また、カーナビゲーションシステムや動画の再生機能などは今後も進化が予想されるため、ソフトウェアのロジック（処理部）を部品化しその再利用が容易であることや、進歩・多様化していくハードウェアやＯＳ、デバイス等の低レベルなプラットフォーム層に依存しない仕組みを有することが必要とされる。
【０００７】
本発明は、上記問題に鑑み、処理とユーザインターフェイスとを分離して、多様なシチュエーションにおいて適切なユーザインターフェイスを提供し、また、システムの拡張が容易な車載多機能装置及びメタデータを提供することを目的とする。
【課題を解決するための手段】
【０００８】
上記課題を解決するため、本発明は、ユーザインターフェイスを介してユーザからの入力を受け付け、出力装置（例えば、表示装置６、スピーカ７）からユーザにサービスを提供する車載多機能装置において、メタデータにより記述されたユーザインターフェイス及びサービスの内容を記憶したメタデータ記憶手段（例えば、記憶装置９）と、メタデータを解釈してユーザインターフェイス又はサービスを生成する制御部（例えば、ＵＩサーバ２０）と、を有することを特徴とする。
【０００９】
また、本発明の好ましい一形態において、前記メタデータ記憶手段は、前記ユーザインターフェイス又はサービスの遷移をメタデータにより記述した遷移情報（例えば、レイアウトＭＬ、シナリオＭＬ、ボイスＭＬ）を記憶している、ことを特徴とする。
【００１０】
本発明によれば、処理とユーザインターフェイス及びサービスとを分離した車載多機能装置を提供できる。なお、サービスとは、車載されたデバイスを制御して出力・表示されるもの、例えば、音声や表示の内容をいう。また、ユーザインターフェイスとは、視覚によるものだけでなく、聴覚や嗅覚によるものを含む。ユーザインターフェイスやサービスの内容や遷移がメタデータにより記述されることで、ユーザインターフェイスやサービスに容易に拡張性をもたらすことができる。
【００１１】
また、本発明の一形態において、ユーザインターフェイス及びサービスの内容を記述したメタデータはそれぞれ独立して変更可能である、ことを特徴とする。すなわち、サービスを定義したシナリオＭＬ、画面構成／遷移を定義したレイアウトＭＬ、音声による対話制御を定義したボイスＭＬ等のＸＭＬファイルは、それぞれ独立に記述されているため、いずれかの変更が他に影響を与えることがない。
【００１２】
本発明によれば、ユーザインターフェイスやサービスを後から追加、拡張することができ、追加、拡張がそれ以外の機能に与える影響が少ない。
【００１３】
また、本発明の一形態において、更新頻度の高い描画を反映する動画用アダプタ（例えば、ＭＭＰ動画再生用実体（Ｄｒａｗｉｎｇ Ａｄａｐｔｅｒ））を有し、更新頻度の高い描画がある場合、制御部はユーザインターフェイスに描画領域を設け、動画アダプタが描画領域に描画する、ことを特徴とする。
【００１４】
本発明によれば、動画のように更新頻度の高い描画も、ユーザインターフェイスとして扱えるので、動画の取り扱いが容易になる。
【００１５】
また、本発明の一形態において、前記ユーザを識別する手段と、道路の交通状況、日時等のシチュエーションを判別する手段とを有し、制御部は、ユーザ又はシチュエーションに応じて、メタデータ記憶手段に記憶されたメタデータを抽出し、制御部は、ユーザ又はシチュエーションに応じたユーザインターフェイス又はサービスを生成する、ことを特徴とする。
【００１６】
本発明によれば、ユーザやシチュエーションに応じて、自動的にユーザインターフェイスやサービスを提供できる。
【発明の効果】
【００１７】
処理とユーザインターフェイスとを分離して、多様なシチュエーションにおいて適切なユーザインターフェイスを提供し、また、システムの拡張が容易な車載多機能装置及びメタデータを提供することができる。
【発明を実施するための最良の形態】
【００１８】
図１（ｂ）は、本実施の形態のマルチメディアアーキテクチャの概念図を示す。本実施の形態のマルチメディアアーキテクチャは、ＭｏｄｅｌとＶｉｅｗ及びＣｏｎｔｒｏｌｌｅｒの間に、シナリオという概念を挿入した。
【００１９】
シナリオは、Ｍｏｄｅｌと動的に結合する機構を有する。シナリオは、Ｖｉｅｗ又はＣｏｎｔｒｏｌｌｅｒをイベントと変数のマッピングにより結合させる機構を持つことにより、それぞれの依存関係を疎結合化している。これにより、ユーザインターフェイスと処理のロジックとを完全に分離することが可能となる。
【００２０】
図２（ａ）は、本実施の形態のマルチメディアアーキテクチャが適用された車載多機能装置のハードウェア構成図を示す。カーナビ装置３は、ＧＰＳ衛星から送信される航法データに基づいて車両の現在位置を検出し、現在位置を含む道路地図に目的地までの走行経路などを制御装置１０に供給する。テレビ／ラジオユニット４は、ＵＨＦやＶＨＦのテレビ放送電波や地上波デジタル放送を受信して、映像及び音楽等を制御装置１０に供給する。また、ＡＭ、ＦＭ放送や地上波デジタルラジオ放送を受信して、音楽等を制御装置１０に供給する。なお、テレビ／ラジオユニット１０４は準天頂衛星からの電波を受信するものであってもよい。メディアプレーヤ５は、ＤＶＤやＣＤ、メモリカードのデータを読み出して再生し、映像及び音楽等を制御装置１０へ供給する。
【００２１】
通信ユニット８は、携帯電話、ＰＨＳ等の移動体通信又は無線ＬＡＮ等により、基地局やアクセスポイントに接続すると共に、ネットワークを介して情報を受信して制御装置１０へ供給したり、制御装置１０から指示された情報をネットワークを介して外部に送信する。なお、通信ユニット８は、情報センタに蓄積されている渋滞情報その他の交通情報をビーコン等により取得して制御装置１０に供給する。
【００２２】
表示装置６は、液晶ディスプレイやプロジェクタなどで構成され、カーナビ装置３から供給される地図、テレビ／ラジオユニット４から供給されるテレビ画像、メディアプレーヤ５から供給される動画などを表示する。また、表示装置６は、車載多機能装置１を操作するための操作メニューを表示する。スピーカ７は、カーナビ装置３による音声案内、テレビ／ラジオユニット４から供給される音声、メディアプレーヤ５から供給される音声などを出力する。入力装置２は、押しボタンやリモコン、表示装置６と一体のタッチパネル等により構成され、ユーザが所望の機能を選択したり、カーナビ装置の目的地の入力、テレビやラジオの選局の入力を可能とする。なお、入力装置２は、マイクロフォンを備えて音声による操作も可能である。
【００２３】
制御装置１０は、車載多機能装置１を制御するための制御装置であり、ＣＰＵ、ＲＯＭ、ＲＡＭ及びＮＶＲＡＭなどをバスにより接続したコンピュータにより構成される。ＣＰＵはＲＯＭや記憶装置９に格納されているプログラムを実行して、入力に応じた処理や画面表示の切り替え等、後述する処理を実行する。記憶装置９はハードディスクドライブや書き換え可能な光ディスク、フラッシュメモリ等により構成され、ＯＳ等や地図データ、ファイル（メタデータ）、プログラムなどを格納している。メタデータ、プログラム、地図データ等は、車両に設けられたコネクタや無線通信を介し記憶装置９にインストールされる。なお、メタデータはネットワークを介してダウンロードされ、記憶装置９にインストールしてもよい。
【００２４】
図２（ｂ）は、マルチメディアアーキテクチャの全体システム構成図を示す（以下、図２（ｂ）のＵＩサーバを単にシステムということがある）。マルチメディアアーキテクチャのシステムは、ディスプレイやスピーカ、マイクロフォン等のハードウェアとそれらのドライバからなるＨ／Ｗ、システム全体を統括するＳｙｓｔｅｍ、分散環境を実現する為の分散ＦＷ、データ等を管理するＣｏｎｔｅｎｔｓサーバ、サービスの個別部品としてソフトウェア処理を行うＭｏｄｅｌ、本実施の形態で説明するユーザインターフェイスを制御するＵＩサーバ２０から構成される。なお、ＵＩサーバ２０とハードウェア以外の構成を外部サブシステムと称す。
【００２５】
図２（ｂ）のＵＩサーバ２０は、分散ＦＷのライフサイクル管理から起動され、取り付けられるデバイスや外部サービスと連携して、ユーザにサービスを提供する。ＵＩサーバ２０は、サービスの状態遷移を受け持つシナリオ処理部１２、画面を受け持つレイアウト部１３及びグラフイック部１６、音を受け持つボイス部及びサウンド部１７、サブシステム間で共有するオブジェクトのリファレンスを格納する為のＵＩリポジトリ及びＬＳｕＩ（Ｌｉｆｅ Ｓｃｅｎｅ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）との連携の際に使用するＬＳｕＩ連携部１１を有する。
【００２６】
ＬＳｕＩ連携部１１は、ＬＳｕＩとＵＩサーバ２０の他のサブシステムとが連携する際にメッセージＭＬの送受信を行う。サブシステム間の連携について説明する。図３（ａ）は、ＸＭＬ（eXtensible Markup Language）メッセージによるサブシステム間の疎結合の概略を示す図である。
【００２７】
本システムでは、サブシステム間のデータ授受に際し、言語やプラットフォームに依存しない形とする為、メタデータ、主にＸＭＬメッセージを用いる。これにより、サブシステム間の疎結合化が可能となる。ＸＭＬメッセージとは、ＸＭＬを用いてメッセージのやり取りを行うことをいう。すなわち、図３（ａ）に示すように、シナリオ処理部とレイアウト部、シナリオ処理部とボイス部は、ＸＭＬメッセージを用いて、例えば、ＸＭＬ読み込み依頼などの内容を相互にやり取りする。したがって、「メッセージＭＬ」のように「〜ＭＬ」と表示されるものは、ＸＭＬメッセージにより対象となる処理に関する連携を行うことを示す。
【００２８】
本システムで使用するＸＭＬ規格は、大きくシナリオ、レイアウト、ボイスの３つについてのＸＭＬと、ＸＭＬ間の情報をマッピングするＤ．Ｄ．（Ｄｅｐｌｏｙｍｅｎｔ Ｄｅｓｃｒｉｐｔｏｒ）から成る（Ｄ．Ｄ．もＸＭＬファイルである）。代表的な「〜ＭＬ」は次のようになる。
・シナリオＭＬ
本システムが提供するサービスの定義。シナリオＭＬがレイアウトＭＬ、ボイスＭＬ及びモデルと繋がる基点となる。
・シナリオＭＬ用リソースＭＬ
シナリオＭＬ、モデル用Ｄ．Ｄ．に対するテキストリソースを定義する。シナリオＭＬ用リソースＭＬを差し替えることにより、同一のシナリオのままで、使用する文字を変更することが可能となる。（例：日本語→英語）
・レイアウトＭＬ
本システムが提供するグラフィックデバイス向けユーザインタフゴースの構成、遷移を定義する。
・レイアウトＭＬ用Ｄ．Ｄ．
シナリオＭＬとレイアウトＭＬの、イベント及び変数の関連づけを定義する。レイアウトＭＬ用Ｄ．Ｄ．により、シナリオＭＬ中の変数とレイアウトＭＬ中の変数が紐付けされ、データが共有される。また、レイアウトＭＬ用Ｄ．Ｄ．により、シナリオＭＬ中のイベントとレイアウトＭＬ中のイベントが紐付けされ、処理のタイミンクの同期がとられる。
・レイアウトＭＬ用スキンＭＬ
レイアウトＭＬに対する画面意匠を定義する。レイアウトＭＬ用スキンＭＬを差し替えることにより、同一の画面構成、画面遷移のままで画面意匠を変更することが可能となる。
・レイアウトＭＬ用リソースＭＬ
レイアウトＭＬに対するテキストリソースを定義する。レイアウトＭＬ用リソースＭＬを差し替えることにより、同一の画面構成、画面遷移のままで表示する文字を変更することが可能となる。（例：日本語→英語）
・ボイスＭＬ
本システムが提供するサウンドデバイス向けユーザインターフェイスの構成、音声による対話制御を定義する。
・ボイスＭＬ用Ｄ．Ｄ．
シナリオＭＬとボイスＭＬの、イベント及び変数の関連づけを定義する。ボイスＭＬ用Ｄ．Ｄ．により、シナリオＭＬ中の変数とボイスＭＬ中の変数がひも付けされ、デ−タが共有される。また、ボイスＭＬ用Ｄ．Ｄ．により、シナリＭＬ中のイベントとボイスＭＬ中のイベントが紐付けされ、処理のタイミングの同期がとられる。
・ボイスＭＬ用スキンＭＬ
ボイスＭＬに対する音声意匠を定義する。ボイスＭＬ用スキンＭＬを差し替えることにより、同一の対話内容のまま、声色を変更することが可能となる。
・ボイスＭＬ用リソースＭＬ
ボイスＭＬに対する発話内容を定義する。ボイスＭＬ用リソースＭＬを差し替えることにより同一の対話内容のまま、発話内容、及び認識辞書を変更することが可能となる。
・モデル用Ｄ．Ｄ．
シナリオＭＬとモデルの、インタフュースの関連づけを定義する。モデル用Ｄ．Ｄ．によりシナリオＭＬ中の変数とモデルに対するバラメタが紐づけされ、データが共有される。
・モデルＭＬ
モデルのインターフェイスや付加情報を定義する。
・デバイスＭＬ
本システムが利用可能なデバイス情報の出力形式を定義する。本定義は、本システムが内部で収集しているデバイスの情報を、サブシステム間で受渡しする際に用いる。
・メッセージＭＬ
本システムのサブシステム間、及びサブシステム内のコンポーネント間で情報を受渡しする際に用いる、ＸＭＬメッセージである。なお、コンポーネントについては後述するが、コンポーネントは、抽象概念系、実装系及び実体系の３層に構成した各サブシステムをいう。
・インデックスＭＬ
ＬＳｕＩがレイアウトＭＬ、スキンＭＬ、リソースＭＬに関し最適なＭＬを提供するために用いる判断材料を記述したものであり、ＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒｓ（後述））が列挙されている。
【００２９】
図３（ｂ）は、状態遷移の概念を示す図である。ＸＭＬを使用することにより、サービスやユーザインターフェイスを構成するデータに意味を持たせることが可能になる為、年次モデルや車種、グレ−ド等に応じた固有の拡張を加えることも可能となる。例えばユーザインターフェイスで一般的な「ボタン」を意味するデータが記述されている場合、ある車種ではこのデータはアイコンで表現されるが、異なる車種では３Ｄオブジェクトや、ハードスイッチにマッピングされる。
【００３０】
図３（ｂ）に示すように、レイアウトＭＬにより「画面Ａ」〜「画面Ｆ」の画面情報（意匠情報やリソース情報、配置情報）、及び各画面の遷移情報が記述される。同様に、シナリオＭＬにより状態遷移が記述され、ボイスＭＬにより対話遷移が記述される。これらの各ＸＭＬは、相互に情報のやり取りを行うことにより、相互関係を持つことが可能である。
【００３１】
図２（ｂ）に戻り、ＵＩリポジトリ１５は、サブシステム間で共有するオブジェクトのリファレンス（参照という場合がある）を格納している。シナリオ処理部１２は、システム本体が提供するサービス（シナリオ）を解釈／実行する。レイアウト部１３は、シナリオ処理部１２からの通知を受けて、画面遷移を記述したレイアウトＭＬを解釈し、グラフィック部１６と連携する。グラフィック部１６は、レイアウト部１３と連携し、ディスプレイやタッチパネルなどのグラフィックデバイスとやり取りを行うことによりユーザと対話を行う。ボイス部１７は、シナリオ処理部１２からの通知を受けて、音声対話を記述したボイスＭＬを読み込み、サウンド部１７と連携し、音声対話サービスを提供する。サウンド部１７は、音や音声の出力、音声の入力を受け付けるサービスを提供する。
【００３２】
続いて、本システムの実体系と抽象概念について説明する。図４は、抽象概念層、実装層及び実体層の関係を示す図である。本システムはプラットフォームに依存しない「抽象概念系」と、プラットフォームに依存する「実体層」、抽象概念系と実体層を繋ぐ「実装層」に分離され、これらが連携して機能を提供する。
【００３３】
抽象概念層では、主に、サービスを定義したシナリオＭＬ、画面構成／遷移を定義したレイアウトＭＬ、音声による対話制御を定義したボイスＭＬ等のＸＭＬファイルの解釈を行い、実装層を通じて実行時に必要なデータを実体層に渡す。
【００３４】
抽象概念層は、ＸＭＬファイル（シナリオＭＬ、レイアウトＭＬ、ボイスＭＬ）の解釈、実体層向けテー夕（実行時に用いるデータ）の送信、実体層からの依頼の受信及び対応する処理（ＸＭＬファイル取得、ＸＭＬL解釈等）等を行う。
【００３５】
実体層では抽象概念層から渡されたデータを保持し、それらと実デバイスを利用してサービスを提供する。プラットフォームに依存する部分であるため、実装方法はプラットフォームに応じて設計される。プラットフォームは例えば、車種やＰＣ（パソコン）などである。実体層は、抽象概念層へ依頼事項の送信（ＸＭＬファイル取得依頼、ＸＭＬ解釈依頼）を行う。
【００３６】
なお、実体層は、プラットフォームや機種に非依存であり、抽象概念層と実体層のインターフェイスとなる。また、以下では、抽象概念層、実装層及び実体層のメタデータをそれぞれ抽象概念系、実装系及び実体系という。
【００３７】
〔ＵＩリポジトリ〕
ＵＩリポジトリ１５について説明する。抽象概念系が実体系部のオブジェクトを指定する際にはＵＲＩを用いてオブジェクトの識別を行う。
【００３８】
ＵＩリポジトリ１５は、本システムの実体系コンポーネントが生成したオブジェクトのリファレンスを格納し、相互に情報のやり取りを行う為に利用するサブシステムである。
【００３９】
図５は、シナリオ処理部、レイアウト部、ボイス部の関係を示す図である。オブジュクトの生成元であるコンポーネントは、生成したオブジェクトのキーとなるＵＲＩと、そのオブジュクトのリファレンスを対応づけて格納しており、参照元のコンポーネントがＵＲＩをキーとしてオブジェクトのリファレンスを取り出す。
【００４０】
抽象概念系のコンポーネント間は、実体系に依存したオブジェクト（及びそのリファレンス）を送受しないため、実体系に依存していないＵＲＩを送受し、実体系のオブジェクトはＵＲＩに結び付けられたオブジェクトをＵＩリポジトリ１５から取り出し、相互に情報のやりとりを行う。
【００４１】
〔シナリオ処理部〕
シナリオ処理部１２は、システム本体が提供するサービス（シナリオ）を解釈／実行するものであり、システム本体から提供されるシナリオＭＬに従い、利用者へ適切なＨＭＩ（Ｈｕｍａｎ Ｉｎｔｅｒｆａｃｅ）サービスを提供する司令塔的役割を持つ、サブシステムである。
【００４２】
シナリオ処理部１２はレイアウト部１３、ボイス部１４と連携し、サービスを提供する。シナリオＭＬにはサービス全体の状態遷移を記述することができ、レイアウト部、ボイス部とＤ．Ｄ．に記述されたマッピング定義によって情報の共有、遷移の同期をとることができる。
【００４３】
実体世界では分散ＦＷの提供する共有変数機能を利用して情報が共有される。また、遷移に対しては分散ＦＷの提供するイベント管理機能を利用して同期がとられる。シナリオＭＬに記述された状態遷移では、サービスで用いる「アクション」と呼ばれるモデルと連携する役割を持ち、車載機が持つ他サービスとの連携を行う。具体的には、シナリオＭＬに実際にモデルの機能を呼び出すアクションを記述し、イベントの活性化等によってこのアクションを実行することでモデルの提供する機能を利用する。また、レイアウトＭＬやボイスＭＬからモデルの提供する機能を利用する場合、イベントを利用しアクションを呼び出すことでモデルとの連携を実現する。
【００４４】
〔レイアウト部〕
レイアウト部１３はシナリオ処理部１２からの通知を受けて、ユーザとの対話を行う為の画面遷移を記述したレイアウトＭＬを解釈し、グラフィック部１６と連携することにより利用者にユーザインタフュースを提供するサブシステムである。
【００４５】
レイアウト部１３は、グラフィック部１６を介して、実テバイスからのタッチパネルやエスカッションキー入力、実デバイスヘの画面出力を行う。レイアウトＭＬには画面構成と画面遷移を記述することができ、シナリオＭＬに記述されたシナリオの状態遷移とは、Ｄ．Ｄに記述されたマッピング定義によって情報の共有、遷移の同期をとることができる。実体世界では分散ＦＷの提供する共有変数機能を利用して情報が共有される。また、遷移に対しては分散ＦＷの提供するイベント管理機能を利して同期がとられる。
【００４６】
レイアウトＭＬに記述した画面表示中にナビ等のモデルの提供する機能を利用する場合は、シナリオＭＬに実際にモデルの機能を呼び出すアクションを記述し、イベントの活性化等によってこのアクションを実行することでモデルの提供する機能を利用する。
【００４７】
レイアウトＭＬに記述した画面遷移中に話す声対話等の音声変化を起こさせる場合は、ボイスＭＬに実際に音声対話アクション等のアクションを記述し、イベントの活性化等によってこのアクションを実行することでボイス部の提供する機能を利用する。また、レイアウトＭＬに記述した画面遷移中にナビ等のモデルの提供する機能を利用する場合は、シナリオＭＬに実際にモデルの機能を呼び出すアクンョンを記述し、イベントの活性化等によってこのアクションを実行することでモデルの提供する機能を利用する。また、ボタン押下時の効果音など一部の音出力に関しては、サウンド部と連携することにより高レスポンスを実現する。
【００４８】
〔グラフィック部〕
グラフィック部１６は基本的にレイアウト部１３と連携し、ディスプレイやタッチパネルなどのグラフィックデバイスとやり取りを行うことにより、ユーザと対話を行うサブシステムである。ただし、ナビ描画など一部はレイアウト部を経由しないサービスも存在する（ナビ描画の場合、プラグインによりナビモデルから直接描画を行うことによりサービスを提供する。）。
【００４９】
図６は、グラフィック部１６と、シナリオ処理部１２、サウンド部１７の関係を示す図である。グラフィック部１６はディスプレイやタッチパネル、エスカッションキーなどの実デバイスに対して画面の出力や表示内容に関連するイベント（ボタンウィジェットなど）入力を行うことが可能であり、これを行う為のインターフェイスを持つ。また、画面の出力に関して、様々な依頼元からの要求を調停する為の、排他制御や合成を行う機能（画面権管理）を持つ。
【００５０】
グラフィック部１６へはレイアウト部１３やサウンド部１７、描画クライアントと呼ばれるモデル群からの依頼を受け、画面の出力、表示に関連するイベントの入力を行う。
【００５１】
〔ボイス部〕
ボイス部１４は、ボイスＭＬを読み込み、ボイスＭＬ中に記述された音声対話サービスを提供するサブシステムである。
【００５２】
図５に戻り、ボイス部１４はサウンド部１７を介して、実デバイスからの音声の入力、実デバイスへの音声の出力を行う。ボイスＭＬには音声対話の状態遷移を記述することができ、シナリオＭＬに記述されたシナリオの状態遷移とは、Ｄ．Ｄ．に記述されたマッピング定義によって情報の共有、遷移の同期をとることができる。実体世界では分散ＦＷの提供する共有変数機能を利用して情報が共在される。また、遷移に対しては分散ＦＷの提供するイベント管理機能を利用して同期がとられる。
【００５３】
ボイスＭＬに記述した音声対話中に画面遷移等の画面変化を起こさせる場合は、レイアウトＭＬに実際に画面遷移アクションやアニメーション等のアクションを記述し、イベントの活性化等によってこのアクションを実行することでレイアウトの提供する機能を利用する。また、ボイスＭＬに記述した音声対話中にナビ等のモデルの提供する機能を利用する場合は、シナリオＭＬに実際にモデルの機能を呼び出すアクションを記述し、イベントの活性化等によってこのアクションを実行することでモデルの提供する機能を利用する。
【００５４】
〔サウンド部〕
サウンド部は音や音声の出力、音声の入力を受け付けるサービスを提供する・サブシステムである。
【００５５】
図７は、サウンド部１７と、ボイス部１４、グラフィック部１６の関係を示す図である。サウンド部１７はスピーカやマイクなどの実デバイスに対して音声の出力や入力を行うことが可能であり、これを行う為のインターフェイスを持つ。また、音の出力に対して、様々な依頼元からの要求を調停する為の、排他制御やミキシングを行う機能（音権管理）を持つ。
【００５６】
サウンド部１７へはボイス部１４やグラフィック部１６、Soundクライアントと呼ばれるモデル群からの依頼を受けて、音診／音声の出力、音声の入力を行う。
【００５７】
〔ＵＲＩ〕
ＵＲＩについて説明する。本システムではサブシステム間で共有する全てのリソースの「所在地」を示す方法としてＵＲＩを用いる。ＵＲＩは1つ1つのリソースに対して必ずコニークに割り当てられる。
【００５８】
本システム内でＵＲＩを割り当てて参照するリソースとしては以下の様なものが挙げられる。
（ｉ）シナリオＭＬ等のＸＭＬファイル
（ｉｉ）スキンＭＬに記述された画像ファイル等
（ｉｉｉ）シナリオＭＬ等をパースした結果生成されるインスタンス
（ｉｖ）システム起動時に生成されるデバイス等のインスタンス
（ｖ）分散ＦＷが提供する各種リモートサービス
図８は、ＵＩサーバ２０がＵＲＩを参照する概念図を示す。これらの列挙したリソースの内、（ｉ）（ｉｉ）のリソースは、コンテンツサーバ上に管理され、ＵＲＩを指定して参照、登録することができる。（ｉｉｉ）、（ｉｖ）、（ｖ）のリソースは分散ＦＷのロケーション管理上に管理され、そのインスタンスやサービスの参照を、ＵＲＩを指定して参照、登録することができる。
【００５９】
〔外部サブシステム〕
続いて、外部サブシステムの概要について説明する。外部サブシステムはＵＩサーバ２０と連携して動作する。図２（ｂ）に示したように、外部サブシステムの構成の一例を示す図である。外部サブシステムは、Ｃｏｎｔｅｎｔｓ Ｓｅｒｖｅｒ、Ｍｏｄｅｌ、Ｓｙｓｔｅｍ、分散ＦＷから構成される。
【００６０】
Ｍｏｄｅｌは、ＬＳｕＩ及びモデルを有する。分散ＦＷは、「ライフサイクル管理」、「ロケーション管理」、「デバイス管理」からなる管理サービス層、「車載ファシリティ」、「イベント管理」、「イベントＩＤ管理」とからなる基本サービス層により構成される。
【００６１】
ライフサイクル管理は、分散ＦＷ内で使用するサービスの起動方法やサービスの参照を、サービスリポジトリ管理するサービスである。各ＯＳにひとつずつ存在し、ロケーション管理より待機系サービスの起動要求があった場合にそのサービスを起動する。
【００６２】
ライフサイクル管理の持つ機能として、「ＳｅｒｖｉｃｅＣｏｎｆｉｇｕｒａｔｉｏｎ」による設定」、「サービスプロセス起動」、「デバイスの追加と削除」が挙げられる。
【００６３】
図９は、ロケーション管理とライフサイクル管理の概要を示す図である。本システムは、ライフサイクル管理の管理下にあるオブジェクトを利用することにより、オブジェクトのライフサイクル管理を分散ＦＷに委任する形とする。通常、ライフサイクル管理の存在は、分散ＦＷのロケーション管理に隠蔽されており、本システムからは意識しない。
【００６４】
ロケーション管理は、分散ＦＷで使用される、分散オブジェクトのオブジェクト参照の登録と検索機能を提供するサービスである。本システムは、ロケーション管理に対して、
・他プロセスから利用するコンポーネントのオブジュクト参照を登録ける。
・利用するコンポーネントのオブジェクト参照を問い合わせ、オブジュクド参照を取得する、
ことにより、サービス（オブジェクト）の実体の位置を意識しない形でサービスを提供・利用することが可能となる。また、オブジェクト参照を登録する際は、登録するオブジェクトのＵＲＩを、オブジェクト参照を取得する際のキーとして使用する。
【００６５】
デバイス管理は、車載多機能装置で使用されるデバイスの構成情報を提供するサービスである。提供されるデバイスの構成情報例は、例えば次のようになる。
全般： 対応座席位置（0 〜 9）
種類
（Graphic／Sound）
デバイスのＵＲＩ
デバイスの識別
接続先ホスト名
オープニング画面の表示の有無
画面： レイヤーＮｏ．
分割位置Ｎｏ．
本システムは、デバイス管理に対して、
・実デバイスの位置情報を問い合わせる。
【００６６】
・実デバイスのデバイス情報を問い合わせる。
ことにより、プラットフオームに依存する実デバイスの実体を隠蔽し、ボキャブラリデバイスと関連付けることが可能となる。
【００６７】
ボキャブラリデバイスとは、一般的に言われるＸＭＬのボキャブラリの他に、所定のイベントやデバイスのＸＭＬを要素化したボキャブラリである。本システムで単に「ボキャブラリ」と呼んだものは「所定のイベントやデバイスをＸＭＬの要素化したボキャブラリ」を指す。
【００６８】
ボキャブラリはＤＴＤ（Document Type Definition)として規定され、各ＸＭＬ規格に取り込まれて使用される。ＸＭＬ規格はボキャブラリを取り込むことにより、規定のイベント定義やデバイス定義を使用することができる様になる。
【００６９】
ボキャブラリは、プラットフォームに依存するイベントやデバイスを隠蔽し抽象化する為のものであり、
・外部イベントや一部の内部イベントの定義
・本システムが認識可能なデバイスの表現
・シナリオからモデルを呼び出す際に補足する例外の定義
を規定する。
【００７０】
イベント管理は、イベントのやり取りを行う際の、データ送受信、フィルタリングを行う。イベント管理では、イベントサーバを利用したＴＣＰ版と、マルチキャスト通信を利用したＵＤＰ版を混在して利用可能である。
【００７１】
ＵＩサーバ２０では、シナリオ・レイアウト・ボイス間で相互に利用するイベントに対し分散ＦＷのイベント管理へイベント登録／削除を行い、イベント管理とイベントの送受を行うことにより、分散環境下での動作が可能となる。
【００７２】
本システムはイベント管理に対して
・各‐サブシステム間で相互利用するイベントのコールバックを登録する
・各サブシステムの内部でのみ利用するイベントのコールバックを登録する
・ボキャブラリイベントのコールバックを登録する
・登録されたイベントが発生したことを通知する（イベントを活性化する）
ことにより、スレッド間、プロセス間、ホスト間であってもイベント通知を受けることが可能になる。また、イベントを登録する際は、登録するイベントのＵＲＩを、イベント通知を受ける際のキーとして使用する。
【００７３】
イベントＩＤ管理は、車載多機能装置で発生するイベントのＩＤ情報を提供する。提供されるイベント情報は、例えば次のようになる。
エスカッションスイッチ ： 「ボタン」押下
「日的地ボタン」押下
「現在地ボタン」押下
「ナビメニューボタン」押下
「ＴＶボタン」押下
車両情報 ： イルミネーションON
イルミネーションOFF
走行規制ＯＮ
走行規制ＯＦＦ
システム情報： 起動処理完了
終了処理完了
本システムはイベントＩＤ管理から、本システムの外部から通知されるプラットフォーム依存のイベントのＩＤを取得することにより、分散ＦＷのイベント管理と連携してプラットフォーム依存のイベントの通知を受信することが可能となる。受信したプラットフォーム依存のイベントはボキャブラリイベントとして本システム内で使用する。
【００７４】
車載ファシリティは、車載多機能装置で発生する走行規制ＯＮ／ＯＦＦやイルミネーンョンＯＮ／ＯＦＦ等の車両のイベントを通知する為のサービスである。提供される車両情報は、例えば次のようになる。
効果：イルミネーションＯＮ／ＯＦＦ
規制：走行規制ＯＮ／ＯＦＦ
本システムは、車載ファシリティが発生させるプラットフォーム依存のイベントを、分散ＦＷのイベント管理を通して受信する。受信したプラットフォーム依存のイベントはボキャブラリイベントとして本システム内で使用する。
【００７５】
モデルは、外部プログラムを定義したものである。本システムは、シナリオＭＬやレイアウトＭＬ等のＸＭＬ規格に記述できない複雑な処理を、外部のプログラムとして定義し、シナリオＭＬから呼び出すことができる。この外部プログラムをモデルと呼ぶ。
【００７６】
図１０は、モデルの概要を示す図である。シナリオＭＬにはモデル実体に関する情報は直接記述しない。図１０に示すように、シナリオＭＬには抽象的にモデルの名称、関数名、パラメータ名が定義され、関数の呼び出し記述に関しても、抽象名を使用して記述される。
【００７７】
これに対し、モデルの実体では、ＤＩＬ（Ｄｙｎａｍｉｃ Ｉｎｔｅｒｆａｃｅ Ｌａｎｇｕａｇｅ）と呼ばれる動的インターフェイス呼び出し用の定義言語を使用してモデルのインターフェイスを定義し、これに対応する本体処理を内部に定義する。
【００７８】
シナリオＭＬ中の抽象モデルと、モデル実体との関連付けは、モデル用Ｄ．Ｄ．に定義する。モデル用Ｄ．Ｄ．には、抽象モデル名に対する実体モデルのＵＲＩ、抽象関数名に対するモデル実体の関数名、モデル実体に渡すパラメータの並び順を記述する。
【００７９】
モデル実体は分散ＦＷの提供するロケ−ション管理に、実体モデルＵＲＩを基に自身の参照を登録する。このモデルの機能を利用するシナリオインスタンスは、ロケーション管理から実例モデルＵＲＩを基にモデル実体の参照を取得し、この参照に対して動的インターフェイス呼び出しを行う。
【００８０】
本システムはＬＳｕＩと呼ばれるサブシステムと連携することにより、その時のシチュエーション、利用者の趣味・嗜好に最適なユーザインターフェイスを提供することを実現する。
【００８１】
図１１がＬＳｕＩの機能概略を示す図である。図１１に示すようにＬＳｕＩの機能は、例えば次のようになる。
・シナリオ自動生成／実行指示
・レイアウト／スキン／言語リソースの最適化
・レイアウト／スキン／言語リソースの変更依頼
・個人情報取得
ＬＳｕＩのインスタンスは利用者1人に対して１個生成する。この為、ＬＳｕＩのインスタンスを生成する、より自立のコンポーネントが必要となる。
【００８２】
本システムとＬＳｕＩの間の通信はＬＳｕＩ連携部１１を介してメッセージＭＬを利用して行われる。ただし、ユーザの切替え機能等の、上位のコンポーネントから呼び出されるべき機能に関しては、シナリオ処理部からモデルを呼び出す上述した方法を用い、ＬＳｕＩの操作を行う方式である。
【００８３】
また、本システムは、コンテンツサーバと連携することにより、異なるホストや異なるプロセスからでも、ＸＭＬファイル、設定ファイル、画像ファイル、等の参照・編集を行うことができる。これらのファイルは統一的にＵＲＩによって指し示される。
【００８４】
図１２はコンテンツサーバの概要を示す図である。本システムの各サブシステムは、コンテンツサーバが提供するライブラリのＡＰＩを利用して、利用するファイルを参照・編集する。コンテンツサーバが提供するライブラリの、参照・編集するファイルへのアクセス方式については、本システムからは隠蔽されている。
【００８５】
以上説明したＵＩサーバ２０のサブシステム間、外部システムとＵＩサーバ２０とが通信することで、ライフシーンに適合したユーザインターフェイスを実現する。サブシステム間の通信について説明する。
【００８６】
本システム内のサブシステム間、及び外部システムと本システム間の通信方式は、大きくは「メッセージＭＬ通信」と「ＣＯＲＢＡ（Common Object Request Broker Architecture）通信」、「イベント」、「共有変数」の４つの方式に分類される。「ＣＯＲＢＡ」通信に関しては、更に「ＩＤＬ（（リモートインターフェイス呼び出し））、「ＤＩＬ（動的インターフェイス呼び出し）」、「ＣＬＬ（コマンドリスト通信）」に分類される。以下に、これらの通信方式の相互作用を記載する。
【００８７】
〔メッセージＭＬ通信〕
本システムの抽象概念系のコンポーネント間では、メッセージＭＬを媒体とする通信が行われる。通信するデータをＸＭＬ形式にすることにより、サブシステム間の関係を疎にしている。
【００８８】
抽象概念系のコンポーネントはメッセージＭＬを作成する処理を隠蔽する為に、実装系のインターフェイスを介して実体系のコンポーネントを使用して実際の処理を行わせる。なお、実体系のコンポーネントはコンテンツサーバ上にメッセージＭＬを生成する。
【００８９】
図１３は、メッセージＭＬ通信（リクエスト）にサブシステムＡからサブシステムＢへリクエストメッセージを送信する処理の概念を示す。サブシステムＡ抽象概念系は、実装系インターフェイスＡを介して、サブシステムＡ実体系にリクユスト内容のメッセージＭＬ生成を依頼する。
【００９０】
サブシステムＡ実体系はコンテンツサーバ上にメッセージＭＬを作成する（この一連の処理の中で、生成するメッセージＭＬはＵＲＩによって特定される）。サブシステムＡ抽象概念系は、実装系インターフェイスＡを介して、サブシステムＡ実体系に、リクエストメッセージの送信を依頼する。
【００９１】
サブシステムＡ実体系はサブシステムＢ実体系の参照を分散ＦＷのロケーション管理から取得し、ＩＤＬで既定された関数を使用して、リクエストメッセージを送信する（この時実際に送信されるのは生成されたメッセージＭＬのＵＲＩ）。
【００９２】
サブシステムＢ実体系は、リクエストメッセージを受け取ったことをサブシステムＢ抽象概念系に通知する。サブシステムＢ抽象概念系は、実装系のインターフェイスＢを介して、サブシステムＢ実体系に、メッセージＭＬの参照を依頼する。サブシステムＢ抽象概念系はメッセージＭＬの内容を基にリクエストメッセージに対応する処理を開始する。
【００９３】
図１４（ａ）（ｂ）は、図１３の処理の後、サブシステムＢからサブシステムＡにレスポンスメッセージを送信する処理の概念を示す図である。図１４（ａ）の処理は、レスポンスとして何らかのデータ（ＸＭＬ）を返す場合を、図１４（ｂ）の処理は、レスポンスとして戻り値等の簡略な文字列（即値）だけを返す場合を示す。
【００９４】
〔ＣＯＲＢＡ通信〕
本システムの実体系のコンポーネントは分散ＦＷ上に構築される為、実体系のコンポーネント間ではＣＯＲＢＡ通信が行われる。ＣＯＲＢＡ通信においては、一般的に使用される、ＩＤＬ（Ｉｎｔｅｒｆａｃｅ Ｄｅｆｉｎｉｔｉｏｎ Ｌａｎｇｕａｇｅ）を既定してリモートでインタフュースを呼び出す方式の他に、分散ＦＷ上で拡張される以下の方式が使用される。
・ＤＩＬに定義したインターフェイスを持つオブジェクトを生成し、クライアント側のスタブなしで動的にリモ−ト呼び出しする方式（動的インターフェイス呼び出し方式）
・ＣＬＬ（Ｃｏｍｍａｎｄ Ｌｉｓｔ Ｌａｎｇｕａｇｅ）に定義したコマンドを送受信、バッファリングするオブジェクトを生成し、コマンド呼び出し時の通信回数を削減する方式（コマンドリスト通信方式）
また、分散ＦＷの基本サービスとして提供される「イベント管理」機能や「共有変数」機能も、通信の代替手段として利用する。以下、ＩＤＬ、ＤＩＬ、ＣＬＬ、イベント、共有変数の5つの方式について説明する。
【００９５】
・ＩＤＬ（リモートインターフェイス呼び出し）
利用する機能のインターフェイスをＩＤＬに定義し、ＩＤＬから生成した「スタブ」と呼ばれる代理オブジェクトと、「スケルトン」と呼ばれるサーバオブジェクトが実際の通信を行う。スタブ又はスケルトンを利用する場合、スタブを利用する機能と、スケルトンを継承する実体オブジェクトを作成する。
【００９６】
この方式は、上述したメッセージＭＬ通信の方式における、実体系のコンポーネントが「メッセージ送受信ＩＤＬ」に規定されるインターフェイスに、リクエストやレスポンスを送信する部分でも使用され、本システムの実体系コンポーネントにおけるもっとも基本的な通信方式である。
【００９７】
開発時には、まずＩＤＬを規定し、ＩＤＬよりクライアント側のスタブと、サーバ側のスケルトンを生成する。サーバ側の開発者は、サーバ側のスケルトンを継承するＩＤＬの実体オブジェクトを作成し、クライアント側の開発者はＩＤＬの代理オブジェクトであるスタブを利用する機能を作成する。
【００９８】
実行時には、（異なるプロセスである場合）サーバ側のプロセスの起動時、または実体オブジュクトが利用されるより以前に、実体オブジュクトを生成し分散ＦＷのロケーション管理へ生成した実体オフジュクトの参照を登録する。
【００９９】
クライアントの利用側の機能は、分散ＦＷのロケーション管理から必要とする実体オブジェクトの参照を取得する。この時の実体オブジコクトを特定するキーとしてＵＲＩが用いられる。取得した参照に対して関数呼び出しを行うと、スタブはスケルトンの該当関数をリモードで呼び出す。
スケルトンは自身を継承する実体オブジェクトの該当関数を呼び出し、関数の実行結果をリモートでスタブに返す。クライアント側のプロセスはスタブから関数の実行結果を受け取る。また、以上の動作が同一プロセス内で行われる場合に限り、「ショートカット」と呼ばれる機能が働き、リモート呼び出しは行われない。これによってリモート呼び出しによる動作オーバヘットを削減する。以上の動作において、クライアントの利用者側の機能はリモート呼び出しが行われた事を一切認識しない。
【０１００】
図１５（ａ）は、分散ＦＷのロケーション管理へ生成した実体オフジュクトの参照を登録する処理のシーケンス図を示す。
Ｓ１．登録側であるサブシステムＡは、上述したように実体オブジュクト（サブシステムＡの実体）を生成する。
Ｓ２．サブシステムＡは、サブシステムＡの実体の参照（リファレンス）を取得する。
Ｓ３．サブシステムＡは、取得したサブシステムＡの実体の参照を分散ＦＷのロケーション管理に登録する。これにより、ロケーション管理からサブシステムＡのＵＲＩを取得できることとなる。
【０１０１】
図１５（ｂ）は、ＩＤＬ呼び出しのシーケンス図を示す。
Ｓ１．サブシステムＢは、分散ＦＷのロケーション管理から必要とする実体オブジェクトの参照を取得する。
Ｓ２．サブシステムＢは、取得したＵＲＩに対して関数を呼び出す。
Ｓ３．上述したようにサブシステムＢのスタブ及びサブシステムＡのスケルトンにより、サブシステムＡの関数が実行される。
Ｓ４．サブシステムＢは、関数の実行結果を受信する。
【０１０２】
・ＤＩＬ（動的インターフェイス呼び出し）
図１６は動的インターフェイス呼び出し時におけるＣＯＲＢＡ通信の概念を示す図である。基本的な流れはＩＤＬの場合と同様であるが、利用する機能のインターフェイスが規定できない為、以下に挙げる点に違いがある。
・呼び出す関数名やパラメータに関する情報は、外部から動的に与えられる。
・ＩＤＬコンパイルと同様にＤＩＬコンパイルを実行しても、クライアント側のスタブは動的に生成されない。
【０１０３】
ＤＩＬスタブは分散ＦＷの機能として提供される。この方式は、シナリオＭＬやモデル用Ｄ．Ｄ．内に動的に定義されるモデルの情報を元に、実際に利用するモデル実体を紐付ける際に使用される。
【０１０４】
図１７は、ＤＩＬ呼び出しのシーケンス図を示す。
Ｓ１．サブシステムＢは、分散ＦＷのロケーション管理から必要とする実体オブジェクトの参照を取得する。
Ｓ２１〜２ｎ．サブシステムＢは、モデル実体が受け取るパラメータを順番に設定する。
Ｓ３．サブシステムＢは、最後にｉｎｖｏｋｅ（発動）により関数を呼び出す。
Ｓ４．サブシステムＢのスタブ及びサブシステムＡのスケルトンにより、サブシステムＡの関数が実行される。
Ｓ５．サブシステムＢは、関数の実行結果を受信する。
【０１０５】
・ＣＬＬ（コマンドリスト通信）
基本的な流れはＩＤＬの場合と同様であるが、通信によるオーバヘッドを削減する為に、利用する機能のリモート呼び出し回数を削減する点においてＩＤＬの場合と異なる。
【０１０６】
図１８はコマンドリスト通信におけるＣＯＲＢＡ通信の概念を示す図である。この方式は、レイアウト部１３とグラフィック部１６の間の様に、明らかにリモート呼び出しが発生し、かつ性能が要求される箇所に使用される。
【０１０７】
図１９（ａ）は、ＣＬＬ呼び出しのシーケンス図を示す。
Ｓ１．サブシステムＢは、分散ＦＷのロケーション管理から必要とする実体オブジェクトの参照を取得する。
Ｓ２１〜２ｎ．サブシステムＢは、サブシステムＡに実行を依頼するコマンドを順番に登録する。
Ｓ３．サブシステムＢは、最後にｆｌｕｓｈにより一連のコマンドをロケーション管理に発動する。リスト化されたコマンドが１回の通信でサブシステムＡに送信される。
Ｓ４１〜４ｎ．ロケーション管理は、コマンドの実行をサブシステムＡに依頼する。サブシステムＡは、一連のコマンドを順に実行する。
Ｓ５．サブシステムＢは、コマンドの実行結果を受信する。
【０１０８】
・イベント
イベントによる通信は、両面に表示されたボタンが選択された際に発生させる様な画面系のイベントや、音声認識時に発生させる様な音声系のイベント以外にも、シナリオから呼び出したモデルの実行完了通知や、走行規制のＯＮ／ＯＦＦの通知に利用される。
【０１０９】
図２０はイベント通信の概念を示す図である。イベント受信側は分散ＦＷのイベント管理機能に対して、イベントの識別子となるイベントＵＲＩに対してコールバック関数の登録を行う。分散ＦＷのイベント管理機能は、イベントの発信側から指定されたイベントＵＲＩのイベントの活性化依頼を受けると、登録されたコールバック開放を呼び出す。イベントの受信側は、コ−ルバック関数内にイベントに対応する処理を定義することにより、イベントハンドリングが実現される。
【０１１０】
図１９（ｂ）は、イベントコールバックのシーケンス図を示す。
Ｓ１．イベントを受信したサブシステムＡは、イベント管理にイベント（コールバック）の登録を行う。
Ｓ２．サブシステムＡは、イベントＵＲＩをサブシステムＢに活性化してほしいイベントのＵＲＩを所定の方法で通知する。
Ｓ３．イベントＵＲＩを通知されたサブシステムＢは、イベント管理部にイベントを活性化を依頼する。
Ｓ４．イベント管理部は、サブシステムＡのコールバックを呼び出す。コ−ルバック関数内にイベントに対応する処理を定義することにより、イベントハンドリングが実現される。
【０１１１】
・共有変数
共有変数を用いた通信は、サブシステム間で共有すべきデータを、専用の領域に保持して共有する。この方式は、シナリオＭＬ内に定義された変数の値や、モデルのアウトプットとして得られるデータを、レイアウトＭＬやボイスＭＬ内で使用する場合、シナリオＭＬと長時間にわたってデータを共有する場合等に使用される。
【０１１２】
図２１は、共有変数による通信の概念を示す図である。
共有変数の生成者は、分散ＦＷが提供する共有変数の生成関数を利用して共有変数の実体を生成する。この時、実体と共にその参照を得る。生成者はこの参照と変数の識別子（ＵＲＩ）をＵＩリポジトリ１５に登録する。本システム内では、ＵＩリポジトリ１５から共有変数の参照を得ることによって、共有変数の参照、登録を行うことができる。
【０１１３】
この為、共有変数を参照する場合は、まずＵＩリポジトリから変数ＵＲＩを指定し、共有変数の参照を取得し、この参照を基に共有変数の値を参照する。また共有変数を更新する場合も同様に、ＵＩリポジトリ１５から得た共有変数の参照に対して、値の更新を行う。
【０１１４】
共有変数では、必要に応じて、その値を更新した時に更新イベントを発生させることができる。この更新イベントは分散ＦＷのイベント管理の機能を利用して発生させている。コールバックを登録するとによって、共有変数の値が更新された時の通知を受ける。
【０１１５】
ＵＩリポジトリ１５は、共有変数の参照と、変数ＵＲＩを関連づける為に必要であり、本システムの共通コンポーネントとして提供される。
【０１１６】
続いて、以上の構成を用いて、サブシステム間及び外部システムとの基本相互作用について、システム起動、シナリオパース、認証画面表示及びユーザ認証完了の場合をそれぞれ説明する。
【０１１７】
〔システム起動〕
図２２は、システムの起動におけるサブシステム間及び外部システムとの基本相互作用を示す図である。図２２の数字は以下の数字と対応している。
１．下位ＰＦから分散ＦＷのライフサイクル管理が起動される。
２．分散ＦＷのライフサイクル管理から本システムと外部サブシステムのプロセスが起動される。
【０１１８】
２−１．ライフサイクル管理から分散ＦＷのその他のサブシステムや、関連するモデル等のシステムが起動される。
【０１１９】
２−２ グラフィック部１６のプロセスが起動される。
【０１２０】
２−３ サウンド部１７のプロセスが起動され、起動したことをグラフィック部１６に通知する。グラフィック部１６はこのプロセス起動通知を受けて、サウンド部１７へ起動効果音の出力を依頼し、起動画面を出力する。サウンド部１７はグラフィック部１６から起動効果音出力依頼を受けて起動効果音を出力する。
【０１２１】
２−４ ＵＩリポジトリのプロセスが起動される。
【０１２２】
２−５ シナリオ処理部のプロセスが起動される。
【０１２３】
２−６ レイアウト部１３のプロセスが起動される。
【０１２４】
２−７ ボイス部１４のプロセスが起動される。
【０１２５】
２−８ ＬＳｕＩのプロセスが起動される。
３．ＬＳｕＩはユーザ認証用のＬＳｕＩインスタンスを生成し、シナリオ処理部１２、レイアウト部１３、ボイス部１４へ、生成したＬＳｕＩインスタンス向けの初期化要求を送信する。
４．ＬＳｕＩインスタンスからシナリオ処理部１２へ、起動直後に実行されるシナリオＭＬを提供する。
【０１２６】
図２３は、システム起動のシーケンス図を示す。
Ｓ１．まず、本システムにプラットフォームから起動が通知される（例えば、ＡＣＣオン）。
Ｓ２．ＵＩサーバ２０（本システム）はグラフィック部１６を起動する。
Ｓ３．ＵＩサーバ２０はサウンド部１７を起動する。グラフィック部１６、サウンド部１７は、起動画面の表示や起動時の効果音出力を行うため、グラフィック部１６とサウンド部１７は本システムの中で最初に起動される。
Ｓ４．ＵＩサーバ２０はＵＩリポジトリ１５を起動する。
Ｓ５．ＵＩサーバ２０はシナリオ処理部１２を起動する。
Ｓ６．ＵＩサーバ２０はレイアウト部１３を起動する。
Ｓ７．ＵＩサーバ２０はボイス部１４を起動する。
Ｓ８．ＵＩサーバ２０はＬＳｕＩを起動する。ＵＩサーバ２０は、ユーザ認証用ＬＳｕＩインスタンスを生成し、専用のシナリオエンジン、レイアウトエンジン等のインスタンスを生成する。
Ｓ９．ＬＳｕＩインスタンスは、ＬＳｕＩインスタンスのＵＲＩをもって、シナリオ処理部１２の初期化を要求する。
Ｓ１０．シナリオ処理部１２は、ＬＳｕＩインスタンス専用のシナリオエンジンインスタンスを生成する。
Ｓ１１．ＬＳｕＩインスタンスは、ＬＳｕＩインスタンスのＵＲＩをもって、レイアウト部１３の初期化を要求する。
Ｓ１２．レイアウト部１３は、ＬＳｕＩインスタンス専用のレイアウトエンジンインスタンスを生成する。
Ｓ１３．ＬＳｕＩインスタンスは、ＬＳｕＩインスタンスのＵＲＩをもって、ボイス部１４の初期化を要求する。
Ｓ１４．ボイス部１４は、ＬＳｕＩインスタンス専用のボイスエンジンインスタンスを生成する。
Ｓ１５．ＬＳｕＩインスタンスは、シナリオＭＬのＵＲＩ、各種Ｄ．Ｄ．のＵＲＩをもって、シナリオ処理部にシナリオの起動を依頼する。
【０１２７】
〔シナリオパース〕
図２４は、シナリオパースにおけるサブシステム間及び外部システムとの基本相互作用を示す図である。
１．ＬＳｕＩインスタンスから起勤直後に実行されるシナリオのシナリオＭＬがシナリオ処理部に提供される。
２．シナリオオ処理部１２は提供されたシナリオＭＬに対して、マッピング情報を記載されたＤ．Ｄ．をレイアウト部１３、ボイス部１４に渡す。
３．シナリオ処理部１２は提供されたシナリオＭＬを解釈する。
【０１２８】
３−１ 読み込んだ変数の定義に対してＵＩリポジトリに共有変数を登録する。
【０１２９】
３−２ 読み込んだ変数の定義に対しでマッピング情報としてレイアウト部１３、ボイス部１４に渡す。
【０１３０】
３−３ 読み込んだイベントの定義に対してマッピング情報としてレイアウト部１３、ボイス部１４に渡す。
４．シナリオ処理部１２は解釈が完了した旨をＬＳｕＩインスタンスに通知する。
５．シナリオ処理部１２はシナリオＭＬを解釈した結果を元に状態遷移を開始する（シナリオを実行する。）。
【０１３１】
図２５は、シナリオパースのシーケンス図を示す。
Ｓ１．ＬＳｕＩはシナリオの起動をシナリオ処理部１２に依頼する。ここでは、ＬＳｕＩはユーザ認証シナリオのＵＲＩ、各種Ｄ．Ｄ．のＵＲＩをシナリオ処理部１２に送信する。
Ｓ２．シナリオ処理部１２はシナリオインスタンスを生成する。
Ｓ３．シナリオ処理部１２はレスポンスメッセージとしてシナリオインスタンスのＵＲＩをＬＳｕＩに送信する。
Ｓ４．シナリオインスタンスは、レイアウトＭＬ用のＤ．Ｄ．のＵＲＩをレイアウト部１３に通知する。レイアウト部１３は、Ｄ．Ｄ．マッピング解決のために情報を保持しておく。
Ｓ５．シナリオインスタンスは、ボイスＭＬ用のＤ．Ｄ．のＵＲＩをボイス部１４に通知する。ボイス部１４は、Ｄ．Ｄ．マッピング解決のために情報を保持しておく。
Ｓ６．レイアウト部１３はＤ．Ｄ．をパースする。
Ｓ７．ボイス部１４はＤ．Ｄ．をパースする。
Ｓ８．レイアウト部１３とボイス部１４はレスポンスをシナリオインスタンスに返す。
Ｓ９．シナリオインスタンスは、シナリオＭＬをパースする。
Ｓ１０．シナリオインスタンスは、リソースＭＬを取得するため、リソースインデックスのＵＲＩをＬＳｕＩに送信する。
Ｓ１１．ＬＳｕＩは、レスポンスメッセージとしてリソースＭＬのＵＲＩをシナリオインスタンスに送信する。
Ｓ１２．シナリオインスタンスは、ＵＩリポジトリ１５に変数（変数ＵＲＩ、共有変数識別子）を登録する。
Ｓ１３．シナリオインスタンスは、イベントマッピングの通知としてイベント名とＵＲＩのリストをレイアウト部１３に送信する。レイアウト部１３は、Ｄ．Ｄ．マッピング解決のために情報を保持しておく。
Ｓ１４．シナリオインスタンスは、イベントマッピングの通知としてイベント名とＵＲＩのリストをボイス部１４に送信する。ボイス部１４は、Ｄ．Ｄ．マッピング解決のために情報を保持しておく。
Ｓ１５．レイアウト部１３とボイス部１４はレスポンスをシナリオインスタンスに返す。
Ｓ１６．シナリオインスタンスは、変数マッピングの通知として変数名とＵＲＩのリストをレイアウト部１３に送信する。レイアウト部１３は、Ｄ．Ｄ．マッピング解決のために情報を保持しておく。
Ｓ１７．シナリオインスタンスは、変数マッピングの通知として変数名とＵＲＩのリストをボイス部１４に送信する。ボイス部１４は、Ｄ．Ｄ．マッピング解決のために情報を保持しておく。
Ｓ１８．レイアウト部１３とボイス部１４はレスポンスをシナリオインスタンスに返す。
Ｓ１９．シナリオインスタンスは状態遷移を登録する。
Ｓ２０．シナリオインスタンスは、シナリオ起動の完了としてシナリオインスタンスＵＲＩをＬＳｕＩに送信する。
Ｓ２１．ＬＳｕＩはレスポンスをシナリオインスタンスに送信する。
Ｓ２２．シナリオインスタンスは、状態遷移を開始する。
【０１３２】
〔認証画面表示〕
図２６は、認証画面表示におけるサブシステム間及び外部システムとの基本相互作用を示す図である。
【０１３３】
シナリオが実行された以後、状態の初期（entry）アクションや、イベントに対応するアクションとしてcreateLayout（指定されたレイアウトを生成する要素）が実行された場合に、レイアウトMLの解釈・実行が行われる。
１．シナリオ処理部１２はシナリオを実行する。
２．シナリオ処理部１２はcreateLayoutアクションを実行する。
３．シナリオ処理部１２はレイアウト部１３に対してcreateLayoutアクションが実行された旨を通知する。
４．レイアウト部１３はメッセージＭＬを解釈し、ＬＳｕＩインスタンスにレイアウトＭＬの最適化を依頼する（シナリオ処理部１２が通知したメッセージＭＬに指定されているレイアウトインデックスをＬＳｕＩに渡す。）。
【０１３４】
ＬＳｕＩインスタンスは、レイアウトインデックスの中に記述されたレイアウトＭＬの内、最適なレイアウトＭＬを選定し、そのＵＲＩをレイアウト部１３に通知する。
５．レイアウト部１３はレイアウトＭＬを解釈する。
【０１３５】
５−１ レイアウト部１３はＬＳｕＩインスタンスにスキンＭＬとリソースＭＬの最適化を依頼する（レイアウトＭＬに指定されているスキンインデックスとリソースインデックスをＬＳｕＩに渡す。）。
【０１３６】
ＬＳｕＩインスタンスはスキンインデックスとリソースインデックスの中に記述されたスキンＭＬとリソースＭＬの内、最適なスキンＭＬとリソースＭＬを選定し、そのＵＲＩをレイアウト部１３に通知する。
【０１３７】
５−２ レイアウト部１３はスキンＭＬとリソースＭＬを解釈する。
【０１３８】
５−３ レイアウト部１３はレイアウトＭＬ中のスタイルにスキンＭＬの内容を、リソースにリソースＭＬの内容を、マッピングされる変数・イベントに「シナリオパース」時にシナリオ処理部１２から渡されたマッピング情報を充て込む。
６．レイアウト部１３はレイアウトＭＬの解釈が完了すると、シナリオ処理部１２に対して、解釈が完了したことを通知する（メッセージＭＬ通信を利用して、ボキャブラリイベントとして通知する。）。
７．レイアウト部１３はレイアウトＭＬを解釈した結果を元に状態遷移を開始する（レイアウトを実行する。）。
【０１３９】
レイアウトが実行された以後、すぐには画面上に表示されない。レイアウトは画面表示用の何らかのイベントを受け取った後に始めて画面を表示する（実際にはシナリオＭＬ上の何らかのイベントと、レイアウトＭＬ上の画面表示用のイベントがマッピングされていて、このマッピングされたイベントが図２８に示すように活性化されることにより、画面が表示される。）。
８．シナリオ処理部１２は画面表示イベントを活性化するアクションを実行する。
９．画面表示イベントがレイアウト部１３に通知される。
１０．レイアウト部１３は通知されたイベントに対して対応するアクションを実行する。 この場合はシーン切替えを行う。
１１．レイアウト部１３は切替えられたシーンに対応する描画コマンドを生成し、グラフィック部１６に送信する。
１２．グラフィック部１６は描画コマンドを解釈し、物理デバイスに描画する。
【０１４０】
図２７は認証画面表示のシーケンス図を示す。
Ｓ１．シナリオ処理部１２はレイアウトの生成をレイアウト部１３に依頼する。シナリオ処理部１２はレイアウト識別名、レイアウトインデックスのＵＲＩ、デバイスのＵＲＩ、レイアウトインスタンスのＵＲＩを、レイアウト部１３に送信する。
Ｓ２．レイアウト部１３は、レイアウトＭＬの取得するため、ＬＳｕＩにレイアウトインデックスのＵＲＩを送信する。
Ｓ３．ＬＳｕＩは、レスポンスとしてレイアウトＭＬのＵＲＩをレイアウト部１３に送信する。
Ｓ４．レイアウト部１３は、レイアウトＭＬをパースする。なお、パースはレイアウト生成のパラメータである「デバイスＵＲＩ」の数だけ繰り返す。
Ｓ５．レイアウト部１３は、スキンＭＬを取得するためスキンインデックスのＵＲＩをＬＳｕＩに送信する。
Ｓ６．ＬＳｕＩはレスポンスとしてスキンＭＬのＵＲＩをレイアウト部１３に送信する。
Ｓ７．レイアウト部１３は、リソースＭＬを取得するためリソースインデックスのＵＲＩをＬＳｕＩに送信する。
Ｓ８．ＬＳｕＩはレスポンスとしてリソースＭＬのＵＲＩをレイアウト部１３に送信する。
Ｓ９．レイアウト部１３はレイアウトインスタンスを生成する。
Ｓ１０．レイアウトインスタンスは、各種の設定を行う。
Ｓ１１．レイアウト部１３はイベントを活性化するため、レイアウト生成完了イベントＵＲＩ、レイアウトインスタンスのＵＲＩをシナリオ処理部１２に送信する。シナリオ処理部１２は、レイアウトインスタンスのＵＲＩがレイアウト生成時にパラメータ指定していたＵＲＩであれば、画面表示開始イベントを活性化する。なお、ボイス部との同期が必要であれば、シナリオＭＬの記述において条件判定が行われる。
Ｓ１２．シナリオ処理部１２はイベントを活性化する。すなわち、画面表示を開始する。
Ｓ１３．シナリオ処理部１２はレイアウト部１３にイベントを通知する。
Ｓ１４．レイアウト部１３は、グラフィック部１６にイベントを通知する。
Ｓ１５．グラフィック部１６は、シーングラフを生成すると共に描画し、実デバイスに描画する。
【０１４１】
〔ユーザ認証＆シナリオ切り替え〕
図２８は、ユーザ認証及びシナリオ切り替えにおけるサブシステム間及び外部システムとの基本相互作用を示す図である。
【０１４２】
シナリオが実行された以後、利用者からタッチパネル等を通じて、ユーザ認証のイベントが発生した場合、このイベントを受けてユーザ切替えのモデルが実行される。
１．タッチパネル上のボタンのタッチ信号がデバイスドライバ等からグラフィック部１６に通知される。
２．グラフィック部１６はＰＦ依存の形式でレイアウト部１３にボタン押下イベントを通知する。
３．レイアウト部１３はグラフィック部１６からのイベント通知を受けて、マッピングされたユーザ認証イベントを活性化する。
４．シナリオ処理部１２にユーザ認証イベントが通知される。この時、イベントがマッピングされていなければレイアウト部１２、ボイス部１４には通知されない。
５．シナリオ処理部１２はユーザ認証イベントを受けて、イベントに対応するアクションとしてcal1Modelアクションを実行する（この場合はＬＳｕＩモデルのユーザ切替え処理）。
【０１４３】
ＬＳｕＩモデルのユーザ切替え処理が実行され、切替わったユーザ用に新しくＬＳｕＩインスタンスが生成される（以降の説明では、切り替わる前のＬＳｕＩインスタンスを「旧ＬＳｕＩインスタンス」、切替わった後のＬＳｕＩインスタンスを「新ＬＳｕＩインスタンス」と称する）。
【０１４４】
新ＬＳｕＩインスタンスモデルの処理依頼でシナリオが切替わり、旧ＬＳｕＩインスタンスが実行したシナリオが破棄され、ＬＳｕＩインスタンスが破棄される。図２９は元のシナリオを破棄する場合のサブシステム間及び外部システムとの基本相互作用を示す図である。
６．ＬＳｕＩモデルは認証されたユーザ用に新ＬＳｕＩインスタンスを生成し、シナリオ処理部１２、レイアウト部１３、ボイス部１４へ新ＬＳｕＩインスタンス向けの初期化要求を送信する。
７．新ＬＳｕＩインスタンスは認証されたユーザ用に、シナリオ処理部１２に対して新しいシナリオを提供する。以降の処理は、シナリオパースと同じであるため省略する。
８．旧ＬＳｕＩインスタンスは、目身が実行していたシナリオの破棄を、シナリオ処理部１２に対して要求する。
９．シナリオ処理部１２は、旧ＬＳｕＩインスタンスのシナリオ破棄要求に対して、レイアウト部１３とボイス部１４にシナリオ破棄要求を送信する。シナリオ処理部１２、レイアウト部１３、ボイス部１４はそれぞれ指定されたシナリオに関連するリソースを解放する。
１０．旧ＬＳｕＩインスタンスは、シナリオ処理部１２、レイアウト部１３、ボイス部１４に対し、自身が初期化したリソースの解放を依頼する。
【０１４５】
図３０は、ユーザ認証とシナリオ切り替えのシーケンス図を示す。
Ｓ１．グラフィック部１６は、イベント通知として選択されたボタンをレイアウト部１３に送信する。
Ｓ２．レイアウト部１３は、ユーザ認証イベントの活性化をイベント管理に依頼する。
Ｓ３．イベント管理は、ユーザ認証イベントの活性化をシナリオ処理部１２に通知する。
Ｓ４．シナリオ処理部１２は、ＬＳｕＩから関数（認証、ユーザＩＤ等）を呼び出す。ＬＳｕＩは、ユーザ認証を行い、選択されたユーザ用ＬＳｕＩインスタンスを生成する。
Ｓ５．ユーザ用ＬＳｕＩインスタンスは、ＬＳｕＩインスタンスのＵＲＩを通知して、シナリオ処理部１２に初期化を要求する。
Ｓ６．ユーザ用ＬＳｕＩインスタンスは、ＬＳｕＩインスタンスのＵＲＩを通知して、レイアウト部１３に初期化を要求する。
Ｓ７．ユーザ用ＬＳｕＩインスタンスは、ＬＳｕＩインスタンスのＵＲＩを通知して、ボイス部１３に初期化を要求する。
Ｓ８．ユーザ用ＬＳｕＩインスタンスは、シナリオＭＬのＵＲＩ、各種Ｄ．Ｄ．のＵＲＩを通知して、シナリオ処理部１２にシナリオの起動を依頼する。
Ｓ９．ＬＳｕＩモデルのユーザ切り替え処理が実行されると、旧ＬＳｕＩインスタンスが破棄され、新ＬＳｕＩインスタンスが生成される。新ＬＳｕＩインスタンスは、シナリオインスタンスのＵＲＩを通知して、シナリオ処理部１２にシナリオの破棄を依頼する。
Ｓ１０．シナリオ処理部１２は、シナリオインスタンスのＵＲＩを通知して、レイアウト部にシナリオを破棄を依頼する。
Ｓ１１．シナリオ処理部１２は、シナリオインスタンスのＵＲＩを通知して、ボイス部にシナリオを破棄を依頼する。
Ｓ１２．シナリオ処理部１２は、レスポンスをＬＳｕＩに送信する。
【０１４６】
〔画面切り替え〕
続いて画面の切替について説明する。画面切替えの相互作用は切替えの方式に応じて以下の４パターンが存在する。
・レイアウト部１３の内部で切替えが完結する。
・スキンＭＬ（またはリソースＭＬ）が切り替わる。
・レイアウトＭＬが切り替わる。
・シナリオＭＬが切り替わる。
【０１４７】
・レイアウト部１３の内部での切り替え
図３１は、レイアウト部１３の内部で画面切替えが行われる場合の相互作用の概略を示す図である。
１．タッチパネル上のボタンのタッチ信号がデバイスドライバ等からグラフィック部１６に通知される。
２．グラフィック部１６はプラットフォーム依存の形式でレイアウト部１３にボタン押下イベントを通知する。これと同時にグラフィック部１６はサウンド部１７にボタン押下に対応する効果音の出力を依頼し、サウンド部１７はスピーカに効果音を出力する。
３．レイアウト部１３はグラフィック部１６からのイベント通知を受けて、対応するアクション（この場合は画面切替え）を実行し、切り替えられた画面に対応する描画コマンドを生成し、グラフィック部１６に送信する。
４．グラフィック部１６は描画コマンドを解釈し、物理デバイスに描画する。
【０１４８】
図３２は、レイアウト部の内部における画面切り替えのシーケンス図を示す。
Ｓ１．タッチパネル上のボタンのタッチ信号がデバイスドライバ等からグラフィック部１６に通知される。
Ｓ２．グラフィック部１６は、プラットフォーム依存の形式でレイアウト部１３にボタン押下イベントを通知する。
Ｓ３．グラフィック部１６は、サウンド部１７に効果音の出力を依頼する。
Ｓ４．サウンド部１７は、スピーカから効果音を出力する。
Ｓ５．レイアウト部１３は、画面の切り替えを実行する。
Ｓ６．レイアウト部１３は、切り替えられた描画に対応する描画コマンドをグラフィック部１６に送信する。
Ｓ７．グラフィック部１６は、描画コマンドを解釈しタッチパネルディスプレイを描画する。
【０１４９】
・スキンＭＬ又はリソースＭＬの切り替え
図３３は、スキンＭＬが切り替わる相互作用の概略を示す図である。なお、リソースＭＬの切り替えは、スキンＭＬと同じであるので説明は省略する。
１．タッチパネル上のボタンのタッチ信号がデバイスドライバ等からグラフィック部１６に通知される。
２．グラフィック部１６は、ＰＦ依存の形式でレイアウト部１３にボタン押下イベントを通知する。これと同時にグラフィック部１６はサウンド部１７にボタン押下に対応する効果音の出力を依頼し、サウンド部１７はスピーカに効果音を出力する。
３．レイアウト部１３はグラフィック部１６からのイベント通知を受けて、対応するアクション（この場合はスキンＭＬ切替えイベントの活性化）を実行し、スキンＭＬ切り替えイベントを活性化する。
４．活性化されたスキンＭＬ切替えイベントがシナリオ処理部１２に通知される。
５．シナリオ処理部１２はスキンＭＬ切替えイベントを受けて、対応するアクション（この場合はモデル呼び出し）を実行し、ＬＳｕＩ（モデル）にスキンＭＬ切替え依頼を行う。
６．ＬＳｕＩ（モデル）はスキンＭＬ切替え依頼に応じて、レイアウト部１３にスキンＭＬ切替え依頼メッセージを送信する。
７．レイアウト部１３はスキンＭＬ切替え依頼メッセージを受信し、ＬＳｕＩにスキンＭＬの最適化を依頼する（レイアウトＭＬに指定されているスキンインデックスとリソースインデックスをＬＳｕＩに渡す。）。
８．ＬＳｕＩはスキンインテックスの中に記述されたスキンＭＬの内、最適なスキンＭＬを選定し、そのＵＲＩをレイアウト部１３に通知する。
９．レイアウト部１３はスキンＭＬを解釈し、レイアウトＭＬ中のスタイルにスキンＭＬの内容を再度充て込む。
１０．レイアウト部１３は現在表示中の画面に対応する描画コマンドを生成し、グラフィック部１６に送信する。
１１．グラフィック部１６は描画コマンドを解釈し、物理デバイスに描画する。
【０１５０】
図３４は、スキンＭＬの画面切り替えのシーケンス図を示す。
Ｓ１．タッチパネル上のボタンのタッチ信号がデバイスドライバ等からグラフィック部１６に入力される。
Ｓ２．グラフィック部１６は、ＰＦ依存の形式でレイアウト部１３にボタン押下イベントを通知する。効果音の出力についてはレイアウト内部の画面切り替えと同様である。
Ｓ３．レイアウト部１３はスキンＭＬ切替えイベントを活性化し、シナリオ処理部１２に通知する。
Ｓ４．シナリオ処理部１２はスキンＭＬ切替えイベントの通知を受けて、モデル呼び出しを実行する。
Ｓ５．また、シナリオ処理部１２は、ＬＳｕＩ（モデル）にスキンＭＬ切替えを依頼する。
Ｓ６．ＬＳｕＩは、スキンＭＬ切替え依頼に応じて、レイアウト部１３にスキンＭＬ切替え依頼メッセージを送信する。
Ｓ７．レイアウト部１３は、スキンＭＬをＬＳｕＩに問い合わせる。
Ｓ８．ＬＳｕＩは、スキンＭＬの内、最適なスキンＭＬを選定し、そのＵＲＩをレイアウト部１３に通知する。
Ｓ９．レイアウト部１３はスキンＭＬを解釈し、レイアウトＭＬ中のスタイルにスキンＭＬの内容を再度充て込む。
Ｓ１０．レイアウト部１３は現在表示中の画面に対応する描画コマンドを生成し、グラフィック部１６に送信する。
Ｓ１１．グラフィック部１６は描画コマンドを解釈し、タッチパネルディスプレイに描画する。
【０１５１】
・レイアウトＭＬの切り替え
図３５は、レイアウトＭＬが切り替わる相互作用の概略を示す図である。
１．タッチパネル上のボタンのタッチ信号がデバイスドライバ等からグラフィック部に通知される。
２．グラフィック部１６はＰＦ依存の形式でレイアウト部１３にボタン押下イベントを通知する。これと同時にグラフィック部１６はサウンド部１７にボタン押下に対応する効果音の出力を依頼し、サウンド部１７はスピーカに効果音を出力する。
３．レイアウト部１３はグラフィック部１６からのイベント通知を受けて、対応するアクション（この場合はレイアウトＭＬ切替えイベントの活性化）を実行し、レイアウトＭＬ切替えイベントを活性化する。
４．活性化されたレイアウトＭＬ切替えイベントがシナリオ処理部１２に通知される。
５．シナリオ処理部１２はレイアウトＭＬ切替えイベントを受けて、対応するアクション（この場合はモデル呼び出し）を実行し、ＬＳｕＩ（モデル）にレイアウトＭＬ切替え依頼を行う。
６．シナリオ処理部１２はレイアウト部１３にdeleteLayoutメッセージ（指定されたレイアウトインスタンスを削除する要素）を送信する。
７ シナリオ処理部１２はレイアウト部１３にcreateLayoutメッセージを送信する。
８．deleteLayoutメッセージ受信後の処理は、初期画面表示時のcreateLayoutメッセージ受信後の処理と同じである為、説明は省略する。
９．何らかのタイミングで画面を表示する（切替える）イベントが発生し、表示する画面に対応する描画コマンドを生成し、グラフィック部１６に通知する。
１０．グラフィック部１６は描画コマンドを解釈し、物理デバイスに描画する。
【０１５２】
図３６は、レイアウトＭＬの切り替えのシーケンス図を示す。
Ｓ１．タッチパネル上のボタンのタッチ信号がデバイスドライバ等からグラフィック部１６に通知される。
Ｓ２．グラフィック部１６はプラットフォーム依存の形式でレイアウト部１３にボタン押下イベントを通知する。効果音の出力についてはレイアウト内部の画面切り替えと同様である。
Ｓ３．レイアウト部１３はレイアウトＭＬ切替えイベントの活性化を実行し、レイアウトＭＬ切替えイベントを活性化する。
Ｓ４．シナリオ処理部１２は、対応するアクション（この場合はモデル呼び出し）を実行する。
Ｓ５．シナリオ処理部１２は、ＬＳｕＩにレイアウトＭＬ切替え依頼を行う。
Ｓ６．シナリオ処理部１２はレイアウト部１３にdeleteLayoutメッセージ（指定されたレイアウトインスタンスを削除する要素）を送信する。
Ｓ７．レイアウト部１３はレイアウトインスタンスを破棄する。
Ｓ８．シナリオ処理部１２は、レイアウト部１３にcreateLayoutメッセージを送信する。
Ｓ９．レイアウト部１３は、初期画面表示時のcreateLayoutメッセージ受信後の処理と同様に画面を生成する。
Ｓ１０．レイアウト部１３は描画コマンドをグラフィック部１６に送信する。
Ｓ１１．グラフィック部１６は、タッチパネルディスプレイに描画する。
【０１５３】
・シナリオＭＬの切り替え
図３７は、シナリオＭＬが切り替わる相互作用の概略を示す図である。
１．タッチパネル上のボタンのタッチ信号がデバイストライバ等からグラフィック部１６に通知される。
２．グラフィック部１６はＰＦ依存の形式でレイアウト部１３にボタン押下イベントを通知する。これと同時にグラフィック部１６はサウンド部１７にボタン押下に対応付ける効果官の出力を依頼し、サウンド部１７はスピーカに効果音を出力する。
３．レイアウト部１３はグラフィック部１６からのイベント通知を受けて、対応するアクション（この場合はシナリオＭＬ切替えイベントの活性化）を実行し、シナリオＭＬ切替えイベントを活性化する。
４．活性化されたシナリオＭＬ切替えイベントがシナリオ処理部１２に通知される。
５．シナリオ処理部１２はシナリオＭＬ切替えイベントを受けて、対応するアクション（この場合はモデル呼び出し）を実行し、ＬＳｕＩ（モデル）にレイアウトＭＬ切替え依頼を行う。
６．ＬＳｕＩ（モデル）はシナリオＭＬ切替え依頼に応じて、シナリオ処理部１２にシナリオＭＬ破棄依頼メッセージを送信する。
７．シナリオ処理部１２はシナリオＭＬ破棄依頼メッセージを受信し、対象のシナリオＭＬに関する一連のデータを破棄する。
8．ＬＳｕＩ（モデル）はシナリオ処理部１２にシナリオＭＬを提供する。
９．以後は初期画面表示におけるシナリオパース以後の処理と同じであるため、説明は省略する。
【０１５４】
図３８は、シナリオＭＬの切り替えのシーケンス図を示す。
Ｓ１．タッチパネル上のボタンのタッチ信号がデバイストライバ等からグラフィック部１６に入力される。
Ｓ２．グラフィック部１６はプラットフォーム依存の形式でレイアウト部１３にボタン押下イベントを通知する。効果音の出力についてはレイアウト内部の画面切り替えと同様である。
Ｓ３．レイアウト部１３はグラフィック部１６からのイベント通知を受けて、対応するアクション（この場合はシナリオＭＬ切替えイベント）を実行する。
Ｓ４．レイアウト部１３はシナリオＭＬ切替えイベントをシナリオ処理部１２に通知する。
Ｓ５．シナリオ処理部１２はシナリオＭＬ切替えイベントの通知を受けて、対応するアクション（この場合はモデル呼び出し）を実行する。
Ｓ６．シナリオ処理部１２は、ＬＳｕＩ（モデル）にレイアウトＭＬ切替え依頼を行う。
Ｓ７．ＬＳｕＩ（モデル）はシナリオＭＬ切替え依頼に応じて、シナリオ処理部１２にシナリオＭＬ破棄依頼メッセージを送信する。以後は初期画面表示におけるシナリオパース以後の処理と同じであるため、説明は省略する。
Ｓ８．シナリオ処理部１２は、対象のシナリオＭＬに関する一連のデータの破棄を、レイアウト部１３，ボイス部１４に依頼する。
Ｓ９．シナリオ処理部１２は、破棄が終了したらシナリオ破棄の完了をＬＳｕＩに通知する。
【０１５５】
〔動画再生〕
続いて動画の再生について説明する。図３９は、動画を再生する際の相互作用の概念図を示す。
【０１５６】
実際に動画を再生する処理の部分以外は、以下に示す点を除き他の相互作用と同様になる。
・シナリオ部に変数としてＭＭＰ動画再生用実体のリファレンスを保管する領域を用意する。ＭＭＰ動画再生用実体を呼び出すと動画が再生されるが、図３９ではＭＭＰ動画再生用実体をＤｒａｗｉｎｇ Ａｄａｐｔｅｒ Ｄ．Ａ．とした。なお、この変数はレイアウト部と共有する。
・ＭＭＰのモデル本体に、ＭＭＰ動画再生用実体のリファレンスを取得する為のメソッド（図３９のＤ．Ａ．生成依頼）が必要となる。
・レイアウト部でＭＭＰ動画再生用実体のリファレンスを利用してテクスチャマッピングを行うオブジェクト（図３９中の「Canvas」）を用意する。
【０１５７】
１．シナリオ処理部１２は、コンテンツの記述に従い、モデル（図３９ではＭＭＰ）にＤ．Ａ．の生成を依頼する。
２．モデルはＭＭＰの出力する動画の描画用にＤ．Ａ．を生成する。
３．シナリオ処理部１２はコンテンツの記述に従い、モデルに描画開始を依頼する。
４．既にｃｒｅａｔＬａｙｏｕｔを実施済みの場合、シナリオ処理部１２はＭＭＰ用レイアウトの画面表示開始のイベントを活性化する。
５．レイアウト部１３は活性化されたイベントを受けて、ＭＭＰ画面の描画コマンドをグラフィック部に送信する。
６．グラフィック部は描画コマンドを解析し、キャンバスを生成する。
【０１５８】
この時、コンテンツ上でキャンバスに関連付けられているＤ．Ａ．と実際に関連付けを行う。
７．Ｄ．Ａ．は関連付けられたキャンバスの持つ描画領域へＭＭＰ出力する動画の映像を描き出す。
８．グラフィック部はキャンバスを含めＭＭＰ画面の全ての部品を描画する。
【０１５９】
図４０は、動画再生のシーケンス図を示す。
Ｓ１．シナリオ処理部１２は、モデル（ＭＭＰ）にＤ．Ａ．の生成を依頼する。
Ｓ２．モデルはＭＭＰの出力する動画の描画用にＤ．Ａ．を生成する。なお、Ｄ．Ａ．のリファレンスは共有変数に格納され、グラフィック部からもモデルからも相互に利用することができる。
Ｓ３．シナリオ処理部１２はコンテンツの記述に従い、モデルに描画開始を依頼する。
Ｓ４．既にｃｒｅａｔＬａｙｏｕｔを実施済みの場合、シナリオ処理部１２はＭＭＰ用レイアウトの画面表示開始のイベントを活性化する。
Ｓ５．レイアウト部１３は活性化されたイベントを受けて、ＭＭＰ画面の描画コマンドをグラフィック部に送信する。
Ｓ６．グラフィック部は描画コマンドを解析し、キャンバスを生成する。
Ｓ７．グラフィック部は、コンテンツ上でキャンバスに関連付けられているＤ．Ａ．とキャンバスとを実際に関連付けする。
Ｓ８．モデル（ＭＭＰ）は、キャンバスが生成した描画領域のリファレンスを取得する。
Ｓ９．グラフィック部はキャンバスを含めＭＭＰ画面の全ての部品を描画する。
Ｓ１０．Ｄ．Ａ．は関連付けられたキャンバスの持つ描画領域へＭＭＰ出力する動画の映像を描き出す。以降は、順次、描画が更新される。
【０１６０】
〔ソフトウェア構成〕
続いて、ソフトウェア構成について説明する。図４１は、３層にサブシステムが配置された概略コンポーネント図を示す。上述したように、本システムはプラットフォーム、機種に依存しない「抽象概念系」と、プラットフォーム、機種に依存する「実体系」と、「抽象概念系」と「実体系」を分離させる為のインターフェイスを規定する「実装系」の3層構造をとる。これに併せてサブシステム単位においても、コンポーネント構成は３層構造となる。なお、「」内がコンポーネント名となる。
【０１６１】
「シナリオ処理部抽象概念系」
・シナリオＭＬを解釈し、シナリオＭＬ内の状態遷移データを、実装系を通じて実体部に渡す。
・各種Ｄ．Ｄ．の記載内容に応じて、他のサブシステムとシナリオ処理部１２、またはシナリオ処理部内で利用するデータとイベントのマッピングを行う。これにより、サブシステム間でのデータの共有と、サブシステム間での処理の同期を行う。
・本システムの外部で発生するイベントメッセーシ（ＸＭＬ）を解釈し、本システム内部に通知する。
・シナリオＭＬの内部に定義されたデバイスの抽象表現を具象化する。
【０１６２】
「シナリオ処理部実装系」
・シナリオ処理部の抽象概念系−実体系間のインターフェイスを規定する。
【０１６３】
「シナリオ処理部実体系」
・実装系が規定するインターフェイスによって、シナリオＭＬに記載されたデータを保持し、実行する役割が課せられるが、実現方式、機能（役割）は規定しない。
【０１６４】
「レイアウト部抽象概念系」
・レイアウトＭＬを解釈し、必要とするスキンＭＬ、リソースＭＬを取り込んだ上で、画面の構成、意匠、遷移情報を、実装系を通じて実体系に渡す。
【０１６５】
「レイアウト部実装系」
・レイアウト部の抽象概念系−実体系間のインターフェイスを規定する。
【０１６６】
「レイアウト部実体系」
・実装系が規定するインターフェイスによって、画面の構成、意匠、遷移情報を保持し、グラフィックスデバイスに出力する役割が課せられるが、実現方式、機能（役割）は規定しない。
【０１６７】
「グラフィック部」
・レイアウト部と連携し、ディスプレイやタッチパネルなどのグラフィックデバイスとやり取りを行うことにより、ユーザと対話を行う。
【０１６８】
「ボイス部抽象概念系」
・ボイスＭＬを解決し、必要とするスキンＭＬ、リソースＭＬを取り込んだ上で、音声による対話内容、音声意匠を、実装系を通じて実体系に渡す。
【０１６９】
「ボイス部実装系」
・ボイス部の抽象概念系−実体系間のインターフェイスを規定する。
【０１７０】
「ホイス部実体系」
・実装系が規定するインターフェイスによって、音声による対話内容、音声意匠を保持し、サウンドデバイスに出力する役割が課せられるが、実現方式、機能（役割）は規定しない。
【０１７１】
「サウンド部」
・ボイス部から渡されるデータを保対し、実デバイスと連携することによって保持した内容の音声対話を実現する。また、ナビ等のモデルから直接音声対話を実行することもできる。
〔ＬＳｕＩの動作〕
以上説明した車載多機能装置によれば、ユーザインターフェイスをユーザやその他のシチュエーションに応じて自由に構成することができる。図４２は、車載多機能装置の利用形態の一例を示す図である。
【０１７２】
例えば、父、母、子の３人が車両に搭乗するものとして、この３人の個人情報を車載多機能装置に登録する。登録する個人情報は、例えば、趣味、嗜好、性別、年齢、職業、生年月日、星座、血液型、家族構成等である。父は、例えば、ゴルフや株価情報に興味があることが、母は、ショッピングやセキュリティに興味があることが、子はゲーム、映画、音楽、チャットに興味があることが登録される。
【０１７３】
また、車載多機能装置には、その時のシチュエーションが情報に応じて自動的に入力される。入力されるシチュエーションは、例えば、日時、曜日、天気、時間帯、目的地、現在地、出発地等である。日時、曜日、時間帯は車載のカレンダや外部から取得でき、天気は天気予報や温度センサ、日射センサ等から取得でき、目的地、現在地、出発地等はカーナビ装置３から取得できる。また、車載多機能装置には、車載しているハードウェアからアクセス可能な周辺のインフラの情報が得られる。例えば、お買い得情報、イベント情報、道路情報等である。
【０１７４】
車両に父が搭乗すれば、スマートキーや生体認識情報、ボタンなどによる入力により、車載多機能装置は父が搭乗したことを検知する。そして、ＬＳｕＩは父の個人情報とシチュエーションに応じて、最適なシナリオを抽出し、プラットフォームに提供する。ＬＳｕＩは、例えば、夕刻であればその日の株価情報を表示し、また、道路が混み始めたら交通情報を提供するシナリオを実行する。その日、ゴルフのトーナメントがあれば、その結果を表示することもできる。このとき表示される画面は、父の好むレイアウトやフォント、スキンであり、父の好む音声である。
【０１７５】
また、車両に、さらに母と子が搭乗するような場合、子がゲームを実行していても、時間帯やシチュエーションによっては、ＬＳｕＩが近くのレストランやショッピングの情報を表示するシナリオを実行するので、母がレストランを選択できる。なお、シート毎にディスプレイを設けてもよい。
【０１７６】
以上のように、本実施の形態の車載多機能装置は、ユーザに対するシステムの振る舞いをメタデータ（ＸＭＬ）で記述したため、ユーザ毎に適切なヒューマンインターフェイスを提供できる。メタデータを補充することで、容易に特徴のあるヒューマンインターフェイスを追加、拡張することができる。
【０１７７】
また、ＭＶＣアーキテクチャにシナリオという概念を導入したため、ユーザインターフェイスとロジックとを分離できる。メタデータを実行する抽象概念系は、プラットフォームに依存しないため、別の車両への移植等も容易である。
【図面の簡単な説明】
【０１７８】
【図１】ＭＶＣアーキテクチャの概念図である。
【図２】マルチメディアアーキテクチャが適用された車載多機能装置のハードウェア構成図、マルチメディアアーキテクチャの全体システム構成図である。
【図３】ＸＭＬメッセージによるサブシステム間の疎結合の概略を示す図、及び、状態遷移の概念を示す図である。
【図４】抽象概念系、実装系及び実体系の関係を示す図である。
【図５】シナリオ処理部、レイアウト部、ボイス部の関係を示す図である。
【図６】グラフィック部とシナリオ処理部、サウンド部の関係を示す図である
【図７】サウンド部とボイス部、グラフィック部の関係を示す図である。
【図８】ＵＩサーバがＵＲＩを参照する概念図を示す。
【図９】ロケーション管理とライフサイクル管理の概要を示す図である。
【図１０】モデルの概要を示す図である。
【図１１】ＬＳｕＩの機能概略を示す図である。
【図１２】コンテンツサーバの概要を示す図である。
【図１３】メヅセージＭＬ通信（リクエスト）にサブコンポーネントＡからサブコンポーネントＢへリクエストメッセージを送信する処理の概念を示す図である。
【図１４】図１３の処理の後、サブシステムＢからサブシステムＡにレスポンスメッセージを送信する処理の概念を示す図である。
【図１５】分散ＦＷのロケーション管理へ生成した実体オフジュクトの参照を登録する処理のシーケンス図、ＩＤＬ呼び出しのシーケンス図である。
【図１６】動的インターフェイス呼び出し時におけるＣＯＲＢＡ通信の概念を示す図である。
【図１７】ＤＩＬ呼び出しのシーケンス図である。
【図１８】コマンドリスト通信におけるＣＯＲＢＡ通信の概念を示す図である。
【図１９】ＣＬＬ呼び出しのシーケンス図、イベントコールバックのシーケンス図である。
【図２０】イベント通信の概念を示す図である。
【図２１】共有変数による通信の概念を示す図である。
【図２２】システムの起動におけるサブシステム間及び外部システムとの基本相互作用を示す図である。
【図２３】システム起動のシーケンス図である。
【図２４】シナリオパースにおけるサブシステム間及び外部システムとの基本相互作用を示す図である。
【図２５】シナリオパースのシーケンス図である。
【図２６】認証画面表示におけるサブシステム間及び外部システムとの基本相互作用を示す図である。
【図２７】認証画面表示のシーケンス図である。
【図２８】ユーザ認証及びシナリオ切り替えにおけるサブシステム間及び外部システムとの基本相互作用を示す図である。
【図２９】元のシナリオを破棄する場合のサブシステム間及び外部システムとの基本相互作用を示す図である。
【図３０】ユーザ認証とシナリオ切り替えのシーケンス図である。
【図３１】レイアウト部の内部で画面切替えが行われる場合の相互作用の概略を示す図である。
【図３２】レイアウト部の内部における画面切り替えのシーケンス図である。
【図３３】スキンＭＬが切り替わる相互作用の概略を示す図である。
【図３４】スキンＭＬの画面切り替えのシーケンス図である。
【図３５】レイアウトＭＬが切り替わる相互作用の概略を示す図である。
【図３６】レイアウトＭＬの切り替えのシーケンス図である。
【図３７】シナリオＭＬが切り替わる相互作用の概略を示す図である。
【図３８】シナリオＭＬの切り替えのシーケンス図である。
【図３９】動画再生の相互作用の概略を示す図である。
【図４０】動画再生のシーケンス図である。
【図４１】３層にサブシステムが配置された概略コンポーネント図を示す。
【図４２】車載多機能装置の利用形態の一例を示す図である。
【符号の説明】
【０１７９】
１ 車載多機能装置
２ 入力装置
３ カーナビ装置
４ ラジオ／テレビユニット
５ メディアプレーヤ
６ 表示装置
７ スピーカ
８ 通信ユニット
９ 記憶装置
１０ 制御装置
１１ ＬＳｕＩ連携部
１２ シナリオ処理部
１３ レイアウト部
１４ ボイス部
１５ ＵＩリポジトリ
１６ グラフィック部
１７ サウンド部
２０ ＵＩサーバ
【技術分野】
【０００１】
本発明は、車両においてユーザに様々なサービスを提供する車載多機能装置及びメタデータに関する。
【背景技術】
【０００２】
従来、車両には、カーナビゲーションシステムやラジオやテレビ、動画の再生など、マルチメディア機能が搭載されている（例えば、特許文献１参照。）。車両のマルチメディア機能は、ユーザとの対話に基づき処理を実行し、次の画面や処理結果を表示するものであるが、このようなコンピュータ上で提供されるシステムの実現方法としてＭＶＣ（Ｍｏｄｅｌ Ｖｉｅｗ Ｃｏｎｔｒｏｌｌｅｒ）アーキテクチャが知られている。
【０００３】
図１（ａ）はＭＶＣアーキテクチャの概念図を示す。ＭＶＣアーキテクチャでは、アプリケーションの構成要素を、処理（Ｍｏｄｅｌ）Ｍ、表示（Ｖｉｅｗ）Ｖ、入力（Ｃｏｎｔｒｏｌｌｅｒ）Ｃの３つで構成する。
【０００４】
Ｍｏｄｅｌはアプリケーションの処理を受け持つ部分であり、アプリケーションで必要となるデータを保持しており、入力Ｃからの入力に応じて処理を実行する。Ｖｉｅｗは、Ｍｏｄｅｌの状態を表示する部分であり、液晶などの表示装置上に表示されるウィンドウ等である。Ｖｉｅｗは、情報の配置又は配置の方法を規定するものであるので、頻繁に変更の要請が生じる。また、Ｃｏｎｔｒｏｌｌｅｒは、ユーザの入力、タッチパネルや押しボタン、音声などの入力を受け取り、入力内容を処理する。Ｃｏｎｔｒｏｌｌｅｒは、例えば、表示画面の更新を行う場合にはＶｉｅｗを呼び出したり、入力内容を適切に変換してＭｏｄｅｌに渡す。
【特許文献１】特開２００１−２３５３３４号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら、図１（ａ）のようなＭＶＣアーキテクチャでは、ＶｉｅｗとＭｏｄｅｌの依存関係が強いため、ユーザインターフェイスと処理を分離することが困難である。車両では多様なシチュエーションにおいてマルチメディア機能を利用することが想定されるため、車載されたマルチメディア機能は、ユーザと密接に関わるユーザインターフェイスを、車両のモデル・車種・ユーザの嗜好等に応じて拡張可能な仕組みが要請される。
【０００６】
また、カーナビゲーションシステムや動画の再生機能などは今後も進化が予想されるため、ソフトウェアのロジック（処理部）を部品化しその再利用が容易であることや、進歩・多様化していくハードウェアやＯＳ、デバイス等の低レベルなプラットフォーム層に依存しない仕組みを有することが必要とされる。
【０００７】
本発明は、上記問題に鑑み、処理とユーザインターフェイスとを分離して、多様なシチュエーションにおいて適切なユーザインターフェイスを提供し、また、システムの拡張が容易な車載多機能装置及びメタデータを提供することを目的とする。
【課題を解決するための手段】
【０００８】
上記課題を解決するため、本発明は、ユーザインターフェイスを介してユーザからの入力を受け付け、出力装置（例えば、表示装置６、スピーカ７）からユーザにサービスを提供する車載多機能装置において、メタデータにより記述されたユーザインターフェイス及びサービスの内容を記憶したメタデータ記憶手段（例えば、記憶装置９）と、メタデータを解釈してユーザインターフェイス又はサービスを生成する制御部（例えば、ＵＩサーバ２０）と、を有することを特徴とする。
【０００９】
また、本発明の好ましい一形態において、前記メタデータ記憶手段は、前記ユーザインターフェイス又はサービスの遷移をメタデータにより記述した遷移情報（例えば、レイアウトＭＬ、シナリオＭＬ、ボイスＭＬ）を記憶している、ことを特徴とする。
【００１０】
本発明によれば、処理とユーザインターフェイス及びサービスとを分離した車載多機能装置を提供できる。なお、サービスとは、車載されたデバイスを制御して出力・表示されるもの、例えば、音声や表示の内容をいう。また、ユーザインターフェイスとは、視覚によるものだけでなく、聴覚や嗅覚によるものを含む。ユーザインターフェイスやサービスの内容や遷移がメタデータにより記述されることで、ユーザインターフェイスやサービスに容易に拡張性をもたらすことができる。
【００１１】
また、本発明の一形態において、ユーザインターフェイス及びサービスの内容を記述したメタデータはそれぞれ独立して変更可能である、ことを特徴とする。すなわち、サービスを定義したシナリオＭＬ、画面構成／遷移を定義したレイアウトＭＬ、音声による対話制御を定義したボイスＭＬ等のＸＭＬファイルは、それぞれ独立に記述されているため、いずれかの変更が他に影響を与えることがない。
【００１２】
本発明によれば、ユーザインターフェイスやサービスを後から追加、拡張することができ、追加、拡張がそれ以外の機能に与える影響が少ない。
【００１３】
また、本発明の一形態において、更新頻度の高い描画を反映する動画用アダプタ（例えば、ＭＭＰ動画再生用実体（Ｄｒａｗｉｎｇ Ａｄａｐｔｅｒ））を有し、更新頻度の高い描画がある場合、制御部はユーザインターフェイスに描画領域を設け、動画アダプタが描画領域に描画する、ことを特徴とする。
【００１４】
本発明によれば、動画のように更新頻度の高い描画も、ユーザインターフェイスとして扱えるので、動画の取り扱いが容易になる。
【００１５】
また、本発明の一形態において、前記ユーザを識別する手段と、道路の交通状況、日時等のシチュエーションを判別する手段とを有し、制御部は、ユーザ又はシチュエーションに応じて、メタデータ記憶手段に記憶されたメタデータを抽出し、制御部は、ユーザ又はシチュエーションに応じたユーザインターフェイス又はサービスを生成する、ことを特徴とする。
【００１６】
本発明によれば、ユーザやシチュエーションに応じて、自動的にユーザインターフェイスやサービスを提供できる。
【発明の効果】
【００１７】
処理とユーザインターフェイスとを分離して、多様なシチュエーションにおいて適切なユーザインターフェイスを提供し、また、システムの拡張が容易な車載多機能装置及びメタデータを提供することができる。
【発明を実施するための最良の形態】
【００１８】
図１（ｂ）は、本実施の形態のマルチメディアアーキテクチャの概念図を示す。本実施の形態のマルチメディアアーキテクチャは、ＭｏｄｅｌとＶｉｅｗ及びＣｏｎｔｒｏｌｌｅｒの間に、シナリオという概念を挿入した。
【００１９】
シナリオは、Ｍｏｄｅｌと動的に結合する機構を有する。シナリオは、Ｖｉｅｗ又はＣｏｎｔｒｏｌｌｅｒをイベントと変数のマッピングにより結合させる機構を持つことにより、それぞれの依存関係を疎結合化している。これにより、ユーザインターフェイスと処理のロジックとを完全に分離することが可能となる。
【００２０】
図２（ａ）は、本実施の形態のマルチメディアアーキテクチャが適用された車載多機能装置のハードウェア構成図を示す。カーナビ装置３は、ＧＰＳ衛星から送信される航法データに基づいて車両の現在位置を検出し、現在位置を含む道路地図に目的地までの走行経路などを制御装置１０に供給する。テレビ／ラジオユニット４は、ＵＨＦやＶＨＦのテレビ放送電波や地上波デジタル放送を受信して、映像及び音楽等を制御装置１０に供給する。また、ＡＭ、ＦＭ放送や地上波デジタルラジオ放送を受信して、音楽等を制御装置１０に供給する。なお、テレビ／ラジオユニット１０４は準天頂衛星からの電波を受信するものであってもよい。メディアプレーヤ５は、ＤＶＤやＣＤ、メモリカードのデータを読み出して再生し、映像及び音楽等を制御装置１０へ供給する。
【００２１】
通信ユニット８は、携帯電話、ＰＨＳ等の移動体通信又は無線ＬＡＮ等により、基地局やアクセスポイントに接続すると共に、ネットワークを介して情報を受信して制御装置１０へ供給したり、制御装置１０から指示された情報をネットワークを介して外部に送信する。なお、通信ユニット８は、情報センタに蓄積されている渋滞情報その他の交通情報をビーコン等により取得して制御装置１０に供給する。
【００２２】
表示装置６は、液晶ディスプレイやプロジェクタなどで構成され、カーナビ装置３から供給される地図、テレビ／ラジオユニット４から供給されるテレビ画像、メディアプレーヤ５から供給される動画などを表示する。また、表示装置６は、車載多機能装置１を操作するための操作メニューを表示する。スピーカ７は、カーナビ装置３による音声案内、テレビ／ラジオユニット４から供給される音声、メディアプレーヤ５から供給される音声などを出力する。入力装置２は、押しボタンやリモコン、表示装置６と一体のタッチパネル等により構成され、ユーザが所望の機能を選択したり、カーナビ装置の目的地の入力、テレビやラジオの選局の入力を可能とする。なお、入力装置２は、マイクロフォンを備えて音声による操作も可能である。
【００２３】
制御装置１０は、車載多機能装置１を制御するための制御装置であり、ＣＰＵ、ＲＯＭ、ＲＡＭ及びＮＶＲＡＭなどをバスにより接続したコンピュータにより構成される。ＣＰＵはＲＯＭや記憶装置９に格納されているプログラムを実行して、入力に応じた処理や画面表示の切り替え等、後述する処理を実行する。記憶装置９はハードディスクドライブや書き換え可能な光ディスク、フラッシュメモリ等により構成され、ＯＳ等や地図データ、ファイル（メタデータ）、プログラムなどを格納している。メタデータ、プログラム、地図データ等は、車両に設けられたコネクタや無線通信を介し記憶装置９にインストールされる。なお、メタデータはネットワークを介してダウンロードされ、記憶装置９にインストールしてもよい。
【００２４】
図２（ｂ）は、マルチメディアアーキテクチャの全体システム構成図を示す（以下、図２（ｂ）のＵＩサーバを単にシステムということがある）。マルチメディアアーキテクチャのシステムは、ディスプレイやスピーカ、マイクロフォン等のハードウェアとそれらのドライバからなるＨ／Ｗ、システム全体を統括するＳｙｓｔｅｍ、分散環境を実現する為の分散ＦＷ、データ等を管理するＣｏｎｔｅｎｔｓサーバ、サービスの個別部品としてソフトウェア処理を行うＭｏｄｅｌ、本実施の形態で説明するユーザインターフェイスを制御するＵＩサーバ２０から構成される。なお、ＵＩサーバ２０とハードウェア以外の構成を外部サブシステムと称す。
【００２５】
図２（ｂ）のＵＩサーバ２０は、分散ＦＷのライフサイクル管理から起動され、取り付けられるデバイスや外部サービスと連携して、ユーザにサービスを提供する。ＵＩサーバ２０は、サービスの状態遷移を受け持つシナリオ処理部１２、画面を受け持つレイアウト部１３及びグラフイック部１６、音を受け持つボイス部及びサウンド部１７、サブシステム間で共有するオブジェクトのリファレンスを格納する為のＵＩリポジトリ及びＬＳｕＩ（Ｌｉｆｅ Ｓｃｅｎｅ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）との連携の際に使用するＬＳｕＩ連携部１１を有する。
【００２６】
ＬＳｕＩ連携部１１は、ＬＳｕＩとＵＩサーバ２０の他のサブシステムとが連携する際にメッセージＭＬの送受信を行う。サブシステム間の連携について説明する。図３（ａ）は、ＸＭＬ（eXtensible Markup Language）メッセージによるサブシステム間の疎結合の概略を示す図である。
【００２７】
本システムでは、サブシステム間のデータ授受に際し、言語やプラットフォームに依存しない形とする為、メタデータ、主にＸＭＬメッセージを用いる。これにより、サブシステム間の疎結合化が可能となる。ＸＭＬメッセージとは、ＸＭＬを用いてメッセージのやり取りを行うことをいう。すなわち、図３（ａ）に示すように、シナリオ処理部とレイアウト部、シナリオ処理部とボイス部は、ＸＭＬメッセージを用いて、例えば、ＸＭＬ読み込み依頼などの内容を相互にやり取りする。したがって、「メッセージＭＬ」のように「〜ＭＬ」と表示されるものは、ＸＭＬメッセージにより対象となる処理に関する連携を行うことを示す。
【００２８】
本システムで使用するＸＭＬ規格は、大きくシナリオ、レイアウト、ボイスの３つについてのＸＭＬと、ＸＭＬ間の情報をマッピングするＤ．Ｄ．（Ｄｅｐｌｏｙｍｅｎｔ Ｄｅｓｃｒｉｐｔｏｒ）から成る（Ｄ．Ｄ．もＸＭＬファイルである）。代表的な「〜ＭＬ」は次のようになる。
・シナリオＭＬ
本システムが提供するサービスの定義。シナリオＭＬがレイアウトＭＬ、ボイスＭＬ及びモデルと繋がる基点となる。
・シナリオＭＬ用リソースＭＬ
シナリオＭＬ、モデル用Ｄ．Ｄ．に対するテキストリソースを定義する。シナリオＭＬ用リソースＭＬを差し替えることにより、同一のシナリオのままで、使用する文字を変更することが可能となる。（例：日本語→英語）
・レイアウトＭＬ
本システムが提供するグラフィックデバイス向けユーザインタフゴースの構成、遷移を定義する。
・レイアウトＭＬ用Ｄ．Ｄ．
シナリオＭＬとレイアウトＭＬの、イベント及び変数の関連づけを定義する。レイアウトＭＬ用Ｄ．Ｄ．により、シナリオＭＬ中の変数とレイアウトＭＬ中の変数が紐付けされ、データが共有される。また、レイアウトＭＬ用Ｄ．Ｄ．により、シナリオＭＬ中のイベントとレイアウトＭＬ中のイベントが紐付けされ、処理のタイミンクの同期がとられる。
・レイアウトＭＬ用スキンＭＬ
レイアウトＭＬに対する画面意匠を定義する。レイアウトＭＬ用スキンＭＬを差し替えることにより、同一の画面構成、画面遷移のままで画面意匠を変更することが可能となる。
・レイアウトＭＬ用リソースＭＬ
レイアウトＭＬに対するテキストリソースを定義する。レイアウトＭＬ用リソースＭＬを差し替えることにより、同一の画面構成、画面遷移のままで表示する文字を変更することが可能となる。（例：日本語→英語）
・ボイスＭＬ
本システムが提供するサウンドデバイス向けユーザインターフェイスの構成、音声による対話制御を定義する。
・ボイスＭＬ用Ｄ．Ｄ．
シナリオＭＬとボイスＭＬの、イベント及び変数の関連づけを定義する。ボイスＭＬ用Ｄ．Ｄ．により、シナリオＭＬ中の変数とボイスＭＬ中の変数がひも付けされ、デ−タが共有される。また、ボイスＭＬ用Ｄ．Ｄ．により、シナリＭＬ中のイベントとボイスＭＬ中のイベントが紐付けされ、処理のタイミングの同期がとられる。
・ボイスＭＬ用スキンＭＬ
ボイスＭＬに対する音声意匠を定義する。ボイスＭＬ用スキンＭＬを差し替えることにより、同一の対話内容のまま、声色を変更することが可能となる。
・ボイスＭＬ用リソースＭＬ
ボイスＭＬに対する発話内容を定義する。ボイスＭＬ用リソースＭＬを差し替えることにより同一の対話内容のまま、発話内容、及び認識辞書を変更することが可能となる。
・モデル用Ｄ．Ｄ．
シナリオＭＬとモデルの、インタフュースの関連づけを定義する。モデル用Ｄ．Ｄ．によりシナリオＭＬ中の変数とモデルに対するバラメタが紐づけされ、データが共有される。
・モデルＭＬ
モデルのインターフェイスや付加情報を定義する。
・デバイスＭＬ
本システムが利用可能なデバイス情報の出力形式を定義する。本定義は、本システムが内部で収集しているデバイスの情報を、サブシステム間で受渡しする際に用いる。
・メッセージＭＬ
本システムのサブシステム間、及びサブシステム内のコンポーネント間で情報を受渡しする際に用いる、ＸＭＬメッセージである。なお、コンポーネントについては後述するが、コンポーネントは、抽象概念系、実装系及び実体系の３層に構成した各サブシステムをいう。
・インデックスＭＬ
ＬＳｕＩがレイアウトＭＬ、スキンＭＬ、リソースＭＬに関し最適なＭＬを提供するために用いる判断材料を記述したものであり、ＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒｓ（後述））が列挙されている。
【００２９】
図３（ｂ）は、状態遷移の概念を示す図である。ＸＭＬを使用することにより、サービスやユーザインターフェイスを構成するデータに意味を持たせることが可能になる為、年次モデルや車種、グレ−ド等に応じた固有の拡張を加えることも可能となる。例えばユーザインターフェイスで一般的な「ボタン」を意味するデータが記述されている場合、ある車種ではこのデータはアイコンで表現されるが、異なる車種では３Ｄオブジェクトや、ハードスイッチにマッピングされる。
【００３０】
図３（ｂ）に示すように、レイアウトＭＬにより「画面Ａ」〜「画面Ｆ」の画面情報（意匠情報やリソース情報、配置情報）、及び各画面の遷移情報が記述される。同様に、シナリオＭＬにより状態遷移が記述され、ボイスＭＬにより対話遷移が記述される。これらの各ＸＭＬは、相互に情報のやり取りを行うことにより、相互関係を持つことが可能である。
【００３１】
図２（ｂ）に戻り、ＵＩリポジトリ１５は、サブシステム間で共有するオブジェクトのリファレンス（参照という場合がある）を格納している。シナリオ処理部１２は、システム本体が提供するサービス（シナリオ）を解釈／実行する。レイアウト部１３は、シナリオ処理部１２からの通知を受けて、画面遷移を記述したレイアウトＭＬを解釈し、グラフィック部１６と連携する。グラフィック部１６は、レイアウト部１３と連携し、ディスプレイやタッチパネルなどのグラフィックデバイスとやり取りを行うことによりユーザと対話を行う。ボイス部１７は、シナリオ処理部１２からの通知を受けて、音声対話を記述したボイスＭＬを読み込み、サウンド部１７と連携し、音声対話サービスを提供する。サウンド部１７は、音や音声の出力、音声の入力を受け付けるサービスを提供する。
【００３２】
続いて、本システムの実体系と抽象概念について説明する。図４は、抽象概念層、実装層及び実体層の関係を示す図である。本システムはプラットフォームに依存しない「抽象概念系」と、プラットフォームに依存する「実体層」、抽象概念系と実体層を繋ぐ「実装層」に分離され、これらが連携して機能を提供する。
【００３３】
抽象概念層では、主に、サービスを定義したシナリオＭＬ、画面構成／遷移を定義したレイアウトＭＬ、音声による対話制御を定義したボイスＭＬ等のＸＭＬファイルの解釈を行い、実装層を通じて実行時に必要なデータを実体層に渡す。
【００３４】
抽象概念層は、ＸＭＬファイル（シナリオＭＬ、レイアウトＭＬ、ボイスＭＬ）の解釈、実体層向けテー夕（実行時に用いるデータ）の送信、実体層からの依頼の受信及び対応する処理（ＸＭＬファイル取得、ＸＭＬL解釈等）等を行う。
【００３５】
実体層では抽象概念層から渡されたデータを保持し、それらと実デバイスを利用してサービスを提供する。プラットフォームに依存する部分であるため、実装方法はプラットフォームに応じて設計される。プラットフォームは例えば、車種やＰＣ（パソコン）などである。実体層は、抽象概念層へ依頼事項の送信（ＸＭＬファイル取得依頼、ＸＭＬ解釈依頼）を行う。
【００３６】
なお、実体層は、プラットフォームや機種に非依存であり、抽象概念層と実体層のインターフェイスとなる。また、以下では、抽象概念層、実装層及び実体層のメタデータをそれぞれ抽象概念系、実装系及び実体系という。
【００３７】
〔ＵＩリポジトリ〕
ＵＩリポジトリ１５について説明する。抽象概念系が実体系部のオブジェクトを指定する際にはＵＲＩを用いてオブジェクトの識別を行う。
【００３８】
ＵＩリポジトリ１５は、本システムの実体系コンポーネントが生成したオブジェクトのリファレンスを格納し、相互に情報のやり取りを行う為に利用するサブシステムである。
【００３９】
図５は、シナリオ処理部、レイアウト部、ボイス部の関係を示す図である。オブジュクトの生成元であるコンポーネントは、生成したオブジェクトのキーとなるＵＲＩと、そのオブジュクトのリファレンスを対応づけて格納しており、参照元のコンポーネントがＵＲＩをキーとしてオブジェクトのリファレンスを取り出す。
【００４０】
抽象概念系のコンポーネント間は、実体系に依存したオブジェクト（及びそのリファレンス）を送受しないため、実体系に依存していないＵＲＩを送受し、実体系のオブジェクトはＵＲＩに結び付けられたオブジェクトをＵＩリポジトリ１５から取り出し、相互に情報のやりとりを行う。
【００４１】
〔シナリオ処理部〕
シナリオ処理部１２は、システム本体が提供するサービス（シナリオ）を解釈／実行するものであり、システム本体から提供されるシナリオＭＬに従い、利用者へ適切なＨＭＩ（Ｈｕｍａｎ Ｉｎｔｅｒｆａｃｅ）サービスを提供する司令塔的役割を持つ、サブシステムである。
【００４２】
シナリオ処理部１２はレイアウト部１３、ボイス部１４と連携し、サービスを提供する。シナリオＭＬにはサービス全体の状態遷移を記述することができ、レイアウト部、ボイス部とＤ．Ｄ．に記述されたマッピング定義によって情報の共有、遷移の同期をとることができる。
【００４３】
実体世界では分散ＦＷの提供する共有変数機能を利用して情報が共有される。また、遷移に対しては分散ＦＷの提供するイベント管理機能を利用して同期がとられる。シナリオＭＬに記述された状態遷移では、サービスで用いる「アクション」と呼ばれるモデルと連携する役割を持ち、車載機が持つ他サービスとの連携を行う。具体的には、シナリオＭＬに実際にモデルの機能を呼び出すアクションを記述し、イベントの活性化等によってこのアクションを実行することでモデルの提供する機能を利用する。また、レイアウトＭＬやボイスＭＬからモデルの提供する機能を利用する場合、イベントを利用しアクションを呼び出すことでモデルとの連携を実現する。
【００４４】
〔レイアウト部〕
レイアウト部１３はシナリオ処理部１２からの通知を受けて、ユーザとの対話を行う為の画面遷移を記述したレイアウトＭＬを解釈し、グラフィック部１６と連携することにより利用者にユーザインタフュースを提供するサブシステムである。
【００４５】
レイアウト部１３は、グラフィック部１６を介して、実テバイスからのタッチパネルやエスカッションキー入力、実デバイスヘの画面出力を行う。レイアウトＭＬには画面構成と画面遷移を記述することができ、シナリオＭＬに記述されたシナリオの状態遷移とは、Ｄ．Ｄに記述されたマッピング定義によって情報の共有、遷移の同期をとることができる。実体世界では分散ＦＷの提供する共有変数機能を利用して情報が共有される。また、遷移に対しては分散ＦＷの提供するイベント管理機能を利して同期がとられる。
【００４６】
レイアウトＭＬに記述した画面表示中にナビ等のモデルの提供する機能を利用する場合は、シナリオＭＬに実際にモデルの機能を呼び出すアクションを記述し、イベントの活性化等によってこのアクションを実行することでモデルの提供する機能を利用する。
【００４７】
レイアウトＭＬに記述した画面遷移中に話す声対話等の音声変化を起こさせる場合は、ボイスＭＬに実際に音声対話アクション等のアクションを記述し、イベントの活性化等によってこのアクションを実行することでボイス部の提供する機能を利用する。また、レイアウトＭＬに記述した画面遷移中にナビ等のモデルの提供する機能を利用する場合は、シナリオＭＬに実際にモデルの機能を呼び出すアクンョンを記述し、イベントの活性化等によってこのアクションを実行することでモデルの提供する機能を利用する。また、ボタン押下時の効果音など一部の音出力に関しては、サウンド部と連携することにより高レスポンスを実現する。
【００４８】
〔グラフィック部〕
グラフィック部１６は基本的にレイアウト部１３と連携し、ディスプレイやタッチパネルなどのグラフィックデバイスとやり取りを行うことにより、ユーザと対話を行うサブシステムである。ただし、ナビ描画など一部はレイアウト部を経由しないサービスも存在する（ナビ描画の場合、プラグインによりナビモデルから直接描画を行うことによりサービスを提供する。）。
【００４９】
図６は、グラフィック部１６と、シナリオ処理部１２、サウンド部１７の関係を示す図である。グラフィック部１６はディスプレイやタッチパネル、エスカッションキーなどの実デバイスに対して画面の出力や表示内容に関連するイベント（ボタンウィジェットなど）入力を行うことが可能であり、これを行う為のインターフェイスを持つ。また、画面の出力に関して、様々な依頼元からの要求を調停する為の、排他制御や合成を行う機能（画面権管理）を持つ。
【００５０】
グラフィック部１６へはレイアウト部１３やサウンド部１７、描画クライアントと呼ばれるモデル群からの依頼を受け、画面の出力、表示に関連するイベントの入力を行う。
【００５１】
〔ボイス部〕
ボイス部１４は、ボイスＭＬを読み込み、ボイスＭＬ中に記述された音声対話サービスを提供するサブシステムである。
【００５２】
図５に戻り、ボイス部１４はサウンド部１７を介して、実デバイスからの音声の入力、実デバイスへの音声の出力を行う。ボイスＭＬには音声対話の状態遷移を記述することができ、シナリオＭＬに記述されたシナリオの状態遷移とは、Ｄ．Ｄ．に記述されたマッピング定義によって情報の共有、遷移の同期をとることができる。実体世界では分散ＦＷの提供する共有変数機能を利用して情報が共在される。また、遷移に対しては分散ＦＷの提供するイベント管理機能を利用して同期がとられる。
【００５３】
ボイスＭＬに記述した音声対話中に画面遷移等の画面変化を起こさせる場合は、レイアウトＭＬに実際に画面遷移アクションやアニメーション等のアクションを記述し、イベントの活性化等によってこのアクションを実行することでレイアウトの提供する機能を利用する。また、ボイスＭＬに記述した音声対話中にナビ等のモデルの提供する機能を利用する場合は、シナリオＭＬに実際にモデルの機能を呼び出すアクションを記述し、イベントの活性化等によってこのアクションを実行することでモデルの提供する機能を利用する。
【００５４】
〔サウンド部〕
サウンド部は音や音声の出力、音声の入力を受け付けるサービスを提供する・サブシステムである。
【００５５】
図７は、サウンド部１７と、ボイス部１４、グラフィック部１６の関係を示す図である。サウンド部１７はスピーカやマイクなどの実デバイスに対して音声の出力や入力を行うことが可能であり、これを行う為のインターフェイスを持つ。また、音の出力に対して、様々な依頼元からの要求を調停する為の、排他制御やミキシングを行う機能（音権管理）を持つ。
【００５６】
サウンド部１７へはボイス部１４やグラフィック部１６、Soundクライアントと呼ばれるモデル群からの依頼を受けて、音診／音声の出力、音声の入力を行う。
【００５７】
〔ＵＲＩ〕
ＵＲＩについて説明する。本システムではサブシステム間で共有する全てのリソースの「所在地」を示す方法としてＵＲＩを用いる。ＵＲＩは1つ1つのリソースに対して必ずコニークに割り当てられる。
【００５８】
本システム内でＵＲＩを割り当てて参照するリソースとしては以下の様なものが挙げられる。
（ｉ）シナリオＭＬ等のＸＭＬファイル
（ｉｉ）スキンＭＬに記述された画像ファイル等
（ｉｉｉ）シナリオＭＬ等をパースした結果生成されるインスタンス
（ｉｖ）システム起動時に生成されるデバイス等のインスタンス
（ｖ）分散ＦＷが提供する各種リモートサービス
図８は、ＵＩサーバ２０がＵＲＩを参照する概念図を示す。これらの列挙したリソースの内、（ｉ）（ｉｉ）のリソースは、コンテンツサーバ上に管理され、ＵＲＩを指定して参照、登録することができる。（ｉｉｉ）、（ｉｖ）、（ｖ）のリソースは分散ＦＷのロケーション管理上に管理され、そのインスタンスやサービスの参照を、ＵＲＩを指定して参照、登録することができる。
【００５９】
〔外部サブシステム〕
続いて、外部サブシステムの概要について説明する。外部サブシステムはＵＩサーバ２０と連携して動作する。図２（ｂ）に示したように、外部サブシステムの構成の一例を示す図である。外部サブシステムは、Ｃｏｎｔｅｎｔｓ Ｓｅｒｖｅｒ、Ｍｏｄｅｌ、Ｓｙｓｔｅｍ、分散ＦＷから構成される。
【００６０】
Ｍｏｄｅｌは、ＬＳｕＩ及びモデルを有する。分散ＦＷは、「ライフサイクル管理」、「ロケーション管理」、「デバイス管理」からなる管理サービス層、「車載ファシリティ」、「イベント管理」、「イベントＩＤ管理」とからなる基本サービス層により構成される。
【００６１】
ライフサイクル管理は、分散ＦＷ内で使用するサービスの起動方法やサービスの参照を、サービスリポジトリ管理するサービスである。各ＯＳにひとつずつ存在し、ロケーション管理より待機系サービスの起動要求があった場合にそのサービスを起動する。
【００６２】
ライフサイクル管理の持つ機能として、「ＳｅｒｖｉｃｅＣｏｎｆｉｇｕｒａｔｉｏｎ」による設定」、「サービスプロセス起動」、「デバイスの追加と削除」が挙げられる。
【００６３】
図９は、ロケーション管理とライフサイクル管理の概要を示す図である。本システムは、ライフサイクル管理の管理下にあるオブジェクトを利用することにより、オブジェクトのライフサイクル管理を分散ＦＷに委任する形とする。通常、ライフサイクル管理の存在は、分散ＦＷのロケーション管理に隠蔽されており、本システムからは意識しない。
【００６４】
ロケーション管理は、分散ＦＷで使用される、分散オブジェクトのオブジェクト参照の登録と検索機能を提供するサービスである。本システムは、ロケーション管理に対して、
・他プロセスから利用するコンポーネントのオブジュクト参照を登録ける。
・利用するコンポーネントのオブジェクト参照を問い合わせ、オブジュクド参照を取得する、
ことにより、サービス（オブジェクト）の実体の位置を意識しない形でサービスを提供・利用することが可能となる。また、オブジェクト参照を登録する際は、登録するオブジェクトのＵＲＩを、オブジェクト参照を取得する際のキーとして使用する。
【００６５】
デバイス管理は、車載多機能装置で使用されるデバイスの構成情報を提供するサービスである。提供されるデバイスの構成情報例は、例えば次のようになる。
全般： 対応座席位置（0 〜 9）
種類
（Graphic／Sound）
デバイスのＵＲＩ
デバイスの識別
接続先ホスト名
オープニング画面の表示の有無
画面： レイヤーＮｏ．
分割位置Ｎｏ．
本システムは、デバイス管理に対して、
・実デバイスの位置情報を問い合わせる。
【００６６】
・実デバイスのデバイス情報を問い合わせる。
ことにより、プラットフオームに依存する実デバイスの実体を隠蔽し、ボキャブラリデバイスと関連付けることが可能となる。
【００６７】
ボキャブラリデバイスとは、一般的に言われるＸＭＬのボキャブラリの他に、所定のイベントやデバイスのＸＭＬを要素化したボキャブラリである。本システムで単に「ボキャブラリ」と呼んだものは「所定のイベントやデバイスをＸＭＬの要素化したボキャブラリ」を指す。
【００６８】
ボキャブラリはＤＴＤ（Document Type Definition)として規定され、各ＸＭＬ規格に取り込まれて使用される。ＸＭＬ規格はボキャブラリを取り込むことにより、規定のイベント定義やデバイス定義を使用することができる様になる。
【００６９】
ボキャブラリは、プラットフォームに依存するイベントやデバイスを隠蔽し抽象化する為のものであり、
・外部イベントや一部の内部イベントの定義
・本システムが認識可能なデバイスの表現
・シナリオからモデルを呼び出す際に補足する例外の定義
を規定する。
【００７０】
イベント管理は、イベントのやり取りを行う際の、データ送受信、フィルタリングを行う。イベント管理では、イベントサーバを利用したＴＣＰ版と、マルチキャスト通信を利用したＵＤＰ版を混在して利用可能である。
【００７１】
ＵＩサーバ２０では、シナリオ・レイアウト・ボイス間で相互に利用するイベントに対し分散ＦＷのイベント管理へイベント登録／削除を行い、イベント管理とイベントの送受を行うことにより、分散環境下での動作が可能となる。
【００７２】
本システムはイベント管理に対して
・各‐サブシステム間で相互利用するイベントのコールバックを登録する
・各サブシステムの内部でのみ利用するイベントのコールバックを登録する
・ボキャブラリイベントのコールバックを登録する
・登録されたイベントが発生したことを通知する（イベントを活性化する）
ことにより、スレッド間、プロセス間、ホスト間であってもイベント通知を受けることが可能になる。また、イベントを登録する際は、登録するイベントのＵＲＩを、イベント通知を受ける際のキーとして使用する。
【００７３】
イベントＩＤ管理は、車載多機能装置で発生するイベントのＩＤ情報を提供する。提供されるイベント情報は、例えば次のようになる。
エスカッションスイッチ ： 「ボタン」押下
「日的地ボタン」押下
「現在地ボタン」押下
「ナビメニューボタン」押下
「ＴＶボタン」押下
車両情報 ： イルミネーションON
イルミネーションOFF
走行規制ＯＮ
走行規制ＯＦＦ
システム情報： 起動処理完了
終了処理完了
本システムはイベントＩＤ管理から、本システムの外部から通知されるプラットフォーム依存のイベントのＩＤを取得することにより、分散ＦＷのイベント管理と連携してプラットフォーム依存のイベントの通知を受信することが可能となる。受信したプラットフォーム依存のイベントはボキャブラリイベントとして本システム内で使用する。
【００７４】
車載ファシリティは、車載多機能装置で発生する走行規制ＯＮ／ＯＦＦやイルミネーンョンＯＮ／ＯＦＦ等の車両のイベントを通知する為のサービスである。提供される車両情報は、例えば次のようになる。
効果：イルミネーションＯＮ／ＯＦＦ
規制：走行規制ＯＮ／ＯＦＦ
本システムは、車載ファシリティが発生させるプラットフォーム依存のイベントを、分散ＦＷのイベント管理を通して受信する。受信したプラットフォーム依存のイベントはボキャブラリイベントとして本システム内で使用する。
【００７５】
モデルは、外部プログラムを定義したものである。本システムは、シナリオＭＬやレイアウトＭＬ等のＸＭＬ規格に記述できない複雑な処理を、外部のプログラムとして定義し、シナリオＭＬから呼び出すことができる。この外部プログラムをモデルと呼ぶ。
【００７６】
図１０は、モデルの概要を示す図である。シナリオＭＬにはモデル実体に関する情報は直接記述しない。図１０に示すように、シナリオＭＬには抽象的にモデルの名称、関数名、パラメータ名が定義され、関数の呼び出し記述に関しても、抽象名を使用して記述される。
【００７７】
これに対し、モデルの実体では、ＤＩＬ（Ｄｙｎａｍｉｃ Ｉｎｔｅｒｆａｃｅ Ｌａｎｇｕａｇｅ）と呼ばれる動的インターフェイス呼び出し用の定義言語を使用してモデルのインターフェイスを定義し、これに対応する本体処理を内部に定義する。
【００７８】
シナリオＭＬ中の抽象モデルと、モデル実体との関連付けは、モデル用Ｄ．Ｄ．に定義する。モデル用Ｄ．Ｄ．には、抽象モデル名に対する実体モデルのＵＲＩ、抽象関数名に対するモデル実体の関数名、モデル実体に渡すパラメータの並び順を記述する。
【００７９】
モデル実体は分散ＦＷの提供するロケ−ション管理に、実体モデルＵＲＩを基に自身の参照を登録する。このモデルの機能を利用するシナリオインスタンスは、ロケーション管理から実例モデルＵＲＩを基にモデル実体の参照を取得し、この参照に対して動的インターフェイス呼び出しを行う。
【００８０】
本システムはＬＳｕＩと呼ばれるサブシステムと連携することにより、その時のシチュエーション、利用者の趣味・嗜好に最適なユーザインターフェイスを提供することを実現する。
【００８１】
図１１がＬＳｕＩの機能概略を示す図である。図１１に示すようにＬＳｕＩの機能は、例えば次のようになる。
・シナリオ自動生成／実行指示
・レイアウト／スキン／言語リソースの最適化
・レイアウト／スキン／言語リソースの変更依頼
・個人情報取得
ＬＳｕＩのインスタンスは利用者1人に対して１個生成する。この為、ＬＳｕＩのインスタンスを生成する、より自立のコンポーネントが必要となる。
【００８２】
本システムとＬＳｕＩの間の通信はＬＳｕＩ連携部１１を介してメッセージＭＬを利用して行われる。ただし、ユーザの切替え機能等の、上位のコンポーネントから呼び出されるべき機能に関しては、シナリオ処理部からモデルを呼び出す上述した方法を用い、ＬＳｕＩの操作を行う方式である。
【００８３】
また、本システムは、コンテンツサーバと連携することにより、異なるホストや異なるプロセスからでも、ＸＭＬファイル、設定ファイル、画像ファイル、等の参照・編集を行うことができる。これらのファイルは統一的にＵＲＩによって指し示される。
【００８４】
図１２はコンテンツサーバの概要を示す図である。本システムの各サブシステムは、コンテンツサーバが提供するライブラリのＡＰＩを利用して、利用するファイルを参照・編集する。コンテンツサーバが提供するライブラリの、参照・編集するファイルへのアクセス方式については、本システムからは隠蔽されている。
【００８５】
以上説明したＵＩサーバ２０のサブシステム間、外部システムとＵＩサーバ２０とが通信することで、ライフシーンに適合したユーザインターフェイスを実現する。サブシステム間の通信について説明する。
【００８６】
本システム内のサブシステム間、及び外部システムと本システム間の通信方式は、大きくは「メッセージＭＬ通信」と「ＣＯＲＢＡ（Common Object Request Broker Architecture）通信」、「イベント」、「共有変数」の４つの方式に分類される。「ＣＯＲＢＡ」通信に関しては、更に「ＩＤＬ（（リモートインターフェイス呼び出し））、「ＤＩＬ（動的インターフェイス呼び出し）」、「ＣＬＬ（コマンドリスト通信）」に分類される。以下に、これらの通信方式の相互作用を記載する。
【００８７】
〔メッセージＭＬ通信〕
本システムの抽象概念系のコンポーネント間では、メッセージＭＬを媒体とする通信が行われる。通信するデータをＸＭＬ形式にすることにより、サブシステム間の関係を疎にしている。
【００８８】
抽象概念系のコンポーネントはメッセージＭＬを作成する処理を隠蔽する為に、実装系のインターフェイスを介して実体系のコンポーネントを使用して実際の処理を行わせる。なお、実体系のコンポーネントはコンテンツサーバ上にメッセージＭＬを生成する。
【００８９】
図１３は、メッセージＭＬ通信（リクエスト）にサブシステムＡからサブシステムＢへリクエストメッセージを送信する処理の概念を示す。サブシステムＡ抽象概念系は、実装系インターフェイスＡを介して、サブシステムＡ実体系にリクユスト内容のメッセージＭＬ生成を依頼する。
【００９０】
サブシステムＡ実体系はコンテンツサーバ上にメッセージＭＬを作成する（この一連の処理の中で、生成するメッセージＭＬはＵＲＩによって特定される）。サブシステムＡ抽象概念系は、実装系インターフェイスＡを介して、サブシステムＡ実体系に、リクエストメッセージの送信を依頼する。
【００９１】
サブシステムＡ実体系はサブシステムＢ実体系の参照を分散ＦＷのロケーション管理から取得し、ＩＤＬで既定された関数を使用して、リクエストメッセージを送信する（この時実際に送信されるのは生成されたメッセージＭＬのＵＲＩ）。
【００９２】
サブシステムＢ実体系は、リクエストメッセージを受け取ったことをサブシステムＢ抽象概念系に通知する。サブシステムＢ抽象概念系は、実装系のインターフェイスＢを介して、サブシステムＢ実体系に、メッセージＭＬの参照を依頼する。サブシステムＢ抽象概念系はメッセージＭＬの内容を基にリクエストメッセージに対応する処理を開始する。
【００９３】
図１４（ａ）（ｂ）は、図１３の処理の後、サブシステムＢからサブシステムＡにレスポンスメッセージを送信する処理の概念を示す図である。図１４（ａ）の処理は、レスポンスとして何らかのデータ（ＸＭＬ）を返す場合を、図１４（ｂ）の処理は、レスポンスとして戻り値等の簡略な文字列（即値）だけを返す場合を示す。
【００９４】
〔ＣＯＲＢＡ通信〕
本システムの実体系のコンポーネントは分散ＦＷ上に構築される為、実体系のコンポーネント間ではＣＯＲＢＡ通信が行われる。ＣＯＲＢＡ通信においては、一般的に使用される、ＩＤＬ（Ｉｎｔｅｒｆａｃｅ Ｄｅｆｉｎｉｔｉｏｎ Ｌａｎｇｕａｇｅ）を既定してリモートでインタフュースを呼び出す方式の他に、分散ＦＷ上で拡張される以下の方式が使用される。
・ＤＩＬに定義したインターフェイスを持つオブジェクトを生成し、クライアント側のスタブなしで動的にリモ−ト呼び出しする方式（動的インターフェイス呼び出し方式）
・ＣＬＬ（Ｃｏｍｍａｎｄ Ｌｉｓｔ Ｌａｎｇｕａｇｅ）に定義したコマンドを送受信、バッファリングするオブジェクトを生成し、コマンド呼び出し時の通信回数を削減する方式（コマンドリスト通信方式）
また、分散ＦＷの基本サービスとして提供される「イベント管理」機能や「共有変数」機能も、通信の代替手段として利用する。以下、ＩＤＬ、ＤＩＬ、ＣＬＬ、イベント、共有変数の5つの方式について説明する。
【００９５】
・ＩＤＬ（リモートインターフェイス呼び出し）
利用する機能のインターフェイスをＩＤＬに定義し、ＩＤＬから生成した「スタブ」と呼ばれる代理オブジェクトと、「スケルトン」と呼ばれるサーバオブジェクトが実際の通信を行う。スタブ又はスケルトンを利用する場合、スタブを利用する機能と、スケルトンを継承する実体オブジェクトを作成する。
【００９６】
この方式は、上述したメッセージＭＬ通信の方式における、実体系のコンポーネントが「メッセージ送受信ＩＤＬ」に規定されるインターフェイスに、リクエストやレスポンスを送信する部分でも使用され、本システムの実体系コンポーネントにおけるもっとも基本的な通信方式である。
【００９７】
開発時には、まずＩＤＬを規定し、ＩＤＬよりクライアント側のスタブと、サーバ側のスケルトンを生成する。サーバ側の開発者は、サーバ側のスケルトンを継承するＩＤＬの実体オブジェクトを作成し、クライアント側の開発者はＩＤＬの代理オブジェクトであるスタブを利用する機能を作成する。
【００９８】
実行時には、（異なるプロセスである場合）サーバ側のプロセスの起動時、または実体オブジュクトが利用されるより以前に、実体オブジュクトを生成し分散ＦＷのロケーション管理へ生成した実体オフジュクトの参照を登録する。
【００９９】
クライアントの利用側の機能は、分散ＦＷのロケーション管理から必要とする実体オブジェクトの参照を取得する。この時の実体オブジコクトを特定するキーとしてＵＲＩが用いられる。取得した参照に対して関数呼び出しを行うと、スタブはスケルトンの該当関数をリモードで呼び出す。
スケルトンは自身を継承する実体オブジェクトの該当関数を呼び出し、関数の実行結果をリモートでスタブに返す。クライアント側のプロセスはスタブから関数の実行結果を受け取る。また、以上の動作が同一プロセス内で行われる場合に限り、「ショートカット」と呼ばれる機能が働き、リモート呼び出しは行われない。これによってリモート呼び出しによる動作オーバヘットを削減する。以上の動作において、クライアントの利用者側の機能はリモート呼び出しが行われた事を一切認識しない。
【０１００】
図１５（ａ）は、分散ＦＷのロケーション管理へ生成した実体オフジュクトの参照を登録する処理のシーケンス図を示す。
Ｓ１．登録側であるサブシステムＡは、上述したように実体オブジュクト（サブシステムＡの実体）を生成する。
Ｓ２．サブシステムＡは、サブシステムＡの実体の参照（リファレンス）を取得する。
Ｓ３．サブシステムＡは、取得したサブシステムＡの実体の参照を分散ＦＷのロケーション管理に登録する。これにより、ロケーション管理からサブシステムＡのＵＲＩを取得できることとなる。
【０１０１】
図１５（ｂ）は、ＩＤＬ呼び出しのシーケンス図を示す。
Ｓ１．サブシステムＢは、分散ＦＷのロケーション管理から必要とする実体オブジェクトの参照を取得する。
Ｓ２．サブシステムＢは、取得したＵＲＩに対して関数を呼び出す。
Ｓ３．上述したようにサブシステムＢのスタブ及びサブシステムＡのスケルトンにより、サブシステムＡの関数が実行される。
Ｓ４．サブシステムＢは、関数の実行結果を受信する。
【０１０２】
・ＤＩＬ（動的インターフェイス呼び出し）
図１６は動的インターフェイス呼び出し時におけるＣＯＲＢＡ通信の概念を示す図である。基本的な流れはＩＤＬの場合と同様であるが、利用する機能のインターフェイスが規定できない為、以下に挙げる点に違いがある。
・呼び出す関数名やパラメータに関する情報は、外部から動的に与えられる。
・ＩＤＬコンパイルと同様にＤＩＬコンパイルを実行しても、クライアント側のスタブは動的に生成されない。
【０１０３】
ＤＩＬスタブは分散ＦＷの機能として提供される。この方式は、シナリオＭＬやモデル用Ｄ．Ｄ．内に動的に定義されるモデルの情報を元に、実際に利用するモデル実体を紐付ける際に使用される。
【０１０４】
図１７は、ＤＩＬ呼び出しのシーケンス図を示す。
Ｓ１．サブシステムＢは、分散ＦＷのロケーション管理から必要とする実体オブジェクトの参照を取得する。
Ｓ２１〜２ｎ．サブシステムＢは、モデル実体が受け取るパラメータを順番に設定する。
Ｓ３．サブシステムＢは、最後にｉｎｖｏｋｅ（発動）により関数を呼び出す。
Ｓ４．サブシステムＢのスタブ及びサブシステムＡのスケルトンにより、サブシステムＡの関数が実行される。
Ｓ５．サブシステムＢは、関数の実行結果を受信する。
【０１０５】
・ＣＬＬ（コマンドリスト通信）
基本的な流れはＩＤＬの場合と同様であるが、通信によるオーバヘッドを削減する為に、利用する機能のリモート呼び出し回数を削減する点においてＩＤＬの場合と異なる。
【０１０６】
図１８はコマンドリスト通信におけるＣＯＲＢＡ通信の概念を示す図である。この方式は、レイアウト部１３とグラフィック部１６の間の様に、明らかにリモート呼び出しが発生し、かつ性能が要求される箇所に使用される。
【０１０７】
図１９（ａ）は、ＣＬＬ呼び出しのシーケンス図を示す。
Ｓ１．サブシステムＢは、分散ＦＷのロケーション管理から必要とする実体オブジェクトの参照を取得する。
Ｓ２１〜２ｎ．サブシステムＢは、サブシステムＡに実行を依頼するコマンドを順番に登録する。
Ｓ３．サブシステムＢは、最後にｆｌｕｓｈにより一連のコマンドをロケーション管理に発動する。リスト化されたコマンドが１回の通信でサブシステムＡに送信される。
Ｓ４１〜４ｎ．ロケーション管理は、コマンドの実行をサブシステムＡに依頼する。サブシステムＡは、一連のコマンドを順に実行する。
Ｓ５．サブシステムＢは、コマンドの実行結果を受信する。
【０１０８】
・イベント
イベントによる通信は、両面に表示されたボタンが選択された際に発生させる様な画面系のイベントや、音声認識時に発生させる様な音声系のイベント以外にも、シナリオから呼び出したモデルの実行完了通知や、走行規制のＯＮ／ＯＦＦの通知に利用される。
【０１０９】
図２０はイベント通信の概念を示す図である。イベント受信側は分散ＦＷのイベント管理機能に対して、イベントの識別子となるイベントＵＲＩに対してコールバック関数の登録を行う。分散ＦＷのイベント管理機能は、イベントの発信側から指定されたイベントＵＲＩのイベントの活性化依頼を受けると、登録されたコールバック開放を呼び出す。イベントの受信側は、コ−ルバック関数内にイベントに対応する処理を定義することにより、イベントハンドリングが実現される。
【０１１０】
図１９（ｂ）は、イベントコールバックのシーケンス図を示す。
Ｓ１．イベントを受信したサブシステムＡは、イベント管理にイベント（コールバック）の登録を行う。
Ｓ２．サブシステムＡは、イベントＵＲＩをサブシステムＢに活性化してほしいイベントのＵＲＩを所定の方法で通知する。
Ｓ３．イベントＵＲＩを通知されたサブシステムＢは、イベント管理部にイベントを活性化を依頼する。
Ｓ４．イベント管理部は、サブシステムＡのコールバックを呼び出す。コ−ルバック関数内にイベントに対応する処理を定義することにより、イベントハンドリングが実現される。
【０１１１】
・共有変数
共有変数を用いた通信は、サブシステム間で共有すべきデータを、専用の領域に保持して共有する。この方式は、シナリオＭＬ内に定義された変数の値や、モデルのアウトプットとして得られるデータを、レイアウトＭＬやボイスＭＬ内で使用する場合、シナリオＭＬと長時間にわたってデータを共有する場合等に使用される。
【０１１２】
図２１は、共有変数による通信の概念を示す図である。
共有変数の生成者は、分散ＦＷが提供する共有変数の生成関数を利用して共有変数の実体を生成する。この時、実体と共にその参照を得る。生成者はこの参照と変数の識別子（ＵＲＩ）をＵＩリポジトリ１５に登録する。本システム内では、ＵＩリポジトリ１５から共有変数の参照を得ることによって、共有変数の参照、登録を行うことができる。
【０１１３】
この為、共有変数を参照する場合は、まずＵＩリポジトリから変数ＵＲＩを指定し、共有変数の参照を取得し、この参照を基に共有変数の値を参照する。また共有変数を更新する場合も同様に、ＵＩリポジトリ１５から得た共有変数の参照に対して、値の更新を行う。
【０１１４】
共有変数では、必要に応じて、その値を更新した時に更新イベントを発生させることができる。この更新イベントは分散ＦＷのイベント管理の機能を利用して発生させている。コールバックを登録するとによって、共有変数の値が更新された時の通知を受ける。
【０１１５】
ＵＩリポジトリ１５は、共有変数の参照と、変数ＵＲＩを関連づける為に必要であり、本システムの共通コンポーネントとして提供される。
【０１１６】
続いて、以上の構成を用いて、サブシステム間及び外部システムとの基本相互作用について、システム起動、シナリオパース、認証画面表示及びユーザ認証完了の場合をそれぞれ説明する。
【０１１７】
〔システム起動〕
図２２は、システムの起動におけるサブシステム間及び外部システムとの基本相互作用を示す図である。図２２の数字は以下の数字と対応している。
１．下位ＰＦから分散ＦＷのライフサイクル管理が起動される。
２．分散ＦＷのライフサイクル管理から本システムと外部サブシステムのプロセスが起動される。
【０１１８】
２−１．ライフサイクル管理から分散ＦＷのその他のサブシステムや、関連するモデル等のシステムが起動される。
【０１１９】
２−２ グラフィック部１６のプロセスが起動される。
【０１２０】
２−３ サウンド部１７のプロセスが起動され、起動したことをグラフィック部１６に通知する。グラフィック部１６はこのプロセス起動通知を受けて、サウンド部１７へ起動効果音の出力を依頼し、起動画面を出力する。サウンド部１７はグラフィック部１６から起動効果音出力依頼を受けて起動効果音を出力する。
【０１２１】
２−４ ＵＩリポジトリのプロセスが起動される。
【０１２２】
２−５ シナリオ処理部のプロセスが起動される。
【０１２３】
２−６ レイアウト部１３のプロセスが起動される。
【０１２４】
２−７ ボイス部１４のプロセスが起動される。
【０１２５】
２−８ ＬＳｕＩのプロセスが起動される。
３．ＬＳｕＩはユーザ認証用のＬＳｕＩインスタンスを生成し、シナリオ処理部１２、レイアウト部１３、ボイス部１４へ、生成したＬＳｕＩインスタンス向けの初期化要求を送信する。
４．ＬＳｕＩインスタンスからシナリオ処理部１２へ、起動直後に実行されるシナリオＭＬを提供する。
【０１２６】
図２３は、システム起動のシーケンス図を示す。
Ｓ１．まず、本システムにプラットフォームから起動が通知される（例えば、ＡＣＣオン）。
Ｓ２．ＵＩサーバ２０（本システム）はグラフィック部１６を起動する。
Ｓ３．ＵＩサーバ２０はサウンド部１７を起動する。グラフィック部１６、サウンド部１７は、起動画面の表示や起動時の効果音出力を行うため、グラフィック部１６とサウンド部１７は本システムの中で最初に起動される。
Ｓ４．ＵＩサーバ２０はＵＩリポジトリ１５を起動する。
Ｓ５．ＵＩサーバ２０はシナリオ処理部１２を起動する。
Ｓ６．ＵＩサーバ２０はレイアウト部１３を起動する。
Ｓ７．ＵＩサーバ２０はボイス部１４を起動する。
Ｓ８．ＵＩサーバ２０はＬＳｕＩを起動する。ＵＩサーバ２０は、ユーザ認証用ＬＳｕＩインスタンスを生成し、専用のシナリオエンジン、レイアウトエンジン等のインスタンスを生成する。
Ｓ９．ＬＳｕＩインスタンスは、ＬＳｕＩインスタンスのＵＲＩをもって、シナリオ処理部１２の初期化を要求する。
Ｓ１０．シナリオ処理部１２は、ＬＳｕＩインスタンス専用のシナリオエンジンインスタンスを生成する。
Ｓ１１．ＬＳｕＩインスタンスは、ＬＳｕＩインスタンスのＵＲＩをもって、レイアウト部１３の初期化を要求する。
Ｓ１２．レイアウト部１３は、ＬＳｕＩインスタンス専用のレイアウトエンジンインスタンスを生成する。
Ｓ１３．ＬＳｕＩインスタンスは、ＬＳｕＩインスタンスのＵＲＩをもって、ボイス部１４の初期化を要求する。
Ｓ１４．ボイス部１４は、ＬＳｕＩインスタンス専用のボイスエンジンインスタンスを生成する。
Ｓ１５．ＬＳｕＩインスタンスは、シナリオＭＬのＵＲＩ、各種Ｄ．Ｄ．のＵＲＩをもって、シナリオ処理部にシナリオの起動を依頼する。
【０１２７】
〔シナリオパース〕
図２４は、シナリオパースにおけるサブシステム間及び外部システムとの基本相互作用を示す図である。
１．ＬＳｕＩインスタンスから起勤直後に実行されるシナリオのシナリオＭＬがシナリオ処理部に提供される。
２．シナリオオ処理部１２は提供されたシナリオＭＬに対して、マッピング情報を記載されたＤ．Ｄ．をレイアウト部１３、ボイス部１４に渡す。
３．シナリオ処理部１２は提供されたシナリオＭＬを解釈する。
【０１２８】
３−１ 読み込んだ変数の定義に対してＵＩリポジトリに共有変数を登録する。
【０１２９】
３−２ 読み込んだ変数の定義に対しでマッピング情報としてレイアウト部１３、ボイス部１４に渡す。
【０１３０】
３−３ 読み込んだイベントの定義に対してマッピング情報としてレイアウト部１３、ボイス部１４に渡す。
４．シナリオ処理部１２は解釈が完了した旨をＬＳｕＩインスタンスに通知する。
５．シナリオ処理部１２はシナリオＭＬを解釈した結果を元に状態遷移を開始する（シナリオを実行する。）。
【０１３１】
図２５は、シナリオパースのシーケンス図を示す。
Ｓ１．ＬＳｕＩはシナリオの起動をシナリオ処理部１２に依頼する。ここでは、ＬＳｕＩはユーザ認証シナリオのＵＲＩ、各種Ｄ．Ｄ．のＵＲＩをシナリオ処理部１２に送信する。
Ｓ２．シナリオ処理部１２はシナリオインスタンスを生成する。
Ｓ３．シナリオ処理部１２はレスポンスメッセージとしてシナリオインスタンスのＵＲＩをＬＳｕＩに送信する。
Ｓ４．シナリオインスタンスは、レイアウトＭＬ用のＤ．Ｄ．のＵＲＩをレイアウト部１３に通知する。レイアウト部１３は、Ｄ．Ｄ．マッピング解決のために情報を保持しておく。
Ｓ５．シナリオインスタンスは、ボイスＭＬ用のＤ．Ｄ．のＵＲＩをボイス部１４に通知する。ボイス部１４は、Ｄ．Ｄ．マッピング解決のために情報を保持しておく。
Ｓ６．レイアウト部１３はＤ．Ｄ．をパースする。
Ｓ７．ボイス部１４はＤ．Ｄ．をパースする。
Ｓ８．レイアウト部１３とボイス部１４はレスポンスをシナリオインスタンスに返す。
Ｓ９．シナリオインスタンスは、シナリオＭＬをパースする。
Ｓ１０．シナリオインスタンスは、リソースＭＬを取得するため、リソースインデックスのＵＲＩをＬＳｕＩに送信する。
Ｓ１１．ＬＳｕＩは、レスポンスメッセージとしてリソースＭＬのＵＲＩをシナリオインスタンスに送信する。
Ｓ１２．シナリオインスタンスは、ＵＩリポジトリ１５に変数（変数ＵＲＩ、共有変数識別子）を登録する。
Ｓ１３．シナリオインスタンスは、イベントマッピングの通知としてイベント名とＵＲＩのリストをレイアウト部１３に送信する。レイアウト部１３は、Ｄ．Ｄ．マッピング解決のために情報を保持しておく。
Ｓ１４．シナリオインスタンスは、イベントマッピングの通知としてイベント名とＵＲＩのリストをボイス部１４に送信する。ボイス部１４は、Ｄ．Ｄ．マッピング解決のために情報を保持しておく。
Ｓ１５．レイアウト部１３とボイス部１４はレスポンスをシナリオインスタンスに返す。
Ｓ１６．シナリオインスタンスは、変数マッピングの通知として変数名とＵＲＩのリストをレイアウト部１３に送信する。レイアウト部１３は、Ｄ．Ｄ．マッピング解決のために情報を保持しておく。
Ｓ１７．シナリオインスタンスは、変数マッピングの通知として変数名とＵＲＩのリストをボイス部１４に送信する。ボイス部１４は、Ｄ．Ｄ．マッピング解決のために情報を保持しておく。
Ｓ１８．レイアウト部１３とボイス部１４はレスポンスをシナリオインスタンスに返す。
Ｓ１９．シナリオインスタンスは状態遷移を登録する。
Ｓ２０．シナリオインスタンスは、シナリオ起動の完了としてシナリオインスタンスＵＲＩをＬＳｕＩに送信する。
Ｓ２１．ＬＳｕＩはレスポンスをシナリオインスタンスに送信する。
Ｓ２２．シナリオインスタンスは、状態遷移を開始する。
【０１３２】
〔認証画面表示〕
図２６は、認証画面表示におけるサブシステム間及び外部システムとの基本相互作用を示す図である。
【０１３３】
シナリオが実行された以後、状態の初期（entry）アクションや、イベントに対応するアクションとしてcreateLayout（指定されたレイアウトを生成する要素）が実行された場合に、レイアウトMLの解釈・実行が行われる。
１．シナリオ処理部１２はシナリオを実行する。
２．シナリオ処理部１２はcreateLayoutアクションを実行する。
３．シナリオ処理部１２はレイアウト部１３に対してcreateLayoutアクションが実行された旨を通知する。
４．レイアウト部１３はメッセージＭＬを解釈し、ＬＳｕＩインスタンスにレイアウトＭＬの最適化を依頼する（シナリオ処理部１２が通知したメッセージＭＬに指定されているレイアウトインデックスをＬＳｕＩに渡す。）。
【０１３４】
ＬＳｕＩインスタンスは、レイアウトインデックスの中に記述されたレイアウトＭＬの内、最適なレイアウトＭＬを選定し、そのＵＲＩをレイアウト部１３に通知する。
５．レイアウト部１３はレイアウトＭＬを解釈する。
【０１３５】
５−１ レイアウト部１３はＬＳｕＩインスタンスにスキンＭＬとリソースＭＬの最適化を依頼する（レイアウトＭＬに指定されているスキンインデックスとリソースインデックスをＬＳｕＩに渡す。）。
【０１３６】
ＬＳｕＩインスタンスはスキンインデックスとリソースインデックスの中に記述されたスキンＭＬとリソースＭＬの内、最適なスキンＭＬとリソースＭＬを選定し、そのＵＲＩをレイアウト部１３に通知する。
【０１３７】
５−２ レイアウト部１３はスキンＭＬとリソースＭＬを解釈する。
【０１３８】
５−３ レイアウト部１３はレイアウトＭＬ中のスタイルにスキンＭＬの内容を、リソースにリソースＭＬの内容を、マッピングされる変数・イベントに「シナリオパース」時にシナリオ処理部１２から渡されたマッピング情報を充て込む。
６．レイアウト部１３はレイアウトＭＬの解釈が完了すると、シナリオ処理部１２に対して、解釈が完了したことを通知する（メッセージＭＬ通信を利用して、ボキャブラリイベントとして通知する。）。
７．レイアウト部１３はレイアウトＭＬを解釈した結果を元に状態遷移を開始する（レイアウトを実行する。）。
【０１３９】
レイアウトが実行された以後、すぐには画面上に表示されない。レイアウトは画面表示用の何らかのイベントを受け取った後に始めて画面を表示する（実際にはシナリオＭＬ上の何らかのイベントと、レイアウトＭＬ上の画面表示用のイベントがマッピングされていて、このマッピングされたイベントが図２８に示すように活性化されることにより、画面が表示される。）。
８．シナリオ処理部１２は画面表示イベントを活性化するアクションを実行する。
９．画面表示イベントがレイアウト部１３に通知される。
１０．レイアウト部１３は通知されたイベントに対して対応するアクションを実行する。 この場合はシーン切替えを行う。
１１．レイアウト部１３は切替えられたシーンに対応する描画コマンドを生成し、グラフィック部１６に送信する。
１２．グラフィック部１６は描画コマンドを解釈し、物理デバイスに描画する。
【０１４０】
図２７は認証画面表示のシーケンス図を示す。
Ｓ１．シナリオ処理部１２はレイアウトの生成をレイアウト部１３に依頼する。シナリオ処理部１２はレイアウト識別名、レイアウトインデックスのＵＲＩ、デバイスのＵＲＩ、レイアウトインスタンスのＵＲＩを、レイアウト部１３に送信する。
Ｓ２．レイアウト部１３は、レイアウトＭＬの取得するため、ＬＳｕＩにレイアウトインデックスのＵＲＩを送信する。
Ｓ３．ＬＳｕＩは、レスポンスとしてレイアウトＭＬのＵＲＩをレイアウト部１３に送信する。
Ｓ４．レイアウト部１３は、レイアウトＭＬをパースする。なお、パースはレイアウト生成のパラメータである「デバイスＵＲＩ」の数だけ繰り返す。
Ｓ５．レイアウト部１３は、スキンＭＬを取得するためスキンインデックスのＵＲＩをＬＳｕＩに送信する。
Ｓ６．ＬＳｕＩはレスポンスとしてスキンＭＬのＵＲＩをレイアウト部１３に送信する。
Ｓ７．レイアウト部１３は、リソースＭＬを取得するためリソースインデックスのＵＲＩをＬＳｕＩに送信する。
Ｓ８．ＬＳｕＩはレスポンスとしてリソースＭＬのＵＲＩをレイアウト部１３に送信する。
Ｓ９．レイアウト部１３はレイアウトインスタンスを生成する。
Ｓ１０．レイアウトインスタンスは、各種の設定を行う。
Ｓ１１．レイアウト部１３はイベントを活性化するため、レイアウト生成完了イベントＵＲＩ、レイアウトインスタンスのＵＲＩをシナリオ処理部１２に送信する。シナリオ処理部１２は、レイアウトインスタンスのＵＲＩがレイアウト生成時にパラメータ指定していたＵＲＩであれば、画面表示開始イベントを活性化する。なお、ボイス部との同期が必要であれば、シナリオＭＬの記述において条件判定が行われる。
Ｓ１２．シナリオ処理部１２はイベントを活性化する。すなわち、画面表示を開始する。
Ｓ１３．シナリオ処理部１２はレイアウト部１３にイベントを通知する。
Ｓ１４．レイアウト部１３は、グラフィック部１６にイベントを通知する。
Ｓ１５．グラフィック部１６は、シーングラフを生成すると共に描画し、実デバイスに描画する。
【０１４１】
〔ユーザ認証＆シナリオ切り替え〕
図２８は、ユーザ認証及びシナリオ切り替えにおけるサブシステム間及び外部システムとの基本相互作用を示す図である。
【０１４２】
シナリオが実行された以後、利用者からタッチパネル等を通じて、ユーザ認証のイベントが発生した場合、このイベントを受けてユーザ切替えのモデルが実行される。
１．タッチパネル上のボタンのタッチ信号がデバイスドライバ等からグラフィック部１６に通知される。
２．グラフィック部１６はＰＦ依存の形式でレイアウト部１３にボタン押下イベントを通知する。
３．レイアウト部１３はグラフィック部１６からのイベント通知を受けて、マッピングされたユーザ認証イベントを活性化する。
４．シナリオ処理部１２にユーザ認証イベントが通知される。この時、イベントがマッピングされていなければレイアウト部１２、ボイス部１４には通知されない。
５．シナリオ処理部１２はユーザ認証イベントを受けて、イベントに対応するアクションとしてcal1Modelアクションを実行する（この場合はＬＳｕＩモデルのユーザ切替え処理）。
【０１４３】
ＬＳｕＩモデルのユーザ切替え処理が実行され、切替わったユーザ用に新しくＬＳｕＩインスタンスが生成される（以降の説明では、切り替わる前のＬＳｕＩインスタンスを「旧ＬＳｕＩインスタンス」、切替わった後のＬＳｕＩインスタンスを「新ＬＳｕＩインスタンス」と称する）。
【０１４４】
新ＬＳｕＩインスタンスモデルの処理依頼でシナリオが切替わり、旧ＬＳｕＩインスタンスが実行したシナリオが破棄され、ＬＳｕＩインスタンスが破棄される。図２９は元のシナリオを破棄する場合のサブシステム間及び外部システムとの基本相互作用を示す図である。
６．ＬＳｕＩモデルは認証されたユーザ用に新ＬＳｕＩインスタンスを生成し、シナリオ処理部１２、レイアウト部１３、ボイス部１４へ新ＬＳｕＩインスタンス向けの初期化要求を送信する。
７．新ＬＳｕＩインスタンスは認証されたユーザ用に、シナリオ処理部１２に対して新しいシナリオを提供する。以降の処理は、シナリオパースと同じであるため省略する。
８．旧ＬＳｕＩインスタンスは、目身が実行していたシナリオの破棄を、シナリオ処理部１２に対して要求する。
９．シナリオ処理部１２は、旧ＬＳｕＩインスタンスのシナリオ破棄要求に対して、レイアウト部１３とボイス部１４にシナリオ破棄要求を送信する。シナリオ処理部１２、レイアウト部１３、ボイス部１４はそれぞれ指定されたシナリオに関連するリソースを解放する。
１０．旧ＬＳｕＩインスタンスは、シナリオ処理部１２、レイアウト部１３、ボイス部１４に対し、自身が初期化したリソースの解放を依頼する。
【０１４５】
図３０は、ユーザ認証とシナリオ切り替えのシーケンス図を示す。
Ｓ１．グラフィック部１６は、イベント通知として選択されたボタンをレイアウト部１３に送信する。
Ｓ２．レイアウト部１３は、ユーザ認証イベントの活性化をイベント管理に依頼する。
Ｓ３．イベント管理は、ユーザ認証イベントの活性化をシナリオ処理部１２に通知する。
Ｓ４．シナリオ処理部１２は、ＬＳｕＩから関数（認証、ユーザＩＤ等）を呼び出す。ＬＳｕＩは、ユーザ認証を行い、選択されたユーザ用ＬＳｕＩインスタンスを生成する。
Ｓ５．ユーザ用ＬＳｕＩインスタンスは、ＬＳｕＩインスタンスのＵＲＩを通知して、シナリオ処理部１２に初期化を要求する。
Ｓ６．ユーザ用ＬＳｕＩインスタンスは、ＬＳｕＩインスタンスのＵＲＩを通知して、レイアウト部１３に初期化を要求する。
Ｓ７．ユーザ用ＬＳｕＩインスタンスは、ＬＳｕＩインスタンスのＵＲＩを通知して、ボイス部１３に初期化を要求する。
Ｓ８．ユーザ用ＬＳｕＩインスタンスは、シナリオＭＬのＵＲＩ、各種Ｄ．Ｄ．のＵＲＩを通知して、シナリオ処理部１２にシナリオの起動を依頼する。
Ｓ９．ＬＳｕＩモデルのユーザ切り替え処理が実行されると、旧ＬＳｕＩインスタンスが破棄され、新ＬＳｕＩインスタンスが生成される。新ＬＳｕＩインスタンスは、シナリオインスタンスのＵＲＩを通知して、シナリオ処理部１２にシナリオの破棄を依頼する。
Ｓ１０．シナリオ処理部１２は、シナリオインスタンスのＵＲＩを通知して、レイアウト部にシナリオを破棄を依頼する。
Ｓ１１．シナリオ処理部１２は、シナリオインスタンスのＵＲＩを通知して、ボイス部にシナリオを破棄を依頼する。
Ｓ１２．シナリオ処理部１２は、レスポンスをＬＳｕＩに送信する。
【０１４６】
〔画面切り替え〕
続いて画面の切替について説明する。画面切替えの相互作用は切替えの方式に応じて以下の４パターンが存在する。
・レイアウト部１３の内部で切替えが完結する。
・スキンＭＬ（またはリソースＭＬ）が切り替わる。
・レイアウトＭＬが切り替わる。
・シナリオＭＬが切り替わる。
【０１４７】
・レイアウト部１３の内部での切り替え
図３１は、レイアウト部１３の内部で画面切替えが行われる場合の相互作用の概略を示す図である。
１．タッチパネル上のボタンのタッチ信号がデバイスドライバ等からグラフィック部１６に通知される。
２．グラフィック部１６はプラットフォーム依存の形式でレイアウト部１３にボタン押下イベントを通知する。これと同時にグラフィック部１６はサウンド部１７にボタン押下に対応する効果音の出力を依頼し、サウンド部１７はスピーカに効果音を出力する。
３．レイアウト部１３はグラフィック部１６からのイベント通知を受けて、対応するアクション（この場合は画面切替え）を実行し、切り替えられた画面に対応する描画コマンドを生成し、グラフィック部１６に送信する。
４．グラフィック部１６は描画コマンドを解釈し、物理デバイスに描画する。
【０１４８】
図３２は、レイアウト部の内部における画面切り替えのシーケンス図を示す。
Ｓ１．タッチパネル上のボタンのタッチ信号がデバイスドライバ等からグラフィック部１６に通知される。
Ｓ２．グラフィック部１６は、プラットフォーム依存の形式でレイアウト部１３にボタン押下イベントを通知する。
Ｓ３．グラフィック部１６は、サウンド部１７に効果音の出力を依頼する。
Ｓ４．サウンド部１７は、スピーカから効果音を出力する。
Ｓ５．レイアウト部１３は、画面の切り替えを実行する。
Ｓ６．レイアウト部１３は、切り替えられた描画に対応する描画コマンドをグラフィック部１６に送信する。
Ｓ７．グラフィック部１６は、描画コマンドを解釈しタッチパネルディスプレイを描画する。
【０１４９】
・スキンＭＬ又はリソースＭＬの切り替え
図３３は、スキンＭＬが切り替わる相互作用の概略を示す図である。なお、リソースＭＬの切り替えは、スキンＭＬと同じであるので説明は省略する。
１．タッチパネル上のボタンのタッチ信号がデバイスドライバ等からグラフィック部１６に通知される。
２．グラフィック部１６は、ＰＦ依存の形式でレイアウト部１３にボタン押下イベントを通知する。これと同時にグラフィック部１６はサウンド部１７にボタン押下に対応する効果音の出力を依頼し、サウンド部１７はスピーカに効果音を出力する。
３．レイアウト部１３はグラフィック部１６からのイベント通知を受けて、対応するアクション（この場合はスキンＭＬ切替えイベントの活性化）を実行し、スキンＭＬ切り替えイベントを活性化する。
４．活性化されたスキンＭＬ切替えイベントがシナリオ処理部１２に通知される。
５．シナリオ処理部１２はスキンＭＬ切替えイベントを受けて、対応するアクション（この場合はモデル呼び出し）を実行し、ＬＳｕＩ（モデル）にスキンＭＬ切替え依頼を行う。
６．ＬＳｕＩ（モデル）はスキンＭＬ切替え依頼に応じて、レイアウト部１３にスキンＭＬ切替え依頼メッセージを送信する。
７．レイアウト部１３はスキンＭＬ切替え依頼メッセージを受信し、ＬＳｕＩにスキンＭＬの最適化を依頼する（レイアウトＭＬに指定されているスキンインデックスとリソースインデックスをＬＳｕＩに渡す。）。
８．ＬＳｕＩはスキンインテックスの中に記述されたスキンＭＬの内、最適なスキンＭＬを選定し、そのＵＲＩをレイアウト部１３に通知する。
９．レイアウト部１３はスキンＭＬを解釈し、レイアウトＭＬ中のスタイルにスキンＭＬの内容を再度充て込む。
１０．レイアウト部１３は現在表示中の画面に対応する描画コマンドを生成し、グラフィック部１６に送信する。
１１．グラフィック部１６は描画コマンドを解釈し、物理デバイスに描画する。
【０１５０】
図３４は、スキンＭＬの画面切り替えのシーケンス図を示す。
Ｓ１．タッチパネル上のボタンのタッチ信号がデバイスドライバ等からグラフィック部１６に入力される。
Ｓ２．グラフィック部１６は、ＰＦ依存の形式でレイアウト部１３にボタン押下イベントを通知する。効果音の出力についてはレイアウト内部の画面切り替えと同様である。
Ｓ３．レイアウト部１３はスキンＭＬ切替えイベントを活性化し、シナリオ処理部１２に通知する。
Ｓ４．シナリオ処理部１２はスキンＭＬ切替えイベントの通知を受けて、モデル呼び出しを実行する。
Ｓ５．また、シナリオ処理部１２は、ＬＳｕＩ（モデル）にスキンＭＬ切替えを依頼する。
Ｓ６．ＬＳｕＩは、スキンＭＬ切替え依頼に応じて、レイアウト部１３にスキンＭＬ切替え依頼メッセージを送信する。
Ｓ７．レイアウト部１３は、スキンＭＬをＬＳｕＩに問い合わせる。
Ｓ８．ＬＳｕＩは、スキンＭＬの内、最適なスキンＭＬを選定し、そのＵＲＩをレイアウト部１３に通知する。
Ｓ９．レイアウト部１３はスキンＭＬを解釈し、レイアウトＭＬ中のスタイルにスキンＭＬの内容を再度充て込む。
Ｓ１０．レイアウト部１３は現在表示中の画面に対応する描画コマンドを生成し、グラフィック部１６に送信する。
Ｓ１１．グラフィック部１６は描画コマンドを解釈し、タッチパネルディスプレイに描画する。
【０１５１】
・レイアウトＭＬの切り替え
図３５は、レイアウトＭＬが切り替わる相互作用の概略を示す図である。
１．タッチパネル上のボタンのタッチ信号がデバイスドライバ等からグラフィック部に通知される。
２．グラフィック部１６はＰＦ依存の形式でレイアウト部１３にボタン押下イベントを通知する。これと同時にグラフィック部１６はサウンド部１７にボタン押下に対応する効果音の出力を依頼し、サウンド部１７はスピーカに効果音を出力する。
３．レイアウト部１３はグラフィック部１６からのイベント通知を受けて、対応するアクション（この場合はレイアウトＭＬ切替えイベントの活性化）を実行し、レイアウトＭＬ切替えイベントを活性化する。
４．活性化されたレイアウトＭＬ切替えイベントがシナリオ処理部１２に通知される。
５．シナリオ処理部１２はレイアウトＭＬ切替えイベントを受けて、対応するアクション（この場合はモデル呼び出し）を実行し、ＬＳｕＩ（モデル）にレイアウトＭＬ切替え依頼を行う。
６．シナリオ処理部１２はレイアウト部１３にdeleteLayoutメッセージ（指定されたレイアウトインスタンスを削除する要素）を送信する。
７ シナリオ処理部１２はレイアウト部１３にcreateLayoutメッセージを送信する。
８．deleteLayoutメッセージ受信後の処理は、初期画面表示時のcreateLayoutメッセージ受信後の処理と同じである為、説明は省略する。
９．何らかのタイミングで画面を表示する（切替える）イベントが発生し、表示する画面に対応する描画コマンドを生成し、グラフィック部１６に通知する。
１０．グラフィック部１６は描画コマンドを解釈し、物理デバイスに描画する。
【０１５２】
図３６は、レイアウトＭＬの切り替えのシーケンス図を示す。
Ｓ１．タッチパネル上のボタンのタッチ信号がデバイスドライバ等からグラフィック部１６に通知される。
Ｓ２．グラフィック部１６はプラットフォーム依存の形式でレイアウト部１３にボタン押下イベントを通知する。効果音の出力についてはレイアウト内部の画面切り替えと同様である。
Ｓ３．レイアウト部１３はレイアウトＭＬ切替えイベントの活性化を実行し、レイアウトＭＬ切替えイベントを活性化する。
Ｓ４．シナリオ処理部１２は、対応するアクション（この場合はモデル呼び出し）を実行する。
Ｓ５．シナリオ処理部１２は、ＬＳｕＩにレイアウトＭＬ切替え依頼を行う。
Ｓ６．シナリオ処理部１２はレイアウト部１３にdeleteLayoutメッセージ（指定されたレイアウトインスタンスを削除する要素）を送信する。
Ｓ７．レイアウト部１３はレイアウトインスタンスを破棄する。
Ｓ８．シナリオ処理部１２は、レイアウト部１３にcreateLayoutメッセージを送信する。
Ｓ９．レイアウト部１３は、初期画面表示時のcreateLayoutメッセージ受信後の処理と同様に画面を生成する。
Ｓ１０．レイアウト部１３は描画コマンドをグラフィック部１６に送信する。
Ｓ１１．グラフィック部１６は、タッチパネルディスプレイに描画する。
【０１５３】
・シナリオＭＬの切り替え
図３７は、シナリオＭＬが切り替わる相互作用の概略を示す図である。
１．タッチパネル上のボタンのタッチ信号がデバイストライバ等からグラフィック部１６に通知される。
２．グラフィック部１６はＰＦ依存の形式でレイアウト部１３にボタン押下イベントを通知する。これと同時にグラフィック部１６はサウンド部１７にボタン押下に対応付ける効果官の出力を依頼し、サウンド部１７はスピーカに効果音を出力する。
３．レイアウト部１３はグラフィック部１６からのイベント通知を受けて、対応するアクション（この場合はシナリオＭＬ切替えイベントの活性化）を実行し、シナリオＭＬ切替えイベントを活性化する。
４．活性化されたシナリオＭＬ切替えイベントがシナリオ処理部１２に通知される。
５．シナリオ処理部１２はシナリオＭＬ切替えイベントを受けて、対応するアクション（この場合はモデル呼び出し）を実行し、ＬＳｕＩ（モデル）にレイアウトＭＬ切替え依頼を行う。
６．ＬＳｕＩ（モデル）はシナリオＭＬ切替え依頼に応じて、シナリオ処理部１２にシナリオＭＬ破棄依頼メッセージを送信する。
７．シナリオ処理部１２はシナリオＭＬ破棄依頼メッセージを受信し、対象のシナリオＭＬに関する一連のデータを破棄する。
8．ＬＳｕＩ（モデル）はシナリオ処理部１２にシナリオＭＬを提供する。
９．以後は初期画面表示におけるシナリオパース以後の処理と同じであるため、説明は省略する。
【０１５４】
図３８は、シナリオＭＬの切り替えのシーケンス図を示す。
Ｓ１．タッチパネル上のボタンのタッチ信号がデバイストライバ等からグラフィック部１６に入力される。
Ｓ２．グラフィック部１６はプラットフォーム依存の形式でレイアウト部１３にボタン押下イベントを通知する。効果音の出力についてはレイアウト内部の画面切り替えと同様である。
Ｓ３．レイアウト部１３はグラフィック部１６からのイベント通知を受けて、対応するアクション（この場合はシナリオＭＬ切替えイベント）を実行する。
Ｓ４．レイアウト部１３はシナリオＭＬ切替えイベントをシナリオ処理部１２に通知する。
Ｓ５．シナリオ処理部１２はシナリオＭＬ切替えイベントの通知を受けて、対応するアクション（この場合はモデル呼び出し）を実行する。
Ｓ６．シナリオ処理部１２は、ＬＳｕＩ（モデル）にレイアウトＭＬ切替え依頼を行う。
Ｓ７．ＬＳｕＩ（モデル）はシナリオＭＬ切替え依頼に応じて、シナリオ処理部１２にシナリオＭＬ破棄依頼メッセージを送信する。以後は初期画面表示におけるシナリオパース以後の処理と同じであるため、説明は省略する。
Ｓ８．シナリオ処理部１２は、対象のシナリオＭＬに関する一連のデータの破棄を、レイアウト部１３，ボイス部１４に依頼する。
Ｓ９．シナリオ処理部１２は、破棄が終了したらシナリオ破棄の完了をＬＳｕＩに通知する。
【０１５５】
〔動画再生〕
続いて動画の再生について説明する。図３９は、動画を再生する際の相互作用の概念図を示す。
【０１５６】
実際に動画を再生する処理の部分以外は、以下に示す点を除き他の相互作用と同様になる。
・シナリオ部に変数としてＭＭＰ動画再生用実体のリファレンスを保管する領域を用意する。ＭＭＰ動画再生用実体を呼び出すと動画が再生されるが、図３９ではＭＭＰ動画再生用実体をＤｒａｗｉｎｇ Ａｄａｐｔｅｒ Ｄ．Ａ．とした。なお、この変数はレイアウト部と共有する。
・ＭＭＰのモデル本体に、ＭＭＰ動画再生用実体のリファレンスを取得する為のメソッド（図３９のＤ．Ａ．生成依頼）が必要となる。
・レイアウト部でＭＭＰ動画再生用実体のリファレンスを利用してテクスチャマッピングを行うオブジェクト（図３９中の「Canvas」）を用意する。
【０１５７】
１．シナリオ処理部１２は、コンテンツの記述に従い、モデル（図３９ではＭＭＰ）にＤ．Ａ．の生成を依頼する。
２．モデルはＭＭＰの出力する動画の描画用にＤ．Ａ．を生成する。
３．シナリオ処理部１２はコンテンツの記述に従い、モデルに描画開始を依頼する。
４．既にｃｒｅａｔＬａｙｏｕｔを実施済みの場合、シナリオ処理部１２はＭＭＰ用レイアウトの画面表示開始のイベントを活性化する。
５．レイアウト部１３は活性化されたイベントを受けて、ＭＭＰ画面の描画コマンドをグラフィック部に送信する。
６．グラフィック部は描画コマンドを解析し、キャンバスを生成する。
【０１５８】
この時、コンテンツ上でキャンバスに関連付けられているＤ．Ａ．と実際に関連付けを行う。
７．Ｄ．Ａ．は関連付けられたキャンバスの持つ描画領域へＭＭＰ出力する動画の映像を描き出す。
８．グラフィック部はキャンバスを含めＭＭＰ画面の全ての部品を描画する。
【０１５９】
図４０は、動画再生のシーケンス図を示す。
Ｓ１．シナリオ処理部１２は、モデル（ＭＭＰ）にＤ．Ａ．の生成を依頼する。
Ｓ２．モデルはＭＭＰの出力する動画の描画用にＤ．Ａ．を生成する。なお、Ｄ．Ａ．のリファレンスは共有変数に格納され、グラフィック部からもモデルからも相互に利用することができる。
Ｓ３．シナリオ処理部１２はコンテンツの記述に従い、モデルに描画開始を依頼する。
Ｓ４．既にｃｒｅａｔＬａｙｏｕｔを実施済みの場合、シナリオ処理部１２はＭＭＰ用レイアウトの画面表示開始のイベントを活性化する。
Ｓ５．レイアウト部１３は活性化されたイベントを受けて、ＭＭＰ画面の描画コマンドをグラフィック部に送信する。
Ｓ６．グラフィック部は描画コマンドを解析し、キャンバスを生成する。
Ｓ７．グラフィック部は、コンテンツ上でキャンバスに関連付けられているＤ．Ａ．とキャンバスとを実際に関連付けする。
Ｓ８．モデル（ＭＭＰ）は、キャンバスが生成した描画領域のリファレンスを取得する。
Ｓ９．グラフィック部はキャンバスを含めＭＭＰ画面の全ての部品を描画する。
Ｓ１０．Ｄ．Ａ．は関連付けられたキャンバスの持つ描画領域へＭＭＰ出力する動画の映像を描き出す。以降は、順次、描画が更新される。
【０１６０】
〔ソフトウェア構成〕
続いて、ソフトウェア構成について説明する。図４１は、３層にサブシステムが配置された概略コンポーネント図を示す。上述したように、本システムはプラットフォーム、機種に依存しない「抽象概念系」と、プラットフォーム、機種に依存する「実体系」と、「抽象概念系」と「実体系」を分離させる為のインターフェイスを規定する「実装系」の3層構造をとる。これに併せてサブシステム単位においても、コンポーネント構成は３層構造となる。なお、「」内がコンポーネント名となる。
【０１６１】
「シナリオ処理部抽象概念系」
・シナリオＭＬを解釈し、シナリオＭＬ内の状態遷移データを、実装系を通じて実体部に渡す。
・各種Ｄ．Ｄ．の記載内容に応じて、他のサブシステムとシナリオ処理部１２、またはシナリオ処理部内で利用するデータとイベントのマッピングを行う。これにより、サブシステム間でのデータの共有と、サブシステム間での処理の同期を行う。
・本システムの外部で発生するイベントメッセーシ（ＸＭＬ）を解釈し、本システム内部に通知する。
・シナリオＭＬの内部に定義されたデバイスの抽象表現を具象化する。
【０１６２】
「シナリオ処理部実装系」
・シナリオ処理部の抽象概念系−実体系間のインターフェイスを規定する。
【０１６３】
「シナリオ処理部実体系」
・実装系が規定するインターフェイスによって、シナリオＭＬに記載されたデータを保持し、実行する役割が課せられるが、実現方式、機能（役割）は規定しない。
【０１６４】
「レイアウト部抽象概念系」
・レイアウトＭＬを解釈し、必要とするスキンＭＬ、リソースＭＬを取り込んだ上で、画面の構成、意匠、遷移情報を、実装系を通じて実体系に渡す。
【０１６５】
「レイアウト部実装系」
・レイアウト部の抽象概念系−実体系間のインターフェイスを規定する。
【０１６６】
「レイアウト部実体系」
・実装系が規定するインターフェイスによって、画面の構成、意匠、遷移情報を保持し、グラフィックスデバイスに出力する役割が課せられるが、実現方式、機能（役割）は規定しない。
【０１６７】
「グラフィック部」
・レイアウト部と連携し、ディスプレイやタッチパネルなどのグラフィックデバイスとやり取りを行うことにより、ユーザと対話を行う。
【０１６８】
「ボイス部抽象概念系」
・ボイスＭＬを解決し、必要とするスキンＭＬ、リソースＭＬを取り込んだ上で、音声による対話内容、音声意匠を、実装系を通じて実体系に渡す。
【０１６９】
「ボイス部実装系」
・ボイス部の抽象概念系−実体系間のインターフェイスを規定する。
【０１７０】
「ホイス部実体系」
・実装系が規定するインターフェイスによって、音声による対話内容、音声意匠を保持し、サウンドデバイスに出力する役割が課せられるが、実現方式、機能（役割）は規定しない。
【０１７１】
「サウンド部」
・ボイス部から渡されるデータを保対し、実デバイスと連携することによって保持した内容の音声対話を実現する。また、ナビ等のモデルから直接音声対話を実行することもできる。
〔ＬＳｕＩの動作〕
以上説明した車載多機能装置によれば、ユーザインターフェイスをユーザやその他のシチュエーションに応じて自由に構成することができる。図４２は、車載多機能装置の利用形態の一例を示す図である。
【０１７２】
例えば、父、母、子の３人が車両に搭乗するものとして、この３人の個人情報を車載多機能装置に登録する。登録する個人情報は、例えば、趣味、嗜好、性別、年齢、職業、生年月日、星座、血液型、家族構成等である。父は、例えば、ゴルフや株価情報に興味があることが、母は、ショッピングやセキュリティに興味があることが、子はゲーム、映画、音楽、チャットに興味があることが登録される。
【０１７３】
また、車載多機能装置には、その時のシチュエーションが情報に応じて自動的に入力される。入力されるシチュエーションは、例えば、日時、曜日、天気、時間帯、目的地、現在地、出発地等である。日時、曜日、時間帯は車載のカレンダや外部から取得でき、天気は天気予報や温度センサ、日射センサ等から取得でき、目的地、現在地、出発地等はカーナビ装置３から取得できる。また、車載多機能装置には、車載しているハードウェアからアクセス可能な周辺のインフラの情報が得られる。例えば、お買い得情報、イベント情報、道路情報等である。
【０１７４】
車両に父が搭乗すれば、スマートキーや生体認識情報、ボタンなどによる入力により、車載多機能装置は父が搭乗したことを検知する。そして、ＬＳｕＩは父の個人情報とシチュエーションに応じて、最適なシナリオを抽出し、プラットフォームに提供する。ＬＳｕＩは、例えば、夕刻であればその日の株価情報を表示し、また、道路が混み始めたら交通情報を提供するシナリオを実行する。その日、ゴルフのトーナメントがあれば、その結果を表示することもできる。このとき表示される画面は、父の好むレイアウトやフォント、スキンであり、父の好む音声である。
【０１７５】
また、車両に、さらに母と子が搭乗するような場合、子がゲームを実行していても、時間帯やシチュエーションによっては、ＬＳｕＩが近くのレストランやショッピングの情報を表示するシナリオを実行するので、母がレストランを選択できる。なお、シート毎にディスプレイを設けてもよい。
【０１７６】
以上のように、本実施の形態の車載多機能装置は、ユーザに対するシステムの振る舞いをメタデータ（ＸＭＬ）で記述したため、ユーザ毎に適切なヒューマンインターフェイスを提供できる。メタデータを補充することで、容易に特徴のあるヒューマンインターフェイスを追加、拡張することができる。
【０１７７】
また、ＭＶＣアーキテクチャにシナリオという概念を導入したため、ユーザインターフェイスとロジックとを分離できる。メタデータを実行する抽象概念系は、プラットフォームに依存しないため、別の車両への移植等も容易である。
【図面の簡単な説明】
【０１７８】
【図１】ＭＶＣアーキテクチャの概念図である。
【図２】マルチメディアアーキテクチャが適用された車載多機能装置のハードウェア構成図、マルチメディアアーキテクチャの全体システム構成図である。
【図３】ＸＭＬメッセージによるサブシステム間の疎結合の概略を示す図、及び、状態遷移の概念を示す図である。
【図４】抽象概念系、実装系及び実体系の関係を示す図である。
【図５】シナリオ処理部、レイアウト部、ボイス部の関係を示す図である。
【図６】グラフィック部とシナリオ処理部、サウンド部の関係を示す図である
【図７】サウンド部とボイス部、グラフィック部の関係を示す図である。
【図８】ＵＩサーバがＵＲＩを参照する概念図を示す。
【図９】ロケーション管理とライフサイクル管理の概要を示す図である。
【図１０】モデルの概要を示す図である。
【図１１】ＬＳｕＩの機能概略を示す図である。
【図１２】コンテンツサーバの概要を示す図である。
【図１３】メヅセージＭＬ通信（リクエスト）にサブコンポーネントＡからサブコンポーネントＢへリクエストメッセージを送信する処理の概念を示す図である。
【図１４】図１３の処理の後、サブシステムＢからサブシステムＡにレスポンスメッセージを送信する処理の概念を示す図である。
【図１５】分散ＦＷのロケーション管理へ生成した実体オフジュクトの参照を登録する処理のシーケンス図、ＩＤＬ呼び出しのシーケンス図である。
【図１６】動的インターフェイス呼び出し時におけるＣＯＲＢＡ通信の概念を示す図である。
【図１７】ＤＩＬ呼び出しのシーケンス図である。
【図１８】コマンドリスト通信におけるＣＯＲＢＡ通信の概念を示す図である。
【図１９】ＣＬＬ呼び出しのシーケンス図、イベントコールバックのシーケンス図である。
【図２０】イベント通信の概念を示す図である。
【図２１】共有変数による通信の概念を示す図である。
【図２２】システムの起動におけるサブシステム間及び外部システムとの基本相互作用を示す図である。
【図２３】システム起動のシーケンス図である。
【図２４】シナリオパースにおけるサブシステム間及び外部システムとの基本相互作用を示す図である。
【図２５】シナリオパースのシーケンス図である。
【図２６】認証画面表示におけるサブシステム間及び外部システムとの基本相互作用を示す図である。
【図２７】認証画面表示のシーケンス図である。
【図２８】ユーザ認証及びシナリオ切り替えにおけるサブシステム間及び外部システムとの基本相互作用を示す図である。
【図２９】元のシナリオを破棄する場合のサブシステム間及び外部システムとの基本相互作用を示す図である。
【図３０】ユーザ認証とシナリオ切り替えのシーケンス図である。
【図３１】レイアウト部の内部で画面切替えが行われる場合の相互作用の概略を示す図である。
【図３２】レイアウト部の内部における画面切り替えのシーケンス図である。
【図３３】スキンＭＬが切り替わる相互作用の概略を示す図である。
【図３４】スキンＭＬの画面切り替えのシーケンス図である。
【図３５】レイアウトＭＬが切り替わる相互作用の概略を示す図である。
【図３６】レイアウトＭＬの切り替えのシーケンス図である。
【図３７】シナリオＭＬが切り替わる相互作用の概略を示す図である。
【図３８】シナリオＭＬの切り替えのシーケンス図である。
【図３９】動画再生の相互作用の概略を示す図である。
【図４０】動画再生のシーケンス図である。
【図４１】３層にサブシステムが配置された概略コンポーネント図を示す。
【図４２】車載多機能装置の利用形態の一例を示す図である。
【符号の説明】
【０１７９】
１ 車載多機能装置
２ 入力装置
３ カーナビ装置
４ ラジオ／テレビユニット
５ メディアプレーヤ
６ 表示装置
７ スピーカ
８ 通信ユニット
９ 記憶装置
１０ 制御装置
１１ ＬＳｕＩ連携部
１２ シナリオ処理部
１３ レイアウト部
１４ ボイス部
１５ ＵＩリポジトリ
１６ グラフィック部
１７ サウンド部
２０ ＵＩサーバ
【特許請求の範囲】
【請求項１】
ユーザインターフェイスを介してユーザからの入力を受け付け、出力装置からユーザにサービスを提供する車載多機能装置において、
メタデータにより記述された前記ユーザインターフェイス及び前記サービスの内容を記憶したメタデータ記憶手段と、
前記メタデータを解釈して前記ユーザインターフェイス及び前記サービスを生成する制御部と、
を有することを特徴とする車載多機能装置。
【請求項２】
前記メタデータ記憶手段は、前記ユーザインターフェイス又は前記サービスの遷移をメタデータにより記述した遷移情報を記憶している、
ことを特徴とする請求項１記載の車載多機能装置。
【請求項３】
前記ユーザインターフェイス及び前記サービスの内容を記述したメタデータはそれぞれ独立して変更可能である、
ことを特徴とする請求項１記載の車載多機能装置。
【請求項４】
更新頻度の高い描画を反映する動画用アダプタを有し、
更新頻度の高い描画がある場合、前記制御部は前記ユーザインターフェイスに描画領域を設け、
前記動画アダプタが前記描画領域に描画する、
ことを特徴とする請求項１ないし３いずれか記載の車載多機能装置。
【請求項５】
前記ユーザを識別する手段と、道路の交通状況、日時等のシチュエーションを判別する手段とを有し、
前記制御部は、前記ユーザ又は前記シチュエーションに応じて、前記メタデータ記憶手段に記憶された前記メタデータを抽出し、
前記制御部は、前記ユーザ又は前記シチュエーションに応じた前記ユーザインターフェイス又は前記サービスを生成する、
ことを特徴とする請求項１〜４いずれか記載の車載多機能装置。
【請求項６】
ユーザインターフェイス及びサービスの内容がそれぞれ独立に記述されると共に、前記ユーザインターフェイス及び前記サービスの遷移情報を規定したメタデータであって、
コンピュータに、
前記遷移情報に基づき前記ユーザインターフェイス又は前記サービスを生成するステップを、
実行させるためのメタデータ。
【請求項１】
ユーザインターフェイスを介してユーザからの入力を受け付け、出力装置からユーザにサービスを提供する車載多機能装置において、
メタデータにより記述された前記ユーザインターフェイス及び前記サービスの内容を記憶したメタデータ記憶手段と、
前記メタデータを解釈して前記ユーザインターフェイス及び前記サービスを生成する制御部と、
を有することを特徴とする車載多機能装置。
【請求項２】
前記メタデータ記憶手段は、前記ユーザインターフェイス又は前記サービスの遷移をメタデータにより記述した遷移情報を記憶している、
ことを特徴とする請求項１記載の車載多機能装置。
【請求項３】
前記ユーザインターフェイス及び前記サービスの内容を記述したメタデータはそれぞれ独立して変更可能である、
ことを特徴とする請求項１記載の車載多機能装置。
【請求項４】
更新頻度の高い描画を反映する動画用アダプタを有し、
更新頻度の高い描画がある場合、前記制御部は前記ユーザインターフェイスに描画領域を設け、
前記動画アダプタが前記描画領域に描画する、
ことを特徴とする請求項１ないし３いずれか記載の車載多機能装置。
【請求項５】
前記ユーザを識別する手段と、道路の交通状況、日時等のシチュエーションを判別する手段とを有し、
前記制御部は、前記ユーザ又は前記シチュエーションに応じて、前記メタデータ記憶手段に記憶された前記メタデータを抽出し、
前記制御部は、前記ユーザ又は前記シチュエーションに応じた前記ユーザインターフェイス又は前記サービスを生成する、
ことを特徴とする請求項１〜４いずれか記載の車載多機能装置。
【請求項６】
ユーザインターフェイス及びサービスの内容がそれぞれ独立に記述されると共に、前記ユーザインターフェイス及び前記サービスの遷移情報を規定したメタデータであって、
コンピュータに、
前記遷移情報に基づき前記ユーザインターフェイス又は前記サービスを生成するステップを、
実行させるためのメタデータ。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図３５】
【図３６】
【図３７】
【図３８】
【図３９】
【図４０】
【図４１】
【図４２】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図３５】
【図３６】
【図３７】
【図３８】
【図３９】
【図４０】
【図４１】
【図４２】
【公開番号】特開２００７−３１７１２１（Ｐ２００７−３１７１２１Ａ）
【公開日】平成１９年１２月６日（２００７．１２．６）
【国際特許分類】
【出願番号】特願２００６−１４８６８０（Ｐ２００６−１４８６８０）
【出願日】平成１８年５月２９日（２００６．５．２９）
【出願人】（０００００３２０７）トヨタ自動車株式会社 (59,920)
【Ｆターム（参考）】
【公開日】平成１９年１２月６日（２００７．１２．６）
【国際特許分類】
【出願日】平成１８年５月２９日（２００６．５．２９）
【出願人】（０００００３２０７）トヨタ自動車株式会社 (59,920)
【Ｆターム（参考）】
[ Back to top ]