"サービス事業者がゲートウェイ装置に対して提供するアプリケーションソフトウェアであるアプリケーションを管理するとともに、前記ゲートウェイ装置においてアプリケーションを実行した際に必要となるリソース実測値を前記サービス事業者に通知するゲートウェイ管理装置のゲートウェイ管理方法であって、前記ゲートウェイ管理装置は、前記サービス事業者がサービス事業者サーバから提供した各アプリケーションを、該サービス事業者と関連付けて管理するアプリケーション管理情報を有するとともに、各アプリケーションが実行されたゲートウェイ装置の機器数と、各アプリケーションが実行された際に必要なリソース実測値とが関連付けられた実測リソース集計管理情報を有する記憶部を備え、前記ゲートウェイ管理装置は、前記各ゲートウェイ装置から、導入済みの各アプリケーションが実行された際に必要となったリソース実測値を受信し、該受信したリソース実測値に基づき前記実測リソース集計管理情報を更新し、前記アプリケーション管理情報に登録されているアプリケーションの機器数が所定値に達しているかを判定し、前記所定値に達したアプリケーションについて前記アプリケーション管理情報に登録されているサービス事業者に、前記リソース実測値を通知することを特徴とするゲートウェイ管理方法。前記ゲートウェイ管理装置は、さらに、前記記憶部に、前記各アプリケーションが利用可能な前記ゲートウェイ装置のリソース値を管理するリソース管理情報が記憶されており、前記ゲートウェイ管理装置は、前記サービス事業者からアプリケーションの配布依頼を受けた場合、前記配布依頼を受けたアプリケーションと、前記サービス事業者が設定したリソース値とを関連付けて、前記リソース管理情報に登録するとともに、前記実測リソース集計管理情報に新規のレコードを作成し、前記配布依頼を受けたアプリケーションに対する機器数を初期設定することを特徴とする請求項1に記載のゲートウェイ管理方法。前記ゲートウェイ管理装置は、前記ゲートウェイ装置に新規のアプリケーションを配布する際に、前記ゲートウェイ装置のアプリケーションが利用可能なリソース値の合計と、既に前記ゲートウェイ装置に導入済みのアプリケーションの利用可能なリソース値の合計とを取得し、前記導入済みのアプリケーションの利用可能なリソース値の合計と前記新規のアプリケーションの利用可能なリソース値との合計と、前記ゲートウェイ装置のアプリケーションが利用可能なリソース値の合計を比較し、前記導入済みのアプリケーションの利用可能なリソース値の合計と前記新規のアプリケーションの利用可能なリソース値との合計が、前記ゲートウェイ装置のアプリケーションが利用可能なリソース量の合計を超えない場合に、前記新規のアプリケーションの配布を許可することを特徴とする請求項1または請求項2に記載のゲートウェイ管理方法。前記ゲートウェイ管理装置は、前記ゲートウェイ装置に配布する新規のアプリケーションが、前記実測リソース集計管理情報に基づいて配布依頼を受けたアプリケーションである場合、前記ゲートウェイ装置に対し、前記新規のアプリケーションが前記ゲートウェイ装置において実行する際のリソース実測値を収集する旨を通知することを特徴とする請求項2に記載のゲートウェイ管理方法。前記リソース値は、前記ゲートウェイ装置のCPUの使用率および前記ゲートウェイ装置のメモリの使用量のうち少なくともいずれかであることを特徴とする請求項2に記載のゲートウェイ管理方法。前記ゲートウェイ装置は、オペレーションシステム、JavaのVM、OSGiで構成された実行環境であることを特徴とする請求項1に記載のゲートウェイ管理方法。サービス事業者がゲートウェイ装置に対して提供するアプリケーションソフトウェアであるアプリケーションを管理するゲートウェイ管理装置であって、前記サービス事業者がサービス事業者サーバから提供した各アプリケーションを、該サービス事業者と関連付けて管理するアプリケーション管理情報を有するとともに、各アプリケーションが実行されたゲートウェイ装置の機器数と、各アプリケーションが実行された際に必要なリソース実測値とが関連付けられた実測リソース集計管理情報を記憶する記憶部と、前記各ゲートウェイ装置から、導入済みの各アプリケーションが実行された際に必要となったリソース実測値を受信し、該受信したリソース実測値に基づき前記実測リソース集計管理情報を更新し、前記アプリケーション管理情報に登録されているアプリケーションの機器数が所定値に達しているかを判定し、前記所定値に達したアプリケーションについて前記アプリケーション管理情報に登録されているサービス事業者に、前記リソース実測値を通知するアプリケーション配布管理部とを有することを特徴とするゲートウェイ管理装置。前記ゲートウェイ管理装置は、前記記憶部に、前記各アプリケーションが利用可能な前記ゲートウェイ装置のリソース値を管理するリソース管理情報が記憶されており、前記ゲートウェイ管理装置は、さらに、前記サービス事業者からアプリケーションの配布依頼を受けた場合、前記配布依頼を受けたアプリケーションと、前記サービス事業者が設定したリソース値とを関連付けて、前記リソース管理情報に登録するとともに、前記実測リソース集計管理情報に新規のレコードを作成し、前記配布依頼を受けたアプリケーションに対する機器数を初期設定するアプリケーション登録管理部を有することを特徴とする請求項7に記載のゲートウェイ管理装置。前記アプリケーション配布管理部は、前記ゲートウェイ装置に新規のアプリケーションを配布する際に、前記ゲートウェイ装置のアプリケーションが利用可能なリソース値の合計と、既に前記ゲートウェイ装置に導入済みのアプリケーションの利用可能なリソース値の合計とを取得し、前記導入済みのアプリケーションの利用可能なリソース値の合計と前記新規のアプリケーションの利用可能なリソース値との合計と、前記ゲートウェイ装置のアプリケーションが利用可能なリソース値の合計を比較し、前記導入済みのアプリケーションの利用可能なリソース値の合計と前記新規アプリケーションの利用可能なリソース値との合計が、前記ゲートウェイ装置のアプリケーションが利用可能なリソース量の合計を超えない場合に、前記新規のアプリケーションの配布を許可することを特徴とする請求項7または請求項8に記載のゲートウェイ管理装置。前記アプリケーション配布管理部は、前記ゲートウェイ装置に配布する新規のアプリケーションが、前記実測リソース集計管理情報に基づいて配布依頼を受けたアプリケーションである場合、前記ゲートウェイ装置に対し、前記新規アプリケーションが前記ゲートウェイ装置において実行する際のリソース実測値を収集する旨を通知することを特徴とする請求項8に記載のゲートウェイ管理装置。前記リソース値は、前記ゲートウェイ装置のCPUの使用率および前記ゲートウェイ装置のメモリの使用量のうち少なくともいずれかであることを特徴とする請求項8に記載のゲートウェイ管理方法。前記ゲートウェイ装置は、オペレーションシステム、JavaのVM、OSGiで構成された実行環境であることを特徴とする請求項7に記載のゲートウェイ管理装置。ゲートウェイ管理装置が配布するアプリケーションソフトウェアであるアプリケーションを実行するゲートウェイ装置であって、前記ゲートウェイ装置は、各アプリケーションが実行された際に必要なリソース実測値と稼動時間とを関連付けて実測リソース装置情報として記憶する記憶部を備え、前記ゲートウェイ装置は、所定期間ごとに導入済みの各アプリケーションが実行された際に必要となったリソースを計測し、該計測したリソース実測値が前記実測リソース情報に登録済みにリソース実測値より大きければ、前記実測リソース情報のリソース実測値を更新し、前記稼動時間が所定の時間を超えた場合、前記実測リソース情報のリソース実測値を前記ゲートウェイ管理装置に送信することを特徴とするゲートウェイ装置。前記ゲートウェイ装置は、前記ゲートウェイ管理装置から新規に配布されたアプリケーションが、該ゲートウェイ装置において実行する際のリソース実測値を収集する旨の通知を受けると、前記実測リソース装置情報に新規のレコードを作成し、前記新規に配布されたアプリケーションの稼動時間を初期設定することを特徴とする請求項13に記載のゲートウェイ装置。前記特許文献2、特許文献3に示される方法には次のような問題がある。まず、特許文献2に示される方法では、複数のプログラムが消費するリソースと実行プログラムリストを複数のゲートウェイ装置から収集することで各々のプログラムが消費するリソースの平均消費量を求める方法が開示されているが、あくまでも平均消費量であり、各々のゲートウェイ装置において、各々のプログラムが、実際にどのようにリソースを消費したのかを示す消費リソース量の実測値を得る方法については言及がない。すなわち、消費リソース量の実測値を基にして、厳密なリソース管理を行う方法については開示されていない。また、特許文献3に示される方法では、アプリケーションの利用可能なメモリの上限について、どのように決定をするかについての言及がない。すなわち、サービス事業者とゲートウェイ装置やOSGiフレームワークなどのアプリケーション基盤を提供するプラットフォーム事業者との責任分界点を考えると、サービス事業者が提供するアプリケーションの利用可能なメモリの上限については、サービス事業者が自ら必要なメモリ使用量を上限値としてプラットフォーム事業者に申告、設定することが自然であると考えられる。しかし、例えば、サービス事業者がゲートウェイ装置の実機を持たずゲートウェイ装置のエミュレータを用いてアプリケーション開発を行うような場合には必要なメモリ上限について精度の高い申告、設定を行うことが困難となる可能性がある。本発明は、前記の課題を解決するための発明であって、サービス事業者の要求に応じて、ゲートウェイ装置からサービス事業者の作成するアプリケーションソフトウェアの実行に必要なリソース実測値を収集し、該リソース実測値をサービス事業者へ提供可能とする、ゲートウェイ管理方法、ゲートウェイ管理装置、およびゲートウェイ装置を提供することを目的とする。前記目的を達成するため、本発明のゲートウェイ管理方法は、サービス事業者がゲートウェイ装置に対して提供するアプリケーションソフトウェアであるアプリケーションを管理するとともに、ゲートウェイ装置においてアプリケーションを実行した際に必要となるリソース実測値をサービス事業者に通知するゲートウェイ管理装置のゲートウェイ管理方法であって、ゲートウェイ管理装置は、サービス事業者がサービス事業者サーバから提供した各アプリケーションを、該サービス事業者と関連付けて管理するアプリケーション管理情報例えば、サービス管理テーブル2000を有するとともに、各アプリケーションが実行されたゲートウェイ装置の機器数と、各アプリケーションが実行された際に必要なリソース実測値とが関連付けられた実測リソース集計管理情報例えば、実測リソース情報集計管理テーブル2200を有する記憶部例えば、サービス管理DB110を備え、ゲートウェイ管理装置は、各ゲートウェイ装置から、導入済みの各アプリケーションが実行された際に必要となったリソース実測値を受信し、該受信したリソース実測値に基づき実測リソース集計管理情報を更新し例えば、ステップS2504、アプリケーション管理情報に登録されているアプリケーションの機器数が所定値に達しているか判定し、所定値に達したアプリケーションについてアプリケーション管理情報に登録されているサービス事業者に、リソース実測値を通知する例えば、ステップS2508ことを特徴とする。本発明によれば、サービス事業者の要求に応じて、ゲートウェイ装置からサービス事業者の作成するアプリケーションソフトウェアの実行に必要なリソース実測値を収集し、該リソース実測値をサービス事業者へ提供可能とすることができる。本発明の実施形態について、図面を参照して詳細に説明する。図1は、本実施形態における機能構成およびネットワーク構成の一例を示す図である。ゲートウェイ管理システムは、ゲートウェイ管理装置100、複数の利用者宅50内のゲートウェイ装置200、複数のサービス事業者サーバ40とを含んで構成されている。利用者宅50内において、ゲートウェイ装置200は、利用者宅内ネットワーク230を介して複数の宅内機器240に接続されている。ゲートウェイ管理装置100、サービス事業者サーバ40、およびゲートウェイ装置200は、フレッツ登録商標などの閉域網、または、インターネットからなる外部ネットワーク30と接続しており、所定の手順に従って情報のやり取りを行うことができる。ゲートウェイ装置200と宅内機器240は、利用者宅50内に設置され、有線または無線から構成される利用者宅内ネットワーク230と接続しており、所定の手順に従って情報のやり取りを行うことができる。ゲートウェイ装置200は、外部ネットワーク30と利用者宅内ネットワーク230の両方と接続しており、利用者宅50に設置された機器にとって、外部ネットワーク30に接続された機器と情報のやり取りをするためのゲートウェイとしての機能を有する。ゲートウェイ管理装置100は、処理部として、サービス事業者サーバ40から依頼を受けてゲートウェイ管理装置100への新規サービスの登録処理S2300図23参照を行うアプリケーション登録管理部101と、ゲートウェイ装置200へ新規サービス導入処理S600図6参照、ゲートウェイ装置200から受信した実測リソース量集計処理S2500図25参照などを行うアプリケーション配布管理部102と、DB管理部103とを有する。なお、DBはDataBaseの略である。また、ゲートウェイ管理装置100は、サービス管理DB110を有し、サービス管理DB110には、サービス管理テーブル2000アプリケーション管理情報図20参照、実測リソース情報集計管理テーブル2200実測リソース集計管理情報図22参照、必要リソーステーブル500リソース管理情報図5参照、依存関係テーブル800図8参照が格納されている。ゲートウェイ装置200は、処理部として、サービスアプリケーション211を実行するアプリケーション実行部210、サービスアプリケーション211の状況を管理するアプリケーション管理部220とを有している。アプリケーション管理部220は、サービスアプリケーション起動処理S700図7参照、サービスアプリケーション起動処理S1400図14参照、メモリ使用量監視処理S1500図15参照、メモリ使用量監視処理S1600図16参照、異常通知処理S1800図18参照、異常通知処理S1900図19参照、実測リソース量計測処理S2400図24参照などの処理を行う機能を有している。また、ゲートウェイ装置200は、ゲートウェイ管理DB250を有し、ゲートウェイ管理DB250には、実測リソース情報テーブル2100実測リソース装置情報図21参照、全体利用可能リソーステーブル300図3参照、利用可能リソーステーブル400図4参照、導入サービスアプリケーション依存関係管理テーブル900図9参照、およびプロセスID管理テーブル1000図10参照が格納されている。図2は、ゲートウェイ管理装置100およびゲートウェイ装置200のハードウェア構成の一例を示す図である。ゲートウェイ管理装置100は、EPROM11、CPU12、メインメモリ13、バス14、不揮発性記憶装置15、周辺制御装置16、ネットワークI/F17を有している。EPROM11、CPU12、メインメモリ13、周辺制御装置16はバス14と接続し、不揮発性記憶装置15、ネットワークI/F17は周辺制御装置16を介してバス14と接続しており、所定の手順に従って情報のやり取りを行うことができる。なお、EPROMはErasableProgrammableReadOnlyMemoryの略であり、CPUはCentralProcessingUnitの略であり、I/FはInterfaceの略である。ゲートウェイ装置200は、EPROM21、CPU22、メインメモリ23、バス24、不揮発性記憶装置25、周辺制御装置26、ネットワークI/F27、ネットワークI/F28を有している。EPROM21、CPU22、メインメモリ23、周辺制御装置26はバス24と接続し、ネットワークI/F27、ネットワークI/F28、不揮発性記憶装置25は周辺制御装置26を介してバス24と接続しており、所定の手順に従って情報のやり取りを行うことができる。ゲートウェイ管理装置100において、EPROM11にはブートプログラムが格納されている。また、不揮発性記憶装置15には各種プログラムが記憶されている。ゲートウェイ管理装置100が起動するとEPROM11に格納されたブートプログラムによって不揮発性記憶装置15から各種プログラムがメインメモリ13へと読み出される。CPU12はメインメモリ13に読み出された各種プログラムを実行することにより、ネットワークI/F17への信号の送受信を行う。ネットワークI/F17は外部ネットワーク30と接続しており、外部ネットワーク30に接続する機器との間で情報のやり取りを行うことができる。ネットワークI/F17はネットワークカードなどにより実現することができる。不揮発性記憶装置15には、前述のようにCPU12がメインメモリ13に読み出して実行するための各種プログラムが記憶されており、フラッシュメモリやHDDハードディスクドライブにより実現することができる。ゲートウェイ装置200において、EPROM21にはブートプログラムが格納されている。また、不揮発性記憶装置25には各種プログラムが記憶されている。ゲートウェイ装置200が起動するとEPROM21に格納されたブートプログラムによって不揮発性記憶装置25から各種プログラムがメインメモリ23へと読み出される。CPU22はメインメモリ23に読み出された各種プログラムを実行することにより、ネットワークI/F27やネットワークI/F28への信号の送受信を行う。ネットワークI/F27は、外部ネットワーク30と接続しており、外部ネットワーク30に接続する機器との間で情報のやり取りを行うことができる。ネットワークI/F27はネットワークカードなどにより実現することができる。ネットワークI/F28は、利用者宅50内のネットワーク230と接続しており、利用者宅内ネットワーク230に接続する機器との間で情報のやり取りを行うことができる。ネットワークI/F28はネットワークカードなどにより実現することができる。不揮発性記憶装置25には、前述のようにCPU22がメインメモリ23に読み出して実行するための各種プログラムが記憶されており、フラッシュメモリやHDDハードディスクドライブにより実現することができる。図示しないが、サービス事業者サーバ40のハードウェア構成は、通常のPCPersonalComputerと同様である。次に、本実施形態において、ゲートウェイ管理装置100、ゲートウェイ装置200が扱う各テーブルについて説明する。図3は、ゲートウェイ装置200の全体利用可能リソーステーブル300を示す図である。全体利用可能リソーステーブル300は、アプリケーションサービス全体が利用可能なリソース量を示すテーブルである。全体利用可能リソーステーブル300には、全体利用可能CPU使用率301、全体利用可能メモリ量302といった項目がある。具体的には、行303には、全体利用可能CPU使用率は50であり、全体利用可能メモリ量は30MBであることがわかる。図4は、ゲートウェイ装置200の利用可能リソーステーブル400を示す図である。利用可能リソーステーブル400は、個別のアプリケーションサービスが利用可能なリソースを管理するテーブルである。利用可能リソーステーブル400には、ID401、利用可能ヒープメモリ量402、利用可能メモリ量403、利用可能CPU使用率404といった項目がある。具体的には、行405のIDが000の場合、利用可能ヒープメモリ量は6MB、利用可能メモリ量15MB、利用可能CPU使用率は20である。行406のIDが003の場合、利用可能ヒープメモリ量は3MB、利用可能メモリ量6MB、利用可能CPU使用率は10である。図5は、ゲートウェイ管理装置100の必要リソーステーブル500を示す図である。必要リソーステーブル500は、ゲートウェイ管理装置100が管理する個別のアプリケーションサービスが利用可能なリソースを管理するテーブルである。必要リソーステーブル500には、ID401、必要ヒープメモリ量502、必要メモリ量503、必要CPU使用率504といった項目がある。具体的には、複数のサービス事業者サーバ40が提供しているサービスアプリケーション211の必要リソースとして、行506のIDが001の場合、必要ヒープメモリ量は1MB、必要メモリ量は2MB、必要CPU使用率は10である。また、行507のIDが002の場合は、必要ヒープメモリ量は4MB、必要メモリ量は10MB、必要CPU使用率は30である。さらに、行505のIDが000は図4で示した行405の000に対応し、行508のIDが003は図4で示した行406の003に対応し、および行509のIDが010は図4に示した行407の010に対応している。図8は、ゲートウェイ管理装置100の依存関係テーブル800を示す図である。依存関係テーブル800は、サービスアプリケーション間の依存関係を管理するテーブルである。依存関係テーブル800には、ID401、ImportPackage802、ExportPackage803といった項目がある。ImportPackage802は、ID401に指定されているバンドルの利用に必要なパッケージ、言い換えると、このバンドルが依存しているパッケージを示す。行804の例ではImportPackageがorgosgiframeworkとしており、orgosgiframeworkというパッケージに依存することを意味する。ExportPackage803は、他のバンドルに公開されるパッケージを示す。行804では、ExportPackageがorgosgiservicehttpとしており、orgosgiservicehttpというパッケージをバンドル外に公開している。逆にExportPackage803に宣言されていないパッケージは、他のバンドルからアクセスができないことを意味する。図9は、ゲートウェイ装置200の導入サービスアプリケーション依存関係管理テーブル900を示す図である。導入サービスアプリケーション依存関係管理テーブル900は、ゲートウェイ装置200に導入したサービスアプリケーション間の依存関係を管理するテーブルである。導入サービスアプリケーション依存関係管理テーブル900には、ID401、ImportPackage902、ExportPackage903といった項目がある。図10は、ゲートウェイ装置200のプロセスID管理テーブル1000を示す図である。プロセスID管理テーブル1000は、サービスアプリケーション211に対応するプロセスIDを管理するテーブルである。プロセスID管理テーブル1000には、ID401、プロセスID1002といった項目がある。図20は、ゲートウェイ管理装置100のサービス管理テーブル2000を示す図である。サービス管理テーブル2000アプリケーション管理情報は、サービス名と、サービス事業者名およびサービスIDとの対応を管理するテーブルである。サービス管理テーブル2000には、サービス名2001、サービス事業者名2002、ID401といった項目がある。具体的には、サービス名がhomecontrolは、家操作のサービス事業者が提供しているサービスであり、サービス名がhealthcareは、健康No1のサービス事業者が提供しているサービスである。図21は、ゲートウェイ装置200の実測リソース情報テーブル2100を示す図である。実測リソース情報テーブル2100実測リソース装置情報は、ID401に対応する実測リソース情報を管理するテーブルである。実測リソース情報テーブル2100には、ID401、実測ヒープメモリ量2101、実測メモリ量2102、実測CPU使用率2103、稼働時間2104といった項目がある。図22は、ゲートウェイ管理装置100の実測リソース情報集計管理テーブル2200を示す図である。実測リソース情報集計管理テーブル2200実測リソース集計管理情報は、ID401に対応する調査機器数の実測リソース情報集計管理テーブルである。実測リソース情報集計管理テーブル2200には、ID401、調査機器数2201、実測ヒープメモリ量最大値2202、実測ヒープメモリ量平均値2203、実測メモリ量最大値2204、実測メモリ量平均値2205、実測CPU使用率最大値2206、実測CPU使用率平均値2207といった項目がある。具体的には、行2208を参照すると、IDが010の場合、調査機器数は15であり、各リソースの最大値および平均値が集計されている。例えば、実測ヒープメモリ量の最大値は0.5MBであり、実測ヒープメモリ量の平均値は0.35MBである。このことから、図20、図22を参照すると、IDが010のサービス名がhomecomtrolを運用する際の、精度の高い各リソースの最大値および平均値を得ることができる。次に本実施形態の各装置の処理部の動作について、適宜図1を参照して説明する。ゲートウェイ管理装置100は、様々なサービス事業者サーバ40を保持するサービス事業者が提供するサービスアプリケーションを、ゲートウェイ装置200へ外部ネットワーク30を介して配布するサービスサービスアプリケーション配布基盤としての機能を有している。サービス事業者サーバ40を保持するサービス事業者は、作成したサービスアプリケーション211の配布をゲートウェイ管理装置100へ委託することにより、サービスアプリケーション配布サーバなどを自身で設置すること、アプリケーション実行部210を備えたゲートウェイ装置200などを自ら利用者へ配布することの必要がなくなり、コストを抑えてサービス提供を行うことが可能となる。ゲートウェイ装置200は、様々なサービスアプリケーション211を実行するアプリケーション実行部210を備える。アプリケーション実行部210は、例えば、OSGi登録商標フレームワークのようなアプリケーション実行基盤を用いて実現することができ、ゲートウェイ管理装置100が配布するサービスアプリケーション211を実行することにより、様々な宅内機器240を、利用者宅内ネットワーク230を介して制御可能とするなど、ゲートウェイ装置200の機能を柔軟に拡張することを可能とする。アプリケーション実行部210としてOSGiフレームワークを用いる場合、通常OSGiフレームワークは、単一のフレームワーク上で複数のサービスアプリケーション211を実行することが可能であるが、本実施形態では、サービスアプリケーション211のそれぞれが、利用するゲートウェイ装置200のCPU処理時間CPU使用率や利用メモリ量といったリソースを詳細に制御するために、サービスアプリケーション211ごとに別個にアプリケーション実行部210を起動することを想定する。OSGiフレームワークのようなアプリケーション実行基盤は、様々なサービスアプリケーション211間でお互いの機能を適切に呼び合うことを可能とする。例えば、OSGiサービスプラットフォーム仕様が標準で規定するHTTPサービスはWEBサーバおよびサーブレットコンテナの機能を有し、サーブレットとして実装された他のサービスアプリケーション211は、HTTPサービスが提供するサーブレットコンテナ機能に自身を登録することにより、サービスアプリケーション211を提供するサービス事業者は、簡単にWEBサーバおよびサーブレットコンテナの機能を利用することができる。アプリケーション実行部210をサービスアプリケーション211ごとに起動した場合、通常前記のようなサービスアプリケーション211間の連携機能は使用できなくなってしまうが、OSGiサービスプラットフォーム仕様R4.2にはHTTPサービスと同様の標準サービスとしてリモートサービスの仕様が追加されている。リモートサービスはOSGiの核となるサービスのImport/Export機能を異なるJava登録商標VM上で動作するOSGiフレームワークと共有することを可能とする。本実施形態においては、特にことわりのない限り、アプリケーション実行部210はOSGiフレームワークを用いて実現され、アプリケーション実行部210は、様々なサービスアプリケーション211ごとにアプリケーション管理部220によって異なるJavaVM異なるソフトウェアプロセス上で実行され、起動した複数のアプリケーション実行部210間はOSGiサービスプラットフォームの標準サービスである、リモートサービスを用いて互いに連携可能であることを想定する。また、本実施形態においては、サービスアプリケーション211は、1つまたは複数のプログラムソフトウェア部品、OSGiバンドルと言うからなる。本実施形態においては、1つのアプリケーション実行部210では、1つのサービスアプリケーション211が動作することを想定する。ただし、1つのアプリケーション実行部210で複数のサービスアプリケーション211を実行することも可能である。例えば、サービスアプリケーション211の提供事業者ごとに同一のアプリケーション実行部を利用するということも可能である。本実施形態において、CPU使用率、メモリ使用量といったリソースの管理を行うことができるのはアプリケーション実行部210ごとである。例えば、前記のように、サービスアプリケーション211の提供事業者ごとに同一のアプリケーション実行部210を利用する場合、利用可能なリソース量を超過した場合には該サービスアプリケーション提供事業者の提供するサービスアプリケーション211のいずれかに問題があるであろう、ということまで分かる。1つのアプリケーション実行部210で複数のサービスアプリケーション211を実行すると、ゲートウェイ装置全体におけるアプリケーション実行部210を実現するプログラムJavaVMやOSGiフレームワークなどの実行数が減少し、その分機器全体でのメモリ使用量などを節約することができるという効果があるが、本実施形態では説明を簡便にするために1つのアプリケーション実行部では1つのサービスアプリが動作することを想定する。また、本実施形態におけるゲートウェイ装置200は、アプリケーション実行部210の実行されるソフトウェアプロセスそれぞれのCPU使用率、メモリ使用量、Javaのヒープメモリ使用量の上限値を適切に制御可能な構成を想定する。例えば、ゲートウェイ装置200のOS基本ソフトがLinux登録商標である場合、ソフトウェアプロセスのCPU使用率はCABICPUAccountingandBlockingInterfaceのようなCPUリソースマネジメントシステムを用いて制御が可能である。CABIはある周期におけるCPU使用時間の上限値を設定することが可能で、例えば、あるソフトウェアプロセスに対し、周期が100ms、CPU使用時間の上限値が30msといったCABIのAOアカウンティングオブジェクトを設定した場合、100msの間に30msの時間においてCPUを利用すると、30ms後のCPUの利用をブロックされ、CPUリソースが他のプロセスへと開放される。本実施形態においては、特にことわりのない限り、ゲートウェイ装置200のOSはLinuxであり、CPUリソースマネジメントにはCABIを用いることを想定するが、例えばその他のリアルタイムOSなどにおいても同様の仕組みを用いて実現が可能な場合がある。また、例えば、ゲートウェイ装置200のOS基本ソフトがLinuxである場合、ソフトウェアプロセスのメモリ使用量はCABI-DMELCommonresourcemanagementAccountingandBlockingInterfacesDependableMemorymanagementsystemforEmbeddedLinuxのようなメモリリソースマネジメントシステムを用いて制御が可能である。CABI-DMELはあるソフトウェアプロセスに対する物理メモリの割り当ての上限制限をすることが可能であり、上限値以上のメモリを確保しようとした場合にメモリ割り当てをブロックすることができる。本実施形態においては、特にことわりのない限り、ゲートウェイ装置200のOSはLinuxであり、メモリリソースマネジメントにはCABI-DMELを用いることを想定するが、例えばその他のOSなどにおいても同様の仕組みを用いて実現が可能な場合がある。また、本実施形態ではアプリケーション実行部210は、OSGiフレームワークを用いて実現されることを想定するが、OSGiフレームワークはJavaVMJavaVirtualMachineを用いて起動される。JavaVMは実行するプログラムの利用可能なヒープメモリの上限を指定することが可能であり、設定した上限値以上のヒープメモリの利用をブロックすることができる。図13は、本実施形態における機能構成の一例を示す図である。図13は、アプリケーション実行部210を実現するプログラムとしてJavaVM、OSGiフレームワークOSGiFramework、OSGiの標準サービスであるリモートサービスバンドルを用いた場合のゲートウェイ装置200の機能構成図である。サービスアプリケーション211を実行するごとにJavaVMとOSGiフレームワークが起動し、各OSGiフレームワーク上でリモートサービスバンドルが動作し、それぞれのアプリケーション実行部210a,210b,210cのOSGiフレームワーク上において各サービスアプリケーション211が動作している。OSGiは通常、同一のJavaVM上で動作するOSGiフレームワーク上で動作するプログラムバンドル間においてお互いの機能サービスを呼び合うことができるが、リモートサービスを用いると異なるJavaVM上で動作するOSGiフレームワーク間で機能サービスの情報をやり取りすることができ、リモートサービスが導入されたOSGiフレームワーク上で実行されるサービスアプリケーション211は異なるアプリケーション実行部で動作するサービスアプリケーション211の機能サービスを利用することが可能となる。また、各アプリケーション実行部210a,210b,210cの起動処理などの管理はアプリケーション管理部220が行う。図23は、アプリケーション登録管理部101によるゲートウェイ管理装置100への新規サービス登録処理S2300の処理フローを示す図である。図23は、ゲートウェイ管理装置100のアプリケーション登録管理部101が、サービス事業者のサービス事業者サーバ40から受信する情報を基にゲートウェイ管理装置100へ新規サービスを登録する手順を示すフローチャートである。ステップS2301は、ゲートウェイ管理装置100のアプリケーション登録管理部101が、サービス事業者のサービス事業者サーバ40から新規登録するサービスに関する情報、すなわち、サービス事業者名、サービスアプリケーションのプログラム、サービス名、必要ヒープメモリ量、必要メモリ量、必要CPU使用率、実測リソース計測の有無に関する情報を受信する処理である。ステップS2302は、アプリケーション登録管理部101が、該サービスアプリケーションのIDを新規に決定する処理である。IDはこれまでにサービス管理テーブル2000図20参照に記載のサービス名に対応するIDとして登録されていない値を選択する。ステップS2303は、アプリケーション登録管理部101が、サービス管理テーブル2000にサービス名、サービス事業者名、ステップS2302で決定したIDを追記する処理である。ステップS2304は、アプリケーション登録管理部101が、必要リソーステーブル500図5参照にID、必要ヒープメモリ量、必要メモリ量、必要CPU使用率を追記する処理である。サービス事業者から受信した情報に実測リソース計測指定があればステップS2305,Yes、ステップS2306の処理に進む、実測リソース計測指定がなければステップS2305,No、処理を終了する。ステップS2306は、アプリケーション登録管理部101が、実測リソース情報集計管理テーブル2200図22参照に新規のレコードを作成し、IDを追記し、該当する調査機器数に初期値である0を設定する処理である。図6は、アプリケーション配布管理部102によるゲートウェイ装置200への新規サービス導入処理S600の処理フローを示す図である。図6は、ユーザが選択したサービスがゲートウェイ管理装置100を介してゲートウェイ装置200に導入されるまでの手順を示したフローチャートである。以下、図6の説明は、特に言及のない限りアプリケーション配布管理部102の処理であり、ステップS609~ステップS611は、ゲートウェイ装置200の処理である。サービス利用者は、宅内機器240のひとつであるPCからゲートウェイ装置200にアクセスすると、サービスアプリケーション管理画面が表示される。サービスアプリケーション管理画面には、現在すでに導入されているサービスアプリケーションの一覧、かつ、まだ導入されていないサービスアプリケーションの一覧などが表示される。サービスアプリケーションの一覧には、有料であるか無料であるか、有料である場合にも無料のトライアル期間があるか否か、サービス内容がどのようなものであるか否かなどが表示される。サービス利用者は、導入を希望するサービスアプリケーション、例えば、3ヶ月無料のサービスとしてサービス名がhealthcare図20参照を選択する。ステップS601は、アプリケーション配布管理部102が、サービス利用者によって新規導入を希望されたサービスアプリケーションのIDAを取得する処理である。ステップS602は、アプリケーション配布管理部102が、ゲートウェイ装置200から全体利用可能リソーステーブル300図3参照に記載の情報全体利用可能CPU使用率および全体利用可能メモリ量B、および利用可能リソーステーブル400図4参照に記載のIDの一覧Cを取得する処理である。ステップS603は、アプリケーション配布管理部102が、サービスアプリケーションを新規導入するにあたって、アプリケーションの依存関係を確認し、ユーザが新規導入を希望するアプリケーション以外に導入が必要なアプリケーションのIDを抽出する処理である、すなわち、新規導入を希望するサービスアプリケーションのIDA、すでにゲートウェイ装置200に導入済みのサービスアプリケーションのID一覧C、依存関係テーブル800に記載の情報Dを用いて、Aのサービスアプリケーションを導入する際に追加で必要なサービスアプリケーションがないかを確認し、もしあれば、新規導入希望サービスアプリケーションのIDAと該追加で必要なサービスサービスアプリケーションのIDを合わせて、ゲートウェイ装置200へ導入するサービスアプリケーションのID一覧Eを抽出する処理である。ステップS604は、アプリケーション配布管理部102が、新規導入希望サービスアプリケーションをゲートウェイ装置200へ導入する場合に必要となるリソースの合計を算出する処理である、すなわち、必要リソーステーブル500を参照し、ゲートウェイ装置200に導入済みのID一覧Cに対する必要メモリ量、必要CPU使用率の合計F、および新規導入希望のID一覧Eに対する必要メモリ量、必要CPU使用率の合計Gを算出する処理である。ステップS605は、アプリケーション配布管理部102が、新規導入希望サービスアプリケーションを導入した場合の必要リソース量の合計と、ゲートウェイ装置200で利用可能な総リソース量Bを比較する処理である、すなわち、新規導入希望サービスアプリケーション導入後に必要となるメモリ量およびCPU使用率の合計FGと、全体利用可能リソース量Bを比較する処理である。ステップS606は、アプリケーション配布管理部102が、ステップS605の比較の結果、新規導入希望サービスアプリケーションを導入した場合の必要リソース量がゲートウェイ装置200で利用可能な総リソース量の範囲内であるかどうかを確認する処理である、すなわち、メモリ量、CPU使用率それぞれについてFG<Bが成立かどうか調べる処理である。メモリ量、CPU使用率それぞれについてFG<Bが成立であればステップS606,Yes、ステップS607へ進む。メモリ量、CPU使用率それぞれについてFG<Bが成立でなければステップS606,No、ステップS612へ進む。ステップS607は、アプリケーション配布管理部102が、ゲートウェイ装置200を介してサービス利用者に、新規導入を希望したサービスアプリケーションを導入可能であることを提示する処理である。ステップS608は、アプリケーション配布管理部102が、ゲートウェイ装置200へ新規導入サービスアプリケーションおよび関連情報を送信する処理である、すなわち、ゲートウェイ装置200へ新規導入サービスアプリケーション、該サービスアプリケーション各々の必要メモリ量、必要CPU使用率といった必要リソース情報H、該サービスアプリケーション各々の依存関係に関する情報I、および実測リソース情報集計管理テーブル2200図22参照を参照し、該新規導入サービスアプリケーションのIDが含まれていれば該IDが実測リソース情報収集要である旨Jを送信する処理である。ステップS609は、ゲートウェイ装置200のアプリケーション管理部220における処理である。ゲートウェイ装置200が、Hの情報を利用可能リソーステーブル400に、Iの情報を導入サービスアプリケーション依存関係管理テーブル900に追記する処理である。ステップS610は、ゲートウェイ装置200のアプリケーション管理部220における処理である。ゲートウェイ装置200が、実測リソース情報収集要である旨Jの情報が存在する場合に、実測リソース情報テーブル2100に新規のレコードを作成し、該当IDを追記し、稼働時間を初期値である0に設定する処理である。ステップS611は、ゲートウェイ装置200のアプリケーション管理部220における処理である。ゲートウェイ装置200が、該サービスアプリケーションを起動する処理である。そして、ステップS611の処理後、一連の処理は終了する。ステップS612は、ゲートウェイ装置200を介してサービス利用者に、新規導入を希望したサービスアプリケーションの導入が不可であることを提示する処理である。そして、ステップS612の処理後、一連の処理は終了する。図6におけるステップS604において、メモリ使用量として必要メモリ量を用いたが、必要リソーステーブル500図5参照に必要メモリ量の記載がなく、必要ヒープメモリ量のみが記載されている場合などはメモリ使用量として必要ヒープメモリ量を用いてもよい。また、必要ヒープメモリ量はJavaVM自身が利用するメモリ量などを含まないが、JavaVMが利用するであろうメモリ量をある程度見込んで、それをメモリ使用量として利用してもよい。例えば、必要ヒープメモリ量と同量のメモリをJavaVMが利用するとして、必要ヒープメモリ量の2倍を必要メモリ量とする、などとしてもよい。図11は、新規導入希望サービスを導入可能である画面表示の一例を示す図である。図11は、図6におけるステップS607において、ゲートウェイ管理装置100がゲートウェイ装置200を介してサービス利用者に提示する情報の画面イメージの一例である。具体的には、画面には、選択したサービスを実行するのに十分なリソース量があることを確認しました。選択したサービスをゲートウェイ装置に導入します。が表示される。図12は、新規導入希望サービスを導入不可である画面表示の一例を示す図である。図6におけるステップS612において、ゲートウェイ管理装置100がサービス利用者に提示する情報の画面イメージの一例である。具体的には、画面には、選択したサービスを実行するのに十分なリソース量があることを確認できませんでした。選択したサービスをゲートウェイ装置に導入できません。不要なサービスを停止するなどして再度サービス導入処理を行ってください。が表示される。図17は、図6に示した新規サービス導入処理を示す処理フローに対応するシーケンスを示す図である。ステップS1701は、サービス利用者のPCを利用してゲートウェイ装置200を介してゲートウェイ管理装置100に接続し、新規導入を希望するサービスアプリケーションを選択する処理である。ステップS1702は、ゲートウェイ管理装置100が該サービスアプリケーションのIDAを得る処理であり、ステップS601に対応する。ステップS1703は、ゲートウェイ管理装置100が、ゲートウェイ装置200に、全体利用可能リソース情報テーブルに記載の情報Bおよび利用可能リソーステーブルに記載のIDの一覧Cの送信を要求する処理である。ステップS1704は、ゲートウェイ装置200が、ゲートウェイ管理装置100に、全体利用可能リソース情報テーブルに記載の情報Bおよび利用可能リソーステーブルに記載のIDの一覧Cを送信する処理であり、ステップS602に対応する。ステップS1705は、ゲートウェイ管理装置100が、AのIDとCのIDの一覧と依存関係テーブルに記載の情報Dを用いてゲートウェイ装置200に導入するサービスアプリケーションのIDの一覧Eを抽出する処理であり、ステップS603に対応する。ステップS1706は、ゲートウェイ管理装置100が、必要リソーステーブルに記載の必要メモリ量、必要CPU使用率のそれぞれについて、CのID一覧に対応する必要メモリ量、必要CPU使用率それぞれの合計Fと、EのID一覧に対応する必要メモリ量、必要CPU使用率それぞれの合計Gを抽出する処理であり、ステップS604に対応する。ステップS1707は、ゲートウェイ管理装置100が、新規サービス導入した場合にゲートウェイ装置200のメモリ量、CPU使用率それぞれについて全体利用可能リソース量を超えないことを確認、すなわち、必要メモリ量、必要CPU使用率それぞれについて、Fの値とGの値の和がBにおける全体利用可能メモリ量、全体利用可能CPU使用率の値を超えないかどうかを確認する処理であり、ステップS605,S606に対応する。ステップS1708は、ゲートウェイ管理装置100が、ゲートウェイ装置200を介してサービス利用者に、新規導入を希望したサービスアプリケーションを導入可能である事を提示する処理であり、ステップS607に対応する。ステップS1709は、ゲートウェイ管理装置100が、ゲートウェイ装置200へ、該新規導入サービスアプリケーションおよび必要リソーステーブル500の情報のうち該サービスアプリケーションのIDに対応する情報H、依存関係テーブル800の情報のうち該サービスアプリケーションのIDに対応する情報I、および実測リソース情報集計管理テーブル2200図22参照を参照し、該新規導入サービスアプリケーションのIDが含まれていれば該IDが実測リソース情報収集要である旨Jを送信する処理であり、ステップS608に対応する。ステップS1710は、ゲートウェイ装置200が、Hの情報を利用可能リソーステーブル400に、Iの情報を導入サービスアプリケーション依存関係管理テーブル900に追記する処理であり、ステップS609に対応する。ステップS1711は、ゲートウェイ装置200が、実測リソース情報収集要である旨Jの情報が存在する場合に、該当IDを実測リソース情報テーブル2100に追記し、稼働時間を初期値である0に設定し、該サービスアプリケーションを起動する処理であり、ステップS610に対応する。図7は、アプリケーション管理部220によるサービスアプリケーション起動処理S700の処理フローを示す図である。ステップS701は、アプリケーション管理部220が、利用可能リソーステーブル400図4参照から、起動するサービスアプリケーション211のIDに対応する利用可能ヒープメモリ量、利用可能メモリ量、利用可能CPU使用率を取得する処理である。ステップS702は、アプリケーション管理部220が、CABIのAPIApplicationProgramInterfaceを用いて、該利用可能CPU使用率の値に関するアカウンティングオブジェクトを生成する処理である。ステップS703は、アプリケーション管理部220が、CABI-DMELのAPIを用いて、該利用可能メモリ量の値に関するアカウンティングオブジェクトを生成する処理である。ステップS704は、アプリケーション管理部220が、JavaVMの起動オプションの最大ヒープ量に該利用可能ヒープメモリ量を設定してOSGiフレームワークアプリケーション実行部210を起動し、該OSGiフレームワークに該サービスアプリケーション211をインストールおよび実行する処理である。ステップS705は、アプリケーション管理部220が、該サービスアプリケーション211を実行したソフトウェアプロセスのプロセスIDを調査、取得し、該プロセスIDをCABIおよびCABI-DMELのアカウンティングオブジェクトにバインドする処理である。ステップS706は、アプリケーション管理部220が、該サービスアプリケーション211のIDおよび該プロセスIDをプロセスID管理テーブル1000図10参照に記憶する処理である。ここで、CABI、CABI-DMELの動作について簡単に説明する。CABIは周期とCPU使用時間をパラメータにアカウンティングオブジェクトを作成し、そのアカウンティングオブジェクトに制御したいプロセスをバインドする。例えば、利用可能CPU使用率が20の場合、周期100ms、CPU使用時間20msなどと記述する。通常Linuxのような非リアルタイムOSにおいては、CPUに余力がある場合、優先度の低いプロセスであっても多くのCPU資源利用時間を割り当てる。CABIを用いると、CPUに余力があった場合でもアカウンティングオブジェクトに設定した時間分のCPU資源を消費したら該プロセスはタスクを開放し、それ以上CPU資源を利用しない。CABIを用いた場合において、設定する周期とCPU使用時間は利用可能な最大値である。設定した時間分のCPUを使用していなくとも、より優先度の高いプロセスから割り込みが発生した場合などは利用時間に達しなくともCPU資源を解放する。CABI-DMELはアカウンティングオブジェクトに利用可能なメモリ量を設定する。制御したいプロセスをアカウンティングオブジェクトにバインドすると、CABI-DMELは該プロセスのメモリの確保/開放を監視し、設定したメモリ量を超えるメモリの確保を行おうとするとそれを拒否する。その場合、制御対象のプロセスではメモリ確保に失敗したことになり、場合によってはプロセスそのものが異常終了するような場合もある。CABIやCABI-DMELを用いた場合のログなどはシステムログなどに記録可能であり、アプリケーション管理部から参照可能である。図6、図7のように新規サービス導入処理、サービス起動処理を行うことで、ゲートウェイ装置200上で動作するサービスアプリケーション211の使用リソースを適切に制御し、サービスアプリケーション211の必要リソース量を確実に確保することが可能となる。図6の処理において、サービスアプリケーション211の配布可否はゲートウェイ管理装置100にて判断している例えば、ステップS606が、これはゲートウェイ装置200で行ってもよい。図7のステップS704の処理において起動されたサービスアプリケーション211の動作ログなどをゲートウェイ管理装置100またはサービス事業者サーバ40サービス提供事業者サーバへ送信することにより、保守管理に役立てることが可能である。例えば、設定した上限値を超えてリソースを利用しようとしたサービスアプリケーション211が存在した場合、そのログをサービス事業者サーバへ送信することによりソフトウェアの品質改良などに役立てることが可能である。図24および図25は、ゲートウェイ装置200に導入したサービスアプリケーション211を動作した際に実際どの程度のリソース量を使用したか実測リソース量を調査する処理である。図24は、ゲートウェイ装置200における実測リソース量計測処理S2400の処理フローを示す図である。実測リソース量計測処理S2400は、ゲートウェイ装置200のアプリケーション管理部220によってゲートウェイ装置200の起動時に開始され、ゲートウェイ装置200の起動中常にループ処理を行う。図24に記載の処理の主体は全てアプリケーション管理部220である。ステップS2401は、アプリケーション管理部220が、実測リソース情報テーブル2100図21参照から記載のIDを全て取得する処理である。ステップS2402は、アプリケーション管理部220が、プロセスID管理テーブル1000図10参照を参照し、ステップS2401で取得した各IDに対応するプロセスIDを取得する処理である。ステップS2403は、アプリケーション管理部220が、各プロセスIDに対応するプロセスのヒープメモリ量、メモリ量、CPU使用率を取得する処理である。OSの機能、JavaVMの機能などを呼び出して実現することが可能である。ステップS2404は、アプリケーション管理部220が、今回のループで取得したリソース量がこれまでに取得したリソース量と比べて大きい最大値をとるかどうかを確認し、大きい場合は今回ループで取得したリソース量を実測リソース情報テーブル2100に記載する処理である、すなわち、実測リソース情報テーブル2100の各IDに対応する実測ヒープメモリ量、実測メモリ量、実測CPU使用率に対し、今回ループで計測したヒープメモリ量、メモリ量、CPU使用率が大きければ実測リソース情報テーブル2100の各値を更新する、また、更新の有無にかかわらず、実測リソース情報テーブル2100の稼働時間の値にシステムであらかじめ決める当該ループ処理の停止時間スリープ時間、例えば10秒、1分、1時間などを設定するを加える処理である。ステップS2405は、アプリケーション管理部220が、十分な期間実測リソース情報を収集した後に、当該情報をゲートウェイ管理装置へ送信する処理である、すなわち、実測リソース情報テーブル2100の各IDに対し、稼働時間があらかじめシステムで決める実測リソース計測時間例えば1日間、1週間などを設定するを超えていれば該ID行の情報ID、実測ヒープメモリ量、実測メモリ量、実測CPU使用率をゲートウェイ管理装置へ送信し、該ID行を削除する処理である。ステップS2406は、アプリケーション管理部220が、あらかじめ決める停止時間ステップS2404にて参照した停止時間のことスリープする処理である。そして、ステップS2401に戻る。図25は、ゲートウェイ管理装置100における実測リソース量集計処理S2500の処理フローを示す図である。適宜図1を参照して説明する。ゲートウェイ管理装置100は、複数のゲートウェイ装置200から実測リソース量を受信し集計する。図25に記載の処理の主体は全てアプリケーション配布管理部102である。アプリケーション配布管理部102は、サービス事業者の指定により実測リソース情報収集要とされたサービスアプリケーションの実測リソース情報を、該サービスアプリケーションを配布した多くのゲートウェイ装置200から収集し、その最大値および平均値を算出して実測リソース情報集計管理テーブル2200図22参照に記載する。また、アプリケーション配布管理部102は、十分な台数のゲートウェイ装置200から実測リソース情報を収集すると、その結果を、該当サービスアプリケーションを提供するサービス事業者へ送信する。ステップS2501は、アプリケーション配布管理部102が、図24のステップS2405の処理によって送られた実測リソース情報を受信する処理であり、ステップS2502は、受信した実測リソース情報に記載のIDを読みだす処理である。ステップS2503は、アプリケーション配布管理部102が、実測リソース情報集計管理テーブル2200図22参照の各リソースの最大値を更新する処理、すなわち、受信した実測リソース情報と、実測リソース情報集計管理テーブル2200の該当ID行を比較し、受信した実測リソース情報の実測ヒープメモリ量、実測メモリ量、実測CPU使用率が、実測リソース情報集計管理テーブル2200に記載の実測ヒープメモリ量最大値、実測メモリ量最大値、実測CPU使用率最大値より大きければ、各最大値を更新する処理である。ステップS2504は、アプリケーション配布管理部102が、実測リソース情報集計管理テーブル2200図22参照の各リソースの平均値を更新する処理である、すなわち、受信した実測リソース情報を基に実測リソース情報集計管理テーブル2200の該当ID行の各リソースの平均値を再計算する処理である。例えば、IDが010のサービスアプリケーションの実測メモリ量平均値については、以下のような計算式で算出することができる。テーブル2200の調査機器数×テーブル2200の実測メモリ量平均値受信した実測リソース情報の実測メモリ量/テーブル2200の調査機器数1なお、前記計算式中のテーブル名称は、略記している。実測ヒープメモリ量、実測CPU使用率についても同様の手順で算出することができる。ステップS2505は、アプリケーション配布管理部102が、実測リソース情報集計管理テーブル2200の該当ID行の調査機器数を1今回受信した機器分追加する処理である。ステップS2506は、アプリケーション配布管理部102が、該当IDのサービスアプリケーションに関して十分な量の実測リソース情報を集計できたかどうかを確認する処理である、すなわち、実測リソース情報集計管理テーブル2200の該当ID行の調査機器数があらかじめシステムで決める一定数例えば10、100、1000などに到達していればステップS2506,Yes、ステップS2507へと進み、該当ID行の実測リソース情報集計値をサービス事業者へ送信する。調査機器数があらかじめシステムで決める一定数に到達していなければステップS2506,No、処理を終了する。ステップS2507は、アプリケーション配布管理部102が、実測リソース情報集計値を送信するサービス事業者に関する情報を取得する処理である、すなわち、サービス管理テーブル2000から該IDに対応するサービス名とサービス事業者名を読みだす処理である。ステップS2508は、アプリケーション配布管理部102が、該当サービス事業者に該サービス名のサービスアプリケーションの実測リソース集計情報として実測リソース情報集計管理テーブル2200に記載の情報を送信する処理である。図25において、ゲートウェイ管理装置100のアプリケーション配布管理部102は、調査機器数が一定数に達するとサービス事業者に実測リソース集計情報を送信するが、アプリケーション配布管理部102がサービス事業者に実測リソース集計情報を送信するタイミングは、例えば、システムであらかじめ決める一定期間例えば1週間、1カ月など経過後、サービス事業者からゲートウェイ管理装置に問い合わせがあった際、などでもよい。その場合、実測リソース情報集計管理テーブル2200の項目や処理などが適宜変更となる。図14、図15、図16は、CABIおよびCABI-DMELが利用できない環境における、サービスアプリケーションの起動処理、メモリ使用量監視処理、およびCPU使用率監視処理を示す図である。図14は、CABIおよびCABI-DMELが利用できない環境における、サービスアプリケーション起動処理S1400の処理フローを示す図である。ステップS1401は、アプリケーション管理部220が、利用可能リソーステーブル400図4参照から、起動するサービスアプリケーションのIDに対応する利用可能ヒープメモリ量を取得する処理である。ステップS1402は、アプリケーション管理部220が、JavaVMの起動オプションの最大ヒープ量に該利用可能ヒープメモリ量を設定してOSGiフレームワークアプリケーション実行部を起動し、該OSGiフレームワークに該サービスアプリケーションをインストールおよび実行する処理である。ステップS1403は、アプリケーション管理部220が、該サービスアプリケーションを実行したソフトウェアプロセスのプロセスIDを調査、取得する。該サービスアプリケーションのIDおよび該プロセスIDをプロセスID管理テーブル1000図10参照に記憶する処理である。図15は、CABIおよびCABI-DMELが利用できない環境における、メモリ使用量監視処理S1500の処理フローを示す図である。ステップS1501は、アプリケーション管理部220が、プロセスID管理テーブル1000図10参照に定期監視を終えていないサービスアプリケーションIDが存在かどうか調べる処理である。プロセスID管理テーブル1000に定期監視を終えていないサービスアプリケーションIDが存在であればステップS1501,Yes、ステップS1502へ進む。あるいは、プロセスID管理テーブルに定期監視を終えていないサービスアプリケーションIDが存在でなければステップS1501,No、ステップS1508へ進む。ステップS1502は、アプリケーション管理部220が、プロセスID管理テーブル1000から定期監視を終えていないサービスアプリケーションのID、および該サービスアプリケーションIDに対応するプロセスIDを取得する処理である。ステップS1503は、アプリケーション管理部220が、該プロセスIDに対応するプロセスのメモリ使用量を取得する処理である。ステップS1504は、アプリケーション管理部220が、メモリ使用量が該サービスアプリケーションIDに対応する利用可能メモリ量を超過しているかどうか調べる処理である。メモリ使用量が該サービスアプリケーションIDに対応する利用可能メモリ量を超過している場合ステップS1504,Yes、ステップS1505へ進む。メモリ使用量が該サービスアプリケーションIDに対応する利用可能メモリ量を超過していない場合ステップS1504,No、ステップS1508へ進む。ステップS1505は、アプリケーション管理部220が、該サービスアプリケーションIDに対応するサービスアプリケーションを強制終了する処理である。ステップS1506は、アプリケーション管理部220が、利用可能リソーステーブル400図4参照、導入サービスアプリケーション依存関係管理テーブル900図9参照、プロセスID管理テーブル1000図10参照から該サービスアプリケーションIDに対応する項目を削除する処理である。ステップS1507は、アプリケーション管理部220が、該サービスアプリケーションを利用可能メモリ使用量超過で強制終了した事をシステムログなどに記録する処理である。そして、ステップS1508は、アプリケーション管理部220が、一定時間停止する処理である。その後、ステップS1501に戻る。図16は、CABIおよびCABI-DMELが利用できない環境における、CPU使用率監視処理S1600を示す図である。ステップS1601は、アプリケーション管理部220が、ゲートウェイ装置200のCPUのロードアベレージを取得する処理である。なお、ロードアベレージとは、実行待ちプロセス数の平均数を表す値であり、負荷平均のことを意味する。通常、サーバ負荷の指標として使われる。この値が大きければ負荷が大きく、小さければ負荷が小さい。ステップS1602は、アプリケーション管理部220が、ロードアベレージ>1かどうか調べる処理である。ロードアベレージ>1であればステップS1602,Yes、ステップS1603へ進む。ロードアベレージ>1でなければステップS1602,No、ステップS1609へ進む。ステップS1603は、アプリケーション管理部220が、プロセスID管理テーブル1000図10参照に定期監視を終えていないサービスアプリケーションIDが存在かどうか調べる処理である。プロセスID管理テーブル1000に定期監視を終えていないサービスアプリケーションIDが存在であればステップS1603,Yes、ステップS1604へ進む。あるいは、プロセスID管理テーブル1000に定期監視を終えていないサービスアプリケーションIDが存在でなければステップS1603,No、ステップS1609へ進む。ステップS1604は、アプリケーション管理部220が、プロセスID管理テーブル1000から定期監視を終えていないサービスアプリケーションのID、および該サービスアプリケーションIDに対応するプロセスIDを取得する処理である。ステップS1605は、アプリケーション管理部220が、該プロセスIDに対応するプロセスのCPU使用率を取得する処理である。ステップS1606は、アプリケーション管理部220が、CPU使用率が該サービスアプリケーションIDに対応する利用可能CPU使用率を超過しているかどうか調べる処理である。CPU使用率が該サービスアプリケーションIDに対応する利用可能CPU使用率を超過している場合ステップS1606,Yes、ステップS1607へ進む。CPU使用率が該サービスアプリケーションIDに対応する利用可能CPU使用率を超過していない場合ステップS1606,No、ステップS1609へ進む。ステップS1607は、アプリケーション管理部220が、該プロセスIDに対応するプロセスのスレッド優先度を下げるする処理である。ステップS1608は、アプリケーション管理部220が、該サービスアプリケーションが利用可能CPU使用率を超過した事をシステムログなどに記録する処理である。ステップS1609は一定時間停止する処理である。その後、ステップS1601に戻る。図18は、アプリケーション管理部220の異常通知処理S1800の処理フローを示す図である。図18は、サービスアプリケーション211が利用可能リソース量を超過した際に、ゲートウェイ管理装置100に異常を通知する手順を示す。ステップS1801は、アプリケーション管理部220が、システムログなどから、サービスアプリケーション211が利用可能リソース量を超過したかどうかに関する情報を取得する処理である。ステップS1802は、アプリケーション管理部220が、利用可能リソース量を超過したサービスアプリケーション有りかどうか調べる処理である。利用可能リソース量を超過したサービスアプリケーションが有りであればステップS1802,Yes、ステップS1803へ進む。利用可能リソース量を超過したサービスアプリケーションが有りでなければステップS1802,No、ステップS1804へ進む。ステップS1803は、アプリケーション管理部220が、該サービスアプリケーションのIDと利用可能リソース量を超過したかどうかに関する情報をゲートウェイ管理装置100に送信する処理である。ステップS1804は、アプリケーション管理部220が、一定時間、異常通知処理S1800を停止する処理である。その後、ステップS1801に戻る。図19は、アプリケーション管理部220の異常通知処理S1900の処理フローを示す図である。図19は、図18の他の処理フローであり、サービスアプリケーションが利用可能リソース量を超過した際に、ゲートウェイ管理装置100に異常を通知する手順を示す。ステップS1901は、アプリケーション管理部220が、システムログなどから、サービスアプリケーションが利用可能リソース量を超過したかどうかに関する情報を取得する処理である。ステップS1902は、アプリケーション管理部220が、利用可能リソース量を超過したサービスアプリケーション有かどうか調べる処理である。利用可能リソース量を超過したサービスアプリケーションが有りであればステップS1902,Yes、ステップS1903へ進む。利用可能リソース量を超過したサービスアプリケーションが有りでなければステップS1902,No、ステップS1905へ進む。ステップS1903は、アプリケーション管理部220が、導入サービスアプリケーション依存関係管理テーブル900図9参照を参照し、該サービスアプリケーションのIDに対応するImport-Packageに記載の情報に対するExport-Packageに記載しているサービスアプリケーションのIDの一覧Jを取得する処理である。ステップS1904は、アプリケーション管理部220が、該サービスアプリケーションのIDと、利用可能リソース量を超過したかどうかに関する情報と、Jの情報をゲートウェイ管理装置に送信する処理である。ステップS1905は、アプリケーション管理部220が、一定時間、異常通知処理S1900を停止する処理である。その後、ステップS1901に戻る。本実施形態において、アプリケーションサービス実行基盤を備えたゲートウェイ装置200に対し、サービス事業者の開発するアプリケーションサービス実行ソフトウェアアプリケーションソフトウェアを配布するゲートウェイ管理装置100は、アプリケーションサービス実行ソフトウェア各々が利用可能なゲートウェイ装置200のリソース量を管理するテーブルを備え、ゲートウェイ装置200に新規のソフトウェアを配布する際に、ゲートウェイ装置200の、アプリケーションサービス実行ソフトウェアが利用可能なリソース量の合計と、既にゲートウェイ装置200に導入済みのソフトウェアの利用可能なリソース量の合計を取得し、導入済みのソフトウェアの利用可能なリソース量の合計と新規ソフトウェアの利用可能なリソース量との合計と、アプリケーションサービス実行ソフトウェアが利用可能なリソース量の合計を比較し、導入済みのソフトウェアの利用可能なリソース量の合計と新規ソフトウェアの利用可能なリソース量との合計が、アプリケーションサービス実行ソフトウェアが利用可能なリソース量の合計を超えない場合に、新規ソフトウェアの配布を許可する。ゲートウェイ管理装置100は、サービス事業者の要求にしたがって、ゲートウェイ装置200からアプリケーション実行ソフトウェアの実測リソース量を収集し、収集した実測リソース量に関する情報をサービス事業者へ提供することができる。また、実施形態においては、ゲートウェイ管理装置100が配布するアプリケーションサービス実行ソフトウェアを実行するゲートウェイ装置200であって、処理部と、メモリを含む記憶部とを備え、記憶部は、アプリケーションサービス実行ソフトウェアを利用可能なリソース量の合計と、既に導入済みのソフトウェアを利用可能なリソース量の合計を保持し、ゲートウェイ管理装置100に新規のソフトウェアを要求する際、処理部は、保持するアプリケーションサービス実行ソフトウェアが利用可能なリソース量の合計と、既に導入済みのソフトウェアの利用可能リソース量の合計をゲートウェイ管理装置100に送信する。ゲートウェイ装置200は、ゲートウェイ管理装置100の要求にしたがって、アプリケーション実行ソフトウェアの実測リソース量を計測し、計測した実測リソース量をゲートウェイ管理装置100に送信することができる。さらに、アプリケーションサービス実行基盤を有するゲートウェイ装置200に対しアプリケーションサービス実行ソフトウェアを配布するゲートウェイ管理装置100を備えたゲートウェイ管理システムは、アプリケーションサービス実行ソフトウェア各々が利用可能なゲートウェイ装置200のリソース量を管理し、ゲートウェイ管理装置100は、ゲートウェイ装置200に新規のソフトウェアを配布する際に、ゲートウェイ装置200から、アプリケーションサービス実行ソフトウェアが利用可能なリソース量の合計と、ゲートウェイ装置200に既に導入済みのソフトウェアの利用可能リソース量の合計を取得し、既に導入済みのソフトウェアの利用可能リソース量の合計と新規ソフトウェアの利用可能リソース量との合計と、アプリケーションサービス実行ソフトウェアが利用可能なリソース量の合計とを比較し、既に導入済みのソフトウェアの利用可能リソース量の合計と新規ソフトウェアの利用可能リソース量との合計が、アプリケーションサービス実行ソフトウェアが利用可能なリソース量の合計を超えない場合に、新規ソフトウェアの配布を許可する。ゲートウェイ管理システムは、サービス事業者の要求にしたがって、ゲートウェイ装置200からアプリケーション実行ソフトウェアの実測リソース量を収集し、収集した実測リソース量に関する情報をサービス事業者へ提供することができる。本実施形態によれば、ゲートウェイ管理装置100は、サービス事業者が提供した各アプリケーションを管理するサービス管理テーブル2000、各アプリケーションが実行されたゲートウェイ装置200の機器数と、各アプリケーションが実行された際に必要なリソース実測値とが関連付けられた実測リソース情報集計管理テーブル2200を有する記憶部を備え、各ゲートウェイ装置200から、導入済みの各アプリケーションが実行された際に必要となったリソース実測値を受信した場合、該受信したリソース実測値に基づき実測リソース情報集計管理テーブル2200を更新し、機器数が所定値に達した場合、サービス管理テーブル2000に登録されているサービス事業者に、リソース実測値を通知することができる。以上述べたように、本実施形態におけるゲートウェイ管理装置100は、サービス事業者の要請にしたがってサービスアプリケーション211をゲートウェイ装置100に配布した後に、該ゲートウェイ装置200上でサービスアプリケーションを実行した結果、どの程度のリソース量ヒープメモリ量、メモリ量、CPU使用率を使用したかを多くのゲートウェイ装置200から収集、集計した情報をサービス事業者へ提供することを実現する。前述のような仕組みを搭載することでサービス事業者は、サービスアプリケーションの開発を、実機を用いずエミュレータなどを用いて行うような場合においても、実測リソース集計情報を得ることが可能となり、サービス事業者がゲートウェイ管理装置に登録する必要リソース量を高い精度で見積もることが可能となる。例えば、サービス事業者が設定する必要リソース量に応じて、ゲートウェイ管理装置100がサービス事業者に課金を行うようなシステムの場合、サービス事業者はサービスアプリケーションが安定的に動作する範囲内においてできるだけ必要リソース量を小さくしたいと考えるが、本実施形態の仕組みを用いる事で必要リソース量をより小さく設定することが可能となると考えられる。例えば、サービス事業者が新規サービスを開始する際に、最初はベータテストとして実測リソース量収集要として、必要リソース量はある程度余裕のある大き目の値を設定してゲートウェイ管理装置に登録し、実測リソース集計情報を得て、その結果を基に正式版を、最小限の必要リソース量の設定で登録するというような運用が可能となる。"