JPWO2007020735A1 - 競合解決装置 - Google Patents

競合解決装置 Download PDF

Info

Publication number
JPWO2007020735A1
JPWO2007020735A1 JP2007530915A JP2007530915A JPWO2007020735A1 JP WO2007020735 A1 JPWO2007020735 A1 JP WO2007020735A1 JP 2007530915 A JP2007530915 A JP 2007530915A JP 2007530915 A JP2007530915 A JP 2007530915A JP WO2007020735 A1 JPWO2007020735 A1 JP WO2007020735A1
Authority
JP
Japan
Prior art keywords
application
competition
applications
conflict
rule
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2007530915A
Other languages
English (en)
Other versions
JP4960237B2 (ja
Inventor
稲見　聡
聡 稲見
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Panasonic Corp
Panasonic Holdings Corp
Original Assignee
Panasonic Corp
Matsushita Electric Industrial Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Panasonic Corp, Matsushita Electric Industrial Co Ltd filed Critical Panasonic Corp
Priority to JP2007530915A priority Critical patent/JP4960237B2/ja
Publication of JPWO2007020735A1 publication Critical patent/JPWO2007020735A1/ja
Application granted granted Critical
Publication of JP4960237B2 publication Critical patent/JP4960237B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44552—Conflict resolution, i.e. enabling coexistence of conflicting executables

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Stored Programmes (AREA)

Abstract

デバイスをインストールしたり、取り外した後でも、アプリケーション間の競合条件を規定したアプリ競合ルールを自動的に更新する競合解決装置を提供する。アプリ競合ルール保存部（１５）は、アプリ競合ルールを保存する。アプリケーション実行部は、アプリ競合ルールに基づいて、複数のアプリケショーン間の競合を判定し、当該判定結果に基づいて、１つ以上のアプリケーションを実行する。アプリ競合ルール更新部は、競合解決装置のリソースが変化した場合に、複数のアプリケーション間の競合条件の変化に合わせて、アプリ競合ルールを更新する。

Description

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

Claims (11)

  1. 複数のアプリケーション間の競合を解決する競合解決装置であって、
    前記複数のアプリケーション間の競合条件が規定されたアプリ競合ルールを保存するアプリ競合ルール保存部と、
    前記アプリ競合ルールに基づいて、前記複数のアプリケショーン間の競合を判定し、当該判定結果に基づいて、１つ以上のアプリケーションを実行するアプリケーション実行部と、
    前記競合解決装置のリソースが変化した場合に、前記複数のアプリケーション間の競合条件の変化に合わせて、前記アプリ競合ルールを更新するアプリ競合ルール更新部とを備えることを特徴とする、競合解決装置。
  2. 前記アプリケーション実行部は、
    １つ以上のアプリケーションを実行する実行部と、
    前記アプリ競合ルールに基づいて、前記複数のアプリケショーン間の競合を判定する競合判定部と、
    前記競合判定部の判定結果に従って、前記実行部でのアプリケーションの実行を管理するアプリ管理部とを含むことを特徴とする、請求項１に記載の競合解決装置。
  3. 前記アプリ競合ルール更新部は、
    前記競合解決装置が備えるデバイスの状態変化を検知するシステム管理部と、
    前記デバイスの状態が変化した場合に、前記デバイスの状態が変化した後の競合解決装置のリソースを取得し、当該取得したリソースに基づいて、前記競合条件が変更されるのか否かを判断するデバイス−競合ルール管理部と、
    前記競合条件が変更されると判断した場合に、前記複数のアプリケーション間の競合条件の変化に合わせて、前記アプリ競合ルールを更新する競合情報更新部とを備える、請求項１に記載の競合解決装置。
  4. 前記デバイス−競合ルール管理部は、
    前記デバイスの状態が変化した場合に、前記複数のアプリケーションの動作に必要なリソースを取得し、
    当該取得した複数のアプリケーションの動作に必要なリソースと、前記デバイスの状態が変化した後の競合解決装置のリソースとに基づいて、前記競合条件が変更されるのか否かを判断することを特徴とする、請求項３に記載の競合解決装置。
  5. 前記アプリ競合ルール更新部は、前記デバイスのリソース種別と、前記アプリケーションとの間の共有・排他条件を示すリソース共有・排他条件を保存するリソース共有・排他条件部をさらに備え、
    前記デバイス−競合ルール管理部は、さらに、前記リソース共有・排他条件に基づいて、前記競合条件が変更さるのか否かを判断する、請求項３に記載の競合解決装置。
  6. 前記システム管理部は、前記競合解決装置が備えるデバイスが追加、交換、あるいは削除されることによる前記デバイスの状態変化を検知することを特徴とする、請求項３に記載の競合解決装置。
  7. 前記デバイスのリソース種別は、メモリであり、
    前記デバイス−競合ルール管理部は、前記デバイスの状態が変化した後の前記競合解決装置のメモリ容量と、前記複数のアプリケーションの動作に必要なメモリ容量とに基づいて、前記競合条件が変更されるのか否かを判断する、請求項３に記載の競合解決装置。
  8. 前記デバイスのリソース種別は、音源ボードであり、
    前記デバイス−競合ルール管理部は、前記デバイスの状態が変化した後の前記競合解決装置の音再生能力と、前記複数のアプリケーションの動作に必要な音再生能力とに基づいて、前記競合条件が変更されるのか否かを判断する、請求項３に記載の競合解決装置。
  9. 複数のアプリケーション間の競合を解決する情報機器が実行する競合解決方法であって、
    前記情報機器には、前記複数のアプリケーション間の競合条件を規定したアプリ競合ルールが保存されており、
    前記情報機器が備えるデバイスの状態変化を検知し、
    前記デバイスの状態が変化した場合に、前記デバイスの状態が変化した後の前記情報機器のリソースを取得し、
    取得した前記情報機器のリソースに基づいて、前記複数のアプリケーション間の競合条件が変更されるのか否かを判断し、
    前記競合条件が変更されると判断した場合に、前記アプリ競合ルールを更新することを特徴とする、競合解決方法。
  10. 複数のアプリケーション間の競合を解決する情報機器が実行するプログラムであって、
    前記情報機器には、前記複数のアプリケーション間の競合条件を規定したアプリ競合ルールが保存されており、
    前記情報機器が備えるデバイスの状態変化を検知し、
    前記デバイスの状態が変化した場合に、前記デバイスの状態が変化した後の前記情報機器のリソースを取得し、
    取得した前記情報機器のリソースに基づいて、前記複数のアプリケーション間の競合条件が変更されるのか否かを判断し、
    前記競合条件が変更されると判断した場合に、前記アプリ競合ルールを更新することを特徴とする、プログラム。
  11. 複数のアプリケーション間の競合を解決する情報機器が備える集積回路であって、
    前記情報機器には、前記複数のアプリケーション間の競合条件を規定したアプリ競合ルールが保存されており、
    前記集積回路は、
    前記情報機器が備えるデバイスの状態変化を検知し、
    前記デバイスの状態が変化した場合に、前記デバイスの状態が変化した後の前記情報機器のリソースを取得し、
    取得した前記情報機器のリソースに基づいて、前記複数のアプリケーション間の競合条件が変更されるのか否かを判断し、
    前記競合条件が変更されると判断した場合に、前記アプリ競合ルールを更新することを特徴とする、集積回路。
JP2007530915A 2005-08-18 2006-05-18 競合解決装置 Expired - Fee Related JP4960237B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2007530915A JP4960237B2 (ja) 2005-08-18 2006-05-18 競合解決装置

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
JP2005237153 2005-08-18
JP2005237153 2005-08-18
JP2007530915A JP4960237B2 (ja) 2005-08-18 2006-05-18 競合解決装置
PCT/JP2006/309913 WO2007020735A1 (ja) 2005-08-18 2006-05-18 競合解決装置

Publications (2)

Publication Number Publication Date
JPWO2007020735A1 true JPWO2007020735A1 (ja) 2009-02-19
JP4960237B2 JP4960237B2 (ja) 2012-06-27

Family

ID=37757404

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2007530915A Expired - Fee Related JP4960237B2 (ja) 2005-08-18 2006-05-18 競合解決装置

Country Status (4)

Country Link
US (1) US8448187B2 (ja)
JP (1) JP4960237B2 (ja)
CN (1) CN101233493B (ja)
WO (1) WO2007020735A1 (ja)

Families Citing this family (31)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080168167A1 (en) * 2007-01-04 2008-07-10 Calrson Michael P Service provided by a single entity for all applications
US9003394B2 (en) 2007-07-10 2015-04-07 Ricoh Company, Ltd. Program determining apparatus and program determining method
US8266635B2 (en) * 2007-12-20 2012-09-11 Access Co., Ltd. Browser-based user interface and control architecture with priority attributes
US8024732B2 (en) 2008-07-28 2011-09-20 Microsoft Corporation State separation for application changes
JP2010033386A (ja) * 2008-07-29 2010-02-12 Kyocera Corp 携帯端末、およびアプリケーション機能起動方法
JP5184268B2 (ja) * 2008-09-08 2013-04-17 株式会社エヌ・ティ・ティ・ドコモ 情報処理装置及びプログラム
JP5561849B2 (ja) * 2009-08-11 2014-07-30 東京エレクトロン株式会社 検査装置の操作方法及び検査装置の操作プログラム
KR101612780B1 (ko) * 2009-11-13 2016-04-18 삼성전자주식회사 컴퓨팅 시스템 및 컴퓨팅 시스템의 메모리 관리 방법
US9164802B2 (en) * 2011-05-24 2015-10-20 International Business Machines Corporation System, method and program product for allocating resources and services
JP5817324B2 (ja) * 2011-08-18 2015-11-18 富士通株式会社 補正装置、補正方法、および補正プログラム
US9032385B2 (en) 2011-12-28 2015-05-12 Lg Electronics Inc. Mobile terminal and control method thereof
JP5798973B2 (ja) * 2012-04-11 2015-10-21 株式会社リコー 処理状態が遷移する複数のプログラムを実行する装置及び方法
US9525587B2 (en) 2012-05-17 2016-12-20 International Business Machines Corporation Updating web resources
US20140222670A1 (en) * 2013-02-01 2014-08-07 Barclays Bank Plc Contactless payment application management
WO2014185837A1 (en) * 2013-05-14 2014-11-20 Telefonaktiebolaget L M Ericsson (Publ) Conflicting data storage requirements
US9870298B2 (en) 2013-08-26 2018-01-16 Google Llc Application resource utilization management
US9830142B2 (en) 2013-09-13 2017-11-28 Microsoft Technology Licensing, Llc Automatic installation of selected updates in multiple environments
US9626176B2 (en) 2013-09-13 2017-04-18 Microsoft Technology Licensing, Llc Update installer with technical impact analysis
US10026064B2 (en) 2013-09-13 2018-07-17 Microsoft Technology Licensing, Llc Automatically recommending updates based on stored lifecycle information
US9665359B2 (en) * 2013-09-13 2017-05-30 Microsoft Technology Licensing, Llc Automatically resolving conflicts after installation of selected updates in a computer system
CN104516704B (zh) * 2013-10-08 2019-12-13 中兴通讯股份有限公司 一种多屏系统中应用激活控制方法、装置及移动终端
CN104850373A (zh) * 2014-02-18 2015-08-19 中兴通讯股份有限公司 一种分屏处理方法和装置
JP6604925B2 (ja) * 2016-09-23 2019-11-13 日立建機株式会社 安全運転支援装置
CN107065639A (zh) * 2016-12-13 2017-08-18 北京光年无限科技有限公司 基于智能机器人的外设行为冲突控制方法和系统
JP7048638B2 (ja) * 2017-11-16 2022-04-05 株式会社日立産機システム コントロール装置
US10705817B2 (en) * 2018-03-19 2020-07-07 Toyota Jidosha Kabushiki Kaisha Conflict determination and mitigation for vehicular applications
US20210240524A1 (en) * 2020-01-31 2021-08-05 Qualcomm Incorporated Methods and apparatus to facilitate tile-based gpu machine learning acceleration
CN113064666B (zh) * 2021-03-18 2022-03-29 北京大学 物联网设备调度冲突检测方法及系统
US11563790B1 (en) * 2022-01-31 2023-01-24 Zoom Video Communications, Inc. Motion-based frame rate adjustment for in-person conference participants
US11979441B2 (en) 2022-01-31 2024-05-07 Zoom Video Communications, Inc. Concurrent region of interest-based video stream capture at normalized resolutions
US11546394B1 (en) * 2022-01-31 2023-01-03 Zoom Video Communications, Inc. Region of interest-based resolution normalization

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3417984B2 (ja) * 1993-09-10 2003-06-16 株式会社日立製作所 キャッシュ競合削減コンパイル方法
JP4058752B2 (ja) 2001-12-11 2008-03-12 日本電気株式会社 携帯情報端末装置
JP2004078936A (ja) * 2002-07-31 2004-03-11 Matsushita Electric Ind Co Ltd 情報処理端末及び情報処理方法
KR20040012540A (ko) 2002-07-31 2004-02-11 마쯔시다덴기산교 가부시키가이샤 정보처리단말 및 정보처리방법
JP4277952B2 (ja) * 2002-11-15 2009-06-10 パナソニック株式会社 競合調停装置、競合調停方法および競合調停プログラム
EP1422622A3 (en) 2002-11-15 2007-07-11 Matsushita Electric Industrial Co., Ltd. Apparatus, method and program for contention arbitration
JP2005004350A (ja) 2003-06-10 2005-01-06 Sony Ericsson Mobilecommunications Japan Inc リソース管理方法及び装置、リソース管理プログラム、記憶媒体
JP4731822B2 (ja) * 2004-03-30 2011-07-27 京セラ株式会社 携帯電話端末装置及びプログラム管理方法並びにそのコンピュータプログラム
CN1677352A (zh) 2004-03-30 2005-10-05 京瓷株式会社 移动电话终端、及其程序管理方法和相应的计算机程序

Also Published As

Publication number Publication date
US20090144756A1 (en) 2009-06-04
CN101233493A (zh) 2008-07-30
CN101233493B (zh) 2012-01-18
US8448187B2 (en) 2013-05-21
JP4960237B2 (ja) 2012-06-27
WO2007020735A1 (ja) 2007-02-22

Similar Documents

Publication Publication Date Title
JP4960237B2 (ja) 競合解決装置
JP6277455B2 (ja) モバイルデバイスにサービスブランドパッケージを格納するシステムおよび方法
US9204239B1 (en) Segmented customization package within distributed server architecture
WO2006011343A1 (ja) 競合解決装置
US8909291B1 (en) Dynamic remotely managed SIM profile
US8677329B2 (en) Methods and apparatuses for a compiler server
US20140289414A1 (en) Api for resource discovery and utilization
RU2486579C2 (ru) Устройство терминала, имеющее основанную на виртуальной машине (vm) структуру уровней для выполнения разнородных приложений
US7693969B2 (en) Program distributing apparatus and program distributing system
JP2007026094A (ja) 実行装置およびアプリケーションプログラム
WO2023185166A1 (zh) 服务调用方法、装置、设备及存储介质
US11789718B2 (en) System and method for subscription based solution modification implementation
US11588909B1 (en) System and method for subscription based solution data compatibility
US20230222471A1 (en) System and method for subscription based solution implementation
CN108090361B (zh) 安全策略更新方法及装置
JP2008546108A (ja) 異なるモードを有するプロセッサ制御装置
US20230062039A1 (en) Information processing device and file recording method
KR100974662B1 (ko) 이동 통신 단말기 및 이의 펌웨어 업데이트 방법
KR101771573B1 (ko) 단말 장치 간 자원 접근 제어 방법 및 이를 위한 서비스 시스템
US10631177B1 (en) Mobile phone chipset parameter adaptation framework
US11922158B2 (en) Unified local patch repository
JP2007122555A (ja) 情報処理装置
JP2005092708A (ja) ソフトウェア更新システム及びソフトウェア更新方法並びにコンピュータプログラム
JP2008234116A (ja) 仮想計算機制御装置
JP4666231B2 (ja) アプリケーション競合管理システム及びその方法並びにそれを用いた情報処理端末

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20081127

RD02 Notification of acceptance of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7422

Effective date: 20110826

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20111222

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20120201

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20120301

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20120322

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20150330

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

S111 Request for change of ownership or part of ownership

Free format text: JAPANESE INTERMEDIATE CODE: R313113

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

LAPS Cancellation because of no payment of annual fees