第一のセキュリティドメインに属する第一のアプリケーションと、前記第一のセキュリティドメイン及び第二のセキュリティドメインに属する第二のアプリケーションと、が動作するアプリケーション実行環境を有する情報処理装置であって、前記第一のセキュリティドメイン及び前記第二のセキュリティドメインに属さず、前記第一のアプリケーションを含む複数のアプリケーションのリソースを管理するリソース管理手段を有し、前記リソース管理手段は、前記第二のアプリケーションから前記第一のアプリケーションのリソースへのアクセス要求を受け取ると、前記アクセス要求に含まれる前記第一のアプリケーションに対する認証結果を前記第一のアプリケーションに引き渡し、前記第一のアプリケーションから前記第二のアプリケーションによる前記リソースへのアクセスを許可するか否かの判断結果を受け取ると、判断結果を前記第二のアプリケーションに返却する情報処理装置。前記第一のセキュリティドメインに属する第二のアプリケーションは、前記第一のセキュリティドメインに属する第一のアプリケーションに対し認証を行うことが可能であり、前記アクセス要求に含まれる認証結果は、前記第二のアプリケーションが前記認証を事前に行った認証の結果であって、前記第一のセキュリティドメイン及び前記第二のセキュリティドメインに属さない前記リソース管理手段は、前記リソースへのアクセスを許可するか否かの判断を行うことができない請求項1記載の情報処理装置。前記リソース管理手段は、前記第一のアプリケーションから前記第二のアプリケーションによる前記リソースへのアクセスを許可することを示す判断結果を受け取ると、前記第二のアプリケーションに対して前記リソースへのアクセスを許可することを示す判断結果を返却し、前記第一のアプリケーションから前記第二のアプリケーションによる前記リソースへのアクセスを許可しないことを示す判断結果を受け取ると、前記第二のアプリケーションに対して前記リソースへのアクセスを許可しないことを示す判断結果を返却する請求項1又は2記載の情報処理装置。前記リソースは、アプリケーションのログであり、前記リソース管理手段は、前記第一のアプリケーションを含む複数のアプリケーションのログを管理する請求項1乃至3何れか1項記載の情報処理装置。前記リソース管理手段は、前記第二のアプリケーションから前記第一のアプリケーションのリソースへのアクセス要求を受け取ると、前記リソースに前記第一のアプリケーションへの問い合わせ用のインターフェースが関連付けられているか否かを判断し、前記リソースに前記第一のアプリケーションへの問い合わせ用のインターフェースが関連付けられている場合、前記アクセス要求に含まれる前記第一のアプリケーションに対する認証結果を、前記インターフェースを介して前記第一のアプリケーションに引き渡す請求項1乃至4何れか1項記載の情報処理装置。前記リソース管理手段は、前記第一のアプリケーションのリソースと、前記第一のアプリケーションへの問い合わせ用のインターフェースと、を関連付けて登録する請求項5記載の情報処理装置。第一のセキュリティドメインに属する第一のアプリケーションと、前記第一のセキュリティドメイン及び第二のセキュリティドメインに属する第二のアプリケーションと、が動作するアプリケーション実行環境を有する情報処理装置における情報処理方法であって、前記情報処理装置は、前記第一のセキュリティドメイン及び前記第二のセキュリティドメインに属さず、前記第一のアプリケーションを含む複数のアプリケーションのリソースを管理するリソース管理手段を有し、前記リソース管理手段が、前記第二のアプリケーションから前記第一のアプリケーションのリソースへのアクセス要求を受け取るステップと、前記リソース管理手段が、前記アクセス要求に含まれる前記第一のアプリケーションに対する認証結果を前記第一のアプリケーションに引き渡すステップと、前記リソース管理手段が、前記第一のアプリケーションから前記第二のアプリケーションによる前記リソースへのアクセスを許可するか否かの判断結果を受け取るステップと、前記リソース管理手段が、判断結果を前記第二のアプリケーションに返却するステップと、を含む情報処理方法。第一のセキュリティドメインに属する第一のアプリケーションと、前記第一のセキュリティドメイン及び第二のセキュリティドメインに属する第二のアプリケーションと、が動作するアプリケーション実行環境を有するコンピュータを、前記第一のセキュリティドメイン及び前記第二のセキュリティドメインに属さず、前記第一のアプリケーションを含む複数のアプリケーションのリソースを管理するリソース管理手段として機能させ、前記リソース管理手段は、前記第二のアプリケーションから前記第一のアプリケーションのリソースへのアクセス要求を受け取ると、前記アクセス要求に含まれる前記第一のアプリケーションに対する認証結果を前記第一のアプリケーションに引き渡し、前記第一のアプリケーションから前記第二のアプリケーションによる前記リソースへのアクセスを許可するか否かの判断結果を受け取ると、判断結果を前記第二のアプリケーションに返却するプログラム。しかしながら、複数のアプリケーションのリソースを一元的に管理するサービスを考えた場合、前記サービスは、アプリケーションと独立してリソースを管理する。そのため、前記サービスは、どのセキュリティドメインにも属さず、第一のアプリケーションのリソースに対して、第二のアプリケーションがアクセスを要求してきてもその可否等を判断できない問題があった。本発明はこのような問題点に鑑みなされたもので、複数のアプリケーションのリソースを一元的に管理するサービスによる、第一のアプリケーションのリソースに対する第二のアプリケーションからのアクセス制御を可能とすることを目的とする。そこで、本発明は、第一のセキュリティドメインに属する第一のアプリケーションと、前記第一のセキュリティドメイン及び第二のセキュリティドメインに属する第二のアプリケーションと、が動作するアプリケーション実行環境を有する情報処理装置であって、前記第一のセキュリティドメイン及び前記第二のセキュリティドメインに属さず、前記第一のアプリケーションを含む複数のアプリケーションのリソースを管理するリソース管理手段を有し、前記リソース管理手段は、前記第二のアプリケーションから前記第一のアプリケーションのリソースへのアクセス要求を受け取ると、前記アクセス要求に含まれる前記第一のアプリケーションに対する認証結果を前記第一のアプリケーションに引き渡し、前記第一のアプリケーションから前記第二のアプリケーションによる前記リソースへのアクセスを許可するか否かの判断結果を受け取ると、前記判断結果に応じて、前記第二のアプリケーションに対して前記リソースへのアクセスを許可するか否かの判断結果を返却する。本発明によれば、複数のアプリケーションのリソースを一元的に管理するサービスによる、第一のアプリケーションのリソースに対する第二のアプリケーションからのアクセス制御を可能とすることができる。以下、本発明の実施形態について図面に基づいて説明する。<実施形態1>図1は、情報処理装置の一例であるデジタル複合機のハードウェア構成の一例を示す図である。図1において、CPU103と、RAM105、Networkインターフェース104、プリンタ部102、操作部108、I/O制御部106が接続され、HDDハードディスクの意107がI/O制御部106を介して接続されている。HDD107には、プログラムが記憶されており、HDD107からCPU103に読み込まれ実行される。CPU103がプログラムを実行することによって、後述するソフトウェアモジュール、及びフローチャートの処理が実現される。ソフトウェアモジュールは、操作部108からユーザの操作入力を受け取ることができると共に、プリンタ部102、RAM105、Networkインターフェース104及びHDD107を利用制御する事が可能である。図2は、ソフトウェアの実行環境等の一例を示す図である。図2において、201は、ソフトウェア実行環境全体を表している。ソフトウェア実行環境における基礎となる部分はOS202である。OSとは一般にコンピュータ技術においてオペレーティングシステムOperatingSystemと呼ばれるソフトウェアモジュールであり、以下で述べる全てのソフトウェアモジュールはOS202上で動作する。また、以下で述べる全てのソフトウェアモジュールは、直接的或いは、後に述べるJava登録商標実行環境204を介して間接的にOS202が提供するAPIを介して、図1のハードウェアモジュールの利用制御を行う。APIは、アプリケーションプログラミングインターフェースの略である。なお、APIの実体はOS202に含まれて提供されることになるため、図2では特に示していない。Java実行環境204は、OS202及びその提供するAPIの種類やハードウェア構成に依らず、その上で動作するソフトウェアに均一化されたAPIを提供する。このことによって、ソフトウェアモジュールの開発効率と再利用可能性とを向上させる仮想実行環境バーチャルマシンを提供する。アプリケーション実行フレームワーク205は、主にアプリケーションのインストールやアンインストールの管理や、アプリケーションの実行順序の制御、同フレームワーク上のアプリケーションやソフトウェアモジュール間のAPIを介した通信機能等、ソフトウェア実行環境201全体を統括して制御する仕組みを提供する。なお、アプリケーション実行フレームワーク205は、上述した機能を提供するソフトウェアモジュール群の総称である。Java実行環境204及び/又はアプリケーション実行フレームワーク205は、アプリケーション実行環境の一例である。ログサービス206は、はじめからソフトウェア実行環境201に存在するソフトウェアモジュールである。ログサービス206は、後にインストールされるアプリケーションのログをHDD107上にログとして記録し管理する機能を提供するが、詳細は後述する図4で示す。ここで、ログとは、一般にアプリケーションの様々な振る舞い、処理の履歴を、ファイルとしてハードディスクやフラッシュメモリ等の記録媒体上に記録されるものの総称である。本実施形態においては、記録媒体としてハードディスク上にファイルとして記録されることとしているが、その他の記録媒体に記録されてもよい。ログサービス206は、リソース管理手段の一例である。ここで、図3において典型的な旧来の構成等の一例を示す。図3は、旧来の構成等の一例を示す図である。図3において、アプリケーション507は、アプリケーション507のみがアクセス可能なファイルにアプリケーションログ509が記録されている。アプリケーション508がアプリケーションログ509にアクセスする場合、アプリケーション508は、予めアクセス可能なパーミッション及びアプリケーション507のログ読み出しに対するユーザ権限の取得が必要となる。即ち、アプリケーション508は、アプリケーション507に対するログ取得を行うパーミッション、及びアプリケーション507が提供するAPIによってアプリケーション507の管理下にあるユーザの権限を取得する。そして、これらを取得した上で、アプリケーション508は、アプリケーションログ509を取得することができる。ここで、アプリケーション507は、アプリケーション507に対する認証機能とアプリケーションログ509のアクセス制御機能とを保有するだけでなく、他のアプリケーションからアクセスされる可能性のあるアプリケーションログ509を所有している。言い換えればアプリケーション507自身が管理する領域にアプリケーションログ509が配置されている。一方、図2では、任意のアプリケーションは、ログサービス206が、アプリケーション実行フレームワーク205に対して登録しているAPIを介して、ログサービス206の機能を利用することができる。即ち、図3の例においては、アプリケーション507は、アプリケーションログ509を保有しているが、図2の例においては、図4で示すように、ログサービス206が複数のアプリケーションログを保有している。言い換えればログサービス206は、アプリケーション207等、複数のアプリケーションに対して、ログ領域を提供していることとなる。図2及び図4のような構成を取る最大の動機は、ログ領域の集約化である。ログ領域を一箇所本実施形態の場合はログサービス206に集約化させておく。このことによって、アプリケーションごとにログの形式、ログの取得方法及びそれらを記録取得するAPIを統一することができ、システム全体としてどのアプリケーションも統一されたログ形式に則ることができる。また、ログサービス206のみから集約されたログ領域のログを採取できれば、システムに存在するアプリケーション全てのログを統一された作法で一度に採取できることとなる。その結果、ユーザのログ採取に関する負荷軽減並びにアプリケーション作者のログ記録取得処理の作成負荷軽減というメリットが生じる。ここでまた図2において、ログサービス206はそのAPIによって任意のアプリケーションに対して次の機能を提供する。まず、第一の機能は、アプリケーションのみが記録する専用ログ領域を、ログサービス206のみが直接的にアクセス可能なHDD107上のファイルログファイルとして作成し確保することである。第二の機能は、アプリケーションに対して、APIを介してログの記録を行う機能である。第三の機能は、アプリケーションに対して、APIを介してログの読み取りを行う機能である。それぞれの機能の詳細は図5以降において説明する。ここで、ログサービス206は、複数のログ領域を作成可能であるが、説明を簡易にするため、図4においては、ログサービス206が管理するログ領域全体を301として示しある。また、ログ領域全体301内に、アプリケーション207がログ領域302を作成確保しており、その他のアプリケーションのログ領域は、他のアプリケーションのログ領域303として表記している。図5は、アプリケーションのインストールからアプリケーションのログ領域を確保するまでの処理の一例を示すフローチャートである。なお、ログサービス206は、既にアプリケーション実行フレームワーク205によって既に実行されているものとする。まず、ステップ401で、アプリケーション207は、アプリケーション実行フレームワーク205によってインストールされ、実行される。実行されたアプリケーション207は、先述のAPIを介して、ログサービス206に対してアプリケーション207専用のログ領域302の確保を要求する。また、アプリケーション207は、ユーザ権限確認用APIとアプリケーションパーミッションここではアプリケーションパーミッションAとしたとをログ領域302に登録するステップ402。アプリケーションパーミッションとは、Javaにおいて導入されているアプリケーションの実行体に施されるコードレベルのセキュリティ機構であり、その定義や振舞いはAPI内部の処理で規定される。一方、パーミッションを保有しているか否かはアプリケーションごとにある定義をその実行体内部のファイル等に宣言する形で実装される。また、パーミッションは、あるAPIを通じて機能や処理を実行要求する場合、そのAPIを呼び出す側のアプリケーションが保有しておくべきものであり、一般にはAPIの機能や処理による異なるパーミッションが定義でき得る。そして、もしアプリケーションがその利用に必要となるパーミッションを保有せずにそのAPIを利用しようとすれば、パーミッションが不足しているものとみなされ、APIの利用は中断され失敗することとなる。以下で示すアプリケーションパーミッションAは、アプリケーションパーミッションAを、アプリケーションが保有していれば、アプリケーションパーミッションAが規定する行為、即ちAPIを介してログ領域302へアクセスする権限があるとみなされる。ここで、ユーザ権限確認用APIは、後の説明でログサービス206が、アプリケーション207に対してユーザ権限の確認を行うために利用するものであるが、詳細は後述する。なお、このユーザ権限確認用APIの登録は必須ではない。また、アプリケーションパーミッションAを登録することは、アプリケーションが保有可能なパーミッションのうち、ステップ402で確保されたログ領域302へアクセスする任意のアプリケーションが保有することを義務付けられることを意味している。即ち、任意のアプリケーションのうち、アプリケーションパーミッションAを保有しているアプリケーションのみが、ここで確保したログ領域302へアクセスする権限を持つ。なお、このアプリケーションパーミッションの登録は、ログ領域302の保有者となるアプリケーション207の定めによって決まるものであり、必ずしも設定されなければならないものではない。ここで注意すべきは、ユーザ権限とアプリケーションパーミッションとは、アプリケーション207の定めによって独立して定義され、ログサービス206によって独立に制御されるものである点であるが、この詳細も後述する。なお、アプリケーションパーミッションとは、アプリケーションがインストールされる際に、任意のアプリケーションの実体インストールパッケージの中に記述されるものである。またアプリケーションパーミッションとは、アプリケーション実行フレームワーク205によってインストール時に解釈され、そのアプリケーションが実行中は、Java実行環境204によってそのパーミッションを保有しているかどうかを検証されるものである。本実施形態では、ログサービス206は、APIを介して任意アプリケーションが同サービスを利用したとき、Java実行環境204のパーミッションチェック機構を介して、アプリケーションパーミッションAを保有しているかどうかを検証することができる。次に、ログサービス206は、ログ領域302と共に、アプリケーションパーミッションAとユーザ権限確認用のAPIとをHDD107上にファイルとして記録するステップ403。次に、ステップ404以降において、ログ領域302の保有者であるアプリケーション207とは異なるアプリケーション208が、ログ領域302へアクセスする際の処理について詳述する。ステップ404において、アプリケーション208は、ログ領域302に記録されたログを読み取るようログサービス206に対してAPIを介して要求する。このAPIは、先述のAPIとはその実体は異なるが、同様の機構によってログサービス206がログ領域へのアクセス用にアプリケーションに対して提供するものである。この要求に応じて、ログサービス206は、ログ領域302に対してアプリケーションパーミッションが設定されているかどうかを検証するステップ405。ログサービス206は、この検証を、先述した通り、ログ領域302と共にファイルに保存された情報を基に行うことができる。次に、ログ領域302がアプリケーションパーミッションAを保持していると検証できた場合、ログサービス206は、前記情報を基にアプリケーション208がアプリケーションパーミッションAを保有しているかどうかを検証するステップ406。ステップ405において、ログ領域302にアプリケーションパーミッションが設定されていない場合はステップ406の検証は行われずステップ407に処理は移る。ログ領域302にアプリケーションパーミッションAが設定され、かつ、アプリケーション208がアプリケーションパーミッションAを保有している場合もステップ407に処理は移る。アプリケーション208がアプリケーションパーミッションAを保有していない場合、ログサービス206は、アプリケーション208の読み取り要求を拒絶し、アプリケーション208にその結果を返却するステップ412。続いて、ステップ407において、ログサービス206は、ログ領域302に対してアプリケーション207からユーザ権限確認用APIが登録されているかどうかを確認する。ユーザ権限確認用APIがログ領域302に登録されていない場合、ログサービス206は、この時点でアプリケーション208のログ領域302へのアクセスが許可でき、その結果をアプリケーション208に返却するステップ411。一方、ステップ407において、ユーザ権限確認用APIが登録されている場合には、同APIを用いて、ログサービス206は、アプリケーション207に対してログ領域302に対するユーザ権限が妥当かどうかを問い合わせる。なお、ここで、アプリケーション208は、事前にアプリケーション207に対して、ログサービス206を介さずに、ユーザ認証を完了している事とする。ここでいうユーザ認証とは、例えばアプリケーション208を操作し、同アプリケーションを介してアプリケーション207のログ領域にアクセスする操作を行うユーザが、アプリケーション207に対して、所定のAPIを介して行う認証である。言うなれば、アプリケーション207は別のアプリケーションに対して独自にユーザ認証するAPIを備える。このAPIによって、アプリケーション208は、アプリケーション207の管理下にあるユーザ認証を行うことができ、更にその認証結果をアプリケーション207から得ることができる。即ち、アプリケーション208は、ログサービス206に対してユーザ認証を要求するはない。このユーザ認証は、アプリケーション207が属するドメイン名を含むユーザ名、又は含まないユーザ名と、パスワードとの組み合わせによって実行されるものとしてもよい。また、ユーザ認証は、機器に装着された外部認証装置を介したICカードや指紋虹彩認証等のバイオメトリクスによる認証によって行われてもよい。なお、アプリケーション208がログサービス206に対してアクセス要求したAPIには、この認証結果を引き渡すことができる事としてもよいし、別のAPIで引き渡す事としてもよい。何れの場合も、ログサービス206は、この認証結果を、ユーザ権限確認用APIを介してアプリケーション207に対して引渡すステップ408。そして、アプリケーション207は、ログ領域302へのアクセス権限が、認証結果に示されるユーザに存在するかどうかを判断してその結果をログサービス206へ返却するステップ409。その結果を以って、ログサービス206は、アプリケーション208を操作しているユーザの認証結果が、ログ領域302にアクセスする権限を有するかどうか判定するステップ410。ログサービス206は、ログ領域302へのアクセスが認められない場合はアクセスを拒絶する結果をアプリケーション208に対して返却するステップ412。ログサービス206は、ログ領域302へのアクセスが認められる場合はアクセス許可される結果をアプリケーション208に対して返却するステップ411。ここで示される結果とは、アプリケーション208を介して、認証されたユーザによってログ領域302へのアクセスが許可されるかどうかを決し、次のような行為に帰結する。即ち、アプリケーション207に対して認証されたユーザが、アプリケーション207内の管理者と判定されれば、そのユーザは管理者権限を有するとみなされる。またアプリケーション207が管理者とみなすユーザは、アプリケーション207が保有するログ領域302へのアクセスを認められる。しかし、認証されたユーザがアプリケーション207に対する一般ユーザであれば、認められない。こうして返却された結果は、引き続いてAPIを介してログサービス206に対するログ領域302を介する場合にもパラメータとして指定されることが求められる。即ちAPIの引数に認証結果情報が含まれる場合のみ、そのAPIはログ領域302へのアクセスを許容して処理を行う。以上、ステップ401からステップ412までの処理によって、ログサービス206は、以下のことができる。つまり、アプリケーション207がログサービス206の管理下で保持するログ領域302へのアプリケーション208からのアクセス要求に対して、予めログ領域302に設定したアプリケーションのパーミッションによるアクセス制御を行うことができる。つまり、ログサービス206は、アプリケーション207の管理するユーザ権限に基づくログ領域302へのアクセスの判断を、アプリケーション207にすべて委任することができる。言い換えればログサービス206はアプリケーション207のログ領域302を管理しているにも関わらず、ログ領域302へのアクセス制御は、アプリケーション207の定めるアクセス制御方法に則ることができる。図6は、ログ又はログ領域に対するアクセス制御の処理を、ソフトウェア構成を用いて説明するための図である。SQ1において、ログサービス206は、例えば、セキュリティドメインAに属するアプリケーション207より、APIを介してログ領域302の確保要求を受信する。また、ログサービス206は、セキュリティドメインAに属するアプリケーション207より、ログ領域のユーザ権限確認用のAPIとアプリケーションパーミッションAとを含む登録要求も受信する。セキュリティドメインAは、第一のセキュリティドメインの一例である。セキュリティドメインBは、第二のセキュリティドメインの一例である。すると、SQ2において、ログサービス206は、管理するログ領域全体301内にログ領域302を確保すると共に、ログ領域302と関連付けて、アプリケーションパーミッションAとユーザ権限確認用のAPIとをHDD107上にファイルとして記録する。SQ3において、ログサービス206は、例えば、セキュリティドメインA及びセキュリティドメインBに属するアプリケーション208より、ログ領域302に記録されたログ又はログ領域に対するアクセス要求を受信する。SQ4において、ログサービス206は、前記ファイルに記録された情報に基づいて、ログ領域302に対してアプリケーションパーミッションが設定されているかどうかを検証する。アプリケーションパーミッションが設定されていた場合、SQ5において、ログサービス206は、アクセス要求を送信してきたアプリケーション208がログ領域302に設定されていたアプリケーションパーミッションAを保有しているかどうかを検証する。なお、ログサービス206は、上述したように、Java実行環境204のパーミッションチェック機構を介して、前記検証を行う。アプリケーションパーミッションAを保有していた場合、SQ6において、ログサービス206は、ログ領域302に関連付けてユーザ権限確認用APIがファイル等に登録されているかどうかを確認する。ログ領域302に関連付けてユーザ権限確認用APIがファイル等に登録されていた場合、SQ7において、ログサービス206は、上述した認証結果を、ユーザ権限確認用APIを介してアプリケーション207に対して引渡す。SQ8において、ログサービス206は、アプリケーション207より、ログ領域302へのアクセス権限が、認証結果に示されるユーザに存在するかどうかの判断結果を受け取る。SQ9において、ログサービス206は、アプリケーション207から受け取った判断結果を検証し、ログ領域302へのアクセスを認めるかどうかを確認する。例えば、ログサービス206は、アプリケーション207から受け取った判断結果がログ領域302へのアクセス権限が、認証結果に示されるユーザに存在することを示していた場合、ログ領域302へのアクセスを認める。一方、ログサービス206は、アプリケーション207から受け取った判断結果がログ領域302へのアクセス権限が、認証結果に示されるユーザに存在しないことを示していた場合、ログ領域302へのアクセスを認めない。SQ10において、ログサービス206は、アプリケーション208に対して、ログ領域302へのアクセスを許可するか否かを示す結果を返却する。なお、本実施形態では、アクセスを許可するか否かを示す結果を返却したが、アクセスを認めることを確認したことに応じて、ログサービス206がログ領域302のログをSQ10の返答時点でアプリケーション208に対して送信してもよい。上述したように、ログサービス206は、アプリケーション207やアプリケーション208が属するセキュリティドメインに属していないため、アプリケーション208からのアプリケーション207のログ領域302へのアクセスを許可するか否かの判断を行うことができない。しかしながら、ログサービス206が、図6等に示したような処理を行うことによって、アプリケーション208からのアプリケーション207のログ領域302へのアクセス制御を可能としている。<その他の実施形態>また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェアプログラムを、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ又はCPUやMPU等がプログラムを読み出して実行する処理である。以上、上述した各実施形態によれば、複数のアプリケーションのリソースを一元的に管理するサービスによる、第一のアプリケーションのリソースに対する第二のアプリケーションからのアクセス制御を可能とすることができる。なお、上述した実施形態では、リソースの一例として、ログ、又はログ領域を例に説明を行ったがこのことは実施形態を限定するものではない。以上、本発明の好ましい実施形態について詳述したが、本発明は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形変更が可能である。