特許 6574422 モノのインターネットイベント管理システムおよび方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6574422

(24)【登録日】2019年8月23日

(45)【発行日】2019年9月11日

(54)【発明の名称】モノのインターネットイベント管理システムおよび方法

(51)【国際特許分類】

   G06F 9/54 20060101AFI20190902BHJP

   G06F 13/00 20060101ALI20190902BHJP

【ＦＩ】

   G06F9/54 C

   G06F13/00 358D

【請求項の数】16

【全頁数】27

(21)【出願番号】特願2016-537891(P2016-537891)

(86)(22)【出願日】2014年8月29日

(65)【公表番号】特表2016-535359(P2016-535359A)

(43)【公表日】2016年11月10日

(86)【国際出願番号】US2014053399

(87)【国際公開番号】WO2015031750

(87)【国際公開日】20150305

【審査請求日】2016年3月24日

【審判番号】不服2018-5083(P2018-5083/J1)

【審判請求日】2018年4月12日

(31)【優先権主張番号】61/871,474

(32)【優先日】2013年8月29日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】515222713

【氏名又は名称】コンヴィーダ ワイヤレス， エルエルシー

(74)【代理人】

【識別番号】110002147

【氏名又は名称】特許業務法人酒井国際特許事務所

(72)【発明者】

【氏名】リー， チュアン

(72)【発明者】

【氏名】ドン， リージュン

(72)【発明者】

【氏名】シード， デール エヌ．

(72)【発明者】

【氏名】ラーマン， シャミム アクバル

【合議体】

【審判長】 辻本 泰隆

【審判官】 山崎 慎一

【審判官】 須田 勝巳

(56)【参考文献】

【文献】 特開２００７−１５７１４９（ＪＰ，Ａ）

【文献】 高田秀志ほか，有効期限に基づく時間的正当性を考慮した時間的オブジェクトモデルとその応用，電子情報通信学会技術研究報告，日本，社団法人電子情報通信学会 Ｔｈｅ Ｉｎｓｔｉｔｕｔｅ ｏｆ Ｅｌｅｃｔｒｏｎｉｃｓ， Ｉｎｆｏｒｍａｔｉｏｎ ａｎｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｅｎｇｉｎｅｅｒｓ，１９９６年 ７月２５日，第９６巻 第１７６号，６７−７２ページ

【文献】 加藤悠一郎ほか，携帯電話を用いた異種ネットワークデバイス連携システムの開発，情報処理学会研究報告 平成２１年度▲６▼ ［ＤＶＤ−ＲＯＭ］，日本，社団法人情報処理学会，２０１０年 ４月１５日，Ｖｏｌ．２０１０−ＵＢＩ−２５， Ｎｏ．２２，１−６ページ

(58)【調査した分野】（Int.Cl.，ＤＢ名）

G06F9/54

G06F13/00

(57)【特許請求の範囲】

【請求項1】

モノのインターネット（ＩｏＴ）デバイスのためのイベント管理に関連する、複数のコンピューティングデバイスを含む通信ネットワーク内において、前記通信ネットワーク内のサービス層における前記複数のコンピューティングデバイスのうちのコンピューティングデバイスのプロセッサによって実行される方法であって、前記方法は、
前記通信ネットワーク内の前記サービス層において、イベントオブジェクトにおいて定義されているイベント式の条件が満たされていることを決定することであって、前記イベント式は、イベントに関連付けられており、前記イベント式は、前記通信ネットワーク内の少なくとも１つのリソースからの値を使用し、前記イベントオブジェクトは、前記サービス層において記憶されており、前記イベントオブジェクトは、前記イベントがどのように評価されるべきかを示す状態値を含む制御ハンドラを含み、
前記イベントオブジェクトは、前記イベント式を含むイベント定義を含み、
前記イベント定義は、トリガ優先順位を含み、前記トリガ優先順位は、少なくとも１つのリソースからの値が取得され、かつ、前記値が前記式の要件を部分的に満たした後、前記式のための他のリソースに対するリソースデータをいつ取得するべきかを示す、ことと、
前記イベント式の条件が満たされていることを決定することに応答して、前記通信ネットワーク内の前記サービス層において、前記イベント式の条件が満たされていることを示すものを生成することと
を含む、方法。

【請求項2】

前記イベント定義は、前記式のためのリソースデータをどのように取得するかを示すトリガ条件を含む、請求項１に記載の方法。

【請求項3】

前記イベントオブジェクトは、式が真であると評価するときに何が起こるかを示す通知ハンドラを含む、請求項１に記載の方法。

【請求項4】

前記イベントオブジェクトは、どのイベント機能性が前記コンピューティングデバイスによってサポートされているかを示すオブジェクト情報を含む、請求項１に記載の方法。

【請求項5】

前記サービス層は、前記通信ネットワークのサーバ、ゲートウェイまたは他のノードにおいて実装されている、請求項１に記載の方法。

【請求項6】

モノのインターネット（ＩｏＴ）デバイスのためのイベント管理に関連する、プロセッサとコンピュータ実行可能な命令を記憶しているメモリとを備えているデバイスであって、前記命令は、前記プロセッサによって実行されると、
通信ネットワークのサービス層のインスタンスの機能を実行することと、
前記サービス層において、イベントオブジェクトにおいて定義されているイベント式の条件が満たされていることを決定することであって、前記イベント式は、イベントに関連付けられており、前記イベント式は、前記通信ネットワーク内の少なくとも１つのリソースからの値を使用し、前記イベントオブジェクトは、前記サービス層において記憶されており、前記イベントオブジェクトは、前記イベントがどのように評価されるべきかを示す状態値を含む制御ハンドラを含み、
前記イベントオブジェクトは、前記イベント式を含むイベント定義を含み、
前記イベント定義は、トリガ優先順位を含み、前記トリガ優先順位は、少なくとも１つのリソースからの値が取得され、かつ、前記値が前記式の要件を部分的に満たした後、前記式のための他のリソースに対するリソースデータをいつ取得するべきかを示す、ことと、
前記イベント式の条件が満たされていることを決定することに応答して、前記通信ネットワーク内の前記サービス層において、前記イベント式の条件が満たされていることを示すものを生成することと
を前記デバイスに行わせる、デバイス。

【請求項7】

前記イベント定義は、前記式のためのリソースデータをどのように取得するかを示すトリガ条件を含む、請求項６に記載のデバイス。

【請求項8】

前記イベントオブジェクトは、式が真であると評価するときに何が起こるかを示す通知ハンドラを含む、請求項６に記載のデバイス。

【請求項9】

前記イベントオブジェクトは、どのイベント機能性が前記デバイスによってサポートされているかを示すオブジェクト情報を含む、請求項６に記載のデバイス。

【請求項10】

前記デバイスは、前記通信ネットワークのサーバ、ゲートウェイまたは他のノードを含む、請求項６に記載のデバイス。

【請求項11】

前記イベント式は、複数のリソースからのデータを用いる複合イベント式である、請求項１に記載の方法。

【請求項12】

前記リソースは、前記サービス層の外側に配置されている、請求項１に記載の方法。

【請求項13】

前記イベント式は、前記サービス層の外側でアプリケーションによって動的に生成される、請求項１に記載の方法。

【請求項14】

前記イベント式は、複数のリソースからのデータを用いる複合イベント式である、請求項６に記載のデバイス。

【請求項15】

前記リソースは、前記サービス層の外側に配置されている、請求項６に記載のデバイス。

【請求項16】

前記イベント式は、前記サービス層の外側でアプリケーションによって動的に生成される、請求項６に記載のデバイス。

【発明の詳細な説明】

【技術分野】

【0001】

本願は、米国仮出願第６１／８７１，４７４号（２０１３年８月２９日出願、名称「Ｍｅｃｈａｎｉｓｍｓ ｔｏ Ｓｕｐｐｏｒｔ ＩｏＴ Ｅｖｅｎｔ Ｍａｎａｇｅｍｅｎｔ」）の利益を主張し、上記出願は、参照により本明細書に引用される。

【背景技術】

【0002】

マシンツーマシン（Ｍ２Ｍ）技術は、有線および無線通信システムを使用して、デバイスが互により直接的に通信することを可能にする。Ｍ２Ｍ技術は、一意に識別可能なオブジェクトおよびインターネット等のネットワークを経由して通信するそのようなオブジェクトの仮想表現のシステムである、モノのインターネット（ＩｏＴ）のさらなる実現を可能にする。ＩｏＴは、食料品店内の商品等のさらに日常的な毎日のオブジェクトとの通信を促進し、それによって、そのようなオブジェクトの知識を向上させることによって、費用および無駄を低減させ得る。例えば、店は、在庫にあり得るか、または販売された場合がある、オブジェクトと通信するか、またはそこからデータを取得することができることによって、非常に精密な在庫データを維持し得る。理解されるであろうように、ＩｏＴは、数百万ものデバイスを含む潜在性を有する。ＩｏＴ内のデバイスからのデータを有意なイベントに関連付けることは、ＩｏＴシステムの機能性を向上させる重要側面である。

【発明の概要】

【課題を解決するための手段】

【0003】

本明細書に開示されるのは、モノのインターネット（ＩｏＴ）デバイスのためのイベント管理に関連する方法、デバイス、およびシステムである。具体的デバイスタイプおよび能力に合わされる、ＩｏＴイベントオブジェクトが、生成され得る。そのようなイベントオブジェクトは、再構成され得るイベントの柔軟な定義を使用し得る。ＩｏＴイベントオブジェクトはまた、再構成され得る可変トリガ条件および優先順位を含み得る。個々のイベント定義は、より複合的なイベントを生成するように拡張され得る。通知ハンドラは、アクションを要求するイベントに応答して、要求またはコマンドを送信することをサポートし得る。

【0004】

本概要は、発明を実施するための形態において以下でさらに説明される、一連の概念を簡略化形態において導入するために提供される。本概要は、請求される主題の主要な特徴または不可欠な特徴を識別することを意図しておらず、また、請求される主題の範囲を限定するために使用されることも意図していない。さらに、請求される主題は、本開示の任意の部分に記載される一部または全ての不利点を解決するという限界にも限定されない。
本発明はさらに、例えば、以下を提供する。
（項目１）
モノのインターネットデバイスを含むモノのインターネットネットワーク内において、
前記モノのインターネットデバイスにおいて、イベントオブジェクトにおいて定義されているイベント式の条件が満たされていることを決定することであって、前記イベント式は、前記モノのインターネットネットワーク内の少なくとも１つのリソースからの値を使用する、ことと、
前記イベント式の条件が満たされていることを決定することに応答して、前記イベント式の条件が満たされているという指示を生成することと
を含む、方法。
（項目２）
前記イベントオブジェクトは、前記イベント式を含むイベント定義を含む、項目１に記載の方法。
（項目３）
前記イベントオブジェクトは、複数のイベント定義を含む、項目２に記載の方法。
（項目４）
前記イベント定義のうちの２つ以上のものは、複合イベント式に組み合わせられる、項目３に記載の方法。
（項目５）
前記イベント定義は、前記式のためのリソースデータを得る方法を示すトリガ条件を含む、項目２に記載の方法。
（項目６）
前記イベント定義は、トリガ優先順位を含み、前記トリガ優先順位は、少なくとも１つのリソースからの値が得られ、前記値が前記式の要件を部分的に満たした後、前記式のための他のリソースに対するリソースデータをいつ得るべきかを示す、項目２に記載の方法。
（項目７）
前記イベントオブジェクトは、前記イベントがどう評価されるべきかを示す状態値を含む制御ハンドラを含む、項目１に記載の方法。
（項目８）
前記イベントオブジェクトは、式が真として評価すると発生することを示す通知ハンドラを含む、項目１に記載の方法。
（項目９）
前記イベントオブジェクトは、どのイベント機能性が前記デバイスによってサポートされているかを示すオブジェクト情報を含む、項目１に記載の方法。
（項目１０）
前記イベントオブジェクトは、サービス層の一部である、項目１に記載の方法。
（項目１１）
プロセッサと、コンピュータ実行可能命令を記憶しているメモリとを備えているデバイスであって、前記命令は、前記プロセッサによって実行されると、
イベントオブジェクトにおいて定義されているイベント式を評価することであって、前記イベント式は、モノのインターネットネットワーク内の少なくとも１つのリソースからの値を使用する、ことと、
前記式の条件が満たされている場合、前記イベント式の条件が満たされているという指示を生成することと
を前記プロセッサに行わせる、デバイス。
（項目１２）
前記イベントオブジェクトは、前記イベント式を含むイベント定義を含む、項目１１に記載のデバイス。
（項目１３）
前記イベントオブジェクトは、複数のイベント定義を含む、項目１２に記載のデバイス。
（項目１４）
前記イベント定義のうちの２つ以上のものは、複合イベント式に組み合わせられる、項目１３に記載のデバイス。
（項目１５）
前記イベント定義は、前記式のためのリソースデータを得る方法を示すトリガ条件を含む、項目１２に記載のデバイス。
（項目１６）
前記イベント定義は、少なくとも１つのリソースからの値が得られ、前記値が前記式の要件を部分的に満たした後、前記式のための他のリソースに対するリソースデータをいつ得るべきかを示すトリガ優先順位を含む、項目１２に記載のデバイス。
（項目１７）
前記イベントオブジェクトは、前記イベントがどう評価されるべきかを示す状態値を含む制御ハンドラを含む、項目１１に記載のデバイス。
（項目１８）
前記イベントオブジェクトは、式が真として評価すると発生することを示す通知ハンドラを含む、項目１１に記載のデバイス。
（項目１９）
前記イベントオブジェクトは、どのイベント機能性が前記デバイスによってサポートされているかを示すオブジェクト情報を含む、項目１１に記載のデバイス。
（項目２０）
前記イベントオブジェクトは、サービス層の一部である、項目１１に記載のデバイス。

【図面の簡単な説明】

【0005】

【図1】図１は、シンプルネットワーク管理プロトコル（ＳＮＭＰ）システムの略図である。

【図2】図２は、ＣｏＡＰオブザーブ特徴を図示する信号フロー図である。

【図3】図３は、アプリケーションサービス層における機能リソースを図示する略図である。

【図4】図４は、例示的ＩｏＴイベントオブジェクトの略図である。

【図5】図５は、例示的ＩｏＴイベント定義の略図である。

【図6】図６は、例示的制御ハンドラの略図である。

【図7】図７は、ＣｏＡＰオブザーブトリガを伴う、例示的かつ非限定的な信号フローを図示する略図である。

【図8】図８は、ＬＷＭ２Ｍデバイス上にいくつかのオブジェクトリソースを含む、例示的オブジェクトを図示する略図である。

【図9】図９は、ＩｏＴイベントオブジェクトの欧州電気通信標準化機構（ＥＴＳＩ）のＭ２Ｍ実施形態に関する例示的リソースツリーの略図である。

【図10】図１０は、ＨＶＡＣシステムを制御するためのＩｏＴイベントオブジェクトの例示的使用を図示する略図である。

【図11A】図１１Ａ−Ｂは、開示されるＩｏＴイベント管理システムおよび方法と併用され得る、例示的インターフェースを図示する略図である。

【図11B】図１１Ａ−Ｂは、開示されるＩｏＴイベント管理システムおよび方法と併用され得る、例示的インターフェースを図示する略図である。

【図12】図１２は、ＩｏＴイベントオブジェクトを伴うＩｏＴイベント管理を実装する、例示的デバイスの略図である。

【図13】図１３は、ｏｎｅＭ２Ｍ ＣＳＦとしてＣＳＥ内にホストされるＩｏＴイベントオブジェクトを含むＩｏＴイベント管理を伴う、例示的ｏｎｅＭ２Ｍ実施形態の略図である。

【図14A】図１４Ａは、ＩｏＴイベント管理システムおよび方法のうちの１つ以上の開示された実施形態が実装され得る、例示的マシンツーマシン（Ｍ２Ｍ）またはモノのインターネット（ＩｏＴ）通信システム１０の略図である。

【図14B】図１４Ｂは、図１４Ａで図示されるＭ２Ｍ／ＩｏＴ通信システム内で使用され得る、例示的アーキテクチャの系統図である。

【図14C】図１４Ｃは、図１４Ａで図示される通信システム内で使用され得る、例示的Ｍ２Ｍ／ＩｏＴ端末またはゲートウェイデバイスの系統図である。

【図14D】図１４Ｄは、図１４Ａの通信システムの側面が具現化され得る、例示的コンピューティングシステムのブロック図である。

【発明を実施するための形態】

【0006】

モノのインターネット（ＩｏＴ）等の多様かつ大規模なシステムでは、システム内の潜在的に数十億とされるデバイスを監視することは、システム全体の適切な動作を確実にすることを支援し得る。ＩｏＴにおけるこれらの「モノ」は、種々のタイプおよび能力であり得、種々の形式における種々のデータを提供し得る。ＩｏＴを最良に利用するために、これらのモノによって供給されるデータは、そのようなデータのより良好な使用を可能にするために、「イベント」に関連付けられ得る。イベントを使用することは、ネットワークのより効率的な動作と、リソースの改良された使用とを可能にする。例えば、スマート温度センサが、周期的な測定を提供するのではなく、現在の温度がある閾値を超える場合のみ測定を報告する場合、ネットワークトラフィックは、減少され得る。制御された環境では、温度変動は、小さくなり得、スマートセンサは、周期的に測定を報告する非スマートセンサよりはるかに少ないトラフィックを生成し得る。

【0007】

イベントは、より自動化された、新しい、よりスマートなアプリケーションを生成するために使用され得る、異なるデバイスからのデータを含み得る。「ＩｏＴイベント」を定義、生成、構成、および管理するための機構は、「ＩｏＴイベント管理」と称され得る。例えば、前述の例のスマート温度センサを既存のセンサと組み合わせることによって、人が部屋にいる場合のみＨＶＡＣシステムを制御することを可能にし得る。加えて、天気予報データもまた使用される場合、ＨＶＡＣシステムは、必要性を予測してオンにするか、または別様に必要に応じて動作するように、知的に動作し得る。

【0008】

いくつかの実施形態において使用され得る機構は、「トラップイベント」と称され得、これは、デバイスの動作の中にプログラムされる条件付きイベントであり、トリガされると、通知を「マネージャ」デバイスに提供する。マネージャは、通知メッセージ内に提供される情報に応じて、適宜応答し得る。

【0009】

トラップイベントは、例えば、シンプルネットワーク管理プロトコル（ＳＮＭＰ）において、コンピュータネットワークを管理するために使用されている。ＳＮＭＰは、図１にアーキテクチャ１００として示されるように、コンピュータネットワーク上の管理されるデバイスのグループを監視および管理する、中央に位置するマネージャ１０２を定義する。ＳＮＭＰマネージャ１０２は、デバイスを構成し、性能を監視し、障害状態を検出し得る。障害状態を検出するためにＳＮＭＰ内に提供される機構は、トラップイベントを使用する。デバイス上で障害状態が発生すると、トラップメッセージが、障害についての情報とともに生成され、マネージャ１０２に送信され得る。マネージャ１０２は、順に、トラップメッセージを処理し、適宜応答し得る。例示的トラップイベントは、デバイスの再起動もしくはシャットダウン、ネットワーク内のリンク失敗の検出、または不適切なアクセスを含む。

【0010】

デバイス上で起動するＳＮＭＰソフトウェアは、「エージェント」１０４と称され得る一方、マネージャ１０２上で起動するソフトウェアは、ネットワーク管理システムまたはＮＭＳと称され得る。エージェント１０４は、いくつかの定義されたトラップイベントのうちの１つを実装し得る。定義されたトラップイベントは、集合的に、一般的トラップイベントと称され得、ｃｏｌｄＳｔａｒｔと、ｗａｒｍＳｔａｒｔと、ｌｉｎｋＤｏｗｎと、ｌｉｎｋＵｐと、ａｕｔｈｅｎｔｉｃａｔｉｏｎＦａｉｌｕｒｅと、ｅｇｐＮｅｉｇｈｂｏｒＬｏｓｓと標識されるイベントを含み得る。一般的トラップに加えて、企業独自のトラップもまた、定義され得る。そのようなトラップは、企業に、それらのデバイスが一般的トラップに加えてサポートするカスタムトラップを定義する能力を提供し得る。

【0011】

トラップイベントの設計および実装は、デバイスのためのソフトウェアの開発中に行われ得る。その結果、トラップイベントは、アプリケーションコードの一部であり得、デバイスが展開される、および／またはコードを実行すると、変更または構成されることができないこともある。このため、各トラップイベントは、これが元々設計された特定のアプリケーションに限定され得る。

【0012】

トラップイベントの機能性と類似する機能性は、制約アプリケーションプロトコル（ＣｏＡＰ）オブザーブ特徴において見出され得る。この特徴は、クライアントに、サーバ等のデバイスにおけるリソースを観察し、ある期間にわたってそのようなリソースに関する更新を提供する能力を提供し得る。図２は、ＣｏＡＰオブザーブ特徴が動作し得る方法を示す、信号フロー２００を図示する略図である。クライアント２０２は、サーバ２０４上の観察可能なリソースのＧＥＴを行い得る。サーバは、そのリソースの現在の状態に応答し得る。観察可能なリソース内で変化が発生すると、別の通知が、新しい状態とともに自動的にクライアントに送信され得る。追加の通知が、ＣｏＡＰオブザーブ要求がキャンセルされるまで、クライアント２０２に送信され得る。

【0013】

ＣｏＡＰオブザーブ特徴は、クライアント２０２に送信される通知をフィルタリングするように拡張され得る。新しいパラメータが、より選択的な通知を提供するために、オブザーブ動作に対して含まれ得る。そのような新しいパラメータ（それらの機能に従って、「Ｇｒｅａｔｅｒ Ｔｈａｎ」、「Ｌｅｓｓ Ｔｈａｎ」、および「Ｓｔｅｐ」等と名付けられ得る）を用いて、クライアントは、観察可能なリソースがパラメータと関連付けられる閾値を超える場合のみ、通知を受信するように要求し得る。いくつかの実施形態では、パラメータが適用され得るリソースは、数値タイプのリソースであるべきことを要求され得る。

【0014】

ある実施形態では、図３の構造３００に示されるように、アプリケーションサービス層における機能リソースの定義は、トラップイベントの実装をサポートし得る。トラップイベントは、機能の入力および出力と関連付けられるパラメータタイプを提供し得る、「ｉｎｐｕｔＴｙｐｅｓ」３０４および「ｏｕｔｐｕｔＴｙｐｅｓ」３０６サブリソースを伴う「＜ｆｕｎｃｔｉｏｎ＞」リソース３０２として生成され得る。図３の表は、構造３００に対する属性のうちのいくつかを示す。サービス層は、「ｔｒｉｇｇｅｒＣｒｉｔｅｒｉａ」属性３０８によって定義されるトリガ条件に基づいて、機能を自律的に呼び出し得る。ｔｒｉｇｇｅｒＣｒｉｔｅｒｉａ３０８のタイプは、１つ以上の規定されるリソースまたはリソースの階層に対する生成、読み出し、更新、削除（ＣＲＵＤ）動作と、メモリリソースの減少およびセキュリティ脅威の検出等のシステムイベントと、リソースの「ｅｘｐｉｒａｔｉｏｎＴｉｍｅ」３１０の到達、リソースの修正、「ａｃｃｅｓｓＲｉｇｈｔｓ」修正等の具体的Ｍ２Ｍ動作の検出とを含み得る。代替として、機能は、実行属性を更新することによって、要求に応じてトリガされ得る。機能の出力は、「ｏｕｔｐｕｔＩｎｓｔａｎｃｅｓ」サブリソース３１２内に記憶され得る。これ以上の通知ハンドリングは、機能の動作の一部として提供されないこともある。

【0015】

トラップイベントの現在の実装は、ＩｏＴデバイスに固定されているか、柔軟ではないか、隠されているか、またはポータブルではない。ＩｏＴシステム内の潜在的に数十億とされるデバイスの展開に伴って、カスタマイズ可能な機能的イベントに基づいて標的通知ハンドリングを可能にする、本明細書に記載されるもの等の機構を提供することが重要である。任意のそのような機構は、柔軟、ポータブル、透過的、かつ拡張可能であるべきである。

【0016】

ＳＮＭＰトラップイベントは、デバイスの動作コードとコンパイルされるカスタムコードにおいて生成され得る。コードは、トリガされると、マネージャに送信されるトラップイベントを生成するために、ＳＮＭＰエージェントを呼び出す。エンドユーザは、トラップイベントをトリガした条件を把握するすべを有しないであろう。加えて、デバイス上に新しいコードを書き込んだり、インストールしたりせずにデバイスが展開されると、トラップイベントを動的に再構成または拡張する機構は、存在しないであろう。

【0017】

ＣｏＡＰオブザーブ特徴は、観察可能なリソースの状態への変更に基づいてトラップイベントを定義する能力を提供する。ＳＮＭＰと同様に、トラップイベントをトリガする条件は、ＧＥＴ要求が完了すると、エンドユーザに把握可能ではないであろう。加えて、オブザーブ要求は、オブザーブイベントが生成された後、構成可能ではなく、拡張可能でもない。

【0018】

ある実施形態では、トラップイベントをサポートするための機能が生成され得る機構が、使用される。そのような機能は、サービス層によって、または、機能リソースの「実行」属性を更新するための「ＲＥＳＴｆｕｌ」要求を通して、自律的にトリガされ得る。これら等の機能は、トラップイベントをトリガし、サービス層におけるリソースとして出力を提供するために、サービス層に依拠し得る。さらなる通知ハンドリングは、提供されないこともある。本実施形態におけるトラップイベントは、サービス層においてホストされ得、したがって、サービス層を伴わないデバイスは、トラップイベントをサポートする能力を有しないであろう。

【0019】

これらの実装の３つ全ては、トラップイベントのある特徴を提供するが、いずれもＩｏＴデバイスに対して完全に好適ではない。トラップイベント能力を伴うＩｏＴデバイスを効率的に提供するために、既存のトラップイベント実装は、柔軟性、ポータビリティ、透過性、および拡張性に関して改良される必要がある。

【0020】

ある実施形態では、ＩｏＴデバイスおよびゲートウェイを標的にされ得るが、サービス層を起動するサーバにも存在し得る、ＩｏＴイベントオブジェクト４００が、生成される。そのようなＩｏＴイベントオブジェクト４００の特徴は、イベントを生成するための一貫したインターフェースを提供しながら、異なる能力およびリソースを有するＩｏＴデバイスおよびゲートウェイに対してイベントオブジェクト４００を調整することを含み得る。ＩｏＴイベントオブジェクト４００は、異なるトリガ条件および優先順位を設定する能力を提供しながら、イベントの柔軟かつ再構成可能な定義を可能にすることができる。個々のイベント定義４０２は、より複合的なイベントを生成するように拡張され得る。通知ハンドラ４０４は、アクションを要求するイベントに応答して、要求またはコマンドを送信することをサポートし得る。開示されるＩｏＴイベントオブジェクト４００は、ＩｏＴデバイスおよびゲートウェイが実装し得る、イベントを規定するポータブルかつ透過性のある方法を提供することができる。開示されるＩｏＴイベントオブジェクト４００は、ＩｏＴシステムのより知的な動作を可能にし得る所望の情報を提供することによって、ネットワークトラフィックを減少させ得る。加えて、開示されるＩｏＴイベントオブジェクト４００は、オブジェクト内またはサービス層上に能力を提供することによって、アプリケーション論理を単純化し得る。

【0021】

ある実施形態では、ＩｏＴイベントオブジェクト４００は、トラップイベントを実装するための全ての機能性を含み得る。そのようなＩｏＴイベントオブジェクト４００は、イベントを定義および生成し、トリガおよび制御条件を定義し、イベントを評価するための下層論理を提供し、イベントを再構成および拡張するための能力を可能にし、いくつかの通知ハンドリングオプションを提供する機構を含み得る。図４は、例示的かつ非限定的なＩｏＴイベントオブジェクト４００の構造４００を示す。本実施例では、ＩｏＴイベントオブジェクト４００は、ＩｏＴイベント定義４０２と、制御ハンドラ４０６と、通知ハンドラ４０４と、オブジェクト情報リソース４０８とを含む。

【0022】

図４に示されるように、ＩｏＴイベントオブジェクト４００は、最大Ｎ個の個々のイベント定義４０２を含み得る。図５に示されるように、各イベント定義４０２は、イベント式５０２と、関連付けられたトリガ条件５０４と、トリガ優先順位５０６とから成り得る。１つ以上のイベントは、制御ハンドラ４０６によって、より複合的なイベントを生成するために組み合わせられ得る。その結果、各イベントは、最初に、独立して定義され得、後に、必要に応じて、より複合的なイベントを生成するために拡張され得る。これは、イベントを定義する際に柔軟性を提供し、将来的なイベント定義の拡張性を可能にする。

【0023】

図５に例示的かつ非限定的なイベント定義４０２の一部として示されるイベント式等、イベント定義のイベント式は、イベントを生じさせる条件を定義し得る。イベント式は、代数式、カスタム関数、セマンティック式（デバイスは、セマンティックタイプをサポートする）、または任意の他のタイプの関数もしくは式であり得る。式は、監視され、ある閾値と比較されるべき１つ以上のリソースを含み得る。そのようなものとして、オペランド、オペレータ、および閾値が、定義を形成するために提供され得る。

【0024】

イベント式のオペランドは、内部リソース、外部リソース、ある外部関数の出力、または別のＩｏＴイベントの出力であり得る。オペレータに対して、算術、論理、カスタム関数、またはセマンティックキーワードが、使用され得る。閾値は、前述のオペランドタイプのいずれかだけではなく、数字、文字列、および他の複合タイプであり得る。いくつかの非限定的かつ例示的イベント式が、以下にリスト化される。
−（ｐｒｅｓｓｕｒｅ＞３２）−ここでは、ｐｒｅｓｓｕｒｅは、リソースである。
−（ｔｅｍｐｅｒａｔｕｒｅ＞９０）ａｎｄ（ｈｕｍｉｄｉｔｙ＞７５）−ここでは、ｔｅｍｐｅｒａｔｕｒｅおよびｈｕｍｉｄｉｔｙは、リソースである。
−（ｐｒｅｓｅｎｃｅ＝１）ａｎｄ［（ｔｉｍｅ＞８：００）ａｎｄ（ｔｉｍｅ＜１７：００）］−ここでは、ｐｒｅｓｅｎｃｅおよびｔｉｍｅは、リソースである。
−｛ｆ（ｔ）＝（ｓｐｅｅｄ（ｔ−１）＋ｓｐｅｅｄ（ｔ））／ｅｌａｐｓｅｄ＿ｔｉｍｅ｝＞（ｘ）−ここでは、ｓｐｅｅｄおよびｅｌａｐｓｅｄ＿ｔｉｍｅは、リソースである。これは、ＩｏＴイベント定義において使用されている関数の実施例であることに留意されたい。関数は、内部で定義されるか、または外部で定義され、ユニフォームリソース識別子（ＵＲＩ）によって参照され得る。
−（ＧＰＳ ｃｏｏｒｄｉｎａｔｅｓ）ｉｎ ｔｈｅ ａｒｅａ ｏｆ １９４０６−ここでは、ＧＰＳ ｃｏｏｒｄｉｎａｔｅｓおよび１９４０６は、リソースである。これは、セマンティック式の例であることに留意されたい。
−Ｔｈｅ ａｖｅｒａｇｅ ｏｆ（ｘ） ｉｓ ｌｅｓｓ ｔｈａｎ（ｙ）−ここでは、ｘおよびｙは、リソースである。これは、セマンティック式の別の実施例であることに留意されたい。

【0025】

イベント式において規定される全てのリソースに関して、関連付けられたトリガ条件は、イベントがどう評価されるべきかを規定し得る。ある実施形態では、トリガ機構は、下層サービス層によってサポートされる、および／またはＣｏＡＰオブザーブＧｅＴ要求によってサポートされる参照ＵＲＩトリガであり得る。他の実施形態では、サブスクリプショントリガ、タイマベースの読み出しトリガ、および要求に応じた読み出しトリガのいずれかが、使用され得る。

【0026】

参照ＵＲＩトリガは、単純に、リソースへの参照ＵＲＩであり得る。この場合、下層サービス層によってサポートされるトリガと、ＣｏＡＰオブザーブ要求によってサポートされるトリガとの、２つのサブトリガ機構が存在し得る。いずれの場合も、リソースの更新は、イベント式の評価をトリガし得る。

【0027】

リソースがサブスクリプショントリガのために構成される場合、ＩｏＴイベントオブジェクト４００は、イベントが制御ハンドラ内でアクティブ化された後、リソースへのサブスクリプションを自動的に生成し得る。リソースのサブスクリプションＵＲＩは、ＩｏＴイベント式５０２内に直接的に、またはトリガ条件リソース５０４内に間接的に規定され得る。サブスクリプションから生成される、結果として生じる通知は、次いで、イベントの評価をトリガし得る。

【0028】

イベントの評価をトリガするための別の方法は、単純に、リソースの読み出しを行うことである。タイマが、リソース値を周期的に読み出すために使用されることができる。代替として、要求に応じた読み出しは、制御ハンドラ４０６内で規定されると、実行され得る。読み出し要求への応答は、イベントの評価をトリガするであろう。

【0029】

複数のリソースを含むＩｏＴイベント式５０２に対して、それに基づいてトリガ条件が先行する優先順位が、トリガ優先順位リソース５０６内に規定され得る。ある実施形態では、優先順位は、各リソースに割り当てられ得、そのトリガ条件５０４がリスト化されるリソースのみが、イベントの評価をトリガし得る。別の実施形態では、任意のリソースに割り当てられる優先順位は、存在しないことがあり、発生する第１のトリガ条件が、イベントの評価をトリガする。

【0030】

トリガ条件５０４がリソースに対して発生すると、ＩｏＴイベントオブジェクト４００は、イベント式を評価する前に、残りのリソースを読み出し得る。所望される場合、タイマが、ＩｏＴイベントオブジェクト４００が読み出しに対する応答を待つ期間を制御するために使用され得る。全ての応答が時間内に受信されない場合、エラー通知が、イベントが実行されなかったことを示すために送信され得る。

【0031】

イベント式５０２およびトリガ条件５０４が定義されると、状態情報が、イベントが動作する方法を制御するために規定され得る。図６の例示的かつ非限定的な制御ハンドラ４０６等、制御ハンドラ４０６は、状態リソース６０２を通してこの機能性を提供し得る。リソースは、「オン、連続」の状態にあり得、イベントは、連続的に動作し、通知が、トリガ条件が満たされる度に送信される。リソースは、「オン、発生ベース」の状態にあり得、イベントは、規定される発生回数の間、連続的に動作する。発生回数が満たされると、通知が、送信され、状態は、オフに変更され得る。リソースは、「オン、タイマベース」の状態にあり得、イベントは、規定された時間間隔の間、連続的に動作し、状態は、時間間隔外でオフに変更される。通知は、トリガ条件が時間間隔内に満たされる場合のみ、送信され得る。時間間隔外に発生する任意のトリガ条件は、通知を生成しないことがある。リソースは、「オフ」の状態にあり得、イベントは、アクティブではなく、任意のトリガ条件に応答しないであろう。

【0032】

状態リソース６０２に加えて、制御ハンドラ４０６はまた、複合イベントジェネレータリソース６０４を有し得る。このリソース６０４は、個々のＩｏＴイベント定義を、より複合的なイベントに組み合わせる機構を提供し得る。これは、リソースの代わりにＩｏＴイベント定義を参照することを除いて、ＩｏＴイベント式と類似する。この機構は、個々のＩｏＴイベント定義を単純かつ柔軟であるように保ち、イベントのより複合的な条件への拡張を可能にし得る。

【0033】

複合イベントが複合イベントジェネレータ６０４を用いて生成される実施形態では、個々のイベント定義の下層トリガ条件は、複合イベントトリガのために使用され得る。加えて、複合トリガ優先順位リソース６０６は、イベント定義に与えられる優先順位を規定するための機構を提供し得る。トリガ優先順位５０６と同様に、複合トリガ優先順位６０６は、複合イベントの評価をトリガし得るＩｏＴイベント定義を規定する方法を提供し得る。

【0034】

イベントがトリガすると、処理は、通知が処理されるべき方法を決定し得る通知ハンドラ４０４に移行され得る。例えば、通知は、アラートを規定されたＵＲＩに送信すること（これは、生成される全てのエラーメッセージに対して、ＩｏＴイベントオブジェクト４００によって自動的に行われ得る）、リソースに要求またはコマンドを送信すること、および／またはイベントを仮想リソースとして記憶することによってハンドリングされ得る。

【0035】

アラートが規定されたＵＲＩに送信される場合、メッセージは、ＵＲＩによって規定されたリソースに、トリガされているイベントの結果を通知するために処理され得る。追加の情報が、イベントをトリガしたもの、発生の日付およびタイムスタンプ、および／または任意の他のカスタム説明のより詳細な説明を提供するように構成され得る。通知メッセージがエラーの結果であった実施形態では、エラーコードおよびエラーの説明が、通知メッセージ内に含まれ得る。

【0036】

要求またはコマンドがリソースに送信される場合、通知ハンドラ４０４は、イベント発生に応答して、別のリソースに要求またはコマンドを送信し得る。そのような実施形態は、何らかが失敗した場合に即時のアクションを要求する、ある用途のために使用され得る。例えば、電車のブレーキは、前方を横切る線路上のセンサが自動車または人物の存在を検出した場合、自動的に適用され得る。

【0037】

イベントが仮想リソースとして記憶されている場合、これは、実際のリソースのように対処され得る。本実施形態は、監視を単純化するために、種々のリソースの状態を、１つのリソースに組み合わせるために使用され得る。本実施形態は、１つのイベントのトリガが第２のイベントをトリガするカスケードイベントのために有用であり得る。

【0038】

通知ハンドラ４０４によって通知をハンドリングする各実施形態は、互に並行して有効にされ、起動され得ることに留意されたい。例えば、複数通知ハンドラオプションが、家屋におけるガス漏出の検知時に使用され得、通知メッセージが、家主とガス会社との両方に送信され、コマンドが、家屋の主要電気ブレーカを無効化するために送信される。

【0039】

ＩｏＴデバイス能力は、限定されたリソースを伴う、小型の非常に制約されたデバイスから、より多くのリソースを伴う、より大型のデバイスまで様々であり得る。したがって、ＩｏＴイベントオブジェクト４００は、デバイスまたはデバイスタイプの能力に基づいて、特定のデバイスまたはデバイスタイプに合わされ得る。例えば、限定されたトリガ機構を伴う基本的オペランドおよびオペレータのみが、非常に制約されたデバイス内でサポートされる一方、拡張されたオペランドおよびオペレータは、より多くのリソースを有するデバイス内でサポートされ得る。

【0040】

オブジェクト情報リソース４０８は、デバイスがサポートするＩｏＴイベントオブジェクト４００の機能性についての情報を提供し得る。このオブジェクト情報リソース４０８は、他のデバイス、ゲートウェイ、プロキシ、またはサーバに、デバイス上で動作し得るサポートされるイベントを広告する目的を果たし得る。このオブジェクト情報リソース４０８は、サポートされるオペランドおよびオペレータのタイプと、サポートされるトリガ機構および優先順位と、サポートされるイベントの制御状態と、複合イベントがサポートされるかどうかと、サポートされる通知ハンドラとを含み得る。

【0041】

図７は、ＣｏＡＰオブザーブトリガが利用される、例示的かつ非限定的な信号フロー７００を図示する略図である。あるアプリケーションが、ある条件がデバイス１ ７０２とデバイス２ ７０４との間に存在する場合、通知されることを望み得る。

【0042】

図７のステップ１において、アプリケーションは、デバイスが登録されているゲートウェイ７０６上にＩｏＴイベントオブジェクト４００を生成し得る。

【0043】

図７のステップ２−３において、トリガ条件が、外部リソースのＣｏＡＰオブザーブを使用するために設定され得る。その結果、ゲートウェイ７０６は、ＣｏＡＰオブザーブ要求をデバイスに送信し得る。

【0044】

図７のステップ４において、ある時間の後、デバイス２ ７０４は、更新の通知をそのリソースに提供し得る。

【0045】

図７のステップ５において、ＩｏＴイベントオブジェクト４００は、順に、デバイス１のリソースを読み出し、イベント式を評価し得る。図示される実施例では、評価は、失敗し、通知は、送信されない。

【0046】

図７のステップ６において、デバイス１ ７０２がそのリソースの更新を送信する前に、ある時間が経過する。

【0047】

図７のステップ７において、これは、ゲートウェイが、イベント式を評価するために、デバイス２のリソースを読み出す結果をもたらし得る。

【0048】

図７のステップ８において、この時、イベント評価は、成功し、通知が、アプリケーション７０８に送信される。

【0049】

図７に図示されるステップを行うエンティティは、図１４Ｃまたは１４Ｄに図示されるもののうちの１つ等、デバイス、サーバ、または他のコンピュータシステムのプロセッサのメモリ内に記憶され、その上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態において実装され得る、論理エンティティであることが理解される。つまり、図７に図示される方法は、例えば、図１４Ｃまたは１４Ｄに図示されるデバイスまたはコンピュータシステム等、コンピューティングデバイスのメモリ内に記憶されるソフトウェア（すなわち、コンピュータ実行可能命令）の形態において実装され得、コンピュータ実行可能命令は、コンピューティングデバイスのプロセッサによって実行されると、図７に図示されるステップを行う。

【0050】

ある実施形態では、ＩｏＴイベントオブジェクト４００は、オープンモバイルアライアンス（ＯＭＡ）軽量Ｍ２Ｍ（ＬＷＭ２Ｍ）アーキテクチャ内で使用され得る。ＬＷＭ２Ｍデバイスは、温度、湿度、光、および存在に対するセンサ測定を提供し得る。デバイスは、これらのセンサ読み取り値をＬＷＭ２Ｍサーバに提供し得る。ＬＷＭ２Ｍサーバに接続されるアプリケーションは、読み取り値を監視し、部屋が暑いことをセンサ読み取り値が示す場合、空調装置をオンにするために使用され得る。

【0051】

未加工のセンサ読み取り値をＬＷＭ２Ｍサーバに提供し、アプリケーションにそれらを全て処理するように要求するのではなく、ＩｏＴイベントオブジェクトが、部屋が暑くなる度のみに通知を提供するように生成され得る。図８は、ＬＷＭ２Ｍデバイス上にいくつかのオブジェクトリソースを含むオブジェクト８００を示す。この図では、オブジェクト５は、センサ読み取り値を提供し得、オブジェクト７は、ＩｏＴイベントオブジェクトであり得る。例えば、オブジェクト８００は、以下のように構成され得る。
−７／１＝＜デバイスがサポートするイベントオブジェクト機能性の情報＞
−７／２／１＝オン、連続
−７／３／１＝＜通知が送信されるべきＬＷＭ２ＭサーバのＵＲＩ＞
−７／４／１＝｛（／５／１＞７５）ａｎｄ（／５／２＞８０）ａｎｄ（／５／４＝１）｝
−７／４／２＝内部リソース参照
−７／４／３＝優先順位は非選択
−全ての他のリソースは不適用
この例示的構成は、温度が７５度を上回り、湿度が８０％を上回り、存在センサが室内に人物を検出する場合、イベントがトリガされるであろうことを規定する。イベントがトリガすると、通知が、ＬＷＭ２Ｍサーバに送信され得る。さらなるイベント定義が、異なるイベントに対する通知を提供するために、ＩｏＴイベント♯１と並行して生成され得る。

【0052】

ＩｏＴイベントオブジェクトの欧州電気通信標準化機構（ＥＴＳＩ）のＭ２Ｍ実施形態が、図９およびリソースツリー９００に示される。ある実施形態では、ＥＴＳＩリソースおよび属性が、ＩｏＴイベントオブジェクト機能性をサポートするために提供される。これらのリソースおよび属性は、ＯＭＡ ＬＷＭ２Ｍ実施形態に提示されるものと類似する構造を有し得る。本実施形態では、サービス能力層（ＳＣＬ）は、ＩｏＴイベントオブジェクトによって行われる下層動作を実装し得る。ＳＣＬ上のリソースは、ＩｏＴイベントオブジェクトがＳＣＬに統合される程度に応じて、内部または外部リソースとして分類され得る。そのような実施形態は、ＯｎｅＭ２Ｍアーキテクチャにも適用され得ることに留意されたい。

【0053】

図９に示されるリソースを使用して、１つのイベントまたは複数のイベントが、図１０および例示的かつ非限定的なシステム１０００に示されるように、温度、湿度、および存在センサだけではなく、地域の気象予報ならびに日付および時間に基づいて、ＨＶＡＣシステムを制御するために生成され得る。例示的ＩｏＴイベント構成が、以下に提供される。
−ｅｖｅｎｔ１／ｄｅｆｉｎｉｔｉｏｎ１／ｅｘｐｒｅｓｓｉｏｎ＝（／ｓｃｌＢａｓｅ／ａｐｐｌｉｃａｔｉｏｎｓ／ａｐｐ１／ｃｏｎｔａｉｎｅｒｓ／ｔｅｍｐ／ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅｓ／ｌａｔｅｓｔ＞７５）−イベントは、最新の温度読み取りに対する通知を得るためのサブスクリプションを有し得ることに留意されたい。
−ｅｖｅｎｔ１／ｄｅｆｉｎｉｔｉｏｎ１／ｔｒｉｇｇｅｒＣｏｎｄｉｔｉｏｎ＝参照ＵＲＩ
−ｅｖｅｎｔ１／ｄｅｆｉｎｉｔｉｏｎ１／ｔｒｉｇｇｅｒＰｒｉｏｒｉｔｙ＝優先順位は非選択
−ｅｖｅｎｔ１／ｄｅｆｉｎｉｔｉｏｎ２／ｅｘｐｒｅｓｓｉｏｎ＝（／ｓｃｌＢａｓｅ／ａｐｐｌｉｃａｔｉｏｎｓ／ａｐｐ１／ｃｏｎｔａｉｎｅｒｓ／ｐｒｅｓｅｎｃｅ／ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅｓ／ｌａｔｅｓｔ＝１）−イベントは、最新の存在センサ読み取りに対する通知を得るためのサブスクリプションを有し得ることに留意されたい。
−ｅｖｅｎｔ１／ｄｅｆｉｎｉｔｉｏｎ２／ｔｒｉｇｇｅｒＣｏｎｄｉｔｉｏｎ＝参照ＵＲＩ
−ｅｖｅｎｔ１／ｄｅｆｉｎｉｔｉｏｎ２／ｔｒｉｇｇｅｒＰｒｉｏｒｉｔｙ＝優先順位は非選択
−ｅｖｅｎｔ１／ｄｅｆｉｎｉｔｉｏｎ３／ｅｘｐｒｅｓｓｉｏｎ＝（ｉｆ［ｈｔｔｐ：／／ｗｗｗ．ｗｅａｔｈｅｒ．ｃｏｍ／ｗｅａｔｈｅｒ／ｔｏｄａｙ／＜ａｒｅａ＿ｉｎｆｏ＞］ｉｓ｛ｈｉｇｈ＞９０，ｌｏｗ＞８０，ｈｕｍｉｄｉｔｙ＞８０，ｓｕｎｎｙ｝）−これは、高温が９０度を上回り、低温が８０度を上回り、湿度が８０％を上回り、空が晴れている場合、天気予報が確認されるセマンティック式の例であり、全４つの条件が満たされる場合のみ、式は、真と評価することに留意されたい。
−ｅｖｅｎｔ１／ｄｅｆｉｎｉｔｉｏｎ３／ｔｒｉｇｇｅｒＣｏｎｄｉｔｉｏｎ＝要求に応じた読み出し
−ｅｖｅｎｔ１／ｄｅｆｉｎｉｔｉｏｎ３／ｔｒｉｇｇｅｒＰｒｉｏｒｉｔｙ＝優先順位は非選択
−ｅｖｅｎｔ１／ｃｔｒｌＨａｎｄｌｅｒ／ｓｔａｔｅ＝オン、連続
−ｅｖｅｎｔ１／ｃｔｒｌＨａｎｄｌｅｒ／ｃｍｐｌｘＥｖｅｎｔＧｅｎ＝定義１および定義２および定義３−これは、トリガするイベントに対して、定義１、２、および３の全てが真と評価される必要がある複合イベントであることに留意されたい。
−ｅｖｅｎｔ１／ｃｔｒｌＨａｎｄｌｅｒ／ｃｍｐｌｘＴｒｉｇｇｅｒＰｒｉｏｒｉｔｙ＝定義１または定義２−この複合イベントは、優先トリガを有し、定義１または２のみが、イベントの評価をトリガするであろう。いずれかのイベントの発生時、要求に応じた残りの定義の読み出しが、行われることに留意されたい。
−ｅｖｅｎｔ１／ｎｏｔｉｆＨａｎｄｌｅｒ／ｃｏｍｍａｎｄ＝＜ＨＶＡＣリソースをオンにするためのコマンド＞
−ｅｖｅｎｔ２／ｄｅｆｉｎｉｔｉｏｎ１／ｅｘｐｒｅｓｓｉｏｎ＝（／ｓｃｌＢａｓｅ／ａｐｐｌｉｃａｔｉｏｎｓ／ａｐｐ１／ｃｏｎｔａｉｎｅｒｓ／ｈｕｍｉｄｉｔｙ／ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅｓ／ｌａｔｅｓｔ＞５０）−このイベントは、最新の湿度読み取りに対する通知を得るためのサブスクリプションを有することに留意されたい。
−ｅｖｅｎｔ２／ｄｅｆｉｎｉｔｉｏｎ１／ｔｒｉｇｇｅｒＣｏｎｄｉｔｉｏｎ＝参照ＵＲＩ
−ｅｖｅｎｔ２／ｄｅｆｉｎｉｔｉｏｎ１／ｔｒｉｇｇｅｒＰｒｉｏｒｉｔｙ＝優先順位は非選択
−ｅｖｅｎｔ２／ｄｅｆｉｎｉｔｉｏｎ２／ｅｘｐｒｅｓｓｉｏｎ＝（ｃｕｒｒｅｎｔ＿ｄａｔｅは、２０１３年７月１日〜２０１３年７月１４日である）−これは、イベントがアクティブである２週間の期間を規定するセマンティック式であることに留意されたい。
−ｅｖｅｎｔ２／ｄｅｆｉｎｉｔｉｏｎ２／ｔｒｉｇｇｅｒＣｏｎｄｉｔｉｏｎ＝タイマベースのリソース
−ｅｖｅｎｔ２／ｄｅｆｉｎｉｔｉｏｎ２／ｔｒｉｇｇｅｒＰｒｉｏｒｉｔｙ＝優先順位は非選択
−ｅｖｅｎｔ２／ｃｔｒｌＨａｎｄｌｅｒ／ｓｔａｔｅ＝オン、タイマベース
−ｅｖｅｎｔ２／ｃｔｒｌＨａｎｄｌｅｒ／ｃｍｐｌｘＥｖｅｎｔＧｅｎ＝定義１および定義２
−ｅｖｅｎｔ２／ｃｔｒｌＨａｎｄｌｅｒ／ｃｍｐｌｘＴｒｉｇｇｅｒＰｒｉｏｒｉｔｙ＝定義１および定義２
−ｅｖｅｎｔ２／ｎｏｔｉｆＨａｎｄｌｅｒ／ｃｏｍｍａｎｄ＝＜ＨＶＡＣリソースをオンにするためのコマンド＞
本実施形態では、互に独立しているが、機能性において関連付けられる、２つのイベントが、生成される。イベント１は、通常動作を提供し、ＨＶＡＣシステムを制御するために、存在および温度センサだけではなく、天気予報からのデータを使用し得る。イベント２は、湿度が２０１３年７月１日から２０１３年７月１４日までの２週間の期間中（例えば、この特定のシステムのユーザが休暇中であるとき）に、ある閾値を上回る場合のみ、効果を生じ得る。さらなるイベントが、快適性とエネルギー節約との間の最適なバランスを見出すために生成され得る。

【0054】

図１１Ａ−Ｂは、開示されるＩｏＴイベント管理システムおよび方法とともに使用され得る、例示的インターフェースを図示する略図である。図１１Ａは、イベント通知／イベントアラートと、イベントのリスト、イベントに関連付けられたリソース値等のイベント状態情報と、イベントが設定された時期、イベントアラートの履歴等についての情報等のイベント履歴とを表示するために使用され得る、インターフェース１１０２を図示する。図１１Ｂは、イベントと、そのようなイベントを構築することを含む複合イベントとを設定するだけではなく、イベントを設定するためのリソースを見出すために使用され得る、インターフェース１１０４を図示する。

【0055】

図１２は、ＩｏＴイベントオブジェクト４００を伴うＩｏＴイベント管理１２０４を実装する、例示的デバイス１２０２の略図である。デバイスは、ＩｏＴデバイスまたは他のデバイスであり得る。

【0056】

デバイス１２０２上のＩｏＴイベント管理１２０４は、サービス層の一部であり得る。例えば、ｏｎｅＭ２Ｍは、ｏｎｅＭ２Ｍサービス層によってサポートされる能力を定義する。ｏｎｅＭ２Ｍサービス層は、能力サービス機能（ＣＳＦ）のセットを備えている、能力サービスエンティティ（ＣＳＥ）としてインスタンス化される。図１３は、ｏｎｅＭ２Ｍ ＣＳＦ１３０４としてＣＳＥ１３０２内にホストされるＩｏＴイベントオブジェクト４００を含むＩｏＴイベント管理１２０４を伴う、例示的実施形態の略図である。

【0057】

図１４Ａは、１つ以上の開示される実施形態が実装され得る、例示的マシンツーマシン（Ｍ２Ｍ）、モノのインターネット（ＩｏＴ）、またはモノのウェブ（ＷｏＴ）通信システム１０の略図である。概して、Ｍ２Ｍ技術は、ＩｏＴ／ＷｏＴのための基礎的要素を提供し、任意のＭ２Ｍデバイス、ゲートウェイ、またはサービスプラットフォームは、ＩｏＴ／ＷｏＴだけではなく、ＩｏＴ／ＷｏＴサービス層等の構成要素であり得る。通信システム１０は、開示される実施形態の機能性を実装するために使用され得、図１１Ａおよび１１Ｂに示されるユーザインターフェースを生成するために、ＩｏＴイベント管理１２０４、ＩｏＴイベントオブジェクト４００、ＩｏＴイベント定義４０２、制御ハンドラ４０６、通知ハンドラ４０４、および論理エンティティ等の機能性および論理エンティティを含むことができる。

【0058】

図１４Ａに示されるように、Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０は、通信ネットワーク１２を含む。通信ネットワーク１２は、固定ネットワーク（例えば、イーサネット（登録商標）、ファイバ、ＩＳＤＮ、ＰＬＣ等）または無線ネットワーク（例えば、ＷＬＡＮ、セルラー等）、もしくは異種ネットワークのネットワークであり得る。例えば、通信ネットワーク１２は、音声、データ、ビデオ、メッセージング、ブロードキャスト等のコンテンツを複数のユーザに提供する、多重アクセスネットワークから成り得る。例えば、通信ネットワーク１２は、符号分割多重アクセス（ＣＤＭＡ）、時分割多重アクセス（ＴＤＭＡ）、周波数分割多重アクセス（ＦＤＭＡ）、直交ＦＤＭＡ（ＯＦＤＭＡ）、単一キャリアＦＤＭＡ（ＳＣ−ＦＤＭＡ）等の１つ以上のチャネルアクセス方法を採用し得る。さらに、通信ネットワーク１２は、例えば、コアネットワーク、インターネット、センサネットワーク、工業制御ネットワーク、パーソナルエリアネットワーク、融合個人ネットワーク、衛星ネットワーク、ホームネットワーク、または企業ネットワーク等の他のネットワークを備え得る。

【0059】

図１４Ａに示されるように、Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０は、インフラストラクチャドメインおよびフィールドドメインを含み得る。インフラストラクチャドメインは、エンドツーエンドＭ２Ｍ展開のネットワーク側を指し、フィールドドメインは、通常、Ｍ２Ｍゲートウェイの背後にある、エリアネットワークを指す。フィールドドメインは、Ｍ２Ｍゲートウェイ１４および端末デバイス１８を含む。任意の数のＭ２Ｍゲートウェイデバイス１４およびＭ２Ｍ端末デバイス１８が、所望に応じて、Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０に含まれ得ることが理解されるであろう。Ｍ２Ｍゲートウェイデバイス１４およびＭ２Ｍ端末デバイス１８の各々は、通信ネットワーク１２または直接無線リンクを介して、信号を伝送および受信するように構成される。Ｍ２Ｍゲートウェイデバイス１４は、無線Ｍ２Ｍデバイス（例えば、セルラーおよび非セルラー）ならびに固定ネットワークＭ２Ｍデバイス（例えば、ＰＬＣ）が、通信ネットワーク１２等のオペレータネットワークを通して、または直接無線リンクを通してのいずれかで、通信することを可能にする。例えば、Ｍ２Ｍデバイス１８は、データを収集し、通信ネットワーク１２または直接無線リンクを介して、データをＭ２Ｍアプリケーション２０またはＭ２Ｍデバイス１８に送信し得る。Ｍ２Ｍデバイス１８はまた、Ｍ２Ｍアプリケーション２０またはＭ２Ｍデバイス１８からデータを受信し得る。さらに、データおよび信号は、以下で説明されるように、Ｍ２Ｍサービス層２２を介して、Ｍ２Ｍアプリケーション２０に送信され、そこから受信され得る。Ｍ２Ｍデバイス１８およびゲートウェイ１４は、例えば、セルラー、ＷＬＡＮ、ＷＰＡＮ（例えば、Ｚｉｇｂｅｅ（登録商標）、６ＬｏＷＰＡＮ、Ｂｌｕｅｔｏｏｔｈ（登録商標））、直接無線リンク、および有線を含む、種々のネットワークを介して通信し得る。

【0060】

図１４Ｂを参照すると、フィールドドメイン内の図示されるＭ２Ｍサービス層２２は、Ｍ２Ｍアプリケーション２０、Ｍ２Ｍゲートウェイデバイス１４、およびＭ２Ｍ端末デバイス１８、ならびに通信ネットワーク１２のためのサービスを提供する。通信ネットワーク１２は、開示される実施形態の機能性を実装するために使用され得、ＩｏＴイベント管理１２０４、ＩｏＴイベントオブジェクト４００、ＩｏＴイベント定義４０２、制御ハンドラ４０６、通知ハンドラ４０４、ならびに図１１Ａおよび１１Ｂに示されるユーザインターフェースを生成するための論理エンティティ等の機能性および論理エンティティを含むことができる。Ｍ２Ｍサービス層２２は、例えば、以下で説明される図１４Ｃおよび１４Ｄで図示されるデバイスを含む、１つ以上のサーバ、コンピュータ、デバイス、仮想マシン（例えば、クラウド／記憶ファーム等）等によって実装され得る。Ｍ２Ｍサービス層２２は、所望に応じて、任意の数のＭ２Ｍアプリケーション、Ｍ２Ｍゲートウェイデバイス１４、Ｍ２Ｍ端末デバイス１８、および通信ネットワーク１２と通信し得ることが理解されるであろう。Ｍ２Ｍサービス層２２は、１つ以上のサーバ、コンピュータ等によって実装され得る。Ｍ２Ｍサービス層２２は、Ｍ２Ｍ端末デバイス１８、Ｍ２Ｍゲートウェイデバイス１４、およびＭ２Ｍアプリケーション２０に適用されるサービス能力を提供する。Ｍ２Ｍサービス層２２の機能は、例えば、ウェブサーバとして、セルラーコアネットワーク内で、クラウド内で等、種々の方法で実装され得る。図示されるＭ２Ｍサービス層２２と同様に、インフラストラクチャドメイン内にＭ２Ｍサービス層２２’が存在する。Ｍ２Ｍサービス層２２’は、インフラストラクチャドメイン内のＭ２Ｍアプリケーション２０’および下層通信ネットワーク１２’のためのサービスを提供する。Ｍ２Ｍサービス層２２’はまた、フィールドドメイン内のＭ２Ｍゲートウェイデバイス１４およびＭ２Ｍ端末デバイス１８のためのサービスも提供する。Ｍ２Ｍサービス層２２’は、任意の数のＭ２Ｍアプリケーション、Ｍ２Ｍゲートウェイデバイス、およびＭ２Ｍ端末デバイスと通信し得ることが理解されるであろう。Ｍ２Ｍサービス層２２’は、異なるサービスプロバイダによるサービス層と相互作用し得る。Ｍ２Ｍサービス層２２’は、１つ以上のサーバ、コンピュータ、仮想マシン（例えば、クラウド／計算／記憶ファーム等）等によって実装され得る。

【0061】

図１４Ｂも参照すると、Ｍ２Ｍサービス層２２および２２’は、多様なアプリケーションおよびバーティカルが活用され得る、サービス送達能力のコアセットを提供する。これらのサービス能力は、Ｍ２Ｍアプリケーション２０および２０’がデバイスと相互作用し、データ収集、データ分析、デバイス管理、セキュリティ、課金、サービス／デバイス発見等の機能を果たすことを可能にする。本質的に、これらのサービス能力は、これらの機能性を実装する負担をアプリケーションから取り除き、したがって、アプリケーション開発を単純化し、市場に出すコストおよび時間を削減する。サービス層２２および２２’はまた、Ｍ２Ｍアプリケーション２０および２０’が、サービス層２２および２２’が提供するサービスと関連して、種々のネットワーク１２および１２’を通して通信することも可能にする。本願の接続方法は、サービス層２２および２２’の一部として実装され得る。サービス層２２および２２’は、アプリケーションプログラミングインターフェース（ＡＰＩ）および下層ネットワーキングインターフェースのセットを通して付加価値サービス能力をサポートする、ソフトウェアミドルウェア層である。ＥＴＳＩ Ｍ２ＭおよびｏｎｅＭ２Ｍの両方は、本願の接続方法を含み得る、サービス層を使用する。ＥＴＳＩ Ｍ２Ｍのサービス層は、サービス能力層（ＳＣＬ）と称される。ＳＣＬは、Ｍ２Ｍデバイス（デバイスＳＣＬ（ＤＳＣＬ）と称される）、ゲートウェイ（ゲートウェイＳＣＬ（ＧＳＣＬ）と称される）、および／またはネットワークノード（ネットワークＳＣＬ（ＮＳＣＬ）と称される）内に実装され得る。ｏｎｅＭ２Ｍサービス層は、共通サービス機能（ＣＳＦ）（すなわち、サービス能力）のセットをサポートする。１つ以上の特定のタイプのＣＳＦのセットのインスタンス化は、異なるタイプのネットワークノード（例えば、インフラストラクチャノード、中間ノード、特定用途向けノード）上にホストされ得る、共通サービスエンティティ（ＣＳＥ）と称される。さらに、本願の接続方法は、本願の接続方法等のサービスにアクセスするために、サービス指向アーキテクチャ（ＳＯＡ）および／またはリソース指向アーキテクチャ（ＲＯＡ）を使用する、Ｍ２Ｍネットワークの一部として実装されることができる。

【0062】

いくつかの実施形態では、Ｍ２Ｍアプリケーション２０および２０’は、キャピラリデバイスと相互作用するアプリケーションを含み得、したがって、開示されるシステムおよび方法と併せて使用され得る。Ｍ２Ｍアプリケーション２０および２０’は、ＵＥまたはゲートウェイと相互作用するアプリケーションを含み得、さらに、他の開示される課金システムおよび方法と併せて使用され得る。Ｍ２Ｍアプリケーション２０および２０’は、限定ではないが、輸送、保健および健康、コネクテッドホーム、エネルギー管理、アセット追跡、ならびにセキュリティおよび監視等の種々の業界でのアプリケーションを含み得る。前述のように、本システムのデバイス、ゲートウェイ、および他のサーバにわたって作動するＭ２Ｍサービス層は、例えば、データ収集、デバイス管理、セキュリティ、課金、場所追跡／ジオフェンシング、デバイス／サービス発見、およびレガシーシステム統合等の機能をサポートし、サービスとしてこれらの機能をＭ２Ｍアプリケーション２０および２０’に提供する。

【0063】

概して、サービス層２２および２２’は、アプリケーションプログラミングインターフェース（ＡＰＩ）および下層ネットワーキングインターフェースのセットを通して付加価値サービス能力をサポートする、ソフトウェアミドルウェア層を定義する。ＥＴＳＩ Ｍ２ＭおよびｏｎｅＭ２Ｍアーキテクチャの両方は、サービス層を定義する。ＥＴＳＩ Ｍ２Ｍのサービス層は、サービス能力層（ＳＣＬ）と称される。ＳＣＬは、Ｍ２Ｍデバイス（デバイスＳＣＬ（ＤＳＣＬ）と称される）、ゲートウェイ（ゲートウェイＳＣＬ（ＧＳＣＬ）と称される）、および／またはネットワークノード（ネットワークＳＣＬ（ＮＳＣＬ）と称される）内で実装され得る。ｏｎｅＭ２Ｍサービス層は、共通サービス機能（ＣＳＦ）（すなわち、サービス能力）のセットをサポートする。１つ以上の特定のタイプのＣＳＦのセットのインスタンス化は、異なるタイプのネットワークノード（例えば、インフラストラクチャノード、中間ノード、特定用途向けノード）上にホストされ得る、共通サービスエンティティ（ＣＳＥ）と称される。第３世代パートナーシッププロジェクト（３ＧＰＰ）はまた、マシンタイプ通信（ＭＴＣ）のためのアーキテクチャも定義している。そのアーキテクチャでは、サービス層、およびそれが提供するサービス能力は、サービス能力サーバ（ＳＣＳ）の一部として実装される。ＥＴＳＩ Ｍ２ＭアーキテクチャのＤＳＣＬ、ＧＳＣＬ、またはＮＳＣＬで具現化されようと、３ＧＰＰ ＭＴＣアーキテクチャのサービス能力サーバ（ＳＣＳ）で具現化されようと、ｏｎｅＭ２ＭアーキテクチャのＣＳＦまたはＣＳＥで具現化されようと、もしくはネットワークのある他の構成要素またはモジュールとして具現化されようと、サービス層は、ネットワーク内の１つ以上の独立型サーバ、コンピュータ、または他のコンピュータデバイスもしくはノード上のいずれかで実行される論理エンティティ（例えば、ソフトウェア、コンピュータ実行可能命令等）として、またはそのようなネットワークの１つ以上の既存のサーバ、コンピュータ、もしくはノードの一部としてのいずれかで実装され得る。実施例として、サービス層またはその構成要素は、以下で説明される図１４Ｃまたは図１４Ｄで図示される一般アーキテクチャを有する、サーバ、コンピュータ、またはデバイス上で作動するソフトウェアの形態において実装され得る。

【0064】

さらに、図１２に示されるユーザインターフェースを生成するための、ＩｏＴイベント管理１２０４、ＩｏＴイベントオブジェクト４００、ＩｏＴイベント定義４０２、制御ハンドラ４０６、通知ハンドラ４０４、および論理エンティティ等、本願の論理エンティティは、本願のサービスにアクセスするために、サービス指向アーキテクチャ（ＳＯＡ）および／またはリソース指向アーキテクチャ（ＲＯＡ）を使用する、Ｍ２Ｍネットワークの一部として実装することができる。

【0065】

図１４Ｃは、Ｍ２Ｍデバイス、ユーザ機器、ゲートウェイ、ＵＥ／ＧＷ、または、例えば、モバイルコアネットワーク、サービス層ネットワークアプリケーションプロバイダ、端末デバイス１８、もしくはＭ２Ｍゲートウェイデバイス１４のノードを含む、任意の他のノードであり得る、例示的デバイス３０の系統図である。デバイス３０は、図１１Ａおよび１１Ｂに示されるユーザインターフェースを生成するために、ＩｏＴイベント管理１２０４、ＩｏＴイベントオブジェクト４００、ＩｏＴイベント定義４０２、制御ハンドラ４０６、通知ハンドラ４０４、および論理エンティティ等の論理エンティティを実行するか、または含むことができる。デバイス３０は、図１４Ａ−Ｂに示されるようなＭ２Ｍネットワークの一部、または非Ｍ２Ｍネットワークの一部であり得る。図１４Ｃに示されるように、デバイス３０は、プロセッサ３２と、送受信機３４と、伝送／受信要素３６と、スピーカ／マイクロホン３８と、キーパッド４０と、ディスプレイ／タッチパッド／インジケータ４２と、非取り外し可能なメモリ４４と、取り外し可能なメモリ４６と、電源４８と、全地球測位システム（ＧＰＳ）チップセット５０と、他の周辺機器５２とを含み得る。デバイス３０は、実施形態と一致したままで、先述の要素の任意の副次的組み合わせを含み得ることが理解されるであろう。本デバイスは、開示されるシステムおよび方法を使用および／または実装する、デバイスであり得る。

【0066】

プロセッサ３２は、汎用プロセッサ、特殊目的プロセッサ、従来のプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアと関連する１つ以上のマイクロプロセッサ、コントローラ、マイクロコントローラ、１つ以上の特定向け集積回路（ＡＳＩＣ）、１つ以上のフィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、任意の他のタイプおよび数の集積回路（ＩＣ）、状態マシン等であり得る。プロセッサ３２は、信号符号化、データ処理、電力制御、入出力処理、および／またはデバイス３０が無線環境内で動作することを可能にする任意の他の機能性を果たし得る。プロセッサ３２は、伝送／受信要素３６に連結され得る、送受信機３４に連結され得る。図１４Ｃは、プロセッサ３２および送受信機３４を別個の構成要素として描写するが、プロセッサ３２および送受信機３４は、電子パッケージまたはチップ内に一緒に統合され得ることが理解されるであろう。プロセッサ３２は、アプリケーション層プログラム（例えば、ブラウザ）および／または無線アクセス層（ＲＡＮ）プログラムおよび／または通信を行い得る。プロセッサ３２は、例えば、アクセス層および／またはアプリケーション層等において、認証、セキュリティキー一致、および／または暗号化動作等のセキュリティ動作を行い得る。

【0067】

伝送／受信要素３６は、信号をＭ２Ｍサービスプラットフォーム２２に伝送し、および／またはそこから信号を受信するように構成され得る。例えば、ある実施形態では、伝送／受信要素３６は、ＲＦ信号を伝送および／または受信するように構成されるアンテナであり得る。伝送／受信要素３６は、ＷＬＡＮ、ＷＰＡＮ、セルラー等の種々のネットワークおよび無線インターフェースをサポートし得る。ある実施形態では、伝送／受信要素３６は、例えば、ＩＲ、ＵＶ、または可視光信号を伝送および／または受信するように構成されるエミッタ／検出器であり得る。さらに別の実施形態では、伝送／受信要素３６は、ＲＦおよび光信号の両方を伝送および受信するように構成され得る。伝送／受信要素３６は、無線または有線信号の任意の組み合わせを伝送および／または受信するように構成され得ることが理解されるであろう。

【0068】

加えて、伝送／受信要素３６は、単一の要素として図１４Ｃに描写されているが、デバイス３０は、任意の数の伝送／受信要素３６を含み得る。より具体的には、デバイス３０は、ＭＩＭＯ技術を採用し得る。したがって、ある実施形態では、デバイス３０は、無線信号を伝送および受信するための２つ以上の伝送／受信要素３６（例えば、複数のアンテナ）を含み得る。

【0069】

送受信機３４は、伝送／受信要素３６によって伝送される信号を変調するように、および伝送／受信要素３６によって受信される信号を復調するように構成され得る。上記のように、デバイス３０は、マルチモード能力を有し得る。したがって、送受信機３４は、デバイス３０が、例えば、ＵＴＲＡおよびＩＥＥＥ８０２．１１等の複数のＲＡＴを介して通信することを可能にするための複数の送受信機を含み得る。

【0070】

プロセッサ３２は、非取り外し可能なメモリ４４および／または取り外し可能なメモリ４６等の任意のタイプの好適なメモリから情報にアクセスし、その中にデータを記憶し得る。非取り外し可能なメモリ４４は、ランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、ハードディスク、または任意の他のタイプのメモリ記憶デバイスを含み得る。取り外し可能なメモリ４６は、加入者識別モジュール（ＳＩＭ）カード、メモリスティック、セキュアデジタル（ＳＤ）メモリカード等を含み得る。他の実施形態では、プロセッサ３２は、サーバまたはホームコンピュータ上等のデバイス３０上に物理的に位置しないメモリから情報にアクセスし、その中にデータを記憶し得る。

【0071】

プロセッサ３０は、電源４８から電力を受け取り得、デバイス３０内の他の構成要素への電力を分配および／または制御するように構成され得る。電源４８は、デバイス３０に給電するための任意の好適なデバイスであり得る。例えば、電源４８は、１つ以上の乾電池バッテリ（例えば、ニッケルカドミウム（ＮｉＣｄ）、ニッケル亜鉛（ＮｉＺｎ）、ニッケル水素（ＮｉＭＨ）、リチウムイオン（Ｌｉ−ｉｏｎ）等）、太陽電池、燃料電池等を含み得る。

【0072】

プロセッサ３２はまた、デバイス３０の現在の場所に関する場所情報（例えば、経度および緯度）を提供するように構成され得る、ＧＰＳチップセット５０に連結され得る。デバイス３０は、実施形態と一致したままで、任意の好適な場所決定方法を介して場所情報を獲得し得ることが理解されるであろう。

【0073】

プロセッサ３２はさらに、追加の特徴、機能性、および／または有線もしくは無線接続を提供する、１つ以上のソフトウェアおよび／またはハードウェアモジュールを含み得る、他の周辺機器５２に連結され得る。例えば、周辺機器５２は、加速度計、ｅ−コンパス、衛星送受信機、センサ、デジタルカメラ（写真またはビデオ用）、ユニバーサルシリアルバス（ＵＳＢ）ポート、振動デバイス、テレビ送受信機、ハンズフリーヘッドセット、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、周波数変調（ＦＭ）無線ユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザ等を含み得る。

【0074】

図１４Ｄは、例えば、図１４Ａおよび１４ＢのＭ２Ｍサービスプラットフォーム２２が実装され得る、例示的なコンピューティングシステム９０のブロック図である。コンピューティングシステム９０は、コンピュータまたはサーバを備え得、主に、ソフトウェアの形態であり得るコンピュータ読み取り可能命令によって制御され得、どこでもまたはどのような手段を用いても、そのようなソフトウェアが記憶またはアクセスされる。コンピューティングシステム９０は、図１１Ａおよび１１Ｂに示されるユーザインターフェースを生成するために、ＩｏＴイベント管理１２０４、ＩｏＴイベントオブジェクト４００、ＩｏＴイベント定義４０２、制御ハンドラ４０６、通知ハンドラ４０４、および論理エンティティ等の論理エンティティを実行するか、または含むことができる。コンピューティングシステム９０は、Ｍ２Ｍデバイス、ユーザ機器、ゲートウェイ、ＵＥ／ＧＷ、または、例えば、モバイルコアネットワーク、サービス層ネットワークアプリケーションプロバイダ、端末デバイス１８、もしくはＭ２Ｍゲートウェイデバイス１４のノードを含む、任意の他のノードであり得る。そのようなコンピュータ読み取り可能命令は、コンピューティングシステム９０を稼働させるように、中央処理装置（ＣＰＵ）９１内で実行され得る。多くの既知のワークステーション、サーバ、およびパーソナルコンピュータでは、中央処理装置９１は、マイクロプロセッサと呼ばれる単一チップＣＰＵによって実装される。他の機械では、中央処理装置９１は、複数のプロセッサを備え得る。コプロセッサ８１は、追加の機能を果たすか、またはＣＰＵ９１を支援する、主要ＣＰＵ９１とは明確に異なる、随意的なプロセッサである。ＣＰＵ９１および／またはコプロセッサ８１は、開示されるシステムの種々の実施形態において使用されるデータを受信、生成、および処理し得る。

【0075】

動作時、ＣＰＵ９１は、命令をフェッチ、復号、および実行し、コンピュータの主要データ転送パスであるシステムバス８０を介して、情報を他のリソースへ、およびそこから転送する。そのようなシステムバスは、コンピューティングシステム９０内の構成要素を接続し、データ交換のための媒体を定義する。システムバス８０は、典型的には、データを送信するためのデータラインと、アドレスを送信するためのアドレスラインと、割り込みを送信するため、およびシステムバスを動作させるための制御ラインとを含む。そのようなシステムバス８０の実施例は、ＰＣＩ（周辺構成要素相互接続）バスである。

【0076】

システムバス８０に連結されるメモリデバイスは、ランダムアクセスメモリ（ＲＡＭ）８２と、読み取り専用メモリ（ＲＯＭ）９３とを含む。そのようなメモリは、情報が記憶され、読み出されることを可能にする回路を含む。ＲＯＭ９３は、概して、容易に修正されることができない記憶されたデータを含む。ＲＡＭ８２内に記憶されたデータは、ＣＰＵ９１または他のハードウェアデバイスによって読み取られるか、または変更され得る。ＲＡＭ８２および／またはＲＯＭ９３へのアクセスは、メモリコントローラ９２によって制御され得る。メモリコントローラ９２は、命令が実行されると、仮想アドレスを物理的アドレスに変換する、アドレス変換機能を提供し得る。メモリコントローラ９２はまた、システム内のプロセスを隔離し、ユーザプロセスからシステムプロセスを隔離する、メモリ保護機能を提供し得る。したがって、第１のモードで作動するプログラムは、その独自のプロセス仮想アドレス空間によってマップされるメモリのみにアクセスすることができ、プロセス間のメモリ共有が設定されていない限り、別のプロセスの仮想アドレス空間内のメモリにアクセスすることはできない。

【0077】

加えて、コンピューティングシステム９０は、ＣＰＵ９１からプリンタ９４、キーボード８４、マウス９５、およびディスクドライブ８５等の周辺機器に命令を伝達する責任がある、周辺機器コントローラ８３を含み得る。

【0078】

ディスプレイコントローラ９６によって制御される、ディスプレイ８６は、コンピューティングシステム９０によって生成される視覚出力を表示するために使用される。そのような視覚出力は、テキスト、グラフィックス、動画グラフィックス、およびビデオを含み得る。ディスプレイ８６は、ＣＲＴベースのビデオディスプレイ、ＬＣＤベースのフラットパネルディスプレイ、ガスプラズマベースのフラットパネルディスプレイ、またはタッチパネルを伴って実装され得る。ディスプレイコントローラ９６は、ディスプレイ８６に送信されるビデオ信号を生成するために要求される、電子構成要素を含む。

【0079】

さらに、コンピューティングシステム９０は、図１４Ａおよび１５Ｂのネットワーク１２等の外部通信ネットワークにコンピューティングシステム９０を接続するために使用され得る、ネットワークアダプタ９７を含み得る。ある実施形態では、ネットワークアダプタ９７は、種々の開示されるシステムおよび方法によって使用されるデータを受信および伝送し得る。

【0080】

本明細書で説明されるシステム、方法、およびプロセスのうちのいずれかまたは全ては、コンピュータ読み取り可能な記憶媒体上に記憶されたコンピュータ実行可能命令（すなわち、プログラムコード）の形態で具現化され得ることが理解される。そのような命令は、コンピュータ、サーバ、Ｍ２Ｍ端末デバイス、Ｍ２Ｍゲートウェイデバイス等の機械によって実行されると、本明細書で説明されるシステム、方法、およびプロセスを行うおよび／または実装する。具体的には、ゲートウェイ、ＵＥ、ＵＥ／ＧＷ、またはモバイルコアネットワーク、サービス層、もしくはネットワークアプリケーションプロバイダのノードのうちのいずれかの動作を含む、前述の説明されるステップ、動作、または機能のうちのいずれかは、そのようなコンピュータ実行可能命令の形態において実装され得る。ＩｏＴイベント管理１２０４、ＩｏＴイベントオブジェクト４００、ＩｏＴイベント定義４０２、制御ハンドラ４０６、通知ハンドラ４０４、ならびに図１１Ａおよび１１Ｂに示されるユーザインターフェースを生成するための論理エンティティ等の論理エンティティは、コンピュータ読み取り可能な記憶媒体に記憶されるコンピュータ実行可能命令の形態において具現化され得る。コンピュータ読み取り可能な記憶媒体は、情報の記憶のための任意の方法または技術で実装される、揮発性および不揮発性、取り外し可能なおよび非取り外し可能な媒体の両方を含むが、そのようなコンピュータ読み取り可能な記憶媒体は、信号を含まない。コンピュータ読み取り可能な記憶媒体は、限定ではないが、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリもしくは他のメモリ技術、ＣＤＲＯＭ、デジタル多用途ディスク（ＤＶＤ）もしくは他の光学ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置もしくは他の磁気記憶デバイス、または所望の情報を記憶するために使用され得、コンピュータによってアクセスされ得る、任意の他の物理的媒体を含む。

【0081】

図に図示されるような本開示の主題の好ましい実施形態を説明する際に、明確にするために、具体的用語が採用される。しかしながら、請求される主題は、そのように選択された具体的用語に限定されることを意図しておらず、各具体的要素は、類似目的を達成するように同様に動作する、全ての技術的均等物を含むことを理解されたい。

【0082】

本明細書は、最良の様態を含む、本発明を開示するために、また、当業者が、任意のデバイスまたはシステムを作製して使用することと、任意の組み込まれた方法を行うこととを含む、本発明を実践することを可能にするために、実施例を使用する。本発明の特許性のある範囲は、請求項によって定義され、当業者に想起される他の実施例を含み得る。そのような他の実施例は、請求項の文字通りの言葉とは異ならない構造要素を有する場合に、または請求項の文字通りの言葉とのごくわずかな差異を伴う同等の構造要素を含む場合に、請求項の範囲内であることを意図している。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11A】

【図11B】

【図12】

【図13】

【図14A】

【図14B】

【図14C】

【図14D】