JP2007514996A - モバイル・ハブおよびモバイル・ハブでのイベント管理 - Google Patents

Abstract

【課題】モバイル・ハブを提供すること。
【解決手段】イベントを保管する環状バッファ（１１）と、前記バッファ（１１）に保管されたイベントのストレージ期間を監視するタイマと、関連するタイマのタイムアウトを過ぎたときにイベントを前記バッファから破棄するように設計されたイベント・マネージャ（１２）とを含むモバイル・ハブを提案する。イベントが、もはやバッファ（１１）をブロックしないので、小規模なバッファ（１１）をモバイル・ハブ（１）に使用することができる。
【選択図】図２

Description

本発明は、モバイル・ハブおよびモバイル・ハブでイベントを管理する方法に関する。

パーソナル・モバイル・ゲートウェイまたはパーソナル・モバイル・ハブという概念は、通常は中央処理装置ＣＰＵ、ランダム・アクセス・メモリＲＡＭ、不揮発性ＮＶストレージ、ローカル無線ネットワーク・テクノロジへのインターフェース（例えば、Ｂｌｕｅｔｏｏｔｈ）、または無線広域ネットワーク・テクノロジへのインターフェース（例えば、ＧＳＭ／ＧＰＲＳ）、あるいはこれらの組合せを有するモバイル・デバイスという概念を中心に展開される。

モバイル・ハブの魅力的な応用領域が、センサ・デバイスおよびアクチュエータ・デバイスが例えばＢｌｕｅｔｏｏｔｈを介してモバイル・ハブに接続される、ヘルス・ケア／医療／製薬応用領域である。各センサは、周期的にセンサ値をモバイル・ハブに送信するか、またはモバイル・ハブ上で稼動するアダプタによってポーリングされる。アクチュエータ・デバイスは、同様に、モバイル・ハブをポーリングすることによって、またはモバイル・ハブ上で稼動するアダプタによって接続されることによって、時々モバイル・ハブ・デバイスから指示を受信する。モバイル・ハブでは、センサ・データが分析され、おそらく他のセンサ・デバイスのデータと相関される必要があり、ネットワーク・ベースのサービスに中継される場合もある。通常、これらのデータは、離散的な性質を有し、各センサ値を、１つのイベントとして扱うことができる。したがって、各センサは、無線通信リンクを介してイベントのシーケンスをモバイル・ハブにサブミットする。同様に、モバイル・ハブの内部プロセスが、イベントを生成することができる。もちろん、これらの内部的に生成されたイベントまたは外部デバイスから受信されたイベントを、モバイル・ハブ上のコンシューマまたはモバイル・ハブの外部のサービスあるいはこの両方から使用可能にすることが必要である場合がある。したがって、イベントを処理し、これらを正しい形で配布するために、モバイル・ハブは、イベント・マネージャとも呼ばれるイベント・エンジンを必要とする。

したがって、イベント・システムが、かなり以前から既知であり、同期式イベント・システムおよび非同期式イベント・システムがある。

同期式イベント・システムでは、イベントが、葉から根までの階層経路に沿って伝搬される。各エンティティが、受け取ったイベントを順番に操作する。

非同期式イベント・システムの最もよく知られた例の１つが、Ｌｉｎｄａ ＴｕｐｌｅｓｐａｃｅシステムまたはＩＢＭ社のＴ−Ｓｐａｃｅｓである。この場合に、イベントは、イベント・ソースによって中央「ブラックボード」（データベースとして実装される）にポストされる。次に、イベント・コンシューマが、パターンを指定してブラックボードを検索するか、そのイベント・コンシューマが関心を持つタプルの式を検索する。

同期式イベント・システムの主な利益は、登録された各エンティティ（エンティティは登録しなければならない）が、１回呼び出されることが保証されることである。呼出しチェーンの終りに、あるイベントが処理されたことが確かにわかる。また同期式イベント・システムは、定義により、登録されたイベントが呼び出される、ある順序を課す。適当な戻り値を使用することによって、処理チェーン内で後にあるエンティティへのイベントの送達に影響することが可能である。同期式モデルのこの利益は、それと同時に、その最大の不利益でもあり、例えば、入出力動作が、完了に長い時間を要する可能性がある。そのイベント・ハンドラが呼び出され、イベント・ハンドラの一部として入出力動作を開始するエンティティが、その結果、ブロックされ、同期式イベント・システム全体をブロックする場合がある。また、イベントを処理するエンティティが、呼び出される前にブロックされ、したがって、イベント・システムをブロックする場合がある。

非同期式イベント・システムは、この特定の問題をこうむらない。この場合に、すべてのイベント・リスナが、新しいイベントに関して同時に知らされるか、または関心を持つエンティティが、新たに到着したイベント自体についてイベント・システムを定期的にポーリングするかのいずれかである。その一方で、非同期式イベント・システムでは、イベント・クロージャ（event closure）すなわち、すべてのエンティティがイベントを見たことを述べることが、どちらかといえば難しく、順序を実施することは、ほとんど不可能である。また、タプル／ブラックボード・ベースのシステムでは、データベースをサポートしなければならず、ポストされたイベントに対するガーベッジ・コレクションを行わなければならないという問題がある。

２００３年８月１８日に検索され、インターネットhttp://www.prismtechnologies.com/English/Products/CORBA/Integration/whitepaper_jms/jms_BR_12_00.pdfでアクセスされた"Java（Ｒ）Message Service - A White Paper, December 2000"に、データベースの使用に基づくそのような非同期式イベント・システムが示されている。

したがって、非同期式イベント・システムは、スープ・モデル（soup model）またはポンド・モデル（pondmodel）として特徴を表すことができ、イベントが、グローバル・スープまたはグローバル・ポンドにダンプされる。イベント・サブスクライバは、そのスープ／ポンドを検索する。同様に、同期式イベント・システムは、フラッシュ・モデルとして特徴を表すことができ、あるイベントが、すべてのサブスクライブしたエンティティにフラッシュされる。

モバイル・ハブなど、例えば無線広域ネットワーク・コンポーネント（ＷＷＡＮ、例えばＧＰＲＳ）、無線ローカル・エリア・ネットワーク・コンポーネント（ＷＬＡＮ、例えばＢｌｕｅｔｏｏｔｈ）、ならびにローカル揮発性ストレージおよびローカル不揮発性ストレージを有するＣＰＵを有する携帯電話プラットフォームとすることができる、モバイル・デバイスは、そのハブの性質によって特徴を表される。センサ、デバイス、またはアプライアンスなどの外部エンティティは、ＷＬＡＮを介してモバイル・ハブに接続され、ハブ上で稼動するソフトウェア・コンポーネントにデータを供給する。これらおよび他のソフトウェア・コンポーネントは、受け取ったデータをある形で処理し、次に、ＷＷＡＮを介して、インターネット内のどこかで稼動するサービスにデータを供給する。

そのようなモバイル・ハブが、２００３年８月１８日に検索され、インターネットhttp://www.ixi.com/PDF/IXI_Brochure.pdfでアクセスされたパンフレット"IXI- Connect with style"で対処されている。

同期式イベント・システムは、実行されなければならない固有の入出力動作に起因して、モバイル・ハブに必要な処理を実行するのに適さない。その一方で、非同期式イベント・システムは、モバイル・デバイス自体の側で維持されるデータベースを必要とするので、やはり特に有用ではない。そのようなデータベースは、通常はポータブルな特性に起因してわずかなリソースを提供するという特徴があるモバイル・デバイス上で多数のリソースを必要とする。
"Java（Ｒ） Message Service - AWhite Paper, December 2000",http://www.prismtechnologies.com/English/Products/CORBA/Integration/whitepaper_jms/jms_BR_12_00.pdf "IXI - Connect withstyle", http://www.ixi.com/PDF/IXI_Brochure.pdf

したがって、モバイル・デバイスに適すると同時に、入出力動作をブロックすることによって導入される複雑さを扱うことができるイベント管理システムの必要がある。

本発明の一態様によれば、イベントを保管する環状バッファと、前記バッファに保管されたイベントのストレージ期間を監視するタイマと、関連するタイマのタイムアウトを過ぎたときにイベントを前記バッファから破棄するように設計されたイベント・マネージャとを含むモバイル・ハブが提供される。

本発明のもう１つの態様によれば、環状バッファにイベントを保管するステップと、保管されたイベントのストレージ期間を監視するステップと、前記ストレージ期間がタイムアウトを過ぎたときに前記バッファから前記イベントを破棄することとを含む、モバイル・ハブでイベントを管理する対応する方法が提供される。

モバイル・ハブは、無線の形でモバイル・ハブに接続されたエンティティを相互接続する中央デバイスとして使用されるモバイル・デバイスを表す。したがって、モバイル・ハブは、モバイル・ネットワーク・ノードの機能を受け入れる。モバイル・ハブの機能は、例えば、独立型デバイスで実装するか、携帯電話機に統合することができる。

外部エンティティは、モバイル・ハブに接続するかまたは接続されることができ、データを送達するかまたは受信することができる。そのようなエンティティの例が、センサまたはアクチュエータである。モバイル・ハブによって受信されるメッセージを、本発明の文脈では「イベント」と呼ぶ。

モバイル・ハブの核を、イベント・エンジンまたはイベント・マネージャと呼ぶ。イベント・マネージャは、ハードウェアで、ソフトウェアで、またはハードウェアとソフトウェアの組合せで実装することができる。イベント・マネージャは、モバイル・ハブ内でイベントを処理するように設計され、特に、到着するイベントに反応し、またはハブの外の世界にイベントを通信し、あるいはその両方を行うために設計される。イベントは、通常、後で詳細に説明するアダプタによってイベント・エンジンにポストされる。イベント・マネージャは、小さい限られた一時バッファにイベントを保管し、イベントのタイマをセット・アップする。タイマの開始点は、イベントがバッファに保管された時点であることが好ましいが、必ずしもそうである必要はない。タイマは、ハードウェアで、ソフトウェアで、またはハードウェアとソフトウェアの組合せで実装することができる。イベント・マネージャは、タイマがタイムアウトを過ぎたときに、バッファの最後からイベントを破棄する。本発明のいくつかの好ましい実施形態で説明するように、タイマのタイムアウトに達する前にイベントが既に破棄されているときには、タイマが、通常はリセットされ、いずれにせよタイムアウトに達しない。

この種のイベント処理は、あるイベントが、イベント・マネージャによって処理されなければならない他のイベントのために限られたバッファ・セルをブロックすることができないことを保証する。その結果、イベントは、タイマのタイムアウトによって決定される最大時間／ストレージ期間の間だけバッファ内に存在し、保管されることができる。

イベントを、モバイル・ハブに到着した直後にバッファに保管することができる。代替案では、イベントを、まず一時的に一時ストレージまたはキャッシュに保管し、その後、環状バッファに転送することができる。環状バッファは、イベントを保管するための限られた空間を提供する。１つの好ましい実施形態で、２００個未満のイベントを環状バッファに保管することができ、もう１つの好ましい実施形態で、１００個未満のイベントを保管することができ、もう１つの好ましい実施形態で、環状バッファのサイズを、応用例に応じて構成することができる。

前に示したように、タイマのタイムアウトは、保管されたイベントをバッファから破棄すべき最後の時点であることが好ましい。好ましい実施形態によれば、バッファにイベントを保管し、対応するタイマを始動するのと一緒に、またはその前後の短い時間のうちに、イベント・エンジンが、イベントの到着についてすべてのまたは選択されたエンティティに通知する。しかし、登録されたエンティティの通知は、モバイル・ハブでのイベントの到着に付随することもでき、必ずしも、バッファへのイベントの到着またはこのイベントに関連する他のアクションに付随しない。通知に、そのイベントが含まれることが好ましい。エンティティが、選択的に通知されることだけが必要である場合に、イベント・マネージャは、登録リストに従ってすべてのエンティティに通知する。エンティティは、すべてのイベントまたは選択されたイベントだけについて通知されるために、登録リストに登録することができる。例えば、センサＢからの測定値がセンサＡでの測定をトリガしなければならないときに、外部エンティティ・センサＡが、イベントがセンサＢからモバイル・ハブに到着するときに通知されるために登録する。エンティティは、一般に、外部エンティティまたはモバイル・ハブ内部エンティティあるいはその両方である。エンティティの形にかかわりなく、そのような通知を見たエンティティは、肯定応答メッセージＡＣＫを用いて非同期に応答する。通知されたすべてのエンティティ（その結果、通知されるために登録リストに以前に登録したエンティティ）のすべてがＡＣＫメッセージを送った場合、またはこのイベントのタイマが満了した場合のいずれかに、イベント・マネージャは、単にそのイベントを破棄する。

この機構は、保管されたイベントがすべての関心を持つエンティティに既に世話されたかどうかについてイベント・エンジンが確信を持てない場合に、そのイベントによってモバイル・ハブがブロックされるのを防ぐ。その一方で、複雑なアクセスを含むデータベースは、不要である。その代わりに、イベント・マネージャは、上で述べた固定されたルールに従ってバッファ内のイベント循環を管理し、したがって、バッファがブロックされるのを防ぐ。したがって、このイベント処理解決策は、効率的であり、非常に適応可能であり、拡張可能である。どのイベントも、バッファをブロックすることが一切できないので、小規模なバッファをモバイル・ハブに使用することができ、これによって、モバイル・ハブが便利でポータブルになる。

モバイル・ハブは、保管されたイベントのすべてに、関連するイベントのストレージ期間を監視する対応するタイマが含まれるときに、イベントのブロックに対して特に抵抗力がある。次に、すべてのイベントが、バッファ内に限られた最大時間だけ常駐し、この最大時間は、イベントが破棄される前の関連するタイマのタイムアウトに対応する。

タイマのタイムアウトは、イベント到着レートに依存する可変タイムアウトとすることができることが好ましい。単位時間あたりにモバイル・ハブに到着するイベントが多いほど、タイムアウトが短くなる。単位時間あたりにモバイル・ハブに到着するイベントが少ないほど、モバイル・ハブの性能を劣化させずにタイムアウトを長くすることができる。

タイムアウトは、モバイル・ハブで稼動する種々のアプリケーションについて変更することもできる。その場合に、バッファの限られた部分を、例えば特定のアプリケーションに割り当てることができ、そのアプリケーションが、まれに到着するイベントに起因して、より長いタイムアウトを提供することができると同時に、バッファの残りの部分は、より頻繁な到着レートを有し、したがってより短いタイムアウトを有する別のアプリケーションに属するイベントのために予約される。イベント・マネージャは、イベントをアプリケーションに分類し、それに従ってめいめいのバッファ部分を充てんする責任を負うことができる。

モバイル・ハブに、従来技術で述べたモバイル・ハブによるハードウェア要素が含まれることが好ましい。具体的には、モバイル・ハブに、外部エンティティとの間でイベントを送信するか、受信するか、その両方を行うための無線ローカル・エリア・ネットワークへのインターフェースが含まれることが好ましい。そのようなＷＬＡＮへのアクセスに、例えば、８０２．１１仕様によるＷＬＡＮへのアクセスを含めることができ、Ｂｌｕｅｔｏｏｔｈへのアクセスを含めることができ、あるいはこの両方を含めることができる。それに加えてまたはその代わりに、モバイル・プラットフォームに、ＧＳＭ網、ＧＰＲＳ網、またはＵＭＴＳ網などの無線広域ネットワークＷＷＡＮへのインターフェースが含まれることが好ましい。センサ、デバイス、またはアプライアンスなどの外部エンティティは、ＷＬＡＮまたはＷＷＡＮあるいはその両方を介してモバイル・ハブに接続することができ、ハブで稼動するソフトウェア・コンポーネントにデータを供給することができる。外部デバイスは、ＷＬＡＮまたはＷＷＡＮあるいはその両方を介して送信されるデータの受取側とすることもできる。したがって、外部デバイスは、イベント・ソースまたはイベント・コンシューマのいずれか、あるいは同時にイベント・ソースとイベント・コンシューマの両方とすることができる。

モバイル・ハブ内部エンティティは、例えば、上で述べたソフトウェア・コンポーネントである。そのような内部エンティティは、イベントに作用し、さまざまな機能を提供することができる。内部エンティティに、ルータの機能を含めることができ、別の内部エンティティに、サーバの機能を含めることができるなどである。

内部エンティティは、受け取ったイベントをある形で処理する。内部エンティティは、例えば、ＷＷＡＮを介して、インターネットのどこかで稼動するサービスに処理されたデータを提供する。

モバイル・ハブ内部イベント表現が、外部エンティティが処理できるイベント表現と異なる場合があるので、モバイル・ハブに、イベントの内部表現を外部エンティティが理解できるイベントの表現におよびその逆に変換するアダプタが含まれることが好ましい。異なる外部エンティティが、モバイル・ハブ内の異なるアダプタを必要とする場合がある。

さらなる好ましい実施形態は、システム内のイベントに注釈を付ける可能性を含む。通常は固定された表記方式に従うイベントに、システムのエンティティによって注釈を付けられることが好ましい。これは、好ましくは、内部エンティティおよび外部エンティティが、さらなるアクションを開始するために、受け取ったイベントに注釈を付けられることを意味する。そのようなイベントは、注釈と一緒に、通常、モバイル・ハブのイベント・マネージャに送り返され、それ相応に処理される。イベント・マネージャは、登録されたエンティティに注釈を配布することが好ましい。イベントに注釈を付けることは、システム全体の通信パフォーマンスを機能強化する簡単で柔軟な形である。

そのような注釈を、正しい処理のためにイベント・マネージャに送られるすべてのイベントに付加できることが好ましい。しかし、特に、肯定応答メッセージを、エンティティによって追加される注釈の担体とすることができる。

しかし、注釈自体だけを配布することはできない。もう１つの好ましい実施形態によれば、注釈を含むイベント全体が、イベント・マネージャによって配布される。

本発明のもう１つの実施形態によれば、イベントの外見が、イベントごとに異なるフィールドが含まれるイベント表記に従い、各フィールドが、あるカテゴリの情報を指定する、イベント・モデルが提供される。フィールドのうちの少なくともいくつかが、階層に従うことが好ましい。そのようなイベント・モデルは、特にイベント用のフィルタを簡単に実装できるので、モバイル・ハブの内部でのイベントの処理を容易にする。

本発明のもう１つの態様によれば、モバイル・ハブの処理ユニットにロードされたときに、方法クレームのうちのいずれか１つによる方法を実行するコード手段を含むコンピュータ・プログラム要素が提供される。

一般に、本装置の実施形態ならびに本装置の利益およびその実施形態が、それぞれ本方法の実施形態および本方法の利益およびその実施形態とも考えられ、逆も同様であることに留意されたい。

本発明およびその実施形態は、添付図面と共に解釈されるときに本発明による現在好ましいがそれでも例示的である実施形態の次の詳細な説明を参照することによって、より十分に諒解されるであろう。異なる図面に、類似するまたは均一の内容を有する要素を表す同一の符号が含まれる場合がある。

図１に、本発明によるモバイル・ハブを含むシステムの図を示す。

通常のモバイル・ハブに、Ｓｙｍｂｉａｎ ＯＳ、Ｌｉｎｕｘ、ＰｅｒｓｏｎａｌＪａｖａ（Ｒ）（商標）、またはＭＩＤＰ Ｊａｖａ（Ｒ）（商標）ランタイム環境などのランタイム・システムと、適当なＷＬＡＮコンポーネントまたはＷＷＡＮコンポーネントもしくはその両方とを含めることができる（Ｊａｖａ（Ｒ）、およびＰｅｓｏｎａｌＪａｖａ（Ｒ）／ＭＩＤＰ Ｊａｖａ（Ｒ）は、Ｓｕｎ Ｃｏｒｐｏｒａｔｉｏｎ社の商標である）。

図１によるモバイル・ハブ１は、実際に、外部エンティティ２および３と通信している。外部エンティティ２は、薬物治療コンプライアンスを監視するセンサ（このデバイスはブリスタ・パックを監視する）であり、無線ローカル・エリア・ネットワークＢｌｕｅｔｏｏｔｈを介してモバイル・ハブ１に接続される。外部エンティティ３は、リモート患者監視アプリケーションを稼動させるサーバであり、無線広域ネットワークＧＰＲＳを介してモバイル・ハブに接続される。医療監督者（例えば、医師、看護婦など）が、患者監視アプリケーションを用いて薬物投与計画（すなわち、いつ何錠薬を飲むか）をセット・アップすることができる。患者監視アプリケーションである外部エンティティ３は、ＧＰＲＳを介して、モバイル・ハブ１で稼動するネットワーク・アダプタに薬物投与計画を送る（例えば、ＩＣＡＬカレンダ指定またはＶＣＡＬカレンダ指定として）。ネットワーク・アダプタは、薬物投与計画をイベント・エンジンに注入し、イベント・エンジンは、これをすべての登録されたアダプタに再配布するが、このアダプタのうちの１つが、薬物治療コンプライアンス・モニタ・アダプタであり、このアダプタは、この情報をＢｌｕｅｔｏｏｔｈリンクを介して薬物治療コンプライアンス・モニタに送る（多分、独自フォーマットに変換するかそのままで）。薬物治療コンプライアンス・モニタである外部エンティティ２は、薬物を飲むときに達したならば、患者に警告音を鳴らす。患者が、外部エンティティ２に含まれるブリスタ・パックから薬物を取り出す場合に、外部エンティティ２は、Ｂｌｕｅｔｏｏｔｈを介してモバイル・ハブ１に接続し、「ｂｌｉｓｔｅｒ ｏｐｅｎｅｄ（ブリスタ開封）」イベント（ブリスタが開かれた時刻および多分他の情報を含む）をモバイル・ハブ１上の薬物治療コンプライアンス・アダプタに送信する。薬物治療コンプライアンス・アダプタは、このセンサ情報を標準化されたイベント・フォーマットに変換し、イベント・エンジンに注入し、イベント・エンジンは、このイベントを他のすべての登録されたアダプタに転送する。ＧＰＲＳネットワーク・アダプタが、ＧＰＲＳを介して外部エンティティ３にサブミットする。

図１に関して既に示したように、集合的に外部エンティティと呼ばれるセンサ・デバイスおよびアクチュエータ・デバイスが例えばＢｌｕｅｔｏｏｔｈを介してモバイル・ハブに接続されるヘルス・ケア／医療／製薬応用領域は、モバイル・ハブの魅力的な応用領域である。各センサが、周期的にセンサ値をモバイル・ハブに送信する。モバイル・ハブでは、センサ・データが分析され、おそらく他のセンサ・デバイスのデータと相関される必要があり、ネットワーク・ベースのサービスに中継される場合もある。通常、これらのデータは、離散的な性質を有し、各センサ値を、１つのイベントとして扱うことができる。したがって、各センサは、無線通信リンクを介してイベントのシーケンスをモバイル・ハブにサブミットする。同様に、モバイル・ハブの内部プロセス／エンティティが、イベントを生成することができる。もちろん、これらの内部的に生成されたイベントまたは外部エンティティから受信されたイベントを、モバイル・ハブ上のコンシューマまたはモバイル・ハブの外部のサービスあるいはこの両方から使用可能にすることが必要である場合がある。したがって、イベントを効率的に処理し、これらを正しい形で配布するために、モバイル・ハブは、イベント・マネージャとも呼ばれるイベント・エンジンを必要とする。

図２に、イベント・エンジン／イベント・マネージャがモバイル・ハブにどのように統合されるかを概略的に示す。図２によるモバイル・ハブ１に、環状バッファ１１、イベント・マネージャ１２、タイマ・ユニット１３、キャッシュ１４、アダプタ１５および１６、ならびに内部エンティティ１７が含まれる。

図２によるモバイル・ハブは、イベント処理システムと見なすことができるので、基本的にシステム内の反応をトリガするメッセージであるイベントは、基本的な情報／データ保持担体である。イベントは、図２による外部エンティティ２または３などの外部エンティティによって生成することができる。モバイル・ハブ１は、イベントの外部表現をそのモバイル・ハブの内部で理解できる表現に変換する必要を有する。同様に、モバイル・ハブ１とイベントを交換する外部エンティティは、イベントのモバイル・ハブ内部表現をその外部エンティティが理解できる表現に変換する必要を有する。この変換が、アダプタの主要な仕事である。図２から導出できるように、アダプタ１５および１６は、外部エンティティ２および３とモバイル・ハブ１の内部イベント処理システムとの間の仲介物として配置される。アダプタは、一般に、外部エンティティおよびモバイル・ハブ・アプリケーションとインターフェースする。

しかし、図２による内部エンティティ１７など、モバイル・ハブ内部エンティティによってイベントを生成し、変更し、分析し、またはこれに作用することもできる。

外部エンティティからサブミットされたかまたは内部エンティティによって作成されたかのいずれかであるイベントがモバイル・ハブに到着したならば、そのイベントは、キャッシュ１４にキャッシングされる。次に、イベント・マネージャ１２が、イベントを１つずつ環状バッファ１１に転送する。イベントは、環状バッファ１１のメモリ・セルが新しいイベントを受け入れる準備ができたときに限って、環状バッファに転送される。このイベント処理は、バッファがその限られたサイズに起因して無制限の個数のイベントを受け入れることができないので、環状バッファ内の非ブロッキング・イベント処理を許可する機構を必要とする。

非ブロッキング特性を有する環状バッファ１１を達成する機構が、タイマを使用することである。図２では、タイマ・ユニット１３が、環状バッファ１１に実際に保管されたすべてのイベント用のタイマを提供する。タイマごとに、タイムアウトが定義される。タイムアウトは、多数の異なる形で定義することができる。タイムアウトは、時間単位あたりに処理されるべきイベントまたは時間単位あたりに到着すると期待されるイベントの予想を基礎として定義することができる。タイムアウト値は、基本的に処理されるイベントの到着レートに依存する可変タイムアウト値として実装することもできる。この最後の実施形態によれば、到着レートを測定するための測定を、モバイル・ハブに導入することができる。

タイムアウトは、基本的に、イベントが環状バッファ１１内のメモリ・セルを占めることができる時間の最大期間を定義する。特定のイベントのタイムアウトを過ぎた最後のときまでに、この特定のイベントが、処理されるべき別のイベントのためにメモリ・セルを解放させるためにバッファから破棄される。

タイマは、イベントが環状バッファ１１に保管されるときにセットされることが好ましい。もう１つの実施形態で、タイマは、イベントがモバイル・ハブに到着するときにセットされる。第１の実施形態では、イベントが、タイムアウト時間である固定された時間の間だけバッファを占めることができるが、第２の実施形態のタイムアウト時間は、モバイル・ハブ内のイベントの最大滞在を定義し、この場合に、バッファ内の有効時間は、モバイル・ハブ内だがバッファの外でイベントを処理するのに必要な時間に起因して、タイムアウト時間よりわずかに短くなる場合がある。

基本的に、タイマ・ユニット１３は、バッファに保管されたすべてのイベント用のタイマを提供する。イベント・マネージャ１２は、環状バッファ１１にイベントを保管し、タイマ・ユニット１３内のタイマをセットし、めいめいのタイマのタイムアウトを過ぎたときに環状バッファ１１からイベントを破棄する責任を負う。

しかし、イベントがバッファ内で費やす時間中に、このイベントを処理しなければならない。イベントに従属して、そのイベントを、内部エンティティによって処理しなければならないか、外部エンティティによって処理しなければならないか、内部エンティティおよび外部エンティティによって処理しなければならない。イベントを処理する前に、そのイベントを、処理するエンティティに転送しなければならない。したがって、登録リスト１９が、モバイル・ハブ１内で確立される。登録リスト１９は、どの種類のイベントをどこに通信しなければならないかという情報を提供する。例えば、登録リスト１９内のエントリは、「外部センサから来るすべてのイベントが、さらなる処理のために内部エンティティ１７に送られなければならない。」または「内部エージェントから来るすべてのイベントが、ＧＰＲＳを介して外部エンティティに通信されるためにモバイル・ハブのアダプタ１６に転送されなければならない。」のようになる。エンティティは、登録リストに登録するかサブスクライブし、どの種類のイベントに関心を持つかを示すことができる。

イベント・マネージャ１２が、登録リスト１９にアクセスでき、イベントが環状バッファ１１に保管された後に登録リスト１９に従ってイベントを処理することが好ましい。したがって、イベントを環状バッファ１１に保管することと一緒に、対応するタイマが、セットされ、イベントが、登録リスト１９に従って、すべての関心を持つエンティティに送られる。そのような登録されたエンティティに送られるものは、必ずしもイベント自体ではない。より一般的に言って、登録されたエンティティは、イベントについて通知される。この通知は、その通知をトリガするイベントと同一でないメッセージであってもまたは同一のメッセージであってもよい。

通知は、新しいイベントの到着時にトリガされる。この文脈では、到着は、環状バッファ１１への到着として、またはモバイル・ハブへの到着として、あるいはこれらの間の任意のときの到着として解釈することができる。通常、図２に示されているように、通知は、イベントが保管されるときまたはその前後の短い時間のうちにトリガされる。というのは、イベントが、まずイベント・マネージャ１２の注目を起こさせなければならず、次に、イベント・マネージャ１２が、このイベントに関する通知の受取側を判定するために登録リスト１９をルック・アップするからである。

モバイル・ハブ１の実装は、通知を受け取ったときに、直接にまたはキャッシュ１４を介してのいずれかで、イベント・マネージャ１２に肯定応答メッセージを返す形を提供する。したがって、イベント・マネージャ１２は、どのエンティティ（内部エンティティまたは外部エンティティ）が、通知の受取を肯定応答したかを監視することができる。すべての受取側が通知の受取を肯定応答したときに、その通知をトリガしたイベントは、イベント処理の観点から、それ以上必要ではない。内部エンティティまたは外部エンティティは、通知に応答してさらなる処理ステップを行うことができる。しかし、イベント・ベースのシステムでは、必要な場合に、これらのエンティティは、相互接続されたモバイル・システムのエンティティのいずれかにさらなる情報を通信しなければならないときに、イベント・マネージャ１２によるさらなる処理のためにモバイル・ハブ１に単純に新しいイベントを送る。その後、そのようなイベントは、上で説明したものと同一の形で処理される。

しかし、イベントは、対応するタイマのタイムアウトの前に、通知されるすべてのエンティティから肯定応答メッセージＡＣＫを受け取ったときに限って（したがって、最後のＡＣＫがイベント・マネージャ１２によって受け取られたときに）、バッファから破棄される。いくつかの期待される肯定応答（通知されるエンティティからの肯定応答が期待される）が、対応するタイマのタイムアウトを過ぎる前に受け取られない限り、イベントは、タイマがそのタイムアウトを過ぎるときにバッファから破棄される。これによって、イベント関連通知の受取側が、故障、切断されたモードなど、なんらかの理由で通知を肯定応答できないイベントによってバッファがブロックされることが防がれる。

図２のモバイル・ハブには、もう１つの特徴が設けられる。エンティティは、保管されたイベントを増補するために、ＡＣＫの代わりにイベント注釈または注釈付きＡＣＫを用いて応答することができる。その場合に、イベント・マネージャ１２は、環状バッファ１１に保管されたイベントを、その注釈を用いて更新し、そのイベントのタイマをリセットし、イベントに注釈を付けたエンティティを除くすべてのサブスクライブしたエンティティに再通知する。

イベントに注釈を付けることは、一般に、すべてのエンティティ／サブスクライバが、既存イベントに追加データを提供し、したがって注釈を付けることができる可能性を提供する。この注釈機構の背後にある原理は、すべての注釈が、他のすべての関心を持つエンティティから使用可能にされることである。この機構は、イベント・マネージャによるイベント処理の速度を改善するのを助ける。しかし、注釈を付ける権利を、通知されるエンティティだけに与えることはできない。アダプタも、必要な場合に、通過するイベントにコメントを付けることができる。

図２によれば、環状バッファ１１に実際に保管される２つのイベント、「緑イベント」および「赤イベント」がある。赤イベントは、内部エンティティ１７によってイベント・マネージャ１２にポストされた（１７と１２の間の点線）。イベント・マネージャ１２は、アダプタのレジストリであるキャッシュ１４を考慮する。イベント・マネージャ１２は、他のサブスクライブしたアダプタ１５および１６に、赤イベントについて通知する。アダプタ１６は、単に、赤イベントの受取を肯定応答するが、アダプタ１５は、赤イベントに注釈を付け、それを肯定応答と共にイベント・マネージャ１２に返す。イベント・マネージャ１２は、赤イベントおよび注釈を他のアダプタ、この例ではアダプタ１６に再配布する。アダプタ１６は、注釈付きイベントの受取をもう一度肯定応答する。すべてのアダプタが、イベント（およびその注釈付きの版）の受取を肯定応答したならば、イベント・マネージャ１２は、赤イベントを環状バッファから除去することができる。

緑イベントについて、イベント・タイムアウトが発生しており、イベント・エンジンは、この緑イベントも環状バッファから除去する。

アダプタおよび内部エンティティは、イベント・フィルタ（例えば、フィルタ・パターン）を提供して、ある種類のイベントだけへの関心を示すことができる。イベント・エンジンは、フィルタ・パターンに一致するイベントだけを特定のアダプタに転送する。また、イベント・エンジンは、フィルタ・パターンがイベントと一致しないアダプタを、その特定のイベントについて通知される当事者のセットに追加しない。タイムアウト・パラメータを調整し、イベント・エンジンによってアダプタに送られる通知に現在の値を含めることによって、このシステムを、異なる使用法シナリオに適合させることができ、このシステムが、変更を通信し、アダプタが反応することを可能にすることができる。

図３に、もう１つのモバイル・ハブ１を概略的に示す。やはり、イベント・マネージャ１２は、イベントを一時的に保管するのに環状バッファ１１を利用することによってイベントを処理する。タイマ・ユニット１３は、すべての保管されたイベント用のタイマを提供し、登録リストは、環状バッファ１１に保管されたどのイベントをどの関心を持つエンティティに送らなければならないかの情報をイベント・マネージャ１２に提供する。

番号１７および１８によって参照される、２つの内部エンティティまたはエージェントが設けられる。外部エンティティとイベント・マネージャ１２の間の通信をサポートするために、３つのアダプタ１５、１５１、および１６が設けられる。モバイル・ハブ１から可視であり、これに接続された２つの外部エンティティ２および３があり、センサを含む外部エンティティ２は、Ｂｌｕｅｔｏｏｔｈを介してモバイル・ハブ１に接続され、「サービス」と呼ばれる外部エンティティ３は、ＧＰＲＳ上のネット接続を介してモバイル・ハブ１に接続される。ブロック１０は、ハブのオペレーティング・システムを示す。符号１０１〜１０４は、よりハードウェアの観点から要素を示し、ブロック１０１はＧＰＲＳインターフェースを表し、ブロック１０２はＢｌｕｅｔｏｏｔｈインターフェースを表すが、ブロック１０３は、モバイル・ハブのストレージ手段を表す。ブロック１０４は、モバイル・ハブのＳＩＭを表す（ＳＩＭ＝subscriber identity module）。図３から導出できるように、外部エンティティ２などの外部デバイスは、Ｂｌｕｅｔｏｏｔｈインターフェース１０２を介してモバイル・ハブに接続される。また、イベント通知を変換するためにこの外部デバイスに割り当てられたインターフェースがあり、このインターフェースは、図３の実施形態によればアダプタ１５である。一般に、１つのアダプタを、インターフェース全体に割り当てることができ、あるいは、特定のエンティティに割り当てることができる。

モバイル・ハブにアクセスするのに必要な最小のＡＰＩセットに、エンティティを登録する「ｒｅｇｉｓｔｅｒ（）」、エンティティを登録解除する「ｄｅｒｅｇｉｓｔｅｒ（）」、およびイベントをポストする「ｐｏｓｔ（）」などの命令が含まれる。

例示的なアダプタは、例えば、下に示す通りであるが、そのうちの１つまたは複数を、ハブの構成および必要性に従ってモバイル・ハブ内で実施することができる。
１つまたは複数のセンサを相互接続するセンサ・アダプタ、
例えばバックアップ目的で、モバイル・ハブをストレージ・デバイスに相互接続する永続ストレージ・アダプタ、
インターネット・プロトコル・ベースのサービスに接続するＨＴＴＰアダプタ、
診断ツールに接続するデバッギング・アダプタ、
ＷＬＡＮアダプタ、ＳＭＳアダプタなどの通信アダプタ、．．．。

内部エンティティは、例えば次のように実施することができる。
カレンダ・エンティティ、
アラーム・エンティティ、
デバイス・ディスカバリ・エンティティ、
デバイス監視エンティティ、
データ監視エンティティ、
構成エンティティ。

図４に、本発明の実施形態による、注釈付けイベントの特徴に特に焦点を合わせた、例示のイベント・フローの図を示す。

例えば図２または図３の図による外部エンティティ２とすることのできるセンサが、新しい値ｖａｌ ｉを感知し、Ｂｌｕｅｔｏｏｔｈを介してモバイル・ハブに送信する。このメッセージが、１つのイベントである。図２によるアダプタ１５とすることのできる対応するセンサ・アダプタが、値ｖａｌ ｉを含むイベントの外部表現を、その表現が例えばｅｖｅｎｔ ０．１．ｘ．ｙ．ｚでなければならない、イベントのハブ内部表現に変換する。そのような表記は、図５に関してより十分に説明する。変換の後に、新しい表記のイベントが、センサ・アダプタによって、モバイル・ハブのイベント処理システムに注入される。

例えば図２による登録リスト１９などの登録リストに従って、イベント・マネージャは、サブスクライブしたエンティティすなわち、エージェントおよびアダプタに通知する。そのような通知の際に、図２によるモバイル・ハブの、通知エージェントである内部エンティティ１７は、イベント（ここでは通知がイベントと同一である）を、注釈と共にイベント・マネージャに返す。この注釈は、そのイベントがネットワークにとって重要であるとそのエージェントが述べたので、「イベントをネットワークに複製しなければならない」ことを表さなければならない。注釈が、アドレスを明示的に示すときに、登録リストは、適当な通知を可能にするために、「イベントまたは注釈がアドレスを明示的に提供する場合に、関心を持つエンティティはこのアドレスだけである」などのエントリを提供することができる。したがって、イベント・エンジンは、サブスクライブしたエンティティに通知するが、このエンティティは、この例ではＧＳＭ／ＧＰＲＳアダプタだけである。したがって、イベント・エンジンは、対応するネット・アダプタにイベントを送るが、このアダプタは、図２によるアダプタ１６とすることができる。次に、アダプタ１６がイベントをＳＭＳ（ショート・メッセージ・サービス）に変換し、ＳＭＳを送出する。

図５に、対応するイベント通知に反映されるイベント構造を示す。したがって、イベントを分類する分類学が導入される。このモデルによれば、第１レベルで、イベントが、センサ・イベントとアクチュエータ・イベントの間で区別される。センサ・イベントは、システムにデータを報告する。例えば、温度センサは、温度測定値をポストし、ＧＳＭセンサは、着信電話呼および発呼者ＩＤを報告し、心拍センサは、鼓動を報告するなどである。アクチュエータ・イベントは、アクションの発生を要求する。アクチュエータ・イベントは、コマンドを示す。例えば、ストア・イベントは、付加されたデータ要素をどこかに保管しなければならないことをシグナリングし、ＧＳＭ電話呼イベントは、ＧＳＭ電話呼を開始しなければならないことを示す。図５によれば、イベント通知の第１桁は、そのイベントがセンサ・イベントまたはアクチュエータ・イベントのどちらであるかを示し、言及したセンサ・イベント・クラスのイベントは、第１桁の（０）によって示され、アクチュエータ・イベント・クラスは、第１桁の（１）によって示される。

センサ・イベントとアクチュエータ・イベントの間のトップ・レベルの区別のほかに、イベント・ソースに関する第２レベル・イベント・カテゴリ、ドメインに関する第３レベル・カテゴリ、およびセンサ／アクチュエータに関する第４レベル・カテゴリがある。イベント・ソースは、内部ソースまたは外部ソースとすることができ、必ずモバイル・ハブに関する分類である。ドメインは、システム全般、電話サブシステム、医療ドメイン、自動車ドメインなど、イベントが何に関連するかを示すことができる。センサ／アクチュエータ分類は、最も広義の可能な意味において用語センサおよびアクチュエータを使用し、センサは、単一ビットの情報だけまたははるかに複雑なものを提供するデバイスとすることができ、同様に、アクチュエータは、１ビットの情報をとり、それに作用するか、複雑な命令のセットをとることができる。

各レベルが、列挙された項目の明確に定義されたリストを提供する。イベントを「アドレッシング」するために、好ましいタプル方式がある。例えば、「ａｓ．ｅｘｉｎ．ｄｏｍ．ｄｅｖ」は、イベントを表す順序を提供する。このタプルの第１フィールドは、アクチュエータ／センサ・イベントの値を示さなければならず、第２フィールドは、イベントが内部デバイスまたは外部デバイスのどちらから来るかを示さなければならず、第３フィールドは、内容ドメインを示し、第４フィールドは、デバイスのタイプを示す。

このイベント表記と共に、外部医療心拍センサ・イベントを、例えばタプル０．１．１０．１によってアドレッシングすることができ、最初の０は、このイベントがセンサによって生成されることを示し、次の１は、これが外部デバイスから来ることを示し、次の１０は、医療ドメインを示し、最後の１は、心拍センサの特徴を表す。図５によれば、次のレベルは、心拍センサが提供しているデータが、鼓動データであることを示す。次のレベルでは、第４レベルで示されたデータのタイプが指定される。したがって、より低いレベルのエントリは、より高いレベルのエントリに依存することができる。最低レベルのエントリは、脈拍が時間を基礎として与えられることを示す。

図５に示されたもう一方のイベント・タプルは、スキャナである内部通信エンティティからの、イベントを送達するセンサ・データを提供する。スキャナ・データは、新しいデバイスが、そのＭＡＣアドレスと共に発見されたことを示す。

そのようなフィールドの一部またはすべてを、フィールドの階層システムの対象とすることができる。フィールドの導入は、イベントのフィルタリングまたは未知イベントのスキップを容易にする。

さらに、必ず「アドレス」部分の後に続くもう１つの２タプルが、好ましい実施形態として導入されている。第１タプルは、明確に定義されたデータ・サブフィールド、例えば医療血圧計カフ・センサ（最高血圧、最低血圧、心拍数）を選択し、第２のタプルは、データ型（整数、ブール値、時刻、日付、文字列、バイナリ）を示す。また、各イベントが、それをイベント・システムに注入したアダプタのユニバーサルＩＤならびに注入の時刻を示すタイムスタンプを、それと共に担持することができる。イベントは、少なくともイベント・ヘッダ（ＵＩＤ、イベント・タイムスタンプ、およびイベント・アドレスを含む）からなることが好ましい。任意選択として、イベントに、追加データを含むサブフィールドが含まれる。アダプタ／エージェントは、イベントを受け取ったときに、受け取ったイベントに注釈を付けることができる。イベントに注釈が付けられる場合に、イベント・エンジンは、そのイベントをすべてのサブスクライブしたエージェント／アダプタに再配布する。任意選択として、帯域幅を節約しなければならない場合には、最初のソースおよび注釈付きのソースをフィルタ・アウトすることができる。

上で説明したイベント表記は、ハブ内部イベント表記を表す。したがって、アダプタは、外部イベント表記を内部イベント表記におよびその逆に変換する責任を負うので、使用される表記を知らなければならない。もちろん、エージェントの形の内部エンティティも、イベントを処理するので、使用されるイベント表記を知らなければならない。上で導入したイベント表記と組み合わされれば、例えば、最初の３つのフィールドが「０．１．１０．．．」から始まる受け取られたイベントだけを評価し、したがって、例えば医療センサからのセンサ・データだけを扱うなど、フィルタリングによってイベントを処理することは簡単である。エージェントを、それにおいて特殊化することができ、エージェントは、医療センサからのセンサ・データの処理について対応する手順を使用可能にすることができる。

例として、ある人の鼓動を感知し、鼓動ごとにＢｌｕｅｔｏｏｔｈ信号を生成する胸帯を検討されたい。モバイル・ハブ上のアダプタが、各鼓動にタイムスタンプを付け、対応するイベントに、０．１．１０．１．１．５というラベルが付けられる。
最初の桁０は、これがセンサ・イベントである（アクチュエータ・コマンドではなく）ことを示し、
次の桁１は、このセンサ・イベントが外部センサによって供給されることを示し、
次の桁１０は、そのセンサが医療センサであることを示し、
次の桁１は、そのセンサが心拍センサであることを示し、
次の桁１は、その心拍センサが鼓動を感知していることを示し、
次の桁５は、情報が鼓動のタイムスタンプであることを示す。
そのような表記を使用することの利益は、アダプタが関心を持たないイベントをフィルタ・アウトすることが非常に簡単であることであり、例えば、外部医療センサ・イベントだけに関心を持つアダプタは、０．１．１０プレフィックスを有しないすべてのイベントを破棄することができ、あるいは、そのアダプタが理解しない情報を破棄することができ、例えば、新しいセンサが、鼓動のタイムスタンプだけではなく現在の平均心拍数も供給する場合に、アダプタは、タイムスタンプ付き鼓動データをとるが現在の平均心拍数を無視することができる。

最後に、モバイル・ハブのイベント処理システムの好ましい実施形態を導入した。本発明によるイベント処理システムは、Ｌｉｎｕｘプラットフォーム上で実装できることが好ましく、イベントは、共用メモリ領域に保管することができる。イベント通知は、Ｕｎｉｘ（Ｒ） Ｓｙｓｔｅｍ Ｖメッセージングによって達成することができる。代替案では、イベント処理システムを、Ｓｙｍｂｉａｎ社の携帯電話オペレーティング・システム上で実装することができる。この場合に、イベントは、オブジェクト呼出しを介して配布される。

本発明によるモバイル・ハブを含むシステムを示す図である。 本発明の実施形態によるモバイル・ハブを示す概略図である。 本発明の実施形態によるモバイル・ハブを示すもう１つの概略図である。 本発明の実施形態による例示のイベント・フローを示す図である。 本発明の実施形態によるイベント構造を示す図である。

符号の説明

１ モバイル・ハブ
２ 外部エンティティ
３ 外部エンティティ
１０ オペレーティング・システム
１１ 環状バッファ
１２ イベント・マネージャ
１３ タイマ・ユニット
１４ キャッシュ
１５ アダプタ
１６ アダプタ
１５１ アダプタ
１７ 内部エンティティ
１８ 内部エンティティ
１９ 登録リスト
１０１ ＧＰＲＳインターフェース
１０２ Ｂｌｕｅｔｏｏｔｈインターフェース
１０３ ストレージ手段
１０４ ＳＩＭ

Claims (26)

1. イベントを保管する環状バッファ（１１）と、
   前記バッファ（１１）に保管されたイベントのストレージ期間を監視するタイマと、
   関連するタイマのタイムアウトを過ぎた場合にイベントを前記バッファ（１１）から破棄するように設計されたイベント・マネージャ（１２）と
   を含むモバイル・ハブ。
2. 前記タイムアウトが、イベント到着レートに依存する可変タイムアウトである
   請求項１に記載のモバイル・ハブ。
3. 前記タイムアウトが、異なるアプリケーションに関連するイベントについて異なる
   請求項１または２に記載のモバイル・ハブ。
4. 前記バッファ（１１）に保管されたすべてのイベントが、タイマを関連付けられる
   請求項１ないし３のいずれか一項に記載のモバイル・ハブ。
5. 前記バッファ（１１）が、２００個未満のイベントを保管する容量を有する
   請求項１ないし４のいずれか一項に記載のモバイル・ハブ。
6. 前記バッファ（１１）が、１００個未満のイベントを保管する容量を有する
   請求項５に記載のモバイル・ハブ。
7. 外部エンティティから／外部エンティティへイベントを受信するか、送信するか、その両方を行う、無線ローカル・エリア・ネットワークへのインターフェース（１０２）
   を含む、請求項１ないし６のいずれか一項に記載のモバイル・ハブ。
8. 外部エンティティから／外部エンティティへイベントを受信するか、送信するか、その両方を行う、無線広域ネットワークへのインターフェース（１０１）
   を含む、請求項１ないし７のいずれか一項に記載のモバイル・ハブ。
9. イベントの内部表現を外部エンティティ（２、３）が理解できる前記イベントの表現におよびその逆に変換するアダプタ（１５、１６）
   を含む、請求項１ないし８のいずれか一項に記載のモバイル・ハブ。
10. イベントを処理する内部エンティティ（１７、１８）
    を含む、請求項１ないし９のいずれか一項に記載のモバイル・ハブ。
11. 前記イベント・マネージャ（１２）が、到着するイベントを前記バッファ（１１）に保管し、前記関連するタイマを始動するように設計される
    請求項１ないし１０のいずれか一項に記載のモバイル・ハブ。
12. イベントが現れた場合に通知されなければならないエンティティを識別する登録リスト（１９）
    を含む、請求項１ないし１１のいずれか一項に記載のモバイル・ハブ。
13. 前記イベント・マネージャ（１２）が、イベントの到着に応答して、前記登録リスト（１９）に従ってエンティティに通知するように設計される
    請求項１２に記載のモバイル・ハブ。
14. 前記イベント・マネージャ（１２）が、エンティティに送られた通知に応答してこれらのエンティティから受け取られる肯定応答メッセージを監視するように設計され、
    前記イベント・マネージャ（１２）が、前記タイマの前記タイムアウトの前に、イベントに関して通知された前記エンティティのそれぞれから肯定応答メッセージが受け取られた場合に、この特定のイベントを前記バッファ（１１）から破棄するように設計され、
    前記イベント・マネージャ（１２）が、前記関連するタイマの前記タイムアウトを過ぎ、かつ前記タイマの前記タイムアウトの前に、イベントに関して通知された前記エンティティのいくつかから肯定応答メッセージを受け取らなかった場合に、この特定のイベントを前記バッファ（１１）から破棄するように設計される
    請求項１ないし１３のいずれか一項に記載のモバイル・ハブ。
15. 環状バッファ（１１）にイベントを保管することと、
    前記保管されたイベントのストレージ期間を監視することと、
    前記ストレージ期間がタイムアウトを過ぎた場合に前記バッファ（１１）から前記イベントを破棄することと
    を含む、モバイル・ハブでイベントを管理する方法。
16. イベントの到着に応答して、登録されたエンティティに通知すること
    を含む、請求項１５に記載の方法。
17. エンティティが、無線ネットワークを介して前記モバイル・ハブ（１）と通信する外部エンティティ（２、３）である
    請求項１６に記載の方法。
18. エンティティが、イベントを処理する、前記モバイル・ハブ（１）の内部エンティティ（１７、１８）である
    請求項１６または１７に記載の方法。
19. エンティティに送られた通知に応答してそれらのエンティティから受け取られる肯定応答メッセージを監視することと、
    前記タイマの前記タイムアウトの前に、イベントに関して通知された各エンティティから肯定応答メッセージが受け取られた場合に、この特定のイベントを前記バッファ（１１）から破棄することと、
    前記関連するタイマの前記タイムアウトを過ぎ、かつ前記タイマの前記タイムアウトの前に、イベントに関して通知された前記エンティティのいくつかから肯定応答メッセージを受け取らなかった場合に、この特定のイベントを前記バッファ（１１）から破棄することと
    を含む、請求項１５ないし１８のいずれか一項に記載の方法。
20. 肯定応答メッセージと組み合わせて受け取られた注釈を、登録されたエンティティに配布すること
    を含む、請求項１５ないし１９のいずれか一項に記載の方法。
21. イベントと組み合わせて受け取られた注釈を、登録されたエンティティに配布すること
    を含む、請求項１５ないし２０のいずれか一項に記載の方法。
22. 最初のイベントに付加された注釈を含むイベントを、登録されたエンティティに配布すること
    を含む、請求項１５ないし２１のいずれか一項に記載の方法。
23. イベントと組み合わせて受け取られた注釈を、登録されたエンティティに配布すること
    を含む、請求項１５ないし２２のいずれか一項に記載の方法。
24. イベントの外見が、イベントごとに異なるフィールドを含むイベント表記に従い、各フィールドが、あるカテゴリの情報を指定する
    請求項１５ないし２３のいずれか一項に記載の方法。
25. 前記フィールドのうちの少なくともいくつかが、階層に従う
    請求項２４に記載の方法。
26. モバイル・ハブの処理ユニットにロードされたときに、請求項１５ないし２５のいずれか一項に記載の方法を実行するコンピュータ・プログラム・コードを含むコンピュータ・プログラム。

Images