特許 6398114 プラットフォーム及びイメージデバイスの間の通信プロトコル

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

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

(11)【特許番号】6398114

(24)【登録日】2018年9月14日

(45)【発行日】2018年10月3日

(54)【発明の名称】プラットフォーム及びイメージデバイスの間の通信プロトコル

(51)【国際特許分類】

   G06F 13/38 20060101AFI20180920BHJP

   G06F 3/01 20060101ALI20180920BHJP

   G06F 3/14 20060101ALI20180920BHJP

   G06F 3/12 20060101ALI20180920BHJP

   B41J 29/38 20060101ALI20180920BHJP

【ＦＩ】

   G06F13/38 320Z

   G06F3/01 570

   G06F3/14 310C

   G06F3/12 306

   G06F3/12 318

   G06F3/12 323

   B41J29/38 Z

【請求項の数】21

【全頁数】15

(21)【出願番号】特願2015-530145(P2015-530145)

(86)(22)【出願日】2013年9月3日

(65)【公表番号】特表2015-537265(P2015-537265A)

(43)【公表日】2015年12月24日

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

(87)【国際公開番号】WO2014039457

(87)【国際公開日】20140313

【審査請求日】2015年3月5日

(31)【優先権主張番号】13/603,738

(32)【優先日】2012年9月5日

(33)【優先権主張国】US

【前置審査】

(73)【特許権者】

【識別番号】591003943

【氏名又は名称】インテル・コーポレーション

(74)【代理人】

【識別番号】110000877

【氏名又は名称】龍華国際特許業務法人

(72)【発明者】

【氏名】クリグ、スコット エー．

【審査官】 坂東 博司

(56)【参考文献】

【文献】 特表２０１０−５３６２３２（ＪＰ，Ａ）

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

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

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

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

【文献】 特開２０１０−００４３５３（ＪＰ，Ａ）

【文献】 特開２００５−３５４５０９（ＪＰ，Ａ）

【文献】 特開２００５−１４２６８３（ＪＰ，Ａ）

【文献】 特開２００３−２４４３７７（ＪＰ，Ａ）

【文献】 特開２００４−３２０１９９（ＪＰ，Ａ）

(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】

前記シンクデバイスは、ディスプレイを有し、
前記プロセッサは、前記ディスプレイからメッセージを受信するとともに、前記ディスプレイから受信したメッセージで指定されるフォーマットの画像データを生成して前記ディスプレイに提供する請求項１１から１５のいずれか１項に記載の装置。

【発明の詳細な説明】

【背景技術】

【0001】

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

【0002】

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

【0003】

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

【図面の簡単な説明】

【0004】

以下の図面に関していくつかの実施形態が説明される。

【図1】本願発明の一実施形態のブロック図である。

【図2】本願発明の一実施形態のフローチャートである。

【図3】本願発明の他の実施形態のフローチャートである。

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

【0005】

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

【0006】

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

【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】

【表1】

【0040】

【表2】

【0041】

【表3】

【0042】

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

【0043】

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

【0044】

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

【0045】

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

【0046】

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

【0047】

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

【図1】

【図2】

【図3】