(57)【特許請求の範囲】
【請求項１】
モノのインターネット(IoT)ネットワークにおいてイベント辞書を自動的に生成する方法であって、
前記IoTネットワークにおける第1のIoTデバイスから第1のイベントの通知を受信するステップと、
前記第1のイベントの前および後の前記第1のIoTデバイスの状態を判定するステップと、
前記第1のIoTデバイスの前記状態同士を比較するステップと、
前記比較するステップに基づいて前記第1のイベントの状態変化のタイプを判定するステップと、
前記第1のイベントの前記状態変化の前記タイプが前記イベント辞書内に存在するかどうかを判定するステップと、
前記第1のイベントの前記状態変化の前記タイプが前記イベント辞書内には存在しないことに基づいて汎用エントリを作成するステップと、
前記第1のIoTデバイスと同じタイプおよび／またはクラスの全てのIoTデバイスに対して前記第1のイベントのイベント記述の前記汎用エントリへのマッピングを前記イベント辞書に記憶するステップとを含む方法。
【請求項２】
前記第1のイベントの前の前記第1のIoTデバイスの前記状態を判定するステップは、前記第1のイベントの前の前記第1のIoTデバイスの前記状態を取り込むために前記第1のIoTデバイスを周期的にポーリングするステップを含み、
前記第1のイベントの後の前記第1のIoTデバイスの状態を判定するステップは、前記第1のイベントの後の前記第1のIoTデバイスの前記状態を取り込むステップを含む、請求項1に記載の方法。
【請求項３】
前記第1のIoTデバイスのタイプを判定するステップをさらに含み、前記作成するステップは、前記第1のIoTデバイスの前記タイプと一致するIoTデバイスのタイプおよび前記第1のイベントの前記状態変化の前記タイプと一致する状態変化のタイプに関する前記汎用エントリを前記イベント辞書内に作成するステップを含む、請求項1に記載の方法。
【請求項４】
前記汎用エントリは、前記汎用エントリに関連する前記状態変化のタイプの計数とテキスト記述とを含む、請求項1に記載の方法。
【請求項５】
前記IoTネットワークにおける第2のIoTデバイスから第2のイベントの第2の通知を受信するステップと、
前記第2のイベントの前および後の前記第2のIoTデバイスの状態を判定するステップと、
前記第2のIoTデバイスの前記状態同士を比較するステップと、
前記比較するステップに基づいて前記第2のイベントの状態変化のタイプを判定するステップと、
前記第2のイベントが、前記第1のイベントの前記状態変化と同じタイプの状態変化および前記第1のIoTデバイスと同じタイプおよび/またはクラスであることに基づいて前記第2のイベントを前記汎用エントリにマッピングするステップと、
前記第2のIoTデバイスから受信された前記第2のイベントのイベント記述の前記汎用エントリへのマッピングを記憶するステップとをさらに含む、請求項1に記載の方法。
【請求項６】
前記第2のイベントの前記イベント記述は、前記第1のイベントの前記イベント記述とは異なる、請求項5に記載の方法。
【請求項７】
前記汎用エントリは、前記第1のIoTデバイスと前記第2のIoTデバイスに共通する汎用状態変化を記述し、さらに、前記汎用エントリは、前記第1のIoTデバイスおよび前記第2のIoTデバイスから受信されたイベントに関するイベント記述を含む、請求項5に記載の方法。
【請求項８】
前記イベント辞書を前記IoTネットワークにおける他のIoTデバイスに送信するステップをさらに含む、請求項1に記載の方法。
【請求項９】
前記イベント辞書において定義された汎用エントリに基づいてホームオートメーション規則を定義するステップと、
前記ホームオートメーション規則を前記IoTネットワークにおける前記他のIoTデバイスに配信するステップとをさらに含む、請求項8に記載の方法。
【請求項１０】
前記IoTネットワークにおける第3のIoTデバイスは、前記IoTネットワークにおける前記第1または前記第2のIoTデバイスからイベント通知を受信し、前記受信されたイベント通知内のイベント情報を前記イベント辞書における前記汎用エントリにマップし、前記イベント辞書における前記汎用エントリに関して定義されたホームオートメーション規則を実行する、請求項5に記載の方法。
【請求項１１】
モノのインターネット(IoT)ネットワークにおいてイベント辞書を自動的に生成するための装置であって、
前記IoTネットワークにおける第1のIoTデバイスから第1のイベントの通知を受信するための手段と、
前記第1のイベントの前および後の前記第1のIoTデバイスの状態を判定するための手段と、
前記第1のIoTデバイスの前記状態同士を比較するための手段と、
前記第1のIoTデバイスの前記状態同士の比較に基づいて前記第1のイベントの状態変化のタイプを判定するための手段と、
前記第1のイベントの前記状態変化の前記タイプが前記イベント辞書内に存在するかどうかを判定するための手段と、
前記第1のイベントの前記状態変化の前記タイプが前記イベント辞書内には存在しないことに基づいて汎用エントリを作成するための手段と、
前記第1のIoTデバイスと同じタイプおよび／またはクラスの全てのIoTデバイスに対して前記第1のイベントのイベント記述の前記汎用エントリへのマッピングを前記イベント辞書に記憶するための手段とを備える装置。
【請求項１２】
前記受信するための手段は、前記IoTネットワークにおける第1のIoTデバイスから第1のイベントの通知を受信するように構成されたトランシーバであり、
前記第1のイベントの前および後の前記第1のIoTデバイスの状態を判定するための手段と、
前記第1のIoTデバイスの前記状態同士を比較するための手段と、
前記第1のIoTデバイスの前記状態同士の比較に基づいて前記第1のイベントの状態変化のタイプを判定するための手段と、
前記第1のイベントの前記状態変化の前記タイプが前記イベント辞書内に存在するかどうかを判定するための手段と、
前記第1のイベントの前記状態変化の前記タイプが前記イベント辞書内には存在しないことに基づいて汎用エントリを作成するための手段と、
として機能するように構成された少なくとも1つのプロセッサと、
前記記憶するための手段は、前記第1のIoTデバイスと同じタイプおよび／またはクラスの全てのIoTデバイスに対して前記第1のイベントのイベント記述の前記汎用エントリへのマッピングを前記イベント辞書に記憶するように構成されたメモリである、
請求項１１に記載の装置。
【請求項１３】
前記第1のイベントの前の前記第1のIoTデバイスの前記状態を判定するように構成された前記少なくとも1つのプロセッサは、前記第1のイベントの前の前記第1のIoTデバイスの前記状態を取り込むために前記第1のIoTデバイスを周期的にポーリングするように構成された前記少なくとも1つのプロセッサを含み、
前記第1のイベントの後の前記第1のIoTデバイスの状態を判定するように構成された前記少なくとも1つのプロセッサは、前記第1のイベントの後の前記第1のIoTデバイスの前記状態を取り込むように構成された前記少なくとも1つのプロセッサを含む、請求項12に記載の装置。
【請求項１４】
前記少なくとも1つのプロセッサは、前記第1のIoTデバイスのタイプを判定するようにさらに構成され、前記作成するように構成された前記少なくとも1つのプロセッサは、前記第1のIoTデバイスの前記タイプと一致するIoTデバイスのタイプおよび前記第1のイベントの前記状態変化の前記タイプと一致する状態変化のタイプに関する前記汎用エントリを前記イベント辞書内に作成するように構成された前記少なくとも1つのプロセッサを備える、請求項12に記載の装置。
【請求項１５】
モノのインターネット(IoT)ネットワークにおいてイベント辞書を自動的に生成するためのコンピュータ可読記憶媒体であって、コンピュータにより実行されたとき、請求項1乃至10のいずれか一項に記載の方法を実施させる命令を含む、コンピュータ可読記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願の相互参照
本特許出願は、本出願の譲受人に譲渡され、その全体が参照により本明細書に明確に組み込まれる、2014年8月11日に出願された「AUTOMATICALLY GENERATING A MACHINE-TO-MACHINE (M2M) EVENTS DICTIONARY IN A DISTRIBUTED INTERNET OF THINGS (IOT) NETWORK」と題する米国仮出願第62/035,580号の利益を主張する。
【０００２】
本開示は、分散モノのインターネット(IoT)ネットワークにおいてマシンツーマシン(M2M)イベント辞書を自動的に生成することに関する。
【背景技術】
【０００３】
インターネットは、標準インターネットプロトコルスイート(たとえば、伝送制御プロトコル(TCP)およびインターネットプロトコル(IP))を使用して互いに通信する、相互接続されたコンピュータならびにコンピュータネットワークのグローバルシステムである。モノのインターネット(IoT)は、コンピュータおよびコンピュータネットワークだけでなく、日常の物が、IoT通信ネットワーク(たとえば、アドホックシステムまたはインターネット)を介して読取り可能、認識可能、位置特定可能、アドレス指定可能、および制御可能であり得るという発想に基づく。
【０００４】
いくつかの市場動向がIoTデバイスの開発を推進している。たとえば、増大するエネルギーコストは、政府によるスマートグリッドに対する戦略投資、ならびに電気自動車および公共充電ステーションなど、将来の消費に対するサポートを推進している。増大する医療費および老齢人口は、遠隔/コネクテッドヘルスケア(connected health care)およびフィットネスサービスの開発を推進している。住居内の技術革命は、「N」プレイ(たとえば、データ、音声、ビデオ、セキュリティ、エネルギー管理など)をマーケティングして、ホームネットワークを拡張するサービスプロバイダによる統合を含めて、新しい「スマート」サービスの開発を推進している。企業設備の運転費を削減するための手段として、建造物はよりスマートかつより便利になっている。
【０００５】
IoT用のいくつかの重要なアプリケーションが存在する。たとえば、スマートグリッドおよびエネルギー管理の領域では、公益事業会社は住居および事業に対するエネルギーの配給を最適化することができるのに対して、カスタマはエネルギー使用をより良好に管理することができる。住居およびビルディングオートメーションの領域では、スマートホームおよびスマート建造物は、住居もしくは事務所内の、電化製品からプラグイン電気自動車(PEV)セキュリティシステムまで、事実上、どのようなデバイスまたはシステムに対しても集中制御し得る。資産管理の分野では、企業、病院、工場、および他の大型組織は、価値が高い設備、患者、車両などの位置を正確に追跡することができる。ヘルスおよびウェルネスの領域では、医師は患者の健康を遠隔で監視することができるのに対して、人々はフィットネスルーチンの進捗を追跡することができる。
【発明の概要】
【課題を解決するための手段】
【０００６】
以下では、本明細書において開示する1つまたは複数の態様および/または実施形態に関する簡略化された概要を示す。したがって、以下の概要は、すべての考えられる態様および/または実施形態に関連する包括的な概説と見なされるべきではなく、また、以下の概要は、すべての考えられる態様および/または実施形態に関連する重要な、または決定的な要素を特定するか、任意の特定の態様および/または実施形態に関連付けられる範囲を定めると見なされるべきでもない。したがって、以下の概要は、以下に提示される詳細な説明に先立って、本明細書において開示される機構に関連する1つまたは複数の態様および/または実施形態に関連する特定の概念を簡略化された形で提示することが唯一の目的である。
【０００７】
本開示は、IoTネットワークにおいてイベント辞書を自動的に生成することに関する。IoTネットワークにおいてイベント辞書を自動的に生成するための方法は、IoTネットワークにおける第1のIoTデバイスから第1のイベントの通知を受信するステップと、第1のイベントの前および後の第1のIoTデバイスの状態を判定するステップと、第1のIoTデバイスの状態同士を比較するステップと、比較するステップに基づいて、第1のイベントの状態変化のタイプを判定するステップと、第1のイベントの状態変化のタイプがイベント辞書内に存在するかどうかを判定するステップと、第1のイベントの状態変化のタイプがイベント辞書内には存在しないことに基づいて汎用エントリを作成するステップであって、汎用エントリに関連する状態変化のタイプが、第1のIoTデバイスと同じタイプおよび/またはクラスのIoTデバイスに共通する、ステップと、第1のイベントのイベント記述の汎用エントリへのマッピングをイベント辞書に記憶するステップとを含む。
【０００８】
IoTネットワークにおいてイベント辞書を自動的に生成するための装置は、IoTネットワークにおける第1のIoTデバイスから第1のイベントの通知を受信するように構成されたトランシーバと、少なくとも1つのプロセッサであって、第1のイベントの前および後の第1のIoTデバイスの状態を判定することと、第1のIoTデバイスの状態同士を比較することと、第1のIoTデバイスの状態同士の比較に基づいて、第1のイベントの状態変化のタイプを判定することと、第1のイベントの状態変化のタイプがイベント辞書内に存在するかどうかを判定することと、第1のイベントの状態変化のタイプがイベント辞書内には存在しないことに基づいて汎用エントリを作成することであって、汎用エントリに関連する状態変化のタイプが、第1のIoTデバイスと同じタイプおよび/またはクラスのIoTデバイスに共通する、作成することとを行うように構成されたプロセッサと、第1のイベントのイベント記述の汎用エントリへのマッピングをイベント辞書に記憶するように構成されたメモリとを含む。
【０００９】
IoTネットワークにおいてイベント辞書を自動的に生成するための装置は、IoTネットワークにおけるIoTデバイスからイベントの通知を受信するための手段と、イベントの前および後のIoTデバイスの状態を判定するための手段と、IoTデバイスの状態同士を比較するための手段と、IoTデバイスの状態同士の比較に基づいて、イベントの状態変化のタイプを判定するための手段と、イベントの状態変化のタイプがイベント辞書内に存在するかどうかを判定するための手段と、イベントの状態変化のタイプがイベント辞書内には存在しないことに基づいて汎用エントリを作成するための手段であって、汎用エントリに関連する状態変化のタイプが、IoTデバイスと同じタイプおよび/またはクラスのIoTデバイスに共通する、手段と、イベントのイベント記述の汎用エントリへのマッピングをイベント辞書に記憶するための手段とを含む。
【００１０】
IoTネットワークにおいてイベント辞書を自動的に生成するための非一時的コンピュータ可読記憶媒体は、IoTネットワークにおけるIoTデバイスからイベントの通知を受信するための少なくとも1つの命令と、イベントの前および後のIoTデバイスの状態を判定するための少なくとも1つの命令と、IoTデバイスの状態同士を比較するための少なくとも1つの命令と、IoTデバイスの状態同士の比較に基づいて、イベントの状態変化のタイプを判定するための少なくとも1つの命令と、イベントの状態変化のタイプがイベント辞書内に存在するかどうかを判定するための少なくとも1つの命令と、イベントの状態変化のタイプがイベント辞書内には存在しないことに基づいて汎用エントリを作成するための少なくとも1つの命令であって、汎用エントリに関連する状態変化のタイプが、IoTデバイスと同じタイプおよび/またはクラスのIoTデバイスに共通する、少なくとも1つの命令と、イベントのイベント記述の汎用エントリへのマッピングをイベント辞書に記憶するための少なくとも1つの命令とを含む。
【００１１】
本明細書において開示される態様および実施形態に関連付けられる他の目的および利点は、添付の図面および詳細な説明に基づいて、当業者に明らかになるであろう。
【００１２】
本開示の態様およびその付随する利点の多くに関するより完全な理解は、以下の詳細な説明を参照しながら、本発明を限定するためではなく単に例示するために提示される添付の図面とともに考察することによって、本開示の態様およびその付随する利点の多くがより深く理解されるようになるときに容易に得られるであろう。
【図面の簡単な説明】
【００１３】
【図１Ａ】本開示の一態様によるワイヤレス通信システムのハイレベルシステムアーキテクチャを示す図である。
【図１Ｂ】本開示の別の態様によるワイヤレス通信システムのハイレベルシステムアーキテクチャを示す図である。
【図１Ｃ】本開示の一態様によるワイヤレス通信システムのハイレベルシステムアーキテクチャを示す図である。
【図１Ｄ】本開示の一態様によるワイヤレス通信システムのハイレベルシステムアーキテクチャを示す図である。
【図１Ｅ】本開示の一態様によるワイヤレス通信システムのハイレベルシステムアーキテクチャを示す図である。
【図２Ａ】本開示の態様による例示的なモノのインターネット(IoT)デバイスを示す図である。
【図２Ｂ】本開示の態様による例示的な受動IoTデバイスを示す図である。
【図３】本開示の態様による、機能を実現するように構成された論理を含む通信デバイスを示す図である。
【図４】本開示の様々な態様による例示的なサーバを示す図である。
【図５】本開示の一態様による、発見可能なピアツーピア(P2P)サービスをサポートすることのできるワイヤレス通信ネットワークを示す図である。
【図６】本開示の一態様による、様々なデバイスが通信するのに利用することができる近接度ベースの分散バスを確立するために発見可能なP2Pサービスを使用し得る例示的な環境を示す図である。
【図７】本開示の一態様による、様々なデバイスが通信するのに利用することができる近接度ベースの分散バスを確立するために発見可能なP2Pサービスを使用し得る例示的なメッセージシーケンスを示す図である。
【図８】本開示の少なくとも1つの態様による例示的な近位IoTネットワーク800を示す図である。
【図９】デバイス間通信プロトコルに関するイベント辞書を自動的に生成するための例示的なフローを示す図である。
【図１０】本開示の一態様による、発見可能なP2Pサービスを使用して近接度ベースの分散バスを介して通信するデバイスに対応する場合がある例示的なブロック図である。
【図１１】本明細書で教示する通信をサポートするように構成された装置のサンプル態様の簡略ブロック図である。
【発明を実施するための形態】
【００１４】
モノのインターネット(IoT)ネットワークにおいてイベント辞書を自動的に生成するための方法およびシステムを開示する。一態様では、IoTネットワークにおける第1のIoTデバイスから第1のイベントの通知を受信し、第1のイベントの前および後の第1のIoTデバイスの状態を判定し、第1のIoTデバイスの状態同士を比較し、比較に基づいて、第1のイベントの状態変化のタイプを判定し、第1のイベントの状態変化のタイプがイベント辞書内に存在するかどうかを判定し、第1のイベントの状態変化のタイプがイベント辞書内には存在しないことに基づいて汎用エントリを作成し、その場合に、汎用エントリに関連する状態変化のタイプが、第1のIoTデバイスと同じタイプおよび/またはクラスのIoTデバイスに共通し、第1のイベントのイベント記述の汎用エントリへのマッピングをイベント辞書に記憶する。
【００１５】
この態様およびその他の態様が、例示的な実施形態に関する特定の例を示すために以下の説明および関連する図面において開示される。代替的実施形態は、この開示を読むと当業者には明らかであり、本開示の範囲または趣旨を逸脱することなく構築され、実践され得る。加えて、本明細書で開示する態様および実施形態の関連する詳細を不明瞭にしないように、よく知られている要素は詳細には説明されず、または省略され得る。
【００１６】
「例示的」という言葉は、本明細書では「例、事例、または例示として機能すること」を意味するために使用される。本明細書で「例示的」として説明するいかなる実施形態も、必ずしも他の実施形態よりも好ましいか、または有利であると解釈されるべきではない。同様に、「実施形態」という用語は、すべての実施形態が、論じられた特徴、利点または動作モードを含むことを要求しない。
【００１７】
本明細書で使用される用語は、特定の実施形態のみを説明しており、本明細書で開示されるいずれかの実施形態を限定すると解釈されるべきではない。本明細書で使用される単数形「a」、「an」、および「the」は、文脈が別段に明確に示すのでなければ、複数形をも含むものとする。さらに、「含む(comprises)」、「含んでいる(comprising)」、「含む(includes)」、および/または「含んでいる(including)」という用語は、本明細書で使用すると、述べられた特徴、整数、ステップ、動作、要素、および/または構成要素の存在を明示するが、1つまたは複数の他の特徴、整数、ステップ、動作、要素、構成要素、および/またはそれらのグループの存在または追加を排除しないことが理解されよう。
【００１８】
さらに、多くの態様について、たとえばコンピューティングデバイスの要素によって実施されるべき、動作のシーケンスに関して説明する。本明細書で説明する様々な動作は、特定の回路(たとえば、特定用途向け集積回路(ASIC))によって、1つまたは複数のプロセッサによって実行されるプログラム命令によって、あるいは両方の組合せによって実施され得ることは認識されよう。さらに、本明細書で説明されるこれらの一連の動作は、実行されると、関連するプロセッサに本明細書において説明される機能を実行させることになる対応する1組のコンピュータ命令を記憶した、任意の形のコンピュータ可読記憶媒体内で完全に具現されるものと見なされ得る。したがって、本開示の様々な態様は、特許請求される主題の範囲内にすべて入ることが企図されているいくつかの異なる形で具現され得る。さらに、本明細書で説明される実施形態ごとに、任意のそのような実施形態の対応する形は、本明細書において、たとえば、説明される動作を実行する「ように構成された論理」として説明される場合がある。
【００１９】
本明細書で使用する「モノのインターネットデバイス」(すなわち「IoTデバイス」)という用語は、アドレス指定可能なインターフェース(たとえば、インターネットプロトコル(IP)アドレス、Bluetooth(登録商標)識別子(ID)、近距離無線通信(NFC:near-field communication)IDなど)を有し、有線またはワイヤレス接続を通じて1つまたは複数の他のデバイスに情報を送信することができる任意の物(たとえば、電化製品、センサーなど)を指すことができる。IoTデバイスは、クイックレスポンス(QR)コード、無線周波数識別(RFID)タグ、NFCタグなどの受動通信インターフェース、または、モデム、トランシーバ、送信機-受信機などの能動通信インターフェースを有し得る。IoTデバイスは、中央処理装置(CPU)、マイクロプロセッサ、ASICなどの中に組み込まれること、および/あるいは、それらによって制御/監視されることが可能であり、ローカルアドホックネットワークまたはインターネットなどのIoTネットワークに接続するように構成された特定の属性セット(たとえば、IoTデバイスがオンであるか、もしくはオフであるか、開いているか、もしくは閉じているか、アイドルであるか、もしくはアクティブであるか、タスク実行のために利用可能であるか、もしくはビジーであるかなど、冷房機能であるか、もしくは暖房機能であるか、環境監視機能であるか、もしくは環境記録機能であるか、発光機能であるか、音響放射機能であるかなど、デバイスの状態またはステータス)を有し得る。たとえば、IoTデバイスは、これらのデバイスがIoTネットワークと通信するためのアドレス指定可能通信インターフェースを備える限り、冷蔵庫、トースター、オーブン、電子レンジ、冷凍庫、皿洗い機、パラボラアンテナ(dishes)、手工具、洗濯機、衣類乾燥機、加熱炉、空調機、温度自動調整器、テレビジョン、照明設備、掃除機、スプリンクラー、電気メータ、ガスメータなどを含み得るが、これらに限定されない。IoTデバイスはまた、セルフォン、デスクトップコンピュータ、ラップトップコンピュータ、タブレットコンピュータ、携帯情報端末(PDA)などを含み得る。したがって、IoTネットワークは、通常はインターネット接続性を有しないデバイス(たとえば、皿洗い機など)に加えて、「レガシー」インターネットアクセス可能デバイス(たとえば、ラップトップコンピュータまたはデスクトップコンピュータ、セルフォンなど)の組合せから構成され得る。
【００２０】
図1Aは、本開示の一態様によるワイヤレス通信システム100Aのハイレベルシステムアーキテクチャを示す。ワイヤレス通信システム100Aは、テレビジョン110と、屋外空調機112と、温度自動調整器114と、冷蔵庫116と、洗濯機および乾燥機118とを含む、複数のIoTデバイス110〜118を含む。
【００２１】
図1Aを参照すると、IoTデバイス110〜118は、図1Aにエアインターフェース108および直接有線接続109として示す物理通信インターフェースまたは物理通信レイヤを介してアクセスネットワーク(たとえば、アクセスポイント125)と通信するように構成される。エアインターフェース108は、IEEE 802.11など、ワイヤレスインターネットプロトコル(IP)に準拠し得る。図1Aは、エアインターフェース108を介して通信するIoTデバイス110〜118と、直接有線接続109を介して通信するIoTデバイス118とを示すが、各IoTデバイスは、有線接続もしくはワイヤレス接続、または両方を介して通信することができる。
【００２２】
インターネット175は、いくつかのルーティングエージェントおよび処理エージェント(便宜上、図1Aには示されていない)を含む。インターネット175は、標準インターネットプロトコルスイート(たとえば、伝送制御プロトコル(TCP)およびIP)を使用して、異種のデバイス/ネットワークの間で通信する、相互接続されたコンピュータならびにコンピュータネットワークのグローバルシステムである。TCP/IPは、データが、宛先において、どのようにフォーマッティング、アドレス指定、送信、経路指定、および受信されるべきかを指定するエンドツーエンド接続性を提供する。
【００２３】
図1Aでは、デスクトップコンピュータまたはパーソナルコンピュータ(PC)などのコンピュータ120は、(たとえば、Ethernet(登録商標)接続またはWi-Fiもしくは802.11ベースのネットワークを介して)インターネット175と直接接続するとして示される。コンピュータ120は、(たとえば、有線接続性とワイヤレス接続性の両方を有するWiFiルータ用の)アクセスポイント125自体などに相当してよいモデムまたはルータとの直接接続など、インターネット175との有線接続を有し得る。代替的に、有線接続を介して、アクセスポイント125およびインターネット175に接続されるのではなく、コンピュータ120は、エアインターフェース108または別のワイヤレスインターフェースを介してアクセスポイント125に接続されてよく、エアインターフェース108を介してインターネット175にアクセスしてよい。デスクトップコンピュータとして例示されているが、コンピュータ120は、ラップトップコンピュータ、タブレットコンピュータ、PDA、スマートフォンなどであり得る。コンピュータ120は、IoTデバイスであり得、かつ/またはIoTデバイス110〜118のネットワーク/グループなど、IoTネットワーク/グループを管理するための機能を含み得る。
【００２４】
アクセスポイント125は、たとえば、FiOS、ケーブルモデム、デジタル加入者線(DSL)モデムなど、光通信システムを介して、インターネット175に接続され得る。アクセスポイント125は、標準インターネットプロトコル(たとえば、TCP/IP)を使用して、IoTデバイス110〜120およびインターネット175と通信することができる。
【００２５】
図1Aを参照すると、IoTサーバ170は、インターネット175に接続されるように示されている。IoTサーバ170は、複数の構造的に別々の複数のサーバとして実装され得るか、または代替的には、単一のサーバに対応し得る。一態様では、IoTサーバ170は、(点線によって示されるように)オプションであり、IoTデバイス110〜120のグループは、ピアツーピア(P2P)ネットワークであり得る。そのような場合、IoTデバイス110〜120は、エアインターフェース108および/または直接有線接続109を介して互いに直接通信することができる。代替的に、または追加として、IoTデバイス110〜120の一部またはすべては、エアインターフェース108および直接有線接続109に依存しない通信インターフェースで構成され得る。たとえば、エアインターフェース108がWiFiインターフェースに対応する場合、IoTデバイス110〜120のうちの1つもしくは複数は、互いに、または他のBluetooth(登録商標)対応デバイスもしくはNFC対応デバイスと直接通信するためのBluetooth(登録商標)インターフェースあるいはNFCインターフェースを有し得る。
【００２６】
ピアツーピアネットワークでは、サービス発見方式は、ノードの存在、その能力、およびグループメンバーシップをマルチキャストすることができる。ピアツーピアデバイスは、この情報に基づいて、関連性および後続の相互作用を確立することができる。
【００２７】
本開示の一態様によれば、図1Bは、複数のIoTデバイスを含む別のワイヤレス通信システム100Bのハイレベルアーキテクチャを示す。一般に、図1Bに示すワイヤレス通信システム100Bは、上でより詳細に説明した、図1Aに示すワイヤレス通信システム100Aと同じ、ならびに/または実質的に同様の様々な構成要素(たとえば、エアインターフェース108および/もしくは直接有線接続109を介してアクセスポイント125と通信するように構成された、テレビジョン110と、屋外空調機112と、温度自動調整器114と、冷蔵庫116と、洗濯機および乾燥機118とを含む様々なIoTデバイス110〜120、インターネット175に直接接続する、かつ/あるいはアクセスポイント125を通してインターネット175に接続するコンピュータ120、ならびにインターネット175を介してアクセス可能なIoTサーバ170など)を含み得る。したがって、説明を簡潔かつ簡単にするために、同じまたは同様の詳細が図1Aに示したワイヤレス通信システム100Aに関して上ですでに提供されている限り、図1Bに示すワイヤレス通信システム100B内のいくつかの構成要素に関する様々な詳細は本明細書で省略される場合がある。
【００２８】
図1Bを参照すると、ワイヤレス通信システム100Bは、代替的に、IoTマネージャ130またはIoTマネージャデバイス130と呼ばれる場合もあるスーパーバイザデバイス130を含み得る。したがって、以下の説明が「スーパーバイザデバイス」130という用語を使用する場合、IoTマネージャ、グループ所有者、または同様の用語に対するいずれの参照もスーパーバイザデバイス130、あるいは同じもしくは実質的に同様の機能を提供する別の物理的構成要素または論理的構成要素を指す場合があることを当業者は諒解されよう。
【００２９】
一実施形態では、スーパーバイザデバイス130は、一般に、ワイヤレス通信システム100B内の様々な他の構成要素を観測、監視、制御、あるいは管理することができる。たとえば、スーパーバイザデバイス130は、エアインターフェース108および/または直接有線接続109を介してアクセスネットワーク(たとえば、アクセスポイント125)と通信して、ワイヤレス通信システム100B内の様々なIoTデバイス110〜120に関連付けられた属性、活動、もしくは他の状態を監視または管理することができる。スーパーバイザデバイス130は、インターネット175に対して、および、オプションで、(点線として示される)IoTサーバ170に対して、有線接続またはワイヤレス接続を有し得る。スーパーバイザデバイス130は、様々なIoTデバイス110〜120に関連付けられた属性、活動、もしくは他の状態をさらに監視または管理するために使用され得る情報をインターネット175および/あるいはIoTサーバ170から取得することができる。スーパーバイザデバイス130は、独立型デバイスであってよく、または、コンピュータ120など、IoTデバイス110〜120のうちの1つであってもよい。スーパーバイザデバイス130は、物理デバイスであってよく、または物理デバイス上で実行するソフトウェアアプリケーションであってもよい。スーパーバイザデバイス130は、IoTデバイス110〜120に関連付けられた、監視される属性、活動、または他の状態に関する情報を出力して、それらに関連付けられた属性、活動、または他の状態を制御あるいは管理するための入力情報を受信することができるユーザインターフェースを含み得る。したがって、スーパーバイザデバイス130は、一般に、様々な構成要素を含むことが可能であり、ワイヤレス通信システム100B内の様々な構成要素を観測、監視、制御、あるいは管理するために様々な有線通信インターフェースおよびワイヤレス通信インターフェースをサポートし得る。
【００３０】
図1Bに示すワイヤレス通信システム100Bは、ワイヤレス通信システム100Bに結合され得るか、あるいはワイヤレス通信システム100Bの一部であり得る(能動IoTデバイス110〜120と対照的な)1つまたは複数の受動IoTデバイス105を含み得る。一般に、受動IoTデバイス105は、短距離インターフェースを介して問い合わされたとき、その識別子と属性とを別のデバイスに提供することができる、バーコード付きデバイス、Bluetooth(登録商標)デバイス、無線周波数(RF)デバイス、RFIDタグ付きデバイス、赤外線(IR)デバイス、NFCタグ付きデバイス、または任意の他の適切なデバイスを含み得る。能動IoTデバイスは、受動IoTデバイスの属性の変化を検出すること、記憶すること、通信すること、それらの変化に作用することなどが可能である。
【００３１】
たとえば、受動IoTデバイス105は、各々、RFIDタグまたはバーコードを有するコーヒーカップとオレンジジュースの容器とを含み得る。キャビネットIoTデバイスおよび冷蔵庫IoTデバイス116は、各々、RFIDタグもしくはバーコードを読み取って、コーヒーカップおよび/またはオレンジジュースの容器の受動IoTデバイス105がいつ追加あるいは除去されたかを検出することができる適切なスキャナまたはリーダーを有し得る。キャビネットIoTデバイスがコーヒーカップの受動IoTデバイス105の除去を検出し、冷蔵庫IoTデバイス116がオレンジジュースの容器の受動IoTデバイスの除去を検出すると、スーパーバイザデバイス130は、キャビネットIoTデバイスおよび冷蔵庫IoTデバイス116において検出された活動に関する1つまたは複数の信号を受信することができる。スーパーバイザデバイス130は、次いで、ユーザがコーヒーカップからオレンジジュースを飲んでいる、およびまたはコーヒーカップからオレンジジュースを飲みたいことを推定することができる。
【００３２】
上記は何らかの形のRFIDタグ通信インターフェースまたはバーコード通信インターフェースを有するとして受動IoTデバイス105を説明しているが、受動IoTデバイス105は、そのような通信能力を有しない、1つもしくは複数のデバイスまたは他の物理的対象物を含み得る。たとえば、あるIoTデバイスは、受動IoTデバイス105を識別するために、受動IoTデバイス105に関連付けられた形状、サイズ、色、および/もしくは他の観測可能な特徴を検出することができる適切なスキャナ機構またはリーダー機構を有し得る。このようにして、任意の適切な物理的対象物はその識別情報および属性を通信して、ワイヤレス通信システム100Bの一部になることができ、スーパーバイザデバイス130を用いて観測、監視、制御、あるいは管理され得る。さらに、受動IoTデバイス105は、図1Aのワイヤレス通信システム100Aに結合され得るか、あるいはその一部であり得、実質的に同様の形で、観測、監視、制御、または管理され得る。
【００３３】
本開示の別の態様によれば、図1Cは、複数のIoTデバイス110〜118を含む別のワイヤレス通信システム100Cのハイレベルアーキテクチャを示す。一般に、図1Cに示すワイヤレス通信システム100Cは、上でより詳細に説明した、図1Aおよび図1Bにそれぞれ示したワイヤレス通信システム100Aならびに100Bと同じ、かつ/または実質的に同様の様々な構成要素を含み得る。したがって、説明を簡潔かつ簡単にするために、同じまたは類似の詳細が、それぞれ、図1Aおよび図1Bに示したワイヤレス通信システム100Aならびに100Bに関して上ですでに提供されている限り、図1Cに示すワイヤレス通信システム100C内のいくつかの構成要素に関する様々な詳細は本明細書で省略される場合がある。
【００３４】
図1Cに示すワイヤレス通信システム100Cは、IoTデバイス110〜118とスーパーバイザデバイス130との間の例示的なピアツーピア通信を示す。図1Cに示すように、スーパーバイザデバイス130は、IoTスーパーバイザインターフェースを介してIoTデバイス110〜118の各々と通信する。さらに、IoTデバイス110および114、IoTデバイス112、114、および116、ならびにIoTデバイス116および118は、互いに直接通信する。
【００３５】
IoTデバイス110〜118はIoTデバイスグループ160を構成する。IoTデバイスグループ160は、ユーザのホームネットワークに接続されたIoTデバイスなど、ローカルに接続されたIoTデバイスのグループである。示さないが、複数のIoTデバイスグループは、インターネット175に接続されたIoT SuperAgent140を介して互いに接続されること、および/または通信することが可能である。ハイレベルで、スーパーバイザデバイス130はグループ内通信を管理するのに対して、IoT SuperAgent140はグループ間通信を管理することができる。別個のデバイスとして示すが、スーパーバイザデバイス130およびIoT SuperAgent140は、同じデバイス(たとえば、図1Aのコンピュータ120など、独立型デバイスもしくはIoTデバイス)であり得るか、またはその中に存在し得る。代替的に、IoT SuperAgent140は、アクセスポイント125の機能に対応し得るか、またはその機能を含み得る。さらに別の代替として、IoT SuperAgent140は、IoTサーバ170などのIoTサーバの機能に対応し得るか、またはその機能を含み得る。IoT SuperAgent140は、ゲートウェイ機能145をカプセル化することができる。
【００３６】
各IoTデバイス110〜118は、スーパーバイザデバイス130をピアとして扱って、属性/スキーマ更新をスーパーバイザデバイス130に送信することができる。IoTデバイスが別のIoTデバイスと通信する必要があるとき、IoTデバイスは、スーパーバイザデバイス130にそのIoTデバイスに対するポインタを要求し、次いで、ピアとしてターゲットIoTデバイスと通信することができる。IoTデバイス110〜118は、共通メッセージングプロトコル(CMP)を使用して、ピアツーピア通信ネットワークを介して互いに通信する。2つのIoTデバイスがCMP対応であり、共通通信トランスポートを介して接続される限り、それらのIoTデバイスは互いに通信することができる。プロトコルスタック内で、CMPレイヤ154は、アプリケーションレイヤ152の下にあり、トランスポートレイヤ156および物理レイヤ158の上にある。
【００３７】
本開示の別の態様によれば、図1Dは、複数のIoTデバイス110〜120を含む別のワイヤレス通信システム100Dのハイレベルアーキテクチャを示す。一般に、図1Dに示すワイヤレス通信システム100Dは、それぞれ、上でより詳細に説明した、図1A〜図1Cに示したワイヤレス通信システム100A〜100Cと同じ、かつ/または実質的に類似した様々構成要素を含み得る。したがって、説明を簡潔かつ簡単にするために、同じまたは類似の詳細がそれぞれ図1A〜図1Cに示したワイヤレス通信システム100A〜100Cに関して上ですでに提供されている限り、図1Dに示すワイヤレス通信システム100D内のいくつかの構成要素に関する様々な詳細は本明細書で省略される場合がある。
【００３８】
インターネット175は、IoTの概念を使用して調整され得る「リソース」である。しかしながら、インターネット175は、調整されるリソースのほんの一例であり、任意のリソースがIoTの概念を使用して調整され得る。調整され得る他のリソースは、電気、ガス、ストレージ、セキュリティなどを含むが、これらに限定されない。IoTデバイスは、リソースに接続され得、それによって、リソースを調整するか、またはリソースはインターネット175を介して調整され得る。図1Dは、天然ガス、ガソリン、湯、および電気など、いくつかのリソース180を示し、リソース180は、インターネット175に加えて調整され得るか、またはインターネット175を介して調整され得る。
【００３９】
IoTデバイスは、互いに通信して、リソース180の使用を調整することができる。たとえば、トースター、コンピュータ、およびヘアドライヤなどのIoTデバイスは、Bluetooth(登録商標)通信インターフェースを介して互いに通信して、その電気(リソース180)使用を調整することができる。別の例として、デスクトップコンピュータ、電話、およびタブレットコンピュータなどのIoTデバイスは、Wi-Fi通信インターフェースを介して通信して、インターネット175(リソース180)に対するそのアクセスを調整することができる。さらに別の例として、ストーブ、衣類乾燥機、および湯沸かし器などのIoTデバイスは、Wi-Fi通信インターフェースを介して通信して、そのガス使用を調整することができる。代替的に、または追加として、各IoTデバイスは、IoTデバイスから受信された情報に基づいて、そのリソース180の使用を調整するための論理を有する、IoTサーバ170などのIoTサーバに接続され得る。
【００４０】
本開示の別の態様によれば、図1Eは、複数のIoTデバイスを含む別のワイヤレス通信システム100Eのハイレベルアーキテクチャを示す。一般に、図1Eに示すワイヤレス通信システム100Eは、上でより詳細に説明した、それぞれ、図1A〜図1Dに示したワイヤレス通信システム100A〜100Dと同じ、かつ/または実質的に類似した様々構成要素を含み得る。したがって、説明を簡潔かつ簡単にするために、同じまたは類似の詳細がそれぞれ図1A〜図1Dに示したワイヤレス通信システム100A〜100Dに関して上ですでに提供されている限り、図1Eに示すワイヤレス通信システム100E内のいくつかの構成要素に関する様々な詳細は本明細書で省略される場合がある。
【００４１】
ワイヤレス通信システム100Eは、2つのIoTデバイスグループ160Aおよび160Bを含む。複数のIoTデバイスグループは、インターネット175に接続されたIoT SuperAgentを介して互いに接続されること、および/または互いに通信することが可能である。ハイレベルで、IoT SuperAgentは、IoTデバイスグループ内のグループ間通信を管理することができる。たとえば、図1Eで、IoTデバイスグループ160Aは、IoTデバイス116A、122A、および124Aと、IoT SuperAgent140Aとを含むのに対して、IoTデバイスグループ160Bは、IoTデバイス116B、122B、および124Bと、IoT SuperAgent140Bとを含む。したがって、IoT SuperAgent140Aおよび140Bは、インターネット175と接続して、インターネット175を介して互いと通信すること、ならびに/またはIoTデバイスグループ160Aおよび160B間の通信を促すために互いと直接通信することができる。さらに、図1Eは、IoT SuperAgent140Aおよび140Bを介して互いと通信する2つのIoTデバイスグループ160Aおよび160Bを示すが、任意の数のIoTデバイスグループが、IoT SuperAgentを使用して互いと好適に通信することができることを当業者は諒解されよう。
【００４２】
図2Aは、本開示の態様によるIoTデバイス200Aのハイレベルな例を示す。IoTデバイス200Aは、IoTデバイス110〜120のうちのいずれかに対応してもよく、スーパーバイザデバイス130およびゲートウェイ145の機能がIoTデバイス(たとえば、コンピュータ120)において具現化されるときには、スーパーバイザデバイス130および/またはゲートウェイ145にさらに対応してもよい。外観および/または内部構成要素はIoTデバイス間でかなり異なる場合があるが、大部分のIoTデバイスは、ディスプレイとユーザ入力のための手段とを含み得る、ある種のユーザインターフェースを有することになる。ユーザインターフェースがないIoTデバイスは、図1A〜図1Bにおけるエアインターフェース108など、有線ネットワークまたはワイヤレスネットワークを介してリモートで通信され得る。
【００４３】
図2Aに示すように、IoTデバイス200Aに関する例示的な構成では、IoTデバイス200Aの外部ケーシングは、当技術分野で知られているように、構成要素の中でも、ディスプレイ226と、電源ボタン222と、2つの制御ボタン224Aおよび224Bとで構成され得る。ディスプレイ226は、タッチスクリーンディスプレイであり得、その場合、制御ボタン224Aおよび224Bは必要でない場合がある。IoTデバイス200Aの一部として明示的に示されてはいないが、IoTデバイス200Aは、限定はしないが、Wi-Fiアンテナ、セルラーアンテナ、衛星位置システム(SPS)アンテナ(たとえば、全地球測位システム(GPS)アンテナ)などを含む、1つまたは複数の外部アンテナおよび/または外部ケーシングに内蔵される1つのまたは複数の内蔵アンテナを含むことができる。
【００４４】
IoTデバイス200AなどのIoTデバイスの内部構成要素は異なるハードウェア構成によって具体化され得るが、内部ハードウェア構成要素のための基本的なハイレベル構成は図2Aにプラットフォーム202として示されている。プラットフォーム202は、図1A〜図1Bのエアインターフェース108ならびに/または有線インターフェースなど、ネットワークインターフェースを介して送信されたソフトウェアアプリケーション、データ、および/またはコマンドを受信ならびに実行することができる。プラットフォーム202は、ローカルに記憶されたアプリケーションを独立して実行してもよい。プラットフォーム202は、一般に、プロセッサ208と呼ばれることになる、マイクロコントローラ、マイクロプロセッサ、特定用途向け集積回路、デジタル信号プロセッサ(DSP)、プログラマブル論理回路、または他のデータ処理デバイスなど、1つもしくは複数のプロセッサ208に動作可能に結合された有線通信および/あるいはワイヤレス通信のために構成された1つもしくは複数のトランシーバ206(たとえば、Wi-Fiトランシーバ、Bluetooth(登録商標)トランシーバ、セルラートランシーバ、衛星トランシーバ、GPS受信機またはSPS受信機など)を含み得る。プロセッサ208は、IoTデバイス200A内のメモリ212内でアプリケーションプログラミング命令を実行することができる。メモリ212は、読取り専用メモリ(ROM)、ランダムアクセスメモリ(RAM)、電気消去可能プログラマブルROM(EEPROM)、フラッシュカード、またはコンピュータプラットフォームに共通の任意のメモリのうちの1つもしくは複数を含み得る。1つもしくは複数の入出力(I/O)インターフェース214は、プロセッサ208が、示すようなディスプレイ226、電源ボタン222、制御ボタン224Aおよび224Bなどの様々なI/Oデバイス、ならびにIoTデバイス200Aに関連付けられたセンサー、アクチュエータ、リレー、バルブ、スイッチなどの任意の他のデバイスと通信すること、ならびにそれらから制御することを可能にするように構成され得る。
【００４５】
したがって、本開示の一態様は、本明細書に記載された機能を実行する能力を含むIoTデバイス(たとえば、IoTデバイス200A)を含むことができる。当業者によって諒解されるように、様々な論理要素は、本明細書で開示する機能を実現するように個別の要素、プロセッサ(たとえば、プロセッサ208)上で実行されるソフトウェアモジュール、またはソフトウェアとハードウェアとの任意の組合せにおいて具現されてもよい。たとえば、トランシーバ206、プロセッサ208、メモリ212、およびI/Oインターフェース214をすべて協調的に使用して、本明細書において開示する様々な機能をロードし、記憶し、実行してもよく、したがって、これらの機能を実行するための論理は様々な要素に分散されてもよい。代替的に、機能は1つの離散構成要素に組み込むことが可能である。したがって、図2AにおけるIoTデバイス200Aの特徴は、単に例示にすぎないものと見なされ、本開示は、示された特徴または構成に限定されない。
【００４６】
たとえば、IoTデバイス200Aが、IoTネットワークにおいてイベント辞書を自動的に生成するように構成された、スーパーバイザデバイス130などのスーパーバイザデバイスに対応する場合、IoTデバイス200Aは、本明細書において説明する機能を実行するかまたは実行させるように構成されたイベントモニタおよび辞書ジェネレータ(EMDG)モジュール210を含んでもよい。EMDGモジュール210は、ハードウェアモジュールであっても、またはプロセッサ208によって実行可能なソフトウェアモジュールであっても、またはハードウェアとソフトウェアの組合せであってもよい。例示的な一実施形態では、トランシーバ206は、IoTネットワークにおけるIoTデバイスからイベントの通知を受信し、プロセッサ208/EMDGモジュール210は、トランシーバ206とともに、そのイベントの前および後のIoTデバイスの状態を判定してもよい。プロセッサ208/EMDGモジュール210はまた、IoTデバイスの状態同士を比較し、比較に基づいてイベントの状態変化のタイプを判定し、第1のイベントの状態変化のタイプがイベント辞書内に存在するかどうかを判定してもよい。プロセッサ208/EMDGモジュール210は、メモリ212とともに、第1のイベントの状態変化のタイプがイベント辞書内には存在しないことに基づいて汎用エントリを作成してもよく、その場合に、汎用エントリに関連する状態変化のタイプが、このIoTデバイスと同じタイプおよび/またはクラスのIoTデバイスと共通し、メモリ212は、イベントのイベント記述の汎用エントリへのマッピングをイベント辞書に記憶してもよい。
【００４７】
図2Bは、本開示の態様による受動IoTデバイス200Bのハイレベルな例を示す。一般に、図2Bに示す受動IoTデバイス200Bは、上でより詳細に説明した、図2Aに示したIoTデバイス200Aと同じ、かつ/または実質的に類似した様々構成要素を含み得る。したがって、説明を簡潔かつ簡単にするために、同じまたは類似の詳細が図2Aに示したIoTデバイス200Aに関して上ですでに提供されている限り、図2Bに示す受動IoTデバイス200B内のいくつかの構成要素に関する様々な詳細は本明細書で省略される場合がある。
【００４８】
図2Bに示す受動IoTデバイス200Bは、プロセッサ、内部メモリ、またはある種の他の構成要素を有しない場合があるという点で、一般に、図2Aに示すIoTデバイス200Aとは異なる場合がある。代わりに、一実施形態では、受動IoTデバイス200Bは、受動IoTデバイス200Bが、制御されたIoTネットワーク内で観測されること、監視されること、制御されること、管理されること、あるいは知られることを可能にする、I/Oインターフェース214または他の適切な機構だけを含み得る。たとえば、一実施形態では、受動IoTデバイス200Bに関連付けられたI/Oインターフェース214は、短距離インターフェースを介して問い合わされたとき、受動IoTデバイス200Bに関連付けられた識別子および属性を別のデバイス(たとえば、受動IoTデバイス200Bに関連付けられた属性に関する情報を検出すること、記憶すること、通信すること、その情報に作用すること、あるいはその情報を処理することができる、IoTデバイス200Aなどの能動IoTデバイス)に提供することができる、バーコード、Bluetooth(登録商標)インターフェース、無線周波数(RF)インターフェース、RFIDタグ、IRインターフェース、NFCインターフェース、または任意の他の適切なI/Oインターフェースを含み得る。
【００４９】
上記は何らかの形のRF、バーコード、または他のI/Oインターフェース214を有するとして受動IoTデバイス200Bを説明しているが、受動IoTデバイス200Bは、そのようなI/Oインターフェース214を有しないデバイスまたは他の物理的対象物を含み得る。たとえば、あるIoTデバイスは、受動IoTデバイス200Bを識別するために、受動IoTデバイス200Bに関連付けられた形状、サイズ、色、および/もしくは他の観測可能な特徴を検出することができる適切なスキャナ機構またはリーダー機構を有し得る。このようにして、任意の適切な物理的対象物は、その識別および属性を通信することができ、制御されたIoTネットワーク内で観測、監視、制御、あるいは管理され得る。
【００５０】
図3は、機能を実行するように構成された論理を含む通信デバイス300を示す。通信デバイス300は、限定はしないが、IoTデバイス110〜120、IoTデバイス200A、インターネット175に結合された任意の構成要素(たとえば、IoTサーバ170)などを含む、上記の通信デバイスのうちのいずれかに対応し得る。したがって、通信デバイス300は、図1A〜図1Dのワイヤレス通信システム100A〜100Dを介して1つもしくは複数の他のエンティティと通信する(または通信を容易にする)ように構成された任意の電子デバイスに対応し得る。
【００５１】
図3を参照すると、通信デバイス300は、情報を受信および/または送信するように構成された論理305を含む。一例では、通信デバイス300がワイヤレス通信デバイス(たとえば、IoTデバイス200Aおよび/または受動IoTデバイス200B)に対応する場合には、情報を受信および/または送信するように構成された論理305は、ワイヤレストランシーバおよび関連ハードウェア(たとえば、RFアンテナ、モデム、変調器および/または復調器など)のようなワイヤレス通信インターフェース(たとえば、Bluetooth(登録商標)、Wi-Fi、Wi-Fi Direct、Long-Term Evolution (LTE) Directなど)を含むことができる。別の例では、情報を受信および/または送信するように構成された論理305は、有線通信インターフェース(たとえば、インターネット175にアクセスする手段となり得るシリアル接続、USBまたはFirewire接続、Ethernet(登録商標)接続など)に対応することができる。したがって、通信デバイス300が、何らかのタイプのネットワークベースのサーバ(たとえば、IoTサーバ170)に対応する場合には、情報を受信および/または送信するように構成された論理305は、一例では、Ethernet(登録商標)プロトコルによってネットワークベースのサーバを他の通信エンティティに接続するEthernet(登録商標)カードに対応し得る。さらなる例では、情報を受信および/または送信するように構成された論理305は、通信デバイス300がそのローカル環境を監視する手段となり得る感知または測定ハードウェア(たとえば、加速度計、温度センサー、光センサー、ローカルRF信号を監視するためのアンテナなど)を含むことができる。情報を受信および/または送信するように構成された論理305は、実行されるときに、情報を受信および/または送信するように構成された論理305の関連ハードウェアがその受信機能および/または送信機能を実行できるようにするソフトウェアも含むことができる。しかしながら、情報を受信および/または送信するように構成された論理305は、ソフトウェアだけに対応するのではなく、情報を受信および/または送信するように構成された論理305は、その機能性を達成するためのハードウェアに少なくとも部分的に依拠する。
【００５２】
図3を参照すると、通信デバイス300は、情報を処理するように構成された論理310をさらに含む。一例では、情報を処理するように構成された論理310は、少なくともプロセッサを含むことができる。情報を処理するように構成された論理310によって実施され得るタイプの処理の例示的な実装形態は、判断を行うこと、接続を確立すること、異なる情報オプション間で選択を行うこと、データに関係する評価を実施すること、測定動作を実施するために通信デバイス300に結合されたセンサーと対話すること、情報をあるフォーマットから別のフォーマットに(たとえば、.wmvから.aviへなど、異なるプロトコル間で)変換することなどを含むが、これらに限定されない。情報を処理するように構成された論理310中に含まれるプロセッサは、汎用プロセッサ、DSP、ASIC、フィールドプログラマブルゲートアレイ(FPGA)もしくは他のプログラマブル論理デバイス、個別ゲートもしくはトランジスタ論理、個別ハードウェア構成要素、または本明細書において説明される機能を実行するように設計されたそれらの任意の組合せに対応し得る。汎用プロセッサはマイクロプロセッサとすることができるが、代替として、プロセッサは、任意の従来のプロセッサ、コントローラ、マイクロコントローラ、または状態機械とすることができる。プロセッサはまた、コンピューティングデバイスの組合せ(たとえば、DSPおよびマイクロプロセッサの組合せ、複数のマイクロプロセッサ、DSPコアと連携する1つもしくは複数のマイクロプロセッサ、または任意の他のそのような構成)として実現され得る。情報を処理するように構成された論理310は、実行されるとき、情報を処理するように構成された論理310の関連ハードウェアがその処理機能を実行できるようにするソフトウェアも含むことができる。しかしながら、情報を処理するように構成された論理310は、ソフトウェアだけに対応するのではなく、情報を処理するように構成された論理310は、その機能を達成するためにハードウェアに少なくとも部分的に依拠する。
【００５３】
図3を参照すると、通信デバイス300は、情報を記憶するように構成された論理315をさらに含む。一例では、情報を記憶するように構成された論理315は、少なくとも非一時的メモリおよび関連ハードウェア(たとえば、メモリコントローラなど)を含むことができる。たとえば、情報を記憶するように構成された論理315に含まれる非一時的メモリは、RAM、フラッシュメモリ、ROM、消去可能プログラマブルROM(EPROM)、EEPROM、レジスタ、ハードディスク、リムーバブルディスク、CD-ROM、または当該技術分野において知られている任意の他の形の記憶媒体に対応することができる。情報を記憶するように構成された論理315は、実行されるときに、情報を記憶するように構成された論理315の関連ハードウェアがその記憶機能を実行できるようにするソフトウェアも含むことができる。しかしながら、情報を記憶するように構成された論理315は、ソフトウェアだけに対応するのではなく、情報を記憶するように構成された論理315は、その機能を達成するためにハードウェアに少なくとも部分的に依拠する。
【００５４】
通信デバイス300が、IoTネットワークにおいてイベント辞書を自動的に生成するように構成された、スーパーバイザデバイス130などのスーパーバイザデバイスに対応する場合、情報を受信および/または送信するように構成された論理305は、IoTネットワークにおけるIoTデバイスからイベントの通知を受信してもよく、情報を処理するように構成された論理310は、情報を受信および/または送信するように構成された論理305とともに、イベントの前および後のIoTデバイスの状態を判定してもよい。情報を処理するように構成された論理310はまた、IoTデバイスの状態同士を比較し、比較に基づいてイベントの状態変化のタイプを判定し、第1のイベントの状態変化のタイプがイベント辞書内に存在するかどうかを判定してもよい。情報を処理するように構成された論理310は、情報を記憶するように構成された論理315とともに、第1のイベントの状態変化のタイプがイベント辞書内には存在しないことに基づいて汎用エントリを作成してもよく、その場合に、汎用エントリに関連する状態変化のタイプが、このIoTデバイスと同じタイプおよび/またはクラスのIoTデバイスと共通し、情報を記憶するように構成された論理315は、イベントのイベント記述の汎用エントリへのマッピングをイベント辞書に記憶してもよい。
【００５５】
図3を参照すると、通信デバイス300は、情報を提示するように構成された論理320をさらにオプションで含む。一例では、情報を提示するように構成された論理320は、少なくとも出力デバイスおよび関連ハードウェアを含むことができる。たとえば、出力デバイスは、ビデオ出力デバイス(たとえば、ディスプレイスクリーン、USB、HDMI(登録商標)のようなビデオ情報を搬送することができるポートなど)、オーディオ出力デバイス(たとえば、スピーカ、マイクロフォンジャック、USB、HDMI(登録商標)のようなオーディオ情報を搬送することができるポートなど)、振動デバイス、および/または、情報がそれによって出力のためにフォーマットされ得る、または通信デバイス300のユーザもしくは操作者によって実際に出力され得る任意の他のデバイスを含むことができる。たとえば、通信デバイス300が、図2Aに示したIoTデバイス200Aおよび/または図2Bに示した受動IoTデバイス200Bに対応する場合、情報を提示するように構成された論理320は、ディスプレイ226を含み得る。さらなる一例では、情報を提示するように構成された論理320は、ローカルユーザを有しないネットワーク通信デバイス(たとえば、ネットワークスイッチ、またはルータ、リモートサーバなど)のようないくつかの通信デバイスでは省くことができる。情報を提示するように構成された論理320は、実行されるとき、情報を提示するように構成された論理320の関連ハードウェアがその提示機能を実施できるようにするソフトウェアも含むことができる。しかしながら、情報を提示するように構成された論理320は、ソフトウェアだけに対応するのではなく、情報を提示するように構成された論理320は、その機能性を達成するためにハードウェアに少なくとも部分的に依拠する。
【００５６】
図3を参照すると、通信デバイス300は、ローカルユーザ入力を受信するように構成された論理325をさらにオプションで含む。一例では、ローカルユーザ入力を受信するように構成された論理325は、少なくともユーザ入力デバイスおよび関連ハードウェアを含むことができる。たとえば、ユーザ入力デバイスは、ボタン、タッチスクリーンディスプレイ、キーボード、カメラ、オーディオ入力デバイス(たとえば、マイクロフォン、もしくはマイクロフォンジャックなど、オーディオ情報を搬送することができるポートなど)、および/または情報がそれによって通信デバイス300のユーザもしくはオペレータから受信され得る任意の他のデバイスを含み得る。たとえば、通信デバイス300が図2Aに示すようなIoTデバイス200Aおよび/または図2Bに示すような受動IoTデバイス200Bに対応する場合、ローカルユーザ入力を受信するように構成された論理325は、電力ボタン222、制御ボタン224Aおよび224B、ならびにディスプレイ226(タッチスクリーンの場合)などを含み得る。さらなる例では、ローカルユーザ入力を受信するように構成された論理325は、(たとえば、ネットワークスイッチまたはルータ、リモートサーバなど)ローカルユーザを有さないネットワーク通信デバイスのようないくつかの通信デバイスでは省略されることがある。ローカルユーザ入力を受信するように構成された論理325は、実行されるとき、ローカルユーザ入力を受信するように構成された論理325の関連ハードウェアがその入力受信機能を実施できるようにするソフトウェアも含むことができる。しかしながら、ローカルユーザ入力を受信するように構成された論理325は、ソフトウェアだけに対応するのではなく、ローカルユーザ入力を受信するように構成された論理325は、その機能性を達成するためにハードウェアに少なくとも部分的に依拠する。
【００５７】
図3を参照すると、305〜325の構成された論理は、図3では別個のまたは相異なるブロックとして示されているが、それぞれの構成された論理がその機能を実行するためのハードウェアおよび/またはソフトウェアは、部分的に重複できることは理解されよう。たとえば、305〜325の構成された論理の機能を容易にするために使用される任意のソフトウェアを、情報を記憶するように構成された論理315に関連する非一時的メモリに記憶することができ、それにより、305〜325の構成された論理は各々、その機能(すなわち、この場合、ソフトウェア実行)を、情報を記憶するように構成された論理315によって記憶されたソフトウェアの動作に部分的に基づいて実行する。同様に、構成された論理のうちの1つに直接関連付けられるハードウェアは、時々、他の構成された論理によって借用または使用され得る。たとえば、情報を処理するように構成された論理310のプロセッサは、データを、情報を受信および/または送信するように構成された論理305によって送信される前に、適切な形式にフォーマットすることができ、それにより、情報を受信および/または送信するように構成された論理305は、その機能(すなわち、この場合、データの送信)を、情報を処理するように構成された論理310に関連付けられたハードウェア(すなわち、プロセッサ)の動作に部分的に基づいて実行する。
【００５８】
概して、別段に明示的に記載されていない限り、本開示全体にわたって使用される「ように構成された論理」という句は、ハードウェアにより少なくとも部分的に実施される態様を呼び出すものとし、ハードウェアから独立したソフトウェアだけの実施形態に位置づけるものではない。様々なブロックにおける構成された論理または「ように構成された論理」は、特定の論理ゲートまたは論理要素に限定されるのではなく、概して、本明細書に記載した機能性を、(ハードウェアまたはハードウェアとソフトウェアの組合せのいずれかを介して)実施するための能力を指すことが諒解されよう。したがって、様々なブロックに示す構成された論理または「ように構成された論理」は、「論理」という言葉を共有するにもかかわらず、必ずしも論理ゲートまたは論理要素として実装されるとは限らない。様々なブロックの論理間の他のやりとりまたは協働が、以下でより詳細に説明する態様の検討から、当業者には明らかになるであろう。
【００５９】
様々な実施形態は、図4に示すサーバ400などの、様々な市販のサーバデバイスのいずれにおいても実装され得る。一例では、サーバ400は、上記で説明したスーパーバイザデバイス130またはIoTサーバ170の1つの例示的な構成に相当し得る。図4では、サーバ400は、揮発性メモリ402と、ディスクドライブ403などの大容量の不揮発性メモリとに結合されたプロセッサ401を含む。サーバ400は、プロセッサ401に結合された、フロッピー(登録商標)ディスクドライブ、コンパクトディスク(CD)ドライブまたはDVDディスクドライブ406を含むことも可能である。サーバ400は、他のブロードキャストシステムコンピュータおよびサーバに、またはインターネットに結合されたローカルエリアネットワークなどのネットワーク407とのデータ接続を確立するための、プロセッサ401に結合されたネットワークアクセスポート404を含むことも可能である。
【００６０】
サーバ400は、IoTネットワークにおけるデバイス間通信プロトコルに関するイベント辞書を自動的に生成するように構成される場合、本明細書において説明する機能を実行するかまたは実行させるように構成されたEMDGモジュール410を含んでもよい。EMDGモジュール410は、ハードウェアモジュールであっても、または実行可能なソフトウェアモジュールであっても、またはハードウェアとソフトウェアの組合せであってもよい。例示的な実施形態では、ネットワークアクセスポート404は、IoTネットワークにおけるIoTデバイスからイベントの通知を受信してもよく、プロセッサ401/EMDGモジュール410は、ネットワークアクセスポート404とともに、イベントの前および後のIoTデバイスの状態を判定してもよい。プロセッサ401/EMDGモジュール410はまた、IoTデバイスの状態同士を比較し、比較に基づいてイベントの状態変化のタイプを判定し、第1のイベントの状態変化のタイプがイベント辞書内に存在するかどうかを判定してもよい。プロセッサ401/EMDGモジュール410は、ディスクドライブ403とともに、第1のイベントの状態変化のタイプがイベント辞書内には存在しないことに基づいて汎用エントリを作成してもよく、その場合に、汎用エントリに関連する状態変化のタイプが、このIoTデバイスと同じタイプおよび/またはクラスのIoTデバイスと共通し、ディスクドライブ403は、イベントのイベント記述の汎用エントリへのマッピングをイベント辞書に記憶してもよい。
【００６１】
図3の文脈において、図4のサーバ400は、通信デバイス300の1つの例示的な実装形態を示すが、情報を受信および/または送信するように構成された論理305は、ネットワーク407と通信するためにサーバ400によって使用されるネットワークアクセスポイント404に対応し、情報を処理するように構成された論理310は、プロセッサ401に対応し、EMDGモジュール410がハードウェアモジュールである場合にはEMDGモジュール410に対応し、情報を記憶するように構成された論理315は、揮発性メモリ402、ディスクドライブ403、ディスクドライブ406の任意の組合せに対応し、EMDGモジュール410が実行可能なソフトウェアモジュールである場合にはEMDGモジュール410に対応することが諒解されよう。情報を提示するように構成されたオプションの論理320およびローカルユーザ入力を受信するように構成されたオプションの論理325は、図4には明示的に示さず、その中に含まれる場合もあれば、含まれない場合もある。したがって、図4は、通信デバイス300が、図2Aに示すようなIoTデバイスの実装形態に加えてサーバとして実装され得ることを説明するのを助ける。
【００６２】
概して、電話、タブレットコンピュータ、ラップトップコンピュータおよびデスクトップコンピュータ、特定の車両などのユーザ機器(UE)は、互いに(たとえば、Bluetooth(登録商標)、ローカルWi-Fiなどによって)ローカルに接続するかまたは(たとえば、セルラーネットワーク、インターネットなどを介して)リモートに接続するように構成されてもよい。さらに、いくつかのUEは、デバイスが1対1の接続を確立するかまたは互いに直接通信するためにいくつかのデバイスを含むグループに同時に接続するのを可能にする特定のワイヤレスネットワーキング技法(たとえば、Wi-Fi、Bluetooth(登録商標)、Wi-Fi Directなど)を使用する近接度ベースのピアツーピア(P2P)通信をサポートしてもよい。そのために、図5は、発見可能なP2Pサービスをサポートすることができる例示的なワイヤレス通信ネットワークまたはWAN500を示す。たとえば、一実施形態では、ワイヤレス通信ネットワーク500は、様々な基地局510と他のネットワークエンティティとを含むLTEネットワークまたは別の適切なWANを備えてもよい。簡単のために、図5には、3つの基地局510a、510bおよび510c、1つのネットワークコントローラ530、ならびに1つのダイナミックホストコンフィギュレーションプロトコル(DHCP)サーバ540のみを示す。基地局510は、デバイス520と通信するエンティティであってもよく、Node B、evolved Node B(eNB)、アクセスポイントなどとも呼ばれることがある。各基地局510は、特定の地理的エリアに対して通信カバレージを実現し得、カバレージエリア内に位置するデバイス520のための通信をサポートし得る。ネットワーク容量を向上させるために、基地局510の全体的なカバレージエリアが複数の(たとえば、3つの)より小さいエリアに区分されてもよく、各々のより小さいエリアがそれぞれの基地局510によってサービスされてもよい。3GPPでは、「セル」という用語は、この用語が使用される状況に応じて、このカバレッジエリアにサービスしている基地局510および/または基地局サブシステム510のカバレッジエリアを指し得る。3GPP2では、「セクタ」または「セルセクタ」という用語は、このカバレッジエリアにサービスしている基地局510および/または基地局510のカバレッジエリアを指し得る。明確にするために、本明細書の説明では3GPPの「セル」の概念が使用されることがある。
【００６３】
基地局510は、マクロセル、ピコセル、フェムトセル、および/または他のセルタイプの通信カバレッジを可能にすることができる。マクロセルは、比較的大きい地理的エリア(たとえば、半径数キロメートル)をカバーすることができ、サービスに加入しているデバイス520による無制限アクセスを可能にし得る。ピコセルは、比較的小さい地理的エリアをカバーすることができ、サービスに加入しているデバイス520による無制限アクセスを可能にし得る。フェムトセルは、比較的小さい地理的エリア(たとえば、家庭)をカバーすることができ、フェムトセルとの関連付けを有するデバイス520(たとえば、限定加入者グループ(CSG)中のデバイス)による限定アクセスを可能にし得る。図5に示す例では、ワイヤレス通信ネットワーク500は、マクロセルのためのマクロ基地局510a、510b、および510cを含む。ワイヤレス通信ネットワーク500は、ピコセルのためのピコ基地局510および/またはフェムトセルのためのホーム基地局510(図5には示されていない)も含み得る。
【００６４】
ネットワークコントローラ530は、基地局510のセットに結合することができ、これらの基地局510の調整および制御を行うことができる。ネットワークコントローラ530は、バックホールを介して基地局と通信することができる単一のネットワークエンティティまたはネットワークエンティティの集合であってもよい。また、基地局510は、たとえば、直接またはワイヤレスバックホールまたはワイヤラインバックホールを介して間接的に、互いに通信し得る。DHCPサーバ540は、以下に説明するように、P2P通信をサポートすることができる。DHCPサーバ540は、ワイヤレス通信ネットワーク500の一部であっても、またはインターネット接続共有(ICS)を介して実行されるワイヤレス通信ネットワーク500の外部のサーバであっても、またはそれらの任意の適切な組合せであってもよい。DHCPサーバ540は、(図5に示されるように)別個のエンティティであってよく、または、基地局510、ネットワークコントローラ530、もしくは他の何らかのエンティティの一部であってもよい。いずれの場合も、DHCPサーバ540は、ピアツーピアの通信を望むデバイス520によって到達可能であり得る。
【００６５】
デバイス520はワイヤレス通信ネットワーク500全体にわたって分散され得、各デバイス520は固定されてもまたは移動可能であってもよい。デバイス520はまた、ノード、ユーザ機器(UE)、局、移動局、端末、アクセス端末、加入者ユニットなどと呼ばれ得る。デバイス520は、セルラー電話、携帯情報端末(PDA)、ワイヤレスモデム、ワイヤレス通信デバイス、ハンドヘルドデバイス、ラップトップコンピュータ、コードレス電話、ワイヤレスローカルループ(WLL)局、スマートフォン、ネットブック、スマートブック、タブレットなどであってよい。デバイス520は、ワイヤレス通信ネットワーク500内の基地局510と通信してもよく、さらに他のデバイス520とピアツーピア通信してもよい。たとえば、図5に示すように、デバイス520aとデバイス520bがピアツーピア通信してもよく、デバイス520cとデバイス520dがピアツーピア通信してもよく、デバイス520eとデバイス520fがピアツーピア通信してもよく、デバイス520gとデバイス520hとデバイス520iがピアツーピア通信し、一方、残りのデバイス520が基地局510と通信してもよい。さらに図5に示すように、デバイス520a、520d、520f、および520hは、たとえば、P2P通信を行っていないときに基地局510と通信するか、または場合によってはP2P通信と同時に基地局510と通信してもよい。
【００６６】
本明細書の説明では、WAN通信は、たとえば別のデバイス520などのリモートエンティティと通話するための、ワイヤレス通信ネットワーク500におけるデバイス520と基地局510との間の通信を指し得る。WANデバイスは、WAN通信に関心を持っているか、WAN通信に関与しているデバイス520である。P2P通信は、基地局510を介さない、2つ以上のデバイス520間の直接通信を指す。P2Pデバイスは、P2P通信に関心を持っているかまたはP2P通信に関与しているデバイス520、たとえば、P2Pデバイスの近傍内の別のデバイス520に関するトラフィックデータを有するデバイス520である。2つのデバイスは、たとえば、各デバイス520が他のデバイス520を検出できる場合、互いに近傍に位置すると見なされてもよい。概して、デバイス520は、別のデバイス520と、P2P通信の場合は直接通信してもよく、WAN通信の場合は少なくとも1つの基地局510を介して通信してもよい。
【００６７】
一実施形態では、デバイス520間の直接通信はP2Pグループとして構成されてもよい。より詳細には、P2Pグループは概して、P2P通信に関心を持っているか、またはP2P通信に関与している2つ以上のデバイス520のグループを指し、P2Pリンクは、P2Pグループ用の通信リンクを指す。さらに、一実施形態では、P2Pグループは、P2Pグループオーナー(またはP2Pサーバ)と指定される1つのデバイス520と、P2PグループオーナーによってサービスされるP2Pクライアントと指定される1つまたは複数のデバイス520とを含んでもよい。P2Pグループオーナーは、WANとのシグナリングの交換、P2PグループオーナーとP2Pクライアントとの間のデータ送信の調整などのような、いくつかの管理機能を実行することができる。たとえば、図5に示すように、第1のP2Pグループは、基地局510aの対象となるデバイス520aおよび520bを含み、第2のP2Pグループは、基地局510bの対象となるデバイス520cおよび520dを含み、第3のP2Pグループは、異なる基地局510bおよび510cの対象となるデバイス520eおよび520fを含み、第4のP2Pグループは、基地局510cの対象となるデバイス520g、520h、および520iを含む。デバイス520a、520d、520f、および520hは、そのそれぞれのP2PグループにおけるP2Pグループオーナーであってもよく、デバイス520b、520c、520e、520g、および520iは、そのそれぞれのP2PグループにおけるP2Pクライアントであってもよい。図5の他のデバイス520は、WAN通信に関与していてもよい。
【００６８】
実施形態では、P2P通信は、P2Pグループ内でのみ行われ、かつ、P2Pグループに関連するP2PグループオーナーとP2Pクライアントとの間でのみ行われる。たとえば、同じP2Pグループ内の2つのP2Pクライアント(たとえば、デバイス520gおよび520i)が情報を交換することを望む場合、P2Pクライアントの一方がP2Pグループオーナー(たとえば、デバイス520h)に情報を送ってもよく、次いでP2Pグループオーナーが送信を他のP2Pクライアントに中継してもよい。一実施形態では、特定のデバイス520は、複数のP2Pグループに属してもよく、各P2Pグループ内でP2PグループオーナーまたはP2Pクライアントのいずれかとして振る舞ってもよい。さらに、一実施形態では、特定のP2Pクライアントは、1つのP2Pグループのみに属するかまたは複数のP2Pグループに属し、任意の特定の瞬間に複数のP2Pグループのいずれかにおけるデバイス520と通信してもよい。概して、通信は、ダウンリンクおよびアップリンク上での送信を通じて促進され得る。WAN通信では、ダウンリンク(または順方向リンク)は基地局510からデバイス520への通信リンクを指し、アップリンク(または逆方向リンク)はデバイス520から基地局510への通信リンクを指す。P2P通信では、P2PダウンリンクはP2PグループオーナーからP2Pクライアントへの通信リンクを指し、P2PアップリンクはP2PクライアントからP2Pグループオーナーへの通信リンクを指す。いくつかの実施形態では、2つ以上のデバイスが、WAN技法を使用してP2P通信するのではなく、Wi-Fi、Bluetooth(登録商標)、またはWi-Fi Directなどの技法を使用してより小さいP2Pグループを形成してワイヤレスローカルエリアネットワーク(WLAN)上でP2P通信してもよい。たとえば、Wi-Fi、Bluetooth(登録商標)、Wi-Fi Direct、またはその他のWLAN技法を使用するP2P通信では、2つ以上のモバイルフォン、ゲームコンソール、ラップトップコンピュータ、またはその他の適切な通信エンティティ間のP2P通信を可能にすることができる。
【００６９】
図6は、本開示の一態様による、様々なデバイス610、630、640が通信するのに利用することができる近接度ベースの分散バス625を確立するために発見可能なP2Pサービスを使用し得る例示的な環境600を示す。たとえば、一実施形態では、ネットワーク化コンピューティング環境におけるアプリケーション間通信を有効化するのに使用されるソフトウェアバスを含んでもよい分散バス625を介したプロセス間通信プロトコル(IPC)フレームワークを使用して単一のプラットフォーム上でのアプリケーション同士などの間の通信を容易にすることができ、この場合、ネットワーク化コンピューティング環境におけるアプリケーション間通信では、各アプリケーションが分散バス625に登録して他のアプリケーションにサービスを提供し、他のアプリケーションが登録されているアプリケーションに関する情報を分散バス625に問い合わせる。そのようなプロトコルは、信号メッセージ(たとえば、通知)がポイントツーポイントメッセージであってもまたはブロードキャストメッセージであってもよく、メソッド呼出しメッセージ(たとえば、RPC)が同期メッセージであってもまたは非同期メッセージであってもよく、分散バス625(たとえば、「デーモン」バスプロセス)が様々なデバイス610、630、640間のメッセージルーティングに対処することができる、非同期通知およびリモートプロシージャ呼出し(RPC)を可能にすることができる。
【００７０】
一実施形態では、分散バス625は、様々なトランスポートプロトコル(たとえば、Bluetooth(登録商標)、TCP/IP、Wi-Fi、CDMA、GPRS、UMTSなど)によってサポートされてもよい。たとえば、一態様によれば、第1のデバイス610は、分散バスノード612と1つまたは複数のローカルエンドポイント614とを含んでもよく、分散バスノード612は、第1のデバイス610に関連するローカルエンドポイント614と第2のデバイス630および第3のデバイス640に関連するローカルエンドポイント634および644との間の、分散バス625を通じた(たとえば、第2のデバイス630および第3のデバイス640上の分散バスノード632および642を介した)通信を容易にすることができる。図7を参照しながら以下にさらに詳細に説明するように、分散バス625は、対称的マルチデバイスネットワークトポロジーをサポートしてもよく、デバイスドロップアウトの存在下でロバストな動作を可能にしてもよい。したがって、分散バス625は、概して任意の下位トランスポートプロトコル(たとえば、Bluetooth(登録商標)、TCP/IP、Wi-Fiなど)とは無関係であってもよく、非セキュア(たとえば、オープン)からセキュア(たとえば、認証または暗号化)まで様々なセキュリティオプションを実現することができ、セキュリティオプションは、第1のデバイス610、第2のデバイス630、および第3のデバイス640間の自発的な接続を容易にしつつ、様々なデバイス610、630、640が互いの範囲に入るかまたは互いに近接したときに介入せずに使用され得る。
【００７１】
図7は、本開示の一態様による、第1のデバイス(「デバイスA」)710および第2のデバイス(「デバイスB」)730が通信するのに利用することができる近接度ベースの分散バスを確立するために発見可能なP2Pサービスを使用し得る例示的なメッセージシーケンス700を示す。概して、デバイスAは、デバイスBとの通信を要求してもよく、デバイスAは、そのような通信を容易にするのを助けることができるバスノード712に加えて通信の要求を出し得るローカルエンドポイント714(たとえば、ローカルアプリケーション、サービスなど)を含んでもよい。さらに、デバイスB 730は、ローカルエンドポイント714が、デバイスA 710上のローカルエンドポイント714とデバイスB 730上のローカルエンドポイント734との間の通信を容易にするのを助けることができるバスノード732に加えて通信を試み得るローカルエンドポイント734を含んでもよい。
【００７２】
一実施形態では、メッセージシーケンスステップ754において、バスノード712および732は適切な発見機構を実行してもよい。たとえば、Bluetooth(登録商標)、TCP/IP、UNIX(登録商標)などによってサポートされる接続を発見するための機構が使用されてもよい。メッセージシーケンスステップ756において、デバイスB 730上のローカルエンドポイント734は、バスノード732を通じて利用可能なエンティティ、サービス、エンドポイントなどに接続することを要求してもよい。一実施形態では、この要求は、ローカルエンドポイント734とバスノード732との間の要求応答プロセスを含んでもよい。メッセージシーケンスステップ758において、分散メッセージバスが、バスノード732をバスノード712に接続し、それによってデバイスA 710とデバイスB 730との間のP2P接続を確立するように形成されてもよい。一実施形態では、バスノード712とバスノード732との間に分散バスを形成するための通信は、近接度ベースのP2Pプロトコル(たとえば、接続された製品間の相互運用性を実現するように設計されたAllJoyn(登録商標)ソフトウェアフレームワークおよび近位ネットワークを動的に作成し近位P2P通信を容易にするための様々な製造業者によるソフトウェアアプリケーション)を使用して容易にされてもよい。代替として、一実施形態では、サーバ(図示せず)はバスノード712とバスノード732との間の接続を容易にしてもよい。さらに、一実施形態では、バスノード712とバスノード732との間に接続を形成する前に適切な認証機構が使用されてもよい(たとえば、クライアントが認証コマンドを送って認証対話を開始することができるSASL認証)。さらに、メッセージシーケンスステップ758の間、バスノード712および732は、利用可能な他のエンドポイント(たとえば、図6のデバイスC 640上のローカルエンドポイント644)に関する情報を交換してもよい。そのような実施形態では、バスノードが維持する各ローカルエンドポイントが他のバスノードに通知されてもよく、この通知は、一意のエンドポイント名、トランスポートタイプ、接続パラメータ、または他の適切な情報を含んでもよい。
【００７３】
一実施形態では、メッセージシーケンスステップ760において、バスノード712およびバスノード732は、それぞれローカルエンドポイント734および714に関連する得られた情報を使用して、様々なバスノードを通じて利用可能な得られた実エンドポイントを表すことのできる仮想エンドポイントを作成してもよい。一実施形態では、バスノード712上のメッセージルーティングでは、実エンドポイントおよび仮想エンドポイントを使用してメッセージを送信してもよい。さらに、リモートデバイス(たとえば、デバイスA 710)上に存在するあらゆるエンドポイントに1つのローカル仮想エンドポイントがあってもよい。さらに、そのような仮想エンドポイントは、分散バス(たとえば、バスノード712とバスノード732との間の接続)を介して送られたメッセージを多重化しならびに/あるいは多重化解除してもよい。一態様では、仮想エンドポイントは、実エンドポイントと同様にローカルバスノード712または732からメッセージを受信してもよく、分散バスを介してメッセージを転送してもよい。したがって、仮想エンドポイントは、エンドポイント多重化分散バス接続からローカルバスノード712および732へメッセージを転送してもよい。さらに、一実施形態では、リモートデバイス上の仮想エンドポイントに対応する仮想エンドポイントは、任意の時点で特定のトランスポートタイプの所望のトポロジーに対処するように再接続されてもよい。そのような態様では、UNIX(登録商標)ベースの仮想エンドポイントは、ローカルと見なされることがあり、したがって、再接続の候補とは見なされないことがある。さらに、TCPベースの仮想エンドポイントは、1つのホップルーティングに関して最適化されてもよい(たとえば、各バスノード712および732は互いに直接接続されてもよい)。さらに、Bluetooth(登録商標)ベースの仮想エンドポイントは、Bluetooth(登録商標)ベースのマスタがローカルマスタノードと同じバスノードであってもよい単一ピコネット(たとえば、1つのマスタおよびn個のスレーブ)に関して最適化されてもよい。
【００７４】
メッセージシーケンスステップ762において、バスノード712とバスノード732は、762においてバス状態情報を交換してバスインスタンス同士をマージし、分散バスを介した通信を可能にしてもよい。たとえば、一実施形態では、バス状態情報は、周知の一意のエンドポイント名マッピング、整合規則、ルーティンググループ、または他の適切な情報を含んでもよい。一実施形態では、状態情報は、分散バスベースのローカル名と通信するローカルエンドポイント714および734とのインターフェースを使用してバスノード712インスタンスとバスノード732インスタンスとの間で伝達されてもよい。別の態様では、バスノード712およびバスノード732の各々は、分散バスへのフィードバックを可能にする役割を果たすローカルバスコントローラを維持してもよく、バスコントローラは、グローバルメソッド、引数、信号、およびその他の情報を分散バスに関連する規格に変換してもよい。メッセージシーケンスステップ764において、バスノード712およびバスノード732は、上述のようなバスノードノード接続の間に導入されるあらゆる変化に関してそれぞれのローカルエンドポイント714および734に通知する信号を伝達(たとえば、ブロードキャスト)してもよい。一実施形態では、新しいおよび/または削除されたグローバル名および/または変換後の名前が、名前オーナー変更後信号によって示されてもよい。さらに、(たとえば、名前衝突に起因して)ローカルに失われることがあるグローバル名が名前喪失信号によって示されてもよい。さらに、名前衝突に起因して転送されるグローバル名が名前オーナー変更後信号によって示されてもよく、バスノード712およびバスノード732が切り離された場合および/またはときに消える一意の名前が名前オーナー変更後信号によって示されてもよい。
【００７５】
上記に使用されたように、周知の名前を使用してローカルエンドポイント714および734を一意に記述してもよい。一実施形態では、デバイスA 710とデバイスB 730との間で通信が行われるとき、異なる周知の名前タイプが使用されてもよい。たとえば、バスノード712が直接接続されるデバイスA 710に関連するバスノード712上にのみデバイスローカル名が存在してもよい。別の例では、すべての既知のバスノード712および732上にグローバル名が存在してもよく、すべてのバスセグメント上に存在してもよい名前のオーナーは1人だけである。言い換えれば、バスノード712とバスノード732が連結され、衝突が起こると、オーナーのうちの1人がグローバル名を失うことがある。さらに別の例では、クライアントが仮想バスに関連する他のバスノードに接続されるときに変換後の名前が使用されてもよい。そのような態様では、変換後の名前はアペンデッドエンドを含んでもよい(たとえば、グローバルに一意の識別子「1234」を有する分散バスに接続された周知の名前「org.foo」を有するローカルエンドポイント714は「G1234.org.foo」と見なされてもよい)。
【００７６】
メッセージシーケンスステップ766において、バスノード712およびバスノード732は、エンドポイントバストポロジーの変更について他のバスノードに通知するための信号を伝達(たとえば、ブロードキャスト)してもよい。その後、ローカルエンドポイント714からのトラフィックは、仮想エンドポイントを通過してデバイスB 730上の意図されるローカルエンドポイント734に達してもよい。さらに、動作中に、ローカルエンドポイント714とローカルエンドポイント734との間の通信はルーティンググループを使用してもよい。一態様では、ルーティンググループは、エンドポイントが信号、メソッド呼出し、またはエンドポイントのサブセットからの他の適切な情報を受信するのを可能にしてもよい。したがって、ルーティング名は、バスノード712または732に接続されたアプリケーションによって決定されてもよい。たとえば、P2Pアプリケーションは、アプリケーションに組み込まれた一意で周知のルーティンググループ名を使用してもよい。さらに、バスノード712および732は、ローカルエンドポイント714および734のルーティンググループへの登録および/または登録解除をサポートしてもよい。一実施形態では、ルーティンググループは、現在のバスインスタンスよりも後のインスタンスまで持続しなくてもよい。別の態様では、アプリケーションは、分散バスに接続するたびにアプリケーションの好ましいルーティンググループの登録をしてもよい。さらに、ルーティンググループはオープンであっても(たとえば、任意のエンドポイントが参加してよい)またはクローズドであっても(たとえば、グループの作成者がグループを修正してもよい)よい。さらに、バスノード712または732は、他のリモートバスノードにルーティンググループエンドポイントの追加、削除、またはその他の変更を通知するための信号を送ってもよい。そのような実施形態では、バスノード712または732は、グループにメンバーが追加されならびに/あるいはグループからメンバーが削除されたときはいつでも他のグループメンバーにルーティンググループ変更信号を送ってもよい。さらに、バスノード712または732は、最初にルーティンググループから削除されることなく分散バスから切り離されるエンドポイントにルーティンググループ変更信号を送ってもよい。
【００７７】
近い将来には、IoT技術の増大する開発により、自宅で、車両内で、職場で、および他の多くの場所で、数多くのIoTデバイスがユーザを取り囲むことになる。IoTは、成長するにつれて、様々なIoTデバイスが、相互作用し、相互に理解されるマシンツーマシン(M2M)イベントを送信/受信することによってアクションを講じるのを可能にする機構をサポートするうえでますます重要になっている。従来、この場合、デバイス製造業者(または集合的に、所与のデバイスクラスに関する製造業者のセット)がイベント辞書を定義し、グローバルにアクセス可能な何らかの手段、たとえば、M2Mイベント辞書のグローバルデータベースを介して公開する必要がある。しかし、この場合、関与する様々なIoT当事者間において顕著な程度の協働が必要であり、かつM2M対話に関するグローバルにアクセス可能なインフラストラクチャが必要であるが、これは望ましい解決策ではない。
【００７８】
したがって、本開示では、様々なIoTベンダー間の事前の協働なしに分散IoTネットワークにおいてM2Mイベント辞書を自動的に生成するための機構を提供する。次いで、そのような辞書をIoTデバイスに配信してIoTデバイスがM2Mイベントを理解しそれらのイベントに基づくアクションを講じるのを可能にする。
【００７９】
所与のIoTネットワークは、同様の機能を実現するそれぞれに異なるベンダーによる複数のIoTデバイスを含むことができる。たとえば、ホームIoTネットワークは、2つの異なるベンダーによる窓センサーを含んでもよい。これらのIoTデバイスは、相互運用性のために窓センサーインターフェースなどの同じP2Pサービスインターフェースを実現してもよい。しかし、IoTデバイスは、エンドユーザに対して同じ意味を有するそれぞれに異なるテキスト記述を使用して同様のイベント/状態遷移を定義する場合がある。たとえば、関連する窓が閉じている場合に、2つの窓センサーが「窓が閉じている(closed)」イベントおよび「窓が閉じている(shut)」イベントを有する場合がある。
【００８０】
別のIoTデバイスが、ブロードキャストされたイベントに基づくアクションを講じることを望む場合、このIoTデバイスは、それぞれに異なる記述を有する2つのイベントが実際には同じタイプのイベントであると解釈できる必要がある。引き続き窓センサーの例によって説明する。HVACシステムは、窓が閉じていることを示すイベントを検出したときには「オン」になるべきであるという規則が設けられる場合がある。したがって、複数の同様のイベントを単一のイベントにマップすることができる共通のM2Mイベント辞書を生成することが望ましい。たとえば、「窓が閉じている(closed)」イベントおよび「窓が閉じている(shut)」イベントが単一の汎用イベントにマッピングされる。
【００８１】
所与のIoTネットワークにおけるIoTデバイスは概して、そのネットワークにおける他のIoTデバイスによってブロードキャストされるM2Mイベントのみに基づくアクションを講じる。したがって、これらのIoTデバイスには、IoTデバイスのグローバルな母集団に関するイベント辞書ではなくそのネットワークにおける他のIoTデバイスからのイベントに関するイベント辞書のみが必要である。したがって、局在化されたM2Mイベント辞書を生成することができる限り、所与のIoTネットワークにおけるIoTデバイスはその辞書に基づくアクションを講じることができる。
【００８２】
各IoTネットワークは、M2Mイベント辞書を分散的に生成する問題に対処する、IoTネットワーク自体の局在化されたM2Mイベント辞書を生成することができる。これによって、M2Mイベント辞書を維持/共有するための任意の集中型インフラストラクチャが不要になる。
【００８３】
M2Mイベント辞書を自動的に生成するには、EMDGモジュール210/410などのイベントモニタおよび辞書ジェネレータ(EMDG)構成要素を、IoTネットワークにおけるIoTデバイスからのブロードキャストされるすべてのイベントを監視する分散IoTネットワークに設置することができる。EMDG構成要素は、スーパーバイザデバイス130、IoT SuperAgent140、またはゲートウェイ145などのIoTネットワークのゲートウェイ上に設置することができる。一態様では、イベントをこの構成要素によって受信されるようにブロードキャストすることができる。代替態様では、イベントがパブリッシュ/サブスクライブモデルを使用して共有される場合、この構成要素は、イベントをブロードキャストするすべてのIoTデバイスにサブスクライブする。EMDG構成要素は、IoTデバイスからの発見アナウンスメントに基づいてイベントブロードキャスタ(たとえば、イベントをブロードキャストするIoTデバイス)を発見することができる。
【００８４】
EMDG構成要素は、ネットワーク上の様々なIoTデバイスに関するデバイスクラス/タイプを認識してもよい。たとえば、EMDG構成要素は、窓センサーXおよび窓センサーYが同じデバイスクラス/タイプに属することを認識している。この情報は、IoTデバイスからの発見アナウンスメントから学習することもできる。
【００８５】
EMDG構成要素は、イベントがブロードキャストされる前およびブロードキャストされた後にIoTデバイスの状態を監視する。EMDG構成要素は、ブロードキャスト前の状態とブロードキャスト後の状態を比較し、イベントを状態変化、すなわちシステム値の変化と相関付けることができる。再び窓センサーの例を参照する。EMDG構成要素は、「窓が閉じている(closed)」イベントの前および後の第1の窓センサーの状態を比較し、「窓が閉じている(shut)」イベントの前および後の第2の窓センサーの状態を比較することができる。EMDG構成要素は、状態変化に基づいて、そのクラス/タイプのIoTデバイスに関してこの2つのイベントをM2Mイベント辞書エントリにおける単一の汎用M2Mイベントにマッピングすることができる。
【００８６】
引き続き窓センサーの例について説明する。EMDG構成要素は、第1の窓センサーから「窓が閉じている(closed)」イベントを受信した後、「窓が閉じている(closed)」イベントの前の第1の窓センサーの状態(たとえば、「開」)を「窓が閉じている(closed)」イベントが発生した後の第1の窓センサーの状態(たとえば、「閉」)と比較することができ、このイベントを「開」から「閉」への窓状態への変化にマッピングすることができる。EMDG構成要素は、そのデバイスクラス/タイプおよび検出された状態変化に関する汎用/共通イベントエントリを作成、そのエントリに「1:窓は現在閉じている」などの計数およびテキスト記述を割り当てることができる。
【００８７】
EMDG構成要素は、汎用イベントの実際の状態変化へのマッピングを維持することもできる。たとえば、文字列「1:窓は現在閉じている」は、「開」の状態変化を「閉」にマッピングする。すなわち、EMDG構成要素は、検出されたイベントの近くで生じた状態変化を記述する汎用エントリを作成し、次いで、その汎用エントリを窓センサーから受信された特定のイベントにマッピングする。
【００８８】
「窓が閉じている(shut)」イベントが第2の窓センサーから受信されると、EMDG構成要素は、そのイベントをそのデバイスクラス/タイプに関してすでに作成されている汎用/共通イベント、すなわち、「1:窓は現在閉じている」に、汎用イベントに関する状態変化と一致する観測された状態変化に基づいてマッピングする。EMDG構成要素は、汎用/共通イベントのブロードキャストされた実際のデバイスイベントへのマッピングを維持し、すなわち、「1:窓は現在閉じている」は「窓が閉じている(closed)」イベントおよび「窓が閉じている(shut)」イベントにマッピングされる。したがって、EMDG構成要素は、「1:窓は現在閉じている」および「2:窓は現在開いている」などの窓センサーデバイスクラスに関する汎用/共通M2Mイベント辞書を作成することができる。
【００８９】
IoTデバイスの状態を監視するEMDG構成要素をより詳細に参照する。EMDG構成要素は、デバイスの現在の状態情報を取得するためにデバイスを周期的にポーリングすることができる。イベントを検出した後、EMDG構成要素は、イベント後のIoTデバイスの状態を取得するためにIoTデバイスを再びポーリングすることができる。いくつかのIoTデバイスは、イベントの前および後のIoTデバイスのシステム状態をロギングするサービスを提供してもよい。そのようなサービスは、EMDG構成要素によってアクティブ化することができ、それによって、EMDG構成要素は、所与のIoTデバイスからイベントを受信したときにイベントの前および後のデバイス状態を取り込むことができる。
【００９０】
EMDG構成要素は、IoTネットワーク上のIoTデバイスによってイベントがブロードキャストされたときに、イベントについて学習し、汎用イベント辞書エントリを生成する。この自己学習プロセスにはいくらか時間がかかる。この自己学習段階を促進するには、IoTデバイスがサポートするすべてのイベントをブロードキャストし、それらのイベントに関する状態変化をシミュレートする「イベントブロードキャストモード」などの特殊モードを有するように各IoTデバイスを設計することができる。これによって、M2Mイベントに関する自己学習/自動生成態様が促進される。このモードは、IoTデバイスが搭載プロセスの一部としてネットワーク上に搭載された直後にトリガすることができる。
【００９１】
M2Mイベント辞書をホームオートメーションに使用することができる。詳細には、汎用M2Mイベント辞書に基づいてホームオートメーション規則を定義することができる。このことは、ユーザが様々なベンダーに対してオートメーション規則を調整する必要がないのでユーザエクスペリエンスの観点から最も望ましい。EMDG構成要素は、生成された汎用M2Mイベント辞書、および場合によっては、実際のIoTデバイスイベントマッピングをIoTネットワークにおける他のノードに送出することができる。たとえば、EMDG構成要素は、ホームオートメーション規則を定義するためのUIを実現する制御アプリケーションならびにブロードキャストされたイベントに基づくアクションを講じることを望むIoTデバイスにM2Mイベント辞書を送信することができる。これらのIoTデバイスは、ホームオートメーション規則における汎用M2M辞書に基づくアクションを講じるようにプログラムすることができる。ブロードキャストされた実際のイベントは、受信されたときに、所望のアクションを講じるための汎用M2Mイベントにマッピングされる。
【００９２】
上述の機構は自己学習機構である。IoTネットワークに新しいIoTデバイスが追加されると、EMDG構成要素は、新しいIoTデバイスからのブロードキャストされたイベントをすでに定義されている汎用M2Mイベント辞書エントリにマッピングするか、またはそのデバイスクラスに関する汎用M2Mイベント辞書エントリの新しいセットを生成する。上述のように、新しいIoTデバイスからのイベントのマッピングは、そのイベントの前および後に観測された状態変化に基づいて行われる。
【００９３】
次に、本開示のこれらの態様およびその他の態様について図8を参照して説明する。図8は、本開示の少なくとも1つの態様による例示的な近位IoTネットワーク800を示す。IoTネットワーク800は、ゲートウェイエージェント802と、(EMDGモジュール210/410に対応する場合がある)EMDG804と、制御アプリケーション806と、4つのIoTデバイス810とを含む。ゲートウェイエージェント802は、たとえば、スーパーバイザデバイス130、SuperAgent140、またはゲートウェイ145上にインストールされてもよい。図8では、円で囲まれた参照符号は動作の順序を示す。
【００９４】
動作1において、参照符号810によって識別されるデバイス3および4は、EMDG804によって検出されたイベント通知をブロードキャストする。上述のように、デバイス3および4は、イベントをブロードキャストしてもよく、その場合、EMDG804は、ブロードキャストを遮断してもよく、あるいはIoTネットワーク800における各デバイス810によってパブリッシュされたイベントにサブスクライブしてもよい。動作2において、EMDG804は、イベントがブロードキャストされる前およびブロードキャストされた後のデバイス3および4の状態を取り込み比較する。上述のように、EMDGはイベントの前および後にデバイスからデバイス状態情報を取り込む。動作3において、EMDG804は、イベントの前および後のデバイス状態に基づいて汎用M2Mイベントマッピングを作成する。
【００９５】
動作4において、EMDG804は、M2M汎用イベント辞書を制御アプリケーション806に送信し、制御アプリケーション806は、たとえば、ユーザのスマートフォンまたはスーパーバイザデバイス130上にインストールされてもよい。動作4においても、EMDG804は、参照符号810によって識別されるデバイス1および2などの、IoTネットワーク800における他のデバイス810に、M2M汎用イベント辞書を送信する。さらに、制御アプリケーション806およびデバイス810は、たとえば、起動時にM2M汎用イベント辞書を取り込むことによって、EMDG804からM2M汎用イベント辞書を取り込むことができる。
【００９６】
動作5において、ユーザが、制御アプリケーション806を使用して汎用M2Mイベント辞書に基づいてホームオートメーション(HA)規則を定義してもよい。ホームオートメーション規則が汎用M2Mイベント辞書を使用して定義されるので、ユーザには汎用イベントを示すだけでよく、複数のベンダーからの様々な種類の同様のイベントを示す必要はない。これによって、ホームオートメーション規則を作成するためのユーザエクスペリエンスが大幅に簡略化される。
【００９７】
動作6において、制御アプリケーション806は、ホームオートメーション規則をデバイス1および2などのIoTネットワーク800における他のデバイス810まで伝搬させる。図8は、ホームオートメーション規則を2つのデバイスのみに伝搬するように示しているが、規則は、すべてのデバイス810を含む、ネットワーク800における任意の数のデバイス810に伝搬してもよいことが諒解されよう。
【００９８】
動作7において、デバイス4は再びイベントをブロードキャストする。動作8において、イベントはデバイス2によって検出される。動作9において、デバイス2は、受信されたイベントを生成されたM2Mイベント辞書における汎用イベントにマッピングすることを決定する。デバイス2は次いで、M2Mイベント辞書における関連する汎用イベントに関して定義された1つまたは複数のホームオートメーション規則を実行する。
【００９９】
図9は、IoTネットワークにおいてM2Mプロトコルなどのデバイス間通信プロトコルに関するイベント辞書を自動的に生成するための例示的なフローを示す。図9に示すフローは、図8におけるEMDG804によって実行されてもよい。910において、EMDG804は、図8におけるIoTデバイス810のうちの1つなどの、IoTネットワークにおけるIoTデバイスによってブロードキャストされたイベントの通知を受信する。この通知は、たとえば、ブロードキャストイベントまたはサブスクリプションイベントのいずれかとして受信されてもよい。
【０１００】
920において、EMDG804は、イベントの前のIoTデバイスの状態およびイベントの後のIoTデバイスの状態を判定する。EMDG804は、IoTデバイスを周期的にポーリングし、それによって、イベントの前のIoTデバイスの状態を取り込んでもよい。EMDG804は、イベントの直後に、周期的なポーリングとは独立にIoTデバイスの状態を取り込んでもよい。930において、EMDG804は、イベントの前のIoTデバイスの状態とイベントの後のIoTデバイスの状態を比較する。
【０１０１】
940において、EMDG804は、920における比較に基づいてイベントの状態変化のタイプを判定する。940における判定は、イベントの前のIoTデバイスの状態に関してIoTデバイスをポーリングすることと、イベントの後のIoTデバイスの状態に関してIoTデバイスをポーリングすることとを含んでもよい。
【０１０２】
950において、EMDG804は、イベントの状態変化のタイプと一致する状態変化のタイプに関するエントリがイベント辞書内にあるかどうかを判定する。EMDG804は、イベントの状態変化のタイプと一致する状態変化のタイプに関するエントリがイベント辞書内にあると判定した場合、EMDG804は何も行う必要がなく、フローは開始点に戻る。
【０１０３】
しかし、EMDG804は、イベントの状態変化のタイプと一致する状態変化のタイプに関するエントリはイベント辞書内にないと判定した場合、960において、イベントの状態変化のタイプに関する汎用エントリをイベント辞書内に作成する。汎用エントリは、汎用エントリに関連する状態変化のタイプの計数とテキスト記述とを含んでもよい。汎用エントリに関連する状態変化のタイプは、このIoTデバイスと同じタイプおよび/またはクラスのIoTデバイスと共通する。970において、EMDG804は、イベントのイベント記述の汎用エントリへのマッピングを記憶する。
【０１０４】
一態様では、EMDG804は、IoTデバイスのタイプを判定してもよい。この場合、イベント辞書内に汎用エントリがあるか否かを判定すること(950)は、このIoTデバイスのタイプと一致するIoTデバイスのタイプおよびイベントの状態変化のタイプと一致する状態変化のタイプに関する汎用イベントがイベント辞書内にあるか否かを判定することを含んでもよく、イベント辞書内に汎用エントリを作成すること(960)は、このIoTデバイスのタイプと一致するIoTデバイスのタイプおよびイベントの状態変化のタイプと一致する状態変化のタイプに関する汎用イベントがイベント辞書内にはないことに基づいてイベント辞書内に汎用エントリを作成することを含んでもよい。
【０１０５】
図9には示されていないが、EMDG804は、(910と同様に)第2のIoTデバイスから第2のイベントを検出し、(920と同様に)第2のイベントの前の第2のIoTデバイスの状態および第2のイベントの後の第2のIoTデバイスの状態を判定し、(930と同様に)第2のイベントの前の第2のIoTデバイスの状態と第2のイベントの後の第2のIoTデバイスの状態を比較し、(940と同様に)比較に基づいて第2のイベントの状態変化のタイプを検出し、第2のイベントが、イベントの状態変化と同じタイプの状態変化および上記のIoTデバイスと同じタイプおよび/またはクラスであることに基づいて第2のイベントを汎用エントリにマップし、第2のIoTデバイスから受信された第2のイベントのイベント記述の汎用エントリへのマッピングを記憶してもよい。第2のIoTデバイスから受信された第2のイベントのイベント記述は、上記のIoTデバイスから受信されたイベントのイベント記述とは異なってもよい。汎用エントリは、上記のIoTデバイスと第2のIoTデバイスに共通する汎用状態変化を記述し、上記のIoTデバイスおよび第2のIoTデバイスから受信されたイベントに関するイベント記述を記憶してもよい。
【０１０６】
一態様では、図9には示されていないが、EMDG804はイベント辞書をIoTネットワークにおける他のIoTデバイスに送信してもよい。EMDG804はまた、制御アプリケーションによってイベント辞書において定義された汎用イベントに基づいてホームオートメーション規則を定義し、ホームオートメーション規則をIoTネットワークにおける他のIoTデバイスに配信してもよい。IoTネットワークにおける第3のIoTデバイスは、IoTネットワークにおける第1または第2のIoTデバイスからイベント通知を受信し、受信されたイベント通知をイベント辞書における汎用エントリにマップし、イベント辞書における汎用エントリに関して定義されたホームオートメーション規則を実行してもよい。
【０１０７】
本開示の一態様によれば、図10は、本明細書において説明するように、IoTネットワークにおけるデバイス間通信プロトコルに関するイベント辞書を自動的に生成する場合がある1つまたは複数のデバイスに対応することがある例示的な通信デバイス1000を示す(たとえば、図8におけるゲートウェイエージェント802、またはEMDG804を具現化する別のデバイス)。特に、図10に示すように、通信デバイス1000は、たとえば、受信アンテナ(図示せず)から信号を受信し、受信信号に典型的なアクション(たとえばフィルタ処理、増幅、ダウンコンバートなど)を実行し、条件付きの信号をデジタル化してサンプルを取得する受信機1002を備えてもよい。受信機1002は、受信されたシンボルを復調し、復調されたシンボルをチャネル推定のためにプロセッサ1006に提供することができる復調器1004を備えてもよい。プロセッサ1006は、受信機1002によって受信される情報を分析することおよび/もしくは変調器1018および送信機1020によって送信するための情報を生成することに専従するプロセッサ、通信デバイス1000の1つもしくは複数のコンポーネントを制御するプロセッサ、ならびに/または受信機1002によって受信される情報の分析と送信機1020によって送信するための情報の生成の両方を行いかつ通信デバイス1000の1つもしくは複数のコンポーネントを制御するプロセッサであってもよい。
【０１０８】
通信デバイス1000は、プロセッサ1006に動作可能に結合され、送信すべきデータ、受信されたデータ、使用可能なチャネルに関連する情報、分析された信号および/または干渉強度に関連するデータ、割り当てられたチャネル、電力、レートなどに関連する情報、およびチャネルを推定し、チャネルを介して通信するための任意の他の適切な情報を記憶することができるメモリ1008をさらに含むことができる。加えて、メモリ1008は、(たとえば、性能ベース、容量ベースなど)チャネルを推定および/または利用することに関連するプロトコルおよび/またはアルゴリズムを記憶することができる。
【０１０９】
メモリ1008は、揮発性メモリもしくは不揮発性メモリのいずれかとすることができ、あるいは揮発性と不揮発性の両方のメモリを含むことができることが諒解されよう。限定ではなく例として、不揮発性メモリは、読取り専用メモリ(ROM)、プログラマブルROM(PROM)、電気的プログラマブルROM(EPROM)、電気的消去可能PROM(EEPROM)、またはフラッシュメモリを含むことができる。揮発性メモリは、外部キャッシュメモリとして働くランダムアクセスメモリ(RAM)を含むことができる。限定ではなく例として、RAMは、同期RAM(SRAM)、ダイナミックRAM(DRAM)、同期DRAM(SDRAM)、ダブルデータレートSDRAM(DDR SDRAM)、拡張SDRAM(ESDRAM)、シンクリンクDRAM(SLDRAM)、およびダイレクトRambus RAM(DRRAM（登録商標）)などの多くの形で使用可能である。対象のシステムおよび方法のメモリ1008は、限定はしないが、これらおよび任意の他の適切なタイプのメモリを含んでもよい。
【０１１０】
一実施形態では、メモリ1008はEMDGモジュール1010を記憶してもよい。EMDGモジュール1010は、プロセッサ1006によって実行可能なソフトウェアモジュールであってもよい。代替として、EMDGモジュール1010は、プロセッサ1006のハードウェア構成要素であってもよく、あるいはプロセッサ1006に結合されてもよい。別の代替として、EMDGモジュール1010はハードウェアとソフトウェアの組合せであってもよい。EMDGモジュール1010は、図8におけるEMDG804に対応してもよい。
【０１１１】
通信デバイス1000は、通信デバイス1000などの他のデバイスとの接続の確立を容易にするために分散バスモジュール1030をさらに含むことができる。分散バスモジュール1030は、分散バスモジュール1030が複数のデバイス間の通信を管理するのを助けるためのバスノードモジュール1032をさらに備えてもよい。一態様では、バスノードモジュール1032は、バスノードモジュール1032が他のデバイスに関連するエンドポイントアプリケーションと通信するのを助けるためのオブジェクト命名モジュール1034をさらに含んでもよい。さらに、分散バスモジュール1030は、ローカルエンドポイントが確立された分散バスを通じて他のローカルエンドポイントおよび/または他のデバイス上のアクセス可能なエンドポイントと通信するのを助けるためのエンドポイントモジュール1036を含んでもよい。別の態様では、分散バスモジュール1030は、複数の利用可能なトランスポート(たとえば、Bluetooth（登録商標）、UNIX（登録商標）ドメインソケット、TCP/IP、Wi-Fiなど)を介したデバイス間通信および/またはデバイス内通信を容易にすることができる。
【０１１２】
さらに、一実施形態では、通信デバイス1000は、ユーザインターフェース1040を含んでもよく、ユーザインターフェース1040は、通信デバイス1000への入力を生成するための1つまたは複数の入力機構1042と、通信デバイス1000のユーザによって消費される情報を生成するための1つまたは複数の出力機構1044とを含んでもよい。たとえば、入力機構1042は、キーまたはキーボード、マウス、タッチスクリーンディスプレイ、マイクロフォンなどの機構を含んでもよい。さらに、たとえば、出力機構1044は、ディスプレイ、オーディオスピーカ、触覚フィードバック機構、パーソナルエリアネットワーク(PAN)トランシーバなどを含んでもよい。図示した態様では、出力機構1044は、メディアコンテンツをオーディオ形式にレンダリングするように動作可能なオーディオスピーカ、メディアコンテンツの画像フォーマットもしくはビデオフォーマットへのレンダリングおよび/または時限メタデータのテキスト形式または視覚形式へのレンダリングを行うように動作可能なディスプレイ、あるいは他の適切な出力機構を含んでもよい。しかし、一実施形態では、通信デバイス1000は、ヘッドレスデバイスである場合、ヘッドレスデバイスは一般にモニタ、キーボード、および/またはマウスなしで動作するように構成されたコンピュータシステムまたはデバイスを指すので、通信デバイス1000は、いくつかの入力機構1042および/または出力機構1044を含まなくてもよい。
【０１１３】
通信デバイス1000が、本明細書において説明するようにIoTネットワークにおけるデバイス間通信プロトコルに関するイベント辞書を自動的に生成するように構成される場合、受信機1002、プロセッサ1006、メモリ1008、EMDGモジュール1010、送信機1020、および分散バスモジュール1030は協働して、本明細書において説明する機能を実行してもよい。たとえば、受信機1002が、IoTネットワークにおけるIoTデバイスによってブロードキャストされたイベントの通知を受信した後、EMDGモジュール1010は、プロセッサ1006によって実行されたときに、プロセッサ1006に、イベントの前のIoTデバイスの状態およびイベントの後のIoTデバイスの状態を判定することと、イベントの前のIoTデバイスの状態とイベントの後のIoTデバイスの状態を比較することと、比較に基づいてイベントの状態変化のタイプを判定することと、イベントの状態変化のタイプと一致する状態変化のタイプに関するエントリがイベント辞書内にあるか否かを判定することと、イベントの状態変化のタイプと一致する状態変化のタイプに関するエントリがイベント辞書内にはない場合に、イベントの状態変化のタイプに関する汎用エントリをイベント辞書内に作成することとをプロセッサ1006に行わせてもよい。メモリ1008は次いで、イベントのイベント記述の汎用エントリへのマッピングを記憶してもよい。代替として、EMDGモジュール1010は、ハードウェアモジュールであり、EMDGモジュール1010は、プロセッサ1006によって実行される機能として上記において説明した機能を実行してもよい。
【０１１４】
図11は、相互に関係する一連の機能モジュールとして表された、例示的な装置1100を示す。受信するためのモジュール1102は、少なくともいくつかの態様では、たとえば、本明細書において説明するような図10におけるトランシーバ1002などの通信デバイスに対応してもよい。判定するためのモジュール1104は、少なくともいくつかの態様では、たとえば、本明細書において説明するような図10におけるプロセッサ1006および/またはEMDGモジュール1010などの処理システムに対応してもよい。比較するためのモジュール1106は、少なくともいくつかの態様では、たとえば、本明細書において説明するような図10におけるプロセッサ1006および/またはEMDGモジュール1010などの処理システムに対応してもよい。判定するためのモジュール1108は、少なくともいくつかの態様では、たとえば、本明細書において説明するような図10におけるプロセッサ1006および/またはEMDGモジュール1010などの処理システムに対応してもよい。判定するためのモジュール1110は、少なくともいくつかの態様では、たとえば、本明細書において説明するような図10におけるプロセッサ1006および/またはEMDGモジュール1010などの処理システムに対応してもよい。作成するためのモジュール1112は、少なくともいくつかの態様では、たとえば、本明細書において説明するような図10におけるメモリ1008などの記憶システムと協働する、図10におけるプロセッサ1006および/またはEMDGモジュール1010などの処理システムに対応してもよい。記憶するためのモジュール1114は、少なくともいくつかの態様では、たとえば、本明細書において説明するような図10におけるメモリ1008などの記憶システムと協働する、図10におけるプロセッサ1006および/またはEMDGモジュール1010などの処理システムに対応してもよい。
【０１１５】
図11のモジュールの機能は、本明細書の教示と矛盾しない様々な方法で実装されてもよい。いくつかの設計では、これらのモジュールの機能は、1つまたは複数の電気構成要素として実装されてもよい。いくつかの設計では、これらのブロックの機能は、1つまたは複数のプロセッサ構成要素を含む処理システムとして実装されてもよい。いくつかの設計では、これらのモジュールの機能は、たとえば、1つまたは複数の集積回路(たとえば、ASIC)の少なくとも一部分を使用して実装されてもよい。本明細書で説明するように、集積回路は、プロセッサ、ソフトウェア、他の関連の構成要素、またはそれらの何らかの組合せを含んでもよい。したがって、異なるモジュールの機能は、たとえば、集積回路の異なるサブセットとして実装されてもよく、あるいは1組のソフトウェアモジュールの異なるサブセットとして実装されてもよく、あるいはその組合せとして実装されてもよい。また、(たとえば、集積回路の、および/またはソフトウェアモジュールのセットの)所与のサブセットが、2つ以上のモジュールに関する機能の少なくとも一部分を実現する場合があることが諒解されよう。
【０１１６】
加えて、図11によって表される構成要素および機能ならびに本明細書で説明する他の構成要素および機能は、任意の適切な手段を使用して実装されてもよい。そのような手段はまた、少なくとも部分的に、本明細書で教示する対応する構造を使用して実装されてもよい。たとえば、図11の「ためのモジュール」構成要素とともに上記で説明した構成要素はまた、同様に指定された「ための手段」機能に相当してもよい。したがって、いくつかの態様では、そのような手段のうちの1つまたは複数は、プロセッサ構成要素、集積回路、または本明細書で教示する他の適切な構造のうちの1つまたは複数を使用して実装されてもよい。
【０１１７】
情報および信号が多種多様な異なる技術および技法のいずれかを使用して表すことができることを、当業者は理解されよう。たとえば上記説明全体を通して参照することができるデータ、命令、指令、情報、信号、ビット、記号およびチップは、電圧、電流、電磁波、磁界または粒子、光学場または粒子、あるいはそれらの任意の組合せによって表すことができる。
【０１１８】
さらに、本明細書で開示する態様に関連して説明した様々な例示的な論理ブロック、モジュール、回路、およびアルゴリズムステップは、電子ハードウェア、コンピュータソフトウェア、または両方の組合せとして実装され得ることを当業者は理解されよう。ハードウェアおよびソフトウェアのこの互換性を明確に示すために、様々な例示的な構成要素、ブロック、モジュール、回路、およびステップは、一般的にそれらの機能性に関してこれまで説明されてきた。そのような機能性がハードウェアとして実現されるか、またはソフトウェアとして実現されるかは、具体的な適用例および全体的なシステムに課される設計制約によって決まる。当業者は、説明される機能を具体的な応用形態ごとに様々な方法で実現することができるが、そのような実現の決定は、本開示の範囲からの逸脱を生じるものと解釈されるべきではない。
【０１１９】
本明細書に開示する態様と関連して説明する様々な例示的な論理ブロック、モジュール、および回路は、汎用プロセッサ、デジタル信号プロセッサ(DSP)、特定用途用集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)もしくは他のプログラマブルロジックデバイス、個別のゲートもしくはトランジスタロジック、個別のハードウェア部品、または本明細書に記載した機能を行うように設計されたこれらの任意の組合せを用いて、実装または実行され得る。汎用プロセッサを、マイクロプロセッサとすることができるが、代替案では、プロセッサを、任意の従来のプロセッサ、コントローラ、マイクロコントローラ、または状態機械とすることができる。プロセッサはまた、コンピューティングデバイスの組合せ(たとえば、DSPおよびマイクロプロセッサの組合せ、複数のマイクロプロセッサ、DSPコアと連携する1つもしくは複数のマイクロプロセッサ、または任意の他のそのような構成)として実装され得る。
【０１２０】
本明細書において開示する態様に関連して説明した方法、シーケンス、および/またはアルゴリズムは、ハードウェアで、プロセッサによって実行されるソフトウェアモジュールで、またはその2つの組合せで直接具現され得る。ソフトウェアモジュールは、RAM、フラッシュメモリ、ROM、EPROM、EEPROM、レジスタ、ハードディスク、リムーバブルディスク、CD-ROM、または当技術分野で知られている任意の他の形態の記憶媒体内に存在し得る。例示的な記憶媒体は、プロセッサが記憶媒体から情報を読取り、そこに情報を書込みできるようにプロセッサに結合される。代替案では、記憶媒体は、プロセッサに一体とされ得る。プロセッサおよび記憶媒体は、ASIC内に存在し得る。ASICはIoTデバイス内に存在し得る。代替として、プロセッサおよび記憶媒体は、ユーザ端末内に個別の構成要素として存在し得る。
【０１２１】
1つまたは複数の例示的な態様では、述べられる機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せで、実施され得る。ソフトウェアに実装される場合、機能は、1つまたは複数の命令またはコードとして、コンピュータ可読媒体上に記憶されるか、または、コンピュータ可読媒体を介して送信される場合がある。コンピュータ可読媒体は、ある場所から別の場所へのコンピュータプログラムの転送を可能にする任意の媒体を含む、コンピュータ記憶媒体と通信媒体の両方を含む。記憶媒体は、コンピュータによってアクセスできるすべての使用可能な媒体とすることができる。限定ではなく例として、そのようなコンピュータ可読媒体は、RAM、ROM、EEPROM、CD-ROMもしくは他の光ディスク(disc)ストレージ、磁気ディスク(disk)ストレージもしくは他の磁気ストレージデバイス、あるいは命令もしくはデータ構造の形で所望のプログラムコードを担持しまたは記憶するのに使用でき、コンピュータによってアクセスできる任意の他の媒体を含むことができる。また、任意の接続は、適切にコンピュータ可読媒体と呼ばれる。たとえば、同軸ケーブル、光ファイバケーブル、ツイストペア、DSL、または赤外線、無線、およびマイクロ波などのワイヤレス技術を使用して、ウェブサイト、サーバ、または他のリモートソースからソフトウェアが送信される場合、同軸ケーブル、光ファイバケーブル、ツイストペア、DSL、または赤外線、無線、およびマイクロ波などのワイヤレス技術は、媒体の定義に含まれる。本明細書で使用するディスク(disk)およびディスク(disc)は、CD、レーザディスク(disc)、光ディスク(disc)、DVD、フロッピーディスク(disk)およびBlu-ray(登録商標)ディスク(disc)を含み、ディスク(disk)は、通常、データを磁気的に再生し、ディスク(disc)は、データをレーザで光学的に再生する。前述の組合せも、コンピュータ可読媒体の範囲内に含まれるべきである。
【０１２２】
上記の開示は本開示の例示的な態様を示すが、添付の特許請求の範囲によって規定される本開示の範囲から逸脱することなく、本明細書で様々な変更および修正が行われ得ることに留意されたい。本明細書で説明した本開示の態様による方法クレームの機能、ステップおよび/または動作は、特定の順序で実施される必要はない。さらに、本開示の要素は、単数形で記載または特許請求されている場合があるが、単数形に限定することが明示的に述べられていない限り、複数形が考えられる。
【符号の説明】
【０１２３】
100A、100B、100C、100D、100E  ワイヤレス通信システム
105  受動IoTデバイス
108  エアインターフェース
109  直接有線接続
110  テレビジョン、IoTデバイス
112  屋外空調機、IoTデバイス
114  温度自動調整器、IoTデバイス
116  冷蔵庫、IoTデバイス
116A、116B  IoTデバイス
118  洗濯機および乾燥機、IoTデバイス
120  コンピュータ
122A、122B  IoTデバイス
124A、124B  IoTデバイス
125  アクセスポイント
130  IoTマネージャ、スーパーバイザデバイス
140、140A、140B  IoT SuperAgent
145  ゲートウェイ機能、ゲートウェイ
152  アプリケーションレイヤ
154  CMPレイヤ
156  トランスポートレイヤ
158  物理レイヤ
160  IoTグループ、IoTデバイスグループ
160A、160B  IoTデバイス
170  IoTサーバ
175  インターネット
180  リソース
200A  IoTデバイス
202  プラットフォーム
206  トランシーバ
208  プロセッサ
210  EMDGモジュール
212  メモリ
214  入出力(I/O)インターフェース
216  鍵交換認証モジュール
222  電力ボタン
224A、224B  制御ボタン
226  ディスプレイ
300  通信デバイス
305  情報を受信および/または送信するように構成された論理
310  情報を処理するように構成された論理
315  情報を記憶するように構成された論理
320  情報を提示するように構成された論理
325  ローカルユーザ入力を受信するように構成された論理
400  サーバ
401  プロセッサ
402  揮発性メモリ
403  ディスクドライブ
404  ネットワークアクセスポート
406  ディスクドライブ
407  ネットワーク
410  EMDGモジュール
500  ワイヤレス通信ネットワーク、WAN
510、510a、510b、510c  基地局
520  デバイス
530  ネットワークコントローラ
540  DHCPサーバ
600  例示的な環境
610  第1のデバイス
612  分散バスノード
614  ローカルエンドポイント
625  分散バス
630  第2のデバイス
632  分散バスノード
634  ローカルエンドポイント
640  第3のデバイス
642  分散バスノード
644  ローカルエンドポイント
700  例示的なメッセージシーケンス
710  第1のデバイス、デバイスA
730  第2のデバイス、デバイスB
712  バスノード
714  ローカルエンドポイント
732  バスノード
734  ローカルエンドポイント
800  IoTネットワーク
802  ゲートウェイエージェント
804  EMDG
806  制御アプリケーション
810  IoTデバイス
1000  通信デバイス
1002  受信機
1004  復調器
1006  プロセッサ
1008  メモリ
1010  EMDGモジュール
1018  変調器
1020  送信機
1030  分散バスモジュール
1032  バスノードモジュール
1034  オブジェクト命名モジュール
1036  ローカルエンドポイントモジュール
1040  ユーザインターフェース
1042  入力機構
1044  出力機構
1100  装置
1102  受信するためのモジュール
1104  判定するためのモジュール
1106  比較するためのモジュール
1108  判定するためのモジュール
1110  判定するためのモジュール
1112  作成するためのモジュール
1114  記憶するためのモジュール
【図１Ａ】
0006640833.tif 000002
【図１Ｂ】
0006640833.tif 000003
【図１Ｃ】
0006640833.tif 000004
【図１Ｄ】
0006640833.tif 000005
【図１Ｅ】
0006640833.tif 000006
【図２Ａ】
0006640833.tif 000007
【図２Ｂ】
0006640833.tif 000008
【図３】
0006640833.tif 000009
【図４】
0006640833.tif 000010
【図５】
0006640833.tif 000011
【図６】
0006640833.tif 000012
【図７】
0006640833.tif 000013
【図８】
0006640833.tif 000014
【図９】
0006640833.tif 000015
【図１０】
0006640833.tif 000016
【図１１】
0006640833.tif 000017