(57)【要約】      （修正有）【課題】コンテキスト作成システムにセンサ情報を供給するコンテキストソースに代わり、１つ以上のセンサの利用を管理するセンサ管理システムを提案する。【解決手段】センサ管理システム１は、コンテキストソース２からの１つ以上のセンサ３を要求する要求の受信を含むコンテキストソースインタラクション手段８と、利用可能なセンササービス７を発見するとともに、発見したセンササービス７に関する探索情報を記憶するセンササービス発見手段９と、センサ３へのアクセスを行うとともに、利用可能であるセンササービス７について記憶された特定の探索情報を判定するセンサ管理サービス１０と、コンテキストソースインタラクション手段８が受信した要求とセンサ管理サービス１０が判定した特定の探索情報に対応する特定の問合せをセンササービス７に送るセンサアクセスオブジェクト手段６とを備える。【選択図】図５
2005260914.tif 000002
【特許請求の範囲】
【請求項１】
各センサ（３，３’）が、ダイレクトリンク又はネットワークリンクへの通信インターフェースをセンサ（３，３’）に与えるセンササービス（７）により利用可能とされ、コンテキストソース（２）により１つ以上のセンサの利用を管理するセンサ管理システム（１）において、
上記コンテキストソース（２）からの、それぞれ所定の特性を有する上記１つ以上のセンサ（３，３’）を要求する要求の受信を含む、上記コンテキストソース（２）とインタラクションを行うコンテキストソースインタラクション手段（８）と、
上記ダイレクトリンク又はネットワークリンクにより利用可能なセンササービス（７）を発見するとともに、該発見したセンササービス（７）に関する探索情報を記憶するセンササービス発見手段（９）と、
上記センササービス発見手段（９）から、上記コンテキストソース（２）が要求する特性のセンサ（３，３’）へのアクセスを行うとともに上記ダイレクトリンク又はネットワークリンクにより利用可能であるセンササービス（７）について記憶された、特定の探索情報を判定するセンサ管理サービス（１０）と、
上記コンテキストソースインタラクション手段（８）が受信した要求と上記センサ管理サービス（１０）が判定した特定の探索情報に対応する特定の問合せを、上記センササービス（７）に送るセンサアクセスオブジェクト手段（６）とを備えるセンサ管理システム。
【請求項２】
上記センサアクセスオブジェクト手段（６）は、上記センササービス（７）からのセンサデータの検索、及び上記コンテキストソース（２）へのセンサデータの供給を行うことを特徴とする請求項１に記載のセンサ管理システム。
【請求項３】
上記センサアクセスオブジェクト手段は、上記コンテキストソースインタラクション手段（８）が受信した要求に対応する、センサのアクセス可能性及び／又は適性について、上記センサ（３，３’）を探査する探査手段（１１）を備えることを特徴とする請求項１又は２に記載のセンサ管理システム。
【請求項４】
上記センサアクセスオブジェクト手段は、上記コンテキストソースインタラクション手段（８）が受信した要求に対応する特定のセンササービス（７）への通信リンクを確立するセンサインスタンス化手段（１１）を備えることを特徴とする請求項１乃至３のいずれか１項に記載のセンサ管理システム。
【請求項５】
上記センササービス発見手段（９）は、発見した各センササービス（７）の探索情報を管理するデータベースを備えることを特徴とする請求項１乃至４のいずれか１項に記載のセンサ管理システム。
【請求項６】
上記センササービスの発見は、上記センササービス発見手段（９）により定期的に行われることを特徴とする請求項１乃至５のいずれか１項に記載のセンサ管理システム。
【請求項７】
上記コンテキストソースインタラクション手段（８）は、上記センサ管理システム（１）及び／又は上記センササービス（７）のいずれかにより使用する上記コンテキストソース（２）から受信したイベント情報を登録するイベント登録を行うことを特徴とする請求項１乃至６のいずれか１項に記載のセンサ管理システム。
【請求項８】
上記コンテキストソースインタラクション手段（８）は、上記センサ管理システム（１）及び／又は上記センササービス（７）のいずれかから発生したイベントを上記コンテキストソース（２）に通知するイベント通知を行うことを特徴とする請求項１乃至７のいずれか１項に記載のセンサ管理システム。
【請求項９】
上記コンテキストソースインタラクション手段（８）が上記コンテキストソース（２）から受信した要求は、センサアクセスオブジェクトの形式であることを特徴とする請求項１乃至８のいずれか１項に記載のセンサ管理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、利用可能性が変動するセンサを用いたコンテキストアウェアシステムに関し、センサの利用可能性をコンテキストアウェアシステムの外部で管理するコンテキストアウェアシステムに関する。
【背景技術】
【０００２】
コンテキストアウェアは、次世代のスマート装置（smart device）の重要な技術である。これらの装置は、ユーザの欲求（desire）や要求（needs）に関する幅広い知識を有し、それに応じて動作するものである。これは、例えば、ユーザ又はユーザの関心がある人物の位置、現在装置を使用しているユーザの身元、ユーザが利用可能な装置の種類等、信頼性のあるコンテキスト情報を検索するのに十分な情報を収集する内部の及び外部の多数のセンサを利用することにより達成される。
【０００３】
本明細書で使用する「コンテキスト」という用語は、アニンド・ケイ・デイ著、「コンテキストの理解と使用」、パーソナルユビキタスコンピューティングジャーナルＶｏｌ．５（１）、２００１年、ｐ．４−７（Anind K. Dey “Understanding And Using Context,” Personal Ubiquitous Computing Journal, Volume 5(1), 2001, pp.4-7）において、あるエンティティの状況を特徴付けるのに使用することができるあらゆる情報として定義されている。ここで、エンティティとは、ユーザとアプリケーション間のインタラクションに対して適切であると考えられる人物、場所、物として定義され、ユーザやアプリケーション自体も含まれる。
【０００４】
コンテキストに関する知識は、コンテキスト情報を自動的に取り込むことにより、アプリケーション装置をさらにスマート化するように種々の方法で利用することができる。コンテキストは、通常、多数の異なるセンサから潜在的に検索される異なる種類のコンテキストの多様性により、非常に複雑な事項である。例えば、外国の都市を回る旅行者は、自分のコンテキストアウェア装置により現在の地図（active map）が得られ、さらに、自分が現在見ている観光名所についての情報が得られる。コンテキストアウェア装置は、この場合、特に旅行者の現在位置についての情報が必要である。旅行者が屋外にいる場合、この情報は、全地球測位システム（Global Positioning System（以下、ＧＰＳと略す））を用いて得ることができるが、ＧＰＳ衛星へのアクセスは建物内ではほとんど不可能になるため、屋内では無理である。このため、屋内で位置情報を検索するためには、特殊な屋内用の位置検出装置（location defining system）を使用しなければならない。ユーザが建物に出入りするたびに、ユーザのコンテキストアウェア装置は別の位置検出装置に切り換えなければならない。この屋外用位置検出装置から屋内用位置検出装置への切換及びその逆の切換は、現在、アプリケーション側で行われており、利用可能な情報源が少ないときには非常に良好に動作する。
【０００５】
幾つかの戦術的な軍事アプリケーション、例えば戦術戦闘機等において、センサ管理システムが配備されており、センサ管理システムは、攻撃目標を効果的に検出し、分類し、追跡するために、センサを制御して、限定されたセンサリソースを割り当てることにより、パイロットの作業負担を削減するのに使用されている。センサ管理システムは、利用可能なセンサデータを集め、高いレベルのデータのみをパイロットに示して、オンボードにおける体感上の複雑さを隠すことにより、パイロットをサポートしている。センサ管理システムでは、既知であれば、あらゆる種類のセンサを動的に接続することができるとともに、そのセンサを直ちに利用することができる。しかしながら、提供されるセンサデータの処理を行う必要もあるため、センサが既にセンサ管理システムよって知られている場合にしか働かない。各センサは、集中管理されており、他のセンサと密接に連動している。
【０００６】
多数の異なるセンサ間で、互いにインタラクションを行い、センサデータを交換及び伝達するセンサネットワークを構成することにより、分散構造が得られる。それぞれの装置は、特定のセンサの探索を行わないので、センサを管理する必要はない。この場合、特定の情報の要求をセンサ管理システムに送ると、データがどこでどのように作成されたかを知らなくても、結果が集計されて、要求したインスタンスに返される。すなわち、適切なセンサを検出して利用といった側面の管理はない。
【０００７】
要求された種類の情報を得るのに必要なデータを検索するために、多数のセンサを必要とするコンテキストアウェアシステムの場合、センサの利用可能性及び妥当性の監視は、コンテキストアウェアシステムにとって重く、実行することができない。
【０００８】
上述した具体例における旅行者は、例えば、自分自身の位置に関心があるだけでなく、ある地域に、ある人物が出入しているか、すなわち、例えば自分の子供たちが遠くに行き過ぎていないかを知りたい場合がある。この場合、コンテキストシステムは、異なる種類の多くの位置探査センサ、すなわち屋内用と屋外用の位置探査センサを利用しなければならないが、屋内用位置探査型センサは、建物毎に異なり、発見する人物毎に異なる場合もある。
【０００９】
このことは、欧州特許出願公開番号ＥＰ１，２９８，５２７Ａ１号に記載されている、要求に応じてコンテキスト情報を提供するシステムによって。達成される。このシステムは、コンテキスト情報の要求から、そのような情報を提供するのに適した利用可能なコンテキストソースへのパスを与える動的なコンテキストグラフ構成の自動設定を用いている。ここで、コンテキストソースは、センサの抽象的概念をコンテキストシステムに示す。コンテキストソースは、要求されたコンテキスト情報を構成することができるコンテキストグラフ構成機構によって管理されている。コンテキストグラフ構成機構は、様々なコンテキストソースからのデータを高いレベルのコンテキスト情報に動的に統合するように構成されているが、コンテキストソースを提供するセンサを探索（search）して利用するようには構成されておらず、それを行うと過負荷になってしまう。
【発明の開示】
【発明が解決しようとする課題】
【００１０】
したがって、本発明の目的は、要求されたセンサ情報をコンテキストソースに対して動的に供給するシステムを提供することである。
【課題を解決するための手段】
【００１１】
この目的は、独立請求項に記載されたセンサ管理システムよって達成される。
【００１２】
本発明に係るセンサ管理システムは、コンテキストソースにより１つ以上のセンサの利用を管理するものであり、各センサは、ダイレクトリンク又はネットワークリンクへの通信インターフェースをセンサに与えるセンササービスにより利用可能とされる。センサ管理システムは、コンテキストソースとインタラクションを行うコンテキストソースインタラクション手段を備え、インタラクションは、コンテキストソースからの１つ以上のセンサを要求する要求の受信を含み、各センサは所定の特性を有する。センサ管理システムは、さらに、ダイレクトリンク又はネットワークリンクにより利用可能なセンササービスを発見するとともに、発見したセンササービスに関する探索情報を記憶するセンササービス発見手段を備える。センサ管理システムは、さらに、センササービス発見手段から、コンテキストソースが要求する特性のセンサへのアクセスを行うとともにダイレクトリンク又はネットワークリンクにより利用可能であるセンササービスについて記憶された、特定の探索情報を判定するセンサ管理サービスを備える。センサ管理システムのセンサアクセスオブジェクト手段は、さらに、コンテキストソースインタラクション手段が受信した要求とセンサ管理サービスが判定した特定の探索情報に対応する特定の問合せを、センササービスに送る。
【００１３】
ユーザ環境の性質上、ユーザ環境を記述するコンテキストの評価に必要なデータを供給する際に必要となるセンサは、非常に頻繁に変わる。提案されるセンサ管理システムは、必要とされるセンサの利用可能性が常に変わることを考慮して、コンテキストシステムを保存する。
【００１４】
さらなる有利な特徴については各従属請求項において記載する。
【００１５】
コンテキストソースがコンテキストシステムに必要なデータを供給することを可能にするため、センサアクセスオブジェクト手段は、好ましくは、センササービスからのセンサデータの検索し、及び、コンテキストソースへのセンサデータの供給を行う。選択されたセンサが、確実に、コンテキストソースからの要求に応じることに実際に適するようにするため、センサアクセスオブジェクト手段は、好ましくは、コンテキストソースインタラクション手段が受信した要求に対応する、センサのアクセス可能性及び／又は適性について、センサを探査する探査手段を備える。センサアクセスオブジェクト手段は、さらに、コンテキストソースインタラクション手段が受信した要求に対応する特定のセンササービスへの通信リンクを確立するセンサインスタンス化手段を備えて構成されてもよい。このようにすれば、コンテキストソースにより特定のセンサを明確に使用することが可能となる。
【００１６】
効果的なセンサ管理のため、センササービス発見手段は、好ましくは、発見した各センササービスの探索情報を管理するデータベースを備える。センサの利用可能状態を常に追跡するため、好ましくは、センササービス発見手段により定期的にセンササービスの発見を行う。
【００１７】
あるイベントの発生時に多くのデータが必要となるので、コンテキストソースインタラクション手段は、好ましくは、センサ管理システム及び／又はセンササービスのいずれかにより使用するコンテキストソースから受信したイベント情報を登録するイベント登録を行う。好ましい実施例において、コンテキストソースインタラクション手段は、さらに、センサ管理システム及び／又はセンササービスのいずれかから発生したイベントをコンテキストソースに通知するイベント通知を行う。
【００１８】
コンテキストソースと、あるセンサに関連するセンササービスとの通信を簡略化するため、コンテキストソースは、センサアクセスオブジェクトを受信用としてコンテキストソースインタラクション手段に直接送ることにより、センサを要求してもよい。
【発明を実施するための最良の形態】
【００１９】
以下、本発明を、特定の実施例及び図面を参照してより詳細に説明する。
【００２０】
コンテキスト情報を供給するシステムは、利用可能なコンテキストの設定に必要な情報を取得する所謂コンテキストソースに基づいている。本発明に基づくセンサ管理システムは、コンテキストソースにとって適切な情報をコンテキスト作成システムから検索（retrive）するのに必要なセンサ利用の複雑性を隠す。センサ管理システムは、コンテキストソースに適したセンサを探索（look up）するという複雑なタスクを担う。典型的には、コンテキストソースは、あるセンサの要求をセンサ管理システムに送るだけであり、センサ管理システムが、センサを利用するのに必要とされる探索及び他の処理手順を実行して、最終的にはセンサの各参照情報を返す。センサの利用可能性が変化した場合、センサ管理システムは、現在使用中のセンサを他の適切なセンサと交換するか、それが不可能な場合はコンテキストグラフ管理部に失敗を報告することができなければならない。
【００２１】
センサ管理システムは、要求されたリソースを検出及び利用するために多数の異なるセンサを取り扱わなければならない。センサは、好ましくは、コンテキストソースが必要とする情報の種類に応じて分類され、この分類は典型的には直交的なものではなく、すなわち、あるセンサは、２つ以上のクラスに属することができる。センサクラスの具体例として、例えば、センサの移動性、アクセスしやすさ、アドレスの可能性等がある。移動性クラスは、典型的には、固定であるか移動できるか等のセンサの移動特性に関する。固定センサは、地理的に固定された位置にあり、同じ通信手段、例えばインターネットによって、常にアクセス可能であることが多い。一方、移動センサ、すなわち移動可能なセンサは、利用可能性が変動するような様々な通信手段を用いる可能性があり、また、得られる情報は、現在の状態に応じて異なる。コンテキスト作成システムにより定義される環境に対して移動するセンサの場合、典型的には、利用可能性の変化を補償する手段が必要である。
【００２２】
センサアクセス可能性クラスは、ローカル的にアクセス可能なセンサと包括的にアクセス可能なセンサとを区別する。ローカルセンサは通常、それを必要とするコンテキストシステムに地理的に近いときにのみ使用することができる。なお、近くの装置のインタラクションを介してアクセスできるセンサも、ローカルセンサとみなされる。センサは、アクセス可能性の種類に応じたそれぞれの方法で、検出及び探索しなければならない。したがって、コンテキストソースがあらゆる基本的な技術ともインタラクションを行わなくてもよいようにするセンサ検出及び探索を実現することが、センサ管理システムの必要条件のひとつである。
【００２３】
第３のセンサクラスであるセンサアドレス可能性クラスは、センサの固定的利用に対する、パラメータ化されたアドレス可能性に関する。幾つかのセンサは、どのような種類の情報が必要かを記述する入力パラメータを必要とする。一例として、移動体通信のためのグローバルシステム（Global System for Mobile Communications（以下、ＧＳＭと略す））における位置検索センサがある。この場合、値を返すために、位置を探索される人物の電話番号が必要である。一方、固定的利用のセンサは、いずれのパラメータも不要であり、使用可能な値を返すだけである。この種のセンサの一例としては、室内温度センサがある。パラメータ化センサは、利用のステップ毎に必要なパラメータを送る必要がある。なお、上述のセンサクラスは、コンテキストソースにより利用可能なセンサの分類特性を限定するものではなく、例えば、センサの空間的参照に関するクラス等、他のセンサ分類も同様に可能である。
【００２４】
コンテキスト情報をクライアント４に供給するコンテキスト作成システム５を、センサに関連した処理から解放するために、本発明では、図１に示すように、コンテキスト作成システム５のコンテキストソース２と、要求されたセンサデータをコンテキストソース２に提供する候補を表すセンサ３及び３’との間の通信パス内に配置されたセンサ管理システム１を提案する。
【００２５】
本発明に基づくセンサ管理システムは、可能なセンサの探索、センサの利用可能性の変化の管理、各センサのアドレッシングの詳細に関する情報の収集を担う。センサ管理システムは、コンテキストソースと、コンテキストソースが利用できるセンサとの間の通信リンク内に配置されているので、まず、コンテキスト作成システムとセンサ間の通信方式について説明する。コンテキスト作成システムは、コンテキストソースがコンテキスト作成システムに対するセンサの抽象的概念を示すように、コンテキストソースを介してセンサと通信を行う。最も単純な場合、コンテキストソースとそれに対応するセンサとの通信は、図４に示すように形成される。この場合、コンテキストソース２＊はセンサ３＊と直接通信を行い、このため、コンテキストソース２＊とセンサ３＊の両方が、両者間でデータ交換を可能にする通信手段を備えている必要がある。
【００２６】
通信方式を高いレベルで示すと、図２に示す構成となる。センサアクセスオブジェクト６は、センササービス７へのアクセス及び問合せを行うのに必要な機能を実現する。これには、センササービス７から情報を検索し、必要に応じてセンササービス７に対してセンサ３の初期化及びパラメータ化を行うのに必要な通信プロトコル及び新たな手段が含まれる。センササービス７は、ダイレクトリンク又はネットワークリンク内のセンサ３を仮想的に表したものであり、センサ３のアドレシングを可能にする。ローカルセンサの場合、センササービス７は単純なドライバに降格される。いずれの場合も、センササービス７は、センサ３との直接通信を取り扱い、センサ３を発見できるようにするとともに、センサアクセスオブジェクト６によって使用できるようにする。センサアクセスオブジェクト６は、センササービス７に対するセンサアクセス方法を実現する。
【００２７】
図２に示す構成要素はいずれも、図３の階層図に示すように、様々なノード上に存在することができる。なお、構成要素をノードに分散させることは、必ずしも必要ではない。特に、多くの場合、センサアクセスオブジェクト６とセンササービス７は、図４に示すように、コンテキストソース２＊又はセンサ３＊に統合されるからである。上述の構成要素の３つ以上を１つに統合することも可能である。しかしながら、機能ブロックは、図に示すように存在し続ける。
【００２８】
本発明に基づく図２の通信方式の実施例を図５に示す。コンテキストシステム固有の構成要素としてのコンテキストソース２は、センサ３によって利用可能なコンテキスト情報の要求を多数のコンテキストグラフから送る。この要求は、要求されたセンサ情報を提供する適切なセンササービス７に向けられる。さらに、コンテキストソース７は、何らかの単純なデータ交換を行って、センササービス７からのデータをコンテキストシステムの内部表現に合わせる。センササービス７に接続されたセンサ３は、実際の物理的又は論理的な情報ソースである。センサ３は、センササービス７を介してアクセスされる。センサ管理システム１は、あるセンサ３に対する要求をコンテキストソース２から受信し、それに応じて、要求されたセンサ３を表す受信要求に対応した問合せをセンササービス７に供給する。
【００２９】
センサ管理システム１は、図５に示すように、コンテキストソース２とデータを交換するためのコンテキストソースインタラクション手段８を備えている。コンテキストソースインタラクション手段８は、専用のアプリケーションプログラマブルインターフェース（application programmable interface（以下、ＡＰＩと略す））、所謂センサ管理ＡＰＩとして実現される。コンテキストソース２からのあるセンサに対する要求は、センサ管理ＡＰＩ８により受信される。この要求は、センサの種類、センサ出力、センササービスアクセスプロトコル等の必要なセンサ特性に加えて、センサアクセスオブジェクト及びパラメータも含んでいる。
【００３０】
センサ管理システム１は、要求された特性に対応するセンササービスをサーチすることにより、適切なセンサの探索を行う。適切なセンサが見つからない場合、コンテキストソース２に対してエラーを報告する。各サービスの提供を可能にするため、センサ管理システム１は、ローカル的及び遠隔的に利用可能なセンサを永続的にチェックする、あるいはコンテキストソース２が要求したセンサをセンサ管理システム１が既知でない場合に特殊サーチを行うセンササービス発見手段９を備えている。発見されたセンササービス７についての探索情報に関する情報は、センササービス発見手段９内に格納される。コンテキストソース２からの要求において定義されているセンサ特性に対応して、センサ管理サービス１０は、適切なセンサの探索を行い、センサアクセスオブジェクト手段６において与えられた方法により、そのセンサを探査（probe）する。探査により、提示されたセンサが実際に適切であること、及びそのセンサへのアクセスが本当に可能であることが保証される。探査の次のステップはセンサのインスタンス化（instantiating）、すなわちセンサに対して実際の通信リンクを確立することである。多くの場合、探査及びインスタンス化は密接に結び付いているが、これを行うのに完全に別々の構成要素が必要となる場合もある。センササービス７を介したセンサ３の探査及びインスタンス化は、各センササービス７に対して問合せを行うセンサアクセスオブジェクト手段６により行われる。センサアクセスオブジェクト６手段が行う問合せは、コンテキストソースインタラクション手段８が受信した要求と、センサ管理サービス１０がセンササービス発見手段９から判定した特定の探索情報とに基づく。コンテキストソース２からの要求にセンサアクセスオブジェクトが既に含まれている場合、このセンサアクセスオブジェクトはセンサアクセスオブジェクト手段６により各センササービス７に送られる。コンテキストソース２からの問合せにおいて与えられるパラメータには、要求側のエンティティ、所望のサービス品質等についての情報が含まれることもあるが、これらのパラメータもセンサアクセスオブジェクト手段６に送られ、センササービス７への問合せに組み込まれる。
【００３１】
センサアクセスオブジェクトは、センササービス７から、したがってセンサ３からの情報を問い合わせるメインロジックを含んでいる。センサアクセスオブジェクトは、コンテキストソース２又はセンササービス７のいずれからも検索することができる。さらに、センサ管理システム１は、格納部、例えばセンササービス発見手段９に格納された探索情報等の、以前に発生した各センサアクセスオブジェクトを保持し、各センサへの再アクセスが必要となった場合に再使用することができる。
【００３２】
センササービス２は、事実上、センサ３を表すものであることから、いずれの直接的な探索又は発見の要求に応じる。したがって、センササービス２は、センサ管理システム１の主たるアクセスポイントである。このため、センササービス発見手段９は、利用可能な全てのセンササービス７とそれらの特性からなるリストを維持している。コンテキストソース２からの要求に合致するセンササービス７を見つける手段は、センサ管理サービス１０として実現される。
【００３３】
センサは非常に低レベルの構成要素であるので、通常、コンテキスト作成システムと直接通信を行うことができない。また、センサは暗示的にのみ発見可能であり、コンテキストシステムと接触するための対応するセンササービス７がない場合もある。このため、センサは、各センササービス７のインスタンス化を介してコンテキストシステムによってのみアクセス可能である。
【００３４】
センサ管理ＡＰＩは、関心のあるオブジェクトに対してシステム内で発生した全てのイベントを伝達するイベント登録及びイベント通知手段を与える。
【００３５】
センサ管理システム１は、コンテキストソース２がセンサの特性を特定することを可能にする。これには、例えば、あるエンティティに関連するセンサの固有パラメータが含まれてもよい。さらに、ソースは、高度にカスタマイズされた方法でセンサと通信を行う自身のセンサアクセスオブジェクトを実現することができる。最後に忘れてはならないのが、コンテキストソース２は、センサアクセスオブジェクトとセンササービスとを介して送られるパラメータを明示的に特定できるということである。
【００３６】
上述のセンサ管理システム１の設計によれば、センサを使用するために以下のステップを行わなければならない。第１に、コンテキストソース２は、必要な属性をセンサ管理システムに送ることにより、ある特性を有するセンサをセンサ管理システムに要求する。また、コンテキストソース２は、使用されることを希望しているセンサアクセスオブジェクトも送ることができる。コンテキストソースが要求においてセンサアクセスオブジェクトを与えなかった場合、センサ管理システムは、センササービス７により与えられたセンサアクセスオブジェクトの使用を試みて、これも失敗した場合は、第三者から検索されたセンサアクセスオブジェクト、又は、以前の要求からキャッシュされたセンサアクセスオブジェクトが使用可能であれば使用する。いずれの適切なセンサについてもセンサアクセスオブジェクトが使用可能でない場合、コンテキストソースに対してエラーを報告する。第２に、センサ管理システム１は、対応するセンササービスをサーチすることにより、適切なセンサの探索を行う。各センサが見つからなかった場合、コンテキストソース２に対してエラーを報告する。第３に、適切なセンササービスが見つかった場合、センサアクセスオブジェクトと、コンテキストソースに返されたセンサアクセスオブジェクトの参照情報とを用いてセンササービスを探査する。
【００３７】
センサアクセスオブジェクト手段６は、センササービス７からセンサデータを検索して、そのセンサデータをコンテキストソース２に供給するため、センササービス７に問合せを送るデータアクセス構成要素１２を備えている。センサアクセスオブジェクト６は、さらに、センサインスタンス化及び探査手段１１を備えている。この構成要素１１は、センサのアクセス可能性及び／又はコンテキストソース２の要求に対応する適性に関して、センササービス７を介してセンサ３を探査する。手段１１は、さらに、コンテキストソース２の特定の要求に対応するセンサ３に接続された特定のセンササービス７に対して通信リンクを確立することにより、センサ３のインスタンス化を行う。
【００３８】
上述のセンサ利用は、センサ及びセンサ探索／発見メカニズムを記述する手段により達成される。センサ管理システム１は、コンテキストソースにとってトランスペアレントな方法で、可能なセンサの利用可能性の変更に対処する。センサの能力を記述するのに、インターフェース記述は必要ない。その知識は、既にセンサアクセスオブジェクトにおいて本質的に使用可能だからである。
【００３９】
センササービス発見手段９により行われるセンサの発見は、２つの側面から構成されている。第１の側面は、周辺領域にあるセンサを見つけることであり、第２の側面は、例えば、インターネット等、広範囲の通信手段により接続することができるセンサを探索する何らかの手段を実現することである。
【００４０】
使用される発見メカニズムとは無関係のセンサ探索を行うことができるようにするため、図６に示すように、センサ発見抽象化レイヤ９＊を導入する。このレイヤ９＊により、種々のサービスプロバイダ１３を使用して、問合せ側から単一化したセンサ記述を得ることで適切なセンサを見つけることができるようになる。サービスプロバイダは、あるセンサが利用可能となった場合にアクティブ情報プル又は情報プッシュを実行するか、要求に応じてセンサをチェックする反応方式を実行すればよい。また、センサ管理システムは、既知の全てのセンサとそれらの属性を格納するデータベース９ａを保持している。サービスプロバイダ１３は、センサの損失を報告しなければならず、これにより、対応するエントリがセンサデータベース９ａから削除される。
【００４１】
センサへのアクセス方法の詳細な知識は、センサアクセスオブジェクト内にカプセル化される。センサへの接触が失われた場合、センサアクセスオブジェクトは、関係のある構成要素にイベントを発するか、コンテキストソースにこの障害を通知すればよい。まず、センサ管理システム１は、可能であれば、他のセンサに切り換えることにより補償を行おうとする。これが失敗した場合、センサ管理システムは、コンテキストソース２に通知を行い、コンテキストソース２が、他のセンサ３に切り換えるか、可能であれば他のセンサカテゴリーに切り換えることを決定する。さらに、コンテキスト作成システムにおけるコンテキストグラフの再構成を要求してもよい。これが不可能である場合、グラフ全体が無効とされ、作成し直される。
【００４２】
原則として、センサアクセスオブジェクトは、センサへのアクセス方法に関する全知識をカプセル化する。また、これには、どのパラメータが使用可能であるか、及び、どのようにしてパラメータをセンササービスに送るかという情報が含まれる。しかしながら、完全なパラメータセットが使用可能ではないセンササービスに、センサアクセスオブジェクトがアクセスできるようにすることが有用となる場合もある。これを行うため、センサ管理システム１はセンサアクセスオブジェクトに代わって幾つかのパラメータを供給すればよい。
【００４３】
例えば、あるセンササービスは、データにアクセスするためにログインとパスワードの組み合わせを必要とする。センサアクセスオブジェクトが、この情報の供給、検索、センサへの伝送を行う方法について知らない場合、センサ管理システム１が、センサアクセスオブジェクトに代わって、この情報を供給すればよい。ここで、センサ管理システムは、センササービスのパラメータをどのように特定するかについて認識していなければならない。これは、どのようにインターフェースが記述されているか、及び、どの程度パラメータがセンサ管理システムに知られているかによって異なる。
【００４４】
センサ管理システムが対処しなければならない重要な問題のひとつは、上述のように、要求されたセンサの探索である。これには、基本的な技術とは無関係のセンサ記述手段必要である。
【００４５】
センサ等のリソースを記述するひとつの方法は、インターフェースに基づくものである。この場合、各リソースは、その能力の記述に使用されるインターフェースをエクスポートする。また、オブジェクト内の属性値を用いて、リソース特性を記述することもできる。あるリソースが要求されている場合、クライアントとなりうる側が、オブジェクトと、内在的にある値を有する多数の属性とともに、サービスを記述するインターフェースを各通信相手に送る。対応するインターフェース／オブジェクトリソースの記述は、例えば、Ｊｉｎｉシステムを使用している。このような解決方法の主な問題点は、それが基本的なプログラミング言語に大きく依存していることである。例えば、Ｊｉｎｉは、Ｊａｖａ（登録商標）で実現される全ての構成要素に依存する。
【００４６】
あるプログラミング言語やモデルに厳格に束縛されるのを避けるため、他のシステムは、メタ言語ベースのアプローチを採用して、サービス特定情報の容易な交換を可能にしている。このアプローチでは、所定の言語を使用して、サービス特性と、おそらくそのインターフェースとが記述される。例えば、ウェブサービス記述言語やＵＰｎＰデバイステンプレートにより可能な実施例がある。
【００４７】
極少数のソースしか使用可能でない場合、共通のネーミングが可能である。あるセンサが要求された場合、そのソース名を介して探索又は参照を行うだけあり、能力や属性をさらに特定する必要はない。ＵＰｎＰは、所定の機能を提示する所定のサービスセットを与えることにより、少なくとも部分的にこのような方式を実現する。このようなサービスの場合、能力やインターフェースに関する知識が既に一般的に入手可能なので、それについての情報は必要ない。
【００４８】
したがって、本発明は、要求されたセンサをセンサ管理部９に対して特定する解決方法を用いる。これは、センサ発見抽象化レイヤにおける対応するサービスプロバイダにより、各リソース発見手段で理解されるフォーマット又はプロトコルに変換される。提案されたＸＭＬベースの記述は、主として、単純のキー値の対に基づいている。以下の例に示すように、センサ記述から、あるセンサを識別するのに使用される多数のキー値が設定される。
【００４９】
<sensor>
<sensor_type>temperature</sensor_type>
<sensor_format>degrees_celcius</sensor_format>
<sensor_id>000-000-000-000-000-000</sensor_id>
<input type="optional" format="int">accuracy</input>
<input type="optional" format="int">init_reset</input>
<access_method protocol "HTTP" version="1.0" type="pull">
<param name="URL">http://nowhere.org:8080/sensor</param>
</access_method>
<access_method protocol="RMI" version="1.3" type="push">
<param name="URL">rmi://nowhere.org:3128/sensor</param>
<param name="RMIServerClass>"org.nowhere.ServerImpl</param>
</access_method>
<attributes>
<param name=”sampling rate” unit=”seconds”>10</param>
<param name=”location”>Room 33.37</param>
</attributes>
</sensor>
【００５０】
コンテキストソースは、多数のセットをセンサ管理システムに送ることができる。いずれかのセットについて合致するセンサが見つけられた場合、センサ管理システムは、どのセットがセンサアクセスオブジェクトに適合するかを示し、センサアクセスオブジェクトは、可能であればアクセス方法を変更することができる。
【００５１】
記述手段に加えて、問合せ言語も発展させることができる。これにより、高レベルの問合せ言語を介して、あるセンサについての問合せ、又は、あるセンサ値の問合せまで行うことが可能となる。
【００５２】
センサ管理システムがセンサアクセスにおける障害に気付いて対応することができるようにするため、図７に示す各センサ管理システムアーキテクチャの高レベル図に示すように、センサ管理システム１においてセンサプロキシ１４を用いることができる。コンテキストソース２が、あるセンサ３を要求し、センサアクセスオブジェクト手段を介したセンサ３の探査が成功すると、センサアクセスオブジェクトは、センサプロキシ内にカプセル化され、データアクセス用にコンテキストソースに返される。プロキシオブジェクトにより、センサ管理システム１は、センサアクセスオブジェクト手段６とコンテキストソース２の間の通信に接続することができるので、発生する障害やエラーをチェックし、それに応じて動作することができる。
【００５３】
より高度なセンサ管理システム１を図８に示す。これは、センサ利用の最適化や、より高度なセンサメンテナンスメカニズム等の側面をも含む。これにより、システムは、より良好な設定が達成されたとわかった場合、センサの交換を行うことができる。センササービス発見手段９は、センサメンテナンス手段１５とセンサ利用最適化手段１６とにより補完されている。センサアクセスオブジェクト手段は、センサリリース手段１７により拡張されている。センサメンテナンス構成要素１５は、既知のセンサのいずれについても利用可能性をチェックし、特にコンテキストソース２により現在使用されているセンサの利用可能性をチェックする。あるセンサ３が利用可能となると、センサデータベースの更新を開始して、センサ管理サービス１０にその旨を通知する。センサ３がもはや存在しないか否かを判定するのにセンサ固有の知識が必要となる場合もある。このため、センサメンテナンス手段は、例えば、センサを探査するためにセンサアクセスオブジェクト機能を利用することができる。また、センサ管理システムにより現在使用されているセンサプロキシ手段１８からのセンサプロキシを監視してもよい。センサ利用最適化構成要素１６は、現在使用されているセンサと最近見つかったセンサとを監視する。センサ利用最適化構成要素は、使用されたセンサ３を他の適切なセンサと交換することができるか否かをチェックしようとする。例えば、ソース、通貨単位等に対してセンサ３の利用コストが非常に高く、他の比較的安価なセンサが利用可能となる場合、センサ利用最適化構成要素１６は、センサの交換を初期化しようとする。より複雑な場合、センサ利用最適化構成要素１６は、いずれかの構成要素が要求する場合、多数のセンサを組み合わせて、より複雑なひとつのセンサを作成しようとする。
【００５４】
センサプロキシ構成要素１８は、センサアクセスオブジェクトとセンササービスとの間の調停手段として使用されるオブジェクトである。これにより、センサ管理サービス１０は、通信に立ち入って、障害が発生したか否かを判定することができる。なお、このメカニズムは、追加的知識がなければ、幾つかのセンサについてしか作用しない。例えば、コンテキストソース２とセンササービスとの通信が暗号化されている場合、発生した障害に関する詳細を判定することは不可能である。しかしながら、例えば、センサからの情報を要求するときのタイムアウト等、他の種類の障害については、容易に捕捉し、伝達することができる。したがって、センサプロキシは、現在使用されているセンサ３に応じて動作をカスタマイズするように設定及び拡張が可能である。
【００５５】
センサアクセスオブジェクト手段は、センサ３にアクセスするための実際のプログラムロジックをカプセル化する。それに関する詳細は既に説明済みである。図８の拡張されたセンサアクセスオブジェクト６は、センサ探査及びインスタンス化手段１１と、データアクセス手段１２と、センサリリース手段１７という、３つの機能ブロックを備えている。センサを探査することにより、そのセンサが実際に使用できるか否か、及び、そのセンサが本当に利用可能であるか否かを判定する。探査機能は、センサにアクセスしようとするときだけでなく、センサメンテナンス手段１５等、他の構成要素によっても使用されること可能である。しかしながら、主機能はデータアクセスであり、これは、センササービス７からセンサデータを検索するのに必要な通信、プロトコル、セキュリティに関する事項を含んでいる。最終的に、センサが必要なくなった場合、あるいは、センサが利用不可能になった場合、何らかのリリース処理手順が必要となる。
【００５６】
センサ管理システム１の使用方法と能力を例示するため、具体的な適用例を図９に示す。この例の場合、移動ノードからなるネットワークで、アドホックネットワークにおけるように、いずれのノードも他のノードとの物理的距離を測定することができるネットワークを備えている。距離測定の精度を高めるため、ノードは、ローカル情報だけでなく周辺環境にある全てのノードからの値を用いる。これは、他のノードが全地球測位システム（Global Positioning System（以下、ＧＰＳと略す））から得た位置情報等の追加情報を供給する場合に特に有用である。
【００５７】
アドホックネットワークの性質上、周辺環境におけるノードは頻繁に変わる。これは、図９に示すようにノードが移動体である場合に特にあてはまる。既に説明したように、この例の場合、本質的な距離測定はひとつの情報ソースにしかならない。ＧＰＳセンサ、屋内追跡システム等から、考慮すべき他のデータが発生する。周辺環境における全てのソースを見つけ、距離又は位置算出を行うインスタンスに対して利用可能としなければならない。種々の情報ソースの管理の問題は、多数の異なるセンサを管理しなければならない場合に、より一層厳しくなる。
【００５８】
センサ管理システム１は、周辺環境における変化を追跡し、存在するいずれのセンサ３をも見つけようとする。上述の例の場合、これには、他のノードの距離測定センサ３、周辺環境におけるＧＰＳセンサ等が含まれる。また、センサ管理システム１は、センサを利用しているインスタンスに代わりノードが移動するにつれて、使用されたセンサを他のセンサと交換しようとする。適切なセンサが存在しない場合、センサ管理システムは、多数のセンサを用いて、要求に適する新たな仮想センサを作成しようとする。例えば、クライアントが３次元位置を要求しているが、２次元位置と高度センサのみ利用可能である場合、センササービスは、これら２つから仮想的な３次元センサを作成しようとすることができる。さらに複雑ないずれの動作であっても、コンテキストシステム内で動的に行われる。
【００５９】
概して、センサデータを要求するインスタンスは、周辺環境における変化を自信で追跡しなければならないという負担から解放される。
【図面の簡単な説明】
【００６０】
【図１】本発明に基づくセンサ管理をコンテキスト供給システムに統合した状態を示す図である。
【図２】コンテキストソースをセンサにリンクする通信方式の原理を示す高レベル図である。
【図３】論理的処理の観点から図２の通信方式の原理を示す図である。
【図４】構成要素を統合した場合の、図２の通信方式の原理を示す図である。
【図５】本発明に基づくセンサ管理システムを用いて、通信方式を実現する場合を示す図である。
【図６】センササービス発見手段の抽象化レイヤを示す図である。
【図７】センサプロキシを組み込んだセンサ管理により、図２に係る通信方式を実現する場合を示す図である。
【図８】本発明に基づくセンサ管理システムのさらなる実施例の拡張アーキテクチャを示す図である。
【図９】本発明に基づくセンサ管理システムを、移動ノード上に存在するコンテキストシステムに適用する例を示す図である。
【図１】
2005260914.tif 000003
【図２】
2005260914.tif 000004
【図３】
2005260914.tif 000005
【図４】
2005260914.tif 000006
【図５】
2005260914.tif 000007
【図６】
2005260914.tif 000008
【図７】
2005260914.tif 000009
【図８】
2005260914.tif 000010
【図９】
2005260914.tif 000011
【外国語明細書】
2005260914.tif 000012
2005260914.tif 000013
2005260914.tif 000014
2005260914.tif 000015
2005260914.tif 000016
2005260914.tif 000017
2005260914.tif 000018
2005260914.tif 000019
2005260914.tif 000020
2005260914.tif 000021
2005260914.tif 000022
2005260914.tif 000023
2005260914.tif 000024
2005260914.tif 000025
2005260914.tif 000026
2005260914.tif 000027
2005260914.tif 000028
【図１】
2005260914.tif 000029
【図２】
2005260914.tif 000030
【図３】
2005260914.tif 000031
【図４】
2005260914.tif 000032
【図５】
2005260914.tif 000033
【図６】
2005260914.tif 000034
【図７】
2005260914.tif 000035
【図８】
2005260914.tif 000036
【図９】
2005260914.tif 000037