JP2004348437A - リソース管理装置、リソース管理方法及び記録媒体 - Google Patents
リソース管理装置、リソース管理方法及び記録媒体 Download PDFInfo
- Publication number
- JP2004348437A JP2004348437A JP2003144776A JP2003144776A JP2004348437A JP 2004348437 A JP2004348437 A JP 2004348437A JP 2003144776 A JP2003144776 A JP 2003144776A JP 2003144776 A JP2003144776 A JP 2003144776A JP 2004348437 A JP2004348437 A JP 2004348437A
- Authority
- JP
- Japan
- Prior art keywords
- function
- module
- resource
- media
- resources
- 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.)
- Pending
Links
Images
Classifications
-
- 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/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
- G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
-
- 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/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2209/00—Indexing scheme relating to G06F9/00
- G06F2209/50—Indexing scheme relating to G06F9/50
- G06F2209/504—Resource capping
-
- G—PHYSICS
- G11—INFORMATION STORAGE
- G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
- G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
- G11B20/10—Digital recording or reproducing
- G11B20/10527—Audio or video recording; Data buffering arrangements
- G11B2020/10537—Audio or video recording
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Abstract
【課題】複数のメディア処理を効率良く並行して行なうリソース管理装置及びリソース管理方法を提供する。
【解決手段】リソース管理装置は、アプリケーションプロセッサ１０１と、それぞれ基本機能と拡張機能とを有する機能モジュール、輻輳解析部２２２、データベース部２２１及びシステム管理部２２０を有しているメディア処理プロセッサ１０２とを備えている。ユーザからの機能追加要求に際して輻輳が検出される場合、輻輳解析部２２２が拡張機能の中から削除対象候補を選択し、該拡張機能を削除した後要求された機能を追加する。これにより、拡張リソースから基本リソースに優先的にリソースが割当てられることができるので、リソースを効率的に使用することができる。
【選択図】 図１
【解決手段】リソース管理装置は、アプリケーションプロセッサ１０１と、それぞれ基本機能と拡張機能とを有する機能モジュール、輻輳解析部２２２、データベース部２２１及びシステム管理部２２０を有しているメディア処理プロセッサ１０２とを備えている。ユーザからの機能追加要求に際して輻輳が検出される場合、輻輳解析部２２２が拡張機能の中から削除対象候補を選択し、該拡張機能を削除した後要求された機能を追加する。これにより、拡張リソースから基本リソースに優先的にリソースが割当てられることができるので、リソースを効率的に使用することができる。
【選択図】 図１
Description
【０００１】
【発明の属する技術分野】
本発明は、メディア処理を行うメディア処理プロセッサにおいて、複数のメディアモジュールの同時実行を可能にするリソース管理装置及びリソース管理方法に関する。
【０００２】
【従来の技術】
従来、メディア処理のリソース管理方法として、各メディア処理で使用するリソースの最大値を予め定義しておき、メディア処理の実行時には、定義した最大値分のリソースを確保することによりリアルタイム性を保証する方法があった。この方法では、定義した最大値を越えないようにリソース割当てを制御することで複数のメディア処理の同時実行を実現していた。このような技術は、例えば特許文献１に開示されている。
【０００３】
【特許文献１】
特開平１０−２８９１１５号公報（第１図）
【０００４】
【発明が解決しようとする課題】
しかしながら、単一のメディア処理プロセッサにおいて処理するメディアの種類が増え、かつ、複数のメディア処理を同時に行う必要性が増加しているため、リソースが不足した場合に、メディア処理が使用するリソースを最適に配分することによりメディア処理の並列度を向上させる重要性が近年、より一層高まっている。
【０００５】
従来の技術は、複数のメディア処理を同時に行う場合において、メディア処理プロセッサ内リソースの最適配分を考慮したものではなく、各メディア処理ごとに常に一定量のリソースを必要としていた。このため、配分されたメディアプロセッサ内のリソースに無駄が生じ、リソースを効率的に配分することができなかった。
【０００６】
本発明は、上述の課題を解決するためになされたものであり、より多くのメディアモジュールの同時実行を可能にするメディア処理方法を提供することを目的としている。
【０００７】
【課題を解決するための手段】
本発明のリソース管理装置は、メディア処理を行なうためのメディアモジュールと、機能追加要求に際し、リソースの輻輳を生じる場合に、上記メディアモジュールの機能情報と上記メディア処理機能についてのリソース情報とを含むモジュール情報と、上記メディア処理機能の起動状態を示すモジュール状態情報とを参照してリソース配分を変更する輻輳解析部と、上記輻輳解析部が変更したリソース配分に従い、リソースの確保及び解放を行なうシステム管理部とを有するメディア処理プロセッサを備えている。
【０００８】
これにより、リソース輻輳時には、輻輳解析部が起動中の機能を削除してリソースの有効利用を図ることができるので、複数のメディア処理を並列して行なうことができる。
【０００９】
ここで、上記モジュール情報と上記モジュール状態情報とを格納するデータベース部をさらに備えていることが好ましい。
【００１０】
上記メディア処理機能は、メディア処理に必須な基本機能と、付加的な機能である拡張機能とに分かれており、機能追加要求に際し、リソースの輻輳が生じる場合に、上記輻輳解析部は、起動中の上記拡張機能を削除してから追加要求のあった機能を起動させることにより、リソースを有効に配分して遅滞なくメディア処理を行なうことができる。
【００１１】
上記メディアモジュールは複数存在し、上記モジュール情報は、メディアモジュール別優先度を含んでおり、上記メディア処理プロセッサは、リソースの輻輳を生じる場合に、上記メディアモジュール別優先度の低い上記メディアモジュールから順に削除対象として決定するためのモジュール決定部をさらに有していることにより、例えば使用頻度の低いメディア処理内の機能から削除して追加要求のあった機能を起動させることができるので、リソースを効率的に配分するとともに、処理のオーバーヘッドを低減してユーザの要求に対する応答速度を向上させることができる。
【００１２】
上記モジュール情報は、上記拡張機能についての機能別優先度を含んでおり、上記メディア処理プロセッサは、リソースの輻輳を生じる場合に、上記機能別優先度の低い上記拡張機能から順に削除対象として決定するための機能決定部をさらに有していることにより、優先度の低い拡張機能に使用されていたリソースを追加要求のあった機能に配分することができる、且つ、ユーザの要求に対する応答速度をより向上させることができる。
【００１３】
上記メディア処理プロセッサは、リソースの輻輳を生じる場合に、起動中の複数の上記拡張機能の削除を上記メディアモジュールに問い合わせ、且つ、少なくとも最初に応答した上記メディアモジュールの上記拡張機能の削除を決定するための応答処理部をさらに有していることにより、ユーザの要求に対する応答速度を向上させることができる。
【００１４】
本発明のリソース管理方法は、拡張機能と、メディア処理に必須な基本機能とに分けられたメディア処理を行なうためのメディアモジュールと、輻輳解析部と、システム管理部とを有するメディア処理プロセッサを備えたリソース管理装置を用いたリソース管理方法であって、機能追加要求に際し、リソースの輻輳を生じる場合に、上記メディアモジュールの機能情報と上記メディア処理機能についてのリソース情報とを含むモジュール情報と、上記メディア処理機能の起動状態を示すモジュール状態情報とを参照して上記輻輳解析部がリソース配分を変更するステップ（ａ）と、上記ステップ（ａ）で上記輻輳解析部が変更したリソース配分に従い、上記システム管理部がリソースの確保及び解放を行なうステップ（ｂ）とを含んでいる。
【００１５】
この方法により、リソース輻輳時に輻輳解析部がリソースの配分を適宜再配分するので、リソースの有効利用が図られ、結果として複数のメディア処理を並列して行なうことが可能となる。
【００１６】
上記ステップ（ａ）は、上記輻輳解析部が、追加要求された機能が必要とするリソース量と空きリソース量とを比較するステップ（ａ１）と、上記ステップ（ａ１）で、空きリソース量が追加要求された機能が必要とするリソース量より少ない場合に、上記輻輳解析部が、上記拡張機能のうちから起動中の機能の削除を問い合わせるステップ（ａ２）とを含んでいることにより、リソースの有効利用が図られる。
【００１７】
上記メディアモジュールは複数存在し、上記モジュール情報は、メディアモジュール別優先度を含んでおり、上記メディア処理プロセッサはモジュール決定部をさらに有しており、上記ステップ（ａ）は、上記輻輳解析部が、追加要求された機能が必要とするリソース量と空きリソース量とを比較するステップ（ａ１）と、上記ステップ（ａ１）で、空きリソース量が追加要求された機能が必要とするリソース量より少ない場合に、上記モジュール決定部が、上記メディアモジュール別優先度の低い上記メディアモジュールから順に削除対象として決定するステップ（ａ３）と、上記輻輳解析部が、上記ステップ（ａ３）で決定された上記メディアモジュールのうち、起動中の上記拡張機能の削除を問い合わせるステップ（ａ４）とを含んでいることにより、リソース輻輳時には、優先度の低いモジュールの機能から削除されるので、リソースを効率的に配分すると同時に、処理のオーバーヘッドを低減し、ユーザの要求に対するレスポンスを向上させることができる。
【００１８】
上記モジュール情報は、上記拡張機能についての機能別優先度を含んでおり、上記メディア処理プロセッサは、機能決定部をさらに有しており、上記ステップ（ａ）は、上記輻輳解析部が、追加要求された機能が必要とするリソース量と空きリソース量とを比較するステップ（ａ１）と、上記ステップ（ａ１）で、空きリソース量が追加要求された機能が必要とするリソース量より少ない場合に、上記機能決定部が、上記機能別優先度の低い起動中の上記拡張機能から順に削除対象として決定するステップ（ａ５）と、上記輻輳解析部が、上記ステップ（ａ５）で決定された上記拡張機能の削除を問い合わせるステップ（ａ６）とを含んでいることにより、優先度の低い機能から順に削除することができるので、リソースの有効利用を図りつつ、ユーザの要求に対するレスポンスの向上も併せて図ることができる。
【００１９】
上記メディア処理プロセッサは応答処理部をさらに有しており、上記ステップ（ａ）は、上記輻輳解析部が、追加要求された機能が必要とするリソース量と空きリソース量とを比較するステップ（ａ１）と、上記ステップ（ａ１）で、空きリソース量が追加要求された機能が必要とするリソース量より少ない場合に、上記輻輳解析部が、起動中の複数の上記拡張機能の削除を上記メディアモジュールに問い合わせるステップ（ａ７）と、上記ステップ（ａ７）の後、上記応答処理部が、少なくとも最初に応答した上記メディアモジュールの上記拡張機能の削除を決定するステップ（ａ８）と、上記ステップ（ａ８）の後に応答した上記メディアモジュールに対しては、上記応答処理部がキャンセルを送信するステップ（ａ９）とを含んでいることにより、応答速度にばらつきがある複数のメディアモジュールがある場合でも、ユーザの要求に対する応答速度を向上させることができる。
【００２０】
本発明の記録媒体は、機能追加要求に際し、リソースの輻輳を生じる場合に、上記メディアモジュールの機能情報と上記メディア処理機能についてのリソース情報とを含むモジュール情報と、上記メディア処理機能の起動状態を示すモジュール状態情報とを参照してリソース配分を変更するステップ（ａ）と、上記ステップ（ａ）で変更したリソース配分に従い、リソースの確保及び解放を行なうステップ（ｂ）とをコンピュータに実行させるためのプログラムを記録したコンピュータ読み取り取り可能な記録媒体である。
【００２１】
これにより、コンピュータを用いて複数のメディア処理を並行して行なうことが可能となる。
【００２２】
【発明の実施の形態】
以下、本発明の実施形態について、図面を用いて詳細に説明する。
【００２３】
（第１の実施形態）
図１は、本発明の第１の実施形態に係るリソース管理装置の構成例を示すブロック図である。同図に示すように、本実施形態のリソース管理装置１００は、ＣＰＵ（アプリケーション処理プロセッサ）１０１（以下、アプリケーション処理プロセッサ１０１と表記する）と、ＣＰＵ（メディア処理プロセッサ）１０２（以下、メディア処理プロセッサ１０２と表記する）と、蓄積メディア１５０と、メモリ１５１と、キーデバイス１６０と、カメラ１６１と、ＬＣＤ１６２と、スピーカ１６３と、マイク１６４と、ベースバンド・プロセッサ１６５とを備えている。
【００２４】
また、アプリケーション処理プロセッサ１０１は、ユーザからの要求に応じてメディアモジュールを制御してメディア処理を行うための各種アプリケーションを備える。本実施形態では、アプリケーション処理プロセッサ１０１は、メインアプリケーション１０３と、静止画処理アプリケーション１１０と、ＡＶ再生アプリケーション１１１と、音声通話アプリケーション１１２とを備えている。
【００２５】
そして、メディア処理プロセッサ１０２は、例えば１６０ＭＨｚで動作するプロセッサで、アプリケーションからの制御によりメディア処理を行う各種メディアモジュールを備える。本実施形態では、メディア処理プロセッサ１０２は、メディアモジュールとして静止画処理モジュール１１３と、ＡＶ再生モジュール１１４と、音声通話モジュール１１５とを備えている。さらに、メディア処理プロセッサ１０２は、システム管理部２２０と輻輳解析部２２２とを備えている。このシステム管理部２２０と輻輳解析部２２２が本実施形態のリソース管理装置の特徴部分であり、後で詳細に説明する。
【００２６】
以上のようなアプリケーションやモジュールは、実際には目的の処理を行なうためのソフトウェアの集合であるが、ハードウェアで構成されていても構わない。
【００２７】
各メディアモジュールはメディア処理プロセッサ１０２からメディア処理に必要なプロセッサリソース（以下、ＣＰＵリソースと表記する）を割当ててもらうことにより、メディア処理を行うことができる。例えばＡＶ再生モジュール１１４がＡＶ再生を行うためには、最大５２ＭＨｚのＣＰＵリソースが必要である。
【００２８】
蓄積メディア１５０は、メディアモジュールによって処理されるメディアデータ、例えばＡＶ再生モジュール１１４によって処理される音楽／音声データと動画データが多重化されたＭＰＥＧ４データなどを保持するための不揮発性メモリである。
【００２９】
メモリ１５１は、アプリケーション処理プロセッサ１０１上で動作する各アプリケーションのプログラムと、メディア処理プロセッサ１０２上で動作する各メディアモジュールのプログラムと、データベース部２２１とを保持するための不揮発性メモリである。さらにメモリ１５１は、メディアモジュールの実行領域として例えば５１２ｋＢのメモリサイズを含んでいる。データベース部２２１については、後で詳細に説明する。
【００３０】
また、メディアモジュールは、メモリ１５１からメディア処理に必要な領域（以下、メモリリソースと表記する）を割当ててもらうことにより、メディア処理を行うことができる。例えば音声通話モジュール１１５が音声通話を行うためには、最大１２４ＫＢのメモリリソースが必要である。
【００３１】
キーデバイス１６０は、ユーザからのキー入力（図１の信号（１））を受け付け、その内容をメインアプリケーション１０３に送信し（図１の信号（２））、メインアプリケーション１０３が、静止画処理アプリケーション１１０と、ＡＶ再生アプリケーション１１１と、音声通話アプリケーション１１２のそれぞれに制御信号を送信する（図１の信号（３））。
【００３２】
カメラ１６１は、画像データのビデオ信号を入力し、その画像データをＬＣＤ１６２や静止画処理モジュール１１３へ出力する。
【００３３】
ＬＣＤ１６２は、カメラ１６１やＡＶ再生モジュール１１４から受け取った画像データのビデオ信号を出力する（図１の信号（１１））。このデバイスは複数のメディアモジュールから共有することが可能である。
【００３４】
スピーカ１６３は、ＡＶ再生モジュール１１４や音声通話モジュール１１５から受け取った音楽／音声データのオーディオ信号を出力する（図１の信号（１２））。このデバイスは複数のメディアモジュールから共有することが可能である。
【００３５】
マイク１６４は、音声データの音声信号を入力し、その音声データを音声通話モジュール１１５へ出力する。
【００３６】
ベースバンド・プロセッサ１６５は、例えばＷ−ＣＤＭＡ方式によって他の装置との通信を行うためのプロセッサであり、受信した音声データを音声通話モジュール１１５へ出力する。また、音声通話モジュール１１５から入力された音声データを他の装置へ送信する。
【００３７】
メインアプリケーション１０３は、キーデバイス１６０から受け取ったユーザからの制御信号（図１の信号（２））を適切なアプリケーションに送信する（図１の信号（３））ことで、各アプリケーションを制御する。
【００３８】
静止画処理アプリケーション１１０は、メインアプリケーション１０３を介してキーデバイス１６０からの指示を受け、静止画処理モジュール１１３へ静止画処理制御要求、例えば静止画撮影開始要求や静止画表示要求を制御信号として送信し、その応答を制御信号として受信する。
【００３９】
ＡＶ再生アプリケーション１１１は、メインアプリケーション１０３を介してキーデバイス１６０から伝達された指示（図１の信号（３））に応じて、ＡＶ再生モジュール１１４へＡＶ再生制御要求、例えばＡＶ再生開始要求や輪郭強調などの画質調整処理開始要求を制御信号として送信し、且つその応答を制御信号として受信する（図１の信号（４）、（５））。さらに、ＡＶ再生アプリケーション１１１は、ＡＶ再生処理動作中に蓄積メディア１５０からＭＰＥＧ４などのストリームデータを取り出し（図１の信号（６））、それを多重分離処理した音楽／音声データと動画データとをＡＶ再生モジュール１１４へ出力する（図１の信号（７）及び信号（８））。
【００４０】
音声通話アプリケーション１１２は、メインアプリケーション１０３を介してキーデバイス１６０から受信したユーザの指示に応じて、音声通話モジュール１１５へ音声通話制御要求、例えば音声通話開始要求や音量設定要求を制御信号として送信し、その応答を制御信号として受信する。
【００４１】
静止画処理モジュール１１３は、静止画処理アプリケーション１１０からの静止画撮影開始要求の制御信号を受信することで静止画撮影を開始する。静止画処理モジュール１１３は、カメラ１６１から受け取った静止画データを、例えばＪＰＥＧデータに符号化し蓄積メディア１５０へ出力する。また、静止画処理モジュール１１３は、静止画処理アプリケーション１１０から要求を受けると、その度に応答の制御信号を返す。
【００４２】
ＡＶ再生モジュール１１４は、ＡＶ再生アプリケーション１１１からＡＶ再生開始要求の制御信号を受信する（図１の信号（４））ことでＡＶ再生を開始する。ＡＶ再生モジュール１１４は、ＡＶ再生アプリケーション１１１から受け取った音楽／音声データ（図１の信号（８））、例えばＡＡＣ（Ａｄｖａｎｃｅｄ Ａｕｄｉｏ Ｃｏｄｉｎｇ）データを復号化してスピーカ１６３へ出力し（図１の信号（１０））、これと同時に、受け取った動画データ（図１の信号（７））、例えばＭＰＥＧ４データを復号化し音楽／音声データと同期してＬＣＤ１６２へ出力する（図１の信号（９））。また、ＡＶ再生モジュール１１４は、ＡＶ再生アプリケーション１１１から要求を受けると、その度に応答の制御信号を返す（図１の信号（５））。
【００４３】
音声通話モジュール１１５は、音声通話アプリケーション１１２から音声通話開始要求の制御信号を受信することで音声通話を開始する。音声通話モジュール１１５は、ベースバンド・プロセッサ１６５から取得した音声データ、例えばＡＭＲデータを復号化してスピーカ１６３へ出力し、これと同時にマイク１６４から取得した音声データを符号化しベースバンド・プロセッサ１６５へ出力することにより音声通話を行う。また、音声通話モジュール１１５は、音声通話アプリケーション１１２から要求を受けると、その度に応答の制御信号を返す。
【００４４】
図２及び図３は、それぞれ本実施形態のリソース管理装置のうち、アプリケーション処理プロセッサ及びメディア処理プロセッサの構成を詳細に示すブロック図である。これらの図を用いてメディア処理プロセッサについてさらに説明する。
【００４５】
メディアモジュールは、アプリケーションを通じてユーザからの機能開始要求を受け取り、それに従って輻輳解析部２２２へ機能追加要求を制御信号として送信する。また、その機能追加要求に対する輻輳解析部２２２からの応答を、機能追加応答、あるいは機能追加キャンセルを制御信号として受信する。例えば、音声通話モジュール１１５は、音声通話アプリケーション１１２からの音声通話開始要求（図２の信号（３））に従って、輻輳解析部２２２へ音声通話機能追加要求を送信する（図２の信号（４））。そして、音声通話モジュール１１５は、輻輳解析部２２２からの機能追加応答を受信して、音声通話アプリケーション１１２へ音声通話開始応答を送信する。
【００４６】
さらに、リソース不足時（以下、リソース輻輳時と表記する）には、メディアモジュールは輻輳解析部２２２からの機能削除問合せを制御信号として受信し、その削除問合せに対し、削除応答あるいはキャンセル応答を制御信号として送信する。メディアモジュールは、必要ならばその機能削除処理をアプリケーションへ制御信号として転送し、その応答を制御信号として受信することにより、アプリケーションに任せることができる。例えば、ＡＶ再生モジュール１１４は、輻輳解析部２２２から起動している動画編集機能の削除問合せを受信すると、ＡＶ再生アプリケーション１１２へ動画編集終了問合せを行う。そして、ＡＶ再生モジュール１１４は、ＡＶ再生アプリケーション１１２からその応答である動画編集終了要求（図３の信号（１））を受信すると、動画編集機能終了処理を行い、削除応答を輻輳解析部２２２へ送信する（図３の信号（２））。
【００４７】
システム管理部２２０は、輻輳解析部２２２からのリソース確保要求、及びリソース解放要求を制御信号として受信し、その要求に従ってメディアモジュールが使用する各リソース、ＣＰＵリソースと、メモリリソースと、カメラ１６１、ＬＣＤ１６２、スピーカ１６３、マイク１６４、ベースバンド・プロセッサ１６５の各デバイスの確保と解放を行う。さらに、システム管理部２２０は、各リソースの使用状況を算出し、その結果を制御信号として輻輳解析部２２２に出力する。
【００４８】
データベース部２２１は、図１に示すようにメモリ１５１内に存在し、各メディアモジュールをサポートする機能情報と、各機能を実行するとき必要なリソース情報とを、モジュール情報として保持している。
【００４９】
ここで、機能情報は、基本機能と拡張機能とから構成され、リソース情報はＣＰＵ演算量、メモリから確保した領域サイズ、使用するデバイスの列挙などから構成されている。
【００５０】
基本機能とはメディアモジュールのプリミティブな機能であり、当該メディアモジュールに最低限必要とされる機能を含む。これに対し、拡張機能とは基本機能に付随する機能である。音声通話モジュール１１５では基本機能として音声通話機能を持ち、拡張機能として音声メモ録音機能と、音声メモ再生機能とを持つ。また、ＡＶ再生モジュール１１４では基本機能としてＡＶ再生機能を持ち、拡張機能としてグラッフィクスとの合成などの動画編集機能と、輪郭強調などの画質調整機能などを持つ。
【００５１】
さらに、データベース部２２１は、起動したメディアモジュールとその中で使用中の機能についてのモジュール状態情報を保持している。
【００５２】
図４は、本実施形態のリソース管理方法において、データベース部２２１に格納されるモジュール情報の一例を示す図である。モジュール情報は、以下の項目を含む。
【００５３】
（１）メディアモジュール名
（２）機能情報
（ア）サポートする機能
（イ）機能分類。上述の基本機能と拡張機能とに分類される。
【００５４】
（３）リソース情報
（ア）ＣＰＵ演算量（ＭＨｚ）。メディアモジュールがこの機能を実現するために必要なＣＰＵリソースの量である。
【００５５】
（イ）メモリサイズ（ＫＢ）。メディアモジュールがこの機能を実現するために必要な命令及びデータを保持するのに必要なメモリリソースの量である。
【００５６】
（ウ）使用デバイス。メディアモジュールがメディア処理に必要なデバイスである。複数のデバイスを列挙することができる。また、デバイスには共有可能なデバイスがある。
【００５７】
本実施形態のリソース管理装置では、データベース部２２１には、静止画処理モジュール１１３と、ＡＶ再生モジュール１１４と、音声通話モジュール１１５に関するモジュール情報が保持されている。ＡＶ再生モジュール１１４のモジュール情報に含まれる機能情報には基本機能としてＡＶ再生機能があり、拡張機能として動画編集機能と、画質調整機能と、イコライズ機能が設定されている。さらに、リソース情報としてＡＶ再生には、最大５２ＭＨｚのＣＰＵリソースと最大２２６ＫＢのメモリリソースが必要で、ＬＣＤ１６２とスピーカ１６３の各デバイスを使用することが設定されている。
【００５８】
図５は、本実施形態のメディア処理方法において、データベース部２２１に格納されるモジュール状態情報の一例を示す図である。モジュール状態情報は、次の項目を含む。
【００５９】
（１）起動したメディアモジュール名
（２）起動した機能名
本実施形態のリソース管理装置では、静止画処理モジュール１１３と、ＡＶ再生モジュール１１４と、音声通話モジュール１１５に関するモジュール状態情報が保持されている。図５に示す例では、ＡＶ再生モジュール１１４のＡＶ再生機能、動画編集機能、及び画質調整機能が起動され、使用可能であることが設定されている。
【００６０】
輻輳解析部２２２は、メディアモジュールから機能追加要求を制御信号として受信し、機能追加要求に含まれるメディアモジュール名と機能をキーとしてデータベース部２２１から対応するリソース情報を取得し、同時に、システム管理部２２０から現在のリソース使用状況を取得することによりリソースの輻輳を解析する。
【００６１】
リソースの輻輳がない場合、輻輳解析部２２２は、追加要求されている機能にリソースを割り当てるためシステム管理部２２０にリソースの確保を要求し、データベース部２２１内のモジュール状態情報を更新する。そして、輻輳解析部２２２はまた、リソース確保の要求に対する結果をメディアモジュールに応答する。
【００６２】
一方、輻輳解析部２２２はリソースの輻輳がある場合、削除対象候補になった拡張機能を保持するメディアモジュールに機能削除問合せを行う。そして、問合せ結果が削除応答であれば、その機能が確保しているリソースを解放するようにシステム管理部２２０に要求し、その後、要求された機能を追加するためにリソース割当てを要求する。このように、データベース部２２１のモジュール状態情報を更新し、メディアモジュールに応答する。
【００６３】
次に、本実施形態のメディア処理方法におけるリソース輻輳時の処理の流れを説明する。
【００６４】
図６は、本実施形態のメディア処理方法において、リソース輻輳時の処理の流れを示すフローチャート図である。輻輳の解析、拡張機能の削除、要求された機能の追加の各処理の流れを以下に説明する。
【００６５】
まず、ステップＳ６０１で、輻輳解析部２２２はメディアモジュールから機能追加要求を受信し、その機能追加要求に含まれるモジュール名と拡張機能とをキーとして、データベース部２２１のモジュール情報から追加する機能についてのリソース情報を取得する。
【００６６】
次に、ステップＳ６０２で、システム管理部２２０から現在のリソース使用状況を取得する。本ステップでは、ＣＰＵ及びメモリのリソース使用状況、及びデバイスの使用状況についての情報を取得する。
【００６７】
これに続くステップＳ６０３では、上述のステップＳ６０１及びＳ６０２で取得したリソース情報から、ＣＰＵと、メモリと、デバイスのそれぞれに関して追加要求された機能が必要なリソース量と空きリソース量とを輻輳解析部２２２が比較する。本ステップで追加機能が必要とするリソース量より空きリソース量の方が多い場合（本ステップでＹｅｓの場合）、ステップＳ６０４へ移行する。空きリソースが十分でない場合（本ステップでＮｏの場合）、ステップＳ６０６へ移行する。
【００６８】
次に、ステップＳ６０４では、先にステップＳ６０１で取得したリソース情報をもとに、輻輳解析部２２２が、システム管理部２２０にＣＰＵと、メモリと、デバイスのそれぞれに関してリソースを確保するように要求する。
【００６９】
そして、ステップＳ６０５では、ステップＳ６０４で追加した機能の状態を登録するためデータベース部２２１のモジュール状態情報を変更し、機能追加要求を送信したメディアモジュールに対して輻輳解析部２２２が機能追加応答を送信する。この時、後述するステップＳ６１２で拡張機能を削除した場合には、この機能の状態もデータベース部２２１のモジュール状態情報に登録する。
【００７０】
一方、ステップＳ６０３で追加要求された機能が必要とするリソースを確保できない場合には、輻輳解析部２２２は、起動している拡張機能の中から削除対象候補となる拡張機能を決定するため、起動しているメディアモジュールを検索する。そして、選択されたメディアモジュールの中から起動している拡張機能を検索し、削除対象候補になりうる拡張機能を検出する。以下にこの手順を示す。
【００７１】
まず、ステップＳ６０６で、データベース部２２１に格納されているモジュール状態情報の先頭から順に起動しているメディアモジュールを検索し、見つかった場合（本ステップでＹｅｓの場合）には、ステップＳ６０７へ移行する。モジュール状態情報のレコードの中から起動しているメディアモジュールが見つからない場合（本ステップでＮｏの場合）、選択されたメディアモジュール内には、削除可能な拡張機能が見つからなかったとして、ステップＳ６１３へ移行する。
【００７２】
次に、ステップＳ６０７では、先のステップＳ６０６で選択されたメディアモジュールにおいて、起動している拡張機能の中から削除すべき拡張機能を一つ決定するために、選択されたメディアモジュールに相当するモジュール状態情報のレコードを、輻輳解析部２２２が先頭から順に検索する。その結果、モジュール状態情報から起動している拡張機能が見つかった場合（本ステップでＹｅｓの場合）、ステップＳ６０８へ移行する。モジュール状態情報のレコードから起動している拡張機能が見つからない場合（本ステップでＮｏの場合）には、選択されたメディアモジュールから削除可能な拡張機能が見つからなかったとして、上述のステップＳ６０６へ移行し処理を繰り返す。
【００７３】
次いで、ステップＳ６０８では、先のステップＳ６０７で選択された拡張機能のリソース情報をデータベース部２２１から取得する。
【００７４】
次に、ステップＳ６０９では、上述のステップＳ６０１、Ｓ６０２、Ｓ６０８でそれぞれ取得したリソース情報から、ＣＰＵと、メモリと、デバイスのそれぞれに関して、追加要求機能が必要なリソース量と、拡張機能が確保しているリソース量と空きリソース量との和を比較する。追加機能が必要とするリソース量に比べて、空きリソース量と選択された拡張機能が確保しているリソース量との和が多い場合（本ステップでＹｅｓの場合）、削除対象候補となる拡張機能が決定し、ステップＳ６１０へ移行する。ここで、１つの拡張機能のみでは追加機能に必要なリソース量を確保できない場合、２つ以上の拡張機能を削除対象としてもよい。一方、追加機能が必要とするリソースが確保できない場合（本ステップでＮｏの場合）、選択された拡張機能は、削除対象候補ではない、として上述のステップＳ６０７へ移行し処理を繰り返す。
【００７５】
続いて、ステップＳ６１０では、上述のステップＳ６０６で選択されたメディアモジュールに対して輻輳解析部２２２が機能削除問合せを行い、それに対する応答を待つ。
【００７６】
次に、ステップＳ６１１では、先のステップＳ６１０でメディアモジュールに対して行った機能削除問合せの応答を判定する。すなわち、機能削除問い合わせの応答が、削除応答である場合（本ステップでＹｅｓの場合）、その拡張機能が削除されることが決定しステップＳ６１２へ移行する。また、応答がキャンセルである場合（本ステップでＮｏの場合）、その拡張機能は削除できないことが決定し、上述のステップＳ６０７へ移行して処理を繰り返す。
【００７７】
次に、ステップＳ６１２で、輻輳解析部２２２は、削除決定した拡張機能を削除するために、上記ステップＳ６０８で取得したリソース情報をもとに、システム管理部２２０にＣＰＵと、メモリと、デバイスのそれぞれに関してリソースを解放するように要求する。そして、上述のステップＳ６０４へ移行する。
【００７８】
これに対し、ステップＳ６１３では、上述のステップＳ６０６で削除可能な拡張機能が見つからなかった場合、機能追加要求を送信したメディアモジュールに対して輻輳解析部２２２が機能追加キャンセルを送信する。以上の手順で輻輳解析は行われる。
【００７９】
次に、本実施形態のリソース管理装置における輻輳解析について、例を挙げて具体的に説明する。
【００８０】
図７は、本実施形態のリソース管理装置において、ＣＰＵのリソース占有率の変化を示す図である。特に、音声通話機能追加前と追加後のＣＰＵリソースの変化を示すために、時間Ａと時間Ｂの時点における各メディアモジュールのＣＰＵリソースの占有率について示している。
【００８１】
図５に示すように、ＡＶ再生モジュール１１４のＡＶ再生機能と、動画編集機能と、画質調整機能とが起動され使用可能である状態で、ユーザから音声通話アプリケーション１１２に音声通話要求があった場合（図２の信号（１）、（２））に、音声通話アプリケーション１１２は、音声通話モジュール１１５へ音声通話開始要求を送信する（図２の信号（３））。音声通話モジュール１１５はその要求を受けて輻輳解析部２２２へ音声通話機能追加要求を送信する（図２の信号（４））。
【００８２】
音声通話機能追加要求を受け取った輻輳解析部２２２は、その要求に含まれるメディアモジュール名と機能、すなわち音声通話モジュールと音声通話とをキーとして、図４に示すデータベース部２２１のモジュール情報から音声通話機能のリソース情報（ＣＰＵ演算量３４ＭＨｚ（ＣＰＵリソースの２１％に相当）とメモリサイズ１２４ＫＢが必要で、使用デバイスとしてスピーカ１６３とマイク１６４を使用）を取得する（図２の信号（５））。
【００８３】
これと同時に、システム管理部２２０から、ＣＰＵに関しては１６０ＭＨｚのリソースのうち、図７に示すようにＡＶ再生モジュール１１４がリソースの９０％を確保しており、１０％が未割当てであること、メモリに関しては５１２ＫＢのリソースのうち、図２に示すようにＡＶ再生モジュール１１４が４２４ＫＢを確保しており、８８ＫＢが未割当てであること、デバイスに関しては、図４に示すようにＡＶ再生モジュール１１４がＬＣＤ１６２とスピーカ１６３を使用しているというリソース使用状況を取得する（図２の信号（６））。なお、ＣＰＵに関するリソースの内訳は、ＡＶ再生が３３％の５２ＭＨｚ、動画編集が３５％の５６ＭＨｚ、画質調整が２２％の３５ＭＨｚである。
【００８４】
次に、輻輳解析部２２２は、ＣＰＵ、メモリ、デバイスについて追加要求機能の音声通話が必要とするリソース量と空きリソース量について比較する。比較の結果、ＣＰＵリソースについては２１％のリソース要求に対して１０％の空きリソースしかないため、輻輳していることを検出する。メモリリソースについても１２４ＫＢのリソース要求に対して、８８ＫＢの空きしかなく輻輳が検出される。さらに、デバイスリソースについては、スピーカ１６３がＡＶ再生モジュール１１４により使用中であるが、共有デバイスであるため輻輳は検出されない。よって、ＣＰＵリソースとメモリリソースから輻輳が検出されたため、リソースの輻輳が発生すると判定される。
【００８５】
輻輳解析部２２２は、輻輳を検出した場合、図５に示すデータベース部２２１のモジュール状態情報をもとに、起動されているメディアモジュールのモジュール情報を先頭から順に読み出す。この際には、モジュール情報のうち、起動されている拡張機能が確保しているリソース情報があるか否かを、モジュール情報の先頭から順に読み出す。
【００８６】
これにより、図４のモジュール情報からは、まずはじめにＡＶ再生モジュール１１４の動画編集機能のリソース情報（ＣＰＵ演算量５６ＭＨｚ（ＣＰＵリソースの３５％に相当）とメモリサイズ１５９ＫＢが必要）が読み出される（図２の信号（７））。
【００８７】
次に、輻輳解析部２２２は、ＣＰＵ、メモリ、デバイスについて追加要求機能の音声通話が必要とするリソース量と、動画編集機能を解放した場合のリソース量について比較する。比較の結果、ＣＰＵリソースについては２１％のリソース要求に対して３５％＋１０％＝４５％の空きリソースがあるため、さきほど検出されていた輻輳が検出されなくなる。また、メモリリソースについては１２４ＫＢのリソース要求にたいして１５９ＫＢ＋８８ＫＢ＝２４７ＫＢの空きリソースがあるため、さきほど輻輳が検出されていた輻輳が検出されなくなる。よって、リソースの輻輳が発生しないことが判定され、動画編集機能は削除対象候補になる。
【００８８】
続いて、輻輳解析部２２２は、削除対象候補である動画編集機能を保持するＡＶ再生モジュール１１４に動画編集機能の削除問合せを行う（図２の信号（８））。
【００８９】
動画編集機能の削除問合せを受け取ったＡＶ再生モジュール１１４は、動画編集機能を終了するために、ＡＶ再生アプリケーション１１１に動画編集終了問合せを行う（図２の信号（９））。
【００９０】
動画編集終了問合せを受け取ったＡＶ再生アプリケーション１１１は、動画編集を終了するために、動画編集終了要求をＡＶ再生モジュール１１４に送信する（図３の信号（１））。この時、必要ならばＧＵＩなどを通じてユーザに動画編集終了確認をおこなってもよい。
【００９１】
動画編集終了要求を受け取ったＡＶ再生モジュール１１４は、動画編集終了処理を行って、削除応答を輻輳解析部２２２に返す（図３の信号（２））。
【００９２】
削除応答を受け取った輻輳解析部２２２は、前に取得した動画編集機能のリソース情報をもとにシステム管理部２２０にリソースの解放を要求し、動画編集機能を削除する（図３の信号（３））。この時、図７に示すようにＡＶ再生モジュール１１４が確保しているＣＰＵリソースは、時点Ａの９０％から時点Ｂの５５％に減少する。また、メモリリソースについては、図３に示すように４２４ＫＢから２６５ＫＢに減少する。
【００９３】
リソース解放後、輻輳解析部２２２は、以前に取得した音声通話機能のリソース情報をもとにシステム管理部２２０にリソースの確保を要求し、音声通話機能を追加する（図３の信号（４））。この時、図７に示すように音声通話モジュール１１５が確保しているＣＰＵリソースは、時間Ａでの０％から時間Ｂでの２１％に増加する。また、メモリリソースについては、図３に示すように０ＫＢから１２４ＫＢに増加する。さらに、スピーカ１６３とマイク１６４が使用可能になる。
【００９４】
次に、輻輳解析部２２２は、動画編集機能が削除され、音声通話機能が追加された状態を保持するため、図５に示すデータベース部２２１のモジュール状態情報を更新する（図３の信号（５））。このモジュール状態情報では、ＡＶ再生モジュール１１４の動画編集機能が起動済み状態から削除され、音声通話モジュール１１５の音声通話機能が起動済み状態に登録される。その後、輻輳解析部２２２は、音声通話モジュール１１５に機能追加応答を返す（図３の信号（６））。
【００９５】
続いて、機能追加応答を受け取った音声通話モジュール１１５は、音声通話アプリケーション１１２に音声通話開始応答を返す（図３の信号（７））。
【００９６】
以上の処理を行うことにより、図７に示すように、時間ＡでＡＶ再生モジュール１１４のみが動作している状態から、音声通話アプリケーション１１２からの音声通話開始要求に応じてＡＶ再生モジュール１１４の動画編集機能を削除し、音声通話機能を追加することになる。従って、時間ＢではＡＶ再生モジュール１１４と音声通話モジュール１１５とが並行して動作している状態に移行している。
【００９７】
以上の方法により、メディアモジュールでサポートする機能を基本機能と拡張機能に分類し管理することにより、リソース輻輳時に拡張リソースから基本リソースに優先的にリソースが割当てられることができるようになる。言い換えれば、新たな機能を起動させる場合に、起動済みであっても使用していない拡張機能を削除することで、リソースを有効に使用することが可能になる。従って、本実施形態のメディア処理方法を用いれば、複数のメディア処理を不具合なく並行して行なうことができる。
【００９８】
なお、本実施形態において、基本機能と拡張機能の分類の例として、静止画処理と、ＡＶ再生処理と、音声通話処理を例として示したが、機能の分類形態はこれに限らない。例えば、ＡＶ再生処理においてＭＰ３や、ＡＡＣや、ＷＭＡといったオーディオファイルを再生するために必要なリソースも、それぞれ拡張機能として分類できる。更に、リソース管理装置が扱うリソースをＣＰＵと、メモリと、デバイスに限定したが、さらにＤＭＡバンド幅などをリソースとして追加してもよい。
【００９９】
また、本実施形態のリソース管理装置は、アプリケーション処理プロセッサとメディア処理プロセッサとが個別に設けられていたが、これらがアプリケーション処理とメディア処理を共通のプロセッサで行なう場合にも、本実施形態のメディア処理方法は適用できる。
【０１００】
なお、本実施形態のリソース管理装置では、モジュール情報を格納するデータベース部２２１がメディア処理プロセッサ１０２内に設けられていたが、データベース部２２１をリソース管理装置の外部に設けていてもよい。
【０１０１】
（第２の実施形態）
図８は、本発明の第２の実施形態に係るリソース管理装置の構成例を示すブロック図である。
【０１０２】
同図に示す本実施形態のリソース管理装置１００は、アプリケーション処理プロセッサ１０１と、メディア処理プロセッサ１０２とを備えている。
【０１０３】
アプリケーション処理プロセッサ１０１は、メインアプリケーション１０３と、静止画処理アプリケーション１１０と、ＡＶ再生アプリケーション１１１と、音声通話アプリケーション１１２とを有している。
【０１０４】
また、メディア処理プロセッサ１０２は、静止画処理モジュール１１３と、ＡＶ再生モジュール１１４と、音声通話モジュール１１５と、システム管理部２２０と、輻輳解析部３２２と、データベース部３２１と、モジュール決定部３２３とを有している。
【０１０５】
本実施形態のリソース管理装置は、モジュール決定部３２３がメディア処理プロセッサ１０２内に設けられている点が第１の実施形態のリソース管理装置と異なっている。また、第１の実施形態のリソース管理装置におけるデータベース部２２１、輻輳解析部２２２は、本実施形態のリソース管理装置ではそれぞれデータベース部３２１、輻輳解析部３２２となっている。
【０１０６】
本実施形態のリソース管理装置に追加された構成要素について、以下に説明する。
【０１０７】
図９は、本実施形態のリソース管理方法において、データベース部３２１に格納されるモジュール情報の一例を示す図であり、図１０は、本実施形態のメディア処理方法において、データベース部３２１に格納されるモジュール状態情報の一例を示す図である。
【０１０８】
図９に示すモジュール情報と図１０に示すモジュール状態情報とは、共にデータベース部３２１に保持されている。ここで、モジュール情報は、図４に示すモジュール情報と同じく機能情報とリソース情報から構成されているが、機能情報にメディアモジュール別優先度が追加されている。
【０１０９】
メディアモジュール別優先度は、リソース輻輳時に、起動している拡張機能の中で削除するものはどれであるかを指定する、つまり削除対象候補を決定するための指標である。第１の実施形態では、リソース輻輳時にデータベースの先頭から削除対象候補となりうる拡張機能を検索することにより削除対象候補となった拡張機能を削除していたが、削除された拡張機能がすぐに必要になり、別の拡張機能を削除してその機能を追加するといったことが起こる可能性があった。そこで、本実施形態では、あらかじめユーザの使用頻度などをもとに拡張機能に削除時の優先順位を付けることとし、機能の追加と削除が不必要に繰り返されるのを防ぐこととしている。
【０１１０】
本実施形態の例では、図９のモジュール情報において、ユーザの使用頻度に応じて静止画処理モジュール１１３に優先度７を、ＡＶ再生モジュール１１４に優先度５を、音声通話モジュール１１５に優先度２をつけている。ここでは、メディアモジュール別優先度は番号の小さいものから順に高くなるものとする。
【０１１１】
また、モジュール決定部３２３は、輻輳解析部３２２からのモジュール決定要求を制御信号として受信すると、データベース部３２１からモジュール情報とメディアモジュール状態情報を読み出し、起動しているメディアモジュールの中からメディアモジュール別優先度の一番低いメディアモジュールを検索する。モジュール決定部３２３は、その結果、見つかったメディアモジュール名を制御信号として輻輳解析部３２２に出力する。
【０１１２】
輻輳解析部３２２から、同一の機能追加要求に対して、再度モジュール決定要求があった場合には、モジュール決定部３２３は、前回返したメディアモジュールの次に高い優先度をもつメディアモジュール名を返す。
【０１１３】
輻輳解析部３２２は、第１の実施形態で示した輻輳解析部２２２の機能に加えて、機能追加要求時においてリソースの輻輳を検出した場合、削除対象候補となりうる拡張機能を決定するためにモジュール決定部３２３にモジュール決定要求を制御信号として送信する。その後、輻輳解析部３２２は、モジュール決定部３２３からメディアモジュール名を制御信号として受信する。
【０１１４】
本発明の実施の形態における輻輳解析部３２２が、輻輳を解析し、リソース輻輳時にはモジュール決定部を使用して削除対象候補となった拡張機能を削除し、要求された機能を追加する処理の流れを図を用いて説明する。
【０１１５】
図１１は、本実施形態のメディア処理方法において、リソース輻輳時の処理の流れを示すフローチャート図である。
【０１１６】
まず、ステップＳ７０１で、輻輳解析部３２２は、メディアモジュールから機能追加要求を受信すると、その要求に含まれるモジュール名と拡張機能とをキーとしてデータベース部３２１のモジュール情報から追加する機能についてのリソース情報を取得する。
【０１１７】
次に、ステップＳ７０２で、システム管理部２２０から現在のリソース使用状況を取得する。
【０１１８】
続いて、ステップＳ７０３で、上述のステップＳ７０１、Ｓ７０２で取得したリソース情報及びリソース使用情報から、ＣＰＵと、メモリと、デバイスのそれぞれに関して追加要求された機能に必要とされるリソース量と空きリソース量とを比較する。追加機能が必要なリソース量より空きリソース量が多い場合（本ステップでＹｅｓの場合）、ステップＳ７０４へ移行する。また、空きリソースが十分でない場合（本ステップでＮｏの場合）、ステップＳ７０６へ移行する。
【０１１９】
そして、ステップＳ７０４で、追加要求された機能が必要とするリソースが確保できる場合に、輻輳解析部３２２は、上記ステップＳ７０１で取得したリソース情報をもとに、システム管理部２２０にＣＰＵと、メモリと、デバイスのそれぞれに関してリソースを確保するように要求する。
【０１２０】
次に、ステップＳ７０５で、輻輳解析部３２２は、上述のステップＳ７０４で追加した機能の状態を登録するためにデータベース部３２１内のモジュール状態情報を変更し、機能追加要求を送信したメディアモジュールに対して機能追加応答を送信する。この時、後述するステップＳ７１３で拡張機能を削除した場合には、この機能の状態もデータベース部３２１のモジュール状態情報に登録する。
【０１２１】
一方、追加要求された機能が必要とするリソースを確保するのに十分なリソースがない場合（ステップＳ７０３でＮｏの場合）、輻輳解析部３２２は、起動している拡張機能の中から削除対象候補となる拡張機能を決定するため、モジュール決定部３２３にモジュール決定要求を行う。そして、輻輳解析部３２２は、選択されたメディアモジュールの中で起動している拡張機能を検索し、削除対象候補となりうる拡張機能を検出する。
【０１２２】
まず、ステップＳ７０６で、輻輳解析部３２２は、起動しているメディアモジュールの中からモジュール別優先度に基づいてメディアモジュールを一つ選択するため、モジュール決定部３２３にモジュール決定要求を送信する。
【０１２３】
続いて、ステップＳ７０７では、起動しているメディアモジュールがあるかどうかを判定する。ここで、メディアモジュールが見つかったという応答がモジュール決定部から返った場合（本ステップでＹｅｓの場合）には、ステップＳ７０８へ移行する。一方、メディアモジュールが見つからなかったという応答が返った場合（本ステップでＮｏの場合）、削除可能な拡張機能が見つからなかったとして、ステップＳ７１４へ移行する。
【０１２４】
次に、ステップＳ７０８で、先のステップＳ７０７で選択されたメディアモジュールにおいて、起動している拡張機能の中から一つを削除候補として決定するために、輻輳解析部３２２は、選択されたメディアモジュールに対応するモジュール状態情報のレコードの先頭から順に検索する。本ステップでモジュール状態情報から起動している拡張機能が見つかった場合（本ステップでＹｅｓの場合）、ステップＳ７０９へ移行する。また、モジュール状態情報のレコードから起動している拡張機能が見つからない場合（本ステップでＮｏの場合）、選択されたメディアモジュールから削除可能な拡張機能が見つからなかったことで、ステップＳ７０６へ移行し、処理を繰り返す。
【０１２５】
次に、ステップＳ７０９では、先のステップＳ７０８で選択された拡張機能のリソース情報をデータベース部３２１から取得する。
【０１２６】
次いで、ステップＳ７０１では、輻輳解析部３２２が、上述のステップＳ７０１と、Ｓ７０２、Ｓ７０９で取得したリソース情報をもとに、ＣＰＵと、メモリと、デバイスのそれぞれに関して、追加要求機能が必要なリソース量と、拡張機能が確保しているリソース量と空きリソース量との和を比較する。本ステップで、追加機能が必要とするリソース量より空きリソース量と選択された拡張機能が確保しているリソース量との和の方が多い場合（本ステップでＹｅｓの場合）、削除対象候補となる拡張機能が決定し、ステップＳ７１１へ移行する。また、追加機能が必要とするリソースを確保できない場合（本ステップでＮｏの場合）、選択された拡張機能は、削除対象候補ではないとして上述のステップＳ７０８へ移行し処理を繰り返す。なお、１つの削除候補では十分な空きリソースが確保できない場合、再度本ステップの処理を行なう際に、複数個の削除候補を選択することもできる。
【０１２７】
そして、ステップＳ７１１では、削除対象候補が決定された場合（ステップＳ７１０でＹｅｓの場合）に、輻輳解析部３２２が上記ステップＳ７０６で選択されたメディアモジュールに対して機能削除問合せを行い、それに対する応答を待つ。
【０１２８】
次に、ステップＳ７１２では、上述のステップＳ７１１で行った機能削除問合せの応答が削除応答である場合（本ステップでＹｅｓの場合）、その拡張機能が削除されることが決定し、ステップＳ７１３へ移行する。また、応答がキャンセルである場合（本ステップでＮｏの場合）、その拡張機能は削除できないことが決定し、上記ステップＳ７０８へ移行して処理を繰り返す。
【０１２９】
次いで、ステップＳ７１３では、削除決定した拡張機能を削除するために、上記ステップＳ７０９で取得したリソース情報をもとに、輻輳解析部３２２がシステム管理部２２０にＣＰＵと、メモリと、デバイスのそれぞれに関してリソースを解放するように要求する。そして、処理はステップＳ７０４へ移行する。
【０１３０】
一方、ステップＳ７１４では、上述のステップＳ７０７において、起動しているメディアモジュールが見つからなかった場合（ステップＳ７０７でＮｏの場合）、機能追加要求を送信したメディアモジュールに対して機能追加キャンセルを送信する。以上の手順で、輻輳解析を行なうことができる。
【０１３１】
次に、本実施形態のリソース管理装置における輻輳解析について、例を挙げて具体的に説明する。
【０１３２】
図１２（ａ）は、第１の実施形態のリソース管理装置において、ＣＰＵのリソース占有率の変化を示す図であり、（ｂ）は、本実施形態のリソース管理装置において、ＣＰＵのリソース占有率の変化を示す図である。なお、同図は、静止画処理モジュール１１３と、ＡＶ再生モジュール１１４と、音声通話モジュール１１５とが確保しているメモリリソースの割合を図示しており、特に、メディアモジュール別優先度の有効性を示すために、アプリケーションから２つの異なる拡張機能の開始要求が交互に行われる場合について示している。
【０１３３】
図１０に示す例では、静止画処理モジュール１１３の静止画撮影機能と静止画編集機能が起動され、ＡＶ再生モジュール１１４のＡＶ再生機能と画質調整機能が起動され、音声通話モジュール１１５の音声通話機能が起動されて、それぞれが使用可能である状態となっている。
【０１３４】
この状態で、ユーザから音声通話アプリケーション１１２を通じて音声通話モジュール１１５へ音声メモ録音開始要求があると、音声通話モジュール１１５はその要求を受けて輻輳解析部３２２へ音声メモ録音機能の追加要求を送信する。
【０１３５】
音声メモ録音機能の追加要求を受け取った輻輳解析部３２２は、音声通話モジュールと音声メモ録音とをキーとして図９に示すデータベース部３２１のモジュール情報から音声メモ録音のリソース情報（ＣＰＵ演算量１０ＭＨｚ（ＣＰＵリソースの６％に相当）とメモリサイズ２１ＫＢ（メモリリソースの４％に相当）が必要）を取得する。
【０１３６】
これと同時に、輻輳解析部３２２は、システム管理部２２０から次のようなリソース使用状況を取得する。
【０１３７】
ＣＰＵに関しては１６０ＭＨｚのリソースのうち、図９に示すように静止画処理モジュール１１３がリソースの１０％（内訳は、静止画撮影が５％の８ＭＨｚ、静止画編集が５％の７ＭＨｚ）を、ＡＶ再生モジュール１１４がリソースの５５％（内訳は、ＡＶ再生が３３％の５２ＭＨｚ、画質調整が２２％の３５ＭＨｚ）を、音声通話モジュール１１５の音声通話がリソースの２１％にあたる３４ＭＨｚをそれぞれ確保しており、残り１４％が未割当てである。メモリに関しては５１２ＫＢのリソースのうち、図１２に示すように静止画処理モジュール１１３がリソースの２２％（内訳は、静止画撮影が１５％の７８ＫＢ、静止画編集が６％の３３ＫＢ）を、ＡＶ再生モジュール１１４がリソースの５２％（内訳は、ＡＶ再生が４４％の２２６ＫＢ、画質調整が８％の３９ＫＢ）を、音声通話モジュール１１５の音声通話がリソースの２４％にあたる１２４ＫＢをそれぞれ確保しており、残り２％が未割当てである。デバイスに関しては、図９に示すように、静止画処理モジュール１１３がＬＣＤ１６２を、ＡＶ再生モジュール１１４がＬＣＤ１６２とスピーカ１６３を、音声通話モジュール１１５がスピーカ１６３とマイク１６４とベースバンド・プロセッサ１６５を使用している。
【０１３８】
次に、輻輳解析部３２２は、ＣＰＵ、メモリ、デバイスについて追加要求機能である音声通話が必要とするリソース量と空きリソース量とを比較する。比較の結果、ＣＰＵリソースについては６％のリソース要求に対して１４％の空きリソースがあるため、輻輳は検出されない。メモリリソースについては、図１２（ｂ）に示すように４％のリソース要求に対して空きが２％しかないため、輻輳解析部３２２は輻輳を検出する。さらに、デバイスリソースについては、輻輳は検出されない。よって、メモリリソースから輻輳が検出されたため、リソースの輻輳が発生することが判定される。
【０１３９】
図１２（ａ）に示すように、第１の実施形態のリソース管理装置において輻輳が検出された場合、輻輳解析部２２２は、図１０に示すモジュール状態情報の先頭から一番近い起動済み拡張機能である画質調整機能を削除対象候補に決定し、ＡＶ再生モジュール１１４に機能削除を要求する。その結果、画質調整機能が削除され、輻輳解析部２２２は要求された音声メモ録音機能を追加する。そして、音声通話アプリケーション１１２は音声メモ録音を開始する。
【０１４０】
しかし、しばらく後、ユーザからＡＶ再生アプリケーション１１１を通じてＡＶ再生モジュール１１４へ画質調整機能の開始要求があると、図１２（ａ）に示すように輻輳解析部２２２はリソースの輻輳を検出し、図１０に示すモジュール状態情報の先頭から一番近い起動済み拡張機能を決定する。この際に、輻輳解析部２２２は、先程追加された音声メモ録音機能を削除対象候補として決定し削除する。そして、画質調整処理が起動する。
【０１４１】
その後、再度ユーザから音声メモ録音機能の追加要求があると、輻輳解析部２２２は先程起動した画質調整機能を削除して音声メモ録音機能を追加する。
【０１４２】
以上のように、第１の実施形態のリソース管理装置では、ユーザからの拡張機能開始要求ごとに機能の追加と削除が発生している。このように、リソース輻輳状態においてユーザが拡張機能を次々と使用するような場合、機能追加と削除にともなう無駄なオーバヘッドが発生する。
【０１４３】
これに対し、本実施形態のリソース管理装置において、輻輳解析部３２２が輻輳を検出した場合には、削除対象候補となる拡張機能を決定するため、モジュール決定部３２３にモジュール決定要求を送信する。
【０１４４】
モジュール決定要求を受信したモジュール決定部３２３は、図９に示すモジュール情報と図１０に示すモジュール状態情報から起動中のメディアモジュールの中で優先度の一番低い静止画処理モジュールを輻輳解析部３２２へ返す。
【０１４５】
次に、モジュール決定部３２３から静止画処理モジュールが選択されると、輻輳解析部３２２は、図１０に示す静止画処理モジュール内のモジュール状態情報を検索し、先頭から順に起動している拡張機能を読み出す。ここでは、図１２（ｂ）に示すように、静止画編集機能が削除対象候補として決定されて削除される。
【０１４６】
その後、ユーザから音声メモ録音機能の開始要求が出された場合、すでに起動済みであるので拡張機能の削除および追加を再度行なう必要はない。
【０１４７】
以上のように、本実施形態のリソース管理装置では、図１２（ｂ）に示すようにユーザから画質調整機能の開始要求と音声メモ録音の開始要求とが交互に出されても拡張機能の追加、あるいは削除が発生しない。すなわち、あらかじめユーザの使用頻度が高い順にメディアモジュールの優先度を決めておくことで、余計な機能追加と削除の手間が省けるので、ユーザの要求に対する応答速度が向上する。
【０１４８】
このように、メディア処理の各機能を基本機能と拡張機能に分けた上で、メディアモジュールごとに優先度を設定することで、リソース輻輳時に優先度の低いメディアモジュールから所望のメディアモジュールへとリソースが割り当てられることとなり、リソースを効率的に配分することができるようになる。従って、本実施形態のリソース管理装置によれば、第１の実施形態よりもさらに効率的に複数のメディア処理を並列して行なうことが可能となる。
【０１４９】
なお、本実施形態のメディア処理方法では、メディアモジュール別優先度の例として、ユーザの使用頻度に応じた優先度を示したが、優先度のつけ方はこれに限らない。
【０１５０】
また、メディアモジュール別優先度は固定されている必要はなく、動的につけてもよい。例えば、使用頻度の高い機能はユーザごとに異なっているので、メモリ１５１に各機能の使用履歴などを記憶しておき、これに基づいて優先度を決定することもできる。
【０１５１】
（第３の実施形態）
図１３は、第３の実施形態に係るリソース管理装置の構成例を示すブロック図である。
【０１５２】
同図に示す本実施形態のリソース管理装置１００は、アプリケーション処理プロセッサ１０１と、メディア処理プロセッサ１０２とを備えている。
【０１５３】
アプリケーション処理プロセッサ１０１は、メインアプリケーション１０３と、静止画処理アプリケーション１１０と、ＡＶ再生アプリケーション１１１と、音声通話アプリケーション１１２とを有している。
【０１５４】
また、メディア処理プロセッサ１０２は、静止画処理モジュール１１３と、ＡＶ再生モジュール１１４と、音声通話モジュール１１５と、システム管理部２２０と、輻輳解析部４２２と、データベース部４２１と、機能決定部４２４とを有している。
【０１５５】
本実施形態のリソース管理装置は、メディア処理プロセッサ１０２内に機能決定部４２４が設けられている点が第１の実施形態のリソース管理装置と異なっている。また、データベース部２２１はデータベース部４２１に、輻輳解析部２２２は輻輳解析部４２２として示している。
【０１５６】
本実施形態のリソース管理装置による輻輳解析について、以下に説明する。
【０１５７】
図１４は、本実施形態のリソース管理方法において、データベース部４２１に格納されるモジュール情報の一例を示す図であり、図１５は、本実施形態のメディア処理方法において、データベース部４２１に格納されるモジュール状態情報の一例を示す図である。
【０１５８】
図１４に示すモジュール情報と図１５に示すモジュール状態情報とは、共にデータベース部４２１に保持されている。ここで、モジュール情報は機能情報とリソース情報、及びメディアモジュール別優先度を含んでいる。なお、このモジュール別優先度は、第２の実施形態で説明したものと同じものである。これに加え、本実施形態においてモジュール情報は、機能別優先度も含んでいる。
【０１５９】
ここで、機能別優先度は、リソース輻輳時にモジュール別優先度を使って選択されたメディアモジュールの中から、削除対象候補となる拡張機能を決定するための指標である。そのため、第１、第２の実施形態と同様に、基本機能に優先度はない。
【０１６０】
第２の実施形態に係るリソース管理装置では、リソース輻輳時に、モジュール決定部３２３が優先度の低いモジュールから順に削除対象候補に選定していた。しかし、モジュール全体としての優先度は低くても、使用頻度の高い機能を含む場合には、削除された拡張機能がすぐに必要になり、別の拡張機能を削除してその機能を追加するといったことが起こる可能性があった。このため、本実施形態のメディア処理方法では、モジュールに含まれる拡張機能にも優先度を付して、リソースの輻輳が生じる際には、機能別優先度も参照して削除する機能を決定することとした。
【０１６１】
本実施形態の例では、図１４に示すようにユーザの使用頻度に応じて静止画処理モジュール１１３に優先度７を、ＡＶ再生モジュール１１４に優先度５を、音声通話モジュール１１５に優先度２をつけている。また、ＡＶ再生モジュール１１４内の拡張機能をユーザの使用頻度に応じて動画編集機能に優先度２を、画質調整機能に優先度４を、イコライズ機能に優先度５を設定している。ここでは、メディアモジュール別優先度と機能別優先度とも、番号の小さいものから順に高くなっているものとする。
【０１６２】
機能決定部４２４は、輻輳解析部４２２からの機能決定要求を制御信号として受信すると、データベース部４２１からモジュール情報とメディアモジュール状態情報とを読み出し、起動しているメディアモジュールの中からメディアモジュール別優先度の低いメディアモジュールを選択する。次に、選択したメディアモジュールの起動中の拡張機能の中から起動別優先度の一番低い拡張機能を削除対象拡張機能として検出する。そして、その結果を制御信号として輻輳解析部４２２に出力する。
【０１６３】
輻輳解析部４２２から、同一の機能追加要求に対して、二回目以降の機能決定要求があった場合には、機能決定部４２４は、前回返した拡張機能の次に高い優先度をもつ拡張機能を返す。
【０１６４】
輻輳解析部４２２は、第１の実施形態の輻輳解析部２２２の機能に加えて、機能追加要求時にリソースの輻輳を検出した場合、削除対象候補となりうる拡張機能を決定するために機能決定部４２４に機能決定要求を制御信号として送信し、拡張機能を制御信号として受信する。
【０１６５】
次に、本実施形態のリソース管理装置における輻輳解析部４２２が、輻輳解析を行なう際の処理の流れを説明する。
【０１６６】
図１６は、本実施形態のメディア処理方法において、リソース輻輳時の処理の流れを示すフローチャート図である。
【０１６７】
まず、ステップＳ８０１で、輻輳解析部４２２は、メディアモジュールから機能追加要求を受信すると、その機能追加要求に含まれるモジュール名と拡張機能とをキーとして、データベース部４２１内のモジュール情報から追加要求があったモジュールについてのリソース情報を取得する。
【０１６８】
次に、ステップＳ８０２で、輻輳解析部４２２は、システム管理部２２０から現在のリソース使用状況を取得する。
【０１６９】
次いで、ステップＳ８０３では、ステップＳ８０１、Ｓ８０２で取得したリソース情報から、ＣＰＵと、メモリと、デバイスのそれぞれに関して、追加要求された機能が必要とするリソース量と空きリソース量とを比較する。追加機能が要求するリソース量より空きリソース量の方が多い場合（本ステップでＹｅｓの場合）、ステップＳ８０４へ移行する。また、空きリソースが十分でない場合（本ステップでＮｏの場合）、ステップＳ８０６へ移行する。
【０１７０】
次に、ステップＳ８０４では、追加要求された機能が必要とするリソースが確保可能の場合（ステップＳ８０３でＹｅｓの場合）に、上記ステップＳ８０１で取得したリソース情報をもとに、システム管理部２２０にＣＰＵと、メモリと、デバイスのそれぞれに関してリソースを確保するように輻輳解析部４２２が要求する。
【０１７１】
続いて、ステップＳ８０５では、先のステップＳ８０４で追加した機能の状態を登録するため、データベース部４２１のモジュール状態情報を変更し、機能追加要求を送信したメディアモジュールに対して輻輳解析部４２２が機能追加応答を送信する。この時、後述するステップＳ８１２で拡張機能を削除した場合には、この機能の状態もデータベース部４２１のモジュール状態情報に登録する。
【０１７２】
一方、ステップＳ８０６では、追加要求された機能が必要とするリソースを確保できない場合（本ステップでＮｏの場合）、輻輳解析部４２２は、起動している拡張機能の中から削除対象候補となる拡張機能を決定するため、機能決定部４２４に機能決定要求を行う。
【０１７３】
次に、ステップＳ８０７では、輻輳解析部４２２が機能決定部４２４からの応答を受ける。ここで、機能決定部より拡張機能が見つかったという応答が返った場合（本ステップでＹｅｓの場合）には、ステップＳ８０８へ移行する。また、起動している拡張機能が見つからなかったという応答が返った場合（本ステップＳ８０８でＮｏの場合）、削除可能な拡張機能が見つからなかったとして、ステップＳ８１３へ移行する。
【０１７４】
次いで、ステップＳ８０８では、上記ステップＳ８０７で選択された拡張機能のリソース情報をデータベース部４２１から取得する。
【０１７５】
続いて、ステップＳ８０９では、上述のステップＳ８０１と、Ｓ８０２と、Ｓ８０８で取得したリソース情報から、ＣＰＵと、メモリと、デバイスのそれぞれに関して、追加要求機能が必要とするリソース量と、拡張機能が確保しているリソース量と空きリソース量との和とを比較する。追加機能が必要とするリソース量より空きリソース量と選択された拡張機能が確保しているリソース量との和の方が多い場合（本ステップでＹｅｓの場合）、削除対象候補となる拡張機能が決定し、ステップＳ８１０へ移行する。また、追加機能が必要とするリソースが確保できない場合（本ステップでＮｏの場合）、選択された拡張機能は削除対象候補ではない、として上述のステップＳ８０６へ移行し、処理を繰り返す。
【０１７６】
次に、ステップＳ８１０では、削除対象候補が決定された場合（ステップＳ８０９がＹｅｓ）に、輻輳解析部４２２が上記ステップＳ８０６で選択されたメディアモジュールに対して機能削除問合せを行い、それに対する応答を待つ。
【０１７７】
続いて、ステップＳ８１１では、先のステップＳ８１０で行った機能削除問合せに対する応答が削除応答である場合（本ステップでＹｅｓの場合）、その拡張機能が削除されることが決定し、ステップＳ８１２へ移行する。また、応答がキャンセルである場合（本ステップでＮｏの場合）、その拡張機能は削除できないことが決定し、上述のステップＳ８０６へ移行して処理を繰り返す。
【０１７８】
次いで、ステップＳ８１２では、削除決定した拡張機能を削除するために、上記ステップＳ８０８で取得したリソース情報をもとに、システム管理部２２０にＣＰＵと、メモリと、デバイスのそれぞれに関してリソースを解放するように輻輳解析部４２２が要求し、上述のステップＳ８０４へ処理が移行する。
【０１７９】
一方、ステップＳ８１３では、先のステップＳ８０６で行った拡張機能の検索の結果、削除可能な拡張機能が見つからなかった場合（ステップＳ８０７でＮｏの場合）、機能追加要求を送信したメディアモジュールに対して輻輳解析部４２２が機能追加キャンセルを送信する。以上の手順によって輻輳解析が行われる。
【０１８０】
次に、本実施形態のリソース管理装置における輻輳解析について、例を挙げて具体的に説明する。
【０１８１】
図１７（ａ）は、第１の実施形態のリソース管理装置において、メモリのリソース占有率の変化を示す図であり、（ｂ）は、本実施形態のリソース管理装置において、メモリのリソース占有率の変化を示す図である。なお、図１７では、ＡＶ再生モジュール１１４で起動しているＡＶ再生機能と、動画編集機能と、画質調整機能と、イコライズ機能の組み合わせにより、ＡＶ再生モジュール１１４が確保しているメモリリソースの割合が変化することを図示しており、特に、機能別優先度を付する有効性を示すために、アプリケーションから２種類の拡張機能の開始要求が交互に行われる場合について示している。
【０１８２】
ここでは、図１５のモジュール状態情報に示すように、ＡＶ再生モジュール１１４のＡＶ再生機能と、画質調整機能と、イコライズ機能が起動され、且つ、静止画処理モジュール１１３の静止画撮影機能が起動されて、それぞれが使用可能である状態の例を挙げている。
【０１８３】
この状態で、ユーザからＡＶ再生アプリケーション１１１を通じてＡＶ再生モジュール１１４へ動画編集開始要求があった場合、ＡＶ再生モジュール１１４はその要求を受けて輻輳解析部４２２へ動画編集機能追加要求を送信する。
【０１８４】
動画編集機能の追加要求を受け取った輻輳解析部４２２は、ＡＶ再生モジュールと動画編集をキーとして、図１４に示すモジュール情報から動画編集のリソース情報（ＣＰＵ演算量５６ＭＨｚ（ＣＰＵリソースの３５％に相当）とメモリサイズ１５９ＫＢ（メモリリソースの３１％に相当）が必要）を取得する。
【０１８５】
これと同時に、輻輳解析部４２２は、システム管理部２２０から次のようなリソース使用状況を取得する。
【０１８６】
ＣＰＵに関しては１６０ＭＨｚのリソースのうち、図１４に示すように静止画処理モジュール１１３の静止画撮影がリソースの５％にあたる８ＭＨｚを、ＡＶ再生モジュール１１４がリソースの６７％のリソース（内訳は、ＡＶ再生が３３％の５２ＭＨｚ、画質調整が２２％の３５ＭＨｚ、イコライズが１２％の１９ＭＨｚ）をそれぞれ確保しており、残り２８％が未割当てである。メモリに関しては、５１２ＫＢのリソースのうち、図１７に示すように静止画処理モジュール１１３の静止画撮影がリソースの１５％にあたる７８ＫＢを、ＡＶ再生モジュール１１４がリソースの５８％のリソース（内訳は、ＡＶ再生が４４％の２２６ＫＢ、画質調整が８％の３９ＫＢ、イコライズが６％の３１ＫＢ）を使用しており、残り２７％の空きがある。デバイスに関しては、静止画処理モジュール１１３がＬＣＤ１６２を、ＡＶ再生モジュール１１４がＬＣＤ１６２とスピーカ１６３を使用している。
【０１８７】
輻輳解析部４２２は、ＣＰＵ、メモリ、デバイスについて追加要求機能である動画編集が必要とするリソース量と空きリソース量とを比較する。比較の結果、ＣＰＵリソースについては３５％のリソース要求に対して２８％の空きリソースしかないため輻輳を検出する。メモリリソースについては、図１７に示すように３１％のリソース要求に対して空きが２７％しかないため輻輳を検出する。デバイスリソースについては、輻輳は検出されない。よって、リソースの輻輳が発生することが判定される。
【０１８８】
第１の実施形態に係るリソース管理装置において輻輳を検出した場合、図１７（ａ）に示すように輻輳解析部２２２は、図１５に示すモジュール状態情報の先頭から一番近い起動済み拡張機能、画質調整機能を削除対象候補に決定し、ＡＶ再生モジュール１１４に機能削除を要求する。その結果、画質調整機能は削除され、輻輳解析部２２２は要求された動画編集機能を追加する。その結果音声通話アプリケーション１１２は動画編集を開始する。
【０１８９】
しかし、しばらく後、ユーザからＡＶ再生アプリケーション１１１を通じてＡＶ再生モジュール１１４へ画質調整機能の開始要求がある場合に、図１７（ａ）に示すように輻輳解析部２２２は、リソースの輻輳を検出し、図１５に示すモジュール状態情報の先頭から一番近い起動済み拡張機能を削除対象とする。ここで、削除対象となる追加機能は、先程追加された動画編集機能である。そして、動画編集機能が削除されることが決定すると、その後、画質調整処理が起動する。図１７（ａ）では、この後にも動画編集機能の開始要求があり、再度画質調整処理を削除し、動画編集機能を追加する例を示している。この例では、ユーザからの拡張機能の開始要求ごとに機能の追加と削除が発生している。
【０１９０】
このように、リソース輻輳状態においてユーザが拡張機能を次々と使用するような場合、特に削除候補となる機能の使用頻度が高ければ、機能追加と削除にともなう無駄なオーバヘッドが発生しやすくなる。
【０１９１】
一方、本実施形態のリソース管理装置において、輻輳解析部４２２が輻輳を検出した場合には、削除対象候補となる拡張機能を決定するため、機能決定部４２４に機能決定要求を送信する。
【０１９２】
機能決定要求を受信した機能決定部４２４は、図１４に示すモジュール情報と図１５に示すモジュール状態情報とから、起動中のメディアモジュールの中で優先度の一番低い静止画処理モジュールを選択するが、起動している拡張機能がないので、二番目に低いＡＶ再生モジュール選択し、ＡＶ再生モジュール内の起動中の拡張機能の中で優先度の一番低いイコライズ機能を選択し、そして輻輳解析部４２２に選択されたイコライズ機能を返す。
【０１９３】
輻輳解析部４２２は、機能決定部４２４からイコライズ機能が選択されると、リソースの計算を行い削除対象候補となるか否かの判定を行う。ここでは、図１７（ｂ）に示すように、イコライズ機能が削除対象候補として決定され、削除される。これにより、メモリリソースの空きが５２％となり、動画編集機能の追加が可能となる。
【０１９４】
次に、ユーザからＡＶ再生アプリケーション１１１を通じてＡＶ再生モジュール１１４へ画質調整機能の開始要求がある場合、画質調整機能は起動状態のままであるので、機能の削除及び追加を行なう必要がない。このように、本実施形態のリソース管理装置によれば、図１７（ｂ）に示すように、ユーザから動画編集機能開始と画質調整機能開始が交互に要求されても拡張機能の追加と削除が発生しない。この例では図１４に示すような優先度を付したが、この他にもユーザの使用頻度が高いメディアモジュールに高い優先度を与え、また、メディアモジュール内の拡張機能の中でも使用頻度が高いものに高い優先度を与えることで、機能の追加と削除が発生する頻度を低くすることができるので、ユーザに対するレスポンスを向上させることができる。
【０１９５】
すなわち、本実施形態のリソース管理装置では、メディアモジュールに加えて、それに含まれる拡張機能にも優先度を付加することにより、リソース輻輳時に優先度の低い拡張リソースから優先度の高い拡張リソースにリソースが割当てられることとなり、ユーザへのレスポンスをさらに向上させることができる。
【０１９６】
なお、以上の説明では、機能別優先度の例として、ユーザの使用頻度に応じた優先度を示したが、優先度のつけ方はこれに限らない。また、機能別優先度は動的につけてもよい。例えば、各ユーザの使用頻度に応じて機能の優先度を変化させるなどしてもよい。
【０１９７】
また、本実施形態の説明では、モジュールの優先度と拡張機能の優先度を合わせて設定している例を示したが、モジュールの優先度を設定せずに拡張機能の優先度のみを設定してもよい。この場合、モジュールの枠を越えて機能別優先度を設定し、機能を削除する場合には、機能別優先度の低い機能から削除対象とする。
【０１９８】
（第４の実施形態）
図１８は、第４の実施形態に係るリソース管理装置の構成例を示すブロック図である。
【０１９９】
同図に示すリソース管理装置１００は、アプリケーション処理プロセッサ１０１と、メディア処理プロセッサ１０２とを備えている。
【０２００】
アプリケーション処理プロセッサ１０１は、メインアプリケーション１０３と、静止画処理アプリケーション１１０と、ＡＶ再生アプリケーション１１１と、音声通話アプリケーション１１２とを有している。
【０２０１】
また、メディア処理プロセッサ１０２は、静止画処理モジュール５１３と、ＡＶ再生モジュール５１４と、音声通話モジュール５１５と、システム管理部２２０と、輻輳解析部５２２と、データベース部２２１と、応答処理部５２５とを有している。
【０２０２】
本実施形態のリソース管理装置は、メディア処理プロセッサ１０２内に応答処理部５２５が設けられている点が第１の実施形態のリソース管理装置と異なっている。また、静止画処理モジュール１１３は静止画処理モジュール５１３として、ＡＶ再生モジュール１１４はＡＶ再生モジュール５１４として、音声通話モジュール１１５は音声通話モジュール５１５として、輻輳解析部２２２は輻輳解析部５２２としてそれぞれ示している。
【０２０３】
本実施形態のリソース管理装置による輻輳解析について、以下に説明する。
【０２０４】
応答処理部５２５は、輻輳解析部５２２から制御信号として送信された１つ以上の削除問合せを受信する。本実施形態のリソース管理装置では、１つ以上の削除問い合わせがほぼ同時に応答処理部５２５に送信される。ここで、削除問合せは、削除問合せ対象の拡張機能と、それをサポートするメディアモジュールとの削除に関している。
【０２０５】
削除問合せを受信した応答処理部５２５は、削除問合せ対象の拡張機能と、それをサポートするメディアモジュールとを記憶し、削除問合せに含まれるメディアモジュール宛てに機能削除問合せを制御信号として送信する。機能削除問合せを行った結果、メディアモジュールからその応答として承認応答、あるいはキャンセルを制御信号として受信する。
【０２０６】
応答処理部５２５は、一番早く受信した承認応答を発行したメディアモジュールに対して削除要求を制御信号として送信する。そして、二番目以降に受信した承認応答を発行したメディアモジュールに対してキャンセルを制御信号として送信する。
【０２０７】
次に、応答処理部５２５は、メディアモジュールに送信した削除要求に対する削除応答を制御信号として受信すると、輻輳解析部５２２に削除応答を受信したメディアモジュールの拡張機能に対する削除応答を返す。
【０２０８】
応答処理部５２５が送受信する制御信号のシーケンスをまとめると以下のようになる。
【０２０９】
（１）機能削除問合せを一つ以上のメディアモジュールへ送信
（２）メディアモジュールから応答、承認応答、あるいはキャンセルを受信
（３―１―１）受信した応答が承認応答で、なおかつ一番最初の応答であった場合には、その応答を発行したメディアモジュールに削除要求を送信
（３―１―２）メディアモジュールから削除要求に対する削除応答を受信
（３―２）受信した応答が承認応答で、なおかつ二番目以降の応答であった場合には、その応答を発行したメディアモジュールにキャンセルを送信
（３―３）受信した応答がキャンセルの場合には、シーケンス終了
第１の実施形態に係るリソース管理装置では、輻輳解析部２２２はメディアモジュールに対して機能削除問合せを一度に一回しか行うことができず、問合せに対するレスポンスが遅いメディアモジュールが複数の削除対象候補の中で最初に選択されてしまうと、ユーザへのレスポンスが遅くなるという現象が起こるおそれがあった。本実施形態のリソース管理装置では、この点が改善されている。
【０２１０】
静止画処理モジュール５１３と、ＡＶ再生モジュール５１４と、音声通話モジュール５１５の各メディアモジュールは、第１の実施形態での各メディアモジュールと同様の処理を行うが、応答処理部５２５の追加に対応した以下の処理を新たに行なう。
【０２１１】
リソース輻輳時に削除対象候補となった拡張機能をサポートするメディアモジュールは、応答処理部５２５から機能削除問合せを受信する。機能削除問合せを受信したメディアモジュールは、削除を許可する承認応答か、あるいは削除を許可しないキャンセルを応答として返す。この時、必要ならばアプリケーションに問い合せてもよい。
【０２１２】
応答処理部５２５に承認応答を送信したメディアモジュールの中で、一番早く送信したメディアモジュールには、応答処理部５２５から削除要求が送信される。
【０２１３】
そして、削除要求を受信したメディアモジュールは、削除される拡張機能の終了処理を行った後、削除応答を返す。
【０２１４】
応答処理部５２５に承認応答を送信したメディアモジュールの中で、二番目以降に送信したメディアモジュールには、応答処理部５２５からキャンセルが送信される。
【０２１５】
キャンセルを受信したメディアモジュールは、引き続きメディア処理を継続することができる。
【０２１６】
次に、本実施形態のリソース管理装置における輻輳解析部５２２と応答処理部５２５が、輻輳解析を行なう際の処理の流れを説明する。
【０２１７】
図１９は、本実施形態のメディア処理方法において、リソース輻輳時の処理の流れを示すフローチャート図である。
【０２１８】
まず、ステップＳ９０１で、メディアモジュールから機能追加要求を受信すると、輻輳解析部５２２は、その機能追加要求に含まれるモジュール名と拡張機能とをキーとしてデータベース部２２１内のモジュール情報から、追加要求があったモジュールについてのリソース情報を取得する。
【０２１９】
次に、ステップＳ９０２では、システム管理部２２０から現在のリソース使用状況を取得する。
【０２２０】
次いで、ステップＳ９０３では、先にステップＳ９０１、Ｓ９０２で取得したリソース情報から、輻輳解析部５２２が、ＣＰＵと、メモリと、デバイスのそれぞれに関して追加要求された機能が必要とするリソース量と空きリソース量とを比較する。追加機能が必要なリソース量より空きリソース量が多い場合（本ステップでＹｅｓの場合）、ステップＳ９０４へ移行する。また、空きリソースが十分でない場合（本ステップでＮｏの場合）、ステップＳ９０６へ移行する。
【０２２１】
次に、ステップＳ９０４では、追加要求された機能が必要とするリソースが確保可能の場合（ステップＳ９０３でＹｅｓの場合）に、輻輳解析部５２２が、上記ステップＳ９０１で取得したリソース情報をもとに、システム管理部２２０にＣＰＵと、メモリと、デバイスのそれぞれに関してリソースを確保するように要求する。
【０２２２】
続いて、ステップＳ９０５では、先のステップＳ９０４で追加した機能の状態を登録するためにデータベース部２２１のモジュール状態情報を変更し、機能追加要求を送信したメディアモジュールに対して機能追加応答を送信する。この時、後述するステップＳ９１０で拡張機能を削除した場合には、この機能の状態もデータベース部２２１のモジュール状態情報に登録する。
【０２２３】
一方、追加要求された機能が必要とするリソースを確保できない場合（ステップＳ９０３でＮｏの場合）には、輻輳解析部５２２は、起動している拡張機能の中から削除対象候補となる複数の拡張機能を決定するため、データベース部２２１から起動しているメディアモジュールを検索し、次に、選択されたメディアモジュールの中から起動している拡張機能を検索し、そして、削除対象候補になりうる拡張機能を検出する。
【０２２４】
まず、ステップＳ９０６で、データベース部２２１に格納されているモジュール状態情報の先頭から順に起動しているメディアモジュールを検索し、削除対象候補が見つかった場合（本テップでＹｅｓの場合）には、ステップＳ９１１へ移行する。また、モジュール状態情報のレコードの中から起動しているメディアモジュールが見つからない場合（本ステップでＮｏの場合）、ステップＳ９０７へ移行する。
【０２２５】
次に、ステップＳ９０７では、応答処理部５２５からの応答待ちがある場合（本ステップでＹｅｓの場合）、ステップＳ９０８に移行する。また、応答待ちがない場合（本ステップでＮｏの場合）、削除可能な拡張機能が見つからなかったとして、ステップＳ９１５へ移行する。
【０２２６】
次いで、ステップＳ９０８で、輻輳解析部５２２は、応答処理部５２５からの機能削除問合せの応答を受信する。
【０２２７】
次に、ステップＳ９０９では、先のステップＳ９０８で、応答処理部５２５から受信した応答が拡張機能削除応答ならば（本ステップでＹｅｓの場合）、ステップＳ９１０へ移行する。また、受信した応答がキャンセルならば（本ステップでＮｏの場合）、削除可能な拡張機能が見つからなかったとして、ステップＳ９１５へ移行する。
【０２２８】
次に、ステップＳ９１０では、削除決定した拡張機能を削除するために、後述するステップＳ９１２で取得したリソース情報をもとに、輻輳解析部５２２が、システム管理部２２０にＣＰＵと、メモリと、デバイスのそれぞれに関してリソースを解放するように要求する。そして、処理を上述のステップＳ９０４へ移行する。
【０２２９】
また、ステップＳ９１１で、輻輳解析部５２２は、起動している拡張機能の中から拡張機能を一つ決定するために、上述のステップＳ９０６で選択されたメディアモジュールにについて、モジュール状態情報のレコードの先頭から順に検索する。ここで、モジュール状態情報から起動している拡張機能が見つかった場合（本ステップでＹｅｓの場合）、ステップＳ９１２へ移行する。また、モジュール状態情報のレコードから起動している拡張機能が見つからない場合（本ステップでＮｏの場合）、上述のステップＳ９０６へ移行する。
【０２３０】
次に、ステップＳ９１２では、上述のステップＳ９１１で選択された拡張機能のリソース情報をデータベース部２２１から取得する。
【０２３１】
次に、ステップＳ９１３では、先のステップＳ９１２、Ｓ９０１、Ｓ９０２で取得したリソース情報から、輻輳解析部５２２が、ＣＰＵと、メモリと、デバイスのそれぞれに関して、追加要求機能が必要とするリソース量と、拡張機能が確保しているリソース量と空きリソース量との和を比較する。追加機能が必要とするリソース量より、空きリソース量と選択された拡張機能が確保しているリソース量の和が多い場合（本ステップでＹｅｓの場合）、削除対象候補となる拡張機能が決定し、ステップＳ９１４へ移行する。また、追加機能が必要とするリソースが確保できない場合（本ステップでＮｏの場合）、選択された拡張機能は、削除対象候補ではないとして上述のステップＳ９１１へ移行し、処理を繰り返す。
【０２３２】
次に、ステップＳ９１４で、削除対象候補が決定された場合（ステップＳ９１３でＹｅｓの場合）、上記ステップＳ９０６で選択されたメディアモジュールに対して機能削除問合せを行い、次の削除対象候補を検索するためにステップＳ９１１へ移行する。以上の手順により、本実施形態の輻輳解析が行われる。
【０２３３】
次に、本実施形態のリソース管理装置における処理の具体例を説明する。
【０２３４】
図２０は、音声通話アプリケーションから音声通話開始要求が発行された場合の、第１の実施形態と本実施形態のリソース管理装置における各ブロック間のシーケンスを示す図である。同図では、音声通話アプリケーション１１２から音声通話の開始要求が発行されてからその応答が返ってくるまでの応答時間の差を比較しやすいように、機能を追加する際に、レスポンスの一番遅い動画編集が、データベースの先頭から一番近いレコードにあったために選択された場合について示している。また、ここでは、静止画編集をレスポンスの一番早い例として示している。
【０２３５】
ＡＶ再生モジュール１１４、５１４の動画編集機能と静止画処理モジュール１１３、５１３の静止画編集機能とが起動していて使用可能な状態で、音声通話アプリケーション１１２から音声通話開始要求が音声通話モジュール１１５、５１５へ送信された場合（この時間をｔ０＝０とする）、それを受信した音声通話モジュール１１５、５１５は、輻輳解析部２２２、５２２へ音声通話機能追加要求を送信する。
【０２３６】
本実施形態のリソース管理装置では、音声通話機能追加要求を受信した輻輳解析部５２２は、リソースの輻輳を検出し、削除対象候補の拡張機能として静止画処理モジュール５１３の静止画編集機能とＡＶ再生モジュール５１４の動画編集機能が決定され、それぞれに対して静止画編集機能の削除問合せと動画編集機能の削除問合せとを応答処理部５２５に行う。
【０２３７】
次に、静止画編集機能の削除問合せと動画編集機能削除問合せとを受信した応答処理部５２５は、静止画処理モジュール５１３とＡＶ再生モジュール５１４に対してそれぞれ静止画編集機能の削除問合せと動画編集機能の削除問合せを送信する。
【０２３８】
すると、静止画編集機能の削除問合せを受け取った静止画処理モジュール５１３は、静止画処理アプリケーション１１０に問合せを行い、その結果、応答処理部５２５に承認応答を返す。
【０２３９】
動画編集機能削除問合せを受け取ったＡＶ再生モジュール５１４も同様に、ＡＶ再生アプリケーション１１１に問合せを行い、その結果、応答処理部５２５に承認応答を返す。
【０２４０】
この場合、静止画処理モジュール５１３の方がＡＶ再生モジュール５１４よりも早く承認応答を返したため、静止画処理モジュール５１３は応答処理部５２５から削除要求を受信し、ＡＶ再生モジュール５１４は応答処理部５２５からキャンセルを受信する。
【０２４１】
削除要求を受け取った静止画処理モジュール５１３は、静止画編集の終了処理を行い、その結果、応答処理部５２５に削除応答を返す。
【０２４２】
キャンセルを受け取ったＡＶ再生モジュール５１４は、動画編集機能が削除されず、引き続き動画編集を継続することが可能である。
【０２４３】
次に、削除応答を受信した応答処理部５２５は、輻輳解析部５２２に静止画編集の削除応答を返す。そして、その削除応答を受け取った輻輳解析部５２２は、静止画編集機能が使用しているリソースを解放し、音声通話機能が使用するリソースを確保して、音声通話モジュール５１５に機能追加応答を返す。
【０２４４】
機能追加応答を受信した音声通話モジュール５１５は、音声通話アプリケーション１１２に音声通話開始応答を返す（この時間をｔ１とする）。
【０２４５】
一方、第１の実施形態に係るリソース管理装置では、輻輳解析部２２２は、データベース部２２１の先頭から登録されている拡張機能から削除問合せを行うので、最初にＡＶ再生モジュール１１４に動画編集機能削除問合せを行う。
【０２４６】
次に、動画編集機能の削除問合せを受け取ったＡＶ再生モジュール１１４は、ＡＶ再生アプリケーション１１１に問合せを行い、その結果、動画編集機能の終了要求を得る。
【０２４７】
そして、ＡＶ再生モジュール１１４は、動画編集終了要求により動画編集機能の終了処理を行い、輻輳解析部２２２に削除応答を返す。
【０２４８】
削除応答を受信した輻輳解析部２２２は、動画編集機能が使用しているリソースを解放し、音声通話機能が使用するリソースを確保して、音声通話モジュール１１５に機能追加応答を返す。
【０２４９】
機能追加応答を受信した音声通話モジュール１１５は、音声通話アプリケーション１１２に音声通話開始応答を返す（この時間をｔ２とする）。
【０２５０】
図２０に示すように、第１の実施形態のリソース管理装置では、音声通話開始要求から応答が返るまでの時間がｔ２かかっていた。これに対し、本実施形態のリソース管理装置では、応答処理部で複数の削除対象である拡張機能から応答の早いものを選択することにより、音声通話開始要求から応答が返るまでの時間がｔ１となり、時間Ｔだけ短縮されていることがわかる。
【０２５１】
このように、本実施形態のリソース管理装置では、複数の削除対象候補の中から応答が速いメディアモジュールが選択できるので、アプリケーションの機能追加要求に対する応答時間を短縮することが可能となる。従って、リソースを効率的に利用しつつ、メディア処理の速度を向上させることが可能となる。
【０２５２】
なお、本実施形態のリソース管理装置において、メディアモジュールからの機能追加要求は重複しないことを前提としたが、複数のメディアモジュールから同時に機能追加要求があった場合でも、それぞれの要求に対して応答時間を短縮することが可能となる。
【０２５３】
また、本実施形態では、第１の実施形態のリソース管理装置に応答処理部を付加した例を説明したが、第２、第３の実施形態のリソース管理装置に応答処理部を付加しても有効である。その場合、拡張機能の追加要求に対して拡張機能の削除対象候補として、優先度の低いモジュール及び優先度の低い拡張機能を順に２つ以上選択する。
【０２５４】
また、以上の説明では、応答処理部５２５が、２つ以上の拡張機能についての削除問い合わせを同時に受ける例を示したが、多数のモジュールが存在し、モジュールごとに機能削除を行なう場合には、複数のモジュールについての削除問い合わせを行なうことになる。
【０２５５】
なお、本発明の各実施形態のリソース管理方法は、例えばリソース管理装置の内部または外部に保持されたプログラムによって実現することができる。
【０２５６】
【発明の効果】
本発明のリソース管理装置によれば、メディア処理機能を、基本機能と拡張機能とに分けることにより、リソースの輻輳時に起動中の拡張機能を削除することにより、メディアモジュールの並列度を向上することができる。
【０２５７】
更に、リソースの輻輳時に、削除すべき拡張機能をメディアモジュール別優先度と機能別優先度により選択することが可能となる。また、応答処理部を設けることでユーザからの機能追加要求に対する応答速度を向上させることも可能となる。
【図面の簡単な説明】
【図１】本発明の第１の実施形態に係るリソース管理装置の構成例を示すブロック図である。
【図２】第１の実施形態のリソース管理装置のうち、アプリケーション処理プロセッサ及びメディア処理プロセッサの構成を詳細に示すブロック図である。
【図３】第１の実施形態のリソース管理装置のうち、アプリケーション処理プロセッサ及びメディア処理プロセッサの構成を詳細に示すブロック図である。
【図４】第１の実施形態のリソース管理方法において、データベース部に格納されるモジュール情報の一例を示す図である。
【図５】第１の実施形態のメディア処理方法において、データベース部に格納されるモジュール状態情報の一例を示す図である。
【図６】第１の実施形態のメディア処理方法において、リソース輻輳時の処理の流れを示すフローチャート図である。
【図７】第１の実施形態のリソース管理装置において、ＣＰＵのリソース占有率の変化を示す図である。
【図８】本発明の第２の実施形態に係るリソース管理装置の構成例を示すブロック図である。
【図９】第２の実施形態のリソース管理方法において、データベース部に格納されるモジュール情報の一例を示す図である。
【図１０】第１の実施形態のメディア処理方法において、データベース部に格納されるモジュール状態情報の一例を示す図である。
【図１１】第２の実施形態のメディア処理方法において、リソース輻輳時の処理の流れを示すフローチャート図である。
【図１２】（ａ）は、第１の実施形態のリソース管理装置において、ＣＰＵのリソース占有率の変化を示す図であり、（ｂ）は、第２の実施形態のリソース管理装置において、ＣＰＵのリソース占有率の変化を示す図である。
【図１３】本発明の第３の実施形態に係るリソース管理装置の構成例を示すブロック図である。
【図１４】第３の実施形態のリソース管理方法において、データベース部に格納されるモジュール情報の一例を示す図であ
【図１５】第３の実施形態のメディア処理方法において、データベース部に格納されるモジュール状態情報の一例を示す図である。
【図１６】第３の実施形態のメディア処理方法において、リソース輻輳時の処理の流れを示すフローチャート図である。
【図１７】（ａ）は、第１の実施形態のリソース管理装置において、メモリのリソース占有率の変化を示す図であり、（ｂ）は、第３の実施形態のリソース管理装置において、メモリのリソース占有率の変化を示す図である。
【図１８】本発明の第４の実施形態に係るリソース管理装置の構成例を示すブロック図である。
【図１９】第４の実施形態のメディア処理方法において、リソース輻輳時の処理の流れを示すフローチャート図である。
【図２０】音声通話アプリケーションから音声通話開始要求が発行された場合の、第１の実施形態と第４の実施形態のリソース管理装置における各ブロック間のシーケンスを示す図である。
【符号の説明】
１００ リソース管理装置
１０１ アプリケーション処理プロセッサ
１０２ メディア処理プロセッサ
１０３ メインアプリケーション
１１０ 静止画処理アプリケーション
１１１ ＡＶ再生アプリケーション
１１２ 音声通話アプリケーション
１１３、５１３ 静止画処理モジュール
１１４、５１４ ＡＶ再生モジュール
１１５、５１５ 音声通話モジュール
１５０ 蓄積メディア
１５１ メモリ
１６０ キーデバイス
１６１ カメラ
１６２ ＬＣＤ
１６３ スピーカ
１６４ マイク
１６５ ベースバンド・プロセッサ
２２０ システム管理部
２２１、３２１，４２１ データベース部
２２２、３２２、４２２、５２２ 輻輳解析部
３２３ モジュール決定部
４２４ 機能決定部
５２５ 応答処理部
【発明の属する技術分野】
本発明は、メディア処理を行うメディア処理プロセッサにおいて、複数のメディアモジュールの同時実行を可能にするリソース管理装置及びリソース管理方法に関する。
【０００２】
【従来の技術】
従来、メディア処理のリソース管理方法として、各メディア処理で使用するリソースの最大値を予め定義しておき、メディア処理の実行時には、定義した最大値分のリソースを確保することによりリアルタイム性を保証する方法があった。この方法では、定義した最大値を越えないようにリソース割当てを制御することで複数のメディア処理の同時実行を実現していた。このような技術は、例えば特許文献１に開示されている。
【０００３】
【特許文献１】
特開平１０−２８９１１５号公報（第１図）
【０００４】
【発明が解決しようとする課題】
しかしながら、単一のメディア処理プロセッサにおいて処理するメディアの種類が増え、かつ、複数のメディア処理を同時に行う必要性が増加しているため、リソースが不足した場合に、メディア処理が使用するリソースを最適に配分することによりメディア処理の並列度を向上させる重要性が近年、より一層高まっている。
【０００５】
従来の技術は、複数のメディア処理を同時に行う場合において、メディア処理プロセッサ内リソースの最適配分を考慮したものではなく、各メディア処理ごとに常に一定量のリソースを必要としていた。このため、配分されたメディアプロセッサ内のリソースに無駄が生じ、リソースを効率的に配分することができなかった。
【０００６】
本発明は、上述の課題を解決するためになされたものであり、より多くのメディアモジュールの同時実行を可能にするメディア処理方法を提供することを目的としている。
【０００７】
【課題を解決するための手段】
本発明のリソース管理装置は、メディア処理を行なうためのメディアモジュールと、機能追加要求に際し、リソースの輻輳を生じる場合に、上記メディアモジュールの機能情報と上記メディア処理機能についてのリソース情報とを含むモジュール情報と、上記メディア処理機能の起動状態を示すモジュール状態情報とを参照してリソース配分を変更する輻輳解析部と、上記輻輳解析部が変更したリソース配分に従い、リソースの確保及び解放を行なうシステム管理部とを有するメディア処理プロセッサを備えている。
【０００８】
これにより、リソース輻輳時には、輻輳解析部が起動中の機能を削除してリソースの有効利用を図ることができるので、複数のメディア処理を並列して行なうことができる。
【０００９】
ここで、上記モジュール情報と上記モジュール状態情報とを格納するデータベース部をさらに備えていることが好ましい。
【００１０】
上記メディア処理機能は、メディア処理に必須な基本機能と、付加的な機能である拡張機能とに分かれており、機能追加要求に際し、リソースの輻輳が生じる場合に、上記輻輳解析部は、起動中の上記拡張機能を削除してから追加要求のあった機能を起動させることにより、リソースを有効に配分して遅滞なくメディア処理を行なうことができる。
【００１１】
上記メディアモジュールは複数存在し、上記モジュール情報は、メディアモジュール別優先度を含んでおり、上記メディア処理プロセッサは、リソースの輻輳を生じる場合に、上記メディアモジュール別優先度の低い上記メディアモジュールから順に削除対象として決定するためのモジュール決定部をさらに有していることにより、例えば使用頻度の低いメディア処理内の機能から削除して追加要求のあった機能を起動させることができるので、リソースを効率的に配分するとともに、処理のオーバーヘッドを低減してユーザの要求に対する応答速度を向上させることができる。
【００１２】
上記モジュール情報は、上記拡張機能についての機能別優先度を含んでおり、上記メディア処理プロセッサは、リソースの輻輳を生じる場合に、上記機能別優先度の低い上記拡張機能から順に削除対象として決定するための機能決定部をさらに有していることにより、優先度の低い拡張機能に使用されていたリソースを追加要求のあった機能に配分することができる、且つ、ユーザの要求に対する応答速度をより向上させることができる。
【００１３】
上記メディア処理プロセッサは、リソースの輻輳を生じる場合に、起動中の複数の上記拡張機能の削除を上記メディアモジュールに問い合わせ、且つ、少なくとも最初に応答した上記メディアモジュールの上記拡張機能の削除を決定するための応答処理部をさらに有していることにより、ユーザの要求に対する応答速度を向上させることができる。
【００１４】
本発明のリソース管理方法は、拡張機能と、メディア処理に必須な基本機能とに分けられたメディア処理を行なうためのメディアモジュールと、輻輳解析部と、システム管理部とを有するメディア処理プロセッサを備えたリソース管理装置を用いたリソース管理方法であって、機能追加要求に際し、リソースの輻輳を生じる場合に、上記メディアモジュールの機能情報と上記メディア処理機能についてのリソース情報とを含むモジュール情報と、上記メディア処理機能の起動状態を示すモジュール状態情報とを参照して上記輻輳解析部がリソース配分を変更するステップ（ａ）と、上記ステップ（ａ）で上記輻輳解析部が変更したリソース配分に従い、上記システム管理部がリソースの確保及び解放を行なうステップ（ｂ）とを含んでいる。
【００１５】
この方法により、リソース輻輳時に輻輳解析部がリソースの配分を適宜再配分するので、リソースの有効利用が図られ、結果として複数のメディア処理を並列して行なうことが可能となる。
【００１６】
上記ステップ（ａ）は、上記輻輳解析部が、追加要求された機能が必要とするリソース量と空きリソース量とを比較するステップ（ａ１）と、上記ステップ（ａ１）で、空きリソース量が追加要求された機能が必要とするリソース量より少ない場合に、上記輻輳解析部が、上記拡張機能のうちから起動中の機能の削除を問い合わせるステップ（ａ２）とを含んでいることにより、リソースの有効利用が図られる。
【００１７】
上記メディアモジュールは複数存在し、上記モジュール情報は、メディアモジュール別優先度を含んでおり、上記メディア処理プロセッサはモジュール決定部をさらに有しており、上記ステップ（ａ）は、上記輻輳解析部が、追加要求された機能が必要とするリソース量と空きリソース量とを比較するステップ（ａ１）と、上記ステップ（ａ１）で、空きリソース量が追加要求された機能が必要とするリソース量より少ない場合に、上記モジュール決定部が、上記メディアモジュール別優先度の低い上記メディアモジュールから順に削除対象として決定するステップ（ａ３）と、上記輻輳解析部が、上記ステップ（ａ３）で決定された上記メディアモジュールのうち、起動中の上記拡張機能の削除を問い合わせるステップ（ａ４）とを含んでいることにより、リソース輻輳時には、優先度の低いモジュールの機能から削除されるので、リソースを効率的に配分すると同時に、処理のオーバーヘッドを低減し、ユーザの要求に対するレスポンスを向上させることができる。
【００１８】
上記モジュール情報は、上記拡張機能についての機能別優先度を含んでおり、上記メディア処理プロセッサは、機能決定部をさらに有しており、上記ステップ（ａ）は、上記輻輳解析部が、追加要求された機能が必要とするリソース量と空きリソース量とを比較するステップ（ａ１）と、上記ステップ（ａ１）で、空きリソース量が追加要求された機能が必要とするリソース量より少ない場合に、上記機能決定部が、上記機能別優先度の低い起動中の上記拡張機能から順に削除対象として決定するステップ（ａ５）と、上記輻輳解析部が、上記ステップ（ａ５）で決定された上記拡張機能の削除を問い合わせるステップ（ａ６）とを含んでいることにより、優先度の低い機能から順に削除することができるので、リソースの有効利用を図りつつ、ユーザの要求に対するレスポンスの向上も併せて図ることができる。
【００１９】
上記メディア処理プロセッサは応答処理部をさらに有しており、上記ステップ（ａ）は、上記輻輳解析部が、追加要求された機能が必要とするリソース量と空きリソース量とを比較するステップ（ａ１）と、上記ステップ（ａ１）で、空きリソース量が追加要求された機能が必要とするリソース量より少ない場合に、上記輻輳解析部が、起動中の複数の上記拡張機能の削除を上記メディアモジュールに問い合わせるステップ（ａ７）と、上記ステップ（ａ７）の後、上記応答処理部が、少なくとも最初に応答した上記メディアモジュールの上記拡張機能の削除を決定するステップ（ａ８）と、上記ステップ（ａ８）の後に応答した上記メディアモジュールに対しては、上記応答処理部がキャンセルを送信するステップ（ａ９）とを含んでいることにより、応答速度にばらつきがある複数のメディアモジュールがある場合でも、ユーザの要求に対する応答速度を向上させることができる。
【００２０】
本発明の記録媒体は、機能追加要求に際し、リソースの輻輳を生じる場合に、上記メディアモジュールの機能情報と上記メディア処理機能についてのリソース情報とを含むモジュール情報と、上記メディア処理機能の起動状態を示すモジュール状態情報とを参照してリソース配分を変更するステップ（ａ）と、上記ステップ（ａ）で変更したリソース配分に従い、リソースの確保及び解放を行なうステップ（ｂ）とをコンピュータに実行させるためのプログラムを記録したコンピュータ読み取り取り可能な記録媒体である。
【００２１】
これにより、コンピュータを用いて複数のメディア処理を並行して行なうことが可能となる。
【００２２】
【発明の実施の形態】
以下、本発明の実施形態について、図面を用いて詳細に説明する。
【００２３】
（第１の実施形態）
図１は、本発明の第１の実施形態に係るリソース管理装置の構成例を示すブロック図である。同図に示すように、本実施形態のリソース管理装置１００は、ＣＰＵ（アプリケーション処理プロセッサ）１０１（以下、アプリケーション処理プロセッサ１０１と表記する）と、ＣＰＵ（メディア処理プロセッサ）１０２（以下、メディア処理プロセッサ１０２と表記する）と、蓄積メディア１５０と、メモリ１５１と、キーデバイス１６０と、カメラ１６１と、ＬＣＤ１６２と、スピーカ１６３と、マイク１６４と、ベースバンド・プロセッサ１６５とを備えている。
【００２４】
また、アプリケーション処理プロセッサ１０１は、ユーザからの要求に応じてメディアモジュールを制御してメディア処理を行うための各種アプリケーションを備える。本実施形態では、アプリケーション処理プロセッサ１０１は、メインアプリケーション１０３と、静止画処理アプリケーション１１０と、ＡＶ再生アプリケーション１１１と、音声通話アプリケーション１１２とを備えている。
【００２５】
そして、メディア処理プロセッサ１０２は、例えば１６０ＭＨｚで動作するプロセッサで、アプリケーションからの制御によりメディア処理を行う各種メディアモジュールを備える。本実施形態では、メディア処理プロセッサ１０２は、メディアモジュールとして静止画処理モジュール１１３と、ＡＶ再生モジュール１１４と、音声通話モジュール１１５とを備えている。さらに、メディア処理プロセッサ１０２は、システム管理部２２０と輻輳解析部２２２とを備えている。このシステム管理部２２０と輻輳解析部２２２が本実施形態のリソース管理装置の特徴部分であり、後で詳細に説明する。
【００２６】
以上のようなアプリケーションやモジュールは、実際には目的の処理を行なうためのソフトウェアの集合であるが、ハードウェアで構成されていても構わない。
【００２７】
各メディアモジュールはメディア処理プロセッサ１０２からメディア処理に必要なプロセッサリソース（以下、ＣＰＵリソースと表記する）を割当ててもらうことにより、メディア処理を行うことができる。例えばＡＶ再生モジュール１１４がＡＶ再生を行うためには、最大５２ＭＨｚのＣＰＵリソースが必要である。
【００２８】
蓄積メディア１５０は、メディアモジュールによって処理されるメディアデータ、例えばＡＶ再生モジュール１１４によって処理される音楽／音声データと動画データが多重化されたＭＰＥＧ４データなどを保持するための不揮発性メモリである。
【００２９】
メモリ１５１は、アプリケーション処理プロセッサ１０１上で動作する各アプリケーションのプログラムと、メディア処理プロセッサ１０２上で動作する各メディアモジュールのプログラムと、データベース部２２１とを保持するための不揮発性メモリである。さらにメモリ１５１は、メディアモジュールの実行領域として例えば５１２ｋＢのメモリサイズを含んでいる。データベース部２２１については、後で詳細に説明する。
【００３０】
また、メディアモジュールは、メモリ１５１からメディア処理に必要な領域（以下、メモリリソースと表記する）を割当ててもらうことにより、メディア処理を行うことができる。例えば音声通話モジュール１１５が音声通話を行うためには、最大１２４ＫＢのメモリリソースが必要である。
【００３１】
キーデバイス１６０は、ユーザからのキー入力（図１の信号（１））を受け付け、その内容をメインアプリケーション１０３に送信し（図１の信号（２））、メインアプリケーション１０３が、静止画処理アプリケーション１１０と、ＡＶ再生アプリケーション１１１と、音声通話アプリケーション１１２のそれぞれに制御信号を送信する（図１の信号（３））。
【００３２】
カメラ１６１は、画像データのビデオ信号を入力し、その画像データをＬＣＤ１６２や静止画処理モジュール１１３へ出力する。
【００３３】
ＬＣＤ１６２は、カメラ１６１やＡＶ再生モジュール１１４から受け取った画像データのビデオ信号を出力する（図１の信号（１１））。このデバイスは複数のメディアモジュールから共有することが可能である。
【００３４】
スピーカ１６３は、ＡＶ再生モジュール１１４や音声通話モジュール１１５から受け取った音楽／音声データのオーディオ信号を出力する（図１の信号（１２））。このデバイスは複数のメディアモジュールから共有することが可能である。
【００３５】
マイク１６４は、音声データの音声信号を入力し、その音声データを音声通話モジュール１１５へ出力する。
【００３６】
ベースバンド・プロセッサ１６５は、例えばＷ−ＣＤＭＡ方式によって他の装置との通信を行うためのプロセッサであり、受信した音声データを音声通話モジュール１１５へ出力する。また、音声通話モジュール１１５から入力された音声データを他の装置へ送信する。
【００３７】
メインアプリケーション１０３は、キーデバイス１６０から受け取ったユーザからの制御信号（図１の信号（２））を適切なアプリケーションに送信する（図１の信号（３））ことで、各アプリケーションを制御する。
【００３８】
静止画処理アプリケーション１１０は、メインアプリケーション１０３を介してキーデバイス１６０からの指示を受け、静止画処理モジュール１１３へ静止画処理制御要求、例えば静止画撮影開始要求や静止画表示要求を制御信号として送信し、その応答を制御信号として受信する。
【００３９】
ＡＶ再生アプリケーション１１１は、メインアプリケーション１０３を介してキーデバイス１６０から伝達された指示（図１の信号（３））に応じて、ＡＶ再生モジュール１１４へＡＶ再生制御要求、例えばＡＶ再生開始要求や輪郭強調などの画質調整処理開始要求を制御信号として送信し、且つその応答を制御信号として受信する（図１の信号（４）、（５））。さらに、ＡＶ再生アプリケーション１１１は、ＡＶ再生処理動作中に蓄積メディア１５０からＭＰＥＧ４などのストリームデータを取り出し（図１の信号（６））、それを多重分離処理した音楽／音声データと動画データとをＡＶ再生モジュール１１４へ出力する（図１の信号（７）及び信号（８））。
【００４０】
音声通話アプリケーション１１２は、メインアプリケーション１０３を介してキーデバイス１６０から受信したユーザの指示に応じて、音声通話モジュール１１５へ音声通話制御要求、例えば音声通話開始要求や音量設定要求を制御信号として送信し、その応答を制御信号として受信する。
【００４１】
静止画処理モジュール１１３は、静止画処理アプリケーション１１０からの静止画撮影開始要求の制御信号を受信することで静止画撮影を開始する。静止画処理モジュール１１３は、カメラ１６１から受け取った静止画データを、例えばＪＰＥＧデータに符号化し蓄積メディア１５０へ出力する。また、静止画処理モジュール１１３は、静止画処理アプリケーション１１０から要求を受けると、その度に応答の制御信号を返す。
【００４２】
ＡＶ再生モジュール１１４は、ＡＶ再生アプリケーション１１１からＡＶ再生開始要求の制御信号を受信する（図１の信号（４））ことでＡＶ再生を開始する。ＡＶ再生モジュール１１４は、ＡＶ再生アプリケーション１１１から受け取った音楽／音声データ（図１の信号（８））、例えばＡＡＣ（Ａｄｖａｎｃｅｄ Ａｕｄｉｏ Ｃｏｄｉｎｇ）データを復号化してスピーカ１６３へ出力し（図１の信号（１０））、これと同時に、受け取った動画データ（図１の信号（７））、例えばＭＰＥＧ４データを復号化し音楽／音声データと同期してＬＣＤ１６２へ出力する（図１の信号（９））。また、ＡＶ再生モジュール１１４は、ＡＶ再生アプリケーション１１１から要求を受けると、その度に応答の制御信号を返す（図１の信号（５））。
【００４３】
音声通話モジュール１１５は、音声通話アプリケーション１１２から音声通話開始要求の制御信号を受信することで音声通話を開始する。音声通話モジュール１１５は、ベースバンド・プロセッサ１６５から取得した音声データ、例えばＡＭＲデータを復号化してスピーカ１６３へ出力し、これと同時にマイク１６４から取得した音声データを符号化しベースバンド・プロセッサ１６５へ出力することにより音声通話を行う。また、音声通話モジュール１１５は、音声通話アプリケーション１１２から要求を受けると、その度に応答の制御信号を返す。
【００４４】
図２及び図３は、それぞれ本実施形態のリソース管理装置のうち、アプリケーション処理プロセッサ及びメディア処理プロセッサの構成を詳細に示すブロック図である。これらの図を用いてメディア処理プロセッサについてさらに説明する。
【００４５】
メディアモジュールは、アプリケーションを通じてユーザからの機能開始要求を受け取り、それに従って輻輳解析部２２２へ機能追加要求を制御信号として送信する。また、その機能追加要求に対する輻輳解析部２２２からの応答を、機能追加応答、あるいは機能追加キャンセルを制御信号として受信する。例えば、音声通話モジュール１１５は、音声通話アプリケーション１１２からの音声通話開始要求（図２の信号（３））に従って、輻輳解析部２２２へ音声通話機能追加要求を送信する（図２の信号（４））。そして、音声通話モジュール１１５は、輻輳解析部２２２からの機能追加応答を受信して、音声通話アプリケーション１１２へ音声通話開始応答を送信する。
【００４６】
さらに、リソース不足時（以下、リソース輻輳時と表記する）には、メディアモジュールは輻輳解析部２２２からの機能削除問合せを制御信号として受信し、その削除問合せに対し、削除応答あるいはキャンセル応答を制御信号として送信する。メディアモジュールは、必要ならばその機能削除処理をアプリケーションへ制御信号として転送し、その応答を制御信号として受信することにより、アプリケーションに任せることができる。例えば、ＡＶ再生モジュール１１４は、輻輳解析部２２２から起動している動画編集機能の削除問合せを受信すると、ＡＶ再生アプリケーション１１２へ動画編集終了問合せを行う。そして、ＡＶ再生モジュール１１４は、ＡＶ再生アプリケーション１１２からその応答である動画編集終了要求（図３の信号（１））を受信すると、動画編集機能終了処理を行い、削除応答を輻輳解析部２２２へ送信する（図３の信号（２））。
【００４７】
システム管理部２２０は、輻輳解析部２２２からのリソース確保要求、及びリソース解放要求を制御信号として受信し、その要求に従ってメディアモジュールが使用する各リソース、ＣＰＵリソースと、メモリリソースと、カメラ１６１、ＬＣＤ１６２、スピーカ１６３、マイク１６４、ベースバンド・プロセッサ１６５の各デバイスの確保と解放を行う。さらに、システム管理部２２０は、各リソースの使用状況を算出し、その結果を制御信号として輻輳解析部２２２に出力する。
【００４８】
データベース部２２１は、図１に示すようにメモリ１５１内に存在し、各メディアモジュールをサポートする機能情報と、各機能を実行するとき必要なリソース情報とを、モジュール情報として保持している。
【００４９】
ここで、機能情報は、基本機能と拡張機能とから構成され、リソース情報はＣＰＵ演算量、メモリから確保した領域サイズ、使用するデバイスの列挙などから構成されている。
【００５０】
基本機能とはメディアモジュールのプリミティブな機能であり、当該メディアモジュールに最低限必要とされる機能を含む。これに対し、拡張機能とは基本機能に付随する機能である。音声通話モジュール１１５では基本機能として音声通話機能を持ち、拡張機能として音声メモ録音機能と、音声メモ再生機能とを持つ。また、ＡＶ再生モジュール１１４では基本機能としてＡＶ再生機能を持ち、拡張機能としてグラッフィクスとの合成などの動画編集機能と、輪郭強調などの画質調整機能などを持つ。
【００５１】
さらに、データベース部２２１は、起動したメディアモジュールとその中で使用中の機能についてのモジュール状態情報を保持している。
【００５２】
図４は、本実施形態のリソース管理方法において、データベース部２２１に格納されるモジュール情報の一例を示す図である。モジュール情報は、以下の項目を含む。
【００５３】
（１）メディアモジュール名
（２）機能情報
（ア）サポートする機能
（イ）機能分類。上述の基本機能と拡張機能とに分類される。
【００５４】
（３）リソース情報
（ア）ＣＰＵ演算量（ＭＨｚ）。メディアモジュールがこの機能を実現するために必要なＣＰＵリソースの量である。
【００５５】
（イ）メモリサイズ（ＫＢ）。メディアモジュールがこの機能を実現するために必要な命令及びデータを保持するのに必要なメモリリソースの量である。
【００５６】
（ウ）使用デバイス。メディアモジュールがメディア処理に必要なデバイスである。複数のデバイスを列挙することができる。また、デバイスには共有可能なデバイスがある。
【００５７】
本実施形態のリソース管理装置では、データベース部２２１には、静止画処理モジュール１１３と、ＡＶ再生モジュール１１４と、音声通話モジュール１１５に関するモジュール情報が保持されている。ＡＶ再生モジュール１１４のモジュール情報に含まれる機能情報には基本機能としてＡＶ再生機能があり、拡張機能として動画編集機能と、画質調整機能と、イコライズ機能が設定されている。さらに、リソース情報としてＡＶ再生には、最大５２ＭＨｚのＣＰＵリソースと最大２２６ＫＢのメモリリソースが必要で、ＬＣＤ１６２とスピーカ１６３の各デバイスを使用することが設定されている。
【００５８】
図５は、本実施形態のメディア処理方法において、データベース部２２１に格納されるモジュール状態情報の一例を示す図である。モジュール状態情報は、次の項目を含む。
【００５９】
（１）起動したメディアモジュール名
（２）起動した機能名
本実施形態のリソース管理装置では、静止画処理モジュール１１３と、ＡＶ再生モジュール１１４と、音声通話モジュール１１５に関するモジュール状態情報が保持されている。図５に示す例では、ＡＶ再生モジュール１１４のＡＶ再生機能、動画編集機能、及び画質調整機能が起動され、使用可能であることが設定されている。
【００６０】
輻輳解析部２２２は、メディアモジュールから機能追加要求を制御信号として受信し、機能追加要求に含まれるメディアモジュール名と機能をキーとしてデータベース部２２１から対応するリソース情報を取得し、同時に、システム管理部２２０から現在のリソース使用状況を取得することによりリソースの輻輳を解析する。
【００６１】
リソースの輻輳がない場合、輻輳解析部２２２は、追加要求されている機能にリソースを割り当てるためシステム管理部２２０にリソースの確保を要求し、データベース部２２１内のモジュール状態情報を更新する。そして、輻輳解析部２２２はまた、リソース確保の要求に対する結果をメディアモジュールに応答する。
【００６２】
一方、輻輳解析部２２２はリソースの輻輳がある場合、削除対象候補になった拡張機能を保持するメディアモジュールに機能削除問合せを行う。そして、問合せ結果が削除応答であれば、その機能が確保しているリソースを解放するようにシステム管理部２２０に要求し、その後、要求された機能を追加するためにリソース割当てを要求する。このように、データベース部２２１のモジュール状態情報を更新し、メディアモジュールに応答する。
【００６３】
次に、本実施形態のメディア処理方法におけるリソース輻輳時の処理の流れを説明する。
【００６４】
図６は、本実施形態のメディア処理方法において、リソース輻輳時の処理の流れを示すフローチャート図である。輻輳の解析、拡張機能の削除、要求された機能の追加の各処理の流れを以下に説明する。
【００６５】
まず、ステップＳ６０１で、輻輳解析部２２２はメディアモジュールから機能追加要求を受信し、その機能追加要求に含まれるモジュール名と拡張機能とをキーとして、データベース部２２１のモジュール情報から追加する機能についてのリソース情報を取得する。
【００６６】
次に、ステップＳ６０２で、システム管理部２２０から現在のリソース使用状況を取得する。本ステップでは、ＣＰＵ及びメモリのリソース使用状況、及びデバイスの使用状況についての情報を取得する。
【００６７】
これに続くステップＳ６０３では、上述のステップＳ６０１及びＳ６０２で取得したリソース情報から、ＣＰＵと、メモリと、デバイスのそれぞれに関して追加要求された機能が必要なリソース量と空きリソース量とを輻輳解析部２２２が比較する。本ステップで追加機能が必要とするリソース量より空きリソース量の方が多い場合（本ステップでＹｅｓの場合）、ステップＳ６０４へ移行する。空きリソースが十分でない場合（本ステップでＮｏの場合）、ステップＳ６０６へ移行する。
【００６８】
次に、ステップＳ６０４では、先にステップＳ６０１で取得したリソース情報をもとに、輻輳解析部２２２が、システム管理部２２０にＣＰＵと、メモリと、デバイスのそれぞれに関してリソースを確保するように要求する。
【００６９】
そして、ステップＳ６０５では、ステップＳ６０４で追加した機能の状態を登録するためデータベース部２２１のモジュール状態情報を変更し、機能追加要求を送信したメディアモジュールに対して輻輳解析部２２２が機能追加応答を送信する。この時、後述するステップＳ６１２で拡張機能を削除した場合には、この機能の状態もデータベース部２２１のモジュール状態情報に登録する。
【００７０】
一方、ステップＳ６０３で追加要求された機能が必要とするリソースを確保できない場合には、輻輳解析部２２２は、起動している拡張機能の中から削除対象候補となる拡張機能を決定するため、起動しているメディアモジュールを検索する。そして、選択されたメディアモジュールの中から起動している拡張機能を検索し、削除対象候補になりうる拡張機能を検出する。以下にこの手順を示す。
【００７１】
まず、ステップＳ６０６で、データベース部２２１に格納されているモジュール状態情報の先頭から順に起動しているメディアモジュールを検索し、見つかった場合（本ステップでＹｅｓの場合）には、ステップＳ６０７へ移行する。モジュール状態情報のレコードの中から起動しているメディアモジュールが見つからない場合（本ステップでＮｏの場合）、選択されたメディアモジュール内には、削除可能な拡張機能が見つからなかったとして、ステップＳ６１３へ移行する。
【００７２】
次に、ステップＳ６０７では、先のステップＳ６０６で選択されたメディアモジュールにおいて、起動している拡張機能の中から削除すべき拡張機能を一つ決定するために、選択されたメディアモジュールに相当するモジュール状態情報のレコードを、輻輳解析部２２２が先頭から順に検索する。その結果、モジュール状態情報から起動している拡張機能が見つかった場合（本ステップでＹｅｓの場合）、ステップＳ６０８へ移行する。モジュール状態情報のレコードから起動している拡張機能が見つからない場合（本ステップでＮｏの場合）には、選択されたメディアモジュールから削除可能な拡張機能が見つからなかったとして、上述のステップＳ６０６へ移行し処理を繰り返す。
【００７３】
次いで、ステップＳ６０８では、先のステップＳ６０７で選択された拡張機能のリソース情報をデータベース部２２１から取得する。
【００７４】
次に、ステップＳ６０９では、上述のステップＳ６０１、Ｓ６０２、Ｓ６０８でそれぞれ取得したリソース情報から、ＣＰＵと、メモリと、デバイスのそれぞれに関して、追加要求機能が必要なリソース量と、拡張機能が確保しているリソース量と空きリソース量との和を比較する。追加機能が必要とするリソース量に比べて、空きリソース量と選択された拡張機能が確保しているリソース量との和が多い場合（本ステップでＹｅｓの場合）、削除対象候補となる拡張機能が決定し、ステップＳ６１０へ移行する。ここで、１つの拡張機能のみでは追加機能に必要なリソース量を確保できない場合、２つ以上の拡張機能を削除対象としてもよい。一方、追加機能が必要とするリソースが確保できない場合（本ステップでＮｏの場合）、選択された拡張機能は、削除対象候補ではない、として上述のステップＳ６０７へ移行し処理を繰り返す。
【００７５】
続いて、ステップＳ６１０では、上述のステップＳ６０６で選択されたメディアモジュールに対して輻輳解析部２２２が機能削除問合せを行い、それに対する応答を待つ。
【００７６】
次に、ステップＳ６１１では、先のステップＳ６１０でメディアモジュールに対して行った機能削除問合せの応答を判定する。すなわち、機能削除問い合わせの応答が、削除応答である場合（本ステップでＹｅｓの場合）、その拡張機能が削除されることが決定しステップＳ６１２へ移行する。また、応答がキャンセルである場合（本ステップでＮｏの場合）、その拡張機能は削除できないことが決定し、上述のステップＳ６０７へ移行して処理を繰り返す。
【００７７】
次に、ステップＳ６１２で、輻輳解析部２２２は、削除決定した拡張機能を削除するために、上記ステップＳ６０８で取得したリソース情報をもとに、システム管理部２２０にＣＰＵと、メモリと、デバイスのそれぞれに関してリソースを解放するように要求する。そして、上述のステップＳ６０４へ移行する。
【００７８】
これに対し、ステップＳ６１３では、上述のステップＳ６０６で削除可能な拡張機能が見つからなかった場合、機能追加要求を送信したメディアモジュールに対して輻輳解析部２２２が機能追加キャンセルを送信する。以上の手順で輻輳解析は行われる。
【００７９】
次に、本実施形態のリソース管理装置における輻輳解析について、例を挙げて具体的に説明する。
【００８０】
図７は、本実施形態のリソース管理装置において、ＣＰＵのリソース占有率の変化を示す図である。特に、音声通話機能追加前と追加後のＣＰＵリソースの変化を示すために、時間Ａと時間Ｂの時点における各メディアモジュールのＣＰＵリソースの占有率について示している。
【００８１】
図５に示すように、ＡＶ再生モジュール１１４のＡＶ再生機能と、動画編集機能と、画質調整機能とが起動され使用可能である状態で、ユーザから音声通話アプリケーション１１２に音声通話要求があった場合（図２の信号（１）、（２））に、音声通話アプリケーション１１２は、音声通話モジュール１１５へ音声通話開始要求を送信する（図２の信号（３））。音声通話モジュール１１５はその要求を受けて輻輳解析部２２２へ音声通話機能追加要求を送信する（図２の信号（４））。
【００８２】
音声通話機能追加要求を受け取った輻輳解析部２２２は、その要求に含まれるメディアモジュール名と機能、すなわち音声通話モジュールと音声通話とをキーとして、図４に示すデータベース部２２１のモジュール情報から音声通話機能のリソース情報（ＣＰＵ演算量３４ＭＨｚ（ＣＰＵリソースの２１％に相当）とメモリサイズ１２４ＫＢが必要で、使用デバイスとしてスピーカ１６３とマイク１６４を使用）を取得する（図２の信号（５））。
【００８３】
これと同時に、システム管理部２２０から、ＣＰＵに関しては１６０ＭＨｚのリソースのうち、図７に示すようにＡＶ再生モジュール１１４がリソースの９０％を確保しており、１０％が未割当てであること、メモリに関しては５１２ＫＢのリソースのうち、図２に示すようにＡＶ再生モジュール１１４が４２４ＫＢを確保しており、８８ＫＢが未割当てであること、デバイスに関しては、図４に示すようにＡＶ再生モジュール１１４がＬＣＤ１６２とスピーカ１６３を使用しているというリソース使用状況を取得する（図２の信号（６））。なお、ＣＰＵに関するリソースの内訳は、ＡＶ再生が３３％の５２ＭＨｚ、動画編集が３５％の５６ＭＨｚ、画質調整が２２％の３５ＭＨｚである。
【００８４】
次に、輻輳解析部２２２は、ＣＰＵ、メモリ、デバイスについて追加要求機能の音声通話が必要とするリソース量と空きリソース量について比較する。比較の結果、ＣＰＵリソースについては２１％のリソース要求に対して１０％の空きリソースしかないため、輻輳していることを検出する。メモリリソースについても１２４ＫＢのリソース要求に対して、８８ＫＢの空きしかなく輻輳が検出される。さらに、デバイスリソースについては、スピーカ１６３がＡＶ再生モジュール１１４により使用中であるが、共有デバイスであるため輻輳は検出されない。よって、ＣＰＵリソースとメモリリソースから輻輳が検出されたため、リソースの輻輳が発生すると判定される。
【００８５】
輻輳解析部２２２は、輻輳を検出した場合、図５に示すデータベース部２２１のモジュール状態情報をもとに、起動されているメディアモジュールのモジュール情報を先頭から順に読み出す。この際には、モジュール情報のうち、起動されている拡張機能が確保しているリソース情報があるか否かを、モジュール情報の先頭から順に読み出す。
【００８６】
これにより、図４のモジュール情報からは、まずはじめにＡＶ再生モジュール１１４の動画編集機能のリソース情報（ＣＰＵ演算量５６ＭＨｚ（ＣＰＵリソースの３５％に相当）とメモリサイズ１５９ＫＢが必要）が読み出される（図２の信号（７））。
【００８７】
次に、輻輳解析部２２２は、ＣＰＵ、メモリ、デバイスについて追加要求機能の音声通話が必要とするリソース量と、動画編集機能を解放した場合のリソース量について比較する。比較の結果、ＣＰＵリソースについては２１％のリソース要求に対して３５％＋１０％＝４５％の空きリソースがあるため、さきほど検出されていた輻輳が検出されなくなる。また、メモリリソースについては１２４ＫＢのリソース要求にたいして１５９ＫＢ＋８８ＫＢ＝２４７ＫＢの空きリソースがあるため、さきほど輻輳が検出されていた輻輳が検出されなくなる。よって、リソースの輻輳が発生しないことが判定され、動画編集機能は削除対象候補になる。
【００８８】
続いて、輻輳解析部２２２は、削除対象候補である動画編集機能を保持するＡＶ再生モジュール１１４に動画編集機能の削除問合せを行う（図２の信号（８））。
【００８９】
動画編集機能の削除問合せを受け取ったＡＶ再生モジュール１１４は、動画編集機能を終了するために、ＡＶ再生アプリケーション１１１に動画編集終了問合せを行う（図２の信号（９））。
【００９０】
動画編集終了問合せを受け取ったＡＶ再生アプリケーション１１１は、動画編集を終了するために、動画編集終了要求をＡＶ再生モジュール１１４に送信する（図３の信号（１））。この時、必要ならばＧＵＩなどを通じてユーザに動画編集終了確認をおこなってもよい。
【００９１】
動画編集終了要求を受け取ったＡＶ再生モジュール１１４は、動画編集終了処理を行って、削除応答を輻輳解析部２２２に返す（図３の信号（２））。
【００９２】
削除応答を受け取った輻輳解析部２２２は、前に取得した動画編集機能のリソース情報をもとにシステム管理部２２０にリソースの解放を要求し、動画編集機能を削除する（図３の信号（３））。この時、図７に示すようにＡＶ再生モジュール１１４が確保しているＣＰＵリソースは、時点Ａの９０％から時点Ｂの５５％に減少する。また、メモリリソースについては、図３に示すように４２４ＫＢから２６５ＫＢに減少する。
【００９３】
リソース解放後、輻輳解析部２２２は、以前に取得した音声通話機能のリソース情報をもとにシステム管理部２２０にリソースの確保を要求し、音声通話機能を追加する（図３の信号（４））。この時、図７に示すように音声通話モジュール１１５が確保しているＣＰＵリソースは、時間Ａでの０％から時間Ｂでの２１％に増加する。また、メモリリソースについては、図３に示すように０ＫＢから１２４ＫＢに増加する。さらに、スピーカ１６３とマイク１６４が使用可能になる。
【００９４】
次に、輻輳解析部２２２は、動画編集機能が削除され、音声通話機能が追加された状態を保持するため、図５に示すデータベース部２２１のモジュール状態情報を更新する（図３の信号（５））。このモジュール状態情報では、ＡＶ再生モジュール１１４の動画編集機能が起動済み状態から削除され、音声通話モジュール１１５の音声通話機能が起動済み状態に登録される。その後、輻輳解析部２２２は、音声通話モジュール１１５に機能追加応答を返す（図３の信号（６））。
【００９５】
続いて、機能追加応答を受け取った音声通話モジュール１１５は、音声通話アプリケーション１１２に音声通話開始応答を返す（図３の信号（７））。
【００９６】
以上の処理を行うことにより、図７に示すように、時間ＡでＡＶ再生モジュール１１４のみが動作している状態から、音声通話アプリケーション１１２からの音声通話開始要求に応じてＡＶ再生モジュール１１４の動画編集機能を削除し、音声通話機能を追加することになる。従って、時間ＢではＡＶ再生モジュール１１４と音声通話モジュール１１５とが並行して動作している状態に移行している。
【００９７】
以上の方法により、メディアモジュールでサポートする機能を基本機能と拡張機能に分類し管理することにより、リソース輻輳時に拡張リソースから基本リソースに優先的にリソースが割当てられることができるようになる。言い換えれば、新たな機能を起動させる場合に、起動済みであっても使用していない拡張機能を削除することで、リソースを有効に使用することが可能になる。従って、本実施形態のメディア処理方法を用いれば、複数のメディア処理を不具合なく並行して行なうことができる。
【００９８】
なお、本実施形態において、基本機能と拡張機能の分類の例として、静止画処理と、ＡＶ再生処理と、音声通話処理を例として示したが、機能の分類形態はこれに限らない。例えば、ＡＶ再生処理においてＭＰ３や、ＡＡＣや、ＷＭＡといったオーディオファイルを再生するために必要なリソースも、それぞれ拡張機能として分類できる。更に、リソース管理装置が扱うリソースをＣＰＵと、メモリと、デバイスに限定したが、さらにＤＭＡバンド幅などをリソースとして追加してもよい。
【００９９】
また、本実施形態のリソース管理装置は、アプリケーション処理プロセッサとメディア処理プロセッサとが個別に設けられていたが、これらがアプリケーション処理とメディア処理を共通のプロセッサで行なう場合にも、本実施形態のメディア処理方法は適用できる。
【０１００】
なお、本実施形態のリソース管理装置では、モジュール情報を格納するデータベース部２２１がメディア処理プロセッサ１０２内に設けられていたが、データベース部２２１をリソース管理装置の外部に設けていてもよい。
【０１０１】
（第２の実施形態）
図８は、本発明の第２の実施形態に係るリソース管理装置の構成例を示すブロック図である。
【０１０２】
同図に示す本実施形態のリソース管理装置１００は、アプリケーション処理プロセッサ１０１と、メディア処理プロセッサ１０２とを備えている。
【０１０３】
アプリケーション処理プロセッサ１０１は、メインアプリケーション１０３と、静止画処理アプリケーション１１０と、ＡＶ再生アプリケーション１１１と、音声通話アプリケーション１１２とを有している。
【０１０４】
また、メディア処理プロセッサ１０２は、静止画処理モジュール１１３と、ＡＶ再生モジュール１１４と、音声通話モジュール１１５と、システム管理部２２０と、輻輳解析部３２２と、データベース部３２１と、モジュール決定部３２３とを有している。
【０１０５】
本実施形態のリソース管理装置は、モジュール決定部３２３がメディア処理プロセッサ１０２内に設けられている点が第１の実施形態のリソース管理装置と異なっている。また、第１の実施形態のリソース管理装置におけるデータベース部２２１、輻輳解析部２２２は、本実施形態のリソース管理装置ではそれぞれデータベース部３２１、輻輳解析部３２２となっている。
【０１０６】
本実施形態のリソース管理装置に追加された構成要素について、以下に説明する。
【０１０７】
図９は、本実施形態のリソース管理方法において、データベース部３２１に格納されるモジュール情報の一例を示す図であり、図１０は、本実施形態のメディア処理方法において、データベース部３２１に格納されるモジュール状態情報の一例を示す図である。
【０１０８】
図９に示すモジュール情報と図１０に示すモジュール状態情報とは、共にデータベース部３２１に保持されている。ここで、モジュール情報は、図４に示すモジュール情報と同じく機能情報とリソース情報から構成されているが、機能情報にメディアモジュール別優先度が追加されている。
【０１０９】
メディアモジュール別優先度は、リソース輻輳時に、起動している拡張機能の中で削除するものはどれであるかを指定する、つまり削除対象候補を決定するための指標である。第１の実施形態では、リソース輻輳時にデータベースの先頭から削除対象候補となりうる拡張機能を検索することにより削除対象候補となった拡張機能を削除していたが、削除された拡張機能がすぐに必要になり、別の拡張機能を削除してその機能を追加するといったことが起こる可能性があった。そこで、本実施形態では、あらかじめユーザの使用頻度などをもとに拡張機能に削除時の優先順位を付けることとし、機能の追加と削除が不必要に繰り返されるのを防ぐこととしている。
【０１１０】
本実施形態の例では、図９のモジュール情報において、ユーザの使用頻度に応じて静止画処理モジュール１１３に優先度７を、ＡＶ再生モジュール１１４に優先度５を、音声通話モジュール１１５に優先度２をつけている。ここでは、メディアモジュール別優先度は番号の小さいものから順に高くなるものとする。
【０１１１】
また、モジュール決定部３２３は、輻輳解析部３２２からのモジュール決定要求を制御信号として受信すると、データベース部３２１からモジュール情報とメディアモジュール状態情報を読み出し、起動しているメディアモジュールの中からメディアモジュール別優先度の一番低いメディアモジュールを検索する。モジュール決定部３２３は、その結果、見つかったメディアモジュール名を制御信号として輻輳解析部３２２に出力する。
【０１１２】
輻輳解析部３２２から、同一の機能追加要求に対して、再度モジュール決定要求があった場合には、モジュール決定部３２３は、前回返したメディアモジュールの次に高い優先度をもつメディアモジュール名を返す。
【０１１３】
輻輳解析部３２２は、第１の実施形態で示した輻輳解析部２２２の機能に加えて、機能追加要求時においてリソースの輻輳を検出した場合、削除対象候補となりうる拡張機能を決定するためにモジュール決定部３２３にモジュール決定要求を制御信号として送信する。その後、輻輳解析部３２２は、モジュール決定部３２３からメディアモジュール名を制御信号として受信する。
【０１１４】
本発明の実施の形態における輻輳解析部３２２が、輻輳を解析し、リソース輻輳時にはモジュール決定部を使用して削除対象候補となった拡張機能を削除し、要求された機能を追加する処理の流れを図を用いて説明する。
【０１１５】
図１１は、本実施形態のメディア処理方法において、リソース輻輳時の処理の流れを示すフローチャート図である。
【０１１６】
まず、ステップＳ７０１で、輻輳解析部３２２は、メディアモジュールから機能追加要求を受信すると、その要求に含まれるモジュール名と拡張機能とをキーとしてデータベース部３２１のモジュール情報から追加する機能についてのリソース情報を取得する。
【０１１７】
次に、ステップＳ７０２で、システム管理部２２０から現在のリソース使用状況を取得する。
【０１１８】
続いて、ステップＳ７０３で、上述のステップＳ７０１、Ｓ７０２で取得したリソース情報及びリソース使用情報から、ＣＰＵと、メモリと、デバイスのそれぞれに関して追加要求された機能に必要とされるリソース量と空きリソース量とを比較する。追加機能が必要なリソース量より空きリソース量が多い場合（本ステップでＹｅｓの場合）、ステップＳ７０４へ移行する。また、空きリソースが十分でない場合（本ステップでＮｏの場合）、ステップＳ７０６へ移行する。
【０１１９】
そして、ステップＳ７０４で、追加要求された機能が必要とするリソースが確保できる場合に、輻輳解析部３２２は、上記ステップＳ７０１で取得したリソース情報をもとに、システム管理部２２０にＣＰＵと、メモリと、デバイスのそれぞれに関してリソースを確保するように要求する。
【０１２０】
次に、ステップＳ７０５で、輻輳解析部３２２は、上述のステップＳ７０４で追加した機能の状態を登録するためにデータベース部３２１内のモジュール状態情報を変更し、機能追加要求を送信したメディアモジュールに対して機能追加応答を送信する。この時、後述するステップＳ７１３で拡張機能を削除した場合には、この機能の状態もデータベース部３２１のモジュール状態情報に登録する。
【０１２１】
一方、追加要求された機能が必要とするリソースを確保するのに十分なリソースがない場合（ステップＳ７０３でＮｏの場合）、輻輳解析部３２２は、起動している拡張機能の中から削除対象候補となる拡張機能を決定するため、モジュール決定部３２３にモジュール決定要求を行う。そして、輻輳解析部３２２は、選択されたメディアモジュールの中で起動している拡張機能を検索し、削除対象候補となりうる拡張機能を検出する。
【０１２２】
まず、ステップＳ７０６で、輻輳解析部３２２は、起動しているメディアモジュールの中からモジュール別優先度に基づいてメディアモジュールを一つ選択するため、モジュール決定部３２３にモジュール決定要求を送信する。
【０１２３】
続いて、ステップＳ７０７では、起動しているメディアモジュールがあるかどうかを判定する。ここで、メディアモジュールが見つかったという応答がモジュール決定部から返った場合（本ステップでＹｅｓの場合）には、ステップＳ７０８へ移行する。一方、メディアモジュールが見つからなかったという応答が返った場合（本ステップでＮｏの場合）、削除可能な拡張機能が見つからなかったとして、ステップＳ７１４へ移行する。
【０１２４】
次に、ステップＳ７０８で、先のステップＳ７０７で選択されたメディアモジュールにおいて、起動している拡張機能の中から一つを削除候補として決定するために、輻輳解析部３２２は、選択されたメディアモジュールに対応するモジュール状態情報のレコードの先頭から順に検索する。本ステップでモジュール状態情報から起動している拡張機能が見つかった場合（本ステップでＹｅｓの場合）、ステップＳ７０９へ移行する。また、モジュール状態情報のレコードから起動している拡張機能が見つからない場合（本ステップでＮｏの場合）、選択されたメディアモジュールから削除可能な拡張機能が見つからなかったことで、ステップＳ７０６へ移行し、処理を繰り返す。
【０１２５】
次に、ステップＳ７０９では、先のステップＳ７０８で選択された拡張機能のリソース情報をデータベース部３２１から取得する。
【０１２６】
次いで、ステップＳ７０１では、輻輳解析部３２２が、上述のステップＳ７０１と、Ｓ７０２、Ｓ７０９で取得したリソース情報をもとに、ＣＰＵと、メモリと、デバイスのそれぞれに関して、追加要求機能が必要なリソース量と、拡張機能が確保しているリソース量と空きリソース量との和を比較する。本ステップで、追加機能が必要とするリソース量より空きリソース量と選択された拡張機能が確保しているリソース量との和の方が多い場合（本ステップでＹｅｓの場合）、削除対象候補となる拡張機能が決定し、ステップＳ７１１へ移行する。また、追加機能が必要とするリソースを確保できない場合（本ステップでＮｏの場合）、選択された拡張機能は、削除対象候補ではないとして上述のステップＳ７０８へ移行し処理を繰り返す。なお、１つの削除候補では十分な空きリソースが確保できない場合、再度本ステップの処理を行なう際に、複数個の削除候補を選択することもできる。
【０１２７】
そして、ステップＳ７１１では、削除対象候補が決定された場合（ステップＳ７１０でＹｅｓの場合）に、輻輳解析部３２２が上記ステップＳ７０６で選択されたメディアモジュールに対して機能削除問合せを行い、それに対する応答を待つ。
【０１２８】
次に、ステップＳ７１２では、上述のステップＳ７１１で行った機能削除問合せの応答が削除応答である場合（本ステップでＹｅｓの場合）、その拡張機能が削除されることが決定し、ステップＳ７１３へ移行する。また、応答がキャンセルである場合（本ステップでＮｏの場合）、その拡張機能は削除できないことが決定し、上記ステップＳ７０８へ移行して処理を繰り返す。
【０１２９】
次いで、ステップＳ７１３では、削除決定した拡張機能を削除するために、上記ステップＳ７０９で取得したリソース情報をもとに、輻輳解析部３２２がシステム管理部２２０にＣＰＵと、メモリと、デバイスのそれぞれに関してリソースを解放するように要求する。そして、処理はステップＳ７０４へ移行する。
【０１３０】
一方、ステップＳ７１４では、上述のステップＳ７０７において、起動しているメディアモジュールが見つからなかった場合（ステップＳ７０７でＮｏの場合）、機能追加要求を送信したメディアモジュールに対して機能追加キャンセルを送信する。以上の手順で、輻輳解析を行なうことができる。
【０１３１】
次に、本実施形態のリソース管理装置における輻輳解析について、例を挙げて具体的に説明する。
【０１３２】
図１２（ａ）は、第１の実施形態のリソース管理装置において、ＣＰＵのリソース占有率の変化を示す図であり、（ｂ）は、本実施形態のリソース管理装置において、ＣＰＵのリソース占有率の変化を示す図である。なお、同図は、静止画処理モジュール１１３と、ＡＶ再生モジュール１１４と、音声通話モジュール１１５とが確保しているメモリリソースの割合を図示しており、特に、メディアモジュール別優先度の有効性を示すために、アプリケーションから２つの異なる拡張機能の開始要求が交互に行われる場合について示している。
【０１３３】
図１０に示す例では、静止画処理モジュール１１３の静止画撮影機能と静止画編集機能が起動され、ＡＶ再生モジュール１１４のＡＶ再生機能と画質調整機能が起動され、音声通話モジュール１１５の音声通話機能が起動されて、それぞれが使用可能である状態となっている。
【０１３４】
この状態で、ユーザから音声通話アプリケーション１１２を通じて音声通話モジュール１１５へ音声メモ録音開始要求があると、音声通話モジュール１１５はその要求を受けて輻輳解析部３２２へ音声メモ録音機能の追加要求を送信する。
【０１３５】
音声メモ録音機能の追加要求を受け取った輻輳解析部３２２は、音声通話モジュールと音声メモ録音とをキーとして図９に示すデータベース部３２１のモジュール情報から音声メモ録音のリソース情報（ＣＰＵ演算量１０ＭＨｚ（ＣＰＵリソースの６％に相当）とメモリサイズ２１ＫＢ（メモリリソースの４％に相当）が必要）を取得する。
【０１３６】
これと同時に、輻輳解析部３２２は、システム管理部２２０から次のようなリソース使用状況を取得する。
【０１３７】
ＣＰＵに関しては１６０ＭＨｚのリソースのうち、図９に示すように静止画処理モジュール１１３がリソースの１０％（内訳は、静止画撮影が５％の８ＭＨｚ、静止画編集が５％の７ＭＨｚ）を、ＡＶ再生モジュール１１４がリソースの５５％（内訳は、ＡＶ再生が３３％の５２ＭＨｚ、画質調整が２２％の３５ＭＨｚ）を、音声通話モジュール１１５の音声通話がリソースの２１％にあたる３４ＭＨｚをそれぞれ確保しており、残り１４％が未割当てである。メモリに関しては５１２ＫＢのリソースのうち、図１２に示すように静止画処理モジュール１１３がリソースの２２％（内訳は、静止画撮影が１５％の７８ＫＢ、静止画編集が６％の３３ＫＢ）を、ＡＶ再生モジュール１１４がリソースの５２％（内訳は、ＡＶ再生が４４％の２２６ＫＢ、画質調整が８％の３９ＫＢ）を、音声通話モジュール１１５の音声通話がリソースの２４％にあたる１２４ＫＢをそれぞれ確保しており、残り２％が未割当てである。デバイスに関しては、図９に示すように、静止画処理モジュール１１３がＬＣＤ１６２を、ＡＶ再生モジュール１１４がＬＣＤ１６２とスピーカ１６３を、音声通話モジュール１１５がスピーカ１６３とマイク１６４とベースバンド・プロセッサ１６５を使用している。
【０１３８】
次に、輻輳解析部３２２は、ＣＰＵ、メモリ、デバイスについて追加要求機能である音声通話が必要とするリソース量と空きリソース量とを比較する。比較の結果、ＣＰＵリソースについては６％のリソース要求に対して１４％の空きリソースがあるため、輻輳は検出されない。メモリリソースについては、図１２（ｂ）に示すように４％のリソース要求に対して空きが２％しかないため、輻輳解析部３２２は輻輳を検出する。さらに、デバイスリソースについては、輻輳は検出されない。よって、メモリリソースから輻輳が検出されたため、リソースの輻輳が発生することが判定される。
【０１３９】
図１２（ａ）に示すように、第１の実施形態のリソース管理装置において輻輳が検出された場合、輻輳解析部２２２は、図１０に示すモジュール状態情報の先頭から一番近い起動済み拡張機能である画質調整機能を削除対象候補に決定し、ＡＶ再生モジュール１１４に機能削除を要求する。その結果、画質調整機能が削除され、輻輳解析部２２２は要求された音声メモ録音機能を追加する。そして、音声通話アプリケーション１１２は音声メモ録音を開始する。
【０１４０】
しかし、しばらく後、ユーザからＡＶ再生アプリケーション１１１を通じてＡＶ再生モジュール１１４へ画質調整機能の開始要求があると、図１２（ａ）に示すように輻輳解析部２２２はリソースの輻輳を検出し、図１０に示すモジュール状態情報の先頭から一番近い起動済み拡張機能を決定する。この際に、輻輳解析部２２２は、先程追加された音声メモ録音機能を削除対象候補として決定し削除する。そして、画質調整処理が起動する。
【０１４１】
その後、再度ユーザから音声メモ録音機能の追加要求があると、輻輳解析部２２２は先程起動した画質調整機能を削除して音声メモ録音機能を追加する。
【０１４２】
以上のように、第１の実施形態のリソース管理装置では、ユーザからの拡張機能開始要求ごとに機能の追加と削除が発生している。このように、リソース輻輳状態においてユーザが拡張機能を次々と使用するような場合、機能追加と削除にともなう無駄なオーバヘッドが発生する。
【０１４３】
これに対し、本実施形態のリソース管理装置において、輻輳解析部３２２が輻輳を検出した場合には、削除対象候補となる拡張機能を決定するため、モジュール決定部３２３にモジュール決定要求を送信する。
【０１４４】
モジュール決定要求を受信したモジュール決定部３２３は、図９に示すモジュール情報と図１０に示すモジュール状態情報から起動中のメディアモジュールの中で優先度の一番低い静止画処理モジュールを輻輳解析部３２２へ返す。
【０１４５】
次に、モジュール決定部３２３から静止画処理モジュールが選択されると、輻輳解析部３２２は、図１０に示す静止画処理モジュール内のモジュール状態情報を検索し、先頭から順に起動している拡張機能を読み出す。ここでは、図１２（ｂ）に示すように、静止画編集機能が削除対象候補として決定されて削除される。
【０１４６】
その後、ユーザから音声メモ録音機能の開始要求が出された場合、すでに起動済みであるので拡張機能の削除および追加を再度行なう必要はない。
【０１４７】
以上のように、本実施形態のリソース管理装置では、図１２（ｂ）に示すようにユーザから画質調整機能の開始要求と音声メモ録音の開始要求とが交互に出されても拡張機能の追加、あるいは削除が発生しない。すなわち、あらかじめユーザの使用頻度が高い順にメディアモジュールの優先度を決めておくことで、余計な機能追加と削除の手間が省けるので、ユーザの要求に対する応答速度が向上する。
【０１４８】
このように、メディア処理の各機能を基本機能と拡張機能に分けた上で、メディアモジュールごとに優先度を設定することで、リソース輻輳時に優先度の低いメディアモジュールから所望のメディアモジュールへとリソースが割り当てられることとなり、リソースを効率的に配分することができるようになる。従って、本実施形態のリソース管理装置によれば、第１の実施形態よりもさらに効率的に複数のメディア処理を並列して行なうことが可能となる。
【０１４９】
なお、本実施形態のメディア処理方法では、メディアモジュール別優先度の例として、ユーザの使用頻度に応じた優先度を示したが、優先度のつけ方はこれに限らない。
【０１５０】
また、メディアモジュール別優先度は固定されている必要はなく、動的につけてもよい。例えば、使用頻度の高い機能はユーザごとに異なっているので、メモリ１５１に各機能の使用履歴などを記憶しておき、これに基づいて優先度を決定することもできる。
【０１５１】
（第３の実施形態）
図１３は、第３の実施形態に係るリソース管理装置の構成例を示すブロック図である。
【０１５２】
同図に示す本実施形態のリソース管理装置１００は、アプリケーション処理プロセッサ１０１と、メディア処理プロセッサ１０２とを備えている。
【０１５３】
アプリケーション処理プロセッサ１０１は、メインアプリケーション１０３と、静止画処理アプリケーション１１０と、ＡＶ再生アプリケーション１１１と、音声通話アプリケーション１１２とを有している。
【０１５４】
また、メディア処理プロセッサ１０２は、静止画処理モジュール１１３と、ＡＶ再生モジュール１１４と、音声通話モジュール１１５と、システム管理部２２０と、輻輳解析部４２２と、データベース部４２１と、機能決定部４２４とを有している。
【０１５５】
本実施形態のリソース管理装置は、メディア処理プロセッサ１０２内に機能決定部４２４が設けられている点が第１の実施形態のリソース管理装置と異なっている。また、データベース部２２１はデータベース部４２１に、輻輳解析部２２２は輻輳解析部４２２として示している。
【０１５６】
本実施形態のリソース管理装置による輻輳解析について、以下に説明する。
【０１５７】
図１４は、本実施形態のリソース管理方法において、データベース部４２１に格納されるモジュール情報の一例を示す図であり、図１５は、本実施形態のメディア処理方法において、データベース部４２１に格納されるモジュール状態情報の一例を示す図である。
【０１５８】
図１４に示すモジュール情報と図１５に示すモジュール状態情報とは、共にデータベース部４２１に保持されている。ここで、モジュール情報は機能情報とリソース情報、及びメディアモジュール別優先度を含んでいる。なお、このモジュール別優先度は、第２の実施形態で説明したものと同じものである。これに加え、本実施形態においてモジュール情報は、機能別優先度も含んでいる。
【０１５９】
ここで、機能別優先度は、リソース輻輳時にモジュール別優先度を使って選択されたメディアモジュールの中から、削除対象候補となる拡張機能を決定するための指標である。そのため、第１、第２の実施形態と同様に、基本機能に優先度はない。
【０１６０】
第２の実施形態に係るリソース管理装置では、リソース輻輳時に、モジュール決定部３２３が優先度の低いモジュールから順に削除対象候補に選定していた。しかし、モジュール全体としての優先度は低くても、使用頻度の高い機能を含む場合には、削除された拡張機能がすぐに必要になり、別の拡張機能を削除してその機能を追加するといったことが起こる可能性があった。このため、本実施形態のメディア処理方法では、モジュールに含まれる拡張機能にも優先度を付して、リソースの輻輳が生じる際には、機能別優先度も参照して削除する機能を決定することとした。
【０１６１】
本実施形態の例では、図１４に示すようにユーザの使用頻度に応じて静止画処理モジュール１１３に優先度７を、ＡＶ再生モジュール１１４に優先度５を、音声通話モジュール１１５に優先度２をつけている。また、ＡＶ再生モジュール１１４内の拡張機能をユーザの使用頻度に応じて動画編集機能に優先度２を、画質調整機能に優先度４を、イコライズ機能に優先度５を設定している。ここでは、メディアモジュール別優先度と機能別優先度とも、番号の小さいものから順に高くなっているものとする。
【０１６２】
機能決定部４２４は、輻輳解析部４２２からの機能決定要求を制御信号として受信すると、データベース部４２１からモジュール情報とメディアモジュール状態情報とを読み出し、起動しているメディアモジュールの中からメディアモジュール別優先度の低いメディアモジュールを選択する。次に、選択したメディアモジュールの起動中の拡張機能の中から起動別優先度の一番低い拡張機能を削除対象拡張機能として検出する。そして、その結果を制御信号として輻輳解析部４２２に出力する。
【０１６３】
輻輳解析部４２２から、同一の機能追加要求に対して、二回目以降の機能決定要求があった場合には、機能決定部４２４は、前回返した拡張機能の次に高い優先度をもつ拡張機能を返す。
【０１６４】
輻輳解析部４２２は、第１の実施形態の輻輳解析部２２２の機能に加えて、機能追加要求時にリソースの輻輳を検出した場合、削除対象候補となりうる拡張機能を決定するために機能決定部４２４に機能決定要求を制御信号として送信し、拡張機能を制御信号として受信する。
【０１６５】
次に、本実施形態のリソース管理装置における輻輳解析部４２２が、輻輳解析を行なう際の処理の流れを説明する。
【０１６６】
図１６は、本実施形態のメディア処理方法において、リソース輻輳時の処理の流れを示すフローチャート図である。
【０１６７】
まず、ステップＳ８０１で、輻輳解析部４２２は、メディアモジュールから機能追加要求を受信すると、その機能追加要求に含まれるモジュール名と拡張機能とをキーとして、データベース部４２１内のモジュール情報から追加要求があったモジュールについてのリソース情報を取得する。
【０１６８】
次に、ステップＳ８０２で、輻輳解析部４２２は、システム管理部２２０から現在のリソース使用状況を取得する。
【０１６９】
次いで、ステップＳ８０３では、ステップＳ８０１、Ｓ８０２で取得したリソース情報から、ＣＰＵと、メモリと、デバイスのそれぞれに関して、追加要求された機能が必要とするリソース量と空きリソース量とを比較する。追加機能が要求するリソース量より空きリソース量の方が多い場合（本ステップでＹｅｓの場合）、ステップＳ８０４へ移行する。また、空きリソースが十分でない場合（本ステップでＮｏの場合）、ステップＳ８０６へ移行する。
【０１７０】
次に、ステップＳ８０４では、追加要求された機能が必要とするリソースが確保可能の場合（ステップＳ８０３でＹｅｓの場合）に、上記ステップＳ８０１で取得したリソース情報をもとに、システム管理部２２０にＣＰＵと、メモリと、デバイスのそれぞれに関してリソースを確保するように輻輳解析部４２２が要求する。
【０１７１】
続いて、ステップＳ８０５では、先のステップＳ８０４で追加した機能の状態を登録するため、データベース部４２１のモジュール状態情報を変更し、機能追加要求を送信したメディアモジュールに対して輻輳解析部４２２が機能追加応答を送信する。この時、後述するステップＳ８１２で拡張機能を削除した場合には、この機能の状態もデータベース部４２１のモジュール状態情報に登録する。
【０１７２】
一方、ステップＳ８０６では、追加要求された機能が必要とするリソースを確保できない場合（本ステップでＮｏの場合）、輻輳解析部４２２は、起動している拡張機能の中から削除対象候補となる拡張機能を決定するため、機能決定部４２４に機能決定要求を行う。
【０１７３】
次に、ステップＳ８０７では、輻輳解析部４２２が機能決定部４２４からの応答を受ける。ここで、機能決定部より拡張機能が見つかったという応答が返った場合（本ステップでＹｅｓの場合）には、ステップＳ８０８へ移行する。また、起動している拡張機能が見つからなかったという応答が返った場合（本ステップＳ８０８でＮｏの場合）、削除可能な拡張機能が見つからなかったとして、ステップＳ８１３へ移行する。
【０１７４】
次いで、ステップＳ８０８では、上記ステップＳ８０７で選択された拡張機能のリソース情報をデータベース部４２１から取得する。
【０１７５】
続いて、ステップＳ８０９では、上述のステップＳ８０１と、Ｓ８０２と、Ｓ８０８で取得したリソース情報から、ＣＰＵと、メモリと、デバイスのそれぞれに関して、追加要求機能が必要とするリソース量と、拡張機能が確保しているリソース量と空きリソース量との和とを比較する。追加機能が必要とするリソース量より空きリソース量と選択された拡張機能が確保しているリソース量との和の方が多い場合（本ステップでＹｅｓの場合）、削除対象候補となる拡張機能が決定し、ステップＳ８１０へ移行する。また、追加機能が必要とするリソースが確保できない場合（本ステップでＮｏの場合）、選択された拡張機能は削除対象候補ではない、として上述のステップＳ８０６へ移行し、処理を繰り返す。
【０１７６】
次に、ステップＳ８１０では、削除対象候補が決定された場合（ステップＳ８０９がＹｅｓ）に、輻輳解析部４２２が上記ステップＳ８０６で選択されたメディアモジュールに対して機能削除問合せを行い、それに対する応答を待つ。
【０１７７】
続いて、ステップＳ８１１では、先のステップＳ８１０で行った機能削除問合せに対する応答が削除応答である場合（本ステップでＹｅｓの場合）、その拡張機能が削除されることが決定し、ステップＳ８１２へ移行する。また、応答がキャンセルである場合（本ステップでＮｏの場合）、その拡張機能は削除できないことが決定し、上述のステップＳ８０６へ移行して処理を繰り返す。
【０１７８】
次いで、ステップＳ８１２では、削除決定した拡張機能を削除するために、上記ステップＳ８０８で取得したリソース情報をもとに、システム管理部２２０にＣＰＵと、メモリと、デバイスのそれぞれに関してリソースを解放するように輻輳解析部４２２が要求し、上述のステップＳ８０４へ処理が移行する。
【０１７９】
一方、ステップＳ８１３では、先のステップＳ８０６で行った拡張機能の検索の結果、削除可能な拡張機能が見つからなかった場合（ステップＳ８０７でＮｏの場合）、機能追加要求を送信したメディアモジュールに対して輻輳解析部４２２が機能追加キャンセルを送信する。以上の手順によって輻輳解析が行われる。
【０１８０】
次に、本実施形態のリソース管理装置における輻輳解析について、例を挙げて具体的に説明する。
【０１８１】
図１７（ａ）は、第１の実施形態のリソース管理装置において、メモリのリソース占有率の変化を示す図であり、（ｂ）は、本実施形態のリソース管理装置において、メモリのリソース占有率の変化を示す図である。なお、図１７では、ＡＶ再生モジュール１１４で起動しているＡＶ再生機能と、動画編集機能と、画質調整機能と、イコライズ機能の組み合わせにより、ＡＶ再生モジュール１１４が確保しているメモリリソースの割合が変化することを図示しており、特に、機能別優先度を付する有効性を示すために、アプリケーションから２種類の拡張機能の開始要求が交互に行われる場合について示している。
【０１８２】
ここでは、図１５のモジュール状態情報に示すように、ＡＶ再生モジュール１１４のＡＶ再生機能と、画質調整機能と、イコライズ機能が起動され、且つ、静止画処理モジュール１１３の静止画撮影機能が起動されて、それぞれが使用可能である状態の例を挙げている。
【０１８３】
この状態で、ユーザからＡＶ再生アプリケーション１１１を通じてＡＶ再生モジュール１１４へ動画編集開始要求があった場合、ＡＶ再生モジュール１１４はその要求を受けて輻輳解析部４２２へ動画編集機能追加要求を送信する。
【０１８４】
動画編集機能の追加要求を受け取った輻輳解析部４２２は、ＡＶ再生モジュールと動画編集をキーとして、図１４に示すモジュール情報から動画編集のリソース情報（ＣＰＵ演算量５６ＭＨｚ（ＣＰＵリソースの３５％に相当）とメモリサイズ１５９ＫＢ（メモリリソースの３１％に相当）が必要）を取得する。
【０１８５】
これと同時に、輻輳解析部４２２は、システム管理部２２０から次のようなリソース使用状況を取得する。
【０１８６】
ＣＰＵに関しては１６０ＭＨｚのリソースのうち、図１４に示すように静止画処理モジュール１１３の静止画撮影がリソースの５％にあたる８ＭＨｚを、ＡＶ再生モジュール１１４がリソースの６７％のリソース（内訳は、ＡＶ再生が３３％の５２ＭＨｚ、画質調整が２２％の３５ＭＨｚ、イコライズが１２％の１９ＭＨｚ）をそれぞれ確保しており、残り２８％が未割当てである。メモリに関しては、５１２ＫＢのリソースのうち、図１７に示すように静止画処理モジュール１１３の静止画撮影がリソースの１５％にあたる７８ＫＢを、ＡＶ再生モジュール１１４がリソースの５８％のリソース（内訳は、ＡＶ再生が４４％の２２６ＫＢ、画質調整が８％の３９ＫＢ、イコライズが６％の３１ＫＢ）を使用しており、残り２７％の空きがある。デバイスに関しては、静止画処理モジュール１１３がＬＣＤ１６２を、ＡＶ再生モジュール１１４がＬＣＤ１６２とスピーカ１６３を使用している。
【０１８７】
輻輳解析部４２２は、ＣＰＵ、メモリ、デバイスについて追加要求機能である動画編集が必要とするリソース量と空きリソース量とを比較する。比較の結果、ＣＰＵリソースについては３５％のリソース要求に対して２８％の空きリソースしかないため輻輳を検出する。メモリリソースについては、図１７に示すように３１％のリソース要求に対して空きが２７％しかないため輻輳を検出する。デバイスリソースについては、輻輳は検出されない。よって、リソースの輻輳が発生することが判定される。
【０１８８】
第１の実施形態に係るリソース管理装置において輻輳を検出した場合、図１７（ａ）に示すように輻輳解析部２２２は、図１５に示すモジュール状態情報の先頭から一番近い起動済み拡張機能、画質調整機能を削除対象候補に決定し、ＡＶ再生モジュール１１４に機能削除を要求する。その結果、画質調整機能は削除され、輻輳解析部２２２は要求された動画編集機能を追加する。その結果音声通話アプリケーション１１２は動画編集を開始する。
【０１８９】
しかし、しばらく後、ユーザからＡＶ再生アプリケーション１１１を通じてＡＶ再生モジュール１１４へ画質調整機能の開始要求がある場合に、図１７（ａ）に示すように輻輳解析部２２２は、リソースの輻輳を検出し、図１５に示すモジュール状態情報の先頭から一番近い起動済み拡張機能を削除対象とする。ここで、削除対象となる追加機能は、先程追加された動画編集機能である。そして、動画編集機能が削除されることが決定すると、その後、画質調整処理が起動する。図１７（ａ）では、この後にも動画編集機能の開始要求があり、再度画質調整処理を削除し、動画編集機能を追加する例を示している。この例では、ユーザからの拡張機能の開始要求ごとに機能の追加と削除が発生している。
【０１９０】
このように、リソース輻輳状態においてユーザが拡張機能を次々と使用するような場合、特に削除候補となる機能の使用頻度が高ければ、機能追加と削除にともなう無駄なオーバヘッドが発生しやすくなる。
【０１９１】
一方、本実施形態のリソース管理装置において、輻輳解析部４２２が輻輳を検出した場合には、削除対象候補となる拡張機能を決定するため、機能決定部４２４に機能決定要求を送信する。
【０１９２】
機能決定要求を受信した機能決定部４２４は、図１４に示すモジュール情報と図１５に示すモジュール状態情報とから、起動中のメディアモジュールの中で優先度の一番低い静止画処理モジュールを選択するが、起動している拡張機能がないので、二番目に低いＡＶ再生モジュール選択し、ＡＶ再生モジュール内の起動中の拡張機能の中で優先度の一番低いイコライズ機能を選択し、そして輻輳解析部４２２に選択されたイコライズ機能を返す。
【０１９３】
輻輳解析部４２２は、機能決定部４２４からイコライズ機能が選択されると、リソースの計算を行い削除対象候補となるか否かの判定を行う。ここでは、図１７（ｂ）に示すように、イコライズ機能が削除対象候補として決定され、削除される。これにより、メモリリソースの空きが５２％となり、動画編集機能の追加が可能となる。
【０１９４】
次に、ユーザからＡＶ再生アプリケーション１１１を通じてＡＶ再生モジュール１１４へ画質調整機能の開始要求がある場合、画質調整機能は起動状態のままであるので、機能の削除及び追加を行なう必要がない。このように、本実施形態のリソース管理装置によれば、図１７（ｂ）に示すように、ユーザから動画編集機能開始と画質調整機能開始が交互に要求されても拡張機能の追加と削除が発生しない。この例では図１４に示すような優先度を付したが、この他にもユーザの使用頻度が高いメディアモジュールに高い優先度を与え、また、メディアモジュール内の拡張機能の中でも使用頻度が高いものに高い優先度を与えることで、機能の追加と削除が発生する頻度を低くすることができるので、ユーザに対するレスポンスを向上させることができる。
【０１９５】
すなわち、本実施形態のリソース管理装置では、メディアモジュールに加えて、それに含まれる拡張機能にも優先度を付加することにより、リソース輻輳時に優先度の低い拡張リソースから優先度の高い拡張リソースにリソースが割当てられることとなり、ユーザへのレスポンスをさらに向上させることができる。
【０１９６】
なお、以上の説明では、機能別優先度の例として、ユーザの使用頻度に応じた優先度を示したが、優先度のつけ方はこれに限らない。また、機能別優先度は動的につけてもよい。例えば、各ユーザの使用頻度に応じて機能の優先度を変化させるなどしてもよい。
【０１９７】
また、本実施形態の説明では、モジュールの優先度と拡張機能の優先度を合わせて設定している例を示したが、モジュールの優先度を設定せずに拡張機能の優先度のみを設定してもよい。この場合、モジュールの枠を越えて機能別優先度を設定し、機能を削除する場合には、機能別優先度の低い機能から削除対象とする。
【０１９８】
（第４の実施形態）
図１８は、第４の実施形態に係るリソース管理装置の構成例を示すブロック図である。
【０１９９】
同図に示すリソース管理装置１００は、アプリケーション処理プロセッサ１０１と、メディア処理プロセッサ１０２とを備えている。
【０２００】
アプリケーション処理プロセッサ１０１は、メインアプリケーション１０３と、静止画処理アプリケーション１１０と、ＡＶ再生アプリケーション１１１と、音声通話アプリケーション１１２とを有している。
【０２０１】
また、メディア処理プロセッサ１０２は、静止画処理モジュール５１３と、ＡＶ再生モジュール５１４と、音声通話モジュール５１５と、システム管理部２２０と、輻輳解析部５２２と、データベース部２２１と、応答処理部５２５とを有している。
【０２０２】
本実施形態のリソース管理装置は、メディア処理プロセッサ１０２内に応答処理部５２５が設けられている点が第１の実施形態のリソース管理装置と異なっている。また、静止画処理モジュール１１３は静止画処理モジュール５１３として、ＡＶ再生モジュール１１４はＡＶ再生モジュール５１４として、音声通話モジュール１１５は音声通話モジュール５１５として、輻輳解析部２２２は輻輳解析部５２２としてそれぞれ示している。
【０２０３】
本実施形態のリソース管理装置による輻輳解析について、以下に説明する。
【０２０４】
応答処理部５２５は、輻輳解析部５２２から制御信号として送信された１つ以上の削除問合せを受信する。本実施形態のリソース管理装置では、１つ以上の削除問い合わせがほぼ同時に応答処理部５２５に送信される。ここで、削除問合せは、削除問合せ対象の拡張機能と、それをサポートするメディアモジュールとの削除に関している。
【０２０５】
削除問合せを受信した応答処理部５２５は、削除問合せ対象の拡張機能と、それをサポートするメディアモジュールとを記憶し、削除問合せに含まれるメディアモジュール宛てに機能削除問合せを制御信号として送信する。機能削除問合せを行った結果、メディアモジュールからその応答として承認応答、あるいはキャンセルを制御信号として受信する。
【０２０６】
応答処理部５２５は、一番早く受信した承認応答を発行したメディアモジュールに対して削除要求を制御信号として送信する。そして、二番目以降に受信した承認応答を発行したメディアモジュールに対してキャンセルを制御信号として送信する。
【０２０７】
次に、応答処理部５２５は、メディアモジュールに送信した削除要求に対する削除応答を制御信号として受信すると、輻輳解析部５２２に削除応答を受信したメディアモジュールの拡張機能に対する削除応答を返す。
【０２０８】
応答処理部５２５が送受信する制御信号のシーケンスをまとめると以下のようになる。
【０２０９】
（１）機能削除問合せを一つ以上のメディアモジュールへ送信
（２）メディアモジュールから応答、承認応答、あるいはキャンセルを受信
（３―１―１）受信した応答が承認応答で、なおかつ一番最初の応答であった場合には、その応答を発行したメディアモジュールに削除要求を送信
（３―１―２）メディアモジュールから削除要求に対する削除応答を受信
（３―２）受信した応答が承認応答で、なおかつ二番目以降の応答であった場合には、その応答を発行したメディアモジュールにキャンセルを送信
（３―３）受信した応答がキャンセルの場合には、シーケンス終了
第１の実施形態に係るリソース管理装置では、輻輳解析部２２２はメディアモジュールに対して機能削除問合せを一度に一回しか行うことができず、問合せに対するレスポンスが遅いメディアモジュールが複数の削除対象候補の中で最初に選択されてしまうと、ユーザへのレスポンスが遅くなるという現象が起こるおそれがあった。本実施形態のリソース管理装置では、この点が改善されている。
【０２１０】
静止画処理モジュール５１３と、ＡＶ再生モジュール５１４と、音声通話モジュール５１５の各メディアモジュールは、第１の実施形態での各メディアモジュールと同様の処理を行うが、応答処理部５２５の追加に対応した以下の処理を新たに行なう。
【０２１１】
リソース輻輳時に削除対象候補となった拡張機能をサポートするメディアモジュールは、応答処理部５２５から機能削除問合せを受信する。機能削除問合せを受信したメディアモジュールは、削除を許可する承認応答か、あるいは削除を許可しないキャンセルを応答として返す。この時、必要ならばアプリケーションに問い合せてもよい。
【０２１２】
応答処理部５２５に承認応答を送信したメディアモジュールの中で、一番早く送信したメディアモジュールには、応答処理部５２５から削除要求が送信される。
【０２１３】
そして、削除要求を受信したメディアモジュールは、削除される拡張機能の終了処理を行った後、削除応答を返す。
【０２１４】
応答処理部５２５に承認応答を送信したメディアモジュールの中で、二番目以降に送信したメディアモジュールには、応答処理部５２５からキャンセルが送信される。
【０２１５】
キャンセルを受信したメディアモジュールは、引き続きメディア処理を継続することができる。
【０２１６】
次に、本実施形態のリソース管理装置における輻輳解析部５２２と応答処理部５２５が、輻輳解析を行なう際の処理の流れを説明する。
【０２１７】
図１９は、本実施形態のメディア処理方法において、リソース輻輳時の処理の流れを示すフローチャート図である。
【０２１８】
まず、ステップＳ９０１で、メディアモジュールから機能追加要求を受信すると、輻輳解析部５２２は、その機能追加要求に含まれるモジュール名と拡張機能とをキーとしてデータベース部２２１内のモジュール情報から、追加要求があったモジュールについてのリソース情報を取得する。
【０２１９】
次に、ステップＳ９０２では、システム管理部２２０から現在のリソース使用状況を取得する。
【０２２０】
次いで、ステップＳ９０３では、先にステップＳ９０１、Ｓ９０２で取得したリソース情報から、輻輳解析部５２２が、ＣＰＵと、メモリと、デバイスのそれぞれに関して追加要求された機能が必要とするリソース量と空きリソース量とを比較する。追加機能が必要なリソース量より空きリソース量が多い場合（本ステップでＹｅｓの場合）、ステップＳ９０４へ移行する。また、空きリソースが十分でない場合（本ステップでＮｏの場合）、ステップＳ９０６へ移行する。
【０２２１】
次に、ステップＳ９０４では、追加要求された機能が必要とするリソースが確保可能の場合（ステップＳ９０３でＹｅｓの場合）に、輻輳解析部５２２が、上記ステップＳ９０１で取得したリソース情報をもとに、システム管理部２２０にＣＰＵと、メモリと、デバイスのそれぞれに関してリソースを確保するように要求する。
【０２２２】
続いて、ステップＳ９０５では、先のステップＳ９０４で追加した機能の状態を登録するためにデータベース部２２１のモジュール状態情報を変更し、機能追加要求を送信したメディアモジュールに対して機能追加応答を送信する。この時、後述するステップＳ９１０で拡張機能を削除した場合には、この機能の状態もデータベース部２２１のモジュール状態情報に登録する。
【０２２３】
一方、追加要求された機能が必要とするリソースを確保できない場合（ステップＳ９０３でＮｏの場合）には、輻輳解析部５２２は、起動している拡張機能の中から削除対象候補となる複数の拡張機能を決定するため、データベース部２２１から起動しているメディアモジュールを検索し、次に、選択されたメディアモジュールの中から起動している拡張機能を検索し、そして、削除対象候補になりうる拡張機能を検出する。
【０２２４】
まず、ステップＳ９０６で、データベース部２２１に格納されているモジュール状態情報の先頭から順に起動しているメディアモジュールを検索し、削除対象候補が見つかった場合（本テップでＹｅｓの場合）には、ステップＳ９１１へ移行する。また、モジュール状態情報のレコードの中から起動しているメディアモジュールが見つからない場合（本ステップでＮｏの場合）、ステップＳ９０７へ移行する。
【０２２５】
次に、ステップＳ９０７では、応答処理部５２５からの応答待ちがある場合（本ステップでＹｅｓの場合）、ステップＳ９０８に移行する。また、応答待ちがない場合（本ステップでＮｏの場合）、削除可能な拡張機能が見つからなかったとして、ステップＳ９１５へ移行する。
【０２２６】
次いで、ステップＳ９０８で、輻輳解析部５２２は、応答処理部５２５からの機能削除問合せの応答を受信する。
【０２２７】
次に、ステップＳ９０９では、先のステップＳ９０８で、応答処理部５２５から受信した応答が拡張機能削除応答ならば（本ステップでＹｅｓの場合）、ステップＳ９１０へ移行する。また、受信した応答がキャンセルならば（本ステップでＮｏの場合）、削除可能な拡張機能が見つからなかったとして、ステップＳ９１５へ移行する。
【０２２８】
次に、ステップＳ９１０では、削除決定した拡張機能を削除するために、後述するステップＳ９１２で取得したリソース情報をもとに、輻輳解析部５２２が、システム管理部２２０にＣＰＵと、メモリと、デバイスのそれぞれに関してリソースを解放するように要求する。そして、処理を上述のステップＳ９０４へ移行する。
【０２２９】
また、ステップＳ９１１で、輻輳解析部５２２は、起動している拡張機能の中から拡張機能を一つ決定するために、上述のステップＳ９０６で選択されたメディアモジュールにについて、モジュール状態情報のレコードの先頭から順に検索する。ここで、モジュール状態情報から起動している拡張機能が見つかった場合（本ステップでＹｅｓの場合）、ステップＳ９１２へ移行する。また、モジュール状態情報のレコードから起動している拡張機能が見つからない場合（本ステップでＮｏの場合）、上述のステップＳ９０６へ移行する。
【０２３０】
次に、ステップＳ９１２では、上述のステップＳ９１１で選択された拡張機能のリソース情報をデータベース部２２１から取得する。
【０２３１】
次に、ステップＳ９１３では、先のステップＳ９１２、Ｓ９０１、Ｓ９０２で取得したリソース情報から、輻輳解析部５２２が、ＣＰＵと、メモリと、デバイスのそれぞれに関して、追加要求機能が必要とするリソース量と、拡張機能が確保しているリソース量と空きリソース量との和を比較する。追加機能が必要とするリソース量より、空きリソース量と選択された拡張機能が確保しているリソース量の和が多い場合（本ステップでＹｅｓの場合）、削除対象候補となる拡張機能が決定し、ステップＳ９１４へ移行する。また、追加機能が必要とするリソースが確保できない場合（本ステップでＮｏの場合）、選択された拡張機能は、削除対象候補ではないとして上述のステップＳ９１１へ移行し、処理を繰り返す。
【０２３２】
次に、ステップＳ９１４で、削除対象候補が決定された場合（ステップＳ９１３でＹｅｓの場合）、上記ステップＳ９０６で選択されたメディアモジュールに対して機能削除問合せを行い、次の削除対象候補を検索するためにステップＳ９１１へ移行する。以上の手順により、本実施形態の輻輳解析が行われる。
【０２３３】
次に、本実施形態のリソース管理装置における処理の具体例を説明する。
【０２３４】
図２０は、音声通話アプリケーションから音声通話開始要求が発行された場合の、第１の実施形態と本実施形態のリソース管理装置における各ブロック間のシーケンスを示す図である。同図では、音声通話アプリケーション１１２から音声通話の開始要求が発行されてからその応答が返ってくるまでの応答時間の差を比較しやすいように、機能を追加する際に、レスポンスの一番遅い動画編集が、データベースの先頭から一番近いレコードにあったために選択された場合について示している。また、ここでは、静止画編集をレスポンスの一番早い例として示している。
【０２３５】
ＡＶ再生モジュール１１４、５１４の動画編集機能と静止画処理モジュール１１３、５１３の静止画編集機能とが起動していて使用可能な状態で、音声通話アプリケーション１１２から音声通話開始要求が音声通話モジュール１１５、５１５へ送信された場合（この時間をｔ０＝０とする）、それを受信した音声通話モジュール１１５、５１５は、輻輳解析部２２２、５２２へ音声通話機能追加要求を送信する。
【０２３６】
本実施形態のリソース管理装置では、音声通話機能追加要求を受信した輻輳解析部５２２は、リソースの輻輳を検出し、削除対象候補の拡張機能として静止画処理モジュール５１３の静止画編集機能とＡＶ再生モジュール５１４の動画編集機能が決定され、それぞれに対して静止画編集機能の削除問合せと動画編集機能の削除問合せとを応答処理部５２５に行う。
【０２３７】
次に、静止画編集機能の削除問合せと動画編集機能削除問合せとを受信した応答処理部５２５は、静止画処理モジュール５１３とＡＶ再生モジュール５１４に対してそれぞれ静止画編集機能の削除問合せと動画編集機能の削除問合せを送信する。
【０２３８】
すると、静止画編集機能の削除問合せを受け取った静止画処理モジュール５１３は、静止画処理アプリケーション１１０に問合せを行い、その結果、応答処理部５２５に承認応答を返す。
【０２３９】
動画編集機能削除問合せを受け取ったＡＶ再生モジュール５１４も同様に、ＡＶ再生アプリケーション１１１に問合せを行い、その結果、応答処理部５２５に承認応答を返す。
【０２４０】
この場合、静止画処理モジュール５１３の方がＡＶ再生モジュール５１４よりも早く承認応答を返したため、静止画処理モジュール５１３は応答処理部５２５から削除要求を受信し、ＡＶ再生モジュール５１４は応答処理部５２５からキャンセルを受信する。
【０２４１】
削除要求を受け取った静止画処理モジュール５１３は、静止画編集の終了処理を行い、その結果、応答処理部５２５に削除応答を返す。
【０２４２】
キャンセルを受け取ったＡＶ再生モジュール５１４は、動画編集機能が削除されず、引き続き動画編集を継続することが可能である。
【０２４３】
次に、削除応答を受信した応答処理部５２５は、輻輳解析部５２２に静止画編集の削除応答を返す。そして、その削除応答を受け取った輻輳解析部５２２は、静止画編集機能が使用しているリソースを解放し、音声通話機能が使用するリソースを確保して、音声通話モジュール５１５に機能追加応答を返す。
【０２４４】
機能追加応答を受信した音声通話モジュール５１５は、音声通話アプリケーション１１２に音声通話開始応答を返す（この時間をｔ１とする）。
【０２４５】
一方、第１の実施形態に係るリソース管理装置では、輻輳解析部２２２は、データベース部２２１の先頭から登録されている拡張機能から削除問合せを行うので、最初にＡＶ再生モジュール１１４に動画編集機能削除問合せを行う。
【０２４６】
次に、動画編集機能の削除問合せを受け取ったＡＶ再生モジュール１１４は、ＡＶ再生アプリケーション１１１に問合せを行い、その結果、動画編集機能の終了要求を得る。
【０２４７】
そして、ＡＶ再生モジュール１１４は、動画編集終了要求により動画編集機能の終了処理を行い、輻輳解析部２２２に削除応答を返す。
【０２４８】
削除応答を受信した輻輳解析部２２２は、動画編集機能が使用しているリソースを解放し、音声通話機能が使用するリソースを確保して、音声通話モジュール１１５に機能追加応答を返す。
【０２４９】
機能追加応答を受信した音声通話モジュール１１５は、音声通話アプリケーション１１２に音声通話開始応答を返す（この時間をｔ２とする）。
【０２５０】
図２０に示すように、第１の実施形態のリソース管理装置では、音声通話開始要求から応答が返るまでの時間がｔ２かかっていた。これに対し、本実施形態のリソース管理装置では、応答処理部で複数の削除対象である拡張機能から応答の早いものを選択することにより、音声通話開始要求から応答が返るまでの時間がｔ１となり、時間Ｔだけ短縮されていることがわかる。
【０２５１】
このように、本実施形態のリソース管理装置では、複数の削除対象候補の中から応答が速いメディアモジュールが選択できるので、アプリケーションの機能追加要求に対する応答時間を短縮することが可能となる。従って、リソースを効率的に利用しつつ、メディア処理の速度を向上させることが可能となる。
【０２５２】
なお、本実施形態のリソース管理装置において、メディアモジュールからの機能追加要求は重複しないことを前提としたが、複数のメディアモジュールから同時に機能追加要求があった場合でも、それぞれの要求に対して応答時間を短縮することが可能となる。
【０２５３】
また、本実施形態では、第１の実施形態のリソース管理装置に応答処理部を付加した例を説明したが、第２、第３の実施形態のリソース管理装置に応答処理部を付加しても有効である。その場合、拡張機能の追加要求に対して拡張機能の削除対象候補として、優先度の低いモジュール及び優先度の低い拡張機能を順に２つ以上選択する。
【０２５４】
また、以上の説明では、応答処理部５２５が、２つ以上の拡張機能についての削除問い合わせを同時に受ける例を示したが、多数のモジュールが存在し、モジュールごとに機能削除を行なう場合には、複数のモジュールについての削除問い合わせを行なうことになる。
【０２５５】
なお、本発明の各実施形態のリソース管理方法は、例えばリソース管理装置の内部または外部に保持されたプログラムによって実現することができる。
【０２５６】
【発明の効果】
本発明のリソース管理装置によれば、メディア処理機能を、基本機能と拡張機能とに分けることにより、リソースの輻輳時に起動中の拡張機能を削除することにより、メディアモジュールの並列度を向上することができる。
【０２５７】
更に、リソースの輻輳時に、削除すべき拡張機能をメディアモジュール別優先度と機能別優先度により選択することが可能となる。また、応答処理部を設けることでユーザからの機能追加要求に対する応答速度を向上させることも可能となる。
【図面の簡単な説明】
【図１】本発明の第１の実施形態に係るリソース管理装置の構成例を示すブロック図である。
【図２】第１の実施形態のリソース管理装置のうち、アプリケーション処理プロセッサ及びメディア処理プロセッサの構成を詳細に示すブロック図である。
【図３】第１の実施形態のリソース管理装置のうち、アプリケーション処理プロセッサ及びメディア処理プロセッサの構成を詳細に示すブロック図である。
【図４】第１の実施形態のリソース管理方法において、データベース部に格納されるモジュール情報の一例を示す図である。
【図５】第１の実施形態のメディア処理方法において、データベース部に格納されるモジュール状態情報の一例を示す図である。
【図６】第１の実施形態のメディア処理方法において、リソース輻輳時の処理の流れを示すフローチャート図である。
【図７】第１の実施形態のリソース管理装置において、ＣＰＵのリソース占有率の変化を示す図である。
【図８】本発明の第２の実施形態に係るリソース管理装置の構成例を示すブロック図である。
【図９】第２の実施形態のリソース管理方法において、データベース部に格納されるモジュール情報の一例を示す図である。
【図１０】第１の実施形態のメディア処理方法において、データベース部に格納されるモジュール状態情報の一例を示す図である。
【図１１】第２の実施形態のメディア処理方法において、リソース輻輳時の処理の流れを示すフローチャート図である。
【図１２】（ａ）は、第１の実施形態のリソース管理装置において、ＣＰＵのリソース占有率の変化を示す図であり、（ｂ）は、第２の実施形態のリソース管理装置において、ＣＰＵのリソース占有率の変化を示す図である。
【図１３】本発明の第３の実施形態に係るリソース管理装置の構成例を示すブロック図である。
【図１４】第３の実施形態のリソース管理方法において、データベース部に格納されるモジュール情報の一例を示す図であ
【図１５】第３の実施形態のメディア処理方法において、データベース部に格納されるモジュール状態情報の一例を示す図である。
【図１６】第３の実施形態のメディア処理方法において、リソース輻輳時の処理の流れを示すフローチャート図である。
【図１７】（ａ）は、第１の実施形態のリソース管理装置において、メモリのリソース占有率の変化を示す図であり、（ｂ）は、第３の実施形態のリソース管理装置において、メモリのリソース占有率の変化を示す図である。
【図１８】本発明の第４の実施形態に係るリソース管理装置の構成例を示すブロック図である。
【図１９】第４の実施形態のメディア処理方法において、リソース輻輳時の処理の流れを示すフローチャート図である。
【図２０】音声通話アプリケーションから音声通話開始要求が発行された場合の、第１の実施形態と第４の実施形態のリソース管理装置における各ブロック間のシーケンスを示す図である。
【符号の説明】
１００ リソース管理装置
１０１ アプリケーション処理プロセッサ
１０２ メディア処理プロセッサ
１０３ メインアプリケーション
１１０ 静止画処理アプリケーション
１１１ ＡＶ再生アプリケーション
１１２ 音声通話アプリケーション
１１３、５１３ 静止画処理モジュール
１１４、５１４ ＡＶ再生モジュール
１１５、５１５ 音声通話モジュール
１５０ 蓄積メディア
１５１ メモリ
１６０ キーデバイス
１６１ カメラ
１６２ ＬＣＤ
１６３ スピーカ
１６４ マイク
１６５ ベースバンド・プロセッサ
２２０ システム管理部
２２１、３２１，４２１ データベース部
２２２、３２２、４２２、５２２ 輻輳解析部
３２３ モジュール決定部
４２４ 機能決定部
５２５ 応答処理部
Claims (12)
- メディア処理を行なうためのメディアモジュールと、
機能追加要求に際し、リソースの輻輳を生じる場合に、上記メディアモジュールの機能情報と上記メディア処理機能についてのリソース情報とを含むモジュール情報と、上記メディア処理機能の起動状態を示すモジュール状態情報とを参照してリソース配分を変更する輻輳解析部と、
上記輻輳解析部が変更したリソース配分に従い、リソースの確保及び解放を行なうシステム管理部と
を有するメディア処理プロセッサを備えているリソース管理装置。 - 請求項１に記載のリソース管理装置において、
上記モジュール情報と上記モジュール状態情報とを格納するデータベース部をさらに備えている、リソース管理装置。 - 請求項１または２に記載のリソース管理装置において、
上記メディア処理機能は、メディア処理に必須な基本機能と、付加的な機能である拡張機能とに分かれており、
機能追加要求に際し、リソースの輻輳が生じる場合に、上記輻輳解析部は、起動中の上記拡張機能を削除してから追加要求のあった機能を起動させることを特徴とするリソース管理装置。 - 請求項３に記載のリソース管理装置において、
上記メディアモジュールは複数存在し、
上記モジュール情報は、メディアモジュール別優先度を含んでおり、
上記メディア処理プロセッサは、リソースの輻輳を生じる場合に、上記メディアモジュール別優先度の低い上記メディアモジュールから順に削除対象として決定するためのモジュール決定部をさらに有している、リソース管理装置。 - 請求項３または４に記載のリソース管理装置において、
上記モジュール情報は、上記拡張機能についての機能別優先度を含んでおり、
上記メディア処理プロセッサは、リソースの輻輳を生じる場合に、上記機能別優先度の低い上記拡張機能から順に削除対象として決定するための機能決定部をさらに有している、リソース管理装置。 - 請求項３〜５のうちいずれか１つに記載のリソース管理装置において、
上記メディア処理プロセッサは、リソースの輻輳を生じる場合に、起動中の複数の上記拡張機能の削除を上記メディアモジュールに問い合わせ、且つ、少なくとも最初に応答した上記メディアモジュールの上記拡張機能の削除を決定するための応答処理部をさらに有している、リソース管理装置。 - 拡張機能と、メディア処理に必須な基本機能とに分けられたメディア処理を行なうためのメディアモジュールと、輻輳解析部と、システム管理部とを有するメディア処理プロセッサを備えたリソース管理装置を用いたリソース管理方法であって、
機能追加要求に際し、リソースの輻輳を生じる場合に、上記メディアモジュールの機能情報と上記メディア処理機能についてのリソース情報とを含むモジュール情報と、上記メディア処理機能の起動状態を示すモジュール状態情報とを参照して上記輻輳解析部がリソース配分を変更するステップ（ａ）と、
上記ステップ（ａ）で上記輻輳解析部が変更したリソース配分に従い、上記システム管理部がリソースの確保及び解放を行なうステップ（ｂ）と
を含んでいるリソース管理方法。 - 請求項７に記載のリソース管理方法において、
上記ステップ（ａ）は、
上記輻輳解析部が、追加要求された機能が必要とするリソース量と空きリソース量とを比較するステップ（ａ１）と、
上記ステップ（ａ１）で、空きリソース量が追加要求された機能が必要とするリソース量より少ない場合に、上記輻輳解析部が、上記拡張機能のうちから起動中の機能の削除を問い合わせるステップ（ａ２）と
を含んでいるリソース管理方法。 - 請求項７に記載のリソース管理方法において、
上記メディアモジュールは複数存在し、
上記モジュール情報は、メディアモジュール別優先度を含んでおり、
上記メディア処理プロセッサはモジュール決定部をさらに有しており、
上記ステップ（ａ）は、
上記輻輳解析部が、追加要求された機能が必要とするリソース量と空きリソース量とを比較するステップ（ａ１）と、
上記ステップ（ａ１）で、空きリソース量が追加要求された機能が必要とするリソース量より少ない場合に、上記モジュール決定部が、上記メディアモジュール別優先度の低い上記メディアモジュールから順に削除対象として決定するステップ（ａ３）と、
上記輻輳解析部が、上記ステップ（ａ３）で決定された上記メディアモジュールのうち、起動中の上記拡張機能の削除を問い合わせるステップ（ａ４）と
を含んでいるリソース管理方法。 - 請求項７に記載のリソース管理方法において、
上記モジュール情報は、上記拡張機能についての機能別優先度を含んでおり、
上記メディア処理プロセッサは、機能決定部をさらに有しており、
上記ステップ（ａ）は、
上記輻輳解析部が、追加要求された機能が必要とするリソース量と空きリソース量とを比較するステップ（ａ１）と、
上記ステップ（ａ１）で、空きリソース量が追加要求された機能が必要とするリソース量より少ない場合に、上記機能決定部が、上記機能別優先度の低い起動中の上記拡張機能から順に削除対象として決定するステップ（ａ５）と、
上記輻輳解析部が、上記ステップ（ａ５）で決定された上記拡張機能の削除を問い合わせるステップ（ａ６）と
を含んでいるリソース管理方法。 - 請求項７に記載のリソース管理方法において、
上記メディア処理プロセッサは応答処理部をさらに有しており、
上記ステップ（ａ）は、
上記輻輳解析部が、追加要求された機能が必要とするリソース量と空きリソース量とを比較するステップ（ａ１）と、
上記ステップ（ａ１）で、空きリソース量が追加要求された機能が必要とするリソース量より少ない場合に、上記輻輳解析部が、起動中の複数の上記拡張機能の削除を上記メディアモジュールに問い合わせるステップ（ａ７）と、
上記ステップ（ａ７）の後、上記応答処理部が、少なくとも最初に応答した上記メディアモジュールの上記拡張機能の削除を決定するステップ（ａ８）と、
上記ステップ（ａ８）の後に応答した上記メディアモジュールに対しては、上記応答処理部がキャンセルを送信するステップ（ａ９）と
を含んでいるリソース管理方法。 - 機能追加要求に際し、リソースの輻輳を生じる場合に、上記メディアモジュールの機能情報と上記メディア処理機能についてのリソース情報とを含むモジュール情報と、上記メディア処理機能の起動状態を示すモジュール状態情報とを参照してリソース配分を変更するステップ（ａ）と、
上記ステップ（ａ）で変更したリソース配分に従い、リソースの確保及び解放を行なうステップ（ｂ）と
をコンピュータに実行させるためのプログラムを記録したコンピュータ読み取り取り可能な記録媒体。
Priority Applications (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003144776A JP2004348437A (ja) | 2003-05-22 | 2003-05-22 | リソース管理装置、リソース管理方法及び記録媒体 |
| CNA200410044800XA CN1573702A (zh) | 2003-05-22 | 2004-05-18 | 资源管理装置、资源管理方法及存储媒体 |
| US10/849,792 US20050007953A1 (en) | 2003-05-22 | 2004-05-21 | Resource management device, resource management method and recording medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003144776A JP2004348437A (ja) | 2003-05-22 | 2003-05-22 | リソース管理装置、リソース管理方法及び記録媒体 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2004348437A true JP2004348437A (ja) | 2004-12-09 |
Family
ID=33532141
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003144776A Pending JP2004348437A (ja) | 2003-05-22 | 2003-05-22 | リソース管理装置、リソース管理方法及び記録媒体 |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US20050007953A1 (ja) |
| JP (1) | JP2004348437A (ja) |
| CN (1) | CN1573702A (ja) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP5370482B2 (ja) * | 2009-05-11 | 2013-12-18 | 日本電気株式会社 | 端末装置、該端末装置に用いられるコミュニケーション方法及びコミュニケーション制御プログラム |
| CN110795054A (zh) * | 2019-10-21 | 2020-02-14 | Oppo广东移动通信有限公司 | 画质调节方法及相关产品 |
Families Citing this family (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20060069457A1 (en) * | 2004-09-24 | 2006-03-30 | Texas Instruments Incorporated | Dynamically adjustable shared audio processing in dual core processor |
| CN100419690C (zh) * | 2005-07-18 | 2008-09-17 | 光宝科技股份有限公司 | 媒体转录控制方法及使用上述方法的嵌入式系统 |
| JP4609410B2 (ja) * | 2006-10-18 | 2011-01-12 | 株式会社デンソー | 車両用ナビゲーション装置 |
| JP2008204581A (ja) * | 2007-02-22 | 2008-09-04 | Elpida Memory Inc | 不揮発性ｒａｍ |
| US20100011367A1 (en) * | 2008-07-11 | 2010-01-14 | Gm Global Technology Operations, Inc. | Methods and systems for allocating a resource of a vehicle among a plurality of uses for the resource |
| US11322224B2 (en) | 2010-05-18 | 2022-05-03 | Natera, Inc. | Methods for non-invasive prenatal ploidy calling |
| EP2656263B1 (en) | 2010-12-22 | 2019-11-06 | Natera, Inc. | Methods for non-invasive prenatal paternity testing |
| JP2012221217A (ja) * | 2011-04-08 | 2012-11-12 | Sony Corp | メモリ管理装置、メモリ管理方法、および、制御プログラム |
| CN103645955A (zh) * | 2013-12-16 | 2014-03-19 | 百度在线网络技术（北京）有限公司 | 应用程序的运行管理方法和装置 |
| JP6542706B2 (ja) * | 2016-04-13 | 2019-07-10 | ファナック株式会社 | 数値制御装置 |
| CN112188235B (zh) * | 2019-07-05 | 2023-03-24 | 上海交通大学 | 媒体处理方式的选择方法及媒体处理方法 |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6282560B1 (en) * | 1997-03-28 | 2001-08-28 | International Business Machines Corporation | Managing processor resources in a non-dedicated computer system |
| US6246692B1 (en) * | 1998-02-03 | 2001-06-12 | Broadcom Corporation | Packet switching fabric using the segmented ring with resource reservation control |
| WO2001090887A1 (fr) * | 2000-05-25 | 2001-11-29 | Fujitsu Limited | Procede de traitement de programme permettant un traitement haute vitesse au moyen d'un materiel a reconfiguration dynamique et programme permettant d'executer ce procede de traitement |
| US20030039233A1 (en) * | 2001-08-14 | 2003-02-27 | Aharon Satt | Estimation of resources in cellular networks |
-
2003
- 2003-05-22 JP JP2003144776A patent/JP2004348437A/ja active Pending
-
2004
- 2004-05-18 CN CNA200410044800XA patent/CN1573702A/zh active Pending
- 2004-05-21 US US10/849,792 patent/US20050007953A1/en not_active Abandoned
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP5370482B2 (ja) * | 2009-05-11 | 2013-12-18 | 日本電気株式会社 | 端末装置、該端末装置に用いられるコミュニケーション方法及びコミュニケーション制御プログラム |
| US8782663B2 (en) | 2009-05-11 | 2014-07-15 | Nec Corporation | Terminal device, communication method used in the terminal device and recording medium |
| CN110795054A (zh) * | 2019-10-21 | 2020-02-14 | Oppo广东移动通信有限公司 | 画质调节方法及相关产品 |
Also Published As
| Publication number | Publication date |
|---|---|
| US20050007953A1 (en) | 2005-01-13 |
| CN1573702A (zh) | 2005-02-02 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3808394B2 (ja) | ストリームデータ処理装置、ストリームデータ処理方法、プログラム、及び、媒体 | |
| JP4972409B2 (ja) | ノード及びネットワークの特性を考慮したサービスロケーション管理を行うためのシステム | |
| JP2004348437A (ja) | リソース管理装置、リソース管理方法及び記録媒体 | |
| US8549526B2 (en) | Access control apparatus and access control method | |
| US20090187588A1 (en) | Distributed indexing of file content | |
| JP2008518354A (ja) | メディア・プレーヤとホスト・デバイスとの間のワイヤレス同期化 | |
| JP2014525619A (ja) | データ処理システム | |
| US7962518B2 (en) | Method and apparatus to control media transfer protocol device to manage media file | |
| JP2004062463A (ja) | プログラム実行装置 | |
| JPH09190293A (ja) | データ読出装置 | |
| CN111177017B (zh) | 一种内存分配方法及装置 | |
| KR20210094639A (ko) | 리소스 스케줄링 방법 및 장치, 전자 디바이스 및 기록 매체 | |
| WO2016078091A1 (zh) | 一种输入输出io请求处理方法及文件服务器 | |
| JP5490078B2 (ja) | メタデータを抽出して送信するコンテンツ提供方法、記録媒体、システムおよびサーバ | |
| KR101521701B1 (ko) | 실행 제어 방법 및 멀티프로세서 시스템 | |
| KR101457561B1 (ko) | 데이터 전송 방법 및 장치와 작업 수행 방법 및 장치 | |
| TW201445989A (zh) | 分散式編解碼系統及方法 | |
| JP3664021B2 (ja) | サービスレベルによる資源割当方式 | |
| JP4311312B2 (ja) | 時系列データ管理方法およびプログラム | |
| KR102613286B1 (ko) | 프레임 그룹에 대한 비트 레이트 제어 | |
| CN110555075B (zh) | 数据处理方法、装置、电子设备以及计算机可读存储介质 | |
| JP2002108579A (ja) | プリンタ、プリンタの制御方法、そのためのプログラム、及び、そのプログラムを記録した記録媒体 | |
| JP2005251067A (ja) | 合成サービス提供方法、合成サービス提供システム、実行装置およびプログラム | |
| CN111290856B (zh) | 数据处理装置和方法 | |
| CN113535673B (zh) | 生成配置文件及数据处理的方法和装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20060310 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20070817 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070904 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20080108 |