JP6563439B2 - 意味命名モデル - Google Patents

Description

（関連出願の引用）
本願は、米国仮特許出願第６１／８２３，９７６号（２０１３年５月１６日出願、名称「ＳＥＭＡＮＴＩＣ ＭＯＤＥＬ ＡＮＤ ＮＡＭＩＮＧ ＦＯＲ ＩＮＴＥＲＮＥＴ ＯＦ ＴＨＩＮＧＳ ＳＥＮＳＯＲＹ ＤＡＴＡ」）の利益を主張し、上記出願の内容は、参照により本明細書に引用される。

物理的環境で展開されるネットワーク使用可能デバイスおよびセンサの数の急速な増加が、通信ネットワークを変化させている。次の１０年以内に、何十億ものデバイスが、スマートグリッド、スマートホーム、ｅ−ヘルス、自動車、輸送、物流、および環境監視等の種々の分野で、多くの用途およびサービスプロバイダによるサービスのための無数の実環境データを生成するであろうと予測される。現在の情報ネットワーキング技術への実環境データおよびサービスの統合を可能にする関連技術および解決策は、多くの場合、モノのインターネット（ＩｏＴ）の総称の下で説明される。デバイスによって作成される大量のデータにより、このデータを識別し、問い合わせる効率的な方法の必要性がある。

データの他の記述メタデータへの連携を提供しながら、データの主要な属性（時間、場所、タイプ、および値）を捕捉するデータのために、意味モデルが提示される。データ名公開、データ集計、およびデータクエリのためのプロシージャも説明される。

本概要は、発明を実施するための形態において以下でさらに説明される、簡略化形態の概念の選択を導入するように提供される。本概要は、請求された主題の主要な特徴または不可欠な特徴を識別することを目的としておらず、また、請求された主題の範囲を限定するために使用されることも目的としていない。さらに、請求された主題は、本開示の任意の部分で記述されるいずれかまたは全ての不利点を解決する制限に限定されない。
本発明はさらに、例えば、以下を提供する。
（項目１）
プロセッサと、
前記プロセッサと連結されたメモリと
を備え、
前記メモリは、実行可能命令を備え、前記実行可能命令は、前記プロセッサによって実行されると、
第１の時間属性、第１の場所属性、および第１のタイプ属性を含む第１の属性を伴う第１の感覚データを受信することと、
前記第１の時間属性、前記第１の場所属性、および前記第１のタイプ属性に基づいて、前記感覚データのための第１の名前を作成することと
を含む動作を前記プロセッサに達成させる、デバイス。
（項目２）
前記実行可能命令は、前記第１の名前をサーバに対して公開することを含むさらなる動作を前記プロセッサに達成させ、前記サーバは、前記第１の名前を記憶することにより、前記第１の時間属性、前記第１の場所属性、または前記第１のタイプ属性に基づいて、クエリが前記感覚データについて行われることを可能にする、項目１に記載のデバイス。
（項目３）
前記実行可能命令は、
前記第１の感覚データを第２の感覚データと集計することであって、前記第２の感覚データは、第２の時間属性、第２の場所属性、または第２のタイプ属性を含む第２の属性を有する、ことと、
前記第１の名前を、前記集計された第１の感覚データおよび第２の感覚データに割り当てることと
を含むさらなる動作を前記プロセッサに達成させる、項目１に記載のデバイス。
（項目４）
前記実行可能命令は、ディスプレイ上で前記第１の名前を表示するための命令を提供することを含むさらなる動作を前記プロセッサに達成させる、項目１に記載のデバイス。
（項目５）
前記第１の場所属性は、ジオハッシュタグを含む、項目１に記載のデバイス。
（項目６）
前記第１の名前は、前記第１のタイプのメッセージダイジェストを含む、項目１に記載のデバイス。
（項目７）
前記第１の名前は、前記第１の時間属性のメッセージダイジェストを含む、項目１に記載のデバイス。
（項目８）
前記デバイスは、センサを備えている、項目１に記載のデバイス。
（項目９）
前記第１の名前は、前記デバイスのデバイス識別子を含む、項目１に記載のデバイス。（項目１０）
コンピュータ実行可能命令を備えているコンピュータ読み取り可能な記憶媒体であって、
前記命令は、コンピュータデバイスによって実行されると、
第１の時間属性、第１の場所属性、および第１のタイプ属性を含む第１の属性を伴う第１の感覚データを受信することと、
前記第１の時間属性、前記第１の場所属性、および前記第１のタイプ属性に基づいて、前記感覚データのための第１の名前を作成することと
を含む命令を前記コンピュータデバイスに行わせる、コンピュータ読み取り可能な記憶媒体。
（項目１１）
さらなる命令が、前記第１の名前をサーバに対して公開することを含み、前記サーバは、前記第１の名前を記憶することにより、前記第１の時間属性、前記第１の場所属性、または前記第１のタイプ属性に基づいて、クエリが前記感覚データについて行われることを可能にする、項目１０に記載のコンピュータ読み取り可能な記憶媒体。
（項目１２）
さらなる命令が、
前記第１の感覚データを第２の感覚データと集計することであって、前記第２の感覚データは、第２の時間属性、第２の場所属性、または第２のタイプ属性を含む第２の属性を有する、ことと、
前記第１の名前を、前記集計された第１の感覚データおよび第２の感覚データに割り当てることと
を含む、項目１０に記載のコンピュータ読み取り可能な記憶媒体。
（項目１３）
さらなる命令が、前記第１の名前を表示するための命令を提供することを含む、項目１０に記載のコンピュータ読み取り可能な記憶媒体。
（項目１４）
前記第１の場所属性は、ジオハッシュタグを含む、項目１０に記載のコンピュータ読み取り可能な記憶媒体。
（項目１５）
前記第１の名前は、前記第１のタイプのメッセージダイジェストを含む、項目１０に記載のコンピュータ読み取り可能な記憶媒体。
（項目１６）
前記第１の名前は、前記第１の時間属性のメッセージダイジェストを含む、項目１０に記載のコンピュータ読み取り可能な記憶媒体。
（項目１７）
前記コンピュータデバイスは、センサを備えている、項目１０に記載のコンピュータ読み取り可能な記憶媒体。
（項目１８）
前記第１の名前は、前記デバイスのデバイス識別子を含む、請求香１０に記載のコンピュータ読み取り可能な記憶媒体。
（項目１９）
センサによって、値を伴う感覚データを観察することであって、前記値を伴う前記感覚データは、時間属性、場所属性、およびタイプ属性を含む属性を有する、ことと、
前記センサによって、前記時間属性、前記場所属性、および前記値属性に基づいて、前記感覚データの名前を作成することと、
前記センサによって、前記名前をサーバに対して公開することと
を含む、方法。
（項目２０）
前記サーバは、前記感覚データに対するクエリを受信し、前記クエリは、前記時間属性、前記場所属性、前記値属性、またはタイプ属性を含む、請求香１９に記載の方法。

添付の図面と併せて一例として挙げられる、以下の説明から、より詳細に理解され得る。
図１は、感覚データ属性を図示する。 図２は、マップ上のセンサ場所を図示する。 図３は、組み込み意味命名のための構造を図示する。 図４は、組み込み意味命名のための別の構造を図示する。 図５は、組み込み意味命名のための方法を図示する。 図６は、感覚データ読み出しフローを図示する。 図７は、感覚データクエリフローを図示する。 図８は、感覚データ公開、感知、およびクエリのアーキテクチャを図示する。 図９は、感覚データクエリフローを図示する。 図１０Ａは、１つ以上の開示された実施例が実装され得る、例示的マシンツーマシン（Ｍ２Ｍ）またはモノのインターネット（ＩｏＴ）通信システムの系統図である。 図１０Ｂは、図１０Ａで図示されるＭ２Ｍ／ＩｏＴ通信システム内で使用され得る、例示的アーキテクチャの系統図である。 図１０Ｃは、図１０Ａで図示される通信システム内で使用され得る、例示的Ｍ２Ｍ／ＩｏＴ端末またはゲートウェイデバイスの系統図である。 図１０Ｄは、図１０Ａの通信システムの側面が具現化され得る、例示的コンピュータシステムのブロック図である。

ネットワーク使用可能センサデバイスは、物理的環境から収集される観察および測定データを捕捉して通信することを可能にする。本明細書で議論される場合、センサは、物理的性質を検出または測定し、記録し、示し、またはそれに応答する、デバイスとして定義され得る。例えば、センサは、光、運動、温度、磁場、重力、湿度、湿気、振動、圧力、電場、音、および環境の他の側面を検出し得る。感覚データは、データを有意義にすることに役立つように、環境または測定データの観察、ならびに時間、場所、および他の記述属性を含み得る。例えば、１５度の温度値は、空間（例えば、Ｇｕｉｌｄｆｏｒｄ市中心部）、時間（例えば、２０１３年３月２１日、グリニッジ標準時午前８時１５分）、および単位（例えば、摂氏）属性を用いて記述される場合、より有意義であり得る。感覚データはまた、品質またはデバイス関連属性（例えば、精度、正確度）を記述する、他の詳細なメタデータを含み得る。

かなりの数の既存のネットワーク使用可能センサデバイスおよびセンサネットワークは、リソースが制約される（すなわち、多くの場合、限定された電力、帯域幅、メモリ、および処理リソースを有する）ため、センサはまた、データを集計または要約して通信オーバーロードを低減させるように、ネットワーク内データ処理をサポートすべきである。意味（ｓｅｍａｎｔｉｃ）注釈が、より強力な中間ノード（例えば、ゲートウェイノード）上で行われると見なされる場合、依然として、膨大な量のストリーミングデータがあり得、メタデータのサイズは、元のデータより有意に大きい。そのような場合において、表現力、詳細のレベル、およびメタデータ記述のサイズ間の平衡が考慮されるべきである。意味記述は、感覚データに対してマシン解釈可能かつ相互運用可能なデータを提供し得る。モノのインターネット（ＩｏＴ）感覚データのための本明細書で説明される意味モデルは、依然として軽量でありながら、感覚データの主要な属性を表現し得る。例えば、本明細書で開示される意味命名モデルが、感覚データのいくつかの一次属性を可能にする一方で、属性の数は、ネットワークにわたって伝送される必要がある情報の量を低減させるために制限される。

現在のモノのインターネット（ＩｏＴ）データ命名は、ユニフォームリソース識別子（ＵＲＩ）またはユニフォームリソースロケータ（ＵＲＬ）ベースの方式である従来のコンテンツ命名方式に従う（例えば、ＥＴＳＩマシンツーマシン（Ｍ２Ｍ）リソース識別子）。センサからの感覚データは、ゲートウェイによって名前を付けられ（データがゲートウェイに記憶されるリソース構造から導出され）、これは、データの元のソースがデータの名前を決定しないことを意味する。感覚データの公開および消費のための効率的なエンドツーエンドソリューションを提供すること、および分散型感覚データクエリを可能にする発見機構を提供することにおいて、感覚データのための命名方式の不足がある。

本明細書では、依然として感覚データの他の記述メタデータへの連携を提供しながら、感覚データの主要な属性（例えば、時間、場所、タイプ、および値）を捕捉する組み込みセマンティクス（ｓｅｍａｎｔｉｃｓ）を有する命名方式（組み込み意味（ｓｅｍａｎｔｉｃ）命名）が開示される。意味モデルは、感覚データのための命名方式であり、感覚データを識別するとともに、追加の意味情報を名前に組み込むことができる。命名方式は、感知されたデータに名前をつけることにおいてデータソース（すなわち、センサ）を関与させるが、さらに、センサに追加されるオーバーヘッドおよび複雑性と名前の表現力との間で平衡を保つ。命名方式は、名前の中にデータの追加の意味情報を提供することによって、分散型感覚データ公開および発見を促進する。命名方式は、データ集計を可能にし得、データ集計は、集計を行う方法を命令するためのいかなる追加の情報も伴わずに自動的に行われ得る。命名方式をさらに強化し得る、名前におけるフィールドの形式も開示される。感覚データの名前の公開、感覚データの集計、および感覚データのクエリのためのプロシージャも開示される。

表１に示されるように、感覚データ（または一般にＩｏＴデータ）のためのモデルは、観察および測定値を記述する一方、体積、多様性、変化の速度、時間、および場所依存性を考慮する。考慮されるべきである別の側面は、どのようにしてデータが使用され、問い合わせられるであろうかである。概して、感覚データのクエリは、場所（例えば、場所タグ、緯度および経度の値）、タイプ（例えば、温度、湿度、または光）、時間（例えば、タイムスタンプ、データの鮮度）、値（例えば、観察および測定値、値データタイプ、および測定の単位を含む）、または他のメタデータ（例えば、情報関連属性のソースまたは品質を提供する記述へのリンク等のメタデータへのリンク）等の属性を含む。

図１は、リンクされたデータのアプローチに従う、感覚データモデル１００の意味記述を図示する。このモデルでは、感覚データは、時間属性１０１と、場所属性１０３と、タイプ属性１０５と、値属性１０７と、他のメタデータへのリンク１０９とを含む。感覚データは、一般的に使用されているオントロジーおよび語彙で定義される既存の概念にリンクされ得る。そして、詳細なメタデータおよびソース関連属性が、他のソースへのリンクとして提供され得る。モデル１００は、そのような感覚データを記述するためのスキーマを提供する。

ジオハッシュタギングが、例えば、場所属性を記述するために使用され得る。ジオハッシュは、地理的な場所の１０進緯度および経度値の文字列ハッシュを作成するために、Ｂａｓｅ−Ｎ符号化およびビットインターリービングを使用する機構である。これは、階層構造を使用し、物理的空間をグリッドに分割する。ジオハッシングは、ジオタギングに使用され得る対称技法である。ジオハッシングの特徴は、（いくつかの例外を伴って）近くの場所が、それらの文字列表現において類似プレフィックスを有するであろうことである。実施例では、緯度および経度地理座標の１２バイトハッシュ文字列表現を作成するように、Ｂａｓｅ３２符号化およびビットインターリービングを使用する、ジオハッシングアルゴリズムが採用される。例えば、「５１．２３５４０１」という緯度値および「０．５７４６００」という経度値を有するＧｕｉｌｄｆｏｒｄの場所は、「ｇｃｐｅ６ｚｊｅｆｆｇｐ」として表される。

図２は、マップ１１０上にマークされた大学構内の４つの場所を示す。表２は、マップ１１０上の異なる場所のジオハッシュ場所タグを示す。表２で観察することができるように、非常に近い場所は、類似プレフィックスを有する。プレフィッックスは、場所間の距離が近くなるほど、より類似する。例えば、位置１１１、位置１１２、位置１１３、および位置１１４は、最初の６桁を共有する。位置１１２および位置１１３は、それらの近さにより、最初の８桁を共有する（他の場所と比較して追加の２桁）。感覚データの名前の中のジオハッシュタグは、例えば、文字列類似性方法の使用により、データを問い合わせること、発見することにおいて場所ベースの検索を提供し得る。場所プレフィックスは、データが非常に近い異なる場所から統合または蓄積される場合に、集計プレフィックスを作成するために使用され得る。例えば、全ての感覚データの間で共有される最長プレフィックス文字列が、データのための集計場所プレフィックスタグを表すために使用され得る。

感覚データモデルのタイプ属性に対して、概念が、地球および環境用語（ＳＷＥＥＴ）オントロジーのためのＮＡＳＡのセマンティックウェブから採用され得る。ＳＷＥＥＴは、８つの最上位概念／オントロジー、すなわち、表現、プロセス、現象、領域、状態、事柄、人間の活動、および数量から成る。各々は、次のレベルの概念を有する。それらの全ては、感覚データモデルのタイプ属性に対する値であり得る。種々の実施例では、タイプ属性は、共通語彙に基づく既存の概念にリンクされ得る。別の実施例では、感覚データのタイプを記述するためのより具体的なオントロジーが採用され得る。

上記のように、図１に示される属性は、感覚データのためのセマンティクスモデル１００を形成する。ソース関連データ（すなわち、どのようにしてデータが測定されるか、特定のデバイスの使用、または情報の質）等の追加の特徴が、プロバイダデバイス自体、ゲートウェイ等の他のソース上で利用可能な情報にリンクされ得るように、モジュール形式で追加され得る。図１は、他のメタデータ属性１０９へのリンクを示す。例えば、情報属性の質または測定範囲性質等を記述するために、新しい意味記述モジュールが追加されることができ、それは、コア記述にリンクされることができる。追加の特徴の追加は、組み込み意味命名を使用してストリーミングセンサデータを記述するための融通性のあるソリューションを提供し、モデルがデータのコア属性を捕捉し、追加の情報がリンクされたデータとして提供され得る。

本発明の側面によると、感覚データは、場所、時間（ストリームに対して、これは、ストリームの現在のウィンドウ内の測定の開始時間であり得る）、およびタイプ等の図１の意味モデル１００の属性を含む情報を使用して、名前を付けられ得る。図３に示されるように、例えば、感覚データの識別（ＩＤ）（すなわち、組み込み意味名）１２４を表すように、文字列が作成され得る。図３は、一実施例による、例示的なＩＤ構造１２０を図示する。ＩＤ構造１２０は、場所情報のジオハッシュタグ１２１を含む場所フィールド１２１と、タイプ情報（例えば、温度、湿度、または光）のメッセージダイジェストアルゴリズム５（ＭＤ５）を含むタイプフィールド１２２と、時間情報のＭＤ５を含む時間フィールド１２３とを備え得る。ＭＤ５は、暗号ハッシュ関数である。場所フィールド１２１、タイプフィールド１２２、および時間フィールド１２３の中の値は、感覚データの名前として使用されるＩＤ１２４を作成するように組み立てられ得る。本実施例では、ＩＤ１２４は、リソース記述フレームワーク（ＲＤＦ）の文脈で使用される。ＲＤＦは、ウェブ上のリソースを記述するためのフレームワークである。

同一のタイプの複数のセンサが、多くの場合、重複した感覚示度値を取得して、信頼性のレベル（例えば、デバイス故障）、測定の一貫性等を達成するように、同一の場所で展開される。本明細書で議論される意味モデルは、同一のタイプの複数のセンサが同一の場所にあり、同時に感覚データを提供する場合、感覚データに名前を付けることの問題に対処する。実施例では、デバイス識別子が、図４に示されるように、感覚データの組み込み意味命名とともに使用され得る。図４は、図３に類似するが、ＤｅｖｉｃｅＩＤフィールド１２６がＩＤ構造１２８の中に追加される。このフィールドは、組み込み意味名のための形式として使用される。ＤｅｖｉｃｅＩＤフィールド１２６で使用されるデバイス識別子は、バーコードまたはＲＦＩＤタグ、ＭＡＣアドレス、移動電話加入者ＩＳＤＮ番号（ＭＳＩＳＤＮ）等であり得る。図４のＤｅｖｉｃｅＩＤフィールド１２６（または任意の他のフィールド）の長さは、デバイス識別子を収容するために任意のバイト数（例えば、１２バイト）に設定され得る。ＩＤ構造１２０およびＩＤ構造１２８は、本明細書で議論される属性を反映する感覚データの組み込み意味名を作成する方法である。

図５は、感覚データの組み込み意味命名のための例示的な方法１３０を図示する。ステップ１３１では、感覚データがセンサによって感知された時間が決定される。ステップ１３３では、感覚データのタイプが決定される。タイプは、感覚データのソースに依存する。例えば、温度を感知するセンサから生じたデータは、温度タイプを有し得、湿度を感知するセンサから生じたデータは、湿度タイプを有し得る。ステップ１３５では、感覚データを生成するセンサの場所のジオハッシュタグが決定される。ステップ１３７では、感覚データのタイプ、センサの場所のジオハッシュタグ、および感覚データが感知された時間に基づいて、感覚データの組み込み意味名が構築される。例えば、組み込み意味名は、図３に関して議論されるような例示的構造に従って構築され得る。図４でさらに図示されるように、別の実施例では、組み込み意味名はまた、感覚データのタイプ、センサの場所のジオハッシュタグ、および感覚データが感知された時間とともに、センサのデバイス識別子を含み得る。実施例では、感覚データの名前は、そのソース（例えば、センサ）によって生成され得る。ブロック１３９では、構築された名前が他のコンピュータデバイスに公開され得る。例えば、センサは、関連感覚データとともに、または関連感覚データとは別に、組み込み意味名をゲートウェイに提供し得る。実施例では、名前作成は、ゲートウェイによって、または専門の命名サーバによって行われ得る。

方法１３０に関して、リソース制約されたデバイスに対して、センサによって感覚データの名前を構築することは、比較的有意な量の電力および他のリソースを消費し得る。加えて、センサが感覚データの名前をゲートウェイに公開する場合、公開は、有意な量のネットワーク帯域幅を消費し、名前を転送する際に有意なオーバーヘッドを中間ノードに課し得る。これは特に、中間ノードがリソース制約されたデバイスでもあるときに問題であり得る。いくつかの実施例では、中間ノードは、発信元からゲートウェイへ感覚データを転送する、中継ノードであり得る。例えば、センサネットワーク内で、中間ノードは、発信元センサとゲートウェイとの間のセンサであり得る。

図６は、感覚データに名前を付け、データを公開するための例示的なフロー１４０を図示する。ステップ１４３では、デバイス登録要求がセンサ１４１からゲートウェイ１４２へ送信され得る。登録要求において、センサ１４１は、例えば、その場所、デバイス識別子、およびそのサポートされたタイプをゲートウェイ１４２に知らせ得る。場所は、ジオハッシュ、経度および緯度、都市の場所、特定の物理的アドレス等の形態であり得る。場所情報がジオハッシュの形態ではない場合、ゲートウェイ１４２は、受信した場所をジオハッシュタグの形式（または別の所望の場所形式）に変換することに関与し得る。センサ１４１は、１つの場所から別の場所へ移動し得、かつ場所の変化を示すためにゲートウェイ１４２に再登録し得る。センサ１４１による場所の変化の登録は、設定された時間に、設定された期間に（例えば、１０秒の時間間隔で）、または特定の所定場所に到達したときに起こり得、これは、場所を頻繁に変更するデバイスにとって好ましくあり得る。ゲートウェイ１４２によってＭＤ５形式で記憶され得る、センサ１４１が行う感知のタイプもまた、ステップ１４３での登録要求に含まれ得る。センサ１４１は、１つより多くのタイプの感知（例えば、温度および湿度）をサポートし得る。ゲートウェイ１４２は、ラベルをセンサ１４１によって行われる各タイプの感知に割り当て得る（例えば、温度が１というラベルを有する一方で、湿度は２というラベルを有する）。

ステップ１４４では、ゲートウェイ１４２が、センサ１４１から受信されるであろう感覚データのストリームを記憶するためのエントリーを構築する。表３は、受信され、ステップ１４４でゲートウェイによって構築されるセンサエントリーに記憶され得る、あるセンサ情報の実施例を示す。示されるように、本実施例では、センサ情報は、とりわけ、センサのデバイス識別子、センサの場所、およびセンサがサポートする感知のタイプを含み得る。ステップ１４５では、ゲートウェイ１４２が、デバイス登録に応答したメッセージをセンサ１４１に送信し、メッセージは、センサ１４１によってサポートされる１つより多くのタイプがある場合、タイプのラベルを含む。タイプラベル（例えば、表３内の１または２）は、公開されるデータのタイプを示す。タイプの対応するＭＤ５が、デバイス情報から読み出される。ステップ１４６では、センサ１４１が、感覚データ値（例えば、温度）、感覚データが感知された時（例えば、正午）、センサの場所（例えば、経度および緯度）、センサのデバイス識別子（例えば、ＭＡＣアドレス）、およびタイプラベル（例えば、１）を含み得る、感覚データをゲートウェイ１４２に公開する。ステップ１４７では、ゲートウェイ１４２が、図１、図３、および図４で図示され、上記で説明される、例示的命名技法／構造および感覚データモデルに従って、公開されたデータの組み込み意味名を生成することができる。

議論されるように、本明細書で開示される感覚データモデルおよび命名プロシージャを用いると、場所、ソース、タイプ、および時間等の感覚データのセマンティクスが、その名前に組み込まれ得る。したがって、ゲートウェイが感覚データの名前を他のエンティティ（例えば、別のゲートウェイまたはサーバ）に公開すると、名前に組み込まれたデータのセマンティクスは、元のデータ公開元（例えば、ゲートウェイ１４２）から読み出される必要がない。

図７は、アプリケーション１５４が感覚データを読み出し、次いで、関連セマンティクスを受信する、感覚データクエリフローを図示する。ステップ１５５では、センサ１５１が（例えば、図６に関して本明細書で議論されるように）感覚データを公開する。ステップ１５６では、ゲートウェイ１５２が、感覚データの組み込み意味名をサーバ１５３に送信する。ステップ１５７では、アプリケーション１５４が、データを要求するメッセージをサーバ１５３に送信する。ステップ１５９では、サーバ１５３が、センサ１５１によって感知される感覚データの値を読み出すために、要求をゲートウェイ１５２に転送する。ステップ１６０では、ゲートウェイ１５２が、感覚データの値をアプリケーション１５４に転送するサーバ１５３に感覚データの値を提供する。１６１で受信される感覚データが、アプリケーション１５４が所望する属性と対応する組み込み意味命名を有する場合には、さらなるセマンティクス情報が必要とされない。しかし、アプリケーション１５４が、感覚データを理解して使用するために、組み込み意味命名によって提供されない、さらなる情報を必要とする場合、アプリケーション１５４は、感覚データのセマンティクスを要求し得る。随意的なステップ１６２では、アプリケーション１５４が、要求される感覚データのセマンティクス（例えば、場所、タイプ、時間、およびソース）を要求する。ステップ１６４では、サーバ１５３が、感覚データのセマンティクスを転送する。実装に基づいて、アプリケーションは、サーバ１５３、ゲートウェイ１５２、センサ１５１、または別のデバイスからセマンティクス情報を読み出し得る。本明細書で議論されるように、セマンティクス情報は、どのようにして異なる形式のデータを解釈するかに関してアプリケーションを支援し得る。

本願の別の側面によると、感覚データの組み込みセマンティクスを用いた、開示された命名方式は、データ集計を促進する。具体的には、データ集計は、どのようにして集計を行うかを命令するためにいかなる追加の情報も伴わずに、上記で説明される様式で、感覚データのために作成される名前の中のフィールド（例えば、センサの場所、タイプ、または時間）を使用することによって、自動的に行うことができる。集計は、データ生成側（例えば、センサ）で、データ生成側とデータ収集側との間の同一のジオハッシュ場所を伴う中間ノード、およびデータ収集側（例えば、ゲートウェイ）で起こり得る。センサの属性（例えば、場所、デバイス識別子、およびサポートされたタイプ）は、頻繁に変化しないこともある。センサにおけるデータ集計は、有意な期間（例えば、数分、数時間、数日、または数ヶ月）にわたって行われ得、これは、センサが、感知する度に感覚データを公開する必要がないこともあることを意味する。センサは、ある期間にわたって感知されるデータを集計し得る（例えば、３０分の期間で全ての感覚データという平均）。この場合、集計されたデータの意味名に組み込まれる時間属性は、集計されたデータの期間であり得る。

感覚データの組み込みセマンティクスを用いた、開示された命名方式はまた、感覚データのクラスタリングを促進するために使用され得る。Ｋ平均法（ベクトル量子化の方法）等のクラスタリング機構が、感覚データを異なるレポジトリにクラスタ化するために使用され得る。クラスタリングモデルに基づく予測方法の使用は、データの各部分を維持するレポジトリの識別を可能にし得る。例えば、各レポジトリは、場所、デバイス、タイプ、または時間等の感覚データの１つのタイプのクラスタリングを維持し得る。

データ集計を促進するために、開示された意味命名方式をどのようにして使用することができるかという概念をさらに例証するため、ならびに記憶された感覚データの発見およびクエリをどのようにして行うことができるかを例証するために、図８は、本明細書で説明される感覚データに名前を付けるための意味モデルを実装する、システム１７０の一実施例のブロック図を提供する。図８では、場所１７５は、センサ１７１、センサ１７２、およびセンサ１７３を含む、複数の通信可能に接続されたセンサを含む。センサ１７２およびセンサ１７３は、センサ１７１とゲートウェイ１７４との間の中間ノードである。ゲートウェイ１７４は、ネットワーク１７６を介して、領域１７５および発見サーバ１７８に通信可能に接続される。

ゲートウェイ１７４（または別のコンピュータデバイス）は、センサ１７１、センサ１７２、およびセンサ１７３からの感覚データの収集側として、感覚データを集計し、名前の中の異なるフィールド（例えば、場所、デバイス識別子、タイプ等）にわたって集計されたデータの意味名を統合し得る。ゲートウェイ１７４または別のコンピュータデバイスは、感覚データを集計するための規則またはポリシーを事前に定義し得る。例えば、ゲートウェイ１７２は、Ｍａｎｈａｔｔａｎ、Ｂｒｏｏｋｌｙｎ、およびＱｕｅｅｎｓにおけるセンサ示度値を平均化するポリシーを有し得る。Ｍａｎｈａｔｔａｎ、Ｂｒｏｏｋｌｙｎ、およびＱｕｅｅｎｓの平均感覚示度値は、「Ｎｅｗ Ｙｏｒｋ Ｃｉｔｙ」という場所識別子、またはいくつかのセンサジオハッシュの最初のいくつかの共通文字（例えば、「ｇｐｃｅｄ」）を有する単一の代表的ジオハッシュを有し得る。別の実施例では、１０月、１１月、および１２月の示度値が平均化され、冬の単一の代表的時間識別子を有し得る。

実施例では、センサ１７１、センサ１７２、およびセンサ１７３は、温度タイプをサポートし得る。センサ１７１は、特定の時間「ｔ１」に、意味命名を伴う感覚データのゲートウェイ１７４に対する公開を開始し得る。センサ１７２は、センサ１７１と同一のジオハッシュ場所を有する（センサ１７１（例えば、最初のデータ生成側）とゲートウェイ１７４（例えば、データ収集側）との間の中間ノードである）。センサ１７２は、受信した感覚データを、場所１７５に位置するデバイスに対する（時間ｔ１またはその付近でセンサ１７２によって感知される）感知された感覚データと集計し得る。この感覚データの集計は、センサ１７２が、ゲートウェイ１７４に向かうことになっている、前のホップ（例えば、センサ１７１）から感覚データを受信するときにトリガされ得る。集計された感覚データは、意味名において、センサ１７１によって公開される、最初に公開された感覚データと同一のデバイス識別子（例えば、ＤｅｖｉｃｅＩＤフィールド１２６で使用される識別子）を割り当てられ得る。別の実施例では、デバイス識別子は、感覚データ集計を行った、または感覚データを転送した最後のセンサ（中間ノード）のみを反映し得る。別の実施例では、デバイス識別子は、感覚データ集計に参加した、または感覚データを転送したセンサの識別子の組み合わせを反映し得る。さらに別の実施例では、異なるセンサからの複数の感覚データが、同一値、類似値、平均値等を有し得るため、異なるセンサからの複数の感覚データは、１つの一意の命名を伴う１つのデータとして扱われ得る。

再度、図８を参照すると、ゲートウェイ１７４は、元の感覚データとともに、集計された感覚データを、発見機能性を有する発見サーバ１７８に公開し得る。集計されたデータは、低レベルコンテキスト情報として、生成され、ゲートウェイ１７４に記憶され得、それは、アプリケーションによって問い合わせられ、高レベルコンテキスト情報を導出するために使用され得る。感覚データのクエリは、いくつかの属性から、また、いくつかのソースからの情報を組み合わせ得る。感覚データのストリームからの可能なクエリのタイプは、厳密クエリ、近似クエリ、範囲クエリ、または複合クエリとして識別され得る。厳密クエリは、タイプ、場所、または時間属性等の既知のデータ属性を要求することを伴う。情報の質（ＱｏＩ）または測定の単位等の他のメタデータ属性もまた、厳密クエリに含まれ得る。近接クエリは、近似場所からの、または情報の質の閾値を伴うデータを要求することを伴う。範囲クエリは、データに問い合わせを行うために使用される時間範囲または場所範囲を要求することを伴う。複合クエリは、そのデータソースとして別のクエリを使用する、クエリである。複合クエリは、異なるソースからの、時として、異なるタイプを伴うデータの統合（および処理）によって提供されているクエリの結果を伴い得る。どのようにしてデータを統合または集計するかについての規則または方針が、複合クエリとともに提供され得る。例えば、データは、３月１日および２日の週末の間に感知される、タイプ温度および湿度を伴うＣｉｔｙＸの場所に基づいて、問い合わせられ得る。

本明細書で開示される組み込み意味命名方式は、これらの種類のクエリが行われ、処理されることを可能にする。クエリは、感覚データの組み込み意味名の中のフィールドのうちの１つにマップされ得る。実施例では、範囲クエリに対して、時間または場所範囲ベースのクエリに対する応答は、発見サーバ１７８が感覚データ名の中の時間および場所フィールドにクエリを直接マップすることを反映し得る。別の実施例では、複合クエリに対して、ソースおよびタイプベースのクエリに対する応答は、発見サーバ１７８が逆規則／ポリシーを直接適用し、それらを感覚データ名の中の場所、タイプ、時間、およびソースフィールドにマップすることを反映し得る。別の実施例では、近接クエリに対して、クエリは、場所を近似するために、感覚データ名の中のジオハッシュの初期プレフィックスを使用し得る。近接クエリに対する応答は、ジオハッシュフィールドへのジオハッシュのプレフィックスのマッピングに基づき得る。

図８に示されるように、時間１８０、場所１８１、タイプ１８２、またはソース１８３（例えば、デバイス識別子）が、発見サーバ１７８によって処理されるクエリの発見識別子（発見ＩＤ）１７９を作成するために入力され得る。本実施例では、意味名と比較される発見ＩＤ１７９を入力することによって、感覚データが見出され得る。本質的に、発見ＩＤ１７９は、クエリのパラメータ（例えば、時間、場所、タイプ、またはソース）を反映するという点で、クエリである。発見サーバ１７８は、独立型コンピュータデバイス、またはゲートウェイ１７４あるいは別のサーバ内に常駐する論理エンティティであり得る。厳密クエリに対して、発見ＩＤ１７９は、時間１８０、場所１８１、タイプ１８２、またはソース１８３であり得る。近接クエリに対して、発見ＩＤ１７９は、ジオハッシュのあるプレフィックスであり得る。範囲クエリに対して、発見ＩＤ１７９は、場所範囲または時間範囲から成り得る。複合クエリに対して、発見ＩＤ１７９は、指定ポリシーを伴う時間１８０、場所１８１、タイプ１８２、またはソース１８３から成り得る。

感覚データの組み込み意味名公開、集計、およびクエリのための開示されたプロシージャは、とりわけ、ハイパーテキスト転送プロトコル（ＨＴＴＰ）または制約アプリケーションプロトコル（ＣｏＡＰ）等の１つ以上の既存のプロトコルに結合され得る。そうするために、ＨＴＴＰまたはＣｏＡＰ等のプロコルは、要求および応答を搬送するための下層転送プロトコルとして使用され得る。要求および応答は、ＨＴＴＰ／ＣｏＡＰメッセージのペイロードに封入され得、または代替として、要求および応答内のある情報は、ＨＴＴＰ／ＣｏＡＰヘッダおよび／またはオプション内のフィールドに結合され得る。実施例では、組み込み意味名公開、データ集計、およびデータクエリ要求および応答プロトコルプリミティブは、ＨＴＴＰまたはＣｏＡＰ要求および応答のペイロードで搬送される、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔオブジェクト表記（ＪＳＯＮ）または拡張マークアップ言語（ＸＭＬ）記述として符号化され得る。本明細書で開示される実施例はまた、先進メッセージ待ち行列プロトコル（ＡＭＱＰ）またはメッセージ待ち行列テレメトリトランスポート（ＭＱＴＴ）を伴い得る。

図９は、上で開示される技法および機構による、感覚データクエリフロー２００の一実施例を図示する。図９のフロー２００は、要求および応答がＨＴＴＰプロトコルに従って搬送される、データクエリを図示する。図９を参照すると、ゲートウェイ２０３は、センサ２０１等のセンサによって感知されるデータを収集する。ステップ２１０では、ゲートウェイ２０３が、ＨＴＴＰ ＰＯＳＴ要求メッセージを発見サーバ２０５に送信する。ステップ２１０でのＨＴＴＰ ＰＯＳＴ要求メッセージは、本明細書で説明される意味命名方式が適用されている、感覚データのペイロードを含む。ＰＯＳＴは、ＨＴＴＰプロトコルによってサポートされる方法であり、ウェブサーバが記憶するために要求メッセージの本体に封入されるデータを受け入れることを要求するように設計されている。

ステップ２１４では、発見サーバ２０５が、場所、タイプ、時間、またはソースの属性に基づいて、任意の受信した感覚データのインデックスを作成し得、例えば、感覚データの各項目の意味名から読み出し、これは、感覚データの発見およびクエリを促進する。発見サーバ２０５によって受信される感覚データは、本明細書で説明されるように、公開された元の感覚データおよび／またはゲートウェイ２０３からの公開された集計データであり得る。発見サーバ２０５はさらに、過去のクエリ要求または結果からの予測に基づいて、データを集計し得る。ステップ２１６では、ＨＴＴＰ ＧＥＴ要求メッセージが、クライアントデバイス２０７（例えば、ユーザ機器）によって発見サーバ２０５に送信され得る。ＧＥＴは、ＨＴＴＰプロトコルによってサポートされる方法であり、特定リソースからデータを要求するために設計されている。ステップ２１６で送信されるＨＴＴＰ ＧＥＴ要求メッセージは、場所、タイプ、時間、またはソースパラメータから成る発見ＩＤを伴う発見要求を備え得る。ステップ２１８では、発見サーバ２０５が、発見ＩＤの中のフィールドを記憶された感覚データの組み込み意味名のフィールドと比較することによって、ステップ２１６で受信される発見ＩＤを感覚データと照合する。発見サーバ２０５は、感覚データ意味名フィールドの中の特定のフィールド（バイト）を見る。発見サーバ２０５は、クエリが既存のフィールドに合致する場合、感覚データの追加のセマンティクス情報を必要としないこともある。合致する感覚データを見出すことにおける発見サーバ２０５のオーバーヘッド（例えば、必要とされる処理）は、組み込み意味命名により、有意に少なくあり得る。ステップ２２０では、ＨＴＴＰ ＧＥＴ応答メッセージが、要求クライアントデバイス２０７に送信される。ＨＴＴＰ ＧＥＴ応答メッセージのペイロードは、ステップ２１６での要求に対応する、合致する感覚データ名を有する。

ステップ２２２では、クライアントデバイス２０７が、将来の使用のために感覚データ名の発見結果を記憶する。ステップ２２４では、クライアントデバイス２０７が、記憶された感覚データ名に合致する、データを読み出すことを決定し得る。ステップ２２６では、クライアントデバイスが読み出すことを希望する感覚データの名前を含むペイロードとともに、ＨＴＴＰ ＧＥＴ要求メッセージが、センサ２０１またはゲートウェイ２０３に送信され得る。いずれにしても、ステップ２２８では、ゲートウェイ２０３は、要求された感覚データがゲートウェイ２０３上に記憶されるかどうかを決定し得る。ステップ２２６で送信されるＨＴＴＰ ＧＥＴ要求は、ゲートウェイ２０３によって途中で捕獲され得、ゲートウェイ２０３は、組み込み意味名のみの代わりに、センサ２０１が合致するデータ値を公開したかどうかを決定するためにチェックし得る。ゲートウェイ２０３が合致するデータ値を有する場合、ゲートウェイ２０３は、ステップ２３０で、適切な感覚データ値を含むＨＴＴＰ ＧＥＴ応答メッセージで返信し得る。ゲートウェイ２０３は、要求された感覚データが任意の他のクライアントによって以前に読み出されていた場合、要求された感覚データ値のキャッシュされたコピーを保持し得る。実施例では、ゲートウェイ２０３が公開されたデータ値のコピーを有さないとき、ステップ２３２で、ゲートウェイ２０３は、ステップ２２６で送信されるＨＴＴＰ ＧＥＴ要求をセンサ２０１に転送し得る。ステップ２３４では、センサ２０１が、最初にステップ２２６で送信されたＨＴＴＰ ＧＥＴ要求に応答するように送信されるＨＴＴＰ ＧＥＴ応答で、応答し得る。

図１０Ａは、１つ以上の開示された実施例が実装され得る、例示的マシンツーマシン（Ｍ２Ｍ）またはモノのインターネット（ＩｏＴ）通信システム１０の略図である。概して、Ｍ２Ｍ技術は、ＩｏＴのための構成要素を提供し、任意のＭ２Ｍデバイス、ゲートウェイ、またはサービスプラットフォームは、ＩｏＴの構成要素ならびにＩｏＴサービス層等であり得る。

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

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

図示したＭ２Ｍサービスプラットフォーム２２は、Ｍ２Ｍアプリケーション２０、Ｍ２Ｍゲートウェイデバイス１４、Ｍ２Ｍ端末デバイス１８、および通信ネットワーク１２のためのサービスを提供する。Ｍ２Ｍサービスプラットフォーム２２は、所望に応じて、任意の数のＭ２Ｍアプリケーション、Ｍ２Ｍゲートウェイデバイス１４、Ｍ２Ｍ端末デバイス１８、および通信ネットワーク１２と通信し得ることが理解されるであろう。Ｍ２Ｍサービスプラットフォーム２２は、１つ以上のサーバ、コンピュータ等によって実装され得る。Ｍ２Ｍサービスプラットフォーム２２は、Ｍ２Ｍ端末デバイス１８およびＭ２Ｍゲートウェイデバイス１４の管理および監視等のサービスを提供する。Ｍ２Ｍサービスプラットフォーム２２はまた、データを収集し、異なるタイプのＭ２Ｍアプリケーション２０と適合性があるようにデータを変換し得る。Ｍ２Ｍサービスプラットフォーム２２の機能は、例えば、ウェブサーバとして、セルラーコアネットワークで、クラウドで等、種々の方法で実装され得る。

図１０Ｂも参照すると、Ｍ２Ｍサービスプラットフォームは、典型的には、多様なアプリケーションおよび垂直線が活用することができる、サービス配信能力のコアセットを提供する、サービス層２６（例えば、ネットワークサービス能力層（ＮＳＣＬ））を実装する。これらのサービス能力は、Ｍ２Ｍアプリケーション２０がデバイスと相互作用し、データ収集、データ分析、デバイス管理、セキュリティ、課金、サービス／デバイス発見等の機能を果たすことを可能にする。本質的に、これらのサービス能力は、これらの機能性を実装する負担をアプリケーションから取り除き、したがって、アプリケーション開発を単純化し、市場に出す費用および時間を削減する。サービス層２６はまた、Ｍ２Ｍアプリケーション２０が、サービス層２６が提供するサービスと関連して、種々のネットワーク１２を通して通信することも可能にする。

いくつかの実施例では、Ｍ２Ｍアプリケーション２０は、本明細書で議論されるように、組み込み意味命名を伴う感覚データを読み出して通信する、所望のアプリケーションを含み得る。Ｍ２Ｍアプリケーション２０は、限定ではないが、輸送、保健および健康、コネクテッドホーム、エネルギー管理、アセット追跡、ならびにセキュリティおよび監視等の種々の業界でのアプリケーションを含み得る。上記のように、本システムのデバイス、ゲートウェイ、および他のサーバにわたって作動するＭ２Ｍサービス層は、例えば、データ収集、デバイス管理、セキュリティ、課金、場所追跡／ジオフェンシング、デバイス／サービス発見、およびレガシーシステム統合等の機能をサポートし、サービス等のこれらの機能をＭ２Ｍアプリケーション２０に提供する。

図１０Ｃは、例えば、Ｍ２Ｍ端末デバイス１８またはＭ２Ｍゲートウェイデバイス１４等の例示的Ｍ２Ｍデバイス３０の系統図である。図１０Ｃに示されるように、Ｍ２Ｍデバイス３０は、プロセッサ３２と、送受信機３４と、伝送／受信要素３６と、スピーカ／マイクロホン３８と、キーパッド４０と、ディスプレイ／タッチパッド４２と、非取り外し可能メモリ４４と、取り外し可能メモリ４６と、電源４８と、全地球測位システム（ＧＰＳ）チップセット５０と、他の周辺機器５２とを含み得る。Ｍ２Ｍデバイス４０は、実施例と一致したままで、先述の要素の任意の副次的組み合わせを含み得ることが理解されるであろう。このデバイスは、感覚データの組み込み意味命名のための開示されたシステムおよび方法を使用する、デバイスであり得る。

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

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

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

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

プロセッサ３２は、非取り外し可能メモリ４４および／または取り外し可能メモリ４６等の任意のタイプの好適なメモリから情報にアクセスし、そこにデータを記憶し得る。非取り外し可能メモリ４４は、ランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、ハードディスク、または任意の他のタイプのメモリ記憶デバイスを含み得る。取り外し可能メモリ４６は、加入者識別モジュール（ＳＩＭ）カード、メモリスティック、セキュアデジタル（ＳＤ）メモリカード等を含み得る。他の実施例では、プロセッサ３２は、サーバまたはホームコンピュータ上等のＭ２Ｍデバイス３０上に物理的に位置しないメモリから情報にアクセスし、そこにデータを記憶し得る。プロセッサ３２は、感覚データの組み込み意味命名に応答して、ディスプレイまたはインジケータ４２上の照明パターン、画像、テキスト、または色を制御するように構成され得る。本明細書で説明される実施例は、成功しているか、または成功していないか、あるいは別様に組み込み意味命名を伴うプロセスステップの状態を示す。

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

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

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

図１０Ｄは、例えば、図１０Ａおよび１０ＢのＭ２Ｍサービスプラットフォーム２２が実装され得る、例示的なコンピュータシステム９０のブロック図である。コンピュータシステム９０は、コンピュータまたはサーバを備え得、主に、ソフトウェアの形態であり得るコンピュータ読み取り可能な命令によって制御され得、どこでも、またはどのような手段を用いても、そのようなソフトウェアが記憶あるいはアクセスされる。そのようなコンピュータ読み取り可能な命令は、コンピュータシステム９０を稼働させるように、中央処理装置（ＣＰＵ）９１内で実行され得る。多くの既知のワークステーション、サーバ、および周辺コンピュータでは、中央処理装置９１は、マイクロプロセッサと呼ばれる単一チップＣＰＵによって実装される。他の機械では、中央処理装置９１は、複数のプロセッサを備え得る。コプロセッサ８１は、追加の機能を果たすか、またはＣＰＵ９１を支援する、主要ＣＰＵ９１とは明確に異なる、随意的なプロセッサである。ＣＰＵ９１および／またはコプロセッサ８１は、組み込み意味名を伴う感覚データのクエリ等の組み込み意味命名のための開示されたシステムおよび方法に関係付けられるデータを受信、生成、および処理し得る。

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

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

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

ディスプレイコントローラ９６によって制御されるディスプレイ８６は、コンピュータシステム９０によって生成される視覚出力を表示するために使用される。そのような視覚出力は、テキスト、グラフィックス、動画グラフィックス、およびビデオを含み得る。ディスプレイ８６は、ＣＲＴベースのビデオディスプレイ、ＬＣＤベースのフラットパネルディスプレイ、ガスプラズマベースのフラットパネルディスプレイ、またはタッチパネルを伴って実装され得る。ディスプレイコントローラ９６は、ディスプレイ８６に送信されるビデオ信号を生成するために必要とされる、電子構成要素を含む。ディスプレイ８６は、組み込み意味名を使用して、ファイルまたはフォルダの中の感覚データを表示し得る。例えば、図３、図４等に示される形式でのフォルダの名前である。

さらに、コンピュータシステム９０は、図１０Ａおよび１０Ｂのネットワーク１２等の外部通信ネットワークにコンピュータシステム９０を接続するために使用され得る、ネットワークアダプタ９７を含み得る。

本明細書で説明されるシステム、方法、およびプロセスのうちのいずれかまたは全ては、命令が、コンピュータ、サーバ、Ｍ２Ｍ端末デバイス、Ｍ２Ｍゲートウェイデバイス等の機械によって実行されると、本明細書で説明されるシステム、方法、およびプロセスを行うおよび／または実装される、コンピュータ読み取り可能な記憶媒体上に記憶されたコンピュータ実行可能命令（すなわち、プログラムコード）の形態で具現化され得ることが理解される。具体的には、上記で説明されるステップ、動作、または機能のうちのいずれかは、そのようなコンピュータ実行可能命令の形態で実装され得る。コンピュータ読み取り可能な記憶媒体は、情報の記憶のための任意の方法または技術で実装される、揮発性および不揮発性、取り外し可能および非取り外し可能媒体の両方を含むが、そのようなコンピュータ読み取り可能な記憶媒体は、信号を含まない。コンピュータ読み取り可能な記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたは他のメモリ技術、ＣＤＲＯＭ、デジタル多用途ディスク（ＤＶＤ）または他の光学ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置または他の磁気記憶デバイス、あるいは所望の情報を記憶するために使用することができ、コンピュータによってアクセスすることができる任意の他の物理的媒体を含むが、それらに限定されない。

図で図示されるような本開示の主題の好ましい実施例を説明する際に、明確にするために、特定の用語が採用される。しかしながら、請求された主題は、そのように選択された特定の用語に限定されることを目的としておらず、各特定の要素は、類似目的を達成するように同様に動作する、全ての技術的均等物を含むことを理解されたい。例えば、感覚データのための組み込み意味命名が開示されているが、本明細書の方法のシステムは、任意のデータとともに使用され得る。

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

Claims (15)

1. 意味クエリのための装置であって、前記装置は、
   プロセッサと、
   前記プロセッサに結合されたメモリと
   を備え、
   前記メモリには、実行可能な命令が記憶されており、前記実行可能な命令は、前記プロセッサによって実行されると、
   第１の時間属性（１２３）と第１の場所属性（１２１）とを含む第１の属性を有する第１のセンサデータを受信することであって、前記第１のセンサデータは、前記第１の時間属性（１２３）と前記第１の場所属性（１２１）のジオハッシュとを含む意味情報を埋め込んだ第１の名前を有する、ことと、
   前記第１のセンサデータを記憶することと、
   センサデータのためのクエリを受信することであって、センサデータのための前記クエリは、場所を含む、ことと、
   センサデータのための前記クエリと意味情報を埋め込んだ前記第１の名前のフィールドとを比較することによって、センサデータのための前記クエリに対する一致を決定することと
   を含む動作を前記プロセッサに行わせる、装置。
2. 前記動作は、
   前記第１のセンサデータを集計することにより、第２のセンサデータを生成することであって、前記第２のセンサデータは、第２の時間属性または第２の場所属性または第２のタイプ属性を含む第２の属性を有する、ことと、
   前記第１の名前を前記第２のセンサデータに割り当てることと
   をさらに含む、請求項１に記載の装置。
3. 第１の属性を有する前記第１のセンサデータは、第１のタイプ属性（１２２）をさらに含む、請求項１または請求項２のいずれかに記載の装置。
4. 第１の属性を有する前記第１のセンサデータは、第１のタイプ属性（１２２）をさらに含み、
   意味情報を埋め込んだ前記第１の名前は、前記第１のタイプ属性（１２２）をさらに含む、請求項１〜３のいずれかに記載の装置。
5. 前記動作は、センサデータのための前記クエリに対する前記一致を決定することに応答して、前記第１のセンサデータを用いて前記クエリに応答することをさらに含む、請求項１〜４のいずれかに記載の装置。
6. 第１の属性を有する前記第１のセンサデータは、第１のタイプ属性（１２２）をさらに含み、前記第１のタイプ属性は、前記第１のセンスデータを感知した第１のセンサによって実行される感知のタイプに関連付けられている、請求項１〜５のいずれかに記載の装置。
7. センサデータのためのクエリは、複合クエリである、請求項１〜６のいずれかに記載の装置。
8. 前記装置は、サーバを含む、請求項１〜７のいずれかに記載の装置。
9. 意味クエリのための方法であって、前記方法は、
   第１の時間属性（１２３）と第１の場所属性（１２１）とを含む第１の属性を有する第１のセンサデータを受信することであって、前記第１のセンサデータは、前記第１の時間属性（１２３）と前記第１の場所属性（１２１）のジオハッシュとを含む意味情報を埋め込んだ第１の名前を有する、ことと、
   前記第１のセンサデータを記憶することと、
   センサデータのためのクエリを受信することであって、センサデータのための前記クエリは、場所を含む、ことと、
   センサデータのための前記クエリと意味情報を埋め込んだ前記第１の名前のフィールドとを比較することによって、センサデータのための前記クエリに対する一致を決定することと
   を含む、方法。
10. 前記第１のセンサデータを集計することにより、第２のセンサデータを生成することであって、前記第２のセンサデータは、第２の時間属性または第２の場所属性または第２のタイプ属性を含む第２の属性を有する、ことと、
    前記第１の名前を前記第２のセンサデータに割り当てることと
    をさらに含む、請求項９に記載の方法。
11. 第１の属性を有する前記第１のセンサデータは、第１のタイプ属性（１２２）をさらに含む、請求項９または請求項１０のいずれかに記載の方法。
12. 第１の属性を有する前記第１のセンサデータは、第１のタイプ属性（１２２）をさらに含み、
    意味情報を埋め込んだ前記第１の名前は、前記第１のタイプ属性（１２２）をさらに含む、請求項９〜１１のいずれかに記載の方法。
13. 前記動作は、センサデータのための前記クエリに対する前記一致を決定することに応答して、前記第１のセンサデータを用いて前記クエリに応答することをさらに含む、請求項９〜１２のいずれかに記載の方法。
14. 第１の属性を有する前記第１のセンサデータは、第１のタイプ属性（１２２）をさらに含み、前記第１のタイプ属性は、前記第１のセンスデータを感知した第１のセンサによって実行される感知のタイプに関連付けられている、請求項９〜１３のいずれかに記載の方法。
15. コンピュータプログラムが記憶されたコンピュータ読み取り可能な記憶媒体であって、前記コンピュータプログラムは、データ処理ユニットにロード可能であり、前記コンピュータプログラムは、前記コンピュータプログラムが前記データ処理ユニットによって実行されると、請求項９〜１４のいずれかに記載の方法のステップを実行することを前記データ処理ユニットに行わせるように適合されている、コンピュータ読み取り可能な記憶媒体。

Images