(57)【要約】      （修正有）【課題】様々な機器を制御するＨＧＷ上のアプリケーションから、どの被制御機器に対して制御を行うかを決める処理を簡易化し、アプリケーションの開発量を低減する。【解決手段】サービス登録手続きとサービス検索手続きを提供し、サービス管理を行うサービス管理手段を有するソフトウェアであって、前記サービス管理手段は、機器の接続方法及び通信方法によらずに機器制御を行うための共通手続きを有し、前記共通手続きを介して機器の接続方法及び通信方法によって異なる機器制御コマンド生成処理を行う機器制御インタフェースサービスを提供し、さらに、前記機器制御インタフェースサービスのプロパティ情報として、前記機器制御インタフェースサービスによって制御される機器に関する情報を記憶する手段を備える。【選択図】図３
2014130411.tif 000002
【特許請求の範囲】
【請求項１】
通信機器に、サービス登録手続きとサービス検索手続きを提供させ、
機器の接続方法及び通信方法によらずに機器制御を行うための共通手続きを有し、前記共通手続きを介して機器の接続方法及び通信方法によって異なる機器制御コマンド生成処理を行う機器制御インタフェースサービスを提供し、
さらに、前記機器制御インタフェースサービスのプロパティ情報として、前記機器制御インタフェースサービスによって制御される機器に関する情報を記憶する
サービス管理手段として機能させることを特徴とするソフトウェア。
【請求項２】
請求項１記載のソフトウェアであって、
前記サービス管理手段は、さらに、
機器の接続方法及び通信方法によらずに機器制御に使用する機器情報を取得するための共通手続きを有し、前記共通手続きを介して機器の接続方法及び通信方法によって種類の異なる機器情報取得する処理を行う機器情報取得インタフェースサービスを提供する
ことを特徴とするソフトウェア。
【請求項３】
請求項１ないしは２記載のソフトウェアであって、
前記サービス管理手段は、さらに、
制御内容と制御パラメータと検索式を引数とする機器制御手続きを有し、外部機器からの要求に応じて前記機器制御手続きを呼び出すことを可能とする外部アクセスサービスを提供する
ことを特徴とするソフトウェア。
【請求項４】
請求項１から３いずれか記載のソフトウェアを搭載した通信装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信装置上で動作するソフトウェア及び通信装置に関する。
【背景技術】
【０００２】
近年、環境保護のためのＣＯ２の削減や電力料金の削減、電力不足への対策のためのエネルギーマネジメントシステムが注目を集めている。このようなエネルギーマネジメントシステムの一形態として、家庭のエネルギーマネジメントを行うホームエネルギーマネジメントシステム（ＨＥＭＳ）がある。ＨＥＭＳは、制御・状態監視のために宅内の機器同士を接続するホームネットワーク技術をベースとして構成される。
【０００３】
また、ネットワークに接続している機器の種類が増え、エネルギーマネジメントの他にも、ホームオートメーション、セキュリティ、ヘルスケアといった多様なホームネットワークサービスが期待されている。これらのサービスは、ホームネットワークに置かれたホームゲートウェイ（ＨＧＷ）上のアプリケーションとして実現されることが多い。ＨＧＷ上のアプリケーションが外部サーバや外部端末と連携して動作する場合もある。
【０００４】
ＨＧＷ上のアプリケーションを開発する上での課題は、接続する機器の種類に応じて、その制御方法が煩雑になり、開発量が増えることである。例えば、被制御機器の接続形態や制御プロトコルの違いを意識してプログラミングしたり、全ての接続機器の中から制御処理を行うべき被制御機器を抽出する処理をプログラミングしたりする必要がある。
【０００５】
これに対し、ネットワーク機器種別によらない共通インタフェースを提供する機能と、共通インタフェースを介して受け付けた要求をネットワーク機器種別毎の固有の管理・制御要求に変換して処理を行う機能とを有するネットワーク管理方法が開示されている（特許文献１）。
【０００６】
また、ＯＳＧｉ（Ｏｐｅｎ  Ｓｅｒｖｉｃｅ  Ｇａｔｅｗａｙ  Ｉｎｉｔｉａｔｉｖｅ）（登録商標）プラットフォーム上で、各目標装置を、ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍｍｉｎｇ  Ｉｎｔｅｒｆａｃｅ）を介してアプリケーションから制御することが可能なエンティティにより表し、前記エンティティが装置タイプの階層構造に従い、階層の低い装置が階層の高い装置の特性を引き継ぐようにし、これにより、アプリケーションに対して一貫したＡＰＩを提供するプラットフォームが開示されている（特許文献２）。
【０００７】
いずれの場合も、接続する機器によって接続形態や制御プロトコルが異なるホームネットワーク環境において、アプリケーションの開発負担を低減することができる。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２００５−２５２６２８
【特許文献２】特開２００８−５０１２０２
【発明の概要】
【発明が解決しようとする課題】
【０００９】
ネットワーク機器種別によらない共通ＡＰＩを提供したり、共通ＡＰＩで装置タイプの階層構造に従った制御を行えるようにしたりした場合、アプリケーションは、接続形態や制御プロトコルの違いを意識せずに済むので、アプリケーションの被制御機器の制御処理は簡単になり、その開発量を低減することができる。
【００１０】
しかしながら、どの被制御機器に対して制御を行うかを決める処理の煩雑さは変わらない。例えば、リビングにある全ての機器を電源ＯＦＦするという制御を行う場合、別途、自分が保持する接続機器リストの中から設置場所＝リビングである機器を検索する処理を行い、その機器の機器ＩＤを取得した上で、上記共通ＡＰＩの引数として機器ＩＤを渡すことで、機器制御ができるようになる。すなわち、共通ＡＰＩと、機器情報を管理する処理とが対応付けられていないので、共通ＡＰＩを呼ぶ前の処理が煩雑になってしまう。
【００１１】
本発明が解決しようとする課題は、機器制御のための共通ＡＰＩ自体に様々機器情報を対応付けて、アプリケーションからは簡単な検索式を記述するのみで所望の被制御機器用の共通ＡＰＩを取得する方法を備えたソフトウェア、及び、当該ソフトウェアを搭載した通信装置を提供することである。
【課題を解決するための手段】
【００１２】
上記課題を解決するために、本発明のソフトウェアは、  サービス登録手続きとサービス検索手続きを提供し、サービス管理を行うサービス管理手段を有するソフトウェアであって、サービス管理手段は、機器の接続方法及び通信方法によらずに機器制御を行うための共通手続きを有し、共通手続きを介して機器の接続方法及び通信方法によって異なる機器制御コマンド生成処理を行う機器制御インタフェースサービスを提供し、さらに、機器制御インタフェースサービスのプロパティ情報として、機器制御インタフェースサービスによって制御される機器に関する情報を記憶する手段を備える  ことを特徴とする。
【発明の効果】
【００１３】
本発明によれば、ＨＧＷ上のアプリケーションは、簡単な検索式を記述するのみで所望の機器を制御するための共通ＡＰＩを取得できるようになるので、アプリケーションの開発負担を低減することができる。
【図面の簡単な説明】
【００１４】
【図１】本発明の第一の実施形態に係るシステム全体の構成図である。
【図２】通信装置１００のハードウェア構成例である。
【図３】通信装置１００のソフトウェア構成例である。
【図４】本発明の第一の実施形態に係るソフトウェアの処理フローを示す図である。
【図５】本発明の第一の実施形態に係るソフトウェアの処理フローを示す図である。
【図６】機器登録時の画面例を示す図である。
【図７】多段接続機器の機器制御実装クラスの実現方法の概念を表す図である。
【図８】多段接続機器の機器制御実装クラスの実現方法の概念を表す図である。
【図９】外部機器からの機器制御処理フローを示す図である。
【図１０】外部機器からの機器制御要求／応答のデータ例を示す図である。
【発明を実施するための形態】
【００１５】
図１は、本発明の第１の実施形態に係るシステム構成の例である。
【００１６】
１はユーザ宅、２は通信サービスプロバイダが提供するアクセスネットワーク、３はアクセスネットワークや拠点をつなぐインターネット、４はインターネット上のサーバである。また、５及び６は電力会社などが運営する無線または有線アクセスネットワーク、７は電力会社の運営するメータリングデータ管理システムＭＤＭＳ（Ｍｅｔｅｒ  Ｄａｔａ  Ｍａｎａｇｅｍｅｎｔ  Ｓｙｓｔｅｍ）である。
【００１７】
ユーザ宅１において、５１はＥｔｈｅｒｎｅｔ（登録商標）で構成された有線ＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）で接続された宅内ネットワーク、５２は無線ＬＡＮ（８０２．１１）で接続された宅内ネットワーク、５３はＩＥＥＥ８０２．１５．４で構成された無線ＰＡＮ（Ｐｅｒｓｏｎａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）で接続された宅内ネットワークである。
【００１８】
１００は接続されたネットワーク上の機器を管理する通信装置、２００は通信装置またはサーバと接続して機器の状態を表示したり、機器の操作画面を表示したりする表示端末、２５０はデジタルテレビ、３００はネットワーク接続機能付エアコン、３５０はネットワーク接続機能無エアコン、４００は電力量メータ、４５０はネットワーク接続機能無エアコン、５００及び５１０は温度・湿度などを計測するセンサ、５５０及び５６０はネットワーク接続機能無エアコン、６００は蓄電池、６５０は照明、７００は太陽光発電システムである。
【００１９】
また、１０は通信装置１００に接続して宅内ネットワーク５３への接続機能を提供するアダプタ、２０はエアコン３５０に接続して宅内ネットワーク５１への接続機能を提供するアダプタ、３０はプロトコル変換を行い宅内ネットワーク５１への接続機能を提供するアダプタ、３１はセンサ５００及び５１０に接続してアダプタ３０への接続機能を提供するアダプタ、３２はネットワーク接続機能無エアコン５５０及び５６０に接続してアダプタ３０への接続機能を提供するアダプタ、４０はネットワーク接続機能無エアコン４５０に接続して宅内ネットワーク５３への接続機能を提供するアダプタである。
【００２０】
宅内ネットワーク５１には、通信装置１００と、デジタルテレビ２５０と、アダプタ２０を介してエアコン３５０と、アダプタ３０及びアダプタ３１を介してセンサ５００及び５１０と、アダプタ３０及びアダプタ３２を介してネットワーク接続機能無エアコン５５０及び５６０と、蓄電池６００と、照明６５０と、太陽光発電システム７００が接続され、相互にデータの送受信を行うことにより、情報取得及び操作ができる。
【００２１】
宅内ネットワーク５２には、通信装置１００と、表示端末２００と、エアコン３００が接続され、相互にデータの送受信を行うことにより、情報取得及び操作ができる。
【００２２】
宅内ネットワーク５３には、通信装置１００と、電力メータ４００と、アダプタ４０を介してネットワーク接続機能無エアコン４５０が、アダプタ１０を介して接続され、相互にデータの送受信を行うことにより、ネットワークを介しての情報取得及び操作ができる。
【００２３】
通信装置１００がユーザ宅１の各機器とのデータ送受信により取得した情報は、インターネット３を介してサーバ４に送信され、サーバ４に蓄積される。ユーザは、表示端末２００やデジタルテレビ２５０を利用することで、蓄積された情報を閲覧できる。
【００２４】
ここで、図１では、宅内ネットワーク５１におけるハブや、宅内ネットワーク５２、または５３における中継器については図示していないが、必要に応じて接続されているものとする。また、ここでは、通信装置１００が直接アクセスネットワーク２に接続しているが、ルータなどを介してアクセスネットワークに接続してもよい。
【００２５】
本実施例では、ユーザ宅１内の宅内ネットワーク５１、アクセスネットワーク２、インターネット３、宅内ネットワーク５２においては、ネットワークプロトコルとしてＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）を使用し、上位のトランスポートプロトコルにはＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）やＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）を用いる。なお、ＩＰにはバージョンの違いとしてＩＰｖ４とＩＰｖ６が有るが、本実施例は、そのどちらかに限定される物ではない。また、その上位層に当たるプロトコルとしては、機器制御用にＥｃｈｏｎｅｔ  Ｌｉｔｅ(登録商標)やＭｏｄｂｕｓ(登録商標)ＴＣＰ、その他ベンダ独自プロトコルが想定されるが、いずれかに限定される物ではない。
【００２６】
図２は、通信装置１００のハードウェア構成例を示すブロック図である。
【００２７】
通信装置１００は、制御部１０１、記憶部１０２、時刻管理部１０３、有線ＬＡＮ  Ｉ／Ｆ１０４、無線ＬＡＮ  Ｉ／Ｆ１０５、ＷＡＮ（Ｗｉｄｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）１０６から構成する。
【００２８】
制御部１０１は、ＯＳ（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）の実行を行い通信装置１００内の他の構成要素を制御する。また、アプリケーションの実行処理を行い、宅内ネットワークで接続された他の機器やアクセスネットワークを介して接続されたサーバへのデータ送受信指示を行うなどして通信装置１００を機能させる。
【００２９】
記憶部１０２は、揮発性メモリおよび不揮発性メモリで構成する。不揮発性メモリにはＯＳやアプリケーションなどの通信装置１００を動作させるためのソフトウェアや固定データを格納する。揮発性メモリにはソフトウェアの動作に必要なデータなどを一時的に格納する。また、制御部１０１の指示に従い、接続された機器の情報など、指示されたデータを保持する。
【００３０】
時刻管理部１０３は、ＲＴＣ（Ｒｅａｌ  Ｔｉｍｅ  Ｃｌｏｃｋ）を備え、アクセスネットワーク１２あるいはインターネット１３上に存在するＮＴＰ（Ｎｅｔｗｏｒｋ  Ｔｉｍｅ  Ｐｒｏｔｏｃｏｌ）サーバが提供する時刻情報を利用して、時刻を管理する。ＮＴＰとは、ネットワークに接続される機器において、機器が持つ時計を正しい時刻に同期するためのプロトコルである。
【００３１】
有線ＬＡＮ  Ｉ／Ｆ１０４は、制御部１０１の指示によって宅内ネットワーク５１に接続された機器との間でデータの送受信を行う。
【００３２】
無線ＬＡＮ  Ｉ／Ｆ１０５は、制御部１０１の指示によって宅内ネットワーク５２に接続された機器との間でデータの送受信を行う。
【００３３】
ＷＡＮ  Ｉ／Ｆ１０６は、制御部１０１の指示によってアクセスネットワーク２を介してインターネットに接続されたサーバなどとの間でデータの送受信を行う。ＷＡＮ  Ｉ／Ｆ１０６は、Ｅｔｈｅｒｎｅｔなどの有線通信部、または３Ｇ、ＷｉＭＡＸ（Ｗｏｒｌｄｗｉｄｅ Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ ｆｏｒ Ｍｉｃｒｏｗａｖｅ Ａｃｃｅｓｓ）（登録商標）、ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）などの無線通信部として構成される。
【００３４】
図３は、通信装置１００のソフトウェア構成例を示すブロック図である。
【００３５】
通信装置１００の機能を実現する制御ソフトウェアは、通信装置１００の記憶部１０２に展開され制御部１０１で実行される。図３は、機能的にブロックに分割して記載されており、各ブロックの分割、統合はあり得る。また制御ソフトウェアは、１つのプログラムで実現する必要はなく、２以上のプログラムの組合せによって実現しても良い。
【００３６】
制御ソフトウェアは、カーネル空間１１００、Ｊａｖａ（登録商標）  ＶＭ（Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ）１２００、ＯＳＧｉ（Ｏｐｅｎ  Ｓｅｒｖｉｃｅ  Ｇａｔｅｗａｙ  Ｉｎｉｔｉａｔｉｖｅ）フレームワーク１３００、デバイスアクセスサービスバンドル１４００、デバイスドライババンドル１５００、機器管理バンドル１６００、機器制御インタフェース（Ｉ／Ｆ）バンドル１７００、アプリケーションバンドル１８００、ＨＴＴＰ（Ｈｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）サービスバンドル１９００から構成する。
【００３７】
カーネル空間１１００は、ＯＳの基本機能を実装したソフトウェアであり、アプリケーションや周辺機器の監視、ディスクやメモリなどの資源の管理、割込み処理、プロセス間通信などの基本機能を提供する。ＴＣＰ／ＩＰなどの基本的な通信プロトコルや、Ｅｔｈｅｒｎｅｔドライバ、無線ＬＡＮドライバなどを含む。
【００３８】
Ｊａｖａ  ＶＭ１２００は、Javaプログラムの実行環境で、Javaバイトコードをそのプラットフォームのネイティブコードに変換して実行するソフトウェアである。
【００３９】
ＯＳＧｉフレームワーク１３００は、様々なソフトウェア部品（バンドル）のダウンロード、インストール、実行といったライフサイクルの管理や、バンドルが提供する機能インタフェース（サービス）の管理機能を提供する。サービス管理機能の一部として、サービス登録を行うＡＰＩと、登録されたサービスを取得するＡＰＩを提供する。
また、サービス登録を行う際には、登録するサービスに対して様々な情報（サービスプロパティ）を関連付けることができる。ＯＳＧｉフレームワーク１３００は、Ｊａｖａベースのソフトウェアコンポーネント化技術であり、ＯＳＧｉフレームワーク１３００上で動作するソフトウェアはバンドルともいう。ＯＳＧｉフレームワーク１３００上で動作するバンドルには、ＨＴＴＰサーバ（Ｗｏｒｌｄ  Ｗｉｄｅ  Ｗｅｂによる情報送信機能を持ったコンピュータ。Ｗｅｂサーバともいう。）やＵＰｎＰ（Ｕｎｉｖｅｒｓａｌ  Ｐｌｕｇ  ａｎｄ  Ｐｌａｙの略。家庭内のパソコンや周辺機器、ＡＶ機器、電話、家電製品などの機器をネットワークを通じて接続し、相互に機能を提供しあうための技術仕様。）に対応した機器の管理・制御といった、ＯＳＧｉサービス基盤に含まれる標準バンドルと、ＯＳＧｉサービス基盤の手法にのっとって実装されたユーザバンドルとがある。
【００４０】
デバイスアクセスサービスバンドル１４００は、ＯＳＧｉサービス基盤に含まれる標準バンドルの一つであり、例えば、通信装置１００に対して機器が動的に追加接続された場合に、その機器のデバイスドライバを動的にネットワークからダウンロードするといった機能の実現を支援する。デバイスアクセスサービスバンドル１４００は、ドライバ管理インタフェースクラス１４１０を含む。
【００４１】
ドライバ管理インタフェースクラス１４１０は、ある機器に対する最適なデバイスドライバを検索、決定するのに使用するメソッドのインタフェース定義を含むクラスである。具体的には、各デバイスドライバの適合度を判定するｍａｔｃｈメソッドや、最適なデバイスドライバが見つかった時に、デバイスドライバ確定処理を行うａｔｔａｃｈメソッドのインタフェース定義を含む。
【００４２】
機器管理バンドル１６００は、ユーザバンドルの一つであり、通信装置１００上のソフトウェアから制御できる機器に関連する各種情報を管理する。機器管理バンドル１６００は、機器構成管理インタフェースクラス１６１０、機器構成管理実装クラス１６２０、機器情報インタフェースクラス１６３０、機器情報実装クラス１６４０、ドライバ情報インタフェースクラス１６５０を含む。
【００４３】
機器構成管理インタフェースクラス１６１０は、機器登録メソッド、機器登録削除メソッド、登録機器一覧取得メソッド等のインタフェース定義を含むクラスである。
【００４４】
機器構成管理実装クラス１６２０は、前述の機器構成管理インタフェースクラス１６１０の実装クラスである。実装クラスとは、Ｊａｖａ等のプログラム言語において、インタフェース宣言されている抽象メソッドの実体を定義するクラスである。つまり、機器登録メソッドの実体として、引数で機器情報が渡された時に、それを表すインスタンスを生成したり、機器登録削除メソッドの実体として、引数で機器を特定する情報が渡された時に、その機器に関連する機器情報インスタンスを削除したり、登録機器一覧取得メソッドの実体として、生成した機器情報インスタンスのリスト情報を返せるようにしたりする。
【００４５】
機器情報インタフェースクラス１６３０は、各種機器情報取得メソッドのインタフェース定義を含むクラスである。機器情報には、例えば、機器ＩＤ、機器種別、機器詳細情報、ドライバＩＤ、プロトコル、シリアル番号、機器名称、ベンダ、型式、設置場所がある。また、上記以外に機器情報として登録されている項目リストを取得するメソッドや、項目名を引数として渡すことで、その項目に該当する機器情報を取得するメソッドのインタフェース定義を含む。
【００４６】
機器情報実装クラス１６４０は、前述の機器情報インタフェースクラス１６３０の実装クラスである。各種機器情報取得メソッドの実体として、登録された機器情報インスタンスに属する各種情報を返せるようする。
【００４７】
ドライバ情報インタフェースクラス１６５０は、ドライバ情報取得メソッドのインタフェース定義を含むクラスである。ドライバ情報とは、全ての機器に共通な機器情報と、機器の接続形態やプロトコルに依存する機器情報とを合わせたものである。つまり、当該デバイスドライバを使って制御する機器に属する情報である。
【００４８】
機器制御インタフェースバンドル１７００は、ユーザバンドルの一つであり、機器制御を行うためのＡＰＩを提供する。制御する機器種別に応じて別のバンドルとして構成する。例えば、エアコン用の機器制御インタフェースバンドル、照明用の機器制御インタフェースバンドル、デジタルテレビ用の機器制御インタフェースバンドルのように構成される。機器制御インタフェースバンドル１７００は、機器制御インタフェースクラス１７１０、機器制御インタフェース変換クラス１７２０を含む。
【００４９】
機器制御インタフェースクラス１７１０は、各種機器制御メソッドのインタフェース定義を含むクラスである。例えば、エアコン用の機器制御インタフェースクラスであれば、冷房／暖房／除湿などのモード変更メソッド、設定温度変更メソッド、電源ＯＮ／ＯＦＦ変更メソッドなど、照明用の機器制御インタフェースクラスであれば、設定照度変更メソッド、照度一段階アップメソッド、照度一段階ダウンメソッド、電源ＯＮ／ＯＦＦ変更メソッドなど、デジタルテレビ用の機器制御インタフェースクラスであれば、チャネル変更メソッド、音量変更メソッド、電源ＯＮ／ＯＦＦ変更メソッドなどのインタフェース定義を含む。
また、全ての機器に共通で使用できる電源ＯＮ／ＯＦＦ変更メソッドのインタフェース定義のみを含む機器制御インタフェースクラスを用意し、それを継承する形で、エアコン用の機器制御インタフェースクラス、照明用の機器制御インタフェースクラス、デジタルテレビ用の機器制御インタフェースクラスを定義する方法もある。さらには、エアコン用の機器制御インタフェースクラスも、標準機用と高級機用とを別々にし、標準エアコン用の機器制御インタフェースクラスでは、前述のようにモード変更メソッド、設定温度変更メソッド、電源ＯＮ／ＯＦＦ変更メソッドなどを定義し、高級エアコン用の機器制御インタフェースクラスは、標準エアコン用の機器制御インタフェースクラスを継承し、さらに、風向変更メソッドや空気清浄機能ＯＮ／ＯＦＦ変更メソッドなどを定義する方法もある。
【００５０】
機器制御インタフェース変換クラス１７２０は、Ｓｅｒｖｌｅｔ機能を持ち、必要に応じてＨＴＴＰサービスバンドル１９００から呼ばれる。外部からのＨＴＴＰリクエストで渡された情報を変換し、機器制御インタフェースクラス１７１０を呼ぶ機能を持つ。
【００５１】
デバイスドライババンドル１５００は、ユーザバンドルの一つであり、特定の機器を制御する処理や、制御に必要な情報を持つ。制御する機器の接続形態やプロトコルに応じて別のバンドルとして構成する。例えば、Ｅｃｈｏｎｅｔ  Ｌｉｔｅ対応エアコン用のデバイスドライババンドル、ベンダ毎の独自通信プロトコル対応エアコン用のデバイスドライババンドルのように構成される。デバイスドライババンドル１５００は、ドライバ管理実装クラス１５１０、ドライバ情報実装クラス１５２０、機器制御実装クラス１５３０を含む。
【００５２】
ドライバ管理実装クラス１５１０は、前述のドライバ管理インタフェースクラス１４１０の実装クラスである。例えば、各デバイスドライバの適合度を判定するｍａｔｃｈメソッドの実体として、当該ドライバ管理実装クラスに割り当てられたドライバＩＤと、ｍａｔｃｈメソッドの引数として渡された機器情報に含まれるドライバＩＤとが一致するかを確認する処理を行ったり、デバイスドライバ確定処理を行うａｔｔａｃｈメソッドの実体として、対応する機器制御実装クラスを生成したりする。
【００５３】
ドライバ情報実装クラス１５２０は、前述のドライバ情報インタフェースクラス１６５０の実装クラスである。ドライバ情報取得メソッドの実体として、当該デバイスドライババンドルに属するドライバ情報の項目リストを返せるようする。
【００５４】
機器制御実装クラス１５３０は、前述の機器制御インタフェースクラス１７１０の実装クラスである。例えば、エアコン用の機器制御インタフェースクラスの実装クラスであれば、冷房／暖房／除湿などのモード変更メソッド、設定温度変更メソッド、電源ＯＮ／ＯＦＦ変更メソッドなどの実体を定義する。各メソッドでは、具体的な機器制御プロトコルに応じた処理を行う。機器制御プロトコルには、Ｅｃｈｏｎｅｔ  Ｌｉｔｅ、Ｍｏｄｂｕｓ、その他ベンダ独自プロトコルがある。
なお、機器制御プロトコル処理を別バンドルとして切り出し、機器制御実装クラスから機器制御プロトコル用バンドルの機能を利用する構成も考えられる。これにより、Ｅｃｈｏｎｅｔ  Ｌｉｔｅ対応エアコン用のデバイスドライババンドルとＥｃｈｏｎｅｔ  Ｌｉｔｅ対応照明用のデバイスドライババンドルを実装する場合に、Ｅｃｈｏｎｅｔ  Ｌｉｔｅプロトコル処理バンドルは共通に使用できるので、各デバイスドライババンドルの開発量を低減できる。
【００５５】
なお、機器の接続形態は上記のように単純でない場合もある。例えば、プロトコル変換アダプタを介して二つ以上のネットワークが接続され、その下に接続される場合や、複数の機器を中継器で一旦集約して通信装置１００と接続される場合もある。そのような場合には、機器制御実装クラスを以下のように実装する方法が考えられる。
【００５６】
一つ目の方法は、親機／子機を個別に表すクラスを設け、それらを組み合わせて一つの機器制御実装クラスとして表す方法である（図７参照）。各中継機の実装クラスは、自分が受信できるプロトコル、アドレス、親機ＩＤ等の情報を含む。末端の制御対象機器の制御メソッドのメソッド実体である機器制御実装クラスの中では、プロトコル、アドレス、制御内容に応じたコマンド（指示）データを生成し、そのコマンドデータを親機の機器制御実装クラスに渡す。制御対象機器の親機に当たる中継機クラスは、自分のプロトコル、アドレス、子機から渡されたコマンドデータに応じて、プロトコル変換を行い、新たなコマンドデータを生成する。
【００５７】
これを繰り返すことで、通信装置１００から最終的に送信すべきコマンドデータを生成することができる。上記方法によれば、各中継機クラスを一度用意すれば、その組み合わせを変えても使用でき、拡張性が高いというメリットがある。
【００５８】
別の方法は、親機／子機の関係を含めて一つの機器制御実装クラスとして表す方法である（図８参照）。本機器制御実装クラスには、途中で経由するプロトコル、階層構造の中の各アドレス等の、最終的な制御コマンドデータを生成するために必要な情報を全て含む。そのため、末端の制御対象機器のメソッド実体である機器制御実装クラスの中では、プロトコルやアドレスの階層関係を考慮して、通信装置１００から最終的に送信すべきコマンドデータを一度に生成することができる。上記方法によれば、実装が比較的容易になるというメリットがある。
【００５９】
アプリケーションバンドル１８００は、ユーザバンドルの一つであり、通信装置１００から制御可能な機器をユーザに登録させるための処理や、所定のアルゴリズムに基づいて機器制御を行う処理を行う。例えば、電力センサの値を定期的に取得し、宅内の消費電力合計をユーザに提示する電力見える化アプリケーションや、宅内の消費電力合計を監視し、それがあらかじめ定めた所定値を超えた場合に、所定の機器の電源をＯＦＦしたり、省電力モードに移行させたりする電力ピークカットアプリケーションである。
【００６０】
ＨＴＴＰサービスバンドル１９００は、ＯＳＧｉの標準サービスの一つであり、ＨＴＴＰサーバ機能やＳｅｒｖｌｅｔエンジン機能を持つ。
【００６１】
図４及び図５は、通信装置１００のソフトウェアの処理フローを示す図である。本処理フローは、アプリケーションが行う機器登録処理と機器制御処理に関するフローである。
【００６２】
デバイスドライババンドル１５００は、起動されるとドライバ管理実装クラス１５１０のインスタンスを生成し（Ｓ４０１）、それをドライバ管理インタフェースサービスとしてＯＳＧｉフレームワーク１３００にサービス登録する（Ｓ４０２）。
【００６３】
また、ドライバ情報実装クラス１５２０のインスタンスを生成する（Ｓ４０３）。当該インスタンスは、全ての機器に共通な機器情報と、デバイスドライババンドルに特有の情報、すなわち、機器の接続形態やプロトコルに依存する機器情報とを保持する。
前者は、例えば、機器ＩＤ、機器種別、機器詳細情報、ドライバＩＤ、プロトコル、シリアル番号、機器名称、ベンダ、型式、設置場所である。
【００６４】
後者は、通信プロトコルとしてＴＣＰ／ＩＰを使う機器用のデバイスドライババンドルであれば、ＩＰアドレス、ＴＣＰポートといった情報を含む。また、複数機器を収容可能な中継器を介して接続される機器用のデバイスドライババンドルであれば、接続された複数機器（子機）を区別するための識別情報（ＭＡＣアドレスやチャネル番号など）を含む。その他にも、デバイスドライババンドルがカバーする機器に応じて、データアクセスサイズ、センサの監視周期、プロトコルバージョンなどを含む。生成したドライバ情報実装クラスのインスタンスを、ドライバ情報インタフェースサービスとしてＯＳＧｉフレームワーク１３００にサービス登録する（Ｓ４０４）。この際、サービスプロパティとしてドライバＩＤを含める。
【００６５】
機器管理バンドル１６００は、起動されると機器構成管理実装クラス１６２０のインスタンスを生成し（Ｓ４０５）、それを機器構成管理インタフェースサービスとしてＯＳＧｉフレームワーク１３００にサービス登録する（Ｓ４０６）。
【００６６】
アプリケーションバンドル１８００は、機器登録処理の最初に、ユーザからドライバＩＤが入力されるのを待つ（Ｓ４０７）。この時、アプリケーションがユーザに提示する画面の一例を図６（ａ）に示す。この例では、ドライバＩＤを直接入力するのではなく、デバイスドライバの種類を選択することで、ドライバＩＤが入力されたと見なす。
【００６７】
ドライバＩＤが入力されると、そのドライバＩＤを検索条件として、ＯＳＧｉフレームワーク１３００からドライバ情報インタフェースサービスを取得する（Ｓ４０８）。前述のとおり、ドライバ情報インタフェースサービスのサービスプロパティとしてドライバＩＤが含まれるので、登録済みの複数のドライバ情報インタフェースサービスの中から、検索条件で記述されたドライバＩＤに合致するドライバ情報インタフェースサービスを取得できる。
【００６８】
次に、取得したドライバ情報インタフェースサービスに含まれるドライバ情報取得メソッドを呼ぶ（Ｓ４０９）。ドライバ情報取得メソッドの実体は、デバイスドライババンドルのドライバ情報実装クラスである。このクラスの中で、当該デバイスドライババンドルに属するドライバ情報の項目リストを返す。ドライバ情報の項目リストに含まれる項目としては、例えば、通信プロトコルとしてＴＣＰ／ＩＰを使う機器用のデバイスドライババンドルであれば、全機器に共通な機器情報以外に、ＩＰアドレス、ＴＣＰポートといった情報を含む。
【００６９】
また、複数機器を収容可能な中継器を介して接続される機器用のデバイスドライババンドルであれば、全機器に共通な機器情報以外に、接続された複数機器（子機）を区別するための識別情報（ＭＡＣアドレスやチャネル番号など）を含む。その他にも、デバイスドライババンドルがカバーする機器に応じて、全機器に共通な機器情報以外に、データアクセスサイズ、センサの監視周期、プロトコルバージョンなどを含む。ドライバ情報の項目リストとは、文字通り、全機器に共通な機器情報である「機器ＩＤ」、「機器種別」、「機器詳細情報」、「ドライバＩＤ」、「プロトコル」、「シリアル番号」、「機器名称」、「ベンダ」、「型式」、「設置場所」と、「ＩＰアドレス」、「ＴＣＰポート」といった全機器に共通な機器情報以外の情報が連結された情報である。もしくは、「機器ＩＤ」とそのデフォルト値、「機器種別」とそのデフォルト値といったように、項目と、それに対応付けられた値とを一組とし、それらが連結された情報である。
【００７０】
さらに、項目リストには、各項目の簡単な説明文、設定変更可否の情報が付加されていてもよい。このように項目リストにデフォルト値や説明文などを追加することで、アプリケーションは内容を解釈することなく当該情報がどのようなものであるかをユーザに提示し、ユーザに入力を促すことができる。これにより、アプリケーションの開発を効率化できる。
【００７１】
アプリケーションバンドル１８００は、ドライバ情報を取得したら、その項目一覧を表示し、各項目に対するユーザ入力を待つ（Ｓ４１０）。この時、アプリケーションがユーザに提示する画面の一例を図６（ｂ）（ｃ）に示す。図６（ａ）の画面にて、「２．エアコン（独自プロトコル）」が選択された場合、Ｓ４０９で取得した情報に基づいて、図６（ｂ）のような画面を表示する。
【００７２】
この例では、全機器に共通する機器情報である「機器ＩＤ」「機器種別」「プロトコル」「ベンダ」と、デバイスドライバに依存した機器情報である「ＩＰアドレス」「ＴＣＰポート」の入力をユーザに促している。
【００７３】
図６（ａ）の画面にて、「５．照明（無線アダプタ）」が選択された場合、Ｓ４０９で取得した情報に基づいて、図６（ｃ）のような画面を表示する。この例では、全機器に共通する機器情報である「機器ＩＤ」「機器種別」「プロトコル」「ベンダ」と、デバイスドライバに依存した機器情報である「ＩＰアドレス」「子機ＭＡＣアドレス」の入力をユーザに促している。これらの各項目に対して、デフォルト値が定められていても良いし、ユーザに全てを入力させるようにしても良い。
【００７４】
このように、アプリケーションバンドル１８００は、機器の接続形態やプロトコルによらず、共通のドライバ情報インタフェースサービスを利用することで、機器の接続形態やプロトコルによって異なるドライバ情報の項目リストを取得することができ、アプリケーション開発量を低減できる。
【００７５】
ドライバ情報の全ての必須項目に対する入力がなされたら、アプリケーションバンドル１８００は、ＯＳＧｉフレームワーク１３００から機器構成管理インタフェースサービスを取得する（Ｓ４１１）。続いて、取得した機器構成管理インタフェースサービスに含まれる機器登録メソッドを呼ぶ（Ｓ４１２）。機器登録メソッドは、登録したい機器の機器情報一式を引数として受けることができる。
【００７６】
機器登録メソッドの実体は機器構成管理実装クラスにある。このクラスの中で、引数で渡された機器情報を保持する機器情報実装クラスのインスタンスを生成する（Ｓ４１３）。つまり、ここで生成された機器情報実装クラスのインスタンスは、Ｓ４１０で入力された機器情報を保持する。そして、当該機器情報実装クラスのインスタンスを機器情報インタフェースサービスとしてＯＳＧｉフレームワーク１３００にサービス登録する（Ｓ４１４）。この際、サービスプロパティとして、当該インスタンスが保持する全ての機器情報を含める。
【００７７】
機器情報インタフェースサービスがサービス登録されると、ＯＳＧｉフレームワーク１３００からその旨をデバイスアクセスサービスバンドルに通知する（Ｓ４１５）。それを受けたデバイスアクセスサービスバンドルは、ＯＳＧｉフレームワーク１３００からドライバ管理インタフェースサービスを取得する（Ｓ４１６）。
【００７８】
取得したドライバ管理インタフェースサービスに含まれるデバイスドライバ適合度判定メソッド（ｍａｔｃｈメソッド）を呼ぶ（Ｓ４１７）。この処理は、取得したドライバ管理インタフェースサービスが複数あれば、各ドライバ管理インタフェースサービスについて行う。そして、最も適合度が高いと判定されたドライバ管理インタフェースサービスのデバイスドライバ確定メソッド（ａｔｔａｃｈメソッド）を呼ぶ（Ｓ４１８）。
【００７９】
デバイスドライバ確定メソッドの実体は、デバイスドライババンドルのドライバ管理実装クラスである。このクラスの中で、機器制御実装クラスのインスタンスを生成し（Ｓ４１９）、それを機器制御インタフェースサービスとしてＯＳＧｉフレームワーク１３００にサービス登録する（Ｓ４２０）。なお、Ｓ４１８のデバイスドライバ確定メソッドの引数で、Ｓ４１４でサービスプロパティに含めた機器情報が渡されるので、Ｓ４２０では、この機器情報を機器制御インタフェースサービスのサービスプロパティとして登録する。
【００８０】
また、Ｓ４１９で生成した機器制御実装クラスのインスタンスが、例えば、高級エアコン用の機器制御インタフェースクラスの実装クラスであった場合、Ｓ４２０において、本インスタンスを高級エアコン用の機器制御インタフェースサービスとしてサービス登録する。さらに、本インスタンスは、標準エアコン用の機器制御インタフェースクラスの実装クラスとも言えるので、Ｓ４２０において、本インスタンスを標準エアコン用の機器制御インタフェースサービスとしてサービス登録する。
【００８１】
さらに、本インスタンスは、全機器共通の機器制御インタフェースクラスの実装クラスとも言えるので、Ｓ４２０において、本インスタンスを全機器共通の機器制御インタフェースサービスとしてサービス登録する。
【００８２】
そして、アプリケーションバンドル１８００は、機器制御処理を行う場合には、ＯＳＧｉフレームワーク１３００から機器制御インタフェースサービスを取得する（Ｓ４２１）。この時、サービス名として、「高級エアコン用の機器制御インタフェースサービス」を指定すれば、登録済みの高級エアコン用の機器制御インタフェースサービスを取得でき、「標準エアコン用の機器制御インタフェースサービス」を指定すれば、登録済みの標準エアコン用の機器制御インタフェースサービスを取得でき、「全機器共通の機器制御インタフェースサービス」を指定すれば、登録済みの全機器共通の機器制御インタフェースサービスを取得できる。
【００８３】
また、サービス取得の際に、Ｓ４２０でサービスプロパティとして登録した機器情報を使った検索式を渡すことで、所望の機器に対する機器制御インタフェースサービスを取得できる。例えば、機器ＩＤを指定したり、設置場所を指定したりすることができる。
【００８４】
アプリケーションバンドル１８００は、取得した機器制御インタフェースサービスに含まれる各種機器制御メソッドを使用して、機器制御要求処理を行う（Ｓ４２２）。機器制御メソッドの処理の中で、制御機器に対して、適切な機器制御要求データを送信する（Ｓ４２３）。
【００８５】
制御機器は、制御した結果に基づいて、機器制御応答データを送信する（Ｓ４２４）。この応答内容は、機器制御メソッドの呼び出し元であるアプリケーションバンドルに返される（Ｓ４２５）。このようにして、最終的に、アプリケーションバンドル１８００は、取得した機器制御インタフェースサービスに含まれる各種機器制御メソッドを使用して、実際の機器を制御することができる。
【００８６】
実際の制御の例として、例えば、全機器共通の機器制御インタフェースサービスを取得し、取得した全ての機器制御インタフェースサービスの電源ＯＮ／ＯＦＦ変更メソッドを呼んで、全ての機器を電源ＯＦＦするという制御処理を実現できる。また別の例として、「設定場所＝リビング」という検索式で標準エアコン用の機器制御インタフェースサービスを取得し、取得した全ての機器制御インタフェースサービスの設定温度変更メソッドを呼んで、リビングに設置された全てのエアコンの設定温度を高くするという制御処理を実現できる。
【００８７】
以上のような一連の処理を行うことで、通信装置１００上のアプリケーションは、簡単に柔軟な制御機器選択を行うことができ、また、簡単に様々な機器を制御することができる。よって、その開発量を低減することができる。
【００８８】
また、アプリケーションは、機器登録メソッドを呼びだすにあたって、取得したドライバ情報に加えて、例えば、「アプリケーションＩＤ」などの任意の情報を追加してもよい。これにより、アプリケーションが独自に追加した情報を機器情報インタフェースサービス及び機器制御インタフェースサービスのサービスプロパティとして追加することができる。その結果、アプリケーションが機器制御インタフェースサービスを選択するにあたって、アプリケーション独自の検索式を構成することができる。具体的には、複数のアプリケーションが機器を登録する場合に、自分の登録した機器だけを選択するなどができる。これにより、通信装置１００上のアプリケーションは、簡単に柔軟な制御機器選択を行うことができ、また、簡単に様々な機器を制御することができる。よって、その開発量を低減することができる。
【００８９】
図９は、通信装置１００のソフトウェアの処理フローを示す図である。本処理フローは、通信装置１００の外部の機器から、通信装置１００が公開するＨＴＴＰサーバ機能を介し、機器制御を行う時の処理フローである。なお、通信装置１００の外部機器とは、例えば、図１の表示端末２００やサーバ４などである。
【００９０】
まず、外部機器からアクセスがある前に、機器制御インタフェース変換クラスをＨＴＴＰサービスバンドルに対して登録しておく（Ｓ９０１）。
【００９１】
通信端末１００に接続された機器を制御したい外部機器は、機器制御要求であることを示す所定のＨＴＴＰリクエスト（図１０（ａ））を通信端末１００に対して送信する（Ｓ９０２）。当該ＨＴＴＰリクエストを受信したＨＴＴＰサービスバンドル１９００は、リクエストの内容に応じて、所定の機器制御インタフェース変換クラスを呼び出す（Ｓ９０３）。
【００９２】
この時、制御内容と制御パラメータと検索式を引数に取る。制御内容とは、機器制御インタフェースクラスが持つ機器制御用メソッドを特定する情報である。例えば、エアコン用の外部ＡＰＩサービスが提供する機器制御要求メソッドの場合、取り得る制御内容は、「モード変更」「設定温度変更」「電源ＯＮ／ＯＦＦ変更」を表す文字列である。制御パラメータは、制御内容が「モード変更」であれば、「冷房」「暖房」「除湿」などを表す文字列であり、制御内容が「電源ＯＮ／ＯＦＦ変更」であれば、「電源ＯＮ」「電源ＯＦＦ」を表す文字列である。検索式は、様々な機器情報を使用して検索条件を表す情報である。例えば、機器ＩＤを指定したり、設置場所を指定したりする。
【００９３】
機器制御インタフェース変換クラスの中では、ＯＳＧｉフレームワーク１３００から機器制御インタフェースサービスを取得する（Ｓ９０４）。この時、機器制御インタフェース変換クラスの呼び出しの引数で渡された検索式を、サービス取得時の検索式として利用する。そして、取得した機器制御インタフェースサービスに含まれる機器制御メソッドを呼ぶ（Ｓ９０５）。これは図５のＳ４２２の処理に相当し、図９では省略しているが、最終的にはデバイスドライババンドルの機器制御実装クラスの機器制御メソッドが呼ばれる。どの機器制御メソッドを呼ぶかは、機器制御要求メソッドの引数で渡された制御内容によって決め、機器制御メソッドの引数として渡す値は、機器制御要求メソッドの引数で渡された制御パラメータを使用する。
【００９４】
機器制御要求メソッドの処理の中で制御機器に対して機器制御要求データを送信し（Ｓ９０６）、制御機器は、制御した結果に基づいて、機器制御応答データを送信し（Ｓ９０７）、この応答内容は、機器制御メソッドの呼び出し元である機器制御インタフェース変換クラスに返される（Ｓ９０８）。Ｓ９０６からＳ９０８までの処理は、図５のＳ４２３からＳ４２５までの処理に相当する。機器制御応答を受信した機器制御インタフェース変換クラスは、ＨＴＴＰサービスバンドルに対して応答を返し（Ｓ９０９）、ＨＴＴＰサービスバンドルは外部機器に対してＨＴＴＰレスポンス（図１０（ｂ））を返す（Ｓ９１０）。
【００９５】
図１０は、表示端末２００などの外部機器から通信装置１００との間で送受信される要求（ａ）及び応答（ｂ）の一例である。
【００９６】
外部機器からの要求（ａ）は例えばＨＴＴＰリクエストとして構成し、どのような機器を制御するかの機器種別を示すＵＲＩ １００１、どのような制御を行うかを示す制御コマンド種別 １００２、制御の内容を示す制御パラメータ １００３、前記ＵＲＩ １００１で指定した機器種別のなかでさらに制御対象機器を絞り込むための検索式１００４を含む。
【００９７】
ＵＲＩ １００１は“／ａｐｉ／ｃｏｎｔｒｏｌ”や“／ａｐｉ／ｃｏｎｔｒｏｌ／ａｉｒｃｏｎ”のような形式で前記機器制御Ｉ／Ｆサービスの継承関係を反映した形で構成し、これを指定することは、前記機器制御Ｉ／Ｆサービスを指定することに該当し、検索式 １００４を指定することで、「設定場所＝リビング」のような指定を行い、１つの要求で複数の機器を同時に制御することも可能となる。
【００９８】
通信装置１００からの応答（ｂ）は、例えばＨＴＴＰレスポンスとして構成し、要求の結果は１０１１に示すようなＪＳＯＮ（ＪａｖａＳｃｒｉｐｔ  Ｏｂｊｅｃｔ  Ｎｏｔａｔｉｏｎ）データとして構成する。データには、複数のデバイスが含まれることを想定し、機器を識別する識別情報１０１２と、機器毎の制御結果１０１３を含む。
【００９９】
以上により、通信装置１００の外部機器からも、機器の接続形態やプロトコルによらない共通の呼び出し方法で機器制御が可能となり、また、例えば複数の機器を一度の要求で制御するなど、制御機器を簡単に柔軟に選択することができ、その開発量を低減することができる。
【０１００】
なお、機器制御インタフェース変換クラスが、どのような機器を制御するかの機器種別を示すＵＲＩと、どのような制御を行うかを示す制御コマンド種別と、制御の内容を示す制御パラメータと、制御対象機器を絞り込むための検索式を引数とするアプリケーション向けのＡＰＩを公開することで、通信装置１００内部のアプリケーションからも同様の方法で使用することができる。この場合、アプリケーションは、ユーザまたは外部機器から、前記どのような機器を制御するかの機器種別を示すＵＲＩと、どのような制御を行うかを示す制御コマンド種別と、制御の内容を示す制御パラメータと、制御対象機器を絞り込むための検索式とを受け取ることによって、新しい機器制御Ｉ／Ｆクラスが追加された場合も、アプリケーションを変更することなく機器の接続形態やプロトコルによらない共通の呼び出し方法で機器制御が可能となり、また、制御機器を簡単に柔軟に選択することができ、その開発量を低減することができる。
【０１０１】
なお、本発明は上記した各実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した各実施例は本発明を分かりやすく説明するために詳細に説明されたものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加・削除・置換をすることが可能である。
【０１０２】
また、上記の各構成、機能、処理部、処理手段等は、それらの一部または全部を、例えば集積回路で設計する等によりハードウェアで実現しても良い。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現しても良い。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Ｓｏｌｉｄ  Ｓｔａｔｅ  Ｄｒｉｖｅ）等の記録装置、または、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に置くことができる。
【０１０３】
また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えても良い。
【符号の説明】
【０１０４】
１００    通信装置
１１００  カーネル空間
１２００  Ｊａｖａ  ＶＭ
１３００  ＯＳＧｉフレームワーク
１４００  デバイスアクセスサービスバンドル
１５００  デバイスドライババンドル
１６００  機器管理バンドル
１７００  機器制御インタフェースバンドル
１８００  アプリケーションバンドル
１９００  ＨＴＴＰサービスバンドル
【図１】
2014130411.tif 000003
【図２】
2014130411.tif 000004
【図３】
2014130411.tif 000005
【図４】
2014130411.tif 000006
【図５】
2014130411.tif 000007
【図６】
2014130411.tif 000008
【図７】
2014130411.tif 000009
【図８】
2014130411.tif 000010
【図９】
2014130411.tif 000011
【図１０】
2014130411.tif 000012