知財求人 - 知財ポータルサイト「IP Force」
特表2024-514823知識の適応化を用いた動的なエッジ－クラウドコラボレーション
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2024-04-03
(54)【発明の名称】知識の適応化を用いた動的なエッジ－クラウドコラボレーション
(51)【国際特許分類】
G06N 3/045 20230101AFI20240327BHJP
G06T 7/00 20170101ALI20240327BHJP
【ＦＩ】
G06N3/045
G06T7/00 350B
【審査請求】未請求
【予備審査請求】未請求
(21)【出願番号】P 2023561737
(86)(22)【出願日】2022-04-06
(85)【翻訳文提出日】2023-12-06
(86)【国際出願番号】 US2022023726
(87)【国際公開番号】W WO2022216867
(87)【国際公開日】2022-10-13
(31)【優先権主張番号】63/171,204
(32)【優先日】2021-04-06
(33)【優先権主張国・地域又は機関】US
(81)【指定国・地域】
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＦＩＲＥＷＩＲＥ
(71)【出願人】
【識別番号】522066573
【氏名又は名称】ワイズ ラブズ，インコーポレイテッド
(74)【代理人】
【識別番号】100094569
【弁理士】
【氏名又は名称】田中 伸一郎
(74)【代理人】
【識別番号】100103610
【弁理士】
【氏名又は名称】▲吉▼田 和彦
(74)【代理人】
【識別番号】100109070
【弁理士】
【氏名又は名称】須田 洋之
(74)【代理人】
【識別番号】100067013
【弁理士】
【氏名又は名称】大塚 文昭
(74)【代理人】
【氏名又は名称】上杉 浩
(74)【代理人】
【識別番号】100120525
【弁理士】
【氏名又は名称】近藤 直樹
(74)【代理人】
【識別番号】100139712
【弁理士】
【氏名又は名称】那須 威夫
(74)【代理人】
【識別番号】100141553
【弁理士】
【氏名又は名称】鈴木 信彦
(72)【発明者】
【氏名】カマニ モハンマドマフディ
(72)【発明者】
【氏名】チェン リン
(72)【発明者】
【氏名】チェン ツォンウェイ
(72)【発明者】
【氏名】リウ ティアンチアン
【テーマコード（参考）】
5L096
【Ｆターム（参考）】
5L096AA06
5L096BA02
5L096EA39
5L096GA51
5L096HA11
5L096KA04
5L096MA07
(57)【要約】
本明細書で紹介するのは、互いに競合する傾向がある前述の目的の間の様々なレベルのトレードオフを有するモデルを学習するエッジ－クラウドコラボレーションフレームワーク（「ＥＣＣフレームワーク」とも呼ばれる）の様々な変形例である。このＥＣＣフレームワークは、エッジデバイスによって使用される「エッジモデル」からコンピュータサーバシステムによって使用される「クラウドモデル」への知識の適応化に基づくものであるが、推論段階中の通信コストおよび計算コストを最小化することを試みつつ、可能な限り最高のパフォーマンスも実現しようと努めることができる。
【特許請求の範囲】
【請求項1】
監視対象の環境の第１の画像のシリーズを生成し、前記第１の画像のシリーズ内の各画像に第１のモデルを適用して、第１の出力のシリーズを生成し、
前記第１の出力のシリーズ内の各出力について、
前記出力の信頼性が閾値を超えているか否かを判定し、
前記信頼性が前記閾値を超えていないという判定に応答して、サーバシステムへの前記出力の送信を引き起こす
ように構成されるカメラと、
前記カメラから第２の画像のシリーズを受信し、
前記第２の画像のシリーズは前記第１の画像のシリーズのサブセットを表し、
前記第２の画像のシリーズ内の各画像に第２のモデルを適用して、第２の出力のシリーズを生成する
ように構成される前記サーバシステムと
を備える、監視システム。
【請求項2】
前記第１の出力のシリーズ内の各出力は、前記第１の画像のシリーズ内の対応する画像の内容に関して前記第１のモデルによって行われた推論を表し、前記第２の出力のシリーズ内の各出力は、前記第２の画像のシリーズ内の対応する画像の内容に関して前記第２のモデルによって行われた推論を表す、
請求項１に記載の監視システム。
【請求項3】
前記カメラは、前記第１の出力のシリーズ内の各出力について、
前記信頼性が前記閾値を超えているという判定に応答して、前記出力が適切な推論であることをデータ構造内に示す
ようにさらに構成される、請求項１に記載の監視システム。
【請求項4】
前記サーバシステムは、前記カメラへの前記第２の出力のシリーズの送信を引き起こす
ようにさらに構成され、
前記カメラは、
（ｉ）前記第１の出力のシリーズ内の信頼性の高い出力と、（ｉｉ）前記第２の出力のシリーズとの分析に基づいて、関心対象の活動またはオブジェクトが前記第１の画像のシリーズ内の少なくとも１つの画像に含まれていることを立証し、
関心対象の前記活動または前記オブジェクトを示す通知を、仲介デバイス上で実行されるコンピュータプログラムによって提示させる
ようにさらに構成される、請求項１に記載の監視システム。
【請求項5】
前記サーバシステムは、仲介デバイス上で実行されるコンピュータプログラムへの前記第２の出力のシリーズの送信を引き起こす
ようにさらに構成され、
前記カメラは、
前記仲介デバイス上で実行される前記コンピュータプログラムへの、前記第１の出力のシリーズ内の信頼性の高い出力の送信を引き起こす
ようにさらに構成される、請求項１に記載の監視システム。
【請求項6】
前記第１のモデルは、所与の画像に適用されたときに出力を生成するために、前記第２のモデルよりも少ない計算リソースを必要とする、請求項１に記載の監視システム。
【請求項7】
前記閾値は、前記カメラのメモリにプログラムされる、請求項１に記載の監視システム。
【請求項8】
監視対象の環境の画像のシリーズを生成し、前記画像のシリーズ内の各画像に第１のモデルを適用して、第１の出力のシリーズを生成し、
前記第１の出力のシリーズ内の各出力について、
前記出力の信頼性が閾値を超えているか否かを判定し、
前記信頼性が前記閾値を超えていないという判定に応答して、サーバシステムへの前記出力に対応する特徴マップの送信を引き起こす
ように構成されるカメラと、
前記カメラから特徴マップのシリーズを受信し、
前記特徴マップのシリーズは前記画像のシリーズのサブセットに対応し、
前記特徴マップのシリーズの各特徴マップについて、
前記特徴マップを第２のモデルに入力として提供して、第２の出力のシリーズを生成する
ように構成される前記サーバシステムと
を備える、監視システム。
【請求項9】
各特徴マップは、前記第２のモデルの中間層に入力として提供される、請求項８に記載の監視システム。
【請求項10】
前記第１および第２のモデルは分類モデルである、請求項８に記載の監視システム。
【請求項11】
前記第１および第２のモデルはオブジェクト検出モデルである、請求項８に記載の監視システム。
【請求項12】
環境を監視しながらサンプルを生成するエッジデバイスによって実行される方法であって、出力を生成するために前記サンプルにモデルを適用することであって、
各出力は、対応するサンプルに関して行われた推論を表す、
適用することと、
前記出力のうちのそれぞれの信頼性が閾値を超えているか否かを判定することと、
前記信頼性が前記閾値を超えていない各出力について、
（ｉ）前記対応するサンプル、または（ｉｉ）前記対応するサンプルに関する情報の、分析のためのサーバシステムへの送信を引き起こすことと
を含む、方法。
【請求項13】
前記エッジデバイスはカメラであり、前記モデルは画像内のオブジェクトのインスタンスを検出するようにトレーニングされる、請求項１２に記載の方法。
【請求項14】
前記情報は、前記対応するサンプルに関して導出された特徴マップを含む、請求項１２に記載の方法。
【請求項15】
前記適用すること、前記判定すること、および前記引き起こすことは、前記サンプルが前記エッジデバイスによって生成されたときにリアルタイムに実行される、請求項１２に記載の方法。
【請求項16】
サーバシステムによって実行される方法であって、環境を監視しながらサンプルを生成するエッジデバイスから特徴マップを受信することであって、
前記特徴マップは、第１のモデルによって、前記サンプルに適用されたときに生成される、
受信することと、
前記サンプルに関して行われた推論を表す出力を生成するために、前記特徴マップを第２のモデルの中間層に入力として提供することと、
前記推論の指示をデータ構造に記憶することと
を含む、方法。
【請求項17】
前記データ構造は、前記サーバシステムのメモリ内に保持される、請求項１６に記載の方法。
【請求項18】
前記サンプルは、前記環境のデジタル画像を表す、請求項１６に記載の方法。
【発明の詳細な説明】
【技術分野】
【0001】
関連出願の相互参照
本出願は、２０２１年４月６日に出願された「Ｄｙｎａｍｉｃ Ｅｄｇｅ－Ｃｌｏｕｄ Ｃｏｌｌａｂｏｒａｔｉｏｎ ｗｉｔｈ Ｋｎｏｗｌｅｄｇｅ Ａｄａｐｔａｔｉｏｎ」と題する米国仮出願第６３／１７１，２０４号に対する優先権を主張し、その全体が引用により本明細書に組み込まれている。
本出願は、２０２１年４月６日に出願された「Ｄｙｎａｍｉｃ Ｅｄｇｅ－Ｃｌｏｕｄ Ｃｏｌｌａｂｏｒａｔｉｏｎ ｗｉｔｈ Ｋｎｏｗｌｅｄｇｅ Ａｄａｐｔａｔｉｏｎ」と題する米国仮出願第６３／１７１，２０４号に対する優先権を主張し、その全体が引用により本明細書に組み込まれている。
【0002】
様々な実施形態は、監視システムと、それらの監視システムによって協働的な方法でソフトウェア実施モデルを学習するための関連技術とに関する。
【背景技術】
【0003】
「監視（ｓｕｒｖｅｉｌｌａｎｃｅ）」という用語は、所与の環境内で人または物品を保護する目的で、行動、活動、および他の変化する情報をモニタリングすることを指す。一般に、監視は、デジタルカメラ、照明、錠、動き検出器などの電子デバイスを使用して所与の環境がモニタリングされることを必要とする。総称的に、これらの電子デバイスは、「監視システム」または「セキュリティシステム」の「エッジデバイス」と呼ばれ得る。
【0004】
監視システムにおいてより一般的になりつつある１つの概念は、エッジインテリジェンスである。エッジインテリジェンスとは、監視システムに含まれるエッジデバイスが情報を処理し、その情報を他の場所に送信する前に意思決定を行う能力を指す。一例として、デジタルカメラ（または単に「カメラ」）は、デジタル画像（または単に「画像」）が宛先に送信される前に、それらの画像に含まれるオブジェクトを発見する役割を担い得る。宛先は、画像をさらに分析する役割を担うコンピュータサーバシステムであり得る。エッジインテリジェンスは一般に、監視システムに含まれるエッジデバイスによって生成された情報をコンピュータサーバシステムが処理するクラウドインテリジェンスの代替手段とみなされている。
【0005】
エッジデバイスによって生成される情報の規模が増大し続けるにつれて、タスクをローカルに、すなわち、エッジデバイス自体で実行することがますます一般的になってきている。たとえば、家庭環境をモニタリングするように設計された監視システムにいくつかのカメラが含まれていることを想定する。これらの各カメラは、サイズが数メガピクセル（ＭＰ）の高解像度画像を生成することが可能であり得る。これらの高解像度画像は家庭環境へのより深い洞察を提供するが、サイズが大きいので、帯域幅の制限により、これらの画像を分析のためにコンピュータサーバシステムにオフロードすることが困難になる。しかしながら、サイズが大きいことにより、これらの画像をローカルに処理することも困難になる。これらの理由から、リモート分析とローカル分析とを組み合わせることが望ましいが、リソース効率の高い方法でこれを実現するのは困難である。
【図面の簡単な説明】
【0006】
【図1】監視対象の環境の至る所に展開された様々なエッジデバイスを含む監視システムの高レベルの図を含む図である。
【図2】エッジベースの推論システムおよびクラウドベースの推論システムの高レベルの図を含む図である。
【図3A】出力の信頼性が閾値よりも高い場合、エッジデバイス上に実施されたエッジモデルが推論を実行し、出力の信頼性が閾値よりも低い場合、コンピュータサーバシステム上に実施されたクラウドモデルが推論を実行する独立型エッジ－クラウドコラボレーションフレームワーク（「ＥＣＣフレームワーク」とも呼ばれる）の高レベルの図を含む図である。
【図3B】エッジモデルによって出力として生成された推論の信頼性を使用して、クラウドモデルによるさらなる分析が必要か否かを判定することができる方法を示す高レベルのフローチャートを含む図である。
【図4A】エッジデバイス上に実施されたエッジモデルが、信頼性が閾値よりも高いサンプルに対して推論を実行する適応的ＥＣＣフレームワークの高レベルの図を含む図である。
【図4B】エッジモデルによって出力として生成された推論の信頼性を使用して、特徴マップをさらなる分析のためにコンピュータサーバシステムに提供すべきか否かを判定することができる方法を示す高レベルのフローチャートを含む図である。
【図5】本明細書に記載の少なくともいくつかのプロセスを実施することができる処理システムの一例を示すブロック図である。
【発明を実施するための形態】
【0007】
本明細書に記載の技術の様々な特徴は、図面と併せて詳細な説明を検討することにより、当業者にはより明らかになるであろう。実施形態は限定ではなく例として図面に示している。図面は例示の目的で様々な実施形態を示しているが、当業者であれば、本技術の原理から逸脱することなく代替の実施形態が使用され得ることを認識するであろう。したがって、特定の実施形態を図面に示しているが、本技術は様々な修正を受け入れることができる。
【0008】
本明細書で紹介するのは、エッジインテリジェンスおよびクラウドインテリジェンスの前述の欠点に対処するモデルを開発して展開するためのアプローチである。具体的には、本開示は、推論の役割を監視システムのエッジデバイスおよびコンピュータサーバシステムに分散させて、これらのシステムの通信負荷および計算負荷を軽減するためのアプローチに関する。
【0009】
エッジインテリジェンスの利用が大幅に増加したことにより、機械学習のアプリケーション、特にソフトウェア実施モデル（または単に「モデル」）の形態のものが、様々な領域でさらに普及した。監視システムおよびコンピュータサーバシステムの機能が向上してはいるが、監視システムのエッジデバイスの計算リソースは限られているので、ほとんどの場合、計算能力が「より豊かな」コンピュータサーバシステムに依存することは避けられない。コンピュータサーバシステム（「クラウドコンピューティングシステム」または「クラウド推論システム」とも呼ばれる）は、一般的により優れたパフォーマンスを実現することができるが、これらのコンピュータサーバシステムに依存するエッジデバイスの数に応じて、必要な通信リソースおよび計算リソースが激増する。したがって、監視システムおよび関連付けられたコンピュータサーバシステムの通信リソース、計算リソース、および全体的なパフォーマンスにはトレードオフが存在する。
【0010】
本明細書で紹介するのは、互いに競合する傾向がある前述の目的の間の様々なレベルのトレードオフを有するモデルを学習するエッジ－クラウドコラボレーションフレームワーク（「ＥＣＣフレームワーク」とも呼ばれる）である。このＥＣＣフレームワークは、エッジデバイスによって使用される「エッジモデル」からコンピュータサーバシステムによって使用される「クラウドモデル」への知識の適応化に基づくものであるが、推論段階中の通信コストおよび計算コストを最小化することを試みつつ、可能な最高のパフォーマンスも実現しようと努めることができる。さらに、このＥＣＣフレームワークは、エッジ－クラウド推論システムが通信コストおよび計算コストを削減するのに適した新しい圧縮技術と考えることができる。
【0011】
前述の課題を踏まえて、このＥＣＣフレームワークは、エッジおよびクラウドコンピューティングシステム間の協働的なアプローチにより、（ｉ）通信リソースおよび計算リソースの消費と、（ｉｉ）監視システムおよびコンピュータサーバシステムの全体的なパフォーマンスとの間のトレードオフの改善を実現するために導入することができる。一般に、「エッジコンピューティングシステム」および「エッジ推論システム」という用語は、監視システムを構成するエッジデバイスを指すために使用し、「クラウドコンピューティングシステム」および「クラウド推論システム」という用語は、コンピュータサーバシステム自体を指すために使用する。一方、「エッジ－クラウド推論システム」および「推論システム」という用語は、エッジコンピューティングシステムとコンピュータサーバシステムとの組み合わせを指すために使用し得る。具体的には、前述の課題に対処するために３つの別個のフレームワークを提案し、各フレームワークにおけるコラボレーションのレベルは、所望のトレードオフに応じて異なる。エッジコンピューティングシステムには、特にエッジインテリジェンスのコンテキストにおいて、これらのフレームワークの開発の動機付け要因となる２つの特徴がある。
【0012】
第１に、ほとんどのエッジコンピューティングシステムでは、たとえば、ビデオセグメントまたは画像の形式のサンプルを表すデータには、エッジコンピューティングシステムが検出しようとしている関心対象が必ずしも含まれていない場合がある。これらのサンプルは主に、分類における正常クラス、またはオブジェクト検出タスクにおける背景画像としてラベル付けされる。したがって、エッジモデルがこれらのサンプルを効果的に検出し、次いで、クラウドコンピューティングシステムにデータを送信する前に、これらのサンプルをフィルタリングすることができれば、クラウドコンピューティングシステムによって必要とされる通信リソースおよび計算リソースの量を大幅に削減することができる。
【0013】
第２に、全てのデータに関心対象が含まれている場合でも、エッジモデルは、検出タスクの一部を処理しつつ、残りの検出タスクをクラウドコンピューティングシステムに渡すことができる（たとえば、通信リソースおよび計算リソースの消費を削減するため）。たとえば、エッジ検出システムは、その役割の一部として、エッジモデルを使用して、入力として提供されたデータに含まれるサンプルの特徴マップを計算することを想定する。これらの特徴マップは、エッジコンピューティングシステムによって使用することができ、これらの特徴マップは、クラウドコンピューティングシステムによって使用されるクラウドモデルによって計算される特徴マップに適応させることができる。簡単に言えば、エッジモデルによって計算された特徴マップを使用して、クラウドモデルによって実行される推論の一部をバイパスすることによって、冗長な計算を回避することができる。
【0014】
これら２つの特徴は、本明細書で提案するフレームワークのうちの２つのための主な動機付け要因となる。第３のフレームワークは、推論のためにクラウドコンピューティングシステムに「いつ」および「何を」送信するかを動的に決定するために、２つのフレームワークの組み合わせに基づいている。要約すると、本明細書に記載のアプローチにはいくつかの核となる側面がある。
・第１に、推論システム全体で必要な通信リソースおよび計算リソースを削減するために、エッジ－クラウドコラボレーション方式で監視システム内のエッジデバイスに推論タスクを分散させる。
・第２に、推論システムに必要な計算リソースを削減するために、エッジコンピューティングシステムによって生成された特徴マップをクラウドコンピューティングシステム用に再利用することにより、知識の適応化を導入する。
・第３に、新規の圧縮技術として機能することができる（また、従来の圧縮技術のような静的な構造ではなく動的な構造を有する）動的エッジ－クラウドコラボレーションフレームワークを導入する。
・第１に、推論システム全体で必要な通信リソースおよび計算リソースを削減するために、エッジ－クラウドコラボレーション方式で監視システム内のエッジデバイスに推論タスクを分散させる。
・第２に、推論システムに必要な計算リソースを削減するために、エッジコンピューティングシステムによって生成された特徴マップをクラウドコンピューティングシステム用に再利用することにより、知識の適応化を導入する。
・第３に、新規の圧縮技術として機能することができる（また、従来の圧縮技術のような静的な構造ではなく動的な構造を有する）動的エッジ－クラウドコラボレーションフレームワークを導入する。
【0015】
本明細書で紹介するフレームワークは、所与のタイプのエッジデバイスによって使用されるモデルのコンテキストで説明し得るが、これらのフレームワークは一般に、カメラ、照明、錠、センサなどを含む様々なエッジデバイスにわたって適用可能であり得ることに留意されたい。たとえば、例示の目的で、カメラによって生成された画像に含まれるオブジェクトのインスタンスを認識するように設計されたモデルのコンテキストで一実施形態を説明し得る。そのようなモデルを「オブジェクト認識モデル」と呼び得る。しかしながら、当業者は、本技術が他のタイプのモデルおよび他のタイプのエッジデバイスにも同様に適用可能であり得ることを認識するであろう。
【0016】
さらに、例示の目的でコンピュータ実行可能命令のコンテキストで実施形態を説明し得る。本技術の態様は、ハードウェア、ファームウェア、またはソフトウェアを介して実施することができる。たとえば、エッジデバイスは、周囲環境を表すデータを生成し、次いでそのデータをモデルに入力として提供するように構成され得る。次いで、エッジデバイスは、モデルによって生成された出力に基づいて、適切な行動方針を決定することができる。出力の信頼性が十分に高い場合、モデルによって行われた推論は信頼され得る。しかしながら、出力の信頼性が低い場合（たとえば、閾値を下回る場合）、エッジデバイスは、データまたはデータを示す情報をさらなる分析のためにコンピュータサーバシステムに送信し得る。信頼性は、コンピュータサーバシステムによるさらなる分析が必要か否かを判定するために使用することができる１つの基準にすぎないことに留意されたい。このアプローチは、データをコンピュータサーバシステムに送信すべきか否かを示す他の基準（または基準のセット）にも同様に適用される。
【0017】
用語
本説明における「一実施形態」または「いくつかの実施形態」への言及は、記載した特徴、機能、構造、または特性が少なくとも１つの実施形態に含まれることを意味する。そのような語句の出現は、必ずしも同一の実施形態を指すわけではなく、必ずしも相互に排他的な代替の実施形態を指すわけでもない。
本説明における「一実施形態」または「いくつかの実施形態」への言及は、記載した特徴、機能、構造、または特性が少なくとも１つの実施形態に含まれることを意味する。そのような語句の出現は、必ずしも同一の実施形態を指すわけではなく、必ずしも相互に排他的な代替の実施形態を指すわけでもない。
【0018】
文脈上明らかに別段の必要がない限り、「備える（ｃｏｍｐｒｉｓｅ）」、「備える（ｃｏｍｐｒｉｓｉｎｇ）」、および「～で構成される（ｃｏｍｐｒｉｓｅｄ ｏｆ）」という用語は、排他的または網羅的な意味ではなく、包括的な意味で（すなわち、「～を含むがこれに限定されない」という意味で）解釈されるべきである。「～に基づいて」という用語も包括的な意味で解釈されるべきである。したがって、特に断りのない限り、「～に基づいて」という用語は、「～に少なくとも部分的に基づいて」を意味するものとする。
【0019】
「接続された」、「結合された」という用語、およびそれらの変形は、直接的または間接的な、オブジェクト間のあらゆる接続または結合を含むものとする。接続／結合は、物理的なもの、論理的なもの、またはそれらの組み合わせとすることができる。たとえば、オブジェクトは、物理的な接続を共有していないにもかかわらず、互いに電気的にまたは通信可能に結合され得る。
【0020】
「モジュール」という用語は、ソフトウェア、ファームウェア、またはハードウェアを広く指すために使用し得る。モジュールは、典型的には、１つまたは複数の入力に基づいて１つまたは複数の出力を生成する機能コンポーネントである。コンピュータプログラムには１つまたは複数のモジュールが含まれ得る。したがって、コンピュータプログラムには、異なるタスクを完了する役割を担う複数のモジュール、または全てのタスクを完了する役割を担う単一のモジュールが含まれ得る。
【0021】
複数の項目のリストに関して使用する場合、「または」という単語は、リスト内の項目のいずれか、リスト内の全ての項目、およびリスト内の項目の任意の組み合わせという解釈を全てカバーするものとする。
【0022】
本明細書に記載のプロセスのいずれかで実行されるステップの順序は例示的なものである。しかしながら、物理的な可能性に反しない限り、ステップは様々な順序および組み合わせで実行され得る。たとえば、本明細書に記載のプロセスに対してステップを追加したり削除したりすることができる。同様に、ステップを置き換えたり、並べ替えたりすることもできる。したがって、任意のプロセスの説明には制約がないことが意図されている。
【0023】
監視システムの概要
図１は、監視対象の環境１０４の至る所に展開された様々なエッジデバイス１０２ａ～ｎを含む監視システム１００の高レベルの図を含む。図１のエッジデバイス１０２ａ～ｎはカメラであるが、カメラに加えて、またはカメラの代わりに、他のタイプのエッジデバイスを環境１０４の至る所に展開することもできる。一方、環境１０４は、たとえば、家庭または会社であり得る。
図１は、監視対象の環境１０４の至る所に展開された様々なエッジデバイス１０２ａ～ｎを含む監視システム１００の高レベルの図を含む。図１のエッジデバイス１０２ａ～ｎはカメラであるが、カメラに加えて、またはカメラの代わりに、他のタイプのエッジデバイスを環境１０４の至る所に展開することもできる。一方、環境１０４は、たとえば、家庭または会社であり得る。
【0024】
いくつかの実施形態では、これらのエッジデバイス１０２ａ～ｎは、ネットワーク１１０ａを介して、１つまたは複数のコンピュータサーバ（または単に「サーバ」）で構成されるサーバシステム１０６と直接通信することが可能である。他の実施形態では、これらのエッジデバイス１０２ａ～ｎは、仲介デバイス１０８を介してサーバシステム１０６と間接的に通信することが可能である。仲介デバイス１０８は、エッジデバイス１０２ａ～ｎおよびサーバシステム１０６にそれぞれのネットワーク１１０ｂ～ｃを介して接続され得る。ネットワークａ～ｃは、パーソナルエリアネットワーク（ＰＡＮ）、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、メトロポリタンエリアネットワーク（ＭＡＮ）、セルラーネットワーク、またはインターネットであり得る。たとえば、エッジデバイス１０２ａ～ｎは、Ｂｌｕｅｔｏｏｔｈ（登録商標）、近距離無線通信（ＮＦＣ）、または他の短距離通信プロトコルによって仲介デバイスと通信し得、エッジデバイス１０２ａ～ｎは、インターネットを介してサーバシステム１０８と通信し得る。
【0025】
一般に、仲介デバイス１０８上で実行されるコンピュータプログラムは、サーバシステム１０６によってサポートされるので、サーバシステム１０６との通信を容易にすることが可能である。仲介デバイス１０８は、たとえば、携帯電話、タブレットコンピュータ、または基地局とすることができる。したがって、仲介デバイス１０８は常に環境１０４内に留まり得、または仲介デバイス１０８は定期的に環境１０４に入り得る。
【0026】
従来、図１に示すような監視システムは「集中型」方式で運用されていた。すなわち、エッジデバイス１０２ａ～ｎによって生成された情報は分析のためにサーバシステム１０６に送信され、サーバシステム１０６は情報の分析を通じて洞察を得る。このアプローチの１つの利点は、サーバシステム１０６が一般に計算集約的なモデルを使用するのによく適していることである。しかしながら、情報をサーバシステム１０６に送信するにはかなりの通信リソースが必要になり、サーバシステムによって適用されるモデルは、一般に「グローバルモデル」と呼ばれるものであるが、エッジデバイス１０２ａ～ｎに合わせて調整されていない場合がある。
【0027】
これらの問題に対処するための努力の一環として、エッジインテリジェンスがますます一般的になってきている。「エッジインテリジェンス」という用語は、エッジデバイス１０２ａ～ｎが、たとえば、情報を他の場所に送信する前に、その情報をローカルに処理する能力を指す。エッジインテリジェンスにより、監視システムは、より「分散された」方式で動作する。分散型監視システムでは、グローバルモデルがサーバシステム１０６によって作成され、次いで、エッジデバイス１０２ａ～ｎに展開され得る。各エッジデバイスは、自身のデータに基づいて、一般に「ローカルモデル」と呼ばれる、グローバルモデルの自身のバージョンを調整することが許可され得るが、このアプローチには上で説明したように欠点がある。特に、必要なモデルを実行するために十分な計算リソースがエッジデバイス１０２ａ～ｎ上で利用可能でない場合がある。加えて、各エッジデバイスが独自のローカルモデルを実施する（したがって「サイロ化」方式で動作する）場合、監視システム１００全体にわたる洞察をほとんど得ることができない。
【0028】
モデル学習のための協働的なアプローチの概要
エッジインテリジェンスは、多くの分野における機械学習およびコンピュータビジョンアプリケーションの進歩において重要な役割を果たす。様々な領域での注目すべき成果にもかかわらず、エッジコンピューティングシステムの計算上の制限は、一般に、それらのエッジコンピューティングシステムにおいてモデルを効率的かつ高速に利用する上で主な障害となっている。従来、この問題の解決策は、推論タスクをより効果的に実行するためにより多くの計算リソースにアクセスすることができるクラウドコンピューティングシステムに依存することであった。しかしながら、クラウドコンピューティングシステムに依存すると、関心対象のデータをクラウドコンピューティングシステムに提供する必要があるので、通信リソースおよび計算リソースの点でコストが高くなる。
エッジインテリジェンスは、多くの分野における機械学習およびコンピュータビジョンアプリケーションの進歩において重要な役割を果たす。様々な領域での注目すべき成果にもかかわらず、エッジコンピューティングシステムの計算上の制限は、一般に、それらのエッジコンピューティングシステムにおいてモデルを効率的かつ高速に利用する上で主な障害となっている。従来、この問題の解決策は、推論タスクをより効果的に実行するためにより多くの計算リソースにアクセスすることができるクラウドコンピューティングシステムに依存することであった。しかしながら、クラウドコンピューティングシステムに依存すると、関心対象のデータをクラウドコンピューティングシステムに提供する必要があるので、通信リソースおよび計算リソースの点でコストが高くなる。
【0029】
したがって、（ｉ）通信リソースおよび計算リソースの消費と、（ｉｉ）推論システムの全体的なパフォーマンスとの間には顕著なトレードオフがあり、エッジコンピューティングシステムおよびクラウドコンピューティングシステムはこのトレードオフの両極端に対応する。エッジモデルは、計算コストが低く、通信コストがかからず、場合によってはパフォーマンスが最も低く、クラウドモデルは、通信コストおよび計算コストが高くなるが、より優れたパフォーマンスを提供する。本明細書で紹介するアプローチは、「ＥＣＣフレームワーク」と呼ばれる新しいフレームワークを導入して、（ｉ）通信リソースおよび計算リソースの消費と、（ｉｉ）推論システムの全体的なパフォーマンスとの間のトレードオフがより管理可能ないくつかのモデルを突き止めることによって、エッジコンピューティングシステムとクラウドコンピューティングシステムとの間のギャップを埋めることを目的とする。
【0030】
効率的で高速なモデルをトレーニングするために、知識蒸留（ｋｎｏｗｌｅｄｇｅ ｄｉｓｔｉｌｌａｔｉｏｎ）または量子化などの多くの圧縮技術が提案されている。しかしながら、パフォーマンスを損なわずに計算量を削減する際の対応するアルゴリズムの能力には下限がある。このため、これらの圧縮技術は、低電力のエッジデバイスでの実行には適さない場合があり、それらのエッジデバイスによって使用されるモデルが過剰パラメータ（ｏｖｅｒ－ｐａｒａｍｅｔｅｒｉｚｅｄ）である場合は特にそうである。さらに、これらの圧縮技術では、トレーニング時のクラウドモデルの通信の非効率性が考慮されていない。ＥＣＣフレームワークでは、最適なエッジモデルで動作する動的な構造をエッジコンピューティングシステム上で、クラウドモデルと連携して実行することによって、そのエッジモデルのパフォーマンスを向上させると共に、推論システム全体に関する通信コストおよび計算コストを削減することができる。
【0031】
大まかに言えば、モデルは、知識蒸留の技術を使用するが、生徒モデルから教師モデルへ逆方向に使用して、エッジモデルによって得られた知識を対応するクラウドマーク（ｃｌｏｕｄ ｍａｒｋ）に適応させることに基づくことができる。教師から生徒への知識の蒸留に関する情報は、「Ｓｅｌｆ－Ｓｕｐｅｒｖｉｓｅｄ Ｃｏｌｌａｂｏｒａｔｉｖｅ Ａｐｐｒｏａｃｈ ｔｏ Ｍａｃｈｉｎｅ Ｌｅａｒｎｉｎｇ ｂｙ Ｍｏｄｅｌｓ Ｄｅｐｌｏｙｅｄ ｏｎ Ｅｄｇｅ Ｄｅｖｉｃｅｓ」と題する国際出願第ＰＣＴ／ＵＳ２２／１６１１７号で見つけることができ、その全体が引用により本明細書に組み込まれている。さらに、ＥＣＣフレームワークは、教師モデルから生徒モデルへの知識の蒸留をさらに改善するために、知識蒸留での適応化にディープモデルを使用し得る。
【0032】
ＥＣＣフレームワークの動的な構造は、エッジコンピューティングシステムが、データを分析のためにクラウドコンピューティングシステムに「いつ」送信すべきかだけでなく、「どのような」データを送信すべきかを決定することも可能にする。入力として提供されたデータを圧縮するための固定のモデル構造に主に焦点を当てた古典的な圧縮技術にもかかわらず、ＥＣＣフレームワークの実行を通じて使用されるモデルは、入力として提供されたデータに基づいて適応させることができる動的な構造を提供することができる。動的な構造により、クラウドモデルのパフォーマンスの維持を試みながら、エッジ－クラウド推論システムの通信コストおよび計算コストが効率的に削減される。したがって、ＥＣＣフレームワークは、効率的な推論システムのために計算コストとパフォーマンスとの間のトレードオフに加えて、通信コストも最適化するという点で、新しい圧縮技術と考えることができる。
【0033】
Ａ．圧縮および知識蒸留の導入
モデルが推論を実行するために必要なメモリフットプリントおよび計算リソースを最小限に抑えるために、圧縮技術が多くの領域で広く使用されている。
モデルが推論を実行するために必要なメモリフットプリントおよび計算リソースを最小限に抑えるために、圧縮技術が多くの領域で広く使用されている。
【0034】
様々なアプリケーションで使用される主な圧縮技術の１つは量子化であり、その目標は、計算の高速化とメモリ使用量の削減との恩恵を受けるために、モデルの重みをより低いビット精度に量子化することである。学習された重みが量子化されるため、このプロセスはモデルのパフォーマンスに悪影響を及ぼすので、当面のタスクには最適ではない場合がある。したがって、様々なアプローチを使用して、トレーニング後のメカニズムを実施することによって、量子化の劣化の影響を軽減する（たとえば、最小限に抑える）ことが試みられてきた。トレーニング後のメカニズムの例には、量子化されたモデル自体のファインチューニング、および量子化を意識したトレーニングの実行などが含まれる。圧縮技術の他の形態は、モデルが一般に過剰パラメータであるため、パラメータ空間が非常にスパースであるという考えに基づいている。そのため、スパースな重みを枝刈り（ｐｒｕｎｉｎｇ）することで、モデルの規模を縮小することができ、その結果、推論に必要な計算リソースの量が減少する。もう１つの主な圧縮技術は知識蒸留であり、これについては以下でより詳しく説明する。これらの様々な圧縮技術ではモデルをある程度圧縮することができるが、圧縮率には下限がある。別の言い方をすると、これらの圧縮技術は、大規模なモデルから始めて、パフォーマンスが大きな影響を受ける前に、大規模なモデルを限られた程度しか圧縮することができない。
【0035】
知識蒸留では、大規模なモデルから始めて大規模なモデルを圧縮するのではなく、代わりに、大規模なモデル（「教師モデル」とも呼ばれる）から小規模なモデル（「生徒モデル」とも呼ばれる）に知識が蒸留される。この技術により、生徒モデルのパフォーマンスを向上させることができることが示されている。理論的には、生徒モデルは非常に小規模であり得るが、生徒モデルの規模が小さくなるにつれて、生徒モデルおよび教師モデルのパフォーマンスのギャップが大きくなる。知識蒸留によって生徒モデルのパフォーマンスを向上させることはできるが、このギャップを埋めることはできない。実際には、知識蒸留は、低電力のエッジデバイスに適した小規模なモデルに相応の影響を与える可能性が低い。それにもかかわらず、知識蒸留から得られる概念は、エッジモデルおよびクラウドモデル間のコラボレーションに依存することでこのギャップを埋める際のインスピレーションを与える動機となり得る。知識蒸留は当初、教師モデルの分類出力から生徒モデルの対応するものに知識を転送することによって、分類モデルに導入された。「ＦｉｔＮｅｔｓ」と呼ばれる他のアプローチは当初、知識蒸留の新しい形態として導入されており、マッチングモジュールを使用してニューラルネットワークの任意の２つの層の間で蒸留を行うことができる。ＦｉｔＮｅｔｓの導入以来、様々な形態の知識蒸留が提案されてきた。
【0036】
関連する他の研究ラインは、ドメイン適応化技術のコンテキストにおける特徴適応化に関連している。ドメイン適応化技術は、ＦｉｔＮｅｔｓと同様のアプローチを使用して、特徴層をターゲットドメインからソースドメインに適応させることによって、ソースドメインでのモデルのパフォーマンスを向上させてきた。適応化は主に同じモデル構造間で行われる。しかしながら、エッジモデルにおけるドメイン適応化に関する最近の研究がいくつかある。いずれにせよ、これらのフレームワークの全てにおいて、目標はターゲットドメイン用のスタンドアロンモデルを学習することであるので、特徴適応化部分は推論中に使用されない。これは本明細書で紹介するアプローチとは異なり、本明細書で紹介するアプローチでは、ドメインは同じであるが、目標は特徴適応化を用いてエッジおよびクラウドコンピューティングシステムを使用するモデルを学習することである。
【0037】
Ｂ．エッジおよびクラウドコンピューティングシステムにわたる知識の適応化
エッジデバイスは、生成したデータをモデルに提供して、タスクに関連する出力（「予測」または「推論」とも呼ばれる）を生成することができる。タスクはエッジデバイス自体の性質に依存する。たとえば、エッジデバイスがカメラである場合、タスクはカメラによって生成された画像内のオブジェクトを検出することであり得る。これを行うために、カメラは、それらのオブジェクトを検出し、次いでバウンディングボックスを使用して検出した各オブジェクトの位置を特定するようにトレーニングされたエッジモデルを使用し得る。あるいは、カメラは画像をコンピュータサーバシステムに送信し得、コンピュータサーバシステムはエッジモデルとよく似た動作をするクラウドモデルを使用し得る。
エッジデバイスは、生成したデータをモデルに提供して、タスクに関連する出力（「予測」または「推論」とも呼ばれる）を生成することができる。タスクはエッジデバイス自体の性質に依存する。たとえば、エッジデバイスがカメラである場合、タスクはカメラによって生成された画像内のオブジェクトを検出することであり得る。これを行うために、カメラは、それらのオブジェクトを検出し、次いでバウンディングボックスを使用して検出した各オブジェクトの位置を特定するようにトレーニングされたエッジモデルを使用し得る。あるいは、カメラは画像をコンピュータサーバシステムに送信し得、コンピュータサーバシステムはエッジモデルとよく似た動作をするクラウドモデルを使用し得る。
【0038】
本明細書で紹介するのは、エッジおよびクラウドコンピューティングシステム間の協働的なアプローチにより、（ｉ）通信リソースおよび計算リソースの消費と、（ｉｉ）監視システムの全体的なパフォーマンスとの間の様々なトレードオフを有するモデルを学習するＥＣＣフレームワークである。これらのＥＣＣモデルの１つの目標は、エッジコンピューティングシステムのパフォーマンスを向上させながら、クラウドコンピューティングシステムの通信の複雑性および計算の複雑性を軽減することである。別の意味では、通信リソース、計算リソース、およびパフォーマンスの間のトレードオフの観点でＥＣＣモデルを比較して、様々なシナリオに適した折衷案を確立することが望ましい。このＥＣＣフレームワークにより、現在利用可能な通信リソースおよび計算リソース、ならびに目標のまたは所望のパフォーマンスに基づいて適切なアプローチを選択する際の柔軟性が向上する。ＥＣＣフレームワークのための３つの異なる構造を以下でより詳細に提案する。
【0039】
図２は、エッジベースの推論システム２００およびクラウドベースの推論システム２０２の高レベルの図を含む。エッジベースの推論システム２００を使用して推論を実行することは、画像がエッジデバイス２０６から離れる必要がないので通信リソースの点でコストが少なく、エッジモデル２０４が比較的「軽量」であるので計算リソースの点でコストが少ないが、提供するパフォーマンスは劣る。クラウドベースの推論システム２０２を使用して推論を実行することは、画像をエッジデバイス２０８からコンピュータサーバシステム２１０に送信する必要があるので通信リソースの点でよりコストがかかり、クラウドモデル２１２が比較的「重い」ので計算リソースの点でよりコストがかかるが、より優れたパフォーマンスを提供する。
【0040】
ディープニューラルネットワークにおける分散された推論の問題を調査するには、これらのモデルの一般的な構造および学習プロセスについて議論することが重要である。たとえば、Ｍ個の異なる層ｗ＝｛ｗ1，．．．，ｗM｝で構成されるディープニューラルネットワークモデルｗ∈Ｒdが存在すると仮定する。たとえば、このディープニューラルネットワークモデルは、畳み込み型、全結合型、残差型であるか、またはｗl，∀ｌ∈［Ｍ］のパラメータセットで表される他の任意の層アーキテクチャを有し得る。各層はｘl，ｌ∈［Ｍ］を入力として受け取り得、これは前の層によって実行された順方向処理の出力である。一例として、順方向処理の各インスタンスは、関数ｙl-1＝ｆl-1（ｘl-1；ｗl-1）（すなわち、ｘl＝ｙl-1）を利用し得る。
【0041】
一般に、分類またはオブジェクト検出などの教師あり学習タスクでは、ｎ個のサンプルを有するトレーニングデータセットＴに関して予測マッピングを最適化することが望ましい。マッピングは、特徴空間Ｘを、たとえばクラスラベルまたはオブジェクト注釈を表すラベル空間Ｙに変換し、各サンプルポイントは（ｘ(i)，ｙ(i)）∈Ｘ×Ｙで表される。マッピングは、様々な関数
【0042】
【数1】
【数2】
【数3】
【数4】
【0043】
エッジモデルまたはクラウドモデルのいずれかの目標は、それらのＮe個の層を有するモデル
およびＮc個の層を有するモデル
にそれぞれに基づいて、テストデータセットで最高の推論パフォーマンスを達成するように経験的リスクを最小化することである。エッジモデルおよびクラウドモデルの表現能力の間のギャップにより、テストデータセットでのパフォーマンスは大きく異なる。しかしながら、一般に推論システムにおける主なボトルネックとなっている、エッジデバイスで利用可能な計算リソースが限られていることにより、エッジモデルの複雑性を増大させても、このパフォーマンスのギャップを埋めることはできない。一方、クラウドベースの推論システムの通信要件および計算要件の方が高いので、クラウドモデルに依存するだけでは、純粋なエッジベースの推論システムと比較して「コスト」が大幅に高くなる。ＥＣＣフレームワークの１つの目標は、コンピュータサーバシステムによる実現可能な最小限の通信および計算でパフォーマンスが向上するようにエッジモデルとクラウドモデルを組み合わせることによって、この損失を軽減する（たとえば、最小化する）ことである。具体的には、ＥＣＣフレームワークはモデルを次のように組み合わせ得る。
【数5】
【数6】
【0044】
【数7】
【0045】
Ｃ．ＥＣＣモデルの概要
ＥＣＣフレームワークの背後にある主な概念の１つは、推論の一部をエッジコンピューティングシステムに分散させつつ、残りの推論はクラウドコンピューティングシステムによって実行されることである。場合によっては、エッジコンピューティングシステムは推論を効果的に実行することが可能であり得るが、他の場合には、エッジコンピューティングシステムは、必要に応じてクラウドコンピューティングシステムのリソースを利用し得る。したがって、日常的に答えるべき問題は、いつデータをクラウドコンピューティングシステムに送信し、そのリソースを使用してより適切な推論を得るべきかということである。推論の一部が既にエッジコンピューティングシステムによって実行されていることを考慮すると、いつ送信するかに加えて、さらなる推論のために何をクラウドコンピューティングシステムに送信すべきかを問う必要がある。以下でさらに説明するように、データ全体そのものを送信することなく、エッジコンピューティングシステムによって出力された結果の特徴マップをクラウドコンピューティングシステムによる推論に利用することができる。この戦略により、通信コストを削減することが可能なだけでなく、クラウドコンピューティングシステムによって発生する計算コストも削減する。また、推論対象のデータをクラウドコンピューティングシステムにそのまま送信する必要がないので、対応するエッジデバイス上でデータのプライバシーを保護することができる。ＥＣＣフレームワークに関与するエッジモデルおよびクラウドモデルを使用した推論のための３つの異なる構造、すなわち、独立型ＥＣＣフレームワーク、適応的ＥＣＣフレームワーク、および動的ＥＣＣフレームワークを以下に提案する。ＥＣＣフレームワークのこれらの変形例を使用すると、通信リソース、計算リソース、およびパフォーマンスの観点で様々なレベルの折衷案を有するモデルをトレーニングすることが可能になり、各監視システムで利用可能なリソースに基づいて、これらの変形例の中から選択を行うことができる。
ＥＣＣフレームワークの背後にある主な概念の１つは、推論の一部をエッジコンピューティングシステムに分散させつつ、残りの推論はクラウドコンピューティングシステムによって実行されることである。場合によっては、エッジコンピューティングシステムは推論を効果的に実行することが可能であり得るが、他の場合には、エッジコンピューティングシステムは、必要に応じてクラウドコンピューティングシステムのリソースを利用し得る。したがって、日常的に答えるべき問題は、いつデータをクラウドコンピューティングシステムに送信し、そのリソースを使用してより適切な推論を得るべきかということである。推論の一部が既にエッジコンピューティングシステムによって実行されていることを考慮すると、いつ送信するかに加えて、さらなる推論のために何をクラウドコンピューティングシステムに送信すべきかを問う必要がある。以下でさらに説明するように、データ全体そのものを送信することなく、エッジコンピューティングシステムによって出力された結果の特徴マップをクラウドコンピューティングシステムによる推論に利用することができる。この戦略により、通信コストを削減することが可能なだけでなく、クラウドコンピューティングシステムによって発生する計算コストも削減する。また、推論対象のデータをクラウドコンピューティングシステムにそのまま送信する必要がないので、対応するエッジデバイス上でデータのプライバシーを保護することができる。ＥＣＣフレームワークに関与するエッジモデルおよびクラウドモデルを使用した推論のための３つの異なる構造、すなわち、独立型ＥＣＣフレームワーク、適応的ＥＣＣフレームワーク、および動的ＥＣＣフレームワークを以下に提案する。ＥＣＣフレームワークのこれらの変形例を使用すると、通信リソース、計算リソース、およびパフォーマンスの観点で様々なレベルの折衷案を有するモデルをトレーニングすることが可能になり、各監視システムで利用可能なリソースに基づいて、これらの変形例の中から選択を行うことができる。
【0046】
Ｄ．独立型ＥＣＣフレームワーク
この構造では、エッジモデルは、入力として提供されたデータをさらなる推論のためにクラウドコンピューティングシステムにいつ送信すべきかを決定するためのフィルタリングメカニズムとして主に使用される。この決定は、エッジモデルによって出力された推論においてエッジデバイスが有する信頼性に基づいて行うことができる。図３Ａは、出力の信頼性が閾値よりも高い場合、エッジデバイス３０２上に実施されたエッジモデル３０４が推論を実行し、出力の信頼性が閾値よりも低い場合、コンピュータサーバシステム３０６上に実施されたクラウドモデル３０８が推論を実行する独立型ＥＣＣフレームワークの高レベルの図を含む。別の言い方をすると、エッジデバイス３０２は、信頼性が閾値を下回った場合に、より計算集約的なモデルにより推論を改善するために、入力データ、この場合は画像をコンピュータサーバシステム３０６に送信することができる。出力の信頼性が閾値よりも高い場合、エッジデバイス３０２は、出力が適切な推論であることをデータ構造内に示すことができる。たとえば、エッジデバイス３０２は、出力が適切な推論であることを、そのメモリ内に保持されているデータ構造内にそのように明記することによって示し得る。
この構造では、エッジモデルは、入力として提供されたデータをさらなる推論のためにクラウドコンピューティングシステムにいつ送信すべきかを決定するためのフィルタリングメカニズムとして主に使用される。この決定は、エッジモデルによって出力された推論においてエッジデバイスが有する信頼性に基づいて行うことができる。図３Ａは、出力の信頼性が閾値よりも高い場合、エッジデバイス３０２上に実施されたエッジモデル３０４が推論を実行し、出力の信頼性が閾値よりも低い場合、コンピュータサーバシステム３０６上に実施されたクラウドモデル３０８が推論を実行する独立型ＥＣＣフレームワークの高レベルの図を含む。別の言い方をすると、エッジデバイス３０２は、信頼性が閾値を下回った場合に、より計算集約的なモデルにより推論を改善するために、入力データ、この場合は画像をコンピュータサーバシステム３０６に送信することができる。出力の信頼性が閾値よりも高い場合、エッジデバイス３０２は、出力が適切な推論であることをデータ構造内に示すことができる。たとえば、エッジデバイス３０２は、出力が適切な推論であることを、そのメモリ内に保持されているデータ構造内にそのように明記することによって示し得る。
【0047】
この構造では、エッジデバイス３０２がエッジモデル３０４によって生成された出力に基づいて入力データをコンピュータサーバシステム３０６に送信することを決定した場合、入力データ全体を推論のためにコンピュータサーバシステム３０６に送信することができる。エッジモデル３０４が自身で推論を実行し、そのため、エッジデバイス３０２が入力データをコンピュータサーバシステム３０６に送信しない２つのケースを考えることができる。
【0048】
第１に、所与のサンプルに対する出力の信頼性が十分に高い場合、推論はエッジモデル３０４のみによって実行され得る。信頼性を示すメトリクスが閾値を超えている場合、信頼性は十分に高いとみなされる。この閾値は、エッジデバイス３０２のメモリにプログラムすることができる。閾値は一般に静的であるが、閾値は推論の性質に基づいて異なり得る。たとえば、分類タスクの閾値は、オブジェクト検出タスクの閾値と異なり得る。同様に、信頼性自体の性質も異なり得る。たとえば、この信頼性は、分類タスクにおけるクラスの信頼性であり得、またはこの信頼性は、オブジェクト検出タスクのために所与の画像で検出されたオブジェクトの信頼性の平均であり得る。
【0049】
もう１つの、場合によってはより重要なケースは、エッジデバイス３０２が、検出対象の情報を含まないサンプルを生成する場合に起こる。このシナリオでは、それらのサンプルは関心対象のクラスまたはオブジェクトを含まないので、通信リソースおよび計算リソースを節約するためにエッジデバイス３０２によって破棄することができる。このシナリオはほとんどのエッジベースの監視システムでよく起こり、そのようなサンプルを転送するには、利用可能な通信リソースまたは計算リソースが必要になる（場合によっては使い果たす）。別の観点から、このシナリオは前述の第１のケースの一例とみなすことができ、このシナリオを除けば、これらのサンプルは別個のクラス（たとえば、分類タスクでの正常クラス）または別個のオブジェクト（たとえば、オブジェクト検出タスクにおける背景オブジェクト）とみなされ得る。この別個のクラスまたは別個のオブジェクトに関して、エッジモデル３０４によって生成された出力の信頼性が高い場合、エッジモデル３０４は推論を結論付けることができる。そうでない場合、エッジデバイス３０２は、さらなる推論結果を得るためにサンプルをコンピュータサーバシステム３０６に送信することができる。したがって、独立型フレームワークに従って実施される場合、ＥＣＣモデルは次のルールを実施することができる。
【0050】
【数8】
【0051】
図３Ｂは、エッジモデルによって出力として生成された推論の信頼性を使用して、クラウドモデルによるさらなる分析が必要か否かを判定することができる方法を示す高レベルのフローチャートを含む。図３Ｂに示すように、最初にエッジモデルを所与のサンプルに適用して第１の推論を生成し、次いで、第１の推論の信頼性が閾値を下回った場合に、クラウドモデルを所与のサンプルに適用して第２の推論を生成する多段階プロセスの一部として、所与のサンプルに対する適切な推論を決定することができる。第１の推論の信頼性が十分に高い（たとえば、閾値を超える）シナリオでは、推論の指示（ｉｎｄｉｃａｔｉｏｎ）をデータ構造に記憶することができる。データ構造はエッジデバイスのメモリ内に保持することができ、またはエッジデバイスは第１の推論（または第１の推論を示す情報）を他の場所に送信することができる。たとえば、データ構造はコンピュータサーバシステムのメモリ内に保持することができ、またはデータ構造は仲介デバイスのメモリ内に保持することができる。具体的には、データ構造は、仲介デバイス上で実行されるコンピュータプログラムによって管理することができ、コンピュータプログラムは、監視システムのエッジデバイスによって生成された推論、ならびに監視システムのエッジデバイスの代わりにコンピュータサーバシステムによって生成された推論をモニタリングし得る。
【0052】
Ｅ．適応的ＥＣＣフレームワーク
この構造では、主な目標は、エッジモデルの特徴マップをクラウドモデル上の対応する特徴マップに適応させることである。そうすると、エッジデバイスからのこれらの適応された特徴マップは、クラウドモデル内の指定された層（たとえば、中間層）への入力として使用することができるので、クラウドモデル内の１つまたは複数の層をバイパスすることができ、その結果、全体の計算コストが削減される。図４Ａは、エッジデバイス４０２上に実施されたエッジモデル４０４が、信頼性が閾値よりも高いサンプルに対して推論を実行する適応的ＥＣＣフレームワークの高レベルの図を含む。しかしながら、信頼性が閾値を下回る場合、エッジデバイス４０２は、その特徴マップ４０６をコンピュータサーバシステム４０８上に実施されたクラウドモデル４１０に送信することができる。図４Ａに示すように、クラウドモデル４１０は、その中間層の１つに対する入力として特徴マップを使用することができる。適応化は、エッジモデル４０４およびクラウドモデル４１０の任意の２つの層の間で実行することができ、適応化は通常、リソース管理の目的でコンピュータサーバシステム４０８によって実行される。
この構造では、主な目標は、エッジモデルの特徴マップをクラウドモデル上の対応する特徴マップに適応させることである。そうすると、エッジデバイスからのこれらの適応された特徴マップは、クラウドモデル内の指定された層（たとえば、中間層）への入力として使用することができるので、クラウドモデル内の１つまたは複数の層をバイパスすることができ、その結果、全体の計算コストが削減される。図４Ａは、エッジデバイス４０２上に実施されたエッジモデル４０４が、信頼性が閾値よりも高いサンプルに対して推論を実行する適応的ＥＣＣフレームワークの高レベルの図を含む。しかしながら、信頼性が閾値を下回る場合、エッジデバイス４０２は、その特徴マップ４０６をコンピュータサーバシステム４０８上に実施されたクラウドモデル４１０に送信することができる。図４Ａに示すように、クラウドモデル４１０は、その中間層の１つに対する入力として特徴マップを使用することができる。適応化は、エッジモデル４０４およびクラウドモデル４１０の任意の２つの層の間で実行することができ、適応化は通常、リソース管理の目的でコンピュータサーバシステム４０８によって実行される。
【0053】
独立型ＥＣＣフレームワークに関して上記で論じたように、エッジモデル４０４によって生成された推論の出力は依然としてフィルタリングに使用され得るが、このシナリオでは、サンプル自体ではなく特徴マップがコンピュータサーバシステム４０８に送信される。クラウドモデル４１０の異なる層に対応する適応化モジュール４１２ａ～ｃを使用する適応化プロセスは、コンピュータサーバシステム４０８によって実行することができる。この構造では、エッジモデル４０４およびクラウドモデル４１０ならびに適応化モジュール４１２ａ～ｃのトレーニングを結合することができる。
【0054】
この構造では、適応化モジュール４１２ａ～ｃを使用して、層の追加を通じて、エッジモデル４０４によって生成された特徴マップをクラウドモデル４１０の対応する特徴マップに転送することができる。図４Ａでは、これらの層は
によって表され、
によってパラメータ化され、ここで、ｍはエッジモデル４０４における特徴マップ層のインデックスであり、ｎはクラウドモデル４１０における特徴マップのインデックスである。これらの補助層は、次のように、エッジモデルの第ｍ層の出力（
）をクラウドモデルの第ｎ層の出力（
）に適応させることができる。
【数9】
【数10】
【数11】
【数12】
【数13】
【0055】
大まかに言えば、目的は
および
の特徴マップ間の距離を最小化することであり、この目標を達成するためにトレーニング中に知識蒸留アプローチが使用される。推論中に、独立型ＥＣＣフレームワークと同様に、閾値ｃ1を使用してサンプルをフィルタリングすることができる。しかしながら、サンプル（たとえば、エッジデバイス４０２がカメラである場合には画像全体）を送信する代わりに、特徴マップをコンピュータサーバシステム４０８に代わりに送信することができる。したがって、ＥＣＣモデルは、適応的フレームワークに従って実施される場合、次のルールを実施することができる。
【数14】
【数15】
【0056】
【数16】
【数17】
【数18】
【数19】
【0057】
図４Ｂは、エッジモデルによって出力として生成された推論の信頼性を使用して、特徴マップをさらなる分析のためにコンピュータサーバシステムに提供すべきか否かを判定することができる方法を示す高レベルのフローチャートを含む。図４Ｂに示すプロセスは、図３Ｂに示すプロセスと大きく類似し得る。しかしながら、ここでは、サンプル自体ではなく、特徴マップがコンピュータサーバシステムに提供される。これらの特徴マップは、クラウドモデルの指定された層に入力として提供することができる。一般に、指定された層はクラウドモデルの中間層であり、これにより、推論段階中にクラウドモデルの少なくとも１つの層をバイパスすることが可能になる。
【0058】
Ｆ．知識蒸留および適応化
従来、知識蒸留には主に２つのアプローチがあり、すなわち、（ｉ）ニューラルネットワークによって使用されるソフトマックス関数の温度を調整することにより、信頼性スコアを通じて知識を蒸留するアプローチ、ならびに（ｉｉ）ニューラルネットワークの異なる層に対してヒント層および特徴模倣（ｆｅａｔｕｒｅ ｉｍｉｔａｔｉｏｎ）を使用して知識を蒸留するアプローチがある。ＥＣＣフレームワークでは、後者に焦点を当てており、その理由は、知識の適応化にも使用できるためである。しかしながら、前者のアプローチも、エッジモデルのパフォーマンスを向上させるために依然として使用することができる。ヒント層のために、従来のアプローチは、全結合ニューラルネットワークの１つの層または畳み込みニューラルネットワークの１つの層などの単純な適応化モジュールを使用して、適応化モジュール自体ではなく、生徒モジュールのパラメータに主に焦点を当てる。しかしながら、本開示は、ドメイン適応化および変分オートエンコーダで使用されるものと同様に、ディープニューラルネットワークを残差層またはボトルネック層として使用することを提案する。これはいくつかの理由で行う。まず、単純なニューラルネットワークよりもディープニューラルネットワークを使用する方が、生徒モデルのパフォーマンスを向上させることができる。第２に、適応化モジュールを前述のように知識の適応化に使用することができ、ディープニューラルネットワークはエッジモデルからクラウドモデルに特徴マップを適応させた際により優れたパフォーマンスを実現することができる。
従来、知識蒸留には主に２つのアプローチがあり、すなわち、（ｉ）ニューラルネットワークによって使用されるソフトマックス関数の温度を調整することにより、信頼性スコアを通じて知識を蒸留するアプローチ、ならびに（ｉｉ）ニューラルネットワークの異なる層に対してヒント層および特徴模倣（ｆｅａｔｕｒｅ ｉｍｉｔａｔｉｏｎ）を使用して知識を蒸留するアプローチがある。ＥＣＣフレームワークでは、後者に焦点を当てており、その理由は、知識の適応化にも使用できるためである。しかしながら、前者のアプローチも、エッジモデルのパフォーマンスを向上させるために依然として使用することができる。ヒント層のために、従来のアプローチは、全結合ニューラルネットワークの１つの層または畳み込みニューラルネットワークの１つの層などの単純な適応化モジュールを使用して、適応化モジュール自体ではなく、生徒モジュールのパラメータに主に焦点を当てる。しかしながら、本開示は、ドメイン適応化および変分オートエンコーダで使用されるものと同様に、ディープニューラルネットワークを残差層またはボトルネック層として使用することを提案する。これはいくつかの理由で行う。まず、単純なニューラルネットワークよりもディープニューラルネットワークを使用する方が、生徒モデルのパフォーマンスを向上させることができる。第２に、適応化モジュールを前述のように知識の適応化に使用することができ、ディープニューラルネットワークはエッジモデルからクラウドモデルに特徴マップを適応させた際により優れたパフォーマンスを実現することができる。
【0059】
クラウドモデルの知識を蒸留するために、コンピュータサーバシステムは、次のように、エッジモデルの第ｍ層の適応された特徴マップと、クラウドモデルの第ｎ層の特徴マップとの間のバイナリクロスエントロピー損失を使用することができる。
ここで、σ（ｘ）＝１／（１＋ｅ-x）は、クラウドモデルと、適応化モジュールによって使用される適応化モデルとの特徴マップ内の各ピクセルの値を正規化するためのシグモイド関数である。この例では入力サンプルが画像であることを前提としているが、この知識蒸留のアプローチは、他のタイプの入力にも同様に適用可能であり得る。この損失を使用して、適応化モジュールパラメータ
【数20】
【0060】
【数21】
【数22】
【0061】
Ｇ．動的ＥＣＣフレームワーク
一般に、独立型ＥＣＣフレームワークのパフォーマンスは、クラウドモデルが推論の生成の全責任を負う場合とほぼ同じくらい優れている。しかしながら、一部のサンプルに関して、入力データがエッジモデルおよびクラウドモデルを通過する必要があるため、一部のシナリオによっては計算コストが依然として負担となり得るので、推論時間が遅れ得る。一方、適応的ＥＣＣフレームワークは、クラウドモデルと比較して一部のパフォーマンス尺度を犠牲にすることで計算コストを効率的に削減することができる。独立型ＥＣＣフレームワークと適応的ＥＣＣフレームワークとを組み合わせることで、両方のアプローチの利点を実現することができる。これを実現するには、異なる入力データに対して各ＥＣＣモデルをいつ使用するかを動的に決定することが可能なメカニズムを実施する必要がある。１つのアプローチは、エッジモデルによって出力された推論結果の信頼性レベルを使用して、サンプルごとにこれら２つのＥＣＣモデルのどちらかに決めることである。動的ＥＣＣフレームワークを使用すると、コンピュータサーバシステムは、エッジ－クラウドモデルの通信リソース、計算リソース、およびパフォーマンスの間の様々なレベルのトレードオフを有するモデルを学習することができる。この遷移に最適な閾値を見つけることにより、動的ＥＣＣモデルの構造を次のように定義することができる。
一般に、独立型ＥＣＣフレームワークのパフォーマンスは、クラウドモデルが推論の生成の全責任を負う場合とほぼ同じくらい優れている。しかしながら、一部のサンプルに関して、入力データがエッジモデルおよびクラウドモデルを通過する必要があるため、一部のシナリオによっては計算コストが依然として負担となり得るので、推論時間が遅れ得る。一方、適応的ＥＣＣフレームワークは、クラウドモデルと比較して一部のパフォーマンス尺度を犠牲にすることで計算コストを効率的に削減することができる。独立型ＥＣＣフレームワークと適応的ＥＣＣフレームワークとを組み合わせることで、両方のアプローチの利点を実現することができる。これを実現するには、異なる入力データに対して各ＥＣＣモデルをいつ使用するかを動的に決定することが可能なメカニズムを実施する必要がある。１つのアプローチは、エッジモデルによって出力された推論結果の信頼性レベルを使用して、サンプルごとにこれら２つのＥＣＣモデルのどちらかに決めることである。動的ＥＣＣフレームワークを使用すると、コンピュータサーバシステムは、エッジ－クラウドモデルの通信リソース、計算リソース、およびパフォーマンスの間の様々なレベルのトレードオフを有するモデルを学習することができる。この遷移に最適な閾値を見つけることにより、動的ＥＣＣモデルの構造を次のように定義することができる。
【0062】
【数23】
【0063】
したがって、エッジデバイスは、最初に、環境の監視を通じて生成されたサンプルにモデルを適用して、サンプルに関して行われた推論を表す出力を生成することができる。サンプルの性質は、エッジデバイスの性質に応じて異なり得る。一例として、エッジデバイスがカメラである場合、サンプルは画像であり得る。次いで、エッジデバイスは、各出力の信頼性が閾値を超えているか否かを判定することができる。信頼性が閾値を超えていない各出力について、エッジデバイスは、（ｉ）対応するサンプル、または（ｉｉ）対応するサンプルに関連する情報の、分析のためのコンピュータサーバシステムへの送信を引き起こすことができる。たとえば、エッジデバイスはそのカメラによって生成された画像を送信することができ、またはエッジデバイスはそのカメラによって生成された画像を表す特徴マップを送信することができる。
【0064】
Ｈ．さらなる特徴
ＥＣＣフレームワークのいくつかの部分は、問題に基づいて変更（たとえば、調整）することができる。一例として、問題に基づいて適応化層を変更することができる。これは、エッジモデルの任意の層からクラウドモデルの任意の層へ行うことができる。しかしながら、理論的には、エッジモデルの終わりに近い層とクラウドモデルの先頭に近い層とが選択されると、モデルはＥＣＣモデルに近づき、そのため、パフォーマンスは向上するが、通信コストおよび計算コストが高くなる。
ＥＣＣフレームワークのいくつかの部分は、問題に基づいて変更（たとえば、調整）することができる。一例として、問題に基づいて適応化層を変更することができる。これは、エッジモデルの任意の層からクラウドモデルの任意の層へ行うことができる。しかしながら、理論的には、エッジモデルの終わりに近い層とクラウドモデルの先頭に近い層とが選択されると、モデルはＥＣＣモデルに近づき、そのため、パフォーマンスは向上するが、通信コストおよび計算コストが高くなる。
【0065】
適応化モジュールの構造およびサイズは変更することができ、これらの変更は、当面の問題に応じてＥＣＣモデルの全体的なパフォーマンスに影響を与え得る。同様に、各ＥＣＣフレームワークの閾値は問題に基づいて調整することができるので、事前に設定されなくてもよい。別の言い方をすると、各ＥＣＣフレームワークの閾値は事前に決定されなくてもよく、代わりに問題に基づいて動的に決定することができる。
【0066】
一般に、ＥＣＣモデルのトレーニング手順はむしろ標準的である。たとえば、トレーニング手順は、知識蒸留を用いてエッジモデルをトレーニングすることから始め、その後、適応化モジュールを用いてファインチューニングし得る。あるいは、エッジモデルおよび適応化モジュールを一緒にトレーニングすることもできる。
【0067】
処理システム
図５は、本明細書に記載の少なくともいくつかのプロセスを実施することができる処理システム５００の一例を示すブロック図である。たとえば、処理システム５００のコンポーネントは、エッジデバイス、仲介デバイス、またはコンピュータサーバシステム上でホストされ得る。
図５は、本明細書に記載の少なくともいくつかのプロセスを実施することができる処理システム５００の一例を示すブロック図である。たとえば、処理システム５００のコンポーネントは、エッジデバイス、仲介デバイス、またはコンピュータサーバシステム上でホストされ得る。
【0068】
処理システム５００は、１つまたは複数の中央処理装置（「プロセッサ」）５０２、メインメモリ５０６、不揮発性メモリ５１０、ネットワークアダプタ５１２、ビデオディスプレイ５１８、入出力デバイス５２０、制御デバイス５２２（たとえば、キーボードまたはポインティングデバイス）、記憶媒体５２６を含むドライブユニット５２４、および信号生成デバイス５３０を含み得、これらはバス５１６に通信可能に接続される。バス５１６は、適切なブリッジ、アダプタ、またはコントローラによって接続される１つまたは複数の物理バスまたはポイントツーポイント接続を表す抽象概念として示されている。したがって、バス５１６は、システムバス、周辺コンポーネント相互接続（ＰＣＩ）バスまたはＰＣＩ－Ｅｘｐｒｅｓｓバス、ＨｙｐｅｒＴｒａｎｓｐｏｒｔまたは業界標準アーキテクチャ（ＩＳＡ）バス、スモールコンピュータシステムインターフェース（ＳＣＳＩ）バス、ユニバーサルシリアルバス（ＵＳＢ）、集積回路間（Ｉ2Ｃ）バス、または電気電子学会（ＩＥＥＥ）標準１３９４バス（「Ｆｉｒｅｗｉｒｅ」とも呼ばれる）を含むことができる。
【0069】
処理システム５００は、デスクトップコンピュータ、タブレットコンピュータ、携帯電話、ゲームコンソール、音楽プレーヤー、ウェアラブル電子デバイス（たとえば、時計またはフィットネストラッカー）、ネットワーク接続された（「スマート」）デバイス（たとえば、テレビまたはホームアシスタントデバイス）、仮想／拡張現実システム（たとえば、ヘッドマウントディスプレイ）、または処理システム５００によって取られるアクションを指定する（順次またはその他の）命令のセットを実行することが可能な他の電子デバイスと同様のプロセッサアーキテクチャを共有し得る。
【0070】
メインメモリ５０６、不揮発性メモリ５１０、および記憶媒体５２６は単一の媒体として示されているが、「機械可読媒体」および「記憶媒体」という用語は、１つまたは複数の命令セット５２８を記憶する単一の媒体または複数の媒体（たとえば、集中型／分散型データベースならびに／あるいは関連付けられたキャッシュおよびサーバ）を含むように解釈されるべきである。「機械可読媒体」および「記憶媒体」という用語はまた、処理システム５００によって実行される命令セットを記憶する、符号化する、または持ち運ぶことが可能な任意の媒体を含むように解釈されるものとする。
【0071】
一般に、本開示の実施形態を実施するために実行されるルーチンは、オペレーティングシステム、または特定のアプリケーション、コンポーネント、プログラム、オブジェクト、モジュール、または命令のシーケンス（総称して「コンピュータプログラム」と呼ばれている）の一部として実施され得る。コンピュータプログラムは、典型的には、電子デバイス内の様々なメモリおよび記憶デバイスに様々な時点で配置される１つまたは複数の命令（たとえば、命令５０４、５０８、５２８）を含む。命令は、プロセッサ５０２によって読み取られて実行された場合に、処理システム５００に、本開示の様々な態様に関与する要素を実行するための動作を行わせる。
【0072】
さらに、完全に機能する電子デバイスのコンテキストで実施形態を説明したが、当業者であれば、本技術のいくつかの態様が様々な形態のプログラム製品として配布されることが可能であることを理解するであろう。本開示は、配布を行うために使用される機械可読媒体またはコンピュータ可読媒体の特定のタイプに関係なく適用される。
【0073】
機械可読媒体およびコンピュータ可読媒体のさらなる例には、記録可能なタイプの媒体、たとえば、揮発性メモリデバイスおよび不揮発性メモリデバイス５１０、リムーバブルディスク、ハードディスクドライブ、および光ディスク（たとえば、コンパクトディスク読み取り専用メモリ（ＣＤ－ＲＯＭ）およびデジタルバーサタイルディスク（ＤＶＤ））、ならびに伝送タイプの媒体、たとえば、デジタルおよびアナログ通信リンクが含まれる。
【0074】
ネットワークアダプタ５１２は、処理システム５００が、ネットワーク５１４において、処理システム５００の外部のエンティティとの間で、処理システム５００および外部エンティティによってサポートされる任意の通信プロトコルを通じて、データを仲介することを可能にする。ネットワークアダプタ５１２は、ネットワークアダプタカード、無線ネットワークインターフェースカード、ルータ、アクセスポイント、無線ルータ、スイッチ、マルチレイヤスイッチ、プロトコルコンバータ、ゲートウェイ、ブリッジ、ブリッジルータ、ハブ、デジタルメディアレシーバ、リピータ、またはこれらの任意の組み合わせを含むことができる。
【0075】
ネットワークアダプタ５１２は、ネットワーク内のデータにアクセス／プロキシするための許可を統括および／または管理するファイアウォールを含み得る。ファイアウォールは、様々なマシンおよび／またはアプリケーション間の様々な信頼レベルも追跡し得る。ファイアウォールは、マシンとアプリケーション、マシンとマシン、またはアプリケーションとアプリケーションのセットの間で（たとえば、これらのエンティティ間のトラフィックの流れおよびリソース共有を規制するために）所定のアクセス権のセットを施行することが可能なハードウェア、ファームウェア、またはソフトウェアコンポーネントの任意の組み合わせを有する任意の数のモジュールとすることができる。ファイアウォールはさらに、個人、マシン、またはアプリケーションによるオブジェクトへのアクセス権および操作権を含む許可と、その許可権が成立する状況とを詳述したアクセス制御リストを管理し得、および／またはアクセス制御リストにアクセス可能であり得る。
【0076】
注意事項
特許請求する主題の様々な実施形態の前述の説明は、例示および説明の目的で提供している。これは網羅的であることも、特許請求する主題を開示した正確な形態に限定することも意図したものではない。多くの修正および変形が当業者には明らかであろう。実施形態は、本発明の原理およびその実際の適用を最もよく説明するために選択および説明しており、これにより、特許請求する主題、様々な実施形態、および考えられる特定の用途に適した様々な修正を関連技術における当業者が理解できるようにしている。
特許請求する主題の様々な実施形態の前述の説明は、例示および説明の目的で提供している。これは網羅的であることも、特許請求する主題を開示した正確な形態に限定することも意図したものではない。多くの修正および変形が当業者には明らかであろう。実施形態は、本発明の原理およびその実際の適用を最もよく説明するために選択および説明しており、これにより、特許請求する主題、様々な実施形態、および考えられる特定の用途に適した様々な修正を関連技術における当業者が理解できるようにしている。
【0077】
詳細な説明では、特定の実施形態および考えられる最良の形態を説明しているが、詳細な説明がどれほど詳細に見えても、本技術は多くの方法で実践することができる。実施形態はそれらの実施の詳細が大幅に異なり得るが、依然として本明細書に包含される。様々な実施形態の特定の特徴または態様を説明する際に使用する特定の用語は、その用語が関連付けられた本技術の任意の特定の特性、特徴、または態様に限定されるようにその用語が本明細書で再定義されることを意味するものと解釈されるべきではない。一般に、添付の特許請求の範囲で使用する用語は、それらの用語を本明細書で明示的に定義していない限り、本明細書で開示した特定の実施形態に本技術を限定するものと解釈されるべきではない。したがって、本技術の実際の範囲は、開示した実施形態だけでなく、実施形態を実践または実施する全ての等価な方法も包含する。
【0078】
本明細書で使用している文言は、主に読みやすさおよび説明の目的で選択している。これは、本主題の線引きをしたりその範囲を限定したりするために選択したものではない場合がある。したがって、本技術の範囲は、この詳細な説明によってではなく、本明細書に基づく出願で発行される任意の特許請求の範囲によって限定されるものとする。したがって、様々な実施形態の開示は、添付の特許請求の範囲に記載したように本技術の範囲を限定するものではなく、例示することを意図している。
【図1】
【図2】
【図3A】
【図3B】
【図4A】
【図4B】
【図5】
【国際調査報告】