JP2005031975A

JP2005031975A - 情報提供システム

Info

Publication number: JP2005031975A
Application number: JP2003196014A
Authority: JP
Inventors: Atsushi Kono; 篤河野; Masaharu Umetsu; 正春梅津; Mitsuo Shitaya; 光生下谷; Kazuma Kaneko; 和磨金子; Fumitaka Satou; 史尚佐藤; Yosuke Asai; 陽介浅井; Tetsuo Kamikawa; 哲生上川; Harumi Minemura; 治実峯村
Original assignee: Mitsubishi Electric Corp
Current assignee: Mitsubishi Electric Corp
Priority date: 2003-07-11
Filing date: 2003-07-11
Publication date: 2005-02-03
Also published as: CN1581087A; CN1324472C; DE102004033371A1; US20050010932A1

Abstract

【課題】リソースの競合を招くことなく、複数のサービスアプリケーションを同時に動作させることができる情報提供システムを得ることを目的とする。
【解決手段】拡張機能モジュール２７上で同時に動作する複数のＪａｖａ（登録商標、以下同じ）アプリ２８，２９が組み込まれた場合、アプリ管理モジュール３２，３４が複数のＪａｖａアプリ２８，２９の動作を管理する。これにより、情報提供システムのリソースの競合を招くことなく、複数のＪａｖａアプリ２８，２９を同時に動作させることができる。
【選択図】図２

Description

【０００１】
【発明の属する技術分野】
この発明は、各種の情報サービスを提供する情報提供システムに関するものである。
【０００２】
【従来の技術】
従来の情報提供システムは、ナビゲーションサービスのような基本機能モジュールと、Ｊａｖａ（登録商標、以下同じ）仮想マシン（ＪａｖａＶＭ（ＶｉｒｔｕａｌＭａｃｈｉｎｅ））上で動作するＪａｖａアプリのような拡張機能モジュールとから構成され、その基本機能モジュール及び拡張機能モジュールが相手側と通信するインタフェースを備えることにより、その基本機能モジュールと拡張機能モジュールが相互に連携して動作できるようにしている（例えば、特許文献１参照）。
【０００３】
【特許文献１】
特開２００２−３１８７０２号公報（段落番号［０００８］、図２）
【０００４】
【発明が解決しようとする課題】
従来の情報提供システムは以上のように構成されているので、基本機能モジュールとＪａｖａアプリを連携して動作させることができる。しかし、Ｊａｖａアプリの動作を管理するモジュールが存在しないため、Ｊａｖａ仮想マシン上で同時に動作する複数のＪａｖａアプリが組み込まれると、複数のＪａｖａアプリがシステムのリソースを競合してしまうことがあるなどの課題があった。
【０００５】
この発明は上記のような課題を解決するためになされたもので、リソースの競合を招くことなく、複数のサービスアプリケーションを同時に動作させることができる情報提供システムを得ることを目的とする。
【０００６】
【課題を解決するための手段】
この発明に係る情報提供システムは、拡張機能モジュール上で同時に動作するアプリ管理モジュールが複数のサービスアプリケーションの動作を管理するようにしたものである。
【０００７】
【発明の実施の形態】
以下、この発明の実施の一形態を説明する。
実施の形態１．
図１はこの発明の実施の形態１による情報提供システムを示すハードウェア構成図であり、図において、ＲＯＭ１は基本機能モジュール及び拡張機能モジュールのプログラムを記録している。外部記憶メディア２は例えばＤＶＤ−ＲＯＭやＣＤ−ＲＯＭやハードディスクから構成され、地図データベースや拡張車載サービスアプリを記憶している。外部記憶装置ドライブ３は外部記憶メディア２から例えば地図データを読み出し、その地図データを外部記憶装置Ｉ／Ｆ４を介してＣＰＵ９に出力する。
周辺機器５は例えばＧＰＳ受信機、ジャイロ、車速パルスセンサ、スピーカ、携帯電話などであり、例えばＧＰＳ信号を周辺機器Ｉ／Ｆ６を介してＣＰＵ９に出力する。
【０００８】
ユーザ操作部７は例えばリモコン、各種スイッチ、タッチパネルなどであり、例えば操作信号を操作部Ｉ／Ｆ８を介してＣＰＵ９に出力する。ＣＰＵ９はユーザ操作部７から出力された操作信号にしたがって、例えば地図データやＧＰＳ信号を参照しながら基本機能モジュールや拡張機能モジュールのプログラムを実行する。ＲＡＭ１０にはＣＰＵ９がプログラムを実行する際に使用するデータ等が一時的に格納される。
グラフィック制御回路１１はＣＰＵ９から出力される描画命令にしたがって画像をディスプレイ１２に描画する。
【０００９】
図２はこの発明の実施の形態１による情報提供システムを示すソフトウェア構成図であり、図において、Ｈ／Ｗ２１は図１の情報提供システムのハードウェアに相当する。デバイスドライバ２２はＨ／Ｗ２１の各処理部（例えば、ＣＰＵ９、外部記憶装置ドライブ３）を制御する。ＯＳ２３はデバイスドライバ２２を用いてＨ／Ｗ２１の各処理部を制御するとともに、基本機能モジュール２４や拡張機能モジュール２７の動作環境を提供してプログラムを実行する。
基本機能モジュール２４は基本的な車載情報サービスとして、例えば車両の現在位置や施設情報を提供するナビゲーションサービス２５から構成されている。Ｊａｖａモジュール２６はナビゲーションサービス２５がＪａｖａアプリ２８，２９と連携を図る際、ＪａｖａＶＭ３０内のアプリ管理モジュールインタフェースモジュール３１と通信を実施する。
【００１０】
拡張機能モジュール２７はＪａｖａ言語でプログラミングされたサービスアプリケーションであるＪａｖａアプリ２８，２９が組み込まれると、基本機能モジュール２４と連携を図りながらＪａｖａアプリ２８，２９を起動させるＪａｖａ仮想マシン（ＪａｖａＶＭ）３０から構成されている。ここでのＪａｖａＶＭ３０は、例えばサンマイクロシステムズにより定義されているＣＤＣ（ＣｏｎｎｅｃｔｅｄＤｅｖｉｃｅＣｏｎｆｉｇｕｒａｔｉｏｎ）及びＦＰ（ＦｏｕｎｄａｔｉｏｎＰｒｏｆｉｌｅ）を満たすＪａｖａ仮想マシンであり、Ｊａｖａアプリ２８，２９がＪａｖａＶＭ３０のプロセス内でのスレッドとして動作することによって実現される。
Ｊａｖａアプリ２８は例えば天気予報を行うサービスアプリケーションであり、Ｊａｖａアプリ２９は例えば運勢を占うサービスアプリケーションである。
【００１１】
アプリ管理モジュール３２は基本機能モジュール２４のサブモジュールとして搭載され、ＪａｖａＶＭ３０内のアプリ管理モジュールインタフェースモジュール３１と通信を実施するＪａｖａＶＭＩ／Ｆモジュール３３を備えている。アプリ管理モジュール３４は拡張機能モジュール２７に組み込まれるＪａｖａアプリの１つとして搭載されている。なお、基本機能モジュール２４と拡張機能モジュール２７に分散して配置されているアプリ管理モジュール３２，３４は、相互に連携してＪａｖａアプリ２８，２９の動作を管理する。
アプリ管理モジュール３２，３４は下記の管理機能を有している。
（１）Ｊａｖａアプリの登録（追加）／削除／更新
（２）Ｊａｖａアプリの起動／停止／状態管理
（３）Ｊａｖａアプリへの入力管理
（４）Ｊａｖａアプリからの画面出力管理
【００１２】
次に動作について説明する。
（１）Ｊａｖａアプリの追加／削除／更新について
Ｊａｖａアプリの追加／削除／更新は、拡張機能モジュール２７に配置されているアプリ管理モジュール３４が行う。図５はＪａｖａアプリの追加処理を示すフローチャートである。
まず、アプリ管理モジュール３４は、内蔵しているアプリ管理テーブルの初期化を行う（ステップＳＴ１）。
ここで、アプリ管理テーブルは、図６に示すように、情報提供システムに組み込まれるＪａｖａアプリの名称と、Ｊａｖａアプリクラス名と、Ｊａｖａアプリクラスが配置されているＲＡＭ１０のアドレス（Ｊａｖａアプリクラスへのポインタ）とが記述されるテーブルである。この実施の形態１では、説明を簡単にするため、各Ｊａｖａアプリクラスのメモリサイズを一定サイズにしているが、不定サイズであっても構わない。
【００１３】
次に、アプリ管理モジュール３４は、予め設定された追加アプリリスト（図７を参照）に記載されたＪａｖａアプリ（Ｊａｖａアプリクラス）を外部記憶メディア２から読み出し（ステップＳＴ２）、そのＪａｖａアプリクラスをＨ／Ｗ２１上のＲＡＭ１０に配置するように、ＪａｖａＶＭ３０に対して要求する（ステップＳＴ３）。
これにより、ＪａｖａＶＭ３０は、ＪａｖａアプリクラスをＨ／Ｗ２１上のＲＡＭ１０に配置し、そのＪａｖａアプリクラスのＲＡＭアドレス（ポインタ）をアプリ管理モジュール３４に返信する。
ここで、追加アプリリストは、図７に示すように、Ｊａｖａアプリの名称と、Ｊａｖａアプリクラス名と、Ｊａｖａアプリクラスが格納されている場所を示すディレクトリ名とが記述されているテーブルであり、アプリ管理モジュール３４は、追加アプリリストを参照することにより、追加するＪａｖａアプリの格納場所を把握する。
【００１４】
アプリ管理モジュール３４は、ＪａｖａＶＭ３０からＪａｖａアプリクラスのＲＡＭアドレス（ポインタ）を受けると、そのＪａｖａアプリのアプリ名称、Ｊａｖａアプリクラス名、ＪａｖａアプリクラスのＲＡＭアドレス（ポインタ）をアプリ管理テーブルに追加記述することにより、アプリ管理テーブルを更新する（ステップＳＴ４）。
なお、アプリ管理テーブルの更新方法については、アプリ管理テーブルの最後の行に逐次追加記述することにより実現可能である。即ち、追加アプリリストを参照して、更に追加すべきＪａｖａアプリがあるか否かを判断し（ステップＳＴ５）、更に追加するＪａｖａアプリがある場合には、ステップＳＴ２のＪａｖａアプリの読出処理に戻って処理を繰り返し実行し、追加するＪａｖａアプリがない場合には、追加処理を終了する。
なお、上記の説明では、追加するＪａｖａアプリを予め設定した追加アプリリストに記載されたＪａｖａアプリとしているが、外部記憶メディア２からＪａｖａアプリクラスを検索し、動的に追加アプリリストを作成して追加処理を実施してもよい。
【００１５】
図８はＪａｖａアプリの削除処理を示すフローチャートである。
アプリ管理モジュール３４は、削除対象のＪａｖａアプリの指定を受けるため、図９に示すようなメニュー画面をディスプレイ１２に表示する。
情報提供システムのユーザは、メニュー画面に表示されているＪａｖａアプリの中から、削除対象のＪａｖａアプリを指定する。例えば、ユーザ操作部７であるタッチパネルを使用して削除対象のＪａｖａアプリを指定する（ステップＳＴ１１）。図９の例では、“Ｊａｖａアプリ１”が削除対象のＪａｖａアプリとして指定されている。
アプリ管理モジュール３４は、ユーザ操作部７の操作内容から削除対象のＪａｖａアプリを認識すると、アプリ管理テーブルから削除対象のＪａｖａアプリ（Ｊａｖａアプリ名称）に対応するＪａｖａアプリクラス名を検索し（ステップＳＴ１２）、そのＪａｖａアプリクラスを削除するように、ＪａｖａＶＭ３０に対して要求する（ステップＳＴ１３）。
【００１６】
これにより、ＪａｖａＶＭ３０は、アプリ管理テーブルから削除対象のＪａｖａアプリが記述されている行を削除し、その削除した行の下にある行を上に詰める処理を実施して、削除処理を終了する（ステップＳＴ１４）。
この実施の形態１では、ユーザが削除対象のＪａｖａアプリを指定するものについて示したが、他のＪａｖａアプリが削除対象のＪａｖａアプリを指定するようにしてもよい。また、基本機能モジュール２４のナビゲーションサービス２５が削除対象のＪａｖａアプリを指定するようにしてもよい。指定方法としては、Ｊａｖａアプリ名称を指定する方法、Ｊａｖａアプリクラス名を指定する方法がある。
【００１７】
Ｊａｖａアプリの更新処理は次のように実施される。
アプリ管理モジュール３４は、更新対象のＪａｖａアプリが削除対象のＪａｖａアプリと同様にして指定されると、更新対象のＪａｖａアプリを削除対象のＪａｖａアプリと同様にして削除する。
その後、アプリ管理モジュール３４は、外部記憶メディア２から更新対象のＪａｖａアプリを検索し、そのＪａｖａアプリを上記の方法で追加することにより更新処理を完了する。
なお、ここでは、外部記憶メディア２から更新対象のＪａｖａアプリを検索しているが、周辺機器５である携帯電話を使用して、例えば、ネットワーク上のサーバ装置等から更新対象のＪａｖａアプリをダウンロードして追加してもよい。また、ＲＯＭ上に記録されたＪａｖａアプリを検索し、追加しても構わない。
【００１８】
（２）Ｊａｖａアプリの起動／停止／状態管理について
Ｊａｖａアプリの起動／停止／状態管理は、拡張機能モジュール２７に配置されているアプリ管理モジュール３４が各Ｊａｖａアプリのメソッド（関数、以下同じ）を呼び出すことによって実現する。図１０はＪａｖａアプリの起動処理を示すフローチャートである。
アプリ管理モジュール３４は、起動対象のＪａｖａアプリが削除対象のＪａｖａアプリと同様にして指定されると（ステップＳＴ２１）、アプリ管理テーブルから起動対象のＪａｖａアプリのＪａｖａアプリクラス名と、ＪａｖａアプリクラスのＲＡＭアドレス（ポインタ）とを検索する（ステップＳＴ２２）。
【００１９】
次に、アプリ管理モジュール３４は、Ｊａｖａアプリクラスの先頭に記述されているＪａｖａクラス情報から、各Ｊａｖａアプリの開始メソッドとして定義しているｓｔａｒｔメソッドが配置されているＲＡＭアドレスに対する開始アドレスからのオフセット値を読み取り（ステップＳＴ２３）、そのｓｔａｒｔメソッドのＲＡＭアドレスからＪａｖａプログラムを実行するように、ＪａｖａＶＭ３０に対して依頼して（ステップＳＴ２４）、Ｊａｖａアプリの起動処理を終了する。
【００２０】
ここでは、ｓｔａｒｔメソッドのＲＡＭアドレスをＪａｖａアプリクラス情報から読み取るようにしているが、ある一定のオフセット値のアドレスにｓｔａｒｔメソッドを配置するようにしてもよい。
上記の説明は、Ｊａｖａアプリの起動方法であるが、基本的には、サービスアプリであるＪａｖａアプリのメソッドを呼び出すことによって、Ｊａｖａアプリの停止（定義：ｓｔｏｐメソッド）や、Ｊａｖａアプリの状態管理（定義：ｉｓＡｌｉｖｅメソッド）を同様の方法で実現することができる。
なお、ＪａｖａアプリのｉｓＡｌｉｖｅメソッドは、Ｊａｖａアプリが正常に動作しているか否かを示す情報をアプリ管理モジュール３４に返信する。
【００２１】
（３）Ｊａｖａアプリへの入力管理について
情報提供システムに対するユーザの入力は、ナビゲーションサービス２５などの基本機能モジュール２４に対する入力と、Ｊａｖａアプリ２８，２９などの拡張機能モジュール２７に対する入力があるため、入力管理処理は、アプリ管理モジュール３２，３４の双方が連携して行う。
最初に、基本機能モジュール２４に配置されているアプリ管理モジュール３２の入力管理処理について説明する。図１１はアプリ管理モジュール３２の入力管理処理を示すフローチャートである。
ただし、ここでは、図１におけるユーザ操作部７がタッチパネルであるとし、操作部Ｉ／Ｆ８ではユーザがタッチパネルをタッチした場所の座標をＣＰＵ９に対して渡すものとする（タッチパネルの処理については、既に周知技術であるタッチパネル機能付きカーナビのタッチパネルの動作と同様であるため説明を省略する）。
【００２２】
まず、アプリ管理モジュール３２は、デバイスドライバ２２及びＯＳ２３を介して、操作部Ｉ／Ｆ８がＣＰＵ９に渡す座標を受信する（ステップＳＴ３１）。
次に、アプリ管理モジュール３２は、現在、画面を出力しているモジュールがナビゲーションサービス２５などの基本機能モジュール２４であるのか、Ｊａｖａアプリ２８，２９などの拡張機能モジュール２７であるのかを判断する（ステップＳＴ３２）。画面出力管理方法については後述する。
【００２３】
仮に、画面を出力しているモジュールがナビゲーションサービス２５であれば、その受信した座標をナビゲーションサービス２５に与える（ステップＳＴ３３）。
一方、画面を出力しているモジュールがＪａｖａアプリ２８，２９などの拡張機能モジュール２７であれば、ＪａｖａＶＭＩ／Ｆモジュール３３及びアプリ管理モジュールインタフェースモジュール３１を利用して、その受信した座標をアプリ管理モジュール３４に送信する（ステップＳＴ３４）。
以降、アプリ管理モジュール３２は座標の受信処理に戻る（ステップＳＴ３１）。
【００２４】
次に、拡張機能モジュール２７に配置されているアプリ管理モジュール３４の入力管理処理について説明する。図１２はアプリ管理モジュール３４の入力管理処理を示すフローチャートである。
アプリ管理モジュール３４は、基本機能モジュール２４のアプリ管理モジュール３２から送信される座標を受信すると（ステップＳＴ４１）、現在画面表示しているＪａｖａアプリを検索する（ステップＳＴ４２）。
例えば、現在画面表示しているＪａｖａアプリがＪａｖａアプリ２８であれば、その受信した座標をＪａｖａアプリ２８に与える（ステップＳＴ４３）。Ｊａｖａアプリ２８に対する座標の送信処理については、Ｊａｖａプログラムのイベント処理を用いることで実現可能である。
以降、アプリ管理モジュール３４は、アプリ管理モジュール３２から送信される座標の受信処理に戻る（ステップＳＴ４１）。
【００２５】
上記の説明では、画面出力しているのは、基本機能モジュール２４、あるいは、拡張機能モジュール２７のいずれかであるものについて示したが、図１３に示すように、基本機能モジュール２４のナビゲーションサービス２５と拡張機能モジュール２７のＪａｖａアプリ２８等が同時に画面出力してもよい。画面管理方法については後述する。
この場合、座標に応じて送信対象のモジュールを変更すればよい。また、拡張機能モジュール２７側でも同様に、単一のＪａｖａアプリのみが画面表示しているだけではなく、複数のＪａｖａアプリが同時に画面表示してもよい（図１４を参照）。
【００２６】
また、上記の説明では、入力したタッチパネルの座標が先に基本機能モジュール２４に配置されているアプリ管理モジュール３２に与えられるものについて示したが、逆に拡張機能モジュール２７に配置されているアプリ管理モジュール３４に先に与えられるようにしてもよい。
また、上記の説明では、ユーザ操作部７としてタッチパネルを採用しているが、現在のカーナビのユーザ操作部７として一般的に利用されているジョイスティックを採用しても同様のことが可能である（画面出力で、どのモジュールが出力対象となっているかをハイライト表示する）。
【００２７】
（４）Ｊａｖａアプリからの画面出力管理について
サービスアプリの画面出力については、基本機能モジュール２４と拡張機能モジュール２７の両方から画面出力されるので、入力管理と同様に、出力管理処理は、アプリ管理モジュール３２，３４の双方が連携して行う。
なお、画面出力処理については、基本機能モジュール２４、拡張機能モジュール２７の各モジュールが、ＯＳ２３及びデバイスドライバ２２を介して、Ｈ／Ｗ２１のグラフィック制御回路１１を制御することによって画面出力することができる。
【００２８】
最初に、基本機能モジュール２４に配置されているアプリ管理モジュール３２の画面出力管理について説明する。図１５はアプリ管理モジュール３２の出力管理処理を示すフローチャートである。
アプリ管理モジュール３２は、ナビゲーションサービス２５などの基本機能モジュール２４が画面出力しているのか、あるいは、Ｊａｖａアプリ２８，２９などの拡張機能モジュール２７が画面出力しているのかの管理を行う。
アプリ管理モジュール３２は、デフォルト（情報提供システム起動後）においては、基本機能モジュール２４のナビゲーションサービス２５の画面出力を有効にする。
【００２９】
その後、拡張機能モジュール２７のＪａｖａＶＭ３０がＪａｖａアプリ２８，２９から画面の出力要求を受けると、拡張機能モジュール２７のアプリ管理モジュール３４が画面出力許可要求を基本機能モジュール２４のアプリ管理モジュール３２に発行する。
基本機能モジュール２４のアプリ管理モジュール３２は、拡張機能モジュール２７から画面出力許可要求を受信すると（ステップＳＴ５１）、ナビゲーションサービス２５に対して画面出力変更許可伺いを出力する（ステップＳＴ５２）。基本機能モジュール２４のアプリ管理モジュール３２は、ナビゲーションサービス２５から画面出力変更を許可しない旨の応答を受けると（ステップＳＴ５３）、画面出力変更却下通知を拡張機能モジュール２７のアプリ管理モジュール３４に送信する（ステップＳＴ５４）。
【００３０】
基本機能モジュール２４のアプリ管理モジュール３２は、ナビゲーションサービス２５から画面出力変更を許可する旨の応答を受けると（ステップＳＴ５３）、画面出力変更許可通知を拡張機能モジュール２７のアプリ管理モジュール３４に送信する（ステップＳＴ５５）。
基本機能モジュール２４のアプリ管理モジュール３２は、画面出力変更許可通知を送信すると、現在画面出力モジュール情報（現在、どのモジュールが画面出力しているのかを管理する情報）を変更する（ステップＳＴ５６）。即ち、現在画面出力モジュール情報を基本機能モジュール２４のナビゲーションサービス２５から拡張機能モジュール２７のＪａｖａＶＭ３０に変更する。
【００３１】
なお、拡張機能モジュール２７のアプリ管理モジュール３４は、アプリ管理モジュール３４自身が画面出力する場合、基本機能モジュール２４のアプリ管理モジュール３２から画面出力変更許可通知を受信した時のみＯＳ２３に対して画面出力処理を行う。
逆に、拡張機能モジュール２７のＪａｖａＶＭ３０が画面出力している場合において、基本機能モジュール２４のナビゲーションサービス２５が画面出力を希望する場合についても、上記と同様の処理によって画面出力変更を行う。
【００３２】
次に、拡張機能モジュール２７に配置されているアプリ管理モジュール３４の出力管理処理について説明する。図１６はアプリ管理モジュール３４の出力管理処理を示すフローチャートである。
ただし、基本機能モジュール２４との画面出力切替については、上記の説明の通りであるため、ここでは、拡張機能モジュール２７のアプリ管理モジュール３４が、同時動作している複数のＪａｖａアプリ２８，２９のうち、どのＪａｖａアプリが画面出力しているかの管理処理について説明する。
【００３３】
同時動作している複数のＪａｖａアプリ２８，２９のうち、例えば、Ｊａｖａアプリ２８が画面出力を希望すると、Ｊａｖａアプリ２８は、画面出力要求をアプリ管理モジュール３４に発行する（ステップＳＴ６１）。
拡張機能モジュール２７のアプリ管理モジュール３４は、現在、ＪａｖａＶＭ３０が画面出力していない場合、即ち、基本機能モジュール２４のナビゲーションサービス２５が画面出力している場合（ステップＳＴ６２）、上述したように、拡張機能モジュール２７側で画面出力できるようにするために、画面出力許可要求を基本機能モジュール２４のアプリ管理モジュール３２に送信する（ステップＳＴ６３）。
これにより、拡張機能モジュール２７のアプリ管理モジュール３４は、基本機能モジュール２４のアプリ管理モジュール３２から画面出力変更許可通知を受けると（ステップＳＴ６４）、画面出力要求を発行したＪａｖａアプリ２８に対して画面出力許可通知を出力する（ステップＳＴ６７）。
【００３４】
拡張機能モジュール２７のアプリ管理モジュール３４は、現在、ＪａｖａＶＭ３０が画面出力をしている場合（ステップＳＴ６２）、画面出力Ｊａｖａアプリ情報（現在、どのＪａｖａアプリが画面出力をしているかを示す情報（Ｊａｖａ（登録商標、以下同じ）アプリ名称で管理））を参照して、現在画面出力しているＪａｖａアプリを特定する。ここでは、説明の便宜上、Ｊａｖａアプリ２９が現在画面出力しているＪａｖａアプリであるとする。
拡張機能モジュール２７のアプリ管理モジュール３４は、現在画面出力しているＪａｖａアプリ２９に対して画面出力を他のＪａｖａアプリに変更してもよいかを問い合わせる（ステップＳＴ６５）。
【００３５】
拡張機能モジュール２７のアプリ管理モジュール３４は、現在画面出力しているＪａｖａアプリ２９から画面出力変更を許可する旨の応答を受けると（ステップＳＴ６６）、画面出力要求を発行したＪａｖａアプリ２８に対して画面出力許可通知を出力する（ステップＳＴ６７）。
一方、現在画面出力しているＪａｖａアプリ２９から画面出力変更を許可しない旨の応答を受けると（ステップＳＴ６６）、画面出力要求を発行したＪａｖａアプリ２８に対して画面出力却下通知を出力する（ステップＳＴ６８）。
【００３６】
なお、上記の説明では、Ｊａｖａアプリ間で画面出力しているＪａｖａアプリを変更する場合、現在画面出力しているＪａｖａアプリに変更許可を問い合わせるようにしているが、問い合わせずに強制的に切り替えても構わない。また、Ｊａｖａアプリにプライオリティ（優先度）を持たせておき、アプリ管理テーブルにプライオリティを加えておくことによって、優先度の高いＪａｖａアプリからの画面出力要求を優先するようにしてもよい。
【００３７】
以上で明らかなように、この実施の形態１によれば、拡張機能モジュール２７上で同時に動作する複数のＪａｖａアプリ２８，２９が組み込まれた場合、アプリ管理モジュール３２，３４が複数のＪａｖａアプリ２８，２９の動作を管理するように構成したので、情報提供システムのリソースの競合を招くことなく、複数のＪａｖａアプリ２８，２９を同時に動作させることができる効果を奏する。したがって、複数のＪａｖａアプリ２８，２９が連携して起動／停止することが可能となり、拡張車載情報サービスの価値が向上する。例えば、ゲームを起動する前にディーラサービス等の広告を表示する宣伝アプリを表示させることが容易に実現することができる。
【００３８】
また、この実施の形態１によれば、アプリ管理モジュール３２，３４が拡張機能モジュール２７に対するＪａｖａアプリの追加処理、削除処理及び更新処理を実施するように構成したので、同一のＪａｖａアプリを重複することなく、情報提供システムに組み込むことが可能になり、余計なリソース（ＲＡＭ容量およびもしくはディスク容量）の使用を回避することができる効果を奏する。
【００３９】
また、この実施の形態１によれば、アプリ管理モジュール３２，３４が基本機能モジュール２４のナビゲーションサービス２５又はＪａｖａアプリ２８，２９から画面出力要求を受けると、その画面出力要求に応じて基本機能モジュール２４のナビゲーションサービス２５又はＪａｖａアプリ２８，２９に画面出力許可を与えるように構成したので、複数のＪａｖａアプリ２８，２９が画面出力する場合において、所望のＪａｖａアプリの画面出力を実現することができる効果を奏する。
【００４０】
さらに、この実施の形態１によれば、アプリ管理モジュール３２，３４がユーザから与えられる入力情報にしたがって複数のＪａｖａアプリ２８，２９の動作を管理するように構成したので、複数のＪａｖａアプリ２８，２９が動作しているときでも、ユーザが所望のＪａｖａアプリに対して入力することができる効果を奏する。
【００４１】
なお、この実施の形態１では、全画面を基本機能モジュール２４あるいは拡張機能モジュール２７が表示する場合の他に、基本機能モジュール２４と拡張機能モジュール２７間で画面分割するものも示しているが（図１３を参照）、この場合、拡張機能モジュール２７のアプリ管理モジュール３４から画面分割要求を発行し、前述の処理と同様に許可／却下によって処理を変更すればよい（ナビゲーションサービス２５は分割表示可能とする）。
また、分割表示した時のお互いの表示領域として、左上と右下の座標を図１７のように管理しておけば、前述の入力管理処理において、タッチパネルのタッチ位置がどちらのモジュールに対する入力なのかを区別することが可能となる。
【００４２】
また、拡張機能モジュール２７のＪａｖａＶＭ３０側も分割画面表示してもよいことを上述したが（図１４を参照）、その処理は、上述の基本機能モジュール２４の処理と同様であるので説明を省略する。なお、Ｊａｖａアプリ側もタッチパネルのタッチ位置からどのＪａｖａアプリに対する入力なのかを判別するために、図１８に示すような画面出力Ｊａｖａアプリ情報を管理する。
【００４３】
実施の形態２．
上記の実施の形態１では、（３）の入力管理及び（４）の画面出力管理を基本側・拡張側の双方に持つとしているのが、基本機能モジュール２４側に全ての機能を置いても構わない。この場合、拡張機能モジュール２７上で動作するＪａｖａアプリ２８，２９がナビゲーションサービス２５と同様に、基本機能モジュール２４のアプリ管理モジュール３２で管理されることを意味する（図１９及び図２０を参照）。ただし、図２０において、ステップＳＴ７１は基本機能モジュール２４のアプリ管理モジュール３２における画面出力要求の受信処理を意味し、ステップＳＴ７２はアプリ管理モジュール３２における画面出力要求元の判断処理を意味している。また、ステップＳＴ７３はナビゲーションサービス２５に対する許可通知処理を意味し、ステップＳＴ７４はナビゲーションサービス２５に対する却下通知処理を意味する。
逆に、（３）の入力管理及び（４）の画面出力管理について、全てを拡張機能モジュール２７側で行ってもよい。この場合、ナビゲーションサービス２５がＪａｖａアプリ２８，２９と同様に（Ｊａｖａアプリと同列に）、拡張機能モジュール２７のアプリ管理モジュール３４で管理されることを意味する。
【００４４】
さらに、（１）の登録処理等や（２）の起動処理等に関しても、全て基本機能モジュール２４のアプリ管理モジュール３２で管理しても構わない（追加・削除、起動・停止・状態管理に必要なＩ／Ｆを各インタフェースモジュールに配置すればよい）。この場合、全てのアプリ管理を基本機能モジュール２４のアプリ管理モジュール３２が行うことになり、ソフトウェア構成は例えば図３のようになる。
これにより、基本機能モジュール２４を拡張機能モジュール２７より優先的に動作させるようにすれば、優先的に動作する基本機能モジュール２４がＪａｖａアプリ２８，２９を管理するので、Ｊａｖａアプリ２８，２９の起動／停止を早めることができる効果を奏する。
【００４５】
逆に、全ての処理等を拡張機能モジュール２７のアプリ管理モジュール３４で管理しても構わない。この場合、全てのアプリ管理を拡張機能モジュール２７のアプリ管理モジュール３４が行うことになり、ソフトウェア構成は例えば図４のようになる。
これにより、アプリ管理を拡張機能モジュール２７のアプリ管理モジュール３４がＪａｖａアプリ２８，２９を管理するので、基本機能モジュール２４と拡張機能モジュール２７間の通信を省略することができる効果を奏する。
【００４６】
実施の形態３．
上記実施の形態１では、拡張機能モジュール２７がＪａｖａアプリ２８，２９を起動させるＪａｖａＶＭ３０から構成されているものについて示したが、これに限るものではなく、例えば、図２１に示すように、ＯＳ２３上にＬｉｎｕｘＯＳ４１を搭載し、ＬｉｎｕｘＯＳ４１をプロセスとして動作させることにより、ＪａｖａＶＭ３０と同様の機能を果たすことができる。この場合、Ｌｉｎｕｘアプリ４２，４３がサービスアプリケーションに相当し、アプリ管理モジュール４４がＬｉｎｕｘアプリ４２，４３の動作を管理する。また、ＬｉｎｕｘＩ／Ｆモジュール４５はアプリ管理モジュールインタフェースモジュール３１と通信を行う。
【００４７】
実施の形態４．
上記実施の形態１では、ユーザ操作部７がタッチパネルやジョイスティックなどのデバイスであるものについて示したが、ユーザ操作部７がマイクを備え、ユーザ操作Ｉ／Ｆ部８がマイクより入力されたユーザの音声を所定の音声入力コマンドに変換する音声認識エンジンを備えるようにしてもよい。
なお、ハードウェア構成は、マイク以外は上記実施の形態１と同様とする。
【００４８】
図２２はこの発明の実施の形態４による情報提供システムを示すソフトウェア構成図であり、図において、図２と同一符号は同一または相当部分を示すので説明を省略する。
音声認識エンジンモジュール５１は基本機能モジュールとして動作し、ユーザの音声を認識する。ＪａｖａＶＭＩ／Ｆモジュール５２は音声認識エンジンモジュール５１がＪａｖａアプリ２８，２９と連携を図る際、ＪａｖａＶＭ３０内の音声認識エンジンモジュールインタフェースモジュール５３と通信を実施する。
【００４９】
次に動作について説明する。
この実施の形態２における音声認識エンジンモジュール５１は、初期設定において登録された音声認識コマンドに対して、コマンドを追加・削除できるものとする。なお、音声認識エンジンモジュール５１自体の動作については、現状のカーナビゲーションシステムにおける音声認識エンジンと同様の処理で構わないので説明を省略する。なお、コマンド追加・削除に関しても現状のシステムで、ナビゲーションサービス２５が登録地点をデータベースに登録・削除する際に、登録地点コマンドを追加・削除する場合と同様であるため説明を省略する。
ここでは、下記の２つの音声認識エンジンの制御について説明する。
（１）Ｊａｖａアプリ追加時のＪａｖａアプリ起動コマンドの追加
（２）Ｊａｖａアプリ起動時のＪａｖａアプリ内で使用する音声認識コマンドの追加
【００５０】
（１）Ｊａｖａアプリ起動コマンドの追加について
図２３はＪａｖａアプリ起動コマンドの追加処理を示すフローチャートであり、図２４はコマンド認識処理を示すフローチャートである。
まず、拡張機能モジュール２７のアプリ管理モジュール３４は、上記実施の形態１におけるＪａｖａアプリの追加処理において、Ｊａｖａアプリを読み出す際（図５のステップＳＴ２）、読み出し対象のＪａｖａアプリの付加情報として、アプリ起動コマンド情報（例えば、読み出し対象のＪａｖａアプリが天気予報を行うアプリであれば「テンキヨホウ」のように読み仮名が書かれた情報）も同時に読み出し（ステップＳＴ８１）、ＲＡＭ１０への展開処理時に読み出したアプリ起動コマンド情報とアプリ起動コマンドＩＤ（アプリ管理テーブルの何行目のアプリかを示す情報）を、音声認識エンジンモジュールインタフェースモジュール５３とＪａｖａＶＭＩ／Ｆモジュール５２を介して、基本機能モジュール２４の音声認識エンジンモジュール５１に送信する（ステップＳＴ８２）。
【００５１】
音声認識エンジンモジュール５１は、アプリ管理モジュール３４からアプリ起動コマンド情報とアプリ起動コマンドＩＤを受信すると（ステップＳＴ８３）、そのアプリ起動コマンドとアプリ起動コマンドＩＤとＪａｖａアプリの起動コマンドであることを示す識別フラグ（例えば、ＪＡＶＡ＿ＣＭＤのような文字列）を音声認識データベースに登録する。
音声認識エンジンモジュール５１は、ユーザがマイクに対して発話した音声コマンドが登録されたコマンドである場合には（ステップＳＴ９１，ＳＴ９２）、インタフェースモジュールを介して、アプリ起動コマンドＩＤと識別フラグを拡張機能モジュール２７のアプリ管理モジュール３４に送信する（ステップＳＴ９３）。なお、音声コマンドが拡張機能モジュールのアプリ管理モジュール３４より登録されたコマンドでない場合、その認識結果をナビゲーションサービス２５に送信する（ステップＳＴ９４）。
拡張機能モジュール２７のアプリ管理モジュール３４は、その識別フラグがアプリ起動コマンドであることを判断した上で、受信したアプリ起動コマンドＩＤに対応するＪａｖａアプリを上記実施の形態１と同様の方法で起動する。
【００５２】
なお、Ｊａｖａアプリが削除される場合は、拡張機能モジュール２７のアプリ管理モジュール３４が音声認識エンジンモジュール５１に対して、アプリ起動コマンドとアプリ起動ＩＤの削除依頼を、インタフェースモジュールを介して音声認識エンジンモジュール５１に送信し、音声認識エンジンモジュール５１が音声認識データベースより起動コマンドを削除することによって実現する。
【００５３】
（２）音声認識コマンドの追加について
拡張機能モジュール２７のアプリ管理モジュール３４は、上記実施の形態１におけるＪａｖａアプリの画面管理において、Ｊａｖａアプリに画面出力許可を送信する際に、Ｊａｖａアプリが保有しているアプリ音声コマンド情報（例えば、Ｊａｖａアプリが天気予報を行うアプリであれば、「オオサカ」とか「ヒョウゴケンナンブ」といった地方名と、「キョウ」とか「アシタ」といった日時を示す文字列）とアプリ音声コマンドＩＤ（音声コマンド文字列を指し示すためのＩＤ）の読出処理を実施する。
【００５４】
拡張機能モジュール２７のアプリ管理モジュール３４は、その読み出したアプリ音声コマンド情報と、その読み出したアプリ音声コマンドの一つ一つを識別するためのアプリ音声コマンドＩＤと、登録するコマンドがアプリ音声コマンドであることを示す識別フラグ（例えば、ＪＡＶＡ＿ＡＰＬ＿ＣＭＤといった文字列）を、インタフェースモジュールを介して、音声認識エンジンモジュール５１に送信する。
音声認識エンジンモジュール５１は、アプリ音声コマンド情報とアプリ音声コマンドＩＤと識別フラグとを受信すると、これらの情報を音声認識データベースに登録する。
【００５５】
音声認識エンジンモジュール５１は、ユーザがマイクに対して発話した音声コマンドが拡張機能モジュール２７のアプリ管理モジュール３４より登録されたコマンドである場合には、インタフェースモジュールを介して、識別フラグと音声コマンドＩＤを拡張機能モジュール２７のアプリ管理モジュール３４に送信する。
拡張機能モジュール２７のアプリ管理モジュール３４は、音声認識エンジンモジュール５１から送信された識別フラグがアプリ音声コマンドであることを判別した後に、その受信した音声コマンドＩＤを画面出力しているＪａｖａアプリに送信する。その後、Ｊａｖａアプリは、受信した音声コマンドＩＤに応じた処理を行う。
なお、Ｊａｖａアプリが画面出力を停止、あるいは、他のＪａｖａアプリに変更になった場合には、登録した全てのアプリ音声コマンドを消去するように音声認識エンジンモジュール５１に通知し、その音声認識エンジンモジュール５１が音声コマンドを音声認識データベースより消去する。
【００５６】
上記の説明では、画面出力するＪａｖａアプリが１つであるものについて示したが、２つ以上のＪａｖａアプリが同時に画面表示する場合には、読み出したアプリ音声コマンドＩＤに、アプリ管理テーブルの何行目にあるかを示すアプリＩＤ（上述のアプリ起動コマンドＩＤと同じ）を加えたＩＤをコマンドＩＤとすれば（例えば、音声コマンドＩＤが０ｘ０００１（２バイトデータ）であり、アプリＩＤが０ｘ０００２（２バイトデータ）である場合には、０ｘ０００２０００１のように４バイトデータとすればよい）、同時表示しているＪａｖａアプリにおいて、どのＪａｖａアプリに対する音声認識コマンドなのかを区別することが可能となる。
なお、上述の起動コマンド追加処理及び音声認識コマンド追加処理を、基本機能モジュール２４のアプリ管理モジュール３２で行っても構わない。
【００５７】
以上で明らかなように、この実施の形態４によれば、アプリ管理モジュール３４がユーザの音声を認識する音声認識エンジンモジュール５１を利用して、Ｊａｖａアプリが使用する音声入力コマンドの登録を受け付けるように構成したので、ユーザが音声を発するだけでＪａｖａアプリを操作することができる効果を奏する。
【００５８】
実施の形態５．
複数のＪａｖａアプリ２８，２９が同時に動作することにより、限られたメモリリソースで動作している情報提供システムでは、メモリ不足になる可能性がある。そのため、アプリ管理モジュール３４では、Ｊａｖａアプリ２８，２９が使用するメモリリソースを管理し、メモリ不足になる可能性が発生すると、任意のＪａｖａアプリを停止させる等の制御を実施する。
具体的には下記の通りである。図２５はメモリ不足時のアプリ停止処理を示すフローチャートである。
【００５９】
ただし、ハードウェア構成及びソフトウェア構成は上記実施の形態１と同様であるとする。また、ＪａｖａＶＭ３０は、起動時に所定量のメモリリソースを確保するものとし、Ｊａｖａアプリから出力されるクラス生成などの要求に応じて、ＪａｖａＶＭ３０が使用している総メモリリソースをメモリ使用量情報として有するものとする。
また、拡張機能モジュール２７のアプリ管理モジュール３４からＪａｖａＶＭ３０が確保しているメモリリソースの空き容量を獲得するためのＡＰＩとして、ｇｅｔＦｒｅｅＭｅｍｏｒｙという関数を用意し、ＪａｖａＶＭ３０がこの関数を呼び出したＪａｖａアプリに対して、起動時に確保したメモリリソースから使用している総メモリリソースを引いた値を返す処理を行うものとする。
【００６０】
まず、拡張機能モジュール２７のアプリ管理モジュール３４は、所定の時間毎（例えば、１分おき）に、上記関数を呼び出して、メモリリソースの空き容量情報を獲得する（ステップＳＴ１０１，ＳＴ１０２）。
拡張機能モジュール２７のアプリ管理モジュール３４は、メモリリソースの空き容量情報を獲得すると、メモリリソースの空き容量が所定のメモリ容量以下であるか否かを判断し（ステップＳＴ１０３）、メモリリソースの空き容量が所定のメモリ容量以下である場合には、任意のＪａｖａアプリを上記実施の形態１と同様の方法で停止させることにより、メモリ不足を回避するようにする（ステップＳＴ１０４）。
【００６１】
以上で明らかなように、この実施の形態５によれば、アプリ管理モジュール３４が使用可能なリソースを考慮して、複数のＪａｖａアプリ２８，２９の動作を管理するように構成したので、情報提供システムの動作を安定化することができる効果を奏する。
【００６２】
上記の説明では、ＪａｖａＶＭ３０が確保しているメモリリソースを対象としているが、情報提供システム全体のメモリリソース（ＤＲＡＭ全容量）を対象としても構わない。この場合、ＪａｖａＶＭ３０は、ＯＳ２３上にＪａｖａＶＭ３０と同様のメモリリソース空き容量を獲得するためのＡＰＩを用意しておき、ＪａｖａアプリからＪａｖａＶＭ３０のＡＰＩを呼び出した時に、ＪａｖａＶＭ３０が上記ＡＰＩを介して情報提供システムの空きメモリ容量を獲得することにより実現する。
【００６３】
また、上記の説明では、任意のＪａｖａアプリを停止するとしているが、Ｊａｖａアプリを起動した順番を情報として記憶しておき、最後に起動したＪａｖａアプリ、あるいは、最初に起動したＪａｖａアプリを停止しても構わない。また、上記実施の形態１と同様に、Ｊａｖａアプリに優先度を持たせておき、優先度の低いＪａｖａアプリから停止するようにしてもよい。
また、上記の説明では、ある所定のメモリ容量以下であったらＪａｖａアプリを停止するとしているが、メモリ容量に余裕が発生した場合、強制停止させたＪａｖａアプリを再起動するようにしてもよい。
【００６４】
さらに、上記の説明では、対象となる情報提供システムのリソースがメモリリソースのみであったが、ハードディスクドライブのような記録メディアに対する書き込みであっても構わない。その場合、ハードディスク容量が不足した場合には、Ｊａｖａアプリに対して、Ｊａｖａアプリが使用しているファイルを削除するように依頼すればよい。
なお、この実施の形態５では、拡張機能モジュール２７のアプリ管理モジュール３４がＪａｖａアプリの停止処理を行うものについて示したが、基本機能モジュール２４のアプリ管理モジュール３２がインタフェースモジュールを介してメモリリソースの空き容量を獲得することによって、Ｊａｖａアプリの停止処理を行うようにしてもよい。
【００６５】
実施の形態６．
上記実施の形態１では、アプリ管理モジュール３２，３４が各Ｊａｖａアプリを削除・追加することにより、Ｊａｖａアプリの更新を行うようにしているが、アプリ管理モジュール自体を更新するようにしてもよい。
具体的には下記の通りである。図２６はＪａｖａＶＭの自動更新処理を示すフローチャートであり、図２７はアプリ管理モジュール３４の自動更新処理を示すフローチャートである。
【００６６】
ただし、ハードウェア構成及びソフトウェア構成は、上記実施の形態１と同様であるものとし、ＪａｖａＶＭ３０には、Ｊａｖａアプリのポインタ（ＤＲＡＭアドレス）と読み込み先（ＤＶＤ−ＲＯＭ等）を引数として、自動更新用のＡＰＩを用意する。このＡＰＩが呼ばれた場合には、指定されたポインタのＪａｖａアプリを停止させるとともに、ＤＲＡＭ上から削除し（ステップＳＴ１１１，ＳＴ１１２）、また、指定された読み込み先からＪａｖａアプリを読み出し、ＤＲＡＭ上に展開したのち（ステップＳＴ１１３）、展開したＪａｖａアプリを起動する（ステップＳＴ１１４）。
【００６７】
拡張機能モジュール２７のアプリ管理モジュール３４は、管理モジュール更新要求を受信すると（ステップＳＴ１２１）、管理している全てのＪａｖａアプリを停止させて（ステップＳＴ１２２）、アプリ管理テーブルを所定の場所に記録する（ステップＳＴ１２３）。
その後、ｔｈｉｓ変数を用いて自分自身のポインタをＪａｖａＶＭ３０より獲得し（ステップＳＴ１２４）、その獲得した自分自身のポインタと所定の読み込み先を、上記ＡＰＩの引数としてＪａｖａＶＭ３０に送信する（ステップＳＴ１２５）。
ＪａｖａＶＭ３０は、上記の処理手順によって、アプリ管理モジュール３４を更新して自動起動する。起動後、アプリ管理モジュール３４は、所定の場所に記録されたアプリ管理テーブルを読み出してアプリ管理処理を開始する。
【００６８】
以上で明らかなように、この実施の形態６によれば、拡張機能モジュール２７のＪａｖａＶＭ３０がアプリ管理モジュール３４を更新するように構成したので、Ｊａｖａアプリの管理方法を用意に拡張することができる効果を奏する。
なお、上記の説明では、更新されるアプリ管理モジュール３４の読み込み先を所定の読み出し先としているが、ユーザに入力させても構わない。また、上記実施の形態１と同様に、読み出し先は外部記録メディア２に限らず、接続された携帯電話等のネットワーク接続機器を介して、ネットワーク上に置かれたアプリ管理モジュールをダウンロードしてもよい。
【００６９】
【発明の効果】
以上のように、この発明によれば、拡張機能モジュール上で同時に動作するアプリ管理モジュールが複数のサービスアプリケーションの動作を管理するように構成したので、情報提供システムのリソースの競合を招くことなく、複数のサービスアプリケーションを同時に動作させることができる効果がある。
【図面の簡単な説明】
【図１】この発明の実施の形態１による情報提供システムを示すハードウェア構成図である。
【図２】この発明の実施の形態１による情報提供システムを示すソフトウェア構成図である。
【図３】この発明の実施の形態２による情報提供システムを示すソフトウェア構成図である。
【図４】この発明の実施の形態２による情報提供システムを示すソフトウェア構成図である。
【図５】Ｊａｖａアプリの追加処理を示すフローチャートである。
【図６】アプリ管理テーブルの一例を示す説明図である。
【図７】追加アプリリストの一例を示す説明図である。
【図８】Ｊａｖａアプリの削除処理を示すフローチャートである。
【図９】メニュー画面の一例を示す説明図である。
【図１０】Ｊａｖａアプリの起動処理を示すフローチャートである。
【図１１】アプリ管理モジュールの入力管理処理を示すフローチャートである。
【図１２】アプリ管理モジュールの入力管理処理を示すフローチャートである。
【図１３】モジュール分割画面の一例を示す説明図である。
【図１４】Ｊａｖａアプリ分割画面の一例を示す説明図である。
【図１５】アプリ管理モジュールの出力管理処理を示すフローチャートである。
【図１６】アプリ管理モジュールの出力管理処理を示すフローチャートである。
【図１７】分割表示時の画面出力表示領域の管理情報を示す説明図である。
【図１８】分割表示時のＪａｖａアプリ画面出力表示領域の管理情報を示す説明図である。
【図１９】アプリ管理モジュールの入力管理処理を示すフローチャートである。
【図２０】アプリ管理モジュールの出力管理処理を示すフローチャートである。
【図２１】この発明の実施の形態３による情報提供システムを示すソフトウェア構成図である。
【図２２】この発明の実施の形態４による情報提供システムを示すソフトウェア構成図である。
【図２３】Ｊａｖａアプリ起動コマンドの追加処理を示すフローチャートである。
【図２４】コマンド認識処理を示すフローチャートである。
【図２５】メモリ不足時のアプリ停止処理を示すフローチャートである。
【図２６】ＪａｖａＶＭの自動更新処理を示すフローチャートである。
【図２７】アプリ管理モジュールの自動更新処理を示すフローチャートである。
【符号の説明】
１ＲＯＭ、２外部記憶メディア、３外部記憶装置ドライブ、４外部記憶装置Ｉ／Ｆ、５周辺機器、６周辺機器Ｉ／Ｆ、７ユーザ操作部、８操作部Ｉ／Ｆ、９ＣＰＵ、１０ＲＡＭ、１１グラフィック制御回路、１２ディスプレイ、２１Ｈ／Ｗ、２２デバイスドライバ、２３ＯＳ、２４基本機能モジュール、２５ナビゲーションサービス、２６ＪａｖａＶＭＩ／Ｆモジュール、２７拡張機能モジュール、２８，２９Ｊａｖａアプリ（サービスアプリケーション）、３０ＪａｖａＶＭ、３１アプリ管理モジュールインタフェースモジュール、３１ａナビゲーションサービスインタフェースモジュール、３２アプリ管理モジュール、３３ＪａｖａＶＭＩ／Ｆモジュール、３４アプリ管理モジュール、４１ＬｉｎｕｘＯＳ、４２，４３Ｌｉｎｕｘアプリ、４４アプリ管理モジュール、４５ＬｉｎｕｘＩ／Ｆモジュール、５１音声認識エンジンモジュール、５２ＪａｖａＶＭＩ／Ｆモジュール、５３音声認識エンジンモジュールインタフェースモジュール。

Claims

基本的な情報サービスを提供する基本機能モジュールと、上記基本機能モジュールにはない拡張機能を提供するサービスアプリケーションが組み込まれると、上記基本機能モジュールと連携を図りながら上記サービスアプリケーションを起動させる拡張機能モジュールとを備えた情報提供システムにおいて、上記拡張機能モジュール上で同時に動作する複数のサービスアプリケーションの動作を管理するアプリ管理モジュールを搭載したことを特徴とする情報提供システム。
基本機能モジュールのサブモジュールとしてアプリ管理モジュールを搭載したことを特徴とする請求項１記載の情報提供システム。
拡張機能モジュールに組み込まれるサービスアプリケーションの１つとしてアプリ管理モジュールを搭載したことを特徴とする請求項１記載の情報提供システム。
拡張機能モジュールがアプリ管理モジュールを更新することを特徴とする請求項３記載の情報提供システム。
基本機能モジュールのサブモジュールとしてアプリ管理モジュールを搭載するとともに、拡張機能モジュールに組み込まれるサービスアプリケーションの１つとしてアプリ管理モジュールを搭載し、双方のアプリ管理モジュールが連携して複数のサービスアプリケーションの動作を管理することを特徴とする請求項１記載の情報提供システム。
アプリ管理モジュールは、拡張機能モジュールに対するサービスアプリケーションの追加処理、削除処理及び更新処理を実施することを特徴とする請求項１から請求項５のうちのいずれか１項記載の情報提供システム。
アプリ管理モジュールは、基本機能モジュール又はサービスアプリケーションから画面出力要求を受けると、その画面出力要求に応じて基本機能モジュール又はサービスアプリケーションに画面出力許可を与えることを特徴とする請求項１から請求項６のうちのいずれか１項記載の情報提供システム。
アプリ管理モジュールは、ユーザから与えられる入力情報にしたがって複数のサービスアプリケーションの動作を管理することを特徴とする請求項１から請求項７のうちのいずれか１項記載の情報提供システム。
アプリ管理モジュールは、ユーザの音声を認識する音声認識エンジンを利用して、サービスアプリケーションが使用する音声入力コマンドの登録を受け付けることを特徴とする請求項１から請求項８のうちのいずれか１項記載の情報提供システム。
アプリ管理モジュールは、使用可能なリソースを考慮して、複数のサービスアプリケーションの動作を管理することを特徴とする請求項１から請求項９のうちのいずれか１項記載の情報提供システム。
アプリ管理モジュールは、複数のサービスアプリケーションの優先度を考慮して、複数のサービスアプリケーションの動作を管理することを特徴とする請求項１から請求項９のうちのいずれか１項記載の情報提供システム。
アプリ管理モジュールは、使用可能なリソースと複数のサービスアプリケーションの優先度を考慮して、複数のサービスアプリケーションの動作を管理することを特徴とする請求項１から請求項９のうちのいずれか１項記載の情報提供システム。