JP2009223821A - センサーネットワーク用統合処理システム - Google Patents

Abstract

【課題】本発明は、センサーネットワークを活用したネットワークサービスにおいて、プル形式とプッシュ形式とを、適切に組み合わせた配信サービスを提供することを目的とする。
【解決手段】本発明に係るセンサーネットワーク用統合処理システムは、センサーの検出したデータ情報をアドホックネットワークを介して取得して送信するネットワーク抽象化機能部と、データ情報を収集するセンサーデータ収集機能部と、収集したデータ情報を取得し、データ情報の内容及びユーザーごとに予め定められたデータ配信サービスをプッシュ型の配信形態で実現するプッシュ型サービス機能部と、収集したデータ情報を取得し、データ情報の内容及びユーザーごとに予め定められたデータ配信サービスを、プル型の配信形態で実現するプル型サービス機能部と、を備え、上記の２つのサービス機能部を相互に連携してサービスを提供することを特徴とする。
【選択図】図１

Description

本発明は、監視対象とする場所にセンサーから得られる情報を伝達するためのセンサーノードを設置することにより、容易に周囲の環境情報を収集することを可能としたセンサーネットワークに関し、当該の監視対象から収集した環境情報に対し情報処理を行い、ユーザーに配信するサービスを提供する、センサー情報統合処理システムに関するものである。

近年、ＭＥＭＳ（Ｍｉｃｒｏ Ｅｌｅｃｔｒｏ Ｍｅｃｈａｎｉｃａｌ Ｓｙｓｔｅｍｓ）技術の発達により、センサー技術、無線通信技術を応用した、センサーノードの小型化、長時間駆動化技術に基づいた、センサーネットワークの活用法に関する提案がなされている。また、通信ネットワークの高速化により、遠隔地域との大容量通信が容易に行えるようになり、通信ネットワークを活用した様々なサービスが登場している。一方、現在の社会事情を考慮すると、災害支援、警備、気象予報、行動支援等、様々な分野でセンサーネットワークと通信ネットワークを融合させた通信サービスの実現が期待されている。

従来、これらの対象分野において、専用の機器、設備等を利用して、サービスが行われてきたが、設置箇所は極めて限定された小規模での活用が一般的であった。センサーネットワークは、無線通信が可能な範囲であれば設置が自由で容易である特徴を持つ。しかしながら、複数の異なる地域に跨る範囲を対象とし、かつ、これらの地域で、各種の異なるセンサーが複合的に使用されている時に、これらセンサーからの通知情報の種別等が、随意に増減する状況が考えられる。この場合、その都度、センサーからの情報の発生状況に、臨機応変に、対応できるセンサー情報を処理できるための、ネットワークサーバシステムの具体的な実現メカニズムについては、その方法が開示されていなかった。

センサーネットワークは、例えば、物流分野、警備分野、気象観測分野等にて実用化が進みつつあるが、上述したように、センサーネットワークを活用し、迅速に、かつタイムリーに、情報を得たい利用者の要求に柔軟に対応するためのネットワークサービスは、まだその実現メカニズムが明らかにされていない状況である（例えば、特許文献１参照。）。
特表２００４−５３３０３４

前述のように、センサーネットワークを介して情報を収集し、統合的に処理し、ユーザーに提供する技術が提案されているが、これらは、主に、ユーザーに情報を提供する手段として、プル型（オンデマンド型）、およびプッシュ型を単に混在させてユーザーに通信サービスを提供しているに過ぎない状況である。

そこで、本発明のセンサー情報統合処理システムは、本質的に利用者の要求の異なるプル型、およびプッシュ型のそれぞれに対して異なったサービス処理を施し、一つのサーバが統合してサービスを提供することを目的とする。

上記課題を解決するために、本発明に係るセンサーネットワーク用統合処理システムは、センサーの検出したデータ情報をアドホックネットワークを介して取得し、予め定められたデータ形式に変換して送信するネットワーク抽象化機能部と、前記ネットワーク抽象化機能部の送信するデータ情報を収集するセンサーデータ収集機能部と、前記センサーデータ収集機能部の収集したデータ情報を取得し、データ情報の内容及びユーザーごとに予め定められたデータ配信サービスを、プッシュ型の配信形態で配信するプッシュ型サービス機能部と、前記センサーデータ収集機能部の収集したデータ情報を取得し、データ情報の内容及びユーザーごとに予め定められたデータ配信サービスを、プル型の配信形態で配信するプル型サービス機能部と、を備えることを特徴とする。

本発明に係るセンサーネットワーク用統合処理システムでは、前記プッシュ型サービス機能部は、前記データ情報の内容の変化であるコンテキストを抽出するコンテキスト抽出論理部と、前記コンテキスト抽出論理部の抽出するコンテキストの種別に対応するイベント処理を処理タスク単位で実行するサービス処理論理部と、を備えることが好ましい。
センサーネットワークを活用したネットワークサービスを実現する場合において、コンテキストを抽出する論理を活用して、当該コンテキストを処理することにより、ネットワークサービスを実現するメカニズムを持たせることができる。

本発明に係るセンサーネットワーク用統合処理システムでは、前記コンテキスト抽出論理部及び前記サービス処理論理部を更新する管理制御部と、を備えることが好ましい。
プッシュ形式サービス処理において、センサー種別あるいはユーザー種別に応じてサービス処理ロジックを、随意に、追加、削除することができる。

本発明によれば、センサーネットワークを活用したネットワークサービスにおいて、本質的に利用者の要求の異なるプル型、およびプッシュ型のそれぞれに対して異なったサービス処理を施し、一つのサーバが統合してサービスを提供することができる。

添付の図面を参照して本発明の実施の形態を説明する。以下に説明する実施の形態は本発明の構成の例であり、本発明は、以下の実施の形態に制限されるものではない。
以下、詳細に説明する。

（実施形態１）
図１は、本実施形態に係るセンサーネットワーク用統合処理システムの構成概略図である。本実施形態に係るセンサーネットワーク用統合処理システムは、センサーネットワーク１００と、センサーデータ統合処理システム１０５と、を備える。センサーネットワーク１００とセンサーデータ統合処理システム１０５は、インターネットなどの通信網１１０で接続されている。

センサーネットワーク１００は、ひとつあるいは複数のセンサーノード１０１と、通信ノード１０２で構成され、アクセスポイントの介在なしに互いに送受信を行うアドホックネットワークにて接続されている。

センサーノード１０１は、センサー及び通信装置を備える。センサー、自然環境又は人体等のデータ情報を取得する。データ情報の取得は、データ情報を直接検知しても、通信によって取得してもよい。通信装置は、マルチホップ通信手段により、取得したデータ情報を通信ノード１０２へ転送する。

通信ノード１０２は、受信インターフェース１０３及びネットワーク抽象化部１０４を備える。受信インターフェース１０３は、データ情報を受信し、ネットワーク抽象化部１０４にデータ情報を転送する。ネットワーク抽象化部１０４は、パケットフォーマット等の通信プロトコル間における差異を吸収するために、受信したデータ情報を統一的に扱えるデータフォーマットに変換し、センサーデータ統合処理システム１０５に転送する。当該データフォーマットは、例えば、ＸＭＬ形式である。

センサーデータ統合処理システム１０５は、センサーデータ収集機能部１０６、プル型サービス機能部１０７、プッシュ型サービス機能部１０８を備える。センサーデータ収集機能部１０６は、ネットワーク抽象化部１０４から送出されたデータ情報を受信する。これによって、センサーデータ統合処理システム１０５は、データ情報を収集する。そして、センサーデータ収集機能部１０６は、データ情報を、プル型サービス機能部１０７及びプッシュ型サービス機能部１０８に転送する。このとき、データ情報は、ＸＭＬ形式などの適した形式でプル型サービス機能部１０７及びプッシュ型サービス機能部１０８に転送される。

プル型サービス機能部１０７は、ユーザーの所有する端末ｚｚ１及びｚｚ２に向けて配信する。プッシュ型サービス機能部１０８は、ユーザーの所有する端末ｙｙ１及びｙｙ２に向けて配信する。これにより、センサーネットワーク用統合処理システムは、プル型、プッシュ型の情報配信サービスを提供することができる。端末ｚｚ１、ｚｚ２、ｙｙ１及びｙｙ２は、データ情報の受信機能を備えるあらゆる物に適用できる。例えば、パソコンやＰＤＡなどのコンピュータ、又は、携帯電話などの電話機である。ここで、プル型サービス機能部１０７とプッシュ型サービス機能部１０８は、それぞれの配信形態に特化した処理機構を備える。

（実施形態２）
実施形態１で説明したセンサーネットワーク１００が複数エリア存在する場合、センサーデータ収集機能部１０６は、センサーデータ抽象化部１０４から送信されるデータ情報から複数拠点のセンサーネットワークの識別を行う。センサーネットワーク１０１の識別は、センサーデータ抽象化部１０４固有の情報である。例えば、ＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）、ＧＩＳ（Ｇｅｏｇｒａｐｈｉｃ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｙｓｔｅｍ）等の拠点毎の地理的情報である。

図２に、センサーネットワークでのデータフォーマット例を示す。センサーデータ抽象化部１０４固有の情報として、各センサーノード１０１が配備される特定の地域を簡易に識別するための地域コード（以下、エリアコードと呼称する）を用いている。この場合、各センサーデータ抽象化部１０４は、エリアコードを、データ情報に付加するためのメカニズムを備える。この外に、各センサーネットワーク１００の監視拠点となる通信ノード１０２にてエリアコードを付加した後、センサーデータ収集機能部１０６にデータ情報を転送する方法も可能であり、エリアコードの付与の方法は、これらの方法に限定されるものではない。

実施形態１及び実施形態２に係るセンサーネットワーク用統合処理システムは、プル形式、プッシュ形式、２つの情報配信手段をユーザーの処理要求の異なる、別のプロセスとして形成するか、あるいは、１プロセスの中で、別のタスクとして実現する、などの処理形態をとり、それぞれの処理サービスに対して、適した配信方式に対応して、当該のユーザーに、配信サービスを行う。また、本実施形態で開示するメカニズムは、プッシュ、およびプルの各形式処理サービスを、相互に連携させる。

具体的には、本実施形態に係るセンサーネットワーク用統合処理システムは、監視センターにおけるコンピュータ、パソコン、携帯電話、固定電話機等に対して、インターネット、または携帯電話網、または固定電話網を介して、自然環境あるいは、人体等に関わる、センサーノード１０１によって検知したデータ情報を、ネットワークの入り口にあたる通信ノード１０２まで、マルチホップで、取得情報を中継するためのアドホックネットワークを介して伝達し、取得されたデータ情報を、予め登録されたネットワーク上の処理サーバ側のセンサーデータ統合処理システム１０５において、取得情報に対して処理を行い、その結果をデータベースに格納し、ユーザーが利用可能とするネットワークサービスシステムにおいて、広範に分散している、膨大なセンサーノード１０１から得られるセンサー情報に対して、１人または複数人の、登録ユーザー毎に、１つまたは複数の、要求するセンサーノード１０１毎のアプリケーション種別対応に、サーバ側のセンサーデータ統合処理システム１０５において、相異なる個別処理を行うにあたり、取得情報からコンテキストを検知する処理部と、当該のコンテキストを処理してサービスを提供する処理部の２つの論理的な処理部を、動的に生成し、対応するコンテキスト抽出処理を実現するためのアプリケーションメカニズムをセンサーデータ統合処理システム１０５内に具備し、どのアプリケーション種別対応のメカニズムを使用するかを、登録ユーザーは遠隔手段を用いてセンサーデータ統合処理システム１０５に通知し、登録されたユーザーに対して、センサーデータ統合処理システム１０５は、要求されたアプリケーションに基づく結果が得られた時のみ、プッシュ配信を行う。

また、実施形態１及び実施形態２に係るセンサーネットワーク用統合処理システムは、監視センターにおけるコンピュータ、パソコン、携帯電話、固定電話機等に対して、インターネット、または携帯電話網又は固定電話網などの通信網１１０及び１１１を介して、人体等に関わる、センサーノード１０１によって検知したデータ情報を、ネットワークの入り口である通信ノード１０２まで、アドホックネットワークを介して中継し、当該のデータを、予め登録されたネットワーク上の処理サーバにおいて処理し、その結果を、データベースに格納して、ユーザーが利用可能とし、広範囲に移動が可能な、人体に装着したセンサーノード１０１から入手した、血圧、体温、脈波、心電図等のデータ情報を、リアルタイムにネットワークに送り、登録された監視者に通知を行うためのネットワークサービスシステムにおいて、センサーデータ統合処理システム１０５は、プッシュ形式でセンサーネットワークを介して、送付されるデータを検出し、内容を分析した後に、登録されたイベント処理用の論理単位に、当該の処理を行い、サービス処理用論理部（図３の３０４）、およびコンテキスト検出用論理部（図３の３０３）に対して、容易に追加・変更を行うことにより、動的なサービスの追加・変更を行うと共に、その処理結果をユーザーｙｙ１及びｙｙ２に、プッシュ配信し、かつ、そのプッシュ配信した時の履歴情報を、登録ユーザーの全体を管理するためのデータベース管理者ｘｘｘからの要求があった後は、プル型ネットワークサービスと協調連携し、当該の履歴情報と同時に、今までの蓄積されたセンサー情報を視覚化して、提供することを特徴とする。

また、実施形態１及び実施形態２に係るセンサーネットワーク用統合処理システムは、監視センターにおけるコンピュータ、パソコン、携帯電話、固定電話機等に対して、インターネット、または携帯電話網、または固定電話網を介して、自然環境あるいは、人体等に関わる、センサーノードによって検知したデータ情報を、前記の当該ネットワークの入り口である通信ノード１０２まで、上記の当該アドホックセンサーネットワークを介してマルチホップで中継し、当該のデータを、予め登録されたネットワーク上の処理サーバにおいて処理し、その結果を、データベースに格納して、ユーザーが利用可能とするネットワークサービスシステムにおいて、当該のデータベースは、震度、照度、騒音、水質、花粉、風速、雨量などの計測情報を、情報を、ある閾値を超えた段階または、定期的な時間間隔で、プッシュ形式で、センサーネットワークを介して、当該のセンサーデータを、統合処理用データベースに送付し、当該のデータベースでは、送られたセンサーデータ内容を分析した後に、予め、ユーザーが登録したイベント処理ロジック単位に処理された内容に基づいて処理し、その結果を登録された当該ユーザーにプッシュ配信すると共に、その当該プッシュ履歴が、登録ユーザーの全体を管理することを目的とするデータベース管理者ｘｘｘからの要求があった時は、当該のプル型サービスの発信履歴ならびに当該情報と、これまでの全ての時系列で得られた情報全体を分析して得られる分析結果を合わせて提示するか、または、プル型のサービス要求があった場合に、当該の要求があったことをプッシュ配信できることを特徴とするネットワークサービスを実現するための、センサー情報統合処理システムである。

（実施形態３）
図３は、プッシュ型サービス機能部１０８の構成例である。プッシュ型サービス機能部１０８は、センサーデータ収集機能部１０６に接続され、プッシュ型ユーザーの登録端末との通信を実現する。プッシュ型サービス機能部１０８は、イベント変換論理部３０１、イベント配信論理部３０２、コンテキスト抽出論理部３０３、サービス処理論理部３０４、プッシュファシリティ３０５、プッシュデータベース３０６、管理制御部３０７、コンテキスト抽出論理部データベース３０８、サービス処理論理部データベース３０９、イベント変換対応テーブル３２０を備える。ここで、プッシュ型サービス機能部１０８は、サービス処理論理部３０４を複数備えていてもよい。

プッシュ型サービス機能部１０８の概略を説明する。ステップの数値は、図中の丸付き数字に対応する。ステップＳ１では、イベント変換論理部３０１が、データ情報を、センサーデータ収集機能部１０６から取得する。ステップＳ２では、イベント変換論理部３０１が、イベント変換対応テーブル３２０を検索する。そして、検索結果に応じてセンサーイベントを生成する。ステップＳ３では、イベント変換論理部３０１が、生成したセンサーイベントを、イベント配信論理部３０２に出力する。ステップＳ４では、イベント配信論理部３０２が、受信可能なコンテキスト抽出論理部３０３に保持された識別子の情報を、コンテキスト抽出論理部データベース３０８から取得する。ステップＳ５では、イベント配信論理部３０２が、センサーイベントを、コンテキスト抽出論理部３０３に出力する。ステップＳ６では、イベント配信論理部３０２が、イベント配信手順を、コンテキスト抽出論理部３０３から取得する。ステップＳ７では、イベント配信論理部３０２が、サービス処理論理部３０４に保持された識別子情報を、サービス処理論理部データベース３０９から取得する。ステップＳ８では、イベント配信論理部３０２が、コンテキストイベントを、サービス処理論理部３０４に出力する。ステップＳ９では、サービス処理論理部３０４が、サービス処理論理部識別子、処理タスクの識別子及びサービス処理結果を、プッシュファシリティ３０５に出力する。ステップＳ１０では、プッシュファシリティ３０５が、プッシュ対象ユーザー情報を、プッシュデータベース３０６から取得する。ステップＳ１１では、プッシュファシリティ３０５が、サービス処理の結果を、プッシュ型ユーザーの端末ｙｙｙに出力する。

ステップＳ１２では、管理制御部３０７が、コンテキスト抽出論理部３０３又はサービス処理論理部３０４の追加コマンド、削除コマンド、変更コマンドを、管理者ｘｘｘから取得する。ステップＳ１３では、管理制御部３０７が、コンテキスト抽出論理部３０３又はサービス処理論理部３０４の追加コマンド、削除コマンド、変更コマンドを、コンテキスト抽出論理部データベース３０８及びサービス処理論理部データベース３０９に格納する。ステップＳ１４では、管理制御部３０７が、コンテキスト抽出論理部３０３内に格納されているコンテキストイベント情報に対して、追加、削除、変更等の更新を行う。なお、ステップＳ１５では、管理制御部３０７が、サービス処理論理部３０４を更新する。例えば、追加コマンドであれば、新たなサービス処理論理部３０４を追加する。削除コマンドであれば、サービス処理論理部３０４を削除する。変更コマンドであれば、新たなサービス処理論理部３０４に更新する。

イベント変換対応テーブル３２０は、センサー種別に対応したイベントを予め格納している。センサー種別は、環境に関する情報であれば、例えば、温度センサー又は照度センサーである。イベントは、例えば、構成フォーマット及び生成情報などのセンサーの情報である。センサー種別に＃０００１などのセンサー種別識別子が割り当てられており、センサー種別に基づいて変換可能となっている。

プッシュデータベース３０６は、プッシュ対象ユーザー情報を格納する。プッシュ対象ユーザー情報は、プッシュ型サービス機能部１０８から配信サービスを提供するユーザーに関する情報であり、プッシュ対象ユーザーの名前、サービス処理結果の配信手段、配信先アドレス等が含まれる。

コンテキスト抽出論理部データベース３０８は、受信可能なコンテキスト抽出論理部３０３の情報をセンサー種別ごとに格納している。

サービス処理論理部データベース３０９は、サービス処理論理部３０４についての情報を格納している。例えば、サービス処理論理部３０４の識別子と、その稼動状況、受信可能イベントタイプ、プッシュ配信の有無、プッシュ配信の履歴等のサービス処理論理部のメタ情報を格納する。

図３に示すイベント変換論理部３０１は、センサーデータ収集機能部１０６から送信されるデータ情報を受信し、当該データ情報を、対応するセンサーイベントに変換する。

図４に、イベント変換論理部３０１の実施フローの一例を示す。ステップＳ１０１では、イベント変換論理部３０１は、センサーデータ収集機能部１０６からデータ情報を受信する。データ情報には、例えば、センサー種別識別子、ユーザーＩＤ、グループＩＤ、イベント内容等が含まれる。
ステップＳ１０２では、ステップＳ１０１で受信したデータ情報からセンサー種別識別子を抽出する。例えば、データ情報のイベント内容にセンサー種別識別子が含まれている場合は、イベント内容からセンサー種別識別子を抽出する。
ステップＳ１０３では、イベント変換論理部３０１は、抽出したセンサー種別識別子をキーとして、イベント変換対応テーブル３２０を検索する。例えば、イベント変換対応テーブル３２０においてセンサー＃０００１が温度センサー、センサー＃０００２が照度センサーに割り当てられ、構成フォーマット及び生成情報などのセンサーの情報がそれぞれのセンサーに関連づけて記憶されている。
ステップＳ１０４では、イベント変換対応テーブル３２０に当該キーに対応する情報が存在するか否かを判定する。

ステップＳ１０４において、イベント変換対応テーブル３２０に当該キーに対応する情報が存在する場合、ステップＳ１０５では、イベント変換論理部３０１は、当該情報の情報をもとに、対応するセンサーイベントを生成する。センサーイベントの記述例を図５に示す。Ｊａｖａ（登録商標）のクラスで記述したがこれに限定しない。また、センサーイベントには、センサーイベントの種類を判別するためのセンサー種別識別子が含まれることが好ましい。
ステップＳ１０６では、生成したセンサーイベントを、イベント配信論理部３０２に送信し、イベント変換論理部３０１の実施フローを終了する。

一方、ステップＳ１０４において、イベント変換対応テーブル３２０に当該キーに対応する情報が存在しなかった場合、イベント変換論理部３０１は実施フローを終了する。

図３に示すイベント配信論理部３０２は、イベント変換論理部３０１から送信されるセンサーイベント又はコンテキスト抽出論理部３０３から送信されるコンテキストイベントに対応した処理タスクを決定する。処理タスクの決定は、例えば配信先の決定である。処理タスクの決定に際し、コンテキスト抽出論理部３０３からイベント配信手順３１１を取得する。そして、当該処理タスクに応じた当該受信イベントを、コンテキスト抽出論理部３０３又はサービス処理論理部３０４に配信する。

図６は、イベント配信論理部３０２の実施フローを示す。この実施フローでは、イベント変換論理部３０１から送信されるセンサーイベントを、イベント配信論理部３０２が、コンテキスト抽出論理部３０３に配信する。
ステップＳ２０１では、イベント配信論理部３０２が、プッシュ型サービス機能部１０８内のイベント変換論理部３０１から送信されたセンサーイベントを受信した後、当該センサー種別を判別する。イベントタイプの判別方法として、センサーイベントに含まれるセンサー種別識別子を用いることが好ましいが、判別方法はこれに限定されるものではない。
ステップＳ２０２では、コンテキスト抽出論理部３０３が、当該センサー種別を判別後、当該センサー種別をキーとして、コンテキスト抽出論理部データベース３０８を検索する。
ステップＳ２０３では、イベント配信論理部３０２が、センサー種別を受信可能なコンテキスト抽出論理部３０３が存在するか否かを判定する。すなわち、コンテキスト抽出論理部３０３の処理タスク群の中に、配信先として決定した処理タスクが存在するか否かを判定する。

ステップＳ２０３においてコンテキスト抽出論理部３０３の処理タスク群の中に、配信先として決定した処理タスクが存在する場合、ステップＳ２０４では、受信可能な各々の論理部を用いてステップＳ２０５からステップＳ２０７までの処理を逐次行う。ステップＳ２０５では、イベント配信論理部３０２が、受信可能なすべてのコンテキスト抽出論理部３０３から、イベント配信手順３１１を取得する。ここで、イベント配信手順３１１は、コンテキスト抽出論理部３０３の処理タスク群３１０内の、どの処理タスクに対して当該受信イベントを配信するかを決定するためのプログラムである。
ステップＳ２０６では、イベント配信手順３１１を実行することにより、配信するコンテキスト抽出論理部３０３の処理タスク群３１０内の処理タスクを決定する。これにより、配信先を決定する。
ステップＳ２０７では、受信イベントを、当該処理タスクに配信する。これにより、配信先にセンサーイベントを配信する。

一方、ステップＳ２０３においてコンテキスト抽出論理部３０３の処理タスク群３１０の中に、配信先として決定した処理タスクが存在しない場合、当該受信イベントを破棄する、又は当該処理タスクを新たに生成し、生成された当該処理タスクに当該受信イベントを配信する。どちらの方法を採用するかは、イベント配信手順３１１によって決定可能である。

図３に示すコンテキスト抽出論理部３０３は、センサーイベントをイベント配信論理部３０２から取得し、イベント配信手順３１１をイベント配信論理部３０２に出力する。

図７は、コンテキスト抽出論理部３０３の構成例である。コンテキスト抽出論理部３０３は、処理タスク群３１０、イベント配信手順３１１、コンテキスト検知手順群３１２、コンテキスト−イベント対応テーブル３１３を格納する。イベント配信手順３１１は、イベント配信論理部３０２がイベント配信先である処理タスクを決定する際に用いるイベント配信ルールを規定する。コンテキスト−イベント対応テーブル３１３は、状態変化（以後、コンテキストと呼称する）を対応するコンテキストイベントを格納する。

コンテキスト検知手順群３１２は、処理タスク群３１０内の処理タスクが、受信したセンサーイベントをどのように分析処理し、コンテキストを検知するかについて記述したプログラムの集合である。コンテキスト検知手順は、コンテキスト抽出論理部３０３が受信可能なセンサー種別毎に定義されることが好ましいが、定義方法はこれに限定されない。コンテキスト−イベント対応テーブル３１３は、処理タスク群３１０の処理タスクが検知したコンテキストの識別子と、コンテキストに対応するコンテキストイベント情報を持つ。例えば、コンテキストの識別子＃０００１であればコンテキストイベント情報は「温度が上限以上」、コンテキストの識別子＃０００２であればコンテキストイベント情報は「温度が下限以上」である。コンテキストイベント情報には、コンテキストイベントの構成フォーマット、生成に関連する情報が含まれる。

処理タスク群３１０は、実際のコンテキスト抽出処理を実行する一つ以上の処理タスクで構成される。処理タスクは、イベント配信論理部３０２から配信されるセンサーイベントを受信し、コンテキスト抽出論理部３０３が保持するコンテキスト検知手順群３１２を規定するプログラム３１２を用いて、当該センサーイベントの分析、コンテキストイベントの生成、当該コンテキストイベントの送信を行う機能を持つ。処理タスクは、処理タスク群３１０の他の処理タスクと区別するために、処理タスク識別子を持つ。処理タスクの各々は、イベント配信手順３１１の記述によって決定する。例えば、イベント配信ルールを規定するイベント配信手順３１１を、エリアコード単位で処理タスクに配信するように記述した場合、処理タスクはエリアコード毎に用意される。

図８は、コンテキスト抽出論理部３０３の実施フローを示す。
ステップＳ３０１では、処理タスク群３１０を構成する処理タスクは、イベント配信論理部３０２から配信されたセンサーイベントを受信する。センサーイベントのセンサー種別を判別する。
ステップＳ３０２では、処理タスクは、センサーイベントのセンサー種別を判別後、判別したセンサー種別に対応するコンテキスト検知手順を取得する。
ステップＳ３０３では、処理タスクは、当該コンテキスト検知手順を用いて分析処理を行う。ここで、処理タスクが、自身の状態を格納するローカル記憶領域を備える場合、分析処理のために当該処理タスクが備える当該ローカル記憶領域を用いることが好ましいが、これに限定されない。
ステップＳ３０４では、分析処理の結果からコンテキストを検知したか否かを判定する。分析処理の結果、分析対象において状態変化が確認された場合、当該処理タスクは、コンテキストを検知したとみなす。検知されるコンテキストには、コンテキスト種別と呼ばれる、コンテキストの種類を識別するための情報を持つ。
ステップＳ３０４において分析処理の結果からコンテキストを検知した場合、ステップＳ３０５では、当該コンテキストのコンテキスト種別をキーとして、当該コンテキストに対応するコンテキストイベント情報を、コンテキスト−イベント対応テーブル３１３から取得する。
ステップＳ３０６では、当該コンテキストイベント情報をもとにコンテキストイベント情報に対応するコンテキストイベントを生成する。
ステップＳ３０７では、生成したコンテキストイベントをイベント配信論理部３０２に送信する。コンテキストイベントは、図３に示すサービス処理論理部３０４がサービス処理を開始するために必要なイベントであり、検知されたコンテキストの情報を持つ。コンテキストイベントの記述例を図９に示す。

図３に示すサービス処理論理部３０４は、イベント配信論理部３０２から配信されたコンテキストイベントを受信し、種々のサービス処理を行い、プッシュファシリティ３０５を実行する。

図１０は、サービス処理論理部３０４の構成例である。サービス処理論理部３０４は、処理タスク群３１４、イベント配信手順３１５、サービス処理手順群３１６を格納する。各々のサービス処理論理部３０４は、他のサービス処理論理部３０４から区別するための、固有のサービス処理論理部識別子を持つ。

イベント配信手順３１５は、イベント配信ルールを規定する。例えば、コンテキスト抽出論理部３０３におけるイベント配信手順３１１と同等の機能を持つ。
サービス処理手順群３１６は、サービス処理ルールを規定するプログラムの集合である。サービス処理手順は、例えば、処理タスク群３１４内の処理タスクが、受信したコンテキストイベントをどのようにサービス処理するかを規定する。このプログラムは、コンテキスト種別毎に定義することが好ましいが、定義方法はこれに限定されない。

処理タスク群３１４は、イベント配信論理部３０２から配信されたコンテキストイベントのコンテキスト種別に対応するサービス処理を行う。処理タスク群３１４における処理タスクは、サービス処理手順群３１６を用いてサービス処理を実行することを除いて、コンテキスト抽出論理部３０３における処理タスク群３１０と同等の機能を持つ。

図１１は、サービス処理論理部３０４の実施フローを示す。
ステップＳ４０１では、処理タスク群３１４を構成する処理タスクは、イベント配信論理部３０２から配信されたコンテキストイベントを受信する。
ステップＳ４０２では、処理タスクがコンテキストイベントのコンテキスト種別を判別後に、サービス処理手順群３１６の中から当該コンテキスト種別に対応するサービス処理手順を取得する。
ステップＳ４０３では、処理タスクは、当該サービス処理手順群３１６を実行してサービス処理を行う。
ステップＳ４０４は、プッシュファシリティ３０５を実行する。

ここで、当該処理タスクが、自身の状態を格納するローカル記憶領域を備える場合、サービス処理のために当該処理タスクが備える当該ローカル記憶領域を用いることが好ましいが、これに限定されない。当該処理タスクは、当該サービス処理を完了後、サービス処理論理部識別子と、当該処理タスクの識別子と、当該サービス処理の結果を渡してプッシュファシリティ３０５を実行する。

図３に示すプッシュファシリティ３０５は、サービス処理論理部３０４のサービス処理結果を、予め登録されたプッシュ型ユーザーｙｙｙに対して配信する。

図１２は、プッシュファシリティ３０５の実施フローを示す。
ステップＳ５０１では、プッシュファシリティ３０５は、サービス処理論理部３０４の処理タスク群３１４の処理タスクから、サービス処理論理部識別子と、当該処理タスクの識別子と、サービス処理結果を受信する。
ステップＳ５０２では、サービス論理部識別子をキーとして、サービス処理論理部データベース３０９から、当該サービス処理論理部のプッシュ機能が有効か無効か判別する。ここで、プッシュ機能の有効・無効の設定は、管理者が任意に設定可能である。
ステップＳ５０２においてプッシュ機能が有効である場合、プッシュファシリティ３０５は、ステップＳ５０３において、処理タスクの識別子をキーとして、プッシュデータベース３０６から、プッシュ対象ユーザー情報を取得する。
ステップＳ５０３では、当該プッシュファシリティ３０５は、プッシュ機能が有効である場合、図１３における当該処理タスクの識別子をキーとして、図３のプッシュデータベース３０６から、プッシュ対象ユーザー情報に対応する識別子（プッシュユーザーＩＤ）を取得する。図１３に、プッシュデータベースの構成例を示す。プッシュ対象ユーザー情報には、プッシュ対象ユーザー名、サービス処理結果の配信手段（プッシュ手段等）、配信先アドレス（プッシュアドレス）等が含まれる。
ステップＳ５０４では、プッシュ対象ユーザーが存在するか否かを判定する。
ステップＳ５０４においてプッシュ対象ユーザーが存在する場合、ステップＳ５０５では、プッシュファシリティ３０５は、当該プッシュ対象ユーザー情報を用いて、プッシュ対象ユーザーに当該サービス処理の結果を配信する。

一方、ステップＳ５０２においてプッシュ機能が有効でない場合、または、ステップＳ５０４においてプッシュ対象ユーザーが存在しない場合は、プッシュファシリティ３０５の実施を終了する。

図３に示す管理制御部３０７は、管理者ｘｘｘからのコンテキスト抽出論理部３０３又はサービス処理論理部３０４の追加コマンド、削除コマンド、変更コマンドを受け付ける機能と、コンテキスト抽出論理部３０３又はサービス処理論理部３０４の追加・削除・変更する機能を持つ。

図１４は、サービス処理論理部３０４を追加する実施シーケンスを示す。管理制御部３０７は、サービス処理論理部３０４を追加する旨指示する追加コマンドを取得する。追加コマンドの取得は、管理者ｘｘｘから受信する。追加コマンドには、追加フラグ、論理部識別子、稼動状況、プッシュ配信フラグ、サービス固有情報が含まれる。
管理制御部３０７は、追加コマンドに含まれるサービス処理論理部の識別子をキーとして、サービス処理論理部データベース３０９を検索する。図１５に、サービス処理論理部データベース３０９の構成例を示す。サービス処理論理部データベース３０９には、サービス処理論理部識別子とともに、稼働状況、受信可能イベントタイプ、プッシュ配信の有無、等のサービス処理論理部のメタ情報を格納するものである。識別子に対応する情報がサービス処理論理部データベース３０９に存在しない場合、管理制御部３０７は、追加コマンドで指定されるサービス処理論理部３０４が追加可能であると判断し、当該管理者ｘｘｘに対してその旨を応答する。
管理者ｘｘｘは、サービス処理論理部３０４が追加可能である旨の応答を受信後、サービス処理論理部３０４のコンポーネントを、当該管理制御部３０７に送信する。当該コンポーネントには、サービス処理論理部３０４の、イベント配信手順３１５と、サービス処理手順群３１６等が含まれる。
管理制御部３０７は、サービス処理論理部３０４のコンポーネントを受信後、当該コンポーネントを用いて、サービス処理論理部３０４をプッシュ型サービス機能部１０８内に追加し、その後、サービス処理論理部データベース３０９に、サービス処理論理部３０４の追加コマンドの情報を格納する。

図１６は、既存のサービス処理論理部３０４を削除する実施シーケンスを示す。管理制御部３０７は、管理者ｘｘｘから、削除するサービス処理論理部３０４に関する情報を含んだ、削除コマンドを受信する。図１７は、削除コマンドのフォーマット構成例を示す。当該管理制御部３０７は、当該削除コマンドを受信後、当該削除コマンドに含まれるサービス処理論理部の識別子をキーとして、サービス処理論理部データベース３０９を検索する。当該識別子に対応する情報が存在する場合、当該管理制御部３０７は、当該削除コマンドで指定される当該サービス処理論理部３０４が削除可能であると判断し、当該サービス処理論理部３０４を削除し、当該サービス処理論理部データベース３０９から、当該サービス処理論理部の情報を削除する。

図１８は、既存のサービス処理論理部３０４のメタ情報を変更する実施シーケンスを示す。既存のサービス処理論理部３０４のメタ情報を変更する場合の実施シーケンスについて説明する。この場合、管理制御部３０７は、管理者ｘｘｘから、メタ情報を変更するサービス処理論理部３０４に関する情報を含んだ変更コマンドを受信する。変更コマンドは、例えば、変更フラグ、論理部識別子、稼動状況、プッシュ配信フラグ、サービス固有情報が含まれる。管理制御部３０７は、変更コマンドを受信後、変更コマンド内の識別子をキーとして、サービス処理論理部データベース３０９を検索する。そして、当該識別子に対応する情報が存在する場合、当該管理制御部３０７は、変更コマンドで指定されるサービス処理論理部３０４が変更可能であると判断し、サービス処理論理部データベース３０９内の、当該サービス処理論理部３０４の情報を変更コマンドに含まれる情報をもとに更新する。
（実施形態４）
図１９は、プッシュ型サービス機能部１０８とプル型サービス機能部１０７との相互間における連携の実施例を示す。プッシュ型サービス機能部１０８は、図３で説明したプッシュ型サービス機能部１０８の構成に加えて、プッシュ配信に関する情報を格納するプッシュ履歴データベース５０１を備える。プッシュ履歴データベース５０１を備えることで、プッシュ型サービス機能部１０８とプル型サービス機能部１０７間の連携の綿密化を図ることができる。なお、本実施形態では、プッシュ型サービス機能部１０８の構成は、プッシュ履歴データベース５０１、コンテキスト抽出論理部３０３及びプッシュファシリティ３０５を除いては前述のとおりなので、記載を省略した。

プル型サービス機能部１０７は、センサーデータベース４０１、処理部４０２、送受信部４０３を備える。まず、プル型サービスにおける処理シーケンス例について、図２０を用いて説明する。センサーデータベース４０１は、センサーデータ収集機能部１０６より逐次転送されるデータ情報を格納する。一方、プル型ユーザーｚｚｚからの要求を送受信部４０３が受け付け、プル型ユーザーｚｚｚからのサービス要求を処理部４０２に転送する。処理部４０２は、送受信部４０３により受け付けた処理要求を基に、処理に必要なデータ情報をセンサーデータベース４０１（以下、センサーＤＢ）に要求し、必要なデータ情報を抽出する。抽出されたデータ情報と、プル型ユーザーによるサービス要求を基にグラフ作成、統計処理等の情報処理を行い、送受信部４０３を介してプル型ユーザーに配信する。

プル型サービス機能部１０７とプッシュ型サービス機能１０８部の連携を実現する際、プッシュ履歴データベース５０１が保持するプッシュ配信に関する情報と、センサーデータベース４０１に保持される当該プッシュ配信に対応したデータ情報とを関連付けるために、コンテキスト抽出論理部３０３に備わるコンテキストイベント対応テーブル３１３内のコンテキストイベント情報には、対応するコンテキストの発生に関わるセンサー種別識別子のリストが含まれている。サービス処理論理部３０４内に備わる処理タスク群３１４を構成する処理タスクは、プッシュファシリティ３０５を実行する時に、サービス処理論理部３０４の識別子、当該処理タスクの識別子、サービス処理の結果に加えて、受信したコンテキストイベントに含まれるセンサー種別識別子のリストを引数として与える。プッシュファシリティ３０５は、サービス処理論理部３０４のサービス処理の結果を、プッシュ型ユーザーｙｙｙに対してプッシュ配信する機能に加えて、当該プッシュ配信に関する情報と、受信したセンサー種別識別子のリスト情報を、プッシュ履歴データベース５０１に格納する機能を持つ。図２１に、プッシュ履歴データベース（以下、プッシュ履歴ＤＢと呼称する）５０１の構成例を示す。

図２２は、本実施形態におけるプッシュファシリティ３０５の実施フローを示す。
ステップＳ６０１では、サービス処理論理部３０４のメタ情報を、サービス処理論理部データベース３０９から取得する。ステップＳ６０２では、プッシュ機能が有効か否かを判定する。

ステップＳ６０２においてプッシュ機能が有効と判定した場合、ステップＳ６０３では、プッシュファシリティ３０５が、提供された処理タスク群３１４の処理タスク識別子からユーザーとの通知手段に関する情報を取得する。ステップＳ６０４では、該当するユーザーは存在するのかを判定する。例えば、プッシュデータベース３０６に登録されているかを参照する。

ステップＳ６０４においてユーザーが存在すると判定した場合、ステップＳ６０５では、プッシュファシリティ３０５は、提供された処理結果を当該ユーザーに対して配信する。ステップＳ６０６では、プッシュファシリティ３０５は、プッシュ履歴機能は有効か否かを判定する。例えば、プッシュ履歴データベース５０１に使用可能か否かを問い合わせる。

ステップＳ６０６においてプッシュ履歴機能は有効であると判定した場合、ステップＳ６０７では、プッシュファシリティ３０５は、配信結果としての、センサー種別識別子及びプッシュ履歴情報等を、プッシュ履歴データベース５０１に格納する。

一方、ステップＳ６０２においてプッシュ機能が無効と判定した場合、又は、ステップＳ６０４においてユーザーが存在しないと判定した場合、又は、ステップＳ６０６においてプッシュ履歴機能は有効でないと判定した場合、プッシュファシリティ３０５の実施フローを終了する。

次に、プル型サービス機能部１０７がプッシュ型サービス機能部１０８と連携する実施例について述べる。図２３に、本実施形態に係るセンサーデータ統合処理システム１０５のデータ転送シーケンスの一例を示す。
プル型ユーザーの端末ｚｚｚから、プッシュ履歴要求が送信される。プッシュ履歴ＤＢ５０１に格納された情報は、プッシュ履歴要求が発生する度毎に、プル型サービス機能部１０７内の送受信部４０３で要求を受け取り、当該プッシュ履歴要求を処理部４０２に転送する。
処理部４０２は、プッシュ履歴ＤＢ５０１にプッシュ履歴要求を送信し、要求されたプッシュ履歴情報（センサー種別識別子を含む）を取得する。
処理部４０２は、プッシュ履歴情報に含まれる、日時とセンサー種別識別子をキーとして、当該プッシュ履歴情報に対応するデータ情報をセンサーＤＢ４０１に要求し、当該プッシュ履歴情報に対応するデータ情報を得る。
処理部４０２は、得られたプッシュ履歴情報及びデータ情報とを組み合わせ、統計、解析等の処理を行う。処理部４０２は、プル型ユーザｚｚｚからの要求に応じて、プッシュ履歴と、センサー情報を組み合わせ、情報処理を行う。これにより、プッシュ履歴に基づいたデータ情報の処理結果を得ることができる。
送受信部４０３は、処理部４０２の処理結果を、プル型ユーザに対して配信する。本実施例により、プル型ユーザｚｚｚからの要求においてもプッシュ履歴と、センサー情報を組み合わせ、情報処理を行った、プッシュ履歴に基づいたデータ情報を配信することが可能である。

実施形態３においては、プッシュ型サービス機能部１０８を構成するコンテキスト抽出論理部３０３は、分析処理を行う場合に、受信するセンサーイベントのみを用いて分析処理を行う方法と、受信するセンサーイベントと、処理タスク群３１０を構成する処理タスクが持つローカル記憶領域を組み合わせて分析処理を行う方法があった。実施形態４に示すように、プッシュ型サービス機能部１０８がプル型サービス機能部１０７と連携する場合は、実施形態３における分析処理を行う場合に、プル型サービス機能部を構成するセンサーデータベース４０１から必要な情報を取得して利用することで、より詳細な分析処理が実現する。

本発明は、災害支援、警備、気象予報、行動支援等の様々な情報を容易に収集し、ユーザーの多様なサービス要求に応えることを可能としたセンサーネットワークを提供することができ、今後の携帯電話システムのサービス機能の高度化に貢献しうる。

実施形態１に係るセンサーネットワーク用統合処理システムの構成概略図である。 センサーネットワークでのデータフォーマット例である。 プッシュ型サービス機能部１０８の構成例である。 イベント変換論理部３０１の実施フローの一例である。 センサーイベントの記述例である。 イベント配信論理部３０２の実施フローである。 コンテキスト抽出論理部３０３の構成例である。 コンテキスト抽出論理部３０３の実施フローである。 コンテキストイベントの記述例である。 サービス処理論理部３０４の構成例である。 サービス処理論理部３０４の実施フローである。 プッシュファシリティ３０５の実施フローである。 プッシュデータベースの構成例である。 新しいサービス処理論理部３０４を追加する実施シーケンスである。 サービス処理論理部データベース３０９の構成例である。 既存のサービス処理論理部３０４を削除する実施シーケンスである。 削除コマンドのフォーマット構成例である。 既存のサービス処理論理部３０４のメタ情報を変更する実施シーケンスである。 プッシュ型サービス機能部とプル型サービス機能部との相互間における連携の実施例である。 プル型サービスにおける処理シーケンス例である。 プッシュ履歴データベース５０１の構成例である。 本実施形態におけるプッシュファシリティ３０５の実施フローである。 センサーデータ統合処理システム１０５のデータ転送シーケンスの一例である。

符号の説明

１００ センサーネットワーク
１０１ センサーノード
１０２ 通信ノード
１０３ 受信インターフェース
１０４ ネットワーク抽象化機能部
１０５ センサーデータ統合処理システム
１０６ センサーデータ収集機能部
１０７ プル型サービス機能部
１０８ プッシュ型サービス機能部
１１０、１１１ 通信網
３０１ イベント変換論理部
３０２ イベント配信論理部
３０３ コンテキスト抽出論理部
３０４ サービス処理論理部
３０５ プシュファシリティ
３０６ プッシュデータベース
３０７ 管理制御部
３０８ コンテキスト抽出論理部データベース
３０９ サービス処理論理部データベース
３１０ 処理タスク群
３１１ イベント配信手順
３１２ コンテキスト検知手順群
３１３ コンテキストイベント対応テーブル
３１４ 処理タスク群
３１５ イベント配信手順
３１６ サービス処理手順群
３２０ イベント変換対応テーブル
４０１ センサーデータベース
４０２ 処理機能部
４０３ 送受信部
５０１ プッシュ履歴データベース

Claims (3)

1. センサーの検出したデータ情報をアドホックネットワークを介して取得し、予め定められたデータ形式に変換して送信するネットワーク抽象化機能部と、
   前記ネットワーク抽象化機能部の送信するデータ情報を収集するセンサーデータ収集機能部と、
   前記センサーデータ収集機能部の収集したデータ情報を取得し、データ情報の内容及びユーザーごとに予め定められたデータ配信サービスを、プッシュ型の配信形態で配信するプッシュ型サービス機能部と、
   前記センサーデータ収集機能部の収集したデータ情報を取得し、データ情報の内容及びユーザーごとに予め定められたデータ配信サービスを、プル型の配信形態で配信するプル型サービス機能部と、
   を備えることを特徴とするセンサーネットワーク用統合処理システム。
2. 前記プッシュ型サービス機能部は、
   前記データ情報の内容の変化であるコンテキストを抽出するコンテキスト抽出論理部と、
   前記コンテキスト抽出論理部の抽出するコンテキストの種別に対応するイベント処理を処理タスク単位で実行するサービス処理論理部と、を備えることを特徴とする請求項１に記載のセンサーネットワーク用統合処理システム。
3. 前記プッシュ型サービス機能部は、さらに、前記コンテキスト抽出論理部及び前記サービス処理論理部を更新する管理制御部と、を備えることを特徴とする請求項２に記載のセンサーネットワーク用統合処理システム。

Images