モノのインターネット(IoT)は、多数のコンピューティングデバイスが、互いに相互接続され、また通信ネットワーク(例えば、インターネット)と相互接続されて、ネットワークの非常に下位レベルにおいてデータ収集およびアクチュエーションなどの機能を提供するシステムである。下位レベルとは、ネットワーク端の直前の数デバイスなどの、ネットワークのエッジまたはその付近に配置され得るデバイスを指す。本明細書で使用される場合、IoTデバイスは、他のIoTデバイスおよび通信ネットワークと通信している、とりわけ検知または制御などの機能を実行するデバイスを含み得る。IoTデバイスは、1つまたは複数の機能を実行するように構成された自律デバイスまたは半自律デバイスを含み得る。多くの場合、IoTデバイスは、メモリ、サイズ、または機能が制限されているため、少数の大型デバイスと同程度のコストで多くの台数をデプロイできる。しかしながら、IoTデバイスは、スマートフォン、ラップトップ、タブレット、PC、および/または他のより大型デバイスであってもよい。さらに、IoTデバイスは、スマートフォンまたは他のコンピューティングデバイス上のアプリケーションなどの仮想デバイスであってもよい。IoTデバイスは、データストレージ、プロセス制御などのために、IoTデバイスを他のIoTデバイスおよびクラウドアプリケーションに結合するために使用されるIoTゲートウェイを含み得る。
IoTデバイスのネットワークとしては、配水システム、配電システム、パイプライン制御システム、プラント制御システム、光スイッチ、サーモスタット、ロック、カメラ、警報、モーションセンサなどの商業用デバイスおよび家庭用デバイスを挙げることができる。IoTデバイスは、例えば、システムを制御したりデータにアクセスしたりするために、コンピュータ、サーバ、および他のシステムなどのコントローラを介してアクセス可能であり得る。コントローラとIoTデバイスとは、互いにリモートに配置させることもできる。
インターネットは、多数のIoTデバイスに通信を提供するように構成され得る。従って、本明細書で説明するように、将来のインターネットのための複数のイノベーションは、中央サーバからゲートウェイを介してエッジデバイスに至るネットワーク層が、制約を受けずに拡大し、接続されたリソースを発見してアクセスできるようにし、接続されたリソースを隠蔽して区画化する機能をサポートするという必要性に対処するように設計されている。任意の数のネットワークプロトコルおよび通信規格を使用することができ、各プロトコルおよび規格は特定の目的に対処するように設計されている。さらに、プロトコルは、位置、時間、または空間に関係なく動作する人間がアクセス可能なサービスをサポートするファブリックの一部である。これらのイノベーションには、サービス提供、ならびにハードウェアおよびソフトウェアなどの関連するインフラストラクチャが含まれる。サービスは、サービスレベルおよびサービス提供契約で指定されているサービス品質(QoS)条件に従って提供され得る。IoTデバイスおよびネットワークの使用は、図1および図2に示すように、有線技術と無線技術との組み合わせを含む、異種ネットワークの接続における新たな課題をいくつか提示する。
図1は、一部の実施形態による、インターネット100およびIoTネットワークの間に存在し得る相互接続の図である。相互接続は、より小さなネットワーク102を個々のIoTデバイス104に至るまで、インターネット100のバックボーン106に結合することができる。図面を簡単にするために、すべてのデバイス104または他の対象物に符号が付けられているわけではない。
図1では、ティア1(「T1」)プロバイダ108と呼ばれ得る最上位レベルのプロバイダは、インターネットのバックボーン106によって、二次プロバイダまたはティア2(「T2」)プロバイダ110などの他のプロバイダに結合される。一部の態様では、バックボーン106は、光ファイバリンクを含むことができる。1つの例では、T2プロバイダ110は、例えば、さらなるリンクによって、マイクロ波通信114によって、または他の通信技術によって、LTEセルラーネットワークのタワー112に結合することができる。タワー112は、LTE通信リンク116を介して、例えば中央ノード118を介して、IoTデバイス104を含むメッシュネットワークに結合することができる。個々のIoTデバイス104間の通信も、LTE通信リンク116に基づいてよい。
別の例では、高速アップリンク119が、T2プロバイダ110をゲートウェイ120に結合することができる。複数のIoTデバイス104は、例えばBluetooth(登録商標)low energy(BLE)リンク122を介して、ゲートウェイ120と通信することができ、またゲートウェイ120を介して互いに通信することができる。
バックボーン106は、ティア3(「T3」)プロバイダ124など、より下位レベルのサービスプロバイダをインターネットに結合することができる。T3プロバイダ124は、例えば、T2プロバイダ110からバックボーン106へのアクセスを購入し、企業ゲートウェイ126および他の顧客にアクセスを提供する、一般的なインターネットサービスプロバイダ(ISP)とみなすことができる。
企業ゲートウェイ126から、無線ローカルエリアネットワーク(WLAN)を使用して、Wi-Fi(登録商標)リンク128を介してIoTデバイス104と通信することができる。Wi-Fi(登録商標)リンク128は、低電力広域(low power wide area)(LPWA)ゲートウェイ130に結合するために使用されてもよく、LPWAゲートウェイ130は、例えば、LoRaアライアンスによって公表されたLoRaWan(登録商標)仕様と互換性のある、LPWAリンク132を介してIoTデバイス104と通信することができる。
T3プロバイダ124はまた、LTEセルラーリンク、LPWAリンク、またはZigbee(登録商標)などのIEEE 802.15.4規格に基づくリンク138などの任意の数の通信リンクを使用してT3プロバイダ124と通信するコーディネータデバイス136を介してメッシュネットワーク134へのアクセスを提供することができる。他のコーディネータデバイス136は、リンクされたデバイスの1つまたは複数のクラスタツリーを形成するリンクのチェーンを提供することができる。
一部の態様では、1つまたは複数のIoTデバイス104は、他のデバイスとの通信に適した送受信機を備える。さらに、1つまたは複数のIoTデバイス104は、追加のプロトコルおよび周波数を使用して通信するための他の無線、光学、または音響送受信機、ならびに有線ネットワークインターフェースを備え得る。一部の態様では、1つまたは複数のIoTデバイス104は、図8に関して説明されるコンポーネントを備える。
技術およびネットワークにより、デバイスおよびネットワークの拡大が可能になり得る。技術が成長するにつれて、ネットワークは、直接的な人間の介入を必要とすることのない、自己管理、機能の発展、および/または協調に向けて開発され得る。よって、これらの技術により、ネットワークが集中型制御システムなしで機能できるようになり得る。本明細書で説明される技術は、現在の能力を超えて、ネットワークを管理および運用する機能を自動化することができる。さらに、これらの手法は、人間の介入なしに動作する集中型制御、自動化された集中型制御、またはそれらの任意の組み合わせを有するための柔軟性を提供することができる。
図2は、一部の実施形態による、バックボーンリンク202を介してゲートウェイ204に結合された複数のモノのインターネット(IoT)ネットワークのために使用され得るネットワークトポロジ200の図である。同様の番号が付けられた項目は、図1に関して説明したとおりである。さらに、図面を簡単にするために、すべてのデバイス104、または通信リンク116、122、128、または132に符号が付けられているわけではない。バックボーンリンク202は、任意の数の有線技術または無線技術を含むことができ、ローカルエリアネットワーク(LAN)の一部であってもよいし、広域ネットワーク(WAN)の一部であってもよいし、インターネットの一部であってもよい。
図2のトポロジはハブアンドスポーク型であり、図1のトポロジはピアツーピア型であるが、これらに矛盾はなく、ピアツーピアノードはゲートウェイを介してハブアンドスポークとして挙動し得ることが認められよう。図2からは、サブネットネットのトポロジが複数のゲートウェイを有することができ、厳密なハブアンドスポーク型トポロジではなく純粋なハブアンドスポーク型トポロジではなく、ハイブリッド型トポロジとなり得ることも認められよう。
ネットワークトポロジ200は、Bluetooth(登録商標)Low Energy(BLE)リンク122を使用するメッシュネットワーク206など、任意の数の種類のIoTネットワークを含むことができる。存在し得る他のIoTネットワークとしては、WLANネットワーク208、セルラーネットワーク210、およびLPWAネットワーク212が挙げられる。本明細書で説明するように、これらのIoTネットワークのそれぞれが、新しい開発の機会を提供し得る。
例えば、バックボーンリンク202を介するなど、IoTデバイス104間の通信は、認証、認可、および課金(AAA)のための非集中型システムによって保護されてもよい。非集中型AAAシステムでは、分散型支払い、クレジット、監査、認可、仲介、調停、および認証システムを相互接続された異種インフラストラクチャにわたって実装することができる。これにより、システムおよびネットワークは自律的運用に移行できる。
この種の自律的運用では、機械は、人的資源を縮小し、他の機械ネットワークとパートナーシップを交渉することができる。これにより、概説され計画されたサービスレベル契約に対する相互目的とバランスのとれたサービス提供との実現が可能になるだけでなく、計量、測定、ならびにトレーサビリティおよび追跡可能性を提供するソリューションを実現できる。新たなサプライチェーン構造および方法の創出は、人間の関与なしに、多数のサービスを創出し、価値を取り出し、そして縮小することを可能にし得る。
IoTネットワークは、音、光、電子トラフィック、顔およびパターンの認識、匂い、ならびに振動などのセンシング技術を自律的な組織に統合することによって、さらに強化され得る。感覚システムの統合は、契約上のサービス目的に対するサービス提供の体系的かつ自律的な通信および調整、オーケストレーションおよびサービスの質(QoS)ベースのスウォーミングならびにリソースの融合を可能にし得る。
メッシュネットワーク206は、インラインでデータから情報への変換を実行するシステムによって強化することができる。例えば、マルチリンクネットワークを含む自己形成型の処理リソースのチェーンは、生データから情報への変換を効率的に分散させることができる。これにより、最初のステージが最初の数値演算を実行し、その結果を別のステージに渡す前に、次いで、次のステージが別の数値演算を実行し、その結果を別のステージに渡すなどの機能を実現できる。このシステムは、アセットとリソースとを区別する機能、およびそれぞれの関連する管理を提供することができる。さらに、データの完全性および品質保証を改善し、データの信頼性のメトリックを提供するために、インフラストラクチャおよびリソースベースの信頼およびサービス指標の適切な成分を挿入することができる。
本明細書で説明されるように、WLANネットワーク208は、規格の変換を実行して複数の規格に対応する接続を提供するシステムを使用し、異なるプロトコルを使用するIoTデバイス104が通信することを可能にし得る。さらなるシステムは、可視であるインターネットリソースおよび隠蔽されたインターネットリソースを含む複数の規格に対応するインフラストラクチャにわたってシームレスな相互接続を提供することができる。
セルラーネットワーク210における通信は、データをオフロードする、よりリモートのデバイスに通信を拡張する、またはその両方を行うシステムによって強化することができる。LPWAネットワーク212は、非インターネットプロトコル(IP)からIPへの相互接続、アドレス指定、および経路指定を実行するシステムを含み得る。
図3は、一部の実施形態による、複数のモノのインターネット(IoT)デバイスと通信しているクラウドコンピューティングネットワークすなわちクラウド302の図300である。クラウド302は、インターネットを表すこともできるし、ローカルエリアネットワーク(LAN)または企業専用のネットワークなどの広域ネットワーク(WAN)とすることもできる。IoTデバイスは、様々な組み合わせでグループ化された、任意の数の異なる種類のデバイスを含むことができる。例えば、交通管制グループ306は、街路に沿いにIoTデバイスを含むことができる。これらのIoTデバイスとしては、信号、交通流モニタ、カメラ、気象センサなどを挙げることができる。交通管制グループ306、または他のサブグループは、LPWAリンクなどの無線リンク308などを介してクラウド302と通信することができる。さらに、有線または無線サブネットワーク312は、ローカルエリアネットワーク、無線ローカルエリアネットワークなどを介して、IoTデバイスが互いに通信できるようにし得る。IoTデバイスは、クラウド302と通信するためにゲートウェイ310などの他のデバイスを使用することができる。
IoTデバイスの他のグループとしては、とりわけ、リモートの気象観測所314、ローカル情報端末316、警報システム318、現金自動預払機320、警報パネル322、または緊急車両324もしくは他の車両326などの移動車両を挙げることができる。これらのIoTデバイスのそれぞれが、他のIoTデバイスと、サーバ304と、またはそれらの両方と、通信することができる。
図3からわかるように、多数のIoTデバイスがクラウド302を介して通信することができる。これにより、異なるIoTデバイスが自律的に他のデバイスに情報を要求または提供できるようになり得る。例えば、交通管制グループ306は、人間の介入なしに予測を提供することができる一群のリモートの気象観測所314からの現在の天気予報を要求することができる。さらに、現金自動預払機320が、現在強盗に入られている最中であることを緊急車両324に警告することもできる。緊急車両324が現金自動預払機320に向かって進む際に、緊急車両324は交通管制グループ306にアクセスして、例えば、緊急車両324が交差点まで妨げられることなくアクセスするのに十分な時間、交差点において交差点の交通を遮断するために信号灯を赤にすることによる、現場までの通行の認可を要求することができる。
リモートの気象観測所314または交通管制グループ306などのIoTデバイスのクラスタは、他のIoTデバイスおよびクラウド302と通信するように装備されてもよい。これは、IoTデバイスがデバイス間にアドホックネットワークを形成することを可能にし、それらが単一のデバイスとして機能することを可能にし、この単一のデバイスはフォグデバイスと呼ばれ得る。フォグデバイスについては、図4に関連してさらに説明する。
図4は、一部の実施形態による、クラウド302のエッジで動作するフォグデバイス402と呼ばれ得るIoTデバイスのメッシュネットワークと通信しているクラウドコンピューティングネットワークすなわちクラウド302の図面400である。同様の番号が付けられた項目は、図3に関して説明したとおりである。本明細書で使用する場合、フォグデバイス402は、交通管制、気象制御、プラント制御などの特定の機能を実行するようにグループ化され得るデバイスのクラスタである。
この例では、フォグデバイス402は、交差点に一群のIoTデバイスを含む。フォグデバイス402は、とりわけ、オープンフォグコンソーシアム(OpenFog Consortium)(OFC)によって公表された仕様に従って確立されてもよい。これらの仕様は、フォグデバイス402をクラウド302に結合するゲートウェイ310と、フォグデバイス402をエンドポイントデバイス、この例では交通信号灯404およびデータアグリゲータ406に結合するゲートウェイ310と、の間のコンピューティング要素の階層の形成を可能にする。フォグデバイス402は、IoTデバイスの集合体が提供する組み合わされた処理およびネットワークリソースを活用することができる。従って、フォグデバイス402は、例えば、財務モデリング、天気予報、交通量調査などを含む任意の数の用途に使用することができる。
例えば、交差点を通る交通流は、複数の交通信号灯404(例えば、3つの交通信号灯404)によって制御され得る。交通流および管制方式の分析は、メッシュネットワークを介して交通信号灯404と通信しており、かつ互いに通信しているアグリゲータ406によって実施することができる。メッシュネットワークを介して交通信号灯404およびアグリゲータ406と通信しているゲートウェイ310を介して、データをクラウド302にアップロードし、クラウド302からコマンドを受信することができる。
フォグデバイス402では、任意の数の通信リンクを使用することができる。短距離リンク408、例えばIEEE 802.15.4と互換性のある短距離リンク408が、交差点に近接したIoTデバイス間にローカル通信を提供することができる。長距離リンク410、例えばLPWA規格と互換性のある長距離リンク410が、IoTデバイスとゲートウェイ310との間の通信を提供することができる。図面を簡単にするために、すべての通信リンク408または410に参照番号が付けられているわけではない。
フォグデバイス402は、複数のIoTデバイスが、例えば通信リンク408および410によって互いに通信している、大規模に相互接続されたネットワークであるとみなすことができる。ネットワークは、2015年12月23日にOpen Connectivity Foundation(登録商標)(OCF)によって公開されたOpen Interconnect Consortium(OIC)規格の仕様1.0を使用して確立することができる。この規格は、デバイスが互いを発見し合い、相互接続のための通信を確立することを可能にする。例えば、とりわけ、AllSeen allianceのAllJoynプロトコル、optimized link state routing(OLSR)プロトコル、またはbetter approach to mobile ad-hoc networking(B.A.T.M.A.N.)を含む、他の相互接続プロトコルも使用することができる。
一部の態様では、1つのIoTデバイスからの通信は、ゲートウェイ310に到達するための最も便利なパス、例えば、とりわけ、中間ホップの数が最も少ないパスまたは最も高い帯域幅を有するパスに沿って伝えられ得る。これらのネットワークでは、複数の相互接続により十分な冗長性が提供され、複数のIoTデバイスが失われても通信を維持できる。
一部の態様では、フォグデバイス402は、一時的なIoTデバイスを含むことができる。換言すれば、すべてのIoTデバイスがフォグデバイス402の恒久的なメンバであるとは限らない場合がある。例えば、例示的なシステム400では、フォグデバイス402には、3つの過渡的なIoTデバイス、すなわち、第1の車両412、第2の車両414、および歩行者416が参加している。これらの場合、IoTデバイスは、車両412および414に内蔵されている場合もあるし、歩行者416によって携帯されるスマートフォン上のアプリケーションである場合もある。自転車用コンピュータ、オートバイ用コンピュータ、無人機などの中のIoTデバイスなどの他のIoTデバイスが存在する場合もある。
IoTデバイスから形成されたフォグデバイス402は、サーバ304などのクラウド302内のクライアントに、クラウド302のエッジに配置された単一のデバイスとして提示され得る。この例では、フォグデバイス402内の特定のリソースへの制御通信は、フォグデバイス402内のいかなる特定のIoTデバイスをも識別することなく行われ得る。従って、フォグデバイス402内の1つのIoTデバイスに障害が発生した場合、フォグデバイス402内の他のIoTデバイスが、アクチュエータ、またはIoTデバイスに接続された他のデバイスなどのリソースを発見および制御することが可能であり得る。例えば、交通信号灯404は、交通信号灯404のうちのいずれか1つが他の交通信号灯404用の信号灯を制御できるように配線されてもよい。アグリゲータ406はまた、交通信号灯404の制御およびフォグデバイス402の他の機能において冗長性を提供することができる。
一部の例では、IoTデバイスは、命令型プログラミングのスタイルを使用して、例えば各IoTデバイスが特定の機能および通信相手を有している状態で、構成され得る。しかしながら、フォグデバイス402を形成するIoTデバイスは、宣言型プログラミングのスタイルで構成され、IoTデバイスが、条件、クエリ、およびデバイス障害に応じて必要なリソースを判定するように、それらの動作および通信を再構成することを可能にし得る。これは、歩行者416などの過渡的なIoTデバイスがフォグデバイス402に参加するときに実行されてもよい。
歩行者416は、車両412および414よりもゆっくりと移動する可能性が高いので、フォグデバイス402は、歩行者416が交差点を通過するのに十分な時間を確保するように、自身を再構成することができる。これは、交通信号灯404を制御するために、車両412および414ならびに歩行者416の一時的なグループを形成することによって実行され得る。車両412または414の一方または両方が自律的である場合、一時的なグループは、交通信号灯404の手前で減速するように車両に命令することができる。さらに、交差点にあるすべての車両が自律型である場合、自律型車両の衝突回避システムでは、交通信号灯が管理するには複雑すぎる可能性がある高度に絡み合った通行パターンを可能にし得るため、交通信号灯の必要性は減少し得る。しかしながら、交通信号灯404は、歩行者416、サイクリスト、または非自律型車両にとって依然として重要であり得る。
過渡的なデバイス412、414、および416がフォグデバイス402の交差点付近を離れると、フォグデバイス402は、それらのIoTデバイスをネットワークから排除するように自身を再構成することができる。他の過渡的なIoTデバイスが交差点に近づくと、フォグデバイス402は、それらのデバイスを含むように自身を再構成することができる。
フォグデバイス402は、街路沿いのすべての過渡的なIoTデバイスと共に、その街路沿いなどの複数の交差点の交通信号灯404を含むことができる。次いで、フォグデバイス402は、交通信号灯404および単一の交差点に近接する他のIoTデバイスなどの機能ユニットに自身を分割することができる。この種類の組み合わせは、より大きなIoT構成体、例えば、特定の機能を実行するIoTデバイスのグループをフォグデバイス402内に形成することを可能にし得る。
例えば、緊急車両がフォグデバイス402に参加する場合、その街路用の交通信号灯404のすべてを含む緊急用構造体または仮想デバイスを作成することができ、それにより街路全体の交通流パターンの制御が可能になる。緊急用構造体は、街路沿いの交通信号灯404に対して、対向車線については赤のままにし、緊急車両については青のままにするようにして、緊急車両の通過を促進するように命令することができる。
フォグデバイス402によって示されるように、IoTネットワークの有機的な発展は、IoT実装の有用性、可用性、および回復力を改善または最大化することの要となっている。さらに、この例は、信頼性、従ってセキュリティを向上させるための戦略の有用性を示している。アイデンティティが非集中化されることによって、中央局を悪用したIoTネットワーク内に存在し得るオブジェクトへのなりすましを可能にすることはできないことが保証されるため、デバイスのローカル識別は実装において重要になり得る。さらに、ローカル識別は、通信のオーバーヘッドおよびレイテンシを短縮する。
ブロックチェーンは現在使用されている名前およびアイデンティティに関してデバイス間の合意を提供することができるため、ブロックチェーンを用いて識別を非集中化させることができる。本明細書で使用される場合、ブロックチェーンは、データ構造ブロックから構成されるアイデンティティ記録の分散型データベースである。さらに、本明細書で使用される場合、「ブロックチェーン」という用語は、他の分散型台帳システムのうちの任意の1つまたは複数の台帳システムを含み得る。他の分散型台帳手法としては、リップル(Ripple)、ハイパーレジャー(Hyperledger)、マルチチェーン(Multichain)、キーレス署名インフラストラクチャ(Keyless Signature Infrastructure)などが挙げられる。各データ構造ブロックはトランザクションに基づいており、デバイス、コンポジットデバイス、または仮想デバイスへの新しい名前の発行はトランザクションの一例である。
識別のためにブロックチェーンを使用して、対応する終了がなされていない名前およびアイデンティティの再発行を観察することによって、なりすましが検出され得る。パブリックブロックチェーンは、様々なオブザーバのコミュニティが、命名間違い、悪質な命名、または命名インフラストラクチャの障害を検出することを可能にし得るため、最も有用であり得る。よって、信頼できるアイデンティティインフラストラクチャは、信頼できるIoTネットワークの要となり得る。
図5は、一部の実施形態による、複数のアトミックオブジェクト504、506、および508からのコンポジットオブジェクト502の形成を示す概略図500である。オブジェクトは、分散型システムのノードを構成する、機能、状態、およびインターフェースのセマンティクスのデータモデル表現を含む。本明細書で使用される場合、オブジェクトまたはIoTオブジェクトは、IoTデバイスから構成される物理デバイス、物理デバイスもしくは仮想デバイスのグループから形成された仮想デバイス、または任意の数の他の構成であり得る。
オブジェクトは、より大きな機能、目標またはワークフローを達成するために相互作用してもよい。オブジェクトは、それらの型、例えば実行される機能、およびインスタンス、例えば存在に関して識別され得る。複数のオブジェクトインスタンスは、同じ型のアイデンティティを持つ場合もあるが、固有のインスタンスアイデンティティを持つ場合もある。さらに、複数のオブジェクトインスタンスをグループに編成することができ、グループのインスタンスがアイデンティティを有し得る。特定の方法で相互作用するオブジェクトのグループは、それらの型、例えば、機能、状態、およびインターフェースのセマンティクスがあれば、コンポジットオブジェクトを表し得る。コンポジション自体が、型およびインスタンスの抽象化したものを有し得る。従って、コンポジットオブジェクトはアトミックオブジェクトと同じアイデンティティ規則に従う。型プロパティとインスタンスプロパティとを有するコンポジションは、コンポジションを通じてオブジェクトの拡張性を可能にする。
オブジェクトは、冷蔵庫などの単一のデバイスである限り、または現在の機能が完了するまでだけ存続することができる。例えば、冷蔵庫は、照明、コンプレッサ、温度センサ、サーモスタット、ウォーターディスペンサ、製氷機などの他の複数のオブジェクトから成るコンポジットオブジェクト502とみなすことができる。他のオブジェクトは、それぞれアトミックオブジェクト504、506、および508とすることもできるし、それら自体がコンポジットオブジェクト502とすることもできる。製氷機は、温度センサ、サーモスタット、電磁送水弁、タイマ、製氷皿などのアトミックオブジェクト504、506、および508から形成されたコンポジットオブジェクト502とすることができる。複数の物理デバイスから構成される仮想コンポジットオブジェクト502の例は、図4に関して説明した交差点および緊急クラスタである。
従って、オブジェクトアイデンティティは、3つの抽象化、すなわちオブジェクトインスタンス、オブジェクト型、およびメタアイデンティティの文脈で理解することができる。オブジェクトインスタンスは、メモリ、CPU、帯域幅、ステータスなどの有限のリソースを占有する計算要素である。オブジェクトのインスタンス化は、作成、突然変異、削除を含むライフサイクルを有する。オブジェクト型は、予想されるまたは起こり得る挙動、状態、およびコンポジションを宣言する論理的な構成体である。オブジェクト型は、インスタンス化されたときのオブジェクトの挙動および相互作用に制約を加えることができる。オブジェクト型は、オブジェクトが応答できる要求の種類、例えばインターフェースを示すこともできる。
メタアイデンティティは、オブジェクトが存在し得るメタデータコンテキストを定義する方法である。オブジェクトは、メタアイデンティティのカプセル化に気付かない場合もある。オブジェクトインスタンスは、所望のメタデータコンテキストを有するグループを定義し、次いでオブジェクトをそのグループに登録することによってステレオタイプ情報を動的に適用することができる。
認証とアイデンティティとは、照合される問題である。認証されていない場合、オブジェクトアイデンティティを信じることはできない。しかしながら、アイデンティティなしの認証は実用性が限られている。ECDSA(楕円曲線デジタル署名アルゴリズム)、RSAなどの非対称鍵署名は、秘密鍵を複製および配布する機能に制限があるという期待の下、認証に役立つ。鍵の使用は、本人または代理人が制限されていても鍵にアクセスできるという証明を確立する。従って、本人または代理人は本物であるはずである。
認証のセマンティクスはまた、オブジェクトアイデンティティに適用されると、オブジェクトインスタンス、オブジェクト型、およびメタアイデンティティの3つの抽象化にも従う。オブジェクトインスタンスの場合、認証チャレンジ/レスポンスは、現在の相互作用がオブジェクトの特定のインスタンス化とのみ可能であることを確立する。オブジェクト型の場合、認証チャレンジ/レスポンスは、現在の相互作用が型識別のセマンティクスによって制約されていることをアテステーションする。メタアイデンティティの場合、認証チャレンジ/レスポンスは定義されたコンテキストに従って現在の相互作用を分類する。
図6は、アトミックオブジェクト604およびコンポジットオブジェクト606の集合からのグループオブジェクト602の形成の概略図600である。グループオブジェクト602は、オブジェクト型のサブセットであるオブジェクトクラスに属する。例えば、オブジェクトクラスは熱交換器であり得るが、クラス熱交換器のオブジェクト型は、冷蔵庫、ヒートポンプ、エアコン、蒸発冷却器などのより具体的なデバイスであり得る。
オブジェクトクラスの認証は、複数の秘密鍵に対応する単一の公開鍵を含む非対称暗号化システムであるEPID(Enhanced Privacy ID)を使用して容易になり得る。秘密鍵のいずれかによって生成されたシグネチャは、単一の公開鍵で検証できる。よって、グループオブジェクト602は単一の公開鍵を有することができ、一方、アトミックオブジェクト604およびコンポジットオブジェクト606のそれぞれには固有の秘密IDが発行される。システムは、EPIDを使用することに限定されず、共有アクセスシグネチャなどの他の識別技法を使用することができる。
オブジェクトクラスがEPIDグループID(gid)に対応する番号と関連付けられ、同じ型のオブジェクトインスタンスがEPIDグループに対応する秘密鍵を発行されると、オブジェクトインスタンスは、そのクラスを検証部に対して認証することができる。オブジェクトクラス認証は、型付き規則に基づいて他がオブジェクトと相互作用できるようにするアテステーションの一形式である。これは業界では型強制としても知られている。そのコンポーネントオブジェクトの型識別子を使用してコンポジットオブジェクトクラス識別子を構成することは、オブジェクト型拡張方法である。例えば、引数としてC=(c1,c2,c3,... cn)を受け入れ、cXが成分オブジェクトのそれぞれのオブジェクト型である、関数f()は、コンポジットオブジェクトの型識別子を表すEPID gid値C2_idを生成する。f()の実施は、Cにおける各cxの暗号化ハッシュの使用を含み得る。別の例では、f()は、各cxがCの親OIDのOIDサブツリーであるOID(Object Identifer)命名階層を使用し得る。f()を計算するための方法は他にもあり得る。
拡張可能なコンポジットオブジェクトクラス識別子は、オブジェクトをホスティングしているデバイスオーナー608の有効期間中いつでもIoTオブジェクトのシステムを組み合わせることを可能にする。ブロックチェーン610は、既存のコンポジションがオーサリングツールに知らせることができるように、構成されたオブジェクトの発展を追跡することができる。分散型スキーマライブラリは、ブロックチェーン610を使用して、オブジェクト型識別子、例えばgidを登録するトランザクション612にコンポジットオブジェクト定義、例えばCを供給することによって形成することができる。現在の中央集権型オブジェクトリポジトリスキームは、しばしば、中央サーバ上でクラス定義を、権限を持って維持する単一の論理サービスに依存する。しかしながら、中央サーバに対する修正は、認可されていないスキーマの変更を生じる可能性がある。それに比べて、ブロックチェーン610の使用は、既存のオブジェクトクラス定義が変更され得る前に、閾値コンセンサスが、例えばフォグ中で、複数のIoTデバイスにわたって存在することを確実にし得る。
ブロックチェーン610は、同型オブジェクト分類の識別を容易にする。例えばメッセージ614において、新しいオブジェクトクラスが提案されると、ブロックチェーン610を探索して、Cが既に存在するか否かを調べることができる。
サブオブジェクトからグループオブジェクト602を構成し、コンポジットオブジェクトを形成することは、IoTオブジェクトモデルのための拡張性メカニズムである。構成されたオブジェクトは、「交差点XYZ」など、サブオブジェクトに関連する機能を使用して命名することができる。グループの提案された各メンバが、集合を識別するクレデンシャルを含むメッセージ218を取得するために、メッセージ616を送信した場合、オブジェクトインスタンスの集合は、グループオブジェクト602を形成することができる。EPIDがクレデンシャルメカニズムとして使用されている場合、集合内の各オブジェクトは、集合のエージェントとして相互にまたは他のIoTデバイスと相互作用できる。
ブロックチェーン610は、ネームサーバ620から信頼の必要性を取り除くためにシステムによって使用される。同じ名前のグループが現在使用中である間にグループ名が再利用される場合、ブロックチェーン610は、ネームサーバ620の不当行為を管理することができる。グループ名の再利用は、ブロックチェーン610を格納および監視しているIoTデバイスによって判定されてもよい。この判定は、現在の命名要求と、アクティブであり、かつグループ名を含む前のブロックと、が重なることを識別することによって行われ得る。
一部の態様では、一次集合グループメンバ(PCGM)またはグループオブジェクト602は、集合の特定の構成に基づいてグループ名を判定するように構成される。PCGMは、他の集合メンバ、例えばコンポジットオブジェクト606およびアトミックオブジェクト604、または別の集合メンバにグループ名を通信し(622)、同じグループ名に到達するためにPCGMと同じ動作を実行する。関数F()は、異なるメンバが別々にグループ名を計算するときにイントロスペクション順序の非決定性における違いを避けるために、集合メンバシップロジックを用いて集合グループ名C2_idを計算することができる。
一例として、EPIDグループID(gid)は、32ビットまたは128ビットの値を取り得る。32ビット値が使用される場合、関数F()は上位12バイトを切り捨て得る。ネームサーバ620は、gidの長さにかかわらず、gidが再発行されるか否かを検証することができる。より短いgidの長さは、より制限されたIoTデバイスを使用するなど、制約のある環境で役立ち得る。F()からの名前の衝突はまれであり得るが、衝突の解決は、グループメンバシップ値を再び指定する、F()の再帰呼び出しによって実現できる(例えば、F'=F(m1,m2,...,mn,F(m1,m2,...,mn))。
図7は、一部の実施形態による、オブジェクトの集合を使用してグループを作成するための例示的な方法700のプロセスフロー図である。方法700は、図8に関して説明されるシステム802を使用して実行することができる。ブロック702は、例えば、新しいグループオブジェクトが望まれるときを表す。これが起こり得るのは、図4の緊急クラスタに関して説明したように、過渡的なオブジェクトが現在のグループオブジェクトの近くに移動するときであり、図4の緊急クラスタは、緊急車両が街路に接近したときに形成され得る。別の例では、図5および図6に関して説明した冷蔵庫などのデバイスの電力供給が、グループオブジェクトの作成を開始することができる。
ブロック704において、コンポジットオブジェクトは、コンポジットオブジェクトの一次集合グループメンバ(PCGM)内のリスト内のグループオブジェクトを構成するアトミック(A)またはコンポジット(C)サブオブジェクトのそれぞれのIDへの参照を維持することによって形成される。コンポジットオブジェクトを構成するオブジェクトは、オブジェクトのコンセンサス、デバイスオーナーの以前のプログラム、または複数のIoTデバイスによるオブジェクトの構築などの任意の数の他の技法によって判定される機能を達成するために必要なオブジェクトによって判定され得る。
ブロック706において、集合グループ識別子が形成される。これは、グループオブジェクトを構成するPCGM内のオブジェクトIDのリストに関数を適用することによって行われ得る。この関数は、結合し、オブジェクトIDのハッシュコード、例えばC2_ID=SHA2(C1,C2,C3,...,A1,A2,A3,...,An)を形成することができる。
ブロック708において、サブオブジェクトのうちの1つまたは複数(例えば、サブオブジェクトのうちのすべて)が、ネームサーバ、例えばデバイスオーナー内のネームサーバと通信して、グループ鍵を取得する。これは、EPID参加プロトコルを使用して実行され得る。参加プロトコルでは、サブオブジェクトは、参加メッセージをネームサーバに送信し、それに対して返された、例えばC2_IDグループオブジェクトに対するEPIDクレデンシャルを受信する。
ブロック710において、グループネームサーバは、PCGM内のリストからグループについて計算された名前を受け入れる。次いで、ネームサーバは、名前をブロックチェーンにコミットすることができる。ブロック712において、ネームサーバは、ブロックチェーンから名前、例えばC2_IDを取得する。本明細書で使用される場合、ブロックチェーンは、複数の個々のIoTデバイスに保存されたトランザクションの分散型データベースである。トランザクションの有効性の確認は、IoTデバイスのそれぞれによって実行され、真正性およびアイデンティティの複数の確認を提供することができる。
ブロック714において、その名前が既に使用中であるか否か、例えば、そのオブジェクトの名前に対応する終了がない状態で、以前のトランザクションブロックに存在するか否かに関する判定が行われる。使用中である場合、ブロック716において、グループメンバシップ値を再び指定する、F()の再帰呼び出し、F'=F(m1,m2,...,mn,F(m1,m2,...,mn))によって新しい名前が判定され得る。
名前が現在使用中ではない場合、ブロック718において、グループメンバシップがプライバシーセンシティブであるか否かに関する判定が行われる。これは、車両が一連の交差点に存在するなど、ある場所にIoTデバイスが存在することが一般に知られるべきではない場合に実行できる。もしそうであれば、ブロック720において、PCGMはプロキシとして働き、サブオブジェクトからの参加プロトコル要求を仲介する。そうではない場合、ブロック722において、ネームサーバは、ブロックチェーンからサブオブジェクトメンバ名を見つける。
ブロック724において、要求者が認可されたグループメンバであるか否かに関する判定が行われる。もしそうであれば、ブロック726において、参加要求が実行される。ブロック728において、ネームサーバは、グループ名、例えばC2_IDをブロックチェーンにコミットする。
ブロック730において、別のサブオブジェクトが存在するか否か、従ってグループクレデンシャルが必要か否かに関する判定が行われる。もしそうであれば、プロセスフローは、サブオブジェクトのクレデンシャリングのためにブロック712に戻る。そうではない場合、または要求者が認可されたグループメンバではないと判定された場合、プロセスはブロック732で終了する。
図8は、データをオフロードするための、IoTデバイス800に存在し得るコンポーネントの一例のブロック図である。IoTデバイス800は、この例に示すコンポーネントの任意の組み合わせを備え得る。コンポーネントは、IC、その一部、個別の電子デバイス、もしくは他のモジュール、ロジック、ハードウェア、ソフトウェア、ファームウェア、またはIoTデバイス800に適合されたそれらの組み合わせとして、あるいはより大きなシステムのシャーシ内に他の方法で組み込まれるコンポーネントとして実装され得る。図8のブロック図は、IoTデバイス800のコンポーネントの上位レベルの図を示すことを意図している。しかしながら、示されているコンポーネントのうちの一部は省略されてもよく、追加のコンポーネントが存在してもよく、示されているコンポーネントの異なる構成が他の実装形態において生じてもよい。
IoTデバイス800は、プロセッサ802を備えることができ、プロセッサ802は、マイクロプロセッサ、マルチコアプロセッサ、マルチスレッドプロセッサ、超低電圧プロセッサ、組み込みプロセッサ、または他の既知の処理要素とすることができる。プロセッサ802は、Intel(登録商標)のEdison(登録商標)もしくはGalileo(登録商標)SoCボードなどの、プロセッサ802および他のコンポーネントが単一の集積回路または単一のパッケージに形成されるシステムオンチップ(SoC)の一部であってもよい。一例として、プロセッサ802は、Quark(登録商標)、Atom(登録商標)、i3、i5、i7、もしくはMCUクラスのプロセッサなどのIntel(登録商標)アーキテクチャコア(登録商標)ベースのプロセッサ、またはカリフォルニア州サンタクララのIntel(登録商標)Corporationから入手可能な、別のそのようなプロセッサを含み得る。しかしながら、カリフォルニア州サニーベールのAdvanced Micro Devices、Inc.(AMD)、カリフォルニア州サニーベールのMIPS Technologies,Inc.のMIPSベースの設計、ARM Holdings,Ltd.からライセンス供与されたARMベースの設計、またはその顧客、あるいはそれらのライセンシーまたは採用者から入手可能なものなど、他の任意の数のプロセッサが使用されてもよい。プロセッサは、Apple(登録商標)Inc.製のA5~A9プロセッサ、Qualcomm(登録商標)Technologies,Inc.製のSnapdragon(登録商標)プロセッサ、またはTexas Instruments,Inc.製のOMAP(登録商標)プロセッサなどのユニットを含むことができる。
プロセッサ802は、バス806を介してシステムメモリ804と通信することができる。所与の量のシステムメモリを提供するために、任意の数のメモリデバイスを使用することができる。例として、メモリは、Joint Electron Devices Engineering Council(JEDEC) JESD 209-2E(2009年4月公開)に従う現在のLPDDR2規格、または、帯域幅を拡大するためにLPDDR2の拡張を提案するLPDDR3もしくはLPDDR4などの次世代LPDDR規格などのJEDECの低電力デュアルデータレート(LPDDR)ベースの設計に従うランダムアクセスメモリ(RAM)であり得る。様々な実装において、個々のメモリデバイスは、シングルダイパッケージ(SDP)、デュアルダイパッケージ(DDP)、またはクワッドダイパッケージ(QDP)などの任意の数の異なるパッケージタイプであってもよい。これらのデバイスは、一部の実施形態では、薄型化の解決策を提供するために、マザーボード上に直接はんだ付けされる場合もある一方で、他の実施形態では、所与のコネクタによりマザーボードに順に結合される1つまたは複数のメモリモジュールとして構成される。他の種類のメモリモジュール、例えば、microDIMMまたはMiniDIMMを含むがこれらに限定されない、異なる種類のデュアルインラインメモリモジュール(DIMM)など、任意の数の他のメモリ実装を使用することができる。例えば、メモリは、2GBから16GBの間のサイズとすることができ、ボールグリッドアレイ(BGA)を介してマザーボード上にはんだ付けされるDDR3LMパッケージまたはLPDDR2もしくはLPDDR3メモリとして構成され得る。
データ、アプリケーション、オペレーティングシステムなどの情報の永続的ストレージを提供するために、大容量ストレージ808もバス806を介してプロセッサ802に結合されてもよい。より薄く、より軽いシステム設計を可能にするために、大容量ストレージ808は、ソリッドステートドライブ(SSD)を介して実装されてもよい。大容量ストレージ808に使用することができる他のデバイスとしては、SDカード、マイクロSDカード、xDピクチャカードなどのフラッシュメモリカード、およびUSBフラッシュドライブが挙げられる。
低電力実装では、大容量ストレージ808は、プロセッサ802に関連するオンダイメモリまたはレジスタであり得る。しかしながら、一部の例では、大容量ストレージ808は、マイクロハードディスクドライブ(HDD)を使用して実装され得る。さらに、大容量ストレージ808には、記載された技術に加えて、またはその代わりに、とりわけ、抵抗変化メモリ、相変化メモリ、ホログラフィックメモリ、または化学メモリなどの任意の数の新しい技術を使用することができる。例えば、IoTデバイス800は、Intel(登録商標)およびMicron(登録商標)の3D XPOINTメモリを組み込んでもよい。
コンポーネントは、バス806を介して通信することができる。バス806は、業界標準アーキテクチャ(ISA)、拡張ISA(EISA)、周辺機器相互接続(PCI)、拡張周辺機器相互接続(PCIx)、PCIエクスプレス(PCIe)、または他の任意の数の技術を含む、任意の数の技術を含み得る。バス806は、例えばSoCベースのシステムで使用される、専用バスであってもよい。とりわけ、I2Cインターフェース、I3Cインターフェース、SPIインターフェース、ポイントツーポイントインターフェース、および電力バスなど、他のバスシステムが含まれてもよい。
バス806は、他のメッシュデバイス812と通信するために、プロセッサ802をメッシュ送受信機810に結合することができる。メッシュ送受信機810は、IEEE 802.15.4規格下の、Bluetooth(登録商標)Special Interest Groupによって規定されるBluetooth(登録商標)low energy(BLE)規格を使用する、またはZigBee(登録商標)規格を使用する、2.4ギガヘルツ(GHz)伝送などの任意の数の周波数およびプロトコルを使用することができる。特定の無線通信プロトコル用に構成された任意の数の無線機をメッシュデバイス812への接続に使用することができる。例えば、WLANユニットは、米国電気電子技術者協会(IEEE)802.11規格に従ってWi-Fi(登録商標)通信を実装するために使用され得る。加えて、例えばセルラーまたは他の無線広域プロトコルによる、無線広域通信は、WWANユニットを介して行われ得る。
メッシュ送受信機810は、異なる距離範囲で通信するために複数の規格または無線機を使用して通信することができる。例えば、IoTデバイス800は、電力を節約するために、BLEに基づくローカル送受信機または別の低電力無線機を使用して、地理的に近接したデバイスと、例えば約10メートル以内で通信することができる。より遠い、例えば約50メートル以内のメッシュデバイス812は、ZigBee(登録商標)または他の中間電力無線機を介して到達することができる。双方の通信技法が、異なる電力レベルで単一の無線機を介して行われてもよいし、例えばBLEを使用するローカル送受信機およびZigBee(登録商標)を使用する別個のメッシュ送受信機などの別個の送受信機を介して行われてもよい。メッシュ送受信機810は、Intel(登録商標)から入手可能なCurie(登録商標)ユニットなどの、チップにより直接アクセス可能であるアドレスとしてMCUに組み込むことができる。
クラウド302内のデバイスと通信するためにアップリンク送受信機814が備えられ得る。アップリンク送受信機814は、とりわけ、IEEE 802.15.4、IEEE 802.15.4g、IEEE 802.15.4e、IEEE 802.15.4k、またはNB-IoT規格に従うLPWA送受信機であり得る。IoTデバイス800は、SemtechおよびLoRa Alliance(登録商標)によって開発されたLoRaWAN(登録商標)(Long Range Wide Area Network)を使用して広域にわたって通信することができる。本明細書で説明される技法はこれらの技術に限定されず、Sigfox(登録商標)などの長距離低帯域幅通信を実装する任意の数の他のクラウド送受信機、および他の技術と共に使用され得る。さらに、IEEE 802.15.4e仕様に記載されているタイムスロットチャネルホッピングなどの他の通信技法を使用することもできる。
本明細書で説明するように、メッシュ送受信機810およびアップリンク送受信機814に関して言及したシステムに加えて、任意の数の他の無線通信およびプロトコルを使用することができる。例えば、無線送受信機810および812は、LTE、またはビデオ転送などのための高速通信を実施するためにスペクトラム拡散(SPA/SAS)通信を使用する他のセルラー送受信機を含むことができる。さらに、静止画、センサ読み取り値、およびネットワーク通信の提供などの中速通信用のWi-Fi(登録商標)ネットワークなど、任意の数の他のプロトコルを使用することができる。
無線送受信機810および812は、任意の数の3GPP(第3世代パートナーシッププロジェクト)仕様、特に、とりわけ、ロングタームエボリューション(LTE)、ロングタームエボリューション-アドバンスト(LTE-A)、ロングタームエボリューション-アドバンストプロ(LTE-A Pro)、または狭帯域IoT(NB-IoT)と互換性のある無線機を含むことができる。他の任意の数の固定、モバイル、または衛星通信技術および規格と互換性のある無線機を選択することができることに留意されたい。これらは、例えば、任意のセルラー方式広域無線通信技術を含むことができ、当該技術は、例えば、第5世代(5G)通信システム、汎欧州デジタル移動電話方式(Global System for Mobile Communications)(GSM(登録商標))無線通信技術、汎用パケット無線サービス(General Packet Radio Service)(GPRS)無線通信技術、またはGSM(登録商標)進化型高速拡張データレート(Enhanced Data Rates for GSM Evolution)(EDGE)無線通信技術を含み得る。使用され得る他の第3世代パートナーシッププロジェクト(3GPP)無線通信技術は、UMTS(ユニバーサル移動体通信システム)、FOMA(Freedom of Multimedia Access)、3GPP LTE(ロングタームエボリューション)、3GPP LTEアドバンスト(ロングタームエボリューションアドバンスト)、3GPP LTEアドバンストプロ(ロングタームエボリューションアドバンストプロ)、CDMA2000(符号分割多元接続2000)、CDPD(Cellular Digital Packet Data)、Mobitex、3G(第3世代)、CSD(Circuit Switched Data)、HSCSD(High-Speed Circuit-Switched Data)、UMTS(3G)(ユニバーサル移動体通信システム(第3世代))、W-CDMA(UMTS)(広帯域符号分割多元接続(ユニバーサル移動体通信システム))、HSPA(High-speed Packet Access)、HSDPA(High-Speed Downlink Packet Access)、HSUPA(High-Speed Uplink Packet Access)、HSPA+(High-speed Packet Access Plus)、UMTS-TDD(ユニバーサル移動体通信システム-時分割複信)、TD-CDMA(時分割-符号分割多元接続)、TD-SCDMA(時分割-同期符号分割多元接続)、3GPP Rel.8(Pre-4G)(第3世代パートナーシッププロジェクトリリース8(Pre-第4世代))、3GPP Rel.9(第3世代パートナーシッププロジェクトリリース9)、3GPP Rel.10(第3世代パートナーシッププロジェクトリリース10)、3GPP Rel.11(第3世代パートナーシッププロジェクトリリース11)、3GPP Rel.12(第3世代パートナーシッププロジェクトリリース12)、3GPP Rel.13(第3世代パートナーシッププロジェクトリリース13)、3GPP Rel.14(第3世代パートナーシッププロジェクトリリース14)、3GPP LTE Extra、LTE Licensed-Assisted Access(LAA)、UTRA(UMTS地上無線アクセス)、E-UTRA(発展型UMTS地上無線アクセス)、LTEアドバンスト(4G)(ロングタームエボリューションアドバンスト(第4世代))、cdmaOne(2G)、CDMA2000(3G)(符号分割多元接続2000(第3世代))、EV-DO(Evolution-Data OptimizedまたはEvolution-Data Only)、AMPS(1G)(Advanced Mobile Phone System(第1世代))、TACS/ETACS(Total Access Communication System/Extended Total Access Communication System)、D-AMPS(2G)(Digital AMPS(第2世代))、PTT(プッシュツートーク)、MTS(Mobile Telephone System)、IMTS(Improved Mobile Telephone System)、AMTS(Advanced Mobile Telephone System)、OLT(Offentlig Landmobil Telefoniを表すノルウェー語、公衆地上携帯電話)、MTD(Mobiltelefonisystem Dのスウェーデン語の略語、すなわち携帯電話システムD)、Autotel/PALM(Public Automated Land Mobile)、ARP(Autoradiopuhelinを表すフィンランド語、すなわち「自動車無線電話」)、NMT(Nordic Mobile Telephony)、Hicap(NTT大容量方式(日本電信電話))、CDPD(Cellular Digital Packet Data)、Mobitex、DataTAC、iDEN(Integrated Digital Enhanced Network)、PDC(Personal Digital Cellular)、CSD(Circuit Switched Data)、PHS(Personal Handy-phone System)、WiDEN Wideband Integrated Digital Enhanced Network)、iBurst、Unlicensed Mobile Access(UMA、さらに3GPP Generic Access NetworkまたはGAN standardとも呼ばれる))、Wireless Gigabit Alliance(WiGig)規格、ミリ波規格一般(WiGig、IEEE 802.11ad、IEEE 802.11ayなどの10~90GHz以上で動作する無線システム)を含む。上に挙げた規格に加えて、例えば、とりわけ、ITU(国際電気通信連合)またはETSI(欧州電気通信規格協会)によって発行された規格に準拠した無線機を含む、任意の数の衛星アップリンク技術をアップリンク送受信機814に使用することができる。よって、本明細書で提供される例は、既存のものとまだ策定されていないものとの両方の、他の様々な通信技術に適用可能であると理解されたい。
ネットワークインターフェースコントローラ(NIC)816は、クラウド302またはメッシュデバイス812などの他のデバイスへの有線通信を提供するために備えられてもよい。有線通信は、イーサネット(登録商標)接続を提供してもよいし、とりわけ、コントローラエリアネットワーク(CAN)、ローカル相互接続ネットワーク(LIN)、DeviceNet、ControlNet、Data Highway+、PROFIBUS、またはPROFINETなどの他の種類のネットワークに基づいてもよい。第2のネットワークへの接続を可能にするために追加のNIC 816、例えばイーサネット(登録商標)を介してクラウドに通信を提供するNIC 816、および他の種類のネットワークを介して他のデバイスに通信を提供する第2のNIC 816が含まれてもよい。
バス806は、プロセッサ802を、外部デバイスを接続するために使用されるインターフェース818に結合することができる。外部デバイスとしては、加速度計、液位センサ、流量センサ、温度センサ、圧力センサ、気圧センサなどのセンサ820を挙げることができる。インターフェース818は、IoTデバイス800を、電源スイッチ、バルブアクチュエータ、可聴音発生器、視覚的警告デバイスなどのアクチュエータ822に接続するために使用されてもよい。
図示されていないが、様々な入出力(I/O)デバイスが、IoTデバイス800内に存在してもよいし、IoTデバイス800に接続されてもよい。例えば、ディスプレイが、センサの読み取り値またはアクチュエータの位置などの情報を示すために含まれてもよい。タッチスクリーンまたはキーパッドなどの入力デバイスが入力を受け入れるために含まれてもよい。
バッテリ824は、IoTデバイス800に電力を供給し得るが、IoTデバイス800が固定位置に取り付けられる例では、送配電網に結合された電源を有し得る。バッテリ824は、リチウムイオン電池、亜鉛空気電池、アルミニウム空気電池、リチウム空気電池などの金属空気電池、ハイブリッドスーパーキャパシタなどとすることができる。
バッテリモニタ/充電器826は、バッテリ820の充電状態(SoCh)を追跡するためにIoTデバイス800に備えられ得る。バッテリモニタ/充電器826は、バッテリ824の他のパラメータを監視して、バッテリ824の劣化状態(state of health)(SoH)および作動状態(SoF)などの障害予測を提供するために使用され得る。バッテリモニタ/充電器826は、Linear Technologies製のLTC4020もしくはLTC2990、アリゾナ州フェニックスのON Semiconductor製のADT7488A、またはテキサス州ダラスのTexas Instruments製のUCD90xxxファミリのICなどのバッテリモニタ集積回路を含むことができる。バッテリモニタ/充電器826は、バッテリ824に関する情報を、バス806を介してプロセッサ802に通信することができる。バッテリモニタ/充電器826はまた、プロセッサ802がバッテリ826の電圧またはバッテリ824からの電流を直接監視できるようにするアナログ-デジタル(ADC)変換器を含み得る。バッテリパラメータは、送信周波数、メッシュネットワーク動作、センシング周波数など、IoTデバイス800が実行することができる動作を判定するために使用され得る。
電力ブロック828、または送配電網に結合された他の電源が、バッテリ824を充電するためにバッテリモニタ/充電器826と結合されてもよい。一部の例では、電力ブロック828は、例えばIoTデバイス800内のループアンテナを介して、無線で電力を取得するために無線給電レシーバと置き換えられ得る。とりわけ、カリフォルニア州ミルピタスのLinear Technologies製のLTC4020チップなどの無線バッテリ充電回路をバッテリモニタ/充電器826に含めることができる。選択される具体的な充電回路は、バッテリ824のサイズ、従って必要とされる電流に依存する。充電は、とりわけ、Airfuel Allianceによって公表されたAirfuel規格、Wireless Power Consortiumによって公表されたQi無線充電規格、またはAlliance for Wireless Powerによって公表されたRezence充電規格を使用して実行することができる。一部の例では、電力ブロック828は、ソーラーパネル、風力発電機、水力発電機、または他の自然電力システムで拡張または置換することができる。
大容量ストレージ808は、本明細書で説明されるグループ作成機能を実施するための複数のモジュールを有することができる。大容量ストレージ808においてコードブロックとして示されているが、モジュールのうちのいずれも、例えば特定用途向け集積回路(ASIC)に組み込まれるなど、ハードワイヤード回路で完全にまたは部分的に置き換えられ得ることが理解されよう。大容量ストレージ808は、グループオブジェクトを形成するために使用され得るアトミックオブジェクトおよびコンポジットオブジェクトのサブオブジェクトリスト830を含み得る。集合グループ識別子832は、サブオブジェクトリスト830を使用して、例えばサブオブジェクトリスト830にハッシュ式を使用して、グループIDを生成することができる。
ネームサーバ834が、名前のサポートを提供し、ブロックチェーン836に名前をコミットするために備えられ得る。ネームサーバ834は、選択された名前が現在使用中ではいないことを確認し、グループオブジェクトに代わって動作するようにサブオブジェクトにクレデンシャルを発行することができる。
ブロックチェーン836は、グループオブジェクトの名前、グループオブジェクトを形成するサブオブジェクト、および形成済み、展開済み、または解消済みなどの、グループオブジェクトの現在のステータスに対応するトランザクションを有するデータのブロックを含む、トランザクションのデータベースを含む。識別情報に加えて、ブロックチェーン836は、グループオブジェクトおよびサブオブジェクト用の公開暗号化鍵などの認可情報を含むことができる。ブロックチェーン836のコピーが、メッシュネットワーク内のIoTデバイスの一部または全部に保存され得る。これにより、他のIoTデバイスがブロックチェーン836内の変更を確認し、適切な認可なしにブロックチェーン836を変更しようとするあらゆる試みを警告することが可能になる。この例ではグループ識別トランザクションに使用されているが、本明細書で説明するように、ブロックチェーン836は、セキュリティ、支払い、取引などに関連する他の任意の数のトランザクションに使用することができる。
グループのコンポジションがプライベートとみなされる場合、プロキシブローカ838は、ブロックチェーン836からグループオブジェクトのサブオブジェクトにクレデンシャルを提供し得る。これは、例えば、交差点や街路などの公共の場所にあるIoTネットワークのセキュリティを強化するために使用することができる。
EPIDサーバ840が、公開鍵または秘密鍵を使用してデータを暗号化したり復号したりするなどの暗号化サービスを提供するために備えられ得る。さらに、EPIDサーバ840は、サブオブジェクトがグループオブジェクトに代わって動作することを認可するために使用され得ると共に、鍵検証サーバとして動作することができるようにするための公開鍵または他のクレデンシャルを提供し得る。EPIDサーバ840は、図10から図15に関して説明したように、他のアプリケーションにおいて鍵を形成し発行するために、あるいは型アイデンティティを生成するために使用されてもよい。
図9は、一部の実施形態による、グループオブジェクトを形成するようにプロセッサ902に指示するためのコードを含む、例示的な非一時的機械可読媒体900のブロック図である。プロセッサ902は、バス904を介して非一時的機械可読媒体900にアクセスすることができる。プロセッサ902およびバス904は、図8のプロセッサ802およびバス806に関して説明したように選択することができる。非一時的機械可読媒体900は、図8の大容量ストレージ808について説明したデバイスを含むこともできるし、光ディスク、USBメモリ(thumb drive)、または任意の数の他のハードウェアデバイスを含むこともできる。
非一時的機械可読媒体900は、例えば図6および図7に関して説明したように、サブオブジェクトのリストからグループ名を計算するようにプロセッサ902に指示するためのコード906を含むことができる。コード908は、例えば、グループオブジェクト名がブロックチェーン910内に存在するか否かを判定するため、そして存在する場合、グループオブジェクトのステータスを判定するために、ブロックチェーン910にアクセスするようにプロセッサ902に指示するために含まれ得る。コード908はまた、名前が確認されると、ブロックチェーン910にトランザクションをコミットするようにプロセッサ902に指示することもできる。コード908はまた、ブロックチェーン910に対する変更を、IoTネットワーク内の他のユニットに移行するようにプロセッサ902に指示することができる。
機械可読媒体900は、グループオブジェクトのためのサブオブジェクトのアイデンティティをリストに格納するようにプロセッサ902に指示するためのコード912を含み得る。コード912はまた、グループへの参加要求が認可されたサブオブジェクトからのものであるか否かを判定するようにプロセッサに指示することができる。もしそうであれば、コード912はまた、要求しているサブオブジェクトにクレデンシャルを発行するようにプロセッサに指示することができる。機械可読媒体900は、プライバシー保護されたグループオブジェクトについてサブオブジェクトにクレデンシャルを提供するためのプロキシサーバとして動作するようにプロセッサに指示するためのコード914を含み得る。
機械可読媒体900は、グループオブジェクトのためのネームサーバとして動作するようにプロセッサ902に指示するためのコード916を含み得る。機械可読媒体900は、例えばサブオブジェクトとして、グループに参加するためのクレデンシャルを要求するようにプロセッサ902に指示するためのコード918を含み得る。
図10は、一部の実施形態による、オブジェクト型アイデンティティのためのEPIDの使用法を示す概略図1000である。デバイスオーナー1002は、コンポジットオブジェクト1010または1012からの登録要求1006または1008に基づいて新しい型を登録する型ネームサーバ1004を含む。本明細書で使用する場合、型またはオブジェクトを登録することは、型またはオブジェクトのデータベースまたはリストにその型またはオブジェクトを登録することを意味する。例えば、登録は、型を格納するためにトランザクションをブロックチェーンに送信することを含み得る。新しいオブジェクト型Tn+1は、サブオブジェクト1014~1018からコンポジットグループ1010または1012を合成することによって導出することができる。サブオブジェクト1014~1018の型名は、コンポジットオブジェクト1010または1012の新しい型名を形成するために使用され得る。
コンポジットオブジェクト1010または1012は、それが相互作用するサブオブジェクト1014~1018を調べることによって型名を動的に判定することができる。サブオブジェクト1014~1018の構成を検査するために2つの方法を使用することができる。第1の方法は、図12のラダー図に関して説明するように、イントロスペクションを使用する。イントロスペクションでは、IoTオブジェクト、またはリソースモデル定義を持つ他のデバイスは、要求されたときに自身を記述することができる。例えば、IoTオブジェクトは、要求されたときに、オブジェクトによって実装される構造、インターフェース、およびセマンティクスを提供するように構成できる。一部の態様では、IoTオブジェクトは、XMLスキーマ、JSONスキーマ、および/またはYANGなどのデータモデル言語(DML)を使用して構造、インターフェース、およびセマンティクスを記述することができる。実際の実装では、実行が遅くなる可能性があるため、データモデルを直接解釈することはしない場合もある。しかし、イントロスペクションによって生成されたDMが実装された挙動と一致することを示すためにテストを使用することができる。
第2の方法は、図13のラダー図に関して説明するように、アテステーションを使用して、デバイスの完全性、クレデンシャル、またはアイデンティティを確認することができる。本明細書で使用される場合、アテステーションは、デバイスまたはプラットフォームの信頼プロパティを開示するためのセキュアな方法であり、デバイスまたはプラットフォームは信頼プロパティを自己報告する。信頼プロパティは、プラットフォーム製造業者、暗号モジュール実装用のFIPS140-2など、セキュリティ強化を反映したベンダによって達成された認証を含むことができる。さらに、ISO9000、および品質を確保するために従うベンダのプロセスも関連し得る。アテステーションは、典型的には、ハードウェア、ファームウェア、およびソフトウェアのバージョンおよびパッチレベルを明らかにする。トラステッド実行環境(TEE)などの強化された環境によって保護されている鍵に関する情報、および鍵の種類に関する情報を明らかにし得る。例えば、強化された環境では、それほど強化されていない暗号化モジュールには、ある種類の鍵をTPMから移行できないような鍵の種類を定義するためにトラステッドプラットフォームモジュール(TPM)を使用できる。
イントロスペクションおよびアテステーションの両方とも、サブオブジェクト型付けに基づいてオブジェクトメンバシップを含むセットを生成できる。さらに、例えば、イントロスペクションアイデンティティが特定のユニットから来たことを確認するためにアテステーション鍵を使用して、2つの方法を一緒に使用することができる。すべてのIoTオブジェクトが型指定されているが、すべての型がその型を認証するクレデンシャルを持っているとは限らない場合がある。
例えば、図12のラダー図に関して説明されるように、新しいオブジェクト型名を導出する方法は、オブジェクト型の自動生成をサポートする。自動生成により、オブジェクトの有用な集合がオブジェクト複製のためにパターンを形成できる。次いで、入力パラメータとして型名およびパターンを使用して、ネットワーク内の他の場所で有用な集合をより容易にインスタンス化できる。
型ネームサーバ1004は、EPIDを使用して、型名をグループIDとして使用して、同じ型オブジェクトの各インスタンスをEPIDグループに入れることによって、オブジェクト型識別子を認証することができる。ブロックチェーン1022を使用して、例えば型ネームサーバ1004からのトランザクション1024をコミットすることによって、動的に導出された型の作成を記録することができ、その結果、同型の冗長性なしに同じ型のオブジェクトを信頼性をもってインスタンス化することができる。
図11は、一部の実施形態による、オブジェクト型を動的に作成するための例示的な方法1100のラダー図である。図11の方法1100は、図14に関して説明されるIoTデバイス1400によって実施することができる。段階1104において、コンポジットオブジェクト1102は、型グループ、例えばT1を作成する要求を型ネームサーバ1106に送信することができる(1104)。型ネームサーバ1106は、図10に関して説明したデバイスオーナー1002に含まれてもよいし、図4に関して説明したアグリゲータ406などの中央のデバイス内または別個のデバイス内にあってもよい。
段階1108において、型ネームサーバ1106は、型イントロスペクションの要求でコンポジットオブジェクト1102に応答する。段階1110において、要求は、イントロスペクションまたはアテステーション情報を提供するために、サブオブジェクト1112への要求の再帰的送信をトリガする。サブオブジェクト1112は、要求された情報で応答する(1114)。再帰が完了すると、コンポジットオブジェクト1102は、例えばT1=F(t1,t2,t3,...,tn)として、すべてのサブオブジェクト1112の型から型名を計算することができる(1116)。次いで、コンポジットオブジェクト1102は、型ネームサーバ1106に対して、EPID参加要求(1118)におけるオブジェクトインスタンス鍵を使用して、型をアテステーションすることができる。
型ネームサーバ1106は、作成イベントの以前のインスタンス化についての要求1120を、ブロックチェーン1122の管理者に送信する。型が既に存在することを示すメッセージ1124をブロックチェーン1122の管理者から受信することもある。これは、以前の型がその名前で既に作成されており、ブロックチェーン1122内に存在する、という型ネームサーバ1106による判定によっても実行され得る。
型が作成されていない場合、型ネームサーバは、ブロックチェーン1122内に型を作成する要求1128を発行する(1126)。これは、型ネームサーバ1106をホストするIoTデバイスに存在するブロックチェーン1122のインスタンス化したものに作成トランザクションをコミットすることによって行われ得る。
一部の例では、ブロックチェーン1122を格納する他のIoTデバイスは、例えば、それらが格納しているブロックチェーン1122内に型の別のインスタンス化したものを見つけることなど、新しい作成を確認することに失敗することがある。大多数が作成を確認するのに失敗した場合、それは拒否され、ブロックチェーン1122は以前のチェーンに戻る。次いで、型ネームサーバ1106は、型を再命名し(1126)、作成を再試行する(1128)。
例えば、ブロックチェーン1122の管理者から受信されたメッセージ1130によって示されるように、または大多数のIoTデバイスによる新しいブロックチェーン1122の確認によって、作成が成功した場合、型ネームサーバ1106は、コンポジットオブジェクト1102にEPID参加要求1132を発行することができる。EPID参加要求1132は、その型のためのEPIDクレデンシャルを含む。これらは、コンポジットオブジェクト1102によってサブオブジェクト1112と直接共有されてもよいし、サブオブジェクト1112は、新しい型名と共に参加要求を送信して、型ネームサーバ1106にクレデンシャルを提供させてもよい。
図12は、一部の実施形態による、再帰を使用した型イントロスペクションのための例示的な方法1200のラダー図である。同様の番号が付けられた項目は、図11に関して説明したとおりである。図12の方法1200は、図14に関して説明されるIoTデバイス1400によって実施することができる。イントロスペクションは、コンポジットオブジェクトからリーフオブジェクトへの接続グラフを提供する。リーフオブジェクトは、サブオブジェクトを持たないため、アトミックオブジェクトとしても知られている。
段階1202において、コンポジットオブジェクト1102は、コマンド1202をサブオブジェクト1204に送信して、イントロスペクションを実行するようにサブオブジェクト1204に指示することができる。サブオブジェクト1204がアトミックオブジェクトである場合、それは型の識別情報としてシグネチャを返す。サブオブジェクト1204自体がコンポジットオブジェクトである場合、サブオブジェクト1204は、サブオブジェクト1204を形成する各サブサブオブジェクト1208に、イントロスペクションを実行するためのコマンド1206を送信する。これは、下位層に送信されたコマンド1210および下位層から返された型グラフ1212または1214によって示されるように、コンポジットオブジェクト1102から各サブオブジェクト1204へ、そして各サブオブジェクト1204から各サブサブオブジェクト1208へと再帰的に行われる。
イントロスペクションは、サブオブジェクトグラフをウォークする方法として再帰を使用する。第1に、アトミックオブジェクトに遭遇した場合と、第2に、既に遭遇したオブジェクトに再度遭遇した場合と、の2つの起こり得る条件のうちの1つがあれば、再帰は停止する。サブオブジェクトグラフを再帰的にウォーキングすることにより、グラフ内の各ノードに到達するための少なくともそして多くても1つの方法から成るツリー(有向非巡回グラフ)が生成される。型グラフの形式は、G=(gn)、[G]Kn_instanceであり、gnはグループ番号、[G]はグループ名、Kn_instanceは具体的なグループの鍵である。ツリーの再帰的ウォークから戻ったときに、現在のノードは、マニフェストにエントリを追加して、オブジェクトの型情報を含むツリー構造を形成する。オブジェクトがインスタンス鍵を所有している場合、型情報は署名されている。よって、サブサブオブジェクト1208は、G'=(gn+1|gn)、[G']Kn_instanceの形式の型グラフを、サブオブジェクト1204に返すことができる。すべてのサブサブオブジェクト1208がそれらの型、すなわち型グラフをサブオブジェクト1204に返すと、それはそれ自身の型グラフ1216をコンポジットオブジェクト1102に返すことができ、例えば、G"=(gn+2|gn+1|gn)、[G"]Kn_instanceである。
結果のマニフェストは、ルートオブジェクトとしてコンポジットオブジェクト1102によって使用されて、自身の型名を生成する(1218)。これには、型名を生成するために使用される関数F()への入力として、ローカルスコープのプロパティ名を含まれ得る。図11に関して説明したように、マニフェストは型ネームサーバ1106に供給されてもよく、型ネームサーバ1106は型名のシグネチャおよび構成を検証してもよい。型ネームサーバ1106は、ブロックチェーン内で以前の型名の予約をチェックすることができる。元の型名が見つかってクレデンシャルが発行されると、ブロックチェーンが更新されて、型名予約ステータスの独立した検証が可能になる。
図13は、一部の実施形態による、再帰的型アテステーションのための例示的な方法1300のラダー図である。図13の方法1300は、図14に関して説明されるIoTデバイス1400によって実施することができる。再帰的オブジェクトアテステーションは、タイプ情報が、例えばデバイスにプログラムされた、またはデバイスにプログラムされたクレデンシャルから形成された、型名クレデンシャルを使用して署名され得るという違いがあるが、再帰的オブジェクトイントロスペクションと同様である。オブジェクト型クレデンシャルが使用されるとき、型名は以前に登録された型を識別することができ、従ってブロックチェーンはその型階層の履歴記録を含むことができる。従って、型のクレデンシャルを使用すると再帰が停止し得る。再帰的オブジェクトアテステーションの一実施形態では、型階層を再検証するための方法として、認証された型の終了を無視することができる。
段階1302において、コンポジットオブジェクト1102は、コマンド1302をサブオブジェクト1204に送信して、アテステーションクレデンシャルを送信するようにサブオブジェクト1204に命令する。サブオブジェクト1204がアトミックオブジェクトである場合、それは型の識別情報としてオブジェクトクレデンシャルを返す。サブオブジェクト1204自体がコンポジットオブジェクトである場合、サブオブジェクト1204は、サブオブジェクト1204を形成する各サブサブオブジェクト1208に、アテステーションクレデンシャルを送信するためのコマンド1304を送信する。これは、下位層に送信されたコマンド1306および下位層から返された型グラフ1308によって示されるように、コンポジットオブジェクト1102から各サブオブジェクト1204へ、そして各サブオブジェクト1204から各サブサブオブジェクト1208へと再帰的に行われる。同様の型グラフ1310が各サブサブオブジェクト1208からサブオブジェクト1204に返される。次いで、型グラフ1312を各サブオブジェクト1204からコンポジットオブジェクト1102に返すことができる。イントロスペクションに関しては、次いで、コンポジットオブジェクト1102は、各シグネチャを検証する(1314)。
図14は、一部の実施形態による、形成時にコンポジットオブジェクトに型を割り当てるための、IoTデバイス1400に存在し得るコンポーネントの一例のブロック図である。同様の番号が付けられた項目は、図3および図8に関して説明したとおりである。図8に関して説明したIoTデバイス800、および図14に関して説明されるIoTデバイス1400には、異なるコンポーネントを選択し使用することができることに留意されたい。
大容量ストレージ808は、本明細書で説明される型作成機能を実施するための複数のモジュールを含むことができる。大容量ストレージ808においてコードブロックとして示されているが、モジュールのうちのいずれも、例えば特定用途向け集積回路(ASIC)に組み込まれるなど、ハードワイヤード回路で完全にまたは部分的に置き換えられ得ることが理解されよう。大容量ストレージ808は、グループオブジェクトを形成するために使用され得るアトミックオブジェクト型およびコンポジットオブジェクト型をリストする型ネームサーバ1402を含み得る。型ネームサーバ1402は、コンポジットオブジェクトを形成するサブオブジェクトおよびサブサブオブジェクトの型を判定するためのコマンドを、型検査部1404に発行することができる。型検査部1404は、イントロスペクションまたはアテステーションを用いてメッシュデバイス812の再帰的検査を実行することができる。型グラフ生成部1406は、サブオブジェクトおよびサブサブオブジェクトからの応答を用いて型グラフを生成することができ、下位レベルのオブジェクトによって生成された型グラフを含む。型名計算部1408は、例えば型グラフ内のエントリのハッシュ関数を計算することによって、生成された型グラフから型名を生成するために使用され得る。IoTデバイス1400の型を識別するために型クレデンシャル1410を含めることができる。型クレデンシャル1410は、例えばアテステーションのために、製造業者によってデバイスにプログラムされたクレデンシャル、または例えばアテステーションのために、別のデバイスによってIoTデバイス1400に提供されたクレデンシャルを含むことができる。デバイスに提供されたクレデンシャルを確認または暗号化するためにデバイスに製造されたクレデンシャルを使用して、結合された型クレデンシャルを作成することができる。
グループ名トランザクションなどの他の情報に加えて、型名トランザクションを記録するために、ブロックチェーン836をIoTデバイス1400に含めることができる。本明細書で説明されるように、ブロックチェーン836のトランザクションは、ブロックチェーン836のコピーの格納もしているメッシュデバイス812の多数決によって確認され得る。
図15は、一部の実施形態による、グループオブジェクトを形成するようにプロセッサ902に指示するためのコードを含む、例示的な非一時的機械可読媒体1500のブロック図である。プロセッサ902は、バス904を介して非一時的機械可読媒体1500にアクセスすることができる。プロセッサ902およびバス904は、図8のプロセッサ802およびバス806に関して説明したように選択することができる。非一時的機械可読媒体1500は、図8の大容量ストレージ808について説明したデバイスを含むこともできるし、光ディスク、USBメモリ(thumb drive)、または任意の数の他のハードウェアデバイスを含むこともできる。
非一時的機械可読媒体1500は、コンポジットオブジェクト内のデバイスの型を判定するための再帰的型イントロスペクションを実行するようにプロセッサ902に指示するためのコード1502を含み得る。コード1504は、コンポジットオブジェクト内のデバイスの型を判定するために順次アテステーションを実行するようにプロセッサ902に指示するために含まれ得る。コード1506は、サブオブジェクトおよびサブサブオブジェクトから返された情報を用いて型グラフを構築するようにプロセッサ902に指示するために含まれ得る。コード1508は、例えば型グラフからハッシュ関数を計算して、型の型名を計算するようにプロセッサ902に指示するために含まれ得る。コード1510は、型名が既にブロックチェーン内にあるか否かを判定し、ない場合はブロックチェーンに型名をコミットするようにプロセッサ902に指示するために含まれ得る。コード1510はまた、メッシュネットワーク内の他のデバイスに格納されたブロックチェーン910に対する変更を移行するようにプロセッサ902に指示することができる。コード1512は、型グループを作成するサブオブジェクトにEPID参加要求を送信するようにプロセッサ902に指示するために含まれ得る。例えば、ブロックチェーン記録内の冗長性または他の障害のために名前が作成されていない場合に、コード1514は、型名を再生成してコミットプロセスを繰り返すようにプロセッサ902に指示するために含まれ得る。
図16は、一部の実施形態による、提携グループ1600の形成の概略図である。IoTネットワークは、提携グループ1600と呼ばれる、常に相互作用するわけではないオブジェクトの緩い提携を形成することができる。しかしながら、グループ抽象化の一部としてオブジェクトにラベルを付けることは意味値(semantic value)を提供し得る。提携グループ1600は、例えば、単一の建物内の床上またはアパート内に配置されたデバイスなどの、地域、位置、または汎用目的を示すために、管理上の決定によって形成され得る。デバイスオーナー1602などの管理局は、グループ化されたデバイスが使用するグループ識別子を、例えば提携グループネームサーバ1604を介して選択することができる。提携グループメンバ1606は、参加要求1608をデバイスオーナー1602に送信することによって提携グループ1600に登録することができる。提携グループネームサーバ1604から、EPIDクレデンシャルを含むクレデンシャル1610をグループメンバに提供することができる。クレデンシャル1610は、例えば、オブジェクト内インターフェース1614を介して、提携グループメンバ1606によってサブオブジェクト1612にさらに提供され得る。提携グループ名は、ブロックチェーン1616からアクセスすることができる、または作成時にブロックチェーン1616にコミットすることができる。
提携グループ1600のためのクレデンシャルにより、提携グループメンバ1606が、プライバシーを追跡するために使用され得る値を明らかにすることなく認証できる。従って、メンバシップの基準を秘密することができ、クレデンシャルの使用に関連するプライバシーリスクの程度を判定するためにグループのサイズが使用される。
IoTデバイスまたはオブジェクトによる提携グループ1600への登録により、そのオブジェクトが提携グループ1600のプロパティおよび属性を継承できる。提携グループメンバ1606のこれらのプロパティおよび属性は、グループプロパティおよび属性を処理するコード、状態、またはインターフェースを組み込まないこともある。それにもかかわらず、他のエンティティは、ソート、カテゴリ分け、経路指定、管理または分析を実行するためにプロパティおよび属性を命名することができる。この意味で、提携グループ化は、オブジェクトメタデータの動的適用のための戦略である。
図17は、一部の実施形態による、提携グループにメンバを登録するための例示的な方法1700のプロセスフロー図である。図17の方法1700は、図18に関して説明されるIoTデバイス1800によって実施することができる。ブロック1702は、IoTデバイスのグループに電力が供給される場合、または例えば仮想デバイスが起動される場合に、他の方法でIoTデバイスのグループが起動される場合を表す。ブロック1704において、ネットワークドメインオーナーは、グループ(G1,G2,...,Gn)を定義する。グループは、上階、階下などの位置指定、または管理、気候制御などの機能指定を含むことができ、スタジアムにおける避難、進入経路などの位置と機能との組み合わせを含むことができる。任意の数の他の指定が使用されてもよい。一般に、提携グループ名は、システムに有用なメタデータを提供するために選択される。
ブロック1706において、グループ、例えばG1が発見可能であるか否かに関する判定が行われる。発見可能ではない場合、ブロック1708において、グループはブロックチェーンにパブリッシュされる。ブロック1710において、オブジェクト、例えばO1から、グループG1に参加するための要求が受信され得る。ブロック1712において、EPID参加パラメータがオブジェクトO1から受信され得る。これらは、グループデバイスオーナーからの要求に応じて送信され得る。
ブロック1714において、提携グループネームサーバは、O1からの参加要求を検証する。要求は、任意の様々なクレデンシャルまたは技法を使用して認証され得る。例えば、提携グループネームサーバは、インスタンス、権限、または型名のクレデンシャルをチェックして、値がブロックチェーン内にあるか否かを判定できる。より高いセキュリティのアプリケーションでは、デバイスが提携グループに参加することを許可する前に、すべてのクレデンシャルが正しいことが要求される場合がある。同様に、より低いセキュリティのアプリケーションでは、提携グループネームサーバは、提携グループにデバイスを登録する際にクレデンシャルを必要としない場合がある。ブロック1716において要求が有効であると判定された場合、ブロック1718において、EPIDなどの提携グループクレデンシャルがオブジェクトO1に発行され得る。要求が有効であると判定されない場合、プロセスは、クレデンシャルを発行せずにブロック1720で終了する。
図18は、一部の実施形態による、提携グループを作成するための、IoTデバイス1800に存在し得るコンポーネントの一例のブロック図である。同様の番号が付けられた項目は、図3および図8に関して説明したとおりである。図8に関して説明したIoTデバイス800、および図18に関して説明されるIoTデバイス1800には、異なるコンポーネントを選択し使用することができることに留意されたい。
大容量ストレージ808は、本明細書で説明される提携グループの作成を実施するための複数のモジュールを含むことができる。大容量ストレージ808においてコードブロックとして示されているが、モジュールのうちのいずれも、例えば特定用途向け集積回路(ASIC)に組み込まれるなど、ハードワイヤード回路で完全にまたは部分的に置き換えられ得ることが理解されよう。大容量ストレージ808は、オブジェクトのための便利なグループ化を含む、提携グループネームサーバ1802を含むことができる。本明細書で論じられるように、グループは、位置、機能、または組み合わせに基づいて形成され得る。ユーザは、グループ化に使用されるパラメータを定義することができる。型ネームサーバ1802は、提携グループの名前を生成するために提携グループメンバリスト1804を構築し維持することができる。グループが発見可能ではない場合、パブリッシャ1806は、型、位置、および他のメタデータを含むグループの特性を他のIoTデバイスが利用できるようにして、それらのIoTデバイスがそれらがグループに参加すべきか否かを判定できるようにする。これは、例えば、グループ名およびコンポジションをブロックチェーン836にパブリッシュすることによって実行することができる。
グループ名トランザクションなどの他の情報に加えて、型名トランザクションおよびコンポジットオブジェクトトランザクションなどの他の情報に加えて、提携グループ名トランザクションを記録するために、ブロックチェーン836をIoTデバイス1800に含めることができる。本明細書で説明されるように、ブロックチェーン836のトランザクションは、ブロックチェーン836のコピーの格納もしているメッシュデバイス812の多数決によって確認され得る。
クレデンシャル検証部1808は、提携に参加することを望むIoTデバイスおよびコンポジットオブジェクトからクレデンシャルを受信するために含まれ得る。クレデンシャル検証部1808は、クレデンシャルが有効であるか否かを判定するためにブロックチェーン836内のトランザクションに対してチェックされ得る。有効である場合、クレデンシャル検証部1808は、EPIDサーバ840からクレデンシャルを取得し、それらを、サブスクリプション要求を送信したIoTデバイスまたはコンポジットオブジェクトに発行することができる。次いで、クレデンシャル検証部1808は、IoTデバイスまたはコンポジットオブジェクトが提携グループに加わったことを記録するために、トランザクションをブロックチェーン836にコミットすることができる。
図19は、一部の実施形態による、提携グループを作成するようにプロセッサ902に指示するためのコードを含む、非一時的機械可読媒体1900のブロック図である。プロセッサ902は、バス904を介して非一時的機械可読媒体1900にアクセスすることができる。プロセッサ902およびバス904は、図8のプロセッサ802およびバス806に関して説明したように選択することができる。非一時的機械可読媒体1900は、図8の大容量ストレージ808について説明したデバイスを含むこともできるし、光ディスク、USBメモリ(thumb drive)、または任意の数の他のハードウェアデバイスを含むこともできる。
非一時的機械可読媒体1900は、例えば位置、機能、またはその両方によって、提携グループを定義するようにプロセッサ902に指示するためのコード1902を含むことができる。コード1904は、提携グループが発見可能か否か、例えば、提携グループを識別するメタデータを用いて発見要求に応答するようにセットアップされているか否かを判定するようにプロセッサ902に指示するために含まれ得る。コード1906は、提携グループをブロックチェーンまたは直接周囲のデバイスにパブリッシュするようにプロセッサ902に指示するために含まれ得る。これにより、提携グループの存在が、知られている、発見可能、またはその両方になり得る。
コード1908は、アトミックオブジェクト、コンポジットオブジェクト、またはその両方を含むIoTデバイスからの提携グループに対する参加要求を受け入れるようにプロセッサ902に指示するために含まれ得る。参加要求は、提携グループを識別し、位置、型、および他のクレデンシャルまたはメタデータなどの検証情報を含むことができる。コード1910は、クレデンシャルを確認して、例えばそれらがブロックチェーン内に存在するか否かを判定する、ようにプロセッサ902に指示するために含まれ得る。コード1912は、EPID鍵などのクレデンシャルを要求者に発行するために含まれ得る。
例えば、提携グループ、メッシュネットワーク、フォグデバイス、または他の構成におけるIoTデバイス間の通信は、保護される必要があり得るが、これは、機能が制限されているデバイスにとって問題となり得る。さらに、IoTデバイスは、異なるネットワークに分散されている可能性があるため、通信の保護がより困難になる。分散型台帳システムが、IoTデバイスによる通信のセキュリティを強化し得る。
図20は、一部の実施形態による、準許可型分散型台帳トランザクション2000を用いてデバイス間の通信を可能にすることの概略図である。本明細書で使用される場合、準許可型分散型台帳システムは、トランザクション鍵を台帳に導入するためにエンハンストプライバシーID(EPID)鍵を使用する。分散型台帳エニュメレーション局(Distributed Ledger Enumeration Authority)(DLEA)2002と呼ばれる名前空間局は、台帳のインスタンスに固有の番号を割り当てる。DLEA 2002は、Internet Assigned Numbers Authority(IANA)、公的機関、民間団体、または使用中の番号の再利用を回避するための措置を講じることによって番号空間を管理する任意の団体によって運営され得る。
名前/番号を割り当てるためにDLEA 2002によって使用されるアルゴリズムは、使用中の割り当てられた番号に関して番号空間がまばらであるために、分散され得ることが観察され得る。よって、衝突の可能性は小さい。従って、DLEA 2002の複数のインスタンスが独立して動作する可能性がある。従って、DLEA 2002を、地政学的境界を越えてホストすることができ、政府または国連などの中央制御当局、あるいは単一の大規模民間組織を必要としない。さらに、分散型ブロックチェーンの独立性は、中央集権型命名局によって損なわれない。
DLEA 2002の運用上の完全性は、使用中のDLEA番号をパブリッシュするパブリック分散型台帳システムを使用して相互チェックすることができる。この台帳DLS-0 2004には「0」の値が割り当てられ、DLEA 2002が割り当てることは禁止されている。DLEA番号割り当ての適切な挙動は、とりわけIntel(登録商標)SGXエンクレーブ、ARM(登録商標)TrustZone、またはハードウェアセキュリティモジュール(HSM)などのトラステッド実行環境(TEE)に番号空間割り当てアルゴリズムを実装することによって強化できる。これらの環境では、番号割り当てアルゴリズムは、全世界の専門家コミュニティによって確認され得る。従って、DLEA 2002は、既に割り当てられた番号の再割り当てを回避するという単純な機能を実行するために、極めて高いレベルまで信頼され得る。
参加者、例えばP1 2006は、通信トランザクションの識別番号、例えばDLS-X#の要求2008をDLEA 2002に送信することができる。この要求は、[request DLS-X#,KTxRoot]KTxRootの形をとることができ、括弧内の情報はメッセージであり、括弧の外側の数字は、P1 2006の公開鍵KTxRootであり、これはメッセージの署名を示す。
DLEA 2002は、準許可型分散型台帳システム(DLS)のインスタンスに固有の番号を割り当て、DLEAが割り当てた番号を公開鍵KTxRootと共にDLS-0 2004に入力することができる(2010)。DLS-0 2004はパブリック分散型台帳システム(DLS)であり、DLEA 2002によってのみ書き込み可能であるが、すべてに対して可視である。
P1 2006は、新しい鍵Xの割り当てがいつ記録されたかを判定するために、台帳DLS-0 2004を監視することができる(2012)。割り当てられた番号Xは、新たに形成された台帳DLS-X 2014のルートまたは開始鍵としてP1 2006によって使用され得る。これは、新しい台帳DLS-X 2014にメッセージ(2016)、すなわち、[KTxRoot]KDLS-X、[KDLS-X、perm]KTxRoot、[KTxP2]KTxRootをコミットすることにより、台帳DLS-X 2014を作成することによって実行され、KTxP2は、新しい台帳トランザクション鍵であり得る。
新しい台帳DLS-X 2014はまた、DLS-X 2014の新しいメンバごとにEPID秘密鍵を確立するEPID「参加」プロトコルの実装するために使用され得る。EPID秘密鍵のその後の使用はすべて、台帳DLS-X 2014への最初のトランザクションの公開鍵KTxRootを使用して検証され得る。EPID秘密鍵のいずれもが、EPID鍵を用いて新しいTxKに署名することによってDLS-X 2014に台帳トランザクション鍵(KTx)を導入することができる。
例えば、別の参加者P2 2018は、参加要求2020を第1の参加者P1 2006に送信することができる。参加要求2020は、メッセージ[JoinP DLS-X]KMfg2、[KT×P2]KT×P2を含むことができる。第2の参加者P2 2018は、DLS-X 2014にアクセスすることによってトランザクション鍵KTxP2を入手した可能性がある。第2の鍵KMfg2は、KMfg2などの製造業者のEPID鍵であり、ルートKTxは、製造業者が提供する形式KMfgのEPID鍵によってアテステーションまたは署名される。KMfgは、ルートTxKを含むトラステッド実行環境(TEE)が十分に信頼できることをアテステーションする。同様に、新しい参加デバイスのTEE内のKMfgは、参加要求2020を保護するために使用される一時鍵、例えばKT×P2が正当で信頼できることをアテステーションするために使用される。
P1 2006は、要求を認証すると、P2 2018にメッセージ2022を返して参加を完了させることができる。メッセージ2022は、[[JoinI DLS-X]KTxRoot]KMfg1を含むことができ、KMfg1は、P1 2006に対する製造業者のEPIDである。ルートKTx、KTxRootは、参加プロトコル応答を認証するために使用される。
デバイスP1 2006およびP2 2018は、2つの異なる階層レベルに存在し得る。よって、P2 2018のレベルにある複数のデバイスは、例えば、本明細書で説明されるコンポジットオブジェクトおよびサブオブジェクトとしてP1 2006に参加することができる。同様に、参加者P3 2024などの他のデバイスは、下位レベルでP2 2018に参加することができる。参加するために、P3 2024は、[JoinP DLS-X]KMfg3、[KT×P3]KT×P3の形の参加プロトコル要求2026をP2 2018に送信することができる。P2 2018は、参加プロトコル要求2026を認証する場合、フォーマット[[JoinI DLS-X]KT×P2]KMfg2、[TxData,KTxP3]KTxP2のメッセージ2028で応答することができる。P3 2024は、フォーマット[[TxData,KTxP3]KTxP2]KDLS-XP3の署名したメッセージ2030を台帳DLS-X 2014に記録することによって、トランザクションを分散型台帳DLS-X 2014にコミットすることができる。
JoinPトランザクションを使用する代わりに、P2およびP3がブロックチェーン(X)のピアノードになってもよい。従って、それらは商取引に従事するためにトランザクション鍵(KT)を使用することができる。例えば、メッセージ2028は商品またはサービスを購入することであり得、メッセージ2026は商品またはサービスを販売することであり得る。この場合、それらはKTx鍵のみを必要とし、この技法はブロックチェーントランザクション鍵の挙動を記述している。
さらに、ブロックチェーンは、一般に、KDLS鍵を持たない。つまり、ブロックチェーンは準許可型トランザクションを施行可能ではない場合がある。例えば、メッセージ2028において、P2は商品またはサービスを購入しており、P3はP2がクラブのメンバ、例えば商業施設、オンラインオークションサイト、カジノクラブなどのメンバであることを知っている。従って、売り手P3もクラブの一部である場合、またはギャンブルチップなどのクラブ独自の通貨がクラブメンバによって提供される様々な商品またはサービスと交換される場合、P2は割引オファーを受けることができる。
便宜上、いくつかのウォレットを維持するためにEPIDをトランザクション鍵(KTx)として使用することは意味があり得る。本明細書で使用される場合、ウォレットは、通貨またはクレジット口座へのリンクを保持する暗号で保護された電子ストレージであり得る。この例では、P2およびP3は、分散型ウォレットのシェアをそれぞれ保持する異なるウォレット、例えば互いの分散型ウォレットであり得る。
EPIDがトランザクション鍵として使用され得る別のケースは、P2およびP3がそれぞれ、会社の従業員のグループや教会や民間企業を代表する人々のグループなど、グループのメンバである場合であり、様々なメンバが企業のエージェントとして動作し得る。ブロックチェーンの観点からは、シグネチャがアイデンティティを検証する限り、Tx鍵がEPID鍵であるか他の種類の鍵であるかは意味的には関係しない。
図21は、一部の実施形態による、準許可型トランザクションを実行するための例示的な方法2100のプロセスフロー図である。図21の方法2100は、図22に関して説明されるIoTデバイス2200によって実施することができる。ブロック2102は、例えば、デバイスが他のデバイスに参加するように命令されたときを表す。ブロック2104において、第1の参加者は、とりわけフォグデバイスを形成するIoTデバイスなどのモノのコミュニティが、高完全性保証で相互作用できると判定する。
ブロック2106において、第1の参加者は、コミュニティを表す名前を予約する。これは、例えば、名前、例えばDLS-X、および第1の参加者のための公開鍵をDLEAに送信することによって実行され得る。名前、例えばDLS-Xは、汎用固有識別子(UUID)、または複製の可能性が極めて低い他の識別情報であり得る。メッセージは、第1の参加者の秘密鍵によって署名され得る。
ブロック2108において、DLEAは、名前が現在使用中であるか、または以前に割り当てられているか否かを判定する。もしそうであれば、プロセスフローは、第1の参加者が新しい名前を選択するために、ブロック2106に戻る。そうでない場合、ブロック2110において、DLEAは、分散型台帳DLS-0にそれをコミットすることによって名前DLS-Xを予約する。DLEAへの最初のトランザクションを認証するために使用される鍵は、名前と共に台帳にコミットされ得る。
ブロック2112において、第1の参加者は、DLS-Xの名前がDLS-0に現れるときに、その名前を使用することができる。これは、DLS-0台帳を監視している第1の参加者によって判定され得る。ブロック2114において、第1の参加者は、EPIDを使用してDLS-Xグループ公開鍵を確立し、許可ポリシーを定義する。グループ公開鍵およびポリシーは、第1の参加者のトランザクション鍵を使用してDLS-X台帳にコミットされる。第1の参加者のトランザクションはまた、EPIDグループ秘密鍵を使用してDLS-Xにコミットされる。
ブロック2116において、第2の参加者は、第1の参加者からDLS-Xグループ秘密鍵を取得することによってDLS-Xグループに参加することができる。第1の参加者は、EPIDグループ鍵発行部として動作し得る。第2の参加者は、製造業者の鍵、例えば製造業者のEPID鍵を使用して、そのデバイスの信頼性をアテステーションすることができる。ブロック2118において、第2のデバイスのアテステーションが信頼できるか否かに関する判定が行われる。信頼できない場合、方法2100は、ブロック2120で終了する。
アテステーションが信頼できる場合、ブロック2122において、第2の参加者は、それがDLS-XのためのEPIDグループ公開鍵の下に第2のグループ秘密鍵を生成することを可能にする、EPID参加プロトコル応答を受信する。ブロック2124において、第2の参加者は、そのトランザクション鍵に自己署名し、それを第1の参加者に配布する。第1の参加者は、第2の参加者の公開鍵に署名し、そのトランザクションを台帳DLS-Xにコミットし、それによって第2の参加者をDLS-Xに紹介する。ブロック2126において、別の参加者がいるか否かに関する判定が行われる。もしいれば、プロセスフローは、ブロック2116に戻り、次の登録を再開する。
ブロック2128において、第3の参加者は、自身を第2の参加者に紹介することができる。これは、第3の参加者が第3の参加者のトランザクション鍵に自己署名し、それを第2の参加者に送信することによって行われ得る。第2の参加者は、第3の参加者の公開トランザクション鍵に署名し、任意選択で、トランザクションデータを含み、そのトランザクション鍵およびDLS-Xグループ鍵を用いて署名する。
ブロック2130において、第3の参加者は、トランザクションをDLS-Xにコミットする。これは、トランザクションをDLS-Xブロックチェーンにコミットする前に、第3の参加者が第3の参加者のDLS-Xグループ秘密鍵を使用して第2の参加者のトランザクションデータに署名することによって実行され得る。第2の参加者はまた、そのDLS-Xグループ秘密鍵を使用してトランザクションデータをDLS-X台帳にコミットすることができる。このシナリオでは、第3の参加者はまた、第3の参加者のDLS-Xグループ鍵を使用して、第3の参加者の自己署名付きのtx鍵にも署名する。次いで、方法2100は、ブロック2120で終了する。
図22は、一部の実施形態による、提携グループを作成するための、IoTデバイス2200に存在し得るコンポーネントの一例のブロック図である。同様の番号が付けられた項目は、図3および図8に関して説明したとおりである。図8に関して説明したIoTデバイス800、および本明細書で説明される他のIoTデバイスに対して選択されたものとは異なるコンポーネントが、IoTデバイス2200に対して選択され使用されてもよいことに留意されたい。
大容量ストレージ808は、本明細書で説明される提携グループ形成を実施するための複数のモジュールを含むことができる。大容量ストレージ808においてコードブロックとして示されているが、モジュールのうちのいずれも、例えば特定用途向け集積回路(ASIC)に組み込まれるなど、ハードワイヤード回路で完全にまたは部分的に置き換えられ得ることが理解されよう。大容量ストレージ808は、オブジェクトのグループが高信頼保証で相互作用できるか否かを判定するグループ作成部2202を含み得る。
本明細書で論じるように、保証は、製造業者によってIoTデバイス2200、および他のメッシュデバイス812にプログラムされたアテステーション鍵に基づくことができる。グループ作成部2202は、グループの名前を作成することができる。DLEAアクセス部2204は、その名前が利用可能であるか否か、またはIoTデバイス2200が別の名前を作成する必要があるか否かを判定するためにDLEAにアクセスすることができる。名前が利用可能である場合、DLEAは、その名前を分散型台帳DLS-0にコミットする。DLEAアクセス部2204は、名前がコミットされたか否かを判定するためにDLS-0を監視することができる。鍵作成部2206は、例えばEPIDサーバを使用して、グループ作成部2202によって作成された名前に基づいて鍵を作成することができる。鍵作成部2206は、鍵をローカルの分散型台帳DLS 2208にコミットすることができる。DLS 2208は、IoTデバイス2200内に存在してもよいし、別のメッシュデバイス812内に存在してもよい。アテステーション確認部2210は、別のデバイスからの参加要求が有効であるか否かを判定するために含まれ得る。有効である場合、グループ参加部2212は、グループ鍵と共に参加メッセージを送信することができる。
図23は、一部の実施形態による、グループにおいてセキュアに通信するようにプロセッサ902に指示するためのコードを含む、非一時的機械可読媒体2300のブロック図である。プロセッサ902は、バス904を介して非一時的機械可読媒体2300にアクセスすることができる。プロセッサ902およびバス904は、図8のプロセッサ802およびバス806に関して説明したように選択することができる。非一時的機械可読媒体2300は、図8の大容量ストレージ808について説明したデバイスを含むこともできるし、光ディスク、USBメモリ(thumb drive)、または任意の数の他のハードウェアデバイスを含むこともできる。
非一時的機械可読媒体2300は、グループが高完全性で通信し得ることを判定するようにプロセッサ902に指示するためのコード2302を含み得る。コード2304は、グループの名前を生成し、その名前を分散型台帳エニュメレーション局(DLEA)で予約するようにプロセッサ902に指示するために含まれ得る。コード2306は、登録された名前から他の鍵を作成し、その情報を新しい分散型台帳DLS-X 2308にコミットするようにプロセッサ902に指示するために含まれ得る。
コード2310は、IoTデバイス、コンポジットオブジェクト、またはその両方からのグループに対する参加要求を確認するようにプロセッサ902に指示するために含まれ得る。参加要求は、要求側デバイスに提供される製造業者の鍵などのアテステーション情報を含み得る。コード2312は、EPIDなどのクレデンシャルを要求者に発行するようにプロセッサ902に指示するために含まれ得る。コード2314は、秘密鍵、公開鍵、または両方の組み合わせを使用して、分散型台帳DLS-Xにトランザクションデータをコミットするようにプロセッサ902に指示するために含まれ得る。
セキュアな通信に加えて、ブート中のセキュリティは、ネットワークを侵入から保護するのに役立つ。セキュアなブートは、トラステッド実行モジュール(TEM)または他のハードウェアデバイスを使用して、より大きなIoTデバイスを含むより制約の少ないシステムで実施され得るが、より多くのリソースが制約されたIoTデバイスにとっては、より困難であり得る。
図24は、一部の実施形態による、IoT環境においてデバイスをセキュアにブートするためのトラステッド実行環境(trusted execution environment)(TEE)の使用法の概略図2400である。トラステッドコンピューティングは、主に、コンピューティングデバイスの信頼できる属性をアテステーションするデバイスの能力に関係している。通常、信頼に影響を与える属性には、トラステッドブートまたはセキュアなブートがある。
トラステッドブートは、ロードおよび実行される次のコードブロックのハッシュを計算する測定動作を有するブートシーケンスを含む。測定値は、トラステッドモジュール(TEE)2402などのセキュアなストレージに格納される。IoTデバイスでは、トラステッドモジュール2402は、別個のデバイスであってもよいし、暗号化されているか、そうでなければIoTデバイスのプロセッサまたは一般的なオペレーティングコードに一般にアクセスできない、保護されたメモリ領域であってもよい。セキュアなブートは、許可されたプロセスのホワイトリストに対する測定値のチェックを追加する、トラステッドブート環境への拡張である。典型的には、実際の測定値とホワイトリストの測定値とが一致しない場合は、例えば非セキュア環境でブートし他のデバイスにそのことを通知することによって、ブートシーケンスが変更される。
トラステッドブートが完了すると、セキュアな実行のためにTEEが提供され得る。コードがTEEなどの強化された実行環境でロードされるか、静的束縛されている場合、実行される動作は一部の攻撃に抵抗し得る。強化された実行環境は、TEEを作成するためのトラステッドプラットフォームモジュール(TPM)などの任意の数のハードウェア強化型セキュリティシステムを含み得る。強化技法は、とりわけ、Intel(登録商標)のソフトウェアガードエクステンションズ(SGX)、ARM(登録商標)のTrustZone(登録商標)、TPMなどのハードウェアセキュリティモジュール(HSM)、スマートカード、または仮想化を含み得る。
TEEはまた、セキュアな更新のための環境を提供し得る。セキュアなブートは、ロード時にコードの真正性をチェックする。セキュアな更新は、マイクロソフトのAuthenticode(登録商標)テクノロジなどのコード署名を使用して完全性および真正性を保証する。マニフェスト構造は、インストールイメージの一部として、コードハッシュ値とハッシュ値に対するシグネチャとの関連付けを管理するために使用できる。インストールイメージパッケージの技法としては、とりわけ、Itsy Package Management System(IPKG)、Debian Linux(登録商標)インストールファイル(DEB)、RPMパッケージマネージャファイル(RPM)、およびClear Linux(登録商標)バンドルが挙げられる。
TEEは、セキュリティ関連データの一時的ストレージと長期的ストレージとの両方にセキュアなストレージを提供することができる。データ種別としては、鍵、ホワイトリスト、ブラックリスト、測定値、監査ログ、パスワード、バイオメトリクス、証明書、およびポリシーが挙げられる。強化技法としては、分離、改ざん防止、暗号化、難読化などが挙げられる。
アテステーションは、セキュアな環境の一部であり得る。本明細書で説明されるように、アテステーションは、デバイスまたはプラットフォームがその信頼プロパティを自己報告する、セキュアな実行またはセキュアなストレージ機能に結び付けられた報告機能である。これは、問題となっているセキュアな機能に適用される強化技法および保証を詳述する。アテステーション機能自体は、強化および保証が、それが報告している機能の品質レベルを超えるセキュアな機能である必要がある。
トラステッドコンピューティングの課題は、いくつかの要因によりIoT設定において増加し得る。例えば、IoTデバイスは、サイズ、機能、および経済性によって制約を受ける可能性がある。セキュリティ強化は、これらのコストとのトレードオフとして生じることが多い。トラステッドコンピューティングのビルディングブロックを含めることは、コストに制約のあるデバイス上では欠落しているか不完全である可能性がある。
さらに、IoTネットワークは、複数のデバイスに機能を分散させることがあるため、ネットワークビルディングブロックへの依存度が高くなる。その結果、ネットワークがコンピューティングファブリック全体においてより大きな要素になるにつれて、ネットワークの挙動はより問題になる可能性がある。ネットワークの複雑さおよび規模が増大するにつれて、望ましくない挙動が増幅される可能性がある。
IoTネットワークには、複数のベンダ、付加価値再販業者、インテグレータ、サプライヤ、およびアナリストのデバイスおよびアプリケーションが含まれることがよくある。これらの各プレーヤは、予期しない望ましくない動作を招くことなく、インターフェース、構造、コンピューティング環境、および動作手続きを確実に適切に一致させるために協力しなければならないシステムを作成し得る。
一部の態様では、これらの問題に対処するために、IoTネットワークは、複数のデバイスにわたって信頼を分散させている場合がある。分散は、集中化によってもたらされる信頼性、可用性、および安全性の低下に対処するための1つの方法である。また分散により、本来の中央管理点が解消するにつれて決定プロセスが散乱される。
一部の態様では、IoTネットワークにおけるトラステッドコンピューティングアテステーションは、ブロックチェーン技術を使用することによって改善され得る。トラステッドコンピューティングの概念は、セキュリティの基本となる機能を実行する信頼ルートのセットを定義し、ルート機能の適切で期待される挙動が期待どおりに機能すると黙示的に信頼される。例えば、トラステッドモジュール2402内のトラステッドコンピューティンググループ(TCG)は、いくつかの信頼ルートを含み得る。
測定のルートオブトラスト(RTM)2404は、システム内の最初のロード可能オブジェクトを測定し検証することができる機能である。報告のためのルートオブトラスト(RTR)2406は、ストレージのためのルートオブトラスト(RTS)2408内の値と、RTM 2404、RTR 2406、およびRTS 2408を実装するコンピューティング環境と、をアテステーションする機能である。アテステーション機能は、RTR 2406内で再帰的に定義することができる。ストレージのためのルートオブトラスト(RTS)2408は、RTM 2404およびRTR 2406によって生成され消費された値を格納する機能である。
セキュリティ機能を分散させることによってセキュリティを向上させるために、IoTネットワーク環境でブロックチェーンのルートオブトラストを使用することができる。ブロックチェーンを使用したIoTネットワークにおける分散された信頼は、ブロックチェーンに追加の2つのルートオブトラストを追加することができる。連鎖のためのルートオブトラスト(RTC)2410は、RTR 2406などのローカルのトラステッドコンピューティングルートにブロックチェーンリソースを公開する機能である。RTC 2410およびRTR 2406は、例えば、アテステーション済み属性をチェーン履歴2412に保存することによって、アテステーション済み属性をブロックチェーンにコミットするように協働することができる。ブロックチェーンの信頼プロパティは、閾値コンセンサスプロトコルを使用して期待される挙動を保証するためのメカニズムとして分散を使用するため、非常に望ましいものである。
アーカイブ機能に対するルートオブトラスト(RTA)2414は、他のルートに可用性コンポーネントを追加する。制約されたIoTデバイスは、測定の履歴2416および複数の再ブートにわたる測定ログを維持するためのリソースを持たない場合がある。さらに、過去の構成または予想される構成を記述する拡張ホワイトリスト2418を格納することができない可能性がある。トラステッドコンピューティングの照会では、履歴コンテキストの探索が必要になる場合がある。RTA 2414は、全ブロック履歴を維持できない可能性があるRTCノードにアーカイブ機能を追加する。
本明細書で説明されるシステムは、チェーン履歴2412を維持するために他のデバイス内のブロックチェーンロジック2422と連携するブロックチェーンロジック2420と共に使用され得る。これは、例えば、ブロックチェーンのチェーン履歴2412を他のデバイスに伝播すること(2424)を含み得る。他のデバイスでは、チェーン履歴2412をローカルコピーと比較して、行われた変更が確実に認可されるようにすることができる。変更が認可されていないことに大多数のデバイスが同意する場合、ブロックチェーンロジック2420は、チェーン履歴2412を以前の履歴に戻す。
図25は、一部の実施形態による、ブート完全性トランザクションを保持するブロックチェーンブロック2502のブロック図2500である。図24も参照すると、ブロックチェーンブロック2502は、チェーン履歴2412または他の分散型台帳システム内に単一の記録を形成する。RTC 2410は、プラットフォーム構成レジスタ(PCR)に測定値2504を含むブロックを構成する。PCRは、保護領域内、特定のハードウェアデバイス内、またはその両方におけるメモリロケーションであり得る。
一部の態様では、ブロックチェーンブロック2502に使用される測定値のサンプルレートは、測定値がPCRに保存されるレートよりも粒度を細かくすることができ、例えばPCRは拡張される。しかしながら、すべてのPCRの拡張によって、ブロックに追加されたトランザクションがトリガされる場合がある。PCR値は、ブロック署名鍵とは異なり得るアテステーション署名鍵2506によって署名される。本質的には、RTR 2406は、その現在の完全性状態についてブロックチェーンをアテステーションしている。RTC 2410は、PCRが未検出のシステムリセットによって上書きされていないことをアテステーションしている。
ブロック図2500はまた、前のブロックチェーンブロック2510および2512の存在を示すことができる。この図には示されていないが、これらのブロック2510および2512は、他のブート完全性トランザクションを保持してもよいし、コンポジットオブジェクト、オブジェクト型、提携グループコンポジション、セキュアトランザクションデータ、またはIoTネットワークのセキュリティをサポートする任意の数の他の項目についての情報を保持してもよい。
図26は、一部の実施形態による、ブロックチェーンによるホワイトリストイメージ収集の使用法の概略図2600である。同様の番号が付けられた項目は、図24に関して説明したとおりである。ブートプロセスが、第1のIoTデバイス2602上で行われている。例えば、システムにプログラムされた製造業者の鍵2612で暗号化された通信2608を使用して、イメージリポジトリ2604にアクセスしてホワイトリストイメージ2606を取得することができる。一部の例では、それらは、イメージリポジトリ2604の代わりに、またはそれに加えて、チェーン履歴2412またはブロックチェーンからアクセスされてもよい。イメージリポジトリ2604内のイメージは、参照カウントを維持することができるように、他の類似のIoTデバイス2610によって格納されていてもよい。各デバイスはブート完全性報告を記録するブロックチェーントランザクションに署名することができるため、参照カウントは、同じデバイスからの再ブートアクティビティと異なるデバイスからのアクティビティとを区別することができる。
測定値は、例えば、ブートシーケンスにおいて実行される次のソフトウェアのハッシュコードを計算することによって、IoTデバイス2602がブートするときに取得される。測定値は、完全性を保証するために、例えばホワイトリストイメージ2606内のホワイトリスト値と比較されてもよい。イメージマニフェスト2614を使用して、ホワイトリスト値の発生を確認することができる。マニフェスト2614は、イメージ2606の動的に取得されたハッシュと比較することができるホワイトリストハッシュ値を含むことができる。
IoTネットワークにおけるホワイトリストの構築が難しいのは、イメージの母集団が変化するレートのためであり、例えば、イメージリポジトリ2604が大きくなるにつれて、ある配置のデバイスがホワイトリストへの包含のために選択された参照イメージを見つけるためにリポジトリに依存する可能性が高くなるためである。ネットワークにデータ重複排除機能およびトラステッド削除機能がない限り、リポジトリ内のイメージを参照するIoTデバイスが存在し得るため、イメージの数は単調増加する。ブロックチェーン履歴は、そのイメージを参照しているデバイスの需要に関してイメージリポジトリに通知する方法である。もはや使用されていないデバイスは、履歴2412に現れず、従ってイメージリポジトリによってカウントされる参照対象ではなくなるであろう。イメージリポジトリ2604は、ブート完全性チェックを実行するデバイスを明らかにする「ヒートマップ」を維持することができる。もはやデプロイされていない古いデバイスを廃れさせる戦略は、イメージリポジトリ2604からそれらのイメージ2606を除去し、ホワイトリストの参照をブロックすることであり得る。この手法は、新しいイメージが作成される成長率に相関するデコミッション率を選択するように調整することができる。
図27は、一部の実施形態による、ホワイトリストイメージについての完全性トランザクションを有するブロックチェーンブロック2702の図である。ブロックチェーンブロックを実装するために、ベンダ、メーカ、およびコード生成ファクトリは、ブロックチェーン機能を生産プロセスに組み込むことができる。各ホワイトリストイメージは、マニフェスト2706を含むマニフェスト構造2704を使用して署名されてもよい。イメージを生成するデベロッパまたはファクトリは、どのエンティティがイメージを製造したかを確立するために、EPID鍵であり得る製造業者の鍵2708を使用してそれに署名することができる。本明細書で説明するように、署名付きマニフェスト2704がブロックチェーンブロック2702に追加され、適切なトランザクション鍵を使用してブロックチェーンのチェーン履歴2412(図24)にコミットされる。
図28は、一部の実施形態による、ブロックチェーンのルートオブトラストを使用するセキュアなブートプロセスフローのための例示的な方法2800のプロセスフロー図である。図28の方法2800は、図29に関して説明されるIoTデバイス2900によって実施することができる。ブロック2802は、例えばブート完全性エージェントがオブジェクトを測定するときを表す。本明細書で論じるように、これは、ブートされる次のコードのハッシュコードを計算し、そのコードのイメージを作成することによって実行され得る。ブロック2804において、イメージが良好であることがわかっているか否かに関する判定が行われる。そうである場合、IoTデバイスが正常な動作を続行するとき、方法2800はブロック2806で終了する。そうでない場合、ブロック2808において、イメージが不良であることがわかっているか否かに関する判定が行われる。もしそうであれば、方法2800は、ブロック2810において、コードの隔離および問題の修正をもって終了する。
ブロック2808において、イメージが不良であることが知られていない場合、プロセスフローは、ブロック2812に進み、イメージが未知であるか否かに関する判定が行われる。そうでない場合、方法2800は、例えば、ステータスが信頼できないとしてリストされている状態で、ブロック2814で終了することができる。そうである場合、方法2800は、適用されるアクションを判定するためにローカルポリシーが調べられるブロック2816で終了することができる。
ブロック2804における比較に使用するためのイメージを取得するために、ブロック2818において、サイト管理者は、例えばクラウドリポジトリから参照ハッシュを取得することができる。ハッシュは、他のIoTデバイス、製造業者などを含む他の情報源から取得されてもよい。ブロック2820において、ハッシュ上の署名が有効であるか否かに関する判定が行われる。そうでない場合、方法2800は、ブロック2822で終了する。ブロック2824において、イメージハッシュがブロックチェーン(BC)ハッシュに等しいか否かに関する判定が行われる。等しい場合、ブロック2826において、サイト管理者は、イメージのマニフェストに署名する。ブロック2828において、イメージは、ホワイトリストに追加され、ホワイトリストは、ブートコードによるアクセスのためにブロックチェーンにコミットされる。次いで、ホワイトリストイメージは、ブロック2804において、例えば、ブロックチェーン内またはイメージリポジトリ内のホワイトリストにアクセスするIoTデバイスによって比較に使用され得る。
ブロック2824でイメージハッシュがBCハッシュと一致しない場合、ブロック2830において、イメージハッシュが攻撃シグネチャを含むか否かに関する判定が行われる。含む場合、ブロック2832において、イメージは、ブラックリストに追加されてもよく、ブラックリストは、ブロックチェーンにコミットされ得る。次いで、ブラックリストイメージは、ブロック2808において、例えば、ブロックチェーン内またはイメージリポジトリ内のブラックリストにアクセスするIoTデバイスによって比較に使用され得る。
ブロック2830でイメージハッシュが既知の攻撃シグネチャと一致しない場合、ブロック2834において、イメージは、未分類のリストに追加され得る。次いで、未分類のリストをブロックチェーンに追加することができる。次いで、未分類のイメージは、ブロック2812において、例えば、ブロックチェーン内またはイメージリポジトリ内の未分類のリストにアクセスするIoTデバイスによって比較に使用され得る。
攻撃シグネチャは、任意の数の技法で識別され得る。例えば、ブロック2836において、フォレンジックラボが攻撃を識別し、そのイメージの攻撃シグネチャを生成することができる。本明細書で使用される場合、フォレンジックラボは、出回っているマルウェア、ウイルス、および他の問題のあるコードを識別する商用セキュリティサービスであり得る。ブロック2838において、フォレンジックラボは、イメージの攻撃シグネチャをブロックチェーンに書き込むことができる。一部の例では、サイト管理者は、商用フォレンジックラボから攻撃シグネチャを入手し、その攻撃シグネチャをブロックチェーンに書き込むことができる。ブロック2840において、ブロック2830で使用するために、ブロックチェーンから攻撃シグネチャを取得することができる。
本明細書で説明されるように、セキュアなブートプロセスは、参照測定値を取得および確認し、ホワイトリスト、ブラックリスト、またはローカル測定値を評価するために使用され得る未分類リストを策定するためのブロックチェーンの使用を含むように拡張され得る。セキュアなブートの施行は正常に行われる。よって、ブロックチェーンは、ネットワーク隔離のための施行ポイントのための情報を提供することができ、それは、既知の不良または未知の構成が見つかったときにデバイスへの、またはデバイスからのパケットの流れにファイアウォール制限を課すことができる。さらに、ブロックチェーンは、信頼できる情報源から参照測定値を取得しようとし得るソフトウェア更新サーバに通知し得る。
図29は、一部の実施形態による、セキュアなブートのための、IoTデバイス2900に存在し得るコンポーネントの一例のブロック図である。同様の番号が付けられた項目は、図3および図8に関して説明したとおりである。図8に関して説明したIoTデバイス800、および本明細書で説明される他のIoTデバイスに対して選択されたものとは異なるコンポーネントが、IoTデバイス2900に対して選択され使用されてもよいことに留意されたい。
大容量ストレージ808は、本明細書で説明される提携グループ形成を実施するための複数のモジュールを含むことができる。大容量ストレージ808においてコードブロックとして示されているが、モジュールのうちのいずれも、例えば特定用途向け集積回路(ASIC)に組み込まれるなど、ハードワイヤード回路で完全にまたは部分的に置き換えられ得ることが理解されよう。
大容量ストレージ808は、システム内の最初のロード可能オブジェクトを測定し検証することができるルートオブトラスト測定部(RTM)2902を含むことができる。ルートオブトラストストレージマネージャ(RTS)2904は、RTM 2902およびルートオブトラスト報告部(RTR)2906などの他のセキュリティシステムによって生成および消費された値を格納することができる。RTR 2906は、ストレージのためのルートオブトラスト(RTS)2408内の値と、RTM 2404、RTR 2406、およびRTS 2408を実装する環境と、をアテステーションすることができる。ルートオブトラストアーカイブ部(RTA)2910は、全チェーン履歴2912を維持する機能を持たない場合があるRTCノードにアーカイブ機能を追加することができる。
様々な履歴データベースが、IoTデバイス2900内で維持されてもよいし、他のメッシュデバイス812上でアクセスされてもよい。例えば、ブロックチェーンロジック2914は、ブロックチェーンのブロックを含むチェーン履歴2912を維持することができる。さらに、ブロックチェーンロジック2914は、他のメッシュデバイス812に変更をプッシュしてもよいし、他のメッシュデバイス812によってブロックチェーンに行われた変更を受け入れて確認してもよい。ホワイトリスト履歴2916は、例えば変更がチェーン履歴2912にコミットされる前に、ホワイトリスト、およびホワイトリスト項目に行われた変更を保持することができる。さらに、ホワイトリスト履歴2916は、ブラックリストおよび未分類のリストなどの他のリストおよび変更を保持することができる。測定履歴2918は、例えばイメージとの比較のために、ブートプロセス中に行われた現在および過去の測定値を保持することができる。
図30は、一部の実施形態による、セキュアにブートするようにプロセッサ902に指示するためのコードを含む、例示的な非一時的機械可読媒体3000のブロック図である。プロセッサ902は、バス904を介して非一時的機械可読媒体3000にアクセスすることができる。プロセッサ902およびバス904は、図8のプロセッサ802およびバス806に関して説明したように選択することができる。非一時的機械可読媒体3000は、図8の大容量ストレージ808について説明したデバイスを含むこともできるし、光ディスク、USBメモリ(thumb drive)、または任意の数の他のハードウェアデバイスを含むこともできる。
非一時的機械可読媒体3000は、コードオブジェクトを実行する前にコードオブジェクトを測定するようにプロセッサ902に指示するためのコード3002を含み得る。コード3004は、既知の良好なイメージのリストに対して測定値を比較するようにプロセッサ902に指示するために含まれ得る。コード3006は、既知の不良のイメージのリストに対してオブジェクトを比較するようにプロセッサ902に指示するために含まれ得る。コード3008は、イメージを分類し、信頼レベルを判定するようにプロセッサ902に指示するために含まれてもよく、例えば、プロセッサが、トラステッド実行環境でブートすることを可能にする、プロセッサが非トラステッド環境でブートすることを可能にする、またはブートを阻止し、サイト管理者に警告する。コード3010は、ブロックチェーン3014を維持するようにプロセッサ902に指示するために含まれてもよく、例えば、とりわけ、トランザクションをチェーン履歴にコミットする、トランザクションの変更を他のIoTデバイスに転送する、または他のIoTデバイスからの変更を確認する。コード3012は、例えば、RTM 2404、RTR 2406、RTS 2408、RTC 2410、およびRTA 2414について図24に関して説明したように、ルートオブトラストを維持するために含まれ得る。機械可読媒体3000はまた、図24に関して説明したチェーン履歴2412などのブロックチェーンを格納することができる。
図31は、一部の実施形態による、パブリックドメイン3102、プライベートドメイン3104、およびパブリック-プライベートドメイン3106にわたる相互運用性を示す概略図3102である。ネットワークトポロジは、連続的に変化している状態であり得るため、パーマネントマップでのいかなる試行も不可能である。従って、IoTデバイスは、ドメインネームサーバ(DNS)などのバックボーンリソースを使用して、ドメイン間でパケットを送信することができる。パケットは、ルータ3108として示されているインターネットバックボーンを介してドメイン3102、3104、および3106の間で経路指定され得る。
一部の態様では、ルータ3108は、ドメインを互いに結合するエッジ接続を提供する。本明細書で説明されるように、相互接続性を高めるために、ドメイン3102、3104、および3106のエッジにおいて任意の数のサービスを提供することができる。例えば、パブリックドメイン3102とプライベートドメイン3104との間の相互接続は、とりわけ、ドメインアクセスに対するマイクロペイメント、ドメインアクセスに対する明示的な許可および追跡、ならびにパブリックトラフィックとプライベートトラフィックとの分離の機会を提供することができる。同様に、パブリックドメイン3102とパブリック-プライベートドメイン3106との間の相互接続は、とりわけ、時間ベースのリース、リソースマーケットプレイス、および分散型アイデンティティサーバなどのサービスの機会を提供することができる。プライベートドメイン3104とパブリック-プライベートドメイン3106との間の相互接続は、とりわけ、インラインサービス相互接続、挙動ベースの脅威分析、およびプルーフオブプロヴェナンスの機会を提供することができる。
図32は、一部の実施形態による、有線ネットワーク3202ならびに無線ネットワーク3204および3206の異種ネットワーク3200にわたる相互運用性の概略図である。無線ネットワーク3204および3206は、有線ネットワーク3202内のデバイスによって通信可能に結合され得る。これは、無線ネットワーク3204および3206内のデバイス間の通信における効率改善、ならびに無線ネットワーク3204または3206内のデバイスと有線ネットワーク3202内のデバイスとの間の通信における改善の機会を提供する。例えば、第1の無線ネットワーク3204を有線ネットワーク3202に結合するエッジデバイス3208は、ペイロードのサイズを縮小するためにデータから情報への変換を提供することができる。さらに、エッジデバイス3208は、未許可のパケットが転送されるのを阻止しながら、第1の無線ネットワーク3204からのパケットが通過することを可能にする許可システムを有し得る。許可システムは、情報が有線ネットワーク3202にわたって移動することを可能にするためにマイクロペイメントを行うシステムを含み得る。一例として、第1の無線ネットワーク3204は、農業用地の地面の水分量センサアレイであり得る。報告頻度は、変化率に応じる場合があり、その場合、最も高い報告頻度に一致するように帯域幅を購入する必要があるため、コストが増加する可能性がある。従って、マイクロペイメントシステムは、トランザクションが必要に応じて支払われることを可能にすることによってコストを下げることができる。
図33は、一部の実施形態による、クラウドA 3302をクラウドB 3304と接続するなど、2つの異なるフォグエンティティまたはクラウドエンティティを接続するインライン経路指定システム3300の概略図である。インライン経路指定は、IoTデバイス3306を複数の送信元と宛先との間のコンジットとして使用することができ、コンジットでは、インラインルータとして動作するIoTデバイス3306の結合動作は、現在ゲートウェイと呼ばれ得るものを形成する。
ネットワーク内の接続されたIoTデバイス3306間のインライン経路指定は、ネットワークスタックのレイヤ3およびレイヤ4で接続するスタックポップ技法を使用して実行され得る。この技法は、インラインレイテンシを減らし、アプリケーション固有トラフィック管理の必要性を減らすことができる。この技法は、MCUクラスのデバイスなどの様々なデバイス用のボードサポートパッケージ(BSP)に直接組み込むことができる。
アプリケーションとインターフェースをとり、IoTデバイス3306間の通信のためにネットワークスタックを管理するためのアプリケーション/サービスマネージャ3308などの、経路指定機能を実行するためのサブシステムをIoTデバイス3306に含めることができる。支払い/クレジットマネージャ3310は、とりわけ、他のネットワークへのトランザクションアクセスのためのマイクロペイメントを処理することができる。例えば、支払い/クレジットマネージャ3310は、ネットワークを介した情報転送、または地域の天気情報、交通流パターンなどのような情報へのアクセスを可能にするためにシステムに支払いをすることができる。通行権システム3312は、トラフィックが特定のIoTデバイス3306を通って流れることを可能にするためにアクセス権を提供するために使用されるネットワーク層を制御することができる。
ネットワークスタック3314は、通信スタックの異なる層を提供するように構成される。本明細書で説明される機能を実施するために追加の層を設けることができる。例えば、通行権システム3312は、本明細書で説明するように、通行権層を制御することができる。タイミングサブシステム3316は、通信にタイミング機能を追加するために使用され得る。例えば、通行権層を通じた通信は、特定のクレデンシャルセットについて限られた時間窓の間に許可され得る。期限が切れると、通信を再開するために新しいクレデンシャル、または追加の支払いが必要になる場合がある。システムは、デバイスに電力を供給するための電力サブシステム3318を含み得る。
図34は、一部の実施形態による、IoTデバイス3306による黙示的パススルー経路指定を示すインライン経路指定の概略図3400である。同様の番号が付けられた項目は、図33に関して説明したとおりである。IoTデバイス3306は、2つのドメイン間のエッジデバイスとして動作することができ、例えば、異なるプロトコル間の通信を変換し得る。
第1のエンティティ3402は、例えば、第1のプロトコル3404を使用して、IoTデバイス3306と通信することができる。この例では、IoTデバイス3306は、トラフィックを制限しないが、さらなる許可なしにそれを通過させる。IoTデバイス3306は、パケットを第2のエンティティ3408で送信するときに、パケットを第2のプロトコル3406に変換することができる。
図35は、一部の実施形態による、IoTデバイス3306による明示的な許可された経路指定の概略図である。同様の番号が付けられた項目は、図33および図34に関して説明したとおりである。この手法は、パススルーが黙示的に行われるシステムにおける潜在的なセキュリティ上の欠陥に対処する。図34に関して説明したように、IoTデバイス3306は、例えば通信を変換するための、2つのドメイン間のエッジデバイスとして動作することができる。
第1のエンティティ3402は、例えば、第1のプロトコル3404を使用して、IoTデバイス3306と通信する。この例では、IoTデバイス3306は、トラフィックを通過させる前に許可を判定するために、一方または両方のデバイスにチャレンジ3502を発行することができる。本明細書で使用される場合、許可されたパススルーは、鍵もしくはトークンのチャレンジ、期限付きの通行権、挙動もしくは評判に基づく許可、金銭的もしくは他の電子通貨交換、またはそれらの任意の組み合わせに基づいてインライン相互接続を通過する権利を主張する方法である。
例えば、IoTデバイス3306は、エンティティ3402または3408から識別鍵を受け入れ、そのデバイスが他のエンティティ3408または3402と通信することを認可されていることを確認するためにブロックチェーンにアクセスすることができる。IoTデバイス3306は、通信が1秒(s)、500ミリ秒(ms)、100ms以下などの所定時間継続することを可能にし得る。IoTデバイス3306は、通信を進めることを可能にするためにマイクロペイメントを必要とし得る。さらに、IoTデバイス3306は、パケットを第2のエンティティ3408に送信するときに、パケットを第2のプロトコル3406に変換することができる。
図36は、パススルーポリシー制御に使用されるインライン経路指定のための通行権層3602、3604、および3606の概略図である。同様の番号が付けられた項目は、図33および図34に関して説明したとおりである。本明細書で使用される場合、通行権という用語は、ノードを所有せずにノードを通して情報を中継するための非所有権を表す。このプロセスは、例えばアプリケーション層の下にある通行権層において、中間ノードがパケットのイングレス、エグレス、または内容を知ることなく、それらのリソースの使用に同意する複数のノードにわたる通信のためのコンジットを提供する。
通行権層3602、3604、または3606は、それぞれ経路指定層3608、3610、または3612の上のネットワークスタックの一部を含むことができる。第1のエンティティ3402内のアプリケーション3614は、第2のエンティティ3404内のアプリケーション3616にパケットを送信することができる。パケットは、第1のエンティティ3402内の通行権層3608を通過し、そこで、例えばIoTデバイス3306内の第2の通行権層3604によって転送される適切な情報と共にパッケージ化される。
例えば、アイデンティティ、認可、支払い、または時間に基づいて、パケットを転送する許可が、メモリ内で動作するコードブロックなどの通行権システムによって確認されると、パケット転送は、IoTデバイス3306内のネットワークスタックにおける通行権層3604を介して行われ得る。パケットのプロトコルは、通行権層3604において第2のプロトコル3406に変換されてもよい。よって、パケットは、IoTデバイス3306内のアプリケーション層3618の下で処理され、それは、その内容、またはパケットが通過したことさえ知らない。
次いで、パケットは、第2のエンティティ3408に渡される。第2のエンティティ3408内の通行権層3606では、通行権情報がパケットから除去され、パケットは、アプリケーションによる消費のためにアプリケーション層3616に送信される。同様のプロセスが、第2のエンティティ3408から第1のエンティティ3402に送信されたパケットに対して反対方向に機能する。
概略図3600は、単一の中間エンティティ、すなわちIoTデバイス3306を示す。しかしながら、図33に示されるように、第1のエンティティ3402から第2のエンティティ3408へパケットを転送するために複数の中間エンティティが使用されてもよい。
図37は、一部の実施形態による、許可に基づく明示的パススルー経路指定のための例示的な方法3700を示すラダー図である。図37の方法3700は、図39に関して説明されるIoTデバイス3900によって実施することができる。同様の番号が付けられた項目は、図33に関して説明したとおりである。この場合、許可はマイクロペイメントに対する電子クレジットに基づいているが、同様の許可は、鍵、ユニット識別情報、評判の鍵などに基づいていてもよい。
方法3700では、通行権システム3312が、パケットが通行権を通じて渡され得るか否かを判定するために、経路指定要求3702をデバイスレジストラ3704に送信することができる。デバイスレジストラ3704、すなわちエスクローエージェントは、明示的パススルーノードとして動作するノード内に存在するか、ノードのグループに対する共通のエージェントとして外部に存在するか、のいずれかであり得る。経路指定要求3702は、パススルー要求が許可されるべきか拒否されるべきかを判定するために、デバイスレジストラ3704によって使用され得る要求者に関連する識別情報または鍵を含む。
支払いベースの例では、要求者の支払い能力も判定される。これは、例えば、デバイスレジストラ3704によって、ブロックチェーン内のデバイスの識別情報または鍵をルックアップすること3706によって実行され得る。トークンクレジットチェック3708は、トランザクションに対して支払うために十分なクレジットが存在するか否かを判定するために、ブロックチェーン内のトランザクションに対して実行され得る。トークンクレジットチェック3708は、パススルー要求に埋め込まれたトークン、またはブロックチェーンに記録されたクレジットの量に基づいてもよい。
次いで、許可または拒否の決定3710は、クレジット、識別情報、鍵、または任意の組み合わせに基づいて行われ得る。次いで、応答3712が、許可または拒否の決定3710の結果を通知するために、通行権システム3312に送信され得る。決定がパケットの通過を拒否することであった場合、通行権システム3312は、とりわけ、さらなる動作なしにパケットを削除してもよいし、アクセスの拒否を送信者に通知してもよい。
許可または拒否の決定3710がパケットを通過させることである場合、通行権システム3312は、パケット3714をターゲットデバイスに向けて経路指定することができる。許可の判定、例えば、マイクロペイメントは、IoTデバイス3306のうちの1つまたは複数を通過して、または異なるドメインを結合しているルータなどのエッジデバイスのみを通過して、行われてもよい。パケットが経路指定されると、通行権システム3312は、経路指定が完了したという通知3716をデバイスレジストラ3704に送信することができる。次いで、デバイスレジストラ3704は、マイクロペイメント3718を解放し、支払い3720を通行権システム3312に送信することができる。ブロックチェーン記録が使用される場合、デバイスレジストラ3704は、ブロックに支払いを記録し、そのブロックをブロックチェーンにコミットして、残りのクレジットの量の変更を記録することができる。
図38は、一部の実施形態による、明示的パススルーのための時間制限リース手法のための例示的な方法3800のラダー図である。図38の方法3800は、図39に関して説明されるIoTデバイス3900によって実施することができる。同様の番号が付けられた項目は、図33および図37に関して説明したとおりである。この例では、段階3802において、デバイスレジストラ3704は、要求者に関連付けられた識別情報または鍵と要求されたパススルー期間とを含むパススルー要求を受信する。クレデンシャルおよびパススルー期間は、要求が許可されるべきか拒否されるべきかを判定するためにレジストラによって使用され得る。これは、例えば、ブロックチェーンにおいて、デバイスの識別情報、鍵、および許可された通信期間をデバイスレジストラ3704にルックアップさせること3804によって実行され得る。
段階3806において、通信に許可された期間が判定される。要求されたパススルー期間をサポートすることができない場合(3808)、最大許容パススルー期間が応答3810で指定される。パケットが経路指定される3812と、通行権システム3312は、経路指定が完了したという通知3814をデバイスレジストラ3704に送信することができる。次いで、デバイスレジストラ3704は、リース期間が満了したか否かを判定することができる3816。満了している場合、段階3818において、デバイスレジストラ3704はリースを無効化し、段階3820において、デバイスレジストラ3704は、リース期間の満了を通知するために通知3820を通行権システム3312に送信する。
図39は、一部の実施形態による、提携グループを作成するための、IoTデバイス3900に存在し得るコンポーネントの一例のブロック図である。同様の番号が付けられた項目は、図3、図8、図33、および図38に関して説明したとおりである。図8に関して説明したIoTデバイス800、および本明細書で説明される他のIoTデバイスに対して選択されたものとは異なるコンポーネントが、IoTデバイス3900に対して選択され使用されてもよいことに留意されたい。
大容量ストレージ808は、本明細書で説明される提携グループ形成を実施するための複数のモジュールを含むことができる。大容量ストレージ808においてコードブロックとして示されているが、モジュールのうちのいずれも、例えば特定用途向け集積回路(ASIC)に組み込まれるなど、ハードワイヤード回路で完全にまたは部分的に置き換えられ得ることが理解されよう。
大容量ストレージ808は、他のメッシュデバイス812、クラウド302内のデバイスなどにパケットを通信するためのオペレーティングシステムおよびプログラミングインターフェースなどのアプリケーション動作環境を提供することができるアプリケーション/サービスマネージャ3308を含むことができる。支払い/クレジットマネージャ3310は、図33に関して説明したように、通信のためのマイクロペイメントを処理することができる。通行権システム3312は、図37および図38に関して説明したように、パケット転送のためのアクセス権を提供するために、通行権レイヤを制御することができる。ネットワークスタック3314は、パケットをパッケージ化し転送するためのネットワーク層を提供することができる。ネットワークスタック3314は、例えば、図36に関して説明したように、通行権を含むことができる。タイミングシステム3316は、例えばリースが期限切れになる前の時間をカウントダウンするなど、通信のためのタイミング機能を追加するために含まれ得る。ブロックチェーンロジック3902は、とりわけ、通信許可、支払い、またはクレジットのブロックチェーンにアクセスしてそれを維持するために含まれ得る。
図40は、通行権を介してデバイス間で通信を転送するようにプロセッサ902に指示するためのコードを含む、非一時的機械可読媒体4000のブロック図である。プロセッサ902は、バス904を介して非一時的機械可読媒体4000にアクセスすることができる。プロセッサ902およびバス904は、図9に関して説明したプロセッサ902およびバス904と同様の方法で実施することができる。非一時的機械可読媒体4000は、図8の大容量ストレージ808について説明したデバイスを含むこともできるし、光ディスク、USBメモリ(thumb drive)、または任意の数の他のハードウェアデバイスを含むこともできる。
非一時的機械可読媒体4000は、通信が許可されているか否かを判定するために経路指定要求をデバイスレジストラに送信するようにプロセッサ902に指示するためのコード4002を含み得る。コード4004は、評判、許可、マイクロペイメントなどに基づいてデバイス間でパケットを経路指定するようにプロセッサ902に指示するために含まれ得る。コード4004は、例えば新しいドメインに入るときに、パケットを新しいプロトコルに変換するようにプロセッサ902に指示することができる。
コード4006は、メッセージを形成するパケットのグループなどの通信が転送されたことを通知するために完了通知をデバイスレジストラに送信するようにプロセッサ902に指示するために含まれ得る。コード4008は、例えば、転送の完了までデバイスレジストラによってエスクローに保留されている、通信のためにデバイスレジストラからの支払いを受け入れるようにプロセッサ902に指示するために含まれ得る。
IoTデバイス3306(図33)は、デバイスレジストラとして動作することができるため、コード4010は、例えば許可およびアイデンティティを判定するためにブロックチェーンにアクセスすることによって、要求者をルックアップするようにプロセッサ902に指示するために含まれ得る。コード4012は、クレジットまたは支払いが通信に対して十分であるか否かを判定するためにクレジットまたは支払いをチェックするようにプロセッサ902に指示するために含まれ得る。コード4012は、許容された通信時間を計算するようにプロセッサ902に指示することができる。コード4014は、許可決定を通行権システム3312に送信し、通行権システム3312がパケットまたは通信を転送または削除することを許可するようにプロセッサ902に指示するために含まれ得る。コード4016は、例えば、最後に完了した通信が許可されたリース時間を超えた場合に、時間ベースのリースを無効化するようにプロセッサ902に指示するために含まれ得る。コード4016は、リースを無効化するメッセージを通行権システム3312に送信するようにプロセッサ902に指示することができる。
フレームが通過するデバイスを追跡することは、通信が送信元デバイスからターゲットデバイスへ異なるドメインを通過するときにセキュリティレベルを強化することができる。これは、とりわけ、中間者攻撃などの、送信元デバイスを模倣する攻撃を防ぐのに役立つ。中間者攻撃では、デバイスは、別のデバイス宛ての通信を傍受し、その通信を変更してセキュリティを危険な状態にする。
図41は、一部の実施形態による、ネットワーク内のデバイスを介してプルーフオブプロヴェナンス(proof-of-provenance)(PoP)情報を運ぶためのフレーム構造の使用の概略図である。デバイスは、IoTデバイス、インターネットデバイス、エッジデバイス、またはそれらの任意の組み合わせを含み得る。プルーフオブプロヴェナンスは、マルチリンク接続チェーンを通じてネットワークトラフィックのトレーサビリティを提供する。PoPの方法は、トラフィック監査証跡を作成し、そして本明細書で説明されるように、中間者攻撃を識別しブロックするために使用され得る。PoPは、例えばパケット4106を送信することによって、エンティティ1 4102が別のエンティティ4 4104との通信を開始するときに使用され得る。パケット4106は、パケット4106が通過したデバイスを識別するための複数のプレースホルダ4108を含み得る。
この例では、パケット4106は、第1のメッセージ4112において、第1のデバイスA 4110、またはルータに送信され得る。デバイスA 4110は、例えば、トランジットコードPoP1 4116をプレースホルダ4108に書き込むこと(4114)によって、パケットがデバイスA 4110を通過したことを示すようにパケット4106を変更することができる。通過コードの生成は、図42に関してさらに説明される。
次いで、パケット4106は、第2のメッセージ4120において別のデバイス、すなわちエンティティ2 4118に渡され得る。第2のメッセージ4120は、例えばデバイスA 4110において第2のプロトコルに変換されていて、第1のメッセージ4112とは異なるプロトコルであり得る。エンティティ2 4118は、パケットを第3のメッセージ4124において別のデバイスB 4122に渡すことができ、またパケットを新しいプロトコルに変換することもできる。
デバイスB 4122は、例えば、第2のトランジットコードPoP 2 4128をプレースホルダ4108に書き込むこと(4126)によって、パケット4106がデバイスB 4122を通過したことを示すようにパケット4106を変更することができる。次いで、デバイスB 4122は、そのパケットを別のメッセージ4132において、別のデバイス、すなわちエンティティ3 4130に渡すことができる。この例では、エンティティ3 4130は、メッセージ4136においてパケットをデバイスC 4134に送信する前に、パケット4106を最初のプロトコルに変換して戻すことができる。
デバイスC 4134は、例えば、第3のトランジットコードPoP3 4140をプレースホルダ4108に書き込むことによって(4138)、パケット4106がデバイスC 4122を通過したことを示すようにパケット4106を変更することができる。次いで、デバイスC 4134は、そのパケットを別のメッセージ4142において、別のデバイス、すなわちエンティティ4 4140に渡すことができる。デバイスC 4134は、パケットをエンティティ4 4140に送信する前に、パケット4106を別のプロトコルに変換してもしなくてもよい。
チェーン内の各ノードは、チェーン内の前のノードおよび次のノードに関する知識のみを有し得る。よって、パケット4106内のPoPシーケンスは、パケット4106が通過したデバイスの証跡を提供する。一部の例では、プレースホルダ4108は、PoPコードがパケット4106に挿入された、または付加された状態で、明示的には使用されない。
図42は、一部の実施形態による、PoP通貨コードまたは鍵を作成するために使用され得る手続きの概略図4200である。発信パケット4204の場合、PoPシーケンス4206は、シードバイトシーケンスに対して変換を実行することによって生成され得る。シードバイトシーケンスは、デバイスIDに基づく乱数発生器によって、または他の任意の数の技法によって生成され得る。変換プロセスは、排他的OR演算(XOR)、または他の2進計算の方法を必然的に伴い得る。
チェーン内のノードは、PoPシーケンスを受信し、それをイングレス鍵4208として扱う。次いで、ノードは、入来するイングレスシーケンスを使用して変換4210を実行して、自身のPoPシーケンス4212を生成する。例えば、排他的OR関数4216を使用してイングレス鍵4208をデバイス鍵4214と組み合わせてPoPシーケンス4212を生成することができる。デバイス鍵4214は、デバイスに格納されている製造業者の鍵、デバイスID、デバイスIDに基づいて生成された乱数などであり得る。次いで、PoPシーケンス4212をPoP鍵4218としてパケット4204に追加することができる。PoPの次のステージで使用されるエグレス鍵4220として同じシーケンスを追加して次のPoP鍵を生成することができる。一部の例では、エグレス鍵4220を省いてもよく、PoP鍵4218自体を次のステージに使用してもよい。PoP変換が前のステージで実行されなかったことを示すために、ヌルシーケンスまたは他の標準的なシーケンスフォーマットを使用することができる。
図43は、PoP鍵を生成するための例示的な方法4300のプロセスフロー図である。図43の方法4300は、図45に関して説明されるIoTデバイス4500によって実施することができる。ブロック4302は、例えば、あるデバイスが別のデバイスから第3のデバイスへの送信を意図したパケットを受信したときを表す。ブロック4304において、例えば、最後のPoPステージによって生成されたPoP鍵を読み取ることによって、イングレス鍵が取得される。ブロック4306において、別のPoP鍵が、例えば、ノードによって使用される秘密鍵または共通鍵などの、前のPoP鍵およびデバイス鍵のXOR関数を使用して計算される。
ブロック4308において、新たに生成されたPoP鍵がパケットに付加され、以前に生成されたPoP鍵はそのまま残される。ブロック4310において、パケットは、次のデバイスに経路指定される。ブロック4312において、パケットが宛先に到達したか否かに関する判定が行われる。到達していない場合、プロセスフローはブロック4302に戻り、次のノードでプロセスを続行する。パケットが宛先に到達した場合、方法4300は終了する。すべてのデバイスがパケットにPoP鍵を挿入または付加する必要があるわけではないことに留意されたい。図41に関して説明したエンティティ3 4130などの一部のデバイスは、PoP鍵をパケットに入れることなくパケットを渡すことができる。これらのデバイスは、単一ドメイン内の一般的なルータや他のデバイスであり得る。
図44は、一部の実施形態による、パケット内のPoP鍵を検証するための例示的な方法4400のプロセスフロー図である。パケットが完全なチェーンを通過した場合、連続したPoPチェーンの最後にある宛先ノードは、有効なPoP鍵シーケンスを受信する。チェーン内のノードからのデバイス鍵は、データベース、ブロックチェーン、または他のメカニズムを介して、宛先ノードまたは他の確認エンティティに利用可能にされ得る。デバイス鍵は、すべてのノードのイングレス鍵およびPoP鍵の知識がある場合に、シーケンス変換プロセスを使用して全チェーンを検証するために使用され得る。このプロセスは、反復検証計算の結果、報告されたPoPシーケンスと一致しないPoP値が発生したときに、PoPチェーンの中断が発生したか否か、またその発生場所を判定するために使用され得る。
ブロック4402は、例えば、確認デバイスがパケットを受信したときを表す。ブロック4404において、検証されるパケットからPoP鍵の連結リストが抽出される。ブロック4406において、PoP鍵は、ストリングを個々のトークン/鍵に分割するためにトークン化され得る。ブロック4408において、現在のPoP鍵が検証され得る。ブロック4410において、現在のPoP鍵は、XORプロセスを用いて共通秘密鍵と結合され得る。ブロック4412において、XORの結果は、経路内の次のノードのイングレス鍵である次のトークンと比較され得る。XORの結果と次のイングレス鍵とが一致しない場合、プロセスフローはブロック4416に進んで、障害状態を報告することができる。
ブロック4412で一致がある場合、ブロック4414において、PoPシーケンス内のすべての鍵がテストされたか否かに関する判定が行われる。テストされていない場合、プロセスフローは、ブロック4408に戻り、次の鍵をテストする。すべての鍵がテストされている場合、ブロック4416において、成功した結果が報告される。
図45は、一部の実施形態による、パケット内のプルーフオブプロヴェナンスを追跡するための、IoTデバイス4500に存在し得るコンポーネントの一例のブロック図である。同様の番号が付けられた項目は、図3および図8に関して説明したとおりである。図8に関して説明したIoTデバイス800、および本明細書で説明される他のIoTデバイスに対して選択されたものとは異なるコンポーネントが、IoTデバイス4500に対して選択され使用されてもよいことに留意されたい。
大容量ストレージ808は、本明細書で説明される提携グループ形成を実施するための複数のモジュールを含むことができる。大容量ストレージ808においてコードブロックとして示されているが、モジュールのうちのいずれも、例えば特定用途向け集積回路(ASIC)に組み込まれるなど、ハードワイヤード回路で完全にまたは部分的に置き換えられ得ることが理解されよう。
大容量ストレージ808は、メッシュデバイス812またはクラウド302内のデバイスからのパケットを受け入れ、そのパケットを他のメッシュデバイス812、クラウド302内のデバイスなどに中継する通信部4502を含み得る。通信部4502は、プロトコル間でのパケットの変換、マイクロペイメントの受け入れなどの他の機能を実行することができる。さらに、通信部4502は、図33を参照して説明した通行権システム3312の一部とすることができる。
イングレス鍵計算部4504は、イングレス鍵を判定するために使用され得る。パケットに付加されたPoP鍵がある場合、これが読み取られてイングレス鍵として識別され得る。イングレス鍵計算部4504がIoTデバイス4500がチェーン内の最初のデバイスであり得ることを示すヌル文字または他の文字を見出した場合、IoTデバイスは、イングレス鍵を計算するために乱数発生器を使用することができる。これはデバイス鍵4506または他のシードに基づき得る。デバイス鍵4506は、製造業者からの格納された値であってもよいし、とりわけ、図20に関して説明されるように、グループ内でセキュアに通信するために生成され、IoTデバイス4500に割り当てられた鍵であってもよい。
PoP鍵計算部4508は、デバイス鍵4506およびイングレス鍵からPoP鍵またはエグレス鍵を計算するために使用され得る。これは、図42に関して説明したように実行され得る。
パケット構築部4510は、例えば、異なるプロトコルへの変換が実行されたときに、新しいパケットを構築するために使用され得る。パケット構築部は、パケットの末尾に、あらゆる他の鍵の後に、現在のノードのPoP鍵を付加することができる。さらに、パケット構築部4510は、図36を参照して説明したように、他のデバイスの通行権層によってパケットを送信するために使用される任意の通行権情報を追加する通行権層の一部であり得る。
PoPシーケンス検証部4512は、図44に関して説明したように、PoPシーケンスを分析するために含まれ得る。PoPシーケンス検証部は、パケット内のPoP鍵がデバイスのチェーンを介して許可された経路をたどり、パケットが不正なデバイスを通過していないことを判定することができる。これにより、中間者攻撃から保護され得る。
図46は、通行権を介してデバイス間で通信を転送するようにプロセッサ902に指示するためのコードを含む、非一時的機械可読媒体4600のブロック図である。プロセッサ902は、バス904を介して非一時的機械可読媒体4600にアクセスすることができる。プロセッサ902およびバス904は、図9に関して説明したプロセッサ902およびバス904と同様の方法で実施することができる。非一時的機械可読媒体4600は、図8の大容量ストレージ808について説明したデバイスを含むこともできるし、光ディスク、USBメモリ(thumb drive)、または任意の数の他のハードウェアデバイスを含むこともできる。
非一時的機械可読媒体4600は、例えば付加されたPoP鍵を検出することによって、イングレス鍵を判定するために受信されたパケットを読み取るようにプロセッサ902に指示するためのコード4602を含み得る。コード4604は、他の鍵を生成するためのデバイス鍵を生成するか、他の方法で提供するようにプロセッサ902に指示するために含まれ得る。デバイス鍵は、デバイスに格納されている製造業者の鍵であってもよいし、とりわけ、ブロックチェーンからアクセスされるデバイス固有の通信鍵であってもよい。
コード4606は、例えばイングレス鍵およびデバイス鍵から、新しいPoP鍵を計算するようにプロセッサ902に指示するために含まれ得る。コード4608は、新しいPoP鍵をパケットの末尾に付加するようにプロセッサ902に指示するために含まれ得る。コード4610は、パケットを次のデバイスに送信するようにプロセッサ902に指示するために含まれ得る。
コード4612は、パケットが正当なデバイスを通過したことを確認するために、パケットに付加されたPoP鍵のシーケンスを検証するようにプロセッサ902に指示するために含まれ得る。コード4614は、検証手続きの結果について報告するように、例えば、パケットの危殆化を別のデバイスまたはデバイスのグループに報告するようにプロセッサ902に指示するために含まれ得る。ユーザはまた、違法なパケットについて警告されてもよい。
図47は、トークンバケット4704にマイクロペイメント情報を含むパケット4702の一例の概略図4700である。トークンバケット4704は、マイクロペイメントのためにトークンを符号化するビットシーケンスを含むパケットの領域である。トークンバケット4704を使用することにより、パケットが、共通データベースまたはブロックチェーンへのアクセスを持たないシステムを介して通過の代金を支払うことができる。トークンバケット4704は、1つまたは複数の送信デバイスによってデクリメントされ得る暗号化された残高を有し得る。一部の例では、トークンバケット内のトークンは、第1の鍵で暗号化された1つまたは複数のシーケンスとすることができ、エッジデバイス4706~4710のうちの1つまたは複数は、トークンファイルを復号しシーケンスまたはトークンを除去する鍵を有し得る。
パケット4702がエッジデバイス4706で受信されると、トークンバケット4704はアクセスされ(4712)、トークンバケット4704に残された残高を判定するために復号される。エッジデバイス4706を通過するコストが差し引かれ、トークンバケットが再暗号化されアクセスされて(4712)、フレームに保存される。パケットが他のエッジデバイス4708および4710を通過するときに、これらの段階が繰り返される。別の例では、トークンバケット4704は、複数の同一の暗号化ビットシーケンスを含む。各シーケンスはトークンを表し、トークンはエッジデバイス4706~4710を通過するときに除去される。トークンバケット4704が空であるか、または残高が不十分である場合、パケットは削除され得る、または送信者に返され得る。
トークンバケット4704は、メッセージを送信するための優先度の向上を可能にし得る。コストは、所与のパケットの優先度に直接関係し得る。さらに、トークン自体がこの情報を運んでもよい。例えば、トークンが第1の残高を有する場合、エッジデバイス4706~4710は、通常の先入れ先出しシーケンスに従ってパケットを転送することができる。しかしながら、トークンがより高い残高を有する場合、エッジデバイス4706~4710は、待ち行列内の他のパケットの前にパケットを送信することができる。これは、IoTデバイスからの通信に優先順位を付けるために使用でき、例えば、通常のデータメッセージを低い優先度で送信しながら、警報を高い優先度で送信できる。
図48は、一部の実施形態による、マイクロペイメントを送信システムに渡すためにトークンバケットを使用するための例示的な方法4800のプロセスフロー図である。図48の方法4800は、図49に関して説明されるIoTデバイス4900によって実施することができる。ブロック4802は、例えば送信システムがパケットを受信したときを表す。ブロック4804において、例えばトークンバケットを見つけるために、パケットフレームメタデータが解析される。ブロック4806で解析されたメタデータが正しくないと判定された場合、例えば、失敗した経路指定報告を送信することによって、送信者に警告4808が行われる。ブロック4810において、続行するか否かについての判定がなされる。続行する場合、プロセスフローはブロック4802に戻る。
ブロック4812において、送信を完了するための支払いが計算される。これは、ペイロードサイズに、経路指定されたバイト当たりの料金を単純に乗算することによって実行されてもよい。一部の例では、優先度による経路指定は、より高いバイト当たりのレートで課金され得る。
ブロック4814において、経路指定に対する支払いがトークンバケットから抽出される。これは、トークンフィールドをデクリメントすることによって実行され得る。ローカル支払い小計をインクリメントすることもできる。ローカル支払い小計は、例えばデータベース内の支払いストアを更新するために使用され得る。支払いストアは、支払い記録を含むブロックチェーンであり得る。
ブロック4816において、新しいトークンフィールドを使用して、発信フレームのメタデータを完成させることができる。ブロック4818において、次いで、パケットは送信機から経路指定される。ブロック4820において、続行するか否かに関する判定が行われる。これは、とりわけ、通信のシーケンスが進行中であるか否かなどに基づき得る。進行中である場合、プロセスフローはブロック4802に戻って続行する。
図49は、一部の実施形態による、支払いを容易にするためにトークンバケットを使用するための、IoTデバイス4900に存在し得るコンポーネントの一例のブロック図である。同様の番号が付けられた項目は、図3および図8に関して説明したとおりである。図8に関して説明したIoTデバイス800、および本明細書で説明される他のIoTデバイスに対して選択されたものとは異なるコンポーネントが、IoTデバイス4900に対して選択され使用されてもよいことに留意されたい。
大容量ストレージ808は、本明細書で説明される提携グループ形成を実施するための複数のモジュールを含むことができる。大容量ストレージ808においてコードブロックとして示されているが、モジュールのうちのいずれも、例えば特定用途向け集積回路(ASIC)に組み込まれるなど、ハードワイヤード回路で完全にまたは部分的に置き換えられ得ることが理解されよう。
大容量ストレージ808は、メッシュデバイス812またはクラウド302内のデバイスからパケットを受け入れ、そのパケットを他のメッシュデバイス812、クラウド302内のデバイスなどに中継する通信部4902を含み得る。1つまたは複数のパケットがデバイス間の通信を構成してもよい。図49に関して説明した機能に加えて、4502に関して説明したように、通信部4902は、プロトコル間でのパケットの変換、プルーフオブプロヴェナンス追加の実行などの他の機能を実行することができる。さらに、通信部4902は、図33を参照して説明した通行権システム3312の一部とすることができる。
データ解析部4904は、トークンバケットを識別するために受信パケットについてメタデータを解析することができる。これは、例えば、IoTデバイス4900によって保存された公開鍵または秘密鍵を使用して、トークンバケットを復号することを含み得る。支払い計算部4906は、通信を送信するのに必要な支払いを計算するために使用され得る。計算は、例えば、より高い帯域幅のチャネルが選択された場合に支払いに乗数を掛けることなど、特定の優先度レベルを考慮する乗数を含むことができる。支払い抽出部4908は、トークンバケットから支払いを差し引くことができる。これは、トークンバケットに記録された残高から金額を差し引くことによって実行され得る。一部の例では、トークンバケットは、個別に除去することができる暗号化トークンなどの複数の個別トークンを含むことができる。フレーム構築部4910は、例えば、トークンバケットを暗号化し、パケットペイロードとメタデータとをアセンブルしてフレームを形成することによって、フレームをメタデータで再構築することができる。次いで、通信部4902は、アセンブルされたパケットを送信するために使用され得る。一部の例では、支払い受け入れ部4912は、別の送信元、例えばトークンバケット内のビットシーケンスによって識別されるブロックチェーンからの支払いを受け付けるために使用され得る。
図50は、トークンバケットからの支払いに基づいてデバイス間で通信を転送するようにプロセッサ902に指示するためのコードを含む、非一時的機械可読媒体5000のブロック図である。プロセッサ902は、バス904を介して非一時的機械可読媒体5000にアクセスすることができる。プロセッサ902およびバス904は、図9に関して説明したプロセッサ902およびバス904と同様の方法で実施することができる。非一時的機械可読媒体5000は、図8の大容量ストレージ808について説明したデバイスを含むこともできるし、光ディスク、USBメモリ(thumb drive)、または任意の数の他のハードウェアデバイスを含むこともできる。
非一時的機械可読媒体5000は、例えばメタデータからトークンバケットを抽出するために、フレームについてメタデータを解析するようにプロセッサ902に指示するためのコード5002を含み得る。コード5004は、メッセージを送信するための支払いを計算するようにプロセッサ902に指示するために含まれ得る。支払いは、例えば、メッセージのサイズおよび/またはメッセージ送信の優先度に基づいてもよい。コード5006は、トークンバケットから支払いを抽出するようにプロセッサ902に指示するために含まれ得る。これは、トークンバケット内の残高を減らすことによって、またはトークンバケットからトークンに対応するビットシーケンスを除去することによって実行され得る。コード5008は、例えば、トークンバケットの変更された残高を含み、フレームを更新するようにプロセッサ902に指示するために含まれ得る。コード5008はまた、フレームを再アセンブルする前にトークンバケットを暗号化するようにプロセッサ902に指示することができる。コード5010は、例えば、最終的な宛先を示すアドレスを用いて後続のデバイスにフレームを送信することによって、フレームを宛先に向けて経路指定するようにプロセッサ902に指示するために含まれ得る。
コード5012は、トークンバケット内の残高を増やすために支払いを受け入れるようにプロセッサ902に指示するために含まれ得る。コード5014は、支払われた額に基づいて送信の優先度を上げるようにプロセッサ902に指示するために含まれ得る。例えば、トークンバケットがトークンのために離散ビットシーケンスを使用する場合、送信デバイスは、個々のトークンの量に少なくとも部分的に基づいて優先度を設定することができる。
図51は、一部の実施形態による、複数ステージでIPドメイン5102を非IPドメイン5104に接続する、異種ネットワーク(ヘットネット)インフラストラクチャ5100の図である。この例では、LPWAドメイン5106は、IEEE 802.15.4gメッシュネットワーク5108と通信している。メッシュネットワーク5108は、IEEE 802.15.4メッシュネットワーク5110と通信している。アクセスポイント5112は、通信接続5114(例えば、イーサネット(登録商標)接続)をコアネットワーク5116に提供する。コアネットワーク5116は、第2のアクセスポイント5118に結合され得る。第2のアクセスポイント5118は、第2のLPWAネットワーク5120に通信を提供し得る。IPドメイン5102と非IPドメイン5104との異なる順列は、相当数のサービスに対するサポートを提供することと相まって、専用の変換ノードに対して不利に作用する。さらに、動的相互接続は、ノードが、ネットワークに参加でき、ネットワークを離れることができ、そして移動可能であり得る揮発性のIoTインフラストラクチャと相互作用するのに有用であり得る。
例えば、プロトコルパッキングを使用することによって、異なるドメインからのデータを送信元からターゲットの宛先へ効率的に送信することができる。この例では、第1のプロトコル内のプロトコルフレームは、別のプロトコル内のパケットのペイロードフィールドにパッケージ化され得る。この手法を採用することによって、両方のプロトコルは規格に準拠したままである。図52に関してさらに説明されるように、LoRaWAN(登録商標)ネットワーク5106などのフォグデバイス内のセンサ5124からゲートウェイ5122で受信されたLoRaWAN(登録商標)フレームは、送信される前にIEEE 802.15.4フレームにパッケージ化され得る。第1のアクセスポイント5112においてさらなるプロトコルパッキングが実行されてもよい。例えば第2のアクセスポイント5118などのターゲットデバイスにおいて、パッケージングは除去され、フレームはターゲットデバイス5124に送信される。これは、異なるネットワークを介して、またはコアネットワーク5116を介してアクセスされるリモートデバイスを含むフォグデバイスにおける通信に使用され得る。
図52は、一部の実施形態による、あるプロトコルから別のプロトコルへフレームをパッケージ化するのに使用されるプロトコルパッキングの概略図5200である。概略図5200に示される例では、LoRaWAN(登録商標)フレーム5202がパケット5204のペイロードフィールドにパックされ、パケット5204は、IEEE 802.15.4のMACフレーム5206に含まれる。MACフレーム5206は、宛先に送信するための送信フレームを形成するヘッダ5208を有する。
この方法を使用して、任意の数の他のデータリンク層およびトランスポートカプセル化ターゲットをサポートできる。例えば、データオーバーケーブルサービスインターフェース仕様(Data Over Cable Service Interface Specification)(DOCSIS)プロトコルに従うフレームは、AX.25プロトコルのパケットにカプセル化され得る。DOCSISは、ケーブルアンド無線システムを介した高速データ転送に使用される。ブロードバンドインターネットやテレビサービスなどの高速データ転送に主に使用されている。AX.25は、1996年にTucson Amateur Packet Radio(TAPR)およびAmerican Radio Relay League(ARRL)の組織によって開発され、1998年に更新されている。AX.25はAX.25プロトコルから派生したデータリンク層プロトコルであり、主にアマチュア無線帯域における障害のある狭帯域無線ネットワークにおける使用のために設計された。
図53は、一部の実施形態による、IEEE 802.11(またはWi-Fi(登録商標))MAC層フレーム5304内でLoRaWAN(登録商標)フレーム5302をパッケージ化するために使用されるプロトコルパッキングの概略図5300である。概略図5300に示されるように、LoRaWAN(登録商標)フレーム5302は、IEEE 802.11のMACフレーム5304内にネットワークデータ5306として挿入され得る。IEEE 802.11のMACフレーム5304がLPWAネットワークにつながるゲートウェイなどの宛先に到達したとき、LoRaWAN(登録商標)フレーム5302は、IEEE 802.11のMACフレーム5304から読み取られ、宛先に送信され得る。
図54は、一部の実施形態による、フレームの送信のためのプロトコルパッキングのための例示的な方法5400のプロセスフロー図である。図54に関して説明される方法5400は、図55に関して説明されるIoTデバイス5500によって実装され得る。ブロック5402は、例えば、データを送信する準備ができたときを表す。
ブロック5404において、利用可能な送信元プロトコルおよび宛先プロトコルが識別される。利用可能なプロトコルのインベントリが作成され、ゲートウェイまたはアクセスポイントに格納され、そしてプロトコルパッケージングのためのイングレスプロトコルおよびエグレスプロトコルが識別される。各プロトコルに関連するペイロードのサイズおよび制約、例えばアドレス、フラグなどの必要なフレームフィールド情報が識別される。
ブロック5406において、ペイロードの制約は、送信されるペイロード、例えば送信元フレームに対してチェックされる。ブロック5408において、送信元フレームが宛先プロトコルペイロードに収まるか否かに関する判定が行われる。収まらない場合、ブロック5410において、ペイロードは複数のペイロードに断片化される。これは、例えば、ペイロードをNバイトのシーケンスに分割することによって実行され得る。各バイトシーケンスは別々の宛先プロトコルフレームに配置されてもよく、パケットシーケンスは番号付けされる。
ブロック5414において、ペイロードおよびデバイスメタデータが宛先フィールドに書き込まれる。ブロック5416において、フレームは宛先に向けてディスパッチされる。ブロック5418において、すべてのデータ断片が処理されたか否かに関する判定が行われる。処理されていない場合、プロセスフローはブロック5414に戻り、次の断片を書き込んで送信する。
ブロック5420において、さらにデータを送信する必要があるか否か、例えば別のイングレスフレームを受信したか否かについての判定が行われる。もしそうであれば、プロセスフローはブロック5404に戻り、次のフレームを処理する。そうでなければ、方法5400はブロック5422で終了し、その時点でデバイスは別のフレームが受信されるのを待つ。
図55は、一部の実施形態による、第1のプロトコルのフレームを異なるプロトコルのフレーム内にパッケージ化するための、IoTデバイス5500内に存在し得るコンポーネントの一例のブロック図である。同様の番号が付けられた項目は、図3および図8に関して説明したとおりである。図8に関して説明したIoTデバイス800、および本明細書で説明される他のIoTデバイスに対して選択されたものとは異なるコンポーネントが、IoTデバイス5500に対して選択され使用されてもよいことに留意されたい。
大容量ストレージ808は、本明細書で説明される提携グループ形成を実施するための複数のモジュールを含むことができる。大容量ストレージ808においてコードブロックとして示されているが、モジュールのうちのいずれも、例えば特定用途向け集積回路(ASIC)に組み込まれるなど、ハードワイヤード回路で完全にまたは部分的に置き換えられ得ることが理解されよう。
大容量ストレージ808は、メッシュデバイス812またはクラウド302内のデバイスからフレームを受け入れ、そのフレームを他のメッシュデバイス812、クラウド302内のデバイスなどに中継する通信部5502を含み得る。図55に関して説明した機能に加えて、4502に関して説明したように、通信部5502は、プロトコル間でのフレームの変換、プルーフオブプロヴェナンス追加の実行などの他の機能を実行することができる。さらに、通信部5502は、図33を参照して説明した通行権システム3312の一部とすることができる。
プロトコルライブラリ構築部5504は、どのプロトコルが利用可能であるかを判定し、それぞれについてプロトコルおよびフォーマットを格納するプロトコルライブラリ5506を構築することができる。フォーマットは、複数のエグレスフレームにおける送信のためにイングレスフレームを断片に分割することなど、フレームをどのようにフォーマットするかを判定するために使用することができる、データフィールド長などの制約を含むことができる。
フレーム分析部5508は、送信デバイスから受信したイングレスフレーム5510を分析して、長さ、パッケージングプロトコル、および他の制約を判定するために使用され得る。フレーム構築部5512は、判定された制約を使用してエグレスフレーム5514を構築することができる。例えば、フレーム構築部5512は、イングレスフレーム5510がエグレスフレーム5514のペイロードフィールド内に収まるには大きすぎる場合、複数のエグレスフレーム5514を構築することができる。1つまたは複数のエグレスフレーム5510が構築されると、通信部5502は、それらを宛先に向けて送信することができる。
図56は、第1のプロトコルのフレームを異なるプロトコルのフレームにパッケージ化するようにプロセッサ902に指示するためのコードを含む、例示的な非一時的機械可読媒体5600のブロック図である。プロセッサ902は、バス904を介して非一時的機械可読媒体5600にアクセスすることができる。プロセッサ902およびバス904は、図9に関して説明したプロセッサ902およびバス904と同様の方法で実施することができる。非一時的機械可読媒体5600は、図8の大容量ストレージ808について説明したデバイスを含むこともできるし、光ディスク、USBメモリ(thumb drive)、または任意の数の他のハードウェアデバイスを含むこともできる。
非一時的機械可読媒体5600は、可能なイングレスプロトコルおよびエグレスプロトコルのインベントリインベントリを作成するようにプロセッサ902に指示するためのコード5602を含み得る。コード5604は、サイズおよび他の制約を判定するためにイングレスフレームを分析するようにプロセッサ902に指示するために含まれ得る。コード5606は、エグレスフレームのためのプロトコルを判定するようにプロセッサ902に指示するために含まれ得る。コード5608は、イングレスフレームが大きすぎてエグレスフレームのペイロードフィールド内に収まることができない場合には、イングレスフレームを断片化するようにプロセッサ902に指示するために含まれ得る。コード5606は、宛先での正しい再アセンブルのために、各断片をシーケンス番号でラベル付けするようにプロセッサに指示することができる。コード5610は、例えば、イングレスフレーム、または関連するシーケンス番号を有するイングレスフレームの断片を、エグレスフレームのペイロードフィールドに配置することによって、エグレスフレームを書き込むようにプロセッサ902に指示するために含まれ得る。コード5612は、例えば、最終的な宛先を示すアドレスを用いて後続のデバイスにフレームを送信することによって、エグレスフレームを宛先に向けて経路指定するようにプロセッサ902に指示するために含まれ得る。
他のプロトコル内に異なるプロトコルのフレームをパッケージ化することに加えて、LoRaWAN(登録商標)などの低オーバーヘッド通信で複雑なデータ構造の使用が増加することは、より高度なフレーミングの有用性を示している。新しいフレーミング構造が図57に関して説明される。
図57は、一部の実施形態による、LoRaWAN(登録商標)フレームなどの低電力広域(LPWA)フレーム5702内のペイロードとして使用され得るペイロード構造5700の図である。ペイロード構造5700は、例えば、集約され、断片化され、インタリーブされ、または他の方法で構築され得る1つまたは複数の送信元からの情報を含む、マルチモーダルデータに使用され得る。これらの種類のマルチモーダルデータは、意図された宛先にディスパッチするために複数のLPWAフレーム5702を必要とするデータサイズにしばしばなり得る。
ペイロード構造5700仕様は、最小限のフレームオーバーヘッドを提供する。フレームオーバーヘッドは、表1に記載のとおりであり得る。
一部の態様では、ペイロード形式識別子は、とりわけ、画像、24ビットGPS報告、または3×2バイトセンサ報告など、ペイロード構造5700で運ばれるデータの種類を識別する。ペイロード形式識別子に使用され得る値の例を表2に提示する。これは4ビットフィールドであるため、15個の可能な識別子を使用できる。
一部の態様では、フレームオーバーヘッドは、ペイロードが暗号化されているか否かを示すための暗号化フラグ、例えば、暗号化されている場合はEncr=0x1、暗号化されていない場合はEncr=0x0を含み得る。デバイスIDは、送信デバイスに対する固有の識別子を表すストリング(例えば、4バイトのストリング)を含み得る。これは、本明細書で説明されるブロックチェーンの方法を使用して割り当てられた識別子であってもよいし、とりわけ、製造業者が割り当てた名前であってもよい。デバイスIDフィールドは、例えば、無線機ごとに任意の数のエンドポイントIDをサポートするために使用され得る。一部の例では、IDゼロが無効であると仮定して、無線機当たり最大65535のエンドポイントIDをサポートするために2バイトの識別子が使用され得る。
バッチサイズは、単一のメッセージに含まれるペイロードの数を示す。シーケンス番号は、再アセンブルのための、シーケンスにおける特定のペイロード構造5700の位置を示す。ペイロードフィールドの長さは、長さフィールドで運ばれる。LoRaフレームカプセル化は、アップリンクメッセージのためのメッセージ完全性チェック(MIC)を提供し得る。そうでなければ、上記のフレーム5702に別個のMICフィールドを含めることができる。
一部の態様では、より長いメッセージのためのペイロードは、複数のフレームにわたって断片化される必要があり得る。これらのフレームは、IoTネットワークにおいて順次送信される必要はないが、送信時間を短縮し送信効率を改善するために並列無線チャネルを介して送信されてもよい。ネットワーク分割多重化(NDM)と呼ばれるこの技法は、データを複数の独立した並列データサブセットに分割し、宛先で再結合する前に、それらを複数のネットワークパスで伝送するネットワークプロトコルに依存しない方法である。この技法は、例えば異なるプロトコルを使用して、相互接続された異なるネットワークパスおよびインフラストラクチャ上で並列に動作する複数のデータストリームをオーバーレイする能力を活用する。NDMは、複数のLPWAパスなどの複数の同一ネットワークパス、または複数のIEEE 802.15.4g経路と連携した複数のLPWAパスなど、複数の異なるネットワークインフラストラクチャパスをサポートする。
データストリームのアラインメント、およびNDMパスのうちの1つまたは複数に影響を及ぼす損失の多いネットワーク特性は、宛先における再結合に悪影響を及ぼす可能性がある。しかしながら、これらの問題は、http://www.rfc-editor.org/rfc/pdfrfc/rfc5050.txt.pdf(最後にアクセスしたのは2016年8月25日)で説明されているバンドルプロトコル(BP)などのフォールトトレラントプロトコルのためのコンバージェンス層として使用され得る、リックライダー転送プロトコル(LTP)などの適応型遅延/混乱耐性プロトコルの統合によって低減され得る。
LTPでは、データは、重要および非重要として識別され得る。ヘッダなどの重要なデータは、データが送信ユニットによって破棄される前に、正確に送信され、受信確認応答されなければならない。ピクチャ内の単一の画素などの非重要データは、伝送から復元可能である、または失われると重要性が低くなるのであってよく、従って、データは送信後に破棄され得る。極端なレイテンシに起因して、通信を開始する前に交渉は行われない。以下の図では、NDM技法を用いるデータの送信を説明する。
図58は、一部の実施形態による、送信のために複数のサブブロック5804に断片化されている送信データペイロード5802の概略図5800である。サブブロック5804のそれぞれは、可変長Liを有し得る。サブブロック5802は、1つまたは複数のネットワークプロトコルまたはPHYが使用される、N個のネットワークパスに割り当てられ得る。
次いで、サブヘッダデータを各サブブロック5804に付加することができ、例えば、データサブストリーム内の各フレームをヘッダデータでカプセル化して、メインデータペイロード内のサブストリームの順序を示して、宛先での再結合をサポートすることができる。ヘッダデータはまた、最大通過時間、例えば有効期間、ならびに優先順位付けおよび再試行ポリシーを含むことができる。ヘッダ情報が添付されると、サブブロック5804は、例えば上記の図54に関して説明したように、送信に使用される異なるプロトコルフレームでパッケージ化され得る。
図59は、一部の実施形態による、NDM-シリアル-パラレル伝送の概略図5900である。サブブロック5804は、同期ディスパッチモードのために時刻Ttx 5902にディスパッチされ得る。一部の場合では、サブブロック5804は、時刻Tt×[i]において、同期パス毎ディスパッチモードで送信されてもよく、各[i]は送信パスを表す。
図60は、一部の実施形態による、サブブロック5804の受信の概略図6000である。宛先、または他の意図された傍受点では、サブブロック5804は、ディスパッチされたときとは異なる順序および異なる時間オフセットで受信され得る。サブブロック5804は、異なるプロトコルにパッケージ化されている場合はパッケージ解除され、メッセージについて予想されるサブブロック5804の数および順序を判定するために分析され得る。次いで、サブブロック5804は、図58のTXデータペイロード5802に再アセンブルされる前に、すべての部分が受信されるまで保持され得る。
図61は、一部の実施形態による、受信データペイロード6102を形成するためのサブブロック5804の再結合の概略図6100である。ブロック順序を識別するために、各サブブロック5804内のヘッダデータを使用して、パラレルからシリアルブロック形式への変換が行われる。ヘッダ内の命令に応じて、サブブロック6102が欠落していても再アセンブルが行われ得る。
図62は、一部の実施形態による、複数の並列通信チャネルを介してペイロードを断片化しディスパッチするための例示的な方法6200のプロセスフロー図である。図62の方法6200は、図64に関して説明されるIoTデバイス6400によって実施することができる。方法6200は、例えばデータペイロードが送信の準備ができているときに、ブロック6202で開始する。
ブロック6204において、利用可能なネットワーク経路および関連プロトコルが発見される。これらはIoTデバイスのライブラリに保存され、接続が依然として存在していることを確認するために定期的にテストされる。発見された情報はまた、サポートされているプロトコルの許容ペイロードサイズ、伝送速度などに関するデータも含むことができる。
ブロック6206において、ペイロードをディスパッチするか否かに関する判定が行われる。これは、ペイロードの準備が整い、1つまたは複数のネットワークへの接続が存在するときに実行され得る。
ブロック6208において、ペイロードは、例えば、利用可能なネットワーク経路と、関連するプロトコルによってサポートされる最大利用可能ペイロードサイズとに基づいて断片化される。断片化は、伝送速度、優先度などの通信チャネルの他のパラメータを考慮に入れることができる。断片化は、図57~図61に関して説明したサブブロック5804を形成することができる。
ブロック6210において、断片はインデックス付けされる。これは、シーケンス番号を断片に割り当て、次いでシーケンス番号を含む断片ヘッダを構築することによって実行され得る。断片は、ヘッダと連結されてサブブロックを形成する。次いで、例えば図52~図56に関して説明したように、個々のサブブロックを異なる経路を介して送信するためのプロトコルフレームでパッケージ化することができる。ブロック6212において、ペイロードのサブブロックまたは断片は、異なる伝送経路に沿ってディスパッチされる。
図63は、一部の実施形態による、NDM技法を使用して送信されたパケットを受信し再結合するための例示的な方法6300のプロセスフロー図である。図63の方法6300は、図64に関して説明されるIoTデバイス6400によって実施することができる。方法6300は、断片が複数の異なる通信チャネルを介して送信デバイスから受信されると、ブロック6302で開始する。
これは、複数の異なる経路上および複数の異なるプロトコル内でフレームの受信を検出することによって実行され得る。フレームが異なるプロトコルでパッケージ化されている場合、ペイロードはプロトコルフレームから取り外されて分析される。分析はフレームを解析し、ヘッダを取り除く。ペイロードの断片はローカルメモリストアにプッシュされ、シーケンス番号が記録される。
ブロック6304において、すべての断片が受信されたか否かに関する判定が行われる。すべて受信されていない場合、プロセスフローはブロック6302に戻り、断片を待ち続ける。IoTデバイスは、データのアセンブルを開始する前に、すべての断片が受信されるのを待つ必要はない。例えば、断片のうちの1つにあるコマンドは、欠落している断片には非重要データが含まれているため、再アセンブルを停止するべきではないことを示すことができる。
ブロック6306において、断片は再度順序付けされ、結合され得る。例えば、各断片は、受信データペイロードを形成するために、シーケンス番号および長さによって再アセンブルされたデータペイロードに付加され得る。ブロック6308において、再結合されたペイロードが、例えばコンシューマプロセスに出力される。
図64は、一部の実施形態による、複数の並列パスに沿って送信するためにペイロードを断片化するための、IoTデバイス6400に存在し得るコンポーネントの一例のブロック図である。同様の番号が付けられた項目は、図3および図8に関して説明したとおりである。図8に関して説明したIoTデバイス800、および本明細書で説明される他のIoTデバイスに対して選択されたものとは異なるコンポーネントが、IoTデバイス6400に対して選択され使用されてもよいことに留意されたい。
大容量ストレージ808は、本明細書で説明される提携グループ形成を実施するための複数のモジュールを含むことができる。大容量ストレージ808においてコードブロックとして示されているが、モジュールのうちのいずれも、例えば特定用途向け集積回路(ASIC)に組み込まれるなど、ハードワイヤード回路で完全にまたは部分的に置き換えられ得ることが理解されよう。
大容量ストレージ808は、1つまたは複数の通信リンクを介して、例えばとりわけ、メッシュ送受信機810、アップリンク送受信機814、およびNIC 816を介して、メッシュデバイス812またはクラウド302内のデバイスからフレームを送信および受信する通信部6402を含むことができる。図64に関して説明した機能に加えて、4502に関して説明したように、通信部6402は、プロトコル間でのフレームの変換、他のプロトコルにおけるフレームのパッケージ化、プルーフオブプロヴェナンス追加の実行などの他の機能を実行することができる。さらに、通信部6402は、図33を参照して説明した通行権システム3312の一部とすることができる。
通信部6402は、IoTデバイス6400とターゲットデバイスとの間の通信のために利用可能なネットワークおよびプロトコルを識別するためにネットワーク発見部6504によって使用され得る。ネットワーク発見部6504は、並列NDM通信に使用される利用可能なネットワーク通信パスおよびプロトコルのリストを構築および維持することができる。
ペイロード6406は、例えばセンサ820から取得された測定値から、IoTデバイス6400によって構築され得る。一部の例では、ペイロード6406は、よりリモートにあるデバイスなど、メッシュデバイス812内の別のIoTデバイスから渡され得る。この例では、IoTデバイス6400は、ペイロードを含む通信を他のデバイスに渡すためのゲートウェイとして動作し得る。
ペイロード断片化部/パッケージ化部6408は、通信速度、信頼性、電力可用性、または任意の数の他の要因およびそれらの要因の組み合わせに基づいて、ペイロードおよび利用可能な通信チャネルを分析して、ペイロードの最適な通信をもたらす可能性があるチャネルの組み合わせを判定し得る。次いで、ペイロード断片化部/パッケージ化部6408は、送信のためにペイロードをサブオブジェクトに断片化することができる。ヘッダおよび他の識別情報およびシーケンス情報が送信のために付加され得る。選択された通信に応じて、サブオブジェクトは、様々なプロトコルフレームのデータフィールドにパッケージ化され、次いで、通信部6402によって選択された通信チャネルを介して送信され得る。
一部の態様では、通信は双方向であり得る。ペイロード受信部/分析部6410は、他のデバイスからのフレームを受信し、プロトコルパッケージングを取り外し、フレームを分析してメッセージおよびシーケンス情報を識別することができる。ペイロード受信部/分析部6410は、受信されたフレームのデータフィールドがペイロードのサブオブジェクトであると判定し得る。ペイロード受信部/分析部6410は、様々な条件が満たされるまでサブオブジェクトおよびシーケンス番号を格納し、次いで、シーケンス番号およびストレージ情報をペイロードデフラグ部6412に渡すことができる。条件は、ペイロード内のすべてのサブオブジェクトが受信されたという判定、またはシーケンス内の欠けているサブオブジェクトが非重要データを含み、アセンブルを進めるべきであるという判定を含むことができる。
ペイロードデフラグ部6412は、例えば、図63で説明したように、ペイロードを最終的なペイロードオブジェクトに再アセンブルすることができる。次いで、ペイロードは、IoTデバイス6400によって使用されても、データコンシューマに送信されてもよい。
図65は、一部の実施形態による、複数の並列パスに沿ってペイロードを断片化し送信するようにプロセッサ902に指示するためのコードを含む、非一時的機械可読媒体6500のブロック図である。プロセッサ902は、バス904を介して非一時的機械可読媒体6500にアクセスすることができる。プロセッサ902およびバス904は、図9に関して説明したプロセッサ902およびバス904と同様の方法で実施することができる。非一時的機械可読媒体6500は、図8の大容量ストレージ808について説明したデバイスを含むこともできるし、光ディスク、USBメモリ(thumb drive)、または任意の数の他のハードウェアデバイスを含むこともできる。
非一時的機械可読媒体6500は、受信デバイスへの利用可能なネットワークパスおよびプロトコルを発見するようにプロセッサ902に指示するためのコード6502を含み得る。コード6504は、通信のために選択されたプロトコルのためのフレームのデータフィールドに収まるようにペイロードを断片化するようにプロセッサ902に指示するために含まれ得る。コード6504は、とりわけパケットのシーケンス番号を含むヘッダ情報を付加するようにプロセッサ902に指示することができる。コード6506は、選択された通信に応じて、断片を異なるプロトコルのフレームにパッケージ化するようにプロセッサ902に指示するために含まれ得る。コード6508は、選択された異なる通信チャネルを介してターゲットデバイスの方向にフレームをディスパッチするようにプロセッサ902に指示するために含まれ得る。
コード6510は、例えば異なるプロトコルのフレームで、断片を受信するようにプロセッサ902に指示するために含まれ得る。コード6512は、異なるプロトコルのフレームからペイロードをパッケージ解除し、次いで、ヘッダ情報を解析して、ペイロードおよびシーケンス番号を識別するために含まれ得る。コード6512は、例えばすべての断片が受信される前に、ペイロードの再アセンブルをいつ試みるべきかを判定するようにプロセッサ902に命令することができる。コード6514は、シーケンス番号に基づいてペイロードを再アセンブルするようにプロセッサに指示するために含まれ得る。
上述の通信技法は、リモートに配置されたIoTデバイス、例えば気象センサ、産業用ユニットなどとの通信を可能にする、または強化するために使用され得る。これらのデバイスの位置判定は、特にバッテリ駆動のユニットを持つネットワークでは、問題になる場合がある。メッシュネットワーク内の他のデバイスから通信された情報からデバイスがそれらの位置を判定することを可能にする技法が、デバイスの少なくとも一部が電力を節約することを可能にし得る。これを実行するための1つの技法を図66~図70に記載する。
図66は、一部の実施形態による、ビーコンノード6602が近くのIoTデバイス6606に位置メッセージ6604を提供する、オーバーレイビーコンシステム6600の概略図である。インフラストラクチャのない地域でのIoTデプロイの場合、単一のIoTノード、またはビーコンノード6602は、衛星ベースの測位受信機を装備し、位置および時間データを隣接する接続されたノードに伝達するための地理位置情報ビーコンとして機能する。これは、ペイロードデータの一部として、それぞれの種類の通信リンクに適したフレームで位置ペイロードを送信することによって、複数の異種ネットワーク上で行われ得る。ビーコンノード6602は、全地球測位システム(GPS)衛星システム、全地球航法衛星システム(the global navigation satellite system)(GLONASS)、または他の全地球航法衛星システム(global navigation satellite system)(GNSS)から信号を受信するための衛星受信機などのGPSモジュールを装備したIoTデバイスであり得る。
一部の態様では、ビーコンノード6602は、3つ以上の全地球測位システム衛星6610から信号6608を取得することによってその位置を判定することができる。ビーコン送信ノード6602は、例えばNational Marine Electronics Association(NMEA)センテンスとして、衛星から受信したデータを、ディスパッチに適したデータ種別に変換することができる。IEEE 754パックドフォーマットなどの位置データを含む位置ペイロード6612が作成され得る。このフォーマットでは、緯度6614を表すために4バイトを使用することができ、経度6616を表すために4バイトを使用することができ、4バイトを付加タイムスタンプ6618とすることができる。ビーコンノード6602は、位置メッセージ6604として他のデバイスに送信するためのプロトコルフレームに位置ペイロード6612をパックすることができる。本明細書で説明されるように、利用可能な通信チャネルに応じて、任意の数のプロトコルが使用され得る。
定期的な時間間隔で、またはイベントベースのトリガもしくは他のトリガで、ビーコンノード6602は、位置メッセージ6604を送信する。ビーコンノード6602の範囲内、例えばビーコンノード6602から数十メートルから数百メートル内のIoTデバイスまたは他のノードは、位置メッセージ6604を受信し、自身のメッセージングまたは他の目的のために地理位置情報ペイロード6612を使用することができる。例えば、ローカルデバイスのための時間補正が、ビーコンノード6602からのタイムスタンプ6618を使用して実行されてもよい。
図67は、一部の実施形態による、位置ペイロードを生成するための例示的な方法6700のプロセスフロー図である。図67の方法6700は、図69に関して説明されるIoTデバイス6900によって実施することができる。ブロック6702は、例えば、デバイスに電源が投入されたとき、またはそうでなければ地理位置情報プロセスを開始するように命令されたときを表す。ブロック6704において、位置(position fix)が取得される。位置を取得するために、コマンドがGPSモジュールに送信される。ブロック6706において、初期位置算出待機時間(a wait time for a first fix)、例えば10秒、30秒、60秒、またはそれ以上が実施される。この待機時間が完了した後、ブロック6708において、位置が得られたか否かに関する判定が行われる。得られていない場合、プロセスフローはブロック6706に戻り、別のインクリメントを待つ。位置が取得されている場合、プロセスフローは、GPSモジュールからの位置データと共に、ブロック6704に戻る。
ブロック6710において、位置データが解析される。これは、経度、緯度、時間、および高度などの他のデータを抽出することによってブロック6712において実施することができる。抽出されたデータは、ローカルストア6714に格納される。
ブロック6716において、位置ペイロードがローカルストア6714内のデータから構築される。ペイロードは、例えば、緯度および経度の位置データのIEEE 754フォーマットの4バイト表現を使用して、位置をパケットに挿入することによって、ブロック6718において構築され得る。ブロック6720において、ビーコンIDをパケットに挿入することができ、ブロック6722において、タイムスタンプを加えることができる。タイムスタンプは、ローカルクロックから導出されてもよいし、衛星データから抽出された時間データであってもよい。ペイロードは、送信のためにフレームにパックされてもよい。フレームのプロトコルは、とりわけ、イーサネット(登録商標)、LoRaWAN(登録商標)、または4Gなどの、使用される通信チャネルに基づいてもよい。
ブロック6724において、フレームは、周囲のIoTデバイスにブロードキャストされる。これは、送信機を起動し、無線送信を介してメッセージとしてフレームをディスパッチすることを必要とし得る。一部の例では、フレームは、イーサネット(登録商標)などの有線ネットワークを介して送信され得る。一部の例では、パケットを位置情報として識別するためにペイロードにヘッダを加え、直接通信またはターゲット通信なしでパケットを周囲のデバイスにブロードキャストすることによって、単純なパケット構成を使用することができる。
ブロック6726において、プロセスを繰り返す前に待機時間を実施することができる。これは、所定期間、スリープコマンドを起動することによって実行されてもよい。ブロック6728において、位置ビーコンプロセスを続行するか否かに関する判定が行われる。続行する場合、プロセスフローは次の位置を取得するためにブロック6704に戻る。そうでなければ、プロセスはブロック6730で終了する。
図68は、一部の実施形態による、位置ペイロードを含むフレームを解析するための例示的な方法6800のプロセスフロー図である。図68の方法6800は、図69に関して説明されるIoTデバイス6900によって実施することができる。ブロック6802は、例えば、IoTデバイスがビーコンノードを発見したときを表す。ブロック6804において、ビーコンフレームまたは位置パケットがビーコンノードから受信される。ブロック6806において、ビーコンIDをチェックしてビーコンノードのアイデンティティを確認する。ブロック6808において、フレーム完全性チェックが実行されて、フレームまたは位置パケットが有効であるか否かが判定される。有効ではない場合、プロセスフローはブロック6804に戻り、別のフレームまたは位置パケットの受信を待つ。
有効なフレームまたは位置パケットが受信された場合、ブロック6812において、位置データ、例えば位置ペイロードが抽出される。ブロック6812において、位置ペイロードが解析され得る。これは、ブロック6814において、ペイロードから緯度および経度、また含まれる場合は高度を抽出することによって実行され得る。タイムスタンプは、ブロック6818において抽出され得る。情報はローカルストア6816に格納することができる。次いで、IoTデバイスは、例えばメッセージング、同期、または他の目的のためにローカルストア6816からの情報を使用することができる。
ブロック6820において、別のビーコンフレームが受信されたか否かに関する判定が行われる。受信された場合、プロセスフローはブロック6804に戻り、そのフレームを処理する。受信されていない場合、プロセスフローはブロック6822で終了する。
この技法では、すべてのノードが専用のGPS受信機を必要としないため、コストおよびバッテリ電力を節約できる。正確なデバイスごとの位置またはウェイポイント情報が必要でない場合、これは、IoTデバイスがそれらのデプロイエリアを識別し、位置および/または時間に依存するタスクを実行するために十分な情報を提供し得る。
図69は、一部の実施形態による、位置データを共有するためのビーコンノードシステムを確立するための、ビーコンノード6900に存在し得るコンポーネントの例のブロック図である。同様の番号が付けられた項目は、図3および図8に関して説明したとおりである。図8に関して説明したIoTデバイス800、および本明細書で説明される他のIoTデバイスに対して選択されたものとは異なるコンポーネントが、ビーコンノード6900に対して選択され使用されてもよいことに留意されたい。
この例では、IoTデバイス6900は、衛星位置データを受信し処理するためにGPSモジュール6902を含み得る。GPSモジュール6902は、複数の相互接続されたメッシュデバイス812に含まれ得るが、1つまたは少数でしかアクティブ化されない。これは、ビーコンノード6900において、例えば低バッテリのために障害が発生した場合、システムが位置および時間の冗長性をいくらか有することを可能にし得る。
大容量ストレージ808は、本明細書で説明されるビーコン機能を実施するための複数のモジュールを含むことができる。大容量ストレージ808においてコードブロックとして示されているが、モジュールのうちのいずれも、例えば特定用途向け集積回路(ASIC)に組み込まれるなど、ハードワイヤード回路で完全にまたは部分的に置き換えられ得ることが理解されよう。
大容量ストレージ808は、1つまたは複数の通信リンクを介して、例えばとりわけ、メッシュ送受信機810、アップリンク送受信機814、およびNIC 816を介して、メッシュデバイス812またはクラウド302内のデバイスからフレーム、または位置ペイロードを含む位置パケットを送信および受信するパケット通信部6904を含むことができる。4502に関して説明したように、パケット通信部6904は、異なるプロトコルで位置ペイロードをパッケージ化すること、プルーフオブプロヴェナンスチェックを実行することなどの他の機能を実行することができる。さらに、通信部6904は、図33を参照して説明した通行権システム3312の一部とすることができる。
GPSロケータ6906は、位置情報を取得するためにGPSモジュール6902と通信することができる。GPSロケータ6906は、例えば、バッテリの使用量を制御するため、またはGPSモジュールを有する別のメッシュデバイス812に障害が発生したときにGPSモジュール6906を起動するために、GPSモジュール6906への電力を供給したり電力供給を制限したりすることができる。GPSロケータ6906は、GPSモジュール6906からGPS位置データを収集し格納することができる。
データ解析部6908は、GPS位置を解析して、緯度、経度、時間、および高度などの他のパラメータを判定することができる。解析されたデータはさらなる使用のために格納されてもよい。
ペイロード構築部6910は、解析されたデータを使用して位置ペイロードを構築することができる。これは、図66に関して説明したように実行することができる。ペイロードは、ペイロード構築部6910によって特定のプロトコルタイプのフレームにパッケージ化することができる。次いで、フレームはパケット通信部6904によって送信されてもよい。
本明細書で説明されるように、IoTデバイスは、ビーコンノードとして機能することに限定されず、位置データを受信することもできる。これは、GPSモジュール6902に障害が発生したとき、またはその位置を判定することができないときに有用であり得る。一部の例では、IoTデバイス6900は、GPSモジュール6902を持たなくてもよいが、位置コンシューマとしてのみ機能してもよい。
フレーム確認部6912を使用して、パケットがビーコンIDと一致しかつ有効なデータを含むか否かを判定するためにビーコンノードから受信されたフレームを確認することができる。パケット確認部6912は、無効なパケットを拒否または無視することもできるし、例えばビーコンIDは正しいがフレームまたは位置パケットが破損している場合、再送要求を送信することもできる。
パケット抽出部6914は、受信したフレームを分析して、位置ペイロードを抽出することができる。これは、緯度、経度、および時間情報、ならびに高度などの他の情報を示すデータを判定することを含み得る。
図70は、一部の実施形態による、位置ペイロードを送信および受信するようにプロセッサ902に指示するためのコードを含む、例示的な非一時的機械可読媒体7000のブロック図である。プロセッサ902は、バス904を介して非一時的機械可読媒体7000にアクセスすることができる。プロセッサ902およびバス904は、図9に関して説明したプロセッサ902およびバス904と同様の方法で実施することができる。非一時的機械可読媒体7000は、図8の大容量ストレージ808について説明したデバイスを含むこともできるし、光ディスク、USBメモリ(thumb drive)、または任意の数の他のハードウェアデバイスを含むこともできる。
非一時的機械可読媒体7000は、例えばGPSモジュールを使用して、GPS衛星から位置データを取得するようにプロセッサ902に指示するためのコード7002を含み得る。コード7004は、緯度、経度、および時間について別々の値を取得するために、GPSモジュールからの位置データを解析するようにプロセッサ902に指示するために含まれ得る。コード7004は、位置データから高度などの他の値を判定するようにプロセッサ902に指示することができる。コード7006は、緯度、経度、および時間を含む位置ペイロードを構築するようにプロセッサ902に指示するために含まれ得る。コード7006は、位置ペイロードを特定のプロトコルのフレームにパッケージ化するようにプロセッサ902に指示することができる。コード7008は、様々な通信チャネルを通してペイロードデータをディスパッチするようにプロセッサ902に指示するために含まれ得る。コード7012は、ビーコンから受信された有効なフレームから位置ペイロードデータを抽出し、他の目的のためにペイロードデータを格納するようにプロセッサに指示するために含まれ得る。
ネットワークを介して情報を格納および配信するためのほとんどすべての方法がプッシュまたはプル方法を利用する。プッシュは、多くの場合、接続されているすべてのベースノードへのゲートウェイまたは基地局のブロードキャストとみなすことができる。この種類のモデルはまた、デバイスがデータを送信する手段としてチャネルを介してデータを送信する、パブリッシュ/サブスクライブモデルでもよく使用される。さらに、ほとんどのモデルでは、エンドポイントがデータをブロードキャストする(プッシュ)元の中央サーバ、またはそれらがプルする元のコンテンツサーバを使用する。図71~図74に関して説明された技法は、ネットワークを介してコンテンツを配信するためにプッシュおよびプルの組み合わせを使用する。
図71は、一部の実施形態による、異種ネットワークのための分散型コンテンツ配信システム7100の概略図である。分散型コンテンツ配信システム7100を使用すると、損失が多い場合がある、または接続が断続的であり得る異種ネットワークにわたる配信を可能にすることができる。さらに、データをステートレスに配信できる。分散型コンテンツ配信システム7100内の1つまたは複数のIoTデバイスまたはノード7102は、ノード上のデータの管理を担当するデータマネージャ7104を有する。データマネージャ7104は、分散型コンテンツ配信システム7100を通過するインバウンドデータ7108およびアウトバウンドデータ7110を分類することができるデータ分類部7106を含む、複数のサブシステムを有する。データには、インバウンド、アウトバウンド、およびキャッシュという3つの主な分類が使用される。
一部の態様では、データマップ部7112は、分類されたデータをシステム上の物理的位置にマッピングする役割を担当する。データマップ部7112は、ハッシュ関数などのアルゴリズムを使用してデータの最適位置を判定することができる。データ分類部7106は、アウトバウンドデータおよびキャッシュデータの分類を判定するためにリソースマネージャ7114と通信する。インバウンドデータ7108は、ノード自身によって消費されることを意図したデータである。データマップ部7112は、データをインボックス7116に転送し、リソースマネージャ7114は、インボックス7116に対する変更または更新を監視する。
アウトバウンドデータ7110は、1ホップを超える距離にあるノード7102によって共有されてもよく、リソースマネージャ7114によって判定される。アウトバウンドデータ7110は、アウトボックス7118に格納されてもよい。リソースマネージャ7114は、電力およびネットワークノード数など、ノード7102での現在のリソース可用性を計算することによってホップ数を計算する。
キャッシュデータは、キャッシュ7120に保存され、ノード7102にとって有用であると判定されたデータである。データ履歴部7122は、インバウンドおよびアウトバウンドのデータ要求など、ノード7102を出入りするデータを追跡することができる。プロトコルマネージャ7124は、例えば、特定のフレームに使用されている通信チャネルに基づいて、入って来るフレームおよび出て行くフレームに使用されるプロトコルを管理することができる。ネットワークマネージャ7126は、例えばネットワークスタックをホストすることなど、様々な通信チャネル上のネットワーク通信を処理することができる。通信マネージャ7128は、無線機、ネットワークインターフェースコントローラなどの物理レベル動作、すなわちPHY動作を処理することができる。
図72は、一部の実施形態による、分散型コンテンツ配信のための例示的な方法7200のプロセスフロー図である。図72の方法7200は、図71および図73に関して説明されるIoTデバイス7102によって実施することができる。ブロック7202において、データは分類される。これは、システムを通過する1つまたは複数のインバウンドデータとアウトバウンドデータ、例えば、インバウンドデータ、アウトバウンドデータ、およびキャッシュデータなどを分類することによって実行される。
ブロック7204において、分類されたデータはシステム上の正しい物理的位置にマッピングされる。例えば、ブロック7206に示されるように、これは、インバウンドデータの位置を識別するハッシュコードを生成するためのアルゴリズムを使用して実行され得る。
ブロック7208において、データがインバウンドであるか否かに関する判定が行われる。そうであれば、ブロック7210においてデータがローカルに格納される。ブロック7212において、ハッシュ鍵がチェックされる。ブロック7214において、ハッシュ鍵がローカルストア7216内にあるか否かに関する判定が行われる。そうでない場合、ブロック7218において、新しいデータ断片はローカルに格納される。次いで、プロセスフローはブロック7202に戻る。
ブロック7214で鍵がローカルストア7216内にあると判定された場合、ブロック7220において、例えばローカルストア7216内の前の情報と同一である場合に、情報が無視されるべきか否かに関する判定が行われる。もしそうであれば、プロセスフローはブロック7202に戻る。そうでない場合、データはローカルストア7216であり、新しい断片で更新され、そしてプロセスフローはブロック7202に戻る。
ブロック7208でデータがアウトバウンドデータであると判定された場合、ブロック7224において、最大ホップ数が計算される。これは生存期間(TTL)と呼ばれ、電力、ネットワークノード数など、ノードにおける現在のリソースの可用性を計算することによって判定され得る。ブロック7226において、データがターゲットノードにディスパッチ、またはプッシュされる。
ターゲットノードはまた、1ホップのノードからデータを要求することによってデータをプルすることもできる。データプル要求は、ホップカウント、すなわち、ネットワークを通過するときにパケットが作るホップ数に関して測定されるTTLを有することができ、TTLは、各ホップに続いてデクリメントされる。TTLがゼロカウントに達すると、データ断片は無効化される。TTLは、絶対時間、例えば、秒、分、または時間で測定されてもよく、データ断片は、タイムアウトが切れると無効化される。タイムアウト内にプル要求を取得しなかった場合は、ノードに要求をプッシュでき、その後、システムを介して転送され得る。
ブロック7226において、コンテンツの分散共有を続行するか否かに関する判定が行われる。続行する場合、プロセスフローはブロック7202において再開する。
各ノードは、データ履歴部で受信されたインバウンド要求およびアウトバウンド要求を追跡することができる。キャッシュウィンドウは、すべての要求に対して維持され得る。頻度は、一定期間にわたる要求の数など、複数の要因によって判定され得る。
デバイスはまた、アクセスされたカウンタとタイマを適用して、キャッシュされたデータがアクセスされる頻度を判定することによって、キャッシュサイズを自己管理する。データが頻繁にアクセスされている場合はキャッシュが増加する可能性があり、アクセス頻度が低い場合はキャッシュが減少する可能性がある。各ノードはまた、データマネージャを介してデータをプッシュできるかプルできるかを判定する。
図73は、一部の実施形態による、分散型コンテンツ配信システムを実装するための、IoTデバイス7300に存在し得るコンポーネントの一例のブロック図である。同様の番号が付けられた項目は、図3、図8、および図71に関して説明したとおりである。図8に関して説明したIoTデバイス800、および本明細書で説明される他のIoTデバイスに対して選択されたものとは異なるコンポーネントが、IoTデバイス7300に対して選択され使用されてもよいことに留意されたい。
大容量ストレージ808は、本明細書で説明される提携グループ形成を実施するための複数のモジュールを含むことができる。大容量ストレージ808においてコードブロックとして示されているが、モジュールのうちのいずれも、例えば特定用途向け集積回路(ASIC)に組み込まれるなど、ハードワイヤード回路で完全にまたは部分的に置き換えられ得ることが理解されよう。
大容量ストレージ808は、図71に関して説明したモジュールを含むことができる。インボックス7116、アウトボックス7118、キャッシュ7120、およびデータ履歴部7122などのデータストア7304が、大容量ストレージ808に含まれてもよいし、他のデバイス上のメモリなどの他の場所に格納されてもよい。
大容量ストレージ808は、1つまたは複数の通信リンクを介して、例えばとりわけ、メッシュ送受信機810、アップリンク送受信機814、およびNIC 816を介して、メッシュデバイス812またはクラウド302内のデバイスに対してパケットを送信し、そこからフレームを受信する通信部7302を含むことができる。図73に関して説明した機能に加えて、図45の4502に関して説明したように、通信部7302は、プロトコル間でのパケットの変換、プルーフオブプロヴェナンス追加などの他の機能を実行することができる。さらに、通信部7302は、図33を参照して説明した通行権システム3312の一部とすることができる。
図74は、一部の実施形態による、分散型コンテンツ配信システムを実装するようにプロセッサ902に指示するためのコードを含む、非一時的機械可読媒体7400のブロック図である。プロセッサ902は、バス904を介して非一時的機械可読媒体7400にアクセスすることができる。プロセッサ902およびバス904は、図9に関して説明したプロセッサ902およびバス904と同様の方法で実施することができる。非一時的機械可読媒体7400は、図8の大容量ストレージ808について説明したデバイスを含むこともできるし、光ディスク、USBメモリ(thumb drive)、または任意の数の他のハードウェアデバイスを含むこともできる。
非一時的機械可読媒体7400は、分散型コンテンツ配信システムを通過するデータを、インバウンドデータ、アウトバウンドデータ、またはキャッシュデータとして分類するためのコード7402を含み得る。コード7404は、分類されたデータをシステム上の物理的位置にマッピングするようにプロセッサ902に指示するために含まれ得る。コード7404は、データの最適位置を判定するようにプロセッサ902に指示することができる。コード7406は、データのハッシュ関数を計算するようにプロセッサ902に指示することができる。コード7408は、ハッシュ鍵がローカルストアにあるか否かを判定するようにプロセッサ902に指示するために含まれ得る。
コード7410は、新しいデータ断片をローカルに格納するようにプロセッサ902に指示するために含まれ得る。コード7412は、ローカルに格納されたデータ断片を更新するために含まれ得る。コード7414は、例えば、削除前のホップ数、削除前の時間、またはその両方で、データ断片の生存期間を計算するようにプロセッサに指示するために含まれ得る。コード7416は、例えばフレーム単位で他のノードにデータをディスパッチするために含まれ得る。フレームのプロトコルは、フレームを送信するために使用された通信チャネルに基づいて選択されてもよい。
図75は、一部の実施形態による、無線メモリシステム7500の概略図である。無線メモリシステム7500は、発信ノード7504および受信ノード7506などの、接続された2つ以上のノード間の通信チャネル7502を記憶媒体7508として使用する。これは、本質的には、無線信号自体がノード7504と7506との間で転送されるデータのための記憶媒体7508として働く、無線順次アクセスメモリシステムである。よって、ノード7504および7506は、通信帯域幅のためにストレージ空間を交換し得る。
無線メモリシステム7500では、発信ノード7504に到着したデータ7510は、受信ノード7506などの別のノードに送信されるためにループバックされる7512。次いで、受信ノード7506に到着したデータ7514はループバック7516され、発信ノード7504に送り返される。一部の例では、複数のノードがデータを受信および送信するためのチェーンを形成し得る。このプロセスを繰り返すことによって、データは飛行中のままであり、通信チャネル7502は記憶媒体として働く。
図76は、一部の実施形態による、無線メモリシステム7500の別の概略図である。同様の番号が付けられた項目は、図75に関して説明したとおりである。この例では、発信ノード7504のためのネットワークスタック7602と、受信ノード7506のためのネットワークスタック7604と、が示されている。発信ノード7504のアプリケーション層7608から到着するデータ7606は、タグ付けされ、保護され、そして受信ノード7506への送信7514として、格納のために送信されてもよい。しかしながら、受信ノード7506は、送信7514内のデータをアプリケーション層7610に渡さないが、ネットワーク/経路指定層7612内でループバック動作7516を実行して、受信データを別の送信7510として送出することができ、例えば発信ノード7504に戻す。
ラウンドトリップメモリストレージ時間、Mtmは、次のように与えられる。 TOstack+TTX+T1stack+TRX この式では、TOstackは、ストレージペイロードが発信ノード7504のネットワーク/経路指定層7614を通過して無線伝送を介して出るのにかかる時間を表す。TTXは、発信ノード7504から受信ノード7506への飛行中の送信時間を示す。T1stackは、スタック内ループバック7516が受信ノード7506内で発生する時間を表し、TRXは、受信ノード7506から発信ノード7504へ戻る飛行中の送信時間である。
図77は、一部の実施形態による、デバイス間の送信ループにおいてデータを断片化し格納するための例示的な方法7700のプロセスフロー図である。図77の方法7700は、図79に関して説明されるIoTデバイス7900によって実施することができる。方法7700は、システムに電力が供給されると、ブロック7702において開始する。ブロック7704において、通信サブシステムが開始され、異なるデバイス間で通信チャネルが確立される。
ブロック7706において、デバイス間の経路指定動作が開始される。経路指定動作は、データ送信またはデータストレージ要求であり得る。ブロック7708において、経路指定要求がデータストレージ要求であるか否かに関する判定が行われる。そうでない場合、データは経路指定され、プロセスフローはブロック7706に戻り、別の経路指定要求を待つ。
ブロック7710において、格納されるデータは、例えば個々のフレームまたは他の適切なパッケージングに収まるように断片化される。ブロック7712において、データがメモリパケットにカプセル化される。データは通信チャネルを介して転送されるのではなく単に経路指定されて戻されるため、パッケージ化は簡単であり、例えば、メモリパケットは、データが格納されていることを示すヘッダとシーケンス番号を加えることにより形成され得る。これにより、オーバーヘッドが削減され、格納されるデータ量を増やすことができる。ブロック7714において、メモリパケットは、再アセンブルし、またはデータの開始点および終了点の識別を可能にするように順序付けされる。
ブロック7716において、メモリパケットは通信チャネルを介してディスパッチされる。ブロック7718において、すべてのメモリパケットが送信されたか否かに関する判定が行われる。送信されていない場合、プロセスフローはブロック7716に戻り、別のメモリパケットをディスパッチする。すべてのパケットがディスパッチされている場合、プロセスフローはブロック7706に戻る。
図78は、一部の実施形態による、ストレージのために通信チャネルを使用するデータストレージおよびアクセスのための例示的な方法7800のプロセスフロー図である。図78の方法7800は、図79に関して説明されるIoTデバイス7900によって実施することができる。ブロック7802は、例えばデバイスが起動されたときを表す。ブロック7804において、通信サブシステムが開始され、通信チャネルが他のデバイスと確立される。
ブロック7806において、例えばパケットまたはフレームがデバイスによって受信されると、経路指定動作が行われる。ブロック7808において、メモリパケットが受信されたか否かに関する判定が行われる。受信されていない場合、プロセスフローはブロック7806に戻り、経路指定を完了し、別のパケットまたはフレームが受信されるのを待つ。
メモリパケットがブロック7808で識別されている場合、ブロック7810において、パケットを格納し続けるべきか否かに関する判定が行われる。もしそうであれば、ブロック7812において、パケットは、例えば送信デバイスに戻されて、格納プロセスに戻される。
パケットがもはや格納されない場合、ブロック7814において、ペイロードがパケットから取り除かれ格納される。ブロック7816において、シーケンス番号がヘッダ情報から判定され、データ再アセンブルのために格納される。ブロック7818において、すべてのパケットが受信されたか否かに関する判定が行われる。そうでなければ、プロセスフローはブロック7806に戻り、次のパケットまたはフレームを待つ。
ブロック7818で、すべてのパケットが受信されたと判定された場合、ブロック7820において、ペイロードが再アセンブルされてデータが形成される。ブロック7822において、データはコンシューマによって使用される。
図79は、一部の実施形態による、送信チャネルにおいてデータを格納するための、IoTデバイス7900に存在し得るコンポーネントの一例のブロック図である。同様の番号が付けられた項目は、図3および図8に関して説明したとおりである。図8に関して説明したIoTデバイス800、および本明細書で説明される他のIoTデバイスに対して選択されたものとは異なるコンポーネントが、IoTデバイス7900に対して選択され使用されてもよいことに留意されたい。
大容量ストレージ808は、本明細書で説明される提携グループ形成を実施するための複数のモジュールを含むことができる。大容量ストレージ808においてコードブロックとして示されているが、モジュールのうちのいずれも、例えば特定用途向け集積回路(ASIC)に組み込まれるなど、ハードワイヤード回路で完全にまたは部分的に置き換えられ得ることが理解されよう。
ペイロード断片化部7902は、ストレージ要求を受信し、通信チャネル、データのサイズなどに基づいてデータをペイロードに断片化することができる。ペイロード断片化部7902は、データストリーム中のペイロードに関連するシーケンス番号を判定することができる。カプセル化部7904は、ペイロードをパケットにカプセル化することができ、ヘッダは、そのパケットをストレージ要求として識別する。ヘッダはまた、ペイロードのシーケンス番号を含むこともある。選択された通信チャネルに応じて、パケットは、プロトコルフレームのデータフィールドにパッケージ化されてもよいが、オーバーヘッドはより単純なカプセル化の使用に向けて不利に作用し得る。
大容量ストレージ808は、1つまたは複数の通信リンクを介して、例えばとりわけ、メッシュ送受信機810、アップリンク送受信機814、およびNIC 816を介して、メッシュデバイス812またはクラウド302内のデバイスに対してパケットを送信および受信する通信部7906を含むことができる。図79に関して説明した機能に加えて、図45の4502に関して説明したように、パケット通信部7902は、プロトコル間でのパケットの変換、プルーフオブプロヴェナンス追加などの他の機能を実行することができる。さらに、パケット通信部7902は、図33を参照して説明した通行権システム3312の一部とすることができる。
ルータ7908は、受信されたパケットおよびフレームを調べて、それらがストレージ要求の一部であるか否かを判定することができる。格納されたデータを含むパケットは、例えば通信スタック内のネットワーク/経路指定レベルから再送信されてもよい。取得要求が受信された場合、ルータは、抽出のために格納されたデータを含むパケットを傍受することがある。ルータ7908はまた、アプリケーションからデータを受信し、それが格納されるべきか送信されるべきかを判定することができる。
ペイロード抽出部7910は、ストレージストリームから抽出されたパケットを取り出し、そのパケットからペイロードおよびシーケンス番号を抽出することができる。次いで、データアセンブラ7912は、デバイスによる使用のために取得されたデータを再アセンブルすることができる。一部のパケットが欠けている場合、データアセンブラ7912は、それらのパケットを探し続けるようにルータに命令することができる。
図80は、一部の実施形態による、データを送信チャネルに格納するようにプロセッサ902に指示するためのコードを含む、例示的な非一時的機械可読媒体8000のブロック図である。プロセッサ902は、バス904を介して非一時的機械可読媒体8000にアクセスすることができる。プロセッサ902およびバス904は、図9に関して説明したプロセッサ902およびバス904と同様の方法で実施することができる。非一時的機械可読媒体8000は、図8の大容量ストレージ808について説明したデバイスを含むこともできるし、光ディスク、USBメモリ(thumb drive)、または任意の数の他のハードウェアデバイスを含むこともできる。
非一時的機械可読媒体8000は、他のデバイスとの通信チャネルを確立するようにプロセッサ902に指示するためのコード8002を含み得る。コード8004は、経路指定要求がデータストレージ要求であるか否かを判定するようにプロセッサ902に指示するために含まれ得る。コード8004は、ストレージ要求のためのデータをペイロードに断片化するようにプロセッサ902に指示するために含まれ得る。コード8008は、ペイロードをメモリパケットにカプセル化するようにプロセッサ902に指示するために含まれ得る。
コード8010は、通信チャネルを介してメモリパケットを経路指定するようにプロセッサ902に指示するために含まれ得る。コード8010は、メモリパケットを別のデバイスに再送すべきか、または使用のために傍受すべきかを判定するようにプロセッサ902に指示することができる。
コード8012は、メモリパケットからペイロードをパッケージ解除し、次いで、ヘッダ情報を解析してシーケンス番号を識別するようにプロセッサ902に指示するために含まれ得る。コード8014は、シーケンス番号に基づいてペイロードからデータを再アセンブルするようにプロセッサ902に指示するために含まれ得る。
図81は、一部の実施形態による、動的シグナリングに使用され得る波形8100の図である。本明細書で説明されるように、プリアンブル波形8102および8104は送信波形8106の前に加えられてもよく、送信波形は個々のチャネル内の複数の重なり合うフレームを含む。プリアンブル波形8102および8104は、アップリンクのためにクライアントデバイスによって使用されることになるデータチャネル数を動的に判定するために基地局によって使用され得る。プリアンブル波形8102および8104を使用すると、帯域外制御メッセージングまたは他の同期情報を使用して基地局にデータチャネルを知らせることを排除することができる。
一部の態様では、プリアンブル波形8102および8104は、シフトZadoff-Chu(ZC)シーケンスを使用して構築されたアナログ波形であり得る。ZCシーケンスは、ZCシーケンスを同期の目的にとって非常に魅力的なものにする自己相関プロパティおよび相互相関プロパティを有する、いわゆる振幅一定のゼロ自己相関(CAZAC)シーケンスの一種である。それらは主に高速無線通信用のロングタームエボリューション(LTE)規格で使用されている。
一部の態様では、ZCシーケンスは、無線信号に適用されたときに一定振幅の電磁信号を生じさせる複素数シーケンスであり、それによって、信号に課されるシーケンスの巡回シフトされたバージョンが、受信機において互いにゼロ相互相関になる。シフトされていない生成されたシーケンスは、ルートシーケンスとして知られる。
ZCシーケンスはまた、一定振幅のプロパティも有する。通信信号に採用されるとき、これは、送信機内の電力増幅器の効率を改善する。これは、直交周波数分割多重(OFDM)などの高線形性システムに通常使用されるよりも低コストの電力増幅器を使用する機会を与える。ZCまたは他の一定包絡線シーケンスを使用して線形増幅信号を維持する能力は、急速に変化する振幅プロファイルを有するシーケンスを使用するよりも複雑ではなく、そして安価である。線形性が損なわれると、信号品質が劣化する可能性がある。CAZACシーケンスは、優れたアンチノイズ特性を示し、信号雑音比が-10dBと低い場合でも検出できる。まとめると、これらのプロパティのすべてにより、通信システムにおけるプリアンブルシグナリングおよび同期のために使用されるとき、ZCシーケンスが非常に魅力的になっている。
この手法は、クライアントおよび基地局のシグナリング波形を、交換されるフレームの前に加えるように設計されており、特定のフレームに使用されているチャネルを示している。動的スペクトルアクセスおよび適応帯域幅の手法を使用して無線システム用に設計されており、制御チャネルまたはスケジューリングされたアップリンク(UL)/ダウンリンク(DL)タイムスロットを使用または要求しないシステムに特に適している。
チャネライズドシステムでは、プリアンブル構造8102および8104は、クライアントがそのULペイロードメッセージをディスパッチする前に、クライアントデバイスが、クライアントデバイスから基地局にULデータペイロードを伝達するために使用されるチャネル数を受信基地局に通知できるようにし得る。低オーバーヘッドIoTシステムに使用される低電力広域無線通信における使用が一例である。これらの技法により、より多くのデータをULモードで基地局にディスパッチする必要がある場合や、例えば無線ファームウェアおよび構成の更新をサポートするために、可変データ長を基地局からリモートクライアントデバイスにディスパッチする必要がある場合に、これらのデバイスが使用する帯域幅を動的に変更できる。
図82は、一部の実施形態による、ZCプリアンブル構造を使用してデータを送信するための例示的な方法8200のプロセスフロー図である。図82の方法8200は、図85に関して説明されるIoTデバイス8500によって実施することができる。ブロック8202において、クライアントデバイスは、利用可能または可能なチャネル数Nを判定する。これは、デバイスを結合している通信チャネルの情報理論分析によって実行され得る。利用可能なチャネル数は、例えば単一のチャネルメッセージで通信を初期化するために受信デバイスに送信されてもよい。
ブロック8204において、利用可能なチャネル数Nに対応するN個のZCシーケンスのセットが、各チャネルに関連する整数のゼロでない固有のZCシフト値K
cのセットKを生成することによって生成され、cはチャネル番号を表す。基地局を含むすべての無線デバイスがKの知識を有し、例えばそれら自身のチャネル情報のコピーを生成することに留意されたい。各シフト値K
cに対するZCシーケンスは次式に従って生成される。
各ルートZCシーケンス(u)の各位置(n)における複素数値は、次の式で与えられる。
0≦n≦N
ZCであり、N
ZCはシーケンスの長さである。
次いで、デバイスは、デバイスが通信においてに基地局にULデータをディスパッチするために使用することを意図しているチャネル数kを判定し得る。例えば、デバイスは、すべての可能なチャネルを使用する必要はなく、送信のための信号雑音比を高めるためにより少ない数を使用する場合もある。
ブロック8206において、無線クライアントデバイスは、波形を送信するために使用されるチャネル数cに対応するシーケンスKcを選択する。次いで、ブロック8208において、クライアントデバイスは、ZCプリアンブルを生成する。ブロック8210において、無線デバイスは、変調フレームを送信するためにデバイスによって使用される既存の複素数値ベースバンド波形の前に単一のZCシーケンスxKcを付加する。ブロック8212において、無線クライアントデバイスは、ベースバンド波形をアップコンバートして送信する。
図83は、一部の実施形態による、ZCシフトシーケンスを使用して複数のチャネルでデータを受信するための例示的な方法8300のプロセスフロー図である。図83の方法8300は、図85に関して説明されるIoTデバイス8500によって実施することができる。方法8300は、受信デバイスが送信デバイスによって使用されることになるチャネル数を判定するときに、ブロック8302において開始する。これは、プリアンブルを検出するために入ってくる複素数値シーケンスに対する自己相関によって実行され得る。NZCが素数の場合、ZCシーケンスは周期NZCで周期的である。NZCが素数の場合、ZCシーケンスの離散フーリエ変換(DFT)もZCシーケンスである。素数長のZCシーケンスとそれ自身の巡回シフトされたバージョンとの自己相関はゼロである。プリアンブルはまた、受信デバイスにおいてシフトされたZCシーケンスのそれぞれと相互相関を実行することによって検出され得る。1つのシーケンスが機能する場合、そのシーケンスの信号強度は、図84に関して説明したように、他のものよりもはるかに高い。
ブロック8304において、プリアンブルが検出された場合、クライアントデバイスによって使用されることが意図されているチャネル数は、受信されたZCプリアンブルと既知の可能なZCシフトシーケンスのセットとの相互相関から判定される。受信機は、ZCシーケンス長、NZ C、およびシフト値のセットに関する先験的な知識を必要とし、そして以下の式を使用することができる。
x(n)およびy(n)は相関している2つのシーケンスで、相関出力は
で表される。例えば、異なるu個の値の2つの素数長のZCシーケンス間の相互相関は一定であり、以下に等しい。
受信信号で使用されるシーケンスは、相関結果によって判定される。ゼロ自己相関ZCシーケンスプロパティにより、これを高い信頼度で達成することが可能になる。ブロック8304でZCプリアンブルが検出されない場合、プロセスフローはブロック8304に戻り、次のフレームを繰り返す。
ブロック8306において、逆マッピングが実行されて、UL信号において使用された検出されたZCシーケンスに対応するチャネル数を判定する。ブロック8310において、基地局は、ZCベースのシグナリング波形の直後に続くクライアントデバイスから組み合わされたiチャネルペイロードを受信および復調するためにその受信チェーンを準備する。ブロック8312において、N個のチャネルデータのそれぞれに対するペイロードデータは、例えば、チャネルに対応するシフトされたZCシーケンスを有するペイロード波形に対して相互相関技法を使用して復調される。
図84は、一部の実施形態による、Kによって与えられるシーケンスのそれぞれについての式、
で詳述されている相関プロセスを示す一連のプロットである。これは、どのシーケンスKcが最大の相関ピークをもたらしたかを判定する。最初のプロットは、u=19、k=19、およびuがチャネルcに対応する最初のシーケンスが最大の相関出力をもたらしたことを示している。より具体的には、正しいシーケンスZCdは、以下の最大値を見つけることによって判定される。 ZC
d=max(max(x
Kc)) x
Kcは相互相関プロセスの出力である。
図85は、一部の実施形態による、複数の同時チャネルでデータを送信するためにZCシーケンスを使用するための、IoTデバイス8500に存在し得るコンポーネントの一例のブロック図である。同様の番号が付けられた項目は、図3および図8に関して説明したとおりである。図8に関して説明したIoTデバイス800、および本明細書で説明される他のIoTデバイスに対して選択されたものとは異なるコンポーネントが、IoTデバイス8500に対して選択され使用されてもよいことに留意されたい。
大容量ストレージ808は、本明細書で説明される提携グループ形成を実施するための複数のモジュールを含むことができる。大容量ストレージ808においてコードブロックとして示されているが、モジュールのうちのいずれも、例えば特定用途向け集積回路(ASIC)に組み込まれるなど、ハードワイヤード回路で完全にまたは部分的に置き換えられ得ることが理解されよう。
大容量ストレージ808は、利用可能な最大チャネル数を判定するチャネル識別部8502を含み得る。シーケンス生成部8504は、チャネルのそれぞれについてZCシーケンスを生成することができる。プリアンブル生成部は、通信に使用されるチャネル数を示すプリアンブル波形を生成することができる。通信部8506は、チャネルに関連付けられたZCシーケンスを使用して、そのチャネルに関連付けられたフレームのそれぞれについて変調波形を生成することができる。次いで、通信部8506は、変調波形を重ね合わせ、プリアンブル波形を先頭に付加し、そして得られた波形をメッシュ送受信機810などの送信機に渡すことができる。
一部の態様では、通信は双方向である。インデックス識別部8510は、別のデバイスから受信した波形を分析し、プリアンブルが存在するか否かを判定するために相互相関を実行することができる。存在する場合、インデックス識別部は、ペイロード内のチャネル数を判定するためにルックアップを実行することができる。チャネル復調部8512は、チャネルのそれぞれにおける情報を復調して、そのチャネル内で送信された元のフレームを復元することができる。
図86は、一部の実施形態による、ZCシフトシーケンスを使用して変調するチャネルを介して通信するようにプロセッサ902に指示するためのコードを含む、例示的な非一時的機械可読媒体8600のブロック図である。プロセッサ902は、バス904を介して非一時的機械可読媒体8600にアクセスすることができる。プロセッサ902およびバス904は、図9に関して説明したプロセッサ902およびバス904と同様の方法で実施することができる。非一時的機械可読媒体8600は、図8の大容量ストレージ808について説明したデバイスを含むこともできるし、光ディスク、USBメモリ(thumb drive)、または任意の数の他のハードウェアデバイスを含むこともできる。
非一時的機械可読媒体8600は、利用可能なチャネル数を判定するようにプロセッサ902に指示するためのコード8602を含み得る。コード8604は、チャネルのそれぞれについてZCシーケンスを生成するようにプロセッサ902に指示するために含まれ得る。コード8606は、変調波形のためのZCプリアンブルを生成するようにプロセッサ902に指示するために含まれ得る。コード8608は、ZCプリアンブルを変調波形の前に加えるようにプロセッサ902に指示するために含まれて得る。コード8610は、ZCプリアンブルおよび変調波形を送信するようにプロセッサ902に指示するために含まれ得る。
コード8612は、ZCプリアンブルが存在するか否か、そして存在する場合、いくつのチャネルが表されるかを判定するために受信波形に対して相互相関を実行するようにプロセッサ902に指示するために含まれ得る。コード8614は、存在するチャネル数に対して受信機を構成するようにプロセッサ902に指示するために含まれ得る。コード8616は、各チャネルからデータを復元するためにチャネルを復調するようにプロセッサ902に指示するために含まれ得る。
図87は、一部の実施形態による、IoTデバイス8702内のマルチ無線機共存システム8700の概略図である。IoTデバイス8702は、クラウドとの通信、またはフォグデバイス内の他のIoTデバイスとの通信を可能にするゲートウェイまたはコーディネータであり得る。本明細書で説明されるように、マルチ無線機共存システム8700は、スペクトルのより効率的な使用を可能にするために、複数の無線システム8704を使用して他のノード8706内の無線システムとの通信を可能にする。これは、異なる無線技術間ならびに周波数スペクトルの一次ユーザと二次ユーザとの間の共存を可能にし得る。
1つの手法は、特定の周波数帯域に限定された、二次ユーザのアクセスシステムとしてコグニティブ無線を使用して、周波数スペクトルの一時的に使用されていない部分への適合による免許不要(license exempt)アクセスを可能にすることである。コグニティブ無線(CR)は、どの通信チャネルが使用中であるかを検出し、占有されているものを避けながら通信を空いているチャネルに移動させることができる。これらの周波数帯で動作するデバイスは、一次ユーザを保護し、他のユーザと共存するなど、定義された一連の規則に従う。
CRはホワイトスペース(WS)スペクトルの使用をカバーするが、本明細書で説明される技法は、IEEE 802.11x、IEEE 802.15.4に準拠する無線機8704およびLoRaなどの非標準無線機などの、規格を用いる無線送受信機の共存に関する。ノード8706間の通信は、無線システム間の共存に関する情報を共有するために使用され得る。例えば、共存マネージャ8708は、特定の通信に使用中の無線機8704を追跡し、その情報をチャネルデータストア8710に保存することができる。
一部の態様では、ユニバーサル共存インターフェース8712が、共存マネージャ8708からの情報にアクセスし、どの時点でどの通信を使用できるかを識別することができる。IEEE 802.22およびIEEE 802.11afに基づく無線規格は、共存のための方法を既にサポートしている。例えば、IEEE 802.22は、共存に時間ベースの方法を使用するが、IEEE 802.19.1は、TV WS周波数間でのみ共存データを共有するためのメカニズムを提供する。ユニバーサル共存インターフェース8712はまた、符号化方式および変調などの動作パラメータ、ならびに個々の無線機の送信電力の変更を可能にし得る。
次いで、ユニバーサル共存インターフェース8712によって選択された通信チャネルは、プロトコル抽象化API(アプリケーションプログラミングインターフェース)8714に渡されて、特定の通信チャネル用のフレームを構築することができる。プロトコル抽象化API 8714は、選択された通信チャネルに使用することができるプロトコルを取得するためにプロトコルデータストア8716にアクセスすることができる。次いで、線8718によって示されているように、フレームは、他のノード8706に送信されてもよいし、他のノード8706から受信されてもよい。
図88は、一部の実施形態による、複数の共存する無線機の制御および管理のための例示的な方法8800のラダー図である。図88の方法8800は、図87および図89に関して説明されるIoTデバイス8702によって実施することができる。同様の番号が付けられた項目は、図87に関して説明したとおりである。段階8802において、共存マネージャ8708は、ローカルセキュリティ機関ドメインブローカ(LSADB)8804への通信に利用可能な帯域の要求8802を送信する。LSADB 8802は、利用可能な帯域を提示するメッセージ8806で応答する。
次いで、共存マネージャ8708は、初期帯域計画を計算し(8808)、1つまたは複数の近隣機のアイデンティティを含む近隣機マップを構築する(8810)。この情報は、図87に関して説明したチャネルデータストア8710に保存され得る。次いで、共存マネージャ8708は、近隣機と通信するために使用され得る通信チャネルまたは帯域を識別するために、クロスドメイン情報共有システム(CDIS)8814に要求8812を送信することができる。CDIS 8814は、近隣機と共に使用することができる通信チャネルを識別するメッセージ8815で応答することができる。この情報は、共存マネージャ8708によって使用されて、近隣機および関連する通信チャネルの両方を識別する初期共存モデルを判定することができる(8816)。その時点で、共存マネージャ8708は、システムをセットアップするためにさらなる通信を待つ。
初期化を完了するために、無線システム8704は、メッセージ8818をプロトコル変換API 8714に送信して、IoTデバイスで利用可能な無線タイプをエニュメレーションすることができる。次いで、プロトコル変換API 8714は、存在する無線タイプに使用される、とりわけフレーム用のプロトコルなどの規格が、例えば図87に関して説明したプロトコルデータストア8716において利用可能であることを検証する(8820)。そうでない場合、プロトコル変換API 8714は、クラウドから適切な規格をダウンロードすることができる。次いで、段階8822において、プロトコル変換API8714は、無線機が規格8822に従っていることを確認し、無線機のためのサブスクリプション要求をユニバーサル共存インターフェース8712に送信する。
段階8826において、ユニバーサル共存インターフェース8712は、無線管理識別を無線タイプのうちの1つまたは複数に割り当てる。次いで、ユニバーサル共存インターフェース8712は、無線タイプの管理IDを含むサブスクリプション要求8828を共存マネージャ8708に送信する。
サブスクリプション要求8828を受信した後、共存マネージャ8708は、アクティブ共存モデルを判定し(8830)、初期共存モデルを更新または置換する。例えばCDIS 8814に存在しないために、いずれの無線タイプも初期共存モデルに存在しなかった場合、共存マネージャ8708は、新しい無線機に対するサブスクリプション要求8832を送信する。CDIS 8814は、例えば、ラジオが登録されたことを示すメッセージで応答する(8834)。次いで、共存マネージャ8708は、新しい無線機のサブスクリプション要求が受け入れられたという通知8836をユニバーサル共存インターフェース8712に送信する。
プロトコル変換API 8714がユニバーサル共存インターフェースへの無線タイプをエニュメレーションすると、機能が完了したことを示すためにメッセージ8838を無線システム8704に送信することができる。メッセージ8838は、ユニバーサル共存インターフェース8712にエニュメレーションされている無線タイプをエニュメレーションすることができる。
無線システム8704は、プロトコル変換API 8714にメッセージ8840を送信して、無線機のうちの1つまたは複数の無線機初期化を再開することができる。プロトコル変換API 8714は、再び無線タイプの規格を確認し(8842)、無線のいずれかが規格に非準拠であるか否かを判定する(8844)。次いで、プロトコル変換API 8714は、メッセージ8846を無線システム8704に送信して、無線機のそれぞれに対して構成可能なパラメータを設定することができる。無線システム8704は、無線機に対して設定されたパラメータを確認するメッセージ8848で応答することができる。次いで、プロトコル変換API 8714は、使用中の無線機用のパラメータマッピングセットを作成し、無線タイプのエニュメレーションが完了したことを示すメッセージ8852を無線システム8704に送信し、無線システム8704との通信が初期化される。
CDIS 8814が共存違反を検出した場合、例えばライセンスを受けたユーザがIoTデバイスによる使用をブロックする周波数を占有している場合、それは共存マネージャ8708に違反を知らせるメッセージ8854を送信することができる。段階8856において、共存マネージャ8708は、例えば関連する無線機がブロック信号を受信しているか否かを判定することによって共存違反を検証し、次いで違反を示すフラグを設定することができる(8858)。次いで、通信パラメータの再構成を要求するために、メッセージ8860をユニバーサル共存インターフェース8712に送信することができる。
ユニバーサル共存インターフェース8712は、共存違反について無線タイプを検証し(8862)、新しいパラメータセットと共に無線システム8704にメッセージ8864を送信することができ、例えば、特定の無線機を一時的に無効にし異なる周波数にシフトすることなどができる。無線システム8704は、無線パラメータの変更を確認するメッセージ8866で応答することができる。次いで、無線システム8704は、例えば、無線機の無線初期化を示すためにメッセージ8840をプロトコル変換API 8714に送信することによって、アクティブタイプリストをプロトコル変換API 8714で再構成することができる。次いで、無線システム8704は、メッセージ8840をプロトコル変換API 8714に送信することによって無線初期化シーケンス8868を再開することができる。次いで、プロトコル変換API 8714は、無線システム8704へのメッセージ8852を介して初期化シーケンス8868を進み、無線タイプのエニュメレーションが完了したことを示し、無線システム8704との通信が初期化される。
繰り返して、共存マネージャ8708は、他のどのノードが依然としてIoTデバイスと通信しているかを判定するために、良好な近隣機チェック8870を実行してもよい。通信が変わった場合、共存マネージャは、近隣機コマンドリスト変更を判定し(8872)、コマンドリストのローカル変更を(8874)することができる。次いで、共存マネージャ8708は、新しいパラメータのセットと共に再構成メッセージ8876を無線システム8704に送信することができる。無線システム8704は、パラメータの受け入れを確認するメッセージ8878で応答してもよい。本明細書で説明されているように、無線システム8704は、プロトコル変換API 8714を用いて初期化シーケンス8868を繰り返すことができる。
共存マネージャ8708による繰り返しの確認を通じて変更をトリガすることに加えて、他のユニットは通信パラメータの変更を要求することができる。例えば、共存マネージャ8708は、変更要求が近隣機から受信されたと判定することができる(8880)。次いで、共存マネージャ8708は、提案されたパラメータと共に再構成要求8882を無線システム8704に送信することができる。次いで、無線システム8704は、パラメータが受け入れられたことを確認するメッセージ8884で応答する。次いで、無線システム8704は、プロトコル変換API 8714を用いて初期化シーケンス8868を繰り返すことができる。
図89は、一部の実施形態による、他のノードと通信するために共存する複数の無線機を使用するための、IoTデバイス8900に存在し得るコンポーネントの一例のブロック図である。同様の番号が付けられた項目は、図3、図8、および図87に関して説明したとおりである。図8に関して説明したIoTデバイス800、および本明細書で説明される他のIoTデバイスに対して選択されたものとは異なるコンポーネントが、IoTデバイス8900に対して選択され使用されてもよいことに留意されたい。図87に関して説明した無線システム8704は、メッシュ送受信機810、アップリンク送受信機814、またはその両方に使用される無線機に対応し得る。他のノード8706は、メッシュデバイス812、クラウド302内のデバイス、またはその両方を含み得る。
大容量ストレージ808は、本明細書で説明される提携グループ形成を実施するための複数のモジュールを含むことができる。大容量ストレージ808においてコードブロックとして示されているが、モジュールのうちのいずれも、例えば特定用途向け集積回路(ASIC)に組み込まれるなど、ハードワイヤード回路で完全にまたは部分的に置き換えられ得ることが理解されよう。
大容量ストレージ808は、共存する複数の無線機の使用を制御するための共存マネージャ8708を含み得る。ユニバーサル共存インターフェース8712は、例えばプロトコル変換API 8714を介して無線機とインターフェースすることができる。プロトコル抽象化API 8714は、使用中の異なる通信チャネルを追跡し、必要とされる特定のプロトコル用のデータをフレーム単位でパッケージ化することができる。チャネルデータストア8710は、共存マネージャによって判定されたアクティブ通信プランおよび無線機を保持することができる。プロトコルデータストア8716は、プロトコル変換API 8714のために利用可能なプロトコルを格納することができる。通信部8902は、例えばメッシュ送受信機810またはアップリンク送受信機814内の適切な無線機を使用して、プロトコル変換API 8714からのフレームを別のデバイスに送信することができる。
図90は、一部の実施形態による、複数の共存する無線機を管理するようにプロセッサ902に指示するためのコードを含む、例示的な非一時的機械可読媒体9000のブロック図である。プロセッサ902は、バス904を介して非一時的機械可読媒体9000にアクセスすることができる。プロセッサ902およびバス904は、図9に関して説明したプロセッサ902およびバス904と同様の方法で実施することができる。非一時的機械可読媒体9000は、図8の大容量ストレージ808について説明したデバイスを含むこともできるし、光ディスク、USBメモリ(thumb drive)、または任意の数の他のハードウェアデバイスを含むこともできる。
非一時的機械可読媒体9000は、初期帯域計画を判定し、近隣機のアイデンティティおよび識別された近隣機と共に使用され得る通信チャネルを含む近隣機マップを構築するようにプロセッサ902に指示するためのコード9002を含み得る。初期帯域計画は、デバイスの無線機のリストから判定され、どの無線が利用可能であると予想されるか、およびそれらの関連プロトコルを含むことができる。次いで、実際に利用可能な無線機を判定した後に、帯域計画を確定することができる。コード9004は、近隣機および関連帯域の両方を識別する初期共存モデルを判定するようにプロセッサ902に指示するために含まれ得る。無線システムの初期化により、どの無線機および帯域が動作可能であるかの判定が可能になった後、共存モデルを確定させることができる。コード9006は、例えば、外部ユニットによって通知された後、または干渉送信を検出することによって、共存違反が存在するか否かを判定するようにプロセッサ902に指示するために含まれ得る。コード9008は、例えば、共存違反が検出された場合、近隣ユニットの繰り返しチェックがパラメータに調整が必要であることを示している場合、または近隣ユニットからの要求時に、通信を再構成するようにプロセッサ902に指示するために含まれ得る。
コード9010は、例えば、利用可能な通信チャネルをプロトコル変換APIに通知する無線システムによって、プロトコル変換を初期化するようにプロセッサ902に指示するために含まれ得る。コード9012は、データを特定の通信チャネル用のフレームにパッケージ化するようにプロセッサ902に指示するために含まれ得る。コード9014は、関連する通信チャネルを介してフレームを送信するようにプロセッサ902に指示するために含まれ得る。コード9016は、無線動作が変更された後にプロトコル変換機能を再初期化するようにプロセッサ902に指示するために含まれ得る。
図91は、一部の実施形態による、異種ネットワーク(ヘットネット)9100にわたるサービスネットワークオーバーレイ機能の概略図である。この技法により、異種ネットワーク間でサービスチェーンを作成でき、これにより、フォグネットワークまたはメッシュネットワークでのIoTデバイスの自動プロビジョニングおよび再構成が可能になる。例えば、IoTデバイスは、図4に関して説明したように、一時的仮想デバイスまたはフォグデバイスなどのサービスを形成するために機能的にクラスタ化されてもよい。HetNetでは、ネットワーク9100、ドメイン9102および9104は、交差点における交通管制機能などの特定の機能を実行するために一緒にグループ化され得るIoTデバイスを含み得る。デバイスは、任意の数の有線および無線リンク9106を介して、互いに接続し、かつクラウド302と接続することができる。
ネットワークドメイン9102または9104は、ネットワークドメイン9102または9104内のデバイス上で動作するネットワークドメインコントローラ(NDC)9108、またはサービスコーディネータを含むことができる。NDC 9108は、ネットワークドメイン9102または9104に動的に移動されてもよいし、デプロイの前にデバイスに事前にインストールされてもよい。NDC 9108は、上位レベルのオーケストレーションシステム9110と通信することができる。NDC 9108は、サービスに参加することができるユニットまたはコンポーネントを識別するサービスコーディネータとして機能することができる。エンドポイントIoTデバイス、データアグリゲータ、クラウド302内のデバイス、または他のネットワークドメイン9102もしくは9104内のデバイスなど、他のデバイスがサービスコーディネータとして機能し得ることに留意されたい。
サービスを実行するための、またはサービスを実行するためのフォグデバイスを作成するためのサービス管理要求は、オーケストレータ9112からNDC 9108に渡され得る。上位レベルのオーケストレーションシステム9110の一部として示されているが、オーケストレータ9112は、ドメイン9102または9104へのゲートウェイインターフェース、データコンシューマとして機能するサーバ9114などのクラウド内の別のユニット、またはNDC 9108内に配置されてもよい。
オーケストレータ9112内の管理アプリケーションは、ネットワークサービスオーバーレイ9116の作成、更新、削除、および移行を含み得る。ネットワークサービスオーバーレイ9116は、例えば、ある場所から温度を取得すること、または道路に沿った一方向の交通量を増加させることなど、特定のタスクを完了するように設計されたコードセグメントなどのマイクロプログラムとして機能し得る。さらに、ネットワークサービスオーバーレイ9116は、下位レベルのネットワークサービスオーバーレイ9116への複数の呼び出しを含むサービスのためのコードシーケンスを含む上位レベルで機能することができる。
オーケストレータ9112は、サービスまたは仮想サービスネットワークを、関連するネットワークサービスオーバーレイ9116によって完成させることができるネットワークサービス要素に分解することができる。オーケストレータ9116に登録されているNDC 9108は、ネットワークサービスオーバーレイまたは他のドメイン9102または9104内のデバイスなどのリソースを提供して、サービス管理要求のためのサービス要素のうちの1つまたは複数を満たすためにプロバイダ要求をオーケストレータ9112に提出することができる。
NDC 9108がオーケストレータ9112によってサービスコーディネータであると確認応答された後、NDC 9108は、例えばサービスを提供するネットワークサービス要素を管理するなど、サービス要求を満たす責任を負う。本明細書で使用されるように、ネットワークサービス要素は、サービスのためのデータを提供するためのシステムのコード操作コンポーネントであり得る。複数のネットワークサービス要素を一緒にグループ化してサービスを提供することができ、それは図4に関して説明したように、フォグデバイス402とすることができる。ネットワークサービス要素は、ノード9118または9120、ノード9118または9120からの単一のセンサ、データアグリゲータ406などのユニット上で実行されているプログラム、あるいは任意の数の他の物理的デバイスもしくはシステムまたは仮想デバイスもしくはシステムを含み得ることに留意されたい。
例えば、サービスが複数のネットワークドメインからのデバイスを含むとき、第1のドメイン9102内のNDC 9108はまた、第2のドメイン9104内のNDC 9108と通信することができる。NDC 9108は、接続されているデバイスおよび機能を含む、特定のドメイン9102または9104に登録されているノード9118または9120からのリソースなどのデータおよびメタデータを格納するためにデータベース9122を使用することができる。NDC 9108はまた、共有仮想リポジトリ9124を維持することができ、共有仮想リポジトリ9124は、アクションを必要とするネットワークサービス要素をアドバタイズし、ネットワークサービス要素を提供するサービスコンポーネントのアイデンティティを格納する。
NDC 9108は、どのノード9118または9120、あるいはノード9118または9120の組み合わせを使用してサービスの要件を満たすかを選択するために使用する機械学習(ML)エンジン9126を使用することができる。MLエンジン9126は、シミュレーション、ニューラルネットワーク、統計分析、および任意の数の他の技法を使用して、どのコンポーネントがネットワークサービス要素を完成させることができるかを判定することができる。
NDC 9108は、どのノード9118または9120、または他のデバイスがネットワークサービス要素をホストするかを選択するために様々な基準を使用することができる。選択基準としては、レイテンシ要件、特定の帯域幅ニーズ、または信頼性メトリックを挙げることができる。データはデータベース9122に格納され、過去の性能データに基づいてもよい。NDC 9108はまた、複数のエンドノードが同じネットワークサービス要素に対する広告要求を満たすために入札するときにメディエータとして機能することができる。NDC 9108は、オーケストレータ9112によって割り当てられたコンポーネントまたはタスクをパブリッシュする役割を担う。
ネットワーククライアント9128は、ネットワークドメイン9102または9104内の各デバイス、またはノード9118または9120に常駐することができる。それは、ノード9118または9120ならびにセンサ、カメラ、アクチュエータなどのような任意の接続された要素についての情報を提供するために、NDC 9108または他のサービスコーディネータに登録されてもよい。それが提供する情報の種類は、電力、性能、および信頼性の測定値などの性能およびシステム遠隔測定情報を含み得る。ネットワーククライアント9128はまた、性能基準が満たされることを保証するために、ノード9118または9120の動作または構成を変更するために、NDC 9108または他のサービスコーディネータによる制御を可能にする。例えば、NDC 9108は、取り付けられたセンサからデータを収集するためにデューティサイクルを修正することができる。NDC 9108はまた、図3および4に関して説明した、ゲートウェイ310などのネットワークドメイン9102または9104内で通信するエンドノード9118または9120のネットワーキングおよびトランスポート設定を構成することができる。ネットワーククライアント9118は、それが完了することができる任意のネットワークサービス要素について共有仮想リポジトリ9124にサブスクライブするかまたはそれをポーリングすることができる。
仮想共有リポジトリ9124は、実行を必要とするすべてのタスク、例えばネットワークサービス要素のリストを含み得る。ノード9118または9120は、タスクを実行しタスク割り当てを要求するその能力をアドバタイズすることができる。NDC 9108は、要求元ノード9118または9120のルックアップを実行して、それが以前に機能違反をしていないかまたは機能の実行に失敗していないことを保証する。NDC 9108がタスクをノード9118または9120に割り当てることを決定した場合、NDC 9108は仮想共有リポジトリ9124内のタスクを割り当て済みとしてマークする。仮想共有リポジトリ9124は、データベース9122の一部であってもよいし、スタンドアロンシステムであってもよい。
サービスおよびネットワークサービス要素は、単一のノード9118または9120、あるいは単一のドメイン9102または9104にさえ限定されない。例えば、サービスは、ドメイン9102および9104の両方においてノード9118および9120が割り当てられたフォグデバイス9130であり得る。図示のように、フォグデバイス9130は、複数のドメイン9102および9104にわたっており、第1のドメイン9102内のNDC 9108および第2のドメイン9104内のNDC 9108の指示の下でノード9118および9120に提供される。第3のネットワークドメイン9132は、クラウド302を介してアクセスされてもよく、例えば、ネットワークサービス要素としてデータの長期ストレージを提供するためのデータベース9134を含んでもよい。他のドメイン9102、9104、または9132に配置されているノード9118または9120およびデータベース9134などのコンポーネントは、オーケストレータ9112によって識別され、図110から図114に関して説明されるように、共有仮想ドメインに組み込まれてリソースを共有することができる。
ネットワークサービスオーバーレイ9116は、オーケストレータ9112、NDC 9108、または他のコンポーネントによって要求された他の項目も含むことができるタスクおよびコンポーネントの共有リポジトリ9136に格納することができる。ネットワークサービスオーバーレイ9116がノード9118および9120にプッシュされてフォグデバイス9130を形成することに加えて、ノード9118および9120はまた、ネットワークサービスオーバーレイ9116を要求またはプルして、コードやその他の設定情報が必要とされるネットワークサービス要素などのタスクを完了することができる。
図92は、一部の実施形態による、サービスに対する新しい要求を処理するための例示的な方法9200のプロセスフロー図である。図92の方法9200は、図94に関して説明されるIoTデバイス9400によって実施することができる。方法9200は、オーケストレーション要求が、例えばネットワークドメインコントローラまたは他のサービスコーディネータで受信されると、ブロック9202で開始する。ブロック9204において、例えば新しいサービスまたはフォグデバイスを形成するために、サービス要求が新しいか否かに関する判定が行われる。そうでない場合、ブロック9206において、オーケストレーション要求は既存のサービスコーディネータに渡される。例えば、サービス要求は、現在サービスまたはフォグデバイスの目的であるデータまたは情報に対する要求であり得るか、または異なる情報を提供するためにフォグデバイスを別の目的で使用し得る。もしそうであれば、サービスコーディネータは、ノードを追加または削除することによってサービスを修正することができる。さらに、サービスコーディネータまたはサービスコンポーネントは、ネットワークサービス要素の完成を可能にするためにダウンロードされるネットワークサービスオーバーレイを要求することができる。
オーケストレーション要求が新しいサービスに対するものである場合、ブロック9208において、サービスコーディネータが識別され得る。サービスコーディネータは、サービス要求に情報を提供する最大数のノードにサービスを提供するNDCなどの、サービス要求に関連するドメインに位置するNDCであり得る。
ブロック9210において、サービスモデルを準備することができる。サービスモデルは、サービス要求を満たすために使用されるフォグデバイスまたはサービス用の仮想部品リストとみなすことができる。サービスモデルは、どのタイプのネットワークサービス要素、エンドノード、および他のサービスプロバイダがそのサービスに必要であるかを識別することができる。サービスモデルは、サービスコーディネータで構築されてもよいし、オーケストレータで準備されてサービスコーディネータにダウンロードされてもよい。ブロック9212において、サービスコーディネータは、ネットワークサービス要素を準備することができる。これらは、特定のデータ要求、動作などを識別するサービスの部分であり得る。ネットワークサービス要素は、サービスコーディネータ上のデータストア内に既に存在していてもよいし、クラウド内などの別のストアから引き出されるネットワークサービスオーバーレイであってもよい。
ブロック9214において、サービスコーディネータは、個々のエンドポイントノード、データソース、コードなど、特定のネットワークサービス要素を提供することができるサービスコンポーネントの候補を識別することができる。個々のエンドポイントノードは、図93に関して説明されるように、それらのアイデンティティおよび機能をNDCに登録したIoTデバイスであり得る。ブロック9216において、サービスコーディネータは、識別されたサービスコンポーネントにネットワークサービス要素に対するサブスクリプション要求をディスパッチすることができる。
ブロック9218において、サービスコンポーネントは、サブスクリプション要求を確認することができる。これは、サービスコンポーネントがサービス要求内でネットワークサービス要素を実行することができることを保証するために、サービスコンポーネント内に存在し動作可能なセンサおよび他のデバイスへのサービス要求どうしを比較することによって実行され得る。ブロック9220において、サービス要求がサポートされているか否かに関する判定が行われる。サポートされていない場合、ブロック9222において、拒否メッセージがサービスコーディネータに送信される。次いで、サービスコーディネータは、そのネットワークサービス要素を満たすことができるデバイスのリストからサービスコンポーネントを除去し、そのネットワークサービス要素を提供することができる別のデバイスを探すことができる。
サービスコンポーネントがネットワークサービス要素にデータまたは動作を提供することによってサービス要求を満たすことができる場合、ブロック9224において、サービスコンポーネントは、確認メッセージをサービスコーディネータに送信することができ、サービスコーディネータはメッセージをデバイスのリストに追加することができる。本明細書で説明するように、ブロックチェーントランザクションを使用して、サービスコンポーネントをトランザクションに記録し、サービスコンポーネントがグループの一部として通信できるようにグループ識別情報を発行することができる。サービスコンポーネントは、ネットワークサービス要素をローカルストアに実装するためのネットワークサービスオーバーレイを有してもよいし、サービスコーディネータから、またはクラウド内のストアからネットワークサービスオーバーレイをダウンロードしてもよい。
ブロック9226において、サービスコンポーネントは、ネットワークサービス要素に対する動作を実行することができる。これは、サービスコンポーネントに関連する、温度、風速、降水量などのセンサからのデータの収集であり得る。一部の例では、ネットワークサービス要素は、照明をオンまたはオフにすること、コンプレッサを起動して温度を下げることなどのようなアクションを実行するサービスコンポーネントによって完成され得る。
ブロック9228において、サービスコンポーネントはデータまたは確認応答をサービスコーディネータに返す。これは、センサの読み取り値に関連するデータ、または動作が実行されたことの確認などである。
図93は、一部の実施形態による、NDCまたは他のサービスコーディネータにより、エンドポイントまたはサービスコンポーネントを登録するための例示的な方法9300のプロセスフロー図である。図93の方法9300は、図94に関して説明されるIoTデバイス9400によって実施することができる。ブロック9302は、例えば、IoTデバイスまたはエンドポイントノードなどのサービスコンポーネントがローカルサービスコーディネータを検索するときを表す。これは、サービスコンポーネントを含むネットワークドメインで動作しているNDCであってもよい。ブロック9304において、サービスコンポーネントは、接続要求をサービスコーディネータに送信する。サービスコーディネータから確認応答を受信すると、ブロック9306において、サービスコンポーネントは、共有鍵、またはブロックチェーンが生成した鍵などの他の識別情報をサービスコーディネータに送信することができる。サービスコンポーネントがローカルサービスコーディネータに登録されているという確認を受信すると、ブロック9308において、サービスコンポーネントは、サービスコーディネータに、接続されたセンサ、アクチュエータなどのデバイス周辺データを送信することができる。ブロック9310において、サービスコンポーネントが依然として登録されているか否かに関する判定が行われる。登録されていない場合、プロセスフローはブロック9302に戻り、デバイスを再登録することができる。ブロック9312において、サブスクリプション要求がサービスコンポーネントによって受信され得る。サービスコンポーネントがサブスクリプションに作用した後、デバイスが依然として登録されているか否かを判定するためにブロック9312に戻ることができる。サービスコンポーネントがもはや登録されていない場合、プロセスフローは9302に戻ってプロセスを繰り返すことができる。
図94は、一部の実施形態による、サービス要求を調整する、または満たすための、IoTデバイス9400に存在し得るコンポーネントの一例のブロック図である。同様の番号が付けられた項目は、図3、図8、および図91に関して説明したとおりである。図8に関して説明したIoTデバイス800、および本明細書で説明される他のIoTデバイスに対して選択されたものとは異なるコンポーネントが、IoTデバイス9400に対して選択され使用されてもよいことに留意されたい。IoTデバイス9400は、オーケストレータ、NDC、エンドポイントノードであってもよいし、これらのシステムの組み合わせとして機能してもよい。
大容量ストレージ808は、本明細書で説明される提携グループ形成を実施するための複数のモジュールを含むことができる。大容量ストレージ808においてコードブロックとして示されているが、モジュールのうちのいずれも、例えば特定用途向け集積回路(ASIC)に組み込まれるなど、ハードワイヤード回路で完全にまたは部分的に置き換えられ得ることが理解されよう。
大容量ストレージ808は、サービスコーディネータなどの他のユニットにサービス要求を送信するためのオーケストレータ9112を含むことができる。データベース9122は、接続されたデバイスおよび機能を含む、特定のドメインに登録されたノードからのデータ、メタデータ、およびリソースを格納することができる。仮想共有リポジトリ9124を使用して、アクションを必要とするネットワークサービス要素をアドバタイズし、ネットワークサービス要素を提供するサービスコンポーネントのアイデンティティを格納することができる。機械学習エンジン9126を使用して、メッシュデバイス812またはクラウド302内のデバイスなどの、サービスコンポーネントのどれを使用してサービスの要件を満たすことができるかを選択することができる。クライアント9128は、サービスコーディネータに登録して、接続されているデバイスおよび機能に関する情報を提供することができる。クライアント9128は、ネットワークサービス要素9402を満たすためにIoTデバイス9500の可用性をアドバタイズすることができる。クライアント9128は、IoTデバイス9400がネットワークサービス要素9402に対するアクションを完了できることを確認してサービス要求に応答することができる、またはアクションを完了できないことをサービスコーディネータに知らせる拒否を送信することができる。クライアント9128は、サービスコーディネータにアクセスして、ネットワークサービス要素9402を完成するのに必要な任意のネットワークサービスオーバーレイを取得してもよいし、必要なネットワークサービスオーバーレイをダウンロードするためにクラウド302内のストアに直接アクセスしてもよい。
図95は、一部の実施形態による、サービス要求を調整する、または満たすように1つまたは複数のプロセッサ902に指示するためのコードを含む、例示的な非一時的機械可読媒体9500のブロック図である。同様の番号が付けられた項目は、図9に関して説明したとおりである。プロセッサ902は、バス904を介して非一時的機械可読媒体9500にアクセスすることができる。非一時的機械可読媒体9500は、図8の大容量ストレージ808について説明したデバイスを含むこともできるし、光ディスク、USBメモリ(thumb drive)、または任意の数の他のハードウェアデバイスを含むこともできる。
非一時的機械可読媒体9500は、ローカルドメイン内のネットワークドメインコントローラなどのサービスコーディネータを識別するようにプロセッサ902に指示するためのコード9502を含み得る。コード9504は、サービス要求に対してネットワークサービス要素を準備するようにプロセッサ902に指示するために含まれ得る。コード9506は、特定のネットワークサービス要素を提供することができるサービスコンポーネントの候補を識別するようにプロセッサ902に指示するために含まれ得る。コード9508は、サブスクリプション要求を確認するようにプロセッサ902に指示するために含まれ得る。コード9510は、ネットワークサービス要素に対する動作を実行するようにプロセッサ902に指示するために含まれ得る。コード9512は、データまたは確認応答をサービスコーディネータに返すようにプロセッサ902に指示するために含まれ得る。コード9514は、接続要求をサービスコーディネータに送信するようにプロセッサ902に指示するために含まれ得る。コード9516は、接続されているセンサ、アクチュエータなどのようなデバイス周辺データをサービスコーディネータに送信するようにプロセッサ902に指示するために含まれ得る。コード9518は、サブスクリプション要求を他のユニットに送信するようにプロセッサ902に指示するために含まれ得る。これらのユニットがあらゆるデバイスに存在し得ることに留意されたい。例えば、エンドポイントノードは、サービスコーディネータまたはオーケストレータとして機能しなくてもよく、その例では、それらの機能を実行するコードブロック9502、9504、9506、および9518を含まない。
メッシュネットワークは、アクターが極めて低いレイテンシでデータにアクセスすることを望んでいる可能性がある環境において、またはデータが時間的空間的様式で密接に結合されている可能性がある場合に有用である。図4に関して説明したように、交差点の例を使用すると、交差点でのデータ交換は、車両、歩行者、サイクリスト、および交通信号灯または他の路側機などの道路利用者間で極めて大量、高速、かつ多様に行われ得る。交差点の環境は、高速で移動する車両の交通、最小限の固定インフラストラクチャ、および困難であり得る信号伝播条件の場合、特に困難な場合がある。
性能を改善しレイテンシを改善するための1つの手法は、ネットワークデータストレージおよびコンテンツ配信をネットワークの一番エッジで実行することである。これは、データを保持することができ、データを必要とするアプリケーションに近いデバイスにおいて非常に速いアクセスを必要とするデータをキャッシュすることを含み得る。
交差点は、交通管制および他の目的のために複数のアプリケーションを使用することができる。アプリケーションとしては、とりわけ、衝突防止システム、緊急サービス、環境データに基づく運用の変更、小売および広告サービスを挙げることができる。そのデータの大部分は時間的および空間的に依存している。例えば、交通渋滞では、データは、場所と時間に密接に結び付けられる。さらに、データは、交通管制システム、車両、サイクリスト、歩行者、警察、緊急サービスなどの近くのグループによって消費されることを意図していることが多い。
IPアドレスの決定、フレーミング、ハンドシェイキング、および他の通信要件のために、IPベースの技術は、デバイス間の接触時間が非常に短い場合がある環境では不十分に機能する場合がある。本明細書に記載のデータセマンティクス、および他の技術は、データへのアクセスおよびデータの使用を単純化するための手段を提供することができる。これらの技術は、データのユーザが、近接したデバイスからのデータにアクセスすることを可能にし得る。車両はまた、例えば、異なる交差点とシステムとの間でデータを移動させるためのミュール(mule)としても機能し得る。これらの種類の通信に使用され得る1つの技法は、ネットワーク内のデータを記述し、格納し、そしてパブリッシュするために分散ハッシュテーブルを使用することである。
図96は、一部の実施形態による、IoTサービスのための逆分散ハッシュテーブル(DHT)ネットワークのアドホック形成の概略図9600である。IoTサービスは、データの送信または格納を含み得る。DHTネットワークは、様々なノードに送信される断片としてネットワーク内でファイルを記述またはパブリッシュするための固有のハッシュの生成によって形成され得る。ファイルの断片を受け取ったノードは、ファイルの新しいコピーの送信元になる。そのファイルにアクセスすることを望むノードは、それらが完全なファイルを有するまで他のノードからファイル断片をダウンロードする。ノードがファイルの断片を受信し始めると、ファイルを取得しようと望む他のノードにそれらの断片を共有またはシードできる。これにより、ネットワーク内のピア全体にファイルの多数のコピーを配布し、1つの送信元ではなく、多数の送信元から断片をダウンロードするために、新しいピアが迅速にファイルを取得できる、集中管理のないアドホックネットワークが作成される。
一部の態様では、イベントの間のデータ損失の可能性を低くするために、これの逆のバージョンもデータ送信に適用され得る。この例では、図中のノード1などのセンサノードが、大量のデータを生成しているイベントストームを検出する。イベントストームは、緊急事態、交差点における交通量が多いこと、データ収集期間の増大などに対応し得る。ノード1は、第1の通信チャネル9602を介してクラウド302に、またはフォグノード、ゲートウェイもしくは他のなんらかの上流のデータシンクに、データを送信するように進む。しかしながら、第1の通信チャネル9602は、ネットワーク帯域幅が制限されており、すぐに輻輳し、メッセージのバックログがノード1上で待ち行列に入ることを余儀なくされる。待ち行列がクリアされるまでにかなりの時間がかかり、宛先へのメッセージが遅れたり、待ち行列がオーバーフローするとデータが失われることさえある。
しかしながら、逆DHTネットワークに使用される技法では、ノード1は、その近隣ノードのネットワーク容量を使用して、過剰なメッセージ負荷を同じ最終宛先に送信することができる。ノード1は、例えば、輻輳していないネットワークリンク9606を介して近隣ノード1...nを発見することができる。Openfogコンソーシアムの仕様、Alljoyn仕様、および様々なオープンソースアドホックネットワーキングプロトコルを含む他のものなどのメッシュネットワークプロトコルを含む、様々な技法をピア発見に使用することができる。さらに、IPv6のIPプロトコルには、他のネットワークプロトコルと同様に、ピア発見のネイティブサポートが含まれている。
輻輳していないネットワークリンク9606は、とりわけ、Wi-Fi(登録商標)またはBluetooth(登録商標)などの任意の数のネットワークリンクを含み得る。一部の例では、図3に関して説明したように、ノードは有線ネットワークによって結合することができ、一方個々の各ノードはゲートウェイへの無線リンクも有することができる。物理的に近接したノードは、リモートのノードよりも高い帯域幅の接続を持つ可能性があるため、輻輳したノードはファイル断片を周囲のピアに送信し、それらにメッセージを宛先へと経路指定させることができる。
この例では、クラウド302内に位置するデータシンクは、受信したメッセージをそれを送信したノードに確認応答することができ、例えば、ノード2がデータの一部をデータシンクに送信した場合、データシンクはノード2に受信を確認応答することができる。次いで、ノード2は、データシンクによるデータの受信を、データ送信元であるノード1に確認応答する。ノード1は、特定のメッセージの配信時に、ノード2または他のピアなどの任意の送信元から確認応答メッセージ(ACK)を受信すると、配信されたメッセージを考慮し、それを待ち行列から除去することができる。
返されたACKがデータソースによって受信される速度は、フロー制御を可能にし得る。例えば、ノード2が1秒ごとに確認応答を送信し、ノード3が2秒ごとに確認応答を送信している場合、ノード2がより高いメッセージ負荷を処理できることを示し、ノード1は、ノード3よりもノード2に、より多くのメッセージを送信するように動作を調整する。
送信元センサノード、すなわちこの例におけるノード1は、メッセージフローを追跡し、ピアがメッセージの配信に失敗することを可能にするためのメカニズムを実装することができる。例えば、ノード4などのピアノードが送信されたメッセージに対してACKを返さない場合、送信元ノードは構成可能な期間、メッセージを経路指定するのを停止することができる。さらに、ノード4に送信されたあらゆるメッセージが失われたとみなされ、他のピアを介して、またはセンサノードからクラウド302内のデバイスに直接再送信され得る。
図97は、一部の実施形態による、ファイルデータ9702を格納または送信するためにどのノードを使用することができるかを追跡するためのプロセスの概略図9700である。ファイルデータ9702は断片9704~9708に分割されてもよい。ハッシュ関数9710~9714を断片9704~9708のそれぞれに対して実行して、鍵9716~9720を生成することができる。次いで、鍵9716~9620を使用して、ノードの分散メッシュ9722にデータ断片を格納または送信するためにどのノードを使用すべきかを判定することができる。
図98は、一部の実施形態による、ストレージノードまたは送信ノードをターゲットとするための例示的な方法9800のプロセスフロー図である。図98の方法9800は、図100に関して説明されるIoTデバイス10000によって実施することができる。ブロック9802は、例えば、ノードが格納または送信用のファイルを生成するときを表す。ブロック9804において、ファイルに対する新しいファイルの格納または送信要求が生成される。ブロック9806において、ファイルは、例えばデータの送信に使用されるパケットまたはフレームのペイロードサイズに応じて、N個の断片に断片化される。ブロック9808において、各断片についてハッシュが計算され得る。
ブロック9810において、各断片のターゲットストレージまたは送信ノードを識別することができる。これは、断片のハッシュコードから最初のMバイトを抽出することによって実行することができ、ここで、数Mは、メッシュネットワークで使用されるノードIDの長さによって判定され得る。次いで、ハッシュからのバイトは、ノードIDの最初のMバイトとファイル断片ハッシュの最初のMバイトとの間の最も近い一致としてターゲットノードを識別することによってターゲットノードを判定するために使用され得る。次いで、ノードIDは、ファイルアドレステーブルの一部を形成してもよい。ノードIDを知っているため、それが保存または送信を担当するファイル断片の範囲に関する判定がなされ得る。IDが厳密に一致するノードの場合、不安定なネットワーク環境など、ノードの可用性が保証されていない場合は、この手法によって冗長性が高まる可能性がある。ブロック9812において、断片は、パケットまたはフレームにパッケージ化されて、ターゲットストレージまたは送信ノードに送信される。
ブロック9814において、プロセスを続行するか否かに関する判定が行われる。プロセスは、データのストレージが終了したときに終了してもよいし、他のノードによって送信されているすべての断片についてACKが受信されるまで待機してもよい。
図99は、一部の実施形態による、分散ハッシュテーブル(DHT)を使用してデータを格納または送信するための例示的な方法9900のプロセスフロー図である。図99の方法9900は、図100に関して説明されるIoTデバイス10000によって実施することができる。ブロック9902は、例えば、デバイスの電源が入ってアドホックネットワークに参加したときを表す。ブロック9904において、長さがnビットのノードIDが計算または取得される。これは、とりわけ、本明細書で説明されるようにブロックチェーンから割り当てられるID、製造業者によって割り当てられるID、または乱数発生器から計算されるIDであり得る。
ブロック9906において、入ってくるストレージまたは送信要求に対する待機期間が実施される。待機期間が完了すると、ブロック9908において、データがストレージまたは送信のために受信されたか否かに関する判定が行われる。そうでなければ、プロセスフローは別の待機期間のためにブロック9906に戻る。
ブロック9908でデータが受信された場合、ブロック9910において、受信されたデータに対して鍵が生成される。これは、受信したデータについてハッシュ関数を計算することによって実行することができる。
ブロック9912において、鍵およびデータは、ローカルに格納される、または送信される。これは、データをノードに格納または送信し、次にノードIDを鍵の前に付けることによって実行され得る。結果として得られる鍵は、とりわけ、リスト、テーブル、キュー、またはデータベースなどのローカルストアに格納することができる。
ブロック9914において、プロセスを続行するか否かに関する判定が行われる。これは、現在のシーケンスについてより多くのデータが予想されるか否かに関する判定に基づいてもよい。そうである場合、プロセスフローはブロック9908に戻り、データが格納または送信のために受信されたか否かを判定する。そうでない場合、プロセスはブロック9916で終了する。
図100は、一部の実施形態による、サービス要求を調整する、または満たすための、IoTデバイス10000に存在し得るコンポーネントの一例のブロック図である。同様の番号が付けられた項目は、図3および図8に関して説明したとおりである。図8に関して説明したIoTデバイス800、および本明細書で説明される他のIoTデバイスに対して選択されたものとは異なるコンポーネントが、IoTデバイス10000に対して選択され使用されてもよいことに留意されたい。他のノードは、メッシュデバイス812、クラウド302内のデバイス、またはその両方を含み得る。
大容量ストレージ808は、本明細書で説明される提携グループ形成を実施するための複数のモジュールを含むことができる。大容量ストレージ808においてコードブロックとして示されているが、モジュールのうちのいずれも、例えば特定用途向け集積回路(ASIC)に組み込まれるなど、ハードワイヤード回路で完全にまたは部分的に置き換えられ得ることが理解されよう。大容量ストレージ808は、パケットまたはフレームのペイロードフィールド内に収まるようにデータファイルを断片化するためのデータ断片化部10002を含み得る。ハッシュ計算部10004は、ハッシュ鍵を計算して、データのための格納ノードまたは送信ノードを識別することができる。
メッセージ生成部10006は、ハッシュ鍵を使用してデータの格納または送信のためのノードIDを判定することができる。メッセージ生成部10006はまた、例えば、データ断片をパケットまたはフレームのペイロードフィールドにパッケージ化するなど、格納または送信のために別のノードに送信するためにデータ断片をフォーマットしてもよい。
通信部10008は、格納または送信のためにパッケージ化されたデータ断片を別のノードに送信することができる。送信のために、通信部10008はまた、メッシュデバイス812などの別のノードから確認応答を受信し、確認応答がクラウド302内のデバイスなどの上流の宛先からのものであるか否かを判定し得る。データ追跡部10010は、確認応答を使用して、データが送信ノードからターゲットデバイスに送信されたのか、または再送信する必要があるのかを判定することができる。データ追跡部10010はまた、例えば他のノードから入ってくる確認応答のレートに基づいてフロー制御を実施することができる。ストレージでは、データストア10012は、データ断片の位置およびアイデンティティと共に鍵を保存することができる。鍵は、格納されたデータを保持している、ノードまたはメッシュデバイス812のIDの前に断片のハッシュコードを付加することができる。
図101は、一部の実施形態による、サービス要求を調整する、または満たすように1つまたは複数のプロセッサ902に指示するためのコードを含む、例示的な非一時的機械可読媒体10100のブロック図である。同様の番号が付けられた項目は、図9に関して説明したとおりである。プロセッサ902は、バス904を介して非一時的機械可読媒体10100にアクセスすることができる。非一時的機械可読媒体10100は、図8の大容量ストレージ808について説明したデバイスを含むこともできるし、光ディスク、USBメモリ(thumb drive)、または任意の数の他のハードウェアデバイスを含むこともできる。
非一時的機械可読媒体10100は、ファイルを断片に分割するようにプロセッサ902に指示するためのコード10102を含み得る。コード10104は、各断片についてハッシュコードを計算するようにプロセッサ902に指示するために含まれ得る。コード10106は、各断片についてターゲットストレージまたは送信ノードを識別するようにプロセッサ902に指示するために含まれ得る。コード10108は、データ断片をターゲットノードに送信するようにプロセッサ902に指示するために含まれ得る。コード10110は、ノードIDを計算するようにプロセッサ902に指示するために含まれ得る。コード10112は、ストレージのための鍵を生成するようにプロセッサ902に指示するために含まれ得る。コード10114は、鍵およびハッシュを格納するようにプロセッサ902に指示するために含まれ得る。
異なるノードによる通信は、同じ種類の通信チャネルを介して行われる必要はない。アプリケーション要件に応じて、異なる通信経路、周波数などが使用されてもよい。図102~図105に関して説明したように、適切なトラフィック経路がデータに対して選択され得る。これらの技法は、高いレイテンシから低いレイテンシ間まで、およびコネクション型からコネクションレス型までの範囲にわたるアプリケーション要件に対処するために使用される異なるパスまたはパスの組み合わせの選択を可能にする。これは、マルチパス伝送制御プロトコル(TCP)を超えてトランスポート選択および使用基準を拡張する。
図102は、一部の実施形態による、2つのエンドポイント10202および10204間の3つの例示的な経路を示し、それが潜在的な使用に利用可能であり得る、マルチ経路通信システムの概略図である。この例では、経路は、衛星アップリンク10206、インターネットバックボーンすなわち有線接続10208、およびLTE接続10210を含む。しかしながら、図8に関して説明した無線接続のうちの任意のもの、ならびに光ファイバ、マイクロ波、および他の接続を含む、任意の数の有線または無線接続を2つのエンドポイント間で使用することができる。
データパスの選択は、転送されるデータ量、データパスの信頼性、通信速度などに依存し得る。例えば、有線接続10208が失われるか利用不可能である場合、エンドポイント10202は、アプリケーション要件に基づいて代替通信パス10206または10210を選択することができる。
図103は、一部の実施形態による、通信経路を選択するための例示的な方法10300のプロセスフロー図である。図103の方法10300は、図104に関して説明されるIoTデバイス10400によって実施することができる。複数の通信パスが並列に使用され得ることに留意されたい。ブロック10302は、例えば、とりわけ、デバイスに電源が投入されたとき、または複数の通信パスの使用を可能にするネットワークサービスオーバーレイがダウンロードされたときを表す。
ブロック10306において、デバイス上の利用可能なネットワークインターフェースが発見される。これは、lfconfigまたはipconfigなど、接続されているネットワークインターフェースを一覧表示するために使用され得る構成コマンドを使用して実行できる。最初のlfconfigは、ネットワークインターフェースを初期化するために一部のオペレーティングシステムによって使われ得るUnix(登録商標)タイプのコマンドである。2番目のipconfigは、例えばApple製、Microsoft製のシステムを含む、複数のオペレーティングシステムで使用され得るコマンドであり、システム内のインターフェースを含め、現在すべてのTCP/IP設定値を表示できる。
ブロック10306において、アクティブネットワークインターフェースを介したエンドポイント間の利用可能な経路が発見される。利用可能な経路の数は、潜在的に異なるトポロジ、セキュリティクレデンシャル、および各個々のネットワークインターフェースによってサポートされるプロトコルのために、ネットワークインターフェースの数よりも大きくなり得る。これは、例えば、論理チャネルを発見すること、最後に知られているアクティブ経路を取得することなどによって実行され得る。発見された経路は経路データベースに保存されてもよい。経路データベースは、とりわけ、デバイス上、リモートサーバ上、またはメッシュネットワーク内の別のデバイス上に配置することができる。リモート接続されたデータベースは、メッシュネットワーク内のデバイス上または別のデバイス上にあり得る1つまたは複数のデバイスによって使用され得る。
ブロック10308において、経路はランク付けされ得る。ランク付けプロセスは、例えば、期待される、または過去のサービス品質、容量、コスト、レイテンシによって経路を順序付けることを含み得る。更新された経路情報は経路データベースに格納されてもよい。
ブロック10310において、経路指定要求が受信されたか否かに関する判定が行われる。受信されていない場合、プロセスフローはブロック10306に戻る。経路指定要求が受信された場合、ブロック10312において、経路指定戦略が計算される。経路指定戦略は、最良QoS経路指定、最小コスト経路指定、最小レイテンシ経路指定などのローカルポリシーの目的によって指示することができる。
経路指定戦略は、単一の最良経路が使用されるべきか否かに関する判定によりブロック10314で開始することができる。もしそうであれば、ブロック10316において、例えば経路データベース内のランク付け情報から判定される、コスト、信頼性、レイテンシなどの所望の経路特性に基づいて単一の経路が選択される。複数の経路戦略が選択される場合、ブロック10318において、経路データベース内の複数の経路が、例えば転送のための総データ、信頼性などに基づいて使用のために選択され得る。
ブロック10320において、選択された経路を介したデプロイのためにパケットまたはフレームが準備される。これは、選択された経路に使用されるパケットまたはフレームのペイロード内に収まるサイズにデータを断片化することによって実行され得る。次いで、断片は、選択された経路のパケットまたはフレームにパックされる。
ブロック10322において、パケットは選択された経路を介してターゲットにディスパッチされる。ブロック10324において、使用された異なる経路について性能に関する統計が収集され、ブロック10326において、性能に関する統計に基づいて経路データベース内の経路ランキングが更新され得る。性能に関する統計は、例えば、ディスパッチが所与の経路で成功したか否か、および経路についてのパケット誤り率、レイテンシ、経路の信頼性、再試行回数、総データ転送量などを含むことができる。
ブロック10328において、プロセスを続行するか否かの判定が行われる。例えば、オーケストレータまたはサービスコーディネータが、マルチ経路通信がもはや必要ではないと判定することができる。複数の経路通信を続行する場合、プロセスフローはブロック10310に戻り、別の経路指定要求を待つ。そうでなければ、方法10300はブロック10330で終了する。
図104は、一部の実施形態による、複数の通信チャネルを介してデータを送信するためにIoTデバイス10400に存在し得るコンポーネントの一例のブロック図である。同様の番号が付けられた項目は、図3および図8に関して説明したとおりである。図8に関して説明したIoTデバイス800、および本明細書で説明される他のIoTデバイスに対して選択されたものとは異なるコンポーネントが、IoTデバイス10400に対して選択され使用されてもよいことに留意されたい。
大容量ストレージ808は、本明細書で説明される経路判定を実施するための複数のモジュールを含むことができる。大容量ストレージ808においてコードブロックとして示されているが、モジュールのうちのいずれも、例えば特定用途向け集積回路(ASIC)に組み込まれるなど、ハードワイヤード回路で完全にまたは部分的に置き換えられ得ることが理解されよう。
大容量ストレージ808は、存在するネットワーク接続を識別し、IoTデバイス10400からメッシュデバイス812またはクラウド302内のデバイスなどのエンドデバイスまでの経路または通信チャネルを判定する、経路発見部10402を含み得る。経路ランク付け部10404は、例えば、伝送レート、信頼性、および他の性能に関する統計に基づいて、経路をランク付けすることができる。経路データベース10408は、経路、ランキング、および関連する性能に関する統計を格納することができる。経路データベース10408は、通信チャネルのためのプロトコル、チャネルのためのアクセス情報およびクレデンシャルなどの他の関連情報を格納するために使用され得る。
経路計算部10406は、IoTデバイス10400からエンドポイントへデータを送信するための1つまたは複数の経路を判定することができる。経路計算部は、経路データベース10408内の経路およびランキングに格納されている情報を使用することができる。
データ準備部10410は、経路計算部10406から情報を受け取り、選択された1つまたは複数の経路を介して送信されるパケットまたはフレームなどのデータを準備することができる。準備は、異なる経路に関連するパケットまたはフレームのペイロードフィールドに収まるようにデータを断片化すること、およびデータをパケットまたはフレームにパッケージ化することを含み得る。通信部10412は、メッシュ送受信機810またはアップリンク送受信機814などの送信機を介して、またはネットワークインターフェースコントローラ816を介したインターネットを介して、パケットまたはフレームをターゲットデバイスに送信することができる。
性能モニタ10414は、通信チャネルに関する性能データを収集する。性能モニタ10414は、経路データベース10408に保存されている経路ランキングを更新することができる。性能モニタ10414はまた、例えば、所定の期間内におけるターゲットデバイスからの確認応答の欠如に気付くことによって、経路が役に立たなくなったときに気付き、次いで、フレームを再送信し、経路データベース10408において潜在的に不適切であるとして経路にフラグを立てる。経路発見部10402は、フラグが立てられた経路を定期的にチェックして、それが再確立されたか否かを判定することができる。
図105は、一部の実施形態による、複数の通信チャネルを介してデータを送信するようにプロセッサ902に指示するためのコードを含む、非一時的機械可読媒体10500のブロック図である。プロセッサ902は、バス904を介して非一時的機械可読媒体10500にアクセスすることができる。プロセッサ902およびバス904は、図9に関して説明したとおりであり得る。非一時的機械可読媒体10500は、図8の大容量ストレージ808について説明したデバイスを含むこともできるし、光ディスク、USBメモリ(thumb drive)、または任意の数の他のハードウェアデバイスを含むこともできる。
非一時的機械可読媒体10500は、ネットワークインターフェースを発見するようにプロセッサ902に指示するためのコード10502を含み得る。コード10504は、発見されたネットワークインターフェースを使用してエンドポイントデバイスへの利用可能な経路を発見するようにプロセッサ902に指示するために含まれ得る。コード10504は、通信速度、信頼性などの様々な性能に関する統計によって経路をランク付けすることができる。コード10506は、とりわけランキングを使用して、経路または経路のグループにわたるデータファイルの経路指定戦略を計算するようにプロセッサ902に指示するために含まれ得る。コード10508は、例えば、通信チャネルに関連するパケットまたはフレームのデータフィールドに収まるサイズにデータファイルを断片化することによって、デプロイのためにデータを準備するようにプロセッサ902に指示するために含まれ得る。コード10510は、選択された1つまたは複数の経路を介してターゲットデバイスにパケットまたはフレームを送信するようにプロセッサ902に指示するために含まれ得る。
コード10512は、受信および確認応答のための時間、確認応答の受信失敗などを含む経路の性能に関する統計を収集するようにプロセッサ902に指示するために含まれ得る。コード10514は、経路について収集された性能に関する統計に基づいてランキングを更新するようにプロセッサ902に指示するために含まれ得る。本明細書に開示された技法は、IoTネットワーク、および他の種類のメッシュネットワークにおける輻輳管理を提供するのに役立ち得る。
図106は、一部の実施形態による、ドメイン間のセキュアな通信および変換のためのIoTゲートウェイ10600の概略図である。IoTネットワークは異種ネットワークであり、異なるドメインやプロトコルが複数の層で機能している。これらのドメインを越えて通信するために、IoTフレームワークはセッションおよびアプリケーションレベルのプロトコルならびにデータモデルを定義する場合がある。しかしながら、エンドツーエンドのデータ保護では、IoTフレームワークと互換性がないことが多い暗号化および署名フォーマットを使用し、変換にゲートウェイを使用する。ゲートウェイ戦略では、プロトコル変換ロジックを含むプラグインを使用することがある。しかしながら、IoTゲートウェイは、プロトコル変換、セキュリティ変換、およびセマンティック変換を単一のIoTゲートウェイに統合することはできない。
イングレスデータ10602は、インターネットなどの第1のドメインすなわちクラウドからIoTゲートウェイ10600に入ることができる。本明細書で説明される例では、イングレスデータ10602は、第1のプロトコルP1 10604内にあり、第1のセキュリティレベル10606を有し、第1のセマンティック表現10608を使用してデータおよびデバイスを表すことができる。下流のデバイスと互換性があるために、IoTゲートウェイ10600を出るエグレスデータ10610は、第2のプロトコル10612内にあり、第2のセキュリティレベル10614を有し、第2のセマンティック表現10616を使用することができる。
IoTゲートウェイ10600は、IoTゲートウェイ10600への攻撃によって引き起こされる破損したデータから上流および下流のデバイスを保護するためにトラステッド実行環境(TEE)10618を使用することができる。TEE 10618は、セキュアブート環境、コードの実行前確認、分離実行、リモートアテステーション、セキュアストレージ、セキュアプロビジョニング、トラステッドパスなどを実装することができる任意の数の異なるセキュリティ技法を含むことができる。例えば、トラステッドコンピューティンググループ(TCG)によって公表された仕様に準拠する任意の数のシステムを使用することができる。
イングレスデータ10602は、イングレスパケットまたはフレームからペイロードを取り外すためにプロトコル変換部10620において処理され得る。これは、第1のプロトコルプラグイン10622を使用してIoTゲートウェイ10600によって実行され得る。次いで、イングレスデータは、処理のためにセキュリティ変換部10624に渡されてもよい。
セキュリティ変換部10624において、第1のセキュリティプラグイン10626を使用して、生体認証的に暗号化されたペイロードについてのイングレスデータを分析することができる。セキュリティ変換ポリシー10628がバイオメトリック符号化パッケージの復号を可能にする場合、ペイロードは復号され得る。第1のセキュリティプラグイン10626は、バイオメトリックペイロードに限定されない。例えば、イングレスデータ10602内のペイロードは、1024ビットなどの第1のセキュリティレベル10606で暗号化され得る。セキュリティ変換ポリシー10628が許可する場合、エグレスデータ10610に対して512ビット、2048ビットなどの第2のセキュリティレベル10614を使用して、後で暗号化するためにペイロードを復号することができる。セキュリティ変換ポリシー10628は、復号プロセスおよび暗号化プロセスのための鍵を有してもよく、セキュリティレベルの最大不一致に対する制限を設定することができ、例えば、イングレスデータ10602とエグレスデータ10610との間の1024から2048ビットの変更を可能にするが、とりわけ2048から512ビットへの変更をブロックする。
セマンティック変換部10630を使用して、イングレスデータ10602内のペイロードのセマンティック表現をエグレスデータ10610内のペイロードに使用されるセマンティック表現に変換することができる。これは、例えば、ペイロードをHTMLなどの第1のセマンティック表現10608から中間状態に変換するために第1のデータセマンティクスプラグイン10632を使用し、次いで、データを中間状態からXMLなどの第2のセマンティック表現10616へ変換するために第2のデータセマンティクスプラグイン10634を使用することを含むことができる。多くの異なるセマンティック表現が使用されてもよく、プラグインは必要な変換に基づいて選択されてもよい。一部の例では、単一の第1のデータセマンティクスプラグイン10632は、2つの異なる第2のデータセマンティクスプラグイン10634と対にされ得る。これは、異なるIoTネットワークからのデータが、クラウド内のデータベースなどの共通の送信元またはシンクからIoTゲートウェイ10600を通過している場合に有用であり得る。データの発信元および宛先に応じて、変換10636は双方向であり得る。セマンティック変換部10630は、単一のプラグインを有することができ、それによってセマンティック表現10608と10616との間の直接変換が可能になる。
セマンティック変換が完了すると、エグレスデータ10610のペイロードは、エグレスデータ10610のセキュリティレベルS2 10614への変換のためにセキュリティ変換部10624に渡される。これは、セキュリティ変換ポリシー10628によって許可されているように、第2のセキュリティプラグイン10638内のペイロードをエグレスデータセキュリティレベル10614に暗号化することを含み得る。例えば、ペイロードは、イングレスデータ10602とは異なるビットレベルで暗号化されてもよい。ペイロードを保護するためにバイオメトリックマーカが使用された場合、データはシミュレーションされたバイオメトリックマーカを使用して再保護されてもよい。
セキュリティ変換10640が完了した後、エグレスデータ10610のためのペイロードは、プロトコル変換部10620に渡される。プロトコル変換部10620では、第2のプロトコルプラグイン10642を使用して、エグレスデータ10610のためにペイロードをプロトコルP2 10612にパッケージ化する。これは、下流のデバイスへの送信経路のプロトコルと一致するパケットまたはフレームのペイロードフィールドにエグレスデータ10610をパッケージ化することを含み得る。エグレスデータ10610のためのペイロードが特定のパケットまたはフレームのペイロードフィールドに対して大きすぎる場合、それは断片化され、複数のパケットまたはフレームにパッケージ化され得る。プロトコル変換10644は、エグレスデータ10610を形成するためのイングレスデータ10602の処理を完了する。次いで、エグレスデータ10610は、下流のデバイスに送信される。
適応性を提供するために、他のユニットがIoTゲートウェイ10600に存在してもよい。例えば、プラグインインストーラ10646は、プラグインを確認し適切な変換部10620、10624、または10630にインストールすることができる。確認プロセスは、トラステッドプラットフォームモジュール(TPM)、または他のシステムを使用してプラグインの測定値を取得すること(例えば、ハッシュコードを計算すること)と、測定値を許容値のホワイトリストと比較することと、を含み得る。
プラグインで使用されるスクリプトをコンパイルするために、スクリプトコンパイラ10648を含めることができる。これは、とりわけビデオフィードなどの、高速かつ高帯域幅の要件を有するアプリケーションに役立ち得る。
すべてのペイロードが3つすべてのレベルで処理されるわけではないことに留意されたい。例えば、イングレスデータ10602内のペイロードは、イングレスフレームからペイロードを取り外すために処理され、次いで、エグレスフレームにパッケージ化されるように直接処理され、エグレスデータ10610として送信されてもよい。他の例では、セマンティック変換は使用されないこともある。これらの例では、ペイロードがイングレスフレームから取り外された後、セキュリティ変換10640が実行されてよく、ペイロードは、それをエグレスデータとして送信する前に、エグレスフレームにパッケージ化するためにプロトコル変換部10620に返される。イングレスネットワークおよびエグレスネットワークのパラメータに応じて、変換機能の任意の組み合わせを使用することができる。
リソース分割方式は、複数の仮想クライアントを含み得ることに留意されたい。データと共にゲートウェイ変換を処理し、第1の仮想IoTクライアントから第1の仮想IoTサーバへのイングレスおよびエグレスを制御するために使用されるリソースは、第2の仮想IoTクライアントから第2の仮想IoTサーバへのデータ転送を制御するためのリソースから分離され得る。このプラットフォーム分割方式は、TEE「チャネル」内でクライアントとサーバとの間で鍵を交換することを含み得る。一般に、チャネルの一方の側にある仮想クライアントは、同じチャネルの他方の側にある仮想サーバによって使用される鍵を交渉する。このようにして、セキュリティセマンティクスおよびセキュリティレベルは、ブリッジされている異なるIoTネットワーク間でも維持され得る。リソースの分割および割り当ては、仮想クライアントと仮想サーバとが相互作用し得る「チャネル」というゲートウェイの概念と一致し得る。
この例には、仮想クライアントと仮想サーバとがセキュリティレベルを持つセキュアなチャネルを介して通信し得るゲートウェイ抽象化が含まれる。例えば、Intel(登録商標)の仮想化技術(VT-XおよびVT-d)、またはIntel(登録商標)のSGX(ソフトウェアガードエクステンション)に基づいて、異なるシステムリソース分割および割り当て方式を使用することができる。リソースの分割および割り当ては、すべての鍵、通信、および処理が適切なセキュリティレベルで実行されるように、ゲートウェイのチャネルと一致させることができる。
さらに、セキュリティレベルを記述するセキュリティポリシーは、イングレスチャネルおよびエグレスチャネルに関連付けられてもよく、第1のチャネルは第1のセキュリティレベルにあり、第2のチャネルは第2のセキュリティレベルにある。例えば、第1のセキュリティレベルは1024ビットの暗号化を用いてデータを暗号化することを含み、第2のセキュリティレベルは256ビットの暗号化を用いてデータを暗号化することを含み得る。ハードウェア分割方式は、割り当てられたセキュリティレベル以上のチャネル分離を施行するのに十分であり得る。
さらに、セキュアブートスキームまたはトラストブートスキームは、トラステッドプラットフォームモジュール(TPM)、またはIntel(登録商標)TXT、Intel(登録商標)SGX、またはARM(登録商標)Trustzoneなどの他のトラステッド実行環境スキームに従って、ハードウェア分割方式が有効かつ検証可能かつアテステーション可能であることを保証し得る。
図107は、一部の実施形態による、セキュアなIoTゲートウェイにおいてワークロードを変換するための例示的な方法10700のプロセスフロー図である。図107の方法10700は、図108に関して説明されるIoTデバイス10800によって実施することができる。ブロック10702は、例えば、ワークロードが変換のためにゲートウェイに到着したときを表す。ブロック10704において、イングレスデータが、イングレスペイロードを取得するために、イングレスプロトコルを使用して処理される。
ブロック10706において、イングレスペイロードがバイオメトリックストリームであるか否かに関する判定が行われる。もしそうであれば、ブロック10708において、バイオメトリックは、プライバシーセンシティブなコンテンツについて分析され得る。
ブロック10710において、イングレスペイロードがプライバシーセンシティブであるか否かに関する判定が行われる。そうである場合、ブロック10712において、例えばイングレスペイロードを復号するために、イングレスプライバシーポリシーが適用され得る。例えば、UUIDなどの第1のアイデンティティを有するIoTオブジェクトは、アイデンティティの開示を制限するポリシーを有し得るが、それは、第1のアイデンティティが、外部システムによって使用されて、このゲートウェイまたは他のゲートウェイを使用する複数の相互作用が追跡されて、追跡情報が、差分分析を使用してさらに分析可能な接続グラフまたは機械学習表現を構築するために使用され得るようにされる場合があるためである。プライバシーポリシーは、追跡、協調、またはUUIDに基づく他の分析を回避するために、第1のUUIDを第2のランダムに生成されたUUIDで置き換えるように変換部に命令することができる。
ポリシーは、差分分析を用いたデータのさらなる分析により、他のオブジェクトから得られた他のデータ値との統計的相関を明らかにし得るように、フィンガープリントをとることができるオブジェクトデータ値をさらに検出することができる。これは、内部の挙動、プロセス、および決定から生じる可能性がある推論をブロックするために使用され得る。プライバシーポリシーモジュールは、問題のデータ値を、より低い粒度、より低い分解能、より大きな抽象化、またはより大きな一般性を有する別のものに置換させることができる。プライバシーポリシーモジュールは、ゲートウェイインターフェースを介して要求されたデータ値を供給することを単に拒否することができる。
プライバシーポリシーは、データを認証、認可、または他の方法で保護するためにゲートウェイによって使用されるクレデンシャルに、EPID秘密鍵を使用するようにさらに命令することができる。EPID鍵の選択は、番号を付けることができる、あるいは複数のインスタンスがプライバシーポリシーを満たす、個人、グループ、または物のコミュニティ、人々、デバイス、または概念と一致してもよい。例えば、番号付きインスタンスの母集団に基づく匿名性の程度は、プライバシーの差分分析が統計的に関連性のある知識の推論に集中するのを妨げる可能性がある。
ブロック10714において、イングレスペイロードがセキュリティセンシティブであるか否か、例えば暗号化されているか否かに関する判定が行われる。もしそうであれば、ブロック10716において、例えば処理のためにペイロードを復号するためにイングレスセキュリティポリシーが適用され得る。
ブロック10718において、イングレスペイロードがエグレスネットワークと意味的に非互換性であるか否かに関する判定が行われる。そうである場合、ブロック10720において、例えば、イングレスペイロードを意味的に中間の表現すなわちIoTゲートウェイ表現に変換し、次いで、意味的に中間の表現をエグレス表現に変換するために、セマンティック変換が実行される。一部の例では、イングレス表現は、変換時間を短縮するためにイングレス表現からエグレス表現に直接変換され得る。これは、とりわけ、高帯域幅を有するデータに対して、または両方のフォーマットが非常に一般的であるときに実行され得る。
ブロック10722において、エグレスペイロードがセキュリティセンシティブであるか否か、例えば、ポリシーはエグレスネットワークのための暗号化を要求するか否かに関する判定が行われる。そうである場合、ブロック10724において、エグレスセキュリティポリシーが適用される。エグレスペイロードは、セキュリティポリシーによって要求されるビットレベルで暗号化されてもよい。
ブロック10726において、エグレスペイロードがプライバシーセンシティブであるか否かに関する判定が行われる。もしそうであれば、ブロック10728において、エグレスプライバシーポリシーが適用される。ブロック10730において、エグレスペイロードがバイオメトリックストリームの一部であるか否かに関する判定が行われる。もしそうであれば、プライバシーポリシーに従って生成された合成バイオメトリックストリームがペイロードを保護するために使用される。
ブロック10734において、エグレスペイロードがエグレスプロトコルに従って処理され、例えば、エグレスパケットまたはフレームのデータフィールドにパックされる。次いで、エグレスパケットまたはフレームは、エグレスネットワークを介してターゲットデバイスに送信される。
方法10700はまた、変換機能のためにIoTゲートウェイを準備するための複数の動作を含み得る。ブロック10736において、プラグインインストーラは、プロトコル、プライバシー、セキュリティ、およびセマンティックの変換に使用されるプラグインを含む、イングレスネットワークとエグレスネットワークとの間の変換プロファイルを識別することができる。イングレスネットワークおよびエグレスネットワークの識別および発見は、IoTゲートウェイで実行されてもよいし、クラウド内に配置されたデータベースなどの別のデバイスで実行されてもよい。別のデバイスがネットワークカタログを持っている場合、IoTゲートウェイのプラグインインストーラはプラグインのリストを受け入れ、次いでプラグインをダウンロードしIoTゲートウェイにインストールすることを試みることができる。
ブロック10738において、各プラグインは、例えば、とりわけ、IoTゲートウェイに対するプラグインの真正性、完全性、バージョン、および互換性に関して確認される。ブロック10740において、プラグインが確認に失敗したと判定された場合、プロセスフローはブロック10736に戻り、そのプラグインの代わりを見つける。代わりが見つからない場合は、警告メッセージが送信され得る。
ブロック10742において、スクリプトコンパイラまたは他のポリシーシステムは、どの変換ルーチンが解釈済みコードを使用して実行され得、そしてどれがバイナリコードへのコンパイルによって加速され得るかを判定し得る。ブロック10744において、変換スクリプトのそれぞれをコンパイルすることができるか否かに関する判定が行われる。もしそうであれば、ブロック10746において、変換スクリプトはコンパイルされそしてバイナリコードファイルとしてリンクされる。ブロック10748において、セキュリティポリシーおよびプライバシーポリシーが構成される。処理フローはブロック10702に戻り、変換ワークロードを開始する。
プロセスフローは、システムを再構成するために必要に応じて構成ブロック10736から10748に戻ることができる。これは、新しいネットワークがIoTゲートウェイに結合されているとき、または古いネットワークがIoTゲートウェイから切り離されたときに実行され得る。さらに、新しいプライバシー、セキュリティ、またはセマンティックの変換がペイロードに使用されることになっているときに、再構成を実行することができる。
図108は、一部の実施形態による、ドメイン間でワークロードを変換するためにIoTゲートウェイ10800に存在し得るコンポーネントの一例のブロック図である。同様の番号が付けられた項目は、図3、図8、および図106に関して説明したとおりである。図8に関して説明したIoTデバイス800、および本明細書で説明される他のIoTデバイスに対して選択されたものとは異なるコンポーネントが、IoTゲートウェイ10800に対して選択され使用されてもよいことに留意されたい。
IoTゲートウェイ10800は、例えば、2009年にISO/IEC 11889としてTrusted Computing Groupによって公表された仕様に準拠する、トラステッドプラットフォームモジュール(TPM)10802を含むことができる。TMP 10802は、暗号化プロセッサ(CP)10804、不揮発性メモリ(NVM)10806、およびセキュアメモリ(SM)10808を含み得る。CP 10804は、とりわけ、乱数発生器、RSAハッシュ発生器、SHA-1ハッシュ発生器、および暗号化-復号エンジンを提供することができる。NVM 10806は、例えばとりわけRSA鍵を含む、製造時にプログラムされた鍵を含み得る。SM 10808は、ソフトウェアで得られた測定値をプラットフォーム構成レジスタに保持することができる。本明細書で使用される場合、測定値は、ストレージ808またはメモリ804に格納されたコードまたはデータセグメント上で計算されたハッシュコードである。ブートコードセグメントの測定から開始して、図106に関して説明したように、初期ブートから信頼チェーンを作成することによって、測定を使用してトラステッド実行環境10618を確立することができる。
大容量ストレージ808は、本明細書で説明される変換機能を実施するための複数のモジュールを含むことができる。大容量ストレージ808においてコードブロックとして示されているが、モジュールのうちのいずれも、例えば特定用途向け集積回路(ASIC)に組み込まれるなど、ハードワイヤード回路で完全にまたは部分的に置き換えられ得ることが理解されよう。
大容量ストレージ808は、コードまたはデータに対して測定を実行するセキュアなブート部/測定部10806を含み得る。本明細書で説明されるように、測定は、コードまたはデータのハッシュコードの生成であり得る。ハッシュコードは、コードまたはデータが実行または送信される前に予想測定値と比較され得る。追加の測定を実行するようにセキュアなブート部/測定部10806を設定するために、プロセッサ802によって初期ブート測定が実行されてもよい。プロトコル変換部10620は、イングレスプロトコルとエグレスプロトコルとの間の変換を実行することができる。セキュリティ変換部10624は、イングレスセキュリティレベルとエグレスセキュリティレベルとの間でセキュリティ変換を実行することができる。プライバシー変換部10808は、例えばとりわけバイオメトリッククレデンシャルに基づいてプライバシー変換を実行することができる。セマンティック変換部10624は、イングレスペイロードとエグレスペイロードとの間のデータセマンティクス変換を実行し得る。セキュアデータストア10810は、プラグイン、セキュリティポリシー、プライバシーポリシー、スクリプトコンパイラなどを格納することができる。
これらのリソースは、セキュリティポリシーモジュールによって管理される割り当てられたセキュリティレベルに従って「チャネル」を処理するゲートウェイに割り当てられてもよい。イングレスポリシーおよびエグレスポリシーは、例えば未分類から分類済みへのセキュリティレベルのアップグレード、または例えば分類済みから未分類へのダウングレードを認可することができる。ポリシーは、例えば、サニタイズ済みから未サニタイズへ、製造からエンジニアリングへ、または任意の他のデータ分類スキームに従ってデータ完全性分類を認可することができる。
図109は、一部の実施形態による、イングレスネットワークとエグレスネットワークとの間でワークロードを変換するようにプロセッサ902に指示するためのコードを含む、非一時的機械可読媒体10900のブロック図である。プロセッサ902は、バス904を介して非一時的機械可読媒体10900にアクセスすることができる。プロセッサ902およびバス904は、図9に関して説明したプロセッサ902およびバス904と同様の方法で実施することができる。非一時的機械可読媒体10900は、図8の大容量ストレージ808について説明したデバイスを含むこともできるし、光ディスク、USBメモリ(thumb drive)、または任意の数の他のハードウェアデバイスを含むこともできる。
非一時的機械可読媒体10900は、イングレスプロトコルの下でイングレスペイロードを処理するようにプロセッサ902に指示するためのコード10902を含み得る。コード10904は、イングレスプライバシーポリシーの下でイングレスペイロードを処理するようにプロセッサ902に指示するために含まれ得る。コード10906は、イングレスセキュリティポリシーの下でイングレスペイロードを処理するようにプロセッサ902に指示するために含まれ得る。コード10908は、イングレスペイロードのデータセマンティクスをエグレスペイロードのデータセマンティクスに変換するようにプロセッサ902に指示するために含まれ得る。
コード10910は、エグレスセキュリティポリシーの下でエグレスペイロードを処理するようにプロセッサ902に指示するために含まれ得る。コード10912は、エグレスプライバシーポリシーの下でエグレスペイロードを処理するために含まれ得る。コード10914は、エグレスプロトコルポリシーの下でエグレスペイロードを処理するようにプロセッサ902に指示するために含まれ得る。コード10916は、例えばインストールの前に、プラグインおよびポリシーのソフトウェア測定を実行するようにプロセッサ902に指示するために含まれ得る。コード10918は、プラグインを検証しインストールするようにプロセッサ902に指示するために含まれ得る。コード10920は、プラグインをコンパイルするようにプロセッサ902に指示するために含まれ得る。
IoTネットワークは、フォグデバイスを形成するデバイスの集合とみなすことができる。個々のデバイスは、様々なネットワークのトランスポート、セッション、およびアプリケーション層の通信パスを介して接続することができる。ユーザ、組織、またはグループなど、IoTネットワークのオーナーは、IoTネットワークに共通の関心があり、参加している。オーナーは様々なデバイス間の協調を管理し、合法的に所有し、または調整しているので、オーナーは、デバイスが組織に属すると判定することができる。
デバイスは、オーナーがそのデバイスの所有権を取得することを可能にし、それによってデバイスを所有デバイスとしてオーナーに登録することを可能にするために、IoTネットワークにオンボーディングされてもよい。本明細書で使用される場合、オンボーディングは、参加要求の交換、識別情報の検証、およびデバイスリソースの作成など、デバイスを参加させるためのアクティビティが行われたことを示す。次いで、デバイスは、オーナー/ドメイン情報をデバイスリソースに記録することによって、ドメイン内の所有権を確認応答することができる。デバイスは複数のオーナーを許可または持つことができる。一部の例では、デバイスは、複数のドメインに存在することができ、互いによるデバイスの認識を複雑にする。
図110は、一部の実施形態による、デバイスが新しいドメインのコンポーネントとして参加することを可能にするように作成された共有ドメインによって組み込まれている、異なるドメインによって搭載されているデバイスの概略図11000である。概略図11000において、第1のデバイス11002は、オンボーディングツール(OBTA)11006によって第1のドメインA 11004にオンボーディングされている。第2のデバイス11008は、第2のオンボーディングツール(OBTB)11012によって第2のドメインB 11010にオンボーディングされている。この例では、デバイス11002および11008は、それら自体をそれぞれドメインA 11004およびB 11010のメンバとみなすことができる。
デバイスD1 11002とD2 11008との間の相互作用は、例えばドメインがファミリーの一部である場合には、セキュリティレベルの下では許可され得るが、場合によっては、異種のOBTA 11006とOBTB 11012とがネットワーク内のリソース11014または11016の間の区分を確立するため、許可されないこともある。従って、ドメインA 11004のOBTA 11006は、外部ドメインB 11010にオンボーディングされているデバイスを認識または信頼できないことがある。これは、例えば、オンボーディングされた、従ってトラステッドデバイス11002および11008を含む共通リソース11014または11016を共有していないそれぞれのオンボーディングツールに起因し得る。
本明細書で説明される技法では、それぞれのドメイン11004および11010内のオンボーディングツール11006および11012の間で信頼が確立されると、共有リソース11020を有する新しいドメイン11018が作成され得る。共有リソース11020は、個々の親ドメイン11004および11010内のリソース11014または11016からの情報を含み得る。これについては、図111に関してさらに説明する。
図111は、一部の実施形態による、デバイスがドメインを越えて参加できるようにするための共有リソースの例示的な作成の概略図11100である。同様の番号が付けられた項目は、図110に関して説明したとおりである。図110で説明したように、別のドメインでローカルのオンボーディングリソースR1 11012とR2 11016を発見すると、共有リソースR3 11020が作成されて、R1 11014に含まれる記録がR3 11020に格納され、ドメインB 11010内のオンボーディングツールOBTB 11012によるアクセスが可能になる。同様に、R2 11016に含まれる記録は、R3 11020に格納され、ドメインA 11004内のオンボーディングツールOBTA 11014によってアクセスされ得る。さらに、例えばとりわけOBTA 11006による推定ドメイン名がOBTB 11012による推定ドメイン名と同じであるとき、共有リソースR3 11020は、命名の衝突を解決することができる。
本技法は、共有リソースR3 11020がローカルリソースR1 11014およびR2 11016内のドメインIDを同期させるように、ドメイン11004および11010の結合のための新しいドメインID、例えば新しいUUIDを発見または作成する。R1 11014内のサブドメインID 11102は、各サブドメインがそれぞれ新たに形成されたドメイン11018のサブドメインになるように、R2 11016内のサブドメインID 11104とは異なり得る。共有リソースR3 11020は、それぞれのローカルリソースR1 11014およびR2 11016と同期して、複数のサブドメインIDを示すマージされたリソースを埋める。
同様に、オンボーディングツールOBT-A 11006およびOBT-B 11012は、それぞれを共通ドメイン11018のメンバとして確立する共有リソース11020と同期される。同様に、デバイスD1 11002およびD2 11008は、それぞれを同じ共通ドメイン11018のメンバとして確立する共有リソース11020と同期されるが、それぞれデバイス11002または11008を元々オンボーディングしていたそれぞれのサブドメイン11004または11010内のメンバシップをそれぞれ保持することができる。
図112は、一部の実施形態による、共有リソースを含む結合IoTドメインを確立するための例示的な方法11200のプロセスフロー図である。図112の方法11200は、図113に関して説明されるIoTデバイス11300によって実施することができる。本明細書で使用される場合、共有リソースは、仮想化リソース、ストレージリソース、通信リソース、オンボーディングリソース、サービスプロバイダリソースなどを含み得る。リソースは、ドメインレベル、サブドメインレベル、またはデバイスレベルで存在し得る。ブロック11202は、例えば、第1のオンボーディングツールが第1のデバイスを第1のネットワークドメインに参加させるときを表す。ブロック11204において、第1のオンボーディングツールは、例えばメンバまたは所有デバイスとして、デバイスをローカルリソースに追加する。
ブロック11206において、第2のオンボーディングツールは、第2のデバイスを第2のネットワークドメインに追加する。ブロック11208において、第2のオンボーディングツールは、例えばメンバまたは所有デバイスとして、デバイスをローカルリソースに追加する。
ブロック11210において、オンボーディングツールは、ネットワーク上で互いを発見し、それらの間で信頼を確立する。これは、本明細書で説明されているように、例えば、相互アテステーション、個々のペアリング、管理コンソールを介して、またはブロックチェーンによって実行することができる。
ブロック11212において、オンボーディングツールは共有リソースを作成し、共有リソースにおいてオンボーディングツールはシェアホルダである。ブロック11214において、オンボーディングツールは、それらのそれぞれのリソースを共有リソースにリンクする。その結果、第1のデバイスのリソースは第2のオンボーディングツールにアクセス可能であり、第2のデバイスのリソースは第1のオンボーディングツールにアクセス可能である。ブロック11216において、2つのデバイスドメインの結合に基づく新しいドメインが形成される。新しいドメインのドメインIDは共有リソースに記録される。
ブロック11218において、第1のドメイン内のサブドメインIDが第2のドメイン内のサブドメインIDと同じまたは類似しているか否かに関する判定が行われる。そうである場合、ブロック11220において、第2のリソース内のサブドメインIDに対して新しいサブドメインIDが選択され、そのサブドメインIDにアクセスするすべてのリソースが新しい名前で更新される。
ブロック11222において、第1のドメイン内のOBT IDすなわちオンボーディングツールIDが第2のドメイン内のOBT IDに等しいか否かに関する判定が行われる。そうである場合、ブロック11224において、第2のリソース内のOBT IDに対して新しいOBT IDが選択され、そのOBT IDにアクセスするすべてのリソースが新しい名前で更新される。
ブロック11226において、第1のドメイン内のデバイスIDが第2のドメイン内のデバイスIDに等しいか否かに関する判定が行われる。そうである場合、ブロック11228において、第2のリソース内のデバイスIDに対して新しいデバイスIDが選択され、そのデバイスIDにアクセスするすべてのリソースが新しい名前で更新される。
本方法は、2つのデバイスおよびドメインについて示されているが、重なり合うドメインから組み込む必要がある任意の数のデバイスを使用することができる。例えば、複数のデバイスを持つ2つのドメインが、両方のドメインのオンボードツールによって作成された共有ドメインによって結合される場合がある。別の例では、3つ以上のドメイン内のデバイスが共有ドメインによって結合されてもよい。
図113は、一部の実施形態による、共有リソースを作成するためのIoTデバイス11300に存在し得るコンポーネントの一例のブロック図である。同様の番号が付けられた項目は、図3および図8に関して説明したとおりである。図8に関して説明したIoTデバイス800、および本明細書で説明される他のIoTデバイスに対して選択されたものとは異なるコンポーネントが、IoTデバイス11300に対して選択され使用されてもよいことに留意されたい。
大容量ストレージ808は、本明細書で説明されるリソースのドメイン間共有を実施するための複数のモジュールを含むことができる。大容量ストレージ808においてコードブロックとして示されているが、モジュールのうちのいずれも、例えば特定用途向け集積回路(ASIC)に組み込まれるなど、ハードワイヤード回路で完全にまたは部分的に置き換えられ得ることが理解されよう。
大容量ストレージ808は、デバイスをIoTデバイス11300のドメインに参加させ、デバイスのためのデバイスリソース11304のストアを作成するオンボーディングツール11302を含み得る。デバイス発見部11306は、現在のドメイン内のデバイスと共にフォグデバイスの一部として使用され得る他のドメイン内のデバイスを識別し得る。本明細書で説明するように、デバイス発見部11306は、オーケストレータによって提供された情報を使用して他のデバイスを発見することができる。信頼構築部11308は、オンボーディングツール11302と別のドメイン内のオンボーディングツールとの間で信頼を確立するために様々な技法を使用することができる。信頼構築部11308は、アテステーション情報、識別鍵を交換してもよいし、管理者ワークステーションから割り当てられた信頼証明書を使用してもよい。一部の例では、信頼構築部11308は、本明細書で説明されるように、ブロックチェーンのルートオブトラストを使用することができる。
共有ドメイン作成部11310は、共有ドメインを作成するために他のドメインからのオンボーディングツールと協働する際にオンボーディングツールを支援するように働くことができる。共有ドメインは、異なるドメインにわたってすべてのオンボーディングツールにアクセス可能である、またはオンボーディングツールをホスティングするIoTデバイスのそれぞれにミラーリングされる、共有リソースディレクトリ11312を含み得る。
図114は、一部の実施形態による、ドメインにわたって共有リソースを確立するようにプロセッサ902に指示するためのコードを含む、非一時的機械可読媒体11400のブロック図である。プロセッサ902は、バス904を介して非一時的機械可読媒体11400にアクセスすることができる。プロセッサ902およびバス904は、図9に関して説明したプロセッサ902およびバス904と同様の方法で実施することができる。非一時的機械可読媒体11400は、図8の大容量ストレージ808について説明したデバイスを含むこともできるし、光ディスク、USBメモリ(thumb drive)、または任意の数の他のハードウェアデバイスを含むこともできる。
非一時的機械可読媒体11400は、デバイスをドメインに参加させるようにプロセッサ902に指示するためのコード11402を含み得る。コード11404は、ドメイン内のデバイスのためのローカルリソースを作成するようにプロセッサ902に指示するために含まれ得る。コード11406は、他のドメイン内の関連デバイス、例えばそれらのドメイン内のオンボーディングツールを含む関連デバイスを発見するようにプロセッサ902に指示するために含まれ得る。コード11408は、ローカルデバイスのためのリソースを他のドメイン内のリソースにリンクするようにプロセッサ902に指示するために含まれ得る。コード11410は、すべてのデバイスのための共有リソースを保持する共有ドメインを作成するようにプロセッサ902に指示するために含まれ得る。コード11412は、ドメイン、オンボーディングツール、およびデバイス間に重複する名前またはIDがあるか否かを判定するようにプロセッサ902に指示するために含まれ得る。コード11414は、ドメイン、オンボーディングツール、または最後に参加したデバイスの名前を変更し、すべての関連リソースに新しい名前を伝播することによって名前の重複を修正するようにプロセッサ902に指示するために含まれ得る。
上記のネットワーキング通信および認証システムは、特定の用途のためにIoTネットワークを実装するための複数の態様を提供する。1つの例では、分散型ネットワークを使用して、食品、医薬品、または工業製品などの最終製品のトレーサビリティを実装することができる。
どのようなライフサイクル追跡システムについても、システム内のプレーヤが、システムが、モデル外のなにかではなく期待される挙動モデルに従って挙動しているという信頼をどのように確立するのかという問題がある。難しいのは、良好な挙動を定義する主体が信頼できない場合があることである。そのためには、末端の(provincial)、例えばデバイス間の信頼メカニズム、および制度的(institutional)な、例えば中央当局によって管理されている信頼メカニズムは、弱点を有する。しかしながら、インフラストラクチャによる信頼は、信頼施行の信頼性の高い形式であり得、そのブロックチェーンは、インフラストラクチャによる信頼を実現するための技術である。従って、図110に関して説明したように、他のドメインへのデバイスの組み込みは、IoTデバイスのグループからのデバイスの形成、およびそれらのデバイス間の信頼の確立を可能にし得る。これは、図20に関して論じられたブロックチェーンのルートオブトラストなどの、信頼を確立するための様々なシステムを使用して実行されてもよい。
「記録鍵」が使用される場合には、記録鍵の信頼プロパティを確立するための方法が提供される。まだ確立されていない新しい産業を含む多くの産業に関わるトレーサビリティシステムを開発するためのIoTの使用として、本明細書で説明されているブロックチェーン信頼などのフレームワークは、トレーサビリティシステムにおける信頼を発展させるのに役立ち得る。
例示的なIoTトレーサビリティシステムが、図115~図120に関してさらに説明される。IoTトレーサビリティシステムは、図3に関して説明したIoTネットワークを使用して、または例えば図4に関して説明したフォグデバイスを使用して実施することができる。IoTトレーサビリティシステムは、パブリックドメインおよびプライベートドメイン、IPネットワークドメインとIoTネットワークドメインなどのドメインに、様々なサプライヤまたは商業エンティティによって制御されているドメインを介してまたがることができる。
図115は、一部の実施形態による、製品追跡システムを実施するための製品ライフサイクルのステージを示すラダー図11500である。図115のラダー図11500は、図119に関して説明されるIoTデバイス11900によって実施することができる。トレーサビリティシステムは、製品の原産地11502から販売店11504まで、例えばとりわけ加工施設11506および流通センター11508を通過するときの、コマンドおよびトレース情報のチェーンの記録、保管、検証、セキュリタイゼーション、および取得を実施することができる。あるステージから次のステージへの移行11510、11512、および11514の間に生成された情報も関連性がある。例えば、移行11510、11512、および11514は、製品が農場などの原産地11502から加工工場11506へ、または加工工場11506から流通センター11508へ移動されるときに発生する。この情報は、例えば、出荷日、製品種別、および量などの在庫目録、および(農産物用の)収穫日、(品物用の)生産日、保管温度履歴、または製品の変化に影響する任意の数の他のパラメータなどの変遷(transforms)を含み得る。
記録鍵11516、11518、および11520を1つまたは複数のステージで生成して、そのステージの、本明細書でトレーサビリティ記録と呼ぶ情報を、格納しアクセスすることができる。トレーサビリティは信頼の一態様であることに留意されたい。トレーサビリティは、追跡履歴が、予想外のまたは不適切な挙動ではなく予期された良い挙動を示しているか否かを立証する方法があるとみなしている。末端の信頼および制度的信頼が関与している場合、予想される、例えば良い挙動、または予想外の、例えば不適切な挙動を定義する基準が明確に定義されていない可能性がある。例えばブロックチェーンを通じて、インフラストラクチャによる信頼を採用するプロセスでは、これらの基準を定義し、予想される挙動に関するコンセンサス真理を使用する必要がある。従って、インフラストラクチャによる信頼が場合によってはより強力な手法になり得る。トレーサビリティ記録は、パブリックアクセス可能なストア、プライベートストア、またはそれらの組み合わせに格納され得る。さらに、トレーサビリティ記録は、記録鍵などのパブリックストアに部分的に格納され、残りの詳細は後の出来事のトラブルシューティングにおけるアクセスのためにプライベートストアに保持される。
図116は、一部の実施形態による、ステージ11614から11620のトレーサビリティ記録11606から11612にアクセスするために記録鍵11604が使用され、プライベートデータストア11602を使用することの概略図である。この例では、パブリックアクセス可能なトレーサビリティ記録11606~11612は、農家、製造業者などに関連する詳細なプロセスまたは情報を含まなくてもよい。
記録鍵、時間、および原産地などの基本的なトレーサビリティデータと、製造施設からの詳細な独自のタスクデータと、の間のプライベート/パブリックの境界を維持することは有用であり得る。これは、ステージ11614~11620において、エンティティについて知覚されるプライバシー保護を高め、採用率を高めることができる。この例では、別々のデータストア11602に送信された呼び出し11622から11628は、トレーサビリティ記録11606~11612を抽出するために利用される。一部の場合では、プライベートデータストア11602は異なるエンティティによって管理されるので、別個のプライベートデータストア11602はセキュリティおよび信頼性の問題を提示し得る。
図117は、一部の実施形態による、パブリックまたは共通のデータストア11702を使用することの概略図である。この例では、データは、パブリックに格納されるが、異なるステージの記録鍵11704の下で暗号化され得る。記録鍵11704はまた、共通データストア11702のためのインデックスとしても機能することができ、コマンドおよびトレーサビリティデータのチェーンが抽出され得る。記録鍵11704は、あるステージについてトレーサビリティ記録11706~11712にアクセスし復号することができる。例えば、鍵11714は、トレーサビリティ記録11706を見つけ解読することができる。
記録鍵11704は、チェーンに追加され、物理的にまたは製品包装上のマーキングを介してステージを通過してもよい。例えば、製品の包装に関連するIoTデバイスは、製品を積込ドックに配送する際に、加工工場などの施設でメッシュネットワークまたはフォグデバイスに参加することができる。
IoTデバイスは、例えば関連する包装内で、製品と共にて加工工場を通り、加工された製品と共に出て行くことができる。小売販売店などの別のステージに配送するためにIoTデバイスがトラックに積み込まれると、施設内のメッシュネットワークまたはフォグデバイスは、そのステージのための記録鍵11704によりIoTデバイスをプログラムすることができる。IoTデバイスがそのステージを離れ、例えば加工施設のメッシュネットワークとの接触が失われると、そのステージのトレーサビリティ記録は、パブリックデータストア11702に保存されてもよいし、図116に関して説明したようにプライベートデータストア11602に保存されてもよいし、またはその両方であってもよい。
図118は、一部の実施形態による、トレーサビリティシステムを実施するための例示的なプロセス11800の概略図である。図118のプロセス11800は、図119に関して説明されるIoTデバイス11900によって実施することができる。この例では、製品は、穀物、果物などの農産物である。この場合、ステージは、栽培、出荷、加工などの、農産物に対して行われる動作を対象としている。以下のステージは特定の製品に関して説明されているが、この例は栽培または製造される任意の種類の製品に適用される。従って、第1のステージにおける動作は、例えば製品が構築されるときに製造工場において行われる動作に関係し得る。
第1のステージ11804は、農産物の生産に関連するプロセスのライフサイクルに関する。第1のステージ11804は、ブロック11806において農産物の植え付けで開始し得る。植え付けは、トラクターなどの植え付けデバイスに関連するIoTメッシュネットワークによって追跡および監視され得る。多くのトラクターにはGPSとコンピュータモニタとが装備されて、畑を通る最も効率的なコース上にトラックを差し向ける。IoTメッシュネットワークは、車載コンピュータと、種子を植え付けるシードドリル、種子貯蔵所、植え付け温度、土壌水分レベル、および他の植え付けパラメータ、ならびに燃料レベル、空気式播種機のコンプレッサ圧力、燃料レベルなどなどの機器パラメータを監視するデバイスと、を含み得る。生成されたデータ11808は、中央サーバなどの農場データストア11810に格納することができる。トラクターは、LPWAネットワーク、LTEネットワーク、衛星アップリンク、または他の無線ネットワークを介して農場データストア11810と連続的に通信してもよいし、トラクターが母屋または納屋に到着したときにダウンロード用のデータを格納してもよい。農場データストア11810は、リモートサイト、例えばクラウド内に配置することができる。
ブロック11812において、作物には、例えば液体アンモニアの注入により、肥料が与えられ得る。これは、トラクターに関連付けられたIoTメッシュネットワークによって監視され、その際、追加のデバイスが栄養剤散布機を監視する。これらのデバイスは、無水アンモニア容器、注入圧力などを監視することができる。肥料やりに加えて、またはその代わりに、このブロックにおいて他のプロセスを監視することができる。これには、固形肥料の散布や灌漑が含まれ得る。固形肥料の散布は、トラクターのIoTメッシュネットワークを通して監視することができる。灌漑は、ポンプ、流量計、圧力センサ、ブームを動かすモータなどの灌漑システムに関連するIoTメッシュネットワークを介して監視することができる。灌漑ネットワークは、LPWAネットワークなどの無線リンクを介して中央システムに報告することができる。これらのプロセスからのデータ11808はまた、農場データストア11810に、例えばプライベートブロックチェーンに格納されてもよい。
ブロック11814において、例えばコンバインを使用して作物を収穫することができる。トラクターに関しては、コンバインは、しばしば、GPSおよびデータ収集を含む広範なコンピュータ制御システムを持っている。IoTメッシュネットワークをコンバインに設置し、コンバイン上のコンピュータシステムに接続して、収穫時の農産物を追跡することができる。メッシュネットワークは、収穫された材料の重量、収穫された材料の畑での位置、およびトレーサビリティのために使用され得る他のパラメータを追跡するデバイスを含み得る。
トラクターまたはコンバインなどの個々のユニットにプロセス制御技術を適用する技術と比較して、IoTメッシュネットワークは、穀物トラック、燃料トラック、および他のデバイスなどの補助車両上に配置されたデバイスを含み得る。これらは、製品の位置および製品が複数のデバイスを通って移動する際の変遷のさらなる記録を提供するために使用され得る。さらに、貯蔵された製品の量、水分含有量、害虫の活動、塵埃量などを追跡する、農産物の冷蔵庫、サイロ、および他の作物貯蔵領域内のデバイスなどの、固定位置にあるデバイスが、IoTメッシュネットワークに参加することができる。これらのデバイスは、農場ネットワークの一部であっても、トレーサビリティ記録の情報を主に収集する企業ネットワークの一部であってもよい。
製品は、最小の追跡可能単位、例えばコンバイン、農産物トラック、穀物トラックなどに保持される量を有し得ることに留意されたい。追跡情報は最小追跡可能単位にのみ適用されるため、最小追跡可能単位未満の量は区別できない場合がある。さらに、流量特性が、発生している混合量を判定するために使用され得るが、製品のいくらかの混合は、例えば穀物サイロ内の貯蔵において予想され得る。同じ問題が、医薬品、またはバッチサイズによって最小追跡可能単位が決まり得る他の製品にも当てはまる。
ブロック11816において、製品を分類し包装することができる。例えば、トラックや鉄道車両に積み込まれる。ブロック11818において、時間、日付、製造場所、運送会社などの追加の情報をトレーサビリティ記録に追加することができる。この情報は、パブリック情報に含まれてもよいし、農場データストア11810に保持されてもよい。
ブロック11820において、製品は、出荷のためにタグ付けされ得る。これには、出荷する前に、IoTデバイスを農産物の包装に取り付けること、またはIoTデバイスを製品に関連付けることが含まれ得る。IoTデバイスは、農場データストア11810からの記録鍵を格納することができる。他の例では、出荷前にバーコードを商品の包装に印刷することができる。タグは、農場データストア11810からのトレーサビリティ記録にアクセスするための記録鍵を含み得る。記録鍵はまた、パブリックブロックチェーンなどのパブリックストア11824に送信され得る(11822)。パブリックストア11824から、ステージの記録鍵にアクセス可能であり得る。
ステージ2 11826において、製品は、農場から加工施設に輸送され得る。ブロック11828において、日時および運送会社ならびに製品のバッチIDが記録され得る。データ11830は、例えばトラックに関連付けられたコンピュータまたはサーバに配置された出荷ストア11832に送信され得る。出荷ストア11832はまた、運送会社の中央出荷事務所に配置されてもよい。この場合、データ11830は、無線アップリンク、例えばLTEリンクまたは衛星リンクを介して中央出荷事務所にアップロードされ得る。
ブロック11834において、製品包装に関連するIoTデバイス、またはトラックもしくは出荷プラットフォーム上の他のIoTデバイスなどのIoTデバイスは、輸送中のイベントを監視することができる。輸送中のイベントとしては、例えば、とりわけ、温度変動、G力、輸送時間、または輸送の遅延を挙げることができる。ブロック11834からのデータ11830はまた、出荷ストア11832に送信され得る。
ブロック11836において、製品の配送状況が記録され得る。これは、配送の時間、場所、および日付を含むことができる。配送データは、出荷ストア11832に送信されてもよい。記録鍵は、ステージ2 11826について作成され、出荷ストア11832に格納され、ブロック11838においてステージ1 11804の記録鍵に付加されてもよい。記録鍵は、パブリックストア11824に送信され(11840)、包装に関連付けられたIoTデバイスに保存されてもよい。第1のステージ11826が完了した後、製品は、加工施設の積み込みドックに存在し得る。
ステージ3 11842において、製品は、販売のために加工される。ブロック11844において、材料の時間、日付、梱包会社、およびバッチIDが記録される。データ11846は、加工データストア11852に送信される。これには、包装および販売前加工が含まれ得る。例えば、新鮮なカットサラダの場合、加工は、材料の洗浄、材料の細断、材料の混合、および材料の包装を含み得る。ブロック11848において、プロセスのそれぞれが実行または完了されると、ステータスに関するデータが加工データストア11852に送信され得る。加工が完了すると、ブロック11850において、ステージ3 11842の記録IDが前のステージの記録IDに付加され、加工データストア11852に保存され、パブリックストア11853に送信される。次いで、包装され加工された製品は、ステージ4 11854のための積み込みドックに移動されて、最終販売場所に運ばれる。
各ステージにおいて、付加された記録鍵は、包装に関連付けられているIoTデバイスに保存され得る。本明細書で説明されるように、IoTデバイスはまた、輸送中のイベントを追跡することができる。ステージ4 11854では、ブロック11856において、製品の時間、日付、運送会社、およびバッチIDが記録される。データ11858は、例えばトラックの中にあるか、または運送会社に配置されている、出荷ストア11866に送信され得る。ブロック11859において、IoTデバイスは、製品の出荷パラメータを監視し、例えば、温度変動、G力、および製品の品質に影響を及ぼし得る他のパラメータを記録する。出荷パラメータを監視することからのデータ11858はまた、出荷ストア11866に送信され得る。
ブロック11860において、製品は、目的地、例えば小売販売店に到着する。配送ステータスが記録され、ブロック11862において、記録IDまたは鍵が前のステージの記録IDまたは鍵に付加される。付加された鍵は、IoTデバイスによって格納され、パブリックストア11824に送信され得る(11864)。
この例では、最終ステージ11868が販売場所である。ブロック11870において、日時およびストック場所が記録される。ブロック11872において、例えば、より古い品物をより新しい品物と交換するためのローテーションによって、商品の鮮度を考慮に入れることができる。ブロック11874において、コンシューマは製品を購入する。コンシューマは、商社であってもよいし、店または他の小売店で製品を購入する個人であってもよい。
購入後、コンシューマまたは他のエンティティは、製品のトレーサビリティチェックを実行したいと思う場合がある。例えば、トレーサビリティ記録にアクセスして製品中の汚染の起源を判定することができる。ブロック11876において、トレーサビリティチェックが要求されたか否かに関する判定が行われる。もしそうであれば、ブロック11878において記録鍵がアクセスされる。ブロック11880において、これは、SKU番号または他の包装マーキングを使用して、包装または輸送用コンテナ上のIoTデバイスから記録鍵を取得することによって、またはパブリックストア11824からデータ11882にアクセスすることによって、実行され得る。連結された、ステージの記録鍵を含む、付加された記録鍵について、原産地から販売場所までの連続性が最初にチェックされる。このプロセスは、完全な鍵の巡回冗長検査、有効性を示すためのゼロのチェックを伴う個々の記録鍵のXOR、またはデータベースもしくはパブリックストア11824における鍵のルックアップを伴うオンライン検証プロセスを含み得る。ブロック11884において、記録鍵を使用して、プライベートストア11810、11832、11852、または11866に保存されているデータにアクセスすることができる(11886)。
検証後、データは要求者に提示され得る。利用可能なオプションとしては、原産地から販売場所までの完全なまたは部分的なパスを要求者に表示することを挙げることができる。他のオプションとしては、トレーサビリティ鍵の結果に関する値またはテキストメッセージを表示することを挙げることができ、これは、要求者への音、色、画像、または他の種類の感覚警報の起動を含むことができる。
ブロックチェーンは、分散型信頼セマンティクスを使用してIoTネットワークの動作における信頼を確立する方法としてIoTデバイスがパブリックおよびプライベートブロックチェーンを利用することができるような、本質的にトレーサブルなシステムであり得る。
監査システムが、トレーサビリティハッシュの収集および格納が末端の(provincial)信頼方法の下で正しく管理されていることを確保するのに役立ち得る。トレーサビリティハッシュのPCR測定に署名するためのPKIを有するTPMに基づくシステムなどのシステムが、制度的信頼に依拠する戦略であり得る。ブロックチェーンまたはブロックチェーンの階層の周囲にプライベートストアを構築する方法では、インフラストラクチャによる信頼を使用する。
図119は、一部の実施形態による、製品のトレーサビリティ記録を提供するためにIoTデバイス11900に存在し得るコンポーネントの一例のブロック図である。同様の番号が付けられた項目は、図3および図8に関して説明したとおりである。図8に関して説明したIoTデバイス800、および本明細書で説明される他のIoTデバイスに対して選択されたものとは異なるコンポーネントが、IoTデバイス11900に対して選択され使用されてもよいことに留意されたい。
大容量ストレージ808は、本明細書で説明される、製品の記録のトレーサビリティを実施するための複数のモジュールを含むことができる。大容量ストレージ808においてコードブロックとして示されているが、モジュールのうちのいずれも、例えば特定用途向け集積回路(ASIC)に組み込まれるなど、ハードワイヤード回路で完全にまたは部分的に置き換えられ得ることが理解されよう。
大容量ストレージ808は、生産ステージおよび販売ステージで記録鍵を生成する記録鍵生成部11902を含むことができ、それは1つのステージで記録鍵を生成することを含むことができる。プライベートストア通信部11904は、製造または販売プロセスステージで、IoTデバイス11900および他のIoTデバイス812から収集された記録鍵およびデータを保存するためにプライベートストアと通信することができる。パブリックストア通信部11906は、パブリックストアと通信して記録鍵をパブリックストアに保存することができる。パブリックストア通信部11906は、通過温度、通過時間などの他の情報をパブリックストアに保存することができる。パブリックストア通信部11906は、記録鍵ストア11908からのすべてのステージについて付加された記録鍵をパブリックストアに保存することができる。データモニタ11910は、インターフェース818を介して温度センサ、G4センサなどのセンサ820を監視して、その製品について温度の極値、衝撃の極値などの輸送の問題があるか否かを判定することができる。警告部11912は、温度などの輸送中の制限に違反した場合、インターフェース818、例えば光、音、または他のデバイスを介してアクチュエータ822を作動させることができる。警告部11912はまた、例えばパブリックストア通信部11906を介して、あらゆる輸送中の違反をパブリックデータストアに格納することができる。
図120は、一部の実施形態による、ドメインにわたってリソースを共有するようにプロセッサ902に指示するためのコードを含む、非一時的機械可読媒体12000のブロック図である。プロセッサ902は、バス904を介して非一時的機械可読媒体12000にアクセスすることができる。プロセッサ902およびバス904は、図9に関して説明したとおりであり得る。非一時的機械可読媒体12000は、図8の大容量ストレージ808について説明したデバイスを含むこともできるし、光ディスク、USBメモリ(thumb drive)、または任意の数の他のハードウェアデバイスを含むこともできる。
非一時的機械可読媒体12000は、製品が加工または出荷ステージにある間にデータを記録するようにプロセッサ902に指示するためのコード12002を含み得る。コード12004は、ステージデータをプライベートストアに通信するようにプロセッサ902に指示するために含まれ得る。コード12006は、ステージの記録鍵を生成するようにプロセッサ902に指示するために含まれ得る。コード12008は、ステージの記録鍵をプライベートストアに保存するようにプロセッサ902に指示するために含まれ得る。コード12010は、そのステージの記録鍵を前のステージの前の記録鍵に付加するようにプロセッサ902に指示するために含まれ得る。コード12012は、付加されたステージ鍵をパブリックストアに送信するようにプロセッサ902に指示するために含まれ得る。コード12014は、とりわけ、あるステージで温度制限などのデータ制限の違反があった場合に警告するようにプロセッサ902に指示するために含まれ得る。コード12014は、データ制限違反をパブリックストアに保存するようにプロセッサ902に指示するために含まれ得る。
ポリシーは、ネットワークリソースへのアクセスを管理および制御するための規則のセットとして定義されている。ポリシーには、イベント、条件、動作、サブジェクト、およびターゲットを含み得る。ポリシーは、発生した条件に応答するようにデバイスまたはネットワークに指示するポリシー構造にイベント、条件、動作、サブジェクト、およびターゲットを集約する。
しかしながら、上記の例の製造プロセスの異なるステージなど、IoTメッシュネットワークの場合は、ポリシーの伝播に対処する必要がある。さらに、広く分散されたIoTネットワークを使用すると、データのセキュリティを保護するポリシー、収集されたデータを変更するポリシー、またはそのデータのアクセス可能性を高めるポリシーなどのポリシーどうしの関連性が高まり得る。
図121の(A)は、一部の実施形態による、コンピュータネットワークで使用されている階層型ポリシー管理システム12100の概略図である。デバイスポリシーをリアルタイムで管理するための手法は、階層型ブロードキャストアーキテクチャである。本明細書で説明されるように、これはブルームフィルタに基づくパブリケーション-サブスクリプション型モデルと置き換えられ得る。典型的なフローは、ゲートウェイ12104などのサブユニットにポリシーを伝播する集中型クラウドサーバ12102などの中央システムからのフローである。次いで、ゲートウェイ12104は、IoTエンドポイントデバイス12406を含む下位レベル12106にポリシーを伝播させることができる。次いで、IoTエンドポイントデバイス12108のうちの1つが、より下位レベル12110、例えばセンサデバイスまたは他のユニットにポリシーを伝播させることができる。
階層型ポリシー管理システム12100では、個々のデバイスは直接アドレス指定可能である。その性質上、このアーキテクチャでのポリシーのデプロイでは、管理者は、すべてのターゲットノードのアドレスと、欠陥のあるノードまたはポリシーを置き換える方法と、を明示的に知る必要がある。さらに、デバイスは、リソースの制約のためにローカルメモリに限られた数のポリシーを格納し、追加のポリシーが実装されたときにポリシーを置き換えることが多い。
本明細書で説明されるように、分散型ポリシーベース管理フレームワークは、ネットワーク内でポリシーを格納し、見つけ出し、アクセスし、そして実行するために実装され得る。このフレームワークは、例えばIoTメッシュネットワークにおいて、利用可能なメモリを利用するためにピアツーピア(P2P)ポリシーストレージおよびデプロイメカニズムを使用することができる。これにより、ノード障害、および単一障害点に関して役立つポリシーシステムを得ることができる。
図121の(B)は、一部の実施形態による、IoTメッシュネットワークなどのピアツーピア(P2P)ネットワークにおけるポリシー管理の概略図である。P2Pネットワークでは、ゲートウェイなどのコーディネータ12112は、最近隣であり得る結合されたノード12116などの近隣機に、ポリシー12114を配信する。次いで、これらの近隣機は、そのポリシーを他の結合されたノード12116に渡すことができる。
IoTメッシュネットワークの規模が拡大し、本質的に異種ネットワークになるにつれて、IoTメッシュネットワークが運用目標を確実に満たすようにするために、多数のポリシーを定義し、継続的に修正する必要があり得る。分散型ポリシー管理などの自律型ネットワーク管理は、ネットワーク運用の最適化に関わる意思決定プロセスを自動化して分散させることができる。これにより、管理者は、下位レベルのデバイス構成プロセスに集中しなくて済むようになり得る。自律管理システムにポリシーを組み込むことは、ポリシー変換、コード生成、競合分析およびポリシー施行のための方法およびアルゴリズムを含み得る。
図122は、一部の実施形態による、分散型ポリシー管理システム12200を実装するためのノード12116内のシステムの概略図である。同様の番号が付けられた項目は、図121に関して説明したとおりである。ノード12116のそれぞれは、ポリシー決定エンジン12202、ポリシー施行エンジン12204、ポリシーリポジトリ12206、およびモニタ12208を実装することができる。ポリシーリポジトリ12206は、ノード12116のためのポリシーを格納し、ポリシーは高い記憶容量を必要としない場合がある。ポリシー決定エンジン12202は、ポリシー施行エンジン12204に渡されるどのポリシーが施行されることになっているかについての決定を行う。決定は、ポリシーリポジトリ12206に格納されているポリシーと、モニタ12208によって報告された状態情報と、に基づいてもよい。ポリシー決定エンジン12202は、未構成ノードにポリシーを配信するために、他のノード12116と相互作用する。未構成ノードでは、ポリシー決定エンジン12202は、他のノード12116と通信してポリシーにアクセスすることができる。
ポリシー施行エンジン12204は、ローカルポリシー決定エンジン12202によって提供されたポリシー決定を実施する。ローカルポリシー施行エンジン12204はまた、その状態、ネットワークトラフィック、伝送エラーに関する情報、および自身にモニタ12208から報告された情報を収集する。
モニタ12208は、ローカルポリシー施行エンジン12204および他のノード12116内のモニタ12208とインターフェースする。モニタ12208は、特定の間隔で情報を収集し、それをデータベース、例えばローカルポリシーリポジトリ12206に格納する。モニタ12208によって収集され得る情報の例としては、現在のデバイス構成、各ノードによってサポートされる能力および機能が挙げられる。モニタ12208によって収集され得る他の情報としては、提供されているサービス、ネットワークに対するノード要件、リソース可用性推定、トリガされたイベントなどに関する情報が挙げられる。
図123の(A)は、一部の実施形態による、例えばピアノード12304からネットワーク上のポリシーを発見しようと試みる新しい未構成ノード12302の例示的な方法12300のラダー図である。図123の(A)の方法12300は、図126に関して説明されるIoTデバイス12600によって実施することができる。新しい未構成ノード12302は、ネットワークに参加すると、ポリシー発見動作を開始する。新しい未構成ノード12302は、発見メッセージ12306をピアノード12304にブロードキャストし、発見タイムアウトタイマ12308の期限が切れるまで待つことができる。応答を受信しない場合は、発見メッセージを再送信する(12306)。
本明細書で説明するように、調整ノード、構成済みノード、および新しい未構成ノードの役割は、ブルームフィルタを使用したPub-Sub型通知システムを使用してモデリングされ得る。この例では、ブルームフィルタの「ルータ」ノードがコーディネータノードとして機能して、新しい未構成ノードが既存の構成済みノードを確実に見つけることができるようにする。既存の構成済みノードは、現在実装しているポリシーオブジェクトのパブリッシャである。新しい未構成ノードは、構成済みノードのポリシーオブジェクトにサブスクライブすることができる。構成済みノードのポリシーオブジェクトを変更または更新すると、ネットワークに広がり得る通知トラフィックのカスケードが生成され得る。
図123の(B)は、一部の実施形態による、構成されたノード12312からポリシーを発見する新しい未構成ノード12302の例示的な方法12310のラダー図である。図123の(B)の方法12310は、図126に関して説明されるIoTデバイス12600によって実施することができる。構成済みノード12312は、ネットワークの目的を満たす高水準のポリシーを有する。一例では、高水準のポリシーは、サービス品質と省電力とのバランスをとるためにネットワーク内のデバイスが通信をどのように処理するかを含み得る。任意の数の他のポリシーを実施することができる。新しい未構成ノード12302は、発見メッセージ12306を構成済みノード12312に送信する。構成済みノード12312は、オファーメッセージ12314で応答する。
オファーメッセージ12314を受信すると、未構成ノード12302は、メッセージをチェックする。オファーが受け入れられると、応答として受け入れメッセージ12316を送信する。そうでなければ、拒否メッセージが構成済みノード12312に送り返される。
受け入れメッセージ12316を受信すると、構成済みノード12312は、InitPolicyメッセージ12318を未構成ノード12302に送信する。InitPolicyメッセージ12318は、未構成ノード12302に送信されるポリシーを組み込む。未構成ノード12302は、ポリシーオブジェクトを処理し、ポリシーをインストールし、その状態を構成済みノード12322に更新する(12320)。
更新されたポリシーは、構成済みノード12312によって受信される更新メッセージ12326において、例えばコーディネータ12324からディスパッチされ得る。構成済みノード12312は、確認およびポリシー完全性チェックに続いて、有効なポリシーに対して更新12328を実行することができる。
確認チェックは、ポリシーが現在の目的と矛盾するか否かを判定することができる。例えば、電力を節約するようにすべてのデバイスに指示するポリシーを、ネットワーク内のすべてのノードにディスパッチすることができる。本明細書で説明されるように、これは、電力管理ポリシーがエニュメレーションされ、Pub-Sub型「トピック」としてサブスクライブされるPub-Sub型システムに関して説明され得る。例えば、電力レベル4で動作するように指示するポリシーの指示が、電力管理トピックのサブスクライバにパブリッシュされる場合がある。効率的なブルームフィルタベースのメッセージ配信システムは、電力管理トピックのサブスクライバにポリシーの変更を確実に通知するのに役立つ。
ポリシーオブジェクトがセキュリティまたはセキュア性が重要な機能を意味する場合、トピック通知メッセージの受信に続いて、ポリシー決定ポイントへのセキュアなセッションを開くことができ、ノードは通知に対処する前にエンドツーエンドセキュリティクレデンシャルを認証および確立することができる。しかしながら、ノードは、デバイスが特定のサービス品質(QoS)を維持することを要求するポリシーを既にアクティブに実施している可能性がある。省電力ポリシーの実装は、QoSポリシーと競合し得る。従って、新しいポリシーが拒否され得る。
ポリシーが確認チェックに合格しなかった場合、更新は有効なポリシーの部分的な置き換えを実行することができる。部分的な置き換えは、現在有効なポリシーと更新されたポリシーとの間の差分の計算を含み得る。部分的な更新では、影響を受けるポリシーのパラメータまたは条件を変更するだけで、完全なポリシーの変更による影響を軽減できる可能性がある。これについては、図124に関してさらに説明する。
更新メッセージ12326はまた、ポリシーの連結も含み得る。これは、近隣ノードから受信した追加のポリシー規則によってベースレベルのポリシーが拡張されている分散型および分散型ネットワーク環境に特に適用される。これについては、図125に関してさらに説明する。
構成済みノード12312がポリシーを更新または置換した場合、競合警告メッセージ12340を別の構成済みノード12322に送信して、ポリシーの競合について警告することができる。このような通信ネットワークの動的な性質およびサイズに対処するために、ポリシー競合分析プロセスは効率的でスケーラブルでなければならない。ポリシー競合分析のためのポリシー選択プロセスは、後続の反復で必要とされる比較の数を減らすために、ツリーベースのデータ構造に、以前のポリシー比較の履歴を維持することができる。
図124は、一部の実施形態による、構成済みノード12322のポリシーを更新するために更新済みポリシーを有するノード12402と通信する構成済みノード12322の例示的な方法12400のラダー図である。図124の方法12400は、図126に関して説明されるIoTデバイス12600によって実施することができる。同様の番号が付けられた項目は、図123に関して説明したとおりである。これは、例えば、構成済みノード12322が、他のノード12402から競合警告メッセージ12340を受信したときに発生し得る。構成済みノード12322は、発見メッセージ12306を更新済みノード12402に送信することができる。
更新済みノード12402は、構成済みノード12322にポリシー更新を警告するオファーメッセージ12314で返信することができる。次いで、構成されたノード12322は、更新されたポリシーを送信し得ることを更新済みノード12402に示すために受け入れメッセージ12316で返答することができる。次いで、更新済みポリシーは、更新済みノード12402から構成済みノード12322へ更新メッセージ12404において送信され得る。確認およびポリシーの完全性チェックの後、構成済みノード12322は、有効なポリシーの完全または部分的な置き換えを実行し得る(12328)。
部分的な置き換えのみが必要であるか否かを判定するために、ポリシー間のデルタを計算するための方法が実装され得る。例えば、新しいポリシーと古いポリシーとの個々の規則間で比較を行って、規則のパラメータ値の変更などによって規則が追加、除去、または変更されているか否かを判定することができる。ブルームフィルタモデルでは、ポリシーの様々なテナントをブルームフィルタの通知として表現できる。ポリシー決定の変更は、パブリッシャであるPDPのサブスクライバであるポリシー施行ポイントに伝播される。本明細書で説明されているように、ブルームフィルタ通知メッセージングによって提供されるのと同じ効率の態様が、分散型ポリシー管理を実装するために活用され得る。
IoTデバイスの数が増えるにつれて、適切なデルタテクノロジが分散型ポリシー管理システムに不可欠になる。デルタファイルのファイルサイズを小さくすると、ネットワーク経由で配信される更新ファイルのサイズが小さくなり、かかる時間が減り、ネットワークの輻輳が少なくなる。ポリシーの更新は、優先度、複雑性、およびサイズの観点から様々であるため、変更のみを送信すると、生成されるファイルがより小さくなり得る。これらのファイルは、例えば、クライアントの要求または要望に基づいて適応デルタ圧縮技法を選択することによって、現在のポリシーと新しいポリシーとの間の差分(またはデルタ)を効果的にカプセル化する。
ポリシーの更新はまた、クライアント側のハードウェアの制限も考慮に入れることがある。例えば、自動車の電子制御ユニット(ECU)、組み込みモジュール、および公益事業、製造、および物流で使用されるマシンツーマシン(M2M)デバイスなど、様々なIoTメッシュネットワークにおいて、デバイスが制約を受ける場合がある。送信された圧縮ファイルは、ハードウェアの容量に応じてのみ再構築できる。それはCPU、メモリ、およびストレージによって制限され得る。受信デバイスにポリシー変更を実装するためのリソースがない場合、送信はこれを見込む必要があり得る。これらの制限は、デバイスごとに異なり得るため、調整可能で適応的なシステムがそれに応じて圧縮することができる必要があり得る。
履歴情報を選択プロセスに組み込む能力は、競合分析アルゴリズムにおける2段階アプローチによって実行され得る。アルゴリズムの第1の段階は、候補ポリシーとデプロイされたポリシーとの間の関係パターンマトリクスを初期化し、第2の段階は、このパターンを競合シグネチャと照合する。一部の解決策では、すべてのデプロイ済みポリシーに対して候補ポリシーを順次比較する。しかしながら、本明細書で説明される例示的な手法は、比較の数を減らすために、アルゴリズムの以前の反復から既に発見されたパターンを再利用することができる。この手法を使用して性能を向上させることができるが、この向上の程度は、デプロイされたポリシー間の関係の性質によって異なる。
ポリシーは階層化されている場合がある。例えば、ポリシーには、仮説チェックなしで実行することを要求するフラグがある場合がある。逆に、ノードは、ポリシーを実装できない場合には、ポリシーの妥協を提案する可能性がある。これは閉ループシステムで実施することができる。一例は、IoTデバイスが5分ごとから5時間ごとに送信間隔を長くすることを要求するポリシーであり得る。実装した場合、このポリシーは、デバイスのQoS要件に違反する可能性がある。デバイスは、毎時の伝送速度を提供することができる。
サイトポリシーによって制御可能な利用可能なパラメータを表すポリシーのセットは、本明細書で説明するように、ブルームフィルタによってさらに表すことができる通知メッセージにそれぞれが対応するポリシーオブジェクト識別子のセットを使用してモデル化することができることを理解されたい。ブルームフィルタに基づく既存の通知配信機能は、ネットワーク管理エンティティによって課されるポリシー変更に対応する通知を配信するために利用され得る。ポリシー変更通知が受信されると、ノードは、ポリシー施行ポイント調整に関するさらなる指示を得るために、ポリシーサーバへのセキュアな接続を開くことができる。
セキュリティを強化するために、非ファイルベースのポリシーを実装することもできる。さらに、非ファイルベースのシステムが、RAMの外部にストレージを欠いているデバイスにポリシーを格納するために使用され得る。一部の態様によれば、デバイスがポリシーを受信すると、ポリシーは格納されず、代わりに、特定のパラメータが、例えば、RAMにおいて更新され、オンザフライで実装される。さらに、ポリシーパラメータがROMに格納されてもよい。セキュアな軽量デバイスでは、ポリシーの実行は、RAMから読み出される一部のパラメータを用いてROMから実行されてもよい。よって、ROMは、カーネルとして動作し、その際、他のすべての機能はRAMで動作し得る。
図125は、一部の実施形態による、構成済みノードによって異なるノードから取得されたポリシーの連結のための例示的な方法のラダー図12500である。図125の方法12500は、図126に関して説明されるIoTデバイス12600によって実施することができる。同様の番号が付けられた項目は、図123に関して説明したとおりである19000。この例では、第1のノード12502はポリシーコンポーネントAを更新し、第2のノード12504はポリシーコンポーネントBを更新した。構成済みノード12322は、構成済みノード12322内のポリシーを更新する必要があることを示す競合警告メッセージ12340を受信したのであってもよい。構成済みノード12322は、第1の発見メッセージ12506を第1のノード12502に送信する。構成されたノードはまた、第2の発見メッセージ12508を第2のノード12504に送信する。それに応答して、第1のノード12502は、ポリシー更新メッセージ12510を構成済みノード12322に送信する。ポリシー更新メッセージ12510は、ポリシーコンポーネントAを含み、これを、構成されたノード12322が現在のポリシーに付加する(12512)。
第2のノード12504は、提供メッセージ12514を構成済みノード12322に送信し、第2のノード12504がポリシーコンポーネントBを有することを構成済みノード12322に知らせる。構成済みノード12322は、受け入れメッセージ12516を第2のノード12504に送信し、更新を受け入れたことを知らせる。次いで、第2のノード12504はポリシーコンポーネントBを含むポリシー更新メッセージ12518を送信し、これを、構成済みノード12322が現在のポリシーに追加する(12520)。これにより、表3に示すように、構成済みノード12322のポリシー構成が他の様々なノードのポリシーコンポーネントの組み合わせになる。
ブルームフィルタ構造がポリシー配信に使用される場合、ポリシーオブジェクトは、ポリシー構造内のライン項目にポリシーオブジェクト識別子(OID)を関連付けることができ、各ポリシーOIDがブルームフィルタ内のビットに対応することができる。この例では、OIDのセットを実装するすべてのノードは、OIDをカバーするブルームフィルタにサブスクライブすることができる。その結果、Pub-Sub型経路指定を実施するのと同じ通知システムを利用して、分散型ポリシー施行の方法を実施することができる。
メッシュネットワーク内のノードは、同じポリシーのすべてを実装すること、またはすべて同じ方法で実装することに限定されない。例えば、バッテリ残量が少なくなっているノードは、バッテリ電力を節約するためのポリシーを実装することができ、この制限を共有しない他のノードは、QoSを維持するポリシーを継続することができる。
図126は、一部の実施形態による、ポリシーの分散管理のためにIoTデバイス12600に存在し得るコンポーネントの一例のブロック図である。同様の番号が付けられた項目は、図3、図8、および図122に関して説明したとおりである。図8に関して説明したIoTデバイス800、および本明細書で説明される他のIoTデバイスに対して選択されたものとは異なるコンポーネントが、IoTデバイス12600に対して選択され使用されてもよいことに留意されたい。
大容量ストレージ808は、本明細書で説明される提携グループ形成を実施するための複数のモジュールを含むことができる。大容量ストレージ808においてコードブロックとして示されているが、モジュールのうちのいずれも、例えば特定用途向け集積回路(ASIC)に組み込まれるなど、ハードワイヤード回路で完全にまたは部分的に置き換えられ得ることが理解されよう。
大容量ストレージ808は、どのポリシーが実施されるかを判定するためのポリシー決定エンジン12202を含み得る。ポリシー施行エンジン12204は、ポリシー決定を実施する。ポリシーリポジトリ12206は、IoTデバイス12600のためのポリシーを格納する。モニタ12208は、メッシュネットワーク812内の他のノード内のモニタと通信し、例えば、ノードによってサポートされるデバイス構成、能力、および機能を含む情報を収集する。
データ収集部12602は、インターフェース818を介してセンサ820からデータを収集することができる。通信部12604は、データ収集部12602から、またはモニタ12208もしくはローカルポリシー決定エンジン12202などの他のユニットから収集されたデータを、メッシュ812内またはクラウド302内の他のデバイスに転送することができる。
図127は、一部の実施形態による、他のIoTデバイスと協働してIoTネットワーク内のポリシーを管理するようにプロセッサ902に指示するためのコードを含む、非一時的機械可読媒体12700のブロック図である。プロセッサ902は、バス904を介して非一時的機械可読媒体12700にアクセスすることができる。プロセッサ902およびバス904は、図9に関して説明したとおりであり得る。非一時的機械可読媒体12700は、図8の大容量ストレージ808について説明したデバイスを含むこともできるし、光ディスク、USBメモリ(thumb drive)、または任意の数の他のハードウェアデバイスを含むこともできる。
非一時的機械可読媒体12700は、他のノード内のポリシーを発見するようにプロセッサ902に指示するためのコード12702を含み得る。コード12704は、他のノードによって送信されたメッセージからポリシーを更新するようにプロセッサ902に指示するために含まれ得る。コード12706は、複数のノードから得られたポリシーを連結するようにプロセッサ902に指示するために含まれ得る。コード12708は、他のノードから得られたポリシーを確認するようにプロセッサ902に指示するために含まれ得る。コード12710は、現在のポリシーからのポリシーについてデルタを計算する、または変更するようにプロセッサ902に指示するために含まれ得る。
コード12712は、グループの目的と矛盾するポリシーを拒否するようにプロセッサ902に指示するために含まれ得る。コード12712は、グループの目的と矛盾するポリシーの部分的実施を交渉するようにプロセッサ902に指示するために含まれ得る。コード12714は、現在の条件に合うように実施されたポリシーを変更するように指示するためにプロセッサ902に含まれ得る。
ポリシーの配信および機能の実行に加えて、IoTデバイスの可用性を維持することは、例えば、IoTデバイスによって収集されたデータの損失を防ぐために役立つことに関係する。IoTデバイスの可用性を向上させ得る技法が、それらの可用性を保証するために帯域外メカニズムを使用する可能性がある。
図128は、一部の実施形態による、IoTデバイスの可用性を改善するために使用され得る例示的な電源プラグデバイス12800の図である。この例では、電源プラグデバイス12800は、220VACプラグに組み込まれている。Linux(登録商標)および他のオペレーティングシステムは、ソフトウェアまたはハードウェアのウォッチドッグと相互作用できる機能を実装している。これらのウォッチドッグは、オンボードの機能であり、それらは組み込みデバイスやIoTデバイスに常に存在するとは限らない。電源プラグデバイス12800は、一般的なまたは実用的なIoTデバイスの可用性を管理するための帯域外メカニズムであり得る。電源プラグデバイス12800は、その利用可能なインターフェース12802のうちの1つまたは複数を介してIoTデバイスと通信することによってこの機能を実行して、IoTデバイスが動作可能であり、正しく機能しているか否かを判定することができる。そうでない場合、電源プラグデバイス12800は、IoTデバイスを健全な状態に戻すための是正措置をとることができる。本明細書で説明されるように、電源プラグデバイス12800は、IoTデバイスの主電源として動作することができる。このようにして、接続されている管理対象デバイスの電源を入れ直すことにより、可用性を向上させることができる。
様々な帯域外管理テクノロジを実装できる。これらの例としては、デスクトップシステムまたはクライアントシステムの場合、Intel(登録商標)CorporationのvProを挙げることができ、サーバシステムまたはデータセンターシステムの場合、Intel(登録商標)CorporationのIntelligent Platform Management Interface(IPMI)を挙げることができる。しかしながら、これらの技術は、組み込みデバイスまたはIoTクラスのデバイスでは利用できない。このように、IoTデバイスは、これらのデバイスは管理上の課題をもたらし得るため、可用性を達成する上で新たなレベルの複雑さをもたらす。
電源プラグデバイス12800は、その電源として標準的な壁コンセントを使用してもよいし、とりわけバッテリによって、またはパワーオーバーイーサネット(登録商標)接続を介して電力を供給されてもよい。基本OS、RTOS、またはBIOSなど、独自のオペレーティングシステムを実行してもよい。
デバイスのユーザまたはオペレータは、デバイスを構成するためにウェブまたは他のインターフェースを使用することができる。デバイスの構成は、管理者およびオペレータのための役割を有し得るログインサービスを含み得る。インターフェースの設定画面は、インターフェースになにか接続されているか否かを示し得る。デバイスに動作上の問題が発生した場合に、いつどのような種類の動作を実行するべきかを決定するための規則またはポリシーとして動作するように、インターフェースにパラメータを設定できる。これらは、例えば、IoTデバイスのサービスまたはオペレーティングシステムを再起動することから、IoTデバイスの電源を入れ直すことまでにわたり得る。
電源プラグデバイス12800は、それ自身の通信チャネルを有することができ、オフラインであるIoTデバイスに連絡するための帯域外メカニズムとして動作することを可能にする。デバイスは、IoTデプロイの要件に合うように製造されてもよいし、広範囲のデバイスに合うように様々なインターフェース12802を用いてより一般的に作られてもよい。インターフェース12802は、例えば、USB接続、イーサネット(登録商標)接続、SPI/I2C/I3C、センサHID、磁力計/無線機、またはJTAGを含み得る。これらのインターフェース12802は、図131に関してさらに説明される。
図129は、一部の実施形態による、電源プラグデバイスの自己適応に基づくグローバルステート遷移のプロット12900である。プロット12900では、IoTデバイスが稼働中か稼働停止中かについて判定12902が行われ得る。別の判定12904が、管理されているIoTデバイスが健全であるか否かに関して行われ得る。本明細書で説明されるように、健全なデバイスは、その指定された機能を実行し、ネットワークと通信しているが、健全ではない装置は、機能を実行していない、通信していない、またはその両方である。
電源プラグデバイスは、IoTデバイスが電力供給されていない、電源プラグデバイスと通信していない、または電源プラグデバイスに応答していないと判定することによって、IoTデバイスが稼働停止中であると判定し得る(12906)。これはいくつかの方法で実行でき、例えば、電源プラグデバイスがSPI、I2C、またはI3Cインターフェースを介してIoTデバイスにインターフェースされている場合、IoTデバイス上のコンポーネントのハードウェアステータスを検出可能であり得る。これらが正しく機能していない場合は、デバイスのリセット、電源の入れ直しなどの修正措置を講じることができる。
さらに、電源プラグデバイスは、オペレーティングシステムがIoTデバイス上で動作しているか否かを判定することによって、IoTデバイスが稼働中であるが健全ではない場合を判定することができる(12910)。これは、IoTデバイスへのディスクのマウント、ポートへのtelnet、別のサービスの起動など、オペレーティングシステムが応答することを証明するためにサービスと通信することでテストできる。電源プラグデバイスは、通信がIoTデバイス上で機能しているか否かを判定することができる。これは、イーサネット(登録商標)接続または別の有線接続を介してIoTデバイスにpingを送信することによってテストできる。それはまた、無線機がIoTデバイス上で送信しているか否かを感知すること、またはIoTデバイスから受信された最後のメッセージについてクラウドフォグサービスに問い合わせることによって実行されてもよい。
電源プラグデバイスは、IoTデバイスからlast willコマンドを受け取っている場合もある。IoTデバイスは、システムがクラッシュした場合に、その通信パスのいずれかまたはすべてにlast willコマンドを発行するように構成され得る。これは、MQTTなどの様々なプロトコルで利用可能な機能であるが、IoTデバイスの開発者がハードウェアレベルで実装して、SPI、I2C、またはI3Cインターフェースバス上に信号を作成することができ、信号は、SPI、I2C、またはI3Cインターフェースを通じて電源プラグデバイスが受信できる。last willコマンドは、IoTデバイスに障害が発生した、またはIoTデバイスがクラッシュしたことを他のデバイスに通知してもよいし、障害またはクラッシュの際に取るべき動作に関する命令を含んでもよい。さらに、IoTデバイス内のウォッチドッグエージェントから電源プラグデバイスへの周期的な「Is Alive」メッセージまたは他のハートビート信号がないことは、IoTデバイスをリセットするためのトリガとして使用され得る。
クラウドまたはメッシュ内の他のデバイスは、IoTデバイスが、稼働停止中12906、または稼働中であるが健全ではない12910のいずれかであると判定し得る。例えば、IoTデバイスがメッセージを設定可能な期間送信しなかったことを検出するクラウドサービスまたはフォグサービスは、IoTデバイスの電源をリセットして健全な状態に戻すことを試みるリモートコマンドを電源プラグデバイスに送信し得る。次いで、電源プラグデバイスは、例えばリセットピンをローに引き下げること、電源を入れ直すことなどによって、IoTデバイスのためのリセットコマンドを実行することができる。
電源プラグデバイスは、リセット生存時間(TTL)を実施することができる。例えば、定期的に、電源プラグデバイスは、IoTデバイスのために定期的に電源を入れ直すことができる。多くのデプロイメントでは、定期的に電源を入れ直すと、稼働時間が長くなり得る。電源を入れ直すことは、スクリプト化されたシャットダウンの方法よりも好ましい場合がある。スクリプト化されたシャットダウンの方法の際には、応答しないプロセスによってオペレーティングシステムがダウンするのが妨げられる場合がある。
これらの例示的な技法を使用して、電源プラグデバイスは、IoTデバイスをより長期間にわたって健全かつ稼働中の象限12908に維持することができる。これにより、電源プラグデバイスがない場合のデプロイよりも、稼働時間が増え、ひいてはIoTデバイスおよびIoTネットワークの信頼性が向上し得る。
図130は、一部の実施形態による、IoTデバイスの信頼性を高めるために電源プラグデバイスを使用するための例示的な方法13000のプロセスフロー図である。図130の方法13000は、図131に関して説明される電源プラグデバイス13100によって実施することができる。ブロック13002は、例えば電源プラグデバイスがブートしたときを表す。ブート中に、電源プラグデバイスは、オペレーティングシステムをロードし、次いで、必要なファームウェアおよびドライバを内部ストレージデバイスからロードする。
ブロック13004において、電源プラグデバイスは、管理対象デバイスのリストを発見する。これには、電源プラグデバイスに接続された単一のデバイス、いくつかのデバイス、またはIoTメッシュネットワークまたはフォグデバイスが含まれ得る。この発見は、動的または静的に実行され得る。動的検出の例としては、電源プラグデバイスに接続されているすべての物理パスをエニュメレーションし、物理的に接続されているものを問い合わせることがあり、あるいは、動的検出の例としては、管理され得る近くのデバイスを発見するためにその無線および通信リンクを通して巡回することを挙げることができる。
デバイスはまた、デバイスに格納されているローカル構成ファイルにリストされている管理対象デバイスの静的リストも含むことができる。電源プラグデバイスは、管理対象デバイスをローカルに格納されているリストに追加する。発見は必要に応じて繰り返されてもよいし、または新しく接続されたIoTデバイスの検出時に実施されてもよい。例えば、センサHIDおよびUSBの存在により、管理対象デバイスのプラグアンドプレイ検出が可能になる。電源プラグデバイスは、新しいIoTデバイスが存在し、管理リストに追加されるべきであるか否かを判定するために無線および通信リンクを周期的に巡回することができる。静的リストは、フォグサービスまたはクラウドサービスから、あるいはRESTfulユーザインターフェースまたはアプリケーションプログラミングインターフェースなどの利用可能にすることができるインターフェースを介して、電源プラグデバイスとの直接的な人間またはデバイスの相互作用を通じてデバイスに提供することができる。
ブロック13006において、電源プラグデバイスは初期化され、動作を開始することができる。電源プラグデバイスは、リモートホストまたはオーケストレーションデバイスからポリシーをロードすることができ、それらはクラウドまたはフォグベースであり得る。デバイス上で実行されるインターフェースを使用して、ポリシーを電源プラグデバイスにロードすることができる。ポリシーは、どの管理対象デバイスがどのポリシーに関連付けられているかを識別するための規則のセットを含むことができる。これは、どの種類の動作がどの種類のデバイスに対して可能であるかについて、オペレータが定義するのをサポートすることを可能にし得る。これは、デバイスへの接続の種類に基づき得る。
ブロック13008において、電源プラグデバイスは、それぞれの接続を介して管理対象のIoTデバイスを監視する。健全性チェックは、本明細書で説明される電力および通信の監視、IoTデバイス内のウォッチドッグエージェントからの健全性に関する報告、またはウォッチドッグエージェントからの健全性報告の受信失敗を含むことができる。任意の数の健全性チェックがあり得、デバイス設計者は、本明細書の前の部分で説明されていない他の方法を実装することができる。運用のこの部分により、管理対象デバイスの機能が定期的にチェックされる。
ブロック13010において、電源プラグデバイスは、ステータスを報告し得る。例えば、管理対象デバイスが予想どおりに機能していない場合は、警報ポリシーを使用して、警報を送信するべきか否か、および送信する警報の種類を判定できる。警報は、警告、エラー、または重大な障害として分類され得る。電子メール、ログに書き込まれたイベント、テキストもしくはSMSメッセージ、または他の種類の警報などの様々なメッセージングメカニズムを警報レベルに関連付けることができる。それらのそれぞれ、またはそれらの組み合わせが、異なるエンドポイント、ユーザ、配信リストなどに送信され得る。
ブロック13012において、電源プラグデバイスは、障害を修正するための措置をとることを試みることができる。例えば、接続の種類に応じて、電源プラグデバイスは、障害が発生している、または障害が発生した管理対象のIoTデバイスで実行されているサービスの封じ込めを試み、デバイスの復旧を試みる前に、障害を修正する措置とることができる。
管理対象のIoTデバイスが無線接続で接続されている場合は、標準のコマンドを使用してデバイスをリモートで再起動またはリセットすることができる。しかしながら、管理対象のIoTデバイスのオペレーティングシステムが応答していない場合、これは機能しない場合がある。従って、パワーオーバーイーサネット(登録商標)(PoE)、USB、またはパワーアウト接続など、IoTデバイスが電力も供給する媒体を介して接続されている場合、電源プラグデバイスは、問題が検出された場合、管理対象のIoTデバイスへの電源の入れ直しを行うことができる。
IoTデバイスがJTAGインターフェースを介して接続されている場合、IoTデバイスをリモートでデバッグし、デバイスファームウェアのフラッシュを提供することなどが可能になる。JTAGインターフェースには、シリアル通信インターフェースを実装する専用のデバッグポートがある。JTAGインターフェースは、電源プラグデバイスから、IoTデバイスのプロセッサ上のテストアクセスポート(TAP)に接続するIoTデバイス上のポートに接続され得る。
管理対象のIoTデバイスは、ネットワーク上の電源プラグデバイスの認識を組み込むように設計され得る。例えば、障害が発生したデバイスを復旧するための有用な方法が電源を入れ直すことであることがわかっている場合、ログをクリーンアップし、一般的なエラーをチェックし、人間の介入なしですべてのプロセスを自動的に再起動するメカニズムを、管理対象デバイスのブートシーケンスに実装できる。この手法は、追加の機能を提供するかもしれないが、認識されていないIoTデバイスの場合でも、電源プラグデバイスは、それらを健全な状態に戻そうと試みるために電源を入れ直すことができる。
図131は、一部の実施形態による、IoTデバイスの可用性を高めるために使用され得る電源プラグデバイス13100内に存在し得るコンポーネントの一例のブロック図である。同様の番号が付けられた項目は、図3および図8に関して説明したとおりである。
電源プラグデバイス13100は、送配電網13104またはパワーオーバーイーサネット(登録商標)接続、バッテリなどの他の電源に結合された電源13102を有することができる。電源13102は、電力コントローラ13106に電力を供給し、電力コントローラ13106は、その電力をIoTデバイス用の外部プラグ13108に供給することができる。電力制御装置13106は、IoTデバイスへの電力を入れ直すことを可能にするためにバス806を介してプロセッサ802に結合されてもよい。
電源プラグデバイス13100は、USBインターフェース13110を備え得る。これにより、電源プラグデバイス13100は、IoTデバイスのUSBクライアントとして動作し、USBを介してIoTデバイスに電力を供給することが可能になる。USBインターフェース13110に結合されたUSBポート13112は、データ結合および電力接続の両方を提供し得る。
ネットワークインターフェースコントローラ(NIC)816は、イーサネット(登録商標)ポート13114を介して、イーサネット(登録商標)接続を有するIoTデバイスへの直接接続を提供することができる。イーサネット(登録商標)ポート13114はまた、例えば、12.95ワット(W)についてはIEEE 802.3atタイプ1で、または25.5WについてはIEEE 802.3atタイプ2で公表されているパワーオーバーイーサネット(登録商標)仕様に従って、IoTデバイスに電力を供給することができる。
電源プラグデバイス13100は、シリアルペリフェラルインターフェース(SPI)バス、I2Cバス、もしくはI3Cバス、またはそれらの組み合わせのためのインターフェース13116を含み得る。このインターフェース13116を介して、電源プラグデバイスは、組み込み装置でしばしば利用可能である通信インターフェースを介してIoTデバイスに直接インターフェースすることができる。インターフェース13116は、電源プラグデバイスの外側に設けられた1つまたは複数のポート13118を介してIoTデバイスに結合することができる。これらのバスのうちの複数のバスが電源プラグデバイス13100内に存在する場合、ポート13118は異なるバスのそれぞれに対して設けられ得る。
電源プラグデバイス13100は、電源プラグデバイス13100が特定のクラスのセンサ820とインターフェースすることを可能にするためにHIDトランスポートインターフェース13120を含み得る。HIDトランスポートインターフェース13120によってサポートされ得るセンサ820は、例えば、とりわけ、周囲温度センサ、湿度センサ、近接センサ、または在否センサを含む。HIDトランスポートインターフェース13120は、SensorHIDと呼ばれるオペレーティングシステム内のHIDクラスドライバによってサポートされ得る。SensorHIDは、HIDトランスポートインターフェース13120を介した電源プラグデバイス13100へのセンサ、ならびにUSBインターフェース13110、またはSPI、I2C、もしくはI3Cバス13116を介してインターフェースされ得るセンサのプラグアンドプレイインターフェースをサポートする機能ブロックである。
電源プラグデバイス13110に結合されたセンサ820は、電源プラグデバイス13110自体を監視するためのセンサ、ならびに温度および湿度などの環境を監視するためのセンサ820、ならびにIoTデバイスを監視するためのセンサ8204を含み得る。IoTデバイスを監視するためのセンサ820は、電力消費センサ、磁力計などを含み得る。これらのセンサは、管理対象のIoTデバイスが送信しているか否かを検出するために使用され得る。
電源プラグデバイス13100は、IoTデバイスへのチップレベルのアクセスを提供してIoTデバイスをリモートからデバッグできるようにするためのJTAGインターフェース13124を含み得る。JTAGインターフェース13124は、電源プラグデバイス13100上のポート13126を介してIoTデバイスに結合することができる。JTAGインターフェース13124はまた、IoTデバイスのための電力リセット機能を可能にし得る。さらに、JTAGインターフェース13124を使用して、IoTデバイス内の不揮発性メモリをリモートでフラッシュすることができる。
電源プラグデバイス13100内の送受信機810および814は、それらの短距離無線機を使用して近くのIoTデバイスと通信するため、または特定のハードウェアシグネチャを有するデバイスが依然として信号を送信しているか否かを証明するために使用され得る。しかしながら、IoTデバイスが機能していない場合、電源プラグデバイス13100が管理対象のIoTデバイスのために電源を入れ直すためには、管理対象デバイスへの物理的接続が必要とされ得る。
電源プラグデバイス13100は、例えば、2009年にISO/IEC 11889としてTrusted Computing Groupによって公表された仕様に準拠する、トラステッドプラットフォームモジュール(TPM)13128を含むことができる。TMP 13128は、暗号化プロセッサ(CP)13130、不揮発性メモリ(NVM)13132、およびセキュアメモリ(SM)13134を含み得る。CP 13130は、とりわけ、乱数発生器、RSAハッシュ発生器、SHA-1ハッシュ発生器、および暗号化-復号エンジンを提供することができる。NVM 13132は、例えばとりわけRSA鍵を含む、製造時にプログラムされた鍵を含み得る。SM 13134は、ソフトウェアで得られた測定値をプラットフォーム構成レジスタに保持することができる。本明細書で使用される場合、測定値は、大容量ストレージ808またはメモリ804に格納されたコードまたはデータセグメント上で計算されたハッシュコードである。
ブートコードセグメントの測定から開始して、初期ブートから信頼チェーンを作成することによって、測定を使用してトラステッド実行環境(TEE)を確立することができる。TPM 13128の代わりに、TEEは、EPID、SGX、または同様の技術などの他の技術に基づいてもよい。TEEは、侵入された電源プラグデバイス13100からの攻撃からIoTデバイスを保護するために使用され得る。
大容量ストレージ808は、本明細書で説明される提携グループ形成を実施するための複数のモジュールを含むことができる。大容量ストレージ808においてコードブロックとして示されているが、モジュールのうちのいずれも、例えば特定用途向け集積回路(ASIC)に組み込まれるなど、ハードワイヤード回路で完全にまたは部分的に置き換えられ得ることが理解されよう。IoTデバイスは、コンピューティングパワーと他のパラメータとの両方に制約されることが多いため、他のデバイスもまた、より単純な回路で実装することができる。例えば、別個のセキュリティコプロセッサとしてのTPMは、IoTのための制約のあるデバイスをターゲットとしたものよりも重要なプロセッサになり得る。従って、TCG TPM仕様で指定されているよりも制約の厳しい「TPM」が採用され得る。さらに、TPM動作などのためのトラステッドコンピューティングプリミティブは、ASICによる解決策よりも市場投入までの時間を短縮するためにFPGAに実装することができる。
本明細書で説明される提携グループ形成ロジックは、13340においてTREアーキテクチャによって表すことができ、本明細書で定義されるようなTPM機能の一部を実装することができる。このロジックも、FPGA、ASIC、または市場投入までの時間、柔軟性、およびコストを最適化するためのハイブリッド手法でインスタンス化できる。
大容量ストレージ808は、基本入出力システムおよびオペレーティングシステム(OS/BIOS)13122を含み得る。これは、電源プラグデバイス13100のオペレーティングシステム(OS)を含む。OS/BIOS 13122は、リアルタイムOS(RTOS)、拡張BIOS、Linux(登録商標) OS、ウィンドウズ(登録商標)カーネル、またはHALとすることができる。OSは、プロセッサ、メモリ、およびストレージの能力に応じて、単純化されたシステムまたはフルシステムのいずれであってもよい。
FW/ドライバ13136は、電源プラグデバイス13100が動作するのに必要な、ファームウェア(FW)として使用される任意のソフトウェアまたはドライバを表す。FW/ドライバ13136は、IoTデバイスとインターフェースするためのドライバおよびポリシーを含み得る。
大容量ストレージ808は、ソフトウェアリポジトリ(SW Repo)13138を含むことができ、ソフトウェアリポジトリ(SW Repo)13138は、電源プラグデバイス13100によって管理されるデバイスへの無線(OTA)アップグレードのためのステージングポイントとして働くことができる。モニタ13140は、管理対象のIoTデバイスを監視するために含まれ得る。
大容量ストレージ808は、とりわけ電源を入れ直すことなど、管理されたIoTデバイスのための動作を回復するために取られるべき動作を実施するためのアクチュエータ13142を含み得る。報告部13144は、報告機能を実行し、管理対象デバイスのステータスについて報告することができる。
図132は、一部の実施形態による、IoTデバイスの可用性を高めるようにプロセッサ902に指示するためのコードを含む、非一時的機械可読媒体13200のブロック図である。プロセッサ902は、バス904を介して非一時的機械可読媒体13200にアクセスすることができる。プロセッサ902およびバス904は、図9に関して説明したとおりであり得る。非一時的機械可読媒体13200は、図8の大容量ストレージ808について説明したデバイスを含むこともできるし、光ディスク、USBメモリ(thumb drive)、または任意の数の他のハードウェアデバイスを含むこともできる。
非一時的機械可読媒体13200は、管理され得るIoTデバイスを発見するようにプロセッサ902に指示するためのコード13202を含み得る。コード13202は、IoTデバイスのリスト13204を構築するようにプロセッサ902に指示することができる。コード13206は、電源プラグデバイスを初期化するようにプロセッサ902に指示するために含まれ得る。コード13208は、管理対象のIoTデバイスを監視するようにプロセッサ902に指示するために含まれ得る。コード13210は、例えば障害が発生したときに、IoTデバイスについて報告するようにプロセッサ902に指示するために含まれ得る。コード13212は、IoTデバイスを作動させて動作を再開させるようにプロセッサ902に指示するために含まれ得る。
IoTデバイスの可用性を保証することに加えて、IoTデバイスの障害に対処するための技法が提供される。これらの技法は、例えば、本明細書で説明されているようにブロックチェーンを使用することによって、他のIoTデバイスに障害を警告することを含み得る。障害を警告されるIoTデバイスは、障害が発生したデバイスに対して、そのデバイスから機能を引き継ぐのに十分に類似したIoTデバイスを含み得る。
図133は、一部の実施形態による、障害が発生したデバイス13302のためのフェイルオーバーメカニズム13300の概略図である。障害が発生したデバイス13302は、独立した電源13306を有するトラステッド信頼性エンジン(TRE)13304を含み得る。TRE 13304は、とりわけASIC、FPGA、またはECなどのハードウェアでブロックチェーンロジック13308を実装することができる。
ホスト環境13310は、ホスト環境13310の健全性および動作についてTRE13304に報告するウォッチドッグメッセージ13314を生成するウォッチドッグエージェント(WA)13312を含み得る。ホスト環境13310は、TRE 13304のハードウェアとは別のホストハードウェア13316上で稼働し得る。
TREは、期待されるウォッチドッグ報告がローカルホストから入って来なくなったときに協力してラストディッチフェイルオーバー機能を実行する、例えば13304の複数のインスタンスを含むメッシュネットワークとすることができる。ウォッチドッグメッセージ13314の欠如は、ホスト環境13310が終了した、または動作不能であるという指示であり得る。この時点での態様は、ノードが停止する前にフェイルオーバーメッセージを配信することである。TRE 13304は、例えば、ピアTREでフェイルオーバーアクションを実行するのには十分な、少量の予備電力で設計されている。
WA 13312は、独立してウォッチドッグメッセージ13314をブロックチェーンに配信することができ、ブロックチェーンオブザーバは、受信したウォッチドッグイベントのパターンを分析してホストの健全性についての結論を引き出すことができる。断続的な損失は、ホスト環境13310またはネットワーク環境における潜在的な障害を示し得る。これらは予防的に修正できる健全性状態である場合もあるが、フェイルオーバーアクションを促さない場合もある。
ウォッチドッグメッセージ13314は、ブロックチェーンロジック13308からのブロックチェーントランザクション13318を通じて、ブロックチェーン13320に書き込まれ得る。ウォッチドッグメッセージ13314をブロックチェーン13320に書き込むことにより、それらを、例えばメッシュまたはフォグネットワーク内の、他のIoTデバイスにわたって同期させることができる。
メッシュネットワーク内の他のIoTデバイスの一部は、障害が発生したデバイスと同様の機能を持ち、予備のサイクルを有する場合があり、それらをフェイルオーバーターゲットとして動作させることができる。例えば、フェイルオーバーデバイス13322または修理/交換無人機13324は、例えば図5~図9に関して定義したように、コンポジットオブジェクトアイデンティティを使用して障害が発生したデバイス13302との機能的互換性を評価することができる。これらの例では、ブロックチェーン13320は、同様に認証され得る類似のオブジェクト型の履歴を含み得る。
フェイルオーバー状態が存在するとき、フェイルオーバーデバイス13322などの類似のオブジェクト型を有するIoTデバイスは、例えばブロックチェーン13320へのトランザクション13326を介して、立候補することを、TRE記録に定期的に登録することによって、ターゲットデバイスになるために競争することができる。TRE 13304は、周期的登録を受信したときに、ブロックチェーン13320から取得された実行可能なフェイルオーバー候補のリスト13328を維持することができる。
TRE 13304によって障害、例えばホスト環境13310内のウォッチドッグエージェント13312からのウォッチドッグメッセージ13314の喪失が観察されるとき、フェイルオーバー動作が適用され得る。始めに、TRE 13304は、最初にローカル戦略13330を実行してホストを復旧することができる。これは、TRE 13304が障害イベントによって損傷を受けていないと想定して適用され得る。TRE 13304によるローカル戦略13330は、ホスト代替イメージ13332をホスト環境13310に復元することを含み得る。
フェイルオーバーデバイス13322などの適切なフェイルオーバーターゲット上のTRE 13304は、ブロックチェーン13320内のウォッチドッグアクティビティを監視することができ(13334)、それが存在しないことに気付くことができる。ローカル戦略13330が失敗した場合、例えば、ローカル戦略13330がある時間窓内に実現されなかった場合、フェイルオーバーデバイス13322などの適切なフェイルオーバーピアが、障害が発生したデバイス13302の役割を担う13336と仮定され得る。これは、フェイルオーバターゲットの権利を主張するトランザクションをブロックチェーン13320にポストすることによって達成することができる。IoTデバイス間のブロックチェーン13320の同期は、第1の要求者が選択され、第2の要求者と競合しないことを保証する。
フェイルオーバーデバイス13322は、障害が発生したデバイス13302を一時的に引き継ぐことができるが、恒久的な解決策を得ることができる。修理または交換無人機13324は、障害が発生したデバイス13302を修理または交換するためにディスパッチされ得る(13338)。修理または交換無人機13324は、例えばブロックチェーン13320を監視してデバイスに障害が発生したと判定することによって、自らを自動的にディスパッチすることができる。交換無人機は、修理無人機またはサービス技術者によって所定の位置に移動される、直接交換であってもよい。一部の例では、交換無人機は、自らを所定の位置に移動させる自律的ユニットであり得る。修理または交換無人機13324が設置されると、障害が発生したデバイス13302の機能を引き継ぎ(13340)、フェイルオーバーデバイス13322を通常の動作に戻すことができる。その時点で、障害が発生したデバイス13302内のTRE 13304は、障害が発生したデバイス13302をデコミッションする(13342)ことができる。ブロックチェーン13320内のアクティビティの観察者は、障害を監視し、障害が発生したデバイス13302を修理、除去または交換するための戦略を計画することができる。
図134は、一部の実施形態による、トラステッド信頼性エンジン(TRE)を使用してフェイルオーバーメカニズムを実装するための例示的な方法13400のプロセスフロー図である。図134の方法13400は、図135に関して説明されるIoTデバイス13500によって実施することができる。TREは、TREを使用してホスト障害を最初に監視しながらデバイスの健全性状態に関するブロックチェーンに通知することによって、自立型戦略を実装することができる。第1の自立型戦略は、損傷した、または障害が発生したホストを復旧するために、例えば障害が発生したデバイス内の破損したイメージを交換するために、交換用イメージを使用することができる。第2の戦略は、フェイルオーバーデバイスを検出し、そのデバイスのワークロードを障害が発生したデバイスからフェイルオーバーデバイスに転送することができる。第3の戦略は、交換または修理無人機などの自動ディスパッチデバイスを使用して交換デバイスをディスパッチすることができる。第4の戦略は、未知の挙動の可能性を減らし、周囲のネットワークデバイスで障害を引き起こすリスクを下げるために、障害が発生したデバイスをデコミッションする。TREはまた、鍵のストレージおよび管理、アテステーションおよび暗号化操作を含むトラステッド実行環境(TEE)機能を実行することができる。方法13400は、TREを含むIoTデバイスに電力が供給されると、ブロック13402において開始する。
ブロック13404において、TREはホスト環境を監視する。これは、とりわけ、メモリ、バス、またはCPUの動作および機能の監視を含み得る。さらに、TREは、ウォッチドッグメッセージまたはpingに関してホスト環境を監視し、ホスト環境が動作していることを確認する。例えば、IoT/デバイスアテステーション測定は、ウォッチドッグ(WD)pingによって生成されたハートビート報告を含む。これは、複数のハートビートまたは最近報告されたハートビートの履歴記録を含み得る。選択された期間、例えば1ミリ秒(ms)、5ms、15ms、またはそれより長い期間にわたってpingが受信されない場合、TREは、ホスト環境に障害があったと判定することができる。
ブロック13406において、TREは、WD pingを含むWDメッセージを生成する。TREアテステーション鍵は、アテステーション要求に応答してWDメッセージに署名するため、またはWDメッセージに署名するために使用され得る。ブロック13408において、例えば、WDメッセージをトランザクションとしてブロックチェーンにコミットすることで、WDメッセージを監視エンティティに送信することができる。WDメッセージ生成ロジックは、TRE内で保護されたままであってよく、それにより、ホストの障害によって影響されることに対するより大きな保証および抵抗が提供される。ブロックチェーン内のWDメッセージを監視しているノードは、様々なサブネット、デバイス、およびネットワークにわたってブロックチェーンの更新を監視できる。
ブロック13410において、IoTデバイスの障害が、例えばTREによってローカルに検出され得る。ブロック13410でローカル障害が検出されなかった場合、リモートデバイスはブロック13412で障害を検出することができる。13412で障害のリモート検出が行われない場合、ブロック13414において、監視は、ブロック13404で再開する。
ブロック13412でリモート障害が検出された場合、ブロック13416において、例えば障害を検出したリモートデバイスによって、プロセス障害メッセージがローカルデバイス内のTREに送信される。ブロック13410でプロセス障害メッセージを受信した場合、またはローカル障害が検出された場合、ブロック13418において、障害処理が開始される。
ブロック13420において、ホストがローカルに復旧可能であるか否かに関する判定が行われる。これは、例えば、ホストに依然として電力が供給されており、特定のコードセグメントでハングアップしたばかりである可能性があることに注目することによって判定され得る。もしそうであれば、ブロック13422において、例えば、障害が発生したデバイスの現在の動作メモリを上書きすることにより、ホスト代替イメージをインストールすることができる。次いで、TREは、ホスト代替イメージのコードでホストデバイスの再起動を試みることができる。TREは、ホスト代替イメージをインストールする前に、ホスト環境の初期再起動を試みることができる。これは、障害がオペレーティングコードの破損によるものではなく、例えばソフトウェアのクラッシュやハングによるものである場合には、時間を節約することができる。
ホスト装置がローカルに復旧可能ではない場合、ブロック13424において、フェイルオーバーデバイスが近くにあるという判定がTREによってなされ得る。フェイルオーバーデバイスが近くにある場合、ブロック13426において、フェイルオーバーデバイスは、ホスト機能の実行を開始するように構成される。
ブロック13424でフェイルオーバーデバイスが近くにない場合、ブロック13428において、ホストが交換可能または修理可能であるか否かに関して判定が行われる。もしそうであれば、ブロック13430において、障害が発生したデバイスの修理または交換を実行するために交換デバイスまたは修理無人機がディスパッチされ得る。ブロック13426で、フェイルオーバーデバイスが識別され、障害が発生したデバイスの機能を引き継いだとしても、ブロック13430において、フェイルオーバーデバイスが通常動作に戻ることを可能にするために、修理または交換無人機が依然としてディスパッチされてもよい。
ブロック13432において、例えば、障害が発生したデバイスの機能が実行されている場合に、障害が解決されたか否かに関する判定が行われる。解決されている場合、方法13400は、例えばブロック13404で通常の監視動作に戻ることによって、ブロック13436で終了する。障害が発生したデバイスがブロック13432で通常の動作に戻っていない場合、ブロック13434において、障害が発生したデバイスはデコミッションされる。障害が発生したデバイスのTREがスリープ状態にされてもよい。この例では、フェイルオーバーデバイスまたは交換デバイスが障害が発生したデバイスの機能を引き継ぎ、障害が発生したデバイスのサービスを提供し続ける。次いで、方法13400は、ブロック13436で終了する。
ホストの障害が悪意のあるものであるシナリオでは、危殆化するイベントは、通常の異常や予期しない挙動と区別がつかない場合がある。TRE環境は、エンドポイントデバイスのセキュリティを向上させ、攻撃者がWDの「sos」メッセージの解放を阻止できなくなる可能性を高める。さらに、攻撃者は、セキュリティ監査の通常の過程で収集されたかもしれない監査証跡証拠を隠蔽する能力において制限され得る。
図135は、一部の実施形態による、トラステッド信頼性エンジンを使用してフェイルオーバー機構を実装するためのIoTデバイス13500に存在し得るコンポーネントの一例のブロック図である。同様の番号が付けられた項目は、図3、図8、および図133に関して説明したとおりである。図8に関して説明したIoTデバイス800、および本明細書で説明される他のIoTデバイスに対して選択されたものとは異なるコンポーネントが、IoTデバイス13500に対して選択され使用されてもよいことに留意されたい。
トラステッド信頼性エンジン(TRE)13304は、例えばトラステッドプラットフォームモジュール(TPM)によって実施される、信頼性ロジックおよび分離を含むトラステッド実行環境(TEE)を提供することができる。従って、TRE 13304は、一般アクセスから保護されている複数の機能ユニットを含み得る。これらの機能ユニットは、IoTデバイス13500内の他の機能ユニットを複製し得る。これらは、本明細書で論じるように、TREロジック13308、ホスト代替イメージ13332、およびブロックチェーン13320を含み得る。加えて、TRE 13304は、マイクロプロセッサ13502と、独立電源13504と、TRE通信部13506と、メモリ13508と、を含み得る。電源13504は、電源ブロック828からの電力に結合してもよいし、または独立した電源、例えば充電器にリンクされたバッテリを有してもよい。
大容量ストレージ808は、本明細書で説明されるトラステッド信頼性エンジンを使用してフェイルオーバー機構を実装するための複数のモジュールを含み得る。大容量ストレージ808においてコードブロックとして示されているが、モジュールのうちのいずれも、例えば特定用途向け集積回路(ASIC)に組み込まれるなど、ハードワイヤード回路で完全にまたは部分的に置き換えられ得ることが理解されよう。
ホストの大容量ストレージ808は、バス806を介してWDメッセージをTRE 13304に送信するウォッチドッグ(WD)エージェント13312を含み得る。本明細書で説明されるように、TRE 13304は、ウォッチドッグメッセージを作成し、そのウォッチドッグメッセージをブロックチェーン13320にコミットすることができる。TREロジック13308は、1つまたは複数の通信リンクを介して、例えばとりわけ、メッシュ送受信機810、アップリンク送受信機814、およびNIC 816を介して、メッシュデバイス812またはクラウド302内の装置にブロックチェーン13320を伝播させることができる。TRE 13304は、必要に応じて送受信機810または814またはネットワークインターフェースコントローラ816に電力を供給することができるTRE通信部13506を介して通信リンクにアクセスすることができる。これは、IoTデバイス13500内のホストシステムに障害が発生したとしても、TRE 13304が外部デバイスとの通信を維持することを保証することができる。
一部の態様によれば、システムの機能のすべてがTRE 13304内に含まれるわけではない。ウォッチドッグエージェント13312に加えて、IoTデバイス13500のストレージ808は、システムに機能を提供する複数の他のブロックを含み得る。例えば、大容量ストレージ808は、TRE 13304の外側にホストブロックチェーン13512を維持するためのホストブロックチェーンロジック13510を含み得る。ホストブロックチェーン13512は、TRE 13304内のブロックチェーン13320内のすべてのトランザクションを含むことができ、より広範なトランザクションのセットを含むことができる。例えば、大容量ストレージ808内のブロックチェーンは、アイデンティティブロック、ピアデバイスブロック、およびメモリの制約のためにTRE 13304内のブロックチェーン13320に存在しない他のブロックを含み得る。
IoTデバイス13500の大容量ストレージ808は、ホストイメージ13514をコピーし、それをバス806を介してTRE 13304に送信して、ホスト代替イメージ13332として保存するためのイメージ作成部13512を含み得る。ホストイメージ13514は、IoTデバイス13500のホスト環境用のオペレーティングシステム、ドライバ、および機能コードを含むことができる。
大容量ストレージ808は、メッシュデバイス812またはクラウド302内のデバイスからパケットまたはフレームを受け取り、パケットまたはフレームを他のメッシュデバイス812、クラウド302内のデバイスなどに送信する通信部13518を含み得る。図45に関して説明したように、通信部13518は、プロトコル間でのパケットの変換、マイクロペイメントの受け入れなどの他の機能を実行することができる。
図136は、一部の実施形態による、トラステッド信頼性エンジンを使用してフェイルオーバー機構を実装するようにプロセッサ902に指示するためのコードを含む、非一時的機械可読媒体13600のブロック図である。プロセッサ902は、バス904を介して非一時的機械可読媒体13600にアクセスすることができる。プロセッサ902およびバス904は、図9に関して説明したとおりであり得る。非一時的機械可読媒体13600は、図8の大容量ストレージ808について説明したデバイスを含むこともできるし、光ディスク、USBメモリ(thumb drive)、または任意の数の他のハードウェアデバイスを含むこともできる。
非一時的機械可読媒体13600は、ハートビートメッセージまたはpingについてホスト環境を監視するようにプロセッサ902に指示するためのコード13602を含み得る。コード13604は、例えばハートビートメッセージを含む、ウォッチドッグメッセージを生成するようにプロセッサ902に指示するために含まれ得る。コード13606は、例えばトランザクションとして、ウォッチドッグメッセージをブロックチェーンにポストするようにプロセッサ902に指示するために含まれ得る。コード13608は、TREに関連付けられたローカルデバイス内の障害を検出するようにプロセッサ902に指示するために含まれ得る。コード13610は、例えばブロックチェーン内のウォッチドッグメッセージを調べることによって、リモートデバイス内の障害を検出するようにプロセッサ902に指示するために含まれ得る。
コード13612は、ホスト環境に現在格納されているイメージの代わりにホスト代替イメージをインストールするようにプロセッサ902に指示するために含まれ得る。コード13614は、フェイルオーバーデバイスを構成するようにプロセッサ902に指示するために含まれ得る。コード13616は、修理または交換用の無人機をディスパッチするようにプロセッサ902に指示するために含まれ得る。コード13618は、障害が発生したデバイスをデコミッションするようにプロセッサ902に指示するために含まれ得る。
特にネットワークの規模が大きくなるにつれて、IoTネットワークのセキュリティが考慮すべき事項になる。秘密鍵のストレージ、更新、および転送中の傍受、不正な鍵の検出、ならびに迅速な新しい鍵の生成は、潜在的な懸念事項である。しかしながら、多くの場合、IoTデバイスは、メモリ、処理能力、およびコンポーネントの制限などの他の問題によって制約を受ける。さらに、IoTネットワークは、データおよび他のすべての機能を共有するために限られた帯域幅を有し得る。よって、デバイス間の通信効率を最大にすることは有用である。
本明細書で説明される技法では、ネットワーク内のIoTノードは、例えば各メッセージと共に完全秘密鍵を受信またはディスパッチする必要がない場合がある。代わりに、それらのIoTノードは、鍵の一部をディスパッチし受信する場合もある。個々のノードが完全な鍵シーケンスを永続的なストレージに格納する必要がないため、通信効率の向上に加えて、これによりセキュアなIoTネットワークの攻撃対象が減少する可能性がある。
図137は、一部の実施形態による、部分鍵13704および13706を使用し、IoTネットワーク内のノード間で交換される鍵13702の構築の概略図である。この例では、注水定理による手法(water filling approach)を使用して、部分鍵13704および13706を使用して鍵13702を構築することができる。鍵13702は循環バッファ13708においてアセンブルされてもよい。各部分鍵13704または13706は、各部分鍵13704または13706内の鍵13712の部分を循環バッファ13708のどこに挿入すべきかを示すオフセット13710を含むことができる。鍵13702は、IoTネットワーク用のサービスにアクセスし、他のIoTネットワークと通信するなどのために使用され得る。
この例では2つの部分鍵13704および13706が示されているが、様々なサイズの複数の部分鍵が循環バッファに格納されてもよい。完全な鍵は、循環バッファを満たすのに十分な部分鍵が追加されたときに識別され得る。この手法では、鍵インデックスが重複することになる可能性があり、これにより、重複する部分鍵バイトは同一であるはずであるため、部分的な鍵検証が可能になる。同様に、これにより、完全な鍵シーケンスが構築される前に不正なデバイスの検出が可能になる。重複する部分鍵バイトが一致しない場合は、デバイスが危険にさらされている可能性があることを示す警報が、メッシュ内の他のデバイスまたは他のユーザに送信され得る。
一般に、一部の態様によれば、IoTネットワーク内の単一のデバイスが完全な鍵を格納することはない。従って、完全鍵を判定するために、綿密に調べて(using a microscope)、単一のデバイスを攻撃または分析することはできない。完全鍵13702がアセンブルされると、それはIoTネットワークまたはフォグデバイスによって使用されて、例えばクラウド内の他のデバイスにアクセスすることができる。
図138は、一部の実施形態による、IoTネットワーク内の個々のノードに格納されている部分鍵から完全な鍵をアセンブルするための例示的な方法13800のプロセスフロー図である。図138の方法13800は、図140に関して説明されるIoTデバイス14000によって実施することができる。ブロック13802は、例えば、クラウド内のシステムにアクセスするために完全鍵がフォグデバイスによって必要とされるときを表す。
ブロック13804において、部分鍵の最初の部分がディスパッチされる。これは、ノードがペイロードを構築し、それを要求したノードに部分鍵を含むペイロードを送信するために有線または無線通信を開始するときに行われ得る。部分鍵のディスパッチはまた、他のノードが部分鍵をピアノードに送信する要求としても機能し得る。
ブロック13806において、要求側ノードは、送信ノードから部分鍵の一部を受信する。ブロック13808において、要求側ノードは、ペイロードを分析して、それが部分鍵およびオフセットを含むか否かを判定する。そうでない場合、プロセスフローはブロック13806に戻る。
ブロック13808でペイロードが部分鍵を含むと判定された場合、ブロック13810において、要求側ノードは、部分鍵をクロスチェックして、受信された部分鍵が他の部分と重複するか否かを判定することができる。これは、例えば、バッファインデックスの比較を行うことを含む複数の方法で実行され得る。さらに、部分鍵パートは、循環バッファに格納されてもよく、そして、いずれかの部分が他の鍵と重複する場合、それらは重複する部分が一致することを確認するために比較され得る。重複する部分が一致しない場合は、デバイスが危険にさらされている可能性を示し得る。もしそうであれば、アセンブルプロセスは停止され、警告が送信され得る。
他の技法によってさらなるセキュリティが提供され得る。例えば、「ダーティビット」は、部分鍵による使用のために割り当てられ得る巡回鍵バッファ内の各「セル」に対して維持され得る。以前に使用されたセルが後続の鍵部分のメンバとして選択されたときにセキュリティの弱点が導入され得る。この可能性のある弱点を修正するために、最初の割り当て時にダーティビットを設定し、その後の重複検証時にチェックすることができる。重複チェックがダーティビットを明らかにした場合、循環バッファオフセット計算が繰り返されて、これがダーティセルではないか否かを判定する。鍵生成方法に十分な未使用の鍵素材が見つかるまで、このプロセスが繰り返される。
ブロック13812において、すべての部分鍵が受信されたか否かに関する判定が行われる。そうでなければ、プロセスフローはブロック13806に戻る。すべての部分鍵が受信されている場合、ブロック13814において、完全鍵が構築され得る。
方法13800は、ブロック13816で終了する。これは、例えば、完全鍵がフォグデバイスの代わりに他のデバイスに提供されるときに起こり得る。
図139は、一部の実施形態による、5つのノードA~Eによって提供される部分鍵からの完全な鍵13902のアセンブリの概略図である。この例では、5つのノードA~Eは、それらの部分鍵を互いに交換する。各ノードA~Eは、循環バッファ内において指定されたオフセットで受信した鍵を配置することによって完全鍵を構築することができる。オフセットは{N:x,O:y}で表すことができ、xは部分鍵のバイト数Nであり、yは完全鍵13902における部分鍵の開始インデックス、すなわちオフセットOである。
例えば、循環バッファ13904がノードAに配置されている場合、ノードAからの部分鍵A 13906は、既に循環バッファ13904に配置されている可能性がある。次いで、部分鍵B 13908をノードBから受信することができる。この例では、部分鍵B 13908の最初のバイトが部分鍵A 13906の最後のバイトと重複し、重複するバイトが2つの部分鍵13906と13908との間で一致することを保証するために、バイト比較13910が実行され得る。バイト比較13910によって、重複するバイトが2つの部分鍵13906と13908との間で一致すると判定された場合、ノードBからの部分鍵は、循環バッファ13904にロードされ得る。
次いで、ノードAは、ノードCから部分鍵C 13912を受信し得る。部分鍵C 13912は、前の部分鍵13906および13908のいずれとも重複しないため、バイト比較なしでバッファにロードされ得る。部分鍵C 13912は、循環バッファ13904の末尾と重複するオフセットおよび長さを有することができ、従って、13912を参照する部分鍵の末尾のバイトは、矢印13914によって示されるように循環バッファ13904の先頭に入るように回転され得る。
次いで、ノードAは、ノードDから部分鍵D 13916を受信することができる。部分鍵D 13916の末尾のバイトが部分鍵C 13912の先頭のバイトと重複するとき、2つのバイトが確実に一致するようにバイト比較13918が実行され得る。これが確認されると、次いで、部分鍵D 13916を循環バッファ13904にロードすることができる。
次いで、ノードAは、ノードEから部分鍵E 13920を受信することができる。部分鍵D 13916とE 13920との間でバイトに実質的な重複があるため、それらが一致することを保証するためにバイト比較13922がこれらのバイトのそれぞれに対して実行され得る。もしそうであれば、次いで、ノードE部分鍵E 13920を循環バッファ13904にロードして完全鍵13902を形成することができる。
重複が発生すると、重複する部分パートが一致することを確認するためにバイト検証が行われる。そうでなければ、プロセスは終了されてもよく、危殆化したノードの可能性が報告され得る。重複するバイトはまた、1つまたは複数のノードがそれらの部分鍵をネットワーク内の他のノードと交換することができない可能性がある場合に冗長性を提供することができる。そうでなければ、例えば直交するすべての部分鍵がバイト重複を有さない場合、すべてのノードが完全鍵13902を構築するのに失敗する場合がある。
図140は、一部の実施形態による、IPメッシュネットワーク812内の異なるノードからの複数の部分鍵を単一の完全な鍵にアセンブルするためのIoTデバイス14000に存在し得るコンポーネントの一例のブロック図である。同様の番号が付けられた項目は、図3および図8に関して説明したとおりである。図8に関して説明したIoTデバイス800、および本明細書で説明される他のIoTデバイスに対して選択されたものとは異なるコンポーネントが、IoTデバイス14000に対して選択され使用されてもよいことに留意されたい。
大容量ストレージ808は、本明細書で説明される提携グループ形成を実施するための複数のモジュールを含むことができる。大容量ストレージ808においてコードブロックとして示されているが、モジュールのうちのいずれも、例えば特定用途向け集積回路(ASIC)に組み込まれるなど、ハードワイヤード回路で完全にまたは部分的に置き換えられ得ることが理解されよう。
大容量ストレージ808は、1つまたは複数の通信リンクを介して、例えばとりわけ、メッシュ送受信機810、アップリンク送受信機814、およびNIC 816を介して、メッシュデバイス812またはクラウド302内のデバイスに対してパケットを送信および受信する通信部14004を含むことができる。図140に関して説明した機能に加えて、図45に関して説明したように、通信部14004は、プロトコル間でのパケットの変換、プルーフオブプロヴェナンス追加などの他の機能を実行することができる。さらに、通信部14004は、図33を参照して説明した通行権システムの一部とすることができる。
部分鍵生成部14002は、例えば、乱数発生器、ブロックチェーンから、または製造中にデバイスに保存された鍵から、部分鍵を生成し得る。一例として、鍵は、Intel(登録商標)デジタル乱数発生器(DRNG)またはDRNGを使用してシードされた擬似乱数発生器(PRNG)を使用して生成することができる。部分鍵生成部14002は、本明細書で説明されるように、ブロックチェーンからの鍵にアクセスすることなど、部分鍵を生成するために任意の数の他の技法を使用することができる。
別の例示的な部分鍵生成方法は、例えばPRNGモードではない場合にDRNGから取得された、ランダムシードを受け入れるDRNGを使用することができ、DRNGのワードサイズアーキテクチャによって判定されるように、循環バッファ上のサーチスペースは事実上無制限であり得る。この例では、循環バッファへのオフセットは、PRNGモードのIntel(登録商標)DRNGのシードとみなされる。従って、循環バッファは事実上無限サイズであり、バッファ内の衝突が確率的に不可能であることを保証する。
通信部14004は、フレームのペイロードに部分鍵を含むフレームを構築することができる。一部の例では、部分鍵を含むフレームは、よりリモートのデバイスなど、メッシュデバイス812内の別のIoTデバイスから渡され得る。この例では、IoTデバイス14000は、メッシュデバイス812の他のIoTデバイスから受信した部分鍵をアセンブルして、最終鍵を形成することができる。
バイト比較部14006は、重複するバイトが同一であることを保証するために、異なるデバイスから受信された部分鍵の重複するバイトを比較するために含まれ得る。バイト比較部14006は、重複しているバイトのいずれかが一致しない場合、このことがIoTデバイスが危険にさらされたことを示し得るので、最終鍵をアセンブルするプロセスを停止し得る。
鍵アセンブラ14008は、最終鍵を形成するために、循環バッファ14010内で部分鍵のそれぞれをアセンブルすることができる。鍵オペレータ14012は、メッシュまたはフォグデバイス812のアイデンティティを確認するためにゲートウェイに鍵を提供するなどの動作において、最終鍵を使用することができる。
図141は、一部の実施形態による、部分鍵を受信し、部分鍵を最終的な鍵にアセンブルし、最終的な鍵を使用する、ようにプロセッサ902に指示するためのコードを含む、非一時的機械可読媒体14100のブロック図である。プロセッサ902は、バス904を介して非一時的機械可読媒体14100にアクセスすることができる。プロセッサ902およびバス904は、図9に関して説明したとおりであり得る。非一時的機械可読媒体14100は、図8の大容量ストレージ808について説明したデバイスを含むこともできるし、光ディスク、USBメモリ(thumb drive)、または任意の数の他のハードウェアデバイスを含むこともできる。
非一時的機械可読媒体14100は、受信デバイスに部分鍵をディスパッチするようにプロセッサ902に指示するためのコード14102を含み得る。コード14104は、部分鍵を受信し、その部分鍵を格納するようにプロセッサ902に指示するために含まれ得る。コード14106は、例えば、最終鍵をアセンブルする前に重複バイトが一致することを保証するために、重複バイトについてバイト比較を実行するようにプロセッサ902に指示するために含まれ得る。コード14108は、部分鍵を循環バッファに書き込み、デバイスから受信した部分鍵から循環バッファにおいて最終鍵をアセンブルするようにプロセッサ902に指示するために含まれ得る。コード14110は、例えば、デバイスまたはIoTネットワーク内のデバイスに代わってクラウド内のデバイスにアクセスするために、最終鍵を使用するようにプロセッサ902に指示するために含まれ得る。
暗号通貨に対する鍵ベースの手法のセキュリティに対する金銭的な懸念は、ブロックチェーンの文脈におけるデジタルウォレットと匿名の鍵ベースのアイデンティティの出現によって提起されている。デジタルウォレットは、個人がトランザクションのために電子支払いをすることを可能にするシステムである。デジタルウォレットは、銀行口座にリンクされる場合もあるし、別の口座から転送された残高を格納する場合もある。一部の例では、デジタルウォレットは、通信、暗号化、および機能を実装するための他のシステムを含む、スマートフォンなどの電子デバイス内のソフトウェアで実装され得る。他の例では、デジタルウォレットは、RFIDタグとして実装され、システムは、通信システムからアクセスされる中央サーバ上に存在し得る。
ブロックチェーンでのトランザクションは、デジタルウォレットのオーナーの秘密鍵によって署名されており、これらの秘密鍵の紛失、すなわち漏洩によって攻撃者はデジタルウォレットを一掃することができる。これは、そのデジタルウォレットによって所有されている未使用の通貨残高が別のオーナー、例えば攻撃者のオーナーに転送されるプロセスである。
一般に、ブロックチェーンのコンセンサスメカニズムには、そのようなトランザクションを不正と識別するための方法がない。事実の後にブロックチェーンを探索すれば通貨がたどった経路を特定できるが、そのような技術の規制されていない性質は、トランザクションを取り消すために利用可能な実用的な方法が禁止されており、拡張性がないことを意味する。関与する当事者のアイデンティティは、より深い調査なしにはわからないため、これはより困難になる可能性がある。さらに、第三者への同じコインのその後のトランザクションは、ロールバックするのが問題となる。従って、そもそも状況を防ぎ、デマンドドリブン型鍵生成の概念を導入することによって、ブロックチェーン内のアクターがさらされることを減らすことを模索することが好ましい場合がある。
図142は、一部の実施形態による、損失の多いネットワーク上のデバイスに対する要求に応じて鍵を生成するための手続き14200の概略図である。本明細書で説明するように、デマンドドリブン型鍵生成は、本明細書で説明する鍵生成のための技法のいずれかを使用して、定期的にスケジュールされたものではなくオンデマンド方式で、デジタルウォレットがトランザクション用の新しい鍵を生成できるようにする。オンデマンドは、すべてのトランザクションに対して新しい鍵生成を実行し、それを一度だけ使用することに相当する。同じメカニズムは、システムアクセスや他の一般的な鍵ベースの技術のアプリケーションにも適用できる。
この手続きは、トランザクションがネットワークにコミットされたとき、ブロック14202において開始し得る。これは、例えば、購入が行われ、購入に対する支払いのためにデジタルウォレットが使用されるときに行われ得る。購入は、オンラインで行われてもよく、または例えば、デジタルウォレットを含むデバイスが通信パッド上でタップされたときに小売店で行われてもよい。
ブロック14204において、新しい鍵が生成され得る。これは、標準的なビットコインの例に関連し得る、ブロック14206に示される手続きによって実行され得る。さらに、本明細書で論じられている他の手続きを使用することができる。この手続きでは、ウォレットインポートフォーマット(WIF)秘密鍵を使用して、256ビットの秘密鍵14210をインポートすることができる。256ビットの秘密鍵14210を使用して512ビットの公開鍵14212を生成することができ、これを使用してウォレットアドレス14216に関連付けられ得る160ビットの公開鍵ハッシュ14214を生成することができる。ブロック14218において、古い鍵を削除することができる。新しい鍵を生成することは、ブロック14206に示される手続きに限定されない。例えば、図143に関して説明した手続きを使用して新しい鍵を生成することができる。
図143は、一部の実施形態による、上述の鍵生成のための、ならびに他の状況で鍵を生成するためのオンデマンドプロセスで使用され得る鍵生成方法14300の概略図である。図143の方法14300は、図145に関して説明されるIoTデバイス14500によって実施することができる。損失のある高レイテンシネットワークでの迅速な鍵生成は挑戦的な課題のままであるが、それは、IoTネットワークには、エンドツーエンドの接続性、永続的なセキュアな接続、集中型鍵認証局および発行エージェント、そして鍵交換をサポートするための安価な通信およびネットワークがあるという、しばしば誤った仮定のためである。ローカル鍵生成のための方法14300は、命令ノードがオフセット値をディスパッチし、完全鍵または部分的な鍵が必要とされないときに使用され得る。例えばベンダによって提供されるローカル鍵14304と共に完全部分鍵14302を使用することができる。ローカル鍵14304は循環バッファに格納されてもよく、新しい鍵が、完全部分鍵14302およびローカル鍵14304の循環排他的論理和(XOR)演算14306によって生成されてもよい。
その後、新しい鍵14308をアクセスに必要なときに使用することができる。完全部分鍵14302とローカル鍵14304との間のオフセットを変更することによって、鍵オフセットを使用して複数の新しい鍵を生成することができる。この例では、リモート制御ノードは、新しい鍵を生成するためのオフセット値だけを送信することができる。
図144は、一部の実施形態による、鍵を生成するための例示的な方法14400のプロセスフロー図である。図144の方法14400は、図145に関して説明されるIoTデバイス14500によって実施することができる。一般に、鍵管理は比較的静的である。鍵は、いったん生成されると、危険にさらされた状況が検出されるまで、時折リフレッシュが必要になるまでなど、使用される。しかしながら、IoTネットワークでは、混乱やエンドツーエンドの接続の欠如が一般的に発生する可能性がある。従って、鍵のリフレッシュ、および大規模なデバイスネットワークへの鍵のセキュアなディスパッチは困難な場合がある。本明細書で説明される技法は、人間の直接介入なしに絶えず鍵を変更することを可能にし得る。方法14400は、例えば、オペレーティングシステムが、鍵を変更するときであると判定したとき、または鍵を変更する要求が受信されたときに、ブロック14402において開始され得る。
ブロック14404において、鍵オフセット値が受信されたか否かに関する判定が行われる。受信されていない場合、ブロック14406において、その鍵に対するオフセット値がIoTデバイスにおいて生成され得る。ブロック14408において、部分鍵がIoTデバイスによって受信され得る。例えば、部分鍵が既にIoTデバイスによって受信されている場合、これは必要ない場合もある。部分鍵は、他のIoTデバイスから受信された他の部分鍵と共に、例えば、図137~図141に関して説明したように、完全部分鍵をアセンブルするために使用され得る。
ブロック14410において、例えば、図140または図143に関して説明したように、新しい鍵を生成することができる。ブロック14412において、新しい鍵を検証することができる。検証は、他のノードからの標準メッセージを復号することによって実行されてもよい。
ブロック14414において、鍵が期限切れになっているか否かに関する判定が行われ得る。期限切れである場合、方法14400は、ブロック14404に戻って新しい鍵を生成することができる。
ブロック14414で鍵が期限切れになっていない場合、ブロック14416において、データファイルの暗号化または復号が実行され得る。ブロック14418において、方法14400は、例えば、暗号化ファイルの送信または復号化ファイルの使用で終了する。
本方法では、内部循環鍵生成部へのオフセット値をノードにディスパッチすることができる。さらに、部分鍵をノードにディスパッチすることができるが、ノードは、自身の鍵を生成することができ、新しい鍵をノードに送信する必要性を低減させ得る。鍵の再生成は、定期的にスケジュールされて実行されてもよい。
図145は、一部の実施形態による、オンデマンドで鍵を生成するためのIoTデバイス14500に存在し得るコンポーネントの一例のブロック図である。同様の番号が付けられた項目は、図3および図8に関して説明したとおりである。図8に関して説明したIoTデバイス800、および本明細書で説明される他のIoTデバイスに対して選択されたものとは異なるコンポーネントが、IoTデバイス14500に対して選択され使用されてもよいことに留意されたい。
大容量ストレージ808は、本明細書で説明される鍵生成プロセスを実施するためのいくつかのモジュールを含むことができる。大容量ストレージ808においてコードブロックとして示されているが、モジュールのうちのいずれも、例えば特定用途向け集積回路(ASIC)に組み込まれるなど、ハードワイヤード回路で完全にまたは部分的に置き換えられ得ることが理解されよう。
大容量ストレージ808は、1つまたは複数の通信リンクを介して、例えばとりわけ、メッシュ送受信機810、アップリンク送受信機814、およびNIC 816を介して、メッシュデバイス812またはクラウド302内のデバイスに対してパケットを送信および受信する通信部14502を含むことができる。図145に関して説明した機能に加えて、図45に関して説明したように、通信部14502は、プロトコル間でのパケットの変換、プルーフオブプロヴェナンス追加などの他の機能を実行することができる。さらに、通信部14502は、図33を参照して説明した通行権システムの一部とすることができる。
トランザクション部14504は、例えば、クラウド302内またはフォグ812のデバイスからのような品目を購入する、または貸すために、トランザクションをネットワークにコミットすることができる。トランザクション部14504は、前に生成された鍵を使用して、トランザクションが終了した後に新しい鍵の生成をトリガすることができる。別の例では、トランザクション部14504は、トランザクションをネットワークにコミットするための新しい鍵を生成することができる。
他の例では、トランザクション部14504は、特定の期間の間、鍵を使用することができる。鍵有効期限タイマ14506は、新しい鍵が生成される前に鍵が使用され得る期間を制御し得る。例えば、鍵有効期限タイマ14506は、鍵が1分、5分、30分、1時間、またはそれ以上持続することを可能にし得る。
鍵生成部14508は、図143に関して説明したように、例えば循環バッファ14510を使用してローカル鍵14304と完全部分鍵14302のXORを実行することにより、新しい鍵を生成することができる。完全部分鍵14302は、図137~図141に関してさらに説明したように、他のIoTデバイスから受信された部分鍵からアセンブルされてもよい。例えば、通信部14502は、フレームのペイロードに部分鍵を含むフレームを受信することができる。この例では、IoTデバイス14000は、メッシュデバイス812の他のIoTデバイスから受信した部分鍵をアセンブルして、完全部分鍵14302を形成することができる。
図146は、一部の実施形態による、オンデマンドで鍵を生成するようにプロセッサ902に指示するためのコードを含む、非一時的機械可読媒体14600のブロック図である。プロセッサ902は、バス904を介して非一時的機械可読媒体14600にアクセスすることができる。プロセッサ902およびバス904は、図9に関して説明したとおりであり得る。非一時的機械可読媒体14600は、図8の大容量ストレージ808について説明したデバイスを含むこともできるし、光ディスク、USBメモリ(thumb drive)、または任意の数の他のハードウェアデバイスを含むこともできる。
非一時的機械可読媒体14600は、送信デバイスから部分鍵を受信するようにプロセッサ902に指示するためのコード14602を含み得る。コード14602は、異なる送信デバイスから受信した複数の部分鍵から完全部分鍵をアセンブルすることができる。コード14604は、完全部分鍵およびデバイスに格納されている鍵から鍵を生成するためのオフセット値を受信するようにプロセッサ902に指示するために含まれ得る。コード14606は、例えばオフセット値を使用して、新しい鍵を生成するために、完全部分鍵およびデバイス鍵を用いて論理演算を実行するために含まれ得る。コード14608は、他の技法を使用して、例えば、図147から図151に関して説明されるように、新しい鍵を取得するためにブロックチェーンにアクセスすること、新しい鍵をランダムに生成すること、またはエントロピー多重化技法を使用することを使用して、新しい鍵を生成するようにプロセッサ902に指示するために含まれ得る。コード14610は、例えばタイマが特定の値に達したときに、鍵を期限切れにするようにプロセッサ902に指示するために含まれ得る。コード14612は、鍵を使用してデータを暗号化または復号するようにプロセッサに指示するために含まれ得る。
状況によっては、ノード間のシグナリングおよび同期の失敗によって分散型協調が複雑になることがある。例えば、ピアIoTデバイスがスリープしている場合もあるし、ネットワーク接続が信頼できない場合もある。この場合、協調ピアはエントロピー多重化概念を使用して、暗号化のための時間対称鍵、メッセージ完全性コードなどについて合意することができる。
図147は、一部の実施形態による、新しい鍵を生成するために使用され得る複数のシードを生成するためのエントロピー多重化プロセス14700の概略図である。エントロピー多重化プロセス14700は、乱数発生器をシードするために使用されるシード値のシードツリー14702を構築する。シードツリー14702の構造は、時間、位置、近接性、または分類法またはオントロジー分解法を使用して記述することができる他の任意の属性クラスなどのコンテキスト属性と相関させることができる。この例では、エントロピー多重化プロセス14700は、少なくとも部分的には時間に基づいている。
シードツリーはまた、図140に関して説明したように、無限サイズの循環バッファとして見ることができるPRNGを使用することができる。ツリーコンテキストは、ツリー構築のための繰り返し可能な規約に基づいてバッファへのオフセットを設定する。
協働ノードは、タイムルート14704を選択し、第1のシード値14706を生成し得る。第1のシード値14706は、オントロジーにおける開始点として使用されてシードツリー14702を生成することができる。例えば、第1の下位レベルのシード14708は、第1のシード値14706の年の値14710を使用して生成され得る。例えば、月の値14712を使用して、第2の下位レベルのシード14714を生成することができる。例えば、日の値14716を使用して、第3のレベルのシード14718を生成することができる。シードツリー14702内のさらなるレベルは、数分、またはさらには数秒など、連続的に細かいインクリメントを使用して生成され得る。
協働ノードは、第1のシード値14706とオントロジーの開始点について合意することができる。次いで、協働ノードは、シードツリー14702の個別のコピーを別々に生成し保存することができる。例えばオントロジー的文脈に関して共有される秘密が必要とされるとき、協働ノードは、共通の秘密を見つけるシードツリー14702のローカルコピーを探索するためにそのコンテキストを独立して使用することができる。次いで、これを使用して、協調ノード間の通信およびデータを暗号化するための対称鍵を生成することができる。
シードツリーを生成するために任意の数の他のオントロジーパラメータを使用することができる。例えば、住所情報、GPS座標、IPアドレスなどの位置情報を含む。
図148は、一部の実施形態による、ロケーションシードツリー14802を生成するためのプロセス14800を示す概略図である。図147に関して説明したシードツリー14702の生成に関しては、ロケーションシードツリー14802は、ロケーションルート14804、初期シード14808、およびツリーオントロジーが合意されると、いくつかの協働ノードによって独立して生成され得る。例えば、アドレスシードツリー14810は、最初に位置14814の大陸からシード14812を生成することによって初期シード14808から生成され得る。次いで、国指定14816から下位レベルのシードが生成され得る。次いで、都市指定14818からさらに低位レベルのシードを生成することができる。必要に応じて、街路指定または住所生成からさらなるレベルを生成することができる。
他の位置パラメータから他の種類の場所シードツリー14802を生成することができる。例えば、GPS座標14820を使用して、座標シードツリー14822内にコードおよびシードツリー14822を生成することができ、下位レベルのシードを、とりわけ、緯度指定14824、経度指定14826、または高度指定14828から生成することができる。IPアドレス指定14830から他のタイプのロケーションシードツリー14802を生成することができ、下位レベルシードを生成するためにIPアドレス14832の小部分を使用することができる。
複数のコンテキストが、HMACなどの擬似ランダム関数(PRF)を使用して複数の値を組み合わせることによって、コンポジット共有秘密を生成するために組み合わされ得る。これは、時間指定から生成されたシードを位置指定から生成されたシードと組み合わせることを含み得る。
図149は、一部の実施形態による、エントロピー多重化を使用してシードを生成し、それらのシードを使用して暗号化通信用の鍵を生成するための例示的な方法14900のプロセスフロー図である。図149の方法14900は、図150に関して説明されるIoTデバイス15000によって実施することができる。ブロック14902は、例えば、IoTデバイスがネットワークに参加して暗号化通信に共通鍵を必要とするときを表す。
ブロック14904において、IoTデバイスにわたって共通のコンテキスト属性が識別される。コンテキスト属性は、例えば、時間、位置、活動、関心などを含み得る。ブロック14906において、コンテキスト属性のそれぞれを分解して、サブ属性のセットを形成し得る。サブ属性は、コンテキスト属性のためのシードツリーを生成するために使用され得る。ブロック14908において、ランダムシード値が各シードツリーのルートに対して生成され得る。
ブロック14910において、各ルートのシードが盗難や紛失などの物理的脅威から保護するために使用されているか否かに関する判定が行われ得る。そうである場合、プロセスフローはブロック14912に進む。ブロック14912において、暗号秘密共有を使用して、ルートシードをM個のN個の共有に分割し得る。ブロック14914において、M個のシェアがN個のデバイスにわたってプロビジョニングされる。ブロック14916において、デバイスは、例えばネットワークの実装中に物理的に分散される。ブロック14910で物理的脅威から保護するために分散型ルートシードが必要とされない場合、ブロック14918において、シードは各参加者デバイスに供給され得る。
ブロック14902~14918が完了すると、ネットワーク内のIoTデバイスは共通の秘密を生成してデータおよび通信の暗号化のための対称鍵を生成し得る。ブロック14920において、ルートシードが配信されているか否かに関する判定が行われ得る。そうである場合、ブロック14922において、ネットワークを使用して、N個のデバイスからルートシードの各シェアを取得し得る。これは、各シェアを取得するためにQRコード(登録商標)ディスプレイおよびリーダを含むパーソナルエリアネットワークを使用して実行され得る。
ブロック14924において、ルートシードを使用してシードツリー内の各ノードのためのランダム値を生成し得る。これは、各コンテキスト属性および階層的分解に対して実行され得る。
ブロック14926において、コンテキスト属性が真であるか否かに関する判定が行われる。これは、どのシードツリーが、もしあれば、暗号化鍵を生成するのに使用されるべきであるかを識別する。ブロック14928において、コンテキスト属性に対応するシードを使用して暗号鍵を生成する。
ブロック14926でどのコンテキスト属性も真でない場合、ブロック14930において、循環部分鍵がサポートされているか否かに関する判定が行われる。サポートされている場合、ブロック14932において、ネットワーク内の他のIoTデバイスによって提出された部分鍵から部分暗号鍵が生成またはアセンブルされる。
ブロック14934において、暗号鍵を使用してデータを保護する。例えば、第1のIoTデバイスから別のIoTデバイスに送信されるデータは、送信される前に暗号化されてもよい。同様に、暗号鍵は他のIoTデバイスから送信されたデータを復号するために使用されてもよい。
プロセスは、データが復号または暗号化されると、ブロック14936において終了する。ブロック14930で、どの循環部分鍵もサポートされていないと判定された場合も、プロセスはブロック14936において終了する。
図150は、一部の実施形態による、IPメッシュネットワーク812内の異なるノードからの複数の部分鍵を単一の完全な鍵にアセンブルするためのIoTデバイス15000に存在し得るコンポーネントの一例のブロック図である。同様の番号が付けられた項目は、図3および図8に関して説明したとおりである。図8に関して説明したIoTデバイス800、および本明細書で説明される他のIoTデバイスに対して選択されたものとは異なるコンポーネントが、IoTデバイス15000に対して選択され使用されてもよいことに留意されたい。
大容量ストレージ808は、本明細書で説明される提携グループ形成を実施するための複数のモジュールを含むことができる。大容量ストレージ808においてコードとして示されているが、モジュールのうちのいずれも、例えば特定用途向け集積回路(ASIC)に組み込まれるなど、ハードワイヤード回路で完全にまたは部分的に置き換えられ得ることが理解されよう。
大容量ストレージ808は、シードツリーの生成のためのコンテキストを判定するためのコンテキスト識別部15002を含み得る。本明細書で説明されているように、コンテキストは、例えば、時間、位置、IPアドレス、または任意の数の他のパラメータに基づいてもよい。
シードツリー生成部15004は、コンテキストのシードツリーを生成し得る。これは、例えば、時間を年、月、日、分などに分解することなど、コンテキストを部分に分解することを含み得る。シードツリー生成部15004は、その時の年の値から、年の値でマイナス1またはマイナス2の値のシードを設定するなど、分解された値の周囲でそのタイプの時間インクリメントを選択することによって、異なる階層レベルでシードを作成することができる。
次いで、シード生成部15006は、階層シードツリー内のノードに対するルートシードおよびシード値を生成するために使用され得る。シード値は、そのノードの分解されたレベルのコンテキストを使用して生成された乱数であり得る。
通信部15008は、1つまたは複数の通信リンクを介して、例えばとりわけ、メッシュ送受信機810、アップリンク送受信機814、およびNIC 816を介して、メッシュデバイス812またはクラウド302内のデバイスに対してパケットを送信および受信するために含まれ得る。パケットは、共通の秘密を生成するために他のノードによって使用される情報を含み得る。例えば、パケットは、コンテキスト、階層レベル、ルートシードなどを含むことができる。
図45に関して説明したように、通信部15008は、プロトコル間のパケットの変換、プルーフオブプロヴェナンスの追加の実行などの他の機能を実行することができる。さらに、通信部15008は、図33を参照して説明した通行権システムの一部とすることができる。部分鍵アセンブラ15010は、他のメッシュデバイス812から受信した部分鍵をアセンブルして鍵を形成するか、またはルートシードの値を回復することができる。
部分鍵アセンブラ15010は、最終鍵を形成するために、循環バッファ内で部分鍵のそれぞれをアセンブルすることができる。暗号化部/復号部15012は、別のメッシュまたはフォグデバイス812に送信するためのデータの暗号化、または別のメッシュまたはフォグデバイス812から受信したデータの復号などの動作において最終鍵を使用することができる。
図151は、一部の実施形態による、エントロピー多重化を使用してデバイス間で共通秘密鍵を生成するようにプロセッサ902に指示するためのコードを含む、非一時的機械可読媒体15100のブロック図である。プロセッサ902は、バス904を介して非一時的機械可読媒体15100にアクセスすることができる。プロセッサ902およびバス904は、図9に関して説明したとおりであり得る。非一時的機械可読媒体15100は、図8の大容量ストレージ808について説明したデバイスを含むこともできるし、光ディスク、USBメモリ(thumb drive)、または任意の数の他のハードウェアデバイスを含むこともできる。
非一時的機械可読媒体15100は、コンテキストのためのシードツリーを生成するようにプロセッサ902に指示するためのコード15102を含み得る。上記のように、コンテキストは、例えば、時間、位置、IPアドレス、または任意の数の他のパラメータに基づいてもよい。コード15104は、コンテキストのルートシードを生成するようにプロセッサ902に指示するために含まれ得る。コード15106は、コンテキストを他のデバイスに提供するようにプロセッサ902に指示するために含まれ得る。コード15108は、ルートシードを他のデバイスに提供するようにプロセッサ902に指示するために含まれ得る。コード15110は、階層型シードツリー内の各ノードまたはデバイスについてシードを生成するようにプロセッサ902に指示するために含まれ得る。コード15112は、暗号鍵を生成するためにシードを使用するようにプロセッサ902に指示するために含まれ得る。コード15114は、他のIoTデバイスに送信されたデータを暗号化するために、または他のIoTデバイスから受信したデータを復号するために、暗号鍵を使用するようにプロセッサ902に指示するために含まれ得る。
本明細書で説明される鍵管理および生成プロセスは、IoTデバイスを含む環境においてセキュリティを管理するための複数の技法を提供する。しかしながら、場合によっては、IoTネットワーク環境では、鍵の生成、有効期間、終了、および再発行の管理が複雑になることがある。
図152は、一部の実施形態による、IoTネットワーク環境における統一鍵管理のための例示的な方法15200のラダー図である。図152の方法15200は、図153に関して説明されるIoTデバイス15300によって実施することができる。この例では、サービスプロバイダ(SP)15202を使用して、全体的なルートオブトラストを提供することができる。このサービスプロバイダ15202は、IoTネットワークにおいて、IoTデバイスのグループによって管理されるブロックチェーンであり得る。別の例では、サービスプロバイダ15202は、IoTネットワークにセキュリティサービスを提供する外部デバイスとすることができる。
IoTサーバ15204は、例えば、IoTサーバ15204からアクセス可能なセキュアなストレージ場所15206にセキュアな情報を格納して、IoTネットワークのローカルセキュリティを管理することができる。セキュアなストレージ場所15206は、例えばトラステッドプラットフォームモジュール(TPM)によって管理される、トラステッド実行環境(TEE)内にあってもよい。
IoTクライアント15208は、データおよび通信の暗号化および復号のための鍵を取得するために、サービスプロバイダ15202およびIoTサーバ15204の両方と相互作用することができる。別のエンティティ15210は、例えば、鍵が危殆化したと判定し、鍵の失効および新しい鍵の生成をトリガして、通信に参加することができる。エンティティ15210は、とりわけ、IoTネットワーク内の別のIoTデバイスであってもよいし、管理コンソールのユーザであってもよいし、IoTネットワーク内のIoTデバイスの製造業者であってもよい。
方法15200は、対称鍵および非対称鍵の両方を管理するために使用され得る。特定の通信では、対称鍵を使用してすべてのデータを保護することができる。方法15200は、IoTサーバ15204がIoTネットワークにオンボーディングされ、サービスプロバイダクレデンシャル15212を受信したときに開始することができる。認証メッセージ15214において、サービスプロバイダクレデンシャル15212を使用して、サービスプロバイダ15202にしてIoTサーバ15204を確認することができる。認証メッセージ15214は、サービスプロバイダ15202がセキュアな通信のためのクレデンシャルを提供することを要求してもよい。サービスプロバイダ15202は、トラストアンカー15218を含むトラストメッセージ15216で応答することができる。トラストアンカー15218は、公開鍵のハッシュ、または証明されたパス、またはトラステッドルート機関へのチェーンを含み得る。
IoTクライアント15208は、対称鍵メッセージ15220をサービスプロバイダ15202に送信して、対称鍵を通信用に提供することを要求することができる。対称鍵メッセージ15220は、IoTクライアント15208からの公開鍵または秘密鍵によって署名されてもよい。
対称鍵メッセージ15220がサービスプロバイダ15220によって確認された場合、サービスプロバイダ15202は、対称鍵またはチケットを含むメッセージ15222で応答することができる。メッセージ15222は、IoTクライアント15208によって提供されたのと同じ鍵を使用してサービスプロバイダ15202によって署名されてもよい。次いで、IoTクライアント15208は、メッセージ15224で対称鍵をIoTサーバ15204に提供することができる。IoTサーバ15204は、対称鍵15226をセキュアなストレージ15206に保存することができる。IoTサーバはまた、タイムスタンプをセキュアストレージ15206内のセキュア時間15229と比較することによって、セキュア鍵が期限切れになっているか否かを判定することができる。この比較の結果は、セキュア鍵ステータス15230に保存され得る。
エンティティ15210は、鍵15232が危険にさらされているという判定を下すことができる。例えば、エンティティ15210は、ネットワーク探索において、その鍵によって保護されていたデータまたはその鍵自体を見つけることができる。セキュアな鍵15226の場合、これは、サービスプロバイダ15202へのメッセージ15234によってセキュアな鍵15226を失効させ得る。メッセージ15234に応答して、サービスプロバイダ15202は、失効メッセージ15236をIoTサーバに送信することができる。IoTクライアント15208に命令する別のメッセージ15238が、IoTクライアント15208に送信されてもよい。次いで、IoTサーバ15204は、認証メッセージ15214を送信することによってサービスプロバイダ15202と再認証して、プロセスを繰り返すことができる。
IoTクライアント15208は対称鍵を使用することに限定されず、秘密鍵を使用して認証メッセージ15240をサービスプロバイダ15202に送信することができる。次いで、サービスプロバイダ15202は、IoTクライアント15208に属する公開鍵を使用して、認証メッセージ15240を復号し、IoTクライアント15208のアイデンティティを確認することができる。
認証メッセージ15240の認証がIoTクライアント15208が有効であることを示す場合、サービスプロバイダ15202は証明書を含むメッセージ15242を送信することができる。メッセージ15242は、サービスプロバイダ15202のための公開鍵で署名されてもよい。次いで、IoTクライアント1528は、証明書を含むメッセージ15244をIoTサーバ15204に送信することができる。メッセージ15244は、IoTクライアント15208のための公開鍵で署名されてもよい。公開鍵15246は、IoTサーバによってセキュアなストレージ15206に保存されてもよい。IoTサーバ15204はまた、例えば、証明書内のタイムスタンプをセキュアなストレージ15206に格納されているセキュアな時間値15250と比較することによって、証明書が期限切れになったか否かを判定することができる(15248)。秘密鍵15252のステータスもセキュアストレージ15206に保存することができる。
次いで、IoTサーバ15204は、通信のために一時対称鍵(TSK)15254を生成することができる。IoTサーバ15204は、TSK 15254を含む鍵交換メッセージ15256をIoTクライアント15208に送信することができる。次いで、IoTクライアント15208は、例えばメッセージ15258を暗号化するために、TSK 15254を使用してIoTサーバ15204と通信することができる。
エンティティ15210が、公開鍵15226が危険にさらされていることを15232を検出すると、失効メッセージ15260をサービスプロバイダ15202に送信することができる。次いで、サービスプロバイダ15202は、公開鍵15246を失効させるように命令する失効メッセージ15262をIoTサーバ15204に送信することができる。サービスプロバイダ15202はまた、IoTサーバ15204に送信された公開鍵15246に対して生成された秘密鍵を削除するように命令するメッセージ15264を、IoTクライアント15208に送信することができる。
TSK 15254は、無期限に存続することはなく、公開鍵よりも有効期限が短くなり得る。例えば、メッセージ15266は、TSK 15254を使用して暗号化された後に、IoTクライアント15208によってIoTサーバ15204に送信され得る。IoTサーバ15204によってセキュアストレージ15206内のセキュア時間値15268を使用して、TSK 15254が期限切れになったか否かを判定する(15270)ことができる。次いで、TSKステータス15272をセキュアストレージ15206に格納することができ、期限切れになると、TSK 15254を、IoTクライアント15208と交換される(15256)新しい値でリフレッシュすることができる。
さらに、エンティティ15210が、TSK 15254が危険にさらされていると判定した場合、エンティティ15210は、失効メッセージ15274をサービスプロバイダ15202に送信することができる。次いで、サービスプロバイダ15202は、TSKステータス15272を無効に変更するように命令する失効メッセージ15276をIoTサーバ15204に送信することができる。サービスプロバイダ15202はまた、TSK 15254を削除するように命令するメッセージ15278をIoTクライアント15208に送信することができる。この時点で、IoTサーバ15204は、認証メッセージ15214を送信することによってサービスプロバイダ15202に再認証を試み、プロセスを再開することができる。
対称鍵15226は、セキュアなストレージ15206に格納されたセキュアな時間値15282によって判定されるように、有効期限を有することができる。IoTサーバ15204は、使用時間をセキュア時間15250と比較することによって、セキュア鍵またはチケットが期限切れになったことを判定することができる(15284)。次いで、IoTサーバ15204は、更新された鍵SK'を発行することができる。その後、リフレッシュされた鍵SK'は、セキュア時間15250を超えるまで使用され得る。エンティティ15210はまた、鍵SK'が危険にさらされているか否かを判定するために監視し、必要に応じて失効メッセージ15234を送信することができる。
本明細書で説明されるように、鍵交換または鍵管理プロトコルは、機密性、完全性、またはその両方を含み、データを保護するために使用される一時的(temporary)な、または一時(temporal)対称鍵をもたらし得る。一時鍵は、一時鍵が最初に確立されてから危殆化されていないという仮定に基づいて、認証/鍵交換イベントによって確立された認証および信頼プロパティを推定する。
しかしながら、一時鍵は様々な有効期限を持ち得る。有効期限はコンテキストおよび状況に基づいて動的に調整され得る。例えば、スリープモードに入ったり出たりしているノードは、スリープしている間は鍵の有効期間を短くしない可能性がある。
さらに、対称および非対称の任意の鍵の鍵失効は、失効メッセージをクライアントおよびサーバの両方に送信することによって実行することができる。鍵が失効した場合、クレデンシャルまたはチケットを所有するクライアントおよびサーバにそれらを削除するように命令する鍵削除メッセージを送信することによって、クレデンシャル(証明書またはチケット)を削除できる。失効は、失効した鍵の検証を拒否するようにクライアントまたはサーバに命令するだけであるが、削除は、鍵をシステムから物理的に削除するように命令するという点で、削除と失効とは異なり得る。失効メッセージおよび削除メッセージは両方ともすぐに有効になるかもしれないが、証明書またはチケットの有効期限が切れた場合、鍵は有効期限まで、鍵の危殆化イベントの後も、使用することができる。
鍵の有効期限管理は、対称鍵キャッシュシステムにさらに適用され、鍵が一時的であるとみなされていても、一時鍵が第2または第3のメッセージのために再利用され得る。キャッシュされた鍵の一時性は、キャッシュの有効期限ポリシーによって判定される。従って、鍵キャッシュポリシーはチケット構造としても使用され、キャッシュポリシー構成メッセージは、対称鍵を含まない「チケット」構造を使用してを指定され得る。
統一鍵管理は、対称鍵および非対称鍵の両方に鍵管理メッセージおよびフローを利用して、制約のあるIoT環境に利益をもたらす実装での効率的な再利用を可能にする。
図153は、一部の実施形態による、IoTメッシュデバイス812のネットワークにおいて鍵を管理するためにIoTデバイス15300内に存在し得るコンポーネントの一例のブロック図である。同様の番号が付けられた項目は、図3および図8に関して説明したとおりである。IoTデバイス15300は、図152に関して説明されたIoTサーバ15204またはIoTクライアント15208であり得る。図8に関して説明したIoTデバイス800、および本明細書で説明される他のIoTデバイスに対して選択されたものとは異なるコンポーネントが、IoTデバイス15300に対して選択され使用されてもよいことに留意されたい。
この例では、IoTデバイス15300は、図152に関して説明されたIoTサーバ15204またはIoTクライアント15208のいずれかとして機能することができる。他の例では、例えば、IoTデバイス15300がより制約されている場合、IoTデバイス15300は、IoTクライアント15208としてのみ機能し得る。さらなる例では、IoTデバイス15300は、IoTサーバ15204としてのみ機能し得る。
IoTデバイス15300は、例えば、2009年にISO/IEC 11889としてTrusted Computing Groupによって公表された仕様に準拠する、トラステッドプラットフォームモジュール(TPM)15302を含むことができる。TMP 15302は、暗号化プロセッサ(CP)15304、不揮発性メモリ(NVM)15306、およびセキュアメモリ(SM)15308を含み得る。CP 15304は、とりわけ、乱数発生器、RSAハッシュ発生器、SHA-1ハッシュ発生器、および暗号化-復号エンジンを提供することができる。NVM 15306は、例えばとりわけRSA鍵を含む、製造時にプログラムされた鍵を含み得る。SM 15308は、ソフトウェアで得られた測定値をプラットフォーム構成レジスタに保持することができる。本明細書で使用される場合、測定値は、ストレージ808またはメモリ804に格納されたコードまたはデータセグメント上で計算されたハッシュコードである。ブートコードセグメントの測定から開始して、初期ブートから信頼チェーンを作成することによって、測定を使用してトラステッド実行環境(TEE)を確立することができる。SM 15308は、図152に関して説明したセキュアストレージ15206を提供することができる。
大容量ストレージ808は、本明細書で説明される鍵管理機能を実施するための複数のモジュールを含むことができる。大容量ストレージ808においてコードブロックとして示されているが、モジュールのうちのいずれも、例えば特定用途向け集積回路(ASIC)に組み込まれるなど、ハードワイヤード回路で完全にまたは部分的に置き換えられ得ることが理解されよう。
大容量ストレージ808は、コードまたはデータに対して測定を実行するセキュアなブート部/測定部15310を含み得る。追加の測定を実行するようにセキュアなブート部/測定部15310を設定するために、プロセッサ802またはTPM 15308によって初期ブート測定が実行されてもよい。これは、IoTデバイス15300にセキュリティを提供するためのトラステッド実行環境(TEE)を作成することができる。TEEにおける後続の測定は、コードセグメントが動作のために準備されるときにTPM 15308によって実行され得る。
認証部15312は、他のメッシュデバイス812、またはクラウド302内のデバイスとの通信を認証するために使用され得る。認証部15312は、パケット通信部15314を使用して、他のメッシュデバイス812またはクラウド302内のデバイスとの間で暗号化されたパケットを送信および受信することができる。認証部15312は、サービスプロバイダ15202によって提供された対称鍵、またはIoTデバイス15300で生成された一時対称鍵(TSK)を使用して通信を認証することができる。
鍵生成部15316は、他のデバイスと通信するための一時対称鍵(TSK)を生成するために使用され得る。認証部15312は、他のデバイスとTSKを交換することができる。鍵生成部15316はまた、鍵が期限切れになった後、例えば鍵の有効期間のセキュア時間を超過したときなどに、新しいTSKまたは新しい対称鍵(SK)を生成することができる。暗号化部/復号部15318は、TSKまたはSKを使用して通信を暗号化または復号することができる。
鍵マネージャ15320は、鍵を監視し管理するために含まれ得る。これは、鍵が期限切れになったか否かを判定すること、および鍵発行部15316を使用して再発行のための新しい鍵を生成することを含み得る。鍵マネージャ15320は、鍵が危険にさらされたことを示す、別のメッシュデバイス812またはクラウド302内のデバイスからの失効メッセージについて通信部15314を介して受信された通信を監視することができる。失効メッセージを受信すると、鍵マネージャ15320は、鍵がもはや有効ではないことを示すために鍵のステータスを変更することができる。次いで、鍵マネージャ15320は、認証部15312を介して認証を再トリガして鍵を再生成することができる。
図154は、一部の実施形態による、セキュアな通信のために鍵を管理するようにプロセッサ902に指示するためのコードを含む、非一時的機械可読媒体15400のブロック図である。プロセッサ902は、バス904を介して非一時的機械可読媒体15400にアクセスすることができる。プロセッサ902およびバス904は、図9に関して説明したとおりであり得る。非一時的機械可読媒体15400は、図8の大容量ストレージ808について説明したデバイスを含むこともできるし、光ディスク、USBメモリ(thumb drive)、または任意の数の他のハードウェアデバイスを含むこともできる。
非一時的機械可読媒体15400は、サービスプロバイダに対して認証するようにプロセッサ902に指示するためのコード15402を含み得る。コード15404は、セキュアな通信またはストレージのための鍵を取得するようにプロセッサ902に指示するために含まれ得る。コード15404は、チケットなどの対称鍵、または証明書などの非対称鍵を、サービスプロバイダから要求するようにプロセッサ902に指示することができる。
コード15406は、通信のための対称鍵を生成するようにプロセッサ902に指示するために含まれ得る。対称鍵は、公開鍵と秘密鍵とのペアの交換による認証後に別のデバイスと交換されるTSKとすることができる。コード15406によって生成される対称鍵はまた、期限切れになった鍵をリフレッシュするために生成された新しい鍵でもあり得る。
コード15408は、鍵が事前設定された鍵寿命に達したか否かを判定するようにプロセッサ902に指示するために含まれ得る。コード15410は、期限が切れた鍵をリフレッシュするようにプロセッサ902に指示するために含まれ得る。コード15412は、他のデバイスからの通信を暗号化および復号するようにプロセッサ902に指示するために含まれ得る。コード15414は、例えば、失効メッセージが受信された場合に、鍵を失効させ、サービスプロバイダへの認証を繰り返すようにプロセッサ902に指示するために含まれ得る。
本明細書で説明されている鍵管理技法は、任意の数のコンテキストで使用することができる。例えば、オブジェクトがアクティブになって接続する必要がある場合、オブジェクトを登録する方法や他のサービスやエージェントを見つける方法について、ネットワークで実行されている他のサービスやエージェントに関するレジストラからの情報を使用できる。しかしながら、パブリックレジストラは、分散型サービス妨害(DDoS)攻撃を受けやすい。実行可能であれば、非集中型プロトコルに基づいてレジストラを実装することは有用であり得る。非集中型プロトコルでは、ブロックチェーンまたは台帳は、それらのブロックチェーンアドレスを使用してデバイスまたはエージェントのアイデンティティを評価するための公開鍵インフラストラクチャ(PKI)の代わりとして動作し得る。ブロックチェーンは、セキュアで、記憶され(memorable)、そして非集中化された名前空間として使用することができる。名前空間内の名前は、なんらかの非集中化された方法で管理され得る限られたリソースである。さらに、動的ホスト構成プロトコル(DHCP)におけるインターネットプロトコル(IP)などの、通常リースによって規制されている下位レベルアドレスは、マイクロペイメントまたは他のクレジットまたは通貨によって課金および規制され得る。
図155は、一部の実施形態による、デバイスのブートストラップおよび発見のためのプロセス15500の概略図である。本明細書で使用されているように、ブートストラップは、デバイスの最初のスタートアップであり、その間にデバイスは、機能を実行するためにオペレーティングシステムおよび他のコードをストレージデバイスからロードすることができる。プロセス15500は、IoTネットワーク環境で行われ得る。ブロック15502は、例えば、デバイスがブートし、例えばトラステッドプラットフォームモジュール(TPM)または他の技術によって確立するなどして、セキュアなエンクレーブまたはトラステッド実行環境(TEE)でコードを実行することを表す。
ブロック15504において、デバイスがブロックチェーンクライアントとして動作するための鍵が生成される。これは、例えば、ブロック14206に示し、図142に関して説明したプロセスによって実行することができる。しかしながら、とりわけ図137~図141、図142~図146、または図147~図151に関して説明した鍵生成プロセスなど、任意の数の鍵生成プロセスを使用することができる。
ブロック15506において、デバイスは、ブロックチェーン上で特別なコミッショニングトランザクションを生成する。コミッショニングトランザクションは、ドメイン名、またはなんらかの他の固有の属性を購入することを含み、これは、デバイスのアイデンティティを構成する属性の全体的なパッケージの一部になり得る。ブロック15508において、デバイスは、ドメイン名またはユニバーサル固有識別子(UUID)などの購入された属性を介して、あるいはオーナーを介して提供されたアイデンティティを割り当てられる。
図156は、一部の実施形態による、デバイスのブートストラップおよび発見のための例示的な方法15600のプロセスフロー図である。図156の方法15600は、図159に関して説明されるIoTデバイス15900によって実施することができる。方法15600は、デバイスにアイデンティティを取得させる、修正されたブートプロセスを記述し得る。アイデンティティは、サービスの発見およびサービスに対する支払いに使用され得る。
ブロック15602は、例えばデバイスがブートプロセスを開始するときを表す。これは、デバイスに最初に電源が投入された後、または再ブート時に行われ得る。ブロック15604において、BIOSは初期化し、通常のPOSTチェックを実行する。ブートプロセスは、トラステッドSWのみが実行されることを確実にするためのセキュアなブートプロセスであり得る。これは通常、デプロイ前にデバイスに鍵を格納するためにファームウェアサプライヤからの指示を使用して製造業者によって有効化されたハードウェアによって実行される。
ブロック15606において、セキュアブートプロセスは、セキュアエンクレーブまたはトラステッド実行環境(TEE)にブートすることができる。セキュアエンクレーブは、アイデンティティクライアントを実行することができ、これは、例えば、分散型台帳を構築し、デプロイし、そして実行するためのオープンソースのモジュール式プラットフォームとしてIntel(登録商標)によってリリースされたSawtooth Lake Clientであってもよい。アイデンティティクライアントが初期化されると、デバイスは通常どおりブートを継続する。ブロック15608において、オペレーティングシステム(OS)は適切なランレベルでブートする。一部の例では、オペレーティングシステムは存在せず、代わりにデバイスはアドバンストBIOSによって動作される。
ブロック15610において、ブートプロセスが正しく実行されたか否かに関する判定が行われる。そうでない場合、ブロック15612において、デバイスをリセットすべきか否かに関する判定が行われる。リセットは、デバイスの工場出荷時のリセットであってもよく、それはデバイスからのすべてのデータを消去し、デバイスをリセットしてオンボードの読み取り専用ROMイメージなどからブートすることができる。実行された場合、プロセスフローはブロック15604に戻り、ブートプロセスを繰り返す。デバイスをリセットすべきではないと判定された場合、ブロック15614において、警告メッセージが送信される。次いで、プロセスはブロック15616において終了する。
ブロック15610において、ブートプロセス中にすべてが正しく機能したと判定された場合、プロセスフローはブロック15618に進み、アイデンティティを取得する。複数のアイデンティティをデバイスに割り当てることができ、例えば、デバイスにはDNS名、IPアドレス、MACアドレス、UUID、または他のアイデンティティを設定することができる。さらに、とりわけ図5から図9に関して説明したように、ブロックチェーン技法を使用してデバイス識別情報を割り当てることができる。この例では、スマートコントラクトまたは同様の構築物によって管理されるプロセスに参加するために、グローバルに固有のアイデンティティを取得することができる。本明細書で使用されるように、スマートコントラクトは、2つのデバイス間で自動的に交渉されるコントラクトであり得、第2のデバイスからの支払いと引き換えに、第1のデバイスが第2のデバイスに対してサービスを実行する、またはデータを提供する。
ブロック15620において、アイデンティティを取得または発見できる潜在的なサービスがエニュメレーションされる。デバイスは、スマートコントラクトの位置を指定する新しいDHCPオプションまたはコンセンサスに基づくネットワークなどの方法を含むがこれらに限定されない動的または静的プロセスを使用して、この機能を実行することができる。さらに、潜在的なサービスは、一部の暗号通貨ネットワーククライアントの場合のように、デバイスに事前にロードされ得る。潜在的なサービスは、デバイスが発見するか、または使用するようにハードコードされている、インターネットベースのサービスレジストリでアドバタイズされる場合もある。潜在的なサービスは、とりわけ、ネームコインなどの非集中型ネームサービスでアドバタイズされてもよい。従って、クライアントは、ネットワークアイデンティティを使用し、スマートコントラクトプロセスによって提供される任意のサービスとの相互作用を開始することができる1つまたは複数のそのようなネットワークに気付き得る。様々なサービスまたはネットワークがアイデンティティメカニズムを共有することを選択する場合もあるし、アイデンティティに対して完全に互換性のない手法を持っている場合もある。
デバイスは、サービスによって指定された種類のアイデンティティを生成する能力に基づいて、または事前にプログラムされた目的に基づいて、サブスクライブを試みるサービスを選択することができる。サービスは、ブート中にセキュアエンクレーブ内で静的に割り当てられてもよいし、ポリシーシステムによって動的に設定されてもよい。しかしながら、サービスは、信頼される前に、セキュアエンクレーブ内で実行されているプロセスによって最初に検証されてもよい。
ブロック15622において、デバイスは、IDを取得する方法が選択されたか否かを判定する。述べたように、IDが使用され得る複数のネットワークが利用可能である場合、複数の方法が選択され得る。ブロック15622で方法が選択されていない場合、ブロック15614において警告メッセージを送信することができ、方法15600はブロック15616において終了する。デバイスは、DNS名、NetBIOS名、IPアドレス、UUIDなどの様々なアイデンティティを有することができるので、警告は多くの形態をとることができる。例えば、警告は、管理者への電子メール、SMTPトラップ、ローカルまたはリモートのログファイル内のエントリ、SMSメッセージ、デバイスの外部にある点滅するLEDシーケンス、またはその他の警告である。
方法がブロック15622において選択されている場合、ブロック15624において、デバイスは選択されたサービスについてのアイデンティティを生成し得る。デバイスオーナーは、例えば、セキュアエンクレーブ内の構成を通じて、ハードウェア支援のアイデンティティ方法を使用するようにデバイスに要求するためのオプションを設定することができる。他の例では、オーナーは、ハードウェア支援アイデンティティ方法の選択を任意または好ましいものにすることができ、それによってデバイスは、サービスによって要求されるように鍵または他の固有の識別子を生成するためによりセキュア性の低い方法を使用できる。これらの設定、または他の予期しないエラーや例外により、デバイスは、特定のサービスのアイデンティティを生成できない場合がある。
ブロック15626において、デバイスのアイデンティティが正常に生成されたか否かに関する判定が行われる。アイデンティティが正常に生成されなかった場合、または複数のアイデンティティが生成される場合、方法15600はブロック15622に戻って、識別情報を生成するために別の方法を選択できるか否かを確認する。デバイスは、そのポリシー設定を満たすまで、可能な方法またはサービスのリストを調べ続けることができる。例えば、ポリシーは、1つのアイデンティティが正常に生成された後にデバイスが停止するように規定することがある。他の例では、デバイスは、成功するまで、またはすべてのオプションが検討されるまで、アイデンティティ生成の多くのメカニズムを試して、利用可能なすべてのサービスを探索することができる。アイデンティティ生成プロセスはまた、デバイスがトランザクションを実行するために使用することができるリソースを獲得することができ、例えば、暗号通貨ネットワークの場合、アイデンティティが割り当てられるときにデバイスに初期残高が割り当てられ得る。
ブロック15628において、コミッショニングトランザクションを生成することができる。コミッショニングトランザクションは、ハードウェア支援プロセスとすることができ、それにより、デバイスに対してセキュアで信頼できる残高が生成される。これには、ネットワーク上の新しいコインの生成が含まれ得る。
コミッショニングトランザクションは、特定のコンセンサスネットワークに固有のものとすることができる。それはネットワーク上のデバイスのアイデンティティを確認することができ、そしてコンセンサスネットワークによって要求されるパブリックアイデンティティ情報を含むことができる。例えば、デバイスの秘密鍵によって署名されたトランザクションは、トランザクション内に公開鍵およびウォレットIDを含むことができ、それによって、トランザクションのソースを容易に検証することができる。コミッショニングトランザクションは、アイデンティティ生成後、いつでも行われ得る。さらに、それはデマンドドリブン型であってもよく、例えば、それはデバイスがトランザクションに参加することを初めて望んだときにのみ起こるのであってもよい。最初のトランザクションの後、デバイスのアイデンティティはネットワーク内でパブリックに知られており、そこからのメッセージはコンセンサスネットワークによって提供されるメカニズムを使用して検証することができる。
ブロック15630において、コミッショニングトランザクションが完了したか否かについての判定が行われる。コミッショニングトランザクションが失敗した場合、例えば、ネットワークがトランザクションを無効として拒否した場合、ブロック15632において、デバイスは警報を生成する。失敗に応じて、ブロック15634において、デバイスはトランザクションの一部のパラメータを変更し、トランザクションを再試行することができる。デバイスは、そのサービスの新しいアイデンティティの生成を試みたり、アイデンティティを生成する他のサービスの選択を試みたりすることができる。
再試行され得る失敗の例は、ドメイン名の購入である。ドメイン名は、ドメイン名がチェックされたときに利用可能になり、トランザクションが生成される。しかしながら、処理される前に、別のエンティティがドメイン名を取得する。この例では、デバイスは、ドメイン名パラメータを更新し、トランザクションを再試行することができる。一部のトランザクションは、失敗するが、再試行できない場合がある。例えば、二重支払いは再び行うことはできない場合もある。
トランザクションがブロック15630で正常に完了したと判定された場合、ブロック15636において、デバイスはアイデンティティを有することを確認され得る。ブロック15614において、プロセスが完全に完了したことを示すために警告を生成することができる。次いで、プロセスはブロック15616において終了する。
デバイスが将来のある時点でデコミッションされた場合、ブロックチェーンプロトコルは、採掘または割り当てられたコインなどの残高の処分を判定することができる。コインは破壊されるか、さもなければ循環から取り除かれ得る。コインまたは残高は、デバイスオーナーによって指定された他のデバイスに再配信されてもよい。一部の例では、残高またはコインは、取引所で販売され、デバイスオーナーへの返済のために通貨に変換され得る。
プロセスは、図155および図156に示すブロックに限定されない。ブロックチェーンスマートコントラクトの概念を使用した、より機能豊富なメカニズムを実装することができる。
図157は、一部の実施形態による、スマートコントラクト機能を使用するデバイスのブートストラップ、発見、およびライフサイクルのためのプロセス15700の概略図である。ブロック15702は、例えばデバイスがブートするときを表す。これは、デバイスの電源を入れた後に行われても、デバイスが再ブートされた後に行われてもよい。図155のブロック15502に関して説明したように、デバイスは、TEEなどのセキュアなエンクレーブ内でコードをブートし実行する。
ブロック15704において、デバイスは、ブロックチェーンクライアントとして使用される鍵を生成することができる。これは、例えば、図142のブロック14206に関して説明したように実行することができる。
ブロック15706において、デバイスは、例えばコミッショニングトランザクションを作成することによって、ブロックチェーン上のスマートコントラクト15708と相互作用することができる。新しいデバイスが最初にスマートコントラクト15708と相互作用するときに、コントラクト参加機能15710が実行されてもよい。スマートコントラクト15708は、デバイスアテステーション機能をサポートし、スマートコントラクト15708内で特定のデバイスを受け入れるか否かを決定することができる。コミッショニングトランザクションの内容は、受け入れを判定するために使用されてもよい。コントラクト参加機能15710は、スマートコントラクト15708に参加することが許可される前にデバイスにポリシーを施行することができる。例えば、コントラクト参加機能15710は、参加前に、デバイスが、指定された最低限の規格を使用してそのハードディスクまたはストレージを暗号化することを要求してもよい。コントラクト参加機能15710は、スマートコントラクト15708に受け入れる前にそれを準備するために、他の機能またはデバイスとの追加の相互作用を要求することができる。
同様に、スマートコントラクト15708を去ると同時に、条件または機能がデバイスに課されてもよい。これらはコントラクト脱退機能15712の一部である場合もある。例えば、コントラクト脱退機能15712は、工場出荷時設定へのリセットの実行など、デバイスがそのメモリを消去することを要求してもよい。コントラクト脱退機能15712の他の要件は、現在のデバイス位置と共に無人機またはロボットを送信して、サービス組織などの保守サービスプロバイダへの販売終了(end-of-life)メッセージを送信することを含むことができ、それによって、デバイスは、回収され、その後、自身をシャットダウンすることができる。コントラクト脱退機能15712は、コントラクトオーナーによって指定された任意の数の条件を含むことができる。
デバイスがスマートコントラクト15708に参加することを許可されている場合、デバイスは、例えばブロックチェーン内の作成されたデバイスのリスト15714に追加される。一般に、制御機能のみがブロックチェーンに格納され得る。変数は、いくつかの異なるセキュアな格納メカニズムのいずれかにチェーン外に格納され得る。これらのメカニズムは、ブロックチェーン内に参照を有し得る。これは、重要なストレージ要件を有し得る変数に役立つ。
ブロック15714において、デバイス属性リスト15716は、作成されたデバイスのリストと関連付けられ得る。さらに、デバイスは属性を自己記述し、その属性を、ブロックチェーン内またはセキュアなストレージメカニズムのチェーン外のいずれかに格納することができる。属性は、デバイスの種類、位置、デバイス能力および機能などの単純なデバイスのコンテキストプロパティを含み得る。属性はまた、デバイスが提供しているアドバタイズされたサービスのリストを含み得る。これはサービス発見メカニズムとして実行され得る。
スマートコントラクト15708は、コミッショニングプロセス中に、またはその後いつでもトークン15718をデバイスに発行することができる。トークンは、複数の抽象的な意味を持つことができ、様々な目的で発行され得る。例えば、デバイスがスマートコントラクト15708内で設定された基準を満たしている場合、例えば特定のレベルの暗号化機能を備えている場合は、特殊なタイプの信頼トークンを発行できる。サービスにアクセスするとき、デバイスから来るデータのためのデータシンクがそれらの暗号化機能を持つことを要求するために、トークンはサービスに提示され得る。さらに、トークンを使用して、デバイスが他のサービスにアクセスしたり、アイデンティティを検証したりすることができる。
スマートコントラクト15708は、デバイスがコントラクトから抜ける準備ができたときにトークン15720を失効させることができる。トークンが失効されると、そのトークンの下のアクセスは無効になる。失効トークン機能15720は、契約を脱退する条件の一部として、コントラクト脱退機能15712によってトリガされてもよい。
デバイスがネットワーク上でコミッションされると、ブロック15722において、デバイスは、スマートコントラクト15708の下で動作を開始することができる。新しい機能がデバイス上で利用可能になった場合、またはその属性が変更された場合、デバイスはその動作中いつでもスマートコントラクト15708と相互作用して新しいトークンを要求することができる。
スマートコントラクト15708に対するデバイスの関係は、多対1、多対多、または1対多であり得る。トークンおよび属性は、コントラクトを結ぶことによってデバイスの有効期間中いつでも変更できる。スマートコントラクト15708は、例えば、他のデバイスにミラーされている共有ブロックチェーンを含むデバイスの一部であり得る。この例では、スマートコントラクト15708の機能は、ブロックチェーンを維持するために使用されるブロックチェーンロジックの一部であり得る。他の例では、スマートコントラクト15708は、別のデバイス上、IoTネットワーク内、またはクラウド内に配置され得る。
ブロック15724において、例えば、デコミッショントランザクションをスマートコントラクト15708のブロックチェーンにポストすることにより、デバイスをデコミッションすることができる。発行されたトークンはすべて無効にされ(15720)、デバイスは、作成されたデバイスのリストから除去される(15714)。さらに、コントラクト脱退機能15712が実施されてもよい。
図158は、一部の実施形態による、スマートコントラクトを使用してデバイスのブートストラップ、発見、およびライフサイクルのための例示的な方法15800のプロセスフロー図である。図158の方法15800は、図159に関して説明されるIoTデバイス15900によって実施することができる。ブロック15802は、例えばデバイスのブートを表す。これは、図156のブロック15602から15608に関して説明されたように実行されてもよい。
ブロック15804において、デバイスがブロックチェーンまたはスマートコントラクトに参加するための鍵を生成することができる。鍵生成段階は、例えば図142のブロック14206に関して説明したように、本明細書で説明したように実行することができる。
ブロック15806において、コミッショニングトランザクションを作成し実施することができる。コミッショニングトランザクションは、図156のブロック15628に関して説明したとおりであり得る。ブロック15808において、コミッショニングトランザクションが正常であったか否かに関する判定が行われる。正常ではなかった場合、ブロック15802に記載されているようにデバイスを再ブートすることができる。
ブロック15808で判定されるように、コミッショニングトランザクションが成功した場合、ブロック15810において、コントラクトがエニュメレーションされ得る。デバイスは様々な方法で相互作用することができるので、コントラクトをエニュメレーションすることは様々なオプションをエニュメレーションすることができる。エニュメレーションは、任意の静的または動的な方法で行うことができ、例えば、それはインターネットでホストされるコントラクトのレジストリ上で実行することができる。さらに、これは、セクション3.4.3で説明されているルックアップの方法を使用して実行することもできる。
ブロック15812において、デバイスは、スマートコントラクトと相互作用することによってスマートコントラクトに参加し、このことは、スマートコントラクトオーナーのウォレットアドレスに料金を送信することを含み得る。交渉には料金関連を含むことができ、例えば、コントラクトは、例えばトラステッドデータの提供や属性のアテステーションなどの一部の条項および条件に同意すると、デバイスの支払い金額が少なくなり得るオプションを提示することができる。本明細書に詳述されているものを含む他の交渉メカニズムを採用することができる。
ブロック15814において、交渉が成功したか否かに関する判定が行われ、成功しなかった場合、交渉はブロック15812において続行する。ブロック15814で交渉が成功した場合、ブロック15816において、デバイスは、例えばブロックチェーントランザクションをコミットすることによって、作成されたデバイスのリストに追加される。これは、図157のブロック15708に関して説明された、作成されたデバイス15714のリストに関して説明されたとおりであり得る。
ブロック15818において、デバイスの属性がパブリッシュされる。各属性について、トラステッドプラットフォームモジュール(TPM)によってサポートされるトラステッド実行環境(TEE)などのハードウェア環境、またはデバイスが実際にその属性を持っていることをアテステーションもしくは検証するために使用され得る他のトラステッドメカニズムがあるか否かを識別することが可能であり得る。
ブロック15820において、デバイスは、スマートコントラクトの下で機能するためのトークンを要求し得る。デバイスが完全に動作可能になると、サービスまたはリソースにアクセスまたは提供しようとするときに、トークンがデバイスによってサービスのオーナーに提示され得る。トークン発行の基準は、属性のアテステーションなどの機能を考慮に入れることができる。ブロック15822において、特定の属性がアテステーションされた場合、ブロック15824において、より高い値のトークンをデバイスに割り当てることができる。そうでない場合、例えばブロック15826において、より低い値のトークンが割り当てられ得る。複数のトークンの種類とトークンボリュームをデバイスに割り当てることができる。しかしながら、スマートコントラクトのオーナーがスマートコントラクトを設計している場合、これはスマートコントラクトのオーナーの裁量による。一部のトークンは、デバイス動作中にプロセス、サービス、またはシステムオーナーに提示されると消費可能になり得、トークンがデバイスのウォレットからオーナーのウォレットに転送されるペイパーユースモデルで消費される。他のトークンは永続的であり得、例えば、デバイスが特定のスマートコントラクト、デバイスグループのメンバであることを検証するため、または特定の属性、能力、または機能を所有するデバイスをアテステーションするためだけに提示され得る。
ブロック15828において、デバイスはコミッショニングされ、ブロック15830において動作が仮定される。これは、図157のブロック15722に関して説明したとおりであり得る。
ブロック15832において、デバイスはデコミッションされる。デバイスに未使用のトークンが含まれていた場合、スマートコントラクトの当事者間で通貨の返金が行われてもよいし行われなくてもよい。次いで、プロセスはブロック15834において終了する。
図159は、一部の実施形態による、ブートストラップ、発見、および有効期限管理のためにIoTデバイス15900に存在し得るコンポーネントの一例のブロック図である。同様の番号が付けられた項目は、図3および図8に関して説明したとおりである。図8に関して説明したIoTデバイス800、および本明細書で説明される他のIoTデバイスに対して選択されたものとは異なるコンポーネントが、IoTデバイス15900に対して選択され使用されてもよいことに留意されたい。
IoTデバイス15900は、例えば、2009年にISO/IEC 11889としてTrusted Computing Groupによって公表された仕様に準拠する、トラステッドプラットフォームモジュール(TPM)15902を含むことができる。TMP 15902は、暗号化プロセッサ(CP)15904、不揮発性メモリ(NVM)15906、およびセキュアメモリ(SM)15908を含み得る。CP 15904は、とりわけ、乱数発生器、RSAハッシュ発生器、SHA-1ハッシュ発生器、および暗号化-復号エンジンを提供することができる。NVM 15906は、例えばとりわけRSA鍵を含む、製造時にプログラムされた鍵を含み得る。SM 15908は、ソフトウェアで得られた測定値をプラットフォーム構成レジスタに保持することができる。本明細書で使用される場合、測定値は、ストレージ808またはメモリ804に格納されたコードまたはデータセグメント上で計算されたハッシュコードであり得る。ブートコードセグメントの測定から開始して、初期ブートから信頼チェーンを作成することによって、測定を使用してトラステッド実行環境(TEE)を確立することができる。SM 15908は、セキュアなストレージを提供することができる。TPM 15902を使用して、プログラムを実行するためのTEEまたはセキュアエンクレーブを確立することができる。
大容量ストレージ808は、本明細書で説明される鍵管理機能を実施するための複数のモジュールを含むことができる。大容量ストレージ808においてコードブロックとして示されているが、モジュールのうちのいずれも、例えば特定用途向け集積回路(ASIC)に組み込まれるなど、ハードワイヤード回路で完全にまたは部分的に置き換えられ得ることが理解されよう。
大容量ストレージ808は、コードまたはデータに対して測定を実行するセキュアなブート部/測定部15910を含み得る。追加の測定を実行するようにセキュアなブート部/測定部15910を設定するために、プロセッサ802またはCP 15904によって初期ブート測定が実行されてもよい。
鍵生成部15912は、他のデバイスと通信するための鍵を生成するために使用され得る。これは、例えば、ブロック14206に示し、図142に関して説明したプロセスによって実行することができる。しかしながら、とりわけ図137~図141、図142~図146、または図147~図151に関して説明した鍵生成プロセスなど、任意の数の鍵生成プロセスを使用することができる。
サービスエニュメレーション部15914は、IoTデバイス15900に利用可能なサービスまたはIoTデバイス15900によって提供され得るサービスをエニュメレーションするために含まれ得る。スマートコントラクト環境における動作のために、コントラクトエニュメレーション部15916は、IoTデバイス15900が参加できるコントラクトを発見することができる。コントラクトエニュメレーション部15916は、とりわけ、Open Connectivity Foundation(登録商標)、Allseen Alliance、またはOpen Fog Consortiumによって提供される仕様の一部として提供される機能など、任意の数の発見技術を使用してコントラクトを発見することができる。
スマートコントラクト機能15918は、例えば、図157のブロック15708に関して説明したように、スマートコントラクトのためのホストとしてのIoTデバイス15900の使用をサポートするために含まれ得る。
ブロックチェーンロジック15920は、サービス、属性、デバイスのアイデンティティ、コントラクト、コイン残高などを保持するブロックチェーン15922を維持するために含まれ得る。ブロックチェーンロジック15920は、ブロックチェーントランザクションを他のIoTデバイスに伝播させるために使用され得る。
図160は、一部の実施形態による、セキュアな通信のために鍵を管理するようにプロセッサ902に指示するためのコードを含む、非一時的機械可読媒体16000のブロック図である。プロセッサ902は、バス904を介して非一時的機械可読媒体16000にアクセスすることができる。プロセッサ902およびバス904は、図9に関して説明したとおりであり得る。非一時的機械可読媒体16000は、図8の大容量ストレージ808について説明したデバイスを含むこともできるし、光ディスク、USBメモリ(thumb drive)、または任意の数の他のハードウェアデバイスを含むこともできる。
非一時的機械可読媒体16000は、セキュアなエンクレーブでブートするようにプロセッサ902に指示するためのコード16002を含み得る。コード16004は、アイデンティティを取得するようにプロセッサ902に指示するために含まれ得る。コード16006は、通信のための鍵を生成するようにプロセッサ902に指示するために含まれ得る。
コード16008は、利用可能なサービスまたはスマートコントラクトをエニュメレーションするようにプロセッサ902に指示するために含まれ得る。コード16010は、スマートコントラクトに参加するようにプロセッサ902に指示するために含まれ得る。コード16012は、IoTデバイスから利用可能な属性またはサービスをパブリッシュするようにプロセッサ902に指示するために含まれ得る。コード16014は、スマートコントラクトの下で動作するようにトークンを要求するようにプロセッサ902に指示するために含まれ得る。
ネットワークに参加するために、データまたはリソースを必要とするデバイスまたはエージェントは、ネットワークまたは他の相互接続ネットワークを探索してデータまたはリソースを取得することができる。本明細書で使用されるように、データは、交差点管制装置のための距離、交通流などの、本デバイスの機能を完成するために必要とされる任意のデータであり得る。リソースには、上流のシステムで実行される予測モデル、またはローカル機能の実行に使用されるコードなど、タスクを完了するために使用される可能性のある任意の機能が含まれる。しかしながら、ネットワークをクエリであふれさせることは、ネットワーク通信を過負荷にする可能性があり、エネルギー制約のあるデバイスにとって問題を引き起こす可能性がある。さらに、集中型ネットワークは、分散型サービス妨害(DDoS)攻撃に対して脆弱な場合がある。台帳またはブロックチェーン認定クレジットを使用ことは、ネットワークの負荷を軽減し、オブジェクトによるリソースの管理を改善し、DDoS攻撃に対するネットワークの脆弱性を減らすのに役立ち得る。
追跡のためにリソースをよりよく編成するために、リソースは、Kademliaなどの分散ハッシュテーブル(DHT)ベースのネットワークに分散させることができる。n個のノードから成るKademliaネットワークでは、ネットワーク内の任意のノードを見つけるのに最大でO(log(n))ホップかかる。加えて、そのようなネットワークは、kバケットの概念を使用し、これは事実上、ネットワーク内のノードがそれら自身の近隣機をよく知っており、従ってそれらのローカルkバケットが多数のノードを有することを意味する。しかしながら、場合によっては、ノードからノードが離れているほど、存在するノードが少なくなり、k値が小さいkバケットのノード数が少なくなることを示す。
上述のように、現在のブロックチェーン技法は、ブロックチェーン内の特定のブロックにインデックスを付けるための方法としてマークルハッシュツリーを構築することができる。ブロックハッシュがわかっている場合、そのブロックはブロックのリポジトリに効率的に配置され得る。これはDHTの一種とみなすことができる。DHTは、ブロックチェーンに含まれる特定のデータを識別するためにも使用できる。この手法では、データ値はDHTにハッシュされてもよく、DHTデータベース内の位置が、データを見つけることができるブロックチェーンブロックハッシュを明らかにする。
データの信頼性を検証したいシステムは、2段階のルックアッププロセスを実行することができ、このプロセスでは、関心のあるデータがDHT位置にハッシュされる。その場所はブロックハッシュ値を明らかにする。ブロックハッシュ値は、マークルツリーにハッシュされ、ブロックチェーン内の実際のブロックを明らかにする。ブロックハッシュの計算および次の前のブロックのチェックによって、チェーン内のブロックの完全性が検証される。このようにして、DHTで認識可能なデータはすべて、インフラストラクチャによる信頼メカニズムに従って完全性が確認される。
本明細書で説明されるブルームフィルタ機構は、DHTを使用して実施することができる。DHT値がブルームフィルタを形成するために使用されるとき、それはサブスクライバのコミュニティによるサブスクリプションのために利用可能なそのデータ項目のためのトピックがあることを示し得る。コミュニティはブルームフィルタ値に興味がある場合もあり、データ値を含むトランザクションがブロックチェーンで見つかるたびに通知されてもよい。
データ分析は、一見無相関のデータ間の相関を見つけることを目的としている。従って、分析エンジンは、以前は予期していなかった相関関係を仮定し、これらのトピックをサブスクライブすることができる。仮説的に相関させた値のDHTが統計的に関心対象の時間枠内に発生する場合、データアナリストは自分の仮説を検定できる。ブロックチェーンにマッピングされた大量のトランザクションを考えると、これはデータアナリストの仮説検定の効率的な通知を可能にし得る。
ネットワーク構造へのこの手法は、遠く離れたノードへのクエリが、参加しているすべてのノードに完全なネットワークマップを複製する必要なしに、リモートの近隣についての詳細な情報を返し得ることを意味する。これにより、ネットワークをより動的に保つことができる。ローカルネットワーク内のリソースを発見するためのブロードキャストは比較的安価であり、ネットワーク全体の連合的な性質は、ネットワーク全体にわたるリソース発見ブロードキャストトラフィックのレベルが低減され得ることを意味する。
しかしながら、従来のコンセンサスネットワークは、この概念を組み入れておらず、それは、相補的なチェーン外データ/ストレージプレーンを有する制御プレーンとしてブロックチェーンをどのように使用するかという方法が開発されていないからである。従って、本明細書で開示される態様は、これを可能にするために使用され得、従ってより多くのデータが時間の経過と共にチェーン上に格納されるにつれて生じるスケーラビリティの問題に対処するために使用され得る方法を提供する。
本明細書で説明されるように、コンセンサスノードがkバケット方式で分散されるように設計されたブロックチェーンは、リソースを見つけるためのブロックチェーンの効率を改善することができる。kバケットは、ローカルなセグメント化されたネットワークを半自律的に導入することができ、ローカルに利用可能なサービスおよびコントラクトをそれらをネットワーク全体に分散させることなく格納することができる。このストレージは、チェーン外でもチェーン内でも行うことができる。
本明細書で説明されるように、デバイスは、ネットワーク内のサービス、スマートコントラクト、および他の情報を見つけたいと思う場合がある。このような情報をチェーンに格納すると、ブロックチェーンはデータプレーンではなく制御プレーンとみなされるため、スケーラビリティおよび性能の問題が発生する可能性がある。台帳認定クレジットのこの概念を使用して、サービスまたはスマートコントラクトの取得にかかる各ホップに動的コストを関連付けることができる。グローバル探索では、利用可能な最良の一致が得られる可能性があるが、実行にかかる時間とクレジットの観点から見れば、より多くのコストがかかる可能性がある。従って、探索エンティティは、ホップのコストを支払うか、現在の探索結果に満足するかの間でトレードオフを決定する必要があり、これは両立しない。探索対象のリソースは発見可能な形式でなければならず、ブルームフィルタのアイデアをネットワーク全体の探索効率をさらに向上させるための技法として適用できる。
図161は、ブルームフィルタホップを使用してリソースを発見するプロセス16100の概略図である。プロセス16100では、一部の実施形態によれば、クライアントノードすなわちcノード16102が、リソースの探索16104を、最寄りのマイニングノードすなわちmノード16106にブロードキャストする。mノード16106は、そのローカルkバケット16110内のノード内に保持されているサービス、スマートコントラクト、およびファイルの内容で埋められた、または基礎となるDHTプロトコルの動作によって指示されるように、それ自体のブルームフィルタ16108を維持する。結果が否定的であれば、探索は失敗しており、そしてcノード16102は、複数の基準を用いて、探索を終了するか続行するかを決定することができる。結果が続行することである場合、ネットワークの内容のより徹底的な探索が実行され得る。
本明細書で使用されるように、ブルームフィルタは、要素がセットのメンバであるか否かをテストするために使用され得る、複数のビットを含むストレージ構造などの確率的データ構造である。クエリは、場合によりセット内にある、またはセット内にはない、2つの異なる結果のうちの1つを返すことができる。ブルームフィルタの各要素または結果は、フィルタ内のビットの一部のセットを埋めるために使用されるハッシュ関数である。探索に使用されるハッシュがブルームフィルタ内のすべてのビットに一致する場合、所望の結果は関連するKバケットに含まれ得る。対照的に、いずれかのビットが一致しない場合、望ましい結果はそのKバケットにはない。潜在的に肯定的な結果が返される場合、そのK個のバケットに関連付けられたノードのDHT内でハッシュコードのさらなる探索を実行して、所望の結果が存在するか否かを判定することができる。
続行するために、mノード16106は、別のノード16112に探索16104をブロードキャストする。ノード16112は、そのローカルKバケット16116内のノードの内容で埋められたブルームフィルタ16114を含むことができる。その探索が成功しなかった場合、cノード16102は、探索を続行するか否かの選択権を有する。cノード16102が探索16104を続行することを選択した場合、それは別のノード16118にブロードキャストされ得る。このノード16118はまた、そのKバケット16122内のノードの内容をリストしたブルームフィルタ16120も含む。この場合、探索16104は、3ホップでターゲットサービスを見つけることに成功する。探索を続行するための例示的な基準は、一致を見つけることの重要性と、さらなる探索のネットワークに対する追加コストとの間のバランスを含む。
図162は、一部の実施形態による、DHTを使用したリソース発見のための例示的な方法16200のプロセスフロー図である。図162の方法16200は、図163に関して説明されるIoTデバイス16300によって実施することができる。本明細書で説明されているように、非集中型ブロックチェーンは、そのデータのほとんどを関連するDHTに格納することができ、従ってブロックチェーンデータベース(DB)のサイズを小さくすることができる。スマートコントラクトやファイルなどのリソースは、DHTに配置されている場合がある。リソースの提供は、ブロックチェーン記録とそれに関連付けられたハッシュの存在によってバックアップされ得る。
結果が要件を満たすことができる限り、最適ではない結果を含む可能性がある探索結果をクライアントが受け入れることを促すために、料金支払いをルックアップと関連付けることができる。料金支払いは、デバイスとネットワークと間のさらなるホップを通じて、デバイス間で探索を拡張するための料金である。最初のkバケットで探索が成功しなかった場合に課金され得、クライアントは探索の延長を要求する。これは、いくらか良い結果を得るためにネットワークの徹底的な探索を実行するよりもコストを節約することができる。
ブロック16202は、例えば、ネットワークに電力が供給されたとき、または新しいデバイスがネットワークに追加されたときを表す。ブロック16204において、ネットワークが構成される。ブロックチェーンとDHTとの両方を構成する必要がある。ブロックチェーンの設定は、コンセンサスアルゴリズムの選択、マイナー(miner)または成功したブロックを提案する確認部に対する報酬レベル、アルゴリズムの難易度レベル、報酬レベルが調整される頻度などを含み得る。本明細書で使用されるように、マイナーまたは確認部は、ブロックチェーンおよびDHTにアクセスすることによってサービスまたは機能を提供可能であり得るデバイスを識別して、適したターゲットを見つけるデバイスである。アルゴリズムの難易度は、探索が成功するために照合されるべき探索項目の数を示し得る。報酬レベルは、探索を成功させるためにマイナーまたは検証者に行われる支払いとみなすことができる。それは、探索の複雑さ、結果に到達するためのホップ数などに基づいてもよい。
ブロック16206において、DHTが初期化される。DHTがインスタンス化され、動作を開始する。DHTオーナーは、既存のDHTを自由に使用したり、独自の専用プロトコルを指定または実装したりすることができ、これにより、ブロックチェーンと統合したり、独自の差別化機能を有効にしたりできる。DHTは、1つのデータの複製をネットワーク内にいくつ保持するべきかなど、一般的ではない設定を含み得る。DHTでは、ファイルは、例えば、群内のいずれかのピアの最後、またはトラッカーノードが使用できなくなったときに期限切れになり得る。本明細書で説明されるように、ブロックチェーンアウェアDHTは、ネットワーク内でファイルの複製を自動的に維持することができる。データは、そのデータのオーナーがデータの除去または削除の方法に関する条件を指定していない場合、無期限に保存され得る。それ以外の場合、データは生存期間(TTL)が固定されているか、オーナーおよび指定されたデリゲートによって除去され得る。
ブロック16208において、最初は空のブロックチェーンデータベース(DB)およびジェネシスブロックが作成される。ブロックチェーンに格納されているデータは他の場所を指している可能性があるため、すべてのデータをブロックチェーンに格納する必要はない。ブロックチェーン開発者は、実装されている特定のプロトコルを通じて、ブロックチェーンに追加された記録にどのフィールドまたはパラメータを含めるかを指定できる。ブロックチェーンを作成または保守している当事者は、その決定をアプリケーション開発者に委任することができ、アプリケーション開発者は、ブロックチェーン開発者によって許可された規則に従って、ブロックチェーン内またはブロックチェーン外に特定のデータを格納することを選択できる。この例では、ブロックチェーン外に格納されたデータは、DHTに格納されてもよい。プロセスのどの時点でも、他のユニットがマイナーまたは確認部としてネットワークに参加できる。マイナーは、格納されているリソースに関して、DHTとブロックチェーンとにデータを追加できる。確認部は、そのデータが正しいことを確認し、DHTを格納し、格納されたリソースに関するデータを見つけるために探索機能を実行することができる。
ブロック16210において、マイナーまたは検証者など、ネットワークに参加している新しい参加者がいるか否かに関する判定が行われる。もしそうであれば、ブロック16212において、新しく参加したマイナーまたは確認部がブロックチェーンデータベースおよび区画DHTをコピーし得る。次いで、プロセスフローはブロック16210に戻り、それ以上のマイナーまたは確認者がネットワークへの参加を希望しているか否かを判定する。動作中のブロックチェーンプロトコルによって許可されている場合、任意のノードがマイナーと確認部との両方になることができる。さらに、任意のノードは、ブロックチェーンストレージまたはDHTノードであり得る。ネットワークに参加している新しいノートがDHTネットワークに参加している場合、これは、DHTのプロトコル規則に従ってDHTの再区画化をもたらし得る。
ブロック16214において、ブロックチェーンデータベースおよび区画DHTのコンテンツが作成され得する。コンテンツの作成は、データがDHTに格納、複製、および配信され、データの場所を指す記録がブロックチェーンに格納される、2段階のプロセスであり得る。コンテンツ作成は、とりわけ、コンテンツソースを判定しアクセスすることなど、特定のタイプのコンテンツに対する追加の段階を含むことができる。従来のブロックチェーンに勝るこの手法の1つの態様は、ネットワーク内のすべてのマイナーまたは確認部が、すべて同じデータの記録を保持する必要があるわけではないということである。例えば、Ethereumでは、スマートコントラクトはチェーン上に格納されており、つまり、ネットワーク内のすべての確認部に重複したコピーがあることを意味する。この例では、DHTが各データオブジェクトの3つの複製を保持することを指定している場合、3つのコピーのファイル断片はDHTに参加するノードにわたって分散され、すべてのノードがすべてのファイルのフルコピーを持つ必要はない。
ブロック16216において、作成されたコンテンツに対して統一資源識別子(URI)が生成される。URIは、トラッカーが関与するところで従来の手法を使用する場合もある。しかしながら、これにより、集中型コンポーネントが導入される。従って、データをネットワーク全体に分散して保持するために、URIは、位置ベースのデータ識別子ではなく、マグネットリンクまたは同様のコンテンツベースのネットワーキング手法を利用することができる。
ブロック16218において、コンテンツ作成部は、URI、ブロックチェーンプロトコルによって規定された任意の追加のメタデータ、およびDHTに格納されているオブジェクトのコンテンツのハッシュを格納する。ブロックチェーンに格納されているハッシュは、データオブジェクトの提供を保証し、その内容が変更されていないことを検証するために使用され得る。さらに、ハッシュをブロックチェーンに格納することは、ハッシュが特定の日に存在したこと、特定のアイデンティティによって作成または所有されたことなどを確認するために使用され得る。
メタデータは、どのコンテンツ制作者が行うことを許可されているかを制御するために使用されてもよい。例えば、スマートコントラクトのオーナーは、コンピュータプログラムを作成し、それをチェーン上で「孤立」させることができ、その結果、その実行がその後中止されないようにすることができる。従って、ブロックチェーンプロトコルのオーナーは、どの機能をブロックチェーンで有効にするかについて慎重に検討する必要がある。有効にした場合、データはブロックチェーンの存続期間中削除されずにDHT内に永遠に存続し、データに対する権利は委任されない場合がある。DHT内のデータは、利用するデータ作成部が自由に使える任意の方法を使用して暗号化することができる。
ブロック16220において、作成すべきコンテンツがまだあるか否かに関する判定が行われる。コンテンツの作成は、DHTとブロックチェーンとの両方が存在し続ける限り、他のアクティビティと並行して実行される方法16200における連続的なループであり得る。
ブロック16222において、ブロックチェーン、またはDHT、あるいはその両方でコンテンツを識別することができる。コンテンツルックアップは、探索対象のハッシュとブルームフィルタとの間にビットの一致があるか否かを判定するために、ブロックチェーンに格納されたブルームフィルタをチェックすることによって開始することができる。もしそうであれば、これは、コンテンツがブルームフィルタに関連するKバケット内に存在し得ることを示し得る。次いで、コンテンツルックアップは、コンテンツが存在するか否かを判定するためにDHTを調べることができる。
コンテンツルックアップは、チェーン上に格納されなくなり、ネットワーク内のすべてのノードに複製されなくなったデータを見つけるために実行される。データは、グローバルネットワークまたはデータプレーンに格納される可能性があり、ネットワーク全体の徹底的な探索が潜在的に問題となるようにしている。DHTは、kバケットを形成するために独自の距離メトリックアルゴリズムを実装している。距離は必ずしも地理的距離を表すものではないが、例えば、参加ノード間のホップ数、それらのホップにわたるレイテンシなどに基づいてもよい。
本明細書に開示された態様は、必ずしも最良のグローバルの結果を見つける必要なく、「十分に良い」探索結果を見つけることを可能にし得る。以下にさらに開示されるように、「料金」の代替概念に基づいて、徹底的な探索に対する阻害要因を導入することができる。先に説明したように、クライアントは、特定のサービスまたはデータを提供または消費しているネットワーク内のノードを探索または発見したい場合がある。典型的なシナリオは、中央集権型のマーケットプレイスホストを必要とすることなく、データサプライヤとデータコンシューマとがお互いを見つけて連絡を取りたい、IoTデータのための非集中型グローバルマーケットプレイスである(例はeBayまたはAmazonであり得る)。
ブロック16222において、クライアントは、探索ターゲットのハッシュコードをその直近のn個のマイニングノードまたは確認ノードにブロードキャストする。ノードは、DHT距離アルゴリズムによって別のノードに「近い」と定義されている。近接していると定義されているノードは、Kバケット内のノードとみなすことができる。さらに、最も近いマイニングノードまたは確認ノードは、それらの領域内に格納されているリソースに関するかなりの量の情報を持っている。例えば、最適化としてブルームフィルタを実装しているため、クライアントブロードキャストは、否定的な場合はすばやく応答でき、肯定的な場合はより徹底的な探索を使用できる。
ブロック16226において、探索が成功したか否かに関する判定が行われる。1つまたは複数の結果が返されれば探索は成功である。ローカル放送の「料金」コストは、可能な場合にクライアントが結果を受け入れるように促す、ブロックチェーンまたはDHTプロトコル開発者の好みに応じて、最小または0になる。探索によってデータサプライヤが識別された場合、クライアントは、結果が満足できるものであるか否かを決定する必要があり、その場合、探索プロセスは終了する、または、さらに探索したい場合もある。クライアントがさらに先へ進むことを望む場合、ネットワークは、より広い探索のための「料金」コストを計算するためにアルゴリズムを適用する。
ブロック16230において、クライアントが料金を支払うことができるか否かに関する判定が行われる。一部の例では、クライアントは、より高価な探索を続行するのではなく、探索の基準を変更して異なるローカル探索を実行することを選択することができる。料金コストは、ブロックチェーンで使用される暗号化コイン通貨での支払いなど、様々な方法で支払うことができる。料金コストは、コントラクト契約に追加されるサービス料として支払われ得、供給業者と生産者とが成功したコントラクト契約を締結している。料金コストは、インターネットサービスプロバイダの請求計算の一部になり得る。
総コストがブロック16230で支払われる場合、ブロック16232において、ブロードキャストは隣接するK個のバケットに拡張される。次いで、プロセスフローはブロック16226に戻り、探索が成功したか否かを判定する。そうである場合、またはブロック16230で料金が支払われていない場合、ブロック16228で探索は終了する。
図163は、一部の実施形態による、IPメッシュネットワーク812内の異なるノードからの複数の部分鍵を単一の完全な鍵にアセンブルするためのIoTデバイス16300に存在し得るコンポーネントの一例のブロック図である。同様の番号が付けられた項目は、図3および図8に関して説明したとおりである。図8に関して説明したIoTデバイス800、および本明細書で説明される他のIoTデバイスに対して選択されたものとは異なるコンポーネントが、IoTデバイス16300に対して選択され使用されてもよいことに留意されたい。
大容量ストレージ808は、本明細書で説明される提携グループ形成を実施するための複数のモジュールを含むことができる。大容量ストレージ808においてコードブロックとして示されているが、モジュールのうちのいずれも、例えば特定用途向け集積回路(ASIC)に組み込まれるなど、ハードワイヤード回路で完全にまたは部分的に置き換えられ得ることが理解されよう。
大容量ストレージ808は、1つまたは複数の通信リンクを介して、例えばとりわけ、メッシュ送受信機810、アップリンク送受信機814、およびNIC 816を介して、メッシュデバイス812またはクラウド302内の装置に対してパケットを送信および受信する通信部16302を含むことができる。図162に関して説明した機能に加えて、図45に関して説明したように、通信部16302は、プロトコル間でのパケットの変換、プルーフオブプロヴェナンス追加などの他の機能を実行することができる。さらに、通信部16302は、図33を参照して説明した通行権システムの一部とすることができる。
ブルームフィルタ16304は、リソースまたはスマートコントラクトなどの項目に対する重複ハッシュ値を含むビットシーケンスを、関連するKバケットに保持するために、大容量ストレージ808に含まれ得る。Kバケットは、複数の異なるIoTデバイスに関する情報を含むことができ、IoTデバイスは、リソース、サービス、またはスマートコントラクトを提供することができる。ブルームフィルタ16304はまた、DHTデータベース内のエントリに関連付けられてもよい。
ブロックチェーンロジック16306は、URI、ブロックチェーンプロトコルによって規定された任意の追加のメタデータ、およびDHTに格納されているオブジェクトのコンテンツのハッシュなどのエントリをブロックチェーン内に作成するために使用され得る。コンテンツ作成部16308は、URI、メタデータ、およびハッシュコードなどの、ブルームフィルタ用およびブロックチェーン用のコンテンツを作成するために含まれ得る。探索マネージャ16312は、例えば、潜在的に肯定的な結果をもたらし得る探索からの結果を受け入れる、またはさらなる探索が必要か否かを判定する、値の探索を指示することができる。探索マネージャ16312は、探索におけるさらなるホップに必要な任意の料金を支払うことができる。
図164は、一部の実施形態による、リソース発見のためにブルームフィルタホップ方法を使用するようにプロセッサ902に指示するためのコードを含む、非一時的機械可読媒体16400のブロック図である。プロセッサ902は、バス904を介して非一時的機械可読媒体16400にアクセスすることができる。プロセッサ902およびバス904は、図9に関して説明したとおりであり得る。非一時的機械可読媒体16400は、図8の大容量ストレージ808について説明したデバイスを含むこともできるし、光ディスク、USBメモリ(thumb drive)、または任意の数の他のハードウェアデバイスを含むこともできる。
非一時的機械可読媒体16400は、ブロックチェーンデータベースを作成するようにプロセッサ902に指示するためのコード16402を含み得る。コード16404は、ブロックチェーンコンテンツを作成するようにプロセッサ902に指示するために含まれ得る。コード16406は、ブロックチェーンコンテンツをブロックチェーンDBに格納するようにプロセッサ902に指示するために含まれ得る。コード16408は、コンテンツを探索するようにプロセッサ902に指示するために含まれ得る。コード16410は、1ホップ内のデバイスにクエリをブロードキャストするようにプロセッサ902に指示するために含まれ得る。コード16412は、探索が成功したか否かを判定するようにプロセッサ902に指示するために含まれ得る。コード16414は、さらなる探索ホップの料金を支払うようにプロセッサ902に指示するために含まれ得る。
デバイスは、ピアデバイスを使用して、例えば、データの交換、複数のアーキテクチャにわたるインストルメンテーションへのアクセス、および並列処理を含む、複雑なタスクを協調して作成できる。一例では、複数のデバイスにわたって複雑なデバイスを構成するために、デバイスは可能なピアを識別することができる。潜在的なピアが識別されると、デバイスは、ピア間で使用するためのデジタル許可ガイドを符号化することができる。許可ガイドは、ピアデバイスがどのサービスまたは機能を使用、アクセス、または他のピアに提供することを許可されるかを判定するポリシーまたは規則のセットであり得る。許可ガイドの一部として、デバイスは、許可ガイドまたはタスクに概説されているように、複雑なタスクからサブタスクを実行し、1つまたは複数のピアおよびピアデバイスに関連するあらゆるユーザからシグネチャを取得するように、ピア自身を自動的にコミッショニングするようにピアに要求することができる。一例では、すべての当事者が許可ガイドに署名したことをデバイスが検出したことに応答して、デバイスは、許可ガイドの主題をアクティブ化するための信号を提供することができる。許可ガイドに概説されている動作は、ブロックチェーンを通して行われる場合もある。一例では、デバイスの許可ガイドで概説され合意されたように、価値またはクレジットを指定された当事者に譲渡することができる。
許可ガイドの使用および協調するデバイスの使用はまた、アドホックネットワークの形成および制御にも使用することができる。これらの許可ガイドによるアドホックネットワークの制御は、時間で制限され得る、または許可ガイドに概説されている時間指定に基づいて制限され得る。この概念では、許可ガイドは、人間によっても、自律的に動作するマシンによっても作成され得る。
図165は、一部の実施形態による、タスク定義およびコミッショニングのための例示的な方法16500の概略図である。図165の方法16500は、図167に関して説明されるIoTデバイス16700によって実施することができる。示されている概略図は、アドホック許可ガイドおよび許可ガイド機能16502に対するタスク定義およびコミッショニングを表すことができる。しかしながら、相互作用のプロセスは、16504から始まり得る。
ブロック16504において、デバイスは、タスクを実行するために使用するピアを識別することができる。デバイスはこの発見を実行することができるが、この文脈におけるデバイスという用語はまた、単一のデバイスまたは複数のデバイスを介して動作するエージェントまたはサービスを指すことができる。ブロック16504でのピアおよびそれらの能力の発見は、デバイスの発見手続き、要求のシステム、定義済みプロトコル、または上述のようなリソース発見のブルームフィルタホップ方法を介して行うことができる。
ブロック16506において、デバイスは、許可ガイドおよび許可ガイド機能16502を生成することができる。許可ガイドおよび機能は機械可読であり得る。許可ガイドは、ブロックチェーン上、ブロックチェーン外に格納することができる。一例では、許可ガイドは発見可能であり得、デバイスによって発見されたピアにアドバタイズされ得る。ブロック16506において、デバイスは、実行される機能を、許可ガイドに書き込まれるべき個別の機能に構成することができる。一例では、機能は、固定機能、汎用、または特殊化されたコードセグメントであり得る。機能は、人間の開発者、コードを生成するための人工知能(AI)メソッド、または任意の組み合わせによって作成することができる。一例では、機能は遺伝的アルゴリズムを通じて生成されてもよい。
ブロック16508において、デバイス、ピア、またはデバイスおよびピアのアドホックネットワーク内の任意の他の当事者によって許可ガイドを交渉または編集することができる。許可ガイドの様々な態様を編集できる。例えば、許可ガイドは、許可ガイドに参加および脱退するための方法を含む上述のフォーマットを有することができる。許可ガイドを交渉することの一部として、許可ガイドが許可ガイドの属性および機能をアドバタイズした後に編集を行うことができる。属性または機能のアドバタイズに応答して、デバイスのピアは、許可ガイドに同意すること、またはそれを挿入または編集することによって、これらの属性または機能を提供することに合意することができる。一例では、ピアリソースまたは他の機能の間の任意のサービスにアクセスする試みにおいて、デバイスまたはピアによる認可が提供される場合、デバイスは、許可ガイドを介してトークンの生成を要求することができる。一例では、許可ガイドは、時間制約、サービス品質、またはデータ品質を含む追加の情報を有する制限を有する機能を含むことができる。一例では、許可ガイドは、許可ガイドオーナーが参加ピアから要求することができる他の条件を含むことができる。許可ガイドは、ソースピアの限定的な使用方法について概説し得る。一例では、許可ガイドは、マルチテナントを許可するように移動し得る。
上述のように、条件はピアによって交渉することができる。例えば、データコンシューマとデータプロバイダとは、許可ガイドに入る前に条件について交渉するメカニズムを持つことができる。一例では、当事者は、条件およびレートをアドバタイズすることができる。一例では、条件およびレートは交渉可能であり得る。このようにして、許可ガイドに参加しているエンティティは、不利な許可ガイドに拘束されないことを確実にするための立場を維持することができる。これらの条件の例には、データ提供者が課すことを望み得る最低サブスクリプションレートおよび期間が含まれ得る。
ブロック16510において、許可ガイドを実行することができる。許可ガイドの実行は無期限に実行できる。一例では、許可ガイドの実行は、固定された指定された時間の間であり得る。サービスプロバイダとの通信の失敗または許可ガイドをピアに提供するデータの失敗に応答して、許可ガイドは終了することができる。同様に、新しいピアが、デバイスまたはサービスから機能の性能を向上させる場合、許可ガイドの機能を引き継ぐことができる。許可ガイド機能の改善は、より低いレート、より高いデータ品質、または他の測定可能なメトリックで許可ガイドで使用されるサービスの性能を含むことができる。一例では、許可ガイドの実行中に実行するためのメカニズムのリストは、許可ガイドが始まる前に許可ガイドに記録することができる。
ブロック16512において、許可ガイドの実行を監視することができる。許可ガイドの実行を監視することは、新しいピアおよび新しいノードを探索することを含むことができる。ブロック16514において、許可ガイドが満たされるという合意された条件に応じて、参加当事者間で支払いが行われ得る。一例では、支払いは許可ガイドに指定することができる。ブロック16516において、許可ガイドの期間が終了すると、許可ガイドを終了することができる。一例では、参加当事者のいずれかが許可ガイドを脱退し、代替の当事者を見つけることができないという判定に応答して許可ガイドを終了することができる。一例では、許可ガイドは、許可ガイドが作成された目的が達成されたという検出に応答して終了することができる。
アドホック許可ガイド16502内に、許可ガイド機能が記述されてもよい。例えば、アドホック許可ガイド16502内の機能は、参加許可ガイド機能16518を含むことができる。参加許可ガイド機能は、上述したように実施することができる。アドホック許可ガイド16502はまた、上述のよう脱退許可ガイド機能16520を含むことができる。アドホック許可ガイド16502は、参加しているデバイス16522をリストする機能を含むことができ、これは上述した他のデバイスリスト機能と同様であり得る。アドホック許可ガイド16502は、上述のようにデバイス属性リスト機能16524を含み得る。
一例では、アドホック許可ガイド16502は、アドホック許可ガイド16502に追加されたデバイスの条項および条件を考慮する機能を含み得る。デバイス条項および条件リスト機能16526は、許可ガイドに参加するデバイスが、アドホック許可ガイド16502内のパラメータまたは機能として含まれるそれらのサービス条件に関する条件を有することを可能にし得る。一例では、デバイス条項および条件リスト機能はまた、許可ガイドの参加当事者に課される、または許可ガイドの参加当事者によって合意される許可ガイドの一部として合意され得るペナルティを施行するための機能を含み得る。
一例では、アドホック許可ガイド16502は、サービス品質(QoS)条項および条件(T&C)リスト16528を考慮する機能を含み得る。QoS T&Cリスト16528は、許可ガイドからのサービスデータのコンシューマがサービスおよびデータの供給についてのQoS規則を規定することを可能にすることを含むことができる。これらの規則は、例えば、データの利用可能性、サービスの利用可能性、供給されるデータの頻度、供給されるデータの正確さ、およびデータの粒度の仕様を含むことができる。QoS T&Cリスト16528はまた、データがトラステッドセンサからのものである場合、規則を含むことができ、データは、データの提供が、例えば、プロセッサ内のコードによって生成された値ではなくセンサによる測定から来たことを示すことができる場合、トラステッドセンサからのものであり得る。アドホック許可ガイド16502は、上述のようにトークン要求機能16530およびトークン失効機能16532を含み得る。
一例では、アドホック許可ガイド16502は、支払い条項および条件を考慮する機能を含み得る。従って、アドホック許可ガイド16502は、当事者間の支払いをトリガするイベントを示すための支払いT&C機能16534を含み得る。一例では、当事者間の支払いをトリガするこれらのイベントは、サブスクリプションのサービスの提供の履行、サブスクリプションに関するデータの提供の履行を含み得る。T&C機能16534は、ペイパーユースモデルまたは他のモデルの枠組みの中で機能するように書くことができ、以前に合意した条件を遵守しなかったことに対する許可ガイドへの当事者へのペナルティの強制のための機能もあり得る。
一例では、アドホック許可ガイド16502はデータプレーン機能16536を含み得る。データプレーン機能16536は、データまたはサービスがどのように供給され消費されるかに許可ガイドの当事者が同意することを可能にし得る。データプレーン機能16536は、データがチェーン外メカニズムにおいて共有され得ることを指定し得、データプレーン機能16536は、データが利用可能にされ得る特定のエンドポイントおよびエンドポイント技術を指定し得る。1つの例では、データは、エンドポイントをソースにサブスクライブさせる機能を通じて、または消費のためにデータをパブリッシュする機能を通じて利用可能にすることができる。一例では、許可ガイド16502に参加する当事者によるデータ消費およびサービス消費の手段は、認証および認可情報を含み得る。アドホック許可ガイド16502の当事者は、サービスまたはデータを提供することができ、また当事者が消費嗜好を利用可能にすることができる方法を指定することができる。データおよびサービスを利用する当事者はまた、消費当事者がどのように認証および認可を消費することができるかについての好みを指定することもできる。
供給技術および消費技術に関して示された重複は、人間が関与することなく、当事者がサービスおよびデータの共有方法について合意することを可能にし得る。一例では、プロトコル変換ブローカが、許可ガイド16502に参加し得る当事者として導入されて、コンシューマおよび消費当事者によって望まれるエンドポイントタイプまたはデータフォーマットへのサービスおよびデータの自動変換または自動プロキシ化を提供し得る。
図166は、一部の実施形態による、プロトコル変換ブローカによるプロトコル変換ブローカリングのための例示的な方法16600のプロセスフロー図である。図166の方法16600は、図167に関して説明されるIoTデバイス16700によって実施することができる。プロトコル変換ブローカの概念は、例えば、コンシューマによって望まれるエンドポイントタイプまたはデータフォーマットへのサービス/データの自動変換または自動プロキシ化を提供するために、許可ガイドに参加し得る当事者であり得る。プロセスフローは、ブロック16602で開始し得る。
ブロック16602において、ピアを発見することができる。これは、プロトコル変換ブローカによって、当事者によって、または許可ガイド16502の計算によって行うことができる。一例では、ピアの発見は初期段階であり得る、またはピアが確実に知られるようにプロセス全体を通して繰り返され得る。
ブロック16604において、許可ガイド16502が潜在的参加者間でドラフティングされ得る。アドホック許可ガイド16502のドラフティングは、アドホック許可ガイド16502のドラフティング段階中に行われる1つまたは複数のタスクの定義を含むことができる。一例では、タスクはサービスの供給を指すことができる。一例では、サービスを供給することは、そのサービスに関して供給者によって提供された情報を利用することができる。サービスの供給者は、ルックアップサービスを通して彼らのサービスをアドバタイズすることができる。ルックアップサービスは中央集権型でも非集中型でもよい。本明細書では、サービスをルックアップする1つの方法を説明する。一例では、アドホック許可ガイド16502のこのドラフティングは交換の段階を含むことができ、許可ガイド16502内のピアが特定のパラメータについて指定された範囲を有することができる。パラメータは、当事者によって優先としてマークされてもよい。パラメータは、他の当事者の好みと比較して好みの順序付けられた重み付けを提供することができる。
ブロック16604において、許可ガイド16502に参加することができる。プロトコル変換ブローカは、許可ガイド16502に参加することができる。プロトコル変換ブローカは、1つまたは複数の当事者による許可ガイド16502への参加を監督することができる。一例では、許可ガイド16502は、許可ガイド16502が終了するか否か、またはサービスのコンシューマが続行して代替サプライヤを見つけようとするか否かを判定するために後で使用され得る生存期間(TTL)パラメータを含み得る。許可ガイド16502にさらされるデバイスはまた、許可ガイド16502のパラメータを満たすために最低限の数の当事者を有することができる。一例では、これらのリストされたパラメータは、サービス、参加デバイスの属性、T&C、およびQoSパラメータに関して概説され得る。参加許可ガイド段階中に、当事者は、プロトコルのタスクの実行のためのより低コストのエンティティの識別に応答して、プロセスに対して参加、脱退、または排除され得る。同様に、当事者は、より高い正味値のエンティティとのタスクまたはプロトコルの実行のためのエンティティの識別に応答して、参加、脱退、または排除され得る。
一例では、タスクコンシューマによって提示されることが好まれる3つの特定の特徴および属性がある場合、これらの特徴および属性は、異なるコストで3つの異なる当事者によって最初に供給され得る。この段階の間、この例では、より良いプライスポイントでサービスを供給し得る単一の当事者の識別に応答して、この見つけられた単一の当事者を使用することがより最適な解決策となり得る。
ブロック16608において、プロトコル変換ブローカはサービス提供ノードの自動コミッショニングを要求することができる。サービス提供ノードは、アドホック許可ガイド16502に概説されているサービスを提供するノードを指すことがある。自動コミッショニングは、タスクコンシューマによって指定された方法でデータおよびサービスを処理するための機能を含む、その分野におけるIoTデバイスへのマイクロサービスのデプロイを含み得る。一例では、自動コミッショニングは、手動の介入なしに妥当な期間内に自動的にまたはリモートで行うことが可能なタスクを含み得る。指定されている場合、自動コミッショニングはまた、現場でのデバイスの手動デプロイを使用してもよい。手動デプロイ、人間、訓練を受けた動物、無人機、またはロボットによるデプロイを含み得る。一例では、供給者によるデプロイ時間を含むQoS設定が当事者による許可ガイド16502の要求を満たす場合、手動デプロイをこのプロセスのバージョンで使用することができる。
一例では、定数、識別子、演算子、予約語、およびセパレータ、ならびにプリアンブルを含む機能を説明するためのトークンまたはオブジェクトを、許可ガイド16502内で当事者に提供することができる。先に説明したように、プリアンブルは、構成、初期化、およびピア間の任意の情報の交換を含むことができ、それらはさらに進むために使用され得る。プリアンブルは、サービスの位置、機械可読アプリケーションプロトコルインターフェース(API)記述子、アクセスクレデンシャル、鍵へのアクセスを含み得る。一例では、失敗したプリアンブルは、供給者のクリティカルマスの損失、コンシューマの損失、プロセスの脱落を含み得る。当事者が脱落した場合、プロセスは、アドホック許可ガイド16502のドラフティングに戻ることができる。
プリアンブルおよびそれに続く段階が存在し成功している場合、ブロック16610において、許可ガイド16502の実行が開始される。プリアンブルおよび許可ガイド16502の条件およびパラメータに基づき、そして当事者の条件に同意し、条件が満たされれば支払いをアンロックすることができる。一例では、許可ガイド16502のドラフティングにおいて条件が交換され同意されている。
ブロック16612において、ピアが許可ガイド16502への参加を終了しているという検出に応答して、プロトコル変換ブローカを介して最終支払いを行うことができる。許可ガイド16502が既存のメンバと共に機能し続けることができる場合、TTLが期限切れになっていないという判定がある場合、許可ガイド16502は機能し続けてもよい。しかしながら、プロセスが完了する前にTTLが期限切れになると、許可ガイド16502は終了することができる。一例では、許可ガイド16502が代替の供給者またはコンシューマを見つけることなしに続行することができない場合、プロセスはピア発見段階16602に戻ることができる。
図167は、一部の実施形態による、タスクおよびコミッションノードを定義するためにIoTデバイス16700に存在し得るコンポーネントの一例のブロック図である。同様の番号が付けられた項目は、図8において説明したとおりである。
上でも示したように、図8を参照すると、大容量ストレージ808は、本明細書で説明されるグループ作成機能を実施するための複数のモジュールを含むことができる。大容量ストレージ808においてコードブロックとして示されているが、モジュールのうちのいずれも、例えば特定用途向け集積回路(ASIC)に組み込まれるなど、ハードワイヤード回路で完全にまたは部分的に置き換えられ得ることが理解されよう。大容量ストレージ808は、発見された複数のピアに関する許可ガイド16502をドラフティングするための許可ガイドドラフト部16702を含むことができ、発見された複数のピアは、それぞれパラメータを有し、許可ガイド16502の条件は、その条件が発見された複数のピアのうちの少なくとも2つによって許容されることに応じて生成され得る。発見された複数のピアのうちの各発見可能なピアのパラメータは、関連付けられたピアについての許容可能な条件範囲の範囲を含み得る。許可ガイドドラフト部16702は、発見された複数のピアの条項および条件を列挙する機能を含み得る。許可ガイドドラフト部16702は、例えば、発見された複数のピアのためのサービス品質条項および条件を列挙することを含み得る。許可ガイドドラフト部16702は、発見された複数のピアのためのデータプレーン条項および条件を列挙することを含む。一例では、データプレーンは、データがピアによってどのように供給および消費されるべきかについてのプロセスを示し得る。許可ガイド16502はまた、上述のように生存期間を含むことができる。一例では、許可ガイド16502は、ピアによる許可ガイド16502への参加および脱退を管理するためのプロトコル変換ブローカを含み得る。許可ガイド16502は、発見された複数のピア間の構成の交換を管理するためのプリアンブルを含み得る。
大容量ストレージ808は、条件が満たされたことを検出したことに応答して許可ガイド16502の動作を実行するための動作実行部16704を含み得る。アクション実行部16704は、データを処理するようにピアに命令するピアへのサービスの自動コミッショニングのための機能を含み得る。一例では、この用語は、発見された複数のピアの間で支払われるべき支払いのレートを指し、複数の発見されたピアのうちのピアが許可ガイドへ16502の参加を終了していることの検出時にピア間で最終的な支払いが行われ得る。
図168は、一部の実施形態による、タスクおよびコミッションノードを定義するためのコードを含む、非一時的機械可読媒体16800のブロック図である。同様の番号が付けられた項目は、図9において説明したとおりである。
非一時的機械可読媒体16800は、発見された複数のピアに関する許可ガイド16502をドラフティングするようにプロセッサ902に指示するためのコード16802を含み得、発見された複数のピアは、それぞれパラメータを有することができ、許可ガイド16502の条件は、その条件が発見された複数のピアのうちの少なくとも2つによって許容されることに応じて生成され得る。許可ガイド16502のドラフティングは、発見された複数のピアの条項および条件を列挙する機能を含み得る。許可ガイド16502のドラフティングは、発見された複数のピアのためのサービス品質条項および条件を列挙することを含み得る。許可ガイド16502のドラフティングは、発見された複数のピアのためのデータプレーン条項および条件を列挙することを含み得る。データプレーンは、データがピアによってどのように供給および消費されるべきかについてのプロセスを示し得る。許可ガイド16502は生存期間を含むことができる。許可ガイド16502は、ピアによる許可ガイド16502への参加および脱退を管理するためのプロトコル変換ブローカを含み得る。許可ガイド16502は、発見された複数のピア間の構成の交換を管理するためのプリアンブルを含み得る。
非一時的機械可読媒体16800は、条件が満たされたことを検出したことに応答して、許可ガイド16502の動作を実行するようにプロセッサ902に指示するためのコード16804を含み得る。許可ガイド16502の動作を実行することは、例えば、データを処理するようにピアに命令するピアへのサービスの自動コミッショニングを含み得る。本明細書で使用される場合、この用語は、発見された複数のピアの間で支払われるべき支払いのレートを指す。一例では、複数の発見されたピアのうちのピアが許可ガイドへ16502の参加を終了していることの検出時にピア間で最終的な支払いが行われ得る。
フローティングサービスは、フローティングサービスに関連するデジタルウォレットを管理し、ホスティング、ならびにフローティングサービスのソフトウェアを使用することができジョブについて交渉する、インターネットで出回っているウェブサイトまたは仮想サービスであり得る。フローティングサービスは、ハードウェアの範囲で実行するためのソフトウェアを含むことができ、ソフトウェアの実行は、サービスのソフトウェアおよび使用されているハードウェアに部分的に基づいて様々な効率で実行することができる。サービス選択ソフトウェアおよびサービス選択ハードウェアを使用してジョブを実行すると、完了したジョブの支払いが発生し得る。
本明細書で使用されているように、支払いは、フローティングサービスが処理している売り上げの手数料を介して実行することができる。支払いは、フローティングサービス上またはサービスによって提供された広告に対して補償されてもよい。一例では、ジョブを処理する際に使用するためにいくつかのサービスを比較することができる。複数のサービスはそれぞれ、それら自身のデジタルウォレットに関連付けられてもよい。フローティングサービスは、フローティングサービスによって完了された作業に対して支払われてもよいが、追加的に、例えば、合意されたジョブを完了するために、フローティングサービスは、リソース、ソフトウェア、またはサブサービスへのアクセスに対して支払ってもよい。デジタルウォレットの値がゼロになると、フローティングサービスも機能しなくなる可能性がある。値のない機能を停止することにより、フローティングサービスの管理者またはオーナーは、複数のサービスについてデジタルウォレット間で値を割り当てることができる。フローティングサービスの管理者は、デジタルウォレットが関連ウォレットの設定値に達したことの検出に応答して、値を自動的に補充または引き出すようにデジタルウォレットを設定することができる。一例では、フローティングサービスは、ビットコイン、litecoin、dogecoin、他の暗号通貨、タンパク質折りたたみ予測、ならびにフローティングサービスがデジタルウォレットに価値を返すために完了することができる他のプロセッサおよびソフトウェアベースのジョブまたはサービス中心のジョブをマイニングするためのサービスを含み得る。一例では、専用コンピュータが、フローティングサービス用のホストまたは雇われたホストとして働くことができる。
図169は、一部の実施形態による、デジタルウォレット内のフローティングサービスおよび価値を管理するための例示的な方法16900のプロセスフロー図である。図169の方法16900は、図172に関して説明されるIoTデバイス17200によって実施することができる。示されている概略図は、フローティングサービスライフサイクルおよびドラフティングされたフローティングサービス許可ガイド16902のプロセスを表すことができる。フローティングサービスライフサイクルのプロセスは、ブロック16904で開始することができる。同様の番号が付けられた項目は、図165において説明したとおりである。
ブロック16904において、フローティングサービスは、そのサービスがタスクを実行するために使用することができるホストを識別することができる。ホストおよびホスト能力のこの発見は、上で開示されたようにブルームフィルタホップを使用して実行され得る。ブロック16906において、フローティングサービスは、ブロックチェーン上またはブロックチェーン外に格納され得る機械可読許可ガイドを作成し得る。一例では、許可ガイドは、識別されたピアおよびホストに発見可能であり得る。許可ガイドは、識別されたピアおよびホストにアドバタイズされてもよいし、ネットワーク上で識別されていないデバイスによって発見可能であってもよい。ブロック16906において、フローティングサービスは、実行されるタスクを機能に構成することができる。機能は許可ガイドに書くことができる。タスクおよび構成された機能は、一般的な目的で小さな固定機能に分割することができる。タスクおよび構成された機能はまた、特殊なコードセグメントに分割される場合もある。タスクコードおよび機能コードは、例えば、遺伝的アルゴリズムを含む人工知能によって生成されてもよい。
ブロック16908において、許可ガイドを事前定義されたフォーマットに合うように修正することができる。許可ガイドのフォーマットの一例は、ピアおよびホストが許可ガイドのガイダンスおよび施行に参加および脱退することを可能にするフォーマットであり得る。許可ガイドはまた、属性およびホストが提供することに合意した機能のリストも含み得る。ホストによって合意された機能は、例えば、ネットワークサービス、負荷分散、完全修飾ドメイン名(FQDN)の使用、ドメインネームシステム(DNS)の使用、およびファイアウォールサービスを含み得る。許可ガイドは、任意の参加ピアおよびホストと同様に、許可ガイドのオーナーが従うべき時間制約およびサービス品質条件のリストを含むことができる。一例では、許可ガイドは、許可されたマルチテナントを通じて、またはホストハードウェアへの直接アクセスの共有を通じて、ホストの専用ハードウェアを使用することができる。上で列挙されたパラメータ、およびフローティングサービスによって使用され得る他のパラメータは、要求しているフローティングサービスから1つまたは複数のホストプロバイダに支払われる、より高いまたはより低い料金の判定に供給され得る。
ブロック16910において、許可ガイドは実行を開始することができる。実行は、許可ガイドによって管理されているデバイスで受信された条件、機能、および入力に基づいてもよい。上記のように、許可ガイドは、設定された固定時間、固定時間なし、または条件ベースの実行を有することができる。許可ガイドの実行の一例では、許可ガイドは、サービス提供ピアが消滅したこと、またはデータ提供ピアが消滅したことの検出に応答して終了することができる。一例では、ピアおよびホストが、許可ガイドで合意されているレートよりも低いレートでサービスを提供していることがことが検出された場合、ピアデバイスまたはホストデバイスを交換、置換、またはデコミッションすることができる。ピアデバイスまたはホストデバイスはまた、データ品質が許可ガイドで合意されたメトリックと一致しない場合があるという検出に応答して、交換、置換、またはデコミッションされ得る。
ブロック16912において、サービスエンティティおよびホスティングエンティティは、許可ガイドにリストするための相互に合意された条件を識別するためにホストとピアとの間で条件を交換する機能を含み得る。許可ガイド内の条件は、実行優先度、通信帯域幅、アクセス許可などを含み得る。ブロック16914において、フローティングサービス16902の許可ガイドのガイダンスに参加したピアとホストとの間で支払いが交換されてもよい。支払いは、フローティングサービス許可ガイド16902によって概説された条件が満たされたときに交換されてもよい。一例では、支払いの交換は、支払いを準備すること、および支払いデータをサービスウォレット16916に提供することを含み得る。支払いは、既存の価値を通じて、またはピア、ホスト、またはフローティングサービス許可ガイド16902に参加した他の当事者からのサービスウォレットへのクレジットを通じてであり得る。一例では、2つのウォレット間のクレジットの交換は、サービスウォレット16916からホストウォレット16918までであり得る。任意のエンティティのウォレットは、価値、クレジット、またはデビットの数値表現の論理的なストレージであり得る。一例では、ピアまたはホストは、それらのウォレット内の価値によって制限され得る。ピア、ホスト、または他のプロバイダがフローティングサービス許可ガイド16902の義務を果たすことに失敗した場合、サービスウォレット16916と被害者のウォレットまたは一般的な価値保持場所との間の価値の交換で、ペナルティおよびサービスウォレット16916からの払い戻しが可能になり得る。義務の違反の1つの例は、合意された利用可能性レベルを満たさないピアまたはホストを含むことができる。一例では、ホスト、ピア、またはフローティングサービスの機能は、そのサービス、ピア、またはホストに関連付けられたウォレットに格納されている値に基づいて調整、管理、または制限され得る。一例では、資金がサービスウォレット16916で使い果たされると、そのウォレットに関連付けられているアクセスピアまたはホストを許可ガイド16902から除去することができる。関連付けられたウォレット内の値が指定された閾値より低いまたは高いときに、フローティングサービスオーナーに通知するために警告閾値を設けることができる。警告閾値は、ウォレット内の値が指定された閾値に到達するかまたはそれを通過することに基づくサービスの自動カットオフまたはスロットルに関連付けられてもよい。
ブロック16920において、許可ガイド16902を終了することができる。終了は、ピアまたはホストによって満たされる条件に応じて適用され得る。許可ガイド16902の終了は、経過時間、脱退するピアの数、脱退するホストの数、脱退するピアの割合、脱退するホストの割合、入ってくるピアおよびホストの欠如、許可ガイド16902で合意された任意の他の手動設定ガイドラインに応答してもよい。
許可ガイド16902の機能の1つとして、ホスト属性機能16922は、許可ガイドに参加したホストが提供し得る能力のリストを提供する。一例では、ホストが提供することができる能力は、アテステーション機能、トラステッドベースの機能、およびホストおよび機能へのアクセスのための認可の証明の許可ガイド16902による受信時に動作する機能を含み得る。ホスト属性機能のサービスの値を維持するために、ホスト属性機能16922の利用可能性は、そのような機能への供給またはアクセスを減らすために制限されてもよい。ホスト属性機能16922は、ホスト機能アクティビティおよびホスト機能挙動の周囲のサービスに関するホスト機能条件のリストと関連付けられてもよい。ホスト属性機能16922は、フローティングサービスがホスト属性機能16922の条件に違反することを検出すると、ホスト機能へのアクセスを拒否するか、またはペナルティを課すことができる。
ホストサービスのリスト16924および対応するサービス条項および条件(T&C)リスト16926は、許可ガイドに参加するサービスが許可ガイド16902内のパラメータまたは機能として含まれるそれらのサービスのレベルに関する条件を示すことを可能にするために組み合わされる。一例では、許可ガイド16902にリストされているパラメータは、フローティングサービスおよびフローティングサービス動作に対するそれらの優先度または優先度の欠如を示す尺度で評価され得る。サービスT&Cリスト16926は、ピアおよびホストによって合意され得るペナルティを概説し得る。これらのペナルティは、フローティングサービス許可ガイド16902の合意された条件に達するピアまたはホストに適用され得る。
図170は、一部の実施形態による、フローティングサービス17002、ならびにオプションおよび条件および条項を管理するための例示的なフローティングサービスデータ構造17000の概略図である。一例では、フローティングサービスデータ構造17000は、条件、条項、および機能の優先度に基づいて、フローティングサービスの条件、条項、および機能を示すことができる。例示的なフローティングサービスデータ構造17000に示されているリストされたオプション、条件、条項、機能、値、およびそれらの関連する優先度は例示的であり、フローティングサービス許可ガイド16902の条項および条件のリストに含まれ得る。
フローティングサービスデータ構造17000は、ホストを選択するときに計算コスト、既知コスト、および未知コストを評価することができる。一例では、フローティングサービス17002は、データ構造17000を使用して、組み合わせ識別されたコストを、フローティングサービスおよびジョブの機能および識別された機能要求のリストと比較することができる。一例では、フローティングサービスに関する機能のリストをデータ構造17000の決定マトリクスに挿入することができる。
データ構造17000の決定マトリクスは、識別されたホスト、ピア、およびフローティングサービス17002に利用可能な他のデバイスまたはリソースの比較を含み得る。提供された例では、データ構造17000は、3つのホスト、すなわち、ホスト1、ホスト2、およびホスト3から収集された例示的なデータを示す。例示的なデータ構造17000では、機能の優先度およびホストから収集されたデータに基づいて、フローティングサービス17002は、ホスト2および3がフローティングサービスの実行のための可能なホストであると判定し、その際、少なくとも部分的には、ホスト3に関して受信したデータにおける優先度を伴う機能の存在の増加に起因して、ホスト3がより高くランク付けされ得る。この例では、ホスト3は、より高い名目コストを表示し、例示的なフローティングサービスデータ構造17000に示される、より高い決定スコアまたは値を受け取ることが示される。より高い値は、考慮される他の機能、オプション、条件、および条項と比較して重要度による優先度が高い機能をホスト3が満たした結果であると考えられる。この決定スコアおよび値を計算する式は、ホストの1時間当たりのコストの和を、フローティングサービス17002のフローティングサービスデータ構造17000における比較のためにリストされた各機能、オプション、条件、または条項の和によって除する計算方法を含む複数の方法で計算され得る。
図171は、一部の実施形態による、フローティングサービス管理のための例示的な方法17100のプロセスフロー図である。図171の方法17100は、図172に関して説明されるIoTデバイス17200によって実施することができる。プロセスフローは、ブロック17102で開始し得る。
ブロック17102において、フローティングサービスが作成され得る。フローティングサービスは、広範囲のハードウェアシステム上で実行可能なカプセル化モジュール内に作成することができる。一例では、カプセル化モジュールは、ドッカーコンテナなどのコンテナ、および仮想マシンを含む仮想化構成体であり得る。一例では、カプセル化モジュールは、ソフトウェアバイナリをパッケージ化し配信するために使用され得るフレームワークとすることができる。次いで、フローティングサービスは、フローティングサービスのオーナーがフローティングサービスの優先度を指定できるようにするために要求を割り当てることができる。一例では、優先度は、ハードウェアのオプションを含む機能または特定の能力を含むことができる。ハードウェア機能は、CPUの容量および能力、ストレージの容量および能力、メモリの容量および能力を含み得る。一例では、これらの容量および能力は、ハードウェアアクセラレータが存在するか否かの評価を含み得る。一例では、ハードウェアアクセラレータが存在する場合、アドバンスト暗号化規格(AES)、SGX、仮想化(VTx)、または高可用性サービスを含むハードウェア対応機能が評価され得る。フローティングサービスのオーナーはまた、評価対象の機能としてソフトウェアの依存関係を指定することもできる。評価されるソフトウェア機能としては、例えば、オペレーティングシステムの種類、オペレーティングシステムのバージョン、ソフトウェアのバージョン、パッチレベル、ならびにメッセージングおよび通信用の階層化アプリケーションの存在を挙げることができる。ブロック17102でフローティングサービスを作成している間に、サービス品質およびフローティングサービスの条項および条件を添付することができる。一例では、サービスオーナーまたは接続されたデータ源は、フローティングサービスの地理的位置またはハードウェアの排他性ステータスを示すことができる。ブロック17102でのフローティングサービスの作成は、サービスウォレットを添付することを含み得る。一例では、フローティングサービスのオーナーは、フローティングサービスに関連する新しいウォレットを作成することができる。一例では、フローティングサービスは、既存のウォレットを関連付けるまたは共有することができる。本明細書で使用されるとき、ウォレットは、任意の価値のストアを指すことができ、ビットコインウォレット、イーサリアムウォレット、およびグーグルウォレットを含むことができる。フローティングサービスには、PayPalおよびVisaのオンラインサービスと同様の、そしてPayPalおよびVisaのオンラインサービスを含む、支払いサービスなど、ウォレット以外の特定の形態の資金調達も含まれ得る。ブロック17102でのフローティングサービスの作成は、フローティングサービスに対する資金調達規則の割り当てを含むことができる。一例では、フローティングサービスのための規則は、ウォレットが補充されるようにする、または補充されないようにする資金調達トリガを含み得る。一例では、1つの設定は、ウォレットの残高が閾値を下回ったという検出に応答して、ユーザによる予め選択された量だけのウォレットの自動補充または補給を含むことができる。フローティングサービスのオーナーは、フローティングサービスが関連するウォレット内のゼロ値ポイントに到達した場合、または負の値の生成率が検出された場合に、フローティングサービスが実行を停止することを示すフローティングサービスの規則を示すことを選択し得る。ブロック17102でフローティングサービスの作成中に開始された追加の規則は、日付トリガ、イベントトリガ、および残高トリガの組み合わせを含むことができる。フローティングサービスは、これらのトリガを、特定のウォレットの補充動作が行われ得るという指示として使用することができる。一例では、ウォレットは、特定の閾値を超える残高の検出に応答して資金を別個のウォレット、口座、または金融サービスに転送する、または識別された日付トリガまたはイベントトリガを渡すことができる。資金の転送は、指定された量の資金の転送、識別された余剰資金、またはウォレットの中の資金の合計を含み得る。一例では、ウォレットはTTL基準を含むことができる。一例では、フローティングサービスオーナーは、TTLの値を指定することができる。TTLは、実行する動作数、資金転送の回数、またはウォレットへのトランザクション数に対する制限を含み得る。一例では、日付に関する特定の基準、サービス上の活動レベル、およびフローティングサービスの移動に関する基準がある場合、フローティングサービスのTTLも自動的に拡張され得る。
ブロック17104において、フローティングサービスがディスパッチされ得る。フローティングサービスのディスパッチは、フローティングサービスの全構成が完了したという指示に応答して開始することができる。フローティングサービスの構成は、部分的にはブロック17102に関して開示されている。一例では、ディスパッチメカニズムは、上述のように、使用されるカプセル化モジュールによって決定され得る。一例では、サービスがコンテナである場合、コンテナをデプロイするための既存の方法は、それに対して適切なターゲットホストが見つかれば使用することができる。フローティングサービスのディスパッチに応答して、ホストが発見され得る。一例では、ターゲットホストを見つけることは、ホスティングサービスを提供するシステムを最初に探索することを含み得る。ブロック17104からのフローティングサービスのディスパッチに応答して、コントラクトがエニュメレーションされ得る。一例では、サービスを提供するシステムは複数の許可ガイドを提供することができ、許可ガイドは異なる基準を含むことができる。許可ガイドがエニュメレーションされ得る。ブロック17104からのフローティングサービスのディスパッチに応答して、ホストおよび許可ガイドが選択され得る。一例では、特定のホストを選択し、特定の許可ガイドを選択するための方法は、上述のように行われ得る。
ブロック17104からのフローティングサービスのディスパッチに応答して、以下に説明されるように条項および条件が交渉または交換され得る。一例では、ピア、ホスト、または他の当事者が許可ガイドの一部を交渉可能としてマークしている場合、それらのパラメータの周りに範囲を指定することができる。とりわけ権利のために料金を支払うなど、許可ガイドの一部を交渉可能にするために他のポリシーを実施することができる。一例では、ホスティングは特定のコストで共有されてもよく、このオファーは、ハードウェアへの制限されたアクセスがより高いコストで利用可能であり得る別のオファーと対照的であり得る。一例では、特定のフローティングサービスは、フローティングサービスが異なるサービス品質に対して支払うことを認可され得る範囲を有し得る。ハードウェアの制限された使用が許容可能な支払い範囲内に収まるという検出に応答して、フローティングサービスはハードウェアへの制限されたアクセスに対する申し出を受け入れることを選択することができる。代わりに、フローティングサービスは、制限されたハードウェア構成を好ましいものとしてタグ付けしないことがあり、このタグに応答して、フローティングサービスは、フローティングサービス最小閾値を満たす市場におけるオプションにデフォルト設定することができる。
ブロック17104からのフローティングサービスのディスパッチに応答して、プリアンブルが提供され得る。上述のように、プリアンブルは、許可ガイドが実行を開始するために使用され得る情報の交換を含み得る。プリアンブルは、ウォレット識別子、識別情報、アクセス情報、サービスとハードウェアとの鍵交換、ホストの位置、ホストのIPアドレス、またはフローティングサービスが利用可能な位置を含むことができる。プリアンブルが失敗したという検出に応答して、ブロック17102の一部として、プロセスをホストの検討および選択から再開して、別のホストを選択することができる。プリアンブル失敗の検出に応答して、通知がフローティングサービスオーナーに送信され得る。通知は、フローティングサービスのオーナーがハードウェア、ソフトウェア、条項および条件、またはサービス品質のレベルを下げて、市場における対応するホストの供給に基づいてフローティングサービスの選択肢を広げることができるか否かに関する入力の要求を含むことができる。
ブロック17106において、許可ガイドは実行を開始することができる。一例では、許可ガイドの実行は、プリアンブル段階の完了に応答して開始することができる。許可ガイドの実行開始に応答して、実行条件が測定され得る。許可ガイドの実行中、許可ガイドのイベントまたは条件が満たされると、支払いがロック解除され得る。許可ガイドに参加し合意した当事者が許可ガイドを脱退することができる一方で、許可ガイドを脱退する当事者は、その当事者に関連するウォレットに課されるペナルティを被る可能性がある。一例では、許可ガイドは、フローティングサービスの性質に少なくとも部分的に基づいていてもよく、許可ガイドの概念に基づいていてもよい。
一例では、許可ガイドの請求期間は必要に応じて短くすることができ、場合により、数秒または数マイクロ秒である。一例では、許可ガイドの実行中に、ホストまたはピアがQoS条件を満たす場合、プロセスが進行し、他の条件がアクセスされ得る。QoS条件が不十分なものとしてランク付けされているという検出に応答して、許可ガイドは終了されてもよく、または違反しているホストにペナルティが適用されてもよい。一例では、許可ガイドの終了は、AIによって管理される実装に基づいて自動的に許可ガイドによって行われる決定であり得る。許可ガイドの終了は、一例では、サービスプロバイダとサービスコンシューマとの両方の裁量で手動で行われる決定であり得る。
ブロック17106で実行される許可ガイドに応答して、許可ガイドの条項および条件がトリガ閾値に達したときに支払いに達することができる。評価される支払いおよびペナルティは、支払いが複数の当事者、ピア、およびホストの間で転送または相殺され得るように多方向であり得る。上記のように、当事者が終了されるかまたは脱退する場合、許可ガイドは終了され得る。
ブロック17108において、最終支払いが交換され得る。一例では、許可ガイドが本来の終了に達したことに応答して、その後プロセスは終了またはリセットされ得る。一例では、本来の終了は、TTLの満了を指し得る。フローティングサービスのTTLが期限切れではないという検出に応答して、フローティングサービスは別のホストを発見する新しいサイクルを開始することができる。
図172は、一部の実施形態による、フローティングサービスを管理するためにIoTデバイス17200に存在し得るコンポーネントの一例のブロック図である。同様の番号が付けられた項目は、図8において説明したとおりである。
上でも示したように、図8を参照すると、大容量ストレージ808は、本明細書で説明されるグループ作成機能を実施するための複数のモジュールを含むことができる。大容量ストレージ808においてコードブロックとして示されているが、モジュールのうちのいずれも、例えば特定用途向け集積回路(ASIC)に組み込まれるなど、ハードワイヤード回路で完全にまたは部分的に置き換えられ得ることが理解されよう。大容量ストレージ808は、フローティングサービス許可ガイドドラフト部17202を含み得る。一例では、フローティングサービス許可ガイドドラフト部17202は、フローティングサービスのタスクを実行するために、発見された複数のホストについてのフローティングサービス許可ガイドをドラフティングすることができ、発見された複数のホストは、フローティングサービスの許可ガイドで指定されたパラメータのホストフルフィルメントに関して評価され得る。
一例では、フローティングサービス許可ガイドは、サービス許可ガイドの検出された違反に応答してホストに対して評価されるべきペナルティを示してもよく、ペナルティはホストウォレットから収集される。
大容量ストレージ808は、ホストハードウェア選択部17204を含み得る。一例では、ホストハードウェア選択部17204は、フローティングサービスのデータ構造に基づいて、フローティングサービスのためのホストハードウェアを選択することができる。
一例では、データ構造は決定行列である。決定行列は、フローティングサービスによって求められた特徴、利用可能なホストの数、および決定行列に列挙された特徴に対するホストの評価スコアを列挙してもよい。フローティングサービスは、1時間当たりのコストを、フローティングサービスの満足のいく使用を示す品質メトリクスを有する複数の特徴で除算して計算された最良値に基づいてホストを選択することができ、1時間当たりのコストは、評価対象のホストを使用したフローティングサービスを運用する、1時間当たりの予想コストである。フローティングサービスの機能は、決定行列を用いた価値計算において特徴を様々に重み付けすることができる。
大容量ストレージ808は、IoTデバイス17200のためのフローティング許可ガイドを実施するためのフローティングサービス許可ガイド実行部17206を含み得る。一例では、フローティングサービス許可ガイドはホストハードウェアを使用することができる。
大容量ストレージ808は、価値転送部17208を含み得る。一例では、価値転送部17208は、フローティング許可ガイドの条件に達したという検出に応答して、フローティングサービスに関連付けられたサービスウォレットに価値を転送し得る。一例では、サービスウォレットはブロックチェーン符号化値を保持することができる。サービスウォレットの値が0になると、フローティングサービスは機能しなくなり得る。一例では、許可ガイドは、サービスウォレットがトリガ閾値に到達したという検出に応答して、サービスウォレットが価値を転送し得ることを示し得る。フローティングサービスは、サービスウォレットとホストウォレットとの間で価値トランザクションを開始することができる。
図173は、一部の実施形態による、フローティングサービスを管理するためのコードを含む、非一時的機械可読媒体17300のブロック図である。同様の番号が付けられた項目は、図9において説明したとおりである。
非一時的機械可読媒体17300は、発見された複数のホストに関するフローティングサービス許可ガイドをドラフティングするためのコード17302を含むことができ、発見された複数のホストがパラメータのホストフルフィルメントについて評価され得る。一例では、フローティングサービス許可ガイドは、サービス許可ガイドの検出された違反に応答してホストに対して評価されるべきペナルティを示してもよく、ペナルティはホストウォレットから収集される。
非一時的機械可読媒体17300は、フローティングサービスのデータ構造に基づいて、フローティングサービスのためのホストハードウェアを選択するためのコード17304を含み得る。一例では、データ構造は決定行列である。決定行列は、例えば、フローティングサービスによって求められた特徴、利用可能なホストの数、および決定行列に列挙された特徴に対するホストの評価スコアを列挙してもよい。フローティングサービスは、1時間当たりのコストを、フローティングサービスの満足のいく使用を示す品質メトリクスを有する複数の特徴で除算して計算された最良値に基づいてホストを選択することができ、1時間当たりのコストは、評価対象のホストを使用したフローティングサービスを運用する、1時間当たりの予想コストである。フローティングサービスの機能は、決定行列を用いた価値計算において特徴を様々に重み付けすることができる。
非一時的機械可読媒体17300は、ホストハードウェアを使用してフローティングサービス許可ガイドを実行するためのコード17306を含み得る。非一時的機械可読媒体17300は、フローティング許可ガイドの条件に達したという検出に応答して、フローティングサービスに関連付けられたサービスウォレットに価値を転送するためのコード17308を含み得る。一例では、サービスウォレットはブロックチェーン符号化値を保持することができる。サービスウォレットの値が0になると、フローティングサービスは機能しなくなり得る。一例では、許可ガイドは、サービスウォレットがトリガ閾値に到達したという検出に応答して、サービスウォレットが価値を転送し得ることを示し得る。フローティングサービスは、サービスウォレットとホストウォレットとの間で価値トランザクションを開始することができる。
許可ガイドは、サービス提供コストならびにホストまたはサービスの評判履歴のランタイム計算を組み込んでもよい。コストとは、エネルギーコスト、機器の資本コスト、減価償却費、ポイントインタイムキャパシティコスト、データのプライバシーコスト、データのエントロピーコストを指すことができる。本明細書に開示されるように、許可ガイド交渉プロセスは時間ベースであり得る。タスクが割り当てられていて実行中であっても、許可ガイドは、プロバイダを切り替えることが可能であり得る。一例では、プロバイダ間の切り替えは、サービスのコンシューマまたはプロバイダに影響を与え得る条件の変化に応じて行われ得る。
図174は、一部の実施形態による、例示的な許可ガイド交渉プロセス17400を示す概略図である。同様の番号が付けられた項目は、図165において説明したとおりである。
一例では、許可ガイドについての交渉は、存在しなくてもよいし、テンプレート許可ガイドであってもよい。テンプレート許可ガイドは、記憶媒体上に散らばった一連の許可として、あるいは許可ガイドを採用することに同意する当事者の許可、権利、および義務を示す単一の文書として格納された施行可能な合意の不完全なバージョンであり得る。テンプレート許可ガイドは、関係する当事者が変更を読んでコミットすることを可能にし得る。
許可ガイド交渉プロセス17400は、ピアの発見および許可ガイドの最初のドラフティングに応答して開始することができる。一例では、初期許可ガイドは、サービスによって要求された、または1人または複数のデータコンシューマによって要求されたQoS T&Cで埋められてもよい。
許可ガイド交渉プロセス17400は、ピア、ホスト、および他のサービスから参加することへの関心の指示を受信することができる。従って、許可ガイドによって設定された許可に参加し遵守することを望む候補サービスプロバイダまたはコンシューマは、参加を申請することによって参加のプロセスを開始することができる(17402)。参加を申し込む候補サービスプロバイダまたはコンシューマは、それぞれプロバイダ属性またはコンシューマ属性に関する情報を提供することができる。プロバイダ属性およびコンシューマ属性は、アサートされているとおりにデバイスの能力または機能を指すことができる、またはこれらの能力および機能をデバイス属性リスト16524に含めることを進める前に、能力および機能を確認することができる。
提供機能、要求機能、または割り当て機能17404を使用して、サービスプロバイダ、データプロバイダ、およびコンシューマの利用可能なセットを識別することができる。属性および機能が許可ガイドの条件を満たすことができるように属性と機能とが重複している場合、サービスプロバイダ、データプロバイダ、およびコンシューマのセットは利用可能になり得る。許可ガイドの条件を満たすことは、例えば、当事者の要求の完全なセットを満たすことを指すこともできる。許可ガイドの条件を満たすことは、例えば、実行可能な限り多くの当事者の要求を満たすことを指すこともできる。
一例では、オファーは、候補サービスコンシューマによって最高ランクのサービスプロバイダまたはデータプロバイダになされ得る。オファーを受信したプロバイダは、そのオファーの受け入れを確認するための要求を送信し得る。オファーを受信したことに応答して、受け入れられたプロバイダは、許可ガイドの許可に拘束され、確認済みデバイスのリスト17406の一部になることができる。参加プロセス中に、交渉が行われてもよい。交渉中に、候補者は、サービスまたはデータにアクセスする方法に合意することができる。重複する技術セットを合意できない場合は、第三者の許可ブローカなどのプロトコルおよびデータスキーマブローカを仲介者として許可ガイドに参加するよう依頼することができる。
確認されたプロバイダおよびコンシューマは、場合により、許可ガイドからオプトアウトすることができる。オプトアウトしてもコストがかからない場合もあれば、ペナルティが課される場合もある。一例では、デバイスがその義務を果たさず、代替デバイスを識別できない場合、ペナルティがアクセスされる場合がある。
許可ガイドの実行中(16510)に、他のプロバイダおよびコンシューマが参加を申し込むことができ、参加することができる。許可ガイドが実行されると(16510)、プロバイダとコンシューマは置き換えられる場合もある。
図175は、一部の実施形態による、許可ガイド交渉のための例示的な方法17500のプロセスフロー図である。図175の方法17500は、図177に関して説明されるIoTデバイス17700によって実施することができる。同様の番号が付けられた項目は、図166に関して説明したとおりである。プロセスフローは、ブロック16602で開始し得る。ブロック17502において、ノードは参加を申し込むことができる。ノードは、プロバイダ、コントリビュータ、ならびに許可ガイドによって管理されることを望み得る他のデバイスおよびサービスを含むことができる。
ブロック17504において、ノードは、それらの提供物、属性、およびノードが有し得る任意の条項および条件をリストし得る。ノード適用プロセス中に、コスト関数がノードから受信された入力に適用され得る。一例では、コスト関数は、以下に開示されるようにinfocoinアルゴリズムであり得る。一例では、コスト評価は、現場でのIoTデバイスのデプロイおよびプロビジョニングのコストを含むことがあるので、コスト関数は、IoT市場のノードに適用することができる。コスト評価は、例えば、運用コストは、例えば、デバイス、データ転送、およびストレージデバイスを運用するためのエネルギー、稼働、および保守のコストを含む。コスト評価には、広範なインフラストラクチャ全体にデプロイされているこれらのデバイスのコストに営業利益率のコストを加えたものが含まれ得る。一例では、マージンは、様々な当事者によるより低い範囲およびより高い範囲の使用を通じて交渉が行われ得る領域を指すことができる。
ブロック17506において、データプレーンが更新され得る。データプレーンは、ブロックチェーン上またはブロックチェーン外のメカニズムを表すことができる。上述したように、ブロックチェーン内で使用され参照されるデータは、分散ハッシュテーブル(DHT)との統合を通じて実行され得る。
ブロック17508において、承認されるデバイスを追加することができる。一例では、確認されたデバイスは、デバイス基準によって、パラメータ選択を通じて、またはコスト関数に基づいて識別され得る。例えば、指定された基準を満たすデバイスはデフォルトで受け入れられ得る。特定の適合性パラメータを持つデバイスが受け入れられる場合もある。コスト関数の出力を満たすデバイスが受け入れられる場合もある。コスト関数は、供給単位当たりのコストに関して、ノードを順序付けし、上位N個の最適なノードを受け入れることを優先することができる。本明細書で説明される他の方法と同様に、プリアンブルをプロトコルフレームで使用することができる。プリアンブルは、トークンが許可ガイドとその参加メンバとの間で交渉される前に、プロセスが続行できるようにするために必要なデータを参加者が交渉できるようにし得る。正しいトークンを所有している当事者は、その後、特定のサービスにアクセスしたり提供したりするのに信頼される場合もある。
上述のように、許可ガイドからのノード交渉は、infocoinアルゴリズムなどのコスト関数を使用することができる。infocoinアルゴリズムは、センサが事前定義されたレートでデータを継続的に送信することを仮定し得る。infocoinアルゴリズムは、センサの寿命および保守スケジュールが予測可能であると仮定し得る。infocoinアルゴリズムは、データの帯域外要求は許可されていないと仮定し得る。infocoinアルゴリズムは、センサ、ゲートウェイ、およびサーバが、例えば電力制約、処理制約、通信制約、またはストレージ制約などのより少ないリソース制約を有すると仮定し得る。
以下の式で使用されているように、Dはデータの単位を表す。このデータ単位は、主要なデータであり得る。一例では、一次データは、IoTネットワーク内のセンサによって直接観測された測定値であり得る。一次データは、1つまたは複数の一次データ源からの入力に基づいて計算された派生データを指すことができる。
以下の式で使用されているように、Ctはデータ単位を転送するコストを表す。一例では、データ単位はinfocoinと呼ばれ得る。データ単位を転送するコストは、ネットワーク転送コストまたは転送されるデータのサイズによって異なり得る。データ単位を転送するコストは、データがネットワークを介して新しいストレージ位置にコピーされているか否か、またはデータホームへのURIが使用されているか否かによって異なり得る。一例では、データホームは、惑星間ファイルシステム(IPFS)または軽量フォグファイルシステムであり得る。以下の式で使用されているように、Cstoreはデータ単位を格納するためのコストを表し、ストレージのコストはデータのサイズの関数であり得る。データを格納するコストは、データの複製が冗長性のために使用される場合、特定の記憶媒体のコストを指し得る。
以下の式で使用されているように、項Marginは、データによって提供される値を反映し得る。一例では、データが他のデータ源と組み合わされてもよいため、データの価値は増大する。以下の式で使用されているように、Crawは取得コストまたは一次データ単位を生成するコストに営業利益率を加えたものを指すことができる。データ単位を取得するコストまたはデータ単位を生成するコストは、両方とも、センサの固定コスト(CS)を含むことができ、センサの寿命にわたる維持コスト(Cm)を含むことができ、センサノードのエネルギーランニングコスト(Ce)を含み得る。一例では、データ単位を取得するコストまたはデータ単位を生成するコストは、両方とも、センサが使用されることになる1日当たりのサンプリングレート(rate)および日数(t)を考慮することができる。Crawは、許可ガイドにサブスクライブしている当事者にとって交渉済みの価値を示すものとして、許可ガイドによって使用され得る。
Craw=[CS+(Ce*t)+Cm]/[rate*t]*Margindata・Cderived
別の例では、派生データまたは仮想データを取得するコストは、新しい洞察および価値を得るために1セットまたは複数セットの一次データを処理または分析することによって生み出すことができる。本明細書で使用されるように、少なくとも3つの種類の導出データがあり得る。1つの種類の導出データは、センサノード内で導出されたデータを含み得。別の種類の導出データは、ネットワーク内で導出されたデータを含み得る。さらなる種類の導出データは、履歴データから導出されたデータを含み得る。
一例では、生コストは、データ源の数に基づいて変動し得る。例えば、導出されたデータが同じセンサノード上の複数の入力から計算され得る場合、データを取得するコストは生データを取得するのと同じまたは類似している。ノード上のすべてのセンサが使用されているか否かにかかわらず、センサノードの固定コストとランニングコストとは同じになり得る。従って、一例では、同じノード上で導出された値を計算するための追加コストがない場合がある。例えば、温度および湿度の入力から快適性指数の導出値を計算することは、同じノードからのデータを含むことができ、従って、データの転送のための生コストは増加しない可能性がある。
導出されたデータは生データよりも多くの値を提供する可能性があり、以下の式に示すように、計算された「導出値に対するMargin」が存在し得る。
Cderived_local=Craw*Margininformation
データは、様々な情報源から導出され得る。一例では、データは、ゲートウェイ、サーバ、機器、中央処理装置、または他のデバイスで導出することができる。生データが導出されたデータの作成のためにある位置に転送されることになっているとき、データを転送するコストのコスト計算にコストが追加され得る。一例では、データを転送するコストは、ノードからゲートウェイまたはサーバへ移動するデータのコストならびにその場所にデータを格納するコストに関係し得る。一例では、生データ単位は、最終データ宛先に到達するために複数の転送ステージを有し得る。転送中、データ単位は、最終データ宛先への移動の間の中間段階または中間ステージでローカルに格納され得る。コストは、生データの最終目的地に到達するためのコストに「導出された値に対するMargin」を加えた和として生成され得る。以下の式では、Cderived_remoteによって参照されるデータを生成するためにデータが最終宛先までの途中のポイントで導出される場合、変数CrawをCderived_localで置き換えることができる。
データが履歴データから導出される場合、データを格納するコストは、データを生成するコストに追加され得る。追加のデータ源が追加されるにつれてデータの価値が増加するため、コストはこのデータの生成に使用された履歴サンプルの数に実質的に比例する可能性がある。
以下の例示的な式では、Cacqは、データDを取得するために計算され得るコストを表す。データは、金銭的な価値(例えば、米国ドル)を持つことができる。データはまた、他のネイティブ資産またはオーバーレイ資産の観点から価値を表すこともある。CacqのコストはCraw、Cderived_local、またはCderived_remoteと等しくてもよい。以下の例示的な式では、Divはデータユニットの情報値を表すことができる。すべてのデータ単位が等しい値を持つとは限らないため、Divはデータ単位ごとに異なり得る。
単位データの値、または一般にデータを識別するために、証拠の重み付けモデルは、データが作成された時点でデータ値を分類するために使用される情報値スコアを知らせることができる。情報値(IV)は、予測モデルにおける変数を選択するために使用され得る。一例では、予測子としてのIV統計は、IV統計が閾値を下回る場合、モデル化には有用ではない可能性がある。計算されたIVについて閾値を使用し変化させることは、データ単位またはinfocoinに対する値を評価するために使用され得る。閾値を下回るIVを持つデータ単位は、より低い値を受け取る。閾値を上回るが第2の閾値を下回るIVを有するデータ単位は、割り当てられた中間値を有することができる。価値スコアのこの評価は、複数のIV閾値がIVデータスコアの入力によって超えられるにつれて増加し得る。一例では、データがIoTエコシステムにおいてコンシューマによってより強く求められているので、高価値データはより大きな金銭的価値を有することができる。一例では、求められるデータ単位が多いほど、そのデータ単位の価値が高くなる。
データ単位の値を格納し評価する追加の方法を交渉システムに代用することができる。データ単位にIVスコアを使用することは、情報自体が交渉の枠組み内で取引可能な資産として使用されることを可能にする、またはそれ以外の方法でデータにスコアを配置することであり得る。
図176は、一部の実施形態による、価値を評価してデータ単位に割り当てるための例示的データ構造17600の概略図である。示されているデータは単なる例示であり、データ単位の値を計算すると共に最も価値のあるデータを選択する方法の例として示されている。さらに、価値を割り当てることができるデータは、許可ガイドの交渉ポイントまたは支払い方法として使用することができる。例示的なデータ構造17600では、証拠の重み付け(WoE)計算17602の列が、特定のノードにおいてデータが収集されたイベントの割合に基づくものとして示されている。
例示的なデータ構造17600では、ビンの列は、特定のデータ種別について少なくとも5%の観測値を有するノードの識別情報であり得る。一例では、各ノードおよび各データ種別について複数のそのような値計算モデルがあり得る。例示的なデータ構造17600では、ビン7は、高い予測値を有し得るデータとして現れる。データ構造例17600では、データセットの全体のDivは0.3138の値として表示される。相対的に、ビン7からのデータは、データ市場でより高い値を指示する場合もある。示された例におけるCacqは、ビンおよびノードにわたって平坦な値として現れ得る。しかしながら、市場の力がCacqの値を変える可能性がある。情報単位のための市場を創設することは、データ供給者が彼らの投資のために利益をもたらすであろう種類のデータを供給することを奨励するかもしれない。
図177は、一部の実施形態による、評価されたデータユニットとの交渉のためのIoTデバイス17700に存在し得るコンポーネントの一例のブロック図である。同様の番号が付けられた項目は、図8において説明したとおりである。
上でも示したように、図8を参照すると、大容量ストレージ808は、本明細書で説明されるグループ作成機能を実施するための複数のモジュールを含むことができる。大容量ストレージ808においてコードブロックとして示されているが、モジュールのうちのいずれも、例えば特定用途向け集積回路(ASIC)に組み込まれるなど、ハードワイヤード回路で完全にまたは部分的に置き換えられ得ることが理解されよう。大容量ストレージ808は、第1のパラメータおよび第1のパラメータ値を含む第1の発見されたピア、ならびに第2のパラメータおよび第2のパラメータ値を含む第2の発見されたピアに関する許可ガイドをドラフティングする許可ガイドドラフト17702を含み得る。一例では、第1のパラメータおよび第2のパラメータは、それぞれ第1および第2のノードについての許容可能なデータ値範囲を指すことができる。許容可能なデータ値範囲は、コスト関数を用いて計算することができる。コスト関数は、許可ガイドを実施するノードの運用コストを計算して組み合わせることができる。運用コストは、例えば、デバイス、データ転送、およびストレージデバイスを運用するためのエネルギー、稼働、および保守のコストのうちの少なくとも1つを含む。一例では、データ値範囲は、複数のデータソースの関数としてのデータの値の計算を指すことができる。データは、複数のセンサから合成された導出データであり得る。データの値は、得ようとするデータのレートが増加するにつれて増加し得る。
大容量ストレージ808は、例えば、図176に関してイベントの重みの欄について説明したように、第1のパラメータ値と第2のパラメータ値とを比較することによって第1のパラメータ重みおよび第2のパラメータ重みを計算するパラメータ重み計算部17704を含み得る。大容量ストレージ808は、提案された条件が第1のパラメータおよび第2のパラメータによって提案された範囲内にあることに応じて許可ガイドの条件を生成する条件生成部17706を含み得、第1パラメータは第1パラメータの重みによって調整され、第2パラメータは第2パラメータの重みによって調整される。大容量ストレージ808は、条件が満たされたことを検出したことに応答して許可ガイドの動作を実行するための動作実行部17706を含み得る。
一例では、プロセッサ802は、参加パラメータおよび参加パラメータ値を含む候補ピアから許可ガイドへの要求を処理することができる。一例では、プロセッサ802は、第1のパラメータ値および第2のパラメータ値を、参加パラメータ値に対して比較することによって参加パラメータウェイトを計算することができる。
図178は、一部の実施形態による、タスクおよびコミッションノードを定義するためのコードを含む、非一時的機械可読媒体17800のブロック図である。同様の番号が付けられた項目は、図9において説明したとおりである。
非一時的機械可読媒体17800は、第1のパラメータおよび第1のパラメータ値を含む第1の発見されたピア、ならびに第2のパラメータおよび第2のパラメータ値を含む第2の発見されたピアに関する許可ガイドをドラフティングするようにプロセッサ902に指示するためのコード17802を含み得る。一例では、第1のパラメータおよび第2のパラメータは、それぞれ第1および第2のノードについての許容可能なデータ値範囲を指すことができる。許容可能なデータ値範囲は、コスト関数を用いて計算することができる。コスト関数は、許可ガイドを実施するノードの運用コストを計算して組み合わせることができる。運用コストは、デバイス、データ転送、およびストレージデバイスを運用するためのエネルギー、稼働、および保守のコストのうちの少なくとも1つを含む。一例では、データ値範囲は、複数のデータソースの関数としてのデータの値の計算を指すことができる。データは、例えば、複数のセンサから合成された導出データであり得る。データの値は、得ようとするデータのレートが増加するにつれて増加し得る。
非一時的機械可読媒体17800は、第1のパラメータ値と第2のパラメータ値とを比較することによって第1のパラメータ重みおよび第2のパラメータ重みを計算するようにプロセッサ902に指示するためのコード17804を含み得る。非一時的機械可読媒体17800は、提案された条件が第1のパラメータおよび第2のパラメータによって提案された範囲内にあることに応じて許可ガイドの条件を生成するようにプロセッサ902に指示するためのコード17806を含み得、第1パラメータは第1パラメータの重みによって調整され、第2パラメータは第2パラメータの重みによって調整される。非一時的機械可読媒体17800は、条件が満たされたことを検出したことに応答して許可ガイドの動作を実行するようにプロセッサ902に指示するためのコード17808を含み得る。
一例では、プロセッサ902は、参加パラメータおよび参加パラメータ値を含む候補ピアから許可ガイドへの要求を処理することができる。一例では、プロセッサ902は、第1のパラメータ値および第2のパラメータ値を、参加パラメータ値に対して比較することによって参加パラメータウェイトを計算することができる。
IoTネットワーク上のメッセージフローは、時間の経過と共に認識可能なパターンを確立することができるが、認可されていないエージェントがネットワークにアクセスすると、認可されていないエージェントは自らの目的で動作を変更可能であり得る。そのため、トランザクションがブロックチェーンで可視である場合は、ネットワーク上のそのような不正行為を検出して解決するため、または事実上不正なトランザクションが発生しないようにするための措置をとることさえ可能であり得る。
一例では、ブロックチェーンを使用して、ネットワーク上のトランザクションの記録、ならびにネットワークエージェントが動作を実行するための事前認可を保持することができる。この事前認可機能は、非集中型ネットワークアクセスプロキシ(DNAP)プロトコルと呼ばれることがある。
図179は、一部の実施形態による、機能を使用するための非集中型ネットワークアクセスプロキシのための例示的な組織17900の概略図である。同様の番号が付けられた項目は、図165を参照して開示されたとおりである。DNPAプロトコルの機能および許可ガイド17902とのその相互作用のためのプロセスは、17904で開始することができる。
ブロック17904において、デバイスがブートし得る。ブートプロセスは、実行前環境(PXE)におけるネットワークインターフェースデバイス上のネットワークスタックの初期化であり得、上位レベルのソフトウェアスタックまたはオペレーティングシステムの存在を意味し得ない。
ブロック17906において、ネットワークインターフェースアダプタは、ブロックチェーンアウェアデバイスとして動作する際に使用するための鍵を生成することができる。生成された鍵を使用するデバイスはまた、ハードウェア対応のセキュアなエンクレーブを使用しているか、またはそれから動作していてもよい。生成された鍵を使用して、各パケットのトラフィックの発信元と各パケットの内容を判定できるように、デバイスから送信されるトラフィックに署名することができる。一例では、このデバイスのための鍵ベースの暗号化は、デバイス上でハードウェア対応にすることができ、中間者攻撃を防ぐのを助けることができる。トラフィックが有効なエージェントからの秘密鍵で署名されていない場合、ネットワークはデバイスに到着するトラフィックをドロップすることができる。一例では、ネットワークスイッチおよびルータを使用するために、トラフィックのハードウェア暗号化および復号が行われ得るように、ネットワークスイッチに修正を加えることができる。
ブロック17908において、ネットワークインターフェースアダプタは、ブロックチェーン上にアクセス要求トランザクションを作成することができる。一例では、ネットワーク上を走っているパケットは、強制的にDNAPに経路指定され得る。これに関連して、DNAPは、ネットワークの物理スイッチおよびルータ上のサービスとして動作している可能性があるため、レイヤ2データリンク層の機能とみなすことができる。ネットワークデバイスがコアネットワークインフラストラクチャを使用しようとすると、ネットワークデバイスは、コアネットワークインフラストラクチャまたは専用媒体を介したピアツーピア接続のプライベートネットワーク以外の接続を使用しようとする場合に、ネットワークデバイストラフィックが非集中型ネットワークアクセスプロキシに経路指定されるのを避けることができない。一例では、専用媒体を介したピアツーピア接続は、Bluetooth(登録商標)またはイーサネット(登録商標)クロスケーブルを介した通信を含み得る。
ブロック17910において、DNAPプロトコルは、デバイスに特定のネットワークアクセス機能を許可し得る。一例では、DNAPプロトコルは、許可ガイドの前述の機能を利用することができる。DNAPプロトコルを実行しているネットワーク上のスイッチおよびルータのようなノードは、ブロックチェーンのマイナーになる場合もある。一例では、ネットワークのノードは、大きな計算オーバーヘッドを使用しないコンセンサスアルゴリズムを実行することができる、またはトランザクションへの直接参加に基づき得る。経過時間の証明アルゴリズムは、このプロトコルで使用される技術の一例であり得る。悪意のあるアクターが、例えば攻撃を成功させるためには、ネットワークインフラストラクチャの51%をデプロイまたは危殆化させる必要があるため、DNAPプロトコルを使用することで、不正なスイッチやルータの導入から保護することもできる。DNAPデバイスがアクセス要求トランザクション機能を使用しようとすると、許可ガイドのメカニズムを介してネットワークインターフェースアダプタがそれ自身をネットワークに対して識別することになり得る。ネットワークインターフェースアダプタは、このプロセスを支援するためにハードウェア対応のセキュアなエンクレーブを実行することができる。
ブロック17912において、DNAP使用デバイスが許可ガイド内の参加機能によって承認された場合、DNAP使用デバイスをネットワーク上の作成された、または認可されたデバイスの許可ガイドリストに追加することができる。ブロック17910において、初期化プロセスが行われてもよく、デバイスはその属性および機能を許可ガイドに記述してもよい。一例では、DNAP記述属性は、信頼レベルを確立するためにDNAPデバイス上のハードウェア対応セキュアエンクレーブを介してアテステーションされてもよい。一例では、DNAPデバイスの属性の記述は、ヒューマンインターフェースデバイス(HID)への拡張において定義されてもよい。許可ガイドに格納されている属性またはデータの記述は、チェーン外に格納され得る。一例では、DNAPプロトコルを用いてイネーブルにされたスイッチまたはルータ、データのチェーン外への格納は、スイッチ内の一部のストレージの統合を含み得る。DNAPネットワーク内のスイッチおよびルータは、エッジノードまたはフォグノードであり得る。ストレージは、ネットワーク上のルータおよびスイッチの上でDHTタイプの分散ストレージメカニズムになることがある。
ブロック17914において、トークンがデバイスに発行されて、デバイスが調整された方法で動作を実行できるようにすることができる。トークンをデバイスに使用すると、DNAPネットワーク上のエンティティに対して個々のデバイスのファイアウォールが可能になり得る。一例では、デバイスがインターネット制御メッセージプロトコル(IMCP)トークンを保持している場合、デバイスはpingトラフィックを送信および受信することができる。トークンの使用は、同じトークンを有するデバイスがルータを介さずに互いに通信することを可能にすることによって仮想ローカルエリアネットワーク(VLAN)の形成を可能にし得る。トークンはまた、大規模な企業ネットワークに接続されていないプライベートネットワークを作成するためにも使用できる。
トークン割り当ては、特定の基準を満たすデバイスにデフォルトのトークン種別を割り当てるための規則を有し得る。これらの規則は、デバイスの種類や、そのデバイスが最低限のセキュリティ基準に準拠しているか否かを管理し得る。一例では、デバイスの種類は、企業が所有およびサポートするデバイス、または従業員が「持ち込み」スタイルプランで所有するデバイスであり得る。個人的なデバイスから金融データベースにアクセスする個人などの一部の環境では、本明細書で説明されているトークン割り当ては、企業環境の外で適用され得る。一例では、認可されていない、または特定の動作のためのトークンを所有していないDNAPデバイスは、デバイスがネットワークによって認可されていないために機能を要求したデバイスに障害が発生したという通知を受信し得る。トークンベースの承認手法を使用すると、ネットワーク上のセキュリティの施行を非集中化させることができる。一例では、ネットワーク管理者は、ネットワーク管理者がネットワーク上で許可または拒否する動作を表すために手動でトークンを作成することができる。一例では、事前に入力されたトークンのセットがネットワーク機器製造業者によって提供され得る。
ブロック17916において、DNAPデバイスは、特定の機能を実行するようにネットワーク上で認可され得る。DNAPデバイスは、追加のトークンが付与され得る、またはトークンが失効され得る。この動作の制御プレーンは、ブロックチェーンで支援されている場合がある。ブロックチェーン支援は、デバイスがトークンを発行した後にデバイスが接続されているポートまたはアクセスポイントに施行されている規則を指すことができ、接続されたデバイスのために提供された規則は一般に変化せず、規則はデバイスの確認されたアイデンティティに基づいて施行される。一例では、ネットワーク内のスイッチおよびルータは、マイナーであり得、トランザクションを共通の共有台帳に同期させ得る。
ブロック17918において、デバイスが実行しようと試み得る機能がブロックされてもよく、デバイスはネットワークが通信をブロックしたことを示すメッセージを受信してもよい。
図180は、一部の実施形態による、機能を使用するための非集中型ネットワークアクセスプロキシのための例示的な方法18000のプロセスフロー図である。図180の方法18000は、図181に関して説明されるIoTデバイス18100によって実施することができる。プロセスフローは、ブロック18002で開始し得る。
ブロック18002において、ネットワークデバイスが初期化され得る。一例では、ネットワークデバイスは、クライアント、サーバ、ネットワークインフラストラクチャ、またはネットワークインターフェースとすることができる。ブロック18004において、デバイス上のファームウェアおよびハードウェアは、アイデンティティを生成し、デバイスがブロックチェーンクライアントの能力で動作できるようにする。一例では、ノードはネットワークスイッチの役割またはルータの役割を持つことができ、デバイスはDNAPブロックチェーンの確認部の容量で動作することができる。DNAPブロックチェーンは、すべてのネットワークインフラストラクチャノードに分散させることができる。
ブロック18006において、デバイスは、ブート前実行環境(PXE)または動的ホスト構成プロトコル(DHCP)と同様に、発見ブロードキャストメッセージをパブリッシュすることができる。一例では、デバイスおよびDNAPプロトコルは、PXEおよびDHCPプロトコルを使用して実施することができる。一例では、発見ブロードキャストがDNAPアウェアシステムの位置を返さない場合、ネットワークデバイスは遅延し再試行し得る。発見ブロードキャストがいかなるDNAPアウェアシステムの位置も返さない場合、デバイスは、デバイスが非DNAPネットワーク上で動作することを可能にするレガシー動作を実行し得る。遅延および再試行のプロセス、または別のネットワークへの切り替えのプロセスは、事前設定されたポリシー、BIOS設定、ファームウェア設定、デバイス上の物理ジャンパ設定、またはその他の方法で手動で調整することによって制御できる。
ブロック18008において、DNAPデバイスは、動作中のDNAPネットワークの発見に応答してDNAPネットワークに参加することを申し込む。上述のように、DNAPネットワークに参加することは、ネットワーク内で従われる許可ガイドに参加することを含み得る。
ブロック18010において、DNAPデバイスは、その属性および機能をパブリッシュし、デバイスの属性またはアイデンティティに基づいてDNAPデバイスに割り当てられ得るトークンを要求し得る。トークンを割り当てる決定は、ポリシーの使用を通じて、または例えばデバイスのネットワーク、アドレス、アイデンティティ、デバイス種別、デバイス能力、デバイス機能に基づいて、またはデバイスおよび許可ガイドに関するポリシーの有効性尺度に基づいてネットワーク管理者によって制御され得る。上述のように、許可ガイドを構築することは、ユーザインターフェースまたはアプリケーションプログラムインターフェースを使用し得るネットワークエンジニアによって達成され得る。許可ガイドおよびトークンの実装は、デバイスごとのネットワークトラフィックの詳細な制御を可能にし得る。一例では、企業システムは、ハイパーテキスト転送プロトコル(HTTP)トラフィックまたは他の特定の種類のトラフィックをデバイスのデフォルトとすることを可能にし得る。DNAPプロトコルを使用する企業システムはまた、指定されたビジネス機能追加トークンをデバイスに提供して、それらのデバイスが他のネットワークサービスを使用したい場合に他のトラフィック種別を許可することができる。
ブロック18012において、デバイスは、ネットワーク上にパケットを送信することができる。オペレーティングシステムおよびOSI(開放型システム間相互接続(Open System Interconnection))スタックの上位層は、このプロセスを認識していない場合がある。一例では、デバイスパケットの送信はネットワーク層で実行され得る。ネットワークは、いくつかの方法でパケットを認証できる。例えば、トークンは、パケットのヘッダに付加されてもよいし、パケットは、パケットを送信しているアイデンティティの秘密鍵で署名されてもよい。ネットワークに到着したパケットは、それらを送信しているアイデンティティが検証され、その種類のトラフィックを送信するためのトークンを所有している場合に許可され得る。トラフィックが許可されていない場合、ネットワーク事業者は、否定応答(NACK)をクライアントに返送することを決定でき、それ以外の場合、パケットはネットワークを経由してその宛先に経路指定される。
DNAPでは、ネットワークインフラストラクチャ自体が、システムの状態に関するコンセンサスが格納される場所として、ブロックチェーン内の確認部ノードとして動作し得る。悪意のあるエンティティがこの手法を危殆化させるには、悪意のあるエンティティがネットワークインフラストラクチャの51%を危殆化させる必要がある。単一の中央集権型ファイアウォールサービスではなく、妥協が必要な場所が多数あるため、ネットワークインフラストラクチャの大部分を侵害すると、悪意のあるエンティティにとってより多くの負荷がかかる可能性がある。ネットワークインフラストラクチャのコンセンサスは、アクセス制御リスト(ACL)コマンドリスト(Cリスト)であり得る。一例では、ネットワークインフラストラクチャのコンセンサスが非集中型プロトコルで確立されると、上述の方法は、ブロックチェーンに格納されたACLまたはCリストの管理上で書き直され得る、またはマッピングされ得る。一例では、DNAPプロトコルは、プロトコル内の有効なアドレスを有するエージェントによって署名されたトランザクションによるトリガに基づいてステータス変更を更新することができる。
本明細書でDNAPとのセキュリティおよび通信に関して使用されるように、リソースの作成部はトークンを発行することができ、トークン自体は転送可能または不可能であり得、トークンはネットワーク事業者からの指示に基づいて使い捨てのクレデンシャルのように使用され得る。DNAP機能トークンを使用すると、いったんトークンが使用されると、そのトークンは再び使用されないため、DNAPや同様のシステムで使用されるトークンを、デバイスがネットワークにどれくらいの量アクセスするかを制御するための割り当てとして使用できる。トークンは、Xの数のパケット、Xの量のデータ、またはXの期間の時間で機能するように設定できる、あるいは、なんらかの種類のトラフィックに対しては無期限のリースを割り当て、その他のトラフィックに対しては割り当て分を割り当てることができる。
図181は、一部の実施形態による、評価されたデータユニットとの交渉のためのIoTデバイス18100に存在し得るコンポーネントの一例のブロック図である。同様の番号が付けられた項目は、図8において説明したとおりである。
上でも示したように、図8を参照すると、大容量ストレージ808は、本明細書で説明されるグループ作成機能を実施するための複数のモジュールを含むことができる。大容量ストレージ808においてコードブロックとして示されているが、モジュールのうちのいずれも、例えば特定用途向け集積回路(ASIC)に組み込まれるなど、ハードワイヤード回路で完全にまたは部分的に置き換えられ得ることが理解されよう。大容量ストレージ808は、ブロックチェーンクライアントとしてのデバイスのためのデバイスアイデンティティを生成するためのデバイスアイデンティティ生成部18102を含み得る。デバイスは、DNAPからトークンを要求することができる。トークンは、ピアツーピア以外のネットワークデータを送信および受信する能力をデバイスに付与することができる。一例では、トークンは、ネットワークのオープンシステム相互接続層の層上でデータを送信および受信する能力をデバイスに付与することができる。一例では、デバイスは、デバイスによって受信および送信されたトランザクションのトランザクション記録を格納することができ、トランザクション記録は、DNAPと共有される。デバイスは、デバイスから送信されたパケットの発信元を示すための鍵を生成することができる。デバイスは、ブロックチェーン対応デバイスであり得、デバイスは、デバイスによって送信され、デバイスによって受信されたトランザクションをブロックチェーン上に格納し得る。デバイス属性の記述は、ブロックチェーンの外に格納されてもよい。
大容量ストレージ808は、デバイスから発見ブロードキャストメッセージをパブリッシュするためのメッセージパブリッシュ部18104を含み得る。大容量ストレージ808は、パブリッシュされた発見ブロードキャストメッセージに基づいて、DNAPからの応答を受信するデバイスに応答して、非集中型ネットワークアクセスプロキシ(DNAP)ネットワークへの参加をデバイスから適用するためのネットワーク適用部18106を含み得る。大容量ストレージ808は、デバイスのアイデンティティおよび属性をDNAPに記述するためのデバイス記述部18108を含み得る。
大容量ストレージ808は、デバイスのアイデンティティおよび属性に基づいてネットワークによってデバイスに許可されているアクセスに応答して、ネットワークを介してデバイスからパケットを送信するためのパケット送信部18110を含み得る。一例では、パケットがトークンを加え、パケットとトークンとの組み合わせが検証のためにDNAPに送信されてもよく、DNAPは、DNAPがトークンを受け入れられないことの検出に応答してパケットとトークンの両方を拒否する。一例では、トークンは、閾値数のパケット、閾値量のデータ、または閾値期間のうちの少なくとも1つと共に使用するのに有効であり得る。
図182は、一部の実施形態による、タスクおよびコミッションノードを定義するためのコードを含む、非一時的機械可読媒体18200のブロック図である。同様の番号が付けられた項目は、図9において説明したとおりである。
非一時的機械可読媒体18200は、ブロックチェーンクライアントとしてのデバイスのためのデバイスアイデンティティを生成するようにプロセッサ902に指示するためのコード18202を含み得る。デバイスは、DNAPからトークンを要求することができる。トークンは、ピアツーピア以外のネットワークデータを送信および受信する能力をデバイスに付与することができる。一例では、トークンは、ネットワークのオープンシステム相互接続層の層上でデータを送信および受信する能力をデバイスに付与することができる。一例では、デバイスは、デバイスによって受信および送信されたトランザクションのトランザクション記録を格納することができ、トランザクション記録は、DNAPと共有される。デバイスは、デバイスから送信されたパケットの発信元を示すための鍵を生成することができる。デバイスは、ブロックチェーン対応デバイスであり得、デバイスは、デバイスによって送信され、デバイスによって受信されたトランザクションをブロックチェーン上に格納する。デバイス属性の記述は、ブロックチェーンの外に格納されてもよい。
非一時的機械可読媒体18200は、デバイスから発見ブロードキャストメッセージをパブリッシュするようにプロセッサ902に指示するためのコード18204を含み得る。非一時的機械可読媒体18200は、パブリッシュされた発見ブロードキャストメッセージに基づいて、DNAPからの応答を受信するデバイスに応答して、非集中型ネットワークアクセスプロキシ(DNAP)ネットワークへの参加をデバイスから適用するようにプロセッサ902に指示するコード18206を含み得る。非一時的機械可読媒体18200は、デバイスのアイデンティティおよび属性をDNAPに記述するようにプロセッサ902に指示するためのコード18208を含み得る。
非一時的機械可読媒体18200は、デバイスのアイデンティティおよび属性に基づいてネットワークによってデバイスに許可されているアクセスに応答して、ネットワークを介してデバイスからパケットを送信するようにプロセッサ902に指示するコード18210を含み得る。一例では、パケットがトークンを加え、パケットとトークンとの組み合わせが検証のためにDNAPに送信されてもよく、DNAPは、DNAPがトークンを受け入れられないことの検出に応答してパケットとトークンの両方を拒否する。一例では、トークンは、閾値数のパケット、閾値量のデータ、または閾値期間のうちの少なくとも1つと共に使用するのに有効であり得る。
許可ガイドは、デバイスのための非集中型の認可、認証、および課金を提供するために使用され得る。本開示は、リモート認証ダイヤルインユーザサービス(RADIUS)および関連するDIAMETERプロトコルへの拡張のためのビルディングブロックを開示する。一例では、本開示の技法は、集中管理システムによって引き起こされるスケーラビリティの問題に対処する。これらの技法は、より大きな分散型RADIUSネットワークに適用することができる。一例では、大規模ネットワークのメンバは、自身のユーザアカウントを維持しながら、自身の構内で自身のRADIUSサーバを実行することができる。一例では、認証は、要求の位置にかかわらず、メンバのネットワークアクセス要求をメンバのネットワークに経路指定するRADIUSプロキシを介して進むことができる。ネットワークへの参加要求がメンバネットワークで受け入れられた場合、大規模ネットワークの残りの部分は認証されたものとしてその発信元からのトラフィックを受け入れる。この技法により、ネットワークは、このような大規模で分散された動的ネットワーク間でユーザアカウントを同期することを回避できる。この技法は、新しいエンティティがネットワークに参加したときに審査プロセスを提供するために追加できる。エンティティがRADIUSサーバをセキュアに運用し、設定ポリシーで設定された基準に準拠していることを確認するために、この技法を追加することができる。
図183は、一部の実施形態による、許可ガイド18302を用いて認証、認可、および課金を提供することの非集中型バージョンのための例示的な組織18300の概略図である。同様の番号が付けられた項目は、図165を参照して開示されたとおりである。機能のための処理は18304で開始され得る。
組織18300および方法は完全なシステムとすることができ、また既存の認可、認証、および課金プロトコルに対する拡張とすることもできる。ブロック18304において、ユーザは、既にユーザである、集中型局にログオンすることができる。一例では、ユーザは大学の学生または教職員であり得、集中型局は大学のネットワークであり得る。ログイン中に、ユーザは自分のプロファイルを作成できる。この時点で、システムに対するユーザアイデンティティを確認するために、ユーザプロファイル、パスワード、またはネットワークの使用を一緒に使用することができる。ユーザがユーザアカウントにログインするのではなくデバイスである場合、デバイスはブートし、システムのモジュールによるデバイス認証をコミッショニングすることができる。
ブロック18306において、ユーザのデバイスは、使用の命令により、支払いを交換することができる。一例では、ユーザのデバイスがペイパーユース方式のネットワークにアクセスしていてもよく、ネットワークにアクセスするために支払いが必要とされ得る。ユーザデバイスを介したユーザは、ネットワークを介してネットワーク事業者と支払いを交渉することができる。この種の支払いは任意であり得、例えば、ネットワークプロバイダは無料アクセスを提供し得る。ネットワークプロバイダは、課金することを選択することができ、課金する際に、ネットワークプロバイダは、ネットワークプロバイダが受け入れることができる支払い形態を指定することができる。一例では、ネットワークは暗号通貨またはinfocoinを受け入れることができる。18306に関して説明したように支払いを交換することは、リストされたように、または参加エンティティが条件を受け入れ、プロバイダが参加エンティティに参加エントリアクセスを許可したときにプロセスの終わりに実行することができる。
ブロック18308において、秘密鍵がユーザに対して作成されてもよく、アドレスと関連付けられてもよい。ブロック18310において、ユーザデバイスは許可ガイドに参加することを要求することができる。ブロック16518で上述したように、許可ガイドへの参加は、ユーザデバイスがネットワークの恒久的なメンバになることができる場合に一度行われ得る。一例では、許可ガイドに参加することは、期限がある、または他の条件によって制限され得る。上述のように、参加許可ガイド機能は、応募者を受け入れる前に特定の条件が満たされることを保証することができる。一例では、支払いが行われた場合、支払いは、許可ガイドに参加する全プロセスが完了するまで確定されてもされなくてもよい。
上述のように、ブロック16522において、参加しているアイデンティティのリストを格納することができる。参加しているアイデンティティの保存は、オフチェーンで行われ得る。ストレージはまた、ハッシュで行われてもよい。さらに、参加しているアイデンティティのストレージに関して、アイデンティティ情報を格納することができる位置を識別するためにポインタを使用することができる。格納されたデータはまた、暗号化され、認可されたエンティティが見ることを制限することもできる。
ブロック18312において、属性フィルタが、属性を確認するために使用され得る。一例では、確認は、ゼロ知識証明メカニズムを用いて行われ得る。属性の確認にはアテステーションを使用できる。一例では、属性フィルタは、例えば個人が18歳よりも上であるか否かを識別することなど、ネットワーク上で動作するための条件を確認することができる。属性フィルタは、個人が彼らの完全なアイデンティティを開示する必要なしに、個人についての属性のアテステーションを可能にし得る。
ブロック16530において、上記のように、申請者デバイスは、トークンを要求することができる。前と同様に、トークンは無制限であってもよいし、トークンが制限されていてもよい。トークンは、暗号通貨コインによって支援されてもされなくてもよい。トークンの使用は、いくつかのトークンが獲得のために支払いを使用することができ、そして他のトークンがネットワーク事業者によって決定されるように無料であることを混ぜ合わせたものを可能にし得る。トークンの要求は、課金機能を実行するブロックチェーン18314およびブロックチェーン18314のサイドチェーン18316を通過する追加の段階を含み得る。ブロック18318において、ブロックチェーン18314内において、許可ガイド18302からの支払いまたは機能呼び出しがブロックチェーン上のコインを予約する。ブロック18320において、サイドチェーン18316内において、予約されたトークンは、トークンが作成されたサイドチェーン18316と関連付けられてもよい。ブロックチェーンにトークンを追加することができるサイドチェーン18316においてコインを予約することまたはトークンを作成することの動作は、どのアイデンティティがどの種類のトークンを要求したかを識別および構築することが可能であり得る課金形態を構築する。
ブロック16534において、上記のように、許可ガイド18302のポリシーの実行によりトークンを失効させることができる。一例では、エンティティが許可ガイド18302を脱退したい場合、トークンはエンティティによって返金されるように要求されてもよい。許可ガイド18302からの要求に応答して、ブロック18322において、トークンをサイドチェーン18316から削除することができる。ブロック18324において、ブロックチェーン18314内において、サイドチェーン18316内の削除されたトークンに関連するコインは、トランザクションの理由に応じてネットワークプロバイダに解放されるかまたはエンティティに返金されてもよい。
ブロック16534において、上記のように、ネットワークプロバイダが主張する支払いT&Cを許可ガイド18302に符号化することができる。ブロック18326において、認証要求が送信され得る。一例では、認証は、デバイスがネットワークに要求を送信することによって機能する。デバイスは、検証側当事者に公開鍵を提示することができる。一例では、公開鍵を送信した当事者は、トークンがそのような公開鍵に入金されているか否かを判定するためにブロックチェーン18314をチェックすることができる。ネットワーク上の異なるサービスにアクセスすることは、異なる種類のトークンを所有するように所有者に要求し得る。
ブロック18328において、トークンを消費することができる。一例では、トークンは使用ごとに消費されてもよい。使用ごとにトークンを使用することは、サービスごとにネットワークプロバイダに予算をネットワーク上のエンティティに割り当てる方法をネットワークプロバイダに提供する認可の形式である。プロバイダは、代わりに、トークンが使用ごとではないことを示してもよく、使用による制限なしに使用されてもよい。ブロック18330において、サイドチェーン18316を通じたトークンの消費または提示は、サイドチェーン上のトランザクションとして記録されてもよい。この記録は、別の課金サービスとみなされる場合もある。ブロック18316において、サイドチェーンは、トークンが消費されたか否かを示すことができる。トークンが消費された場合、この消費の記録がサイドチェーン18316にある場合がある。一例では、サイドチェーン18316で消費されたトークンは、メインブロックチェーン18314上のコインによって支援されてもよい。ブロック18332において、ブロックチェーン18314上において、コインをネットワーク事業者およびプロバイダのウォレットに返金または払い戻され得る。
図184は、一部の実施形態による、許可ガイドを用いて認証、認可、および課金を提供することの非集中型バージョンのための例示的な方法18400のプロセスフロー図である。図184の方法18400は、図185に関して説明されるIoTデバイス18500によって実施することができる。プロセスフローは、ブロック18402で開始し得る。
ブロック18402において、ネットワークの使用を要求しているエンティティは、例えばポータルまたはAPIを介して登録することができる。一例では、ポータルは、所属学生が登録し料金を支払うために個々の大学によって提供されてもよい。一例では、マシン指向ネットワークに参加しようとしているエンティティの場合、そのようなエンティティは、任意のウォレットまたはクレジットカードプロバイダからの資金を使用して自動的に参加することができる。
ブロック18404において、参加エンティティが、彼らが参加を希望するネットワーク上にクレジットがない場合、支払い交換が使用され得る。ブロック18406において、参加エンティティは、支払いの交換に参加することによってスマートコントラクトに入ることができる。一例では、参加エンティティの属性を登録することができる。一例では、使用のための属性は生年月日および他の個人データを含み得る。一例では、マシンの属性は、デバイスの種類またはソフトウェアの種類およびバージョンを含み得る。属性データは、属性データが裏付け文書と共に報告されているか否かをアテステーションされ得る。マシンの属性の場合、これらのマシンの属性は、トラステッドセンシングやハードウェアのルートオブトラスト(HWROT)を含む技術的な方法でアテステーションされ得る。このアテステーションに応答して、参加エンティティのリストが許可ガイド内に維持され得、これでエンティティは許可ガイドからトークンを要求し得る。
ブロック18408において、コンセンサスネットワークによって判定された有効なアイデンティティ要求の確認に応答して、トークンがエンティティに発行され得る。ネットワーク上のアイデンティティの残高がゼロより大きい場合、トークンがエンティティに発行され得る。一例では、TTLは、エンティティのアテステーションに対して設定され得る。一例では、エンティティのアテステーションは、時間、使用法、および地理的に制限され得る。一例では、エンティティがモバイルである場合、トークンは一部の地域では機能し、他の地域では機能しないことがあるので、制限はトークンによって施行され得る。
ブロック18410において、コインがトークンに対して予約され得る。一例では、コインはサイドチェーンに予約され得る。コインの予約プロセスは、失敗した試行に応じて再試行され得る。一例では、プロセスはまた、トランザクションから引き出すことによってプロセス内で交換されたクレジットを返金することを含むことができる。コインを予約する試みが成功した場合、トークンが作成され、エンティティに発行され、それにより、次いで、エンティティが認証要求を送信し得る。認証要求は、前述のように属性フィルタリングされてもよい。トークンが消費されると、サイドチェーンでそれらに関連付けられているコインのロックが解除されるか返金され、これらのトークンがネットワークプロバイダに渡され得る。
ブロック18412において、エンティティは許可ガイドを脱退し得る。許可ガイドを脱退することを避けるために、エンティティのトークンが既に消費されている場合、エンティティは追加のトークンを要求し得る。一例では、エンティティのアイデンティティがネットワーク上でもはや有効ではない場合、許可ガイドは終了し得る。一例では、ネットワークエンティティまたはネットワークプロバイダはまた、エンティティを追い出すためにこのプロセスを開始し得る。使用されていないトークンは失効または破棄され得、エンティティに対する残りの資金の残高は、許可ガイドの条件に従って返金され得る。
図185は、一部の実施形態による、IoTデバイスを用いた非集中型の認可、認証、および課金のためにIoTデバイス18500に存在し得るコンポーネントの一例のブロック図である。同様の番号が付けられた項目は、図8において説明したとおりである。
上でも示したように、図8を参照すると、大容量ストレージ808は、本明細書で説明されるグループ作成機能を実施するための複数のモジュールを含むことができる。大容量ストレージ808においてコードブロックとして示されているが、モジュールのうちのいずれも、例えば特定用途向け集積回路(ASIC)に組み込まれるなど、ハードワイヤード回路で完全にまたは部分的に置き換えられ得ることが理解されよう。大容量ストレージ808は、第2のネットワークへのポータルを介して第1のネットワークにデバイスを登録するためのデバイスレジストラ18502を含むことができ、第2のネットワークは、第1のネットワークへのアクセスを認可される。デバイスは、第2のネットワーク内のウォレットへの支払い交換を実行してもよい。
大容量ストレージ808は、許可ガイドの義務の合意を介してデバイスを許可ガイドに参加させるためのデバイス参加部18504を含み得る。大容量ストレージ808は、許可ガイドの機能を使用してトークンを要求するためのトークン要求部18506を含むことができ、トークンは、第2のネットワークにアクセスするために認証されたデバイスを識別する。一例では、トークンの要求は、サイドチェーン上で生成されたトークンに対応するように、課金ブロックチェーン上のコインの予約をもたらし得る。ブロックチェーンのコインは、サイドチェーンによって失効され消費されたトークンのうちの少なくとも1つであるトークンの検出に応答して解放されてもよい。一例では、許可ガイドに参加することは、デバイスの属性が第1のネットワークで許可されていることを確認するために、デバイスから、デバイスの属性を属性フィルタの許可ガイドに提供することを含み得る。属性は、デバイスが許可ガイドに参加している間にアクティブなユーザプロファイルの属性を含み得る。トークンは、デバイスの認可形式として使用されたことに応答して、自身を破壊することができる。
大容量ストレージ808は、デバイスからの認証要求を第1のネットワークに送信するための要求送信部18508を含むことができ、第1のネットワークは、トークンの検出に応答して認証を確認する。トークンは、デバイスによるトークンの第1のネットワークへの提示によるデバイスの認証に応答してサイドチェーン上で消費され得る。デバイスは、デバイスが第2のネットワークにアクセスするためのクレデンシャルを有するという第1のネットワークに対する認証に基づいて第1のネットワークにアクセスすることを認可されてもよい。一例では、第1のネットワークを使用するためのデバイスの認可は、アクセス数、第1のネットワークを通してアクセスされるデータの量、および許可されたアクセスの時間のうちの少なくとも1つに基づいて期限切れになり得る。
図186は、一部の実施形態による、IoTデバイスを用いた非集中型の認可、認証、および課金のためのコードを含む、非一時的機械可読媒体18600のブロック図である。同様の番号が付けられた項目は、図9において説明したとおりである。
非一時的機械可読媒体18600は、第2のネットワークへのポータルを介して第1のネットワークにデバイスを登録するようにプロセッサ902に指示するコード18602を含み得、第2のネットワークは、第1のネットワークへのアクセスを認可される。デバイスは、第2のネットワーク内のウォレットへの支払い交換を実行してもよい。
非一時的機械可読媒体18600は、許可ガイドの義務の合意を介してデバイスを許可ガイドに参加させるようにプロセッサ902に指示するためのコード18604を含み得る。非一時的機械可読媒体18600は、許可ガイドの機能を使用してトークンを要求するようにプロセッサ902に指示するコード18606を含み得、トークンは、第2のネットワークにアクセスするために認証されたデバイスを識別する。一例では、トークンの要求は、サイドチェーン上で生成されたトークンに対応するように、課金ブロックチェーン上のコインの予約をもたらし得る。ブロックチェーンのコインは、サイドチェーンによって失効され消費されたトークンのうちの少なくとも1つであるトークンの検出に応答して解放されてもよい。一例では、許可ガイドに参加することは、デバイスの属性が第1のネットワークで許可されていることを確認するために、デバイスから、デバイスの属性を属性フィルタの許可ガイドに提供することを含み得る。属性は、デバイスが許可ガイドに参加している間にアクティブなユーザプロファイルの属性を含み得る。トークンは、デバイスの認可形式として使用されたことに応答して、自身を破壊することができる。
非一時的機械可読媒体18600は、デバイスからの認証要求を第1のネットワークに送信するようにプロセッサ902に指示するコード18608を含み得、第1のネットワークは、トークンの検出に応答して認証を確認する。トークンは、デバイスによるトークンの第1のネットワークへの提示によるデバイスの認証に応答してサイドチェーン上で消費され得る。デバイスは、デバイスが第2のネットワークにアクセスするためのクレデンシャルを有するという第1のネットワークに対する認証に基づいて第1のネットワークにアクセスすることを認可されてもよい。一例では、第1のネットワークを使用するためのデバイスの認可は、アクセス数、第1のネットワークを通してアクセスされるデータの量、および許可されたアクセスの時間のうちの少なくとも1つに基づいて期限切れになり得る。
本技法の一部の実施形態は、とりわけ、例えばリモート認証ダイヤルインユーザサービス(RADIUS)および/またはDIAMETERプロトコルを使用するIoTデバイス上の非集中型の認可、認証、および課金を開示する。非集中型プロキシは、RADIUSサーバ、DIAMETERサーバ、またはDIAMETERプロトコルを実行しているRADIUSサーバの前に配置できる。非集中型APIは、RADIUSサービスおよび/またはDIAMETERサービスに組み込まれ得る。既存の呼び出しは、ブロックチェーン型暗号化メカニズムでRADIUSサービスおよび/またはDIAMETERサービスにラップされ得る。ブロックチェーン型暗号化メカニズムは、例えば、RADIUSサーバおよび/またはDIAMETERサーバによる処理のために要求を通過させることを可能にするために、要求の送信元の証明のレイヤとして使用され得る。
図187は、一部の実施形態による、リモート認証ダイヤルインユーザサービス(RADIUS)および/またはDIAMETERプロトコルを使用するIoTデバイス上での非集中型の認可、認証、および課金のための技法18700の概略図である。RADIUSサーバ18702は、変更からロックされてもよく、非集中型RADIUSプロキシ18704は機能拡張されてもよい。非集中型RADIUSプロキシ18704は、メッセージが従来のRADIUSサーバに到着する前に措置とることができる。非集中型API 18706は、RADIUSサーバ187020とバックエンドデータベース18708との間に挿入することができ、RADIUSサービスの動作に対する修正を含むことができる。
非集中型RADIUSプロキシ18704は、RADIUSサーバ18702がバックエンドデータベース18708を実装するときに機能することができる。一例では、データベース18708はファイルであり得る、またはそれは任意の数のサポートされるデータストアを使用し得る。非集中型RADIUSプロキシ18704では、サービスは、RADIUSサーバ18702の前に位置し、非集中型フィルタとして動作することができる。非集中型RADIUSプロキシ18704は、非集中型メカニズムを使用して要求者のアイデンティティを確認することによってセキュリティチェックを提供することができる。
RADIUSサーバ18702が使用する呼び出しは、非集中型API 18706を介してそれらを経路指定するように修正することができる。非集中型API 18706は、RADIUS機能のブロックチェーンへの経路指定をサポートするクラスのセットとしてRADIUSサーバのコードベースに組み込まれ得る。RADIUSサーバ18706は、ブロックチェーンクライアントになり、アイデンティティおよびトランザクションの有効性チェックを実行することができる。あるいは、またはそれに加えて、アイデンティティおよび有効性チェックは、RADIUSサーバがサポートするように修正された外部サービスとして実施することができる。非集中型APIを用いて、RADIUSサーバコードは、動作がアイデンティティおよび有効性チェック機能を可能にすることができるように修正され得る。有効性チェックを実行するための例示的なメカニズムを以下に説明する。
図188は、一部の実施形態による、IoTデバイス上での認可、認証、および課金のために非集中型RADIUS 18704プロキシを介して動作するための図187のコンポーネントのための例示的な方法18800のラダー図である。図188の方法18800は、図191に関して説明されるIoTデバイス19100によって実施することができる。同様の番号が付けられた項目は、図187に関して開示されたとおりである。
非集中型RADIUSプロキシ18704は、RADIUSクライアント18804からのRADIUS認証要求18802を処理することができる。RADIUSクライアント18804は、RADIUSクライアントブロックチェーンまたは分散型台帳18806のアイデンティティからの秘密鍵を用いてRADIUS要求に署名するように修正されてもよい。アイデンティティは、要求の送信元であるアイデンティティ18808と、要求が実際にブロックチェーンまたは分散型台帳18806上のアイデンティティに対応する秘密鍵の所有者であるか否かと、を検証するために使用され得る。ブロックチェーンまたは分散型台帳18806上のアイデンティティは、先のセクションで説明したように、許可ガイドを使用して以前に確立されている場合がある。例えば、アイデンティティは、サービスに登録しており、許可ガイドに参加していてもよく、そしてそのコントラクト内の参加エンティティとしてリストされてもよく、あるいはアイデンティティはトークン保有者であってもよい。アイデンティティ検証は、新しいチェーンによって署名された認証要求が初めて見られたときに、ブロックチェーンまたは分散型台帳18806がそのリクエストのアイデンティティを受け入れることができる実行時に行うことができる。アイデンティティ検証応答18810が、非集中型プロキシ18704に返され得る。アイデンティティが許容可能であると検証されたことに応答して、非集中型プロキシ18704は、適切なRADIUSサーバを要求する18812ことができる。それに応じて、RADIUSサーバ18702は、要求が、成功として承認された、または失敗として拒否されたことを応答18814することができる。
アイデンティティの検証が成功すると、同一ユーザからの将来のRADIUS要求が正しい秘密鍵によって署名され得るように、複数のアイデンティティがリンクされ得、秘密鍵を含まない要求は拒否され得る。アイデンティティは、RADIUS要求と共にトークンを提示し、そのアイデンティティを確認するために、検証をブロックチェーンまたは台帳に対して比較することによって応答することができる。前述のように、確認は、有効なトークン保有者としての要求を示し得、失敗した確認でも、特定の許可ガイドのメンバとしてリストされていることによってアイデンティティが検証されている可能性がある。確認は、ブロックチェーン上の通貨がRADIUS要求に対して費やされる時期を示す。例えば、RADIUS要求を行うために、アイデンティティは、使用するブロックチェーン上に一部のクレジットおよびコインを有することができる。
図189は、一部の実施形態による、IoTデバイス上での認可、認証、および課金のために非集中型API 18706プロキシを介して動作するための図187のコンポーネントのための例示的な方法18900のラダー図である。図189の方法18900は、図191に関して説明されるIoTデバイス19100によって実施することができる。同様の番号が付けられた項目は、図187および図188に関して開示されたとおりである。
呼び出しは、実質的には同様であるが、異なるアクターをアドレス指定し得るため、呼び出しのシーケンスは、図188に関する呼び出しのシーケンスとは異なる。例えば、図189では、署名付き認可要求18902は、RADIUSクライアント18804からRADIUSサーバ18702へのものであり得る。アイデンティティの検証18904は、RADIUSサーバ18702から非集中型API 18706へのものであり得る。アイデンティティ要求の第2の検証18906が、非集中型API 18706から分散型台帳18806に送信され得る。それに応答して、分散型台帳18806は、アイデンティティ検証の成功または失敗を示すアイデンティティ応答18908を非集中型API 18706に返すことができる。それに応答して、非集中型API 18706は、アイデンティティ検証の成功または失敗を示す第2のアイデンティティ応答18910をRADIUSサーバ18702に返すことができる。RADIUSサーバ18702は、RADIUSサーバ要求-応答をRADIUSクライアント18804に返すことができる。これらの動作の結果は、RADIUS要求のソースのアイデンティティの確認であり得、確認は、例えば、確認の要求が処理され得る前に、ブロックチェーンまたは非集中型台帳を通過し得る。
図190は、一部の実施形態による、IoTデバイス上での非集中型の認可、認証、および課金のための動作図19000の概略図である。認可要求19002は、ブロックチェーン19006を利用するトランザクション確認チェック部19004と相互作用する。
認可要求19002内で、ブロック19008において、トランザクション内容をメッセージに追加することができる。図190に示す例では、トランザクション内容は、ユーザ名およびパスワード、例えば「マイク」のユーザ名およびクレデンシャルであり得る。後述のとおり、この方法で機密情報が第三者に公開されることはない。トランザクションはメタデータを含み得る。メタデータはパブリック台帳に格納されてもよい。金銭または暗号通貨の額面金額がトランザクションの一部である場合、トランザクションの内容には、どのくらいの価値がトランザクションされたかについての詳細が含まれ得る。トランザクションの有効性は、満たされているトランザクションの条件によって異なり得る。例えば、満たされているトランザクションの条件は、上述の例における支払い動作および認証動作を含むことができる。
認可要求19002内で、ブロック19010において、要求されているネットワークアドレスをトランザクション内容に含めることができる。ネットワークアドレスの代わりに、要求されているリソースがトランザクション内容に含まれてもよい。ネットワークアドレスは、例えば、RADIUSサーバの完全修飾ドメイン名(FDQN)またはインターネットプロトコル(IP)アドレスであり得る。ネットワークアドレスは、ネットワーク上のリソースであり得る。ネットワークアドレスは、RADIUSサーバまたはネットワークリソースのオーナーの秘密鍵に基づくウォレットアドレスを含み得る。ネットワークアドレスは、サービスの使用のために要求されている支払いが実行され得ることに応じてウォレットを含み得る。
認可要求19002内で、ブロック19012において、トランザクション内容は当事者の秘密鍵によって署名されてもよい。トランザクションの内容に署名するプロセスは、シグネチャ19014を形成することを含み、公開鍵の位置への参照が含まれ得る19016、またはトランザクションが公開鍵自体を含み、認可要求19002自体に公開鍵19018を提供し得る。
トランザクション確認チェック部19004内で、公開鍵を検証する要求19020を行うことができる。公開鍵の位置は19022でルックアップされ得る、またはブロックチェーン19006から要求され得る。ネットワークオーナーはブロックチェーン19006を作成することができ、エンティティは、エンティティの公開鍵をブロックチェーン19006にポストすることによってブロックチェーン19006上のアイデンティティを購入または獲得することができる。交渉中のエンティティに対する公開鍵のブロックチェーン19006へのポストは、暗号通貨、トークン、または他の支払いと交換とすることができる。支払い額は、ブロックチェーン19006内に鍵が保持され得る期間を判定し得る。鍵は、無期限に、または指定された期間、ブロックチェーン19006によって保持され得る。アイデンティティが確立または確認されるための条件は、ネットワーク管理者によって調整され得る。
ブロックチェーン19006は、複数のブロック19024を含むことができる。アイデンティティを格納するために使用されるブロックチェーン19006は、マイナーのクリティカルマスを有するより大きなブロックチェーンの上に位置する仮想ブロックチェーンであり得る。ブロックチェーンは、例えば、デュアルマイニングの概念を組み込んでいてもよく、1つのブロックチェーンにおける証明のために行われた作業19006は別のブロックチェーンにおける証明としても役立つ。ルックアップ19022は、例えば、上に開示されたブルームフィルタホップの方法を使用して実行されてもよい。ルックアップ19022の結果は、公開鍵が知られているということであり得る。ルックアップ19022の結果は、鍵が最初にトランザクションに含まれていたことであり得る。
トランザクション確認チェック部19004内で、ブロック19026において、鍵は、トランザクションを復号し、識別されたエンティティを確認することができる。鍵は、非対称鍵の場合は公開鍵であってよいし、対称鍵の場合は秘密鍵であってもよい。メッセージ通信は、一般に、暗号化/復号に秘密対称鍵を使用する。トランザクションは、ブロックチェーン19006にコミットされ得る。トランザクションは、チェーン外ストレージメカニズムへの参照となり得る。ブロック19026において、チェーン外ストレージメカニズムを使用して、アイデンティティ検証段階の結果を記録することができる。アイデンティティ検証段階の結果の記録は、課金を提供することができる。記録は、例えば、ネットワークプロバイダのブロックチェーン19006および/または仮想ブロックチェーンにコミットすることができる。ブロックチェーン19006への記録は、場合によっては、トランザクションに関するメタデータに限定され得る。ユーザ名およびパスワードに関する情報は、場合によっては、ブロックチェーン19006に含まれることを禁じられ得る。情報がブロックチェーン19006に含まれる場合、その情報はRADIUSプロキシおよび/または修正RADIUSサーバとの間のトランザクションの一部であり得る。
トランザクション確認チェック部19004内で、ブロック19028でチェーン外イベントが発生する場合があり、トランザクションアイデンティティが有効である場合、通常の処理のために、トランザクションの内容がRADIUSサーバに渡され得る。認証要求の場合、内容は、例えば、ユーザ名およびパスワードを含み得る。サーバへのコンテンツの受け渡しは、RADIUSサーバとそのプロキシ、またはRADIUSプロキシ内の修正された非集中型コードの間で行われ得る。
トランザクション確認チェック部19004内で、ブロック19030において、チェーン外イベントが発生することがあり、RADIUSサーバからの応答が、直接クライアントに送り返されることがある。応答の経路指定は、実装アーキテクチャの選択に部分的に応じて、プロキシを介しても、RADIUSサーバを介してもよい。RADIUSサーバは、RADIUSサーバが受信した要求のロギングおよびアカウンティングを実行することができる。
トランザクション確認チェック部19004内で、ブロック19032において、応答が返送されてもよい。応答は、肯定または否定であり得る。応答は、不変記録としてブロックチェーン19006に格納されてもよい。ブロックチェーン19006に応答を格納すると、悪意のあるアクターが自分の行動を隠すことの難しさが高まり得る。
図191は、一部の実施形態による、IoTデバイスを用いた非集中型の認可、認証、および課金のためにIoTデバイス19100に存在し得るコンポーネントの一例のブロック図である。同様の番号が付けられた項目は、図3および図8に関して説明したとおりである。図8に関して説明したIoTデバイス800、および本明細書で説明される他のIoTデバイスに対して選択されたものとは異なるコンポーネントが、IoTデバイス19100に対して選択され使用されてもよいことに留意されたい。
大容量ストレージ808は、IoTデバイスを用いた非集中型の認可、認証、および課金を実施するための複数のモジュールを含むことができる。大容量ストレージ808においてコードブロックとして示されているが、モジュールのうちのいずれも、例えば特定用途向け集積回路(ASIC)に組み込まれるなど、ハードワイヤード回路で完全にまたは部分的に置き換えられ得ることが理解されよう。
大容量ストレージ808は、非集中型APIを用いて認証要求のアイデンティティを検証するためのアイデンティティ検証部19102であって、認証要求がRADIUSクライアントから受信され、非集中型APIが、分散型台帳に要求を送信し、分散型台帳からのアイデンティティ検証応答の受信に応答して応答をRADIUSサーバに返すことによってアイデンティティを検証する、アイデンティティ検証部19102を含み得る。RADIUSクライアントは、認証されたアイデンティティの応答に応答してトランザクションを行うことができる。トランザクションは、ユーザ名、パスワード、およびメタデータのうちの少なくとも1つを含み得る。トランザクションは、価値トランザクションを含み得る。トランザクションは、暗号通貨トランザクションであり得る。認証要求は、ネットワークアドレスに対する要求を含み得る。ネットワークアドレスは、RADIUSサーバの完全修飾ドメイン名またはRADIUSサーバのインターネットプロトコルアドレスのうちの少なくとも一方を含むことができる。RADIUSサーバは、ブロックチェーンから公開鍵の位置を要求することによって公開鍵を検証することができる。RADIUSサーバへの要求は、認証されたアイデンティティの確認をRADIUSクライアントが受信したことに応答して、オフチェーンで行われ得る。RADIUSサーバは、RADIUSサーバが受信した要求のロギングおよびアカウンティングを実行することができる。認証要求に対する応答は、不変記録としてブロックチェーンに格納されてもよい。
大容量ストレージ808は、非集中型APIからの応答の受信に応答して、認証要求に対する応答をRADIUSクライアントに返すための応答返送部19104を含むことができる。大容量ストレージ808は、分散型台帳からの肯定的なアイデンティティ検証応答の受信に応答して、RADIUSサーバに要求を送信するための要求送信部19106を含むことができる。
図192は、一部の実施形態による、IoTデバイスを用いた非集中型の認可、認証、および課金のためにプロセッサ902に指示するためのコードを含む、非一時的機械可読媒体19200のブロック図である。プロセッサ902は、バス904を介して非一時的機械可読媒体19200にアクセスすることができる。プロセッサ902およびバス904は、図9に関して説明したプロセッサ902およびバス904と同様の方法で実施することができる。非一時的機械可読媒体19200は、図8の大容量ストレージ808について説明したデバイスを含むこともできるし、光ディスク、USBメモリ(thumb drive)、または任意の数の他のハードウェアデバイスを含むこともできる。
非一時的機械可読媒体19200は、分散型台帳を用いて認証要求のアイデンティティを検証するようにプロセッサ902に指示するためのコード19202を含むことができ、認証要求は、リモート認証ダイヤルインユーザサービス(RADIUS)クライアントから受信される。RADIUSクライアントは、認証されたアイデンティティの応答に応答してトランザクションを行うことができる。トランザクションは、ユーザ名、パスワード、およびメタデータのうちの少なくとも1つを含み得る。トランザクションは、価値トランザクションを含み得る。トランザクションは、暗号通貨トランザクションであり得る。認証要求は、ネットワークアドレスに対する要求を含み得る。ネットワークアドレスは、RADIUSサーバの完全修飾ドメイン名またはRADIUSサーバのインターネットプロトコルアドレスのうちの少なくとも一方を含むことができる。RADIUSサーバは、ブロックチェーンから公開鍵の位置を要求することによって公開鍵を検証することができる。RADIUSサーバへの要求は、認証されたアイデンティティの確認をRADIUSクライアントが受信したことに応答して、オフチェーンで行われ得る。RADIUSサーバは、RADIUSサーバが受信した要求のロギングおよびアカウンティングを実行することができる。認証要求に対する応答は、不変記録としてブロックチェーンに格納されてもよい。
非一時的機械可読媒体19200は、分散型台帳からの肯定的なアイデンティティ検証応答の受信に応答して、要求をRADIUSサーバに送信するようにプロセッサ902に指示するためのコード19204を含み得る。非一時的機械可読媒体19200は、RADIUSサーバからの応答の受信に応答して、認証要求に対する応答をRADIUSクライアントに返すようにプロセッサ902に指示するためのコード19206を含み得る。
本明細書に開示された技法は、ネイティブ非集中型データベースを参照することができる。ネイティブ非集中型データベースは、分散型クラスタとは対照的に、非集中型クラスタへの参加の概念を理解しているデータベースであり得る。一例では、非集中型データベースは、分散型データベースの非集中型オペレーションをネイティブにサポートするためにデータベース内のテーブルのパブリックおよびプライベート区画の使用を通じて機能することができる。これは、複数の制約のあるデバイスにわたるデータの分散型ストレージを可能にすることによってIoTシステムの動作を改善することができる。
図193は、一部の実施形態による、ネイティブ非集中型データベースを使用してコンセンサスネットワーク19302を構成し動作させるためのプロセス19300の概略図である。コンセンサスネットワーク19302はノード19304を有することができる。コンセンサスネットワークは、第1のノードから第nのノードまでを含む複数のノード19304を有することができる。ネイティブ非集中型データベースクラスタを使用している間、ネットワークに知られていない当事者がネットワークに参加し得る。既存のノード19304は、中央局を形成することを妨げられ得る。ネットワークに参加することは、パブリック統一資源位置指定子(URL)またはアドバタイズされた名前空間に発行され得るトランザクションに参加するための要求を含み得る。名前空間は、ストレージにハードコードされるか、またはユーザによって調整可能であり得る。コンセンサスネットワーク19302内のノード19304が、ネットワーク内のノードで構成された中央局の実施を要求するメッセージを示している場合、ノード19304は新しいメンバの加入に投票することができる。中央局のノードは、デフォルトで新しいメンバがネットワークに参加することを可能にする規則を確立し得る。新しいメンバが加わると、新しいメンバのデータベース19306は既存のメンバのデータベース19306と同期され得る。同期は、複製される共有区画、すなわちS区画19308を含み得る。データベースはブロックチェーンデータベースであり得る。
共有区画19308は、基礎となるデータベース19306によって複製され得る。共有区画19308は、データプレーンを収容するために使用され得る。共有区画19308は、コンセンサスブロックチェーンを収容するために使用され得る。ネットワークは、タスクを実行している可能性がある多くのサービス19310およびクライアント19312から構成され得る。サービス19310およびクライアント19312は、例えば、ローカルに作動決定を下すためにデータを収集および処理するIoTシステムであり得る。サービス19310およびクライアント19312によって収集および計算されたデータは、プライベート区画19314に送信され得る。プライベート区画は集中的に制御されてもよい。
ネットワークオーナーが、サービスが共有され得ること、またはサービスから導出されたサービスデータが共有され得ることを示すときはいつでも、プライベート区画の設定は、変更され得る、またはパブリック区画にコピーされ得る(19308)。プライベート区画19314からパブリック区画19308へのデータの移動は、データをチェーン外メカニズムに追加することを含み得る。プライベートからパブリックへのデータの変更は、例えば、非集中型ネットワーク19302内の投票に参加するために非集中型データベース19306のコンセンサスの性質を使用することを含み得る。データをパブリックからプライベートに、またはその逆に変更するための他の技法は、中央システムから受信したコマンド、データの有効期限などを含み得る。これらの組み合わせを使用することができる。例えば、有効期限をポリシーに含めることができ、その後、ネットワーク内のデバイスのコンセンサスにより、ステータスをプライベートからパブリックに変更すべきであると判定される。
プライベート区画19314は、ネットワークオーナーによって所有されている他のノードに複製されてもよい。プライベート区画19314は、場合によっては、コンセンサスネットワークの他のメンバによって運営されている他のデータベースインスタンスへの複製が制限されることがある。共有区画は、許可され得る、および/または暗号化され得る。
ネットワークオーナーは、例えば、データオーナーであり得、共有区画19308を作成することによって、区画上の許可および暗号化は、ネットワークオーナーによって設定され得る。許可は、例えば、役割ベースであってもよいし、とりわけRADIUS/DIAMETERプロトコルベースであってもよい。役割ベースの許可は、特定のデータにアクセスするための特定の役割を有するネットワーク内の他のアクターを含み得る。RADIUSまたはDIAMETERベースは、例えば、許可制御メカニズムとしてインターネットによって使用される認証方法を指すことができる。暗号化はネットワークによって採用され得る。例えば、暗号化としては、公開鍵方式、秘密鍵方式、パスワード、パスフレーズ、トリプルデータ暗号化規格(DES)、Blowfish、Twofish、またはAESを挙げることができる。共有区画を用いて許可および暗号化を調整することによって、データオーナーは、データにアクセスすることを認可されている可能性があるネットワーク内の当事者を制御する能力を保持することができる。共有区画を使用して許可と暗号化を調整することによって、データオーナーはデータをチェーン外で格納することができる。
データのコピーは、識別された特権を含むノードに複製され得る。識別された特権を含むノードは、識別された特権をデータオーナーにいつでも失効させることができる。識別された特権の失効は、データオーナーによって共有されている将来のデータへのアクセスの損失、または履歴データに及ぶ特権の失効のいずれかをもたらす可能性がある。許可システムは、データのコピーを作成するデータコンシューマの能力を制御するために作成することができる。データのコピーを作成するデータコンシューマの能力を制限することには、役割が失効され、データコンシューマにデータのコピーを作成する権限がない場合に、以前に共有したデータへのアクセスを失効させる機能を含めることができる。
役割を付与したり失効させたりする能力は、制御プレーンによって処理され得る。制御プレーンは、コンセンサスネットワークの一部として動作してもよく、そのような役割およびデータへのアクセスは、デジタル通貨と引き換えに当事者間で許可され得る。デジタル通貨は、ピア間でデータを相互に共有するための合意であり得る。
図194は、一部の実施形態による、ネイティブ非集中型データベースを使用してコンセンサスネットワーク内に参加し、そのネットワーク内で動作するための例示的な方法19400のプロセスフロー図である。図194の方法19400は、図195に関して説明されるIoTデバイス19500によって実施することができる。ブロック19402において、デバイスは非集中型データベースネットワークに接続することができる。接続は、他のノードによる受け入れおよび信頼を黙示する可能性があるため、接続は、一部の例では参加と区別され得る。非集中型バイナリソフトウェアがインストールされ得る。データベースは、他のノードでの複製から制限され得るプライベートデータベース区画またはテーブルを作成することができる。これらの拠点の数、規模、および機能は、システムのオーナーまたはシステム開発者の裁量に任され得る。
ブロック19404において、システムは名前空間を発見することができる。名前空間は、例えば、他のネットワークを指すことがあり、他のネットワークは、非集中型データベースサービスを提供し得る。名前空間の発見は、例えば、位置ルックアップ、ネットワーク発見、デバイス発見などを通じて行われ得る。発見プロセスは自動化されていてもハードコードされていてもよい。ネットワークへの参加要求は、参加を試みるデバイスによって開始され得る。要求は、許可ガイドなどの構成体によって駆動され得る。ネットワークへの参加要求は、デバイスの既存のネットワーク上の既知のノードを介して行われてもよく、参加ノードは、クラスタの既知のノードを使用してクラスタに参加してもよい。どのようにして新しいノードをネットワークに参加させることができるかについての決定は、ネットワーク開発者が最初にネットワークを初期化するとき、またはそれより早いまたは遅い時に行うことができる。上述したように、ネットワーク開発者は、非集中型データベースクラスタ内の参加ノードに実装されたポリシーを通じてノードの許可に関する条件を設定することができる。参加者が、非集中型データベースソフトウェアの検証済みバージョンを実行している場合、ポリシーは、参加を要求している参加者を自動的に受け入れる。本明細書で説明するように、非集中型データベースソフトウェアの検証は、ソフトウェアがホワイトリストに載っていることを確認するために測定環境を使用して実行され得る。バージョンおよび有効性を確認するために、他の任意の数の技法も使用され得る。承認ポリシーは、新しいエンティティを承認または拒否するために投票を使用することができる。
新しいエンティティは、最初は非集中型データベースクラスタ内の権限が制限されている役割で参加することができ、また、時間が経つにつれて、エンティティの信頼度が高まるにつれて、エンティティはより信頼できるものになる可能性がある。ネットワーク開発者は、指定されたノードがネットワーク上の確認部になることを許可し得る。例えば、ネットワーク開発者は、ビットコインのようなブロックチェーンの確認部としてノードを指定できる。非集中型データベースクラスタに参加しようとしているノードが拒否された場合、そのノードはスタンドアロンデータベースとして動作し続けることができる。スタンドアロンデータベースは、スタンドアロンデータベースと同じセキュリティドメインおよび/またはネットワークに存在する中央集権型アプリケーションに役立つことができる。非集中型データベースクラスタに参加しようとしているノードは、1つまたは複数の名前空間を検出しようとし得る。ネットワーク開発者によって実装されたポリシーが許可する場合、非集中型データベースクラスタに参加しようとするノードは、複数のコンセンサスネットワークに参加することができる。
ブロック19406において、非集中型データベースクラスタに参加することを許可されたノードは、例えばネットワーク開発者によって指定された複数の共有区画およびテーブルを作成することができる。共有区画および共有テーブルに格納されているデータは、ネットワーク内で複製され得る。ネットワークは、冗長性のためにデータオブジェクトのいくつのコピーを格納することができるかを示すことができる。複製因子はグローバルであってもよいし、複製因子は、例えばデータオブジェクト型に基づいて異なって適用されてもよい。複製因子は、データの重要性に基づいて選択することも、データの重要性に応じて区画およびテーブルを少しずつ選択することもできる。格納されているデータがシャードになっていてもよい。共有データは、単一のノードが、特定のオブジェクトの再構成のための部分を完全なセットとして持たないように、ネットワーク内の参加ノードにわたって部分的に格納されたデータを指し得る。
ブロック19408において、ノードはネットワークの残りの部分と同期されてもよく、そのサービスをアドバタイズしてもよい。サービスのアドバタイズには、例えば、特定のポートまたはポート範囲をリッスンすることが含まれる。データベースを使用するクライアントは、様々なポートを介してデータベースサービスにアクセスできる。ネイティブ集中型データベースは、それが受信したデータを、データが、プライベート区画およびプライベートテーブル、または共有区画および共有テーブルに格納され得るように、経路指定することができる。クライアントは、データベースの非集中型の性質を知っていてもよく、クライアントは、非集中型データベースがプライベートにデータを格納することを要求し得る。クライアントは、データベースの非集中型の性質を知っていてもよく、クライアントは、非集中型データベースがパブリックにデータを格納することを要求し得る。非集中型ネットワークの参加者は、参加者のデータを1つの位置に保管し、後で参加者が共有したいデータと共有しないデータとを選択できる。プライベート区画または共有区画に格納されたデータは、データが格納される前にデータオーナーの指示に従って暗号化され得る。暗号化は、クライアントによって行われ得る、および/または、例えばデータオーナーがデータベースを信頼している場合には、非集中型データベース内に実装され得る。非集中型データベースは、IoTデータの共有市場を可能にし得る。
図195は、一部の実施形態による、非集中型データベースに参加してそれを動作させるためのIoTデバイス19500に存在し得るコンポーネントの一例のブロック図である。同様の番号が付けられた項目は、図3および図8に関して説明したとおりである。図8に関して説明したIoTデバイス800、および本明細書で説明される他のIoTデバイスに対して選択されたものとは異なるコンポーネントが、IoTデバイス19500に対して選択され使用されてもよいことに留意されたい。
大容量ストレージ808は、非集中型データベースに参加し動作するための複数のモジュールを含むことができる。大容量ストレージ808においてコードブロックとして示されているが、モジュールのうちのいずれも、例えば特定用途向け集積回路(ASIC)に組み込まれるなど、ハードワイヤード回路で完全にまたは部分的に置き換えられ得ることが理解されよう。
大容量ストレージ808は、デバイスを非集中型データベースのネットワークに接続するためのデバイスコネクタ19502を含み得る。デバイスは、非集中型データベースのネットワークへの接続に応答して非集中型データベースソフトウェアをインストールすることができる。デバイスは、非集中型データベースのネットワークへの接続に応答して共有データベース区画を作成することができる。
大容量ストレージ808は、非集中型データベースのノードの名前空間を発見するための名前空間発見部19504を含むことができる。デバイスは、非集中型データベースのノードの名前空間を発見することに応答して、非集中型データベースに参加するように要求することができる。デバイスは、非集中型データベースのノードの名前空間を発見することに応答して、非集中型データベースに受け入れられ得る。
大容量ストレージ808は、ノードによって受け入れられたことに応答して共有データベース区画を作成するための区画作成部19506を含み得る。共有データベース区画は、許可されたものと暗号化されたものうちの少なくとも一方であり得る。共有データベース区画に格納されたデータのコピーは、データをコピーするための第2のノードの権限を示す特権を提示する第2のノードに応答して第2のノードに複製されてもよい。デバイスは、共有データベース区画の作成に応答して、共有データベース区画内に格納するために共有ノード区画を複製することができる。
大容量ストレージ808は、サービスを非集中型データベースにアドバタイズするためのサービスアドバタイズ部19508を含み得る。大容量ストレージ808は、プライベートデータベース区画と共有データベース区画との間のサービスの実行の際に受信および生成されたデータを経路指定するためのデータルータ19510を含み得る。共有区画内のデータは、データが共有データベース区画に経路指定されたことに応答して、共有ノード区画内の格納のために複製することができる。デバイスは、ノードがデバイスの受け入れに投票したことに応答して、非集中型データベースへの受け入れを受信することができる。
図196は、一部の実施形態による、非集中型データベースに参加してそれを動作させるためのプロセッサ902を指示するためのコードを含む非一時的機械可読媒体19600のブロック図である。プロセッサ902は、バス904を介して非一時的機械可読媒体19600にアクセスすることができる。プロセッサ902およびバス904は、図9に関して説明したプロセッサ902およびバス904と同様の方法で実施することができる。非一時的機械可読媒体19600は、図8の大容量ストレージ808について説明したデバイスを含むこともできるし、光ディスク、USBメモリ(thumb drive)、または任意の数の他のハードウェアデバイスを含むこともできる。
非一時的機械可読媒体19600は、デバイスを非集中型データベースのネットワークに接続するようにプロセッサ902に指示するためのコード19602を含み得る。デバイスは、非集中型データベースのネットワークへの接続に応答して非集中型データベースソフトウェアをインストールすることができる。デバイスは、非集中型データベースのネットワークへの接続に応答して共有データベース区画を作成することができる。
非一時的機械可読媒体19600は、非集中型データベースのノードの名前空間を発見するようにプロセッサ902に指示するためのコード19604を含み得る。デバイスは、非集中型データベースのノードの名前空間を発見することに応答して、非集中型データベースに参加するように要求することができる。デバイスは、非集中型データベースのノードの名前空間を発見することに応答して、非集中型データベースに受け入れられ得る。
非一時的機械可読媒体19600は、ノードによって受け入れられたことに応答して共有データベース区画を作成するようにプロセッサ902に指示するためのコード19606を含み得る。共有データベース区画は、許可されたものと暗号化されたものうちの少なくとも一方であり得る。共有データベース区画に格納されたデータのコピーは、データをコピーするための第2のノードの権限を示す特権を提示する第2のノードに応答して第2のノードに複製されてもよい。デバイスは、共有データベース区画の作成に応答して、共有データベース区画内に格納するために共有ノード区画を複製することができる。
非一時的機械可読媒体19600は、サービスを非集中型データベースにアドバタイズするようにプロセッサ902に指示するためのコード19608を含み得る。非一時的機械可読媒体19600は、プライベートデータベース区画と共有データベース区画との間のサービスの実行に応答して受信および生成されたデータを経路指定するようにプロセッサ902に指示するためのコード19610を含み得る。共有区画内のデータは、データが共有データベース区画に経路指定されたことに応答して、共有ノード区画内の格納のために複製することができる。デバイスは、ノードがデバイスの受け入れに投票したことに応答して、非集中型データベースへの受け入れを受信することができる。
一部の実施形態では、本明細書の技法は、IoTオブジェクトにおけるアクセス制御を開示する。IoTシステムでは、関連するデバイスの制約があるためセキュリティが複雑になり、とりわけ、デスクトップ、ラップトップ、スマートフォンなど、制約の少ないデバイスで使用されているセキュリティシステムを実装できない場合がある。それほど複雑ではないパラメータを使用するアクセス制御を実装することは、セキュアな環境におけるIoTアプリケーションのセキュアな実装を強化し、IoTシステムの運用および採用を改善し得る。
IoTシステム設計では、オブジェクトとは、データモデルの記述と動作単位の物理的なインスタンス化とを指し得る。IoTシステムは、目標または結果を達成するために相互作用する複数のオブジェクトに関して説明することができる。オブジェクトは、複数の動作層から構成され得、その意味でオブジェクトの定義は再帰的であり得る。イントロスペクションなどのオブジェクト分解メソッドは、そのリーフノード属性への再帰を解決できる。IoTオブジェクトアクセスは、一部の場合において、少なくとも6つの層を有する階層化分解に従って理解でき、そして他の場合において、より多いまたはより少ない層が使用され得る。
図197は、一部の実施形態による、IoTオブジェクトにおけるアクセス制御のための論理分割19700の概略図である。一例では、アクセス制御のための論理的な区分は、呼び出し元の認可がアクセス要求を伴い得ることを示し得る。呼び出し元認可は、呼び出し元オブジェクト19704およびターゲットオブジェクト19706を識別するアクセス制御リスト(ACL)構造19702内に制限され得る。ACL構造19702は、作成、読み取り、更新、削除、および通知(CRUDN)許可19708が、階層化分解において任意の層に適用され得ることを示し得る。ACL呼び出し元オブジェクト19704およびACLターゲットオブジェクト19706は、同じオブジェクト参照型を有する構造体であり得るので、呼び出し元オブジェクト19704およびターゲットオブジェクト19706の粒度の範囲を階層化モデルに従ってそれぞれ指定する際に完全な柔軟性があり得る。CRUDNポリシー19708は、粒度の各層で意味を持ち得る。
呼び出し元オブジェクト19704は、呼び出し元が要求をしている特権を定義する認可構造を有するクレデンシャルを発行されてもよい。特権は、上記の階層化構造に従って定義され得る。要求を出したプラットフォーム、デバイス、収集、リソース、記録、またはプロパティは、認可セクションで指定され得る。
図198は、一部の実施形態による、IoTオブジェクトにおけるアクセス制御のための呼び出し元クレデンシャル19802とアクセス制御要求19804との間の論理分割19800の概略図である。呼び出し元の認可可19806は、アクセスの要求および結果として生じる許可19808を伴い得る。アクセスされるオブジェクトは、そのオブジェクトの物理性によってそのオブジェクトに課される固有の制限によって制約を受け得る。例えば、読み取り専用ストレージデバイス(ROM)は、書き込み動作を可能にする物理性を持たない。物理性はCRUDNを使用して表現できる。予想されるアクセスは、オブジェクトの物理性によって制限され得るため、アクセス要求は、要求された許可が物理性によって支配されると予想し得る。予想されるアクセスは、オブジェクト19810および許可19812を含む要求19804であり得る。オブジェクトの物理性によって制限されない場合、オブジェクトによるアクセス要求は、もしそれが尊重されるならば、デバイスを未定義または危険な方法で挙動させ得る。
図199は、一部の実施形態による、IoTオブジェクト内の層19904を使用したアクセス制御のためのオブジェクト機能19902の間の論理的分割19900の概略図である。IoTオブジェクトアクセスの第1の層はプラットフォーム層19906であり得る。プラットフォーム層は、計算、ネットワーキング、ストレージ、センシング、またはアクチュエーションの能力を含むコンピュータの物理的インスタンスを含むことができる。プラットフォームアクセス制御は、プラットフォーム識別子およびクレデンシャルに関して理解され得る。クレデンシャルは、例えば、クレデンシャルがアテステーションクレデンシャルとして機能することができるように、製造業者によって埋め込まれ得る、または構成または実装中にユニット内に格納され得る。プラットフォームクレデンシャルは、アクセス要求がデバイスクレデンシャル発行の条件であり得る場合、クレデンシャルなしでアクセス要求で検証することができる。プラットフォームクレデンシャルは、その物理性を含むプラットフォームプロパティを再アテステーションするために使用され得る。
IoTオブジェクトアクセスの第2の層は、デバイス層19908であり得る。デバイス層は、計算、ネットワーキング、ストレージ、センシング、またはアクチュエーションの能力を含むコンピュータの論理的インスタンスを含むことができる。デバイスアクセス制御は、デバイス識別子およびクレデンシャルに関して理解され得る。
IoTオブジェクトアクセスの第3の層は、収集層19910であり得る。収集層は、以下に開示されるように、1つまたは複数のリソースの論理構造を含み得る。アクセス制御は、型識別子、インターフェース定義、および構造を命名する権限IDに関して理解することができる。
IoTオブジェクトアクセスの第4の層は、リソース層19912であり得る。リソース層は、以下に開示されるように、1つまたは複数の記録の論理構造を含み得る。アクセス制御は、型識別子、インターフェース定義、および構造を命名する権限IDに関して理解することができる。
IoTオブジェクトアクセスの第5層は、記録層19914であり得る。記録層は、以下に開示されるように、1つまたは複数のプロパティの論理構造を含み得る。アクセス制御は、リソースおよび記録インデックスオフセットの観点から理解され得る。
IoTオブジェクトアクセスの第6層は、プロパティ層19916であり得る。プロパティ層は、例えば、データモデリング言語(DML)を使用して定義可能な任意の構造のアトミックデータ構造および/または複素データ構造を含み得る。例えば、アトミックデータ構造は、ストリング、数、および/または日付を含み得る。DMLは、例えば、受け入れ可能なデータフォーマット、構造、およびJSONスキーマなどのデータ値の制約に対する制限を取得するためのメタデータの構造を提供し得る。アクセス制御ポリシーは、作成、読み取り、更新、削除、および通知(CRUDN)のデータ構造ライフサイクルの観点から表現することができる。通知は、観察と通知とにさらに分けることができ、観察は、構造変更イベントの読み取り許可を推定し、通知は、別のオブジェクトへの書き込み許可を推定する。
アクセス制御リスト(ACL)評価は、呼び出し元セクションを支配および/または重複する呼び出し元オブジェクトの認可を検証するプロセスであり得る。ACL評価は、アクセスされている構造がターゲットセクションによって支配されおよび/または重複され得るプロセスであり得る。ターゲットセクション内の層の完全なセットが、アクセスされる構造と一致しない限り、ACLは適用が制限され得る。ACLが一致しないと、アクセスが拒否され得る。
図200は、一部の実施形態による、IoTオブジェクトにおけるアクセス制御のための例示的な方法20000のプロセスフロー図である。図200の方法20000は、図201に関して説明されるIoTデバイス20100によって実施することができる。プロセスフローは、ブロック20002で開始し得る。ブロック20002において、クレデンシャルが、呼び出し元エンティティに発行され得る。クレデンシャルは、セキュリティ要件に応じて、例えば、6層の認可構造を含むことができるが、4層などの他の認可構造を使用することもできる。ブロック20004において、オブジェクトエンティティは、ACLを用いてプロビジョニングされ得る。ACLは、ターゲットオブジェクトへの6層参照とCRUDNまたはCRUDON許可を指定できる。ブロック20006において、呼び出し元は、適切な接続インターフェースを介して認可クレデンシャルをオブジェクトに提示することができる。ブロック20008において、アクセス施行エンジン(AEE)は、供給者クレデンシャルを与えられたACLポリシーを適用することができる。
ブロック20010において、クレデンシャル認可が呼び出し元と重複するか否かに関する判定が行われ得る。否であり、クレデンシャル認可が呼び出し元と重複していない場合、プロセスフローはブロック20012に進み、アクセスは拒否される。
ブロック20014において、ターゲットが要求と重複するか否かに関する判定が行われ得る。否の場合、ターゲットは要求と重複しないため、プロセスフローはブロック20012に進み、アクセスが拒否され得る。
ブロック20016において、呼び出し元オブジェクト層識別情報の層が、クレデンシャルオブジェクト層識別情報と比較されて、一致があるか否かが判定され得る。否であり、呼び出し元オブジェクト層識別情報がクレデンシャルオブジェクト層識別情報と一致しない場合、プロセスフローはブロック200012に進み、アクセスが拒否され得る。呼び出し元オブジェクト層識別情報は、プラットフォーム層、デバイス層、収集層、リソース層、記録層、およびプロパティ層を含み得る。
ブロック20018において、ターゲットオブジェクト層識別情報の層を要求オブジェクト層識別情報と比較して、一致があるか否かが判定され得る。否であり、ターゲットオブジェクト層識別情報が要求オブジェクト層識別情報と一致しない場合、プロセスフローはブロック200012に進み、アクセスが拒否され得る。ターゲットオブジェクト層識別情報は、プラットフォーム層、デバイス層、収集層、リソース層、記録層、およびプロパティ層を含み得る。上記の判定結果が是である場合、ブロック20020において、アクセスはIoTオブジェクトについて許可され得る。
図201は、一部の実施形態による、IoTオブジェクトにおけるアクセス制御のためにIoTデバイス20100に存在し得るコンポーネントの例のブロック図である。同様の番号が付けられた項目は、図3および図8に関して説明したとおりである。図8に関して説明したIoTデバイス800、および本明細書で説明される他のIoTデバイスに対して選択されたものとは異なるコンポーネントが、IoTデバイス20100に対して選択され使用されてもよいことに留意されたい。
大容量ストレージ808は、IoTオブジェクトにおけるアクセス制御のための複数のモジュールを含み得る。大容量ストレージ808においてコードブロックとして示されているが、モジュールのうちのいずれも、例えば特定用途向け集積回路(ASIC)に組み込まれるなど、ハードワイヤード回路で完全にまたは部分的に置き換えられ得ることが理解されよう。
大容量ストレージ808は、呼び出し元エンティティにクレデンシャルを発行するためのクレデンシャル発行部20102を含み得、クレデンシャルは、複数の認可構造の層を含む。クレデンシャルは、6層の許可とすることができる。6層の許可は、プラットフォーム層、デバイス層、収集層、リソース層、記録層、およびプロパティ層を含むことができる。複数の層は、コンピュータの物理インスタンスを反映するためのプラットフォーム層を含むことができ、計算、ネットワーキング、ストレージ、センシング、およびアクチュエーションの能力のうちの少なくとも1つを含む。複数の層は、コンピュータの論理インスタンスを反映するためのデバイス層を含むことができ、計算、ネットワーキング、ストレージ、センシング、およびアクチュエーションの能力のうちの少なくとも1つを含む。層の数は、リソースの論理構造に対する収集層を含むことができ、リソースは記録のための論理構造を含み、記録はプロパティの論理構造を含み、プロパティはアトミックデータ構造および複合データ構造のうちの少なくとも1つを含む。プロパティは、複素データ構造であり、複素データ構造は、データモデリング言語を使用して定義可能な構造に対するものであり得る。プロパティは、アトミックデータ構造を含むことができ、アトミックデータ構造は、文字列、数字、または日付のうちの少なくとも1つであり得る。クレデンシャルは、製造業者による設置を示すことができる。
大容量ストレージ808は、ターゲットオブジェクトへの参照および許可を指定するアクセス制御リストをオブジェクトエンティティにプロビジョニングするためのオブジェクトエンティティプロビジョニング部20104を含み得る。大容量ストレージ808は、認可クレデンシャルをオブジェクトエンティティに提示するためのクレデンシャル提示部20106を含み得る。作成、読み取り、更新、削除、および通知(CRUDN)ライフサイクル通知に基づくオブジェクトデータの物理的性質によってオブジェクトに課される制限によって、オブジェクトエンティティに対する認可クレデンシャルが制限され得る。大容量ストレージ808は、クレデンシャルが呼び出し元エンティティと重複するか否か、ターゲットオブジェクトは要求と重複するか否か、複数のデバイス層識別情報が複数のクレデンシャル層識別情報と一致するか否か、および複数のターゲット層識別情報が複数の要求層識別情報と一致するか否かの比較に基づいてアクセスがIoTデバイスに許可されるか否かを判定するためにアクセス制御リストポリシーを適用するアクセス制御リストポリシー適用部20108を含み得る。
図202は、一部の実施形態による、IoTオブジェクト内のアクセス制御のためにプロセッサ902に指示するためのコードを含む非一時的機械可読媒体19600のブロック図である。プロセッサ902は、バス904を介して非一時的機械可読媒体20200にアクセスすることができる。プロセッサ902およびバス904は、図9に関して説明したプロセッサ902およびバス904と同様の方法で実施することができる。非一時的機械可読媒体19600は、図8の大容量ストレージ808について説明したデバイスを含むこともできるし、光ディスク、USBメモリ(thumb drive)、または任意の数の他のハードウェアデバイスを含むこともできる。
非一時的機械可読媒体20200は、呼び出し元エンティティにクレデンシャルを発行するようにプロセッサ902に指示するコード20202を含み得、クレデンシャルは、複数の認可構造の層を含む。クレデンシャルは、6層の許可とすることができる。6層の許可は、プラットフォーム層、デバイス層、収集層、リソース層、記録層、およびプロパティ層を含むことができる。複数の層は、コンピュータの物理インスタンスを反映するためのプラットフォーム層を含むことができ、計算、ネットワーキング、ストレージ、センシング、およびアクチュエーションの能力のうちの少なくとも1つを含む。複数の層は、コンピュータの論理インスタンスを反映するためのデバイス層を含むことができ、計算、ネットワーキング、ストレージ、センシング、およびアクチュエーションの能力のうちの少なくとも1つを含む。層の数は、リソースの論理構造に対する収集層を含むことができ、リソースは記録のための論理構造を含み、記録はプロパティの論理構造を含み、プロパティはアトミックデータ構造および複合データ構造のうちの少なくとも1つを含む。プロパティは、複素データ構造であり得、複素データ構造は、データモデリング言語を使用して定義可能な構造に対するものであり得る。プロパティは、アトミックデータ構造を含むことができ、アトミックデータ構造は、文字列、数字、または日付のうちの少なくとも1つであり得る。クレデンシャルは、製造業者による設置を示すことができる。
非一時的機械可読媒体20200は、ターゲットオブジェクトへの参照および許可を指定するアクセス制御リストをオブジェクトエンティティにプロビジョニングするようにプロセッサ902に指示するためのコード20204を含み得る。非一時的機械可読媒体20200は、オブジェクトエンティティに認可クレデンシャルを提示するようにプロセッサ902に指示するためのコード20206を含み得る。場合によっては、作成、読み取り、更新、削除、および通知(CRUDN)ライフサイクル通知に基づくオブジェクトデータの物理的性質によってオブジェクトに課される制限によって、オブジェクトエンティティに対する認可クレデンシャルが制限され得る。非一時的機械可読媒体20200は、クレデンシャルが呼び出し元エンティティと重複するか否か、ターゲットオブジェクトは要求と重複するか否か、複数のデバイス層識別情報が複数のクレデンシャル層識別情報と一致するか否か、および複数のターゲット層識別情報が複数の要求層識別情報と一致するか否かの比較に基づいてアクセスがIoTデバイスに許可されるか否かを判定するためにアクセス制御リストポリシーを適用するようにプロセッサ902に指示するためのコード20208を含み得る。
一部の実施形態による自己管理デバイスおよびシステムは、それら自体およびそれらの特徴を、それら自体および他のデバイスに説明することができる。例えば、本明細書で説明されているように、イントロスペクションを使用することができる。イントロスペクションは、機械可読であるデータ記述言語(DDL)、例えばとりわけJSONスキーマまたはXMLが、問い合わせ(interrogation)またはアドバタイズの下でデバイスの意味分解をカプセル化する、セルフアウェアネスの一形態である。本明細書で使用されているように、自己管理デバイスおよびシステムはセルフアウェアであり、デバイスの性能を最適化するか、またはそれが損傷したとき、もしくはリソースが不足しているときを認識することができる。さらに、自己記述型モジュールは、データシートを読み、そのモジュールのための特定のコードを開発するタスクを自動化することによって、人の入力および労力を減らすことができる。例えば、自己記述型トランスデューサは、データシートにあるデータを記述する統合メモリを含むことができる。
データシート情報としては、製造業者の詳細、較正パラメータ、信号調整、および信号処理の要件を挙げることができる。データシートは、相互作用のためのノードメタモデル(NMM)をさらに記述することができる。メタモデルでは、ノードは、ノードID、プロパティのセット、ノードが送信するコマンドおよびノードが受信するコマンドなどのコマンドのセット、ならびにコマンドパラメータのセットを含むことができる。パラメータは、識別子、編集子、および初期化子によって修飾できる。編集子は、プロパティおよび/またはコマンドパラメータに適用できる。ノードは、独自のエディタを有し得る。従って、ノードメタモデルでは、データシート情報は、プロパティ情報に加えてコマンド相互作用セマンティクスを含むことができる。
NMMは、自動イントロスペクションを容易にするDDLを使用して表現可能であり得る。従って、ノードと相互作用するIoTデバイスは、本明細書でさらに詳述するように、データシート内の変化に動的に反応することができる。データシートの相互作用の両側で同じNMMの語彙が認識されると、IoTデバイスのシステムは、デバイスのドライバやシステムソフトウェアのインストールまたは更新をせずに、デバイスの挙動および能力の変化を動的に利用できる。従って、データシート上の情報にアクセスするための特定のコードを手作業で開発する必要なしに、自己記述型トランスデューサをマイクロコントローラまたはIoTデバイスと共にプラグアンドプレイ構成で使用することができる。自己記述型デバイスは、ネットワークでプラグアンドプレイすることもでき、ネットワークでは、自己記述型デバイスは、リソースおよび要件をアドバタイズする。
さらに、トランスデューサ、無線機、エネルギーストレージ、環境発電およびマイクロコントローラを含む自己記述型外部モジュールは、期限切れまたは損傷したコンポーネントを処分し、長寿命のコンポーネントを再利用することによって無駄を減らすために使用され得る。例えば、外部モジュールは、とりわけ、外部センサもしくはアクチュエータ、通信モジュール、環境発電コンポーネントもしくは外部バッテリ、または外部メモリを含み得る。センサまたは無線機などの外部モジュールは有効期限を有することがあり、その有効期限では精度または機能が低下すると予測され得る。交換可能な外部モジュールがIoTデバイスで使用される場合、有効期限に達すると外部モジュールが交換され、IoTデバイスの残りの部分を再構成して再利用することができる。経年劣化または機能していない外部モジュールの交換または取り外し、および残りのIoTデバイスと機能している外部モジュールの再構成により、IoTデバイス全体の寿命を延ばすことができる。
単一のIoTデバイスアセンブリでは、寿命は、最初に故障するコンポーネントの寿命に結び付けられ得る。しかしながら、一部の実施形態によれば、本開示の技法を使用して、寿命が最も短いコンポーネントの寿命を超えて、センサノード全体を自動的に修復するか、または別の目的のために再構成することができる。例えば、IoTデバイスは、寿命の終わり近くで外部モジュールを非アクティブ化し、残りのモジュールに基づいて異なるタスクを実行するように再構成することができる。
さらに、コンポーネントが非アクティブ化された後は、自己記述型IoTモジュール式デバイスの機能が完全に異なり得る。例えば、欠陥のある外部モジュールを別の機能のために機能している外部モジュールと交換することができ、それにより、IoTデバイス全体の機能が変化する。センサノード上の無線モジュールは、新しい、低電力、または長距離の無線リソースに交換できる。システムゲートウェイが新しい無線プロトコルにアップグレードされるとセンサノードが再構成される可能性があるため、これはセンサノードの耐用年数を延ばし得る。さらに、自己記述型IoTデバイスは、これらの複数のモジュールからの値を相互参照し、追加の外部モジュールを使用することによってより較正されたデータを出力することができる。機械可読DDLが相互参照され自己記述されたデバイスに転送可能であるセマンティックマークアップを含むとき、これは容易にされ得る。従って、セマンティックマークアップを適用する別個の手動の段階を回避することができる。IoT較正パラメータにより、追加の処理で生データを処理しなくても、プロセッサでこれらの較正された値を直接読み取って適用できる。
共通のプロトコルは、それらのリソースおよび要件を自己記述することができるデバイスおよびモジュールによって使用され得る。これらの構成では、外部モジュールは、多くのデバイスに統合することができる。デバイスは、デバイス能力と接続されているコンポーネントの要件との間の競合にフラグを立てることができる。
図203は、一部の実施形態による、リソースおよび自己記述型ハードウェアの要件をマッピングするためにモノのインターネット(IoT)デバイスによって使用される例示的な方法20300のプロセスフロー図である。図203の方法20300は、図204に関して説明されるIoTデバイス20400によって実施することができる。方法20300は、図8に関して説明したシステム802を使用して実行することができる。方法20300は、IoTデバイスがブートするとブロック20302で開始することができる。
ブロック20304において、IoTデバイスは、IoTデバイスの制御下にあるリソースをエニュメレーションすることができる。一例では、リソースは、ハードウェアコンポーネントとすることができ、電源、バッテリ、またはとりわけ、ソーラーパネル、風力タービン、または水力タービンを含む環境発電システムなどのエネルギー源を含むことができる。IoTデバイスのハードウェアコンポーネントは、例えば、プロセッサ、コンテキストセンサ、コンテキストアクチュエータ、信号調整回路、ストレージ、およびメモリを含み得る。リソースハードウェアコンポーネントは、例えば、集積回路間(I2C)、シリアルペリフェラルインターフェース(SPI)、ユニバーサル非同期受信機/送信機(UART)、または統合無線機を含む統合通信を含み得る。一部の実施形態によるIoTデバイスのコンポーネントは、図204に関してさらに論じられる。
ブロック20306において、一部またはすべての外部モジュールがエニュメレーションされたか否か、および外部モジュールの要件に関する詳細に関する判定が行われる。すべての外部モジュールが識別されていない場合、ブロック20308において、外部モジュールの要件が識別され、外部モジュールがエニュメレーションされる。外部モジュールをエニュメレーションすることにより、IoTデバイスは、外部モジュールを参照し、外部モジュールの要件にアクセスできる。ブロック20310において、IoTデバイスのリソースが外部モジュールの要件を超えているか否かに関する判定が行われる。要件は、例えば、モジュール電力、通信能力、通信速度、メモリ要件、ならびに他のIoTデバイスおよびモジュールの能力を含み得る。
外部モジュールの要件がそれ自体でIoTデバイスのリソースを超える場合、ブロック20312において、IoTデバイスは、非アクティブ化するように信号を外部モジュールに送信する。ブロック20314において、IoTデバイスは、可視または可聴警報を作動させることができる。警告は、発光ダイオード(LED)、可聴音、またはその両方の作動であり得る。LEDなどの警告は、指示された外部モジュールの要件がリソースを超えたことをユーザに知らせることができる。例えば、外部モジュールとして動作する高スループットマイクロホンは、高スループット処理がマイクロコントローラにおいて実行可能ではないかもしれないので、単純なマイクロコントローラのリソースを超え得る。ローカル警告に加えて、メッセージがIoTデバイスからマスタデバイスに送信され得る。
IoTデバイスのリソースが外部モジュールの要件を満たすのに十分である場合、ブロック20316において、IoTデバイスは、それ自体のリストを更新してその残りのリソース、ならびにそのIoTデバイスから動作する一部またはすべての外部モジュールの全要件のリストを含むことができる。
プロセスフローはブロック20306において再開し、IoTデバイスに接続されている一部またはすべての外部モジュールが識別されエニュメレーションされているか否かの判定が行われる。外部モジュールが識別されてエニュメレーションされると、外部モジュールはリソースにマッピングされ得る。例えば、外部モジュールとして使用されるガスセンサは、データを正確に報告するために温度および湿度の測定値を必要とする場合もある。しかしながら、IoTデバイスは、温度センサおよび湿度センサを持たない場合もある。ガスセンサが取り付けられており、温度および湿度の測定値を使用していることを検出したことに応答して、IoTデバイスは、これらの要件を含む要求をマスタデバイスに送信することができる。次いで、マスタデバイスは、温度センサおよび湿度センサなどの要求された外部モジュールが、マスタデバイスによって直接または別の接続されたIoTデバイスを介してアクセス可能であるか否かを判定することができる。
温度または湿度センサが、例えば外部モジュール内のマスタデバイスによって発見された場合、外部モジュールは、IoTデバイスの制御下にあるように再構成され得る。測定が有用であるために十分に近接している限り、センサは、IoTデバイスのローカルにあってもよいし、IoTデバイスの外部のモジュール内にあってもよい。例えば、IoTデバイスが湿度および温度の情報を必要としている場合、マスタデバイスはIoTデバイスと同じ部屋または近くの廊下にある温度センサまたは湿度センサにアクセスし再構成することができる。IoTデバイスに対するこれらの外部モジュールは、IoTデバイスの制御下にあるように構成され得る。これらのセンサのリソースを使用して、生データを返すのではなく、IoTデバイス上のガスセンサを温度および湿度の変数に対して較正できる。
別の観点からは、ガスセンサなどの外部モジュールが電力、通信、およびメモリの要件を満たす場合、ガスセンサが温度または湿度データにアクセスできず、これらの要因によって較正されているデータを提供できない場合でも、外部モジュールをシステムに追加することができる。しかしながら、IoTデバイスにガスセンサコンポーネントを追加することは、ガス検知を必要とする様々な構成において他のIoTデバイスによって使用され得る。
外部モジュールが識別されエニュメレーションされると、ブロック20318において、組み合わされたモジュールおよびIoTデバイスの和の全要件が、IoTデバイスの全リソースを超えるか否かに関する判定が行われる。本明細書で使用されるIoTデバイスの全リソースは、一般に、IoTデバイスのリソースに加えて、IoTデバイスがマスタデバイスにメッセージを送ることなくアクセスすることができる任意の外部リソースを指す。IoTデバイスのリソースは、IoTの能力に反映され得る。一例では、これらのリソースは、IoTデバイスおよびそれに接続された外部モジュールの需要に基づいて、IoTデバイスに、またはいくつかの相互接続されたIoTデバイス間に割り当てられ得る。
IoTデバイスの全リソースが全モジュール要件を超えている場合、ブロック20320において、通信モジュールを除いて、外部モジュールを無効にすることができる。ブロック20322において、IoTデバイスは、通信モジュールを使用して、全リソースの不足をマスタデバイスに通知することができる。この通知の受信に応答して、マスタデバイスは、リソースのプールを特定のIoTデバイスに再構成することによって、それがどのリソースを再割り当てし得るかを判定し得る。あるいは、通知の受信に応答して、マスタデバイスは、第2のIoTデバイスがそれらを使用しながら第1のIoTデバイスが別のタスクまたは目的のために再デプロイされ得るように、IoTデバイスの外部モジュールを再構成し得る。
ブロック20324において、LED、音声信号、またはその両方をIoTデバイスによって作動させて、外部モジュールが非アクティブ化されているというローカルの指示を提供することができる。ブロック20326において、マスタデバイスは、外部モジュールをIoTデバイスの制御下に置くことによって、欠けている要件を満たすための構成を識別することができる。較正の更新は、IoTデバイスに送信され適用される。IoTデバイスに新しい構成を適用することは、IoTデバイスに利用可能なリソースを変更することを含み得る。IoTデバイスに新しい設定を適用することは、外部モジュールがIoTデバイスの制御下にあるか否かを変更することを含み得る。外部モジュールがIoTデバイスから取り外された場合、IoTデバイスは、残りの外部モジュールの残りの要件を満たすことができるか否かを判定するために別のチェックを行うことがある。再構成に応答して、IoTデバイスリソースが変更された場合、外部要件の合計が変更された場合、または再構成によってIoTデバイスが実行しようとする機能が変更された場合、IoTデバイスはその外部モジュールをサポート可能であり得る。ブロック20328において、そしてマスタデバイスによる再構成の後、IoTデバイス上の外部モジュールの新しい構成について新しい全要件が計算され得る。
ブロック20318において、IoTデバイスの全リソースが全モジュール要件を超えていない場合、ブロック20330において、IoTデバイスの予想寿命は、コンポーネントの寿命を比較するアルゴリズムを使用して計算することができる。例示的なアルゴリズムでは、IoTデバイスの予想寿命は、紛失または非アクティブ化された場合に予想どおりに機能するためにIoTデバイスの再構成をもたらし得るコンポーネントの最も短い残り寿命に一致するように設定され得る。
ユーザまたはユーザアカウントに関連付けられているIoTモジュール式デバイスは、サービスレベル合意(SLA)で指定されているサービスレベルが含まれ得る。SLAには、IoTデバイスの合意された機能、構成、予想される寿命、予想される機能、予想される性能、および予想されるデバイスの可用性が含まれる。ブロック20332において、IoTは、デバイスの寿命が特定のユーザまたはアカウントについてSLAに指定された寿命より短いか否かを判定する。そうである場合、プロセスフローはブロック20322に進み、マスタデバイスに通知される。デバイスの残りの寿命がSLAで規定されているよりも短い場合、現在の構成のIoTデバイスはSLAの要件を満たさない。ブロック20332でマスタデバイスが通知されると、SLAを満たす外部モジュールを有する新しい構成が追加され得る。
一例では、IoTデバイスの構成は、SLAで指定されたセンサ寿命を満たすためにデバイスの寿命を延ばす1つまたは複数のモジュールを含み得る。例えば、IoTデバイスで利用可能な外部モジュールの寿命は、SLAで指定されている寿命と比較できる。寿命がSLAで指定されたものより短い場合、IoTは、リストされたSLA寿命値を満たす外部デバイスの新しい構成をマスタデバイスに要求することができる。
しかしながら、デバイスの寿命がSLAに記載された寿命を超える場合、ブロック20334において、その現在の構成においてサービス品質(QoS)測定がIoTデバイスについて存在するか否かに関する判定が行われ得る。QoSがIoTデバイスおよびその外部モジュールについて存在しない場合、ブロック20336において、IoTデバイスに関するQoSメトリクスが生成され得る。これらのQoSメトリクスが生成されると、またはQoSメトリクスが既にIoTデバイスに存在していた場合、ブロック20338において、IoTデバイスは、QoSがSLA内の指定されたQoS閾値よりも小さいか否かを判定することができる。
QoSがSLAで指定された要求された閾値より小さければ、ブロック20340において、IoTは、QoSがSLAで要求されたものより低いことをマスタデバイスに通知し得、QoSを変更するために必要な1つまたは複数の外部モジュールを識別し得る。ブロック20342において、IoTデバイスがQoSを満たしていないことをIoTデバイスにローカルに示すために、LEDまたは音声などの可視信号または音声信号を作動させることができる。ブロック20344において、IoTは、QoS測定値がSLAの要件に一致するように、追加の、交換用の、またはより少ない外部モジュールのいずれかで更新された構成を受信することができる。プロセスフローはブロック20334に進み、更新された構成に基づいて新しいQoSが見つけられる。
一例では、IoTデバイスのQoSは、外部モジュールの加算、減算、および置換によって変更され得る。これらの変更により、SLAで指定されたQoSよりも低いQoSが発生する可能性がある。例えば、IoTデバイス通信モジュールについてIoTデバイス上に過去のQoSが存在しない場合、QoSはそのデバイスに基づいてテストされ得る。あるIoTデバイス上の通信モジュールに対するQoSは、他の外部モジュールに対して異なる構成を有する別の同じIoTデバイス上の通信モジュールに対するQoSとは異なり得る。
この例では、通信モジュールのQoSがSLAで指定された閾値を下回ると、マスタデバイスはIoTデバイスによって通知され、新しい通信構成に対する要求が行われ得る。構成に対する更新がマスタデバイスによって許可された場合、更新された構成に対する新しいQoSを評価し見つけ出すために新しいQoSテストが実行され得る。QoSがSLAにリストされた閾値以上であるとき、ブロック20334において、プロセスは、IoTデバイスの現在の構成において外部モジュールの能力を利用するIoTデバイス上でアプリケーションを開始することによって終了する。
一例では、IoTおよび特定の外部モジュールのセットを使用するアプリケーションの後に、IoTデバイスの構成を解散し、他のIoTデバイスとの再構成のためにIoTデバイス制御から外部モジュールを除去することができる。
さらに、自己記述型ハードウェアは、本明細書で説明されるノードメタモデルを組み込んでもよく、それが受け入れるコマンドに対するパラメータとしてサービスレベル合意(SLA)をキャプチャしてもよい。例えば、パラメータは、コマンドを達成するために利用される予想電力を指定してもよく、編集子は、デバイス電源の予想寿命について予想SLA閾値に適応するために利用される電力を調整し得る。NMMおよびこれらのSLA規約を使用して、一部の実施形態によるIoTデバイスは、別個のドライバまたはシステムソフトウェアの更新を追加することなく、本明細書で説明される機能をサポートおよび実行することができる。
図204は、一部の実施形態による、リソースおよび自己記述型ハードウェアの要件をマッピングするためにIoTデバイス20400に存在し得るコンポーネントの一例のブロック図である。同様の番号が付けられた項目は、図8において説明したとおりである。
上でも示したように、図8を参照すると、大容量ストレージ808は、本明細書で説明されるグループ作成機能を実施するための複数のモジュールを含むことができる。大容量ストレージ808においてコードブロックとして示されているが、モジュールのうちのいずれも、例えば特定用途向け集積回路(ASIC)に組み込まれるなど、ハードワイヤード回路で完全にまたは部分的に置き換えられ得ることが理解されよう。大容量ストレージ808は、IoTデバイスによって制御されるリソースハードウェアコンポーネントを識別するためのリソースハードウェアコンポーネント識別子20402を含むことができ、リソースハードウェアコンポーネントは能力閾値を有する。一例では、リソースハードウェアコンポーネントは、電源、処理リソース、統合通信コンポーネント、コンテキストセンサ、およびコンテキストアクチュエータ、信号調整回路、メモリリソース、またはストレージリソースのうちの少なくとも1つを含み得る。本明細書で使用される場合、能力閾値は、一般に、リソースハードウェアコンポーネントと外部モジュールとの間の、一緒に機能する最小能力を示す、最小機能的互換性を指す。本明細書で使用される能力閾値はまた、リソースハードウェアコンポーネントと外部モジュールとの間の、外部モジュールの最高能力で機能する能力を示す、完全な互換性を含んでもよい。
指示受信部20404は、外部モジュールから受信した、外部モジュールハードウェア要件の指示を処理することができる。一例では、外部モジュールは、IoTデバイスの指示で使用するために第1のリソースハードウェアコンポーネントと共にプールされるモジュールリソースを含む。
外部モジュール比較部20406は、外部モジュールハードウェア要件を、IoTデバイスのリソースハードウェアコンポーネントの能力閾値と比較し得る。非アクティブ化送信機20408は、リソースハードウェアコンポーネントの能力閾値を満たさない外部モジュールハードウェア要件に応答して、外部モジュールに非アクティブ化信号を送信する。
図205は、一部の実施形態による、実行時に、リソースおよび自己記述型ハードウェアの要件をマッピングするようにプロセッサに指示する命令を含む、非一時的機械可読媒体20500のブロック図である。同様の番号が付けられた項目は、図9において説明したとおりである。
非一時的機械可読媒体20500は、IoTデバイスによって制御されるリソースハードウェアコンポーネントを識別するようにプロセッサ902に指示するためのコード20502を含むことができ、リソースハードウェアコンポーネントは能力閾値を有する。本明細書で使用される場合、能力閾値は、一般に、リソースハードウェアコンポーネントと外部モジュールとの間の、一緒に機能する最小能力を示す、最小機能的互換性を指す。能力閾値はまた、リソースハードウェアコンポーネントと外部モジュールとの間の互換性を含んでもよい。これは、外部モジュールの最高の能力で機能する能力を示し得る。
非一時的機械可読媒体20500は、外部モジュールから受信した、外部モジュールハードウェア要件の指示を処理するようにプロセッサ902に指示するためのコード20504を含み得る。非一時的機械可読媒体20500は、外部モジュールハードウェア要件を、IoTデバイスのリソースハードウェアコンポーネントの能力閾値と比較するようにプロセッサ902に指示するためのコード20506を含み得る。非一時的機械可読媒体20500は、リソースハードウェアコンポーネントの能力閾値を満たさない外部モジュールハードウェア要件に応答して、外部モジュールに非アクティブ化信号を送信するようにプロセッサ902に指示するコード20508を含み得る。
非一時的機械可読媒体20500は、実行されると、リソースハードウェアコンポーネントの能力閾値を満たさない外部モジュールハードウェア要件に応答して、要求をマスタデバイスに送信するようにプロセッサに指示する命令を含み得、第2のリソースハードウェアコンポーネントを要求するマスタデバイスは、IoTデバイスによって制御されるように割り当てられる。非一時的機械可読媒体20500は、IoTデバイスの制御下にある第2のリソースハードウェアコンポーネントを含むことができ、第1のリソースハードウェアコンポーネントおよび第2のリソースハードウェアコンポーネントは、能力閾値が第1のリソースハードウェアと第2のリソースハードウェアとの能力閾値の和であるようにプールされ得る。
コンピュータ可読媒体に格納された実行された命令に基づいて、満たされていない能力閾値を示し、可視インジケータを作動させる指示が送信され得る。非一時的機械可読媒体20500は、実行されると、能力閾値を満たすことに応答して、IoTデバイスの制御下に外部モジュールを置くようにプロセッサに指示する命令を含み得る。
非一時的機械可読媒体20500は、実行のために追加のコードブロックを含み得る。このコードは、外部モジュールの寿命がIoTデバイスの動作寿命より短いことに応答して使用され、更新された外部モジュールに対する要求を送信し得る。このコードは、リソースハードウェアコンポーネントの寿命がIoTデバイスの動作寿命より短いことに応答して使用され、プロセッサは、更新されたリソースハードウェアコンポーネントに対する要求を送信する命令を送信され得る。
上述のように、モノのインターネット(IoT)は、任意のモジュールがプラグアンドプレイ構成で使用されてもよく、共通の物理インターフェースを介して他の任意のデバイスで使用されてもよい状態に進んでもよい。この構成では、モジュールは、共通の相互運用性プロトコルを使用して任意のデバイスと相互運用可能であり得る。しかしながら、IoTデバイスは、モジュールまたはデバイスが接続されるまで、モジュールまたはデバイス間でアプリケーションを実装するためのエネルギーコストを知らない場合がある。本明細書で使用されるとき、アプリケーションは、エネルギーを消費する可能性があるコンピューティングハードウェアが実行することができる、アルゴリズム、演算、サブルーチン、ソフトウェア、または他の任意の動作を含むことができる。
例えば、コイン型電池式IoTデバイスでは、Bluetooth(登録商標)low energy(BLE)無線機を含むモジュールをWi-Fi(登録商標)無線機モジュールに置き換えることができる。Wi-Fi(登録商標)無線機は、IoTデバイスと正常にインターフェース可能であり得るが、1時間以内にIoTデバイスのバッテリを消耗させ、IoTデバイスが使い物にならなくなり得る。本明細書で説明されるように、IoTデバイスは、アプリケーションが処理するのに必要とされるエネルギーを計算し、モジュールがあまりにも多くの電力を使用する可能性がある場合に警告を発することが可能であり得る。エネルギー効率の悪いアプリケーションは、アプリケーションが電力を消耗するモジュールとあまりにも頻繁に通信または依拠しているか否か、またはアプリケーションが低電力スリープモードを実装していない場合などの特性によって識別され得る。
アプリケーションのエネルギー要件は、計算ツールを使用して、接続されているハードウェアに従って計算できる。計算ツールは、IoTデバイスの電源投入時、モジュールの追加時または除去時、またはIoTデバイスが自己管理型の場合は内部要求によって、またはマスタデバイスがデバイスを管理する場合は外部要求によってアプリケーションが更新されるときに、IoTデバイス上で使用され得る。計算ツールは、エンドノードなどのスレーブデバイスからの新しい構成の要求に続いて、ゲートウェイなどのマスタデバイス上で使用することができる。計算ツールはまた、ソフトウェアの更新が実施される前の事前検証方法としてマスタデバイス上で使用され得る。計算ツールはまた、サービスレベル合意(SLA)で指定された最小パラメータの違反を識別することができるデプロイ前シミュレーションツールの一部であり得る。
構成最適化プロセスは、計算ツールの使用によって支援され得る。例えば、計算ツールは、アプリケーション設定またはデバイス設定を操作してデバイスエネルギー効率を改善する構成を識別することができるデプロイ前シミュレーションツールの一部として使用され得る。さらに、モジュールまたはデバイスをよりエネルギー効率的にするものを判定することは、モジュールまたはデバイスの寿命を延ばすことができるアプリケーションの提案を提供することができる。
計算ツールは、デバイスおよびモジュールにわたる共通のプロトコルに従って、リソース、要件、およびアプリケーションを自己記述することができるデバイスおよびモジュールに対処することができる。本明細書に開示されるように、計算ツールは、例えば、見積もりを行う際に使用するための測定値、特定のエネルギー消費量などを提供するためにモジュールの履歴エネルギー使用量を識別することによってモジュールのデフォルトエネルギー使用量を識別し得る。例えば、3Gモジュールの定格エネルギー消費は、モジュールの基地局への近接度に依存し得る。
計算ツールは、テストされている様々なハードウェア構成間での様々なエネルギー使用量を考慮に入れることができる。1つの例では、計算ツールは、分解可能なタスクで書かれたアプリケーションに依拠している。ツールは、モジュール上のアプリケーションのエネルギー使用量を測定することに依拠することができ、モジュールは、モジュール上で実行することができるタスクに対するそのエネルギー使用量を自己記述することができる。モジュールがエネルギー消費量を報告することができるタスクの例は、とりわけ、メッセージの送信、センサの読み取り、およびLEDへの電力供給を含む。
図206は、一部の実施形態による、リソースおよび自己記述型ハードウェアの要件をマッピングするためにモノのインターネット(IoT)デバイスによって使用される例示的な方法20600のプロセスフロー図である。図206の方法20600は、図207に関して説明されるIoTデバイス20700によって実施することができる。方法20600は、図8に関して説明したシステム802を使用して実行することができる。方法20600は、IoTデバイスがブートするとブロック20602で開始することができる。
ブロック20604において、計算ツールは、デバイスがネットワークに有線ネットワークによって接続されているか無線ネットワークによって接続されているかを判定する。有線ネットワークで接続されている場合は、ローカルデバイスのエネルギー管理を目的として電力要件を計算する必要はない。有線の場合、ブロック20606において、計算ツールは、信号を送信してデバイス上でアプリケーションを開始することができる。しかしながら、一部の例では、デバイスが有線ネットワークを使用する場合、計算ツールは依然として使用され得る。たとえそれらのモジュールが無線でなくても、デバイスが、グラフィック処理ユニット(GPU)などの多くのエネルギーを消費する他の種類のモジュールを含む場合、これは重要であり得る。
デバイスが有線ではないと計算ツールが判定した場合、ブロック20608において、デバイスのコアに電力を供給している電力リソースがエニュメレーションされる。これは、例えば、電源の数、電源の種類、電源に含まれる電力の測定値、コアデバイスのためのエネルギー源、バッテリ容量、およびエネルギー収穫能力、およびコアデバイスによるエネルギー消費の識別を含み得る。
ブロック20610において、計算ツールは、外部モジュールの電力要件をエニュメレーションする。本明細書で論じられるように、外部モジュールの電力要件のエニュメレーションは、例えば、外部モジュールのベースラインエネルギー消費、外部モジュールのフルパワーエネルギー消費などに注目することを含み得る。注目されるベースラインエネルギー消費量は、デバイスがアプリケーションの実行中にデバイスが電力供給している可能性がある各周辺モジュールまたは追加モジュールについて判定され得る。計算ツールは、外部モジュールについてのエネルギー消費量の範囲、エネルギー消費量の平均、および最大エネルギー消費量を判定および識別することができる。計算ツールは、外部モジュールに格納されているか、または中央ノードに格納されており、外部モジュールに関連付けられているエネルギー使用の仕様を識別することができる。上述のように、計算ツールは、外部モジュールがあるシステム上で動作し、自己記述型であり、そのモジュール上の特定の動作に対して予想されるエネルギー使用量を自己記述することができる。
ブロック20612において、計算ツールは、分析されているアプリケーションをより小さなタスクに分解する。タスクは、個別のアクションまたは一連のアクションであり得、タスクが、分析されているハードウェア上の既知のエネルギー使用値に関連付けられるまで、ますます小さなタスクに分割される。これらの分解された動作は、後で様々なハードウェア構成にわたる総エネルギーコストの作表に使用するために保存され得る。一例では、エネルギー要件のエニュメレーションは、休止電力および有効電力を考慮する、モジュールに関するものであり得る。有効電力は、例えば、メッセージを送信するときまたは測定を実行するときに使用される電力であり得る。
ブロック20614において、計算ツールは、アプリケーション内のすべてのタスクがそれらのエネルギー使用量について評価されたか否かを判定することができる。そうでない場合、ブロック20616において、そのタスクがトランスデューサモジュールに関連付けられているか否かについての判定が行われる。このプロセスは、本方法における、トランスデューサモジュールに対するタスクと通信モジュールに対するタスクとの間の分割を示すが、とりわけGPUなどの他の種類のモジュールがこのプロセスによって評価されてもよい。ブロック20614に示され、図206に示される方法で示される決定は、特定のハードウェアおよび構成について、タスクごとおよびタスクの種類ごとのエネルギーの作表を企図する。エネルギー使用量は、モジュールをホストしているデバイスのハードウェアで実装されたタスクとモジュールの両方について作表されている。従って、図206に示される決定ブロックおよび表は、エネルギー使用のためにタスクを分析することを可能にするだけでなく、特定のモジュールおよびモジュールグループも可能にする作表プロセスの例示を容易にするために含まれる。
ブロック20616において、タスクがトランスデューサモジュールに対するものであると計算ツールが判定した場合、ブロック20618において、1時間におけるトランスデューサ要求の数がエニュメレーションされる。トランスデューサ要求の数のエニュメレーションは、例えば、アプリケーションの実行中の1時間にわたって測定される数値を含み得る。トランスデューサ要求の数のエニュメレーションはまた、問題のタスクについての分析の下でトランスデューサに対して行われた要求の数についての過去の平均を含み得る。
ブロック20620において、計算ツールは、問題のタスクを実行するのに要する電力に、トランスデューサの要求が1時間以内にアプリケーションによって行われる回数を乗算することができる。期間は一例であり、必要に応じてもっと長くても短くてもよい。例えば、期間は、ユーザまたはツールのデプロイヤによって調整されてもよいし、期間は、アプリケーションの推定実行時間に自動的に一致されてもよい。期間は増やしたり減らしたりできる。一部の実施形態では、測定される期間は、エネルギー使用量が測定されているすべてのアプリケーションに対して等しい。一例では、モジュールは、特定のタスクに対するそのエネルギー使用量を自己格納することができる。例えば、1つのタスクまたは複数の関連タスクがモジュール上で頻繁に実行される場合、モジュールは、複数のエネルギー使用値を格納することによってエネルギー分析段階を改善することができる。例えば、計算ツールが、モジュールメモリに既にタスクのエネルギー使用量があるモジュール上のタスクのエネルギー使用量を要求した場合、値はすぐに返され得るため、それ以上の分析は必要ない。
ブロック20622において、計算ツールは、現在のハードウェア構成においてアプリケーションがどれだけのエネルギーを使用することになるかについての計算値を更新することができる。次いで、プロセスはブロック20614に戻り、アプリケーションに対するすべてのタスクが評価されたか否かを判定することができる。
ブロック20616でタスクがトランスデューサモジュールに対するものではないと計算ツールが判定した場合、ブロック20624において、1時間における通信要求の数がエニュメレーションされる。本明細書で述べたように、プロセスは、本方法における、トランスデューサモジュールに対するタスクと通信モジュールに対するタスクとの間の分割を示すが、他の種類のモジュールがこのプロセスおよび二分法において企図される。通信部モジュールのタスクのためのエネルギー使用量を測定することの開示は、測定され得るモジュールの一例にすぎない。
ブロック20626において、計算ツールは、通信モジュールタスクを実行するのに要する電力に、通信要求が1時間以内にアプリケーションによって行われる回数を乗算することができる。上述したように、図に示され本明細書に開示された期間は例示的なものであり、調整することができる。ブロック20622において、計算ツールは、通信部モジュールのためのタスクのエネルギー使用量に関して学習したことに基づいて、現在のハードウェア構成においてアプリケーションがどれだけのエネルギーを使用することになるかについての計算値を更新することができる。次いで、プロセスはブロック20614に戻り、アプリケーションに対するすべてのタスクが評価されたか否かを判定することができる。
ブロック20614でアプリケーション内の十分な数のタスクが評価されたと計算ツールが判定した後、プロセスはブロック20628に進むことができる。例えば、他のタスクの電力消費量の計算を依然として実行しながら電力計画を実施することができ、例えば、評価されたタスクがユニットのパワーリザーブに対して大きな電力消費量値を有する場合、プロセスフローは以下のブロックを並行して実行しながら、他のタスクの電力消費量を依然として評価し得る。
ブロック20628において、計算ツールは、スリープモード機能が評価されたか否かを判定する。そうでない場合、ブロック20630において、アプリケーションがスリープモードで費やす時間がエニュメレーションされる。スリープモード機能がない場合、エニュメレーションされた時間はゼロであり得る。スリープモードで費やされる時間のエニュメレーションは、秒単位で、ハードウェアのクロックサイクル単位で、または客観的に測定可能な時間の任意の細分単位で測定することができる。時間のエニュメレーションは、アプリケーションの実行中の1時間にわたって起こるであろうスリープ時間の量を測定することを含み得る。一例では、スリープモード中の時間のエニュメレーションは、問題のアプリケーションを実行するプロセッサによってスリープモード中に費やされた時間量の履歴平均も含み得る。
ブロック20632において、プロセッサをスリープモードにしているアプリケーションから節約されたプロセッサ電力が計算される。一例では、節約されるプロセッサ電力は、ブロック20630で判定されるように、単位時間当たりに消費されるプロセッサ電力に、スリープモードで費やされる時間の単位数を乗ずることによって判定され得る。上述したように、1時間の単位時間が示されているが、追加の時間単位も企図される。一部の実施形態では、単位時間は測定されたモジュールおよびデバイスにわたって一貫している。
この例では計算がスリープモードに対して実行されるが、同様のエネルギー使用量の計算が計算ツールによって実行されてもよい。例えば、問題のアプリケーションを実行している間にプロセッサがアクティブである、または他のタスクを実行するために利用可能である時間が測定され得る。今回は、必ずしも電力を節約するわけではないが、測定対象のアプリケーションとは無関係のタスクの実行に費やされ得る時間およびエネルギーとして表にして表示することができる。
スリープモードにおいてプロセッサによって節約された総電力が計算されると、ブロック20622において、計算ツールは、現在のハードウェア構成においてアプリケーションがどれだけのエネルギーを使用することができるかについての計算値を更新することができる。このアプリケーションを使用して節約された総電力はプロセッサの電力を節約するため、この値はアプリケーションが使用するエネルギー量の計算値を減らし得る。本明細書で説明するように、次いで、プロセスはブロック20614に戻り、アプリケーションに対する十分な数のタスクが評価されたか否かを判定することができる。
ブロック20614でアプリケーション内の十分な数のタスクが評価されたこと、およびブロック20628でスリープモード機能が評価されたことを計算ツールが判定した後、プロセスフローはブロック20634に進むことができる。ブロック20634において、計算ツールは、デバイスの電力寿命を計算することができる。一例では、これは、モジュールのリソースをモジュールの要件と比較することによって実行され得る。比較は、モジュール要件によってデバイスリソースを分割することを含み得る。一例では、比較は、ブロック20622において更新されるように、単位時間あたりに計算された総電力要件の合計によって、デバイスリソースに存在する電力の量を除したものを含み得る。
ブロック20636において、計算ツールは、デバイスの寿命が事前定義された所定のエネルギー使用量最小閾値よりも大きいこと、従って、使用される電力がエネルギー使用量閾値を十分に下回ることを判定することができる。もしそうであれば、プロセス計算ツールは終了し、アプリケーションがブロック20606において開始することを可能にする。
デバイス寿命がエネルギー使用量のための最小閾値より大きくない場合(ブロック20638)、計算ツールは、エネルギー使用量最小閾値が満たされなかったことをマスタデバイスに通知し、そしてモジュールの新しい構成を要求することができる。エネルギー使用量をマスタデバイスに通知することは、モジュールによって使用されるエネルギー量、個々のタスクによって使用されるエネルギー量、アプリケーションがスリープモードを含むか否か、およびモジュールおよびコアデバイスのエネルギー使用量の分析中に収集される他の情報の内訳を含み得る。この情報に基づいて、マスタデバイスは、可能な限り効率的に動作していないモジュールを識別し、それらを新しい構成に置き換えることができる。
ブロック20640において、モジュールの新しい構成が計算ツールに提供され得。新しい構成には、追加されたハードウェア、交換されたハードウェア、またはハードウェアが含まれ得る。次いで、計算ツールは、この新しい構成で、アプリケーションのエネルギー使用量をチェックし得る。従って、プロセスフローは20610に戻ってもよく、アプリケーションによって使用されるモジュールの要件が上記のようにエニュメレーションされ得る。
図207は、一部の実施形態による、自己記述型ハードウェアの要件のための計算ツールのためのIoTデバイス20700に存在し得るコンポーネントの一例のブロック図である。同様の番号が付けられた項目は、図8において説明したとおりである。大容量ストレージ808は、本明細書で説明される計算ツールを実施するための複数のモジュールを含むことができる。大容量ストレージ808においてコードブロックとして示されているが、モジュールのうちのいずれも、例えば特定用途向け集積回路(ASIC)に組み込まれるなど、ハードワイヤード回路で完全にまたは部分的に置き換えられ得ることが理解されよう。大容量ストレージ808は、複数のモジュールに電力を供給し制御するように構成されたデバイスのためのエネルギーリソースをエニュメレーションするためのエネルギーリソースエニュメレーション部20702を含み得る。
大容量ストレージ808は、とりわけ、メッシュ送受信機810またはアップリンク送受信機814などのモジュールに関するエネルギー要件をエニュメレーションするためのエネルギー要件エニュメレーション部20704を含み得る。大容量ストレージ808は、実行時に単一のモジュール上で完全に機能するタスクにアプリケーションを分解するためのアプリケーション分解部20706を含むことができる。
消費電力識別部20708は、分析に使用される各期間について、モジュールの消費電力を識別することができる。タスク起動カウンタ20710は、タスクが単位時間内にモジュールを起動する回数をカウントすることができる。
大容量ストレージ808は、タスクがアクティブである時間、1つのモジュールで完了されたタスクの期間、およびアクティブ期間までにモジュールが必要としたエネルギーに少なくとも部分的に基づいて、複数のモジュールのうちの1つのモジュールによって単位時間に使用される総エネルギーを計算する総エネルギー計算部20712を含み得る。
一例では、大容量ストレージ808はまた、複数のモジュールについて単位時間内に使用された総エネルギーと、デバイスのエネルギーリソースと、に基づいてデバイス寿命を生成するために、デバイス寿命生成部と共に、総エネルギー計算部20712を含み得る。デバイス寿命が、デバイスのアプリケーション分析が始まる前に設定された最小閾値時間以上であるとして計算されるのに応答して、アプリケーションを開始するようにデバイスに命令するデバイス命令部が、総エネルギー計算部20712に追加され得る。この例では、デバイス命令部は、デバイス寿命が、デバイスのアプリケーション分析が始まる前に設定された最小閾値時間未満であるとして計算されるのに応答して、新しい構成がマスタデバイスに送信されることの要求を命令し得る。さらに、一例では、新しい構成の要求は、モジュール上のタスクのためのエネルギー使用量、単位時間中にモジュールによって使用されたエネルギー、および複数のモジュールにおけるモジュールタイプのためのエネルギー使用量のうちの少なくとも1つの詳細なリストを含み得る。
一例では、大容量ストレージ808は、デバイスへの電力供給、デバイスのハードウェア構成の更新、およびアプリケーションのコードの更新の制御を実施するためのコードブロックを提供し得る。この例では、アプリケーションエネルギー計算装置はまた、第1の構成に対して計算された単位時間当たりの総エネルギーを格納するようにデバイスに指示するデバイス命令部も含むことができる。この例では、デバイス命令部は、マスタデバイスから第2の構成を要求するようにデバイスに命令することができる。さらに、この例では、第2の総エネルギー計算部は、デバイスの第2の構成に対して単位当たりの第2の総エネルギーを計算することができる。
一例では、大容量ストレージ808はまた、第1の構成の単位当たりの総エネルギーを第2の構成の単位当たりの第2の総エネルギーと比較するために、総エネルギー計算部20712の一部として総エネルギー比較部を含み得る。一例では、大容量ストレージ808はまた、単位当たりの総エネルギーと単位当たりの第2の総エネルギーとの比較に基づいて、第1の構成もしくは第2の構成またはその両方を要求するようにデバイスに命令するデバイス命令部を含み得る。一例では、大容量ストレージ808はまた、デバイスが有線リソースによって電力を供給されていると判定された場合にアプリケーションを開始するようにデバイスに命令するためのデバイス命令部を含み得る。一例では、アプリケーションエネルギー計算装置はまた、アクティブ期間ごとにモジュールの電力消費量を識別することができ、モジュールが、そのタスクについてそのモジュールに関連する履歴エネルギー使用量値を取得することを含み得る。
一例では、大容量ストレージ808はまた、アプリケーションがスリープモード機能を有するか否かを識別するために、総エネルギー計算部20712の一部としてアプリケーションスリープモード識別部を含み得る。この例では、大容量ストレージ808はまた、アプリケーションが時間単位でスリープモードになる時間をカウントするための時間カウンタも含むことができる。大容量ストレージ808はまた、アプリケーションのプロセッサがスリープモードになる時間に基づいて節約された総電力に基づいて、使用された総エネルギーを計算する総エネルギー計算部を含み得る。
図208は、一部の実施形態による、実行時に、リソースおよび自己記述型ハードウェアの要件をマッピングするようにプロセッサに指示する命令を含む、非一時的機械可読媒体20800のブロック図である。同様の番号が付けられた項目は、図9において説明したとおりである。
一例では、プロセッサは、デバイスへの電力供給、デバイスのハードウェア構成の更新、およびアプリケーションのコードの更新を命令することができる。非一時的機械可読媒体20800は、複数のモジュールに電力を供給し制御するように構成されたデバイスのためのエネルギーリソースをエニュメレーションするようにプロセッサ902に指示するためのコード20802を含み得る。
非一時的機械可読媒体20800は、複数のモジュールについてのエネルギー要件をエニュメレーションするようにプロセッサ902に指示するためのコード20804を含み得る。非一時的機械可読媒体20800は、実行時にIoTデバイス内の単一のモジュールとして完全に機能するタスクにアプリケーションを分解するようにプロセッサ902に指示するためのコード20806を含み得る。非一時的機械可読媒体20800は、アクティブ期間ごとに、複数のモジュールにおけるモジュールの電力消費量を識別するようにプロセッサ902に指示するコード20808を含み得る。一例では、アクティブ期間ごとに複数のモジュールのうちの1つのモジュールの電力消費量を識別することは、モジュールが、そのタスクについてそのモジュールに関連する履歴エネルギー使用量値を取得することを含む。
非一時的機械可読媒体20800は、実行されると、タスクが単位時間内にモジュールを起動する回数を数えるようにプロセッサに指示する命令を含み得る。非一時的機械可読媒体20800は、実行されると、タスクがアクティブである時間、モジュールによって完了されたタスクの期間、およびアクティブ期間までにモジュールが必要としたエネルギーに少なくとも部分的に基づいて、モジュールによって単位時間に使用される総エネルギーを計算するようにプロセッサに指示する命令を含み得る。
機械可読媒体は、上に列挙されたコードブロックに限定されず、他の機能を実行するためのコードを含み得る。例えば、コードは、複数のモジュールについて単位時間内に使用された総エネルギーと、デバイスのエネルギーリソースと、に基づいてデバイス寿命を生成するようにプロセッサに指示することができる。この例では、プロセッサは、デバイス寿命が、デバイスのアプリケーション分析が始まる前に設定された最小閾値時間未満であるとして計算されるのに応答して、新しい構成がマスタデバイスに送信されるように要求するように指示され得る。本明細書で使用される場合、新しい構成の要求は、モジュール上のタスクのためのエネルギー使用量、単位時間中にモジュールによって使用されたエネルギー、および複数のモジュールにおけるモジュールタイプのためのエネルギー使用量のうちの少なくとも1つの詳細なリストを含む。
モノのインターネット(IoT)のための現在開示されている技法では、一部の実施形態によれば、センサは、センサによって収集された生データポイントを処理し、データポイントを意味のある情報に変換することができるアルゴリズムを実装することができる。例えば、データポイントは、3.4Vなどのアナログ値から華氏78度などの温度読み取り値に変換され得る。
本明細書に開示されるように、センサは、それらの信号調整要件を説明するためにIoTデバイス上の汎用ピンに接続することができ、IoTデバイスと協働して、適切な信号調整回路を生成することができる。信号調整回路の例は、例えば雑音を除去するために、増幅器およびそれに続くバターワースフィルタを含むことができる。
IoTデバイスは、フィールドプログラマブルゲートアレイ(FPGA)デバイスを含み得、これは、IoTネットワーク階層のすべてのレベルに埋め込まれ得る。FPGAは、一般に、製造後、通常OEMによる手動プロセスで構成されるように設計された集積回路である。本明細書で説明されるように、モジュールが信号調整回路を持たないセンサであっても、モジュールはそれらの信号調整要件を記述し得る。自己記述型モジュールは、モジュールのためのカスタム信号調整ハードウェアを作成するために、IoTデバイスのFPGA回路と共に使用され得る。
モジュールを含むIoTデバイスは、モジュールよりも制約が少ない場合がある。本明細書で使用されるように、制約されるとは、一般に、ハードウェアの制限、リソースの制限、またはライセンスまたは許可の制限など、デバイスの動作を制限し得る制限を有するハードウェアまたはソフトウェアを指す。一例では、制約の少ないIoTデバイスは、LINUX(登録商標)オペレーティングシステムまたは同様のオペレーティングシステム(OS)、図8に関して説明したものなどの汎用プロセッサを使用することができ、IoTデバイスは、送配電網から電力を供給され得、高帯域幅ネットワーク接続へのアクセスを含む。この例では、IoTデバイスはFPGAとFPGAコンパイラとを含む。FPGAコンパイラを含むIoTデバイスは、新しいモジュールが接続されたときに新しいモジュールのためのFPGA内に信号処理回路を生成することができる。
FPGAにおける信号調整用のカスタムハードウェアの作成は、新しいモジュールが制約の少ないIoTデバイスに接続されたときに開始することができる。IoTデバイスが新しいモジュールの接続を検出したことに応答して、IoTデバイスは、モジュールから信号調整要件および信号処理アルゴリズムを読み取る。上記のように、制約のあるモジュールおよびセンサは自己記述型であり、モジュールのための信号調整要件および好ましい信号処理アルゴリズムをメモリから提供することができる。次いで、FPGAコンパイラを備えた制約の少ないIoTデバイスは、カスタム調整回路を生成し、その調整回路をIoTデバイスのFPGAに実装することができる。カスタム調整回路がFPGAコンパイラによって実装されると、IoTデバイスはデータ出力を読み取り、信号処理アルゴリズムをデータに適用して情報を生成することができる。
信号調整のためのカスタムハードウェアを作成する場合、モジュールを受け取るデバイスは制約のあるデバイスであり得る。制約のあるデバイスは、例えば、無線ノードであり得、そのデバイスは低電力プロセッサを有し得るか、またはそのデバイスは低帯域幅ネットワーク接続を有し得る。制約のあるデバイスでは、FPGAコンパイラの実装効率が低下する可能性がある。FPGAコンパイラの効率が低い実装は、特定のFPGAコンパイラ用に最適化された信号調整ではなく、FPGAコンパイラ上の予め構築された信号調整ブロックに依拠し得る。
一例では、信号調整ブロックに関するパラメータおよびそれらの間の接続は、センサが接続された後にプロセッサによって定義され得る。デバイスが制約付きであり得る間、モジュールは、共通のデータプロトコルを通してメッセージを自己記述し、送信し、そして受信し得る。上述したように、共通のデータプロトコルは一般的にすべてのデバイスによって理解されるプロトコルである。
一例では、モジュールは、それ自体の信号調整要件を記述することができる。このモジュールの自己記述から、信号調整のためのカスタムハードウェアを作成するための例示的な方法を示すことができる。
制約のあるデバイスで信号調整を生成することは、モジュールがデバイスに接続されたときに開始することができる。制約のあるデバイスは、信号調整要件および信号処理アルゴリズムを読み取ることができる。次いで、制約のあるデバイスは、既存のFPGAコンパイラブロックのパラメータを構成し、FPGAロジックブロックを接続してカスタム信号調整回路を作成することができる。次いで、制約のあるデバイスは、それが作成したカスタム信号調整回路からの出力を読み取り、従って、事前構築された信号調整ブロックおよび処理アルゴリズムを適用して、人間が読めるデータを生成することができる。
信号調整のためのカスタムハードウェアを作成する場合、モジュールを受信するデバイスは、IoTデバイスの制約の少ないリソースを活用する制約のあるデバイスになり得る。一例では、制約のあるノードは、新しく接続されたモジュールから制約の少ないゲートウェイ、ネットワークデバイス、またはクラウドデバイスに信号調整要件を送信することができる。制約の少ないIoTデバイスは、例えば、制約のあるノード内のFPGAに実装するために、制約のあるデバイスに転送されるFPGAコードを生成することができる。最適化されたコードの転送は、有線および無線(OTA)を含むデータ転送手段を介して転送されてもよい。
この例では、カスタムハードウェアまたは信号調整を作成するための方法は、制約のあるデバイスが新しいモジュールが接続されたことを検出したときに開始し得る。制約のあるデバイスは、モジュールによって記述された信号調整要件および信号処理アルゴリズムを読み取ることができ、両方とも制約の少ないIoTデバイスに送信することができる。制約のあるデバイスはまた、制約のあるデバイスのパラメータおよび制約のあるデバイスのFPGAを記述するパラメータを、制約の少ないIoTデバイスに送信することができる。信号調整要件には、信号処理アルゴリズム、ならびに制約のあるデバイスのデバイスパラメータおよびFPGAパラメータが含まれ得る。信号調整要件を受信したことに応答して、制約の少ないIoTデバイスはカスタム調整回路を生成することができる。生成されたカスタム調整回路は、制約のあるデバイスおよび制約のあるデバイスのFPGA用にカスタマイズすることができる。カスタム調整回路がより制約の少ないIoTデバイスによって生成されると、制約のあるデバイスは、カスタム信号調整回路からの出力を読み取り、生データを処理して情報を生成するために信号処理アルゴリズムを適用することができる。
図209は、一部の実施形態による、信号調整回路を構成するためにモノのインターネット(IoT)デバイスによって使用される例示的な方法20900のプロセスフロー図である。図209の方法20900は、図210に関して説明されるIoTデバイス21000によって実施することができる。方法20900は、図8に関して説明したシステム802を使用して実行することができる。方法20900は、新しいモジュールがIoTデバイスに接続されたときにブロック20902において開始することができる。
ブロック20904において、IoTデバイスは、信号調整要件を判定し得る。信号調整要件は、例えば、測定された電圧ではなく度数で温度をフォーマットする、または光電池またはフォトレジスタから出力される生の電圧ではなくルーメンで光測定値をフォーマットするなど、デバイスが信号に対応する情報を配信できるフォーマットを含み得る。
ブロック20906において、IoTデバイスが制約のあるデバイスであるか、制約の少ないデバイスであるかに関する判定が行われ得る。本明細書で使用されるように、制約が少ないとは、より一般的な処理ソフトウェア、通信ハードウェアを実装することができるハードウェアまたはソフトウェアを有する、または受信もしくは作成されたデータを読み取る、書き込む、もしくは実行するための拡張ライセンスもしくは許可を有する、デバイスを指し得る。
デバイスが制約の少ないものである場合、ブロック20908において、自己記述型モジュールおよびデバイスの信号調整要件に基づいて、FPGAコードをそのデバイスのために生成することができる。ブロック20910において、デバイス上のFPGAがそのタスクに不適当であるか否かに関して決定が行われる。もしそうであれば、ブロック20912において、警告が送信されてもよく、デバイスはモジュールを切断してもよい。
ブロック20910でFPGAがそのタスクに適していると判定された場合、ブロック20914において、FPGAコードがデバイスにダウンロードされ得る。FPGAコードはデバイス自体で生成されてもよい。FPGAコードは、例えばクラウド内のデバイスによってリモートで生成されてもよく、次いでIoTデバイスにダウンロードされてもよい。FPGAコードが生成またはダウンロードされると、FPGAコンパイラは、FPGAコードに基づいて信号調整回路を生成することができる。次いで、信号調整回路はFPGA上に実装されてもよい。従って、モジュール収集データは、ブロック20916において、最終情報フィードを作成するための処理のためにFPGA内の信号調整回路を介して供給されるデータを収集することができる。
ブロック20906でデバイスが制約されていると判定された場合、ブロック20918において、デバイスが利用可能なFPGA上に十分な構成可能信号調整ブロックを有するか否かが判定される。利用可能なFPGAは、デバイスに対してローカルであるか、またはデバイスに対してリモートで、かつデバイスの制御下にあり得る。もしそうであれば、ブロック20920において、デバイスはFPGA上の既存のブロックのパラメータの構成を命令してもよい。例えば、これは、制約の少ないデバイスで生成され、制約のあるデバイスにダウンロードされたFPGAコードに基づき得る。
構成されると、ブロック20922において、デバイスは、既存のFPGAブロックを互いに接続して制約のあるデバイス内のモジュールのための信号調整回路を形成することができる。上記のように、一部の実施形態によれば、FPGAの接続された回路は、モジュールで受信された信号を調整するために使用され得る。その結果、ブロック20916でデータを収集するモジュールはデータを収集し、そのデータをFPGA内の信号調整回路に提供することができる。
ブロック20918において、デバイスがFPGA上に十分な構成可能な信号調整ブロックを有していないと判定された場合、ブロック20924において、デバイスのFPGAブロックおよびデバイス特性がエニュメレーションされる。本明細書で使用されるように、一部の実施形態によれば、FPGAブロックおよびデバイス特性のエニュメレーションは、FPGAブロックおよびデバイスに関する詳細を識別するために使用され得る。ブロック20926において、FPGAブロックおよびデバイス特性のエニュメレーションを使用して、FPGAブロックおよびデバイスに関する詳細を、現在の制約のあるデバイスから上位階層レベルのマスタデバイスに送信することもできる。
上位階層レベルでマスタデバイスによって受信されると、ブロック20928において、マスタデバイスがデバイス特性およびエニュメレーションされたFPGAに適したFPGAコンパイル能力を有するか否かに関する判定を行うことができる。そうでない場合、ブロック20926において、送信元デバイスは、エニュメレーションされたFPGAブロックおよびデバイス特性を、マスタデバイスよりも上位階層にある第2のマスタデバイスに送信することができる。マスタデバイスが要求された能力を有する場合、ブロック20930において、マスタデバイスは、制約のあるデバイスからのデータを処理するためのFPGAコードを生成することができる。
ブロック20932において、制約のあるデバイス上のFPGAがそのタスクに不適当であるか否かに関して判定が行われる。もしそうであれば、ブロック20912において、非互換性に関する警告が送信されてもよく、デバイスはモジュールを切断され得る。ブロック20932において、デバイス上のFPGAがそのタスクに不適切ではないと判定された場合、ブロック20934において、FPGAコードが制約のあるデバイスにダウンロードされる。FPGAコードがデバイスにダウンロードされると、FPGAコンパイラは、FPGAコードに基づいて信号調整回路を生成することができる。結果として、データを収集するモジュールは、ブロック20916において、生成されたFPGAコードに基づくモジュールおよびデバイスの信号調整回路を介して供給されるデータを収集し始めることができる。
図210は、一部の実施形態による、信号調整回路を構成するためにIoTデバイス21000に存在し得るコンポーネントの一例のブロック図である。同様の番号が付けられた項目は、図8において説明したとおりである。
IoTデバイス21000はFPGA 21002を含むことができる。本明細書で使用されるように、一部の実施形態によれば、FPGAは、製造後に顧客または設計者によって構成されるように設計された集積回路であり得る。一例では、自己記述型センサモジュール21004はセンサFPGA 21006を含み得る。センサFPGA 21006は、IoTデバイス21000のFPGA 21002と同様に機能することができる。IoTデバイス21000は、本明細書では自己記述型IoTデバイス21000として説明され得る。
上でも示したように、図8を参照すると、大容量ストレージ808は、本明細書で説明されるグループ作成機能を実施するための複数のモジュールを含むことができる。大容量ストレージ808においてコードブロックとして示されているが、モジュールのうちのいずれも、例えば特定用途向け集積回路(ASIC)に組み込まれるなど、ハードワイヤード回路で完全にまたは部分的に置き換えられ得ることが理解されよう。大容量ストレージ808は、自己記述型センサモジュール21004のIoTデバイス21000への接続に応答して自己記述型センサモジュール21004を検出するためのセンサモジュール検出部21008を含み得る。
大容量ストレージ808は、自己記述型センサモジュール21004から受信したデータを処理するための受信データプロセッサ21010を含み得、受信したデータは自己記述型センサモジュール21004に関する信号調整情報を示す。大容量ストレージ808は、FPGA 21002上に実装されるFPGAコードを生成するためのFPGAコード生成部21012を含み得る。
大容量ストレージ808は、自己記述型センサモジュール21004から受信した生データを修正して、信号調整情報に基づいてFPGAを使用して信号調整データを生成するための生データ修正部21014を含むことができる。一例では、プロセッサ802は、FPGAがFPGAコードをサポートできないことを検出することができる。この例では、プロセッサはまた、FPGAブロックが自己記述型センサモジュール21004から受信した生データを信号調整するのに十分であることの検出に応答して既存のFPGAブロックを接続し得る。
プロセッサ802はまた、識別されたFPGA特性および自己記述型デバイス特性を送信し得る。この場合、プロセッサ802は、FPGA特性および自己記述型デバイス特性を含む要求をフォグ812またはクラウド302内のマスタデバイスに送信することもできる。この要求は、自己記述型デバイスが制約されていることの検出と、自己記述型IoTデバイス21000のFPGAに十分な構成可能な信号調整ブロックがないことの検出と、に応答して送信され得る。さらに、要求は、マスタデバイスによって生成されたFPGAコードを生成し返すことができる。同様に、例えば、バッテリ824、メッシュ送受信機810またはアップリンク送受信機814によって提供される無線技術に基づくインターネット接続、または低電力モードを有するプロセッサ802のうちの少なくとも1つを含む自己記述型IoTデバイス21000は、一部の実施形態によれば、制約付き自己記述装置とみなすことができる。
別の例では、プロセッサ802は、自己記述型デバイスが制約されているという検出に応答して、自己記述型センサモジュール21004に関する信号調整情報およびデバイス情報を制約の少ないデバイスに送信し得る。この例では、プロセッサ802はまた、自己記述型センサモジュール21004のFPGA 21006に実装されるリターンFPGAコードを生成するための要求を制約の少ないデバイスに送信することもできる。さらに、プロセッサ802は、自己記述型IoTデバイス21000が制約されているという検出に応答して、自己記述型センサモジュール21004に関する信号調整情報およびデバイス情報を第2の制約のあるデバイスに送信し、第2の制約のあるデバイスは制約の少ないデバイスにアクセスできる。
自己記述型センサモジュール21004は、本明細書で説明されるノードメタモデル(NMM)に従うことができる。これはFPGAとして実装することができ、FPGAの動的更新のための方法が、ノードメタモデルに基づいて、プラグアンドプレイモードなどの普遍的に相互運用可能なインターフェースを実装する自己記述型センサモジュール21004の動的動作をもたらし得る。
図211は、一部の実施形態による、実行時に、信号調整回路を構成するようにプロセッサに指示する命令を含む、非一時的機械可読媒体21100のブロック図である。同様の番号が付けられた項目は、図9において説明したとおりである。
非一時的機械可読媒体21100は、自己記述型センサモジュールの自己記述型デバイスへの接続に応答して自己記述型センサモジュールを検出するようにプロセッサ902に指示するためのコード21102を含み得、自己記述型デバイスはFPGAを含む。一例では、自己記述型デバイスは、バッテリ電源、無線技術に基づくインターネット接続、または低電力モードを有するプロセッサのうちの少なくとも1つを含み得、制約付き自己記述型デバイスとみなされる。
非一時的機械可読媒体21100は、自己記述型センサモジュールから受信したデータを処理するようにプロセッサ902に指示するためのコード21104を含み得、受信したデータは自己記述型センサモジュールに関する信号調整情報を示す。非一時的機械可読媒体21100は、自己記述型デバイスのFPGA上に実装されるFPGAコードを生成するようにプロセッサ902に指示するためのコード21106を含み得る。最後に、非一時的機械可読媒体21100は、自己記述型センサモジュールから受信した生データを修正して、信号調整情報に基づいてFPGAを使用して信号調整データを生成するためのコード21108を含むことができる。
一例では、機械可読媒体は、実行されると、FPGAがFPGAコードをサポートできないことを検出するようにプロセッサに指示する命令を含み得る。この例では、命令はまた、FPGAブロックが自己記述型センサモジュールから受信した生データを信号調整するのに十分であることの検出に応答して既存のFPGAブロックを接続するようにプロセッサに指示することもできる。さらに、命令はまた、識別されたFPGA特性および自己記述型デバイス特性を送信するようにプロセッサに指示することもできる。次いで、プロセッサは、マスタデバイスへ要求を送信し、その要求はFPGA特性と自己記述型デバイス特性とを含み、要求は、自己記述型デバイスが制約されていることの検出と、自己記述型デバイスのFPGAに十分な構成可能な信号調整ブロックがないことの検出と、に応答して送信される。一例では、要求は、マスタデバイスによって生成されたFPGAコードを生成し返す。
機械可読媒体は、上に列挙されたコードブロックに限定されず、他の機能を実行するためのコードを含み得る。例えば、コードは、自己記述型デバイスが制約されているという検出に応答して、自己記述型センサモジュールに関する信号調整情報およびデバイス情報を制約の少ないデバイスに送信し得る。コードは、自己記述型デバイスのFPGAに実装されるリターンFPGAコードを生成するための要求を制約の少ないデバイスに送信することもできる。あるいは、プロセッサは、自己記述型デバイスが制約されているという検出に応答して、自己記述型センサモジュールに関する信号調整情報およびデバイス情報を第2の制約のあるデバイスに送信し、第2の制約のあるデバイスは制約の少ないデバイスにアクセスできる。
IoTネットワークには様々な種類のデバイスがある。一部のIoTデバイスはバッテリによって電力を供給されてもよく、他のIoTデバイスは送配電網からの電力を使用してもよい。さらに、一部のIoTデバイスは固定式であり、他のIoTデバイスは移動式である。モバイルデバイスの挙動や頻繁にスリープ状態に入るデバイスを考慮することは、ネットワーク健全性モニタが多数のデバイスを考慮するために拡張する方法に影響を与え得る。本明細書で説明されているように、例えばブルームフィルタ、ブロックチェーン、DHTなどを使用して健全性報告を生成することは、ネットワーク健全性モニタを実施するために拡張することができる。
図212は、一部の実施形態による、階層型デバイスおよびネットワークの健全性の報告21200の概略図である。現在編成されているように、ネットワークトポロジは階層的であり得る。説明されるネットワーク健全性報告のための技法は、階層的トポロジに基づいて構築することができる。例えば、IoTフレームワークアクター21202は、ネットワークおよびデバイスの階層を監督することを望む場合もある。IoTフレームワークアクター21202は、とりわけ、ネットワーク管理者、ネットワークコンソール、およびビジネスサービスレベル合意プロバイダなど、ネットワークに依拠している関係者を含むことができる。
デバイスAなどの単一のデバイス、またはサブネット内の多数のデバイスは、デバイス健全性報告21204を生成することができる。デバイス健全性報告21204は、報告がカバーする期間を示す値を含む時間変数と、シャドウフィルタ入力を有するスパースアレイ変数とを含むデバイス健全性報告データ21206を含み得る。シャドウフィルタは、報告が予想されるが、存在しないときにデータを収集することができる。
監視エージェントは、サブネットからRepresentational State Transfer(REST)呼び出し21208を実行して、デバイスA健全性報告21204など、サブネット内のすべてのデバイスのデバイス健全性報告を取得し、それらをサブネット健全性報告21210として集約できる。本明細書で使用されているように、REST呼び出しは、要求するシステムに、統一された事前定義されたステートレスオペレーションのセットを使用してウェブリソースのテキスト表現にアクセスし操作することを可能にする呼び出しである。一例では、サブネット健全性報告21210は、サブネットA、サブネットB、およびサブネットC健全性報告など、多数のサブネット健全性報告のうちの1つであり得る。各サブネットは複数のデバイスを監視できる。サブネット健全性報告21210は、サブネット健全性報告データ21212を含み得る。サブネット健全性報告データ21210は、デバイス報告が網羅している期間と、とりわけネットワークフィルタデータなどのネットワークフィルタシャドウフィルタデータを含むスパースアレイ変数とを含み得る。サブネット健全性報告データ21210は、それらのデバイスにアクセスまたはアドレス指定するために使用され得るリンクと共に、サブネット内でカバーされるデバイスの集合のリストを含み得る。
監視エージェントは、ネットワークからRepresentational State Transfer(REST)呼び出し21208を実行して、サブネットA健全性報告21210など、ネットワーク内のすべてのサブネットのサブネット健全性報告を取得し、それらをネットワーク健全性報告21214として集約できる。ネットワーク健全性報告21214は、ネットワーク健全性報告データ21216を含み得る。ネットワーク健全性報告データ21216は、サブネット報告が網羅している期間と、ネットワークフィルタデータなどのネットワークフィルタシャドウフィルタデータを含むスパースアレイ変数とを含み得る。ネットワーク健全性報告データ21216は、それらのサブネットにアクセスまたはアドレス指定するために使用され得るリンクを有するネットワーク内でカバーされるサブネットの集合のリストを含み得る。
このネットワークトポロジおよび階層を使用して、健全性報告は、IoTネットワーク健全性を監視するためにIoTフレームワークアクター21202によって収集され得る。トポロジベースでネットワークの健全性を監視することで、要求に応じて上位レベルの情報を幅広くも狭くも取得して提示できる。
図213は、一部の実施形態による、デバイスレベルブルームフィルタおよびシャドウフィルタの健全性の報告21300の概略図である。同様の番号が付けられた項目は、図212を参照して説明したとおりである。デバイス21302は、デバイスA健全性報告21204に健全性メッセージ21304を提供することができる。健全性メッセージ21304は、毎秒1回など、一定の期間に繰り返されるようにスケジュールされ得る。報告は健全性情報を含み得る。しかしながら、健全性および機能を示す単純なping、または他の同様の動作の警告で十分な場合もある。
一例では、デバイスレベルでの健全性報告は、ウォッチドッグエージェントに依拠し得る。ウォッチドッグエージェントは、予想される健全性メッセージ21304の受信の欠如を検出することができる。予想される健全性メッセージ21304の受信の欠如を検出することは、一般に、障害シナリオを検出し、障害を能動的に報告することとは異なり得る。一例では、ウォッチドッグエージェントは、ブルームフィルタ21306を使用して、期待されたスケジュールに従ってウォッチドッグメッセージの受信を確認応答することができる。
ブルームフィルタは、一般に、予想されるスケジュールに従って構成され得るフィルタである。例えば、ある期間内、例えば数秒内に期待されるレートでウォッチドッグメッセージが受信された場合、例えば、数分、数時間、数日、数週間など、より長い期間にわたって良好な健全性が発生していることを示すために、図213の矢印によって示されるロールオーバー機能などによって、第2のブルームフィルタが更新され得る。このパターンに従って、ブルームフィルタの上向きカスケードは、次第により長い期間の健全な動作を格納することができる。本明細書に開示されるように、一部の実施形態によれば、予想される時間窓内に受信されない予想されるウォッチドッグメッセージがあるときに、デバイスの健全性の報告が調査され得る。
各ブルームフィルタ21306は、その時間間隔の各インクリメントに対して対応するビットで特定の期間をカバーするように示されている。例えば、秒のブルームフィルタは60ビットにコード化し、1分間の各1秒に1ビットを許容する。秒のブルームフィルタは、60ビットにコード化し、1時間の各1分に1ビットを許容する、分のブルームフィルタにロールオーバーする場合もある。分のブルームフィルタは、24ビットにコード化し、1日の各1時間に1ビットを許容する、時間のブルームフィルタにロールオーバーする場合もある。このパターンは、上述のように増加し続け得る。
最後の時間インクリメントの後、ブルームフィルタをその対応するビットに適用することができ、スリープビット21308と呼ばれる別のビットは、デバイスがスリープモードにある、またはパワーダウンされていることを示すメッセージをデバイスが送信したかを示すことができる。一例では、スリープビット21308が設定されている場合、システムは、デバイスの電源が再投入されてスリープビット21308が設定解除されるまで、システム健全性情報の追跡を回避することを選択することができる。
図213に示すように、予想されるが存在しない健全性報告が検出された場合にのみ一般に更新されるペアシャドウフィルタ21310と協調してブルームフィルタを使用することによって、履歴報告のために、断続的な欠落したウォッチドッグメッセージが検出され記録され得る。シャドウフィルタ21310は、同様の時間インクリメントのブルームフィルタとペアになって示されている。シャドウフィルタ21310の値は、ペアブルームフィルタおよび対応するロールオーバフィルタにAND論理関数を適用することによって計算することができる。例えば、ブルームフィルタに欠落報告がなく、ロールオーバーフィルタにそのブルームフィルタ内に記録されたタイムスパンにわたって欠落報告がない場合、AND論理関数はTRUEまたは1の値を返す。対照的に、ブルームフィルタが記録されたタイムスパンにわたって欠落報告を示す場合、またはロールオーバーフィルタが記録されたタイムスパンにわたって欠落報告を示す場合は、AND論理関数はFALSEまたは0の値を返す。この出力値は、さらなるネットワーク健全性統計収集のためにデバイスシャドウフィルタに格納されてもよい。
一例では、ブロックチェーンは、健全性報告データをリストし交換する際に、デバイス、サブネットワーク、およびネットワークによって使用され得る。ブロックチェーンとは、一般的に、ブロックと呼ばれる記録の継続的に増加するリストを維持する分散型データベースのことである。一例では、ブロックは、タイムスタンプおよび前のブロックへのリンクを含み、従ってブロックチェーンを形成する。ブロックチェーンアテステーションは、連鎖およびアーカイブのためにルートオブトラストを使用するトラステッドブートメカニズムで使用され得る広い概念である。例えば、ブロックチェーンアテステーションは、ローカルプラットフォーム上のブロックチェーンのルートオブトラストだけでなく、参加者の「マイナー」プラットフォームの測定値を収集することもできる。ブロックチェーン上を流れる最初のトランザクションは、個々のプラットフォームの連鎖のためのルートオブトラストのアテステーションであり得る。マイナーのルートのそれぞれの測定値を比較することによって、検証部は、ブロックチェーンが後続のトランザクションを処理するために信頼できる(trustworthy and reliable)ものであると結論付けることができる。
ブロックチェーンは、上述のようにトラステッドプラットフォームモジュール(TPM)においてアクセスされてもよい。一例では、TPMは、2009年にISO/IEC 11889としてTrusted Computing Groupによって公表された仕様に準拠し得る。デバイスがブートコードセグメントから開始している場合、初期ブートから信頼チェーンを作成することによって、ブロックチェーンをまず使用してトラステッド実行環境(TEE)を確立することができる。TPM 13128の代わりに、TEEは、EPID、SGX、または同様の技術などの他の技術に基づいてもよい。
本明細書で使用されるとき、健全性情報のブロックチェーンは、全体的なトポグラフィにおいて、デバイス層からサブネット層へ、ネットワーク層へと垂直に到達することができる。同様に、ブロックチェーンは、スケジュールされた健全性メッセージの受信の欠如に基づいて、デバイス健全性情報の複数のインスタンスの水平方向のキャプチャを反映し得る。
一例では、ブルームフィルタは、ネットワークトポグラフィの最下層においてネットワークの健全性の履歴記録を確立するためにブロックチェーントランザクションに含まれ得る。一例では、最下位の層は、デバイスなどのエンドポイントを指し得る。最下位の層のデバイスをマイニングノードと呼ぶことができ、それは、マイニングノードが、シャドウフィルタを使用して他の最下位層のデバイスと組み合わせる前に、ブルームフィルタ内の健全性情報を収集し得るためである。
一例では、ルータ、コンセントレータ、またはゲートウェイがマイニングノードとみなされた場合、そのルータ、コンセントレータ、またはゲートウェイは、ネットワーク健全性の相互リンクされた記録のブロックチェーン表現に含めることができる。健全性情報を格納するためにブロックチェーンを使用することは、マイニングノードの相互にリンクされた性質のために、他のブロックチェーンマイナーがマイナーの集団の健全性について知らされることを可能にし得る。この情報を使用して、悪意のある障害および悪意のない障害が予測され得る。一例では、ブロックチェーンを使用する50%以上のマイニングノードの障害は、コンセンサスを形成することができない可能性があるため、ブロックチェーンの完全性を危殆化し得る。
図214は、ウォッチドッグ報告の過去の断続的な損失のネットワークレベルブルームフィルタ報告21400の概略図である。同様の番号が付けられた図面は、図213に関して説明したとおりである。示されるように、デバイスまたはデバイスのセット21402は、シャドウフィルタまたはシャドウフィルタのセット21404と対になってそれらのデータを提供することができる。一例では、シャドウフィルタ21404のセット内のシャドウフィルタのそれぞれは、デバイスのリセットレートおよびロールオーバー時間ならびにペアになったシャドウフィルタ21404に基づいて、単一のデバイスまたはデバイスのセット21402に対応し得る。
本明細書で使用されるとき、シャドウフィルタのセット21404は、特定のサブネットに属するすべてのデバイス、例えば、サブネットA 21406、サブセットB 21408、サブセットC 21410、サブセットD 21412、またはサブセットE 21414以外には関連しない場合がある。これらのサブネットのそれぞれは、それら自体のサブネットシャドウフィルタを含むことができ、例えば、サブネットA 21406はシャドウフィルタFAを含むことができ、サブセットB 21408はシャドウフィルタFBを含むことができ、サブセットC 21410はシャドウフィルタFC 21416を含むことができ、サブセットD 21412は、シャドウフィルタFDを含むことができ、サブセットE 21414はシャドウフィルタFEを含むことができる。
例示的なサブネットシャドウフィルタ、サブセットC 21410用のシャドウフィルタFC 21416が示されている。示されるように、シャドウフィルタFC 21416に含める値は、複数のデバイスシャドウフィルタにAND論理演算を適用することによって生成され得る。上述したように、AND論理機能は、すべてのソースが機能している場合には複数のソースにわたってTRUEまたは1を示し、ソースデバイスのシャドウフィルタのうちの1つでも機能しないデバイスを示す場合にはFALSEまたは0を読み取り得る。従って、シャドウフィルタFC 21416を使用して、サブネットC 21410内のすべてのデバイスについて断続的なシャドウイベントをキャプチャし、それによってサブネット全体の健全性アクティビティを一度に示すことができる。同様に、サブネットシャドウフィルタは、ネットワークのサブネットシャドウフィルタのそれぞれにおいて生成され格納された値に適用されるAND論理関数を有することができる。これにより、各サブネットシャドウフィルタからの健全性報告は、ネットワーク健全性報告21214内のネットワークシャドウフィルタに、ネットワークの断続的な健全性を反映するように通知することができる。この情報から、ネットワーク健全性監視システムは、ネットワークシャドウフィルタのデータを分析して、1つまたは複数のネットワークがウォッチドッグ報告からの応答として予想外の失効のインシデントをより多くまたはより少なく経験する期間を観察することができる。一例では、判定は、負荷、帯域幅、輻輳、または他の処理条件が物理的容量を超えているという指示であり得、これらの指示は、IoTネットワークの安全性が低い動作条件に注意を促し得る。
図215は、一部の実施形態による、シャドウおよびブルームフィルタを使用して健全性を報告するためにモノのインターネット(IoT)デバイスによって使用されるための例示的な方法21500のプロセスフロー図である。図215の方法21500は、図216に関して説明されるIoTデバイス21600によって実施することができる。方法21500は、図8に関して説明したシステム802を使用して実行することができる。プロセスフローは、ブロック21502で開始し得る。
ブロック21504において、健全性監視エージェントが、ネットワーク内のIoTデバイスおよびネットワーク機器にインストールされ得る。ブロック21506において、健全性エージェントのソフトウェアは、IoTデバイスまたはネットワーク機器の一部のブートまたはリセット時に実行され得る。
ブロック21508において、報告頻度に対応するブルームフィルタを更新することによって、デバイスまたは機器レベルでの健全性監視エージェントは、健全性報告が定期的なスケジュールで受け取られないたびに、ウォッチドッグイベントメッセージを報告することができる。ブロック21510において、ブルームフィルタがロールオーバー条件を満たしているか否かに関する判定が行われる。そうでない場合、プロセスフローはブロック21508に戻ることができ、追加のウォッチドッグ報告が送信され得る。ブルームフィルタがロールオーバー条件を満たしている場合、ブロック21512において、ブルームフィルタはロールオーバーによって更新され得る。ブルームフィルタの更新は、デバイスがブルームフィルタの報告期間全体にわたって正常であったことを示す。
ブロック21514において、リセット閾値に達したか否かに関する判定が行われる。そうでない場合、プロセスフローはブロック21508に戻ることができ、追加のウォッチドッグ報告が送信され得る。ブロック21514でリセット閾値に達した場合、ブロック21516において、ブルームフィルタおよびロールオーバフィルタについてAND論理演算を計算し、その結果をシャドウフィルタに格納することができる。ブロック21518において、スリープビットが設定されているか否かに関する判定が行われる。もしそうであれば、ブロック21520において、ブルームフィルタおよびシャドウフィルタの処理は、スリープ時間が終了しスリープビットが設定解除されるまで中断される。次いで、プロセスフローはブロック21518に戻る。
ブロック21518でスリープビットが設定されていないと判定された場合、ブロック21522において、プロセスは、システムがネットワーク健全性統計収集要求を受信し処理するまで待機することができる。集合が処理されると、ブロック21524において、サブネットモニタは、サブネット内のデバイスのシャドウフィルタを取得することができる。このデバイスシャドウフィルタの結果は、サブネットワークシャドウフィルタに適用できる。ブロック21526において、別のデバイスがあるか否か、すなわち収集するサブネット内にシャドウフィルタがあるか否かに関する判定が行われる。そうである場合、プロセスフローはブロック21526に戻り、残りのデバイスシャドウフィルタが収集され、サブネットシャドウフィルタに適用される。
収集するサブネットに他のデバイスシャドウフィルタがない場合、ブロック21528において、ネットワークモニタはネットワーク内のサブネットからサブネットシャドウフィルタを取得することができる。このサブネットシャドウフィルタの結果は、ネットワークシャドウフィルタに適用され得る。ブロック21530において、別のサブネットがあるか否か、すなわち収集するネットワーク内にシャドウフィルタがあるか否かに関する判定が行われる。そうである場合、プロセスフローはブロック21528に戻り、残りのサブネットシャドウフィルタが収集され、ネットワークシャドウフィルタに適用される。収集するネットワーク内に別のサブネットシャドウフィルタがない場合、ブロック21532において、ネットワーク健全性シャドウフィルタをサブスクライバに報告することができる。次いで、プロセスはブロック21534において終了する。
図216は、一部の実施形態による、ネットワークおよびネットワークデバイスの健全性を報告するためのIoTデバイス21600内に存在し得るコンポーネントの一例のブロック図である。同様の番号が付けられた項目は、図8において説明したとおりである。
上でも示したように、図8を参照すると、大容量ストレージ808は、本明細書で説明されるグループ作成機能を実施するための複数のモジュールを含むことができる。大容量ストレージ808においてコードブロックとして示されているが、モジュールのうちのいずれも、例えば特定用途向け集積回路(ASIC)に組み込まれるなど、ハードワイヤード回路で完全にまたは部分的に置き換えられ得ることが理解されよう。大容量ストレージ808は、サブネットワーク健全性データ要求部21602を含み得る。一例では、サブネットワーク健全性データ要求部21602は、ネットワークに対する受信されたネットワーク健全性要求に応答して、サブネットワークからサブネットワーク健全性データを要求することができる。一例では、サブネットワークは、サブネットワーク健全性データ要求の受信に応答してデバイスからデバイス健全性データを要求することができる。サブネットワークはまた、受信されたデバイス健全性データから生成されたブロックチェーンデータを使用してサブネットワークシャドウフィルタを修正することによってサブネットワーク健全性データを生成するように命令され得る。
サブネットワークはまた、サブネットワーク健全性データ要求の受信に応答して複数のデバイスからデバイス健全性データを要求することができる。さらに、サブネットワークは、論理演算子を使用して受信した複数の健全性データを比較することによって、受信した複数のデバイス健全性データを使用してサブネットワークシャドウフィルタを修正することによってサブネットワーク健全性データを生成するように命令され得る。一例では、デバイスは、デバイスシャドウフィルタに基づいてデバイス健全性データを返すことができ、デバイスシャドウフィルタは、デバイス上のスケジュールされた健全性メッセージの欠如を追跡するデバイスブルームフィルタに基づいて生成され得る。デバイスシャドウフィルタを実装するための他の技法は、DHT、ブロックチェーンなどを含み得る。デバイスシャドウフィルタは、複数のシャドウフィルタを含むことができ、それぞれが、複数のブルームフィルタの時間間隔に対応する。
大容量ストレージ808は、ブロックチェーンデータから生成された受信したサブネットワーク健全性データに基づいて、ネットワークシャドウフィルタを修正するためのネットワークシャドウフィルタ修正部21604を含み得る。大容量ストレージ808は、ネットワークシャドウフィルタに基づいて、ネットワーク健全性の報告を提供するための報告提供部21606を含み得る。一例では、ネットワークシャドウフィルタは、論理演算子の適用を通じて動作する。
一例では、サブネットワーク健全性データリクエスタは、ネットワーク内で論理的に編成された複数のサブネットワークからのサブネットワーク健全性データ、およびいくつかの受信されたサブネットワーク健全性データに基づいてネットワークシャドウフィルタを修正するネットワークシャドウフィルタ変更子を要求し得る。この例および上で論じた他の例では、ブロックチェーンデータは、ネットワークトポグラフィのエンドポイントでネットワーク健全性の履歴記録を確立するためにブロックチェーントランザクションに含まれ得るブルームフィルタに基づくことができる。
図217は、一部の実施形態による、ネットワークおよびネットワークデバイスの健全性を報告するためのコードを含む非一時的機械可読媒体21700のブロック図である。同様の番号が付けられた項目は、図9において説明したとおりである。
非一時的機械可読媒体21700は、ネットワークに対する受信されたネットワーク健全性要求に応答して、サブネットワークからサブネットワーク健全性データを要求するようにプロセッサ902に指示するためのコード21702を含み得る。一例では、サブネットワークは、サブネットワーク健全性データ要求の受信に応答してデバイスからデバイス健全性データを要求することができる。サブネットワークはまた、受信されたデバイス健全性データから生成されたブロックチェーンデータを使用してサブネットワークシャドウフィルタを修正することによってサブネットワーク健全性データを生成するように命令され得る。サブネットワークはまた、サブネットワーク健全性データ要求の受信に応答して複数のデバイスからデバイス健全性データを要求することができる。さらに、サブネットワークは、論理演算子を使用して受信した複数の健全性データを比較することによって、受信した複数のデバイス健全性データを使用してサブネットワークシャドウフィルタを修正することによってサブネットワーク健全性データを生成するように命令され得る。一例では、デバイスは、デバイスシャドウフィルタに基づいてデバイス健全性データを返すことができ、デバイスシャドウフィルタは、デバイス上のスケジュールされた健全性メッセージの欠如を追跡するデバイスブルームフィルタに基づいて生成され得る。デバイスシャドウフィルタは複数のシャドウフィルタを含み、それぞれが、複数のブルームフィルタの時間間隔に対応し得る。
一例では、自己記述型デバイスは、バッテリ電源、無線技術に基づくインターネット接続、または低電力モードを有するプロセッサのうちの少なくとも1つを含み得、制約付き自己記述型デバイスとみなされる。
非一時的機械可読媒体21100は、ブロックチェーンデータから生成された受信したサブネットワーク健全性データに基づいて、ネットワークシャドウフィルタを修正するためのコード21704を含み得る。非一時的機械可読媒体21100は、ネットワークシャドウフィルタに基づいて、ネットワーク健全性の報告を提供するためのコード21704を含み得る。一例では、サブネットワーク健全性データリクエスタは、ネットワーク内で論理的に編成された複数のサブネットワークからのサブネットワーク健全性データ、およびいくつかの受信されたサブネットワーク健全性データに基づいてネットワークシャドウフィルタを修正するネットワークシャドウフィルタ変更子を要求し得る。この例および上で論じた他の例では、ブロックチェーンデータは、ネットワークトポグラフィのエンドポイントでネットワーク健全性の履歴記録を確立するためにブロックチェーントランザクションに含まれ得るブルームフィルタに基づくことができる。
IoTデバイスは、様々な接続デバイスおよびインフラストラクチャのネットワークのための制御チャネル機能を実行するために低電力広域ネットワーク(LPWAN)を使用することができる。モバイルネットワーク、有線ネットワークなど、IoTデバイスの電力および通信の可用性に応じて、他のネットワークを使用して説明した技法を実装することができる。制御チャネルLPWANは、デバイスの地理位置情報ベースのアクティブ化および非アクティブ化に使用され得る。制御チャネルLPWANはまた、ネットワーク全体のサービス警告およびブロードキャストに使用され得る。セキュリティ鍵を再生成する必要があることをデバイスに通知するなどのセキュリティ動作も、LPWANを使用して実行できる。さらに、LPWANは、インフラストラクチャインベントリを実行すること、またはデバイスからディスパッチされる位置メッセージをトリガすることなどの監査目的で使用され得る。
図218は、一部の実施形態による、制御チャネル21802が各接続にわたって使用され得る無線広域ネットワーク(WWAN)21800の概略図である。一例では、制御チャネルは、低電力広域(LPWA)技術を介して実行され得る。
WWAN 21800は、互いに動作する複数の技術およびネットワーク種別を含み得る。WWAN 21800は、コアルータ間にファイババックボーン21804を含み得る。WWAN 21800はまた、セルラーネットワーク接続21806を含み得る。一例では、セルラーネットワーク接続21806は、コアルータとセルラー送信機ノードとの間の接続であり得る。WWAN 21800はまた、無線ローカルエリアネットワーク(WLAN)21808へのネットワーク接続を含み得る。WWAN 21800はまた、メッシュネットワーク21810へのネットワーク接続を含み得る。一例では、メッシュネットワークは、802.15.4xメッシュなどの任意の種類の無線パーソナルエリアネットワーク(WPAN)を含み得る。WWAN 21800はまた、近距離無線通信ネットワーク21812を使用するエンドポイント間のネットワーク接続を含み得る。一例では、近距離無線通信ネットワークは、Bluetooth(登録商標)、Bluetooth(登録商標)low energy(BLE)、Zigbee(登録商標)、および他の同様の接続プロトコルを含むプロトコルを使用して作られてもよい。WWAN 21800はまた、デバイス間のLPWA接続21814の使用を含み得る。
上述のように、WWAN 21800は、制御チャネル21802を介してデバイス間で通信を管理することができる。上述のように、制御チャネルは、とりわけ、LoRaWAN(登録商標)などのLWPAプロトコルを含む、任意の数のプロトコルを使用することができる。本明細書で説明されるようにLWPAを使用してネットワークを介して制御チャネルを使用することは、地理位置特定機能、他のセンサ機能などを可能にし得る。ここに示されている地理位置情報機能は、グローバルな地理位置情報データポイントを符号化する方法、およびグリッド手法に基づいてゾーンIDを生成する方法を介して動作し得る。地理位置情報技法の一例は、ネットワークインフラストラクチャコンポーネント間のトランザクションおよびメッセージと共に使用するためのゾーン識別子を生成するものであり、ゾーン識別子はまた、人間が読める緯度、経度、および/または標高データに変換され得る。この情報を可視化してプロットするためには、図219に示すようにゾーン識別子グリッドの使用を含み得る。
図219は、一部の実施形態による、ゾーンに分割された物理的領域のマップ21900の概略図である。同様の番号が付けられた項目は、図218を参照して説明したとおりである。
示されている地図21900は、緯度線21902と経度線21904とを含む。一例では、これらの線によって形成されたグリッド正方形は、様々なゾーンを示すために使用され、各ゾーンにゾーンIDが与えられ得る。マップ21900は、それぞれがそれ自身のゾーンIDを有するゾーンへの物理的領域の分解を示すグリッド正方形のゾーン符号化オーバーレイを示す。一例では、ゾーン識別子グリッドサイズは、位置メトリックまたはゾーンマーキングユニットの修正などのパラメータ修正を介して構成され得る。このコンテキストに関連して使用されるように、パラメータ修正は、使用されている地理位置情報の方法のアルゴリズムフローへの変更をもたらさないこともある。
地理位置情報に対するゾーン識別子手法を使用することによって、とりわけ数千平方キロメートルから平方メートルの範囲のゾーンサイズを符号化および復号することができる。ゾーン識別子手法を使用することはまた、任意のサイズの物理的領域についてゾーンIDを計算し、符号化し、そして復号することを可能にし、ゾーンはグローバルな使用に適している。
これらのゾーンを制御チャネル21802に組み込むことは、ゾーン識別子(ID)21906の使用を含み得る。一部の実施形態では、リソース発見のための地理位置特定方法は、制御チャネルメッセージ21910および制御メッセージ21912自体に関係する1つまたは複数のゾーンを含むメッセージ21908をブロードキャストすることができる。一例では、メッセージ21908は、該当する場合、例えば制御チャネルメッセージ識別情報、ゾーン数、存続時間(TTL)、およびデータフィールドの長さに関する、メッセージ21908に関する情報を反映して、メッセージが含む他のデータの先頭に追加されるメッセージヘッダデータを含み得る。一例では、メッセージ21908は、認可、認証、およびフレームに添付され得るメッセージ完全性データなどのセキュリティ機能を含み得る。制御チャネルで使用するために、メッセージ21908は短くなり得、従って、より少ないリソースを使用することができ、その結果、送信時間を比較的短くし、電力使用量を減少させ得る。
図220は、一部の実施形態による、到着時間差を使用して地理位置情報を報告するためにモノのインターネット(IoT)デバイスによって使用される例示的な方法22000のプロセスフロー図である。図220の方法22000は、図221および図223に関して説明されるシステム22100および22300によって実施することができる。方法21400は、図8に関して説明したシステム802を使用して実行することができる。プロセスフローは、ブロック22002で開始し得る。
ブロック22002において、タイムスタンプ付きのペイロードが受信される。受信されたペイロードは、単一のペイロードまたはいくつかのデータのペイロードであり得る。ブロック22004において、ペイロードは、デバイスIDによって分類されてもよい。このようにして、複数のデバイスの1つまたは複数のタイムスタンプを比較することができる。ブロック22006において、デバイスについて受信された2つ以上のタイムスタンプ付きペイロードがあるか否かに関する判定が行われ得る。そうでない場合、プロセスフローはブロック22002に戻って、追加のタイムスタンプ付きペイロードを待つことができる。単一のデバイスについて受信されたタイムスタンプ付きペイロードが2つ以上ある場合、プロセスフローはブロック22008に進む。
ブロック22008において、同じデバイスに対する2つのタイムスタンプ間の時間差を計算することができる。ブロック22010において、時間差は、位置計算のための関数への入力であり得る。一例では、この関数は、最初にペイロードを提供したデバイスの座標から推定距離を、続いてx座標およびy座標に関して取得するために使用され得る。ブロック22010で使用され得る関数の一例は、以下により詳細に説明される双曲線関数であり得る。関数の出力は、物理空間内の地図上でデバイスを見つけるために使用され得る座標であり得る。
ブロック22012において、関数計算の出力はローカル座標からグローバル座標に変換され得る。グローバル座標が使用に十分であれば、変換は必要ない場合もある。ブロック22014において、生成された座標を用いてノード位置を推定することができる。このプロセスは、デバイスの位置を識別するために望まれる回数だけ、またはデバイスがネットワーク内のメッセージを介して位置を識別することを要求するたびに繰り返され得る。
上述したプロセスにおいて双曲線計算を使用することは、受信ゲートウェイの数が増加するにつれて精度を向上させ得る。例えば、標準的な共通ネットワーク地理位置情報手法は、追加の同種または異種ネットワークノードを含み得る本開示の協調ネットワークによって改善され得る。
図221は、一部の実施形態による、部分的にゾーンIDを使用して、異種ネットワーク内の到着時間情報に基づいて時間差を判定するためのネットワーク22000の概略図である。一般的に、地理位置情報は、産業、スマートシティ、小売、およびセキュリティベースのIoT、そして将来のインターネットアプリケーションおよびサービスにとって重要な差別化要因となり得る。地理的位置を計算し格納することは、ネットワークサーバ22102において行われ得る。通信リンクとネットワーク経路プロパティとの積として地理位置情報を取得するプロセスは、本明細書で説明される技法を使用して拡張することができる。共通の時間同期基準点を使用するネットワークパケットの到着時間差(TDOA)は、地理的位置を識別するのに役立ち得る。時間同期基準点の1つの例は、全地球測位デバイス(GPS)または他の衛星時間基準である。
送信ノード22104は、データまたはペイロードを受信ゲートウェイ22106に送信することができる。出発時にペイロードに添付されたタイムスタンプおよび到着時に受信されたタイムスタンプに基づいて、飛行時間(TOF)22108を計算することができる。一例では、受信機ゲートウェイ22104は、GPS 22110のような位置センサを含み得る。GPSは、TOFが計算されることを可能にするだけでなく、送信ノード22104によって使用されるための基準距離を提供することができる。TOFおよび開始距離を測定するゲートウェイの数が増加するにつれて、TOFおよび基準位置に関して追加のデータ収集が行われてもよく、従って送信ノード22104の位置はより正確にされ得る。ネットワーク内に存在する位置検知ノードの数を増やすために、ゲートウェイ22106は、センサ、例えばGPS 22110を含むことができる協働センサノード22112に接続され得る。
協調センサノード22112は、無線プロトコルおよび/または有線方法を介してゲートウェイ22106に接続され得る。送信ノード22104が無線ネットワークを使用してその位置を評価しているとき、送信ノード22104は、ペイロードが移動したパスの長さに関連する遅延時間(TOD)22114を有する、ゲートウェイ22110または協調センサノード22112で受信されるタイムスタンプ付きペイロードを送信することができる。
受信ゲートウェイは、共通のクロックを使用して時間同期させることができる。これらの追加のノードは異なるネットワークの一部であり、サーバ22102からゲートウェイ22106へのネットワークとは異なるプロトコルを使用することがあるため、協調センサノード22112の使用は、集中型処理ポイントでTDOA計算を使用する同種ネットワークの拡張である。センサノード22112は、関心のあるパケットを検知、観察、および受信し、タイムスタンプ付き検出情報を範囲内のゲートウェイノード22110に報告することができる。ネットワーク外であっても追加のノードを使用すると、パケットオブザーバの数が増える。位置を評価するために双曲線投影を使用する位置近似システムでは、パケットオブザーバの数が増えると、位置計算プロセスに使用されるゲートウェイ22110にローカルに存在する双曲線軌跡の数も増えることがある。
一例では、図220に示す方法は、図221に概略的に示すネットワーク上で実施することができる。例えば、描かれたノードを参照して、到着時間(TOA)は、以下の式を使用して送信ノード22104からゲートウェイへと計算され得る。 TOA
i=T
tx+TOF
i, 0≦i≦N 上式で、Tは、txまたは送信ノード22104からの送信時間を指す。項Nは、送信ノード22104(i)によってインデックス付けされた受信ゲートウェイの数を表し、l
iは、送信ノード22104と受信ゲートウェイ22106との間の見通し線距離である。一例では、22104は図221に示すとおりであり得る。上式および次式におけるTOAは到着時間を反映し、TOFは飛行時間であり、T
txは送信時間である。到着時間の変化は、以下の式を用いて計算することができる。 ΔTOA
ij=TOA
i-TOA
j=TOF
i-TOF
j
上式で、vは空気中または水中の光または音の速度であり、媒体の選択は、送信が行われる場所によって異なり得る。1つの例では、媒体は、ノード間に見通しの良いリンクを有する空気であり得る。
信号およびデータを収集するとき、データは双曲線関数手法を使用して処理されてよく、そのために、受信ゲートウェイからの推定距離l、およびその後xおよびy座標に関して使用され得る。一例では、これらの値は以下のように使用され得る。 l
i-l
j=δ
ij=vΔTOA
ij, 各δ
ijは、以下の式に示すように双曲線に沿った位置(x,y)に対応する。
双曲線関数は、以下の式を使用してローカル座標(x,y)からグローバル座標(X,Y)に変換することができる。
ネットワーク通過時間Ttransit 22116は、協調センサノード22112から受信ゲートウェイ22110へ情報を伝達するための時間を示す。以下の式では、協調センサノードがパケットを検出した時間が、i番目の協調ノードに対するTODiとして示されている。この情報を用いて、TODiは以下のように計算することができる。 TODi=Ttx+TOFi δTOAi=TODi-TOAi-Ttransit
非同種のプロトコル、デバイス、および地理的な位置を持つネットワークでは、これらの計算に使用される通過時間にばらつきがあり得る。これらの差は、サーバ22102が周期的なタイムスタンプ付きサウンディングパケットをゲートウェイ22110に送信することによって較正されてもよく、測定された通過時間はΔTOAiの計算から差し引かれる。この差し引きは、パケットが協調ノードから受信ゲートウェイ22110まで通過するのにかかる時間に起因する増大した遅延を相殺するのに役立ち得る。
図222は、一部の実施形態による、例示的な低電力広域ネットワークフレーム(LPWAN)にパックされた例示的な制御チャネルフレーム構造22200の概略図である。一例として、LPWANネットワークは、長距離広域ネットワーク(LoRaWAN(登録商標))フレームおよびプラットフォームとすることができるが、他のプラットフォームも企図され、このフレームは、制御チャネルフレーム構造22200を使用する一例として示されている。
例示的な制御チャネルフレーム構造22200は、長さXバイトのメッセージヘッダ22202、1からMバイトを含み得るゾーンIDフィールド22204、1からNバイトを含み得るデータフィールド22206、および長さYバイトのセキュリティ/メッセージ完全性チェック(MIC)フィールド22208を含み得る。例えば、ゾーンIDフィールド22204は、2~4バイトを含み得、データフィールドは、8~256バイトを含み得、そして完全性チェックフィールドは、2~4バイトを含み得る。プロトコルおよびデータに応じて、任意の数の長さを使用できる。
このフレームを通して送信される制御チャネルコマンドは、表4のリモートデプロイされたインフラストラクチャの広域またはゾーン固有制御のための動作の例である。注記として、表4に示すコマンドセットは一例であり、コマンドセットは拡張可能であり、特定の用途に対応するように後で修正することができる。
コマンドは、LoRaWAN(登録商標)を使用するLPWA技術を介してコマンドチャネルフレーム22200を介して渡されてもよい。フレーム配信の1つの例では、LoRaWAN(登録商標)外部フレームカプセル化は、フレームヘッダ(FHDR)22210、フレームポートフィールド(FPort)22212、およびフレームペイロードフィールド(FRMPayload)22212を含む。制御チャネルメッセージ22200は、FRMPayloadフィールド22214内にカプセル化されてもよい。このパッキング手法は、制御チャネルデータがアプリケーション固有の情報として扱われ得るため、LoRaWAN(登録商標)の互換性が必ずしも影響を受けるのではないことを意味する。制御チャネルデータはまた、DOCSIS、WEIGHTLESS、ZWave、イーサネット(登録商標)、WLAN、Bluetooth(登録商標)、AX.25、Zigbee(登録商標)、IEEE 802.15.4、IEEE 802.16、およびTIA/EIA-485を含むがこれらに限定されない技術のためのアプリケーションペイロードフレームフィールドにパックすることもできる。
一例では、帯域外制御チャネルシステムが、固定式、携帯式、移動式、空中、宇宙、体内、地下、および水上/水中のデバイスの制御に使用され得る。例としては、ストリートファーニチャ、広告用掲示板、車、トラック、無人航空機、自律型水中機などの航走体(vehicle)が挙げられる。地理的計算は、飛行禁止区域、ウェイポイントの更新、およびその他のナビゲーションツールの施行に特に役立ち得る。他の帯域外制御チャネルシステムシステムは、海底パイプライン検査ローバー、オイルライン検査およびワックス除去に使用されるスマートピッグ監視システム、キューブサットなどの衛星システム、環境制御およびセキュリティシステム、医療診断プローブ、リモート監視および作動を必要とするシステムを含む工業生産施設制御システムなどを含むデバイスの制御に使用され得る。
図223は、一部の実施形態による、リソースの発見および地理位置情報セクタ識別のためにIoTデバイス22300内に存在し得るコンポーネントの例のブロック図である。同様の番号が付けられた項目は、図8において説明したとおりである。
上でも示したように、図8を参照すると、大容量ストレージ808は、本明細書で説明されるグループ作成機能を実施するための複数のモジュールを含むことができる。大容量ストレージ808においてコードブロックとして示されているが、モジュールのうちのいずれも、例えば特定用途向け集積回路(ASIC)に組み込まれるなど、ハードワイヤード回路で完全にまたは部分的に置き換えられ得ることが理解されよう。
大容量ストレージ808は、制御チャネルデータを広域ネットワークフレームに挿入するための制御チャネルデータ挿入部22402を含み得る。広域ネットワークフレームは、送信前および送信中に制御チャネルデータをカプセル化するためのアプリケーションペイロードフレームフィールドを含み得る。制御チャネルデータは、第1のデバイスが送信ノードからペイロードを収集し、ペイロードからタイムスタンプを抽出し、タイムスタンプおよびゾーンIDを含むペイロードを返すための命令を含み得る。制御チャネルデータは、メッセージヘッダ、ゾーンIDフィールド、制御メッセージデータフィールド、およびセキュリティフィールドを含み得る。一例では、制御チャネルデータは、第1のデバイスがそのゾーンIDおよび送信ノードからの複数のタイムスタンプを返すための命令を含み得る。制御チャネルデータはまた、第2のデバイスが第1のデバイスにそのゾーンIDと送信ノードからのタイムスタンプとを返すための命令を含むことができ、一部の実施形態によれば、第2のデバイスは第1のデバイスを通過すること以外にサーバデバイスへの通信経路を持たない。
大容量ストレージ808は、例えばメッシュ送受信機810を使用して第1の送信プロトコルで第1のデバイスに、また例えばアップリンク送受信機814を使用して第2のプロトコルで第2のデバイスに、広域ネットワークフレームを送信するためのフレーム送信部22404を含み得る。制御チャネルデータは、第1のデバイスおよび第1のデバイスのプロトコルならびに第2のデバイスと第2のデバイスのプロトコルの両方にアクセスできるようになり得る。フレーム送信部22404は、中間送信機として動作し、第2のデバイスに再送信するための第1のデバイスへの命令を通して、広域ネットワークフレームを第2のデバイスに送信し得る。
大容量ストレージ808は、第1のデバイスが送信ノードからの検出された送信を返すことに応答して、送信ノードデータを修正するためのデータ修正部22406を含むことができる。送信ノードデータの変更は、送信ノードから検出された送信を返すゾーンIDおよびタイムスタンプを抽出することに基づくことができる。
一例では、装置はまた、双曲線関数と、第1のデバイスおよび第2のデバイスによって受信されたパッケージの複数のタイムスタンプと、第1のデバイスおよび第2のデバイスのゾーンIDと、を使用して送信ノードの位置を計算する計算部を含み得る。装置は、信号検出デバイスと信号受信デバイスとの間の送信通過時間に基づいて送信デバイスの位置を計算する計算部を含み得る。
図224は、一部の実施形態による、ネットワークおよびネットワークデバイスの健全性を報告するためのコードを含む非一時的機械可読媒体22400のブロック図である。同様の番号が付けられた項目は、図9において説明したとおりである。
非一時的機械可読媒体22400は、制御チャネルデータを広域ネットワークフレームに挿入するようにプロセッサ902に指示するためのコード22402を含み得る。広域ネットワークフレームは、送信前および送信中に制御チャネルデータをカプセル化するためのアプリケーションペイロードフレームフィールドを含み得る。制御チャネルデータは、第1のデバイスが送信ノードからペイロードを収集し、ペイロードからタイムスタンプを抽出し、タイムスタンプおよびゾーンIDを含むペイロードを返すための命令を含み得る。制御チャネルデータは、メッセージヘッダ、ゾーンIDフィールド、制御メッセージデータフィールド、およびセキュリティフィールドを含み得る。一例では、制御チャネルデータは、第1のデバイスがそのゾーンIDおよび送信ノードからの複数のタイムスタンプを返すための命令を含み得る。制御チャネルデータはまた、第2のデバイスが第1のデバイスにそのゾーンIDと送信ノードからのタイムスタンプとを返すための命令を含むことができ、第2のデバイスは第1のデバイスを通過すること以外にサーバデバイスへの通信経路を持たない。
非一時的機械可読媒体22400は、広域ネットワークフレームを第1の送信プロトコルを有する第1のデバイスおよび第2のプロトコルを有する第2のデバイスに送信するようにプロセッサ902に指示するためのコード22404を含み得、制御チャネルデータは、第1のデバイスおよび第1のデバイスのプロトコルならびに第2のデバイスと第2のデバイスのプロトコルの両方にアクセスできるようになる。フレーム送信部は、中間送信機として動作し、第2のデバイスに再送信するための第1のデバイスへの命令を通して、広域ネットワークフレームを第2のデバイスに送信し得る。
非一時的機械可読媒体22400は、第1のデバイスが送信ノードから検出された送信を返すことに応答して、送信ノードデータを修正するようにプロセッサ902に指示するコード22404を含み得る。送信ノードデータの変更は、送信ノードから検出された送信を返すゾーンIDおよびタイムスタンプを抽出することに基づくことができる。
一例では、機械可読媒体はまた、双曲線関数と、第1のデバイスおよび第2のデバイスによって受信されたパッケージの複数のタイムスタンプと、第1のデバイスおよび第2のデバイスのゾーンIDと、を使用して送信ノードの位置を計算する計算部を含み得る。機械可読媒体は、信号検出デバイスと信号受信デバイスとの間の送信通過時間に基づいて送信デバイスの位置を計算する計算部を含み得る。
本明細書で説明されるIoTデバイスおよびネットワークは、トレンドを識別し、問題を解決するなどのためにマイニングすることができる膨大な量のデータを生成することができる。しかしながら、データ分析は、実務家および研究者によって異なる解釈をされる場合もある。多種多様なデータ分析技法に基づいて、IoTのコンテキストでデータ分析の技術的課題について一般化するのは難しい場合もある。IoT技術の課題の1つは、IoTの実務家や研究者が彼らのIoTプラットフォームにわたって分析をより容易にデプロイできるようにするためのフレームワークを持つことである。
本明細書では、ビジュアル分析、デザイン科学、および知識工学からの影響を利用する分析のためのアーキテクチャフレームワークを説明する。図226に示されるモデルは、エッジベースの分析を含む分析一般を実行することに関与するタスクを含む。データ分析の統合ビューを提供することによって、このアーキテクチャフレームワークはデータ分析の実務家および研究者のための参照として動作し、これらのエージェント間のより大きな協調を可能にする。アーキテクチャフレームワークは、データ分析に影響を与える技術的課題を強調するのに役立ち得る。アーキテクチャフレームワークは、研究ベクトルに関連する発明の説明を可能にするためにも使用され得る。
データ分析は、エッジベースの分析などのオンラインベース分析とオフライン分析とに大別される。オフラインの間に代表的なデータから知識を生成することと、この知識をIoTプラットフォーム上などのオンラインシステムにデプロイすることと、を区別するために、異なるタイプの分析を使用することができる。オフライン分析のセクションは、エッジベースの分析に広く対応している。さらに、一例では、オフライン分析の階層構造は、データが様々な分析タスクを通過するにつれてより多くの知識が推論される、またはより大きなコンテキストが学習される、推論階層に対応し得る。オフライン分析の階層構造は、アクチュエータを制御するために使用され得る決定または動作をもたらし得る。この階層分析モデルは、複雑な分析タスクを特徴抽出、分類、決定アルゴリズムなどのサブタスクのクラスに分解できる段階的なフレームワークを提供する。加えて、サブタスクが分散可能な場合、オフライン分析フレームワークによる分類は、IoTプラットフォームにわたってワークロードを配置するための一般的なガイドとして動作し得る。一例では、ハードウェアプラットフォームは、センサノードおよびゲートウェイなど、類似のハードウェアリソースのプラットフォームのグループに分類され得る。プラットフォームが類似のハードウェアリソースのグループに分類される場合、ワークロード特性を分析要件の対象となるプラットフォーム特性と一致させることによって、あるクラスの分析タスクを特定のクラスのハードウェアプラットフォームにデプロイすることができる。
図225は、一部の実施形態による、データ分析の概念モデル22500の概略図である。一例では、概念モデル22500は、データマイニング22502およびデータ融合22504を含む。概念モデル22500は、1つまたは複数のネットワークシステムのストレージ内のデータ構造を表すことができる。例えば、データマイニング22502は、IoTネットワークまたはフォグデバイス内のデータアグリゲータ上で行われてもよく、データ融合22504は、データ収集システム上で実行されてもよい。
データマイニング22502は、バッチ方式またはオフライン方式で知識を生成するとみなされ得る。データ融合22504は、オンラインで知識を適用するとみなされ得る。概念モデル22500は、結合モデル22506に視覚分析パラダイムを組み合わせることによってデータマイニング22502を記述し、視覚分析パラダイムは、データ視覚化技法22508を介したデータ分析者とデータとの相互作用を中心的な活動として配置する。データマイニング22502におけるデザイン科学研究パラダイムは、設計を通してモデル評価サイクルの反復プロセスとして知識創造をモデル化し、知識ベース22512からの既存の知識とアプリケーションドメイン22514からのビジネスニーズを使用する分析モデル22510を構築する。データ融合22504環境からの入って来るデータは、データウェアハウス22516によってデータマイニング22502のために受信されてもよい。次いで、設計および構築分析モデル22510と可視化および評価モデル22508との間のサイクルで使用するために、データを整理し、変換し、結合モデル22506にロードする(22518)ことができる。
データ融合モデル22504は、概念モデル22500からデータを受信し、それをワークロードおよびリソース管理22520に適用することができる。ワークロードおよびリソース管理モデルから、データを信号融合モデル22522および信号改善モデル22524に送信することができる。
信号改善モデル22524内では、受信したデータを取り出し、このデータとセンサアクチュエータ22528で検知されたデータとを比較および交換することにより、信号を信号処理22526で処理することができる。1つのセンサアクチュエータ22528および信号プロセッサ22526のみが示されているが、複数のペアリングが存在してもよい。さらに、信号アクチュエータによって作動された任意のデータをデータマイニング22502のためにデータウェアハウス22516に返すことができる。ワークロードおよびリソースマネージャ22520からのデータはまた、特徴抽出またはオブジェクト改善モデル22530に送信されてもよく、それはデータおよび信号改善22524からの追加データを受信してもよい。ワークロードおよびリソースマネージャ22520からのデータはまた、イベントまたはシナリオモデル22532を検出、分類、または予測するために送信されてもよく、それはデータならびに特徴抽出またはオブジェクト改善モデル22530からの追加データを受信してもよい。ワークロードおよびリソースマネージャ22520からのデータは、決定モデル22534に作用するように送信されてよく、それはデータならびにイベントまたはシナリオモデル22532を検出、分類、または予測することから追加のデータを受信してもよい。決定に基づいて、決定モデル22534に対する作用から信号改善モデル22526に動作が送信され得る。決定に基づいて、決定モデル22534に対する作用から可視化管理モジュール22536に動作が送信され得る。
図226は、一部の実施形態による、モノのインターネット(IoT)システムのデータ分析を提供するためにIoTデバイスによって使用される例示的な方法22600のプロセスフロー図である。図226の方法22600は、図227に関して説明されるIoTデバイス22700によって実施することができる。方法22600は、図8に関して説明したシステム802を使用して実行することができる。プロセスフローは、ブロック22602で開始し得る。このプロセスの開始は、ターゲットシステムのデータ分析を評価しているクライアントデバイス、アプリケーション、または第三者による要求によってトリガされ得る。
ブロック22604において、工場監視設定における分散型センサなどの代表的なデータをデプロイ環境から取得することができる。このデータは、デバイスに物理的に接続し、UARTまたは他のインターフェースを介してデータをコンマ区切り値(CSV)ファイルフォーマットでプルすることによって取得され得る。拡張マークアップ言語(XML)などの他のフォーマット、またはとりわけマイクロソフトエクセルなどの独自フォーマットを使用することもできる。
ブロック22606において、データを様々なCSVファイルに挿入して、構造化問い合わせ言語(SQL)など問い合わせ可能データ、または他のデータ構造にすることができる。データは標準的な時系列スキーマに従って入力されてもよく、センサはテーブル内にそれ自体の列を有し、各行は固有のタイムスタンプを有してもよい。
ブロック22608において、データベースをスキャンして、タイムスタンプが複製されているデータ、または欠けているデータなどの不良データを識別することができる。これは、ユーザによって実行されてもよいし、複製値および他の障害、あるいはその両方を探索する自動化ツールを使用して実行されてもよい。この複製されたデータは除去され得る。ブロック22610において、データ分析が実行され得る分析環境が選択され得る。これは、例えば、Rベースのデータツール、pythonベースのデータツール、およびその他のビッグデータツールであり得る。ブロック22612において、分析のためにデータを環境にロードすることができる。ブロック22614において、モデルを仮定することができるように、分析のための環境内でデータを可視化してデータの全体構造を理解することができる。構造は、サンプル間の時間的関係、および異なるセンサからのサンプル間の関係を含む。データ間の関係を理解するために、相互相関/自己相関などの様々な数学的ツールを使用することができる。
ブロック22616において、分類の問題の場合にデータを捕捉する、またはデータから有用なデータを抽出するモデルが提案され得る。ブロック22618において、提案されたモデルの成功は、アプリケーションの目的を達成するために評価され得る。例えば、モデルが分類子である場合、モデルの性能は、偽陽性、真陽性、および偽陰性の数に関して評価され得る。
ブロック22620において、性能がアプリケーションの目的を満たさない場合、プロセスフローは、ブロック22614に戻り、データが可視化されて再び検査され得る。しかしながら、ブロック22620において、モデル成功の尺度がアプリケーションの目的によって設定され得るユーザ指定の閾値を上回ると判定された場合、プロセスフローはブロック22622に進むことができる。
ブロック22622において、モデルを分析してワークロードを計算することができる。ワークロードの計算は、ワークロードの計算、メモリおよびネットワークならびにエネルギーの要件をプロファイリングすることを含み得る。ブロック22624において、ワークロードを分解する手段が識別され得る。一例では、ワークロードを分解するための手段は、並列処理またはモジュール式直列依存タスクを介してもよい。ワークロードの分解の別の例は、分類タスクのためであってもよく、前処理、特徴抽出、および分類タスクが分離され得る。サブワークロードの実行ワークロードの特徴付けは、上記のようなメトリックを少なくとも部分的に使用して実行され得る。
ブロック22626において、利用可能なデバイスは、分散型ネットワークにおいてエニュメレーションされ、利用可能なデバイスが特性を取得し得る。一例では、特性のエニュメレーションおよび取得は、各デバイス上で一連のベンチマークを実行し、メモリ、コンピューティング、ネットワーキング、およびエネルギー容量を測定することを含み得る。ワークロードは、デバイスと密接に合意しているデバイス上のサブワークロードを含むことができる。合意のレベルは、必要なリソースの観点からワークロードを分類し、利用可能なリソースの観点からデバイスを分類し、次いで、このリストのランキンブに従ってワークロードとデバイスとをペアにすることで取得され得る。
ブロック22628において、ワークロードは、セキュアコピー(SCP)などの適切なプロトコルを使用してデバイスに配置され得る。ブロック22630において、システムの性能は、リソース使用量およびアプリケーション目的の観点から継続的に監視され得る。ブロック22632において、プロセスは終了または再開することができる。
図227は、一部の実施形態による、IoTシステムのデータ分析を提供するためにIoTデバイス22700に存在し得るコンポーネントの一例のブロック図である。同様の番号が付けられた項目は、図8において説明したとおりである。
上でも示したように、図8を参照すると、大容量ストレージ808は、本明細書で説明されるグループ作成機能を実施するための複数のモジュールを含むことができる。大容量ストレージ808においてコードブロックとして示されているが、モジュールのうちのいずれも、例えば特定用途向け集積回路(ASIC)に組み込まれるなど、ハードワイヤード回路で完全にまたは部分的に置き換えられ得ることが理解されよう。大容量ストレージ808は、選択された相互作用型分析環境にデータをロードするためのデータロード部22702を含み得る。一例では、データは、環境からの代表的なデータセットに基づいてロードされてもよく、相互作用型分析環境は、データマイニング環境およびデータ融合環境のうちの少なくとも1つであるべきである。選択された相互作用型分析環境にロードする前に、データを整理して整理することができる。相互作用型分析は、第1のデータサンプルと第2のデータサンプルとの間の時間的関係を示し得る。さらに、相互作用型分析は、第1のサンプルおよび第1のセンサと第2のデータサンプルおよび第2のセンサとの間の関係を示し得る。ワークロードは、ワークロードの計算要件、メモリ要件、およびネットワーク要件のプロファイルを含み得る。一例では、ワークロードは、デバイス上の複数のサブワークロードを含み、ワークロードは、必要とされるリソースおよび利用可能なリソースに関してワークロードを分類し、必要とされるリソースおよび利用可能なリソースに基づいて、ワークロードをデバイスにペアリングすることによって得られるデバイスとの合意を含むことができる。
大容量ストレージ808は、提案されたモデルがデータにフィットするか否かを判定するためのフィット判定部22704を含むことができ、提案されたモデルは、複数のデバイスで処理するための分解可能部分のワークロードを含む。ワークロードは、並列処理およびモジュール式直列依存タスクのうちの少なくとも1つを通して分解される。ワークロードはまた、分類タスクのために分解されてもよく、前処理、特徴抽出、および分類タスクが分離され得る。一例では、IoTデバイスは、デバイスによる実行のためにワークロードをデバイスにマッピングする前にワークロードを分解するためのプロセッサを含み得る。一例では、プロセッサはまた、マッピングおよびデバイス上のワークロードの実行に続いて使用されるリソースに関してプラットフォームの性能を計算することができる。
一例では、大容量ストレージ808は、デバイスによる実行のためにワークロードをデバイスにマッピングするためのワークロードマップ部22706を含み得る。一例では、データマイニング環境は、アプリケーションドメインからの、および環境からの代表的なデータセットに対応する格納された知識ベースからのデータを組み込む。
図228は、一部の実施形態による、ネットワークおよびネットワークデバイスの健全性を報告するためのコードを含む非一時的機械可読媒体22800のブロック図である。同様の番号が付けられた項目は、図9において説明したとおりである。
非一時的機械可読媒体22400は、選択された相互作用型分析環境にデータをロードするようにプロセッサ902に指示するためのコード22802を含み得る。一例では、データは、環境からの代表的なデータセットに基づいてロードされてもよく、相互作用型分析環境は、データマイニング環境およびデータ融合環境のうちの少なくとも1つであるべきである。選択された相互作用型分析環境にロードする前に、データを整理して整理することができる。相互作用型分析は、第1のデータサンプルと第2のデータサンプルとの間の時間的関係を示し、相互作用型分析は、第1のサンプルおよび第1のセンサと第2のデータサンプルおよび第2のセンサとの間の関係をさらに示す。ワークロードは、ワークロードの計算要件、メモリ要件、およびネットワーク要件のプロファイルを含み得る。一例では、ワークロードは、デバイス上の複数のサブワークロードを含み、ワークロードは、必要とされるリソースおよび利用可能なリソースに関してワークロードを分類し、必要とされるリソースおよび利用可能なリソースに基づいて、ワークロードをデバイスにペアリングすることによって得られるデバイスとの合意を含むことができる。
非一時的機械可読媒体22800は、提案されたモデルがデータに適合するか否かを判定するようにプロセッサ902に指示するコード22804を含み得、提案されたモデルは、複数のデバイスで処理するための分解可能部分のワークロードを備える。ワークロードは、並列処理およびモジュール式直列依存タスクのうちの少なくとも1つを通して分解され得る。ワークロードはまた、分類タスクのために分解されてもよく、前処理、特徴抽出、および分類タスクが分離され得る。一例では、IoTデバイスは、デバイスによる実行のためにワークロードをデバイスにマッピングする前にワークロードを分解するためのプロセッサを含み得る。一例では、プロセッサはまた、マッピングおよびデバイス上のワークロードの実行に続いて使用されるリソースに関してプラットフォームの性能を計算することができる。
非一時的機械可読媒体22800は、デバイスによる実行のためにワークロードをデバイスにマッピングするようにプロセッサ902に指示するためのコード22706を含み得る。一例では、データマイニング環境は、アプリケーションドメインからの、および環境からの代表的なデータセットに対応する格納された知識ベースからのデータを組み込む。
IoTネットワーク内でアクティブなデータ収集およびモデリングを使用することに加えて、IoTデバイスは、リモートで処理され、他のシステム、デバイス、またはユーザによって消費されるデータのパッシブプロデューサになり得る。一部のフレームワークでは、データは、ネットワークを介して流れ、フォグまたはクラウドのいずれかにリモートで格納および処理される。アプリケーションに基づいて、処理された情報は、データを生成したIoTノードに地理的に近い1つまたは複数のIoTデバイスに配信され得る。
本開示では、ネットワーク内処理パラダイムは、統合された計算および通信システムとして動作するためにIoTネットワークを活用することができる。1つの方法は、データがネットワークを介して送信されるときにデータを協調的に処理することによって、IoTネットワークが並列プロセッサとして機能することを可能にする。並列方式でデータを処理することは、宛先IoTデバイスにおけるさらなる処理への依存を低減または除去することができる。
IoTネットワークに近接ベースの並列処理を提供することで、ネットワークで生成されたデータをそのネットワークに対してローカルに保つことができる。近接ベースの並列処理はまた、外部システムおよびネットワークにデータを転送するプロセスを低減または排除することができ、それによって外部データの公開における潜在的なセキュリティおよびプライバシーの欠陥を低減する。近接ベースの並列処理は、IoTシステムに存在するレイテンシを減らすことができ、生成された情報のローカル性を保つことができる。計算のためのレイテンシの減少、およびローカル性の保存は、処理された情報のコンシューマが感知デバイスの近くに位置し得る自動または半自動制御用途に役立ち得る。
IoTネットワークにおける並列処理の1つの例では、人工ニューラルネットワーク(ANN)を、IoTネットワークによって実施される一般的な並列プロセッサとして使用することができる。ANNは任意の測定可能な関数に近似する。一例では、フィードフォワードニューラルネットワークによって実行される計算は、同時に実行される異なるタスクに分割されてもよい。処理は、ネットワーク内のリソースの使用を最適化しながらデータを処理するために、分散処理、保存されたローカル性、低減されたレイテンシ、および同様の特性を活用することができる。各ノードで利用可能なリソース、IoTネットワークの接続、ネットワーク内の情報のプロデューサおよびコンシューマを考慮して、様々なコンピューティングタスクを複数のIoTノードに分散することができる。
一例では、計算タスクは、計算タスクをネットワーク内の複数のプラットフォーム上でのデプロイに適した断片に分離するという計算上の慣例を適用するフォグリソースにわたるデプロイのために分解され得る。1つの例では、デプロイおよび計算手法は、計算プラットフォーム間でデータを交換するためのツールとして別の通信ネットワークを利用することになる、フォグにわたるデプロイに基づき得る。この例では、計算と通信とは別々のプロセスとみなされる。従って、この例示的なシステムにおける分散コンピューティングのデプロイは、計算をサポートするためのネットワークトポロジまたは動作を考慮することなく行われる。現在開示されている技法は、一部の実施形態に従って、通信および計算を一緒に考慮している。
図229は、一部の実施形態による、分散型ニューラルネットワークマッピングおよびリソース管理においてモノのインターネット(IoT)デバイスによって使用される例示的な方法22900のプロセスフロー図である。図229の方法22900は、図231に関して説明されるIoTデバイス23100によって実施することができる。方法22900は、図8に関して説明したシステム802を使用して実行することができる。プロセスフローは、ブロック22002で開始し得る。
ブロック22902において、IoTデバイスは、接続ノードおよび物理ネットワーク特性を識別することによってネットワークトポロジマップおよびリストを取得することができる。物理ネットワーク特性は、正確な位置または互いに対する相対位置を含み得る。物理ネットワーク特性はまた、ノード間距離、クラスタリング、分散情報、受信信号強度、および信号雑音比を含み得る。IoTデバイスによるネットワークトポロジの取得は、ニューラルネットマッピングシステムによるさらなる使用のために、IoTネットワークトポロジの抽象化をさらに提供し得る。これは、デバイスの互いに対する近接度およびデバイスの現在の電力レベルを判定することを含み得る。抽象化の一部として、信号測定値をIoTデバイスから取得することができる。信号測定の例は、受信信号強度インジケータ(RSSI)およびブロードキャスティング電力を含み得る。トポロジが取得されると、IoTデバイスは、デバイス間のネットワークで予想されるパス損失と干渉をモデル化できる。抽象化の結果は、IoTデータベース22904に格納することができる。
ブロック22906において、本方法は、IoTノードリソースを抽象化する段階を含み得る。これらのリソースとしては、電力レベル、利用可能なストレージスペース、現在の処理負荷、ネットワーキング能力、稼働時間、およびノードの信頼性情報を挙げることができる。一例では、ネットワーキング能力は、インターフェース種別、レイテンシ、およびデータ容量を含み得る。一例では、抽象化されたIoTリソースは、アプリケーションプログラミングインターフェース(API)ラッパー機能または表現状態呼び出しを介して公開され得る。IoTノードリソースを抽象化することは、残留メモリ、電力、およびストレージのソフトウェア抽象化を含み得る。別のサブタスクは、システムリソース情報のためのAPIラッパー機能を有することを含み得る。抽象化されると、IoTデバイスはアクセス可能なリソース情報を取得できる。
ブロック22908において、ニューラルネットワークトポロジは、処理のためのソースデータを有する入力ノード、中間ニューラルネット処理のための隠蔽ノード、およびシンクデータを使用する出力ノードの位置を判定することなどのサブタスクを実行することによって判定され得る。この方法の他の段階に関して論じたように、データは、データベース22904または同等の記憶媒体にローカルまたはリモートのいずれかに格納され得る。ニューラルネットワークトポロジを抽象化することは、例えば、とりわけ、信号三角測量を使用してユークリッド距離を使用して位置を識別すること、または直接全地球測位システム(GPS)位置報告を含むことができる。
ブロック22910において、本方法は、マッピング最適化を実行する。マッピング最適化は、現在および過去のネットワークおよびノード特性に基づいてノードタスクを最適に割り当てることを目的として、多変量目的関数を選択および改善することを含み得る。目的関数は、例えば、コスト、信頼性、処理速度および結果生産時間、または地理的領域の広がりを選択することができる。ブロック22910の別のサブタスクは、整数線形計画、目的関数の選択、制約の改善、およびモデル開発を策定することを含み得る。
ブロック22912において、本方法は、ニューラルネットワークトポロジをネットワーク上にオーバーレイする段階を含み得る。これは、最適化ステージから得られた役割およびタスクをネットワーク内の物理ノードにマッピングすることを含み得る。ノードのタスクが作成、準備され、物理ノードまたはデバイスにディスパッチされる。ブロック22912の1つのサブタスクは、最適化ステージからの役割およびタスクのデプロイの成功を確認することを含み得る。タスクおよび役割のディスパッチが成功した後、システムは、後続のワークロード割り当て要求に備えて、更新されたネットワークおよびノードマッピングの行使を開始することができる。次いで、プロセスフローは終了し、必要に応じてIoTを上記の言語で説明したように通信および処理のノードに沿って分散可能な一連のタスクに抽象化するために再び開始することもできる。
図230は、一部の実施形態による、リソース管理のための分散型ニューラルネットワークマッピング23000の概略図である。示される例示的なIoTネットワークトポロジにおける入力ノード、出力ノード、および隠蔽ノードを識別する記号の説明文がブロック23002で提供される。
入力IoTネットワークトポロジ23004では、3つの入力層ノード、4つの隠蔽層ノード、および2つの出力層ノードが、IoT接続のメッシュ内に散在して示されている。一例では、IoTトポロジの各ドットはノードを表す。ノードは、上で説明したように、また本出願全体を通じて説明するように、IoTデバイス、サーバ、または他の相互接続可能な通信および処理ツールを表すことができる。一例では、入力IoTネットワークトポロジは、ニューラルネットワークを物理IoTネットワークにマッピングすることを最適化する前のノード接続の可視化を表すことができる。図示されたノードまたはデバイスのそれぞれは、1つまたは複数のニューロンとして作用し、接続は無線リンクを介して実現され得る。
マッピングフレームワーク23006は、入力ノードから出力ノードへの情報の送信のための送信電力および送信時間を最小にするためにノード間のマッピングを試みることを表すことができる。マッピングは、各デバイス上で利用可能なリソース、各デバイスの能力、およびIoTネットワークの接続を考慮に入れることができる。IoT可視化ノードネットワークのメッシュに示されるノード接続はそれぞれ、特定のノードにわたる情報の重みおよび転送時間を表すことができる。
マッピングフレームワーク23006は、出力IoTネットワークトポロジ23008のためのデータパスを示すマッピングをもたらし得る。出力IoTネットワークトポロジは、ニューロンをマッピングする物理ノードの識別情報を含み得る。マッピングは、基礎となるIoTネットワークおよびオーバーレイニューラルネットワークに関連するすべての入力を使用する最適化モデルを策定することによって達成され得る。最適化モデルへの入力は、IoTトポロジおよび各ノードで利用可能なリソース、IoTトポロジ上にマッピングされるニューラルネットワークトポロジ、ソースノードのセット、および出力ノードのセットを含み得る。IoTネットワークトポロジの目的のために、各ノードにおけるリソースは、例えば、とりわけ、メモリリソース、電力リソース、センサリソース、またはストレージリソースを指すことができる。同様に、ニューラルネットワークトポロジは、少なくとも図230に示されるように、複数の層および隠蔽ニューロンを含むIoTトポロジにマッピングされ得る。
図231は、一部の実施形態による、分散型ニューラルネットワークマッピングおよびリソース管理のためにIoTデバイス23100に存在し得るコンポーネントの一例のブロック図である。同様の番号が付けられた項目は、図8において説明したとおりである。
一例では、大容量ストレージ808は、本明細書で説明されるマッピングフレームワークを実装するための複数のモジュールを含むことができる。大容量ストレージ808においてコードブロックとして示されているが、モジュールのうちのいずれも、例えば特定用途向け集積回路(ASIC)に組み込まれるなど、ハードワイヤード回路で完全にまたは部分的に置き換えられ得ることが理解されよう。大容量ストレージ808は、IoTネットワーク内の複数のIoTノード間の接続を示すIoTネットワークトポロジを識別するためのIoTネットワークトポロジ識別部23102を含み得る。IoTネットワークトポロジは、例えば、ノード間距離、クラスタリング、分散情報、受信信号強度、および信号雑音比のうちの少なくとも1つを含むノード特性を示す。IoTネットワークトポロジを識別することは、複数のノードの互いの近接性、複数のノードの現在の電力レベル、および複数のノードに関する信号測定を判定することを含み得る。一例では、複数のノードの信号測定値を取得することは、少なくとも受信信号強度インジケータまたはブロードキャスト電力を取得することを介してであり得る。
大容量ストレージ808は、IoTネットワークトポロジ内で識別された各IoTノードのIoTノードリソースを識別するためのIoTノードリソース識別部23104を含み得る。IoTノードリソースは、電力レベル、利用可能なストレージスペース、現在の処理負荷、ネットワーキング能力、稼働時間、またはノードの信頼性情報のうちの少なくとも1つを含み得る。
大容量ストレージ808は、ノード距離およびノード位置のニューラルネットワークトポロジを識別するためのニューラルネットワークトポロジ識別部23106を含み得る。ニューラルネットワークは、人工ニューラルネットワークであり得る。
大容量ストレージ808は、IoTノードリソース、ノード距離、およびノード位置に基づいてマッピングを最適化するためのマッピング最適化部23108を含み得る。最適化されたマッピングは、複数のノードのノード位置を使用して同一の物理的位置に位置する1つまたは複数のノードを識別することによって、IoTネットワークにわたって分解可能タスクを処理する位置を保存する。マッピングの最適化は、入力ノードから出力ノードへの情報の送信のための送信時間を判定することを含む。
大容量ストレージ808は、IoTネットワーク上のニューラルネットワークトポロジのオーバーレイに基づいて、複数のIoTノードの分解可能なタスクを処理するための分解可能タスクプロセッサ23110を含み得る。複数のIoTノードにおける分解可能なタスクの処理は、IoTノードが同じネットワーク上の物理的な位置に位置すると識別されたか否かに基づいて分解可能なタスクの部分を複数のIoTノードにディスパッチすることを含む。ニューラルネットワークトポロジのオーバーレイは、例えば、入力層、隠蔽層、および出力層を含む3つの層を含み得る。
図232は、一部の実施形態による、ネットワークおよびネットワークデバイスの健全性を報告するためのコードを含む非一時的機械可読媒体23200のブロック図である。同様の番号が付けられた項目は、図9において説明したとおりである。
非一時的機械可読媒体23200は、IoTネットワーク内の複数のIoTノード間の接続を示すIoTネットワークトポロジを識別するようにプロセッサ902に指示するためのコード23202を含み得る。IoTネットワークトポロジは、例えば、ノード間距離、クラスタリング、分散情報、受信信号強度、および信号雑音比のうちの少なくとも1つを含むノード特性を示し得る。IoTネットワークトポロジを識別することは、複数のノードの互いの近接性、複数のノードの現在の電力レベル、および複数のノードに関する信号測定を判定することを含み得る。一例では、複数のノードの信号測定値を取得することは、少なくとも受信信号強度インジケータまたはブロードキャスト電力を取得することを介してであり得る。
非一時的機械可読媒体23200は、IoTネットワークトポロジ内で識別された各IoTノードのIoTノードリソースを識別するようにプロセッサ902に指示するためのコード23204を含み得る。IoTノードリソースは、電力レベル、利用可能なストレージスペース、現在の処理負荷、ネットワーキング能力、稼働時間、またはノードの信頼性情報のうちの少なくとも1つを含む。
非一時的機械可読媒体23200は、ノード距離およびノード位置のニューラルネットワークトポロジを識別するようにプロセッサ902に指示するためのコード23206を含み得る。ニューラルネットワークは、人工ニューラルネットワークであり得る。
非一時的機械可読媒体23200は、IoTノードリソース、ノード距離、およびノード位置に基づいてマッピングを最適化するようにプロセッサ902に指示するためのコード23208を含み得る。最適化されたマッピングは、複数のノードのノード位置を使用して同一の物理的位置に、例えば交差点、建物、建物内の部屋など都市の領域に位置する1つまたは複数のノードを識別することによって、IoTネットワークにわたって分解可能タスクを処理する位置を保存する。 マッピングの最適化は、入力ノードから出力ノードへの情報の送信のための送信時間を含む。
非一時的機械可読媒体23200は、IoTネットワーク上のニューラルネットワークトポロジのオーバーレイに基づいて、複数のIoTノードの分解可能なタスクを処理するようにプロセッサ902に指示するためのコード23210を含み得る。複数のIoTノードにおける分解可能なタスクの処理は、IoTノードが同じネットワーク上の物理的な位置に、またはルータもしくはピアツーピア接続によって結合されるなど同じローカルネットワーク上に位置すると識別されたか否かに基づいて分解可能なタスクの部分を複数のIoTノードにディスパッチすることを含み得る。ニューラルネットワークトポロジのオーバーレイは、例えば、入力層、隠蔽層、および出力層を少なくとも含む3つの層を含み得る。
一部の実施形態では、IoTネットワークは、複数の機能のためにブロックチェーンを利用することができる。これらには、例えば、とりわけグループ識別情報の作成、型識別情報の作成、信頼測定値のアーカイブ、オブジェクト識別子の登録、セキュアなデバイスの導入、イベント追跡、およびデータロギングが含まれ得る。しかしながら、ブロックチェーン同期は、制約のあるデバイスでは困難な場合がある追加のオーバーヘッドが導入され得る。どこからでもトランザクションを受け入れるようなローカライズされていないブロックチェーンを使用すると、帯域幅に制約のあるIoTサブネットが飽和し、その結果、とりわけ機能的な遅延やデータの損失などの問題が発生する可能性がある。その結果、需要を下げるためにブロックチェーン処理をローカライズするための戦略が必要になり得る。さらに、より小さなブロックチェーンは、ノードがより少ないために、信頼性がより低くなり得る。
図233は、一部の実施形態による、ネットワーク階層23304内のレベルに関連するブロックチェーン23302の階層の概略図である。ブロックチェーン23302の階層は、ブロックチェーン23302を維持し使用するためにローカルサブネットトラフィックの効率を高めることができる。効率をさらに向上させるために、ブロックチェーン23304は、図235に関してさらに説明されるように、マークルツリー23306の関連する階層によってインデックスを付けられ得る。本明細書で使用されているように、マークルツリーは、一般に、すべての非リーフノードがラベルのハッシュまたは2つの子ノードの値でラベル付けされたハッシュツリーの形態である。
ブロックチェーン操作がサブネット内に含まれるように、IoTサブネットはそれぞれサブネットにローカルなブロックチェーンを持つことができる。従って、ローカルブロックチェーンを頻繁に使用しても、ローカルサブネットに接続するサブネットが飽和することはない。
図233に示されるように、部屋またはローカル環境などのローカルIoTネットワーク(R1)23308は、関連するブロックチェーン23310を有することができる。R1 23308で行われる、またはブロックチェーン23310にコミットされ得るトランザクション23312に組み込まれる動作は、アイデンティティ、グループコンポジション、セキュリティ、オペレーション追跡などのアクティビティを記録する。トランザクション23312は、ブロックチェーン23310内のブロックに格納することができる。関連付けられたハッシュコードは、ブロックに対して計算され、そしてマークルツリー23306に保存され得る。マークルツリー23306において、三角形は、上部の親ノードと、下部の2つの子ノードを表す。この例では、R1マークルツリー23314およびR2マークルツリー23316は、ブロックチェーン23310内の異なるブロックに関連付けられてもよい。
ローカルIoTネットワークR1 23308は、ブリッジまたはルータ23320を介してホームネットワーク(H1)23318などのより上位レベルのIoTネットワークに結合されてもよい。H1 23318は、H1 23318からのトランザクション23324を記録するためのブロックチェーン23322を含み得る。毎秒、毎分、または他の繰り返し期間など、周期的に、チェックポイントトランザクション23326が、親ネットワークH1 23318に属するブロックチェーン23322内に作成され得る。チェックポイントトランザクション23326は、他のマークルツリーの中でもとりわけ、R1マークルツリー23314または23316のハッシュ値、あるいは下位レベルブロックチェーン23310にコミットされたブロックのサンプルを含むことができる。
マークルツリーR1 23314およびR2 23316の最も高い頂点23328は、ネットワーク参照23330によって、H1マークルツリー23334の最も低いレベル23332にリンクされている。同様に、H1 23318は、別のブリッジまたはルータ23338を介してIoTネットワーククラウド(C1)23336などの次に上位のネットワークに結合されてもよい。統合チェックポイントトランザクション23340が、C1 23336に関連するパブリックまたはプライベートブロックチェーン23342内に作成され得る。さらに、C1 23336は、トランザクション23344をブロックチェーン23342に保存することができる。C1マークルツリー23348の最も低いレベル23346は、H1マークルツリー23334などの、次の下位レベルのマークルツリーの最も高いレベルの頂点23352のハッシュコードから作成されたネットワーク参照23350を含むことができる。
単純なカスケードブロックチェーンとそれに関連する3つのレベルのマークルツリーのセットとして表示されているが、このプロセスには、多数の参加者とレベルに関するルートブロックチェーンまでのカスケードが含まれ得る。周期的なチェックポイントにより、ローカルトラフィックの大部分を親ブロックチェーンから分離できるため、ブロックチェーンを使用して完全性を保護し続けながら、IoTネットワークのスケーラビリティを実現できる。ブロックチェーンを多用する場合は、新しいブロックチェーンをインスタンス化して許可するための定義済みの方法を用意しておくと便利である。
図234は、一部の実施形態による、ブロックチェーン階層を構築するための例示的な方法23400のプロセスフロー図である。図234の方法23400は、図242に関して説明されるIoTデバイス24200によって実施することができる。方法23400は、例えば、IoTデバイスが起動されるかまたはローカルネットワークに参加するときに、ブロック23402において開始し得る。
ブロック23404において、現在の、またはローカルの、IoTサブネット内のデバイスは、トランザクションデータを現在のブロックチェーンに書き込む。本明細書で説明されているように、トランザクションデータは、IoT動作イベント、トラステッドコンピューティング測定値、デバイスまたはグループアイデンティティ情報などであり得る。
ブロック23406において、ブロックチェーンブロックが「同期」ブロックであるか否かに関する判定が行われ得る。そうでない場合、プロセスフローはブロック23404に戻る。ブロック23406でブロックが同期ブロックであると判定された場合、ブロック23408において、ゲートウェイブロックチェーンノードは、同期ブロックのハッシュコードを含むメッセージを構築する。メッセージは、次のレベルのブロックチェーンに送信される。
ブロック23410において、次のレベルのブロックチェーン内のマイナーは、下位のブロックチェーンを指し示すネットワーク参照と共に、メッセージを現在のブロックにコミットする。ブロック23412において、次のレベルのブロックチェーンがあるか否かに関する判定が行われる。ある場合、プロセスフローはブロック23406に戻り、ブロックが同期ブロックであるか否かを判定する。ない場合、IoTデバイスが通常の動作に戻って別の周期的なブロックチェーン書き込みを待つとき、方法23400は、ブロック23414において終了する。
図235は、一部の実施形態による、図233に関して説明されたマークルツリーの拡大図である。説明したように、ブロックチェーンを使用した多くのIoTユースケースでは、ブロックチェーンブロックを使用して完全性が検証された情報の取得を要求する。ただし、ブロックチェーントランザクションの性質上、重要な測定値がチェーン内で互いに近接していない可能性がある。従って、ブロックチェーンの効率的なインデックス付けが必要とされている。これは、チェーンをインデックス付けするためにマークルツリーを使用することによって実行することができる。図233に関して説明したように、ネットワーク階層を横断するブロックチェーンは、トランザクションをインデックス付けするために、ネットワーク参照と共にマークルツリーを使用することができる。ブロックチェーンには独自のマークルツリーまたはインデックスがあり得る。チェックポイントトランザクションでは、最初にチェックポイントを生成した子ブロックチェーンへのコンテキスト切り替えが必要である。チェックポイントされたブロックに関する洞察を得ようとする探索エンジンは、例えば、ブロックチェーン階層の下位レベルについてマークルツリーインデックスを探索するために、とりわけネットワーク参照23330または23350をたどることによって、ネットワークを横断する必要があり得る。
図236は、一部の実施形態による、マークルツリーインデックスを使用してブロックチェーン階層を探索するための例示的な方法23600のプロセスフロー図である。図236の方法23600は、図242に関して説明されるIoTデバイス24200によって実施することができる。本方法は、例えば、データを見つけるためのクエリが受信されたときに、ブロック23602において開始し得る。ブロック23604において、クエリデータは、階層型ブロックチェーン内に配置され得る。ブロック23606において、データ値は、データ値をブロックハッシュ値に関連付けるインデックスまたはルックアップテーブルを調べるために使用され得る。ブロック23608において、現在のブロックチェーンが、階層型ブロックチェーンのルートを指すように設定される。ブロック23610において、ブロックハッシュ値は、現在のブロックチェーンについてマークルツリーを調べ、ブロックチェーン内のブロックのチェーン内のターゲットブロックの位置を判定するために使用される。
ブロック23612において、ターゲットブロックが子ブロックチェーンからの同期ブロックハッシュを含むか否かに関する判定が行われる。そうである場合、ブロック23614において、現在のブロックチェーンは、子ブロックチェーンを探索するために子ブロックチェーンを指すように設定される。次いで、プロセスフローはブロック23610に戻り、子ブロックチェーン内の探索を再開する。
ターゲットブロックが同期ブロックハッシュを含まない場合、ブロック23616において、ターゲットブロックが取得され、探索エンティティに提供される。次いで、本方法は、例えば、通常の動作が再開されるとブロック23618において終了する。
ネットワーク参照を使用して、マークルツリーインデックスを下位レベルのブロックチェーン階層で探索すると、ネットワークのレイテンシが長くなる可能性がある。子ノードのブロックチェーンに対するマークルツリーインデックスのキャッシュは、探索をルートブロックチェーンに限定することによる、インデックス探索のオーバーヘッドを減らすための方法である。さらに、クラウドサーバは、IoTネットワーク内のすべての子ブロックチェーンに対してマークルツリーを維持するのに十分な処理リソースを持つことができる。
図237は、一部の実施形態による、クラウドサーバに格納されたキャッシュされたマークルツリーの概略図である。同様の番号が付けられた項目は、図233に関して説明したとおりである。この例では、C1マークルツリー23348は、図233の階層型マークルツリーと同じである。しかし、C1マークルツリー23348の最も低いレベル23702はネットワーク参照を含まず、代わりに下位レベルIoTネットワーク用のキャッシュされたマークルツリー23706へのキャッシュ参照23704を含む。
例えば、キャッシュされたマークルツリー23706は、図233に関して説明されたH1マークルツリー23334のH1マークルツリーコピー23708を含み得る。H1マークルツリーコピー23708において、最も低いレベル23710は、さらに下位レベルのマークルツリーのコピー23714への参照23712を含み得る。
同様に、中間ブロックチェーンは、より効率的な地域探索が実行され得るようにサブツリーキャッシュを維持することができる。例えば、図238は、図233に関して説明したように、IoTネットワークレベルH1 23318での分散型マークルツリーキャッシュ23800の概略図を示す。H1マークルツリー23334は、図233に関して説明したものと同じであり得る。しかしながら、最も低いレベル23802は、ネットワーク参照ではなく、Rnマークルツリー23806のコピーへのキャッシュ参照23804を含み得る。
図239は、一部の実施形態による、コヒーレンシを用いて分散キャッシュ23900を維持するための技法の概略図である。キャッシュは参照するブロックチェーンに直接保存されないため、子ブロックチェーンマークルツリーのキャッシュコヒーレンシを維持する方法を実装すると便利であり得る。IoTフレームワークは、パブリッシュ-サブスクライブ型シグナリングを効率的に実装するために使用され得る。子ブロックチェーンは、下位レベルのマークルツリー23904を、上位レベルのマークルツリー23906を保持する親ブロックチェーンにパブリッシュすることができる(23902)。同様に、親ブロックチェーンは、図233に関して論じられたC1マークルツリー23348などのルートブロックチェーンに、上位レベルのマークルツリー23906をパブリッシュすることができる(23908)。
図240は、一部の実施形態による、ブロックチェーンの階層のためのコヒーレントキャッシュを構築するための例示的な方法24000のプロセスフロー図である。方法24000は、例えば、階層の任意のレベルにおけるIoTまたはクラウドデバイスによって実装され得る。例えば、図240の方法24000は、図242に関して説明されるIoTデバイス24200によって実施することができる。本方法は、例えば、IoTネットワークが最初に起動されたとき、またはIoTデバイスがIoTネットワークに参加したときに、ブロック24002において開始し得る。
ブロック24004において、現在のブロックチェーンが、子ブロックチェーンのパブリッシャエージェントにサブスクライブする。ブロック24006において、子ブロックチェーンは、親ブロックチェーンのサブスクリプションエージェントの登録を受け入れる。パブリケーションおよびサブスクリプション(Pub-Sub)は、コヒーレントキャッシュを維持するためにインデックス、つまりマークルツリーのみを含み得る。一部の例では、Pub-Sub型は、子ブロックチェーンからの完全なブロックチェーンを含み得る。
ブロック24008において、現在のブロックチェーンは、その現在のポインタをその親ブロックチェーンに設定する。ブロック24010において、現在のブロックチェーンがルートブロックチェーンであるか否かに関する判定が行われる。そうである場合、ブロック24012において、コヒーレントキャッシュリンクが設定され、システムは、例えば、図241に関して説明したように、パブリケーションイベントが起こるのを待つ。現在のブロックチェーンがルートブロックチェーンではない場合、プロセスフローはブロック24004に戻り、階層内の次のレベルのPub-Sub型リンクを構築する。
図241は、一部の実施形態による、ブロックチェーンの階層のためのコヒーレントキャッシュを維持するための例示的な方法24100のプロセスフロー図である。方法24100は、例えば、階層の任意のレベルにおけるIoTまたはクラウドデバイスによって実装され得る。例えば、図241の方法24100は、図242に関して説明されるIoTデバイス24200によって実施することができる。本方法は、コヒーレントキャッシュが構築された後、例えば図240の技法に続いて、ブロック24102において開始し得る。
ブロック24104において、ブロックチェーンキャッシュエージェントはキャッシュコヒーレンシイベントを受信する。キャッシュコヒーレンシイベントは、例えば、下位レベルのブロックチェーンについてマークルツリーで行われた変更のパブリケーションであり得る。一部の例では、上位レベルのマークルツリー内の情報が正しいことを確認するために定期的なリフレッシュが使用され得る。
ブロック24106において、ソースブロックチェーンからのマークルツリーパスが、サブスクライバキャッシュエージェントにコピーされパブリッシュされる。ブロック24108において、サブスクライバブロックチェーン内のキャッシュエージェントは、子ツリーおよびブロックに対応するサブツリー内の現在キャッシュされているマークルツリーパスを置き換える。ブロック24110において、パスがマークルツリーの新しい分岐を形成するか否かに関する判定が行われる。そうでない場合、プロセスフローはブロック24104に戻り、通常の更新を続けてキャッシュコヒーレンシを維持する。
ブロック24110でパスがマークルツリーの新しい分岐を形成する場合、ブロック24112において、サブツリー内の新しいローカルルートが構築される。ブロック24114において、現在の参照はローカルルートに等しくされる。ブロック24116において、ローカルルートがグローバルルートであるか否かに関する判定が行われる。そうでなければ、プロセスフローはブロック24112に戻り、次のサブツリーに新しいローカルルートを構築する。
ブロック24116でローカルルートがグローバルルートに等しい場合、方法24100はブロック24118において終了する。この時点で、プロセスはブロック24102において再開し得る。
図242は、一部の実施形態による、関連するインデックスを用いて階層型ブロックチェーンを実装するためのIoTデバイス24200に存在し得るコンポーネントの一例のブロック図である。同様の番号が付けられた項目は、図3および図8に関して説明したとおりである。図8に関して説明したIoTデバイス800、および本明細書で説明される他のIoTデバイスに対して選択されたものとは異なるコンポーネントが、IoTデバイス24200に対して選択され使用されてもよいことに留意されたい。
IoTデバイス24200は、例えば、2009年にISO/IEC 11889としてTrusted Computing Groupによって公表された仕様に準拠する、トラステッドプラットフォームモジュール(TPM)を含むことができる。TPMは、暗号化プロセッサ(CP)、不揮発性メモリ(NVM)、およびセキュアメモリ(SM)を含み得る。CPは、とりわけ、乱数発生器、RSAハッシュ発生器、SHA-1ハッシュ発生器、および暗号化-復号エンジンを提供することができる。NVMは、例えばとりわけRSA鍵を含む、製造時にプログラムされた鍵を含み得る。SMは、ソフトウェアで得られた測定値をプラットフォーム構成レジスタに保持することができる。測定値は、ストレージ808またはメモリ804に格納されたコードまたはデータセグメント上で計算されたハッシュコードと呼ばれ得る。ブートコードセグメントの測定から開始して、初期ブートから信頼チェーンを作成することによって、測定を使用してトラステッド実行環境(TEE)を確立することができる。SMはセキュアなストレージを提供することができる。
TPMを使用して、プログラムを実行するためのTEEまたはセキュアエンクレーブを確立することができる。TPMはまた、セキュアな通信のための暗号化サポートおよび識別のための鍵を提供することを含む、任意の数の他の機能のためにも使用され得る。TPMは、IoTネットワークの一番エッジにあるセンサなど、より制約の厳しいデバイスには存在しない可能性がある。これらのデバイスでは、セキュリティは、ブロックチェーン自体によって、上流のデバイスによって、仮想TPMなどによって提供され得る。
大容量ストレージ808は、本明細書で説明される鍵管理機能を実施するための複数のモジュールを含むことができる。大容量ストレージ808においてコードブロックとして示されているが、モジュールのうちのいずれも、例えば特定用途向け集積回路(ASIC)に組み込まれるなど、ハードワイヤード回路で完全にまたは部分的に置き換えられ得ることが理解されよう。
大容量ストレージ808は、サービス、属性、デバイスのアイデンティティ、コントラクト、コイン残高などを保持するブロックチェーン24204を維持するために含まれ得るブロックチェーンロジック24202を含み得る。ブロックチェーンロジック24202は、ブロックチェーントランザクションを他のIoTデバイスに伝播させるために使用され得る。さらに、ブロックチェーンロジック24202を使用して、ネットワーク階層の下位レベルまたは上位レベルでブロックチェーンへのネットワーク参照を確立することができる。例えば、ネットワーク参照は、ゲートウェイまたはルータを介した下位レベルのIoTネットワークへのリンクを含み得る。
インデクサ24206は、ブロックチェーン2422内のブロックのハッシュコードを含むマークルツリー24208を生成するために使用され得る。マークルツリー24208の最も低いレベルは、ブロックチェーンロジック24202によって生成された、下位レベルのIoTネットワーク内のIoTデバイス内のマークルツリーへのネットワーク参照を含み得る。
ロケータ24210は、ブロックチェーン階層を探索するために含まれ得る。ロケータ24210は、図236に関して説明したようにこの機能を実行することができ、ロケータ24210は、ブロックチェーン内のブロックを見つけるために使用され得るターゲットデータのハッシュコードについて関連するマークルツリーを探索する。
キャッシュ作成部24212は、階層内の下位レベルにあるIoTネットワーク内のマークルツリーのキャッシュ24214を構築するために使用され得る。例えば、キャッシュ作成部24212は、図240に関して説明した方法24000を実行することができる。次いで、ロケータ24210は、キャッシュ24214内のブロックチェーン階層の探索を実行し、IoTネットワークへの負荷を減らすことができる。
キャッシュ24214のコヒーレンシは、キャッシュエージェント24216によって維持され得る。キャッシュエージェント24216は、図241に関して説明した方法24100を実行することができる。さらに、キャッシュエージェント24216は、それらのキャッシュエージェントからキャッシュコヒーレンシイベントの通知を受信するために、下位レベルのIoTデバイス内のキャッシュエージェントにサブスクライブすることができる。キャッシュエージェント24216はまた、変更通知を受信するためにキャッシュエージェント24216にサブスクライブしている上位レベルのIoTデバイスに現在のIoTデバイス24200に関するキャッシュコヒーレンシイベントをパブリッシュすることができる。
図243は、一部の実施形態による、セキュアな通信のために鍵を管理するようにプロセッサ902に指示するためのコードを含む、非一時的機械可読媒体24300のブロック図である。プロセッサ902は、バス904を介して非一時的機械可読媒体24300にアクセスすることができる。プロセッサ902およびバス904は、図9に関して説明したプロセッサ902およびバス904と同様の方法で実施することができる。非一時的機械可読媒体24300は、図8の大容量ストレージ808について説明したデバイスを含むこともできるし、光ディスク、USBメモリ(thumb drive)、または任意の数の他のハードウェアデバイスを含むこともできる。
非一時的機械可読媒体24300は、例えば、ある部屋の中にあるセンサなどの最下位レベルのデバイスから、家や工場のネットワークなどのより広いIoTネットワークまで延在し、さらにはクラウドなどのより広範なIoTネットワークにも至る、階層IoTネットワークにわたってブロックチェーン階層を構築するようにプロセッサ902に指示するためのコード24302を含み得る。コード24302は、図243に関して説明した方法に従ってこの機能を実行することができる。
コード24304は、ブロックチェーンの階層インデックスを構築するようにプロセッサ902に指示するために含まれ得る。階層型インデックスは、ブロックチェーン内のブロックの内容のハッシュコード値に基づいて、マークルツリーとすることができる。
コード24306は、現在のIoTネットワークレベルでマークルツリーのコヒーレントキャッシュを構築するようにプロセッサ902に指示するために含まれ、コヒーレントキャッシュは、IoTネットワーク内の下位レベルのマークルツリーを含み得る。コード24306は、図240に関して説明した方法を使用してコヒーレントキャッシュの構築を実行することができる。
コード24308は、キャッシュのコヒーレンシを維持するようにプロセッサ902に指示するために含まれ得る。コード24308は、図241に関して説明した方法を使用してこの機能を実行することができる。
IoTデバイスの機能を実施するために、任意の数の他のコードブロックを機械可読媒体24300に含めることができる。これらのコードブロックは、IoTデバイス間でパケットを構築し送信するための通信部、セキュアに実行されるコードのための測定を実行するためのセキュアブータ/測定部、鍵生成部、または本明細書で説明される任意の数の他のコードブロックを含み得る。
パブリッシュ-サブスクライブ(Pub-Sub)型は、特定のネットワークアドレスにパケットまたはフレームを送信することによる経路指定と比較して、ネットワーク経路指定機能がコンテンツの効率的な経路指定に適用される、コンテンツ中心ネットワーク(CCN)のサブセットである。Pub-Sub型の焦点は、単一のパブリッシュ済みコンテンツを複数のサブスクライバに、複数のパブリケーションを単一のサブスクライバに、またはその両方に効率的に経路指定することにある。特定のコンテンツ項目に使用されることに加えて、Pub-Sub型はトピックに関連していてもよく、トピックは、複数のコンテンツ項目が交換され得る論理的なタイトルまたは件名(subject line)であり得る。
Pub-Sub型モデルにより、どのネットワークデバイスがサブスクライブ、パブリッシュ、またはその両方を行うことができるかについてトピックを定義できる。パブリッシャは複数のトピックにパブリッシュでき、サブスクライバは複数のトピックにサブスクライブできる。従って、トピックトラフィックを経路指定するときにスケーラビリティの問題が発生する可能性がある。トピックは、文字列、数字、ネットワーク(マルチキャスト)アドレス、UUID、およびオブジェクトID階層を含む、様々なデータ形式で表現できる。しかしながら、経路指定効率は、トピックの表現方法および形式によって影響を受け得る。
本明細書で説明されるように、ブルームフィルタは、経路指定のためにPub-Sub型トピックを表すための効率的な方法を提供することができる。ブルームフィルタは、ターゲット値の設定ビットのすべて、例えば、値が1のビットがブルームフィルタの設定ビットと一致する場合に一致を示す。例えば、設定されていないビットはゼロの値を持ち、無視される。従って、ブルームフィルタにビットが設定され、ターゲット値にゼロの値がある場合、ターゲット値の設定ビットがすべてブルームフィルタに設定されている限り、一致する可能性がある。とりわけ、トピックのビットパターンを分散ハッシュタグ(DHT)に格納すること、またはトピックおよび関連ステータスをブロックチェーンに格納することなど、他の技法をPub-Sub型配信のトピックを追跡するために使用することができる。
図244は、一部の実施形態による、ブルームフィルタに基づくPub-Sub型経路指定の使用の概略図である。本装置は、ブルームフィルタを構築し、トピックがハッシュされ、次いで、XOR関数などによって、ブルームフィルタのためのビット空間に上書きされる。それぞれが異なってハッシュするので、複数のトピックフォーマットが同じブルームフィルタを使用し得る。ブルームフィルタに使用されるビット空間の長さは、情報理論に基づいて判定され得る。例えば、より多くのビット値を含むより長いブルームフィルタは、より多くのトピックが含まれることを可能にする一方で、ビットが重複する可能性を減少させ、トピックの誤った取得の可能性につながる。
図244に示されるように、コンテンツパブリッシャ24402はトピックのハッシュコードを生成することができる。次いで、パブリッシャは、コンテンツのハッシュコードの設定ビットのすべてを含むルータ24404(U2)を介してコンテンツを送信することができる。次いで、ルータ24404は、ブルームフィルタをローカルパブリッシャ24406にパブリッシュすることができる(P4)。U2およびU3などの他のルータ24404は、例えば第1のルータU2にサブスクライブして、ターゲットトピックのハッシュコードを含むビットマップを提示することができる。
U3などのルータ24404がブルームフィルタ内の設定ビットのすべてを含まない場合、そのトピックに対するハッシュコードはそのツリーを通して送信されない。これは、24404 U3までのルータによって維持されているツリー内のどのサブスクライバ24408もそのトピックをサブスクライブしていないことを示し得る。ルータ24404 U2から、ハッシュコードは、P2などの他のパブリッシャ24406に提供され得る。さらに、トピックのハッシュコードは、U1内のブルームフィルタ内の設定ビットのすべてが一致する限り、U1などの他のルータ24404を通って移動することができる。S1、S2、およびS5などのサブスクライバ24408は、P1などのパブリッシャ24406から、またはU1などのルータ24404からコンテンツを受信することができる。この例では、サブスクライバ24408、S2は、コンテンツパブリッシャ24402からのハッシュコードと一致するターゲットトピックのハッシュコードを有する。
この手法では、サブスクライバ24408は、サブスクライブしたいトピックのすべてについて上書きされたハッシュコードを含むブルームフィルタを構築することができる。次いで、サブスクライバ24408は、ブルームフィルタをルータファブリックに登録することができる。パブリッシャ24406はまた、それがコンテンツを提供することができるすべてのトピックについて重複するハッシュコードを含むブルームフィルタを供給することもできる。一例として、同じセマンティックトピックに対応する複数のフォーマット方法がある場合、ブルームフィルタは、経路指定要件を満たす1つまたは複数のものと一致し得る。
パブリッシュ-サブスクライブ型モデルを使用する経路指定方式を考えると、セキュリティポリシーが、サブネットワーク、デバイス、または外部ネットワークへのゲートウェイにパブリッシュされ得るトピックのセットに対して制限を課したい場合がある。ブルームフィルタマスクは、経路指定ノードに追加され得、マスクは、経路指定され得るトピックのホワイトリスト表現を表す。マスクはまた、フィルタリングされたトピックのブラックリストを表すために使用され得る。
図245は、一部の実施形態による、コンテンツの配信を可能にするためのホワイトリストブルームフィルタの使用の概略図である。図245では、トピックブルームフィルタ24502とホワイトリストブルームフィルタ24504との共通部分が、例えば、AND機能を実行することによって計算される。終了ブルームフィルタ24506がゼロの場合、トピックブルームフィルタ24502はホワイトリストブルームフィルタ24504内にあり、コンテンツはコンシューマに進むことが許可される。
図246は、一部の実施形態による、コンテンツの配信を防止するためのブラックリストブルームフィルタの使用の概略図である。図246では、トピックブルームフィルタ24602とブラックリストブルームフィルタ24604との共通部分が、例えば、中間ブルームフィルタ24608を生成するためにNAND関数を実行することによって計算される。次いで、中間ブルームフィルタ24608は、例えばAND機能24610を使用して、トピックブルームフィルタ24602と交差され得る。終了ブルームフィルタ24612がゼロではない場合、トピックブルームフィルタ24602はブラックリストブルームフィルタ24604内にあり、コンテンツはコンシューマに進むことを妨げられる。
図247は、一部の実施形態による、コンテンツ制御のためにブラックリストまたはホワイトリストブルームフィルタを用いてPub-Subを実装するための例示的な方法24700のプロセスフロー図である。図247の方法24700は、図248に関して説明されるIoTデバイス24800によって実施することができる。方法24700は、例えば、サブスクライバが複数のトピックについてのハッシュコードを含むブルームフィルタを計算するときに、ブロック24702において開始し得る。
ブロック24706において、管理者は、ブラックリストブルームフィルタ、ホワイトリストブルームフィルタ、またはその両方をシステム内のルータに登録する。ブロック24708において、パブリッシャは、パブリケーションブルームフィルタを使用してコンテンツをパブリッシュする。パブリケーションブルームフィルタは、配信に使用されるブルームフィルタの長さと一致するビット長を持つ、トピックまたはパブリケーションの直接ハッシュコードであり得る。
ブロック24710において、コンテンツがルータに配信される。次いで、ルータは、パブリッシャおよびサブスクライバのブルームフィルタのPub-Sub型共通部分を計算する。ブロック24712において、Pub-Sub型共通部分がゼロに等しいか否かに関する判定が行われる。Pub-Sub型共通部分がゼロに等しく、パブリッシャおよびサブスクライバのブルームフィルタが重複していないことを示す場合、方法24700はブロック24714で終了する。
ブロック24712で、Pub-Sub型共通部分がゼロに等しくないと判定された場合、ブロック24716において、Pub-Sub型共通部分とホワイトリストトピックのブルームフィルタとのホワイトリスト共通部分が計算される。ブロック24718において、ブラックリストトピックのPub-Sub型共通部分とブルームフィルタのブラックリスト共通部分が計算される。
ブロック24720において、ホワイトリスト共通部分がゼロに等しく、ブラックリスト共通部分がゼロに等しくないか否かに関する判定が行われる。両方の条件が真である場合、ブロック24722において、コンテンツはサブスクライバに経路指定されない。いずれかの条件が真ではない場合、ブロック24724において、コンテンツはサブスクライバに経路指定される。次いで、方法24700は、次にブロック24714で終了する。
図248は、一部の実施形態による、ブルームフィルタを使用してPub-Sub型コンテンツ配信システムを実装するためにIoTデバイス24800に存在し得るコンポーネントの一例のブロック図である。同様の番号が付けられた項目は、図3および図8に関して説明したとおりである。図8に関して説明したIoTデバイス800、および本明細書で説明される他のIoTデバイスに対して選択されたものとは異なるコンポーネントが、IoTデバイス24800に対して選択され使用されてもよいことに留意されたい。
IoTデバイス24800は、例えば、2009年にISO/IEC 11889としてTrusted Computing Groupによって公表された仕様に準拠する、トラステッドプラットフォームモジュール(TPM)を含むことができる。TPMは、暗号化プロセッサ(CP)、不揮発性メモリ(NVM)、およびセキュアメモリ(SM)を含み得る。CPは、とりわけ、乱数発生器、RSAハッシュ発生器、SHA-1ハッシュ発生器、および暗号化-復号エンジンを提供することができる。NVMは、例えばとりわけRSA鍵を含む、製造時にプログラムされた鍵を含み得る。SMは、ソフトウェアで得られた測定値をプラットフォーム構成レジスタに保持することができる。本明細書で使用される場合、測定値は、ストレージ808またはメモリ804に格納されたコードまたはデータセグメント上で計算されたハッシュコードである。ブートコードセグメントの測定から開始して、初期ブートから信頼チェーンを作成することによって、測定を使用してトラステッド実行環境(TEE)を確立することができる。SMはセキュアなストレージを提供することができる。
TPMを使用して、プログラムを実行するためのTEEまたはセキュアエンクレーブを確立することができる。TPMはまた、セキュアな通信のための暗号化サポートおよび識別のための鍵を提供することを含む、任意の数の他の機能のためにも使用され得る。TPMは、IoTネットワークの一番エッジにあるセンサなど、より制約の厳しいデバイスには存在しない可能性がある。これらのデバイスでは、セキュリティは、ブロックチェーン自体によって、上流のデバイスによって、仮想TPMなどによって提供され得る。
大容量ストレージ808は、本明細書で説明されるPub-Sub型機能を実施するための複数のモジュールを含むことができる。大容量ストレージ808においてコードブロックとして示されているが、モジュールのうちのいずれも、例えば特定用途向け集積回路(ASIC)に組み込まれるなど、ハードワイヤード回路で完全にまたは部分的に置き換えられ得ることが理解されよう。
大容量ストレージ808は、トピックのためのハッシュコードを生成することができるハッシュコード計算部24802を含むことができる。ハッシュコード計算部24802は、例えばXOR関数を使用して、ハッシュコードをブルームフィルタに書き込むことができる。これにより、ブルームフィルタトピックリスト24804を作成することができる。一部の例では、IoTデバイス24800は、パブリッシャまたはルータとして機能することができる。これらの例では、ブルームフィルタトピックリスト24804は、例えばフォグ812内またはクラウド302内の他のパブリッシャまたはルータから取得され得る。
ホワイトリストマスク24806は、管理者による再配信のために許容可能であると識別されたトピックを格納するために含まれ得る。ブラックリストマスク24808は、再配信を許容可能ではないと識別されたトピックを格納するために含まれ得る。
サブスクリプションマネージャ24810は、ブルームフィルタトピックリスト24804は、フォグ812またはクラウド302内のルータおよび他のデバイスに登録するために含まれ得る。IoTデバイス24800がルータまたはパブリッシャとして機能している場合、サブスクリプションマネージャ24810は、図247に関して説明したように、ブルームフィルタトピックリスト24804内のトピックがホワイトリストマスク24806またはブラックリストマスク24808のどちらにあるかを判定して、コンテンツを渡すべきか否かを判定し得る。
コンテンツロケータ24812は、トピックに関連するコンテンツを見つけて提供するために含まれ得る。例えば、コンテンツが他のパブリッシャまたはルータによって提供され、コンテンツロケータ24812によって保存されて、コンテンツがフォグ812またはクラウド302内の他のデバイスに提供される前に、そのコンテンツがホワイトリスト24806またはブラックリスト24808にあるか否かに関する判定を可能にし得る。
図249は、一部の実施形態による、コンテンツ配信のためにブルームフィルタを使用してPub-Sub型システムを管理するようにプロセッサ902に指示するためのコードを含む、非一時的機械可読媒体24900のブロック図である。プロセッサ902は、バス904を介して非一時的機械可読媒体24900にアクセスすることができる。プロセッサ902およびバス904は、図9に関して説明したプロセッサ902およびバス904と同様の方法で実施することができる。非一時的機械可読媒体24900は、図8の大容量ストレージ808について説明したデバイスを含むこともできるし、光ディスク、USBメモリ(thumb drive)、または任意の数の他のハードウェアデバイスを含むこともできる。
非一時的機械可読媒体24900は、例えば、複数のトピックのそれぞれのハッシュコードを計算し、次いでハッシュコードをブルームフィルタに上書きすることによって、ブルームフィルタトピックリストを生成するようにプロセッサ902に指示するためのコード24902を含み得る。
コード24904は、IoTネットワーク内のルータにホワイトリストマスク、ブラックリストマスク、またはその両方を登録するようにプロセッサ902に指示するために含まれ得る。一部の例では、コード24904は、コンテンツを転送するか否かを判定する際にプロセッサによって使用されるホワイトリストマスク、ブラックリストマスク、またはその両方を別のデバイスから受け入れることができる。
コード24906は、サブスクリプションブルームフィルタをルータに登録するようにプロセッサ902に指示するために含まれ得る。例えば機械可読媒体24900がルータの一部である場合、コード24906は、別のデバイスからのサブスクリプションブルームフィルタを受け入れるようにプロセッサ902に指示することができる。
コード24908は、コンテンツがネットワーク上でアクセス可能か否かを判定するために、コンテンツフィルタとサブスクリプションブルームフィルタとのコンテンツの共通部分を計算するようにプロセッサ902に指示するために含まれ得る。コード24910は、コンテンツが許可されているか否かを判定するために、コンテンツ共通部分とホワイトリストマスクとの共通部分を計算するようにプロセッサ902に指示するために含まれ得る。コード24912は、コンテンツが禁止されているか否かを判定するために、コンテンツ共通部分とブラックリストマスクとの共通部分を計算するようにプロセッサ902に指示するために含まれ得る。
コード24914は、例えば、コンテンツがホワイトリストマスクによって認可され、ブラックリストマスクによって禁止されていない場合、コンテンツをサブスクライバに経路指定するようにプロセッサ902に指示するために含まれ得る。これらの条件のいずれかが真である場合、コード24914はコンテンツを削除し得る。
IoTデバイスの機能を実施するために、任意の数の他のコードブロックを機械可読媒体24900に含めることができる。これらのコードブロックは、IoTデバイス間でパケットを構築し送信するための通信部、セキュアに実行されるコードのための測定を実行するためのセキュアブータ/測定部、鍵生成部、または本明細書で説明される任意の数の他のコードブロックを含み得る。
パブリッシャ、サブスクライバ、および経路指定ノードのセットから成るPub-Sub型ネットワークを考えると、パブリッシャは、機密コンテンツをトピック通知メッセージに含めることを希望する場合がある。コンテンツは、グループまたは共有鍵とすることができるトピック暗号化鍵で暗号化することができる。このユースケースの課題は、トピック通知を受け取った後にコンテンツを消費する前に、サブスクライバがコンテンツ暗号化鍵を取得する必要があることである。
経路指定ノードは鍵管理ノードとして機能することができるので、Pub-Sub型ネットワークを使用して、ネットワークのダイナミクスに合わせて拡張された鍵管理通知メッセージを配信することができる。例えば、鍵の必要性を知らせる暗号化されたコンテンツが元のトピックに含まれている場合など、鍵管理トピックが自動的に作成されて配信されることがある。暗号化されたコンテンツを受信すると、サブスクライバは暗号化鍵を取得するために鍵管理のGET要求を発行する。経路指定ノードはこれを予想し、暗号化鍵をプリフェッチする鍵管理トピックをサブスクライブする。
図250は、一部の実施形態による、暗号化されたコンテンツを用いたトピック通知の概略図である。図250では、経路指定ノード25002は、KT1などのトピック鍵をキャッシュすることができ、その結果、それらが経路指定ノード25002によってサービスされるサブスクライバ25004のコミュニティにとってローカルに利用可能になり得る。鍵管理トピックは、鍵管理トピックへのサブスクライバとして動作する経路指定ノード25002に通知する。
図251の(A)は、一部の実施形態による、暗号化されたコンテンツを含むトピックの通知を受信するルータのグループの概略図である。そのキャッシュに含まれている鍵KT1を有する経路指定ノード25102は、トピックT1 25108に対する鍵管理トピックT[KT1] 25106をパブリッシュすることによってサブスクリプション25104に応答することができる。トピック通知T1 25108は、暗号化コンテンツCを含むことができ、コンテンツ暗号化鍵はKT1である。トピック通知T1 25108を受信すると、ルータ25102、25110、25112、または25114に、トピックT[KT1] 25106を定義させることができる。
トピックT[T1]にサブスクライブしている(25104)ルータ25110は、そのトピックについての鍵管理イベントの受信を待つことができる。トピックT1 25108のパブリッシャP 25116は、鍵KT1をルータ25102に供給することができ、これはシステム内の他のルータに対する鍵キャッシュマネージャとして機能することができる。鍵を受信すると、経路指定ノード25102は、そのサブスクライバに鍵KT1の利用可能性を通知する。
図251の(B)は、一部の実施形態による、サブスクライバが暗号化されたトピックを要求することを見越してそれらのキャッシュをウォーミングするルータのグループの概略図である。経路指定ノード25110などの経路指定ノード25102へのサブスクライバは、例えば、鍵GET要求25122を使用して鍵KT1をプリエンプティブに取得することによって、自分のキャッシュ25120をウォームアップすることができる。これは、経路指定ノード25112などの下流のルータ、およびサブスクライビングノード25118などのサブスクライバノードが鍵GET要求25124を発行することによってT1通知25108に応答することを見越して実行され得る。コンテンツ暗号化鍵は、サイト固有の鍵によって、または経路指定ノードとサブスクライバノードとの間のホップにわたってトピック鍵を保護するVPNセッションによってさらに暗号化され得ることに留意されたい。
図252は、一部の実施形態による、鍵管理通知およびウォームキーキャッシングを使用するための例示的な方法25200のプロセスフロー図である。図252の方法25200は、図253に関して説明されるIoTデバイス25300によって実施することができる。本方法は、例えば、IoTデバイスが、コンテンツ配信のためにブルームフィルタを使用することができるコンテンツ配信のために経路指定ネットワークに参加するときに、ブロック25202において開始し得る。ブロック25204において、パブリッシャは、コンテンツ(C)およびコンテンツ暗号化鍵(KT1)を生成する。次いで、暗号化されたコンテンツE={C}KT1は、パブリックリポジトリからダウンロードするために利用可能であり得る。
ブロック25206において、パブリッシャは、Pub-Sub型サブスクライバを有するトピックT1の下でコンテンツを利用可能にすることができる。ブロック25208において、パブリッシャは、第1の経路指定ノード(R1)にT1を通知することができる。経路指定ノード(R1)は、利用可能なパブリッシュされたトピックを含むブルームフィルタを構築することができる。経路指定ノード(R1)は、暗号化コンテンツ(E)が利用可能であることを示すタグを含む。
ブロック25210において、T1のサブスクリプションを有する第2の経路指定ノード(R2)は、Eタグを含む、第1の経路指定ノード(R1)からのトピック通知を受信する。ブロック25212において、第1の経路指定ノード(R1)は、鍵管理トピックT[KT1]を構築して、第2の経路指定ノード(R2)に鍵KT1の利用可能性を通知する。
ブロック25214において、Eタグを有するT1通知を受信すると、第2の経路指定ノード(R2)は、鍵管理トピックT[KT1]にサブスクライブする。さらに、T1通知および鍵管理トピックは、チェーン内の連続するルータを介して伝播され得る。
ブロック25216において、パブリッシャは、トピック暗号化鍵KT1を第1の経路指定ノードに供給する。トピック暗号化鍵を受信すると、T1のすべてのサブスクライバに通知される。
ブロック25218において、トピックT1へのサブスクライバ(S)がトピック暗号化鍵KT1を使用してEを復号したいとき、サブスクライバは、鍵キャッシュマネージャとして機能するルータからKT1を要求する。サブスクライバのための鍵キャッシュマネージャは、サブスクライバと通信している最寄りのルータでもよいし、ルータのグループ全体に鍵キャッシュ管理サービスを提供する最初のルータでもよい。
ブロック25220において、トピック暗号化鍵がキャッシュ内にあるか否かに関する判定が行われる。ない場合、ブロック25222において、鍵キャッシュマネージャとして機能するルータは、ピアノードからトピック暗号化鍵を要求する。次いで、プロセスフローはブロック25220に戻り、トピック暗号化鍵が現在キャッシュ内にあるか否かを判定する。ブロック25220でトピック暗号化鍵がキャッシュ内にあると判定された場合、プロセスフローはブロック25224に進み、トピック暗号化鍵がこの例ではサブスクライバなどの要求者に送信される。
ブロック25226において、トピック暗号化鍵KT1を使用して、暗号化されたコンテンツEが復号される。次いで、方法25200は、ブロック25228で終了する。
図253は、一部の実施形態による、暗号化されたコンテンツを用いてトピック通知を管理するためのIoTデバイス25300に存在し得るコンポーネントの一例のブロック図である。同様の番号が付けられた項目は、図3および図8に関して説明したとおりである。図8に関して説明したIoTデバイス800、および本明細書で説明される他のIoTデバイスに対して選択されたものとは異なるコンポーネントが、IoTデバイス25300に対して選択され使用されてもよいことに留意されたい。
IoTデバイス25300は、例えば、2009年にISO/IEC 11889としてTrusted Computing Groupによって公表された仕様に準拠する、トラステッドプラットフォームモジュール(TPM)を含むことができる。TPMは、暗号化プロセッサ(CP)、不揮発性メモリ(NVM)、およびセキュアメモリ(SM)を含み得る。CPは、とりわけ、乱数発生器、RSAハッシュ発生器、SHA-1ハッシュ発生器、および暗号化-復号エンジンを提供することができる。NVMは、例えばとりわけRSA鍵を含む、製造時にプログラムされた鍵を含み得る。SMは、ソフトウェアで得られた測定値をプラットフォーム構成レジスタに保持することができる。本明細書で使用される場合、測定値は、ストレージ808またはメモリ804に格納されたコードまたはデータセグメント上で計算されたハッシュコードである。ブートコードセグメントの測定から開始して、初期ブートから信頼チェーンを作成することによって、測定を使用してトラステッド実行環境(TEE)を確立することができる。SMはセキュアなストレージを提供することができる。
TPMを使用して、プログラムを実行するためのTEEまたはセキュアエンクレーブを確立することができる。TPMはまた、セキュアな通信のための暗号化サポートおよび識別のための鍵を提供することを含む、任意の数の他の機能のためにも使用され得る。TPMは、IoTネットワークの一番エッジにあるセンサなど、より制約の厳しいデバイスには存在しない可能性がある。これらのデバイスでは、セキュリティは、ブロックチェーン自体によって、上流のデバイスによって、仮想TPMなどによって提供され得る。
大容量ストレージ808は、本明細書で説明される暗号化コンテンツ配信機能を実施するための複数のモジュールを含むことができる。大容量ストレージ808においてコードブロックとして示されているが、モジュールのうちのいずれも、例えば特定用途向け集積回路(ASIC)に組み込まれるなど、ハードワイヤード回路で完全にまたは部分的に置き換えられ得ることが理解されよう。
大容量ストレージ808は、暗号化されたコンテンツを含むトピックを識別することができるトピック分類部25302を含むことができる。トピック分類部25302は、暗号化されたコンテンツおよび暗号化されていないコンテンツを含むトピックを含む、利用可能なトピックについてブルームフィルタトピックリストを作成することができる。
通知部25304は、暗号化されたコンテンツを含むトピックを、フォグ812内の他のデバイスに通知することができる。鍵サブスクライバ25306は、暗号化コンテンツ25310のトピック鍵25308を含むトピックをサブスクライブするために含まれ得る。鍵サブスクライバ25306は、パブリッシャまたはルータなどのフォグ812内のデバイスから暗号化コンテンツ25310をプルまたは受信し、ルータまたはサブスクライバなど、フォグ812内の他のデバイスに暗号化コンテンツ25310を提供することができる。復号部25312は、例えば、トピック鍵25308を使用して、暗号化されたコンテンツを復号化するために含まれ得る。
図254は、一部の実施形態による、暗号化されたコンテンツを用いてトピック通知を管理するようにプロセッサ902に指示するためのコードを含む、非一時的機械可読媒体25400のブロック図である。プロセッサ902は、バス904を介して非一時的機械可読媒体25400にアクセスすることができる。プロセッサ902およびバス904は、図9に関して説明したプロセッサ902およびバス904と同様の方法で実施することができる。非一時的機械可読媒体25400は、図8の大容量ストレージ808について説明したデバイスを含むこともできるし、光ディスク、USBメモリ(thumb drive)、または任意の数の他のハードウェアデバイスを含むこともできる。
非一時的機械可読媒体25400は、暗号化されたコンテンツの通知を受信するようにプロセッサ902に指示するためのコード25402を含み得る。通知は、パブリッシャ、パブリッシャと接触しているプライムルータ、またはプライムルータと接触している他のルータによって送信され得る。
コード25404は、利用可能なコンテンツのブルームフィルタを構築するようにプロセッサ902に指示するために含まれ得る。ブルームフィルタは、暗号化されたコンテンツを含むトピックに関するハッシュコードと、暗号化されたコンテンツを含まないトピックに関するハッシュコードとを含み得る。
コード25406は、トピック通知をルータに送信するようにプロセッサ902に指示するために含まれ得る。トピック通知は、トピックがコンテンツを暗号化したという情報を含み得る。
コード25408は、例えば鍵管理トピックを含むトピック通知を受信したときに、トピックにサブスクライブするようにプロセッサ902に指示するために含まれ得る。コード25410は、暗号化されたコンテンツのための鍵の利用可能性をサブスクライバに通知するようにプロセッサ902に指示するために含まれ得る。
コード25412は、例えば、サブスクライバがルータの場合、ピアノードから鍵を取得するようにプロセッサ902に指示するために含まれ得る。コード25412は、サブスクライバと通信しているルータから鍵を取得するようにプロセッサ902に指示することができる。
コード25414は、鍵をサブスクライバに送信するようにプロセッサ902に指示するために含まれ得、サブスクライバは、ルータまたはコンテンツのエンドコンシューマを含み得る。コード25414は、例えば、サブスクライバがコンテンツのコンシューマである場合、コンテンツを復号するようにプロセッサに指示することができる。
IoTデバイスの機能を実施するために、任意の数の他のコードブロックを機械可読媒体25400に含めることができる。これらのコードブロックは、IoTデバイス間でパケットを構築し送信するための通信部、セキュアに実行されるコードのための測定を実行するためのセキュアブータ/測定部、鍵生成部、または本明細書で説明される任意の数の他のコードブロックを含み得る。
交信を保護するためのトピックレベルの暗号化に加えて、トピックはパブリッシャおよびサブスクライバのグループ内でプライバシーセンシティブであり得る。追加の保護レベルを達成するために、グループ鍵を使用してトピックを暗号化することができる。グループ鍵は、コンテンツ暗号化鍵を兼ねてもよいし、第2のグループ鍵であってもよい。グループ鍵の配布は、他の技法の中でも、図252に関して説明した方法25200に従うことができる。
図255は、一部の実施形態による、トピックグループ鍵25504を取得するサブスクライバ25502の概略図である。トピックグループ鍵25504は、最初にトピックネーミングサーバ25506によって管理されるトピックグループにサブスクライバ25502を登録することによって、例えば、トピックネーミングサーバ25506に対してトピックへ参加またはトピックを作成するための参加要求25508をサブスクライバ25502に送信させることによって、取得され得る。次いで、トピックネーミングサーバ25506は、グループメンバシップクレデンシャルを含むメッセージ25510を発行し得る。同様に、パブリッシャ25512は、参加要求25514を送信し、トピックグループ鍵25504などのグループメンバシップクレデンシャルを含むメッセージ25516をトピックネーミングサーバ25516から受信することによってグループに参加することができる。
次いで、パブリッシャ25512およびサブスクライバ25502は、グループメンバとして認証することができる。認証が成功すると、トピックネーミングサーバ25506はセキュアなセッションを開始してトピックグループ鍵25504をメンバに配布することができる。
図256は、一部の実施形態による、利用可能なトピックをサブスクライバに通知するためのサブスクリプションブルームフィルタ25602を生成するパブリッシャの概略図である。ブルームフィルタ通知システムは、図244に関して説明したように機能することができる。パブリッシャおよびサブスクライバがトピック25606を暗号化するためのトピックグループ鍵25604を所有すると、トピック25606は暗号化されてパブリッシャによる暗号化トピック25608を形成することができる。非プライベートトピック25610は、ハッシュ関数25612で暗号化トピック25608と組み合わされて通知ブルームフィルタ25602を形成することができる。同様に、サブスクライバは、関心のあるトピックを暗号化し、次いで暗号化された値をブルームフィルタへの入力として使用することによって、サブスクリプションブルームフィルタを計算することができる。
図257は、一部の実施形態による、トピック暗号化のための例示的な方法25700のラダー図である。図257の方法25700は、図260に関して説明されるIoTデバイス26000によって実施することができる。トピック暗号化鍵は、例えば、図255に関して説明したように、トピックネーミングサービス(TNS)から既知のトピックのリストを受信する鍵配布センター(KDC)25702によって管理され得る。KDC 25702は、TNSによって発行された証明書またはアテステーション鍵25704を使用して、トピックグループ鍵25710を提供する前に、サブスクライバ25706などのサブスクライバと、パブリッシャ25708などのパブリッシャがトピックグループのメンバであることを検証することができる。
TNSは、トピックグループ鍵25710としてエンハンストプライバシID(EPID)鍵およびメンバを登録するためのEPID参加プロトコルを使用することができる。KDC 25702は、トピックグループ鍵25704を配布するときに、署名されたDiffie-Hellmanプロトコルを使用してサブスクライバ25704またはパブリッシャ25706へのセキュアなチャネルを確立することができる。トピックグループ鍵25704は対称鍵であり得る。
方法25700は、パブリッシャ25708がトピック暗号化鍵25710を生成した(25712)ときに開始し得る。次いで、パブリッシャ25708は、トピック暗号化鍵25710をKDC 25702から提供された鍵で暗号化し、アテステーションメッセージ25714でトピック暗号化鍵25710をKDC 25702にプッシュする。
次いで、パブリッシャ25708は、トピック暗号化鍵25710を使用して暗号化されたコンテンツと共に、トピックをルータ25718にパブリッシュする(25716)ことができる。サブスクライバ25706は、例えばサブスクライバ25706が受信したいトピックのハッシュコードを含むブルームフィルタを含む、サブスクリプションメッセージ25720をルータ25718に送信することができる。
パブリッシュされたトピックメッセージ25716を受信すると、ルータ25718は、コンテンツがサブスクライバ25706によって要求されていると判定することができる。次いで、ルータ25718は、暗号化されたコンテンツを含む通知メッセージ25722をサブスクライバ25706に送信することができる。次いで、サブスクライバ25706は、トピック暗号化鍵25710を取得するための要求と共にアテステーションメッセージ25724をKDC 25702に送信することができる。
次いで、KDC 25702は、例えば通信鍵で暗号化されたトピック暗号化鍵25710を含むメッセージ25726を送信することができる。次いで、サブスクライバ25706は、使用のためにコンテンツを復号する(25728)ことができる。
同じトピック暗号化鍵25710を使用して、トピックに追加のコンテンツを提供することができる。例えば、パブリッシャ25708は、追加の暗号化コンテンツを含むメッセージ25730をルータ25718に送信することができる。次いで、ルータ25718は、追加の暗号化コンテンツを含む通知メッセージ25732をサブスクライバ25706に送信することができる。次いで、サブスクライバ25706は、使用のために追加のコンテンツを復号することができる(25734)。
IoTネットワークは、セキュリティ、プライバシー、完全性、または安全性の分類に従って分割されることがよくある。分類を明確にするために、マルチレベルのセキュリティラベルを使用することができる。各レベルに関連するトピックまたはカテゴリのセットがあり得る。例えば、図244に関して説明したように、ブルームフィルタメカニズムを使用して、セキュリティラベルを含む通知を配信することができる。セキュリティラベルの後には、経路指定ノードや他のサブスクライバやパブリッシャが続くことがある。マルチレベルセキュリティラベルは、とりわけ、例えば、Biba Integrity ModelおよびBella-LaPadulaセキュリティモードを含む、複数の異なるモデルに基づき得る。
図258は、一部の実施形態による、パブリケーション-サブスクライブ型環境におけるマルチレベルセキュリティラベルの使用の概略図である。この図は、Biba完全性モデルとBell-LaPodula機密性モデルの使用法を示している。Biba完全性モデルでは、一般に、L1からL2などの上位レベルへの許可された書き込み(制約I)はなく、L0からL1などの下位レベルからの許可された読み取り(制約II)はない。Bell-LaPadula機密性モデルでは、一般に、L1からL0などの下位レベルへの許可された書き込み(制約III)はなく、L0からL1などの上位レベルへの許可された読み取り(制約IV)はない。
パブリッシャ25802は、ラベルカテゴリをブルームトピックCxにマッピングすることによって、セキュリティラベルをブルームフィルタとして符号化することができる。ラベルレベル自体は、ラベルカテゴリのいずれかが提供されているときに存在するトピックであり得る。異なるレベルのカテゴリが最初のレベルのカテゴリと混同されないように、レベルトピックをカテゴリトピックのそれぞれで符号化することが適切であり得る。符号化は、例えば、2つの値の暗号化ハッシュによって、または出力値が入力値のいずれとも衝突しないようになんらかの関数f()を適用することによって実現できる。例えば、レベルを表すビットパターンは、ビットパターンのXORを実行することによってトピックのビットパターンと共に処理されてもよい。次いで、結果として得られるビットパターンはブルームフィルタで使用されてもよい。
経路指定ノード25804は、セキュリティレベルトピックを認識し、次いで適切なセキュリティモデル挙動制約を適用することによってセキュリティポリシーセマンティクスを適用する。例えば、制約条件Iが守られる場合、ルータは、レベルL0で動作することを認可されたサブスクライバS0がレベルL1で動作することを認可されたパブリッシャから通知を受信することを可能にし得る。同様に、サブスクライバS2がレベルL2で動作することを認可されている場合、L1パブリッシャからの通知はブロックされる。
図258に示したマルチレベルセキュリティポリシーは排他的なものではない。他のマルチレベルセキュリティポリシーが使用されてもよい。さらに、本明細書で使用される例は、ネットワーク内の複数レベルへのマルチレベルセキュリティポリシーの適用を説明しているが、セキュリティレベルは、とりわけ、単一ネットワークレベル内の異なるセキュリティレベルとして定義され得ることに留意されたい。
図259は、一部の実施形態による、マルチレベルセキュリティポリシーを通知メッセージに適用するためにブルームフィルタを実装するための例示的な方法25900のプロセスフロー図である。図259の方法25900は、図260に関して説明されるIoTデバイス26000によって実施することができる。方法25900は、例えば、パブリッシャが共有するコンテンツを有する場合に、サブスクライバがコンテンツを要求しているときに、ブロック25902において開始し得る。ブロック25904において、これがパブリケーションであるか否かに関する判定が行われる。そうでなければ、そのアクティビティはサブスクリプションの登録であり得、そしてプロセスフローはブロック25906へ進む。
ブロック25906において、サブスクライバはルータノードに対するそのアイデンティティをアテステーションし、サブスクリプションが登録されているセキュリティレベルを開示する。ブロック25908において、サブスクライバは関心のあるコンテンツを含むブルームフィルタを供給する。本明細書で開示されるように、ブルームフィルタは、とりわけ、関心のあるトピック、カテゴリ、およびセキュリティレベルについての上書きされたビットハッシュコードを含み得る。
ブロック25910において、ルータが完全性ポリシーを施行しているか否かに関する判定が行われる。そうである場合、ブロック25912において、ルータは、下位ネットワークレベルへの読み取りを許可したフィルタ値をマスクオフすることができる。ブロック25914において、ルータが機密性ポリシーを施行しているか否かに関する判定が行われる。そうである場合、ブロック25916において、ルータは、上位ネットワークレベルまでの読み取りを可能にするフィルタ値をマスクオフすることができる。ブロック25918において、サブスクリプションはルータに登録される。次いで、方法25900は、ブロック25920で終了する。
ブロック25904において、アクティビティがパブリケーションであると判定された場合、プロセスフローはブロック25922に進む。ブロック25922において、パブリッシャは、パブリケーションが与えられるセキュリティレベルをルータノードにアテステーションする。ブロック25924において、カテゴリ内のセキュリティレベルは、パブリケーションコンテンツに対応するブルームフィルタに符号化される。本明細書で説明されるように、ブルームフィルタは、例えば、現在のパブリケーションに加えて、パブリックトピック、プライベートトピック、鍵管理トピック、セキュリティレベルトピックなどを含むことができる。
ブロック25926において、ルータが完全性ポリシーを施行しているか否かに関する判定が行われる。そうである場合、ブロック25928において、ルータは、上位ネットワークレベルまでの書き込みを可能にするフィルタ値をマスクオフすることができる。ブロック25930において、ルータが機密性ポリシーを施行しているか否かに関する判定が行われる。そうである場合、ブロック25932において、ルータは、下位ネットワークレベルまでの書き込みを可能にするフィルタ値をマスクオフすることができる。ブロック25934において、パブリッシュされた通知はルータ、サブスクライバ、または両方に送信される。次いで、方法25900は、ブロック25920で終了する。
図260は、一部の実施形態による、暗号化されたコンテンツを用いてトピック通知を管理するためのIoTデバイス26000に存在し得るコンポーネントの一例のブロック図である。IoTデバイス26000は、フォグ812などのIoTネットワークにおけるパブリッシャ、ルータ、またはサブスクライバとして機能することができる。同様の番号が付けられた項目は、図3、図8、図255、および図257に関して説明したとおりである。図8に関して説明したIoTデバイス800、および本明細書で説明される他のIoTデバイスに対して選択されたものとは異なるコンポーネントが、IoTデバイス26000に対して選択され使用されてもよいことに留意されたい。
IoTデバイス26000は、例えば、2009年にISO/IEC 11889としてTrusted Computing Groupによって公表された仕様に準拠する、トラステッドプラットフォームモジュール(TPM)を含むことができる。TPMは、暗号化プロセッサ(CP)、不揮発性メモリ(NVM)、およびセキュアメモリ(SM)を含み得る。CPは、とりわけ、乱数発生器、RSAハッシュ発生器、SHA-1ハッシュ発生器、および暗号化-復号エンジンを提供することができる。NVMは、例えばとりわけRSA鍵を含む、製造時にプログラムされた鍵を含み得る。SMは、ソフトウェアで得られた測定値をプラットフォーム構成レジスタに保持することができる。本明細書で使用される場合、測定値は、ストレージ808またはメモリ804に格納されたコードまたはデータセグメント上で計算されたハッシュコードである。ブートコードセグメントの測定から開始して、初期ブートから信頼チェーンを作成することによって、測定を使用してトラステッド実行環境(TEE)を確立することができる。SMはセキュアなストレージを提供することができる。
TPMを使用して、プログラムを実行するためのTEEまたはセキュアエンクレーブを確立することができる。TPMはまた、セキュアな通信のための暗号化サポートおよび識別のための鍵を提供することを含む、任意の数の他の機能のためにも使用され得る。
大容量ストレージ808は、本明細書で説明される暗号化コンテンツ配信機能を実施するための複数のモジュールを含むことができる。大容量ストレージ808においてコードブロックとして示されているが、モジュールのうちのいずれも、例えば特定用途向け集積回路(ASIC)に組み込まれるなど、ハードワイヤード回路で完全にまたは部分的に置き換えられ得ることが理解されよう。
大容量ストレージ808は、図255に関して説明したように、トピックネーミングサーバ25506を含むことができる。説明したように、トピックネーミングサーバ25506は、トピックグループの作成およびトピックグループの鍵の発行、セキュリティレベルなどのトピックを管理することができる。トピックネーミングサーバ25506は、循環部分鍵のアセンブルし、EPID鍵生成、ブロックチェーン鍵生成などの本明細書で説明される技法を含む、鍵を生成するために任意の数の技法を使用することができる。
サブスクライバ26002は、とりわけ関心のあるカテゴリ、トピック、およびセキュリティレベルを含むブルームフィルタを、ルータ、およびパブリッシャなどの他のデバイスに供給することができる。アテステーション部26004は、図257に関して説明したように、例えば、鍵配布センター25702に対して、パブリッシャまたはサブスクライバの識別情報をアテステーションすることができる。鍵配布センター25702は、フォグ812またはクラウド302内などの別のデバイス内に配置することができる。鍵配布センター25702は、フォグ812またはクラウド302内のデバイスのアイデンティティを確認し、トピック鍵、レベル鍵、またはその両方を他のデバイスに提供することができる。サブスクライバ26002は、関心のあるコンテンツの通知を受信し、関心のあるコンテンツを復号するために鍵配布センター25702から受信した鍵を使用することができる。
完全性施行部26006は、下位セキュリティレベルもしくはネットワークレベルまでの読み取り動作、上位セキュリティレベルもしくはネットワークレベルまでの書き込み動作、またはその両方を可能にするフィルタ値をマスクオフすることができる。機密性執行部26008は、上位セキュリティレベルもしくはネットワークレベルまでの読み取り操作、下位セキュリティレベルもしくはネットワークレベルまでの書き込み操作、またはその両方を可能にするフィルタ値をマスクオフすることができる。
図261は、一部の実施形態による、暗号化されたコンテンツを用いてトピック通知を管理するようにプロセッサ902に指示するためのコードを含む、非一時的機械可読媒体26100のブロック図である。プロセッサ902は、バス904を介して非一時的機械可読媒体26100にアクセスすることができる。プロセッサ902およびバス904は、図9に関して説明したプロセッサ902およびバス904と同様の方法で実施することができる。非一時的機械可読媒体26100は、図8の大容量ストレージ808について説明したデバイスを含むこともできるし、光ディスク、USBメモリ(thumb drive)、または任意の数の他のハードウェアデバイスを含むこともできる。
非一時的機械可読媒体26100は、トピックのための暗号化鍵、セキュリティレベル、またはその両方を生成するようにプロセッサ902に指示するためのコード26102を含み得る。コード26104は、暗号化鍵を鍵配布センターにプッシュするようにプロセッサ902に指示するために含まれ得る。次いで、鍵配布センターは、識別情報を確認するために鍵配布センターにアテステーションを提供するデバイスに鍵を提供することができる。デバイスは、とりわけ、パブリッシャ、ルータ、およびサブスクライバを含み得る。
コード26106は、暗号化されたトピックを例えばルータにパブリッシュするようにプロセッサ902に指示するために含まれ得る。コード26108は、ルータ、サブスクライバ、またはその両方などの他のデバイスにトピックの通知を送信するようにプロセッサ902に指示するために含まれ得る。トピック通知は、トピックがコンテンツを暗号化したという情報を含み得る。
コード26110は、例えば、暗号化鍵を要求するアテステーションメッセージを送信することによって、鍵配布センターから暗号化鍵を取得するようにプロセッサ902に指示するために含まれ得る。コード26112は、暗号化鍵を使用してコンテンツを復号するようにプロセッサ902に指示するために含まれ得る。
コード26114は、例えば、より低いセキュリティまたはネットワークレベルへの読み取りまたはより高いセキュリティまたはネットワークレベルへの書き込みを可能にするフィルタ値をマスクオフするなど、完全性ポリシーを施行するようにプロセッサ902に指示するために含まれ得る。コード26116は、例えば、より低いセキュリティまたはネットワークレベルへの読み取りまたはより高いセキュリティまたはネットワークレベルへの書き込みを可能にするフィルタ値をマスクオフするなど、機密性ポリシーを施行するようにプロセッサ902に指示するために含まれ得る。
IoTデバイスの機能を実施するために、任意の数の他のコードブロックを機械可読媒体26100に含めることができる。これらのコードブロックは、IoTデバイス間でパケットを構築し送信するための通信部、セキュアに実行されるコードのための測定を実行するためのセキュアブータ/測定部、鍵生成部、または本明細書で説明される任意の数の他のコードブロックを含み得る。
本明細書で説明される技法は、様々な目的のために任意の数のIoTネットワークを実装するために使用され得る。以下のセクションでは、実装できるその他のアプリケーションについて説明する。
第1の例では、IoTネットワークを使用して、清掃、メンテナンス、ごみ処理などの目立たない動作のためにロボットの群を実装することができる。ロボットは、人間が動作領域に接近しているとき、またはロボットに近接しているときに動きを最小にするように設計され得るため、シャイロボットとして説明することができる。シャイロボットは、存在、動き検出、および他のシャイロボット、人間、および他のサイバネティックシステムとの相互作用を含む複数のモダリティの下で機能を実行して、特定の目的を達成するための自律同時位置特定およびマッピング(SLAM)システムに基づき得る。
図262は、一部の実施形態による、シャイロボット26200の一例の図である。この例では、シャイロボットは、通行人によって落とされたくずやごみを拾うこともできるリサイクル用ごみ箱またはごみ箱26202である。ごみを自律的に収集することが主要な機能であり得るが、シャイロボットは、複数の拡張された機能および二次的な機能を有し得る。例えば、ごみ箱は、例えば公園や街区などの領域を動き回り、ごみを集めるために通常は隠された腕を使用することができる。
さらに、シャイロボットは、含まれるコンピューティング、メモリ、およびネットワーキング能力によって提供される二次的な機能を有することができる。シャイロボットは、例えば、駐車料金支払いアクセスポイント、インターネットアクセスポイントなどを提供するために、エッジノードまたはフォグノードとして動作し得る。インターネットアクセスポイントとして、それらはプロキシサーバとして動作するように構成され、一般的にアクセスされたウェブページをローカルにキャッシュしてユーザによるインターネット体験を改善する。彼らは、ローカルで収集されたあらゆるデータを格納して処理し、そのデータをクラウドに送信することで、例えば市または公的機関のための拡張されたセキュリティメカニズムとして動作することができる。これには、違法または反社会的活動の監視、警告、および抑止が含まれる。また、道に迷った場合の道順の提示、当局への連絡など、音声認識通信用に構成することもできる。
これらの機能を実施するために、シャイロボット26200は複数の異なるシステムを装備することができる。システムは、各シャイロボット26200内にIoTネットワークを形成する個々のIoTデバイスとして実装することができる。
シャイロボット26200は、複数のセンサ26204を有することができる。センサ26204は、環境に関するデータを収集して、シャイロボットがコンテキスト情報を収集し、動きおよび他の機能についてのローカル決定を下すことを可能にし得る。
電源26206は、シャイロボット26200に電力を供給するために使用され得る。電源は、バッテリ、充電器、太陽電池パネルなどの任意の数の構成を含み得る。
シャイロボット26200は、ロボットが、例えば他のシャイロボット、および他のローカルデバイスと共にフォグノードとして機能することを可能にするために、処理および分析システム26208を含み得る。これにより、とりわけ、データや処理サービスを提供したり、さらなる動作のために分析の結果をクラウドや人間に送信したりできる。実行され得る動作は、図264に関してより詳細に説明される。
機能の実行を補助するために、複数の格納式ユーティリティ26210が含まれ得る。例えば、ごみ箱26202は、その経路に沿ってくずを収集するように構成され得る隠れた格納式アームを含み得る。他の格納式ユーティリティ26210は、充電ステーションに自律的に接続する充電用の隠しプラグ、人間のデバイス用の充電ステーションなどを含み得る。
推進システム26212は、人、動物、または他の障害物が近くにあるか否かを判定する運動規則に応じて、シャイロボット26200を異なる場所に移動させるために含まれ得る。推進システム26212は、用途に応じて、モータ駆動のトラック、車輪、または他のシステムを含み得る。
図263は、一部の実施形態による、シャイロボット26200に存在し得るコンポーネントの一例のブロック図である。同様の番号が付けられた項目は、図8および図262に関して説明したとおりである。図8に関して説明したIoTデバイス800、および本明細書で説明される他のIoTデバイスに対して選択されたものとは異なるコンポーネントが、シャイロボット26200に対して選択され使用されてもよいことに留意されたい。
シャイロボット26200は、例えば、2009年にISO/IEC 11889としてTrusted Computing Groupによって公表された仕様に準拠する、トラステッドプラットフォームモジュール(TPM)を含むことができる。TPMは、暗号化プロセッサ(CP)、不揮発性メモリ(NVM)、およびセキュアメモリ(SM)を含み得る。CPは、とりわけ、乱数発生器、RSAハッシュ発生器、SHA-1ハッシュ発生器、および暗号化-復号エンジンを提供することができる。NVMは、例えばとりわけRSA鍵を含む、製造時にプログラムされた鍵を含み得る。SMは、ソフトウェアで得られた測定値をプラットフォーム構成レジスタに保持することができる。本明細書で使用される場合、測定値は、ストレージ808またはメモリ804に格納されたコードまたはデータセグメント上で計算されたハッシュコードである。ブートコードセグメントの測定から開始して、初期ブートから信頼チェーンを作成することによって、測定を使用してトラステッド実行環境(TEE)26302を確立することができる。SMはセキュアなストレージを提供することができる。
TEE 26302は、保護のためにハードウェア支援エンクレーブを必要とするプロセスを実行できる領域を提供する。TPM、および本明細書で説明される他の方法を使用して、シャイロボットの機能およびアイデンティティのアテステーションを、とりわけ、他のシャイロボット、クラウドベースのシステム、およびスマートフォンなどの携帯型ユーザデバイスを含む他のシステムに提供することができる。
シャイロボット26200は、時刻を追跡するためのクロック26304を含むことができる。これは、リアルタイムクロック(RTC)、原子時計、またはロボットに時刻を知らせることができる任意の種類のクロックである。都市での、農場での、または他の環境での活動は、時刻に直接相関している可能性がある。
説明したように、シャイロボット26200は、任意の数のセンサ26306を含み得る。センサ26306は、その本体から発せられる赤外線エネルギーによって人間または野生生物の存在を検出するために使用され得る赤外線(IR)および受動赤外線(PIR)センサを含み得る。超音波検出器は、近接する物体およびそれらの物体までの距離を検出するために使用され得る。超音波からのデータは、ロボットがナビゲートし、その範囲内の物体の動きを検出するのを助け得る。
センサ26306は、視聴覚(AV)センサを含み得る。音声データは、例えば、図264に関して説明したように、人間の存在を検出するために使用され得る。マイクロホンアレイは、音の到来角を使用し、音源の距離を推定し得る。カメラを使用して画像データを取得することができる。画像データは、例えば、エッジ検出、三次元画像検出などを含む任意の数の技法によって分析され得る。例えば、エッジ検出は、画像内のオブジェクトを識別し、オブジェクトまでの距離に関する判定を可能にし得るオブジェクトのサイズを判定するために使用され得る。視覚的検知はまた、光レベルの検出を含み得る。これをコンテキストエンジンに供給して、図264に関して説明したように、それを時刻または車両からの光、フラッシュライト、または街路灯からの光の接近と相関させることができる。
センサ26306は、D6Tすなわち熱センサを含み得る。D6Tセンサは、人間の熱シグネチャを認識するように構成され得るセンサである。それは、利用可能な異なる検出角度で、人間の存在または動きを検出するために使用され得る。次いで、検出角度の組み合わせは、広い範囲を提供することができる。しかしながら、D6Tセンサは、関心のある他の熱シグネチャに合わせて調整することもできる。
センサ26306は、例えば電話によって放出された電場を検出するための磁力計(mag)を含むことができる。マイクロ波レーダセンサは、対象物までの距離を判定するために組み込まれ得る。マイクロ波レーダセンサは、シャイロボット26200に低コストで追加することができ、機能性および経済性の両方を向上させる。
推進システム26308は、ロボットの動きを制御するためにロボットに含まれ得る。推進システム26308は、ロボットを動かすため、または例えば1つのトラックが他のトラックとは異なる方向に動かされるときに、ロボットを異なる方向に向けるために使用され得る、ツイントラックドライブなどの任意の数の既知のロボット推進システムを含み得る。他の推進システムは、3輪システムを含み得、2つの車輪が駆動され、第3の車輪は、三脚を完成させるために使用されるコースターである。このシステムでは、2つの車輪が駆動される方向を使用してロボットを操縦することができる。他の例では、用途に応じて異なる推進システムを選択することができる。例えば、ロボットは、例えばジェット駆動によって推進され、操舵のために方向舵を使用する、自律型水上機であり得る。他の例では、ロボットは、ヘキサコプター、クアドコプターなどの推進システムを使用する無人航空機、または翼上の揚力を発生させるために推進システムを使用する空力システムであり得る。
地理位置情報システム26310は、シャイロボット26200をナビゲートするのを助けるために、全地球測位システム(GPS)衛星受信機を使用して、位置、向き、またはその両方を判定することができる。位置データは、シャイロボットの群によって使用されて、それらの動きを調整し、ロボットの動作範囲内にゾーンを出入りする人間/野生生物の存在を伝えることができる。これについては、図265に関してさらに説明する。
ロボティクスシステム26312は、デバイス内に存在する任意のロボティクスを制御するために含まれ得る。例えば、ロボティックシステムは、ごみ拾いまたは充電ステーションへの自動接続のためのアームを格納することなどの機能を完了するためのデバイスを含み得る。デバイスは、例えば、ユーザデバイス用の外部充電ポートを覆うような、耐候性のドアを含み得る。ロボティックシステム26312は、プロセッサがステッピングモータ、ソレノイドなどのデバイスを制御することを可能にするドライバを含み得る。
シャイロボット26200は、充電システム26314を含み得る。充電システム26314は、本明細書で説明されるように、任意の数のバッテリ監視および充電デバイスを含み得る。さらに、充電システム26314は、バッテリ824を充電するために充電システム263142を外部電力に接続するための自動結合システムを含み得る。本明細書で説明されるように、ソーラーパネルなど、これを支援するために任意の数の他のデバイスが含まれてもよい。消費電力、および経済性に応じて、充電システム26314を削除し、デバイスは、バッテリを監視し、バッテリ残量が選択された下限、例えば10%の残余電力、5%の残余電力、またはそれ以下に達するとオペレータに知らせることができる。この例では、バッテリは、例えば、消耗したバッテリを取り外して充電されたバッテリの中に滑り込ませるためにオペレータによって容易に交換可能にされ得る。バッテリを交換している間、クロック設定、メモリ設定などを維持するために、スーパーキャパシタなどの他のデバイスを含めることができる。
電源出力システム26316は、外部デバイスに電力を供給するために含まれ得る。例えば、シャイロボット26200はまた、ユーザデバイスのための充電ステーションとして機能してもよい。充電ステーションは、USB接続、無線電力位置などを含み得る。
ネットワークシステム26318は、シャイロボット26200間の通信を提供するために含まれ得る。ネットワークシステム26318は、無線および/または有線の技術を含み得る。シャイロボット26200はクラウド接続されてもよい、および/またはピアツーピアネットワークおよび/または群のメンバとして動作してもよい。群として動作している間、同じような地理的領域にあるシャイロボットは、関心対象の情報を共有することができる。このシナリオでは、ロボットは人間の活動に関する情報を他のロボットに渡すことができる。
大容量ストレージ808は、本明細書で説明されるシャイロボット26200の機能を実施するための複数のモジュールを含むことができる。大容量ストレージ808においてコードブロックとして示されているが、モジュールのうちのいずれも、例えば特定用途向け集積回路(ASIC)に組み込まれるなど、ハードワイヤード回路で完全にまたは部分的に置き換えられ得ることが理解されよう。
大容量ストレージ808は、オペレーティングシステムおよび基本入出力システム(OS/BIOS)26318を含み得る。OS/BIOS 26318は、シャイロボット26200のオペレーティングシステムである。OS/BIOS 26318は、例えば、より高度なシステムで使用される種類の完全なOSであってもよいし、拡張BIOSであってもよい。
大容量ストレージ808は、シャイロボット26200ためのファームウェアおよびドライバ(FW/ドライバ)26320を含むことができる。FW/ドライバ26320は、センサ26306、推進力26308、地理位置26310、ロボット工学26312、およびネットワークシステム26318を動作させるのに必要なドライバを含み得る。さらに、FW/ドライバ26320は、オープンコネクティビティファウンデーション(OCF)によって発行されたもの、またはAllSeen Allianceによって発行されたAllJoyn仕様など、他のデバイスを発見するためのドライバを含み得る。FW/ドライバ26320は、本明細書で説明するように、オープンフォグコンソーシアム(OFC)用のものなどのフォグデバイスを形成するためのコードを含むことができる。
大容量ストレージ808は、コンテキストエンジン26322を含むことができる。コンテキストエンジン26322は、動きの制御、ロボット間通信の提供、バッテリ警告の送信などの機能をシステムに提供することができる。本明細書で説明されるように、コンテキストエンジン26322は、システムメモリから実行されてもよいし、特定用途向け集積回路(ASIC)またはフィールドプログラマブルゲートアレイ(FPGA)内にあってもよい。
図264は、一部の実施形態による、コンテキストエンジン26322の動作26400の概略図である。同様の番号が付けられた項目は、図263に関して説明したとおりである。動作26400は、例えばロボットがオンラインになったときに、ブロック26402において開始し得る。
センシング26404は、人間、野生生物、またはごみもしくは他のターゲット項目などの他の対象物の付近での存在を判定するための情報を収集するために実行され得る。図263に関して説明されたセンシングユニット26306は、近くに人間または野生生物の存在をはっきりさせるために必要とされる情報を提供する。
例えば、動き検出部または近接検出部は、近くに動きがあるか否かを検出することができる。動きには、人間、野生生物、または風に吹き飛ばされているビニール袋などのその他の物体が含まれ得る。動きの判定は、生きているものと、ビニール袋などのそうでないものとを区別するために動きの種類を分類し得る。
検知26404は、時刻の判定を含み得る。公園や街の通りなど、すぐ近くの様々な地域では、1日の異なる時間帯に混雑している場合がある。混雑時とそれ以外との週の時間にロボットを訓練するために学習アルゴリズムを組み込むことができる。特定の時間が常に混雑している場合、ロボットは、それらの時間帯に動きを制限するように構成され得る。
センシング26404は、音のレベルおよび方向を検出および分類し、音が人間または動物の音源によるものであるか否かを判定し、音までの距離を判定して、人間または動物の音源によるものかを判定し、距離を判定するための音声検出部の使用を含み得る。
センシング26404が終了すると、コンテキストエンジン26322は、さらなる処理のためにセンサの読み取り値を0から1の間の値に正規化することができる。それは、例えば関心のある範囲内の値に重点を置く重み付け係数を使用して、センサによって検出可能な可能な値の範囲内に観測値を配置することによってこの機能を実行することができる。例として音声センサを使用して、音声センサが0Hzから40KHzの範囲の音を検出することができ、関心のある範囲が人間の聴力の範囲、例えば20Hzから20KHzである場合、200Hzの観測値は、(200/40Khz)*1として計算できる。観測値が関心のある範囲外になった場合は、1未満の係数を使用できる。
コンテキストエンジンに供給される各センサソースS
nについて、アルゴリズムは以下の式に基づき得る。
この式では、S
nはセンサnからの値である。項μは、0から1の間の値を有する重み付け係数である。重み付け係数は、可能なすべての値にわたって任意の変換関数によって適用することができ、それにより、関心のある範囲は1または1に近い値を有し、関心の少ない範囲は0または0に近い値を有する。項O
snは、センサnからの現在の読み取り値に対する特定の観測値である。項Max
snは、センサから取り得る最大値である。
移動する決定26406は、センサからの特定の読み取り値に基づいて行われ得る。プロセスは26408において終了する。他のセンサの読み取り値に対するセンサの読み取り値の重要性に重みを付けるために、重みをセンサの読み取り値に適用することもできる。例えば、システム設計者は、音声が動き検出部よりも人間または動物の存在のより良い指標であると判定したかもしれない。変数Mを移動するという決定は、0から1の間の値を有することができる。意思決定はいくつかの方法で実行することができ、例えば、Mに対する加重平均値を使用することができる。この技法では、入って来る値はそれに割り当てられた重みwを持ち、移動するか否かの決定をするために使われる最終値はそれらの値の加重平均である。
最大加重値の技法が使用されてもよく、最大加重値がMの値として採用される。 M=max(w
1Sn
1,...,w
iSn
i)
加えて、コンテキストエンジン26322は、群内の近隣のロボットからの警告を受け入れために警告モニタを実装することができる。他のセンサの読み取り値に関しては、警告モニタの出力は0から1の間の値であり得る。この値は、警告を送信しているピアロボットまでの距離によって異なり得る。例えば、より遠いピアロボットはより低い読みをもたらし得るが、より近いピアロボットはより高い読みをもたらし得る。従って、より高い値は、人間または動物がシャイロボットの視野に入っていく可能性がより高いことに対応し得、コンテキストエンジンの意思決定に対してより高い影響を及ぼし得る。
これらの技法に加えて、またはそれらの代わりに、任意の数の他の技法も使用され得る。これらは、例えば、機械学習、ニューラルネットワーク、ハードウェア支援学習などを含み得る。例えば、センサの読み取り値は、事前に訓練されたニューラルネットへの入力として、またはIntel(登録商標)Atlas Peakプロセッサ内のARCプロセッサなどのハードウェア支援型学習プラットフォームへの入力として使用され得る。
移動するという決定がなされると、ロボットは自らを新しい場所へナビゲートする。動きを制御するために任意の数の技法を使用することができる。例えば、ロボットは、公園のベンチ、街灯柱、特定の歩道領域などの既知の固定された障害物の周りの固定された領域内を移動することができる。ロボットは、舗装路または遊歩道上の塗装による線または埋められた線をたどることができる。さらに、ロボットは、ナビゲートするためにADASの分野で開発された技術を組み込んでもよい。ロボットは、指定された「停止」ポイント、すなわちベースを有する事前に定められた経路に沿ってGPS誘導されてもよく、妨害を引き起こさずにそうする可能性が高い場合を除き、ロボットは次のベースに移動しない。あるいは、ロボットは、経路に沿ったどこかで停止することを許可され得る。
このように動作しているロボットは、それぞれの観察結果を組み合わせて、近隣のロボットにその地域で活動に気付いたときに警告することで大きな利益を得ることができる。これは群(swarm)動作と呼ばれ得る。これにより、図265に関して説明したように、ロボットがそのセンサの直接範囲を超えて情報を得てこれを他のロボットに送ることが可能になる。
図265は、一部の実施形態による、シャイロボットの群の動作26500の概略図である。ロボットと他の自律型SLAMロボットとの協調によって、単一のユニットでは達成できない動作の実行が可能になり得る。このプロセスは、ピアツーピアおよびブロードキャスト方法での共通の通信、挙動、およびセキュリティプロトコルの確立を含み得る。各ロボットRは、2つの一般的な検出ゾーン、すなわち、活動の検知が検出の確実性高く行うことができる内側ゾーン26502と、感知活動を確実性低く行うことができる外側ゾーン26504と、を有することができる。ロボット26506が、ゾーン26502または26504のうちの1つを通って移動している物体26508を検出した場合、検出を知らせるために警告メッセージ26510を最も近い近隣ロボット26512に送信することができる。警告メッセージ26510は、物体26508の動きおよび位置、ならびに検出の確実性などの情報を含み得る。
群として、ロボットは、個々のタスクに加えてグループタスクをいくつでも実行できる。これらには、仮説の生成およびテスト、集合への役割およびサブタスクの委任、タスクの実行、完全なサブタスクの確認、データの集約および分析、評判ベースのフィードバック、報酬メカニズムなどの動作が含まれる。
図266は、一部の実施形態による、シャイロボットを群で動作させるための例示的な方法26600のプロセスフロー図である。図266の方法26600は、図262および図263に関して説明したシャイロボット26200によって実施することができる。本方法は、例えば、シャイロボットに電源が投入されたときに、ブロック26602において開始し得る。
ブロック26604において、シャイロボットは制御システムをブートする。これには、オペレーティングシステムまたは拡張BIOSのロードが含まれ、次いでコードのロードまたはファームウェアの初期化が含まれ得る。次いで、シャイロボットは、あなたが動作のために必要し得るドライバまたは他のソフトウェアをロードし得る。これは、例えば、シャイロボット内にTEEを作成するための測定値を得るためにTPMを使用して、セキュアブートプロセスの一部として行われ得る。
ブロック26606において、ロボットは利用可能なすべてのセンサをエニュメレーションすることができる。これらは、ロボット自体に配置されていない可能性があるセンサを含む、図263に関して説明された任意のセンサのセットを含み得る。これらは、電柱、建物、および他の物体上に配置された動きセンサなど、リモートに配置されたセンサであり得る。さらに、ロボットは、群内の他のロボットのセンサを利用することができる。従って、群内の一部のロボットは、群内の他のロボットよりも高度なセンサシステムを有することができる。センサはロボットに組み込まれてもよいが、例えばセンサをUSBポートまたは同様の拡張ポートもひくはスロットに挿入すること、および/またはそれらを無線で接続することによって、動作中にセンサを動的に追加することができる。
ブロック26608において、ロボットはその動作を初期化する。初期化の一部として、ポリシーがロードされる。ポリシーは、警告のための規則、およびコンテキストエンジンによって使用される任意のハードセットまたは動的閾値もしくは係数を含み得る。シャイロボットが無人航空機システム(UAS)に関するFCC規制などの規制に準拠していることを確認するためのポリシーを実装することもできる。その時点でコンテキストエンジンも初期化され得る。
ブロック26610において、ロボットは、例えば存在または動きを検出すること、目標指向挙動を実施することなどによって、通常の動作を開始することができる。接続されたセンサはデータをコンテキストエンジンに送り、データは図264に関して説明したように分析される。
ブロック26612において、存在が検出されたか否かに関する判定が行われる。検出された場合、ブロック26614において、例えば警告しているピアおよび動きを止めることに関して、シャイロボットがその存在を検出すると取るべき行動を判定するために警告ポリシーがチェックされる。
ブロック26616において、ロボットは、その推進システムにコマンドを発行してそれを停止させることができる。ロボットは、その機能に応じて、直ちに停止することも、停止するために最も近い事前定義された場所に移動することもできる。ロボットがサイクリングパスの途中など、問題のある場所にいる場合は、問題のある位置の外側の地点に移動するように指示され得る。
ブロック26618において、シャイロボットは、群内の他のロボットに警告することができる。警告ポリシーは、どのピアに警告するか、例えばとりわけ、最も近い近隣機に最初に警告するか、すべてのロボットに直接ブロードキャスト警告するかに関する規則および閾値を含むことができる。その結果従って、警告ポリシーは、警告を使用する可能性が最も高いピアロボットに警告を優先的に送信することで、群ノード間のネットワークトラフィックの効率を向上させることができる。
次にプロセスフローはブロック26610に戻り、検出機能を再開する。シャイロボットは、場合により、存在が検出されなくなるまで動かなくてもよい。
ブロック26620で存在が検出されない場合、シャイロボットが動くべきか否かに関する判定を行うことができる。動きは、検出されない場合、以前の動きの継続であり得る、またはシャイロボットの近くのごみ片を拾うなどの機能を完成させるために使用される新しい動きとすることができる。
ブロック26622において、シャイロボットは、その現在位置を取得するために地理位置情報技法を使用することができる。ブロック26624において、シャイロボットは、現在位置、一片のごみなどのターゲットの位置、およびターゲットに到達するためのパスを使用して地図を作成することができる。ロボットは、マッピングにいくつかの方法のいずれかを使用することができる。GPSを使用して場所を判定し、インターネットからダウンロードした地図と比較することができる。ブロック26626において、推進システムは、シャイロボットを現在位置からターゲット位置に移動させるために使用され得る。シャイロボットは、有線や磁気などの電子的ガイドライン、または塗装線などの光学的ガイドラインに従うことができる。さらに、シャイロボットは、1つのごみを拾うなど、ターゲットタスクを完了するのに必要な任意の数の方向に移動することができる。いずれにせよ、一部の実施形態では、存在が検出されない限り、ロボットは動くという選択肢を有する。
図267は、一部の実施形態による、シャイロボットの動作を管理するようにプロセッサ902に指示するためのコードを含む、非一時的機械可読媒体26700のブロック図である。プロセッサ902は、バス904を介して非一時的機械可読媒体26700にアクセスすることができる。プロセッサ902およびバス904は、図9に関して説明したプロセッサ902およびバス904と同様の方法で実施することができる。非一時的機械可読媒体26700は、図8の大容量ストレージ808について説明したデバイスを含むこともできるし、光ディスク、USBメモリ(thumb drive)、または任意の数の他のハードウェアデバイスを含むこともできる。
非一時的機械可読媒体26700は、シャイロボットを信頼された実行環境(TEE)内でブートするようにプロセッサ902に指示するためのコード26702を含み得る。コード26704は、シャイロボットに組み込まれたセンサ、外部センサ、新たに取り付けられたセンサ、およびロボット群の他のメンバに関連付けられているセンサを含む、シャイロボットに関連付けられているセンサを発見するようにプロセッサ902に指示するために含まれ得る。
コード26706は、例えば、ポリシーをロードしてコンテキストエンジンを起動するなど、ロボットを初期化するようにプロセッサ902に指示するために含まれ得る。コード26708は、人、野生生物、またはとりわけ、自動車、自転車などのシャイロボットが反応する必要がある他の物体の存在を検出するようにプロセッサ902に指示するために含まれ得る。これらのオブジェクトは、機械可読媒体内のポリシー内のオブジェクトのリストに格納することができ、各オブジェクトは、シャイロボットが実行することになる動作に関連付けられる。動作は、動作を終了させること、物体の邪魔にならないところへ移動すること、収集される物体に向かって移動することなどを含むことができる。
コード26710は、例えば、ごみ拾い、インターネット通信の提供、充電器ユニットへの自律的接続などの構成された機能を実行するようにプロセッサ902に指示するために含まれ得る。コード26712は、例えば機能を実行する、シャイロボットを充電する、近づいてくる人または交通の邪魔にならないように移動するなどのために、シャイロボットを新しい場所に移動させるようにプロセッサ902に指示するために含まれ得る。
コード26714は、群の中の他のロボットと通信するようにプロセッサ902に指示するために含まれてもよい。これは、存在の検出に関して他のロボットに警告するため、機能の実行を調整するためなどに実行され得る。
IoTデバイスの機能を実施するために、任意の数の他のコードブロックを機械可読媒体26700に含めることができる。これらのコードブロックは、IoTデバイス間でパケットを構築し送信するための通信部、セキュアに実行されるコードのための測定を実行するためのセキュア測定部、鍵生成部、または本明細書で説明される任意の数の他のコードブロックを含み得る。
他のアプリケーションでは、IoTパワーデバイスを使用してサイトを保護し、イベント中にサービスを提供することができる。モバイルIoTデバイスの予期しない協調を含むシナリオとしては、とりわけ、緊急事態、動的な交通管制、複数の当事者や目的地への到着、荷物の配達と配送、乗車の共有、または航空交通管制を挙げることができる。
プライバシーおよびセキュリティは、これらの各ケースの考慮事項であり得る。デバイスがクレデンシャルなしでシーンに到着した場合、そのデバイスが不正なデバイスであり得る否かはわからない。さらに、あるシーンでのイベントは、プライバシーセンシティブであり得る。従って、感知されたシーンの条件およびアウェアネスは、旅行者の収集および使用の制御を受け得る。本明細書で使用されているように、旅行者はシーンでの相互作用を予想しているエンティティを指す。
1つの例では、旅行者は、一連のウェイポイントが交差する目的地への経路をたどることを予想する。旅行計画部は、旅行中に遭遇するであろう予想ウェイポイントを計算する。各ウェイポイントで、プレファーストレスポンダの管轄が計算される。図270および図271に関して説明したように、緊急管理(EM)ツリー構造を使用して、EMツリーから生成された鍵で保護されている通信を調整するために、旅行者およびプレファーストレスポンダ、とりわけ無人機、ロボット、または自走式車両などによって使用され得る鍵を生成することができる。
図268は、一部の実施形態による、権限内のシーンに対するプレファーストレスポンダデバイスとしての無人機を示すユースケース26800の概略図である。ユースケース26800では、セキュリティおよびプライバシー保護暗号化を用いてプレファーストレスポンダデバイス(PFRD)26802をコミッショニングするときに3つの管轄シナリオが考慮され得る。図268(A)に示す第1の例示的ユースケースでは、単一の管轄区域26806が存在し、すべての緊急応答部26804はその管轄区域からのものである。PFRD 26802は、複数種類の緊急応答部26804に代わって単一の管轄区域26806内で機能することを認可されている。図268(B)において、PFRD 26802は、N種類の緊急応答部26804に代わって、重複する管轄区域26808内で機能することを認可されている。図268(C)では、PFRD 26802は、N種類の緊急応答部26804に代わって、3つの別々の異なる管轄区域26810内で機能することを認可されている。
図269は、一部の実施形態による、図268の単一および複数の権限制御域に関連する参加および登録プロセスを実行するための例示的な方法26900のプロセスフロー図である。図269の方法26900は、図274に関して説明されるPFRD 27400によって実施することができる。本方法は、例えば緊急事態などのイベントに参加するためのコマンドをプレファーストレスポンダデバイス(PFRD)が受信したときに、ブロック26902において開始し得る。
ブロック26904において、PFRDは、それが参加し得る管轄区域をチェックする。ブロック26906において、例えば、図268(A)に関して説明したように、PFRDが単一の管轄区域に参加しているという判定が行われる。ブロック26908において、PFRDは、通信を許可するために管轄区域と鍵を交渉する。ブロック26910において、PFRDは、鍵を使用して単一管轄区域に登録する。
ブロック26912において、登録が成功したか否かに関する判定が行われる。そうである場合、PFRDのための通信タスクはブロック26914において開始し得る。登録が成功しなかった場合、ブロック26916において、管轄制御ネットが警告される。
ブロック26918において、PFRDが重複する管轄に参加している可能性があるか否かに関する判定が行われる。もしそうであれば、ブロック26920において、重複する管轄区域を用いて共有鍵交渉が行われる。管轄区域が重複しているため、両方の管轄区域への通信のために単一の鍵が発行され得る。
ブロック26922において、プロセスフローがブロック26912に戻って登録が成功したか否かを判定する前に、発行済み鍵を使用して管轄区域1に登録する。ブロック26924において、発行鍵は、処理フローがブロック26912に戻って登録が成功したか否かを判定する前に、管轄区域2に登録するために使用される。ブロック26926に示されるように、登録は任意の数の他の管轄区域を通じて継続することができる。
ブロック26928において、PFRDが同時に参加している可能性がある複数の重複しない管轄区域があるか否かに関する判定が行われる。もしそうであれば、ブロック26930において、個々の管轄区域のそれぞれと個々の鍵交渉が行われる。鍵が個々の管轄区域のそれぞれから発行されると、プロセスフローはブロック26922に進み、管轄区域のそれぞれとの登録を開始する。
ブロック26906、26918、または26928で管轄区域が識別されない場合、ブロック26932において、PFRDは、管轄区域のいずれにも登録することを許可されないことがある。登録プロセスが管轄区域のうちの1つまたは複数について失敗した場合、警告が制御ネットにディスパッチされる。
図270は、一部の実施形態による、目的地への経路27004を判定するための緊急応答部(ER)27002または他のエンティティのための例示的な旅行計画27000の概略図である。旅行計画27000は、経路27002に沿って様々なシーン、ウェイポイント、位置、交差点および目的地を予測する。旅行計画27004は、代替経路および直前またはオンデマンド計画を含むことができる。各ウェイポイント27006において、位置座標および到着予定時刻27008を計算することができる。時間の粒度は、早い到着または遅い到着を可能にするように選択することができる。ウェイポイント27006ごとに、予想されるPFRDコミュニティが応答するように依頼され得る管轄区域にウェイポイントをマッピングするエントロピー多重化(EM)ツリー27010が見出される。緊急応答部のユースケースのコンテキストを考えると、PFRDは、旅行者によって開発されたEMツリー27010(ER 27008)の分岐にコミッションされている。
旅行計画27000からの旅行情報は、潜在的なPFRDと共有されるランダムなノンス値を含み得る。これはシーンでER 27008によって確認され得る。ノンスは、PFRDが正しいEMツリーを使用していることを確保する。旅行計画は、各PFRD参加者にEPID秘密鍵を発行することによって旅行に応答者を登録することを含み得る。EPIDは、シーンでPFRDを認証するために使用できる。
図271は、一部の実施形態による、各ウェイポイントでのEMサブツリー27102および27104の使用の概略図である。この例では、第1のEMサブツリー27102は、所与の場所(A)および時間(A~C)に対するEMツリーを表す。第2のEMサブツリー27104は、経路上のさらに別の位置(N)および時間(A~C)を表す。各EMサブツリー27102および27104は、時間27106を減少する粒度で符号化する。PRFDは、管轄区域の適用範囲の様々な順列を考慮に入れてその管轄区域と整列するEMサブツリー27102または27104を用いてプロビジョニングされる。例えば、プライバシーおよびセキュリティを向上させるために、複数の管轄区域間の重複を表すために別個のサブツリー分岐27108を使用することができる。あるいは、PFRDは、それがこれらの複数の管轄区域にデプロイされることを可能にするいくつかのサブツリー分岐27110を用いてプロビジョニングされ得る。
図272は、一部の実施形態による、あるシーンでのPFRDネットワークの動的構成のための例示的な方法27200のプロセスフロー図である。図272の方法27200は、図274に関して説明されるPFRD 27400によって実施することができる。方法27200は、緊急応答部または他の旅行者がターゲット目的地に踏み出すときに、ブロック27202において開始し得る。ブロック27204において、経路に沿ったPFRDがトリガされるか否かに関する判定が行われる。もしそうであれば、ブロック27206において、例えば、トラステッド実行環境(TEE)内のセキュアなストレージからポリシーが取得される。ブロック27208において、TEEセキュアストレージにプロビジョニングされた初期飛行計画ポリシーがロードされアクティブ化される。飛行計画ポリシーは、PFRDが完了しようとしている特定の動作を含むことができる。これらは、アンカーポイントからの切り離し、ホバー、画像のキャプチャ、画像認識の実行などの動作を含み得る。無人機以外の自律型水上艇などの他の自律型航走体が使用される場合、マッピングポリシーは、障害物を回避すること、速度を制御することなどの他の活動を含むことができるTEEセキュアストレージにプロビジョニングされ得る。
ブロック27210において、劣悪なネットワーク接続があるか否かに関する判定が行われる。そうである場合、ブロック27212において、最大接続ポリシーがTEEセキュアストレージから取得され、実施される。これらのポリシーは、例えば、タワーと通信するために特定の位置に移動されるなどのコマンドを含み、現在の位置に基づき得る。
ブロック27214において、PFRDがERコントラクトを遵守するか否かに関する判定が行われる。そうである場合、ブロック27216において、リモート管理ポリシーがTEEセキュアストレージから取得され、実施される。ブロック27218において、リモート飛行管理を許可することができ、それによってERはさらなる情報を収集することができる。これにより、インシデントの準備が改善され、初期構成されたポリシーに追加され得る。
方法27200は、ブロック27220で終了する。これは、例えば、ブロック27204でPFRDがトリガされない場合、またはブロック27214でERコントラクトが遵守されない場合に行われ得る。
図273は、一部の実施形態による、PFRDによってシーン情報をビーコン送信するための例示的な方法27300のラダー図である。図273の方法27300は、図274に関して説明されるPFRD 27400によって実施することができる。緊急応答部(ER)27302などの旅行者がシーンに到着すると、そのシーンに参加することを認可された他のデバイス間のメッセージを暗号化するために使用される鍵が、シーンシードを与えられて動的に生成される。参加者デバイスは、旅行計画部27304からのシーン情報にEPIDを用いて署名し、それを検証のために旅行者に供給することによって、その認可をアテステーションすることができる。
デバイス27302がシーンに到着すると、必要なポリシー、鍵、および他の情報にアクセスするためにプロビジョニング27306が行われ得る。これは、帯域外(OOB)プロビジョニングアクセスを介して実行されてもよい。
旅行計画27308は、旅行計画部27304によって提供される旅行計画メッセージ27310を介してER 27302に提供され得る。緊急応答部の支援が必要か否かに関する判定27312が行われる。そうであれば、旅行計画部は、EMツリーを使用して応答部を識別し、助けを求めるために緊急応答部にpingすることによって、緊急応答部を識別することができる(27314)。ビーコンアテステーションメッセージ27316は、旅行計画部27304とER 27302のそれぞれとの間で交換され得る。さらに、ER 27302は、リソース割り当てのためにそれらどうしの間で27318を交渉することができる(27318)。次いで、ER 27302は、ビーコンを確認応答し、そのER 27302が使用中のポリシーを旅行計画部27304に通知するメッセージ27320を返すことができる。
図274は、一部の実施形態による、プレファーストレスポンダ無人機(PFRD)27400に存在し得るコンポーネントの一例のブロック図である。同様の番号が付けられた項目は、図8および図263に関して説明したとおりである。図263に関して説明したシャイロボット26300、図8に関して説明したIoTデバイス800、および本明細書で説明される他のIoTデバイスに対して選択されたものとは異なるコンポーネントが、PFRD 27400に対して選択され使用されてもよいことに留意されたい。例えば、PFRD 27400は、無人機または他の無人航空機であり得る。従って、PFRD 27400のための推進システム26308は、ヘキサコプターまたはクアドコプターシステムであり得る。一部の例では、PFRD 27400は、無人空気力学的航空機などの空気力学的飛行体であり得る。
PFRD 27400は、例えば、2009年にISO/IEC 11889としてTrusted Computing Groupによって公表された仕様に準拠する、トラステッドプラットフォームモジュール(TPM)を含むことができる。TPMは、暗号化プロセッサ(CP)、不揮発性メモリ(NVM)、およびセキュアメモリ(SM)を含み得る。CPは、とりわけ、乱数発生器、RSAハッシュ発生器、SHA-1ハッシュ発生器、および暗号化-復号エンジンを提供することができる。NVMは、例えばとりわけRSA鍵を含む、製造時にプログラムされた鍵を含み得る。SMは、ソフトウェアで得られた測定値をプラットフォーム構成レジスタに保持することができる。本明細書で使用される場合、測定値は、ストレージ808またはメモリ804に格納されたコードまたはデータセグメント上で計算されたハッシュコードである。ブートコードセグメントの測定から開始して、初期ブートから信頼チェーンを作成することによって、測定を使用してトラステッド実行環境(TEE)26302を確立することができる。SMはセキュアなストレージを提供することができる。
TEE 26302は、保護のためにハードウェア支援エンクレーブを必要とするプロセスを実行できる領域を提供する。TPM、および本明細書で説明される他の方法を使用して、PFRD 27400の機能およびアイデンティティのアテステーションを、とりわけ、旅行計画部、緊急応答部、クラウドベースのシステム、およびスマートフォンなどの携帯型ユーザデバイスを含む他のシステムに提供することができる。
ネットワークシステム26318は、PFRD 27400間の通信を提供するために含まれ得る。ネットワークシステム26318は、無線または有線の技術を含み得る。PFRD 27400はクラウド接続されてもよいし、ピアツーピアネットワークまたは群のメンバとして動作してもよい。群として動作している間、同じような地理的領域にあるPFRDは、関心対象の情報を共有することができる。このシナリオでは、PFRDは緊急応答部、通信ポリシー、イベント、およびその他の関連情報に関する情報を他のPFRDに渡すことができる。
大容量ストレージ808は、本明細書で説明されるPFRD 27400の機能を実施するための複数のモジュールを含むことができる。大容量ストレージ808においてコードブロックとして示されているが、モジュールのうちのいずれも、例えば特定用途向け集積回路(ASIC)に組み込まれるなど、ハードワイヤード回路で完全にまたは部分的に置き換えられ得ることが理解されよう。
大容量ストレージ808は、オペレーティングシステムおよび基本入出力システム(OS/BIOS)26318を含み得る。OS/BIOS 26318は、PFRD 27400のオペレーティングシステムである。OS/BIOS 26318は、例えば、より高度なシステムで使用される種類の完全なOSであってもよいし、拡張BIOSであってもよい。
大容量ストレージ808は、PFRD 27400のためのファームウェアおよびドライバ(FW/ドライバ)26320を含むことができる。FW/ドライバ26320は、センサ26306、推進力26308、地理位置26310、ロボット工学26312、およびネットワークシステム26318を動作させるのに必要なドライバを含み得る。さらに、FW/ドライバ26320は、オープンコネクティビティファウンデーション(OCF)によって発行されたもの、またはAllSeen Allianceによって発行されたAllJoyn仕様など、他のデバイスを発見するためのドライバを含み得る。FW/ドライバ26320は、本明細書で説明するように、オープンフォグコンソーシアム(OFC)用のものなどのフォグデバイスを形成するためのコードを含むことができる。
大容量ストレージ808は、シーン評価コントローラ27402を含むことができる。シーン評価コントローラは、動きの制御、画像のキャプチャおよび転送、ユーザデバイスへのネットワークプロビジョニング、デバイス間通信、バッテリ警告などの機能をシステムに提供することができる。本明細書で説明されるように、シーン評価コントローラ27402は、システムメモリから実行されてもよいし、特定用途向け集積回路(ASIC)またはフィールドプログラマブルゲートアレイ(FPGA)内にあってもよい。
PFRD 27400では、ハードウェアは、例えば、セキュアストレージ内のEMシードをセグメント化し、Intel(登録商標)SGX、Intel(登録商標)CSME、Intel(登録商標)VTx、または他のシステムなどのトラステッド実行環境技術を使用することによって、信頼性を高めることができる。Intel(登録商標)DRNGは、制約のあるデバイスが格納されたシード値から動的に鍵を生成することが可能であるように、ツリー生成の品質および性能を向上させることができる。
図275は、一部の実施形態による、プレファーストレスポンダデバイスの動作を管理するようにプロセッサ902に指示するためのコードを含む、非一時的機械可読媒体27500のブロック図である。プロセッサ902は、バス904を介して非一時的機械可読媒体27500にアクセスすることができる。プロセッサ902およびバス904は、図9に関して説明したプロセッサ902およびバス904と同様の方法で実施することができる。非一時的機械可読媒体27500は、図8の大容量ストレージ808について説明したデバイスを含むこともできるし、光ディスク、USBメモリ(thumb drive)、または任意の数の他のハードウェアデバイスを含むこともできる。
非一時的機械可読媒体27500は、例えば緊急応答部がPFRDの管轄に入ったときに、PFRDをトリガするようにプロセッサ902に指示するためのコード27502を含み得る。コード27504は、ホバリング、画像のキャプチャなどを含む飛行操作などの自動化された操作のためのポリシーを取得するようにプロセッサ902に指示するために含まれ得る。
コード27506は、旅行計画部のための旅行計画を受け入れ、旅行計画を緊急応答部に提供するようにプロセッサ902に指示するために含まれ得る。コード27508は、劣悪なネットワーク伝導性を検出し、通信のためのポリシーを実施するようにプロセッサ902に指示するために含まれ得る。
コード27510は、緊急応答部がデータ収集のためにPFRDを制御することを可能にするなどのリモート管理機能を実施するようにプロセッサ902に指示するために含まれ得る。コード27512は、例えばリモート制御モードにおいて、リモート操作管理を可能にするようにプロセッサ902に指示するために含まれ得る。コード27514は、リモートネットワークアクセスをユーザに提供するようにプロセッサ902に指示するために含まれ得る。
IoTデバイスの機能を実施するために、任意の数の他のコードブロックを機械可読媒体27500に含めることができる。これらのコードブロックは、IoTデバイス間でパケットを構築し送信するための通信部、セキュアに実行されるコードのための測定を実行するためのセキュア測定部、鍵生成部、または本明細書で説明される任意の数の他のコードブロックを含み得る。
実施例1は、装置を含む。本装置は、デバイスオーナーであって、デバイスオーナーがまた、コンポジットオブジェクトを形成するサブオブジェクトに名前を提供するネームサーバと、コンポジットオブジェクトを形成する前記サブオブジェクトのサブオブジェクトリストと、を有する、デバイスオーナーと、コンポジットオブジェクトを形成する複数のサブオブジェクトと、コンポジットオブジェクトを形成するサブオブジェクトを記録するブロックチェーンと、を備える、コンポジットオブジェクトを含む、装置。
実施例2は、実施例1の主題を含む。実施例2では、サブオブジェクトが、下位レベルのサブオブジェクトから形成されたコンポジットオブジェクトを含む。
実施例3は、実施例1または2のいずれかの主題を含む。実施例3では、サブオブジェクトはアトミックオブジェクトを含む。
実施例4は、実施例1から3のいずれかの主題を含む。実施例4では、コンポジットオブジェクトの名前は、複数のサブオブジェクトの名前から計算されたハッシュを含む。
実施例5は、実施例1から4のいずれかの主題を含む。実施例5では、各サブオブジェクトは、サブオブジェクトがグループに代わって動作することを可能にするグループ鍵を含む。
実施例6は、実施例1から5のいずれかの主題を含む。実施例6では、デバイスオーナーは、EPIDサーバを含む。
実施例7は、実施例1から6のいずれかの主題を含む。実施例7では、デバイスオーナーは、プロキシブローカを含む。
実施例8は、実施例1から7のいずれかの主題を含む。実施例8では、デバイスオーナーは、ブロックチェーンを含む。
実施例9は、実施例1から8のいずれかの主題を含む。実施例9では、ブロックチェーンは、コンポジットオブジェクトの記録を含む。
実施例10は、IoTネットワークにおけるコンポジットオブジェクトを形成するための方法を含む。IoTネットワークにおけるコンポジットオブジェクトを形成するための方法は、デバイスオーナーにおいてサブオブジェクトのリストを構築する段階と、集合グループ識別子を作成する段階と、ブロックチェーントランザクションにおいて集合グループ識別子をブロックチェーンにコミットする段階と、ネームサーバにおいてブロックチェーンからグループ名を取得する段階と、を含む。
実施例11は、実施例10の主題を含む。実施例11では、本方法は、ブロックチェーンから、集合グループ識別子が既に使用中であるか否かを判定する段階と、使用中である場合に、新しい集合グループ識別子を生成する段階と、を含む。
実施例12は、実施例10または11のいずれかの主題を含む。実施例12では、本方法は、サブオブジェクトから参加要求を受け取る段階と、サブオブジェクトがグループメンバであることを確認する段階と、ブロックチェーンにおいてサブオブジェクトの名前をルックアップする段階と、ネームサーバからサブオブジェクトにグループ鍵を提供する段階と、を含む。
実施例13は、実施例10から12のいずれかの主題を含む。実施例13では、本方法は、グループメンバシップがプライベートであるか否かを判定する段階と、プライベートである場合に、ネームサーバへのプロキシとして動作するデバイスオーナーからサブオブジェクトにグループ鍵を提供する段階と、を含む。
実施例14は、実施例10から13のいずれかの主題を含む。実施例14では、方法は、組み合わせを形成するために、サブオブジェクトの名前を組み合わせる段階と、組み合わせのハッシュコードを計算する段階と、によって集合グループ識別子を作成する段階を含む。
実施例15は、実施例10から14のいずれかの主題を含む。実施例15では、本方法は、組み合わせを形成するために、サブオブジェクトを形成するすべてのサブサブオブジェクトの名前を組み合わせる段階と、組み合わせのハッシュコードを計算する段階と、によってサブオブジェクトの名前を作成する段階を含む。
実施例16は、実施例10から15のいずれかの主題を含む。実施例16では、本方法は、ブロックチェーントランザクションがメッシュネットワーク内のデバイスのグループで有効であることを確認する段階と、無効な場合に、ブロックチェーントランザクションを取り消す段階と、を含む。
実施例17は、非一時的機械可読媒体を含む。非一時的機械可読媒体は、グループのサブオブジェクトのリストを格納し、グループの集合グループアイデンティティを計算し、グループ内のサブオブジェクトにグループアイデンティティクレデンシャルを提供する、ようにプロセッサに指示するための命令を含む。
実施例18は、実施例17の主題を含む。実施例18では、非一時的機械可読媒体は、サブオブジェクトのためのプロキシサーバとして動作するようにプロセッサに指示するための命令を含む。
実施例19は、実施例17または18のいずれかの主題を含む。実施例19では、非一時的機械可読媒体が、集合グループアイデンティティを含むトランザクションをブロックチェーンにコミットし、ブロックチェーンをメッシュ内の他のデバイスに移行する、ようにプロセッサに指示するための命令を含む。
実施例20は、実施例17から19のいずれかの主題を含み、トランザクションブロックを含むブロックチェーンを20に含む。実施例20では、トランザクションブロックは、集合グループアイデンティティを含む。
実施例21は、コンポジットオブジェクトを含む装置を含む。本装置は、コンポジットオブジェクトの型名を作成するための型ネームサーバを含むデバイスオーナーと、コンポジットオブジェクトを形成するサブオブジェクトの型を含むトランザクションを含むブロックチェーンと、を含む。
実施例22は、実施例21の主題を含む。実施例22では、本装置は、コンポジットオブジェクトを含むサブオブジェクトの型を判定するための型検査部を含む。
実施例23は、実施例21および22のいずれかの主題を含む。実施例23では、型検査部は、型イントロスペクションシステムを含む。
実施例24は、実施例21から23のいずれかの主題を含む。実施例24では、型検査部は、型アテステーションシステムを含む。
実施例25は、実施例21から24のいずれかの主題を含む。実施例25では、本装置は、サブオブジェクトを形成するサブサブオブジェクトの型の型グラフを生成するための型グラフ生成部を含む。
実施例26は、実施例21から25のいずれかの主題を含む。実施例26では、本装置は、型グラフから型名を生成するための型名計算部を含む。
実施例27は、実施例21から26のいずれかの主題を含む。実施例27では、トランザクションは、型グラフを含む。
実施例28は、実施例21から27のいずれかの主題を含む。実施例28では、オブジェクトは、型クレデンシャルを含む。
実施例29は、実施例21から28のいずれかの主題を含む。実施例29では、型クレデンシャルは、製造業者の鍵を含む。
実施例30は、実施例21から29のいずれかの主題を含む。実施例30では、型クレデンシャルは、ネームサーバによって提供される。
実施例31は、実施例21から30のいずれかの主題を含む。実施例31では、サブオブジェクトは、サブサブオブジェクトを含み、サブオブジェクトの型名は、サブサブオブジェクトの型から判定される。
実施例32は、実施例21から31のいずれかの主題を含む。実施例32では、本装置は、サブサブオブジェクトの型を含むサブオブジェクトによって生成された型グラフを含む。
実施例33は、IoTネットワークにおいてオブジェクト型を作成するための方法を含む。IoTネットワークにおいてオブジェクト型を作成するための方法は、ネームサーバによる型グループの作成を要求する段階と、コンポジットオブジェクトを形成するオブジェクトの型グラフを構築するために、コンポジットオブジェクトを構成するサブオブジェクトの型検査を実行する段階と、型グラフから型グループ名を計算する段階と、型グループ名が既に作成されているか否かを判定するために、ブロックチェーンにアクセスする段階と、を含む。
実施例34は、実施例33の主題を含む。実施例34では、本方法は、型グラフを含むトランザクションをブロックチェーンに書き込むことによって型グループ名を作成する段階を含む。
実施例35は、実施例33または34のいずれかの主題を含む。実施例35では、本方法は、ネームサーバからコンポジットオブジェクトにEPID参加要求を発行する段階を含む。
実施例36は、実施例33から35のいずれかの主題を含む。実施例36では、本方法は、コンポジットオブジェクトを形成するサブオブジェクトに型クレデンシャルを発行する段階を含む。
実施例37は、実施例33から36のいずれかの主題を含む。実施例37では、ネームサーバは、コンポジットオブジェクトに型検査の実行を要求する。
実施例38は、実施例33から37のいずれかの主題を含む。実施例38では、型検査は、コンポジットオブジェクトを形成するサブオブジェクトの再帰的イントロスペクションを含む。
実施例39は、実施例33から38のいずれかの主題を含む。実施例39では、再帰的イントロスペクションは、コンポジットオブジェクトを形成するサブオブジェクトのそれぞれに型イントロスペクション要求を送信することと、サブオブジェクトを形成する各サブサブオブジェクトの型を判定するために型イントロスペクションを実行することと、サブサブオブジェクトから形成された各サブオブジェクトにおいて型グラフを構築することと、型グラフをコンポジットオブジェクトに返すことと、型グラフ上のシグネチャを検証することと、を含む。
実施例40は、実施例33から39のいずれかの主題を含む。実施例40では、本方法は、各サブサブオブジェクトから階層内の下位レベルのオブジェクトへの再帰的型イントロスペクションを実行する段階と、階層の各レベルでオブジェクトに関する型グラフを構築する段階と、階層の型グラフを次の上位レベルに返す段階と、を含む。
実施例41は、実施例33から40のいずれかの主題を含む。実施例41では、型検査は、コンポジットオブジェクトを形成するサブオブジェクトの再帰的アテステーションを実行することを含む。
実施例42は、実施例33から41のいずれかの主題を含む。実施例42では、再帰的アテステーションは、各レベルから次の下位レベルのオブジェクトに型アテステーションを送信することと、階層の特定のレベルのオブジェクトを構成するすべてのオブジェクトの型グラフを次の上位レベルに返すことと、コンポジットオブジェクト内の全体型グラフを構築することを含む。
実施例43は、非一時的機械可読媒体を含む。非一時的機械可読媒体は、コンポジットオブジェクトを形成するオブジェクトの型グラフを構築し、そのコンポジットオブジェクトの型名を計算し、その型名および型グラフをブロックチェーンに記録するようにプロセッサに指示する命令を含む。
実施例44は、実施例43の主題を含む。実施例44では、非一時的機械可読媒体は、コンポジットオブジェクトを形成するオブジェクトの再帰的型イントロスペクションを実行するようにプロセッサに指示する命令を含む。
実施例45は、実施例43または44のいずれかの主題を含む。実施例45では、非一時的機械可読媒体は、コンポジットオブジェクトを形成するオブジェクトの再帰的型アテステーションを実行するようにプロセッサに指示する命令を含む。
実施例46は、実施例43から45のいずれかの主題を含む。実施例46では、非一時的機械可読媒体は、ブロックチェーン内に存在しない場合、型名を作成するようにプロセッサに指示する命令を含む。
実施例47は、実施例43から46のいずれかの主題を含む。実施例47では、非一時的機械可読媒体は、型クレデンシャルと共にEPID参加要求をサブオブジェクトに送信することを含む。
実施例48は、装置を含む。本装置は、提携グループを形成するオブジェクトに名前を提供するための提携グループネームサーバと、提携グループに属するオブジェクトの連盟グループメンバリストと、提携グループを形成するオブジェクトの名前を記録するブロックチェーンと、を含む、提携グループを含む。
実施例49は、実施例48の主題を含む。実施例49では、本装置は、提携グループの存在をブロードキャストするためのパブリッシャを含む。
実施例50は、実施例48または49のいずれかの主題を含む。実施例50では、本装置は、オブジェクトから受信されたアイデンティティクレデンシャルを確認するためのクレデンシャル検証部を含む。
実施例51は、実施例48から50のいずれかの主題を含む。実施例51において、本装置は、提携グループに参加するためにオブジェクトにクレデンシャルを提供するためのEPIDサーバを含む。
実施例52は、実施例48から51のいずれかの主題を含む。実施例52では、本装置は、オブジェクトからのアイデンティティクレデンシャルを検証し、そのオブジェクトに提携グループクレデンシャルを提供するためのデバイスオーナーと、提携グループのメンバシップを示す提携グループクレデンシャルをそれぞれ有する複数のオブジェクトと、を含む。
実施例53は、実施例48から52のいずれかの主題を含む。実施例53では、提携グループ内のオブジェクトは位置ごとにグループ化されている。
実施例54は、実施例48から53のいずれかの主題を含む。実施例54では、提携グループ内のオブジェクトは機能ごとにグループ化されている。
実施例55は、IoTネットワークにおいて提携グループを形成するための方法を含む。IoTネットワークにおいて提携グループを形成する方法は、提携グループを定義する段階と、オブジェクトから提携グループに参加する要求を受信する段階と、提携グループクレデンシャルをオブジェクトに発行する段階と、を含む。
実施例56は、実施例55の主題を含む。実施例56では、提携グループを定義することは、位置によってデバイスをグループ化することを含む。
実施例57は、実施例55または56のいずれかの主題を含む。実施例57では、提携グループを定義することは、機能によってデバイスをグループ化することを含む。
実施例58は、実施例55から57のいずれかの主題を含む。実施例58では、本方法は、提携グループが発見不可能である場合に、その提携グループをブロックチェーンにパブリッシュする段階を含む。
実施例59は、実施例55から58のいずれかの主題を含む。実施例59では、本方法は、提携グループクレデンシャルを発行する前に要求を検証する段階を含む。
実施例60は、実施例59から59のいずれかの主題を含む。実施例60では、本方法は、要求が有効なアイデンティティクレデンシャルを含むことを確認することによって要求を検証する段階を含む。
実施例61は、実施例59から60のいずれかの主題を含む。実施例61では、本方法は、要求が有効なインスタンスクレデンシャルを含むことを確認することによって要求を検証することを含む。
実施例62は、実施例59から61のいずれかの主題を含む。実施例62では、方法は、要求が有効な型クレデンシャルを含むことを確認することによって要求を検証することを含む。
実施例63は、非一時的機械可読媒体を含む。非一時的機械可読媒体は、提携グループを定義し、提携グループをブロックチェーンにパブリッシュし、オブジェクトからの参加要求を受け入れるようにプロセッサに指示する命令を含む。
実施例64は、実施例63の主題を含む。実施例64では、非一時的機械可読媒体は、提携グループが発見可能であることを確認するようにプロセッサに指示する命令を含む。
実施例65は、実施例63または64のいずれかの主題を含む。実施例65では、非一時的機械可読媒体は、オブジェクトからの参加要求が有効であるか否かを確認するようにプロセッサに指示する命令を含む。
実施例66は、実施例63から65のいずれかの主題を含む。実施例66では、非一時的機械可読媒体は、有効な参加要求に応答してクレデンシャルを発行するようにプロセッサに指示する命令を含む。
実施例67は、実施例63から66のいずれかの主題を含む。実施例67では、非一時的機械可読媒体は、EPIDクレデンシャルを生成するようにプロセッサに指示する命令を含む。
実施例68は、装置を含む。本装置は、トラステッドグループの作成を開始するためのグループ作成部を含む一次参加者と、グループメンバのためのアイデンティティおよびクレデンシャルを格納するための分散型台帳と、を含む、トラステッド通信環境を含む。本装置はまた、一次参加者によって提供されたトラステッドグループのための通信クレデンシャルを含む二次参加者を含む。
実施例69は、実施例68の主題を含む。実施例69では、通信クレデンシャルは、トラステッドグループのための秘密鍵、および分散型台帳から取得されたトランザクション鍵を含む。
実施例70は、実施例68または69のいずれかの主題を含む。実施例70では、一次参加者は、分散型台帳エニュメレーション局(DLEA)に対する参加要求を含み、参加要求は、一次参加者に対する秘密鍵で署名されたトラステッドグループ名を含む。
実施例71は、実施例68から70のいずれかの主題を含む。実施例71では、装置は、トラステッドグループ名が作成されたか否かを判定するための分散型台帳エニュメレーション局(DLEA)アクセス部を含む。
実施例72は、実施例68から71のいずれかの主題を含み、その分散型台帳を実施例72に含む。実施例72では、分散型台帳は、トラステッドグループ用の公開鍵と許可ポリシーとを含む。
実施例73は、実施例68から72のいずれかの主題を含む。実施例73では、主参加者は、トラステッドグループ名に少なくとも部分的に基づいて鍵を作成するための鍵作成部を含む。
実施例74は、実施例68から73のいずれかの主題を含む。実施例74では、装置は、二次参加者からの参加要求を確認するためのアテステーション確認部を含む。
実施例75は、実施例68から74のいずれかの主題を含む。実施例75では、装置は、通信クレデンシャルを二次参加者に発行するためのグループ参加者を含む。
実施例76は、実施例68から75のいずれかの主題を含む。実施例76では、装置は、二次参加者によって提供されたトラステッドグループについての二次通信クレデンシャルを含む三次参加者を含む。
実施例77は、実施例68から76のいずれかの主題を含む。実施例77では、二次通信クレデンシャルは、グループのための秘密鍵および二次トランザクション鍵を含む。
実施例78は、実施例68から77のいずれかの主題を含む。実施例78では、装置は、一次参加者によって発行された通信クレデンシャルを含む複数の二次参加者を含む。
実施例79は、実施例68から78のいずれかの主題を含む。実施例79では、装置は、一次参加者によって発行された二次通信クレデンシャルをそれぞれ含む、複数の三次参加者を含む。
実施例80は、実施例68から79のいずれかの主題を含む。実施例80では、分散型台帳は、参加者のためのグループ鍵および秘密鍵によって署名されたトランザクションデータを含む。
実施例81は、IoTネットワークにおける通信トランザクションをセキュアにするための方法を含む。IoTネットワークにおける通信トランザクションを保護するための方法は、参加者のグループが完全性保証で通信できることを第1の参加者によって判定する段階と、分散型台帳エニュメレーション局(DLEA)からグループの名前を予約する段階と、名前を使用してグループの分散型台帳を確立する段階と、グループの秘密鍵を2番目の参加者に提供する段階と、を含む。
実施例82は、実施例81の主題を含む。実施例82では、名前を予約する段階は、第1の参加者のための秘密鍵を使用して署名されたメッセージで、第1の参加者のための名前および公開鍵をDLEAに送信する段階と、DLEAが名前をパブリック分散型台帳にコミットしたときにグループが作成されたことを判定する段階と、エンハンストプライバシーID(EPID)システムを使用したグループ公開鍵の確立する段階と、を含む。
実施例83は、実施例81または82のいずれかの主題を含む。実施例83では、グループの分散型台帳を確立する段階は、第1の参加者からグループの分散型台帳へトランザクションをコミットする段階を含み、トランザクションは、第1の参加者のトランザクション鍵で署名されたグループ公開鍵および許可ポリシーを含む。
実施例84は、実施例81から83のいずれかの主題を含む。実施例84では、秘密鍵を提供する段階は、第2の参加者からグループに参加する許可を要求する参加要求を受信する段階と、第2の参加者の信頼性を確認する段階と、を含む。
実施例85は、実施例81から84のいずれかの主題を含む。実施例85では、信頼性を確認する段階は、参加要求に署名するために使用された製造業者の鍵を検証する段階を含む。
実施例86は、実施例81から85のいずれかの主題を含む。実施例86では、本方法は、第2の参加者におけるグループの第2の秘密鍵を生成する段階であって、第2の秘密鍵は、グループ公開鍵の下にある、段階と、第1の参加者にメッセージを送信する段階であって、メッセージは、第2の秘密鍵によって署名された、第2の参加者の公開鍵である、段階と、グループ分散型台帳にトランザクションをコミットする段階であって、トランザクションは、秘密鍵によって署名された第2の参加者の公開鍵を含む、段階と、を含む。
実施例87は、実施例81から86のいずれかの主題を含む。実施例87では、本方法は、第3の参加者における参加要求を作成する段階であって、参加要求は、第3の参加者のための秘密鍵によって署名された第3の参加者トランザクション鍵を含む、段階と、参加要求を第2の参加者に送信する段階と、第2の参加者によって、第3の参加者のための公開鍵、第2の参加者のためのトランザクション鍵、および署名付きトランザクションを作成するためのグループ鍵で参加要求に署名する段階と、署名付きトランザクションを第3の参加者に送り返す段階と、を含む。
実施例88は、実施例81から87のいずれかの主題を含む。実施例88では、本方法は、署名されたトランザクションに第2の参加者からのトランザクションデータを含めることを含む。
実施例89は、実施例81から88のいずれかの主題を含む。実施例89では、本方法は、第3の参加者のための秘密グループ鍵を用いて署名付きトランザクションに署名する段階と、署名付きトランザクションをグループ分散型台帳にコミットする段階と、を含む。
実施例90は、実施例81から89のいずれかの主題を含む。実施例90では、本方法は、第2の参加者のための秘密グループ鍵を使用して第2の参加者でトランザクションデータに署名する段階と、トランザクションデータをグループ分散型台帳にコミットする段階と、を含む。
実施例91は、非一時的機械可読媒体を含む。非一時的機械可読媒体は、グループに完全性保証があることを判定し、分散型台帳エニュメレーション局(DLEA)を用いてグループ名を予約し、グループ公開鍵および許可ポリシーを作成し、グループ名およびグループ公開鍵をグループ分散型台帳にコミットするようにプロセッサに指示する命令を含む。
実施例92は、実施例91の主題を含む。実施例92では、非一時的機械可読媒体は、第2の参加者からの参加要求を確認し、参加メッセージを第2の参加者に送信するようにプロセッサに指示する命令を含み、参加要求はグループ秘密鍵を含む。
実施例93は、実施例91または92のいずれかの主題を含む。実施例93では、非一時的機械可読媒体は、グループ秘密鍵でトランザクションデータに署名し、署名付きトランザクションデータをグループ分散型台帳にコミットするようにプロセッサに指示する命令を含む。
実施例94は、装置を含む。装置は、IoTネットワークを含み、IoTネットワークは、トラステッド実行環境(TEE)を含む。これはまた、ブロックチェーンのチェーン履歴も含み、チェーン履歴は、ハッシュシグネチャのホワイトリスト、チェーン履歴をローカルコンピューティングのルートオブトラストに提供するための連鎖のためのルートオブトラスト(RTC)、およびIoTネットワーク内の制約のあるデバイスにアーカイブ機能を提供するためのアーカイブのためのルートオブトラスト(RTA)を含む。
実施例95は、実施例94の主題を含む。実施例95では、TEEは、システム内の最初のロード可能オブジェクトを検証するためのルートオブトラスト測定部(RTM)を含む。
実施例96は、実施例94または95のいずれかの主題を含む。実施例96では、TEEは、ストレージに対するルートオブトラストの値をアテステーションするための報告用のルートオブトラスト(RTR)、およびストレージのためのルートオブトラストデバイスに対する値を格納するためのルートオブトラスト(RTS)を含む。
実施例97は、実施例94から96のいずれかの主題を含む。実施例97では、TEEは、チェーン履歴を他のデバイスに移行し、他のデバイスからのチェーン履歴を検証するためのブロックチェーンロジックを含む。
実施例98は、実施例94から97のいずれかの主題を含む。実施例98では、TEEは、現在の構成、過去の構成、または予想される構成、あるいはそれらの任意の組み合わせを含むホワイトリスト履歴を含む。
実施例99は、実施例94から98のいずれかの主題を含む。実施例99では、TEEは、ブートプロセス中に行われた測定を記録するために測定履歴を含めることを含む。
実施例100は、実施例94から99のいずれかの主題を含む。実施例100では、測定履歴は、複数のブートシーケンスからの測定ログを含む。
実施例101は、実施例94から100のいずれかの主題を含む。実施例101では、本装置は、トラステッド環境でブートするデバイスのメッシュネットワークを含む。
実施例102は、実施例94から101のいずれかの主題を含む。実施例102では、チェーン履歴は、それぞれアテステーション鍵によって署名されているプラットフォーム制御レジスタ(PCR)からの複数の値を含むブロックチェーンブロックを含む。
実施例103は、実施例94から102のいずれかの主題を含む。実施例103では、ブロックチェーンブロックはブロック署名鍵を含む。
実施例104は、実施例94から103のいずれかの主題を含む。実施例104では、装置は、ホワイトリスト値を記憶するイメージリポジトリを含む。
実施例105は、実施例94から104のいずれかの主題を含む。実施例105では、チェーン履歴は、製造業者アテステーション鍵によってそれぞれ署名された複数のホワイトリストイメージのマニフェストを含むブロックチェーンブロックを含む。
実施例106は、実施例94から105のいずれかの主題を含む。実施例106では、ブロックチェーンブロックはブロック署名鍵を含む。
実施例107は、IoTネットワーク内のデバイスをセキュアにブートするための方法を含む。IoTネットワーク内のデバイスをセキュアにブートするための方法は、コードオブジェクトを実行する前にコードオブジェクトを測定する段階と、ブロックチェーンから取得された既知の良好なイメージと測定を比較する段階と、測定が既知の良好なイメージと一致する場合、コードオブジェクトを実行する段階と、を含む。
実施例108は、実施例107の主題を含む。実施例108では、本方法は、測定値をブロックチェーンから取得された既知の不良イメージと比較する段階と、測定値が既知の不良イメージと一致する場合にデバイスを隔離する段階と、測定値と既知の不良イメージとが一致する場合にコードを修正する段階と、を含む。
実施例109は、実施例107または108のいずれかの主題を含む。実施例109では、本方法は、測定値が既知の良好なイメージまたは既知の不良イメージと一致しない場合、事前定義されたポリシーに従う段階を含む。
実施例110は、実施例107から109のいずれかの主題を含む。実施例110では、事前定義されたポリシーは、信頼されていない状態でブートし、信頼されているデバイスと通信しないようにデバイスに指示する。
実施例111は、実施例107から110のいずれかの主題を含む。実施例111では、本方法は、クラウドリポジトリから測定用のイメージを取得する段階と、イメージのシグネチャが有効であることを確認する段階と、イメージがブートチェーンのハッシュであることを確認する段階と、イメージのマニフェストに署名する段階と、ホワイトリストにイメージを追加する段階と、ホワイトリストをブロックチェーンにコミットする段階と、を含む。
実施例112は、実施例107から111のいずれかの主題を含む。実施例112では、本方法は、イメージがブートチェーンのイメージではないと判定する段階と、イメージが攻撃イメージであることを判定する段階と、攻撃イメージをブラックリストに追加する段階と、ブラックリストをブロックチェーンにコミットする段階と、を含む。
実施例113は、実施例107から112のいずれかの主題を含む。実施例113では、本方法は、イメージがブートチェーンのイメージではないと判定する段階と、イメージが未知のイメージであることを判定する段階と、未知のイメージを未分類リストに追加する段階と、未分類リストをブロックチェーンにコミットする段階と、を含む。
実施例114は、実施例107から113のいずれかの主題を含む。実施例114では、本方法は、正常に実行されたコードブロックのイメージを含むブロックを作成する段階と、ブロックをブロックチェーンにコミットする段階と、を含む。
実施例115は、実施例107から114のいずれかの主題を含む。実施例115では、本方法は、拒否されたコードブロックのイメージを含むブロックを作成する段階と、ブロックをブロックチェーンにコミットする段階と、を含む。
実施例116は、非一時的機械可読媒体を含む。非一時的機械可読媒体は、測定値を取得するためにオブジェクトを実行する前にコードオブジェクトを測定し、その測定値をブロックチェーンから取得された既知の良好なイメージと比較し、測定値と既知の良好なイメージとの間に一致がある場合にコードオブジェクトを良好として分類するようにプロセッサに指示する命令を含む。
実施例117は、実施例116の主題を含む。実施例117では、非一時的機械可読媒体は、測定値を既知の不良イメージと比較し、測定値が既知の不良イメージと一致する場合にコードオブジェクトが実行されることを防ぐようにプロセッサに指示する命令を含む。
実施例118は、実施例116または117のいずれかの主題を含む。実施例118では、非一時的機械可読媒体は、チェーン履歴を含むブロックチェーンを維持し、ブロックチェーン内のルートオブトラストの測定値を維持するようにプロセッサに指示する命令を含む。
実施例119は、装置を含む。装置はIoTデバイスを含み、IoTデバイスは、トラフィックがIoTデバイスを通って流れることを可能にするためのアクセス権を提供するために使用されるネットワーク層と、ネットワークスタックにある通行権層であって、通行権層は、IoTデバイスを通してアプリケーション層の下でパケットを経路指定する、通行権層と、を制御するための通行権システムを含む。
実施例120は、実施例119の主題を含む。実施例120では、アクセス権は、アイデンティティ、認可、支払い、または時間に少なくとも部分的に基づく。
実施例121は、実施例119または120のいずれかの主題を含む。実施例121では、装置は、2つのドメインにわたって結合するデバイスのメッシュネットワークを含み、2つのドメインのそれぞれは、異なる通信プロトコルを使用する。
実施例122は、実施例119から121のいずれかの主題を含む。実施例122において、IoTデバイスは、2つのドメイン間にエッジデバイスを含む。
実施例123は、実施例119から122のいずれかの主題を含む。実施例123では、通行権システムは、第1のドメインによって使用されるプロトコルから第2のドメインによって使用されるプロトコルにパケットを変換する。
実施例124は、実施例119から123のいずれかの主題を含む。実施例124では、IoTデバイスは、アプリケーションとインターフェースをとり、通信のためにネットワークスタックを管理するためのアプリケーション/サービスマネージャを含む。
実施例125は、実施例119から124のいずれかの主題を含む。実施例125では、他のメッシュデバイスにパケットを通信するためのオペレーティングシステムおよびプログラミングインターフェースなどのアプリケーション動作環境を提供するためのアプリケーション/サービスマネージャである。
実施例126は、実施例119から125のいずれかの主題を含む。実施例126では、IoTデバイスは、通信のためのマイクロペイメントを処理するための支払い/クレジットマネージャを含む。
実施例127は、実施例119から126のいずれかの主題を含む。実施例127では、IoTデバイスは、通信を計時するためのタイミングサブシステムを含む。
実施例128は、実施例119から127のいずれかの主題を含む。実施例128では、IoTデバイスは、通信許可、支払い、もしくはクレジット、またはそれらの任意の組み合わせのブロックチェーンにアクセスし維持するためのブロックチェーンロジックを含む。
実施例129は、実施例119から128のいずれかの主題を含む。実施例129では、IoTデバイスは、ブロックチェーンを他のデバイスに移行し、別のデバイスから転送されたブロックチェーンを検証するためのブロックチェーンロジックを含む。
実施例130は、IoTネットワークにおける通信のために通行権システムを使用するための方法を含む。IoTネットワークにおける通信のために通行権システムを使用するための方法は、通行権層を介して第1のデバイスから第2のデバイスへパケットを転送する段階を含み、通行権層は、ネットワークスタックにおいてアプリケーション層の下にある。
実施例131は、実施例130から131のいずれかの主題を含む。実施例131では、本方法は、デバイスレジストラに経路指定要求を送信する段階と、デバイスレジストラから許可を受信する段階と、通行権層を通してパケットを経路指定する段階と、を含む。
実施例132は、実施例130の主題を含む。実施例132では、本方法は、経路指定完了通知をデバイスレジストラに送信する段階を含む。
実施例133は、実施例130または132のいずれかの主題を含む。実施例133では、本方法は、デバイスレジストラからの支払いを受け入れる段階を含む。
実施例134は、実施例130から133のいずれかの主題を含む。実施例134では、本方法は、経路指定要求をデバイスレジストラに送信する段階と、デバイスレジストラから拒否決定を受信する段階と、パケットを削除する段階と、を含む。
実施例135は、実施例130から134のいずれかの主題を含む。実施例135では、本方法は、要求が認可されているか否かを判定するために要求者をルックアップする段階と、データ転送に十分なクレジットが存在するか否かを判定するために記録をチェックする段階と、パケットの転送を認可するためにメッセージを送信する段階と、を含む。
実施例136は、実施例130から135のいずれかの主題を含む。実施例136では、本方法は、要求が認可されているか否かを判定するために要求者をルックアップする段階と、リース時間を計算するために記録をチェックする段階と、通信のための期限付きリースを付与するためにメッセージを送信する段階と、を含む。
実施例137は、実施例130から136のいずれかの主題を含む。実施例137では、本方法は、パケットの転送に対するエスクロー支払いを解除する段階と、を含む。
実施例138は、実施例130から137のいずれかの主題を含む。実施例138では、本方法は、通信のための期限付きリースを無効にする段階と、有効期限をデバイスに通知するためにメッセージを送信する段階と、を含む。
実施例139は、非一時的機械可読媒体を含む。非一時的機械可読媒体は、実行されたときに、パケットの認可に少なくとも部分的に基づいて、モノのインターネット(IoT)デバイス内の通行権層を通してパケットを経路指定するようにプロセッサに指示する命令を含む。
実施例140は、実施例139の主題を含む。実施例140では、非一時的機械可読媒体は、実行されると、パケットを経路指定するための認可を得るために経路指定要求をデバイスレジストラに送信するようにプロセッサに指示する命令を含む。
実施例141は、実施例139または140のいずれかの主題を含む。実施例141では、非一時的機械可読媒体は、実行されると、パケットを含む通信が終了した後に完了通知をデバイスレジストラに送信するようにプロセッサに指示する命令を含む。
実施例142は、実施例139から141のいずれかの主題を含む。実施例142では、非一時的機械可読媒体は、実行されると、デバイスレジストラからパケットを転送するための支払いを受け入れるようにプロセッサに指示する命令を含む。
実施例143は、実施例139から142のいずれかの主題を含む。実施例143では、非一時的機械可読媒体は、実行されると、認可を判定するために要求者をルックアップするようにプロセッサに指示する命令を含む。
実施例144は、実施例139から143のいずれかの主題を含む。実施例144では、非一時的機械可読媒体は、実行されると、パケットの転送に対して支払うのに十分なクレジットが存在するか否かを判定するようにプロセッサに指示する命令を含む。
実施例145は、実施例139から144のいずれかの主題を含む。実施例145では、非一時的機械可読媒体は、実行されると、パケットを含む通信のリース時間を計算するようにプロセッサに指示する命令を含む。
実施例146は、実施例139から145のいずれかの主題を含む。実施例146では、非一時的機械可読媒体は、実行されると、認可、リース時間、またはその両方をIoTデバイスに通信するようにプロセッサに指示する命令を含む。
実施例147は、実施例139から146のいずれかの主題を含む。実施例147では、非一時的機械可読媒体は、実行されると、リースを終了させ、IoTデバイスに終了を通知するようにプロセッサに指示する命令を含む。
実施例148は、装置を含む。本装置は、モノのインターネット(IoT)ネットワークを含み、IoTネットワークは、パケットがIoTデバイスによって送信されたことを識別するPoP鍵を計算するためのプルーフオブプロヴェナンス(PoP)鍵計算部と、パケットにPoP鍵を付加するためのパケット構築部と、パケットを別のデバイスに送信するための通信部と、を含むIoTデバイスを含む。
実施例149は、実施例148の主題を含む。実施例149では、IoTデバイスは、イングレス鍵を判定するイングレス鍵計算部を含む。
実施例150は、実施例148または149のいずれかの主題を含む。実施例150では、イングレス鍵計算部は、パケット内の前のPoP鍵を識別し、イングレス鍵を前のPoP鍵に設定するためのパケットリーダを含む。
実施例151は、実施例148から150のいずれかの主題を含む。実施例151では、イングレス鍵計算部は、イングレス鍵を計算するための乱数発生器を含む。
実施例152は、実施例148から151のいずれかの主題を含む。実施例152では、IoTデバイスはデバイス鍵を含む。
実施例153は、実施例148から152のいずれかの主題を含む。実施例153では、デバイス鍵は、デバイスにプログラムされている製造業者の鍵である。
実施例154は、実施例148から153のいずれかの主題を含む。例154では、デバイス鍵はブロックチェーンから取得される。
実施例155は、実施例148から154のいずれかの主題を含む。実施例155では、PoP鍵計算部は、PoP鍵を形成するためにイングレス鍵とデバイス鍵を組み合わせる機能を含む。
実施例156は、実施例148から155のいずれかの主題を含む。実施例156では、IoTデバイスは、パケット内のPoP鍵シーケンスが認可されていることを確認するためのPoPシーケンス検証部を含む。
実施例157は、実施例148から156のいずれかの主題を含む。実施例157では、本装置は、複数のデバイスを含み、デバイスのそれぞれが、受信したパケットのPoP鍵を計算するPoP鍵計算機と、パケットにPoP鍵を付加するパケット構築部と、パケットを別のデバイスに送信する通信部と、を含む。
実施例158は、実施例157の主題を含む。実施例158では、通信部は、パケットを新しいプロトコルに変換するためのプロトコル変換部を含む。
実施例159は、実施例157および158のいずれかの主題を含み、パケットを159に含む。実施例159では、パケットは、PoP鍵のための複数のプレースホルダを含む。
実施例160は、パケットに対するプルーフオブプロヴェナンス(PoP)を用いてデバイス間でパケットを転送するための方法を含む。パケットに対するプルーフオブプロヴェナンス(PoP)を用いてデバイス間でパケットを転送するための方法は、デバイスからパケットを受信する段階と、パケットからイングレス鍵を判定する段階と、パケットのPoP鍵を計算する段階と、PoP鍵をパケットに付加する段階と、パケットを別のデバイスに送信する段階と、を含む。
実施例161は、実施例160の主題を含む。実施例161では、本方法は、ブロックチェーンからデバイス鍵を取得する段階を含む。
実施例162は、実施例160または161のいずれかの主題を含む。実施例162では、本方法は、PoPをイングレス鍵およびデバイス鍵の関数として計算する段階を含む。
実施例163は、実施例160から162のいずれかの主題を含む。実施例163では、本方法は、パケットからPoP鍵を抽出する段階と、鍵をトークン化する段階と、PoPトークンを検証する段階と、検証の結果を報告する段階と、を含む。
実施例164は、実施例160から163のいずれかの主題を含む。実施例164では、結果を検証する段階は、送信デバイスのアイデンティティを確認するためにPoPトークンを共通の秘密鍵と組み合わせる機能を実行する段階を含む。
実施例165は、実施例160から164のいずれかの主題を含む。実施例165では、結果を報告する段階は、他のデバイスに故障を知らせる段階を含む。
実施例166は、非一時的機械可読媒体を含む。非一時的機械可読媒体は、実行されると、イングレス鍵を識別するために受信パケットを読み取り、イングレス鍵に少なくとも部分的に基づいて、プルーフオブプロヴェナンス(PoP)鍵を計算し、パケットにPoP鍵を付加し、パケットを受信デバイスに送信するようにプロセッサに指示する命令を含む。
実施例167は、実施例166の主題を含む。実施例167では、非一時的機械可読媒体は、実行されると、ブロックチェーンからデバイス鍵を取得するようにプロセッサに指示する命令を含む。
実施例168は、実施例166または167のいずれかの主題を含む。実施例168では、非一時的機械可読媒体は、実行されると、デバイス鍵を生成するようにプロセッサに指示する命令を含む。
実施例169は、実施例166から168のいずれかの主題を含む。実施例169では、非一時的機械可読媒体は、実行されると、PoP鍵を計算するために、イングレス鍵およびデバイス鍵に対して機能を実行するようにプロセッサに指示する命令を含む。
実施例170は、実施例166から169のいずれかの主題を含む。実施例170では、非一時的機械可読媒体は、実行されると、パケット内のPoP鍵のシーケンスを検証するようにプロセッサに指示する命令を含む。
実施例171は、実施例166から170のいずれかの主題を含む。実施例171では、非一時的機械可読媒体は、実行されると、検証の結果を別のデバイスに報告するようにプロセッサに指示する命令を含む。
実施例172は、装置を含む。装置は、モノのインターネット(IoT)ネットワークを含み、IoTネットワークは、IoTデバイスを含む。IoTデバイスは、通信を受け入れて通信を送信するための通信部と、トークンバケットを識別するために通信内のメタデータを解析するためのデータ解析部と、通信を送信するために必要な支払いを計算するための支払い計算部と、トークンバケットからの支払いを差し引き、メタデータを更新するための支払い抽出部と、更新されたメタデータで通信を再構築するためのフレーム構築部と、を含む。
実施例173は、実施例172の主題を含む。実施例173では、通信部は、プロトコル間の通信を変換する、またはその通信にプルーフオブプロヴェナンスの追加を実行する、またはその両方である。
実施例174は、実施例172または173のいずれかの主題を含む。実施例174では、装置は通行権システムを含む。
実施例175は、実施例172から174のいずれかの主題を含む。実施例175では、データ解析部は、トークンバケットを復号する。
実施例176は、実施例172から175のいずれかの主題を含む。実施例176では、支払い計算部は、ペイロードサイズにペイロードを送信するための1バイト当たりのコストを掛けたものに少なくとも部分的に基づいて支払いを計算する。
実施例177は、実施例172から176のいずれかの主題を含む。実施例177では、支払い計算部は、通信の優先度レベルに少なくとも部分的に基づいて支払いを計算する。
実施例178は、実施例172から177のいずれかの主題を含む。実施例178では、支払い抽出部は、トークンバケットに記録された残高から支払いを差し引く。
実施例179は、実施例172から178のいずれかの主題を含む。実施例179では、支払い抽出部は、トークンバケットからトークンを取り除く。
実施例180は、実施例172から179のいずれかの主題を含む。実施例180では、フレーム構築部は、トークンバケットを暗号化し、パケットペイロードおよびメタデータをアセンブルして、通信の少なくとも一部を含むフレームを形成する。
実施例181は、実施例172から180のいずれかの主題を含む。実施例181では、本装置は、トークンバケットで参照されたソースからの支払いを受け入れるための支払い受け入れ部を含む。
実施例182は、実施例172から181のいずれかの主題を含む。実施例182では、ソースは、トークンバケット内のビットシーケンスによって識別されたブロックチェーンを含む。
実施例183は、通信を送信するために経路指定デバイスに支払うためにトークンバケットを使用するための方法を含む。通信を送信するために経路指定デバイスに支払うためにトークンバケットを使用するための方法は、送信システムにおいてフレームを受信する段階と、トークンバケットを識別するためにパケットフレームメタデータを解析する段階と、通信を送信するために支払いを計算する段階と、トークンバケットから支払いを抽出し、新しいトークンバケットを提供する、段階と、新しいトークンバケットを使用してフレームメタデータを更新する段階と、経路指定デバイスからフレームを経路指定する段階と、を含む。
実施例184は、実施例183の主題を含む。実施例184では、本方法は、フレームメタデータが正しくないと判定された場合に送信者に警告する段階を含む。
実施例185は、実施例183または184のいずれかの主題を含む。実施例185では、支払いを計算する段階は、ペイロードサイズに経路指定された各バイトに対する料金を掛ける段階を含む。
実施例186は、実施例183から185のいずれかの主題を含む。実施例186では、支払いを計算する段階は、より高いレートで優先度による経路指定に課金する段階を含む。
実施例187は、実施例183から186のいずれかの主題を含む。実施例187では、トークンバケットから支払いを抽出する段階は、通信を送信するための量だけトークンフィールドをデクリメントさせる段階を含む。
実施例188は、実施例183から187のいずれかの主題を含む。実施例188では、本方法は、ローカル支払い小計をインクリメントさせる段階を含む。
実施例189は、実施例183から188のいずれかの主題を含む。実施例189では、本方法は、ローカル支払い小計を用いて支払いストアを更新する段階を含む。
実施例190は、実施例183から189のいずれかの主題を含む。実施例190では、支払いストアは、支払いトランザクションを含むブロックチェーンである。
実施例191は、非一時的機械可読媒体を含む。非一時的機械可読媒体は、実行されると、トークンバケットを識別するためのフレームのメタデータを解析し、メタデータからトークンバケットを抽出し、宛先にメッセージを送信するための支払いを計算し、トークンバケットから支払いを抽出し、トークンバケットの変更を含むようにフレームを更新し、宛先に向けてフレームを経路指定するようにプロセッサに指示する命令を含む。
実施例192は、実施例191の主題を含む。実施例192では、非一時的機械可読媒体は、実行されると、最終宛先を示すアドレスと共に後続のデバイスにフレームを送信するようにプロセッサに指示する命令を含む。
実施例193は、実施例191または192のいずれかの主題を含む。実施例193では、非一時的機械可読媒体は、実行されると、フレームのサイズと送信されるバイト当たりのコストとに少なくとも部分的に基づいて支払いを計算するようにプロセッサに指示する命令を含む。
実施例194は、実施例191から193のいずれかの主題を含む。実施例194では、非一時的機械可読媒体は、実行されると、メッセージ送信の優先度に少なくとも部分的に基づいて支払いを計算するようにプロセッサに指示する命令を含む。
実施例195は、実施例191から194のいずれかの主題を含む。実施例195では、非一時的機械可読媒体は、実行されると、トークンバケットに記録された残高を減らすようにプロセッサに指示する命令を含む。
実施例196は、実施例191から195のいずれかの主題を含む。実施例196では、非一時的機械可読媒体は、実行されると、トークンバケットからトークンを除去するようにプロセッサに指示する命令を含み、トークンは暗号化されたビットシーケンスを含む。
実施例197は、実施例191から196のいずれかの主題を含む。実施例197では、非一時的機械可読媒体は、実行されると、フレームを更新する前にトークンバケットを暗号化するようにプロセッサに指示する命令を含む。
実施例198は、実施例191から197のいずれかの主題を含む。実施例198では、非一時的機械可読媒体は、実行されると、トークンバケット内の残高を増やすために支払いを受け入れるようにプロセッサに指示する命令を含む。
実施例199は、装置を含む。装置は、モノのインターネット(IoT)ネットワークを含み、IoTネットワークは、IoTデバイスを含む。これは、エグレスフレームを含む通信を送信するための通信部と、利用可能なプロトコルを判定するためのプロトコルライブラリ構築部と、イングレスフレームを分析するためのフレーム分析部と、イングレスフレームからエグレスフレームを構築するためのフレーム構築部と、を含む。
実施例200は、実施例199の主題を含む。実施例200では、フレーム分析部は、イングレスフレームのフレーム長、エグレスフレームのプロトコル、またはその両方を判定する。
実施例201は、実施例199または200のいずれかの主題を含む。実施例201では、装置は通行権システムを含む。
実施例202は、実施例199から201のいずれかの主題を含む。実施例202では、本装置は、利用可能なプロトコルを格納するためのプロトコルライブラリを含む。
実施例203は、実施例199から202のいずれかの主題を含む。実施例203では、プロトコルライブラリは、ペイロードサイズ、フィールド長、フレームヘッダフォーマット、もしくはフレームフッタフォーマット、またはそれらの任意の組み合わせを含むプロトコル用のフォーマットデータを含む。
実施例204は、実施例199から203のいずれかの主題を含む。実施例204では、本装置は、第1のプロトコルのイングレスフレームと、第2のプロトコルのエグレスフレームであって、エグレスフレームは、イングレスフレームの少なくとも一部を含むペイロードフィールドを含む、エグレスフレームと、を含む。
実施例205は、実施例199から204のいずれかの主題を含む。実施例205では、本装置は、第1のプロトコルのイングレスフレームと、複数のエグレスフレームであって、それぞれが第2のプロトコルであり、複数のエグレスフレームのそれぞれは、イングレスフレームの少なくとも一部を含むペイロードフィールドを含む、エグレスフレームと、を含む。
実施例206は、第1のプロトコルのフレームを第2のプロトコルのペイロードフィールドにパックするための方法を含む。第1のプロトコルのフレームを第2のプロトコルのペイロードフィールドにパックするための方法は、イングレスフレームのプロトコルとエグレスフレームのプロトコルとを識別する段階と、イングレスフレームの少なくとも一部をエグレスフレームのペイロードフィールドに書き込む段階と、エグレスフレームを宛先に向けてディスパッチする段階と、を含む。
実施例207は、実施例206の主題を含む。実施例207では、本方法は、利用可能なイングレスおよびエグレスプロトコルのライブラリを作成する段階を含み、ライブラリは、各プロトコルのフレームのサイズ、各プロトコルのフレームのペイロードフィールドのサイズ、各プロトコルのアドレス、または任意の組み合わせを含む。
実施例208は、実施例206または207のいずれかの主題を含む。実施例208では、本方法は、エグレスフレーム内のペイロードフィールドのサイズを判定する段階と、イングレスフレームがペイロード内に収まるか否かを判定する段階と、を含む。
実施例209は、実施例206から208のいずれかの主題を含む。実施例209では、本方法は、エグレスフレームのペイロードフィールドに収まるには大きすぎるイングレスフレームを断片化する段階を含む。
実施例210は、実施例206から209のいずれかの主題を含む。実施例210では、本方法は、イングレスフレームを複数のバイトシーケンスに分割する段階を含み、各バイトシーケンスは、エグレスフレームのペイロードフィールドに収まる。
実施例211は、実施例206から210のいずれかの主題を含む。実施例211では、本法は、複数のバイトシーケンスのそれぞれを、別々のエグレスフレームのデータフィールドに書き込む段階と、複数のバイトシーケンスのそれぞれに対するシーケンス番号を別々のエグレスフレームのデータフィールドに書き込む段階と、を含む。
実施例212は、実施例209から211のいずれかの主題を含む。実施例212では、本方法は、イングレスフレームのすべての断片が処理されたか否かを判定する段階と、そうでない場合、エグレスフレームに断片を書き込み続ける段階と、を含む。
実施例213は、実施例206から212のいずれかの主題を含む。実施例213では、本方法は、新しいイングレスフレームが受信されたか否かを判定する段階と、新しいイングレスフレームを処理してそれをエグレスフレームにパッケージ化する、段階と、を含む。
実施例214は、非一時的機械可読媒体を含む。非一時的機械可読媒体は、実行されると、サイズおよび他の制約を判定するためにイングレスフレームを分析し、エグレスフレームのプロトコルを判定し、イングレスフレームの少なくとも一部をエグレスフレームのデータフィールドに書き込み、宛先に向かってエグレスフレームを経路指定するようにプロセッサに指示する命令を含む。
実施例215は、実施例214の主題を含む。実施例215では、非一時的機械可読媒体は、実行されたときに、利用可能なイングレスプロトコルおよびエグレスプロトコルのインベントリを作成するようにプロセッサに指示する命令を含む。
実施例216は、実施例214または215のいずれかの主題を含む。実施例216では、非一時的機械可読媒体は、実行されると、エグレスフレームのデータフィールド内に収まるには大きすぎる場合にはイングレスフレームを断片化するようにプロセッサに指示する命令を含む。
実施例217は、実施例214から216のいずれかの主題を含む。実施例217では、非一時的機械可読媒体は、実行されると、宛先で正しく再アセンブルするために各断片にシーケンス番号をラベル付けするようにプロセッサに指示する命令を含む。
実施例218は、実施例214から217のいずれかの主題を含む。実施例218では、非一時的機械可読媒体は、実行されると、イングレスフレームまたはイングレスフレームの断片を、エグレスフレームのペイロードフィールドに配置するようにプロセッサに指示する命令を含む。
実施例219は、実施例214から218のいずれかの主題を含む。実施例219では、非一時的機械可読媒体は、実行されると、最終宛先を示すアドレスを付けて後続のデバイスにフレームを送信するようにプロセッサに指示する命令を含む。
実施例220は、装置を含む。装置は、モノのインターネット(IoT)ネットワークを含み、IoTネットワークは、IoTデバイスを含む。IoTデバイスは、IoTデバイスとターゲットデバイスとの間の利用可能な並列通信チャネルを識別するためのネットワーク発見部と、送信のためにペイロードをサブオブジェクトに断片化するためのペイロード断片化部/パッケージ化部と、並列通信チャネルを介してサブオブジェクトをターゲットデバイスに送信するためのパケット通信部と、を含む。
実施例221は、実施例220の主題を含む。実施例221では、ネットワーク発見部は、通信チャネルの組み合わせを判定する。
実施例222は、実施例220または221のいずれかの主題を含む。実施例222では、ネットワーク発見部は、通信速度、信頼性、または電力利用可能性、あるいはそれらの組み合わせに少なくとも部分的に基づいて、通信チャネルを判定する。
実施例223は、実施例220から222のいずれかの主題を含む。実施例223では、ペイロードはセンサから得られた測定値を含む。
実施例224は、実施例220から223のいずれかの主題を含む。実施例224では、ペイロードは別のIoTデバイスからのメッセージを含む。
実施例225は、実施例220から224のいずれかの主題を含む。実施例225では、ネットワーク発見部は、並列通信に使用されるべき利用可能なネットワーク通信パスおよび関連プロトコルのリストを維持する。
実施例226は、実施例220から225のいずれかの主題を含む。実施例226では、ペイロード断片化部/パッケージ化部は、サブオブジェクトのそれぞれをフレームにパッケージ化し、フレームは、通信チャネルに関連するプロトコル内にある。
実施例227は、実施例220から226のいずれかの主題を含む。実施例227では、装置は、他のデバイスからのフレームを受信し、プロトコルパッケージングを取り外し、フレームを分析してメッセージおよびシーケンス情報を識別するために、ペイロード受信部/分析部を含む。
実施例228は、実施例220から227のいずれかの主題を含む。実施例228では、ペイロード受信部/分析部は、受信されたフレームのデータフィールドがペイロードのサブオブジェクトであると判定する。
実施例229は、実施例220から228のいずれかの主題を含む。実施例229では、ペイロード受信部/分析部は、サブオブジェクトおよびすべての受信されたサブオブジェクトのシーケンス番号を格納し、次いで、シーケンス番号およびストレージ情報をペイロードデフラグ部に渡す。
実施例230は、実施例220から229のいずれかの主題を含む。実施例230では、装置は、ペイロードを最終ペイロードオブジェクトに再アセンブルするためのペイロードデフラグ部を含む。
実施例231は、複数の並列通信チャネルを介してペイロードを断片化しディスパッチするための方法を含む。複数の並列通信チャネルを介してペイロードを断片化しディスパッチするための方法は、利用可能な通信チャネルおよび通信チャネルに関連するプロトコルフレームによってサポートされるペイロードサイズに少なくとも部分的に基づいて、ペイロードを断片に断片化する段階を含む。本方法はまた、シーケンス番号を断片に割り当てる段階と、サブブロックを形成するために、シーケンス番号を含むヘッダを断片に付加する段階と、サブブロックを異なる経路で伝送するためのプロトコルフレームにパッケージ化する段階と、異なる通信チャネルを介してサブブロックをディスパッチする段階と、を含む。
実施例232は、実施例231の主題を含む。実施例232では、ペイロードを断片に断片化する段階は、通信チャネルを介する送信速度、または通信チャネルを介する優先度、あるいはその両方に少なくとも部分的に基づく。
実施例233は、実施例231または232のいずれかの主題を含む。実施例233では、本方法は、宛先への利用可能な通信チャネルを発見する段階と、通信チャネルおよび関連プロトコルをライブラリに保存する段階と、を含む。
実施例234は、実施例231から233のいずれかの主題を含む。実施例234では、本方法は、接続が依然として存在することを確認するために周期的に通信チャネルをテストする段階を含む。
実施例235は、複数の並列通信チャネルを介して送信されたパケットを受信し再結合する方法を含む。複数の並列通信チャネルを介して送信されたパケットを受信し再結合するための方法は、複数の異なる通信チャネルを介して送信デバイスからのフレームを受信する段階と、ペイロードの断片を取得するためにフレームを解析する段階と、断片からペイロードを再アセンブルするときを判定する段階と、ペイロードを再アセンブルするために断片を結合する段階と、を含む。
実施例236は、実施例235の主題を含む。実施例236では、本方法は、複数の異なる通信チャネル上でのフレームの受信を検出する段階と、フレームからペイロードを取り外す段階と、ペイロード断片および関連シーケンス番号を識別するために、ペイロードを分析する段階と、ペイロード断片を格納する段階と、関連シーケンス番号を記録する段階と、を含む。
実施例237は、実施例235または236のいずれかの主題を含む。実施例237では、本方法は、部分ペイロードを取得するためにすべてのフレームが受信される前に断片を結合する段階を含む。
実施例238は、実施例235から237のいずれかの主題を含む。実施例238では、本方法は、ペイロードをコンシューマプロセスに提供する段階を含む。
実施例239は、非一時的機械可読媒体を含む。非一時的機械可読媒体は、実行されると、通信のために選択されたプロトコルのフレームのデータフィールドに収まるようにペイロードを断片化し、サブブロックを形成するために、断面のシーケンス番号を含む各断片にヘッダを付加し、通信チャネルに応じて、各サブブロックをプロトコルフレームにパッケージ化し、プロトコルフレームに関連する通信チャネルを介してプロトコルフレームのそれぞれをターゲットデバイスにディスパッチするようにプロセッサに指示する命令を含む。
実施例240は、実施例239の主題を含む。実施例240では、非一時的機械可読媒体は、実行されると、受信デバイスへの利用可能な通信チャネルを発見するようにプロセッサに指示する命令を含む。
実施例241は、実施例239または240のいずれかの主題を含む。実施例241では、非一時的機械可読媒体は、実行されると、プロトコルフレームを受信し、プロトコルフレームからサブブロックをパッケージ解除し、各サブブロック内のヘッダを解析して断片と断片のシーケンス番号を識別するようにプロセッサに指示し、シーケンス番号の順序で断片からペイロードを再アセンブルするようにプロセッサに指示する命令を含む。
実施例242は、実施例239から241のいずれかの主題を含む。実施例242では、非一時的機械可読媒体は、実行されると、すべての断片が受信される前にペイロードを再アセンブルする必要があると判定するようにプロセッサに指示する命令を含む。
実施例243は、装置を含む。装置は、モノのインターネット(IoT)ネットワークを含み、IoTネットワークはビーコンノードを含む。ビーコンノードは、衛星位置データを受信および処理するための衛星支援ナビゲーションモジュールと、衛星支援ナビゲーションモジュールを制御し、衛星支援ナビゲーション位置情報を取得するための衛星支援ナビゲーションロケータと、衛星支援ナビゲーション位置情報を解析するためのデータ解析部と、位置パケットを構築するためのペイロード構築部と、通信リンクを介してパケットをメッシュデバイスに送信するための通信部と、を含む。
実施例244は、実施例243の主題を含む。実施例244では、衛星支援ナビゲーション位置情報は、緯度、経度、時間、もしくは高度、またはそれらの任意の組み合わせを含む。
実施例245は、実施例243または244のいずれかの主題を含む。実施例245では、装置は、通信リンクを提供するために、メッシュ送受信機、アップリンク送受信機、またはネットワークインターフェースコントローラ(NIC)、あるいはそれらの任意の組み合わせを含む。
実施例246は、実施例243から245のいずれかの主題を含む。実施例246では、ペイロード構築部は、通信リンクに関連するプロトコルを有するフレームにパケットを配置する。
実施例247は、実施例243から246のいずれかの主題を含む。実施例247では、衛星支援ナビゲーションロケータは、バッテリ容量に少なくとも部分的に基づいて、GPSモジュールを非アクティブ化する。
実施例248は、実施例243から247のいずれかの主題を含む。実施例248では、衛星支援ナビゲーションロケータは、別のビーコンノードが衛星支援ナビゲーションモジュールを非アクティブ化したときに、衛星支援ナビゲーションモジュールをアクティブ化する。
実施例249は、実施例243から248のいずれかの主題を含み、IoTデバイスを249に含む。実施例249では、IoTデバイスは、パケットがビーコンIDと一致するか、有効データを含むか、またはその両方であるかを判定するためにビーコンノードから受信したパケットを確認するためのパケット確認部を含む。
実施例250は、実施例243から249のいずれかの主題を含む。実施例250では、パケット確認部は無効フレームを無視する。
実施例251は、実施例243から250のいずれかの主題を含む。実施例251では、パケット確認部は再送要求を送信する。
実施例252は、実施例243から251のいずれかの主題を含む。実施例252では、IoTデバイスは、位置ペイロードを抽出するために、受信したフレームを分析するためのパケット抽出部を含む。
実施例253は、位置ペイロードを生成するための方法を含む。位置ペイロードを生成するための方法は、衛星支援ナビゲーションモジュールから位置データを取得する段階と、位置データを解析する段階と、位置データから位置ペイロードを構築する段階と、位置ペイロードを周囲のIoTデバイスにブロードキャストする段階と、を含む。
実施例254は、実施例253の主題を含む。実施例254では、本方法は、位置を取得する段階を含み、位置を取得するために衛星支援ナビゲーションモジュールにコマンドを送信する段階と、事前定義された期間待機する段階と、位置が取得されたか否かを判定する段階と、位置が取得されたいる場合に位置データを提供する段階と、を含む。
実施例255は、実施例253または254のいずれかの主題を含む。実施例255では、位置データを解析する段階は、経度、緯度、または時間、あるいはそれらの任意の組み合わせを抽出する段階と、位置データをローカルストアに格納する段階と、を含む。
実施例256は、実施例253から255のいずれかの主題を含む。実施例256では、位置データから位置ペイロードを構築する段階は、シーケンシャルビットストリングに緯度、経度、および時間を書き込む段階と、ビーコンIDをシーケンシャルビットストリングに書き込む段階と、タイムスタンプをシーケンシャルビットストリングに書き込む段階と、を含む。
実施例257は、実施例253から256のいずれかの主題を含む。実施例257では、タイムスタンプは衛星データから抽出された時間データを含む。
実施例258は、実施例253から257のいずれかの主題を含む。実施例258では、本方法は、送信のためにペイロードをフレームにパッケージ化することを含む。
実施例259は、実施例253から258のいずれかの主題を含む。実施例259では、フレームは、イーサネット(登録商標)フレーム、LoRaWAN(登録商標)フレーム、4Gフレーム、3Gフレーム、またはそれらの任意の組み合わせである。
実施例260は、実施例253から259のいずれかの主題を含む。実施例260では、本方法は、送信機を起動する段階と、無線送信、有線ネットワーク、またはその両方を介してメッセージとしてフレームをディスパッチする段階と、を含む。
実施例261は、実施例253から260のいずれかの主題を含む。実施例261では、本方法は、事前定義された間隔待機する段階を含む。
実施例262は、実施例253から261のいずれかの主題を含む。実施例262では、本方法は、位置ペイロードを含むビーコンフレームを受信する段階と、ビーコンノードのアイデンティティを確認する段階と、フレームが有効であることを確認する段階と、ビーコンフレームから位置ペイロードを抽出する段階と、緯度および経度情報を抽出するために位置ペイロードを解析する段階と、を含む。
実施例263は、実施例253から262のいずれかの主題を含む。実施例263では、本方法は、タイムスタンプを抽出するために位置ペイロードを解析する段階を含む。
実施例264は、非一時的機械可読媒体を含む。非一時的機械可読媒体は、実行されると、衛星支援ナビゲーションモジュールから位置データを取得し、緯度および経度について別々の値を取得するために衛星支援ナビゲーションモジュールからの位置データを解析し、緯度および経度を含む位置ペイロードを構築し、位置ペイロードを特定のプロトコルのフレームにパッケージ化し、位置ペイロードをディスパッチするようにプロセッサに指示する命令を含む。
実施例265は、実施例264の主題を含む。実施例265では、非一時的機械可読媒体は、実行されると、タイムスタンプを一ペイロードに追加するようにプロセッサに指示する命令を含む。
実施例266は、実施例264または265のいずれかの主題を含む。実施例266では、非一時的機械可読媒体は、実行されると、ビーコンノードから受信されたフレームから位置ペイロードを抽出するようにプロセッサに指示する命令を含む。
実施例267は、装置を含む。装置は、モノのインターネット(IoT)ネットワークを含み、IoTネットワークは、IoTデバイスを含む。IoTデバイスは、IoTデバイス上のデータを管理するためのデータマネージャと、IoTデバイスを通過するデータの各断片をインバウンド、アウトバウンド、またはキャッシュとして分類するためのデータ分類部と、分類されたデータをIoTデバイス上の物理的な位置にマッピングするためのデータマップ部と、を含む。
実施例268は、実施例267の主題を含む。実施例268では、IoTデバイスは、IoTデバイスを出入りするデータ移動を追跡するためのデータ履歴部を含む。
実施例269は、実施例267から268のいずれかの主題を含む。実施例269では、IoTデバイスは、通信チャネルのためのフレームに使用されるプロトコルを管理するためのプロトコルマネージャを含む。
実施例270は、実施例267から269のいずれかの主題を含む。実施例270では、IoTデバイスは、複数の通信チャネル上のネットワーク通信を管理するためのネットワークマネージャを含む。
実施例271は、実施例267から270のいずれかの主題を含む。実施例271では、IoTデバイスは、メッシュ送受信機、アップリンク送受信機、イーサネット(登録商標)接続、またはそれらの任意の組み合わせを管理するための通信マネージャを含む。
実施例272は、実施例267から271のいずれかの主題を含む。実施例272では、IoTデバイスは、IoTデバイス自体のためのインバウンドデータを格納するためのインボックスを含む。
実施例273は、実施例267から272のいずれかの主題を含む。実施例273では、IoTデバイスは、別のメッシュデバイスに送信されるアウトバウンドデータを格納するためのアウトボックスを含む。
実施例274は、実施例267から273のいずれかの主題を含む。実施例274では、IoTデバイスは、データ要求を格納するためのキャッシュを含む。
実施例275は、実施例267から275のいずれかの主題を含む。実施例275では、IoTデバイスは、データを格納し配信するために互いに通信する複数のメッシュデバイスを含む。
実施例276は、実施例267から276のいずれかの主題を含む。実施例276では、データは、ステートレス方式で配信される。
実施例277は、分散型コンテンツ配信のための方法を含む。分散型コンテンツ配信のための方法は、データ断片をインバウンドデータ、アウトバウンドデータ、またはキャッシュデータとして分類する段階と、データ断片をデータストア内の物理的位置にマッピングする段階と、を含む。
実施例278は、実施例277の主題を含む。実施例278では、本方法は、インバウンドデータ断片についてのハッシュ鍵を計算する段階と、ハッシュ鍵がデータストア内にあるか否かを判定する段階と、そうでない場合にはデータ断片を格納する段階と、を含む。
実施例279は、実施例277または278のいずれかの主題を含む。実施例279では、本方法は、データ断片がアウトバウンドデータであると判定された場合、データの生存期間(TTL)を計算する段階を含む。
実施例280は、実施例277から279のいずれかの主題を含む。実施例280では、TTLは、データ断片が削除前に送信され得るホップ数として計算される。
実施例281は、実施例277から280のいずれかの主題を含む。実施例281では、TTLは、削除前の期間として計算される。
実施例282は、実施例277から281のいずれかの主題を含む。実施例282では、TTLは、データ断片が送信され得るホップ数と期間との組み合わせとして計算される。
実施例283は、実施例277から282のいずれかの主題を含む。実施例283では、本方法は、データ履歴部内でインバウンドデータ要求、アウトバウンドデータ要求、またはその両方を追跡する段階を含む。
実施例284は、実施例277から283のいずれかの主題を含む。実施例284では、本方法は、キャッシュへのデータアクセスの頻度に少なくとも部分的に基づいて、キャッシュのサイズを調整する段階を含む。
実施例285は、実施例277から284のいずれかの主題を含む。実施例285では、本方法は、キャッシュへのデータアクセスの頻度に少なくとも部分的に応じて選択されるストレージ種別を選択する段階を含む。
実施例286は、非一時的機械可読媒体を含む。非一時的機械可読媒体は、実行されると、モノのインターネット(IoT)デバイスを通過するデータ断片を、インバウンドデータ、アウトバウンドデータ、またはキャッシュデータとして分類し、分類されたデータ断片をIoTデバイス上の物理的な位置にマッピングするようにプロセッサに指示する命令を含む。
実施例287は、実施例286の主題を含む。実施例287では、非一時的機械可読媒体は、実行されると、インバウンドデータのデータ断片のハッシュ鍵を計算し、ハッシュ鍵がローカルストアにあるか否かを判定し、ない場合は、データ断片をローカルストアに保存するようにプロセッサに指示する命令を含む。
実施例288は、実施例286または287のいずれかの主題を含む。実施例288では、非一時的機械可読媒体は、実行されると、ローカルストア内にあるデータ断片を更新するようにプロセッサに指示する命令を含む。
実施例289は、実施例286から288のいずれかの主題を含む。実施例289では、非一時的機械可読媒体は、実行されると、データ断片の生存期間を計算するようにプロセッサに指示する命令を含む。
実施例290は、装置を含む。装置は、モノのインターネット(IoT)ネットワークを含み、IoTネットワークは、少なくとも2つのIoTデバイスを含む無線メモリシステムを含む。無線メモリシステムは、発信ノードと受信ノードとを含む。発信ノードは、断片に格納されるデータを分割するためのペイロード断片化部と、断片からパケットを形成するためのカプセル化部と、受信ノードにパケットを送信するための通信部と、受信ノードから受信したパケットを発信ノードにループバックするためのルータと、を含む。受信ノードは、発信ノードから受信したパケットを受信ノードにループバックするルータを含み、パケットは発信ノードと受信ノードとの間の送信に格納される。
実施例291は、実施例290の主題を含む。実施例291では、発信ノードは、受信ノードから受信したパケットから断片を取り外すためのペイロード抽出部と、断片からデータを再構築するためのデータアセンブラと、を含む。
実施例292は、実施例290または291のいずれかの主題を含む。実施例292では、発信ノードと受信ノードとは、互換性のあるメッシュ送受信機をそれぞれ含む。
実施例293は、実施例290から292のいずれかの主題を含む。実施例293では、本装置は、発信元ノードと受信ノードとの間にチェーンを形成する複数のノードを含む。
実施例294は、実施例290から293のいずれかの主題を含む。実施例294では、発信ノードおよび受信ノードは、ネットワーク/経路指定層を含む通信スタックを含む。
実施例295は、実施例290から294のいずれかの主題を含む。実施例295では、ネットワーク/経路指定層は、ネットワーク/経路指定層で受信したパケットを送信のために物理層にループバックする。
実施例296は、実施例290から295のいずれかの主題を含む。実施例296では、ネットワーク/経路指定層は、データアクセスコマンドを受け入れ、パケットをアプリケーション層に転送する。
実施例297は、デバイス間の送信ループにおいてデータを断片化し格納するための方法を含む。デバイス間の送信ループでデータを断片化し格納するための方法は、格納されるデータをデータ断片に断片化する段階と、データ断片をメモリパケットにカプセル化する段階と、メモリパケットを別のデバイスに送信する段階と、他のデバイスからメモリパケットを受信する段階と、メモリパケットは他のデバイスにループバックする段階と、を含む。
実施例298は、実施例297の主題を含む。実施例298では、本方法は、断片のそれぞれにシーケンス番号を割り当てる段階を含む。
実施例299は、実施例297または298のいずれかの主題を含む。実施例299では、本方法は、メモリパケットを形成するために、シーケンス番号を含むヘッダを断片に付加する段階を含む。
実施例300は、実施例297から299のいずれかの主題を含む。実施例300では、ヘッダは、メモリパケットが格納されたデータであるという指示を含む。
実施例301は、実施例297から300のいずれかの主題を含む。実施例301では、本方法は、アプリケーション層の下のスタック層においてメモリパケットを他のデバイスにループバックする段階を含む。
実施例302は、実施例297から301のいずれかの主題を含む。実施例302では、本方法は、受信されたメモリパケットが格納され続けるべきであるか否かを判定する段階と、格納され続けるべきである場合、パケットを他のデバイスに送信する段階と、を含む。
実施例303は、実施例297から302のいずれかの主題を含む。実施例303では、本方法は、データがメモリパケットから受信されるべきであると判定する段階を含む。
実施例304は、実施例297から303のいずれかの主題を含む。実施例304では、本方法は、メモリパケットからデータ断片を取り除く段階を含む。
実施例305は、実施例297から304のいずれかの主題を含む。実施例305では、本方法は、メモリパケットからシーケンス番号を取り除く段階を含む。
実施例306は、実施例297から305のいずれかの主題を含む。実施例306では、本方法は、データ断片のすべてが受信されたか否かを判定する段階と、受信された場合、データを取得するためにシーケンス番号の順にデータ断片をアセンブルする段階と、を含む。
実施例307は、実施例297から306のいずれかの主題を含む。実施例307では、本方法は、データ演算で使用するために、データをアプリケーション層に渡す段階を含む。
実施例308は、非一時的機械可読媒体を含む。非一時的機械可読媒体は、実行されると、経路指定要求がデータストレージ要求であるか否かを判定し、データをペイロードに断片化し、ペイロードをメモリパケットにカプセル化し、通信チャネルを介してメモリパケットを経路指定し、受信したメモリパケットを別のデバイスに送信すべきか、使用のために傍受するかを判定するようにプロセッサに指示する命令を含む。
実施例309は、実施例308の主題を含む。実施例309では、非一時的機械可読媒体は、実行されると、メモリパケットからペイロードをパッケージ解除するようにプロセッサに指示する命令を含む。
実施例310は、実施例308または319のいずれかの主題を含む。実施例310では、非一時的機械可読媒体は、実行されると、シーケンス番号順にペイロードを再アセンブルしてデータを形成するようにプロセッサに指示する命令を含む。
実施例311は、装置を含む。本装置は、モノのインターネット(IoT)ネットワークを含み、IoTネットワークは、複数の重複するフレームを含む変調波形を送信するための無線送信機を含むIoTデバイスを含み、変調波形は、Zadoff-Chu(ZC)シーケンスを含む。
実施例312は、実施例311の主題を含む。実施例312では、装置は、別のデバイスへの無線通信に存在し得る利用可能なチャネル数を判定するためのチャネル識別部を含む。
実施例313は、実施例311または312のいずれかの主題を含む。実施例313では、本装置は、利用可能なチャネルのそれぞれに対してZCシーケンスを生成するためのシーケンス生成部を含む。
実施例314は、実施例311から313のいずれかの主題を含む。実施例314では、本装置は、送信に使用される複数のチャネルを符号化するプリアンブル波形を生成するためのプリアンブル生成部を含む。
実施例315は、実施例311から314のいずれかの主題を含む。実施例315では、本装置は、複数のチャネルのそれぞれについてのZC変調フレームと複数のチャネルを示すプリアンブル波形とを含む変調波形を生成するための通信部を含む。
実施例316は、実施例311から315のいずれかの主題を含む。実施例316では、装置は、プリアンブル波形が存在するか否かを判定するために受信波形に対して相互相関を実行し、存在する場合には受信波形内のチャネル数を判定するためのインデックス識別部を含む。
実施例317は、実施例311から316のいずれかの主題を含む。実施例317では、本装置は、複数の重複するフレームを抽出するために変調波形を復調するためのチャネル復調部を含む。
実施例318は、Zadoff-Chu(ZC)シフトシーケンスを使用して複数のチャネルでデータを送信するための方法を含む。Zadoff-Chu(ZC)シフトシーケンスを使用して複数のチャネルでデータを送信するための方法は、通信に使用される複数のチャネルを判定する段階と、ZCシフトシーケンス内の複数のチャネルを含むプリアンブル波形を生成する段階と、メッセージを作成するために、変調波形の前にプリアンブル波形を追加する段階と、メッセージを受信デバイスに送信する段階と、を含む。
実施例319は、実施例318の主題を含む。実施例319では、本方法は、利用可能なチャネル数を判定する段階を含む。
実施例320は、実施例318または319のいずれかの主題を含む。実施例320では、利用可能な複数のチャネルは、送信で運ばれ得る最大量の情報を判定するために情報理論を使用して判定される。
実施例321は、実施例318から320のいずれかの主題を含む。実施例321では、本方法は、利用可能なチャネルの番号を受信デバイスに送信する段階を含む。
実施例322は、実施例318から321のいずれかの主題を含む。実施例322では、本方法は、利用可能なチャネルのそれぞれに対応するZCシフトシーケンスを生成する段階を含む。
実施例323は、実施例318から322のいずれかの主題を含む。実施例323では、本方法は、別々のZCシフトシーケンスで複数のチャネルのそれぞれで運ばれるフレームを変調する段階と、変調波形を生成するために、変調されたフレームを結合する段階と、を含む。
実施例324は、実施例318から323のいずれかの主題を含む。実施例324では、本方法は、対応するチャネルによって運ばれるフレームを取得するために、複数のZCシフトシーケンスのそれぞれにおいてメッセージ内の変調波形を復調する段階を含む。
実施例325は、実施例318から324のいずれかの主題を含む。実施例325では、本方法は、プリアンブル波形が存在するか否かを判定するために、メッセージに対して自己相関を実行する段階を含む。
実施例326は、実施例318から325のいずれかの主題を含む。実施例326では、本方法は、変調波形内の複数のチャネルを判定するために、複数のZCシフトシーケンスのそれぞれにおいてプリアンブル波形上で相互相関を実行する段階を含む。
実施例327は、非一時的機械可読媒体を含む。非一時的機械可読媒体は、実行されると、通信に使用される複数のチャネルを判定し、複数のチャネルを含むプリアンブル波形を生成し、メッセージを作成するために、変調波形の前にプリアンブル波形を追加し、メッセージを受信デバイスに送信するようにプロセッサに指示する命令を含む。
実施例328は、実施例327の主題を含む。実施例328では、非一時的機械可読媒体は、実行されると、利用可能な複数のチャネルを判定するようにプロセッサに指示する命令を含む。
実施例329は、実施例327または328のいずれかの主題を含む。実施例329では、非一時的機械可読媒体は、実行されると、利用可能な複数のチャネルを受信デバイスに送信するようにプロセッサに指示する命令を含む。
実施例330は、実施例327から329のいずれかの主題を含む。実施例330では、非一時的機械可読媒体は、実行されると、利用可能な各チャネルに対応する別々のZCシフトシーケンスを生成するようにプロセッサに指示する命令を含む。
実施例331は、実施例327から330のいずれかの主題を含む。実施例331では、非一時的機械可読媒体は、実行されたときに、別々のZCシフトシーケンスで複数のチャネルのそれぞれによって運ばれるフレームを変調し、変調波形を生成するために、変調されたフレームを組み合わせるようにプロセッサに命令する命令を含む。
実施例332は、実施例327から331のいずれかの主題を含む。実施例332では、非一時的機械可読媒体は、実行されると、対応するチャネルによって運ばれるフレームを取得するために、複数のZCシフトシーケンスのそれぞれにおいて変調波形を復調するようにプロセッサに指示する命令を含む。
実施例333は、実施例327から332のいずれかの主題を含む。実施例333では、非一時的機械可読媒体は、実行されると、プリアンブル波形が存在するか否かを判定するために、メッセージに対して自己相関を実行するようにプロセッサに指示する命令を含む。
実施例334は、実施例327から333のいずれかの主題を含む。実施例334では、非一時的機械可読媒体は、実行されると、変調波形内の複数のチャネルを判定するために、複数のZCシフトシーケンスのそれぞれにおいてプリアンブル波形に対して相互相関を実行するようにプロセッサに指示する命令を含む。
実施例335は、装置を含む。装置は、モノのインターネット(IoT)ネットワークを含み、IoTネットワークは、IoTデバイスを含む。IoTデバイスは、複数の周波数、プロトコル、またはその両方を含む無線送受信機と、通信に使用中の無線送受信機を追跡するための共存マネージャと、通信に使用され得る無線送受信機を識別するための汎用共存インターフェースと、通信のためのフレームを構築するためのプロトコル抽象化アプリケーションプログラミングインターフェース(API)と、無線送受信機を使用してプロトコル変換APIから別のデバイスへフレームを送信するための通信部と、を含む。
実施例336は、実施例335の主題を含む。実施例336では、ユニバーサル共存インターフェースは、無線送受信機の構成可能パラメータを修正する。
実施例337は、実施例335から336のいずれかの主題を含む。実施例337では、構成可能パラメータは、符号化方式、変調、またはその両方を含む。
実施例338は、実施例335から337のいずれかの主題を含む。実施例338では、構成可能パラメータは、個々の無線送受信機に対する送信電力を含む。
実施例339は、実施例335から338のいずれかの主題を含む。実施例339では、ユニバーサル共存インターフェースは、無線送受信機がいつ通信に使用されるべきかを識別する。
実施例340は、実施例335から339のいずれかの主題を含む。実施例340では、IoTデバイスは、選択された無線送受信機を介した通信に使用され得るプロトコルを取得するためのプロトコルデータストアを含む。
実施例341は、実施例335から340のいずれかの主題を含む。実施例341では、IoTデバイスは、アクティブ通信計画と、共存マネージャによって判定された無線とを含むチャネルデータストアを含む。
実施例342は、実施例335から341のいずれかの主題を含む。実施例342では、無線送受信機は、IEEE 802.11x規格、IEEE 802.15.4規格、またはLoRa規格、またはそれらの任意の組み合わせに準拠する。
実施例343は、複数の共存する無線機の制御および管理ための方法を含む。複数の共存無線機を制御および管理するための方法は、モノのインターネット(IoT)デバイス内の無線システムで利用可能な無線機をエニュメレーションする段階と、近隣機と関連無線機との両方を識別するアクティブ共存モデルを判定する段階と、利用可能な帯域で関連無線機を通して近隣機と通信する段階と、を含む。
実施例344は、実施例343の主題を含む。実施例344では、本方法は、ローカルセキュリティオーソリティドメインブローカ(LSADB)からの通信に利用可能な帯域を識別する段階と、その帯域を使用するための帯域計画を判定する段階と、各近隣機のアイデンティティを含む近隣機マップを構築する段階と、クロスドメイン情報共有システム(CDIS)から各近隣と通信するために使用され得る関連帯域を識別する段階と、近隣機と関連帯域との両方を識別する初期共存モデルを判定する段階と、を含む。
実施例345は、実施例343または344のいずれかの主題を含む。実施例345では、本方法は、無線機の帯域が初期共存モデルに存在しなかった場合には、無線機のサブスクリプション要求をCDISに送信する段階を含む。
実施例346は、実施例343から345のいずれかの主題を含む。実施例346では、本方法は、IoTデバイス内の無線機に使用される規格が利用可能であることを検証する段階を含む。
実施例347は、実施例343から346のいずれかの主題を含む。実施例347では、本方法は、クラウドコンピューティングネットワークからIoTデバイス内の無線機に使用される規格をダウンロードする段階を含む。
実施例348は、実施例343から347のいずれかの主題を含む。実施例348では、本方法は、デバイス内の無線機のそれぞれを初期化する段階と、無線機のいずれかが規格に非準拠であるか否かを判定する段階と、無線機のそれぞれに対して構成定可能なパラメータを設定するメッセージを無線システムに送信する段階と、使用中の無線機用のパラメータマッピングセットを作成する段階と、無線システムとの通信が初期化されたことを示すために無線システムにメッセージを送信する段階と、を含む。
実施例349は、実施例343から348のいずれかの主題を含む。実施例349では、本方法は、共存違反を検出する段階と、構成可能パラメータを再構成する段階と、を含む。
実施例350は、実施例343から349のいずれかの主題を含む。実施例350では、本方法は、ライセンスされたユーザが帯域を占有していると判定することによって共存違反を検出する段階を含む。
実施例351は、実施例343から350のいずれかの主題を含む。実施例351では、構成可能なパラメータを再構成する段階は、新しいパラメータのセットと共にメッセージを無線システムに送信する段階と、無線機との通信を再初期化する段階と、を含む。
実施例352は、実施例343から351のいずれかの主題を含む。実施例352では、構成可能パラメータを再構成する段階は、無線機を一時的に無効にする段階を含む。
実施例353は、実施例343から352のいずれかの主題を含む。実施例353では、構成可能パラメータを再構成する段階は、異なる帯域にシフトする段階を含む。
実施例354は、実施例343から353のいずれかの主題を含む。実施例354では、本方法は、他のどのノードがIoTデバイスと通信しているかを判定する段階と、近隣コマンドリストの変更を判定する段階と、新しいパラメータのセットと共に再構成要求を無線システムに送信する段階と、を含む。
実施例355は、実施例343から354のいずれかの主題を含む。実施例355では、本方法は、提案されたパラメータを用いて近隣機からの変更の要求を受信する段階と、提案されたパラメータを用いて再構成要求を無線システムに送信する段階と、を含む。
実施例356は、非一時的機械可読媒体を含む。非一時的機械可読媒体は、実行されると、帯域計画を判定し、各近隣機のアイデンティティおよびその近隣機に関連する帯域を含む近隣機マップを構築し、近隣機および関連する通信チャネルの両方を識別する共存モデルを判定するようにプロセッサに指示する命令を含む。
実施例357は、実施例356の主題を含む。実施例357では、非一時的機械可読媒体は、実行されると、利用可能な無線機を判定した後に帯域計画を修正するようにプロセッサに指示する命令を含む。
実施例358は、実施例356または357のいずれかの主題を含む。実施例358では、非一時的機械可読媒体は、実行されると、利用可能な無線機を判定した後に共存モデルを修正するようにプロセッサに指示する命令を含む。
実施例359は、実施例356から358のいずれかの主題を含む。実施例359では、非一時的機械可読媒体は、実行されると、共存違反が検出された場合、隣接ユニットの繰り返しチェックが構成可能パラメータの調整が必要であることを示す場合、もしくは隣接ユニットから要求された場合、またはそれらの任意の組み合わせの場合、通信を再構成するようにプロセッサに指示する命令を含む。
実施例360は、装置を含む。本装置は、モノのインターネット(IoT)ネットワークを含み、IoTネットワークは、サービスを形成するためにサービスコーディネータにサービス管理要求を発行するオーケストレータを含むデバイスを含み、サービスコーディネータは、サービスに参加するための複数のコンポーネントと、サービスのためのネットワークサービス要素を実行するためのコンポーネントとを識別する。
実施例361は、実施例360の主題を含む。実施例361では、オーケストレータは、タスクを実行するために複数のネットワークサービスオーバーレイを管理する。
実施例362は、実施例360から361のいずれかの主題を含む。実施例362では、本装置は、複数のネットワークサービスオーバーレイを含む共有リポジトリを含む。
実施例363は、実施例360から362のいずれかの主題を含む。実施例363では、ネットワークサービスオーバーレイは、コンポーネントがネットワークサービス要素を実行することを可能にするためのコードセグメントを含む。
実施例364は、実施例360から363のいずれかの主題を含む。実施例364では、サービスコーディネータは、コンポーネントからのデータまたはメタデータまたはその両方を格納するためのデータベースと、完了を必要とするネットワークサービス要素を保持するための共有仮想リポジトリと、ネットワークサービス要素を完成するためにコンポーネントを選択するための機械学習エンジンと、を含む。
実施例365は、実施例360から364のいずれかの主題を含む。実施例365では、共有仮想リポジトリは、ネットワークサービス要素に割り当てられたコンポーネントのアイデンティティを格納する。
実施例366は、実施例360から365のいずれかの主題を含む。実施例366では、サービスは複数のネットワークサービス要素を含み、ネットワークサービス要素は複数のコンポーネントによって完成される。
実施例367は、実施例360から366のいずれかの主題を含む。実施例367では、サービスは、複数のモノのインターネット(IoT)デバイスを含むフォグデバイスを含む。
実施例368は、実施例360から367のいずれかの主題を含む。実施例368では、サービスコーディネータは、ネットワークドメインコントローラを含む。
実施例369は、実施例360から368のいずれかの主題を含む。実施例369では、コンポーネントは、クライアントを含むデバイスであり、クライアントは、デバイスをサービスコーディネータに登録する。
実施例370は、実施例360から369のいずれかの主題を含む。実施例370では、クライアントは、サービスコーディネータに、取り付けられたセンサ、アクチュエータ、もしくはデバイス、またはそれらの任意の組み合わせを含むメッセージを送信する。
実施例371は、実施例360から370のいずれかの主題を含む。実施例371では、複数のコンポーネントは複数のドメインから選択される。
実施例372は、サービス要求を完了するための方法を含む。サービス要求を完了するための方法は、ネットワークドメインコントローラでオーケストレーション要求を受信する段階と、オーケストレーション要求が既存のサービスに対するものであるか否かを判定する段階と、オーケストレーション要求が既存のサービスに対するものである場合、オーケストレーション要求をサービスコーディネータに送信する段階と、を含む。
実施例373は、実施例372の主題を含む。実施例373では、本方法は、オーケストレーション要求がネットワークサービス要素を含むサービスモデルを準備する新しい要求である場合、ネットワークサービス要素を準備する段階と、ネットワークサービス要素を実行するサービスコンポーネントを識別する段階と、ネットワークサービス要素の動作を実行するためのサービスコンポーネントへのサブスクリプション要求をディスパッチする段階と、を含む。
実施例374は、実施例372または373のいずれかの主題を含む。実施例374では、本方法は、サービスコーディネータを識別する段階を含む。
実施例375は、実施例372から374のいずれかの主題を含む。実施例375では、サービスコンポーネントを識別する段階は、複数のサービスコンポーネントの過去の性能に関するデータにアクセスする段階と、サービスコンポーネントを選択するために機械学習技法を使用する段階と、を含む。
実施例376は、実施例372から375のいずれかの主題を含む。実施例376では、本方法は、サービスコンポーネントでサブスクリプション要求を確認する段階と、サブスクリプション要求が有効である場合に確認をサービスコーディネータに送信する段階と、を含む。
実施例377は、実施例372から376のいずれかの主題を含む。実施例377では、本方法は、サブスクリプション要求が有効ではない場合にサービスコーディネータに拒否を送信する段階を含む。
実施例378は、実施例372から377のいずれかの主題を含む。実施例378では、サブスクリプション要求がサービスコンポーネントによってサポートされている場合、それは有効である。
実施例379は、実施例372から378のいずれかの主題を含む。実施例379では、本方法は、サービスコンポーネント内でネットワークサービス要素を実行する段階と、サービスコンポーネントからサービスコーディネータにデータを返す段階と、を含む。
実施例380は、実施例372から379のいずれかの主題を含む。実施例380では、サービスコンポーネントは、ネットワークサービス要素を実行するために仮想共有リポジトリからネットワークサービスオーバーレイをダウンロードする。
実施例381は、実施例372から380のいずれかの主題を含む。実施例381では、サービスコンポーネントは、クラウド内の共有リポジトリからネットワークサービスオーバーレイをダウンロードする。
実施例382は、実施例372から381のいずれかの主題を含む。実施例382では、本方法は、サービスコンポーネントを登録するために、サービスコンポーネントの能力を含むメッセージをサービスコーディネータに送信する段階を含む。
実施例383は、非一時的機械可読媒体を含む。非一時的機械可読媒体は、実行されると、サービスコーディネータを識別し、ネットワーク要素を準備し、サービスコンポーネントを識別し、サービスコンポーネントへのサブスクリプション要求を送信するように1つまたは複数のプロセッサに指示する命令を含む。
実施例384は、実施例383の主題を含む。実施例384では、非一時的機械可読媒体は、実行されると、サブスクリプション要求を確認し、ネットワークサービス要素を実行および動作させ、データをサービスコーディネータに送信するように1つまたは複数のプロセッサに指示する命令を含む。
実施例385は、実施例383または384のいずれかの主題を含む。実施例385では、非一時的機械可読媒体は、実行されると、接続要求をサービスコーディネータに送信し、デバイス周辺機器データをサービスコーディネータに送信するように1つまたは複数のプロセッサに指示する命令を含む。
実施例386は、装置を含む。本装置は、モノのインターネット(IoT)ネットワークを含み、IoTネットワークは、複数のIoTデバイスを含む。各IoTデバイスは、上流デバイスへの通信チャネルと、複数のIoTデバイスのうちの別の1つへのネットワークリンクと、隣接IoTデバイスを識別するためのハッシュ計算部と、隣接IoTデバイスにメッセージを送信するための通信部と、を含む。
実施例387は、実施例386の主題を含む。実施例387では、本装置は、データファイルを複数のペイロードに断片化するためのデータ断片化部を含む。
実施例388は、実施例386または387のいずれかの主題を含む。実施例388では、本装置は、ペイロードをフレームにパッケージ化してメッセージを作成するための、メッセージ生成部を含む。
実施例389は、実施例386から388のいずれかの主題を含む。実施例389では、隣接IoTデバイス内の通信部がメッセージを受信し、そのメッセージを上流デバイスに送信する。
実施例390は、実施例386から389のいずれかの主題を含む。実施例390では、隣接IoTデバイス内のメッセージ生成部がメッセージを分析してペイロードを取得し、そのペイロードをデータストアに格納する。
実施例391は、実施例386から390のいずれかの主題を含む。実施例391では、本装置は、隣接するIoTデバイスに送信された各メッセージの識別情報をデータストアに格納するためのデータ追跡部を含む。
実施例392は、実施例386から391のいずれかの主題を含む。実施例392では、識別情報は、メッセージ内のペイロードのハッシュコードと隣接IoTデバイスのノードIDとを含む。
実施例393は、実施例386から392のいずれかの主題を含む。実施例393では、データ追跡部は、近隣IoTデバイスから受信した、メッセージが上流のデバイスによって受信されたという確認応答を格納する。
実施例394は、モノのインターネット(IoT)デバイスから近隣のIoTデバイスに送信またはストレージのためにデータを送信するための方法を含む。送信またはストレージのためにモノのインターネット(IoT)デバイスから隣接IoTデバイスにデータを送信するための方法は、ファイルを複数の断片にセグメント化する段階と、各断片のハッシュコードを計算する段階と、ハッシュコードからターゲットノードを識別する段階と、断片をターゲットノードに送信する段階と、を含む。
実施例395は、実施例394の主題を含む。実施例395では、ターゲットノードを識別する段階は、ハッシュコードから選択された複数のバイトを抽出する段階と、選択された複数のバイトを複数のIoTデバイスのそれぞれについてノードIDと比較する段階と、選択された複数のバイトと複数のIoTデバイスにおけるノードIDとの間の一致が最も近いものによってターゲットノードを識別する段階と、を含む。
実施例396は、実施例394または395のいずれかの主題を含む。実施例396では、断片をターゲットノードに送信する段階は、断片をフレーム内のペイロードフィールドにパックする段階と、フレームをターゲットノードに送信する段階と、を含む。
実施例397は、実施例394から396のいずれかの主題を含む。実施例397では、本方法は、ノードIDを計算する段階と、ノードIDを複数のIoTデバイス内の隣接ノードと共有する段階と、を含む。
実施例398は、実施例394から397のいずれかの主題を含む。実施例398では、本方法は、隣接IoTデバイスからフレームを受信する段階と、フレーム内のペイロードが格納される断片を含むことを判定する段階と、ハッシュ関数を使用してペイロードの鍵を生成する段階と、ノードにデータを格納する段階と、データ識別子を作成するために鍵の前にノードIDを追加する段階と、ローカルストアにデータ識別子を格納する段階と、を含む。
実施例399は、実施例394から398のいずれかの主題を含む。実施例399では、本方法は、IoTデバイスからフレームを受信する段階と、フレーム内のペイロードが上流のデバイスに送信される断片を含むことを判定する段階と、フレームを上流のデバイスに送信する段階と、を含む。
実施例400は、実施例394から399のいずれかの主題を含む。実施例400では、本方法は、フレームからペイロードを抽出する段階と、ペイロードを新しいフレームにパッケージ化する段階と、新しいフレームを上流のデバイスに送信する段階と、を含む。
実施例401は、実施例394から400のいずれかの主題を含む。実施例401では、本方法は、フレームをセグメントに断片化する段階と、セグメントを複数の新しいフレームのそれぞれのペイロードフィールドにパックする段階と、複数の新しいフレームを上流のデバイスに送信する段階と、を含む。
実施例402は、実施例394から401のいずれかの主題を含む。実施例402では、本方法は、上流のデバイスからフレームの送信の確認応答を受信する段階と、確認応答をIoTデバイスに転送する段階と、を含む。
実施例403は、実施例394から402のいずれかの主題を含む。実施例403では、本方法は、近隣IoTデバイスからIoTデバイスにおいて受信された確認応答の速度を監視する段階と、確認応答の速度に少なくとも部分的に基づいてフレームを送信する速度を制御する段階と、を含む。
実施例404は、実施例394から403のいずれかの主題を含む。実施例404では、本方法は、隣接IoTデバイスに送信されたフレームについて確認応答が受信されなかったと判定する段階と、フレームを異なる近隣IoTデバイスに再送信する段階と、近隣IoTデバイスを潜在的に不良としてマークする段階と、を含む。
実施例405は、非一時的機械可読媒体を含む。非一時的機械可読媒体は、実行されると、データを断片にセグメント化し、各断片のハッシュコードを計算し、断片のターゲットノードを識別し、その断片をターゲットノードに送信するように1つまたは複数のプロセッサに指示する命令を含む。
実施例406は、実施例405の主題を含む。実施例406では、非一時的機械可読媒体は、実行されると、ターゲットノードを識別するためにハッシュコードを複数のノードのノードIDと比較するように1つまたは複数のプロセッサに指示する命令を含む。
実施例407は、実施例405または406のいずれかの主題を含む。実施例407では、非一時的機械可読媒体は、実行されると、ノードのノードIDを計算し、そのノードIDを複数のノードと共有するように1つまたは複数のプロセッサに指示する命令を含む。
実施例408は、実施例405から407のいずれかの主題を含む。実施例408では、非一時的機械可読媒体は、実行されると、断片を受信し、断片の鍵を計算し、鍵および断片を格納するように1つまたは複数のプロセッサに指示する命令を含む。
実施例409は、実施例405から408のいずれかの主題を含む。実施例409では、非一時的機械可読媒体は、実行されると、断片を受信し、断片を上流のデバイスに送信するように1つまたは複数のプロセッサに指示する命令を含む。
実施例410は、実施例405から409のいずれかの主題を含む。実施例410では、非一時的機械可読媒体は、実行されると、上流のデバイスから確認応答を受信し、その確認応答を断片を送信したデバイスに転送するように1つまたは複数のプロセッサに指示する命令を含む。
実施例411は、装置を含む。装置は、モノのインターネット(IoT)ネットワークを含み、IoTネットワークは、IoTデバイスを含む。IoTデバイスは、複数の通信チャネルを提供する複数の通信デバイスと、複数の通信チャネルのうちどれがターゲットエンドポイントと通信しているかを識別する経路発見部と、ターゲットエンドポイントと通信している複数の通信チャネルをランク付けする経路ランク付け部と、ランキングを格納するための経路データベースと、を含む。
実施例412は、実施例411の主題を含む。実施例412では、本装置は、IoTデバイスからターゲットエンドポイントまでの経路を選択するための経路計算機を含み、経路は通信チャネルを含む。
実施例413は、実施例411または412のいずれかの主題を含む。実施例413では、経路は少なくとも部分的にランキングに基づいて選択される。
実施例414は、実施例411から413のいずれかの主題を含む。実施例414では、経路は少なくとも部分的にアプリケーションに基づいて選択される。
実施例415は、実施例411から414のいずれかの主題を含む。実施例415では、本装置は、通信チャネルを介した送信のために通信パケットを準備するためのパケット準備部を含む。
実施例416は、実施例411から415のいずれかの主題を含む。実施例416では、パケット準備部は、通信チャネルを介して送信されるデータを断片化する。
実施例417は、実施例411から416のいずれかの主題を含む。実施例417では、パケット準備部は、送信されるデータを通信チャネルのプロトコルのフレームにパッケージ化する。
実施例418は、実施例411から417のいずれかの主題を含む。実施例418では、本装置は、通信チャネルを介してデータを送信するための通信部を含む。
実施例419は、実施例411から418のいずれかの主題を含む。実施例419では、通信部は、2つ以上の通信チャネルを介してデータの一部を並列に送信する。
実施例420は、実施例411から419のいずれかの主題を含む。実施例420では、本装置は、ターゲットエンドポイントと通信している複数の通信チャネルのそれぞれについて性能統計を追跡するための性能モニタを含み、性能モニタは、性能統計に少なくとも部分的に基づいてランキングを更新する。
実施例421は、モノのインターネット(IoT)デバイスからターゲットエンドポイントへの通信チャネルを選択するための方法を含む。モノのインターネット(IoT)デバイスからターゲットエンドポイントへの通信チャネルを選択するための方法は、ターゲットエンドポイントへの1つまたは複数の利用可能な経路を含む経路指定戦略を計算する段階と、経路指定戦略で識別された利用可能な経路にわたるディスパッチのためのデータを準備する段階と、データをディスパッチする段階と、ディスパッチに使用される利用可能な経路に関する性能統計を収集する段階と、性能統計に少なくとも部分的に基づいて利用可能な経路のランキングを更新する段階と、を含む。
実施例422は、実施例421の主題を含む。実施例422では、経路指定戦略を計算する段階は、単一の経路が使用されるべきであると判定する段階と、使用されるべき単一の経路を選択する段階と、を含む。
実施例423は、実施例421または422のいずれかの主題を含む。実施例423では、経路指定戦略を計算する段階は、複数の経路が使用されるべきであると判定する段階と、使用されるべき複数の経路を選択する段階と、を含む。
実施例424は、実施例421から423のいずれかの主題を含む。実施例424では、ディスパッチのためにデータを準備する段階は、データをペイロードに断片化する段階と、ペイロードをパケットにパッケージ化する段階と、パケットを経路に割り当てる段階と、を含む。
実施例425は、実施例421から424のいずれかの主題を含む。実施例425では、本方法は、経路に基づいてペイロードをフレームにパッケージ化する段階を含む。
実施例426は、実施例421から425のいずれかの主題を含む。実施例426では、データをディスパッチする段階は、単一の利用可能な経路を介してパケットを送信する段階を含む。
実施例427は、実施例421から426のいずれかの主題を含む。実施例427では、データをディスパッチする段階は、複数の経路を介してパケットを送信する段階を含む。
実施例428は、実施例421から427のいずれかの主題を含む。実施例428では、性能統計を収集する段階は、データ配信ステータスを監視する段階、経路の信頼性を判定する段階、経路ごとに転送された総データを測定する段階、またはそれらの任意の組み合わせを含む。
実施例429は、実施例421から428のいずれかの主題を含む。実施例429では、本方法は、IoTデバイス内のネットワークインターフェースを発見する段階と、ネットワークインターフェースを介してターゲットエンドポイントへの利用可能な経路を発見する段階と、ターゲットエンドポイントまでの利用可能な経路をランク付けする段階と、を含む。
実施例430は、実施例421から429のいずれかの主題を含む。実施例430では、ネットワークインターフェースを発見する段階は、構成コマンドを通してインターフェースのリストにアクセスする段階を含む。
実施例431は、実施例421から430のいずれかの主題を含む。実施例431では、利用可能な経路を発見する段階は、ターゲットエンドポイントへの論理チャネルを発見する段階を含む。
実施例432は、実施例421から431のいずれかの主題を含む。実施例432では、利用可能な経路を発見する段階は、ターゲットエンドポイントへの以前のアクティブな経路を取得する段階を含む。
実施例433は、実施例421から432のいずれかの主題を含む。実施例433では、利用可能な経路を発見する段階は、ネットワークインターフェースを介してターゲットエンドポイントへの論理チャネルを確立することを試みる段階を含む。
実施例434は、非一時的機械可読媒体を含む。非一時的機械可読媒体は、実行されると、ネットワークインターフェースを発見し、利用可能な経路を発見し、経路指定戦略を計算し、経路指定戦略に従ってパケットをディスパッチするようにプロセッサに指示する命令を含む。
実施例435は、実施例434の主題を含む。実施例435では、非一時的機械可読媒体は、データを断片化してパケットのペイロードを形成することによって、ディスパッチのためにパケットを準備することを含む。
実施例436は、実施例434または435のいずれかの主題を含む。実施例436では、非一時的機械可読媒体は、経路指定戦略で使用された経路に関する性能統計を収集することを含む。
実施例437は、実施例436から436のいずれかの主題を含む。実施例437では、非一時的機械可読媒体は、性能統計に少なくとも部分的に基づいて、利用可能な経路のランキングを更新することを含む。
実施例438は、装置を含む。本装置は、モノのインターネット(IoT)ネットワークを含み、IoTネットワークは、IoTゲートウェイを含む。IoTゲートウェイは、第1プロトコルにおける第1セキュリティレベルでの通信を含む第1ドメインへの通信インターフェースと、第2プロトコルにおける第2セキュリティレベルでの通信を含む第2ドメインへの通信インターフェースと、第1のプロトコルと第2のプロトコルとの間でペイロードを変換するためのペイロードを変換するためのプロトコル変換部と、第1のプロトコルと第2のプロトコルとの間でペイロードを変換するためのセキュリティ変換部と、を含む。
実施例439は、実施例438の主題を含む。実施例439では、本装置は、イングレスデータのセマンティック表現をエグレスデータで使用されるセマンティック表現に変換するためのセマンティック変換部を含む。
実施例440は、実施例438または439のいずれかの主題を含む。実施例440では、装置は、セマンティック変換部がイングレスデータ内のペイロードのセマンティック表現をエグレスデータ内で使用されるセマンティック表現に変換することを可能にするためのセマンティック変換部プラグインを含む。
実施例441は、実施例438から440のいずれかの主題を含む。実施例441では、装置は、セマンティック変換部がイングレスデータ内のペイロードのセマンティック表現を中間のセマンティック表現に変換することを可能にするための第1のセマンティックプラグインを含む。
実施例442は、実施例438から441のいずれかの主題を含む。実施例442では、本装置は、セマンティック変換部がイングレスデータ内のペイロードのセマンティック表現を、中間のセマンティック表現からエグレスデータ内で使用されるセマンティック表現に変換することを可能にするための第2のセマンティック変換部プラグインを含む。
実施例443は、実施例438から442のいずれかの主題を含む。実施例443では、本装置は、イングレスフォーマットをエグレスフォーマットに変換するための複数の変換部を含むトラステッド実行環境を含む。
実施例444は、実施例438から443のいずれかの主題を含む。実施例444では、本装置は、トラステッド実行環境をサポートするためのトラステッドプラットフォームモジュールを含む。
実施例445は、実施例438から444のいずれかの主題を含む。実施例445では、本装置は、プロトコル変換部がペイロードからイングレスプロトコルを取り外しできるようにするための第1のプロトコルプラグインを含む。
実施例446は、実施例438から445のいずれかの主題を含む。実施例446では、本装置は、プロトコル変換部がエグレスプロトコル内にペイロードをパッケージ化することを可能にするための第2のプロトコルプラグインを含む。
実施例447は、実施例438から446のいずれかの主題を含む。実施例447では、本装置は、セキュリティ変換部がイングレスセキュリティレベルで暗号化されたペイロードを復号できるようにするための第1のセキュリティプラグインを含む。
実施例448は、実施例438から447のいずれかの主題を含む。実施例448では、本装置は、セキュリティ変換部がエグレスセキュリティレベルのペイロードを暗号化できるようにするための第2のセキュリティプラグインを含む。
実施例449は、実施例438から448のいずれかの主題を含む。実施例449では、本装置は、イングレスペイロードとエグレスペイロードとの間に許容されるセキュリティレベル差を制御するためのセキュリティ変換ポリシーを含むセキュアなデータストアを含む。
実施例450は、実施例438から449のいずれかの主題を含む。実施例450では、本装置は、プラグインをコンパイルするためのスクリプトコンパイラを含むセキュアなデータストアを含む。
実施例451は、実施例438から450のいずれかの主題を含む。実施例451では、本装置は、プラグインインストーラを含むセキュアなデータストアを含む。
実施例452は、モノのインターネット(IoT)ゲートウェイにおいてドメイン間の通信を変換するための方法を含む。モノのインターネット(IoT)ゲートウェイにおいてドメイン間の通信を変換するための方法は、第1のドメインからイングレスプロトコルのペイロードを受信する段階と、イングレスプロトコルからペイロードを取り外す段階と、イングレスセキュリティレベルからペイロードを復号する段階と、ペイロードが暗号化されている場合、イングレスセマンティック表現と異なる場合は、ペイロードをイングレスセマンティック表現からエグレスセマンティック表現に変換する段階と、を含む。本方法はまた、セキュリティポリシーによって必要とされる場合、エグレスセキュリティレベルでペイロードを暗号化する段階と、ペイロードをエグレスプロトコルにパックする段階と、ペイロードを第2のドメインで送信する段階と、を含む。
実施例453は、実施例452の主題を含む。実施例453では、本方法は、ペイロードをイングレスプロトコルから取り外す段階の後、ペイロードがバイオメトリックによって保護されているか否かを判定する段階と、そうであれば、コンテンツについてバイオメトリックを分析する段階と、を含む。
実施例454は、実施例452または453のいずれかの主題を含む。実施例454では、本方法は、ペイロードを暗号化する段階の後、バイオメトリックのシミュレーションでペイロードを保護する段階を含む。
実施例455は、実施例452から454のいずれかの主題を含む。実施例455では、本方法は、ペイロードをイングレスプロトコルから取り外す段階の後、ペイロードがプライバシーセンシティブであるか否かを判定する段階と、そうである場合、コンテンツについてペイロードを分析するためにプライバシーポリシーを適用する段階と、を含む。
実施例456は、実施例452から455のいずれかの主題を含む。実施例456では、本方法は、ペイロードを暗号化する段階の後、ペイロードを保護するためにプライバシーポリシーを適用する段階を含む。
実施例457は、実施例452から456のいずれかの主題を含む。実施例457では、本方法は、第1のドメインと第2のドメインとの間の通信の変換を可能にするために複数のプラグインを識別する段階と、複数のプラグインのそれぞれを、有効なプラグインであることを判定するために確認する段階と、各有効なプラグインはIoTゲートウェイと互換性があるか否かを判定する段階と、そうであれば、有効な各プラグインをインストールする段階と、を含む。
実施例458は、実施例452から457のいずれかの主題を含む。実施例458では、本方法は、プラグインが実行する変換を加速するためにプラグインをコンパイルする段階を含む。
実施例459は、実施例452から458のいずれかの主題を含む。実施例459では、本方法は、各有効なプラグインを変換用に構成する段階を含む。
実施例460は、非一時的機械可読媒体を含む。非一時的機械可読媒体は、実行されると、第1のドメインからイングレスデータを受信し、ペイロードを抽出するために、イングレスプロトコルの下でイングレスデータを処理し、イングレスセキュリティポリシーの下でペイロードを処理し、イングレスセマンティックフォーマットからエグレスセマンティックフォーマットへペイロードを変換し、エグレスセキュリティポリシーの下でペイロードを処理し、ペイロードをエグレスデータにパッケージ化するために、エグレスプロトコルの下でペイロードを処理し、エグレスデータを第2のドメインに送信するようにプロセッサに指示する命令を含む。
実施例461は、実施例460の主題を含む。実施例461では、非一時的機械可読媒体は、実行されると、コンテンツを分析するためにイングレスバイオメトリックポリシーの下でペイロードを処理し、コンテンツを保護するためにエグレスバイオメトリックポリシーの下でペイロードを処理するようにプロセッサに指示する命令を含む。
実施例462は、実施例460または461のいずれかの主題を含む。実施例462では、非一時的機械可読媒体は、実行されると、コンテンツを分析するためにイングレスプライバシーポリシーの下でペイロードを処理し、コンテンツを保護するためにエグレスプライバシーポリシーの下でペイロードを処理するようにプロセッサに指示する命令を含む。
実施例463は、実施例460から462のいずれかの主題を含む。実施例463では、非一時的機械可読媒体は、実行されると、ソフトウェア測定を実行し、ソフトウェア測定の結果を許容値と比較するようにプロセッサに指示する命令を含む。
実施例464は、実施例460から463のいずれかの主題を含む。実施例464では、非一時的機械可読媒体は、実行されると、プラグインを確認しプラグインをインストールするようにプロセッサに指示する命令を含む。
実施例465は、実施例460から464のいずれかの主題を含む。実施例465では、非一時的機械可読媒体は、実行されると、プラグインをコンパイルするようにプロセッサに指示する命令を含む。
実施例466は、装置を含む。装置は、モノのインターネット(IoT)ネットワークを含み、IoTネットワークは、IoTデバイスを含む。IoTデバイスは、ドメイン内の他のIoTデバイスと通信するための通信システムと、ドメイン内のデバイスを発見し、そのデバイス用のリソースを作成するためのオンボーディングツールと、リモートドメイン内に配置されたリモートオンボーディングツールによってサービスを受けるリモートデバイスを発見するためのデバイス発見部と、リモートオンボーディングツールとの信頼関係を確立するための信頼構築部と、リモートオンボーディングツールと共有ドメインを形成するための共有ドメイン作成部と、デバイスとリモートデバイスとの両方のリソースを格納する共有リソースディレクトリと、を含む。
実施例467は、実施例466の主題を含む。実施例467では、ドメイン内のデバイスは、第1のリソースブロック内のリソースによって表され、リモートドメイン内のリモートデバイスは、第2のリソースブロック内のリソースによって表され、仮想ドメインは、第3のリソースブロックを格納し、第3のリソースブロックは、第1のリソースブロックおよび第2のリソースブロックからのリソースを含む。
実施例468は、実施例466または467のいずれかの主題を含む。実施例468では、通信システムは、メッシュ送受信機、アップリンク送受信機、またはネットワークインターフェースコントローラ、あるいはそれらの任意の組み合わせを含む。
実施例469は、実施例466から468のいずれかの主題を含む。実施例469では、本装置は、フォグデバイスを形成する複数のドメイン内に複数のデバイスを含み、仮想ドメイン内の共通リソースブロックは複数のデバイスすべてに対するリソースを格納する。
実施例470は、実施例466から469のいずれかの主題を含む。実施例470では、本装置は、複数のリモートデバイスに関する情報をオンボーディングツールに提供するためのオーケストレータを含む。
実施例471は、実施例466から470のいずれかの主題を含む。実施例471では、信頼構築部は、アテステーション鍵、識別鍵、または管理者からの割り当てられた信頼、またはそれらの任意の組み合わせを含む。
実施例472は、実施例466から471のいずれかの主題を含む。実施例472では、トラスト構築部は、ブロックチェーンのルートオブトラストを形成するためのブロックチェーンシステムを含む。
実施例473は、ドメイン間でリソースを共有するための方法を含む。ドメインにわたってリソースを共有するための方法は、第1ドメインにおいてデバイスをIoTネットワークに参加させる段階と、第1ドメイン内のデバイスのためのリソースをローカルリソースブロックに追加する段階と、リモートドメイン内のリモートデバイスを発見する段階と、リモートドメインとの信頼を形成する段階と、デバイスおよびリモートデバイスのリソースを含む共有リソースブロックを作成する段階と、を含む。
実施例474は、実施例473の主題を含む。実施例474では、本方法は、まだ存在していない場合は、ローカルリソースブロックを作成する段階を含む。
実施例475は、実施例473または474のいずれかの主題を含む。実施例475では、リモートデバイスを発見する段階は、リモートデバイスに関する情報をオーケストレータから受信する段階を含む。
実施例476は、実施例473から475のいずれかの主題を含む。実施例476では、リモートデバイスを発見する段階は、リモートドメイン内でオンボーディングツールを発見する段階と、リモートドメイン内のオンボーディングツールとデバイス情報を交換する段階と、を含む。
実施例477は、実施例473から476のいずれかの主題を含む。実施例477では、リモートデバイスとの信頼を形成する段階は、リモートデバイスとアテステーション情報を交換する段階を含む。
実施例478は、実施例473から477のいずれかの主題を含む。実施例478では、リモートデバイスとの信頼を形成する段階は、リモートデバイスをブロックチェーンでルックアップする段階を含む。
実施例479は、実施例473から478のいずれかの主題を含む。実施例479では、リモートデバイスと信頼関係を形成する段階は、管理者からの割り当てられた信頼設定を受け入れる段階を含む。
実施例480は、実施例473から479のいずれかの主題を含む。実施例480では、本方法は、サブドメインIDが共有リソースブロック内の前のサブドメインIDと一致する場合にサブドメインIDの名前を変更する段階と、そのサブドメインIDを使用するすべてのデバイスに新しいサブドメインIDを伝播する段階と、を含む。
実施例481は、実施例473から480のいずれかの主題を含む。実施例481では、本方法は、オブジェクトIDが共有リソースブロック内の前のオブジェクトIDと一致する場合にオブジェクトIDの名前を変更する段階と、そのオブジェクトIDを使用するすべてのデバイスに新しいオブジェクトIDを伝播する段階と、を含む。
実施例482は、実施例473から481のいずれかの主題を含む。実施例482では、本方法は、デバイスIDが共有リソースブロック内の前のデバイスIDと一致する場合にデバイスIDの名前を変更する段階と、そのデバイスIDを使用するすべてのデバイスに新しいデバイスIDを伝播する段階と、を含む。
実施例483は、実施例473から482のいずれかの主題を含む。実施例483では、本方法は、第1のドメインからリモートデバイスのリソースにアクセスする段階を含む。
実施例484は、実施例473から483のいずれかの主題を含む。実施例484では、共有リソースブロックを作成する段階は、ローカルリソースブロックとリモートリソースブロックとの間に共用体を形成する段階を含む。
実施例485は、非一時的機械可読媒体を含む。非一時的機械可読媒体は、実行されると、デバイスをIoTネットワークに参加させ、ローカルリソースブロック内にデバイスのローカルリソースを作成し、他のドメイン内のデバイスを発見し、共有ドメインを作成し、共有ドメイン内に共有リソースブロックを作成し、共有リソースブロック内の他のドメインにあるデバイスのローカルリソースとリモートリソースとをマージするようにプロセッサに指示する命令を含む。
実施例486は、実施例485の主題を含む。実施例486では、非一時的機械可読媒体は、実行されると、リモートドメイン内のオンボーディングツールを発見し、リモートドメイン内のオンボーディングツールとの信頼を築き、ローカルドメインおよびリモートドメインの複数のデバイスに関する情報を交換するようにプロセッサに指示する命令を含む。
実施例487は、実施例485または486のいずれかの主題を含む。実施例487では、非一時的機械可読媒体は、実行されると、リモートドメイン内のオンボーディングツールを発見し、リモートドメイン内のオンボーディングツールを確認するためにブロックチェーンにアクセスするようにプロセッサに指示する命令を含む。
実施例488は、実施例485から487のいずれかの主題を含む。実施例488では、非一時的機械可読媒体は、実行されると、共用リソースブロック内の名前の重複を検出し、重複するエントリを新しい名前に変更することによって名前の重複を修正し、新しい名前を、その名前を使用するすべてのデバイスに伝播するようにプロセッサに指示する命令を含む。
実施例489は、実施例485から488のいずれかの主題を含む。実施例489では、非一時的機械可読媒体は、実行されると、ローカルドメイン内のデバイスとリモートドメイン内のリモートデバイスとを含むフォグデバイスを形成するようにプロセッサに指示する命令を含む。
実施例490は、装置を含む。本装置は、モノのインターネット(IoT)ネットワークを含み、IoTネットワークは、製品の製造プロセスのステージのための記録鍵を生成する記録鍵生成部、IoTデバイスによってステージのために収集された記録鍵および関連データを保存するためのプライベートストア通信部と、パブリックストアと通信して記録鍵をパブリックストアに保存するパブリックストア通信部と、を含むIoTデバイスを含む。
実施例491は、実施例490の主題を含む。実施例491では、記録鍵生成部は、分散型台帳から記録鍵を取得する。
実施例492は、実施例490または491のいずれかの主題を含む。実施例492では、記録鍵生成部は、中央管理者から記録鍵を発行される。
実施例493は、実施例490から492のいずれかの主題を含む。実施例493では、本装置は、ステージの記録鍵を保存するための記録鍵ストアを含む。
実施例494は、実施例490から493のいずれかの主題を含む。実施例494では、記録鍵ストアは、付加された記録鍵を格納し、付加された記録鍵は生産プロセスの前のステージの記録鍵に追加された生産プロセスのステージの記録鍵を含む。
実施例495は、実施例490から494のいずれかの主題を含む。実施例495では、パブリックストア通信部は、すべてのステージについて付加された記録鍵をパブリックストアに保存する。
実施例496は、実施例490から495のいずれかの主題を含む。実施例496では、本装置は、インターフェースを介してセンサを監視し、そのデータを記録鍵と関連付けるためのデータモニタを含む。
実施例497は、実施例490から496のいずれかの主題を含む。実施例497では、センサは、温度センサ、衝撃センサ、もしくは全地球測位システム、またはそれらの任意の組み合わせを含む。
実施例498は、実施例490から497のいずれかの主題を含む。実施例498では、本装置は、通過中の制限に違反した場合に警告指示を起動するための警告部を含む。
実施例499は、実施例490から498のいずれかの主題を含む。実施例499では、通過中の制限は、温度制限、衝撃制限、光の制限、またはそれらの任意の組み合わせを含む。
実施例500は、実施例490から499のいずれかの主題を含む。実施例500では、警告は、照明用のアクチュエータ、音発生器、またはその両方を含む。
実施例501は、実施例490から500のいずれかの主題を含む。実施例501では、警告は、メッシュ送受信機、アップリンク送受信機、またはその両方を介して送信されたメッセージを含む。
実施例502は、モノのインターネット(IoT)デバイスを使用してトレーサビリティシステムを実施するための方法を含む。モノのインターネット(IoT)デバイスを使用してトレーサビリティシステムを実施するための方法は、IoTデバイスにおいて製品の製品出荷鍵を受信する段階であって、IoTデバイスが製品と共にある、段階と、IoTデバイスにおいて製品の加工鍵を受信する段階と、IoTデバイスにおいて加工された製品の加工された製品出荷鍵を受信する段階と、IoTデバイスにおいて加工された製品に対する販売場所鍵を受信する段階と、製品出荷鍵、加工鍵、加工された製品出荷鍵、販売場所鍵を含む添付鍵をIoTデバイスからパブリックデータストアへ送信する段階と、を含む。
実施例503は、実施例502の主題を含む。実施例503では、本方法は、製品の製造プロセスに関するデータを収集する段階と、製造プロセスに関するデータを製造店舗に格納する段階と、製造プロセスに関するデータに関連付けられた製造データ鍵を生成する段階と、製造データ鍵をIoTデバイスに保存する段階と、を含む。
実施例504は、実施例502または503のいずれかの主題を含む。実施例504では、IoTデバイスを製品と関連付ける段階は、IoTデバイスを製品パッケージに取り付ける段階を含む。
実施例505は、実施例502から504のいずれかの主題を含む。実施例505では、本方法は、製品の出荷に関する出荷データを収集する段階と、出荷データを出荷ストアに格納する段階と、製品出荷鍵を生成する段階と、出荷鍵を出荷ストア内の出荷データに関連付ける段階と、を含む。
実施例506は、実施例502から505のいずれかの主題を含む。実施例506では、製品の出荷に関するデータは、温度測定値、G力測定値、もしくは位置座標、またはそれらの任意の組み合わせを含む。
実施例507は、実施例502から506のいずれかの主題を含む。実施例507では、本方法は、加工された製品を形成するために、製品の加工に関する加工データを収集する段階と、製品の加工に関する加工データを加工ストアに格納する段階と、加工鍵を生成する段階と、加工ストアにおいて加工鍵を加工データに関連付ける段階と、を含む。
実施例508は、実施例502から506のいずれかの主題を含む。実施例508では、加工された製品を形成するための製品の加工は、製品を倉庫において梱包することを含む。
実施例509は、実施例502から508のいずれかの主題を含む。実施例509では、本方法は、加工された製品の出荷に関する加工された製品の出荷データを収集する段階と、加工された製品に関する出荷データを加工ストアに格納する段階と、加工された製品出荷鍵を生成する段階と、加工ストアにおいて加工された製品出荷鍵を出荷データに関連付ける段階と、を含む。
実施例510は、実施例502から509のいずれかの主題を含む。実施例510では、本方法は、販売場所における加工された製品の販売場所データを収集する段階と、加工された製品に関する販売場所データを販売ストアに格納する捨て婦と、販売場所鍵を生成する段階と、販売ストア内の販売場所データを販売場所鍵に関連付ける段階と、を含む。
実施例511は、実施例502から510のいずれかの主題を含む。実施例511では、IoTデバイスからパブリックデータストアへの各鍵の送信は、IoTデバイスに関連する製品が販売されたときに行われる。
実施例512は、実施例502から511のいずれかの主題を含む。実施例512では、本方法は、IoTデバイスからデータを消去する段階と、IoTデバイスを生産施設に返却して新しい製品と関連付ける段階と、を含む。
実施例513は、実施例502から512のいずれかの主題を含む。実施例513では、本方法は、製品包装に関連する情報に少なくとも部分的に基づいてトレーサビリティハッシュをルックアップする段階と、トレーサビリティハッシュに少なくとも部分的に基づいてパブリックストアで鍵をルックアップする段階と、パブリックストアからの鍵に少なくとも部分的に基づいてプライベートストア内の情報にアクセスする段階と、を含む。
実施例514は、非一時的機械可読媒体を含む。非一時的機械可読媒体は、実行されると、IoTデバイス内の加工ステージのデータを記録し、IoTデバイスからプライベートストアにデータを通信し、IoTデバイスにおいてそのステージのための記録鍵を生成し、IoTデバイスからプライベートストアに記録鍵を通信するようにプロセッサに指示する命令を含む。
実施例515は、実施例514の主題を含む。実施例515では、非一時的機械可読媒体は、実行されると、前のステージのために生成された鍵に記録鍵を付加して、付加された鍵を生成するようにプロセッサに指示する命令を含む。
実施例516は、実施例514または515のいずれかの主題を含む。実施例516では、非一時的機械可読媒体は、実行されると、付加された鍵をパブリックストアに送信するようにプロセッサに指示する命令を含む。
実施例517は、実施例514から516のいずれかの主題を含む。実施例517では、非一時的機械可読媒体は、実行されると、データ制限に違反した場合に警報を起動するようにプロセッサに指示する命令を含む。
実施例518は、装置を含む。装置は、モノのインターネット(IoT)ネットワークを含み、IoTネットワークは、IoTデバイスを含む。IoTデバイスは、IoTネットワーク内の他のIoTデバイスと通信するための通信システムと、施行されるポリシーを判定するためのポリシー決定エンジンと、ポリシーおよびネットワークモニタによって報告された状態情報を格納するためのポリシーリポジトリと、ポリシー決定エンジンによって判定されたポリシーを施行するためのポリシー施行エンジンと、IoTデバイスによって、およびIoTネットワーク内の他のIoTデバイスによって施行されたポリシーを監視するためのピアモニタと、を含む。
実施例519は、実施例518の主題を含む。実施例519では、通信システムは、メッシュ送受信機、アップリンク送受信機、またはネットワークインターフェースコントローラ、あるいはそれらの任意の組み合わせを含む。
実施例520は、実施例518または519のいずれかの主題を含む。実施例520では、IoTネットワークは、フォグデバイスを形成する複数のデバイスを含む。
実施例521は、実施例518から520のいずれかの主題を含む。実施例521では、ポリシー決定エンジンは、IoTデバイスのためのパラメータに基づいて、どのポリシーが施行されるかを判定する。
実施例522は、実施例518から521のいずれかの主題を含む。実施例522では、パラメータは、IoTデバイス内のバッテリの残容量、メッシュ送受信機を介して結合された他のIoTデバイス、またはクラウド内のデバイスへのアップリンク送受信機のステータス、あるいはそれらの任意の組み合わせを含む。
実施例523は、実施例518から522のいずれかの主題を含む。実施例523では、ポリシー決定エンジンは、パラメータの変更に少なくとも部分的に基づいて、施行されているポリシーを変更する。
実施例524は、実施例518から523のいずれかの主題を含む。実施例524では、ポリシー決定エンジンは、ポリシーを未構成ノードに配布する。
実施例525は、実施例518から524のいずれかの主題を含む。実施例525では、ピアモニタは、情報を収集し、それをデータベースに格納する。
実施例526は、実施例518から525のいずれかの主題を含む。実施例526では、情報は、現在のデバイス構成、ピアノードの能力、提供されているサービス、ネットワークに対するノード要件、リソース利用可能性推定、またはトリガイベント、あるいはそれらの任意の組み合わせを含む。
実施例527は、実施例518から526のいずれかの主題を含む。実施例527では、本装置は、IoTネットワーク内のピアノードにポリシーを配信するためのコーディネータを含む。
実施例528は、実施例518から527のいずれかの主題を含む。実施例528では、コーディネータは、IoTネットワークとクラウドデバイスとの間のゲートウェイを含む。
実施例529は、実施例518から528のいずれかの主題を含む。実施例529では、IoTデバイスは、最も近い近接ノードにポリシーを配布する。
実施例530は、実施例518から529のいずれかの主題を含む。実施例530では、ポリシー決定エンジンは、ポリシーにアクセスするためにピアノードと通信する。
実施例531は、IoTネットワーク内のIoTデバイスにわたってポリシー管理を分散させるための方法を含む。IoTネットワーク内のIoTデバイスにポリシー管理を分散するための方法は、ノードで発見メッセージを受信する段階であって、発見メッセージは、新しいポリシーを識別する、ポリシーを変更すること、またはその両方を意図されている、段階と、オファーメッセージで発見メッセ以上に応答する段階であって、オファーメッセージは、ポリシーを識別する、段階と、承認メッセージを受信する段階であって、承認メッセージはポリシーを要求する、段階と、ポリシーを含むメッセージで応答する段階と、を含む。
実施例532は、実施例531の主題を含む。実施例532では、本方法は、ピアノードから受信したポリシーをインストールする段階と、ステータスを構成済みノードに更新する段階と、を含む。
実施例533は、実施例531または532のいずれかの主題を含む。実施例533では、本方法は、更新メッセージで更新されたポリシーを受信する段階を含む。
実施例534は、実施例531から533のいずれかの主題を含む。実施例534では、本方法は、更新メッセージにおいて受信された更新されたポリシーに対して確認を実行する段階と、更新されたポリシーをインストールする段階と、を含む。
実施例535は、実施例531から534のいずれかの主題を含む。実施例535では、確認は、新しいポリシーが現在のポリシーと競合するか否かを判定する段階と、そうであれば、新しいポリシーを拒否する段階と、を含む。
実施例536は、実施例531から535のいずれかの主題を含む。実施例536では、確認は、新しいポリシーが現在のポリシーと競合するか否かを判定する段階と、そうであれば、新しいポリシーを部分的に実施する段階と、を含む。
実施例537は、実施例531から536のいずれかの主題を含む。実施例537では、本方法は、ピアノードにポリシーの競合を警告するために、競合警告メッセージをピアノードに送信する段階を含む。
実施例538は、実施例531から537のいずれかの主題を含む。実施例538では、本方法は、ポリシー更新のためにピアノードから発見メッセージを受信する段階と、オファーメッセージで返信する段階と、ポリシー更新が送信され得ることを示すためにピアノードから受諾メッセージを受信する段階と、新しいポリシーを含む更新メッセージを送信する段階と、を含む。
実施例539は、実施例531から538のいずれかの主題を含む。実施例539では、本方法は、更新メッセージにおいて受信された更新されたポリシーに対して確認を実行する段階と、更新されたポリシーをインストールする段階と、を含む。
実施例540は、実施例531から539のいずれかの主題を含む。実施例540では、本方法は、現在のポリシーと新しいポリシーとの間のデルタを含むファイルを生成する段階と、ファイルをピアノードに送信する段階と、を含む。
実施例541は、実施例531から540のいずれかの主題を含む。実施例541では、本方法は、ピアノードがポリシーのためのハードウェア容量を有するか否かを判定する段階と、ピアノードのハードウェア容量と一致するようにポリシーを修正する段階と、修正されたポリシーをピアノードに送信する段階と、を含む。
実施例542は、実施例531から541のいずれかの主題を含む。実施例542では、本方法は、新しいポリシーと現在のポリシーとの間の変更を判定する段階と、ポリシーにおける変更をピアノードに送信する段階と、を含む。
実施例543は、非一時的機械可読媒体を含む。非一時的機械可読媒体は、実行されると、他のノード内のポリシーを発見し、IoTネットワーク内の他のノードによって送信されたメッセージからポリシーを更新するようにプロセッサに指示するようにプロセッサに指示する命令を含む。
実施例544は、実施例543の主題を含む。実施例544では、非一時的機械可読媒体は、実行されると、複数のノードからのポリシーを連結するようにプロセッサに指示する命令を含む。
実施例545は、実施例543または544のいずれかの主題を含む。実施例545では、非一時的機械可読媒体は、実行されると、他のノードからのメッセージで受信されたポリシーを確認し、グループ目的と競合するポリシーを拒否するようにプロセッサに指示する命令を含む。
実施例546は、実施例543から545のいずれかの主題を含む。実施例546では、非一時的機械可読媒体は、実行されると、現在のデバイス条件に一致するように実装されたポリシーを変更するようにプロセッサに指示する命令を含む。
実施例547は、実施例543から546のいずれかの主題を含む。実施例547では、非一時的機械可読媒体は、実行されると、ポリシー間のデルタを計算するようにプロセッサに指示する命令を含む。
実施例548は、装置を含む。装置は、モノのインターネット(IoT)ネットワークを含み、IoTネットワークは、電源プラグデバイスを含む。電源プラグデバイスは、電源プラグデバイス内の回路に電力を供給するための電源と、外部IoTデバイスに電力を供給するための電力コントローラと、外部IoTデバイスに問い合わせて外部IoTデバイスに障害が発生したか否かを判定するためのインターフェースであって、外部IoTデバイスに障害が発生した場合、電源プラグデバイスが電源コントローラを介して外部IoTデバイスへの電源を入れ直す、インターフェースと、を含む。
実施例549は、実施例548の主題を含む。実施例549では、インターフェースは、データ交換、電力供給、またはその両方のために外部IoTデバイスとインターフェースをとるためのネットワークインターフェースコントローラを含む。
実施例550は、実施例548または549のいずれかの主題を含む。実施例550では、インターフェースは、データ交換、電力供給、またはその両方のために外部IoTデバイスとインターフェースをとるためのユニバーサルシリアルバスを含む。
実施例551は、実施例548から550のいずれかの主題を含む。実施例551では、インターフェースは、動作の監視、パワーリセット機能の実行、または不揮発性メモリのリモートフラッシュ、あるいはそれらの任意の組み合わせのために外部IoTデバイスとインターフェースをとるためのJTAGインターフェースを含む。
実施例552は、実施例548から551のいずれかの主題を含む。実施例552では、インターフェースは、シリアルペリフェラルインターフェース(SPI)バス、I2Cバス、もしくはI3Cバス、またはそれらの任意の組み合わせのためのインターフェースを含む。
実施例553は、実施例548から552のいずれかの主題を含む。実施例553では、電源プラグデバイスは、センサとインターフェースをとるためのHIDトランスポートインターフェースを含む。
実施例554は、実施例548から553のいずれかの主題を含む。実施例554では、センサは、周囲温度センサ、湿度センサ、近接センサ、もしくは在否センサ、またはそれらの任意の組み合わせを含む。
実施例555は、実施例548から554のいずれかの主題を含む。実施例555では、本装置は、電源プラグデバイスのためのトラステッド実行環境(TEE)を確立するためのトラステッドプラットフォームモジュールを含む。
実施例556は、実施例548から555のいずれかの主題を含む。実施例556では、本装置は、外部IoTデバイスの動作を監視するためのモニタを含む。
実施例557は、実施例548から556のいずれかの主題を含む。実施例557では、本装置は、電力制御を使用して外部IoTデバイスの電源を入れ直すためのアクチュエータを含む。
実施例558は、実施例548から557のいずれかの主題を含む。実施例558では、本装置は、メッシュ送受信機、アップリンク送受信機、またはネットワークインターフェースコントローラ、あるいはそれらの任意の組み合わせを含む通信システムを含む。
実施例559は、実施例558から558のいずれかの主題を含む。実施例559では、本装置は、通信システムを通して外部IoTデバイスの状態を報告するための報告部を含む。
実施例560は、実施例548から559のいずれかの主題を含む。実施例560では、本装置は、電源プラグデバイスと通信する複数のIoTデバイスを含み、電源プラグデバイスは、電源プラグデバイスと通信する複数のIoTデバイスのそれぞれのステータスを報告する。
実施例561は、電源プラグデバイスを使用してモノのインターネット(IoT)デバイスの可用性を向上させるための方法を含む。電源プラグデバイスを使用してモノのインターネット(IoT)デバイスの利用可能性を向上させるための方法は、管理対象のIoTデバイスのリストを発見する段階と、電源プラグデバイスを初期化する段階と、IoTデバイスを監視する段階と、IoTデバイスのステータスを報告する段階と、IoTデバイスに障害が発生した場合に動作を復旧するための措置をとる段階と、を含む。
実施例562は、実施例561の主題を含む。実施例562では、管理対象のIoTデバイスのリストを発見する段階は、電源プラグデバイスに接続された物理的パスをエニュメレーションする段階と、物理的に接続されているものを判定するために物理的パスのそれぞれを問い合わせる段階と、を含む。
実施例563は、実施例561または562のいずれかの主題を含む。実施例563では、管理対象のIoTデバイスのリストを発見する段階は、管理するために近くのデバイスを発見するために無線機および通信リンクを巡回する段階を含む。
実施例564は、実施例561から563のいずれかの主題を含む。実施例564では、電源プラグデバイスを初期化する段階は、リモートホスト、オーケストレーションデバイス、またはその両方からポリシーをロードする段階を含む。
実施例565は、実施例561から564のいずれかの主題を含む。実施例565では、ポリシーは、動作を管理対象のIoTデバイスのリストと関連付ける規則のセットを含む。
実施例566は、実施例561から565のいずれかの主題を含む。実施例566では、動作は、IoTデバイスへの接続の種類に少なくとも部分的に基づいている。
実施例567は、実施例561から566のいずれかの主題を含む。実施例567では、IoTデバイスを監視する段階は、IoTデバイスから通信を監視する段階、IoTデバイス内のウォッチドッグエージェントからメッセージを受信する段階、IoTデバイス内のウォッチドッグエージェントからメッセージを受信することの失敗を監視する段階、またはそれらの任意の組み合わせを含む。
実施例568は、実施例561から567のいずれかの主題を含む。実施例568では、IoTデバイスのステータスを報告する段階は、警報を送信する段階を含む。
実施例569は、実施例561から568のいずれかの主題を含む。実施例569では、警報は、電子メール、ログに書き込まれたイベント、またはテキストメッセージ、あるいはそれらの任意の組み合わせを含む。
実施例570は、実施例561から569のいずれかの主題を含む。実施例570では、動作を再開するための措置をとる段階は、デバイス内でリモートで再起動する段階を含む。
実施例571は、実施例561から570のいずれかの主題を含む。実施例571では、動作を再開するための措置をとる段階は、IoTデバイス内のファームウェアをフラッシュする段階を含む。
実施例572は、実施例561から571のいずれかの主題を含む。実施例572では、動作を回復するための措置をとることは、IoTデバイスへの電源を入れ直して、電源プラグデバイスから電力を得ることを含む。
実施例573は、実施例561から572のいずれかの主題を含む。実施例573では、動作を回復するための措置をとる段階は、電源からバッテリに切り替える段階を含む。
実施例574は、非一時的機械可読媒体を含む。非一時的機械可読媒体は、実行されると、管理対象のモノのインターネット(IoT)デバイスを発見し、管理対象のIoTデバイスのリストを構築し、電源プラグデバイスを初期化し、管理対象のIoTデバイスを監視するようにプロセッサに指示する命令を含む。
実施例575は、実施例574の主題を含む。実施例575では、非一時的機械可読媒体は、実行されると、電源プラグおよび接続されたIoTデバイスをアドバタイズするようにプロセッサに指示する命令を含む。
実施例576は、実施例574または575のいずれかの主題を含む。実施例576では、非一時的機械可読媒体は、実行されると、管理対象のIoTデバイスのステータスを報告するようにプロセッサに指示する命令を含む。
実施例577は、実施例574から576のいずれかの主題を含む。実施例577では、非一時的機械可読媒体は、実行されると、管理対象のIoTデバイスを作動させて動作を復旧させるようにプロセッサに指示する命令を含む。
実施例578は、装置を含む。装置は、モノのインターネット(IoT)ネットワークを含み、IoTネットワークは、IoTデバイスを含む。IoTデバイスは、ホスト環境を含み、ホスト環境は、ホスト環境の健全性および動作を報告するウォッチドッグメッセージを送信するためのウォッチドッグエージェントと、ホスト環境用の電源とは別の電源を含むトラステッド信頼性エンジン(TRE)と、ウォッチドッグメッセージをTREブロックチェーンに書き込むためのTRE分散型台帳ロジックと、ホスト環境に障害が発生した場合にフェイルオーバー動作を適用するためのTREロジックと、を含む。
実施例579は、実施例578の主題を含む。実施例579では、ホスト環境は、ホスト環境のイメージを作成し、ホスト代替イメージ(HRI)として保存されるイメージコピーをTREに送信するためのイメージ作成部を含む。
実施例580は、実施例578または579のいずれかの主題を含む。実施例580では、ホスト環境は、ホストブロックチェーンを維持するためのホストブロックチェーンロジックを含む。
実施例581は、実施例578から580のいずれかの主題を含む。実施例581では、ホストブロックチェーンは、ウォッチドッグメッセージブロック、ピアデバイスブロック、または識別ブロック、またはそれらの任意の組み合わせを含む。
実施例582は、実施例578から581のいずれかの主題を含む。実施例582では、ホスト環境は、他のメッシュデバイス、クラウド内のデバイス、またはその両方と通信するための通信部を含む。
実施例583は、実施例578から582のいずれかの主題を含む。実施例583では、TREは、ホスト環境に障害が発生した場合にTREが外部デバイスと通信することを可能にするための通信システムを含む。
実施例584は、実施例578から583のいずれかの主題を含む。実施例584では、TREは、ホスト代替イメージ(HRI)を含む。
実施例585は、実施例578から584のいずれかの主題を含む。実施例585では、HRIは、IoTデバイス用のオペレーティングシステム、ドライバ、および機能コードのコピーを含む。
実施例586は、トラステッド信頼性エンジン(TRE)を使用してフェイルオーバーメカニズムを実装するための方法を含む。トラステッド信頼性エンジン(TRE)を使用してフェイルオーバーメカニズムを実装するための方法は、障害についてホスト環境を監視する段階と、ブロックチェーンにウォッチドッグメッセージをポストする段階と、ホスト環境の障害を検出する段階と、ホスト環境の障害から回復するための障害プロセスを実装する段階と、を含む。
実施例587は、実施例586の主題を含む。実施例587では、ホスト環境を監視する段階は、ホスト環境からpingを受信する段階を含む。
実施例588は、実施例586または587のいずれかの主題を含む。実施例588では、ウォッチドッグメッセージをポストする段階は、ウォッチドッグメッセージにpingを組み込む段階と、トランザクションとしてウォッチドッグメッセージをブロックチェーンにコミットする段階と、を含む。
実施例589は、実施例586から588のいずれかの主題を含む。実施例589では、ホスト環境の障害を検出する段階は、選択された期間にわたってホスト環境からpingが受信されていないと判定する段階を含む。
実施例590は、実施例586から589のいずれかの主題を含む。実施例590では、ホスト環境の障害を検出する段階は、ホスト環境のバスを介して通信が行われていないと判定する段階を含む。
実施例591は、実施例586から590のいずれかの主題を含む。実施例591では、ホスト環境の障害を検出することは、CPUが停止したと判定することを含む。
実施例592は、実施例586から591のいずれかの主題を含む。実施例592では、ホスト環境の障害を検出することは、ホスト環境内のメモリに障害が発生したと判定することを含む。
実施例593は、実施例586から592のいずれかの主題を含む。実施例593では、障害プロセスは、ホスト環境がローカルに回復可能であるか否かを判定することと、そうである場合は、ホスト環境にホスト代替イメージをインストールすることと、ホスト環境を再起動することと、を含む。
実施例594は、実施例586から593のいずれかの主題を含む。実施例594では、障害プロセスは、フェイルオーバーデバイスが近くにあるか否かを判定することと、そうであれば、ホスト環境の機能の実行を開始するようにフェイルオーバーデバイスを構成することとを含む。
実施例595は、実施例586から594のいずれかの主題を含む。実施例595では、障害プロセスは、ホスト環境を含むデバイスが修理可能であるか否かを判定することと、そしてそうであれば、デバイスを修理するために修理無人機をディスパッチすることと、を含む。
実施例596は、実施例586から595のいずれかの主題を含む。実施例596では、障害プロセスは、ホスト環境を含むデバイスが交換可能であるか否かを判定することと、そうであれば、デバイスを交換するために修理無人機をディスパッチすることと、を含む。
実施例597は、実施例586から596のいずれかの主題を含む。実施例597では、障害プロセスは、障害が解決されたか否かを判定することと、そして解決された場合、ホスト環境をデコミッションすること、TREをスリープ状態に置くこと、またはその両方を含む。
実施例598は、非一時的機械可読媒体を含む。非一時的機械可読媒体は、実行されると、ハートビートメッセージについてホスト環境を監視し、ウォッチドッグ(WD)メッセージを生成し、WDメッセージをブロックチェーンにポストし、ホスト環境における障害を検出するようにプロセッサに指示する命令を含む。
実施例599は、実施例598の主題を含む。実施例599では、非一時的機械可読媒体は、実行されると、ローカルホスト環境における障害を検出し、ホスト代替イメージをインストールするようにプロセッサに指示する命令を含む。
実施例600は、実施例598または599のいずれかの主題を含む。実施例600では、非一時的機械可読媒体は、実行されると、リモートホスト環境における障害を検出し、リモートホスト環境として機能するようにフェイルオーバーデバイスを構成するようにプロセッサに指示する命令を含む。
実施例601は、実施例598から600のいずれかの主題を含む。実施例601では、非一時的機械可読媒体は、実行されると、リモートホスト環境における障害を検出し、リモートホスト環境を含むデバイスの修理または交換のために無人機をディスパッチするようにプロセッサに指示する命令を含む。
実施例602は、実施例598から601のいずれかの主題を含む。実施例602では、非一時的機械可読媒体は、実行されると、障害が解決されたと判定し、障害が発生したデバイスをデコミッションするようにプロセッサに指示する命令を含む。
実施例603は、装置を含む。装置は、モノのインターネット(IoT)ネットワークを含み、IoTネットワークは、IoTデバイスを含む。IoTデバイスは、フレームのペイロードフィールド内に部分鍵およびオフセットを含むパケットを別のIoTデバイスから受信するための通信部と、部分鍵と循環バッファに格納された別の部分鍵との重複するバイトとを比較するためのバイト比較部と、部分鍵を循環バッファのオフセット位置に配置するための鍵アセンブラと、を含む。
実施例604は、実施例603の主題を含む。実施例604では、循環バッファに格納された部分鍵と他の部分鍵との重複するバイトが一致しない場合、バイト比較部は、鍵アセンブラが部分鍵を循環バッファに配置することを防止する。
実施例605は、実施例603または604のいずれかの主題を含む。実施例605では、鍵アセンブラは、他のIoTデバイスから受信した複数の部分鍵から循環バッファにおいて最終鍵を構築する。
実施例606は、実施例603から605のいずれかの主題を含む。実施例606では、本装置は、循環バッファにおいてアセンブルされた鍵を使用するための鍵オペレータを含む。
実施例607は、実施例603から606のいずれかの主題を含む。実施例607では、本装置は、循環バッファにおいてアセンブルされた鍵をプロセス内で使用するための鍵オペレータを含む。
実施例608は、実施例603から607のいずれかの主題を含む。実施例608では、プロセスは、IoTデバイスのアイデンティティを確認するために鍵をゲートウェイに提供することを含む。
実施例609は、実施例603から608のいずれかの主題を含む。実施例609では、プロセスは、フォグデバイスのアイデンティティを確認するために鍵をゲートウェイに提供することを含む。
実施例610は、実施例603から609のいずれかの主題を含む。実施例610では、本装置は、IoTデバイスのための部分鍵を生成するための部分鍵生成部と、フレームのペイロード内に部分鍵を含むフレームを構築し、そのフレームをピアデバイスに送信するための通信部と、を含む。
実施例611は、IoTネットワーク内の個々のノードに格納されている部分鍵から完全な鍵をアセンブルするための方法を含む。IoTネットワーク内の個々のノードに格納されている部分鍵から完全鍵をアセンブルするための方法は、IoTネットワーク内のデバイスから部分鍵を受信する段階と、部分鍵の重複するバイトを他のデバイスから受信した他の部分鍵と比較する段階と、循環バッファにおいて完全鍵を構築する段階と、を含む。
実施例612は、実施例611から612のいずれかの主題を含む。実施例612では、本方法は、IoTネットワーク内のデバイスからフレームを受信する段階と、フレームがペイロードフィールド内に部分鍵を含むか否かを判定する段階と、を含む。
実施例613は、実施例611の主題を含む。実施例613では、本方法は、部分鍵を循環バッファに格納する段階と、部分鍵が循環バッファの端部と重なる場合、残りのバイトを循環バッファの反対側の端部に書き込む段階と、を含む。
実施例614は、実施例611または613のいずれかの主題を含む。実施例614では、本方法は、別のデバイスから第2の部分鍵を受信する段階と、第2の部分鍵内のいずれかのバイトが既に循環バッファに書き込まれているバイトと重複するか否かを判定する段階と、既に循環バッファに書き込まれているバイトと重複する第2の部分鍵内のバイトを比較する段階と、を含む。
実施例615は、実施例611から614のいずれかの主題を含む。実施例615では、本方法は、第2の部分鍵内のバイトが既に循環バッファに書き込まれている重複するバイトと一致しないと判定する段階と、第2の部分鍵を削除する段階と、デバイスが危殆化している可能性があるという警告を送信する段階と、を含む。
実施例616は、実施例611から615のいずれかの主題を含む。実施例616では、本方法は、第2の部分鍵内のすべてのバイトが循環バッファに既に書き込まれている重複するバイトと一致すると判定する段階と、第2の部分鍵を循環バッファに書き込む段階と、を含む。
実施例617は、実施例611から616のいずれかの主題を含む。実施例617では、本方法は、すべての鍵が受信されたこと、および循環バッファが完全鍵を含むことを判定する段階と、完全鍵を別のデバイスに提供する段階と、を含む。
実施例618は、実施例611から617のいずれかの主題を含む。実施例618では、部分鍵は異なる長さのものである。
実施例619は、実施例611から618のいずれかの主題を含む。実施例619では、すべての部分鍵が受信される前に、完全鍵がアセンブルされる。
実施例620は、非一時的機械可読媒体を含む。非一時的機械可読媒体は、実行されると、デバイスから部分鍵を受け取り、部分鍵内のバイトを循環バッファに既に書き込まれているバイトと比較し、部分鍵を循環バッファに書き込むようにプロセッサに指示する命令を含む。
実施例621は、実施例620から621のいずれかの主題を含む。実施例621では、非一時的機械可読媒体は、実行されると、デバイスからフレームを受信し、そのフレームがペイロードフィールドに部分鍵を含むと判定するようにプロセッサに指示する命令を含む。
実施例622は、実施例620の主題を含む。実施例622では、非一時的機械可読媒体は、実行されると、別のデバイスに部分鍵をディスパッチするようにプロセッサに指示する命令を含む。
実施例623は、実施例620または622のいずれかの主題を含む。実施例623では、非一時的機械可読媒体は、実行されると、循環バッファにおいてアセンブルされた完全鍵を使用するようにプロセッサに指示する命令を含む。
実施例624は、実施例620から623のいずれかの主題を含む。実施例624では、非一時的機械可読媒体は、実行されると、部分鍵と循環バッファに書き込まれたバイトとの間の重複するバイトが一致しないと判定し、部分鍵の使用を防ぐようにプロセッサに指示する命令を含む。
実施例625は、装置を含む。装置は、モノのインターネット(IoT)ネットワークを含み、IoTネットワークは、IoTデバイスを含む。IoTデバイスは、送受信機、ネットワークインターフェースコントローラ、またはその両方を介して他のデバイスとパケットを交換するための通信部と、完全部分鍵およびローカル鍵の論理演算を実行することによって鍵を生成するための鍵生成部と、鍵を使用して、通信部を介してトランザクションをネットワークにコミットするトランザクション部と、を含む。
実施例626は、実施例625の主題を含む。実施例626では、IoTデバイスは、新しい鍵が生成される前に鍵が使用され得る期間を制御するための鍵有効期限タイマを含む。
実施例627は、実施例625または626のいずれかの主題を含む。実施例627では、IoTデバイスは、完全部分鍵とローカル鍵との間の論理演算の結果を格納するための循環バッファを含む。
実施例628は、実施例625から627のいずれかの主題を含む。実施例628では、IoTデバイスは完全部分鍵を含み、完全部分鍵は他のIoTデバイスから転送された部分鍵からアセンブルされる。
実施例629は、実施例625から628のいずれかの主題を含む。実施例629では、論理演算は完全部分鍵とローカル鍵との間の排他的論理和を含む。
実施例630は、実施例625から629のいずれかの主題を含む。実施例630では、トランザクションは、アクセスに対する購入、レンタル、支払い、またはそれらの任意の組み合わせを含む。
実施例631は、実施例625から630のいずれかの主題を含む。実施例631では、鍵生成部は、ブロックチェーンからローカル鍵を取得する。
実施例632は、モノのインターネット(IoT)デバイスにおいてオンデマンドで鍵を生成するための方法を含む。モノのインターネット(IoT)デバイスにおいてオンデマンドで鍵を生成するための方法は、完全部分鍵とローカル鍵との間で論理演算を実行することによって新しい鍵を生成する段階と、新しい鍵を検証する段階と、トランザクションをコミットするために新しい鍵を使用する段階と、を含む。
実施例633は、実施例632の主題を含む。実施例633では、本方法は、他のIoTデバイスから複数の部分鍵を受信する段階と、完全部分鍵を形成するために複数の部分鍵をアセンブルする段階と、を含む。
実施例634は、実施例632または633のいずれかの主題を含む。実施例634では、本方法は、鍵オフセット値が受信されたか否かを判定する段階と、受信されなかった場合に鍵オフセット値を生成する段階と、を含む。
実施例635は、実施例632から634のいずれかの主題を含む。実施例635では、本方法は、完全部分鍵とローカル鍵との間の論理演算のための循環バッファ内の開始点を判定するために、鍵オフセット値を使用する段階を含む。
実施例636は、実施例632から635のいずれかの主題を含む。実施例636では、論理演算は、完全部分鍵の各ビットとローカル鍵の各ビットとの間の排他的論理和を含む。
実施例637は、実施例632から636のいずれかの主題を含む。実施例637では、本方法は、新しい鍵が期限切れになったか否かを判定する段階と、期限が切れた場合に別の新しい鍵を生成する段階と、を含む。
実施例638は、実施例632から637のいずれかの主題を含む。実施例638では、本方法は、新しい鍵がトランザクションにおいて使用された後に別の新しい鍵を生成する段階を含む。
実施例639は、実施例632から638のいずれかの主題を含む。実施例639では、本方法は、トランザクションをコミットするのに使用された後に新しい鍵を削除する段階を含む。
実施例640は、非一時的機械可読媒体を含む。非一時的機械可読媒体は、実行されると、部分鍵を受信し、オフセット値を受信し、部分鍵とオフセット値とに少なくとも部分的に基づいて新しい鍵を生成するようにプロセッサに指示する命令を含む。
実施例641は、実施例640の主題を含む。実施例641では、非一時的機械可読媒体は、実行されると、ネットワーク内のモノのインターネット(IoT)デバイスから複数の部分鍵を受信し、複数の部分鍵をアセンブルして完全部分鍵を作成するようにプロセッサに指示する命令を含む。
実施例642は、実施例640または641のいずれかの主題を含む。実施例642では、非一時的機械可読媒体は、実行されると、オフセット値で開始して、完全部分鍵の各ビットとローカル鍵の各ビットとの間で排他的論理和演算を実行し、新しい鍵を生成するようにプロセッサに指示する命令を含む。
実施例643は、実施例640から642のいずれかの主題を含む。実施例643では、非一時的機械可読媒体は、実行されると、新しい鍵を使用してデータを暗号化するようにプロセッサに指示する命令を含む。
実施例644は、実施例640から643のいずれかの主題を含む。実施例644では、非一時的機械可読媒体は、実行されると、選択された時間の後に新しい鍵を期限切れにして別の新しい鍵を生成するようにプロセッサに指示する命令を含む。
実施例645は、実施例640から644のいずれかの主題を含む。実施例645では、非一時的機械可読媒体は、実行されると、新しい鍵によって確認されたトランザクションを実行し、トランザクションが完了した後に新しい鍵を期限切れにし、そして別の新しい鍵を生成するようにプロセッサに指示する命令を含む。
実施例646は、実施例640から645のいずれかの主題を含む。実施例646では、非一時的機械可読媒体は、実行されると、ブロックチェーンから鍵を取得するようにプロセッサに指示する命令を含む。
実施例647は、装置を含む。装置は、モノのインターネット(IoT)ネットワークを含み、IoTネットワークは、IoTデバイスを含む。IoTデバイスは、シードを生成するためのコンテキストを判定するためのコンテキスト識別部と、コンテキストからシードツリーを生成するためのシードツリー生成部と、シードツリー内の各ノードについてシードを生成するためのシード生成部と、を含む。
実施例648は、実施例647の主題を含む。実施例648では、コンテキストは、時間、位置、もしくはIPアドレス、あるいはそれらの任意の組み合わせに少なくとも部分的に基づくことができる。
実施例649は、実施例647または648のいずれかの主題を含む。実施例649では、シードツリー生成部は、コンテキストを分解してシードツリーを形成する。
実施例650は、実施例647から649のいずれかの主題を含む。実施例650では、シードツリー生成部は、各ノードにおいてコンテキストの一部を抽出し、その部分は数値を含む。
実施例651は、実施例647から650のいずれかの主題を含む。実施例651では、シード生成部は、数値をシードとして使用して乱数を生成する。
実施例652は、実施例647から651のいずれかの主題を含み、他のIoTデバイスとパケットを交換するための通信部を652に含む。実施例652では、パケットはコンテキスト、階層レベル、またはルートシード、あるいはそれらの任意の組み合わせを含む。
実施例653は、実施例647から652のいずれかの主題を含む。実施例653では、シード生成部は、シードツリー内のトップノードに対するルートシードを生成する。
実施例654は、実施例647から653のいずれかの主題を含む。実施例654では、IoTデバイスは、通信部を介して他のIoTデバイスから受信した部分鍵部分から完全部分鍵をアセンブルするための部分鍵アセンブラを含む。
実施例655は、実施例647から654のいずれかの主題を含む。実施例655では、IoTデバイスは、シードから生成された鍵を使用して通信を暗号化または復号するための暗号化部/復号部を含む。
実施例656は、IoTデバイス間のセキュアな通信のための共有秘密鍵を生成するための方法を含む。IoTデバイス間のセキュアな通信のための共有秘密を生成するための方法は、IoTデバイス間で共通の属性を識別する段階と、シードツリーを形成するために属性を分解する段階と、シードツリーのルートに対するシードを生成する段階と、参加している各デバイスにシードおよび属性をプロビジョニングする段階と、を含む。
実施例657は、実施例656の主題を含む。実施例657では、属性を分解する段階は、属性のサブセットを階層内の各ノードに割り当てる段階を含む。
実施例658は、実施例656または657のいずれかの主題を含む。実施例658では、本方法は、シードツリー内のノードについての新しいシードを生成するためにシードツリーのルートのためにシードを使用する段階と、暗号鍵を生成するためにその新しいシードを使用する段階と、を含む。
実施例659は、実施例656から658のいずれかの主題を含む。実施例659では、本方法は、シードをシェアに分割するために暗号秘密を使用する段階と、デバイスにわたってシェアをプロビジョニングする段階と、を含む。
実施例660は、実施例656から659のいずれかの主題を含む。実施例660では、本方法は、シェアのそれぞれを取得するためにネットワークを使用する段階と、シェアからシードを再アセンブルする段階と、を含む。
実施例661は、実施例656から660のいずれかの主題を含む。実施例661では、本方法は、ネットワーク内の他のIoTデバイスから複数の部分鍵を受信する段階と、複数の部分鍵から完全部分鍵をアセンブルする段階と、を含む。
実施例662は、実施例656から661のいずれかの主題を含む。実施例662では、本方法は、シードツリー内のノードについて生成された暗号鍵を使用してデータを暗号化する段階と、データを別のIoTデバイスに送信する段階と、他のIoTデバイス内に格納されたシードツリー内のノードについて生成された暗号鍵を使用してデータを復号する段階と、を含む。
実施例663は、非一時的機械可読媒体を含む。非一時的機械可読媒体は、実行されると、コンテキストのためのシードツリーを生成し、コンテキストのためのルートシードを生成し、他のデバイスにコンテキストを提供し、他のデバイスにルートシードを提供するようにプロセッサに指示する命令を含む。
実施例664は、実施例663の主題を含む。実施例664では、非一時的機械可読媒体は、実行されると、シードツリー内の各ノードについてシードを生成し、暗号鍵を生成するためにそのシードを使用し、他のデバイスに送信されるデータを暗号化するために暗号鍵を使用するようにプロセッサに指示する命令を含む。
実施例665は、実施例663または664のいずれかの主題を含む。実施例665では、非一時的機械可読媒体は、実行されると、別のデバイスからコンテキストを受信し、別のデバイスからルートシードを受信し、そのコンテキスト用のローカルシードツリーを生成し、ローカルシードツリーの各ノードにローカル暗号化鍵を生成するためにルートシードを使用するようにプロセッサに指示する命令を含む。
実施例666は、実施例663から665の非一時的機械可読媒体を含む。実施例666では、非一時的機械可読媒体は、実行されると、部分鍵を受信し、オフセット値を受信し、部分鍵とオフセット値とに少なくとも部分的に基づいて新しい鍵を生成するようにプロセッサに指示する命令を含む。
実施例667は、実施例663から666のいずれかの主題を含む。実施例667では、非一時的機械可読媒体は、実行されると、ネットワーク内のモノのインターネット(IoT)デバイスから複数の部分鍵を受信し、複数の部分鍵をアセンブルして完全部分鍵を作成するようにプロセッサに指示する命令を含む。
実施例668は、装置を含む。装置は、モノのインターネット(IoT)ネットワークを含み、IoTネットワークは、IoTサーバを含む。IoTサーバは、トラステッドプラットフォームモジュール(TPM)を使用してトラステッド実行環境(TEE)を作成するためのセキュアブート部/測定部と、サービスプロバイダのアイデンティティを確認するためのトラストアンカーと、対称鍵(SK)を使用してIoTクライアントとの通信を認証するための認証部と、鍵の有効期限が切れているか否かを判定するための鍵マネージャと、鍵を生成するための鍵生成部と、を含む。
実施例669は、実施例668の主題を含む。実施例669では、トラストアンカーは、公開鍵のハッシュ、または証明されたパス、またはトラステッドルート機関へのチェーンを含む。
実施例670は、実施例668または679のいずれかの主題を含む。実施例670では、SKは、鍵生成部によって生成された一時対称鍵(TSK)である。
実施例671は、実施例668から670のいずれかの主題を含む。実施例671では、IoTサーバは、サービスプロバイダからのメッセージを復号するための公開鍵(PK)を含む。
実施例672は、実施例668から671のいずれかの主題を含む。実施例672では、IoTサーバは、公開鍵の有効期限を含む。
実施例673は、実施例668から672のいずれかの主題を含む。実施例673では、IoTサーバは、サービスプロバイダから受信したSKを含む。
実施例674は、実施例668から673のいずれかの主題を含む。実施例674では、IoTサーバは、SKの有効期限を含む。
実施例675は、実施例668から674のいずれかの主題を含む。実施例675では、IoTサーバは、IoTサーバをサービスプロバイダに対して確認するためのサービスプロバイダクレデンシャルを含む。
実施例676は、実施例668から675のいずれかの主題を含む。実施例676では、本装置は、通信のためのSKを含むIoTクライアントを含む。
実施例677は、実施例668から676のいずれかの主題を含む。実施例677では、本装置は、公開鍵のステータスを含むIoTサーバを含む。
実施例678は、実施例668から677のいずれかの主題を含む。実施例678では、本装置は、公開鍵が危険にさらされたことを検出し、失効メッセージをIoTサーバに送信するためのエンティティを含む。
実施例679は、IoTネットワーク環境における統一鍵管理のための方法を含む。IoTネットワーク環境における統一鍵管理のための方法は、IoTクライアントからサービスプロバイダへ通信鍵の要求を送信する段階と、IoTクライアントでサービスプロバイダから通信鍵を受信する段階と、IoTサーバからIoTクライアントへ通信鍵を送信する段階と、IoTサーバから受信したメッセージを復号するために対称鍵を使用してIoTサーバと通信する段階と、を含む。
実施例680は、実施例679の主題を含む。実施例680では、通信鍵は、対称鍵を含む。
実施例681は、実施例679または680のいずれかの主題を含む。実施例681では、通信鍵は、IoTサーバによって提供された証明書を含む。
実施例682は、実施例679から実施例681のうちのいずれかの主題を含み、IoTクライアントからIoTサーバへの一時対称鍵を受信する段階を682に含む。実施例682では、一時対称鍵は、対称鍵を含む。
実施例683は、実施例679から682のいずれかの主題を含む。実施例683では、本方法は、セキュアな通信のためにサービスプロバイダからIoTサーバに対するクレデンシャルを要求する段階と、サービスプロバイダからIoTサーバにおいてトラストアンカを受信する段階と、を含む。
実施例684は、実施例679から683のいずれかの主題を含む。実施例684では、本方法は、IoTサーバにおいて一時対称鍵を生成する段階を含む。
実施例685は、実施例679から684のいずれかの主題を含む。実施例685では、本方法は、通信鍵を失効させるためにIoTサーバで失効メッセージを受信する段階を含む。
実施例686は、実施例679から685のいずれかの主題を含む。実施例686では、本方法は、通信鍵を期限切れにする段階と、サービスプロバイダによって提供される新しい通信鍵を要求する段階と、を含む。
実施例687は、非一時的機械可読媒体を含む。非一時的機械可読媒体は、実行されると、サービスプロバイダを認証し、サービスプロバイダからの鍵を取得し、デバイスに通信鍵を提供し、データを暗号化および復号するためにその鍵を使用してデバイスとの通信するようにプロセッサに指示する命令を含む。
実施例688は、実施例687の主題を含む。実施例688では、非一時的機械可読媒体は、実行されると、デバイスから鍵を受信するようにプロセッサに指示する命令を含む。
実施例689は、実施例687または688のいずれかの主題を含む。実施例689では、非一時的機械可読媒体は、実行されると、サービスプロバイダから受信した鍵に応答して通信鍵を生成するようにプロセッサに指示する命令を含む。
実施例690は、実施例687から689のいずれかの主題を含む。実施例690では、非一時的機械可読媒体は、実行されると、鍵が所定の寿命を過ぎたか否かを判定するようにプロセッサに指示する命令を含む。
実施例691は、実施例687から690のいずれかの主題を含む。実施例691では、非一時的機械可読媒体は、実行されると、鍵を失効させ、サービスプロバイダへの認証を繰り返すようにプロセッサに指示する命令を含む。
実施例692は、実施例687から691のいずれかの主題を含む。実施例692では、非一時的機械可読媒体は、実行されると、失効したまたは期限切れの鍵をリフレッシュするようにプロセッサに指示する命令を含む。
実施例693は、実施例687から692のいずれかの主題を含む。実施例693では、非一時的機械可読媒体は、実行されると、失効メッセージを受信し、鍵を失効させるようにプロセッサに指示する命令を含む。
実施例694は、装置を含む。装置は、モノのインターネット(IoT)ネットワークを含み、IoTネットワークは、IoTデバイスを含む。IoTデバイスは、IoTデバイスが利用可能なサービス、IoTデバイスによって提供可能なサービス、またはその両方をエニュメレーションするサービスエニュメレーション部と、IoTデバイスのコントラクトを発見するためのコントラクトエニュメレーション部と、IoTデバイスをコントラクトに参加するための参加コントラクト機能と、を含む。
実施例695は、実施例694の主題を含む。実施例695では、IoTデバイスは、IoTデバイスのネットワークにわたってブロックチェーンを共有および維持するためのブロックチェーンロジックと、サービス、コントラクト、アイデンティティ、属性、またはそれらの任意の組み合わせを含むブロックチェーンと、を含む。
実施例696は、実施例694または695のいずれかの主題を含む。実施例696では、ブロックチェーンは、作成されたデバイスのリストを含み、作成されたデバイスのリストは、コントラクトに参加したデバイスを含む。
実施例697は、実施例694から696のいずれかの主題を含む。実施例697では、ブロックチェーンは、そのデバイスのコンテキストプロパティ、アドバタイズされたサービス、またはその両方を含む、作成されたデバイスのリスト内の各デバイスのデバイス属性リストを含む。
実施例698は、実施例694から697のいずれかの主題を含む。実施例698では、IoTデバイスは、コントラクトへのIoTデバイスの参加を終了するためのコントラクト脱退機能を含む。
実施例699は、実施例694から698のいずれかの主題を含む。実施例699では、IoTデバイスは、トークンをデバイスに発行するためのトークン発行機能を含む。
実施例700は、実施例694から699のいずれかの主題を含む。実施例700では、IoTデバイスは、デバイスがコントラクトを脱退するときにデバイスに発行されたトークンを無効化するための失効トークン機能を含む。
実施例701は、実施例694から700のいずれかの主題を含む。実施例701では、IoTデバイスは、ブートプロセス中にトラステッド実行環境についての測定を実行するためのトラステッドプラットフォームモジュールを含む。
実施例702は、デバイスのライフサイクルを管理するための方法を含む。デバイスのライフサイクルを管理する方法は、IoTデバイスをセキュアエンクレーブでブートする段階と、セキュアエンクレーブ内でアイデンティティクライアントを実行する段階と、IoTデバイスのアイデンティティを取得する段階と、IoTデバイスのコミッショニングトランザクションを生成する段階と、IoTデバイスに利用可能なコントラクトをエニュメレーションする段階と、IoTデバイスをコントラクトに参加させる段階と、を含む。
実施例703は、実施例702の主題を含む。実施例703では、IoTデバイスのアイデンティティを取得する段階は、アイデンティティを取得することができるサービスをエニュメレーションする段階と、アイデンティティを取得するためのサービスを選択する段階と、サービスからアイデンティティを要求する段階と、を含む。
実施例704は、実施例702または703のいずれかの主題を含む。実施例704では、アイデンティティは、DNS名、NetBIOS名、IPアドレス、またはUUID、あるいはそれらの任意の組み合わせを含む。
実施例705は、実施例702から704のいずれかの主題を含む。実施例705では、アイデンティティは、コントラクトに少なくとも部分的に基づいて選択される。
実施例706は、実施例702から705のいずれかの主題を含む。実施例706では、本方法は、アイデンティティの取得に失敗した場合に警告メッセージを送信する段階を含む。
実施例707は、実施例702から706のいずれかの主題を含む。実施例707では、本方法は、アイデンティティが取得されたときに初期残高を割り当てる段階を含む。
実施例708は、実施例702から707のいずれかの主題を含む。実施例708では、IoTデバイスをコントラクトに参加させる段階は、コントラクトのオーナーのためのウォレットアドレスに料金を送信する段階を含む。
実施例709は、実施例702から708のいずれかの主題を含む。実施例709では、本方法は、コントラクトに参加する前にコントラクトに参加するための要件を満たす段階を含む。
実施例710は、実施例702から709のいずれかの主題を含む。実施例710では、要件は、コントラクトに参加する前にストレージを暗号化する段階を含む。
実施例711は、実施例702から710のいずれかの主題を含む。実施例711では、本方法は、コントラクトに関連する作成されたデバイスのリストにIoTデバイスを追加する段階を含む。
実施例712は、実施例702から711のいずれかの主題を含む。実施例712では、本方法は、IoTデバイスのデバイス属性をパブリッシュする段階を含む。
実施例713は、実施例702から712のいずれかの主題を含む。実施例713では、本方法は、デバイス属性のそれぞれをアテステーションするためのメカニズムを識別する段階を含む。
実施例714は、実施例702から713のいずれかの主題を含む。実施例714では、本方法は、コントラクトの下で機能するためにトークンを要求する段階を含む。
実施例715は、実施例702から714のいずれかの主題を含む。実施例715では、本方法は、サービスへのアクセスを可能にするためにトークンをサービスのオーナーに提示する段階を含む。
実施例716は、実施例702から715のいずれかの主題を含む。実施例716では、本方法は、コントラクトの下で動作するようにIoTデバイスをコミッショニングする段階と、コントラクトの下で動作を実行する段階と、を含む。
実施例717は、実施例702から716のいずれかの主題を含む。実施例717では、本方法は、IoTデバイスをデコミッショニングする段階と、コントラクトを脱退するのに必要とされる条件を完了する段階と、を含む。
実施例718は、実施例702から717のいずれかの主題を含む。実施例718では、本方法は、コントラクトを脱退すると、工場出荷時設定へのリセットを実行する段階を含む。
実施例719は、実施例702から718のいずれかの主題を含む。実施例719では、本方法は、コントラクトを脱退すると、保守サービスプロバイダに販売終了メッセージを送信する段階を含む。
実施例720は、実施例702から719のいずれかの主題を含む。実施例720では、本方法は、IoTデバイスがコントラクトを脱退するときにIoTデバイスに残された資金残高を返金する段階を含む。
実施例721は、非一時的機械可読媒体を含む。非一時的機械可読媒体は、実行されると、セキュアエンクレーブでブートし、アイデンティティを取得し、利用可能なコントラクトをエニュメレーションし、コントラクトに参加するようにプロセッサに指示する命令を含む。
実施例722は、実施例721の主題を含む。実施例722では、非一時的機械可読媒体は、実行されると、ブロックチェーンクライアントとして使用される鍵を生成するようにプロセッサに指示する命令を含む。
実施例723は、実施例721または722のいずれかの主題を含む。実施例723では、非一時的機械可読媒体は、実行されると、IoTデバイスの属性をパブリッシュするようにプロセッサに指示する命令を含む。
実施例724は、実施例721から723のいずれかの主題を含む。実施例724では、非一時的機械可読媒体は、実行されると、コントラクト下で動作するためのトークンを要求するようにプロセッサに指示する命令を含む。
実施例725は、装置を含む。装置は、モノのインターネット(IoT)ネットワークを含み、IoTネットワークは、IoTデバイスを含む。IoTデバイスは、Kバケット内の項目に関する情報を格納するブルームフィルタと、ブルームフィルタからの値を含むエントリをブロックチェーンに作成するブロックチェーンロジックと、ブルームフィルタのハッシュコードを作成するコンテンツ作成部と、探索対象が存在する確率を判定するためのブルームフィルタを探索する探索マネージャと、を含む。
実施例726は、実施例725の主題を含む。実施例726では、ブルームフィルタは、ビットシーケンスを含むストレージ構造を含む。
実施例727は、実施例725または726のいずれかの主題を含む。実施例727では、ビットシーケンスは、項目のそれぞれについて計算された上書きされたハッシュ値を含む。
実施例728は、実施例725から727のいずれかの主題を含む。実施例728では、Kバケットは、IoTデバイスに関連付けられたノードのグループを含む。
実施例729は、実施例727から728のいずれかの主題を含む。実施例729では、項目は、リソース、サービス、コントラクト、もしくはIoTデバイスアイデンティティ、またはそれらの任意の組み合わせを含む。
実施例730は、実施例725から729のいずれかの主題を含み、分散ハッシュタグ(DHT)データベースを730に含む。実施例730では、DHTデータベースは、Kバケット内の各項目についての個別のエントリを含む。
実施例731は、実施例725から730のいずれかの主題を含む。実施例731では、本装置は、項目が存在するか否かを判定するためにDHTデータベースを探索するためのコンテンツロケータを含む。
実施例732は、実施例725から731のいずれかの主題を含む。実施例732では、コンテンツ作成部は、統一資源識別子(URI)、メタデータ、もしくはハッシュコード、またはそれらの任意の組み合わせを含むコンテンツを作成する。
実施例733は、実施例725から732のいずれかの主題を含む。実施例733では、探索マネージャは、探索においてさらなるホップの料金を支払う。
実施例734は、リソース発見のための方法を含む。リソース発見のための方法は、探索ターゲットのハッシュコードを計算する段階と、ハッシュコードのビットをブルームフィルタに設定されたビットと比較する段階と、ハッシュコードのビットが、ブルームフィルタに設定されているビットと一致する場合、探索ターゲットのハッシュコードについて分散ハッシュテーブル(DHT)の探索を実行する段階と、を含む。
実施例735は、実施例734の主題を含む。実施例735では、本方法は、探索ターゲットのハッシュコードをローカルKバケット内のノードにブロードキャストする段階と、ハッシュコードのビットがブルームフィルタに設定されたビットと一致するローカルKバケット内のいずれかのノードでDHTの探索を実行する段階と、を含む。
実施例736は、実施例734または735のいずれかの主題を含む。実施例736では、本方法は、ローカルKバケット内の探索が失敗したと判定する段階と、探索ターゲットのハッシュコードをリモートKバケットに送信するための料金コストを判定する段階と、料金コストを支払う段階と、探索を続行するために探索ターゲットのハッシュコードをリモートKバケットに送信する段階と、を含む。
実施例737は、実施例734から736のいずれかの主題を含む。実施例737では、本方法は、ローカルKバケット内の探索が失敗したと判定する段階と、探索ターゲットのハッシュコードをリモートKバケットに送信するための料金コストを判定する段階と、料金コストが事前定義された制限を超えた場合探索を終了する段階と、を含む。
実施例738は、実施例734から737のいずれかの主題を含む。実施例738では、本方法は、DHTを初期化する段階と、ブロックチェーンデータベースを作成する段階と、ブロックチェーンデータベース内にジェネシスブロックを作成する段階と、ブロックチェーンデータベースおよびDHTを複数の参加者のそれぞれにコピーする段階と、を含む。
実施例739は、実施例734から738のいずれかの主題を含む。実施例739では、本方法は、ブルームフィルタをトランザクションとしてブロックチェーンデータベースに保存する段階を含む。
実施例740は、実施例734から739のいずれかの主題を含む。実施例740では、本方法は、ポインタをトランザクションとしてブロックチェーンデータベースに保存することを含み、ポインタはDHTの位置を含む。
実施例741は、実施例734から740のいずれかの主題を含む。実施例741では、本方法は、ブロックチェーンデータベース、DHT、またはその両方のコンテンツを作成する段階であって、項目ハッシュコードを作成する段階と、項目ハッシュコードをDHTに保存する段階と、DHTに保存されたデータのための統一資源識別子(URI)を作成する段階と、URIおよびアイテムハッシュコードをブロックチェーンデータベースに保存する段階と、を含む段階を含む。
実施例742は、実施例734から741のいずれかの主題を含む。実施例742では、本方法は、URIおよび項目ハッシュコードのメタデータをブロックチェーンデータベースに保存する段階を含み、メタデータはコンテンツ制作部のための動作を制御する。
実施例743は、非一時的機械可読媒体を含む。非一時的機械可読媒体は、実行されると、探索ターゲットのハッシュコードを計算し、そのハッシュコードのビットをブルームフィルタに設定されたビットと比較することによって、リソースを見つけるためにコンテンツをルックアップするようにプロセッサに指示する命令を含む。
実施例744は、実施例743の主題を含む。実施例744では、非一時的機械可読媒体は、実行されると、ハッシュコードのビットがブルームフィルタ内に設定されたビットと一致すると判定し、DHTを探索してハッシュコードがDHT内にあるか否かを判定するようにプロセッサに指示する命令を含む。
実施例745は、実施例743または744のいずれかの主題を含む。実施例745では、非一時的機械可読媒体は、実行されると、ブロックチェーンデータベースを作成するようにプロセッサに指示する命令を含む。
実施例746は、実施例743から745のいずれかの主題を含む。実施例746において、非一時的機械可読媒体は、実行されると、ブロックチェーンデータベースのためのコンテンツを作成するようにプロセッサに指示する命令を含み、これには複数の項目のそれぞれについて項目ハッシュコードを計算することが含まれる。
実施例747は、実施例743から746のいずれかの主題を含む。実施例747では、非一時的機械可読媒体は、実行されると、各項目ハッシュコードをブロックチェーンデータベースに格納するようにプロセッサに指示する命令を含む。
実施例748は、実施例743から747のいずれかの主題を含む。実施例748では、非一時的機械可読媒体は、実行されると、ローカルノードで探索が失敗した場合、他のノードに探索を送信するために料金を支払うようにプロセッサに指示する命令を含む。
実施例749は、モノのインターネット(IoT)ネットワークで使用するための装置を含む。モノのインターネット(IoT)ネットワークで使用するための装置は、発見された複数のピアに関する許可ガイドをドラフティングするための許可ガイドドラフト部を含み、発見された複数のピアは、それぞれパラメータを有し、許可ガイドの条件は、その条件が発見された複数のピアのうちの少なくとも2つによって許容されることに応じて生成される。発見された複数のピアのうちの各発見可能なピアのパラメータは、関連付けられたピアについての許容可能な条件範囲の範囲と、条件が満たされたことを検出したことに応答して許可ガイドの動作を実行するための動作実行部と、を含む。
実施例750は、実施例749の主題を含む。実施例750では、許可ガイドドラフト部は、発見された複数のピアの条項および条件を列挙する機能を含む。
実施例751は、実施例749または750のいずれかの主題を含む。実施例751では、許可ガイドドラフト部は、発見された複数のピアについてのサービス品質条項および条件のリストを含む。
実施例752は、実施例749から751のいずれかの主題を含む。実施例752では、許可ガイドドラフト部は、発見された複数のピアについてのデータプレーン条項および条件のリストを含む。
実施例753は、実施例752から752のいずれかの主題を含む。実施例753では、一例では、データプレーンは、データがピアによってどのように供給および消費されるべきかについてのプロセスを示す。
実施例754は、実施例749から753のいずれかの主題を含む。実施例754では、許可ガイドは生存期間を含む。
実施例755は、実施例749から754のいずれかの主題を含む。実施例755では、一例では、許可ガイドは、ピアによる許可ガイドへの参加および脱退を管理するためのプロトコル変換ブローカを含む。
実施例756は、実施例749から755のいずれかの主題を含む。実施例756では、許可ガイドの動作を実行することは、データを処理するようにピアに命令するピアへのサービスの自動コミッショニングを含む。
実施例757は、実施例749から756のいずれかの主題を含む。実施例757では、許可ガイドは、発見された複数のピア間の構成の交換を管理するためのプリアンブルを含む。
実施例758は、実施例749から757のいずれかの主題を含む。実施例758では、この用語は、発見された複数のピアの間で支払われるべき支払いのレートを指し、複数の発見されたピアのうちのピアが許可ガイドへの参加を終了していることの検出時にピア間で最終的な支払いが行われる。
実施例759は、モノのインターネット(IoT)デバイスにおけるタスク定義およびコミッショニングのための方法を含む。モノのインターネット(IoT)デバイスにおけるタスク定義およびコミッショニングのための方法は、発見された複数のピアに関する許可ガイドをドラフティングする段階であって、発見された複数のピアは、それぞれパラメータを有し、許可ガイドの条件は、その条件が発見された複数のピアのうちの少なくとも2つによって許容されることに応じて生成される、段階と、条件が満たされたことを検出したことに応答して許可ガイドの動作を実行する段階と、を含む。
実施例760は、実施例759の主題を含む。実施例760では、許可ガイドのドラフティングは、発見された複数のピアの条項および条件を列挙する機能を含む。
実施例761は、実施例759から760のいずれかの主題を含む。実施例761では、許可ガイドのドラフティングは、発見された複数のピアについてのサービス品質条項および条件のリストを含む。
実施例762は、実施例759から761のいずれかの主題を含む。実施例762では、許可ガイドのドラフティングは、発見された複数のピアについてのデータプレーン条項および条件のリストを含む。
実施例763は、実施例759から762のいずれかの主題を含む。実施例763では、一例では、データプレーンは、データがピアによってどのように供給および消費されるべきかについてのプロセスを示す。
実施例764は、実施例759から763のいずれかの主題を含む。実施例764では、許可ガイドは生存期間を含む。
実施例765は、実施例759から764のいずれかの主題を含む。実施例765では、一例では、許可ガイドは、ピアによる許可ガイドへの参加および脱退を管理するためのプロトコル変換ブローカを含む。
実施例766は、実施例759から765のいずれかの主題を含む。実施例766では、許可ガイドの動作を実行することは、データを処理するようにピアに命令するピアへのサービスの自動コミッショニングを含む。
実施例767は、実施例759から766のいずれかの主題を含む。実施例767では、許可ガイドは、発見された複数のピア間の構成の交換を管理するためのプリアンブルを含む。
実施例768は、実施例759から767のいずれかの主題を含む。実施例768では、この用語は、発見された複数のピアの間で支払われるべき支払いのレートを指し、複数の発見されたピアのうちのピアが許可ガイドへの参加を終了していることの検出時にピア間で最終的な支払いが行われる。
実施例769は、非一時的機械可読媒体を含む。非一時的機械可読媒体は、実行されると、発見された複数のピアに関する許可ガイドをドラフティングし、発見された複数のピアは、それぞれパラメータを有し、許可ガイドの条件は、その条件が発見された複数のピアのうちの少なくとも2つによって許容されることに応じて生成され、条件が満たされたことを検出したことに応答して許可ガイドの動作を実行するようにプロセッサに指示する命令を含む。
実施例770は、実施例769の主題を含む。実施例770では、許可ガイドのドラフティングは、発見された複数のピアの条項および条件を列挙する機能を含む。
実施例771は、実施例769または770のいずれかの主題を含む。実施例771では、許可ガイドのドラフティングは、発見された複数のピアについてのサービス品質条項および条件のリストを含む。
実施例772は、実施例769から771のいずれかの主題を含む。実施例772では、許可ガイドのドラフティングは、発見された複数のピアについてのデータプレーン条項および条件のリストを含む。
実施例773は、実施例769から772のいずれかの主題を含む。実施例773では、一例では、データプレーンは、データがピアによってどのように供給および消費されるべきかについてのプロセスを示す。
実施例774は、実施例769から773のいずれかの主題を含む。実施例774では、許可ガイドは生存期間を含む。
実施例775は、実施例769から774のいずれかの主題を含む。実施例775では、一例では、許可ガイドは、ピアによる許可ガイドへの参加および脱退を管理するためのプロトコル変換ブローカを含む。
実施例776は、実施例769から775のいずれかの主題を含む。実施例776では、許可ガイドの動作を実行することは、データを処理するようにピアに命令するピアへのサービスの自動コミッショニングを含む。
実施例777は、実施例769から776のいずれかの主題を含む。実施例777では、許可ガイドは、発見された複数のピア間の構成の交換を管理するためのプリアンブルを含む。
実施例778は、実施例769から777のいずれかの主題を含む。実施例778では、この用語は、発見された複数のピアの間で支払われるべき支払いのレートを指し、複数の発見されたピアのうちのピアが許可ガイドへの参加を終了していることの検出時にピア間で最終的な支払いが行われる。
実施例779は、モノのインターネット(IoT)ネットワークで使用するための装置を含む。モノのインターネット(IoT)ネットワークで使用するための装置は、発見された複数のホストに関するフローティングサービス許可ガイドをドラフティングするためのフローティングサービス許可ガイドドラフト部を含み、発見された複数のホストはそれぞれ、パラメータのホストフルフィルメントに関して評価される。本装置はまた、フローティングサービスのデータ構造に基づいて、フローティングサービスのためのホストハードウェアを選択するホストハードウェア選択部と、ホストハードウェアを使用してフローティングサービス許可ガイドを実行するフローティングサービス許可ガイド実行部と、フローティング許可ガイドの条件に達したという検出に応答して、フローティングサービスに関連付けられたサービスウォレットに価値を転送する価値転送部と、を含む。
実施例780は、実施例779の主題を含む。実施例780では、フローティングサービスは、サービスウォレットとホストウォレットとの間で価値トランザクションを開始する。
実施例781は、実施例779または780のいずれかの主題を含む。実施例781では、サービスウォレットはブロックチェーン符号化値を保持する。
実施例782は、実施例779から781のいずれかの主題を含む。実施例782では、データ構造は決定行列である。
実施例783は、実施例779から782のいずれかの主題を含む。実施例783では、決定行列は、フローティングサービスによって求められた特徴、利用可能なホストの数、および決定行列に列挙された特徴に対するホストのそれぞれの評価スコアを列挙する。
実施例784は、実施例779から783のいずれかの主題を含む。実施例784では、フローティングサービスは、1時間当たりのコストを、フローティングサービスの満足のいく使用を示す品質メトリクスを有する複数の特徴で除算して計算された最良値に基づいてホストを選択し、1時間当たりのコストは、評価対象のホストを使用したフローティングサービスを運用する、1時間当たりの予想コストである。
実施例785は、実施例779から784のいずれかの主題を含む。実施例785では、フローティングサービスの機能は、決定行列を用いた価値計算において特徴を様々に重み付けする。
実施例786は、実施例779から785のいずれかの主題を含む。実施例786では、一例では、フローティングサービス許可ガイドは、サービス許可ガイドの検出された違反に応答してホストに対して評価されるべきペナルティを示し、ペナルティはホストウォレットから収集される。
実施例787は、実施例779から786のいずれかの主題を含む。実施例787では、サービスウォレットの値が0になると、フローティングサービスは機能しなくなる。
実施例788は、実施例779から787のいずれかの主題を含む。実施例788では、一例では、許可ガイドは、サービスウォレットがトリガ閾値に到達したという検出に応答して、サービスウォレットが価値を転送することを示す。
実施例789は、モノのインターネット(IoT)デバイスにおけるフローティングサービスの管理のための方法を含む。モノのインターネット(IoT)デバイスにおけるフローティングサービスの管理のための方法は、発見された複数のホストに関するフローティングサービス許可ガイドをドラフティングする段階であって、発見された複数のホストはそれぞれ、パラメータのホストフルフィルメントに関して評価される、段階と、フローティングサービスのデータ構造に基づいて、フローティングサービスのためのホストハードウェアを選択する段階と、ホストハードウェアを使用してフローティングサービス許可ガイドを実行する段階と、フローティング許可ガイドの条件に達したという検出に応答して、フローティングサービスに関連付けられたサービスウォレットに価値を転送する段階と、を含む。
実施例790は、実施例789の主題を含む。実施例790では、フローティングサービスは、サービスウォレットとホストウォレットとの間で価値トランザクションを開始する。
実施例791は、実施例789または790のいずれかの主題を含む。実施例791では、サービスウォレットはブロックチェーン符号化値を保持する。
実施例792は、実施例789から791のいずれかの主題を含む。実施例792では、データ構造は決定行列である。
実施例793は、実施例789から792のいずれかの主題を含む。実施例793では、決定行列は、フローティングサービスによって求められた特徴、利用可能なホストの数、および決定行列に列挙された特徴に対するホストのそれぞれの評価スコアを列挙する。
実施例794は、実施例789から793のいずれかの主題を含む。実施例794では、フローティングサービスは、1時間当たりのコストを、フローティングサービスの満足のいく使用を示す品質メトリクスを有する複数の特徴で除算して計算された最良値に基づいてホストを選択し、1時間当たりのコストは、評価対象のホストを使用したフローティングサービスを運用する、1時間当たりの予想コストである。
実施例795は、実施例789から794のいずれかの主題を含む。実施例795では、フローティングサービスの機能は、決定行列を用いた値計算において特徴を様々に重み付けする。
実施例796は、実施例789から795のいずれかの主題を含む。実施例796では、一例では、フローティングサービス許可ガイドは、サービス許可ガイドの検出された違反に応答してホストに対して評価されるべきペナルティを示し、ペナルティはホストウォレットから収集される。
実施例797は、実施例789から796のいずれかの主題を含む。実施例797では、サービスウォレットの値が0になると、フローティングサービスは機能しなくなる。
実施例798は、実施例789から797のいずれかの主題を含む。実施例798では、一例では、許可ガイドは、サービスウォレットがトリガ閾値に到達したという検出に応答して、サービスウォレットが価値を転送することを示す。
実施例799は、非一時的機械可読媒体を含む。非一時的機械可読媒体は、実行されると、発見された複数のホストに関するフローティングサービス許可ガイドをドラフティングし、発見された複数のホストはそれぞれ、パラメータのホストフルフィルメントに関して評価され、フローティングサービスのデータ構造に基づいて、フローティングサービスのためのホストハードウェアを選択し、ホストハードウェアを使用してフローティングサービス許可ガイドを実行し、フローティング許可ガイドの条件に達したという検出に応答して、フローティングサービスに関連付けられたサービスウォレットに価値を転送するようにプロセッサに指示する命令を含む。
実施例800は、実施例799の主題を含む。実施例800では、フローティングサービスは、サービスウォレットとホストウォレットとの間で価値トランザクションを開始する。
実施例801は、実施例799または800のいずれかの主題を含む。実施例801では、サービスウォレットはブロックチェーン符号化値を保持する。
実施例802は、実施例799から801のいずれかの主題を含む。実施例802では、データ構造は決定行列である。
実施例803は、実施例779から802のいずれかの主題を含む。実施例803では、決定行列は、フローティングサービスによって求められた特徴、利用可能なホストの数、および決定行列に列挙された特徴に対するホストのそれぞれの評価スコアを列挙する。
実施例804は、実施例779から803のいずれかの主題を含む。実施例804では、フローティングサービスは、1時間当たりのコストを、フローティングサービスの満足のいく使用を示す品質メトリクスを有する複数の特徴で除算して計算された最良値に基づいてホストを選択し、1時間当たりのコストは、評価対象のホストを使用したフローティングサービスを運用する、1時間当たりの予想コストである。
実施例805は、実施例779から804のいずれかの主題を含む。実施例805では、フローティングサービスの機能は、決定行列を用いた価値計算において特徴を様々に重み付けする。
実施例806は、実施例799から805のいずれかの主題を含む。実施例806では、一例では、フローティングサービス許可ガイドは、サービス許可ガイドの検出された違反に応答してホストに対して評価されるべきペナルティを示し、ペナルティはホストウォレットから収集される。
実施例807は、実施例799から806のいずれかの主題を含む。実施例807では、サービスウォレットの値が0になると、フローティングサービスは機能しなくなる。
実施例808は、実施例799から807のいずれかの主題を含む。実施例808では、一例では、許可ガイドは、サービスウォレットがトリガ閾値に到達したという検出に応答して、サービスウォレットが価値を転送することを示す。
実施例809は、モノのインターネット(IoT)ネットワークで使用するための装置を含む。モノのインターネット(IoT)ネットワークで使用するための装置は、第1のパラメータおよび第1のパラメータ値を含む、第1の発見されたピアのための許可ガイドをドラフティングするための許可ガイドドラフト部を含む。装置はまた、第2のパラメータおよび第2のパラメータ値を含む第2の発見されたピアと、第1のパラメータ値と第2のパラメータ値とを比較することによって第1のパラメータ重みおよび第2のパラメータ重みを計算するパラメータ重み計算部と、提案された条件が第1のパラメータおよび第2のパラメータによって提案された範囲内にあることに応じて許可ガイドの条件を生成する条件生成部であって、第1パラメータは第1パラメータの重みによって調整され、第2パラメータは第2パラメータの重みによって調整される、条件生成部と、条件の条件が満たされたことを検出したことに応答して許可ガイドの動作を実行するための動作実行部と、を含む。
実施例810は、実施例809の主題を含む。実施例810では、装置は、参加パラメータおよび参加パラメータ値を含む、候補ピアから許可ガイドへの要求を処理するためのプロセッサを含む。
実施例811は、実施例809または810のいずれかの主題を含む。実施例811では、プロセッサは、第1のパラメータ値および第2のパラメータ値を、参加パラメータ値に対して比較することによって参加パラメータウェイトを計算する。
実施例812は、実施例809から811のいずれかの主題を含む。実施例812では、第1のパラメータおよび第2のパラメータは、それぞれ第1および第2のノードについての許容可能なデータ値範囲を指す。
実施例813は、実施例809から812のいずれかの主題を含む。実施例813では、許容可能データ値範囲が、コスト関数を用いて計算される。
実施例814は、実施例809から813のいずれかの主題を含む。実施例814では、コスト関数は、許可ガイドを実施するノードの運用コストを計算して組み合わせる。
実施例815は、実施例809から814のいずれかの主題を含む。実施例815では、運用コストは、デバイス、データ転送、およびストレージデバイスを運用するためのエネルギー、稼働、および保守のコストのうちの少なくとも1つを含む。
実施例816は、実施例809から815のいずれかの主題を含む。実施例816では、一例では、データ値範囲は、複数のデータソースの関数としてのデータの値の計算を指す。
実施例817は、実施例809から816のいずれかの主題を含む。実施例817では、データは複数のセンサから合成された導出データである。
実施例818は、実施例809から817のいずれかの主題を含む。実施例818では、データの値は、得ようとするデータのレートが増加するにつれて増加する。
実施例819は、モノのインターネット(IoT)デバイスにおける値のあるデータユニットとの交渉のための方法を含む。モノのインターネット(IoT)デバイスにおける値のあるデータユニットとの交渉のための方法は、第1のパラメータおよび第1のパラメータ値を含む第1の発見されたピア、ならびに第2のパラメータおよび第2のパラメータ値を含む第2の発見されたピアに関する許可ガイドをドラフティングする段階と、第1のパラメータ値と第2のパラメータ値とを比較することによって第1のパラメータ重みおよび第2のパラメータ重みを計算する段階と、提案された条件が第1のパラメータおよび第2のパラメータによって提案された範囲内にあることに応じて許可ガイドの条件を生成する段階であって、第1パラメータは第1パラメータの重みによって調整され、第2パラメータは第2パラメータの重みによって調整される、段階と、条件の条件が満たされたことを検出したことに応答して許可ガイドの動作を実行する段階と、を含む。
実施例820は、実施例819の主題を含む。実施例820では、本方法は、参加パラメータおよび参加パラメータ値を含む、候補ピアから許可ガイドへの要求を受信する段階を含む。
実施例821は、実施例819または820のいずれかの主題を含む。実施例821では、本方法は、第1のパラメータ値および第2のパラメータ値を、参加パラメータ値に対して比較することによって参加パラメータウェイトを計算する段階を含む。
実施例822は、実施例819から821のいずれかの主題を含む。実施例822では、第1のパラメータおよび第2のパラメータは、それぞれ第1および第2のノードについての許容可能なデータ値範囲を指す。
実施例823は、実施例819から822のいずれかの主題を含む。実施例823では、許容可能データ値範囲が、コスト関数を用いて計算される。
実施例824は、実施例819から823のいずれかの主題を含む。実施例824では、コスト関数は、許可ガイドを実施するノードの運用コストを計算して組み合わせる。
実施例825は、実施例819から824のいずれかの主題を含む。実施例825では、運用コストは、デバイス、データ転送、およびストレージデバイスを運用するためのエネルギー、稼働、および保守のコストのうちの少なくとも1つを含む。
実施例826は、実施例819から825のいずれかの主題を含む。実施例826では、一例では、データ値範囲は、複数のデータソースの関数としてのデータの値の計算を指す。
実施例827は、実施例819から826のいずれかの主題を含む。実施例827では、データは複数のセンサから合成された導出データである。
実施例828は、実施例819から827のいずれかの主題を含む。実施例828では、データの値は、得ようとするデータのレートが増加するにつれて増加する。
実施例829は、非一時的機械可読媒体を含む。非一時的機械可読媒体は、実行されると、第1のパラメータおよび第1のパラメータ値を含む第1の発見されたピア、ならびに第2のパラメータおよび第2のパラメータ値を含む第2の発見されたピアに関する許可ガイドをドラフティングし、第1のパラメータ値と第2のパラメータ値とを比較することによって第1のパラメータ重みおよび第2のパラメータ重みを計算し、提案された条件が第1のパラメータおよび第2のパラメータによって提案された範囲内にあることに応じて許可ガイドの条件を生成し、第1パラメータは第1パラメータの重みによって調整され、第2パラメータは第2パラメータの重みによって調整され、条件の条件が満たされたことを検出したことに応答して許可ガイドの動作を実行するようにプロセッサに指示する命令を含む。
実施例830は、実施例829の主題を含む。実施例830では、非一時的機械可読媒体は、実行されると、候補ピアから受信した要求を処理するようにプロセッサに指示する命令を含み、要求は参加パラメータおよび参加パラメータ値を含む。
実施例831は、実施例829または830のいずれかの主題を含む。実施例831では、非一時的機械可読媒体は、実行されると、第1のパラメータ値および第2のパラメータ値に対して参加パラメータ値を比較することによって参加パラメータ重みを計算するようにプロセッサに指示する命令を含む。
実施例832は、実施例829から831のいずれかの主題を含む。実施例832では、第1のパラメータおよび第2のパラメータは、それぞれ第1および第2のノードについての許容可能なデータ値範囲を指す。
実施例833は、実施例829から832のいずれかの主題を含む。実施例833では、許容可能データ値範囲が、コスト関数を用いて計算される。
実施例834は、実施例829から833のいずれかの主題を含む。実施例834では、コスト関数は、許可ガイドを実施するノードの運用コストを計算して組み合わせる。
実施例835は、実施例829から834のいずれかの主題を含む。実施例835では、運用コストは、デバイス、データ転送、およびストレージデバイスを運用するためのエネルギー、稼働、および保守のコストのうちの少なくとも1つを含む。
実施例836は、実施例829から835のいずれかの主題を含む。実施例836では、一例では、データ値範囲は、複数のデータソースの関数としてのデータの値の計算を指す。
実施例837は、実施例829から836のいずれかの主題を含む。実施例837では、データは複数のセンサから合成された導出データである。
実施例838は、実施例829から837のいずれかの主題を含む。実施例838では、データの値は、得ようとするデータのレートが増加するにつれて増加する。
実施例839は、モノのインターネット(IoT)ネットワークで使用するための装置を含む。モノのインターネット(IoT)ネットワークで使用するための装置は、ブロックチェーンクライアントとしてのデバイスのためのデバイスアイデンティティを生成するためのデバイスアイデンティティ生成部と、デバイスから発見ブロードキャストメッセージをパブリッシュするためのメッセージパブリッシュ部と、パブリッシュされた発見ブロードキャストメッセージに基づいて、DNAPからの応答を受信するデバイスに応答して、非集中型ネットワークアクセスプロキシ(DNAP)ネットワークへの参加をデバイスから適用するためのネットワーク適用部と、デバイスのアイデンティティおよび属性をDNAPに記述するためのデバイス記述部と、デバイスのアイデンティティおよび属性に基づいてネットワークによってデバイスに許可されているアクセスに応答して、ネットワークを介してデバイスからパケットを送信するためのパケット送信部と、を含む。
実施例840は、実施例839の主題を含む。実施例840では、デバイスは、DNAPにトークンを要求する。
実施例841は、実施例839または840のいずれかの主題を含む。実施例841では、トークンは、ピアツーピア以外のネットワークデータを送信および受信する能力をデバイスに付与する。
実施例842は、実施例839から841のいずれかの主題を含む。実施例842では、トークンは、ネットワークのオープンシステム相互接続層の層上でデータを送信および受信する能力をデバイスに付与する。
実施例843は、実施例839から842のいずれかの主題を含む。実施例843では、パケットがトークンを加え、パケットとトークンとの組み合わせが検証のためにDNAPに送信され、DNAPは、DNAPがトークンを受け入れられないことの検出に応答してパケットとトークンの両方を拒否する。
実施例844は、実施例839から843のいずれかの主題を含む。実施例844では、トークンは、パケット数閾値、データ量閾値、および期間閾値のうちの少なくとも1つと共に使用されるのに有効である。
実施例845は、実施例839から844のいずれかの主題を含む。実施例845では、一例では、デバイスは、デバイスによって受信および送信されたトランザクションのトランザクション記録を格納し、トランザクション記録は、DNAPと共有される。
実施例846は、実施例839から845のいずれかの主題を含む。実施例846では、デバイスは、デバイスから送信されたパケットの発信元を示すための鍵を生成する。
実施例847は、実施例839から846のいずれかの主題を含む。実施例847では、デバイスは、ブロックチェーン対応デバイスであり、デバイスは、デバイスによって送信され、デバイスによって受信されたすべてのトランザクションをブロックチェーン上に格納する。
実施例848は、実施例839から847のいずれかの主題を含む。実施例848では、デバイス属性の記述は、ブロックチェーンの外に格納されている。
実施例849は、モノのインターネット(IoT)デバイスとのセキュアな通信のための方法を含む。モノのインターネット(IoT)デバイスとのセキュアな通信のための方法は、ブロックチェーンクライアントとしてのデバイスのためのデバイスアイデンティティを生成する段階と、デバイスから発見ブロードキャストメッセージをパブリッシュする段階と、パブリッシュされた発見ブロードキャストメッセージに基づいて、DNAPからの応答を受信するデバイスに応答して、非集中型ネットワークアクセスプロキシ(DNAP)ネットワークへの参加をデバイスから適用する段階と、デバイスのアイデンティティおよび属性をDNAPに記述する段階と、デバイスのアイデンティティおよび属性に基づいてネットワークによってデバイスに許可されているアクセスに応答して、ネットワークを介してデバイスからパケットを送信する段階と、を含む。
実施例850は、実施例849の主題を含む。実施例850では、デバイスは、DNAPにトークンを要求する。
実施例851は、実施例849または850のいずれかの主題を含む。実施例851では、トークンは、ピアツーピア以外のネットワークデータを送信および受信する能力をデバイスに付与する。
実施例852は、実施例849から851のいずれかの主題を含む。実施例852では、トークンは、ネットワークのオープンシステム相互接続層の層上でデータを送信および受信する能力をデバイスに付与する。
実施例853は、実施例849から852のいずれかの主題を含む。実施例853では、パケットがトークンを加え、パケットとトークンとの組み合わせが検証のためにDNAPに送信され、DNAPは、DNAPがトークンを受け入れられないことの検出に応答してパケットとトークンの両方を拒否する。
実施例854は、実施例849から853のいずれかの主題を含む。実施例854では、トークンは、パケット数閾値、データ量閾値、および期間閾値のうちの少なくとも1つと共に使用されるのに有効である。
実施例855は、実施例849から854のいずれかの主題を含む。実施例855では、一例では、デバイスは、デバイスによって受信および送信されたトランザクションのトランザクション記録を格納し、トランザクション記録は、DNAPと共有される。
実施例856は、実施例849から855のいずれかの主題を含む。実施例856では、デバイスは、デバイスから送信されたパケットの発信元を示すための鍵を生成する。
実施例857は、実施例849から856のいずれかの主題を含む。実施例857では、デバイスは、ブロックチェーン対応デバイスであり、デバイスは、デバイスによって送信され、デバイスによって受信されたすべてのトランザクションをブロックチェーン上に格納する。
実施例858は、実施例849から857のいずれかの主題を含む。実施例858では、デバイス属性の記述は、ブロックチェーンの外に格納されている。
実施例859は、非一時的機械可読媒体を含む。非一時的機械可読媒体は、実行されると、ブロックチェーンクライアントとしてのデバイスのためのデバイスアイデンティティを生成し、デバイスから発見ブロードキャストメッセージをパブリッシュし、パブリッシュされた発見ブロードキャストメッセージに基づいて、DNAPからの応答を受信するデバイスに応答して、非集中型ネットワークアクセスプロキシ(DNAP)ネットワークへの参加をデバイスから適用し、デバイスのアイデンティティおよび属性をDNAPに記述し、デバイスのアイデンティティおよび属性に基づいてネットワークによってデバイスに許可されているアクセスに応答して、ネットワークを介してデバイスからパケットを送信するようにプロセッサに指示する命令を含む。
実施例860は、実施例859の主題を含む。実施例860では、デバイスは、DNAPにトークンを要求する。
実施例861は、実施例859または860のいずれかの主題を含む。実施例861では、トークンは、ピアツーピア以外のネットワークデータを送信および受信する能力をデバイスに付与する。
実施例862は、実施例859から861のいずれかの主題を含む。実施例862では、トークンは、ネットワークのオープンシステム相互接続層の層上でデータを送信および受信する能力をデバイスに付与する。
実施例863は、実施例859から862のいずれかの主題を含む。実施例863では、パケットがトークンを加え、パケットとトークンとの組み合わせが検証のためにDNAPに送信され、DNAPは、DNAPがトークンを受け入れられないことの検出に応答してパケットとトークンの両方を拒否する。
実施例864は、実施例859から863のいずれかの主題を含む。実施例864では、トークンは、パケット数閾値、データ量閾値、および期間閾値のうちの少なくとも1つと共に使用されるのに有効である。
実施例865は、実施例859から864のいずれかの主題を含む。実施例865では、一例では、デバイスは、デバイスによって受信および送信されたトランザクションのトランザクション記録を格納し、トランザクション記録は、DNAPと共有される。
実施例866は、実施例859から865のいずれかの主題を含む。実施例866では、デバイスは、デバイスから送信されたパケットの発信元を示すための鍵を生成する。
実施例867は、実施例859から866のいずれかの主題を含む。実施例867では、デバイスは、ブロックチェーン対応デバイスであり、デバイスは、デバイスによって送信され、デバイスによって受信されたすべてのトランザクションをブロックチェーン上に格納する。
実施例868は、実施例859から867のいずれかの主題を含む。実施例868では、デバイス属性の記述は、ブロックチェーンの外に格納されている。
実施例869は、モノのインターネット(IoT)ネットワークで使用するための装置を含む。モノのインターネット(IoT)ネットワークで使用するための装置は、第2のネットワークへのポータルを介して第1のネットワークにデバイスを登録するためのデバイスレジストラであって、第2のネットワークは、第1のネットワークへのアクセスを認可される、デバイスレジストラと、許可ガイドの義務の合意を介してデバイスを許可ガイドに参加させるためのデバイス参加部と、許可ガイドの機能を使用してトークンを要求するためのトークン要求部であって、トークンは、第2のネットワークにアクセスするために認証されたデバイスを識別する、トークン要求部と、デバイスからの認証要求を第1のネットワークに送信するための要求送信部であって、第1のネットワークは、トークンの検出に応答して認証を確認する、要求送信部と、を含む。
実施例870は、実施例869の主題を含む。実施例870では、デバイスは、第2のネットワーク内のウォレットへの支払い交換を実行する。
実施例871は、実施例869または870のいずれかの主題を含む。実施例871では、一例では、トークンの要求は、サイドチェーン上で生成されたトークンに対応するように、課金ブロックチェーン上のコインの予約をもたらす。
実施例872は、実施例869から871のいずれかの主題を含む。実施例872では、トークンは、デバイスによるトークンの第1のネットワークへの提示によるデバイスの認証に応答してサイドチェーン上で消費される。
実施例873は、実施例869から872のいずれかの主題を含む。実施例873では、ブロックチェーンのコインは、サイドチェーンによって失効され消費されたトークンのうちの少なくとも1つであるトークンの検出に応答して解放される。
実施例874は、実施例869から873のいずれかの主題を含む。実施例874では、許可ガイドに参加することは、デバイスの属性が第1のネットワークで許可されていることを確認するために、デバイスから、デバイスの属性を属性フィルタの許可ガイドに提供することを含む。
実施例875は、実施例869から874のいずれかの主題を含む。実施例875では、属性は、デバイスが許可ガイドに参加している間にアクティブなユーザプロファイルの属性を含む。
実施例876は、実施例869から875のいずれかの主題を含む。実施例876では、トークンは、デバイスの認可形式として使用されたことに応答して、自身を破壊する。
実施例877は、実施例869から876のいずれかの主題を含む。実施例877では、デバイスは、デバイスが第2のネットワークにアクセスするためのクレデンシャルを有するという第1のネットワークに対する認証に基づいて第1のネットワークにアクセスすることを認可される。
実施例878は、実施例869から877のいずれかの主題を含む。実施例878では、第1のネットワークを使用するためのデバイスの認可は、アクセス数、第1のネットワークを通してアクセスされるデータの量、および許可されたアクセスの時間のうちの少なくとも1つに基づいて期限切れになる。
実施例879は、モノのインターネット(IoT)デバイスを用いた非集中型の認可、認証、および課金のための方法を含む。モノのインターネット(IoT)デバイスを用いた非集中型の認可、認証、および課金のための方法は、第2のネットワークへのポータルを介して第1のネットワークにデバイスを登録する段階であって、第2のネットワークは、第1のネットワークへのアクセスを認可される、段階と、許可ガイドの義務の合意を介してデバイスを許可ガイドに参加させる段階と、許可ガイドの機能を使用してトークンを要求する段階であって、トークンは、第2のネットワークにアクセスするために認証されたデバイスを識別する、段階と、デバイスからの認証要求を第1のネットワークに送信する段階であって、第1のネットワークは、トークンの検出に応答して認証を確認する、段階と、を含む。
実施例880は、実施例879の方法を含む。実施例879では、デバイスは、第2のネットワーク内のウォレットへの支払い交換を実行する。
実施例881は、実施例879または880のいずれかの主題を含む。実施例881では、一例では、トークンの要求は、サイドチェーン上で生成されたトークンに対応するように、課金ブロックチェーン上のコインの予約をもたらす。
実施例882は、実施例879から881のいずれかの主題を含む。実施例882では、トークンは、デバイスによるトークンの第1のネットワークへの提示によるデバイスの認証に応答してサイドチェーン上で消費される。
実施例883は、実施例879から882のいずれかの主題を含む。実施例883では、ブロックチェーンのコインは、サイドチェーンによって失効され消費されたトークンのうちの少なくとも1つであるトークンの検出に応答して解放される。
実施例884は、実施例879から883のいずれかの主題を含む。実施例884では、許可ガイドに参加することは、デバイスの属性が第1のネットワークで許可されていることを確認するために、デバイスから、デバイスの属性を属性フィルタの許可ガイドに提供することを含む。
実施例885は、実施例879から884のいずれかの主題を含む。実施例885では、属性は、デバイスが許可ガイドに参加している間にアクティブなユーザプロファイルの属性を含む。
実施例886は、実施例879から885のいずれかの主題を含む。実施例886では、トークンは、デバイスの認可形式として使用されたことに応答して、自身を破壊する。
実施例887は、実施例879から886のいずれかの主題を含む。実施例887では、デバイスは、デバイスが第2のネットワークにアクセスするためのクレデンシャルを有するという第1のネットワークに対する認証に基づいて第1のネットワークにアクセスすることを認可される。
実施例888は、実施例879から887のいずれかの主題を含む。実施例888では、第1のネットワークを使用するためのデバイスの認可は、アクセス数、第1のネットワークを通してアクセスされるデータの量、および許可されたアクセスの時間のうちの少なくとも1つに基づいて期限切れになる。
実施例889は、非一時的機械可読媒体を含む。非一時的機械可読媒体は、実行されると、第2のネットワークへのポータルを介して第1のネットワークにデバイスを登録し、第2のネットワークは、第1のネットワークへのアクセスを認可され、許可ガイドの義務の合意を介してデバイスを許可ガイドに参加させ、許可ガイドの機能を使用してトークンを要求し、トークンは、第2のネットワークにアクセスするために認証されたデバイスを識別し、デバイスからの認証要求を第1のネットワークに送信し、第1のネットワークは、トークンの検出に応答して認証を確認するようにプロセッサに指示する命令を含む。
実施例890は、実施例889の主題を含む。実施例890では、デバイスは、第2のネットワーク内のウォレットへの支払い交換を実行する。
実施例891は、実施例889または890のいずれかの主題を含む。実施例891では、一例では、トークンの要求は、サイドチェーン上で生成されたトークンに対応するように、課金ブロックチェーン上のコインの予約をもたらす。
実施例892は、実施例889から891のいずれかの主題を含む。実施例892では、トークンは、デバイスによるトークンの第1のネットワークへの提示によるデバイスの認証に応答してサイドチェーン上で消費される。
実施例893は、実施例889から892のいずれかの主題を含む。実施例893では、ブロックチェーンのコインは、サイドチェーンによって失効され消費されたトークンのうちの少なくとも1つであるトークンの検出に応答して解放される。
実施例894は、実施例889から893のいずれかの主題を含む。実施例894では、許可ガイドに参加することは、デバイスの属性が第1のネットワークで許可されていることを確認するために、デバイスから、デバイスの属性を属性フィルタの許可ガイドに提供することを含む。
実施例895は、実施例889から894のいずれかの主題を含む。実施例895では、属性は、デバイスが許可ガイドに参加している間にアクティブなユーザプロファイルの属性を含む。
実施例896は、実施例889から895のいずれかの主題を含む。実施例896では、トークンは、デバイスの認可形式として使用されたことに応答して、自身を破壊する。
実施例897は、実施例889から896のいずれかの主題を含む。実施例897では、デバイスは、デバイスが第2のネットワークにアクセスするためのクレデンシャルを有するという第2のネットワークによる第1のネットワークに対する認証に基づいて第1のネットワークにアクセスすることを認可される。
実施例898は、実施例889から897のいずれかの主題を含む。実施例898では、第1のネットワークを使用するためのデバイスの認可は、アクセス数、第1のネットワークを通してアクセスされるデータの量、および許可されたアクセスの時間のうちの少なくとも1つに基づいて期限切れになる。
実施例899は、モノのインターネット(IoT)ネットワークで使用するための装置を含む。モノのインターネット(IoT)ネットワークで使用するための装置は、非集中型アプリケーションプログラムインターフェース(API)を用いて認証要求のアイデンティティを検証するためのアイデンティティ検証部を含む。装置はまた、リモート認証ダイヤルインユーザサービス(RADIUS)クライアントから受信した認証要求、分散型台帳に要求を送信し、分散型台帳からのアイデンティティ検証応答の受信に応答して応答をRADIUSサーバに返すことによってアイデンティティを検証するための非集中型APIと、分散APIからの応答の受信に応答して認証要求に対する応答をRADIUSクライアントに返す応答返送部と、を含み、RADIUSクライアントは、認証済みのアイデンティティの応答に応答してトランザクションを行う。
実施例900は、実施例899の主題を含む。実施例900では、トランザクションは、ユーザ名、パスワード、およびメタデータのうちの少なくとも1つを含む。
実施例901は、実施例899または900のいずれかの主題を含む。実施例901では、トランザクションは、価値トランザクションを含む。
実施例902は、実施例899から901のいずれかの主題を含む。実施例902では、トランザクションは、暗号通貨トランザクションである。
実施例903は、実施例899から902のいずれかの主題を含む。実施例903では、認証要求はネットワークアドレスに対する要求を含む。
実施例904は、実施例899から903のいずれかの主題を含む。実施例904では、ネットワークアドレスは、RADIUSサーバの完全修飾ドメイン名およびRADIUSサーバのインターネットプロトコルアドレスのうちの少なくとも一方を含む。
実施例905は、実施例899から904のいずれかの主題を含む。実施例905では、RADIUSサーバは、ブロックチェーンから公開鍵の位置を要求することによって公開鍵を検証する。
実施例906は、実施例899から905のいずれかの主題を含む。実施例906では、RADIUSサーバへの要求は、認証されたアイデンティティの確認をRADIUSクライアントが受信したことに応答して、オフチェーンで行われる。
実施例907は、実施例899から906のいずれかの主題を含む。実施例907では、RADIUSサーバは、RADIUSサーバが受信した要求のロギングおよびアカウンティングを実行する。
実施例908は、実施例899から907のいずれかの主題を含む。実施例908では、認証要求に対する応答は、不変記録としてブロックチェーンに格納される。
実施例909は、モノのインターネット(IoT)デバイスを用いた非集中型の認可、認証、および課金のための方法を含む。モノのインターネット(IoT)デバイスを使用した非集中型の認可、認証、および課金のための方法は、分散型台帳を使用して認証要求のアイデンティティを検証する段階であって、認証要求が、リモート認証ダイヤルインユーザサービス(RADIUS)クライアントから受信される、段階と、分散型台帳からの肯定的なアイデンティティ検証応答の受信に応答してRADIUSサーバに要求を送信する段階と、RADIUSサーバからの応答の受信に応答してRADIUSクライアントに認証要求に対する応答を返す段階と、を含み、RADIUSクライアントは、認証済みのアイデンティティの応答に応答してRADIUSサーバとトランザクションを行う。
実施例910は、実施例909の主題を含む。実施例910では、トランザクションは、ユーザ名、パスワード、およびメタデータのうちの少なくとも1つを含む。
実施例911は、実施例909または910のいずれかの主題を含む。実施例911では、トランザクションは、価値トランザクションを含む。
実施例912は、実施例909から911のいずれかの主題を含む。実施例912では、トランザクションは、暗号通貨トランザクションである。
実施例913は、実施例909から912のいずれかの主題を含む。実施例913では、認証要求はネットワークアドレスに対する要求を含む。
実施例914は、実施例909から913のいずれかの主題を含む。実施例914では、ネットワークアドレスは、RADIUSサーバの完全修飾ドメイン名およびRADIUSサーバのインターネットプロトコルアドレスのうちの少なくとも一方を含む。
実施例915は、実施例909から914のいずれかの主題を含む。実施例915では、RADIUSサーバは、ブロックチェーンから公開鍵の位置を要求することによって公開鍵を検証する。
実施例916は、実施例909から915のいずれかの主題を含む。実施例916では、RADIUSサーバへの要求は、認証されたアイデンティティの確認をRADIUSクライアントが受信したことに応答して、オフチェーンで行われる。
実施例917は、実施例909から916のいずれかの主題を含む。実施例917では、RADIUSサーバは、RADIUSサーバが受信した要求のロギングおよびアカウンティングを実行する。
実施例918は、実施例917から917のいずれかの主題を含む。実施例918では、認証要求に対する応答は、不変記録としてブロックチェーンに格納される。
実施例919は、非一時的機械可読媒体を含む。非一時的機械可読媒体は、実行されると、分散型台帳を使用して認証要求のアイデンティティを検証し、認証要求が、リモート認証ダイヤルインユーザサービス(RADIUS)クライアントから受信され、分散型台帳からの肯定的なアイデンティティ検証応答の受信に応答してRADIUSサーバに要求を送信し、RADIUSサーバからの応答の受信に応答してRADIUSクライアントに認証要求に対する応答を返し、RADIUSクライアントは、認証済みのアイデンティティの応答に応答してRADIUSサーバとトランザクションを行うようにプロセッサに指示する命令を含む。
実施例920は、実施例919の主題を含む。実施例920では、トランザクションは、ユーザ名、パスワード、およびメタデータのうちの少なくとも1つを含む。
実施例921は、実施例919または920のいずれかの主題を含む。実施例921では、トランザクションは、価値トランザクションを含む。
実施例922は、実施例919から921のいずれかの主題を含む。実施例922では、トランザクションは、暗号通貨トランザクションである。
実施例923は、実施例919から922のいずれかの主題を含む。実施例923では、認証要求はネットワークアドレスに対する要求を含む。
実施例924は、実施例919から923のいずれかの主題を含む。実施例924では、ネットワークアドレスは、RADIUSサーバの完全修飾ドメイン名およびRADIUSサーバのインターネットプロトコルアドレスのうちの少なくとも一方を含む。
実施例925は、実施例919から924のいずれかの主題を含む。実施例925では、RADIUSサーバは、ブロックチェーンから公開鍵の位置を要求することによって公開鍵を検証する。
実施例926は、実施例919から925のいずれかの主題を含む。実施例926では、RADIUSサーバへの要求は、認証されたアイデンティティの確認をRADIUSクライアントが受信したことに応答して、オフチェーンで行われる。
実施例927は、実施例919から926のいずれかの主題を含む。実施例927では、RADIUSサーバは、RADIUSサーバが受信した要求のロギングおよびアカウンティングを実行する。
実施例928は、実施例919から927のいずれかの主題を含む。実施例928では、認証要求に対する応答は、不変記録としてブロックチェーンに格納される。
実施例929は、モノのインターネット(IoT)ネットワークで使用するための装置を含む。モノのインターネット(IoT)ネットワークで使用するための装置は、非集中型データベースのネットワークにデバイスを接続するためのデバイスコネクタと、非集中型データベースのノードの名前空間を発見するための名前空間発見部と、ノードに受け入れられたことに応答して共有データベース区画を作成するための区画作成部と、非集中型データベースにサービスをアドバタイズするためのサービスアドバタイズ部と、プライベートデータベース区画と共有データベース区画との間のサービスの実行の際に受信および生成されたデータを経路指定するためのデータルータと、を含む。
実施例930は、実施例929の主題を含む。実施例930では、共有データベース区画は、許可されたものと暗号化されたものうちの少なくとも一方である。
実施例931は、実施例929または930のいずれかの主題を含む。実施例931では、共有データベース区画に格納されたデータのコピーは、データをコピーするための第2のノードの権限を示す特権を提示する第2のノードに応答して第2のノードに複製される。
実施例932は、実施例929から931のいずれかの主題を含む。実施例932では、デバイスは、非集中型データベースのネットワークへの接続に応答して非集中型データベースソフトウェアをインストールする。
実施例933は、実施例929から932のいずれかの主題を含む。実施例933では、デバイスは、非集中型データベースのネットワークへの接続に応答して共有データベース区画を作成する。
実施例934は、実施例929から933のいずれかの主題を含む。実施例934では、デバイスは、非集中型データベースのノードの名前空間を発見することに応答して、非集中型データベースに参加するように要求する。
実施例935は、実施例929から934のいずれかの主題を含む。実施例935では、デバイスは、共有データベース区画の作成に応答して、共有データベース区画内に格納するために共有ノード区画を複製する。
実施例936は、実施例929から935のいずれかの主題を含む。実施例936では、共有区画内のデータは、データが共有データベース区画に経路指定されたことに応答して、共有ノード区画内の格納のために複製される。
実施例937は、実施例929から936のいずれかの主題を含む。実施例937では、デバイスは、ノードがデバイスの受け入れに投票したことに応答して、非集中型データベースへの受け入れを受信する。
実施例938は、実施例929から937のいずれかの主題を含む。実施例938では、デバイスは、非集中型データベースのノードの名前空間を発見することに応答して、非集中型データベースに受け入れられる。
実施例939は、非集中型データベースに参加するための方法を含む。非集中型データベースに参加するための方法は、非集中型データベースのネットワークにデバイスを接続する段階と、非集中型データベースのノードの名前空間を発見する段階と、ノードに受け入れられたことに応答して共有データベース区画を作成する段階と、非集中型データベースにサービスをアドバタイズする段階と、プライベートデータベース区画と共有データベース区画との間のサービスの実行の際に受信および生成されたデータを経路指定する段階と、を含む。
実施例940は、実施例939の主題を含む。実施例940では、共有データベース区画は、許可されたものと暗号化されたものうちの少なくとも一方である。
実施例941は、実施例939または940のいずれかの主題を含む。実施例941では、共有データベース区画に格納されたデータのコピーは、データをコピーするための第2のノードの権限を示す特権を提示する第2のノードに応答して第2のノードに複製される。
実施例942は、実施例939から941のいずれかの主題を含む。実施例942では、デバイスは、非集中型データベースのネットワークへの接続に応答して非集中型データベースソフトウェアをインストールする。
実施例943は、実施例939から942のいずれかの主題を含む。実施例943では、デバイスは、非集中型データベースのネットワークへの接続に応答して共有データベース区画を作成する。
実施例944は、実施例939から943のいずれかの主題を含む。実施例944では、デバイスは、非集中型データベースのノードの名前空間を発見することに応答して、非集中型データベースに参加するように要求する。
実施例945は、実施例939から944のいずれかの主題を含む。実施例945では、デバイスは、共有データベース区画の作成に応答して、共有データベース区画内に格納するために共有ノード区画を複製する。
実施例946は、実施例939から945のいずれかの主題を含む。実施例946では、共有区画内のデータは、データが共有データベース区画に経路指定されたことに応答して、共有ノード区画内の格納のために複製される。
実施例947は、実施例939から946のいずれかの主題を含む。実施例947では、デバイスは、ノードがデバイスの受け入れに投票したことに応答して、非集中型データベースへの受け入れを受信する。
実施例948は、実施例939から947のいずれかの主題を含む。実施例948では、デバイスは、非集中型データベースのノードの名前空間を発見することに応答して、非集中型データベースに受け入れられる。
実施例949は、非一時的機械可読媒体を含む。非一時的機械可読媒体は、実行されると、非集中型データベースのネットワークにデバイスを接続し、非集中型データベースのノードの名前空間を発見し、ノードに受け入れられたことに応答して共有データベース区画を作成し、非集中型データベースにサービスをアドバタイズし、プライベートデータベース区画と共有データベース区画との間のサービスの実行に応答して受信および生成されたデータを経路指定するようにプロセッサに指示する命令を含む。
実施例950は、実施例949の主題を含む。実施例950では、共有データベース区画は、許可されたものと暗号化されたものうちの少なくとも一方である。
実施例951は、実施例949または950のいずれかの主題を含む。実施例951では、共有データベース区画に格納されたデータのコピーは、データをコピーするための第2のノードの権限を示す特権を提示する第2のノードに応答して第2のノードに複製される。
実施例952は、実施例949から951のいずれかの主題を含む。実施例952では、デバイスは、非集中型データベースのネットワークへの接続に応答して非集中型データベースソフトウェアをインストールする。
実施例953は、実施例949から952のいずれかの主題を含む。実施例953では、デバイスは、非集中型データベースのネットワークへの接続に応答して共有データベース区画を作成する。
実施例954は、実施例949から934のいずれかの主題を含む。実施例954では、デバイスは、非集中型データベースのノードの名前空間を発見することに応答して、非集中型データベースに参加するように要求する。
実施例955は、実施例949から954のいずれかの主題を含む。実施例955では、デバイスは、共有データベース区画の作成に応答して、共有データベース区画内に格納するために共有ノード区画を複製する。
実施例956は、実施例949から955のいずれかの主題を含む。実施例956では、共有区画内のデータは、データが共有データベース区画に経路指定されたことに応答して、共有ノード区画内の格納のために複製される。
実施例957は、実施例949から956のいずれかの主題を含む。実施例957では、デバイスは、ノードがデバイスの受け入れに投票したことに応答して、非集中型データベースへの受け入れを受信する。
実施例958は、実施例949から957のいずれかの主題を含む。実施例958では、デバイスは、非集中型データベースのノードの名前空間を発見することに応答して、非集中型データベースに受け入れられる。
実施例959は、モノのインターネット(IoT)ネットワークで使用するための装置を含む。モノのインターネット(IoT)ネットワークで使用するための装置は、呼び出し元エンティティにクレデンシャルを発行するためのクレデンシャル発行部であって、クレデンシャルは、複数の許可構造の層を含む、クレデンシャル発行部と、ターゲットオブジェクトへの参照および許可を指定するアクセス制御リストをオブジェクトエンティティにプロビジョニングするためのオブジェクトエンティティプロビジョニング部と、を含む。装置はまた、認可クレデンシャルをオブジェクトエンティティに提示するためのクレデンシャル提示部と、クレデンシャルが呼び出し元エンティティと重複するか否か、ターゲットオブジェクトは要求と重複するか否か、複数のデバイス層識別情報が複数のクレデンシャル層識別情報と一致するか否か、および複数のターゲット層識別情報が複数の要求層識別情報と一致するか否かの比較に基づいてアクセスがIoTデバイスに許可されるか否かを判定するためにアクセス制御リストポリシーを適用するアクセス制御リストポリシー適用部と、を含む。
実施例960は、実施例959の主題を含む。実施例960では、クレデンシャルは6層の許可である。
実施例961は、実施例959または960のいずれかの主題を含む。実施例961では、6層の許可は、プラットフォーム層、デバイス層、収集層、リソース層、記録層、およびプロパティ層を含む。
実施例962は、実施例959から961のいずれかの主題を含む。実施例962では、複数の層は、コンピュータの物理インスタンスを反映するためのプラットフォーム層を含み、計算、ネットワーキング、ストレージ、センシング、およびアクチュエーションの能力のうちの少なくとも1つを含む。
実施例963は、実施例959から962のいずれかの主題を含む。実施例963では、複数の層は、コンピュータの論理インスタンスを反映するためのデバイス層を含み、計算、ネットワーキング、ストレージ、センシング、およびアクチュエーションの能力のうちの少なくとも1つを含む。
実施例964は、実施例959から963のいずれかの主題を含む。実施例964では、層の数は、リソースの論理構造に対する収集層を含み、リソースは記録のための論理構造を含み、記録はプロパティの論理構造を含み、プロパティはアトミックデータ構造および複合データ構造のうちの少なくとも1つを含む。
実施例965は、実施例959から964のいずれかの主題を含む。実施例965では、プロパティは、複素データ構造であり、複素データ構造は、データモデリング言語を使用して定義可能な構造に対するものである。
実施例966は、実施例959から965のいずれかの主題を含む。実施例966では、プロパティは、アトミックデータ構造を含み、アトミックデータ構造は、文字列、数字、および日付のうちの少なくとも1つである。
実施例967は、実施例959から966のいずれかの主題を含む。実施例967では、作成、読み取り、更新、削除、および通知(CRUDN)ライフサイクル通知に基づくオブジェクトデータの物理的性質によってオブジェクトに課される制限によって、オブジェクトエンティティに対する認可クレデンシャルが制限される。
実施例968は、実施例959から967のいずれかの主題を含む。実施例968では、クレデンシャルは製造業者による設置を示す。
実施例969は、IoTオブジェクトにおけるアクセス制御のための方法を含む。IoTオブジェクトにおけるアクセス制御のための方法は、呼び出し元エンティティにクレデンシャルを発行する段階であって、クレデンシャルは、複数の許可構造の層を含む、段階と、ターゲットオブジェクトへの参照および許可を指定するアクセス制御リストをオブジェクトエンティティにプロビジョニングする段階と、認可クレデンシャルをオブジェクトエンティティに提示する段階と、クレデンシャルが呼び出し元エンティティと重複するか否か、ターゲットオブジェクトは要求と重複するか否か、複数のデバイス層識別情報が複数のクレデンシャル層識別情報と一致するか否か、および複数のターゲット層識別情報が複数の要求層識別情報と一致するか否かの比較に基づいてアクセスがIoTデバイスに許可されるか否かを判定するためにアクセス制御リストポリシーを適用する段階と、を含む。
実施例970は、実施例969の主題を含む。実施例970では、クレデンシャルは6層の許可である。
実施例971は、実施例969または970のいずれかの主題を含む。実施例971では、6層の許可は、プラットフォーム層、デバイス層、収集層、リソース層、記録層、およびプロパティ層を含む。
実施例972は、実施例969から971のいずれかの主題を含む。実施例972では、複数の層は、コンピュータの物理インスタンスを反映するためのプラットフォーム層を含み、計算、ネットワーキング、ストレージ、センシング、およびアクチュエーションの能力のうちの少なくとも1つを含む。
実施例973は、実施例969から972のいずれかの主題を含む。実施例973では、複数の層は、コンピュータの論理インスタンスを反映するためのデバイス層を含み、計算、ネットワーキング、ストレージ、センシング、およびアクチュエーションの能力のうちの少なくとも1つを含む。
実施例974は、実施例969から973のいずれかの主題を含む。実施例974では、層の数は、リソースの論理構造に対する収集層を含み、リソースは記録のための論理構造を含み、記録はプロパティの論理構造を含み、プロパティはアトミックデータ構造および複合データ構造のうちの少なくとも1つを含む。
実施例975は、実施例969から974のいずれかの主題を含む。実施例975では、プロパティは、複素データ構造であり、複素データ構造は、データモデリング言語を使用して定義可能な構造に対するものである。
実施例976は、実施例969から975のいずれかの主題を含む。実施例976では、プロパティは、アトミックデータ構造を含み、アトミックデータ構造は、文字列、数字、および日付のうちの少なくとも1つである。
実施例977は、実施例969から976のいずれかの主題を含む。実施例977では、作成、読み取り、更新、削除、および通知(CRUDN)ライフサイクル通知に基づくオブジェクトデータの物理的性質によってオブジェクトに課される制限によって、オブジェクトエンティティに対する認可クレデンシャルが制限される。
実施例978は、実施例969から977のいずれかの主題を含む。実施例978では、クレデンシャルは製造業者による設置を示す。
実施例979は、非一時的機械可読媒体を含む。非一時的機械可読媒体は、実行されると、呼び出し元エンティティにクレデンシャルを発行し、クレデンシャルは、複数の許可構造の層を含み、ターゲットオブジェクトへの参照および許可を指定するアクセス制御リストをオブジェクトエンティティにプロビジョニングし、認可クレデンシャルをオブジェクトエンティティに提示し、クレデンシャルが呼び出し元エンティティと重複するか否か、ターゲットオブジェクトは要求と重複するか否か、複数のデバイス層識別情報が複数のクレデンシャル層識別情報と一致するか否か、および複数のターゲット層識別情報が複数の要求層識別情報と一致するか否かの比較に基づいてアクセスがIoTデバイスに許可されるか否かを判定するためにアクセス制御リストポリシーを適用するようにプロセッサに指示するための命令を含む。
実施例980は、実施例979の主題を含む。実施例980では、クレデンシャルは6層の許可である。
実施例981は、実施例979または980のいずれかの主題を含む。実施例981では、6層の許可は、プラットフォーム層、デバイス層、収集層、リソース層、記録層、およびプロパティ層を含む。
実施例982は、実施例979から981のいずれかの主題を含む。実施例982では、複数の層は、コンピュータの物理インスタンスを反映するためのプラットフォーム層を含み、計算、ネットワーキング、ストレージ、センシング、およびアクチュエーションの能力のうちの少なくとも1つを含む。
実施例983は、実施例979から982のいずれかの主題を含む。実施例983では、複数の層は、コンピュータの論理インスタンスを反映するためのデバイス層を含み、計算、ネットワーキング、ストレージ、センシング、およびアクチュエーションの能力のうちの少なくとも1つを含む。
実施例984は、実施例979から983のいずれかの主題を含む。実施例984では、層の数は、リソースの論理構造に対する収集層を含み、リソースは記録のための論理構造を含み、記録はプロパティの論理構造を含み、プロパティはアトミックデータ構造および複合データ構造のうちの少なくとも1つを含む。
実施例985は、実施例979から984のいずれかの主題を含む。実施例985では、プロパティは、複素データ構造であり、複素データ構造は、データモデリング言語を使用して定義可能な構造に対するものである。
実施例986は、実施例979から985のいずれかの主題を含む。実施例986では、プロパティは、アトミックデータ構造を含み、アトミックデータ構造は、文字列、数字、および日付のうちの少なくとも1つである。
実施例987は、実施例979から986のいずれかの主題を含む。実施例987では、作成、読み取り、更新、削除、および通知(CRUDN)ライフサイクル通知に基づくオブジェクトデータの物理的性質によってオブジェクトに課される制限によって、オブジェクトエンティティに対する認可クレデンシャルが制限される。
実施例988は、実施例979から987のいずれかの主題を含む。実施例988では、クレデンシャルは製造業者による設置を示す。
実施例989は、装置を含む。装置は、モノのインターネット(IoT)ネットワークを含み、IoTネットワークは、IoTデバイスを含む。IoTデバイスはまた、IoTデバイスによって制御されるリソースハードウェアコンポーネントを識別するためのリソースハードウェアコンポーネント識別部であって、ソースハードウェアコンポーネントが能力閾値を有する、リソースハードウェアコンポーネント識別部と、外部モジュールからの外部モジュールハードウェア要件の受信指示を処理するためのプロセッサと、外部モジュールのハードウェア要件をIoTデバイスのリソースハードウェアコンポーネントの能力閾値と比較するための外部モジュール比較部と、リソースハードウェアコンポーネントの能力閾値を満たさない外部モジュールハードウェア要件に応答して、外部モジュールに非アクティブ化信号を送信する送信機と、を備える。
実施例990は、実施例989の主題を含む。実施例990では、IoTデバイスは、リソースハードウェアコンポーネントの能力閾値を満たさない外部モジュールハードウェア要件に応答して、要求をマスタデバイスに送信し、第2のリソースハードウェアコンポーネントを要求するマスタデバイスは、IoTデバイスによって制御されるように割り当てられる。
実施例991は、実施例989または990のいずれかの主題を含む。実施例991では、IoTデバイスは、IoTの制御下にある第2のリソースハードウェアコンポーネントを含み、第1のリソースハードウェアコンポーネントおよび第2のリソースハードウェアコンポーネントは、能力閾値が第1のリソースハードウェアと第2のリソースハードウェアとの能力閾値の和であるようにプールされ得る。
実施例992は、実施例989から991のいずれかの主題を含む。実施例992では、外部モジュールは、IoTデバイスによる使用のために第1のリソースハードウェアコンポーネントとプールされるモジュールリソースを含む。
実施例993は、実施例989から992のいずれかの主題を含む。実施例993では、リソースハードウェアコンポーネントは、電源、処理リソース、統合通信コンポーネント、コンテキストセンサ、コンテキストアクチュエータ、信号調整回路、メモリリソース、またはストレージリソースのうちの少なくとも1つを含む。
実施例994は、実施例989から993のいずれかの主題を含む。実施例994では、能力閾値は、一緒に機能するための最小限の能力を示すリソースハードウェアコンポーネントと外部モジュールとの間の最小の機能的互換性、およびリソースハードウェアコンポーネントと外部モジュールとの間の、外部モジュールの最高能力で機能する能力を示す、完全な互換性を含む。
実施例995は、実施例989から994のいずれかの主題を含む。実施例995では、IoTデバイスは、可視インジケータを作動させることによって、満たされていない能力閾値を示す。
実施例996は、実施例989から995のいずれかの主題を含む。実施例996では、IoTデバイスは、能力閾値を満たすことに応答して、IoTデバイスの制御下に外部モジュールを置く。
実施例997は、実施例989から996のいずれかの主題を含む。実施例997では、外部モジュールの寿命がIoTデバイスの動作寿命より短いことに応答して、IoTデバイスは更新された外部モジュールに対する要求を送信する。
実施例998は、実施例989から997のいずれかの主題を含む。実施例998では、リソースハードウェアコンポーネントの寿命がIoTデバイスの動作寿命より短いことに応答して、IoTデバイスは、更新されたリソースハードウェアコンポーネントに対する要求を送信する。
実施例999は、リソースおよび自己記述型ハードウェアの要件をマッピングするために、モノのインターネット(IoT)デバイスを使用するための方法を含む。自己記述型ハードウェアのリソースおよび要件をマッピングするためにモノのインターネット(IoT)デバイスを使用するための方法は、IoTデバイスによって制御されるリソースハードウェアコンポーネントを識別する段階であって、ソースハードウェアコンポーネントが能力閾値を有する、段階と、外部モジュールからの外部モジュールハードウェア要件の受信指示を処理する段階、外部モジュールのハードウェア要件をIoTデバイスのリソースハードウェアコンポーネントの能力閾値と比較する段階と、リソースハードウェアコンポーネントの能力閾値を満たさない外部モジュールハードウェア要件に応答して、外部モジュールに非アクティブ化信号を送信する段階と、を含む。
実施例1000は、実施例999の主題を含む。実施例1000では、本方法は、リソースハードウェアコンポーネントの能力閾値を満たさない外部モジュールハードウェア要件に応答して、要求をマスタデバイスに送信する段階であって、第2のリソースハードウェアコンポーネントを要求するマスタデバイスは、IoTデバイスによって制御されるように割り当てられる、段階を含む。
実施例1001は、実施例999または1000のいずれかの主題を含む。実施例1001では、本方法は、IoTデバイスの制御下にある第2のリソースハードウェアコンポーネントを含み、第1のリソースハードウェアコンポーネントおよび第2のリソースハードウェアコンポーネントは、能力閾値が第1のリソースハードウェアと第2のリソースハードウェアとの能力閾値の和であるようにプールされ得る。
実施例1002は、実施例999から1001のいずれかの主題を含む。実施例1002では、外部モジュールは、IoTデバイスの指示により第1のリソースハードウェアコンポーネントと共にプールされるモジュールリソースを含む。
実施例1003は、実施例999から1002のいずれかの主題を含む。実施例1003では、リソースハードウェアコンポーネントは、電源、処理リソース、統合通信コンポーネント、コンテキストセンサ、コンテキストアクチュエータ、信号調整回路、メモリリソース、またはストレージリソースのうちの少なくとも1つを含む。
実施例1004は、実施例999から1003のいずれかの主題を含む。実施例1004では、能力閾値は、一緒に機能するための最小限の能力を示すリソースハードウェアコンポーネントと外部モジュールとの間の最小の機能的互換性、およびリソースハードウェアコンポーネントと外部モジュールとの間の、外部モジュールの全能力で機能する能力を示す、完全な互換性を含む。
実施例1005は、実施例999から1004のいずれかの主題を含む。実施例1005では、本方法は、可視インジケータを作動させることによって、満たされていない能力閾値を示す段階を含む。
実施例1006は、実施例999から1005のいずれかの主題を含む。実施例1006では、本方法は、能力閾値を満たすことに応答して、外部モジュールをIoTデバイスの制御下に置く段階を含む。
実施例1007は、実施例999から1006のいずれかの主題を含む。実施例1007では、外部モジュールの寿命がIoTデバイスの動作寿命より短いことに応答して、更新された外部モジュールに対する要求を送信する段階を含む。
実施例1008は、実施例999から1007のいずれかの主題を含む。実施例1008では、リソースハードウェアコンポーネントの寿命がIoTデバイスの動作寿命より短いことに応答して、更新されたリソースハードウェアコンポーネントに対する要求を送信する段階を含む。
実施例1009は、実行されると、IoTデバイスによって制御されるリソースハードウェアコンポーネントを識別し、ソースハードウェアコンポーネントが能力閾値を有し、外部モジュールからの外部モジュールハードウェア要件の受信指示を処理し、外部モジュールのハードウェア要件をIoTデバイスのリソースハードウェアコンポーネントの能力閾値と比較し、リソースハードウェアコンポーネントの能力閾値を満たさない外部モジュールハードウェア要件に応答して、外部モジュールに非アクティブ化信号を送信するようにプロセッサに指示する命令を含む、非一時的機械可読媒体を含む。
実施例1010は、実施例1009の主題を含む。実施例1010では、非一時的機械可読媒体は、実行されると、リソースハードウェアコンポーネントの能力閾値を満たさない外部モジュールハードウェア要件に応答して、要求をマスタデバイスに送信するようにプロセッサに指示する命令を含み、第2のリソースハードウェアコンポーネントを要求するマスタデバイスは、IoTデバイスによって制御されるように割り当てられる。
実施例1011は、実施例1009または1010のいずれかの主題を含む。実施例1011では、非一時的機械可読媒体は、IoTデバイスの制御下にある第2のリソースハードウェアコンポーネントを含み、第1のリソースハードウェアコンポーネントおよび第2のリソースハードウェアコンポーネントは、能力閾値が第1のリソースハードウェアと第2のリソースハードウェアとの能力閾値の和であるようにプールされ得る。
実施例1012は、実施例1009から1011のいずれかの主題を含む。実施例1012では、外部モジュールは、IoTデバイスによる使用のために第1のリソースハードウェアコンポーネントとプールされるモジュールリソースを含む。
実施例1013は、実施例1009から1012のいずれかの主題を含む。実施例1013では、リソースハードウェアコンポーネントは、電源、処理リソース、統合通信コンポーネント、コンテキストセンサ、コンテキストアクチュエータ、信号調整回路、メモリリソース、またはストレージリソースのうちの少なくとも1つを含む。
実施例1014は、実施例1009から1013のいずれかの主題を含む。実施例1014では、能力閾値は、一緒に機能するための最小限の能力を示すリソースハードウェアコンポーネントと外部モジュールとの間の最小の機能的互換性、およびリソースハードウェアコンポーネントと外部モジュールとの間の、外部モジュールの最高能力で機能する能力を示す、完全な互換性を含む。
実施例1015は、実施例1009から1014のいずれかの主題を含む。実施例1015では、非一時的機械可読媒体は、実行されると、可視インジケータを作動させることによって満たされていない能力閾値を示すようにプロセッサに指示する命令を含む。
実施例1016は、実施例1009から1015のいずれかの主題を含む。実施例1016では、非一時的機械可読媒体は、実行されると、能力閾値を満たすことに応答して、IoTデバイスの制御下に外部モジュールを置くようにプロセッサに指示する命令を含む。
実施例1017は、実施例1009から1016のいずれかの主題を含む。実施例1017では、非一時的機械可読媒体は、実行されると、外部モジュールの寿命がIoTデバイスの動作寿命より短いことに応じて、更新された外部モジュールの要求を送信するようにプロセッサに指示する命令を含む。
実施例1018は、実施例1009から1017のいずれかの主題を含む。実施例1018では、非一時的機械可読媒体は、実行されると、リソースハードウェアコンポーネントの寿命がIoTデバイスの動作寿命より短いことに応じて、更新済みリソースハードウェアコンポーネントの要求を送信するようにプロセッサに指示する命令を含む。
実施例1019は、適用エネルギー計算のための装置を含む。適用エネルギー計算のための装置は、複数のモジュールに電力を供給し制御するように構成されたデバイスのためのエネルギーリソースをエニュメレーションするエネルギーリソースエニュメレーション部と、複数のモジュールのエネルギー要求をエニュメレーションするエネルギー要求エニュメレーション部と、を含む。本装置はまた、実行時に複数のモジュールのうちの1つのモジュール上で完全に機能するタスクにアプリケーションを分解するためのアプリケーション分解部と、各作動期間について、複数のモジュールのうちの1つのモジュールの消費電力を識別する消費電力識別部と、タスクが単位時間内に複数のモジュールのうちの1つのモジュールを起動する回数をカウントするタスク起動カウンタと、タスクがアクティブである時間、1つのモジュールで完了されたタスクの期間、およびアクティブ期間までにモジュールが必要としたエネルギーに少なくとも部分的に基づいて、複数のモジュールのうちの1つのモジュールによって単位時間に使用される総エネルギーを計算する総エネルギー計算部と、を含み得る。
実施例1020は、実施例1019の主題を含む。実施例1020では、本装置は、複数のモジュールについて単位時間内に使用された総エネルギーと、デバイスのエネルギーリソースと、に基づいてデバイス寿命を生成するためのデバイス寿命生成部を含む。
実施例1021は、実施例1019または1020のいずれかの主題を含む。実施例1021では、本装置は、デバイス寿命が、デバイスのアプリケーション分析が始まる前に設定された最小閾値時間以上であるとして計算されるのに応答して、アプリケーションを開始するようにデバイスに命令するデバイス命令部を含む。
実施例1022は、実施例1019から1021のいずれかの主題を含む。実施例1022では、本装置は、デバイス寿命が、デバイスのアプリケーション分析が始まる前に設定された最小閾値時間未満であるとして計算されるのに応答して、新しい構成がマスタデバイスに送信されることの要求を命令するデバイス命令部を含む。
実施例1023は、実施例1019から1022のいずれかの主題を含む。実施例1023では、新しい構成の要求は、モジュール上のタスクのためのエネルギー使用量、単位時間中にモジュールによって使用されたエネルギー、および複数のモジュールにおけるモジュールタイプのためのエネルギー使用量のうちの少なくとも1つの詳細なリストを含む。
実施例1024は、実施例1019から1023のいずれかの主題を含む。実施例1024では、エネルギーリソースのエニュメレーションの前にアクティブ化段階が行われ、アクティブ化段階は、デバイスへの電力供給、デバイスのハードウェア構成の更新、およびアプリケーションコードの更新のうちの少なくとも1つを含む。
実施例1025は、実施例1019から1024のいずれかの主題を含む。実施例1025では、本装置は、第1の構成について計算された単位時間当たりの総エネルギーを格納するようにデバイスに命令するデバイス命令部であって、デバイス命令部が、マスタデバイスから第2の構成を要求するようにデバイスに命令する、デバイス命令部と、デバイスの第2の構成の単位当たりの第2の総エネルギーを計算する第2の総エネルギー計算部と、第1の構成の単位当たりの総エネルギーを第2の構成の単位当たりの第2の総エネルギーと比較する総エネルギー比較部であって、デバイス命令部が単位当たりの総エネルギーと単位当たりの2番目の総エネルギーの比較に基づいて第1の構成または第2の構成を要求するようにデバイスに命令する、総エネルギー比較部と、を含む。
実施例1026は、実施例1019から1025のいずれかの主題を含む。実施例1026において、本装置は、デバイスが有線リソースによって電力を供給されていると判定された場合にアプリケーションを開始するようにデバイスに命令するためのデバイス命令部を含む。
実施例1027は、実施例1019から1026のいずれかの主題を含む。実施例1027では、アクティブ期間ごとに複数のモジュールのうちの1つのモジュールの電力消費量を識別することは、モジュールが、そのタスクについてそのモジュールに関連する履歴エネルギー使用量値を取得することを含む。
実施例1028は、実施例1019から1027のいずれかの主題を含む。実施例1028では、本装置は、アプリケーションがスリープモード機能を有するか否かを識別するアプリケーションスリープモード識別部と、アプリケーションがスリープモードになる時間を時間単位でカウントする時間カウンタと、アプリケーションのプロセッサがスリープモードになる時間に基づいて節約された総電力に基づいて、使用された総エネルギーを計算する総エネルギー計算部と、を含む。
実施例1029は、アプリケーションのエネルギー需要を判定するための方法を含む。適用エネルギー需要を判定する方法は、複数のモジュールに電力を供給し制御するように構成されたデバイスのためのエネルギーリソースをエニュメレーションする段階と、複数のモジュールのエネルギー要求をエニュメレーションする段階と、実行時に複数のモジュールのうちの1つのモジュール上で完全に機能するタスクにアプリケーションを分解する段階と、各作動期間について、複数のモジュールのうちの1つのモジュールの消費電力を識別する段階と、タスクが単位時間内に複数のモジュールのうちの1つのモジュールを起動する回数をカウントする段階と、タスクがアクティブである時間、1つのモジュールで完了されたタスクの期間、およびアクティブ期間までにモジュールが必要としたエネルギーに少なくとも部分的に基づいて、複数のモジュールのうちの1つのモジュールによって単位時間に使用される総エネルギーを計算する段階と、を含む。
実施例1030は、実施例1029の主題を含む。実施例1030では、本方法は、複数のモジュールについて単位時間内に使用された総エネルギーと、デバイスのエネルギーリソースと、に基づいてデバイス寿命を生成する段階を含む。
実施例1031は、実施例1029または1030のいずれかの主題を含む。実施例1031では、本方法は、デバイス寿命が、デバイスのアプリケーション分析が始まる前に設定された最小閾値時間以上であるとして計算されるのに応答して、アプリケーションを開始するようにデバイスに命令する段階を含む。
実施例1032は、実施例1029から1031のいずれかの主題を含む。実施例1032では、本方法は、デバイス寿命が、デバイスのアプリケーション分析が始まる前に設定された最小閾値時間未満であるとして計算されるのに応答して、新しい構成がマスタデバイスに送信されることの要求を命令する段階を含む。
実施例1033は、実施例1029から1032のいずれかの主題を含む。実施例1033では、新しい構成の要求は、モジュール上のタスクのためのエネルギー使用量、単位時間中にモジュールによって使用されたエネルギー、および複数のモジュールにおけるモジュールタイプのためのエネルギー使用量のうちの少なくとも1つの詳細なリストを含む。
実施例1034は、実施例1029から1033のいずれかの主題を含む。実施例1034では、エネルギーリソースのエニュメレーションの前にアクティブ化段階が行われ、アクティブ化段階は、デバイスへの電力供給、デバイスのハードウェア構成の更新、またはアプリケーションコードの更新のうちの少なくとも1つを含む。
実施例1035は、実施例1029から1034のいずれかの主題を含む。実施例1035では、本方法は、第1の構成について計算された単位時間当たりの総エネルギーを格納するようにデバイスに命令する段階と、マスタデバイスから第2の構成を要求するようにデバイスに命令し、デバイスの第2の構成の単位当たりの第2の総エネルギーを計算する段階と、第1の構成の単位当たりの総エネルギーを第2の構成の単位当たりの第2の総エネルギーと比較する段階と、単位当たりの総エネルギーと単位当たりの2番目の総エネルギーの比較に基づいて第1の構成または第2の構成を要求するようにデバイスに命令する段階と、を含む。
実施例1036は、実施例1029から1035のいずれかの主題を含む。実施例1036では、本方法は、デバイスが有線リソースによって電力を供給されていると判定された場合にアプリケーションを開始するようにデバイスに命令する段階を含む。
実施例1037は、実施例1029から1036のいずれかの主題を含む。実施例1037では、アクティブ期間ごとに複数のモジュールのうちの1つのモジュールの電力消費量を識別することは、モジュールが、そのタスクについてそのモジュールに関連する履歴エネルギー使用量値を取得することを含む。
実施例1038は、実施例1029から1037のいずれかの主題を含む。実施例1038では、本方法は、アプリケーションがスリープモード機能を有するか否かを識別する段階と、アプリケーションがスリープモードになる時間を時間単位でカウントする段階と、アプリケーションのプロセッサがスリープモードになる時間に基づいて節約された総電力に基づいて、使用された総エネルギーを計算する段階と、を含む。
実施例1039は、実行されると、複数のモジュールに電力を供給し制御するように構成されたデバイスのためのエネルギーリソースをエニュメレーションし、複数のモジュールのエネルギー要求をエニュメレーションし、実行時に複数のモジュールのうちの1つのモジュール上で完全に機能するタスクにアプリケーションを分解し、各作動期間について、複数のモジュールのうちの1つのモジュールの消費電力を識別し、タスクが単位時間内に複数のモジュールのうちの1つのモジュールを起動する回数をカウントし、タスクがアクティブである時間、1つのモジュールで完了されたタスクの期間、およびアクティブ期間までにモジュールが必要としたエネルギーに少なくとも部分的に基づいて、複数のモジュールのうちの1つのモジュールによって単位時間に使用される総エネルギーを計算するようにプロセッサに指示する命令を含む非一時的機械可読媒体を含む。
実施例1040は、実施例1039の主題を含む。実施例1040では、非一時的機械可読媒体は、実行されると、複数のモジュールについて単位時間内に使用された総エネルギーと、デバイスのエネルギーリソースと、に基づいてデバイス寿命を生成するようにプロセッサに指示する命令を含む。
実施例1041は、実施例1039または1040のいずれかの主題を含む。実施例1041では、非一時的機械可読媒体は、実行されると、デバイス寿命が、デバイスのアプリケーション分析が始まる前に設定された最小閾値時間以上であるとして計算されるのに応答して、アプリケーションを開始するようにプロセッサに指示する命令を含む。
実施例1042は、実施例1039から1041のいずれかの主題を含む。実施例1042では、非一時的機械可読媒体は、実行されると、デバイス寿命が、デバイスのアプリケーション分析が始まる前に設定された最小閾値時間未満として計算されるのに応答して、新しい構成がマスタデバイスに送信されることを要求するようにプロセッサに指示する命令を含む。
実施例1043は、実施例1039から1042のいずれかの主題を含む。実施例1043では、新しい構成の要求は、モジュール上のタスクのためのエネルギー使用量、単位時間中にモジュールによって使用されたエネルギー、および複数のモジュールにおけるモジュールタイプのためのエネルギー使用量のうちの少なくとも1つの詳細なリストを含む。
実施例1044は、実施例1039から1043のいずれかの主題を含む。実施例1044では、エネルギーリソースのエニュメレーションの前にアクティブ化段階が行われ、アクティブ化段階は、デバイスへの電力供給、デバイスのハードウェア構成の更新、およびアプリケーションコードの更新のうちの少なくとも1つを含む。
実施例1045は、実施例1039から1044のいずれかの主題を含む。実施例1045では、非一時的機械可読媒体は、実行されると、第1の構成について計算された単位時間当たりの総エネルギーを格納し、マスタデバイスから第2の構成を要求するようにデバイスに命令し、デバイスの第2の構成の単位当たりの第2の総エネルギーを計算し、第1の構成の単位当たりの総エネルギーを第2の構成の単位当たりの第2の総エネルギーと比較し、単位当たりの総エネルギーと単位当たりの2番目の総エネルギーの比較に基づいて第1の構成または第2の構成を要求するようにデバイスに命令するようにプロセッサに指示する命令を含む。
実施例1046は、実施例1039から1045のいずれかの主題を含む。実施例1046において、非一時的機械可読媒体は、実行されると、デバイスが有線リソースによって電力を供給されていると判定された場合にアプリケーションの起動をプロセッサに指示する命令を含む。
実施例1047は、実施例1039から1046のいずれかの主題を含む。実施例1047では、アクティブ期間ごとに複数のモジュールのうちの1つのモジュールの電力消費量を識別することは、モジュールが、そのタスクについてそのモジュールに関連する履歴エネルギー使用量値を取得することを含む。
実施例1048は、実施例1039から1047のいずれかの主題を含む。実施例1048では、非一時的機械可読媒体は、実行されると、アプリケーションがスリープモード機能を有するか否かを識別し、アプリケーションがスリープモードになる時間を時間単位でカウントし、アプリケーションのプロセッサがスリープモードになる時間に基づいて節約された総電力に基づいて、使用された総エネルギーを計算するようにプロセッサに指示する命令を含む。
実施例1049は、信号調整のためのカスタムハードウェアを作成するための装置を含む。信号調整のためのカスタムハードウェアを作成するための装置は、自己記述型デバイスを含む。装置はまた、自己記述型センサモジュールへの接続を検出するためのフィールドプログラマブルゲートアレイと、自己記述型センサモジュールから受信したデータを処理し、受信したデータは自己記述型センサモジュールに関する信号調整情報を示し、自己記述型デバイスのフィールドプログラマブルゲートアレイ上に実装されるフィールドプログラマブルゲートアレイコードを生成し、自己記述型センサモジュールから受信した生データを修正して、信号調整情報に基づいてフィールドプログラマブルゲートアレイを使用して信号調整データを生成するためのプロセッサとを含む。
実施例1050は、実施例1049の主題を含む。実施例1050では、プロセッサは、フィールドプログラマブルゲートアレイがフィールドプログラマブルゲートアレイコードをサポートできないことを検出する。
実施例1051は、実施例1049または1050のいずれかの主題を含む。実施例1051では、プロセッサは、フィールドプログラマブルゲートアレイブロックが自己記述型センサモジュールから受信した生データを信号調整するのに十分であることの検出に応答して既存のフィールドプログラマブルゲートアレイブロックを接続する。
実施例1052は、実施例1049から1051のいずれかの主題を含む。実施例1052では、プロセッサは、識別されたフィールドプログラマブルゲートアレイ特性および自己記述型デバイス特性を送信する。
実施例1053は、実施例1049から1052のいずれかの主題を含む。実施例1053では、プロセッサは、マスタデバイスへ要求を送信し、その要求はフィールドプログラマブルゲートアレイ特性と自己記述型デバイス特性とを含み、要求は、自己記述型デバイスが制約されていることの検出と、自己記述型デバイスのフィールドプログラマブルゲートアレイに十分な構成可能な信号調整ブロックがないことの検出と、に応答して送信される。
実施例1054は、実施例1049から1053のいずれかの主題を含む。実施例1054では、要求は、マスタデバイスによって生成されたフィールドプログラマブルゲートアレイコードを生成し返す。
実施例1055は、実施例1049から1054のいずれかの主題を含む。実施例1055では、バッテリ電源、無線技術に基づくインターネット接続、または低電力モードを有するプロセッサのうちの少なくとも1つを含む自己記述型デバイスは、制約付き自己記述型デバイスとみなされる。
実施例1056は、実施例1049から1055のいずれかの主題を含む。実施例1056では、プロセッサは、自己記述型デバイスが制約されているという検出に応答して、自己記述型センサモジュールに関する信号調整情報およびデバイス情報を制約されていないデバイスに送信する。
実施例1057は、実施例1049から1056のいずれかの主題を含む。実施例1057では、プロセッサは、自己記述型デバイスのフィールドプログラマブルゲートアレイに実装されるリターンフィールドプログラマブルゲートアレイコードを生成するための要求を制約のないデバイスに送信する。
実施例1058は、実施例1049から1057のいずれかの主題を含む。実施例1058では、プロセッサは、自己記述型デバイスが制約されているという検出に応答して、自己記述型センサモジュールに関する信号調整情報およびデバイス情報を第2の制約のあるデバイスに送信し、第2の制約のあるデバイスは制約されていないデバイスにアクセスできる。
実施例1059は、カスタム信号調整ハードウェアを作成する方法を含む。カスタム信号調整ハードウェアを作成する方法は、自己記述型センサモジュールの自己記述型デバイスへの接続に応答して自己記述型センサモジュールを検出する段階であって、自己記述型デバイスはフィールドプログラマブルゲートアレイを含む、段階と、自己記述型センサモジュールから受信したデータを処理する段階であって、受信したデータは自己記述型センサモジュールに関する信号調整情報を示す、段階と、自己記述型デバイスのフィールドプログラマブルゲートアレイ上に実装されるフィールドプログラマブルゲートアレイコードを生成する段階と、自己記述型センサモジュールから受信した生データを修正して、信号調整情報に基づいてフィールドプログラマブルゲートアレイを使用して信号調整データを生成する、段階と、を含む。
実施例1060は、実施例1059の主題を含む。実施例1060では、本方法は、フィールドプログラマブルゲートアレイがフィールドプログラマブルゲートアレイコードをサポートすることができないことを検出する段階を含む。
実施例1061は、実施例1059または1060のいずれかの主題を含む。実施例1061では、本方法は、フィールドプログラマブルゲートアレイブロックが自己記述型センサモジュールから受信した生データを信号調整するのに十分であることの検出に応答して既存のフィールドプログラマブルゲートアレイブロックを接続する段階を含む。
実施例1062は、実施例1059から1061のいずれかの主題を含む。実施例1062では、本方法は、識別されたフィールドプログラマブルゲートアレイ特性および自己記述型デバイス特性を送信する段階を含む。
実施例1063は、実施例1059から1062のいずれかの主題を含む。実施例1063では、本方法は、マスタデバイスへ要求を送信する段階であって、その要求はフィールドプログラマブルゲートアレイ特性と自己記述型デバイス特性とを含み、要求は、自己記述型デバイスが制約されていることの検出と、自己記述型デバイスのフィールドプログラマブルゲートアレイに十分な構成可能な信号調整ブロックがないことの検出と、に応答して送信される、段階を含む。
実施例1064は、実施例1059から1063のいずれかの主題を含む。実施例1064では、要求は、マスタデバイスによって生成されたフィールドプログラマブルゲートアレイコードを生成し返す。
実施例1065は、実施例1059から1064のいずれかの主題を含む。実施例1065では、バッテリ電源、無線技術に基づくインターネット接続、または低電力モードを有するプロセッサのうちの少なくとも1つを含む自己記述型デバイスは、制約付き自己記述型デバイスとみなされる。
実施例1066は、実施例1059から1065のいずれかの主題を含む。実施例1066では、本方法は、自己記述型デバイスが制約されているという検出に応答して、自己記述型センサモジュールに関する信号調整情報およびデバイス情報を制約されていないデバイスに送信する段階を含む。
実施例1067は、実施例1059から1066のいずれかの主題を含む。実施例1067では、本方法は、自己記述型デバイスのフィールドプログラマブルゲートアレイに実装されるリターンフィールドプログラマブルゲートアレイコードを生成するための要求を制約されていないデバイスに送信する段階を含む。
実施例1068は、実施例1059から1067のいずれかの主題を含む。実施例1068では、本方法は、自己記述型デバイスが制約されているという検出に応答して、自己記述型センサモジュールに関する信号調整情報およびデバイス情報を第2の制約のあるデバイスに送信する段階であって、第2の制約のあるデバイスは制約されていないデバイスにアクセスできる、段階を含む。
実施例1069は、実行されると、自己記述型センサモジュールの自己記述型デバイスへの接続に応答して自己記述型センサモジュールを検出し、自己記述型デバイスはフィールドプログラマブルゲートアレイを含み、自己記述型センサモジュールから受信したデータを処理し、受信したデータは自己記述型センサモジュールに関する信号調整情報を示し、自己記述型デバイスのフィールドプログラマブルゲートアレイ上に実装されるフィールドプログラマブルゲートアレイコードを生成し、自己記述型センサモジュールから受信した生データを修正して、信号調整情報に基づいてフィールドプログラマブルゲートアレイを使用して信号調整データを生成するようにプロセッサに指示する命令を含む、非一時的機械可読媒体を含む。
実施例1070は、実施例1069の主題を含む。実施例1070では、機械可読媒体は、実行されると、フィールドプログラマブルゲートアレイがフィールドプログラマブルゲートアレイコードをサポートできないことを検出するようにプロセッサに指示する命令を含む。
実施例1071は、実施例1069または1070のいずれかの主題を含む。実施例1071では、機械可読媒体は、実行されると、フィールドプログラマブルゲートアレイブロックが自己記述型センサモジュールから受信した生データを信号調整するのに十分であることの検出に応答して既存のフィールドプログラマブルゲートアレイブロックを接続するようにプロセッサに指示する命令を含む。
実施例1072は、実施例1069から1071のいずれかの主題を含む。実施例1072では、機械可読媒体は、実行されると、識別されたフィールドプログラマブルゲートアレイ特性および自己記述型デバイス特性を送信するようにプロセッサに指示する命令を含む。
実施例1073は、実施例1069から1072のいずれかの主題を含む。実施例1073では、機械可読媒体は、実行されるとマスタデバイスへ要求を送信するようにプロセッサに指示する命令を含み、その要求はフィールドプログラマブルゲートアレイ特性と自己記述型デバイス特性とを含み、要求は、自己記述型デバイスが制約されていることの検出と、自己記述型デバイスのフィールドプログラマブルゲートアレイに十分な構成可能な信号調整ブロックがないことの検出と、に応答して送信される。
実施例1074は、実施例1069から1073のいずれかの主題を含む。実施例1074では、要求は、マスタデバイスによって生成されたフィールドプログラマブルゲートアレイコードを生成し返す。
実施例1075は、実施例1069から1074のいずれかの主題を含む。実施例1075では、バッテリ電源、無線技術に基づくインターネット接続、または低電力モードを有するプロセッサのうちの少なくとも1つを含む自己記述型デバイスは、制約付き自己記述型デバイスとみなされる。
実施例1076は、実施例1069から1075のいずれかの主題を含む。実施例1076では、機械可読媒体は、実行されると、自己記述型デバイスが制約されているという検出に応答して、自己記述型センサモジュールに関する信号調整情報およびデバイス情報を制約されていないデバイスに送信するようにプロセッサに指示する命令を含む。
実施例1077は、実施例1069から1076のいずれかの主題を含む。実施例1077では、機械可読媒体は、実行されると、自己記述型デバイスのフィールドプログラマブルゲートアレイに実装されるリターンフィールドプログラマブルゲートアレイコードを生成するための要求を制約のないデバイスに送信するようにプロセッサに指示する命令を含む。
実施例1078は、実施例1069から1077のいずれかの主題を含む。実施例1078では、機械可読媒体は、実行されると、自己記述型デバイスが制約されているという検出に応答して、自己記述型センサモジュールに関する信号調整情報およびデバイス情報を第2の制約のあるデバイスに送信するようにプロセッサに指示する命令を含み、第2の制約のあるデバイスは制約されていないデバイスにアクセスできる。
実施例1079は、装置を含む。装置は、モノのインターネット(IoT)デバイスを備える。IoTデバイスは、ネットワークに対する受信されたネットワーク健全性要求に応答して、サブネットワークからサブネットワーク健全性データを要求するサブネットワーク健全性データ要求部と、ブロックチェーンデータから生成された受信したサブネットワーク健全性データに基づいて、ネットワークシャドウフィルタを修正するためのネットワークシャドウフィルタ修正部と、ネットワークシャドウフィルタに基づいて、ネットワーク健全性の報告を提供するための報告提供部と、を含む。
実施例1080は、実施例1079の主題を含む。実施例1080では、サブネットワークは、サブネットワーク健全性データ要求の受信に応答してデバイスからデバイス健全性データを要求する。
実施例1081は、実施例1079または1080のいずれかの主題を含む。実施例1081では、サブネットワークは、受信されたデバイス健全性データから生成されたブロックチェーンデータを使用してサブネットワークシャドウフィルタを修正することによってサブネットワーク健全性データを生成するように命令される。
実施例1082は、実施例1079から1081のいずれかの主題を含む。実施例1082では、サブネットワークは、サブネットワーク健全性データ要求の受信に応答して複数のデバイスからデバイス健全性データを要求する。
実施例1083は、実施例1079から1082のいずれかの主題を含む。実施例1083では、サブネットワークは、論理演算子を使用して受信した複数の健全性データを比較することによって、受信した複数のデバイス健全性データを使用してサブネットワークシャドウフィルタを修正することによってサブネットワーク健全性データを生成するように命令される。
実施例1084は、実施例1079から1083のいずれかの主題を含む。実施例1084では、デバイスは、デバイスシャドウフィルタに基づいてデバイス健全性データを返し、デバイスシャドウフィルタは、デバイス上のスケジュールされた健全性メッセージの欠如を追跡するデバイスブルームフィルタに基づいて生成される。
実施例1085は、実施例1079から1084のいずれかの主題を含む。実施例1085では、デバイスシャドウフィルタは複数のシャドウフィルタを含み、それぞれが、複数のブルームフィルタの時間間隔に対応する。
実施例1086は、実施例1079から1085のいずれかの主題を含む。実施例1086では、ネットワークシャドウフィルタは、少なくともサブネットワークと他の1つのサブネットワークとを含むセットに適用される論理演算子の適用を通じて動作する。
実施例1087は、実施例1079から1086のいずれかの主題を含む。実施例1087では、装置は、ネットワーク内で論理的に編成された複数のサブネットワークからのサブネットワーク健全性データ、およびいくつかの受信されたサブネットワーク健全性データに基づいてネットワークシャドウフィルタを修正するネットワークシャドウフィルタ変更子を要求するためのサブネットワーク健全性データリクエスタを含む。
実施例1088は、実施例1079から1087のいずれかの主題を含む。実施例1088では、ブロックチェーンデータは、ネットワークトポグラフィの各エンドポイントでネットワーク健全性の履歴記録を確立するためにブロックチェーントランザクションに含まれ得るブルームフィルタに基づく。
実施例1089は、ネットワークおよびネットワークデバイスの健全性を報告するためにモノのインターネット(IoT)デバイスを使用するための方法を含む。ネットワークおよびネットワークデバイスの健全性を報告するためにモノのインターネット(IoT)デバイスを使用するための方法は、ネットワークに対する受信されたネットワーク健全性要求に応答して、サブネットワークからサブネットワーク健全性データを要求する段階と、ブロックチェーンデータから生成された受信したサブネットワーク健全性データに基づいて、ネットワークシャドウフィルタを修正する段階と、ネットワークシャドウフィルタに基づいて、ネットワーク健全性の報告を提供する段階と、を含む。
実施例1090は、実施例1089の主題を含む。実施例1090では、サブネットワークは、サブネットワーク健全性データ要求の受信に応答してデバイスからデバイス健全性データを要求する。
実施例1091は、実施例1089または1090のいずれかの主題を含む。実施例1091では、サブネットワークは、受信されたデバイス健全性データから生成されたブロックチェーンデータを使用してサブネットワークシャドウフィルタを修正することによってサブネットワーク健全性データを生成するように命令される。
実施例1092は、実施例1089から1091のいずれかの主題を含む。実施例1092では、サブネットワークは、サブネットワーク健全性データ要求の受信に応答して複数のデバイスからデバイス健全性データを要求する。
実施例1093は、実施例1089から1092のいずれかの主題を含む。実施例1093では、サブネットワークは、論理演算子を使用して受信した複数の健全性データを比較することによって、受信した複数のデバイス健全性データを使用してサブネットワークシャドウフィルタを修正することによってサブネットワーク健全性データを生成するように命令される。
実施例1094は、実施例1089から1093のいずれかの主題を含む。実施例1094では、デバイスは、デバイスシャドウフィルタに基づいてデバイス健全性データを返し、デバイスシャドウフィルタは、デバイス上のスケジュールされた健全性メッセージの欠如を追跡するデバイスブルームフィルタに基づいて生成される。
実施例1095は、実施例1089から1094のいずれかの主題を含む。実施例1095では、デバイスシャドウフィルタは複数のシャドウフィルタを含み、それぞれが、複数のブルームフィルタの時間間隔に対応する。
実施例1096は、実施例1089から1095のいずれかの主題を含む。実施例1096では、ネットワークシャドウフィルタは、少なくともサブネットワークと他の1つのサブネットワークとを含むセットに適用される論理演算子の適用を通じて動作する。
実施例1097は、実施例1089から1096のいずれかの主題を含む。実施例1097では、本方法は、ネットワークに論理的に編成された複数のサブネットワークからサブネットワーク健全性データを要求する段階と、受信した複数のサブネットワーク健全性データに基づいてネットワークシャドウフィルタを修正する段階と、を含む。
実施例1098は、実施例1089から1097のいずれかの主題を含む。実施例1098では、ブロックチェーンデータは、ネットワークトポグラフィの各エンドポイントでネットワーク健全性の履歴記録を確立するためにブロックチェーントランザクションに含まれ得るブルームフィルタに基づく。
実施例1099は、実行されると、ネットワークに対する受信されたネットワーク健全性要求に応答して、サブネットワークからサブネットワーク健全性データを要求し、ブロックチェーンデータから生成された受信したサブネットワーク健全性データに基づいて、ネットワークシャドウフィルタを修正し、ネットワークシャドウフィルタに基づいて、ネットワーク健全性の報告を提供するようにプロセッサに指示する命令を含む、非一時的機械可読媒体を含む。
実施例1100は、実施例1099の主題を含む。実施例1100では、サブネットワークは、サブネットワーク健全性データ要求の受信に応答してデバイスからデバイス健全性データを要求する。
実施例1101は、実施例1099または1100のいずれかの主題を含む。実施例1101では、サブネットワークは、受信されたデバイス健全性データから生成されたブロックチェーンデータを使用してサブネットワークシャドウフィルタを修正することによってサブネットワーク健全性データを生成するように命令される。
実施例1102は、実施例1099から1101のいずれかの主題を含む。実施例1102では、サブネットワークは、サブネットワーク健全性データ要求の受信に応答して複数のデバイスからデバイス健全性データを要求する。
実施例1103は、実施例1099から1102のいずれかの主題を含む。実施例1103では、サブネットワークは、論理演算子を使用して受信した複数の健全性データを比較することによって、受信した複数のデバイス健全性データを使用してサブネットワークシャドウフィルタを修正することによってサブネットワーク健全性データを生成するように命令される。
実施例1104は、実施例1099から1103のいずれかの主題を含む。実施例1104では、デバイスは、デバイスシャドウフィルタに基づいてデバイス健全性データを返し、デバイスシャドウフィルタは、デバイス上のスケジュールされた健全性メッセージの欠如を追跡するデバイスブルームフィルタに基づいて生成される。
実施例1105は、実施例1099から1104のいずれかの主題を含む。実施例1105では、デバイスシャドウフィルタは複数のシャドウフィルタを含み、それぞれが、複数のブルームフィルタの時間間隔に対応する。
実施例1106は、実施例1099から1105のいずれかの主題を含む。実施例1106では、ネットワークシャドウフィルタは、少なくともサブネットワークと他の1つのサブネットワークとを含むセットに適用される論理演算子の適用を通じて動作する。
実施例1107は、実施例1099から1106のいずれかの主題を含む。実施例1107では、機械可読媒体は、実行されると、ネットワークに論理的に編成された複数のサブネットワークからサブネットワーク健全性データを要求し、受信した複数のサブネットワーク健全性データに基づいてネットワークシャドウフィルタを修正するようにプロセッサに指示する命令を含む。
実施例1108は、実施例1099から1107のいずれかの主題を含む。実施例1108では、ブロックチェーンデータは、ネットワークトポグラフィの各エンドポイントでネットワーク健全性の履歴記録を確立するためにブロックチェーントランザクションに含まれ得るブルームフィルタに基づく。
実施例1109は、モノのインターネット(IoT)デバイスを備える装置を含む。モノのインターネット(IoT)装置は、制御チャネルデータを広域ネットワークフレームに挿入するための制御チャネルデータ挿入部と、広域ネットワークフレームを第1の送信プロトコルを有する第1のデバイスおよび第2のプロトコルを有する第2のデバイスに送信するためのフレーム送信部であって、制御チャネルデータは、第1のデバイスおよび第1のデバイスのプロトコルならびに第2のデバイスと第2のデバイスのプロトコルの両方にアクセスできるようになる、フレーム送信部と、第1のデバイスが送信ノードからの検出された送信を返すことに応答して、送信ノードデータを修正するためのデータ修正部と、を含む。
実施例1110は、実施例1109の主題を含む。実施例1110では、広域ネットワークフレームは、送信前および送信中に制御チャネルデータをカプセル化するためのアプリケーションペイロードフレームフィールドを含む。
実施例1111は、実施例1109または1110のいずれかの主題を含む。実施例1111では、制御チャネルデータは、第1のデバイスが送信ノードからペイロードを収集し、ペイロードからタイムスタンプを抽出し、タイムスタンプおよびゾーンIDを含むペイロードを返すための命令を含む。
実施例1112は、実施例1109から1111のいずれかの主題を含む。実施例1112では、フレーム送信部は、中間送信機として動作し、第2のデバイスに再送信するための第1のデバイスへの命令を通して、広域ネットワークフレームを第2のデバイスに送信する。
実施例1113は、実施例1109から1112のいずれかの主題を含む。実施例1113では、制御チャネルデータは、メッセージヘッダ、ゾーンIDフィールド、制御メッセージデータフィールド、およびセキュリティフィールドを含む。
実施例1114は、実施例1109から1113のいずれかの主題を含む。実施例1114では、送信ノードデータの変更は、送信ノードから検出された送信を返すゾーンIDおよびタイムスタンプを抽出することに基づく。
実施例1115は、実施例1109から1114のいずれかの主題を含む。実施例1115では、制御チャネルデータは、第1のデバイスがそのゾーンIDおよび送信ノードからの複数のタイムスタンプを返すための命令を含む。
実施例1116は、実施例1109から1115のいずれかの主題を含む。実施例1116では、制御チャネルデータは、第2のデバイスが第1のデバイスにそのゾーンIDと送信ノードからのタイムスタンプとを返すための命令を含み、第2のデバイスは第1のデバイスを通過すること以外にサーバデバイスへの通信経路を持たない。
実施例1117は、実施例1109から1116のいずれかの主題を含む。実施例1117では、本装置は、双曲線関数と、第1のデバイスおよび第2のデバイスによって受信されたパッケージの複数のタイムスタンプと、第1のデバイスおよび第2のデバイスのゾーンIDと、を使用して送信ノードの位置を計算する計算部を含む。
実施例1118は、実施例1109から1117のいずれかの主題を含む。実施例1118では、本装置は、信号検出デバイスと信号受信デバイスとの間の送信通過時間に基づいて送信ノードの位置を計算する計算部を含む。
実施例1119は、リソースおよび地理位置情報セクタの識別情報を発見するためにモノのインターネット(IoT)デバイスを使用するための方法を含む。リソースおよび地理位置情報セクタ識別情報を発見するためにモノのインターネット(IoT)デバイスを使用するための方法は、制御チャネルデータを広域ネットワークフレームに挿入する段階と、広域ネットワークフレームを第1の送信プロトコルを有する第1のデバイスおよび第2のプロトコルを有する第2のデバイスに送信する段階であって、制御チャネルデータは、第1のデバイスおよび第1のデバイスのプロトコルならびに第2のデバイスと第2のデバイスのプロトコルの両方にアクセスできるようになる、段階と、第1のデバイスが送信ノードからの検出された送信を返すことに応答して、送信ノードデータを修正する段階と、を含む。
実施例1120は、実施例1119の主題を含む。実施例1120では、広域ネットワークフレームは、送信前および送信中に制御チャネルデータをカプセル化するためのアプリケーションペイロードフレームフィールドを含む。
実施例1121は、実施例1119または1120のいずれかの主題を含む。実施例1121では、制御チャネルデータは、第1のデバイスが送信ノードからペイロードを収集し、ペイロードからタイムスタンプを抽出し、タイムスタンプおよびゾーンIDを含むペイロードを返すための命令を含む。
実施例1122は、実施例1119から1121のいずれかの主題を含む。実施例1122では、本方法は、中間送信機として動作し、第2のデバイスに再送信するための第1のデバイスへの命令を通して、広域ネットワークフレームを第2のデバイスに送信する段階を含む。
実施例1123は、実施例1119から1122のいずれかの主題を含む。実施例1123では、制御チャネルデータは、メッセージヘッダ、ゾーンIDフィールド、制御メッセージデータフィールド、およびセキュリティフィールドを含む。
実施例1124は、実施例1119から1123のいずれかの主題を含む。実施例1124では、送信ノードデータの変更は、送信ノードから検出された送信を返すゾーンIDおよびタイムスタンプを抽出することに基づく。
実施例1125は、実施例1119から1124のいずれかの主題を含む。実施例1125では、制御チャネルデータは、第1のデバイスがそのゾーンIDおよび送信ノードからの複数のタイムスタンプを返すための命令を含む。
実施例1126は、実施例1119から1125のいずれかの主題を含む。実施例1126では、制御チャネルデータは、第2のデバイスが第1のデバイスにそのゾーンIDと送信ノードからのタイムスタンプとを返すための命令を含み、第2のデバイスは第1のデバイスを通過すること以外にサーバデバイスへの通信経路を持たない。
実施例1127は、実施例1119から1126のいずれかの主題を含む。実施例1127では、本方法は、双曲線関数と、第1のデバイスおよび第2のデバイスによって受信されたパッケージの複数のタイムスタンプと、第1のデバイスおよび第2のデバイスのゾーンIDと、を使用して送信ノードの位置を計算する段階を含む。
実施例1128は、実施例1119から1127のいずれかの主題を含む。実施例1128では、本方法は、信号検出デバイスと信号受信デバイスとの間の送信通過時間に基づいて送信ノードの位置を計算する段階を含む。
実施例1129は、実行時に、制御チャネルデータを広域ネットワークフレームに挿入し、広域ネットワークフレームを第1の送信プロトコルを有する第1のデバイスおよび第2のプロトコルを有する第2のデバイスに送信し、制御チャネルデータは、第1のデバイスおよび第1のデバイスのプロトコルならびに第2のデバイスと第2のデバイスのプロトコルの両方にアクセスできるようになり、第1のデバイスが送信ノードからの検出された送信を返すことに応答して、送信ノードデータを修正するようにプロセッサに指示する命令を含む非一時的機械可読媒体を含む。
実施例1130は、実施例1129の主題を含む。実施例1130では、広域ネットワークフレームは、送信前および送信中に制御チャネルデータをカプセル化するためのアプリケーションペイロードフレームフィールドを含む。
実施例1131は、実施例1129または1130のいずれかの主題を含む。実施例1131では、制御チャネルデータは、第1のデバイスが送信ノードからペイロードを収集し、ペイロードからタイムスタンプを抽出し、タイムスタンプおよびゾーンIDを含むペイロードを返すための命令を含む。
実施例1132は、実施例1129から1131のいずれかの主題を含む。実施例1132では、機械可読媒体は、実行されると、中間送信機として動作し、第2のデバイスに再送信するための第1のデバイスへの命令を通して、広域ネットワークフレームを第2のデバイスに送信するようにプロセッサに指示する命令を含む。
実施例1133は、実施例1129から1132のいずれかの主題を含む。実施例1133では、制御チャネルデータは、メッセージヘッダ、ゾーンIDフィールド、制御メッセージデータフィールド、およびセキュリティフィールドを含む。
実施例1134は、実施例1129から1133のいずれかの主題を含む。実施例1134では、送信ノードデータの変更は、送信ノードから検出された送信を返すゾーンIDおよびタイムスタンプを抽出することに基づく。
実施例1135は、実施例1129から1134のいずれかの主題を含む。実施例1135では、制御チャネルデータは、第1のデバイスがそのゾーンIDおよび送信ノードからの複数のタイムスタンプを返すための命令を含む。
実施例1136は、実施例1129から1135のいずれかの主題を含む。実施例1136では、制御チャネルデータは、第2のデバイスが第1のデバイスにそのゾーンIDと送信ノードからのタイムスタンプとを返すための命令を含み、第2のデバイスは第1のデバイスを通過すること以外にサーバデバイスへの通信経路を持たない。
実施例1137は、実施例1129から1136のいずれかの主題を含む。実施例1137では、機械可読媒体は、実行されると、双曲線関数と、第1のデバイスおよび第2のデバイスによって受信されたパッケージの複数のタイムスタンプと、第1のデバイスおよび第2のデバイスのゾーンIDと、を使用して送信ノードの位置を計算するようにプロセッサに指示する命令を含む。
実施例1138は、実施例1129から1137のいずれかの主題を含む。実施例1138では、機械可読媒体は、実行されると、信号検出デバイスと信号受信デバイスとの間の送信通過時間に基づいて送信ノードの位置を計算するようにプロセッサに指示する命令を含む。
実施例1139はモノのインターネット(IoT)デバイスを備える装置を含む。モノのインターネット(IoT)デバイスは、環境からの代表的なデータセットに基づいて、選択された相互作用型分析環境にデータをロードするためのデータロード部であって、相互作用型分析環境は、データマイニング環境およびデータ融合環境のうちの少なくとも1つである、データロード部と、提案されたモデルがデータにフィットするか否かを判定するためのフィット判定部であって、提案されたモデルは、複数のデバイスで処理するための分解可能部分のワークロードを含む、フィット判定部と、デバイスによる実行のためにワークロードをデバイスにマッピングするためのワークロードマップ部と、を含む。
実施例1140は、実施例1139の主題を含む。実施例1140では、データマイニング環境は、アプリケーションドメインからの、および環境からの代表的なデータセットに対応する格納された知識ベースからのデータを組み込む。
実施例1141は、実施例1139または1140のいずれかの主題を含む。実施例1141では、選択された相互作用型分析環境にロードする前に、データを整理して整理する。
実施例1142は、実施例1139から1141のいずれかの主題を含む。実施例1142では、装置は、デバイスによる実行のためにワークロードをデバイスにマッピングする前にワークロードを分解するための分解部を含み得る。
実施例1143は、実施例1139から1142のいずれかの主題を含む。実施例1143では、ワークロードは、並列処理およびモジュール式直列依存タスクのうちの少なくとも1つを通して分解される。
実施例1144は、実施例1139から1143のいずれかの主題を含む。実施例1144では、ワークロードは、分類タスクのために分解され、前処理、特徴抽出、および分類タスクが分離される。
実施例1145は、実施例1139から1144のいずれかの主題を含む。実施例1145では、装置は、マッピングおよびデバイス上のワークロードの実行に続いて使用されるリソースに関してプラットフォームの性能を計算するためのプロセッサを備える。
実施例1146は、実施例1139から1145のいずれかの主題を含む。実施例1146では、相互作用型分析は、第1のデータサンプルと第2のデータサンプルとの間の時間的関係を示し、相互作用型分析は、第1のサンプルおよび第1のセンサと第2のデータサンプルおよび第2のセンサとの間の関係をさらに示す。
実施例1147は、実施例1139から1146のいずれかの主題を含む。実施例1147では、ワークロードは、ワークロードの計算要件、メモリ要件、およびネットワーク要件のプロファイルを含む。
実施例1148は、実施例1139から1147のいずれかの主題を含む。実施例1148では、ワークロードは、デバイス上の複数のサブワークロードを含み、ワークロードは、必要とされるリソースおよび利用可能なリソースに関してワークロードを分類し、必要とされるリソースおよび利用可能なリソースに基づいて、ワークロードをデバイスにペアリングすることによって得られるデバイスとの合意を含む。
実施例1149は、IoTシステムのデータ分析を提供する方法を含む。IoTシステムのデータ分析を提供する方法は、環境からの代表的なデータセットに基づいて、選択された相互作用型分析環境にデータをロードする段階であって、相互作用型分析環境は、データマイニング環境およびデータ融合環境のうちの少なくとも1つである、段階と、提案されたモデルがデータにフィットするか否かを判定する段階であって、提案されたモデルは、複数のデバイスで処理するための分解可能部分のワークロードを含む、段階と、デバイスによる実行のためにワークロードをデバイスにマッピングする段階と、を含む。
実施例1150は、実施例1149の主題を含む。実施例1150では、データマイニング環境は、アプリケーションドメインからの、および環境からの代表的なデータセットに対応する格納された知識ベースからのデータを組み込む。
実施例1151は、実施例1149または1150のいずれかの主題を含む。実施例1151では、選択された相互作用型分析環境にロードする前に、データを整理して整理する。
実施例1152は、実施例1149から1151のいずれかの主題を含む。実施例1152では、本方法は、デバイスによる実行のためにワークロードをデバイスにマッピングする前にワークロードを分解する段階を含む。
実施例1153は、実施例1149から1152のいずれかの主題を含む。実施例1153では、ワークロードは、並列処理およびモジュール式直列依存タスクのうちの少なくとも1つを通して分解される。
実施例1154は、実施例1149から1153のいずれかの主題を含む。実施例1154では、ワークロードは、分類タスクのために分解され、前処理、特徴抽出、および分類タスクが分離される。
実施例1155は、実施例1149から1154のいずれかの主題を含む。実施例1155では、本方法は、マッピングおよびデバイス上のワークロードの実行に続いて使用されるリソースに関してプラットフォームの性能を計算する段階を含む。
実施例1156は、実施例1149から1155のいずれかの主題を含む。実施例1156では、相互作用型分析は、第1のデータサンプルと第2のデータサンプルとの間の時間的関係を示し、相互作用型分析は、第1のサンプルおよび第1のセンサと第2のデータサンプルおよび第2のセンサとの間の関係をさらに示す。
実施例1157は、実施例1149から1156のいずれかの主題を含む。実施例1157では、ワークロードは、ワークロードの計算要件、メモリ要件、およびネットワーク要件のプロファイルを含む。
実施例1158は、実施例1149から1157のいずれかの主題を含む。実施例1158では、ワークロードは、デバイス上の複数のサブワークロードを含み、ワークロードは、必要とされるリソースおよび利用可能なリソースに関してワークロードを分類し、必要とされるリソースおよび利用可能なリソースに基づいて、ワークロードをデバイスにペアリングすることによって得られるデバイスとの合意を含む。
実施例1159は、実行されると、環境からの代表的なデータセットに基づいて、選択された相互作用型分析環境にデータをロードし、相互作用型分析環境は、データマイニング環境およびデータ融合環境のうちの少なくとも1つであり、提案されたモデルがデータにフィットするか否かを判定し、提案されたモデルは、複数のデバイスで処理するための分解可能部分のワークロードを含み、デバイスによる実行のためにワークロードをデバイスにマッピングするようにプロセッサに指示する命令を含む、非一時的機械可読媒体を含む。
実施例1160は、実施例1159の主題を含む。実施例1160では、データマイニング環境は、アプリケーションドメインからの、および環境からの代表的なデータセットに対応する格納された知識ベースからのデータを組み込む。
実施例1161は、実施例1159または1160のいずれかの主題を含む。実施例1161では、選択された相互作用型分析環境にロードする前に、データを整理して整理する。
実施例1162は、実施例1159から1161のいずれかの主題を含む。実施例1162では、機械可読媒体は、実行されると、デバイスによる実行のためにワークロードをデバイスにマッピングする前にワークロードを分解するようにプロセッサに指示するための命令を含む。
実施例1163は、実施例1159から1162のいずれかの主題を含む。実施例1163では、ワークロードは、並列処理およびモジュール式直列依存タスクのうちの少なくとも1つを通して分解される。
実施例1164は、実施例1159から1163のいずれかの主題を含む。実施例1164では、ワークロードは、分類タスクのために分解され、前処理、特徴抽出、および分類タスクが分離される。
実施例1165は、実施例1159から1164のいずれかの主題を含む。実施例1165では、機械可読媒体は、実行されると、マッピングおよびデバイス上のワークロードの実行に続いて使用されるリソースに関してプラットフォームの性能を計算するようにプロセッサに指示するための命令を含む。
実施例1166は、実施例1159から1165のいずれかの主題を含む。実施例1166では、相互作用型分析は、第1のデータサンプルと第2のデータサンプルとの間の時間的関係を示し、相互作用型分析は、第1のサンプルおよび第1のセンサと第2のデータサンプルおよび第2のセンサとの間の関係をさらに示す。
実施例1167は、実施例1159から1166のいずれかの主題を含む。実施例1167では、ワークロードは、ワークロードの計算要件、メモリ要件、およびネットワーク要件のプロファイルを含む。
実施例1168は、実施例1159から1167のいずれかの主題を含む。実施例1168では、ワークロードは、デバイス上の複数のサブワークロードを含み、ワークロードは、必要とされるリソースおよび利用可能なリソースに関してワークロードを分類し、必要とされるリソースおよび利用可能なリソースに基づいて、ワークロードをデバイスにペアリングすることによって得られるデバイスとの合意を含む。
実施例1169は、装置を含む。装置は、モノのインターネット(IoT)ネットワークを含み、IoTネットワークは、IoTデバイスを含む。IoTデバイスは、IoTネットワーク内の複数のIoTノード間の接続を示すIoTネットワークトポロジを識別するためのIoTネットワークトポロジ識別部と、IoTネットワークトポロジ内で識別された各IoTノードのIoTノードリソースを識別するためのIoTノードリソース識別部と、ノード距離およびノード位置のニューラルネットワークトポロジを識別するためのニューラルネットワークトポロジ識別部と、IoTノードリソース、ノード距離、およびノード位置に基づいてマッピングを最適化するためのマッピング最適化部と、IoTネットワーク上のニューラルネットワークトポロジのオーバーレイに基づいて、複数のIoTノードの分解可能なタスクを処理するための分解可能タスクプロセッサと、を含む。
実施例1170は、実施例1169の主題を含む。実施例1170では、ニューラルネットワークは、人工ニューラルネットワークである。
実施例1171は、実施例1169または1170のいずれかの主題を含む。実施例1171では、最適化されたマッピングは、複数のノードのノード位置を使用して同一の物理的位置に位置する1つまたは複数のノードを識別することによって、IoTネットワークにわたって分解可能タスクを処理する位置を保存する。
実施例1172は、実施例1169から1171のいずれかの主題を含む。実施例1172では、IoTネットワークトポロジは、ノード間距離、クラスタリング、分散情報、受信信号強度、および信号雑音比のうちの少なくとも1つを含むノード特性を示す。
実施例1173は、実施例1169から1172のいずれかの主題を含む。実施例1173では、IoTネットワークトポロジを識別することは、複数のノードの互いの近接性、複数のノードの現在の電力レベル、および複数のノードに関する信号測定を判定することを含む。
実施例1174は、実施例1169から1173のいずれかの主題を含む。実施例1174では、複数のノードの信号測定値を取得することは、少なくとも受信信号強度インジケータまたはブロードキャスト電力を取得することを介してであり得る。
実施例1175は、実施例1169から1174のいずれかの主題を含む。実施例1175では、IoTノードリソースは、電力レベル、利用可能なストレージスペース、現在の処理負荷、ネットワーキング能力、稼働時間、またはノードの信頼性情報のうちの少なくとも1つを含む。
実施例1176は、実施例1169から1175のいずれかの主題を含む。実施例1176では、複数のIoTノードにおける分解可能なタスクの処理は、IoTノードが同じネットワーク上の物理的な位置に位置すると識別されたか否かに基づいて分解可能なタスクの部分を複数のIoTノードにディスパッチすることを含む。
実施例1177は、実施例1169から1176のいずれかの主題を含む。実施例1177では、ニューラルネットワークトポロジのオーバーレイは、入力層、隠蔽層、および出力層を少なくとも含む3つの層を含む。
実施例1178は、実施例1169から1177のいずれかの主題を含む。実施例1178では、マッピングの最適化は、入力ノードから出力ノードへの情報の送信のための送信時間を含む。
実施例1179は、分散型ニューラルネットワークマッピングおよびリソース管理のためにモノのインターネット(IoT)デバイスを使用するための方法を含む。モノのインターネット(IoT)デバイスを分散型ニューラルネットワークマッピングおよびリソース管理に使用するための方法は、IoTネットワーク内の複数のIoTノード間の接続を示すIoTネットワークトポロジを識別する段階と、IoTネットワークトポロジ内で識別された各IoTノードのIoTノードリソースを識別する段階と、ノード距離およびノード位置のニューラルネットワークトポロジを識別する段階と、IoTノードリソース、ノード距離、およびノード位置に基づいてマッピングを最適化する段階と、IoTネットワーク上のニューラルネットワークトポロジのオーバーレイに基づいて、複数のIoTノードの分解可能なタスクを処理する段階と、を含む。
実施例1180は、実施例1179の主題を含む。実施例1180では、ニューラルネットワークは、人工ニューラルネットワークである。
実施例1181は、実施例1179または1180のいずれかの主題を含む。実施例1181では、最適化されたマッピングは、複数のノードのノード位置を使用して同一の物理的位置に位置する1つまたは複数のノードを識別することによって、IoTネットワークにわたって分解可能タスクを処理する位置を保存する。
実施例1182は、実施例1179から1181のいずれかの主題を含む。実施例1182では、IoTネットワークトポロジは、ノード間距離、クラスタリング、分散情報、受信信号強度、および信号雑音比のうちの少なくとも1つを含むノード特性を示す。
実施例1183は、実施例1179から1182のいずれかの主題を含む。実施例1183では、IoTネットワークトポロジを識別することは、複数のノードの互いの近接性、複数のノードの現在の電力レベル、および複数のノードに関する信号測定を判定することを含む。
実施例1184は、実施例1179から1183のいずれかの主題を含む。実施例1184では、複数のノードの信号測定値を取得することは、少なくとも受信信号強度インジケータまたはブロードキャスト電力を取得することを介してであり得る。
実施例1185は、実施例1179から1184のいずれかの主題を含む。実施例1185では、IoTノードリソースは、電力レベル、利用可能なストレージスペース、現在の処理負荷、ネットワーキング能力、稼働時間、またはノードの信頼性情報のうちの少なくとも1つを含む。
実施例1186は、実施例1179から1185のいずれかの主題を含む。実施例1186では、複数のIoTノードにおける分解可能なタスクの処理は、IoTノードが同じネットワーク上の物理的な位置に位置すると識別されたか否かに基づいて分解可能なタスクの部分を複数のIoTノードにディスパッチすることを含む。
実施例1187は、実施例1179から1186のいずれかの主題を含む。実施例1187では、ニューラルネットワークトポロジのオーバーレイは、入力層、隠蔽層、および出力層を少なくとも含む3つの層を含む。
実施例1188は、実施例1179から1187のいずれかの主題を含む。実施例1188では、マッピングの最適化は、入力ノードから出力ノードへの情報の送信のための送信時間を含む。
実施例1189は、実行されたときに、IoTネットワーク内の複数のIoTノード間の接続を示すIoTネットワークトポロジを識別し、IoTネットワークトポロジ内で識別された各IoTノードのIoTノードリソースを識別し、ノード距離およびノード位置のニューラルネットワークトポロジを識別し、IoTノードリソース、ノード距離、およびノード位置に基づいてマッピングを最適化し、IoTネットワーク上のニューラルネットワークトポロジのオーバーレイに基づいて、複数のIoTノードの分解可能なタスクを処理するようにプロセッサに指示する命令を含む、非一時的機械可読媒体を含む。
実施例1190は、実施例1189の主題を含む。実施例1190では、ニューラルネットワークは、人工ニューラルネットワークである。
実施例1191は、実施例1189または1190のいずれかの主題を含む。実施例1191では、最適化されたマッピングは、複数のノードのノード位置を使用して同一の物理的位置に位置する1つまたは複数のノードを識別することによって、IoTネットワークにわたって分解可能タスクを処理する位置を保存する。
実施例1192は、実施例1189から1191のいずれかの主題を含む。実施例1192では、IoTネットワークトポロジは、ノード間距離、クラスタリング、分散情報、受信信号強度、および信号雑音比のうちの少なくとも1つを含むノード特性を示す。
実施例1193は、実施例1189から1192のいずれかの主題を含む。実施例1193では、IoTネットワークトポロジを識別することは、複数のノードの互いの近接性、複数のノードの現在の電力レベル、および複数のノードに関する信号測定を判定することを含む。
実施例1194は、実施例1189から1193のいずれかの主題を含む。実施例1194では、複数のノードの信号測定値を取得することは、少なくとも受信信号強度インジケータまたはブロードキャスト電力を取得することを介してであり得る。
実施例1195は、実施例1189から1194のいずれかの主題を含む。実施例1195では、IoTノードリソースは、電力レベル、利用可能なストレージスペース、現在の処理負荷、ネットワーキング能力、稼働時間、またはノードの信頼性情報のうちの少なくとも1つを含む。
実施例1196は、実施例1189から1195のいずれかの主題を含む。実施例1196では、複数のIoTノードにおける分解可能なタスクの処理は、IoTノードが同じネットワーク上の物理的な位置に位置すると識別されたか否かに基づいて分解可能なタスクの部分を複数のIoTノードにディスパッチすることを含む。
実施例1197は、実施例1189から1196のいずれかの主題を含む。実施例1197では、ニューラルネットワークトポロジのオーバーレイは、入力層、隠蔽層、および出力層を少なくとも含む3つの層を含む。
実施例1198は、実施例1189から1197のいずれかの主題を含む。実施例1198では、マッピングの最適化は、入力ノードから出力ノードへの情報の送信のための送信時間を含む。
実施例1199は、モノのインターネット(IoT)デバイスを含む装置を含む。装置は、モノのインターネット(IoT)デバイスを備える。IoTデバイスは、IoTデバイス内にブロックチェーンを維持し、他のIoTデバイスにわたってブロックチェーンを伝播させるためのブロックチェーンロジックと、ブロックチェーン内の各ブロックに関連付けられたハッシュコードエントリを含むマークルツリーであって、マークルツリー内のエントリが、下位レベルネットワークのための下位ブロックチェーンに関連付けられた下位レベルのマークルツリーへの参照を含む、マークルツリーと、ブロックチェーン内のターゲットブロックを見つけるためにマークルツリーでターゲットハッシュコードを探索するロケータであって、ロケータが下位レベルのマークルツリーへの参照に遭遇した場合、ロケータは下位レベルのマークルツリーでターゲットブロックを探索する、ロケータと、を含む。
実施例1200は、実施例1199の主題を含む。実施例1200では、参照は、下位レベルネットワーク内の下位レベルマークルツリーへのリンクを含むネットワーク参照を含む。
実施例1201は、実施例1199または1200のいずれかの主題を含む。実施例1201では、参照は、IoTデバイス内の下位レベルのマークルツリーのコピーへのリンクを含む。
実施例1202は、実施例1199から1201のいずれかの主題を含む。実施例1202では、本装置は、ブロックチェーンのためのマークルツリーを構築するためのインデクサを含む。
実施例1203は、実施例1199から1202のいずれかの主題を含む。実施例1203では、本装置は、IoTデバイス内にコヒーレントキャッシュを構築するためのキャッシュ作成部を含み、コヒーレントキャッシュは、下位レベルマークルツリーのコピーを含む。
実施例1204は、実施例1199から1203のいずれかの主題を含む。実施例1204では、本装置は、IoTデバイス内にコヒーレントキャッシュを維持するためのキャッシュエージェントを含み、キャッシュエージェントは、キャッシュコヒーレンシイベントについてキャッシュエージェントに通知するために、下位レベルネットワーク内のデバイスからの通知にサブスクライブする。
実施例1205は、実施例1199から1204のいずれかの主題を含む。実施例1205では、キャッシュエージェントは、キャッシュコヒーレンシイベントを、上位レベルのネットワーク内の上位レベルのキャッシュエージェントにパブリッシュする。
実施例1206は、階層型ブロックチェーン内のブロックを見つけるための方法を含む。階層型ブロックチェーン内のブロックを見つけるための方法は、ブロックのハッシュ値を取得する段階と、現在のネットワークレベルで現在のブロックチェーンを階層型ブロックチェーンのルートに設定する段階と、ブロックハッシュ値を現在のブロックチェーンのマークルツリー内の値と比較する段階と、ハッシュ値が子ブロックチェーンの同期ブロックにマッピングされるか否かを判定する段階と、そうであれば、現在のブロックチェーンを子ブロックチェーンに設定し、現在のブロックチェーン内でブロックを見つけ、ブロックを取得する、段階と、を含む。
実施例1207は、実施例1206の主題を含む。実施例1207では、ハッシュ値を取得する段階は、テーブル内でハッシュ値を検索する段階を含む。
実施例1208は、実施例1206または1207のいずれかの主題を含む。実施例1208では、ハッシュ値を取得する段階は、ハッシュ値を計算する段階を含む。
実施例1209は、実施例1206から1208のいずれかの主題を含む。実施例1209では、現在のブロックチェーンを子ブロックチェーンに設定する段階は、ネットワーク参照を下位レベルのブロックチェーンに設定する段階と、下位レベルのブロックチェーン内で探索を続ける段階と、を含む。
実施例1210は、実施例1206から1209のいずれかの主題を含む。実施例1210では、現在のブロックチェーンを子ブロックチェーンに設定する段階は、コヒーレントキャッシュ内の下位レベルのブロックチェーンのコピーへのポインタに対する値を設定する段階を含む。
実施例1211は、実施例1206から1210のいずれかの主題を含む。実施例1211では、現在のブロックチェーン内のブロックを見つける段階は、ブロックハッシュ値が現在のブロックチェーンについてのマークルツリー内の値と一致すると判定する段階と、マークルツリーからブロックへのポインタを取得する段階と、を含む。
実施例1212は、実施例1206から1211のいずれかの主題を含む。実施例1212では、本方法は、階層型ブロックチェーンを構築する段階であって、ローカルIoTネットワークのためのトランザクションデータを現在のブロックチェーンに書き込む段階と、ブロックが同期ブロックであるか否かを判定する段階と、そうである場合、同期ブロックのハッシュを含む送信を構築する段階と、次に上位のレベルのIoTネットワークへの同期ブロックのハッシュを送信する段階と、次に上位のレベルのネットワーク内の現在のブロックに送信をコミットする段階と、を含む、段階を含む。
実施例1213は、実施例1206から1212のいずれかの主題を含む。実施例1213では、本方法は、階層型ブロックチェーンのコヒーレントキャッシュを構築する段階であって、現在のブロックチェーンを子ブロックチェーン内のパブリッシングキャッシュエージェントにサブスクライブする段階と、子ブロックチェーン内の現在ブロックチェーンの登録を受け入れる段階と、パブリケーションイベントを待つ段階と、を含む、段階を含む。
実施例1214は、実施例1206から1213のいずれかの主題を含む。実施例1214では、本方法は、階層型ブロックチェーンのコヒーレントキャッシュを維持する段階であって、子ブロックチェーン内のキャッシュコヒーレンシイベントの通知を受信する段階と、子ブロックチェーンからマークルツリーパスをコピーし、これをサブスクライバブロックチェーンでキャッシュエージェントにパブリッシュする、段階と、子ブロックチェーンに対応する現在キャッシュされているマークルツリーパスを置き換える段階と、を含む、段階を含む。
実施例1215は、実施例1206から1214のいずれかの主題を含む。実施例1215では、本方法は、パスがマークルツリーパスの新しい分岐を形成するか否かを判定する段階と、そうである場合、現在のブロックチェーン内に新しいローカルルートを構築する段階と、現在のブロックチェーンをローカルルートに等しくする段階と、ローカルルートがグローバルルートと同じになるまで、新しいローカルルートの構築を繰り返す段階と、を含む。
実施例1216は、実行されると、階層型ブロックチェーンを構築し、階層型ブロックチェーンの階層型インデックスを構築するようにプロセッサに指示する命令を含む、非一時的機械可読媒体を含む。
実施例1217は、実施例1216の主題を含む。実施例1217では、非一時的機械可読媒体は、実行されると、階層インデックス内の下位レベルのブロックチェーンへの参照を挿入するようにプロセッサに指示する命令を含む。
実施例1218は、実施例1216または1217のいずれかの主題を含む。実施例1218では、非一時的機械可読媒体は、実行されると、モノのインターネット(IoT)ネットワーク内の下位レベルでマークル木のコヒーレントキャッシュを構築するようにプロセッサに指示する命令を含む。
実施例1219は、実施例1216から1218のいずれかの主題を含む。実施例1219では、非一時的機械可読媒体は、実行されると、モノのインターネット(IoT)内の下位レベルからIoTネットワーク内の現在のレベルにマークル木をコピーするようにプロセッサに指示する命令を含む。
実施例1220は、実施例1216から1219のいずれかの主題を含む。実施例1220では、非一時的機械可読媒体は、実行されると、IoTネットワーク内の下位レベルからのマークル木のキャッシュのコヒーレンシを維持するようにプロセッサに指示する命令を含む。
実施例1221は、装置を含む。装置は、モノのインターネット(IoT)ネットワークを含み、IoTネットワークは、IoTデバイスを含む。IoTデバイスは、トピックのハッシュコードを含むブルームフィルタトピックリストと、ブルームフィルタトピックリストを利用可能なコンテンツのリストと比較するためのサブスクリプションマネージャと、ハッシュコードに関連するコンテンツを提供するためのコンテンツロケータと、を含む。
実施例1222は、実施例1221の主題を含む。実施例1222では、IoTデバイスは、許可されたコンテンツのハッシュコードを含むホワイトリストマスクを含む。
実施例1223は、実施例1221または1222のいずれかの主題を含む。実施例1223では、IoTデバイスは、禁止されたコンテンツのハッシュコードを含むブラックリストマスクを含む。
実施例1224は、実施例1221から1223のいずれかの主題を含む。実施例1224では、IoTデバイスは、トピックのハッシュコードを取得するためのハッシュコード計算部を含むことを含む。
実施例1225は、実施例1221から1224のいずれかの主題を含む。実施例1225では、IoTデバイスは、トラステッド実行環境を確立するためにトラステッドプラットフォームモジュールを含む。
実施例1226は、実施例1221から1225のいずれかの主題を含む。実施例1226では、IoTデバイスは、別のデバイスからコンテンツを提供されるサブスクライバを含む。
実施例1227は、実施例1221から1226のいずれかの主題を含む。実施例1227では、IoTデバイスは、別のデバイスにコンテンツを提供するパブリッシャを含む。
実施例1228は、実施例1221から1227のいずれかの主題を含む。実施例1228では、IoTデバイスは、コンテンツを複数のデバイスに提供するルータを含む。
実施例1229は、実施例1221から1228のいずれかの主題を含む。実施例1229では、複数のデバイスは、サブスクライバ、パブリッシャ、またはルータ、あるいはそれらの任意の組み合わせを含む。
実施例1230は、ブルームフィルタを使用してパブリッシュ-サブスクライブ型コンテンツ配信モデルを実施するための方法を含む。ブルームフィルタを使用してパブリッシュ-サブスクライブ型コンテンツ配信モデルを実装するための方法は、トピックのハッシュコードを含むサブスクライバブルームフィルタの登録を受信する段階と、トピックの複数のハッシュコードを含むパブリッシャブルームフィルタを用いてサブスクライバブルームフィルタのコンテンツ切片を計算する段階と、コンテンツ切片が、サブスクライバブルームフィルタ内の設定ビットとパブリッシャブルームフィルタ内の設定ビットとの間のビット一致を示す場合、ハッシュコードのためにサブスクライバにコンテンツを提供する段階と、を含む。
実施例1231は、実施例1230の主題を含む。実施例1231では、本方法は、許可されたトピックの複数のハッシュコードを含むホワイトリストマスクを用いてサブスクライバブルームフィルタのホワイトリスト切片を計算する段階を含む。
実施例1232は、実施例1230または1231のいずれかの主題を含む。実施例1232では、本方法は、サブスクライバブルームフィルタとホワイトリストマスクとの間でAND機能を実行することによりホワイトリスト切片を計算する段階を含む。
実施例1233は、実施例1230から1232のいずれかの主題を含む。実施例1233では、本方法は、禁止されたトピックの複数のハッシュコードを含むブラックリストマスクを用いてサブスクライバブルームフィルタのブラックリスト切片を計算する段階を含む。
実施例1234は、実施例1230から1233のいずれかの主題を含む。実施例1234では、本方法は、サブスクライバブルームフィルタとブラックリストマスクとの間のNAND関数として中間ブルームフィルタを計算し、中間ブルームフィルタとサブスクライバブルームフィルタとの間のAND関数としてブラックリスト切片を計算することによって、ブラックリスト切片を計算する段階を含む。
実施例1235は、実施例1230から1234のいずれかの主題を含む。実施例1235では、本方法は、ホワイトリスト切片が、サブスクライバブルームフィルタ内の設定ビットとホワイトリストマスク内の設定ビットとの間のビット一致を示し、ブラックリスト切片が、サブスクライバブルームフィルタ内の設定ビットとブラックリストマスクの設定ビットとの間のビット一致がないことを示す場合に、コンテンツをサブスクライバに提供する段階を含む。
実施例1236は、実施例1230から1235のいずれかの主題を含む。実施例1236では、本方法は、複数のトピックのそれぞれのハッシュコードを計算し、複数のトピックのそれぞれのハッシュコードをブルームフィルタに上書きすることによって、ブルームフィルタトピックリストを生成する段階を含む。
実施例1237は、実行されると、サブスクリプションブルームフィルタを登録し、サブスクリプションブルームフィルタとコンテンツフィルタとの共通部分を計算し、共通部分がゼロでない場合に、サブスクリプションブルームフィルタに関連付けられているコンテンツを提供するようにプロセッサに指示する命令を含む、非一時的機械可読媒体を含む。
実施例1238は、実施例1237の主題を含む。実施例1238では、非一時的機械可読媒体は、実行されると、許可されたコンテンツを示すホワイトリストマスクを登録し、禁止されたコンテンツを示すブラックリストマスクを登録するようにプロセッサに指示する命令を含む。
実施例1239は、実施例1237または1238のいずれかの主題を含む。実施例1239では、非一時的機械可読媒体は、実行されると、サブスクリプションブルームフィルタのハッシュコードがホワイトリストマスクとのゼロ以外の切片を有することを判定し、もしそうであればコンテンツを提供するようにプロセッサに指示する命令を含む。
実施例1240は、実施例1237から1239のいずれかの主題を含む。実施例1240では、非一時的機械可読媒体は、実行されると、サブスクリプションブルームフィルタのハッシュコードがブラックリストマスクとのゼロ以外の切片を有することを判定し、もしそうであればコンテンツが提供されるのを防ぐようにプロセッサに指示する命令を含む。
実施例1241は、実施例1237から1240のいずれかの主題を含む。実施例1241では、非一時的機械可読媒体は、実行されると、トピックのハッシュコードを判定し、そのハッシュコードをサブスクリプションブルームフィルタに書き込むようにプロセッサに指示する命令を含む。
実施例1242は、実施例1237から1241のいずれかの主題を含む。実施例1242では、非一時的機械可読媒体は、実行されると、トピックのハッシュコードを判定し、ハッシュコードとサブスクリプションブルームフィルタとのXORを実行して新しいブルームフィルタを生成し、サブスクリプションブルームフィルタを新しいブルームフィルタで置き換えるようにプロセッサに指示する命令を含む。
実施例1243は、装置を含む。装置は、モノのインターネット(IoT)ネットワークを含み、IoTネットワークは、IoTデバイスを含む。IoTデバイスは、トピックが暗号化コンテンツを含むことを判定するためのトピック分類部と、トピックが暗号化コンテンツを含むという通知を他のデバイスに送信するための通知部と、暗号化コンテンツのトピック鍵を含むトピックにサブスクライブするための鍵サブスクライバと、を含む。
実施例1244は、実施例1243の主題を含む。実施例1244では、IoTネットワークは、暗号化されたコンテンツを含むトピックを提供するためのパブリッシャを含む。
実施例1245は、実施例1243または1244のいずれかの主題を含む。実施例1245では、IoTネットワークは、トピックに関する暗号化されたコンテンツを取得するためにパブリッシャと通信しているルータを含む。
実施例1246は、実施例1243から1245のいずれかの主題を含む。実施例1246では、ルータは、暗号化されたコンテンツについてのパブリッシャからトピック鍵を取得する。
実施例1247は、実施例1243から1246のいずれかの主題を含む。実施例1247では、IoTネットワークは、ルータのチェーンを介してパブリッシャに通信しているルータを含む。
実施例1248は、実施例1243から1247のいずれかの主題を含む。実施例1248では、ルータの鍵サブスクライバは、ルータのチェーンの中のピアノードからトピック鍵を取得する。
実施例1249は、実施例1243から1248のいずれかの主題を含む。実施例1249では、ルータはトピック鍵のためのキャッシュを含み、鍵サブスクライバはキャッシュをウォームアップするためにルータのチェーンの中のピアノードからトピック鍵をプリエンプティブに取得する。
実施例1250は、実施例1243から1249のいずれかの主題を含む。実施例1250では、IoTネットワークは、ルータと通信しているサブスクライバを含み、サブスクライバは暗号化されたコンテンツのコンシューマを含む。
実施例1251は、実施例1243から1250のいずれかの主題を含む。実施例1251では、サブスクライバの鍵サブスクライバはルータからトピック鍵を取得する。
実施例1252は、実施例1243から1251のいずれかの主題を含む。実施例1252では、サブスクライバは、トピック鍵を使用して暗号化されたコンテンツを復号するための復号部を含む。
実施例1253は、パブリケーション-サブスクリプション型コンテンツ配信環境において暗号化鍵を管理するための方法を含む。パブリケーションーサブスクリプション型コンテンツ配信環境において暗号化鍵を管理するための方法は、暗号化されたコンテンツを含むトピックが利用可能であるというトピック通知を受信する段階と、トピック鍵について鍵管理トピックをサブスクライブする段階と、トピック鍵が利用可能であるという通知を受信する段階と、プリエンプティブにキャッシュをウォームアップためにトピック鍵を要求する段階と、を含む。
実施例1254は、実施例1253の主題を含む。実施例1254では、本方法は、トピック鍵についてのサブスクライバからの要求を受信する段階と、キャッシュからトピック鍵を提供する段階と、を含む。
実施例1255は、実施例1253または1254のいずれかの主題を含む。実施例1255では、本方法は、トピック鍵の利用可能性に関してデバイスに通知するために鍵管理トピックを構築する段階を含む。
実施例1256は、実施例1253から1255のいずれかの主題を含む。実施例1256では、本方法は、トピック鍵がキャッシュ内にあるか否かを判定する段階と、そうでなければ、ピアノードからトピック鍵を要求する段階と、を含む。
実施例1257は、実施例1253から1256のいずれかの主題を含む。実施例1257では、本方法は、利用可能なパブリッシュトピックのハッシュコードを含むブルームフィルタを構築する段階を含む。
実施例1258は、実施例1253から1257のいずれかの主題を含む。実施例1258では、トピック鍵を要求する段階は、トピック鍵を取得するためにGETコマンドを発行する段階を含む。
実施例1259は、実施例1253から1258のいずれかの主題を含む。実施例1259では、本方法は、経路指定ノードとサブスクライバノードとの間の転送中に傍受からトピック鍵を保護するためにサイト固有鍵を使用してトピック鍵を暗号化する段階を含む。
実施例1260は、実施例1253から1259のいずれかの主題を含む。実施例1260では、本方法は、パブリックリポジトリから暗号化されたコンテンツをダウンロードする段階を含む。
実施例1261は、実施例1253から1260のいずれかの主題を含む。実施例1261では、本方法は、トピック鍵を使用して暗号化されたコンテンツを復号する段階を含む。
実施例1262は、実行されると、暗号化コンテンツのトピック通知を受信し、トピック通知を受信すると鍵管理トピックをサブスクライブし、トピック鍵が利用可能であるという鍵通知を受信すると、ピアノードからトピック鍵を取得するようにプロセッサに指示する命令を含む、非一時的機械可読媒体を含む。
実施例1263は、実施例1262の主題を含む。実施例1263では、非一時的機械可読媒体は、実行されると、利用可能なコンテンツのハッシュコードを含むブルームフィルタを構築するようにプロセッサに指示する命令を含む。
実施例1264は、実施例1262または1263のいずれかの主題を含む。実施例1264では、非一時的機械可読媒体は、実行されると、トピック通知をピアルータに送信するようにプロセッサに指示する命令を含む。
実施例1265は、実施例1262から1264のいずれかの主題を含む。実施例1265では、非一時的機械可読媒体は、実行されると、暗号化されたコンテンツを含むトピックをサブスクライバに通知するようにプロセッサに指示する命令を含む。
実施例1266は、実施例1262から1265のいずれかの主題を含む。実施例1266では、非一時的機械可読媒体は、実行されると、サブスクライバからトピック鍵の要求を受信したときにトピック鍵をサブスクライバに送信するようにプロセッサに指示する命令を含む。
実施例1267は、装置を含む。装置は、モノのインターネット(IoT)ネットワークを含み、IoTネットワークは、IoTデバイスを含む。これはまた、IoTデバイスのグループメンバシップクレデンシャルを鍵配布センターに提供するアテステーション部と、関心のあるトピックのハッシュコードを含むブルームフィルタを提供し、関心のあるコンテンツを復号するために、鍵配布センターから鍵を受信するサブスクライバと、を含む。
実施例1268は、実施例1267の主題を含む。実施例1268では、関心のあるトピックは、パブリックトピック、プライベートトピック、鍵管理トピック、またはセキュリティレベルトピック、あるいはそれらの任意の組み合わせを含む。
実施例1269は、実施例1267または1268のいずれかの主題を含む。実施例1269では、本装置は、トピックにデバイスを登録し、IoTデバイスにグループメンバシップクレデンシャルを発行するためのトピックネーミングサーバを含む。
実施例1270は、実施例1267から1269のいずれかの主題を含む。実施例1270では、本装置は、IoTデバイスのアイデンティティを検証し、IoTデバイスにトピックグループ鍵を提供するための鍵配布センターを含む。
実施例1271は、実施例1267から1270のいずれかの主題を含む。実施例1271では、本装置は、下位レベルへの読み取り動作、上位レベルへの書き込み動作、またはその両方をブロックするための完全性施行部を含む。
実施例1272は、実施例1267から1271のいずれかの主題を含む。実施例1272では、レベルは、セキュリティレベル、ネットワークレベル、またはその両方であり得る。
実施例1273は、実施例1267から1272のいずれかの主題を含む。実施例1273において、本装置は、上位レベルへの読み取り動作、下位レベルへの書き込み動作、またはその両方をブロックするための機密性施行部を含む。
実施例1274は、実施例1267から1273のいずれかの主題を含む。実施例1274では、レベルは、セキュリティレベル、ネットワークレベル、またはその両方であり得る。
実施例1275は、パブリケーション-サブスクリプション型環境においてトピック暗号化を管理するための方法を含む。パブリケーション-サブスクライブ型環境においてトピック暗号化を管理するための方法は、ルータで暗号化トピックをサブスクライブする段階と、暗号化コンテンツを含む暗号化トピックの通知を受信する段階と、サブスクライバアテステーションメッセージを鍵配布センター(KDC)に送信する段階と、KDCからのトピック暗号化鍵を受信する段階と、トピック暗号化鍵を使用して暗号化コンテンツを復号する段階と、を含む。
実施例1276は、実施例1275の主題を含む。実施例1276では、本方法は、さらなる暗号化コンテンツを含む暗号化トピックに関する通知を受信する段階と、トピック暗号化鍵を用いてさらなる暗号化コンテンツを復号する段階と、を含む。
実施例1277は、実施例1275または1276のいずれかの主題を含む。実施例1277では、本方法は、トピック暗号化鍵を生成する段階と、パブリッシャアテステーションメッセージにおいてトピック暗号化鍵をKDCにプッシュする段階と、暗号化コンテンツをルータにパブリッシュする段階と、を含む。
実施例1278は、実施例1275から1277のいずれかの主題を含む。実施例1278では、本方法は、サブスクライバから暗号化トピックのサブスクリプションを受信する段階と、パブリッシャから暗号化トピックのパブリケーションを受信する段階と、暗号化コンテンツを含むパブリケーションの通知をサブスクライバに提供する段階と、を含む。
実施例1279は、実施例1275から1278のいずれかの主題を含む。実施例1279では、本方法は、下位レベルへの読み出し、上位レベルへの書き込み、またはその両方を防ぐことによって完全性ポリシーを施行する段階を含む。
実施例1280は、実施例1275から1279のいずれかの主題を含む。実施例1280では、レベルは、セキュリティレベル、ネットワークレベル、またはその両方である。
実施例1281は、実施例1275から1280のいずれかの主題を含む。実施例1281では、本方法は、上位レベルまでの読み取り、下位レベルへの書き込み、またはその両方を防止することによって機密性ポリシーを施行する段階を含む。
実施例1282は、実施例1275から1281のいずれかの主題を含む。実施例1282では、レベルは、セキュリティレベル、ネットワークレベル、またはその両方である。
実施例1283は、実行されると、トピック暗号化鍵を生成し、トピック暗号化鍵を鍵配布センター(KDC)にプッシュし、トピック暗号化鍵を使用して暗号化されたコンテンツをルータにパブリッシュするようにプロセッサに指示する命令を含む、非一時的機械可読媒体を含む。
実施例1284は、実施例1283の主題を含む。実施例1284では、非一時的機械可読媒体は、実行されると、暗号化されたコンテンツをサブスクライバに送信するようにプロセッサに指示する命令を含む。
実施例1285は、実施例1283または1284のいずれかの主題を含む。配布実施例1285では、非一時的機械可読媒体は、実行されると、鍵配布センターからトピック暗号化鍵を取得するようにプロセッサに指示する命令を含む。
実施例1286は、実施例1283から1285のいずれかの主題を含む。実施例1286では、非一時的機械可読媒体は、実行されると、トピック暗号化鍵を使用してコンテンツを復号するようにプロセッサに指示する命令を含む。
実施例1287は、実施例1283から1286のいずれかの主題を含む。実施例1287では、非一時的機械可読媒体は、実行されると、トピックネーミングサーバによって提供された証明書を使用してアイデンティティをアテステーションするようにプロセッサに指示する命令を含む。
実施例1288は、実施例1283から1287のいずれかの主題を含む。実施例1288では、非一時的機械可読媒体は、実行されると、完全性ポリシーを施行するようにプロセッサに指示する命令を含む。
実施例1289は、実施例1283から1288のいずれかの主題を含む。実施例1289では、非一時的機械可読媒体は、実行されると、機密性ポリシーを施行するようにプロセッサに指示する命令を含む。
実施例1290は、装置を含む。本装置は、モノのインターネット(IoT)ネットワークを含み、IoTネットワークはシャイロボットを含む。シャイロボットは、存在を検出するためのセンサと、シャイロボットを動かすための推進システムと、検出された存在に少なくとも部分的に基づいて推進システムを制御するためにセンサからのデータを使用するためのコンテキストエンジンと、他のデバイスにその存在を警告するためのネットワークシステムと、を含む。
実施例1291は、実施例1290の主題を含む。実施例1291では、センサは、画像データを得るためにカメラを含む。
実施例1292は、実施例1290または1291のいずれかの主題を含む。実施例1292では、センサは、生物の熱シグネチャを認識するための熱センサを含む。
実施例1293は、実施例1290から1292のいずれかの主題を含む。実施例1293では、センサは、音への位置、音源への距離、またはその両方を判定するためのマイクロホンアレイを含む。
実施例1294は、実施例1290から1293のいずれかの主題を含む。実施例1294では、センサは、対象物までの距離を判定するためのレーダセンサを含む。
実施例1295は、実施例1290から1294のいずれかの主題を含む。実施例1295では、存在は、動いている物体を含む。
実施例1296は、実施例1290から1295のいずれかの主題を含む。実施例1296では、シャイロボットは、全地球測位システムを使用して位置および/または向き、あるいはその両方を判定するための地理位置特定システムを含む。
実施例1297は、実施例1290から1296のいずれかの主題を含む。実施例1297では、シャイロボットは、物体を拾い上げるため、充電ユニットに接続するため、外部充電ポートを提供するため、またはそれらの任意の組み合わせでデバイスを制御するためのロボットシステムを含む。
実施例1298は、実施例1290から1297のいずれかの主題を含む。実施例1298では、シャイロボットは、バッテリを充電するためにシャイロボットを外部電源に自動的に結合するための充電システムを含む。
実施例1299は、実施例1290から1298のいずれかの主題を含む。実施例1299では、シャイロボットは、トラステッド実行環境(TEE)を含む。
実施例1300は、実施例1290から1299のいずれかの主題を含む。実施例1300では、シャイロボットは、ブート中にトラステッド実行環境(TEE)を確立するためのトラステッドプラットフォームモジュール(TPM)を含む。
実施例1301は、実施例1290から1300のいずれかの主題を含む。実施例1301では、シャイロボットは、外部デバイスに電力を供給するための電力出力システムを含む。
実施例1302は、実施例1290から1301のいずれかの主題を含む。実施例1302では、装置は、存在に関する情報を共有するために同様の地理的領域にあるロボットの群を含む。
実施例1303は、ロボット群内のシャイロボットを制御するための方法を含む。ロボット群内のシャイロボットを制御するための方法は、シャイロボットに近接した存在を検出する段階と、移動している場合にシャイロボットを停止するように推進システムに命令する段階と、存在について群の中の他のロボットに警告する段階と、を含む。
実施例1304は、実施例1303の主題を含む。実施例1304では、存在を検出する段階は、シャイロボットの近くにある物体の動きを検出する段階と、生物を含む物体を分類する段階と、を含む。
実施例1305は、実施例1303または1304のいずれかの主題を含む。実施例1305では、存在を検出する段階は、シャイロボットの近くにある物体の画像を取得する段階と、画像内の人間または動物を識別するために画像を処理する段階と、を含む。
実施例1306は、実施例1303から1305のいずれかの主題を含む。実施例1306では、存在を検出する段階は、別のデバイスによって検出された存在を含む警告メッセージを受信する段階を含む。
実施例1307は、実施例1303から1306のいずれかの主題を含む。実施例1307では、シャイロボットを停止するように推進システムに命令する段階は、シャイロボットを対向交通のパスの外側にある位置に移動させる段階と、推進システムを非作動にする段階と、を含む。
実施例1308は、実施例1303から1307のいずれかの主題を含む。実施例1308では、本方法は、バッテリリザーブが予め設定された制限未満であることを検出する段階と、シャイロボットを充電ステーションに移動させる段階と、シャイロボットを充電デバイスに自動的に結合する段階と、を含む。
実施例1309は、実施例1303から1308のいずれかの主題を含む。実施例1309では、本方法は、シャイロボットが新しい場所に移動することを判定する段階と、現在の位置を取得する段階と、新しい位置への経路をマッピングする段階と、およびシャイロボットを現在の位置から目標位置に移動させる段階と、を含む。
実施例1310は、実施例1303から1309のいずれかの主題を含む。実施例1310では、シャイロボットを動かすことは、ガイドラインに従うことを含む。
実施例1311は、実施例1303から1310のいずれかの主題を含む。実施例1311では、他のロボットに警告する段階は、シャイロボットの周りの領域を通って移動する物体を検出する段階と、および最も近くにあるロボットに警告を送信してその検出を知らせることを含む。
実施例1312は、実施例1303から1311のいずれかの主題を含む。実施例1312では、警報は、物体の位置、物体の移動、または物体の検出の確実性、あるいはそれらの任意の組み合わせを含む。
実施例1313は、実行されると、オブジェクトの存在を検出するようにプロセッサに指示し、そのオブジェクトがポリシー内のオブジェクトのリスト内にあることを判定し、群の中の他のロボットの存在の警報を通信する、命令を含む非一時的機械可読媒体を含む。
実施例1314は、実施例1313の主題を含む。実施例1314では、非一時的機械可読媒体は、実行されると、オブジェクトが生物であることを判定するようにプロセッサに指示し、シャイロボットを停止するように推進システムに命令する命令を含む。
実施例1315は、実施例1313または1314のいずれかの主題を含む。実施例1315では、非一時的機械可読媒体は、実行されると、シャイロボットを新しい位置に移動し、新しい位置で機能を実行するようにプロセッサに指示する命令を含む。
実施例1316は、実施例1313から1315のいずれかの主題を含む。実施例1316では、非一時的機械可読媒体は、実行されると、トラステッド実行環境(TEE)でシャイロボットをブートし、ポリシーをロードしコンテキストエンジンをブートさせることによってシャイロボットを初期化するようにプロセッサに指示する命令を含む。
実施例1317は、実施例1313から1316のいずれかの主題を含む。実施例1317では、非一時的機械可読媒体は、実行されると、シャイロボットに結合されたセンサを発見するようにプロセッサに指示し、そのセンサのドライバをロードする命令を含む。
実施例1318は、装置を含む。本装置は、モノのインターネット(IoT)ネットワークを含み、IoTネットワークは、プレファーストレスポンダデバイス(PFRD)の位置を判定するための地理位置情報システムと、イベントシーンにPFRDを移動させるための推進システムと、PFRDに機能を提供するシーン評価コントローラと、を含むPFRDを含む。
実施例1319は、実施例1318の主題を含む。実施例1319では、機能は、動きを制御すること、画像をキャプチャし転送すること、またはユーザデバイスにネットワーク通信を提供すること、あるいはそれらの任意の組み合わせを含む。
実施例1320は、実施例1318または1319のいずれかの主題を含む。実施例1320では、装置は、PFRDへの通信、PFRDと緊急応答部(ER)との間の通信、またはPFRDと基地局との間の通信、またはそれらの任意の組み合わせでの通信を提供するネットワーク通信システムを含む。
実施例1321は、実施例1318から1320のいずれかの主題を含む。実施例1321では、装置は、エントロピー多重化(EM)ツリーを格納するためのトラステッド実行環境(TEE)を含む。
実施例1322は、実施例1318から1321のいずれかの主題を含む。実施例1322では、EMツリーは、複数のPFRDが応答するようにコミッショニングされ得るウェイポイントにマッピングする。
実施例1323は、実施例1318から1322のいずれかの主題を含む。実施例1323では、EMツリーは、位置座標と各ウェイポイントのための到着予定時刻とを含む。
実施例1324は、実施例1318から1323のいずれかの主題を含む。実施例1324では、EMツリーは、ウェイポイントで識別鍵を生成するためのシード値を提供する。
実施例1325は、実施例1318から1324のいずれかの主題を含む。実施例1325において、装置は、目的地までの経路情報を提供するための旅行計画部を含む。
実施例1326は、実施例1318から1325のいずれかの主題を含む。実施例1326では、経路情報は、シーン、ウェイポイント、位置、目的地、または交差点、あるいはそれらの任意の組み合わせを含む。
実施例1327は、実施例1318から1326のいずれかの主題を含む。実施例1327では、経路情報は、代替経路を含む。
実施例1328は、実施例1318から1327のいずれかの主題を含む。実施例1328では、PFRDは、無人航空機を含む。
実施例1329は、実施例1318から1328のいずれかの主題を含む。実施例1329では、PFRDは、単一の管轄内の通信のための鍵を含む。
実施例1330は、実施例1318から1329のいずれかの主題を含む。実施例1330では、PFRDは、複数の独立した管轄内の通信のための複数の鍵を含む。
実施例1331は、実施例1318から1330のいずれかの主題を含む。実施例1331では、PFRDは、重複する管轄内の通信のための複数管轄鍵を含む。
実施例1332は、プレファーストレスポンダデバイス(PFRD)を管理するための方法を含む。プレファーストレスポンダデバイス(PFRD)を管理するための方法は、PFRDがイベントに参加するためのコマンドを受信する段階と、管轄権のための鍵を取得する段階と、管轄権に登録する段階と、イベントで緊急応答部に支援を提供する段階と、を含む。
実施例1333は、実施例1332の主題を含む。実施例1333では、本方法は、PFRDが単一の管轄区域内で動作しているか否かを判定する段階と、単一の管轄区域からの鍵について交渉する段階と、その鍵を使用してPFRDを単一の管轄区域に登録する段階と、登録が成功した場合は緊急応答部との通信を開始する段階と、を含む。
実施例1334は、実施例1332または1333のいずれかの主題を含む。実施例1334では、本方法は、PFRDが重複する管轄区域内で動作しているか否かを判定する段階と、重複する管轄区域から共有鍵を交渉する段階と、共有鍵を使用してPFRDを各重複管轄区域に登録する段階と、すべての重複する管轄区域での登録が成功した場合は緊急応答部との通信を開始する段階と、を含む。
実施例1335は、実施例1332から1334のいずれかの主題を含む。実施例1335では、本方法は、PFRDが複数の重複していない管轄区域内で動作しているか否かを判定する段階と、重複していない管轄区域それぞれからの個々の鍵を交渉する段階と、適切な個々の鍵を使用してPFRDを重複していない管轄区域のそれぞれと登録する段階と、すべての重複していない管轄区域での登録が成功した場合は緊急応答部との通信を開始する段階と、を含む。
実施例1336は、実施例1332から1335のいずれかの主題を含む。実施例1336では、本方法は、管轄区域への登録が成功しなかったと判定する段階と、管轄区域制御ネットワークに警告する段階と、を含む。
実施例1337は、実施例1332から1336のいずれかの主題を含む。実施例1337では、本方法は、トラステッド実行環境内のセキュアストアからポリシーを取得する段階と、初期飛行計画ポリシーをアクティブ化する段階と、を含む。
実施例1338は、実施例1332から1337のいずれかの主題を含む。実施例1338では、初期飛行計画ポリシーは、アンカーポイントからの離脱、ホバリング、画像のキャプチャ、または画像認識の実行、あるいはそれらの任意の組み合わせを含む、自律的な動作を含む。
実施例1339は、実施例1332から1338のいずれかの主題を含む。実施例1339では、本方法は、ネットワーク接続が劣悪であるか否かを判定する段階と、通信を改善するために接続性ポリシーを実装する段階と、を含む。
実施例1340は、実施例1332から1339のいずれかの主題を含む。実施例1340では、本方法は、トラステッド実行環境内のセキュアストアからリモート管理ポリシーを取得する段階と、緊急応答部によるリモート飛行管理を可能にする段階と、を含む。
実施例1341は、実行されると、イベントに応答し、PFRDの動作のためのポリシーを取得し、そしてイベントに応答するようにプレファーストレスポンダデバイス(PFRD)をトリガするようにプロセッサに指示する命令を含む非一時的機械可読媒体を含む。
実施例1342は、実施例1341の主題を含む。実施例1342では、非一時的機械可読媒体は、実行されると、PFRD内にリモート管理ポリシーを実施し、緊急応答部によるリモート操作管理を可能にするようにプロセッサに指示する命令を含む。
実施例1343は、実施例1341または1342のいずれかの主題を含む。実施例1343では、非一時的機械可読媒体は、実行されると、通信を改善するためのポリシーを実施するようにプロセッサに指示する命令を含む。
実施例1344は、実施例1341から1343のいずれかの主題を含む。実施例1344では、非一時的機械可読媒体は、実行されると、緊急応答部へのリモートネットワークアクセスを提供するようにプロセッサに指示する命令を含む。
実施例1345は、実施例1341から1344のいずれかの主題を含む。実施例1345では、非一時的機械可読媒体は、実行されると、旅行計画部からの旅行計画を受け入れるようにプロセッサに指示する命令を含む。
実施例1346は、任意の他の実施例と同様に方法を実行するための手段を備える装置を含む。
実施例1347は、実行されると、方法を実施する、または任意の他の実施例と同様に装置を実現するための機械可読命令を含む機械可読ストレージを含む。
一部の実施形態は、ハードウェア、ファームウェア、およびソフトウェアのうちの1つまたはそれらの組み合わせで実装され得る。一部の実施形態はまた、機械可読媒体に格納された命令として実装され、機械可読媒体は、本明細書で説明される動作を実行するためにコンピューティングプラットフォームによって読み出され実行され得る。機械可読媒体は、機械、例えばコンピュータによって可読である形で情報を格納または送信するための任意のメカニズムを含み得る。例えば、機械可読媒体は、読み取り専用メモリ(ROM)、ランダムアクセスメモリ(RAM)、磁気ディスク記憶媒体、光記憶媒体、フラッシュメモリデバイス、あるいは電気的、光学的、音響的、または他の形態の伝播信号、例えばとりわけ搬送波、赤外線信号、デジタル信号、または信号を送信および/もしくは受信するインターフェースを含むことができる。
一実施形態は、一実装または実施例である。本明細書において、「一実施形態(an embodiment)」、「1つの実施形態(one embodiment)」、「一部の実施形態(some embodiment)」、「様々な実施形態(various embodiment)」、または「他の実施形態(other embodiment)」と言及する場合、そのような実施形態に関して説明した特定の特徴、構造、または特性が本技術の少なくとも一部の実施形態に含まれるが、必ずしもすべての実施形態に含まれるわけではないことを意味している。「一実施形態(an embodiment)」、「1つの実施形態(one embodiment)」、または「一部の実施形態(some embodiment)」の様々な出現は、必ずしもすべてが同じ実施形態を指すとは限らない。ある実施形態の要素または態様は、別の実施形態の要素または態様と組み合わせることができる。
本明細書で説明され図示されるすべてのコンポーネント、特徴、構造、特性などは、特定の1つまたは複数の実施形態に含まれる必要はない。本明細書において、コンポーネント、特徴、構造、または特性が、含まれ「得る(may)」、「得る(might)」、「得る(can)」、または「得る(could)」と述べられている場合、例えば、その特定のコンポーネント、特徴、構造、または特性が含まれる必要はない。本明細書または特許請求の範囲において、「一(aまたはan)」要素に言及がある場合、それはその要素が1つしかないことを意味するのではない。本明細書または特許請求の範囲において「追加の(an additional)」要素に言及がある場合、それは複数の追加の要素があることを排除するものではない。
一部の実施形態が特定の実装形態に関して説明されているが、一部の実施形態に従って他の実装形態が可能であることに留意されたい。加えて、図面に示され、かつ/または本明細書で説明されている回路要素または他の特徴の配置および/または順序は、図示および説明された特定の方法で構成される必要はない。一部の実施形態によれば、他の多くの構成が可能である。
図示の各システムでは、場合によっては、表される要素が異なっていることおよび/または類似していることがあることを示唆するために、要素がそれぞれ同じ参照番号または異なる参照番号を持つことがある。しかしながら、要素は、異なる実装を有し、本明細書に図示または説明されたシステムの一部またはすべてと協働するのに十分に柔軟であり得る。図に示されている様々な要素は同じでも異なっていてもよい。どちらを第1の要素と呼び、どちらを第2の要素と呼ぶかは任意である。
技法は、本明細書に列挙された特定の詳細に限定されない。実際、本開示の恩恵を受ける当業者は、前述の説明および図面からの他の多くの変形が本技法の範囲内でなされ得ることを理解するはずである。従って、本技法の範囲を定義するのは、それに対するあらゆる補正を含む添付の特許請求の範囲である。