ゲートウェイ管理方法、ゲートウェイ管理装置、およびゲートウェイ装置
【課題】ゲートウェイ装置からアプリケーションソフトウェアの実行に必要なリソース値をサービス事業者へ提供可能とするゲートウェイ管理方法を提供する。
【解決手段】ゲートウェイ管理装置１００は、サービス事業者が提供した各アプリケーションを管理するサービス管理テーブル２０００、各アプリケーションが実行されたゲートウェイ装置２００の機器数と、各アプリケーションが実行された際に必要なリソース実測値とが関連付けられた実測リソース情報集計管理テーブル２２００を有する記憶部を備え、各ゲートウェイ装置２００から、導入済みの各アプリケーションが実行された際に必要となったリソース実測値を受信した場合、該受信したリソース実測値に基づき実測リソース情報集計管理テーブル２２００を更新し、機器数が所定値に達した場合、サービス管理テーブル２０００に登録されているサービス事業者に、リソース実測値を通知する。
【解決手段】ゲートウェイ管理装置１００は、サービス事業者が提供した各アプリケーションを管理するサービス管理テーブル２０００、各アプリケーションが実行されたゲートウェイ装置２００の機器数と、各アプリケーションが実行された際に必要なリソース実測値とが関連付けられた実測リソース情報集計管理テーブル２２００を有する記憶部を備え、各ゲートウェイ装置２００から、導入済みの各アプリケーションが実行された際に必要となったリソース実測値を受信した場合、該受信したリソース実測値に基づき実測リソース情報集計管理テーブル２２００を更新し、機器数が所定値に達した場合、サービス管理テーブル２０００に登録されているサービス事業者に、リソース実測値を通知する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ゲートウェイ管理方法、ゲートウェイ管理装置、およびゲートウェイ装置に関し、特に、サービス事業者の要求に応じてサービス事業者の作成するアプリケーションのリソース上限設定に必要な情報を、サービス事業者へ提供可能なゲートウェイ管理方法、ゲートウェイ管理装置、およびゲートウェイ装置に関する。
【背景技術】
【０００２】
従来、ＡＤＳＬ（Asymmetric Digital Subscriber Line）、ＣＡＴＶ（Community Antenna TeleVision）、ＦＴＴＨ（Fiber To The Home）といったＷＡＮ（Wide Area Network）とホームネットワークなどのＬＡＮ（Local Area Network）を接続するゲートウェイ装置は、音声（ＩＰ(Internet Protocol)電話など）、映像（放送、ＶｏＤ（(Video on Demand）など）、データ通信（インターネット接続など）といったいわゆるトリプルプレイサービスを提供してきた。
【０００３】
近年では、前記トリプルプレイサービスに加え、ホームネットワークに接続する様々な機器を制御するアプリケーションのインストールおよび管理を行うことにより、機能を動的に拡張できる手段が提案されている（例えば、特許文献１参照）。
【０００４】
特許文献１におけるホームネットワークシステムは、各種ホームネットワークミドルウェアを統合支援するＯＳＧｉ（Open Services Gateway Initiative）フレームワークを搭載したゲートウェイ装置などのアプリケーションサーバを導入し、種々のデバイスへアクセスするためのミドルウェアサービスをバンドル機能として提供することにより、ミドルウェアに制約されないホームネットワークシステムを実現する。
【０００５】
しかしながら、特許文献１に記載のＯＳＧｉフレームワークには様々なソフトウェア部品（ＯＳＧｉバンドルと呼ぶ）を単一のソフトウェアプロセス上で動作するフレームワーク上で動作させることから、個別のＯＳＧｉバンドルがどの程度のＣＰＵ、メモリなどのリソースを消費するかを詳細に知ることができないという問題がある。
【０００６】
この問題に対し、個別のバンドルのリソース消費量を複数のゲートウェイでの平均消費量として求める手段（例えば、特許文献２参照）や、サービス事業者ごとに別々のＯＳＧｉフレームワークのソフトウェアプロセスを生成し、サービス事業者ごとに使用メモリ（Ｊａｖａ（登録商標）のヒープメモリ）にあらかじめ決めておいた上限値を設定することで円滑なサービス運用を実現する手段（例えば、特許文献３参照）が開示されている。
【０００７】
特許文献２は、複数のゲートウェイがもつリソースの消費量についての解析結果を得る管理システムの動作方法であって、前記ゲートウェイのそれぞれから、該ゲートウェイで検出された消費量を示す消費量情報と、検出のときに当該ゲートウェイで実行されていたプログラムを示す実行プログラムリストとを取得し、平均消費量を含むレコードを作成する管理システムの動作方法が開示されている。
【０００８】
特許文献３には、サービス事業者ごとに利用可能なメモリの上限を管理し、アプリケーション起動時にＪａｖａ（登録商標）の起動オプションにてヒープの上限値に設定することで設定値以上のメモリを該アプリケーションが利用できないようにする方法が開示されている。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】特開２００４−２１３６１２号公報（第３図）
【特許文献２】特開２００７−３１６９４７号公報（第１図）
【特許文献３】特開２００８−１５９５４号公報（第１図）
【発明の概要】
【発明が解決しようとする課題】
【００１０】
前記特許文献２、特許文献３に示される方法には次のような問題がある。まず、特許文献２に示される方法では、複数のプログラムが消費するリソースと実行プログラムリストを複数のゲートウェイ装置から収集することで各々のプログラムが消費するリソースの平均消費量を求める方法が開示されているが、あくまでも平均消費量であり、各々のゲートウェイ装置において、各々のプログラムが、実際にどのようにリソースを消費したのかを示す消費リソース量の実測値を得る方法については言及がない。すなわち、消費リソース量の実測値を基にして、厳密なリソース管理を行う方法については開示されていない。
【００１１】
また、特許文献３に示される方法では、アプリケーションの利用可能なメモリの上限について、どのように決定をするかについての言及がない。すなわち、サービス事業者とゲートウェイ装置やＯＳＧｉフレームワークなどのアプリケーション基盤を提供するプラットフォーム事業者との責任分界点を考えると、サービス事業者が提供するアプリケーションの利用可能なメモリの上限については、サービス事業者が自ら必要なメモリ使用量を上限値としてプラットフォーム事業者に申告、設定することが自然であると考えられる。しかし、例えば、サービス事業者がゲートウェイ装置の実機を持たずゲートウェイ装置のエミュレータを用いてアプリケーション開発を行うような場合には必要なメモリ上限について精度の高い申告、設定を行うことが困難となる可能性がある。
【００１２】
本発明は、前記の課題を解決するための発明であって、サービス事業者の要求に応じて、ゲートウェイ装置からサービス事業者の作成するアプリケーションソフトウェアの実行に必要なリソース実測値を収集し、該リソース実測値をサービス事業者へ提供可能とする、ゲートウェイ管理方法、ゲートウェイ管理装置、およびゲートウェイ装置を提供することを目的とする。
【課題を解決するための手段】
【００１３】
前記目的を達成するため、本発明のゲートウェイ管理方法は、サービス事業者がゲートウェイ装置に対して提供するアプリケーションソフトウェアであるアプリケーションを管理するとともに、ゲートウェイ装置においてアプリケーションを実行した際に必要となるリソース実測値をサービス事業者に通知するゲートウェイ管理装置のゲートウェイ管理方法であって、ゲートウェイ管理装置は、サービス事業者がサービス事業者サーバから提供した各アプリケーションを、該サービス事業者と関連付けて管理するアプリケーション管理情報（例えば、サービス管理テーブル２０００）を有するとともに、各アプリケーションが実行されたゲートウェイ装置の機器数と、各アプリケーションが実行された際に必要なリソース実測値とが関連付けられた実測リソース集計管理情報（例えば、実測リソース情報集計管理テーブル２２００）を有する記憶部（例えば、サービス管理ＤＢ１１０）を備え、ゲートウェイ管理装置は、各ゲートウェイ装置から、導入済みの各アプリケーションが実行された際に必要となったリソース実測値を受信し、該受信したリソース実測値に基づき実測リソース集計管理情報を更新し（例えば、ステップＳ２５０４）、アプリケーション管理情報に登録されているアプリケーションの機器数が所定値に達しているか判定し、所定値に達したアプリケーションについてアプリケーション管理情報に登録されているサービス事業者に、リソース実測値を通知する（例えば、ステップＳ２５０８）ことを特徴とする。
【発明の効果】
【００１４】
本発明によれば、サービス事業者の要求に応じて、ゲートウェイ装置からサービス事業者の作成するアプリケーションソフトウェアの実行に必要なリソース実測値を収集し、該リソース実測値をサービス事業者へ提供可能とすることができる。
【図面の簡単な説明】
【００１５】
【図１】本実施形態における機能構成およびネットワーク構成の一例を示す図である。
【図２】本実施形態におけるゲートウェイ管理装置およびゲートウェイ装置のハードウェア構成の一例を示す図である。
【図３】ゲートウェイ装置の全体利用可能リソーステーブルを示す図である。
【図４】ゲートウェイ装置の利用可能リソーステーブルを示す図である。
【図５】ゲートウェイ管理装置の必要リソーステーブルを示す図である。
【図６】アプリケーション配布管理部によるゲートウェイ装置への新規サービス導入処理の処理フローを示す図である。
【図７】アプリケーション管理部によるサービスアプリケーションの起動処理の処理フローを示す図である。
【図８】ゲートウェイ管理装置の依存関係テーブルを示す図である。
【図９】ゲートウェイ装置の導入サービスアプリケーション依存関係管理テーブルを示す図である。
【図１０】ゲートウェイ装置のプロセスＩＤ管理テーブルを示す図である。
【図１１】新規導入希望サービスを導入可能である画面表示の一例を示す図である。
【図１２】新規導入希望サービスを導入不可である画面表示の一例を示す図である。
【図１３】本実施形態における機能構成の一例を示す図である。
【図１４】ＣＡＢＩおよびＣＡＢＩ−ＤＭＥＬが利用できない環境における、サービスアプリケーションの起動処理の処理フローを示す図である。
【図１５】ＣＡＢＩおよびＣＡＢＩ−ＤＭＥＬが利用できない環境における、サービスアプリケーションのメモリ使用量監視処理の処理フローを示す図である。
【図１６】ＣＡＢＩおよびＣＡＢＩ−ＤＭＥＬが利用できない環境における、サービスアプリケーションのＣＰＵ使用率監視処理の処理フローを示す図である。
【図１７】図６に示した新規サービス導入処理を示す処理フローに対応するシーケンスを示す図である。
【図１８】アプリケーション管理部の異常通知処理の処理フローを示す図である。
【図１９】アプリケーション管理部の異常通知処理の他の処理フローを示す図である
【図２０】ゲートウェイ管理装置のサービス管理テーブルを示す図である。
【図２１】ゲートウェイ装置の実測リソース情報テーブルを示す図である。
【図２２】ゲートウェイ管理装置の実測リソース情報集計管理テーブルを示す図である。
【図２３】アプリケーション登録管理部によるゲートウェイ管理装置への新規サービス登録処理の処理フローを示す図である。
【図２４】ゲートウェイ装置における実測リソース量計測処理の処理フローを示す図である。
【図２５】ゲートウェイ管理装置における実測リソース量集計処理の処理フローを示す図である。
【発明を実施するための形態】
【００１６】
本発明の実施形態について、図面を参照して詳細に説明する。
図１は、本実施形態における機能構成およびネットワーク構成の一例を示す図である。ゲートウェイ管理システムは、ゲートウェイ管理装置１００、複数の利用者宅５０内のゲートウェイ装置２００、複数のサービス事業者サーバ４０とを含んで構成されている。利用者宅５０内において、ゲートウェイ装置２００は、利用者宅内ネットワーク２３０を介して複数の宅内機器２４０に接続されている。
【００１７】
ゲートウェイ管理装置１００、サービス事業者サーバ４０、およびゲートウェイ装置２００は、フレッツ（登録商標）などの閉域網、または、インターネットからなる外部ネットワーク３０と接続しており、所定の手順に従って情報のやり取りを行うことができる。
【００１８】
ゲートウェイ装置２００と宅内機器２４０は、利用者宅５０内に設置され、有線または無線から構成される利用者宅内ネットワーク２３０と接続しており、所定の手順に従って情報のやり取りを行うことができる。
【００１９】
ゲートウェイ装置２００は、外部ネットワーク３０と利用者宅内ネットワーク２３０の両方と接続しており、利用者宅５０に設置された機器にとって、外部ネットワーク３０に接続された機器と情報のやり取りをするためのゲートウェイとしての機能を有する。
【００２０】
ゲートウェイ管理装置１００は、処理部として、サービス事業者サーバ４０から依頼を受けてゲートウェイ管理装置１００への新規サービスの登録処理Ｓ２３００（図２３参照）を行うアプリケーション登録管理部１０１と、ゲートウェイ装置２００へ新規サービス導入処理Ｓ６００（図６参照）、ゲートウェイ装置２００から受信した実測リソース量集計処理Ｓ２５００（図２５参照）などを行うアプリケーション配布管理部１０２と、ＤＢ管理部１０３とを有する。なお、ＤＢはData Baseの略である。
【００２１】
また、ゲートウェイ管理装置１００は、サービス管理ＤＢ１１０を有し、サービス管理ＤＢ１１０には、サービス管理テーブル２０００（アプリケーション管理情報）（図２０参照）、実測リソース情報集計管理テーブル２２００（実測リソース集計管理情報）（図２２参照）、必要リソーステーブル５００（リソース管理情報）（図５参照）、依存関係テーブル８００（図８参照）が格納されている。
【００２２】
ゲートウェイ装置２００は、処理部として、サービスアプリケーション２１１を実行するアプリケーション実行部２１０、サービスアプリケーション２１１の状況を管理するアプリケーション管理部２２０とを有している。
【００２３】
アプリケーション管理部２２０は、サービスアプリケーション起動処理Ｓ７００（図７参照）、サービスアプリケーション起動処理Ｓ１４００（図１４参照）、メモリ使用量監視処理Ｓ１５００（図１５参照）、メモリ使用量監視処理Ｓ１６００（図１６参照）、異常通知処理Ｓ１８００（図１８参照）、異常通知処理Ｓ１９００（図１９参照）、実測リソース量計測処理Ｓ２４００（図２４参照）などの処理を行う機能を有している。
【００２４】
また、ゲートウェイ装置２００は、ゲートウェイ管理ＤＢ２５０を有し、ゲートウェイ管理ＤＢ２５０には、実測リソース情報テーブル２１００（実測リソース装置情報）（図２１参照）、全体利用可能リソーステーブル３００（図３参照）、利用可能リソーステーブル４００（図４参照）、導入サービスアプリケーション依存関係管理テーブル９００（図９参照）、およびプロセスＩＤ管理テーブル１０００（図１０参照）が格納されている。
【００２５】
図２は、ゲートウェイ管理装置１００およびゲートウェイ装置２００のハードウェア構成の一例を示す図である。ゲートウェイ管理装置１００は、ＥＰＲＯＭ１１、ＣＰＵ１２、メインメモリ１３、バス１４、不揮発性記憶装置１５、周辺制御装置１６、ネットワークＩ／Ｆ１７を有している。ＥＰＲＯＭ１１、ＣＰＵ１２、メインメモリ１３、周辺制御装置１６はバス１４と接続し、不揮発性記憶装置１５、ネットワークＩ／Ｆ１７は周辺制御装置１６を介してバス１４と接続しており、所定の手順に従って情報のやり取りを行うことができる。なお、ＥＰＲＯＭはErasable Programmable Read Only Memoryの略であり、ＣＰＵはCentral Processing Unitの略であり、Ｉ／ＦはInterfaceの略である。
【００２６】
ゲートウェイ装置２００は、ＥＰＲＯＭ２１、ＣＰＵ２２、メインメモリ２３、バス２４、不揮発性記憶装置２５、周辺制御装置２６、ネットワークＩ／Ｆ２７、ネットワークＩ／Ｆ２８を有している。ＥＰＲＯＭ２１、ＣＰＵ２２、メインメモリ２３、周辺制御装置２６はバス２４と接続し、ネットワークＩ／Ｆ２７、ネットワークＩ／Ｆ２８、不揮発性記憶装置２５は周辺制御装置２６を介してバス２４と接続しており、所定の手順に従って情報のやり取りを行うことができる。
【００２７】
ゲートウェイ管理装置１００において、ＥＰＲＯＭ１１にはブートプログラムが格納されている。また、不揮発性記憶装置１５には各種プログラムが記憶されている。ゲートウェイ管理装置１００が起動するとＥＰＲＯＭ１１に格納されたブートプログラムによって不揮発性記憶装置１５から各種プログラムがメインメモリ１３へと読み出される。ＣＰＵ１２はメインメモリ１３に読み出された各種プログラムを実行することにより、ネットワークＩ／Ｆ１７への信号の送受信を行う。
【００２８】
ネットワークＩ／Ｆ１７は外部ネットワーク３０と接続しており、外部ネットワーク３０に接続する機器との間で情報のやり取りを行うことができる。ネットワークＩ／Ｆ１７はネットワークカードなどにより実現することができる。
【００２９】
不揮発性記憶装置１５には、前述のようにＣＰＵ１２がメインメモリ１３に読み出して実行するための各種プログラムが記憶されており、フラッシュメモリやＨＤＤ（ハードディスクドライブ）により実現することができる。
【００３０】
ゲートウェイ装置２００において、ＥＰＲＯＭ２１にはブートプログラムが格納されている。また、不揮発性記憶装置２５には各種プログラムが記憶されている。ゲートウェイ装置２００が起動するとＥＰＲＯＭ２１に格納されたブートプログラムによって不揮発性記憶装置２５から各種プログラムがメインメモリ２３へと読み出される。ＣＰＵ２２はメインメモリ２３に読み出された各種プログラムを実行することにより、ネットワークＩ／Ｆ２７やネットワークＩ／Ｆ２８への信号の送受信を行う。
【００３１】
ネットワークＩ／Ｆ２７は、外部ネットワーク３０と接続しており、外部ネットワーク３０に接続する機器との間で情報のやり取りを行うことができる。ネットワークＩ／Ｆ２７はネットワークカードなどにより実現することができる。
【００３２】
ネットワークＩ／Ｆ２８は、利用者宅５０内のネットワーク２３０と接続しており、利用者宅内ネットワーク２３０に接続する機器との間で情報のやり取りを行うことができる。ネットワークＩ／Ｆ２８はネットワークカードなどにより実現することができる。
【００３３】
不揮発性記憶装置２５には、前述のようにＣＰＵ２２がメインメモリ２３に読み出して実行するための各種プログラムが記憶されており、フラッシュメモリやＨＤＤ（ハードディスクドライブ）により実現することができる。図示しないが、サービス事業者サーバ４０のハードウェア構成は、通常のＰＣ（Personal Computer）と同様である。
【００３４】
次に、本実施形態において、ゲートウェイ管理装置１００、ゲートウェイ装置２００が扱う各テーブルについて説明する。
【００３５】
図３は、ゲートウェイ装置２００の全体利用可能リソーステーブル３００を示す図である。全体利用可能リソーステーブル３００は、アプリケーションサービス全体が利用可能なリソース量を示すテーブルである。全体利用可能リソーステーブル３００には、全体利用可能ＣＰＵ使用率３０１、全体利用可能メモリ量３０２といった項目がある。具体的には、行３０３には、全体利用可能ＣＰＵ使用率は５０％であり、全体利用可能メモリ量は３０ＭＢであることがわかる。
【００３６】
図４は、ゲートウェイ装置２００の利用可能リソーステーブル４００を示す図である。利用可能リソーステーブル４００は、個別のアプリケーションサービスが利用可能なリソースを管理するテーブルである。利用可能リソーステーブル４００には、ＩＤ４０１、利用可能ヒープメモリ量４０２、利用可能メモリ量４０３、利用可能ＣＰＵ使用率４０４といった項目がある。具体的には、行４０５のＩＤが「０００」の場合、利用可能ヒープメモリ量は６ＭＢ、利用可能メモリ量１５ＭＢ、利用可能ＣＰＵ使用率は２０％である。行４０６のＩＤが「００３」の場合、利用可能ヒープメモリ量は３ＭＢ、利用可能メモリ量６ＭＢ、利用可能ＣＰＵ使用率は１０％である。
【００３７】
図５は、ゲートウェイ管理装置１００の必要リソーステーブル５００を示す図である。必要リソーステーブル５００は、ゲートウェイ管理装置１００が管理する個別のアプリケーションサービスが利用可能なリソースを管理するテーブルである。必要リソーステーブル５００には、ＩＤ４０１、必要ヒープメモリ量５０２、必要メモリ量５０３、必要ＣＰＵ使用率５０４といった項目がある。具体的には、複数のサービス事業者サーバ４０が提供しているサービスアプリケーション２１１の必要リソースとして、行５０６のＩＤが「００１」の場合、必要ヒープメモリ量は１ＭＢ、必要メモリ量は２ＭＢ、必要ＣＰＵ使用率は１０％である。また、行５０７のＩＤが「００２」の場合は、必要ヒープメモリ量は４ＭＢ、必要メモリ量は１０ＭＢ、必要ＣＰＵ使用率は３０％である。
【００３８】
さらに、行５０５のＩＤが「０００」は図４で示した行４０５の「０００」に対応し、行５０８のＩＤが「００３」は図４で示した行４０６の「００３」に対応し、および行５０９のＩＤが「０１０」は図４に示した行４０７の「０１０」に対応している。
【００３９】
図８は、ゲートウェイ管理装置１００の依存関係テーブル８００を示す図である。依存関係テーブル８００は、サービスアプリケーション間の依存関係を管理するテーブルである。依存関係テーブル８００には、ＩＤ４０１、Import-Package８０２、Export-Package８０３といった項目がある。
【００４０】
Import-Package８０２は、ＩＤ４０１に指定されているバンドルの利用に必要なパッケージ、言い換えると、このバンドルが依存しているパッケージを示す。行８０４の例ではImport-Packageがorg.osgi.frameworkとしており、org.osgi.frameworkというパッケージに依存することを意味する。Export-Package８０３は、他のバンドルに公開されるパッケージを示す。行８０４では、Export-Packageがorg.osgi.service.httpとしており、org.osgi.service.httpというパッケージをバンドル外に公開している。逆にExport-Package８０３に宣言されていないパッケージは、他のバンドルからアクセスができないことを意味する。
【００４１】
図９は、ゲートウェイ装置２００の導入サービスアプリケーション依存関係管理テーブル９００を示す図である。導入サービスアプリケーション依存関係管理テーブル９００は、ゲートウェイ装置２００に導入したサービスアプリケーション間の依存関係を管理するテーブルである。導入サービスアプリケーション依存関係管理テーブル９００には、ＩＤ４０１、Import-Package９０２、Export-Package９０３といった項目がある。
【００４２】
図１０は、ゲートウェイ装置２００のプロセスＩＤ管理テーブル１０００を示す図である。プロセスＩＤ管理テーブル１０００は、サービスアプリケーション２１１に対応するプロセスＩＤを管理するテーブルである。プロセスＩＤ管理テーブル１０００には、ＩＤ４０１、プロセスＩＤ１００２といった項目がある。
【００４３】
図２０は、ゲートウェイ管理装置１００のサービス管理テーブル２０００を示す図である。サービス管理テーブル２０００（アプリケーション管理情報）は、サービス名と、サービス事業者名およびサービスＩＤとの対応を管理するテーブルである。サービス管理テーブル２０００には、サービス名２００１、サービス事業者名２００２、ＩＤ４０１といった項目がある。具体的には、サービス名が「home control」は、「家操作(株)」のサービス事業者が提供しているサービスであり、サービス名が「healthcare」は、「(株)健康Ｎｏ.１」のサービス事業者が提供しているサービスである。
【００４４】
図２１は、ゲートウェイ装置２００の実測リソース情報テーブル２１００を示す図である。実測リソース情報テーブル２１００（実測リソース装置情報）は、ＩＤ４０１に対応する実測リソース情報を管理するテーブルである。実測リソース情報テーブル２１００には、ＩＤ４０１、実測ヒープメモリ量２１０１、実測メモリ量２１０２、実測ＣＰＵ使用率２１０３、稼働時間２１０４といった項目がある。
【００４５】
図２２は、ゲートウェイ管理装置１００の実測リソース情報集計管理テーブル２２００を示す図である。実測リソース情報集計管理テーブル２２００（実測リソース集計管理情報）は、ＩＤ４０１に対応する調査機器数の実測リソース情報集計管理テーブルである。実測リソース情報集計管理テーブル２２００には、ＩＤ４０１、調査機器数２２０１、実測ヒープメモリ量最大値２２０２、実測ヒープメモリ量平均値２２０３、実測メモリ量最大値２２０４、実測メモリ量平均値２２０５、実測ＣＰＵ使用率最大値２２０６、実測ＣＰＵ使用率平均値２２０７といった項目がある。具体的には、行２２０８を参照すると、ＩＤが「０１０」の場合、調査機器数は１５であり、各リソースの最大値および平均値が集計されている。例えば、実測ヒープメモリ量の最大値は０．５ＭＢであり、実測ヒープメモリ量の平均値は０．３５ＭＢである。このことから、図２０、図２２を参照すると、ＩＤが「０１０」のサービス名が「home comtrol」を運用する際の、精度の高い各リソースの最大値および平均値を得ることができる。
【００４６】
次に本実施形態の各装置の処理部の動作について、適宜図１を参照して説明する。
ゲートウェイ管理装置１００は、様々なサービス事業者サーバ４０を保持するサービス事業者が提供するサービスアプリケーションを、ゲートウェイ装置２００へ外部ネットワーク３０を介して配布するサービスサービスアプリケーション配布基盤としての機能を有している。サービス事業者サーバ４０を保持するサービス事業者は、作成したサービスアプリケーション２１１の配布をゲートウェイ管理装置１００へ委託することにより、サービスアプリケーション配布サーバなどを自身で設置すること、アプリケーション実行部２１０を備えたゲートウェイ装置２００などを自ら利用者へ配布することの必要がなくなり、コストを抑えてサービス提供を行うことが可能となる。
【００４７】
ゲートウェイ装置２００は、様々なサービスアプリケーション２１１を実行するアプリケーション実行部２１０を備える。アプリケーション実行部２１０は、例えば、ＯＳＧｉ（登録商標）フレームワークのようなアプリケーション実行基盤を用いて実現することができ、ゲートウェイ管理装置１００が配布するサービスアプリケーション２１１を実行することにより、様々な宅内機器２４０を、利用者宅内ネットワーク２３０を介して制御可能とするなど、ゲートウェイ装置２００の機能を柔軟に拡張することを可能とする。
【００４８】
アプリケーション実行部２１０としてＯＳＧｉフレームワークを用いる場合、通常ＯＳＧｉフレームワークは、単一のフレームワーク上で複数のサービスアプリケーション２１１を実行することが可能であるが、本実施形態では、サービスアプリケーション２１１のそれぞれが、利用するゲートウェイ装置２００のＣＰＵ処理時間（ＣＰＵ使用率）や利用メモリ量といったリソースを詳細に制御するために、サービスアプリケーション２１１ごとに別個にアプリケーション実行部２１０を起動することを想定する。
【００４９】
ＯＳＧｉフレームワークのようなアプリケーション実行基盤は、様々なサービスアプリケーション２１１間でお互いの機能を適切に呼び合うことを可能とする。例えば、ＯＳＧｉサービスプラットフォーム仕様が標準で規定するＨＴＴＰサービスはＷＥＢサーバおよびサーブレットコンテナの機能を有し、サーブレットとして実装された他のサービスアプリケーション２１１は、ＨＴＴＰサービスが提供するサーブレットコンテナ機能に自身を登録することにより、サービスアプリケーション２１１を提供するサービス事業者は、簡単にＷＥＢサーバおよびサーブレットコンテナの機能を利用することができる。
【００５０】
アプリケーション実行部２１０をサービスアプリケーション２１１ごとに起動した場合、通常前記のようなサービスアプリケーション２１１間の連携機能は使用できなくなってしまうが、ＯＳＧｉサービスプラットフォーム仕様Ｒ４．２にはＨＴＴＰサービスと同様の標準サービスとしてリモートサービスの仕様が追加されている。リモートサービスはＯＳＧｉの核となるサービスのＩｍｐｏｒｔ／Ｅｘｐｏｒｔ機能を異なるＪａｖａ（登録商標）ＶＭ上で動作するＯＳＧｉフレームワークと共有することを可能とする。
【００５１】
本実施形態においては、特にことわりのない限り、アプリケーション実行部２１０はＯＳＧｉフレームワークを用いて実現され、アプリケーション実行部２１０は、様々なサービスアプリケーション２１１ごとにアプリケーション管理部２２０によって異なるＪａｖａＶＭ（異なるソフトウェアプロセス）上で実行され、起動した複数のアプリケーション実行部２１０間はＯＳＧｉサービスプラットフォームの標準サービスである、リモートサービスを用いて互いに連携可能であることを想定する。
【００５２】
また、本実施形態においては、サービスアプリケーション２１１は、１つまたは複数のプログラム（ソフトウェア部品、ＯＳＧｉバンドルと言う）からなる。本実施形態においては、１つのアプリケーション実行部２１０では、１つのサービスアプリケーション２１１が動作することを想定する。ただし、１つのアプリケーション実行部２１０で複数のサービスアプリケーション２１１を実行することも可能である。例えば、サービスアプリケーション２１１の提供事業者ごとに同一のアプリケーション実行部を利用するということも可能である。
【００５３】
本実施形態において、ＣＰＵ使用率、メモリ使用量といったリソースの管理を行うことができるのはアプリケーション実行部２１０ごとである。例えば、前記のように、サービスアプリケーション２１１の提供事業者ごとに同一のアプリケーション実行部２１０を利用する場合、利用可能なリソース量を超過した場合には該サービスアプリケーション提供事業者の提供するサービスアプリケーション２１１のいずれかに問題があるであろう、ということまで分かる。
【００５４】
１つのアプリケーション実行部２１０で複数のサービスアプリケーション２１１を実行すると、ゲートウェイ装置全体におけるアプリケーション実行部２１０を実現するプログラム（ＪａｖａＶＭやＯＳＧｉフレームワークなど）の実行数が減少し、その分機器全体でのメモリ使用量などを節約することができるという効果があるが、本実施形態では説明を簡便にするために１つのアプリケーション実行部では１つのサービスアプリが動作することを想定する。
【００５５】
また、本実施形態におけるゲートウェイ装置２００は、アプリケーション実行部２１０の実行されるソフトウェアプロセスそれぞれのＣＰＵ使用率、メモリ使用量、Ｊａｖａのヒープメモリ使用量の上限値を適切に制御可能な構成を想定する。
【００５６】
例えば、ゲートウェイ装置２００のＯＳ（基本ソフト）がＬｉｎｕｘ（登録商標）である場合、ソフトウェアプロセスのＣＰＵ使用率はＣＡＢＩ（CPU Accounting and Blocking Interface）のようなＣＰＵリソースマネジメントシステムを用いて制御が可能である。ＣＡＢＩはある周期におけるＣＰＵ使用時間の上限値を設定することが可能で、例えば、あるソフトウェアプロセスに対し、周期が１００ｍｓ、ＣＰＵ使用時間の上限値が３０ｍｓといったＣＡＢＩのＡＯ（アカウンティングオブジェクト）を設定した場合、１００ｍｓの間に３０ｍｓの時間においてＣＰＵを利用すると、３０ｍｓ後のＣＰＵの利用をブロックされ、ＣＰＵリソースが他のプロセスへと開放される。本実施形態においては、特にことわりのない限り、ゲートウェイ装置２００のＯＳはＬｉｎｕｘであり、ＣＰＵリソースマネジメントにはＣＡＢＩを用いることを想定するが、例えばその他のリアルタイムＯＳなどにおいても同様の仕組みを用いて実現が可能な場合がある。
【００５７】
また、例えば、ゲートウェイ装置２００のＯＳ（基本ソフト）がＬｉｎｕｘである場合、ソフトウェアプロセスのメモリ使用量はＣＡＢＩ−ＤＭＥＬ（Common resource management Accounting and Blocking Interfaces - Dependable Memory management system for Embedded Linux）のようなメモリリソースマネジメントシステムを用いて制御が可能である。ＣＡＢＩ−ＤＭＥＬはあるソフトウェアプロセスに対する物理メモリの割り当ての上限制限をすることが可能であり、上限値以上のメモリを確保しようとした場合にメモリ割り当てをブロックすることができる。本実施形態においては、特にことわりのない限り、ゲートウェイ装置２００のＯＳはＬｉｎｕｘであり、メモリリソースマネジメントにはＣＡＢＩ−ＤＭＥＬを用いることを想定するが、例えばその他のＯＳなどにおいても同様の仕組みを用いて実現が可能な場合がある。
【００５８】
また、本実施形態ではアプリケーション実行部２１０は、ＯＳＧｉフレームワークを用いて実現されることを想定するが、ＯＳＧｉフレームワークはＪａｖａＶＭ（Java Virtual Machine）を用いて起動される。ＪａｖａＶＭは実行するプログラムの利用可能なヒープメモリの上限を指定することが可能であり、設定した上限値以上のヒープメモリの利用をブロックすることができる。
【００５９】
図１３は、本実施形態における機能構成の一例を示す図である。図１３は、アプリケーション実行部２１０を実現するプログラムとしてＪａｖａＶＭ、ＯＳＧｉフレームワーク（OSGi Framework）、ＯＳＧｉの標準サービスであるリモートサービスバンドルを用いた場合のゲートウェイ装置２００の機能構成図である。
【００６０】
サービスアプリケーション２１１を実行するごとにＪａｖａＶＭとＯＳＧｉフレームワークが起動し、各ＯＳＧｉフレームワーク上でリモートサービスバンドルが動作し、それぞれのアプリケーション実行部２１０ａ，２１０ｂ，２１０ｃのＯＳＧｉフレームワーク上において各サービスアプリケーション２１１が動作している。
【００６１】
ＯＳＧｉは通常、同一のＪａｖａＶＭ上で動作するＯＳＧｉフレームワーク上で動作するプログラム（バンドル）間においてお互いの機能（サービス）を呼び合うことができるが、リモートサービスを用いると異なるＪａｖａＶＭ上で動作するＯＳＧｉフレームワーク間で機能（サービス）の情報をやり取りすることができ、リモートサービスが導入されたＯＳＧｉフレームワーク上で実行されるサービスアプリケーション２１１は異なるアプリケーション実行部で動作するサービスアプリケーション２１１の機能（サービス）を利用することが可能となる。また、各アプリケーション実行部２１０ａ，２１０ｂ，２１０ｃの起動処理などの管理はアプリケーション管理部２２０が行う。
【００６２】
図２３は、アプリケーション登録管理部１０１によるゲートウェイ管理装置１００への新規サービス登録処理Ｓ２３００の処理フローを示す図である。図２３は、ゲートウェイ管理装置１００のアプリケーション登録管理部１０１が、サービス事業者のサービス事業者サーバ４０から受信する情報を基にゲートウェイ管理装置１００へ新規サービスを登録する手順を示すフローチャートである。
【００６３】
ステップＳ２３０１は、ゲートウェイ管理装置１００のアプリケーション登録管理部１０１が、サービス事業者のサービス事業者サーバ４０から新規登録するサービスに関する情報、すなわち、サービス事業者名、サービスアプリケーションのプログラム、サービス名、必要ヒープメモリ量、必要メモリ量、必要ＣＰＵ使用率、実測リソース計測の有無に関する情報を受信する処理である。
【００６４】
ステップＳ２３０２は、アプリケーション登録管理部１０１が、該サービスアプリケーションのＩＤを新規に決定する処理である。ＩＤはこれまでにサービス管理テーブル２０００（図２０参照）に記載のサービス名に対応するＩＤとして登録されていない値を選択する。
【００６５】
ステップＳ２３０３は、アプリケーション登録管理部１０１が、サービス管理テーブル２０００にサービス名、サービス事業者名、ステップＳ２３０２で決定したＩＤを追記する処理である。
【００６６】
ステップＳ２３０４は、アプリケーション登録管理部１０１が、必要リソーステーブル５００（図５参照）にＩＤ、必要ヒープメモリ量、必要メモリ量、必要ＣＰＵ使用率を追記する処理である。
【００６７】
サービス事業者から受信した情報に実測リソース計測指定があれば（ステップＳ２３０５，Ｙｅｓ）、ステップＳ２３０６の処理に進む、実測リソース計測指定がなければ（ステップＳ２３０５，Ｎｏ）、処理を終了する。
【００６８】
ステップＳ２３０６は、アプリケーション登録管理部１０１が、実測リソース情報集計管理テーブル２２００（図２２参照）に新規のレコードを作成し、ＩＤを追記し、該当する調査機器数に初期値である０を設定する処理である。
【００６９】
図６は、アプリケーション配布管理部１０２によるゲートウェイ装置２００への新規サービス導入処理Ｓ６００の処理フローを示す図である。図６は、ユーザが選択したサービスがゲートウェイ管理装置１００を介してゲートウェイ装置２００に導入されるまでの手順を示したフローチャートである。以下、図６の説明は、特に言及のない限りアプリケーション配布管理部１０２の処理であり、ステップＳ６０９〜ステップＳ６１１は、ゲートウェイ装置２００の処理である。
【００７０】
サービス利用者は、宅内機器２４０のひとつであるＰＣからゲートウェイ装置２００にアクセスすると、サービスアプリケーション管理画面が表示される。サービスアプリケーション管理画面には、現在すでに導入されているサービスアプリケーションの一覧、かつ、まだ導入されていないサービスアプリケーションの一覧などが表示される。サービスアプリケーションの一覧には、有料であるか無料であるか、有料である場合にも無料のトライアル期間があるか否か、サービス内容がどのようなものであるか否かなどが表示される。サービス利用者は、導入を希望するサービスアプリケーション、例えば、３ヶ月無料のサービスとしてサービス名が「healthcare」（図２０参照）を選択する。
【００７１】
ステップＳ６０１は、アプリケーション配布管理部１０２が、サービス利用者によって新規導入を希望されたサービスアプリケーションのＩＤ（Ａ）を取得する処理である。
【００７２】
ステップＳ６０２は、アプリケーション配布管理部１０２が、ゲートウェイ装置２００から全体利用可能リソーステーブル３００（図３参照）に記載の情報（全体利用可能ＣＰＵ使用率および全体利用可能メモリ量）（Ｂ）、および利用可能リソーステーブル４００（図４参照）に記載のＩＤの一覧（Ｃ）を取得する処理である。
【００７３】
ステップＳ６０３は、アプリケーション配布管理部１０２が、サービスアプリケーションを新規導入するにあたって、アプリケーションの依存関係を確認し、ユーザが新規導入を希望するアプリケーション以外に導入が必要なアプリケーションのＩＤを抽出する処理である、すなわち、新規導入を希望するサービスアプリケーションのＩＤ（Ａ）、すでにゲートウェイ装置２００に導入済みのサービスアプリケーションのＩＤ一覧（Ｃ）、依存関係テーブル８００に記載の情報（Ｄ）を用いて、Ａのサービスアプリケーションを導入する際に追加で必要なサービスアプリケーションがないかを確認し、もしあれば、新規導入希望サービスアプリケーションのＩＤ（Ａ）と該追加で必要なサービスサービスアプリケーションのＩＤを合わせて、ゲートウェイ装置２００へ導入するサービスアプリケーションのＩＤ一覧（Ｅ）を抽出する処理である。
【００７４】
ステップＳ６０４は、アプリケーション配布管理部１０２が、新規導入希望サービスアプリケーションをゲートウェイ装置２００へ導入する場合に必要となるリソースの合計を算出する処理である、すなわち、必要リソーステーブル５００を参照し、ゲートウェイ装置２００に導入済みのＩＤ一覧（Ｃ）に対する必要メモリ量、必要ＣＰＵ使用率の合計（Ｆ）、および新規導入希望のＩＤ一覧（Ｅ）に対する必要メモリ量、必要ＣＰＵ使用率の合計（Ｇ）を算出する処理である。
【００７５】
ステップＳ６０５は、アプリケーション配布管理部１０２が、新規導入希望サービスアプリケーションを導入した場合の必要リソース量の合計と、ゲートウェイ装置２００で利用可能な総リソース量（Ｂ）を比較する処理である、すなわち、新規導入希望サービスアプリケーション導入後に必要となるメモリ量およびＣＰＵ使用率の合計（Ｆ＋Ｇ）と、全体利用可能リソース量（Ｂ）を比較する処理である。
【００７６】
ステップＳ６０６は、アプリケーション配布管理部１０２が、ステップＳ６０５の比較の結果、新規導入希望サービスアプリケーションを導入した場合の必要リソース量がゲートウェイ装置２００で利用可能な総リソース量の範囲内であるかどうかを確認する処理である、すなわち、メモリ量、ＣＰＵ使用率それぞれについてＦ＋Ｇ＜Ｂが成立かどうか調べる処理である。メモリ量、ＣＰＵ使用率それぞれについてＦ＋Ｇ＜Ｂが成立であれば（ステップＳ６０６，Ｙｅｓ）、ステップＳ６０７へ進む。メモリ量、ＣＰＵ使用率それぞれについてＦ＋Ｇ＜Ｂが成立でなければ（ステップＳ６０６，Ｎｏ）、ステップＳ６１２へ進む。
【００７７】
ステップＳ６０７は、アプリケーション配布管理部１０２が、ゲートウェイ装置２００を介してサービス利用者に、新規導入を希望したサービスアプリケーションを導入可能であることを提示する処理である。
【００７８】
ステップＳ６０８は、アプリケーション配布管理部１０２が、ゲートウェイ装置２００へ新規導入サービスアプリケーションおよび関連情報を送信する処理である、すなわち、ゲートウェイ装置２００へ新規導入サービスアプリケーション、該サービスアプリケーション各々の必要メモリ量、必要ＣＰＵ使用率といった必要リソース情報（Ｈ）、該サービスアプリケーション各々の依存関係に関する情報（Ｉ）、および実測リソース情報集計管理テーブル２２００（図２２参照）を参照し、該新規導入サービスアプリケーションのＩＤが含まれていれば該ＩＤが実測リソース情報収集要である旨（Ｊ）を送信する処理である。
【００７９】
ステップＳ６０９は、ゲートウェイ装置２００のアプリケーション管理部２２０における処理である。ゲートウェイ装置２００が、Ｈの情報を利用可能リソーステーブル４００に、Ｉの情報を導入サービスアプリケーション依存関係管理テーブル９００に追記する処理である。
【００８０】
ステップＳ６１０は、ゲートウェイ装置２００のアプリケーション管理部２２０における処理である。ゲートウェイ装置２００が、実測リソース情報収集要である旨（Ｊ）の情報が存在する場合に、実測リソース情報テーブル２１００に新規のレコードを作成し、該当ＩＤを追記し、稼働時間を初期値である０に設定する処理である。
【００８１】
ステップＳ６１１は、ゲートウェイ装置２００のアプリケーション管理部２２０における処理である。ゲートウェイ装置２００が、該サービスアプリケーションを起動する処理である。そして、ステップＳ６１１の処理後、一連の処理は終了する。
【００８２】
ステップＳ６１２は、ゲートウェイ装置２００を介してサービス利用者に、新規導入を希望したサービスアプリケーションの導入が不可であることを提示する処理である。そして、ステップＳ６１２の処理後、一連の処理は終了する。
【００８３】
図６におけるステップＳ６０４において、メモリ使用量として必要メモリ量を用いたが、必要リソーステーブル５００（図５参照）に必要メモリ量の記載がなく、必要ヒープメモリ量のみが記載されている場合などはメモリ使用量として必要ヒープメモリ量を用いてもよい。また、必要ヒープメモリ量はＪａｖａＶＭ自身が利用するメモリ量などを含まないが、ＪａｖａＶＭが利用するであろうメモリ量をある程度見込んで、それをメモリ使用量として利用してもよい。例えば、必要ヒープメモリ量と同量のメモリをＪａｖａＶＭが利用するとして、必要ヒープメモリ量の２倍を必要メモリ量とする、などとしてもよい。
【００８４】
図１１は、新規導入希望サービスを導入可能である画面表示の一例を示す図である。図１１は、図６におけるステップＳ６０７において、ゲートウェイ管理装置１００がゲートウェイ装置２００を介してサービス利用者に提示する情報の画面イメージの一例である。具体的には、画面には、「選択したサービスを実行するのに十分なリソース量があることを確認しました。選択したサービスをゲートウェイ装置に導入します。」が表示される。
【００８５】
図１２は、新規導入希望サービスを導入不可である画面表示の一例を示す図である。図６におけるステップＳ６１２において、ゲートウェイ管理装置１００がサービス利用者に提示する情報の画面イメージの一例である。具体的には、画面には、「選択したサービスを実行するのに十分なリソース量があることを確認できませんでした。選択したサービスをゲートウェイ装置に導入できません。不要なサービスを停止するなどして再度サービス導入処理を行ってください。」が表示される。
【００８６】
図１７は、図６に示した新規サービス導入処理を示す処理フローに対応するシーケンスを示す図である。ステップＳ１７０１は、サービス利用者のＰＣを利用してゲートウェイ装置２００を介してゲートウェイ管理装置１００に接続し、新規導入を希望するサービスアプリケーションを選択する処理である。ステップＳ１７０２は、ゲートウェイ管理装置１００が該サービスアプリケーションのＩＤ（Ａ）を得る処理であり、ステップＳ６０１に対応する。
【００８７】
ステップＳ１７０３は、ゲートウェイ管理装置１００が、ゲートウェイ装置２００に、全体利用可能リソース情報テーブルに記載の情報（Ｂ）および利用可能リソーステーブルに記載のＩＤの一覧（Ｃ）の送信を要求する処理である。
【００８８】
ステップＳ１７０４は、ゲートウェイ装置２００が、ゲートウェイ管理装置１００に、全体利用可能リソース情報テーブルに記載の情報（Ｂ）および利用可能リソーステーブルに記載のＩＤの一覧（Ｃ）を送信する処理であり、ステップＳ６０２に対応する。
【００８９】
ステップＳ１７０５は、ゲートウェイ管理装置１００が、ＡのＩＤとＣのＩＤの一覧と依存関係テーブルに記載の情報（Ｄ）を用いてゲートウェイ装置２００に導入するサービスアプリケーションのＩＤの一覧（Ｅ）を抽出する処理であり、ステップＳ６０３に対応する。
【００９０】
ステップＳ１７０６は、ゲートウェイ管理装置１００が、必要リソーステーブルに記載の必要メモリ量、必要ＣＰＵ使用率のそれぞれについて、ＣのＩＤ一覧に対応する必要メモリ量、必要ＣＰＵ使用率それぞれの合計（Ｆ）と、ＥのＩＤ一覧に対応する必要メモリ量、必要ＣＰＵ使用率それぞれの合計（Ｇ）を抽出する処理であり、ステップＳ６０４に対応する。
【００９１】
ステップＳ１７０７は、ゲートウェイ管理装置１００が、新規サービス導入した場合にゲートウェイ装置２００のメモリ量、ＣＰＵ使用率それぞれについて全体利用可能リソース量を超えないことを確認、すなわち、必要メモリ量、必要ＣＰＵ使用率それぞれについて、Ｆの値とＧの値の和がＢにおける全体利用可能メモリ量、全体利用可能ＣＰＵ使用率の値を超えないかどうかを確認する処理であり、ステップＳ６０５，Ｓ６０６に対応する。
【００９２】
ステップＳ１７０８は、ゲートウェイ管理装置１００が、ゲートウェイ装置２００を介してサービス利用者に、新規導入を希望したサービスアプリケーションを導入可能である事を提示する処理であり、ステップＳ６０７に対応する。
【００９３】
ステップＳ１７０９は、ゲートウェイ管理装置１００が、ゲートウェイ装置２００へ、該新規導入サービスアプリケーションおよび必要リソーステーブル５００の情報のうち該サービスアプリケーションのＩＤに対応する情報（Ｈ）、依存関係テーブル８００の情報のうち該サービスアプリケーションのＩＤに対応する情報（Ｉ）、および実測リソース情報集計管理テーブル２２００（図２２参照）を参照し、該新規導入サービスアプリケーションのＩＤが含まれていれば該ＩＤが実測リソース情報収集要である旨（Ｊ）を送信する処理であり、ステップＳ６０８に対応する。
【００９４】
ステップＳ１７１０は、ゲートウェイ装置２００が、Ｈの情報を利用可能リソーステーブル４００に、Ｉの情報を導入サービスアプリケーション依存関係管理テーブル９００に追記する処理であり、ステップＳ６０９に対応する。
【００９５】
ステップＳ１７１１は、ゲートウェイ装置２００が、実測リソース情報収集要である旨（Ｊ）の情報が存在する場合に、該当ＩＤを実測リソース情報テーブル２１００に追記し、稼働時間を初期値である０に設定し、該サービスアプリケーションを起動する処理であり、ステップＳ６１０に対応する。
【００９６】
図７は、アプリケーション管理部２２０によるサービスアプリケーション起動処理Ｓ７００の処理フローを示す図である。
【００９７】
ステップＳ７０１は、アプリケーション管理部２２０が、利用可能リソーステーブル４００（図４参照）から、起動するサービスアプリケーション２１１のＩＤに対応する利用可能ヒープメモリ量、利用可能メモリ量、利用可能ＣＰＵ使用率を取得する処理である。
【００９８】
ステップＳ７０２は、アプリケーション管理部２２０が、ＣＡＢＩのＡＰＩ（Application Program Interface）を用いて、該利用可能ＣＰＵ使用率の値に関するアカウンティングオブジェクトを生成する処理である。
【００９９】
ステップＳ７０３は、アプリケーション管理部２２０が、ＣＡＢＩ−ＤＭＥＬのＡＰＩを用いて、該利用可能メモリ量の値に関するアカウンティングオブジェクトを生成する処理である。
【０１００】
ステップＳ７０４は、アプリケーション管理部２２０が、ＪａｖａＶＭの起動オプションの最大ヒープ量に該利用可能ヒープメモリ量を設定してＯＳＧｉフレームワーク（アプリケーション実行部２１０）を起動し、該ＯＳＧｉフレームワークに該サービスアプリケーション２１１をインストールおよび実行する処理である。
【０１０１】
ステップＳ７０５は、アプリケーション管理部２２０が、該サービスアプリケーション２１１を実行したソフトウェアプロセスのプロセスＩＤを調査、取得し、該プロセスＩＤをＣＡＢＩおよびＣＡＢＩ−ＤＭＥＬのアカウンティングオブジェクトにバインドする処理である。
【０１０２】
ステップＳ７０６は、アプリケーション管理部２２０が、該サービスアプリケーション２１１のＩＤおよび該プロセスＩＤをプロセスＩＤ管理テーブル１０００（図１０参照）に記憶する処理である。
【０１０３】
ここで、ＣＡＢＩ、ＣＡＢＩ−ＤＭＥＬの動作について簡単に説明する。ＣＡＢＩは周期とＣＰＵ使用時間をパラメータにアカウンティングオブジェクトを作成し、そのアカウンティングオブジェクトに制御したいプロセスをバインドする。例えば、利用可能ＣＰＵ使用率が２０％の場合、周期１００ｍｓ、ＣＰＵ使用時間２０ｍｓなどと記述する。
【０１０４】
通常Ｌｉｎｕｘのような非リアルタイムＯＳにおいては、ＣＰＵに余力がある場合、優先度の低いプロセスであっても多くのＣＰＵ資源（利用時間）を割り当てる。ＣＡＢＩを用いると、ＣＰＵに余力があった場合でもアカウンティングオブジェクトに設定した時間分のＣＰＵ資源を消費したら該プロセスはタスクを開放し、それ以上ＣＰＵ資源を利用しない。ＣＡＢＩを用いた場合において、設定する周期とＣＰＵ使用時間は利用可能な最大値である。設定した時間分のＣＰＵを使用していなくとも、より優先度の高いプロセスから割り込みが発生した場合などは利用時間に達しなくともＣＰＵ資源を解放する。
【０１０５】
ＣＡＢＩ−ＤＭＥＬはアカウンティングオブジェクトに利用可能なメモリ量を設定する。制御したいプロセスをアカウンティングオブジェクトにバインドすると、ＣＡＢＩ−ＤＭＥＬは該プロセスのメモリの確保／開放を監視し、設定したメモリ量を超えるメモリの確保を行おうとするとそれを拒否する。その場合、制御対象のプロセスではメモリ確保に失敗したことになり、場合によってはプロセスそのものが異常終了するような場合もある。ＣＡＢＩやＣＡＢＩ−ＤＭＥＬを用いた場合のログなどはシステムログなどに記録可能であり、アプリケーション管理部から参照可能である。
【０１０６】
図６、図７のように新規サービス導入処理、サービス起動処理を行うことで、ゲートウェイ装置２００上で動作するサービスアプリケーション２１１の使用リソースを適切に制御し、サービスアプリケーション２１１の必要リソース量を確実に確保することが可能となる。
【０１０７】
図６の処理において、サービスアプリケーション２１１の配布可否はゲートウェイ管理装置１００にて判断している（例えば、ステップＳ６０６）が、これはゲートウェイ装置２００で行ってもよい。
【０１０８】
図７のステップＳ７０４の処理において起動されたサービスアプリケーション２１１の動作ログなどをゲートウェイ管理装置１００またはサービス事業者サーバ４０（サービス提供事業者サーバ）へ送信することにより、保守管理に役立てることが可能である。例えば、設定した上限値を超えてリソースを利用しようとしたサービスアプリケーション２１１が存在した場合、そのログをサービス事業者サーバへ送信することによりソフトウェアの品質改良などに役立てることが可能である。
【０１０９】
図２４および図２５は、ゲートウェイ装置２００に導入したサービスアプリケーション２１１を動作した際に実際どの程度のリソース量を使用したか（実測リソース量）を調査する処理である。
【０１１０】
図２４は、ゲートウェイ装置２００における実測リソース量計測処理Ｓ２４００の処理フローを示す図である。実測リソース量計測処理Ｓ２４００は、ゲートウェイ装置２００のアプリケーション管理部２２０によってゲートウェイ装置２００の起動時に開始され、ゲートウェイ装置２００の起動中常にループ処理を行う。図２４に記載の処理の主体は全てアプリケーション管理部２２０である。
【０１１１】
ステップＳ２４０１は、アプリケーション管理部２２０が、実測リソース情報テーブル２１００（図２１参照）から記載のＩＤを全て取得する処理である。
【０１１２】
ステップＳ２４０２は、アプリケーション管理部２２０が、プロセスＩＤ管理テーブル１０００（図１０参照）を参照し、ステップＳ２４０１で取得した各ＩＤに対応するプロセスＩＤを取得する処理である。
【０１１３】
ステップＳ２４０３は、アプリケーション管理部２２０が、各プロセスＩＤに対応するプロセスのヒープメモリ量、メモリ量、ＣＰＵ使用率を取得する処理である。ＯＳの機能、ＪａｖａＶＭの機能などを呼び出して実現することが可能である。
【０１１４】
ステップＳ２４０４は、アプリケーション管理部２２０が、今回のループで取得したリソース量がこれまでに取得したリソース量と比べて大きい（最大値をとる）かどうかを確認し、大きい場合は今回ループで取得したリソース量を実測リソース情報テーブル２１００に記載する処理である、すなわち、実測リソース情報テーブル２１００の各ＩＤに対応する実測ヒープメモリ量、実測メモリ量、実測ＣＰＵ使用率に対し、今回ループで計測したヒープメモリ量、メモリ量、ＣＰＵ使用率が大きければ実測リソース情報テーブル２１００の各値を更新する、また、更新の有無にかかわらず、実測リソース情報テーブル２１００の稼働時間の値にシステムであらかじめ決める当該ループ処理の停止時間（スリープ時間、例えば１０秒、１分、１時間などを設定する）を加える処理である。
【０１１５】
ステップＳ２４０５は、アプリケーション管理部２２０が、十分な期間実測リソース情報を収集した後に、当該情報をゲートウェイ管理装置へ送信する処理である、すなわち、実測リソース情報テーブル２１００の各ＩＤに対し、稼働時間があらかじめシステムで決める実測リソース計測時間（例えば１日間、１週間などを設定する）を超えていれば該ＩＤ行の情報（ＩＤ、実測ヒープメモリ量、実測メモリ量、実測ＣＰＵ使用率）をゲートウェイ管理装置へ送信し、該ＩＤ行を削除する処理である。
【０１１６】
ステップＳ２４０６は、アプリケーション管理部２２０が、あらかじめ決める停止時間（ステップＳ２４０４にて参照した停止時間のこと）スリープする処理である。そして、ステップＳ２４０１に戻る。
【０１１７】
図２５は、ゲートウェイ管理装置１００における実測リソース量集計処理Ｓ２５００の処理フローを示す図である。適宜図１を参照して説明する。ゲートウェイ管理装置１００は、複数のゲートウェイ装置２００から実測リソース量を受信し集計する。図２５に記載の処理の主体は全てアプリケーション配布管理部１０２である。
【０１１８】
アプリケーション配布管理部１０２は、サービス事業者の指定により実測リソース情報収集要とされたサービスアプリケーションの実測リソース情報を、該サービスアプリケーションを配布した多くのゲートウェイ装置２００から収集し、その最大値および平均値を算出して実測リソース情報集計管理テーブル２２００（図２２参照）に記載する。また、アプリケーション配布管理部１０２は、十分な台数のゲートウェイ装置２００から実測リソース情報を収集すると、その結果を、該当サービスアプリケーションを提供するサービス事業者へ送信する。
【０１１９】
ステップＳ２５０１は、アプリケーション配布管理部１０２が、図２４のステップＳ２４０５の処理によって送られた実測リソース情報を受信する処理であり、ステップＳ２５０２は、受信した実測リソース情報に記載のＩＤを読みだす処理である。
【０１２０】
ステップＳ２５０３は、アプリケーション配布管理部１０２が、実測リソース情報集計管理テーブル２２００（図２２参照）の各リソースの最大値を更新する処理、すなわち、受信した実測リソース情報と、実測リソース情報集計管理テーブル２２００の該当ＩＤ行を比較し、受信した実測リソース情報の実測ヒープメモリ量、実測メモリ量、実測ＣＰＵ使用率が、実測リソース情報集計管理テーブル２２００に記載の実測ヒープメモリ量最大値、実測メモリ量最大値、実測ＣＰＵ使用率最大値より大きければ、各最大値を更新する処理である。
【０１２１】
ステップＳ２５０４は、アプリケーション配布管理部１０２が、実測リソース情報集計管理テーブル２２００（図２２参照）の各リソースの平均値を更新する処理である、すなわち、受信した実測リソース情報を基に実測リソース情報集計管理テーブル２２００の該当ＩＤ行の各リソースの平均値を再計算する処理である。例えば、ＩＤが「０１０」のサービスアプリケーションの実測メモリ量平均値については、以下のような計算式で算出することができる。
【０１２２】
（（テーブル２２００の調査機器数×テーブル２２００の実測メモリ量平均値）＋受信した実測リソース情報の実測メモリ量）／（テーブル２２００の調査機器数＋１）
なお、前記計算式中のテーブル名称は、略記している。
【０１２３】
実測ヒープメモリ量、実測ＣＰＵ使用率についても同様の手順で算出することができる。
【０１２４】
ステップＳ２５０５は、アプリケーション配布管理部１０２が、実測リソース情報集計管理テーブル２２００の該当ＩＤ行の調査機器数を＋１（今回受信した機器分追加）する処理である。
【０１２５】
ステップＳ２５０６は、アプリケーション配布管理部１０２が、該当ＩＤのサービスアプリケーションに関して十分な量の実測リソース情報を集計できたかどうかを確認する処理である、すなわち、実測リソース情報集計管理テーブル２２００の該当ＩＤ行の調査機器数があらかじめシステムで決める一定数（例えば１０、１００、１０００など）に到達していれば（ステップＳ２５０６，Ｙｅｓ）、ステップＳ２５０７へと進み、該当ＩＤ行の実測リソース情報集計値をサービス事業者へ送信する。調査機器数があらかじめシステムで決める一定数に到達していなければ（ステップＳ２５０６，Ｎｏ）、処理を終了する。
【０１２６】
ステップＳ２５０７は、アプリケーション配布管理部１０２が、実測リソース情報集計値を送信するサービス事業者に関する情報を取得する処理である、すなわち、サービス管理テーブル２０００から該ＩＤに対応するサービス名とサービス事業者名を読みだす処理である。
【０１２７】
ステップＳ２５０８は、アプリケーション配布管理部１０２が、該当サービス事業者に該サービス名のサービスアプリケーションの実測リソース集計情報として実測リソース情報集計管理テーブル２２００に記載の情報を送信する処理である。
【０１２８】
図２５において、ゲートウェイ管理装置１００のアプリケーション配布管理部１０２は、調査機器数が一定数に達するとサービス事業者に実測リソース集計情報を送信するが、アプリケーション配布管理部１０２がサービス事業者に実測リソース集計情報を送信するタイミングは、例えば、システムであらかじめ決める一定期間（例えば１週間、１カ月など）経過後、サービス事業者からゲートウェイ管理装置に問い合わせがあった際、などでもよい。その場合、実測リソース情報集計管理テーブル２２００の項目や処理などが適宜変更となる。
【０１２９】
図１４、図１５、図１６は、ＣＡＢＩおよびＣＡＢＩ−ＤＭＥＬが利用できない環境における、サービスアプリケーションの起動処理、メモリ使用量監視処理、およびＣＰＵ使用率監視処理を示す図である。
【０１３０】
図１４は、ＣＡＢＩおよびＣＡＢＩ−ＤＭＥＬが利用できない環境における、サービスアプリケーション起動処理Ｓ１４００の処理フローを示す図である。
【０１３１】
ステップＳ１４０１は、アプリケーション管理部２２０が、利用可能リソーステーブル４００（図４参照）から、起動するサービスアプリケーションのＩＤに対応する利用可能ヒープメモリ量を取得する処理である。
【０１３２】
ステップＳ１４０２は、アプリケーション管理部２２０が、ＪａｖａＶＭの起動オプションの最大ヒープ量に該利用可能ヒープメモリ量を設定してＯＳＧｉフレームワーク（アプリケーション実行部）を起動し、該ＯＳＧｉフレームワークに該サービスアプリケーションをインストールおよび実行する処理である。
【０１３３】
ステップＳ１４０３は、アプリケーション管理部２２０が、該サービスアプリケーションを実行したソフトウェアプロセスのプロセスＩＤを調査、取得する。該サービスアプリケーションのＩＤおよび該プロセスＩＤをプロセスＩＤ管理テーブル１０００（図１０参照）に記憶する処理である。
【０１３４】
図１５は、ＣＡＢＩおよびＣＡＢＩ−ＤＭＥＬが利用できない環境における、メモリ使用量監視処理Ｓ１５００の処理フローを示す図である。
【０１３５】
ステップＳ１５０１は、アプリケーション管理部２２０が、プロセスＩＤ管理テーブル１０００（図１０参照）に定期監視を終えていないサービスアプリケーションＩＤが存在かどうか調べる処理である。プロセスＩＤ管理テーブル１０００に定期監視を終えていないサービスアプリケーションＩＤが存在であれば（ステップＳ１５０１，Ｙｅｓ）、ステップＳ１５０２へ進む。あるいは、プロセスＩＤ管理テーブルに定期監視を終えていないサービスアプリケーションＩＤが存在でなければ（ステップＳ１５０１，Ｎｏ）、ステップＳ１５０８へ進む。
【０１３６】
ステップＳ１５０２は、アプリケーション管理部２２０が、プロセスＩＤ管理テーブル１０００から定期監視を終えていないサービスアプリケーションのＩＤ、および該サービスアプリケーションＩＤに対応するプロセスＩＤを取得する処理である。
【０１３７】
ステップＳ１５０３は、アプリケーション管理部２２０が、該プロセスＩＤに対応するプロセスのメモリ使用量を取得する処理である。
【０１３８】
ステップＳ１５０４は、アプリケーション管理部２２０が、メモリ使用量が該サービスアプリケーションＩＤに対応する利用可能メモリ量を超過しているかどうか調べる処理である。メモリ使用量が該サービスアプリケーションＩＤに対応する利用可能メモリ量を超過している場合（ステップＳ１５０４，Ｙｅｓ）、ステップＳ１５０５へ進む。メモリ使用量が該サービスアプリケーションＩＤに対応する利用可能メモリ量を超過していない場合（ステップＳ１５０４，Ｎｏ）、ステップＳ１５０８へ進む。
【０１３９】
ステップＳ１５０５は、アプリケーション管理部２２０が、該サービスアプリケーションＩＤに対応するサービスアプリケーションを強制終了する処理である。
【０１４０】
ステップＳ１５０６は、アプリケーション管理部２２０が、利用可能リソーステーブル４００（図４参照）、導入サービスアプリケーション依存関係管理テーブル９００（図９参照）、プロセスＩＤ管理テーブル１０００（図１０参照）から該サービスアプリケーションＩＤに対応する項目を削除する処理である。
【０１４１】
ステップＳ１５０７は、アプリケーション管理部２２０が、該サービスアプリケーションを利用可能メモリ使用量超過で強制終了した事をシステムログなどに記録する処理である。そして、ステップＳ１５０８は、アプリケーション管理部２２０が、一定時間停止する処理である。その後、ステップＳ１５０１に戻る。
【０１４２】
図１６は、ＣＡＢＩおよびＣＡＢＩ−ＤＭＥＬが利用できない環境における、ＣＰＵ使用率監視処理Ｓ１６００を示す図である。
【０１４３】
ステップＳ１６０１は、アプリケーション管理部２２０が、ゲートウェイ装置２００のＣＰＵのロードアベレージを取得する処理である。なお、ロードアベレージとは、実行待ちプロセス数の平均数を表す値であり、負荷平均のことを意味する。通常、サーバ負荷の指標として使われる。この値が大きければ負荷が大きく、小さければ負荷が小さい。
【０１４４】
ステップＳ１６０２は、アプリケーション管理部２２０が、ロードアベレージ＞１かどうか調べる処理である。ロードアベレージ＞１であれば（ステップＳ１６０２，Ｙｅｓ）、ステップＳ１６０３へ進む。ロードアベレージ＞１でなければ（ステップＳ１６０２，Ｎｏ）、ステップＳ１６０９へ進む。
【０１４５】
ステップＳ１６０３は、アプリケーション管理部２２０が、プロセスＩＤ管理テーブル１０００（図１０参照）に定期監視を終えていないサービスアプリケーションＩＤが存在かどうか調べる処理である。プロセスＩＤ管理テーブル１０００に定期監視を終えていないサービスアプリケーションＩＤが存在であれば（ステップＳ１６０３，Ｙｅｓ）、ステップＳ１６０４へ進む。あるいは、プロセスＩＤ管理テーブル１０００に定期監視を終えていないサービスアプリケーションＩＤが存在でなければ（ステップＳ１６０３，Ｎｏ）、ステップＳ１６０９へ進む。
【０１４６】
ステップＳ１６０４は、アプリケーション管理部２２０が、プロセスＩＤ管理テーブル１０００から定期監視を終えていないサービスアプリケーションのＩＤ、および該サービスアプリケーションＩＤに対応するプロセスＩＤを取得する処理である。
【０１４７】
ステップＳ１６０５は、アプリケーション管理部２２０が、該プロセスＩＤに対応するプロセスのＣＰＵ使用率を取得する処理である。
【０１４８】
ステップＳ１６０６は、アプリケーション管理部２２０が、ＣＰＵ使用率が該サービスアプリケーションＩＤに対応する利用可能ＣＰＵ使用率を超過しているかどうか調べる処理である。ＣＰＵ使用率が該サービスアプリケーションＩＤに対応する利用可能ＣＰＵ使用率を超過している場合（ステップＳ１６０６，Ｙｅｓ）、ステップＳ１６０７へ進む。ＣＰＵ使用率が該サービスアプリケーションＩＤに対応する利用可能ＣＰＵ使用率を超過していない場合（ステップＳ１６０６，Ｎｏ）、ステップＳ１６０９へ進む。
【０１４９】
ステップＳ１６０７は、アプリケーション管理部２２０が、該プロセスＩＤに対応するプロセスのスレッド優先度を下げるする処理である。ステップＳ１６０８は、アプリケーション管理部２２０が、該サービスアプリケーションが利用可能ＣＰＵ使用率を超過した事をシステムログなどに記録する処理である。ステップＳ１６０９は一定時間停止する処理である。その後、ステップＳ１６０１に戻る。
【０１５０】
図１８は、アプリケーション管理部２２０の異常通知処理Ｓ１８００の処理フローを示す図である。図１８は、サービスアプリケーション２１１が利用可能リソース量を超過した際に、ゲートウェイ管理装置１００に異常を通知する手順を示す。
【０１５１】
ステップＳ１８０１は、アプリケーション管理部２２０が、システムログなどから、サービスアプリケーション２１１が利用可能リソース量を超過したかどうかに関する情報を取得する処理である。
【０１５２】
ステップＳ１８０２は、アプリケーション管理部２２０が、利用可能リソース量を超過したサービスアプリケーション有りかどうか調べる処理である。利用可能リソース量を超過したサービスアプリケーションが有りであれば（ステップＳ１８０２，Ｙｅｓ）、ステップＳ１８０３へ進む。利用可能リソース量を超過したサービスアプリケーションが有りでなければ（ステップＳ１８０２，Ｎｏ）、ステップＳ１８０４へ進む。
【０１５３】
ステップＳ１８０３は、アプリケーション管理部２２０が、該サービスアプリケーションのＩＤと利用可能リソース量を超過したかどうかに関する情報をゲートウェイ管理装置１００に送信する処理である。
【０１５４】
ステップＳ１８０４は、アプリケーション管理部２２０が、一定時間、異常通知処理Ｓ１８００を停止する処理である。その後、ステップＳ１８０１に戻る。
【０１５５】
図１９は、アプリケーション管理部２２０の異常通知処理Ｓ１９００の処理フローを示す図である。図１９は、図１８の他の処理フローであり、サービスアプリケーションが利用可能リソース量を超過した際に、ゲートウェイ管理装置１００に異常を通知する手順を示す。
【０１５６】
ステップＳ１９０１は、アプリケーション管理部２２０が、システムログなどから、サービスアプリケーションが利用可能リソース量を超過したかどうかに関する情報を取得する処理である。
【０１５７】
ステップＳ１９０２は、アプリケーション管理部２２０が、利用可能リソース量を超過したサービスアプリケーション有かどうか調べる処理である。利用可能リソース量を超過したサービスアプリケーションが有りであれば（ステップＳ１９０２，Ｙｅｓ）、ステップＳ１９０３へ進む。利用可能リソース量を超過したサービスアプリケーションが有りでなければ（ステップＳ１９０２，Ｎｏ）、ステップＳ１９０５へ進む。
【０１５８】
ステップＳ１９０３は、アプリケーション管理部２２０が、導入サービスアプリケーション依存関係管理テーブル９００（図９参照）を参照し、該サービスアプリケーションのＩＤに対応するＩｍｐｏｒｔ−Ｐａｃｋａｇｅに記載の情報に対するＥｘｐｏｒｔ−Ｐａｃｋａｇｅに記載しているサービスアプリケーションのＩＤの一覧（Ｊ）を取得する処理である。
【０１５９】
ステップＳ１９０４は、アプリケーション管理部２２０が、該サービスアプリケーションのＩＤと、利用可能リソース量を超過したかどうかに関する情報と、Ｊの情報をゲートウェイ管理装置に送信する処理である。
【０１６０】
ステップＳ１９０５は、アプリケーション管理部２２０が、一定時間、異常通知処理Ｓ１９００を停止する処理である。その後、ステップＳ１９０１に戻る。
【０１６１】
本実施形態において、アプリケーションサービス実行基盤を備えたゲートウェイ装置２００に対し、サービス事業者の開発するアプリケーションサービス実行ソフトウェア（アプリケーションソフトウェア）を配布するゲートウェイ管理装置１００は、アプリケーションサービス実行ソフトウェア各々が利用可能なゲートウェイ装置２００のリソース量を管理するテーブルを備え、ゲートウェイ装置２００に新規のソフトウェアを配布する際に、ゲートウェイ装置２００の、アプリケーションサービス実行ソフトウェアが利用可能なリソース量の合計と、既にゲートウェイ装置２００に導入済みのソフトウェアの利用可能なリソース量の合計を取得し、導入済みのソフトウェアの利用可能なリソース量の合計と新規ソフトウェアの利用可能なリソース量との合計と、アプリケーションサービス実行ソフトウェアが利用可能なリソース量の合計を比較し、導入済みのソフトウェアの利用可能なリソース量の合計と新規ソフトウェアの利用可能なリソース量との合計が、アプリケーションサービス実行ソフトウェアが利用可能なリソース量の合計を超えない場合に、新規ソフトウェアの配布を許可する。ゲートウェイ管理装置１００は、サービス事業者の要求にしたがって、ゲートウェイ装置２００からアプリケーション実行ソフトウェアの実測リソース量を収集し、収集した実測リソース量に関する情報をサービス事業者へ提供することができる。
【０１６２】
また、実施形態においては、ゲートウェイ管理装置１００が配布するアプリケーションサービス実行ソフトウェアを実行するゲートウェイ装置２００であって、処理部と、メモリを含む記憶部とを備え、記憶部は、アプリケーションサービス実行ソフトウェアを利用可能なリソース量の合計と、既に導入済みのソフトウェアを利用可能なリソース量の合計を保持し、ゲートウェイ管理装置１００に新規のソフトウェアを要求する際、処理部は、保持するアプリケーションサービス実行ソフトウェアが利用可能なリソース量の合計と、既に導入済みのソフトウェアの利用可能リソース量の合計をゲートウェイ管理装置１００に送信する。ゲートウェイ装置２００は、ゲートウェイ管理装置１００の要求にしたがって、アプリケーション実行ソフトウェアの実測リソース量を計測し、計測した実測リソース量をゲートウェイ管理装置１００に送信することができる。
【０１６３】
さらに、アプリケーションサービス実行基盤を有するゲートウェイ装置２００に対しアプリケーションサービス実行ソフトウェアを配布するゲートウェイ管理装置１００を備えたゲートウェイ管理システムは、アプリケーションサービス実行ソフトウェア各々が利用可能なゲートウェイ装置２００のリソース量を管理し、ゲートウェイ管理装置１００は、ゲートウェイ装置２００に新規のソフトウェアを配布する際に、ゲートウェイ装置２００から、アプリケーションサービス実行ソフトウェアが利用可能なリソース量の合計と、ゲートウェイ装置２００に既に導入済みのソフトウェアの利用可能リソース量の合計を取得し、既に導入済みのソフトウェアの利用可能リソース量の合計と新規ソフトウェアの利用可能リソース量との合計と、アプリケーションサービス実行ソフトウェアが利用可能なリソース量の合計とを比較し、既に導入済みのソフトウェアの利用可能リソース量の合計と新規ソフトウェアの利用可能リソース量との合計が、アプリケーションサービス実行ソフトウェアが利用可能なリソース量の合計を超えない場合に、新規ソフトウェアの配布を許可する。ゲートウェイ管理システムは、サービス事業者の要求にしたがって、ゲートウェイ装置２００からアプリケーション実行ソフトウェアの実測リソース量を収集し、収集した実測リソース量に関する情報をサービス事業者へ提供することができる。
【０１６４】
本実施形態によれば、ゲートウェイ管理装置１００は、サービス事業者が提供した各アプリケーションを管理するサービス管理テーブル２０００、各アプリケーションが実行されたゲートウェイ装置２００の機器数と、各アプリケーションが実行された際に必要なリソース実測値とが関連付けられた実測リソース情報集計管理テーブル２２００を有する記憶部を備え、各ゲートウェイ装置２００から、導入済みの各アプリケーションが実行された際に必要となったリソース実測値を受信した場合、該受信したリソース実測値に基づき実測リソース情報集計管理テーブル２２００を更新し、機器数が所定値に達した場合、サービス管理テーブル２０００に登録されているサービス事業者に、リソース実測値を通知することができる。
【０１６５】
以上述べたように、本実施形態におけるゲートウェイ管理装置１００は、サービス事業者の要請にしたがってサービスアプリケーション２１１をゲートウェイ装置１００に配布した後に、該ゲートウェイ装置２００上でサービスアプリケーションを実行した結果、どの程度のリソース量（ヒープメモリ量、メモリ量、ＣＰＵ使用率）を使用したかを多くのゲートウェイ装置２００から収集、集計した情報をサービス事業者へ提供することを実現する。
【０１６６】
前述のような仕組みを搭載することでサービス事業者は、サービスアプリケーションの開発を、実機を用いずエミュレータなどを用いて行うような場合においても、実測リソース集計情報を得ることが可能となり、サービス事業者がゲートウェイ管理装置に登録する必要リソース量を高い精度で見積もることが可能となる。
【０１６７】
例えば、サービス事業者が設定する必要リソース量に応じて、ゲートウェイ管理装置１００がサービス事業者に課金を行うようなシステムの場合、サービス事業者はサービスアプリケーションが安定的に動作する範囲内においてできるだけ必要リソース量を小さくしたいと考えるが、本実施形態の仕組みを用いる事で必要リソース量をより小さく設定することが可能となると考えられる。
【０１６８】
例えば、サービス事業者が新規サービスを開始する際に、最初はベータテストとして実測リソース量収集要として、必要リソース量はある程度余裕のある大き目の値を設定してゲートウェイ管理装置に登録し、実測リソース集計情報を得て、その結果を基に正式版を、最小限の必要リソース量の設定で登録するというような運用が可能となる。
【符号の説明】
【０１６９】
１１，２１ ＥＰＲＯＭ
１２，２２ ＣＰＵ
１３，２３ メインメモリ
１４，２４ バス
１５，２５ 不揮発性記憶装置
１６，２６ 周辺制御装置
１７，２７，２８ ネットワークＩ／Ｆ
３０ 外部ネットワーク
４０ サービス事業者サーバ
５０ 利用者宅
１００ ゲートウェイ管理装置
１０１ アプリケーション登録管理部
１０２ アプリケーション配布管理部
１０３ ＤＢ管理部
１１０ サービス管理ＤＢ
２００ ゲートウェイ装置
２１０ アプリケーション実行部
２１１ サービスアプリケーション
２２０ アプリケーション管理部
２３０ 利用者宅内ネットワーク
２４０ 宅内機器
２５０ ゲートウェイ管理ＤＢ
３００ 全体利用可能リソーステーブル
４００ 利用可能リソーステーブル
５００ 必要リソーステーブル（リソース管理情報）
８００ 依存関係テーブル
９００ 導入サービスアプリケーション依存関係管理テーブル
１０００ プロセスＩＤ管理テーブル
２０００ サービス管理テーブル（アプリケーション管理情報）
２１００ 実測リソース情報テーブル（実測リソース装置情報）
２２００ 実測リソース情報集計管理テーブル（実測リソース集計管理情報）
【技術分野】
【０００１】
本発明は、ゲートウェイ管理方法、ゲートウェイ管理装置、およびゲートウェイ装置に関し、特に、サービス事業者の要求に応じてサービス事業者の作成するアプリケーションのリソース上限設定に必要な情報を、サービス事業者へ提供可能なゲートウェイ管理方法、ゲートウェイ管理装置、およびゲートウェイ装置に関する。
【背景技術】
【０００２】
従来、ＡＤＳＬ（Asymmetric Digital Subscriber Line）、ＣＡＴＶ（Community Antenna TeleVision）、ＦＴＴＨ（Fiber To The Home）といったＷＡＮ（Wide Area Network）とホームネットワークなどのＬＡＮ（Local Area Network）を接続するゲートウェイ装置は、音声（ＩＰ(Internet Protocol)電話など）、映像（放送、ＶｏＤ（(Video on Demand）など）、データ通信（インターネット接続など）といったいわゆるトリプルプレイサービスを提供してきた。
【０００３】
近年では、前記トリプルプレイサービスに加え、ホームネットワークに接続する様々な機器を制御するアプリケーションのインストールおよび管理を行うことにより、機能を動的に拡張できる手段が提案されている（例えば、特許文献１参照）。
【０００４】
特許文献１におけるホームネットワークシステムは、各種ホームネットワークミドルウェアを統合支援するＯＳＧｉ（Open Services Gateway Initiative）フレームワークを搭載したゲートウェイ装置などのアプリケーションサーバを導入し、種々のデバイスへアクセスするためのミドルウェアサービスをバンドル機能として提供することにより、ミドルウェアに制約されないホームネットワークシステムを実現する。
【０００５】
しかしながら、特許文献１に記載のＯＳＧｉフレームワークには様々なソフトウェア部品（ＯＳＧｉバンドルと呼ぶ）を単一のソフトウェアプロセス上で動作するフレームワーク上で動作させることから、個別のＯＳＧｉバンドルがどの程度のＣＰＵ、メモリなどのリソースを消費するかを詳細に知ることができないという問題がある。
【０００６】
この問題に対し、個別のバンドルのリソース消費量を複数のゲートウェイでの平均消費量として求める手段（例えば、特許文献２参照）や、サービス事業者ごとに別々のＯＳＧｉフレームワークのソフトウェアプロセスを生成し、サービス事業者ごとに使用メモリ（Ｊａｖａ（登録商標）のヒープメモリ）にあらかじめ決めておいた上限値を設定することで円滑なサービス運用を実現する手段（例えば、特許文献３参照）が開示されている。
【０００７】
特許文献２は、複数のゲートウェイがもつリソースの消費量についての解析結果を得る管理システムの動作方法であって、前記ゲートウェイのそれぞれから、該ゲートウェイで検出された消費量を示す消費量情報と、検出のときに当該ゲートウェイで実行されていたプログラムを示す実行プログラムリストとを取得し、平均消費量を含むレコードを作成する管理システムの動作方法が開示されている。
【０００８】
特許文献３には、サービス事業者ごとに利用可能なメモリの上限を管理し、アプリケーション起動時にＪａｖａ（登録商標）の起動オプションにてヒープの上限値に設定することで設定値以上のメモリを該アプリケーションが利用できないようにする方法が開示されている。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】特開２００４−２１３６１２号公報（第３図）
【特許文献２】特開２００７−３１６９４７号公報（第１図）
【特許文献３】特開２００８−１５９５４号公報（第１図）
【発明の概要】
【発明が解決しようとする課題】
【００１０】
前記特許文献２、特許文献３に示される方法には次のような問題がある。まず、特許文献２に示される方法では、複数のプログラムが消費するリソースと実行プログラムリストを複数のゲートウェイ装置から収集することで各々のプログラムが消費するリソースの平均消費量を求める方法が開示されているが、あくまでも平均消費量であり、各々のゲートウェイ装置において、各々のプログラムが、実際にどのようにリソースを消費したのかを示す消費リソース量の実測値を得る方法については言及がない。すなわち、消費リソース量の実測値を基にして、厳密なリソース管理を行う方法については開示されていない。
【００１１】
また、特許文献３に示される方法では、アプリケーションの利用可能なメモリの上限について、どのように決定をするかについての言及がない。すなわち、サービス事業者とゲートウェイ装置やＯＳＧｉフレームワークなどのアプリケーション基盤を提供するプラットフォーム事業者との責任分界点を考えると、サービス事業者が提供するアプリケーションの利用可能なメモリの上限については、サービス事業者が自ら必要なメモリ使用量を上限値としてプラットフォーム事業者に申告、設定することが自然であると考えられる。しかし、例えば、サービス事業者がゲートウェイ装置の実機を持たずゲートウェイ装置のエミュレータを用いてアプリケーション開発を行うような場合には必要なメモリ上限について精度の高い申告、設定を行うことが困難となる可能性がある。
【００１２】
本発明は、前記の課題を解決するための発明であって、サービス事業者の要求に応じて、ゲートウェイ装置からサービス事業者の作成するアプリケーションソフトウェアの実行に必要なリソース実測値を収集し、該リソース実測値をサービス事業者へ提供可能とする、ゲートウェイ管理方法、ゲートウェイ管理装置、およびゲートウェイ装置を提供することを目的とする。
【課題を解決するための手段】
【００１３】
前記目的を達成するため、本発明のゲートウェイ管理方法は、サービス事業者がゲートウェイ装置に対して提供するアプリケーションソフトウェアであるアプリケーションを管理するとともに、ゲートウェイ装置においてアプリケーションを実行した際に必要となるリソース実測値をサービス事業者に通知するゲートウェイ管理装置のゲートウェイ管理方法であって、ゲートウェイ管理装置は、サービス事業者がサービス事業者サーバから提供した各アプリケーションを、該サービス事業者と関連付けて管理するアプリケーション管理情報（例えば、サービス管理テーブル２０００）を有するとともに、各アプリケーションが実行されたゲートウェイ装置の機器数と、各アプリケーションが実行された際に必要なリソース実測値とが関連付けられた実測リソース集計管理情報（例えば、実測リソース情報集計管理テーブル２２００）を有する記憶部（例えば、サービス管理ＤＢ１１０）を備え、ゲートウェイ管理装置は、各ゲートウェイ装置から、導入済みの各アプリケーションが実行された際に必要となったリソース実測値を受信し、該受信したリソース実測値に基づき実測リソース集計管理情報を更新し（例えば、ステップＳ２５０４）、アプリケーション管理情報に登録されているアプリケーションの機器数が所定値に達しているか判定し、所定値に達したアプリケーションについてアプリケーション管理情報に登録されているサービス事業者に、リソース実測値を通知する（例えば、ステップＳ２５０８）ことを特徴とする。
【発明の効果】
【００１４】
本発明によれば、サービス事業者の要求に応じて、ゲートウェイ装置からサービス事業者の作成するアプリケーションソフトウェアの実行に必要なリソース実測値を収集し、該リソース実測値をサービス事業者へ提供可能とすることができる。
【図面の簡単な説明】
【００１５】
【図１】本実施形態における機能構成およびネットワーク構成の一例を示す図である。
【図２】本実施形態におけるゲートウェイ管理装置およびゲートウェイ装置のハードウェア構成の一例を示す図である。
【図３】ゲートウェイ装置の全体利用可能リソーステーブルを示す図である。
【図４】ゲートウェイ装置の利用可能リソーステーブルを示す図である。
【図５】ゲートウェイ管理装置の必要リソーステーブルを示す図である。
【図６】アプリケーション配布管理部によるゲートウェイ装置への新規サービス導入処理の処理フローを示す図である。
【図７】アプリケーション管理部によるサービスアプリケーションの起動処理の処理フローを示す図である。
【図８】ゲートウェイ管理装置の依存関係テーブルを示す図である。
【図９】ゲートウェイ装置の導入サービスアプリケーション依存関係管理テーブルを示す図である。
【図１０】ゲートウェイ装置のプロセスＩＤ管理テーブルを示す図である。
【図１１】新規導入希望サービスを導入可能である画面表示の一例を示す図である。
【図１２】新規導入希望サービスを導入不可である画面表示の一例を示す図である。
【図１３】本実施形態における機能構成の一例を示す図である。
【図１４】ＣＡＢＩおよびＣＡＢＩ−ＤＭＥＬが利用できない環境における、サービスアプリケーションの起動処理の処理フローを示す図である。
【図１５】ＣＡＢＩおよびＣＡＢＩ−ＤＭＥＬが利用できない環境における、サービスアプリケーションのメモリ使用量監視処理の処理フローを示す図である。
【図１６】ＣＡＢＩおよびＣＡＢＩ−ＤＭＥＬが利用できない環境における、サービスアプリケーションのＣＰＵ使用率監視処理の処理フローを示す図である。
【図１７】図６に示した新規サービス導入処理を示す処理フローに対応するシーケンスを示す図である。
【図１８】アプリケーション管理部の異常通知処理の処理フローを示す図である。
【図１９】アプリケーション管理部の異常通知処理の他の処理フローを示す図である
【図２０】ゲートウェイ管理装置のサービス管理テーブルを示す図である。
【図２１】ゲートウェイ装置の実測リソース情報テーブルを示す図である。
【図２２】ゲートウェイ管理装置の実測リソース情報集計管理テーブルを示す図である。
【図２３】アプリケーション登録管理部によるゲートウェイ管理装置への新規サービス登録処理の処理フローを示す図である。
【図２４】ゲートウェイ装置における実測リソース量計測処理の処理フローを示す図である。
【図２５】ゲートウェイ管理装置における実測リソース量集計処理の処理フローを示す図である。
【発明を実施するための形態】
【００１６】
本発明の実施形態について、図面を参照して詳細に説明する。
図１は、本実施形態における機能構成およびネットワーク構成の一例を示す図である。ゲートウェイ管理システムは、ゲートウェイ管理装置１００、複数の利用者宅５０内のゲートウェイ装置２００、複数のサービス事業者サーバ４０とを含んで構成されている。利用者宅５０内において、ゲートウェイ装置２００は、利用者宅内ネットワーク２３０を介して複数の宅内機器２４０に接続されている。
【００１７】
ゲートウェイ管理装置１００、サービス事業者サーバ４０、およびゲートウェイ装置２００は、フレッツ（登録商標）などの閉域網、または、インターネットからなる外部ネットワーク３０と接続しており、所定の手順に従って情報のやり取りを行うことができる。
【００１８】
ゲートウェイ装置２００と宅内機器２４０は、利用者宅５０内に設置され、有線または無線から構成される利用者宅内ネットワーク２３０と接続しており、所定の手順に従って情報のやり取りを行うことができる。
【００１９】
ゲートウェイ装置２００は、外部ネットワーク３０と利用者宅内ネットワーク２３０の両方と接続しており、利用者宅５０に設置された機器にとって、外部ネットワーク３０に接続された機器と情報のやり取りをするためのゲートウェイとしての機能を有する。
【００２０】
ゲートウェイ管理装置１００は、処理部として、サービス事業者サーバ４０から依頼を受けてゲートウェイ管理装置１００への新規サービスの登録処理Ｓ２３００（図２３参照）を行うアプリケーション登録管理部１０１と、ゲートウェイ装置２００へ新規サービス導入処理Ｓ６００（図６参照）、ゲートウェイ装置２００から受信した実測リソース量集計処理Ｓ２５００（図２５参照）などを行うアプリケーション配布管理部１０２と、ＤＢ管理部１０３とを有する。なお、ＤＢはData Baseの略である。
【００２１】
また、ゲートウェイ管理装置１００は、サービス管理ＤＢ１１０を有し、サービス管理ＤＢ１１０には、サービス管理テーブル２０００（アプリケーション管理情報）（図２０参照）、実測リソース情報集計管理テーブル２２００（実測リソース集計管理情報）（図２２参照）、必要リソーステーブル５００（リソース管理情報）（図５参照）、依存関係テーブル８００（図８参照）が格納されている。
【００２２】
ゲートウェイ装置２００は、処理部として、サービスアプリケーション２１１を実行するアプリケーション実行部２１０、サービスアプリケーション２１１の状況を管理するアプリケーション管理部２２０とを有している。
【００２３】
アプリケーション管理部２２０は、サービスアプリケーション起動処理Ｓ７００（図７参照）、サービスアプリケーション起動処理Ｓ１４００（図１４参照）、メモリ使用量監視処理Ｓ１５００（図１５参照）、メモリ使用量監視処理Ｓ１６００（図１６参照）、異常通知処理Ｓ１８００（図１８参照）、異常通知処理Ｓ１９００（図１９参照）、実測リソース量計測処理Ｓ２４００（図２４参照）などの処理を行う機能を有している。
【００２４】
また、ゲートウェイ装置２００は、ゲートウェイ管理ＤＢ２５０を有し、ゲートウェイ管理ＤＢ２５０には、実測リソース情報テーブル２１００（実測リソース装置情報）（図２１参照）、全体利用可能リソーステーブル３００（図３参照）、利用可能リソーステーブル４００（図４参照）、導入サービスアプリケーション依存関係管理テーブル９００（図９参照）、およびプロセスＩＤ管理テーブル１０００（図１０参照）が格納されている。
【００２５】
図２は、ゲートウェイ管理装置１００およびゲートウェイ装置２００のハードウェア構成の一例を示す図である。ゲートウェイ管理装置１００は、ＥＰＲＯＭ１１、ＣＰＵ１２、メインメモリ１３、バス１４、不揮発性記憶装置１５、周辺制御装置１６、ネットワークＩ／Ｆ１７を有している。ＥＰＲＯＭ１１、ＣＰＵ１２、メインメモリ１３、周辺制御装置１６はバス１４と接続し、不揮発性記憶装置１５、ネットワークＩ／Ｆ１７は周辺制御装置１６を介してバス１４と接続しており、所定の手順に従って情報のやり取りを行うことができる。なお、ＥＰＲＯＭはErasable Programmable Read Only Memoryの略であり、ＣＰＵはCentral Processing Unitの略であり、Ｉ／ＦはInterfaceの略である。
【００２６】
ゲートウェイ装置２００は、ＥＰＲＯＭ２１、ＣＰＵ２２、メインメモリ２３、バス２４、不揮発性記憶装置２５、周辺制御装置２６、ネットワークＩ／Ｆ２７、ネットワークＩ／Ｆ２８を有している。ＥＰＲＯＭ２１、ＣＰＵ２２、メインメモリ２３、周辺制御装置２６はバス２４と接続し、ネットワークＩ／Ｆ２７、ネットワークＩ／Ｆ２８、不揮発性記憶装置２５は周辺制御装置２６を介してバス２４と接続しており、所定の手順に従って情報のやり取りを行うことができる。
【００２７】
ゲートウェイ管理装置１００において、ＥＰＲＯＭ１１にはブートプログラムが格納されている。また、不揮発性記憶装置１５には各種プログラムが記憶されている。ゲートウェイ管理装置１００が起動するとＥＰＲＯＭ１１に格納されたブートプログラムによって不揮発性記憶装置１５から各種プログラムがメインメモリ１３へと読み出される。ＣＰＵ１２はメインメモリ１３に読み出された各種プログラムを実行することにより、ネットワークＩ／Ｆ１７への信号の送受信を行う。
【００２８】
ネットワークＩ／Ｆ１７は外部ネットワーク３０と接続しており、外部ネットワーク３０に接続する機器との間で情報のやり取りを行うことができる。ネットワークＩ／Ｆ１７はネットワークカードなどにより実現することができる。
【００２９】
不揮発性記憶装置１５には、前述のようにＣＰＵ１２がメインメモリ１３に読み出して実行するための各種プログラムが記憶されており、フラッシュメモリやＨＤＤ（ハードディスクドライブ）により実現することができる。
【００３０】
ゲートウェイ装置２００において、ＥＰＲＯＭ２１にはブートプログラムが格納されている。また、不揮発性記憶装置２５には各種プログラムが記憶されている。ゲートウェイ装置２００が起動するとＥＰＲＯＭ２１に格納されたブートプログラムによって不揮発性記憶装置２５から各種プログラムがメインメモリ２３へと読み出される。ＣＰＵ２２はメインメモリ２３に読み出された各種プログラムを実行することにより、ネットワークＩ／Ｆ２７やネットワークＩ／Ｆ２８への信号の送受信を行う。
【００３１】
ネットワークＩ／Ｆ２７は、外部ネットワーク３０と接続しており、外部ネットワーク３０に接続する機器との間で情報のやり取りを行うことができる。ネットワークＩ／Ｆ２７はネットワークカードなどにより実現することができる。
【００３２】
ネットワークＩ／Ｆ２８は、利用者宅５０内のネットワーク２３０と接続しており、利用者宅内ネットワーク２３０に接続する機器との間で情報のやり取りを行うことができる。ネットワークＩ／Ｆ２８はネットワークカードなどにより実現することができる。
【００３３】
不揮発性記憶装置２５には、前述のようにＣＰＵ２２がメインメモリ２３に読み出して実行するための各種プログラムが記憶されており、フラッシュメモリやＨＤＤ（ハードディスクドライブ）により実現することができる。図示しないが、サービス事業者サーバ４０のハードウェア構成は、通常のＰＣ（Personal Computer）と同様である。
【００３４】
次に、本実施形態において、ゲートウェイ管理装置１００、ゲートウェイ装置２００が扱う各テーブルについて説明する。
【００３５】
図３は、ゲートウェイ装置２００の全体利用可能リソーステーブル３００を示す図である。全体利用可能リソーステーブル３００は、アプリケーションサービス全体が利用可能なリソース量を示すテーブルである。全体利用可能リソーステーブル３００には、全体利用可能ＣＰＵ使用率３０１、全体利用可能メモリ量３０２といった項目がある。具体的には、行３０３には、全体利用可能ＣＰＵ使用率は５０％であり、全体利用可能メモリ量は３０ＭＢであることがわかる。
【００３６】
図４は、ゲートウェイ装置２００の利用可能リソーステーブル４００を示す図である。利用可能リソーステーブル４００は、個別のアプリケーションサービスが利用可能なリソースを管理するテーブルである。利用可能リソーステーブル４００には、ＩＤ４０１、利用可能ヒープメモリ量４０２、利用可能メモリ量４０３、利用可能ＣＰＵ使用率４０４といった項目がある。具体的には、行４０５のＩＤが「０００」の場合、利用可能ヒープメモリ量は６ＭＢ、利用可能メモリ量１５ＭＢ、利用可能ＣＰＵ使用率は２０％である。行４０６のＩＤが「００３」の場合、利用可能ヒープメモリ量は３ＭＢ、利用可能メモリ量６ＭＢ、利用可能ＣＰＵ使用率は１０％である。
【００３７】
図５は、ゲートウェイ管理装置１００の必要リソーステーブル５００を示す図である。必要リソーステーブル５００は、ゲートウェイ管理装置１００が管理する個別のアプリケーションサービスが利用可能なリソースを管理するテーブルである。必要リソーステーブル５００には、ＩＤ４０１、必要ヒープメモリ量５０２、必要メモリ量５０３、必要ＣＰＵ使用率５０４といった項目がある。具体的には、複数のサービス事業者サーバ４０が提供しているサービスアプリケーション２１１の必要リソースとして、行５０６のＩＤが「００１」の場合、必要ヒープメモリ量は１ＭＢ、必要メモリ量は２ＭＢ、必要ＣＰＵ使用率は１０％である。また、行５０７のＩＤが「００２」の場合は、必要ヒープメモリ量は４ＭＢ、必要メモリ量は１０ＭＢ、必要ＣＰＵ使用率は３０％である。
【００３８】
さらに、行５０５のＩＤが「０００」は図４で示した行４０５の「０００」に対応し、行５０８のＩＤが「００３」は図４で示した行４０６の「００３」に対応し、および行５０９のＩＤが「０１０」は図４に示した行４０７の「０１０」に対応している。
【００３９】
図８は、ゲートウェイ管理装置１００の依存関係テーブル８００を示す図である。依存関係テーブル８００は、サービスアプリケーション間の依存関係を管理するテーブルである。依存関係テーブル８００には、ＩＤ４０１、Import-Package８０２、Export-Package８０３といった項目がある。
【００４０】
Import-Package８０２は、ＩＤ４０１に指定されているバンドルの利用に必要なパッケージ、言い換えると、このバンドルが依存しているパッケージを示す。行８０４の例ではImport-Packageがorg.osgi.frameworkとしており、org.osgi.frameworkというパッケージに依存することを意味する。Export-Package８０３は、他のバンドルに公開されるパッケージを示す。行８０４では、Export-Packageがorg.osgi.service.httpとしており、org.osgi.service.httpというパッケージをバンドル外に公開している。逆にExport-Package８０３に宣言されていないパッケージは、他のバンドルからアクセスができないことを意味する。
【００４１】
図９は、ゲートウェイ装置２００の導入サービスアプリケーション依存関係管理テーブル９００を示す図である。導入サービスアプリケーション依存関係管理テーブル９００は、ゲートウェイ装置２００に導入したサービスアプリケーション間の依存関係を管理するテーブルである。導入サービスアプリケーション依存関係管理テーブル９００には、ＩＤ４０１、Import-Package９０２、Export-Package９０３といった項目がある。
【００４２】
図１０は、ゲートウェイ装置２００のプロセスＩＤ管理テーブル１０００を示す図である。プロセスＩＤ管理テーブル１０００は、サービスアプリケーション２１１に対応するプロセスＩＤを管理するテーブルである。プロセスＩＤ管理テーブル１０００には、ＩＤ４０１、プロセスＩＤ１００２といった項目がある。
【００４３】
図２０は、ゲートウェイ管理装置１００のサービス管理テーブル２０００を示す図である。サービス管理テーブル２０００（アプリケーション管理情報）は、サービス名と、サービス事業者名およびサービスＩＤとの対応を管理するテーブルである。サービス管理テーブル２０００には、サービス名２００１、サービス事業者名２００２、ＩＤ４０１といった項目がある。具体的には、サービス名が「home control」は、「家操作(株)」のサービス事業者が提供しているサービスであり、サービス名が「healthcare」は、「(株)健康Ｎｏ.１」のサービス事業者が提供しているサービスである。
【００４４】
図２１は、ゲートウェイ装置２００の実測リソース情報テーブル２１００を示す図である。実測リソース情報テーブル２１００（実測リソース装置情報）は、ＩＤ４０１に対応する実測リソース情報を管理するテーブルである。実測リソース情報テーブル２１００には、ＩＤ４０１、実測ヒープメモリ量２１０１、実測メモリ量２１０２、実測ＣＰＵ使用率２１０３、稼働時間２１０４といった項目がある。
【００４５】
図２２は、ゲートウェイ管理装置１００の実測リソース情報集計管理テーブル２２００を示す図である。実測リソース情報集計管理テーブル２２００（実測リソース集計管理情報）は、ＩＤ４０１に対応する調査機器数の実測リソース情報集計管理テーブルである。実測リソース情報集計管理テーブル２２００には、ＩＤ４０１、調査機器数２２０１、実測ヒープメモリ量最大値２２０２、実測ヒープメモリ量平均値２２０３、実測メモリ量最大値２２０４、実測メモリ量平均値２２０５、実測ＣＰＵ使用率最大値２２０６、実測ＣＰＵ使用率平均値２２０７といった項目がある。具体的には、行２２０８を参照すると、ＩＤが「０１０」の場合、調査機器数は１５であり、各リソースの最大値および平均値が集計されている。例えば、実測ヒープメモリ量の最大値は０．５ＭＢであり、実測ヒープメモリ量の平均値は０．３５ＭＢである。このことから、図２０、図２２を参照すると、ＩＤが「０１０」のサービス名が「home comtrol」を運用する際の、精度の高い各リソースの最大値および平均値を得ることができる。
【００４６】
次に本実施形態の各装置の処理部の動作について、適宜図１を参照して説明する。
ゲートウェイ管理装置１００は、様々なサービス事業者サーバ４０を保持するサービス事業者が提供するサービスアプリケーションを、ゲートウェイ装置２００へ外部ネットワーク３０を介して配布するサービスサービスアプリケーション配布基盤としての機能を有している。サービス事業者サーバ４０を保持するサービス事業者は、作成したサービスアプリケーション２１１の配布をゲートウェイ管理装置１００へ委託することにより、サービスアプリケーション配布サーバなどを自身で設置すること、アプリケーション実行部２１０を備えたゲートウェイ装置２００などを自ら利用者へ配布することの必要がなくなり、コストを抑えてサービス提供を行うことが可能となる。
【００４７】
ゲートウェイ装置２００は、様々なサービスアプリケーション２１１を実行するアプリケーション実行部２１０を備える。アプリケーション実行部２１０は、例えば、ＯＳＧｉ（登録商標）フレームワークのようなアプリケーション実行基盤を用いて実現することができ、ゲートウェイ管理装置１００が配布するサービスアプリケーション２１１を実行することにより、様々な宅内機器２４０を、利用者宅内ネットワーク２３０を介して制御可能とするなど、ゲートウェイ装置２００の機能を柔軟に拡張することを可能とする。
【００４８】
アプリケーション実行部２１０としてＯＳＧｉフレームワークを用いる場合、通常ＯＳＧｉフレームワークは、単一のフレームワーク上で複数のサービスアプリケーション２１１を実行することが可能であるが、本実施形態では、サービスアプリケーション２１１のそれぞれが、利用するゲートウェイ装置２００のＣＰＵ処理時間（ＣＰＵ使用率）や利用メモリ量といったリソースを詳細に制御するために、サービスアプリケーション２１１ごとに別個にアプリケーション実行部２１０を起動することを想定する。
【００４９】
ＯＳＧｉフレームワークのようなアプリケーション実行基盤は、様々なサービスアプリケーション２１１間でお互いの機能を適切に呼び合うことを可能とする。例えば、ＯＳＧｉサービスプラットフォーム仕様が標準で規定するＨＴＴＰサービスはＷＥＢサーバおよびサーブレットコンテナの機能を有し、サーブレットとして実装された他のサービスアプリケーション２１１は、ＨＴＴＰサービスが提供するサーブレットコンテナ機能に自身を登録することにより、サービスアプリケーション２１１を提供するサービス事業者は、簡単にＷＥＢサーバおよびサーブレットコンテナの機能を利用することができる。
【００５０】
アプリケーション実行部２１０をサービスアプリケーション２１１ごとに起動した場合、通常前記のようなサービスアプリケーション２１１間の連携機能は使用できなくなってしまうが、ＯＳＧｉサービスプラットフォーム仕様Ｒ４．２にはＨＴＴＰサービスと同様の標準サービスとしてリモートサービスの仕様が追加されている。リモートサービスはＯＳＧｉの核となるサービスのＩｍｐｏｒｔ／Ｅｘｐｏｒｔ機能を異なるＪａｖａ（登録商標）ＶＭ上で動作するＯＳＧｉフレームワークと共有することを可能とする。
【００５１】
本実施形態においては、特にことわりのない限り、アプリケーション実行部２１０はＯＳＧｉフレームワークを用いて実現され、アプリケーション実行部２１０は、様々なサービスアプリケーション２１１ごとにアプリケーション管理部２２０によって異なるＪａｖａＶＭ（異なるソフトウェアプロセス）上で実行され、起動した複数のアプリケーション実行部２１０間はＯＳＧｉサービスプラットフォームの標準サービスである、リモートサービスを用いて互いに連携可能であることを想定する。
【００５２】
また、本実施形態においては、サービスアプリケーション２１１は、１つまたは複数のプログラム（ソフトウェア部品、ＯＳＧｉバンドルと言う）からなる。本実施形態においては、１つのアプリケーション実行部２１０では、１つのサービスアプリケーション２１１が動作することを想定する。ただし、１つのアプリケーション実行部２１０で複数のサービスアプリケーション２１１を実行することも可能である。例えば、サービスアプリケーション２１１の提供事業者ごとに同一のアプリケーション実行部を利用するということも可能である。
【００５３】
本実施形態において、ＣＰＵ使用率、メモリ使用量といったリソースの管理を行うことができるのはアプリケーション実行部２１０ごとである。例えば、前記のように、サービスアプリケーション２１１の提供事業者ごとに同一のアプリケーション実行部２１０を利用する場合、利用可能なリソース量を超過した場合には該サービスアプリケーション提供事業者の提供するサービスアプリケーション２１１のいずれかに問題があるであろう、ということまで分かる。
【００５４】
１つのアプリケーション実行部２１０で複数のサービスアプリケーション２１１を実行すると、ゲートウェイ装置全体におけるアプリケーション実行部２１０を実現するプログラム（ＪａｖａＶＭやＯＳＧｉフレームワークなど）の実行数が減少し、その分機器全体でのメモリ使用量などを節約することができるという効果があるが、本実施形態では説明を簡便にするために１つのアプリケーション実行部では１つのサービスアプリが動作することを想定する。
【００５５】
また、本実施形態におけるゲートウェイ装置２００は、アプリケーション実行部２１０の実行されるソフトウェアプロセスそれぞれのＣＰＵ使用率、メモリ使用量、Ｊａｖａのヒープメモリ使用量の上限値を適切に制御可能な構成を想定する。
【００５６】
例えば、ゲートウェイ装置２００のＯＳ（基本ソフト）がＬｉｎｕｘ（登録商標）である場合、ソフトウェアプロセスのＣＰＵ使用率はＣＡＢＩ（CPU Accounting and Blocking Interface）のようなＣＰＵリソースマネジメントシステムを用いて制御が可能である。ＣＡＢＩはある周期におけるＣＰＵ使用時間の上限値を設定することが可能で、例えば、あるソフトウェアプロセスに対し、周期が１００ｍｓ、ＣＰＵ使用時間の上限値が３０ｍｓといったＣＡＢＩのＡＯ（アカウンティングオブジェクト）を設定した場合、１００ｍｓの間に３０ｍｓの時間においてＣＰＵを利用すると、３０ｍｓ後のＣＰＵの利用をブロックされ、ＣＰＵリソースが他のプロセスへと開放される。本実施形態においては、特にことわりのない限り、ゲートウェイ装置２００のＯＳはＬｉｎｕｘであり、ＣＰＵリソースマネジメントにはＣＡＢＩを用いることを想定するが、例えばその他のリアルタイムＯＳなどにおいても同様の仕組みを用いて実現が可能な場合がある。
【００５７】
また、例えば、ゲートウェイ装置２００のＯＳ（基本ソフト）がＬｉｎｕｘである場合、ソフトウェアプロセスのメモリ使用量はＣＡＢＩ−ＤＭＥＬ（Common resource management Accounting and Blocking Interfaces - Dependable Memory management system for Embedded Linux）のようなメモリリソースマネジメントシステムを用いて制御が可能である。ＣＡＢＩ−ＤＭＥＬはあるソフトウェアプロセスに対する物理メモリの割り当ての上限制限をすることが可能であり、上限値以上のメモリを確保しようとした場合にメモリ割り当てをブロックすることができる。本実施形態においては、特にことわりのない限り、ゲートウェイ装置２００のＯＳはＬｉｎｕｘであり、メモリリソースマネジメントにはＣＡＢＩ−ＤＭＥＬを用いることを想定するが、例えばその他のＯＳなどにおいても同様の仕組みを用いて実現が可能な場合がある。
【００５８】
また、本実施形態ではアプリケーション実行部２１０は、ＯＳＧｉフレームワークを用いて実現されることを想定するが、ＯＳＧｉフレームワークはＪａｖａＶＭ（Java Virtual Machine）を用いて起動される。ＪａｖａＶＭは実行するプログラムの利用可能なヒープメモリの上限を指定することが可能であり、設定した上限値以上のヒープメモリの利用をブロックすることができる。
【００５９】
図１３は、本実施形態における機能構成の一例を示す図である。図１３は、アプリケーション実行部２１０を実現するプログラムとしてＪａｖａＶＭ、ＯＳＧｉフレームワーク（OSGi Framework）、ＯＳＧｉの標準サービスであるリモートサービスバンドルを用いた場合のゲートウェイ装置２００の機能構成図である。
【００６０】
サービスアプリケーション２１１を実行するごとにＪａｖａＶＭとＯＳＧｉフレームワークが起動し、各ＯＳＧｉフレームワーク上でリモートサービスバンドルが動作し、それぞれのアプリケーション実行部２１０ａ，２１０ｂ，２１０ｃのＯＳＧｉフレームワーク上において各サービスアプリケーション２１１が動作している。
【００６１】
ＯＳＧｉは通常、同一のＪａｖａＶＭ上で動作するＯＳＧｉフレームワーク上で動作するプログラム（バンドル）間においてお互いの機能（サービス）を呼び合うことができるが、リモートサービスを用いると異なるＪａｖａＶＭ上で動作するＯＳＧｉフレームワーク間で機能（サービス）の情報をやり取りすることができ、リモートサービスが導入されたＯＳＧｉフレームワーク上で実行されるサービスアプリケーション２１１は異なるアプリケーション実行部で動作するサービスアプリケーション２１１の機能（サービス）を利用することが可能となる。また、各アプリケーション実行部２１０ａ，２１０ｂ，２１０ｃの起動処理などの管理はアプリケーション管理部２２０が行う。
【００６２】
図２３は、アプリケーション登録管理部１０１によるゲートウェイ管理装置１００への新規サービス登録処理Ｓ２３００の処理フローを示す図である。図２３は、ゲートウェイ管理装置１００のアプリケーション登録管理部１０１が、サービス事業者のサービス事業者サーバ４０から受信する情報を基にゲートウェイ管理装置１００へ新規サービスを登録する手順を示すフローチャートである。
【００６３】
ステップＳ２３０１は、ゲートウェイ管理装置１００のアプリケーション登録管理部１０１が、サービス事業者のサービス事業者サーバ４０から新規登録するサービスに関する情報、すなわち、サービス事業者名、サービスアプリケーションのプログラム、サービス名、必要ヒープメモリ量、必要メモリ量、必要ＣＰＵ使用率、実測リソース計測の有無に関する情報を受信する処理である。
【００６４】
ステップＳ２３０２は、アプリケーション登録管理部１０１が、該サービスアプリケーションのＩＤを新規に決定する処理である。ＩＤはこれまでにサービス管理テーブル２０００（図２０参照）に記載のサービス名に対応するＩＤとして登録されていない値を選択する。
【００６５】
ステップＳ２３０３は、アプリケーション登録管理部１０１が、サービス管理テーブル２０００にサービス名、サービス事業者名、ステップＳ２３０２で決定したＩＤを追記する処理である。
【００６６】
ステップＳ２３０４は、アプリケーション登録管理部１０１が、必要リソーステーブル５００（図５参照）にＩＤ、必要ヒープメモリ量、必要メモリ量、必要ＣＰＵ使用率を追記する処理である。
【００６７】
サービス事業者から受信した情報に実測リソース計測指定があれば（ステップＳ２３０５，Ｙｅｓ）、ステップＳ２３０６の処理に進む、実測リソース計測指定がなければ（ステップＳ２３０５，Ｎｏ）、処理を終了する。
【００６８】
ステップＳ２３０６は、アプリケーション登録管理部１０１が、実測リソース情報集計管理テーブル２２００（図２２参照）に新規のレコードを作成し、ＩＤを追記し、該当する調査機器数に初期値である０を設定する処理である。
【００６９】
図６は、アプリケーション配布管理部１０２によるゲートウェイ装置２００への新規サービス導入処理Ｓ６００の処理フローを示す図である。図６は、ユーザが選択したサービスがゲートウェイ管理装置１００を介してゲートウェイ装置２００に導入されるまでの手順を示したフローチャートである。以下、図６の説明は、特に言及のない限りアプリケーション配布管理部１０２の処理であり、ステップＳ６０９〜ステップＳ６１１は、ゲートウェイ装置２００の処理である。
【００７０】
サービス利用者は、宅内機器２４０のひとつであるＰＣからゲートウェイ装置２００にアクセスすると、サービスアプリケーション管理画面が表示される。サービスアプリケーション管理画面には、現在すでに導入されているサービスアプリケーションの一覧、かつ、まだ導入されていないサービスアプリケーションの一覧などが表示される。サービスアプリケーションの一覧には、有料であるか無料であるか、有料である場合にも無料のトライアル期間があるか否か、サービス内容がどのようなものであるか否かなどが表示される。サービス利用者は、導入を希望するサービスアプリケーション、例えば、３ヶ月無料のサービスとしてサービス名が「healthcare」（図２０参照）を選択する。
【００７１】
ステップＳ６０１は、アプリケーション配布管理部１０２が、サービス利用者によって新規導入を希望されたサービスアプリケーションのＩＤ（Ａ）を取得する処理である。
【００７２】
ステップＳ６０２は、アプリケーション配布管理部１０２が、ゲートウェイ装置２００から全体利用可能リソーステーブル３００（図３参照）に記載の情報（全体利用可能ＣＰＵ使用率および全体利用可能メモリ量）（Ｂ）、および利用可能リソーステーブル４００（図４参照）に記載のＩＤの一覧（Ｃ）を取得する処理である。
【００７３】
ステップＳ６０３は、アプリケーション配布管理部１０２が、サービスアプリケーションを新規導入するにあたって、アプリケーションの依存関係を確認し、ユーザが新規導入を希望するアプリケーション以外に導入が必要なアプリケーションのＩＤを抽出する処理である、すなわち、新規導入を希望するサービスアプリケーションのＩＤ（Ａ）、すでにゲートウェイ装置２００に導入済みのサービスアプリケーションのＩＤ一覧（Ｃ）、依存関係テーブル８００に記載の情報（Ｄ）を用いて、Ａのサービスアプリケーションを導入する際に追加で必要なサービスアプリケーションがないかを確認し、もしあれば、新規導入希望サービスアプリケーションのＩＤ（Ａ）と該追加で必要なサービスサービスアプリケーションのＩＤを合わせて、ゲートウェイ装置２００へ導入するサービスアプリケーションのＩＤ一覧（Ｅ）を抽出する処理である。
【００７４】
ステップＳ６０４は、アプリケーション配布管理部１０２が、新規導入希望サービスアプリケーションをゲートウェイ装置２００へ導入する場合に必要となるリソースの合計を算出する処理である、すなわち、必要リソーステーブル５００を参照し、ゲートウェイ装置２００に導入済みのＩＤ一覧（Ｃ）に対する必要メモリ量、必要ＣＰＵ使用率の合計（Ｆ）、および新規導入希望のＩＤ一覧（Ｅ）に対する必要メモリ量、必要ＣＰＵ使用率の合計（Ｇ）を算出する処理である。
【００７５】
ステップＳ６０５は、アプリケーション配布管理部１０２が、新規導入希望サービスアプリケーションを導入した場合の必要リソース量の合計と、ゲートウェイ装置２００で利用可能な総リソース量（Ｂ）を比較する処理である、すなわち、新規導入希望サービスアプリケーション導入後に必要となるメモリ量およびＣＰＵ使用率の合計（Ｆ＋Ｇ）と、全体利用可能リソース量（Ｂ）を比較する処理である。
【００７６】
ステップＳ６０６は、アプリケーション配布管理部１０２が、ステップＳ６０５の比較の結果、新規導入希望サービスアプリケーションを導入した場合の必要リソース量がゲートウェイ装置２００で利用可能な総リソース量の範囲内であるかどうかを確認する処理である、すなわち、メモリ量、ＣＰＵ使用率それぞれについてＦ＋Ｇ＜Ｂが成立かどうか調べる処理である。メモリ量、ＣＰＵ使用率それぞれについてＦ＋Ｇ＜Ｂが成立であれば（ステップＳ６０６，Ｙｅｓ）、ステップＳ６０７へ進む。メモリ量、ＣＰＵ使用率それぞれについてＦ＋Ｇ＜Ｂが成立でなければ（ステップＳ６０６，Ｎｏ）、ステップＳ６１２へ進む。
【００７７】
ステップＳ６０７は、アプリケーション配布管理部１０２が、ゲートウェイ装置２００を介してサービス利用者に、新規導入を希望したサービスアプリケーションを導入可能であることを提示する処理である。
【００７８】
ステップＳ６０８は、アプリケーション配布管理部１０２が、ゲートウェイ装置２００へ新規導入サービスアプリケーションおよび関連情報を送信する処理である、すなわち、ゲートウェイ装置２００へ新規導入サービスアプリケーション、該サービスアプリケーション各々の必要メモリ量、必要ＣＰＵ使用率といった必要リソース情報（Ｈ）、該サービスアプリケーション各々の依存関係に関する情報（Ｉ）、および実測リソース情報集計管理テーブル２２００（図２２参照）を参照し、該新規導入サービスアプリケーションのＩＤが含まれていれば該ＩＤが実測リソース情報収集要である旨（Ｊ）を送信する処理である。
【００７９】
ステップＳ６０９は、ゲートウェイ装置２００のアプリケーション管理部２２０における処理である。ゲートウェイ装置２００が、Ｈの情報を利用可能リソーステーブル４００に、Ｉの情報を導入サービスアプリケーション依存関係管理テーブル９００に追記する処理である。
【００８０】
ステップＳ６１０は、ゲートウェイ装置２００のアプリケーション管理部２２０における処理である。ゲートウェイ装置２００が、実測リソース情報収集要である旨（Ｊ）の情報が存在する場合に、実測リソース情報テーブル２１００に新規のレコードを作成し、該当ＩＤを追記し、稼働時間を初期値である０に設定する処理である。
【００８１】
ステップＳ６１１は、ゲートウェイ装置２００のアプリケーション管理部２２０における処理である。ゲートウェイ装置２００が、該サービスアプリケーションを起動する処理である。そして、ステップＳ６１１の処理後、一連の処理は終了する。
【００８２】
ステップＳ６１２は、ゲートウェイ装置２００を介してサービス利用者に、新規導入を希望したサービスアプリケーションの導入が不可であることを提示する処理である。そして、ステップＳ６１２の処理後、一連の処理は終了する。
【００８３】
図６におけるステップＳ６０４において、メモリ使用量として必要メモリ量を用いたが、必要リソーステーブル５００（図５参照）に必要メモリ量の記載がなく、必要ヒープメモリ量のみが記載されている場合などはメモリ使用量として必要ヒープメモリ量を用いてもよい。また、必要ヒープメモリ量はＪａｖａＶＭ自身が利用するメモリ量などを含まないが、ＪａｖａＶＭが利用するであろうメモリ量をある程度見込んで、それをメモリ使用量として利用してもよい。例えば、必要ヒープメモリ量と同量のメモリをＪａｖａＶＭが利用するとして、必要ヒープメモリ量の２倍を必要メモリ量とする、などとしてもよい。
【００８４】
図１１は、新規導入希望サービスを導入可能である画面表示の一例を示す図である。図１１は、図６におけるステップＳ６０７において、ゲートウェイ管理装置１００がゲートウェイ装置２００を介してサービス利用者に提示する情報の画面イメージの一例である。具体的には、画面には、「選択したサービスを実行するのに十分なリソース量があることを確認しました。選択したサービスをゲートウェイ装置に導入します。」が表示される。
【００８５】
図１２は、新規導入希望サービスを導入不可である画面表示の一例を示す図である。図６におけるステップＳ６１２において、ゲートウェイ管理装置１００がサービス利用者に提示する情報の画面イメージの一例である。具体的には、画面には、「選択したサービスを実行するのに十分なリソース量があることを確認できませんでした。選択したサービスをゲートウェイ装置に導入できません。不要なサービスを停止するなどして再度サービス導入処理を行ってください。」が表示される。
【００８６】
図１７は、図６に示した新規サービス導入処理を示す処理フローに対応するシーケンスを示す図である。ステップＳ１７０１は、サービス利用者のＰＣを利用してゲートウェイ装置２００を介してゲートウェイ管理装置１００に接続し、新規導入を希望するサービスアプリケーションを選択する処理である。ステップＳ１７０２は、ゲートウェイ管理装置１００が該サービスアプリケーションのＩＤ（Ａ）を得る処理であり、ステップＳ６０１に対応する。
【００８７】
ステップＳ１７０３は、ゲートウェイ管理装置１００が、ゲートウェイ装置２００に、全体利用可能リソース情報テーブルに記載の情報（Ｂ）および利用可能リソーステーブルに記載のＩＤの一覧（Ｃ）の送信を要求する処理である。
【００８８】
ステップＳ１７０４は、ゲートウェイ装置２００が、ゲートウェイ管理装置１００に、全体利用可能リソース情報テーブルに記載の情報（Ｂ）および利用可能リソーステーブルに記載のＩＤの一覧（Ｃ）を送信する処理であり、ステップＳ６０２に対応する。
【００８９】
ステップＳ１７０５は、ゲートウェイ管理装置１００が、ＡのＩＤとＣのＩＤの一覧と依存関係テーブルに記載の情報（Ｄ）を用いてゲートウェイ装置２００に導入するサービスアプリケーションのＩＤの一覧（Ｅ）を抽出する処理であり、ステップＳ６０３に対応する。
【００９０】
ステップＳ１７０６は、ゲートウェイ管理装置１００が、必要リソーステーブルに記載の必要メモリ量、必要ＣＰＵ使用率のそれぞれについて、ＣのＩＤ一覧に対応する必要メモリ量、必要ＣＰＵ使用率それぞれの合計（Ｆ）と、ＥのＩＤ一覧に対応する必要メモリ量、必要ＣＰＵ使用率それぞれの合計（Ｇ）を抽出する処理であり、ステップＳ６０４に対応する。
【００９１】
ステップＳ１７０７は、ゲートウェイ管理装置１００が、新規サービス導入した場合にゲートウェイ装置２００のメモリ量、ＣＰＵ使用率それぞれについて全体利用可能リソース量を超えないことを確認、すなわち、必要メモリ量、必要ＣＰＵ使用率それぞれについて、Ｆの値とＧの値の和がＢにおける全体利用可能メモリ量、全体利用可能ＣＰＵ使用率の値を超えないかどうかを確認する処理であり、ステップＳ６０５，Ｓ６０６に対応する。
【００９２】
ステップＳ１７０８は、ゲートウェイ管理装置１００が、ゲートウェイ装置２００を介してサービス利用者に、新規導入を希望したサービスアプリケーションを導入可能である事を提示する処理であり、ステップＳ６０７に対応する。
【００９３】
ステップＳ１７０９は、ゲートウェイ管理装置１００が、ゲートウェイ装置２００へ、該新規導入サービスアプリケーションおよび必要リソーステーブル５００の情報のうち該サービスアプリケーションのＩＤに対応する情報（Ｈ）、依存関係テーブル８００の情報のうち該サービスアプリケーションのＩＤに対応する情報（Ｉ）、および実測リソース情報集計管理テーブル２２００（図２２参照）を参照し、該新規導入サービスアプリケーションのＩＤが含まれていれば該ＩＤが実測リソース情報収集要である旨（Ｊ）を送信する処理であり、ステップＳ６０８に対応する。
【００９４】
ステップＳ１７１０は、ゲートウェイ装置２００が、Ｈの情報を利用可能リソーステーブル４００に、Ｉの情報を導入サービスアプリケーション依存関係管理テーブル９００に追記する処理であり、ステップＳ６０９に対応する。
【００９５】
ステップＳ１７１１は、ゲートウェイ装置２００が、実測リソース情報収集要である旨（Ｊ）の情報が存在する場合に、該当ＩＤを実測リソース情報テーブル２１００に追記し、稼働時間を初期値である０に設定し、該サービスアプリケーションを起動する処理であり、ステップＳ６１０に対応する。
【００９６】
図７は、アプリケーション管理部２２０によるサービスアプリケーション起動処理Ｓ７００の処理フローを示す図である。
【００９７】
ステップＳ７０１は、アプリケーション管理部２２０が、利用可能リソーステーブル４００（図４参照）から、起動するサービスアプリケーション２１１のＩＤに対応する利用可能ヒープメモリ量、利用可能メモリ量、利用可能ＣＰＵ使用率を取得する処理である。
【００９８】
ステップＳ７０２は、アプリケーション管理部２２０が、ＣＡＢＩのＡＰＩ（Application Program Interface）を用いて、該利用可能ＣＰＵ使用率の値に関するアカウンティングオブジェクトを生成する処理である。
【００９９】
ステップＳ７０３は、アプリケーション管理部２２０が、ＣＡＢＩ−ＤＭＥＬのＡＰＩを用いて、該利用可能メモリ量の値に関するアカウンティングオブジェクトを生成する処理である。
【０１００】
ステップＳ７０４は、アプリケーション管理部２２０が、ＪａｖａＶＭの起動オプションの最大ヒープ量に該利用可能ヒープメモリ量を設定してＯＳＧｉフレームワーク（アプリケーション実行部２１０）を起動し、該ＯＳＧｉフレームワークに該サービスアプリケーション２１１をインストールおよび実行する処理である。
【０１０１】
ステップＳ７０５は、アプリケーション管理部２２０が、該サービスアプリケーション２１１を実行したソフトウェアプロセスのプロセスＩＤを調査、取得し、該プロセスＩＤをＣＡＢＩおよびＣＡＢＩ−ＤＭＥＬのアカウンティングオブジェクトにバインドする処理である。
【０１０２】
ステップＳ７０６は、アプリケーション管理部２２０が、該サービスアプリケーション２１１のＩＤおよび該プロセスＩＤをプロセスＩＤ管理テーブル１０００（図１０参照）に記憶する処理である。
【０１０３】
ここで、ＣＡＢＩ、ＣＡＢＩ−ＤＭＥＬの動作について簡単に説明する。ＣＡＢＩは周期とＣＰＵ使用時間をパラメータにアカウンティングオブジェクトを作成し、そのアカウンティングオブジェクトに制御したいプロセスをバインドする。例えば、利用可能ＣＰＵ使用率が２０％の場合、周期１００ｍｓ、ＣＰＵ使用時間２０ｍｓなどと記述する。
【０１０４】
通常Ｌｉｎｕｘのような非リアルタイムＯＳにおいては、ＣＰＵに余力がある場合、優先度の低いプロセスであっても多くのＣＰＵ資源（利用時間）を割り当てる。ＣＡＢＩを用いると、ＣＰＵに余力があった場合でもアカウンティングオブジェクトに設定した時間分のＣＰＵ資源を消費したら該プロセスはタスクを開放し、それ以上ＣＰＵ資源を利用しない。ＣＡＢＩを用いた場合において、設定する周期とＣＰＵ使用時間は利用可能な最大値である。設定した時間分のＣＰＵを使用していなくとも、より優先度の高いプロセスから割り込みが発生した場合などは利用時間に達しなくともＣＰＵ資源を解放する。
【０１０５】
ＣＡＢＩ−ＤＭＥＬはアカウンティングオブジェクトに利用可能なメモリ量を設定する。制御したいプロセスをアカウンティングオブジェクトにバインドすると、ＣＡＢＩ−ＤＭＥＬは該プロセスのメモリの確保／開放を監視し、設定したメモリ量を超えるメモリの確保を行おうとするとそれを拒否する。その場合、制御対象のプロセスではメモリ確保に失敗したことになり、場合によってはプロセスそのものが異常終了するような場合もある。ＣＡＢＩやＣＡＢＩ−ＤＭＥＬを用いた場合のログなどはシステムログなどに記録可能であり、アプリケーション管理部から参照可能である。
【０１０６】
図６、図７のように新規サービス導入処理、サービス起動処理を行うことで、ゲートウェイ装置２００上で動作するサービスアプリケーション２１１の使用リソースを適切に制御し、サービスアプリケーション２１１の必要リソース量を確実に確保することが可能となる。
【０１０７】
図６の処理において、サービスアプリケーション２１１の配布可否はゲートウェイ管理装置１００にて判断している（例えば、ステップＳ６０６）が、これはゲートウェイ装置２００で行ってもよい。
【０１０８】
図７のステップＳ７０４の処理において起動されたサービスアプリケーション２１１の動作ログなどをゲートウェイ管理装置１００またはサービス事業者サーバ４０（サービス提供事業者サーバ）へ送信することにより、保守管理に役立てることが可能である。例えば、設定した上限値を超えてリソースを利用しようとしたサービスアプリケーション２１１が存在した場合、そのログをサービス事業者サーバへ送信することによりソフトウェアの品質改良などに役立てることが可能である。
【０１０９】
図２４および図２５は、ゲートウェイ装置２００に導入したサービスアプリケーション２１１を動作した際に実際どの程度のリソース量を使用したか（実測リソース量）を調査する処理である。
【０１１０】
図２４は、ゲートウェイ装置２００における実測リソース量計測処理Ｓ２４００の処理フローを示す図である。実測リソース量計測処理Ｓ２４００は、ゲートウェイ装置２００のアプリケーション管理部２２０によってゲートウェイ装置２００の起動時に開始され、ゲートウェイ装置２００の起動中常にループ処理を行う。図２４に記載の処理の主体は全てアプリケーション管理部２２０である。
【０１１１】
ステップＳ２４０１は、アプリケーション管理部２２０が、実測リソース情報テーブル２１００（図２１参照）から記載のＩＤを全て取得する処理である。
【０１１２】
ステップＳ２４０２は、アプリケーション管理部２２０が、プロセスＩＤ管理テーブル１０００（図１０参照）を参照し、ステップＳ２４０１で取得した各ＩＤに対応するプロセスＩＤを取得する処理である。
【０１１３】
ステップＳ２４０３は、アプリケーション管理部２２０が、各プロセスＩＤに対応するプロセスのヒープメモリ量、メモリ量、ＣＰＵ使用率を取得する処理である。ＯＳの機能、ＪａｖａＶＭの機能などを呼び出して実現することが可能である。
【０１１４】
ステップＳ２４０４は、アプリケーション管理部２２０が、今回のループで取得したリソース量がこれまでに取得したリソース量と比べて大きい（最大値をとる）かどうかを確認し、大きい場合は今回ループで取得したリソース量を実測リソース情報テーブル２１００に記載する処理である、すなわち、実測リソース情報テーブル２１００の各ＩＤに対応する実測ヒープメモリ量、実測メモリ量、実測ＣＰＵ使用率に対し、今回ループで計測したヒープメモリ量、メモリ量、ＣＰＵ使用率が大きければ実測リソース情報テーブル２１００の各値を更新する、また、更新の有無にかかわらず、実測リソース情報テーブル２１００の稼働時間の値にシステムであらかじめ決める当該ループ処理の停止時間（スリープ時間、例えば１０秒、１分、１時間などを設定する）を加える処理である。
【０１１５】
ステップＳ２４０５は、アプリケーション管理部２２０が、十分な期間実測リソース情報を収集した後に、当該情報をゲートウェイ管理装置へ送信する処理である、すなわち、実測リソース情報テーブル２１００の各ＩＤに対し、稼働時間があらかじめシステムで決める実測リソース計測時間（例えば１日間、１週間などを設定する）を超えていれば該ＩＤ行の情報（ＩＤ、実測ヒープメモリ量、実測メモリ量、実測ＣＰＵ使用率）をゲートウェイ管理装置へ送信し、該ＩＤ行を削除する処理である。
【０１１６】
ステップＳ２４０６は、アプリケーション管理部２２０が、あらかじめ決める停止時間（ステップＳ２４０４にて参照した停止時間のこと）スリープする処理である。そして、ステップＳ２４０１に戻る。
【０１１７】
図２５は、ゲートウェイ管理装置１００における実測リソース量集計処理Ｓ２５００の処理フローを示す図である。適宜図１を参照して説明する。ゲートウェイ管理装置１００は、複数のゲートウェイ装置２００から実測リソース量を受信し集計する。図２５に記載の処理の主体は全てアプリケーション配布管理部１０２である。
【０１１８】
アプリケーション配布管理部１０２は、サービス事業者の指定により実測リソース情報収集要とされたサービスアプリケーションの実測リソース情報を、該サービスアプリケーションを配布した多くのゲートウェイ装置２００から収集し、その最大値および平均値を算出して実測リソース情報集計管理テーブル２２００（図２２参照）に記載する。また、アプリケーション配布管理部１０２は、十分な台数のゲートウェイ装置２００から実測リソース情報を収集すると、その結果を、該当サービスアプリケーションを提供するサービス事業者へ送信する。
【０１１９】
ステップＳ２５０１は、アプリケーション配布管理部１０２が、図２４のステップＳ２４０５の処理によって送られた実測リソース情報を受信する処理であり、ステップＳ２５０２は、受信した実測リソース情報に記載のＩＤを読みだす処理である。
【０１２０】
ステップＳ２５０３は、アプリケーション配布管理部１０２が、実測リソース情報集計管理テーブル２２００（図２２参照）の各リソースの最大値を更新する処理、すなわち、受信した実測リソース情報と、実測リソース情報集計管理テーブル２２００の該当ＩＤ行を比較し、受信した実測リソース情報の実測ヒープメモリ量、実測メモリ量、実測ＣＰＵ使用率が、実測リソース情報集計管理テーブル２２００に記載の実測ヒープメモリ量最大値、実測メモリ量最大値、実測ＣＰＵ使用率最大値より大きければ、各最大値を更新する処理である。
【０１２１】
ステップＳ２５０４は、アプリケーション配布管理部１０２が、実測リソース情報集計管理テーブル２２００（図２２参照）の各リソースの平均値を更新する処理である、すなわち、受信した実測リソース情報を基に実測リソース情報集計管理テーブル２２００の該当ＩＤ行の各リソースの平均値を再計算する処理である。例えば、ＩＤが「０１０」のサービスアプリケーションの実測メモリ量平均値については、以下のような計算式で算出することができる。
【０１２２】
（（テーブル２２００の調査機器数×テーブル２２００の実測メモリ量平均値）＋受信した実測リソース情報の実測メモリ量）／（テーブル２２００の調査機器数＋１）
なお、前記計算式中のテーブル名称は、略記している。
【０１２３】
実測ヒープメモリ量、実測ＣＰＵ使用率についても同様の手順で算出することができる。
【０１２４】
ステップＳ２５０５は、アプリケーション配布管理部１０２が、実測リソース情報集計管理テーブル２２００の該当ＩＤ行の調査機器数を＋１（今回受信した機器分追加）する処理である。
【０１２５】
ステップＳ２５０６は、アプリケーション配布管理部１０２が、該当ＩＤのサービスアプリケーションに関して十分な量の実測リソース情報を集計できたかどうかを確認する処理である、すなわち、実測リソース情報集計管理テーブル２２００の該当ＩＤ行の調査機器数があらかじめシステムで決める一定数（例えば１０、１００、１０００など）に到達していれば（ステップＳ２５０６，Ｙｅｓ）、ステップＳ２５０７へと進み、該当ＩＤ行の実測リソース情報集計値をサービス事業者へ送信する。調査機器数があらかじめシステムで決める一定数に到達していなければ（ステップＳ２５０６，Ｎｏ）、処理を終了する。
【０１２６】
ステップＳ２５０７は、アプリケーション配布管理部１０２が、実測リソース情報集計値を送信するサービス事業者に関する情報を取得する処理である、すなわち、サービス管理テーブル２０００から該ＩＤに対応するサービス名とサービス事業者名を読みだす処理である。
【０１２７】
ステップＳ２５０８は、アプリケーション配布管理部１０２が、該当サービス事業者に該サービス名のサービスアプリケーションの実測リソース集計情報として実測リソース情報集計管理テーブル２２００に記載の情報を送信する処理である。
【０１２８】
図２５において、ゲートウェイ管理装置１００のアプリケーション配布管理部１０２は、調査機器数が一定数に達するとサービス事業者に実測リソース集計情報を送信するが、アプリケーション配布管理部１０２がサービス事業者に実測リソース集計情報を送信するタイミングは、例えば、システムであらかじめ決める一定期間（例えば１週間、１カ月など）経過後、サービス事業者からゲートウェイ管理装置に問い合わせがあった際、などでもよい。その場合、実測リソース情報集計管理テーブル２２００の項目や処理などが適宜変更となる。
【０１２９】
図１４、図１５、図１６は、ＣＡＢＩおよびＣＡＢＩ−ＤＭＥＬが利用できない環境における、サービスアプリケーションの起動処理、メモリ使用量監視処理、およびＣＰＵ使用率監視処理を示す図である。
【０１３０】
図１４は、ＣＡＢＩおよびＣＡＢＩ−ＤＭＥＬが利用できない環境における、サービスアプリケーション起動処理Ｓ１４００の処理フローを示す図である。
【０１３１】
ステップＳ１４０１は、アプリケーション管理部２２０が、利用可能リソーステーブル４００（図４参照）から、起動するサービスアプリケーションのＩＤに対応する利用可能ヒープメモリ量を取得する処理である。
【０１３２】
ステップＳ１４０２は、アプリケーション管理部２２０が、ＪａｖａＶＭの起動オプションの最大ヒープ量に該利用可能ヒープメモリ量を設定してＯＳＧｉフレームワーク（アプリケーション実行部）を起動し、該ＯＳＧｉフレームワークに該サービスアプリケーションをインストールおよび実行する処理である。
【０１３３】
ステップＳ１４０３は、アプリケーション管理部２２０が、該サービスアプリケーションを実行したソフトウェアプロセスのプロセスＩＤを調査、取得する。該サービスアプリケーションのＩＤおよび該プロセスＩＤをプロセスＩＤ管理テーブル１０００（図１０参照）に記憶する処理である。
【０１３４】
図１５は、ＣＡＢＩおよびＣＡＢＩ−ＤＭＥＬが利用できない環境における、メモリ使用量監視処理Ｓ１５００の処理フローを示す図である。
【０１３５】
ステップＳ１５０１は、アプリケーション管理部２２０が、プロセスＩＤ管理テーブル１０００（図１０参照）に定期監視を終えていないサービスアプリケーションＩＤが存在かどうか調べる処理である。プロセスＩＤ管理テーブル１０００に定期監視を終えていないサービスアプリケーションＩＤが存在であれば（ステップＳ１５０１，Ｙｅｓ）、ステップＳ１５０２へ進む。あるいは、プロセスＩＤ管理テーブルに定期監視を終えていないサービスアプリケーションＩＤが存在でなければ（ステップＳ１５０１，Ｎｏ）、ステップＳ１５０８へ進む。
【０１３６】
ステップＳ１５０２は、アプリケーション管理部２２０が、プロセスＩＤ管理テーブル１０００から定期監視を終えていないサービスアプリケーションのＩＤ、および該サービスアプリケーションＩＤに対応するプロセスＩＤを取得する処理である。
【０１３７】
ステップＳ１５０３は、アプリケーション管理部２２０が、該プロセスＩＤに対応するプロセスのメモリ使用量を取得する処理である。
【０１３８】
ステップＳ１５０４は、アプリケーション管理部２２０が、メモリ使用量が該サービスアプリケーションＩＤに対応する利用可能メモリ量を超過しているかどうか調べる処理である。メモリ使用量が該サービスアプリケーションＩＤに対応する利用可能メモリ量を超過している場合（ステップＳ１５０４，Ｙｅｓ）、ステップＳ１５０５へ進む。メモリ使用量が該サービスアプリケーションＩＤに対応する利用可能メモリ量を超過していない場合（ステップＳ１５０４，Ｎｏ）、ステップＳ１５０８へ進む。
【０１３９】
ステップＳ１５０５は、アプリケーション管理部２２０が、該サービスアプリケーションＩＤに対応するサービスアプリケーションを強制終了する処理である。
【０１４０】
ステップＳ１５０６は、アプリケーション管理部２２０が、利用可能リソーステーブル４００（図４参照）、導入サービスアプリケーション依存関係管理テーブル９００（図９参照）、プロセスＩＤ管理テーブル１０００（図１０参照）から該サービスアプリケーションＩＤに対応する項目を削除する処理である。
【０１４１】
ステップＳ１５０７は、アプリケーション管理部２２０が、該サービスアプリケーションを利用可能メモリ使用量超過で強制終了した事をシステムログなどに記録する処理である。そして、ステップＳ１５０８は、アプリケーション管理部２２０が、一定時間停止する処理である。その後、ステップＳ１５０１に戻る。
【０１４２】
図１６は、ＣＡＢＩおよびＣＡＢＩ−ＤＭＥＬが利用できない環境における、ＣＰＵ使用率監視処理Ｓ１６００を示す図である。
【０１４３】
ステップＳ１６０１は、アプリケーション管理部２２０が、ゲートウェイ装置２００のＣＰＵのロードアベレージを取得する処理である。なお、ロードアベレージとは、実行待ちプロセス数の平均数を表す値であり、負荷平均のことを意味する。通常、サーバ負荷の指標として使われる。この値が大きければ負荷が大きく、小さければ負荷が小さい。
【０１４４】
ステップＳ１６０２は、アプリケーション管理部２２０が、ロードアベレージ＞１かどうか調べる処理である。ロードアベレージ＞１であれば（ステップＳ１６０２，Ｙｅｓ）、ステップＳ１６０３へ進む。ロードアベレージ＞１でなければ（ステップＳ１６０２，Ｎｏ）、ステップＳ１６０９へ進む。
【０１４５】
ステップＳ１６０３は、アプリケーション管理部２２０が、プロセスＩＤ管理テーブル１０００（図１０参照）に定期監視を終えていないサービスアプリケーションＩＤが存在かどうか調べる処理である。プロセスＩＤ管理テーブル１０００に定期監視を終えていないサービスアプリケーションＩＤが存在であれば（ステップＳ１６０３，Ｙｅｓ）、ステップＳ１６０４へ進む。あるいは、プロセスＩＤ管理テーブル１０００に定期監視を終えていないサービスアプリケーションＩＤが存在でなければ（ステップＳ１６０３，Ｎｏ）、ステップＳ１６０９へ進む。
【０１４６】
ステップＳ１６０４は、アプリケーション管理部２２０が、プロセスＩＤ管理テーブル１０００から定期監視を終えていないサービスアプリケーションのＩＤ、および該サービスアプリケーションＩＤに対応するプロセスＩＤを取得する処理である。
【０１４７】
ステップＳ１６０５は、アプリケーション管理部２２０が、該プロセスＩＤに対応するプロセスのＣＰＵ使用率を取得する処理である。
【０１４８】
ステップＳ１６０６は、アプリケーション管理部２２０が、ＣＰＵ使用率が該サービスアプリケーションＩＤに対応する利用可能ＣＰＵ使用率を超過しているかどうか調べる処理である。ＣＰＵ使用率が該サービスアプリケーションＩＤに対応する利用可能ＣＰＵ使用率を超過している場合（ステップＳ１６０６，Ｙｅｓ）、ステップＳ１６０７へ進む。ＣＰＵ使用率が該サービスアプリケーションＩＤに対応する利用可能ＣＰＵ使用率を超過していない場合（ステップＳ１６０６，Ｎｏ）、ステップＳ１６０９へ進む。
【０１４９】
ステップＳ１６０７は、アプリケーション管理部２２０が、該プロセスＩＤに対応するプロセスのスレッド優先度を下げるする処理である。ステップＳ１６０８は、アプリケーション管理部２２０が、該サービスアプリケーションが利用可能ＣＰＵ使用率を超過した事をシステムログなどに記録する処理である。ステップＳ１６０９は一定時間停止する処理である。その後、ステップＳ１６０１に戻る。
【０１５０】
図１８は、アプリケーション管理部２２０の異常通知処理Ｓ１８００の処理フローを示す図である。図１８は、サービスアプリケーション２１１が利用可能リソース量を超過した際に、ゲートウェイ管理装置１００に異常を通知する手順を示す。
【０１５１】
ステップＳ１８０１は、アプリケーション管理部２２０が、システムログなどから、サービスアプリケーション２１１が利用可能リソース量を超過したかどうかに関する情報を取得する処理である。
【０１５２】
ステップＳ１８０２は、アプリケーション管理部２２０が、利用可能リソース量を超過したサービスアプリケーション有りかどうか調べる処理である。利用可能リソース量を超過したサービスアプリケーションが有りであれば（ステップＳ１８０２，Ｙｅｓ）、ステップＳ１８０３へ進む。利用可能リソース量を超過したサービスアプリケーションが有りでなければ（ステップＳ１８０２，Ｎｏ）、ステップＳ１８０４へ進む。
【０１５３】
ステップＳ１８０３は、アプリケーション管理部２２０が、該サービスアプリケーションのＩＤと利用可能リソース量を超過したかどうかに関する情報をゲートウェイ管理装置１００に送信する処理である。
【０１５４】
ステップＳ１８０４は、アプリケーション管理部２２０が、一定時間、異常通知処理Ｓ１８００を停止する処理である。その後、ステップＳ１８０１に戻る。
【０１５５】
図１９は、アプリケーション管理部２２０の異常通知処理Ｓ１９００の処理フローを示す図である。図１９は、図１８の他の処理フローであり、サービスアプリケーションが利用可能リソース量を超過した際に、ゲートウェイ管理装置１００に異常を通知する手順を示す。
【０１５６】
ステップＳ１９０１は、アプリケーション管理部２２０が、システムログなどから、サービスアプリケーションが利用可能リソース量を超過したかどうかに関する情報を取得する処理である。
【０１５７】
ステップＳ１９０２は、アプリケーション管理部２２０が、利用可能リソース量を超過したサービスアプリケーション有かどうか調べる処理である。利用可能リソース量を超過したサービスアプリケーションが有りであれば（ステップＳ１９０２，Ｙｅｓ）、ステップＳ１９０３へ進む。利用可能リソース量を超過したサービスアプリケーションが有りでなければ（ステップＳ１９０２，Ｎｏ）、ステップＳ１９０５へ進む。
【０１５８】
ステップＳ１９０３は、アプリケーション管理部２２０が、導入サービスアプリケーション依存関係管理テーブル９００（図９参照）を参照し、該サービスアプリケーションのＩＤに対応するＩｍｐｏｒｔ−Ｐａｃｋａｇｅに記載の情報に対するＥｘｐｏｒｔ−Ｐａｃｋａｇｅに記載しているサービスアプリケーションのＩＤの一覧（Ｊ）を取得する処理である。
【０１５９】
ステップＳ１９０４は、アプリケーション管理部２２０が、該サービスアプリケーションのＩＤと、利用可能リソース量を超過したかどうかに関する情報と、Ｊの情報をゲートウェイ管理装置に送信する処理である。
【０１６０】
ステップＳ１９０５は、アプリケーション管理部２２０が、一定時間、異常通知処理Ｓ１９００を停止する処理である。その後、ステップＳ１９０１に戻る。
【０１６１】
本実施形態において、アプリケーションサービス実行基盤を備えたゲートウェイ装置２００に対し、サービス事業者の開発するアプリケーションサービス実行ソフトウェア（アプリケーションソフトウェア）を配布するゲートウェイ管理装置１００は、アプリケーションサービス実行ソフトウェア各々が利用可能なゲートウェイ装置２００のリソース量を管理するテーブルを備え、ゲートウェイ装置２００に新規のソフトウェアを配布する際に、ゲートウェイ装置２００の、アプリケーションサービス実行ソフトウェアが利用可能なリソース量の合計と、既にゲートウェイ装置２００に導入済みのソフトウェアの利用可能なリソース量の合計を取得し、導入済みのソフトウェアの利用可能なリソース量の合計と新規ソフトウェアの利用可能なリソース量との合計と、アプリケーションサービス実行ソフトウェアが利用可能なリソース量の合計を比較し、導入済みのソフトウェアの利用可能なリソース量の合計と新規ソフトウェアの利用可能なリソース量との合計が、アプリケーションサービス実行ソフトウェアが利用可能なリソース量の合計を超えない場合に、新規ソフトウェアの配布を許可する。ゲートウェイ管理装置１００は、サービス事業者の要求にしたがって、ゲートウェイ装置２００からアプリケーション実行ソフトウェアの実測リソース量を収集し、収集した実測リソース量に関する情報をサービス事業者へ提供することができる。
【０１６２】
また、実施形態においては、ゲートウェイ管理装置１００が配布するアプリケーションサービス実行ソフトウェアを実行するゲートウェイ装置２００であって、処理部と、メモリを含む記憶部とを備え、記憶部は、アプリケーションサービス実行ソフトウェアを利用可能なリソース量の合計と、既に導入済みのソフトウェアを利用可能なリソース量の合計を保持し、ゲートウェイ管理装置１００に新規のソフトウェアを要求する際、処理部は、保持するアプリケーションサービス実行ソフトウェアが利用可能なリソース量の合計と、既に導入済みのソフトウェアの利用可能リソース量の合計をゲートウェイ管理装置１００に送信する。ゲートウェイ装置２００は、ゲートウェイ管理装置１００の要求にしたがって、アプリケーション実行ソフトウェアの実測リソース量を計測し、計測した実測リソース量をゲートウェイ管理装置１００に送信することができる。
【０１６３】
さらに、アプリケーションサービス実行基盤を有するゲートウェイ装置２００に対しアプリケーションサービス実行ソフトウェアを配布するゲートウェイ管理装置１００を備えたゲートウェイ管理システムは、アプリケーションサービス実行ソフトウェア各々が利用可能なゲートウェイ装置２００のリソース量を管理し、ゲートウェイ管理装置１００は、ゲートウェイ装置２００に新規のソフトウェアを配布する際に、ゲートウェイ装置２００から、アプリケーションサービス実行ソフトウェアが利用可能なリソース量の合計と、ゲートウェイ装置２００に既に導入済みのソフトウェアの利用可能リソース量の合計を取得し、既に導入済みのソフトウェアの利用可能リソース量の合計と新規ソフトウェアの利用可能リソース量との合計と、アプリケーションサービス実行ソフトウェアが利用可能なリソース量の合計とを比較し、既に導入済みのソフトウェアの利用可能リソース量の合計と新規ソフトウェアの利用可能リソース量との合計が、アプリケーションサービス実行ソフトウェアが利用可能なリソース量の合計を超えない場合に、新規ソフトウェアの配布を許可する。ゲートウェイ管理システムは、サービス事業者の要求にしたがって、ゲートウェイ装置２００からアプリケーション実行ソフトウェアの実測リソース量を収集し、収集した実測リソース量に関する情報をサービス事業者へ提供することができる。
【０１６４】
本実施形態によれば、ゲートウェイ管理装置１００は、サービス事業者が提供した各アプリケーションを管理するサービス管理テーブル２０００、各アプリケーションが実行されたゲートウェイ装置２００の機器数と、各アプリケーションが実行された際に必要なリソース実測値とが関連付けられた実測リソース情報集計管理テーブル２２００を有する記憶部を備え、各ゲートウェイ装置２００から、導入済みの各アプリケーションが実行された際に必要となったリソース実測値を受信した場合、該受信したリソース実測値に基づき実測リソース情報集計管理テーブル２２００を更新し、機器数が所定値に達した場合、サービス管理テーブル２０００に登録されているサービス事業者に、リソース実測値を通知することができる。
【０１６５】
以上述べたように、本実施形態におけるゲートウェイ管理装置１００は、サービス事業者の要請にしたがってサービスアプリケーション２１１をゲートウェイ装置１００に配布した後に、該ゲートウェイ装置２００上でサービスアプリケーションを実行した結果、どの程度のリソース量（ヒープメモリ量、メモリ量、ＣＰＵ使用率）を使用したかを多くのゲートウェイ装置２００から収集、集計した情報をサービス事業者へ提供することを実現する。
【０１６６】
前述のような仕組みを搭載することでサービス事業者は、サービスアプリケーションの開発を、実機を用いずエミュレータなどを用いて行うような場合においても、実測リソース集計情報を得ることが可能となり、サービス事業者がゲートウェイ管理装置に登録する必要リソース量を高い精度で見積もることが可能となる。
【０１６７】
例えば、サービス事業者が設定する必要リソース量に応じて、ゲートウェイ管理装置１００がサービス事業者に課金を行うようなシステムの場合、サービス事業者はサービスアプリケーションが安定的に動作する範囲内においてできるだけ必要リソース量を小さくしたいと考えるが、本実施形態の仕組みを用いる事で必要リソース量をより小さく設定することが可能となると考えられる。
【０１６８】
例えば、サービス事業者が新規サービスを開始する際に、最初はベータテストとして実測リソース量収集要として、必要リソース量はある程度余裕のある大き目の値を設定してゲートウェイ管理装置に登録し、実測リソース集計情報を得て、その結果を基に正式版を、最小限の必要リソース量の設定で登録するというような運用が可能となる。
【符号の説明】
【０１６９】
１１，２１ ＥＰＲＯＭ
１２，２２ ＣＰＵ
１３，２３ メインメモリ
１４，２４ バス
１５，２５ 不揮発性記憶装置
１６，２６ 周辺制御装置
１７，２７，２８ ネットワークＩ／Ｆ
３０ 外部ネットワーク
４０ サービス事業者サーバ
５０ 利用者宅
１００ ゲートウェイ管理装置
１０１ アプリケーション登録管理部
１０２ アプリケーション配布管理部
１０３ ＤＢ管理部
１１０ サービス管理ＤＢ
２００ ゲートウェイ装置
２１０ アプリケーション実行部
２１１ サービスアプリケーション
２２０ アプリケーション管理部
２３０ 利用者宅内ネットワーク
２４０ 宅内機器
２５０ ゲートウェイ管理ＤＢ
３００ 全体利用可能リソーステーブル
４００ 利用可能リソーステーブル
５００ 必要リソーステーブル（リソース管理情報）
８００ 依存関係テーブル
９００ 導入サービスアプリケーション依存関係管理テーブル
１０００ プロセスＩＤ管理テーブル
２０００ サービス管理テーブル（アプリケーション管理情報）
２１００ 実測リソース情報テーブル（実測リソース装置情報）
２２００ 実測リソース情報集計管理テーブル（実測リソース集計管理情報）
【特許請求の範囲】
【請求項１】
サービス事業者がゲートウェイ装置に対して提供するアプリケーションソフトウェアであるアプリケーションを管理するとともに、前記ゲートウェイ装置においてアプリケーションを実行した際に必要となるリソース実測値を前記サービス事業者に通知するゲートウェイ管理装置のゲートウェイ管理方法であって、
前記ゲートウェイ管理装置は、
前記サービス事業者がサービス事業者サーバから提供した各アプリケーションを、該サービス事業者と関連付けて管理するアプリケーション管理情報を有するとともに、各アプリケーションが実行されたゲートウェイ装置の機器数と、各アプリケーションが実行された際に必要なリソース実測値とが関連付けられた実測リソース集計管理情報を有する記憶部を備え、
前記ゲートウェイ管理装置は、
前記各ゲートウェイ装置から、導入済みの各アプリケーションが実行された際に必要となったリソース実測値を受信し、該受信したリソース実測値に基づき前記実測リソース集計管理情報を更新し、
前記アプリケーション管理情報に登録されているアプリケーションの機器数が所定値に達しているかを判定し、前記所定値に達したアプリケーションについて前記アプリケーション管理情報に登録されているサービス事業者に、前記リソース実測値を通知する
ことを特徴とするゲートウェイ管理方法。
【請求項２】
前記ゲートウェイ管理装置は、さらに、
前記記憶部に、前記各アプリケーションが利用可能な前記ゲートウェイ装置のリソース
値を管理するリソース管理情報が記憶されており、
前記ゲートウェイ管理装置は、前記サービス事業者からアプリケーションの配布依頼を受けた場合、前記配布依頼を受けたアプリケーションと、前記サービス事業者が設定したリソース値とを関連付けて、前記リソース管理情報に登録するとともに、
前記実測リソース集計管理情報に新規のレコードを作成し、前記配布依頼を受けたアプリケーションに対する機器数を初期設定する
ことを特徴とする請求項１に記載のゲートウェイ管理方法。
【請求項３】
前記ゲートウェイ管理装置は、
前記ゲートウェイ装置に新規のアプリケーションを配布する際に、
前記ゲートウェイ装置のアプリケーションが利用可能なリソース値の合計と、既に前記ゲートウェイ装置に導入済みのアプリケーションの利用可能なリソース値の合計とを取得し、
前記導入済みのアプリケーションの利用可能なリソース値の合計と前記新規のアプリケーションの利用可能なリソース値との合計と、前記ゲートウェイ装置のアプリケーションが利用可能なリソース値の合計を比較し、
前記導入済みのアプリケーションの利用可能なリソース値の合計と前記新規のアプリケーションの利用可能なリソース値との合計が、前記ゲートウェイ装置のアプリケーションが利用可能なリソース量の合計を超えない場合に、前記新規のアプリケーションの配布を許可する
ことを特徴とする請求項１または請求項２に記載のゲートウェイ管理方法。
【請求項４】
前記ゲートウェイ管理装置は、
前記ゲートウェイ装置に配布する新規のアプリケーションが、前記実測リソース集計管理情報に基づいて配布依頼を受けたアプリケーションである場合、
前記ゲートウェイ装置に対し、前記新規のアプリケーションが前記ゲートウェイ装置において実行する際のリソース実測値を収集する旨を通知する
ことを特徴とする請求項２に記載のゲートウェイ管理方法。
【請求項５】
前記リソース値は、前記ゲートウェイ装置のＣＰＵの使用率および前記ゲートウェイ装置のメモリの使用量のうち少なくともいずれかである
ことを特徴とする請求項２に記載のゲートウェイ管理方法。
【請求項６】
前記ゲートウェイ装置は、オペレーションシステム、ＪａｖａのＶＭ、ＯＳＧｉで構成された実行環境である
ことを特徴とする請求項１に記載のゲートウェイ管理方法。
【請求項７】
サービス事業者がゲートウェイ装置に対して提供するアプリケーションソフトウェアであるアプリケーションを管理するゲートウェイ管理装置であって、
前記サービス事業者がサービス事業者サーバから提供した各アプリケーションを、該サービス事業者と関連付けて管理するアプリケーション管理情報を有するとともに、各アプリケーションが実行されたゲートウェイ装置の機器数と、各アプリケーションが実行された際に必要なリソース実測値とが関連付けられた実測リソース集計管理情報を記憶する記憶部と、
前記各ゲートウェイ装置から、導入済みの各アプリケーションが実行された際に必要となったリソース実測値を受信し、該受信したリソース実測値に基づき前記実測リソース集計管理情報を更新し、前記アプリケーション管理情報に登録されているアプリケーションの機器数が所定値に達しているかを判定し、前記所定値に達したアプリケーションについて前記アプリケーション管理情報に登録されているサービス事業者に、前記リソース実測値を通知するアプリケーション配布管理部とを有する
ことを特徴とするゲートウェイ管理装置。
【請求項８】
前記ゲートウェイ管理装置は、
前記記憶部に、前記各アプリケーションが利用可能な前記ゲートウェイ装置のリソース
値を管理するリソース管理情報が記憶されており、
前記ゲートウェイ管理装置は、さらに、
前記サービス事業者からアプリケーションの配布依頼を受けた場合、前記配布依頼を受けたアプリケーションと、前記サービス事業者が設定したリソース値とを関連付けて、前記リソース管理情報に登録するとともに、前記実測リソース集計管理情報に新規のレコードを作成し、前記配布依頼を受けたアプリケーションに対する機器数を初期設定するアプリケーション登録管理部を有する
ことを特徴とする請求項７に記載のゲートウェイ管理装置。
【請求項９】
前記アプリケーション配布管理部は、
前記ゲートウェイ装置に新規のアプリケーションを配布する際に、
前記ゲートウェイ装置のアプリケーションが利用可能なリソース値の合計と、既に前記ゲートウェイ装置に導入済みのアプリケーションの利用可能なリソース値の合計とを取得し、
前記導入済みのアプリケーションの利用可能なリソース値の合計と前記新規のアプリケーションの利用可能なリソース値との合計と、前記ゲートウェイ装置のアプリケーションが利用可能なリソース値の合計を比較し、
前記導入済みのアプリケーションの利用可能なリソース値の合計と前記新規アプリケーションの利用可能なリソース値との合計が、前記ゲートウェイ装置のアプリケーションが利用可能なリソース量の合計を超えない場合に、前記新規のアプリケーションの配布を許可する
ことを特徴とする請求項７または請求項８に記載のゲートウェイ管理装置。
【請求項１０】
前記アプリケーション配布管理部は、
前記ゲートウェイ装置に配布する新規のアプリケーションが、前記実測リソース集計管理情報に基づいて配布依頼を受けたアプリケーションである場合、
前記ゲートウェイ装置に対し、前記新規アプリケーションが前記ゲートウェイ装置において実行する際のリソース実測値を収集する旨を通知する
ことを特徴とする請求項８に記載のゲートウェイ管理装置。
【請求項１１】
前記リソース値は、前記ゲートウェイ装置のＣＰＵの使用率および前記ゲートウェイ装置のメモリの使用量のうち少なくともいずれかである
ことを特徴とする請求項８に記載のゲートウェイ管理方法。
【請求項１２】
前記ゲートウェイ装置は、オペレーションシステム、ＪａｖａのＶＭ、ＯＳＧｉで構成された実行環境である
ことを特徴とする請求項７に記載のゲートウェイ管理装置。
【請求項１３】
ゲートウェイ管理装置が配布するアプリケーションソフトウェアであるアプリケーションを実行するゲートウェイ装置であって、
前記ゲートウェイ装置は、
各アプリケーションが実行された際に必要なリソース実測値と稼動時間とを関連付けて実測リソース装置情報として記憶する記憶部を備え、
前記ゲートウェイ装置は、
所定期間ごとに導入済みの各アプリケーションが実行された際に必要となったリソースを計測し、該計測したリソース実測値が前記実測リソース情報に登録済みにリソース実測値より大きければ、前記実測リソース情報のリソース実測値を更新し、
前記稼動時間が所定の時間を超えた場合、前記実測リソース情報のリソース実測値を前記ゲートウェイ管理装置に送信する
ことを特徴とするゲートウェイ装置。
【請求項１４】
前記ゲートウェイ装置は、
前記ゲートウェイ管理装置から新規に配布されたアプリケーションが、該ゲートウェイ装置において実行する際のリソース実測値を収集する旨の通知を受けると、
前記実測リソース装置情報に新規のレコードを作成し、前記新規に配布されたアプリケーションの稼動時間を初期設定する
ことを特徴とする請求項１３に記載のゲートウェイ装置。
【請求項１】
サービス事業者がゲートウェイ装置に対して提供するアプリケーションソフトウェアであるアプリケーションを管理するとともに、前記ゲートウェイ装置においてアプリケーションを実行した際に必要となるリソース実測値を前記サービス事業者に通知するゲートウェイ管理装置のゲートウェイ管理方法であって、
前記ゲートウェイ管理装置は、
前記サービス事業者がサービス事業者サーバから提供した各アプリケーションを、該サービス事業者と関連付けて管理するアプリケーション管理情報を有するとともに、各アプリケーションが実行されたゲートウェイ装置の機器数と、各アプリケーションが実行された際に必要なリソース実測値とが関連付けられた実測リソース集計管理情報を有する記憶部を備え、
前記ゲートウェイ管理装置は、
前記各ゲートウェイ装置から、導入済みの各アプリケーションが実行された際に必要となったリソース実測値を受信し、該受信したリソース実測値に基づき前記実測リソース集計管理情報を更新し、
前記アプリケーション管理情報に登録されているアプリケーションの機器数が所定値に達しているかを判定し、前記所定値に達したアプリケーションについて前記アプリケーション管理情報に登録されているサービス事業者に、前記リソース実測値を通知する
ことを特徴とするゲートウェイ管理方法。
【請求項２】
前記ゲートウェイ管理装置は、さらに、
前記記憶部に、前記各アプリケーションが利用可能な前記ゲートウェイ装置のリソース
値を管理するリソース管理情報が記憶されており、
前記ゲートウェイ管理装置は、前記サービス事業者からアプリケーションの配布依頼を受けた場合、前記配布依頼を受けたアプリケーションと、前記サービス事業者が設定したリソース値とを関連付けて、前記リソース管理情報に登録するとともに、
前記実測リソース集計管理情報に新規のレコードを作成し、前記配布依頼を受けたアプリケーションに対する機器数を初期設定する
ことを特徴とする請求項１に記載のゲートウェイ管理方法。
【請求項３】
前記ゲートウェイ管理装置は、
前記ゲートウェイ装置に新規のアプリケーションを配布する際に、
前記ゲートウェイ装置のアプリケーションが利用可能なリソース値の合計と、既に前記ゲートウェイ装置に導入済みのアプリケーションの利用可能なリソース値の合計とを取得し、
前記導入済みのアプリケーションの利用可能なリソース値の合計と前記新規のアプリケーションの利用可能なリソース値との合計と、前記ゲートウェイ装置のアプリケーションが利用可能なリソース値の合計を比較し、
前記導入済みのアプリケーションの利用可能なリソース値の合計と前記新規のアプリケーションの利用可能なリソース値との合計が、前記ゲートウェイ装置のアプリケーションが利用可能なリソース量の合計を超えない場合に、前記新規のアプリケーションの配布を許可する
ことを特徴とする請求項１または請求項２に記載のゲートウェイ管理方法。
【請求項４】
前記ゲートウェイ管理装置は、
前記ゲートウェイ装置に配布する新規のアプリケーションが、前記実測リソース集計管理情報に基づいて配布依頼を受けたアプリケーションである場合、
前記ゲートウェイ装置に対し、前記新規のアプリケーションが前記ゲートウェイ装置において実行する際のリソース実測値を収集する旨を通知する
ことを特徴とする請求項２に記載のゲートウェイ管理方法。
【請求項５】
前記リソース値は、前記ゲートウェイ装置のＣＰＵの使用率および前記ゲートウェイ装置のメモリの使用量のうち少なくともいずれかである
ことを特徴とする請求項２に記載のゲートウェイ管理方法。
【請求項６】
前記ゲートウェイ装置は、オペレーションシステム、ＪａｖａのＶＭ、ＯＳＧｉで構成された実行環境である
ことを特徴とする請求項１に記載のゲートウェイ管理方法。
【請求項７】
サービス事業者がゲートウェイ装置に対して提供するアプリケーションソフトウェアであるアプリケーションを管理するゲートウェイ管理装置であって、
前記サービス事業者がサービス事業者サーバから提供した各アプリケーションを、該サービス事業者と関連付けて管理するアプリケーション管理情報を有するとともに、各アプリケーションが実行されたゲートウェイ装置の機器数と、各アプリケーションが実行された際に必要なリソース実測値とが関連付けられた実測リソース集計管理情報を記憶する記憶部と、
前記各ゲートウェイ装置から、導入済みの各アプリケーションが実行された際に必要となったリソース実測値を受信し、該受信したリソース実測値に基づき前記実測リソース集計管理情報を更新し、前記アプリケーション管理情報に登録されているアプリケーションの機器数が所定値に達しているかを判定し、前記所定値に達したアプリケーションについて前記アプリケーション管理情報に登録されているサービス事業者に、前記リソース実測値を通知するアプリケーション配布管理部とを有する
ことを特徴とするゲートウェイ管理装置。
【請求項８】
前記ゲートウェイ管理装置は、
前記記憶部に、前記各アプリケーションが利用可能な前記ゲートウェイ装置のリソース
値を管理するリソース管理情報が記憶されており、
前記ゲートウェイ管理装置は、さらに、
前記サービス事業者からアプリケーションの配布依頼を受けた場合、前記配布依頼を受けたアプリケーションと、前記サービス事業者が設定したリソース値とを関連付けて、前記リソース管理情報に登録するとともに、前記実測リソース集計管理情報に新規のレコードを作成し、前記配布依頼を受けたアプリケーションに対する機器数を初期設定するアプリケーション登録管理部を有する
ことを特徴とする請求項７に記載のゲートウェイ管理装置。
【請求項９】
前記アプリケーション配布管理部は、
前記ゲートウェイ装置に新規のアプリケーションを配布する際に、
前記ゲートウェイ装置のアプリケーションが利用可能なリソース値の合計と、既に前記ゲートウェイ装置に導入済みのアプリケーションの利用可能なリソース値の合計とを取得し、
前記導入済みのアプリケーションの利用可能なリソース値の合計と前記新規のアプリケーションの利用可能なリソース値との合計と、前記ゲートウェイ装置のアプリケーションが利用可能なリソース値の合計を比較し、
前記導入済みのアプリケーションの利用可能なリソース値の合計と前記新規アプリケーションの利用可能なリソース値との合計が、前記ゲートウェイ装置のアプリケーションが利用可能なリソース量の合計を超えない場合に、前記新規のアプリケーションの配布を許可する
ことを特徴とする請求項７または請求項８に記載のゲートウェイ管理装置。
【請求項１０】
前記アプリケーション配布管理部は、
前記ゲートウェイ装置に配布する新規のアプリケーションが、前記実測リソース集計管理情報に基づいて配布依頼を受けたアプリケーションである場合、
前記ゲートウェイ装置に対し、前記新規アプリケーションが前記ゲートウェイ装置において実行する際のリソース実測値を収集する旨を通知する
ことを特徴とする請求項８に記載のゲートウェイ管理装置。
【請求項１１】
前記リソース値は、前記ゲートウェイ装置のＣＰＵの使用率および前記ゲートウェイ装置のメモリの使用量のうち少なくともいずれかである
ことを特徴とする請求項８に記載のゲートウェイ管理方法。
【請求項１２】
前記ゲートウェイ装置は、オペレーションシステム、ＪａｖａのＶＭ、ＯＳＧｉで構成された実行環境である
ことを特徴とする請求項７に記載のゲートウェイ管理装置。
【請求項１３】
ゲートウェイ管理装置が配布するアプリケーションソフトウェアであるアプリケーションを実行するゲートウェイ装置であって、
前記ゲートウェイ装置は、
各アプリケーションが実行された際に必要なリソース実測値と稼動時間とを関連付けて実測リソース装置情報として記憶する記憶部を備え、
前記ゲートウェイ装置は、
所定期間ごとに導入済みの各アプリケーションが実行された際に必要となったリソースを計測し、該計測したリソース実測値が前記実測リソース情報に登録済みにリソース実測値より大きければ、前記実測リソース情報のリソース実測値を更新し、
前記稼動時間が所定の時間を超えた場合、前記実測リソース情報のリソース実測値を前記ゲートウェイ管理装置に送信する
ことを特徴とするゲートウェイ装置。
【請求項１４】
前記ゲートウェイ装置は、
前記ゲートウェイ管理装置から新規に配布されたアプリケーションが、該ゲートウェイ装置において実行する際のリソース実測値を収集する旨の通知を受けると、
前記実測リソース装置情報に新規のレコードを作成し、前記新規に配布されたアプリケーションの稼動時間を初期設定する
ことを特徴とする請求項１３に記載のゲートウェイ装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【公開番号】特開２０１３−８０３６８（Ｐ２０１３−８０３６８Ａ）
【公開日】平成２５年５月２日（２０１３．５．２）
【国際特許分類】
【出願番号】特願２０１１−２１９８８４（Ｐ２０１１−２１９８８４）
【出願日】平成２３年１０月４日（２０１１．１０．４）
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【Ｆターム（参考）】
【公開日】平成２５年５月２日（２０１３．５．２）
【国際特許分類】
【出願日】平成２３年１０月４日（２０１１．１０．４）
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【Ｆターム（参考）】
[ Back to top ]