特許 7555388 画像理解によるデータパイプラインの構成

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-09-12

(45)【発行日】2024-09-24

(54)【発明の名称】画像理解によるデータパイプラインの構成

(51)【国際特許分類】

   G06T 1/20 20060101AFI20240913BHJP

   H04N 23/60 20230101ALI20240913BHJP

【ＦＩ】

G06T1/20 C

H04N23/60

【請求項の数】 41

(21)【出願番号】P 2022502793

(86)(22)【出願日】2020-03-12

(65)【公表番号】

(43)【公表日】2022-05-26

(86)【国際出願番号】 US2020022485

(87)【国際公開番号】W WO2020190657

(87)【国際公開日】2020-09-24

【審査請求日】2023-03-13

(31)【優先権主張番号】16/355,705

(32)【優先日】2019-03-15

(33)【優先権主張国・地域又は機関】US

(73)【特許権者】

【識別番号】521425272

【氏名又は名称】シネラ インコーポレイテッド

(73)【特許権者】

【識別番号】316005926

【氏名又は名称】ソニーセミコンダクタソリューションズ株式会社

(74)【代理人】

【識別番号】110001243

【氏名又は名称】弁理士法人谷・阿部特許事務所

(72)【発明者】

【氏名】アンドリュー オーガスチン ヴァイズ

(72)【発明者】

【氏名】アヴィラム コーヘン

(72)【発明者】

【氏名】下村 宗弘

(72)【発明者】

【氏名】三好 弘孝

【審査官】三沢 岳志

(56)【参考文献】

【文献】米国特許出願公開第２０１９／００４２８７０（ＵＳ，Ａ１）

【文献】米国特許出願公開第２０１４／０１６８０８４（ＵＳ，Ａ１）

【文献】米国特許出願公開第２０１７／０３３６８５８（ＵＳ，Ａ１）

【文献】国際公開第２０１９／０２１７９３（ＷＯ，Ａ１）

【文献】特表２００８－５０８８０２（ＪＰ，Ａ）

【文献】Jon PATMAN et al.，“Predictive analytics for fog computing using machine learning and GENI”，IEEE INFOCOM 2018 - IEEE Conference on Computer Communications Workshops (INFOCOM WKSHPS)，IEEE，2018年04月15日，DOI: 10.1109/INFCOMW.2018.8407027

【文献】小牧 大治郎ほか，“IoTアプリケーション開発のためのメディア制御・処理フレームワーク”，情報処理学会シンポジウムシリーズ(CD-ROM) = IPSJ Symposium Series (CD-ROM)，2016号，情報処理学会，2016年06月29日，pp.79－88，<https://ipsj.ixsq.nii.ac.jp/ej/?action=repository_uri&item_id=177115&file_id=1&file_no=1>

【文献】Raul RAMOS-POLLAN et al.，“A framework for high performance image analysis pipelines”，2012 7th Colombian Computing Congress (CCC)，IEEE，2012年10月，DOI: 10.1109/COLOMBIANCC.2012.6398003

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｔ １／２０

Ｈ０４Ｎ ２３／６０

(57)【特許請求の範囲】

【請求項1】

複数の構成可能なノードを含むネットワークについて、画像理解を必要とする１つ以上のアプリケーションのために、前記ノードをデータパイプラインに編成する方法であって、
前記ノードの各々の機能の記述を含む機能オブジェクトを受信するステップであって、前記機能オブジェクトの構文は規格により定義されており、前記規格に従って、特定のノードの前記機能オブジェクトは、前記特定のノードのために任意の入力ポートおよび出力ポートを定義するとともに、前記特定のノードが提供できる処理とトランスデューサの少なくとも１つを定義することと、
前記機能オブジェクトにおける前記記述に基づいて、前記データパイプラインに含めるノードを選択し、前記選択されたノード間の相互接続を決定して前記データパイプラインを形成するステップであって、前記選択された少なくとも１つのノードの前記機能オブジェクトは、前記データパイプラインに使用された少なくとも１つのセンサ機能を定義し、前記選択されたノードの他の少なくとも１つの前記機能オブジェクトは、前記データパイプラインに使用された画像理解機能を定義することと、
制御データを前記選択されたノードに規格に従って送信するステップであって、前記制御データは、対応する前記機能オブジェクトに定義された前記処理および／またはトランスデューサに従って、前記データパイプラインにおける各ノードの役割に応じて前記選択されたノードの機能を指定するとともに、前記選択されたノード間の前記決定された相互接続を、対応する前記機能オブジェクトにおいて定義された前記入力ポート及び前記出力ポートに従って指定することと、
を含み、
前記データパイプラインは、前記データパイプラインのソースとして動作するセンサ機能にアクセスできる１つ以上のノードを含み、前記ソースの少なくとも１つは画像を取り込み、前記データパイプラインは、前記ソースによって取り込まれたセンサデータから画像データ及び画像理解メタデータを生成し、前記画像データは、取り込まれた画像及び／または前記取り込まれた画像から現像された拡張画像を含み、前記画像理解メタデータは、前記画像データの画像理解を記述し、前記画像理解に対応する前記画像データを参照するメタデータを含み、前記制御データは、前記データパイプラインによって生成された前記画像データ及び前記画像理解メタデータをも指定する、方法。

【請求項2】

前記データパイプラインが、事前に指定されたオブジェクトの検出、事前に指定されたオブジェクトの不在の検出、及び／または事前に指定されたオブジェクトの識別を含む画像理解を行い、画像理解メタデータが前記画像理解を記述する、請求項１に記載の方法。

【請求項3】

前記事前に指定されたオブジェクトが、顔、人間、動物、車両、テキスト、ロゴ、またはバーコードの少なくとも１つを含む、請求項２に記載の方法。

【請求項4】

前記データパイプラインは、前記指定されたオブジェクトの検出または識別に基づいて、さらなる理解を含む画像理解を行い、前記画像理解メタデータは、前記画像理解を記述することを特徴とする請求項２に記載の方法。

【請求項5】

前記データパイプラインは、事前に指定されたアクションまたはアクティビティの検出、事前に指定された動作または活動の検出、事前に指定された位置または環境の検出、及び／または事前に指定された位置または環境の識別を含む画像理解を行い、前記画像理解メタデータは、前記画像理解を記述することを特徴とする請求項１に記載の方法。

【請求項6】

前記データパイプラインは、機械学習、深層学習及び／または人工知能技術を用いて画像理解を行い、前記画像理解メタデータが前記画像理解を記述することを特徴とする請求項１に記載の方法。

【請求項7】

前記制御データは、画像理解のマルチレベルモデルに基づいて、前記マルチレベルモデルは、動き検出レベル、物体検出レベル、物体識別レベル、及び物体特性化レベルを含む、請求項１に記載の方法。

【請求項8】

前記機能の記述は、前記マルチレベルモデルのどのレベルを各ノードによって実装できるか、及びどのレベルをどのオブジェクトによって実装できるかを指定する、請求項７に記載の方法。

【請求項9】

前記制御データは、前記マルチレベルモデルのどのレベルが前記選択されたノードに対して構成されているか、及びどのオブジェクトに対して構成されているかを指定する請求項７に記載の方法。

【請求項10】

前記ノードの機能の前記記述は、前記ノードの画像現像機能の記述を含む、請求項１に記載の方法。

【請求項11】

前記画像現像機能は、センサバイアスの補正、画素欠陥の補正、周辺光量補正、ダークフレーム減算、ホワイトバランス、デモザイキング、ノイズリダクション、空間フィルタリング、色空間変換、トーンマッピング、ガンマ補正、コントラスト強調、エッジ強調、収差補正、フォーカス調整、露出調整、リサンプリング、解像度向上、ハイダイナミックレンジ調整、カラーフィルターアレイ補間のうち、少なくとも１つを含む、請求項１０に記載の方法。

【請求項12】

前記データパイプラインは、異なるセンサ機能、画像現像機能、及び／または画像理解機能を含む異なる分岐を含み、前記異なる分岐は、前記画像理解に関する条件によってトリガーされる、請求項１に記載の方法。

【請求項13】

前記制御データは、前記画像理解に関する条件も指定する、請求項１２に記載の方法。

【請求項14】

前記データパイプラインは、少なくとも１つの画像理解機能からのフィードバックループを含む、請求項１に記載の方法。

【請求項15】

前記フィードバックループが、前記画像理解機能から少なくとも１つの画像取り込み機能へのものである、請求項１４に記載の方法。

【請求項16】

前記画像理解機能は前記ノードの１つに実装され、前記フィードバックループは、前記画像理解機能から別のノードの機能へのものである、請求項１４に記載の方法。

【請求項17】

前記データパイプラインは、異なるタイプのセンサデータを取り込む複数のソースへのアクセスを有し、前記データパイプラインは、少なくとも１つの画像理解機能のためにセンサデータを融合する、請求項１に記載の方法。

【請求項18】

前記データパイプラインに含めるノードを選択し、前記選択されたノード間の相互接続を決定して前記データパイプラインを形成することは、前記データパイプラインにセンサデータを提供するセンサ間の既知の近接性にさらに基づく、請求項１に記載の方法。

【請求項19】

前記データパイプラインに含めるノードを選択し、前記選択されたノード間の相互接続を決定して前記データパイプラインを形成することは、前記ノードの前記機能の前記記述に含まれない情報にさらに基づく、請求項１に記載の方法。

【請求項20】

構成可能なノードの前記ネットワークは、マイク、温度センサ、及びスピーカのうちの少なくとも１つへのアクセスをも含む、請求項１に記載の方法。

【請求項21】

少なくとも１つのアプリケーションが、前記ノードにアクセスする仲介サービスにアクセスする、請求項１に記載の方法。

【請求項22】

前記ノードへのアクセスが条件付きアクセスである、請求項１に記載の方法。

【請求項23】

前記条件付きアクセスは、前記アプリケーション及び前記ノードとは別のサービスによって許可される、請求項２２に記載の方法。

【請求項24】

前記データパイプラインは、インターネットを介して少なくとも１つのノードにアクセスする、請求項１に記載の方法。

【請求項25】

複数の異なるアプリケーションによってアクセス可能な複数の構成可能なノードを含むネットワークについて、各アプリケーションが、前記ネットワークからのノードをそのアプリケーションのためのデータパイプラインに編成するための、規格で規定された方法であって、前記データパイプラインは画像理解を必要とし、
前記ノードの能力の記述に基づいて、前記データパイプラインに含めるノードを選択し、前記選択されたノード間の相互接続を決定して前記データパイプラインを形成するステップであって、前記能力の記述は、規格により定義されており、前記ノードの前記能力は、前記ノードによるセンサ機能へのアクセスを含み、前記ノードの画像理解機能も含むことと、
前記データパイプラインにおける各ノードの役割と、前記選択されたノード間の前記決定された相互接続と、に応じて、前記選択されたノードにSceneModesを送信するステップであって、前記SceneModesは、前記選択されたノードと、前記選択されたノード間の前記決定された相互接続と、の機能を指定するために前記規格によって定義されることと、
を含み、
前記データパイプラインが、前記データパイプラインのソースとして動作するセンサ機能にアクセスできる１つ以上のノードを含み、前記ソースの少なくとも１つが画像を取り込み、前記データパイプラインが、前記ソースによって取り込まれたセンサデータからSceneData及びSceneMarksを生成し、前記SceneDataが、取り込まれた画像及び／または前記取り込まれた画像から現像された拡張画像を含み、前記SceneMarksは、前記SceneDataの画像理解を記述する画像理解メタデータと、前記画像理解に対応する前記SceneDataへの参照とを含むように前記規格で定義され、前記SceneModesは、前記データパイプラインによって生成された前記SceneDataと前記SceneMarksとを指定するように前記規格で定義されている、方法。

【請求項26】

前記規格で定義された前記SceneModesが、Face SceneMode、Human SceneMode、ObjectLabel SceneMode、Animal SceneMode、Text SceneMode、Logo SceneMode、Barcode SceneMode、及びVehicle SceneModeのうちの少なくとも１つを含む、請求項２５に記載の方法。

【請求項27】

前記規格で定義された前記SceneMarksは、物体の検出、及び物体の識別の少なくとも１つを記述する画像理解メタデータを含む、請求項２５に記載の方法。

【請求項28】

前記SceneMarksは、前記SceneDataの前記画像理解におけるトリガーの発生時に生成され、前記SceneModesは、前記トリガーも指定するように前記規格で定義されている、請求項２５に記載の方法。

【請求項29】

前記規格で指定された方法で、前記ノードの能力の前記記述にアクセスすることをさらに含む、請求項２５に記載の方法。

【請求項30】

前記規格は、各ノードからそのノードの前記能力を発見するための自動発見プロセスを指定している、請求項２９に記載の方法。

【請求項31】

前記規格は、前記ノードの前記能力の前記記述を含むデータオブジェクトを指定する、請求項２９に記載の方法。

【請求項32】

前記規格は、前記ノードの前記能力が、各ノードがサポートするSceneModesのリストを含むことを指定する、請求項２９に記載の方法。

【請求項33】

前記規格は、前記ノードの前記能力が、各ノードからの入力または各ノードへの出力としてサポートされるSceneData及び／またはSceneMarksのリストを含むことを指定する、請求項２９に記載の方法。

【請求項34】

SceneData及び／またはSceneMarksの前記リストは、エンコーディング及び／または暗号化をも指定する、請求項３３に記載の方法。

【請求項35】

少なくとも１つのアプリケーションが、前記ノードへの直接アクセスを有する、請求項２５に記載の方法。

【請求項36】

少なくとも１つのアプリケーションが、前記ノードへのアクセスを有する仲介サービスへのアクセスを有する、請求項２５に記載の方法。

【請求項37】

前記ノードへのアクセスが条件付きアクセスである、請求項２５に記載の方法。

【請求項38】

前記条件付きアクセスは、前記アプリケーション及び前記ノードとは別のサービスによって許可される、請求項３７に記載の方法。

【請求項39】

前記規格は、ユーザ定義のSceneModesをサポートする、請求項２５に記載の方法。

【請求項40】

前記データパイプラインは、インターネットを介して少なくとも１つのノードにアクセスする、請求項２５に記載の方法。

【請求項41】

少なくとも２つの前記ノードが同一のデバイスに実装される、請求項２５に記載の方法。

【発明の詳細な説明】

【技術分野】

【0001】

この開示は、一般に、画像を含むセンサデータの処理及び理解に関する。

【背景技術】

【0002】

（関連技術の説明）
今日、何百万ものカメラやその他のセンサデバイスが配備されている。一般に、カメラにより取り込まれたコンテンツと容易に有意な方法で相互作用できる機構はない。その結果、カメラからのデータのほとんどがリアルタイムで処理されず、せいぜい、イベントが発生したことがわかった後、取り込まれた画像が犯罪捜査の目的で使用される。その結果として、最終的に分析しても興味の無いビデオを保存するために大量のデータストレージが無駄になる。さらに、取り込まれたビデオの意味を理解するには、通常人間の視聴が求められる。画像における関連データを解釈または検出することに利用できる機械の支援は限られている。

【0003】

今日の別の問題は、情報の処理はアプリケーション依存性が高いことである。高度な運転支援システムや顔認識に基づくセキュリティのようなアプリケーションには、各カメラ本来の低レベルインターフェイスを使用してカメラから生画像を読み込み、目的の」アプリケーション用に特定の方法で生画像を処理するカスタムビルドのソフトウェアが求められる。アプリケーション開発者は、通常、生の画像を取得するためだけに、様々なタイプのカメラ毎に特定の低レベルインターフェイスを作成する必要があり、そして、通常、そのときに生のビデオフレームを処理して目的の情報を抽出するアプリケーション固有のソフトウェアも作成する必要がある。

【0004】

低レベルのカメラインターフェースに加え、アプリケーション開発者がより高度な画像理解のために人工知能や機械学習等の既存の処理や分析機能を使用したい場合、これらのシステムを理解し、それぞれのインターフェースを作成する必要がある。これらのシステムは、独自のＡＰＩを使用する場合があり得る。アプリケーション開発者は、特定の供給元のソリューションに縛られるようになり、その後、他のソリューションに切り替えることが困難になり得る。

【0005】

その結果、センサのネットワークを利用したアプリケーションの開発は遅く、かつ、制限される。例えば、環境に設置された監視カメラは、通常セキュリティ目的でのみ使用され、非常に限られた方法で使用される。これは、そのようなシステムによって取り込まれた画像フレームは意味のあるデータを抽出するのが非常に困難であることが一因である。同様に、車にカメラのネットワークが搭載されている自動車環境では、これらのカメラから取り込まれた画像データは、車の特徴に向けた非常に特殊な方法で処理される。例えば、前向きのカメラは、車線を支援することにのみ使用され得る。通常は、アプリケーションがデータまたはビデオを他の目的で利用する機能はない。また、通常は、特定のアプリケーションの必要に応じて、異なるアプリケーションが異なるセンサ及び異なる処理機能をデータパイプラインに組み合わせることを許容するような柔軟性もない。

【0006】

したがって、カメラによって取り込まれた画像及びビデオのよりレベルの高い理解を含む、センサデバイスによって取り込まれたデータへのアクセス及び処理において、より柔軟性及び容易さが必要である。また、様々なアプリケーションが既存の（及び共有された）センサ及び処理機能からカスタマイズされたデータパイプラインを組み立てできるようにするための柔軟性と容易さも必要である。

【発明の概要】

【0007】

本開示は、画像理解を必要とする１つまたは複数のアプリケーションのためにノードのネットワークをデータパイプラインに編成するためのアプローチを提供することによって、従来技術の制限を克服する。ノードは、アプリケーションのニーズに応じて、異なるデータパイプラインを形成するように構成される。ノードからデータパイプラインを構成するプロセスは、規格に従って、及び／または規格化されたAPIを介して実行される。

【0008】

ノードには様々な機能があり、センサ機能（例えば画像取り込み）及び画像理解機能（例えばオブジェクトの検出や認識等）へのアクセスが含まれる場合があり得る。ノードの機能の説明に基づいて、データパイプライン内のノードには、信頼性の高いノードが選択される。データパイプラインを形成するために選択されたノード間の相互接続も決定される。制御データは選択されたノードに送信され、その結果データパイプラインが形成される。制御データは、データパイプラインにおける各ノードの役割に従って、選択されたノードのセンサ及び/または画像理解機能を指定し、選択されたノード間の相互接続も指定する。

【0009】

パイプラインでは、いくつかのノードがセンサ機能へのアクセス権を有する。それらはセンサ自体である場合もあれば、センサへのアクセス権を有する場合もある。センサ機能は、データパイプラインのソースとして作用する。これは、画像取り込みが可能なノード（つまり、カメラ）を含む。データパイプラインは、ソースによって取り込まれたセンサデータから画像データと画像理解メタデータを生成する。画像データの例は、取り込まれた画像及び／または取り込まれた画像から導出された強調画像を含む。画像理解メタデータは、例えば、顔やオブジェクトの検出や認識の、画像データの画像理解を説明するメタデータである。画像理解メタデータは、また、画像理解に対応する画像データも参照する。例えば、認識された顔またはオブジェクトのビデオフレームへのサムネイルとポインタが含まれていてもよい。いくつかの場合において、制御データは、また、データパイプラインによって生成された画像データと画像理解メタデータを指定する。

【0010】

他の側面は、コンポーネント、デバイス、システム、改善、方法、プロセス、アプリケーション、コンピューター可読媒体、及び上記のいずれかに関連する他の技術を含む。

【図面の簡単な説明】

【0011】

特許または出願ファイルは、カラーで実行された少なくとも１つの図面を含む。この特許または特許出願の出版物とカラー図面のコピーは、要求と必要な料金の支払いに応じて、官庁から提供されるであろう。

【0012】

本開示の実施形態は、添付の図面の例と併せて解釈される場合、以下の詳細な説明及び添付の特許請求の範囲からより容易に明らかになるであろう他の利点及び特徴を有する。

【0013】

【図1A】図１Ａは、１つのアプリケーションのデータパイプラインを構成可能なノードのネットワークのブロック図である。

【図1B】図１Ｂは、ノードのブロック図である。

【図2】図２は、画像理解を伴うデータパイプラインを例示する図である。

【図3】図３は、画像理解を伴うデータパイプラインを例示する図である。

【図4】図４は、画像理解を伴うデータパイプラインを例示する図である。

【図5】図５は、データパイプラインにおける図１のノードの構成を示すブロック図である。

【図6A】図６Ａは、データパイプラインによって生成された出力データを示す図である。

【図6B】図６Ｂは、データパイプラインによって生成された出力データを示す図である。

【図7】図７は、仲介サービスの使用を示すブロック図である。

【図8】図８は、データパイプラインの規格ベースの構成の事象追跡を示す図である。

【図9】図９は、構成されたデータパイプラインのブロック図である。

【図10】図１０は、ノード内部にフィードバックを有するデータパイプラインのブロック図である。

【図11】図１１は、ノード間のフィードバックを有するデータパイプラインのブロック図である。

【発明を実施するための形態】

【0014】

図及び以下の説明は、説明のみを目的とした好ましい実施形態に関するものである。以下の議論から、本明細書に開示された構造及び方法の代替的な実施形態が、請求されているものの原理から逸脱することなく採用され得る実行可能な代替物として容易に認識される。

【0015】

図１Ａは、アプリケーション１７０のデータパイプラインに構成可能であるノード１１０のネットワークのブロック図である。アプリケーション１７０の例は、スマートフォンアプリケーション、クラウドアプリケーション、及びウェブページアプリケーションを含む。Nodes１１０は、アプリケーション１７０によって望まれる機能を達成するために、物理デバイス内または別個の物理デバイス内の他のノードに相互接続されてもよい。

【0016】

図１Ｂは、ノード１１０を例示するブロック図である。ノード１１０は、１つまたは複数のポートを有し、これらは、入力ポート１１２または出力ポート１１８であってもよい。それは、また、トランスデューサ機能１２０及び／または処理機能１３０を有する。図１Ｂは、ノードの一般的なブロック図である。実際のノードは、示されているすべての機能を備えるものでなくてもよい。

【0017】

トランスデューサ１２０は、大きくは、センサ１２２とアクチュエータに分けられる。センサ１２２は、外部の刺激をデータに変換する。例としては、画像及び他のスペクトルセンサ、マイクロフォン、温度または熱センサ、圧力センサ並びに煙及び他の化学センサを含んでもよい。アクチュエータ１２８は、データを外部刺激に変換する。例としては、スピーカ及び触覚フィードバックを含む。

【0018】

以下の例では、簡単のため、トランスデューサ機能はノード１１０内に示されている。ノード１１０が物理的なトランスデューサを含む場合、ノードは、トランスデューサ機能に直接アクセスするであろう。しかしながら、ノード１１０は、また、ノードの外側に配置されたトランスデューサ機能にアクセスしてもよい。例えば、レガシーカメラは、以下で説明する概念を実装する規格と互換性がない場合があり得る。その場合、ブリッジは、カメラ機能にアクセスするノード１１０のようにカメラ機能へのアクセスを提供してもよい。これは、処理機能１３０にも適用する。

【0019】

処理１３０は、大きくは画像処理部１３２と非画像処理１３８とに分けることができる。画像処理１３２は、画像現像１３４と画像理解１３６とにさらに分けることができる。画像現像１３４は、画像の品質を改善するために使用される低レベルの機能である。例としては、センサバイアスの補正、ピクセル欠陥の補正、ケラレ補正、ダークフレーム減算、ホワイトバランス、デモザイキング、ノイズリダクション、空間フィルタリング、色空間変換、トーンマッピング、ガンマ補正、コントラスト強調、エッジ強調、収差補正、フォーカス調整、露出調整、リサンプリング、解像度向上、ハイダイナミックレンジ調整、カラーフィルターアレイ補間を含む。

【0020】

画像理解１３６は、画像の内容を理解するために使用されるより高いレベルの機能である。一例は、特定のオブジェクト：顔、人間、動物または特定の種類の動物、車両、武器、人工構造物または特定の種類の構造物、または検出テキストまたはロゴまたはバーコードの存在または不在の検出である。より高いレベルの例は、特定のオブジェクト：群衆の中のテロリストの識別、名前による個人の識別、会社によるロゴの識別、パスポートまたは運転免許証に対する個人の識別または他の資格の識別（つまり、認識）である。画像理解１３６のさらに高いレベルの例は、特定のオブジェクトの検出または識別に基づくさらなる特徴付けである。例えば、顔を検出して分析し、表現された感情を理解してもよい。画像理解の他の例は、特定のアクションまたは活動、及び特定の場所または環境の検出と識別を含む。

【0021】

図１Ａに戻り、ノード１１０は、例えば、カメラ内に埋め込まれ、クラウド上で、またはモバイルアプリケーションとして実行される、多くの異なるプラットフォーム上に実装されてもよい。デバイスは、１つのノードまたは様々なノードを内包してもよい。デバイスは、これらのノードの構成に責を追う。デバイスは、物理デバイスであってもよく、サーバまたはクラウド上で仮想化されていてもよい。各ノードは一意に識別可能である。

【0022】

図１Ａにおいて、ノード１１０Ａ～Ｃの異なるグループは、対応する管理層１６０Ａ～Ｃによって管理されるが、これは必須ではない。この例では、管理層１６０Ａは、グループＡのノード１１０Ａ１～３を管理し、管理層１６０Ｂは、グループＢのノード１１０Ｂ１～２を管理し、管理層１６０Ｃは、グループＣのノード１１０Ｃ１～２を管理する。

【0023】

グループ化は、デバイスにより、またはその他で行うことができる。例えば、グループＡは、カメラ内のすべてのノード１１０：例えば、個々のセンサ、デバイス上の画像処理、及びアプリケーションプロセッサを含んでもよい。グループＢは、一緒にネットワーク接続されたデバイスのシステム全体に分散された異なる機能性等、ローカルにアクセス可能なノード１１０のプールを含んでもよい。より複雑な形式の画像理解は、機械学習、ディープラーニング、及び／または大量のコンピュータリソースを必要とする人工知能技術に基づくものであってもよい。例えば、グループＣは、クラウドサービスとして利用できる高レベルの機能を含んでもよい。

【0024】

アプリケーション１７０は、ノード１１０をデータパイプラインに編成する。データパイプラインには、データのソースとして画像取り込みを含む。また、取り込まれた画像データの画像理解を実行し、画像理解を説明するメタデータを生成する。明確性のために、他のタイプのメタデータと区別して、これを画像理解メタデータとする。例えば、画像理解メタデータは、人間が存在するかどうかを明確にする、または識別された人間の名前を提供する、または顔から識別された感情を記録してもよい。通常、データパイプラインは、画像データ（取り込まれた画像または取り込まれた画像から派生したバージョン）も生成し、画像理解メタデータは画像理解に対応する画像データも参照する。例えば、感情を識別する画像理解メタデータは、対応する顔の画像フレーム（群）を参照してもよい。

【0025】

アプリケーション１７０は、他のエンティティの支援により直接、または他のエンティティ（管理層等）を介して間接的にデータパイプラインをアセンブリすることができる。ノード１１０は、編成された後、異なるデータパイプラインに複数回再編成され得るため、本明細書で説明されるアプローチは、ノードの機能をよりよく利用するための柔軟性を提供する。いくつかの実施形態では、ノードをデータパイプラインに編成するためのプロセスは、規格化されたＡＰＩ（アプリケーションプログラミングインターフェース）等の規格に基づいている。次に、様々なアプリケーション１７０は、ノードにアクセスして異なるデータパイプラインを構築してもよく、ノードに十分な容量がある場合、それらのパイプラインを同時に動かしてもよい。

【0026】

図２～４は、画像理解を伴うデータパイプラインの例である。図２において、アプリケーションは群衆の中の人々の虹彩スキャンを実行する。データパイプラインは、広い視野を有する低解像度のカラー画像２１０の取り込みを開始する。パイプラインは、次の段階で高速デジタルズームを使用して注目領域を拡大する２１２。続いて、注目対象を識別するため、顔の検出及び認識（画像理解）２１４が行われる。次に、目の位置が決定される２１６。高倍率カメラは、光学ズームとデジタルトリミングを使用して、目の位置に向けられる。これらの画像は、生体認証による虹彩の識別に使用できる。図２の下部は、データパイプラインによって生成された画像データを示している。このパイプラインのメタデータは、例えば、サブジェクトの識別子を含んでもよい。

【0027】

図３の例において、アプリケーションが学校の監視を提供する。この例では、データパイプラインは、教室の一般的なビデオ監視を提供するステージを開始する。この段階の中で、一般的な広範囲の監視用に調整されている。この段階の１２：００に、泣いている人を識別する音声認識のイベントがある。これにより、画像フレームは１２：００に自動的にマークされる。

【0028】

図３の下の４つのフレームに示すように、このイベントは、パイプラインステージが、より多くのデータを取り込む及び／または、より多くの処理を提供することを引き起こす。ここでは、通常のビデオが暗すぎるため、露出の高いフレームも取り込まれる。データパイプラインは、赤外線フレームも取り込み、クローズアップフレームにズームインする。これらの異なる画像から、データパイプラインの追加の段階で、学生をジョンとして識別し、彼が苦しんでいる感情的な状態にあることを識別する。この画像の理解は、図３に示すように、メタデータＦａｃｅ＝Ｊｏｈｎ及びＥｍｏｔｉｏｎ＝Ｄｉｓｔｒｅｓｓとしてデータパイプラインによって出力される。このメタデータは、特定の１つのフレームではなく、４つの画像フレームのセットのものである。このメタデータは、対応する画像フレームをも参照する。

【0029】

図４は、高速フレームレートにより、データパイプラインによる分析のために様々なフレームの組み合わせを許容する例を示している。この例において、センサデバイスの未加工のフレームレートは毎秒１２０フレームである。通常の操作の下、４フレームごとにフレームが取り込まれ、画像データとして保存される。ただし、データパイプラインでは、特定のトリガーが発生すると、異なる条件下で追加のフレームが取り込まれる。この例では、カメラは３色カメラであるが、フィルターをかけて赤外線画像を効果的に取り込むことができる。動きが検出されると、追加の画像；露出を増加させた画像、赤外線画像、及び深度測定を伴うフレーム（この例では赤外線構造化光に基づく）が取り込まれる。データパイプラインは、これらの画像を後の段階で処理して、顔やオブジェクトを検出し、他のタイプの画像理解を実行する。

【0030】

図５は、図１のノードのデータパイプラインへの構成を示すブロック図である。この例は、ノードとその機能のリストを維持し、アプリケーションにノードへのアクセスを許可するアカウントサービス５８０を含む。アカウントサービス５８０は、エンドユーザがカメラ及び他のセンサデバイスを管理する方法、ならびにより高いレベルの処理を提供することができる。

【0031】

１つのアプローチにおいて、ユーザは、自分のユーザアカウントにアクセスできるデバイス／ノードを割り当て、次に、自分が選択したアプリケーション１７０を自分のアカウントにリンクする。いったんアプリケーション１７０がユーザのアカウントへのアクセスを許可されると、アプリケーション１７０は、ユーザのアカウント及びそれらの機能に関連付けられたデバイスのリストを要求してもよい５１０。アカウントサービス５８０は、この情報を返し５１２、ノードへのアクセスを得るために必要なパスワード、キーまたは他の資格情報をも返してもよい。通常、これはアクセストークンになる。アカウントサービス５８０が使用されない場合、アプリケーション１７０は、例えば、規格で指定された自動発見プロセスを通じて、利用可能なノード及びそれらの機能を直接指定してもよい。または、この情報を別々のファイルに提供してもよい。

【0032】

ノードの機能の記述に基づいて、アプリケーション１７０はデータパイプラインを決定する５２０。それはデータパイプラインに含めるノードを選択し、選択したノード間の相互接続を決定してデータパイプラインを形成する。データパイプラインは、パイプラインの残りのデータのソースとして機能するセンサノードを含み、画像理解機能を備えたノードをも含む。データパイプラインの決定は、ノードの機能の説明以外の追加情報に基づいてもよい。例えば、センサの地理的範囲または相互の近接性を使用して、パイプラインに含めるセンサとそれらを相互接続する方法を決定してもよい。

【0033】

アプリケーション１７０は、データパイプラインを形成するために選択されたノード１１０に制御データを送信する５３０。図５において、制御データは、管理層１６０に（すなわち、間接的にノードに）送信され５３０、要求された構成を実行する。制御データは、各ノードの機能を指定し、ノード間の相互接続も指定する。また、それはデータパイプラインによって生成される画像データとメタデータを指定してもよい。１つのアプローチにおいて、データパイプラインは、各ノード（シンクノード）がデータを提供するすぐ上流のノード（ソースノード）との制御セッションを確立することによって形成されるが、他の制御アプローチも使用できる。図５において、コントロールプレーンは破線で示され、データパイプラインは太い実線で示されている。

【0034】

図５におけるデータパイプラインの例は、線形ではない。それは分岐を有している。Node１１０Ａ１は、データパイプライン全体のソースである。順方向データパスは、最初にノード１１０Ａ１からノード１１０Ａ２へ向かう。次に、ノード１１０Ａ３及び１１０Ｂ２に分岐する。１１０Ａ３分岐は、１１０Ｂ１、１１０Ｃ１、１１０Ｃ２に続き、次に５４０からアプリケーション１７０に続く。他の分岐では、ノード１１０Ｂ２の出力は、アプリケーション１７０に提供される５４０。また、１１０Ｃ２に与え、１１０Ａ３分岐と結合する。したがって、アプリケーション１７０への２つのデータフィード５４０が存在する：１つはノード１１０Ｂ２からのものであり、もう１つはノード１１０Ｃ２からのものである。

【0035】

ノード１１０Ａ２からのデータが常に両方の分岐に流れる上記のように、データパイプラインの分岐は静的であることができる。それはまた、画像理解の条件によって引き起こされることができる。例えば、ノード１１０Ａ２がいくつかの画像理解を実行する場合、データパイプラインは、画像理解の結果に応じて、ノード１１０Ａ３またはノード１１０Ｂ２のいずれかを継続してもよい。例えば、武器が検出されない場合は特定の処理が行われるが、致命的な武器が検出されると他の処理が行われる。トリガーは、制御データで指定してもよい。

【0036】

図５におけるデータパイプラインの例は、また、ノード１１０Ａ２からノード１１０Ａ１へのフィードバックループを含み、これは、同じグループ内の（例えば、同じデバイス上の）２つのノード間のフィードバックである。この特定のループは、ソースノード１１０Ａ１にフィードバックを提供する。例えば、画像の理解度に応じて、画像取り込みの設定を変更してもよい。フィードバックループは、他のノード間、例えば異なるデバイス上のノード間でも確立し得る。

【0037】

図５は、単に一例である。他の例と形態は明らかになるであろう。例えば、データパイプラインには、異なるタイプのセンサデータを取り込む複数のソースが含まれる場合があり、データパイプラインにはセンサの融合に基づく画像理解機能も含まれる。さらに、同じまたは異なるユーザからの様々なアプリケーション１７０は、同じノードにアクセスして、それら自身のデータパイプラインを構築することができる。

【0038】

図６Ａから図６Ｂは、データパイプラインによって生成されたデータの例を提供する。これらの例において、画像データ及びその他の生または拡張センサデータは「シーンデータ」と呼ばれる。データは時間ごとに「シーンショット」に編成されている。スナップショットが一連のビデオ画像の１フレームである場合、シーンショットは類似の概念であるが、単一フレームまたは画像のみに限定されない。シーンショットは、通常、図６Ａにおいて画像理解メタデータと他のタイプのメタデータに分けられるメタデータも含む。

【0039】

図６Ａは、シーンショットのブロック図である。このシーンショットは、ヘッダーを含む。これは、次の一般的なメタデータを含む：センサデバイスＩＤ、シーンモード（以下で説明する制御データの一種）、ＩＤ要求しているアプリケーション、タイムスタンプ、ＧＰＳロケーションスタンプ。

【0040】

シーンショットのデータ部分は、２台のカメラからのカラービデオ、異なる解像度とフレームレートのＩＲビデオ、深度測定、及びオーディオといったシーンデータをも含む。ビデオコンテキスト内でのシーンデータの例には、モノクロ、カラー、赤外線、及び異なる解像度とフレームレートで取り込まれた画像が含まれる。画像以外のタイプのシーンデータは、オーディオ、温度、周囲の照明または光度、及び周囲環境に関するその他のタイプのデータを含む。シーンデータは、エンコード及び／または暗号化されてもよい。それらはまた、センサバイアスの補正、ダークフレーム減算、ホワイトバランス、デモザイキング、ノイズリダクション、空間フィルタリング、コントラスト強調、エッジ強調等の画像現像機能によって強化されてもよい。

【0041】

シーンショットは、また、画像理解するメタデータ：例えば、動き検出及びオブジェクト／人間／顔検出を含む。これらは、以下でより詳細に説明するように、シーンマークの形式をとってもよい。

【0042】

このデータは、また、時間的な側面を有する。従来のビデオでは、ビデオのフレームレートに応じて一定の間隔で新しい画像が取り込まれる。ビデオシーケンスの各画像はフレームと呼ばれる。同様に、シーンには通常、特定の期間があり（一部のシーンは無期限に続くことができるが）、シーンの異なる「サンプル」が時間の経過とともに取込み／生成される。混乱を避けるために、シーンショットには１つまたは複数のビデオフレームが含まれることから、フレームではなくシーンショットと呼ぶ。シーンショットは、シーンとスナップショットを結合した用語である。

【0043】

従来のビデオと比較して、シーンショットは、より大きなばらつきを有することができる。シーンショットは、一定の時間間隔で作成されても、されなくてもよい。一定の時間間隔で作成されたとしても、シーンが進むにつれて時間間隔が変わり得る。例えば、シーン中に興味深いものが検出された場合、シーンショットの周期を増やしてもよい。同じアプリケーションの一連のシーンショットには、同じタイプのデータ、またはすべてのシーンショットの同じセンサチャネルから派生したデータを含んでも、含まなくてもよい。例えば、シーンの特定の部分の高解像度ズーム画像が望ましくてもよく、またはシーンが進行するにつれて追加のセンサチャネルが追加または削除されてもよい。最後の例として、シーンショットまたはシーンショット内のコンポーネントは、異なるアプリケーション間で、またはより広く共有されてもよい。

【0044】

実際には、実際のシーンデータは非常に大きくなり得る。その結果、このデータはミドルウェアまたはクラウドに保存されてもよく、シーンショットの実際のデータパケットは、実際のデータ自体ではなく、シーンデータへのポインタを含んでもよい。別の例として、メタデータは動的であってもよい（すなわち、各シーンショットの変化が含まれる）。ただし、メタデータが頻繁に変更されない場合は、個々のシーンショットとは別に、または別のチャネルとして送信されてもよい。

【0045】

図６Ｂは、シーンショットの「シーン」への編成を示すタイムラインである。この図において、時間は左から右に進む。オリジナルシーン１は、学校の時間外監視を実行するアプリケーションのためのものである。シーンショット６５２Ａは、このシーン１用に取込み／生成される。シーンショット６５２Ａは、学校への主要な入口点の粗い解像度、比較的低いフレームレートのビデオを含んでもよい。シーンショット６５２Ａは、また、潜在的に疑わしい活動を示し得る動き検出または他の処理されたデータを含んでもよい。図６Ｂにおいて、シーンショットは括弧内の番号（Ｎ）で示されており、６５２Ａ（０１）は１つのシーンショットであり、６５２Ａ（０２）は次のシーンショットである等のようになっている。

【0046】

シーンマーク２でマークされたシーンショット６５２Ａ（０１）で疑わしいアクティビティが検出され、２番目のシーン２が生成された可能性がある。シーンマーク２は、動きが検出されたことを示す画像理解メタデータを含む。このシーン２は、シーン１のサブシーンである。「サブ」は生成関係を指し、データまたは時間的期間の観点から、シーン２がシーン１のサブセットであることを意味しないことに注意されたい。実際、このシーン２は、追加のデータ６５２Ｂを要求する。おそらく、この追加データは顔認識である。サイトで検出された各々は許可されたものとして認識されず、これによりシーンマーク３でマークされたシーン３（つまりサブサブシーン３）が生成される。シーン３はデータ６５２Ｂを使用しないが、例えば、エントリポイントだけでなく、サイト全体に配置されたカメラからの高解像度画像の追加データ６５２Ｃを使用する。画像の取り込み頻度も増加する。シーンマーク３は、状況を調査するために当局へ通知するトリガーとなる。

【0047】

その間に、別の無関係なアプリケーションがシーン４を作成する。おそらく、このアプリケーションは、学校のインフラストラクチャをリモートで監視して障害を早期に検出したり、予防保守を行ったりするために使用される。それはまた、同じデータ６５２Ａのいくつかを利用するが、異なる目的のために異なるアプリケーションによって使用される。

【0048】

図７は、データパイプラインを構成するための中間サービスの使用を示すブロック図である。図７は、仲介サービス７９０が導入されていることを除いて、図５と同様である。アプリケーション１７０は、アカウントサービス５８０または管理層１６０と直接相互作用しない。むしろ、アプリケーション１７０は、アカウントサービス５８０及び管理層１６０と相互作用する中間体７９０と相互作用する。例えば、データサービス７９０は、アプリケーションにサービスを提供するために、アプリケーション１７０にＡＰＩを提供してもよい。

【0049】

図７において、システムは次のように動作する。データサービス７９０は、ノード及びそれらの機能のリストを維持する。それは、デバイス、ノード、及びそれらの機能のリストを定期的に要求してもよい。アカウントサービス５８０は、この情報を返し７１２、また、ノードへのアクセスを得るために必要なパスワード、キー、または他の資格情報を返してもよい。次に、アプリケーション１７０は、要求し７１４、データサービス７９０からこの情報を受信する７１６。

【0050】

ノードの機能の記述に基づいて、アプリケーション１７０は、データパイプラインを決定する７２０。データパイプラインに含めるノードを選択し、選択されたノード間の相互接続を決定してデータパイプラインを形成する。次に、アプリケーション１７０は、制御データをデータサービス７９０に送信し７３０、データサービス７９０は、対応する制御データを管理層１６０に（すなわち、間接的にノードに）送信し７３２、次に、管理層１６０は、要求された構成を実行する。制御データは、各ノードの機能を指定し、ノード間の相互接続も指定する。また、データパイプラインによって生成される画像データとメタデータを指定してもよい。

【0051】

結果として生じるデータパイプラインは、データ７４０をデータサービス７９０に返し、データサービス７９０は、それを要求しているアプリケーション１７０に提供する７４２。図５に関して説明したように、異なるデータパイプラインを構成してもよい。

【0052】

上記の例において、仲介サービス７９０は、アプリケーション１７０とシステムの残りの部分との間にあるパススルーエンティティとして説明された。しかしながら、データサービス７９０は、また、追加の機能を提供することができる。例えば、データサービス７９０はそれ自体がトランスデューサまたは処理機能を有してもよい。それはまた、複数のノード１１０からの、または複数のアプリケーション１７０のためのデータの相互分析を実行してもよい。データサービス７９０は、また、様々のアプリケーション１７０からのデータに対する要求を集約、優先順位付け、または多重化してもよい。デバイスは、一度に単一のアプリケーション１７０と相互作用することに制限され得る。しかしながら、その場合、複数のアプリケーション１７０は、データサービス７９０と相互作用することができ、データサービス７９０は、次に、デバイスと相互作用する。

【0053】

データサービス７９０は、また、追加のサービスを提供してもよく、例えば、近接マップ等のデバイス及びノードに関する追加情報、またはデバイスが互いにどのように相互作用するかに関する追加情報を提供する。データサービス７９０は、また、ノード１１０を個々のデバイスから引き離して抽象化する。ノード１１０と相互作用するアプリケーション１７０は、各ノードを構成するために各デバイスとの制御セッションをセットアップする必要はない。むしろ、アプリケーション１７０は、ノード１１０を構成するようにデータサービス７９０に要求し、データサービス７９０は、各ノード１１０との制御セッションの作成を管理する。仲介者はデータサービスである必要はない。例えば、ミドルウェア層である可能性がある。

【0054】

いくつかの実装において、データパイプラインを構成するプロセスは、規格で定義されているか、規格化されたＡＰＩを使用して定義されている。図８～１１は、規格の一例を提供する。この例では、Sink,Source,Capabilities,SceneData,SceneMark,SceneMode等の大文字の用語が規格で定義されている。図８は、データパイプラインの規格ベースの構成の事象追跡である。この例及び図１～７の比較において、Sink８７０は、要求しているアプリケーション１７０に対応するNodeであり、Source８１０は、ノード１１０に対応するNodesである。Capabilitiesは、規格の構文を使用して、Nodesの機能を記述する。SceneModesは、Nodesの構成に使用される図５の制御データである。SceneDataとSceneMarksは、データパイプラインによって返されるデータである。SceneDataは、画像データとその他のセンサデータを含む。SceneMarksは,関連するSceneDataへの参照とともに,画像を理解するメタデータを含む。このデータはシーンに編成され、シーンのサンプルはScene Shotsと呼ばれる。

【0055】

より詳細には、この例は規格で定義されている次のデータオブジェクトを使用する。
・NodesはData Pipelineの構成要素である。各Nodeは一意のＩＤを有する。
・Capabilitiesは、AIアルゴリズム、サポートされているSceneModes、ハードウェアセンサ機能等、Source Nodesが提供できる機能である。
・SceneModeはNodeの構成である。必要に応じて、SceneModeは、センサのキャプチャプロセス、データの処理に使用されるコンピュータービジョンまたは人工知能アルゴリズム、データ出力形式等を定義する。
・SceneMarkは、イベントを説明するNodeによって生成される構造化された出力である。これは、Nodeの識別子、SceneMarkがトリガーされたときのタイムスタンプ、及びイベントをトリガーしたNode処理の結果を含む。また、イベントに関連付けられているSceneDataへの参照も含む。
・SceneDataは、SceneMarkをトリガーしたイベントに関連付けられた実際のデータである。静止画像、ビデオクリップ、温度、またはその他のセンサのデータであってもよい。データは、要求されたSceneModeに応じて、イベントの数秒前に開始し、イベントの数秒後に実行できる。

【0056】

Capabilitiesオブジェクトは、Nodesの機能を確立するために使用され、SceneModeオブジェクトは各Nodeの構成とNodes間の相互接続を定義するために使用される。SceneMarkオブジェクトとSceneDataオブジェクトは、Data Pipelineによって処理されるデータの表現である。

【0057】

データパイプラインは、アプリケーションによって最終的に消費されるSceneMarkオブジェクトとSceneDataオブジェクトを生成する。SceneMarkオブジェクトは、データパイプライン内の様々なNodesによって操作されてもよい。これは、通常、Nodesが前のNodesのSceneMarkまたはSceneDataのいずれかを処理した結果であるSceneMarkオブジェクトにフィールドを追加する必要がある。Nodesは、以前のSceneMarksとSceneDataを処理した結果であるSceneDataをもさらに生成してもよい。例えば、顔を検出できるNodeは、前のNodeによって生成されたSceneDataからビデオフレームを処理し、検出された顔に対応するフレームから長方形を抽出してもよい。

【0058】

Data Pipelineの構成は、Capabilitiesオブジェクトを利用してNodesの機能を決定する。Capabilitiesオブジェクトは、Nodeにトランスデューサが含まれているかどうか、どのSceneModesがサポートされているかを含むNodeの処理能力、Node内のプロセスで実行可能な分析レベル、Nodeからのデータの入力または出力のためのポートオプションについて記述する。この情報を使用して、Nodeにどのようなデータが流入、流出するか、またNodeが新しいセンサデータを取得するか、他のNodesから受信したデータを処理するか等、NodeのSceneModeが定義される。

【0059】

各NodeのSceneModeがいったん各Nodeに提供されると、Data Pipelineが構築され、各Nodeに提供されたSceneModeに従ってSceneModeとSceneDataのシーケンスの生成が開始される。このサンプル規格のこれらのデータオブジェクトのより詳細な定義は、以下のセクションＡに記載されている。

【0060】

図８を参照すると、Data Pipelineは次のように設定されている。Sink８７０は、Source８１０との制御セッションをセットアップする８０５。１つのアプローチにおいて、制御セッションの構成は、Sink８７０にアクセストークンまたはクレデンシャルを提供するアカウントサービスを介して行われる。Sink８７０は、アクセストークンを使用してSource８１０と通信する。Sinkは、各SourceにGet Capabilities要求を行うことにより、各Sourceの能力を決定する。Sourceは、そのCapabilitiesを返す８１６。Sinkは、パイプライン内の各Nodeのトランスデューサ及び処理機能／構成を決定し、Nodes間の相互接続を決定することにより、プロセスのData Pipelineを定義する８２０。

【0061】

Sinkは、対応するSet SceneModeコマンドを発行する８３２。SceneModeデータオブジェクトは、Nodeのセンサ及び／または画像理解機能を指定する。この構成は、また、各Nodeをトリガーして、Data Pipeline内の他のNodesとの相互接続を作成する。Sinkは、Start Sceneコマンドを使用してシーンモードを開始するために、各Nodeを個別にトリガーする８３４。次に、Data Pipelineは、規格で定義されているSceneMarks及びSceneData形式を使用してデータを生成する。Sinkは、Nodesによって生成されたSceneMarksとSceneDataを消費する８４０。Data Pipelineは、SinkがStop Sceneコマンドを発行するまで動作する。

【0062】

より詳細には、１つのアプローチにおいて、NodesはNodeＩＤによって一意に識別可能である。Node IDは、NodeをホストしているデバイスのデバイスIDに基づき、複数のNodeをホストしているデバイスの場合、NodeにはさらにNode番号が付与され、デバイスIDと組み合わされることで、そのNodeに固有のNode IDが定義される。Nodeに関連する入出力ポートについても同様に、各ポートはNodeの範囲内で固有のポート番号を持つ。デバイスID、Node番号、ポート番号の組み合わせにより、ユニークなポートIDが定義される。

【0063】

Nodesは、通常、Control InterfaceとData Interfaceの２つのインターフェースを有する。Control Interfaceは、Nodesを利用するData Pipelineを構成するために使用され、NodesのCapabilitiesを決定し、Data Pipeline内のNodesにSceneModeを配布する等の機能を含む。ある実装において、Source Nodesは、一度に１つの制御セッションしか受け付けないように制限され、どのNodeも他の１つのNodeからしか制御されないことを意味する。しかし、Sink Nodesは、様々な制御セッションを並行して確立し、様々なSource Nodesを制御してもよい。いくつかのNodesの中は、異なるNodesに対してSourceとSinkの両方の機能を持ってもよい。

【0064】

Nodeは、Data Interfaceを用いてSceneMarksやSceneDataを処理し、配信する。これらは、SceneModeで定義されたNodeの順序とその構成に従って処理される。NodeのData Interfaceは、Node同士のデータ交換を可能にする。

【0065】

図８に戻ると、Sink Nodeは、Node IDを使用して、Set SceneModeコマンド８３２をSource Nodeに送信する。Set SceneModeは以下を決定する：
・どのデータが優先されるか、例えば、SceneMode = Faceでは顔が優先される。
・SceneMarkが生成される結果となるトリガー。
・トリガーが発生したときに生成されるSceneDataのタイプと量、例えば、ＪＰＥＧまたはトリガーの３秒前と２０秒後のビデオ等。
・SceneMarkの情報を抽出するためにNodeがSceneDataに対して実行するなんらかの処理。
この規格例でサポートされているコマンドの追加の詳細については、以下のセクションＢにおいて提供される。

【0066】

Data Pipelineは、Nodesの入力及び出力をリンクすることによって構築される。SceneModeオブジェクトの仕様には、次の項目が含まれる：
・入力（群）：各入力は、入力を介して受信されると予想されるデータのタイプ、その暗号化ステータス、権限オブジェクトへの参照、及び入力へのソースデータのソースＵＲＩの構成を有する。各入力は、一意のポートＩＤをも有する。
・出力（群）：各出力は、入力ポートと同様の構成を有する。各出力は、一意のポートＩＤをも有する。
・トランスデューサ（群）：トランスデューサは、センサまたはアクチュエータのいずれかである。トランスデューサの出力は、Node内の処理機能だけでなく、１つ以上の出力、入力（アクチュエータ用）にルーティングできる。
・プロセス（群）：プロセスは、Nodesによって生成されたデータ、または他のNodesからルーティングされたデータの分析を実行する。データは、他のNodeからのSceneMarksまたはSceneDataの形式とすることができる。プロセスは分析を実行し、定義されたしきい値に達すると、プロセスはトリガー条件を生成し、SceneMode構成に従ってSceneMarkとSceneDataが生成される。

【0067】

図９は、構成されたデータパイプラインのブロック図である。この例では、Node９１０Ａには、イメージセンサ（トランスデューサ機能）とモーション検出（プロセス機能）が含まれている。出力SceneDataは、取り込まれたビデオである。これは、Nodeの出力ポートの構成に従ってエンコードされ、Node９１０Ｂの入力ポートにリンクされる。SceneDataは、特定のターゲットビットレートとエンコードメカニズムを使用してビデオストリームとしてエンコードされてもよい。Node９１０Ａは、また、動きが検出された場合に、動きが検出されたことを示すメタデータを伴うSceneMarkを生成する。Node９１０Ｂ内のプロセスは「Face」SceneModeに設定されており、動きが検出されたときにNodeが「Detect」及び「Recognize」の顔の分析レベルを実行することも指定する。このProcessは、Node９１０Ａから受信したSceneMarkに結果のメタデータを付加し、更新されたSceneMarkを要求元のアプリケーション１７０に転送する。例えば、更新されたSceneMarkには、検出された顔の（ｘ，ｙ）座標と、その顔に基づく個人のアイデンティティを示すメタデータが含まれてもよい。Input Portで受信したSceneDataは、顔情報を抽出するためにさらに処理される。例えば、デジタルズームやクロッピング等が適用されてもよい。また、このSceneDataは、アプリケーション１７０に転送されてもよい。

【0068】

Data Pipelineは、Nodesをリンクすることによって構築される。NodeのSceneModeは、この構成を定義する。パイプラインを構築するアプリケーションは、Nodeがプロセスを実行し、そのプロセスから要求された出力がデータパイプラインの後続のNodesの入力に転送されるように注意しながら、各NodeにSceneModeを設定する。連動は、生成されたPortまたはSceneMarksのいずれかの宛先を定義し、PortまたはSceneMarksのソースを定義することによって行われる。ソースとデスティネーションを同時に定義することは、ブローカーが２つのプロセスの間を仲介するMQTT等のプロトコルの使い方と互換性がある。Source Nodeはブローカー上のトピックにメッセージを投稿し、Sink Nodeはブローカーからのメッセージを受信する。このタイプの接続では、Source Nodeはメッセージの送信先を持ち、Sink Nodeは受信メッセージの送信元を持つ。これは使用しているプロトコルによって異なってもよい。

【0069】

１つのデバイスに１つのNodesがある場合と、様々なNodesがある場合がある。デバイスに様々なNodesがある場合、デバイス内のNodes間でSceneDataとSceneMarksを転送する方法は、デバイス独自のものであってもよい。１つのアプローチにおいて、デバイス内のNodesのSceneModeの構成により、デバイス内のデータの送信元と宛先が定義される。ポート構成は、データがデバイス間で転送されるときにデータのエンコードを構成するために使用される。

【0070】

Data Pipeline内のいくつかのプロセスは、データパイプライン内の以前のプロセスに結果をフィードバックしてもよい。例えば、顔検出を行うプロセスは，顔が検出された領域をセンサにフィードバックすることができる。センサは、この情報を使用して、検出された顔が最高の鮮明さで取り込まれるように、取込みの設定を調整してもよい（フォーカス、露出、ズーム等）。

【0071】

図１０は、Nodeの内部にフィードバックを持つData Pipelineのブロック図である。この例では、Node１０１０Ａは動きを検出する機能を持つ。このNodeのSceneModeは、動きが検出された場合に、取込みシーケンスがセンサにフィードバックされるように設定されている。取込みシーケンスは、センサが取り込むフレームのシーケンスの設定を定義する。これらの設定は、動きが検出された領域や、フォーカス、露出、ズームの設定を含んでもよい。取込みシーケンスは、１つまたは複数のフレームで構成されてもよい。取込みシーケンスは、Nodeの内部で転送されるが、NodeのSceneMode構成の一部として定義される。

【0072】

図１１は、Nodes間のフィードバックを備えたData Pipelineのブロック図である。この例では、Node１１１０Ｂは、そのSceneModeをFaceに設定し、センサのCapture SequenceをNode１１１０Ａにフィードバックするように構成される。この例は、プロセスが顔を検出するように設定され、顔を検出すると、その顔に対応する関心領域がセンサに送信され、センサが顔を検出した領域の取り込みを最適化できる。

【0073】

詳細な説明には多くの具体的な内容が含まれているが、これらは本発明の範囲を限定するものと解釈されるべきではなく、単に異なる例を示すものと解釈されるべきである。本開示の範囲には、上記で詳細に説明されていない他の実施形態が含まれることを理解すべきである。当業者に明らかになるであろう様々な他の修正、変更、及び変形が、添付の請求項で定義された精神及び範囲から逸脱することなく、本明細書で開示された方法及び装置の配置、動作、及び詳細においてなされ得る。したがって、本発明の範囲は、添付の特許請求の範囲及びその法的等価物によって決定されるべきである。

【0074】

代替の実施形態は、コンピュータハードウェア、ファームウェア、ソフトウェア、及び／またはそれらの組み合わせで実装される。実施形態は、プログラマブルプロセッサによる実行のために機械読み取り可能な記憶装置に明示的に具現化されたコンピュータプログラム製品に実装することができ、方法ステップは、入力データを操作して出力を生成することによって機能を実行する命令のプログラムを実行するプログラマブルプロセッサによって実行することができる。実施形態は、データ記憶システム、少なくとも１つの入力デバイス、及び少なくとも１つの出力デバイスからデータ及び命令を受信し、データ及び命令を送信するように結合された少なくとも１つのプログラマブルプロセッサを含むプログラマブルシステム上で実行可能な１つまたは複数のコンピュータプログラムで有利に実施することができる。各コンピュータプログラムは、高レベルの手続き型またはオブジェクト指向のプログラミング言語、または必要に応じてアセンブリ言語または機械語で実装することができ、いずれの場合も、言語はコンパイル言語またはインタープリター言語とすることができる。適切なプロセッサには、例として、汎用及び特殊目的のマイクロプロセッサである。一般に、プロセッサは、読み取り専用メモリ及び／またはランダムアクセスメモリから命令及びデータを受け取る。コンピューターには、データファイルを保存するための１つまたは複数の大容量記憶装置が含まれる。このような装置には、内蔵ハードディスクやリムーバブルディスク等の磁気ディスク、光磁気ディスク、光ディスク等がある。コンピュータプログラムの命令やデータを具体化するのに適した記憶装置には、あらゆる形態の不揮発性メモリが含まれる。例えば、ＥＰＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ等の半導体メモリデバイス、内蔵ハードディスクやリムーバブルディスク等の磁気ディスク、光磁気ディスク、ＣＤ－ＲＯＭディスク等が挙げられである。また、ＡＳＩＣ（特定用途向け集積回路）等のハードウェアで補完したり、それらを組み込んだりすることも可能である。

【0075】

セクションA：データオブジェクトの説明
本セクションAでは、以下のデータオブジェクトについて説明する。
・Capabilities
・SceneMode
・SceneMark
・SceneData

【0076】

Capabilitiesオブジェクト
Capabilitiesオブジェクトは、Nodeが提供可能なTransducer、ポートのプロセスを定義する。Capabilitiesデータ構造は、Nodeがサポートしている利用可能な処理、画像、音声、データのソース、データのアウトプットのキャプチャ（入力）とアウトプットを記述している。これらには以下のようなものがある。

【0077】

１．Transducer: Transducerは、データを物理的な外乱（スピーカ等）に変換できるセンサまたはアクチュエータのいずれかである。以下は、トランスデューサの例である。
・イメージセンサ（画像、深度、または温度カメラ）は通常、フレームを表す２次元配列を出力する。
・データセンサ（湿度センサ、温度センサ等）は通常、テキストまたはデータ構造を出力する。
・オーディオマイクは、通常、オーディオサンプルの連続シーケンスを生成する。
・スピーカは、オーディオサンプルのシーケンスを入力として受け取り、オーディオを出力する。

【0078】

２．サポートされるSceneModes：これらは、画像を分析するために定義されたモードである。 以下のSceneModeオブジェクトも参照されたい。

【0079】

３．オーディオ処理：これはNodeによって定義されてもよい。これは、テキストを話す機能を含む。

【0080】

４．Custom Analysis：これにより、ユーザはカスタム分析を許可される。一例として、それは、オーディオ、画像、またはビデオ入力を処理し、その意味がアルゴリズムによって定義されるスコアのベクトルを生成することができるアルゴリズムであってもよい。

【0081】

５．Input：これは、SceneDataまたはSceneMarksであり、処理済みまたは未処理の形式であってもよい。以下は、プロセスのソースであり得る。
・デバイスの内部または外部のセンサの出力。
・別のデバイスのNodeの出力。
・同じデバイス内の異なるNodeの出力。

【0082】

６．Output：出力はSceneDataまたはSceneMarksでもよく、また、処理済みまたは未処理のフォーム。

【0083】

SceneModeオブジェクト
SceneModeは、生成されるデータを決定する。それは、フレームの取り込みと、取り込まれたフレームの処理によって優先されるデータのタイプを定義する。それは、また、生成されるSceneMarksと、SceneMarksを生成するためのトリガー条件を定義する。

【0084】

例えば、Face SceneModeは、一連のフレーム内の顔の取り込みを優先する。顔が検出されると、カメラシステムは、顔が正しく焦点を合わせられ、照らされ、必要に応じて十分にズームされた顔が存在するフレームを取込み、成功の可能性を高めて顔認識を実行できるようにする。複数の顔が検出された場合、カメラは、できるだけ多くの顔を正しく取り込むことがある。カメラは、表示されている顔に最適化された様々な設定で複数のフレームを使用する場合がある。例えば、カメラに近い顔の場合、カメラは近くに焦点が合っている。遠くの顔には、デジタルズーム及びより長いフォーカスが使用される。

【0085】

次のSceneModesを定義してもよい。
・顔
・人間
・動物
・テキスト／ロゴ／バーコード
・車両
・オブジェクトラベル。 これはカメラで撮影した画像に一般的なラベリングを施したものである。
・顧客 これはユーザ定義である。
SceneModeは、他のSceneModeに関連付けられたSceneMarkにデータフィールドを生成してもよい。SceneModeの目的は、モードに合わせて画像の取り込みをガイドし、SceneModeで定義されたデータを生成するためのワークフローを定義することである。アプリケーションレベルでは、アプリケーションは、デバイスの特定の構成や、デバイスがどのように画像を取り込んでいるかについての洞察を持っている必要はない。アプリケーションは、SceneModeを使用して、アプリケーションが関心を持ち、アプリケーションにとって最も優先度の高いデータのタイプを示す。

【0086】

トリガー条件（TriggerCondition）

【0087】

SceneModeは、通常、１つ以上の「Trigger」を有する。Triggerは、SceneMarkが生成され、SceneMode用に定義されたSceneDataが取り込まれて処理される条件である。アプリケーションは、SceneMarkがいつ生成されるかを決定できる。

【0088】

１つのアプローチにおいて、トリガーは画像理解のマルチレベルモデルに基づいている。分析レベルは次のとおりである。
１．MotionDetected：プロセスは、視野内の動きを検出することができる。
２．ItemDetected or ItemDisappeared：プロセスは、SceneModeに関連付けられたアイテムを検出したり(Item Detected)、アイテムがなくなったことを検出したり(Item Disappeared)することができる。例えば、SceneMode=Faceの場合、Item Detectedは、Faceが検出されたことを意味する。SceneMode=Animalの場合、Item Disappearedは、以前に検出された動物が存在しなくなったことを意味する。
３．ItemRecognized：プロセスは、検出されたアイテムを識別することができる。例えば、「SceneMode=Label」の場合、「Recognized」は検出されたアイテムにラベルを付けることができることを意味する。「SceneMode=Face」の場合、「Recognized」は、顔の識別が可能であることを意味する。あるバージョンでは、SceneMode構成は、オブジェクトのための参照画像に基づくオブジェクトの認識をサポートする。
４．ItemCharacterized：このプロセスは、アイテムのより高いレベルの特性を決定することができる。例えば、「SceneMode=Face」の場合、「Characterized」とは、検出された顔の何らかの特徴に属性が関連付けられていることを意味する。例えば、検出された顔に気分や感情が関連付けられていることを意味する。
SceneModeは、SceneMarkの生成をトリガーするのに必要なAnalysis Levelを定義する。例えば、SceneMode=Faceの場合、Trigger Conditionは、Face Detected、またはFace Recognized、またはFace Characterized for Emotionとなる。同様のオプションが上記の他のScene Modeのリストにある。

【0089】

SceneMarkオブジェクト
SceneMarkは、時間及び／または場所に相関のある集約されたイベントの画像理解に基づいて認識された関心のあるシーンのコンパクトな表現である。SceneMarkは、センサデータの消費者に関連する情報を抽出して提示するために使用することができる。また、SceneMarksは、生のセンサデータを含む詳細情報の知的かつ効率的なアーカイブ／検索を促進するために使用することができる。この役割において、SceneMarksは、より大量のセンサデータへのインデックスとして機能する。

【0090】

SceneMarkオブジェクトには、以下のものがある。
・SceneMark識別子
・タイムスタンプ
・画像理解メタデータ
・対応するSceneDataへの参照

【0091】

解析エンジンがTriggerConditionに遭遇すると、SceneMarkが生成される。それは、SceneDataへの参照と、Trigger Conditionのメタデータを提供する。SceneMarkの完全性は、Nodeの分析能力によって決定される。より高いレベルの分析が最終的に必要とされるときに、Nodeが動作検出しか実行できない場合、部分的なSceneMarkが生成されることがある。この部分的なSceneMarkは、後続の処理Nodesによって完成され得る。

【0092】

SceneDataオブジェクト
SceneDataは、１つまたは複数のセンサデバイス及び／またはセンサモジュールのグループによって取り込みまたは提供され、シーンに関連するさまざまなタイプのセンサデータを含む。SceneDataは、取り込まれた生のデータに限定されるものではなく、いくつかのさらなる処理を含んでいてもよい。例は、以下を含む。
・ＲＧＢ画像データ
・ＩＲ画像データ
・ＲＧＢのＩＲ画像データ
・深度マップ
・ステレオ画像データ
・オーディオ
・温度
・湿度
・一酸化炭素
・パッシブ赤外線

【0093】

SceneModeは、SceneModeに関連付けられたTriggerがトリガーされたときに生成されるSceneDataの種類と量を定義する。例えば、SceneModeの構成は、Triggerの前の１０秒のビデオとTriggerの後の30秒のビデオがSceneDataとして生成されることを示すことができる。これは、SceneModeデータオブジェクトのSceneDataコンフィギュレーションフィールドに設定される。SceneDataに定義された期間よりも早くトリガーが発生した場合、複数のSceneMarkがSceneDataの１つのビデオファイルを参照することがある。例えば、複数のTriggersが３０秒以内に発生し、各Triggerに対してSceneDataが３０秒と定義されている場合。この３０秒の間に複数のTriggersが発生した場合、各Triggersに対して生成されたSceneMarksは、そのTriggersのSceneDataを構成する同じビデオファイルを参照する。

【0094】

セクションＢ：コマンドの説明
Control Interfaceでは、以下のコマンドがサポートされている。
・GetCapabilities. Sinkによって特定のSource Nodeのケイパビリティのリストを取得するために使用される。
・SetSceneMode. Sinkは、Source NodeにSceneModeをロードする。SceneModeは、SceneMode ScheduleがSceneModeをトリガーするか、明示的なStartSceneコマンドがNodeに送信されると、アクティブになる。SceneModeは、Scheduleに従って、またはStopScene コマンドがNodeに送信されると、非アクティブになる。StartSceneとStopSceneコマンドは、Scheduleを上書きする。
・SetCaptureSequence. このコントロールクラスの実装は、イメージ取込みに使用されるTransducer Source Nodの取り込み設定をコントロールするために、Sinkが使用することを意図している。取込みモードは、フレームの取り込みのシーケンスと各フレームの設定を表す。例えば、取込みモードで高解像度フレームの後に４つのビデオフレームが必要な場合、センサには２つのコントロールクラスが送信されることになる。１つ目のクラスは、静止画が撮影される前に送信され、特定の露出設定、特定のフォーカス設定などでフル解像度のフレームを撮影することを示す。２つ目のクラスは、ビデオシーケンスの取り込み、シーケンス内のフレーム数、デジタルズームの設定等を指示するために送信される。
・StartScene． Sinkは、SceneModeを開始する。このSceneModeを停止するには、明示的にStop Sceneコマンドが発行される。SceneMarkScheduleに同じScene IDがある場合、このコマンドはSceneMarkScheduleを上書きする。
・StopScene． Sinkは、実行中のSceneModeを停止する。これは、スケジュールされたSceneModeまたは定期的にトリガーされたSceneModeを停止するために使用される。このコマンドを使用してスケジュールされたSceneModeが停止した場合、StartSceneModeコマンドが送信されるか、次のスケジュールされた時間が発生した場合にのみ、SceneMode が再起動される。
・SetSceneModeSchedule． Sinkは、プリロードされたSceneModeと組み合わせて使用するSceneMode スケジュールを設定する。複数のSceneModeをNodeにロードすることができる。このオブジェクトがNodeにロードされた場合、オブジェクトにリストされているSceneMode IDは、オブジェクト内で定義されたScheduleに従って実行される。

【0095】

Data Interfaceでは、以下のコマンドがサポートされる。
・GetSceneData． Sinkは、Source NodeからSceneDataファイルまたはマニフェストを要求する。
・SetSceneData． Source Nodeは、少なくとも１つのSceneDataオブジェクトまたは少なくとも１つのSceneDataファイルへの参照を含むSceneDataマニフェストを公開する。この構造は、過去のSceneDataの一部または完全なセットを含む、または参照するためにも使用できる。また、SceneDataは、このデータオブジェクト内にエンコードすることもできる。
・GetSceneMark． Sinkは、特定のSceneMark ID に対応するNodeから特定のSceneMark を要求する。
・SetSceneMark. Source． Sourceは、Node 内に保存されているSceneMarkを書き込む。

【図1A】

【図1B】

【図2】

【図3】

【図4】

【図5】

【図6A】

【図6B】

【図7】

【図8】

【図9】

【図10】

【図11】