JP5485946B2 - 仮想化ホームゲ−トウェイシステム - Google Patents

Description

本発明は、仮想化ホームゲ−トウェイシステムに係り、特に、機能を集中的に配置することで、システムの運用性及びメインテナンス性を向上したホームゲ−トウェイシステムに関する。

従来のホームゲ−トウェイでは、例えば特許文献１、非特許文献１、非特許文献２にあるように、宅内サービスを実行するために、アプリケーションソフトウェアを各家庭内に配置されるホームゲ−トウェイに配布し、ホームゲ−トウェイのＣＰＵおよびメモリを利用して実行する方式が提案されている。同様に大容量の記憶容量を有するホームサーバについても、ホームネットワーク内に配置することが提案されている。

特許第４５７５１７７号

北島茂樹、岩崎健人、「宅内機器向けサービス基盤システムへの取り組み」、日立評論、Ｖｏｌ．９０、Ｎｏ．０６、ｐｐ．４６−４９、２００８年６月 濱田卓志、大野千代 他、「ホームネットワークの技術開発」、日立評論、Ｖｏｌ．８９、Ｎｏ．０６、ｐｐ．４４−４７、２００７年６月

しかしこの方式では、各家庭に配置されたホームゲートウェイ及び、当該ホームゲ−トウェイ内のアプリケーションソフトウェアの管理が必要であり、また、当該アプリケーションの設計、動作においてはホームゲ−トウェイのハードウェア構成即ちＣＰＵ能力やメモリ量により制約があった。
また、大容量の記憶容量を有するホームサーバを、ホームネットワーク内に配置する場合、これら記憶デバイスの容量制約があり、またデバイスの管理もユーザ任せとなることから、データ保存の信頼性を確保することが困難であった。
加えて、各家庭に配置されたセンサなどは、単一のサービス事業者と対応することが想定されており、類似のサービスを複数の事業者から提供を受ける場合には、類似のセンサなどを家庭内に重複して配置する必要があった。
また、宅内に設置したホームゲ−トウェイに接続されたホームネットワーク内を対象としたアプリケーションとなるため、複数のホームネットワークを単一のホームネットワークとして扱うことが困難であった。
本発明は、以上の点に鑑み、ホームネットワークに配置される機器及びセンサを用いてユーザに新たなサービスを提供する事業者が、既存の機器及びセンサを有効活用してサービスを提供することが可能な仮想化ホームゲ−トウェイシステムを提供することを目的とする。

上記課題を解決するため、本発明では、例えば広域ネットワークに接続されたホームゲ−トウェイ配下のホームネットワークに接続された各種センサ、機器の制御、情報収集、プロトコル変換などを行うソフトウェア実行環境を、広域ネットワークを介して接続されたサーバ内に仮想実行環境として集合的に配置することでホームゲ−トウェイ機能内のアプリケーションソフトウェアの管理を容易にし、且つホームゲ−トウェイによるハードウェア制約をなくすることを特徴のひとつとする。
また、各ホームネットワークに接続された各種センサ、機器に対し、複数のサービス事業者の異なるサービスの対応が管理できる機能を有する。これにより、サービス提供事業者毎に類似のセンサなどを配置することを不要とし、センサなどからの取得情報の共有化を図る。また、新規サービス事業者の参入可能性を拡大できる。また、重複するセンサデータ取得を削減することができ通信トラフィックの削減が可能であることを特徴のひとつとする。
また、本発明では、広域ネットワークを介して接続されたサーバ内の一つの仮想実行環境に複数のオペレーティングシステムを実行可能とすることで、異なるアプリケーション配信プラットフォームへの対応を可能とし、また、旧ＯＳ環境でのみ動作するアプリケーションの実行を可能とし、アプリケーション提供事業者のアプリケーション更新時期のずれがあった場合にもエンドユーザに対しアプリケーションを提供可能とすることを特徴のひとつとする。
また、本発明ではセンタ側に各ホームネットワークに接続されたユーザ、各種センサ、機器と、サービス事業者の提供するサービス対応を管理する機能を有することで、サービス提供事業者に対しサービス提供状況のレポート作成をする機能を有し、またサービス提供事業者およびその他の事業者に対し、ユーザの利用状況などを統計情報として提供可能とすることを特徴のひとつとする。

本発明の解決手段によると、
ひとつ又は複数の第１の事業者により配布され各ホームネットワークに接続された機器及びセンサの制御、情報収集、プロトコル変換のいずれか又は複数を行う仮想ホームゲートウェイを集合的に配置し、複数のホームネットワークに接続された仮想化ホームゲートウェイサーバと、
各ホームネットワークに接続された前記機器及びセンサの種別と、配布元の第１の事業者の識別情報が記憶された機器データベースと、
第２の事業者が、第１の事業者の前記機器及びセンサのデータを利用することによる課金情報を記憶する事業者課金データベースと、
所望の機器及びセンサの種別を含む第２の事業者からの機器使用要求に対し、前記機器データベースを参照して、該所望の機器及びセンサに該当する第１の事業者の前記機器及びセンサを特定する管理部と
を備え、
前記管理部は、
特定された第１の事業者の前記機器及びセンサのデータを利用した第２の事業者によるサービスに対するユーザからの加入要求を入力し、
第１の事業者を請求元とし、第２の事業者を請求先とした課金情報を、前記事業者課金データベースに記憶する仮想化ホームゲートウェイシステムが提供される。

本発明によると、ホームネットワークに配置される機器及びセンサを用いてユーザに新たなサービスを提供する事業者が、第一の事業者により配備された既存の機器及びセンサを有効活用してサービスを提供することが可能な仮想化ホームゲ−トウェイシステムを提供することができる。

複数のサービス事業者によるサービス提供を容易にするシステムの概念図。 サービス管理部の構成例。 ＨＧＷ−ＶＭとＨＧＷ−ＩＦ部の構成例。 サービス管理部のフロー例。 サービス管理部のアプリ更新フロー例。 加入者データベースの構成例（１）。 加入者データベースの構成例（２）。 機器・センサデータベースの例。 サービスデータベースの例。 課金データベースの例。 共有データベースの例。 サービス間のセンサ共用ビジネスモデルの例（１）。 他の事業者の機器・センサを利用したサービス提供までのサービス管理部フロー例（１）。 他の事業者の機器・センサを利用したサービス提供までのサービス管理部フロー例（２）。 他の事業者への利用候補機器・センサリスト提供のサービス管理部フロー例。 利用可能機器・センサファイルの例。 サービス提供可能者ファイルの例。 サービス間のセンサ共用ビジネスモデルの例（２）。 事業者課金データベースの構成例。

図１は、本実施の形態の仮想化ホームゲ−トウェイシステムの一実施例を示すブロック構成図である。このシステムは、仮想化ホームゲ−トウェイサーバ１と、仮想化ホームゲートウェイインタフェース部（ＨＧＷ−ＩＦ部）２と、ホームネットワーク３と、各種家庭内機器・センサ類４と、広域ネットワーク５と、複数のサービス事業者の装置６と、サービス管理部１０とから構成されている。
仮想ホームゲートウェイサーバ１の内の仮想マシンＶＭ７は広域ネットワーク５を介して、各家庭・事務所などに配置された仮想化ホームゲートウェイインタフェース部２と接続されている。仮想マシンＶＭ７と、仮想化ホームゲートウェイインタフェース部２はサービス実行時には１対１に対応している。また、仮想化ホームゲートウェイインタフェース部２には、ホームネットワーク３を介して各種家庭内機器・センサ類４が接続されている。
仮想化ホームゲートウェイサーバ１は、仮想化ゲートウェイのアプリケーションを実行するためのＣＰＵ、メモリと外部記憶装置とを備え、仮想化ホームゲートウェイサーバ１は、ホームゲートウェイの実行環境である仮想マシンＶＭ７を複数同時に実行可能となっている。
サービス提供事業者の装置６は、ユーザ要求に応じて、サービスセンタ８内の仮想マシンＶＭ７に対してアプリケーションの配布及び管理を行い、仮想マシンＶＭ７でのアプリケーションの実行を可能とする。この際、サービス管理部１０はアプリケーションの配布管理を行う。
仮想化ホームゲートウェイインタフェース部２と仮想マシンＶＭ７は広域ネットワーク５を介して接続されている。この際、広域ネットワーク５において仮想化ホームゲートウェイインタフェース部２と仮想マシンＶＭ７の対応関係を明らかにするには、広域ネットワーク５にポイントツーポイントＰＰＰを利用し両者を接続することや、ＩＰｓｅｃによりトンネリングをすることなどを用いることができる。
ホームネットワーク３内の機器４ａ（例えば携帯端末）から同一ホームネットワーク３内の機器４に対して制御を行う場合、機器４ａの制御コマンドは、ホームネットワーク３を経由し、仮想化ホームゲートウェイインタフェース部２に送られ、仮想マシンＶＭ７上のアプリケーションによって処理された後、逆のルートをたどり機器４ｂに送られ制御がされる。ホームネットワーク３は単一のネットワークとして構成される場合もあるが、複数のプロトコル、インタフェースの異なるネットワークで構成される場合もある。なお、このアプリケーションによる処理には、制御演算、プロトコル変換、アドレス変換などが含まれる。

図２は、本実施の形態のサービス管理部１０を詳細化した構成例である。
サービス管理部１０は、例えば、ＣＰＵ（管理部）２０１、メモリ２０２、外部記憶装置２０３及びインタフェース部２０４を有する。メモリ２０２にはソフトウェアが記憶され、ＣＰＵ２０１に読み出されて実行される。インタフェース部を介して、加入者データベース２２１、機器・センサデータベース（機器データベース）２２２、サービスデータベース２２３、課金データベース２３１及び共有データベースが接続されている。課金データベース２３１は、加入者課金データベース２３１−１と事業者課金データベース２３１−２を含む。また、インタフェース部を介してサービス事業者の装置６及び、ホームゲートウェイサーバ１と接続されている。なお、各データベースは、ひとつ又は複数の記憶装置で構成されてもよいし、外部記憶装置２０３に備えられても良い。各データベースの構成は後述する。
図３に示すように、仮想化ホームゲートウェイインタフェース部２には、例えば、ホームネットワーク３に接続するためのインタフェースであるＥｔｈｅｒネットドライバ、ＵＳＢドライバおよび両者のハードウェアのほか、音声インタフェースを行うためのサウンドドライバ及び音声発生装置が実装されている。また、ＩＰ電話のための音声コーデック及びプロトコル処理を行う機能、ＳＩＰのプロトコルスタック、広域ネットワーク５とのインタフェース部、及び、全体の制御を行う共通制御部を有する。
仮想ホームゲートウェイサーバ１は、例えば、ＣＰＵ、メモリ、記憶装置及びインタフェース部を有する。仮想ホームゲートウェイサーバ１は複数の仮想マシンＶＭ７を実行可能であり、それぞれの仮想マシンＶＭ７は、広域ネットワーク５を介して仮想化ホームゲートウェイインタフェース部２との接続を行うインタフェース部、仮想マシンＯＳ、ＯＳＧｉフレームワーク、アプリケーション及び管理部より構成されている。各機能を実現するためのソフトウェアが例えばメモリや記憶装置に記憶され、ＣＰＵにより読み出されて実行される。
管理センタ８（本実施の形態においてサービスセンタと称する場合もある）は、仮想ホームゲートウェイサーバ１と、サービス管理部１０とを有する。サービス管理部１０は、仮想マシンＶＭ７へのアプリケーションの配布管理を行い、各ユーザの仮想マシンＶＭ７に対しどのアプリケーションがインストールされているか、バージョンの管理などを行う。ＶＭ管理部は仮想ホームゲートウェイサーバ１内の仮想マシンＶＭ７の管理を実施する。

図６は、加入者データベース２２１の構成の一例である。
本例では、加入者識別子をキーとして、当該加入者のＨＧＷアドレス、ホームネットワーク接続機器情報（接続ハードウェア情報）、導入済アプリケーション情報が記憶される。また、接続ハードウェアのデータなどの他の事業者への情報開示の可否の情報も含むことが出来る。ここでの加入者（ユーザ）は、ホームゲートウェイインタフェース部２が設置される家庭・事業所に対応する。ホームネットワーク接続機器情報は、加入者に対応するホームゲートウェイインタフェース部２が管理するホームネットワークに接続されるひとつ又は複数の機器の情報であり、例えば、機種情報（機器及びセンサの識別情報）、機器アドレス及び機器種別を含む。機種情報は例えば配布元の事業者、及び、機器及びセンサの種別を特定可能なものを用いることが出来る。導入済アプリケーション情報は、例えば、機器用アプリケーション名、機器用アプリケーションのバージョン情報及び課金情報を含む。導入済アプリケーション情報は、ホームネットワーク接続機器情報に対して複数記憶されてもよい。各データベースは、各エントリに対しエントリ番号（Ｎｏ）が割り当てられてもよい。
図７は、加入者データベース２２１の他の構成例である。
本例も図６と同様に加入者識別子をキーに、例えば、当該加入者のＨＧＷアドレス、機器情報、ホームゲートウェイのインタフェース情報などを記憶するものであり、機器の管理などの利用を想定している。機器情報は、例えば、ホームゲートウェイの機種情報と、ホームゲートウェイのシリアル番号と、ファームウェアのバージョン情報とを含む。
なお、図６及び図７は独立にデータベースとすることも可能であるし、一つのデータベースとすることも可能である。

図８は、機器・センサデータベース２２２の一例である。
本データベースは、複数の事業者において機器・センサのデータを共有したサービスを実施可能とするためのものであり、機器・センサの目的、機能、性能、利用者数、他事業者の利用可否、利用形態及び他事業者利用時の料金などで構成される。例えば、機器・センサデータベース２２２は、加入者に提供するサービスの分類情報と、サービスを提供する事業者識別子と、機器・センサの識別記号と、機器・センサの機能又は名称と、機器・センサの性能情報と、利用者数と、他事業者の利用可否情報と、他事業者の利用形態情報と、他事業者利用時の料金情報とを含む。
性能情報は、例えば、センサの測定対象、測定可能範囲、精度、機器の機能などが記憶される。利用者数は、例えば、分類情報に対応するサービスの利用者数、又は、機能情報に記憶された機器・センサの配布数である。他社利用形態は、例えばＡ事業者の配布したセンサのデータをＣ事業者が共有する形態を示す。独自アクセスでは、例えばＡ事業者、Ｃ事業者それぞれが、独自のタイミングでユーザデータを取得する（実際にはアプリが取得し、アップすることができる）。これに対し、データ共有では、例えば、Ａ事業者の取得したデータを後述する一時ファイルに置き、Ｃ事業者がデータを利用する。他事業者利用時の料金情報は、例えば、機器・センサを他事業者が利用した場合の料金を示し、例えば、機器・センサ１つあたりの料金など機器あたりの料金及び１月あたりの料金など期間あたりの料金が記憶される。

図９は、サービスデータベース２２３の一例である。
本データベースは、例えば、サービスを提供する事業者識別子とサービス名に対応して、サービスが利用するアプリケーションの名称、最新バーション情報、アプリケーションファイル名（ファイルの格納場所の特定情報を含んでも良い）、利用する機器・センサの識別記号、情報取得頻度、及び、利用料を含む。これらの各情報は、例えばサービス提供開始時などに適宜登録される。
図１０は、加入者課金データベース２３１−１の一例である。
加入者課金データベース２３１−１は、加入者識別子をキーに、当該加入者が加入しているひとつ又は複数の加入サービス情報と料金合計を含む。加入サービス情報は、例えばサービス提供事業者の識別子、サービス名及び料金情報を含む。これらの他に課金の方法、支払い状況などを追加することも可能である。これらの各情報は、例えばサービスへの加入時に記憶されることができる。
図１９は、事業者課金データベース２３１−２の一例である。
事業者課金データベース２３１−２は、例えば、ある事業者が他の事業者の機器及びセンサを利用してサービスを提供する場合に、事業者間で利用料を精算するためのデータベースである。
事業者課金データベース２３１−２は、例えば、請求先の事業者識別子（例えば事業者Ｃ）と、サービス名と、請求元の事業者識別子（例えば事業者Ａ、Ｂなど）と、当該サービスへの加入者数と、合計請求額とが記憶される。請求先の事業者は、他の事業者の機器及びセンサを利用してサービスを提供する事業者（第２の事業者）である。請求元の事業者は、自らが配布した機器及びセンサを使用させている事業者（第１の事業者）である。単価は、図８の他社利用料金に相当する。合計請求額は、例えば単価と加入者数により求められる。例えば加入者数が、対応するサービスへの利用受付毎に更新され、合計請求額が更新される。また、加入者毎に利用開始日を記憶すれば例えば日割り計算する場合に利用できる。

図１１は、共有データベース２４１の一例である。
本データベースは、ホームサーバ機能として加入者が写真などのデータをＨＧＷを通じて保存、管理する場合に利用される。このため、データベースの構成としては加入者毎に、ファイル名、サイズ、作成日、更新日などを含むひとつ又は複数のファイル情報が記憶される。サービスセンタ８に本データベースを設置することにより、加入者宅内機器による容量制限を受けない。サービス提供者は、バックアップなど適切な管理をすることにより高信頼なデータ保管環境を加入者に提供できる。
図４は、本実施の形態による新たなサービス受付の実施フロー例である。
手順４０１の利用受付はＷｅｂ、Ｍａｉｌ、電話、郵便など様々な手段で実施可能である。例えば、サービス管理部１０は、加入者からある事業者のサービス利用開始の申請を受け付ける。サービス利用開始の申請は、例えば、加入者識別子と、サービスを提供する事業者識別子と、サービス名を含む。Ｗｅｂやメールを用いる場合、サービス管理部１０は利用開始申請を受信してこれらの情報を抽出する。電話や郵便を用いる場合、オペレータの操作により入力部を介してこれらの情報を入力する。申請があると、手順４０２のサービスアプリ抽出によりサービスデータベース２２３から、当該サービスの実行に必要なアプリケーションファイルが抽出される。例えば、サービス管理部１０は、利用開始の申請に含まれる事業者識別子とサービス名に基づき、サービスデータベース２２３を参照し、対応するアプリケーションファイルを抽出する。また、対応するアプリケーション名、最新バージョン情報、センサ・機器情報、利用料情報等を抽出する。手順４０３により利用申込を行った当該加入者の当該仮想マシンＶＭ７に対し、サービス管理部１０は、抽出されたサービスアプリケーションを配布する。配布されたアプリケーションは、手順４０４により配布が確実に実施されたことが確認された後、手順４０５により実行されサービス提供が開始される。
サービス提供開始を受け、サービス管理部１０は、手順４０６により加入者情報のデータベース２２１に当該サービスを利用していることが登録される。例えば、サービス管理部１０は、加入者識別子とセンサ・機器情報（ホームネットワーク接続機器情報）に対応して、アプリケーション情報を記憶する。アプリケーション情報は、例えば、手順４０３でサービスデータベース２２３から取得されたアプリケーション名と、最新バージョン情報と、利用料金情報に基づく課金情報とを含む。その後、手順４０７により課金データベース２３１にも当該加入者が当該サービスの利用が登録され、課金に必要な情報が生成される。例えば、サービス管理部１０は、加入者課金データベース２３１−１に、加入者識別子に対応して、サービスを提供する事業者識別子と、サービス名と、料金情報（上述の利用料情報）とを記憶する。なお、説明の便宜上、手順４０４から手順４０７はアプリケーション配布確認から課金情報更新までの一連の手順として手順４２０と定義する。

図５は、サービス提供事業者６から、アプリケーションの更新要請があった場合の手順である。
手順５０１においてサービス提供事業者６からＷｅｂ、Ｍａｉｌなどの手段によりアプリケーション更新の申し出があった場合、当該サービス事業者からの最新のアプリケーションファイルをサービスデータベース２２３上に書き込む。例えば、サービス管理部１０は、サービス提供事業者の装置６から、アプリケーション名、最新バージョン情報、アプリケーションファイルを含むアプリケーション更新指示を受信する。サービス管理部１０は、サービスデータベース２２３上の更新対象のアプリケーション名に対応するアプリケーションファイルを上書きする。また、最新バージョン情報も更新する。
手順５０２において、サービス管理部１０は、加入者データベース２２１から当該アプリケーションの更新が必要な加入者を抽出する。例えば、アプリケーション更新指示に含まれるアプリケーション名が記憶された加入者の加入者識別子を抽出する。手順５０３では更新された当該アプリケーションファイルの抽出が行われる。例えば、サービス管理部１０は、アプリケーション名に基づきサービスデータベース２２３を参照し、対応するアプリケーションファイルを抽出する。また、事業者識別子、サービス名も抽出する。手順５０４において、サービス管理部１０は当該加入者の仮想マシンＶＭ７に対して新バージョンのアプリケーションを配布する。この後、上記の通り定義された手順４２０に従いアプリケーションの配布確認、サービス提供開始、加入者データベース２２２の更新、課金データベース２３１の更新が行われる。手順５０５により、全ての対象者が更新されたかの確認が行われ、対象者に残りが有る場合は手順５０２に戻り、次の対象者の更新を行う。また、全ての対象者が更新完了した場合には終了する。

次に、複数のサービス提供事業者６によるサービス提供を容易にする実施例の動作を以下説明する。図１及び上述の様にサービスセンタ８には、複数のサービス事業者６のサービス提供内容、ユーザのホームネットワーク３に接続された機器／センサ４の情報、ユーザ毎のアプリケーション対応状況などを把握するサービス管理部１０が存在する。サービス管理部１０は、仮想サーバ１内のそれぞれ仮想化ホームゲートウェイインタフェース部２の対応する仮想マシンＶＭ７に対して機器／センサ４の情報、ユーザ毎のアプリケーション対応状況の把握、管理を行っている。
サービス事業者６が新たなサービスを展開する場合、各ホームネットワーク３に新たな機器／センサを配置する必要があるが、既に類似センサを利用した他のサービスを提供している事業者が存在する場合、新たなサービス事業者は既に配置した機器／センサを利用したサービス提供を実施することで、設備投資の削減を図ることができ、また、機器／センサからの情報収集を共通化することにより、通信トラフィックの削減が可能となる。
図１２は、上記サービスを行う上で、サービス事業者Ａの投資により配布したセンサの情報を、サービス事業者Ｂが利用することにより新たなサービスを実施した場合に、サービス事業者Ｂが適切なセンサ利用対価をサービス事業者Ａに支払う仕組みを構築した例である。まず、サービスの全体像を説明し、後に各装置の処理を説明する。
例えばサービス事業者Ａの投資により加入者に配布し、ホームネットワーク内に設置されたセンサの情報を、サービス事業者Ｂが利用した頻度、量などに応じてサービス事業者間の利用料の請求、支払いを可能とした例である。
ユーザＸは、サービス事業者Ａからセンサ（例．血圧計）の配布を受け、情報をサービス事業者Ａに提供することによって、所定のサービス（例．健康管理）を受け、ユーザＸはサービス提供事業者Ａに対し対価を支払っている。
ユーザＸが、新たにサービス提供事業者Ｂから付加価値サービス（例．食事指導）を受ける場合、サービス提供事業者Ａが配布したセンサ（例．血圧計）を利用したデータをサービス提供事業者Ｂに提供し付加価値サービス（例．食事指導）を受け、サービス提供対価をサービス提供事業者Ｂに支払う。
サービス管理部１０では、サービス提供事業者Ｂが利用した、サービス提供事業者Ａに帰属するセンサの利用料に応じて、センサ利用料の請求及び支払いを実施する。
本機能により、サービス提供事業者はサービス事業への参入が容易となる。また、ユーザは同種のセンサなどを複数配置する必要がなくなる。機器及びセンサを配布した事業者は、配布の際の投資を回収する機会を得る。加えて、複数のサービス提供事業者が、取得したセンサ情報の交換を実施可能とした場合には、ユーザは複数回の同一内容の情報伝送の必要がなくなり、通信トラフィックの節減が期待できる。

図１３はサービス管理部１０による他の事業者の機器・センサを利用し、ある事業者がサービスを開始するまでのフローの例である。
本フローの処理を開始する前に、ある事業者（本例では事業者Ｃ）は、既に配布されている機器・センサを利用したサービスを実施したい旨をサービスセンタ８に何らかの手段で通知している。
手順１３０１で事業者Ｃのサービス提供に必要な機器・センサの要求仕様が登録される。この要求仕様は、例えば機器・センサの仕様を含む。例えば、機器・センサの種別（例、血圧計又は血圧）を含む。また、機器及びセンサの性能（例、要求測定範囲、要求精度）を含んでもよい。サービス管理部１０は、例えば、事業者Ｃの装置６から本要求を受信してもよいし、郵送等で通知された場合には、操作者に操作により本要求を入力部から入力してもよい。
本情報に基づき、機器・センサデータベース２２２から利用可能な機器・センサを抽出する。具体的には、サービス管理部１０は、手順１３０２で機器・センサを最初から順にチェックできるように機器番号を初期値０に設定し、手順１３０３で機器番号に１を加える。手順１３０４で、サービス管理部１０は、機器・センサデータベース２２２と手順１３０１で得た要求との比較を行い、利用可能であれば、手順１３０５に進み、利用可能でない場合は手順１３０３に戻り機器番号に１を加え次の機器のチェックにス進む。より具体的には、サービス管理部１０は、設定した機器番号に対応するセンサデータベース２２２のエントリを参照し、該エントリに記憶された機器・センサの識別記号、機器センサの機能又は名称、機器・センサの性能情報に基づき、機器・センサの使用要求を満たす（利用可能である）か判断し、判断結果に応じて手順１３０５、手順１３０３に移る。なお、本例では機器・センサの仕様の他、機器・センサ配布事業者の指定する他者利用可否も判断材料としている。例えば、該エントリに記憶された他者利用可否情報が「否」の場合、機器・センサの使用要求を満たすかどうかに関わらず利用不可と判断して手順１３０３に戻る。
手順１３０５では事業者Ｃが利用可能な機器・センサのリスト１３０７を生成する。図１６に利用可能機器・センサファイル１３０７の例を示す。本例では、機器・センサデータベース２２２の各機器に、項目１６０１事業者Ｃ利用適否のフラグを追加することで構成されている。これ以外にも適宜の形態で利用可能機器・センサファイル１３０７を作成してもよい。機器・センサデータベース２２２に記憶されている全ての機器・センサについて処理していなければ手順１３０３に戻り、全ての機器・センサについて処理が終わると手順１３１０に移る。
手順１３１０では、上記手順で抽出された機器・センサ（図１６の例では、事業者Ｃ利用適否フラグが「適」となっている機器及びセンサ）の名称、記号などを抽出し、手順１３１１から手順１３１６において加入者データベース２２１から、当該機器を利用している加入者を抽出し、サービス提供可能者ファイル１３１５を生成する。より具体的には、サービス管理部１０は、例えば利用可能機器・センサファイル１３０７から、事業者Ｃが利用可能と判断された機器・センサの識別記号を抽出する。また、手順１３０２、手順１３０３と同様に、サービス管理部１０は手順１３１１で加入者番号を初期値０に設定し、手順１３１２で加入者番号に１を加える。手順１３１３では、サービス管理部１０は、設定した加入者番号に対応する加入者データベース２２１のエントリを参照し、該エントリの機器情報に、抽出された識別記号が存在するか判断する。存在すれば、サービス管理部１０はサービス提供可能者ファイル１３１５に当該加入者を登録する。

図１７にサービス提供可能者ファイル１３１５の一例を示す。本例では加入者データベース２２１の各加入者に対し、項目１７０１のＣ事業者利用適否フラグを追加して構成している。これ以外にも適宜の形態でサービス提供可能者ファイル１３１５を作成してもよい。加入者データベース２２１に記憶されている全ての加入者について処理していなければ手順１３１２に戻り、全ての加入者について処理が終わると手順１３２１に移る。
手順１３２１から手順１３２５ではサービス提供可能者ファイル１３１５の全てに対し、サービス利用勧誘を行う手順である。例えば、サービス管理部１０は、サービス提供可能者ファイル１３１５の事業者Ｃ利用適否情報が「適」である各ユーザを抽出し（手順１３２３）、各ユーザにサービス利用勧誘（案内情報）を送信する。本例では対象者に対し、手順１３２６でｅ−Ｍａｉｌによる勧誘を行っている。また、リストを取得しダイレクトメールなど他の手段での勧誘も可能である。なお、ユーザに対応して、送信先のメールアドレス、ダイレクトメールの宛先を予め記憶されておくことができる。
勧誘を受けた加入者は、その意志により利用申込を実施し、申込は手順１３２７にて受理される。申込が受理されてから、サービス開始までのフローは図４と同様である。
次に、事業者Ａ、Ｂの機器・センサのデータを使用する事業者Ｃへのデータの配信や、事業者Ｃから事業者Ａ、Ｂへの利用料支払い（事業者間の課金）の処理について説明する。
サービス管理部１０は、図１３の処理で特定された利用可能機器・センサの情報と、事業者Ｃが新たに提供するサービス名を、事業者識別子に対応してサービスデータベース２２３に記憶する。例えば同一サービスで異なる事業者センサを活用できる場合、それぞれ別々のエントリとして記憶する。この場合、サービス名に枝番をつけることで、その後のユーザ課金などの処理がスムーズになる。アプリケーション名、最新バージョン、アプリケーションファイル、頻度情報、利用料などは、サービス提供事業者の装置６から適宜に登録されることができる。加入者からの利用申込に対し、上述のように図４と同様の処理が実行され、加入者の仮想マシンＶＭ７に対しアプリケーションが配布される。そのアプリケーションが、例えば事業者Ａの機器・センサのデータを利用する。どの事業者のどの機器・センサを利用するかは、例えばサービスデータベース２２３を参照して特定されることができる。
また、加入者からの利用申込に対し、サービス管理部１０は、事業者課金データベース２３１−２を更新する。例えば、ここでの加入者からの利用申込は、加入者識別子とサービス提供元の事業者識別子（ここでは事業者Ｃ）とサービス名の他、使用する機器・センサの事業者識別子（例えば、事業者Ａ又はＢ）を含む。サービス管理部１０は、サービス提供元の事業者識別子、サービス名、使用する機器・センサの事業者識別子に基づき、事業者課金データベース２３１−２の請求先事業者情報、サービス名、請求元事業者情報を参照し、該当するエントリの加入者数を１増加させる。これにより、合計請求額も更新できる。
なお、該当するエントリがない場合、サービス管理部１０は、サービス提供元の事業者識別子、サービス名、使用する機器・センサの事業者識別子を、事業者課金データベース２３１−２の請求先事業者情報、サービス名、請求元事業者情報に記憶し、加入者数を１にする。また、事業者課金データベース２３１−２の単価は、サービス提供元の事業者識別子と、図１３の処理で特定された利用可能機器・センサの情報とに基づき、機器・センサデータベース２２２を参照して、対応する他社利用料金を記憶する。

（特定事業者の機器・センサの活用）
図１４は、ある事業者（この例では事業者Ａ）が、同社が配布した機器・センサの活用を他の事業者に行う場合のフロー例である。
本フローの処理開始以前に、事業者Ａはサービスセンタ８に対し自社配布機器・センサの他社活用を検討するよう申し込んでいる。また、対象事業者（本例では事業者Ｃ）も他社の機器・センサの活用をサービスセンタ８に申し込んでいるものとする。本フローでは事業者毎にＡ事業者の機器・センサ活用可否をチェックし、加入者に対する勧誘までを行う。図１３のフローとの差異は、機器・センサデータベース２２２から、Ｃ事業者要求とのマッチを検討する前に、手順１４０４において事業者Ａの機器・センサの情報のみをフィルタして出力した点である。他の処理は、図１３のフローと同様である。
この様な方法で、事業者Ａは他の事業者に対し、自社が配布した機器・センサの利用を拡大することが出来る。

（利用可能な機器・センサの情報の推薦）
図１５は、サービスセンタ８が事業者に対して他の事業者が配布した機器・センサから、その事業者（本例では事業者Ｃ）が事業に利用可能な機器・センサの情報を抽出し、推薦するフロー例である。
本フロー例では、手順１５０１により推薦の要求があるものとしている。この推薦要求は、新たなサービス開始を検討している事業者の装置６（例えば事業者Ｃの装置）から受信する場合も考えられるし、サービスセンタ８のオペレータの操作により入力部から入力するが行う場合もある。本要求は、例えば推薦先の事業者識別子（ここでは事業者Ｃ）を含む。
手順１５０２から手順１５０７は、上述のフローと同様である。本手順による出力の利用可能機器・センサファイル１３０７は手順１５１０にて事業者Ｃに提示可能な情報のみに加工される。例えば、事業者Ｃ利用適否フラグが「適」を示すエントリのみ抽出される。また、利用可能機器・センサファイル１３０７の各情報のうち、提示可能な情報が予め定められても良い。提示可能な情報は、例えば機器及びセンサを配布する事業者毎に異なっても良い。提示可能な情報は手順１５１１にて推薦先の事業者Ｃに提示される。本提示の形態はオンラインでも、オフラインでも良い。
事業者Ｃは上記提示内容に興味があった場合には、新たに事業機会を得ることになる。その後、例えば図１３に示すように事業者Ｃから機器要求が送信される。

（変形例）
図１８は、データ取得の他の形態である。図１８の実施例では、ユーザＸのセンサデータの取得を事業者Ａが行うと、そのデータは一時ファイル１８０１に一時保存される。一時ファイル１８０１は、例えばサービス管理部１０に備えられることが出来る。事業者ＢはユーザＸのセンサデータを再度取得することなく、一時ファイル１８０１から取得することが出来る。従って、ユーザＸは１回のみの利用で複数の事業者にデータを提供できることとなり、測定に時間がかかるデータや、ユーザ負担の大きいデータ取得の場合有効である。また通信回線の利用頻度も下がるため、トラフィック削減にも効果がある。他の処理は、上述と同様である。
一時ファイルは、当該データを利用している事業者のデータ収集が終了した段階で消去することで、一時ファイルの容量削減でき、また情報漏えいの対策ともなる。
なお、本実施の形態ではセンタ側に各ホームネットワークに接続されたユーザ、各種センサ、機器と、サービス事業者の提供するサービス対応を管理する機能を利用し、サービス提供事業者に対しサービス提供状況のレポート作成をする機能を有してもよい。また、サービス提供事業者およびその他の事業者に対し、ユーザの利用状況などを統計情報として提供可能としてもよい。
本実施の形態によると、ホームゲ−トウェイのアプリケーション実行環境を広域ネットワークを介して接続されたサーバ内に仮想実行環境として集合的に配置しているため、アプリケーションの配布管理が容易となる。また、仮想実行環境を利用しているためホームゲ−トウェイのＣＰＵ能力やメモリ容量の制約をうけることがないという利点がある。
また、本実施の形態では、サーバ内の一つの仮想実行環境に複数のオペレーティングシステムを実行可能とすることで、異なるアプリケーション配信プラットフォームへの対応が可能となるため、アプリケーション選択の幅を広げることができ、サービス事業者の参入機会拡大、ユーザの利便性向上に役立つという利点がある。また、異なるバージョンのＯＳを同時に稼動可能とした場合、旧ＯＳ環境でのみ動作するアプリケーションの利用が可能となり、ＯＳ更新と、アプリケーション提供事業者のアプリケーション更新時期のずれがあった場合にもエンドユーザに対しアプリケーションを継続して提供可能とすることができるという利点がある。

また、本実施の形態ではセンタ側に各ホームネットワークに接続されたユーザ、各種センサ、機器と、サービス事業者の提供するサービス対応を管理する機能を有することで、サービス提供事業者は、サービス提供状況のレポートを取得することが可能となりサービス利用の実態が把握できるという利点がある。またサービス提供事業者およびその他の事業者に対し、ユーザの利用状況などを統計情報として提供可能とすることによって、新たに市場参入を計画するものや、市場開拓をしようとするものに対して有効な情報提供が可能になるという利点を有する。
また、各ホームネットワークに接続された各種センサ、機器に対し、複数のサービス事業者の異なるサービスの対応が管理できる機能を有することで、サービス提供事業者毎に類似のセンサなどの重複配置を不要とし、サービス事業者の設備投資を削減できるという利点がある。また、センサからの取得情報の共有化を図ることによって、新規サービス事業者の参入可能性を拡大し、重複するセンサデータ取得を削減することによって、通信トラフィックの削減が可能になるという利点を有する。

本発明は、例えば、ホームネットワークを提供するホームネットワークシステムにおいて、ユーザ宅内に配置されるホームゲ−トウェイのアプリケーション実行機能などをセンタ側に集中して設置するシステムに利用可能である。

１ 仮想化ホームゲートウェイサーバ
２ 仮想化ホームゲートウェイインタフェース部
３ ホームネットワーク
４ 各種家庭内機器・センサ類
５ 広域ネットワーク
６ 複数のサービス事業者
７ 仮想マシンＶＭ
８ 管理センタ
９ 記憶装置
１０ サービス管理部

Claims (9)

1. ひとつ又は複数の第１の事業者により配布され各ホームネットワークに接続された機器及びセンサの制御、情報収集、プロトコル変換のいずれか又は複数を行う仮想ホームゲートウェイを集合的に配置し、複数のホームネットワークに接続された仮想化ホームゲートウェイサーバと、
   各ホームネットワークに接続された前記機器及びセンサの種別と、配布元の第１の事業者の識別情報が記憶された機器データベースと、
   第２の事業者が、第１の事業者の前記機器及びセンサのデータを利用することによる課金情報を記憶する事業者課金データベースと、
   所望の機器及びセンサの種別を含む第２の事業者からの機器使用要求に対し、前記機器データベースを参照して、該所望の機器及びセンサに該当する第１の事業者の前記機器及びセンサを特定する管理部と
   を備え、
   前記管理部は、
   特定された第１の事業者の前記機器及びセンサのデータを利用した第２の事業者によるサービスに対するユーザからの加入要求を入力し、
   第１の事業者を請求元とし、第２の事業者を請求先とした課金情報を、前記事業者課金データベースに記憶する仮想化ホームゲートウェイシステム。
2. 前記機器データベースは、第１の事業者の識別情報と、前記機器及びセンサの種別とに対応して、他事業者利用可否情報がさらに記憶され、
   前記管理部は、前記機器データベースを参照して、前記所望の機器及びセンサに該当し、かつ、他事業者利用可否情報が利用可を示す第１の事業者の前記機器及びセンサを特定する請求項１に記載の仮想化ホームゲートウェイシステム。
3. 前記機器データベースは、第１の事業者の識別情報に対応して、第２の事業者が前記機器及びセンサを利用する際の利用料情報がさらに記憶され、
   前記課金データベースに記憶される課金情報は、第１の事業者を請求元とし、第２の事業者を請求先とした請求金額情報を含み、
   前記管理部は、前記加入要求に応じて、第１の事業者の該利用料情報に基づき、前記課金データベースの請求金額情報を更新する請求項１に記載の仮想化ホームゲートウェイシステム。
4. ホームネットワークに対応するユーザの識別情報と、該ホームネットワークに接続された前記機器及びセンサの識別情報とが対応して記憶された加入者データベース
   をさらに備え、
   前記管理部は、特定された前記機器及びセンサの識別情報に基づき前記加入者データベースを参照して、対応するユーザを特定し、
   該ユーザに対して、第２の事業者によるサービスの案内情報を送信する請求項１に記載の仮想化ホームゲートウェイシステム。
5. 前記機器データベースは、第１の事業者の識別情報と、前記機器及びセンサの種別とに対応して、該機器及びセンサの測定範囲情報及び／又は精度情報がさらに記憶され、
   第２の事業者からの前記機器使用要求は、所望の機器及びセンサの種別と、センサの要求測定範囲及び／又は要求精度とを含み、
   前記管理部は、
   該機器使用要求に対し、前記機器データベースを参照して、該所望の機器及びセンサに該当し、かつ、要求測定範囲及び／又は要求精度を満たす第１の事業者の前記機器及びセンサを特定する請求項１に記載の仮想化ホームゲートウェイシステム。
6. 前記管理部は、特定された第１の事業者の前記機器及びセンサのデータを取得するアプリケーションを前記仮想化ホームゲートウェイサーバに送信し、
   該アプリケーションが実行されることにより取得された第１の事業者の前記機器及びセンサのデータが、第２の事業者によるサービスに利用される請求項１に記載の仮想化ホームゲートウェイシステム。
7. 第１の事業者の前記機器及びセンサのデータが、一時ファイルに格納され、
   該一時ファイルに格納された第１の事業者の前記機器及びセンサのデータが、第２の事業者によるサービスに利用される請求項６に記載の仮想化ホームゲートウェイシステム。
8. 前記管理部は、特定された第１の事業者の前記機器及びセンサに関する情報を第２の事業者の装置に送信する請求項１に記載の仮想化ホームゲートウェイシステム。
9. 各ホームネットワークに配置され、ホームネットワークと前記仮想化ホームゲートウェイサーバとを広域ネットワークを介して接続するためのホームゲートウェイインタフェース部
   をさらに備える請求項１に記載の仮想化ホームゲートウェイシステム。

Images