JP2020115350A - プラットフォーム及びイメージデバイスの間の通信プロトコル - Google Patents

Abstract

【課題】画像上の被写体を認識したことに応じてメタデータを生成する装置、方法、プログラム、カメラ及び記録媒体を提供する。【解決手段】コンピュータシステム１０において、プロトコルは複数のプラットフォームと複数のイメージデバイスの間の通信を許可する。これは、プラットフォームが望む情報の複数の特定のタイプ、プラットフォームが好む情報のフォーマット及びプラットフォームにおける処理の量を低減する他の情報をプラットフォームが指定することを可能にする。【選択図】図１

Description

概して、これは、複数のプリンタ、複数のモニタまたは複数のディスプレイ、及び複数のカメラなどの複数のイメージングデバイス周辺機器を含む、コンピュータ制御される複数のデバイスに関する。

いくつかの例を挙げると複数のラップトップコンピュータ、複数のデスクトップ型コンピュータ及び複数のタブレットなどの従来の複数のコンピュータプラットフォームは、相互作用してイメージングデバイスからの情報を受信し得る。
本明細書中で用いられるように「イメージデバイス」とは、画像を生成または表示することができる任意のものであり、モニタ、ディスプレイ、カメラ、イメージセンサ、プリンタ、またはファクス送受信機を含む。

従来、プラットフォームはイメージングデバイスから単純に未処理データを受信し、その後、未処理データに対する必要な処理を実行する。

以下の図面に関していくつかの実施形態が説明される。
本願発明の一実施形態のブロック図である。 本願発明の一実施形態のフローチャートである。 本願発明の他の実施形態のフローチャートである。

いくつかの実施形態によると、プロトコルは複数のプラットフォームと複数のイメージデバイスの間の通信を可能にする。これは、例えば、プラットフォームが望み得る情報の複数の特定のタイプ、プラットフォームが好み得る情報のフォーマット、及び、プラットフォームにおける処理の量を低減し得る他の情報、をプラットフォームが指定することを可能にする。

したがって、プロトコルは標準化された制御方法と、複数のデバイス間を行き来するステータス情報、例えばデバイス機能を得るための制御メッセージなどと、をもたらすと共に、処理の特徴及び挙動と、複数の利用可能なデバイスの特徴及びオプションを示す複数のステータスメッセージとを変更しても良い。例えば、従来、ジェスチャ認識ソフトウェアにおいて、プラットフォームは、ジェスチャを特定するべく解析され、サーチされ、かつ処理されるための、動画の継続中のストリームを受信する。

これは、特に無線通信または他の帯域幅制限通信が関係し得る場合に、複数のプラットフォーム及び複数のイメージデバイスの間の通信帯域幅を消費し得る。したがって、いくつかの実施形態では、プラットフォーム及びイメージングデバイスの間の通信に、プラットフォームにとって所望の情報、例えば、どのみち単純に破棄される不要なデータを送信する必要を減らすこと、を指定できるようにすることが有効である。

同様に、ディスプレイ、モニタ、プリンタ、ファクス送受信機などの任意の画像受信装置は、コンピュータシステムまたはプラットフォームなどの画像ソースに対して、データを受信したいフォーマットを指定しても良い。例えば、特定のマージンを使用する特定のデータタイプ、特定のデータ密度、または特定のプロトコルを必要とするディスプレイまたはプリンタは、この情報をソースに対して指定することができる。従って、ソースは画像受信装置に情報を供給すべく処理を行うことができる。

また、本発明のプロトコルの実施形態は、複数の実際のカメラ、複数のプリンタ及び複数のディスプレイも、複数のカメラ及び複数のディスプレイの代わりに動作する複数のプロセッシングユニットも、他のデバイス内で動作する複数のバーチャルカメラ、複数のプリンタ及び複数のディスプレイも含んで良い。例えば、ラップトップコンピュータデバイスは、このプロトコルを用いて実際のプリンタに対して通信することができるバーチャルカメラを実行しても良く、複数のバーチャルカメラはダンプラップトップカメラの代わりに動作し、このプロトコルを実現すべくスマートラッパーを提供する。

同様に、いくつかの実施形態では、複数の画像ソースは、それらが提供することができる画像データの特性を指定することで、複数の他のフォーマットの選択についての複数の選択肢を提供し、好ましいフォーマットに関するフィードバックをシンクデバイスから受信することができる。

いくつかの例に言及すれば、複数のイメージデバイスは複数のディスプレイ、複数のプリンタ、複数のイメージプロセッサ、複数のイメージセンサ及び複数のファクス送受信機を含んでも良い。いくつかの実施形態では、これらの周辺機器は、データの解析及び編集を実行するとともに、複数のコマンドを受信し、これら複数のコマンドに対する応答を通信するための十分な知能を有する。したがって、概してこれらの周辺機器は、メモリまたは記憶装置も含むプロセッサベースシステムであろう。

複数の潜在的な用途には、顔認識、被写体認識、シーン認識、シーン内の光源及び方向ベクトルに関する知覚指向情報、ソース及び複数の目標デバイスの比色分析の複数のプロパティが含まれる。

最初の例として、カメラ内のイメージセンサは、例えば、コンシューミングなエンドポイントプラットフォームのニーズに適合させるべく、実行される処理のタイプを変更するための知能か、或いは、生成される対応メタデータを変更するための知能を有しても良い。例えば、いくつかのプラットフォームは、動画または他の画像情報が有る場合又は無い場合での、関心点座標、被写体座標、被写体カウント、及び他の記述子情報などの、メトリクスの形態の処理済み画像メタデータを望むかもしれない。プリンタなどの他のイメージングデバイスは、メタデータを望まないかも知れないし、特定の態様で処理された生の動画のみを要求するかも知れない。

他の例のように、スマートカメラは、特定の属性の顔を探すよう命令されるかも知れない。スマートプリンタは、１０フレーム／秒のシーンの３次元デプスマップをカメラに用意するよう求めることをスマートアプリケーションソフトウェアに許可しつつ、最適なプリントレンダリングのための、プリンタの色空間デバイスモデルに適した未処理画像データを配信するようカメラに伝えても良い。同様に、プリンタまたはディスプレイは、顔などの被写体の範囲の位置及び領域を提供するようカメラに求めても良く、これによりプリンタまたはディスプレイは、ベストな鑑賞結果を実現するべく最適化された態様で、顔領域などの被写体のスマートエンハンスメントを実行する。したがって、イメージキャプチャデバイスは、被写体の広い範囲を認識するとともに、プリンタ、ディスプレイまたは他のレンダリングデバイスにレンダリングを最適化させつつ、ここで説明されるタイプの標準化されたプロトコルを用いて、プリンタまたはディスプレイに被写体情報を通信することができても良い。

したがって、いくつかの実施形態では、標準化された双方向性のプロトコルは、プラットフォームと周辺機器の間でイメージングデータの仕様の通信を許可するように実装されても良い。いくつかの実施形態では、これはより効率のよいデータ伝達と、不必要なデータの伝達の縮小をもたらす。

プロトコルは、ＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）、限定されるものではないがＵＳＢ（ｕｎｉｖｅｒｓａｌ ｓｅｒｉａｌ ｂｕｓ）を含むカメラによって使用される既存の複数の標準ハードウェアプロトコルメソッドを通じてイメージングデバイス間を双方向に送信されるＡＳＣＩＩ（Ａｍｅｒｉｃａｎ Ｓｔａｎｄａｒｄ Ｃｏｄｅ ｆｏｒ Ｉｎｆｏｒｍａｔｉｏｎ Ｉｎｔｅｒｃｈａｎｇｅ）テキストコマンドストリーム、ＭＩＰＩ（Ｍｏｂｉｌｅ Ｉｎｄｕｓｔｒｙ Ｐｒｏｃｅｓｓｏｒ Ｉｎｔｅｒｆａｃｅ）（ＭＩＰＩアライアンスインコーポレイテッドから入手可能な仕様）、ＰＣＩＥ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔｓ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｅｘｐｒｅｓｓ）、または、３．０５仕様（ＰＣＩ Ｓｐｅｃｉａｌ Ｉｎｔｅｒｅｓｔ Ｇｒｏｕｐ, Ｂｅａｖｅｒｔｏｎ, ＯＲ ９７００６, ２０１０‐１０−８)のように高水準に具体化されることができ、或いは、プロトコルは既存の複数のハードウェアプロトコルの拡張であっても良い。

代わりに、新たなハードウェアプロトコルは、例えばＭＩＰＩ、ＵＳＢ、ＰＣＩｅにおける双方向チャネルとして考案されても良いし、それどころか、Ｈ．２６５（Ｈｉｇｈ Ｅｆｆｉｃｉｅｎｃｙ Ｖｉｄｅｏ Ｃｏｄｉｎｇ, Ｆｅｂ. ２０１２, ａｖａｉｌａｂｌｅ ｆｒｏｍ Ｆｒａｕｎｈｏｆｅ Ｈｅｉｎｒｉｃｈ Ｈｅｒｔｚ Ｉｎｓｔｉｔｕｔｅ）及びコーデックフォーマットなどの動画規格を含む双方向チャネルとして考案されても良い。ＩＳＯ／ＩＥＣ ＭＰＥＧ（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅｓ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ）から入手可能なＨ．２６５を参照して欲しい。

複数の使用事例には、スマートプロトコルを使用可能なカメラに対し、各デバイスの色域が与えられた場合に複数の画像が最適に印刷されるように処理する方法をアドバイスする、スマートプロトコルの使用可能な複数のプリンタが含まれる。他の使用事例は、特定の顔が見えた場合に情報を生成するだけに構成されることのできる、スマートプロトコルを使用可能なカメラであり、顔にマッチする座標と共に顔の詳細がスマートカメラデバイスに送信され、信頼水準が対応画像と共に、または対応画像無しでプラットフォームに送信されることを許可する。このやり取りは、これらの特性を有する複数の顔を探したり、追尾するジェスチャを探したり、追尾する被写体を探したり、被写体が見つかった場合に報告のみを行い、その後、座標、記述子情報、信頼レベル、及び、全体の画像フレームまたは被写体を含むフレーム部分を送信したりするなどのサーチを行うための、標準化された関心のセットまたは記述子セットを送信することを伴っても良い。

他の使用例はスマートプロトコルを使用可能な複数のディスプレイを含み、これらのディスプレイは、それらの比色定量的に正確な色域マップと、デバイスカラーモデルとをカメラに送信し、そのディスプレイにとって最適な画像をカメラが生成できるようにすることができる。他の適用は、スマートプロトコルを使用可能なカメラのセンサチップにコマンドを送信して、顔の長方形の座標だけを、対応する関心点及び他の画像記述子についての複数の詳細と共に要求する通信プロトコルの使用を可能とする、顔追跡アプリケーションソフトウェアを伴う。

追加の適用として、３次元プリンタは、設定コマンドをスマート３Ｄカメラに送信するための通信プロトコル及び通信チャネルを使用しても良い。これらの設定コマンドは、限定されるものではないが、ステレオ、タイムオブフライト（ＴＯＦ）、ストラクチャライトなどを含む、様々な複数の３次元（３Ｄ）センサ技術ごとに、特定の複数のコマンドまたは複数の命令を含んでも良い。

３Ｄプリンタは、次に、３Ｄトライアングルデプスメッシュにおける各トライアングル上の複数のテクスチャだけでなく、デプスマップと３Ｄトライアングルデプスメッシュにおける複数のトライアングルのセットとを、各ポリゴンについての複数の対応色と、デプスマップとを有するイメージセンサカメラデバイスに要求するのみであり、その結果、３次元モデルをカメラデプスマップ及び３次元プリンタ上の色情報から直接的に印刷することが可能となる。または、ここで説明されるタイプの標準化されたプロトコルによって、３Ｄトライアングルデプスメッシュ、及び、同一の３Ｄトライアングルデプスメッシュが３Ｄディスプレイにも提供され、ディスプレイ上でのフル３Ｄレンダリングを可能としても良い。

したがって、図１を参照すると、コンピュータシステム１０は、メモリ１６、プロセッサ１４及びインターフェース１８を有するプラットフォーム１２を備える。インターフェース１８は、カメラ２０、プリンタ２２及びモニタ２４などの複数のイメージングデバイスとインターフェースしても良い。

デバイス２０、２２および２４のそれぞれは、ハードウェアプロセッサ５０及び内部ストレージ５２を有するハードウェアデバイスであっても良い。また顔認識アプリケーション２６及びジェスチャ認識アプリケーション２８がメモリ１６に格納されても良い。ここで説明されるタイプのプロトコルは、複数のデバイスに対し、互いにプログラムして特別な機能を実現することを可能にする。例えばスマートプリンタはプログラムソースコードまたは実行可能コードをスマートカメラに送信することで、プリンタの代わりに特定の処理を実現させても良い。

インターフェース１８は、ＭＩＰＩ，ＵＳＢ，ＵＥＦＩ（Ｕｎｉｆｉｅｄ Ｅｘｔｅｎｓｉｂｌｅ Ｆｉｒｍｗａｒｅ Ｉｎｔｅｒｆａｃｅ）（ＵＥＦＩ Ｓｐｅｃｉｆｉｃａｔｉｏｎ, ｖ. ２.３．１ , Ａｐｒｉｌ １８, ２０１ １ ）、ＨＴＭＬ（Ｈｙｐｅｒｔｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）、またはＴＣＰ／ＩＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ/Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）ソケット若しくはＵＤＰ（Ｕｎｉｆｏｒｍ Ｄａｔａ Ｐｒｏｔｏｃｏｌ）データグラムでさえも含む、様々な異なるインターフェースの１つを実装しても良い。他の複数の通信チャネルは、有線及び無線ネットワークの両方を含む。いくつかの例に言及すると、インターフェースは、要求／応答プロトコル、ポーリングされたプロトコル、または、イベントまたはインタラプトイベントプロトコルであり得るプロトコルを実装しても良い。いくつかの例に言及すると、プロトコルは、ＣＳＲ（Ｃｏｍｍａｎｄ ａｎｄ Ｓｔａｔｕｓ Ｒｅｇｉｓｔｅｒ）共有メモリまたはレジスタのインターフェース、または、ＨＴＴＰ、ＴＣＰ/ＩＰ上のソケット内のデータグラムなどのストリームプロトコルインターフェースもまた用いることができる。本発明のいくつかの実施形態に関連し、任意のプロトコル方式が使用され得る。

図２のプロトコルソースシーケンス３０及び図３に示されるプロトコルシンクシーケンス４０を含む図２及び図３の複数のシーケンスは、ソフトウェア、ファームウェア及び／またはハードウェアによって実装され得る。 ソフトウェア及びファームウェアの複数の実施形態において、複数のシーケンスは、コンピュータに実行される複数の命令を記憶する１または複数の非一時的なコンピュータ可読媒体によって実装される。いくつかの実施形態では、非一時的なコンピュータ可読媒体は、オプティカル、マグネティック、及び／または半導体のメモリであっても良い。

図２を参照すると、データを要求するためのプロトコルソースシーケンス３０は、ブロック３２で示されるように、要求を受信することで始まる。要求は、プラットフォームまたはカメラなどの周辺機器で受信され得る。

ブロック３４で示されるように、要求は、動画受信／要求デバイス内で有効な適切な複数のコマンドに変換され得る。次に、ブロック３６で示されるように、受信され得る未処理データは、フィルタリングされて、要求で記載されるフォームにされ得る。したがって、フォーマットは、多様なデータフォーマット、多様なデータサイズ、特定のテキストアイテムを検索しつつデータ及び画像内で特定の被写体を検索するための複数の特定の被写体のスペック、または、他の要求を含んでも良い。

次に、ブロック３８に示されるように、フィルタリングされたデータは、シンクに送信される。いくつかの実施形態では、シンクは、モニタまたはプラットフォームなどの受信デバイスであっても良い。

図３は、データを消費するデバイスであるプロトコルシンクシーケンス４０を示す。シーケンス４０は、ブロック４２において、データフォーマットを特定することにより始まる。

プロトコルシンクシーケンスは、例えば２つの例として、プラットフォームまたはディスプレイに実装されても良い。次に、ブロック４４において、データのポテンシャルソース（例えばカメラ）が特定されても良い。次に、ブロック４６に示すように、既にブロック４２で特定された特定フォーマットで、データがソースから要求される。次に、ブロック４８に示されるように、フォーマットされたデータが受信されて確認される。

使用され、プラットフォーム及び複数のイメージングデバイスの間で通信され得るメタデータは、ＸＭＬを含む様々なフォーマットであっても良い。プロトコルメタデータは、ソフトウェアメタデータのコマンド及びステータスの構文を実装しても良い。選択されたプロトコル指示語のセットが使用され、複数のプラットフォーム及び複数のイメージングデバイスの間の双方向通信を可能にしても良い。

複数の異なるコマンドが開発されても良いし、デフォルトのコマンドが提供されても良い。 各コマンドは、任意の有用な、要求された情報を返すのに加え、成功、失敗または故障のコードを示すステータスコードを返しても良い。

コマンドの第１の例として、画像前処理パイプラインの要求または応答は、複数の例として、シャープニング、コントラスト改善、またはＨＩＳＴＥＱの項目を指定しても良い。画像フォーマット要求または応答コマンドは、ＲＧＢなどの使用されるべき色空間、ＢＡＹＥＲ，ＹＵＶ４２２，ＹＵＶ４４４，ＨＳＤ，Ｌｕｖなどの使用され得るパターン、ｘ／ｙ次元が使用されるべきか否かなどの次元を指定しても良い。

最適なコマンドとしての、さらに他の適用可能なコマンドは、カメラによって画像及びメタデータの両方が最適化される複数のデバイス及び複数のアプリケーションを指定するための要求及び応答を含む。これは、この技術に関係する既知の複数のデバイスのリストに対する複数のデバイスモデルのプロファイルの公開リストに基づいても良い。

これらのプロファイルは、カメラに組み込まれても良いし、或いは、カメラによってオンデマンドでネットワークまたは記憶デバイスから検索されても良い。この構成は、カメラがデバイスの画像色域、または顔認識のような既知のアプリケーションに対する画像色域を更に最適化することを可能にする。したがって、複数のデバイスの標準的な構成は登録され、周知の位置にオンラインで格納されても良く、これにより、ここで説明されるタイプの標準化されたプロトコルが使用されてデバイス構成を獲得する、或いは、このプロトコルで使用されるデバイス構成をセットすることができる。

他の潜在的なコマンドは、複数の所望の関心点の複数のタイプを指定するための関心点要求または応答である。さらにコマンドの他の例は、複数の関心点の周囲の複数の領域記述子のタイプを指定するための記述子要求及び応答である。他の複数のコマンドは、複数の光源の色と、返される複数の方向ベクトルを指定するための光源要求及び応答を含む。他の複数の例は、デバイスカラーモデルに対する、デバイスのカラーモデルを返すための要求及び応答を含む。

要求または応答は、デバイスの色域の数学モデルなどの所望の情報と、Ｊａｖａ（登録商標）バイトコードなどのＬＬＶＭ（Ｌｏｗ Ｌｅｖｅｌ Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ）コードとのいくつかの組み合わせを含んでも良い。さらに他のコマンドは、デプスマップ内で返されるフォーマットを指定するためのデプスマップ要求及び応答である。プロトコルの実施形態では、整数値及び浮動小数点演算の精度と、８整数または１６整数と、複数の画像領域のｘ／ｙ次元と、ポリゴン３Ｄメッシュポイント、及び、ポイントまたはピクセルデプスマップを含むデプスマップの固有フォーマットとを含む複数のコンピュータメモリデータフォーマットを指定する可能性が存在する。

以下の表は、複数のコマンドの例を説明及びＸＭＬ（ＥＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）サンプル具体例とともに示す、各コマンドは、要求された任意の有用な情報を返すのに加え、成功、失敗または故障のコードを示すステータスコードを返しても良い。

いくつかの実施形態では、特定の画像処理及び動画分析の複数のプロトコルが生成されることができ、そのようなシーケンシャルな組み合わせは、例えば画像の先鋭化、画像の色修正、顔のサーチ、プリンタへの顔座標の送信、またはプリンタへの画像送信などである。

複数の基本要素の他のコマンドリストは、スマートデバイスにＪａｖａ（登録商標）バイトコードまたはＬＬＶＭコードを送信するための複数の基本要素の要求を除き、デバイスが実行可能な複数の基本機能をリスト化することを要求する。コードは、実行されるアルゴリズムであっても良く、デバイスがプロセッサを有し、コードを受け付けて実行でき、その後、コードがコマンドによって名指しで実行され得ることを前提とする。

基本コマンドの実行は、名指しでの基本要素の実行の要求であっても良い。生成コマンドは、一連の基本要素からパイプラインを生成しても良い。サーチ方法コマンドは、スマートカメラが探すべきもの、メタデータが返すべきもの及びメタデータがどのくらいの量か、及び、どのくらいの頻度でメタデータを返すか、を指定する要求であっても良い。

サーチターゲットコマンドは、スマートカメラが探すべきものを指定する要求である。これは、複数の例として、どのタイプの端点を探すか、どのタイプの顔を探すか、及び、どのタイプの車を探すか、をカメラに教えることができる。最終的に、サーチ結果コマンドは、対応するサーチコマンドからの結果の受信に対する応答であっても良い。複数の結果は、サーチ方法コマンドによって指定されるように定期的に来ても良い。

本明細書の全体を通じ「一実施形態」または「実施形態」という語は、その実施形態に関連して説明された特定の機能、構造または特性が、本発明内に含まれる少なくとも１つの実装に含まれることを意味する。したがって、「一実施形態」または「実施形態では」という用語の複数の出現は、必ずしも同一の実施形態を指すものではない。さらに、複数の特有の特徴、構造、または特性は、説明された特定の実施形態以外の他の適した形態で実施されることができ、そのようなすべての形態は、本願発明内に包含され得る。

本発明は、限定的な数の実施形態に関して説明されたものであり、当業者であれば、そこから多数の修正及び変形が理解される。添付された特許請求の範囲は、本発明の真の趣旨および範囲に属する全ての複数の修正及び複数の変形を包含することが意図されている。

Claims (29)

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. 被写体認識は、顔認識を有する、請求項２２〜２４の何れか一項に記載のカメラ。
26. 前記メッセージは、提供される前記メタデータを指定する、請求項２２〜２５の何れか一項に記載のカメラ。
27. 前記メタデータは、ＸＭＬを有する、請求項２２〜２６の何れか一項に記載のカメラ。
28. 前記カメラは前記プラットフォームの周辺機器であり、
    前記メッセージは、インターネットプロトコル（ＩＰ）コンパーチブルネットワークを介して受信される、請求項２２〜２７の何れか一項に記載のカメラ。
29. 請求項１５〜２１の何れか一項に記載のプログラムを格納する少なくとも１つの記録媒体。

Images