JP5843207B2 - 直観的コンピューティング方法及びシステム - Google Patents

Description

関連出願データ

米国において、本出願は、２０１０年３月２６日出願の米国特許仮出願第６１／３１８２１７号、及び、２０１０年３月１９日出願の米国特許仮出願第６１／３１５４７５号の優先権を主張し、２０１０年６月９日出願の米国特許出願第１２／７９７５０３号の継続である。

本明細書は、米国特許第６９４７５７１号、２０１０年３月３日出願の米国特許出願第１２／７１６９０８号（米国特許出願公開第２０１０／０２２８６３２号）、２０１０年２月２４日出願の米国特許出願第１２／７１２１７６号、２０１０年１月２８日出願の米国特許出願第１２／６９５９０３号（米国特許出願公開第２０１０／０２２２１０２号）、２００９年８月１９日出願の国際出願ＰＣＴ／ＵＳ０９／５４３５８（国際公開第２０１０／０２２１８５号パンフレット）、２００９年６月２４日出願の米国特許出願第１２／４９０９８０号（米国特許出願公開第２０１０／０２０５６２８号）、２００９年６月１２日出願の米国特許出願第１２／４８４１１５号（米国特許出願公開第２０１０／００４８２４２号）、及び、２００８年１１月１４日出願の米国特許出願第１２／２７１７７２号（米国特許出願公開第２０１０／０１１９２０８号）を含む、譲受人の以前の特許及び特許出願に詳述された技術に対する拡張及び改良に関する。読者は、前述の公報に精通していると推定される。

これらの直前に引用された文献からの原理及び教示は、ここで詳述される構成（ａｒｒａｎｇｅｍｅｎｔｓ）に関連して適用されるように意図され、逆の場合も同じである。（これらの以前の特許及び出願の開示は、全体として参照により本明細書に組み込まれる。）

本明細書は、様々な技術に関し、スマートフォン及び他のモバイルデバイスが、例えば、直観的な聴覚及び視覚デバイスとしての機能を果たすことによって、ユーザの環境に応答することを可能にすることに最も関係する。

序論

携帯電話は、単一目的の通信ツールから多機能コンピュータプラットフォームへと進化を遂げている。「Ｔｈｅｒｅ’ｓ ａｎ ａｐ ｆｏｒ ｔｈａｔ」は、よく知られている言葉である。

２０万を超えるアプリケーションがスマートフォン用に入手可能であり−圧倒的に様々なサービスを提供している。しかし、これらのサービスの各々は、ユーザによって明示的に識別され、起動されなければならない。

これは、コンピュータに対して我々がより多くの注意を払う必要があるのではなく、より少ない注意を払えばよいという、２０年以上前に遡るユビキタスコンピューティングのビジョンからは、程遠いものである。真に「スマート」な電話とは、アクションを−自律的に−起こして、推論又は予想されたユーザの要望をかなえる電話であるだろう。

この方向における飛躍は、携帯電話に、インテリジェントな視覚／聴覚デバイス−ユーザの環境を監視させ、視覚及び／又は他の刺激に応答して動作を自動的に選択させ、その動作に着手させる−技術を、携帯電話に装備することであるだろう。

このようなデバイスの実現には、多くの課題がある。これらの課題には、デバイスへの入力刺激が何を表すかを理解し、その理解に基づいてユーザの要望を推論し、それらの要望を充足する際にユーザとインタラクトするための技術が含まれる。おそらく、これらの課題のうち最大の課題は最初の課題であり、本質的に機械認知の長年の問題である。

携帯電話カメラを考えられたい。キャプチャされるフレーム毎に、携帯電話カメラは、１００万ほどの数（ピクセル値）を出力する。これらの数は、車、バーコード、ユーザの子供、又は１００万もの他の物のうち１つを表すのか？

仮定として、この問題には直接的なソリューションがありうる。それらのピクセルを「クラウド」へ転送し、莫大な数の匿名のコンピュータに、描かれた被写体を１台のコンピュータがついに識別するまで、あらゆる知られている画像認識アルゴリズムをそのデータに適用させることである。（１つの特定の手法は、その知られていない画像を、フリッカー（Ｆｌｉｃｋｒ）及びフェイスブック（Ｆａｃｅｂｏｏｋ）など、ウェブベースの公共の写真リポジトリに投稿された数十億もの画像の各々と比較することであるだろう。最も類似した投稿写真を発見した後、マッチするピクチャに関連付けられた記述語又は「メタデータ」が示され、その知られていない画像の被写体を識別するために記述子として使用されうる。）クラウドコンピューティング能力を数日又は数カ月（及び、数メガワットの電力を）費やした後、答えが出されるだろう。

そのようなソリューションは、しかし−時間の点からもリソースの点からも−実用的ではない。

幾分より実用的な手法は、アマゾン（Ａｍａｚｏｎ）のメカニカルターク（Ｍｅｃｈａｎｉｃａｌ Ｔｕｒｋ）など、クラウドソーシングサービスにその画像を投稿することである。このサービスは、その画像を１人又は複数人のレビュアーに任せ、レビュアーが記述用語をサービスに戻すように提供し、その記述用語が次いでデバイスに戻すように転送される。他のソリューションが無効であると判明するとき、これは可能な代替手段であるが、多くの状況で時間遅延が甚だしい。

一態様では、本明細書は、この認知の問題によりよく取り組むために用いることができる技術に関する。一実施形態では、入力刺激についてのより多くのよりよい情報を連続して得るために、画像処理構成が適用される。画像のコンテンツの大まかな感じは、１秒で入手可能でありうる。より多くの情報は、２秒後に入手可能でありうる。さらなる処理により、さらにより精緻化された査定が３〜４秒後に入手可能でありうる、などとなる。この処理は、そのような処理が継続することをユーザが必要としないという−明示された、暗示された、又は推論された−指示によって、任意の時点で中断することができる。

そのような処理が迅速で満足の行く結果を生じず、画像の被写体がユーザにとって関心のあるものであり続ける場合（又は、ユーザがそうでないと示さない場合）、画像は、より網羅的で非常に長い解析のために、クラウドに任せられてもよい。ブックマーク又は他のポインタをスマートフォンに格納して、ユーザがリモートサービスによるそのようなさらなる解析の結果を遡ってチェックし、知ることができるようにしてもよい。又は、そのようなさらなる解析がアクション可能な結論に達する場合、ユーザにアラートを出すことができる。

適切なデバイス応答（複数可）の認知及び識別を、コンテキストなど、付帯情報によって支援することができる。スマートフォンが、格納されたプロファイル情報から、ユーザが３５歳の男性であることを知り、ＧＰＳデータ及び関連付けられた地図情報から、ユーザがポートランドのスターバックス（Ｓｔａｒｂｕｃｋｓ）に位置することを知り、時間及び気象情報から、仕事日で暗く雪の降る朝であることを知り、デバイスの履歴から、この場所に以前に何回か訪れた際、ユーザが電話の電子ウォレットを用いて、コーヒー及び新聞を買い、電話のブラウザを使用して、フットボールの結果をレポートするウェブサイトを見たことを呼び戻す場合、スマートフォンのタスクは、かなり簡素化される。もはや、限りなく多数の可能性のある入力刺激はない。むしろ、入力の光景及びざわめきは、暗く雪の降る朝のコーヒー店で普通に遭遇するタイプのものである可能性が高い（又は、逆に言えば、例えば、東京の日当たりのよい公園で見られる光景及びざわめきである可能性が低い）。そのような光景及びざわめきに応答して適切である、限りなく多数の可能性のあるアクションもない。その代わりに、候補アクションは、３５歳の、フットボールに関心のある、ポートランドで仕事に出かける途中にコーヒーを飲んでいるユーザに関連するアクションである可能性が高い（又は、逆に言えば、例えば、東京の公園で座っている年配の女性に関連のあるアクションである可能性が低い）。

通常、最も重要なコンテキスト情報は、場所である。２番目に関連性が高いのは、典型的には（現在の曜日、季節などまでに知らされた）アクションの履歴である。同様に重要なものは、ユーザの社会的グループ内又はユーザの人口統計学的グループ内の他の人々が、類似の状況で何を行ったかについての情報である。（メイシーズ〔Ｍａｃｙｓ〕の特定の場所で最後に立ち止まった９人の十代の少女が、通路端のディスプレイにある一足のブーツの画像をキャプチャし、全員が値段を知ることに関心を持ち、そのうち２人が、どのサイズの在庫があるかを知ることにも関心を持った場合、その場所で立ち止まる１０人目の十代の少女がキャプチャする画像もまた、多分、同じブーツの画像であり、そのユーザは、値段、及び、おそらく在庫があるサイズを知ることに関心がある可能性が高い。）そのような付帯情報に基づいて、スマートフォンは、統計的に可能性が高い刺激に適した認識ソフトウェアをロードすることができ、それに応答して、統計的に関連のあるアクションに着手する用意をすることができる。

１つの特定の実施形態では、スマートフォンは、入手可能な何百もの代替ソフトウェアエージェントを有することができ−その代替ソフトウェアエージェントの各々は、複数の異なる機能を行うことができてもよく、各機能は、例えば、応答時間、ＣＰＵ使用率、メモリ使用量、及び／又は、他の関連のある制約の点から異なる「コスト」を有する。電話は次いで、プランニング課題に着手し、例えば、様々な入手可能なエージェント及び機能からなるＮ分木を定義し、その木を通るパスをナビゲートして、最低コストで所望の組み合わせの動作を行う方法を見極めることができる。

時として、このプランニング課題は、適切なソリューションを発見しないことがあり、又は、そのコストがひどく高いことを発見することがある。そのような場合、電話は、ある動作に−少なくともこの瞬間には−着手しないように決定することがある。電話は、そのようなタスクについてそれ以上何も行わないことがあり、又は、ソリューションを実用的にする追加の情報が入手可能になった場合に備えて、少ししてから、再度試みることがある。又は、電話は、単に、データを−より有能なクラウドリソースによる処理のために−クラウドに任せてもよく、又は、入力刺激を格納して、再び戻り、場合によっては後に処理してもよい。

システムの処理（例えば、画像処理）の多くは、推論的な性質であることがあり−現在のコンテキストにおいて有用である可能性があることを予期して試みられうる。本技術の別の態様によれば、そのような処理は、様々な要因に従って、スロットルアップ又はスロットルダウンされる。１つの要因は、成功である。ある処理が決定的な結果を出しつつあるように思われる場合、その処理により多くのリソース（例えば、メモリ、ネットワーク帯域幅など）を割り振ることができ、動作のさらなる段階へと継続することを許可することができる。その結果が思わしくないように見える場合、その処理により少ないリソースを割り振るか−又は完全に停止することができる。もう１つの要因は、特定の処理の結果に対するユーザの関心又はその欠如であり、この要因は、処理の継続が可能にされるかどうか、及び、どのリソースにより処理の継続が可能にされるかに、同様に影響を与えることができる。（ユーザの関心は−例えば、ユーザが画面上のある場所をタッチすることによって−明示／明確化されてもよく、又は、ユーザのアクション若しくはコンテキストから−例えば、ユーザがカメラを動かして、画像フレームの中心にある特定の被写体の位置決めをやり直すことによって−推論されてもよい。ユーザの関心の欠如は、ユーザのアクションによって、又は、そのようなアクションがないことによって、同様に明示又は推論されてもよい。）さらにもう１つの要因は、スロットルアップ又はスロットルダウンされている別の処理に対する、その処理の結果の重要性である。

認知が達成された後（例えば、画像の被写体が識別された後）、携帯電話プロセッサ−又はクラウドリソース−は、ユーザに提供されるべきである適切な応答を示唆することがある。描かれた被写体がバーコードである場合、ある応答が示されうる（例えば、製品情報を調べる）。描かれた被写体が家族の一員である場合、異なる応答が示されうる（例えば、オンラインフォトアルバムに投稿する）。時として、しかし、適切な応答は、直ちに明らかではない。もし、描かれた被写体が街路シーン又はパーキングメーターであるとしたらどうなるだろうか−その後どうなるだろうか？ここでもまた、コンテキストなど、付帯情報ソース、及び、自然言語処理からの情報を問題に適用して、適切な応答を決定する助けとすることができる。

スマートフォンのセンサは、刺激−マイクロフォンに対する音、画像センサに対する光、加速度計及びジャイロスコープに対する動き、磁力計に対する磁場、サーミスタに対する周辺温度等々−を絶えず与えられる。これらの刺激のいくつかは、重要であることがある。多くは雑音であり、無視することが最良である。電話は、もちろん、例えば、ＣＰＵ、バッテリ、無線帯域幅、金銭の予算など、様々なリソースが制限されている。

したがって、さらなる態様では、本技術は、集中するデータの何を処理すべきかを識別すること、並びに、視覚的検索のためのデータ処理構成とプラットフォームの制約及びシステムの他のニーズとのバランスを取ることを伴う。

さらにもう１つの態様では、本技術は、例えば、視覚的オブジェクト（又は可聴ストリーム）に対応した、モバイルデバイス画面上の「ボーブル（ｂａｕｂｌｅｓ）」の提示を伴う。ボーブルのユーザ選択（例えば、タッチスクリーンのタップによる）は、オブジェクトに関係付けられた体験につながる。デバイスが次第に、オブジェクトについて理解を深めるか、又は、より多くの情報を取得するにつれて、ボーブルの明瞭さ又はサイズが進化することが可能である。

初期の実装では、上記の種類のシステムは比較的に初歩的となり、多くの洞察を示すことはない。しかし、少量の（又は連発する）データを、（そのようなデータに基づいたユーザアクションについての情報と共に）アーカイブ及び解析するために、クラウドにフィードバックすることによって、それらの初期のシステムは、そこからテンプレート及び他のトレーニングモデルを構築することができるデータの基礎を確立することができ−そのようなシステムの後続の世代が、刺激を与えられるとき、高度に直観的となり、且つ、応答することを可能にする。

以下で明らかになるように、本明細書は、多数の他の、発明の特徴及び組み合わせをも詳述する。

主として視覚的検索に関連して記載されるが、本明細書で詳述される原理は、他のセンサから、又は、複数のセンサの組み合わせからの刺激の処理など、他の関連で適用可能であることを理解されたい。詳述される原理の多くは、さらにはるかにより幅広い適用可能性を有する。

同様に、以下の説明は、少数の例示的実施形態に焦点を合わせるが、発明の原理は、これらの特定の形式の実装に限定されないことを理解されたい。そのため、例えば、ブラックボードデータ構造、ステートマシン構成物、認識エージェント、遅延実行等々、詳細が具体的に述べられるが、いずれも（発行された特許請求の範囲によって特に明記されうる場合を除いて）必須ではない。

本技術のある態様を用いる実施形態をアーキテクチャ図で示す図である。 ローカルデバイスの、クラウド処理への関与を例示する図である。 認知処理の機能を、−システムモジュール及びデータ構造に関して−異なる態様の機能性とマッピングする図である。 異なるレベルの空間的編成及び理解を例示する図である。 サービスの構成の意思決定において使用することができるデータ構造を示す図である。 サービスの構成の意思決定において使用することができるデータ構造を示す図である。 サービスの構成の意思決定において使用することができるデータ構造を示す図である。 人工知能から知られ、本技術のある実施形態で用いられるプランニングモデルの態様を示す図である。 人工知能から知られ、本技術のある実施形態で用いられるプランニングモデルの態様を示す図である。 オペレーティングシステムによって行うことができる、４つのレベルの同時処理を識別する図である。 例示的実装のためのこれらの４つのレベルの処理をさらに詳述する図である。 ユーザの意図を見極めることに関与する、ある態様を示す図である。 ある実装で使用することができる循環的処理構成を描く図である。 図１２の構成の別の図である。 システム動作のある態様を描く概念図である。 認識エージェント及びリソース追跡にそれぞれ関するデータを例示する図である。 認識エージェント及びリソース追跡にそれぞれ関するデータを例示する図である。 視空間のマシン理解を支援するために使用することができる、グラフィカルターゲットを示す図である。 音声ベースの実装の態様を示す図である。 様々な可能なユーザインタフェースの特徴を示す図である。 様々な可能なユーザインタフェースの特徴を示す図である。 閾値化されたブロブを使用した、オブジェクトのセグメント化の方法を例示する図である。 閾値化されたブロブを使用した、オブジェクトのセグメント化の方法を例示する図である。 他の例示的ユーザインタフェースの特徴を示す図である。 他の例示的ユーザインタフェースの特徴を示す図である。 ユーザインタフェースにおけるレーダーの特徴を示す図である。 ユーザインタフェースにおけるレーダーの特徴を示す図である。 他のユーザインタフェース技術を詳述する役目を果たす図である。 センサ関連システムの宣言的な構成に関連付けられた特徴を例示する図である。 センサ関連システムの宣言的な構成に関連付けられた特徴を例示する図である。 センサ関連システムの宣言的な構成に関連付けられた特徴を例示する図である。 センサ関連システムの宣言的な構成に関連付けられた特徴を例示する図である。 センサ関連システムの宣言的な構成に関連付けられた特徴を例示する図である。 センサ関連システムの宣言的な構成に関連付けられた特徴を例示する図である。

詳細な説明

多くの点で、本開示の主題は、コンピュータデバイスを使用して、ユーザが自分の環境とインタラクトすることを可能にする際に、有用な技術と見なされうる。この幅広い範囲により、開示された技術は、無数の応用例によく適するようになる。

本開示で詳述される広い範囲及び様々な主題のため、順序正しい提示を達成することは困難である。以下で明らかになるように、以下で提示される題目別のセクションの多くは、他のセクションに基づき、また、他のセクションの基礎をなす。やむを得ず、そのため、様々なセクションが幾分任意の順序で提示される。各セクションからの一般的原理及び特定の詳細は共に、他のセクションにおいても応用されることを理解されたい。本開示の長さが収拾のつかないほどに膨れ上がることを防ぐため（簡潔さは、特に特許明細書において、常に有益である）、異なるセクションの特徴の様々な並べ換え及び組み合わせは、網羅的に詳述されるとは限らない。本発明者は、そのような組み合わせ／並べ換えを明示的に教示することを意図するが、実際には、詳述された総合が、そのような教示に従ってシステムを最終的に実装する者に委ねられることを必要とする。

また、ここで詳述される技術は、以前に引用された特許出願で開示された技術に基づき、これらの技術を拡張することにも留意されたい。読者はしたがって、これらの文書へと導かれ、これらの文書は、本技術が適用されることを出願人が意図する構成を詳述し、本開示を技術的に補うものである。
認知、中抜き検索（Ｄｉｓｉｎｔｅｒｍｅｄｉａｔｅｄ Ｓｅａｒｃｈ）

携帯電話など、モバイルデバイスは、単なる通信ツールというより、認知ツールになりつつある。一態様では、認知を、人にその人の環境について知らせるアクティビティと見なすことができる。認知アクションには、以下が含まれうる。
・・感覚入力に基づいて特徴を感知すること、
・・形式を感知すること（例えば、オーケストレートされた構造を決定すること）、
・・外部構造及び関係を決定するなど、関連付け、
・・問題を定義すること、
・・問題解決状況を定義すること（例えば、そのテキスト：自分に何ができるか？答え．それを読む）、
・・ソリューションのオプションを決定すること、
・・アクション及び応答を開始すること、
・・・識別は一般に、適切な応答の決定における最初の必須のステップである。

視覚及び聴覚モバイルデバイスは、人にそれらの環境について知らせることに関与するそれらの処理を支援するツールである。

モバイルデバイスは、驚くべき速さで急増している。多くの国々では（フィンランド、スウェーデン、ノルウェイ、ロシア、イタリア及び英国を含む）、伝えられるところによれば、人々よりも携帯電話の方が多い。ＧＳＭアソシエーション（ＧＳＭ Ａｓｓｏｃｉａｔｉｏｎ）によれば、およそ４０億台ものＧＳＭ及び３Ｇ電話が現在使われている。国際電気通信連合は、２００９年終わりに４９億の移動セルラ加入を見積もっている。アップグレードサイクルはとても短く、デバイスは、平均して２４カ月に一度交換される。

したがって、モバイルデバイスは、巨額の投資の中心となっている。グーグル（Ｇｏｏｇｌｅ）、マイクロソフト（Ｍｉｃｒｏｓｏｆｔ）、アップル（Ａｐｐｌｅ）及びノキア（Ｎｏｋｉａ）など、業界の巨大企業は、その巨大市場がこれらのデバイスの機能性の拡張にかかっていると認識しており、研究開発に相応の多額の投資を行っている。そのような広範囲に及ぶ、熱心な取組みを考えると、本明細書で詳述された技術を業界の巨大企業が開発できないことは、そのような技術の発明性の証しである。

ビジュアルクエリなど、「中抜き検索」は、次世代のモバイルデバイスのための、最も人を引き付けるアプリケーションの１つであると考えられる。

一態様では、中抜き検索を、検索の開始における人間の役割を減らす（又は、なくすことさえある）検索と見なすことができる。例えば、スマートフォンは常に、視覚的環境を解析中であり、明示的にクエリを受けることなく、解釈及び関連情報を提供中であることがある。

別の態様では、中抜き検索を、グーグルを超えた次のステップと見なすことができる。グーグルは、公共のウェブ上のテキスト情報のすべてを編成するために、モノリシックな大規模システムを構築した。しかし、ビジュアルの世界は、グーグルにとってさえ大き過ぎ、複雑過ぎて、支配できるものではない。無数の関係者が、−より大きい役割であれ、より小さい役割であれ、特化された役割を各々が果たしながら−関与しなければならない。「すべてを支配するための１つの検索エンジン」は、存在しないことになるであろう。（無数の関係者の潜在的な関与を考えると、おそらく、代わりの名前は「超介在型検索（ｈｙｐｅｒｉｎｔｅｒｍｅｄｉａｔｅｄ ｓｅａｒｃｈ）」となるであろう。）

前述の考察から明らかになるように、本発明者は、視覚的検索が、具体的には、その態様のうちあるものにおいて極めて複雑であり、満足のいく体験を生じるために、非常にインタラクティブなモバイル画面ユーザインタフェースによってサポートされた、密接なデバイス／クラウドオーケストレーションを必要とすると考える。ユーザガイダンス及びインタラクションは、−少なくとも最初は−結果の有用性の基本となる。ローカルデバイス上では、主要な課題は、目が回るような、ずらりと並んだ要求に対して、不十分なＣＰＵ／メモリ／チャネル／電力リソースを配置することである。クラウド側では、オークションベースのサービスモデルが現れて、この技術の発展を促進すると予期される。最初に、中抜き検索が、閉じられたシステムの形式で商用化されるようになるが、盛んになるために、拡張可能なオープンプラットフォームを介するようになる。最終的に、最も成功する技術は、最高の価値をユーザに提供するために配置されるものとなる。
アーキテクチャ図

図１は、本技術のある原理を用いる実施形態を、直感的なコンピューティングプラットフォーム又はＩＣＰのアーキテクチャ図で示す。（機能性の、ブロックへの分割は、幾分任意であることを理解されたい。実際の実装は、描かれ、記載された特定の編成に従わないことがある。）

ＩＣＰボーブル＆空間モデル（ＩＣＰ Ｂａｕｂｌｅｓ ＆ Ｓｐａｔｉａｌ Ｍｏｄｅｌ）コンポーネントは、視空間、表示及びそれらの関係を伴うタスクを扱う。関連のある機能の一部には、ボーブルを視覚的シーンの上にオーバーレイすることに関連した、姿勢評価、追跡、及び、オルソ補正マッピングが含まれる。

ボーブルは、一態様では、キャプチャされた画像の特徴と関連して画面上に表示される拡張現実アイコンと見なされうる。これらのボーブルは、インタラクティブになることができ、ユーザにより調整可能である（すなわち、同一のシーンを見る異なるユーザの画面上に、異なるボーブルが現れることが可能である）。

いくつかの構成では、ボーブルは、システムによる最初のかすかな認識を示すように見える。ディスプレイ上のある場所に潜在的な関心のある何か−視覚的特徴−があることを、システムが見極め始めるとき、システムはボーブルを提示する。システムがその特徴についてより多くを推定するにつれて、ボーブルのサイズ、形状、色又は明るさが変化し−ボーブルをより目立つようにし、及び／又は、より多くの情報を与えるものにすることができる。ユーザがボーブルをタップし−その視覚的特徴への関心を表す場合、システムのリソースマネージャ（例えば、ＩＣＰステートマシン〔ＩＣＰ Ｓｔａｔｅ Ｍａｃｈｉｎｅ〕）は、他の領域よりも画像のその特徴の解析に、より多くの処理リソースを不均衡に充てることができる。（ユーザのタップについての情報はまた、特徴又はボーブルについての情報と共にデータストアに格納されるので、その特徴へのユーザの関心を、次回はより速く又は自動的に認識することができるようになる。）

ボーブルが最初に現れるとき、視覚的特徴が、例えば、やや明るい点、又はエッジの輪郭を伴う何かなど、視覚的に個別のエンティティを構成するように見えることを除いて、視覚的特徴について何も知られていないことがある。このレベルの理解では、小さい星又は円など、汎用ボーブル（おそらく「プロトボーブル〔ｐｒｏｔｏ−ｂａｕｂｌｅ〕」と呼ばれる）を表示することができる。より多くの情報がその特徴について推定される（その特徴が、顔又はバーコード又は葉のように見える）につれて、次いで、その理解が増したことを反映するボーブルグラフィックを表示することができる。

ボーブルは、性質的に商用であってもよい。いくつかの環境では、表示画面は、ユーザの注目をめぐって競い合う、複数の異なるボーブルであふれうる。この表示画面に取り組むため、どのくらい多くの情報が画面上に提示されるかをスロットルする、ユーザにより設定可能なコントロール−視覚的冗長コントロール−がありうる。加えて、又は別法として、ユーザが商用ボーブル対非商用ボーブルの最大比を確立することを可能にする、コントロールを設けることができる。（グーグルのように、システムからの生データの集まりは、広告をユーザに提示するよりも、長期的により価値があると判明することがある。）

表示のために選択されるボーブルは、現在のコンテキストの様々な次元に基づいて、ユーザに最高の価値を供給するものであることが望ましい。場合によっては、−商用及び非商用の両方の−ボーブルが、クラウド内で実施されるオークション処理に基づいて選択されうる。表示されたボーブルの最終名簿は、ユーザによって影響を受けることがある。ユーザがインタラクトするものは、明らかなお気に入りとなり、将来に表示される可能性がより高く、ユーザが繰り返して無視し、又は捨てるものは、再度示されないことがある。

別のＧＵＩコントロールを、ユーザの現在の関心（例えば、観光、買い物、ハイキング、懇親会、ナビゲート、食べることなど）を示すために設けることができ、ボーブルの提示をそれに応じて調整することができる。

いくつかの点で、古い車のラジオ−左にボリュームつまみ、及び、右にチューニングつまみがある−の類比が適当である。ボリュームつまみは、画面の忙しさ（視覚的冗長）に対する、ユーザにより設定可能なコントロールに対応する。チューニングつまみは、個々に又は共に、何のタイプのコンテンツがユーザに現在関連があるか、例えば、ユーザの可能性が高い意図を示す、センサ、格納されたデータ、及び、ユーザ入力に対応する。

例示されたＩＣＰボーブル＆空間モデルコンポーネントは、関連機能を供給する既存のソフトウェアツールから借りるか、又はそれに基づいて構築されてもよい。１つは、ＡＲＴｏｏｌＫｉｔ−Ｈｕｍａｎ Ｉｎｔｅｒｆａｃｅ Ｔｅｃｈｎｏｌｏｇｙ Ｌａｂ ａｔ ｔｈｅ Ｕｎｉｖｅｒｓｉｔｙ ｏｆ Ｗａｓｈｉｎｇｔｏｎ（ｈｉｔｌ＜ｄｏｔ＞Ｗａｓｈｉｎｇｔｏｎ＜ｄｏｔ＞ｅｄｕ／ａｒｔｏｏｌｋｉｔ／）の研究から生まれた、自由に使用可能なソフトウェアのセットであり、現在はシアトルのＡＲ Ｔｏｏｌｗｏｒｋｓ，Ｉｎｃ．（ａｒｔｏｏｌｗｏｒｋｓ＜ｄｏｔ＞ｃｏｍ）によってさらに開発されている。もう１つの関連するツールのセットは、ＭＶ Ｔｏｏｌｓ−普及しているマシンビジョン機能のライブラリである。

図１は、少数のみの認識エージェント（ＲＡ）を示し、数十又は数百ものＲＡが存在することがある。ＲＡは、特徴及び形式抽出を行い、且つ、センサデータ（例えば、ピクセル）、及び／又は、派生物（例えば、「キーベクトル」データ、米国特許出願公開第２０１０／００４８２４２号、国際公開第１０／０２２１８５号パンフレットを参照）に基づいて、関連付け及び識別を支援する、コンポーネントを含む。ＲＡは一般に、使用可能情報を認識し、そこから意味を抽出する助けとなる。一態様では、いくつかのＲＡを、特化された検索エンジンになぞらえることができる。あるＲＡはバーコードを検索することができ、あるＲＡは顔を検索することができる、などとなる。（ＲＡは、他のタイプのものであってもよく、例えば、異なる処理タスクのサービスにおいて、音声情報を処理する、ＧＰＳ及び磁力計データを提供するなどである。）

ＲＡは、−セッション及び環境のニーズに基づいて−ローカルで、リモートで、又は双方で実行することができる。ＲＡは、デバイス／クラウドによりネゴシエートされたビジネスルールによって、リモートでロードされ、操作されうる。ＲＡは一般に、入力として、共有されたデータ構造、ＩＣＰブラックボード（後述される）から、キーベクトルデータを取る。ＲＡは、ソリューションツリーに従って、ＩＣＰステートマシンによって構成される基本サービスを提供することができる。

ボーブルのように、ＲＡを伴う競合の態様があることがある。すなわち、重複する機能性が、いくつかの異なるプロバイダからのいくつかの異なるＲＡによって提供されうる。特定のコンテキストで特定のデバイスにおいてどのＲＡを使用するべきかの選択は、ユーザ選択、サードパーティ再検討、コスト、システム制約、出力データの再利用可能性、及び／又は、他の基準の相関的要素でありうる。最終的に、ダーウィン的なふるい分け（Ｄａｒｗｉｎｉａｎ ｗｉｎｎｏｗｉｎｇ）が起こることがあり、ユーザのニーズを最もよく満たすＲＡが優勢となる。

スマートフォンベンダは最初に、電話にデフォルトセットのＲＡを備えることができる。いくつかのベンダは、ＲＡ選択の制御の維持−囲い込み手法−を行うことがあるが、他のベンダは、ユーザによる異なるＲＡの発見を促すことがある。アップルＡｐｐ Ｓｔｏｒｅなど、オンライン市場は、ＲＡ市場を供給するように進化することができる。異なる顧客グループ及びニーズを満たすＲＡのパッケージが出現することがあり、例えば、いくつかのパッケージは、視力が不十分な人々を支援するためのものであり（例えば、テキストから音声への認識など、視力補助ＲＡがロードされる）、いくつかのパッケージは、最も単純なユーザインタフェースを望む人々に応えるものであり（例えば、大きいボタンコントロール、専門用語でない説明文）、いくつかのパッケージは、アウトドアのファンに応えるものであり（例えば、鳥の鳴き声識別ＲＡ、木の葉識別ＲＡを含む）、いくつかのパッケージは、世界を旅する人々に応えるものである（例えば、言語翻訳機能、及び、場所に基づいた旅行者サービスを含む）、などとなる。システムは、ユーザがデバイスに、異なるそのようなＲＡのセットを異なる時間にロードさせることができる、メニューを提供してもよい。

ＲＡの一部又は全部は、状況に応じて、クラウドに機能性をプッシュしてもよい。例えば、クラウドへの高速データ接続が使用可能であり、デバイスバッテリが完全な消耗に近付きつつある場合（又は、ユーザがゲームをプレイ中であり−デバイスのＣＰＵ／ＧＰＵリソースの大部分を消費中である場合）、ローカルＲＡは、ほんのわずかのタスクをローカルで行うのみにして（例えば、アドミニストレーション）、残りをクラウドの対応物へ、クラウドで実行するために送ってもよい。

他のところで詳述するように、ＲＡにとって使用可能なプロセッサ時間及び他のリソースを動的な方法で制御し−より多くのリソースを、それに値するように思われるＲＡに割り振ることができる。ＩＣＰステートマシンのディスパッチャコンポーネントは、そのような監督を処理することができる。ＩＣＰステートマシンはまた、ＲＡ動作をローカルＲＡコンポーネントとクラウド対応物の間で分割することを管理することもできる。

ＩＣＰステートマシンは、アンドロイド（Ａｎｄｒｏｉｄ）オープンソースオペレーティングシステム（例えば、ｄｅｖｅｌｏｐｅｒ＜ｄｏｔ＞ａｎｄｒｏｉｄ＜ｄｏｔ＞ｃｏｍ／ｇｕｉｄｅ／ｔｏｐｉｃｓ／ｆｕｎｄａｍｅｎｔａｌｓ．ｈｔｍｌ）から、並びに、アイフォン（ｉＰｈｏｎｅ）及びシンビアン（Ｓｙｍｂｉａｎ）ＳＤＫからモデリングされた態様を用いることができる。

図１の右の方は、クラウド＆ビジネスルール（Ｃｌｏｕｄ ＆ Ｂｕｓｉｎｅｓｓ Ｒｕｌｅｓ）コンポーネントであり、このコンポーネントは、クラウド関連処理へのインタフェースとしての機能を果たす。このコンポーネントはまた、クラウドオークションのためのアドミニストレーションを行い−複数のクラウドサービスプロバイダのうちどれがあるタスクを行うかを決定することもできる。このコンポーネントは、サービスプロバイダインタフェース（ＳＰＩ）を介してクラウドへ通信し、ＳＰＩは、本質的に任意の通信チャネル及びプロトコルを利用することができる。

個々のルールは異なるようになるが、この態様のアーキテクチャのためのモデルとして使用可能である例示的ルールベースシステムには、Ｍｏｖｉｅｌａｂｓコンテントルールズアンドライツ（Ｃｏｎｔｅｎｔ Ｒｕｌｅｓ ａｎｄ Ｒｉｇｈｔｓ）構成（例えば、ｍｏｖｉｅｌａｂｓ＜ｄｏｔ＞ｃｏｍ／ＣＲＲ／）、及び、ＣＮＲＩハンドルシステム（Ｈａｎｄｌｅ Ｓｙｓｔｅｍ）（例えば、ｈａｎｄｌｅ＜ｄｏｔ＞ｎｅｔ／）が含まれる。

左の方は、コンテキストエンジンであり、システムによって使用されるコンテキスト情報（例えば、現在地はどこか？ユーザが何のアクションを過去１分間に行ったか？過去１時間では？など）を提供し、処理するものである。コンテキストコンポーネントは、インタフェースを介してリモートデータにリンクすることができる。リモートデータには、任意の外部情報、例えば、類似の休暇の目的地など、関係するアクティビティ、同等者、ソーシャルネットワーク、消費されたコンテンツ、地理−本ユーザを他者に関係付けることができるいかなるものも−が含まれうる。（デバイスが音楽認識エージェントを含む場合、デバイスは、ユーザのフェイスブック友達のプレイリストを調べてもよい。デバイスは、この情報を使用して、ユーザが聴く音楽のモデルを精緻化し−また、例えば、何のオンラインラジオ局にユーザがサブスクライブされているか、などについての知識を考慮してもよい）。

コンテキストエンジン及びクラウド＆ビジネスルールコンポーネントは、残存的なクラウド側の対応物を有することができる。すなわち、この機能性を、ローカルの部分、及び、クラウド内の対応物に分散させることができる。

クラウドベースのインタラクションは、グーグルのＡｐｐエンジン（Ａｐｐ Ｅｎｇｉｎｅ）（例えば、ｃｏｄｅ＜ｄｏｔ＞Ｇｏｏｇｌｅ＜ｄｏｔ＞ｃｏｍ／ａｐｐｅｎｇｉｎｅ／）、及び、アマゾンのエラスティックコンピュートクラウド（Ｅｌａｓｔｉｃ Ｃｏｍｐｕｔｅ Ｃｌｏｕｄ）（例えば、ａｗｓ＜ｄｏｔ＞ａｍａｚｏｎ＜ｄｏｔ＞ｃｏｍ／ｅｃ２／）による、関連クラウドコンピューティングのために既に発行されているツール及びソフトウェアの多くを利用することができる。

図１の下部は、ブラックボード及びクラスタリングエンジン（Ｂｌａｃｋｂｏａｒｄ ａｎｄ Ｃｌｕｓｔｅｒｉｎｇ Ｅｎｇｉｎｅ）である。

ブラックボードは、共有されたデータリポジトリとして、且つ、プロセス間通信のための手段として−複数の認識エージェントが特徴オブジェクト（例えば、キーベクトル）を観察し、それらに寄与し、且つ協調できるようにすることを含む、様々な機能をサービスすることができる。ブラックボードは、システムのためのデータモデルとしての役目を果たすことができ、例えば、視覚表現を維持して、複数の認識エージェントに渡る特徴抽出及び関連付けを支援し、時間的特徴／形式抽出のためのキャッシング及びサポートを提供し、メモリ管理及びごみサービスを提供する。ブラックボードはまた、特徴クラスファクトリとしての役目を果たし、特徴オブジェクトインスタンス化（作成及び破壊、アクセス制御、通知、キーベクトルの形式におけるシリアル化など）を提供することもできる。

ブラックボード機能性は、オープンソースブラックボードソフトウェアＧＢＢｏｐｅｎ（ｇｂｂｏｐｅｎ＜ｄｏｔ＞ｏｒｇ）を利用することができる。Ｊａｖａ仮想マシン上で実行する（且つ、ＪａｖａＳｃｒｉｐｔによるスクリプティングをサポートする）、もう１つのオープンソース実装は、ブラックボードイベントプロセッサ（Ｂｌａｃｋｂｏａｒｄ Ｅｖｅｎｔ Ｐｒｏｃｅｓｓｏｒ）（ｃｏｄｅ＜ｄｏｔ＞Ｇｏｏｇｌｅ＜ｄｏｔ＞ｃｏｍ／ｐ／ｂｌａｃｋｂｏａｒｄｅｖｅｎｔｐｒｏｃｅｓｓｏｒ／）である。

ブラックボード構成物は、Ｄａｎｉｅｌ Ｃｏｒｋｉｌｌによって普及された。例えば、Ｃｏｒｋｉｌｌ、Ｃｏｌｌａｂｏｒａｔｉｎｇ Ｓｏｆｔｗａｒｅ−Ｂｌａｃｋｂｏａｒｄ ａｎｄ Ｍｕｌｔｉ−Ａｇｅｎｔ Ｓｙｓｔｅｍｓ ＆ ｔｈｅ Ｆｕｔｕｒｅ、Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｌｉｓｐ Ｃｏｎｆｅｒｅｎｃｅ、２００３年を参照されたい。しかし、本技術の実装は、この概念のいかなる特定の形式も必要としない。

クラスタリングエンジンは、コンテンツデータの項目（例えば、ピクセル）を共に、例えば、キーベクトルでグループ化する。キーベクトルは、一態様では、テキストキーワードに対する視聴覚的な対応物−関連結果を取得するために処理へ入力される要素のグループ化−に、おおよそなぞらえることができる。

クラスタリングは、画像データから新しい特徴−点、ベクトル、画像領域などのリストとして表現されうる特徴を生成する、低レベルの処理によって行うことができる。（認識動作は一般に、関連特徴のクラスタを探し、その理由は、それらが関心のあるオブジェクトを潜在的に表現するからである。）これらの特徴を、ブラックボードに投稿することができる。（より高いレベルの処理−認識エージェントの一部を形成することができる−はまた、新しい特徴又は関心のあるオブジェクトを生成し、且つ、それらをブラックボードへ投稿することもできる。）

ここでもまた、以前に参照されたＡＲＴｏｏｌＫｉｔは、この機能性のあるもののための基礎を提供することができる。

前述の態様は、本明細書の以下及び他のセクションでさらに詳述される。
ローカルデバイス＆クラウド処理

図２によって概念的に表されるように、中抜き検索は、ローカルデバイス及びクラウドの強度／属性に依拠するべきである。（クラウド「パイプ」もまた、例えば、帯域幅及びコストを含む制約によって、混合の要素として入る。）

ローカルデバイスとクラウドの間の機能性の特定の配分は、実装毎に変わる。１つの特定の実装では、機能性は以下のように分割される。
・ローカル機能性：
・・コンテキスト：
・・・ユーザのアイデンティティ、プリファレンス、履歴
・・・コンテキストメタデータ処理（例えば、自分はどこにいるか？自分はどの方向を向いているか？）
・・ＵＩ：
・・・画面上のレンダリング＆フィードバック（タッチ、ボタン、可聴、近接など）
・・全体的な向き：
・・・グローバルサンプリング、多くの構文解析のないカテゴリ化
・・・データ配置及び特徴抽出
・・・列挙された特徴のパッチワーク
・・・フレーム間の集まり、時間的特徴のシーケンス
・・クラウドセッション管理：
・・・認識エージェントによる登録、関連付け＆二重セッション動作
・・認識エージェント管理：
・・・特定の機能性を有するＤＬＬと同種−特定のアイデンティティ及び形式を認識する
・・・リソース状態及び検出状態スケーラビリティ
・・・認識エージェントによって提供されたサービスの構成
・・・開発及びライセンシングプラットフォーム
・クラウドの役割には、例えば、以下が含まれうる。
・・記録されたクラウド側サービスと通信する
・・サービスのためのオークションを管理且つ実行する（及び／又は、デバイス上のオークションを監査する）
・・例えば、アイデンティティの７原則（マイクロソフトのＫｉｍ Ｃａｍｅｒｏｎを参照）に関連付けられたサービスを提供することによって、ユーザ及びオブジェクトのアイデンティティを提供／サポートする
・・・ユーザコントロール及び同意。技術的アイデンティティシステムは、ユーザの同意を有してのみ、ユーザを識別する情報を明かさなければならない。
・・・制約された使用のための最小限の開示。最小量の識別情報を開示し、その使用を最良に制限するソリューションは、最も安定した長期のソリューションである。
・・・正当なパーティ。デジタルアイデンティティシステムは、識別情報の開示が、所与のアイデンティティ関係において必要且つ正当な立場を有するパーティに限定されるように、設計されなければならない。
・・・指図されたアイデンティティ。ユニバーサルアイデンティティシステムは、公共のエンティティによる使用のための「全方向性」の識別子、及び、プライベートエンティティによる使用のための「一方向性」の識別子を共にサポートし、こうして、相関ハンドルの不要なリリースを防ぎながら、発見を容易にしなければならない。
・・・オペレータ及び技術の複数性。ユニバーサルアイデンティティシステムは、複数のアイデンティティプロバイダによって実行された複数のアイデンティティ技術の相互作用を伝え、可能にしなければならない。
・・・人間の統合。ユニバーサルアイデンティティメタシステムは、人間のユーザを、曖昧でないマン／マシン通信機構を通じて統合された分散システムのコンポーネントとなるように定義し、アイデンティティ攻撃からの保護を提供しなければならない。
・・・複数のコンテキストに渡って一貫した体験。統一アイデンティティメタシステムは、そのユーザに、複数のオペレータ及び技術を通じて複数のコンテキストの分離を可能にしながら、簡単で一貫した体験を保証しなければならない。
・・ドメインの構成物を作成且つ実施する
・・・課金、地理、デバイス、コンテンツ
・・ユーザにより開始されたセッション内で、認識エージェントを実行且つ制御する
・・リモート認識エージェント（例えば、プロビジョニング、認証、取り消しなど）を管理する
・・ビジネスルール及びセッション管理などに注意を払う
・クラウドは、中抜き検索を容易にするのみでなく、しばしば、検索先でもある（結果が一般にセンサデータのみに基づいて提供されうる、ＯＣＲなどの場合を除く）。
・ここで詳述される技術は、以下を含む多様なソースからインスピレーションを受ける。
・・生物学的：人間の視覚系＆より高いレベルの認知モデルとの相似
・・信号処理：センサフュージョン
・・コンピュータビジョン：画像処理演算（空間＆周波数ドメイン）
・・コンピュータ科学：サービスの構成＆リソース管理、パラレルコンピューティング
・・ロボット工学：自律的インタラクションのためのソフトウェアモデル（プラン（ＰＬＡＮ）、ガゼボ（Ｇａｚｅｂｏ）など）
・・ＡＩ：マッチ／熟慮／実行モデル、ブラックボード、プランニングモデルなど
・・経済学：オークションモデル（セカンドプライスが勝つ．．．）
・・ＤＲＭ：権利表現言語＆ビジネスルールエンジン
・・人的要因：ＵＩ、拡張現実、
・・モバイル価値連鎖構造：ステークホルダ、ビジネスモデル、ポリシーなど
・・行動科学：ソーシャルネットワーク、クラウドソーシング／フォークソノミー、
・・センサ設計：磁力計、近接、ＧＰＳ、音声、光学（拡張被写界深度など）

図３は、例示的認知処理の様々な機能を、−システムモジュール及びデータ構造に関して−異なる態様の機能性とマッピングする。したがって、例えば、直観的コンピューティングプラットフォーム（Ｉｎｔｕｉｔｉｖｅ Ｃｏｍｐｕｔｉｎｇ Ｐｌａｔｆｏｒｍ）（ＩＣＰ）コンテキストエンジン（Ｃｏｎｔｅｘｔ Ｅｎｇｉｎｅ）は、関連付け、問題解決状況、ソリューションの決定、アクション／応答の開始、及び、管理の認知処理を、システムのコンテキスト態様に適用する。すなわち、ＩＣＰコンテキストエンジンは、履歴などに基づいてユーザの意図を決定し、そのような情報を使用して、システム動作の態様に情報を与えるように試みる。同様に、ＩＣＰボーブル＆空間モデルコンポーネントは、情報をユーザに提示すること、及び、ユーザから入力を受信することに関連して、同じ処理の多くを供給する。

ＩＣＰブラックボード及びキーベクトルは、他の目的の中でも、システムの向き適応の態様と関連して使用されるデータ構造である。

ＩＣＰステートマシン＆認識エージェント管理（Ｒｅｃｏｇｎｉｔｉｏｎ Ａｇｅｎｔ Ｍａｎａｇｅｍｅｎｔ）は、認識エージェントと共に、認識処理、及び、認識に関連付けられたサービスの構成を処理する。ステートマシンは典型的には、リアルタイムオペレーティングシステムである。（そのような処理はまた、例えば、ＩＣＰブラックボード及びキーベクトルをも伴う。）

クラウド管理＆ビジネスルール（Ｃｌｏｕｄ Ｍａｎａｇｅｍｅｎｔ ＆ Ｂｕｓｉｎｅｓｓ Ｒｕｌｅｓ）は、クラウド登録、関連付け、及び、セッション動作を扱い−認識エージェント及び他のシステムコンポーネントと、クラウドの間のインタフェースを提供する。
ボーブルをサポートするためのローカル機能性

ボーブルに関するソフトウェアコンポーネントのうち１つ又は複数によって提供される機能のいくつかには、以下が含まれうる。
・・ユーザのプロファイル、ユーザの一般的関心、ユーザの現在のコンテキスト内のユーザの現在の特定の関心を理解する。
・・ユーザ入力に応答する。
・・グローバルな画像処理ライブラリの選択されたモジュールを使用して、ストリーミングフレームの重複するシーン領域を、空間的に構文解析且つ「オブジェクト化（ｏｂｊｅｃｔ−ｉｆｙ）」する
・・・シンボル（ピクセル解析結果、ＩＤ、属性など）の階層の層を、プロト領域に添付する、プロトクエリの「キーベクトル」としてパッケージ化する。
・・ユーザにより設定された視覚的冗長レベル及びグローバルシーン理解に基づいて、ボーブルプリミティブ表示機能／正射影をセットアップする。
・・キーベクトルを適切なローカル／クラウドアドレスに経路指定する
・・・一番上にリストされた黒点からの「フルコンテキスト」メタデータが添付される。
・・・ローカルの場合：キーベクトルを処理し、クエリ結果を出す。
・・キーベクトルクエリ結果を収集し、適切なボーブルをユーザ画面へ活性化／ブリット（ｂｌｉｔ）する
・・・ボーブルは、「完全且つ十分にアクション可能」であることができ、又は、「中間的な状態」を例示し、よって、より深いクエリのドリリング又はクエリ精緻化のためのユーザインタラクションを予期することができる。
直観的コンピューティングプラットフォーム（ＩＣＰ）ボーブル

サービス及び高価値ボーブル結果を提供するためのクラウド内の競合は、サプライヤにとって優越及びビジネスの成功を促進するべきである。基本的品質の非商用サービスによりクラウドオークションの場所を確立することは、この市場を促進する助けとなることがある。

ユーザは、ユーザの意図及び実際のクエリに応じて調整された商用侵入による、最高品質及び最も関連のあるボーブルを望む（且つ、求めるはずである）。

一方では、スクリーンリアルエステート（ｓｃｒｅｅｎ ｒｅａｌ ｅｓｔａｔｅ）の買い手を２つのクラスに分割することができ、すなわち、非商用ボーブル及びセッションを進んで提供する買い手（例えば、ブランディングのために顧客を獲得することを目標とする）、及び、スクリーンリアルエステートを「制限」し（例えば、それを見るユーザ（ら）の人口統計学的な意味において）、そのスクリーンリアルエステートが表す商業的な機会に単に入札することを望む買い手である。

グーグルは、もちろん、その「オークション処理へ、スポンサー付きハイパーリンク提示への、キーワード」構成を収益化することに基づいて、巨大なビジネスを構築している。しかし、視覚的検索では、単一のエンティティが処理のすべての態様を同様に支配するようになるということは、起こりそうもないように思われる。むしろ、中間層の企業がユーザクエリ／スクリーンリアルエステートの買い手のマッチメイキングを支援するようになることは、起こりそうに思われる。

ユーザインタフェースは、ユーザが関心のないボーブルを捨てる−関心のないボーブルを画面から除去する（且つ、その視覚的特徴に関するさらなる情報の開発に充てられた、あらゆる進行中の認識エージェント処理を終了する）−ことができる、コントロールを含んでもよい。捨てられるボーブルについての情報を、データストアに記録することができ、この情報を使用して、ユーザのプロファイル情報を拡張することができる。ユーザがスターバックスコーヒー店及び別個のコーヒー店のボーブルを捨てる場合、システムは、すべてのコーヒー店へのユーザの関心の欠如を推論するようになりうる。ユーザがスターバックスコーヒー店のみのボーブルを捨てる場合、ユーザの関心のより狭い欠如を見極めることができる。今後のボーブルの表示は、データストアを調べることができ、以前に捨てられた（又は、繰り返し捨てられた）ボーブルは、再び正常には表示されないことがある。

同様に、ユーザがボーブルをタップする−関心を示す−場合、そのタイプ又はクラスのボーブル（例えば、スターバックス又はコーヒー店）には、どのボーブルを（多数の候補の中で）表示するべきかを評価する際に、今後はより高いスコアを与えることができる。

ボーブルとのユーザインタラクションについての過去にあった情報を、現在のコンテキスト情報と共に使用することができる。例えば、ユーザが午後のコーヒー店に関するボーブルを捨てるが、午前のものは捨てない場合、システムは、午前のコーヒー関連ボーブルを提示し続けてもよい。

ビジュアルクエリ問題に固有の複雑性は、多数のボーブルが中間的なもの、又は、プロトボーブルクラスとなり−ユーザを促し、導いて、人間レベルのフィルタリング、インタラクション、ガイダンス及び、クエリ処理へのより深いナビゲーションを提供することを暗示する。あるシーンにおけるボーブル表示の進行は、したがって、リアルタイムの人間の入力、並びに、他の要因の相関的要素となりうる。

ユーザがボーブルをタップするか、又は、他の方法でボーブルへの関心を表すとき、このアクションは通常、ボーブルの主題に関するセッションを開始する。セッションの詳細は、個々のボーブルによって決まるようになる。いくつかのセッションは、性質的に商用であってもよい（例えば、スターバックスボーブルをタップすると、スターバックス製品の１ドル値引きの電子クーポンが生じてもよい）。他のセッションは、情報を提供するものであってもよい（例えば、ある像に関連付けられたボーブルをタップすると、その像又は彫刻家についてのウィキペディア（Ｗｉｋｉｐｅｄｉａ）エントリの提示につながってもよい）。キャプチャされた画像内の顔の認識を示すボーブルは、様々な動作（例えば、リンクトイン（ＬｉｎｋｅｄＩｎ）など、ソーシャルネットワークからその人のプロファイルを提示する、そのピクチャの顔の注釈付きのコピーを、認識された人又はユーザのフェイスブックページに投稿する、など）につながるかもしれない。時として、ボーブルをタップすると、いくつかの動作のメニューが呼び出され、そこからユーザが所望のアクションを選択することができる。

ボーブルをタップすることは、そのボーブルにとって、他のボーブルを超えたある種の勝利を表す。タップされたボーブルが性質的に商用である場合、そのボーブルは、ユーザの注目をめぐる、且つ、ビューアの画面上のリアルエステートの一時的な使用をめぐる争いに勝っている。場合によっては、関連付けられた支払いが−おそらくユーザに対して、ことによると別の相手（例えば、顧客をめぐる「勝利」を確保したエンティティ）に対して−行われてもよい。

タップされたボーブルはまた、プリファレンスの投票−他のボーブルを超えた、そのボーブルへの、可能なダーウィン的な承諾（Ｄａｒｗｉｎｉａｎ ｎｏｄ）−をも表す。今後、本ユーザに表示するためのボーブルの選択に影響を与えることに加えて、このような肯定はまた、他のユーザに表示するためのボーブルの選択にも影響を与えることができる。これは、うまくいけば、ボーブルプロバイダを、ユーザサービスでの優越に向かう好循環に導くようになる。（ユーザのお気に入りのみが進行中の放送時間を得た場合、いくつの現在のテレビコマーシャルが生き残るだろうか？）

上記に示したように、所与の画像シーンは、多数のボーブル−画面が有用に含むことができる、より多数のボーブルであることが多い−の表示の機会を提供することがある。この多数の可能性を、扱いやすいセットに絞り込む処理は、ユーザから開始することができる。

以前に示されたような冗長コントロール−単に、どのくらい盛んに画面がボーブルでオーバーレイされることをユーザが望むかについての基礎を設定する−を始めとして、様々な異なるユーザ入力を用いることができる。他のコントロールは、話題別のプリファレンス、及び、指定された商用−非商用の混合を示してもよい。

もう１つの次元の制御は、画面の個々のエリアへのユーザの関心のリアルタイム表現であり、例えば、それについてユーザがさらに知るか、又は他の方法でインタラクトすることを望む、特徴を示す。この関心は、そのような特徴上にオーバーレイされたプロトボーブルをタップすることによって示すことができるが、プロトボーブルは必須ではない（例えば、ユーザは単に、画面の区別されていないエリアをタップして、プロセッサの注意を画像フレームのその部分に集中させてもよい）。

追加のユーザ入力は、コンテキスト的であり−他のところで詳述される多数の色々な情報（例えば、計算コンテキスト、物理的コンテキスト、ユーザコンテキスト、物理的コンテキスト、時間的コンテキスト、及び、過去にあったコンテキスト）が含まれる。

ボーブル選択処理に入力される外部データには、サードパーティインタラクションに関する情報−何のボーブルとインタラクトすることを他者が選んだか？−が含まれうる。この要因を与えられた重みは、他のユーザ（複数可）と本ユーザの間の距離測定、及び、それらのコンテキストと本コンテキストの間の距離によって決まる可能性がある。例えば、類似のコンテキストの状況で、本ユーザの社会的な友達のアクションによって明示されたボーブルプリファレンスに、異なる状況での他人のアクションよりもはるかに大きい重みを与えることができる。

もう１つの外部要因は、商業的に考慮すべき点である可能性があり、例えば、サードパーティが、少しのユーザのスクリーンリアルエステートを少しの間に借りるために、いくら（及び、場合によっては誰に）進んで支払うか、である。上述のように、そのような問題は、クラウドベースのオークション構成に要素として入ることが可能である。オークションはまた、他のユーザからの個々のボーブルの人気を考慮に入れることもできる。この態様の処理の実装では、オンライン広告リアルエステートをオークションするためのグーグル技術（例えば、Ｌｅｖｙ、Ｓｅｃｒｅｔ ｏｆ Ｇｏｏｇｌｅｎｏｍｉｃｓ：Ｄａｔａ−Ｆｕｅｌｅｄ Ｒｅｃｉｐｅ Ｂｒｅｗｓ Ｐｒｏｆｉｔａｂｉｌｉｔｙ、Ｗｉｒｅｄ Ｍａｇａｚｉｎｅ、２００９年５月２２日を参照）−一般化されたセカンドプライスオークションの変形形態−を参照することができる。出願人は、クラウドベースのオークション構成を、国際出願公開ＷＯ２０１００２２１８５において詳述した。

（要するに、そのようなクラウドベースのモデルの仮定は、クリックスルーレート（ＣＴＲ）に基づく広告モデルに類似であるということであり、エンティティは、様々な金額（金銭的及び／又は奨励金付きのサービス）を支払って、エンティティのサービスが使用されるように、及び／又は、エンティティのボーブルがユーザの画面上に現れるようにする。商用及び非商用認識エージェント（例えば、既にスターバックスのロゴを予めキャッシュしているロゴ認識エージェント）によって提供された認識サービスのための動的な市場があることが望ましい。検索により知らされた広告から教訓を得ることもでき−バランスが取れた状態は、トラフィック上で利益を得ながら、ユーザ価値を提供することである。）

一般に、これらのオークションにおける課題は、オークションの実施におけるものではなく、むしろ、関与する変数の数に適切に取り組むことにある。これらの変数には、以下が含まれる。
・・ユーザプロファイル（例えば、−ブラウザの世界ではクッキーによってなど−何が知られているかに基づいて、ベンダがボーブルを配置するために、どのくらいの額を費やすことを望むか？）
・・コスト（帯域幅、計算及び機会コストは何であるか？）、及び
・・デバイス機能（ハードウェアの設備−フラッシュ？ ＧＰＵ？ その他など、静的な点で、且つ、また、ユーザの現在の場所におけるチャネル帯域幅、デバイスの電力状態、メモリ使用量、その他など、動的状態の点でも）

（いくつかの実装では、ボーブルプロモータは、裕福なユーザが使用中であるデバイスのタイプによって示されるような、裕福なユーザの画面上にボーブルを配置しようと、より懸命に努めることができる。最新の最も高価なタイプのデバイスを有するか、又は、高価なデータサービスを使用するユーザは、時代遅れのデバイス、又は、最も遅れているデータサービスを有するユーザよりも、より商用的な注目に値することがある。ユーザによってエクスポーズされたか、又は、状況から推論可能な他のプロファイルデータは、サードパーティによって、どの画面がそれらのボーブルにとって最良のターゲットであるかを決定する際に、同様に使用されうる。）

１つの特定の実装では、少数のボーブル（例えば、１〜８個）が商用プロモーションに割り振られてもよく（例えば、グーグルのようなオークション手順によって決定されるように、且つ、商用対非商用ボーブルのユーザ調整を受ける）、他のボーブルが、以前に述べたものなど、非商用要因に基づいて選択されてもよい。これらの後者のボーブルは、ルールベースの方法で、例えば、以前に述べた異なる要因に重み付けして、ボーブル毎にスコアを取得するアルゴリズムを適用して、選ばれてもよい。競合スコアが次いでランク付けされ、最高スコアのＮ個のボーブル（ただし、Ｎは、冗長コントロールを使用してユーザにより設定されてもよい）が画面上に提示される。

もう１つの実装では、商用ボーブルのための推測的な割り振りはない。その代わりに、これらの商用ボーブルは、非商用ボーブルと類似の方法でスコア化される（典型的には、異なる基準を使用するが、類似のスコアの範囲に合わせてスケールされる）。上位スコアのＮ個のボーブルが次いで提示され−これらのボーブルは、すべて商用であっても、すべて非商用であっても、又は混合であってもよい。

さらにもう１つの実装では、商用−非商用ボーブルの混合は、ユーザのサブスクリプションサービスの相関的要素である。エントリレベルのユーザは、導入料金を支払うと、サイズが大きい、及び／又は、数が多い商用ボーブルが提示される。サービスプロバイダにプレミアムサービスの支払いをするユーザには、より小さい、及び／又は、より少数の商用ボーブルが提示されるか、又は、商用ボーブルの表示についてのユーザ自身のパラメータを設定する自由が与えられる。

ボーブルを表すグラフィカルなしるしを、その特徴関連付けを示すように視覚的に調整することができ、このしるしには、ユーザの注目を引き付けるためにアニメーションの要素が含まれてもよい。ボーブルプロバイダは、様々なサイズのしるしをシステムに提供し、−ユーザが、表示された画像のそのエリアにズームインするか、又は、他の方法でそのようなボーブルへの潜在的な関心を表す場合−システムがボーブルサイズ−及び解像度−を増すことができるようにしてもよい。場合によっては、システムは、警官の役を果たさなければならず−例えば、そのサイズが、格納されたルールによって確立された寸法を超える、その外観がわいせつであると見なされる、などのために、提供されたボーブルを提示しないことに決定する。（システムは、ボーブルを適切なサイズに自動的にスケールダウンし、汎用のしるし−星など−を、不適切又は他の状態で使用不可能であるしるしの代わりに用いてもよい。）

ボーブルを、画像から見極められた視覚的特徴に関連する以外で提示することができる。例えば、ボーブルは、デバイスがそのジオロケーションを知っていること、又は、デバイスがそのユーザのアイデンティティを知っていることを示すために、提示されてもよい。様々な動作のフィードバックを、したがって、−画像コンテンツにかかわらず−ユーザに提供することができる。ある画像フィードバックもまた、−特定の特徴識別は別として−ボーブルを介して提供されてもよく、例えば、キャプチャされた画像が、焦点又はコントラストなど、基本的な品質標準を満たすことである。

各ボーブルは、ビットマップ表現を含むことができ、又は、グラフィカルプリミティブの集まりに関して定義することができる。典型的には、ボーブルのしるしは、平面ビューで定義される。ソフトウェアの空間モデルコンポーネントは、キャプチャされた画像内で見極められた表面に従って、その投影を画面上へマッピングすること、例えば、斜めに見られた店先に関連付けられたボーブルを外見的に傾け、おそらく遠近法によって曲げることを処理することが可能である。そのような論点については、以下のセクションでさらに論じる。
空間モデル／エンジン

３Ｄ世界を２Ｄ画面上へ、満足の行くように投影且つ表示することは、楽しいユーザ体験の確立において重要でありうる。したがって、好ましいシステムは、そのような目的を果たすために、ソフトウェアコンポーネント（例えば、空間モデル又は空間エンジンなど、様々に呼ばれる）を含む。

３Ｄ世界を２Ｄでレンダリングすることは、３Ｄ世界について何かを理解することによって開始する。空のピクセルのフレーム−あらゆるジオロケーションデータ又は他の空間理解が欠けている−から、どこで始めればよいのか？どのようにオブジェクトを見極めて、カテゴリ化すればよいのか？画像シーンの動きを追跡してボーブルがそれに応じて再位置決めされる方法は？幸いにも、そのような問題には、何度も多くの状況で直面されてきた。マシンビジョン及びビデオ動き符号化は、多くの中でも、当業者が精通していると推定され、当業者が本出願に関連してそこから引き出すことができる、有用な従来技術を提供する２つの分野である。
・第一原理として：
・・カメラ及び表示された画面は、古典的な２Ｄ空間的構造である
・・カメラは、２Ｄ平面への３Ｄ世界の空間的投影を通じて機能する
・・ボーブル及びプロトボーブルは、空間的フレームワーク内で「オブジェクト化」される。

以下に、空間理解を直交処理ストリームとして、並びに、コンテキスト項目及び属性項目として体系化するための提案が続く。この提案は、３つの「空間レベル」−空間理解の段階−の構成物を利用する。

空間レベル１は、基本シーン解析及び構文解析を含む。ピクセルは、最初のグループにクランプ化（ｃｌｕｍｐｅｄ）される。キャプチャされたシーンリアルエステート、並びに、表示スクリーンリアルエステートの、ある基本理解が存在する。また、複数のフレームにわたるシーンリアルエステートの流れについての、ある初歩的な知識も存在する。

幾何学的に、空間レベル１は、単純な２Ｄ平面に関連して存続する。空間レベル１の動作には、ピクセルデータから見極められた２Ｄオブジェクトのリストを生成することが含まれる。ＯｐｅｎＣＶビジョンライブラリ（後述）によって行われる基本の動作は、この解析の範囲に入る。スマートフォンのローカルソフトウェアは、空間レベル１の動作を扱うことに堪能であってもよく、２Ｄオブジェクトの豊富なリストがローカルで作成されうる。

空間レベル２は、過渡的であり−空間レベル１の２Ｄプリミティブを多少理解するが、まだ空間レベル３の完全な３Ｄ理解には至らない。このレベルの解析には、異なる空間レベル１プリミティブを関係付けようとする−オブジェクトが２Ｄコンテキストにおいてどのように関係するかを見極めるタスク、及び、３Ｄ理解の手がかりを探すタスクが含まれる。含まれるものは、オブジェクトのグループ（例えば、形状を定義する輪郭を形成する異なるエッジ）を識別する、パターン−直線に沿ったオブジェクトなどに注目する、並びに、消失点、水平線、及び、「上／下」の観念など、「世界の空間的手がかり」を見極めるなどの動作である。「より近い／より遠い」の観念もまた、明らかにされうる。（例えば、顔は、一般に知られている寸法を有する。基本の特徴のセットが顔を表現する可能性が高いように見え、且つ、このセットが、４８０ピクセルの高さであるシーン内で４０ピクセルの高さしかない場合、「より遠い」属性が集められうる−４００ピクセルの高さである、顔のピクセルの集まりとは対照的である。）

空間レベル１プリミティブの不協和音が抜き出され、オブジェクト関連エンティティのより短く、より意味のあるリストに合成される。

空間レベル２は、シーン及びシーンシーケンス上にＧＩＳのような編成を課し、例えば、識別されたクランプ、オブジェクト、又は関心領域の各々に、それ自体の論理データ層を−場合によっては、重複するエリアを有して−割り当てることができる。各層は、関連付けられたメタデータのストアを有してもよい。このレベルで、−フレーム間の−オブジェクト連続性を見極めることができる。

幾何学的に、空間レベル２は、キャプチャされたピクセルデータが、カメラによる２Ｄ画像フレームへの３Ｄ世界の投影であることを認める。より前に見極められたプリミティブ及びオブジェクトは、現実の完全な特徴付けであるように解釈されないが、むしろ、１つのビューであると解釈される。オブジェクトは、それらのオブジェクトが見られる元のカメラレンズに関連して見なされる。レンズ位置は、ピクセルデータが理解されるべき視点を確立する。

空間レベル２の動作は典型的には、空間レベル１の動作よりもクラウド処理の方により依拠する傾向がある。

例示的実施形態では、ソフトウェアの空間モデルコンポーネントは汎用であり−ピクセルデータをより有用な形式へと抜き出す。異なる認識エージェントは次いで、それら自体のバージョンのそのような処理をそれぞれ行うのではなく、それぞれのタスクを行う際に、抜き出されたデータのこの共通プールから引き出すことができる。しかし、どの動作が、当然この共通の方法で行われるというそのような一般用途のものであるか、及び、どの動作が個々の認識エージェントに委ねられ−必要に応じてのみ行われるべきであるかを決定する際に、境界線が引かれなければならない。（それらの結果は、それにもかかわらず、例えば、ブラックボードによって共有されうる。）この境界線を任意に引くことができ、設計者は、どの動作が境界線のどちら側に来るかを自由に決定することができる。時々、境界線は、電話の動作中に動的に移動することがあり、例えば、認識エージェントが、さらなる共通サービスサポートを要求する場合である。

空間レベル３の動作は、３Ｄに基づいている。データが完全な３Ｄ関係を明らかにするかどうかにかかわらず（一般には、明らかにはしない）、これらの解析は、ピクセルが３Ｄ世界を表現するという前提に基づいている。そのような理解は、あるオブジェクト認識処理にとって有用で−不可欠ですら−ある。

空間レベル３は、このように、以前の理解のレベルに基づき、世界の相関にまで広がる。ユーザは、所与の投影及び時空の軌跡を有する世界モデル内の観察者であると理解される。シーンから世界へ、及び、世界からシーンへのマッピングを行う変換方程式を適用して、システムが空間内のどこにあるのか、及び、オブジェクトが空間内のどこにあるのかをシステムが共に理解するように、且つ、どのように物事が関係するかについてのあるフレームワークをシステムが有するようにすることができる。これらの解析のフェーズは、ゲーム業界及び拡張現実エンジンにおける作業から引き出す。

空間レベル１に関連付けられた動作（及び、空間レベル２に関連付けられたいくつか）とは異なり、空間レベル３に関連付けられた動作は一般に大変特化されるので、入ってくるデータに対してルーチン的には行われない（少なくとも、現在の技術ではそのように行われない）。むしろ、これらのタスクは、特定の３Ｄ情報を必要とすることがある特定の認識タスクに委ねられる。

いくつかの認識エージェントは、ユーザの環境の仮想モデルを構築し−且つ、そのモデルを、検知されたオブジェクトで、それらの３Ｄコンテキストにおいてポピュレートすることができる。車両運転モニタは、例えば、ユーザの車のフロントガラスの外を見て−交通安全に関連のある項目及びアクションに注目することができる。車両運転モニタは、交通環境の３Ｄモデル、及び、その環境内のアクションを維持することができる。車両運転モニタは、ユーザの妻（別のソフトウェアエージェントによって識別され、そのソフトウェアエージェントがその識別をブラックボードに投稿した）が自分の赤いスバル（Ｓｕｂａｒｕ）を運転しながら赤信号を通過することに−ユーザのビュー内で−注意することができる。そのような機能性をサポートするための３Ｄモデリングは確かに可能であるが、電話の一般的なサービスによってルーチン的に行われるようになる動作の種類ではない。

これらの態様のうちいくつかを図４に示し、図４は、空間レベル１から、２へ、３へと増していく空間理解の洗練を概念的に例示する。

例示的応用例では、異なるソフトウェアコンポーネントが、異なる空間レベルに関連付けられた異なるタイプの情報を見極めることを担う。クランプ化エンジン（ｃｌｕｍｐｉｎｇ ｅｎｇｉｎｅ）は、例えば、空間レベル１の理解のいくつかの生成に使用される。

クランプ化は、（一般に連続的な）ピクセルのグループを、関連するものとして識別するための処理を指す。この関係は、例えば、色又はテクスチャの類似性でありうる。又は、この関係は、流れの類似性でありうる（例えば、フレームからフレームへと静的な背景にわたってシフトする顔のピクセルの類似パターン）。

１つの構成では、システムがピクセルのクランプを識別した後、システムは、シンボロジー（例えば、ＩＤ番号と同様に単純）を、クランプに関連付けられるように割り当てる。これは、クランプのさらなる管理及び解析に関連して（及び、そうでない場合も、例えば、リンクトデータ（ｌｉｎｋｅｄ ｄａｔａ）構成に関連して）有用である。プロトボーブルがクランプに割り当てられ、識別シンボルを参照することによって追跡されてもよい。システムがクランプの位置を２Ｄ及び３Ｄにおけるカメラの位置に関係付けることによって行われた、構文解析及び向き調節動作の結果生じる情報が、クランプのシンボルを参照することによって編成されてもよい。同様に、クランプに関連付けられた画像処理演算の結果生じるデータを、クランプのシンボルを参照することによって識別することができる。同様に、ユーザのタップがシンボルと関連して記録されてもよい。それによりクランプ関連情報を格納且つ管理することができるハンドルとしてのシンボルのこの使用は、クランプに関するクラウドベースの処理、クランプ−オブジェクトの完全認識及びそれに基づいた応答全体を通じての、クランプに関連付けられたボーブルの進化にまで及ぶ可能性がある。（例えば、セッションＩＤを含む、より詳細な命名構成物は、以下で紹介される。）

これらの空間理解コンポーネントは、他のシステムソフトウェアコンポーネントと並列に動作し、例えば、共通／グローバルな空間理解を維持し、エージェント及びオブジェクトが利用することができる空間的フレームワークをセットアップすることができる。そのような動作には、空間的環境についての現在の情報を共有可能データ構造（例えば、ブラックボード）に投稿することが含まれる可能性があり、認識エージェントは、この共有可能データ構造を参照して、何を見ているかを理解する助けとすることができ、グラフィックシステムは、現在の景色の上にどのようにボーブルをペイントするかを決定する際に、この共有可能データ構造を調べることができる。異なるオブジェクト及びエージェントは、この３つのレベルに関連付けられた空間レベルフィールド及び属性項目をセットアップすることができる。

これらのシステムの継続的な世代を通じて、空間理解コンポーネントは、デバイスのほとんど反射的、機械的な反復機能になると予期される。
直観的コンピューティングプラットフォーム（ＩＣＰ）ステートマシン−サービスの構成、サービス指向コンピューティング、認識エージェント

以前に述べたように、ＩＣＰステートマシンは、本質的に、リアルタイムオペレーティングシステムを備えることができる。ＩＣＰステートマシンは、スケジューリング、マルチタスキング、エラー回復、リソース管理、メッセージング及びセキュリティなど、従来のタスク、並びに、現在のアプリケーションにより特有であるいくつかの他のタスクを処理することができる。これらの追加のタスクには、監査証跡機能性の提供、安全なセッション管理の処理、及び、サービスの構成の決定が含まれうる。

監査証跡機能性は、商用エンティティに対し、彼らがスポンサーになるために支払いをしたボーブルが実際にユーザに提示されたという保証を提供する。

安全なセッション管理は、（例えば、暗号化により）盗聴などに対してロバストであるクラウドサービス及び他のデバイスとの、接続の確立及び維持を伴う。

サービスの構成は、ある機能（及び、これらのコンポーネント動作の関連オーケストレーション／コレオグラフィ）を行うための動作の選択を指す。ディスパッチ処理は、例えば、リソースをアプリケーションにうまく調和させるなど、これらの態様のステートマシンの動作に関与することができる。

ある高レベルの機能が、様々なより低いレベルの動作の異なる組み合わせからのデータを使用して、実装されてもよい。どの機能を利用すべきか、及び、いつかの選択は、いくつかの要因に基づく可能性がある。１つは、何の他の動作が既に進行中であるか、又は完了しているかであり−その結果もまた、このニーズを満たすことがある。

例示のため、バーコードの位置測定は通常、位置測定される水平コントラストの計算、及び、位置測定される垂直コントラストの計算、及び、そのようなコントラストデータの比較に依拠することがある。しかし、画像中の１６×１６ピクセルのタイルの２ＤのＦＦＴデータが別の処理から既に入手可能である場合、代わりにこの情報を使用して、候補バーコードエリアが位置指定されるかもしれない。

同様に、ある機能が、画像内の長いエッジの場所についての情報を必要とすることがあり、長いエッジデータを作り出すための専用の動作が開始されうる。しかし、別の処理が、フレーム内の様々な長さのエッジを既に識別していることがあり、これらの既存の結果が単にフィルタリングされて、長いエッジが識別され、再使用されてもよい。

もう１つの例は、ハフ（Ｈｏｕｇｈ）変換ベースの特徴認識である。ＯｐｅｎＣＶビジョンライブラリは、この機能が、間引かれたエッジ画像データを入力データとして使用することが望ましいことを示す。ＯｐｅｎＣＶビジョンライブラリは、キャニー演算（Ｃａｎｎｙ ｏｐｅｒａｔｉｏｎ）をエッジデータに適用することによって、間引かれたエッジ画像データを生成することを、さらに推奨する。エッジデータは、さらに、ソーベルフィルタを画像データに適用することによって、一般に生成される。そのため、ハフ手順の「型通り」の実装は、ソーベルフィルタから開始し、その後にキャニー演算が続き、次いでハフ法を呼び出すことになる。

しかし、エッジを、ソーベルフィルタ以外の方法によって決定することができる。また、間引かれたエッジを、キャニー以外の方法によって決定することができる。システムがエッジデータ−ソーベルフィルタ以外の方法によって生成されたものであろうとも−を既に有する場合、このエッジデータが使用されてもよい。同様に、別の処理が、改良されたエッジデータを既に作り出している場合−たとえキャニー演算によるものでない場合でも、この改良されたエッジデータが使用されてもよい。

１つの特定の実装では、システム（例えば、ディスパッチ処理）は、異なるタイプのキーベクトル間の大まかな度合いの機能的対応を確立する情報を有する、データ構造を参照することができる。キャニーによって作り出されたキーベクトルエッジデータは、無限対称指数フィルタ（Ｉｎｆｉｎｉｔｅ Ｓｙｍｍｅｔｒｉｃ Ｅｘｐｏｎｅｎｔｉａｌ Ｆｉｌｔｅｒ）技術によって作り出されたエッジデータとの高度の機能的対応、及び、Ｍａｒｒ−Ｈｉｌｄｒｅｔｈ手順によって見極められたエッジデータとの幾分より低い対応を有するように示されうる。ハリス演算子によって検出されたコーナーは、Ｓｈｉ及びＴｏｍａｓｉ方法によって検出されたコーナーと交換可能でありうる、などとなる。

このデータ構造は、１つの大きいテーブルを含むことができ、又は、いくつかのテーブルに分解可能であり−各々のテーブルは特定のタイプの動作に特化される。図５は、例えば、エッジ発見に関連付けられたテーブルの一部を概略的に示し−対応の度合い（１００にスケールされたもの）を示す。

特定の高レベルの機能（例えば、バーコードの復号）は、キャニーエッジフィルタなど、特定の処理によって生成されたデータを必要とすることがある。キャニーフィルタ機能は、システムにとって使用可能なソフトウェア処理アルゴリズムのライブラリで使用可能であることがあるが、その動作を呼び出す前に、システムは、図５のデータ構造を調べて、適切な代替データが既に入手可能又は処理中であるかどうかを確かめてもよい（好ましいキャニーデータが既に入手可能ではないと仮定する）。

このチェックは、一番左の列に名目的に所望の機能がある行を発見することによって、開始する。この手順は次いで、最高値を求めてその行中を走査する。キャニーの場合、最高値は、無限対称指数フィルタの９５である。システムは、共有データ構造（例えば、ブラックボード）をチェックして、そのようなデータが対象の画像フレーム（又は適切な代用物）のために入手可能であるかどうかを判定することができる。発見される場合、そのようなデータが、名目的に指定されたキャニーデータの代わりに使用されてもよく、バーコード復号動作は、それに基づいて継続することができる。何も発見されない場合、ステートマシン処理は継続し−次に高い値（複数可）（例えば、Ｍａｒｒ−Ｈｉｌｄｒｅｔｈの９０）を探す。ここでもまた、システムは、このタイプのいずれかのデータが入手可能であるかどうかをチェックする。処理は、テーブル内の代替物のすべてがチェックされ尽くすまで、進行する。

ここで好ましい実施形態では、このチェックは、ディスパッチ処理によって着手される。このような実施形態では、大抵の認識処理は、カスケードされた動作のシーケンスとして行われ−各々が指定された入力を有する。ディスパッチ処理の使用により、付随するサービスの構成の意思決定が集中化されることが可能となる。これにより、また、動作可能なソフトウェアコンポーネントを、例えば、適切な入力リソースを求めてテーブルをチェックすること、及び、他の処理の動作の意識を維持すること−そのようなコンポーネントをより複雑にし、維持を困難にするであろう負荷−にも関与するのではなく、画像処理に集中させることもできる。

いくつかの構成では、閾値が−バーコード復号機能によって、又は、システムによってグローバルに−指定され、例えば、７５など、データ代用のために受け入れ可能である最小対応値を示す。そのような場合、直前に記載された処理は、ソーベル及びキルヒフィルタからのデータを考慮することはなく−その理由は、それらのフィルタの、キャニーフィルタとの対応の度合いが、７０でしかないためである。

他の実装は異なることがあるが、図５のテーブルは、対称ではないことに留意されたい。例えば、キャニーが望ましい場合、ソーベルには７０のみの対応が示される。しかし、ソーベルが望ましい場合、キャニーには９０の対応が示される。したがって、キャニーをソーベルの代わりに用いることはできるが、７５の閾値が設定される場合、逆もまた同様ではない。

図５のテーブルは、汎用である。いくつかの特定の応用例では、しかし、このテーブルは適切ではないことがある。ある機能は、例えば、エッジがキャニー（好ましい）、又は、キルヒ若しくはラプラシアンにより発見されることを、必要とすることがある。その機能の性質により、他のエッジファインダは満足の行くものになりえない。

システムは、個々の機能が１つ又は複数の動作のためのそれら自体の対応テーブルを提供し−汎用テーブル（複数可）の適用を防止することを可能にすることができる。ある機能のための特化された対応テーブルの存在は、その機能に関連付けられたフラグビットによって、又は他の方法で示すことができる。直前に挙げた例では、フラグビットは、図５Ａのテーブルが代わりに使用されるべきであることを示してもよい。このテーブルは、−その機能で使用するために名目的に指定されるキャニー演算のための−ただ１行のみを含む。また、このテーブルは、−無限対称指数フィルタ及びラプラシアンのための−ただ２列のみを有する。（他のデータは適切ではない。）対応値（すなわち、９５、８０）は省かれてもよく−このテーブルが単純な代替処理のリストを含むことができるようにしてもよい。

共有データ構造内の代用可能なデータの発見を容易にするため、特定のキーベクトルが何の情報を含むかを示す、命名規則を使用することができる。このような命名規則は、機能のクラス（例えば、エッジ発見）、機能の特定の種（例えばキャニー）、データが基づく画像フレーム（複数可）、及び、データに特有の任意の他のパラメータ（例えば、キャニーフィルタのためのカーネルのサイズ）を示すことができる。この情報は、逐語的に、省略形による、全詳細を取得するために別のデータ構造を通じて解決可能である１つ又は複数のインデックス値による、その他など、様々な方法で表すことができる。例えば、フレーム１３５７のためのキャニーエッジデータを含み、５×５のぼけカーネル（ｂｌｕｒｒｉｎｇ ｋｅｒｎｅｌ）により作り出されたキーベクトルは、「ＫＶ＿Ｅｄｇｅ＿Ｃａｎｎｙ＿１３５７＿５×５」と命名されてもよい。

他の処理に、処理中であるデータのアラートを出すために、ある機能が初期化されるとき、空のエントリを共有データ構造に書き込むことができ−その機能の最終結果に従って命名することができる。したがって、システムが、キャニー演算をフレーム１３５７で、５×５のぼけカーネルにより行うことを開始する場合、空のファイルが、上述の名前で共有データ構造に書き込まれてもよい。（この書き込みは、その機能によって、又は、ステートマシン−例えば、ディスパッチ処理によって行われうる。）別の処理がその情報を必要とし、空のエントリを有する適切に命名されたファイルを発見する場合、別の処理は、このような処理が起動されていることを知る。別の処理は次いで、共有データ構造を監視し、又は、共有データ構造に戻ってチェックし、必要とされた情報が入手可能になるとき、取得することができる。

より詳細には、その情報を必要とする処理段階は、その入力パラメータの中に、所望のエッジ画像の仕様−その必要とされた品質を与える記述子を含む−を含むようになる。システム（例えば、ディスパッチ処理）は、現在メモリ内（例えば、ブラックボード上）にあるデータのタイプ、及び、上述のような記述テーブルを調べて、適切なデータが現在入手可能であるか、処理中であるかを判定するようになる。可能なアクションには、このとき、受け入れ可能、入手可能なデータによりその段階を開始すること、データが入手可能であると予期されるとき、後の時間まで開始を遅延させること、開始を遅延させ、必要とされたデータを生成するようになる処理（例えば、キャニー）の開始をスケジュールすること、又は、必要とされたデータ及びそのデータを生成するために必要とされるであろうリソースの不足により、その段階を遅延又は終了させることが含まれうる。

代わりのデータが特定の動作による使用に適切であるかどうかを検討する際、他のフレームからのデータが検討されてもよい。カメラがフリーランニングモードである場合、そのカメラは毎秒多数（例えば、３０）のフレームをキャプチャ中であることがある。（上記で挙げた例で）ある解析処理がフレーム１３５７を特に検討することがあるが、この解析処理は、フレーム１３５６から、又は、フレーム１２００若しくは１５００からさえも導出された情報を利用可能であってもよい。

この点で、コンテンツが比較可能である画像を包含するフレームのグループを識別することが、助けとなる。２つの画像フレームが比較可能であるかどうかは、当然、例えば、画像コンテンツ及び行われている動作（複数可）など、個々の状況によって決まるようになる。

１つの例示的構成では、（１）関連のある関心領域が双方のフレーム内に現れる（例えば、同じ顔の被写体、又は、バーコードの被写体）場合、及び（２）ＡとＢの間のフレームの各々もまた、その同じ関心領域を含む（これは、カメラが被写体を最初に見たときと、カメラが被写体に戻ったときの間に、変化する被写体に対する、ある程度の保護をもたらす）場合、フレームＡはフレームＢと比較可能であると見なされてもよい。

もう１つの構成では、２つのフレームの色ヒストグラムが、指定された閾値内までに類似している（例えば、それらの色ヒストグラムが、０．９５又は０．９８より大きい相関を有する）場合、それらの２つのフレームは比較可能であると見なされる。

さらにもう１つの構成では、ＭＰＥＧのような技術を画像ストリームに適用して、２つのフレーム間の差異情報を決定することができる。差異が閾値を超える場合、これらの２つのフレームは比較不可能であると見なされる。

上述の基準に加えて課すことができる、さらなるテストは、フレーム内の関心特徴又は関心領域の位置が比較的固定されることである（「比較的」とは、例えば、１０ピクセル、フレーム幅の１０％など、許可された動きの閾値を可能にする）。

多くの様々な他の技術を、別法として使用することができ、これらの構成は例示的でしかない。

１つの特定の実施形態では、モバイルデバイスは、比較可能な画像フレームを識別するデータ構造を維持する。このデータ構造は、例えば、以下のように、各グループの先頭及び終了フレームを識別するテーブルのように単純でありうる。

いくつかの構成では、第３のフィールドが設けられてもよく−示された範囲内で、いくつかの理由で比較可能ではない（例えば、焦点が合っていない）フレームを示す。

以前に述べられた例に戻ると、ある機能が入力データ「ＫＶ＿Ｅｄｇｅ＿Ｃａｎｎｙ＿１３５７＿５×５」を望み、何も発見されない場合、その機能は、前述のテーブルによって示された比較可能性（おおよそ等価）に基づいて、検索を拡大して、「ＫＶ＿Ｅｄｇｅ＿Ｃａｎｎｙ＿１２００＿５×５」ないし「ＫＶ＿Ｅｄｇｅ＿Ｃａｎｎｙ＿１５００＿５×５」を探すことができる。また、上記で示したように、その機能はここでも、他の方法によってフレーム１２００〜１５００のいずれかから作り出されたエッジデータを利用可能であってもよい。

したがって、例えば、フレーム１２５０内の高い水平コントラストの領域、及び、フレーム１３００内の低い垂直コントラストの領域を発見することによって、バーコードが位置指定されてもよい。位置指定の後、このバーコードは、フレーム１３５０内で発見された境界線構造（エッジ）、並びに、フレーム１３６０、１３６２及び１３６４内で発見されたシンボルパターンの相関を参照することによって、復号されてもよい。すべてのこれらのフレームは共通グループ内にあるので、デバイスは、それらのフレームの各々から導出されたデータを、他のフレームの各々から導出されたデータと共に使用可能であると見なす。

より高度な実施形態では、フレーム間の特徴追跡（流れ）を見極め、使用して、フレーム間の動きを識別することができる。したがって、例えば、デバイスは、フレームＡ内のピクセル（１００，１００）で開始する線が、フレームＢ内のピクセル（１０１，１０７）で開始する同じ線に対応することを理解することができる。（ここでもまた、ＭＰＥＧ技術を、例えば、フレーム間オブジェクト追跡のために使用することができる。）データを再登録するために適切な調整を行うことができ、又は、他の方法で調整を導入することができる。

より単純な実施形態では、画像フレーム間の等価は、単に時間的近接に基づく。対象フレームの所与の期間（又はフレーム期間）内のフレームは、比較可能であると見なされる。そのため、フレーム１３５７を求めて、キャニーエッジ情報を探す際、システムは、フレーム１３５２〜１３６２（すなわち、プラス及びマイナス５フレーム）のうちいずれからのエッジ情報をも等価であるように受け入れることができる。この手法は、時として失敗につながるようになるが、その単純さにより、ある状況では望ましくなりうる。

時として、代用された入力データを使用する動作は、代替処理からの入力データが動作の名目的な所望の入力データの正確な特性のものではなかったために、失敗する（例えば、その動作はバーコードを発見できない、又は、顔を認識できない）。例えば、まれではあるが、ハフ変換ベースの特徴認識は、入力データがキャニー演算子によって作り出されたものではなく、代替処理によって作り出されたために、失敗するかもしれない。ある動作が失敗する場合、−今度は異なる入力データのソースにより−再試行されてもよい。例えば、キャニー演算子が、代替物の代わりに利用されてもよい。しかし、動作を繰り返すコスト、及び、２回目の試行の成功への期待が一般に低いことにより、そのような再試行は一般に、ルーチン的に着手されない。再試行が試みられうる１つの場合は、ユーザアクションに応答してなど、トップダウンの方法で動作が開始された場合である。）

いくつかの構成では、最初のサービスの構成の決定は、ある程度、動作がトップダウンで開始されたか、ボトムアップで開始されたか（これらの概念については、後述される）によって決まる。ボトムアップの場合、トップダウンの場合よりも、例えば、異なる入力データのソース（例えば、名目データソースへの対応がより少なく示されるソース）を代わりに用いるために、より多くの自由が認められてもよい。

サービスの構成を決定する際に検討することができる他の要因には、電力及び計算の制約、あるクラウドベースの動作にかかる金銭的なコスト、オークション結果、ユーザ満足度ランキングなどが含まれうる。

ここでもまた、サービスの構成の決定の助けとするために、代わりの動作の各々のための相対的情報を与えるテーブルを調べてもよい。一例が、図６に示される。

図６のテーブルは、異なるエッジ発見機能を実行するために必要とされるＣＰＵ及びメモリについてのメトリックを与える。これらのメトリックは、何らかの実際の値（例えば、記載された演算を所与のサイズ、例えば、１０２４×１０２４の画像で行うためのＣＰＵサイクル、及び、このような演算を実行するために必要とされるＲＡＭのＫＢ）であってもよく、又は、例えば、０〜１００のスケールで任意にスケールされてもよい。

ある機能が−好ましくはキャニー演算からの−エッジデータを必要とし、適切なデータが既に入手可能ではない場合、ステートマシンは、要求されたキャニー演算を呼び出すか、別の演算を呼び出すかを決定しなければならない。システムメモリの供給が不十分である場合、図６のテーブルは（図５のテーブルと共に）、無限対称指数フィルタが代わりに使用されてもよいこと、すなわち、このフィルタは、ＣＰＵ負荷がわずかに大きいだけであるが、２５％少ないメモリを要することを示唆する。（図５は、無限対称指数フィルタの、キャニーとの対応が９５であり、そのため、機能的に代用可能であるはずであると示す。）ソーベル及びキルヒは、はるかにより小さいメモリフットプリントを要するが、図５は、これらが適切ではない場合があること（７０のスコア）を示す。

リアルタイムステートマシンは、様々なパラメータを検討することができ−これらのパラメータは、図５及び図６のスコアに加えて、代替エッジ発見演算の各々についてのコスト、ユーザ満足度、現在のシステム制約（例えば、ＣＰＵ及びメモリ利用）についての他のスコア、及び、他の基準などである。これらのパラメータは、多項式に従って異なる組み合わせのパラメータの重み付け及び合計を行う処理へ、入力されてもよい。この処理の出力は、呼び出される可能性のある異なる演算の各々についてのスコアを生じる。最高スコア（又は、式に応じて、最低）を有する演算が、本状況で最良であると見なされ、次いで、システムによって開始される。

図５及び図６のテーブルは、このような機能のローカルデバイス実行のみを検討したが、クラウドベースの実行もまた検討されてもよい。この場合、機能のプロセッサ及びメモリコストは本質的にゼロであるが、例えば、結果を受信するための時間の増大、ネットワーク帯域幅の消費、及び、場合によっては金銭的なマイクロペイメントにおいて、他のコストが負担されうる。これらのコストの各々は、代替サービスプロバイダ及び機能によって異なることがある。これらの要因を査定するために、追加のスコアを、例えば、サービスプロバイダ及び代わりの機能毎に計算することができる。これらのスコアには、入力として、結果を取り戻す緊急性の指示、及び、クラウドベースの機能から予期されるターンアラウンド時間の増大と、ネットワーク帯域幅の現在の使用、及び、機能をクラウドベースのサービスへ委託することによって消費されるであろう追加の帯域幅と、企図された機能（例えば、無限対称指数フィルタ）対、名目的に所望の機能（例えば、キャニー）の代替性と、値段に対するユーザの敏感さの指示、及び、何の料金が（もしあれば）機能のリモート実行について査定されるようになるかとが含まれうる。様々な他の要因もまた関与する可能性があり、ユーザプリファレンス、オークション結果などが含まれる。そのような計算の結果生じるスコアを使用して、検討される異なるリモートプロバイダ／機能の中で好ましいオプションを識別することができる。システムは次いで、この課題からの勝利スコアを、ローカルデバイスによる機能の性能に関連付けられたものからの勝利スコアと比較することができる。（スコアリングスケールは、比較可能であることが望ましい。）次いで、そのような査定に基づいて、アクションを起こすことができる。

サービスの選択は、他の要因にも基づくことができる。コンテキスト、ユーザの意図の指示などから、本状況に関連のある認識エージェントのセットを識別することができる。これらの認識エージェントから、システムは、それらの所望の入力からなるセットを識別することができる。これらの入力には、他の異なる入力を有する他の処理が含まれてもよい。関連のある入力のすべてを識別した後、システムは、示された入力並びに代替物を含む、ソリューションツリーを定義することができる。システムは次いで、ツリー中で異なるパスを識別し、（例えば、関連のある制約に基づいて）最適であると見なされるパスを選択する。ここでもまた、ローカル及びクラウドベースの処理の双方を検討することができる。

最適性の１つの尺度は、ソリューションが発見されるようになる確率に、且つ、関与するリソースに、パラメータを割り当てることによって計算された、コストのメトリックである。このメトリックは次いで、商である。
コスト＝（消費されたリソース）／（ソリューションが発見される確率）

ステートマシンは、この機能を最適化（最小化）することによって、ＲＡサービスを構成することを管理することができる。そのように行う際に、ステートマシンは、クラウドシステムと連動して、リソースを管理し、様々なソリューションツリートラバーサルのコストを計算することができる。

これを容易にするため、ＲＡは、複数の段階により設計されうるものであり、各々がソリューションに向かって前進する。段階は、それらのエントリポイントで粒度が細かく、それらの出力で冗長である（例えば、ロギング及び他の情報、収束の信頼性、状態などに関する指示をエクスポーズする）べきであることが望ましい。ストリーミングデータモデルを使用するように設計されるＲＡが、好ましいことが多い。

そのような点において、この技術は、例えば、「スマート環境」に関連して、人工知能（ＡＩ）の分野において知られる「プランニングモデル」から引き出すことができる。

（以下のプランニングモデルの考察は、部分的には、Ｍａｒｑｕａｒｄｔ、「Ｅｖａｌｕａｔｉｎｇ ＡＩ Ｐｌａｎｎｉｎｇ ｆｏｒ Ｓｅｒｖｉｃｅ Ｃｏｍｐｏｓｉｔｉｏｎ ｉｎ Ｓｍａｒｔ Ｅｎｖｉｒｏｎｍｅｎｔｓ」、ＡＣＭ Ｃｏｎｆ．ｏｎ Ｍｏｂｉｌｅ ａｎｄ Ｕｂｉｑｕｉｔｏｕｓ Ｍｅｄｉａ、２００８年、４８〜５５ページから引き出す。）

スマート環境は、Ｘｅｒｏｘ ＰＡＲＣのＭａｒｋ Ｗｅｉｓｅｒによって考え出されたように、「センサ、アクチュエータ、ディスプレイ及び計算要素に豊かに、且つ、目に見えないように織り込まれ、我々の生活の日常的なものにシームレスに埋め込まれ、連続的なネットワークを通じて接続される」環境である。そのような環境は、個別化されたサービス（例えば、照明、暖房、冷房、加湿、画像の投影、アラートを出すこと、画像の記録など）を控えめな方法でユーザに提供するデバイスの動的な全体的調和によって、特徴付けられる。

図７は例示的である。ユーザの意図は、例えば、観察によって、且つ、コンテキストを参照することによって識別される。この情報から、システムは、ユーザの推定された目標を導出する。方策統合のステップは、これらの目標を満たすアクションのシーケンスを発見しようと試みる。最後に、これらのアクションは、環境内で入手可能なデバイスを使用して実行される。

環境は変わりやすいので、方策統合−サービスの構成を処理する−は、例えば、目標及び入手可能なデバイスが変化するにつれて適合可能でなければならない。サービスの構成タスクは、ＡＩ「プランニング」問題と見なされる。

ＡＩプランニングは、特定の目標を達成するために、自律的エージェントが実行しなければならないアクションシーケンスを識別する問題に関する。エージェントが行うことができる各機能（サービス）は、演算子として表される。（前提及び事後条件（ｐｏｓｔ−ｃｏｎｄｉｔｉｏｎｓ）を、これらの演算子に関連付けることができる。前提条件は、演算子（機能）を実行するために存在しなければならない必要条件を記述する。事後条件は、演算子の実行によってトリガされた環境内の変化−スマート環境が応答する必要がある場合のある変化−を記述する。）プランニングに関して、図７の「方策統合」はプラン生成に対応し、「アクション」はプラン実行に対応する。プラン生成は、スマート環境のためのサービス構成を伴う。

多数のプランナが、ＡＩ分野から知られている。例えば、Ｈｏｗｅ、「Ａ Ｃｒｉｔｉｃａｌ Ａｓｓｅｓｓｍｅｎｔ ｏｆ Ｂｅｎｃｈｍａｒｋ Ｃｏｍｐａｒｉｓｏｎ ｉｎ Ｐｌａｎｎｉｎｇ」、Ｊｏｕｒｎａｌ ｏｆ Ａｒｔｉｆｉｃｉａｌ Ｉｎｔｅｌｌｉｇｅｎｃｅ Ｒｅｓｅａｒｃｈ、１７：１〜３３、２００２年を参照されたい。実際には、ＡＩプランナ間の競合に専念する年次会議がある（ｉｐｃ＜ｄｏｔ＞ｉｃａｐｓ−ｃｏｎｆｅｒｅｎｃｅ＜ｄｏｔ＞ｏｒｇを参照）。スマート環境内でサービスを合成するための少数のプランナが、Ａｍｉｇｏｎｉ、「Ｗｈａｔ Ｐｌａｎｎｅｒ ｆｏｒ Ａｍｂｉｅｎｔ Ｉｎｔｅｌｌｉｇｅｎｃｅ Ａｐｐｌｉｃａｔｉｏｎｓ？」ＩＥＥＥ Ｓｙｓｔｅｍｓ、Ｍａｎ ａｎｄ Ｃｙｂｅｒｎｅｔｉｃｓ、３５（１）：７〜２１、２００５年において評価されている。スマート環境内のサービス構成のための他のプランナは、以前に述べられたＭａｒｑｕａｒｄｔ論文で特に考察されており、ＵＣＰＯＰ、ＳＧＰ、及びブラックボックス（Ｂｌａｃｋｂｏｘ）が含まれる。すべては一般に、ＰＤＤＬ（プランニングドメイン定義言語）−プランニングドメイン及び問題のための普及している記述言語−の変形を使用する。

Ｍａｒｑｕａｒｄｔは、異なるプランナを単純なスマート環境シミュレーションで評価しており−その一部が図８によって表され、図８は、５個から２０個の間のデバイスを用い−各々は、２つのランダムに選択されたサービス、及び、ランダムに選択された目標を有する。データは、モデルコンポーネント間で、示された線に沿ってメッセージの形式で交換される。シミュレーション内のサービスは、それぞれ最大１２個の前提条件（例えば、「ｌｉｇｈｔ＿ｏｎ」、「ｈａｖｅ＿ｄｏｃｕｍｅｎｔ＿Ａ」など）を有する。各サービスはまた、様々な事後条件をも有する。

この研究は、すべての３つのプランナが満足の行くものであるが、ブラックボックス（Ｋａｕｔｚ、「Ｂｌａｃｋｂｏｘ：Ａ Ｎｅｗ Ａｐｐｒｏａｃｈ ｔｏ ｔｈｅ Ａｐｐｌｉｃａｔｉｏｎ ｏｆ Ｔｈｅｏｒｅｍ Ｐｒｏｖｉｎｇ ｔｏ Ｐｒｏｂｌｅｍ Ｓｏｌｖｉｎｇ」、ＡＩＰＳ、１９９８年）が最良に機能した、という結論を出した。目標が解決可能でない場合、プランナは概して、目標を満たすためにプランを考案しようと試みて不成功に終わるまでに過度の時間を要した、と、Ｍａｒｑｕａｒｄｔは言及した。著者は、処理が１秒以内にソリューションを生じない場合、リソースを無駄にしないために、プランニング処理を終了（又は、異なるプランナを開始）した方がよい、という結論を出した。

異なる分野の取組みからではあるが、出願人は、この後者の洞察が、ビジュアルクエリの分野において特定の目標を達成するためのサービスの構成を試行するときに、同様に適用されるべきであり、すなわち、ソリューションツリー（又は他のプランニング手順）中の満足の行くパスを迅速に考案することができない場合、ステートマシンは多分、この機能を、入手可能なデータでは解決できないと見なすべきであり、ソリューションを発見しようと試みながらさらに多くのリソースを費やすべきではない、と考える。閾値間隔がソフトウェアで確立されてもよく（例えば、０．１秒、０．５秒など）、タイマをこの閾値に対して比較することができ、閾値に達する前に適切な方策が発見されない場合、タイマは、ソリューションの試みを中断することができる。

本技術の実施形態はまた、ウェブサービスの分野の研究から引き出すこともでき、ウェブサービスはますます、複雑なウェブサイトの機能的コンポーネントとして含まれつつある。例えば、旅行ウェブサイトは、あるウェブサービスを使用して航空券の予約を行い、別のウェブサービスを使用して飛行機の座席を選択し、別のウェブサービスを使用してユーザのクレジットカードに請求することがある。旅行ウェブサイトは、これらの機能的コンポーネントを作り出す必要はなく、他者によって作り出され、提供された、複雑な機構のウェブサービスを使用する。このモジュール手法−他者によって以前になされた作業を利用する−は、システム設計及び引き渡しを速める。

この特定の形式のシステム設計は、様々な名称で通っており、これらの名称には、サービス指向アーキテクチャ（ＳＯＡ）及びサービス指向コンピューティングが含まれる。このスタイルの設計では、開発者は、個々のコンポーネント動作を行うためにソフトウェアを記述しなくても済むが、どのウェブサービスを使用するべきかを決定し、そのようなサービスへのデータの提出−及び、そのようなサービスからの結果の収集−をオーケストレートするタスクが、依然として存在する。これらの問題に対する様々な手法が知られている。例えば、Ｐａｐａｚｏｇｌｏｕ、「Ｓｅｒｖｉｃｅ−Ｏｒｉｅｎｔｅｄ Ｃｏｍｐｕｔｉｎｇ Ｒｅｓｅａｒｃｈ Ｒｏａｄｍａｐ」、Ｄａｇｓｔｕｈｌ Ｓｅｍｉｎａｒ Ｐｒｏｃｅｅｄｉｎｇｓ ０５４６２、２００６年、及び、Ｂｉｃｈｌｅｒ、「Ｓｅｒｖｉｃｅ Ｏｒｉｅｎｔｅｄ Ｃｏｍｐｕｔｉｎｇ」、ＩＥＥＥ Ｃｏｍｐｕｔｅｒ、３９：３、２００６年３月、８８〜９０ページを参照されたい。

サービスプロバイダは当然、サービスを提供するための能力が有限であり、時として、その能力を超える要求に優先順位を付けるという問題に対処しなければならない。この分野の研究には、競合する要求の中で選び、需要に従って、サービスの料金を適合させるためのアルゴリズムが含まれる。例えば、Ｅｓｍａｅｉｌｓａｂｚａｌｉ他、「Ｏｎｌｉｎｅ Ｐｒｉｃｉｎｇ ｆｏｒ Ｗｅｂ Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒｓ」、ＡＣＭ Ｐｒｏｃ．ｏｆ ｔｈｅ ２００６ Ｉｎｔ’ｌ Ｗｏｒｋｓｈｏｐ ｏｎ Ｅｃｏｎｏｍｉｃｓ Ｄｒｉｖｅｎ Ｓｏｆｔｗａｒｅ Ｅｎｇｉｎｅｅｒｉｎｇ Ｒｅｓｅａｒｃｈを参照されたい。

本技術のステートマシンは、サービス指向コンピューティング構成を用いて、処理負荷の一部をリモートサーバ及びエージェントに配置することによって、（視覚的検索及びその他のための）モバイルデバイスの機能性を拡張することができる。関連のあるウェブサービスが、１つ又は複数のクラウドベースのブローカ処理に登録されてもよく、例えば、それらのサービス、入力及び出力が、標準化された、例えば、ＸＭＬの形式で指定されてもよい。ステートマシンは、システムのニーズをかなえるためのサービスを識別する際、そのようなブローカ（複数可）を調べることができる。（ステートマシンは、複数のブローカのうち１つのブローカを調べて、個々のタイプのサービスを扱うブローカを識別することができる。例えば、第１のクラスのサービス、例えば、顔認識に関連付けられたクラウドベースサービスプロバイダは、第１のブローカによってカタログ化されてもよいが、異なるクラスのサービス、例えば、ＯＣＲに関連付けられたクラウドベースサービスプロバイダは、第２のブローカによってカタログ化されてもよい。）

ユニバーサル・ディスクリプション・ディスカバリー・アンド・インテグレーション（ＵＤＤＩ）仕様は、ウェブサービスについての情報をウェブサービスが発行するため、且つ、ステートマシンが発見するための、１つの方法を定義する。他の適切な標準には、拡張マークアップ言語（ｅｂＸＭＬ）を使用する電子ビジネス、及び、ＩＳＯ／ＩＥＣ １１１７９メタデータレジストリ（ＭＤＲ）に基づくものが含まれる。ＷＳＤＬ−Ｓ及びＯＷＬ−Ｓ（後述）など、セマンティックベースの標準は、ステートマシンがセマンティックモデルからの用語を使用して、所望のサービスを記述することを可能にする。記述論理推論（ｄｅｓｃｒｉｐｔｉｏｎ ｌｏｇｉｃ ｉｎｆｅｒｅｎｃｅｓ）など、推理技術を次いで使用して、ステートマシンによって提供された記述と、異なるウェブサービスのサービス能力の間のセマンティック類似性を発見し、ステートマシンが自動的に適切なウェブサービスを選択可能にすることができる。（他のところで上述したように、リバースオークションモデルを使用して、例えば、いくつかの適切なウェブサービスの中から選択することができる。）
直観的コンピューティングプラットフォーム（ＩＣＰ）ステートマシン−同時処理

システムを、応答する状態に維持するため、ＩＣＰステートマシンは、図９に概念的に例示された様々なレベルの同時処理（認知に類似）を監督してもよい。４つのこのようなレベル、及び、それらの各範囲の大まかな要約は、以下の通りである。
・・反射的−ユーザ又はクラウドインタラクションなし
・・条件付き−意図に基づく、最小のユーザインタラクション、クラウドを従事させる
・・直観型（Ｉｎｔｕｉｔｅｄ）又は「浅いソリューション（Ｓｈａｌｌｏｗ ｓｏｌｕｔｉｏｎ）」−ユーザインタラクションによって支援され、意図及び履歴の解釈によって情報を与えられた、デバイス上で達したソリューションに基づく
・・「深いソリューション（Ｄｅｅｐ Ｓｏｌｕｔｉｏｎ）」−ユーザ及びクラウドとのセッションを通じて達した完全なソリューション。

図１０は、システムの異なる態様によって編成されたビジュアルクエリを行うこと、及び、各々に関連付けられた要素を識別することに関連付けられた、これらの４つのレベルの処理をさらに詳述する。

反射的処理を行うには、典型的には、ほんの一瞬のみを要する。いくつかの処理は、めったにリフレッシュされることはない（例えば、カメラ解像度であるもの）。他の処理−カメラ焦点の査定など−は、１秒に数回（例えば、１回又は２回から数十回まで−フレームキャプチャ毎に、など）繰り返されうる。通信コンポーネントは単に、ネットワーク接続の存在をチェックしてもよい。プロトボーブル（アナログボーブル）が、画像分割の全体の査定（例えば、明るいスポットがあるか？）に基づいて配置されてもよい。基本画像分割の時間的態様には、例えば、赤いブロブの、３ピクセル右への−あるフレームから次のフレームへの−流れなどが通知されてもよい。キャプチャされた２Ｄ画像は、画面上に提示される。ユーザは典型的には、このレベルでは関与しないが、ただし、例えば、ユーザ入力−タップされたボーブルのような−が承認される。

条件付き処理を行うには、より長い時間がかかり（しかし、典型的には１秒未満）、例えば、約０．５秒毎にリフレッシュされうる。これらの処理の多くは、コンテキストデータ及びユーザ入力への作用に関する。これらには、類似のコンテキスト状況で前回、ユーザが何のアクションに着手したか（例えば、ユーザが歩いて仕事に行く途中でしばしばスターバックスに入る）を呼び戻すこと、所望の冗長についてのユーザ命令に応答すること、現在のデバイス状態（例えば、飛行機モード、省電力モード）に基づいて動作を構成すること、初歩的な向き調節動作を行うこと、ジオロケーションを決定することなどが含まれる。現在の画像及び他のコンテキストに関連のあるように見える認識エージェントがアクティベートされ、又は、アクティベートのために準備される（例えば、画像が少々テキストのように見えるので、可能なＯＣＲ認識のための処理を準備する）。認識エージェントは、同じく実行中である他のエージェントに気付くことができ、他のエージェントによる使用のために、結果をブラックボードに投稿することができる。ある動作からの出力を示すボーブルが、画面上に現れる。クラウドベースのリソースとのハンドシェイキングが行われて、使用するためのデータチャネルが準備され、チャネルの品質がチェックされる。クラウドベースのオークションを伴う処理では、そのようなオークションが、関連のある背景情報（例えば、ユーザに関する）と共に公表され、異なるクラウドベースのエージェントが参加するかどうかを決定し、且つ、あらゆる必要な準備を行うことができるようにしてもよい。

直観型の処理を行うには、さらにより長い時間がかかるが、大部分はデバイス自体においてである。これらの処理は一般に、認識エージェントをそれらの作業でサポートすること−必要とされたキーベクトルを合成すること、関連付けられたＵＩを提示すること、関連機能を呼び出すこと、リソースに対する競合する要求に応答し、そのバランスを取ることなどを伴う。システムは、何のセマンティック情報が望まれるか、又は、ユーザによって望まれる可能性が高い場合があるかを見極める。（スターバックスにいるユーザが典型的に、ニューヨークタイムズ紙（Ｎｅｗ Ｙｏｒｋ Ｔｉｍｅｓ）の表紙を撮像する場合、ＯＣＲに関連付けられた動作が−ユーザの要求なしに−開始されてもよい。同様に、テキストのような画像の提示が、ＯＣＲ及びスペイン語への翻訳を要求するようにユーザに促したことが過去にあった場合、これらの動作を開始することができ−クラウドベースの翻訳エンジンを用意することが含まれる。）関連のあるオントロジー（Ｏｎｔｏｌｏｇｉｅｓ）が識別され、用いられてもよい。認識エージェントによって投稿された出力ボーブルを、デバイスによる、キャプチャされたシーンの理解に従って、幾何学的に再マッピングすることができ、他の態様の３Ｄ理解を適用することができる。ルールエンジンは、外部データチャネル上のトラフィックを監視し、それに応じて応答することができる。迅速なクラウドベースの応答が、−しばしば、メニュー、ウィンドウ、及び、他のインタラクティブなグラフィカルコントロールと共に−ユーザに戻され、提示されてもよい。機能のサードパーティライブラリもまた、このレベルで関与することがある。

最終的な深いソリューションにはタイミングの制約がなく−数秒から数分、又はそれより長く延びることがあり、典型的には、クラウド及び／又はユーザを関与させる。直観型の処理は典型的には、個々の認識エージェントを伴うのに対して、深いソリューションは、例えば、関連付けによってインタラクトする、いくつかのそのようなエージェントからの出力に基づいてもよい。ソーシャルネットワーク入力もまた、例えば、同等者グループ、ユーザが尊敬する、流行を作る人々、彼らの経歴などについての情報を使用して、この処理に関与することがある。クラウドに出ると、例えば、複数のリモートエージェントがサービスをデバイスに提供しようとして競合するとき、複雑な処理が展開中であることがある。クラウドに以前に提出されたあるデータは、より多くの又はよりよいデータの要求を促すことがある。以前にリソースの不足に苦しんだ認識エージェントはこのとき、他の状況が出力のニーズをクリアしたために、それらの認識エージェントが望むすべてのリソースを許可されうる。自由の女神（Ｓｔａｔｕｅ ｏｆ Ｌｉｂｅｒｔｙ）の近くの、誰もがほしがる１０×２０ピクセルの部分は、ハッピーボーブルプロバイダに与えられ、このプロバイダは、その部分をタップするユーザ向けに楽しいインタラクティブ体験を配置している。クラウドへのデータの定期的な流れが確立されて、進行中のクラウドベースの、ユーザの要望の充足がもたらされてもよい。他の処理−多くはインタラクティブ−が、視覚的検索の結果として、このフェーズの動作で起動されてもよく、例えば、スカイプ（Ｓｋｙｐｅ）セッションを確立すること、ユーチューブ（ＹｏｕＴｕｂｅ）デモンストレーションビデオを見ること、ＯＣＲされたフランス語のメニューを英語に翻訳することなどである。

デバイスの起動時（又は、その動作の他のフェーズで）、デバイスは、入手可能であり、適用する準備ができている認識エージェントの一部又は全部に対応するボーブルを表示してもよい。これは、車が最初にスタートされるとき、ダッシュボードのすべての警告灯が明るくなり、警告灯が必要に応じて機能することができることを実際に示すことに類似している（又は、マルチプレイヤオンラインゲームで、集まった宝物及び武器−ユーザがドラゴンとの戦いでそこから引き出すことがあるツール及びリソースなど−を、プレイヤが見せることに類似している）。

この構成は例示的でしかないことは理解されよう。他の実装では、他の構成を当然使用することができる。
トップダウン及びボトムアップ、遅延アクティベーション（Ｌａｚｙ Ａｃｔｉｖａｔｉｏｎ）構造

アプリケーションは、様々な方法で開始されてもよい。１つは、ユーザ命令によるもの（「トップダウン」）である。

大抵のアプリケーションは、あるセットの入力データ（例えば、キーベクトル）を必要とし、出力データ（例えば、キーベクトル）のセットを作り出す。ユーザが（例えば、ボーブルをタップする、メニューとインタラクトする、ジェスチャーする、又は、その他のことによって）、アプリケーションを起動するようにシステムに命令する場合、システムは、「必要とされたキーベクトル」リスト又はツリーを構築することによってなど、何の入力が必要とされるかを識別することによって、開始することができる。必要とされたキーベクトルのすべてが（例えば、ブラックボード上に、又は「存在するキーベクトル」リスト又はツリー内に）存在する場合、アプリケーションは実行し（おそらく、明るいボーブルを提示し）、対応する出力データを生成することができる。

必要とされたキーベクトルのすべてが存在するのではない場合、アプリケーションに対応するボーブルが表示されてもよいが、薄暗い表示のみである。キーベクトル出力の逆ディレクトリを調べて、ユーザにより開始されたアプリケーションのための入力として必要とされたキーベクトルを提供するために実行されうる、他のアプリケーションを識別することができる。それらの他のアプリケーションによって必要とされたキーベクトルのすべてを、「必要とされたキーベクトル」に追加することができる。この処理は、これらの他のアプリケーションによって必要とされたキーベクトルのすべてが「存在するキーベクトル」内に入るまで、継続する。これらの他のアプリケーションが、次いで実行される。それらの結果として生じる出力キーベクトルのすべてが、「存在するキーベクトル」リストに入力される。トップレベルのアプリケーションのために必要とされた別のキーベクトルが入手可能になるたびに、そのアプリケーションのボーブルが明るくされてもよい。最終的に、必要な入力データのすべてが入手可能であり、ユーザによって開始されたアプリケーションが実行される（且つ、明るいボーブルは、その事実を公表してもよい）。

アプリケーションを実行させることができるもう１つの方法は、「ボトムアップ」であり−その入力データの可用性によってトリガされる。ユーザがアプリケーションを呼び出し、次いで、必要なデータを待つのではなく、処理が予約される。データの可用性は、アプリケーションのアクティベーション（及び、しばしば、次いで選択）を促進する。関連する作業は、「遅延評価」又は「遅延アクティベーション」という名前で知られている。

遅延アクティベーション構造の１つの特定の実装は、人工知能、すなわち、生産システムアーキテクチャの分野から引き出す。生産は典型的には、２つの部分−条件（ＩＦ）及びアクション（ＴＨＥＮ）を有する。これらの部分は、格納されたルールの形式（例えば、ある楕円が存在する場合、その楕円内のピクセルの大多数が肌の色合いの色を有するかどうかをチェックする）を取ってもよい。条件は、いくつかの要素を、論理結合において有することができる（例えば、ある楕円が存在する場合、且つ、その楕円の高さが少なくとも５０ピクセルである場合、次いで．．．）が、そのようなルールはしばしば、一連のより単純なルールに分解されうるものであり、それが時として好ましいことがある（例えば、ある楕円が検出される場合、その楕円の高さが少なくとも５０ピクセルであるかどうかをチェックし、その楕円の高さが少なくとも５０ピクセルである場合、次いで．．．）。

これらのルールは、ワーキングメモリ−ソリューション処理の現在の状態を表現するストア（例えば、ブラックボードデータ構造）−に対して評価される。

条件を述べるルールが満たされる（マッチされる）とき、アクションは一般に実行され−時として、熟慮を受ける。例えば、いくつかの条件が満たされるとき、システムは、さらに熟慮して、どの順序でこれらのアクションを実行するかを決定しなければならない。（あるアクションを実行することで、−場合によっては−他のマッチ条件を変更することがあるので、どのように熟慮が決定されるかに応じて、異なる結果が後に続くようになることがある。熟慮のための手法には、例えば、マッチされたルールを、それらのルールがルールデータベース内でリストされる順序に基づいて、又は、異なるルールに割り当てられた異なる優先度を参照することによって、実行することが含まれる。）

これらの構成は時として、マッチ／熟慮（又は評価）／実行構成と呼ばれる（Ｃｒａｉｇ、Ｆｏｒｍａｌ Ｓｐｅｃｉｆｉｃａｔｉｏｎｓ ｏｆ Ａｄｖａｎｃｅｄ ＡＩ Ａｒｃｈｉｔｅｃｔｕｒｅｓ、Ｅｌｌｉｓ Ｈｏｒｗａｒｄ，Ｌｔｄ．、１９９１年を参照）。場合によっては、「マッチ」ステップは、ユーザがボタンを押すことによって、又は、システムが、ボトムアップのモダリティにあること、若しくは、検知されたコンテンツに明示的に結び付けられないある他の条件によって、満たされてもよい。

述べたように、条件付きルールは、処理を開始する−評価されなければならない基準である。本状況では、条件付きルールは、ある入力データの可用性に関係することがある。例えば、現在の「存在するキーベクトル」ツリーを、システムにインストールされたトップレベルアプリケーションの全リストと比較することによって、「ボトムアップ」処理を定期的にアクティベートすることができる。アプリケーションの入力要件のいずれかが既に存在する場合、アプリケーションは実行を開始することができる。

アプリケーションの入力要件の一部（しかし、全部ではない）が既に存在する場合、対応するボーブルが、適切な表示領域内に、すべてのその入力が満たされることがどのくらい近いかを示す明るさで表示されてもよい。すべてのその入力が満たされた後、アプリケーションは、ユーザ入力なしで起動してもよい。しかし、多くのアプリケーションは、「ユーザアクティベーション」入力を有することがある。ボーブルがユーザによってタップされる場合（又は、別のＵＩデバイスがユーザアクションを受信する場合）、アプリケーションはトップダウン起動モードに切り替えられて−他のアプリケーションを開始し−上述のように−、残りの述語（ｐｒｅｄｉｃａｔｅ）入力データが収集されるので、トップレベルアプリケーションが次いで実行することができるようになる。

同様に、そのための一部の（全部ではない）入力が入手可能であるアプリケーションは、コンテキストなど、状況によって、トップダウンのアクティベーションに与えられてもよい。例えば、ある条件である機能をアクティベートするという、ユーザの過去にあったパターンは、推論されたユーザの意図としての機能を果たすことができ、それらの条件が繰り返されるとき、その機能がアクティベートされるべきであることを知らせることができる。（このようなアクティベーションは、推論されたユーザの意図が十分に強制的である場合、必要な入力が入手可能でなくても、起こることがある。）

（いくつかの実装では、従来の生産システム技術は、多数のルールが評価されることにより、扱いにくくなりうる。どのルールの条件が満たされるかを決定するための一般化されたトライ（ｔｒｉｅ）パターンマッチング手法など、最適化が用いられうる。例えば、Ｆｏｒｇｙ、「Ｒｅｔｅ：Ａ Ｆａｓｔ Ａｌｇｏｒｉｔｈｍ ｆｏｒ ｔｈｅ Ｍａｎｙ Ｐａｔｔｅｒｎ／Ｍａｎｙ Ｏｂｊｅｃｔ Ｐａｔｔｅｒｎ Ｍａｔｃｈ Ｐｒｏｂｌｅｍ」、Ａｒｔｉｆｉｃｉａｌ Ｉｎｔｅｌｌｉｇｅｎｃｅ、Ｖｏｌ．１９、１７〜３７ページ、１９８２年を参照されたい。）

前述のような構成では、リソースは、実行の準備ができている−又は、ほぼそうである−機能にのみ適用される。機能は、日和見的に−適切な入力データの可用性が値するとき−アクションを開始させられる。
定期的に行われる画像処理

いくつかのユーザが望む動作は常に複雑過ぎて、ポータブルシステム単体では行うことができないものであり、クラウドリソースが関与しなければならない。逆に、ポータブルシステムが、クラウドリソースを全く使用することなく行うことができるべきである、いくつかの画像関連動作がある。

後者を可能にし、前者を容易にするために、システム設計者は、機能によって又はユーザによって要求されることなく、キャプチャされた画像上でルーチン的に行われる、基本的な画像処理演算のセットを指定してもよい。このような定期的に行われるバックグラウンド機能は、他のアプリケーションが入力として使用することができる素材（ｆｏｄｄｅｒ）（キーベクトルとして表された出力データ）を提供してもよい。これらのバックグラウンド機能のうちいくつかはまた、別の目的を果たすこともでき、すなわち、他のデバイス及びクラウドリソースへの効率的な転送、及び、他のデバイス及びクラウドリソースによる利用ための、画像関連情報の標準化／抜き出しである。

第１のクラスのそのような定期的に行われる動作は一般に、１つ又は複数の画像フレーム（又はその一部）を入力として取り、画像フレーム（又は部分フレーム）キーベクトルを出力として作り出す。例示的動作には、以下が含まれる。
・・画像的（又は関心領域的）サンプリング又は補間：出力画像はソースと同じ寸法を有していないことがあり、ピクセル深度も必ずしも同じではない
・・ピクセル再マッピング：出力画像はソースと同じ寸法を有しているが、ピクセル深度は同じである必要はない。各ソースピクセルは独立してマッピングされる
・・・例：閾値化、「疑似色」、ピクセル値を典型値に置き換える
・・局所演算：出力画像はソースと同じ寸法を有しているか、又は、標準の方法で（例えば、黒い画像境界を追加して）拡張される。各宛先ピクセルは、対応するソースピクセルの周囲の固定サイズの局所近傍によって定義される
・・・例：６×６のソーベル垂直エッジ、５×５のライン−エッジの大きさ、３×３の極大など
・・空間的再マッピング：例えば、遠近法によるか、又は、曲率の「歪み」を補正する
・・新しい空間内の「画像」へのＦＦＴ又は他のマッピング
・・画像計算：出力画像は、入力画像の和、最大などである
・・・シーケンス平均：各出力画像は、平均してｋ個の連続する入力画像となる
・・・シーケンス（ｏｐ）ｉｎｇ：各出力画像は、ｋ個の連続する入力画像の相関的要素である

第２のクラスのそのようなバックグラウンド動作は、１つ又は複数の入力画像（又はその一部）を処理して、１Ｄ又は２Ｄ領域又は構造のリストからなる出力キーベクトルを生じる。この第２のクラスの例示的動作には、以下が含まれる。
・・長い直線の抽出：抽出された直線の線分（例えば、終点及び長さと共に、傾き−切片の形式で表される）のリストを返す
・・長い直線が交差する点のリスト（例えば、行／列の形式で表される）
・・楕円ファインダ：抽出された楕円のリストを返す（この場合及び他の場合、注目された特徴の場所及びパラメータがリストに含まれる）
・・円柱ファインダ：可能性のある３Ｄ円柱のリストを返す（長い直線を使用）
・・ヒストグラムベースのブロブ抽出：それらのローカルヒストグラムによって区別される画像領域のリストを返す
・・境界ベースのブロブ抽出：それらの境界特性によって区別される画像領域のリストを返す
・・各コンポーネントブロブ（完全画像を含む）が、その中に完全に含まれる互いに素のサブブロブを有する、ブロブ「ツリー」。有用なスケール不変の（又は、少なくともスケール耐性の）情報を保持することができる
・・・例：画像を複数の閾値で閾値化した結果
・・厳密な境界、例えば、閾値化されたブロブ領域の厳密な境界
・・不明瞭な境界、例えば、閾値化されたブロブの境界とは異なり、適度に密な領域境界をもたらすが、小さい間隙又は不一致を有することがある、エッジ又は点のリスト

第３のクラスのそのようなルーチンの、進行中の処理は、出力キーベクトルデータとして、テーブル又はヒストグラムを作り出す。この第３のクラスの例示的動作には、以下が含まれる。
・・色相、彩度、色、明るさ、エッジ値、テクスチャなどのヒストグラム
・・例えば、１Ｄ値の、特徴共起を示す、２Ｄヒストグラム又はテーブル：（色相、彩度）、（ｘ−彩度、ｙ−彩度）、又は、ある他の組み合わせ

第４のクラスのそのようなデフォルトの画像処理演算は、共通の非画像オブジェクトにおける動作からなる。この第４のクラスの例示的動作には、以下が含まれる。
・・分割／マージ：入力ブロブリストは、新しい異なるブロブリストを生じる
・・境界修復：入力ブロブリストは、より滑らかな境界を有するブロブのリストを生じる
・・ブロブ追跡：入力ブロブリストのシーケンスは、ブロブシーケンスのリストを生じる
・・正規化：画像ヒストグラム、及び、ヒストグラムベースのブロブのリストは、画像を（おそらく、「領域タイプ」値及び「バックグラウンド」値（複数可）へ）再マッピングするためのテーブルを返す

前述の動作は当然、例示的でしかない。ルーチン的に行うことができる、大変多くの他の低レベルの動作がある。上記のタイプのかなり大きいセットは、しかし、一般に有用であり、かなり小さいライブラリを必要とし、一般に入手可能なＣＰＵ／ＧＰＵ要件内で実装可能である。
コンテキスト的にトリガされた画像処理：バーコード復号

これまでの考察は、システムが、様々なより特化された機能のための入力としての機能を果たすことができるキーベクトルデータを提供するために、ルーチン的に行ってもよい様々な動作について述べた。これらのより特化された機能は、トップダウンの方法で（例えば、ユーザ命令によって）、又は、ボトムアップの方法で（例えば、すべてのデータ述語の可用性によって）開始することができる。

直前に詳述された動作に加えて、システムはまた、処理を起動して、コンテキストに基づいて他のキーベクトルを生成してもよい。

例示のため、場所を考えられたい。ジオロケーションデータを参照することによって、デバイスは、ユーザが食料雑貨店にいると決定してもよい。この場合、システムは、食料雑貨店に一般に関連のあるアプリケーションにとって有用でありうるキーベクトルデータを生成する、追加の画像処理演算の実行を自動的に開始してもよい。（これらの自動的にトリガされたアプリケーションは、さらに、そのトリガされたアプリケーションのための入力を提供するために必要とされる、他のアプリケーションを呼び出してもよい。）

例えば、食料雑貨店で、ユーザはバーコードに遭遇すると予期されうる。バーコード復号には、２つの異なる態様が含まれる。第１は、視野内でバーコード領域を発見することである。第２は、識別された領域内でラインシンボロジーを復号することである。前者の態様に関連付けられた動作は、ユーザが食料雑貨店（又は他の小売店）にいると決定されるとき、ルーチン的に着手することができる。すなわち、以前に詳述された、ルーチン的に行われる画像処理演算のセットは、−食料雑貨店内のユーザの場所によってトリガされた−コンテキスト的にトリガされた動作のさらなるセットの追加によって、一時的に拡大される。

バーコードの発見は、画像のグレースケールバージョンを解析して、水平方向に高い画像コントラスト、及び、垂直方向に低い画像コントラストを有する領域を識別することによって、行うことができる。したがって、食料雑貨店内であるとき、システムは、ルーチン的に行われる画像処理演算のカタログを拡大して、例えば、対象ピクセルの両側２〜８ピクセルなど、位置測定される水平グレースケール画像コントラストの測定の計算をも含めてもよい。（１つのこのような測定は、複数の近接したピクセルの値の差異の絶対値を合計することである。）コントラスト情報のこのフレーム（すなわち、ダウンサンプリングされたフレーム）は、キーベクトル−そのコンテンツについてラベルが付けられ、他の処理が見て使用するために投稿される−を含むことができる。同様に、システムは、位置測定される垂直グレースケール画像コントラストを計算し、これらの結果を別のキーベクトルとして投稿することができる。

システムは、画像内の点毎に、ローカル垂直画像コントラストの計算された測定を、ローカル水平画像コントラストの計算された測定から減算することによって、これらの２つのキーベクトルをさらに処理してもよい。通常、この動作は、雑然としたデータのフレームを−強度に正の点で、且つ、強度に負の点で−生じる。しかし、バーコード領域では、雑然さがはるかに少なく−バーコード領域にわたって強度に正の値を有する。このデータもまた、他の処理が、ユーザが食料雑貨店内にいる間にルーチン的に作り出されるさらにもう１つの（第３の）キーベクトルとして見るために、投稿することができる。

第４のキーベクトルを、閾値化動作を適用すること−ターゲット値を超える値を有する点のみを識別すること−によって、第３のキーベクトルから作り出してもよい。この動作はしたがって、画像内で、特性において潜在的にバーコードのように、すなわち、水平コントラストが強く、垂直コントラストが弱いように見える点を識別する。

第５のキーベクトルを、連結成分解析を適用すること−特性において潜在的にバーコードのように見える点の領域（ブロブ）を定義すること−によって、第４のキーベクトルから作り出してもよい。

第６のキーベクトルを、第５のキーベクトルによって作り出してもよく−３つの値からなり、すなわち、最大ブロブ内の点の数、並びに、そのブロブの左上隅及び右下隅の場所（画像フレームの左上隅のピクセルからの行及び列オフセットで定義される）である。

これらの６つのキーベクトルは、将来を見越して作り出される−ユーザが明示的にこれらのキーベクトルを要求することなく、ただ、ユーザが、食料雑貨店に関連付けられた場所にいるからである。他のコンテキストでは、これらのキーベクトルは通常、作り出されることはない。

これらの６つの動作は、単一の認識エージェント（すなわち、バーコード位置指定エージェント）を含んでもよい。又は、これらの６つの動作は、より大きい認識エージェント（例えば、バーコード位置指定／読み取りエージェント）の一部であってもよく、又は、個々に若しくは組み合わせてそれら自体の認識エージェントである下位機能であってもよい。

（バーコード読み取り処理における、より少数又はさらなる動作が同様に行われてもよいが、これらの６つは要点を例示する。）

バーコードリーダアプリケーションは、デバイス上にロードされたものの中にあってもよい。食料雑貨店内であるとき、バーコードリーダアプリケーションは、とても低いレベルの動作−例えば、１５，０００を超える値を求めて、上述の第６のキーベクトルの第１のパラメータを調べるに過ぎないことを行う−で、うまくいくことがある。このテストが満たされる場合、バーコードリーダは、システムに対し、ぼんやりとしたバーコードを示すボーブルを、この第６のキーベクトルの第２及び第３のパラメータによって識別されたブロブの隅の点の場所の間の中間にあるフレーム内の場所で提示するように、命令してもよい。このボーブルは、バーコードかもしれない何か、及び、フレーム内でそれが現れる場所をデバイスが検知したことを、ユーザに伝える。

ユーザがそのぼんやりとしたボーブルをタップする場合、これは、バーコードを復号するために必要とされた他の動作を（トップダウンで）起動する。例えば、第６のキーベクトル内で識別された２つの隅の点の間の画像の領域が抽出され−第７のキーベクトルが形成される。

一連のさらなる動作が次いで、続いて起こる。これらの動作には、抽出された領域を低周波エッジ検出器によりフィルタリングすること、及び、ハフ変換を使用して、ほぼ垂直な線を検索することが含まれうる。

次いで、フィルタリングされた画像内の行毎に、開始、中央及び終了バーコードパターンの位置が、バーコードの評価済みの右及び左のエッジをガイドとして使用して、相関を通じて識別される。次いで、バーコードの数字毎に、行内の数字の位置が決定され、行のその位置のピクセルが可能性のある数字コードと相関させられて、最良のマッチが決定される。これがバーコードの数字毎に繰り返され、候補バーコードペイロードが生じる。パリティテスト及びチェックディジットテストが次いで、その行からの結果に対して実行され、そのペイロードの発生カウントがインクリメントされる。これらの動作が次いで、フィルタリングされた画像内でさらにいくつかの行に対して繰り返される。最高発生カウントを有するペイロードが次いで、正しいバーコードペイロードと見なされる。

この時点で、システムは、バーコードのボーブルを明るく照らすことができ−データが満足に抽出されたことを示すことができる。ユーザが明るいボーブルをタップする場合、デバイスは、アクションのメニューを提示することができ、又は、復号されたバーコードに関連付けられたデフォルトのアクションを起動することができる。

直前に記載された構成では、システムは、第６のキーベクトルを生成した後、そのルーチン動作を停止するが、さらに進行した可能性がある。しかし、リソース制約のため、機会がある毎に、例えば、第６のキーベクトルの第１のパラメータが１５，０００を超えるとき、さらに進行することは実用的でないことがある。

１つの代替構成では、システムは、例えば、３秒に一回、さらに進行してもよい。各３秒間隔の間、システムは、第６のキーベクトルの第１のパラメータを監視し−（１）１５，０００を超える値、及び（２）その３秒間隔内ですべての以前の値を超える値を探す。これらの条件が満たされるとき、システムは、このフレームをバッファし、おそらく、いずれかの予めバッファされたフレームに上書きすることができる。３秒間隔の終わりに、フレームがバッファされる場合、そのフレームは、その３秒間隔内のいずれかの第１のパラメータの最大値を有するフレームである。そのフレームから、システムは次いで、−有効なバーコードペイロードがうまく復号される場合、ボーブルを明るく照らす間ずっと−関心領域を抽出し、低周波エッジ検出器を適用し、ハフ手順を使用して線を発見すること等々を行うことができる。

機械的に３秒毎にバーコード読み取り動作を完了しようとするのではなく、システムは、日和見的に−中間結果が特に見込みがあるとき−そのようにすることができる。

例えば、関心領域内の点の数が１５，０００を超えるときは常に、バーコード読み取り処理が進行してもよいが、その値は、バーコード読み取りの試行が実りの多い可能性がある最小閾値である。バーコードをうまく読み取る可能性は、この点の領域がより大きくなるにつれて増す。そのため、３秒に１回、復号処理でさらに進行するのではなく、さらなる処理が、第６のキーベクトルの第１のパラメータで５０，０００（又は、１００，０００若しくは５００，０００など）を超える値の発生によってトリガされてもよい。

このような大きい値は、はっきりと見えるバーコードがカメラのビューイングフレームのかなりの要部を占めることを示す。これは、ユーザによる意図的なアクション−バーコードのよいビューをキャプチャすること−を示唆する。この場合、バーコード読み取り動作の残りを起動することができる。これは、直観的感覚をデバイスの振る舞いにもたらし、すなわち、ユーザはバーコードを撮像することを明らかに意図し、システムは−いかなる他の命令もなしに−バーコード読み取り動作を完了するために必要とされたさらなる動作を起動したということである。

同様に、システムは−あるタイプの動作に特に適した画像情報の可用性から−そのあるタイプの動作をユーザが意図するか、又はそれによって利益を得るであろうと推論することができる。システムは次いで、その動作のために必要とされた処理に着手し、直観的応答を生じることができる。（テキストのような画像は、ＯＣＲ処理に関連付けられた動作をトリガすることができ、顔のような特徴は、顔認識に関連付けられた動作をトリガすることができる、などである。）

これは、コンテキストにかかわらず、行うことができる。例えば、デバイスは、現在の環境についてのある手がかりを周期的にチェックすることができ、例えば、−バーコードがビュー内にあるかもしれない場合に備えて−画像フレーム内の水平対垂直グレースケールコントラストを時々チェックする。そのような動作は、ルーチン的にロードされ、又は、コンテキストのためにロードされたものの中にはないことがあるが、例えば、いずれにしても５秒に１回ほど着手することができ、その理由は、計算コストが小さく、視覚的に有用な情報の発見がユーザによって評価されうるからである。

コンテキストに戻ると、ユーザの場所が食料雑貨店内であったため、システムが異なるセットのバックグラウンド画像処理演算に自動的に着手したと同時に、システムは、他の状況又はコンテキストに基づいて、そのセットのルーチン的に発生する処理動作を同様に適合させることができる。

１つは、履歴（すなわち、ユーザの、又は、ユーザの社会的な同等者の）である。通常、我々は、自宅でバーコードリーダを使用することはない。しかし、本のコレクターは、家庭の書庫にある新しい本を、それらの本のＩＳＢＮバーコードを読み取ることによってカタログ化することがある。最初にユーザが自宅でこの機能性のためにデバイスを用いるとき、上述の第１から第６のキーベクトルを生成する動作がトップダウンの方法で起動される−ユーザがデバイスのＵＩを通じて、バーコードの読み取りに関心があることを示すので、起動される−ことが必要である場合がある。２回目も同様である。しかし、システムは、（１）特定の場所、すなわち自宅にいるユーザ、及び（２）バーコード読み取り機能性のアクティベーションの、繰り返された共起に気付くことが望ましい。そのような過去にあったパターンが確立された後、システムは、ユーザが自宅の場所にいるときは常に、上述の第１から第６のキーベクトルの生成をルーチン的に可能にしてもよい。

システムは、ユーザがバーコード読み取り機能性を自宅で夕方にのみアクティベートすることを、さらに見極めてもよい。このように、時間もまた、ある画像処理演算の自動起動をトリガする、別のコンテキスト的要因であることが可能であり、すなわち、これらのキーベクトルは、ユーザが夕方に自宅にいるとき、生成される。

社会的な情報もまた、トリガリングデータを提供することが可能である。ユーザは、一人で行う趣味としてのみ、本をカタログ化することがある。配偶者が家にいるとき、ユーザは本をカタログ化しないことがある。配偶者が家にいることは、様々な方法で検知されてもよい。１つは、配偶者の携帯電話からのブルートゥース（Ｂｌｕｅｔｏｏｔｈ）無線信号ブロードキャストによるものである。このように、バーコード位置指定キーベクトルは、（１）ユーザが自宅にいる、（２）夕方に、（３）ユーザの配偶者の近くではないとき、自動的に生成されてもよい。配偶者がいる場合、又は、昼間である場合、又は、ユーザが家（及び、食料雑貨店）から離れている場合、システムは、バーコード位置指定に関連付けられたキーベクトルをルーチン的に生成しないことがある。

このような繰り返される状況の共起を検出するために、ユーザの振る舞いのベイズ又は他の統計モデルをコンパイル且つ利用し、次いで、それに基づいてアクションをトリガするために使用することができる。

（これに関連して、マイクロプロセッサ設計における分岐予測の科学は、情報を与えるものでありうる。現代のプロセッサは、数十段階を含むことがあるパイプラインを含み−１５又は２０ステップ先で使用されるべき命令をフェッチするロジックを必要とする。誤った推測があると、パイプラインのフラッシュが必要となり−性能面で著しい不利益を被る可能性がある。マイクロプロセッサはしたがって、分岐予測レジスタを含み、このレジスタは、例えば、過去２５５回で条件付き分岐がどのように解決されたかを追跡する。このような履歴情報に基づいて、プロセッサの性能は大幅に強化される。同様に、−ユーザ及び代理人（例えば、ユーザの社会的な同等者、又は、人口統計学的な同等者）の双方による−デバイス使用の過去にあったパターンを追跡すること、及び、そのような情報に基づいてシステムの振る舞いを調整することで、重要な性能改善をもたらすことができる。）

音声の手がかり（さらに後述する）もまた、ある画像処理演算の自動トリガリングに関与してもよい。聴覚の手がかりが、ユーザが屋外にいることを示唆する場合、あるセットの追加のバックグラウンド処理動作を起動することができ、この手がかりが、ユーザが運転中であることを示唆する場合、異なるセットの動作を起動することができる。音声がテレビのサウンドトラックの顕著な特徴を有する場合、又は、この音声が、ユーザが職場環境にいることを示唆する場合、同様である。システムにロードされ、実行中のソフトウェアコンポーネントは、このように、その特定の環境内で−遭遇することがある刺激−又は、ユーザが要求することがある動作−を予想して、自動的に適合することができる。（同様に、異なる音声処理動作を適用して、異なる音声機能によって必要とされたキーベクトルを生成する聴覚デバイスでは、視覚的環境から検知された情報は、通常は実行されることがないある音声処理動作が可能であることを指図するコンテキストを示すことができる。）

環境の手がかりもまた、ある機能が選択され、起動され、又は調整されることを可能にする。デバイスが、周辺温度が摂氏マイナス１０度であることを検知する場合、ユーザは、推定上、冬の屋外にいる。顔認識が（例えば、ユーザ命令によって、又は、他の手がかりによって）指示される場合、画像内に描かれたどの顔も帽子及び／又はスカーフにくるまっていることがある。したがって、異なるセットの顔認識動作が用いられる−顔のある部分のマスキングを考慮に入れる−ことは、例えば、コンテキストが、人々の髪及び耳が露出されると予期される暑い夏の日である場合よりも、ありうることである。

システムとの他のユーザインタラクションが気付かれ、−気付かれたユーザインタラクションがそのような動作を含まない場合であっても−通常は実行されないある画像処理演算の開始につながる可能性がある。（例えば、テキスト又は発話入力によって）デバイスのウェブブラウザに、近所のレストランを識別するためのクエリを出すユーザを考えられたい。このクエリは、カメラ又は画像を含むものではない。しかし、そのようなインタラクションから、システムは、ユーザが間もなく（１）場所を変更し、（２）レストラン環境にいるようになると、推論してもよい。したがって、システムは、例えば、（１）新しい場所にナビゲートすること、及び（２）レストランメニューに対処することにおいて、助けとなることがある画像処理演算を起動してもよい。

ナビゲーションは、カメラからの画像を、（例えば、ＳＩＦＴを使用して、グーグルストリートビュー（Ｓｔｒｅｅｔｖｉｅｗ）又は他の画像リポジトリからの）ユーザの予期されたルートに沿った縁石側の画像とパターンマッチングすることによって、支援されてもよい。関連のある画像をグーグルから獲得することに加えて、デバイスは、スケール不変の特徴変換動作に関連付けられた画像処理演算を開始することができる。

例えば、デバイスは、カメラによって異なるスケール状態でキャプチャされた画像フレームを再サンプリングし、各々についてのキーベクトルを作り出すことができる。これらの各々に対して、ガウス関数の差分（Ｄｉｆｆｅｒｅｎｃｅ ｏｆ Ｇａｕｓｓｉａｎｓ ｆｕｎｃｔｉｏｎ）が適用され、さらなるキーベクトルを生じてもよい。処理制約が許す場合、これらのキーベクトルをブラーフィルタにより畳み込み、またさらなるキーベクトルなどを作り出すことが−すべて、ＳＩＦＴパターンマッチングの使用の可能性を予想して−できる。

レストランメニューを見ることを予想して、ＯＣＲ機能性に付随する動作を起動することができる。

例えば、デフォルトのセットのバックグラウンド画像処理演算は、長いエッジのための検出器を含むが、ＯＣＲでは、短いエッジを識別することが必要となる。したがって、短いエッジを識別するアルゴリズムが起動されてもよく、この出力をキーベクトルにおいて表すことができる。

閉輪郭を定義するエッジを使用して、文字−候補ブロブを識別することができる。文字の線を、これらのブロブの位置から導出することができ、スキュー補正を適用することができる。文字ブロブのスキュー補正された線から、候補語領域を見極めることができる。パターンマッチングを次いで適用して、それらの語領域のための候補テキストを識別することができる。等々となる。

前述のように、これらの動作のすべてがあらゆる処理された画像フレームで行われうるとは限らない。ある初期の動作がルーチン的に行われてもよく、（１）タイミングトリガ、（２）これまでに処理されたデータの見込みがある属性、（３）ユーザ指示、又は（４）他の基準に基づいて、さらなる動作に着手することができる。

食料雑貨店の例に戻ると、コンテキストは、着手される画像処理演算のタイプに影響を与えることができるのみでなく、異なるタイプの情報（画像情報、並びに、例えばジオロケーションなど、他の情報の双方）に起因するように、意味に影響を与えることもできる。

食料雑貨店で画像のフレームをキャプチャする、ユーザの電話を考えられたい。電話は、直ちに応答し−ユーザがスープの缶の方に向いていることを示唆してもよい。電話は、ジオロケーションデータ及び磁力計（コンパス）データを、その特定の店のレイアウトについての格納された情報−カメラがスープの棚の方を向いていることを示す−と共に参照することによって、これを行うことができる。ボーブルは、その初期段階で、この最初の推測をユーザへ、例えば、食料雑貨店の品目を表すアイコンによって、又はテキストによって、又はリンクされた情報によって伝えてもよい。

一瞬の後、キャプチャされたフレーム内のピクセルの初期処理中に、デバイスは、白いピクセルのブロブの隣にある赤いピクセルのブロブを見極めてもよい。食料雑貨店コンテキストに関連付けられた参照データソースを参照することによって（且つ、ここでもまた、おそらく、ジオロケーション及びコンパスデータにも依拠して）、デバイスは、その品目がキャンベル（Ｃａｍｐｂｅｌｌ’ｓ）スープの缶（その可能性が最も高い）又はケチャップのボトル（その可能性がより低い）であると、迅速に（例えば、１秒未満で）推測してもよい。長方形を表示画面上に重ね合わせ−デバイスによって検討中であるオブジェクト（複数可）の輪郭を描いてもよい。

１秒後、デバイスは、白い背景上の、トマトスープと書かれた−キャンベルスープの仮説にさらなる信頼性を与える−大きい文字に対する、ＯＣＲ動作を完了していてもよい。さらに、短い間隔の後、電話は、画像の赤いエリア内の様式化されたスクリプト「キャンベル」をなんとか認識し−そのオブジェクトが、キャンベルの配色をまねているストアブランドのスープではないことを確認していてもよい。さらにすぐに、電話は、すぐ近くの缶で見えるバーコードを復号し、サイズ、ロット番号、製造日、及び／又は、キャンベルトマトスープに関する他の情報を詳述していてもよい。各段階で、ボーブル−又はリンクされた情報−は、カメラが向いている方のオブジェクトの、デバイスによる精緻化された理解に従って、進化する。（任意の時点で、ユーザは、デバイスに対し、−おそらく、素早く振ることによって−その認識作業を停止するように命令し、バッテリ及び他のリソースを他のタスクのために保つことができる。）

対照的に、ユーザが屋外にいる（例えば、ＧＰＳ及び／又は明るい日差しによって検知される）場合、白いピクセルのブロブの隣にある赤いピクセルのブロブに関する、電話の最初の推測は、キャンベルスープ缶ではない可能性が高くなる。むしろ、電話は、そのブロブを、米国の国旗、又は花、又は衣料品、又はギンガムのテーブルクロスであると推測する可能性の方が高いことがあり−ここでもまた、屋外コンテキストに対応する情報のデータストアを参照することによる。
直観的コンピューティングプラットフォーム（ＩＣＰ）コンテキストエンジン、識別子

アーサー Ｃ．クラークは、「十分に進歩したいかなる技術も、魔法と区別がつかない」と述べたと伝えられている。「進歩した」は、多くの意味を有する可能性があるが、魔法に似た何かをモバイルデバイスに吹き込むために、本明細書ではこの用語を「直観的」又は「スマート」と解釈する。

直観的振る舞いの重要な部分は、ユーザのありそうな意図を検知する−且つ、次いでそれに応答する−能力である。図１１に示すように、意図は、ユーザのみではなく、ユーザの過去の相関的要素でもある。加えて、意図は、ユーザの同等者のアクティビティ、及び、彼らの過去の相関的要素と見なすこともできる。

意図の決定においては、コンテキストが鍵となる。すなわち、例えば、どこにユーザがいるか、この場所で前回、何のアクティビティにユーザ及び他者が携わったかなどを知ることが、現時点でユーザの可能性の高いアクティビティ、ニーズ及び要望を見極める上で価値があるという意味で、コンテキストは意図の推定に情報を与える。ユーザの振る舞いについてのこのような自動化された推理は、人工知能の中心的な目標であり、この主題について多くのことが書かれてきた。（例えば、Ｃｈｏｕｄｈｕｒｙ他、「Ｔｏｗａｒｄｓ Ａｃｔｉｖｉｔｙ Ｄａｔａｂａｓｅｓ：Ｕｓｉｎｇ Ｓｅｎｓｏｒｓ ａｎｄ Ｓｔａｔｉｓｔｉｃａｌ Ｍｏｄｅｌｓ ｔｏ Ｓｕｍｍａｒｉｚｅ Ｐｅｏｐｌｅ’ｓ Ｌｉｖｅｓ」、ＩＥＥＥ Ｄａｔａ Ｅｎｇ．Ｂｕｌｌ、２９（１）：４９〜５８、２００６年３月を参照。）

画像、音声、動き情報、場所、及びブルートゥース信号など、センサデータは、ユーザの可能性が高いアクティビティを推論する際（又は、起こりそうもないアクティビティを除外する際）に有用である。Ｃｈｏｕｄｈｕｒｙで述べられたように、センサ情報を、複数のアクティビティの間で弁別する助けとすることができる特徴へと処理する、ソフトウェアモジュールに、そのようなデータを提供することができる。特徴には、高レベルの情報（周囲におけるオブジェクトの識別、又は、すぐ近くの人々の数、その他など）、又は、低レベルの情報（可聴周波数コンテンツ又は振幅、画像の形状、相関係数、その他など）が含まれうる。そのような特徴から、計算モデルは、起こりそうなアクティビティ（例えば、歩く、話す、コーヒーを買う、など）を推定することができる。

電話からのセンサデータがルーチン的に記録され、過去のアクティビティのパターンを見極めることができるようになることが望ましい。次には、ユーザが着手するアクティビティに注目し、このようなアクティビティを引き起こした（同時発生の、及び、直前の）コンテキストと相関させることができる。アクティビティは、さらに、そこからユーザの関心が推論されうる素材である。すべてのそのようなデータが格納され、ユーザが所与のコンテキストに携わることができる可能な行為を推定すること、及び、ユーザの関心のうちどれがそれらの状況において関連がありうるかを見極めることを、電話が行うことができるようにする、参考情報の本文としての役目を果たす。

そのような知能は、テンプレート、モデル又はルールベース形式（例えば、コンテキストデータの繰り返し発生するパターン、及び、−おそらく、関連付けられた信頼因子により−それと明らかに相関されるユーザの行為／関心を詳述する）で体系化されうる。リアルタイムのセンサデータが与えられると、そのようなテンプレートは、予期された意図についてのアドバイスをポータブルデバイスに提供することができるので、ポータブルデバイスはそれに応じて応答することができる。

これらのテンプレートは、継続的に精緻化されうるものであり−より多くの体験が記録されるにつれて、コンテキストの追加の態様（例えば、季節、天候、近所の友達など）と相関し、より多くの微妙な差異のあるパターンを見極めることができる。エキスパートシステムからのよく知られている技術が、この技術のこれらの態様の実装において適用されうる。

モバイルデバイスセンサによって提供された豊富なデータに加えて、コンテキスト（及び、したがって意図）を理解する際に有用な他の特徴を、すぐ近くのオブジェクトから導出することができる。木は、屋外コンテキストを示唆し、テレビは、屋内コンテキストを示唆する。いくつかのオブジェクトは、関連付けられたメタデータを有しており−コンテキスト上の理解を大幅に促進する。例えば、ユーザの環境内のいくつかのオブジェクトは、ＲＦＩＤなどを有することがある。ＲＦＩＤは、一意のオブジェクトＩＤを搬送する。これらの一意のオブジェクトＩＤに関連付けられ、典型的にはリモートデータストア内にあるものは、ＲＦＩＤが添付されるオブジェクトについての固定メタデータ（例えば、色、重さ、所有権、出所など）である。そのため、関連情報をピクセルのみから推定しようとするよりも、モバイルデバイス内−又は、モバイルデバイスがリンクする環境内−のセンサは、これらの情報のキャリアを検知し、関連メタデータを取得し、本コンテキストを理解する際にこの情報を使用することができる。

（ＲＦＩＤは例示的でしかなく、他の構成もまた用いることができ、例えば、デジタルウォーターマーキング、バーコード、フィンガープリンティングなどである。）

ユーザのアクティビティは複雑であり、オブジェクトデータもセンサデータも、曖昧でない結論に向いていないので、ユーザの可能性が高いアクティビティ及び意図を推論するための計算モデルは、一般に確率的である。生成技術を使用することができる（例えば、ベイズ、隠れマルコフなど）。クラス境界のための弁別技術（例えば、事後確率）もまた、用いることができる。関係確率的及びマルコフネットワークモデルでも、同様である。これらの手法では、確率は、ユーザの社会的グループ（複数可）内の他者のプロパティによって決まる可能性もある。

１つの特定の構成では、意図の決定は、コンテキストに関連するローカルデバイス観察に基づき、クラウドに格納されうるテンプレート（例えば、ユーザの履歴又は社会的な友達或いは他のグループの履歴など）に対してマッピングされる。

意図を見極めることによって、本技術は、刺激に対する可能な応答の探索空間を縮小し、本技術を使用して、入力データをセグメント化し、アクティビティ、オブジェクトを見極め、識別子を作り出すことができる。識別子を、明示的な導出されたメタデータにより構築することができる。

少々バックアップするため、あらゆるコンテンツオブジェクトが識別されることが望ましい。理想的には、オブジェクトの識別子は、グローバル一意且つ永続的となる。しかし、モバイルデバイスのビジュアルクエリでは、この理想は達成不可能であることが多い（ただし、例えば、デジタルウォーターマークなどの機械可読しるしを有するオブジェクトの場合を除く）。それにもかかわらず、ビジュアルクエリセッション内では、見極められた各オブジェクトが、セッション内で一意である識別子を有することが望ましい。

一意識別子（ＵＩＤ）の１つの可能な構成物には、２つ又は３つの（又はそれより多い）コンポーネントが含まれる。１つは、トランザクションＩＤであり、セッションＩＤであってもよい。（１つの適切なセッションＩＤは、疑似乱数であり、例えば、ＭＡＣ識別子など、デバイス識別子がシードされたＰＲＮジェネレータによって作り出されるものである。他の構成では、セッションＩＤは、センサが直前にオフ又はスリープ状態からアクティベートされたＵＮＩＸ時間など、セマンティック情報を搬送することができる）。このようなトランザクションＩＤは、他の識別コンポーネントのために必要とされる範囲を縮小する役目を果たし、識別子を一意にする助けとなる。このようなトランザクションＩＤはまた、オブジェクト識別を特定のセッション又はアクションのコンテキスト内に入れる。

識別子のもう１つのコンポーネントは、明示的オブジェクトＩＤであることが可能であり、以前に参照されたクランプＩＤであってもよい。これは典型的には、割り当てられた識別子である。（いくつかの明確に識別可能な特徴又はオブジェクトを含めるようにクランプが決定される場合、さらなるビットをクランプＩＤに付加して、同じものを区別することができる。）

さらにもう１つのコンポーネントを、オブジェクト又は状況から、何らかの方法で導出することができる。１つの簡単な例は、「フィンガープリント」−オブジェクト自体の特徴から導出された、統計的に一意の識別情報（例えば、ＳＩＦＴ、画像署名など）である。加えて、又は別法として、このコンポーネントは、コンテキスト、意図、推定された特徴−後続の処理によってアイデンティティの決定を支援するために使用することができる、本質的に任意のもの−に関する情報からなることがある。この第３のコンポーネントは、導出されたメタデータ、又は、オブジェクトに関連付けられた「オーラ」であると見なすことができる。

オブジェクト識別子は、そのようなコンポーネントの連結又は他の組み合わせでありうる。
パイスライスなど

システムによって呼び出された異なる認識処理は、並行して、又は、循環的な連続した方法で動作することができる。後者の場合、クロック信号などが、別々のパイスライスがアクティベートされる律動を提供してもよい。

図１２は、このような循環的処理構成を、パイスライスの循環として示す。各スライスは、認識エージェント処理又は別の処理を表す。矢印は、あるスライスから次のスライスへの進行を示す。右の拡大されたスライスによって示されるように、各スライスは、いくつかの別個の段階又は状態を含むことができる。

本技術が直面する問題は、リソース制約である。制約がなかったならば、視覚／聴覚デバイスは、無数のリソース集中的認識アルゴリズムを、入ってくるデータの各フレーム及びシーケンスに絶えず適用し−ユーザにとって潜在的な関心があるあらゆる項目について、各々をチェックすることができるであろう。

現実世界では、処理にはコストがかかる。この問題は、入ってくるデータに適用されるべきであり、且つ、各々に充てるためのリソースのタイプ及び量を動的に決定しているべきである、動的識別処理の１つとして表現することができる。

図１２では、パイスライス（認識エージェント処理）の異なる段階は、リソース消費のさらなるレベルに対応する。最も内部の（指し示された）段階は一般に、最も少ないリソースを使用する。累積リソース負荷は、スライスの連続する段階による処理により増大する。（各段階は、それに先行した段階よりもリソース集中的となることが多いが、このことは必須ではない。）

このタイプの振る舞いが達成可能である１つの方法は、認識及び他の動作を、モノリシックな動作としてではなく、「カスケードされた動作のシーケンス」として実装することによる。このようなシーケンスはしばしば、比較的低いオーバーヘッドを有する初期動作に関与し、これらの動作は−−成功するとき−−より多くのリソースを必要とすることがある動作によって継続されうるが、現在は、可能性の高い成功の初期インジケータの後にのみ開始される。この技術はまた、ある動作によって正常に使用された関連特徴に対する、既に使用可能なキーベクトルの日和見的代用を容易にし、ここでもまた、前述のように、リソースオーバーヘッドを減らすこともできる。

考察の目的で、顔認識エージェントを考えられたい。顔を識別するため、一連のテストが適用される。いずれかが失敗する場合、顔が存在することはありそうもないことである。

最初のテスト（多数の処理に共通する）は、カメラによって作り出された画像が、（例えば、暗いハンドバッグ又はポケット内にあるときのカメラ出力と対比して）いずれかの種類の特徴を有するかどうかをチェックすることである。これは、画像中のピクセルの場所のまばらなサンプリングのための、グレースケールピクセル値の単純なヒストグラム解析によって行われてもよい。ヒストグラム解析が、サンプリングされたピクセルのすべてが実質的に同じグレースケール出力を有することを示す場合、さらなる処理をスキップすることができる。

ヒストグラムが、ピクセルグレースケール値においてある多様性を示す場合、画像を次にエッジについてチェックすることができる。見極めることができるエッジのない画像は、使用不可能な画像、例えば、大変ぼけているか、焦点が合っていない画像である可能性が高い。上記に示したように、様々なエッジ検出フィルタが当業者によく知られている。

エッジが発見される場合、顔の検出手順は次に、いずれかのエッジが曲がっており、閉領域を定義するかどうかをチェックしてもよい。（ある実装ではルーチンのバックグラウンド動作として実行する楕円ファインダは、処理がこのステップで開始できるようにしてもよい。）

そうである場合、色ヒストグラムが行われて、閉領域内のかなりの割合のピクセルの色相が互いに類似するかどうかが判定されてもよい（肌は、顔の大部分を構成する）。「かなりの」は、３０％、５０％、７０％などより大きいことを意味してもよい。「類似」は、ＣＩＥＬＡＢの意味で距離閾値内又は角回転内を意味してもよい。事前定義された肌の色合いの範囲内の色のテストが、オプションで適用されてもよい。

次に、閾値化動作が適用されて、閉領域内の最も暗い５％のピクセルが識別されてもよい。これらのピクセルを解析して、これらのピクセルが、２つの目と調和するグループを形成するかどうかを判定することができる。

このようなステップは、同様に、顔の候補（複数可）のための固有ベクトルの生成中ずっと継続する。（顔の固有ベクトルは、顔の高次元ベクトル空間表現の確率分布の共分散行列から計算される。）そうである場合、−ローカル又はリモートの−参照データ構造内のマッチを求めて、固有ベクトルが検索されてもよい。

動作のいずれかが負の結果を生じる場合、システムは、見極めることができる顔が存在しないという結論を下し、そのフレームに対するさらなる顔発見の取組みを終了することができる。

これらのステップのすべてが、単一のパイスライス処理内の段階を形成することができる。別法として、１つ又は複数のステップは、基本的であり、且つ、いくつかの異なる処理にとって有用であると見なされてもよい。そのような場合、そのようなステップ（複数可）は、専用のパイスライス処理の一部を形成することはないが、代わりに別個でありうる。そのようなステップ（複数可）を、１つ又は複数のパイスライス処理で実装し−他のエージェント処理と共に循環的に実行し、それらの結果をブラックボードに投稿することができる（他のエージェントがそれらの結果を発見することができるかどうかにかかわらず）。又は、そのようなステップ（複数可）を、他の方法で実装することができる。

システムの制限されたリソースを、異なる進行中の処理に適用する際、検出状態は、有用な概念になりうる。各瞬間に、各エージェントによって求められる目標（例えば、顔を認識すること）に達する可能性がより多いか又はより少ないと思われうる。すなわち、各エージェントは、「大変見込みがある」から「中間的」を通じて「大変思わしくない」へと至る連続体における、瞬時検出状態を有してもよい。検出状態が「見込みがある」の場合、より多くのリソースがその取組みに割り振られてもよい。その検出状態が「思わしくない」に向かう傾向がある場合、より少ないリソースを割り振ることができる。（ある時点で、システムにそのエージェントの取組みを終了させる、思わしくない状態の閾値に達してもよい。）検出状態は、エージェント処理が関係する特定のパラメータに合わせて調整される（別個の、又は、エージェント処理に含まれる）ソフトウェアルーチンによって、循環的に定量化することができる。

あるリソースの割り振りの増大は、エージェント処理の次に続く段階が呼び出されるとき、発生する傾向がある（例えば、ＦＦＴ演算−７番目の段階で発生するかもしれない−は、ヒストグラム演算−４番目の段階で発生するかもしれない−よりも、本質的に複雑である）。しかし、システムはまた、リソースの割り振りを基本動作の複雑性とは別に計ることもできる。例えば、所与の画像処理演算は、システムのＣＰＵ又はＧＰＵで行われるかもしれない。ＦＦＴは、計算用の１ＭＢのスクラッチパッドメモリ、又は１０ＭＢで実行されるかもしれない。ある処理は、いくつかの状況では（より高速に応答する）キャッシュデータストレージを使用することを許可されるかもしれないが、他の状況では、（より遅く応答する）システムメモリのみを使用することを許可されるかもしれない。ある段階は、ある場合には４Ｇネットワーク接続へのアクセスが付与されうるが、別の場合にはより遅い３Ｇ又はＷｉＦｉネットワーク接続へアクセスが付与されうる。ある処理は、その有効性を増すために、又は、そのリソース消費を低減するために呼び出されうる、これらの異なるオプションを詳述する情報を発行することができる（例えば、私は、この量のリソースでＸを、これよりさらに多い量でＹを、これより少ない量でＺを行うことができる、など）。部分的な実行シナリオが、明示的に提供されうる。ステートマシンは、様々なリソース割り振り要因に基づいて、これらのオプションの中から選択することができる。最も見込みがある結果を生じるか、又は、最も見込みがある結果の可能性を提供する処理には、システムリソースの消費において特権的ステータスを付与することができる。

さらなる構成では、リソースの割り振りは、エージェントのその目標達成における状態によって決まるだけでなく、そのためのエージェントの速度又は加速度によっても決まる。例えば、最初のリソース努力レベルに応答して、見込みがある結果が速く現れつつある場合、追加のリソースを適用することができるだけでなく、見込みがある結果がそれほど速く現れなかった場合より、より多くの追加のリソースを適用することができる。リソースの割り振りは、このように、検出状態（又は、性能若しくは結果の他のメトリック）のみによって決まる可能性があるのではなく、このような測定の１次−又は高次−導関数によっても決まる可能性がある。

関連して、ある検出エージェント処理のある段階によって作り出されたデータは、大変見込みがあるので、その処理が１つ又は複数の段階より先にジャンプして−間にある段階をスキップすることができることがある。これは、例えば、スキップされた段階（複数可）が処理に必須の結果を出さないが、単に、またさらなる段階による処理の価値があるという、より大きい信頼を得るために着手される場合でありうる。例えば、認識エージェントは、段階１、２及び３を行い、次いで−段階３の出力からの信頼メトリックに基づいて−段階４をスキップし、段階５を実行（又は、段階４及び５をスキップし、段階６を実行するなど）してもよい。ここでもまた、ステートマシンは、ある処理による、その処理のための異なるエントリ段階についての情報の公開に基づいて、そのような意思決定制御を行うことができる。

このような構成は、よく知られている従来技術とは異なることは、当業者には理解されよう。以前は、異なるプラットフォームは、実質的に異なる量のコンピューティング、例えば、メインフレーム、ＰＣ、携帯電話などを提供した。同様に、ソフトウェアは、固定されたリソース需要を有する、モノリシックな機能ブロックとして考えられた。（例えば、特定のＤＬＬは、メモリの可用性に応じて、ロードされてもされなくてもよい。）設計者は、このように、コンピューティング環境を、確立されたサイズのブロックとつなぎ合わせた。いくつかは適合し、他のものは適合しなかった。フォーリン（Ｆｏｒｅｉｇｎ）は、異なるエントリポイント及び異なるコストに関してタスクを記述する現在の概念であったので、システムは、様々な範囲の機能的な能力にどのくらい深く入るべきであるかについての、インテリジェントな決定を行うことができた。以前は、パラダイムは、「あなたができるのであれば、この機能を実行してもよい」であった。（コストは、事後に決定可能であったかもしれない。）現在のモデルは、パラダイムを、むしろ「私はこの機能を３１セント分買うでしょう。状況がどうなるかに基づいて、もしかすると後でもっと買うでしょう」のようにシフトする。現在の構成では、多次元範囲の選択肢が、あるタスクを行うためにこのように提示され、それらの選択肢から、システムは、他のタスク、現在のリソース制約、及び、他の要因に鑑みて、インテリジェントな決定を行うことができる。

ここで記載される構成はまた、リソース消費が時間と共にどのように変化するようになるかを、オペレーティングシステムが見越すこともできるようにする。オペレーティングシステムは、例えば、見込みがある結果が特定の認識エージェントで速く現れつつあり、それがまもなく、そのエージェントへのリソースの割り振りの増加につながるようになることに、注目することができる。オペレーティングシステムは、そのエージェントのタスクの、明らかに差し迫った満足のいく完了が、あるルールの条件−他の認識エージェントをトリガするなど−を満たすようになることを、認識することができる。来たるべきリソース消費の急増に鑑みて、オペレーティングシステムは、先を見越して他のステップを取ることができ、例えば、無線ネットワークを４Ｇから３Ｇへスロットルバックする、有望な結果を生じていない処理をより積極的に縮小する、などである。そのような程度の見通し及び応答性は、典型的な分岐予測手法（例えば、特定の分岐決定の最近の２５５個の結果の機械的な検査に基づく）に関連するものよりも、はるかに豊富である。

リソース割り振り及び段階スキップは、検出状態によって促されうることと全く同様に、ユーザ入力によっても促すことができる。ユーザが特定の処理を奨励する場合、その処理に特別のリソースを割り振ることができ、及び／又は、そうでなければ、見込みがある結果が足りないためにその動作が自動的に縮小されていたかもしれない時点を超えて、その処理が継続してもよい。（例えば、前述の検出状態の連続体が、スコア０＜全く思わしくない＞から１００＜全く有望な＞に及び、そのスコアが３５の閾値を下回る場合に処理が通常は動作を終了する場合、ユーザがその処理を奨励する場合はその閾値を２５又は１５まで下げてもよい。閾値の変化の量を、受けた奨励の量に関係付けることができる。）

ユーザの奨励は、明示又は暗示されうる。明示された奨励の一例は、ユーザが入力信号（例えば、画面のタップなど）を提供し、特定の動作が行われることを命令すること（例えば、システムに対して、描かれた人を識別するために画像を処理するように命令するＵＩコマンド）である。

いくつかの実施形態では、カメラは画像を連続してキャプチャしており−特定のユーザ命令なしに視覚的環境を監視している。そのような場合、ユーザがシャッターボタンなどをアクティベートする場合、そのアクションを、その瞬間にフレーミングされた画像を処理するようにと、明示されたユーザの奨励の証拠として解釈することができる。

暗示された奨励の一例は、ユーザが、画像内に描かれた人をタップすることである。これは、その人についてもっと知るための合図として意図され、又は、ランダムな行為であることがある。とにかく、システムに、画像のその部分に関する処理、例えば、顔認識へのリソース割り振りを増大させれば、十分である。（他の処理もまた優先されてもよく、例えば、その人が身につけたハンドバッグ又は靴を識別すること、及び、顔認識による識別の後にその人についての事実を調査すること−ソーシャルネットワーク、例えば、リンクトイン又はフェイスブックの使用を通じて、グーグル、ｐｉｐｌ＜ｄｏｔ＞ｃｏｍ、又は他のリソースの使用を通じてなど−である。）

タップの場所を、どのくらいの量のリソース増大が異なるタスクに適用されるべきであるか（例えば、奨励の量）を決定する際に、使用することができる。人が画像内の顔をタップする場合、ユーザが画像内の人の靴をタップする場合よりも、より多くの特別のリソースが顔認識処理に適用されてもよい。この後者の場合、靴識別処理に、顔認識処理よりも大きいリソース増大が割り振られてもよい。（靴をタップすることで、靴認識処理が既に進行中ではない場合、開始することもできる。）

暗示されたユーザ奨励のもう１つの例は、ユーザがカメラを位置決めして、特定の被写体が画像フレームの中心点にあるようにすることである。これは、システムがフレームの時系列に留意する場合に特に有望であり、この際、カメラは新しい方向に向けられ−特定の被写体が中心点に移動される。

前述のように、被写体は、いくつかの部分（靴、ハンドバッグ、顔など）からなることがある。そのような各部分とフレームの中心の間の距離は、奨励の量と逆相関すると見なすことができる。すなわち、中心フレームの部分は、暗示的に最も奨励され、他の部分は、距離と共に連続的により少なく奨励される。（数学関数は、距離を奨励に関係付けることができる。例えば、フレームの中心とされる部分は、０〜１００のスケールで、１００の奨励値を有することができる。画像フレームの遠い周辺の任意の部分は、０の奨励値を有することができる。中間の位置は、直線関係、力関係、三角関数、又は他の方法による奨励値に対応してもよい。）

カメラがズームレンズ（又はデジタルズーム機能）を装備しており、カメラが特定の被写体（又は一部）にズームインされるフレームの時系列に留意する場合、そのようなアクションを、その特定の被写体／部分のための暗示されたユーザ奨励として見なすことができる。フレームの時系列なしであっても、ズームの度合いを示すデータを、フレーミングされた被写体へのユーザの関心の測定として見なすことができ、奨励の測定へと数学的に変換することができる。

例えば、カメラが１Ｘから５Ｘのズーム範囲を有する場合、５Ｘのズームは、１００の奨励係数に対応してもよく、１Ｘのズームは、１の奨励係数に対応してもよい。中間ズーム値は、直線関係、力関係、三角関数などによる奨励係数に対応してもよい。

意図の推論はまた、画像フレーム内の特徴の向きに基づいてもよい。ユーザは一般に、所期の被写体を垂直にフレーミングする向きで、イメージングデバイスを押さえると考えられる。加速度計又はジャイロスコープデータを参照することによって、又は他の方法で、デバイスは、ユーザがイメージャを「風景」モード画像をキャプチャするための位置で押さえているか、「ポートレート」モード画像をキャプチャするための位置で押さえているかを見極めることができ、そこから「垂直」を決定することができる。垂直に向けられた主軸（例えば、大体対称の軸）を有する、画像フレーム内のオブジェクトは、垂直から傾いているオブジェクトよりも、ユーザの意図の被写体である可能性がより高い。

（画像フレーム内でユーザの意図の被写体を推論するための他の手がかりは、米国特許第６９４７５７１号で論じられている。）

これまでの考察は、負でない奨励値を企図したが、他の実施形態では、負の値を、例えば、特定の刺激に対する明示又は暗示されたユーザの無関心、フレームの中心から画像特徴が遠く離れていることなどに関連して、利用することができる。

奨励−正及び負の種類の双方−を、他の処理によって提供することができる。バーコード検出器が、フレームの中心のオブジェクトがバーコードであると検知することを開始する場合、その検出状態メトリックは増加する。このような結論は、しかし、フレームの中心の被写体が顔である可能性に、異議を唱える傾向がある。したがって、第１の認識エージェントによる検出状態メトリックの増加は、その第１のエージェントと相互排他的である可能性が高い他の認識エージェントにとって、負の奨励としての機能を果たすことができる。

複数の認識エージェントのための奨励及び検出状態メトリックを、様々な数学的アルゴリズムによって組み合わせて、ハイブリッド制御メトリックを生じることができる。１つは、それらの和であり−２つのエージェント（奨励についての負の値がない）の場合、０〜２００に及ぶ出力を生じる。もう１つは、それらの積であり、０〜１０，０００に及ぶ出力を生じる。それらのそれぞれのハイブリッド制御メトリックが変化するとき、リソースを異なる認識エージェントに再割り振りすることができる。

認識エージェントは、アプリケーションに応じて、異なる粒度及び機能のものでありうる。例えば、直前に論じた顔認識処理は、多数の段階の単一のパイスライスであってもよい。又は、いくつかの、又は数十の、関連のより単純な処理−各々それ自体のスライス−として実装することができる。

図１２のパイスライス認識エージェントが、ＤＬＬ−所望のクラスのサービスを提供するために選択的にロード／呼び出されるコード−に類似していることは、理解されよう。（実際に、いくつかの実装では、ＤＬＬに関連付けられたソフトウェア構成物を、例えば、オペレーティングシステムで使用して、エージェントコードのロード／アンロードを管理すること、そのような機能性の可用性を他のソフトウェアに発行することなどができる。ＤＬＬベースのサービスもまた、認識エージェントと共に使用することができる。）しかし、好ましい認識エージェントは、ＤＬＬとは異なる振る舞いを有する。一態様では、この異なる振る舞いは、スロットリング又は状態ホッピングとして記述されうる。すなわち、それらの実行−及び、リソースのサポート−は、１つ又は複数の要因、例えば、検出状態、奨励などに基づいて変わる。

図１３は、図１２の構成の別の図を示す。この図は、異なる処理が異なる量のプロセッサ時間及び／又は他のリソースを消費する場合があることを明確にする。（実装は、もちろん、単一のプロセッサシステム又はマルチプロセッサシステム上でありうる。今後は、マルチプロセッサシステムの異なるプロセッサ又は「コア」は、別々のタスクを行うように割り当てられてもよい。）

時として、認識エージェントは、処理リソース、入力データ、又はそうでないものかにかかわらず、満足の行くリソースの不足のために、その目標（複数可）を達成することができない。追加又はよりよいリソースがあれば、その目標は達成されるかもしれない。

例えば、顔認識エージェントは、画像がキャプチャされたとき、カメラが４５度傾いたために、画像内に描かれた人の顔を認識することができない場合がある。その角度では、鼻は口の上−顔が存在するかどうかを見極める際に、エージェントが適用した可能性のある基準−にはない。より多くの処理リソースがあれば、その基準が緩められるか、又は除去されるかもしれない。或いは、別のエージェント−例えば、向き調節エージェント−からの、例えば、画像内の実際の水平線の傾きを識別する結果が入手可能であったならば、顔が検出されたかもしれない。水平線の傾きを知ることで、顔認識エージェントが−顔を識別することを可能にしたであろう−異なる角度から、「上」を理解することを可能にしたかもしれない。（同様に、以前に又は後にキャプチャされたフレームが解析された場合、顔が見極められたかもしれない。）

いくつかの構成では、他のリソースが入手可能になるとき、システムは、入力刺激（例えば、画像）のさらなる解析を行う。簡単な例を挙げると、ユーザが電話をハンドバッグに入れ、カメラセンサが暗くなるか、又はどうしようもないほど焦点が合わなくなるとき（又は、ユーザが電話をテーブルの上に置いたので、電話が固定されたシーン−おそらく、テーブル又は天井−を凝視するとき）、ソフトウェアは、それらの目標を以前に達成することができなかったエージェント処理を再アクティベートし、データを再検討してもよい。次々と入ってくる動画を処理する混乱、及び、関連付けられたリソース負荷がなければ、これらのエージェントはこのとき、例えば、以前に逃した顔を認識するという、それらの本来の目標を達成することができる場合がある。これを行う際、システムは、他のエージェント処理からの出力データ−対象エージェントが最初に実行中であったときに入手可能なもの、及び、また、対象エージェントが終了した後まで入手可能ではなかったそれらの結果の双方−を呼び戻してもよい。この他のデータは、以前に不成功であった処理がその目標を達成する助けとなることがある。（電話の以前の動作中に収集された、収集された「ごみ」が、手がかり、及び、エージェントが実行された最初の処理環境で見落とされた−又は、まだ入手可能ではなかった−助けとなる情報を求めて、見直されてもよい。）このような「事後の熟考」動作中のバッテリの消耗を低減するため、電話は省電力状態に切り替わってもよく、例えば、ある処理回路を無効にすること、プロセッサクロック速度を下げることなどを行ってもよい。

関連構成では、電話でそれらの目標を達成することなく終了した処理の一部又は全部が、クラウドで継続されてもよい。電話は、不成功のエージェント処理についての状態データをクラウドへ送信し、電話が終わったところで、クラウドプロセッサが解析（例えば、アルゴリズムステップ及びデータ）を再開できるようにしてもよい。電話はまた、他のエージェント処理からの結果−不成功のエージェント処理が終了されたとき、入手可能でなかったものを含む−をクラウドに提供することもできる。ここでもまた、以前に廃棄された情報がクラウドの処理との新しい関連性を持つようになる場合に備えて、データの「ごみ」を可能性のあるリソースとしてクラウドに提供することもできる。クラウドは、−電話システムが見落とした可能性のある、有用な価値ある情報又は意味を発見しようと試みて−すべてのそのようなデータの収集動作を行うことができる。これらの結果が電話に返されるとき、これらの結果は、さらに、電話が過去又は現在に処理している情報を電話に再査定させ、おそらく、そうでなければ逃していたであろう有用な情報を、電話が見極めることができるようにしてもよい。（例えば、そのデータ収集処理において、クラウドは、水平線が４５度傾いているように見えることを発見し、電話の顔認識エージェントが、そうでなければ逃していたであろう顔を識別できるようにしてもよい。）

前述の考察は、認識エージェントに焦点を合わせたが、同じ技術をまた、例えば、向き又はコンテキスト、その他の確立など、認識の補助的なものなど、他の処理に適用することもできる。
さらに制約について

図１４は、ある実施形態で用いることができる技術のある態様を描く概念図である。図の最上部は、実行されうる認識エージェント（ＲＡ）サービスで満ちたホッパーを示し−大部分は、そのサービスのための入力として使用されるべき１つ又は複数のキーベクトルに関連付けられる。しかし、システム制約により、すべてのこれらのサービスの実行が可能にされるわけではない。したがって、ホッパーの底は、制約によってゲートで制御されるものとしてグラフィカルに図示され−バッテリ状態、ＣＰＵにおける他の需要などに応じて、より多いか又はより少ないサービスが開始できるようになる。

実行可能にされるこれらのサービスは、ホッパーの下に示される。これらのサービスが実行するとき、これらのサービスは、中間又は最終結果をブラックボードに投稿してもよい。（いくつかの実施形態では、これらのサービスは、ＵＩマネージャへ、別の認識エージェントへ、監査証跡又は他のデータストアへなど、他の処理又はデータ構造へ出力を提供して、オペレーティングシステムへ信号−例えば、ステートマシンを前進させるためなど−を出してもよい。）

いくつかのサービスは、完了まで実行して終了し（図では、１本の取り消し線によって図示される）−他のサービスを実行可能にするリソースを解放する。他のサービスは、完了より前にキルされる（二重取り消し線によって図示される）。これは、様々な理由で起こる可能性がある。例えば、サービスからの中間結果が、見込みがないことがある（例えば、ある楕円はこのとき、顔よりも車のタイヤである可能性がより高いように見える）。又は、システム制約は変わることがあり−例えば、リソースの不足のため、あるサービスの終了を必要とする。又は、他のより見込みがあるサービスは、実行する準備ができ、リソース再割り振りを要求することがある。図１４の例示には描かれないが、キルされる処理からの中間結果は、−それらの動作中、又は、それらがキルされる時点で−ブラックボードに投稿されてもよい。（例えば、ある楕円が顔よりも車のタイヤのように見える場合、顔認識アプリケーションは終了してもよいが、車両認識エージェントは、そのような情報を使用することができる。）

ブラックボードに投稿されたデータは、様々な方法で使用される。１つは、ボーブルの画面表示をトリガして、他のユーザインタフェース要件を満たすことである。

ブラックボードからのデータはまた、認識エージェントサービスへの入力として、例えば、入力キーベクトルとして、入手可能にされてもよい。加えて、ブラックボードデータは、新しいサービスが実行するための理由を知らせてもよい。例えば、楕円の検出は、−ブラックボード上にレポートされるとき−顔認識サービスが実行されるべきであることを知らせてもよい。ブラックボードデータはまた、（概念上の）ホッパー内で既に待機中のサービスの関連性スコアを増し−そのサービスが実行されるようになる可能性をより高くしてもよい。（例えば、その楕円が実際に車のタイヤであるという指示は、そのエージェント処理が実行されるに至るほどに、車両認識処理の関連性スコアを増してもよい。）

関連性スコアの概念が、図１５に示される。データ構造は、実行される可能性のあるサービスのリストを維持する（図１４のホッパーに類似）。関連性スコアは、各々について示される。これは、そのサービスを実行する重要性の相対的指示である（例えば、１〜１００のスケールによる）。このスコアは、ブラックボード、コンテキスト、明示されたユーザの意図、ユーザ履歴などで発見されたデータを含む、−特定のサービス及びアプリケーションに応じた−複数の変数の相関的要素でありうる。関連性スコアは典型的には、より多くのデータが入手可能になる、コンテキストが変化するなどにつれて、時間と共に変化する。進行中の処理は、現在の条件に基づいて、関連性スコアを更新することができる。

いくつかのサービスは、高度に関連があるようなスコアになるが、提供されうるよりも多くのシステムリソースを要求し、そのため実行しないことがある。他のサービスは、関連が弱いものでしかないようなスコアになることがあるが、リソース消費が大変控えめなので、それらの低い関連性スコアにかかわらず、実行されうるということがある。（このクラスでは、以前に詳述された、定期的に行われる画像処理演算である場合がある。）

サービスを実行するためのコストを−リソース要件に関して−示すデータが、例示されたデータ構造内で提供される（図１５のコストスコアという見出しの下）。このデータは、関連性−コスト解析が行われることを可能にする。

例示されたコストスコアは、複数の数の配列であり−各々は、特定のリソース要件、例えば、メモリ使用量、ＣＰＵ使用量、ＧＰＵ使用量、帯域幅、他のコスト（金銭的費用に関連付けられたサービスのためなど）などに対応する。ここでもまた、例示的構成では、任意の０〜１００のスコアが示される。３つの数のみが示される（メモリ使用量、ＣＰＵ使用量、及びクラウド帯域幅）が、より多くの又はより少ない数がもちろん使用されうる。

関連性−コスト解析は、システム保証と同じように単純又は複雑になりうる。単純な解析は、組み合わせられたコスト成分を関連性スコアから減算することであり、例えば、データ構造内の第１のエントリでは、−７０の結果を生じる。もう１つの単純な解析は、関連性を、総計のコスト成分で除算することであり、例えば、第１のエントリでは、０．３９６の結果を生じる。

類似の計算を、キュー内のすべてのサービスに対して行い、それによりサービスの順序付けを決定することができる最終スコアを生じることができる。最終スコア列は、図１５で、上記の第１の解析に基づいて提供される。

単純な実施形態では、サービスは、直観的コンピューティングプラットフォームに付与されたリソース予算に達するまで、開始される。プラットフォームには、例えば、３００ＭＢのＲＡＭメモリ、クラウドへの２５６Ｋビット／秒のデータチャネル、５０ミリワットの電力消費量、並びに、ＣＰＵ、ＧＰＵ、及び／又は、他の制約のあるリソースについて同様に定義された予算が付与されうる。（これらの割り振りは、デバイスオペレーティングシステムによって設定されてもよく、他のシステム機能が呼び出されるか、又は終了するとき、変化してもよい。）これらの閾値のいずれかに達するとき、状況が変化するまで、それ以上の認識エージェントサービスは開始されない。

単純ではあるが、この構成は、定義されたリソース予算のうち最初のものに達するとき、すべてのサービスを制限する。一般に好ましいものは、関連のある制約のうちいくつか又は全部を考慮して、呼び出されたサービスを最適化しようとする構成である。したがって、２５６Ｋビット／秒のクラウド帯域幅制約に達する場合、システムは、クラウド帯域幅を必要としないさらなるサービスを、なお開始してもよい。

より高度な構成では、各候補サービスには、そのサービスに関連付けられた異なるコスト成分の各々についての性能指数スコアが割り当てられる。これは、最終スコアの計算のための上述の減算又は除算の手法によって、若しくは他の方法で行うことができる。減算の手法を使用すると、図１５で最初にリストされたサービスのメモリ使用量についての３７のコストスコアは、９のメモリ性能指数（すなわち、４６〜３７）を生じる。ＣＰＵ使用量及びクラウド帯域幅についてのサービスの性能指数は、それぞれ−１８及び３１である。それらの異なるリソース要件に関して候補サービスにスコアを与えることによって、システムリソースをより効率的に利用するサービスの選択を行うことができる。

新しい認識エージェントが起動され、他の認識エージェントが終了し、他のシステム処理が変わるとき、リソースのヘッドルーム（制約）が変化するようになる。これらの動的な制約は追跡され（図１６）、認識エージェントを起動（又は終了）する処理に影響を与える。メモリ集中的なＲＡがその動作を完了し、４０ＭＢのメモリを解放する場合、プラットフォームは、１つ又は複数の他のメモリ集中的なアプリケーションを起動して、最近解放されたリソースを利用してもよい。

（異なるサービスの選択による異なるリソースの消費を最適化するタスクは、線形プログラミングにおける課題であり、そのための多数の周知の手法があることは、当業者には理解されよう。本明細書で詳述された構成は、実際に採用されうるものよりも単純であるが、概念を例示する助けとなる。）

図１５に戻ると、例示されたデータ構造はまた、「条件」データをも含む。あるサービスは、高度に関連があることがあり、リソースは、そのサービスを実行するために十分であることがある。しかし、実行に先立つ条件がまだ満たされないことがある。例えば、必要なデータを提供する別の登録エージェントサービスが、まだ完了していないことがある。又は、ユーザ（又はエージェントソフトウェア）がまだ、サービスによって要求された支出を承認していないか、又は、サービスのクリックラップの法律上の契約に同意していない、などのことがある。

サービスが実行を開始した後、リソース制約が変化して、総計の直観的コンピューティングプラットフォームがその最大予算を超えるようにする場合であっても、そのサービスが完了まで実行できるようにするために、プログラムされたバイアスが存在してもよい。異なるバイアスを異なるサービスに、且つ、所与のサービスのための異なるリソースに関連付けることができる。図１５は、異なる制約、例えば、メモリ、ＣＰＵ及びクラウド帯域幅のためのバイアスを示す。場合によっては、バイアスは１００％未満であってもよく、その場合、そのリソースの可用性がバイアスの数字より低い場合、そのサービスは起動されることはない。

例えば、あるサービスは、総計のＩＣＰ帯域幅がその最大値の１１０％になるまで、実行を継続してもよいのに対して、別のサービスは、１００％の閾値が越えられるとき、直ちに終了してもよい。

あるサービスが特定のリソースの低ユーザである場合、より高いバイアスが許可されてもよい。又は、あるサービスが高い関連性スコアを有する場合、より高いバイアスが許可されてもよい。（バイアスは、バイアス＝９０＋関連性スコア、又は１００、どちらでもより大きい方など、関連性スコアから数学的に導出されてもよい。）

異なるサービス及び異なる制約に割り当てられたバイアスに応じて、リソース需要が指図するとき、このような構成は、プログラマブルな方法でサービスの縮小を可能にする。

いくつかの構成では、スロットルバックされたリソースによってではあるが、サービスが実行可能にされてもよい。例えば、あるサービスは通常、５０Ｋビット／秒の帯域幅要件を有することがある。しかし、特定の状況では、その実行は、４０Ｋビット／秒の使用に制限されてもよい。ここでもまた、これは、最適化における課題であり、その詳細は応用例によって異なるようになる。
ローカルソフトウェア

１つの特定の実施形態では、モバイルデバイス上のローカルソフトウェアを、６つの異なるクラスの機能を行うものとして概念することができる（インストール、及び、オペレーティングシステムへのそれ自体の登録は含まない）。

第１のクラスの機能は、ユーザと通信することに関する。このクラスは、ユーザが入力を提供し、例えば、ユーザが誰であるか、ユーザが何に関心を持っているか、何の認識動作がユーザに関連があるか（木の葉：イエス、車両タイプ：ノー）などを指定することを可能にする。（ユーザは、関心に応じて、異なる認識エンジンを申し込みしてもよい。）ユーザインタフェース機能性もまた、−タッチスクリーン及びキーボード上の入力を検知する、情報を表示画面上に出力するなど−ハードウェアＵＩデバイスのために必要とされたサポートを提供する。

ユーザと有効に通信するため、ソフトウェアは、ユーザの環境のある３Ｄ理解を有することが望ましく、例えば、表現されている３Ｄ領域があるという知識によって情報が与えられて、画面上に提示された２Ｄ情報を編成する方法、及び、カメラが３Ｄ世界を表現することを知りながら、カメラによってキャプチャされた２Ｄ情報を理解する方法である。これには、正射影ブリッティングプリミティブ（ｏｒｔｈｏｇｒａｐｈｉｃ ｂｌｉｔｔｉｎｇ ｐｒｉｍｉｔｉｖｅｓ）のライブラリが含まれうる。これは、第２のクラスに入る。

第２のクラスの機能は、一般的な向き調節、正射影、及び、オブジェクトシーン構文解析に関する。これらの能力は、オブジェクト認識動作に情報を与える助けとなることができる、コンテキストの共通項（例えば、空は上にある、この画像内の水平線は２０度右に傾いている、など）を提供する。

第３のクラスは、実際のピクセル処理に入り、キーベクトル処理及びパッケージングと呼ばれうる。これは、多数の知られているピクセル処理動作−変換、テンプレートマッチング等々−である。ピクセル及びクランチ（ｃｒｕｎｃｈ）を取る。

８×８ブロックのピクセルは、多くの画像処理演算（例えば、ＪＰＥＧ）でよく知られているが、そのグループは、本コンテキストではそれほど優勢ではない（ただし、ある状況で使用されうる）。その代わりに、５つのタイプのピクセルグループが優勢である。

第１のグループは、全くグループではないが、グローバルである。例えば、レンズキャップが付いているか？焦点の一般的な状態は何か？これは、−あるとしても−多くの構文解析のないカテゴリである。

第２のグループは、長方形のエリアである。長方形のピクセルのブロックが、任意の数の動作のために要求されうる。

第３のグループは、長方形でない連続的なエリアである。

第４は、列挙されたピクセルのパッチワークである。まだ単一のフレーム内であるが、これは、第２の及び第３のグループの組み合わせであり−首尾一貫性のある観念（例えば、特定の認識タスクへの関連性など、含まれたピクセル間の関係を示す、あるメトリック又はあるヒューリスティック）を有することが多い。

第５は、ピクセルのフレーム間の集まりである。これらは、ピクセルデータの時系列を含む（フレームでないことが多い）。他のグループのように、特定の形式は、応用例に応じて大幅に変わるようになる。

このピクセル処理クラスの機能の別の態様は、リソースが有限であり、例えば、顔を認識するなど、それらの目標の達成に向かって進行しつつあるように見える処理に、ますます増える量で割り振られるべきであり、逆の場合も同じであることを認める。

ローカルソフトウェアによって行われるべき第４のクラスの機能は、コンテキストメタデータ処理である。これは、例えば、ユーザによって入力された、センサによって供給された、又は、メモリから呼び戻された、多くの種類の情報を集めることを含む。

「コンテキスト」の１つの形式上の定義は、「エンティティ（ユーザ及びアプリケーション自体を含む、ユーザとアプリケーションの間のインタラクションに関連があると考えられる人、場所又はオブジェクトの状況を特徴付けるために使用することができる、任意の情報」である。

コンテキスト情報には多くの種類がある可能性があり、計算コンテキスト（ネットワーク接続性、メモリ可用性、ＣＰＵ競合など）、ユーザコンテキスト（ユーザプロファイル、場所、アクション、プリファレンス、近所の友達、ソーシャルネットワーク（複数可）、及び、状況など）、物理的コンテキスト（例えば、照明、雑音レベル、トラフィックなど）、時間的コンテキスト（時刻、日、月、季節など）、上記の履歴などが含まれる。

ローカルソフトウェアのための第５のクラスの機能は、クラウドセッション管理である。ソフトウェアは、異なるクラウドベースサービスプロバイダを、個々のタスクを実行するためのリソースとして登録すること、クラウドとの二重セッションをインスタンス化する（ＩＰ接続を確立し、トラフィックの流れを管理する）こと、リモートサービスプロバイダをピングする（例えば、それらのサービスが間もなく必要とされうるというアラートを出す）ことなどを行う必要がある。

ローカルソフトウェアのための第６の最後のクラスの機能は、認識エージェント管理である。これらの機能には、認識エージェント及びサービスプロバイダが、それらの入力要件と、ランタイムでロード（又はアンロード）されなければならない、それらが依拠する共通ライブラリ機能と、他のシステムコンポーネント／処理とのそれらのデータ及び他の依存性と、共通項の処理を行うためのそれらの能力（場合によっては、他のサービスプロバイダに取って代わる）と、それらのシステムリソースの最大使用についての情報と、それらの動作の各段階（図１２の考察を参照）及び各々によって課せられたリソース要求についての詳細と、スロットルダウンされたリソースによるそれらの性能／振る舞いについてのデータなどとを、−携帯電話へ−発行するための構成が含まれる。この第６のクラスの機能は次いで、これらのパラメータが与えられると、現在の状況に基づいて、認識エージェントを管理し、例えば、結果及び現在のシステムパラメータに応じて、それぞれのサービスの強度をスロットルアップ又はスロットルダウンする。すなわち、認識エージェント管理ソフトウェアは、エージェントの動作がシステムリソース制約に従って仲介される手段としての機能を果たす。
サンプルの視覚的アプリケーション

１つの例示的アプリケーションは、表面上の複数の硬貨を見て、それらの合計額を計算する役目を果たす。システムは、楕円発見処理（例えば、ハフアルゴリズム）を適用して、硬貨を位置指定する。これらの硬貨は、互いに上に重なり合うことがあり、いくつかは部分的にしか見えないことがあり、アルゴリズムは、検出する楕円の各部分の中心−各々が異なる硬貨に対応する−を決定することができる。これらの楕円の軸は、ほぼ平行であるはずであり（斜めのビュー、すなわち、すべての硬貨が画像内で円として描かれるとは限らないと仮定する）−このことは、この手順をチェックするものとしての機能を果たすことができる。

楕円が位置指定された後、硬貨の直径が査定されて、それぞれの額が識別される。（査定された直径をヒストグラム化して、予期される直径で、又は、予期される直径比率で、クラスタ化するようにすることができる。）

様々ないくつかの硬貨が存在する場合、これらの硬貨が、直径の比率のみによって−色又はしるしを参照することなく−識別されてもよい。１０セント硬貨の直径は１７．９１ｍｍであり、１ペニー硬貨の直径は１９．０５ｍｍであり、５セント硬貨の直径は２１．２１ｍｍであり、２５セント硬貨の直径は２４．２６ｍｍである。１０セント硬貨に対して、１ペニー硬貨、５セント硬貨及び２５セント硬貨は、１．０６、１．１８及び１．３５の直径比率を有する。１ペニー硬貨に対して、５セント硬貨及び２５セント硬貨は、１．１１及び１．２７の直径比率を有する。５セント硬貨に対して、２５セント硬貨は、１．１４の直径比率を有する。

これらの比率はすべて一意であり、即座の見極めを可能にするために十分広い間隔が空いている。２つの硬貨が１．１４の直径比率を有する場合、小さい方は５セント硬貨に違いなく、他方は２５セント硬貨に違いない。２つの硬貨が１．０６の直径比率を有する場合、小さい方は１０セント硬貨に違いなく、他方は１ペニー硬貨に違いない、などとなる。他の比率が発見される場合、何かが誤っている。（硬貨が楕円として描かれる場合であっても、直径の比率を決定することができ、その理由は、同じ視点から見られた楕円の寸法が同様に比例するためであることに留意されたい。）

硬貨のすべてが同じタイプである場合、見えているしるしによって識別されてもよい。

いくつかの実施形態では、色もまた使用することができる（例えば、１ペニー硬貨を１０セント硬貨と区別する際に支援するため）。

識別された２５セント硬貨の額を、識別された１０セント硬貨の額と、識別された５セント硬貨の額と、識別された１ペニー硬貨の額と合計することによって、この表面上の硬貨の合計額が決定される。この額をユーザに、適切なユーザインタフェース構成を通じて提示又は公表することができる。

関連するアプリケーションは、山積みの硬貨を見て、それらの硬貨の発行国を決定する。各国の異なる硬貨は、硬貨間の寸法の比率の一意のセットを有する。したがって、−上記のような−直径比率の決定は、ある硬貨の集まりが米国のものか、カナダのものか、などを示すことができる。（１ペニー硬貨、５セント硬貨、１０セント硬貨、２５セント硬貨、及び、カナダの５０セント硬貨は、例えば、１９．０５ｍｍ、２１．２ｍｍ、１８．０３ｍｍ、２３．８８ｍｍ及び２７．１３ｍｍの直径を有するので、その山が５セント硬貨及び１ペニー硬貨のみを含む場合、ある曖昧さがあるが、他の硬貨が含まれる場合、これは解決される）。
拡張環境

多数の画像処理アプリケーションでは、視覚的コンテキストが明確に定義される。例えば、合板工場におけるプロセス制御カメラは、既知の照明下でコンベヤーベルト上のベニヤ板を見ていることがあり、又は、ＡＴＭカメラは、１８インチ離れて、現金を引き出す人々のセキュリティ画像をとらえていることがある。

携帯電話環境は、より困難であり−カメラが何を見ているかについて、ほとんど又は何も知られないことがある。そのような場合、既知の見える特徴−システムに視覚的な足掛かりを与えるための何かを、環境に導入することが望ましいことがある。

１つの特定の構成では、シーンのマシンビジョン理解は、視野内で１つ又は複数の特徴又はオブジェクトを位置決めすることによって支援され、それについての参照情報が知られ（例えば、サイズ、位置、角度、色）、それによってシステムは、−関係により−他の特徴を理解することができる。１つの特定の構成では、ターゲットパターンがシーンに含まれ、そこから、例えば、視空間内の表面までの距離及びその向きを見極めることができる。そのようなターゲットはしたがって、距離及び向き情報をカメラシステムへ信号で送る、ビーコンとしての機能を果たす。１つのそのようなターゲットは、トリップコード（ＴＲＩＰｃｏｄｅ）であり、例えば、ｄｅ Ｉｐｉｎａ、ＴＲＩＰ：ａ Ｌｏｗ−Ｃｏｓｔ Ｖｉｓｉｏｎ−Ｂａｓｅｄ Ｌｏｃａｔｉｏｎ Ｓｙｓｔｅｍ ｆｏｒ Ｕｂｉｑｕｉｔｏｕｓ Ｃｏｍｐｕｔｉｎｇ、Ｐｅｒｓｏｎａｌ ａｎｄ Ｕｂｉｑｕｉｔｏｕｓ Ｃｏｍｐｕｔｉｎｇ、Ｖｏｌ．６、Ｎｏ．３、２００２年５月、２０６〜２１９ページに詳述されている。

Ｉｐｉｎａ論文で詳述されるように、ターゲット（図１７に示す）は、ターゲットの半径を含む情報を符号化し、カメラ付きシステムがカメラからターゲットまでの距離、及び、ターゲットの３Ｄ姿勢を共に決定することを可能にする。ターゲットが視空間内のある表面上（例えば、壁面）に位置する場合、Ｉｐｉｎａの構成は、カメラ付きシステムが、壁までの距離、及び、カメラに対する壁の空間的な向きを共に理解することを可能にする。

トリップコードは、スポットコード（ＳｐｏｔＣｏｄｅ）、次いで、ショットコード（ＳｈｏｔＣｏｄｅ）（及び、時として、バンゴ〔Ｂａｎｇｏ〕）として継続的に知られながら、様々な実装を経てきた。現在は、ＯＰ３ Ｂ．Ｖ．によって商品化されていると考えられる。

トリップコードターゲットの美的感覚は、いくつかの応用例には適していないが、他の応用例にはよく適している。例えば、カーペット又はじゅうたんが、例えば、カーペットの幅にわたって規則的又は不規則的な位置に位置する、繰り返されるデザイン特徴として、トリップコードターゲットを組み込んで作られてもよい。そのようなカーペットの上に立っている人を含むシーンを見るカメラは、その人までの距離を決定する際に（且つ、床を包含する平面を定義するためにも）ターゲットを参照することができる。同様に、このターゲットを、壁紙、家具用の布製カバー、衣類、その他など、他の材料の設計に組み込むことができる。

他の構成では、トリップコードターゲットは、人間の視覚系には見えないインクで印刷することによって、それほどはっきり見えないようにされるが、例えば、赤外線スペクトルでは可視である。モバイル電話で使用される多くの画像センサは、赤外線スペクトルへの感度がよい。そのようなターゲットは、したがって、人間の注意から逃れるとしても、キャプチャされた画像データから見極めることができる。

また、さらなる構成では、トリップコードの存在を、他のシーン特徴の中でカモフラージュし、それにもかかわらず、モバイル電話によるその検出を可能にするようにすることができる。

１つのカモフラージュ方法は、カメラセンサによる画像シーンの周期的サンプリングに依拠する。そのようなサンプリングは、ある品目が人間によって直接点検されるときにははっきりと見えない視覚的アーチファクト（例えば、エイリアシング、モアレ効果）を、カメラによりキャプチャされた画像に導入することができる。画像センサの規則的間隔のフォトセンサセルによって撮像されるとき、このようなアーチファクトの影響を通して現れるように、トリップコードターゲットを導入するように設計されたパターンで、オブジェクトを印刷することができるが、そうでなければ、このオブジェクトは見る人にとってはっきりと見えない。（この同じ原理は、コピーに基づく偽造に強い小切手の作成で、有利に使用される。「ボイド（ＶＯＩＤ）」という語など、潜像が、オリジナルの文書設計のグラフィカル要素に組み込まれる。この潜像は、見る者にとってはっきりと見えない。しかし、コピー機のイメージングシステムによってサンプリングされるとき、周期的サンプリングは「ボイド（ＶＯＩＤ）」という語を浮かび上がらせ、コピーに現れるようにする。）様々なそのような技術は、ｖａｎ Ｒｅｎｅｓｓｅ、Ｈｉｄｄｅｎ ａｎｄ Ｓｃｒａｍｂｌｅｄ Ｉｍａｇｅｓ−ａ Ｒｅｖｉｅｗ、Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｏｐｔｉｃａｌ Ｓｅｃｕｒｉｔｙ ａｎｄ Ｃｏｕｎｔｅｒｆｅｉｔ Ｄｅｔｅｒｒｅｎｃｅ Ｔｅｃｈｎｉｑｕｅｓ ＩＶ、ＳＰＩＥ Ｖｏｌ．４６７７、３３３〜３４８ページ、２００２年に詳述されている。

もう１つのカモフラージュ方法は、カラー印刷が一般に４つのインク、すなわち、シアン、マゼンタ、黄色及び黒（ＣＭＹＫ）で行われるという事実に依拠する。通常、黒の素材は、黒インクで印刷される。しかし、黒はまた、シアン及びマゼンタ及び黄色を刷り重ねることによって模造することもできる。人間にとって、これらの２つの技術は、基本的に区別できない。デジカメでは、しかし、これらの２つの技術を容易に見極めることができる。この理由は、黒インクが典型的には、比較的多い量の赤外光を吸収するのに対して、シアン、マゼンタ及び黄色チャネルは、そうしないからである。

黒に見えるべきである領域では、印刷処理は、（例えば、白い下地の上に）重複するシアン、マゼンタ及び黄色インクのエリアを適用することができる。このエリアを次いで、黒インクを使用して、トリップコードでさらに刷り重ね（又は事前印刷）することができる。見る者にとっては、このエリアはすべて黒く見える。しかし、カメラには、赤外線の振る舞いからその違いが分かる。すなわち、黒インクの付いたトリップコードの領域内のある点で、白い下地を暗くする黒インクがあり、この黒インクは、そうでなければ白い下地から反射されるかもしれない、いかなる入射する赤外線照明をも吸収する。例えば、トリップコードターゲットの外側、又は、その周辺内−であるが、白が正常に現れるところ−の別の点で、赤外線照明は、シアン、マゼンタ及び黄色インクを通過し、白い下地からセンサに戻るように反射される。

カメラの赤センサは、赤外線照明に最も応答するので、トリップコードターゲットが区別されるのは、赤チャネル内である。カメラは、赤外線照明を（例えば、１つ又は複数のＩＲ ＬＥＤによって）提供してもよく、又は、周囲照明が十分なＩＲ照明を提供してもよい。（将来のモバイルデバイスでは、第２の画像センサが、例えば、赤外線検出のために特に構成されたセンサにより、設けられてもよい。）

直前に記載された構成を、−黒領域のみでなく−あらゆるカラー印刷画像で使用するために構成することができる。そうするための詳細は、米国特許出願公開第２００６／０００８１１２号において提供されている。そのような構成によって、トリップコードターゲットを、印刷が視覚的シーンに現れうるどんなところでも隠し、そのようなターゲットを参照することによって、シーン内のある特徴及びオブジェクトの正確な測定を可能にすることができる。

トリップコードなど、丸いターゲットは、計算を容易にするために望ましいが、例えば、異なる楕円形の姿勢になっているそのような形状の認識では、他の形状のマーカーを使用することができる。表面の３Ｄ位置を決定するために適した正方形のマーカーは、ソニー（Ｓｏｎｙ）のサイバーコード（ＣｙｂｅｒＣｏｄｅ）であり、例えば、Ｒｅｋｉｍｏｔｏ、ＣｙｂｅｒＣｏｄｅ：Ｄｅｓｉｇｎｉｎｇ Ａｕｇｍｅｎｔｅｄ Ｒｅａｌｉｔｙ Ｅｎｖｉｒｏｎｍｅｎｔｓ ｗｉｔｈ Ｖｉｓｕａｌ Ｔａｇｓ、Ｐｒｏｃ．ｏｆ Ｄｅｓｉｇｎｉｎｇ Ａｕｇｍｅｎｔｅｄ Ｒｅａｌｉｔｙ Ｅｎｖｉｒｏｎｍｅｎｔｓ ２０００年、１〜１０ページに詳述されている。様々な他の参照マーカーが、−個々の応用例の要件に応じて−別法として使用される。特定の出願において有利であるものは、米国特許出願公開２０１０／００９２０７９に詳述されている。

いくつかの構成では、デジタルウォーターマークデータを搬送するように、トリップコード（又はサイバーコード）をさらに処理することができる。これは、上述され、上記特許出願に詳述されている、ＣＭＹＫ構成によって行うことができる。そのようなマシン可読データキャリアにステガノグラフィックデジタルウォーターマークデータによりマークを付けるための他の構成、及び、そのような構成のための応用例は、米国特許第７１５２７８６号及び米国特許出願公開第２００１／００３７４５５号に詳述されている。

同様の効果を有して用いられうるもう１つの技術は、ＭＩＴのメディアラボで開発されたような、Ｂｏｋｏｄｅｓである。Ｂｏｋｏｄｅｓは、カメラレンズのボケ効果を活用し−焦点が外れたシーン点から出る光線を、カメラセンサ上のディスクのようなぼやけにマップする。在庫があり、すぐ買えるカメラは、１０フィート以上の距離から、２．５ミクロンほどの小さいＢｏｋｏｄｅ特徴をキャプチャすることができる。バイナリ符号化を用いて、カメラに対する相対距離及び角度を評価することができる。この技術は、Ｍｏｈａｎ、Ｂｏｋｏｄｅ：Ｉｍｐｅｒｃｅｐｔｉｂｌｅ Ｖｉｓｕａｌ Ｔａｇｓ ｆｏｒ Ｃａｍｅｒａ Ｂａｓｅｄ Ｉｎｔｅｒａｃｔｉｏｎ ｆｒｏｍ ａ Ｄｉｓｔａｎｃｅ、Ｐｒｏｃ．ｏｆ ＳＩＧＧＲＡＰＨ’０９、２８（３）：１−８にさらに詳述されている。
マルチタッチ入力、画像再マッピング、及び他の画像処理

他のところで上述したように、ユーザは、プロトボーブルをタップして、システムが処理中である特徴又は情報への関心を表してもよい。このユーザの入力は、例えば、システムが追加のリソースをその取組みに適用するべきであると指示することによって、その処理の優先度を上げる。そのようなタップは、プロトボーブルをボーブルへとより速く成熟させることにつながる可能性がある。

ボーブルをタップすることはまた、他の目的を果たすこともできる。例えば、ボーブルは、アップルのアイフォン（すなわち、そのマルチタッチＵＩ）によって普及したものと類似の方法で、ユーザインタフェースの目的のためのタッチのターゲットであってもよい。

以前の画像マルチタッチインタフェースは、画像を、区別されていない全体として扱った。ズームなどが、画像内に描かれた特徴とは関係なく実施された。

本技術のさらなる態様によれば、マルチタッチ及び他のタッチスクリーンユーザインタフェースは、表示された画像の１つ又は複数の部分が何を表すかについてのある知識によって部分的に決まる動作を行う。

簡単な例を挙げるため、机の表面中に散乱したいくつかの品目の斜めの角度のビューを考えられたい。１つは、−画像フレーム内で楕円として描かれた−硬貨である場合がある。

モバイルデバイスは、以前に詳述されたような様々なオブジェクト認識ステップを適用し、潜在的に異なるオブジェクトに対応する画像のエッジ及び領域を識別することが含まれる。ボーブルが現れうる。画像内の硬貨（又は、硬貨に関連付けられたボーブル）の場所をタップして、ユーザは、−机の上を見下ろす平面ビュー内であるかのように−硬貨が円として提示されるように、画像が再マッピングされるべきであることを、デバイスに知らせることができる。（これは、時として、オルソ補正〔ｏｒｔｈｏ−ｒｅｃｔｉｆｉｃａｔｉｏｎ〕と呼ばれる。）

これを行うため、システムは、その形状が円であることを最初に知ることが望ましい。そのような知識は、いくつかの代替ソースに由来することが可能である。例えば、ユーザは、この情報を（例えば、ＵＩを通じて−硬貨をタップし、次いで、画像の縁に提示された円コントロールをタップして、タップされたオブジェクトの本当の形状が円形であると示すことによるなど）明示的に示してもよい。又は、そのような硬貨が、デバイスによって、−例えば、その色及びしるしを参照することによって−ローカルに認識されてもよい（又は、クラウド処理がそのような認識を提供してもよい）。又は、デバイスは、楕円の形状を有するあらゆるセグメント化された画像特徴が実際には斜めの視点から見た円であると仮定してもよい。（いくつかのオブジェクトは、−斜めでさえ−検知可能なマシン可読符号化を含み、オブジェクトの本来の形状を示してもよい。例えば、ＱＲバーコードデータが長方形のオブジェクトから見極められ、オブジェクトの真の形状が正方形であることを示してもよい。）その他もある。

画像内の硬貨の描写（又は対応するボーブル）をタップすることで、−それ以上のことがなくても−画像を再マッピングさせてもよい。他の実施形態では、しかし、そのような命令は、ユーザからの１つ又は複数のさらなる指図を必要とする。例えば、ユーザのタップは、デバイスに、行うことができるいくつかの代替動作を詳述するメニュー（例えば、グラフィカル又は聴覚による）を提示させてもよい。１つは、平面再マッピングでありうる。

そのような命令に応答して、システムは、キャプチャされた画像のスケールを楕円の短軸の寸法に沿って拡大し、その短軸の長さが楕円の主軸の長さに等しくなるようにする。（別法として、類似の効果を有して、画像を主軸に沿って縮小することができる。）そうする際に、システムは、描かれたオブジェクトをその平面ビュー形状により近くなるように再マッピングしており、画像の残りもまた再マッピングされる。

別の構成では、スケーリング係数をただ１つの方向に適用するのではなく、画像が２つの異なる方向に沿ってスケールされてもよい。いくつかの実施形態では、シアリング、又は、差分スケーリング（ｄｉｆｆｅｒｅｎｔｉａｌ ｓｃａｌｉｎｇ）（例えば、遠近法的効果に取り組むため）を使用することができる。

メモリは、それにより斜めのビューからのオブジェクトの平面形状についての推論を決定することができる、ルールのセットを格納することができる。例えば、あるオブジェクトがほぼまっすぐの４面を有する場合、そのオブジェクトは−反対の面がカメラのビュー内で平行でない場合であっても−長方形であると仮定されてもよい。そのオブジェクトが、はっきりと見える第３次元の範囲を有しておらず、明るい色で広く一様である−おそらく、明るい色に囲まれたいくつかの高周波の暗いマーキングがある−場合、そのオブジェクトは１枚の紙であると仮定されてもよく−多分、ＧＰＳが米国内の場所を示す場合、８．５：１１（又は、ＧＰＳが欧州内の場所を示す場合、１：ＳＱＲＴ（２））のアスペクト比である。再マッピングは、−他の知識が不足する際に−そのような情報を用いて、描かれたオブジェクトの、平面ビューに近似するものへのビュー変換を行うことができる。

いくつかの構成では、画像フレーム内のあるセグメント化されたオブジェクトについての知識を使用して、同じフレーム内の別のオブジェクトについての結論を知らせるか、又は精緻化することができる。最大寸法が３０ピクセルである丸いオブジェクト、及び、最大寸法が１５０ピクセルである別のオブジェクトを描く、画像フレームを考えられたい。後者のオブジェクトは、−ある処理によって−コーヒーカップであると識別されてもよい。参照情報のデータストアは、コーヒーカップの最も長い寸法が典型的には３〜６インチであることを示す。次いで、前者のオブジェクトを、約１インチの寸法を有する（例えば、他の画像内に描かれた丸いオブジェクトの場合にありうるような、１フィート又は１メートルではない）と推定することができる。

単なるサイズ分類以上のものを、このように推論することができる。例えば、データストアには、関連付けられた品目を共にグループ化する情報が含まれうる。タイヤ及び車。空及び木。キーボード及びマウス。シェービングクリーム及びかみそり。塩及びコショウ入れ（時として、ケチャップ及びマスタードのディスペンサーと共に）。硬貨及び鍵及び携帯電話及び財布。その他。

そのような関連付けを、様々なソースから収集することができる。１つは、フリッカー又はグーグルイメージ（Ｇｏｏｇｌｅ Ｉｍａｇｅｓ）など、画像アーカイブからのテキストメタデータである（例えば、記述メタデータにおいてかみそりを有するすべての画像を識別し、そのような画像のメタデータからすべての他の用語を収集し、発生に関してランク付けし、例えば、上位２５％を保持する）。もう１つは、自然言語処理によるものであり、例えば、米国特許第７３８３１６９号で詳述されるように、逆のセマンティック関係を見極めることによって拡張された、１つ又は複数のテキスト（例えば、辞書及び百科事典）の前方連結（ｆｏｒｗａｒｄ−ｌｉｎｋｉｎｇ）解析を実施することによる。

寸法の知識を、類似の方法で推定することができる。例えば、参照データの種の集まりを、データストアに入力することができる（例えば、キーボードの最長寸法は約１２〜２０インチであり、電話は約８〜１２インチであり、車は約２００インチである、など）。画像を次いで、既知の品目を含むフリッカーから、他のものと共に収集することができる。例えば、フリッカーは現在、「キーボード」という用語のタグが付いたほぼ２００，０００もの画像を有する。それらの画像のうち、３００を超える画像にはまた、「コーヒーカップ」という用語のタグも付いている。これらの３００以上の画像における、類似のキーボードでない形状の解析により、追加されたオブジェクトが、キーボードの最長寸法のおよそ３分の１である最長寸法を有することが明らかになる。（類似の解析によって、機械学習処理は、コーヒーカップの形状が一般に円筒形であると推定することができ、そのような情報を、デバイスによって調べられる−ローカル又はリモートの−知識ベースに追加することもできる。）

上述のもののような推論は典型的には、最終的なオブジェクト識別を行わない。しかし、これらの推論は、ある識別を他の識別より可能性が高い（又は、より可能性が低い）ものにし、したがって、例えば、確率的な分類子において有用である。

時として、画像の再マッピングは、画像自体を超えるものに基づくことができる。例えば、画像は、例えばビデオからの、画像のシーケンスのうち１つであってもよい。他の画像は、他の視点からのものであってもよく、そのシーンの３Ｄモデルを作成可能にしてもよい。同様に、デバイスがステレオイメージャを有する場合、３Ｄモデルを形成することができる。再マッピングは、このような３Ｄモデルを参照することによって進行することができる。

同様に、ジオロケーションデータを参照することによって、同じ概略位置からの他の画像が識別され（例えば、フリッカーなどから）、３Ｄモデルを作成するために、又は、そうでなければ再マッピング動作に情報を与えるために使用されてもよい。（同様に、フォトシンス〔Ｐｈｏｔｏｓｙｎｔｈｓ〕が人気及び可用性を獲得し続ける場合、フォトシンスは、そこから再マッピングが進行することができる豊富なデータを提供する。）

そのような再マッピングは、ＯＣＲなど、認識アルゴリズムが適用される前に、キャプチャされた画像に適用することができる、助けとなるステップである。例えば、以前の例の机の写真がまた、机から上に傾いた電話をも描いており、ＬＣＤ画面が電話番号を表示していることを考えられたい。電話の傾き及び見る角度のため、この表示は長方形として見えないが、偏菱形として見える。四辺形の形状を認識すると、デバイスは、この四辺形の形状を長方形に再マッピングしてもよい（例えば、横ずれ変換〔ｓｈｅａｒ ｔｒａｎｓｆｏｒｍａｔｉｏｎ〕を適用することによる）。ＯＣＲは次いで、再マッピングされた画像において進行し−電話画面上に表示された文字を認識することができる。

マルチタッチユーザインタフェースに戻ると、デバイス画面上に表示された２つ以上の特徴をタッチすることによって、追加の動作を開始することができる。

いくつかの動作は、他の再マッピング動作を行う。以前の机の例が、机の表面から上に傾いた電話／ＬＣＤディスプレイの双方、及び、水平に置かれている名刺をも描いていることを考えられたい。机に対する電話ディスプレイの傾きのため、これらの２つのテキストを有する特徴は、異なる平面にある。単一の画像から双方をＯＣＲするには、中間物が必要となる。

ユーザが双方のセグメント化された特徴（又は、双方に対応するボーブル）をタッチする場合、デバイスは、選択された特徴のジオメトリを査定する。デバイスは次いで、電話について、ＬＣＤディスプレイのはっきりと見える平面に垂直に伸びるベクトルの方向を計算し、名刺の表面から垂直に伸びるベクトルについて同様に計算する。これらの２つのベクトルを次いで平均して、中間ベクトル方向を生じることができる。画像フレームを次いで再マッピングし、計算された中間ベクトルが垂直に上方へ伸びるようにすることができる。この場合、画像が変換されて、ＬＣＤディスプレイの平面と名刺の平面の間の中間の角度になる平面上に、平面ビューが生じている。このような再マッピングされた画像提示は、異なる平面に置かれている２つの対象からテキストをＯＣＲするための最適な中間物であると考えられる（各々におけるテキストが、再マッピングされた画像描写において類似のサイズであると仮定する）。

類似の画像変換は、マルチタッチインタフェースを使用して画像から選択された３つ以上の特徴に基づくことができる。

説明の看板が至るところにある史跡にいるユーザを検討されたい。これらの看板は、異なる平面にある。ユーザのデバイスは、３つの看板を描く画像のフレームをキャプチャし、これらの看板を、それらのエッジ及び／又は他の特徴から、潜在的な関心のある個別のオブジェクトとして識別する。ユーザは、ディスプレイ上ですべての３つの看板に（又は、対応するボーブルに、共に又は順次に）タッチする。直前に記載されたもののような手順を使用して、３つの看板の平面が決定され、それに対して画像が再マッピングされる、中間物を見る視点−平均看板面に垂直な方向からそのシーンを見る−が次いで作成される。

中間物を見る視点から３つの看板を提示する代わりに、代替手法は、各看板を別々に再マッピングして、平面ビューに現れるようにすることである。これは、単一の画像を３つの異なる画像に−それぞれ異なる再マッピングにより−変換することによって、行うことができる。又は、異なる看板を構成するピクセルを、同じ画像フレーム内で異なって再マッピングすることができる（再形成され、多分拡大された看板の描写を合わせるように、すぐ近くの画像を曲げる）。

さらにもう１つの構成では、３つの看板に（同時に、又は順次に）タッチすることで、指定されたオブジェクトの他の画像を、フリッカー又はフォトシンスなど、画像アーカイブから取得することを伴う動作を開始する。（ユーザは、デバイス上のＵＩとインタラクトして、例えば「フリッカーからの他のピクセルデータで拡張する」など、ユーザの意図を明らかにしてもよい。）これらの他の画像は、キャプチャされた画像との姿勢の類似性（例えば、緯度／経度に加えて、向き）によって、又は他の方法（例えば、他のメタデータ対応、パターンマッチングなど）で識別されてもよい。より高い解像度の、又は、よりしっかりとした焦点の看板の画像が、これらの他のソースから処理されてもよい。これらの看板の抜粋を、適宜スケール及びレベルシフトし、次いで、ユーザによってキャプチャされた画像フレームにブレンド及びペーストし−おそらく、上記で詳述されたように処理することができる（例えば、中間物画像面に再マッピングする、別々に再マッピングする−おそらく、３つの異なる画像に、又は、再形成された看板の抜粋を合わせるように曲げられた合成写真に−など）。

直前に詳述された構成では、キャプチャされた画像内で見える影の解析により、デバイスが、シーンについてのある３Ｄ知識（例えば、オブジェクトの深度及び姿勢）を単一のフレームから得ることが可能となる。この知識は、上記で詳述された動作のいずれかに情報を与える助けとなりうる。

画像（又は抜粋）の再マッピングがＯＣＲを支援可能であることと全く同じように、画像（又は抜粋）の再マッピングはまた、何の他の認識エージェント（複数可）が起動されるべきであるかの決定を支援することもできる。

画像内で２つの特徴（又はボーブル）をタップすることで、描かれたオブジェクト間の空間的関係を決定するための処理を開始することができる。ＮＡＳＣＡＲレースのカメラビューでは、ボーブルは、異なるレースカーをオーバーレイし、それらの動きを追跡してもよい。隣り合っている車のためのボーブルをタップする（又は、描かれた車自体をタップする）ことによって、デバイスは、これらの車の各々の場所データを取得してもよい。これは、例えば、（カメラ光学系の詳細、及び、これらの車の本当のサイズを知り）これらの車の場所を、画像フレーム内のそれらのスケール及び位置から推定することによって、ビューアの視点から相対的に決定することができる。又は、デバイスは、車のリアルタイムのジオロケーションを追跡する１つ又は複数のウェブリソースにリンクすることができ、例えば、そこから、ユーザデバイスは、車間の間隔が８インチであり接近しつつあることをレポートすることができる。

（以前の例のように、この特定の動作は、ユーザが画面をタップするとき、いくつかの可能な動作のメニューから選択されてもよい。）

ボーブルを単にタップする代わりに、さらなる新機軸は、１つ又は複数のボーブルを画面上でドラッグすることに関する。これらのボーブルを互いの上に、又は、画面のある領域上にドラッグすることができ、それにより、ユーザは、所望のアクション又はクエリを知らせる。

いくつかの顔を有する画像において、ユーザは、対応するボーブルのうち２つを第３のボーブルの上にドラッグしてもよい。これは、例えば、示された人々がある社会的関係を有するという、グループ化動作を示してもよい。（この関係についてのさらなる詳細が、ユーザがテキスト入力を使用することによって、又は、発話されたテキストによって−音声認識を通じて−入力されてもよい。）ネットワークグラフの意味では、２人の個人を表すデータオブジェクト間で、リンクが確立される。この関係は、他のデバイス処理動作が、示された個人をどのように扱うかに対して、影響を与えることができる。

別法として、すべての３つのボーブルが、画像フレーム内の新しい場所にドラッグされてもよい。この新しい場所は、グループに関連付けられるべき−推論的に（例えば、コンテキスト）−、又は、ユーザ入力によって明示されるべき、動作又は属性を示すことができる。

特徴−プロキシボーブル（ｆｅａｔｕｒｅ−ｐｒｏｘｙ ｂａｕｂｌｅｓ）のもう１つのインタラクティブな使用は、画像の編集におけるものである。３つの顔、すなわち、２人の友達及び１人の他人を有する画像を考えられたい。ユーザは、この画像をオンラインリポジトリ（フェイスブック）に投稿することを望む場合があるが、最初に他人を除去することを望む場合がある。ボーブルを、この目的のために操作することができる。

アドビ（Ａｄｏｂｅ）フォトショップ（Ｐｈｏｔｏｓｈｏｐ）ＣＳ４は、スマートスケーリング（Ｓｍａｒｔ Ｓｃａｌｉｎｇ）と呼ばれる機能を導入しており、この機能は、ｒｓｉｚｒ＜ｄｏｔ＞ｃｏｍなど、オンラインサイトから既に知られたものである。保存されるべきである画像のエリアが示され（例えば、マウスで描かれた境界ボックスによる）、他のエリア（例えば、余分な特徴を有する）が次いで縮小又は削除される。画像処理アルゴリズムは、保存されたエリアを不変のまま保ち、余分な特徴を以前に有した編集済み領域と組み合わせる。

本システムでは、画像のフレームを処理して、見極められた特徴に対応するボーブルを生成した後、ユーザは、ある特徴（例えば、他人）が削除されるべきであること、及び、２つの他の特徴（例えば、２人の友達）が保たれるべきであることを示す、一連のジェスチャーを実行することができる。例えば、ユーザは、望まれていないボーブルにタッチし、表示画面の下縁部まで指をスイープして、対応する視覚的特徴が画像から除去されるべきであることを示してもよい。（ボーブルは、指の後を追っても追わなくてもよい）。ユーザは次いで、友達ボーブルの各々をダブルタップして、それらのボーブルが保たれるべきであることを示してもよい。もう１つのジェスチャーは、メニューを呼び出し、そこから、ユーザは、編集ジェスチャーのすべてが入力されたことを示す。プロセッサは次いで、ユーザの命令に従って画像を編集する。「元に戻す」ジェスチャー（例えば、画面上の反時計回りの半円の指の跡）は、編集が満足の行かないものであると判明した場合にその編集を取り消すことができ、ユーザは別の編集を試みてもよい。（システムは、画面上のジェスチャー、例えば、指で「ｅ」の文字をなぞることによって、又はメニューからの選択によって、又は他の方法で、編集ボーブルジェスチャーを受信するためのモードにされてもよい。）

一連のボーブルのタップの順序により、ユーザの意図についての情報をシステムに伝え、対応する処理を引き出すことができる。

新しい街にいる旅行者が、各々の名所（例えば、エッフェル塔、凱旋門、ルーブル美術館など）の写真が付いた、様々な関心点を紹介する看板を見ることを考えられたい。ユーザのデバイスは、これらの写真の一部又は全部を認識し、描かれた各名所に対応するボーブルを提示してもよい。特定の順序でこれらのボーブルにタッチすることで、タップされた順序で、タップされた名所までの歩き方を取得するように、デバイスに命令してもよい。又は、名所の各々についてのウィキペディアのエントリを取って来て、示された順序で提示するように、デバイスに行わせてもよい。

特徴−プロキシボーブルは、個々のオブジェクト又は画像特徴に関連付けられるので、−タップされるか、又はジェスチャーに含まれるとき−対応するオブジェクト／特徴に応じて、応答を有することができる。すなわち、ジェスチャーに対する応答は、含まれたボーブルに関連付けられたメタデータの相関的要素でありうる。

例えば、人に対応するボーブルをタップすることで、像又はレストランに対応するボーブルをタップすることとは異なる何かを示す（又は、入手可能な動作の異なるメニューを呼び出す）ことができる。（例えば、前者のタップは、その人の名前及び社会的なプロファイルの表示又は公表を、例えば、フェイスブックから引き出してもよく、２番目のタップは、その像又はその彫刻家についてのウィキペディア情報を呼び出してもよく、後者のタップは、レストランのメニュー、及び、任意の現在のプロモーションについての情報を生じてもよい。）同様に、２つ以上のボーブルのタップを含むジェスチャーはまた、タップされたボーブルが何を表すかによって決まる意味、及び、オプションでボーブルがタップされた順序、を有することもできる。

経時的に、異なるボーブルにわたって全体的に一貫しているジェスチャー語彙は、標準化されるようにしてもよい。１回タップすることで、例えば、ボーブルのタイプに対応する特定のタイプの紹介情報を呼び出してもよい（例えば、人に関連付けられたボーブルがタップされる場合は名前及びプロファイル、ビルに関連付けられたボーブルがタップされる場合はオフィスの住所及び案内表示、史跡のためのボーブルがタップされる場合はウィキペディアページ、小売用製品のためのボーブルがタップされる場合は製品情報など）。２回タップすることで、例えば、ここでもやはり対応するオブジェクト／特徴に合わせて調整された、最も頻繁に呼び出される４つの動作のハイライトメニューを呼び出してもよい。ボーブルへのタッチ、及び、その場所を指で揺り動かすことで、別の応答−スクロールバーが付いた、省略されてない選択肢のメニューの表示など−を開始してもよい。もう１回揺り動かすことで、このメニューを引っ込ませてもよい。
アーキテクチャについての注記

本明細書は、いくつかの特徴を詳述する。実装を特徴のサブセットで実現することはできるが、やや好ましさに欠ける。より乏しい特徴のセットより、より豊富な特徴のセットを実装する理由を、以下の考察で説明する。

例示的ソフトウェアフレームワークは、以下のように、様々なコンポーネントを使用して、スマートフォンで実行する視覚的ユーティリティアプリケーションをサポートする。
・１．画面は、リアルタイムで修正されたカメラ画像であり、画像の一部に付着することができ、且つ、一度に起こる（可能性のある）複数のアクションのための値表示及びコントロールポイントとしての機能を同時に果たすことができる、動的アイコン（ボーブル）によってオーバーレイされる。画面はまた、−ちょうどユーザの注目の焦点に合った−価値のある、収益化可能な広告スペース（グーグルの検索ページに類似したようなもの）でもある。
・２．デバイスのための多数のアプリケーションは、単なる「スナップショット」ではなく、カメラ画像のライブシーケンスを処理する。多くの場合、複雑な画像判断が必要とされるが、応答性は優先されたままである。
・３．実際のアプリケーションは通常、表示されたボーブル、及び、ディスプレイによって示された現在見える「シーン」に関連付けられるようになり−ユーザインタラクションがこれらのアプリケーションのすべてレベルの標準部分になることが可能になる。
・４．画像の基本セット−特徴抽出機能は、バックグラウンドで実行することができ、見えるシーンの特徴がアプリケーションにとって常に入手可能になることを可能にする。
・５．個々のアプリケーションは、システムリソースの「一人占め」を許可されないことが望ましく、その理由は、見えるシーン内の変化により多くの有用性が増減するようになるので、２つ以上のアプリケーションが一度にアクティブになることが多いからである。（これは一般に、アプリケーションを有用にするために十分活発に保つために、適切なディスパッチ機能によるマルチタスキングを必要とする。）
・６．アプリケーションを、シーンデータ又はユーザの要望を監視することができる比較的低負荷の機能により、複数の層で設計し、より集中的な機能が適切なときに呼び出されるようにすることができる。ディスパッチ構成は、このコード構造をサポートすることができる。
・７．多数のアプリケーションは、デバイス自体の実際の機能を超えた動作を行うために、クラウドベースの部分を含んでもよい。ここでもまた、ディスパッチ構成は、この機能をサポートすることができる。
・８．アプリケーションは、相互に有用であるデータの投稿及びアクセスを行うための方法（例えば、ブラックボード）を必要とすることが多い。

厳密でなく、順序付けされない形であるが、以下は、上記の態様を−単に個々に望ましいだけでなく−全体の一部にすることができる、相互関係のいくつかである。
・１．ライブシーンを参照するアプリケーションは一般に、すべての（又は、少なくとも多数の）フレームからの基本画像特徴の効率的な抽出に依拠するものであり−そのため、リアルタイムの特徴を入手可能にすることは、重要な考慮すべき点である（それにもかかわらず、あるアプリケーションでは、必要とされないことがある）。
・２．効率的なアプリケーション開発及びテストを可能にするため、並びに、様々な機能によりデバイス上のアプリケーションをサポートするために、オプションで、任意のアプリケーションのかなりの部分を「クラウド内」に入れるための能力は、ほぼ義務的となる。そのような機能から、多くの利益が生じる。
・３．多数のアプリケーションは、支援されていないソフトウェアの現在の機能を超える認識機能によって、利益を得るようになる。これらのアプリケーションは、ユーザとのインタラクションが有効であることを求めるようになる。さらに、モバイルデバイスは一般に、ユーザインタラクションを促し−ＧＵＩがこの要件をサポートする場合にのみ、一貫した、フレンドリーなインタラクションが可能となる。
・４．複雑なアプリケーションを、制限された柔軟性のないリソースを有するデバイス上でサポートするには、ソフトウェアアーキテクチャからの全面的なサポートが必要となる。ＰＣスタイルのアプリケーションをこれらのデバイス上に押し込めることは、一般に、慎重な再設計をしない限り、満足の行くものではない。階層化ソフトウェアのマルチタスキングは、このデバイス制約のある環境内で魅力的なユーザ体験をもたらす重要なコンポーネントになりうる。
・５．画像情報を効率的な方法で複数のアプリケーションに提供することは、情報を一度だけ作り出すこと、及び、その情報を必要とするあらゆるアプリケーションによるその使用を可能にすることによって−情報アクセス及びキャッシングの非効率性を最小にする方法で−最良に行われる。「ブラックボード」データ構造は、この効率を達成する１つの方法である。

このように、詳述された技術の態様は個々に有用であるが、組み合わせると、それらの最高の効用を実現することができる。
さらにブラックボードについて

ガベージコレクション技術をブラックボードで用いて、もはや関連のないデータを除去することができる。除去されたデータは、ディスクファイルなど、長期ストアに転送されて、他の解析においてリソースとしての役目を果たすようにしてもよい。（除去されたデータはまた−他の箇所で述べるように−クラウドへ転送又はコピーされてもよい。）

１つの特定の構成では、代わりの基準のうち最初のものが満たされるとき、例えば、新しい発見セッションが開始するか、又は、ユーザの場所が閾値（例えば、１００フィート若しくは１０００フィート）より多く変化するか、又は、キーベクトルデータが生成されてから、新鮮でなくなる期間が経過する（例えば、３秒、若しくは３０秒、若しくは３００秒）とき、画像及び音声ベースのキーベクトルデータがブラックボードから除去される。前者の２つの場合、古いデータは、例えば、新しい発見セッションが開始した後、さらにＮの時間の増分（例えば、さらに２０秒）、又は、ユーザの場所が閾値より多く変化した後、さらにＭの増分（例えば、さらに３０秒）に渡って保持されうる。

非画像／音声キーベクトルデータ（例えば、加速度計、ジャイロスコープ、ＧＰＳ、温度）は典型的には、それらの制限されたストレージ要件に鑑みて、画像／音声キーベクトルデータよりも長くブラックボード上で保たれる。例えば、そのようなデータは、電話が次に４時間を超えて動作のスリープ（低バッテリ消耗）状態となるまで、又は、いくつかのそのような連続するスリープ状態が発生するまで、ブラックボード上で存続してもよい。

いずれかの古くなってきたブラックボードデータが新たに利用される（例えば、認識エージェントによって入力として使用されるか、又は、他のデータに関係することが新たに分かる）場合、ブラックボード上でのその許可された滞在が延長される。１つの特定の構成では、その滞在は、データの最初の作成からその新しい利用までの期間に等しい期間だけ延長される（例えば、その新しい利用時間を、新しい作成時間として扱う）。共通オブジェクトに関するキーベクトルデータは、新しいキーベクトル形式で共にまとめられうるものであり、同様にその許可されたブラックボード寿命を拡張してもよい。

除去されたデータが、ユーザの現在の位置に地理的に近接した閾値の基準内に集められた場合、データをまた、（例えば、長期ストアからの）その除去の後、ブラックボードにリストアすることもできる。例えば、ユーザがショッピングモールにいた間、ブラックボードが画像関連キーベクトルデータによりポピュレートされ、且つ、ユーザが車で帰宅した（ブラックボードをフラッシュする）場合、ユーザが次にそのモールに戻るとき、その場所に対応する、直前にフラッシュされたキーベクトルデータを、ブラックボードにリストアすることができる。（リストアされるデータの量は、ブラックボードのサイズ及び可用性によって決まる。）

いくつかの点で、ブラックボードは、センサフュージョンに焦点が置かれた、オブジェクトのための自動化されたウィキ（Ｗｉｋｉ）のようなものとして、実装されうるものであり、又は、別のデータ構造がそのようなものとしての役目を果たすことができる。数秒（又は、数分の１秒）毎に、データの数ページが落とされ、データ要素間のリンクが切られる（又は、新しいリンクが確立される）。認識エージェントは、ページをポピュレートし、リンクをセットアップすることができる。ページは、−一般にエディタとしての役目を果たすステートマシンにより−頻繁に編集される。各ウィキ著者は、他のすべてのページを見ることができ、寄与することができる。

システムはまた、例えば、ブラックボードに関連して、信用手順を呼び出すこともできる。認識エージェントがデータをブラックボードに新たに投稿しようとするたびに、認識エージェントが信用システムデータベース内で調査されて、その信頼性が決定されうる。このデータベースはまた、エージェントが商用であるかどうかを示すこともできる。ユーザによるその格付けを、そのデータに与えられるべき信頼性スコア（又は、ブラックボードへの参加がそもそも許可されるべきであるかどうか）を決定する際に、考慮することができる。信用の結果及び格納されたポリシーデータに基づいて、エージェントは、リンクに寄与する、リンクを切る（それ自体のリンク、又はサードパーティのリンク）、データを削除する（それ自体のデータ、又はサードパーティのデータ）、その他など、ある特権を付与又は拒否されうる。

１つの特定の構成では、デバイスは、ベリサイン（Ｖｅｒｉｓｉｇｎ）又はトラストイー（ＴＲＵＳＴｅ）など、独立した信用機関に相談して、認識エージェントの信用性を調査してもよい。デジタル署名技術など、知られている暗号技術を用いて、エージェントサービスを提供するサードパーティが、それ自体が主張するものであること、及び、いかなるエージェントソフトウェアも改ざんされていないことを認証することができる。そのような認証が成功する場合にのみ、及び／又は、独立した信用機関がプロバイダを、閾値（例えば、「Ｂ」又は１００のうち９３であって、ユーザにより設定されうる）より上の等級で格付けする場合にのみ、認識エージェントに、（例えば、情報を読み取り、及び／又は、書き込むことによって）デバイスのブラックボード構造とインタラクトする特権が付与される。

デバイスは同様に、（例えば、トラストイーを通じて）サービスプロバイダのプライバシー慣行を調査し、ある閾値が超えられるか、又は、パラメータが満たされる場合にのみ、インタラクションを可能にすることができる。
さらに処理、使用モデル、コンパス及びセッションについて

上述のように、いくつかの実装は、フリーランニングベースで画像をキャプチャする。制限されたバッテリ電力が制約である場合（現在は通常そうであるように）、システムは、ある実施形態では、この継続する画像の流れを、高度に選択的なモード−デバイスの計算機能のかなりの部分（例えば、１０％又は５０％）を、めったにデータの解析に適用しない−で処理してもよい。その代わりに、システムは、低電力消費状態で動作し、例えば、著しい電力コストをかけずに動作を行い、及び／又は、（例えば、毎秒キャプチャされうる１５、２４又は３０フレームのうち）毎秒又は毎分、少数のフレームのみを調べる。（Ａ）最初の低レベルの処理が、画像内に描かれたオブジェクトを正確に認識することができる高い確率を示す、及び（Ｂ）コンテキストが、そのようなオブジェクトの認識がユーザに関連するであろう高い確率を示す場合にのみ、システムは、電力消費が増大される第２のモードにスロットルアップする。この第２のモードでは、電力消費は、第１のモードの電力消費の２倍を超えるか、又は、１０、１００、１０００倍以上であってもよい。（示された確率は、特定の実装に応じて計算された数値スコアに基づくことができる。これらのスコア−成功するオブジェクト認識の、及び、ユーザとの関連性の−がそれぞれの閾値を超える（又は、単一の閾値を超える式によって結合する）場合にのみ、システムは第２のモードに切り替わる。）もちろん、ユーザが関心又は奨励を明示的又は暗示的に知らせる場合、若しくは、コンテキストが指図する場合もまた、システムは、第１のモードから出て第２のモードに切り替わることができる。

ある拡張現実（ＡＲ）アプリケーションのための新生の使用モデルで、例えば、ユーザがスマートフォンを外に出して、（例えば、所望のコーヒー店又は地下鉄の駅へナビゲートするために）変わりつつある表示に集中しながら、ある都市の街路を歩くと予期されるものは、賢明ではない。大変多くの代替物が好ましいように思われる。

１つは、ガイダンスを、イヤホン又はスピーカを通じて聞こえるように提供することである。発話されたガイダンスを提供するのではなく、より繊細な聴覚の手がかりを利用し−ユーザが、車のクラクション又は連れの話など、他の聴覚入力によりよく注意を払うことを可能にすることができる。１つの聴覚の手がかりは、ユーザが正しい方向に歩いており、所期の目的地に近付きつつあるかどうかを知らせるために、繰り返し率又は頻度が変化する、時々のトーン又はクリック音であってもよい。ユーザが交差点で誤って曲がろうとするか、又は、目的地へ向かうのではなく離れるように移動する場合、このパターンは、違いを示すような方法で変化することができる。１つの特定の構成は、ユーザが所期の目的地に向かって進行するにつれてより頻繁になり、ユーザが正しい方向から向きを変える場合に減少する、まばらなクリック音のパターンによる、ガイガーカウンタのような音響効果を用いる。（１つの特定の実施形態では、聴覚のフィードバックの音量が、ユーザの動きに従って変化する。ユーザが、例えば、信号機で立ち止まる場合、音量を大きくして−ユーザが異なる方向を向き、音声フィードバックによって、どの方向に進行するべきであるかを識別することを可能にしてもよい。ユーザが再び歩き出した後、ユーザがもう一度立ち止まるまで、音声の音量を小さくすることができる。音量又は他のユーザフィードバックの強度レベルは、このように、ユーザがナビゲーション方向に従って進行中であるときに下がり、ユーザが立ち止まるか、又は予期された進路からそれるときに上がることができる。）

動きは、加速度計又はジャイロスコープ出力による、ＧＰＳ座標を変更することによる、カメラによって検知される景色を変更することによる、その他など、様々な方法で検出することができる。

聴覚フィードバックの代わりに、上記の構成は、振動性のフィードバックを代わりに用いることができる。

モバイルデバイスの磁力計を、これらの実装で使用して、方向を検知することができる。しかし、モバイルデバイスは、ユーザ及びユーザの前方移動の方向に対して、任意の方法で向きが調節されてもよい。磁力計は、北の方を向いているユーザのベルトに留められる場合、デバイスが−デバイスがベルト上でどのように向けられているかに応じて−北、又は南、又はいずれかの他の方向を向いていることを示してもよい。

この問題に取り組むため、デバイスは、ユーザが向いている方向を正確に示すように、磁力計出力に適用されるべき補正係数を見極めることができる。例えば、デバイスは、時々のＧＰＳ測定結果を参照することによって、それに沿ってユーザが移動中である方向ベクトルを検知することができる。１０秒間に、ユーザのＧＰＳ座標の緯度が増しているが、経度は変わっていない場合、ユーザは−推定上、北寄りの方向を向いている間は−北へ移動している。デバイスは、この期間中の磁力計の出力に留意することができる。ユーザが明らかに北を向いていた間に、その磁力計が「東」を示していたような形でデバイスの向きが調節される場合、９０度の補正係数を見極めることができる。その後、デバイスは、−そのような解析が、異なる補正が適用されるべきであると示すまで−ユーザが向いている方向を決定するために、磁力計によって示された方向から９０度を減算することを知る。（そのような技術は幅広く適用可能であり−本明細書で詳述される特定の構成に限定されない。）

もちろん、そのような方法は、歩行のみではなく、自転車に乗ること、及び、他の形態の移動手段にも適用可能である。

詳述された構成は、画像がキャプチャされるときに解析されること、及び、そのキャプチャがユーザデバイスによって行われることを仮定したが、いずれも必須ではない。同じ処理が、以前に、及び／又は、他のところでキャプチャされた画像（又は音声）で行われてもよい。例えば、ユーザのデバイスは、１時間又は１週間前に、例えば、市の駐車場にある公共のカメラによって、キャプチャされた画像を処理してもよい。他の画像のソースには、フリッカー及び他のそのような公共の画像リポジトリ、ユーチューブ及び他のビデオサイト、公共のウェブをクローリングすることによって収集された画像などが含まれる。

（ライブ及び予め用意された画像データ、例えば、ライブ画像静止又はストリーム、及び、予め記録されたデータファイルを共に入れ替え可能に扱うことができるように、処理ソフトウェアを設計することは、有利である。これにより、見たところ異なるユーザアプリケーションが、同じ内部コアを用いることができるようになる。ソフトウェア設計者にとって、これはまた、ライブ画像アプリケーションを既知の画像又はシーケンスで繰り返しテストできるようになるため、有用でもある。）

多くの人々は、ボイスメールを、テキストに書き換えられた形式で見直すこと−長々と話す人のあらゆる発声を聞くよりも、関連のあるコンテンツを求めてざっと読むこと−を好む。同様に、視覚的な画像のシーケンスに基づいた結果を、多くのユーザによって、そのシーケンスをキャプチャするために要した時間よりも速く見直し、把握することができる。

市街地のブロックを歩いていくユーザが着用するヘッドウェアに搭載されたカメラを組み込んでいる、次世代モバイルデバイスを考えられたい。そのブロックの範囲中に、カメラシステムは、２０、６０秒以上のビデオを収集することができる。オーバーレイされたＡＲ提示が画像に基づいて結果を与えるのを（歩行中に）見て気が散るのではなく、ユーザは、素早く身をかわして歩行者及び障害物を避けるという目前のタスクに集中することができる。その間に、システムは、キャプチャされた画像を解析し、結果情報を後に見直すために格納することができる。（又は、歩行中に画像をキャプチャする代わりに、ユーザが立ち止まり、カメラ付きスマートフォンをスイープして、画像のパノラマをキャプチャし、次いで、電話をポケット又はハンドバッグにしまってもよい。）

（結果情報は、任意の形式であってもよく、例えば、画像内のオブジェクトの識別、そのようなオブジェクトに関して取得された音声／ビデオ／テキスト情報、視覚刺激に応答して取られた他のアクションについてのデータなどがある。）

都合のよい瞬間に、ユーザは、スマートフォンの画面をちらりと見て（又は、アイウェアのヘッドアップディスプレイをアクティベートして）、キャプチャされたフレームのシーケンスに基づいて出た結果を見直すことができる。このような見直しは、応答情報のみの提示を伴うことができ、及び／又は、それぞれの応答が基づいた、キャプチャされた画像を含むことができる。（応答がオブジェクトに基づく場合、オブジェクトは、シーケンスのいくつかのフレームに現れうる。しかし、応答は、これらのフレームのうち１つに対して提示されるだけでよい。）結果の見直しは、デバイスによって、標準化された提示で指図することができ、又は、ユーザによって指図することができる。後者の場合、ユーザは、ＵＩコントロールを用いて、結果データ（画像データと関連して提示されても、そうでなくてもよい）内をナビゲートすることができる。１つのＵＩは、アップルのアイフォンファミリによって普及した、よく知られているタッチインタフェースである。例えば、ユーザは、シーン（例えば、１秒若しくは５秒、又は、数分、別々にキャプチャされたフレーム）のシーケンス内でスイープすることができ、各シーンは、追加の情報を提示するためにタップすることができる、オーバーレイされたボーブルを有する。もう１つのナビゲーションコントロールは、グラフィカル又は物理的なシャトルコントロール−アドビプレミア（Ａｄｏｂｅ Ｐｒｅｍｉｅｒ）など、ビデオ編集製品からよく知られている−であり−ユーザが画像及び／又は応答のシーケンスの早送り、停止又は逆戻しをすることを可能にする。結果情報の一部又は全部は、視覚よりむしろ聴覚の形式で与えられ得る。ユーザインタフェースは、例えばタッチ応答よりむしろ声応答であり得る。

視覚情報がビデオの形式で収集されたが、ユーザは、静的シーンの形式で情報を見直すことが最も情報量が多い、と気付くことがある。これらの静的フレームは一般に、ユーザによって選択されるが、デバイスによって選択又は事前フィルタリングして、例えば、低品質である（例えば、ぼやけているか、又は、前景にある障害物によって遮られているか、又は、多くの情報内容を有していない）フレームを省いてもよい。

デバイスにより取得された応答のナビゲーションは、（例えば、各画像フレーム又は各応答を表示しながら）シーケンス全体をトラバースする必要はない。いくつかのモダリティは、情報内で前方にスキップし、例えば、毎秒フレーム、又は１０フレーム毎、又は、ある他のフレームカウント又は時間の間隔に対応して応答（及び／又は画像）のみを提示してもよい。又は、見直しは、顕著な点、又は内容に基づいて、前方にスキップすることができる。例えば、いかなる識別された特徴又は対応する応答もないシーケンスの部分は、完全にスキップされてもよい。１つ又は少数の識別された特徴（又は他の応答データ）を有する画像は、短い間隔で提示されてもよい。多数の識別された特徴（又は他の応答データ）を有する画像は、より長い間隔で提示されてもよい。ユーザインタフェースは、例えば、キャプチャに３０秒を要したシーケンスを、１０秒、又は２０秒、又は３０秒、又は６０秒などで見直すことができるように、ユーザが見直しの全体のペースを設定することができる、コントロールを提示してもよい。

直前に記載された、見直し時間からキャプチャ時間へのマッピングは、画像の時間的に変化する顕著な点（例えば、いくつかの抜粋は、興味深いオブジェクトが豊富であり、他の抜粋はそうでない）、その他によるなど、非線形でありうることは理解されよう。例えば、１５秒で見直されるシーケンスをキャプチャするために６０秒かかった場合、見直し中の３分の１は、キャプチャ中の３分の１に対応しない、などとなることがある。そのため、対象は、見直しデータ内で、キャプチャデータ内のそれらの時間の場所に比例しない時間の場所で発生することがある。

ユーザインタフェースはまた、ユーザが任意の見直しを停止して、さらなる検討又はインタラクションを可能にし、又は、特定の描かれた特徴についてさらなる解析及びレポートをするようにデバイスに要求することができる、コントロールを提供することもできる。応答情報は、画像がキャプチャされた順序に対応する順序、若しくは逆の順序（最新のものを最初にする）で見直されてもよく、又は、評価された、ユーザとの関連性に基づいて、若しくは、ある他の時間的順序ではない方法で順序付けすることができる。

そのようなインタラクション及び解析は、セッションベースの構成物を用いていると見なされてもよい。ユーザは、画像シーケンスの最中で見直しを開始し、前方若しくは後方に、継続的に、又は飛び回るようにトラバースすることができる。そのようなセッション構成の利点の１つは、後に獲得される画像が、以前に獲得された画像の理解に情報を与える助けとなりうることである。一例を挙げると、ある人の顔がフレーム１０で明らかにされうる（且つ、顔認識技術を用いて認識されうる）のに対して、その人の後頭部のみがフレーム５に示されうる。それにもかかわらず、この画像を１つの集まりとして解析することによって、その人にフレーム５で正しくラベルを付けることができ、フレーム５のシーンの他の理解は、そのような知識に基づくことができる。対照的に、シーン解析が全く現在及び先行のフレームのみに基づく場合、その人はフレーム５で匿名となる。

セッション構成物を、本明細書で詳述された実施形態を通じて使用することができる。いくつかのセッションは、自然の開始及び／又は終了点を有する。例えば、ユーザがカメラをポケットから取り出して、シーンを走査し、後にカメラをポケットに戻すときのように、キャプチャされたビデオ内の突然のシーン変換は、セッションを開始又は終了する役目を果たすことができる。（ＭＰＥＧから借用された技術をこのために用いることができ、例えば、新しいピクチャのグループ（ＧＯＰ）−「Ｉ」フレームで開始する−の開始を必要とするシーン変化を検出する。）ちょうど新しい関心を呈するシーンがセッションを開始することができるように、その新規性を失いつつあるシーンを使用して、セッションを終了することができる。（例えば、カメラが一晩中、ベッドサイドテーブルからの空間を凝視しており、次いで、手に取られて−画像に動きを新たに導入する場合、これは、セッションの開始をトリガすることができる。逆に、カメラが静的環境内で固定された向きのままにされる場合、この新しい視覚刺激の欠乏は、セッションをまもなく終了させることができる。）

画像ベースのセッションに類似した音声を、別法として、又は追加で、用いることができる。

電話内の他のセンサを使用して、セッションの開始又は終了をトリガすることもでき、加速度計又はジャイロスコープが、ユーザが電話を手に取ったか、又はその向きを変えたことを、信号で送るなどである。

ユーザアクションもまた、セッションの開始又は終了を明示的に信号で送ることができる。例えば、ユーザは、デバイスに、「トニーを見る」ように言葉で命令することができる。このような指令は、新しいセッションの論理的開始としての役目を果たすイベントである。（指令は、発話による以外で出すことができ、例えば、ユーザインタフェースとのインタラクションによる、電話を振って、その計算リソースが環境内にそのとき存在する刺激に集中／増大されるべきであることを信号で送ることによる、などである。）

いくつかのセッションは、「発見」又は「開始」など、言葉によって明示的に呼び出されうる。これらのセッションは、「停止」又は「やめる」など、指令によって、より早く停止されない限り、（例えば、格納された構成データに応じて−１０秒、３０秒、１２０秒、６００秒後に）ソフトウェアタイマからの信号に応答して、終了してもよい。タイマがセッションの終了に近付きつつあることを警告するＵＩが、ユーザに出されうるものであり、ボタン又は他のコントロール構成の選択を提示することができ−例えば、１０秒、３０秒、１２０秒若しくは６００秒に渡って、又は無期限に、セッションの延長を可能にする（又は、ユーザが別の値を入力できるようにする）。

不要なデータキャプチャ、及び、命令の曖昧性を回避するため、「見るだけ」又は「聞くだけ」などの指令が、ユーザによって出されうる。前者の場合、音声データはサンプリングされない（又は、サンプリングされる場合、格納されない）。後者と相互的である。

同様に、ユーザは、「この音楽を聴く」又は「この話を聞く」と言うことができる。いずれの場合も、キャプチャされたデータをクラスについてセグメント化且つ識別することができ、解析は、指定されたタイプに集中することができる。（他のものは廃棄されうる。）

同じく、ユーザは、「ＴＶを聴く」と言うことができる。この命令が呼び出すことができる他の処理に加えて、この命令は、プロセッサに対し、テレビ音声において、ニールセンカンパニー（Ｔｈｅ Ｎｉｅｌｓｅｎ Ｃｏｍｐａｎｙ）によって符号化されたようなデジタルウォーターマークデータを探すための手がかりをも与える。（そのようなウォーターマークは、特定のスペクトル領域、例えば、２ＫＨｚ〜５ＫＨｚ内で符号化される。そのような情報の知識により、デバイスは、そのサンプリング、フィルタリング及び解析を、それに応じて調整することができる。）

時として、所期の発見アクティビティとは無関係のデータがキャプチャされる。例えば、セッションの長さがタイマによって設定されるか、又は、視覚的な非活動の期間（例えば、１０秒）によって決定される場合、セッションは、−特に終了の近くで−所期の発見動作にとって価値のない情報をキャプチャすることがある。システムは、何のデータが所期の発見動作に関連があるかを識別するための処理を用いて、残りを廃棄することができる。（又は、同様に、システムは、何のデータが所期の発見動作に関連がないかを識別して、それ廃棄することができる。）

電器店におり、潜在的な関心のある製品の画像−特にそれらのバーコード−をキャプチャ中であるユーザを考えられたい。このセッションはまた、例えば、店の常連の、音声及び他の画像をキャプチャすることもできる。ビデオデータ、及び、特に−ユーザが思案する−連続するバーコードへのその動きから、システムは、ユーザが製品情報に関心を有すると推論することができる。そのような場合、システムは、音声データ、及び、バーコードを含まないビデオを廃棄することができる。（同じく、システムは、バーコードに関係しないキーベクトルデータを廃棄することができる。）いくつかの実装では、システムは、そのようなアクションに着手する前にユーザに問い合わせ、例えば、ユーザが何に関心を有するかのその仮説を詳述し、確認を求める。画像のバーコード領域に対応するキーベクトルデータのみが、保持されうる。

セッションは通常、時間的な構成物、例えば、一連の論理的に関係付けられたイベント又は処理を包含する間隔を示すが、他のセッション構成物もまた用いることができる。例えば、論理的セッションは、画像フレーム内、又は、画像シーケンス内（その場合、領域は動きを示すことができる）の特定の空間領域を参照することによって、定義されうる。（ＭＰＥＧ−４オブジェクトはそれぞれ、空間的セッションに関して考えられうる。他のオブジェクト指向データ表現でも同様である。）

複数のセッションが一度に進行中であり、全体的又は部分的に重複し、独立して開始且つ終了することがありうることを理解されたい。又は、複数のセッションは、独立して終了（又は開始）するが、共通の開始（又は終了）を共有することができる。電話を振ること（又は、タップすること）により、例えば、電話に対して、入ってくるセンサデータに増した注意を払わせることができる。電話は、増した処理リソースをマイクロフォン及びカメラデータに適用することによって、応答することができる。電話は、しかし、注目すべきマイクロフォンデータがないのに対して、視覚的シーンは劇的に変化しつつあることを、直ちに見極めることができる。電話は、したがって音声処理セッションを数秒後に終了し−音声の解析に適用されたリソースを低減するが、ビデオ処理セッションをはるかにより長く、例えば、アクティビティがおさまるまで、ユーザアクションが停止を信号で送るまでなど、継続することができる。

前に述べたように、発見セッションからのデータは一般に格納され、後で呼び戻すことができる。場合によっては、しかし、ユーザは、セッションの結果を廃棄することを望むことがある。ＵＩコントロールは、このようなオプションを可能にすることができる。

「トニーを見る」など、言葉による指令は、デバイスの動作を大いに支援することができる。いくつかの構成では、電話は、いつでも厳重警戒体制で−終わることのない連発するセンサデータにおいて何か有用なものを見極めようと試みる必要はない。その代わりに、電話は通常は、より低いアクティビティ状態であり（例えば、格納されたスロットルデータによって確立されたバックグラウンドレベルで処理を行う）、指示されるときにのみ、追加の処理リソースを充てることができる。

そのような指令はまた、他の処理をショートカットすることができる、重要な手がかりとしての役目も果たす。（例えば、ローカル又はリモートデータベース内に）格納されたデータを参照することによって、電話は、「トニー」が、人間、人、男性、フェイスブック友達、及び／又は、顔など、１つ又は複数の論理的クラスのメンバであることを、直ちに認識することができる。電話は、このようなクラスエンティティに関連付けられた特徴を見極め、解析するための処理を、起動又は調整することができる。言い換えれば、電話は、あるタスク、又は、オブジェクトのクラスを識別することができ、それに関係する必要はない。（「トニーを見る」は、紙幣を探すためでなく、バーコードを復号するためでなく、曲認識を行うためでなく、車に焦点を合わせるためでない等々の指令として見なされうる。これらの処理は、進行中である場合、終了されうるものであり、又は、単にセッション中に開始されないことがある。）この指令はこのように、デバイスが対処しなければならない視覚的検索空間を大幅に縮小する。

ユーザの指令を解釈する際に、電話によって調べられる、格納されたデータは、様々な形式でありうる。１つは、各語又は句に対して、１つ又は複数の関連付けられた記述子（例えば、「人」、「場所」若しくは「物」、又は、１つ若しくは複数の他のクラス記述子）を示す、簡単な用語集である。もう１つは、ユーザの電話帳であり−連絡先の名前をリストし、オプションで画像を提供するものである。もう１つは、例えば、友達及び関心の対象を識別する、ユーザのソーシャルネットワーキングデータである。いくつかのそのようなリソースは、クラウド内にあってもよく−複数のユーザのグループに渡って共有されてもよい。場合によっては、電話帳など、格納されたデータは、画像情報−又は手がかり−を含んで、電話の画像処理／認識タスクを支援することができる。

そのような実施形態において有用な音声認識技術は、当業者によく知られている。認識の精度は、その間で認識アルゴリズムがマッチしなければならない多数の候補語を限定することによって、増すことができる。用語集を千（又は百、又はより少数の）語に限定することによって、極めて高い認識精度を、制限された処理で、且つ、制限された時間で達成することができる。（このような縮約された用語集は、友達の名前、「開始」、「停止」、「見る」、「聞く」、「はい」、「いいえ」、「行く」、「やめる」、「終了」、「発見」など、一般的な命令語、一般的な色、数字及び他の番号、現在のエリア内で人気のある地理的な用語などを含んでもよい。）速度（又はローカルデータストレージ）が最重要の関心事ではない場合、グーグルのＧＯＯＧ４１１製品で使用されたその音声認識技術を用いることができる。音声認識技術の関連情報は、本譲受人の米国特許出願公開第２００８／００８６３１１号に詳述されている。

ユーザからの指令は、確立された定義を有する、よく知られた語である必要はない。ユーザからの指令は、発声、鼻を鳴らすこと、鼻声を出すこと、ブーブー言う声、又は、あるコンテキストにおいてユーザによって出された他のサウンドであってもよい。「ＵＨ−ＵＮＨ」は、否定を示す語−電話に対して、その現在の焦点又は結果が満足のいくものでないことを示す−として取ることができる。「ＵＭ−ＨＭＭ」は、肯定−電話の処理がユーザの意図に一致していることを確認する−として取ることができる。電話は、他の認識されない語と同様に、そのような発声に対して適切に応答するようにトレーニングされうる。

指令は、聴覚のものである必要はない。指令は、そうでない場合は、ジェスチャーによるものなどであってもよい。ここでもまた、電話は、トレーニング体験を通じて、意味の原因をジェスチャーに帰することができる。

いくつかの実施形態では、視覚投影は、電話を関心の対象に向けることができる。例えば、ユーザは、知られているスペクトル色、又は、異なる時間若しくはスペクトル変調を有する、レーザポインタを使用して、関心の対象を指すことができる。マイクロプロジェクタを同様に利用して、異なるターゲット（例えば、図１７のもの、又は、３×３の点の配列）を、関心のあるオブジェクト上に−可視光又は赤外線を使用して−投影することができる。（可視光が使用される場合、ターゲットは、たまに、例えば、各秒につき３０分の１秒間−検出ソフトウェアが同期されうるタイミング−に投影されうる。赤外線の場合、ターゲットは赤いレーザポインタの点により投影されて、赤外線パターンがどこに配置されるかがユーザに示されうる。場合によっては、ターゲットは、異なるユーザに個別化、例えば、シリアル化されて、公共の空間内などで、多数の投影されたターゲットの同時存在が可能にされうる。）そのような投影されたターゲットは、関心の対象を示すだけでなく、オブジェクトの向き、及び、オブジェクトまでの距離を決定できるようにし（その姿勢）−他の解析において有用な「グランドトゥルース」を確立することも行う。投影された特徴が画像内で発見された後、システムは、画像をセグメント化／解析して、その上でターゲットが発見されるオブジェクトを識別し、又は、他の応答アクションを取ることができる。

いくつかの構成では、電話は、そのような投影された指令を常に探している。他の構成では、そのようなアクションは、ユーザが言葉で「レーザを探す」又は「ターゲットを探す」と命令することによって、トリガされる。これは、指令の組み合わせが用いられ、発話され、視覚的に投影される一例である。異なるタイプの指令の他の組み合わせもまた可能である。

システムが特定の指令を認識しないか、又は、関連付けられたタスクを完了しようとするその試みに失敗する場合、システムは、舌を出して両唇の間でブーッとたてる音、音声の質問（例えば、「誰？」又は「何？」）によって、視覚的メッセージによって、その他など、ユーザへのフィードバックによって、そのことを示すことができる。

例えば、電話は、「トニーを見る」が、画像を処理して（その人についての参照画像がストレージ内で入手可能でありうる）ユーザの友達を見極めるための指令であることを、理解することができる。しかし、電話のカメラの視点のために、電話は、トニーを視野内で認識できないことがあり（例えば、トニーの背中がカメラの方に向いていることがある）、失敗をユーザに示すことができる。ユーザは、「帽子」、「緑のシャツ」、「近い」、「右の男」、その他−それによって所期の対象又はアクションが識別されうる他の手がかり−など、他の指令を試すことによって、応答することができる。

モール内のユーザは、棚の上にある３つのアイテムを示す画像をキャプチャすることができる。「真ん中のもの」と話すことによって、ユーザは、電話の処理リソースを、右及び左（及び他のところ）のオブジェクトを除外して、真ん中のオブジェクトについて学習することに集中させることができる。他の記述子を、同様に使用することができる（例えば、「それは赤いものです」又は「正方形のもの」など。）

このような例から、音声の手がかり（及び／又は他の手がかり）を、ＩＣＰデバイスの処理労力を制限する手段として使用できることは理解されよう。オブジェクト認識はこのように、音声認識（及び／又は他の手がかり）によって補われる／支援される。

（逆に、音声認識を、オブジェクト認識によって補う／支援することができる。例えば、デバイスが、ユーザの友達ヘレンがカメラの視野内にいると認識する場合、且つ、発話された音声の言葉が曖昧である−「ヒーロー」又は「ヘレン」又は「ハロー」かもしれない−場合、画像内でヘレンという人を認識することで、この曖昧性の解決を「ヘレン」に傾けることができる。同様に、視覚的コンテキストが、カモがいる池を示す場合、曖昧な語は「家禽」として解決されるかもしれないのに対して、視覚的コンテキストが野球場を示す場合、同じ語は「ファウル」として解決されるかもしれない。）ＧＰＳからなどの場所データを、発話における曖昧性の解決において同様に使用することができる。（場所データが、ユーザがスターバックスにいることを示す（記述子を緯度／経度データに関連付ける、知られているサービスのうち１つを通じてなど）場合、曖昧な発声は「茶」として解決されるかもしれないのに対して、ゴルフ場では、同じ発声は「ティー」として解決されるかもしれない。）

発話に対するシステムの応答は、何の処理に電話が着手しているか、又は、何の処理を完了したかに応じて、変わることがある。例えば、電話が、街路シーンを解析し、異なる店及びレストランに対応する視覚的ボーブルをオーバーレイした場合、ユーザがこれらの店又はレストランのうち１つの名前を話すことは、表示されたボーブルをタップすることに等しいと取られうる。「カモ（Ｔｈｅ Ｄｕｃｋ）」というバーが画面上にボーブルを有する場合、「カモ」という名前を話すことで、バーのハッピーアワーメニューを電話に表示させることができる。対照的に、ハイキング中に、ユーザの電話が池の中のマガモを認識しており、ユーザが「カモ」と話す場合、これにより、マガモについてのウィキペディアページの表示を呼び出すことができる。またさらに、１１月に、電話が、車の窓に付いているオレゴン大学の「Ｏ」のロゴを認識し、対応するボーブルをユーザの電話画面上にオーバーレイする場合、「カモ」という語を話すことで、オレゴンダックス（Ｏｒｅｇｏｎ Ｄｕｃｋｓ）フットボールチームの名簿又は試合のスケジュールを呼び出すことができる。（２月である場合、同じ状況で、オレゴンダックスバスケットボールチームの名簿又は試合のスケジュールを呼び出すことができる。）このように、同じ話し言葉（複数可）に対する異なる応答が、電話が着手した処理に応じて提供されうる（及び／又は、電話画面上に表示されたしるしによって変化する）。

直前に述べたように、応答はまた、場所、時刻、又は他の要因（複数可）に応じて変わることもある。正午に、そのボーブルが表示されるレストランの名前を話すことで、そのレストランのランチメニューを呼び出すことができる。夕方には、その代わりにディナーメニューが表示されうる。「ヒルトン（ＨＩＬＴＯＮ）」という名前を話すと、ヒルトンホテルが近くにあるとき、近くの物件の部屋代を表示することができる。（同じ「ヒルトン」という語で、ニューヨーク市内とは異なるデトロイトの部屋代の表示を促す。）

電話に話すことで、会話モードの命令が可能となる。最初の命令に応答して、電話は、最初のセットの動作に着手することができる。最初の命令（又は、それからの結果）に応答して着手されたアクションを見て、ユーザは、さらなる命令を出すことができる。電話は、さらに、さらなる動作で応答する。反復の方法で、ユーザは、ユーザの所望の結果を生じるように、電話をインタラクティブに導くことができる。どの時点であっても、ユーザは、セッションが保存されることを指図することができるので、反復処理を後の時間に再開することができる。「保存」される間、処理は、例えば、クラウド内で継続することができるので、ユーザが後の時間にインタラクションに戻るとき、追加の情報が使用可能となりうる。

「保存」は、ユーザプリファレンス又は適用、及びプライバシーの考慮すべき点に基づいて、異なって実装されうる。場合によっては、セッションのダイジェストのみが保たれる。ダイジェストには、場所データ（例えば、ＧＰＳからのもの）、方向／向きデータ（例えば、磁力計からのもの）、及び、日付／時間が含まれてもよい。最初にキャプチャされた画像／音声は保持されうるが、保持されないことが多い。その代わりに、派生物が保たれうる。あるタイプの派生物は、コンテンツフィンガープリントであり−人にわかりやすいコンテンツから導出されるが、それから人にわかりやすいコンテンツを再構成することはできないデータである。もう１つのタイプの派生物は、キーベクトルデータであり、例えば、形状、語、ＳＩＦＴデータ、及び、他の特徴を識別するデータである。もう１つのタイプの派生的なデータは、ウォーターマーク又はバーコードペイロードなど、復号されたマシン可読情報である。曲のタイトル及びテレビ番組名など、コンテンツを識別する、導出されたデータもまた保たれうる。

場合によっては、最初にキャプチャされた画像／音声データは−そのようなデータが表す人（複数可）から許可が受信されるのであれば−保たれうる。派生的なデータはまた、そのデータが人（例えば、顔識別ベクトル、声紋情報）に関連付けられる場合、保つための許可を必要とすることもある。

ちょうど、一般的なカメラが、カメラビューファインダ内で感知された顔の周囲に長方形を描画して、カメラのオートフォーカス及び露出がそれに基づくようになる被写体を示すように、ＩＣＰデバイスは、デバイス画面上に提示された視覚的な対象の周囲に長方形を描画するか、又は、他の視覚的なしるしを設けて、画像内の何がデバイスの処理の焦点になるかを、ユーザに知らせることができる。

いくつかの実施形態では、発話された手がかり又は命令によってデバイスの注目を向けるのではなく（又は、それに加えて）、ユーザは、画面上に表示されるようなオブジェクトをタッチし、又は、それを円で囲んで、デバイスがその労力を集中させるべき対象を示すことができる。この機能性は、システムがまだ、オブジェクトに対応するボーブルを表示していない（又は、表示しない）場合であっても、可能にされうる。
センサ関連システムの説明的構成

このセクションでは、上述の概念のうちいくつかをさらに詳述する。

従来技術では、スマートフォンは、ハンズフリーダイヤリングなどの目的のため、且つ、発話されたインターネットクエリ（セマンティック検索）のために、音声認識を使用していた。本技術のある実施形態によれば、音声認識が１つ又は複数のセンサベースのシステムの動作の調整に関連して用いられて、ユーザによって要望された情報の抽出が強化されるようになる。

図２５を参照すると、例示的スマートフォン７１０は、マイクロフォン７１２及びカメラ７１４など、様々なセンサを含み、各センサは、それぞれのインタフェース７１６、７１８を有する。電話の動作は、メモリ７２２内に格納されたソフトウェア命令によって構成された、プロセッサ７２０によって制御される。

電話７１０は、音声認識モジュール７２４を含むように図示される。この機能性は、メモリ７２２内の関連付けられた命令と共に、電話のプロセッサ７２０によって実装されうる。又は、専用ハードウェアプロセッサであってもよい。いくつかの実施形態では、この機能性は、電話の外部にあってもよく−データは、電話のＲＦセルラー−又はデータトランシーバ−機能を通じて、外部音声認識サーバとの間で渡される。又は、音声認識機能性を、電話とリモートプロセッサの間で分散させることができる。

使用中に、ユーザは、１つ又は複数の語を話す。マイクロフォン７１２は、関連付けられた音声を検知し、インタフェース電子機器７１６は、マイクロフォンによって出力されたアナログ信号をデジタルデータに変換する。この音声データは、音声認識モジュール７２４に提供され、音声認識モジュール７２４は、認識された発話データを返す。

ユーザは、例えば、「この男性の話を聞く」と話すことができる。電話は、男性音声フィルタを、マイクロフォンによって検知された音声に適用することによって、この認識された発話命令に応答することができる。（典型的な男性の声に出した発話は、約８５ヘルツまで下がった基本周波数を有するので、フィルタは、その値より低い周波数を除去することができる。）ユーザが「この女性の話を聞く」と言う場合、電話は、１６５Ｈｚ−典型的な女性の声の最低範囲−より低い周波数を除去するフィルタリング機能を適用することによって、応答することができる。どちらの場合も、そのような命令に応答して、電話によって適用されたフィルタリング機能は、約２５００Ｈｚ又は３０００Ｈｚの可聴周波数−典型的な音声周波数バンドの上端−を取り除くことができる。（音声フィルタリングは時として「等化」と呼ばれ、異なる可聴周波数をブーストすること、並びに、減衰することに関与することができる。）

電話は、このように、ユーザが関心を有する、ユーザの環境内の対象（例えば、「男性」）の発話された指示を受信し、受信された音声のその信号処理を、それに応じて構成する。このような構成が、図２６に描かれる。

電話の構成は、サンプリングレート、フィルタカットオフ周波数、ウォーターマークキーデータ、調べられるべきデータベースのアドレス、その他など、信号処理に関連して使用されるパラメータを確立することによって、実施することができる。他の構成では、異なる信号処理動作に対応する、異なるソフトウェア命令を実行することによって、この構成を実施することができる。又は、異なるハードウェア処理回路をアクティベートすること、又は、データを外部プロセッサへルーティングすることなどによって、この構成を実施することができる。

１つの特定の実装では、電話は、図２７のテーブル抜粋によって示されるような、異なる発話された対象（例えば、「男性」、「女性」、「ラジオ」、「テレビ」、「曲」など）を異なる信号処理動作に関連付ける、テーブル又は他のデータ構造を含む。音声認識エンジンによって認識された各語が、このテーブルに適用される。任意の認識された語が、テーブル内で識別された「対象」のうち１つにマッチする場合、電話は次いで、指定された信号処理命令を、（例えば、現在のセッション内で）その後に受信された音声に適用する。描かれた例では、電話が「男性」を認識する場合、電話は、対応する男性音声フィルタリング機能をその音声に適用し、フィルタリングされた音声を音声認識エンジンへ渡す。音声認識から出力されるテキストは次いで、−テーブルによって指定された指図によって−電話の表示画面上に提示される。

ユーザは、「ラジオを聴く」と話すことができる。図２７のテーブルを調べると、電話は、アービトロン（Ａｒｂｉｔｒｏｎ）デジタルウォーターマークを検出することによって、音声を識別するように試みることによって、この認識された発話データに応答する。音声は最初に、６ＫＨｚサンプリング周波数でサンプリングされる。音声は次いでフィルタリングされ、アービトロンウォーターマークに対応する復号手順が適用される（例えば、格納されたソフトウェア命令による）。復号されたウォーターマークペイロードは、アービトロンのリモートウォーターマークデータベースへ送信され、ラジオ放送に関するメタデータが、データベースからハンドセットへ返される。電話は次いで、このメタデータをその画面上に提示する。

アービトロンウォーターマークが音声において発見されない場合、テーブル内の命令は、動作の代替セットを指定する。特に、この「そうでなければ」という条件は、対象の「曲」に関連付けられた動作を適用するように、電話に命令する。

「曲」に関連付けられた命令は、音声を４ＫＨｚで低域フィルタリングすることから開始する。（より以前にキャプチャされた音声データは、メモリ内でバッファされて、より以前にキャプチャされた刺激のそのような再処理ができるようにされうる。）シャザム（Ｓｈａｚａｍ）曲識別フィンガープリントが、次いで計算され（別々に格納された命令を使用する）、結果として生じるフィンガープリントデータが、シャザムの曲識別データベースへ送信される。対応するメタデータが、このデータベース内でルックアップされ、表示のために電話へ返される。メタデータが発見されない場合、この表示は、音声が認識されないことを示す。

（詳述された信号処理動作は、電話上で、又は、（例えば、「クラウド」内の）リモートプロセッサによって、又は、分散した方法で行われうることを理解されたい。図２７に示された信号処理動作は、ユーザ入力に基づいてトリガされうる、とても大量の信号処理動作−及び、動作のシーケンス−の小さいサブセットでしかないことを、さらに理解されたい。パラメータが、テーブル内で詳述された命令において指定されないとき、デフォルト値を使用することができ、例えば、サンプリングレートでは８ＫＨｚ、低域フィルタリングでは４ＫＨｚ、などである。）

いくつかのスマートフォンは、２つ以上のマイクロフォンを含む。そのような場合、ユーザ入力によってトリガされた信号処理命令は、結合された音声ストリームへの、各マイクロフォンからのフェージング及び振幅の寄与を制御することによるなど、マイクロフォンアレイを構成することに関与することができる。又は、命令は、異なるマイクロフォンからの音声ストリームを別々に処理することに関与することができる。これは、例えば、サウンドの位置測定又はスピーカの識別について有用である。追加の信号調節動作が適用されて、所望の音声信号の抽出が改善されうる。センサフュージョン技術を通じて、スピーカの場所を、中でもカメラ及び姿勢評価技術に基づいて評価することができる。ソースが識別された後、且つ、複数のマイクロフォンの存在があれば、ビーム形成技術が利用されて、スピーカが特定されうる。一連のサンプルに渡って、チャネルを表す音声環境をモデル化且つ除去して、スピーカの音声の回復をさらに改善することができる。

電話は典型的には、マイクロフォン以外のセンサを含む。カメラは、ユビキタスである。他のセンサもまた、一般的である（例えば、ＲＦＩＤ及び近距離通信センサ、加速度計、ジャイロスコープ、磁力計など）。ユーザの発話を同様に用いて、そのような他のセンサデータの処理を構成することができる。

いくつかの実施形態では、この機能性は、ユーザが、「ディジマーク（ＤＩＧＩＭＡＲＣ） 見る」又は「ディジマーク 聞く」など、弁別的キーワード又は表現を話すこと−アプリケーションを開始し、後に続くものとしての語が単なる指図ではないことを、デバイスに合図すること−によって、トリガされるかもしれない。（他の実施形態では、異なる合図を−発話で、又は、ジェスチャーによるなど、他の方法で−提供することができる。さらに他の実施形態では、そのような合図を省略することができる。）

例えば、「ディジマーク テレビを見る」は、コマンドの特別な辞書を呼び起こして、フレームキャプチャレートを設定する、あるカラーフィルタを適用する、その他など、信号処理動作のシーケンスをトリガすることができる。「ディジマーク 人を見る」は、正しいフレッシュトーンのための色補償、顔の情報の抽出、及び、顔認識システムへの顔情報の適用を含む、手順を起動することができる。

ここでもまた、テーブル又は他のデータ構造を使用して、対応する信号処理動作を、異なるアクション及び関心のあるオブジェクトに関連付けることができる。それに対する命令がテーブル内で示されうる、異なるオブジェクトの中には、「新聞」、「本」、「雑誌」、「ポスター」、「テキスト」、「印刷物」、「チケット」、「箱」、「パッケージ」、「カートン」、「包装紙」、「製品」、「バーコード」、「ウォーターマーク」、「写真（フォトグラフ）」、「写真（フォト）」、「人」、「男性」、「少年」、「女性」、「少女」、「彼を（に）」、「彼女を（に）」、「彼らを（に）」、「人々」、「ディスプレイ」、「画面」、「モニタ」、「ビデオ」、「映画」、「テレビ」、「ラジオ」、「アイフォン」、「アイパッド（ｉＰａｄ）」、「キンドル（Ｋｉｎｄｌｅ）」などがある。関連付けられる動作には、光学式文字認識の適用、デジタルウォーターマーク復号、バーコード読み取り、画像又はビデオフィンガープリントの計算、並びに、色補償、フレームレート、露出時間、焦点、フィルタリング、その他など、補助的な画像処理演算及びパラメータが含まれうる。

追加の言い回しが利用されて、オブジェクトの記述子、色、形状、又は場所（前景、背景など）による、視覚的シーンのセグメント化の助けとなりうる。複数のサンプルに渡って、明滅する、点滅するなど、一時的な記述子を利用することができ、速い又は遅いなど、追加の動き記述子を適用することができる。

センサを含み、センサがデバイスの動きを識別できるようにするデバイスは、別の層の制御語を追加し、デバイスと所望のオブジェクトの間の関係を述べるものである。「追跡する」など、単純なコマンドは、デバイスが視覚的又は聴覚的シーンをセグメント化して、その軌道がデバイスの動きに近いそれらのオブジェクトのみを含むようにするべきであることを、示すかもしれない。

より複雑な構成では、電話は、いくつかのそのようなテーブルを含み、例えば、聴覚刺激のためのテーブル１、視覚刺激のためのテーブル２などである。電話は、認識されたユーザ発話における他の用語及び／又は構文に基づいて、どれを使用するべきであるかを決定することができる。

例えば、認識されたユーザ発話が「注視する（ｌｏｏｋ）」、「見守る（ｗａｔｃｈ）」、「眺める（ｖｉｅｗ）」、「見る（ｓｅｅ）」又は「読む（ｒｅａｄ）」などの動詞を含む場合、これは、視覚刺激がユーザにとって関心のあるものであることを、電話に信号で送ることができる。これらの語のうち１つがユーザの発話において検出される場合、電話は、ユーザの認識された発話からの他の語又は構文を、テーブル２に適用することができる。逆に、認識されたユーザ発話が、「聴く（ｌｉｓｔｅｎ）」又は「聞く（ｈｅａｒ）」などの動詞を含む場合、これは、ユーザが可聴刺激に関心を有し、テーブル１が調べられるべきであることを示す。

このようなルールベースの構成によって、電話は、２つの発話された句「ディジマーク この男性を見る」及び「ディジマーク この男性の話を聞く」に対して、異なって応答する。前者の場合、テーブル２（カメラによってキャプチャされた視覚刺激に対応する）が調べられる。後者の場合、テーブル１（マイクロフォンによってキャプチャされた可聴刺激に対応する）が調べられる。図２８及び図２９は、そのようなシステムの例を示す。

（記載されたテーブルの構成は、詳述された機能性を達成することができる多数の方法のうち、ただ１つでしかないことは、当業者には理解されよう。同様に、−上記で詳述されたものを超える−幅広い種類の動詞及び他の語を、ユーザが視覚刺激に関心を有するか、聴覚刺激に関心を有するかについての手がかりとして解釈できることは、当業者には理解されよう。）

時として、発話された名詞もまた、刺激のタイプについての何かを明らかにする。「ディジマーク 雑誌を見る」という句では、「ディジマーク」は、特別なライブラリ及び動作を呼び起こし、「見る」は、視覚刺激を言外に意味し、「雑誌」も同様に、視覚刺激についての何か、すなわち、それが静的な印刷された画像及び／又はテキスト（「見る」よりも「読む」を使用して、区別されうる）を備えることを伝える。対照的に、「ディジマーク テレビを見る」という句では、「テレビ」という語は、コンテンツが時間的態様を有するので、解析のために複数のフレームをキャプチャすることが適切であることを示す。

異なるパラメータ及び／又は信号処理動作を、異なるキーとなる語と関連付けることによって、電話が、発話されたユーザ入力によって本質的に再構成されることは理解されよう。ある瞬間、電話は、無線ウォーターマーク検出器として構成される。次の瞬間、電話は、顔認識システムとして構成される、などとなる。センサ関連システムは、ユーザの明らかな関心にサービスするように、動的に調整される。また、ユーザは一般に、機能（例えば、「バーコードを読み取る」）を明示的に宣言しないが、むしろ、対象を識別し（例えば、「パッケージを見る」）、電話は、所望の機能（又は、可能な機能の階層）を推論し、それに応じて、電話システムの動作を変更する。

同じ動作（例えば、デジタルウォーターマーク復号）を伴ういくつかの場合では、動作の詳細は、特定の対象に応じて変わることがある。例えば、雑誌におけるデジタルウォーターマークは典型的には、インク、媒体、及び、使用された印刷技術の間の違いにより、新聞に埋め込まれたデジタルウォーターマークとは異なる符号化パラメータを使用して符号化される。このように、「ディジマーク、雑誌を見る」及び「ディジマーク、新聞を見る」は共に、デジタルウォーターマーク復号動作を伴うことがあるが、前者は、後者とは異なる復号パラメータを利用することがある（例えば、関連色空間、ウォーターマークスケール、ペイロードなど）。（「ディジマーク」という出だしは、以下に続く例では省略されるが、それにもかかわらず、そのような合図が使用されうることは、当業者には理解されよう。）

異なる対象は、典型的な異なるカメラビューイング距離に関連付けられうる。ユーザが「雑誌を見る」と命令する場合、電話は、（例えば、テーブル内に格納された他の情報から）対象が約８インチ離れるようになると理解することができ、その距離でカメラシステムの焦点を合わせるように、機械又は電子システムに命令することができる。ユーザが「電子掲示板を見る」と命令する場合、対照的に、カメラは、８フィートの距離で焦点を合わせることができる。電話が見極めることを予期する画像特徴のスケールを、同様に確立することができる。

時として、ユーザの発話された命令は、「ない（ｎｏｔ）」又は「ノー（ｎｏ）」又は「無視する（ｉｇｎｏｒｅ）」など、否定を含んでもよい。

「パッケージを見る」というユーザ発話に対して、通常、バーコードを求めて、キャプチャされた画像データを調べることによって、応答する電話を考えられたい。発見される場合、バーコードは復号され、ペイロードデータがデータベース内でルックアップされ、結果として生じるデータが次いで画面上に提示される。バーコードが発見されない場合、電話は、格納されたデータ内の「そうでなければ」命令に頼り、例えば、ウォーターマークデータを求めて、キャプチャされた画像データを解析し、あらゆる復号されたペイロードデータをウォーターマークデータベースに提出して、関連メタデータを取得し、関連メタデータが次いで画面上に表示される。（ウォーターマークが発見されない場合、さらなる「そうでなければ」命令は、電話に、可能性が高いテキストを求めて画像を調べさせ、且つ、あらゆるそのような抜粋をＯＣＲエンジンに提出させることができる。ＯＣＲエンジンからの結果が次いで、画面上に提示される。）

ユーザが「パッケージを見る、バーコードを無視する」と言う場合、これは、通常の命令の流れを変更する。この場合、電話は、キャプチャされた画像からバーコードデータを復号しようと試みない。その代わりに、電話は、最初の「そうでなければ」命令、すなわち、ウォーターマークデータを求めて画像を調べることに、直接進行する。

時として、ユーザは、対象を具体的に識別しないことがある。時として、ユーザは、否定、例えば、「ノー ウォーターマーク」のみを提供することがある。そのような場合、電話は、（例えば、格納されたリスティングによる）コンテンツ処理動作の優先順位付きの階層を刺激データに適用し−ユーザの発話から、適用不可能であるとして示される（又は、推論される）動作をスキップすることができる。

言うまでもなく、発話された関心の対象の指示は、他の潜在的な関心の対象の否定として、又は、刺激データに適用されるかもしれない異なるタイプの処理の否定として理解されうる。（例えば、「この男性を見る」は、電話に対して、デジタルウォーターマーク又はバーコードを求めて画像を調べる必要がないという手がかりを与える。）

このように、ユーザの宣言は、ユーザのありそうな要望を最もよく満たすために、電話の処理システムが何の識別技術及び他のパラメータを用いるべきであるかを決定する助けとなることは、理解されよう。

本技術と共に使用するために適した音声認識ソフトウェアは、ニュアンスコミュニケーションズ（Ｎｕａｎｃｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）から入手可能であり、例えば、同社のスピーチマジック（ＳｐｅｅｃｈＭａｇｉｃ）及びナチュラリースピーキングＳＤＫ（ＮａｔｕｒａｌｌｙＳｐｅａｋｉｎｇ ＳＤＫ）である。フリーの音声認識ソフトウェア（例えば、オープンソースライセンスにより入手可能）には、カーネギーメロン大学による、スフィンクス（Ｓｐｈｉｎｘ）ファミリーの提供品が含まれる。これには、スフィンクス４（ＪＡＶＡ実装）、及び、ポケットスフィンクス（Ｐｏｃｋｅｔ Ｓｐｈｉｎｘ）（ＡＲＭプロセッサ上で使用するために最適化された簡易バージョン）が含まれる。他のフリーの音声認識ソフトウェアには、Ｊｕｌｉｕｓ（音声対話技術コンソーシアムにおいて協力する日本の大学のコンソーシアムによる）、ＩＳＩＰ（ミシシッピ州）、及び、ＶｏｘＦｏｒｇｅ（オープンソース音声コーパス及び音響モデル、スフィンクス、Ｊｕｌｉｕｓ及びＩＳＩＰと共に使用可能）が含まれる。

ユーザの発話された音声を参照することによって、ユーザの関心を検知することに関連して説明されたが、他のタイプのユーザ入力もまた用いることができる。凝視（目）追跡構成を用いて、ユーザが見ている対象を識別することができる。手又はレーザポインタによって指す動きを、同様に検知且つ使用して、関心の対象を識別することができる。ユーザがスマートフォンと（例えば、キーボードによって、又は、タッチジェスチャーによって）触覚的にインタラクトすることを伴わない、様々なそのようなユーザ入力を使用することができる。そのような構成の全体が、図３０において描かれる。

いくつかの実施形態では、電話によって適用される信号処理はまた、部分的に、コンテキスト情報に基づくことも可能である。

他のところで論じたように、「コンテキスト」の１つの定義は、「エンティティ（ユーザ及びアプリケーション自体を含む、ユーザとアプリケーションの間のインタラクションに関連があると考えられる人、場所又はオブジェクトの状況を特徴付けるために使用することができる、任意の情報」である。コンテキスト情報には多くの種類がある可能性があり、計算コンテキスト（ネットワーク接続性、メモリ可用性、ＣＰＵ競合など）、ユーザコンテキスト（ユーザプロファイル、場所、アクション、プリファレンス、近所の友達、ソーシャルネットワーク（複数可）、及び、状況など）、物理的コンテキスト（例えば、照明、雑音レベル、トラフィックなど）、時間的コンテキスト（時刻、日、月、季節など）、コンテンツコンテキスト（主題、行為者、ジャンルなど）、上記の履歴などが含まれる。
さらに視覚的動作及び関連する観念について

デバイス上のリソース及び「クラウド」の中で、所望のタスクを動的に配分する能力により、本技術の特定の実施形態は、制限されたメモリ及び計算リソースに関連してアプリケーション応答を最適化するために、よく適している。

紙幣の単位名の確認など、複雑なタスクでは、タスク全体を、最も時間又はコスト効果的なプロバイダに任せることができる。ユーザが米国の紙幣を認識することを望み、それを行うことができる外部プロバイダ（例えば、入札者）が発見される場合、高レベルのタスクをクラウド内で行うことができる。効率のため、クラウドサービスプロバイダは、デバイス上で行われたサブタスクによって抽出された−例えば、その画像データを処理して、必要とされる外部帯域幅を最小にする−、又は、個人的に識別可能又は異質のデータを除去するためにフィルタリングされた、画像特徴データを使用することができる。（このローカルで処理されたデータを同時にまた、他のタスクにとっても−ローカル及びリモートの両方で−使用可能にすることもできる。）

いくつかの構成では、外部プロバイダの処理の詳細は、ローカルデバイスに知られておらず、ローカルデバイスは、必要とされた入力データのタイプ及びフォーマット、並びに、提供された出力データのタイプ／フォーマットについてのみ、命令される。他の構成では、プロバイダは、その処理を行う際に適用された特定のアルゴリズム／解析についての情報を発行し、ローカルデバイスが、代わりのプロバイダの間で選択を行う際に、この情報を考慮できるようにする。

計算モデルが、あるタスクが常にデバイス上で行われることが可能であることに集中する限り、これらの基本動作は、デバイス毎に構想された、可能性が高いクラウドアプリケーションのタイプに合わせて調整されるようになる。例えば、アプリケーションが、紙幣又は他の文書の特定の解像度、コントラスト及び適用範囲を有する画像を必要とするようになる場合、マッチング機能が、提供された「画像獲得」機能のために必要とされるようになる。

一般に、トップダウンの思考は、デバイスが提供するためのいくつかの大変具体的な低レベルの特徴及び機能をもたらす。その時点で、設計者は、ブレーンストーミングを少々行うことになる。これ以上有用な何の特徴又は機能を、これらは示唆するか？ そのような一般に有用な機能のリストがまとめられた後、基本動作のスィートを選択することができ、メモリ及び電力要件を最小化するために準備することができる。

余談として、Ｕｎｉｘは長い間、中間ストレージを最小化することができる「フィルタチェーン」を使用してきた。変換のシーケンスを行うために、カスケード可能な「フィルタ」がステップ毎に設けられる。例えば、変換Ａ−＞Ｂが、実際には以下のシーケンスであると仮定する。
Ａ｜ｏｐｌ｜ｏｐ２｜ｏｐ３＞Ｂ

各ステップがある項目を同じか又は類似のサイズの新しい項目に取り込み、Ａがそれでも最後には入手可能になると仮定する場合、メモリ要件は、サイズ（Ａ）＋サイズ（Ｂ）＋２バッファであり、各バッファは典型的には、全オブジェクトサイズよりはるかに小さく、動作が完了するとき、割り振り解除される。複雑な局所変換を、例えば、このように少数の単純な局所演算を組み合わせることによって得ることができる。行われる動作のストレージ及び数を共に減らし、時間、電力、又は双方を節約することができる。

少なくともいくつかのアプリケーションは当然、短い画像シーケンスを入力として、考えられる。システム設計は、短い、おそらく固定長（例えば、３若しくは４、又は４０フレーム）の画像シーケンスバッファを設けることによって、この考えをサポートすることができ、このバッファは、あらゆる画像獲得動作のための行き先である。様々なアプリケーション要件を、このバッファへの様々な書き込み方法を提供することによってサポートすることができ、すなわち、１つ又は複数の新しい画像がＦＩＦＯ挿入される、１つ又は複数の新しい画像がフィルタを介して結合され（最小、最大、平均、．．．）、次いでＦＩＦＯ挿入される、１つ又は複数の新しい画像がフィルタを介して、対応する現在のバッファ要素と結合され、次いで挿入される、などである。

ある画像シーケンスが、特定の方法で満たされた固定サイズのバッファによって表される場合、画像をシーケンスから抽出することは、画像をそのバッファから抽出することに置き換えられるようになる。そのような各抽出は、画像のセットをバッファから選択し、フィルタを介して結合して、抽出された画像を形成することができる。抽出の後、バッファは不変であることがあり、１つ又は複数の画像が除去されていることがあり、又は、それらの画像のいくつかが基本画像動作によって更新されうる。

パターン認識で一般に使用される画像の、少なくとも３つのタイプのサブ領域がある。最も一般的であるのは、通常は点又は行の断片のリストとしての、幾何学的関係が損なわれていない、単なる抽出された点のセットである。次は、おそらく、連続する行の断片のリストとしての、画像の接続された領域である。最後は、おそらく、画像内のピクセル値の配列及びオフセットとしての、長方形のサブ画像である。

サポートするべきこれらの特徴タイプのうち１つ又は複数を決めると、表現を効率又は一般性のために選択することができ−例えば、画像上の任意のところに位置する「１−ｄ」曲線は、単にピクセルのシーケンスであり、よって、あるタイプのブロブである。したがって、双方が同じ表現、及び、よって、全く同じサポート機能（メモリ管理など）を使用することができる。

表現が選択された後、任意のブロブ「抽出」は、単一の２ステップ動作である可能性がある。第１に、ブロブ「本体」を定義し、第２に、ピクセル値を画像からそれらの対応するブロブの場所にコピーする。（これは「フィルタ」動作であってもよく、結果として画像をもたらし、並びに静的画像に適用可能となるフィルタ動作の任意のシーケンスに従ってもよい。）

画像であっても、処理のための「オークション」処理は、内部フォーマットから適切な外部フォーマットへ、且つ、適切な外部フォーマットから変換するために使用可能な動作を有することを含むことができる。ブロブ及び他の特徴では、かなり様々なフォーマット変換がサポートされる可能性がある。

画像処理又はコンピュータビジョンパッケージの「通常」の考察から少々外れて、詳述された構成で実行されうるアプリケーションの性質、及び、含まれる（典型的でない）制約及び自由に戻ることは、おそらく有用である。

例えば、いくつかのタスクは、直接のユーザアクションによって「トリガされる」ようになるが、他のタスクは、適切なとき、単に開始され、それら自体をトリガすると予想されうる。すなわち、ユーザは、スマートフォンを駐車場に向けて、「自分の車を発見する」アプリケーションをトリガするかもしれず、そのアプリケーションは、画像のスナップ写真を撮り、それを解析しようと試みることになる。それどころか、ユーザはそのアプリケーションをトリガすることを好み、次いで、車が識別されたことをデバイスが知らせるまで、カメラを周囲にパンしながら、駐車場内を歩き回るだろう。ディスプレイは次いで、ユーザの現在地からキャプチャされた、車がハイライトされた画像を提示してもよい。

このようなアプリケーションは普及するかもしれないし、そうでないかもしれないが、多くのものは、画像が獲得され、サンプリングされ、可能性が高いターゲットの存在について調べられ、そのターゲットの検出が「実際」のアプリケーションをトリガするようになり、そのアプリケーションがより多くの計算能力を候補画像に注ぐようになるという、処理ループを含むようになる可能性が高い。処理は、成功したとアプリケーション及びユーザが同意するまで継続するようになり、又は、明らかに成功しないことで、ユーザにその処理を終了させる。望ましくは、「仮検出」ループがカメラのみで実行可能であり、いかなる外部リソースも、有用であるかもしれないと期待する理由があったときにのみ呼び込まれるようにするべきである。

もう１つのタイプのアプリケーションは、オブジェクト追跡用であるだろう。ここでは、既知のタイプのオブジェクトが（方法を問わず）位置指定されると、画像の連続がその後に獲得され、アプリケーションが終了されるか又はオブジェクトが失われるまで、そのオブジェクトの新しい場所が決定され、示される。この場合、アプリケーションは、外部リソースを使用して、オブジェクトを最初に位置指定するかもしれず、それらのリソースを使用して、既知の検出パターンを、検出されていた特定のインスタンスに特化させるようになる可能性が大変高いが、新しいパターンインスタンスを使用する次の「追跡」アプリケーションは、電話上で支援を受けずに実行することが望ましい。（おそらく、このようなアプリケーションは、遊び場で子供の世話をする際の支援となる。）

いくつかのアプリケーションでは、パターン認識タスクがかなり粗雑である−おそらく、フレームのシーケンス内の青のパッチ（例えば、セーター）を追跡する−ことがあるが、他のアプリケーションでは、例えば、紙幣の認証など、大変高度であるかもしれない。上記の２つのように、かなり少数の制御ループは、非常に多数の単純なアプリケーションには十分となる可能性が高い。これらのアプリケーションは、抽出される特徴、用いられるパターンマッチング技術、及び、頼りにされる外部リソース（もしあれば）の性質が異なるようになる。

上記のように、少なくとも少数のパターン認識アプリケーションは、基本モバイルデバイス上で、ネイティブで実行することができる。すべてのパターン認識方法が、そのような制限されたプラットフォームにとって適切になるとは限らない。可能なものには、特に、大変小さいテンプレート、又は、大変小さい要素を用いる合成テンプレートによる、単純なテンプレートマッチングと、検出されたパラメータのための適度な解像度要件による、ハフスタイルのマッチングと、ニューラルネット検出とが含まれるであろう。ネットをトレーニングするには、多分、外部リソースが必要となるが、特に、ＤＳＰ又はグラフィックスチップを用いることができる場合、その適用をローカルに行うことができることに留意されたい。大きいデータベースルックアップを用いるか、又は、計算集中的過ぎる任意の検出技術（例えば、Ｎ空間最近傍（Ｎ−ｓｐａｃｅ ｎｅａｒｅｓｔ−ｎｅｉｇｈｂｏｒ））、は、多分、外部リソースを使用して最良に行われる。
さらにクランプ化に関して

前述のように、クランプ化は、ピクセルのグループを関連するものとして識別するための処理を指す。

１つの特定の手法は、「共通運命」を有する、例えば、共通の動きを共有する、シーン項目をグループ化することである。もう１つの手法は、マルチ閾値又はスケール空間ツリーに依拠する。データ構造（ブラックボードを含む）は、クランプが識別された方法（複数可）を示すシンボルのタグを格納することができ、又は、クランプを、そのタイプを示すラベルと共に格納することができる。（認識エージェントは、タグ／ラベル辞書に寄与することができる。）

タグは、使用されるクラスタリング方法、及び、関与する特徴（例えば、明るさのエッジと組み合わせられた色の均一性）から導出することができる。最低レベルでは、「局所的に明るいエッジ」又は「最も均一の色」が使用されうる。より高いレベルでは、「類似の均一性レベル、近いが、局所的に明るいエッジによって分離される」などのタグを用いることができる。さらにより高いレベルでは、「葉のような」又は「顔のような」などのタグが、−認識エージェントからの情報に基づいて−クランプに割り当てられうる。結果は、タグが付けられた特徴によりポピュレートされたｎ次元空間であり、（場合によっては、特定の平面に対する特徴の投影として）より高次の認識技術を容易にする。

共通の動きの方法は、画像間の点／特徴の２Ｄの動きを考慮する。これらの動きは、例えば、ほぼ同一の変位、又は、ある画像方向に沿ったほぼ直線の変位、又は、画像点の周りのほぼ共通の回転でありうる。他の手法もまた使用することができ、オプティックフロー、点の群れ（ｓｗａｒｍ ｏｆ ｐｏｉｎｔｓ）、動きベクトル、その他などである。

マルチ閾値ツリー方法を使用して、画像内でネストされたブロブのツリーを関連付けることができる。図２０Ａ及び２０Ｂは、例示的である。要するに、画像（又は抜粋）は閾値化され−各ピクセル値が検査されて、閾値を満たすか、超えるかが判定される。最初に、閾値は黒に設定されうる。あらゆるピクセルは、この基準に合格する。閾値の値が次いで上げられる。画像の部分は、閾値テストを満たさなくなり始める。エリア（ブロブ）は、閾値テストが満たされるところに現れる。最終的に、閾値は明るい（高い）レベルに達する。このテストに合格する、少数の小さい場所のみが残る。

図２０Ａ及び２０Ｂによって示されるように、画像全体が黒閾値に合格する。暗い閾値では、単一のブロブ（長方形）がテストを満たす。この閾値が増大されるにつれて、２つの楕円のブロブエリアが分化する。閾値を明るい値へ上げ続けることで、第１のエリアを２つの明るい楕円に分離させ、第２のエリアを単一の小さい明るいエリアへと分解させる。

ピクセル値をこのような変動閾値に対してテストすることにより、画像フレーム内のピクセルの関連クランプを識別するための迅速且つチェックの方法がもたらされる。

実用的な実装では、画像が最初にガウス又は他のぼけにより処理されて、わずかな雑音アーチファクトが結果に極度に影響を与えないようにされうる。

（この方法の変形は、エッジ検出器としての役目を果たすことができる。例えば、閾値がいくつかの値に渡って上げられる間に、ブロブのうち１つの輪郭が大体固定されたままである場合、この輪郭は、エッジであるとして見極められる。このエッジの強度は、輪郭が本質的に固定される閾値の値の範囲によって示される。）

輝度値に対する閾値化が詳述されたが、他の閾値メトリックを同様に、例えば、色、テクスチャの程度などに対して比較することができる。

そのような方法によって識別されたクランプは、画像特徴及びキーベクトルなど、他のデータのための、組織化する構成物としての役目を果たすことができる。例えば、画像データから抽出された特徴／キーベクトルが関係付けられることを識別するための１つの手法は、それらを含む最小の閾値化されたブロブを識別することである。ブロブが小さいほど、特徴が多分、より関係付けられる。同様に、第１及び第２の特徴が関係付けられることが知られている場合、最初の２つの特徴を含む、最小の閾値化されたブロブを発見することによって、関係する他の特徴を評価することができる。そのブロブ内のいかなる他の特徴もまた、多分、第１及び第２の特徴に関係付けられる。
自由及び制約

いくつかのパターン認識方法の実用性は、アプリケーションの要求で、浮動小数点演算を行う、又は、ＤＳＰのベクトル演算を呼び出すための、プラットフォームの能力によって決まる。

より一般には、直観的コンピューティングプラットフォームにおいて、いくつかの具体的な自由及び制約がある。自由には、すぐ近くの通信アクセサリデバイス上にあるか、クラウド内にあるかにかかわらず、オフデバイスリソースをタスクが使用する能力が含まれ、デバイス上で実行することが「どうしてもできなかった」アプリケーションが、そのように実行するように見えることが可能となる。制約には、制限されたＣＰＵパワー、制限された使用可能メモリ、及び、変動するリソースでアプリケーションが続行する必要性が含まれる。例えば、使用可能なメモリが制限されるかもしれないだけでなく、突然減らされ（例えば、通話が開始される）、次いで、より高い優先順位のアプリケーションが終了するとき、再度使用可能になるかもしれない。

速度もまた制約であり−一般に、メモリとの緊張関係にある。迅速な応答への要望は、平凡なアプリケーションであってもメモリ上限に反して押し上げるかもしれない。

特徴表現の点から、メモリ制限は、値の明示的配列（可能なパラメータの数に比例するメモリ要件）よりもむしろ、要素の順序付きリスト（エントリの数に比例するメモリ要件）の維持を助長することがある。動作シーケンスは、全中間画像ではなく、最小限のバッファを（上述のように）使用するかもしれない。画像の長いシーケンスは、１つ又は複数の平均された結果と共に、短い実際のシーケンスによって、「フェイク」されるかもしれない。

キャニーエッジ演算子など、いくつかの「標準」のイメージング機能は、一般的な使用にとってはリソース集中的過ぎることがある。しかし、同じことが、ＦＦＴ処理−スマートフォンのアプリケーションがますます用いている動作−について、以前に言われた。
検討に適したデバイス上の処理

上記の制約の関連において、以下の概要は、ローカルデバイスのレパートリーに含まれうる幅広く有用な動作のクラスを詳述する。
・Ｉ．タスク関連動作
・・Ａ．画像関連
・・・ｉ．画像シーケンス演算
・・・・ａ）画像をシーケンスから抽出する
・・・・ｂ）画像をシーケンス範囲から生成する
・・・・ｃ）特徴又はＲＯＩをシーケンス中で追跡する
・・・ｉｉ．画像変換
・・・・ａ）点別再マッピング
・・・・ｂ）アフィン変換
・・・・ｃ）局所演算：例えばエッジ、局所平均、．．．
・・・・ｄ）ＦＦＴ又は関連
・・・ｉｉｉ．画像からの視覚的特徴抽出
・・・・ａ）２Ｄ特徴
・・・・ｂ）１Ｄ特徴
・・・・ｃ）３Ｄのような特徴
・・・・ｄ）完全画像−＞ＲＯＩのリスト
・・・・ｅ）非局所特徴（色ヒストグラム、．．．）
・・・・ｆ）スケール、回転不変量強度特徴（ｒｏｔａｔｉｏｎ−ｉｎｖａｒｉａｎｔ ｉｎｔｅｎｓｉｔｙ ｆｅａｔｕｒｅｓ）
・・・ｉｖ．特徴操作
・・・・ａ）２Ｄ特徴からの２Ｄ特徴
・・・・ｂ）１Ｄ−１Ｄなど
・・・・ｃ）２Ｄ特徴からの１Ｄ特徴
・・・ｖ．ＵＩ−画像フィードバック（例えば、画像上でタグ関連シンボルをオーバーレイする）
・・Ｂ．パターン認識
・・・ｉ．特徴セットのセットからパターンを抽出する
・・・ｉｉ．シーケンス、画像又は特徴セットをタグに関連付ける
・・・ｉｉｉ．タグ又はタグセットを特徴セットから「認識する」
・・・ｉｖ．合成又は複雑なタグを、「認識された」タグのより単純なセットから「認識する」
・・Ｃ．アプリケーション関連通信
・・・ｉ．システム状態から必要な機能のリストを抽出する
・・・ｉｉ．入札の要求をブロードキャストする−応答を収集する
・・・ｉｉｉ．抜き出されたデータを送信し、アウトソース結果を受信する
・ＩＩ．アクション関連動作（多くは既に基本システムアクション内で存在するようになる）
・・・ｉ．システム機能をアクティベート／アクティベート解除する
・・・ｉｉ．システムメッセージを作成／消費する
・・・ｉｉｉ．システム状態を検出する
・・・ｉｖ．システムを新しい状態へ移行する
・・・ｖ．保留中、アクティブ及び完了済みアクションのキューを維持する
ユーザ体験及びユーザインタフェース

本技術の１つの特定の実施形態は、訓練されていないユーザが、モバイルデバイスの使用を通じて、どのツールを使用するかを決定する必要なしに、自分の環境について（及び／又は、自分がいるところのオブジェクトについて）の情報を発見できるようにしながら、要望されるときはいつでも、どこでも、中断された発見体験を継続するための能力を提供する。

アイフォンなど、既存のシステムが、そのようなニーズを満たさないことは理解されよう。例えば、ユーザは、所望の特定のタイプの情報をもたらすために、何千もの異なるアイフォンアプリケーションのうちどれ（複数可）が起動されるべきであるかを、決定しなければならない。また、ユーザが動作を指図中にさえぎられる場合、後の時間又は場所で発見処理を再開する方法はない。すなわち、ユーザは、オブジェクト又は環境とのインタラクションのポイントで、発見を体験しなければならない。後の探究又は共有のためにその体験を「保存」する能力はない。

図１９は、画面１０２及び発見ボタン１０３を含む、例示的ユーザインタフェースを有するスマートフォン１００を示す。

発見ボタン１０３は、電話にその発見モード−入ってくる刺激を解析して、意味及び／又は情報を見極める−をアクティベートさせるように、ハードワイヤード又はプログラムされる。（いくつかのモダリティでは、電話は常にそのような刺激を解析中であり、ボタンアクションは必要とされない。）

描かれた画面１０２は、トップペイン部分１０４及び下方ペイン部分１０６を有する。これら２つのペインの相対的サイズは、バー１０８によって制御され、バー１０８は、描かれたペインを分離する。グラフィカルユーザインタフェース設計者によく知られている構成物を使用して、バー１０８をユーザによってドラッグして、トップペインをより大きく、又は、ボトムペインをより大きくすることができる。

例示的ボトムペイン１０６は、地図、画像、ＧＩＳ層、その他など、空間的情報を提示する役目を果たす。例示的ボトムペイン１０６は、ジオロケーションペインと呼ばれうるものであるが、その機能性を限定するように解釈されるべきではない。

例示的トップペイン１０４は、以下の考察でセンサペインと呼ばれる−しかし、これもまた限定ではない。図示のモードでは、このペインは音声情報、すなわち、聴覚シーン可視化を提示する。しかし、ボタン１３１がＵＩ上に提示され、ボタン１３１によって、このトップペインを切り替えて、視覚情報を提示することができる（この場合、ボタンが次いで「音声」となり−ユーザが元に切り替えることができるようになる）。磁力計、加速度計、ジャイロスコープ、その他など、他のタイプのセンサデータもまた、このペイン内に提示されうる。

トップペインで開始すると、スマートフォンの１つ又は複数の音声センサ（マイクロフォン）は、音声環境を聴く。話者／音声認識ソフトウェアは、キャプチャされた音声を解析して、話している人（複数可）を識別し、話されている言葉を見極めようと試みる。マッチがなされる（例えば、ローカルに、又は、クラウド内に格納された、格納済み話者特徴付けデータを使用する）場合、識別された話者に対応するアイコン１１０が、ディスプレイの縁に沿って提示される。スマートフォンが、（例えば、ユーザの電話帳から、又は、フェイスブックからの）認識された話者の格納された画像１１０ａにアクセスできる場合、この画像をアイコンとして使用可能である。そうでない場合、デフォルトアイコン１１０ｂを用いることができる。（認識ソフトウェアが、指定された信頼性閾値を持って性別判定を行うことができる場合、男性及び女性話者に対して異なるデフォルトアイコンが用いられうる。）例示されたＵＩは、２人の話者が検出されたことを示すが、他の状況では、さらに多くてもさらに少なくてもよい。

音声認識に加えて、ウォーターマーク検出及びフィンガープリント計算／ルックアップなど、処理を音声ストリームに適用して、その音声ストリームを識別することができる。これら又は他の手法によって、ソフトウェアは、周囲の音声において音楽を検出し、そのような検出を示すアイコン１１２を提示することができる。

他の別個の音声タイプもまた検出され、示されうる（例えば、道路の騒音、鳥の鳴き声、テレビ等々。）

アイコン（１１０、１１２など）の各々の左側には、波形表示１２０がある。描かれた実施形態では、実際のデータに基づいた波形が表示されるが、要望される場合、予め用意された描写を使用することができる。（スペクトルヒストグラムなど、他の形式の表現を使用することができる。）例示されたアナログ波形は、左に移動し、最新のデータが右に来る（テキストの行を読む我々の体験に類似している）。各波形の最新の間隔のみが、左の見えない所に移動する前に、提示される（例えば、３、１０又は６０秒）。

周囲の音声の、別個の波形へのセグメント化は、概算であり、正確な分割は困難である。２つの異なるマイクロフォンを用いる単純な実施形態では、２つの音声ストリームの間の差分信号が決定され−第３の音声ストリームがもたらされる。第１の話者が話し中であると検知されるとき、これらの３つの信号のうちより強いものが提示される（波形１２０ａ）。その話者が話し中でないとき、その波形（又は別のもの）が、大幅に減衰されたスケールで提示され−話者が黙り込んだ（が、周囲の音声レベルは、レベルがあまり小さくならなかったかもしれない）ことが示される。

第２の話者でも同様に、アイコン１１０ｂによって示される。その人の音声が認識される（又は、ある人間の音声が見極められるが、識別されず−しかし、アイコン１１０ａによって示された話者ではないことが知られる）とき、３つの音声信号のうちより大きいものが波形形式１２０ｂで表示される。その話者が黙り込むとき、かなり減衰された波形が提示される。

波形１２０ｃが同様に提示されて、検知されたバックグラウンド音楽が示される。３つのソースのうちどれであっても、話者の音声と最も相関性のないものからのデータが、提示されうる。ここでもまた、音楽が中断される場合、波形をソフトウェアによって減衰して、同じことを示すことができる。

前述のように、数秒の音声のみが波形１２０によって表現される。その間に、スマートフォンは、音声を解析中であり、意味を見極めている。この意味には、例えば、話者のための音声認識テキスト、及び、音楽のための曲識別が含まれうる。

音声ストリームについての情報が見極められるとき、ボーブル（アイコン）１２２によって表現することができる。ボーブルが、まだ画面を横断している波形によって表現される音声の抜粋に対応する場合、ボーブルは、ボーブル１２２ａ（例えば、話者の最近の発声のためのテキストファイルを示すことができる）など、波形に近接して配置されうる。ボーブル１２２ａは、対応する波形と共に、その波形が仮想停止ゲート１２３で見えない所に消えるまで、左へ移動する。その時点で、ボーブルは短いスレッド１２４上にスレッド化される。

ボーブル１２２は、ひもでつながれた真珠のように、スレッド１２４上で列を作る。スレッド１２４は、制限された数のボーブル（例えば、２から５）を保持するために十分な長さでしかない。スレッドが一杯になった後、追加された各ボーブルは、最も古いものを見えない所に押し込む。（消えているボーブルはなお、履歴において使用可能である。）新しいボーブルが到着しない場合、既存のボーブルは、ある時間間隔の後、「年を取って駄目になる」ので、画面から消えるように設定されうる。この間隔は、ユーザにより構成されうるものであり、例示的間隔は、１０若しくは６０秒、又は、１０若しくは６０分などであってもよい。

（いくつかの実施形態では、プロトボーブルは、任意の関連情報が見極められる前であっても、波形又は他の特徴に関連して提示されうる。そのような場合、プロトボーブルをタップすることで、電話にその処理の焦点を、関連付けられた特徴に関する情報の取得に合わせさせる。）

ボーブル１２２は、見えるしるしを含んで、その内容をグラフィカルに示すことができる。例えば、ある曲が認識される場合、対応するボーブルは、関連付けられたＣＤカバーアートワーク、アーティストの顔、又は、音楽配信者のロゴ（ボーブル１２２ｂなど）を含んでもよい。

別の音声シーン可視化は、電話に対するそれらの方向を参照することにより、異なる音声ストリームを識別し、描く。例えば、ある波形は、右上から入ってくるように表示されるかもしれないが、別の波形は、左から到着するように表示されうる。中央のハブは、ボーブル１２２がそれに対して（ひも１２４上のように）蓄積する、そのような波形のための停止ゲートとしての役目を果たす。ハブをタップすることで、格納された履歴情報を呼び戻す。このような構成を、図１９Ａに示す。

スマートフォンによるすべてのアクション及び発見の履歴は、−ローカルで、及び／又は、リモートで−まとめられ、格納されうる。格納された情報には、発見された情報（例えば、曲のタイトル、発話されたテキスト、製品情報、テレビ番組のタイトル）のみが含まれうるか、又は、さらなるもの−音声ストリームの記録、及び、カメラによってキャプチャされた画像データなどが含まれうる。ユーザが適切なプロファイル設定によって選択する場合、履歴には、キーベクトル、加速度計、及び、すべての他のセンサデータなどを含む、セッション中に電話によって処理されたすべてのデータが含まれうる。

加えて、又は別法として、ユーザインタフェースには、「保存」ボタン１３０が含まれうる。このコントロールのユーザアクティベーションにより、システムの情報状態が格納される。もう１つのユーザコントロール（図示せず）は、格納された情報をシステムにリストアできるようにするので、−異なる場所及び時間であっても−デバイス解析及びユーザ発見が継続できるようになる。例えば、ユーザが書店で本を拾い読み中であり、且つ、ポケットベルがユーザをすぐ近くのレストランの空いているテーブルへと呼び出す場合、ユーザは「保存」を押すことができる。後に、このセッションを呼び戻すことができ、例えば、デバイスがそのジャケットアート又はバーコードを参照することにより、関心のある本を探し、且つ、デバイスが、バックグラウンドで再生中であった曲を識別して、ユーザは発見を継続することができる。

図１９は、音声環境についての情報をセンサペイン１０４で示すが、同様の構成物を用いて、視覚環境についての情報を、例えば、本明細書の他の部分で詳述された構成を使用して、提示することができる。前述のように、「カメラ」ボタン１３１をタップすることで、モダリティを音声から視覚へ（且つ、逆に）切り替える。視覚モードでは、このセンサペイン１０４を使用して、拡張現実モードのインタラクションを表示することができる。

図１９の、より下方のジオロケーションペイン１０６を見ると、地図データが示される。地図は、グーグルマップ、ビング（Ｂｉｎｇ）、その他など、オンラインサービスからダウンロードされうる。

地図データの解像度／粒度は最初に、スマートフォンがその現在地を知る粒度によって決まる。高度に正確な場所情報が分かる場合、精巧に詳細な地図が提示されうる（例えば、ズームインされる）が、大体の場所しか分からない場合、それほど詳細ではない地図が示される。ユーザは、ズームイン又はアウトして、従来のように、スケールコントロール１４０によって、より多くの、又はより少ない詳細を取得することができる。ユーザの場所は、より大きいプッシュピン１４２又は他のしるしによって示される。

ユーザが、例えば、表示されたボーブルをタップすることによって、発見セッション又は発見動作に携わるたびに、より小さいピン１４６が地図上に立てられ−遭遇の場所をメモリアライズ（ｍｅｍｏｒｉａｌｉｚｉｎｇ）する。発見動作についての情報（時間及び場所を含む）は、ピンに関連して格納される。

ユーザがピン１４６をタップする場合、以前の発見についての情報がストレージから呼び戻され、新しいウィンドウ内で提示される。例えば、ユーザがショッピングモールで１足のブーツの発見体験をした場合、より以前の遭遇中にユーザに提示された値段及び他の情報と共に、このブーツの画像が表示されうる（ユーザによりキャプチャされたものか、又は、ストックフォト）。もう１つの発見は、ナイトクラブでのある曲の認識、又は、教室内のある顔の認識に関与したかもしれない。すべてのそのようなイベントが、表示された地図上のピンによってメモリアライズされる。

ジオロケーションペインは、時間コントロール１４４（例えば、グラフィカルスライダ）によって、以前の発見の再検討を容易にする。一方の極端では、以前の発見が示されない（又は、過去１時間以内の発見のみ）。しかし、コントロールを変えることによって、地図は追加のピン１４６でポピュレートされ−各ピンは、以前の発見体験、及び、その発見体験が行われた場所を示す。コントロール１４４は、例えば、先週、先月又は去年の発見を示すように設定されうる。「Ｈ」（履歴）ボタン１４８がアクティベートされて、スライダ１４４が現れるようにされうるが−これにより、過去にあった発見にアクセスできるようになる。

いくつかの地理的な場所（例えば、ショッピングモール又は学校）では、ユーザの発見の履歴が豊富過ぎて、ピンが地図を雑然とふさぐことがないように、フィルタリングされなければならないことがある。このため、あるモードは、発見の開始及び終了日を、（例えば、スライダ１４４のような、一対のコントロールによって）ユーザにより設定できるようにする。又は、例えば、ノードストローム（Ｎｏｒｄｓｔｒｏｍ）、ブーツ、音楽、顔、人々の名前など、対応するＵＩコントロールを通してキーワードフィルタが適用されうる。

コンパスの矢印１４６がディスプレイ上に提示されて、地図の理解が支援される。描かれたモードでは、地図上の「上」は、電話が向けられる方向である。矢印１４６がタップされる場合、この矢印は、さっと垂直の向きになる。地図が次いで回転されて、地図上の「上」が北に対応するようになる。

ユーザは、所望のものと同じくらい多く、又は同じくらい少ない、ユーザのアクションについての情報を、他者と共有することに応じることができる。あるシナリオでは、ユーザのプロファイルは、地元のショッピングモールでの自分の発見を、ただし、自分のフェイスブックソーシャルネットワークアカウント上で選ばれた友人のみと、且つ、ユーザが（通常すべてのアクションを記録する、システムの履歴アーカイブとは対照的に）発見を明示的に保存した場合にのみ、共有することを可能にする。ユーザが、書店で特定の本についての情報を発見し、発見を保存する場合、この情報は、データストアクラウドに投稿される。ユーザが１週間後にショッピングモールに戻り、より以前の訪問からのボーブルを再検討する場合、ユーザは、ある友人がその間にその書店におり、ユーザの格納された発見体験に基づいて、その本を見たことを発見することができる。その友人はその本についてのコメントを投稿し、場合によっては、同じ主題の別の本を推奨したかもしれない。このように、発見についてのクラウドアーカイブを、他者が発見し、他者自身の内容により拡張するために、共有することができる。

同様に、ユーザは、ユーザの発見履歴の一部又は全部を、例えば、視聴者測定、群衆トラフィック解析、その他などの目的で、商用エンティティが使用可能にすることに同意してもよい。
例示的な動作のシーケンス

図１９の構成は、ユーザインタラクションなしで提示可能であることは理解されよう。表示された動作のモードは、デバイスが任意の期間の非活動の後に戻るスクリーンセーバーなど、デバイスのデフォルトでありうる。

ある特定の構成では、電話がかけられるとき、ソフトウェアがアクティベートされる。アクティベーションは、デバイスの動き、又は、他のセンサイベント（例えば、視覚刺激変化、又は、画面上でタップを検知すること）によってトリガされうる。動作の最初の１秒くらいで、カメラ及びマイクロフォンは、既にアクティベートされていない場合、アクティベートされる。電話は、（例えば、ローカルＷｉＦｉノード、又は、他の全体のチェックを識別することによって）迅速な位置の概算を行い、利用可能な位置情報が、他の処理が使用するためにバックボードに書き込まれる。ある場所情報が入手可能になるとすぐに、対応する地図データが画面上に提示される（地図の中心が対応する場所からの電話の距離が、１００ヤード又は１マイルなど、格納された閾値を超えない場合、キャッシュされた地図データのフレームは十分でありうる）。電話はまた、クラウドサービスへの接続を確立し、電話の場所を送信する。ユーザのプロファイル情報は、オプションで、最近の履歴データと共に呼び戻される。

アクティベーションの１秒から３秒の間、デバイスは、環境についてのデータを処理し始める。画像及び／又は音声シーンセグメント化が起動される。キャプチャされた画像に示された特徴がプロトボーブルによって示され、スクリーンに表示され得る（例えば、ここが注目する画像の明るい領域であるが、ここを超えてこれ見ることも価値がある。）。検知されたデータに関するキーベクトルは、クラウド処理へのストリーミングを開始することができる。より精緻化されたジオロケーションを決定することができ、更新された地図データを取得／提示することができる。以前の発見体験に対応するプッシュピンを、地図上でプロットすることができる。ユーザの友人の場所を示すアイコンなど、他のグラフィカルオーバーレイもまた提示されうる。ユーザが、繁華街又はショッピングモールにいる場合、別のオーバーレイが、商品を特売で提供している店、又は、それらの店内の場所を示してもよい。（このオーバーレイは、選択に基づいて、例えば、小売店の得意客クラブの会員に対して、提供されうる。ＲＳＳタイプの配信は、そのようなサブスクリプション情報を電話へ、オーバーレイ提示のために供給してもよい。）もう１つのオーバーレイは、すぐ近くの車道などの現在の交通状態を示してもよい。

はっきり見える、関心のある特徴は既に、視覚的シーン（例えば、バーコード）内で識別され、カメラビュー内でハイライトされ、又は輪郭が描かれうる。高速画像セグメント化動作の結果（例えば、それは顔である）に、例えば、長方形の輪郭を描くことによって、同様に注目することができる。デバイス側の認識動作の結果は、例えば、センサペイン１０４上のボーブルとして現れてもよい。ボーブルＵＩは、タップされうるという意味で、アクティベートされ、関連情報を提示するようになる。ボーブルを同様に、所望の動作を信号で送るために、画面全体に渡ってドラッグすることができる。

まだ、ユーザは電話でアクションを取っていない（ただし、例えば、ポケット又はハンドバッグから電話を持ち上げることを除く）。

電話が視覚的発見モードである場合、オブジェクト認識データが、（例えば、ローカルで、又は、クラウドから）センサペイン上で現れ始めることがある。データは、タイド（Ｔｉｄｅ）洗剤の箱を認識し、例えば、それに応じてブランドの付いたボーブルをオーバーレイしてもよい。

ユーザは、タイドボーブルを画面の異なる角へドラッグして、異なるアクションを信号で送ることができる。ある角は、ごみ入れアイコンを有してもよい。別の角は、「保存」アイコンを有してもよい。タイドボーブルをそこへドラッグすることで、発見を継続するために後に呼び戻され、再検討されうる、履歴データストアにタイドボーブルを追加する。

ユーザがタイドボーブルをタップする場合、あらゆる他のボーブルが画面上でグレー表示にされうる。電話は−そのタップがユーザによる関心／意図の表現であると理解して−、リソースを、選択されたボーブルによって示されたオブジェクトのさらなる解析に転じる。

ボーブルをタップすることで、そのボーブルのためのコンテキストメニューを呼び出すこともできる。そのようなメニューを、ローカルに供給することができ、又は、クラウドから提供することができる。タイドでは、メニューオプションには、使用説明書、ユーザがメーカーにフィードバックを提供することができるブログなどが含まれうる。

メニューオプションの１つは、ユーザがさらなるメニューオプションを望むことを信号で伝えることができる。このオプションをタップすることで、他の、より人気のないオプションを取得し、そのオプションをユーザに提示するように、電話に指図する。

別法として、又は加えて、メニューオプションの１つは、ユーザがオブジェクト認識結果に満足していないことを、信号で伝えることができる。このオプションをタップすることで、さらに激しく動いて、さらなる発見をするように試みるように、電話（及び／又はクラウド）に指図する。

例えば、書店にいるユーザは、アルバート・アインシュタインを描く本のカバーの画像をキャプチャしてもよい。電話は、その本を認識し、本のレビュー及び購入オプションなど、リンクを提供してもよい。ユーザの意図は、しかし、アインシュタインについてのさらなる情報を取得することであったかもしれない。元に戻って、さらに働くように電話に伝えることで、電話がアインシュタインの顔を認識し、次いで、その本ではなく、その人に関するリンクのセットを提示することにつながる可能性がある。

いくつかのユーザインタフェースでは、メニューオプションは、一度タップされるか、二度タップされるかに応じて、代わりの意味を有してもよい。特定のメニューオプションのシングルタップは、より多くのメニューオプションが表示されることを、ユーザが望むことを示してもよい。同じメニューオプションの２回のタップは、ユーザが元のオブジェクト認識結果に満足せず、他の結果を望むことを、信号で伝えてもよい。二重の意味は、表示されたメニュー説明文にテキストで示されうる。

別法として、慣例が生じることがあり、それにより、シングルタップの意味が与えられると、ユーザは２回のタップのメニューの意味を推論することができる。例えば、シングルタップは、電話のローカルリソースを使用して、示されたタスクを行うための命令を指示することができるのに対して、ダブルタップは、クラウドリソースによるその同じタスクの実行を指図する。又は、シングルタップは、コンピュータリソースを排他的に使用して、示されたタスクを行うための命令を指示することができるのに対して、ダブルタップは、アマゾンのメカニカルタークサービスを使用することによるなど、人間により支援された実行のためにタスクを任せるための命令を指示することができる。

ボーブルをタップする代わりに、ユーザは、１つ又は複数のボーブルを円で囲むこと−画面上でグラフィックの周囲を指でなぞることによって、関心を示すことができる。この形式の入力により、ユーザは、ボーブルのグループへの関心を示すことができるようになる。

このようなジェスチャー（２つ以上のボーブルへの関心を示す）を使用して、単に２つのボーブルを別々にタップすることとは異なるアクションをトリガすることができる。例えば、図２４のアップル及びＮＡＳＡボーブルを共通の円の中に囲むことで、アップル及びＮＡＳＡの両方に関する情報を探し求めるように、システムに指図することができる。それに応じて、デバイスは、例えば、ＮＡＳＡアイフォンアプリについての情報を提供してもよく、このアプリにより、ＮＡＳＡ画像がアイフォンのユーザにとって入手可能となる。そのような発見は、アップル及びＮＡＳＡのロゴを別々にタップすることによっては、生じていなかったであろう。同様に、ＮＡＳＡのロゴ及びローリング・ストーンズのロゴをまとめて円で囲むことで、ボイジャー宇宙船（フィクション−「スターマン」という映画で紹介された）に搭載された金メッキの銅ディスクにローリング・ストーンズの曲が含められたことについての、ウィキペディアの記事の発見につながる、検索をトリガしてもよい。

図２１Ａは、図１９とはやや異なる発見ＵＩを示す。視覚的発見が画面の大部分を占有し、画面の底部の帯が、検知された音声情報を表示している。この白黒の描写でははっきり見えないが、図２１Ａの画面の中央に渡って、「Ｏ」という様式化された文字（オレゴニアン（Ｏｒｅｇｏｎｉａｎ）新聞のバナーからの活字書体を使用）からなる、オーバーレイされた赤いボーブル２０２がある。この場合、電話は、オレゴニアンの記事から、デジタルウォーターマーク信号を検知し−このボーブルの表示をトリガした。

ボーブルをクリックすることで、ボーブルを、アニメのように、図２１Ｂに示されたコンテキスト依存メニューへと変換させる。中央には、図２１Ａで発見されたオブジェクト（例えば、新聞の記事）を表現するグラフィックがある。左上には、ユーザがその記事又はリンクを他者にメール送信することができる、メニュー項目がある。右上には、その記事がユーザアーカイブに保存されることを許可する、メニュー項目がある。

左下には、ユーザがその記事に関する注釈を書くことができる、ブログへのリンクがある。右下には、その記事に関連付けられたビデオへのリンクがある。

新聞の読者は、次に、カジノの広告に遭遇することがある。電話によって検知されるとき、ボーブルが再度現れる。このボーブルをタップすると、例えば、演奏者の今度のコンサートのチケットを買うため、コンテストに参加するため、及び、カジノホールの３６０度の没入型ツアーに出るための、異なるセットのメニューオプションが立ち上がる。「保存」オプションもまた提供される。画面の中央には、カジノのロゴが付いた長方形がある。

デジタルウォーターマーク付きの薬剤の瓶を見ると、図２２に示された、さらにもう１つのコンテキストメニューが立ち上がる。中央には、錠剤がどのように見えるべきであるかの画像があり−（例えば、旅行者がいくつかの異なる錠剤を混合した瓶から）薬を飲むとき、安全性のチェックが可能となる。薬はまた、名前（「Ｆｅｄｒａｔｒｙｌ」）、強さ（「５０ｍｇ」）によって、且つ、処方医師（「Ｌｅｓｌｉｅ Ｋａｔｚ」）によっても識別される。あるメニューオプションは、ユーザの医師（又は薬剤師）に電話をかけさせる。このオプションは、ユーザの電話帳で処方医師の名前を検索し、その番号に電話をかける。もう１つのオプションは、自動化された処方薬補充要求を薬局に提出する。もう１つのリンクは、その薬物についてのよくある質問を提示し、且つ、ＦＤＡにより要求された開示情報を含む、ウェブサイトにつながる。もう１つは、ユーザの現在の場所を中心とした地図−プッシュピンが、Ｆｅｄｒａｔｒｙｌを置く薬局にマークを付けている−を示すことができる。電話を、水平ではなく、垂直に持つことで、ビューをマーカーなしの拡張現実提示に切り替え、電話が動かされて異なる方向を向くとき、実際の水平線の画像上にオーバーレイされた、現れては消える、Ｆｅｄｒａｔｒｙｌを置いている薬局のロゴを示す。（オレゴン州ポートランドのＳｐｏｔＭｅｔｒｉｘによる、アイフォン用の３ＤＡＲ拡張現実ＳＤＫソフトウェアが、例示的実施形態において拡張現実提示のために使用される。）「保存」オプションもまた設けられる。

同様に、ＰＤＦ文書内のウォーターマークは、文書に固有のメニューオプションを明らかにすることができ、ギャップ（Ｇａｐ）ジーンズタグのバーコードは、取扱表示及びファッションのヒントにつながることが可能であり、本のカバーのアートワークの認識は、本のレビュー及び購入機会を含むメニューオプションの表示をトリガすることができ、顔の認識は、その人のフェイスブックページを見る、名前の注釈付きの写真をフリッカーに格納する、その他など、オプションを立ち上げることができる。同様に、ウォーターマーク付きのラジオ又はテレビのオーディオ／ビデオは、サンプリングされた番組についての情報の発見などにつながることが可能である。

いくつかの構成では、デジタル看板（例えば、小売店内のもの）は、ウォーターマークデータによりステガノグラフィ的符号化が行われる、視覚的（又は聴覚的）コンテンツを提示することができる。例えば、店は、あるジーンズを宣伝するビデオ提示を示すことができる。このビデオを、例えば、リモートサーバの対応するデータベースレコード内の関連情報にアクセスするために使用することができる、インデックスデータを搬送する、複数のビットペイロードにより符号化することができる。この関連情報には、他の情報の中でも、そこからビデオウォーターマークが復号された看板の場所を識別するジオロケーション座標データが含まれうる。この情報をユーザのデバイスに返し、デバイスにその場所を知らせるために使用することができる。場合によっては（例えば、デバイスが屋内である場合）、他の場所データ−ＧＰＳ衛星からのものなど−が入手可能でないことがある。それにもかかわらず、リモートサーバから返されたデータ−復号されたウォーターマーク情報に対応する−は、それにより電話が他の場所に基づいたサービス（店、ウォーターマークなどに無関係のものでさえも）を入手又は提供することができる情報を提供する。例えば、デバイスが、例えば、特定のショッピングモールに対応する地理座標（ｇｅｏｃｏｏｒｄｉｎａｔｅｓ）にあると知り、電話は、近くの商人に関係付けられたクーポン又は他の情報を（例えば、同じソフトウェアアプリケーションによって、別のソフトウェアアプリケーションによって、又は、他の方法で）提供することができる。

図２３は、画像処理に関連付けられた、「レーダー」ユーザインタフェース手がかりを描く。明るくされた赤いバー２０２（図２４Ａに図示）は、−仮想回転軸から−画像全体に渡って繰り返してスイープする。（描かれた場合では、この回転軸は画面外にある。）スイープは、ユーザに、電話の画像処理アクティビティについてのアラートを出す。各スイープは、キャプチャされたデータの新しい解析を示すことができる。

デジタルウォーターマークは典型的には、ウォーターマークペイロードが検出可能になる前に、見極められなければならない向きを有する。キャプチャされた画像の向きが、ウォーターマークの向きと大体一直線になる場合、検出が容易になる。いくつかのウォーターマークは、ウォーターマークの向きを識別するために迅速に見極められうる、向き信号を有する。

図２３Ｂの画面ショットでは、レーダートレース（ｒａｄａｒ ｔｒａｃｅ）２０２により、そのすぐ跡を追って、瞬時のゴーストパターンが現れる。このパターンは、ウォーターマークの向きと一直線に合わせられたグリッドを示す。傾いたグリッド（図２３Ｂに描かれたものなど）を見ることで、電話の向きをわずかに変えるようにユーザに促すことができるので、グリッドラインが画面の縁に平行になり−ウォーターマーキング復号を支援する。

もう１つの視覚の手がかり−これは時間的なものである−として、ボーブルは、一定の時間が経過した後、それらの空間的な係留を失い、画面の縁に流れ着いてもよい。最終的に、ボーブルは、見えない所にすべり込んでもよい（が、なお、ユーザの履歴ファイルでは使用可能となってもよい）。このような構成を図２４に示す。（他の実施形態では、ボーブルは画像特徴に空間的に関連付けられたままであり−関連付けられた視覚的特徴が視界から出るときにのみ、消える。音声では、且つ、オプションで画像では、ボーブルは、別法として、時の経過と共に適所で活気づいてもよい。）

聴覚的発見は、上記で詳述された処理と並行することができる。プロトボーブルを、検出された音に直ちに関連付け、より多くの情報が入手可能であるとき、完全なボーブルへと精緻化することができる。異なるタイプの音声ウォーターマーク復号及びフィンガープリンティング／ルックアップを使用して、曲などを識別することができる。音声認識は、進行中でありうる。ある音声は、迅速にローカルで処理され、クラウド内でより徹底的な処理を受けてもよい。ローカル処理の結果生じるボーブルは、クラウド処理が完了され、元の結果を確認した後、異なる外観（例えば、太字になる、又は、より明るく、又は、カラー対モノクロ）を呈してもよい。（視覚解析でも、−ローカル及びクラウド処理によって、又は、代わりの識別機構、例えば、ＳＩＦＴ及びバーコード読み取りによって−最初の識別が確認されるとき、同様である。）

前述のように、ユーザは、ボーブルをタップして、関連付けられた情報及びコンテキストメニューを明らかにすることができる。あるボーブルがタップされるとき、他のオブジェクトの処理が保留又は縮小されるので、ユーザが関心を示したところに処理が焦点を合わせることができる。ユーザが、表示されたメニューオプションのうち１つをタップする場合、デバイスＵＩは、選択された動作をサポートするものに変化する。

認識された曲では、コンテキストメニューは、アーティスト名、トラック名、配信者、ＣＤ名、ＣＤアートワークなどを提示する、中央ペインを含みうる。周囲は、例えば、ユーザがその音楽をアイチューンズ（ｉＴｕｎｅｓ）又はアマゾンで購入するか、又は、その曲のユーチューブ音楽ビデオを見ることができるようにする、リンクであってもよい。話された音声では、タップにより、話者の言葉の転写を表示し、且つ、友人へ送信する、フェイスブックへ投稿する、話者の発話の格納された記録を再生する、その他など、オプションを提供する、メニューを開くことができる。

音声の時間的性質のため、ユーザインタフェースは、ユーザがより以前の時間からの情報にアクセスできるようにするコントロールを含むことが望ましく−そのボーブルは、既に画面から除去されたかもしれない。１つの手法は、ユーザが、所望の音声トラックを後方へ（例えば、波形１２０ｂを右へ）スイープできるようにすることである。このアクションは、進行中の波形の表示を一時停止し（しかし、すべての情報はバッファされる）、その代わりに、音声及び関連付けられたボーブルを、格納された履歴から順次呼び戻す。所望のボーブルがそのような方法で画面にリストアされるとき、ユーザはそのボーブルを、対応する発見体験を求めて、タップすることができる。（時間領域をナビゲートするための他のデバイスを、別法として提供することができ、例えば、シャトルコントロールである。）

そのような時間的ナビゲーションを容易にするために、インタフェースは、呼び戻された波形に沿った１０秒又は６０秒毎のチックコード（ｔｉｃ ｃｏｄｅｓ）など、相対的時間情報の、又は、呼び戻されたボーブルに関連付けられたテキストのタイムスタンプ（例えば、「２：４５前」）を有する、表示を設けてもよい。

ソフトウェアのユーザインタフェースは、「後で」ボタンなどを含み、ユーザが発見情報をリアルタイムで再検討中ではなくなることを信号で送ることができる。コンサートの場にいるユーザは、例えば、このモードをアクティベートし−自分の注意が他のところに集中されるようになると認めることができる。

このコントロールは、電話に対して、発見データで表示を更新する必要がなく、データを直ちに処理する必要すらもないことを示す。代わりに、デバイスは単に、すべてのデータをクラウドへ、処理のために（単にキャプチャされた音声及び画像データだけでなく、ＧＰＳの場所、加速度計及びジャイロスコープ情報なども）転送することができる。クラウドからの結果を、完了時に、ユーザの履歴に格納することができる。後のより都合のよい時間に、ユーザは、格納されたデータを呼び戻し、注目された発見を−それらの発見は即時性の制約により処理されなかったので、おそらく、より詳細に−探究してもよい。

もう１つのユーザインタフェースの特徴は、例えば、後のアクセスのために、ボーブルがドラッグされた先でくっつく「ドック」（アップルのＯＳ Ｘオペレーティングシステムのドックに類似のもの）でありうる。ボーブルがそのような方法でドックに入れられるとき、そのボーブルに関連付けられたすべてのキーベクトルが保存される。（別法として、現在のセッションに関連付けられたすべてのキーベクトルが保存され−後の動作のためにより有用なコンテキストを提供する。）ボーブルがドックへドラッグされる場合、関連データ（ボーブル固有、又は、セッション全体）がクラウドによって処理されて、示されたオブジェクトに関するより詳細な情報が見極められるように、デバイスプリファレンスを設定することができる。

さらにもう１つのインタフェースの特徴は、ボーブルがドラッグされうる先の「ワームホール」（又は「共有」アイコン）でありうる。これは、ユーザの友人と共有するために、ボーブル、又は、関連情報（例えば、ボーブル関連キーベクトル、又は、セッションデータ全体）を投稿する。ワームホールに置かれたボーブルは、例えば、地図表示上の独特なピンとして、ユーザの友人のデバイス上にポップアップ可能である。友人がユーザに同行中であるとき、ボーブルは、友人のデバイスのカメラビュー上に、友人のデバイスによって見られるようなシーンの対応する部分上のオーバーレイとして、現れてもよい。関連情報の他の表示は、もちろん使用可能である。
ＭＡＵＩプロジェクト

マイクロソフトリサーチ（Ｍｉｃｒｏｓｏｆｔ Ｒｅｓｅａｒｃｈ）は、同社のＴｅｃｈＦｅｓｔ ２０１０イベントで、Ｍｏｂｉｌｅ Ａｓｓｉｓｔａｎｃｅ Ｕｓｉｎｇ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅプロジェクト、すなわち、ＭＡＵＩを公表した。

ＭＡＵＩ研究者、Ｃｕｅｒｖｏ他による論文の要約、ＭＡＵＩ：Ｍａｋｉｎｇ Ｓｍａｒｔｐｈｏｎｅｓ Ｌａｓｔ Ｌｏｎｇｅｒ Ｗｉｔｈ Ｃｏｄｅ Ｏｆｆｌｏａｄ、ＡＣＭ ＭｏｂｉＳｙｓ ‘１０は、ＭＡＵＩプロジェクトを以下のように紹介している。
・・この論文は、ＭＡＵＩという、インフラストラクチャへのモバイルコードの、きめの細かい、エネルギーを意識したオフロードを可能にするシステムを提示する。これらの問題への以前の手法は、プログラマサポートに大幅に依拠して、アプリケーションをパーティショニングしたか、又は、完全な処理（若しくは、フルＶＭ）移行を必要とする、きめの粗いものであった。ＭＡＵＩは、管理されたコード環境の利点を使用して、両方の世界の最良のものを提供し、すなわち、きめの細かいコードオフロードをサポートして、プログラマへの最小限の負担により、省エネルギーを最大にする。ＭＡＵＩは、ランタイムで、どの方法がリモートで実行されるべきであるかを決定し、モバイルデバイスの現在の接続性制約下で可能な最良の省エネルギーを達成する最適化エンジンによって動かされる。我々の評価においては、我々は、ＭＡＵＩが以下を可能にすることを示す。１）１桁少ないエネルギーを消費する、リソース集中的な顔認識アプリケーション、２）そのリフレッシュレートを２倍にする、レイテンシの影響を受けやすいアーケードゲームアプリケーション、及び、３）サポートされていないコンポーネントをリモートで実行することによって、スマートフォン環境の制限を回避する、音声ベースの言語翻訳アプリケーション。

ＭＡＵＩ研究者（Ｄｕｋｅ、カーネギーメロン、ＡＴ＆Ｔリサーチ（ＡＴ＆Ｔ Ｒｅｓｅａｒｃｈ）及びランカスター大学からの個人を含む）によって示された原理及び概念は、出願人の現在及び以前の研究における原理及び概念の多数をそのまま繰り返すものである。例えば、ＭＡＵＩ研究者の研究は、バッテリ制約がスマートフォンの使用における根本的な制限であるという所見−出願人の研究において繰り返し述べられた所見−によって動機付けられる。ＭＡＵＩ研究者は、認知関連アプリケーションをサブタスクに分けることを提案し、サブタスクはスマートフォン上で実行することができ、又は、実行のためにクラウドリソースに任せられてもよく、出願人もそのようにする。ＭＡＵＩ研究者は、異なるプロセッサへの異なるタスクのこの割り振りが、バッテリ寿命、接続性、その他など、動的状況によって決まる可能性があることをさらに提案し−これもまた出願人のものをそのまま繰り返している。これらの研究者はまた、最小のレイテンシのために、近くの処理センタ（「クラウドレット（ｃｌｏｕｄｌｅｔｓ）」）への依拠をも促し−ちょうど、出願人が、この理由で、無線ネットワークのエッジ上のフェムトセル処理ノードの使用を提案したことと同様である（２００９年７月１６日出願の米国特許仮出願第６１／２２６１９５号、及び、公開された出願、国際公開第２０１０／０２２１８５号パンフレット）。

ＭＡＵＩプロジェクトと、出願人の現在及び以前の研究の間の、多数の共通の目標及び原理に鑑みて、読者は、本出願人の詳述された構成に組み込まれうる特徴及び詳細について、ＭＡＵＩ研究を参照されたい。同様に、本出願人の研究からの特徴及び詳細は、ＭＡＵＩ研究者によって提案された構成に組み込まれうる。そのような統合によって、利益は各々に生ずる。

例えば、ＭＡＵＩは、マイクロソフト．ＮＥＴ共通言語ランタイム（ＣＬＲ）を用いており、それによりコードを一度書き、次いで、ローカルプロセッサ（例えば、ＡＲＭ ＣＰＵ）上、又は、リモートプロセッサ（典型的には、ｘ８６ ＣＰＵ）上で実行することができる。この構成では、ソフトウェア開発者は、アプリケーションのどのメソッドがリモート実行のためにオフロードされうるかの注釈を付ける。ランタイムで、ソルバーモジュールは、各メソッドがリモートで実行されるべきであるか、ローカルで実行されるべきであるかを、（１）エネルギー消費特性、（２）プログラム特性（例えば、実行時間及びリソースのニーズ、及び、（３）ネットワーク特性（例えば、帯域幅、レイテンシ及びパケットロス）に基づいて解析する。特に、ソルバーモジュールは、コードオフロード問題の線形プログラミング公式化を構築し、解いて、レイテンシ制約を受けて、エネルギー消費を最小にする、最適なパーティショニング戦略を発見する。

同様に、ＭＡＵＩ研究者は、出願人の研究と併せて有利に用いられうる以外に、特定のクラウドレットアーキテクチャ、及び、仮想マシン合成技術を詳述する。ＭＡＵＩ研究者はまた、クラウドレットを、各使用後にその元のソフトウェア状態に復元する、一時的カスタマイズ方法−クラウドレットインフラストラクチャの永続的なホストソフトウェア環境から短期ゲストソフトウェア環境をカプセル化し、２つの間の安定したユビキタスインタフェースを定義すること−をも詳述する。これら及び他のＭＡＵＩ技術を、出願人の技術の実施形態において直接用いることができる。

ＭＡＵＩについての追加の情報は、Ｓａｔｙａｎａｒａｙａｎａｎ他による論文、「Ｔｈｅ Ｃａｓｅ ｆｏｒ ＶＭ−ｂａｓｅｄ Ｃｌｏｕｄｌｅｔｓ ｉｎ Ｍｏｂｉｌｅ Ｃｏｍｐｕｔｉｎｇ」、ＩＥＥＥ Ｐｅｒｖａｓｉｖｅ Ｃｏｍｐｕｔｉｎｇ、Ｖｏｌ．８、Ｎｏ．４、１４〜２３ページ、２００９年１１月（参照により組み込まれた文献、米国特許仮出願第６１／３１８２１７号において付録Ａとして添付されたものであり、この出願の公報において一般の閲覧が可能となる）において見られる。また、さらなる情報は、「Ａｎ Ｅｎｇａｇｉｎｇ Ｄｉｓｃｕｓｓｉｏｎ」という名称の２０１０年３月４日にウェブに投稿された記事（米国特許仮出願第６１／３１８２１７号に付録Ｂとして添付）において見られる。当業者は、このような以前の研究に精通していると推定される。
さらに音源位置測定について

スマートフォンは、ユビキタスになるにつれて、新規な方法で協調することができる。１つは、高度な音源位置測定を行うことである。

従来技術（例えば、米国特許出願公開第２００８／００８２３２６号及び米国特許出願公開第２００５／０１１７７５４号）から知られているように、空間的に分離されたマイクロフォンからの信号を使用して、検知された音声信号における、相関性のある特徴間の時間遅延に基づいて、音声が発出する元の方向を見極めることができる。異なる個人によって携行された電話は、空間的に分離されたマイクロフォンとしての役目を果たすことができる。

音源位置測定の必要条件は、成分音声センサの位置を理解することである。ＧＰＳは、使用可能な１つの位置指定技術である。しかし、より正確な技術が現れつつあり、そのいくつかを以下に述べる。そのような技術を用いて、携帯電話の相対的場所が、１メートル未満（場合によっては、さらに１センチメートルに近い）精度内で決定されうる。

そのような位置測定技術を使用して、３つの空間次元で協調する各電話の位置を識別することができる。さらなる精緻化は、電話本体のセンサ（複数可）の場所及び向きを知ること、及び、電話の向きを知ることに由来することが可能である。前者の情報は、各電話に固有であり、ローカル又はリモートデータストレージから取得されうる。加速度計、ジャイロスコープ及び磁力計など、電話内のセンサを使用して、電話の向き情報を生成することができる。最終的に、各マイクロフォンの６Ｄ姿勢が決定されうる。

これらの電話は次いで、この情報を他の電話と共有する。これらの電話のマイクロフォンによって検知されるとき、タイムスタンプの付いた音声のデジタルストリームをブロードキャストするように、これらの電話をプログラムすることができる。（いくつかのストリームのためのデータは、いくつかのマイクロフォンを有する電話によってブロードキャストされうる。）場所情報もまた、各電話によってブロードキャストすることができ、又は、１台の電話が、以下に述べるような適切な技術を使用して、別の電話の場所を見極めてもよい。ブロードキャストは、ブルートゥース又はジグビー（Ｚｉｇｂｅｅ）又は８０２．１１など、短距離無線技術によるものでありうる。ボンジュール（Ｂｏｎｊｏｕｒ）など、サービス発見プロトコルを使用して、電話間でデータを交換することができ、又は、別のプロトコルを使用することができる。

ＭＰ３圧縮は一般に、音声圧縮のために使用されるが、その使用は、現在の状況では支持されていない。ＭＰ３などは、音声を、サンプリングウィンドウ毎に、周波数係数の連続セットとして表現する。このサンプリングウィンドウは、実際には、時間的不確実性のウィンドウである。この不確実性は、音源を位置測定することができる精度を制限する。特徴相関が時間遅延に正確に関係付けられるために、圧縮されていない音声、又は、時間情報を正確に保つ圧縮（例えば、無損失のデータ圧縮）が使用されることが好ましい。

一実施形態では、第１の電話が、１つ又は複数の第２の電話によって検知且つブロードキャストされた音声データを受信し、−それ自体のマイクロフォンによって検知されたデータと共に−音源の方向を判断する。この決定は次いで、他の電話と共有されうるので、他の電話自体で決定を行う必要はない。音源の場所は、第１の電話からのコンパスの方向として明示されうる。望ましくは、第１の電話の場所が他の電話に知られるので、第１の電話に対する音源位置測定情報を他の電話の位置に関係付けることができるようになる。

もう１つの構成では、環境内の専用デバイスが、すぐ近くのセンサからの音声ストリームを収集する役目を果たし、音源位置測定の決定を行い、その結果を、関係する電話にブロードキャストする。この機能性は、照明コントローラ、サーモスタット、その他など、他のインフラストラクチャデバイスに組み込まれうる。

音声方向を２次元で決定することは、大部分の応用例では十分である。しかし、マイクロフォン（電話）の間隔が３次元で空いている（例えば、異なる高度にある）場合、音源方向を３次元で決定することができる。

センサの間隔が、（単一の電話上の複数のマイクロフォンなど、多数の応用例で一般的であるように）数センチメートルではなく、数メートル空いている場合、音源を、その方向によってのみでなく、その距離によっても位置測定することができる。方向情報に基づいて三角測量を使用し、且つ、それら自体のそれぞれの場所が分かると、２つ以上の空間的に分離された電話は、各々から音源までの距離を決定することができる。既知の電話の場所からの距離及び方向により、音源の位置を決定することができるようになる。前述のように、センサが３次元で分散している場合、この位置情報を３次元で解決することができる。（ここでもまた、これらの計算を１台の電話によって、他の電話からのデータを使用して行うことができる。結果として生じる情報を、次いで共有することができる。）
リンクトデータ

本技術の別の態様によれば、データ及びリソースのウェブ２．０の概念（例えば、リンクトデータに関連する）が、有形のオブジェクト及び／又は関連キーベクトルデータ、並びに、関連付けられた情報と共に使用される。

リンクトデータは、Ｓｉｒ Ｔｉｍ Ｂｅｒｎｅｒｓ Ｌｅｅによって奨励された、ウェブ上で参照解除可能なＵＲＩを介してデータをエクスポーズ、共有及び接続するための構成を指す。（例えば、Ｔ．Ｂ．Ｌｅｅ、Ｌｉｎｋｅｄ Ｄａｔａ、ｗｗｗ＜ｄｏｔ＞ｗ３＜ｄｏｔ＞ｏｒｇ／ＤｅｓｉｇｎＩｓｓｕｅｓ／ＬｉｎｋｅｄＤａｔａ．ｈｔｍｌを参照。）

要するに、ＵＲＩが使用されて、有形のオブジェクト及び関連付けられたデータオブジェクトが識別される。ＨＴＴＰ ＵＲＩは、人々及びユーザエージェントによってこれらのオブジェクトを参照し、ルックアップ（「参照解除」）することができるように、使用される。ある有形のオブジェクトが参照解除されるとき、その有形のオブジェクトについての有用な情報（例えば、構造化されたメタデータ）が提供される。この有用な情報は、−他の関連情報及び有形のオブジェクトの発見を改善するために−他の関連ＵＲＩへのリンクを含むことが望ましい。

ＲＤＦ（リソース記述フレームワーク）は一般に、リソースについての情報を表現するために使用される。ＲＤＦは、リソース（例えば、有形のオブジェクト）を、主語、述語及び目的語からなる、いくつかのトリプルとして記述する。これらのトリプルは、時として、アサーションと呼ばれる。

トリプルの主語は、記述されたリソースを識別するＵＲＩである。述語は、どのような種類の関係が主語と目的語の間に存在するかを示す。述語もまた、典型的にはＵＲＩであり−特定のドメインに関する標準化された語彙から引き出されるものである。目的語は、リテラル値（例えば、名前又は形容詞）であってもよく、又は、主語に何らかの形で関係付けられる別のリソースのＵＲＩであってもよい。

異なる知識表現言語を使用して、有形のオブジェクト及び関連付けられたデータに関するオントロジーを明示することができる。ウェブオントロジー言語（ＯＷＬ）はその１つであり、ＲＤＦスキーマとの互換性を提供するセマンティックモデルを使用する。ＳＰＡＲＱＬは、ＲＤＦ表現と共に使用するためのクエリ言語であり−クエリが、連言、選言、及びオプションのパターンと共に、トリプルパターンからなることを可能にする。

本技術のこの態様によれば、モバイルデバイスによってキャプチャされ、作り出されたデータの項目には、一意及び永続的な識別子がそれぞれ割り当てられる。これらのデータには、基本のキーベクトル、セグメント化された形状、認識されたオブジェクト、これらの項目について取得された情報などが含まれる。これらのデータの各々は、クラウドベースのレジストリシステムに記録され、このレジストリシステムはまた、関連するルーティング機能をもサポートする。（データオブジェクト自体もまた、長期の格納のためにクラウドへプッシュされてもよい。）データに関する関連アサーションは、モバイルデバイスからレジストリへ提供される。したがって、ローカルデバイスに知られている各データオブジェクトは、クラウド内のデータを介してインスタンス化される。

ユーザは、画像をキャプチャしながら、カメラをスイープしてもよい。そのようなアクションを通じて集められ、処理され、及び／又は識別されたすべてのオブジェクト（及び関連データ）は、識別子が割り当てられ、クラウド内で存続する。１日又は１年後、別のユーザがそのようなオブジェクトに対して、（例えば、ある木がホワイトオークである、など）アサーションを作成することができる。カメラが特定の場所を、特定の時間に素早く見ることであっても、クラウド内で無期限にメモリアライズ（ｍｅｍｏｒｉａｌｉｚｅｄ）される。そのようなコンテンツは、この基本のクラウドベースの形式において、協調のために組織化する構成物となりうる。

データの命名は、クラウドベースのシステムによって割り当てることができる。（クラウドベースのシステムは、割り当てられた名前を発信側のモバイルデバイスに戻すようにレポートすることができる。）モバイルデバイスに知られているようなデータを識別する情報（例えば、上述のクランプＩＤ又はＵＩＤ）をクラウドベースのレジストリに提供することができ、そのデータについての別のアサーションとして、クラウド内でメモリアライズすることができる。

クラウドベースのレジストリによって維持されたデータの部分ビューには、以下が含まれうる。

このように、この態様では、モバイルデバイスは、クラウドベースのレジストリが複数のソフトウェアオブジェクト（例えばＲＤＦトリプル）を、モバイルデバイスが処理するデータの項目毎に、及び／又は、そのカメラの視野内で発見された物理的オブジェクト又は特徴毎に、インスタンス化することを可能にするデータを提供する。大変多くのアサーションを、各々について作成することができる（私はキャニーデータである、私はある場所及び時間でキャプチャされた画像に基づいている、私は、緯度Ｘ、経度／Ｙから北を見ると見える、質感の高い青いオブジェクトである、など）。

重要なことには、これらの属性を、他のデバイスによって投稿されたデータとリンクさせることができ−ユーザのデバイスによって、入手可能な画像データ及びコンテキストのみから見極めることができない、新しい情報の獲得及び発見を可能にする。

例えば、ジョンの電話は、ある形状をビルとして認識するが、その街路アドレスを見極めること、又はそのテナントを知ることができないことがある。ジェーンは、しかし、そのビルで働いていることがある。彼女の特定のコンテキスト及び履歴のため、彼女の電話がビル関連画像データに関連してレジストリに以前に提供した情報においては、そのビルの住所及びいくつかのテナントについての情報を含む、そのビルについての情報がより豊富であることがある。ジオロケーション情報及び形状情報における類似性によって、ジェーンの電話がそれについて情報を提供したビルを、ジョンの電話がそれについて情報を提供した同じビルである可能性が高いものとして識別することができる。（新しいアサーションをクラウドレジストリに追加して、ジェーンのビルのアサーションをジョンのものに明示的に関係付けることができ、逆もまた同様である。）ジョンの電話がレジストリに対して、そうするように要求した場合（且つ、関連のあるプライバシー保護手段が許可する場合）、レジストリは、ジョンの電話に、ジェーンの電話によって提供されたそのビルについてのアサーションを送信することができる。ここで作用している、根底にある機構は、仲介されたクラウドソーシングであると見なすことができ、アサーションは、参加者も同意するポリシー及びビジネスルールフレームワーク内で作成される。

関連付けられたアサーションの豊富なセットを有する場所（例えば、場所によって、且つ、オプションで時間によっても決定される）は、新しい発見体験をもたらす。モバイルデバイスは、ＧＰＳ場所及び現在時間など、単純なアサーションを、リンクトデータ又は他のデータリポジトリ内で検索又は発見体験を開始するためのエントリポイントとして、提供することができる。

また、クラウド内のアサーションのアクセス又はナビゲーションに、モバイルデバイス上のセンサによって影響を与えることができることにも留意されたい。例えば、ジョンは、ＧＰＳ又は他のセンサによって決定されるような、そのビルとの特定の近接内（例えば、１０ｍ、３０ｍ、１００ｍ、３００ｍなど）にいる場合にのみ、そのビルに関するジェーンのアサーションにリンクすることを許可されてもよい。この許可は、ジョンが静止しているか、又は、ＧＰＳ、加速度計／ジャイロスコープ若しくは他のセンサによって決定されるような歩く速度（例えば、毎分１００フィート若しくは３００フィート未満）で移動中である必要がある場合に、さらに限定されてもよい。モバイルデバイス内のセンサからのデータに基づくそのような制限は、望まれていないか、又はより関連性の少ないアサーション（例えば、広告など、スパム）を減らし、データのリモート又はドライブバイ（又はフライバイ）マイニングに対する、あるセキュリティを提供することができる。（様々な構成を用いて、ＧＰＳ又は他のセンサデータのスプーフィングと戦うことができる。）

同様に、２人の関係者が、ジオロケーション、時間、ソーシャルネットワークのつながりなどにおける近接など、ある特色を共有するときにのみ、クラウド内に格納されたアサーションがアクセスされてもよい（又は、対象についての新しいアサーションが作成されてもよい）。（後者は、ジョンが、例えば友達として、ジェーンに社会的にリンクされることを示す、フェイスブック又はリンクトインなど、ソーシャルネットワークデータストアを参照することによって、示すことができる。）ジオロケーション及び時間のそのような使用は、社会慣習に近似し、すなわち、人々の大きいグループが集まるとき、発生する自然発生的なインタラクションは価値のある可能性があり、その理由は、そのグループのメンバが共通の関心、特色などを有する高い見込みがあるからである。アサーションにアクセスし、それを投稿するための能力、及び、他者の存在に基づいて新しい発見体験を可能にすることは、このモデルの結果として生じる。

場所は、画像データのセットが関連付けられる、よくある手がかりである。他の手がかりもまた、使用することができる。

ゾウの調査員を考えられたい。知られているゾウ（例えば、自然保護区域内にいる）には、一般に名前が付けられ、顔の特徴（傷跡、しわ及びきばを含む）によって識別される。調査員のスマートフォンは、あるゾウについての顔の特徴ベクトルを大学データベースに提出してもよく、大学データベースは、顔のベクトルをゾウの名前に関連付けるために存在する。しかし、そのような顔のベクトル情報がクラウドベースのレジストリに提出されるとき、より大量の情報が明らかにされ、例えば、以前の目撃の日付及び場所、そのゾウを見たことがある他の調査員の名前などである。ここでもまた、データセット間の対応が見極められた後、さらなるアサーションをレジストリに追加することによって、この事実をメモリアライズすることができる。

モバイルデバイスのカメラ、マイクロフォン及び他のセンサによって検知された刺激についてのアサーションの、このようなクラウドベースのリポジトリは、特に他のリンクトデータシステム（そのうちの少数は、ｌｉｎｋｅｄｄａｔａ＜ｄｏｔ＞ｏｒｇに詳述されている）内の情報と関係付けられるとき、グローバルに有用な情報の莫大なストアを迅速に備えることができることは理解されよう。格納されたアサーションによって明示された理解は、部分的に、そのデバイスがそのような情報に寄与する個々のユーザのプロファイル及び履歴を反映するので、知識ベースは特に豊富である。（ウェブのグーグルのインデックスは、比較すると小さく見えることがある。）

（有形のオブジェクトの識別に関連して、潜在的に有用な語彙は、ＡＫＴ（高度知識技術（Ａｄｖａｎｃｅｄ Ｋｎｏｗｌｅｄｇｅ Ｔｅｃｈｎｏｌｏｇｉｅｓ））オントロジーである。ＡＫＴは、そのトップレベルにクラス「Ｔｈｉｎｇ（物）」を有し、その下に２つのサブクラスである「Ｔａｎｇｉｂｌｅ−Ｔｈｉｎｇ（有形物）」及び「Ｉｎｔａｎｇｉｂｌｅ−Ｔｈｉｎｇ（無形物）」がある。「Ｔａｎｇｉｂｌｅ−Ｔｈｉｎｇ」には、ソフトウェアから亜原子粒子まで、現実及び想像上のあらゆるものが含まれる（例えば、ミッキーマウス（Ｍｉｃｋｅｙ Ｍｏｕｓｅ）の車）。「Ｔａｎｇｉｂｌｅ−Ｔｈｉｎｇ」は、「Ｌｏｃａｔｉｏｎ（場所）」、「Ｇｅｏｇｒａｐｈｉｃａｌ−Ｒｅｇｉｏｎ（地理的領域）」、「Ｐｅｒｓｏｎ（人）」、「Ｔｒａｎｓｐｏｒｔａｔｉｏｎ−Ｄｅｖｉｃｅ（移動手段デバイス）」、及び、「Ｉｎｆｏｒｍａｔｉｏｎ−Ｂｅａｒｉｎｇ−Ｏｂｊｅｃｔ（情報を伝えるオブジェクト）」を含む、サブクラスを有する。この語彙を拡張して、本技術に関連して遭遇されると予期されるオブジェクトについての識別を提供することができる。）
拡張空間

本技術の１つの応用例は、夜空に関する（現実の、又は人工的な）画像上に情報を提示する機能である。

ユーザは、スマートフォンを空の特定の点に向け、画像をキャプチャすることがある。小型のハンドヘルドイメージングデバイスで星の光をキャプチャすることは困難であるため、この画像は、それ自体では画面上の提示のために使用することはできない。しかし、ジオロケーション、磁力計、加速度計及び／又はジャイロスコープデータをサンプリングして、ユーザがそこからカメラを向けた場所、及び、カメラを向けた向きを示すことができる。グーグルスカイ（Ｇｏｏｇｌｅ Ｓｋｙ）プロジェクト（グーグルアース（Ｇｏｏｇｌｅ Ｅａｒｔｈ）インタフェースを通じて使用可能）など、夜空のデータベースを調べて、キーのその部分に対応するデータを取得することができる。スマートフォンプロセッサは次いで、このデータを、例えば、グーグルサービスから直接、画面上で再生することができる。又は、スマートフォンプロセッサは、アイコン、ボーブル又は他のグラフィカルなしるしを、空の向けられた部分にある星の位置に対応する、画面上の場所にオーバーレイすることができる。ギリシャ（及び／又は、インド、中国など）の星座を示す線を、画面上に描画することができる。

星自体は、カメラによってキャプチャされた画像内では見えないことがあるが、他の局所特徴は、はっきりと見えることがある（木、家など）。星及び星座データ（アイコン、線、名前）をこの実画像の上に表示し−見える周囲に対して星がどこに位置するかを示すことができる。このようなアプリケーションはまた、例えば、ユーザが（星の位置が対応する）表示されるビューイング時間を前方又は後方に変更することを可能にするスライダコントロールにより、はっきりと見える星の弧を通じて、星を動かすことなどの提供を含むこともある。ユーザはしたがって、北極星が今晩の特定の時間に、特定の木の後ろから上ることを発見することができる。
他のコメント

本明細書は、譲受人の以前の特許出願及びＭＡＵＩプロジェクトとの関係を以前に述べたが、繰り返しを有する。これらの素材は同時に読まれ、一緒に解釈されるべきである。出願人は、各開示における特徴が他の開示における特徴と組み合わせられることを意図する。したがって、例えば、本明細書に記載された構成及び詳細を、米国特許出願第１２／２７１，７７２号及び第１２／４９０，９８０号並びにＭＡＵＩの業績に記載されたシステム及び方法の異なる実装において使用することができるが、今言及した業績の構成及び詳細を、本明細書に記載されたシステム及び方法の異なる実装において使用することができる。他の記載された文書についても同様である。したがって、本出願において開示された方法、要素及び概念は、これらの引用文献において詳述された方法、要素及び概念と組み合わせられることを理解されたい。いくつかは本明細書で特に詳述されたが、−並べ換え及び組み合わせが多数であり簡潔さの必要性のため−多くは詳述されていない。しかし、すべてのそのような組み合わせの実装は、提供された教示から、当業者には容易である。

例示的特徴及び例を参照して、我々の発明の研究の原理を記載し、例示したが、本技術はそのように限定されないことは理解されよう。

例えば、スマートフォンなど、モバイルデバイスが参照されたが、本技術は、あらゆる種類のデバイス−ポータブル及び固定の双方−での効用を見出すことは理解されよう。ＰＤＡ、オーガナイザ、ポータブル音楽プレイヤ、デスクトップコンピュータ、ラップトップコンピュータ、タブレットコンピュータ、ネットブック、ウルトラポータブル、ウェアラブルコンピュータ、サーバなどはすべて、本明細書で詳述された原理を使用することができる。特に企図されたスマートフォンには、アップルのアイフォン、及び、グーグルのアンドロイド仕様に従うスマートフォン（例えば、ＨＴＣ Ｃｏｒｐ．によってＴ−モバイル（Ｔ−Ｍｏｂｉｌｅ）用に製造されたＧ１電話、モトローラドロイド（Ｍｏｔｏｒｏｌａ Ｄｒｏｉｄ）電話、及び、グーグルネクサス（Ｇｏｏｇｌｅ Ｎｅｘｕｓ）電話）が含まれる。「スマートフォン」（又は「携帯電話」）という用語は、厳密に言えばセルラーでも電話でもないもの（例えば、アップルｉＰａｄデバイス）であっても、すべてのこのようなデバイスを包含するように解釈されるべきである。

（そのタッチインタフェースを含む、アイフォンの詳細は、アップルの米国特許出願公開第２００８／０１７４５７０号において提供されている。）

同様に、本技術をまた、拡張現実（ＡＲ）メガネなど、顔に着用する装置を使用して実装することもできる。そのようなメガネは、−ユーザの前のシーン上にオーバーレイされるか、又は、そのシーンをブロックする−コンピュータ情報をユーザによって見ることができる表示技術を含む。仮想現実ゴーグルは、そのような装置の一例である。例示的技術は、米国特許第７３９７６０７号及び米国特許出願公開第２００５／０１９５１２８号に詳述されている。市販用に提供された物には、Ｖｕｚｉｘ ｉＷｅａｒ ＶＲ９２０、Ｎａｔｕｒａｌｐｏｉｎｔ Ｔｒａｃｋｉｒ ５、及び、ｅｚＧｅａｒによるｅｚＶｉｓｉｏｎ Ｘ４ビデオグラス（Ｖｉｄｅｏ Ｇｌａｓｓｅｓ）が含まれる。来たるべき代替物は、ＡＲコンタクトレンズである。そのような技術は、例えば、米国特許出願公開第２００９０１８９８３０号、及び、Ｐａｒｖｉｚ、Ａｕｇｍｅｎｔｅｄ Ｒｅａｌｉｔｙ ｉｎ ａ Ｃｏｎｔａｃｔ Ｌｅｎｓ、ＩＥＥＥ Ｓｐｅｃｔｒｕｍ、２００９年９月において詳述されている。一部又は全部のそのようなデバイスは、例えば、無線で、（ユーザによって、又は他の方法で携行された）他のコンピューティングデバイスと通信してもよく、又は、内蔵された処理機能を含むことができる。同様に、一部又は全部のそのようなデバイスは、既存のスマートフォン及び特許文献から知られている他の機能を組み込んでもよく、これらの機能には、電子コンパス、加速度計、ジャイロスコープ、カメラ（複数可）、プロジェクタ（複数可）、ＧＰＳなどが含まれる。

さらに、レーザ式距離測定（ＬＩＤＡＲ）等の機能が電話（及び関連デバイス）において標準となり、本技術と共に用いられる。他の任意のセンサ技術、例えば触覚や嗅覚など、も同様である。

詳述された技術は、ボーブルを頻繁に参照したが、他のグラフィカルアイコン−詳述された構成では必ずしもボーブルの目的を果たすとは限らない−を、例えば、ユーザインタフェースに関連して用いることができる。

本明細書は、冗長コントロール、スコアリング構成、その他など、ユーザの画面上に配置されたボーブルを制限するための様々な構成を詳述した。いくつかの実施形態では、非プログラマブルな固定の制約（例えば、３０個のボーブル）を設けて、ウィルスベースのサービス妨害攻撃がインタフェースを無用にするまで画面をボーブルで圧倒することを防ぐようにすることは、役に立つ。

本明細書に記載されたようなボーブルは、最も一般には画像及び音声の特徴に関連付けられるが、他の目的を果たすこともできる。例えば、ボーブルは、どのタスクが現在動作中であるかをユーザに示し、他のステータス情報を提供することができる。

本技術の商用の実装が、本明細書に提示されたユーザインタフェースとは全く異なるユーザインタフェースをおそらく利用することに留意されるべきである。本文書に詳細化されている事項は、関連する技術の説明を支援する柱である（多くの場合において、それらの原理及び特徴は、それ自体で発明と確信される）。同様に、インタラクションの詳細なユーザモダリティは、例示的でしかない。すなわち、商用の実装は、おそらく他のものを利用する。

本開示で参照されたスマートフォン及び他のコンピュータデバイスの設計は、当業者によく知られている。大まかに言えば、各々は、１つ又は複数のプロセッサ（例えば、インテル〔Ｉｎｔｅｌ〕、ＡＭＤ又はＡＲＭ型のもの）と、１つ又は複数のメモリ（例えば、ＲＡＭ）と、ストレージ（例えば、ディスク又はフラッシュメモリ）と、ユーザインタフェース（例えば、キーパッド、ＴＦＴ ＬＣＤ又はＯＬＥＤ表示画面、タッチ又は他のジェスチャーセンサ、カメラ又は他の光学センサ、コンパスセンサ、３Ｄ磁力計、３軸加速度計、３軸ジャイロスコープ、マイクロフォンなどを、グラフィカルユーザインタフェースを提供するためのソフトウェア命令と共に含んでもよい）と、これらの要素の間の相互接続（例えば、バス）と、他のデバイスと通信するためのインタフェース（ＧＳＭ、ＣＤＭＡ、Ｗ−ＣＤＭＡ、ＣＤＭＡ２０００、ＴＤＭＡ、ＥＶ−ＤＯ、ＨＳＤＰＡ、ＷｉＦｉ、ＷｉＭａｘ、メッシュネットワーク、ジグビー（Ｚｉｇｂｅｅ）及び他の８０２．１５構成、若しくは、ブルートゥースなど、無線、並びに／又は、イーサネット（Ｅｔｈｅｒｎｅｔ）ローカルエリアネットワーク、Ｔ−１インターネット接続などを通じたものなど、有線であってもよい）とを含む。

より一般には、本明細書で詳述された処理及びシステムコンポーネントは、コンピューティングデバイスのための命令として実装されてもよく、これらの命令には、マイクロプロセッサ、グラフィックス処理ユニット（ｎＶｉｄｉａ Ｔｅｇｒａ ＡＰＸ ２６００など、ＧＰＵ）、デジタル信号プロセッサ（例えば、テキサスインスツルメンツ〔Ｔｅｘａｓ Ｉｎｓｔｒｕｍｅｎｔｓ〕ＴＭＳ３２０シリーズのデバイス）などを含む、様々なプログラマブルなプロセッサのための汎用プロセッサ命令が含まれる。これらの命令は、ソフトウェア、ファームウェアなどとして実装されてもよい。これらの命令はまた、様々な形式のプロセッサ回路に実装することもでき、これらのプロセッサ回路には、プログラマブルな論理デバイス、ＦＰＧＡ（例えば、Ｘｉｌｉｎｘ Ｖｉｒｔｅｘシリーズのデバイス）、ＦＰＯＡ（例えば、ＰｉｃｏＣｈｉｐブランドのデバイス）、及び、特定用途向け回路−デジタル、アナログ、及び、混合のアナログ／デジタル回路を含む−が含まれる。命令の実行を、複数のプロセッサ間で分散させることができ、及び／又は、１つのデバイス内の複数のプロセッサにわたって、若しくは、複数のデバイスのネットワークにわたって並列にすることができる。コンテンツ信号データの変換もまた、異なるプロセッサ及びメモリデバイスの間で分散されてもよい。「プロセッサ」又は「モジュール」（フーリエ変換プロセッサ、又は、ＦＦＴモジュール、その他など）への参照は、特定の形式の実装を要するのではなく、機能性を指すものと理解されたい。

詳述された機能性を実装するためのソフトウェア命令は、当業者によって、本明細書で提供された説明から容易に作り出すことができ、例えば、Ｃ、Ｃ＋＋、ビジュアルベーシック（Ｖｉｓｕａｌ Ｂａｓｉｃ）、Ｊａｖａ、パイソン（Ｐｙｔｈｏｎ）、Ｔｃｌ、パール（Ｐｅｒｌ）、スキーム（Ｓｃｈｅｍｅ）、ルビー（Ｒｕｂｙ）などで記述することができる。本技術によるモバイルデバイスは、異なる機能及び行為を行うためのソフトウェアモジュールを含むことができる。知られている人工知能システム及び技術を用いて、推論を行い、結論を出し、上述の他の決定を行うことができる。

一般に、各デバイスは、ハードウェアリソース及び汎用機能へのインタフェースを提供するオペレーティングシステムソフトウェアを含み、また、ユーザによって望まれた特定のタスクを行うために選択的に呼び出すことができるアプリケーションソフトウェアをも含む。知られているブラウザソフトウェア、通信ソフトウェア、及び、メディア処理ソフトウェアを、本明細書で詳述された使用の多数に合わせて構成することができる。ソフトウェア及びハードウェア構成データ／命令は一般に、磁気又は光ディスク、メモリカード、ＲＯＭ、その他など、有形のメディアによって搬送される１つ又は複数のデータ構造における命令として格納され、ネットワークを介してアクセスされうる。いくつかの実施形態は、埋め込みシステム−ユーザには、オペレーティングシステムソフトウェア及びアプリケーションソフトウェアの区別がつかない、専用コンピュータシステム−として実装されてもよい（例えば、基本的な携帯電話の場合に一般的であるように）。本明細書で詳述された機能性を、オペレーティングシステムソフトウェア、アプリケーションソフトウェア内で、及び／又は、埋め込みシステムソフトウェアとして実装することができる。

ソフトウェアの格納に加えて、上記で参照された様々なメモリコンポーネントを、本技術によって利用される様々な情報（例えば、コンテキスト情報、テーブル、閾値など）のためのデータストアとして使用することができる。

本技術を、様々な異なる環境で実装することができる。１つは、アンドロイドという、グーグルから入手可能なオープンソースオペレーティングシステムであり、リナックス（Ｌｉｎｕｘ）カーネル上で実行するものである。アンドロイドアプリケーションは、一般にＪａｖａで記述され、それら自体の仮想マシン内で実行する。

アプリケーションを大きいモノリシックなコードのブロックとして構築するのではなく、アンドロイドアプリケーションは典型的には、「アクティビティ」及び「サービス」の集まりとして実装され、必要に応じて選択的にロードすることができる。本技術の１つの実装では、最も基本的なアクティビティ／サービスのみがロードされる。次いで、必要に応じて、他のアクティビティ／サービスが開始される。これらのアクティビティ／サービスは、メッセージを互いに送信し、例えば、互いにウェイクアップすることができる。そのため、あるアクティビティが長円を探す場合、そのアクティビティは、見込みがある長円が探し出される場合は顔検出器アクティビティをアクティベートすることができる。

アンドロイドのアクティビティ及びサービスは（及び、アンドロイドのブロードキャストレシーバもまた）、メッセージを搬送する「インテントオブジェクト」（例えば、特定のタイプのキーベクトルを生成するなど、サービスを要求する）によってアクティベートされる。この構成物によって、ある条件が生じるまで、コードは休止状態にあることができる。顔検出器は、開始するために長円を必要とすることがある。顔検出器は、長円が発見されるまでアイドル状態であり、長円が発見される時間にアクションを開始する。

アクティビティとサービスの間で情報を共有する（例えば、以前に述べたブラックボードの役割を果たす）ため、アンドロイドは、「コンテンツプロバイダ」を利用する。これらのコンテンツプロバイダは、データを格納且つ検索し、すべてのアプリケーションにとってアクセス可能にする役目を果たす。

アンドロイドＳＤＫ及び関連文書は、ｄｅｖｅｌｏｐｅｒ＜ｄｏｔ＞ａｎｄｒｏｉｄ＜ｄｏｔ＞ｃｏｍ／ｉｎｄｅｘ．ｈｔｍｌで入手可能である。

本明細書に記載された別々の機能性を、異なるデバイス上で実装することができる。例えば、スマートフォンがリモートサービスプロバイダのサーバと通信するシステムでは、異なるタスクをあるデバイス又は他のデバイスによって排他的に行うことができ、又は、実行をデバイス間で分散させることができる。画像からのバーコード又は固有値データの抽出は、そのようなタスクの２つの例に過ぎない。したがって、特定のデバイス（例えば、スマートフォン）によって行われているような動作の記述は、限定的ではなく例示的であり、別のデバイス（例えば、リモートサーバ又はクラウド）による、又は、デバイス間で共有された動作の性能もまた、明示的に企図されることを理解されたい。（また、３つ以上のデバイスが共通して用いられてもよい。例えば、サービスプロバイダは、画像検索、オブジェクトのセグメント化、及び／又は、画像分類など、いくつかのタスクを、そのようなタスク専用のサーバに任せてもよい。）

同様に、特定のデバイス上に格納されているデータの記述もまた例示的であり、データを、ローカルデバイス、リモートデバイス、クラウド内、分散型など、どこに格納することもできる。

動作は、明確に識別可能なハードウェアによって排他的に行われる必要はない。むしろ、いくつかの動作を、他のサービス（例えば、クラウドコンピューティング）に任せることができ、これらのサービスは、またさらに一般に匿名のシステムによるそれらの実行を処理する。そのような分散システムは、大規模（例えば、世界中のコンピューティングリソースを含む）であっても、ローカル（例えば、ポータブルデバイスが、ブルートゥース通信を通じてすぐ近くのデバイスを識別し、すぐ近くのデバイスのうち１つ又は複数をあるタスク−ローカルの地理からのデータに寄与するなど−に含めるときのようなものであり、この点では、Ｂｅｒｏｓの米国特許第７２５４４０６号を参照されたい。）であってもよい。

同様に、ある機能が、あるモジュール、エージェント、処理などによって行われているように詳述されたが、他の実装では、そのような機能を、そのようなエンティティの別のものによって、又は他の方法で行う（又は完全に省く）ことができる。

時として「認識エージェント」、及び、時として「動作」が参照されるが、他の時には、「機能」、及び、時として「アプリケーション」又は「サービス」又は「モジュール」又は「タスク」又は「段階」などが参照される。異なるソフトウェア開発環境では、これらの用語は異なる個々の意味を有することがある。本明細書では、しかし、これらの用語は一般に入れ替え可能に使用される。

上述のように、多数の機能を、複数のコンポーネント段階の順次的な動作によって実装することができる。そのような機能は、多段階の（カスケードされた）分類子であると見なされてもよく、より後の段階は、より前の段階で処理された領域又は値を検討するのみである。このタイプの多数の機能では、ある段階からの出力を調べ、基準が満たされる場合にのみ、次の段階をアクティベートする、閾値又は類似の判断がある可能性がある。（先行する段階によって出力されたパラメータが１５，０００を超える値を有した場合にのみトリガした、バーコードデコーダは、このタイプの一例である。）

多数の実施形態では、様々なコンポーネントによって行われる機能、並びに、それらの入力及び出力は、（例えば、コンポーネントによって）標準化されたメタデータの形式で指定又は発行され、ディスパッチ処理によってなど、同じものを識別することができるようになる。ＸＭＬベースのＷＳＤＬ標準を、いくつかの実施形態で使用することができる。（例えば、Ｗｅｂ Ｓｅｒｖｉｃｅｓ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ （ＷＳＤＬ） Ｖｅｒｓｉｏｎ ２．０ Ｐａｒｔ １：Ｃｏｒｅ Ｌａｎｇｕａｇｅ、Ｗ３Ｃ、２００７年６月を参照。）ＷＳＤＬ−Ｓと呼ばれる、ＷＳＤＬの拡張は、他の機能の中でも、サービスの構成を容易にすることによって、再利用可能性を改善するセマンティック要素を含めるように、ＷＳＤＬを拡張する。（代替セマンティック対応規格は、サービス用オントロジーウェブ言語（Ｏｎｔｏｌｏｇｙ Ｗｅｂ Ｌａｎｇｕａｇｅ ｆｏｒ Ｓｅｒｖｉｃｅｓ：ＯＷＬ−Ｓ）である。クラウドベースサービスプロバイダと通信するために、ＸＭＬベースのシンプルオブジェクトアクセスプロトコル（ＳＯＡＰ）を−一般に、ウェブサービスプロトコルスタックの基礎層として−利用することができる。（ジーニー（Ｊｉｎｉ）、共通オブジェクト要求ブローカアーキテクチャ（Ｃｏｍｍｏｎ Ｏｂｊｅｃｔ Ｒｅｑｕｅｓｔ Ｂｒｏｋｅｒ Ａｒｃｈｉｔｅｃｔｕｒｅ）（ＣＯＲＢＡ）、表現状態転送（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ Ｓｔａｔｅ Ｔｒａｎｓｆｅｒ）（ＲＥＳＴ）、及び、マイクロソフトのウィンドウズコミュニケーションファウンデーション（Ｗｉｎｄｏｗｓ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｆｏｕｎｄａｔｉｏｎ）（ＷＣＦ）など、他のサービスベースの技術もまた適切である。）

ウェブサービスのオーケストレーションを、ウェブサービスビジネスプロセス実行言語（Ｗｅｂ Ｓｅｒｖｉｃｅ Ｂｕｓｉｎｅｓｓ Ｐｒｏｃｅｓｓ Ｅｘｅｃｕｔｉｏｎ Ｌａｎｇｕａｇｅ）２．０（ＷＳ−ＢＰＥＬ ２．０）を用いて実施することができる。コレオグラフィは、Ｗ３Ｃのウェブサービスコレオグラフィ記述言語（Ｗｅｂ Ｓｅｒｖｉｃｅ Ｃｈｏｒｅｏｇｒａｐｈｙ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ）（ＷＳ−ＣＤＬ）を用いることができる。ＪＢｏｓｓのｊＢＰＭ製品は、ＷＭ−ＢＰＥＬ ２．０及びＷＳ−ＣＤＬの双方で使用するために構成された、オープンソースプラットフォームである。アクティブエンドポインツ（Ａｃｔｉｖｅ Ｅｎｄｐｏｉｎｔｓ）は、ＷＳ−ＢＰＥＬ ２．０のためのオープンソースソリューションを、ＡｃｔｉｖｅＢＰＥＬという名で提供し、ソースフォージ（ＳｏｕｒｃｅＦｏｒｇｅ）のｐｉ４ＳＯＡは、ＷＳ−ＣＤＬのオープンソース実装である。ウェブサービスのためのセキュリティを、ＷＳセキュリティ（ＷＳ−Ｓｅｃｕｒｉｔｙ）（ＷＳＳ）通信プロトコルの使用を通じて提供することができ、その普及しているＪａｖａライブラリ実装は、アパッチ（Ａｐａｃｈｅ）のＷＳＳ４Ｊである。

本技術のある実装は、画像処理機能（ソフトウェア）の既存のライブラリを使用する。これらには、ＣＭＶｉｓｉｏｎ（Ｃａｒｎｅｇｉｅ Ｍｅｌｌｏｎ Ｕｎｉｖｅｒｓｉｔｙによる−特にカラー画像分割が得意）と、ＩｍａｇｅＪ（国立衛生研究所によって開発されたＪａｖａルーチンの自由に配布可能なパッケージであり、例えば、ｅｎ＜ｄｏｔ＞Ｗｉｋｉｐｅｄｉａ＜ｄｏｔ＞ｏｒｇ／ｗｉｋｉ／ｌｍａｇｅＪを参照）と、ＯｐｅｎＣＶ（インテルによって開発されたパッケージであり、例えば、ｅｎ＜ｄｏｔ＞Ｗｉｋｉｐｅｄｉａ＜ｄｏｔ＞ｏｒｇ／ｗｉｋｉ／ＯｐｅｎＣＶ、及び、書籍のＢｒａｄｓｋｉ、Ｌｅａｒｎｉｎｇ ＯｐｅｎＣＶ、Ｏ’Ｒｅｉｌｌｙ、２００８年を参照）が含まれる。評判の良い商用ビジョンライブラリパッケージには、コグネックス（Ｃｏｇｎｅｘ）によるビジョンプロ（Ｖｉｓｉｏｎ Ｐｒｏ）、及び、マトロックスイメージングライブラリ（Ｍａｔｒｏｘ Ｉｍａｇｉｎｇ Ｌｉｂｒａｒｙ）が含まれる。

繰り返される動作が着手されるリフレッシュレートは、コンピューティングコンテキスト（バッテリ容量、他の処理要求など）を含む、状況によって決まる。いくつかの画像処理演算は、あらゆるキャプチャされたフレームに対して着手されてもよく、又は、ほぼそうであってもよい（例えば、レンズキャップ又は他の障害物がカメラのビューをふさぐかどうかをチェックする）。他の画像処理演算は、３フレーム毎、１０フレーム毎、３０フレーム毎、１００フレーム毎などに着手されてもよい。又は、これらの動作は、時間によって、例えば、１０秒毎、０．５秒毎、まる１秒毎、３秒毎などにトリガされてもよい。又は、これらの動作は、キャプチャされたシーン内の変化などによってトリガされてもよい。異なる動作は、異なるリフレッシュレートを有することがあり−単純な動作は頻繁に繰り返され、複雑な動作はそれほどでもない。

以前に述べたように、画像データ（又は、画像データに基づくデータ）は、解析のためにクラウドに任せられてもよい。いくつかの構成では、これは、ローカルデバイス処理の代わりに（又は、あるローカルデバイス処理がなされた後）行われる。時として、しかし、そのようなデータをクラウドに渡し、クラウドで、且つ、ローカルデバイス内の双方で同時に処理することができる。クラウド処理のコストは通常小さいので、プライマリコストは、帯域幅のものでありうる。帯域幅が使用可能である場合、たとえデータがローカルでも処理される場合であっても、データをクラウドへ送信しない理由はほとんどないことがある。いくつかの場合には、ローカルデバイスが結果をより速く返すことがあり、他の場合には、クラウドがこのレースに勝つことがある。双方を同時に使用することによって、ユーザに対して、２つの応答のうち速い方を常に提供することができる。（また、上述のように、ローカル処理が停滞するか、又は見込みがなくなる場合、縮小されてもよい。その間に、クラウド処理は激しく動き続け−おそらく、ローカルデバイスが決して提供しない結果を生じることがある。）加えて、グーグルなど、クラウドサービスプロバイダは、クラウドベースのデータ処理機会へのアクセスから他の利益を収集することができ、例えば、そのデータストアがそれに関して比較的力を失った地理的環境の詳細を知る（もちろん、適切なプライバシー保護を受ける）ことができる。

時として、ローカル画像処理を一時停止し、後に再開してもよい。１つのそのような場合は、電話をかけるか、又は受ける場合であり、デバイスは、そのリソースをその通話のサービスにのみ適用することを選んでもよい。電話はまた、ユーザが電話に対して画像処理を停止するように明示的に指図することができる、ＵＩコントロールを有してもよい。いくつかのそのような場合、関連のあるデータがクラウドへ転送され、クラウドが処理を継続し、結果を電話へ返す。

ローカルの画像処理が迅速で満足の行く結果を生じず、画像の被写体がユーザにとって関心のあるものであり続ける場合（又は、ユーザがそうでないと示さない場合）、画像は、より網羅的で非常に長い解析のために、クラウドへ任せられてもよい。ブックマークなどをスマートフォンに格納して、ユーザがそのようなさらなる解析の結果を遡ってチェックし、知ることができるようにしてもよい。又は、そのようなさらなる解析がアクション可能な結論に達する場合、ユーザにアラートを出すことができる。

詳述された技術の動作に含まれた意思決定を、いくつかの異なる方法で実装することができることは理解されよう。１つは、スコアリングによるものである。異なる代替物のための関連する入力に関連付けられたパラメータが提供され、組み合わせられ、重み付けされ、例えば、多項式に従って、異なる組み合わせで合計される。最大（又は最小）スコアを有する代替物が選択され、その代替物に基づいてアクションが取られる。他の構成では、ルールベースエンジンを用いることができる。そのような構成は、条件付きルール、例えば、ＩＦ（条件（複数可））、ＴＨＥＮアクション（複数可）などを明示する、格納されたデータを参照することによって、実装される。適応モデルもまた用いることができ、適応モデルでは、ルールが、例えば、過去にあった使用のパターンに基づいて進化する。ヒューリスティックな手法もまた用いることができる。さらに他の決定処理が個々の状況に適する場合があることは、当業者には理解されよう。

場所に基づいた技術が、多数の実施形態における効果に含まれうる。ＧＰＳは、１つのそのような技術である。他のものは、一般にデバイス間で発生するような無線シグナリングに依拠する（例えば、ＷｉＦｉ、セルラー、放送テレビ）。特許公報の国際公開第０８／０７３３４７号パンフレット、米国特許出願公開第２００９／０２１３８２８号、米国特許出願公開第２００９／０２３３６２１号、米国特許出願公開第２００９／０３１３３７０号、及び米国特許出願公開第２０１０／００４５５３１号は、いくつかのデバイスが与えられると、信号自体−及び、信号を制御する不完全なデジタルクロック信号−が、そこから高度に正確な時間及び位置情報を共に取り出すことができる参照システムを、どのように形成するかを記載している。

テンプレートマッチング構成を、この技術の多数の異なる態様において使用することができる。可能性が高いユーザの意図を見極める、及び、あるコンテキストデータに基づいて、適切なシステム応答を決定するなどの応用例に加えて、テンプレートマッチングをまた、コンテンツ内の特徴（例えば、画像内の顔）を認識するなどの応用例において使用することもできる。

テンプレートデータは、クラウド内で格納され、使用を通じて精緻化されうる。テンプレートデータは、数人のユーザの間で共有されうる。本技術によるシステムは、入ってくるデータをどのように理解するか、又は、入ってくるデータに鑑みてどのように行動するかを決定することにおいて、例えば、ユーザの友達のうち数人の、複数のテンプレートを調べることができる。

コンテンツ特徴検出の特定の応用例において、テンプレートは、それにより未知の画像が異なる場所で畳み込まれて最高出力が発見される（時として、線形空間フィルタリング（Ｌｉｎｅａｒ Ｓｐａｔｉａｌ Ｆｉｌｔｅｒｉｎｇ）と呼ばれる）、マスクデータの形を取ることができる。言うまでもなく、テンプレートは、ピクセルドメイン内で動作する必要はなく、求められた特徴パターンを、周波数ドメイン、又は、ある変換（例えば、スケール、回転、色）に敏感でない他のドメイン内で定義することができる。又は、複数のテンプレートを試みることができ−各々は異なって変換される、などとなる。

ちょうど、テンプレートマッチングを本技術の多数の異なる態様において使用することができるように、センサデータに基づいて実際のユーザコンテキストを査定すること（例えば、目／口パターンは、木よりも顔で見つかる可能性がより高い）において、コンテキストに鑑みて適切な応答を決定することにおいて、その他など、確率モデリングの関連技術もそのように使用することができる。

ある実施形態では、キャプチャされた画像が、カラフルさ（ｃｏｌｏｒｆｕｌｎｅｓｓ）（例えば、色の彩度）について調べられる。これは、カメラからの赤／緑／青信号を、色が輝度から離れて表される別の表現（例えば、ＣＩＥＬＡＢ）に変換することによって、行われうる。この後者の表現では、画像を調べて、画像フレームの全部−又は、有意の空間的エリア（例えば、４０％又は９０％より多い）−の色調が著しく弱い（例えば、３０％又は５％未満の彩度）かどうかを判定することができる。この条件が満たされる場合、システムは、バーコード又はテキストなど、印刷物を見ている可能性が高いと推論することができ、そのような物に合わせて調整された認識エージェント（例えば、バーコードデコーダ、光学式文字認識処理など）をアクティベートすることができる。同様に、この色調の弱い状況は、デバイスがある他の認識技術、例えば、顔認識及びウォーターマーク復号を適用する必要がないことを、信号で送ることができる。

コントラストは、同様に適用されうるもう１つの画像メトリックである（例えば、印刷されたテキスト及びバーコードは、高コントラストである）。この場合、閾値を超えるコントラスト測定（例えば、ＲＭＳコントラスト、ウェーバーコントラストなど）は、バーコード及びテキスト関連エージェントのアクティベーションをトリガすることができ、他の認識エージェント（例えば、顔認識及びウォーターマーク復号）を、アクティベートしない方に偏らせることができる。

逆に、キャプチャされた画像の色調が強いか、又は、コントラストが低い場合、これは、バーコード及びＯＣＲエージェントを、アクティベートしないように偏らせることができ、その代わりに、顔認識及びウォーターマーク復号エージェントを、アクティベートする方に偏らせることができる。

このように、全画像メトリックは、何の異なるタイプの処理が、キャプチャされた画像に適用されるべきであるかの決定を助けることにおいて、有用な弁別手段又はフィルタでありうる。

本明細書によるシステムを実装する当業者は、関係する様々な技術に精通していると推定される。

無線技術の新生の分野は、「コグニティブ無線」と呼ばれる。そのレンズを通じて見ると、本技術の名称は「コグニティブイメージング（ｃｏｇｎｉｔｉｖｅ ｉｍａｇｉｎｇ）」となるかもしれない。コグニティブ無線からの説明を適合させると、コグニティブイメージングの分野は、「無線イメージングデバイス及び関連ネットワークが、ユーザコンテキストに応じてユーザのイメージングのニーズを検出し、且つ、イメージングサービスをそれらのニーズにとって最適な方法により無線で提供するために、セマンティック抽出及びコンピュータ間の通信をサポートして、イメージング構成物の抽出において十分コンピュータ的にインテリジェントであるポイント」であると見なすことができる。

本開示は、例示的実施形態において、行為の特定の順序付け、及び、要素の特定の組み合わせを詳述したが、他の方法は、行為の順序を変えてもよく（場合によっては、いくつかの行為を省き、他の行為を追加する）、他の組み合わせは、いくつかの要素を省き、他の要素を追加するなどしてもよいことは理解されよう。

完全なシステムとして開示されたが、詳述された構成の副次的組み合わせもまた、別々に企図される。

ある実施形態では、インターネットが参照された。他の実施形態では、他のネットワーク−複数のコンピュータのプライベートネットワークを含む−もまた用いることができ、又は代わりに用いることができる。

主として、画像キャプチャ及び処理を行うシステムに関連して詳述されたが、対応する構成は、音声又は他の刺激（例えば、接触、匂い、動き、向き、温度、湿度、気圧、微量化学物質など）をキャプチャし、処理するシステムに等しく適用可能である。いくつかの実施形態は、複数の異なるタイプの刺激に応答することができる。

音声シーンアナライザ（Ｋｕｂｏｔａ他、Ｄｅｓｉｇｎ ａｎｄ Ｉｍｐｌｅｍｅｎｔａｔｉｏｎ ｏｆ ３Ｄ Ａｕｄｉｔｏｒｙ Ｓｃｅｎｅ Ｖｉｓｕａｌｉｚｅｒ−Ｔｏｗａｒｄｓ Ａｕｄｉｔｏｒｙ Ａｗａｒｅｎｅｓｓ Ｗｉｔｈ Ｆａｃｅ Ｔｒａｃｋｉｎｇ、１０^ｔｈ ＩＥＥＥ Ｍｕｌｔｉｍｅｄｉａ Ｓｙｍｐ．、４６８〜４７６ページ、２００８年による）の態様を示す、図１８を考えられたい。Ｋｕｂｏｔａシステムは、３Ｄサウンドをマイクロフォンアレイによりキャプチャし、サウンドを位置測定且つ分離し、分離されたサウンドを音声認識技術によって認識する。Ｊａｖａ可視化ソフトウェアは、いくつかの表示を提示する。図１８の第１のボックスは、人々からの発話イベント及び背景音楽を、タイムラインに沿って示す。第２のボックスは、選択された時点のマイクロフォンアレイに対するサウンドソースの配置を示す。第３のボックスは、望まれないサウンドソースを除去するように、方向フィルタリングを可能にする。第４のボックスは、特定の話者の選択、及び、その話者の言葉の転写を可能にする。これらの表示とのユーザインタラクションは、顔追跡によって達成され、例えば、画面により近付き、所望の話者の方に向かって移動することで、ユーザがその話者の発話を選び、フィルタリングすることができる。

本技術に関連して、あるシステムは、カメラベースのシステムのための空間モデルコンポーネントに類似した構成を使用して、３Ｄ聴覚シーンの共通可視化を提供することができる。ボーブルを、位置、時間及び／又はクラスに応じて、識別された音源上に配置することができる。ユーザは、システムとのインタラクションを通じて音源をセグメント化することに携わり−ユーザがより多くの情報を望むサウンドを分離することができるようにしてもよい。例えば、背景音楽について、話者を識別する、音源を位置指定する、ジャンルで分類するなどの情報を提供することができる。既存のクラウドベースのサービス（例えば、シャザム（Ｓｈａｚａｍ）、グレースノート（Ｇｒａｃｅｎｏｔｅ）及びミドミ（Ｍｉｄｏｍｉ）からなど、ポピュラー音楽認識サービス）は、そのような構成における音声識別／分類の一部を提供するように構成されうる。

大学の講義のコンテキストでは、学生のモバイルデバイスは、教授の声、及び、すぐ近くの学生によるいくつかの偶然の副次的な会話をキャプチャすることがある。副次的な会話の色々と興味深い詳細によって気が散らされると、学生は、講義の一部を瞬間的に聞き逃してしまうことがある。電話の画面を指でスイープしながら、学生は、約１５秒前の時間（例えば、１フレームにつき５秒）の、様々な顔ボーブルを示す画面に戻る。教授に対応する顔ボーブルを認識すると、学生はその顔ボーブルをタップし、教授の声のみから転写されたテキストが次いで提示され（及び／又は、聞こえるようにされ）−学生は聞き逃したことを理解できるようになる。（見直しを速めるため、レンダリングは、スキップ又は短縮し、教授の発話中に一時停止してもよい。短縮は、ある割合、例えば５０％で行ってもよく、又は、０．５秒より長いあらゆる一時停止を０．５秒まで削ることができる。）又は、学生は単に、教授のボーブルを画面の最上部にスワイプし−その場所へのブックマークを、格納された話者の音声データに格納してもよく、学生は次いで、そのコンテンツを後に見直すことができる。

音源位置測定を行うには、２つ以上のマイクロフォンが使用されることが望ましい。グーグルによるネクサスフォンハンドセット、モトローラによるドロイドフォンハンドセット及びアップルアイフォン４は、２つのマイクロフォンを備えているが、このためではない。（これらの複数のマイクロフォンは、アクティブノイズキャンセリング構成において用いられる。）このように、これらのハンドセットは、第２の音声センサと共に、適切なソフトウェアの使用を通じて、音源位置指定（並びに音源認識）を行うように構成されうる。（各々における第２の音声センサは、マイクロメカニカルＭＥＭｓマイクロフォンである。このようなデバイスは、電話のハンドセットにおいてますます一般的になりつつある。例示的マルチマイクロフォン音源位置指定システムは、公報の米国特許出願公開第２００８／００８２３２６号及び米国特許出願公開第２００５／０１１７７５４号で詳述されている）。

音源認識についての追加の情報は、例えば、Ｍａｒｔｉｎ、Ｓｏｕｎｄ Ｓｏｕｒｃｅ Ｒｅｃｏｇｎｉｔｉｏｎ： Ａ Ｔｈｅｏｒｙ ａｎｄ Ｃｏｍｐｕｔａｔｉｏｎａｌ Ｍｏｄｅｌ、ＰｈＤ Ｔｈｅｓｉｓ、ＭＩＴ、１９９９年６月において見られる。音源位置指定についての追加の情報は、例えば、公報の米国特許出願公開第２００４／０２４０６８０号及び米国特許出願公開第２００８／０１８１４３０号において見られる。このような技術を、ある実施形態では、顔認識及び／又は音声認識技術と組み合わせることができる。

例えば、音楽及び他の音声からのスピーチを識別する追加の情報が、米国特許６，４２４、９３８及びＰＣＴ特許出願公開ＷＯ０８１４３５６９（特徴抽出に基づく）において詳述されている。

詳述された実施形態は、比較的汎用であるように記載されるが、他の実施形態は、特定の目的又は知識領域を満たすように特化されてもよい。例えば、１つのそのようなシステムは、鳥及びそれらの鳴き声を識別するように、且つ、鳥の目撃のクラウドソースによるデータベースを更新するようになど、特に巧みに作られた画像及びサウンド認識エージェントのスィートにより、バードウオッチャーに合わせて調整されてもよい。もう１つのシステムは、多様であるが特化された機能性の集まりを提供してもよい。例えば、あるデバイスは、印刷されたデジタルウォーターマークを読み取るためのディジマーク（Ｄｉｇｉｍａｒｃ）により提供された認識エージェント、バーコードを読み取るためのリンクミーモバイル（ＬｉｎｋＭｅ Ｍｏｂｉｌｅ）認識エージェント、パッケージングから認証マーキングを復号するためのＡｌｐＶｉｓｉｏｎ認識エージェント、曲を識別するためのシャザム又はグレースノート（Ｇｒａｃｅｎｏｔｅ）音楽認識エージェント、テレビ放送を認識するためのニールセン（Ｎｉｅｌｓｅｎ）認識エージェント、ラジオ放送を識別するためのアービトロン（Ａｒｂｉｔｒｏｎ）認識エージェント、等々を含んでもよい。（認識されたメディアコンテンツに関連して、このようなシステムはまた、米国特許出願第１２／２７１，７７２号（米国特許出願公開第２０１０／０１１９２０８号）及び第１２／４９０，９８０号に詳述されたものなど、他の機能性を提供することもできる。）

詳述された技術は、ＹｏｕＴｕｂｅ＜ｄｏｔ＞ｃｏｍから取得されたユーザ生成コンテンツ（ＵＧＣ）など、ウェブから取得されたビデオデータと共に使用することができる。本明細書で詳述されたもののような構成によって、ビデオのコンテンツを見極めることができるので、適切な広告／コンテンツの組み合わせを決定することができ、ユーザの体験の他の強化を提供することができる。特に、出願人は、本明細書で開示された技術を使用して、米国特許出願公開第２００８／０２０８８４９号及び第２００８／０２２８７３３号（ディジマーク）、米国特許出願公開第２００８／０１６５９６０号（ＴａｇＳｔｏｒｙ）、米国特許出願公開第２００８／０１６２２２８号（Ｔｒｉｖｉｄ）、米国特許出願公開第２００８／０１７８３０２号及び第２００８／００５９２１１号（Ａｔｔｒｉｂｕｔｏｒ）、米国特許出願公開第２００８／０１０９３６９号（グーグル）、米国特許出願公開第２００８／０２４９９６１号（ニールセン）、並びに、米国特許出願公開第２００８／０２０９５０２号（ＭｏｖｉｅＬａｂｓ）に詳述されたＵＧＣ関連システムを強化し、拡張することができることを企図する。

詳述されたコンテンツ信号（例えば、画像信号、音声信号など）の処理には、これらの信号を様々な物理的形式で変換することが含まれることは理解されよう。画像及びビデオ（物理的空間中を移動し、物理的オブジェクトを描く電磁波の形式）は、カメラ又は他のキャプチャ機器を使用して物理的オブジェクトからキャプチャされてもよく、又は、コンピューティングデバイスによって生成されてもよい。同様に、物理的媒体中を移動する音圧波は、音声トランスデューサ（例えば、マイクロフォン）を使用してキャプチャされ、電子信号（デジタル又はアナログ形式）に変換されてもよい。これらの信号は典型的には、上記のコンポーネント及び処理を実装するために、電子及びデジタル形式で処理されるが、電子、光学、磁気及び電磁波形式を含む、他の物理的形式で、キャプチャ、処理、転送且つ格納されてもよい。コンテンツ信号は、処理中に様々な方法で、様々な目的のために変換され、信号及び関連情報の様々なデータ構造表現が作り出される。さらに、メモリ内のデータ構造信号が、探索、ソート、読み取り、書き込み及び検索中の操作のために変換される。これらの信号はまた、ディスプレイ又は音声トランスデューサ（例えば、スピーカ）を介したキャプチャ、転送、格納及び出力のために変換される。

読者は、類似又は同一のコンポーネント、処理などを指すとき、時として異なる用語が使用されることに留意されたい。これは部分的には、経時的な、数名の関与による本技術の開発のためである。

本明細書で開示された異なる実施形態内の要素及び教示はまた、交換され、組み合わせられるものでもある。

ＦＦＴへの参照はまた、逆ＦＦＴ及び関連する変換（例えば、ＤＦＴ、ＤＣＴ、それぞれの逆変換など）をも含むように理解されたい。

ＳＩＦＴが参照されており、ＳＩＦＴは、参照により組み込まれた文書の一定のものにおいて詳述されるように、スケール不変の特徴に基づいて、パターンマッチング動作を行うものである。ＳＩＦＴデータは、それによりオブジェクトを認識することができるフィンガープリントとしての機能を本質的に果たす。

同様に、ブラックボード（又は他の共有データ構造）に投稿されたデータもまた、フィンガープリントとしての機能を果たすことができ−画像又はシーンを特徴付ける視覚的に有意な情報を備え、それにより画像又はシーンが認識されうる。ビデオシーケンスでも同様であり、ユーザデバイスが検知中である刺激について、時間的及び経験的なデータの集まりからなるブラックボードを生じることができる。又は、そのような場合のブラックボードデータをさらに抜き出すことができ、この抜き出しは、フィンガープリンティングアルゴリズムをそのデータに適用し、一般に一意の識別データのセットを生成することによって行い、それにより最近キャプチャされた刺激が識別され、且つ他のパターンの刺激とマッチングされうる。（ピカソは、時間的、空間的に乱雑な画像要素のセットが、シーンに関連のある知識をもたらし、それによりシーンの本質が理解されうることを、ずっと以前に予見した。）

上述のように、人工知能技術は、本技術の実施形態において重要な役割を果たすことができる。最近この分野に参入したのは、ウォルフラムリサーチ（Ｗｏｌｆｒａｍ Ｒｅｓｅａｒｃｈ）によるアルファ（Ａｌｐｈａ）製品である。アルファは、キュレートされたデータの知識ベースを参照することによって、構造化入力に応答して、回答及び可視化を計算する。本明細書で詳述された構成から収集された情報をウォルフラムアルファ製品に提示して、応答情報をユーザへ戻すように提供することができる。いくつかの実施形態では、システムによって収集された用語及び他のプリミティブからクエリを構築することによって、システムによって構成された異なるクエリのメニューの中から選択することによって、その他によってなどして、ユーザがこの情報の提出に関与する。他の構成では、これはシステムによって扱われる。加えて、又は別法として、アルファシステムからの応答情報を、グーグルなど、他のシステムへの入力として提供して、さらなる応答情報を識別することができる。ウォルフラムの米国特許出願公開第２００８／００６６０５２号及び第２００８／０２５０３４７号は、アルファ技術の態様をさらに詳述しており、この技術は現在、アイフォンアプリケーションとして使用可能である。

もう１つの補助的な技術は、グーグルボイス（Ｇｏｏｇｌｅ Ｖｏｉｃｅ）であり、従来の電話システムにいくつかの改良を提供するものである。そのような機能を、本技術と共に使用することができる。

例えば、グーグルボイスによって提供された音声−テキスト転写サービスを用いて、ユーザのスマートフォンのマイクロフォンを使用しながら、話者の環境から周囲の音声をキャプチャし、対応するデジタルデータ（例えば、ＡＳＣＩＩ情報）を生成することができる。このシステムは、そのようなデータを、グーグル又はウォルフラムアルファなどのサービスに提出して、関連情報を取得することができ、その関連情報をシステムが次いで−画面表示によって、又は音声によって（例えば、既知のテキスト−音声システムによって）、又は他の方法で−ユーザへ戻すように提供することができる。同様に、グーグルボイスによってもたらされた音声認識を使用して、会話ユーザインタフェースをスマートフォンデバイスに提供することができ、それにより、本明細書で詳述された技術の機能を発話によって選択的に呼び出し、制御することができる。

別の態様では、ユーザがコンテンツ（音声又は視覚）をスマートフォンデバイスでキャプチャし、ここで開示される技術を用いるシステムが応答を返すとき、その応答情報をテキストから音声に変換し、ユーザへ、例えば、グーグルボイスのユーザのボイスメールアカウントへ配信することができる。ユーザは、このデータリポジトリに任意の電話から、又は、任意のコンピュータからアクセスすることができる。格納されたボイスメールを、その可聴形式で見直すことができ、又は、ユーザはその代わりに、例えば、スマートフォン又はコンピュータ画面上に提示された、テキスト対応物を見直すことを選択することができる。

（グーグルボイス技術の態様は、米国特許出願公開第２００８／０２５９９１８号に詳述されている。）

音声情報は、時として、視覚情報の理解を支援することができる。異なる環境は、異なるサウンド現象によって特徴付けられ、この現象が、その環境についての手がかりとしての機能を果たすことができる。タイヤノイズ及びエンジン音は、車内又は路傍の環境を特徴付けてもよい。暖房、換気及び空調の送風機のブーンとうなる音、又はキーボード音は、職場環境を特徴付けてもよい。鳥、及び、木に吹く風の雑音は、屋外を知らせてもよい。帯域制限され、コンパンダにより処理された、めったに静かにならない音声は、テレビがすぐ近くでついていること−おそらく、家の中−を示唆してもよい。砕ける波が繰り返される音は、海辺の場所を示唆する。

そのような音声の場所の手がかりは、視覚画像処理に関連して様々な役割を果たすことができる。例えば、そのような手がかりは、視覚的環境内でオブジェクトを識別する助けとなることができる。職場のような音の存在下でキャプチャされる場合、見たところ円筒形のオブジェクトを描く画像は、木の幹よりもコーヒーマグ又は水のボトルである可能性がより高い。海辺の音声環境内の丸みのあるオブジェクトは、タイヤである場合があるが、貝殻である可能性がより高い。

そのような情報の利用は、無数の形式を取ることができる。１つの特定の実装は、認識されうる個々のオブジェクトと異なる（音声）場所の間の関連付けを確立しようとする。制限された音声の場所のセットが識別されてもよく、例えば、屋内若しくは屋外、又は、海辺／車／職場／家／不確定である。異なるオブジェクトに、次いで、そのような環境内で発見される相対的な見込みを（例えば、０〜１０の範囲で）示すスコアを、与えることができる。そのような曖昧性除去データを、インターネット（クラウド）上の公的にアクセス可能なデータベースなど、データ構造内で保持することができる。これは、屋内／屋外の場合の簡単な例である。

（屋内及び屋外スコアは必ずしも逆相関であるとは限らず、いくつかのオブジェクトは、ある程度、双方の環境内で発見される可能性が高い場合があることに留意されたい。）

円筒形のように見えるオブジェクトが画像フレーム内で見極められ、−使用可能な画像解析からは−そのオブジェクトが木の幹であるか水のボトルであるかについて曖昧である場合、曖昧性除去データ、及び、聴覚環境についての情報を参照することができる。聴覚環境が「屋外」の属性を有する（及び／又は、「屋内」である属性が不足している）場合、候補オブジェクト「木」及び「水のボトル」の屋外曖昧性除去スコアがチェックされる。「木」の屋外スコアは１０であり、「水のボトル」の屋外スコアは８であるので、この五分五分の見込みは、「木」の方を選ぶように決定される。

聴覚環境の認識を、本明細書の他のところで記載された画像解析構成の音声対応物である技術及び解析を使用して、行うことができる。又は、他の技術を使用することができる。しかし、聴覚環境の認識は不確実であることが多い。この不確実性を、曖昧性除去スコアの使用の要素に入れることができる。

直前に挙げた例では、環境からキャプチャされた音声は、屋内環境に関連付けられたいくつかの特徴、及び、屋外環境に関連付けられたいくつかの特徴を有することがある。音声解析は、したがって、例えば、６０％の可能性で屋外であり、４０％の可能性で屋内である、というファジーな結果に終わることがある。（これらの割合は、合計して１００％になってもよいが、その必要はなく、場合によっては、これらの割合は合計してより多く又はより少なくなってもよい。）これらの査定を使用して、オブジェクト曖昧性除去スコアの査定に影響を与えることができる。

多数のそのような手法があるが、１つは、以下の表によって示されるものなど、単純な乗算によって、候補オブジェクトのオブジェクト曖昧性除去スコアに、音声環境の不確実性により重み付けすることである。

この場合、たとえ聴覚環境が高度の確実性で知られていないとしても、曖昧性除去データは、オブジェクトの識別において有用である。

直前に挙げた例では、視覚解析−のみで−は、等しい確率を有する２つの候補識別、すなわち、木である可能性があること、水のボトルである可能性があることを示唆した。視覚解析は、あるオブジェクトに対していくつかの異なる可能な識別−あるものが他のものより、ありそうである−を決定するようになることが多い。最もありそうな識別が、最終的な識別として使用されてもよい。しかし、本明細書で示された概念は、そのような識別を精緻化する助けとなることができ−時として、異なる最終結果につながる。

描かれたオブジェクトが４０％の可能性で水のボトルであり、３０％の可能性で木であるという結論を（例えば、円筒形の形状の視覚的な質感の不足に基づいて）出す、視覚解析を考えられたい。この査定を、−視覚解析のみによって決定されたオブジェクト確率によるさらなる乗算によって−上述の計算と共にカスケードすることができる。

この場合、−たとえ、画像解析のみでは、その形状は水のボトルである可能性が最も高いという結論を出したとしても−オブジェクトは木として識別されうる（１．８が最高スコア）。

これらの例は、作用中の原理を例示するために、やや極度に単純化されたものであり、実際の実施では、より複雑な数学及び論理演算が確かに使用されるであろう。

これらの例は、２つの代替オブジェクト識別を簡単に示したが、実際の実装では、多数の可能な代替物の分野からの１つのタイプのオブジェクトの識別を同様に行うことができる。

曖昧性除去データの編集、例えば、異なるオブジェクトを異なる環境に関連付けることについては、何もまだ言われていない。これは大きな仕事になりうるが、いくつかの代替手法がある。

ユーチューブなどのビデオコンテンツサイト、及び、フリッカーなどの画像コンテンツサイトを考えられたい。サーバは、静止及びビデオ画像ファイルをそのようなソースからダウンロードし、知られている画像解析技術を適用して、−たとえ多数のオブジェクトが認識されないままでありうるとしても−各々内で示されたあるオブジェクトを識別することができる。各ファイルをさらに解析して、オブジェクトが見つかる環境のタイプ（例えば、屋内／屋外、海辺／職場／その他）を視覚的に推測することができる。たとえわずかな割合のビデオ／画像のみが有用な情報を与える（例えば、ある屋内ビデオでベッド及び机を識別する、ある屋外写真で花を識別する、など）場合でさえ、且つ、たとえ解析のいくつかが不正確である場合でさえ、全体で、情報の統計的に有用な選択をそのような方法で生成することができる。

直前に論じた構成では、視覚情報のみを参照することによって、環境が分類されうることに留意されたい。壁は屋内環境を示し、木は屋外環境を示す、などとなる。音は、データマイニングの一部を形成してもよいが、これは必須ではない。他の実施形態では、類似の構成は、別法として−又は加えて−コンテンツ及び環境特徴付けのために音解析を用いることができる。

ユーチューブ、フリッカー及び他のコンテンツサイトはまた、記述メタデータ（例えば、キーワード、ジオロケーション情報など）をも含み、記述メタデータもまた、描かれた画像についての情報を求めて、又は、描かれたオブジェクトの認識を他の方法で支援する（例えば、複数の可能なオブジェクト識別の間で決定する）ために、マイニングすることができる。国際出願ＰＣＴ／ＵＳ０９／５４３５８（ＰＣＴ特許出願公開ＷＯ２０１０／０２２１８５号）を含む、以前に参照された文書は、様々なそのような構成を詳述している。

音声情報を使用して、どのタイプのさらなる画像処理演算が着手されるべきであるか（すなわち、動作のルーチンのセットを超えて）を決定する助けとすることもできる。音声が職場環境を示唆する場合、これは、テキストＯＣＲ関連動作が関連するかもしれないことを示唆してもよい。デバイスはしたがって、そのような動作に着手してもよいのに対して、別の音声環境内（例えば、屋外）の場合、デバイスはそのような動作に着手していなくてもよい。

オブジェクトとそれらの典型的環境の間の追加の関連付けが、百科事典（例えば、ウィキペディア）及び他のテキストの自然言語処理によって収集されてもよい。他のところで上述したように、米国特許第７３８３１６９号は、辞書及び他の大きい言語の著作物を、世界についてのそのような「常識」情報の厖大なソースとしての機能を果たす語彙知識ベースを編集するために、ＮＬＰ技術によってどのように処理することができるかについて記載している。そのような技術によって、あるシステムは、例えば、対象「キノコ」を環境「森」（及び／又は「スーパーマーケット」）に、「ヒトデ」を「海」に、などと関連付けることができる。もう１つのリソースは、Ｃｙｃであり−常識知識の大型のオントロジー及び知識ベースをまとめている人工知能プロジェクトである（ＯｐｅｎＣｙｃは、オープンソースライセンスで入手可能である。）

環境曖昧性除去データの編集はまた、人間の関与を利用することもできる。ビデオ及び画像を、アマゾンのメカニカルタークサービスの使用を通じてなど、査定のために見る者に提示することができる。特に発展途上国では、多くの人々は、報酬を求めて画像の主観解析を進んで提供し、例えば、描かれたオブジェクト、及び、それらのオブジェクトが見られる環境を識別する。

同じ技術を用いて、異なる音を異なる環境に関連付けることができる（ケロケロ鳴くカエルを池に、航空機エンジンを空港に、など）。音声認識−グーグルボイス、ドラゴンナチュラリースピーキング（Ｄｒａｇｏｎ Ｎａｔｕｒａｌｌｙ Ｓｐｅａｋｉｎｇ）、ビアボイス（ＶｉａＶｏｉｃｅ）など（メカニカルタークを含む）によって行われるものなど−もまた、環境又は環境の属性を認識するために用いることができる。（「背もたれ及びトレイを、直立の固定の位置に戻してください．．．」は、飛行機の環境を示す。）

直前に詳述された特定の構成は、代替オブジェクト識別の曖昧性を除去するために、音声情報を使用したが、音声情報を、画像解析に関連して多数の他の異なる方法で使用することができる。例えば、異なる環境内で異なるオブジェクトに遭遇する、スコア化された見込みを識別するデータ構造ではなく、音声が、単にＳＩＦＴ特徴のいくつかの異なる用語集のうち１つを選択する（又は、用語集をまとめる）ために使用されてもよい（ＳＩＦＴについては、他のところで論じる）。音声が海辺の雑音を含む場合、オブジェクト用語集は、海辺のそばで発見されるオブジェクト（ホッチキスではなく、貝殻）についてのＳＩＦＴ特徴のみを含むことができる。画像解析システムによって探される多数の候補オブジェクトは、このように、聴覚刺激に従って制約されてもよい。

音声情報をこのように、−個々の応用例の要件に応じて−画像解析を支援するために、非常に多数の方法で用いることができ、前述はごくわずかである。

聴覚刺激が画像の解析／理解に情報を与える助けとなりうることと全く同様に、視覚刺激は、音声の解析／理解に情報を与える助けとなりうる。カメラが明るい太陽の光を検知する場合、これは屋外環境を示唆し、キャプチャされた音声の解析はしたがって、屋外に対応する参照データのライブラリを参照して進行してもよい。カメラが、蛍光灯の特性である色スペクトルを有する、規則的に明滅する照明を検知する場合、屋内環境が仮定されてもよい。最上部全体が青く、質感の高い特徴が下方にある画像フレームがキャプチャされる場合、屋外コンテキストが仮定されてもよい。これらの状況でキャプチャされた音声の解析は、そのような情報を使用することができる。例えば、低レベルの背景雑音は、暖房、換気及び空調の送風機ではなく−風である可能性が高く、大きいクリック音はキーボードの雑音ではなく、猛り狂うリスである可能性がより高い。

ユーチューブ及びフリッカーが画像情報のためのソースを提供することと全く同様に、音声情報のための多数の自由に使用可能なソースがインターネット上にある。１つは、これもまたユーチューブである。それらの小売用に提供された物に対応する、無料の、忠実度の低い物を提供する、音響効果のオンラインライブラリもある（例えば、ｓｏｕｎｄｅｆｆｅｃｔ＜ｄｏｔ＞ｃｏｍ、ｓｏｕｎｄｄｏｇ＜ｄｏｔ＞ｃｏｍ、ｓｏｕｎｄｓｎａｐ＜ｄｏｔ＞ｃｏｍなど）。これらは一般に、よく整理された分類法で提示され、例えば、Ｎａｔｕｒｅ（自然）：Ｏｃｅａｎ（海）：ＳｕｒｆＧｕｌｌｓＡｎｄＳｈｉｐＨｏｒｎ（打ち寄せる波カモメ及び船の警笛）、Ｗｅａｔｈｅｒ（天候）：Ｒａｉｎ（雨）：ＨａｒｄＲａｉｎＯｎＣｏｎｃｒｅｔｅＩｎＴｈｅＣｉｔｙ（都市のコンクリートに降る土砂降り）、Ｔｒａｎｓｐｏｒｔａｔｉｏｎ（移動手段）：Ｔｒａｉｎ（列車）：ＣｒｏｗｄｅｄＴｒａｉｎＩｎｔｅｒｉｏｒ（満員の列車内）などである。記述テキストデータをマイニングして、関連付けられた環境を決定することができる。

前述の考察は、聴覚刺激と視覚刺激の間の相互作用に焦点を合わせたが、本技術によるデバイス及び方法は、温度、場所、磁場、匂い、微量化学物質検知など、あらゆる種類の刺激及び検知されたデータと共に、そのような原理を用いることができる。

磁場については、スマートフォンは、例えば、電子コンパスの目的で、ますます磁力計を備えつつあることは理解されよう。そのようなデバイスは極めて高感度であり−その理由は、かすかな地球磁場（例えば、３０〜６０マイクロテスラ、０．３〜０．６ガウス）に応答する必要があるからである。変調された磁場のエミッタを使用して、電話の磁力計に信号を送り、例えば、情報を電話に通信することができる。

アップルのアイフォン３Ｇは、３軸ホール効果磁力計（旭化成によって製造されたと考えられる）を有し、この磁力計は、ソリッドステート回路を使用して、印加された磁場及び極性に比例した電圧を生じさせる。現在のデバイスは、高速データ通信用に最適化されていないが、将来の実装は、そのような機能を優先させることができる。それにもかかわらず、有用なデータレートを容易に達成することができる。音声及び視覚入力とは異なり、電話は、磁気入力の受信を最適化するために、特定の方向に向けられる必要はない（３Ｄセンサのため）。電話はまた、ユーザのポケット又はハンドバッグから取り出される必要すらもない。

１つの構成では、小売店は、時変信号により駆動される、隠された電磁石を含む、視覚的なプロモーションディスプレイを有してもよい。この時変信号は、データをすぐ近くの電話に送信する役目を果たす。このデータは、任意のタイプであってもよい。このデータは、例えば、プロモーション対象品目から１ドル値引きされる、受信者が使用可能なクーポンを提示する、磁力計駆動型スマートフォンアプリケーションに、情報を提供することができる。

磁場データは単に、電話に対して、異なる通信媒体を通じて送信された関連情報の可用性のアラートを出してもよい。初歩的なアプリケーションでは、磁場データは単に、モバイルデバイスに信号を送り、指定された入力コンポーネント、例えば、ブルートゥース、ＮＦＣ、ＷｉＦｉ、赤外線、カメラ、マイクロフォンなどをオンにすることができる。磁場データはまた、キー、チャネル、又は、その媒体で有用な他の情報を提供することもできる。

もう１つの構成では、異なる製品（又は、異なる製品に関連付けられた、棚に取り付けられたデバイス）は、異なる磁気データ信号を出すことができる。ユーザは、スマートフォンを特定の製品に近付けることによって、競合する伝送の中から選択する。磁場は、エミッタからの距離に指数関数的に比例して低下するので、電話は、最強（最も近い）信号を他の信号とは区別することが可能である。

さらにもう１つの構成では、棚に取り付けられたエミッタは通常アクティブではないが、ユーザ又はユーザの意図を検知することに応答して、アクティブになる。エミッタは、ボタン又は動きセンサを含んでもよく、ボタン又は動きセンサが磁気エミッタを５〜１５秒間アクティベートする。又は、エミッタは、照明の変化（より明るいか、又はより暗い）に応答するフォトセルを含んでもよい。ユーザは、電話の明るくされた画面をフォトセルに提示し（又は、手でフォトセルを影にし）、磁気エミッタに５秒のブロードキャストを開始させてもよい。その他もある。

アクティベートされた後、磁場を利用して、例えば、カメラ、ＮＦＣ又はマイクロフォンなど、使用されるために位置決め又は向けられる必要のある他のセンサをどのように利用するかについて、ユーザに知らせることができる。固有の方向性、及び、距離に対する感度により、磁場データは、ターゲットの方向及び距離を確立する（例えば、カメラを向けて焦点を合わせる）際に有用になる。例えば、エミッタは、あるパッケージを既知の場所（例えば、原点）に有する座標系を作成し、モバイルデバイスのためのグランドトゥルースデータを提供することができる。これを（一般に現在の）モバイルデバイス加速度計／ジャイロスコープと組み合わせることで、正確な姿勢評価が可能となる。

バーコード又は他のマシン可読データを製品から読み取り、それに基づいて応答をトリガするための様々なアプリケーションが、スマートフォン用に入手可能にされている（且つ、例えば、米国特許出願公開第２００１／００１１２３３号、第２００１／００４４８２４号、第２００２／００８０３９６号、第２００２／０１０２９６６号、米国特許第６３１１２１４号、第６４４８９７９号、第６４９１２１７号及び第６６３６２４９号から知られている）。同じ構成を、スマートフォンの磁力計を使用して、磁気的に検知された情報を使用して実施することができる。

他の実施形態では、磁場は、微小方向（ｍｉｃｒｏ−ｄｉｒｅｃｔｉｏｎｓ）の提供に関連して使用されてもよい。例えば、店内で、エミッタからの磁気信号は、微小方向をモバイルデバイスユーザに伝えることができ、例えば、「通路７へ行く、左側で製品Ｘを探す、Ｙドルで現在特売中、この品目のピクチャを最初にキャプチャした３名までに２ドルの追加値引きあり」（又は、関連プロモーションディスプレイの）。

関連アプリケーションは、店内の個々の製品への方向を提供する。ユーザは、所望の製品の名前をキー入力し、又は話し、それらの名前は、様々なシグナリング技術の任意のものを使用して、店のコンピュータへ送信される。コンピュータは、店内の所望の製品の場所を識別し、ユーザを案内するために方向データを定式化する。これらの方向は、磁気的に、又は他の方法でモバイルデバイスに伝えられてもよい。磁気エミッタ、又は、いくつかのエミッタのネットワークは、ユーザを所望の製品へと案内する助けとなる。

例えば、所望の製品のエミッタは、ホーミングビーコンとしての機能を果たすことができる。各エミッタは、各々が製品識別子を含むフレーム又はパケットでデータを送信してもよい。ユーザに提供された最初の方向（例えば、左へ行き、通路７を発見し、次いで、半分ほど行った右側）はまた、ユーザによって望まれた製品のための店の製品識別子を提供することもできる。ユーザのモバイルデバイスは、これらの識別子を使用して、所望の製品からの磁気放射に「合わせる」ことができる。コンパス又は他のそのようなＵＩは、ユーザがそれらの方向によって示された全体のエリア内で製品の正確な場所を発見する助けとなることができる。ユーザが所望の各製品を発見するとき、モバイルデバイスはもはや、その製品に対応する放射に合わせなくてもよい。

店内の通路及び他の場所は、それら自体のそれぞれの磁気エミッタを有してもよい。ユーザに提供された方向は、自動ナビゲーションシステムによって普及した「ターンバイターン」型にすることができる。（そのようなナビゲーション技術を、他の実施形態でも用いることができる。）モバイルデバイスは、そのルートに沿った様々な中間地点からのエミッタを検知することによって、それらの方向のユーザの進行を追跡し、次のステップ（複数可）について、ユーザに促すことができる。さらに、エミッタは、ブルートゥース又は他のシグナリングによってなど、モバイルデバイスの近接を検知し、信号で送るデータをユーザ及びユーザの位置に合わせて適合させてもよい。

複数のユーザにサービスするため、複数のエミッタ（例えば、製品識別エミッタではなく、ナビゲーションエミッタ）のあるネットワークからの伝送を時分割多重化し、データをパケット又はフレームで送信することができ、その各々は、所期の受信者を示す識別子を含む。この識別子を、方向の要求に応答してユーザに提供することができ、ユーザのデバイスが、そのデバイスを対象とした伝送を他の伝送とは区別することを可能にする。

そのようなエミッタからのデータをまた、周波数分割多重化し、例えば、あるアプリケーションのための高周波データ信号、及び、別のアプリケーションのための低周波データ信号を出すこともできる。

磁気信号を、任意の知られている構成を使用して変調することができ、これらの構成には、限定されないが、周波数、振幅、最小又は位相シフトキーイング、直交振幅変調、連続位相変調、パルス位置変調、トレリス変調、チャープ又は直接シーケンススペクトル拡散などが含まれる。異なる順方向誤り訂正コーディング方式（例えば、ターボ、リードソロモン、ＢＣＨ）を用いて、正確でロバストなデータ伝送を保証することができる。異なるエミッタからの信号を区別することを支援するため、異なる無線局によるスペクトルの共有に類似した方法で、変調ドメインを、異なるエミッタ、又は、クラス若しくはエミッタの間で分割することができる。

モバイルデバイスは、本明細書で詳述された応用例のためにデバイスの磁力計を使用するように特に構成された、ユーザインタフェースを備えることができる。このユーザインタフェースは、よく知られているＷｉＦｉユーザインタフェースに類似してもよく−使用可能なチャネルについての情報をユーザに提示し、ユーザが、利用するべきチャネル、及び／又は、避けるべきチャネルを指定することができるようにしてもよい。上記で詳述された応用例では、ＵＩは、何のエミッタに合わせるべきであるか、又は、−他のデータを無視して−何のデータをリッスンするべきであるかを、ユーザが指定することができるようにしてもよい。

タッチスクリーンインタフェース−ジェスチャーインタフェースの１つの形式−が参照された。本技術の実施形態で使用することができる、もう１つの形式のジェスチャーインタフェースは、スマートフォンの動きを検知することによって−キャプチャされた画像内の特徴の動きを追跡することによって−動作する。そのようなジェスチャーのインタフェースのさらなる情報は、ディジマークの米国特許第６９４７５７１号に詳述されている。ユーザ入力がシステムに提供されるべきであるときは常に、ジェスチャーの技術を用いることができる。

さらに先を見越すと、表情（例えば、まばたきするなど）、及び／又は、ユーザから検出されたバイオメトリック信号（例えば、脳波又はＥＥＧ）に応答するユーザインタフェースもまた、用いることができる。そのような構成は、ますます周知となっており、いくつかは、米国特許出願公開第２００１／００５６２２５号、第２００２／００７７５３４号、第２００７／０１８５６９７号、第２００８／０２１８４７２号及び第２００９／０２１４０６０号に詳述されている。電話機のカメラシステム（及び補助的なクラウドリソース）を利用してそのような入力および制御動作を認識しうる。

本譲受人は、デジタルウォーターマーキング及びフィンガープリントに基づいた技術を含む、コンテンツ識別技術における広範な経歴を有する。これらの技術は、あるビジュアルクエリにおいて重要な役割を有する。

ウォーターマーキングは、例えば、流通ネットワーク内で個別の媒体／物理的オブジェクトを識別するために使用可能な、唯一のコンテナに依存しない技術である。ウォーターマーキングは幅広く展開され、数え切れないほどの曲、映画及び印刷文書がそうであるように、米国内のテレビ及びラジオの本質的にすべてにデジタルウォーターマークが付いている。

ウォーターマークデータは、コンピュータのための一種の点字としての役目を果たし−マークが付けられたオブジェクト（物理的又は電子的）についての情報により、コンピュータを導くことができる。ある画像へのパターン認識技術の適用は、長い待ち時間の後、その画像が多分、靴を描くという、出力仮説を生じることがある。対照的に、その靴にデジタルウォーターマークデータが付いている場合、はるかに短い時間ではるかに信頼性の高い−且つ、正確な−情報のセットを得ることができ、例えば、その画像は、２００９年５月にインドネシアで製造された、Ｎｉｋｅ（ナイキ）野球シューズ、サイズ１１Ｍ、モデル「ズームコービーＶ（Ｚｏｏｍ Ｋｏｂｅ Ｖ）」を描く。

オブジェクトアイデンティティの指示を、オブジェクト自体の固有の部分として提供することによって、デジタルウォーターマークは、オブジェクトのアイデンティティに基づいて、モバイルデバイス−オブジェクトのインタラクションを非常に容易にする。

ウォーターマークを符号化／復号するための技術は、例えば、ディジマークの米国特許第６６１４９１４号及び第６１２２４０３号、ニールセンの米国特許第６９６８５６４号及び第７００６５５５号、並びに、アービトロンの米国特許第５４５０４９０号、第５７６４７６３号、第６８６２３５５号及び第６８４５３６０号に詳述されている。

ディジマークは、本主題に関連のある様々な他の特許出願を有する。例えば、米国特許出願公開第２００７／０１５６７２６号、第２００８／００４９９７１号及び第２００７／０２６６２５２号を参照されたい。

オーディオフィンガープリンティングの例は、米国特許出願公開第２００７／０２５０７１６号、第２００７／０１７４０５９号及び第２００８／０３０００１１号（ディジマーク）、第２００８／０２７６２６５号、第２００７／０２７４５３７号及び第２００５／０２３２４１１号（ニールセン）、第２００７／０１２４７５６号（グーグル）、米国特許第７５１６０７４号（Ａｕｄｉｔｕｄｅ）、並びに、第６９９０４５３号及び第７３５９８８９号（双方ともシャザム）に詳述されている。画像／ビデオフィンガープリンティングの例は、米国特許第７０２０３０４号（ディジマーク）、第７４８６８２７号（Ｓｅｉｋｏ−Ｅｐｓｏｎ）、米国特許出願公開第２００７／０２５３５９４号（Ｖｏｂｉｌｅ）、第２００８／０３１７２７８号（Ｔｈｏｍｓｏｎ）、及び、第２００２／００４４６５９号（ＮＥＣ）に詳述されている。

ノキアは、視覚的検索技術（Ｐｉｘｔｏ）に従事したＰｈｉｌｉｐｐ Ｓｃｈｌｏｔｅｒによって設立された、ベイエリアの新設企業を獲得し、その「ポイントアンドファインド（Ｐｏｉｎｔ ＆ Ｆｉｎｄ）」プログラムにおいて、その分野の研究を継続している。この研究は、例えば、米国特許出願公開第２００７／０１０６７２１号、第２００８／００７１７４９号、第２００８／００７１７５０号、第２００８／００７１７７０号、第２００８／００７１９８８号、第２００８／０２６７５０４号、第２００８／０２６７５２１号、第２００８／０２６８８７６号、第２００８／０２７０３７８号、第２００９／００８３２３７号、第２００９／００８３２７５号及び第２００９／００９４２８９号に詳述されている。これらの文書に詳述された特徴及び教示は、本出願に詳述された技術及び構成と組み合わせるために適しており、逆の場合も同じである。

簡潔にするため、記載された技術の無数の変形形態及び組み合わせは、本書に列挙されない。出願人は、本明細書の複数の概念を、−それら自体の間で、並びに、引用された従来技術から知られている概念と共に−組み合わせ、代用及び入れ替え可能であることを理解し、意図している。また、詳述された技術は、−現在の、及び来るべき−他の技術と共に効果的に含まれうることは理解されよう。

本明細書を過度に長くすることなく、包括的な開示を提供するため、出願人は、上記で参照された文書及び特許開示を参照により組み込む。（そのような文書は、それらの教示の特定のものに関連して上記で引用された場合であっても、それらの全体として組み込まれる。）これらの参照文献は、本明細書で詳述された構成に組み込むことができ、且つ、本明細書で詳述された技術及び教示がそれらに組み込まれうる、技術及び教示を開示している。

本明細書が、幅広い種類の発明の技術を詳述したことは理解されよう。不完全な要約には、以下が含まれる。

プロセッサと、１つ又は複数のマイクロフォンとを有するポータブルユーザデバイスが、方法において使用され、この方法は、音声認識モジュールに、マイクロフォン（複数可）によって受信されたユーザ発話に対応する音声データを適用し、且つ、それに対応する認識されたユーザ発話データを受信することを含む。次いで、認識されたユーザ発話データを参照することによって、マイクロフォン（複数可）によって受信された音声に関連して適用されるべき、１つ若しくは複数の信号処理動作（複数可）が推論され、又は、信号処理動作のためのパラメータが推論される。

音声刺激を受信するためのマイクロフォンを含み、且つ、第２の刺激を検知するための、少なくとも１つの他のセンサを含む、もう１つのデバイスが、方法において使用され、この方法は、音声認識モジュールに、マイクロフォンによって受信されたユーザ発話に対応する音声データを適用すること、音声認識モジュールから、動詞に対応する、認識された動詞データを受信すること、認識された動詞データを参照することによって、センサ刺激タイプのうちどれがユーザにとって関心のあるものであるかを決定すること、音声認識モジュールから、ユーザの環境内の対象に対応する、認識された名詞データを受信すること、及び、認識された名詞データを参照することによって、決定されたタイプの刺激に関連して適用されるべき、１つ若しくは複数の信号処理動作（複数可）、又は、信号処理動作のためのパラメータを決定することを含む。

第１及び第２の異なるタイプの刺激を受信するための、少なくとも第１のセンサ及び第２のセンサを含む、さらにもう１つのデバイスが、方法において使用され、この方法は、デバイスにおいて、ユーザにとって関心のあるものである、ユーザの環境内の対象の識別を助ける、非触覚ユーザ入力を受信すること、及び、関心の対象を示す前記入力を参照することによって、関連付けられたセンサデータ処理システムを、その対象に関連付けられた情報を抽出するように構成することを含む。

さらにもう１つのそのようなデバイスが、方法において使用され、この方法は、音声認識モジュールに、１つ又は複数のマイクロフォン（複数可）によって受信されたユーザ発話に対応する音声データを適用し、且つ、それに対応する認識されたユーザ発話データを受信すること、及び、前記認識されたユーザ発話データを参照することによって、第２のタイプの刺激に関連して適用されるべき処理を、少なくとも部分的に定義するパラメータを確立することを含む。

さらなるそのようなデバイスは、以下の、音声認識モジュールに、１つ又は複数のマイクロフォン（複数可）によって受信されたユーザ発話に対応する音声データを適用し、且つ、それに対応する認識されたユーザ発話データを受信するステップと、前記認識されたユーザ発話データを参照することによって、第２のタイプの刺激に関連して適用されるべき処理を、少なくとも部分的に定義するパラメータを確立するステップと、前記確立されたパラメータに従って、第２のタイプの刺激を処理するステップとを行うように構成された、プロセッサを含む。

さらにもう１つのデバイスは、複数のセンサと、プロセッサと、メモリとを含み、メモリが、ブラックボードデータ構造を備え、プロセッサが、センサデータを入力として取り、且つ、出力を作り出す、複数の認識エージェントサービスの実行に関与する。そのようなデバイスが方法において使用され、この方法は、サービスに対して、ブラックボードデータ構造においてデータを投稿、編集又は削除するための特権を、（ａ）そのサービスが性質的に商用であるかどうか、及び／又は、（ｂ）前記サービスに関する外部プロバイダから用意された信用のしるし（ｔｒｕｓｔ ｉｎｄｉｃｉａ）が基準を満たすかどうかに応じて、付与することを含む。

さらにもう１つのデバイスは、画像及び音声センサと、プロセッサと、メモリとを含む。メモリは、画像データを処理して、オブジェクト認識データを作り出すこと、音声データを処理して、認識された発話データを作り出すこと、及び、認識された発話データを作り出すことにおける曖昧性を解決することに関連して、オブジェクト認識データを使用することを含むステップを、デバイスに行わせる命令を格納する。

さらなるそのようなデバイスは、場所及び音声センサと、プロセッサと、メモリとを含む。メモリは、以下の、場所センサからのデータを参照することによって、デバイスの場所についての場所記述子を取得するステップと、音声データを処理して、認識された発話データを作り出すステップと、認識された発話データを作り出すことにおける曖昧性を解決することに関連して、場所記述子を使用するステップとを、デバイスに行わせる命令を格納する。

本技術のもう１つの発明の態様は、受信された画像データを解析して、カラフルさのメトリック又はコントラストのメトリックを決定すること、及び、異なるタイプの画像から導出された情報をモバイル電話からユーザに提示するために、複数の異なる画像認識処理のうちどれが、又は、複数の異なる画像認識処理がどの順序で、モバイル電話のカメラによってキャプチャされた画像データに適用されるべきであるかを決定することにおいて、前記決定されたメトリックを使用することを含む、方法である。

さらなるそのような方法は、受信された画像データを解析して、色の彩度のメトリックを決定すること、決定されたメトリックを、閾値と比較すること、決定されたメトリックが閾値より低い場合、第１のセットの処理から１つ又は複数の認識処理を適用すること、及び、決定されたメトリックが閾値より高い場合、第１のセットの処理とは異なる第２のセットの処理から、１つ又は複数の認識処理を適用することを含む。

もう１つのそのような方法は、第１のセットの画像データを解析して、色の彩度のメトリックを計算すること、前記計算された色の彩度のメトリックを、入力として、ルールベースの処理に適用して、複数の異なる認識処理のうちどれが、又は、複数の異なる認識処理がどの順序で、適用されるべきであるかを決定すること、及び、決定された認識処理（複数可）を、画像データのセットに適用することを含む。

さらにもう１つの発明の方法は、センサベースの、人力による、ルートに沿ったナビゲーションに関し、目的地までのルートを決定すること、ユーザによって携行された電子装置内の１つ又は複数のセンサを使用して、決定されたルートに沿ったユーザの進行を検知すること、及び、フィードバックをユーザに提供して、ナビゲーションを支援することを含み、フィードバックが、ユーザが目的地へ向かって進行するにつれて、より頻繁になるクリックのパターンを含む。

さらなるそのような方法は、画像データを処理する、カメラ付きポータブルデバイスを操作することに関し、最初のセットの複数の異なる画像処理演算を行うこと、及び、明示されたユーザコマンドなしに、状況が保証するとき、追加の画像処理演算を呼び出すことを含み、デバイスが自律的に作動して、推論又は予想されたユーザの要望をかなえる。

さらにもう１つの発明の方法は、磁気センサ付きスマートフォンに関与し、小売店環境内で複数の電磁エミッタによって出された磁気信号を検知し、それに基づいて、ナビゲーション又は製品情報をユーザに提供することを含む。

さらにもう１つのそのような方法は、第１のフェーズの動作内で、画像のシーケンスをユーザの周囲からキャプチャすること、シーケンスを処理して、その中で特徴を認識し、関連情報を識別することであって、前記処理が、ユーザによって携行されたポータブル装置によって少なくとも部分的に行われること、及び、第１の後に続く第２のフェーズの動作内で、ポータブル装置に関連付けられた出力デバイスを使用して、関連情報をユーザに提示することを含む。

さらなる方法は、（例えば、リンクトデータシステムにおいて）物理的オブジェクトについての、アサーションにアクセスするため、又は、アサーションを作成するためのユーザの能力を、ユーザがオブジェクトとの、又は、そのようなアサーションを以前に作成した別のユーザとの明白な関係を有しなければ、制限する。

関連するリンクトデータ方法は、ユーザによって携行されたセンサによって作り出されたデータに基づいて、動き情報をチェックし、動き情報が、ユーザがある方法で（例えば、閾値を上回る速度で）動いていることを示す場合、物理的オブジェクトに関する、アサーションにアクセスするため、又は、アサーションを作成するためのユーザの能力を制限することによって、特徴付けられる。

詳述された技術のもう１つの発明の態様は、プロセッサと、メモリと、タッチスクリーンと、場所決定モジュールと、少なくとも１つの音声又は画像センサとを含む、処理デバイスである。メモリは、タッチスクリーン上でユーザインタフェースを提示するようにプロセッサを構成する命令を格納し、その第１の部分が、センサからの情報を提示し、その第２の部分が、デバイスの場所に関係付けられた情報を同時に提示する。

もう１つのデバイスは、プロセッサと、メモリと、画面と、画像センサとを含む。メモリは、タッチスクリーン上で、画像センサによって検知された画像に対応するデータを提示するようにプロセッサを構成する命令を格納し、プロセッサが、タッチスクリーン上で、スイープするレーダートレース効果をさらに提示して、画像データを処理することにおけるデバイスアクティビティを示す。

本明細書で詳述されたさらなる発明の方法は、サウンドソース位置測定の方法であり、この方法は、環境内の複数の無線電話を使用して、周囲の音声をサンプリングすること、第１の電話によって検知された音声情報を、第２の電話へ送信すること、第１の電話の位置を第２の場所に関係付ける、場所データを見極めること、並びに、第２の電話において、場所データ、第１の電話から受信された音声情報、及び、第２の電話によってサンプリングされた音声を処理して、第２の電話に対するサウンドソース方向を見極めることを含む。

当然、上述の方法に対応するデバイス及びソフトウェア、並びに、上述のデバイスに対応する方法及びソフトウェアもまた、出願人の発明の研究の部分である。また、ポータブルデバイス内のプロセッサによって行われているとして記載される方法をまた、リモートサーバによって行うこともでき、又は、いくつかのユニットによって分散した方法で行うことができる。
発明例
［発明例１］
プロセッサを有するポータブルユーザデバイスを用いた方法であって、前記プロセッサが、前記方法の１つ又は複数のステップを行うように構成され、前記デバイスがまた、音声を受信する少なくとも１つのマイクロフォンをも含み、前記方法が、
音声認識モジュールに、マイクロフォン（複数可）によって受信されたユーザ発話に対応する音声データを適用し、且つ、それに対応する認識されたユーザ発話データを受信するステップと、
前記認識されたユーザ発話データを参照することによって、前記マイクロフォン（複数可）によって受信された音声に関連して適用されるべき、１つ若しくは複数の信号処理動作（複数可）、又は、信号処理動作のためのパラメータを推論するステップと、
を含む、方法。
［発明例２］
前記マイクロフォン（複数可）によって受信された音声において、前記推論された信号処理動作（複数可）を行うステップをさらに含む、発明例１に記載の方法。
［発明例３］
前記方法が、前記推論された信号処理動作（複数可）を行うステップに関連して、前記ポータブルデバイスの画面上に、それに関係付けられたボーブルを表示するステップをさらに含み、前記ボーブルの外観が、第１の状態から第２の状態へ変化して、前記信号処理における処理を示す、発明例２に記載の方法。
［発明例４］
前記推論するステップが、認識されたユーザ発話データをデータ構造に適用し、且つ、命令、又は、それに対応するパラメータデータを取得するサブステップを含む、発明例１に記載の方法。
［発明例５］
前記信号処理動作（複数可）が、音声イコライゼーション機能を含む、発明例１に記載の方法。
［発明例６］
前記パラメータが、それにより前記音声がサンプリング又は再サンプリングされるサンプリング周波数に関する、発明例１に記載の方法。
［発明例７］
前記パラメータが、前記音声に関連して調べられるべきであるリモートデータベースの識別に関する、発明例１に記載の方法。
［発明例８］
前記信号処理動作（複数可）が、前記音声に適用されるべきコンテンツ識別処理に関する、発明例１に記載の方法。
［発明例９］
前記信号処理動作（複数可）が、前記音声に適用されるべきウォーターマークベースのコンテンツ識別処理に関する、発明例８に記載の方法。
［発明例１０］
前記信号処理動作（複数可）が、前記音声に適用されるべきフィンガープリントベースのコンテンツ識別処理に関する、発明例８に記載の方法。
［発明例１１］
前記認識された発話データが、前記ユーザの環境内の対象を識別し、前記方法が、前記識別された対象に基づいて、前記１つ若しくは複数の信号処理動作（複数可）、又は、パラメータを推論するステップを含む、発明例１に記載の方法。
［発明例１２］
前記音声データを、前記ポータブルユーザデバイス内の音声認識モジュールに適用するステップを含む、発明例１に記載の方法。
［発明例１３］
前記認識されたユーザ発話データが、ない（ｎｏｔ）、ノー（ｎｏ）、及び、無視する（ｉｇｎｏｒｅ）、というリストからの否定を含み、前記方法が、それに基づいて信号処理を変更するステップを含む、発明例１に記載の方法。
［発明例１４］
前記推論するステップがまた、部分的にコンテキスト情報にも基づく、発明例１に記載の方法。

［発明例１５］
プロセッサを有するポータブルユーザデバイスを用いた方法であって、前記プロセッサが、前記方法の１つ又は複数のステップを行うように構成され、前記デバイスがまた、前記ユーザの環境から第１及び第２の異なるタイプの刺激をそれぞれ受信するための、少なくとも第１のセンサ及び第２のセンサをも含み、前記第１のセンサが、聴覚刺激を検知するためのマイクロフォンを備え、前記方法が、
音声認識モジュールに、前記マイクロフォンによって受信されたユーザ発話に対応する音声データを適用するステップと、
前記音声認識モジュールから、動詞に対応する、認識された動詞データを受信するステップと、
前記認識された動詞データを参照することによって、前記第１の刺激タイプ又は前記第２の刺激タイプのうちどちらが前記ユーザにとって関心のあるものであるかを決定するステップと、
前記音声認識モジュールから、前記ユーザの環境内の対象に対応する、認識された名詞データを受信するステップと、
前記認識された名詞データを参照することによって、前記決定されたタイプの刺激に関連して適用されるべき、１つ若しくは複数の信号処理動作（複数可）、又は、信号処理動作のためのパラメータを決定するステップと、
を含む、方法。
［発明例１６］
前記動詞データが、注視する（ｌｏｏｋ）、見守る（ｗａｔｃｈ）、眺める（ｖｉｅｗ）、見る（ｓｅｅ）、及び、読む（ｒｅａｄ）、からなるリストからの動詞に対応するデータを備える、発明例１５に記載の方法。
［発明例１７］
前記動詞データが、聴く（ｌｉｓｔｅｎ）、及び、聞く（ｈｅａｒ）、からなるリストからの動詞に対応するデータを備える、発明例１５に記載の方法。
［発明例１８］
前記名詞データが、新聞、本、雑誌、ポスター、テキスト、印刷物、チケット、箱、パッケージ、カートン、包装紙、製品、バーコード、ウォーターマーク、写真、人、男性、少年、女性、少女、人々、ディスプレイ、画面、モニタ、ビデオ、映画、テレビ、ラジオ、アイフォン、アイパッド（登録商標）、及び、キンドル、からなるリストからの名詞に対応するデータを備える、発明例１５に記載の方法。
［発明例１９］
前記認識された動詞データを参照することによって、視覚刺激が前記ユーザにとって関心のあるものであることを決定するステップと、前記視覚刺激に適用されるべき画像処理のタイプを決定するステップと、を含む、発明例１５に記載の方法。
［発明例２０］
前記画像処理のタイプが、デジタルウォーターマーク復号を備える、発明例１９に記載の方法。
［発明例２１］
前記画像処理のタイプが、画像フィンガープリンティングを備える、発明例１９に記載の方法。
［発明例２２］
前記画像処理のタイプが、光学式文字認識を備える、発明例１９に記載の方法。
［発明例２３］
前記画像処理のタイプが、バーコード読み取りを備える、発明例１９に記載の方法。
［発明例２４］
前記認識された動詞データを参照することによって、視覚刺激が前記ユーザにとって関心のあるものであることを決定するステップと、
前記認識された名詞データを参照することによって、視覚刺激に適用されるべきフィルタリング機能を決定するステップと、
を含む、発明例１５に記載の方法。
［発明例２５］
前記認識された動詞データを参照することによって、視覚刺激が前記ユーザにとって関心のあるものであることを決定するステップと、
前記認識された名詞データを参照することによって、視覚刺激に適用されるべき光学的焦点合わせ機能を決定するステップと、
を含む、発明例１５に記載の方法。
［発明例２６］
前記認識されたユーザ発話データが、ない（ｎｏｔ）、ノー（ｎｏ）、及び、無視する（ｉｇｎｏｒｅ）、というリストからの否定を含む、発明例１５に記載の方法。

［発明例２７］
プロセッサを有するポータブルユーザデバイスを用いた方法であって、前記プロセッサが、前記方法の１つ又は複数のステップを行うように構成され、前記デバイスがまた、第１及び第２の異なるタイプの刺激をそれぞれ受信するための、少なくとも第１のセンサ及び第２のセンサをも含み、前記方法が、
前記デバイスにおいて、前記ユーザにとって関心のあるものである、前記ユーザの環境内の対象の識別を助ける、非触覚ユーザ入力を受信するステップと、
関心の対象を示す前記入力を参照することによって、関連付けられたセンサデータ処理システムを、その対象に関連付けられた情報を抽出するように構成するステップと、
を含む、方法。
［発明例２８］
前記ユーザにとって関心のあるものである前記対象を示す、ユーザ発話入力を受信するステップを含む、発明例２７に記載の方法。
［発明例２９］
前記構成するステップが、前記関連付けられたセンサに関するデータを処理することにおいて使用されるパラメータを確立するサブステップを含む、発明例２７に記載の方法。

［発明例３０］
プロセッサを有するポータブルユーザデバイスを用いた方法であって、前記プロセッサが、前記方法の１つ又は複数のステップを行うように構成され、前記デバイスがまた、前記ユーザの環境から第１及び第２の異なるタイプの刺激をそれぞれ受信するための、少なくとも第１のセンサ及び第２のセンサをも含み、前記第１のセンサが、聴覚刺激を検知するためのマイクロフォンを備え、前記方法が、
音声認識モジュールに、マイクロフォン（複数可）によって受信されたユーザ発話に対応する音声データを適用し、且つ、それに対応する認識されたユーザ発話データを受信するステップと、
前記認識されたユーザ発話データを参照することによって、前記第２のタイプの刺激に関連して適用されるべき処理を、少なくとも部分的に定義するパラメータを確立するステップと、
を含む、方法。

［発明例３１］
非一時的ソフトウェア命令を含む、コンピュータ可読物理記憶媒体であって、前記非一時的ソフトウェア命令が、そのようなソフトウェア命令によってプログラムされたユーザデバイスプロセッサに、
音声認識モジュールに、マイクロフォン（複数可）によって受信されたユーザ発話に対応する音声データを適用し、且つ、それに対応する認識されたユーザ発話データを受信すること、及び
前記認識されたユーザ発話データを参照することによって、前記第２のタイプの刺激に関連して適用されるべき処理を、少なくとも部分的に定義するパラメータを確立すること
を行わせるように動作する、コンピュータ可読物理記憶媒体。
［発明例３２］
前記確立されたパラメータに従って、前記第２のタイプの刺激を処理することを、前記プロセッサに行わせるように動作する命令を追加で含む、発明例３１に記載のコンピュータ可読物理記憶媒体。

［発明例３３］
音声を受信する少なくとも１つのマイクロフォンを有し、且つ、プロセッサを有するスマートフォンデバイスであって、前記プロセッサが、以下の
音声認識モジュールに、マイクロフォン（複数可）によって受信されたユーザ発話に対応する音声データを適用し、且つ、それに対応する認識されたユーザ発話データを受信するステップと、
前記認識されたユーザ発話データを参照することによって、前記第２のタイプの刺激に関連して適用されるべき処理を、少なくとも部分的に定義するパラメータを確立するステップと、
前記確立されたパラメータに従って、前記第２のタイプの刺激を処理するステップと、
を行うように構成される、スマートフォンデバイス。

［発明例３４］
複数のセンサと、プロセッサと、メモリとを有するポータブルデバイスを用いた方法であって、前記プロセッサが、複数の認識エージェントサービスの実行に関与し、前記サービスが、センサデータを入力として取り、且つ、出力を作り出し、前記メモリが、ブラックボードデータ構造を備え、前記方法が、サービスに対して、前記ブラックボードデータ構造においてデータを投稿、編集又は削除するための特権を、（ａ）前記サービスが性質的に商用であるかどうか、及び／又は、（ｂ）前記サービスに関する外部プロバイダから用意された信用のしるしが基準を満たすかどうかに応じて、付与するステップを含む、方法。
［発明例３５］
前記ブラックボードデータ構造が、異なる認識エージェントサービスがデータを投稿することができる先の複数の仮想ページを、その間のリンクと共に備える、ウィキとして配置される、発明例３４に記載の方法。

［発明例３６］
画像及び音声センサと、プロセッサと、メモリとを有するポータブルデバイスであって、前記メモリが、以下の
画像データを処理して、オブジェクト認識データを作り出すステップと、
音声データを処理して、認識された発話データを作り出すステップと、
前記認識された発話データを作り出すことにおける曖昧性を解決することに関連して、前記オブジェクト認識データを使用するステップと、
を、前記デバイスに行わせる命令を格納する、ポータブルデバイス。

［発明例３７］
場所及び音声センサと、プロセッサと、メモリとを有するポータブルデバイスであって、前記メモリが、以下の
前記場所センサからのデータを参照することによって、前記デバイスの場所についての場所記述子を取得するステップと、
音声データを処理して、認識された発話データを作り出すステップと、
前記認識された発話データを作り出すことにおける曖昧性を解決することに関連して、前記場所記述子を使用するステップと、
を、前記デバイスに行わせる命令を格納する、ポータブルデバイス。

［発明例３８］
受信された画像データを解析して、カラフルさのメトリック又はコントラストのメトリックを決定するステップと、
異なるタイプの画像から導出された情報をモバイル電話からユーザに提示するために、複数の異なる画像認識処理のうちどれが、又は、複数の異なる画像認識処理がどの順序で、前記モバイル電話のカメラによってキャプチャされた画像データに適用されるべきであるかを決定することにおいて、前記決定されたメトリックを使用するステップと、
を含む、方法。
［発明例３９］
前記決定するステップに従って、画像認識処理を適用するステップを含む、発明例３８に記載の方法。
［発明例４０］
バーコード読み取り機能、光学式文字認識機能、顔認識機能、及び／又は、ウォーターマーク復号機能を、前記決定するステップの結果として適用するステップを含む、発明例３８に記載の方法。
［発明例４１］
バーコード読み取り機能を、前記決定するステップの結果として適用するステップを含む、発明例３８に記載の方法。
［発明例４２］
光学式文字認識機能を、前記決定するステップの結果として適用するステップを含む、発明例３８に記載の方法。
［発明例４３］
顔認識機能を、前記決定するステップの結果として適用するステップを含む、発明例３８に記載の方法。
［発明例４４］
ウォーターマーク復号機能を、前記決定するステップの結果として適用するステップを含む、発明例３８に記載の方法。
［発明例４５］
前記画像データを、モバイル電話デバイスのカメラシステムから受信するステップを含む、発明例３８に記載の方法。
［発明例４６］
前記複数の画像認識処理のうちどれを呼び出さないかを決定することにおいて、前記決定されたメトリックを使用するステップをさらに含む、発明例３８に記載の方法。
［発明例４７］
プロセッサと、メモリとを含むモバイル電話であって、前記メモリが、発明例３８に記載の方法を前記プロセッサに行わせる、非一時的ソフトウェア命令を含む、モバイル電話。

［発明例４８］
非一時的ソフトウェア命令を格納しているコンピュータ可読記憶媒体であって、前記命令が、それによってプログラムされたモバイル電話プロセッサに、
受信された画像データを解析して、色の彩度のメトリック又はコントラストのメトリックを決定すること、及び
複数の異なる画像認識処理のうちどれが、又は、複数の異なる画像認識処理がどの順序で、前記モバイル電話によって呼び出されるべきであるかを決定することにおいて、前記決定されたメトリックを使用することを行わせるように動作する、コンピュータ可読記憶媒体。

［発明例４９］
受信された画像データを解析して、色の彩度のメトリックを決定するステップと、
前記決定されたメトリックを、閾値と比較するステップと、
前記決定されたメトリックが前記閾値より低い場合、第１のセットの処理から１つ又は複数の認識処理を適用するステップと、
前記決定されたメトリックが前記閾値より高い場合、前記第１のセットの処理とは異なる第２のセットの処理から、１つ又は複数の認識処理を適用するステップと、
を含む、方法。
［発明例５０］
前記決定されたメトリックが前記閾値より低い場合、前記第１のセットの処理から１つ又は複数の認識処理を適用した後、前記第２のセットの処理から認識処理を適用するステップをさらに含む、発明例４９に記載の方法。
［発明例５１］
前記セットのうち一方がバーコード読み取り処理を含み、前記セットのうち他方が顔認識処理を含む、発明例４９に記載の方法。
［発明例５２］
前記セットのうち一方がバーコード読み取り処理を含み、前記セットのうち他方がオブジェクト認識処理を含む、発明例４９に記載の方法。
［発明例５３］
前記セットのうち一方がＯＣＲ処理を含み、前記セットのうち他方が顔認識処理を含む、発明例４９に記載の方法。
［発明例５４］
前記セットのうち一方がＯＣＲ処理を含み、前記セットのうち他方がオブジェクト認識処理を含む、発明例４９に記載の方法。

［発明例５５］
第１のセットの画像データを解析して、色の彩度のメトリックを計算するステップと、
前記計算された色の彩度のメトリックを、入力として、ルールベースの処理に適用して、複数の異なる認識処理のうちどれが、又は、複数の異なる認識処理がどの順序で、適用されるべきであるかを決定するステップと、
前記決定された認識処理（複数可）を、画像データのセットに適用するステップと、
を含む、方法。
［発明例５６］
前記決定された認識処理（複数可）を、前記第１のセットの画像データに適用するステップを含む、発明例５５に記載の方法。
［発明例５７］
前記決定された認識処理（複数可）を、前記第１のセットの画像データとは異なる第２のセットの画像データに適用するステップを含む、発明例５５に記載の方法。

［発明例５８］
センサベースの、人力による、ルートに沿ったナビゲーションの方法であって、前記方法が、
目的地までのルートを決定するステップと、
前記ユーザによって携行された電子装置内の１つ又は複数のセンサを使用して、前記決定されたルートに沿ったユーザの進行を検知するステップと、
フィードバックを前記ユーザに提供して、ナビゲーションを支援するステップと、
を含み、
前記フィードバックが、前記ユーザが前記目的地へ向かって進行するにつれて、より頻繁になるクリックのパターンを含む、方法。
［発明例５９］
前記フィードバックが、振動フィードバックを含む、発明例５８に記載の方法。
［発明例６０］
前記ユーザが向く方向に従って、前記フィードバックを変更して、前記ユーザによる進行するべき方向の決定を支援するステップを含む、発明例５８に記載の方法。
［発明例６１］
前記ユーザが静止しているとき、前記フィードバックの大きさを増し、又は、前記ユーザが動いているとき、前記フィードバックの前記大きさを減らすステップを含む、発明例５８に記載の方法。
［発明例６２］
前記１つ又は複数のセンサが、その方向を示す出力データを作り出す磁力計を含み、前記磁力計が、−前記装置が前記ユーザによって携行される向きにより−前記ユーザが向いている方向よりも逸脱する方向を示すことがあり、前記方法が、前記逸脱を補償するステップを含む、発明例５８に記載の方法。

［発明例６３］
画像データを処理する、カメラ付きポータブルデバイスを操作する方法であって、前記デバイスがユーザによって携行され、前記方法が、以下の
最初のセットの複数の異なる画像処理演算を行うステップと、
明示されたユーザコマンドなしに、状況が保証するとき、追加の画像処理演算を呼び出すステップと、
を含み、
前記デバイスが自律的に作動して、推論又は予想されたユーザの要望をかなえる、方法。
［発明例６４］
前記画像処理演算のうち１つ又は複数の結果生じるデータオブジェクトを格納するか、又は、その前記格納を用意し、前記データオブジェクトに関するセマンティックアサーションを、リモートのリンクトデータレジストリへ送信するステップを含む、発明例６３に記載の方法。
［発明例６５］
前記画像データによって表されたシーン内で１つ又は複数の視覚的特徴を見極め、視覚的ボーブルを前記デバイスの画面上で、前記シーン内の前記視覚的特徴（複数可）に対応する場所（複数可）に提示するステップを含む、発明例６３に記載の方法。
［発明例６６］
前記ボーブルが、長方形でない形状である、発明例６５に記載の方法。
［発明例６７］
前記デバイス画面上で１つ又は複数のボーブルに関して、ユーザのジェスチャーを検知し、それに基づいてアクションを起こすステップを含む、発明例６５に記載の方法。
［発明例６８］
前記アクションが、
（ａ）より多いか又はより少ない処理リソースを、ボーブルに関連付けられた機能に割り振るステップであって、前記機能が、前記ユーザのジェスチャーを検知するより前に開始されている、ステップと、
（ｂ）ボーブルに関連付けられた処理を縮小し、それに関係付けられた情報を格納して、ユーザプリファレンス又は振る舞いのパターンを見極めることができるようにするステップと、
（ｃ）リモート処理システム内で関連処理を継続中に、前記デバイス上でボーブルに関連付けられた処理を少なくとも一時的に縮小するステップと、
（ｄ）画像を編集して、１つ又は複数の特徴を除外するステップと、
（ｅ）前記デバイス画面上に提示された画像データ内の１つ又は複数の特徴の投影を変更するステップと、
（ｆ）複数のボーブルによって表されたエンティティ間の社会的関係を定義するステップと、
のうち、少なくとも１つを含む、発明例６７に記載の方法。
［発明例６９］
前記提示されたボーブルのうち少なくとも１つを遠近法によって曲げて、前記シーン内で見極められた表面特徴に対応するようにするステップを含む、発明例６５に記載の方法。
［発明例７０］
前記画像処理演算のうち１つ又は複数が、前記シーン内で特徴を認識又は識別するなど、所望の結果に向かって進行するとき、前記提示されたボーブルのうち１つの明るさ、形状又はサイズを変更するステップを含む、発明例６５に記載の方法。
［発明例７１］
前記呼び出すステップが、
（ａ）場所、
（ｂ）時刻、
（ｃ）１人又は複数の人々への近接、
（ｄ）前記最初のセットの画像処理演算に基づいた出力、又は
（ｅ）ユーザの振る舞いの統計モデルのうち、少なくとも１つを含む状況に基づいて、追加の画像処理演算を呼び出すサブステップを含む、発明例６３に記載の方法。
［発明例７２］
前記画像処理演算のうち１つ又は複数からの結果を含むデータから、前記ユーザによって望まれたインタラクションのタイプについての情報を推論し、そのような情報に基づいて、追加の画像処理演算を呼び出すステップを含む、発明例６３に記載の方法。
［発明例７３］
データをリモートシステムへ送信して、前記リモートシステムが前記デバイスと同じ画像処理演算のうち１つ又は複数を行うことができるようにするステップをも含む、発明例６３に記載の方法。
［発明例７４］
前記デバイスが自律的に作動して、前記デバイスのカメラによって撮像された硬貨の集まりの価値を決定する、発明例６３に記載の方法。
［発明例７５］
第１のセットの行われるべき追加の画像処理演算を、より大きい第２のセットの可能な画像処理演算から、
（ａ）デバイスリソース使用、
（ｂ）別々の前記可能な演算に関連付けられたリソース需要、及び
（ｃ）別々の前記可能な演算の間の対応のうち、１つ又は複数を示すデータに基づいて、選択するステップを含む、発明例６３に記載の方法。
［発明例７６］
前記方法が、前記画像データによって表されたシーン内で１つ又は複数の視覚的特徴を見極め、そのような特徴の各々に関係付けられたデータを、対応する識別子に関連して格納するステップを含み、前記識別子が、以下の
（ａ）セッションＩＤ、
（ｂ）明示的オブジェクトＩＤ、及び
（ｃ）前記特徴から導出された、又は、関連状況から導出されたデータのうち、少なくとも２つに基づく、発明例６３に記載の方法。
［発明例７７］
前記方法が、前記デバイス内の非画像センサシステムを使用して、非画像情報を作り出し、そのような情報を、以下の
（ａ）画像処理演算の選択に影響を与えること、及び
（ｂ）前記画像データについての２つ以上の候補の結論の間の曖昧性を除去することのうち、少なくとも１つのために用いるステップを含み、
前記非画像センサシステムが、ジオロケーションシステム、音声センサ、温度センサ、磁場センサ、動きセンサ又は嗅覚センサのうち、少なくとも１つを含む、発明例６３に記載の方法。
［発明例７８］
前記画像データのうち少なくとも一定のもの、又は、前記画像処理演算のうち１つ又は複数からのデータを、リモートコンピュータシステムへ送信して、前記リモートコンピュータシステムが、前記デバイスが、その処理中に、見極めなかった情報を収集するために、前記デバイスによって以前に行われた画像処理を継続することができるようにするステップをさらに含む、発明例６３に記載の方法。

［発明例７９］
磁気センサ付きスマートフォンを操作する方法であって、小売店環境内で複数の電磁エミッタによって出された磁気信号を検知し、それに基づいて、ナビゲーション又は製品情報をユーザに提供するステップによって特徴付けられる、方法。

［発明例８０］
第１のフェーズの動作内で、画像のシーケンスをユーザの周囲からキャプチャするステップと、
前記シーケンスを処理して、その中で特徴を認識し、関連情報を識別するステップであって、前記処理が、前記ユーザによって携行されたポータブル装置によって少なくとも部分的に行われる、ステップと、
前記第１の後に続く第２のフェーズの動作内で、前記ポータブル装置に関連付けられた出力デバイスを使用して、前記関連情報を前記ユーザに提示するステップと、
を含む、方法。
［発明例８１］
（ａ）さもなければ前記シーケンスのより前の部分内で識別不可能である、画像特徴を前記シーケンスのより後の部分内で識別し、前記より後の部分からの前記識別を使用して、前記より前の部分内で前記特徴を識別するステップと、
（ｂ）ユーザのジェスチャーに応答して、前記関連情報のうち少なくともいくつかによって注釈が付けられた、前記シーケンスの少なくとも部分中を前方又は後方に進むステップと、
のうち、少なくとも１つを含む、発明例８０に記載の方法。

［発明例８２］
物理的オブジェクトについての、アサーションにアクセスするため、又は、アサーションを作成するためのユーザの能力を、前記ユーザが前記オブジェクトとの、又は、そのようなアサーションを以前に作成した別のユーザとの明白な関係を有しなければ、制限するステップによって特徴付けられる、リンクトデータ方法。
［発明例８３］
前記明白な関係が、前記ユーザによって携行されたスマートフォンデバイス内のセンサシステムによって作り出されたデータによって示されるような、前記物理的オブジェクトから一定の距離内の存在である、発明例８２に記載の方法。

［発明例８４］
ユーザによって携行されたセンサによって作り出されたデータに基づいて、動き情報をチェックし、前記動き情報が、前記ユーザが制限された方法で動いていることを示す場合、物理的オブジェクトに関する、アサーションにアクセスするため、又は、アサーションを作成するための前記ユーザの能力を制限するステップによって特徴付けられる、リンクトデータ方法。
［発明例８５］
前記制限された方法が、閾値より上の速度の動きを含む、発明例８４に記載の方法。

［発明例８６］
プロセッサと、メモリと、タッチスクリーンと、場所決定モジュールと、少なくとも１つの音声又は画像センサとを含む、処理デバイスであって、前記メモリが、前記タッチスクリーン上でユーザインタフェースを提示するように前記プロセッサを構成する命令を格納し、前記ユーザインタフェースの第１の部分が、前記センサからの情報を提示し、前記ユーザインタフェースの第２の部分が、前記デバイスの場所に関係付けられた情報を同時に提示する、処理デバイス。
［発明例８７］
前記デバイスの場所に関係付けられた前記情報が、近くの付近を描く地図を備え、前記命令が、前記ユーザの過去にあったアクションを示すピンを前記地図上に提示するように、前記プロセッサを構成する、発明例８６に記載のデバイス。

［発明例８８］
プロセッサと、メモリと、画面と、画像センサとを含む、処理デバイスであって、前記メモリが、前記タッチスクリーン上で、前記画像センサによって検知された画像に対応するデータを提示するように前記プロセッサを構成する命令を格納し、前記プロセッサが、前記タッチスクリーン上で、スイープするレーダートレース効果をさらに提示して、画像データを処理することにおけるデバイスアクティビティを示す、処理デバイス。
［発明例８９］
前記命令が、前記スイープするレーダートレースを引きずりながら、前記画像センサによって撮像されたオブジェクトの向きについてのしるしを提示するように、前記プロセッサを構成する、発明例８８に記載のデバイス。
［発明例９０］
前記しるしが、検知された画像データにおけるデジタルウォーターマークの向きを示す、発明例８９に記載のデバイス。
［発明例９１］
サウンドソース位置測定の方法であって、
環境内の複数の無線電話を使用して、周囲の音声をサンプリングするステップと、
第１の電話によって検知された音声情報を、第２の電話へ送信するステップと、
前記第１の電話の位置を前記第２の場所に関係付ける、場所データを見極めるステップと、
前記第２の電話において、前記場所データ、前記第１の電話から受信された音声情報、及び、前記第２の電話によってサンプリングされた音声を処理して、前記第２の電話に対するサウンドソース方向を見極めるステップと、
を含む、方法。
［発明例９２］
前記送信するステップが、ウィンドウ化周波数ドメイン（ｗｉｎｄｏｗｅｄ ｆｒｅｑｕｅｎｃｙ ｄｏｍａｉｎ）ベースの圧縮によって時間的に曖昧にされていない情報を送信するサブステップを含む、発明例９１に記載の方法。

Claims (7)

1. 画像をキャプチャし処理する、カメラ付きポータブルデバイスを操作する方法であって、前記デバイスがユーザによって携行され、前記方法が、以下の
   前記キャプチャされた画像上でルーチン的に行われる基本的な画像処理演算のセットを実行するステップと、
   前記実行された基本的な画像処理演算のセットからの結果を含むコンテキストデータから前記ユーザによって望まれる演算のタイプについての情報を推論し、前記推論された情報に基づき追加の画像処理演算を決定するステップであって、前記追加の画像処理演算は前記キャプチャされた画像に示される特定の被写体を認識するように機能する、ステップと、
   明示されたユーザコマンドなしに、前記決定された追加の画像処理演算を呼び出すステップと、
   を含み、
   前記デバイスが自律的に作動して、推論又は予想されたユーザの要望をかなえ、
   第１のキャプチャされた画像及び第２のキャプチャされた画像に関連付けられた異なるコンテキストデータにより、前記第１のキャプチャされた画像に対し、前記望まれる演算のタイプがウォータマーク復号演算を含まずにバーコード復号演算を含むと推論され、前記第２のキャプチャされた画像に対し、前記望まれる演算のタイプがバーコード復号演算を含まずにウォータマーク復号演算を含むと推論される、方法。
2. 前記キャプチャされた画像上で基本的な画像処理演算のセットを実行するステップは、前記キャプチャされた画像の色彩度を決定するステップを含む、請求項１に記載の方法。
3. 前記コンテキストデータはユーザの場所に関するデータをさらに含む、請求項１に記載の方法。
4. 前記コンテキストデータは認識されたユーザの発話に関するデータをさらに含む、請求項１に記載の方法。
5. 前記第２のキャプチャされた画像に対し、前記望まれる演算のタイプがバーコード復号演算を含まずに顔認識演算を含むと推論される、請求項１に記載の方法。
6. 前記第２のキャプチャされた画像は、前記第１のキャプチャされた画像に比べて強い色調を有する、請求項１に記載の方法。
7. 前記第２のキャプチャされた画像は、前記第１のキャプチャされた画像に比べて低いコントラストを有する、請求項１に記載の方法。