様々な態様および実施形態が、例示的な態様および実施形態に関する特定の例を示すために以下の説明および関連する図面において開示される。代替的態様および代替的実施形態は、この開示を読むと当業者には明らかであり、本開示の範囲または趣旨を逸脱することなく構築され、実践され得る。加えて、本明細書で開示する態様および実施形態の関連する詳細を不明瞭にしないように、よく知られている要素は詳細には説明されず、または省略され得る。
「例示的」という言葉は、本明細書では「例、事例、または例示として機能すること」を意味するために使用される。本明細書で「例示的」として説明するいかなる実施形態も、必ずしも他の実施形態よりも好ましいか、または有利であると解釈されるべきではない。同様に、「実施形態」という用語は、すべての実施形態が、論じられた特徴、利点または動作モードを含むことを要求しない。
本明細書で使用される用語は、特定の実施形態のみを説明しており、本明細書で開示されるいずれかの実施形態を限定すると解釈されるべきではない。本明細書で使用される単数形「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デバイスを含む。
図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は、適切なデバイス間(D2D)通信技術を使用してエアインターフェース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デバイス、インターネット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デバイスの属性の変化を検出すること、記憶すること、通信すること、それらの変化に作用することなどが可能である。
たとえば、1つまたは複数の受動IoTデバイス105は、各々がRFIDタグまたはバーコードを有するコーヒーカップ受動IoTデバイス105とオレンジジュース容器受動IoTデバイス105とを含んでもよい。キャビネットIoTデバイス(図示せず)および冷蔵庫IoTデバイス116は、各々、RFIDタグもしくはバーコードを読み取って、コーヒーカップの受動IoTデバイス105および/またはオレンジジュース容器の受動IoTデバイス105がいつ追加あるいは除去されたかを検出することができる適切なスキャナまたはリーダーを有し得る。キャビネットIoTデバイスがコーヒーカップの受動IoTデバイス105の除去を検出し、冷蔵庫IoTデバイス116がオレンジジュース容器の受動IoTデバイス105の除去を検出すると、スーパーバイザデバイス130は、キャビネットIoTデバイスおよび冷蔵庫IoTデバイス116において検出された活動に関する1つまたは複数の信号を受信することができる。スーパーバイザデバイス130は、次いで、コーヒーカップの受動IoTデバイス105からユーザがオレンジジュースを飲んでいること、および/またはコーヒーカップの受動IoTデバイス105からユーザがオレンジジュースを飲みたいことを推定することができる。
上記は何らかの形のRFIDタグ通信インターフェースまたはバーコード通信インターフェースを有するとして受動IoTデバイス105を説明しているが、受動IoTデバイス105は、そのような通信能力を有しない、1つもしくは複数のデバイスまたは他の物理的対象物を含み得る。たとえば、あるIoTデバイスは、受動IoTデバイス105を識別するために、受動IoTデバイス105に関連付けられた形状、サイズ、色、および/もしくは他の観測可能な特徴を検出することができる適切なスキャナ機構またはリーダー機構を有し得る。このようにして、任意の適切な物理的対象物は、それに関連付けられた識別情報および1つまたは複数の属性を通信して、ワイヤレス通信システム100Bの一部になることができ、スーパーバイザデバイス130を用いて観測、監視、制御、あるいは管理され得る。さらに、受動IoTデバイス105は、図1Aのワイヤレス通信システム100Aに結合され得るか、あるいはその一部であり得、実質的に同様の形で、観測、監視、制御、または管理され得る。
様々な態様によれば、図1Cは、複数のIoTデバイスを含む別のワイヤレス通信システム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デバイスを含む別のワイヤレス通信システム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デバイス間でかなり異なる場合があるが、大部分の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デバイス内のメモリ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は、図2Aに示す、示された特徴または構成に限定されない。
図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に関連付けられた形状、サイズ、色、および/もしくは他の観測可能な特徴を検出することができる適切なスキャナ機構またはリーダー機構を有し得る。このようにして、任意の適切な物理的対象物は、それに関連付けられた識別情報および1つまたは複数の属性を通信することができ、制御されたIoTネットワーク内で観測、監視、制御、あるいは管理され得る。
図3は、機能を実行するように構成される論理を含む通信デバイス300を示す。通信デバイス300は、限定はしないが、IoTデバイス110〜120、IoTデバイス200A、インターネット175に結合された任意の構成要素(たとえば、IoTサーバ170)などを含む、上記の通信デバイスのうちのいずれかに対応し得る。したがって、通信デバイス300は、図1A〜図1Bのワイヤレス通信システム100A〜100Bを介して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は、それに関連付けられた機能を達成するためにハードウェアに少なくとも部分的に依拠する。
図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は、上記で説明したIoTサーバ170の1つの例示的な構成に対応し得る。図4では、サーバ400は、揮発性メモリ402と、大容量の不揮発性メモリ403(たとえば、ハードディスク)とに結合されたプロセッサ401を含む。サーバ400は、プロセッサ401に結合された、フロッピー(登録商標)ディスクドライブ、コンパクトディスク(CD)ドライブ、および/またはDVDディスクドライブ406を含むことも可能である。サーバ400は、他のブロードキャストシステムコンピュータおよびサーバに、またはインターネットに結合されたローカルエリアネットワークなどのネットワーク407とのデータ接続を確立するための、プロセッサ401に結合されたネットワークアクセスポート404を含むことも可能である。図3において、当業者には、図4のサーバ400が通信デバイス300の1つの例示的な実装形態を示し、それにより、情報の受信および/または送信を行うように構成された論理305が、ネットワーク407と通信するためにサーバ400によって使用されるネットワークアクセスポート404に対応してもよく、情報を処理するように構成された論理310が、プロセッサ401に対応してもよく、情報を記憶するように構成された論理315が、揮発性メモリ402、不揮発性メモリ403、および/またはフロッピー/CD/DVDディスクドライブ406の任意の組合せに対応してもよいことが諒解されよう。情報を提示するように構成されたオプションの論理320およびローカルユーザ入力を受信するように構成されたオプションの論理325は、図4には明示的に示さず、その中に含まれる場合もあれば、含まれない場合もある。したがって、図4は、通信デバイス300が、図2Aに示すようなIoTデバイスの実装形態に加えてサーバとして実装され得ることを説明するのを助ける。
概して、上述のように、IPベースの技法およびサービスが成熟し、コストを削減しIPの可用性を向上させており、それによって、インターフェース接続性をますます多くの種類の日常の電子対象物に付加することが可能になっている。したがって、IoTは、コンピュータおよびコンピュータネットワークだけでなく、日常の電子的対象物が、インターネットを介して読取り可能、認識可能、位置特定可能、アドレス指定可能、および制御可能であり得るという発想に基づく。概して、IoTが開発され普及することによって、それぞれに異なる種類を有しそれぞれに異なる活動を実行する多数の近位異種IoTデバイスおよびその他の対象物(たとえば、ライト、プリンタ、冷蔵庫、空調装置など)は、多くの異なる方法で相互作用し、多くの異なる方法で使用される場合がある。したがって、制御されたIoTネットワーク内で使用される場合がある場合によっては多数の異種IoTデバイスおよびその他の対象物に起因して、概して、特に、様々な異種IoTデバイスが適切に構成され、管理され、かつ互いに通信して情報を交換することが可能になるように、明確な信頼できる通信インターフェースを様々な異種IoTデバイスに接続する必要がある。したがって、図5〜図8に関する以下の説明では、概して、本明細書で開示するように分散型プログラミング環境における異種デバイス間の直接D2D通信を可能にすることができる発見可能なデバイス間(D2D)またはピアツーピア(P2P)サービスをサポートする場合がある例示的な通信フレームワークについて概略的に説明する。
概して、ユーザ機器(UE)(たとえば、電話、タブレットコンピュータ、ラップトップコンピュータおよびデスクトップコンピュータ、車両など)は、互いに(たとえば、Bluetooth(登録商標)、ローカルWi-Fiなどによって)ローカルに接続するように構成されても、あるいは(たとえば、セルラーネットワーク、インターネットなどを介して)リモートに接続するように構成されても、あるいはそれらの適切な組合せに従って構成されてもよい。さらに、いくつかのUEは、1対1の接続をサポートするかまたは互いに直接通信するいくつかのデバイスを含むグループに同時に接続するのをサポートする特定のワイヤレスネットワーキング技法(たとえば、Wi-Fi、Bluetooth(登録商標)、Wi-Fi Directなど)を使用する近接度ベースのD2D通信をサポートしてもよい。ここで、図5は、直接D2D通信を有効化することができる発見可能なD2Dサービスをサポートする場合がある例示的なワイヤレス通信ネットワークまたは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は、バックホールを介して基地局と通信することができる単一のネットワークエンティティまたはネットワークエンティティの集合であってもよい。また、基地局は、(たとえば、直接またはワイヤレスバックホールまたはワイヤラインバックホールを介して間接的に)互いに通信し得る。DHCPサーバ540は、以下に説明するように、D2D通信をサポートすることができる。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は、(たとえば、D2D通信を行っていないときに、または場合によってはD2D通信と同時に)基地局510と通信してもよい。
本明細書の説明では、WAN通信は、(たとえば別のデバイス520などのリモートエンティティと通話するための)ワイヤレスネットワーク500におけるデバイス520と基地局510との間の通信を指し得る。WANデバイスは、WAN通信に関心を持っているか、WAN通信に関与しているデバイス520である。概して、本明細書において使用される「ピアツーピア」または「P2P」通信および「デバイス間」または「D2D」通信という用語は、基地局510を介さない2つ以上のデバイス520間の直接的な通信を指す。説明を簡単にするために、本明細書における説明では、そのような直接的な通信を指すために「デバイス間」または「D2D」という用語を使用する。ただし、本明細書において説明する様々な態様および実施形態では「ピアツーピア」、「P2P」、「デバイス間」、および「D2D」という用語が交換可能であってもよいことを当業者は諒解されよう。
様々な実施形態によれば、D2Dデバイスは、D2D通信に関心を持っているかまたはD2D通信に関与しているデバイス520(たとえば、D2Dデバイスの近傍内の別のデバイス520に関するトラフィックデータを有するデバイス520)である。2つのデバイスは、たとえば、各デバイス520が他のデバイス520を検出できる場合、互いに近傍に位置すると見なされてもよい。概して、デバイス520は、別のデバイス520と、D2D通信の場合は直接通信してもよく、WAN通信の場合は少なくとも1つの基地局510を介して通信してもよい。
様々な実施形態では、D2Dデバイス520間の直接通信はD2Dグループとして構成されてもよい。より詳細には、D2Dグループは概して、D2D通信に関心を持っているか、またはD2D通信に関与している2つ以上のデバイス520のグループを指し、D2Dリンクは、D2Dグループ用の通信リンクを指す。さらに、様々な実施形態では、D2Dグループは、D2Dグループオーナー(またはD2Dサーバ)と指定される1つのデバイス520と、D2DグループオーナーによってサービスされるD2Dクライアントと指定される1つまたは複数のデバイス520とを含んでもよい。D2Dグループオーナーは、WANとのシグナリングの交換、D2DグループオーナーとD2Dクライアントとの間のデータ送信の調整などのような、いくつかの管理機能を実行することができる。たとえば、図5に示すように、第1のD2Dグループは、基地局510aの対象となるデバイス520aおよび520bを含み、第2のD2Dグループは、基地局510bの対象となるデバイス520cおよび520dを含み、第3のD2Dグループは、異なる基地局510bおよび510cの対象となるデバイス520eおよび520fを含み、第4のD2Dグループは、基地局510cの対象となるデバイス520g、520h、および520iを含む。デバイス520a、520d、520f、および520hは、そのそれぞれのD2DグループにおけるD2Dグループオーナーであってもよく、デバイス520b、520c、520e、520g、および520iは、そのそれぞれのD2DグループにおけるD2Dクライアントであってもよい。図5の他のデバイス520は、WAN通信に関与していてもよい。
様々な実施形態では、D2D通信は、D2Dグループ内でのみ行われ、かつ、D2Dグループに関連するD2DグループオーナーとD2Dクライアントとの間でのみ行われる。たとえば、同じD2Dグループ内の2つのD2Dクライアント(たとえば、デバイス520gおよび520i)が情報を交換することを望む場合、D2Dクライアントの一方がD2Dグループオーナー(たとえば、デバイス520h)に情報を送ってもよく、次いでD2Dグループオーナーが送信を他のD2Dクライアントに中継してもよい。様々な実施形態では、特定のデバイス520は、複数のD2Dグループに属してもよく、各D2Dグループ内でD2DグループオーナーまたはD2Dクライアントのいずれかとして振る舞ってもよい。さらに、様々な実施形態では、特定のD2Dクライアントは、1つのD2Dグループのみに属するかまたは複数のD2Dグループに属し、任意の特定の瞬間に複数のD2DグループのいずれかにおけるD2Dデバイス520と通信してもよい。概して、通信は、ダウンリンクおよびアップリンク上での送信を通じて促進され得る。WAN通信では、ダウンリンク(または順方向リンク)は基地局510からデバイス520への通信リンクを指し、アップリンク(または逆方向リンク)はデバイス520から基地局510への通信リンクを指す。D2D通信では、D2DダウンリンクはD2DグループオーナーからD2Dクライアントへの通信リンクを指し、D2DアップリンクはD2DクライアントからD2Dグループオーナーへの通信リンクを指す。様々な実施形態では、2つ以上のデバイスが、WAN技法を使用してD2D通信するのではなく、Wi-Fi、Bluetooth(登録商標)、またはWi-Fi Directなどの技法を使用してより小さいD2Dグループを形成してワイヤレスローカルエリアネットワーク(WLAN)上でD2D通信してもよい。たとえば、Wi-Fi、Bluetooth(登録商標)、Wi-Fi Direct、またはその他のWLAN技法を使用するD2D通信では、2つ以上のモバイルフォン、ゲームコンソール、ラップトップコンピュータ、またはその他の適切な通信エンティティ間のD2D通信を可能にすることができる。
図6は、様々な態様による、様々なデバイス610、620、630がD2D技術を使用して通信するのに利用することができる近接度ベースの分散バス640を確立するために発見可能なD2Dサービスを使用し得る例示的な環境600を示す。たとえば、様々な実施形態では、ネットワーク化コンピューティング環境におけるアプリケーション間通信を有効化するのに使用されるソフトウェアバスを含んでもよい分散バス640を介したプロセス間通信プロトコル(IPC)フレームワークを使用して単一のプラットフォーム上でのアプリケーション同士などの間の通信を容易にすることができ、この場合、ネットワーク化コンピューティング環境におけるアプリケーション間通信では、各アプリケーションが分散バス640に登録して他のアプリケーションにサービスを提供し、他のアプリケーションが登録されているアプリケーションに関する情報を分散バス640に問い合わせる。そのようなプロトコルは、信号メッセージ(たとえば、通知)がポイントツーポイントメッセージであってもまたはブロードキャストメッセージであってもよく、メソッド呼出しメッセージ(たとえば、RPC)が同期メッセージであってもまたは非同期メッセージであってもよく、分散バス640が(たとえば、1つまたは複数のバスルータまたは「デーモン」あるいは分散バス640との接続を可能にする場合がある他の適切なプロセスを介して)様々なデバイス610、620、630間のメッセージルーティングに対処する場合がある、非同期通知およびリモートプロシージャ呼出し(RPC)を可能にしてもよい。
様々な実施形態では、分散バス640は、様々なトランスポートプロトコル(たとえば、Bluetooth(登録商標)、TCP/IP、Wi-Fi、CDMA、GPRS、UMTSなど)によってサポートされてもよい。たとえば、様々な態様によれば、第1のデバイス610は、分散バスノード612と1つまたは複数のローカルエンドポイント614とを含んでもよく、分散バスノード612は、第1のデバイス610に関連するローカルエンドポイント614と第2のデバイス620および第3のデバイス630に関連するローカルエンドポイント624および634との間の、分散バス640を通じた(たとえば、第2のデバイス620および第3のデバイス630上の分散バスノード622および632を介した)通信を容易にすることができる。図7を参照しながら以下にさらに詳細に説明するように、分散バス640は、対称的マルチデバイスネットワークトポロジーをサポートしてもよく、デバイスドロップアウトの存在下でロバストな動作を可能にしてもよい。したがって、仮想分散バス640は、概して任意の下位トランスポートプロトコル(たとえば、Bluetooth(登録商標)、TCP/IP、Wi-Fiなど)とは無関係であってもよく、非セキュア(たとえば、オープン)からセキュア(たとえば、認証または暗号化)まで様々なセキュリティオプションを実現することができ、セキュリティオプションは、第1のデバイス610、第2のデバイス620、および第3のデバイス630間の自発的な接続を容易にしつつ、様々なデバイス610、620、630が互いの範囲に入るかまたは互いに近接したときに介入せずに使用され得る。
図7は、様々な態様による、第1のデバイス(「デバイスA」)710および第2のデバイス(「デバイスB」)720がD2D技術を使用して通信するのに利用することができる近接度ベースの分散バスを確立するために発見可能なD2Dサービスを使用し得る例示的なシグナリングフロー700を示す。たとえば、図7に示すシグナリングフロー700において、デバイスA 710は、デバイスB 720との通信を要求してもよく、デバイスA 710は、そのような通信を容易にするのを助ける場合があるバスノード712に加えて、通信を要求する場合があるローカルエンドポイント714(たとえば、ローカルアプリケーション、サービスなど)を含んでもよい。さらに、デバイスB 720は、ローカルエンドポイント714が、デバイスA 710上のローカルエンドポイント714とデバイスB 720上のローカルエンドポイント724との間の通信を容易にするのを助けることができるバスノード722に加えて通信を試み得るローカルエンドポイント724を含んでもよい。
様々な実施形態では、754において、バスノード712および722は適切な発見機構を実行してもよい。たとえば、Bluetooth(登録商標)、TCP/IP、UNIX(登録商標)などによってサポートされる接続を発見するための機構が使用されてもよい。756において、デバイスA 710上のローカルエンドポイント714は、バスノード712を通じて利用可能なエンティティ、サービス、エンドポイントなどに接続することを要求してもよい。様々な実施形態では、この要求は、ローカルエンドポイント714とバスノード712との間の要求応答プロセスを含んでもよい。758において、分散メッセージバスが、バスノード712をバスノード722に接続し、それによってデバイスA 710とデバイスB 720との間のD2D接続を確立するように形成されてもよい。様々な実施形態では、バスノード712とバスノード722との間に分散バスを形成するための通信は、近接度ベースのD2Dプロトコル(たとえば、接続された製品間の相互運用性を実現するように設計されたAllJoyn(登録商標)ソフトウェアフレームワークおよび近位ネットワークを動的に作成し近位D2D通信を容易にするための様々な製造業者によるソフトウェアアプリケーション)を使用して容易にされてもよい。代替として、様々な実施形態では、サーバ(図示せず)はバスノード712とバスノード722との間の接続を容易にしてもよい。さらに、様々な実施形態では、バスノード712とバスノード722との間に接続を形成する前に適切な認証機構が使用されてもよい(たとえば、クライアントが認証コマンドを送って認証対話を開始することができるSASL認証)。さらに、758において、バスノード712および722は、利用可能な他のエンドポイント(たとえば、図6のデバイスC 630上のローカルエンドポイント634)に関する情報を交換してもよい。そのような実施形態では、バスノードが維持する各ローカルエンドポイントが他のバスノードに通知されてもよく、この通知は、一意のエンドポイント名、トランスポートタイプ、接続パラメータ、または他の適切な情報を含んでもよい。
様々な実施形態では、760において、バスノード712およびバスノード722は、それぞれローカルエンドポイント724および714に関連する得られた情報を使用して、様々なバスノードを通じて利用可能な得られた実エンドポイントを表すことのできる仮想エンドポイントを作成してもよい。様々な実施形態では、バスノード712上のメッセージルーティングでは、実エンドポイントおよび仮想エンドポイントを使用してメッセージを送信してもよい。さらに、リモートデバイス(たとえば、デバイスA 710)上に存在するあらゆるエンドポイントに1つのローカル仮想エンドポイントがあってもよい。さらに、そのような仮想エンドポイントは、分散バス(たとえば、バスノード712とバスノード722との間の接続)を介して送られたメッセージを多重化しならびに/あるいは多重化解除してもよい。様々な実施形態では、仮想エンドポイントは、実エンドポイントと同様にローカルバスノード712または722からメッセージを受信してもよく、分散バスを介してメッセージを転送してもよい。したがって、仮想エンドポイントは、エンドポイント多重化分散バス接続からローカルバスノード712および722へメッセージを転送してもよい。さらに、様々な実施形態では、リモートデバイス上の仮想エンドポイントに対応する仮想エンドポイントは、任意の時点で特定のトランスポートタイプの所望のトポロジーに対処するように再接続されてもよい。そのような実施形態では、UNIX(登録商標)ベースの仮想エンドポイントは、ローカルと見なされることがあり、したがって、再接続の候補とは見なされないことがある。さらに、TCPベースの仮想エンドポイントは、1つのホップルーティングに関して最適化されてもよい(たとえば、各バスノード712および722は互いに直接接続されてもよい)。さらに、Bluetooth(登録商標)ベースの仮想エンドポイントは、Bluetooth(登録商標)ベースのマスタがローカルマスタノードと同じバスノードであってもよい単一ピコネット(たとえば、1つのマスタおよびn個のスレーブ)に関して最適化されてもよい。
様々な実施形態では、バスノード712とバスノード722は、762においてバス状態情報を交換してバスインスタンス同士をマージし、分散バスを介した通信を可能にしてもよい。たとえば、様々な実施形態では、バス状態情報は、周知の一意のエンドポイント名マッピング、整合規則、ルーティンググループ、または他の適切な情報を含んでもよい。様々な実施形態では、状態情報は、分散バスベースのローカル名と通信するローカルエンドポイント714および724とのインターフェースを使用してバスノード712インスタンスとバスノード722インスタンスとの間で伝達されてもよい。別の態様では、バスノード712およびバスノード722の各々は、分散バスへのフィードバックを可能にする役割を果たすローカルバスコントローラを維持してもよく、バスコントローラは、グローバルメソッド、引数、信号、およびその他の情報を分散バスに関連する規格に変換してもよい。バスノード712およびバスノード722は、764において上述のようなバスノードノード接続の間に導入されるあらゆる変化に関してそれぞれのローカルエンドポイント714および724に通知する信号を伝達(たとえば、ブロードキャスト)してもよい。様々な実施形態では、新しいおよび/または削除されたグローバル名および/または変換後の名前が、名前オーナー変更後信号によって示されてもよい。さらに、(たとえば、名前衝突に起因して)ローカルに失われることがあるグローバル名が名前喪失信号によって示されてもよい。さらに、名前衝突に起因して転送されるグローバル名が名前オーナー変更後信号によって示されてもよく、バスノード712およびバスノード722が切り離された場合および/またはときに消える一意の名前が名前オーナー変更後信号によって示されてもよい。
上記に使用されたように、周知の名前を使用してローカルエンドポイント714および724を一意に記述してもよい。様々な実施形態では、デバイスA 710とデバイスB 720との間で通信が行われるとき、異なる周知の名前タイプが使用されてもよい。たとえば、バスノード712が直接接続されるデバイスA 710に関連するバスノード712上にのみデバイスローカル名が存在してもよい。別の例では、すべての既知のバスノード712および722上にグローバル名が存在してもよく、すべてのバスセグメント上に存在してもよい名前のオーナーは1人だけである。言い換えれば、バスノード712とバスノード722が連結され、衝突が起こると、オーナーのうちの1人がグローバル名を失うことがある。さらに別の例では、クライアントが仮想バスに関連する他のバスノードに接続されるときに変換後の名前が使用されてもよい。そのような実施形態では、変換後の名前はアペンデッドエンドを含んでもよい(たとえば、グローバルに一意の識別子「1234」を有する分散バスに接続された周知の名前「org.foo」を有するローカルエンドポイント714は「G1234.org.foo」と見なされてもよい)。
様々な実施形態では、バスノード712およびバスノード722は、766においてエンドポイントバストポロジーの変更について他のバスノードに通知するための信号を伝達(たとえば、ブロードキャスト)してもよい。その後、ローカルエンドポイント714からのトラフィックは、仮想エンドポイントを通過してデバイスB 720上の意図されるローカルエンドポイント724に達してもよい。さらに、動作中に、ローカルエンドポイント714とローカルエンドポイント724との間の通信はルーティンググループを使用してもよい。様々な実施形態では、ルーティンググループは、エンドポイントが信号、メソッド呼出し、またはエンドポイントのサブセットからの他の適切な情報を受信するのを可能にしてもよい。したがって、ルーティング名は、バスノード712または722に接続されたアプリケーションによって決定されてもよい。たとえば、D2Dアプリケーションは、アプリケーションに組み込まれた一意で周知のルーティンググループ名を使用してもよい。さらに、バスノード712および722は、ローカルエンドポイント714および724のルーティンググループへの登録および/または登録解除をサポートしてもよい。様々な実施形態では、ルーティンググループは、現在のバスインスタンスよりも後のインスタンスまで持続しなくてもよい。別の態様では、アプリケーションは、分散バスに接続するたびにアプリケーションの好ましいルーティンググループの登録をしてもよい。さらに、グループはオープンであっても(たとえば、任意のエンドポイントが参加してよい)またはクローズドであっても(たとえば、グループの作成者がグループを修正してもよい)よい。さらに、バスノード712または722は、他のリモートバスノードにルーティンググループエンドポイントの追加、削除、またはその他の変更を通知するための信号を送ってもよい。そのような実施形態では、バスノード712または722は、グループにメンバーが追加されならびに/あるいはグループからメンバーが削除されたときはいつでも他のグループメンバーにルーティンググループ変更信号を送ってもよい。さらに、バスノード712または722は、1つまたは複数のエンドポイントが最初にルーティンググループから削除されることなく分散バスから切り離される1つまたは複数のエンドポイントにルーティンググループ変更信号を送ってもよい。
様々な態様によれば、図8Aは、第1のホストデバイス810と第2のホストデバイス830との間のD2D通信を可能にするために第1のホストデバイス810と第2のホストデバイス830との間に形成される場合がある近接度ベースの例示的な分散バスを示す。より詳細には、図6に関して上記に説明したように、近接度ベースの分散バスの基本構造は、別個の物理的ホストデバイス上に存在する複数のバスセグメントを備えてもよい。したがって、図8Aでは、近接度ベースの分散バスの各セグメントがホストデバイス810、830のうちの1つのホストデバイス上に配置されてもよく、ホストデバイス810、830の各々は、それぞれのホストデバイス810、830上に配置されたバスセグメントを実施する場合があるローカルバスルータ(または「デーモン」)を実行する。たとえば、図8Aでは、各ホストデバイス810、830は、それぞれのホストデバイス810、830上に配置されたバスセグメントを実施するバスルータを表すために丸で囲まれた「D」を含む。さらに、ホストデバイス810、830のうちの1つまたは複数はいくつかのバスアタッチメントを有してもよく、各バスアタッチメントはローカルバスルータに接続する。たとえば、図8Aでは、ホストデバイス810および830上のバスアタッチメントは、各々がサービス(S)またはサービスを要求する場合があるクライアント(C)に対応する六角形として示されている。
しかし、場合によっては、埋込みデバイスにはローカルバスルータを実行するのに十分なリソースがない場合がある。したがって、図8Bは、1つまたは複数の埋込みデバイス820、825が近接度ベースの分散バスに接続するためにホストデバイス(たとえば、ホストデバイス830)に接続し、それによって、(たとえば、ホストデバイス830あるいはホストデバイス830を介して近接度ベースの分散バスにアタッチされた他のホストデバイス810および/または埋込みデバイス825との)D2D通信に関与することができる例示的な近接度ベースの分散バスを示す。したがって、埋込みデバイス820、825は概して、ホストデバイス830上で実行されているバスルータを「借用して」もよく、図8Bは、埋込みデバイス820、825が、埋込みデバイス820、825が存在する分散バスセグメントを管理する借用されたバスルータを実行するホストデバイス830から物理的に分離される構成を示す。概して、埋込みデバイス820、825とホストデバイス830との間の接続は、伝送制御プロトコル(TCP)に従って行われてもよく、埋込みデバイス820、825とホストデバイス830との間を流れるネットワークトラフィックは、上記に図6および図7に関してさらに詳細に説明したのと同様にそれぞれのセッションを介して流れるバスメソッド、バス信号、および特性を実現するメッセージを含んでもよい。
より詳細には、埋込みデバイス820、825は、クライアントとサービスとの間の発見および接続プロセスと概念的に同様であってもよい発見および接続プロセスに従ってホストデバイス830に接続してもよく、ホストデバイス830は、埋込みデバイス820、825をホストする能力または意志をシグナリングする周知の名前を通知してもよい(たとえば、「org.alljoyn.BusNode」)。一使用事例では、埋込みデバイス820、825は、単に、周知の名前を通知する「第1の」ホストデバイスに接続してもよい。しかし、埋込みデバイス820、825は、単に、周知の名前を通知する第1のホストデバイスに接続する場合、そのホストデバイスに関連する種類に関する知識(たとえば、ホストデバイス830がモバイルデバイスであるか、セットトップボックスであるか、アクセスポイントであるか、など)を有さない場合があり、またホストデバイスに関するロードステータスに関する知識を有さない可能性がある。したがって、他の使用事例では、埋込みデバイス820、825は、ホストデバイス810、830が、他のデバイス(たとえば、埋込みデバイス820、825)をホストする能力または意志を通知するときに提供する情報に基づいてホストデバイス830に適応的に接続してもよく、それによって、他のデバイスは、ホストデバイス810、830に関連する特性(たとえば、種類、ロードステータスなど)および/または埋込みデバイス820、825に関連する要件(たとえば、同じ製造業者から得られる、ホストデバイスに接続するための優先権を表すランキングテーブル)に従って近接度ベースの分散バスに参加してもよい。
様々な実施形態によれば、上記において概略的に説明した通信フレームワークは理想的には、異種IoTデバイスを接続し、異種IoTデバイス間の直接デバイス間(D2D)通信を有効化するためのプロセスを抽象化し簡略化するのに適していてもよい。したがって、本明細書においてさらに詳細に説明するように、IoT接続性モジュール900は、(たとえば、上述の通信フレームワークを使用する)IoTデバイスの接続をさらに簡略化することができるアーキテクチャを有してもよい。たとえば、IoT接続性モジュール900は概して、1つまたは複数のD2D通信フレームワーク(たとえば、AllJoyn(商標)、HomeKit、IoTivityなど)に関連する機能をラップするかまたは場合によってはカプセル化するハードウェアモジュールを備えてもよく、その場合、D2D通信フレームワークは、適切なプロセッサを有する接続されていない任意の既存の「モノ」を容易に接続し、それによって接続されていないモノを接続されたデバイスにするように配備することができる。
たとえば、図9を参照するとわかるように、接続されていないホスト920が他のモノ(たとえば、IoTデバイス940、942、944、1つまたは複数のクラウドサービス960など)に接続する必要があるホストプロセッサ922(通常マイクロコントローラユニット(MCU))を有すると仮定すると、ホストプロセッサ922は、ホスト920に関連する接続性および処理を分離する場合があるIoT接続性モジュール900に接続されることがある。より詳細には、様々な実施形態において、ホストプロセッサ922は、標準周辺インターフェース915を介してIoT接続性モジュール900に接続してもよく、標準周辺インターフェース915は、集積回路間(I2C)インターフェース、シリアル周辺インターフェース(SPI)、ユニバーサル非同期レシーバ/トランスミッタ(UART)インターフェース、高速チップ間(HSIC)インターフェース、またはホストプロセッサ922が実装するかまたは場合によってはサポートする別の適切な標準インターフェース915を備えてもよい。たとえば、ホストプロセッサ922がI2Cインターフェース915を介してIoT接続性モジュール900に接続すると仮定すると、接続性モジュール900は、ホストプロセッサ922のI2C周辺機器のように見える場合がある。さらに、IoT接続性モジュール900は、ホストプロセッサ922を他のIoTデバイス940、942、944、クラウドサービス960などに接続するのに必要な通信フレームワークに関連する様々なコアサービスを実装するコマンドプロトコルを実装してもよく、IoT接続性モジュール900は、他のIoTデバイス940、942、944、1つまたは複数のクラウドサービス960などに接続するための適切な下位レベルの詳細にさらに対処してもよい。
したがって、様々な実施形態では、IoT接続性モジュール900は、ホストプロセッサ922が標準インターフェース915を介してコマンドプロトコルをエクスポーズできるようにしてもよく、それによりホストプロセッサ922は、コマンドプロトコルをIoT接続性モジュール900を介して(たとえば、ホストプロセッサ922が自律的に作成し管理してもよい近接度ベースの分散バスを介して)他のIoTデバイス940、942、944などに接続し、さらに1つまたは複数のクラウドサービス960および/または他の適切なネットワークリソースに接続するように設定することができる。たとえば、図9に示すように、ホスト920は概して、1つまたは複数のセンサーおよび/またはアクチュエータ950とのインターフェース(たとえば、モーターとの接続、汎用入出力(GPIO)ピン、またはその他の適切な物理インターフェースを)備えてもよく、他のIoTデバイス940、942、944とのD2D通信に参加すること、クラウドサービス960を呼び出すことなどを行うために、D2D通信プロトコルに関連するコマンドを標準周辺インターフェース915を介してIoT接続性モジュール900に送信してもよい。さらに、様々な実施形態では、ホスト920は、消費すべきデータ(IoTデバイス940、942、944、クラウドサービス960などからの着信データ)が利用可能になったことをホストプロセッサ922に通知するためにアサートされる場合がある専用割込み信号回線917を介してIoT接続性モジュール900に結合されてもよい。
より詳細には、様々な実施形態において、標準インターフェース915を介してエクスポーズされたコマンドプロトコルには、ホストプロセッサ922が特に、インターフェースおよび構成のセットアップ、1つまたは複数の特性の設定および取得、通知およびその他の信号の送信および受信、特定の通知またはイベントに対する特定のアクションまたはイベントのトリガ、リモートメソッドの呼出し、メソッドの詳細の取得、ならびに特定のメソッド呼出しおよび/またはメソッド応答に対する特定のアクションまたはイベントのトリガを行うのを可能にするコマンドを含めてもよい。したがって、ホストプロセッサ922は、D2D通信フレームワークに関連する発表された1つまたは複数のコマンドを標準周辺インターフェース915を介してIoT接続性モジュール900に送信してもよく、ホスト920は、開発者コードを実行し、IoT接続性モジュール900において完全に実装されたD2D通信フレームワークに対応する実装論理またはビジネス論理を含むことができるD2Dアプリケーション924を含んでもよい。さらに、様々な実施形態では、IoT接続性モジュール900は、データが消費できるようになったこと(たとえば、コマンド戻り値、受信信号、コントロールパネル対話など)をホストプロセッサ922に示すために専用割込み信号回線917をアサートしてもよい。
したがって、標準周辺インターフェース915および専用割込み信号回線917は、IoT接続性モジュール900が、「適切な」D2D接続性ソリューションを実現してホスト920およびIoT接続性モジュール900をIoTデバイス930に変換することができるように、IoT接続性モジュール900とホスト920がD2D通信プロトコルに関連するデータを交換するのを可能にしてもよい。たとえば、IoT接続性モジュール900は、開発者がIoT接続性モジュール900上にコードをインストールする必要がなく、その代わり、シリアル化または他の適切なデータ交換プロトコル(たとえば、JavaScript(登録商標)オブジェクト表記法)を使用して実装されてもよい標準周辺インターフェース915を介してエクスポーズされたD2D通信プロトコルを介してIoT接続性モジュール900と対話するD2Dアプリケーション924内にすべての開発者コードをインストールする場合があるという点で適切であることがある。IoT接続性モジュール900側では、D2Dアプリケーション906は、(たとえば、図6〜図8に関して上記においてさらに詳細に説明したように)D2D通信プロトコルをD2D通信ネットワークとつなぐことができる埋込み(またはシンクライアント)アプリケーションを含んでもよい。したがって、ホスト920とIoT接続性モジュール900は、IoTデバイス930を任意の他のIoTデバイスのように見えるようにしかつ任意の他のIoTデバイスと同様に動作させるように1つのデバイスまたはモジュールとしてパッケージ化されてもよい。さらに、様々な実施形態では、D2Dアプリケーション906は、それぞれに異なるD2D通信フレームワークを実装するかまたはそれぞれに異なるD2D通信フレームワークに対するサポートを拡張し、それぞれに異なるD2D通信ソリューションを実装する場合がある他のIoTデバイスとの相互運用性を実現してもよい。
したがって、様々な実施形態では、IoT接続性モジュール900は、1つまたは複数の汎用インターフェースをサポートしてもよく、エクスポーズされたコマンドプロトコルは、ホストプロセッサ922が、標準周辺インターフェース915を介してIoT接続性モジュール900上でサポートされる汎用インターフェースの決定、有効化、名前変更、および/またはその他の構成を行うのを可能にしてもよい。その場合、IoT接続性モジュール900は、様々な実装形態においてそれぞれに異なる数の汎用インターフェースをサポートしてもよく、例示的な汎用インターフェースは以下の定義を有する場合がある。
<interface name=“org.allseen.AJM.generic1">
<property name=“prop1" type=“q" access=“readwrite" />
<property name=“bool1" type=“b" access=“read" />
...
</interface>
したがって、MCUに基づく大部分の既存の構成は標準インターフェースを有するので、IoT接続性モジュール900は既存の構成への接続性の付加を非常に簡単にする。さらに、ホスト920が、電力に接続した後SoftAPモードに入りネットワークにオンボーディングする準備を整えるだけでよいので、IoT接続性モジュール900は、ネットワークに対するサポートの負担を実質的に軽減する場合がある。さらに、IoT接続性モジュール900は、IoT接続性モジュール900が接続性をサポートするのに使用するネットワークプロトコルを将来開発されるネットワークプロトコルをサポートするように容易に変更される場合がある(たとえば、Wi-FiがBluetooth(登録商標) Low Energy、802.11ahなどと交換される場合がある)という点で、近位接続性を抽象化し、高レベルインターネットプロトコルを許容してもよい。したがって、いくつかの実施形態では、IoT接続性モジュール900は、高度に一体化されたホストレスソリューションを実現することがあり、その場合、IoT接続性モジュール900は、IoT接続性モジュール900が単一のモジュールにおいて完全なIoTプラットフォームを構成できるようにD2Dアプリケーション924を実装することができるユーザ空間(図示せず)を備えてもよい(たとえば、ホスト920とIoT接続性モジュール900を相互接続するのに使用される周辺インターフェース915と専用割込み信号回線917はチップ内仮想配線を構成してもよい)。しかし、図9に示すように、IoT接続性モジュール900は、周辺インターフェース915と専用割込み信号回線917が物理配線を構成するホスト型ソリューションを実現する。
様々な実施形態では、IoT接続性モジュール900は、ワイヤレスネットワークプラットフォーム(たとえば、QUALCOMM社によって開発されたQCA4002/4004チップオンボードソリューション)を実装する接続性チップ910を含んでもよい。たとえば、様々な実施形態では、接続性チップ910上に実装されるワイヤレスネットワークプラットフォームは、1つまたは複数のローカルシステムコントローラ、1つまたは複数のアンテナ、一体化された無線周波数(RF)フロントエンドとネットワークスタック、1つまたは複数のワイヤレス無線(たとえば、WLAN無線、Bluetooth(登録商標)無線など)、および/またはIoTデバイスにネットワーク接続性を付加するのに使用できる他の適切な構成要素との1つまたは複数のホストインターフェースを備えてもよい。さらに、IoT接続性モジュール900は、既存のMCU/プロセッサ構成を有するデジタルデバイスがSPI、I2C、UART、および/またはその他の標準インターフェースを介してサービスにアクセスするのを可能にする様々なアプリケーションプログラムインターフェース(API)904をエクスポーズしてもよく、IoT接続性モジュール900は、API 904がサポートするすべての下位レベルコマンドをパススルーしてもよい。さらに、D2Dアプリケーション906は、様々なコアサービスを実装してもよく、接続性通信フレームワークに関連する適切な下位レベル接続性の詳細に対処する(たとえば、通知、コントロールパネル、オンボーディング、構成、照明、ソフトウェア更新、イベント、アクションなどに関するサービス)。さらに、様々な実施形態では、製造業者は、サービス構成912(たとえば、デバイス名、サービス有効化、サービスへの入出力マッピングなど)を定義する能力を有し、かつD2Dアプリケーション906において実装されるサービスフレームワークをバインドすることができる埋込みJavaScript(登録商標)モジュールを実装するファームウェア908を有してもよい。たとえば、様々な実施形態では、ファームウェア908は、様々なMCUアーキテクチャ、メモリアーキテクチャ、センサーアーキテクチャ、およびその他の汎用入出力(GPIO)ピン902をサポートしてもよく、ファームウェア908は、さらに単純に更新されてもよい(たとえば、ファームウェア908をロードするうえでジョイントテストアクショングループ(JTAG)テストインターフェースは必要とされないことがあり、ファームウェア908はオーバージエア(OTA)更新を必要としない場合がある)。
様々な実施形態では、ネットワーク接続性およびD2D通信をサポートする能力をホスト920に付加するのに使用されるインターフェースを定義するうえで1つまたはいくつかの異なる手法が使用されてもよい。たとえば、第1の手法は、実行時インターフェース定義を含んでもよく、ホスト920は、このインターフェース定義を(JavaScript(登録商標)オブジェクト表記法(JSON)、XML、または別の適切なデータ交換プロトコルを使用して)周辺インターフェースを介してIoT接続性モジュール900に送信してもよい。IoT接続性モジュール900は、ホスト920からインターフェース定義を受信したことに応答して、定義されたインターフェースを実装し、近位ネットワークを介して(たとえば、近接度ベースの分散バスを介して)通知してもよい。さらに、ホスト920はその後、エクスポーズされたD2D通信フレームワークに関連する特定のコマンドをIoT接続性モジュール900に送信することによって実行時手法においてインターフェース定義を削除し、更新し、追加し、または場合によっては修正してもよい。第2の手法では、再構成可能なインターフェースが使用されてもよく、IoT接続性モジュール900は、後でファームウェア908への更新を介して更新しならびに/あるいは製造時に新しいバージョンに組み込むことが可能である事前構成された様々なD2D通信インターフェースを含むように製造されてもよい。再構成可能なインターフェースを使用する実施形態では、ホスト920は、周辺インターフェース915を介してIoT接続性モジュール900にGetSupportedInterfacesコマンドを送信してもよく、IoT接続性モジュール900は次いで、IoT接続性モジュール900上でサポートされる事前構成されたインターフェースをホスト920に返してもよい。さらに、ホスト920は、IoT接続性モジュール900にSetEnabledInterfacesコマンドを送信して特定のインターフェースを有効化すること、IoT接続性モジュール900にDefineInterfaceNameコマンドを送信して(たとえば、汎用インターフェースから特定のインターフェースを作成するために)特定のインターフェースの名前を変更することなどを行ってもよい。さらに別の手法では、抽象化されたインターフェースが使用されてもよく、IoT接続性モジュール900は、1つまたは複数のインターフェースの集合として表される1つまたは複数の公知のサービスを含むように製造されてもよく、これらのインターフェースは同様に、ファームウェア908への更新を介して更新されならびに/あるいは製造時に新しいバージョンに組み込まれてもよい。しかし、抽象化インターフェース手法は、プロトコルおよびサービスがホストプロセッサ922から抽象化されるという点が異なる場合がある。たとえば、サービス構成フレームワーク912は、特定のD2D通信フレームワークに従って1つまたは複数のデバイス特性(たとえば、デバイス名)を定義するのに使用されてもよく、ホストプロセッサ922とのインターフェースは、サービス構成フレームワーク912が特性を定義するのに使用するD2D通信フレームワークに固執しないようにデバイス特性を設定し取り出す(たとえば、ホストプロセッサ922がよりなじみが深いかまたは他の製品との互換性を有する場合がある他のインターフェースを実装するのを可能にする)ためのメソッドをエクスポーズしてもよい。したがって、ホスト920が周辺インターフェース915および割込み信号回線917を介してIoT接続性モジュール900と通信するのに使用するデータ交換プロトコルに影響を与えずに同じIoT接続性モジュール900を他のプロトコルをサポートするように更新してもよい。
したがって、上述のIoT接続性モジュール900は、ネットワーク接続性およびD2D通信をサポートする能力を接続されていないホスト920に付加し、それによって、接続されていないホスト920を、他のIoTデバイス940、942、944、クラウドサービス960の発見ならびに他のIoTデバイス940、942、944、クラウドサービス960との接続および直接通信を行うか、あるいは他のネットワークサービスを利用することのできるIoTデバイス930にすることのできるターンキーソリューションを実現してもよい。
たとえば、様々な態様によれば、図10は、上述のIoT接続性モジュール900が場合によっては接続されていないホストに接続性を付加するために実装する場合がある近位D2D通信フレームワークに関連する例示的なアーキテクチャ1000を示す。より詳細には、図6〜図8に関して上記において説明したように、近位D2D通信フレームワークは、別々の物理ホストデバイス上に存在する複数のバスセグメントを含む近接度ベースの分散バスを確立するのに使用されてもよく、各ホストデバイスは、ローカルバスルータを実行して近接度ベースの分散バス上にローカルセグメントを実装してもよい。さらに、近接度ベースの分散バス上にローカルセグメントを形成するために図10に示すアーキテクチャ1000を実装する任意の特定のホストデバイスは、ローカルバスルータに接続する1つまたは複数のバスアタッチメント(たとえば、1つまたは複数のサービス、サービスを要求する場合がある1つまたは複数のクライアントなど)を有してもよい。したがって、IoT接続性モジュールは、ローカルバスセグメントをホストするために図10に示すアーキテクチャ1000を実装してもよく、接続されていないホストは基本的に、ホストが近接度ベースの分散バスにアタッチされた他のエンドポイントとのD2D(またはP2P)通信に参加できるように、ローカルバスセグメント上のバスアタッチメントに相当してもよい。したがって、ローカルバスルータは概して、バックグラウンドにおいて実行されて近接度ベースの分散バスを監視し、近接度ベースの分散バスを介して伝達される対象となる1つまたは複数のイベントを検出し、必要に応じて1つまたは複数のイベントに応答してもよい。これらのイベントは通常、(たとえば、近接度ベースの分散バス上の別のノードによって生成された)外部イベントであるので、以下では、アーキテクチャ1000における様々な構成要素について下位レベルの構成要素から順に説明する。
特に、アーキテクチャ1000は、最下位レベルにおいてネイティブシステム1010を含み、ネイティブシステム1010よりも上にオペレーティングシステムアブストラクションレイヤ1020が存在する場合がある。オペレーティングシステムアブストラクションレイヤ1020は、様々な異なるオペレーティングシステム上で動作するルータに対して共通の抽象化を実行してもよく、様々な異なるオペレーティングシステムには、Linux(登録商標)オペレーティングシステム、Windowsオペレーティングシステム、Androidオペレーティングシステムなどを含めてもよい。近接度ベースの分散バスに接続するクライアント、サービス、およびピアは概して、ローカルプロセス間通信機構を使用してバスルータと通信するので、アーキテクチャ1000は、オペレーティングシステムアブストラクションレイヤ1020上で動作する様々な下位レベルネットワーキング構成要素をさらに含んでもよく、これにより、このルータは、所与のプラットフォーム上の様々な利用可能なトランスポート機構に対処する責任を有する。特に、図10に示すように、下位レベルネットワーキング構成要素は、特定のホスト型バスセグメント上で動作するクライアント、サービス、ピアとの単独の接続に相当する場合がある「ローカル」トランスポート機構1032を含んでもよい。たとえば、様々な態様によれば、Bluetooth(登録商標)トランスポート機構1034は、Bluetooth(登録商標)システムにおけるピコネットの作成および管理に関連する複雑さに対処してもよい。さらに、Bluetooth(登録商標)トランスポート機構1034は、信頼できる通信を確保することに加えて、Bluetooth(登録商標)に適切な1つまたは複数のサービス通知および発見機能を実現してもよい。したがって、オペレーティングシステムアブストラクションレイヤ1020よりも上に、インターネットプロトコル(IP)トランスポート機構1038と並んで、ローカルトランスポート機構1032、Bluetooth(登録商標)トランスポート機構1034、および/またはその他のトランスポート機構1036が設けられてもよい。さらに、図10に示すように、有線トランスポート機構、Wi-Fiトランスポート機構、およびWi-Fiダイレクトトランスポート機構がIPトランスポート機構1038よりも下方においてグループ化されてもよい。その理由としては、これらのトランスポート機構の各々が下方のTCP/IPネットワークスタックを使用することが挙げられる。いくつかの使用事例では、サービスの通知および発見がどのように実現され得るかに関して違いがある場合がある。その理由としては、そのような機能がTCP/IP標準の範囲外であることが挙げられる。したがって、IPトランスポート機構1038は、サービス通知および発見機能を実装するための1つまたは複数のモジュールを含んでもよい。
様々な実施形態によれば、基本的にWi-Fi接続、非Wi-Fi(たとえば、Bluetooth(登録商標))接続、有線イーサネット(登録商標)接続などの間に違いがなくなるように、上記において説明した技術固有の様々なトランスポート実装形態は、ネットワークトランスポートアブストラクション1030として集合化されてもよい。様々な態様によれば、セッションモジュール1040は、ネットワークトランスポートアブストラクション1030上に存在してもよく、セッションモジュール1040は、近位D2D通信フレームワークに関連する1つまたは複数のルータおよび1つまたは複数のアプリケーションが統合されたソフトウェアバスに見えるように通信接続を確立して維持するための手順に対処してもよい。その点において、アーキテクチャ1000は、1つまたは複数のローカルクライアント、サービス、および/またはピアとの接続を確立し、エンドポイントオブジェクトに関連する使用を、バスルータが近接度ベースの分散バスを介してメッセージを送信するのに使用するトランスポートを表すバス間接続に拡張するためのエンドポイントレイヤ1041を含んでもよい。
ルータアーキテクチャ1000は、バス間接続が意味するルーティング機能に加えて、ルータアーキテクチャ1000を介して実装されたローカルバスセグメントに相当する1つまたは複数の分散バスオブジェクト1049を管理するのに使用される1つまたは複数のバスオブジェクト1047に相当するエンドポイント1041を含んでもよい。したがって、エンドポイントレイヤ1041とバスオブジェクト1047、1049との間にメッセージングおよびルーティングレイヤ1043が存在してもよく、メッセージングおよびルーティングレイヤ1043は、パラメータおよび戻り値を近接度ベースの分散バスを介して送信されるメッセージにマーシャルしアンマーシャルするための機能を実現してもよい。メッセージングおよびルーティングレイヤ1043は、(たとえば、ホストとアーキテクチャ1000を実装するIoT接続性モジュールとの間に結合された専用物理割込み回線をアサートすることによって)適切なバスオブジェクトおよびプロキシにインバウンドメッセージを伝達するようにさらに構成されてもよく、メッセージングおよびルーティングレイヤ1043は、近接度ベースの分散バス上の他のバスアタッチメントに伝達すべきメッセージを送信するようにさらに構成されてもよい。したがって、メッセージングおよびルーティングレイヤ1043は、エンドポイントレイヤ1041と通信してもよく、近位D2D通信フレームワークは、あるエンドポイントをより下位レベルの別のエンドポイントに移動させてもよい。たとえば、特定のサービスが周知のバス名を通知することを要求するとき、その要求は、ルータ上に実装されたバスオブジェクト1047、1049宛てのリモートメソッド呼出しに変換されてもよい。ルータは、サービスの場合と同様に、特定の名前を有するインターフェースを実装する対応するオブジェクトパスに関連する様々なバスオブジェクト1047、1049を有してもよい。近接度ベースの分散バスを介した通信を制御するための下位レベル機構は、そのようなルータバスオブジェクト1047、1049にリモートメソッド呼出しを送信することを含んでもよい。
様々な態様によれば、最上位レベルにおいて、図10に示すアーキテクチャ1000は、バスルータに関連する全体的な動作を制御する構成サブシステム1050を含んでもよく、この動作は、システム管理者、OEM、ユーザ、または別の適切なエンティティが、いくつかの許可を指定し、必要に応じてサービスを作成する能力を実現するのを可能にする場合がある。さらに、構成システム1050は、バスルータが消費することのできるリソースを制限する(たとえば、任意の所与の時間にアクティブになるTCP接続を特定の最大値に制限する)1つまたは複数のパラメータを定義し、サービス拒否(DoS)攻撃による影響を防止しならびに/あるいは軽減する(たとえば、現在認証する接続を制限する)のに使用されてもよい。さらに、セキュリティモジュール1045が、アプリケーション同士が互いに認証し、暗号化されたデータを送信し、それによってエンドツーエンドアプリケーションレベルセキュリティを確立することを可能にしてもよい。特に、アプリケーションにおいて認証およびデータ暗号化が実施されてもよく、アプリケーションは、同じデバイス上に存在することもあるいはそれぞれに異なるデバイス上に存在することも可能であり、同じバスルータにアタッチすることもあるいはそれぞれに異なるバスルータにアタッチすることも可能である。したがって、アプリケーションは、消費者アプリケーションがセキュアインターフェース上でメソッド呼出しを実行しならびに/あるいはAPIを明示的に呼び出してリモートピアアプリケーションとの接続をセキュアにするときに、インターフェースを「セキュア」とタグ付けし、必要に応じて認証関連鍵交換および暗号化関連鍵交換を開始することができる。したがって、セキュリティモジュール1045は、認証鍵および暗号化鍵を鍵ストアに記憶し、認証証明情報(たとえば、PINまたはパスワード)に関して使用されならびに/あるいは認証証明情報を検証する(たとえば、証明チェーンを検証する)のに使用されるリスナーコールバック関数によって認証手順および暗号化手順を支援してもよい。
様々な態様によれば、図11および図12は、適切なプロセッサまたはマイクロコントローラユニット(MCU)を有するホスト1120、1220と上記においてさらに詳細に説明した特徴を実現する場合があるIoT接続性モジュール1100、1200との間の例示的なシグナリングフローを示す。概して、図11および図12に示すシグナリングフローは、IoT接続性モジュール1100、1200がエクスポーズし標準インターフェースを介してホスト1120、1220に送信するコマンドプロトコルに従って動作してもよい。たとえば、様々な態様によれば、コマンドプロトコルは、以下のTable 1(表1)に示すようにコマンドおよびパラメータに関するパケット構造を定義し、以下のTable 2(表2)に示すようにコマンドバイトに関するバイト構造をさらに定義してもよい。
したがって、ホスト1120、1220とIoT接続性モジュール1100、1200との間で送信される各コマンドおよびパラメータは、上記のTable 1(表1)において定義される構造を有するパケットを備え、ホスト1120、1220とIoT接続性モジュール1100、1200との間で送信されるパケット内のコマンドバイトは、上記のTable 2(表2)に示すような構造を有してもよい。その場合、コマンドが、コマンドバイトの直後に送信すべき複数のパラメータを有するときにはCmdExtビットが使用されてもよい。したがって、CmdExtビットがセットされたときには、ビット5〜ビット0が現在のコマンドに関するパラメータ番号を指定してもよく、現在のパケットが最後のコマンドパケットである場合にはDoneビットがセットされてもよい。したがって、コマンドが1つのパケットのみを有する場合、Doneビットは一般に、そのパケットにおいて設定される。さらに、Table 1(表1)では、コマンド参照番号は、ホスト1120、1220がIoT接続性モジュール1100、1200から返された値を追跡するために割り当てる参照識別子を備えてもよく、コマンド参照番号は、ホスト1120、1220が戻り値の順番が狂ってもそのまま追跡を続ける場合には零に設定されてもよく、その場合、ホスト1120、1220は、次のコマンドを発行する前にあらゆるコマンドからの応答を待ってもよい。さらに、IoT接続性モジュール1100、1200がホスト1120、1220に送信するすべてのデータが同じ標準インターフェースを介して送られるが、ホスト1120、1220は常にマスタであり、IoT接続性モジュール1100、1200からデータを送信することを要求する。したがって、IoT接続性モジュール1100、1200がホスト1120、1220に非同期的に送信すべきデータ(たとえば、着信信号、イベント、通知、コントロールパネル対話など)を有する場合、IoT接続性モジュール1100、1200は別個の割込み信号回線をアサートしてホスト1120、1220に保留中のデータを通知してもよい。
さらに、様々な態様によれば、IoT接続性モジュール1100、1200がエクスポーズしホスト1120、1220に送信するコマンドプロトコルは、以下のTable 3(表3)〜Table 7(表7)に示すようにIoT接続性モジュール1100、1200がホスト1120、1220に返すデータに関するパケット構造を定義してもよく、IoT接続性モジュール1100、1200は一般に、コマンドに関するすべての戻りパケットが連続する1つのユニットとして(すなわち、複数のコマンドからのパケットをインターリーブすることなしに)送信されるようにしてもよい。
上記において定義されたコマンドプロトコル構造に従って、以下のTable 8(表8)に示すように、IoT接続性モジュール1100、1200は、ホスト1120、1220において発信された各パケットに肯定応答してもよく、ホスト1120、1220は同様に、IoT接続性モジュール1100、1200において発信された各パケットに肯定応答してもよい。したがって、いずれの場合も、発信デバイスは、値が再送信をトリガするための「1」に設定された肯定応答パケットを受信したことに応答してパケットを再送信してもよい。
上記において定義された様々なコマンドプロトコル構造に従って、以下のTable 9(表9)は、ホスト1120、1220にエクスポーズされる場合がある様々なコマンドを示す。
したがって、図11を参照するとわかるように、ホスト1120は、(たとえば、ホスト1120をIoT接続性モジュール1100に結合する標準周辺配線を介して)IoT接続性モジュール1100にコマンドパケットを送信することによって図11の1170に示す例示的なシグナリングフローを開始してもよい。IoT接続性モジュール1100は次いで、1172においてホスト1120に肯定応答パケットを送信してもよく、ホスト1120は次いで、1174において肯定応答パケットの値が「0」であることに応答してIoT接続性モジュール1100に1つまたは複数のパラメータパケットを送信してもよく、肯定応答パケットの値が「0」ではない場合、ホスト1120は、肯定応答パケットの値が「1」であることに応答して、IoT接続性モジュール1100からの肯定応答メッセージが、コマンドパケットが首尾よく受信されたことを示すまで、IoT接続性モジュールにコマンドパケットを再送信してもよい。さらに、上述のように、IoT接続性モジュール1100は、1176に示すように、各パラメータパケットに応答してホスト1120に肯定応答パケットを送信してもよく、ホスト1120は、肯定応答パケットに関連する値に応じて、前のパケットを再送信するかまたはキューにおける次のパケットを送信してもよい。様々な態様によれば、ホスト1120が適用可能なすべてのパラメータパケットを送信した後、IoT接続性モジュール1100は、1174に示す様々なパラメータに従って、1170に示された適切なコマンドを呼び出してもよい。その後のある時点において、IoT接続性モジュール1100は、ホスト1120に伝達すべきインバウンドデータを受信し、1178に示すように、ホスト1120においてインバウンドデータが消費できるようになったことをホスト1120に通知するために専用割込み回線をアサートしてもよい。それに応答して、ホスト1120は、1180に示すように、利用可能なインバウンドデータを要求するためのメッセージを送信してもよく、IoT接続性モジュールは次いで、1182に示すように、利用可能なインバウンドデータを含む1つまたは複数のパケットをホスト1120に送信してもよい。さらに、上述のように、ホスト1120は、1184に示すように、利用可能なインバウンドデータを保持する各パケットに応答してIoT接続性モジュール1100に肯定応答パケットを送信してもよく、IoT接続性モジュール1100は、肯定応答パケットに関連する値に応じて、前のインバウンドデータパケットを再送信するかまたは次のインバウンドデータパケットを送信してもよい。
様々な態様によれば、次に図12を参照するとわかるように、IoT接続性モジュール1200がホスト1220に伝達すべきインバウンドデータを受信したことに応答して、IoT接続性モジュール1200において、図12に示す例示的なシグナリングフローが開始されてもよい。特に、IoT接続性モジュール1200は、ホスト1200に伝達すべきインバウンドデータを受信したことに応答して、1278に示すように、ホスト1220においてインバウンドデータが消費できるようになったことをホスト1220に通知するために専用割込み回線をアサートしてもよい。それに応答して、ホスト1220は、1280に示すように、利用可能なインバウンドデータを要求するためのメッセージを送信してもよく、IoT接続性モジュール1200は次いで、1282に示すように、利用可能なインバウンドデータを含む1つまたは複数のパケットをホスト1220に送信してもよい。さらに、上述のように、ホスト1220は、1284に示すように、利用可能なインバウンドデータを保持する各パケットに応答してIoT接続性モジュール1200に肯定応答パケットを送信してもよく、IoT接続性モジュール1200は、肯定応答パケット値に応じて、前のインバウンドデータパケットを再送信するかまたは次のインバウンドデータパケットを送信してもよい。その後のある時点において、ホスト1220は、1270に示すように、前のインバウンドデータに基づいてIoT接続性モジュール1200にコマンドパケットを送信してもよく、IoT接続性モジュール1200は、1272に示すように、ホスト1220に肯定応答パケットを送信してもよい。したがって、ホスト1220は次いで、IoT接続性モジュール1200に1つまたは複数のパラメータパケットを送信してもよく、IoT接続性モジュール1200は、1274、1276に示すように、上記において説明したのと同様に各パラメータパケットに応答してホスト1220に肯定応答パケットを送信してもよい。したがって、ホスト1220が適用可能なすべてのパラメータパケットを送信した後、IoT接続性モジュール1200は、1274に示す様々なパラメータに従って1270に示された適切なコマンドを呼び出してもよく、したがって、ホスト1220とIoT接続性モジュール1200との間の通信が継続してもよい。
様々な態様によれば、図13〜図17は、上記においてさらに詳細に説明したIoT接続性モジュールを実装する場合がある様々な例示的な使用事例を示す。したがって、説明を簡潔にかつ容易にするために、図13〜図17に示す例示的な使用事例に関する以下の説明は、そのような事例に固有の特定の詳細に焦点を当て、それによって、図13〜図17に示す例示的な使用事例に関連するいくつかの構成要素および/または機能に関する様々な詳細は、同じ詳細または同様の詳細がすでに記載されている限り省略される場合がある。したがって、当業者には、図13〜図17に示す様々な例示的な使用事例が、本明細書において明示的に説明するか否かにかかわらず、場合によっては接続されていないホストと一体化され、それによって接続されていないホストを接続されたIoTデバイスに変換する場合があるIoT接続性モジュールに関して上記において説明した構成要素および/または機能と同じであるかまたは実質的に同様の様々な追加の構成要素および/または機能を含んでもよいことが諒解されよう。
次に、図13を参照すると、アナログデバイス1326(たとえば、コンセント、スイッチ、ボタン、扇風機、照明器具、ガレージドアオープナー、センサーなど)に接続性を付加するために相手先商標製造会社(OEM)回路1320にIoT接続性モジュール1300が結合される場合がある例示的な使用事例が示されている。より詳細には、図13に示す例示的な使用事例では、IoT接続性モジュール1300は、電力モジュール1314と1つまたは複数のGPIOピン1302とを含んでもよい。したがって、アナログデバイス1326は、OEM回路1320を通してIoT接続性モジュール1300に接続してもよく、OEM回路1320は、1つまたは複数のGPIOピン1302に接続する周辺インターフェース1315を介してIoT接続性モジュール1300と一体化されてもよい。さらに、様々な実施形態では、専用割込み信号回線1317がOEM回路1320およびIoT接続性モジュール1300に結合されてもよく、IoT接続性モジュール1300は、着信データが消費できるようになったときに専用割込み信号回線1317をアサートしてOEM回路1320に通知してもよい。したがって、図13に示す例示的な使用事例は、OEMがファームウェアを開発することなしにアナログデバイス1326に接続性を付加し、それにより、OEM回路1320をIoT接続性モジュール1300と一体化してアナログデバイス1326をOEM回路1320に接続することによってアナログIoTデバイス1330を製造するのを可能にしてもよい。たとえば、製造業者において、デバイス名、有効化すべきサービス、GPIOピン1302に関連する入力といくつかのイベントとの間のマッピング、いくつかのアクションとGPIOピン1302に関連する出力との間のマッピング、およびイベント、アクション、コントロールパネルなどに関する人間が読み取れるテキストを定義するための構成が設けられてもよい。さらに、IoT接続性モジュール1300は、接続性をカスタマイズするのに使用することができる様々な集積サービスを提供してもよい(たとえば、アンテナ集積、回路集積、カスタム電力要件など)。したがって、OEM回路1320を通してアナログデバイス1326に接続される場合があるIoT接続性モジュール1300は、非反復エンジニアリング費用(NRE)、ソースファームウェアを開発する必要性、およびアナログIoTデバイス1330を製造する際の品質保証(QA)のための労力を実質的に低減させる。
次に、図14を参照すると、デジタルデバイス1426(たとえば、ハイエンドキッチンアプライアンス)に接続性を付加するためにOEM MCUモジュール1420にIoT接続性モジュール1400が結合される場合がある例示的な使用事例が示されている。より詳細には、図14に示す例示的な使用事例において、OEM MCUモジュール1420は、ローカル電源1428を有し、周辺インターフェース1415(たとえば、UART、SPI、I2Cなど)および1つまたは複数のAPI 1404を介してIoT接続性モジュール1400と一体化してもよく、それによって、OEMが、既存のアプリケーションに対する変更(もしあれば)を最低限に抑えながらデジタルデバイス1426に接続性を付加するのを可能にする。さらに、様々な実施形態では、専用割込み信号回線1417がOEM MCUモジュール1420およびIoT接続性モジュール1400に結合されてもよく、IoT接続性モジュール1400は、着信データが消費できるようになったときに専用割込み信号回線1417をアサートしてOEM MCUモジュール1420に通知してもよい。さらに、製造業者において、デバイス名、有効化すべきサービス、およびイベント、アクション、コントロールパネルなどに関する人間が読み取れるテキストを定義するための構成が設けられてもよい。さらに、IoT接続性モジュール1400は同様に、接続性をカスタマイズするのに使用することができる様々な集積サービスを提供してもよい(たとえば、アンテナ集積、回路集積、カスタム電力要件など)。したがって、OEM MCUモジュール1420を通してデジタルデバイス1426に接続されることがあるIoT接続性モジュール1400は、NREおよびQA労力を実質的に低減させ、ポーティングを不要にし、デジタルIoTデバイス1430を製造するためのデジタルデバイス1426へのベースサービスの付加を簡略化する場合がある。
次に、図15を参照すると、IoT接続性モジュール1500が、アナログ機能およびデジタル機能を有する多機能デバイス1526に接続性を付加する場合がある例示的な使用事例が示されており、図15に示すIoT接続性モジュール1500は概して、図13に示すIoT接続性モジュール1300によって実現される機能と図14に示すIoT接続性モジュール1400によって実現される機能を組み合わせる場合がある。より詳細には、図15に示す例示的な使用事例では、多機能デバイス1526は、ローカル電源1528とアナログ機能およびデジタル機能とを有するOEM MCUモジュール1520を介してIoT接続性モジュール1500に接続する場合があり、アナログ機能およびデジタル機能を有するOEM MCUモジュール1520は、周辺インターフェース1515(たとえば、UART、SPI、I2C、および/または他の適切な標準周辺インターフェース)を介してIoT接続性モジュール1500に関連する1つまたは複数のAPI 1504および1つまたは複数のGPIOピン1502と一体化してもよいさらに、図13および図14に示す例示的な使用事例と同様に、専用割込み信号回線1517がOEM MCUモジュール1520およびIoT接続性モジュール1500に結合されてもよく、それによって、IoT接続性モジュール1500は、着信データが消費できるようになったときに専用割込み信号回線1517をアサートしてOEM MCUモジュール1520に通知してもよい。したがって、1つまたは複数のGPIOピン1502が、OEM MCUモジュール1520を通して多機能デバイス1526内の1つまたは複数のアナログ構成要素に接続性を付与してもよく、かつ1つまたは複数のAPI 1504が、OEM MCUモジュール1520に関連する1つまたは複数のデジタルインターフェースに接続して多機能デバイス1526に関連する1つまたは複数のデジタル構成要素に接続性を付与し、それによって多機能アナログおよびデジタルIoTデバイス1530を作成してもよい。
次に、図16を参照すると、IoT接続性モジュール1600を使用してメーカーボード1630(たとえば、Arduinoボード、Beagleboneボード、Raspberry Piボード、または他の適切なDIY(do-it-yourself)メーカーボード)に接続性を付加する場合がある例示的な使用事例が示されている。より詳細には、様々な態様によれば、メーカーボード1630は、MCU 1620または他の適切なプロセッサに結合された1つまたは複数のGPIOピン1626および/または他の適切な電子構成要素を備えてもよく、MCU 1620または他の適切なプロセッサは、IoT接続性モジュール1600に関連する1つまたは複数のGPIOピン1602および1つまたは複数のAPI 1604と周辺インターフェース1615を介して一体化してもよい。したがって、メーカーボード1630は、IoT接続性モジュール1600上に実装された近位デバイス間(D2D)通信フレームワークに伴う利点を活用して近接する他のデバイスとピアツーピアで容易に通信する場合がある。さらに、図13〜図15に示す例示的な使用事例と同様に、メーカーボード1630上でIoT接続性モジュール1600からMCU 1620に至る専用割込み信号回線1617が設けられてもよく、それによって、MCU 1620は、IoT接続性モジュール1600が専用割込み信号回線1617をアサートしたことに応答して着信データが消費できるようになったときにそれを判定してもよい。代替使用事例では、IoT接続性モジュール1600はスタンドアロンアーキテクチャを有してもよく、その場合、メーカーボード1630は必ずしもMCU 1620を有するとは限らない。さらに、特定の使用事例に応じて、IoT接続性モジュール1600は、関連する場合がある適用可能な任意の遮蔽要件に応じて特定のメーカーボード1630に適合するように設計された形状係数を有してもよい。さらに、図13〜図15に関して上記において説明した例示的な使用事例と同様に、デバイス名、有効化される1つまたは複数のサービス、GPIOピン1602、1626と1つまたは複数のイベント、アクション、および/またはコントロールパネルサービスとの間のマッピング、ならびに1つまたは複数のイベント、アクション、および/またはコントロールパネルサービスなどに関する人間が読み取れるテキストを指定するための構成がIoT接続性モジュール1600内に画定されてもよい。したがって、メーカーボード1630に内蔵されたIoT接続性モジュール1600は、多くの利点をもたらし、特に、学習曲線を実質的に改善し、様々なDIYプラットフォームおよび形状係数との適合性を実現し、小形のMCU 1620をサポートする場合がある。
次に、図17を参照すると、IoT接続性モジュール1700を使用して照明コントローラ1730に接続性を付加する場合がある例示的な使用事例が示されている。図17に示す例示的な使用事例では、IoT接続性モジュール1700は、電力モジュール1714とパルス幅変調(PWM)モジュール1716とを含んでもよい。たとえば、様々な態様によれば、PWMモジュール1716は、1つまたは複数の電気パルスに関連する幅を調節して、照明コントローラ1730を通して電力モジュール1714から照明システムに供給される電力を制御してもよい。概して、IoT接続性モジュール1700は、照明サービスフレームワークを実装してターンキーソリューションを構成してもよく、このターンキーソリューションは、周辺インターフェース1715を介して照明コントローラ1730に内蔵することができる接続された多色発光ダイオード(LED)照明システムを構築するのに使用されてもよい。周辺インターフェース1715は、接続性モジュール1700をMCU 1720に結合し、MCU1720はさらに、1つまたは複数のGPIOピン1726に結合される。さらに、図13〜図16に示す例示的な使用事例と同様に、IoT接続性モジュール1700からMCU 1720に至る専用割込み信号回線1717が設けられてもよく、MCU 1620は、IoT接続性モジュール1700が専用割込み信号回線1717をアサートしたことに応答して着信データが消費できるようになったことを判定してもよい。したがって、照明コントローラ1730に内蔵されてもよいIoT接続性モジュール1700は、スマート照明開発に伴うNREを実質的に削減し、照明電力消費量を減らし、照明材料表(BOM)を改善し、MCUを有さない場合がある照明システムを制御する。特に、様々な態様によれば、照明サービスフレームワークは、埋込み照明デバイス(たとえば、接続された電球)をコントローラサービスによって制御するのを可能にすることができるコントローラサービスおよびランプサービスを含んでもよい。たとえば、様々な態様によれば、照明OEMは、スマート照明フィーチャを有効化するために照明製品に関連付けられたファームウェアにランプサービスを埋め込むことができ、コントローラサーバは、ランプサービスを実行する近位ネットワークにおける1つまたは複数のデバイスを見つけ、照明デバイスを様々な方法で制御する(たとえば、複数のライトを同時に制御したり、カスタム照明効果を適用したり、ライトのオンとオフを切り替えたり、電力消費量およびライトの詳細を取り込んだり、輝度または色相を設定したりすることなど)の追加の機能を実現するように構成されてもよい。
本開示の一態様によれば、図18は、本明細書において開示する様々な態様および実施形態による、他の近位デバイスとの直接D2D通信をサポートする場合がある例示的な通信デバイス1800を示す。たとえば、様々な態様によれば、図18に示す通信デバイス1800は、上述の接続性モジュールを場合によっては接続されていないホストと一体化することによって得られることがあるIoTデバイスを表す場合がある。特に、図18に示すように、通信デバイス1800は、たとえば、受信アンテナ(図示せず)から信号を受信し、受信信号に対して典型的なアクション(たとえばフィルタ処理、増幅、ダウンコンバートなど)を実行し、条件付きの信号をデジタル化してサンプルを取得するレシーバ1802を備えてもよい。レシーバ1802は、受信されたシンボルを復調し、復調されたシンボルをチャネル推定のためにプロセッサ1806に提供することができる復調器1804を備えてもよい。プロセッサ1806については、レシーバ1802によって受信された情報の分析および/またはトランスミッタ1820によって送信される情報の生成専用に使用すること、通信デバイス1800の1つまたは複数の構成要素を制御すること、ならびに/あるいはそれらの任意の適切な組合せが可能であってもよい。
様々な実施形態では、通信デバイス1800は、プロセッサ1806に動作可能に結合されたメモリ1808をさらに備えることができ、メモリ1808は、受信されたデータ、送信すべきデータ、利用可能なチャネルに関連する情報、分析された信号および/または干渉強度に関連するデータ、割り当てられたチャネル、電力、レートなどに関連する情報、およびチャネルを推定し、チャネルを介して通信するための任意の他の適切な情報を記憶することができる。一態様では、メモリ1808は、1つまたは複数のローカルエンドポイントアプリケーション1810を含むことができ、ローカルエンドポイントアプリケーション1810は、分散バスモジュール1830を通じた通信デバイス1800および/または他の通信デバイス(図示せず)上のエンドポイントアプリケーション、サービスなどとの通信を求めてもよい。メモリ1808は、(たとえば、性能ベース、容量ベースなど)チャネルの推定および/またはチャネルの使用に関連付けられたプロトコルおよび/またはアルゴリズムをさらに記憶することができる。
当業者には、本明細書で説明するメモリ1808が、揮発性メモリもしくは不揮発性メモリであることが可能であり、または揮発性と不揮発性の両方のメモリを含むことが可能であることが諒解されよう。限定ではなく例として、不揮発性メモリは、読取り専用メモリ(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(登録商標))などの多くの形で使用可能である。対象のシステムおよび方法におけるメモリ1808は、それだけに限定されないが、これらの種類のメモリおよび任意の他の適切な種類のメモリを備えてもよい。
様々な実施形態では、通信デバイス1800に関連する分散バスモジュール1830は、他のデバイスとの接続を確立するのをさらに容易にすることができる。分散バスモジュール1830は、分散バスモジュール1830が複数のデバイス間の通信を管理するのを助けるためのバスノードモジュール1832をさらに備えてもよい。一態様では、バスノードモジュール1832は、バスノードモジュール1832が他のデバイスに関連するエンドポイントアプリケーションと通信するのを助けるためのオブジェクト命名モジュール1834をさらに含んでもよい。さらに、分散バスモジュール1830は、ローカルエンドポイントアプリケーション1810が確立された分散バスを通じて他のローカルエンドポイントおよび/または他のデバイス上のアクセス可能なエンドポイントアプリケーションと通信するのを助けるためのエンドポイントモジュール1836を含んでもよい。別の態様では、分散バスモジュール1830は、複数の利用可能なトランスポート(たとえば、Bluetooth(登録商標)、Unixドメインソケット、TCP/IP、Wi-Fiなど)を介したデバイス間通信および/またはデバイス内通信を容易にしてもよい。したがって、一実施形態では、分散バスモジュール1830およびエンドポイントアプリケーション1810を使用して、通信デバイス1800が直接デバイス間(D2D)通信を使用して通信デバイス1800に近接する他の通信デバイスと通信することができる近接度ベースの分散バスを確立しならびに/あるいはそのような近接度ベースの分散バスに参加してもよい。
さらに、一実施形態では、通信デバイス1800は、ユーザインターフェース1840を含んでもよく、ユーザインターフェース1840は、通信デバイス1800への入力を生成するための入力機構1842と、通信デバイス1800のユーザによって消費される情報を生成するための出力機構1844とを含んでもよい。たとえば、入力機構1842は、キーまたはキーボード、マウス、タッチスクリーンディスプレイ、マイクロフォンなどの1つまたは複数の機構を含んでもよい。さらに、たとえば、出力機構1844は、ディスプレイ、オーディオスピーカ、触覚フィードバック機構、パーソナルエリアネットワーク(PAN)送受信機などを含んでもよい。図示した態様では、出力機構1844は、メディアコンテンツをオーディオ形式にレンダリングするように動作可能なオーディオスピーカ、メディアコンテンツの画像フォーマットもしくはビデオフォーマットへのレンダリングおよび/または時限メタデータのテキスト形式または視覚形式へのレンダリングを行うように動作可能なディスプレイ、あるいは他の適切な出力機構を含んでもよい。しかし、一実施形態では、ヘッドレス通信デバイス1800は、一般にモニタ、キーボード、および/またはマウスなしで動作するように構成されたコンピュータシステムまたはデバイスを指すので、いくつかの入力機構1842および/または出力機構1844を含まなくてもよい。
情報および信号が多種多様な異なる技術および技法のいずれかを使用して表すことができることを、当業者は理解されよう。たとえば上記説明全体を通して参照することができるデータ、命令、指令、情報、信号、ビット、記号およびチップは、電圧、電流、電磁波、磁界または粒子、光学場または粒子、あるいはそれらの任意の組合せによって表すことができる。
さらに、本明細書で開示する態様に関連して説明した様々な例示的な論理ブロック、モジュール、回路、およびアルゴリズムステップは、電子ハードウェア、コンピュータソフトウェア、または両方の組合せとして実装され得ることを当業者は理解されよう。ハードウェアおよびソフトウェアのこの互換性を明確に示すために、様々な例示的な構成要素、ブロック、モジュール、回路、およびステップは、一般的にそれらの機能性に関してこれまで説明されてきた。そのような機能性がハードウェアとして実現されるか、またはソフトウェアとして実現されるかは、具体的な適用例および全体的なシステムに課される設計制約によって決まる。当業者は、記載された機能を特定の適用例ごとに様々な方法で実装することができるが、そのような実装の決定は、本開示の範囲から逸脱するものと解釈されるべきではない。
本明細書に開示する態様と関連して説明する様々な例示的な論理ブロック、モジュール、および回路は、汎用プロセッサ、デジタル信号プロセッサ(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)を含み、ディスクは、通常、データを磁気的に再生する、かつ/または、データをレーザで光学的に再生する。前述の組合せも、コンピュータ可読媒体の範囲内に含まれるべきである。
上記の開示は、本開示の例示的な態様を示しているが、添付の特許請求の範囲によって定義されるような本開示の範囲から逸脱することなく、本明細書において様々な変更および修正を施すことが可能であることが、当業者には諒解されよう。本明細書で説明した本開示の態様による方法クレームの機能、ステップおよび/または動作は、特定の順序で実施される必要はない。さらに、本開示の要素は、単数形で記載または特許請求されている場合があるが、単数形に限定することが明示的に述べられていない限り、複数形が考えられる。