複数のサービス事業者のサービスが動作するゲートウェイ装置であって、サービス毎に設けられ、当該サービスで用いられるルート情報と、当該サービスの利用が許可される機器に関する許可情報とを含むサービス定義情報を記憶する記憶部と、通信プロトコル毎に設けられ、機器にインストールされた外部アプリケーションまたは機器と当該通信プロトコルでデータを送受信するドライバ部と、前記ドライバ部が対応する通信プロトコルのインタフェースで送受信されたデータを共通インタフェースに変換する中継部と、前記中継部から共通インタフェースに変換されたデータを受け付け、対応するサービスのサービス定義情報を前記記憶部から読み出し、当該サービス定義情報のルート情報および許可情報に基づいて前記データを中継する中継基本部と、を有することを特徴とするゲートウェイ装置。複数のサービス事業者のサービスが動作するゲートウェイ装置が行う通信方法であって、前記ゲートウェイ装置は、サービス毎に設けられ、当該サービスで用いられるルート情報と、当該サービスの利用が許可される機器に関する許可情報とを含むサービス定義情報を記憶する記憶部を備え、機器にインストールされた外部アプリケーションまたは機器と、所定の通信プロトコルでデータを送受信する通信ステップと、前記通信ステップで所定の通信プロトコルのインタフェースで送受信されたデータを共通インタフェースに変換する変換ステップと、前記共通インタフェースに変換されたデータを受け付け、対応するサービスのサービス定義情報を前記記憶部から読み出し、当該サービス定義情報のルート情報および許可情報に基づいて前記データを中継する中継ステップと、を行うことを特徴とする通信方法。非特許文献1のプラットフォーム技術では、サービス事業者は、サービスを実行するアプリケーションプログラム以下、APというを作成し、作成されたAPは当該サービスを利用するユーザのゲートウェイ装置にダウンロードされ、実行される。ゲートウェイ装置のAPが機器の制御などの通信を行うことで、サービスが提供される。しかしながら、非特許文献1には次のような課題がある。すなわち、ゲートウェイ装置では、様々なサービス事業者のAPやゲートウェイ装置自身が提供する機能が動作しており、あるAPに障害が発生した場合に、ゲートウェイ装置全体が停止などしてしまうと大きな問題となる。そのようなことが発生しないように、新たなAPを導入する際には、事前にAPの動作検証を行う必要があり、新サービス追加時のAPの事前動作検証コスト費用、期間が大きいという課題がある。本発明は、上記事情に鑑みてなされたものであり、本発明の目的は、複数のサービス事業者のサービスが動作するゲートウェイ装置において、新たなサービスを追加する際の動作検証コストを低減することにある。上記目的を達成するため、本発明は、複数のサービス事業者のサービスが動作するゲートウェイ装置であって、サービス毎に設けられ、当該サービスで用いられるルート情報と、当該サービスの利用が許可される機器に関する許可情報とを含むサービス定義情報を記憶する記憶部と、通信プロトコル毎に設けられ、機器にインストールされた外部アプリケーションまたは機器と当該通信プロトコルでデータを送受信するドライバ部と、前記ドライバ部が対応する通信プロトコルのインタフェースで送受信されたデータを共通インタフェースに変換する中継部と、前記中継部から共通インタフェースに変換されたデータを受け付け、対応するサービスのサービス定義情報を前記記憶部から読み出し、当該サービス定義情報のルート情報および許可情報に基づいて前記データを中継する中継基本部と、を有するまた、本発明は、複数のサービス事業者のサービスが動作するゲートウェイ装置が行う通信方法であって、前記ゲートウェイ装置は、サービス毎に設けられ、当該サービスで用いられるルート情報と、当該サービスの利用が許可される機器に関する許可情報とを含むサービス定義情報を記憶する記憶部を備え、機器にインストールされた外部アプリケーションまたは機器と、所定の通信プロトコルでデータを送受信する通信ステップと、前記通信ステップで所定の通信プロトコルのインタフェースで送受信されたデータを共通インタフェースに変換する変換ステップと、前記共通インタフェースに変換されたデータを受け付け、対応するサービスのサービス定義情報を前記記憶部から読み出し、当該サービス定義情報のルート情報および許可情報に基づいて前記データを中継する中継ステップと、を行う。本発明によれば、複数のサービス事業者のサービスが動作するゲートウェイ装置において、新たなサービスを追加する際の動作検証コストを低減することができる。以下、本発明の実施の形態について、図面を参照して説明する。図1は、本発明の実施形態に係る通信システムの全体構成図である。従来、サービス事業者から提供されるAPをゲートウェイ装置で動作させることにより実現していたサービス提供を、本実施形態では、ゲートウェイ装置側に保持されるAPバンドルと、機器側で動作させる外部APとに分けて、サービス提供を実現する。なお、本実施形態では、OSGiJava登録商標の技術を用いた実装を一例として以下に説明するが、本発明はこれに限定されるものではなく、様々な技術に適用することができる。図示する通信システムは、ゲートウェイ装置1と、複数の機器41~44と、配信サーバ3とを備える。複数の機器41~44は、ホームネットワーク8または外部ネットワーク9を介してゲートウェイ装置1と接続され、ゲートウェイ装置1と通信する。なお、図1では、機器の例として、機器41がスマートフォン、機器42がプリンタ、機器43がパソコン、機器44が固定電話機としているが、これらに限定されるものではない。また、図示する例では、機器41スマートフォンおよび機器43パソコンには、所定のサービスの利用に必要な外部APがそれぞれインストールされている。ユーザは、所望のサービスの利用する場合、当該サービスを提供するサービス事業者のサーバに機器41、43を用いてアクセスし、対応する外部APを機器41、43にダウンロードおよびインストールする。配信サーバは、例えばOSAPのセンターシステムであって、各サービス事業者から提供されるAPバンドルと、ゲートウェイ装置1の提供者例えば、通信事業者などが提供する中継バンドルおよびドライババンドルを保持し、これらのバンドルをゲートウェイ装置に配信する。ユーザは、所望のサービスの利用する場合、当該サービスに対応するAPバンドル、中継バンドルおよびドライババンドルを配信サーバ3からゲートウェイ装置1にダウンロードし、インストールする。ゲートウェイ装置1は、宅内に配置されるホームゲートウェイサービスゲートウェイであって、ホームネットワーク8または外部ネットワーク9に接続されたネットワーク装置である。本実施形態のゲートウェイ装置1は、OSGi標準技術に基づいた各種のバンドルソフトウェアを備える。図示する例では、ドライババンドルドライバ部18~21と、中継バンドル中継部15~17と、中継基本バンドル中継基本部14と、APバンドルサービス定義情報11~13とを備える。なお、ドライババンドル18~21と、中継バンドル15~17と、APバンドル11~13は、前述のとおり、配信サーバ3から配信されるものである。ドライババンドル18~21は、通信プロトコル毎に設けられ、機器にインストールされた外部アプリケーションまたは機器と当該通信プロトコルでデータを送受信する。具体的には、各ドライババンドルは、対応する機器と、当該機器が使用する通信プロトコル例えばHTTPやUPnP、SIPなどで通信する。各ドライババンドルは、それぞれの通信プロトコルに特化した専用のインタフェースを定義している。中継バンドル15~17は、ドライババンドルが所定の通信プロトコルのインタフェースで送受信されたデータを共通インタフェースに変換する。具体的には、ドライババンドルの個別のインタフェースを、中継基本バンドル14が定義する共通インタフェースに変換する。中継バンドルは、基本的にはドライババンドル毎に存在するが、図1に示す中継バンドル16のように複数のドライババンドル19、10で共有されていてもよい。中継基本バンドル14は、各中継バンドルから共通インタフェースに変換されたデータを受け付け、対応するサービスのサービス定義ファイルサービス定義情報をAPバンドルから読み出し、当該サービス定義ファイルのルート情報および許可情報に基づいてデータを中継する。また、中継基本バンドルは、APバンドルに保持されるサービス定義ファイルを読み出し、当該ファイルに定義された範囲内で、当該APバンドル、対応する中継バンドル向けのサービス例えばOSGiサービスを生成し、登録する。なお、中継基本バンドルは、1つであって、APバンドルサービス事業者に代わって中継バンドルを用いて通信の中継処理を行う。APバンドル11~13は、サービス事業者が作成するバンドルであって、外部APと対をなすソフトウェアであり、サービス毎に設けられる。各APバンドルには、サービスを定義するためのサービス定義ファイルが格納される。サービス定義ファイルには、当該サービスで用いられるルート情報例えば、HTTP→UPnPなどの中継先プロトコル、当該サービスの利用が許可される機器に関するパーミッション情報サービス事業者に許可されたパーミッションのみ記述される、その他サービスの名称や説明文などの情報などの中継に関する設定情報が格納される。なお、APバンドルは、通常、中継基本バンドル14に初期化の要求だけを行い、その他の処理は行わない。以上説明したゲートウェイ装置1は、例えば、CPUと、メモリと、HDD等の外部記憶装置と、入力装置と、出力装置とを備えた汎用的なコンピュータシステムを用いることができる。このコンピュータシステムにおいて、CPUがメモリ上にロードされたゲートウェイ装置1のプログラムバンドルを実行することにより、ゲートウェイ装置1の各機能が実現される。また、ゲートウェイ装置1のプログラムバンドルは、ハードディスク、フレキシブルディスク、CD-ROM、MO、DVD-ROMなどのコンピュータ読取り可能な記録媒体に記憶することも、ネットワークを介して配信することもできる。次に、本実施形態のゲートウェイ装置1の処理について説明する。まず、ゲートウェイ装置1の初期処理について説明する。新たなAPバンドルと、当該APバンドルに対応する中継バンドルおよびドライババンドルがゲートウェイ装置1に登録ダウンロードされると、中継基本バンドルは初期処理を行う。中継基本バンドルは、APバンドルに格納されたサービス定義ファイルに基づいて、対応する中継バンドルからのコールバックを受け付けるためのリスナ登録と、対応する中継バンドルの初期化とを行う。中継バンドルは、中継基本バンドルからの初期化指示により、機器が備える外部APへの接続をドライババンドルに要求し、また、必要に応じてドライババンドルからのコールバックを受けるための処理を行う。図2は、OSGiにおける初期処理の一例を示すシーケンスである。新たに登録されたAPバンドルは、起動時に、中継基本バンドルのRelayManagerの機能を用いて、中継機能の初期化を要求する。これにより、中継基本バンドルは、APバンドル内のサービス定義ファイルを読み出し、RelayAdmin、Notifyの各OSGiサービスの登録を行う。具体的には、APバンドルは、RelayManagerの生成指示を中継基本バンドルに送信しS11、中継基本バンドルは、APバンドルに格納されたサービス定義ファイルを読み出し、RelayManagerを生成するS12。RelayManagerは、APバンドルが中継基本バンドルに初期化を依頼するインタフェースである。中継基本バンドルにRelayManagerが生成されると、APバンドルは、RelayManagerのinitメソッドを呼び出して、中継基本バンドルの初期化を行うS13。これにより、RelayManagerは、APバンドルのサービス定義ファイルのサービス事業者識別子、中継種別のリスト、ルートクラスのリストなどの設定情報に基づき、ルート情報の設定、RelayAdminの登録S14、およびNotifyの登録S17、S20を行う。RelayAdminの登録S14では、サービスプロパティにAPバンドルのサービス事業者識別子、その他のAPバンドルのサービス定義ファイルの内容の一部を設定する。RelayAdminは、APバンドルに関する情報を中継バンドルが取得するためのインタフェースである。登録されたRelayAdminは、対応する中継バンドル図示する例では、中継バンドル1と中継バンドル2の各々に、登録通知を送信するS15、S19。これにより、中継バンドルは、必要に応じて、ドライババンドルの初期化に必要な情報を取得してドライババンドルを初期化し、また、対応する外部APへの接続情報を取得して外部APへの接続を行うようにドライババンドルに指示するS16。Notifyの登録S17、S20では、APバンドルのサービス定義ファイルからサービス事業者と中継種別のリストを読み出し、サービスプロパティに設定する。Notifyは、中継バンドルが中継基本バンドルにノーティファイ中継を依頼するインタフェースである。また、中継バンドルがノーティファイ中継の必要性を判断するためにノーティファイの登録を監視しているインタフェースでもある。登録されたNotifyは、対応する中継バンドル図示する例では、中継バンドル1と中継バンドル2の各々に、登録通知を送信するS18、S21。中継バンドルは、Notifyが登録されると、自分が処理するべきノーティファイ中継種別をサービスプロパティに持つサービスをトラッキングし、ノーティファイ中継を開始する。また、中継バンドルは、ドライババンドルに対して機器からの通知や、外部APからの要求を受信できるように設定する場合には、APバンドルのBundeContextやAccessControlContextを使用し、APバンドルのサービス定義ファイルに設定されているパーミッション情報の範囲内で動作するようにするS22。このように、中継バンドルは、RelayAdminおよびNotifyが登録されると、外部APへの接続をドライババンドルに依頼したり、必要に応じて、ドライババンドルからのコールバックを受けるためのサービスをAPバンドルのBundleContextおよびAccessControlContextを用いて登録する。次に、本実施形態の中継処理について説明する。中継処理は、中継バンドルからの呼び出しノーティファイ中継を、別の中継バンドルへの呼び出しアクション中継に変換し、応答がある場合には、アクション中継の戻り値をノーティファイ中継の戻り値として、元の中継バンドルに返す一連の処理である。図3は、OSGiにおける中継処理の一例を示すシーケンスである。ドライババンドルは、外部APからの通信または機器からの通知などのイベントを受け取った場合、対応する中継バンドルを呼び出すS41。ここでは、ドライババンドルは、外部APからのイベント受け取り、中継バンドル1を呼び出すものとする。中継バンドル1は、当該イベントを受け取るべきAPバンドルを選択し、当該APバンドルが登録されている中継基本バンドルのNotify1を呼び出し、イベントを中継するS42。このノーティファイ中継において、中継バンドル1は、必要に応じて送信先ルートクラスルートセッション、および、送信元ルートクラスルートセッションを含めることができる。Notify1は、イベントのノーティファイ中継を受けると、送信先ルートクラス中継バンドルを決定するルーティング処理を行うS43。Notify1は、例えば、APバンドル内のサービス定義ファイルに記載されたルート情報から、中継種別の先頭部分が最も長く一致するエントリを選択し、選択したルートクラスを送信先として決定する。なお、ノーティファイ中継に送信先ルートクラスが指定されている場合は、指定されたルートクラスを送信先として決定する。具体的には、ある要求に対する応答などルートクラスが明確である場合、中継バンドルは送信先ルートクラスをノーティファイ中継の要求データに送信先ルートクラスを含めるためそれを利用する。要求データに送信先ルートクラスがない場合、例えばサービス定義ファイルに以下の様に記載されているとき、中継種別がAUPnP10CPInvokeActionの場合、送信先ルートクラスとしてupnpcustomを選択し、中継種別がAUPnP10CPGetDeviceDescriptionの場合は送信先ルートクラスとしてupnpcpを選択する。なお、中継バンドルは、起動時に自らが処理可能なルートクラスを自らのオブジェクトのプロパティに登録しておき、それを元に中継バンドルを選択する。<例:サービス定義ファイルの記述>applicationrelayrouteAUPnP10CPupnpcpapplicationrelayrouteAUPnP10CPInvokeActionupnpcustomNotify1は、S43で決定した送信先ルートクラスの中継バンドルを、APバンドルのパーミッション情報を用いて呼び出す、アクション中継を行うS44。ここでは、中継バンドル2を呼び出すものとする。このとき、ノーティファイ中継で送信先ルートセッション、および、送信元ルートクラスルートセッションが指定されている場合、これらも引き渡す。中継バンドル2は、APバンドルのパーミッション情報の範囲内で、ドライババンドルの機能を用いてアクションを実行し、機器の制御または外部APへの通知を行うS45。具体的には、例えばパーミッション情報として該当するドライババンドルの利用権限が与えられていない場合には、制御を失敗させる。その他、ドライババンドルに規定されたパーミッションJavaパーミッションがすべてAPバンドルのパーミッション情報に記載されている場合のみ制御が成功する。なお、S41で入力されたイベントが応答を要求する応答付の場合には、S45のアクションの応答データを、逆のルートでノーティファイ中継の送信元の中継バンドル1、外部APまたは機器に返す。図示する例では、機器の応答データは、中継バンドル2を介してNotify2に中継されS46、S47、Notify2は送信先ルートクラス中継バンドル1を決定しS48、中継バンドル1から外部APに送信されるS49、S50。以上説明した本実施形態では、ルート情報およびパーミッション情報が定義されたサービス定義ファイルをゲートウェイ装置1に配信するとともに、中継バンドルによってAPIApplicationProgramInterfaceを統一する。これにより、ゲートウェイ装置の提供者例えば、通信事業者などは、サービス事業者から提供されるAPバンドルに記述されたサービス定義ファイルの情報のみを静的に読み出し、チェック検証するだけで、新たなサービスを追加することができる。すなわち新サービス追加時の動作検証コストを低減することができる。従来技術では、APバンドルの代わりにゲートウェイ装置にダウンロードされるAPをチェックする必要があるが、APは通常汎用的なプログラム言語で記載されるため、記述された内容に問題がないかを静的に読み出しチェックするだけでは、ゲートウェイ装置の提供者にとって不都合があるかどうか判断できない場合が多く、実際には新たなサービスのAPを導入する前に、実際にAPを動作させた試験を行う必要があり、期間的、金銭的なコストが大きい。これに対し、本実施形態では、サービス定義ファイルの情報のみを検証するだけで、新たなサービスを追加することができため、動作検証コストを低減することができる。また、本実施形態では、サービス事業者は、サービスをゲートウェイ装置1のAPバンドルと、機器の外部APとで実現する。これにより、外部APは複数の通信プロトコルを直接制御する必要はなく、サービス事業者が慣れている開発コストが小さい1つの通信プロトコル例えばHTTP等で、各機器を利用することができる。すなわち、本実施形態では、従来技術における、サービス事業者が各通信プロトコルおよびそのドライバプログラムの挙動を把握してAPを作成することによる、開発コストが大きいという課題を解決することができる。また、本実施形態では、エンドユーザは、通信プロトコル毎のドライババンドルの単位ではなく、サービス毎のAPバンドルによって許可される機器もしくは外部APのみが通信するよう制限することができる。また、本実施形態では、将来新たな通信プロトコルや、それを利用するサービスが登場した場合でも、当該通信プロトコルまたはサービスに対応するドライババンドル、中継バンドル、APバンドルをゲートウェイ装置に配信することで、同じ枠組みで対応可能であり、将来的な拡張が容易である。なお、本発明は上記実施形態に限定されるものではなく、その要旨の範囲内で数々の変形が可能である。例えば、中継バンドルが処理する内容を、機能ごとに文字列中継種別で定義し、中継種別の単位で中継を行うこともできる。例えば、UPnP機器のDeviceDescriptionは取得させるが、UPnPのActionは送信させない等、独自に定義した中継種別単位で記述することが考えられる。また、外部APの認証情報をAPバンドルに格納する例えばダイジェスト認証のIDPass、証明書等ことで、外部APとAPバンドルサービスとを1対1に対応させることとしてもよい。また、ユーザインタフェースを設け、ユーザからの入力により、APバンドルのパーミッション情報を動的に変更し、例えば中継対象を機器個体単位で追加削除することができるようにしてもよい。これにより、機器単位でのアクセスコントロールが可能になる。また、上記実施形態では、OSGiの技術を用いた実装例について説明したが、本発明はこれに限定されるものではなく、様々な技術に適用することができる。