JP4277952B2 - 競合調停装置、競合調停方法および競合調停プログラム - Google Patents

Description

本発明は、複数のアプリケーションが起動するコンピュータシステム内において使用される装置および方法に関し、より特定的には、複数のアプリケーションがアクセス対象に同時にアクセスする時に生じる競合の調停を行うための装置および方法に関する。

一般に、一つのコンピュータシステムで実行される一つのアプリケーションは、スピーカやＭＩＤＩ（Ｍｕｓｉｃａｌ Ｉｎｓｔｒｕｍｅｎｔｓ Ｄｉｇｉｔａｌ Ｉｎｔｅｒｆａｃｅ）物理デバイス、ＳＤＳＰ（Ｓｏｕｎｄ Ｄｉｇｉｔａｌ Ｓｉｇｎａｌ Ｐｒｏｃｅｓｓｏｒ）物理デバイス等の複数の物理デバイスの動作を制御することによって、コンピュータシステム全体の動作を制御し、所望の処理を行っている。しかし、複数のアプリケーションが起動するコンピュータシステム内において、二つ以上のアプリケーションが同時に一つの物理デバイスにアクセスしようとした場合、アクセス要求が衝突してしまうこととなる。アクセス要求が衝突した場合、物理デバイスは、所望通りに動作しない。

以下、このように、二つ以上のアプリケーションが同時に一つの物理デバイスにアクセスしようとする状態のことを競合ということにする。競合が発生すると、アプリケーションは、所望通りにコンピュータシステムの動作を制御することができない。したがって、複数のアプリケーションが起動するコンピュータシステム内では、競合が発生しないように、各アプリケーションから物理デバイスへのアクセス要求を制御する必要がある。以下、このように、各アプリケーションから物理デバイスへのアクセス要求を制御することを競合調停ということにする。従来、競合調停のための方法は、様々提案されてきた。

たとえば、競合調停のための方法として、排他制御識別子を用いる方法が提案されている（たとえば、特許文献１参照）。この方法では、排他制御識別子が、アプリケーションを実行する計算機に予め配布されている。あるアプリケーションが共有の物理デバイスにアクセスする場合、当該アプリケーションを実行する計算機は、他の計算機に配布されている排他制御識別子を集める。そして、全ての排他制御識別子を集めた計算機は、排他制御権を獲得し、共有の物理デバイスにアクセスすることができる。

また、一つのコンピュータシステム内において、同時に複数のスレッドが記憶データ・オブジェクトにアクセス要求する際に生じるアクセス競合を調停するための方法が提案されている（たとえば、特許文献２参照）。この方法では、先勝ち処理することによってアクセス競合を調停する。

また、一つのコンピュータシステム内において、競合調停を行う専用の制御デバイスを設けることによって、競合調停を行う方法が提案されている（たとえば、特許文献３参照）。この方法では、制御デバイスが、アクセス要求に付与されている優先度に基づいて、競合調停を行う。

また、一つの制御対象機器に対して、複数の制御命令が与えられたとき、当該制御対象機器は、所定の条件に基づいて、いずれか一つの制御命令を選択することによって、競合調停する方法も提案されている（たとえば、特許文献４参照）。
特開２００２−１７５２８７号公報 特開平１０−１８７５２７号公報 特開２０００−２３１４５８号公報 特開２００１−３４６２７６号公報

しかし、従来の競合調停方法では、一つのコンピュータシステム内で競合調停を行う場合、実際に存在する物理デバイスの単位でのみ競合調停を行っていた。そのため、実際には一つの物理デバイスであるが、ある条件の下では、複数のアプリケーションからの同時アクセスが可能であるような物理デバイスを用いる場合や、所定数までのアプリケーションからの同時アクセスを許容するような多重アクセスを許容する物理デバイスを用いる場合、従来の競合調停方法を用いて競合調停を行ったとしたら、物理デバイスの特性を十分に活かすことができなかった。

また、スピーカ物理デバイスのように、他の物理デバイスと配線結合されている物理デバイスであって、それ単体では、Ｉ／Ｏポートを持っていない物理デバイスが複数の物理デバイス間で共有されているような場合、従来の競合調停方法を用いて競合調停を行ったとしたら、各アプリケーションは、状態遷移表を参照しながら、当該物理デバイスに同時にアクセスしないように、自らの判断で競合を回避するしかなかった。そのため、競合調停は、アプリケーション自身の動作や、物理デバイス間の接続構成に依存してしまうこととなっていた。また、物理デバイスの数が増えることによって、各アプリケーションが状態遷移表を更新する必要があり、競合調停が困難なものとなっていた。

このように、従来の競合調停方法は、物理デバイスの特性を十分に活かしきることができず、かつ物理デバイスの構成変化に対応しにくい柔軟性に乏しいものであった。

それゆえ、本発明の目的は、物理デバイスの特性を十分に活かしきることができ、かつ物理デバイスの構成変化に柔軟に対応することができる競合調停装置および競合調停方法を提供することである。

上記課題を解決するために、本発明は、以下のような特徴を有する。本発明は、複数のアプリケーションが同時に少なくとも一つの物理デバイスの使用を所望した場合に発生する競合を調停する競合調停装置であって、物理デバイスには、Ｉ／Ｏポートを持つ第１の物理デバイスと、当該第１の物理デバイスに配線結合されＩ／Ｏポートを持たない第２の物理デバイスとが存在し、各物理デバイスが有する少なくとも一つの機能を機能毎に定義するリソースと、当該リソースの使用が現在許可されているアプリケーションとの対応関係を示すリソース情報を格納するリソース情報記憶手段と、アプリケーションが実行されることで実現される機能を定義する論理デバイスと、当該論理デバイスが定義した機能を実現するために必要なリソースとの対応関係を示すデバイス情報を格納するデバイス情報格納手段と、アプリケーションによって新たに論理デバイスが指定された場合、デバイス情報を参照して、新たに指定された論理デバイスに対応する必要なリソースを認識する使用リソース認識手段と、リソース情報を参照して現在使用が許可されているアプリケーションを認識し、使用リソース認識手段によって認識された必要なリソースのそれぞれについて、使用が許可されるアプリケーションを所定の基準に基づいて判定するリソースアクセス判定手段と、アプリケーションが指定した論理デバイスが定義する機能を実現するために必要なリソースの全てを使用可能か否かを、リソースアクセス判定手段による判定結果に基づいて判定することによって、当該アプリケーションが当該論理デバイスにアクセス可能か否かを判定するデバイスアクセス判定手段とを備える。

好ましくは、デバイスアクセス判定手段によって、論理デバイスを新たに指定したアプリケーションが必要なリソースの全てを使用可能と判定されたことによって当該アプリケーションがこ当該論理デバイスにアクセス可能と判定された場合、当該必要なリソースの全てにそれぞれ対応する物理デバイスを制御するためのデバイスドライバを実行させる実行手段をさらに備えるとよい。

好ましくは、デバイスアクセス判定手段による判定結果を、判定対象のアプリケーションと対応させてアプリケーション情報として格納するアプリケーション情報記憶手段と、デバイスアクセス判定手段による判定結果に基づいてアプリケーション情報を更新し、当該判定結果がアクセス可能である場合、必要なリソースの全てにそれぞれ対応する物理デバイスを制御するためのデバイスドライバを実行させる実行手段とをさらに備え、使用リソース認識手段は、論理デバイスにアクセスしているアプリケーションから当該論理デバイスへのアクセス終了要求を受け取った場合、アクセスを終了する論理デバイスに対応するリソースを認識し、リソースアクセス判定手段は、アプリケーション情報を参照して、アクセスを終了する論理デバイスに対応するリソースの使用が競合により許可されていない他のアプリケーションの有無を判定し、当該他のアプリケーションが有る場合、当該他のアプリケーションに競合を理由に使用許可されていないリソースの使用許可を与え、当該許可の結果を反映してリソース情報を更新し、デバイスアクセス判定手段は、リソースアクセス判定手段により更新されたリソース情報に基づいて、他のアプリケーションが指定する論理デバイスが定義する機能を実現するために必要なリソースの全てを当該他のアプリケーションが使用できるか否かを判定することによって、当該他のアプリケーションが当該論理デバイスにアクセス可能か否かを判定し、実行手段は、デバイスアクセス判定手段によって他のアプリケーションが論理デバイスにアクセス可能と判定された場合、当該他のアプリケーションが必要なリソースの全てにそれぞれ対応する物理デバイスにアクセスできるように、当該物理デバイスを制御するデバイスドライバの設定を変更するとよい。

また、本発明は、複数のアプリケーションが同時に少なくとも一つの物理デバイスの使用を所望した場合に発生する競合を調停するようにコンピュータ装置を機能させるためのプログラムであって、物理デバイスには、Ｉ／Ｏポートを持つ第１の物理デバイスと、当該第１の物理デバイスに配線結合されＩ／Ｏポートを持たない第２の物理デバイスとが存在し、コンピュータ装置には、各物理デバイスが有する少なくとも一つの機能を機能毎に定義するリソースと当該リソースの使用が現在許可されているアプリケーションとの対応関係を示すリソース情報と、アプリケーションが実行されることで実現される機能を定義する論理デバイスと当該論理デバイスが定義した機能を実現するために必要なリソースとの対応関係を示すデバイス情報とが記憶されており、アプリケーションによって新たに論理デバイスが指定された場合、デバイス情報を参照して、新たに指定された論理デバイスに対応する必要なリソースをコンピュータ装置に認識させるステップと、リソース情報を参照して現在使用が許可されているアプリケーションをコンピュータ装置に認識させ、新たに指定された論理デバイスに対応する必要なリソースのそれぞれについて、使用が許可されるアプリケーションを所定の基準に基づいてコンピュータ装置に判定させるステップと、アプリケーションが指定した論理デバイスが定義する機能を実現するために必要なリソースの全てを使用可能か否かを、使用が許可されるアプリケーションの判定結果に基づいて判定させることによって、当該アプリケーションが当該論理デバイスにアクセス可能か否かをコンピュータ装置に判定させるステップとを備える。

また、本発明は、コンピュータ装置によって、複数のアプリケーションが同時に少なくとも一つの物理デバイスの使用を所望した場合に発生する競合を調停するための方法であって、物理デバイスには、Ｉ／Ｏポートを持つ第１の物理デバイスと、当該第１の物理デバイスに配線結合されＩ／Ｏポートを持たない第２の物理デバイスとが存在し、コンピュータ装置には、各物理デバイスが有する少なくとも一つの機能を機能毎に定義するリソースと当該リソースの使用が現在許可されているアプリケーションとの対応関係を示すリソース情報と、アプリケーションが実行されることで実現される機能を定義する論理デバイスと当該論理デバイスが定義した機能を実現するために必要なリソースとの対応関係を示すデバイス情報とが記憶されており、アプリケーションによって新たに論理デバイスが指定された場合、デバイス情報を参照して、新たに指定された論理デバイスに対応する必要なリソースをコンピュータ装置が認識するステップと、リソース情報を参照して現在使用が許可されているアプリケーションをコンピュータ装置が認識し、新たに指定された論理デバイスに対応する必要なリソースのそれぞれについて、使用が許可されるアプリケーションを所定の基準に基づいてコンピュータ装置が判定するステップと、アプリケーションが指定した論理デバイスが定義する機能を実現するために必要なリソースの全てを使用可能か否かを、使用が許可されるアプリケーションの判定結果に基づいて判定することによって、当該アプリケーションが当該論理デバイスにアクセス可能か否かをコンピュータ装置が判定するステップとを備える。

本発明によれば、競合調停装置は、アプリケーションによって指定される論理デバイスと、実際に存在する物理デバイスと、物理デバイスと論理デバイスとを対応付けるリソースとに分離して、物理デバイスの機能およびアプリケーション所望する機能を管理し、リソース単位でアプリケーションから物理デバイスへのアクセスの競合調停を行う。したがって、物理デバイスの構成が変化したとしても、競合調停装置内のリソース情報およびデバイス情報を変更するだけでよいので、物理デバイスの構成変化に柔軟に対応することができる競合調停装置および競合調停方法を提供することができる。さらに、物理デバイスの機能をリソース単位に分割して競合調停を行うので、物理デバイスが様々な特性を有していたとしても、その特性を十分に活かしきることができる競合調停装置および競合調停方法を提供することができる。

また、ある上限数以内であれば多重アクセスを許すような場合や、ある条件を満たせば多重アクセスを許すような場合において、競合調停装置は、複数のアプリケーションにアクセス権を付与することができる。このように、競合調停装置は、物理デバイスの特性を十分に活かしきるように競合調停を行うことができる。

また、他の物理デバイスとは配線結合されているものの、単体ではＩ／Ｏポートを持たない物理デバイスが複数のデバイス間で共有されるような場合でも、競合調停装置は、当該物理デバイスへのアクセスの競合調停を行うことができる。

図１は、本発明の一実施形態に係る競合調停装置が適用されるコンピュータシステムの全体構成を示すブロック図である。図１において、コンピュータシステムは、競合調停装置１と、アプリケーション実行装置２と、複数の物理デバイス３と、デバイスドライバ実行装置４とを備える。なお、図１では、アプリケーション実行装置２およびデバイスドライバ実行装置４は、それぞれ一つずつだけ示すこととしたが、複数あってもよい。また、物理デバイス３の数および接続関係は、図１のものに限定されるものではない。

図１におけるコンピュータシステムは、携帯電話等の携帯通信端末や、ＰＤＡ等の携帯端末、パソコン等の通信端末、複数の通信端末を接続しているＬＡＮシステム、複数のデジタル家電を接続している家庭内ＬＡＮシステムなど、コンピュータ装置を使用するあらゆるシステムが想定される。

アプリケーション実行装置２は、アプリケーションを実行するためのコンピュータ装置であって、少なくとも、中央処理装置（以下、ＣＰＵという）および記憶装置を含む。アプリケーション実行装置２は、プログラムをメモリに読み込んで、ＣＰＵで実行することによって、アプリケーションを実行する。アプリケーション実行装置２は、マルチタスク機能によって、複数のアプリケーションを同時に実行することができる。

物理デバイス３は、入力装置や出力装置、補助記憶装置、通信装置等のハードウエアである。入力装置としての物理デバイス３は、たとえば、ボタンスイッチやジョグダイヤル、キーボード、マウス、ジョイスティック、マイクロホン等である。出力装置としての物理デバイス３は、たとえば、スピーカや液晶ディスプレイ、ブラウン管、プリンタ、ＳＤＳＰ装置、ＭＩＤＩ装置等である。なお、ＳＤＳＰ装置は、アプリケーションが有するデジタルデータを復号して、アナログ音声として出力するための装置である。補助記憶装置としての物理デバイス３は、ハードディスク装置や光ディスク装置、ＣＤ−ＲＯＭドライブ装置、ＤＶＤドライブ装置等である。通信装置としての論理デバイス３は、モデムやＤＳＵ、ＬＡＮカード等である。

デバイスドライバ実行装置４は、物理デバイス３の動作を制御するためのソフトウエア（以下、デバイスドライバという）を実行するためのコンピュータ装置であって、少なくとも、ＣＰＵおよび記憶装置を含む。

競合調停装置１は、アプリケーション実行装置２が実行するアプリケーションが物理デバイス３へアクセスする際の競合を調停する装置であって、少なくとも、ＣＰＵおよび記憶装置を含む。競合調停装置１は、アプリケーションから物理デバイス３の使用を開始したい旨の要求があった場合、競合調停を行う。そして、競合調停装置１は、当該アプリケーションが当該物理デバイス３を使用できるように、デバイスドライバ実行装置４にデバイスドライバを実行させる。これによって、アプリケーションは、所望の物理デバイス３を使用することができる。

なお、上記では、説明を分かりやすくするために、競合調停装置１、アプリケーション実行装置２およびデバイスドライバ実行装置４は、それぞれ別々に構成されていることとしたが、共通のＣＰＵおよび／または記憶装置を用い、マルチタスク処理によって、それぞれをソフトウエア的に構成するようにしてもよい。また、競合調停装置１、アプリケーション実行装置２およびデバイスドライバ実行装置４は、それぞれ、専用のＬＳＩを用いてハードウエア的に実現しても、専用のプログラムを汎用のＣＰＵで実行することによってソフトウエア的に実現してもよい。

本実施形態において、物理デバイス３の機能は、物理デバイス側とアプリケーション側との両方の視点から定義されている。

まず、物理デバイス側の視点から定義される物理デバイス３の機能について説明する。各物理デバイス３は、それぞれ特有の機能を有している。本実施形態において、競合調停装置１は、物理デバイスによって提供される機能を構造体によって定義している。本実施形態では、この構造体のことをリソースと呼ぶ。物理デバイスは少なくとも一つ以上の機能を提供しているので、一つの物理デバイスに対して、少なくとも一以上のリソースが対応することとなる。

次に、アプリケーション側の視点から定義される物理デバイス３の機能について説明する。各アプリケーションは、物理デバイス３の動作を制御することによって、所望の機能が実現されることを望む。本実施形態において、競合調停装置１は、アプリケーションによって所望される機能を構造体によって定義している。本実施形態では、この構造体のことを論理デバイスと呼ぶ。アプリケーションが所望する機能は、少なくとも一以上の物理デバイスが動作することによって実現される。物理デバイス３の機能は少なくとも一以上のリソースによって定義されているので、アプリケーションが所望する機能は、一以上のリソースによって提供される。すなわち、論理デバイスには、一以上のリソースが対応することとなる。

本発明の最大の特徴は、論理デバイスおよびリソースという概念を導入し、論理デバイスおよびリソースを用いて、競合調停を行う点にある。

アプリケーションは、物理デバイスに電気的に実際にアクセスして所望の機能を実現したい場合、競合調停装置１に対して、論理デバイスを指定し、競合調停を行ってもらう。競合調停装置１は、アプリケーションが物理デバイスにアクセスできるか否かをリソース単位で管理する。競合調停装置１は、論理デバイスに対応するリソースを認識して、認識したリソースにアプリケーションに対するアクセス権が与えられているか否かを判断する。与えられている場合、競合調停装置１は、当該アプリケーションが物理デバイスにアクセスできるように、デバイスドライバを実行する。

図２〜図４は、アプリケーション、論理デバイス、リソース、および物理デバイスの対応関係の例を示す模式図である。以下、図２〜図４を参照して、本実施形態の概要について説明する。

図２では、物理デバイスとして、ＳＤＳＰ物理デバイス、スピーカ物理デバイス、およびＭＩＤＩ物理デバイスを用いている例を示している。ここでは、ＳＤＳＰ物理デバイスは、多重アクセスを許さない物理デバイスであると想定する。図２において、Ｉ／Ｏポートを持った物理デバイスは、ＳＤＳＰ物理デバイスとＭＩＤＩ物理デバイスとであるとする。スピーカ物理デバイスは、ＳＤＳＰ物理デバイスとＭＩＤＩ物理デバイスとに配線されており、Ｉ／Ｏポートは持っていないとする。

そのため、アプリケーションは、スピーカ物理デバイスのみを制御するということはできない。さらにスピーカ物理デバイスは、ＳＤＳＰ物理デバイスとＭＩＤＩ物理デバイスとで共有されているため、アプリケーションＡ１がＳＤＳＰ物理デバイスにアクセスするとき、アプリケーションＡ２は、ＭＩＤＩ物理デバイスにはアクセスできない。また、逆も起こり得る。

このように、複数のアプリケーションが同時にＳＤＳＰ物理デバイスとＭＩＤＩ物理デバイスとへのアクセスを所望した場合、アプリケーションからは見えないスピーカ物理デバイスに対してアクセス競合が発生する。このアクセス競合を回避するために、従来では、アプリケーション間で調停を行う必要があった。そのため、従来の方法では、アプリケーションやデバイスの種類が増えるに従って、調停が困難になる。しかし、本発明では、物理デバイスが提供する機能をリソースによって定義し、リソース単位で競合調停を行うので、アプリケーション間における調停が不要となり、アプリケーションやデバイスの種類が増えても、調停が容易である。

図２において、ＳＤＳＰ物理デバイスに対応するリソースは、ＳＤＳＰリソースである。スピーカ物理デバイスに対応するリソースは、スピーカリソースである。ＭＩＤＩに対応するリソースは、ＭＩＤＩリソースである。ＳＤＳＰ機能を定義するＳＤＳＰ論理デバイスは、ＳＤＳＰリソースとスピーカリソースとを必要とする。ＭＩＤＩ機能を定義するＭＩＤＩ論理デバイスは、ＭＩＤＩリソースとスピーカリソースとを必要とする。

アプリケーションが論理デバイスにアクセス可能となるための条件は、論理デバイスが必要とする全てのリソースに対して、当該アプリケーションにアクセス権が与えられている場合である。本実施形態では、個々のリソースに対するアクセス権は、アプリケーションの優先度によって決められる。なお、先勝ちや後勝ちなどによって決めてもよい。

たとえば、図２において、アプリケーションＡ１がＳＤＳＰ論理デバイスへのアクセスを所望し、アプリケーションＡ２がＭＩＤＩ論理デバイスへのアクセスを所望した場合を想定する。ここで、アプリケーションＡ１とアプリケーションＡ２との間では、アプリケーションＡ２の方が優先度が高いとする。この場合、ＳＤＳＰリソースへはアプリケーションＡ１しかアクセスを所望していないので、アプリケーションＡ１がＳＤＳＰリソースのアクセス権を取得する。同様に、ＭＩＤＩリソースへはアプリケーションＡ２しかアクセスを所望していないので、アプリケーションＡ２がＭＩＤＩリソースのアクセス権を取得する。

アプリケーションＡ１とアプリケーションＡ２との両方が所望する論理デバイスが、共にスピーカリソースを必要としているので、競合が発生する。ここでは、アプリケーションＡ２の方が優先度が高いとしているので、アプリケーションＡ２がスピーカリソースのアクセス権を取得できる。そして、アプリケーションＡ２はアクセス対象のＭＩＤＩ論理デバイスが必要とするリソース全てにおいてアクセス権を取得することとなるので、アプリケーションＡ２は、ＭＩＤＩ物理デバイスとスピーカデバイスとへのアクセスが可能となる。また、アプリケーションＡ１はアクセス対象のＳＤＳＰ論理デバイスが必要とするリソースのうち、スピーカリソースについてアクセス権を取得できなかったため、ＳＤＳＰ物理デバイスとスピーカデバイスとへのアクセスが不可能となる。

図３では、物理デバイスとして、回線物理デバイスを用いている例を示している。図３において、物理デバイスは一つしか存在しない。しかし、実際には、多重アクセスを許し、同時に三回線まで使用できるマルチコール対応の回線物理デバイスを用いている。この場合、アプリケーションのアクセス対象である論理デバイスおよび回線物理デバイスは一つしかないが、回線リソースは三つ定義されることとなる。回線論理デバイスは、最低限一つの回線リソースを必要とする。

たとえば、図３において、アプリケーションＡ１、Ａ２、Ａ３、Ａ４がともに回線論理デバイスへのアクセスを所望した場合を想定する。ここで、優先度は、アプリケーションＡ１、アプリケーションＡ２、アプリケーションＡ３、アプリケーションＡ４の順で高いとする。すなわち、アプリケーションＡ１が最も高い優先度を有するとする。

まず、アプリケーションＡ１が回線論理デバイスへのアクセスを所望すると、アプリケーションＡ１は、３つある回線リソースのうち、一つ目の回線リソース３２のアクセス権を取得する。次に、アプリケーションＡ２が回線論理デバイスへのアクセスを所望すると、アプリケーションＡ２は、二つ目の回線リソース３３のアクセス権を取得する。次に、最も優先度の低いアプリケーションＡ４が回線論理デバイスへのアクセスを所望すると、アプリケーションＡ４は三つ目の回線リソース３４のアクセス権を取得する。

このような状況の下、アプリケーションＡ４より優先度の高いアプリケーションＡ３が回線論理デバイスへのアクセスを所望すると、競合調停装置１は、アプリケーションＡ４とアプリケーションＡ３との優先度を比較する。上記の例では、アプリケーションＡ３の方が優先度が高いため、アプリケーションＡ４は、３つ目の回線リソース３４に対してアクセス不可となる。そして、アプリケーションＡ３は、回線リソース３４へのアクセス権を取得する。結果、アプリケーションＡ１、Ａ２、Ａ３が回線論理デバイスにアクセス可能となる。

図４では、物理デバイスとして、ＳＤＳＰ物理デバイスを用いる例を示している。ここでは、ＳＤＳＰ物理デバイスは、多重アクセスを許す物理デバイスであると想定する。なお、図２に示す多重アクセスを許さないＳＤＳＰ物理デバイスと図４で示す多重アクセスを許すＳＤＳＰ物理デバイスは、一つのコンピュータ装置内で共存可能であるとする。図４において、物理デバイスは、一つしか存在しない。当該ＳＤＳＰ物理デバイスでは、録音機能と再生機能とは同時に使用できるとする。この場合、アプリケーションのアクセス対象論理デバイスは、ＳＤＳＰ録音論理デバイスとＳＤＳＰ再生論理デバイスとの二つである。リソースは、コーデック機能を表すＳＤＳＰコーデックリソースと、録音機能を表すＳＤＳＰ録音リソースと、再生機能を表すＳＤＳＰ再生リソースとの三つである。さらにＳＤＳＰコーデックリソースは、コーデックが同じ場合、録音機能と再生機能とを同時に使用できる。そのため、ＳＤＳＰコーデックリソースは、二つ存在すると考えるのではなく、コーデック情報を付加情報として持たせることによって、ただ一つだけ存在すると考え、多重アクセスを許していると考える。

このような状況の下、ＳＤＳＰ物理デバイスへのアクセスを所望しているアプリケーションが複数存在する場合、競合調停装置１は、優先度が最も高いアプリケーションのコーデックをＳＤＳＰコーデックリソースに設定する。優先度が低いアプリケーションのコーデックと設定されているコーデックとが同じであれば、競合調停装置１は、優先度が低いアプリケーションにもＳＤＳＰコーデックリソースへのアクセス権を付与する。

たとえば、図４においてアプリケーションＡ１およびＡ２がＳＤＳＰ録音論理デバイスへのアクセスを所望し、アプリケーションＡ３がＳＤＳＰ再生論理デバイスへのアクセスを所望していると想定する。優先度は、アプリケーションＡ１、アプリケーションＡ２、アプリケーションＡ３の順に高いものとする。すなわち、アプリケーションＡ１が最も高い優先度を有する。また、アプリケーションＡ１、Ａ２、Ａ３は、共に、同じコーデックＸでアクセスを所望しているとする。

まず、アプリケーションＡ１がＳＤＳＰ録音論理デバイスへのアクセスを所望すると、アプリケーションＡ１は、ＳＤＳＰコーデックリソースのアクセス権を取得し、ＳＤＳＰコーデックリソース内のコーデックをＸに設定する。また、アプリケーションＡ１は、ＳＤＳＰ録音リソースに対してもアクセス権を取得する。次に、アプリケーションＡ２がＳＤＳＰ録音論理デバイスへのアクセスを所望すると、アプリケーションＡ２は、優先度の高いＡ１と同じコーデックを有するためＳＤＳＰコーデックリソースに対するアクセス権を取得できるが、ＳＤＳＰ録音リソースに対してはＡ１と競合するためアクセス権を取得できない。

次に、アプリケーションＡ３がＳＤＳＰ再生論理デバイスへのアクセスを所望するとする。アプリケーションＡ３は、優先度の高いＡ１と同じコーデックを有するためＳＤＳＰコーデックリソースに対するアクセス権を取得できる。さらに、アプリケーションＡ３は、ＳＤＳＰ再生リソースに対しては、競合が発生していないのでアクセス権を取得できる。

結果、アプリケーションＡ１、Ａ３は、共に、アクセス対象論理デバイスが必要とする全てのリソースに対してアクセス可能であることとなる。そのため、それぞれ、アプリケーションＡ１、Ａ３は、ＳＤＳＰ録音論理デバイスおよびＳＤＳＰ再生論理デバイスにアクセス可能となる。一方、アプリケーションＡ２は、ＳＤＳＰ録音リソースのアクセス権が取得できないため、ＳＤＳＰ録音論理デバイスにアクセス不可能である。

図５は、競合調停装置１の機能的構成を示すブロック図である。図５において、競合調停装置１は、アプリケーションＩＦ部１１と、アプリケーション情報記憶部１２と、使用リソース認識部１３と、リソース情報記憶部１４と、リソースアクセス判定部１５と、デバイスアクセス判定部１６と、実行部１７と、デバイス情報記憶部１８とを含む。図５に示した全ての機能部は、汎用のＣＰＵを備えるコンピュータ装置を機能させるプログラムによってまとめて実現されてもよいし、専用のＬＳＩによってまとめて実現されてもよい。また、各機能部は、それぞれ、汎用のＣＰＵを実行させるプログラムによって実現されてもよいし、専用のＬＳＩによって実現されてもよい。また、複数の機能部の組み合わせが、同様にして実現されてもよい。

アプリケーションＩＦ部１１は、物理デバイス３の使用を開始したい旨のアプリケーションからの要求（以下、アクセス開始要求という）を受信する。アクセス開始要求には、当該アプリケーションのアプリＩＤと、当該アプリケーションが使用したい論理デバイスの名称（以下、アクセス対象論理デバイス名という）と、当該アプリケーションの優先度とが指定されている。優先度は、予めアプリケーション毎に設定されていてもよいし、ＯＳが後発的にアプリケーションに対して設定しても、アプリケーション自身が他のアプリケーションの種別を認識して自ら設定してもよい。

アクセス開始要求を受信したアプリケーションＩＦ部１１は、アプリケーションを識別するためのＩＤ（以下、アプリＩＤという）に対応させて、当該アクセス開始要求で指定されているアクセス対象論理デバイス名と優先度とをアプリケーション情報記憶部１２に格納する。さらに、アクセス開始要求を受信したアプリケーションＩＦ部１１は、使用リソース認識部１３に対して、当該アクセス開始要求で指定されているアクセス対象論理デバイスが使用するリソースを認識させる。

アクセス開始要求があった後、アプリケーションＩＦ部１１は、物理デバイス３にアクセスしたい旨のアプリケーションからの要求（以下、アクセス要求という）を受信する。アクセス要求には、アプリＩＤと、アクセス対象論理デバイス名と、当該アプリケーションの優先度とが指定されている。アクセス要求を受信したアプリケーションＩＦ部１１は、当該アクセス要求の内容を実行部１７に通知して、当該アプリケーションが当該論理デバイスにアクセス可能であるか否かを示す情報を実行部１７から受け取る。アクセス可能であることを示す情報を受け取った場合、アプリケーションＩＦ部１１は、当該アプリケーションに対して、当該アクセス対象論理デバイスにアクセス可能である旨を通知する。一方、アクセス不可能であることを示す情報を実行部１７から受け取った場合、アプリケーションＩＦ部１１は、当該アプリケーションに対して、当該アクセス対象論理デバイスにアクセス不可能である旨を通知する。

アクセス要求があった後、アプリケーションＩＦ部１１は、物理デバイス３へのアクセスを終了したい旨のアプリケーションからの要求（以下、アクセス終了要求という）を受信する。アクセス終了要求を受信したアプリケーションＩＦ部１１は、使用リソース認識部１３に対して、当該アプリケーションが保持しているアクセス権を開放するように指示する。

アプリケーション情報記憶部１２は、アプリケーション情報をアプリケーション毎に格納する。ここで、アプリケーション情報は、対応するアプリケーションの優先度と、対応するアプリケーションのアクセス対象論理デバイス名と、アクセス対象論理デバイスに対応するアプリケーションがアクセス可能であるか否かを示す情報（以下、アクセス可否情報という）とから構成されている。

図６は、アプリケーション情報記憶部１２に格納されているアプリケーション情報の一例を示す図である。図６に示すように、アプリケーション情報記憶部には、アプリＩＤと対応して、優先度と、アクセス対象論理デバイス名と、アクセス可否情報とが格納されている。たとえば、アプリＩＤが「１」のアプリケーションの優先度は「１」であり、アクセス対象論理デバイス名は「ＳＤＳＰ論理デバイス」であり、アクセス可否情報は「可」である。なお、ここでは、アクセス対象論理デバイス名は、識別ＩＤによって表されていてもよい。アクセス可否情報は、フラグによって表されていてもよい。

デバイス情報記憶部１８は、論理デバイスと当該論理デバイスが必要とするリソースとの関係を示すデバイス情報を保持している。図７は、デバイス情報の一例を示す図である。図７に示すように、デバイス情報では、論理デバイス名に対応するリソース名が指定されている。たとえば、ＳＤＳＰ論理デバイスには、ＳＤＳＰリソースと、スピーカリソースとが指定されている。一つの論理デバイスに必要なリソースは、一つであってもよいし、複数であってもよい。

使用リソース認識部１３は、アプリケーションＩＦ部１１からアクセス開始要求が通知されると、デバイス情報記憶部１８に格納されているデバイス情報を参照して、アクセス対象論理デバイスが必要とするリソースを認識する。使用リソース認識部１３は、認識したリソースと、当該アクセス対象論理デバイスの使用を希望しているアプリケーションのアプリＩＤと、当該アクセス対象論理デバイスと、当該アプリケーションの優先度とをリソースアクセス判定部１５およびデバイスアクセス判定部１６に通知する。一つの論理デバイスに必要なリソースが複数である場合、使用リソース認識部１３は、複数のリソース名を同時にリソースアクセス判定部１５に通知してもよいし、一つずつ順番に通知してもよい。

リソース情報記憶部１４は、リソース情報を格納する。ここで、リソース情報とは、リソース毎に、アクセス権を有するアプリケーションを指定しておくための情報のことをいう。図８は、リソース情報の一例を示す図である。図８に示すように、リソース情報には、リソース名と対応して、当該リソースに対するアクセス権を有しているアプリケーションのアプリＩＤが登録されている。たとえば、図８において、ＳＤＳＰリソースに対するアクセス権を有しているアプリケーションのアプリＩＤは、「１」である。また、アクセス権が設定されていないリソースに対しては、「ＮＵＬＬ」が登録されている。リソース情報記憶部１４に格納されているリソース情報は、リソースアクセス判定部１５によって、リソースに対するアクセス権を保持するアプリケーションが変更になったと判断された場合に更新される。

リソースアクセス判定部１５は、使用リソース認識部１３から通知されるリソースに関するリソース情報をリソース情報記憶部１４から読み出して、既にアクセス権を取得しているアプリケーションを判定する。リソースアクセス判定部１５は、既にアクセス権を取得しているアプリケーションが存在する場合、そのアプリケーションとアクセス開始要求をなしているアプリケーションとの内、どちらの優先度が高いかを、アプリケーション情報記憶部１２に格納してあるアプリケーションの優先度に基づいて判定する。リソースアクセス判定部１５は、判定の結果、アクセス権を取得するアプリケーションが変更になった場合、リソース情報記憶部１４におけるリソース情報の内容を更新する。

デバイスアクセス判定部１６は、使用リソース認識部１３が検出したリソースと、リソース情報記憶部１４に格納されているリソース情報とに基づいて、アクセス開始要求をなしているアプリケーションが、アクセス対象論理デイバスによって使用される全てのリソースに対して、アクセス権を取得しているか否かを判定し、その情報を実行部１７に通知する。デバイスアクセス判定部１６は、全てのリソースに対してアクセス権を取得している場合、当該アプリケーションによる当該論理デバイスへのアクセスが可能であると決定する。

実行部１７は、デバイスアクセス判定部１６から論理デバイスへのアクセスが可能であるか否かを示す情報を受け取る。実行部１７は、受け取った情報に基づいて、アプリケーション情報記憶部１２に格納されているアプリケーション情報におけるアクセス可否情報を更新する。また、実行部１７は、アプリケーションＩＦ部１１からアクセス要求が通知されると、アプリケーション情報記憶部１２を参照して、当該アプリケーションがアクセス対象としている論理デバイスにアクセス可能であるか否かを判断する。アクセス可能である場合、実行部１７は、当該論理デバイスに対応するデバイスドライバをデバイスドライバ実行装置４に実行させ、アクセス可能である旨を示す情報をアプリケーションＩＦ部１１に送る。一方、アクセス不可能である場合、実行部１７は、アプリケーションＩＦ部１１にアクセス不可能である旨を示す情報を送る。

次に、競合調停装置１の動作を詳細に説明する。まず、競合調停装置１を備えるコンピュータシステムにおいて、アプリケーションは、物理デバイス３を使用したい場合、アクセス開始要求を競合調停装置１に通知する。実際に物理デバイス３を使用したい場合、アプリケーションは、アクセス要求を競合調停装置１に通知する。最後に、物理デバイス３へのアクセスを終了したい場合、アプリケーションは、アクセス終了要求を競合調停装置１に通知する。

図９は、アプリケーションからアクセス開始要求があったときの競合調停装置１の動作を示すフローチャートである。以下、図９を参照しながら、アプリケーションからアクセス開始要求があったときの競合調停装置１の動作について説明する。

まず、アプリケーションＩＦ部１１は、アプリケーションからのアクセス開始要求を受信する（ステップＳ１０１）。以下、アクセス開始要求をなしたアプリケーションをアプリケーションＡＰ１という。また、当該アクセス開始要求におけるアクセス対象論理デバイスを論理デバイスＤＥＶ１という。上述のように、当該アクセス開始要求には、アプリケーションの優先度も指定されている。

次に、アプリケーションＩＦ部１１は、受信したアクセス開始要求に基づいて、アプリケーションＡＰ１のアプリケーション情報をアプリケーション情報記憶部１２に登録する。また、アプリケーションＩＦ部１１は、アクセス開始要求で指定されているアプリＩＤ、アクセス対象論理デバイス名および優先度を使用リソース認識部１３に与えて、アクセス開始要求があった旨を通知する（ステップＳ１０２）。なお、この段階では、アプリケーション情報記憶部１２におけるアプリケーションＡＰ１に対応するアクセス可否情報は空白である。

次に、使用リソース認識部１３は、デバイス情報記憶部１８に格納されているデバイス情報を参照して、アプリケーションＩＦ部１１から通知されてきたアクセス対象論理デバイスＤＥＶ１が使用するリソース名を取得し、リソースアクセス判定部１５およびデバイスアクセス判定部１６に通知する（ステップＳ１０３）。このとき、アクセス対象論理デバイスＤＥＶ１が使用するリソースが複数ある場合、使用リソース認識部１３は、全てのリソース名をリソースアクセス判定部１５およびデバイスアクセス判定部１６に通知する。

次に、リソースアクセス判定部１５は、リソース情報記憶部１４およびアプリケーション情報記憶部１２を参照して、使用リソース認識部１３から通知されてきた全てのリソースに対して、アクセス開始要求をなした当該アプリケーションが、アクセス権を取得できるか否かを判断し、当該判断結果をリソース情報記憶部１４およびアプリケーション情報記憶部１２に反映させる（ステップＳ１０４）。ステップＳ１０４における処理は、後で詳述する。

次に、デバイスアクセス判定部１６は、リソース情報記憶部１４に格納されているリソース情報を参照して、アプリケーションＡＰ１がアクセス対象論理デバイスＤＥＶ１に必要な全てのリソースに関するアクセス権を有しているか否かを判断する（ステップＳ１０５）。

全てのリソースに関するアクセス権を有している場合、デバイスアクセス判定部１６は、実行部１７にその旨を通知する。これに応じて、実行部１７は、アプリケーションＡＰ１に対するアクセス可否情報が「可」となるようにアプリケーション情報記憶部１２の登録内容を更新する（ステップＳ１０６）。次に、実行部１７は、アクセス対象論理デバイスＤＥＶ１に関するデバイスドライバをデバイスドライバ実行装置４に実行させて（ステップＳ１０７）、処理を終了する。

一方、全てのリソースに関するアクセス権を有していない場合、デバイスアクセス判定部１６は、実行部１７にその旨を通知する。これに応じて、実行部１７は、アプリケーションＡＰ１に対するアクセス可否情報が「不可」となるようにアプリケーション情報記憶部１２の登録内容を更新し（ステップＳ１０８）、処理を終了する。

図１０は、ステップＳ１０４におけるリソースアクセス判定部１５の動作を詳細に示したフローチャートである。以下、図１０を参照しながら、ステップＳ１０４におけるリソースアクセス判定部１５の動作について説明する。

まず、リソースアクセス判定部１５は、リソース情報記憶部１４を参照して、アクセス対象論理デバイスＤＥＶ１が使用するリソースについて、同一名のリソースが複数存在するか否かを判断する（ステップＳ２０１）。たとえば、図８に示したように、同一名のリソースとして、回線リソースがある。

複数存在する場合、リソースアクセス判定部１５は、同一名のリソースに対して、アクセス権を持つアプリケーションが全て設定されているか否かを判断する（ステップＳ２０２）。全て設定されている場合、リソースアクセス判定部１５は、アプリケーション情報記憶部１２に格納されているアプリケーション情報を参照して、当該リソースにアクセス権が設定されているアプリケーションの内、最も優先度が低いアプリケーションを検索し（ステップＳ２０３）、ステップＳ２０４の動作に進む。ここで、優先度が最も低いアプリケーションをアプリケーションＡＰ２ということにする。全て設定されていない場合、リソースアクセス判定部１５は、ステップＳ２０８の動作に進む。

ステップＳ２０４において、リソースアクセス判定部１５は、当該リソースが多重アクセスを許すリソースであるか否かを判断する。多重アクセスを許すリソースとは、所定の条件を満たすアプリケーションからの同時アクセスを許容するようなリソースのことをいう。多重アクセスを許すリソースであるか否かは、リソース情報に付加されている多重アクセス情報（図８上、図示は省略）によって示されている。

多重アクセスを許さないリソースである場合、リソースアクセス判定部１５は、ステップＳ２０６の動作に進む。一方、多重アクセスを許すリソースである場合、リソースアクセス判定部１５は、当該リソースへアクセスするアプリケーションＡＰ１の属性と既に設定されているリソースの属性とが同一であるか否かを判断する（ステップＳ２０５）。

ここで、属性とは、リソースをアプリケーションがどのように利用するかの条件を示す情報のことをいう。たとえば、属性として、ＳＤＳＰコーデックリソースに対しては、どのようなコーデックを用いるかを示す情報がある。この属性は、アクセス開始要求ともにアプリケーションから通知されてくる。属性が同一である場合、リソースアクセス判定部１５は、ステップＳ２０８の動作に進んで、当該リソースに対して、アプリケーションＡＰ１およびＡＰ２にアクセス権を付与するようリソース情報を更新する。一方、属性が同一でない場合、リソースアクセス判定部１５は、ステップＳ２１０の動作に進む。このように、本実施形態では、属性がアクセス開始要求をなしている全てのアプリケーション間において共通であるといった所定の条件を満たす場合に、リソースアクセス判定部１５は、多重アクセスが可能なようにリソース情報を登録する。

なお、多重アクセスが許容されているアプリケーションの数に上限がある場合、ステップＳ２０５において、リソースアクセス判定部１５は、当該上限数を超えているか否かを判断して、超えていない場合のみ、ステップＳ２０８の動作に進み、超えている場合、ステップＳ２０６の動作に進んで、最も優先度が低いアプリケーションの優先度と、アプリケーションＡＰ１の優先度とを比較して、優先度が高いアプリケーションにアクセス権を設定するようにする。

ステップＳ２０６において、リソースアクセス判定部１５は、アクセス開始要求をなしているアプリケーションＡＰ１の優先度と、アプリケーションＡＰ２の優先度とを比較する。次に、リソースアクセス判定部１５は、比較の結果に基づいて、アプリケーションＡＰ１の方が優先度が高いか否かを判断する（ステップＳ２０７）。アプリケーションＡＰ１の方が優先度が高い場合、リソースアクセス判定部１５は、ステップＳ２０８の動作に進み、優先度が高いアプリケーションにアクセス権を設定するよう、リソース情報を更新する。その後、リソースアクセス判定部１５は、アプリケーション情報記憶部１２におけるアプリケーションＡＰ２に関するアクセス可否情報を「不可」となるように設定し（ステップＳ２０９）、ステップＳ２１０の動作に進む。一方、アプリケーションＡＰ１の方が優先度が低い場合、リソースアクセス判定部１５は、ステップＳ２１０の動作に進む。

一方、ステップＳ２０１において、複数存在しないと判断された場合、すなわち、アクセス対象論理デバイスＤＥＶ１が使用するリソースが一つだけであるか、あるいは使用するリソースは複数あるが、それぞれは一つずつである場合、リソースアクセス判定部１５は、当該リソースのいずれか一つに対してアクセス権を取得している他のアプリケーションが存在するか否かを判断する（ステップＳ２１１）。ここで、アクセス権を取得している他のアプリケーションをアプリケーションＡＰ３ということにする。それぞれは一つずつのリソースが複数ある場合、アクセス権を取得しているアプリケーションは複数ある場合があるが、ここではまず、いずれか一つのリソースについて以下の処理を行うこととする。

ステップＳ２１１において、存在しないと判断した場合、リソースアクセス判定部１５は、ステップＳ２０８の動作に進み、アプリケーションＡＰ１がアクセス権を取得するようにリソース情報を更新する。一方、存在すると判断した場合、リソースアクセス判定部１５は、アプリケーション情報記憶部１２を参照して、当該リソースに対応するアプリケーションのアプリケーション情報を取得し（ステップＳ２１２）、ステップＳ２０４に進む。

ステップＳ２１０において、リソースアクセス判定部１５は、アクセス対象論理デバイスＤＥＶ１で使用される全てのリソースに関して、上記リソース情報およびアプリケーション情報の更新処理が終了しているか否かを判断する（ステップＳ２１０）。終了していない場合、リソースアクセス判定部１５は、ステップＳ２０１の動作に戻る。この際、リソースアクセス判定部１５は、一度判定したリソースに関しては、ステップＳ２０１以降の判定を行わないこととする。一方、終了している場合、競合調停装置１は、ステップＳ１０５以降の動作に進む。

図１１は、アプリケーションからアクセス要求があったときの競合調停装置１の動作を示すフローチャートである。以下、図１１を参照しながら、アプリケーションからアクセス要求があったときの競合調停装置１の動作について説明する。

アプリケーションＡＰ１は、アクセス要求をする前に、アクセス開始要求を行っている。アクセス要求が行われたとき、上述のように、アクセス対象論理デバイスＤＥＶ１に対するアプリケーションＡＰ１のアクセス可否情報がアプリケーション情報記憶部１２に登録される。アクセス要求時の動作では、アクセス開始要求で設定されたアプリケーション情報を用いて、処理がなされる。

まず、アプリケーションＩＦ部１１は、アプリケーションＡＰ１からのアクセス要求を受信して、実行部１７に通知する（ステップＳ３０１）。次に、実行部１７は、アプリケーション情報記憶部１２を参照する（ステップＳ３０２）。

次に、実行部１７は、アプリケーションＡＰ１に対応するアクセス可否情報に基づいて、アクセス要求をなしたアプリケーションＡＰ１がアクセス対象論理デバイスＤＥＶ１にアクセス可能と設定されているか否かを判断する（ステップＳ３０３）。

アクセス可能と設定されている場合、実行部１７は、当該デバイスドライバをデバイスドライバ実行部１７に実行させて（ステップＳ３０４）、処理を終了する。

一方、アクセス不可と設定されている場合、実行部１７は、アプリケーションＩＦ部１１に対して、アクセス不可である旨のエラーメッセージを通知する。これに応じて、アプリケーションＩＦ部１１は、アプリケーションＡＰ１に対して、論理デバイスＤＥＶ１にアクセス不可である旨を通知し（ステップＳ３０５）、処理を終了する。

図１２は、アプリケーションからアクセス終了要求があったときの競合調停装置１の動作を示すフローチャートである。以下、図１２を参照しながら、アプリケーションからアクセス終了要求があったときの競合調停装置１の動作について説明する。

まず、アプリケーションＩＦ部１１は、アプリケーションＡＰ１からのアクセス終了要求を受信し、アプリＩＤ、アクセス対象論理デバイス名および優先度を使用リソース認識部１３に送って、アクセス終了要求がきた旨を、使用リソース認識部１３に通知する（ステップＳ４０１）。

これに応じて、使用リソース認識部１３は、デバイス情報記憶部１８を参照して、当該アクセス対象論理デバイスＤＥＶ１に必要なリソース名を取得して、リソースアクセス判定部１５に通知する。これに応じて、リソースアクセス判定部１５は、当該アクセス対象論理デバイスが必要とするリソースに対応するリソース情報をリソース情報記憶部１４から取得する（ステップＳ４０２）。

次に、リソースアクセス判定部１５は、デバイス情報記憶部１８を参照して、ステップＳ４０２で認識したリソースを用いる論理デバイスを認識し、アプリケーション情報記憶部１２を参照して、当該論理デバイスにアクセス開始要求をなしているがアクセス可否情報が「不可」となっているアプリケーションを認識する。これによって、リソースアクセス判定部１５は、ステップＳ４０２で認識した全てのリソースに対して、アプリケーションＡＰ１以外のアプリケーションがアクセス開始要求をなしているがアクセス権を取得できていない状況であるか否かを判断する。アクセス権を取得できていないアプリケーションがある場合、リソースアクセス判定部１５は、リソース情報記憶部１４の内容を書き換えて、当該アプリケーションに対して、アクセス権を設定する（ステップＳ４０３）。ステップＳ４０３における処理については、後で詳述する。

次に、リソースアクセス判定部１５は、アプリケーション情報記憶部１２を参照して、ステップＳ４０３の処理でアクセス権を取得したアプリケーションのアクセス対象論理デバイスを認識し、デバイス情報を参照して、当該アクセス対象論理デバイスが使用する全てのリソースを認識し、リソース情報記憶部１４を参照して、当該全てのリソースに対して、当該アプリケーションにアクセス権が設定されているか否かを判断する。これによって、リソースアクセス判定部１５は、使用する全てのリソースに対してアクセス権が設定されているアプリケーションを検索する（ステップＳ４０４）。以下、ステップＳ４０４で検索されたアプリケーションをアプリケーションＡＰ４とする。

次に、リソースアクセス判定部１５は、ステップＳ４０４での検索の結果、アプリケーションＡＰ４が見つかったか否かを判断する（ステップＳ４０５）。見つからなかった場合、リソースアクセス判定部１５は、ステップＳ４０８の動作に進んで、アクセス終了要求のあったアプリケーションＡＰ１に関するアプリケーション情報をアプリケーション情報記憶部１２から削除し、処理を終了する。

一方、見つかった場合、リソースアクセス判定部１５は、アプリケーションＡＰ４に関するアクセス可否情報が「可」となるように、アプリケーション情報記憶部１２を更新する（ステップＳ４０６）。次に、実行部１７は、アクセス可否情報が「可」となったアプリケーションが所望の論理デバイスを使用することができるように、当該論理デバイスに対応するデバイスドライバの設定をアプリケーションＡＰ４が使用できるように変更して、ステップＳ４０８の動作に進んで、処理を終了する。

ただし、上記動作は、デバイスドライバが一度設定されたアクセス権を有するアプリケーションに関する設定を保持しておく機能を有している場合にのみ有効に実現する。もし、このような機能をデバイスドライバが有していない場合、実行部１７は、アプリケーションＡＰ４がアクセス要求をなしてきたときに、デバイス設定が必要だというエラーコードをアプリケーションＡＰ４に返せばよい。また、デバイスドライバが上記の保持機能をサポートしている場合、デバイスドライバは、設定の自動復元ができる。

図１３は、ステップＳ４０３におけるリソースアクセス判定部１５の動作の詳細を示すフローチャートである。以下、図１３を参照しながら、ステップＳ４０３におけるリソースアクセス判定部１５の動作について説明する。

まず、リソースアクセス判定部１５は、アプリケーション情報記憶部１２を参照して、アプリケーションＡＰ１のアクセス対象論理デバイスを認識し、デバイス情報を参照して、当該アクセス対象論理デバイスが使用する全てのリソースを認識し、リソース情報記憶部１４を参照して、認識したいずれか一つのリソースに対してアプリケーションＡＰ１にアクセス権が設定されているか否かを判断する（ステップＳ５０１）。

アクセス権が設定されている場合、リソースアクセス判定部１５は、デバイス情報記憶部１８を参照して、当該リソースを用いる論理デバイスを認識し、アプリケーション情報記憶部１２を参照して、当該論理デバイスに対してアクセス開始要求をなしているアプリケーションを検索する（ステップＳ５０２）。ここで、検索されたアプリケーションをＡＰ５ということにする。

次に、リソースアクセス判定部１５は、ステップＳ５０２で認識したアプリケーションＡＰ３が複数存在するか否かを判断する（ステップＳ５０３）。複数存在する場合、リソースアクセス判定部１５は、アプリケーション情報記憶部１２を参照して、その中から最も優先度の高いアプリケーションＡＰ５を検索して（ステップＳ５０４）、ステップＳ５０５の動作に進む。一方、複数存在しない場合、リソースアクセス判定部１５は、そのまま、ステップＳ５０５の動作に進む。

ステップＳ５０５において、リソースアクセス判定部１５は、アプリケーションＡＰ５にアクセス権が与えられるように、リソース情報記憶部１４の内容を更新し、ステップＳ５０６の動作に進む。このとき、リソースアクセス判定部１５は、アプリケーションＡＰ１にアクセス権が与えられていたリソースを必要とするアプリケーションＡＰ５が存在しない場合、当該リソースのリソース情報にＮＵＬＬを設定する。また、多重アクセスを許すリソースのリソース情報が更新になった場合、リソースアクセス判定部１５は、新たにリソースの属性を設定する。その上で、リソースアクセス判定部１５は、新たに設定された属性とステップＳ５０２で検索された他のアプリケーションが用いる当該リソースの属性とを比較する。比較の結果、同一の属性であると判断した場合、リソースアクセス判定部１５は、他のアプリケーションに対してもアクセス権を付与する。このとき、付与できるアクセス権の数に上限がある場合は、リソースアクセス判定部１５は、優先度の高い順にアクセス権を付与することとする。

ステップＳ５０６において、リソースアクセス判定部１５は、アプリケーションＡＰ１のアクセス対象である論理デバイスが必要とする全てのリソースに対して、上記の処理が行われたか否かを判断する（ステップＳ５０６）。行われていない場合、リソースアクセス判定部１５は、ステップＳ５０１の動作に戻る。一方、行われている場合、競合調停装置は、ステップＳ４０４の動作に進む。

図１２および図１３を用いて説明したように、競合調停装置１は、アプリケーションＡＰ１が論理デバイスＤＥＶ１へのアクセスを終了した場合に、自動的に、今までリソース競合が起きていたためアクセスが不可になっていたアプリケーションに対して論理デバイスＤＥＶ１へのアクセス権を付与する。

図１２および図１３を用いて説明した処理は、アクセス終了処理がなされた論理デバイスＤＥＶ１以外の論理デバイス（たとえば、ＤＥＶ２）に対しても、アクセス権を付与するといった特徴を有している。ここで、一例として、アプリケーションＡＰ２がアクセス対象論理デバイスＤＥＶ２にアクセス開始要求をし、実際にはまだ論理デバイスＤＥＶ２にアクセスしていないときに、アプリケーションＡＰ２より優先度の高いアプリケーションＡＰ１が論理デバイスＤＥＶ１にアクセス開始要求をしてきた場合を考える。ここでは、論理デバイスＤＥＶ１と論理デバイスＤＥＶ２とは、共に、リソースＲを必要とすると想定する。

まず始めに、アプリケーションＡＰ２が論理デバイスＤＥＶ２にアクセス開始要求をなしたとき、リソースＲに対してはアクセス競合が発生していない。そのため、アプリケーションＡＰ２は、論理デバイスＤＥＶ２に対してアクセスできる。その後、アプリケーションＡＰ１が論理デバイスＤＥＶ１にアクセス開始要求をなしたとする。ここでは、アプリケーションＡＰ１の方が優先度が高いと想定しているため、リソースＲへのアクセス権は、アプリケーションＡＰ１が取得する。結果、アプリケーションＡＰ２は、論理デバイスＤＥＶ２に対してアクセス不可となる。

しかし、アプリケーションＡＰ２は、アクセス開始要求をなした段階で止まっているので、実際には論理デバイスＤＥＶ２に対してアクセス要求を未だなしていない。そのため、アプリケーションＡＰ２は、論理デバイスＤＥＶ２に対してアクセス不可になったことを未だ知らない。

このような状況の下、アプリケーションＡＰ１が論理デバイスＤＥＶ１にアクセスした後、必要な処理を終えてアクセス終了要求をなしたとする。これによって、リソースＲは、アプリケーションＡＰ１から解放される。論理デバイスＤＥＶ２はリソースＲを必要としているので、図１２および図１３で説明した処理によって、アプリケーションＡＰ２は、自動的に、論理デバイスＤＥＶ２へアクセス可となる（ステップＳ４０４〜Ｓ４０６参照）。すなわち、アプリケーションＡＰ２は自分がアクセス開始要求をした後、論理デバイスＤＥＶ２にアクセスするまでの間、論理デバイスＤＥＶ２へアクセス不可となっていたことを知ることなく、論理デバイスＤＥＶ２へのアクセスできることとなる。このような処理によって、デバイスアクセスするためのアプリケーションの作りが簡潔になる。

次に、図９〜図１３を用いて説明した処理の流れを、図２〜図４に示したアプリケーション、論理デバイス、リソース、および物理デバイスの対応関係を例にとって、具体的に説明する。

たとえば、図２において、既にアプリケーションＡ１がＳＤＳＰ論理デバイスにアクセス可能であるときに、アプリケーションＡ２がＭＩＤＩ論理デバイスにアクセス開始要求をなした状況を考える。ここでは、アプリケーションＡ２の方がアプリケーションＡ１よりも優先度が高いとする。

まず、競合調停装置１は、アプリケーションＡ２が必要なＭＩＤＩリソースとスピーカリソースとのリソース情報を取得する。ＭＩＤＩリソースおよびスピーカリソースは、共に、同一名のリソースはなく、一つずつしか存在しない。そのため、競合調停装置１は、これらのリソースのアクセス権を既に取得しているアプリケーションが存在するか否かを判断する（図１０：ステップＳ２１１参照）。ここで、スピーカリソースのアクセス権は、既に、アプリケーションＡ１が取得している。そのため、競合調停装置１は、アプリケーションＡ２とアプリケーションＡ１との優先度を比較する（図１０：ステップＳ２０６参照）。ここでは、アプリケーションＡ２の方が優先度が高いと想定しているため、アプリケーションＡ２は、ＭＩＤＩリソースおよびスピーカリソースのアクセス権を取得することとなり、ＭＩＤＩ論理デバイスにアクセス可能となる（図１０：ステップＳ２０８参照）。

一方、アプリケーションＡ１は、スピーカリソースにアクセス不可となるため、ＳＤＳＰ論理デバイスに対してアクセス不可となる（図１０：ステップＳ２０９参照）。

次に、アプリケーションＡ１がアクセス要求をなした場合、既にアプリケーション情報にアクセス不可と設定されているため、競合調停装置１は、アプリケーションＡ１に対して、エラーメッセージを返す（図１１：ステップＳ３０５参照）。これにより、アプリケーションＡ１は、アクセス不可となったことを知る。

次に、アプリケーションＡ１がアクセス要求をなす前に、アプリケーションＡ２がアクセス終了要求をなした場合を考える。まず、競合調停装置１は、アプリケーションＡ２がアクセス権を取得していたリソース（ＭＩＤＩリソースおよびスピーカリソース）のリソース情報を取得する。次に、競合調停装置１は、各リソースに対して、アクセス権を必要としているアプリケーションが存在するか否かを検索する。本事案では、ＭＩＤＩリソースに対してアクセス権を必要としているアプリケーションが存在しないため、競合調停装置１は、ＭＩＤＩリソースのリソース情報に、ＮＵＬＬを設定する。一方、アプリケーションＡ１がスピーカリソースに対してアクセス権を必要としているため、競合調停装置１は、スピーカリソース情報に、アプリケーションＡ１がアクセス権を取得したことを設定する（図１２：ステップＳ４０３参照）。

もし、アプリケーションＡ１以外にもスピーカリソースを必要とするその他のアプリケーションが存在する場合、競合調停装置１は、アプリケーションＡ１とその他のアプリケーションとの優先度を比較し、優先度の高いアプリケーションにアクセス権を取得させる。

アプリケーションＡ１は、スピーカリソースのアクセス権を新たに取得したことによって、必要とするリソース全てにアクセス可能となったため、ＳＤＳＰ論理デバイスにアクセス可能となる。これにより、競合調停装置１は、アプリケーションＡ１のアプリケーション情報にＳＤＳＰ論理デバイスへのアクセス可能である旨を設定する（図１２：ステップＳ４０６参照）。

もし、ＳＤＳＰデバイスドライバがアプリケーションＡ１の設定を復元することができる機能を有している場合、次にアプリケーションＡ１がアクセス要求をなしたとき、アプリケーションＡ１は、一度アクセス不可になっていたことを知ることなく、ＳＤＳＰ論理デバイスにアクセスできる。つまり、アプリケーションＡ１は、ＳＤＳＰ物理デバイスとスピーカ物理デバイスとにアクセスできる。

次に、図３の構成例の場合における具体的な処理の流れについて説明する。たとえば、図３において、アプリケーションＡ１、Ａ２、Ａ４が既に回線論理デバイスにアクセス可能であると想定する。このとき、アプリケーションＡ３が、回線論理デバイスにアクセス開始要求をなしたときを考える。ここで、優先度は、アプリケーションＡ１、アプリケーションＡ２、アプリケーションＡ３、アプリケーションＡ４の順に高いとする。すなわち、ＡＰ１の優先度が最も高い。

まず、競合調停装置１は、三つの回線リソース３２〜３４の内、アクセス権が設定されていない回線リソースを判断する（図１０：ステップＳ２０２参照）。本事案では、既に、全ての回線リソース３２〜３４に対して、アプリケーションＡ１、Ａ２、Ａ４が、アクセス権を取得している。したがって、アクセス権が設定されていない回線リソース（空いている回線リソース）は、存在しない。

次に、競合調停装置１は、アプリケーションＡ１、Ａ２、Ａ４の中で最も優先度の低いアプリケーションを認識する（図１０：ステップＳ２０３参照）。本事案では、アプリケーションＡ４の優先度が最も低い。次に、競合調停装置１は、アプリケーションＡ４とＡ３との優先度を比較する（図１０：ステップＳ２０６参照）。本事案では、アプリケーションＡ３の優先度の方がアプリケーションＡ４の優先度よりも高い。したがって、競合調停装置１は、アプリケーションＡ４がアクセス権を取得していた回線リソースに対して、アプリケーションＡ３がアクセス権を取得するように設定する。これにより、アプリケーションＡ３は、回線論理デバイスに対してアクセス可能となる（図１０：ステップＳ２０８参照）。一方、アプリケーションＡ４は、回線論理デバイスに対して、アクセス不可となる（図１０：ステップＳ２０９参照）。

次に、アプリケーションＡ４より優先度の低いアプリケーションＡ５（図示せず）がアクセス開始要求をしてきた場合を考える。このとき、既に、回線リソースは全て埋まっているため、競合調停装置１は、アプリケーションＡ１、Ａ２、Ａ３の中で優先度の最も低いアプリケーションを認識する（図１０：ステップＳ２０３参照）。この中では、アプリケーションＡ３が最も優先度が低い。次に、競合調停装置１は、アプリケーションＡ３とＡ５との優先度を比較する（図１０：ステップＳ２０６参照）。本事案では、ＡＰ５の方が優先度が低い。したがって、競合調停装置１は、ＡＰ５は回線論理デバイスにアクセス不可となるように設定する（図９：ステップＳ１０８参照）。

次に、アプリケーションＡ４およびＡ５がともに回線論理デバイスにアクセス要求をなす前に、アプリケーションＡ２がアクセス終了要求をなした場合を考える。この場合、回線リソースを必要としているアプリケーションは、アプリケーションＡ４、Ａ５の２つが存在する（図１３：ステップＳ５０２参照）。競合調停装置１は、アプリケーションＡ４とＡ５との内、最も優先度が高いアプリケーションを認識する（図１３：ステップＳ５０４参照）。本事案では、ＡＰ４の方が優先度が高い。したがって、競合調停装置１は、ＡＰ２がアクセス権を取得していた回線リソースに対して、アプリケーションＡ４にアクセス権を与える（図１３：ステップＳ５０５参照）。これにより、アプリケーションＡ４は、回線論理デバイスにアクセス可能となる（図１２：ステップＳ４０６参照）。

次に、図４の構成例の場合における具体的な処理の流れについて説明する。たとえば、図４において、アプリケーションＡ１が既にＳＤＳＰ録音論理デバイスにアクセス可能であると想定する。このとき、アプリケーションＡ３がＳＤＳＰ再生論理デバイスにアクセス開始要求をなしたときを考える。ここで、アプリケーションＡ１の優先度は、アプリケーションＡ３の優先度より高いとする。また、アプリケーションＡ１とＡ３とは、同じコーデックＸを使用するとする。また、ＳＤＳＰコーデックリソースは、付加情報を持ったリソースで、設定された状態と同じであれば多重アクセスを許す性質を持っているとする。

ＳＤＳＰコーデックリソースが多重アクセスを許さないリソースであれば、ＳＤＳＰコーデックリソースには、既にアプリケーションＡ１にアクセス権が設定されているため、競合調停装置１は、アプリケーションＡ１とアプリケーションＡ３との優先度を比較する（図１０：ステップＳ２０６参照）。本事案では、アプリケーションＡ１の優先度の方が、アプリケーションＡ３の優先度よりも高い。したがって、このような場合、多重アクセスを許さない普通のリソースであれば、アプリケーションＡ３は、アクセス権を取得できない。

しかし、ＳＤＳＰコーデックリソースは多重アクセスを許すリソースであるため、アプリケーションＡ３は、アクセス権を取得できる可能性がある。そこで、競合調停装置１は、ＳＤＳＰコーデックリソースに設定されているコーデックの種別とアプリケーションＡ３が使用するコーデックの種別とを比較する（図１０：ステップＳ２０５参照）。本事案では、二つの種別は同じコーデックＸであるため、競合調停装置１は、アプリケーションＡ３に対してＳＤＳＰコーデックリソースへのアクセス権を付与する（図１０：ステップＳ２０８）。これにより、アプリケーションＡ３は、ＳＤＳＰ再生論理デバイスに対してアクセス可能となる。

次に、アプリケーションＡ２がＳＤＳＰ録音論理デバイスにアクセス開始要求をした場合を考える。ここで、アプリケーションＡ２の優先度は、アプリケーションＡ１の優先度よりも低く、アプリケーションＡ３の優先度よりも高いとする。

まず、競合調停装置１は、ＳＤＳＰコーデックリソースに設定されているコーデックの種別とＡＰ２の使用するコーデックの種別とを比較する（図１０：ステップＳ２０５）。ここで、アプリケーションＡ２は、アプリケーションＡ１やＡ３とは異なるコーデックＹを使用するとする。この場合、リソースに設定されている属性であるコーデックの種類が異なることとなるので、アプリケーションＡ２は、ＳＤＳＰコーデックリソースのアクセス権を取得できないこととなる。よって、アプリケーションＡ２は、ＳＤＳＰ録音論理デバイスにはアクセス不可となる（図９：ステップＳ１０８参照）。

一方、アプリケーションＡ２は、アプリケーションＡ１やＡ３と同一のコーデックＸを使用するとする。この場合、リソースに設定されている属性であるコーデックの種類と同一となるので、アプリケーションＡ２は、ＳＤＳＰコーデックリソースのアクセス権を取得できる（図１０：ステップＳ２０５参照）。しかし、ＳＤＳＰ録音リソースのアクセス権は、アプリケーションＡ１に付与されたままであるので、アプリケーションＡ２は、全てのリソースに対してのアクセス権を有していないこととなり（図９：ステップＳ１０５参照）、ＳＤＳＰ録音論理デバイスにはアクセス不可となる（図９：ステップＳ１０８参照）。

次に、アプリケーションＡ１がアクセス終了要求をなしたときを考える。まず、ＳＤＳＰ録音リソースに対して、アプリケーションＡ２がアクセス権を必要としているため（図１３：ステップＳ５０２参照）、競合調停装置１は、アプリケーションＡ２にアクセス権を取得させる（図１３：ステップＳ５０５参照）。

次に、ＳＤＳＰコーデックリソースに対して、アプリケーションＡ２とＡ３とがアクセス権を必要としているため（図１３：ステップＳ５０２参照）、競合調停装置１は、アプリケーションＡ２とＡ３との優先度を比較する（図１３：ステップＳ５０４参照）。そして、アプリケーションＡ２の方が優先度が高いため、競合調停装置１は、アプリケーションＡ２にＳＤＳＰコーデックリソースのアクセス権を与える（図１３：ステップＳ５０５参照）。このとき、コーデックの種別が変更になるので、競合調停装置１は、コーデックの種別を設定しなおす。

次に、競合調停装置１は、ＳＤＳＰコーデックリソースに新たに設定されたコーデックの種別とアプリケーションＡ３が使用するコーデックの種別とを比較する（図１３：ステップＳ５０５参照）。ここで、アプリケーションＡ２とＡ３とは異なるコーデックを使用することとしているので、競合調停装置１は、アプリケーションＡ３はＳＤＳＰコーデックリソースに対してアクセス不可となるように設定する。これにより、アプリケーションＡ３は、ＳＤＳＰ再生論理デバイスに対してアクセス不可となる。

このように、上記実施形態では、競合調停装置は、アプリケーションによって指定される論理デバイスと、実際に存在する物理デバイスと、物理デバイスと論理デバイスとを対応付けるリソースとに分離して、物理デバイスの機能およびアプリケーション所望する機能を管理し、リソース単位でアプリケーションから物理デバイスへのアクセスの競合調停を行う。したがって、物理デバイスの構成が変化したとしても、競合調停装置内のリソース情報およびデバイス情報を変更するだけでよいので、物理デバイスの構成変化に柔軟に対応することができる競合調停装置および競合調停方法を提供することができる。さらに、物理デバイスの機能をリソース単位に分割して競合調停を行うので、物理デバイスが様々な特性を有していたとしても、その特性を十分に活かしきることができる競合調停装置および競合調停方法を提供することができる。

たとえば、回線物理デバイスのように、ある上限数以内であれば多重アクセスを許すような場合や、ＳＤＳＰ物理デバイスにおけるＳＤＳＰコーデック機能のように、ある条件を満たせば多重アクセスを許すような場合において、競合調停装置は、複数のアプリケーションにアクセス権を付与することができる。このように、競合調停装置は、物理デバイスの特性を十分に活かしきるように競合調停を行うことができる。

また、たとえば、スピーカ物理デバイスのように、他の物理デバイスとは配線結合されているもの、単体ではＩ／Ｏポートを持たない物理デバイスが複数のデバイス間で共有されるような場合でも、競合調停装置は、当該物理デバイスへのアクセスの競合調停を行うことができる。

また、アプリケーションがアクセス要求をなしたときに、アクセスが可能であれば該当のデバイスドライバが実行され、アクセスが不可能であればアプリケーションにエラーが戻るという仕組みが提供されることとなる。したがって、アプリケーションは、アクセス要求をしたときのエラーの対処のみを考慮すれるだけでよい。このようなシステムは、アプリケーション開発者にとって、開発負担が軽減されたものである。

また、アプリケーションに付与された優先度を用いて競合調停を行うことで、優先度の高いアプリケーションから順に物理デバイスへのアクセスが許可されることとなる。特に、多重アクセスを許す物理デバイスにおいては、優先度のより高いものからアクセスが可能となり、優先度に応じた複雑な排他制御が可能となる。

また、アプリケーションが物理デバイスにアクセス可能であるか否かは、アプリケーション情報内に登録されることとなるので、アクセス要求がある度に、アクセス可能であるか否かを判断する必要がないので、処理が高速化される。

さらに、他のアプリケーションのアクセス要求により、物理デバイスへのアクセス権が奪われた場合、アクセス権が奪われる前のアプリケーションが次にアクセス要求するまでに、再びその物理デバイスへのアクセスが可能になったら、当該アプリケーションは、一度アクセスが不可能になったという事実を知ることなく、特別な処理を行うことなく、物理デバイスへのアクセスを継続することができる。

また、複数の物理デバイスを同時に制御することで所望の機能が実現されるといったアプリケーションを用いる場合、当該所望の処理を実現するには、当該複数の物理デバイスへのアクセスが許可されている必要がある。本発明のように、リソース単位でアクセス権を管理すれば、全ての物理デバイスにアクセス可能な場合に必要なデバイスドライバを実行させ、所望の機能を実現させることができる。一方、一つでもアクセス不可能な場合、競合調停装置は、アプリケーションにエラーを通知することができる。

なお、上記実施形態で示した物理デバイス、論理デバイスおよびリソースは一例であって、当然、これらに限定されるものではない。

なお、上記実施形態において、リソースアクセス判定部は、優先度が高いアプリケーションに対してリソースに対するアクセス権を付与することとした。この他、リソース情報毎に、先にアクセス要求をなしたアプリケーションに使用許可を与えるのか、それとも、後からアクセス要求をなしたアプリケーションに使用許可を与えるのかに関する先勝ち情報を付加しておいて、リソースアクセス判定部は、先勝ち情報に基づいて、アクセス権を与えるアプリケーションを判定してもよい。また、リソースアクセス判定部は、アプリケーションの優先度が同じ場合にのみ、先勝ち情報に基づいて、アクセス権を与えるアプリケーションを判定してもよい。

なお、上記実施形態において、競合調停装置は、アプリケーションが所望する論理デバイスに必要な全てのリソースに対してアクセス権が付与されている場合にのみ、当該アプリケーションが当該論理デバイスにアクセス可能であると設定することとした（図９：ステップＳ１０５〜Ｓ１０６参照）。しかし、全てのリソースに対してアクセス権が設定されていなくても、一部のリソースにのみアクセス権が設定されていれば、論理デバイスの一部の機能を実現できる場合がある。そのため、競合調停装置は、論理デバイスが使用するリソースの全てが使用できない場合であっても、使用可能なリソースのみアプリケーションが使用できるようにしてもよい。

図１４は、論理デバイスが使用するリソースの全てが使用できない場合であっても、使用可能なリソースのみアプリケーションが使用できるようにするときの競合調停装置の動作を示すフローチャートである。図１４に示すフローチャートは、図９に示すステップＳ１０５〜Ｓ１０８に置き換わるものである。図１４において、図９に示すステップと同様の動作であるステップについては、同一のステップ番号を付し、説明を省略する。

競合調停装置１は、アクセス開始要求をなしたアプリケーションがアクセス対象論理デバイスが使用する全てのリソースに対してアクセス権を有していないと判断した場合、ステップＳ１０８１の動作に進む。ステップＳ１０８１において、競合調停装置１の実行部１７は、アクセス対象論理デバイスが使用する全てのリソースの内、当該アプリケーションがアクセス可能なリソースを認識する。次に、実行部１７は、ステップＳ１０８１で認識したリソースの内、単独で使用できるリソースが存在するか否かを判断する（ステップＳ１０８２）。このとき、実行部１７は、リソース情報に付加されている単独で使用できるかを示す情報に基づいて、当該判断を行う。

単独で使用できるリソースが存在する場合、実行部１７は、当該リソースの機能を実現するように、デバイスドライバ実行部５にデバイスドライバを実行させ（ステップＳ１０８３）、処理を終了する。一方、単独で使用できるリソースが存在しない場合、実行部１７は、当該アプリケーションに対するアクセス可否情報が「不可」となるようにアプリケーション情報記憶部１２の登録内容を更新し（ステップＳ１０８）、処理を終了する。

このように、全ての物理デバイスにアクセスできなくても、所望の機能の一部が実行できればよい場合、競合調停装置は、アプリケーションが当該所望の機能の一部を実行できるように、デバイスドライバを実行させることもできる。

本発明にかかる競合調停装置、競合調停方法および競合調停プログラムは、物理デバイスの特性を十分に活かしきることができ、かつ物理デバイスの構成変化に柔軟に対応することができ、複数のアプリケーションが起動するコンピュータシステム等に用いられるものとして有用である。

本発明の一実施形態に係る競合調停装置が適用されるコンピュータシステムの全体構成を示すブロック図 アプリケーション、論理デバイス、リソース、および物理デバイスの対応関係の例を示す模式図 アプリケーション、論理デバイス、リソース、および物理デバイスの対応関係の例を示す模式図 アプリケーション、論理デバイス、リソース、および物理デバイスの対応関係の例を示す模式図 競合調停装置１の機能的構成を示すブロック図 アプリケーション情報記憶部１２に格納されているアプリケーション情報の一例を示す図 デバイス情報の一例を示す図 リソース情報の一例を示す図 アプリケーションからアクセス開始要求があったときの競合調停装置１の動作を示すフローチャート ステップＳ１０４におけるリソースアクセス判定部１５の動作を詳細に示したフローチャート アプリケーションからアクセス要求があったときの競合調停装置１の動作を示すフローチャート アプリケーションからアクセス終了要求があったときの競合調停装置１の動作を示すフローチャート ステップＳ４０３におけるリソースアクセス判定部１５の動作の詳細を示すフローチャート 論理デバイスが使用するリソースの全てが使用できない場合であっても、使用可能なリソースのみアプリケーションが使用できるようにするときの競合調停装置の動作を示すフローチャート

符号の説明

１ 競合調停装置
２ アプリケーション実行装置
３ 物理デバイス
４ デバイスドライバ実行装置
１１ アプリケーションＩＦ部
１２ アプリケーション情報記憶部
１３ 使用リソース認識部
１４ リソース情報記憶部
１５ リソースアクセス判定部
１６ デバイスアクセス判定部
１７ 実行部
１８ デバイス情報記憶部

Claims (5)

1. 複数のアプリケーションが同時に少なくとも一つの物理デバイスの使用を所望した場合に発生する競合を調停する競合調停装置であって、
   前記物理デバイスには、Ｉ／Ｏポートを持つ第１の物理デバイスと、当該第１の物理デバイスに配線結合されＩ／Ｏポートを持たない第２の物理デバイスとが存在し、
   各前記物理デバイスが有する少なくとも一つの機能を機能毎に定義するリソースと、当該リソースの使用が現在許可されているアプリケーションとの対応関係を示すリソース情報を格納するリソース情報記憶手段と、
   前記アプリケーションが実行されることで実現される機能を定義する論理デバイスと、当該論理デバイスが定義した機能を実現するために必要なリソースとの対応関係を示すデバイス情報を格納するデバイス情報格納手段と、
   前記アプリケーションによって新たに論理デバイスが指定された場合、前記デバイス情報を参照して、新たに指定された論理デバイスに対応する必要なリソースを認識する使用リソース認識手段と、
   前記リソース情報を参照して現在使用が許可されているアプリケーションを認識し、前記使用リソース認識手段によって認識された必要なリソースのそれぞれについて、使用が許可されるアプリケーションを所定の基準に基づいて判定するリソースアクセス判定手段と、
   前記アプリケーションが指定した論理デバイスが定義する機能を実現するために必要なリソースの全てを使用可能か否かを、前記リソースアクセス判定手段による判定結果に基づいて判定することによって、当該アプリケーションが当該論理デバイスにアクセス可能か否かを判定するデバイスアクセス判定手段とを備える、競合調停装置。
2. 前記デバイスアクセス判定手段によって、前記論理デバイスを新たに指定したアプリケーションが前記必要なリソースの全てを使用可能と判定されたことによって当該アプリケーションが当該論理デバイスにアクセス可能と判定された場合、当該必要なリソースの全てにそれぞれ対応する物理デバイスを制御するためのデバイスドライバを実行させる実行手段をさらに備える、請求項１に記載の競合調停装置。
3. 前記デバイスアクセス判定手段による判定結果を、判定対象のアプリケーションと対応させてアプリケーション情報として格納するアプリケーション情報記憶手段と、
   前記デバイスアクセス判定手段による判定結果に基づいて前記アプリケーション情報を更新し、当該判定結果がアクセス可能である場合、前記必要なリソースの全てにそれぞれ対応する物理デバイスを制御するためのデバイスドライバを実行させる実行手段とをさらに備え、
   前記使用リソース認識手段は、論理デバイスにアクセスしているアプリケーションから当該論理デバイスへのアクセス終了要求を受け取った場合、アクセスを終了する論理デバイスに対応するリソースを認識し、
   前記リソースアクセス判定手段は、前記アプリケーション情報を参照して、前記アクセスを終了する論理デバイスに対応するリソースの使用が競合により許可されていない他のアプリケーションの有無を判定し、当該他のアプリケーションが有る場合、当該他のアプリケーションに競合を理由に使用許可されていないリソースの使用許可を与え、当該許可の結果を反映して前記リソース情報を更新し、
   前記デバイスアクセス判定手段は、前記他のアプリケーションが指定する論理デバイスが定義する機能を実現するために必要なリソースの全てを当該他のアプリケーションが使用できるか否かを、前記リソースアクセス判定手段により更新された前記リソース情報に基づいて判定することによって、当該他のアプリケーションが当該論理デバイスにアクセス可能か否かを判定し、
   前記実行手段は、前記デバイスアクセス判定手段によって前記他のアプリケーションが前記論理デバイスにアクセス可能と判定された場合、当該他のアプリケーションが前記必要なリソースの全てにそれぞれ対応する物理デバイスにアクセスできるように、当該物理デバイスを制御するデバイスドライバの設定を変更することを特徴とする、請求項１に記載の競合調停装置。
4. 複数のアプリケーションが同時に少なくとも一つの物理デバイスの使用を所望した場合に発生する競合を調停するようにコンピュータ装置を機能させるためのプログラムであって、
   前記物理デバイスには、Ｉ／Ｏポートを持つ第１の物理デバイスと、当該第１の物理デバイスに配線結合されＩ／Ｏポートを持たない第２の物理デバイスとが存在し、
   前記コンピュータ装置には、各前記物理デバイスが有する少なくとも一つの機能を機能毎に定義するリソースと当該リソースの使用が現在許可されているアプリケーションとの対応関係を示すリソース情報と、前記アプリケーションが実行されることで実現される機能を定義する論理デバイスと当該論理デバイスが定義した機能を実現するために必要なリソースとの対応関係を示すデバイス情報とが記憶されており、
   前記アプリケーションによって新たに論理デバイスが指定された場合、前記デバイス情報を参照して、新たに指定された論理デバイスに対応する必要なリソースを前記コンピュータ装置に認識させるステップと、
   前記リソース情報を参照して現在使用が許可されているアプリケーションを前記コンピュータ装置に認識させ、前記新たに指定された論理デバイスに対応する必要なリソースのそれぞれについて、使用が許可されるアプリケーションを所定の基準に基づいて当該コンピュータ装置に判定させるステップと、
   前記アプリケーションが指定した論理デバイスが定義する機能を実現するために必要なリソースの全てを使用可能か否かを、前記使用が許可されるアプリケーションの判定結果に基づいて判定させることによって、当該アプリケーションが当該論理デバイスにアクセス可能か否かを前記コンピュータ装置に判定させるステップとを備える、競合調停プログラム。
5. コンピュータ装置によって、複数のアプリケーションが同時に少なくとも一つの物理デバイスの使用を所望した場合に発生する競合を調停するための方法であって、
   前記物理デバイスには、Ｉ／Ｏポートを持つ第１の物理デバイスと、当該第１の物理デバイスに配線結合されＩ／Ｏポートを持たない第２の物理デバイスとが存在し、
   前記コンピュータ装置には、各前記物理デバイスが有する少なくとも一つの機能を機能毎に定義するリソースと当該リソースの使用が現在許可されているアプリケーションとの対応関係を示すリソース情報と、前記アプリケーションが実行されることで実現される機能を定義する論理デバイスと当該論理デバイスが定義した機能を実現するために必要なリソースとの対応関係を示すデバイス情報とが記憶されており、
   前記アプリケーションによって新たに論理デバイスが指定された場合、前記デバイス情報を参照して、新たに指定された論理デバイスに対応する必要なリソースを前記コンピュータ装置が認識するステップと、
   前記リソース情報を参照して現在使用が許可されているアプリケーションを前記コンピュータ装置が認識し、前記新たに指定された論理デバイスに対応する必要なリソースのそれぞれについて、使用が許可されるアプリケーションを所定の基準に基づいて当該コンピュータ装置が判定するステップと、
   前記アプリケーションが指定した論理デバイスが定義する機能を実現するために必要なリソースの全てを使用可能か否かを、前記使用が許可されるアプリケーションの判定結果に基づいて判定することによって、当該アプリケーションが当該論理デバイスにアクセス可能か否かを前記コンピュータ装置が判定するステップとを備える、競合調停方法。

Images