(57)【要約】デバイスをインストールしたり、取り外した後でも、アプリケーション間の競合条件を規定したアプリ競合ルールを自動的に更新する競合解決装置を提供する。アプリ競合ルール保存部（１５）は、アプリ競合ルールを保存する。アプリケーション実行部は、アプリ競合ルールに基づいて、複数のアプリケショーン間の競合を判定し、当該判定結果に基づいて、１つ以上のアプリケーションを実行する。アプリ競合ルール更新部は、競合解決装置のリソースが変化した場合に、複数のアプリケーション間の競合条件の変化に合わせて、アプリ競合ルールを更新する。【特許請求の範囲】
【請求項１】
複数のアプリケーション間の競合を解決する競合解決装置であって、
前記複数のアプリケーション間の競合条件が規定されたアプリ競合ルールを保存するアプリ競合ルール保存部と、
前記アプリ競合ルールに基づいて、前記複数のアプリケショーン間の競合を判定し、当該判定結果に基づいて、１つ以上のアプリケーションを実行するアプリケーション実行部と、
前記競合解決装置のリソースが変化した場合に、前記複数のアプリケーション間の競合条件の変化に合わせて、前記アプリ競合ルールを更新するアプリ競合ルール更新部とを備えることを特徴とする、競合解決装置。
【請求項２】
前記アプリケーション実行部は、
１つ以上のアプリケーションを実行する実行部と、
前記アプリ競合ルールに基づいて、前記複数のアプリケショーン間の競合を判定する競合判定部と、
前記競合判定部の判定結果に従って、前記実行部でのアプリケーションの実行を管理するアプリ管理部とを含むことを特徴とする、請求項１に記載の競合解決装置。
【請求項３】
前記アプリ競合ルール更新部は、
前記競合解決装置が備えるデバイスの状態変化を検知するシステム管理部と、
前記デバイスの状態が変化した場合に、前記デバイスの状態が変化した後の競合解決装置のリソースを取得し、当該取得したリソースに基づいて、前記競合条件が変更されるのか否かを判断するデバイス−競合ルール管理部と、
前記競合条件が変更されると判断した場合に、前記複数のアプリケーション間の競合条件の変化に合わせて、前記アプリ競合ルールを更新する競合情報更新部とを備える、請求項１に記載の競合解決装置。
【請求項４】
前記デバイス−競合ルール管理部は、
前記デバイスの状態が変化した場合に、前記複数のアプリケーションの動作に必要なリソースを取得し、
当該取得した複数のアプリケーションの動作に必要なリソースと、前記デバイスの状態が変化した後の競合解決装置のリソースとに基づいて、前記競合条件が変更されるのか否かを判断することを特徴とする、請求項３に記載の競合解決装置。
【請求項５】
前記アプリ競合ルール更新部は、前記デバイスのリソース種別と、前記アプリケーションとの間の共有・排他条件を示すリソース共有・排他条件を保存するリソース共有・排他条件部をさらに備え、
前記デバイス−競合ルール管理部は、さらに、前記リソース共有・排他条件に基づいて、前記競合条件が変更さるのか否かを判断する、請求項３に記載の競合解決装置。
【請求項６】
前記システム管理部は、前記競合解決装置が備えるデバイスが追加、交換、あるいは削除されることによる前記デバイスの状態変化を検知することを特徴とする、請求項３に記載の競合解決装置。
【請求項７】
前記デバイスのリソース種別は、メモリであり、
前記デバイス−競合ルール管理部は、前記デバイスの状態が変化した後の前記競合解決装置のメモリ容量と、前記複数のアプリケーションの動作に必要なメモリ容量とに基づいて、前記競合条件が変更されるのか否かを判断する、請求項３に記載の競合解決装置。
【請求項８】
前記デバイスのリソース種別は、音源ボードであり、
前記デバイス−競合ルール管理部は、前記デバイスの状態が変化した後の前記競合解決装置の音再生能力と、前記複数のアプリケーションの動作に必要な音再生能力とに基づいて、前記競合条件が変更されるのか否かを判断する、請求項３に記載の競合解決装置。
【請求項９】
複数のアプリケーション間の競合を解決する情報機器が実行する競合解決方法であって、
前記情報機器には、前記複数のアプリケーション間の競合条件を規定したアプリ競合ルールが保存されており、
前記情報機器が備えるデバイスの状態変化を検知し、
前記デバイスの状態が変化した場合に、前記デバイスの状態が変化した後の前記情報機器のリソースを取得し、
取得した前記情報機器のリソースに基づいて、前記複数のアプリケーション間の競合条件が変更されるのか否かを判断し、
前記競合条件が変更されると判断した場合に、前記アプリ競合ルールを更新することを特徴とする、競合解決方法。
【請求項１０】
複数のアプリケーション間の競合を解決する情報機器が実行するプログラムであって、
前記情報機器には、前記複数のアプリケーション間の競合条件を規定したアプリ競合ルールが保存されており、
前記情報機器が備えるデバイスの状態変化を検知し、
前記デバイスの状態が変化した場合に、前記デバイスの状態が変化した後の前記情報機器のリソースを取得し、
取得した前記情報機器のリソースに基づいて、前記複数のアプリケーション間の競合条件が変更されるのか否かを判断し、
前記競合条件が変更されると判断した場合に、前記アプリ競合ルールを更新することを特徴とする、プログラム。
【請求項１１】
複数のアプリケーション間の競合を解決する情報機器が備える集積回路であって、
前記情報機器には、前記複数のアプリケーション間の競合条件を規定したアプリ競合ルールが保存されており、
前記集積回路は、
前記情報機器が備えるデバイスの状態変化を検知し、
前記デバイスの状態が変化した場合に、前記デバイスの状態が変化した後の前記情報機器のリソースを取得し、
取得した前記情報機器のリソースに基づいて、前記複数のアプリケーション間の競合条件が変更されるのか否かを判断し、
前記競合条件が変更されると判断した場合に、前記アプリ競合ルールを更新することを特徴とする、集積回路。
【発明の詳細な説明】
【技術分野】
【０００１】  本発明は、複数のアプリケーション間の競合を解決する競合解決装置に関し、より特定的には、競合解決装置が備えるリソースが変化した場合にも、アプリケーション間の競合条件を規定したアプリ競合ルールを自動的に更新する競合解決装置に関する。
【背景技術】
【０００２】  従来より、携帯電話などの情報機器においては、特定のアプリケーション（例えば、電話の機能など）を、他のアプリケーション（例えば、メロディプレーヤなど）よりも優先させて動作させることが行なわれていた。例えば、携帯電話においては、メロディプレーヤがメロディを再生中であったとしても、電話の着信が発生した際には、再生中の音を停止した上で、着信画面を表示し、着信音を鳴動させることが行われていた。これは携帯電話においては、電話の着信があった場合に、常に着信の処理を優先させ、通話を可能としなければならないためである。また、着信時にメロディの音が鳴動していてはユーザへの通知や通話の妨げとなるために、このようなアプリケーション間の競合を解決するユーザインタフェースが実現されていた。【０００３】  また、携帯電話、ＡＶ機器、及びカーナビゲーション機器などのアプリケーションが出荷時から組み込まれた情報機器においては、アプリケーション間の競合を解決し、より安定したシステムをユーザに提供するために、予め使用できるメモリ量と、アプリケーションが必要とするメモリ量とを計算し、起動できるアプリケーションの最大数を決定することで、システムの安定性を実現する場合もあった。【０００４】  また、このようなアプリケーションが出荷時から組み込まれた情報機器においては、出荷前にアプリケーションの動作に関して十分にテストを行い、アプリケーション同士で競合が発生する可能性があるアプリケーションを予め組み込まないようにしていた。【０００５】  また、特許文献１には、アプリケーション間の競合を解決するために、アプリケーション間の競合条件が規定された競合制御テーブルを参照し、新規オペレーションの実行の可否を判定すると共に、各アプリケーションに対して動作の指示を行なう情報機器が開示されている。
【特許文献１】特開２００３−１７７９２６号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】  しかしながら、特許文献１に開示されている情報機器では、組み込まれるアプリケーションや情報機器が備えるデバイスの種類に基づいて、出荷前に想定可能な範囲でアプリケーション間の競合条件が用意されていた。そのため、出荷後となっては、新たなデバイスを追加するなどしたために、アプリケーション間の競合条件を変更した方がユーザの利便性の観点で優れていたとしても、競合条件を変更することができなかった。【０００７】  それ故に、本発明の目的は、上述した課題を解決するものであり、出荷後にデバイスの追加などでシステムが備えるリソースが変化した場合にも、アプリケーション間の競合条件を規定したアプリ競合ルールを自動的に更新することができる競合解決装置を提供することである。
【課題を解決するための手段】
【０００８】  本発明は、複数のアプリケーション間の競合を解決する競合解決装置に向けられている。そして、上記目的を達成させるために、本発明の競合解決装置は、複数のアプリケーション間の競合条件が規定されたアプリ競合ルールを保存するアプリ競合ルール保存部と、アプリ競合ルールに基づいて、複数のアプリケショーン間の競合を判定し、当該判定結果に基づいて、１つ以上のアプリケーションを実行するアプリケーション実行部と、競合解決装置のリソースが変化した場合に、複数のアプリケーション間の競合条件の変化に合わせて、アプリ競合ルールを更新するアプリ競合ルール更新部とを備える。【０００９】  好ましくは、アプリケーション実行部は、１つ以上のアプリケーションを実行する実行部と、アプリ競合ルールに基づいて、複数のアプリケショーン間の競合を判定する競合判定部と、競合判定部の判定結果に従って、実行部でのアプリケーションの実行を管理するアプリ管理部とを含む。【００１０】  好ましくは、アプリ競合ルール更新部は、競合解決装置が備えるデバイスの状態変化を検知するシステム管理部と、デバイスの状態が変化した場合に、デバイスの状態が変化した後の競合解決装置のリソースを取得し、当該取得したリソースに基づいて、競合条件が変更されるのか否かを判断するデバイス−競合ルール管理部と、競合条件が変更されると判断した場合に、複数のアプリケーション間の競合条件の変化に合わせて、アプリ競合ルールを更新する競合情報更新部とを備える。【００１１】  また、デバイス−競合ルール管理部は、デバイスの状態が変化した場合に、複数のアプリケーションの動作に必要なリソースを取得し、取得した複数のアプリケーションの動作に必要なリソースと、デバイスの状態が変化した後の競合解決装置のリソースとに基づいて、競合条件が変更されるのか否かを判断してもよい。【００１２】  好ましくは、アプリ競合ルール更新部は、デバイスのリソース種別と、アプリケーションとの間の共有・排他条件を示すリソース共有・排他条件を保存するリソース共有・排他条件部をさらに備える。この場合、デバイス−競合ルール管理部は、さらに、リソース共有・排他条件に基づいて、競合条件が変更さるのか否かを判断する。【００１３】  好ましくは、システム管理部は、競合解決装置が備えるデバイスが追加、交換、あるいは削除されることによるデバイスの状態変化を検知する。【００１４】  例えば、デバイスのリソース種別は、メモリである。この場合、デバイス−競合ルール管理部は、デバイスの状態が変化した後の競合解決装置のメモリ容量と、複数のアプリケーションの動作に必要なメモリ容量とに基づいて、競合条件が変更されるのか否かを判断する。【００１５】  例えば、デバイスのリソース種別は、音源ボードである。この場合、デバイス−競合ルール管理部は、デバイスの状態が変化した後の競合解決装置の音再生能力と、複数のアプリケーションの動作に必要な音再生能力とに基づいて、競合条件が変更されるのか否かを判断する。【００１６】  また、本発明は、複数のアプリケーション間の競合を解決する情報機器が実行する競合解決方法にも向けられている。ただし、情報機器には、複数のアプリケーション間の競合条件を規定したアプリ競合ルールが保存されている。そして、上記目的を達成させるために、本発明の競合解決方法は、情報機器が備えるデバイスの状態変化を検知し、デバイスの状態が変化した場合に、デバイスの状態が変化した後の情報機器のリソースを取得し、取得した情報機器のリソースに基づいて、複数のアプリケーション間の競合条件が変更されるのか否かを判断し、競合条件が変更されると判断した場合に、アプリ競合ルールを更新する。【００１７】  好ましくは、この競合解決方法は、一連の処理手順を情報機器に実行させるためにプログラムの形式で提供される。このプログラムは、コンピュータが読みとり可能な記憶媒体に記憶されてもよい。また、この競合解決方法は、情報機器が備える集積回路として提要されてもよい。
【発明の効果】
【００１８】  以上のように本発明によれば、デバイスが追加、交換、あるいは削除されることによって、システムが備えるリソースが変化したときに、アプリケーション間の競合条件を規定したアプリ競合ルールを自動的に更新することができる。これによって、システムを出荷した後にデバイスがインストールされた場合でも、デバイスの性能を充分に活用しつつ、不具合なく安定したアプリケーションの動作を確保することができる。【００１９】  また、システム設計者は、予め追加、交換、あるいは削除されるデバイスを予測した上で、アプリケーション間の競合条件を設計する必要がなくなる。このため、システム出荷時の負荷を軽減することができる。また、想定外のデバイスを追加する必要性が生じた場合にも、システム全体を更新するのではなく、アプリ競合ルールのみを更新することで対応できる。このため、デバイス追加時の負荷も軽減することができる。【００２０】  また、システムの状況に基づいて、競合条件を更新することができるため、例えば、インストールされていないデバイスに関する競合条件を保持する必要がなく、不要な競合条件を保持することによるメモリサイズの増大を防ぐことができる。また、追加、交換、あるいは削除されるデバイスの性能変化を動的に判定し、システムによって最適となるようにアプリ競合ルールを更新するので、ユーザの負荷も軽減することができる。
【図面の簡単な説明】
【００２１】
【図１】図１は、本発明の第１の実施形態に係る競合解決装置１の構成の一例を示すブロック図である。
【図２】図２は、本発明の第１の実施形態に係る競合解決装置１が実施する競合解決方法の動作の一例を示すフローチャートである。
【図３】図３は、アプリ競合ルール保存部１５が保存するアプリ競合ルールの一例を示す図である。
【図４】図４は、アプリケーションの状態毎に競合条件が規定されたアプリ競合ルールの一例を示す図である。
【図５】図５は、本発明の第１の実施形態に係る競合解決装置１が実施するアプリ競合ルールの更新方法の一例を示すフローチャートである。
【図６】図６は、デバイスリソース部２１に設定されているデバイス−リソース情報の一例を示す図である。
【図７】図７は、リソース必要情報部２２が保持するリソース必要情報の一例を示す図である。
【図８】図８は、アプリ−リソース属性管理部１６が管理するアプリ−リソース属性情報の一例を示す図である。
【図９】図９は、リソース共有・排他条件部２３が保持するリソース共有・排他条件の一例を示す図である。
【図１０】図１０は、本発明の第２の実施形態に係る競合解決装置２の構成の一例を示すブロック図である。
【図１１】図１１は、アプリ−リソース属性管理部１６が管理するアプリ−リソース属性情報の一例を示す図である。
【図１２】図１２は、アプリ−リソース属性管理部１６が管理するアプリ−リソース属性情報の一例を示す図である。
【図１３】図１３は、アプリ競合ルール保存部１５が保存するアプリ競合ルールの一例を示す図である。
【符号の説明】
【００２２】  １１    実行部
１２    アプリ管理部
１３    動作アプリ情報管理部
１４    競合判定部
１５    アプリ競合ルール
１６    アプリ−リソース属性管理部
１７    競合情報更新部
１８    デバイス−競合ルール管理部
１９    システム管理部
２０    デバイス部
２１    デバイスリソース部
２２    リソース必要情報部
２３    リソース共有・排他条件部
２４    アプリ更新部
【発明を実施するための最良の形態】
【００２３】  以下、本発明の各実施形態について、図面を参照しながら説明する。【００２４】  （第１の実施形態）
図１は、本発明の第１の実施形態に係る競合解決装置１の構成の一例を示すブロック図である。図１において、競合解決装置（情報機器）１は、実行部１１、アプリ管理部１２、動作アプリ情報管理部１３、競合判定部１４、アプリ競合ルール保存部１５、アプリ−リソース属性管理部１６、競合情報更新部１７、デバイス−競合ルール管理部１８、システム管理部１９、デバイス部２０、デバイスリソース部２１、リソース必要情報部２２、及びリソース共有・排他条件部２３を備える。【００２５】  実行部１１は、アプリ管理部１２が保存するアプリケーションを実行する。ここで、アプリケーションとは、例えば競合解決装置１が携帯電話である場合、電話アプリやブラウザアプリなどである。アプリ管理部１２は、実行部１１が実行するアプリケーションを保存すると共に、実行部１１が実行するアプリケーションの動作を管理する。動作アプリ情報管理部１３は、動作中のアプリケーションの情報を管理する。競合判定部１４は、アプリ競合ルールに基づいて、アプリケーション間の競合を判定する。【００２６】  アプリ競合ルール保存部１５は、アプリケーション間の競合ルールを規定したアプリ競合ルールを保存する（図３、図４参照）。アプリ−リソース属性管理部１６は、アプリ−リソース属性情報として、各アプリケーションが必要とするリソース情報を管理する（図８参照）。競合情報更新部１７は、アプリケーション間の競合条件が変更された場合に、アプリ競合ルールを更新する。デバイス−競合ルール管理部１８は、デバイスの状態が変化した場合に、競合条件を決定するために必要な情報の種類を特定する。【００２７】  システム管理部１９は、デバイス部２０の状態を管理する。システム管理部１９の機能は、Ｌｉｎｕｘ（登録商標）などのＯＳによって実現することができる。デバイス部２０は、競合解決装置１が備えるデバイスである。デバイス部２０は、例えば、メモリや音を再生するデバイス、通信を行なうデバイスなどである。デバイスリソース部２１は、デバイス−リソース情報として、各デバイスに対応したリソース種別等の情報を保持する（図６参照）。リソース必要情報部２２は、リソース必要情報として、リソース種別毎に競合ルールを決定するために必要な情報の種類を保持する（図７参照）。リソース共有・排他条件部２３は、リソース共有・排他条件として、リソース種別と、アプリケーションとの間の共有・排他条件を保持する（図９参照）。【００２８】  なお、実行部１１、アプリ管理部１２、動作アプリ情報管理部１３、及び競合判定部１４は、アプリ競合ルールに基づいて、複数のアプリケショーン間の競合を判定し、当該判定結果に基づいて、１つ以上のアプリケーションを実行するので、まとめてアプリケーション実行部と記すことができる。また、アプリ−リソース属性管理部１６、競合情報更新部１７、デバイス−競合ルール管理部１８、システム管理部１９、デバイスリソース部２１、リソース必要情報部２２、及びリソース共有・排他条件部２３は、競合解決装置１のリソースが変化した場合に、複数のアプリケーション間の競合条件の変化に合わせて、アプリ競合ルールを更新するので、まとめてアプリ競合ルール更新部と記すことができ���。【００２９】  図２は、本発明の第１の実施形態に係る競合解決装置１が実施する競合解決方法の動作の一例を示すフローチャートである。このフローチャートを説明するにあたり、前提条件として、すでに優先度が低いアプリケーションＡが動作中であると仮定する。また、このフローチャートでは、アプリケーションＡよりも優先度が高いアプリケーションＢが動作を要求し、アプリケーションＡは動作を中止するシナリオを記述する。【００３０】  図２を参照して、競合解決装置１は、ユーザの操作等を契機として、動作中のアプリケーションＡよりも優先度が高いアプリケーションＢの動作開始を要求する。具体的には、実行部１１は、ユーザの操作等を契機として、アプリ管理部１２に対して、アプリケーションＢの動作開始を要求する。アプリ管理部１２は、実行部１１からアプリケーションＢの動作開始を要求されると、競合判定部１４に対して、アプリケーションＢが動作可能であるかどうかの判定を依頼する（ステップＳ１１）。【００３１】  競合判定部１４は、アプリ管理部１２から動作開始を要求されたアプリケーションの起動アプリ情報を取得する（ステップＳ１２）。起動アプリ情報とは、動作開始を要求されたアプリケーションを特定するための情報であり、例えば、アプリケーションに設定された固有のＩＤなどである。ここでは、競合判定部１４は、アプリ管理部１２からアプリケーションＢの起動アプリ情報を取得するものとする。【００３２】  次に、競合判定部１４は、動作中のアプリケーションがあれば、アプリケーション間の競合を解決するために、動作中のアプリケーションの情報を動作アプリ情報管理部１３に対して問い合わせる。動作アプリ情報管理部１３は、この問い合わせに対して、動作中のアプリケーションの情報があれば競合判定部１４に返す。ここでは、動作アプリ情報管理部１３は、アプリケーションＡの情報を返すものとする。競合判定部１４は、動作アプリ情報管理部１３から返ってくる情報に基づいて、動作中のアプリケーションがあるかどうかを判定する（ステップＳ１３）。【００３３】  競合判定部１４は、動作中のアプリケーションがないと判定した場合、ステップＳ１５に状態を遷移させる。一方、競合判定部１４は、動作中のアプリケーションがあると判定した場合、アプリ競合ルールに基づいて、動作中のアプリケーションＡと、これから動作しようとしているアプリケーションＢとが競合するかどうかを判定する（ステップＳ１４）。【００３４】  図３は、アプリ競合ルール保存部１５が保存するアプリ競合ルールの一例を示す図である。図３を参照して、アプリ競合ルールには、動作中のアプリケーションＡと、新しく動作するアプリケーションＢとの間の競合条件が規定されている。例えば、動作中のアプリケーションＡはブラウザであり、新しく動作するアプリケーションＢが電話アプリであるとする。このような場合、競合判定部１４は、アプリ競合ルールを参照して、ブラウザと電話アプリとが競合すると判定する。そして、競合判定部１４は、アプリケーションＡとアプリケーションＢとが競合する場合、どうらのアプリケーションの優先度が高いかを判定する。例えば、競合判定部１４は、アプリケーションにそれぞれ優���度が設定されている場合には、アプリケーションに設定された優先度に基づいて、アプリケーション間の優先度を判定することができる。【００３５】  競合判定部１４は、競合判定した結果をアプリ管理部１２に通知する。また、競合判定部１４は、動作アプリ情報管理部１３が管理している動作中のアプリケーションの情報を更新する（ステップＳ１５）。アプリ管理部１２は、競合判定部１４からの判定結果を元に、アプリケーションＡ及びアプリケーションＢに対して所定の指示を送る（ステップＳ１６）。ここでは、アプリ管理部１２は、アプリケーションＢがアプリケーションＡより優先度が高いため、アプリケーションＡには動作の中止を指示し、アプリケーションＢには動作の開始を指示するものとする。【００３６】  なお、上述したアプリ競合ルール（図３参照）には、アプリケーション毎に競合条件が規定されていたが、アプリケーションの状態毎に競合条件が規定されていてもよい。図４は、アプリケーションの状態毎に競合条件が規定されたアプリ競合ルールの一例を示す図である。このような場合、競合解決装置１は、アプリケーションの状態に応じて、アプリケーション間の競合を判断することができる。【００３７】  例えば、競合判定部１４は、アプリケーションＡが音を鳴らしている状態で、アプリケーションＢが音を鳴らす状態で起動するか否かに基づいて、アプリケーション間の競合を判定する。あるいは、競合判定部１４は、ある状態のアプリケーションＡが確保しているメモリ量と、ある状態のアプリケーションＢが要求しているメモリ量とを加えたメモリ量が、システムが提供可能なメモリ総量よりも大きいか否かに基づいて、アプリケーション間の競合を判定する。【００３８】  より具体的な競合解決装置１の動作について、動作中のアプリケーションＡをＴＶアプリとして、新しく動作するアプリケーションＢを電話アプリとして説明する。ＴＶアプリが音を鳴らしている状態（例えば、状態１）で、電話アプリを通話可能な状態（例えば、状態２）にしようとする場合を考える。このような場合、競合判定部１４は、図４に示すアプリ競合ルールを参照して、ＴＶアプリの状態１と、電話アプリの状態２とが競合すると判定する。そして、競合判定部１４は、アプリケーションに設定された優先度に基づいて、ＴＶアプリよりも、電話アプリの方が優先度が高いと判定する。アプリ管理部１２は、競合判定部１４の判定結果に応じて、ＴＶアプリを終了させ、電話アプリの動作を開始させる。【００３９】  次に、競合解決装置１にデバイスがインストールされるなどして、デバイスの状態が変化するために競合条件が変更される場合のアプリ競合ルールの更新方法を説明する。なお、インストールという用語には、デバイスの追加、交換、あるいは削除という概念を含むものとする。図５は、本発明の第１の実施形態に係る競合解決装置１が実施するアプリ競合ルールの更新方法の一例を示すフローチャートである。ここでは、ユーザが競合解決装置１のデバイスとして、新しいメモリカードをインストールした場合を例にして具体的に説明する。【００４０】  図５を参照して、システム管理部１９は、競合解決装置１のデバイスがインストールされた場合、新しいデバイ���がインストールされたことを検知する（ステップＳ２１）。システム管理部１９は、新しいデバイスがインストールされたことを検知すると、そのデバイスを特定することができるデバイスＩＤなどと共に、デバイス−競合ルール管理部１８に対して新しいデバイスがインストールされたことを通知する。また、システム管理部１９は、同時に、新しいデバイスが使用できるように様々な設定を行う。【００４１】  デバイス−競合ルール管理部１８は、インストールされたデバイスがどのようなリソースに相当するのかを判断するため、デバイスＩＤに対応するリソース種別をデバイスリソース部２１から取得する（ステップＳ２２）。図６は、デバイスリソース部２１に設定されているデバイス−リソース情報の一例を示す図である。図６を参照して、デバイスリソース部２１は、デバイス−リソース情報として、デバイスＩＤに対応したリソース種別を保持している。ここでは、デバイス−競合ルール管理部１８は、例えば、「ｓｄ３８９３ＤＡ」というデバイスＩＤをシステム管理部１９から取得した場合、デバイス−リソース管理部２１にアクセスすることで、このデバイスがメモリデバイスであることを認識する。【００４２】  次に、デバイス−競合ルール管理部１８は、デバイスリソース部２１から取得したリソース種別を元に、リソース必要情報部２２にアクセスして、競合条件を決定するために必要な情報の種類を特定する（ステップＳ２３）。図７は、リソース必要情報部２２が保持するリソース必要情報の一例を示す図である。図７を参照して、リソース必要情報部２２は、リソース必要情報として、リソース種別毎に競合条件を決定するために必要な情報の種類を保持している。ここでは、デバイス−競合ルール管理部１８は、インストールされたデバイスがメモリデバイスであるので、競合条件を決定するために必要な情報の種類が、メモリサイズと、アプリケーションメモリサイズであることを特定する。【００４３】  デバイス−競合ルール管理部１８は、特定した情報の種類に基づいて、競合条件を決定するために必要な情報を取得する（ステップＳ２４）。デバイス−競合ルール管理部１８は、例えば、システム全体のメモリサイズをシステム管理部１９にアクセスして取得し、各アプリケーションを動作させるのに必要なメモリサイズをアプリ−リソース属性管理部１６にアクセスして取得する。図８は、アプリ−リソース属性管理部１６が管理するアプリ−リソース属性情報の一例を示す図である。図８を参照して、アプリ−リソース属性管理部１６は、アプリ−リソース属性情報として、各アプリケーションが必要とするリソース情報を管理している【００４４】  次に、デバイス−競合ルール管理部１８は、リソース共有・排他条件部２３から関連するリソースの共有・排他条件を取得する（ステップＳ２５）。図９は、リソース共有・排他条件部２３が保持するリソース共有・排他条件の一例を示す図である。図９を参照して、リソース共有・排他条件部２３は、リソース共有・排他条件として、リソース種別と、アプリケーションとの間の共有・排他条件を保持している。ここでは、インストールされたデバイスがメモリデバイスなので、デバイス−競合ルール管理部１８は、イン��トールされたデバイスがアプリケーション間で共有されることを示す共有・排他条件を取得する。また、この共有・排他条件には、デバイスのメモリサイズが、動作中のアプリケーションの総メモリサイズよりも大きくなると記述されている。【００４５】  次に、デバイス−競合ルール管理部１８は、これまでに取得した情報（この例では、インストールされたデバイスのメモリ量、元から備えていたメモリ量、各アプリケーションが使用するメモリ量、及びメモリデバイスに関する共有・排他条件など）に基づいて、アプリケーション間の競合条件が変更されるか否かを判断する（ステップＳ２６）。具体的には、デバイス−競合ルール管理部１８は、取得した情報に基づいて、各アプリケーションが動作している状態で、どのようなアプリケーションが動作できるかの条件を決定し、決定した条件を競合情報更新部１７に通知する。例えば、図８に示した４つのアプリケーションが同時に動作可能なアプリケーションである場合、全てのアプリケーションが同時に動作した場合の総メモリサイズは８０ＭＢとなり、システムが備える総メモリサイズが１２８ＭＢであるなら、全てのアプリケーションが同時に動作してもメモリサイズに関しては問題がなくなる。このような場合、メモリサイズに関する新しい競合条件が作成される。【００４６】  競合情報更新部１７は、既存の競合条件と、新しい競合条件とを比較し、競合条件に変更があれば、アプリ競合ルールを更新する（ステップＳ２７）。例えば、以前インストールされていたメモリカードのサイズが３０ＭＢであった場合、メールアプリとその他のアプリケーションとは、メモリサイズの制限から同時に動作することができなかった。しかし、デバイスの更新によってメモリサイズが増大すれば、このようなメモリサイズに関する競合はなくなる。したがって、競合情報更新部１７は、メモリサイズ以外の条件に制限がないアプリケーションに関しては、電話アプリと同時に起動できるように、アプリ競合ルールを更新する。【００４７】  また、競合解決装置１は、新しい音源ボードがインストールされた場合にも、アプリ競合ルールを更新することができる。例えば、競合解決装置１は、性能上（音再生能力）の問題によって、単一のアプリケーションが出力する音しか再生できなかったとする。このような場合、競合解決装置１は、新しい音源ボードがインストールされることで、性能上の問題がなくなり、複数の音を出力するアプリケーションを同時に動作させることができる。このように、新しい音源ボードがインストールされた場合、競合解決装置１は、アプリケーション間の競合条件が変更されるので、メモリデバイスと同様の方法を用いて、アプリ競合ルールを更新する。【００４８】  また、競合解決装置１は、新しいビデオボードがインストールされた場合にも、アプリ競合ルールを更新することができる。例えば、競合解決装置１は、性能上の問題によって、単一のアプリケーションが出力する映像しか再生することができなかったとする。このような場合に、競合解決装置１は、新しいビデオボードがインストールされることで、性能上の問題がなくなり、複数の映像を出力するアプリケーションを同時に動作させることができる。このように、新しいビデオボードがインストールされた場合、アプリケーション間の競合条件が変更されるので、競合解決装置１は、メモリデバイスと同様の方法を用いて、アプリ競合ルールを更新する。【００４９】  また、競合解決装置１は、新しいカメラがインストールされた場合にも、アプリ競合ルールを更新することができる。例えば、競合解決装置１は、カメラを１台しか備えていないために、単一のアプリケーションでしか映像を撮影できなかったとする。このような場合に、競合解決装置１は、新しいカメラがインストールされることで、カメラを２台備えることになり、複数の映像を撮影するアプリケーションを同時に動作させることができるようになる。このように、新しいカメラがインストールされた場合、アプリケーション間の競合条件が変更されるので、競合解決装置１は、メモリデバイスと同様の方法を用いて、アプリ競合ルールを更新する。【００５０】  以上のように、本発明の第１の実施形態に係る競合解決装置１によれば、デバイスが追加、交換、あるいは削除されることによって、システムが備えるリソースが変化したときに、アプリケーション間の競合条件を規定したアプリ競合ルールを自動的に更新することができる。これによって、システムを出荷した後にデバイスがインストールされた場合でも、デバイスの性能を充分に活用しつつ、不具合なく安定したアプリケーションの動作を確保することができる。【００５１】  また、システム設計者は、予め追加、交換、あるいは削除されるデバイスを予測した上で、アプリケーション間の競合条件を設計する必要がなくなる。このため、システム出荷時の負担を軽減することができる。また、想定外のデバイスを追加する必要性が生じた場合にも、システム全体を更新するのではなく、アプリ競合ルールのみを更新することで対応できる。このため、デバイス追加時の負荷も軽減することができる。【００５２】  また、システムの状況に基づいて、競合条件を更新することができるため、例えば、インストールされていないデバイスに関する競合条件を保持する必要がなく、不要な競合条件を保持することによるメモリサイズの増大を防ぐことができる。また、追加、交換、あるいは削除されるデバイスの性能変化を動的に判定して最適なアプリ競合ルールに更新するので、ユーザの負荷も軽減することができる。【００５３】  なお、上述した説明では、実行部１１が、アプリ管理部１２が保存するアプリケーションを実行すると仮定していた。しかし、実行部１１は、アプリケーションそのものを実行するのではなく、単にアプリケーションから要求を受けたミドルウェアなどのソフトウェアを実行するものであってもよい。【００５４】  また、上述した説明（図２）では、アプリケーションの動作を開始する場合のシーケンスのみを記述したが、競合判定部１４は、アプリケーションが終了する場合にも、アプリケーション間の競合判定を行ない、動作アプリ情報管理部１３を更新することも可能である。【００５５】  また、上述した説明では、競合判定部１４は、アプリケーション同士の関係によって競合判定を行っていた。しかし、競合判定部１４は、アプリケーションをタイプ別に分けたグループ毎に競合判定を行ってもよい。あ���いは、競合判定部１４は、アプリケーションが使用するリソースの種類や、その他の属性によって競合判定を行ってもよい。【００５６】  また、上述した説明では、競合判定部１４は、アプリケーション同士が競合する場合に、アプリーションに設定された優先度に基づいて、どちらのアプリケーションの優先度が高いかを判定していた。しかし、競合判定部１４は、アプリケーションが使用しているリソースの数や実行時間等の情報に基づいて優先度の判定を行っても良い。これによって、競合解決装置１は、ある少数のアプリケーションがリソースを長時間占有したり、多量のリソースを占有したりするといったことを防ぐことができる。【００５７】  また、上述したアプリ競合ルール（図３参照）には、動作中のアプリケーションＡと、新しく動作するアプリケーションＢとの間の競合条件として、“競合する”、“競合しない”、“保留”のみを記述したが、さらにアプリケーションの優先度が付加されていてもよい。これによって、競合解決装置１は、アプリ競合ルールに基づいて、アプリケーション間の優先度を判定することができる。また、競合解決装置１は、競合するアプリケーションの優先度が同じ場合には、予め決まった動作を行なうようにしてもよい。【００５８】  また、判定結果が“保留”となった場合、アプリ管理部１２は、アプリケーションＢの動作を中断するが、アプリケーションＡが動作を終了した後に、中断されていたアプリケーションＢの動作を再開してもよい。また、アプリ管理部１２は、中断されていたアプリケーションが複数ある場合には、その中から優先度が最も高いアプリケーションを選択して、選択したアプリケーションの動作を再開してもよい。これによって、競合解決装置１は、ユーザにとって利便性の高い動作を実現することができる。【００５９】  また、上述した説明では、デバイス−競合ルール管理部１８は、デバイスリソース部２１、リソース必要情報部２２、リソース共有・排他条件部２３、及びアプリ−リソース属性管理部１６などにアクセスして、競合条件を決定するために必要な情報を取得していた。しかし、デバイス−競合ルール管理部１８は、外部のサーバなどにアクセスして、競合条件を決定するために必要な情報を取得してもよい。また、このときのサーバへのアクセス手段としては、有線ケーブルによる通信やＩｒＤＡによる無線通信など、あらゆる手段を用いることができる。【００６０】  また、外部のサーバから取得する競合条件を決定するために必要な情報は、暗号化されていてもよい。このような場合、デバイス−競合ルール管理部１８は、暗号化された情報の復号化を試み、復号化できた場合にのみ取得した情報を信頼してデバイスのインストールと共に、競合条件の変更を行なってもよい。あるいは、復号に失敗した場合は、デバイスのインストールは行うが、競合条件の変更は行なわなくてもよい。【００６１】  また、上述した説明では、新しくインストールされるデバイスの情報は、取得可能であると仮定してきたが、取得できない場合でもデフォルトの属性値を予め決めておき、その値が得られたものとして扱ってもよい。【００６２】  また、競合解決装置において、アプリ管理部１２、動作アプリ情報管理部１３��競合判定部１４、競合情報更新部１７、デバイス−競合ルール管理部１８、システム管理部１９などの機能ブロックは、プログラムとして動作しても良い。このプログラムは、１つのＣＰＵ上で動作しても良いし、各機能ブロックの処理を分けて複数のＣＰＵ上で動作しても良い。【００６３】  また、アプリ競合ルール保存部１５、アプリ−リソース属性管理部１６、デバイスリソース部２１、リソース必要情報部２２、及びリソース共有・排他条件部２３などの機能ブロックは、ＲＯＭやＲＡＭに保存されるデータであってもよい。あるいは、これらの機能ブロックは、組み込み機器のメモリに保存されるデータであってもよいし、取り外し可能な外部メモリに保存されるデータであってもよい。【００６４】  また、アプリ管理部１２、動作アプリ情報管理部１３、競合判定部１４、競合情報更新部１７、デバイス−競合ルール管理部１８、システム管理部１９などの機能ブロックは、典型的には集積回路であるＬＳＩとして実現される。これらは個別に１チップ化されても良いし、一部又は全てを含むように１チップ化されても良い。ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現しても良い。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Ｆｉｅｌｄ  Ｐｒｏｇｒａｍｍａｂｌｅ  Ｇａｔｅ  Ａｒｒａｙ）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギャラブル・プロセッサを利用しても良い。さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行っても良い。例えば、バイオ技術の適応などが可能性としてありえる。【００６５】  （第２の実施形態）
図１０は、本発明の第２の実施形態に係る競合解決装置２の構成の一例を示すブロック図である。図１０において、競合解決装置２は、第１の実施形態に係る競合解決装置１と比較して、さらにアプリ更新部２４を備える。アプリ更新部２４は、何らかの通信手段を用いて、外部からアプリケーションをダウンロードし、アプリ管理部１２が保存するアプリケーションを更新する。なお、アプリ更新部２４は、通信手段を用いる以外に、アプリケーションが記憶されたメモリカード等の媒体を用いて、アプリ管理部１２が保存するアプリケショーンを更新してもよい。【００６６】  アプリ管理部１２は、更新されたアプリケーションに合わせて、競合解決装置２の各種情報を更新する。例えば、アプリ管理部１２は、更新されたアプリケーションが保持する情報に基づいて、アプリ競合ルール保存部１５が保存するアプリ競合ルール、及びアプリ−リソース属性管理部１６が管理するアプリ−リソース属性情報を更新する。なお、アプリ管理部１２は、更新されたアプリケーションに、アプリケーション間の競合条件や、使用するリソース情報が設定されている場合は、設定されている情報に基づいて、アプリ競合ルール保存部１５、及びアプリ−リソース属性管理部１６の情報を更新する。また、アプリ管理部１２は、更新されたアプリケーションに、アプリケーション間の競合条件や、使用するリソース情報が設定されていない場合は、更新されたアプリケショーンの種類等に基づいて、アプリケーション間の競合条件や、使用するリソース情報を類推し、類推した情報に基づいて、アプリ競合ルール保存部１５、及びアプリ−リソース属性管理部１６の情報を更新する。【００６７】  例えば、アプリ更新部２４は、ユーザからの指示に従って、アプリ管理部１２が保存しているブラウザアプリをバージョンアップしたとする。アプリ管理部１２は、ブラウザアプリが必要とするリソースが変更されたか否かを判定する。ここでは、ブラウザアプリが必要とするメモリサイズが、２５ＭＢから３５ＭＢに増加したとする。アプリ管理部１２は、ブラウザアプリが必要とするメモリサイズが２５ＭＢから３５ＭＢに増加したことを認識すると、ブラウザアプリのメモリリソースの設定値が３５ＭＢになるように、アプリ−リソース属性情報を更新する（図１１参照）。【００６８】  例えば、アプリ更新部２４は、ユーザからの指示に従って、ラジオアプリをダウンロードし、ラジオアプリをアプリ管理部１２に保存したとする。アプリ管理部１２は、ラジオアプリが必要とするリソース情報を取得する。ここでは、ラジオアプリが必要とするメモリサイズが５ＭＢで、音リソースが共用使用で、通信リソースが未使用であるものとする。アプリ管理部１２は、ラジオアプリが必要とするリソース情報を取得すると、アプリ−リソース属性情報にラジオアプリのリソース情報を追加する（図１２参照）。また、アプリ管理部１２は、ラジオアプリと競合する可能性のあるアプリケーションを特定する。ここでは、ラジオアプリと競合するアプリケーションが、電話アプリだけであるとする。アプリ管理部１２は、ラジオアプリと競合するアプリケーションが電話アプリであることを認識すると、アプリ競合ルールに、ラジオアプリに関する競合条件を設定する（図１３参照）。【００６９】  これによって、競合解決装置２は、アプリケーションの状態に変更があった場合も、アプリケーション間の競合を解決することができる。
【産業上の利用可能性】
【００７０】  本発明に係る競合解決装置は、携帯電話、ＰＤＡ、及びカーナビゲーション機器などのモバイル機器や、ＡＶ機器などの組み込み機器などに利用することができる。
【図１】
2007020735.tif 000002
【図２】
2007020735.tif 000003
【図３】
2007020735.tif 000004
【図４】
2007020735.tif 000005
【図５】
2007020735.tif 000006
【図６】
2007020735.tif 000007
【図７】
2007020735.tif 000008
【図８】
2007020735.tif 000009
【図９】
2007020735.tif 000010
【図１０】
2007020735.tif 000011
【図１１】
2007020735.tif 000012
【図１２】
2007020735.tif 000013
【図１３】
2007020735.tif 000014
【手続補正書】
【提出日】平成19年5月19日(2007.5.19)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
複数のアプリケーション間の競合を解決する競合解決装置であって、
前記複数のアプリケーション間の競合条件が規定されたアプリ競合ルールを保存するアプリ競合ルール保存部と、
前記アプリ競合ルールに基づいて、前記複数のアプリケショーン間の競合を判定し、当該判定結果に基づいて、１つ以上のアプリケーションを実行するアプリケーション実行部と、
前記競合解決装置のリソースが変化した場合に、前記複数のアプリケーション間の競合条件の変化に合わせて、前記アプリ競合ルールを更新するアプリ競合ルール更新部とを備えることを特徴とする、競合解決装置。
【請求項２】
前記アプリケーション実行部は、
１つ以上のアプリケーションを実行する実行部と、
前記アプリ競合ルールに基づいて、前記複数のアプリケショーン間の競合を判定する競合判定部と、
前記競合判定部の判定結果に従って、前記実行部でのアプリケーションの実行を管理するアプリ管理部とを含むことを特徴とする、請求項１に記載の競合解決装置。
【請求項３】
前記アプリ競合ルール更新部は、
前記競合解決装置が備えるデバイスの状態変化を検知するシステム管理部と、
前記デバイスの状態が変化した場合に、前記デバイスの状態が変化した後の競合解決装置のリソースを取得し、当該取得したリソースに基づいて、前記競合条件が変更されるのか否かを判断するデバイス−競合ルール管理部と、
前記競合条件が変更されると判断した場合に、前記複数のアプリケーション間の競合条件の変化に合わせて、前記アプリ競合ルールを更新する競合情報更新部とを備える、請求項１に記載の競合解決装置。
【請求項４】
前記デバイス−競合ルール管理部は、
前記デバイスの状態が変化した場合に、前記複数のアプリケーションの動作に必要なリソースを取得し、
当該取得した複数のアプリケーションの動作に必要なリソースと、前記デバイスの状態が変化した後の競合解決装置のリソースとに基づいて、前記競合条件が変更されるのか否かを判断することを特徴とする、請求項３に記載の競合解決装置。
【請求項５】
前記アプリ競合ルール更新部は、前記デバイスのリソース種別と、前記アプリケーションとの間の共有・排他条件を示すリソース共有・排他条件を保存するリソース共有・排他条件部をさらに備え、
前記デバイス−競合ルール管理部は、さらに、前記リソース共有・排他条件に基づいて、前記競合条件が変更さるのか否かを判断する、請求項３に記載の競合解決装置。
【請求項６】
前記システム管理部は、前記競合解決装置が備えるデバイスが追加、交換、あるいは削除されることによる前記デバイスの状態変化を検知することを特徴とする、請求項３に記載の競合解決装置。
【請求項７】
前記デバイスのリソース種別は、メモリであり、
前記デバイス−競合ルール管理部は、前記デバイスの状態が変化した後の前記競合解決装置のメモリ容量と、前記複数のアプリケーションの動作に必要なメモリ容量とに基づいて、前記競合条件が変更されるのか否かを判断する、請求項３に記載の競合解決装置。
【請求項８】
前記デバイスのリソース種別は、音源ボードであり、
前記デバイス−競合ルール管理部は、前記デバイスの状態が変化した後の前記競合解決装置の音再生能力と、前記複数のアプリケーションの動作に必要な音再生能力とに基づいて、前記競合条件が変更されるのか否かを判断する、請求項３に記載の競合解決装置。
【請求項９】
複数のアプリケーション間の競合を解決する情報機器が実行する競合解決方法であって、
前記情報機器には、前記複数のアプリケーション間の競合条件を規定したアプリ競合ルールが保存されており、
前記情報機器が備えるデバイスの状態変化を検知し、
前記デバイスの状態が変化した場合に、前記デバイスの状態が変化した後の前記情報機器のリソースを取得し、
取得した前記情報機器のリソースに基づいて、前記複数のアプリケーション間の競合条件が変更されるのか否かを判断し、
前記競合条件が変更されると判断した場合に、前記アプリ競合ルールを更新することを特徴とする、競合解決方法。
【請求項１０】
複数のアプリケーション間の競合を解決する情報機器が実行するプログラムであって、
前記情報機器には、前記複数のアプリケーション間の競合条件を規定したアプリ競合ルールが保存されており、
前記情報機器が備えるデバイスの状態変化を検知し、
前記デバイスの状態が変化した場合に、前記デバイスの状態が変化した後の前記情報機器のリソースを取得し、
取得した前記情報機器のリソースに基づいて、前記複数のアプリケーション間の競合条件が変更されるのか否かを判断し、
前記競合条件が変更されると判断した場合に、前記アプリ競合ルールを更新することを特徴とする、プログラム。
【請求項１１】
複数のアプリケーション間の競合を解決する情報機器が備える集積回路であって、
前記情報機器には、前記複数のアプリケーション間の競合条件を規定したアプリ競合ルールが保存されており、
前記集積回路は、
前記情報機器が備えるデバイスの状態変化を検知し、
前記デバイスの状態が変化した場合に、前記デバイスの状態が変化した後の前記情報機器のリソースを取得し、
取得した前記情報機器のリソースに基づいて、前記複数のアプリケーション間の競合条件が変更されるのか否かを判断し、
前記競合条件が変更されると判断した場合に、前記アプリ競合ルールを更新することを特徴とする、集積回路。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数のアプリケーション間の競合を解決する競合解決装置に関し、より特定的には、競合解決装置が備えるリソースが変化した場合にも、アプリケーション間の競合条件を規定したアプリ競合ルールを自動的に更新する競合解決装置に関する。
【背景技術】
【０００２】
従来より、携帯電話などの情報機器においては、特定のアプリケーション（例えば、電話の機能など）を、他のアプリケーション（例えば、メロディプレーヤなど）よりも優先させて動作させることが行なわれていた。例えば、携帯電話においては、メロディプレーヤがメロディを再生中であったとしても、電話の着信が発生した際には、再生中の音を停止した上で、着信画面を表示し、着信音を鳴動させることが行われていた。これは携帯電話においては、電話の着信があった場合に、常に着信の処理を優先させ、通話を可能としなければならないためである。また、着信時にメロディの音が鳴動していてはユーザへの通知や通話の妨げとなるために、このようなアプリケーション間の競合を解決するユーザインタフェースが実現されていた。
【０００３】
また、携帯電話、ＡＶ機器、及びカーナビゲーション機器などのアプリケーションが出荷時から組み込まれた情報機器においては、アプリケーション間の競合を解決し、より安定したシステムをユーザに提供するために、予め使用できるメモリ量と、アプリケーションが必要とするメモリ量とを計算し、起動できるアプリケーションの最大数を決定することで、システムの安定性を実現する場合もあった。
【０００４】
また、このようなアプリケーションが出荷時から組み込まれた情報機器においては、出荷前にアプリケーションの動作に関して十分にテストを行い、アプリケーション同士で競合が発生する可能性があるアプリケーションを予め組み込まないようにしていた。
【０００５】
また、特許文献１には、アプリケーション間の競合を解決するために、アプリケーション間の競合条件が規定された競合制御テーブルを参照し、新規オペレーションの実行の可否を判定すると共に、各アプリケーションに対して動作の指示を行なう情報機器が開示されている。
【特許文献１】特開２００３−１７７９２６号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかしながら、特許文献１に開示されている情報機器では、組み込まれるアプリケーションや情報機器が備えるデバイスの種類に基づいて、出荷前に想定可能な範囲でアプリケーション間の競合条件が用意されていた。そのため、出荷後となっては、新たなデバイスを追加するなどしたために、アプリケーション間の競合条件を変更した方がユーザの利便性の観点で優れていたとしても、競合条件を変更することができなかった。
【０００７】
それ故に、本発明の目的は、上述した課題を解決するものであり、出荷後にデバイスの追加などでシステムが備えるリソースが変化した場合にも、アプリケーション間の競合条件を規定したアプリ競合ルールを自動的に更新することができる競合解決装置を提供することである。
【課題を解決するための手段】
【０００８】
本発明は、複数のアプリケーション間の競合を解決する競合解決装置に向けられている。そして、上記目的を達成させるために、本発明の競合解決装置は、複数のアプリケーション間の競合条件が規定されたアプリ競合ルールを保存するアプリ競合ルール保存部と、アプリ競合ルールに基づいて、複数のアプリケショーン間の競合を判定し、当該判定結果に基づいて、１つ以上のアプリケーションを実行するアプリケーション実行部と、競合解決装置のリソースが変化した場合に、複数のアプリケーション間の競合条件の変化に合わせて、アプリ競合ルールを更新するアプリ競合ルール更新部とを備える。
【０００９】
好ましくは、アプリケーション実行部は、１つ以上のアプリケーションを実行する実行部と、アプリ競合ルールに基づいて、複数のアプリケショーン間の競合を判定する競合判定部と、競合判定部の判定結果に従って、実行部でのアプリケーションの実行を管理するアプリ管理部とを含む。
【００１０】
好ましくは、アプリ競合ルール更新部は、競合解決装置が備えるデバイスの状態変化を検知するシステム管理部と、デバイスの状態が変化した場合に、デバイスの状態が変化した後の競合解決装置のリソースを取得し、当該取得したリソースに基づいて、競合条件が変更されるのか否かを判断するデバイス−競合ルール管理部と、競合条件が変更されると判断した場合に、複数のアプリケーション間の競合条件の変化に合わせて、アプリ競合ルールを更新する競合情報更新部とを備える。
【００１１】
また、デバイス−競合ルール管理部は、デバイスの状態が変化した場合に、複数のアプリケーションの動作に必要なリソースを取得し、取得した複数のアプリケーションの動作に必要なリソースと、デバイスの状態が変化した後の競合解決装置のリソースとに基づいて、競合条件が変更されるのか否かを判断してもよい。
【００１２】
好ましくは、アプリ競合ルール更新部は、デバイスのリソース種別と、アプリケーションとの間の共有・排他条件を示すリソース共有・排他条件を保存するリソース共有・排他条件部をさらに備える。この場合、デバイス−競合ルール管理部は、さらに、リソース共有・排他条件に基づいて、競合条件が変更さるのか否かを判断する。
【００１３】
好ましくは、システム管理部は、競合解決装置が備えるデバイスが追加、交換、あるいは削除されることによるデバイスの状態変化を検知する。
【００１４】
例えば、デバイスのリソース種別は、メモリである。この場合、デバイス−競合ルール管理部は、デバイスの状態が変化した後の競合解決装置のメモリ容量と、複数のアプリケーションの動作に必要なメモリ容量とに基づいて、競合条件が変更されるのか否かを判断する。
【００１５】
例えば、デバイスのリソース種別は、音源ボードである。この場合、デバイス−競合ルール管理部は、デバイスの状態が変化した後の競合解決装置の音再生能力と、複数のアプリケーションの動作に必要な音再生能力とに基づいて、競合条件が変更されるのか否かを判断する。
【００１６】
また、本発明は、複数のアプリケーション間の競合を解決する情報機器が実行する競合解決方法にも向けられている。ただし、情報機器には、複数のアプリケーション間の競合条件を規定したアプリ競合ルールが保存されている。そして、上記目的を達成させるために、本発明の競合解決方法は、情報機器が備えるデバイスの状態変化を検知し、デバイスの状態が変化した場合に、デバイスの状態が変化した後の情報機器のリソースを取得し、取得した情報機器のリソースに基づいて、複数のアプリケーション間の競合条件が変更されるのか否かを判断し、競合条件が変更されると判断した場合に、アプリ競合ルールを更新する。
【００１７】
好ましくは、この競合解決方法は、一連の処理手順を情報機器に実行させるためにプログラムの形式で提供される。このプログラムは、コンピュータが読みとり可能な記憶媒体に記憶されてもよい。また、この競合解決方法は、情報機器が備える集積回路として提要されてもよい。
【発明の効果】
【００１８】
以上のように本発明によれば、デバイスが追加、交換、あるいは削除されることによって、システムが備えるリソースが変化したときに、アプリケーション間の競合条件を規定したアプリ競合ルールを自動的に更新することができる。これによって、システムを出荷した後にデバイスがインストールされた場合でも、デバイスの性能を充分に活用しつつ、不具合なく安定したアプリケーションの動作を確保することができる。
【００１９】
また、システム設計者は、予め追加、交換、あるいは削除されるデバイスを予測した上で、アプリケーション間の競合条件を設計する必要がなくなる。このため、システム出荷時の負荷を軽減することができる。また、想定外のデバイスを追加する必要性が生じた場合にも、システム全体を更新するのではなく、アプリ競合ルールのみを更新することで対応できる。このため、デバイス追加時の負荷も軽減することができる。
【００２０】
また、システムの状況に基づいて、競合条件を更新することができるため、例えば、インストールされていないデバイスに関する競合条件を保持する必要がなく、不要な競合条件を保持することによるメモリサイズの増大を防ぐことができる。また、追加、交換、あるいは削除されるデバイスの性能変化を動的に判定し、システムによって最適となるようにアプリ競合ルールを更新するので、ユーザの負荷も軽減することができる。
【発明を実施するための最良の形態】
【００２１】
以下、本発明の各実施形態について、図面を参照しながら説明する。
【００２２】
（第１の実施形態）
図１は、本発明の第１の実施形態に係る競合解決装置１の構成の一例を示すブロック図である。図１において、競合解決装置（情報機器）１は、実行部１１、アプリ管理部１２、動作アプリ情報管理部１３、競合判定部１４、アプリ競合ルール保存部１５、アプリ−リソース属性管理部１６、競合情報更新部１７、デバイス−競合ルール管理部１８、システム管理部１９、デバイス部２０、デバイスリソース部２１、リソース必要情報部２２、及びリソース共有・排他条件部２３を備える。
【００２３】
実行部１１は、アプリ管理部１２が保存するアプリケーションを実行する。ここで、アプリケーションとは、例えば競合解決装置１が携帯電話である場合、電話アプリやブラウザアプリなどである。アプリ管理部１２は、実行部１１が実行するアプリケーションを保存すると共に、実行部１１が実行するアプリケーションの動作を管理する。動作アプリ情報管理部１３は、動作中のアプリケーションの情報を管理する。競合判定部１４は、アプリ競合ルールに基づいて、アプリケーション間の競合を判定する。
【００２４】
アプリ競合ルール保存部１５は、アプリケーション間の競合ルールを規定したアプリ競合ルールを保存する（図３、図４参照）。アプリ−リソース属性管理部１６は、アプリ−リソース属性情報として、各アプリケーションが必要とするリソース情報を管理する（図８参照）。競合情報更新部１７は、アプリケーション間の競合条件が変更された場合に、アプリ競合ルールを更新する。デバイス−競合ルール管理部１８は、デバイスの状態が変化した場合に、競合条件を決定するために必要な情報の種類を特定する。
【００２５】
システム管理部１９は、デバイス部２０の状態を管理する。システム管理部１９の機能は、Ｌｉｎｕｘ（登録商標）などのＯＳによって実現することができる。デバイス部２０は、競合解決装置１が備えるデバイスである。デバイス部２０は、例えば、メモリや音を再生するデバイス、通信を行なうデバイスなどである。デバイスリソース部２１は、デバイス−リソース情報として、各デバイスに対応したリソース種別等の情報を保持する（図６参照）。リソース必要情報部２２は、リソース必要情報として、リソース種別毎に競合ルールを決定するために必要な情報の種類を保持する（図７参照）。リソース共有・排他条件部２３は、リソース共有・排他条件として、リソース種別と、アプリケーションとの間の共有・排他条件を保持する（図９参照）。
【００２６】
なお、実行部１１、アプリ管理部１２、動作アプリ情報管理部１３、及び競合判定部１４は、アプリ競合ルールに基づいて、複数のアプリケショーン間の競合を判定し、当該判定結果に基づいて、１つ以上のアプリケーションを実行するので、まとめてアプリケーション実行部と記すことができる。また、アプリ−リソース属性管理部１６、競合情報更新部１７、デバイス−競合ルール管理部１８、システム管理部１９、デバイスリソース部２１、リソース必要情報部２２、及びリソース共有・排他条件部２３は、競合解決装置１のリソースが変化した場合に、複数のアプリケーション間の競合条件の変化に合わせて、アプリ競合ルールを更新するので、まとめてアプリ競合ルール更新部と記すことができる。
【００２７】
図２は、本発明の第１の実施形態に係る競合解決装置１が実施する競合解決方法の動作の一例を示すフローチャートである。このフローチャートを説明するにあたり、前提条件として、すでに優先度が低いアプリケーションＡが動作中であると仮定する。また、このフローチャートでは、アプリケーションＡよりも優先度が高いアプリケーションＢが動作を要求し、アプリケーションＡは動作を中止するシナリオを記述する。
【００２８】
図２を参照して、競合解決装置１は、ユーザの操作等を契機として、動作中のアプリケーションＡよりも優先度が高いアプリケーションＢの動作開始を要求する。具体的には、実行部１１は、ユーザの操作等を契機として、アプリ管理部１２に対して、アプリケーションＢの動作開始を要求する。アプリ管理部１２は、実行部１１からアプリケーションＢの動作開始を要求されると、競合判定部１４に対して、アプリケーションＢが動作可能であるかどうかの判定を依頼する（ステップＳ１１）。
【００２９】
競合判定部１４は、アプリ管理部１２から動作開始を要求されたアプリケーションの起動アプリ情報を取得する（ステップＳ１２）。起動アプリ情報とは、動作開始を要求されたアプリケーションを特定するための情報であり、例えば、アプリケーションに設定された固有のＩＤなどである。ここでは、競合判定部１４は、アプリ管理部１２からアプリケーションＢの起動アプリ情報を取得するものとする。
【００３０】
次に、競合判定部１４は、動作中のアプリケーションがあれば、アプリケーション間の競合を解決するために、動作中のアプリケーションの情報を動作アプリ情報管理部１３に対して問い合わせる。動作アプリ情報管理部１３は、この問い合わせに対して、動作中のアプリケーションの情報があれば競合判定部１４に返す。ここでは、動作アプリ情報管理部１３は、アプリケーションＡの情報を返すものとする。競合判定部１４は、動作アプリ情報管理部１３から返ってくる情報に基づいて、動作中のアプリケーションがあるかどうかを判定する（ステップＳ１３）。
【００３１】
競合判定部１４は、動作中のアプリケーションがないと判定した場合、ステップＳ１５に状態を遷移させる。一方、競合判定部１４は、動作中のアプリケーションがあると判定した場合、アプリ競合ルールに基づいて、動作中のアプリケーションＡと、これから動作しようとしているアプリケーションＢとが競合するかどうかを判定する（ステップＳ１４）。
【００３２】
図３は、アプリ競合ルール保存部１５が保存するアプリ競合ルールの一例を示す図である。図３を参照して、アプリ競合ルールには、動作中のアプリケーションＡと、新しく動作するアプリケーションＢとの間の競合条件が規定されている。例えば、動作中のアプリケーションＡはブラウザであり、新しく動作するアプリケーションＢが電話アプリであるとする。このような場合、競合判定部１４は、アプリ競合ルールを参照して、ブラウザと電話アプリとが競合すると判定する。そして、競合判定部１４は、アプリケーションＡとアプリケーションＢとが競合する場合、どうらのアプリケーションの優先度が高いかを判定する。例えば、競合判定部１４は、アプリケーションにそれぞれ優先度が設定されている場合には、アプリケーションに設定された優先度に基づいて、アプリケーション間の優先度を判定することができる。
【００３３】
競合判定部１４は、競合判定した結果をアプリ管理部１２に通知する。また、競合判定部１４は、動作アプリ情報管理部１３が管理している動作中のアプリケーションの情報を更新する（ステップＳ１５）。アプリ管理部１２は、競合判定部１４からの判定結果を元に、アプリケーションＡ及びアプリケーションＢに対して所定の指示を送る（ステップＳ１６）。ここでは、アプリ管理部１２は、アプリケーションＢがアプリケーションＡより優先度が高いため、アプリケーションＡには動作の中止を指示し、アプリケーションＢには動作の開始を指示するものとする。
【００３４】
なお、上述したアプリ競合ルール（図３参照）には、アプリケーション毎に競合条件が規定されていたが、アプリケーションの状態毎に競合条件が規定されていてもよい。図４は、アプリケーションの状態毎に競合条件が規定されたアプリ競合ルールの一例を示す図である。このような場合、競合解決装置１は、アプリケーションの状態に応じて、アプリケーション間の競合を判断することができる。
【００３５】
例えば、競合判定部１４は、アプリケーションＡが音を鳴らしている状態で、アプリケーションＢが音を鳴らす状態で起動するか否かに基づいて、アプリケーション間の競合を判定する。あるいは、競合判定部１４は、ある状態のアプリケーションＡが確保しているメモリ量と、ある状態のアプリケーションＢが要求しているメモリ量とを加えたメモリ量が、システムが提供可能なメモリ総量よりも大きいか否かに基づいて、アプリケーション間の競合を判定する。
【００３６】
より具体的な競合解決装置１の動作について、動作中のアプリケーションＡをＴＶアプリとして、新しく動作するアプリケーションＢを電話アプリとして説明する。ＴＶアプリが音を鳴らしている状態（例えば、状態１）で、電話アプリを通話可能な状態（例えば、状態２）にしようとする場合を考える。このような場合、競合判定部１４は、図４に示すアプリ競合ルールを参照して、ＴＶアプリの状態１と、電話アプリの状態２とが競合すると判定する。そして、競合判定部１４は、アプリケーションに設定された優先度に基づいて、ＴＶアプリよりも、電話アプリの方が優先度が高いと判定する。アプリ管理部１２は、競合判定部１４の判定結果に応じて、ＴＶアプリを終了させ、電話アプリの動作を開始させる。
【００３７】
次に、競合解決装置１にデバイスがインストールされるなどして、デバイスの状態が変化するために競合条件が変更される場合のアプリ競合ルールの更新方法を説明する。なお、インストールという用語には、デバイスの追加、交換、あるいは削除という概念を含むものとする。図５は、本発明の第１の実施形態に係る競合解決装置１が実施するアプリ競合ルールの更新方法の一例を示すフローチャートである。ここでは、ユーザが競合解決装置１のデバイスとして、新しいメモリカードをインストールした場合を例にして具体的に説明する。
【００３８】
図５を参照して、システム管理部１９は、競合解決装置１のデバイスがインストールされた場合、新しいデバイスがインストールされたことを検知する（ステップＳ２１）。システム管理部１９は、新しいデバイスがインストールされたことを検知すると、そのデバイスを特定することができるデバイスＩＤなどと共に、デバイス−競合ルール管理部１８に対して新しいデバイスがインストールされたことを通知する。また、システム管理部１９は、同時に、新しいデバイスが使用できるように様々な設定を行う。
【００３９】
デバイス−競合ルール管理部１８は、インストールされたデバイスがどのようなリソースに相当するのかを判断するため、デバイスＩＤに対応するリソース種別をデバイスリソース部２１から取得する（ステップＳ２２）。図６は、デバイスリソース部２１に設定されているデバイス−リソース情報の一例を示す図である。図６を参照して、デバイスリソース部２１は、デバイス−リソース情報として、デバイスＩＤに対応したリソース種別を保持している。ここでは、デバイス−競合ルール管理部１８は、例えば、「ｓｄ３８９３ＤＡ」というデバイスＩＤをシステム管理部１９から取得した場合、デバイス−リソース管理部２１にアクセスすることで、このデバイスがメモリデバイスであることを認識する。
【００４０】
次に、デバイス−競合ルール管理部１８は、デバイスリソース部２１から取得したリソース種別を元に、リソース必要情報部２２にアクセスして、競合条件を決定するために必要な情報の種類を特定する（ステップＳ２３）。図７は、リソース必要情報部２２が保持するリソース必要情報の一例を示す図である。図７を参照して、リソース必要情報部２２は、リソース必要情報として、リソース種別毎に競合条件を決定するために必要な情報の種類を保持している。ここでは、デバイス−競合ルール管理部１８は、インストールされたデバイスがメモリデバイスであるので、競合条件を決定するために必要な情報の種類が、メモリサイズと、アプリケーションメモリサイズであることを特定する。
【００４１】
デバイス−競合ルール管理部１８は、特定した情報の種類に基づいて、競合条件を決定するために必要な情報を取得する（ステップＳ２４）。デバイス−競合ルール管理部１８は、例えば、システム全体のメモリサイズをシステム管理部１９にアクセスして取得し、各アプリケーションを動作させるのに必要なメモリサイズをアプリ−リソース属性管理部１６にアクセスして取得する。図８は、アプリ−リソース属性管理部１６が管理するアプリ−リソース属性情報の一例を示す図である。図８を参照して、アプリ−リソース属性管理部１６は、アプリ−リソース属性情報として、各アプリケーションが必要とするリソース情報を管理している
【００４２】
次に、デバイス−競合ルール管理部１８は、リソース共有・排他条件部２３から関連するリソースの共有・排他条件を取得する（ステップＳ２５）。図９は、リソース共有・排他条件部２３が保持するリソース共有・排他条件の一例を示す図である。図９を参照して、リソース共有・排他条件部２３は、リソース共有・排他条件として、リソース種別と、アプリケーションとの間の共有・排他条件を保持している。ここでは、インストールされたデバイスがメモリデバイスなので、デバイス−競合ルール管理部１８は、インストールされたデバイスがアプリケーション間で共有されることを示す共有・排他条件を取得する。また、この共有・排他条件には、デバイスのメモリサイズが、動作中のアプリケーションの総メモリサイズよりも大きくなると記述されている。
【００４３】
次に、デバイス−競合ルール管理部１８は、これまでに取得した情報（この例では、インストールされたデバイスのメモリ量、元から備えていたメモリ量、各アプリケーションが使用するメモリ量、及びメモリデバイスに関する共有・排他条件など）に基づいて、アプリケーション間の競合条件が変更されるか否かを判断する（ステップＳ２６）。具体的には、デバイス−競合ルール管理部１８は、取得した情報に基づいて、各アプリケーションが動作している状態で、どのようなアプリケーションが動作できるかの条件を決定し、決定した条件を競合情報更新部１７に通知する。例えば、図８に示した４つのアプリケーションが同時に動作可能なアプリケーションである場合、全てのアプリケーションが同時に動作した場合の総メモリサイズは８０ＭＢとなり、システムが備える総メモリサイズが１２８ＭＢであるなら、全てのアプリケーションが同時に動作してもメモリサイズに関しては問題がなくなる。このような場合、メモリサイズに関する新しい競合条件が作成される。
【００４４】
競合情報更新部１７は、既存の競合条件と、新しい競合条件とを比較し、競合条件に変更があれば、アプリ競合ルールを更新する（ステップＳ２７）。例えば、以前インストールされていたメモリカードのサイズが３０ＭＢであった場合、メールアプリとその他のアプリケーションとは、メモリサイズの制限から同時に動作することができなかった。しかし、デバイスの更新によってメモリサイズが増大すれば、このようなメモリサイズに関する競合はなくなる。したがって、競合情報更新部１７は、メモリサイズ以外の条件に制限がないアプリケーションに関しては、電話アプリと同時に起動できるように、アプリ競合ルールを更新する。
【００４５】
また、競合解決装置１は、新しい音源ボードがインストールされた場合にも、アプリ競合ルールを更新することができる。例えば、競合解決装置１は、性能上（音再生能力）の問題によって、単一のアプリケーションが出力する音しか再生できなかったとする。このような場合、競合解決装置１は、新しい音源ボードがインストールされることで、性能上の問題がなくなり、複数の音を出力するアプリケーションを同時に動作させることができる。このように、新しい音源ボードがインストールされた場合、競合解決装置１は、アプリケーション間の競合条件が変更されるので、メモリデバイスと同様の方法を用いて、アプリ競合ルールを更新する。
【００４６】
また、競合解決装置１は、新しいビデオボードがインストールされた場合にも、アプリ競合ルールを更新することができる。例えば、競合解決装置１は、性能上の問題によって、単一のアプリケーションが出力する映像しか再生することができなかったとする。このような場合に、競合解決装置１は、新しいビデオボードがインストールされることで、性能上の問題がなくなり、複数の映像を出力するアプリケーションを同時に動作させることができる。このように、新しいビデオボードがインストールされた場合、アプリケーション間の競合条件が変更されるので、競合解決装置１は、メモリデバイスと同様の方法を用いて、アプリ競合ルールを更新する。
【００４７】
また、競合解決装置１は、新しいカメラがインストールされた場合にも、アプリ競合ルールを更新することができる。例えば、競合解決装置１は、カメラを１台しか備えていないために、単一のアプリケーションでしか映像を撮影できなかったとする。このような場合に、競合解決装置１は、新しいカメラがインストールされることで、カメラを２台備えることになり、複数の映像を撮影するアプリケーションを同時に動作させることができるようになる。このように、新しいカメラがインストールされた場合、アプリケーション間の競合条件が変更されるので、競合解決装置１は、メモリデバイスと同様の方法を用いて、アプリ競合ルールを更新する。
【００４８】
以上のように、本発明の第１の実施形態に係る競合解決装置１によれば、デバイスが追加、交換、あるいは削除されることによって、システムが備えるリソースが変化したときに、アプリケーション間の競合条件を規定したアプリ競合ルールを自動的に更新することができる。これによって、システムを出荷した後にデバイスがインストールされた場合でも、デバイスの性能を充分に活用しつつ、不具合なく安定したアプリケーションの動作を確保することができる。
【００４９】
また、システム設計者は、予め追加、交換、あるいは削除されるデバイスを予測した上で、アプリケーション間の競合条件を設計する必要がなくなる。このため、システム出荷時の負担を軽減することができる。また、想定外のデバイスを追加する必要性が生じた場合にも、システム全体を更新するのではなく、アプリ競合ルールのみを更新することで対応できる。このため、デバイス追加時の負荷も軽減することができる。
【００５０】
また、システムの状況に基づいて、競合条件を更新することができるため、例えば、インストールされていないデバイスに関する競合条件を保持する必要がなく、不要な競合条件を保持することによるメモリサイズの増大を防ぐことができる。また、追加、交換、あるいは削除されるデバイスの性能変化を動的に判定して最適なアプリ競合ルールに更新するので、ユーザの負荷も軽減することができる。
【００５１】
なお、上述した説明では、実行部１１が、アプリ管理部１２が保存するアプリケーションを実行すると仮定していた。しかし、実行部１１は、アプリケーションそのものを実行するのではなく、単にアプリケーションから要求を受けたミドルウェアなどのソフトウェアを実行するものであってもよい。
【００５２】
また、上述した説明（図２）では、アプリケーションの動作を開始する場合のシーケンスのみを記述したが、競合判定部１４は、アプリケーションが終了する場合にも、アプリケーション間の競合判定を行ない、動作アプリ情報管理部１３を更新することも可能である。
【００５３】
また、上述した説明では、競合判定部１４は、アプリケーション同士の関係によって競合判定を行っていた。しかし、競合判定部１４は、アプリケーションをタイプ別に分けたグループ毎に競合判定を行ってもよい。あるいは、競合判定部１４は、アプリケーションが使用するリソースの種類や、その他の属性によって競合判定を行ってもよい。
【００５４】
また、上述した説明では、競合判定部１４は、アプリケーション同士が競合する場合に、アプリーションに設定された優先度に基づいて、どちらのアプリケーションの優先度が高いかを判定していた。しかし、競合判定部１４は、アプリケーションが使用しているリソースの数や実行時間等の情報に基づいて優先度の判定を行っても良い。これによって、競合解決装置１は、ある少数のアプリケーションがリソースを長時間占有したり、多量のリソースを占有したりするといったことを防ぐことができる。
【００５５】
また、上述したアプリ競合ルール（図３参照）には、動作中のアプリケーションＡと、新しく動作するアプリケーションＢとの間の競合条件として、“競合する”、“競合しない”、“保留”のみを記述したが、さらにアプリケーションの優先度が付加されていてもよい。これによって、競合解決装置１は、アプリ競合ルールに基づいて、アプリケーション間の優先度を判定することができる。また、競合解決装置１は、競合するアプリケーションの優先度が同じ場合には、予め決まった動作を行なうようにしてもよい。
【００５６】
また、判定結果が“保留”となった場合、アプリ管理部１２は、アプリケーションＢの動作を中断するが、アプリケーションＡが動作を終了した後に、中断されていたアプリケーションＢの動作を再開してもよい。また、アプリ管理部１２は、中断されていたアプリケーションが複数ある場合には、その中から優先度が最も高いアプリケーションを選択して、選択したアプリケーションの動作を再開してもよい。これによって、競合解決装置１は、ユーザにとって利便性の高い動作を実現することができる。
【００５７】
また、上述した説明では、デバイス−競合ルール管理部１８は、デバイスリソース部２１、リソース必要情報部２２、リソース共有・排他条件部２３、及びアプリ−リソース属性管理部１６などにアクセスして、競合条件を決定するために必要な情報を取得していた。しかし、デバイス−競合ルール管理部１８は、外部のサーバなどにアクセスして、競合条件を決定するために必要な情報を取得してもよい。また、このときのサーバへのアクセス手段としては、有線ケーブルによる通信やＩｒＤＡによる無線通信など、あらゆる手段を用いることができる。
【００５８】
また、外部のサーバから取得する競合条件を決定するために必要な情報は、暗号化されていてもよい。このような場合、デバイス−競合ルール管理部１８は、暗号化された情報の復号化を試み、復号化できた場合にのみ取得した情報を信頼してデバイスのインストールと共に、競合条件の変更を行なってもよい。あるいは、復号に失敗した場合は、デバイスのインストールは行うが、競合条件の変更は行なわなくてもよい。
【００５９】
また、上述した説明では、新しくインストールされるデバイスの情報は、取得可能であると仮定してきたが、取得できない場合でもデフォルトの属性値を予め決めておき、その値が得られたものとして扱ってもよい。
【００６０】
また、競合解決装置において、アプリ管理部１２、動作アプリ情報管理部１３、競合判定部１４、競合情報更新部１７、デバイス−競合ルール管理部１８、システム管理部１９などの機能ブロックは、プログラムとして動作しても良い。このプログラムは、１つのＣＰＵ上で動作しても良いし、各機能ブロックの処理を分けて複数のＣＰＵ上で動作しても良い。
【００６１】
また、アプリ競合ルール保存部１５、アプリ−リソース属性管理部１６、デバイスリソース部２１、リソース必要情報部２２、及びリソース共有・排他条件部２３などの機能ブロックは、ＲＯＭやＲＡＭに保存されるデータであってもよい。あるいは、これらの機能ブロックは、組み込み機器のメモリに保存されるデータであってもよいし、取り外し可能な外部メモリに保存されるデータであってもよい。
【００６２】
また、アプリ管理部１２、動作アプリ情報管理部１３、競合判定部１４、競合情報更新部１７、デバイス−競合ルール管理部１８、システム管理部１９などの機能ブロックは、典型的には集積回路であるＬＳＩとして実現される。これらは個別に１チップ化されても良いし、一部又は全てを含むように１チップ化されても良い。ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現しても良い。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Ｆｉｅｌｄ  Ｐｒｏｇｒａｍｍａｂｌｅ  Ｇａｔｅ  Ａｒｒａｙ）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギャラブル・プロセッサを利用しても良い。さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行っても良い。例えば、バイオ技術の適応などが可能性としてありえる。
【００６３】
（第２の実施形態）
図１０は、本発明の第２の実施形態に係る競合解決装置２の構成の一例を示すブロック図である。図１０において、競合解決装置２は、第１の実施形態に係る競合解決装置１と比較して、さらにアプリ更新部２４を備える。アプリ更新部２４は、何らかの通信手段を用いて、外部からアプリケーションをダウンロードし、アプリ管理部１２が保存するアプリケーションを更新する。なお、アプリ更新部２４は、通信手段を用いる以外に、アプリケーションが記憶されたメモリカード等の媒体を用いて、アプリ管理部１２が保存するアプリケショーンを更新してもよい。
【００６４】
アプリ管理部１２は、更新されたアプリケーションに合わせて、競合解決装置２の各種情報を更新する。例えば、アプリ管理部１２は、更新されたアプリケーションが保持する情報に基づいて、アプリ競合ルール保存部１５が保存するアプリ競合ルール、及びアプリ−リソース属性管理部１６が管理するアプリ−リソース属性情報を更新する。なお、アプリ管理部１２は、更新されたアプリケーションに、アプリケーション間の競合条件や、使用するリソース情報が設定されている場合は、設定されている情報に基づいて、アプリ競合ルール保存部１５、及びアプリ−リソース属性管理部１６の情報を更新する。また、アプリ管理部１２は、更新されたアプリケーションに、アプリケーション間の競合条件や、使用するリソース情報が設定されていない場合は、更新されたアプリケショーンの種類等に基づいて、アプリケーション間の競合条件や、使用するリソース情報を類推し、類推した情報に基づいて、アプリ競合ルール保存部１５、及びアプリ−リソース属性管理部１６の情報を更新する。
【００６５】
例えば、アプリ更新部２４は、ユーザからの指示に従って、アプリ管理部１２が保存しているブラウザアプリをバージョンアップしたとする。アプリ管理部１２は、ブラウザアプリが必要とするリソースが変更されたか否かを判定する。ここでは、ブラウザアプリが必要とするメモリサイズが、２５ＭＢから３５ＭＢに増加したとする。アプリ管理部１２は、ブラウザアプリが必要とするメモリサイズが２５ＭＢから３５ＭＢに増加したことを認識すると、ブラウザアプリのメモリリソースの設定値が３５ＭＢになるように、アプリ−リソース属性情報を更新する（図１１参照）。
【００６６】
例えば、アプリ更新部２４は、ユーザからの指示に従って、ラジオアプリをダウンロードし、ラジオアプリをアプリ管理部１２に保存したとする。アプリ管理部１２は、ラジオアプリが必要とするリソース情報を取得する。ここでは、ラジオアプリが必要とするメモリサイズが５ＭＢで、音リソースが共用使用で、通信リソースが未使用であるものとする。アプリ管理部１２は、ラジオアプリが必要とするリソース情報を取得すると、アプリ−リソース属性情報にラジオアプリのリソース情報を追加する（図１２参照）。また、アプリ管理部１２は、ラジオアプリと競合する可能性のあるアプリケーションを特定する。ここでは、ラジオアプリと競合するアプリケーションが、電話アプリだけであるとする。アプリ管理部１２は、ラジオアプリと競合するアプリケーションが電話アプリであることを認識すると、アプリ競合ルールに、ラジオアプリに関する競合条件を設定する（図１３参照）。
【００６７】
これによって、競合解決装置２は、アプリケーションの状態に変更があった場合も、アプリケーション間の競合を解決することができる。
【産業上の利用可能性】
【００６８】
本発明に係る競合解決装置は、携帯電話、ＰＤＡ、及びカーナビゲーション機器などのモバイル機器や、ＡＶ機器などの組み込み機器などに利用することができる。
【図面の簡単な説明】
【００６９】
【図１】本発明の第１の実施形態に係る競合解決装置１の構成の一例を示すブロック図
【図２】本発明の第１の実施形態に係る競合解決装置１が実施する競合解決方法の動作の一例を示すフローチャート
【図３】アプリ競合ルール保存部１５が保存するアプリ競合ルールの一例を示す図
【図４】アプリケーションの状態毎に競合条件が規定されたアプリ競合ルールの一例を示す図
【図５】本発明の第１の実施形態に係る競合解決装置１が実施するアプリ競合ルールの更新方法の一例を示すフローチャート
【図６】デバイスリソース部２１に設定されているデバイス−リソース情報の一例を示す図
【図７】リソース必要情報部２２が保持するリソース必要情報の一例を示す図
【図８】アプリ−リソース属性管理部１６が管理するアプリ−リソース属性情報の一例を示す図
【図９】リソース共有・排他条件部２３が保持するリソース共有・排他条件の一例を示す図
【図１０】本発明の第２の実施形態に係る競合解決装置２の構成の一例を示すブロック図
【図１１】アプリ−リソース属性管理部１６が管理するアプリ−リソース属性情報の一例を示す図
【図１２】アプリ−リソース属性管理部１６が管理するアプリ−リソース属性情報の一例を示す図
【図１３】アプリ競合ルール保存部１５が保存するアプリ競合ルールの一例を示す図
【符号の説明】
【００７０】
１１    実行部
１２    アプリ管理部
１３    動作アプリ情報管理部
１４    競合判定部
１５    アプリ競合ルール
１６    アプリ−リソース属性管理部
１７    競合情報更新部
１８    デバイス−競合ルール管理部
１９    システム管理部
２０    デバイス部
２１    デバイスリソース部
２２    リソース必要情報部
２３    リソース共有・排他条件部
２４    アプリ更新部
【手続補正３】
【補正対象書類名】図面
【補正対象項目名】全図
【補正方法】変更
【補正の内容】
【図１】
2007020735.tif 000015
【図２】
2007020735.tif 000016
【図３】
2007020735.tif 000017
【図４】
2007020735.tif 000018
【図５】
2007020735.tif 000019
【図６】
2007020735.tif 000020
【図７】
2007020735.tif 000021
【図８】
2007020735.tif 000022
【図９】
2007020735.tif 000023
【図１０】
2007020735.tif 000024
【図１１】
2007020735.tif 000025
【図１２】
2007020735.tif 000026
【図１３】
2007020735.tif 000027
【国際調査報告】
2007020735.tif 000028
2007020735.tif 000029
2007020735.tif 000030
2007020735.tif 000031