(57)【特許請求の範囲】
【請求項１】
オペレーティングシステム（ＯＳ）ソフトウェアが格納されているコンピュータ可読ストレージ媒体であって、
前記オペレーティングシステムソフトウェアは、複数のＯＳサービスを、前記ＯＳによって定義された複数のアプリケーションプログラミングインターフェース（ＡＰＩ）を通して、呼び出し側アプリケーションプログラムに提供するように、プロセッサを構成する役目を果たし、
前記ＯＳサービスが、
視覚又は聴覚の情報を表す信号データから、コンテンツ識別データを導出すること、及び、
前記コンテンツ識別データをサブスクライブする複数のアプリケーションプログラムによって使用するためのメッセージキューに前記コンテンツ識別データをパブリッシュすること、
を含む、コンピュータ可読ストレージ媒体。
【請求項２】
前記導出することが、ウォーターマーク抽出アルゴリズムを前記信号データに適用して、ウォーターマークデータを生じることを含む、請求項１に記載のコンピュータ可読ストレージ媒体。
【請求項３】
前記導出することが、フィンガープリント抽出アルゴリズムを前記信号データに適用して、フィンガープリントデータを生じること、及び、メタデータレジストリにアクセスして、前記信号データに関連付けられているメタデータであって前記コンテンツ識別データとして機能するメタデータを得ること、を含む、請求項１に記載のコンピュータ可読ストレージ媒体。
【請求項４】
処理デバイスとメモリとを含む装置であって、
前記メモリがオペレーティングシステム（ＯＳ）命令を含み、該ＯＳ命令は、複数のＯＳサービスを、前記ＯＳによって定義された複数のアプリケーションプログラミングインターフェース（ＡＰＩ）を通して、呼び出し側アプリケーションプログラムに提供するように、前記処理デバイスを構成し、
前記装置が、前記処理デバイスの環境から周囲の視覚及び／又は音の刺激を検知するためであり、且つ、それに対応するコンテンツデータを作り出すための、検知システムをさらに含み、
前記ＯＳサービスのうち１つが、
前記作り出されたコンテンツデータからコンテンツ識別データを導出することと、
メッセージキューをサブスクライブする複数のアプリケーションプログラムによってアクセスするための前記メッセージキューに前記コンテンツ識別データをパブリッシュすることと、
を実行する、装置。
【発明の詳細な説明】
【関連出願データ】
【０００１】
米国において、本出願は、以下の仮出願、
・２０１０年１１月４日出願の米国特許仮出願第６１／４１０２１７号、
・２０１１年３月４日出願の米国特許仮出願第６１／４４９５２９号、
・２０１１年３月２５日出願の米国特許仮出願第６１／４６７８６２号、
・２０１１年４月４日出願の米国特許仮出願第６１／４７１６５１号、
・２０１１年４月２６日出願の米国特許仮出願第６１／４７９３２３号、
・２０１１年５月６日出願の米国特許仮出願第６１／４８３５５５号、
・２０１１年５月１３日出願の米国特許仮出願第６１／４８５８８８号、
・２０１１年６月２７日出願の米国特許仮出願第６１／５０１６０２号の優先権を主張し、
また、以下の各出願、
・２０１１年６月３０日出願の米国特許出願第１３／１７４２５８号、
・２０１１年８月１１日出願の米国特許出願第１３／２０７８４１号、及び
・２０１１年１０月２１日出願の米国特許出願第１３／２７８９４９号の一部継続出願でもある。
これらの出願の開示は、それらの全体として参照により本明細書に組み込まれる。
【技術分野】
【０００２】
本技術は、一般には、主に、スマートフォン及びタブレットコンピュータなど、センサを装備した消費者電子デバイスに関する。
【序論】
【０００３】
本明細書は、様々な異なる目的を果たすために、長期間にわたって集められた多様な技術を詳述する。しかも、多様な技術は、様々な方法で互いに関係し、連携して使用されうることが多く、そのため、この単一の文書では集合的に提示される。
【０００４】
この多様な、相互に関係する主題は、簡単な提示に役立つものではない。したがって、この話は時折、種々雑多な話題及び技術の中で、非線形的な方式で進むので、読者の寛大さが求められる。
【０００５】
詳細な技術は、以前の米国特許出願において詳述された研究を基礎とする。これらの特許出願には、以下の出願、
・２０１１年５月３１日出願の米国特許出願第１３／１４９３３４号、
・２０１１年４月１５日出願の米国特許出願第１３／０８８２５９号、
・２０１１年４月４日出願の米国特許出願第１３／０７９３２７号、
・２０１１年１月２１日出願の米国特許出願第１３／０１１６１８号（米国特許出願公開第２０１１／０２１２７１７号として公開）、
・２０１０年６月９日出願の米国特許出願第１２／７９７５０３号（米国特許出願公開第２０１１／０１６１０７６号として公開）、
・２０１０年５月５日出願の米国特許出願第１２／７７４５１２号、
・２０１０年３月３日出願の米国特許出願第１２／７１６９０８号（米国特許出願公開第２０１０／０２２８６３２号として公開）、
・２００９年６月２４日出願の米国特許出願第１２／４９０９８０号（米国特許出願公開第２０１０／０２０５６２８号として公開）、
・２００８年１１月１４日出願の米国特許出願第１２／２７１７７２号（米国特許出願公開第２０１０／０１１９２０８号として公開）、
・２００７年１月８日出願の米国特許出願第１１／６２０９９９号（米国特許出願公開第２００７／０１８５８４０号として公開）、
・米国特許第７００３７３１号、及び
・米国特許第６９４７５７１号
が含まれる。
【０００６】
ポータブルコンピューティングデバイス（例えば、スマートフォン、音楽プレイヤ、及び、タブレットコンピュータ）は、発表から数年間で、目新しいものからほぼ必需品へと移り変わってきた。ポータブルコンピューティングデバイスの広範囲に及ぶ採用で、そのようなプラットフォームに使用可能なソフトウェアプログラム（「アプリ」）の数が急増してきた。３００，０００を越えるアプリが、現在、アップル（Ａｐｐｌｅ）アイチューンズ（ｉＴｕｎｅｓ）ストアのみから入手可能である。
【０００７】
多数のアプリは、メディアコンテンツに関する。一部のアプリは、オーディオ又はビデオコンテンツ、例えば、テレビショーのオンデマンド再生を提供するように設計される。他のアプリは、特別コンテンツ（舞台裏のクリップ、出演者の経歴及びインタビュー、コンテスト、ゲーム、レシピ、ハウツーもののビデオ）へのアクセスを可能にすることによって、ソーシャルネットワークベースの機能（ツイッター（Ｔｗｉｔｔｅｒ）、フェイスブック（Ｆａｃｅｂｏｏｋ）及びフォースクエア（Ｆｏｕｒｓｑｕａｒｅ）、ブログによるものを含む、他のファンとコミュニケーションを取ること）、その他などを可能にすることによって、メディアコンテンツを補足する役目を果たす。場合によっては、メディア関連アプリは、オーディオ又はビデオコンテンツと同期して動作し、例えば、コンテンツ及びリンクを、コンテンツ中の時間又はイベントの適切な点で提示することがある。
【０００８】
アプリは、現在、特定の放送及び記録されたメディアコンテンツに特化されている。ＡＢＣテレビショーのマイ・ジェネレーション（Ｍｙ  Ｇｅｎｅｒａｔｉｏｎ）は、例えば、番組のみの専用のコンパニオンアイパッド（ｉＰａｄ）アプリで導入され−投票、クイズ及び他の情報を、同期化された方式で提供した。ＣＮＮ、ＥＳＰＮ、ＣＢＳ、その他など、従来のメディア企業も同様に、次第にアプリ企業になりつつある。
【０００９】
アプリがこの込み合った市場において魅力を得ることは、困難である。アイチューンズ及び他のアプリストアを検索することは、ユーザが自分のデバイスのための新しいアプリを発見する、最も一般的な技法である。次に普及している、アプリ発見のための技法は、友人からの推奨によるものである。両方の手法は、しかし、アプリ市場がはるかに小さかったときに確立されたものであり、十分に比例してきていない。
【００１０】
マイ・ジェネレーションのアイパッドアプリの場合、例えば、ショーのプロデューサは、対象の視聴者に働きかけ、アプリストアへ行くように誘わなければならず、アプリストアで、対象の視聴者は、アプリのタイトルを入力し、アプリをダウンロードし、インストールし、次いで、テレビ番組が放送中であるとき、アプリを実行しなければならない。
【００１１】
本技術のある実施形態によれば、異なる解決策が提供される。１つのそのような実施形態では、マイクロフォンを装備したユーザデバイスは、周囲のコンテンツをサンプリングし、コンテンツ識別データを、取り込まれたオーディオから作り出す。このコンテンツ識別データが次いで使用されて、コンテンツの所有者によって推奨されたアプリが調べられ、そのアプリが次いでインストール及び起動され−ユーザによるアクションは、ほとんど又は全く必要とされない。
【００１２】
そのような構成によって、コンテンツは、アプリを有効に選択する。ユーザは、ソフトウェアを選択せず、ユーザのアクティビティが、ソフトウェアを選択する。時間とともに、各ユーザデバイスは、アプリによりユーザのコンテンツプリファレンスに適合されるようになり−それにより、コンテンツの世界におけるユーザの特定の関心に合わせて最適化されるようになる。
【００１３】
ある程度まで、本技術のこの態様は、アプリを除いて、ティーボ（ＴｉＶｏ）の推奨機能に類似している。ユーザのコンテンツ消費習慣（及び、任意選択で、ユーザのソーシャルネットワークの友人のコンテンツ消費習慣）は、ユーザの関心に役立つアプリを推奨するように、デバイスを導く。
【００１４】
アーティスト自身の創造的な作品によって呼び出されるべきアプリ（複数可）を指定する特権が与えられるのは、アーティストであることが望ましい。多数の国々には、アーティスト自身の作品が扱われる際の完全性（いわゆる「人格権」）へのアーティストの継続的な権利を認める法律がある。本技術の実施形態は、この権利に役立ち、アーティストに、自分のアートがどのように提示されるかにおいて継続的な役割をもたらし、アーティストが、自分の作品がそれにより体験されるべきである好ましい機構を規定できるようにする。継続性が、アーティストの意図とアートの配信との間でもたらされる。
【００１５】
この方式で扱われうるものは、スタンドアロンアプリのみではない。メディアプレイヤ（例えば、ウィンドウズ（Ｗｉｎｄｏｗｓ）メディアプレイヤ（Ｍｅｄｉａ  Ｐｌａｙｅｒ））によって使用されるべき特定のレンダリングコーデックの選択など、より粒度の細かいソフトウェア選択を、同様に行うことができる。例えば、ナショナルホッケーリーグ（Ｎａｔｉｏｎａｌ  Ｈｏｃｋｅｙ  Ｌｅａｇｕｅ）は、そのコンテンツが、最大フレームレートに合わせて設計されたコーデックでレンダリングされることを好むことがある。対照的に、フードネットワーク（Ｆｏｏｄ  Ｎｅｔｗｏｒｋ）は、そのコンテンツが、最も実際どおりの色忠実度に合わせて最適化されたコーデックでレンダリングされることを好むことがある。
【００１６】
歴史的に見て、「チャネル」が王様であり、コンテンツは、サポートする役割（つまり、消費者をチャネルへ、及び、その広告へ引き寄せる）を果たした。消費者の見地からは、しかし、これらの役割が逆転されるべきであり、すなわち、コンテンツが主たるものであるべきである。本技術の実施形態は、この前提に基づいている。ユーザがコンテンツを選び、配信機構が次いで、結果として後に続く。
【００１７】
本技術の前述及び他の特徴及び利点は、以下の詳細な説明からより容易に明らかとなり、詳細な説明は、添付の図面を参照して進行する。
【図面の簡単な説明】
【００１８】
【図１】本技術のある実施形態において使用されうるシステムのブロック図である。
【図２】図１の実施形態とともに使用されうるデータ構造の表現である。
【図３】例えば、テキスト入力のための、例示的な視線追跡（ｇａｚｅ−ｔｒａｃｋｉｎｇ）実施形態の特徴を詳述する図である。
【図４】例えば、テキスト入力のための、例示的な視線追跡（ｇａｚｅ−ｔｒａｃｋｉｎｇ）実施形態の特徴を詳述する図である。
【図５】例えば、テキスト入力のための、例示的な視線追跡（ｇａｚｅ−ｔｒａｃｋｉｎｇ）実施形態の特徴を詳述する図である。
【図６】例えば、テキスト入力のための、例示的な視線追跡（ｇａｚｅ−ｔｒａｃｋｉｎｇ）実施形態の特徴を詳述する図である。
【図７】例えば、テキスト入力のための、例示的な視線追跡（ｇａｚｅ−ｔｒａｃｋｉｎｇ）実施形態の特徴を詳述する図である。
【図８】例示的ユーザインターフェースの特徴を詳述する図である。
【図９】例示的ユーザインターフェースの特徴を詳述する図である。
【図１０】本技術の原理を組み込んだシステムのブロック図を示す図である。
【図１１】空間周波数ドメイン内のマーカ信号を示す図である。
【図１２】本技術の一態様による、図１１のマーカ信号を含む印刷物の混合ドメインビューを示す図である。
【図１３】非表示データを指示するために使用されうる角のマーカを示す図である。
【図１４】図１１のマーカ信号の代替物を示す図である。
【図１５】スマートフォンカメラから出力されたデータのグラフ表現を示す図である。
【図１６】オブジェクト認識のためのミドルウェアアーキテクチャを示す図である。
【図１７】図１６に類似しているが、特にディジマーク（Ｄｉｇｉｍａｒｃ）ディスカバー（Ｄｉｓｃｏｖｅｒ）実装形態に類似している図である。
【図１８】システムタスクに対する、画像ウォーターマークを読み取る影響を示す棒グラフである。
【図１９】アップルアイフォン（ｉＰｈｏｎｅ）４デバイス上で実行するウォーターマーク認識エージェントの性能をさらに詳述する図である。
【図２０】第１及び第２の画像フレーム内の顕著点（ｓａｌｉｅｎｔ  ｐｏｉｎｔｓ）のロケーションを示す図である。
【図２１】２つの顕著点のフレームの幾何学的位置合わせに関連付けられたヒストグラムを示す図である。
【図２２】それぞれ８ビット深度の３色ビットプレーンを含む、スマートフォン内の画像メモリを示す図である。
【図２３】同様のスマートフォンメモリであるが、ここではＲＤＦトリプルを格納するために利用されるスマートフォンメモリを示す図である。
【図２４】図２３のメモリに格納されうる数百又は数千のＲＤＦトリプルのうち、いくつかを示す図である。
【図２５】ここでは、人々の間のある関係を詳述する例示的ＲＤＦ情報がポピュレートされる、図２３のメモリを示す図である。
【図２６】描かれたＲＤＦトリプルにおいてセマンティックな推論を行うために、図２５のメモリの述部プレーンに適用されうる、テンプレートのいくつかを示す図である。
【図２７】メモリの３×３ピクセルブロック内で９個のＲＤＦトリプルを命名する図である。
【図２８】スマートフォン内のメモリのストアを示す図である。
【図２９Ａ】図２８のメモリからデータを使用する、グラフィカルユーザインターフェースの要素を描く図である。
【図２９Ｂ】図２８のメモリからデータを使用する、グラフィカルユーザインターフェースの要素を描く図である。
【図３０】ユーザへの検索クエリレポートの生成において使用されるデータを生成するための、トリプルを格納するメモリと、関連付けられたテーブルとの使用を示す図である。
【図３１】整数（例えば、８ビット）ストレージのより多くのプレーンのうち、４つを描く、スマートフォン内のメモリの別のストアを示す図である。
【図３２】ステガノグラフィ的にデジタルウォーターマークの存在を信号伝達する、独特のグラフィック効果を有する、カタログページから取り込まれた画像を表示するスマートフォンを示す図である。
【図３３】表示の縁部に沿って提示され、表示内の異なる項目に関連付けられるタグを、スマートフォンがどのように発生させることができるかを示す図である。
【図３４】表示の縁部に沿って提示され、表示内の異なる項目に関連付けられるタグを、スマートフォンがどのように発生させることができるかを示す図である。
【図３５】ウォーターマークにより識別されたカタログページに関する、データベースから取得された情報（つまり、オブジェクト形状のためのオブジェクトハンドル）を示す図である。
【図３６】画像の異なる領域内の異なるウォーターマークの検出が、どのようにユーザに信号伝達されうるかを示す図である。
【図３８】高帯域幅及び低帯域幅チャネルの両方を組み込んだ、ＬＥＤベースの通信システムを示す図である。
【詳細な説明】
【００１９】
本技術は、いくつかの点で、譲受人の上記で詳述した特許出願において詳述された技術を拡大する。読者は、本技術の実装形態において使用されうる（且つ、本技術が組み込まれうる）、そのような以前の研究に精通していると推定される。
【００２０】
図１を参照すると、例示的システム１２は、プロセッサ１６と、メモリ１８と、１つ又は複数の入力周辺機器２０と、１つ又は複数の出力周辺機器２２とを有する、デバイス１４を含む。システム１２はまた、ネットワーク接続２４、及び、１つ又は複数のリモートコンピュータ２６をも含んでもよい。
【００２１】
例示的デバイス１４は、スマートフォン又はタブレットコンピュータであるが、任意の他の消費者電子デバイスが使用されうる。プロセッサは、アトム（Ａｔｏｍ）又はＡ４デバイスなど、マイクロプロセッサを含んでもよい。プロセッサの動作は、オペレーティングシステムソフトウェア、アプリケーションソフトウェア（例えば、「アプリ」）、データ、その他など、メモリ内に格納された情報によって、部分的に制御される。メモリは、フラッシュメモリ、ハードドライブ、その他を含んでもよい。
【００２２】
入力周辺機器２０には、カメラ及び／又はマイクロフォンが含まれうる。周辺機器（又は、デバイス１４自体）はまた、それにより、カメラ／マイクロフォンによってサンプリングされたアナログ信号が、システムによる処理に適したデジタルデータに変換される、インターフェースシステムをも備えてもよい。他の入力周辺機器には、タッチスクリーン、キーボード、その他が含まれうる。出力周辺機器２２には、表示画面、スピーカ、その他が含まれうる。
【００２３】
ネットワーク接続２４は、ワイヤード（例えば、イーサネット（Ｅｔｈｅｒｎｅｔ）、その他）、ワイヤレス（ＷｉＦｉ、４Ｇ、ブルートゥース（Ｂｌｕｅｔｏｏｔｈ）、その他）、又は両方であってもよい。
【００２４】
例示的動作では、デバイス１４は、デジタルコンテンツデータのセットを、マイクロフォン２０及びインターフェースを通して、ネットワーク接続２４を通して、又はそれ以外などで受信する。コンテンツデータは、いかなるタイプのものであってもよく、オーディオは例示的である。
【００２５】
システム１２は、デジタルコンテンツデータを処理して、対応する識別データを生成する。このことは、例えば、デジタルウォーターマーク復号処理、又は、フィンガープリンティングアルゴリズムを、−望ましくは、いわゆる「アウトオブバンド」データ（例えば、ファイル名、ヘッダデータ、その他）にではなく、音又は視覚の情報自体を表すデータに−適用することによって、行われうる。結果として生じる識別データは、受信されたコンテンツデータを、同じタイプの他のデータ（例えば、他のオーディオ又は他のビデオ）とは区別する役目を果たす。
【００２６】
この識別データを参照して、システムは、呼び出されるべき対応するソフトウェアを決定する。このことを行うための１つの方法は、識別データにより、テーブル、データベース、又は他のデータ構造をインデックス付けして、それにより、適切なソフトウェアを識別する情報を得ることによる。例示的テーブルを、図２で概念的に示す。
【００２７】
場合によっては、データ構造は、単一のソフトウェアプログラムの識別を返すことがある。その場合、このソフトウェアが−使用可能であれば−起動される。（可用性は、ソフトウェアがデバイス上に常駐することを必要としない。クラウドベースのアプリが使用可能であってもよい。）使用可能でない場合、ソフトウェアは、（例えば、アイチューンズストアなど、オンラインリポジトリから）ダウンロードされ、インストールされ、起動されてもよい。（又は、デバイスは、アプリのソフトウェアアズサービス（ｓｏｆｔｗａｒｅ−ａｓ−ｓｅｒｖｉｃｅ）クラウドバージョンをサブスクライブすることができる。）そのようなアクション（複数可）におけるユーザの関与は、特定の実装形態によって決まることがあり、つまり、時々、ユーザは許可を求められ、他の実装形態では、そのようなアクションは、ユーザに迷惑をかけることなく進行する。
【００２８】
時々、データ構造は、いくつかの異なるソフトウェアプログラムを識別することがある。異なるプログラムは、異なるプラットフォームに特有のものであることがあり、その場合、デバイス１２は単に、プラットフォーム（例えば、アンドロイド（Ａｎｄｒｏｉｄ）Ｇ２、アイフォン４、その他）に対応するプログラムを見つけ出してもよい。又は、データ構造は、所与のプラットフォーム上で使用されうる、いくつかの代替プログラムを識別してもよい。この状況では、デバイスは、どれが−もしあれば−既にインストールされ、使用可能であるかを決定するために、チェックしてもよい。そのようなプログラムが発見される場合、起動されうる。２つのそのようなプログラムが発見される場合、デバイスは、アルゴリズム（例えば、直近に使用された、最小のメモリフットプリント、その他）を使用して、２つのそのようなプログラムの間で選んでもよく、又は、デバイスは、ユーザに選択を促してもよい。代替プログラムのいずれも、デバイスにとって使用可能でない場合、デバイスは、−再びアルゴリズムを使用して、又は、ユーザからの入力に基づいて−プログラムを選択及びダウンロードすることができる。ダウンロード及びインストールされると、アプリケーションが起動される。
【００２９】
（時々、データ構造は、異なる機能をサービスする異なるプログラム−すべてがコンテンツに関係付けられる−を識別することがある。１つは、例えば、歌詞の発見のためのアプリでありうる。別の１つは、音楽家の経歴に関するアプリでありうる。別の１つは、コンテンツの購買のためのアプリでありうる。ここでも、各異なるクラスのソフトウェアには、いくつかの代替物が含まれうる。）
【００３０】
デバイスは、受信されたコンテンツと連動するため（例えば、ＭＰＥＧ４又はＭＰ３ファイルをレンダリングするため）に技術的に適している、インストール済みのアプリケーションを既に有していることがあることに留意されたい。あるタイプの動作では、技術的に適している、数ダース以上のそのようなプログラムがありうる。しかし、コンテンツは、この多数の可能なソフトウェアプログラムのサブセットのみが使用されるべきであることを指示してもよい。
【００３１】
デバイス１４内のソフトウェアは、コンテンツにより識別されたソフトウェア選択を厳密に実施することがある。代替として、システムは、そのようなソフトウェア識別を、ユーザが無効にすることができるプリファレンスとして扱ってもよい。いくつかの実装形態では、ユーザには、コンテンツにより識別されたソフトウェアを使用するためのインセンティブが提供されうる。又は、反対に、ユーザは、コンテンツによって指示されたソフトウェア以外のソフトウェアを使用するために、料金又は他の障害が課されることがある。
【００３２】
時々、システムは、（例えば、適したアプリ又はハードウェア能力の欠如のために）デバイス上であるコンテンツのレンダリングを断ることがあるが、必要とされる能力を有する別のユーザデバイスへコンテンツを転送するようにユーザに勧めてもよく、そのような転送を実施してもよい。（アンセル・アダムス（Ａｎｓｅｌ  Ａｄａｍｓ）は、自分の大きいフォーマットの写真が、小さいフォーマットで低解像度のスマートフォンのディスプレイでスクリーンセーバーとして使用されることを、快く思わなかったかもしれない。そのような表示が試みられる場合、ソフトウェアは、代わりに、画像を見るために、ユーザの自宅にある大きいフォーマットのＨＤディスプレイへ転送するように、ユーザに勧めてもよい。）
【００３３】
コンテンツのレンダリングを完全に断る代わりに、システムは、制限された方式でコンテンツをレンダリングしてもよい。例えば、ビデオは、（例えば、シーン遷移からの）一連の静止キーフレームとしてレンダリングされることがある。ここでも、システムは、コンテンツをより適切に楽しむことができるところへ転送することができ、又は、ハードウェアの考慮すべき事柄が許す（例えば、画面表示解像度が適当である）場合、必要とされるソフトウェアがダウンロード及び使用されうる。
【００３４】
図２のテーブル（そのデータ構造は、メモリ１８内に、又は、リモートコンピュータシステム２６内に常駐可能である）によって示すように、ソフトウェアの指示は、−コンテンツ識別データに加えて−１つ又は複数のコンテキストの要素に基づいてもよい。（２つのコンテキスト要素のみを示すが、もちろん、より多い又はより少ないコンテキスト要素が使用可能である。）
【００３５】
「コンテキスト」の１つの形式的な定義は、「エンティティ（ユーザとアプリケーションの間のインタラクションに関連があると見なされる、人、場所又は物体であり、ユーザ及びアプリケーション自体が含まれる、の状況を特徴付けるために使用されうる任意の情報」である。
【００３６】
コンテキスト情報は、多数の種類のものであってもよく、コンピューティングコンテキスト（ネットワーク接続性、メモリ可用性、プロセッサタイプ、ＣＰＵ競合、その他）、ユーザコンテキスト（ユーザプロファイル、ロケーション、アクション、プリファレンス、近くの友人、ソーシャルネットワーク（複数可）及び状況、その他）、物理的コンテキスト（例えば、照明、雑音レベル、トラフィック、その他）、時間的コンテキスト（時刻、日、月、季節、その他）、上記の履歴、その他が含まれる。
【００３７】
図示のテーブルでは、行３２及び３４は、同じコンテンツ（すなわち、同じコンテンツＩＤ）に対応するが、−ユーザのコンテキストが屋内であるか、屋外であるかに応じて−異なるソフトウェアが使用されるべきであることを指示する。（ソフトウェアは、５シンボル１６進識別子によって指示され、コンテンツは、６個の１６進シンボルによって識別される。他の形式、及び、より長い又はより短い長さの識別子が、もちろん使用可能である。）
【００３８】
行３６は、ソフトウェアの２つの項目を含むソフトウェア選択を示し−２つの項目の両方が呼び出される。（一方は、さらなる記述子−ソフトウェア「ＦＦ２４５」によってロードされるべきであるユーチューブ（ＹｏｕＴｕｂｅ）ビデオの識別子−を含む。）このソフトウェアは、日中のコンテキストにおけるユーザに対して、及び、２０〜２５歳の年齢層のユーザに対して指示される。
【００３９】
行３８は、ユーザのロケーション（郵便番号）及び性別を、コンテキストのデータとして示す。このコンテンツ／コンテキストのためのソフトウェアは、選択的に指定される（つまり、行３６の「ＡＮＤ」とは対照的に、ともに「ＯＲ」された４つの識別子）。
【００４０】
行４０及び４２は、同じコンテンツＩＤが−デバイスプロセッサ（アトム又はＡ４）に応じて−異なるコーデックに対応できることを示す。
【００４１】
（比較の点により、コーデックが現在選ばれる手順を考えられたい。典型的には、ユーザは、競合するコーデック間の技術的な区別をよく知らず、アーティストには発言権がない。コーデック選択は、このように、選択に最も極めて重大に関心のあるいずれの当事者によっても行われない。代わりに、デフォルトのコーデックが、あるメディアレンダリングソフトウェア（例えば、ウィンドウズメディアプレイヤ）とセットになってくる。デフォルトが、あるコンテンツを扱うことができない場合、レンダリングソフトウェアは典型的には、−やはり、最も関係している当事者からの入力なしに−さらなるコーデックをダウンロードする。）
【００４２】
コンテンツによってテーブル３０内で指示されるソフトウェアは、スタンドアロンアプリ、又は、ソフトウェアコンポーネント−コーデック、ドライバ、その他など−であってもよいことは理解されよう。ソフトウェアは、コンテンツをレンダリングすることができ、又は、コンテンツコンパニオン−コンテンツに関係付けられた他の情報又は機能性を提供する−であってもよい。いくつかの実装形態では、「ソフトウェア」は、ＵＲＬ、又は、別のソフトウェアプログラム若しくはオンラインサービスに提供される他のデータ／パラメータ（例えば、ユーチューブビデオ識別子）を備えてもよい。
【００４３】
テーブル内で識別されたすべてのそのようなソフトウェアが、ソフトウェアが関連付けられるコンテンツの所有者（例えば、アーティスト、創作者又は著作権保持者）によって選ばれることが望ましい。これにより、大部分の他のデジタルコンテンツシステムに欠けている、ある程度のアートの制御権が、所有者に与えられる。（そのような事柄における所有者の制御権には、例えば、コンテンツ配給者、ＡＯＬ又はアイチューンズなど、の制御権よりも、多くの敬意が払われるべきである。同様に、所有者の選択は、デバイスのための文書処理及び表計算ソフトウェアを提供する会社の選択よりも、重要なものに値するように思われる。）
【００４４】
所有者のソフトウェアの選択は、美しさ及び技術的なメリットに基づくようになることが多い。時々、しかし、商業的に考慮すべき事柄が出てくる。（アーティストのロバート・ゲン（Ｒｏｂｅｒｔ  Ｇｅｎｎ）が言及したように、「’飢えたアーティスト’は、２０歳で受け入れられ、４０歳では怪しく、６０歳では問題がある。」）
【００４５】
したがって、例えば、ユーザのデバイスが、グループのザ・ディセンバリスツ（Ｔｈｅ  Ｄｅｃｅｍｂｅｒｉｓｔｓ）による周囲のオーディオを検出する場合、データ構造３０内でアーティストにより指定されたデータは、デバイスが、検出された音楽の購買のためにアマゾン（Ａｍａｚｏｎ）アプリをロード（又は、対応するアマゾンウェブページをロード）して、販売を誘導するべきであることを指示してもよい。同じデバイスが、レッド・ホット・チリ・ペッパーズ（Ｒｅｄ  Ｈｏｔ  Ｃｈｉｌｉ  Ｐｅｐｐｅｒｓ）による周囲のオーディオを検出する場合、そのグループは、同じ目的で、デバイスがバンド自体のウェブページ（又は、別のアプリ）をロードするべきであると指定していてもよい。所有者は、このようにして、コンテンツオブジェクト指向の商取引のためのフルフィルメントサービスを指定することができる。
【００４６】
いくつかの構成では、飢えたアーティストの問題は、オークション構成によって最も良く軽減されうる。つまり、デバイス１４（又は、リモートコンピュータシステム２６）は、ある人口統計プロファイル／コンテキスト情報が使用可能でありうるユーザのアイポッド（ｉＰｏｄ）が映画のアバター（Ａｖａｔａｒ）のサウンドトラックを検出したことを、オンラインサービス（グーグル（Ｇｏｏｇｌｅ）アドワーズ（ＡｄＷｏｒｄｓ）に類似のもの）に発表してもよい。ミニオークションが、次いで、購入機会をユーザに提示する特権をめぐって、結果として起こることがある。勝者（例えば、イーベイ（ＥＢａｙ））は次いで、落札金額を口座に支払い、口座から落札金額が、オークションサービス、アーティスト、その他で分配される。ユーザのデバイスは、ユーザが１本の映画、そのサウンドトラック又は関連商品を購入できるイーベイアプリを起動することによって、応答する。そのようなコンテンツ検出イベント、及び、関連付けられたコンテキスト情報を、クラウドベースのサービスにプッシュすることは、応答の十分な競争市場を可能にすることができる。
【００４７】
（オークション技術はまた、譲受人の以前に引用した特許出願において、並びに、グーグルの米国特許出願公開第２０１０／０１７２９８号及び第２００９／１９８６０７号においても詳述されている。）
【００４８】
コンテンツの人気は、関連付けられたソフトウェアが同様に人気になることにつながる可能性がある。このことは、自分たちのコンテンツとともに使用するためにそのようなソフトウェアを検討するように、他のコンテンツ所有者を誘導する可能性があり、その理由は、そのソフトウェアの幅広い展開により、消費者が他の所有者のコンテンツにさらされることが容易になりうるからである。
【００４９】
例えば、ユニバーサル・ミュージック・グループ（Ｕｎｉｖｅｒｓａｌ  Ｍｕｓｉｃ  Ｇｒｏｕｐ）は、ＦＦｍｐｅｇ  ＭＰ３プレイヤが好ましいレンダリングソフトウェアとして識別されるようにする識別子により、すべての自社の曲にデジタルウォーターマーキングしてもよい。ＵＭＧアーティストの熱心なファンは、すぐに推奨ソフトウェアをインストールし−そのようなソフトウェアが多数の消費者デバイス上に展開されることにつながる。他の音楽所有者が、テーブル３０内で何のソフトウェアを指定すべきかを検討するとき、広く行き渡ったＦＦｍｐｅｇ  ＭＰ３ソフトウェアの使用は、他の音楽所有者が選ぶ際に熟考する要素の１つでありうる。
【００５０】
（テーブル３０内で指示されたソフトウェアは、曲のリリースサイクルの過程を通してなど、経時的に変更されてもよい。新しいバンドが曲を出すとき、テーブルにより指定されたソフトウェアは、新しいバンドを世間に紹介するように意図されたアプリを含んでもよい（又は、ユーチューブクリップがこの目的のために指示されうる）。音楽の人気が出て、バンドがより良く知られるようになった後、異なるソフトウェア選択が指示されてもよい。）
【００５１】
現在、音楽発見及び他のコンテンツ関連アプリケーションは、一般に、アプリケーションソフトウェアによって行われる。オペレーティングシステム（ＯＳ）ソフトウェアは、様々な有用なサービスを提供し−サービスのいくつか（例えば、Ｉ／Ｏ）は、一般に、コンテンツ関連アプリケーション内で使用される。しかし、市販のＯＳソフトウェアは、コンテンツ処理又は識別に特有のいかなるサービスも以前に提供していない。
【００５２】
本技術のさらなる態様によれば、コンテンツ処理又は識別に特有の１つ又は複数のサービスを行うために、オペレーティングシステムソフトウェアが提供される。
【００５３】
１つの特定の実装形態では、ＯＳアプリケーションプログラミングインターフェース（ＡＰＩ）は、コンテンツデータを入力として（又は、コンテンツデータが格納されるロケーションへのポインタ）を取り、コンテンツデータに対応するフィンガープリントデータを返す。別のＯＳサービス（同じＡＰＩ又は別のＡＰＩを使用して提供される）は、同じ入力を取り、コンテンツデータから復号されたウォーターマーク情報を返す。（ＡＰＩへの入力パラメータは、複数のフィンガープリント又はウォーターマーク処理のうちどれが適用されるべきであるかを指定することができる。代替として、サービスは、いくつかの異なるウォーターマーク及び／又はフィンガープリント抽出処理を入力データに適用し、結果として生じる情報を呼び出し側のプログラムへ返してもよい。ウォーターマーク抽出の場合、結果として生じる情報は、エラー訂正データなどを参照することによって、明らかな有効性についてチェックされうる。）
【００５４】
同じＡＰＩ又は別のＡＰＩは、抽出されたフィンガープリント／ウォーターマークデータをさらに処理して、コンテンツに関連付けられるＸＭＬベースのコンテンツメタデータ（例えば、作品のタイトル、アーティストの名前、著作権保持者、その他を与えるテキスト）を得ることができる。このことを行うために、同じＡＰＩ又は別のＡＰＩは、グレースノート（Ｇｒａｃｅｎｏｔｅ）によって維持されたものなど、リモートメタデータレジストリを調べてもよい。
【００５５】
そのようなコンテンツ処理ＡＰＩは、フィンガープリント／ウォーターマーク抽出処理の結果（文字通りに、又は、対応するメタデータのいずれか）がパブリッシュされる先のメッセージキュー（例えば、「リスニング／ヒアリングキュー）を確立することができる。１つ又は複数のアプリケーションプログラムは、−ある識別子を求めてリッスンしながら−キューを監視（フック）することができる。あるアプリは、ビートルズ（Ｂｅａｔｌｅｓ）による音楽へのアラートであってもよい。別のアプリは、ディズニー（Ｄｉｓｎｅｙ）映画のサウンドトラックを求めてリスニングしてもよい。そのようなコンテンツが検出されるとき、監視アプリ、又は、別のアプリ、は、アクティビティ−イベントのロギング、メディアコンテンツを補足するように作動すること、購入機会の提供、その他−に取りかかることができる。
【００５６】
代替として、そのような機能性は、オペレーティングシステムから離れて実装可能である。１つの手法は、パブリッシュ／サブスクライブモデル（出版／購読型モデル）によるものであり、パブリッシュ／サブスクライブモデルによって、いくつかのアプリが能力（例えば、特定のタイプのオーディオを求めてリスニングすること）をパブリッシュし、他のアプリがそのような機能をサブスクライブする。これらの構成によって、疎結合アプリケーションが協働して、同様のエコシステムを可能にすることができる。
【００５７】
本技術の１つの適用例は、ユーザがさらされるメディアを−バックグラウンド処理として−監視することである。つまり、シャザム（Ｓｈａｚａｍ）など、曲識別サービスとは異なり、ユーザは、発見動作を開始して、特定の曲のアイデンティティを知るために、いかなるアクションを取る必要もない。（もちろん、ユーザは、ある時点で、デバイスをオンにし、このバックグラウンド機能性を認可しなければならない。）代わりに、デバイスは、ユーザの一日の流れの中で、延長された期間（シャザムのようなサービスの１０〜１５秒よりもはるかに長い）にわたってリスニングする。コンテンツに遭遇すると、コンテンツが処理及び認識される。認識情報は、デバイス内にロギングされ、−次回にユーザの注目がデバイスの方に向くときに使用可能な−そのようなコンテンツにさらされることを反映するために、あるソフトウェアを用意するために使用される。
【００５８】
例えば、デバイスは、周囲のオーディオを、１５分間、１時間、又は１日にわたって処理してもよい。ユーザが次にデバイスとインタラクトするとき、デバイスは、ユーザがさらされてきたコンテンツのリストを提示してもよい。ユーザは、関心のあるコンテンツを求めてリストをタッチして、発見動作に参加するように勧められてもよい。このコンテンツに関連付けられたソフトウェアが、次いで起動する。
【００５９】
いくつかの実装形態では、デバイスは、ソフトウェアアプリケーションを、コンテンツ識別データに少なくとも部分的に基づく情報により、用意することができる。この用意は、例えば、ユーチューブアプリに、ユーザが聞いた曲の音楽ビデオに対応するサムネイルを示す−サムネイルを選択のために準備する−ようにさせてもよい。同様に、９０秒のサンプルオーディオクリップが、アイポッド音楽プレイヤアプリにダウンロードされ−「最近の遭遇（Ｒｅｃｅｎｔ  Ｅｎｃｏｕｎｔｅｒｓ）」フォルダ内で使用可能にされてもよい。バンドからの電子メールが、ユーザの電子メールのインボックスに追加されてもよく、トリビアゲームアプリが、バンドに関する一連の質問をロードしてもよい。そのようなデータは、ローカルに常駐しており（つまり、ユーザは、例えば、ウェブサイトから、そのようなデータの取得を指図する必要がない）、対応するアプリが次に使用されるとき、情報がユーザにとって顕著であり−それにより、ユーザのコンテンツ体験ごとにこれらのアプリをカスタマイズする。
【００６０】
ソーシャルメディアアプリケーションは、そのような情報が提示及び共有されるプラットフォームとしての役目を果たすことができる。ユーザがフェイスブックアプリをアクティベートするとき、例えば、アバターが「あなたが今日、以下のものを体験したことに気付きました．．．」という挨拶をして、次いで、例えば、ディセンバリスツによる「ビリー・ライアー（Ｂｉｌｌｙ  Ｌｉａｒ）」、ダンディ・ウォーホルズ（Ｄａｎｄｙ  Ｗａｒｈｏｌｓ）による「ボーイズ・ベター（Ｂｏｙｓ  Ｂｅｔｔｅｒ）」、及び、ナイキ（Ｎｉｋｅ）の新しいレブロン・ジェームズ（ＬｅＢｒｏｎ  Ｊａｍｅｓ）のコマーシャルなど、ユーザがさらされたコンテンツをリストしてもよい。アプリは、各々に遭遇した際のコンテキストをユーザに思い出させてもよく、例えば、２０１０年１１月４日にポートランドのダウンタウンを通って歩いている間（例えば、デバイス内のＧＰＳ及び加速度計センサによって決定される）などである。フェイスブックアプリは、このコンテンツのいずれかを友人と共有するように、ユーザに勧めることができる。フェイスブックアプリは、ユーザがバンドのいずれかのディスコグラフィーを望むかどうか、又は、コンテンツのフルデジタルコピーを望むか、いずれかに関連付けられた補足的なコンテンツに関心があるか、関連付けられたアプリ（複数可）が起動されることを望むか、その他のクエリをさらに行ってもよい。
【００６１】
アプリは同様に、（適切な許可があれば）ユーザの友人のメディア遭遇及び関連付けられたアクティビティについて、レポートしてもよい。
【００６２】
前述から、前述の実施形態のうち特定のものは、あるメディアコンテンツに関連付けられたアプリを探し出すことの、ユーザのジレンマを和らげることは理解されよう。代わりに、メディアコンテンツが、それ自体の有利なアプリを探し出す役目を果たす。
【００６３】
そのような実施形態は、アートの意図と配信の間の継続性を保証し、アートが作り出すように意図される体験を最適化する。もはや、アートの体験は、アーティストが制御権を有していない配信プラットフォーム−それ自体のために注目を求め、潜在的に、ユーザが関心のあるアートから気を散らすことがあるプラットフォーム−によって仲介されなければならないものではない。
【００６４】
この技術はまた、アプリ市場の競争をも促進し−アーティストに、どのアプリが自分たちの創作物を最良に表現するかについて、より顕著な発言権を与える。望ましくは、ダーウィン効果（Ｄａｒｗｉｎｉａｎ  ｅｆｆｅｃｔ）が現れてもよく、それにより、アプリ人気がそれほどブランディング及びマーケティング予算の表れではなくなり、より、アプリによって配信されたコンテンツの人気の反映となる。
他の構成
オブジェクトインタラクションを参照することによる、データストリームのフィルタリング／ハイライト
【００６５】
ユーザには、ますます大量のデータが提示されている。例には、数百のテレビ番組のチャネル、電子メール、及び、ＲＳＳ／ツイッター／ソーシャルネットワーク／ブログフィードが含まれる。ユーザがそのような情報の流れを扱うことを助けるために、入ってくる情報を、ユーザプロファイルデータに従ってフィルタリング又はハイライトする技術が提案されている。
【００６６】
よく知られている例は、明らかなユーザ関心に基づいて完全な電子番組ガイドのサブセットを提示する、ティーボによるものなどのＤＶＲソフトウェアである。ティーボソフトウェアは、どのテレビ番組がユーザによって見られたかに注目し、「よし（ｔｈｕｍｂｓ−ｕｐ）」又は「だめ（ｔｈｕｍｂｓ−ｄｏｗｎ）」ランキングの形式でユーザフィードバックを勧め、次いで、そのような過去の振る舞い及びランキングに基づいて、潜在的に関心のある今後の番組を提案する。
【００６７】
より最近の例は、グーグルのＧｍａｉｌ（ジーメール）サービスのための「優先トレイ（Ｐｒｉｏｒｉｔｙ  Ｉｎｂｏｘ）」である。着信電子メールが解析され、ユーザにとってのその電子メールの潜在的な重要性に従ってランク付けされる。そのような判断を行う際に、グーグルは、どのような電子メールをユーザが以前読んだか、どの電子メールにユーザが以前返信したか、及び、そのようなメールに関連付けられた送信者／キーワードを考慮する。そのような評価で高いスコアを取る着信電子メールが、メールリストの最上部に提示される。
【００６８】
Ｍｙ６ｓｅｎｓｅ．ｃｏｍという会社は、ＲＳＳ及びツイッターフィードを優先順位付けするための同様のサービスを提供する。ここでも、ソフトウェアは、データフィードとのユーザの過去のインタラクションを監視し、ユーザに最も関連があると思われる着信項目の優先度を高める。（ツイッターフィードの処理では、Ｍｙ６ｓｅｎｓｅは、ユーザがクリックしたことがあるリンク、ユーザがお気に入りのマークを付けたツイート、ユーザがリツイートしたツイート、及び、そのようなツイートを特徴付ける著者／キーワードを考慮する。）
【００６９】
そのような原理を、オブジェクトインタラクションを包含するように拡張することができる。例えば、ノードストローム（Ｎｏｒｄｓｔｒｏｍ）デパートを訪れる人が、自分のスマートフォンを使用して、一足のジミー・チュウ（Ｊｉｍｍｙ  Ｃｈｏｏ）オートバイ用ブーツの画像を取り込む場合、このことは、ファッション、又はオートバイに乗ること、又は履物、又はブーツ、又はジミー・チュウ商品、その他へのある関心を指示するように推測されうる。その人が後に自分のスマートフォンを使用して、リバー・ロード（Ｒｉｖｅｒ  Ｒｏａｄ）オートバイ用サドルバッグを撮像する場合、このことは、その人の関心が、オートバイに乗ることを含むものとして、より正確に特徴付けられうることを示唆する。それぞれの新しい画像オブジェクトが見極められるとき、その人の関心についてのより多くの情報が収集される。いくつかの初期の結論を強めることができ（例えば、オートバイに乗ること）、他の仮説を度外視することができる。
【００７０】
画像内のオブジェクトを認識することに加えて、解析（クラウドソーシングによって人が見直すことを含みうる）もまた、アクティビティを見極めることができる。ロケーションも、気付くことができる（画像から推測されるか、又は、ＧＰＳデータなどによって指示される）。
【００７１】
例えば、画像のフレームに適用された画像解析は、画像のフレームが、オートバイに乗っている人を含み、バックグラウンドとしてテント及び森林設定を有すると決定することがある。又は、一連の時間の画像内で、１つの画像が、オートバイに乗っている人を含むことが発見されることがあり、数分後に撮影された別の画像が、以前のフレームのオートバイの運転手と同じ服装の人−ここでは森林設定内でテントの隣に描かれている−を含むことが発見されることがあり、数分後に撮影された別の画像が、森林のバックグラウンドで運転されているオートバイを描くことが発見されることがある。ＧＰＳデータは、画像のすべてをイエローストーン国立公園（Ｙｅｌｌｏｗｓｔｏｎｅ  Ｎａｔｉｏｎａｌ  Ｐａｒｋ）内で位置指定することがある。
【００７２】
そのような履歴の情報（経時的に累積されたもの）は、ユーザにとって関心のある被写体、アクティビティ、人々、及び場所を指示する、度重なるテーマ及びパターンを明らかにすることができる。それぞれのそのような結論に、属性がユーザの関心を正確に特徴付けるというシステムの信頼度に基づいて、信頼メトリックを与えることができる。（今挙げた例では、「オートバイに乗る」は、「ジミー・チュウ商品」よりも高いスコアを取るようになる。）そのようなデータは次いで、ユーザのデバイスに提示される上述のデータ（及び他のもの）のフィードのフィルタリング又はハイライトにおいて使用されうる。
【００７３】
デバイス使用の履歴が編集されるとき、ユーザによる世界とのインタラクションを強化するために使用されうる、関心及びメディア消費パターンの総合的な履歴が現れる。例えば、ユーザが、セフォラ（Ｓｅｐｈｏｒａ）のファッションアクセサリを撮像する場合、ユーザの迷惑メールフィルタを制御するパラメータが修正されて、その会社からの電子メール−そうでない場合はブロックされていたかもしれない電子メール−の配信が可能にされてもよい。ユーザのウェブブラウザ（例えば、スマートフォンのサファリ（Ｓａｆａｒｉ）、ホームＰＣのファイアーフォックス（Ｆｉｒｅｆｏｘ））は、ティーボが番組提案で行うことと同様に、セフォラのウェブページを「お気に入りの提案（Ｓｕｇｇｅｓｔｅｄ  Ｆａｖｏｒｉｔｅｓ）」のリストに追加してもよい。
【００７４】
ユーザは、ツイッターアカウントを確立することを選択してもよく、該アカウントは、ユーザのオブジェクトにより導出されたプロファイルによって本質的に所有される。このツイッターアカウントは、ユーザが最近検知したオブジェクトに関するツイートをフォローする。ユーザがキャノン（Ｃａｎｏｎ）ＳＬＲカメラを撮像した場合、この関心は、プロファイル関連のツイッターアカウントに反映可能であり、プロファイル関連のツイッターアカウントは、そのような被写体に関するツイートをフォローすることができる。このアカウントは次いで、ユーザがユーザ自身のツイッターアカウントからフォローするか、又は、定期的にチェックすることができるフィードに、そのような投稿をリツイートすることができる。
【００７５】
そのようなオブジェクトにより導出されたプロファイル情報を、スマートフォン、テレビ、ＰＣ及び他のコンテンツ配信デバイスを介してユーザに配信されるコンテンツの選択に影響を与えることを越えることに、使用することができる。そのようなオブジェクトにより導出されたプロファイル情報はまた、そのようなコンテンツの構成に影響を与えることもできる。例えば、ユーザがインタラクトするオブジェクトは、ユーザの消費のためにメディアマッシュアップに含まれうる。ユーザがしばしば訪れる仮想現実ゲームの世界の主人公は、ジミー・チュウのオートバイ用ブーツを履いていてもよい。対戦相手から獲得した宝物には、キャノンＳＬＲカメラが含まれていてもよい。
【００７６】
ユーザがオブジェクトとインタラクトするたびに、このインタラクションを、ツイッター、フェイスブック、その他を介してパブリッシュすることができる（ユーザの許可及びパラメータの共有を必要とする）。これらの通信はまた、フォースクエアの意味における「チェックイン」であると考えることもできるが、この場合、ロケーションのためではなく、オブジェクト又はメディアタイプ（音楽、ＴＶ、その他）のためである。
【００７７】
これらの公の声明に基づいて、ソーシャルフレームワークが出現することが可能である。１９８０年代から手作りのベルギーのレース用自転車に関心のある人々（人々がそのような自転車の画像を取り込むことによって証明される）は、例えば、ツイッター若しくはフェイスブック（又は、ツイッター若しくはフェイスブックの後継）上で、アフィニティソーシャルグループに合体することができる。オブジェクトベースのコミュニティは、このようにして、関心のあるユーザによって定義及び探求されうる。
【００７８】
ソーシャルネットワーク理論家は、このことがソーシャルネットワーク解析の一形式であるが、ノードが物理的オブジェクトを表すことを、理解するであろう。
【００７９】
ソーシャルネットワーク解析は、ネットワーク理論を使用して、関係を見るものであり、ネットワーク理論において、ネットワークは、ノード及びタイ（ｔｉｅ）（エッジ、リンク又は接続と呼ばれることがある）を備える。ノードは、ネットワーク内の個々の行為者であり、タイは、行為者間の関係である。結果として生じるグラフベースの構造は複雑になることがあり、ノード間に多数の種類のタイがあることがある。今挙げた場合では、関係タイには、「好き」、「所有」、その他が含まれうる。
【００８０】
特定の３Ｄグラフは、人々のオブジェクトを１つの平面に入れ、物理的オブジェクトを、平行な平面に入れてもよい。２つの平面間のリンクは、人々を、人々が所有するか又は好きであるオブジェクトに関連付ける。（デフォルトの関係は、「好き」であってもよい。「所有」は、コンテキストから推測されてもよく、又は、他のデータから導き出されてもよい。例えば、ユーザによって写真に撮られ、ユーザの居住地でジオロケートされ（ｇｅｏｌｏｃａｔｅｄ）たカマロ（Ｃａｍａｒｏ）自動車は、「所有」関係を指示することがある。同様に、その車がユーザに登録されることを指示する、公的データベースにおけるカマロナンバープレートの検索もまた、「所有」関係を示唆する。）
【００８１】
そのようなグラフはまた、典型的には、（ソーシャルネットワークグラフにおいて通常あるように）人々のオブジェクト間のリンクをも含むようになり、また、物理的オブジェクト間のリンクをも含みうる。（１つのそのようなリンクは、物理的近接の関係である。駐車場内で隣り合って駐車された２台の車は、そのような関係によってリンクされうる。）
【００８２】
そのようなネットワーク内の物理的オブジェクトへのリンクの数は、そのネットワーク内のオブジェクトの相対的重要性を指示するものである。２つの異なる物理的オブジェクト間の関連度は、２つの異なる物理的オブジェクトをリンクするネットワークパス（複数可）の長さによって指示可能であり−より短いパスは、より近い関連度を指示する。
【００８３】
いくつかのオブジェクトは、ユーザにとって一時的に関心のあるものでありうるが、他のオブジェクトは、長い期間にわたって関心のあるものでありうる。ユーザが、特定のタイプのオブジェクトを一度だけ撮像する場合、そのオブジェクトは、前者のクラスに属する可能性が高い。ユーザが、そのようなオブジェクトタイプの画像を経時的に繰り返し取り込む場合、そのようなオブジェクトタイプは、後者のクラスに属する可能性がより高い。プロファイルデータに基づく決定は、オブジェクトにより指示された関心が古くなることを考慮に入れることができるので、１年前に一度遭遇したオブジェクトに、より最近遭遇したオブジェクトと同じ重みが与えられないようにする。例えば、システムは、キャノンＳＬＲベースのツイートを１日、１週間、又は１カ月のみフォローし、次いで、ユーザによって撮像された他のオブジェクトがキャノンの機器又はＳＬＲカメラへの継続的な関心を証明しない限り、もはやフォローされないようにしてもよい。各オブジェクト関心に、そのタイプのオブジェクトとの度重なる遭遇によって増加又は維持されるが、そうでない場合は経時的に減少する、数値のプロファイルスコアを割り当てることができる。このスコアは次いで、コンテンツの扱いにおいて、そのオブジェクト関連の関心に重み付けするために使用される。
【００８４】
（詳述した構成は、取り込まれた画像データの解析によって物理的オブジェクトを識別したが、ユーザがインタラクトするオブジェクトは、そのようなオブジェクトに関連付けられたＲＦＩＤ／ＮＦＣチップの検出によるなど、他の方法で識別可能であることは理解されよう。）
【００８５】
上記で詳述したものに類似した原理及び実施形態を、音楽及び音声認識を含む、ユーザのオーディオ環境の解析に適用することができる。そのような情報は、ユーザ（例えば、ユーザデバイス）に提示されるか、及び／又は、ユーザ（ユーザデバイス）によって送られうる、データのストリームの選択及び構成に、同様に適用されうる。さらにより大きい有用性が、ユーザデバイスセンサによって取り込まれた視覚及び聴覚刺激の両方の検討によってもたらされうる。
テキスト入力
【００８６】
スマートフォンの前面カメラを使用して、視線追跡モードでテキスト入力の速度を速めることができる。
【００８７】
ユーザに連続して表示画面上の３つ又は４つの既知の位置を見させると同時に、スマートフォンカメラ１０１を使用して両目のうち一方の凝視を監視することによって、基本的な幾何学的な参照フレームが最初に確立されうる。図３では、ユーザは、連続して点Ａ、Ｂ、Ｃ及びＤを見る。このサイクルを繰り返すことによって、正確さの向上が達成されうる。（読者は、視線追跡システムの原理に精通していると推定されるので、ここでは同じことを長々と論じない。システムの例は、例えば、特許公報の２０１１００１３００７、２０１００３１５４８２、２０１００２９５７７４、及び、２００５０１７５２１８、並びに、本明細書中で引用された参考文献に詳述されている。）
【００８８】
システムが、ユーザの目の凝視及びデバイス画面に関係する幾何学的なフレームワークを決定すると、ユーザは、表示されたキーボード１０２上で最初の文字を凝視することによって、最初の文字を指示することができる。（画面をより十分に使用する他のキーボード表示を、もちろん使用することができる。）ユーザは、凝視された文字の選択を、ジェスチャー、例えば、目のまばたき、又は、スマートフォン本体（若しくは、スマートフォン本体が置いてある机の上）のタップなど、信号によって示すことができる。テキストが選択されるとき、テキストは、メッセージエリア１０３に追加される。
【００８９】
最初の文字（例えば、「Ｎ」）が提示されると、可能性が高い次の文字を画面の拡大文字メニュー部分１０４に提示することによって、データ入力の速度を速めることができる（また、視線追跡をより正確にすることができる）。文字が入力されるたびに、可能性が高い次の文字のメニュー（例えば、代表的なコーパスにおける文字の対の頻度分析によって決定される）が提示される。一例を図４に示し、図４では、メニューは、六角形配列のタイルの形式を取る（が、もちろん、他の構成を使用することができる）。
【００９０】
この例では、ユーザは、テキスト「Ｎｏｗ  ｉｓ  ｔｈｅ  ｔｉｍｅ  ｆｏｒ  ａ＿（今こそ〜のときである）」を既に入力しており、システムは、下線１０６が指示されるところに入れるべき文字をユーザが選択することを、待機中である。選択された最後の文字は、「ａ」であった。この文字は、ここで−グレー表示のフォーマットで−中央のタイルに表示され、様々なオプション−「ａｎ」、「ａｔ」、「ａｌ」及び「ａｒ」を含む−に囲まれている。これらのオプションは、「ａ」で始まる４つの最も一般的な文字の対である。同じく、指示された六角形配列内に表示されるものは、「−−」選択タイル１０８（次のシンボルがスペースであるべきであることを指示する）、及び、キーボード選択タイル１１０である。
【００９１】
次の文字「ｌ」を入力するため、ユーザは単に、「ａｌ」表示タイル１１２を見て、上記のようにタップ又は他のジェスチャーによって承認を示す。システムは次いで、図５に示すように、画面を更新する。ここでは、メッセージが１文字だけ長くされており（「Ｎｏｗ  ｉｓ  ｔｈｅ  ｔｉｍｅ  ｆｏｒ  ａｌ＿」）、メニュー１０４は、文字「ｌ」で始まる最も一般的な文字の対を示すように更新されている。デバイスは、次の文字入力を求める。もう１つの「ｌ」を入力するために、ユーザは、「ｌｌ」タイル１１４を凝視し、ジェスチャーをする。
【００９２】
初期の研究は、テキスト入力の５０％をはるかに上回るものが、可能性が高い次の文字（に加えて、スペース）の拡大文字メニューによって達成されうることを示唆している。異なる文字が必要とされる場合、ユーザは単に、キーボードタイル１１０を凝視し、ジェスチャーをするだけである。キーボード−図３に示すようなもの、又は別のもの−が現れ、ユーザはキーボードから選択を行う。
【００９３】
図２及び図３に示すように、４つの文字の対、スペース、及び、キーボードアイコンを提示する代わりに、代替実施形態は、図６に示すように、５つの文字の対、及び、スペースを提示する。この構成では、キーボードが常に画面上に表示されているので、ユーザは、図４のキーボードタイル１１０を選択する中間ステップなしに、文字をキーボードから選択できるようになる。
【００９４】
通常のキーボード表示１０２の代わりに、変形例のキーボード表示１０２ａ−図７に示す−を使用することができる。このレイアウトは、５つの文字が、表示されたキーボード上で必要とされないという事実を反映し、その理由は、５つの最も可能性が高い文字が六角形のメニュー内に既に提示されているからである。図示の例では、５つのキーが完全に省略されるのではなく、むしろ、極小のキーが与えられる。２１個の残りの文字には、特大のキーが与えられる。そのような構成は、ユーザによるキーボードからの文字選択の速度を速め、残りのキーの視線追跡をより正確にする。（５つの文字キーがキーボードから完全に省略される、さらなる変形例もまた使用可能である。）
【００９５】
図７の変形例のキーボードレイアウト１０２ａは、通常のスペースバーを省略することにも留意されたい。スペースシンボルのための拡大メニュータイル１１６があるので、キーボード１０２ａ内でスペースバーは必要とされない。図示の構成では、このエリアは、一般的な句読シンボルで置き換えられている。
【００９６】
多数の代替物及び拡張が実装可能であることは、当業者には理解されよう。例えば、最後の文字が六角形の中央に表示されることは必要ではない。このスペースは空いたままにすることができ、又は、代わりに、ユーザの現在の凝視によって明らかに指示された次の文字を指示するために使用することができるので、ユーザは、ジェスチャーして確認する前に選択をチェックできるようになる。（明らかに指示された文字で更新されるとき、中央のタイルを凝視することで、以前の凝視ベースの選択を変更しない。）数字パッドを、−図４のキーボードタイル１１０のような−数字パッドアイコンの選択によって、画面に呼び出すことができる。又は、数字キーボードを、（図６のキーボード１０２のように）メッセージ構成動作の全体を通して画面上に表示することができる。六角形のタイルのうち１つ又は複数は、ユーザが入力中の完全な語の推量を−ここでもテキストコーパスの解析に基づいて−提示することができる。
【００９７】
最も一般的な文字の対と、完全な語の推量とを決定するために使用されるコーパスは、ユーザによりカスタマイズ可能であり、例えば、ユーザによって書かれた、又は、ユーザのデバイスから送られた、すべてのテキスト及び／又は電子メールメッセージの履歴のアーカイブである。指示された表示の特徴は、当然、使用されているスマートフォン機能性（例えば、テキストメッセージングアプリケーション）に関連付けられた、他のグラフィカルなしるし及びコントロールによって拡張可能である。
【００９８】
さらに他の実施形態では、ユーザは、−印刷されたページ上など−スマートフォンのディスプレイから離れて提示されたシンボル及び語から選択してもよい。大きいスケールの完全なキーボード及び完全な数字パッドを、そのようなページ上に提示し、単独で、又は、メニュー１０４のような、表示された文字メニューとともに使用することができる。（ここでも、スマートフォンカメラを使用して、視線追跡を行うことができ、ユーザに基準点を凝視させることによって、幾何学的な較正を行うことができる。）
手話
【００９９】
スマートフォンがユーザの目を見て、動きを解釈することができることと全く同じように、スマートフォンは同様に、ユーザの手のジェスチャーを見て、解釈することもできる。結果は、手話インタプリタである。
【０１００】
手話（アメリカ及びイギリスの手話が最も優勢である）は、様々な要素を備え−その要素のすべてを、カメラによって取り込み、適した画像解析ソフトウェアによって識別することができる。サインは典型的には、手型（ｈａｎｄｆｏｒｍ）及び向きの態様を含み、ロケーション（又は、調音の位置）及び動きによっても特徴付けられうる。手話用アルファベット（指文字）ジェスチャーは同様であり、主に、固有名詞及び他の特殊な語彙のために採用される。
【０１０１】
例示的手話解析モジュールは、大部分の肌の色合いに関連付けられた全域内のクロミナンスを有する連続的なピクセルのセットを識別することによって、スマートフォンにより取り込まれた画像を関心領域に区分する。このようにして区分された画像は次いで、手の構成（複数可）を参照手型のデータベースライブラリ内の最良のマッチとマッチングしようと努める分類エンジンに適用される。同様に、画像フレームのシーケンスが処理されて、手型内の動きの異なる点と、経時的な向きの変化とを指示する、動きベクトルが見極められる。これらの見極められた動きは、同様に、参照の動き及び変化のデータベースに適用されて、最良のマッチが識別される。
【０１０２】
マッチするサインがデータベース内で発見されるとき、見極められたサインに関連付けられたテキストの意味が、データベースレコードから取得され、−語、音素又は文字として−スマートフォンの表示画面など、出力デバイスに出力されうる。
【０１０３】
データベースからの最良マッチデータは、生の形式で出力されないことが望ましい。データベースは、サインごとに候補マッチのセットを識別し−各々が信頼メトリックを有することが好ましい。システムソフトウェアは次いで、どのような組み合わせの語、音素又は文字が、その連続コンテキスト内にある可能性が最も高いかを検討し−可能なマッチの異なる信頼度に重みを与え、語のスペリングを詳述する参照データベース（例えば、辞書）を参照し、頻繁に手話で使われる語の対及びトリプルを識別する。（同様の技法は、音声認識システムにおいて−無意味な語句を出力する見込みを減らすために−使用されることは、当業者には理解されよう。）
【０１０４】
認識ソフトウェアはまた、トレーニングによって恩恵を受けることもできる。ユーザが、正しくない解釈がシステムによってサインに与えられたことに気付く場合、ユーザは、以前のサインが再解釈のために繰り返されるようになることを指示する、サインを出すことができる。ユーザは次いで、このサインを繰り返す。システムは次いで、代替解釈を提供し−（システムの推測が正しくなかった）以前の解釈を避ける。この処理は、システムが正しい解釈（親指を立てるジェスチャーなど、ユーザのサインにより承認されうる）で応答するまで、繰り返されてもよい。システムは次いで、システムの参照サインのデータベースに、今表現されたサインを−正しい意味と関連して−追加することができる。
【０１０５】
同様に、システムがサインを解釈し、ユーザがその解釈を疑わない場合、取り込まれたサイン画像についてのデータを、参照データベースに、−その解釈と関連して−追加することができる。この構成によって、システムは、あるサインの様々な提示を認識することを学習する。同じ技法は、システムがユーザ特有の日常語及び他の特異な表現法を認識するように、経時的にトレーニングされることを可能にする。
【０１０６】
マシン認識を支援するため、標準的な手話を拡張して、画像解析ソフトウェアに、理解を支援するようになるある較正又は参照情報を与えることができる。例えば、スマートフォンに対してサインを出すとき、ユーザは、外向きの手のひらから指及び親指を広げ（数字「５」の典型的なサイン）、次いで、指を握りこぶしに戻すなどのジェスチャーから始めてもよい。これにより、スマートフォンは、ユーザの肌色（ｆｌｅｓｈｔｏｎｅ）のクロミナンスを識別し、ユーザの手及び指のスケールを決定できるようになる。同じジェスチャー又は別のジェスチャーを使用して、−文の終わりのピリオドのように−概念を分離することができる。（そのような句読は一般に、アメリカの信号語において、小休止によって表現される。ジェスチャーがないことよりも、明白な手のジェスチャーの方が、マシンビジョンベースの手話解釈にとって、より信頼できる構文解析要素である。）
【０１０７】
述べたように、解釈された手話を、スマートフォン表示上でテキストとして出力することができる。しかし、他の構成もまた実装可能である。例えば、テキストを単に（例えば、アスキー（ＡＳＣＩＩ）又はワード（Ｗｏｒｄ）文書に）格納することができ、又は、テキストから音声への変換器を通して出力して、可聴音声を生じることができる。同様に、テキストは、翻訳ルーチン又はサービス（例えば、グーグル翻訳）に入力されて、別の言語に変換されてもよく−別の言語で格納、表示又は発話されてもよい。
【０１０８】
スマートフォンは、その近接センサを採用して、ユーザの身体の一部分（例えば、手）の接近を検出し、次いで、カメラ画像のフレームを取り込み、肌の色合いのクロミナンス及び長いエッジ（又は、手及び／若しくは指の特性を示す他の属性）についてチェックしてもよい。そのような解析が、ユーザが手を電話の方へ動かしたと結論付ける場合、電話は、その手話翻訳機をアクティベートしてもよい。関連して、アップルのフェイスタイム（ＦａｃｅＴｉｍｅ）通信ソフトウェアは、ユーザが電話のカメラによって撮像されるように手を位置決めするとき、手話翻訳機をアクティベートするように構成されうる。その後、ユーザの手のジェスチャーに対するテキスト対応物を、テキスト表示、テキストから音声への変換、その他によってなど、電話がつなげられる相手（複数可）に通信することができる。
ストリーミングモード検出器
【０１０９】
この技術の別の態様によれば、スマートフォンは、複数のオブジェクトから識別を迅速に取り込み、識別をのちに見直すために使用可能にするように装備される。
【０１１０】
図８は、一例を示す。アプリケーションは、カメラから（すなわち、通常のビューファインダーモード）のストリーミングビデオにより更新される、大きい表示ウィンドウを含む。ユーザがカメラをパンするとき、システムは、画像を解析して、いずれかの識別可能なオブジェクトを見極める。図８では、カメラの視野内に、バーコードを持ついくつかのオブジェクトがある。
【０１１１】
図示のシステムでは、プロセッサは、中央で開始して画像フレームを解析し−識別可能な特徴を探す。（他の構成では、トップダウン又は他の画像検索手順に従うことができる。）電話が識別可能な特徴（例えば、バーコード１１８）を発見するとき、電話は、角括弧１２０を特徴の周りにオーバーレイするか、又は、特徴をハイライトして、ユーザに対し、表示された画像の何の部分が電話の注意を引いたかを指示する。「シューッ」という音が次いで、デバイスのスピーカから発せられ、アニメのしるしが、画面の角括弧が付いた部分から底部の履歴１２２ボタンへと動く。（アニメーションは、履歴ボタンで１ポイント下につぶれる正方形のグラフィックであってもよい。）履歴ボタンの隣に表示される、赤い円で囲まれたカウンタ１２４は、デバイス履歴内でこのようにして検出及び配置された項目の数（この場合、７）を指示する。
【０１１２】
バーコード１１８をこのようにして処理した後、システムは、他の認識可能な特徴を求めて、その視野の解析を継続する。中央から解決しながら、システムは次にバーコード１２６を認識し、同様の動作のシーケンスが後に続く。カウンタ１２４は、「８」に増分される。システムは次に、バーコード１２８に−部分的にカメラの視野の外側にあるにもかかわらず−気付く。（あるバーコードの冗長符号化は、そのような復号を可能にする。）３つのバーコードからデータを認識し、関連付けられたユーザフィードバック（サウンド及びアニメーション効果）とともにデバイス履歴に取り込むために経過した時間は、３秒未満である（１秒又は２秒が典型的である）。
【０１１３】
履歴ボタン１２２をタップすることによって、以前に取り込まれた特徴のスクロール可能な表示が、図９に示すように提示される。このリストでは、各エントリは、認識された特徴のタイプを指示するグラフィカルなしるしを、特徴から見極められた情報、及び、特徴が検出された時間とともに含む。（この時間は、絶対的な方式で、又は、現在時間に相対的に示されてもよく、後者を図９に示す。）
【０１１４】
図９に示すように、システムによって検出される特徴は、カメラデータ内で発見される必要はない。特徴には、オーディオ（例えば、話している人の識別）から、又は他のセンサから見極められた特徴が含まれうる。図９は、電話が、データを近距離無線チップ（ｎｅａｒ  ｆｉｅｌｄ  ｃｈｉｐ）（例えば、ＲＦＩＤチップ）−「ＮＦＣ」のしるしによって指示される−からも検知したことを示す。
【０１１５】
後で、ユーザは、この履歴リストを呼び戻し、関心のあるしるしをタップすることができる。電話は次いで、その特徴に対応する応答を開始することによって（又は、いくつかの使用可能な特徴のメニューを提示し、メニューからユーザが選択できるようにすることによって）、応答する。
【０１１６】
時々、ユーザは、詳述したストリーミングモード動作をオフにすることを望むことがあり、例えば、環境に検出可能な特徴が豊富にあり、ユーザが複数の取り込みを望まないときである。アプリケーションＵＩのボタンコントロール１３０は、そのような機能性のオン及びオフを切り替える。示した状態では、複数の特徴の検出が可能にされる。ユーザがこのコントロールをタップする場合、そのしるしは「複数がオフ」に切り替わる。電話がこのモードで特徴を検出するとき、システムは、（前述のように）その特徴を履歴に追加し、対応する応答を直ちに開始する。例えば、システムは、ウェブブラウザ機能性を呼び出し、検出された特徴に対応するウェブページをロードしてもよい。
証拠ベースのステートマシン、及び、ブラックボードベースのシステム
【０１１７】
本技術の別の態様は、スマートフォンベースのステートマシンを含み、スマートフォンベースのステートマシンは、センサ入力に応答してその動作を変化させる。
【０１１８】
米国特許出願第１２／７９７５０３号は、ブラックボードデータ構造が、データをシステムコンポーネント間で渡すためにどのように使用されるかについて、詳述している。以下の説明は、例示的実施形態についてのさらなる情報を提供する。
【０１１９】
この例示的システムでは、物理センサ及び論理センサの両方がある。物理センサは、センサを監視し、センサからのデータをブラックボードへ供給する。スマートフォンのカメラ及びマイクロフォンは、特定のタイプの物理センサであり、一般に「メディアセンサ」と呼ばれることがある。いくつかのセンサが、いくつかのタイプのデータを出力することがある。例えば、画像センサは、ピクセルデータのフレーム、及び、ＡＧＣ（自動利得制御）信号をも出力することがある。
【０１２０】
論理センサは、データを−典型的にはブラックボードから−得て、さらなるデータを計算するために使用する。このさらなるデータもまた、一般にブラックボードに戻すように格納される。（米国特許出願第１２／７９３５０３号で論じられた認識エージェントは、論理センサの例である。もう１つは、推測エンジンである。）場合によっては、同じ物理的データが、処理中に複数の段階の論理センサ精緻化を通過してもよい。
【０１２１】
メディアコンテンツを作り出すか、又は消費するモジュールは、例えば、他のモジュールとのフォーマットネゴシエーションを可能にするために、ある特殊な機能性を必要とすることがある。このことには、認識エージェントに対して、その要求されたフォーマット（例えば、関連付けられたパラメータとともに、オーディオ又はビデオ）についてクエリを行い、次いで、対応するセンサデータをブラックボードから得ることが含まれうる。
【０１２２】
以下に、取り込まれた画像からデジタルウォーターマークを読み取るための、例示的な６段階の物理センサ／論理センサデータフローを詳述するテーブルが続く（ＲｅａｄＩｍａｇｅＷａｔｅｒｍａｒｋシナリオ）。格納されたデータの列は、ブラックボード内の格納されたデータの名前を与える。（ＭＳはメディアセンサの略であり、ＰＳは物理センサの略であり、ＬＳは論理センサの略であり、ＲＡは認識エージェントの略である。）
【表１】
0006054870.tif 000002
【０１２３】
最初の２行は単に、ビデオデータのフレームと、関連付けられたＡＧＣデータ（例えば、フレームの全域の平均輝度値でありうる）とが、カメラからブラックボードへ書き込まれることを指示する。３行目は、関連付けられたハンドセットの動きデータ−スマートフォンの加速度計システムによって検知されたもの−もまた、ブラックボードに書き込まれることを示す。
【０１２４】
４行目で、テーブルは、以前にブラックボードに格納されたＤａｔａ＿Ｆｒａｍｅデータが画像分類器（様々な論理センサ）に適用され、結果として、ブラックボード内に格納される分類データが生じることを指示する。（分類データは、様々な種類のものでありうる。分類データの１つのタイプは、色の彩度である。フレームが極めて低い色の彩度を有する場合、このことは、フレームがカラーのシーンではなく、白いバックグラウンド上に印刷されたテキスト、又はバーコードである可能性がより高いことを指示する。例示的データフローは、シーンが印刷されたテキスト又はバーコードである可能性が高いことをＤａｔａ＿Ｃｌａｓｓｉｆｉｃａｔｉｏｎデータが指示する場合、ウォーターマーク検出器をアクティベートしないようになるが−他の実装形態では、ウォーターマークが、白黒又はグレースケールの画像から読み取られてもよい。別の分類器は、発話された音声と音楽とを区別し、例えば、発話されたオーディオが入力されるとき、曲認識処理が実行しないようにする。）
【０１２５】
５行目は、今導出された分類データが、ＡＧＣ及び加速度計データとともに、ブラックボードから呼び戻され、ウォーターマーク推測モジュール（別の論理センサ）に適用されて、フレーム品質メトリックが生じ、フレーム品質メトリックがブラックボードに書き戻されることを指示する。ウォーターマーク推測モジュールは、入力データを使用して、フレームが、ウォーターマーク（ある場合）が復号可能な品質のものであるという見込みを推定する。例えば、フレームが極めて暗いか、又は極めて淡いことを、ＡＧＣ信号が指示する場合、ウォーターマークが回復可能であることは、ありそうもないことである。画像のフレームが取り込まれたとき、スマートフォンが加速されていることを、加速度計データが指示する場合も、上記と同じである。（加速度計データは典型的には、重力について補償される。）低い彩度のデータのセットであることを、分類器が指示する場合も、同様である。
【０１２６】
６行目は、今決定されたフレーム品質メトリックが、−取り込まれた画像のフレームとともに−ウォーターマークリーダ（認識エージェント）に提供されることを示す。フレーム品質が閾値を超える場合、ウォーターマークリーダは、画像からウォーターマークを復号するように試みるようになる。そのような試みの結果は、ＲｅａｄＲｅｓｕｌｔデータに格納され（例えば、「１」は、ウォーターマークの復号に成功したことを指示し、「０」は、ウォーターマークが発見されなかったことを指示する）、復号されたウォーターマークペイロード−ある場合−は、ＷＭ＿ＩＤとして格納される。
【０１２７】
（別の実施形態では、フレーム品質メトリックが閾値を超える場合にウォーターマーク復号器を条件付きで呼び出す代わりに、このメトリックを、ウォーターマーク復号器の動作を−システムコンテキストに基づいて−動的に制御する優先度値として、使用することができる。システムが他の動作で忙しい場合、又は、他のコンテキスト−充電など−により、復号動作のコストが高くなる場合、低品質メトリックを有するフレームは、ウォーターマーク処理をされないようになり、より高い優先度の処理からシステムリソースを流用しないようにする。）
【０１２８】
例示的システムでは、インストールされたモジュールは、構成ファイル内で列挙される。これらのモジュールは、インスタンス化及びランタイムの使用のために使用可能である。構成ファイルはまた、１つ又は複数のシナリオ（例えば、ＲｅａｄＩｍａｇｅＷａｔｅｒｍａｒｋ−上記で詳述したようなもの−、及び、ＦｉｎｇｅｒｐｒｉｎｔＡｕｄｉｏ）をも詳述し−各々は、そのシナリオのために使用されるべきであるモジュールの集まりを指定する。ランタイムで、アプリケーションは、呼び出すべき特定のシナリオ（複数可）を指定するミドルウェアを初期化する。ミドルウェア構成、及びシナリオは、典型的には、ＸＭＬ構成ファイルからロードされる。
【０１２９】
例示的システムは、Ｃ／Ｃ＋＋で（例えば、ビジュアルスタジオ（Ｖｉｓｕａｌ  Ｓｔｕｄｉｏ）２０１０を使用して）コーディングされ、図１０に示すアーキテクチャに従う。ミドルウェア−ブラックボードを、イベントコントローラ及びミドルウェアステートマシンとともに備える−は、動的リンクライブラリ（ＤＬＬ）で実装される。
【０１３０】
当業者にはよく知られているように、図１０のシステムは、異なるシステムコンポーネントが通信する標準化されたインターフェースを採用する。特に、システムアプリケーション（上）とミドルウェアの間の通信は、ＡＰＩを通して実施され、ＡＰＩは、関数呼び出しを開始及びサービスするための取り決め／プロトコルを定義する。同様に、センサモジュール（典型的には、ミドルウェアによってランタイムに動的にロードされるＤＬＬとして実装される）は、サービスプロバイダインターフェース（ＳＰＩ）を通してミドルウェアと通信する。
【０１３１】
図示のブラックボードは、様々な方法でデータを格納することができ、例えば、キー値の対、ＸＭＬ、オントロジー、その他である。例示的ブラックボードは、データをキー値の対として格納し、キー値の対には、プッシュ及びプルＡＰＩを使用してアクセスされる。並行処理制御は、悲観的なロッキング−データが別の処理によって使用中である間、処理がデータにアクセスすることを妨げること−によって処理される。ブラックボードデータタイプには、個別のデータ要素（例えば、整数及び文字列）に加えて、データブロブ（ｂｌｏｂ）が含まれる。
【０１３２】
データ値自体に加えて、各データエントリは、関連付けられたデータのいくつかの項目（メタデータ）を有する。これらの項目には、以下が含まれる。
・名前
・ソース（エントリを作成したモジュールの名前）
・値
・データタイプ
・データサイズ
・参照カウント
・タイムスタンプ（最後の更新時間）
・寿命（この値がどのくらい長く有用であるか）
・品質（この値がどのくらい確実であるか）
【０１３３】
ブラックボードに格納される値は、以下の代表的なデータタイプのものである。
・ビデオフレーム
・ビデオ統計値（フレームレート、ＡＧＣ、焦点距離、その他）
・加速度計データ
・ＷＭ読み取り結果
・ＷＭ  ＩＤ
・ビデオ分類結果
【０１３４】
データは、ＡＰＩ及びＳＰＩの両方によってサポートされる関数を通して、ブラックボードに書き込まれ、ブラックボードから読み取られる。そのような関数は、当業者にはよく知られており、以下が含まれる（括弧付きのものは、ＡＰＩ／ＳＰＩ呼び出しの一部として渡される値を示す）。
・ＢＢ＿ＣｒｅａｔｅＥｎｔｒｙ（名前、ソース、タイプ、サイズ）、ハンドルを返す
・ＢＢ＿ＯｐｅｎＥｎｔｒｙ（名前）、ハンドルを返す
・ＢＢ＿ＧｅｔＥｎｔｒｙＮａｍｅｓ（ソース、バッファ）
・ＢＢ＿ＧｅｔＥｎｔｒｙＩｎｆｏ（名前、ソース、情報）
・ＢＢ＿ＧｅｔＥｎｔｒｙＩｎｆｏ（ハンドル、情報）
・ＢＢ＿ＧｅｔＶａｌｕｅ（ハンドル、値）
・ＢＢ＿ＳｅｔＶａｌｕｅ（ハンドル、値）
・ＢＢ＿ＣｌｏｓｅＥｎｔｒｙ（ハンドル）
【０１３５】
上記で詳述したデータタイプに加えて、モジュールは、共通の名前付きエントリのセットを使用して、ステータス情報をブラックボードにパブリッシュする。各名前は、接頭辞＋「＿」＋モジュール名というパターンを使用することによって作成される。接頭辞には、以下が含まれる。
・Ｓｔａｔｕｓ（数値ステータスコード）
・Ｅｒｒｏｒ（最後のエラーについてのエラー文字列）
・Ｒｅｓｕｌｔ（直近の動作の数値結果コード）
【０１３６】
ＡＰＩ及びＳＰＩ関数にはまた、Ｉｎｉｔｉａｌｉｚｅ、Ｕｎｉｎｉｔｉａｌｉｚｅ、ＬｏａｄＳｃｅｎａｒｉｏ、Ｓｔａｒｔ、Ｓｔｏｐ及びＰａｕｓｅもが含まれ、これらの関数を通して、関連のあるＤＬＬが初期化され（又は、初期化されず）、異なるシナリオが構成され、開始／停止／一時停止される。
【０１３７】
図１０のミドルウェアのイベントコントローラモジュールは、異なるＳＰＩの様々な優先度、処理の複雑さ、及び処理頻度に対処する。例えば、画像ウォーターマーク復号器ＲＡは、プロセッサ集中的であるが、個別のフレーム上で動作するので、他のＳＰＩが実行する時間を必要とする場合、フレームを無視できるようになる。（例えば、ＷａｔｅｒｍａｒｋＩｍａｇｅＲｅａｄシナリオを画像のストリーム、すなわち、ビデオストリーム上で行う際に、様々なフレームを落とすことができ−それにより、実行を使用可能なリソースに合わせてスケールし、システムが停滞されるようになることを防ぐ）。対照的に、オーディオウォーターマーク復号器ＲＡは、よりプロセッサ集中的ではない可能性があるが、中断されないストリーム内でオーディオデータを処理する必要がある。つまり、オーディオデータのストリームが使用可能であるとき、オーディオウォーターマークＲＡは、他のＳＰＩに優先するべきである。複数のメディアストリーム（例えば、オーディオ及びストリーミング画像）が存在し、他のＲＡが処理に関与するとき、イベントコントローラは、画像の高品質のフレームが使用可能である場合、オーディオ処理を定期的に中断して、画像処理を可能にしてもよい。
【０１３８】
各モジュールは、モジュールの優先度の必要性及び制限、実行頻度、その他についての情報を詳述する、データ構造を含むことが望ましい。そのような構造のデータのサンプルは、以下の通りである。
・名前
・タイプ（ＰＳ、ＭＳ、ＬＳ、ＲＡ）
・優先度（低−高、例えば、２〜１０ステップによる）
・消費されたブラックボードデータ値
・作り出されたブラックボードデータ値
【０１３９】
モジュール及びアプリケーションはさらに、ブラックボードトリガ関数を、対応するトリガ値（又は、トリガ値範囲）とともに出すことができ、それにより、ブラックボード内のあるデータがトリガ値基準を満たすとき、ミドルウェア（例えば、ブラックボード又はイベントコントローラ）に、そのようなモジュール／アプリケーションに対して通知／メッセージを出させる。１つのそのようなトリガは、ＲｅａｄＩｍａｇｅＷａｔｅｒｍａｒｋ動作が、ウォーターマーク読み取りの成功を表す「１」のＲｅａｄＲｅｓｕｌｔ値を返す場合である。別のトリガは、音楽認識モジュールが、テレビショーのグレイズ・アナトミー（Ｇｒｅｙ’ｓ  Ａｎａｔｏｍｙ）のテーマ音楽を識別する場合である。そのような関数によって、モジュール／アプリケーションは、ブラックボード上のあるデータの存在のアラートが出されるまで、休止状態のままでいることができる。
【０１４０】
前述の構成によって、センサの各々は、データ及びステータス情報をブラックボードへパブリッシュすることができ、この情報は、他のモジュールによって、及び、異なるアプリケーションによって、取得及び使用することができ、他のモジュール及び異なるアプリケーションは次に、それぞれの結果をブラックボードへパブリッシュすることは理解されよう。そのような反復処理を通して、単一の物理センサからの生データが、他の情報とともに連続して処理及び拡張され、推論されて、極めて複雑な動作が行われうる。ＲｅａｄＩｍａｇｅＷａｔｅｒｍａｒｋは、そのようなシステムが可能にする多面的な処理の簡単な例である。
さらにミドルウェア、その他について
【０１４１】
図１６は、メディア及び物理的オブジェクト認識のためのミドルウェアの別のアーキテクチャの図である。この柔軟なアーキテクチャを使用して、より多くのコンテキストの情報をアプリケーションに配信することもできる。この設計は、ブラックボード、センサバンク、認識エージェント（ＲＡ）バンク、推測エンジン、及び、イベントコントローラを含む。
【０１４２】
述べたように、ブラックボードは、アーキテクチャの中心にある。ブラックボードは、システムコンポーネントが通信する共有リポジトリである。直接通信は典型的には、他のいかなるシステムコンポーネント間でも可能にされない。例示的ブラックボードは、実質的に別々のセクションに構築され、各セクションは、所与のタイプのデータ専用である。例えば、オーディオデータのための１つのセクション、及び、画像のための別のセクションがある。
【０１４３】
センサバンクは、入力をブラックボードに提供し、カメラ、マイクロフォン、加速度計、ジャイロスコープ、周囲光センサ、ＧＰＳ、その他が含まれてもよい。ＲＡバンクには、画像及びオーディオウォーターマークリーダ、フィンガープリントリーダ、バーコードリーダ、その他が含まれてもよい。各センサ及びＲＡは、その割り当てられたタスクを達成するコストと、その結果の品質とを推定するための、プライベートの知識ベースを含む。このことは、拡張可能性をサポートし、システムの他のコンポーネントへの影響なしに、センサ又はＲＡを追加又は除去できるようにする。
【０１４４】
イベントコントローラは、システムの全体的な動作を調整する。推測エンジンは、ブラックボードのコンテンツを監視し、コンテキストのデータを推測して、センサ及びＲＡバンク内のリソースの使用を最適化する。推測エンジンは、推測されたデータをブラックボードに書き込む。
【０１４５】
最小数のセンサが、典型的には、入力をブラックボードに提供するためにアクティブである。いずれかのコンポーネントから入力があると、ブラックボードは、変更をすべてのコンポーネントへ信号伝達してもよい。各センサ及びＲＡは次いで、検出されたオブジェクトのアイデンティティの解決を助けることができるかどうかを評価する。センサは、関連のある、より正確なデータを提供することによって、アイデンティティの解決を助けることができる。センサ又はＲＡは、その知識ベースを使用して、その解決策のコスト及び品質を推定し、そのデータをブラックボードに書き込む。イベントコントローラは、最適な結果を最も経済的に出すと推定されるセンサ（複数可）又はＲＡ（複数可）をアクティベートする。センサ及び推測エンジンは、ブラックボードを更新し続けて、最も適したモジュール（複数可）が常に活動中であることを保証する。システムは、オブジェクトのアイデンティティが解決されるまで、この処理を継続する。このシナリオでは、イベントコントローラは、システム内の電力及びリソースの使用を最適化する。例えば、照明レベルが不十分であるか、又は、デバイスが活発な動きをしている場合、カメラは使用されず、画像ウォーターマークリーダもバーコードリーダも、識別のために使用されない。
【０１４６】
図１７は、ディジマークディスカバーアプリケーションのミドルウェアアーキテクチャを示す。このミドルウェアアーキテクチャは、Ｃ／Ｃ＋＋及びアセンブリ言語で実装され、アイフォン及びアンドロイドプラットフォームに合わせて最適化される。ディジマークディスカバーアプリケーションは、デジタルウォーターマーク、バーコード、及び、オーディオフィンガープリントのためのＲＡを統合する。
【０１４７】
図１７に描かれたアーキテクチャと、図１６に示されたアーキテクチャの間の主な違いは、形式的推測エンジンがないこと、及び、ブラックボードのための役割がより制限されていることである。いくつかの機構が実装されて、メディアサンプルを処理するかどうかが決定されるが、完全推測エンジンは必要とされない。また、ブラックボードは、本質的に、あるセンサデータ（加速度計、ジャイロスコープ、その他）とともに、メディアデータ（オーディオ及びビデオ）を移動するための手段として、使用される。ブラックボードは、すべての取り込まれたデータを、ＲＡのデータのサンプリングレートにかかわらず、ＲＡによる消費のために同期化され、キューに入れられたままに保つ。ＲＡが処理する準備ができているとき、ＲＡは、ブラックボード内の対応するデータキューからメディアサンプルを要求する。ブラックボードは次いで、ＲＡに、メディアデータ及び関連付けられたセンサデータを提供する。
【０１４８】
ＲＡがメディアサンプルの処理を開始するとき、ＲＡは、サンプルに添付されたセンサデータのいずれかを使用してもよい。ＲＡは最初に、サンプルを処理するかどうかを決定する。ＲＡは、正しい識別に達していることを比較的確信している場合にのみ、その識別タスクを引き受ける。そうでない場合、ＲＡは、動作を中止し、次のメディアサンプルを待機する。ＲＡは、論理センサを使用して、その識別パラメータを調整してもよい。成功した場合、ＲＡは、ミドルウェアを通して、その結果をアプリケーションへ返す。
【０１４９】
魅力的なユーザ体験を提供するために、ＲＡは、明確なオブジェクト／メディア識別における最良の機会のために、大量のデータを迅速に処理するべきである。識別にはそのような量のデータが必要であるため、オペレーティングシステムとの適切な統合が望ましい。この統合は典型的には、使用される特定のオーディオ及びビデオ取り込み処理に基づいて調整される。そのような統合がなければ、ブラックボードは、ＲＡが検出を行うために十分なデータを有していないことがあり、正しい識別を得る機会が低減される。複数のＲＡを同時に使用することは、この問題を悪化させる可能性がある。
【０１５０】
ディジマークディスカバーアプリケーションの初期の実装形態は、デモンストレーションプラットフォームとしてはかなりうまくいったが、速くはなく、容易に拡張可能ではなかった。追加の識別技術を統合することは、性能及び実装の課題を提示した。そのような状況に対処するため、２つのタイプの最適化が実装される。
【０１５１】
１つは、スマートフォンメディア取り込みサブシステムとの改善された統合による、より効率的なＯＳリソースの利用である。別の１つは、ＲＡのアイフォン特有の最適化である。これらの最適化を、以下で詳述する。
【０１５２】
アイフォンバージョンのディジマークディスカバーアプリケーションは、アップルのグランドセントラルディスパッチ（Ｇｒａｎｄ  Ｃｅｎｔｒａｌ  Ｄｉｓｐａｔｃｈ）スレッディング機能に依拠し、この機能は、低スレッドレイテンシとともにアプリケーションの大規模なマルチスレッディングを可能にする。オーディオ及びビデオストリームは、別々のスレッド内に記録され、各ＲＡは、それ自体のスレッド内で実行する。オーバーヘッドは、スレッドの数とともに目立って増大しなかった。アイフォンのシングルコアプロセッサ上でさえ、この利益は、可能性のある欠点をはるかに上回る。ＲＡ処理は一般に、オーディオ及びビデオ取り込みスレッドによって駆動されるが、このことは、使用中のＲＡのタイプに応じて変わる可能性がある。
【０１５３】
以前に述べたように、ストリーミング画像（ビデオ）識別技術（例えば、ウォーターマーク及びバーコード）と、オーディオ（例えば、ウォーターマーク及びフィンガープリント）との間に基本的な違いがあり、つまり、ビデオ技術は個々の画像を処理するが、オーディオ技術はストリームを処理するという違いである。ビデオは、アプリケーションへ、各々が完全な画像であるフレームのシーケンスとして配信される。しかし、オーディオは、生のバイトストリームのデータのブロックとして配信される。ビデオフレームは、スタンドアロンでありうるが、単一のオーディオブロックは、オーディオ識別のために役に立たないことが多い。大部分のオーディオ識別技術は、識別のために少なくとも数秒（多数のブロックに相当する）のオーディオデータを必要とする。
【０１５４】
データタイプとサンプルレートの間のこの違いは、ミドルウェアアーキテクチャにおける違いを引き起こす。プロセッサの使用度が高い間、個々のビデオフレームは、ビデオＲＡのロバスト性へのごくわずかな影響により、落とされることがある。オーディオＲＡは、しかし、コンテンツを識別するために、数ブロックを必要とする。ディジマークディスカバーアプリケーションの初期の実装形態では、メディアサンプルが使用可能になったとき、ＲＡがメディアサンプルを処理したが、必ずしもオーディオでうまくいくとは限らなかった。場合によっては、オーディオ処理は、重い処理中に遅れて、遅延される結果、及び、所望の速度よりも遅いユーザインターフェースにつながる可能性があった。このことに対処するために、ディジマークディスカバーアプリケーションは、優先度システムを採用し、優先度システムでは、ミドルウェアが、フレームをスキップしても差し支えない可能性のあるＲＡを減速させると同時に、他のＲＡを全速力で実行したままに保つことによって、処理のバランスをとる。
【０１５５】
画像／ビデオフレームの処理は、最もＣＰＵ集中的なタスクの１つである。２つの別々のＲＡ（ウォーターマーク検出器及びバーコードリーダ）が、取り込まれた各画像を処理するために同時に使用されることがある。画像を調べることから１つのＲＡを除くことで、性能を著しく向上させることができる。上記で示したように、ディジマークディスカバーアプリケーションは、分類器を使用して、バーコードリーダが画像を処理するべきであるかどうかを決定する。バーコードは、ほとんど常に白黒で印刷されるので、分類器は、画像の彩度レベルを点検し、有意な量の色を持つ画像を排除する。同様に、フィンガープリントベースのグレースノート音楽認識ＲＡは、音声分類器を参照することによって制御され、それにより、マイクロフォンオーディオが音声として分類されるとき、グレースノートＲＡを呼び出すことを回避する。
【０１５６】
上記で示したように、ＩｍａｇｅＷａｔｅｒｍａｒｋＲｅａｄシナリオは、スマートフォンの加速度計からのデータを採用し−画像が過度のモーションブラーを含む可能性が高くなる場合、試みられるウォーターマーク読み取りを防ぐ。同様に、他の位置／動きセンサ、並びに、焦点距離、自動ホワイトバランス、自動利得制御、及びＩＳＯのセンサを含む、他のスマートフォン論理センサを使用して、低品質フレームを識別することができるので、スマートフォンリソースが、不十分な品質の入力の処理でむやみに消費されないようになる。
【０１５７】
我々の研究は、論理センサが、システムリソースの使用の最適化、及び、ユーザ体験を高めることを助けることを示している。同様に、ユーザコンテキスト及びデバイスコンテキストについての追加の情報を提供する論理センサは、さらにより複雑な動作を可能にする。いつ、どこで、どのように、誰によってデバイスが使用されるかについての情報は、ミドルウェアを伴うすべての決定に含まれることが望ましい。いくつかの実装形態は、コンテキストの形式的な表現、及び、人工知能ベースの推測エンジンを採用する。そのような構成では、センサ及びＲＡを、知識源と考えることができる。
【０１５８】
（いかなる論理センサも、ある意味で、推測モジュールと見なされうる。光センサは、微光を検出し、スマートフォンのコンテキストが暗やみの中であると推測することができる。そのような推測を使用して、トーチ（ｔｏｒｃｈ）を付けて照明を増す信号を出すことができる。より高度な構成は、スマートフォンにおいていくつかのモジュールを採用する。例えば、光センサが、微光を検出することがあり、マイクロフォンが、サラサラという雑音を検出することがある。システムは、スマートフォンがユーザのポケットの中にあると推測することができ、その場合、カメラのトーチをオンにすることは無意味でありうる。さらにより複雑な構成は、１つ又は複数のシステムモジュールを、ユーザ履歴データ及び／又は外部リソースとともに採用することができる。例えば、システムは、オーディオフィンガープリンティングモジュールと、外部データベースと、ユーザ履歴とによって、スマートフォンユーザがテレビショーのグレイズ・アナトミーのシーズン４、エピソード６を１５分間見たこと、及び、サラ・ラミレス（Ｓａｒａ  Ｒａｍｉｒｅｚ）−外科医カリー・トーレス（Ｃａｌｌｉｅ  Ｔｏｒｒｅｓ）を演じる女優−が、ユーザのお気に入りの女優の一人であることを決定し、スマートフォンに、ラミレスのウィキペディア（Ｗｉｋｉｐｅｄｉａ）のエントリへのリンクを、エピソードのこの部分の間にユーザに表示されるメニューオプションのリストの上の方に提示させてもよい。）
【０１５９】
認識の有効性が、ＲＡ及びミドルウェアの速度によって多大な影響を受けることは、理解されよう。この点について、様々な改善を行うことができる。
【０１６０】
各ＲＡは、所与の総合プラットフォーム利用プロファイルにおいて受信者動作曲線（Ｒｅｃｅｉｖｅｒ  Ｏｐｅｒａｔｉｎｇ  Ｃｕｒｖｅ）によりモデリングされうる。理想的には、ＲＡのインスタンスごとのモバイルデバイスプロファイルが、システム設計を知らせるために採用される。
【０１６１】
ディジマーク画像ウォーターマークＲＡは、ＦＦＴ、ログポーラ（ｌｏｇ−ｐｏｌａｒ）、及び、非線形フィルタリング段階をアセンブリ言語で実装して、アイフォンのＡ４プロセッサ内のＮＥＯＮレジスタを利用することによって、アイフォンプラットフォームに合わせて最適化される。
【０１６２】
画像ウォーターマークＲＡは、８ビットの深度の１２８×１２８ピクセルブロックを処理し、単一ブロック又は４ブロック検出器として実行することができる。単一ブロック実施形態では、以下の表に示すように、ＮＥＯＮ実装形態の実行時間が、マーク付きのフレーム及びマークなしのフレームの両方で２０％減った。マークなしのフレームに対する拒否速度を増すことは、より高いスループットを生じ、次には、ＲＡによる認識の試みの割合を増す。
【表２】
0006054870.tif 000003
【０１６３】
ＮＥＯＮ実装形態は、レジスタのＳＩＭＤ能力が使用されて、同時に４つの画像ブロックが処理されるとき、特定の利益を生じる。この４ブロック手法は、ＲＡの動作エンベロープ（以下で説明する）を増大し、したがってユーザ体験を改善するために、様々な前置フィルタの使用を可能にする。
【０１６４】
モバイルプラットフォームは時々、所与のシステムサービスのために複数のＡＰＩを提供する。ＡＰＩの選択は、プラットフォーム上で、リソース利用と、結果として生じるタスク混合とに影響を及ぼす可能性がある。場合によっては、この選択は、センサのスループットに影響を及ぼすことがある。
【０１６５】
ｉＯＳ  ４．０では、いくつかのＡＰＩが、カメラへのアクセスを提供する。最良の手法を識別するため、アイフォン４は、タスク混合を取り込むように機器が備えられたが、ディジマークディスカバーアプリケーションは、プリントトゥウェブ（Ｐｒｉｎｔ−ｔｏ−Ｗｅｂ）使用モデルにおいて使用された。
【０１６６】
図１８は、プレビュー（Ｐｒｅｖｉｅｗ）ＡＰＩを使用して、画像フレームを取得する前後の、タスク混合を示す（それぞれ、ビルド１．０．８及び１．１１）。プレビューＡＰＩを使用することで、フレームのレンダリングで費やされる時間が劇的に削減し、画像ウォーターマーク認識（「ＷＭの復号」として図示）のための時間が空く。プレビューＡＰＩを使用することで、他のシステム及びアプリケーションスレッドがプロセッサをより多く使用できるようにもなった。
【０１６７】
ＯＳに、他のスレッドにサービスするためのより多くの時間を与えることは、確実にシステム全体としての利益であるが、毎秒１１フレームから１４フレームへのスループットの増大は、ユーザにとってより直接的に有益である。スループットの増大はまた、ＲＡによるオブジェクトを認識する試みの割合をも増す。
【０１６８】
ユーザ体験の改善を定量化するために、認識率を、特定のユーザシナリオについての一次環境因子に応じて取り込むことができる。加えて、スループットを測定して、時間に応じて認識率を正規化することができる。
【０１６９】
以下の表は、最適化されたＲＡを、ｉＯＳ  ４．０プレビュー及びＵＩＧｅｔＳｃｒｅｅｎＩｍａｇｅ  ＡＰＩの両方とともに使用して、アイフォンビデオキュー（Ｖｉｄｅｏ  Ｑｕｅｕｅ）からフレームを取得した結果を示す。プレビューＡＰＩの実装形態は、すべてのＲＡについて、アイフォン３ＧＳで重要な改善を生じた。
【表３】
0006054870.tif 000004
【０１７０】
プリントトゥウェブの使用シナリオでは、主要な環境因子は、プリントまでの距離、照明、及び姿勢である。これらの因子を検討するために、認識率へのそれらの影響を繰り返し測定する、ロボットセルが構築された。
【０１７１】
２つのバージョンの画像ウォーターマークＲＡが、距離に対してテストされた。「ＳＳ」バージョンは、改良されたサンプリングアルゴリズムを含むが、「ベース（Ｂａｓｅ）」バージョンは含まない。サンプリングアルゴリズムは、ｉＯＳ  ４．２によって提供されたメタデータ辞書におけるＣｕｒｒｅｎｔＦｏｃｕｓＰｏｓｉｔｉｏｎによって提供された論理センサデータを使用する。
【０１７２】
図１９は、２つのバージョンの結果を表示し、どのフレームがウォーターマーク（又は、ペイロード）の復号に成功する結果となったか、及び、どのフレームがそうならなかったかを示す。改良されたサンプリングアルゴリズムは、ウォーターマークが検出可能であり、且つ、ペイロードが回復可能である、距離の範囲を著しく増大した。
【０１７３】
合わせて、図１９からの結果及び上記の表は、システムリソースの効率的な利用を、最適化されたＲＡと組み合わせることで、画像ウォーターマークＲＡの動作エンベロープが測定可能な程度に増大することを示す。
【０１７４】
要するに、詳述したディジマークディスカバープラットフォームは、現実世界の使用シナリオに基づいて、コンテンツ識別を提供し、関連する、モバイル発見アプリケーションを構築する複雑さを低減するように、設計される。プラットフォームは、拡張可能となるように、且つ、システムに影響を及ぼすことなく、いかなるタイプの認識エージェントの追加又は除去をも可能にするように、設計される。オペレーティングシステムリソースの効率的な利用、及び、認識エージェントの最適化は、消費者の満足のいくシステム性能を可能にする。すべてのオーディオ及びビデオ取り込みを扱うミドルウェアアーキテクチャを採用することで、レイテンシを低減し、システムリソースの共有を容易にし、電力消費を削減し、内部の競合を減少させる。いくつかの実装形態では、このミドルウェアは、ユーザ及びデバイスコンテキストに基づいて、センサ及び認識エージェントの使用を適合させる、形式的推測エンジンを含むが、他のミドルウェアは、より非形式的なタイプの推測を使用する。
モバイル発見の極小構成物としてのリンクトデータ（Ｌｉｎｋｅｄ  Ｄａｔａ）
【０１７５】
米国特許出願第１２／７９７５０３号に詳述されているように、リンクトデータの原理をスマートフォンデータに関連して使用することができる。
【０１７６】
スマートフォンセンサは、コンテキストについてのデータを作り出すものと見なされうる。
【０１７７】
コンテキストデータが格納されうる１つの方法は、ラベル（一般に辞書から取られる）及びデータを含む、キー値の対によるものである。（例えば、ＬＡＴ＝４５．０３、ＡｕｄｉｏＥｎｖｉｒｏｎｍｅｎｔ＝ＳｐｏｋｅｎＷｏｒｄ、ＢａｔｔｅｒｙＬｅｆｔ＝．１０７）。そのような簡単なキー値表現の欠点は、コンピュータがラベルを理解しないことである。コンピュータは単に、変数ＬＡＴが浮動小数点数を運ぶこと、変数ＡｕｄｉｏＥｎｖｉｒｏｎｍｅｎｔが文字列であること、その他を知るのみでありうる。
【０１７８】
本技術の別の態様によれば、そのような情報が、リソース記述フレームワーク（ＲＤＦ）知識表現言語におけるデータトリプルの集まりによってなど、セマンティックな表現方法で表される。（トリプルは典型的には、主部、述部（又は、プロパティ）、及び目的部からなる。）ＲＤＦスキーマ（ＲＤＦＳ）は、オブジェクト及びクラスの階層の維持を可能にする。セマンティックトリプル（Ｓｅｍａｎｔｉｃ  ｔｒｉｐｌｅｓ）は一般に、２つのデータ要素を含む関係を表現し、又は、単一のデータ要素に関する属性を表現する。
【０１７９】
トリプルでは、パラメータに値をさらに割り当てることができるが、トリプルは、他の情報にセマンティックに関係付けられ−意味を吹き込む。様々なオントロジーモデル（ＲＤＦＳ、ＯＷＬ、その他）を使用して、これらのトリプルの解釈、及び、そこでこれらのトリプルの互いの関係を形式的に記述することができる。ＬＡＴ（緯度）パラメータに、浮動小数点データがさらに割り当てられることがあるが、他のトリプルを参照することによって、コンピュータは、このＬＡＴデータが地球上の位置を指すことを理解することができる。そのような理解は、強力な推測を可能にする。（例えば、あるオブジェクトをある時間の瞬間に緯度４５に、２秒後に緯度１５に配置するデータセットは、疑わしいと理解されうる。）セマンティックウェブ技術は、スマートフォンが、コンテキストの情報と、そのような形式で提示された他のデータとに基づいて、推論することを可能にする。
【０１８０】
検知されたコンテキストトリプルは、グラフ形式で格納可能であり、但し、センサは、センサ自体及びセンサの出力データについてのアサーション（ａｓｓｅｒｔｉｏｎｓ）を収集する。１つのそのようなグラフ（ツリー）を、図１５に示す。
【０１８１】
異なる名前空間を、異なるセンサによって使用して、データの不一致を低減することができる。別個の名前を、各トリプルアサーションに反映することができ、例えば、以下の通りである。
・｛ＩｍａｇｅＳｅｎｓｏｒ３ＤＦ１２＿ＩｍａｇｅＴｉｍｅ＝２０１１０４０１１８０６０１０３＿Ｐｉｘｅｌ（０，０）；ＨａｓＲｅｄＶａｌｕｅ；４５｝
・｛ＩｍａｇｅＳｅｎｓｏｒ３ＤＦ１２＿ＩｍａｇｅＴｉｍｅ＝２０１１０４０１１８０６０１０３＿Ｐｉｘｅｌ（０，０）；ＨａｓＧｒｅｅｎＶａｌｕｅ；３２｝
・その他である。
【０１８２】
代替として、ツリー構造は、固有の名前空間識別子をルート又は他の基本となるノード（図１５に記載）に含むことが可能であり、他のノードを次いで、推測によりそのようにラベル付けすることができる。ツリーは、データ編成構成物として長い歴史を有しており、ツリー関連技法（例えば、ソート、枝刈り（ｐｒｕｎｉｎｇ）、メモリ最適化、その他）の豊富な集まりが適用可能である。
【０１８３】
ブラックボードデータ構造は、ＲＤＦトリプルのためのデータベースとしての役目を果たすことができる。極端な例では、取り込まれた画像内のあらゆるピクセルロケーションが、１つ又は複数のトリプルとして表現される。特定の実装形態では、センサシステムは、それらのデータをトリプルのストリームとして出力するように構成される。
【０１８４】
トリプルの述部自体が、他のトリプルの主部であることがある。例えば、「ＨａｓＲｅｄＶａｌｕｅ」は、上記の例では述部であるが、｛ＨａｓＲｅｄＶａｌｕｅ；ＩｓＡｔｔｒｉｂｕｔｅＯｆ；Ｉｍａｇｅ｝のようなトリプルの主部でもありうる。データがブラックボード上へ流されるとき、一体化動作を行うことができ−データタイプのそのような理解によって可能にされうる。
【０１８５】
認識エージェントは、米国特許出願第１２／７９７５０３号に詳述されているように、そのようなデータトリプルを使用して、認識エージェントの動作をトリガ又は一時停止することができる。例えば、入ってくるピクセルトリプルが暗い場合、光学的認識エージェント（例えば、バーコードリーダ、ウォーターマーク復号器、ＯＣＲエンジン）は実行されるべきではない。きめの細かい方式で（例えば、特定のピクセル値をアサートするトリプルのレベルまで下がって）データを表現することは、認識エージェントのきめの細かい制御を同様に可能にする。
【０１８６】
より高いレベルの粒度では、トリプルは、画像フレーム内の中心の１６×１６ピクセルブロックなど、ピクセルの集まりを含むメモリへのポインタを提供してもよい。さらに高くなると、トリプルは、画像のフレームを格納するメモリロケーションへのポインタを提供してもよい。このメモリロケーションの画像についてのアサーションを、一連のトリプルを通して作成し、例えば、画像のサイズ（例えば、６４０×４８０ピクセル）、画像の色表現（例えば、ＹＵＶ）、画像の取り込み時間、画像が取り込まれた際のセンサ、画像が取り込まれたジオロケーション、その他を詳述することができる。
【０１８７】
システムプロセッサは次いで、格納されたアサーションを使用して、画像へのアクションを取ることができる。例えば、システムプロセッサは、ユーザから−又は、別のシステム処理から−のクエリに応答して、特定のロケーションから取り込まれたか、又は、特定の時間に取り込まれた画像のフレームを探し出すことができる。システムは次いで、このようにして識別された画像のフレームにおいて、動作（例えば、オブジェクト認識）を行うことができる。別の例では、システムは、フレームの平均輝度をどのように計算するかを、格納されたＲＤＦデータからのフレームの色表現の形式の知識を部分的に使用して、見極めることができる。（ＹＵＶ画像では、Ｙは輝度を示すので、フレームのすべてのピクセルにわたってＹを平均することで、平均輝度が生じる。ＲＧＢ画像では、対照的に、各ピクセルでの輝度は、Ｒ値、Ｇ値及びＢ値の加重和であり、これらの加重和が次いでフレームの全体で平均されて、平均輝度が得られる。）
【０１８８】
ソフトウェア（例えば、上記で詳述したミドルウェア構成を有する、米国特許出願第１２／７９７５０３号のＩＣＰステートマシン）は、異なる認識エージェントにとって有用な入力データのタイプを考慮することができ、コンテキストに応じて、異なるタイプのデータを異なる時間に出力するように、センサシステムを構成することができる。
【０１８９】
例えば、コンテキストは、バーコード読み取りエージェント及びウォーターマーク復号エージェントがともにアクティブであるべきであることを、指示することがある。（そのようなコンテキストには、例えば、小売店内のジオロケーション、閾値を上回る周囲の照明、及び、ユーザの手に持たれたスマートフォンが含まれうる。）バーコードリーダは、輝度データを選ぶことがあるが、それほど好ましくなく、ＲＧＢデータを使用し、ＲＧＢデータから輝度を導出することが可能である。ウォーターマーク復号器は、フルカラー画像を必要とすることがあるが、フルカラー画像がＲＧＢで提供されるか、ＹＵＶで提供されるか、ある他のフォーマットで提供されるかは、重要ではない。システムソフトウェアは、異なる認識エージェントの異なる必要性及びプリファレンスに重み付けし、それに応じてセンサシステムを構成することができる。（いくつかの実施形態では、ミドルウェアは、異なるエージェント間でネゴシエートするプロキシとしての役目を果たし、例えば、プリファレンスによりスコアが取られた、可能なデータタイプのリストを求め、異なる組み合わせのスコアを取り、結果として得られた異なるスコアに基づいて選択を行う。）
【０１９０】
今述べた場合では、ソフトウェアは、ＹＵＶデータを出力するように、センサシステムに指図するようになり、その理由は、そのようなデータがウォーターマーク復号器に直接適しているためであり、Ｙチャネル（輝度）データをバーコードリーダによって直接使用することができるからである。
【０１９１】
物理センサに加えて、スマートフォンは、論理センサを有するものと見なされうる。論理センサは、コンテキストデータを消費すること、及び、コンテキストデータを作り出すことの両方を行ってもよく、典型的には−スマートフォン上、又はクラウド内のいずれかで−ソフトウェア処理を備えてもよい。例には、初期段階の認識（例えば、ここに関係があると思われるピクセルのブロブがある、ここに円の形がある）を行うコードから、ユーザの現在のアクティビティ（例えば、トニーは歩いている（Ｔｏｎｙ  ｉｓ  ｗａｌｋｉｎｇ）、その他）をレポートする、全くの推測駆動のセンサまで、幅広くすべてが含まれる。）
【０１９２】
そのようなコンテキストデータはやはり、単純なグラフとして格納可能であり、グラフでは、論理センサは、主部についての１つ又は複数のアサーション（例えば、主部＝Ｓｍａｒｔｐｈｏｎｅ＿Ｏｗｎｅｒ＿Ｔｏｎｙ、述部＝Ｅｎｇａｇｅｄ＿ｉｎ＿Ａｃｔｉｖｉｔｙ、目的部＝Ｗａｌｋｉｎｇ）を作成する。ＳＰＡＲＱＬを使用して、データベース内のトリプルにアクセスすることができ、詳細なクエリを維持することが可能になる。
【０１９３】
論理センサは当然、−入力として−スマートフォンセンサデータ及びその派生物以外のデータを使用することができる。環境内のセンサは、例えば、入力のソースでありうる。ユーザの予定表データ又は電子メールデータもまた、使用されうる。（ユーザがミーティングに出るようにスケジュールされている時間に検知されたサウンド−又は、見られたオブジェクト−は、他のミーティング出席者（複数可）がいるところで起こったものとして指示されうる。）ソーシャルメディアネットワークから（例えば、フェイスブック又はリンクトイン（ＬｉｎｋｅｄＩｎ）ウェブＡＰＩを介して）得られた情報は、同様に入力として論理センサに提供可能であり、ＲＤＦ出力トリプルに反映可能である。
【０１９４】
米国特許出願第１２／７９７５０３号に詳述されている認識エージェントは、ステートマシン及び関連付けられたアルゴリズムを実施して、特定のアプリケーションをサポートして、特定のコンテンツ／オブジェクトタイプを認識することができる。アプリケーションは、目標駆動の使用モデルを表す。アプリケーションは、１つ又は複数の認識エージェントを活用することによって、詳述されている直観的コンピューティングプラットフォームとインターフェースして、特定のタスクを行う。例えば、ウォーターマークを復号する、曲を認識する、バーコードを読み取るなどである。（米国特許出願第１２／７９７５０３号に詳述されている直観的コンピューティングプラットフォームは、センサを使用して、−ローカル及びクラウド内の両方で−ソフトウェアエージェントのタスクをより良く完了するための方法について、ソフトウェアエージェントに情報を与えることができるコンテキストを生成する。）
【０１９５】
この技術の特定の実装形態は、ＲＤＦ  ＡＰＩと、ＲＤＦ／ＸＭＬ、Ｎ３、及びＮ−トリプルの読み取り／書き込みと、ＯＷＬ  ＡＰＩと、ＳＰＡＲＱＬクエリエンジンとを提供する、Ｊｅｎａ−セマンティックウェブアプリケーションのためのオープンソースＪａｖａフレームワーク（当初はヒューレット・パッカード（Ｈｅｗｌｅｔｔ−Ｐａｃｋａｒｄ）によって開発された）を採用している。Ｊｅｎａをモバイルハンドセットに適合させた１つのものは、ミラノのポリテクニック（Ｐｏｌｙｔｅｃｈｎｉｃ）によるμ−Ｊｅｎａである。（代替実装形態は、Ａｎｄｒｏｊｅｎａ又はモバイル（Ｍｏｂｉｌｅ）ＲＤＦを使用することができる。）
【０１９６】
米国特許出願第１２／７９７５０３号に詳述されている直観的コンピューティングプラットフォームは、アプリケーションから認識エージェントへのトラフィックを管理し、論理センサ及び物理センサの両方のリソース競合を調停する。ブラックボードデータ構造を使用して、そのようなプロセス間通信を可能にし、システムのステータス（例えば、バッテリ状態）についての情報を維持することができる。
【０１９７】
ブラックボードを介したプロセス間通信の一例は、取り込まれた画像内で不適当な輝度を検知し、スマートフォンのトーチがオンにされることを望む、ウォーターマーク復号器である。ウォーターマーク復号器は、（ＯＳシステムコールを行う代わりに）トリプルをブラックボードに投稿し、そのようなアクションを要求してもよい。１つのそのようなトリプルは、以下の通りでありうる。
｛Ｔｏｒｃｈ；Ｑｕｅｕｅｄ＿Ｒｅｑｕｅｓｔ；Ｏｎ｝
別の１つは、以下の通りでありうる。
｛ＷＭ＿Ｄｅｃｏｄｅｒ；Ｒｅｑｕｅｓｔｓ；Ｔｏｒｃｈ＿Ｏｎ｝
【０１９８】
トーチ制御プロセス（又は、別のプロセス）は、そのようなトリプルについてブラックボードを監視し、同じことが起こるとき、トーチをオンにしてもよい。又は、バッテリ電源が低い場合、そのようなプロセスは、トーチが照明されることを２つ以上の認識エージェントが待機中となるまで（又は、他の緊急性の兆候が発見されるまで）待機し、そのときにのみトーチをオンにしてもよい。
【０１９９】
ウォーターマーク復号器は、トーチの電源が投入されることを指示するトリプルを求めてブラックボードを検索するＳＰＡＲＱＬクエリによって、トーチがオンにされたことを検出してもよい。このクエリは、トーチが照明されるとき、応答を返し、ウォーターマーク復号エージェントをブロック解除し、完了まで実行可能にする。
【０２００】
ロケーションは、（上記で示したような）コンテキスト情報の別の重要なソースであり、ＲＤＦトリプルで同様に表現可能である。ＤＢペディア（ＤＢｐｅｄｉａ）−ウィキペディアからの情報のリンクトデータ表現、及び、ジオネームズ（ＧｅｏＮａｍｅｓ）は、そのようなデータのための多数のソースの中にある。電話センサデータ（ＧＰＳ）を、ジオネームズ又はＤＢペディアサービスに適用して、対応するテキストのジオラベル（ｇｅｏ−ｌａｂｅｌｓ）を得ることができる。
【０２０１】
コンテキストデータは、ユーザ自身のスマートフォンから生じる必要はない。例えば、同じロケール及び時間期間で、他者によって他者のモバイルデバイスを使用して収集／寄付された、低レベルのセンサ情報（トリプル）を使用することもできる（適切なプライバシー保護手段を必要とする）。政府機関、その他によって維持された道路のカメラなど、近くの静止センサからのデータの場合も、同様である。（同じロケールは、それ自体がコンテキスト／アプリケーション依存であり、例えば、閾値距離内−１００ｍ、１ｋｍ又は１０ｋｍなど−、同じ地理的機関内−町又は市など−、その他が含まれうる。同様に、時間の近接は、過去１０秒以内、１０分以内、１時間以内、その他に収集されたデータなど、閾値により境界が付けられうる）。そのような情報を、ローカルのブラックボードに直接統合して、デバイスエージェントがその情報において動作できるようにしてもよい。画像に加えて、そのようなデータには、オーディオ、ロケーションの識別を助けるためにエリア内で使用可能なワイヤレス信号のサンプル、その他が含まれうる。データ共有のためのそのような「オープンワールド」手法は、スマートフォンプラットフォームによるコンテキストの理解を非常に増すことができる。
【０２０２】
前述のものは、リンクトデータ方式のコンテキスト及びセンサデータの表現に焦点を合わせているが、他のスマートフォンデータは同様に利益を得ることができる。
【０２０３】
例えば、米国特許出願第１３／０７９３２７号において、出願人は、印刷されたテキストにおけるマシン可読データがどのように検知されうるか、及び、関連付けられた情報である、「ツールのヒント」ポップアップテキストと、関連情報の拡大されたストアとの両方にリンクするために、どのように使用されうるかを詳述している。例えば、新聞の分類広告のページをカメラ付き電話でスキャンするとき、スマートフォン表示は、電話が広告上を通過するとき、広告の短い概要（例えば、「１９６７  マスタング（Ｍｕｓｔａｎｇ）」）を提示してもよい。読み取られている特定の新聞は、コンテキスト情報であり、識別発行情報は、ページから復号された最初のウォーターマークペイロードから導き出される。このコンテキストから、新聞全体のための適切なポップアップテキストがリモートデータストアからプルされ、後の使用のために、電話にキャッシュされる。そのようなポップアップテキストを、トリプルの形式（例えば、｛Ｗａｔｅｒｍａｒｋ  １４ＤＡ３；ＨａｓＰｏｐＵｐＴｅｘｔ；１９６７  Ｍｕｓｔａｎｇ｝）で送信及び／又は格納することができる。
【０２０４】
スマートフォンアプリケーションにおけるリンクトデータの別の実装形態については、Ｚａｎｄｅｒ他、「Ｃｏｎｔｅｘｔ−Ｄｒｉｖｅｎ  ＲＤＦ  Ｄａｔａ  Ｒｅｐｌｉｃａｔｉｏｎ  ｏｎ  Ｍｏｂｉｌｅ  Ｄｅｖｉｃｅｓ」、Ｐｒｏｃ．  Ｏｆ  ｔｈｅ  ６ｔｈ  Ｉｎｔ’ｌ  Ｃｏｎｆ．  ｏｎ  Ｓｅｍａｎｔｉｃ  Ｓｙｓｔｅｍｓ、２０１０年に詳述されている。Ｚａｎｄｅｒの研究は、ローカルソフトウェアエージェントによって使用するための、リモートソースからモバイルデバイスへの、構造化セマンティックウェブデータの、コンテキスト情報に基づくレプリケーションに焦点が合わせられているが、詳述されたシステムは、スマートフォンにおけるリンクトデータ利用の他の態様を例示している。Ｚａｎｄｅｒの研究の特徴及び詳細は、出願人の発明性のある研究に関連して適用可能であり、逆もまた同様である。
【０２０５】
ＲＤＦ関連技術に関して米国特許出願第１２／７９７５０３号から写された抜粋は、以下の通りである。
リンクトデータ
【０２０６】
本技術の別の態様によれば、データ及びリソースのウェブ２．０の概念（例えば、リンクトデータに関連する）が、有形のオブジェクト及び／又は関連キーベクトルデータ、並びに、関連付けられた情報と共に使用される。
【０２０７】
リンクトデータは、Ｓｉｒ  Ｔｉｍ  Ｂｅｒｎｅｒｓ  Ｌｅｅによって奨励された、ウェブ上で参照解除可能なＵＲＩを介してデータを公開、共有及び接続するための構成を指す。（例えば、Ｔ．Ｂ．  Ｌｅｅ、Ｌｉｎｋｅｄ  Ｄａｔａ、ｗｗｗ＜ｄｏｔ＞ｗ３＜ｄｏｔ＞ｏｒｇ／ＤｅｓｉｇｎＩｓｓｕｅｓ／ＬｉｎｋｅｄＤａｔａ．ｈｔｍｌを参照。）
【０２０８】
要するに、ＵＲＩが使用されて、有形のオブジェクト及び関連付けられたデータオブジェクトが識別される。ＨＴＴＰ  ＵＲＩは、人々及びユーザエージェントによってこれらのオブジェクトを参照し、ルックアップ（「参照解除」）することができるように、使用される。ある有形のオブジェクトが参照解除されるとき、その有形のオブジェクトについての有用な情報（例えば、構造化されたメタデータ）が提供される。この有用な情報は、−他の関連情報及び有形のオブジェクトの発見を改善するために−他の関連ＵＲＩへのリンクを含むことが望ましい。
【０２０９】
ＲＤＦ（リソース記述フレームワーク）は一般に、リソースについての情報を表現するために使用される。ＲＤＦは、リソース（例えば、有形のオブジェクト）を、主部、述部及び目的部からなる、いくつかのトリプルとして記述する。これらのトリプルは、時として、アサーションと呼ばれる。
【０２１０】
トリプルの主部は、記述されたリソースを識別するＵＲＩである。述部は、どのような種類の関係が主部と目的部の間に存在するかを指示する。述部もまた、典型的にはＵＲＩであり−特定のドメインに関する標準化された語彙から引き出されるものである。目的部は、リテラル値（例えば、名前又は形容詞）であってもよく、又は、主部に何らかの形で関係付けられる別のリソースのＵＲＩであってもよい。
【０２１１】
異なる知識表現言語を使用して、有形のオブジェクト及び関連付けられたデータに関するオントロジーを表現することができる。ウェブオントロジー言語（ＯＷＬ）はその１つであり、ＲＤＦスキーマとの互換性を提供するセマンティックモデルを使用する。ＳＰＡＲＱＬは、ＲＤＦ表現とともに使用するためのクエリ言語であり−クエリが、連言、選言、及びオプションのパターンとともに、トリプルパターンからなることを可能にする。
【０２１２】
本技術のこの態様によれば、モバイルデバイスによって取り込まれ、作り出されたデータの項目には、一意及び永続的な識別子がそれぞれ割り当てられる。これらのデータには、基本のキーベクトル、セグメント化された形状、認識されたオブジェクト、これらの項目について得られた情報、その他が含まれる。これらのデータの各々は、クラウドベースのレジストリシステムに記録され、このレジストリシステムはまた、関連するルーティング機能をもサポートする。（データオブジェクト自体もまた、長期の格納のためにクラウドへプッシュされてもよい。）データに関する関連アサーションは、モバイルデバイスからレジストリへ提供される。したがって、ローカルデバイスに知られている各データオブジェクトは、クラウド内のデータを介してインスタンス化される。
【０２１３】
ユーザは、画像を取り込みながら、カメラをさっと動かしてもよい。そのようなアクションを通して集められ、処理され、及び／又は識別されたすべてのオブジェクト（及び関連データ）は、識別子が割り当てられ、クラウド内で存続する。１日又は１年後、別のユーザがそのようなオブジェクトに対して、（例えば、ある木がホワイトオークである、などという）アサーションを作成することができる。カメラが特定の場所を、特定の時間に素早く見ることであっても、クラウド内で無期限にメモリアライズ（ｍｅｍｏｒｉａｌｉｚｅｄ）される。そのようなコンテンツは、この基本のクラウドベースの形式において、協調のために組織化する構成物となりうる。
【０２１４】
データの命名を、クラウドベースのシステムによって割り当てることができる。（クラウドベースのシステムは、割り当てられた名前を発信側のモバイルデバイスに戻すようにレポートすることができる。）モバイルデバイスに知られているようなデータを識別する情報（例えば、上述のクランプＩＤ又はＵＩＤ）をクラウドベースのレジストリに提供することができ、そのデータについての別のアサーションとして、クラウド内でメモリアライズすることができる。
【０２１５】
クラウドベースのレジストリによって維持されたデータの部分ビューには、以下が含まれうる。
【表４】
0006054870.tif 000005
【０２１６】
このように、この態様では、モバイルデバイスは、クラウドベースのレジストリが複数のソフトウェアオブジェクト（例えば、ＲＤＦトリプル）を、モバイルデバイスが処理するデータの項目ごとに、及び／又は、そのカメラの視野内で発見された物理的オブジェクト又は特徴ごとに、インスタンス化することを可能にするデータを提供する。大変多くのアサーションを、各々について作成することができる（私はキャニーデータである、私はある場所及び時間で取り込まれた画像に基づいている、私は、緯度Ｘ、経度／Ｙから北を見ると見える、質感の高い青いオブジェクトである、その他）。
【０２１７】
重要なことには、これらの属性を、他のデバイスによって投稿されたデータとリンクさせることができ−ユーザのデバイスによって、入手可能な画像データ及びコンテキストのみから見極めることができない、新しい情報の獲得及び発見が可能となる。
【０２１８】
例えば、ジョンの電話は、ある形状をビルとして認識するが、その住所を見極めること、又はそのテナントを知ることができないことがある。ジェーンは、しかし、そのビルで働いていることがある。彼女の特定のコンテキスト及び履歴のため、彼女の電話がビル関連画像データに関連してレジストリに以前に提供した情報においては、そのビルの住所及びいくつかのテナントについての情報を含む、そのビルについての情報がより豊富であることがある。ジオロケーション情報及び形状情報における類似性によって、ジェーンの電話が情報を提供したビルを、ジョンの電話が情報を提供した同じビルである可能性が高いものとして識別することができる。（新しいアサーションをクラウドレジストリに追加して、ジェーンのビルのアサーションをジョンのものに明示的に関係付けることができ、逆もまた同様である。）ジョンの電話がレジストリに対して、そうするように要求した場合（且つ、関連のあるプライバシー保護手段が許可する場合）、レジストリは、ジョンの電話に、ジェーンの電話によって提供されたそのビルについてのアサーションを送ることができる。ここで作用している、根底にある機構は、仲介されたクラウドソーシングであると見なすことができ、アサーションは、参加者もサブスクライブするポリシー及びビジネスルールフレームワーク内で作成される。
【０２１９】
関連付けられたアサーションの豊富なセットを有するロケーション（例えば、場所によって、及び、任意選択で時間によっても決定される）は、新しい発見体験をもたらす。モバイルデバイスは、ＧＰＳロケーション及び現在時間など、単純なアサーションを、リンクトデータ又は他のデータリポジトリ内で検索又は発見体験を開始するためのエントリポイントとして、提供することができる。
【０２２０】
また、クラウド内のアサーションのアクセス又はナビゲーションに、モバイルデバイス上のセンサによって影響を与えることができることにも留意されたい。例えば、ジョンは、ＧＰＳ又は他のセンサによって決定されるような、そのビルとの特定の近接内（例えば、１０ｍ、３０ｍ、１００ｍ、３００ｍ、その他）にいる場合にのみ、そのビルに関するジェーンのアサーションにリンクすることを許可されてもよい。この許可は、ジョンが静止しているか、又は、ＧＰＳ、加速度計／ジャイロスコープ、若しくは他のセンサによって決定されるような歩く速度（例えば、毎分１００フィート若しくは３００フィート未満）で移動中である必要がある場合に、さらに限定されてもよい。モバイルデバイス内のセンサからのデータに基づくそのような制限は、望まれていないか、又はより関連性の少ないアサーション（例えば、広告など、スパム）を減らし、データのリモート又はドライブバイ（若しくは、フライバイ）マイニングに対する、あるセキュリティを提供することができる。（様々な構成を用いて、ＧＰＳ又は他のセンサデータのスプーフィングと戦うことができる。）
【０２２１】
同様に、２人の関係者が、ジオロケーション、時間、ソーシャルネットワークのつながり、その他における近接など、ある特色を共有するときにのみ、クラウド内に格納されたアサーションがアクセスされてもよい（又は、主部についての新しいアサーションが作成されてもよい）。（後者は、ジョンが、例えば友人として、ジェーンに社会的にリンクされることを示す、フェイスブック又はリンクトインなど、ソーシャルネットワークデータストアを参照することによって、示されうる。）ジオロケーション及び時間のそのような使用は、社会慣習に近似し、すなわち、人々の大きいグループが集まるとき、発生する自然発生的なインタラクションは価値のある可能性があり、その理由は、そのグループのメンバが共通の関心、特色、その他を有する高い見込みがあるからである。アサーションにアクセスし、それを投稿するための能力、及び、他者の存在に基づいて新しい発見体験を可能にすることは、このモデルの結果として生じる。
【０２２２】
ロケーションは、画像データのセットが関連付けられる、よくある手がかりである。他の手がかりもまた、使用することができる。
【０２２３】
ゾウの調査員を考えられたい。知られているゾウ（例えば、自然保護区域内にいる）には、一般に名前が付けられ、顔の特徴（傷跡、しわ及びきばを含む）によって識別される。調査員のスマートフォンは、あるゾウについての顔の特徴ベクトルを大学データベースに提出してもよく、大学データベースは、顔のベクトルをゾウの名前に関連付けるために存在する。しかし、そのような顔のベクトル情報がクラウドベースのレジストリに提出されるとき、より大量の情報が明らかにされることがあり、例えば、以前の目撃の日付及びロケーション、そのゾウを見たことがある他の調査員の名前、その他である。ここでもまた、データセット間の対応が見極められた後、さらなるアサーションをレジストリに追加することによって、この事実をメモリアライズすることができる。
【０２２４】
モバイルデバイスのカメラ、マイクロフォン及び他のセンサによって検知された刺激についてのアサーションの、そのようなクラウドベースのリポジトリは、特に他のリンクトデータシステム（そのうちの少数は、ｌｉｎｋｅｄｄａｔａ＜ｄｏｔ＞ｏｒｇに詳述されている）内の情報と関係付けられるとき、グローバルに有用な情報の莫大なストアを迅速に備えうることは理解されよう。格納されたアサーションによって表現された理解は、部分的に、そのデバイスがそのような情報に寄与する個々のユーザのプロファイル及び履歴を反映するので、知識ベースは特に豊富である。（ウェブのグーグルのインデックスは、比較すると小さく見えることがある。）
【０２２５】
（有形のオブジェクトの識別に関連して、潜在的に有用な語彙は、ＡＫＴ（高度知識技術（Ａｄｖａｎｃｅｄ  Ｋｎｏｗｌｅｄｇｅ  Ｔｅｃｈｎｏｌｏｇｉｅｓ））オントロジーである。ＡＫＴオントロジーは、そのトップレベルにクラス「Ｔｈｉｎｇ（物）」を有し、その下に２つのサブクラスである「Ｔａｎｇｉｂｌｅ−Ｔｈｉｎｇ（有形物）」及び「Ｉｎｔａｎｇｉｂｌｅ−Ｔｈｉｎｇ（無形物）」がある。「Ｔａｎｇｉｂｌｅ−Ｔｈｉｎｇ」には、ソフトウェアから亜原子粒子まで、現実及び想像上のあらゆるものが含まれる（例えば、ミッキー・マウス（Ｍｉｃｋｅｙ  Ｍｏｕｓｅ）の車）。「Ｔａｎｇｉｂｌｅ−Ｔｈｉｎｇ」は、「Ｌｏｃａｔｉｏｎ（ロケーション）」、「Ｇｅｏｇｒａｐｈｉｃａｌ−Ｒｅｇｉｏｎ（地理的領域）」、「Ｐｅｒｓｏｎ（人）」、「Ｔｒａｎｓｐｏｒｔａｔｉｏｎ−Ｄｅｖｉｃｅ（移動手段デバイス）」、及び、「Ｉｎｆｏｒｍａｔｉｏｎ−Ｂｅａｒｉｎｇ−Ｏｂｊｅｃｔ（情報を伝えるオブジェクト）」を含む、サブクラスを有する。この語彙を拡張して、本技術に関連して遭遇されると予期されるオブジェクトについての識別を提供することができる。）
混合ドメイン表示
【０２２６】
本技術の別の態様によれば、スマートフォンは、カメラによって取り込まれた自然画像、並びに、カメラによって取り込まれた画像に基づいた変換ドメイン情報（例えば、空間周波数、又はフーリエ、ドメイン内）の両方を含む、表示を提示する。
【０２２７】
２０１０年５月５日出願の米国特許出願第１２／７７４５１２号は、ステガノグラフィ的にウォーターマーク検出器による、ウォーターマークが存在するかどうかの判定を支援するために、画像に符号化されうる例示的参照信号を詳述している。詳述された参照信号は、空間周波数ドメイン内に−十分に高い周波数で−、クロミナンス−偶然に見る人々にとって参照信号を知覚不可能にさせる−とともに符号化される。
【０２２８】
本技術の実施形態は、見る人に対して、この変換ドメインベースの情報を明らかにする。
【０２２９】
図１１は、印刷されたホスト画像に追加される参照信号２１０の例示的空間周波数ドメインビューを示し、実数成分が横軸によって表され、虚数成分が縦軸によって表される（いわゆる「ｕ，ｖ」平面）。図示の参照信号は、人間が知覚するには高すぎるが、スマートフォンカメラ内の画像センサによって作り出されたデータ内で検出可能である周波数（つまり、原点からの距離）での、空間ドメインインパルスの五角形の配列２１２を備える。（ホスト画像の対応する空間周波数ドメインビューは図示しないが、典型的には、ｕ，ｖ平面の全体にわたって散乱しているが、横軸及び縦軸に沿って最も集中している、信号を備えるようになる。）
【０２３０】
図１１のビューでは、マーカ２１５は、円２１５を中心とする。人間の視覚の限界は、より小さい円２１７によって示される。円２１７の外側の空間周波数成分から構成される特徴（例えば、マーカ２１２）は、周波数が高すぎて、見る人々にとって見極め不可能である。（マーカ２１２が空間周波数内でより低かった場合、マーカ２１２は、細かいヘリンボーン織りに類似しているピクセルパターンに対応するようになる。より高い周波数では、しかし、目は、織り込みパターン（ｗｅａｖｅ  ｐａｔｔｅｒｎ）を区別することができない。むしろ、織り込みは、一見すると平坦になる。）
【０２３１】
４つの五角形のマーカ配列２１２を示すが、もちろん、より少ない又はより多い数を使用することもできる。同様に、マーカは、五角形の形である必要はない。
【０２３２】
スマートフォンカメラが参照パターン２１０を検出するとき、スマートフォンカメラは、それにより、カメラと印刷物の間の相対距離、並びに、印刷物に対するカメラのいかなる回転及び傾きを見極めることもできる。例えば、カメラが印刷物に近付くように動かされる場合、拡大された画像成分が、より低い成分の空間周波数を有するものとして検知される。したがって、五角形のマーカは、原点に近付くように動く。カメラが（参照信号が当初ホスト画像内で符号化された向きに対して）回転される場合、五角形のマーカは、同様に回転されるように見える。カメラが−印刷された画像の一部分が、印刷された画像の他の部分よりもセンサに近くなるように−傾けられる場合、五角形のパターンは歪められる。（五角形のパターンの中心２１４は、ｕ，ｖ原点を中心とした円２１５上にもはや位置しておらず、代わりに、楕円上に位置する。）
【０２３３】
図１２は、例示的スマートフォン表示２２０を示す。この例示では、スマートフォンは、シリアルの箱の一部分を撮像中であり−そのアートワーク２２２は、画面の大部分を占有している。画面上に重ね合わせられたものは、上の２つの五角形の参照マーカを含む、検出された参照信号の半平面の描写である。図示の表示はまた、２つの固定された対象領域２２４−円形の破線で輪郭が描かれている−をも含む。電話をシリアルの箱に向かって、又は、シリアルの箱から離れるように動かし、必要に応じて傾ける／回転させることによって、ユーザは、五角形のマーカ２１２を２つの対象領域２２４内へ移動させることができる。この位置で、シリアルの箱からのウォーターマーク信号の読み取りが、最適化される。スマートフォンは、ウォーターマークを直ちに（マーカが対象領域内に位置合わせされる前の可能性が高い）読み取るようになり、電話は、検出されたデータに応答して、対応するアクションを取るようになる。
【０２３４】
変換ドメインオーバーレイは、検出された参照信号の強度とともに変化する可視性（強度）で提示されることが望ましい。参照信号が（例えば、パターン検出器によって出力された検出メトリックによって）検出されない場合、オーバーレイは提示されない。より強い信号では、オーバーレイされたマーカ信号は、−バックグラウンド画像２２２と比較して−より高いコントラストで提示される。いくつかの実施形態では、マーカは、検出された参照信号の強度に応じて、クロミナンス又は明度が変化する配色で提示される。
【０２３５】
１つの特定の実装形態では、取り込まれた画像の空間周波数表現が閾値処理されるので、閾値を下回るいかなる空間周波数成分も表示されないようになる。これにより、取り込まれたシリアルの箱のアートワーク２２２のフーリエドメイン表現によって表示が劣化することを防ぐ。代わりに、オーバーレイされた信号のみが、マーカ信号に対応する。
【０２３６】
同様に、空間周波数データを、高域スペクトルフィルタリングして、閾値空間周波数（例えば、図１１の円２１７によって指示された空間周波数）を上回る画像成分のみが示されるようにしてもよい。
【０２３７】
円形の対象領域２２４は、必須ではない。他の視覚的ガイドを提示することができ、又は、完全に省略することができる。後者の場合、ユーザは、マーカ２２４が平らである（すなわち、水平にわたる）ように、電話を位置決めするように命令されることがある。変換されたデータが（前の段落で説明したように）スペクトルフィルタリングされる場合、ユーザは、マーカがちょうど現れるまで、電話を被写体に向かって−又は、被写体から離れるように−位置決めするように命令されることがある。（実際の実施では、マーカ２１２の５つの点は、特にカラーでレンダリングされるとき、やや、小さい小妖精の姿−頭、２つの手、及び２本の足−のように見える。ユーザには、したがって、「小妖精の人々を探す」ように命令することができる。小妖精の外観は、各マーカの５つの成分要素に異なる色を与えることによって、特に顕著にすることができ、経時的に色を変え−人をひきつける、きらめき効果を生じることができる。）
【０２３８】
図１２に描かれた特定の実施形態では、空間周波数情報は、長方形のボックス２２６内に示される。空間周波数情報のためのフレームとしての役目を果たすことに加えて、このボックスはまた、アートワーク２２２内で長方形のピクセルの小領域を定義する役目も果たし、長方形のピクセルの小領域において変換ドメイン解析が行われる。つまり、画像のフレーム全体をフーリエドメインに変換する代わりに、ボックス２２６内のそれらのピクセルのみがそのように変換される。これにより、電話プロセッサへの負荷が低減される。（ボックス２２６を、小さなくぼみの領域（ｆｏｖｅａ  ｒｅｇｉｏｎ）−プロセッサが、ユーザによる電話の最適な位置決めを助けるときに注意を集中させる、ピクセルの小領域−と見なすことができる。）領域２２６内のピクセルの輝度をわずかに増加又は減少させて−ユーザに対して領域をさらにハイライトすることができる。
ウォーターマーク合図パターン
【０２３９】
デジタルウォーターマークは、通常は知覚不可能である。このことは望ましいことであり、その理由は、デジタルウォーターマークは、いかなる可視の変化を導入することもなく、細かいアートワーク及び他のグラフィックスに符号化可能であるからである。しかし、この利点には、関連する欠点があり、つまり、符号化されたデータの潜在的ユーザは、いずれかのウォーターマーキングされたデータが存在するかどうか、確信がない。
【０２４０】
従来、この欠点は時々、符号化された視覚的アートワークの角に印刷されて、そのアートワークがウォーターマーク符号化されていることを指示する、小さい視覚的なロゴの使用によって軽減されてきた。
【０２４１】
本技術の別の態様によれば、デジタルウォーターマーキングされた情報の存在は、視覚的なウォーターマークパターンをかすかに見えるようにすることによって、視覚的に合図される。
【０２４２】
前のセクションで述べたように、ウォーターマークを含む空間周波数要素の周波数が十分に低い場合、空間周波数要素は、織り込み（例えば、標準の五角形のマーカの場合、ヘリンボーン織り）に類似したパターンを生じる。いくつかの応用例では、そのような織り込まれたバックグラウンドパターンは、不快ではない。バックグラウンドパターンは、（例えば、印刷された銀行小切手の上の）多数のコンテキストからよく知られている。そのため、光沢仕上げの写真を含まない文書の場合は特に、文書の有用性を損なうことなく、パターンを挿入することができる。
【０２４３】
ユーザは、経時的に学習し、又はトレーニングされて、ある繰り返し発生するパターンを、関連付けられたデータの存在の証拠となるものとして認識することができる。（例えば、オンライン文書内の青い下線付きのテキストの提示が、ハイパーリンクを表すものとして、大部分のユーザにどれほどよく知られているかを考えられたい。）スマートフォンベースのシステムを使用して、そのような独特のパターンの画像を取り込み、ウォーターマークキングされた情報を復号し、対応するアクション（複数可）を取ることができる。
【０２４４】
１つの特定の実施形態では、そのようなウォーターマークは、人間の視覚の範囲内である（すなわち、図１１の円２１７の内側の）第１のセットの空間周波数成分と、人間の視覚の範囲を越えている（すなわち、図１１の円２１７の外側の）第２のセットの空間周波数成分とを含む。前者は、手漉き紙の表面の外観−一般に、そのような紙のパルプ繊維の分散に基づくランダムパターンを含む−に類似している、ピクセルドメイン内の対応するパターンを定義するように、ｕ，ｖ平面内で擬似ランダムに分散している成分を含みうる。この第１のセットの空間周波数成分を、すべてのタイプの文書にわたって繰り返し使用して−ユーザが最終的に、符号化された情報の存在の手がかりを与えるものとして認識するようになることが可能である、特性的パターンを作り出すことができる。（パターンの色は、空間周波数成分を異なる色チャネルに入れることによって、応用例に最良に合うように変更されうる。）この一貫したパターンをスマートフォンのウォーターマーク検出器によって使用して、（１）ウォーターマークの存在を迅速に識別し、任意選択で（２）取り込まれた画像の−その当初符号化された状態に対する−変換、スケール及び／又は回転を決定することができる。
【０２４５】
第２のセットの空間周波数成分は、この特定の実施形態では、ウォーターマークペイロード情報の一部又は全部を搬送する。この情報は、文書によって変わる。しかし、これらの画像成分は、偶然に見る状況では人間には見えないので、そのような可変性は、ユーザがそれにより符号化情報を含むものとして文書を認識する特性的テクスチャパターンを、妨げない。
【０２４６】
ちょうど、カラーの下線付きのテキストが、人々の心の中でハイパーリンクされた情報に関連付けられるようになっているように、独特の可視パターンも同様に、デジタルウォーターマーキングされた情報の存在に関連付けられるようになりうる。
【０２４７】
手がかりを与えるパターンは、−非表示情報の存在を指示するために使用された−独特のスクリプト体又は活字書体の形態を取ることさえある。例えば、あるフォントは、独特の拡張特徴−右側で巻いている、又はねじれ、又は結びなど−を含む、セリフを含むことがある。又は、符号化されたウォーターマークデータを含む印刷物は、独特の縁を含むことがある。１つは、３本の細い線によって定義された、フレームを付ける長方形である。別の１つは、２つ又は４つの類似する角のマーカのセット−図１３に示すものなど−である。
【０２４８】
（いくつかの構成では、そのような縁−又は、角−のマーキングは、元の物理的媒体には存在しないが、媒体内で符号化された信号（例えば、図１１又は図１４の信号）のスマートフォン検出によってトリガされる画面上のグラフィックオーバーレイとして、レンダリングされる。特定の構成では、そのようなオーバーレイされたマーキングの線は、スマートフォンが次善の見る姿勢である場合、多少ぼけたようにレンダリングされ、ユーザがスマートフォンをより最適な見る姿勢に動かすにつれて、次第に焦点が合うようにレンダリングされる。電話が最適に（例えば、ウォーターマーキングされた被写体の平面ビューでは、６インチの距離で）位置決めされるとき、次いで、線は、くっきりした鮮明な形で提示される。このようにして、電話内のソフトウェアは、見る姿勢の最適性についての情報を、あるユーザにとって多少なじみのある視覚的パラダイム−焦点の、距離への依存−に変換する。）
情報提示の層
【０２４９】
いくつかの実装形態では、情報がユーザに提示される３つの概念的な「層」があることがある。これらの層は、視覚層、フラグ層、及びリンク層と呼ばれることがある。
【０２５０】
視覚層は、デジタルウォーターマーク情報が存在するという、人間が知覚可能な手がかりである。今述べたように、これらの手がかりは、異なる形態を取ることができる。１つは、符号化された情報の存在を指示するロゴ、活字書体、縁、又は他の印刷されたしるしである。別の１つは、ウォーターマーキング処理の一部として、印刷されたコンテンツ内に導入される、目に見えるアーチファクト（例えば、織り込みのようなデザイン）である。
【０２５１】
フラグ層は、ある初期デジタル画像処理の結果としてユーザに提示される（典型的には一時的な）しるしである。１つの例は、上記で言及した「小妖精の人々」である。別の例は、米国特許出願第１２／７９７５０３号で論じられている「プロトボーブル（ｐｒｏｔｏ−ｂａｕｂｌｅｓ）」である。他の例は、米国特許出願第１２／７７４５１２号で論じられている。フラグ層は、実際にはウォーターマークが存在しているという、最初のかすかな電子的認識としての役目を果たす。（フラグ層は、任意選択で、最適化されたウォーターマーク読み取りのためにスマートフォンカメラを位置決めする際に、ユーザをガイドする支援をするものとしての役目を果たしてもよい。）
【０２５２】
リンク層は、ウォーターマークが復号された後にユーザに提示される情報を備える。このことは一般に、リゾルバデータベースを復号されたウォーターマークペイロード（例えば、大数）によりインデックス付けして、どのような振る舞いがそのウォーターマークに関連付けられるかを学習すること、及び、次いで、その振る舞いを開始することを含む。
符号化されたデータ変換
【０２５３】
本技術のさらなる態様によれば、ウォーターマークにより符号化されたメディア信号を受信するデバイスは、ウォーターマークデータを復号し、別のデータチャネルによって前方へ中継するように作動することができる。
【０２５４】
テレビ、セットトップボックス、又は、ビデオエンターテインメント番組を受信する他のデバイスを考えられたい。番組のオーディオ及び／又はビデオは、例えば、番組を識別する、デジタルウォーターマーク情報により符号化されることがある。消費者は、ビデオ番組をテレビで見ながら、スマートフォン又はタブレットコンピュータを使用中であることがあり、スマートフォン／コンピュータが、見られている番組のアイデンティティを知ることは、有利でありうる（例えば、特許公報の米国特許出願公開第２０１０／０１１９２０８号及び第２０１０／０２０５６２８号に詳述されている理由のため）。従来技術では、このことは、−番組のオーディオ内に符号化されたウォーターマークについては−スマートフォン又はコンピュータ内のマイクロフォンを使用して、周囲のオーディオを取り込み、次いで、取り込まれたオーディオからウォーターマークデータを復号することによって達成されている。しかし、このことは時々、マイクロフォンによって同様に取り込まれることがあり、信頼できるウォーターマーク復号を妨げることがある、他のサウンドによって、困難にされる。
【０２５５】
本技術のこの態様によれば、第１のデバイス（例えば、テレビ又はセットトップボックス）は、ウォーターマークデータをコンテンツストリームから復号する。第１のデバイスは次いで、このデータを−異なるチャネルによって−第２のデバイス（例えば、スマートフォン）へ中継する。
【０２５６】
１つの例示的実施形態では、テレビ内の復号器は、番組を受信し、オーディオ成分からオーディオウォーターマークを復号する。テレビ内の復号器は次いで、復号されたウォーターマークデータを近くのスマートフォンへ、ブルートゥースワイヤレス技術を介して再送信する。これらのスマートフォンは、このようにして、周囲の室内雑音干渉のないウォーターマークデータを（スマートフォンの内蔵のブルートゥース受信機を使用して）受信する。
【０２５７】
復号されたウォーターマーク情報を中継することができる別のワイヤレスデータチャネルは、ＮＦＣ無線プロトコル（現在、１３．５６ＭＨｚで動作する）である。ＮＦＣシステムは典型的には、電磁結合によって近くのパッシブＮＦＣチップ／エミッタに電力供給し、次いで、チップによって発せられた、結果として生じる弱いＲＦ応答を受信するように作動する、受信機（例えば、スマートフォン）を含むが、同じスマートフォンＮＦＣ回路は、電力供給された１３ＭＨｚ送信機−テレビ、セットトップボックス、又は他のデバイスが装備可能である−によって送信される信号を受信することができる。最低の標準的なＮＦＣデータレートである１０６キロビット／秒は、ウォーターマーク関係のサービスにとって非常に十分である（また、−所望であれば−中継されたデータの極めて冗長なエラー訂正コーディングを可能にするために十分に広帯域である）。
【０２５８】
復号されたウォーターマークデータをデバイス間で中継するためのさらに別のデータチャネルは、例えば、８０２．１１ｂ、８０２．１１ｇ又は８０２．１１ｎ規格によるＷｉＦｉである。
【０２５９】
さらに別のデータチャネルは、ＩＲ通信−テレビ及びリモートコントロールが一般に通信する種類など−である。この応用例では、しかし、テレビ（又は、セットトップボックス、その他）は典型的には、受信機というよりむしろ、ＩＲ放射線のエミッタである。ＩＲ通信システムは一般に、９４０ｎｍの波長を使用する。データは、普及しているＲＣ−５プロトコルの場合、例えば、３６ＫＨｚのキャリア信号を変調することによって通信される。このプロトコルでは、リモートコントロール上の各ボタンは、１４ビットコード送信に対応し、それにより、ボタンが押されるとき、キャリア信号が変調される。ウォーターマークデータは、同様の方式で、例えば、１４ビットコードのグループを使用する（それにより、既存の復号ハードウェアがそのような使用のために構成されうるようにする）ことによって、搬送可能である。
【０２６０】
１つの特定のシステムでは、テレビ（又は、セットトップボックス）は、ボンジュール（Ｂｏｎｊｏｕｒ）サービスを使用して、復号されたウォーターマークデータの可用性を−他のデバイスに−宣伝する。公報の米国特許出願公開第２０１０／０２０５６２８号に詳述されているように、ボンジュールは、ゼロコンフ（Ｚｅｒｏｃｏｎｆ）−サービス発見プロトコル−の一実装形態である。ボンジュールは、デバイスをローカルネットワーク上で探し出し、マルチキャストドメインネームシステムサービス記録を使用して、各々が提供するサービスを識別する。このソフトウェアは、アップルＭＡＣ  ＯＳ  Ｘオペレーティングシステムに組み込まれ、また、アイフォンのためのアップル「リモート（Ｒｅｍｏｔｅ）」アプリケーションにも含まれており、そこでは、ＷｉＦｉを介してアイチューンズライブラリへの接続を確立するために使用される。ボンジュールはまた、ティーボによって、デジタルビデオレコーダ及び共有されたメディアライブラリを探し出すためにも使用される。ボンジュールを使用して、第１のデバイスは、ネットワーク上の他のデバイスに、ウォーターマークデータの可用性についてアドバイスし、他のデバイスがそのようなデータを得ることを可能にするパラメータを提供する。
【０２６１】
前述の原理を、（ウォーターマークではなく）メディアフィンガープリントに関連して採用することもできる。第１のデバイス（例えば、テレビ又はセットトップボックス）は、受信されたメディアコンテンツからフィンガープリントデータを導出し、次いで、別のデータチャネルを介して、フィンガープリントデータを第２のデバイスへ通信することができる。（代替として、第１のデバイスは、フィンガープリントデータをデータベースシステムへ送ってもよい。データベースシステムは、格納された参照データの中で近いマッチを発見して、それにより、フィンガープリントにより識別されたコンテンツに関連付けられたメタデータにアクセスしようと試みる。このメタデータは次いで、発信側の第１のデバイスへ返信されうる。この第１のデバイスは、次に、データチャネルを介して、このメタデータを第２のデバイス上へ中継する。）
スマートフォン支援パーソナルショッピングサービス
【０２６２】
本技術のさらに別の態様によれば、スマートフォンは、パーソナルショッピングサービスに関連して使用される。
【０２６３】
サービス指向の小売店−あるショッピングセンターで発見されたアップルストアなど−を考えられたい。そのような店内を見て回っている消費者は、スマートフォンを使用して、ある製品（例えば、マックブックプロ（ＭａｃＢｏｏｋ  Ｐｒｏ）コンピュータ）への好奇心を表すことがある。このことは、マックブックプロの画像を取り込むこと、又は、そうでない場合は識別情報を（例えば、デバイス上のＲＦＩＤ若しくはＮＦＣチップから、又は、関連する看板のバーコード若しくはウォーターマークから）検知することを含みうる。スマートフォンは、信号をサービスへ送り、消費者の関心を指示する。例えば、電話は、ワイヤレスで（例えば、ＷｉＦｉ又はブルートゥースによって）、画像又は検知された識別情報を、買物客サービスアプリケーションソフトウェアを実行中のバックオフィスの店のコンピュータへ送ってもよい。
【０２６４】
送信された製品情報とともに、電話はまた、バックオフィスコンピュータへ消費者の識別子をも送る。この消費者識別子は、名前、電話番号、アップル顧客番号（例えば、アイチューンズログイン識別子）、又は、フェイスブック（若しくは、他のソーシャルネットワーク）ログイン識別子、その他でありうる。買物客サービスアプリケーションソフトウェアは次いで、もしあれば、その買物客に関連付けられたプロファイル情報を取得する。このプロファイル情報は、アップルが遭遇する、その人のアップルでの履歴−購買履歴、登録されたアップルソフトウェアのリスト、及び、他の買物客についての情報を含む−を含みうる。
【０２６５】
買物客サービスアプリケーションソフトウェアは、消費者をパーソナルサービスのためのキューに入れる。キュー内で数名の顧客が前にいる場合、ソフトウェアは、買物客がサービスの前に体験する可能性が高いであろう待ち時間を予測し、この情報を消費者へ（例えば、ユーザの電話へのテキストメッセージによって）送る。
【０２６６】
店がパーソナルショッピング店員を顧客に割り当てることができるようになるまでに、遅延があるようになる場合、店は、顧客（例えば、顧客のスマートフォン又は他のコンピュータデバイス）に、時間をつぶす助けとなる、人をひきつけるコンテンツを提供してもよい。例えば、店は、買物客に、アイチューンズメディアストアから入手可能な曲、ビデオ及び他のメディアを無制限に聴く／見る権利を付与してもよい。限られた数のコンテンツ項目のフリーダウンロードが、付与されてもよい。そのような特権は、買物客が店内又は店のそばにとどまる間、継続してもよい。
【０２６７】
パーソナルショッピング店員が、顧客を手伝うために応対可能であるとき、ソフトウェアは、買物客に、店員の名前及び店員の写真を含むアラートを送る。予め、買物客のプロファイル情報の抜粋されたバージョン−短縮されたテキスト形式でハイライトを与える−が、ショッピング店員に（例えば、店員のスマートフォンに）提供されて、店員がより良いサービスを提供する助けとなりうるバックグラウンド情報が与えられている。店員は次いで、顧客に近付き、名指しで顧客に挨拶し−マックブックプロについてのいかなる質問にも答える準備ができている。
【０２６８】
パーソナルサービスのためのキューは、厳密な先着順サービスではないことがある。代わりに、アップル購買の履歴を有する買物客には、優先度が与えられ−且つ、他者の過去のアップル購買の価格に従って、キュー内で他者より前に上げられ−てもよい。買物客サービスソフトウェアは、いくつかの保護手段を適用して、既存のアップル顧客が店に入るたびに、新しい顧客が必ずしも優先度を下げられるわけではないことを保証する。例えば、キューは、限られた数の優先顧客（例えば、２人）に、キュー内で新しい顧客より前の配置が付与されるように、管理されてもよい。２人の優先顧客が新しい顧客より前に上げられた後、次の優先顧客は、キュー内で、新しい顧客の後（であるが、まだ２回動かされていない他の新しい顧客より前）に挿入される。
【０２６９】
キュー管理は、アップルとの過去の取引履歴に加えて、（又は、その履歴以外の）要素によって決まってもよい。公的データベース及び商用データベースのマイニングは、大部分の買物客についての有用な人口統計プロファイル情報の編集を可能にする。買物客サービスコンピュータが、店に入ったばかりの顧客が新型のレクサス（Ｌｅｘｕｓ）自動車のＤＭＶ登録者であると思われると決定する場合、その顧客には、古いユーゴ（Ｙｕｇｏ）を運転しているとＤＭＶ記録が指示する、より早い顧客より前の優先位置が、キュー内で与えられてもよい。（又は、店は、逆のポリシーを採用してもよい。）
【０２７０】
アップル取引情報、並びに、公的データベース及び商用データベースから収集されたデータに部分的に基づいて、顧客サービスを管理することに加えて、そのような決定は同様に、顧客によって自発的に提供された情報に基づくことが可能である。例えば、「デジタルウォレット」技術は、個人が、自分のスマートフォン又は他のデバイスから、他者−小売店を含む−へ、自分自身についてのある人口統計及び他のプロファイル情報を容易に共有できるようにする。顧客サービスキュー内の顧客の位置は、そのような自分で明らかにした情報に基づいてもよい。消費者は、自分についてのより多くの情報を入手可能にするほど、より良い顧客サービスが提供されることを発見することがある。
【０２７１】
前述の機能性は、顧客のスマートフォンにダウンロードされたアプリケーションプログラムを介して、又は、顧客が誘導される先のウェブサービスとして実装されてもよい。又は、機能性の多くは、テキスト（画像）メッセージング構成−店が任意選択で、他の標準スマートフォンソフトウェア（例えば、ウェブブラウザ又はアイチューンズソフトウェア）を呼び出すリンクを提供する−によって実装されてもよい。
好都合な互換性判定
【０２７２】
本技術のさらなる態様によれば、スマートフォンは、ある電子デバイスとともに有用であるアクセサリを迅速に識別するために使用される。
【０２７３】
例示的シナリオは、フライズ（Ｆｒｙ’ｓ）など、電子機器の小売店に入る買物客が、自分のＨＴＣサンダーボルト（Ｔｈｕｎｄｅｒｂｏｌｔ）スマートフォン用の保護ケースを探すことである。店には、スマートフォンケースの壁がある。従来技術では、買物客は、異なる各パッケージを吟味し、そのケースが合うスマートフォン（複数可）の指示を探すようになる。このことには、壁からケースの多数を取り外し、ケースをひっくり返し−細かい文字を読むことが必要となりうる。フラストレーションがすぐに生じる。
【０２７４】
本技術のこの態様によれば、小売店は、ソフトウェアツールを入手可能にし、ソフトウェアツールが、ユーザのスマートフォン（又は、他のデバイス）にダウンロードされうる。又は、ツールは、ウェブサービスとして提供されてもよい。ユーザは、アクセサリ（ケース、充電器、その他）を含みうるドロップダウンメニューによってなど、何を探し中であるかを指示するように勧められる。ユーザが「アクセサリ」を選択するとき、さらなるダイアログが、アクセサリが探されている製品について尋ねる。ユーザは、「ＨＴＣサンダーボルト」と入力する（又は、ドロップダウンメニューから選択する）。（この情報は、多数の他の方法で収集されることがあり−このデータ収集段階の特定の実装形態は、特定の店の事情に合わせて構成されうることは、当業者には理解されよう。）
【０２７５】
店のソフトウェアが、顧客の使命を、ＨＴＣサンダーボルト電話用のアクセサリを識別するものとして識別する、データを収集すると、店のソフトウェアは次いで、データベースを検索して、その店の在庫品のうち、そのようなデバイスと互換性があるすべての製品を識別する。このことは、店の製品のためのデータシートをテキスト検索して、関連キーワードを有する製品を識別することによって、行われうる。又は、アクセサリのベンダが、そのような互換性情報を、標準化された形式−ＵＰＣコードのリストによって、又は、アクセサリが互換性を有する各製品のための他のそのような識別子など−で、店が使用できるようにしてもよい。
【０２７６】
１つの特定の実装形態では、店は、互換性のある製品の識別子のリストを、買物客のデバイスにダウンロードする。ソフトウェアは次いで、買物客に、保護用スマートフォンケースの陳列（買物客がまだそこにいない場合、８Ｂ通路の中ほどで発見される）を物理的にスキャンするようにアドバイスし、ＨＴＣサンダーボルトと互換性のあるアクセサリに対して、電話が青信号を表示する（又は、別の確認信号を出力する）ことを、買物客に知らせる。
【０２７７】
スキャニング機構は、−やはり事情に応じて−様々な種類のものでありうる。製品パッケージにはそれぞれ、ＲＦＩＤ又はＮＦＣチップが装備されてもよく、このチップは、電話が近接近に持ち込まれるとき、スマートフォンに対して製品を電子的に識別する役目を果たす。（ＮＦＣリーダは、間もなく、大部分のスマートフォンの標準機能になるであろう。）又は、画像認識技法を使用することができる。（多数であるが、限られた数の保護ケースが壁にあり、各々が異なるパッケージを有する。店のコンピュータは、ストリーミングカメラデータの解析によって、ＳＩＦＴ又はＳＵＲＦデータなどの視覚的フィンガープリントデータ、又は、それによりスマートフォンがこの限られた多数から特定のパッケージを視覚的に識別することができる他の特性的情報を、ダウンロードすることができる。）
【０２７８】
さらに別の構成では、スマートフォンは、そのカメラによって取り込まれた画像をウォーターマーク検出器に適用し、ウォーターマーク検出器は、製品パッケージのアートワークに符号化された複数ビットデータを抽出する。又は、バーコード読み取りを使用することができる。
【０２７９】
電話が近くの製品から識別子を取り入れるとき、予めダウンロードされた、互換性のあるデバイスのための識別子のリストが、マッチについてチェックされる。スキャンされた製品の識別子が、ダウンロードされた互換性のある製品のリストの中で発見される場合、適切な指示がユーザに対して出力される。
【０２８０】
そのような構成によって、スマートフォンは、ガイガーカウンタに類似した方法で作動する。顧客が電話を、陳列された保護ケースに沿って動かすとき、電話は、顧客の注目を関心のある特定のアイテム（すなわち、ＨＴＣサンダーボルト電話を保護するように構成されたケース）に集めるように、信号を出す。ユーザは次いで、どのケースが購買のために適した候補であるかという基本的な疑問で頭を悩ませるのではなく、他の考慮すべき事柄（例えば、価格及び美しさ）に問い合わせを集中させることができる。
【０２８１】
前述の構成は、多数の変形を受けるが、なお、互換性へのインタラクティブなガイドを提供することは理解されよう。例えば、店は、互換性のある識別子のリストをスマートフォンにダウンロードする必要はない。代わりに、スマートフォンは、検知された識別子を店のコンピュータへ送ることができ、店のコンピュータは次いで、そのような識別子を、互換性のある製品のリストに対してマッチングすることができる。同様に、互換性のある製品のリストが事前に生成される必要はない。代わりに、店のコンピュータは、スキャンされた識別子を顧客のスマートフォンから受信し、次いで、オンザフライで、（例えば、次いで、その製品に関連付けられたデータを呼び戻し、ＨＴＣサンダーボルト電話が互換性のある製品の１つであるという指示についてチェックすることによって）スキャンされた製品に互換性があるかどうかを判定することができる。
【０２８２】
同様に、検知されたパッケージからの製品識別子の検出は、電話によって行われる必要はない。例えば、カメラ画像が電話から店のコンピュータへ流されてもよく、そこで、カメラ画像を（例えば、パターン認識技法、ウォーターマーク認識技法、又はバーコード認識技法によって）処理して、関連付けられた識別子を得ることができる。
【０２８３】
識別子は、製品パッケージから見極められる／導出される必要はない。棚のタグ又は他のマーキングもまた、製品識別のための基礎としての役目を果たすことができる。
【０２８４】
特定の実装形態に応じて、識別子をマッピング又は変換して、互換性を判定するステップがあってもよい。例えば、棚のタグは、店の独自のＳＫＵ番号を持つことがある。しかし、それにより互換性が指示される参照データ（例えば、製品のデータシート）は、ＵＰＣコードによって製品を識別してもよい。このようにして、システムは、互換性の判定において、検知されたＳＫＵ番号からＵＰＣコードを調べる必要がありうる。
【０２８５】
当然、これらの原理は、ビデオプレイヤのための車内充電器の発見、携帯電話のための不明瞭なバッテリの発見、又は、カメラのためのメモリカードの発見など、他の関連製品の対に適用可能である。
コンピュテーショナルフォトグラフィ（Ｃｏｍｐｕｔａｔｉｏｎａｌ  Ｐｈｏｔｏｇｒａｐｈｙ）及びサブリミナルな参照情報
【０２８６】
コンピュテーショナルフォトグラフィは、取り込まれた画像データをアルゴリズムにより改変して、向上した形式の画像を生じる、画像処理技法を指す。一例は、画像ぼけ除去である。
【０２８７】
画像ぼけは、必然的に小さいサイズのカメラ開口部による、スマートフォンカメラに特有の問題であり、センサへ送られる光の量が制限されるので、比例して延ばされた露光時間が必要となる。延ばされた露光時間により、ユーザがより長い期間にわたってカメラを固定して押さえることが必要となり−モーションブラーのリスクが増す。（そのような電話の軽量さもまた、モーションブラーのリスクを増す−そのような電話には、ＳＬＲなど、より重いカメラが提供する慣性安定度が欠如している。）
【０２８８】
ぼけは、動き以外の現象によって導入されることがある。例えば、レンズ光学系は典型的には、特定の焦点面及び被写界深度内で被写体に焦点を合わせる。焦点が合った視野の外側にあるオブジェクトは、ぼける（いわゆる「焦点ぼけ」）。
【０２８９】
ぼけ関数を、数学的に特徴付けることが可能であり、特徴付けると、逆関数の適用によって打ち消すことが可能である。しかし、ぼけ関数は通常、直接測定することができず、むしろ、典型的には推定され、反復改良されなければならない。ぼけた画像からぼけ関数を回復すること（ブラインドデコンボリューション（ｂｌｉｎｄ−ｄｅｃｏｎｖｏｌｕｔｉｏｎ）問題として知られる）は、不確実な努力であり、その理由は、ぼけた画像のみでは、典型的には部分的制約のみをもたらすからである。
【０２９０】
代替的な元の画像間の曖昧性除去、及び、関連付けられたぼけ関数（一般に、ぼけ「カーネル」）のより良い推定を助けるため、ぼけていない元の画像についての何か−いわゆる「事前制約」（又は、単に「画像プライア（ｉｍａｇｅ  ｐｒｉｏｒ）」）を知ることが助けになる。
【０２９１】
例えば、特許出願公開２００９０３２４１２６では、マイクロソフト（Ｍｉｃｒｏｓｏｆｔ）の研究者は、画像が一般に、類似する配色の領域によって特徴付けられることを観察している。多少ぼけたとしても、これらの領域は、その同じ全体的な配色を保持する傾向がある。局所的な画像の色は、ぼけに対して不変である傾向があるので、ぼけ関数のより良い推定を生じる助けとなるように使用することができる、画像プライアとしての役目を果たすことができる。
【０２９２】
別の画像プライアは、ハッブル（Ｈｕｂｂｌｅ）望遠鏡からの画像の鮮明化を助けるために使用されたが、ハッブル望遠鏡は元々、歪みを導入する鏡の変形を欠点として持っていた。取り込まれた画像における大部分の光源が円板（又は、点光源）であったことは、理解された。この知識により、候補の矯正的なぼけカーネルを、処理された画像がそれらの元の円板の形で星を描くまで、反復して修正することができた。（例えば、Ｃｏｇｇｉｎｓ他、Ｉｔｅｒａｔｉｖｅ／Ｒｅｃｕｒｓｉｖｅ  Ｄｅｃｏｎｖｏｌｕｔｉｏｎ  ｗｉｔｈ  Ａｐｐｌｉｃａｔｉｏｎ  ｔｏ  ＨＳＴ  Ｄａｔａ」、ＡＳＰ  Ｃｏｎｆｅｒｅｎｃｅ  Ｓｅｒｉｅｓ、Ｖｏｌ．６１、１９９４年、及び、Ａｄｏｒｆ、「Ｈｕｂｂｌｅ  Ｓｐａｃｅ  Ｔｅｌｅｓｃｏｐｅ  Ｉｍａｇｅ  Ｒｅｓｔｏｒａｔｉｏｎ  ｉｎ  ｉｔｓ  Ｆｏｕｒｔｈ  Ｙｅａｒ」、Ｉｎｖｅｒｓｅ  Ｐｒｏｂｌｅｍｓ、Ｖｏｌ．１１、６３９、１９９５年を参照。）
【０２９３】
（別のグループのぼけ除去技法は、取り込まれた画像の特徴についての事前情報に焦点を合わせておらず、むしろ、画像取り込みについての技術的属性に関する。例えば、以前に言及したマイクロソフトの研究チームは、カメラに慣性センサ（例えば、加速度計及びジャイロスコープ）を装備して、画像露光中のカメラの動きについてのデータを収集した。この動きデータが次いで、矯正的なぼけカーネルの推定において使用された。Ｊｏｓｈｉ他、「Ｉｍａｇｅ  Ｄｅｂｌｕｒｒｉｎｇ  Ｕｓｉｎｇ  Ｉｎｅｒｔｉａｌ  Ｍｅａｓｕｒｅｍｅｎｔ  Ｓｅｎｓｏｒｓ」、ＳＩＧＧＲＡＰＨ  ’１０、Ｖｏｌ  ２９、Ｎｏ  ４、２０１０年７月を参照されたい。（対応する特許出願が、シーグラフ（ＳＩＧＧＲＡＰＨ）より前に出願されたとも考えられている。）アドオンハードウェアセンサを有するＳＬＲとの関連で詳述したが、出願人は、マイクロソフトの方法が、スマートフォンとともに使用するために適していると考える（スマートフォンには、ますます３Ｄ加速度計及びジャイロスコープが装備されるようになっており、アップルアイフォン４を参照）。）
【０２９４】
本技術の別の態様によれば、既知の参照情報が、カメラ（例えば、スマートフォン）によって撮像されうるシーンに導入されて、画像の向上を可能にする画像プライアがもたらされる。
【０２９５】
図１２に描かれたシリアルの箱を考えられたい。そのアートワークは、空間周波数が高すぎて人間の観察者には見えないマーカ特徴により、サブリミナル的に符号化される。それでも、これらのマーカの形及び周波数は、事前に知られている。（これらのマーカは典型的には、一般的なウォーターマーキング技法によって標準化される。一例は、ディジマーク画像ウォーターマーキング技術であり、アドビ（Ａｄｏｂｅ）フォトショップ（Ｐｈｏｔｏｓｈｏｐ）とともに提供される。）これらのマーカを、このようにして画像プライアとして使用することができ−シリアルの箱の画像を、いかなるモーションブラー−又は、焦点ぼけ−をも打ち消すように処理することができる。
【０２９６】
事前情報を、空間周波数ドメイン内で使用することができ（事前情報が、インパルス関数の五角形の配列として現れる）、又は、ピクセルドメイン内で使用することができる（事前情報が、特性的織り込みパターン−周波数が高すぎて、見る人によって見極めることができないが、カメラにより取り込まれた画像から検出可能−として現れる）。
【０２９７】
知られているブラインドデコンボリューション技法を使用して、そのようなプライアは、ぼけカーネルの反復改良を可能にし、ぼけカーネルが次いで、取り込まれた画像内のいかなるぼけをも打ち消すために適用されうる。
【０２９８】
例示的実装形態は、リチャードソン−ルーシー（Ｒｉｃｈａｒｄｓｏｎ−Ｌｕｃｙ）技法を使用し、この技法は、Ｒｉｃｈａｒｄｓｏｎ、「Ｂａｙｅｓｉａｎ−Ｂａｓｅｄ  Ｉｔｅｒａｔｉｖｅ  Ｍｅｔｈｏｄ  ｏｆ  Ｉｍａｇｅ  Ｒｅｓｔｏｒａｔｉｏｎ」、Ｊ．Ｏｐｔ．Ｓｏｃ．Ａｍ．６２、５５〜５９、１９７２年、及び、Ｌｕｃｙ、「Ａｎ  Ｉｔｅｒａｔｉｖｅ  Ｔｅｃｈｎｉｑｕｅ  ｆｏｒ  ｔｈｅ  Ｒｅｃｔｉｆｉｃａｔｉｏｎ  ｏｆ  Ｏｂｓｅｒｖｅｄ  Ｄｉｓｔｒｉｂｕｔｉｏｎｓ」、Ｔｈｅ  Ａｓｔｒｏｎｏｍｉｃａｌ  Ｊｏｕｒｎａｌ、Ｖｏｌ．７９、Ｎｏ．６、１９７４年６月という、２つの出版物に遡る。そのような方法は、その後の数十年間において改良されている。例は、マイクロソフト及びＭＩＴによる特許出願、例えば、２０１０１２３８０７、２００８２４０６０７、２００８０２５６２７、２０１００７４５５２、及び２００９２４４３００に示されている。
【０２９９】
ピクセルドメイン内の大部分のぼけは、−周波数ドメイン内のぼけとしてよりもむしろ−フーリエドメイン内の高周波数での強度の低減として、より明示される。よって、フーリエドメイン内で鮮明に定義されたパターンを発見する能力は、−フーリエドメイン信号の振幅が十分であるとすれば−ピクセルドメインぼけに耐える傾向がある。特定の応用例における特定の振幅は、ヒューリスティックに決定されうる。わずかなぼけのみの補正が予想される（例えば、スマートフォンカメラの応用例における小さい手の震えによるモーションブラー）場合、比較的低い振幅のフーリエマーカ信号が採用されうる。より大きなぼけが予期される場合、より強いマーカ信号が使用されるべきである。（振幅の減少は、マーカ（複数可）を比較的より低い周波数に、例えば、図１１の線２１７により近くなるように置くことによって、軽減されうる。）
【０３００】
今述べたように、マーカ信号は、ぼけ補償に関してその有用性を最適化するように、周波数が調整されうる。マーカ信号はまた、形も調整されうる。例えば、−図１１の場合のように−５つのインパルス関数から構成されるマーカの代わりに、ぼけ軽減マーカ信号は、１つ又は２つなど、より少ない数の要素を備えてもよい。同様に、インパルス関数成分の代わりに、そのようなマーカは、水平に、垂直に、及び／又は、中間の角度で配置された細長い区分からなり−モーションブラーの存在下でロバスト性の改善を助けてもよい。一例は、図１４に示すパターン３０２である。
【０３０１】
特許６，５９０，９９６に詳述されているように、ウォーターマーク信号は、様々なセットの信号要素を含みうる。１つのセットは、登録信号のセットを備えうる。登録信号は、比較的強力に符号化され、ウォーターマーキングされた画像の変換、スケール及び回転を決定できるようにする。これらのパラメータがわかると、このようにして知らされたウォーターマーク検出器は次いで、ウォーターマークペイロードデータの大部分（又は、すべて）を搬送する、第２のセットの要素を回復することができ、第２のセットの要素は、より多数である（且つ、典型的にはより弱く符号化される）。
【０３０２】
図１１及び図１４のマーカ信号を、特許６，５９０，９９６の登録信号のような方法で使用して、取り込まれた画像についてのアフィンパラメータを決定することができる。そして、図１１及び図１４のマーカ信号はまた、ぼけ補正のために、画像プライアを提供する二重の目的を果たすこともできる。
【０３０３】
特定の実施形態では、パターン２１０／３０２によって提供されたサブリミナルなマーカを画像プライアとして使用して、ブラインドデコンボリューションが、ぼけた画像に適用される。反復補正が画像に適用されて、−画像をより鮮明な形に復元することを求めて−ぼけ効果が低減される。（ぼけ補正されたフーリエドメインマーカ信号の強度を評価することは、使用可能な１つのメトリックである。）ウォーターマーク読み取り動作が次いで、ぼけ補償された画像において行われ−複数ビットペイロード情報の回復が可能にされる。このようにして、結果として好循環が生じ−マーカ信号は、画像のぼけ除去において有用であり、結果として生じるぼけ除去された画像は、より良く復号されたウォーターマークの結果を生じる。
【０３０４】
いくつかの実施形態では、ウォーターマークペイロードは、元の画像についての統計値を搬送する様々なビットを含んでもよい。非常に様々な画像統計値が、従来技術では、ぼけの除去を支援するために、画像プライアとして使用されている。従来技術に関する問題は、しかし、−ぼけた画像のみが使用可能であるときに−信頼できる画像統計値を得ることである。デジタルウォーターマークは、そのような情報を画像からぼけ除去システムへ確実に搬送することができる、チャネルを提供することができる。
【０３０５】
いくつかの実施形態では、マーカ信号２１０／３０２は、それら自体で情報を搬送することができる。例えば、成分マーカ要素の位相を選択的に反転させて、限られた数のビットを搬送することができる。このように搬送されうる１つの画像統計値は、元のアートワークの平均輝度である。この統計値は、異なる反復されるぼけ解決策の精度の評価において有用である制約を提供する。
【０３０６】
（異なるウォーターマークペイロードを、アートワークの異なる領域−一般に、長方形のタイル−内で符号化することができる。これにより、いくつかの局所統計値が搬送可能になる。例えば、図１２に描かれたシリアルの箱のアートワークは、６×４のウォーターマークタイルの配列を備え、２４個の異なる空間領域のための統計値を搬送可能にしてもよい。）
【０３０７】
大部分の画像は、シリアルの箱を含んでいない。しかし、ウォーターマーキングされたデータは、多数の一般の環境に挿入可能であり、上記で説明したように、画像プライアを提供する役目を果たすことができる。例えば、カーペット及び室内装飾材料の織物は、ウォーターマークパターンを含みうる。そのようなウォーターマークパターンが発見されるいかなる環境でも、そのような環境で取り込まれた画像の品質を、前述のぼけ補正技法によって向上させることができる。（他のコンピュテーションフォトグラフィ方法は同様に、そのようなウォーターマーク信号に依拠することができる。）
【０３０８】
大部分の実施形態は、信号の周波数のために人間の視覚的知覚の範囲外（例えば、図１１及び図１４の円２１７の外側）である、ウォーターマーク信号を使用するが、他の実施形態では、信号のクロミナンスのために注意を免れる、ウォーターマーク信号が追加されてもよい。人間の目は、例えば、黄色に対して比較的鈍感である。したがって、既知のマーカパターンが、黄色で印刷される場合、より低い周波数で挿入されてもよい。同様に、一般に人間の知覚の範囲外にあるが、画像センサによって検出可能である、他のインクもまた使用可能である。
【０３０９】
先を見越すと、フリッカー（Ｆｌｉｃｋｒ）及びフェイスブックなど、オンライン写真リポジトリは、アップロードされた画像を、ウォーターマークについてルーチン的にチェックしてもよい。ウォーターマークが発見されるときはいつでも、サービスは、コンピュテーショナルフォトグラフィ方法でそのような信号を採用して、画像を向上させることができる。
【０３１０】
（事後の画像補正手順との関連で説明したが、同じ技法を、画像取り込み処理前又は処理中に同様に採用することができる。例えば、サブリミナルなマーカ信号は、焦点がどこで確立されるべきかの決定において、カメラの自動焦点システムを支援することができる。）
さらにぼけについて
【０３１１】
引用したＪｏｓｈｉ他の論文は、ぼけカーネルの推定値を改良するために、慣性データをどのように使用することができるかについて、教示している。しかし、慣性データのより簡単な適用は、最終的により広範囲に有用となりうる。
【０３１２】
１つの特定の構成では、スマートフォンカメラは、画像フレームのシーケンスを（例えば、ストリーミング取り込み、又は、ビデオモードで）取り込む。各フレーム中に、電話の動きが、−電話の３Ｄジャイロスコープ及び／又は加速度計によってなど−検知される。画像フレームのストリームのうち選択された（つまり、低い電話の動きに基づいて選択された）ものが次いで、位置合わせ及び結合され、向上した画像として出力される。
【０３１３】
そのような向上した画像は、例えば、デジタルウォーターマーク検出器に適用されうる。画像の向上により、検出器は、復号された情報をより迅速に出力できるようになり（その理由は、検出器が周辺信号の回復においてそれほど長く機能する必要がないためである）、よりロバストなウォーターマーク回復（例えば、不十分な照明、画像破損、及び他の課題にもかかわらず、復号すること）が可能になる。
【０３１４】
結合されることになる画像フレームの選択は、異なる方式で進むことが可能である。例えば、動き閾値を（例えば、ジャイロスコープにより検知された、毎秒の回転度で）設定することができ、その閾値を下回る動きを有するフレームを結合することができる。（又は、別のビューでは、その閾値を上回る動きを有するフレームが無視される。）結合されることになるフレームの数を事前に設定する（例えば、閾値基準を満たす最初の６個のフレームを使用する）ことができ、又は、この技法は、そのようなテストに合格するシーケンス内のすべてのフレームを利用することができる。別のオプションは、対象のフレームカウントに関する閾値（例えば、１０）を設定し、次いで、−取り込まれたフレームのシーケンスから−（値がどのようなものでも）最低値の動きデータを有する、対象数のフレームを選択することである。
【０３１５】
フレームの結合は、簡単な平均によるものでありうる。又は、加重平均を使用することができる。各フレームに割り当てられる重みは、関連付けられた動きデータによって決まってもよい。重み付けは、より詳細には、フレームのそれぞれの動きデータ間の関係に基づくので、フレームが「より静止している」ほど、フレームがより平均に寄与するようになることが望ましい。１つ又は複数のフレームがゼロの動きを有する場合、最大の重み値が与えられるべきであり、ゼロでない動きの値を有するフレームには、ゼロの重み値が与えられるべきであることが好ましい。そのようなフレーム依存の重み付け係数「ｋ」を確立するための１つのアルゴリズムは、以下の通りである。
ｋＡ＝［Ｍｏｔｉｏｎ（ＦｒａｍｅＭＩＮ）／Ｍｏｔｉｏｎ（ＦｒａｍｅＡ）］Ｘ
但し、ｋＡは、フレーム「Ａ」のための重み付け係数であり、Ｍｏｔｉｏｎ（ＦｒａｍｅＡ）は、フレーム「Ａ」の毎秒の度単位の動きであり、Ｍｏｔｉｏｎ（ＦｒａｍｅＭＩＮ）は、選択されたセット内のフレームのすべての中の最小の動きであり、Ｘは、指数関数的比率係数（ｅｘｐｏｎｅｎｔｉａｌ  ｒａｔｉｏ−ｉｎｇ  ｆａｃｔｏｒ）である。
【０３１６】
ぼけを低減することに加えて、そのような技法はまた、スマートフォンにより取り込まれた画像の雑音を除去するためにも有効である。
ハイブリッドウォーターマーク／顕著点／バーコード／ＮＦＣ構成
【０３１７】
以前に引用した米国特許出願第１３／０７９３２７号は、印刷された文書（例えば、新聞）から取り込まれた画像が、スマートフォン画面上に補助情報とともにレンダリングされ、補助情報が、幾何学的に登録された方式でオーバーレイされる構成を、詳述している。公開された出願２００８０３０００１１は、関連技術を詳述している。
【０３１８】
これらの今述べた出願の好ましい実施形態は、ページ内に符号化されたウォーターマーク信号の登録信号成分を参照することによって、ページに対するスマートフォンの姿勢を見極める。このウォーターマークのペイロードが、ページに関係付けられた補助情報を含むデータベースにアクセスするために使用される。この補助情報は次いで、ページから取り込まれた画像の上で、見極められた姿勢によって決まる画面上の位置にオーバーレイされる。
【０３１９】
以前に引用した米国特許出願第１３／０１１６１８号は、やや異なる構成を教示しており、ユーザが、スマートフォン画面上に提示された、撮像されたページの一部分をタップする。取り込まれた画像から復号されたウォーターマークペイロードは、データベースへ送られ、データベースは、見られているページに対応するページレイアウト情報を返す。（ページレイアウトデータは、ページを構成するときに使用されたパブリッシングソフトウェアから以前にエクスポートされ、データベース格納された。）ウォーターマークの登録信号成分から見極められたスケール及び回転情報を、取得されたページレイアウトデータとともに参照することによって、電話は、ユーザのタップによって指示された物理的ページ上の座標（例えば、印刷されたページの左上角から４インチ下、及び、６インチ右）を決定する。これらの決定されたページ座標を参照することによって、ページのその特定の部分に関する補助情報が識別され、スマートフォン画面上に提示される。
【０３２０】
本技術の別の態様によれば、印刷されたページ−又は、他のオブジェクト−上の異なるロケーションに対応する情報を提示するための、異なる構成が利用される。
【０３２１】
１つの特定の実施形態では、ページに対するスマートフォンのロケーションは、ウォーターマーク信号の登録成分を参照することによって決定されない。代わりに、復号されたウォーターマークペイロードがリモートサーバ（データベース）へ送られ、リモートサーバ（データベース）が、ページについての情報を返す。米国特許出願第１３／０１１６１８号とは異なり、しかし、返される情報は、パブリッシングソフトウェアからエクスポートされたページレイアウトデータではない。代わりに、データベースは、ページ上に存在する顕著点（特徴）についての、以前に格納された参照データを返す。
【０３２２】
（顕著点は、例えば、ページの最上の角から下及び横に数インチによってなど、元のページ上の顕著点の座標に関して簡単に識別されうる。加えて、又は代替として、他の情報−典型的には、特徴ベクトル−を提供することができる。個々の、無関係な点を識別する代わりに、データベースから返される情報は、顕著点の配列を特徴付けてもよい。）
【０３２３】
スマートフォンは、様々な方法で見られているページ上の参照顕著点についてのこの知識を使用することができる。例えば、スマートフォンは、データベースによって識別された顕著点を、電話の視野内で発見された顕著点とマッチングすることによって、ページのどの特定の部分が撮像されているかを識別することができる。
【０３２４】
ユーザに提示された補助データもまた、顕著点の機能でありうる。例えば、スマートフォンは、リモートサーバへ、電話の視野内でマッチングされる識別された顕著点のリストを送信することができる。このサブセットは、見られているページの領域を正確に位置測定する役目を果たすので、その領域に特に対応する（例えば、ユーザにとって関心のある特定の記事に対応する）補助情報を、電話に返すことができる。代替として、例えばページの全体に、又は、新聞のすべてのページに対応する、より大きいセットの補助データを、ウォーターマークペイロードに応答して、データベースから返すことができる。スマートフォンは次いで、このより大きいセットのデータの中から選択し、（顕著点によって決定されるような）撮像されている特定のページ抜粋に対応するサブセットのみを提示することができる。ユーザが電話を動かして、オブジェクトの異なる部分を撮像するとき、異なるサブセットを迅速に提示することができる。
【０３２５】
データベースによって返された参照顕著点を利用することができる別の方法は、ページに対する電話の姿勢の決定におけるものである。オブジェクトに対するカメラの３Ｄ姿勢は、カメラレンズを通したその視野の投影とともに、取り込まれた画像内のどこに顕著点が現れるかを一意に決定する。取り込まれた画像、及び、オブジェクトの平面ビュー内の顕著点の位置についての参照データが与えられると、３Ｄ姿勢を決定することができる。（正確な姿勢の決定には、例えば、焦点距離及び画像フォーマットなど、カメラ／レンズによって影響を受ける投影についてのある情報が必要となる。）
【０３２６】
オブジェクトの姿勢が決定されると、任意のオーバーレイされる情報を、例えば、ページのスマートフォンのビューにマッチする回転、スケール、変換、及び／又は、アフィン若しくは遠近ワープとともに、下にある画像に幾何学的に登録することができる。
【０３２７】
（情報を画像上に、顕著点に基づいて、幾何学的に登録される方式でオーバーレイすることは、拡張現実から知られている。例えば、特許文献７，６１６，８０７、７，３５９，５２６、２００３００１２４１０、及び２０１００２３２７２７、並びに、記事、Ｒｅｉｔｍａｙｒ、「Ｇｏｉｎｇ  Ｏｕｔ：Ｒｏｂｕｓｔ  Ｍｏｄｅｌ−ｂａｓｅｄ  Ｔｒａｃｋｉｎｇ  ｆｏｒ  Ｏｕｔｄｏｏｒ  Ａｕｇｍｅｎｔｅｄ  Ｒｅａｌｉｔｙ」、Ｐｒｏｃ．  ５ｔｈ  ＩＥＥＥ／ＡＣＭ  Ｉｎｔ．  Ｓｙｍｐ．  ｏｎ  Ｍｉｘｅｄ  ａｎｄ  Ａｕｇｍｅｎｔｅｄ  Ｒｅａｌｉｔｙ、２００６年、１０９〜１１８ページ、及び、Ｇｅｎｃ、「Ｍａｒｋｅｒ−ｌｅｓｓ  Ｔｒａｃｋｉｎｇ  ｆｏｒ  ＡＲ：Ａ  Ｌｅａｒｎｉｎｇ−Ｂａｓｅｄ  Ａｐｐｒｏａｃｈ、Ｐｒｏｃ．  １ｓｔ  ＩＥＥＥ／ＡＣＭ  Ｉｎｔ．  Ｓｙｍｐ．  ｏｎ  Ｍｉｘｅｄ  ａｎｄ  Ａｕｇｍｅｎｔｅｄ  Ｒｅａｌｉｔｙ、２００２年、２９５〜３０４ページを参照されたい。）
【０３２８】
１つの特定の構成では、データベースはまた、スマートフォンに提供された顕著点情報に関係付けられた、スケール及び回転データをも返す。例えば、データベースは、どの方向が撮像されたオブジェクトの上部に向かう（すなわち、垂直である）かを指示するために有用な数値を返してもよい。この値は、例えば、垂直と、最初にリストされた顕著点と最後にリストされた顕著点との間の直線との間の、角度を表現することができる。同様に、データベースは、オブジェクト（例えば、新聞）が当初印刷されたスケールにおける、最初にリストされた顕著点と最後にリストされた顕著点との間の距離−インチ単位−を指示する数値を返してもよい。（これらの簡単な例示は、例示的でしかないが、概念を例示する役目を果たす。）
【０３２９】
関連して、データベースから返された顕著点はまた、グラフィカルなしるし−ボックス、縁、メニュー、その他など−のサイズ決定及び位置決めにおけるガイドとしての役目を果たすこともできる。例えば、スマートフォンは、電話の表示上で境界ボックスを−５、３２、４４及び６５と番号付けされた顕著点を包含するためにちょうど十分な大きさのサイズで、縁部が表示の縁部に対して平行であるように−レンダリングするように命令されうる。顕著点は同様に、それを参照することによって他の情報がサイズ決定又は提示されうる、オブジェクト内の目安としての役目を果たすことができる。
【０３３０】
参照顕著点情報のさらに別の使用は、焦点距離など、カメラのレンズシステムの固有のパラメータの決定におけるものである。典型的には、そのような仕様は、メーカーから入手可能であり、又は、カメラによって出力されたメタデータ内で（例えば、ＥＸＩＦデータ内で）入手可能である。しかし、不明の場合、写真測量法の分野の当業者にはよく知られているように、レンズパラメータを、既知の顕著点を含む画像の解析から経験的に決定することができる。（他者は、そのような方法の実装において、Ｈａｒｔｌｅｙによる書籍、「Ｍｕｌｔｉｐｌｅ  Ｖｉｅｗ  Ｇｅｏｍｅｔｒｙ  ｉｎ  Ｃｏｍｐｕｔｅｒ  Ｖｉｓｉｏｎ」、Ｃａｍｂｒｉｄｇｅ  Ｕｎｉｖｅｒｓｉｔｙ  Ｐｒｅｓｓ、２００４年、及び、Ｐｏｌｌｅｆｅｙｓによる論文、「Ｓｅｌｆ−Ｃａｌｉｂｒａｔｉｏｎ  ａｎｄ  Ｍｅｔｒｉｃ  ３Ｄ  Ｒｅｃｏｎｓｔｒｕｃｔｉｏｎ  ｆｒｏｍ  Ｕｎｃａｌｉｂｒａｔｅｄ  Ｉｍａｇｅ  Ｓｅｑｕｅｎｃｅｓ」、Ｃａｔｈｏｌｉｃ  Ｕｎｉｖｅｒｓｉｔｙ  ｏｆ  Ｌｅｕｖｅｎ、１９９９年など、参考文献を調べることができる。）
【０３３１】
上記で説明した構成では、ウォーターマーク信号の登録成分は使用されず、ウォーターマークのペイロードのみが採用される。そのような構成では、他のデータ搬送機構が代替として使用されてもよく、バーコード、ＯＣＲ、近距離無線通信チップ（ＲＦＩＤ）、その他などである。
【０３３２】
埋め込まれたか、又は取り付けられたＮＦＣチップを含む、印刷されたポスターを考えられたい。ＮＦＣリーダが装備されたスマートフォンは、ポスターのＮＦＣチップから複数シンボル識別子−ポスターを識別する役目を果たす−を検知する。このポスター識別情報は、電話によってデータベースへ送信され、データベースは、ポスターに関連付けられた顕著点を返す。ユーザは次いで、位置依存の方法で、ポスターとインタラクトすることができる。
【０３３３】
例えば、全体としてポスターに一般的である応答データを提示する（すなわち、典型的なＮＦＣ使用モデルの）代わりに、ユーザは、スマートフォンカメラで、ポスターの異なるエリアを撮像することができる。電話は、取り込まれた画像内の顕著点を識別し、識別した顕著点を、ＮＦＣポスター識別データの提出に応答してデータベースから返された顕著点とマッチングする。そのような構成によって、スマートフォンは、ポスターのどのような抜粋が撮像されているか（及び、望むなら、ポスターに対する電話の姿勢）を見極める。そのような抜粋に特に対応する補助情報が次いで、ユーザに（望むなら、幾何学的に登録された画面オーバーレイとして）提示される。このようにして、そのようなユーザは、ポスターの第１の部分を見ている場合、ある応答が提示され、ポスターの第２の部分を見ている場合、異なる応答が提示されうる。
【０３３４】
より一般には、そのような顕著点の方法は、極めて正確なロケーション決定方法−例えば、ＧＰＳよりも分解能がはるかに細かい−としての役目を果たすことができる。ポスターを含む現場を考えられたい。ポスター上の固定点（例えば、ポスターの中心）の位置が、事前に決定され、そのような情報が、ポスターに含まれたＮＦＣチップのペイロードによって識別されたデータベースレコードに格納される（又は、チップのデータペイロードの一部として符号化される）。基準点の位置は、緯度／経度／高度（ジオロケーションデータ）など、様々な形式で、又は、単に、ポスターの顕著点に対するそのロケーション（例えば、ポスターの中心、又は、左上角）によって、表現されてもよい。ロケーションデータはまた、姿勢情報、例えば、ポスターが向いているコンパス方向、及び、ある場合、その水平及び垂直の傾き（度単位）をも含みうる。このＮＦＣチップを検知するユーザは、ポスターのロケーション座標、並びに、ポスターアートワークに関する顕著点情報を、データベースから得る。スマートフォンは次いで、電話の現在の観点から取り込まれた画像を解析し、ポスターに対する電話の姿勢を見極める（例えば、中心から３インチ右、４インチ下、及び、ポスターから２４インチ、１０度の傾きで上方を、２０度の角度で右の方を見ており、電話はポスターに対して時計回りに４度傾いている）。この顕著点により決定された姿勢情報を、ポスターの既知の位置とともに使用することによって、電話の絶対６Ｄ姿勢が決定される。
【０３３５】
当然、そのような方法を、ポスター以外のオブジェクトとともに使用することができる。そして、このようにして決定されたスマートフォンのロケーションを、ロケーション決定に依拠する大部分の方法に関連して使用することができる。
【０３３６】
顕著点−関心点、又は、局所的特徴として知られることがある−は、コンテンツベースの画像取得（ＣＢＩＲ）及び他の画像ベースの技術からよく知られている。一般的に言えば、そのような点は、画像内で、１つ又は複数の選ばれた画像特徴に対して有意な局所的変化があるロケーションであり−そのようなロケーションが、独特で検出されやすくなる。そのような特徴は、輝度、色、テクスチャ、その他など、単純なパラメータ、又は、より複雑なメトリック（例えば、ガウス差分（ｄｉｆｆｅｒｅｎｃｅ  ｏｆ  Ｇａｕｓｓｉａｎｓ））に基づくことが可能である。各顕著点は、画像内のそのロケーションと、点の向きと、及び／又は、そのロケーションに関連付けられた情報を表す特徴ベクトルとを指示する、データによって表すことができる。（ＳＵＲＦ実装形態で一般に使用される特徴ベクトルは、関心点の周りに配列された１６個の異なる正方形ピクセルブロックの各々についての輝度勾配情報の４つの値を詳述する、６４個のデータを備える。）
【０３３７】
顕著点は、個々のピクセル（又は、画像内のサブピクセルのロケーション）に対応してもよいが、顕著点検出器は典型的には、角など、２Ｄ構造に焦点を合わせるか、又は、ピクセルの正方形エリア内の勾配を考慮する。顕著点は、１つの特定のタイプの局所的画像記述子である。上記で詳述した構成は、他のそのような記述子とともに同様に使用することができる。特定の実装形態では、ＳＩＦＴ又はＳＵＲＦアルゴリズムによって使用される顕著点を使用することができる。つまり、ウォーターマーク、ＮＦＣ、又は他のオブジェクト識別子をスマートフォンから受信することに応答して、リモートサーバ／データベースは、そのオブジェクトに対応するＳＩＦＴ又はＳＵＲＦデータのセットを返すことができる。
【０３３８】
（ＳＩＦＴは、スケール不変特徴変換（Ｓｃａｌｅ−Ｉｎｖａｒｉａｎｔ  Ｆｅａｔｕｒｅ  Ｔｒａｎｓｆｏｒｍ）の頭字語であり、Ｄａｖｉｄ  Ｌｏｗｅによって開拓され、「Ｄｉｓｔｉｎｃｔｉｖｅ  Ｉｍａｇｅ  Ｆｅａｔｕｒｅｓ  ｆｒｏｍ  Ｓｃａｌｅ−Ｉｎｖａｒｉａｎｔ  Ｋｅｙｐｏｉｎｔｓ」、Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｊｏｕｒｎａｌ  ｏｆ  Ｃｏｍｐｕｔｅｒ  Ｖｉｓｉｏｎ，６０，２（２００４年）、９１〜１１０ページ、及び、「Ｏｂｊｅｃｔ  Ｒｅｃｏｇｎｉｔｉｏｎ  ｆｒｏｍ  Ｌｏｃａｌ  Ｓｃａｌｅ−Ｉｎｖａｒｉａｎｔ  Ｆｅａｔｕｒｅｓ」、Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｃｏｎｆｅｒｅｎｃｅ  ｏｎ  Ｃｏｍｐｕｔｅｒ  Ｖｉｓｉｏｎ、Ｃｏｒｆｕ、Ｇｒｅｅｃｅ（１９９９年９月）、１１５０〜１１５７ページを含む、彼の様々な論文において、並びに、特許６，７１１，２９３において説明されている、コンピュータビジョン技術である。ＳＵＲＦは、関連があり、例えば、Ｂａｙ他、「ＳＵＲＦ：Ｓｐｅｅｄｅｄ  Ｕｐ  Ｒｏｂｕｓｔ  Ｆｅａｔｕｒｅｓ」、Ｅｕｒ．  Ｃｏｎｆ．  ｏｎ  Ｃｏｍｐｕｔｅｒ  Ｖｉｓｉｏｎ（１）、４０４〜４１７ページ、２００６年、並びに、Ｃｈｅｎ他、「Ｅｆｆｉｃｉｅｎｔ  Ｅｘｔｒａｃｔｉｏｎ  ｏｆ  Ｒｏｂｕｓｔ  Ｉｍａｇｅ  Ｆｅａｔｕｒｅｓ  ｏｎ  Ｍｏｂｉｌｅ  Ｄｅｖｉｃｅｓ」、Ｐｒｏｃ．  ｏｆ  ｔｈｅ  ６ｔｈ  ＩＥＥＥ  ａｎｄ  ＡＣＭ  Ｉｎｔ．  Ｓｙｍｐ．  Ｏｎ  Ｍｉｘｅｄ  ａｎｄ  Ａｕｇｍｅｎｔｅｄ  Ｒｅａｌｉｔｙ、２００７年、及び、Ｔａｋａｃｓ他、「Ｏｕｔｄｏｏｒｓ  Ａｕｇｍｅｎｔｅｄ  Ｒｅａｌｉｔｙ  ｏｎ  Ｍｏｂｉｌｅ  Ｐｈｏｎｅ  Ｕｓｉｎｇ  Ｌｏｘｅｌ−Ｂａｓｅｄ  Ｖｉｓｕａｌ  Ｆｅａｔｕｒｅ  Ｏｒｇａｎｉｚａｔｉｏｎ」、ＡＣＭ  Ｉｎｔ．  Ｃｏｎｆ．  ｏｎ  Ｍｕｌｔｉｍｅｄｉａ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｒｅｔｒｉｅｖａｌ、２００８年１０月に詳述されている。）
【０３３９】
上記で説明した動作への予備的な行為として、オブジェクトのための参照顕著点データが、（典型的には、オブジェクトの所有者又は発行者によって、オブジェクトが印刷される元のファイルの解析から）決定され、このデータが、そのオブジェクトのための識別子（例えば、ＮＦＣ識別子、又は、ウォーターマーク若しくはバーコードペイロード、その他）に関連してデータベースに格納される。
【０３４０】
いくつかの構成では、顕著点データは、事前に決定及び格納されないことがある。代わりに、顕著点データは、例えば、クラウドソースされる方式で、使用を通して開発されてもよい。例えば、ユーザは、ポスターから画像を取り込み、ウォーターマークペイロードを復号し、顕著点情報を取り込むことがある。ウォーターマークペイロードとともにデータベースにクエリを行うとき、スマートフォンは、そのオブジェクトについて予め格納された顕著点参照情報がないことを発見することがある。スマートフォンは次いで、電話によって見極められた情報を提供するように、データベースによって要求されることがあり、要求に対して、スマートフォンは、その顕著点情報を格納のためにデータベースへ転送することによって、応答することができる。
【０３４１】
スマートフォンは、加えて、電話−オブジェクト姿勢に関する情報を送ってもよい。例えば、電話内のウォーターマーク検出器は、−ウォーターマーク信号に含まれた登録信号成分を参照することによって決定されるような−そのオブジェクト観点のスケール、回転及び変換を特徴付けるアフィン変換パラメータを提供してもよい。又は、電話プロセッサによって実行される画像処理アルゴリズムは、姿勢情報の少なくともいくつかの態様（複数可）を、視野内で描かれた既知の項目（例えば、正方形の２Ｄバーコードの縁部）の見かけの歪みを参照することによって、見極めてもよい。さらに他の構成では、電話は、データベースに、取り込まれた画像データを送ってもよく、そのような姿勢推定方法を、−電話ではなく−データベースに関連付けられたプロセッサによって行うことができる。又は、姿勢データを、他の方法で（例えば、音響エコー技法、加速度計／ジャイロスコープ／磁力計センサデータ、無線ベースのロケーション、その他によって）決定することができる。）
【０３４２】
そのような姿勢情報を参照することによって、データベースに関連付けられたプロセッサは、電話により提出された顕著点情報を処理し、正規化して、姿勢関連の歪みを低減又は除去し、顕著点情報を後で使用するために参照データとして格納することができる。（又は、そのような正規化は、スマートフォンによって、顕著点情報を格納するためにデータベースに提供する前に、行われてもよい。）この正規化された顕著点情報は次いで、第２のスマートフォンがその後にデータベースにクエリを行って、そのオブジェクトについての参照顕著点情報を得るとき、参照情報としての役目を果たすことができる。
【０３４３】
同様に、オブジェクトの縁部についてのデータ−電話により取り込まれた画像から検知される−を、データベースに格納することができる。そのような情報は、顕著点情報に幾何学的に関係付けられるので、顕著点が、例えば、オブジェクトの異なる縁部からの距離を指示する役目を果たすことができるようになることが好ましい。
【０３４４】
他の実施形態では、データベースが、ページ上に存在する顕著点（特徴）についての以前に格納された参照データを返す代わりに、ページ画像自体のコピーを−関連付けられた顕著点データあり又はなしで−返すことができる。
【０３４５】
顕著点ベースのシステムについてのより多くの情報を、以下のセクションで提示する。そのようなセクションで説明する実施形態の詳細を、上記で説明した構成に組み込むことができ、その逆も同様である。
顕著点及びウォーターマーク検出
【０３４６】
ウォーターマーク検出は一般に、ウォーターマークの登録信号成分（例えば、空間周波数ドメイン内の既知のインパルスの配列）を参照することによって、ウォーターマーキングされたオブジェクトの変換、回転及びスケールを最初に推定することによって、進行する。取り込まれた画像が次に処理されて、これらの推定されたアフィン歪みが除去される。最後に、ウォーターマーク復号アルゴリズムが、処理された画像に適用される。
【０３４７】
本技術の別の態様によれば、カメラに対する撮像されたオブジェクトの姿勢が、−上述のような−参照顕著点の使用を通して推定される。姿勢が推定されると、矯正的な調整（例えば、アフィン逆歪み（ａｆｆｉｎｅ  ｃｏｕｎｔｅｒ−ｄｉｓｔｏｒｔｉｏｎｓ））が取り込まれた画像に対して行われて、姿勢のアーチファクトが低減され、平面のようなビューに正規化される画像のフレームが生じる。ウォーターマーク復号アルゴリズムが次いで、補正された画像に適用される。
【０３４８】
平面のオブジェクト上で、極めて小さい顕著点のセットは、そのような目的のために十分でありうる（例えば、３つの点）。印刷物で一般に発見されるグラフィカルなしるし（例えば、リサイクルシンボル、又は会社のロゴ、又は正方形のバーコードさえも）は、そのような目的に好適である。代替として、典型的な寸法の、典型的な雑誌のページの長方形の輪郭もまた、十分でありうる。
画像雑音除去のための顕著点
【０３４９】
ウォーターマーク信号は典型的には、振幅が小さく、画像雑音−低露光量から生じるなど−によって劣化されうる。他の画像操作は同様に、画像雑音を欠点として有する（例えば、フィンガープリントベースの画像認識）。画像雑音は、露光間隔を長くすることによって減少可能であるが、そのように行うことで、モーションブラーのリスクが増す。
【０３５０】
本技術のさらなる態様によれば、シーンの複数の画像フレームが、スマートフォンによってビデオ取り込みモードでなど、取り込まれる。各フレームは、独立して、不十分な信号対雑音比を有することがある。この信号対雑音比は、それらの共通の顕著点を参照することによって、複数のフレームを幾何学的に位置合わせし、次いで、位置合わせされたフレームを平均することによって、改善される。このようにして得られた複合フレームは、成分フレームよりも雑音が低いが、この利点は、モーションブラーのリスクなしに達成される。そのような複合フレームを次いで、ウォーターマーク復号のためにウォーターマーク検出器へ提出することができ、又は、他の方法で使用することができる。
【０３５１】
そのような方法は、フレームの各々における顕著点を（例えば、ＳＵＲＦ技法を使用して）識別することによって機能する。対応する点が次いで、フレーム間でマッチングされる。フレーム間の点の動きは、それによりあるフレームが変化して次のフレームが生じた変換を定量化するために、使用される。これらのそれぞれの変換が次いで逆にされて、フレームの各々が、共通の参照（例えば、５個のフレームのシーケンス内の中心のフレームであってもよい）に位置合わせされる。位置合わせされたフレームが次いで、平均される。
【０３５２】
ビデオ取り込みモードは、この方法の迅速な実行を容易にする、確実な仮定を可能にする。例えば、顕著点のフレーム間の並進運動は小さいので、対象フレームを検索して前のフレームから顕著点を識別する際に、対象フレーム全体が検索される必要はない。代わりに、検索を、前のフレーム内の点の位置を中心とした、小さい境界のある区域（例えば、３２×３２ピクセル）に限定することができる。
【０３５３】
同様に、顕著点のフレーム間の回転変換は、小さい可能性が高いので、点のための特徴ベクトルは、通例の向き情報を省略することができる。
【０３５４】
同様に、フレームのシーケンス内に取り込まれた画像のスケール係数は、比較的不変である可能性が高く−やはり、マッチする点を発見する際に検討されなければならない検索空間を制約する。
【０３５５】
特定のマッチングアルゴリズムは、通常は第１及び第２のフレーム内で識別された顕著点から開始する。例示的フレームは、２０〜４００個の顕著点を有することがある。第１のフレーム内の点ごとに、その特徴ベクトルと、第２のフレーム内の各顕著点の特徴ベクトルとの間の、ユークリッド距離が計算される。第１のフレーム内の点ごとに、最も近いユークリッド距離を有する第２のフレーム内の点が、候補マッチとして識別される。
【０３５６】
時々、第２のフレーム内の点は、第１のフレーム内の２つ以上の点への候補マッチとして識別されることがある。そのような候補マッチは、廃棄される。また、廃棄されるものは、計算されたユークリッド距離が閾値を超える候補マッチである。（絶対値の閾値が使用されてもよく、又は、アルゴリズムは、距離値の最大の１０パーセントに基づいて、候補マッチを廃棄してもよい。）候補マッチのセットが残る。
【０３５７】
図２０は、第１及び第２のフレーム内で、残っている顕著点のロケーションを示す。わかるように、フレームの中心に近い点は、厳密に一致している。さらに離れると、あるずれがあり−一部は、２つの画像フレーム間のわずかに異なるスケールによるものであり（例えば、ユーザがカメラを被写体により近付くように動かした）、一部は、変換による（例えば、ユーザがカメラを少々震わせた）。
【０３５８】
第１近似では、第１及び第２のフレーム間の変換は、スケール係数によって、及び、（Ｘ及びＹにおける）変換によって特徴付けられる。スケールが最初に推定される。このことは、残っている顕著点の第２のフレームを様々な量によってスケールし、次いで、スケールされた点のロケーションと、第１のフレーム内のそれらの最も近い対応物との間の距離のヒストグラムを調べることによって、行われる。図２１は、１．０１、１．０３、１．０５及び１．０７のスケール係数についての結果を示す。わかるように、１．０５のスケールが、最良のピークを生じる。
【０３５９】
残っている顕著点の第２のフレームが次いで、決定されたスケール値（１．０５）に従ってスケールされる。スケールされた点のロケーションと、第１のフレーム内のそれらの最も近い対応物との間の（Ｘ及びＹにおける）距離が、次いで計算され、Ｘオフセット及びＹオフセットの中央値が、次いで計算される。これにより、第１の画像に対する第２の画像の位置合わせを特徴付ける変換の第１近似が完成する。
【０３６０】
この近似を、望むなら、さらに改良することができる。１つの適した技法は、決定されたスケール及びＸオフセット、Ｙオフセットを適用した後に閾値距離内でなお位置合わせされない、それらの候補点の対を廃棄することによる。決定されたスケール及びオフセットに基づく、アフィン変換に、次いで反復する方式で摂動が与えられて、なお保持された候補点間の最良の最小二乗適合を生じる変換が識別される。
【０３６１】
１つの実験では、デジタルウォーターマーキングされた写真の５００個のフレームが、スマートフォンのビデオ取り込みモードを使用して、微光の中で取り込まれた。個々に、５００個のフレームの２５％を処理して、符号化されたデジタルウォーターマークを読み取ることができた。成功したウォーターマーク読み取りは、４９％の時間で、５個のフレームの各シーケンス内で１つ又は複数のフレームにより達成された。５個のフレームの連続するグループが、いかなる位置合わせもなしに平均された場合、結果は、１８％まで下がった。しかし、５個のフレームの各シーケンスが、上記で説明したように位置合わせ及び平均された（第３のフレームを参照として使用し、それに対して他のフレームがマッチングされた）場合、成功したウォーターマーク読み取りは、６１％の時間で達成された。
【０３６２】
ちょうど、説明した手順がウォーターマーク読み取り動作の成功を向上させたように、複数の画像フレームの−顕著点の位置合わせ及び平均に基づく−そのような処理は、同様に、他の目的（消費者の楽しみを含む）のために、低雑音の鮮明な画像を生じることができる。
【０３６３】
前述の構成とともに、又は独立して使用することができる別の方法は、ビデオシーケンスの各フレームが取り込まれた瞬間に対応するスマートフォンの動きセンサデータに注目することである。センサデータ（例えば、３Ｄ加速度計又はジャイロスコープからのもの）が閾値を上回る動きを指示する場合、画像の対応するフレームを廃棄し、平均する演算で使用しないことができる。閾値は、例えば、１０個のフレームの各シーケンスから、最高の動きの値を有する２つのフレームを廃棄することによって、適応的でありうる。
【０３６４】
（予備的な研究は、ハンドヘルド電話でハンドヘルドの動きの大きさが瞬間ごとに大幅に−無から、比較的大きい値まで−変化することを示している。後の方のフレームを廃棄することによって、はるかに向上した結果を達成することができる。）
チャネル化されたオーディオウォーターマーク
【０３６５】
オーディオウォーターマークは、オーディオ及びオーディオ−ビデオコンテンツに関連してネットワークサービスを提供するために、ますます使用されつつある。一例は、ＡＢＣテレビジョン（Ｔｅｌｅｖｉｓｉｏｎ）によって提供された、グレイズ・アナトミーＳｙｎｃアプリケーションであり、アップルアプリストア（Ａｐｐ  Ｓｔｏｒｅ）からダウンロードが可能である。このアイパッドアプリは、グレイズ・アナトミーの番組の視聴者が、番組を見ながら、他のファンと（例えば、チャット機能性によって）インタラクトすること、及び、エピソード関連コンテンツ（例えば、俳優の経歴、クイズ、その他）をリアルタイムで得ることを可能にする。同様に、音楽コンテンツ内のオーディオウォーターマークは、リスナーが他のファンとインタラクトすること、及び、関連情報を得ることを可能にすることができる。
【０３６６】
オーディオウォーターマーク情報は典型的には、コンテンツ自体に織り込まれ−オーディオデータから分離不可能である、極めて低レベルの、雑音のような信号である。ウォーターマークの除去は典型的には、極めて困難、又は不可能である。
【０３６７】
本技術の別の態様によれば、オーディオウォーターマーク情報は、別のオーディオチャネルで搬送されるので、ユーザの希望、又は他の状況に応じて、そのような情報がレンダリング可能−又は不可能となる。
【０３６８】
１つの適したフォーマットは、ドルビートゥルーＨＤ（Ｄｏｌｂｙ  ＴｒｕｅＨＤ）であり、８個の個別のオーディオチャネルの各々で２４ビットオーディオを搬送することができる。別の１つは、マイクロソフトのＷＡＶファイルフォーマットであり、現在、複数のオーディオチャネルをサポートしている。さらに別の１つは、欧州放送連合（Ｅｕｒｏｐｅａｎ  Ｂｒｏａｄｃａｓｔｉｎｇ  Ｕｎｉｏｎ）によって指定されるような、ＲＦ６４フォーマットである。
【０３６９】
例示的実装形態は、関連付けられたウォーターマークデータが追加のチャネル上で搬送される、オーディオファンの５．１又は７．１サラウンドサウンドシステムを使用した、ホームオーディオシステムである。オーディオ受信機上の（及び／又は、リモートコントロールデバイス上の）コントロールによって、ユーザは、ウォーターマークチャネルがレンダリングされるべきであるかどうかを命令することができる。レンダリングが選択される場合、受信機は、ウォーターマークデータを、スピーカチャネルのうち１つ又は複数（例えば、前方の左右のスピーカ）にミキシングする。ウォーターマークの振幅は通常、ミキシングで変更されないが、いくつかの実装形態は、追加として、ミキシングされたウォーターマークの振幅を変化させるためのある能力を、ユーザに与えてもよい。
【０３７０】
別の実装形態は、オーディオが録音された本来のマルチトラック形式で消費者に配信され、ユーザが自分自身のミックスを創作できるようになる日を期待している。（例えば、サクソフォーンを好む消費者は、バンドの１６トラック録音においてサクソフォーントラックを強調してもよく、ドラムトラック、その他を弱めてもよい。）やはり、そのような実装形態では、−ユーザが、ウォーターマークによって可能にされるネットワークサービス又は他の機能を利用するつもりであるかどうかに応じて−ウォーターマーク信号を最終的なオーディオミックスに含めるか、又は、除外する機会が、ユーザに与えられる。
【０３７１】
大部分の実装形態では、単一のウォーターマークトラックが提供される。しかし、複数のトラックを使用することができる。１つのそのような実施形態は、基本的なウォーターマークトラック、及び、複数のさらなるトラックを有する。さらなるトラックの各々は、データチャネルであり、対応するオーディオ（楽器）トラックに関連付けられるべきであるウォーターマークの振幅成分を指定する。今挙げた例では、ドラムトラックの振幅が減衰される場合、マスキングのために、ドラムトラックに依拠するウォーターマーク信号のある特徴を同様に減衰することが望ましいことがある。振幅データチャネルは、対応するオーディオ（楽器）トラックのユーザ設定振幅に従ってスケールされ、すべてのそのようなチャネルからのスケールされた振幅データが次いで合計されて、ウォーターマーク信号のための最終的なスケール係数が生じる。ウォーターマーク信号は次いで、このスケール係数に従って（例えば、乗算によって）振幅が動的に調整されるので、ウォーターマーク振幅は、総合のオーディオを構成する様々なオーディオトラックの振幅に最適に対応するようになる。
【０３７２】
オーディオのトラックは、消費者電子デバイスが上記のようにトラックを読み取り且つ処理するコンピュータ可読媒体上に格納可能である。又は、トラックは、ケーブル若しくはオンライン配信サービスによってなど、デバイスにストリームされ、読み取り及び処理される前にメモリ内に一時的にバッファされてもよい。
取り込まれたシーン内の複数のオブジェクトの曖昧性除去
【０３７３】
スマートフォンは、共有されたコンテキストにおいていくつかの異なるオブジェクトを描く画像フレームを取り込むことがよくある。一例は、単一の写真画像内で様々な製品を特集するデパートの広告である。別の例は、分類広告のページである。複数の異なるオブジェクトを含むそのような文書は、「複合被写体（ｃｏｍｐｏｓｉｔｅ  ｓｕｂｊｅｃｔｓ）」と呼ばれることがある。複合被写体の一部分を形成する各オブジェクトは、異なる電子的応答（例えば、対応するオンラインウェブページ、又は、他のトリガされるアクション）に関連付けられることが望ましいことが多い。
【０３７４】
本技術のさらなる態様によれば、前述は、複合被写体に関連付けられた識別子を決定すること、その識別子をデータストアへ送信すること、及び、返信において、元の複合被写体の一部又は全部のレンダリングを作り出すことができるデータを含む、オーサリングされたページを受信することによって、達成可能である。この受信されたページは、異なるクリック可能（タップ可能）な領域を定義することができる。ユーザは、レンダリングされたページ上に示された、関心のある特定のオブジェクトをタップし、スマートフォンは、当技術分野で知られている技法を使用して（画像をハイパーリンクとしてレンダリングする、よく知られているＨＴＭＬハイパーテキストマークアップを介してなど）、その領域に関連付けられた応答を設けることによって、応答する。
【０３７５】
そのような構成では、スマートフォン画面上に提示される画像は、スマートフォンカメラによって取り込まれた画像ではないことがある。代わりに、画像は典型的には、リモートストアからスマートフォンへ配信されたページ（ファイル）である。しかし、画像は、ユーザがインタラクト中である同じ複合被写体の１つのバージョンを示す（通常は、「平面」ビュー−スマートフォンにより取り込まれた画像にいかなる遠近歪みもないもの−であるが）。
【０３７６】
スマートフォンに配信されたファイルは、複合被写体を、スマートフォン画面上に一度に好都合に表示可能であるよりも大きい、本来のスケール／解像度で提示してもよい。（つまり、最初に取り込まれた画像は、描かれた被写体を１インチ当たり５０ピクセルで解像することがあるのに対して、配信されたファイルは、１インチ当たり７２ピクセルの解像度を提供してもよい。このようにして、最初に取り込まれた画像内で１０ピクセルにわたることがある印刷ページ上の特徴は、配信されたファイル内で１４ピクセルにわたることがある。）ユーザは、ピンチ、スワイプ、その他を含む、知られているタッチスクリーンジェスチャーを使用して、表示倍率を変更し、ページを横切って、所望の抜粋を表示させることができる。（大きいスケール／解像度のために、配信されたファイルのピクセルのすべてを画面上で一度に提示することが、−ある種のダウンサンプリングがなければ−可能でないことがある。）ユーザの関心のある被写体である、描かれたオブジェクトが、表示上で好都合なサイズで提示されると、ユーザは、オブジェクトをタップして、関連付けられた振る舞いを開始する。
【０３７７】
複合被写体に関連付けられた識別子を決定することに、言及した。このことを、様々な方法で行うことができる。いくつかの実施形態では、複合被写体内に描かれた各オブジェクトは、それ自体のマシン可読コード（例えば、デジタルウォーターマーク、バーコード、その他）により符号化される。オブジェクトのうちいずれかが復号され、そのペイロードがリモートサーバへ送られる場合、システムは、引き換えに、同じ複合ページデータにより応答する（つまり、複数の入力ペイロードはすべて、同じ出力ページとなる）。代替として、複合被写体全体が、単一の識別子（例えば、完全な複合被写体にわたるデジタルウォーターマーク、又は、いくつかのオブジェクトを描く印刷ページ上の単一のバーコード）により符号化されてもよい。やはり、システムは、スマートフォン表示上でレンダリングするために、ページデータを返すことによって、そのような単一の識別子の送信に応答することができる。
【０３７８】
同様に、複合被写体内で描かれた個々のオブジェクト、又は、複合被写体の他の抜粋（そのような被写体を全体として含む）は、ＳＵＲＦなど、画像フィンガープリント技法によって認識されてもよい。やはり、そのような識別は、その被写体のための識別子にマッピングすることができ、識別子は、レンダリングのために対応する電子ページに関連付けられうる。
【０３７９】
さらに他の実施形態では、スマートフォンは、スマートフォンカメラを使用せずに、例えば、対応する検出器を使用して、複合被写体によって搬送されたＮＦＣ又はＲＦＩＤチップから識別子を検出することによって、複合被写体から識別子を見極めてもよい。
【０３８０】
ユーザインタラクションのためにスマートフォン上で提示される電子ページは、異なる度合いで、体験を開始した物理的ページと視覚的に一致してもよい。いくつかの実施形態では、電子ページは、物理的ページとは区別不可能であってもよい（例えば、−斜めではなく−平面の視点からなど、異なる観点から提示されうることを除く）。他の実施形態では、電子ページは、視覚的に類似するが、等しくなくてもよい。例えば、電子ページは、解像度がより低くてもよく、又は、より小さいカラーパレット若しくは他の様式化されたグラフィック効果、その他により、ページを提示してもよい。
【０３８１】
そのような構成を通して、システムは、−スマートフォン画面上で−ユーザによって見られている複合被写体のバージョンを複製するが、対応するリソースにリンクするか、又は、対応する振る舞いをトリガする、クリック可能／タップ可能な領域を伴う。
【０３８２】
前述の構成は、潜在的問題、つまり、画像の単一のフレーム内で複数のマシン可読なしるしを検出し、どのしるしがユーザにとって特に関心のあるものであるかを見極めることができない、スマートフォン内のウォーターマーク又はバーコード検出器の潜在的な問題を回避することは、理解されよう。代わりに、単一のフレームは−複数のオブジェクトを描くことがあるが−応答において、単一の電子ページにマッピングする。ユーザは次いで、どのオブジェクトに関心があるかを、タップによって（又は、代替ユーザインターフェース選択によって）曖昧でなく指示することができる。
【０３８３】
関連する問題が、（上記で詳述した）ストリーミングモード検出器のある実装形態で生じることがある。ユーザがスマートフォンカメラを動かして、関心のある特定のオブジェクトの画像を取り込むとき、スマートフォンは、複合被写体の一部分を形成する多数の他のオブジェクト（ユーザが関心を有していないことがある）の画像を取り込むことがあるが、それでも、スマートフォンは、各々からマシン可読識別子を復号することがある。
【０３８４】
本技術のさらなる態様によれば、スマートフォンは、電話の動きセンサ（例えば、加速度計、ジャイロスコープ及び／又は磁力計）が、閾値の動きの程度よりも大きいものを指示するとき、あるモジュール（例えば、ウォーターマーク及びバーコード復号器、ＮＦＣリーダ、その他）の動作を無効化してもよい。例えば、電話が毎秒２、４又は６インチを超える動きを検知する場合、電話は、そのようなモジュールの動作を抑制してもよい。（ある動きは、単に自然な手の細かい震えによって起こる。）電話は、動きがその閾値を下回るか、又は、異なる閾値（例えば、毎秒１インチ）を下回るとき、モジュール動作を再開してもよい。そのような構成によって、意図されていない識別子の復号が抑制される。
例えば、新聞のための、プリントトゥウェブの見返り（Ｐａｙｏｆｆｓ）
【０３８５】
示したように、印刷媒体−新聞及び雑誌など−にデジタルウォーターマーキングして、非表示ペイロードデータを埋め込むことができる。そのようなペイロードデータが、スマートフォン上の適したウォーターマーク検出プログラム（例えば、ディジマークディスカバーアプリ）によって検知されるとき、そのようなペイロードデータは、スマートフォンに、関連付けられたオンラインコンテンツを表示させるなど、関連付けられた「見返り」を提示させる。
【０３８６】
新聞が、多数のその毎日の写真、又は、多数のその毎日の記事にデジタルウォーターマーキングする場合、発行者が写真／記事ごとに適切な見返りを指定することは、記号論理学的な課題となりうる。制作スケジュールに圧倒され、ある発行者は、そのウォーターマーキングされた画像のすべてが単に発行物のオンラインプレゼンスのホームページ（例えば、ｗｗｗ＜ｄｏｔ＞ｎｙｔｉｍｅｓ＜ｄｏｔ＞ｃｏｍウェブページ）に戻るようにリンクするように準備する。代替として、発行者は、印刷記事のための見返りが、単に同じ記事のオンラインバージョンであると指定することがある。
【０３８７】
そのような手段は、しかし、付加価値をほとんど提供しない。
【０３８８】
本技術のさらなる態様によれば、新聞記事（又は、画像）は、ほとんど又は全く労力をかけずに、より価値のある見返りに関連付けられる。
【０３８９】
１つの特定の実施形態によれば、新聞が購読者に配達される前（であるが、ウォーターマークＩＤが記事に割り当てられた後）に、オペレータが、記事に関連付けられる少数の（例えば、２〜５個の）キーワード（例えば、オバマ、プエルトリコ、又は、スタンレーカップ、ブルーインズ）を入力する。これらのキーワードは、中央コンピュータシステムのデータベースに、それとともに記事がデジタルウォーターマーキングされるウォーターマークペイロードＩＤに関連して、格納される。見る人がその後、ディジマークディスカバーアプリを使用して、ウォーターマークを復号し、見返りにリンクするとき、見返りは、その記事について入力されたキーワードに基づくグーグル（又は、Ｂｉｎｇなど、他のプロバイダ）検索である。
【０３９０】
実際には、グーグルキーワード検索は、発行者が他のいかなる見返りも指定しない場合に備えて、デフォルトの、又は支えになる見返りとして使用されてもよい。このようにして、典型的なワークフローでは、キーワードが記事に関連して格納され、格納されたキーワードに基づくグーグル検索が、記事のための見返りとして最初に指定される。その後、しかし、新聞の発行者、又は記事の記者は、格納されたデータを変更して、異なる見返りを指定してもよい。（時々、筆者により指定されたオンラインの見返りが発行者に、記事テキストとともに提出され、その場合、この筆者により指定された見返りを、最初からオンラインの見返りとして使用することができる。）
【０３９１】
別の実施形態では、キーワードは、手動で入力されず、むしろ、例えば、タグクラウド技法によるように、記事のテキストから抽出される。１つの特定のタグクラウドは、記事内の名詞を頻度によってランク付けし−場合によっては「雑音語」を廃棄する。共起法を使用して、２語以上の句を識別することができる。最も頻繁に発生する用語は、記事キーワードとして格納される。そのような技法は、当業者にはよく知られている。
【０３９２】
さらに別の構成では、システムは、記事の筆者に基づいて、可能性が高いキーワードを予測することができる。オレゴニアン（Ｏｒｅｇｏｎｉａｎ）の人気があるスポーツ記者は、通常、トレイルブレイザーズ（Ｔｒａｉｌｂｌａｚｅｒｓ）バスケットボールチームについて書いている。ザ・ニューヨーク・タイムズ（Ｔｈｅ  Ｎｅｗ  Ｙｏｒｋ  Ｔｉｍｅｓ）のポール・クルーグマン（Ｐａｕｌ  Ｋｒｕｇｍａｎ）は、通常、経済について書いている。そのようなキーワードに基づくグーグル検索は、筆者の記事のコンテンツについてのいかなる特定の情報もない場合に、適したデフォルトの見返りイベントになりうる。
【０３９３】
さらに別の方法は、パターンマッチング又は顔認識によってなど、画像からセマンティックな情報を抽出する。例えば、知られている方法を使用して、新聞の写真内で、有名人及びよく知られているランドマークの描写を識別することができる。そのような技法の使用を通して見極められた名前を、そのような写真のためのキーワードとして格納することができる。
【０３９４】
自動化されたシステムが、画像に関するロケーション情報のある知識を有する場合、画像のコンテンツを見極めることが支援される。オレゴニアン新聞は、例えば、地元及び州の役人の顔を含む画像を頻繁に発行する。役人の顔は、世界中の顔から描かれた参照顔データとマッチングすることが困難でありうる。しかし、そのような画像がオレゴニアンで発行されていることを知ることで、認識システムに、描かれた人々／ランドマークを識別するために使用できるさらなる手がかり、つまり、オレゴンに関連付けられた顔データとのマッチを最初にチェックするということが与えられる。
【０３９５】
前述の実施形態では、自動生成されたキーワードがオペレータによって見直されてもよく、オペレータは、そのような出力を監督し、自動生成されたキーワードが不適切又は不適当に見える場合、そのような出力を修正することができる。
【０３９６】
一般に、ウォーターマークベースのプリントトゥウェブのスマートフォンアプリが、ウォーターマークペイロードを検知し、オンラインの見返りへのリンクを開始するとき、ウォーターマークを検出したアプリは、画面から消え、電話のウェブブラウザに置き換えられる。これが、ディジマークディスカバーアプリの最初のリリースの場合であった。本技術の好ましい実装形態によれば、しかし、ＨＴＭＬ  ５又はアドビフラッシュ（Ｆｌａｓｈ）が使用されて、関連付けられたオンラインの見返り（例えば、引用されたグーグル検索）が、ウォーターマーク読み取りアプリによって表示されたカメラの視野の上に−そのアプリコンテキストを離れることなく−視覚的オーバーレイとしてレンダリングされる。
【０３９７】
特定の実装形態では、中央コンピュータシステムのデータベースは、ウォーターマークペイロードＩＤを、関連付けられた見返りの詳述に関連付ける。このデータベースは、新聞発行者によって、又は別の関係者によって維持されうる。ウォーターマークペイロードＩＤごとに、関連付けられたデータベースレコードがあり、関連付けられたデータベースレコードは、その記事（又は、写真）のためのキーワードを含む。データベースレコードはまた、ＨＴＭＬ  ５テンプレートをも指定する。データベースが、復号されたウォーターマークＩＤを提供するスマートフォンアプリによって尋ねられるとき、データベースは、ＨＴＭＬ  ５テンプレートをプルし、関連付けられたキーワードを挿入して、スマートフォンに返す。スマートフォンアプリは次いで、返されたＨＴＭＬテンプレートに従って、画面表示をレンダリングする。（代替として、データベースは、キーワードによりグーグルにクエリを行い、スマートフォンに完全な形式のＨＴＭＬページを返してもよく、完全な形式のＨＴＭＬページには既にグーグル検索結果が含まれている。）
【０３９８】
ユーザに提示されるグーグル結果を制限することが、望ましいことがある。例えば、ニューヨーク・タイムズの記事からのオンラインの見返りが、競合する新聞の記事へ読者を導いた場合、具合の悪いことになりうる。したがって、変形実施形態では、スマートフォンアプリによって提示されるグーグル検索が、ニューヨーク・タイムズのウェブサイト、及び、競合しないドメイン（例えば、ウィキペディア、米国政府ウェブサイト、その他）などにドメイン制限されてもよい。
【０３９９】
読者が、（例えば、オバマのプエルトリコ訪問についての）新聞記事から、キーワードベースのグーグル検索結果の対応するページへリンクするとき、アプリは、何の検索結果をユーザがその後にたどるかを監視することができる。全体として、そのようなユーザ選択は、ユーザの明らかな関心をより良く追跡するために、その記事のためのオンラインの見返りを修正するように、システムを導くことができる。
【０４００】
例えば、キーワード「オバマ」及び「プエルトリコ」によるグーグル検索は、（ザ・ニューヨーク・タイムズ、ザ・ネイション（Ｔｈｅ  Ｎａｔｉｏｎ）、アル・ジャジーラ（Ａｌ  Ｊａｚｅｅｒａ）、その他によって発行された）オバマの訪問の新しいレポートがトップに来る結果のリストを生じる。検索結果の下の方には、しかし、集会でダンスをするオバマを示すユーチューブのリンクがある。ＨＴＭＬ  ５コードは、アプリへ及び／又はアプリからのトラフィックを観察することができ、データベースに対し、どのリンク（複数可）をユーザがたどるかを指示してもよい。ダンスのリンクをクリックするユーザの数に基づいて、システムは、見返りを修正し、この結果が検索結果のリストのより上の方に現れるようにしてもよい。
【０４０１】
データベースは、プエルトリコで「ビール（ｃｅｒｖｅｚａ）」を飲み、「バナナ（ｐｌａｔａｎｏｓ）」を食べるオバマに関するリンクへの見る人の関心を、同様に知ることがある。
【０４０２】
これらの用語のうちすべてが、データベースキーワードとして追加され、検索のための基礎として使用されてもよい。しかし、結果は次いで、以前トップにランクされたニュースアカウントを除外することがある。そのような場合に、より良いことは、データベースが複数のグーグルクエリを実行することであり−あるクエリは、元のキーワードによるものであり、あるクエリは、それらのキーワード及び「ダンスをする」によるものであり、あるクエリは、それらのキーワード及び「ビール」によるものであり、あるクエリは、それらのキーワード及び「バナナ」によるものである。リモートシステムは次いで、結果を−指示された、異なる主題のユーザ人気に基づいて−組み合わせ、これらの修正された結果を、その後に記事からリンクするスマートフォンへ返すことができる。これらの後のユーザは次いで、ユーチューブビデオがトップに来る検索結果を見ることがある。リンクがスマートフォンアプリ上で提示される順序を、新聞の読者の中の明らかな人気に対応するように、調整することができる。
【０４０３】
そのような構成によって、新聞は、その読者に人気が出るであろう特定の記事のためにオンラインの見返りを指定する負担から解放される。代わりに、最初のグーグル検索は、後続のクラウドソースされたフィードバックとともに、システムが、実証された読者の関心を満たすオンラインの見返りを自動的に見極めることを可能にする。
【０４０４】
時々、ある記事に対するユーザの反応が、新聞が第２の関連記事に関連付けるリンクに、影響を与えることがありうる。４ページにオバマのプエルトリコ訪問の政治についての記事、及び、５ページに−ダンスを含む−オバマの訪問についての別の人情話を含む、オレゴニアンの版を考えられたい。トラフィック解析は、より多くの読者が（５ページの話を読者のディジマークディスカバーアプリに提示することによって）、４ページの話に関心を表すよりも、５ページの話に関心を表すことを示すことがある。オンラインの見返りをそのような話に（例えば、上記で詳述した方法で）自信を持って変更するために十分な、４ページの話からのトラフィックがないことがある。しかし、中央システムは、４ページの記事のセマンティックな比較を行って、−キーワード類似性によって−新聞のどのような他の記事（複数可）が関係付けられるかを発見してもよい。そのような処理によって、５ページの記事が４ページの記事に関係付けられることが発見される。そのような場合、システムは、−４ページの記事の読者に対する見返りオプションとして−５ページの記事の読者に最も人気があると判明するリンク（複数可）を提示することができる。
可動オブジェクトにリンクされたタグ
【０４０５】
上記で詳述した特徴のうち特定のものをさらに広げると、オブジェクトは、画像内で（例えば、ウォーターマーキング又はフィンガープリンティングによって）認識されてもよく、スマートフォンは、タグ（アイコン又はボーブルとしても知られる）を、そのような表示されたオブジェクトに関連して提示してもよいことは理解されよう。この関連は、「べたべたした」ものでありうる。つまり、スマートフォン画面上に表示された視野が変更される場合、表示されたタグは、タグがそれぞれ関連付けられるオブジェクトの見かけの動きとともに動く。
【０４０６】
そのような振る舞いは、直観的な応答を提供するが、動くタグは、ユーザがタグをタップして、例えば、関連付けられたアクションをトリガすることを望む場合、問題になると判明する可能性がある。これには典型的には、カメラを少なくとも片手で押さえると同時に、画面上で潜在的に動く対象をタップすることが必要となる。
【０４０７】
本技術のさらなる態様によれば、表示された画像内で認識されたオブジェクトに関連付けられたタグが、画面上で固定された位置に、タグを対応するオブジェクトにリンクする視覚的指示とともに、提示される。
【０４０８】
ユーザが、スマートフォンカメラを、販売用衣類を着ている女性を描く印刷されたカタログに向けることを考えられたい。スマートフォンが、（例えば、閾値強度を超えるウォーターマーク較正又は向き信号が、取り込まれた画像内で発見されるので）カタログ印刷がステガノグラフィ的にデジタルウォーターマークを搬送していると結論付ける場合、スマートフォンは、取り込まれた画像の、ウォーターマークが発見されるように見えるエリア上に、独特のグラフィック効果を提示するようにプログラムされてもよい。この効果は、例えば、きらめき、クロミナンス又は輝度変動、オーバーレイされたグラフィカルな特徴、その他を備えてもよい。図３２は、１つのそのような構成を示す。（オーバーレイされた星の明るさ又は位置が、数ヘルツの周波数で変化し−目に映るより多くのものがここにあることを、ユーザに指示する。図３２では、ウォーターマーク信号が、表示された画像の全体で検出された。）
【０４０９】
そのような独特のグラフィック効果に応答して、ユーザは、取り込まれた画像上のウォーターマーク読み取り動作を完了するように、スマートフォンに命令するアクションを取ってもよい。そのようなアクションは、タッチスクリーンジェスチャー、電話を振ること、物理的ボタンのタッチ、発話コマンド、その他であってもよい。代替として、電話は、可能なウォーターマーク信号が検出されるときは常にウォーターマーク読み取りに自動的に着手するモードで、動作してもよい。
【０４１０】
図３２の構成では、スマートフォンは、ウォーターマーク読み取り動作を完了する。スマートフォンは次いで、復号されたウォーターマークペイロードを、リモートデータベースステーション／ウェブサービスへ送信する。リモートデータベースステーションは、受信されたウォーターマークペイロードを使用して、関連付けられた情報を含むデータベースレコードにアクセスし、次いで、関連付けられた情報をスマートフォンへ返信する。
【０４１１】
描かれた構成では、スマートフォンへ返されたこの情報は、電話に、図３３に示すような表示を提示させる。つまり、スマートフォンは、３つのタグを画面の下縁部に発生させ−そこで、３つのタグは、ユーザの親指で好都合にタップ可能である。１つのタグは、取り込まれた画像内で描かれた女性が着ているブラウスに対応し、第２のタグは、女性のショートパンツに対応し、第３のタグは、女性のハンドバッグに対応する。
【０４１２】
図３３では、各タグを対応するオブジェクトに概念的にリンクする、２つのタイプの視覚的指示がある。１つのタイプは、タグからオブジェクトまで伸びる、つなぎ線である。別のタイプは、オブジェクトによりカスタマイズされたタグである。
【０４１３】
つなぎ線に関しては、カメラが動かされ、オブジェクトが画面表示内で動かされる場合、タグは、関連付けられたつなぎ線の下端部とともに、画面の下縁部に固定されたまま残ることが望ましい。しかし、つなぎ線の上端部が動いて、オブジェクトを追跡し、オブジェクトとタグの間の持続的な視覚的関連を維持する。このことは、図３３及び図３４を対比することによってわかる。ユーザは、スマートフォンをこれらの２つの図の間で動かしており、カタログページの異なるビューを生じている。ブラウス及びショートパンツを着ている女性は、表示された視野内で右方向に移動しており、ハンドバッグは、見えない所に移動している。ブラウス及びショートパンツのタグは、しかし、画面の底部で静止したままである。つなぎ線の上部が動いて、移動するブラウス及びショートパンツオブジェクトを追跡する。（カメラの見えない所に移動したハンドバッグのタグは、図３４では消える。）
【０４１４】
描かれたつなぎ線の構成は、このようにして二重形式の図像を採用している。一方はオブジェクトの後を追い（すなわち、つなぎ線）、他方は静止している（すなわち、タグ）。
【０４１５】
示したように、各タグをそれぞれのオブジェクトにリンクする第２の視覚的指示は、対応するオブジェクトの性質を指示する独特のグラフィカルタグアートワークである。描かれた構成では、つなぎ線は必要とされず、その理由は、独特のタグが単独で、画像内の異なるオブジェクト（ブラウス、ショートパンツ及びハンドバッグ）をシンボル化する−不可欠な、関連の視覚的指示を提供する−からであることは理解されよう。しかし、他の実施形態では、タグが汎用で互いに等しい可能性があり、その場合、つなぎ線が適切な視覚的関連を提供する。
【０４１６】
（多数の他の形式の−タグを画像オブジェクトに関連付けるための−視覚的指示を、図示の２つのタイプの代わりに用いることができる。１つの他の形式は、画像オブジェクトをある色でハイライトするか、又は輪郭を付け、次いで、同じ色のタグをスマートフォン表示の縁部に設けることである。異なる色を使用して、異なるオブジェクトを異なるタグに関連付けることができる。）
【０４１７】
舞台裏では、特定の実施形態では、ウェブサービスに送られたウォーターマークペイロード（又は、フィンガープリントデータ）は、見られている特定のカタログ及びページについての情報を含むデータベースレコードへのアクセスを可能にする。データベースから返される情報は、画像内の特定の特徴を特徴付ける参照画像データを含みうる。この情報は、１つ又は複数のサムネイル画像又はマップ−異なるオブジェクト形状（ブラウス、ショートパンツ、ハンドバッグ、その他）を定義する−を備えてもよい。加えて、又は代替として、この情報は、描かれたオブジェクト（複数可）がそれにより認識及び追跡されうる特徴を識別するデータなど、画像フィンガープリントデータを備えてもよい。加えて、又は代替として、この情報は、オブジェクト「ハンドル」−つなぎ線の上端部が終了可能である、オブジェクト形状の縁部内又は縁部でのロケーション−を定義するデータを備えてもよい。図３５は、３つのハンドルロケーション（「Ｘ」によって指示される）を定義する、１つのそのような形状（ショートパンツ用）を示す。
【０４１８】
この特定の例では、データベースから返される情報が典型的にはカタログの発行者によって書かれることは理解されよう。発行者は、図３２の画像が、リンクされたタグを介して、ユーザ選択可能なインタラクティビティを備えるべきである３つのオブジェクトを含むことを、指定する。３つのオブジェクトについての情報は、データベースに格納され、電話に提供され（例えば、図３５のような形状データ、又は、フィンガープリントデータ−ＳＵＲＦなど）、ビューが動くにつれて３つのオブジェクトをパターンマッチング及び追跡可能にし、アタッチメントハンドル点が識別される。発行者により指定されたデータは、３つの異なるオブジェクトに関連して画面の底部に提示されることになる特定のアイコン形状を、さらに定義する。
【０４１９】
図３３の場合のように、タグが、取り込まれた画像上に最初にオーバーレイされるとき、ソフトウェアは、画像の下縁部を解析して、どこにタグを最良に配置するべきであるかを識別してもよい。この決定は、画像のその領域内の縁部を識別することによってなど、異なる候補ロケーションの評価に基づくことが可能である。望ましくは、タグは強い縁部上に配置されるべきではなく、その理由は、この配置が、取り込まれた画像の知覚的に関連のある特徴を不明瞭にすることがあるからである。タグを、画像の比較的「穏やか」又は一様な−強い縁部及び他の知覚的に顕著な特徴がない−部分上に配置する方がより良く、そこでは、障害物がそれほど問題にならない可能性が高くなる。タグが最初に配置されると、しかし、−下にある取り込まれた画像がずれる場合でも−タグがそのロケーションに残されて、そのようなタグとのユーザインタラクションが容易になるようにすることが望ましい。画像がずれる場合、つなぎ線の最上部が動く特徴の後を追う−ゴムバンドのように伸びて、必要に応じて位置決めし直す−ことが望ましい。（場合によっては、タグの移動が必要となることがあり、追加のオブジェクトがビューに入ってくる−追加のタグの提示を必要とする−ときなどである。そのような場合には、ソフトウェアは、新しいタグをさらに収容しながら、元のタグをできるだけその元の位置の近くに維持しようとする。このことは、元のタグをより小さいサイズにすることを含むことがある。）
【０４２０】
つなぎ線（複数可）は、使用される場合、タグから対応するオブジェクト上の最も近いハンドルへの単純な曲線状のパスを識別するアルゴリズムを使用して、ルーティングされる。異なるオブジェクトハンドルへの異なるパスを評価することができ、ルートの選択は、ある基準（例えば、強い縁部を横切ることを最小限にすること、ほぼ９０度の角度で強い縁部を横切ること−回避不可能な場合−、視覚的に心地良い範囲−２５度に近い曲線角など−を有する曲線を生じるルートを識別すること、オブジェクトの外側からオブジェクトの縁部上のハンドルに近付くルートを識別すること、その他）に基づくことが可能である。つなぎ線の色は、つなぎ線がその上にオーバーレイされる取り込まれた画像に基づいて、適したコントラストをもたらすように構成されうる。カメラの視野がずれるとき、つなぎ線のルート及び色が再評価されてもよく、そのような線は、状況によっては、所与のオブジェクト上の異なるハンドルで終了してもよい。（これは、例えば、ショートパンツを対応するアイコンに接続するつなぎ線の場合である。図３３では、女性のショートパンツの右側のハンドルが採用され、図３４では、左側のハンドルが使用される。）
【０４２１】
カメラの視野が、いくつかの明確にウォーターマーキングされたオブジェクトを包含する場合、ウォーターマーク検出の指示を、オブジェクトの各々の上に提示することができる。スマートフォンが、女性の衣類を包含する画像の領域内で符号化されたあるウォーターマーク、及び、女性のハンドバッグを包含する画像の領域内で符号化された別のウォーターマークを検出するとき、そのような構成を図３６に概念的に示す。ここでは、スマートフォンは、女性のショートパンツ及びブラウスを描く画像の領域を修正して、１つの特定のグラフィック効果（オーバーレイされた星パターンとして示す）を提示し、女性のハンドバッグを描く画像の領域を修正して、異なるグラフィック効果（オーバーレイされた円として示す）を提示する。
【０４２２】
デジタルウォーターマークの証拠が検出されるとき、スマートフォンによって提示されるグラフィック効果は、−上記で示すものをはるかに超えて−いかなる外観を有することも可能である。１つの特定の構成では、ソフトウェアＡＰＩが、そのような検出によってアクティベートされ、ウォーターマーキングされた領域の見かけの中心のピクセル座標を（おそらく、半径、又は垂直及び水平範囲、又はベクトルエリア記述など、他の情報とともに）出力してもよい。ＡＰＩ、又は他のソフトウェアは、どのようなグラフィック効果がこの特定のウォーターマークのために（例えば、このペイロードのために、又は、このエリア内で発見されるウォーターマークのために）提示されるべきであるかを定義する、ソフトウェアスクリプトをフェッチしてもよい。スクリプトは、拡大鏡、泡、揺れ、炎のアニメーション、その他などの効果−ウォーターマークが位置すると見られるとＡＰＩがレポートする領域に、配置される−をもたらすことができる。
【０４２３】
１つの特定の実施形態では、そのような領域のウォーターマークが検出されるとすぐに、スマートフォンは、画面上に、ウォーターマーキングされた領域内、又はその縁部で開始するつなぎ線を表示し始め、その線を、画面の縁部に向かってくねって進むようにアニメーション化する。伸びる線が縁部に達するまでに、スマートフォンは、復号されたウォーターマークをリモートデータベースへ送っており、応答において、適切な表示応答−アニメーションの線が終了するところでハンドバッグアイコンを提示するなど−を確定できるようになる情報を受信している。（スマートフォンはまた、線の上端部を、受信された情報によって定義されたハンドル点にスナップしてもよい。）
【０４２４】
フィンガープリントベースの画像オブジェクト識別の場合、典型的には、提示された画像に関連付けられたインタラクティビティのアラートをユーザに出すための、きらめき又は他のグラフィック効果はない。そして、上記で説明したような振る舞いは、通常、自動的に起動されるようにはならず、その理由は、振る舞いをトリガするための画像特徴がないからである。（いくつかの実装形態は、しかし、バーコード、又は、ＲＦＩＤ／ＮＦＣにより検知されたデータなど、他のトリガを使用することがある。）代わりに、ユーザは、そのようなアクションを、ユーザ命令によって開始するようになる。応答において、電話は、画像（又は、画像に基づいたフィンガープリントデータ）をリモートシステム／ウェブサービスへ送信する。リモートシステムは、フィンガープリントを（既に電話によって提供されていない場合に）計算し、データベース内でマッチする参照フィンガープリントを識別しようとする。マッチが発見される場合、データベース内の関連付けられた情報は、画像によって描かれたオブジェクト／シーン（例えば、特定のカタログ及びページ）を識別する役目を果たす。そのような識別が行われると、上記で詳述した振る舞いが進行することが可能である。
【０４２５】
上記で説明したように、ハンドバッグがもはや表示されないように、カメラの視野が動かされるとき、対応するハンドバッグタグは、画面の底部から除去される。他の実施形態では、ユーザは、現在表示されている画像ビューをフリーズさせるため、及び／又は、画面上に現在表示されているタグを維持するためのコマンドとして、スマートフォンが解釈するアクションを、取ることができる。そのような機能性は、ユーザがカメラをカタログページに向けて、対応するタグを得て、その後、画像／タグとインタラクトするためにより好都合な位置へ電話を位置決めし直すことを可能にする。
【０４２６】
取り込まれた画像との関連で説明したが、これらの実施形態、及び、本明細書の他のところの実施形態を、ストレージデバイスから、又はネットワークの全体から受信されるなど、他の方法で得られた画像とともに実装できることは理解されよう。
【０４２７】
同様に、オブジェクト識別は、詳述した構成では、ウォーターマーキング（又は、画像フィンガープリンティング）によって行われるが、他の実施形態は、バーコード、グリフ、ＲＦＩＤ／ＮＦＣチップ、その他など、他の形式の識別に基づくことが可能である。
スマートフォンハードウェア及びＲＤＦトリプル
【０４２８】
スマートフォンには、例えば、ゲーム、ビデオ、及び、他の画像集中的なアプリケーションのための、複雑な画面表示のレンダリングの速度を速めるために、グラフィックス処理装置（ＧＰＵ）がますます装備されつつある。
【０４２９】
ＧＰＵチップは、複数のプロセッシングコア、及び、一般にグラフィックスのために最適化される命令セットによって特徴付けられる、プロセッサチップである。典型的な使用では、各コアは、画像内の小さいピクセル値の区域専用であり、例えば、陰影付け、霧、アフィン変換、その他など、視覚的効果を適用する処理を行う。ＧＰＵは通常、そのようなプロセッシングコアと、ＲＧＢフレームバッファなど、関連付けられたメモリとの間の、画像データの交換を加速するためにも最適化される。（ＧＰＵによって処理される画像データは一般に、赤／緑／青、又はＹＵＶなど、３つの成分プレーンで表現される。）整数データストレージの複数のプレーンを提供することに加えて、フレームバッファはまた、フレームバッファが（例えば、適切なインターフェースハードウェアによって）バッファされたデータを表示するためにデバイス画面へ素早く切り替えることを可能にするように構成される点でも、プログラムストレージメモリとは異なる。フレームバッファのピクセルサイズは通常、表示画面のピクセルサイズと１：１の対応を有する（例えば、９６０×６４０ピクセル表示画面を有するスマートフォンは一般に、１つ又は複数の９６０×６４０フレームバッファを有するようになる）。
【０４３０】
ＧＰＵは、グラフィックス処理の速度を速めることに起源を有したが、他の用途にも適用されている。汎用ＧＰＵ（ＧＰＧＰＵ）のより幅広い分野では、そのようなデバイスは現在、音声認識からタンパク質の折り畳み計算に及ぶ応用例で使用されている。多数のメインフレームスーパーコンピュータは、超並列処理（ｍａｓｓｉｖｅ  ｐａｒａｌｌｅｌｉｓｍ）のためにＧＰＵに依拠する。ますます、ＮＶＩＤＩＡなどのＧＰＵベンダは、通常の「Ｃ」言語コンピュータプログラムからの指定された関数を、自社のＧＰＵを装備したビデオカード上で実行可能にする、ソフトウェアツールを提供しつつある。
【０４３１】
本技術の別の態様によれば、ある実施形態は、グラフィックスの目的のために提供されたスマートフォンハードウェア（例えば、ＧＰＵ、及びＲＧＢフレームバッファ）を、検索及びセマンティックな推論のためなど、ＲＤＦトリプルとともに代わりに使用するために転用する。
【０４３２】
（セマンティックな推論は時々、アサートされた事実のセットに基づいて、論理的帰結を見極めること（例えば、推測すること）として定義される。）
【０４３３】
１２８×１２８ピクセルの寸法を有することがある、画像データのフレームを格納するために使用されるメモリの概念図である、図２２を考えられたい。各ピクセルは、３つの成分色値を有し、１つは赤、１つは緑、１つは青である。例示的ピクセルを、ＲＧＢ色値｛４３，３５，２１６｝とともに示す。これらのデータは、ロイヤルブルーに類似した色を有するピクセルに対応する。
【０４３４】
この概念的構成は、ＲＤＦトリプルのストレージにうまくマッピングする。ピクセル表現の３つの成分を格納する代わりに、このメモリは、ＲＤＦトリプルの３つの成分−一般に、主部、述部、及び目的部と呼ばれる−を格納する役目を果たす。
【０４３５】
画像メモリロケーションに格納されたデータは典型的には、８ビット値（つまり、赤、緑、青に１つずつ）を備える。各値は、０〜２５５の範囲の整数でありうる。ＲＤＦ使用のために転用されるとき、ＲＤＦ成分は、０〜２５５の範囲の整数コードとして同様に表現される。テーブルなど、補助データ構造は、異なる８ビットＲＤＦコードを、関連付けられた文字列、整数、又は実数値にマッピングすることができる。
【０４３６】
一例が以下に続き、この例では、セマンティックな推論が入力ＲＤＦデータのセットに適用されて、人々の間の述べられていない関係が見極められる。推論が後に適用されるようになるそのような入力トリプルの一例は、以下の通りである。
ＢＯＢ  ＨａｓＣｈｉｌｄ  ＴＥＤ（ボブにはテッドという子供がいる）
このトリプルは、ボブという名前の人に、テッドという名前の子供がいるという、情報を表現する。「ＢＯＢ（ボブ）」は主部であり、「ＨａｓＣｈｉｌｄ（子供がいる）」は述部であり、「ＴＥＤ（テッド）」は目的部である。
【０４３７】
そのようなデータを画像メモリに格納するために、１つ又は複数のテーブルを使用して、異なるデータを対応する整数コードにマッピングすることができる。例えば、第１のテーブルは、人々の名前を整数コードにマッピングすることができ、例えば、以下の通りである。
【表５】
0006054870.tif 000006
【０４３８】
そのようなテーブルは、ＲＤＦトリプルの単一の成分（例えば、主部データ）専用であってもよく、又は、２つ以上の成分用になることができる。データは、すべて同じタイプ（例えば、人々の名前）であってもよく、又は、異なるタイプのデータが含まれてもよい。あらゆる８ビットコードが対応するデータにマッピングされる必要があるとは限らない。
【０４３９】
本例では、さらなるテーブルが使用されて、８ビットコードが、人々に関与する異なる述部に関連付けられ、例えば、以下の通りである。
【表６】
0006054870.tif 000007
【０４４０】
「ＢＯＢ  ＨａｓＣｈｉｌｄ  ＴＥＤ」という表現は、このようにして、８ビットコード｛６，３，４｝のトリプルとして表現されうる。第１のコード及び第３のコード（６及び４）の意味は、テーブルＩによって指示されるが、第２のコード（３）の意味は、テーブルＩＩによって指示されることは理解されよう。
【０４４１】
図２３は、図２２と同じメモリ構成を示すが、ここではＲＤＦ使用のために転用されている。８ビット整数コード｛６，３，４｝は、３つのプレーン−ここでは、主部、述部、及び目的部を表す−内の対応するメモリロケーションに格納される。
【０４４２】
「ＢＯＢ  ＨａｓＣｈｉｌｄ  ＴＥＤ」を指示する、１つのトリプルが、図２３で特に詳述される。しかし、画像メモリは典型的には、極めて大きく、例えば、１０２４×７６８である。小さい１２８×１２８ピクセルメモリさえもが、１６，３８４個の異なるデータ要素を有するので、１６，３８４個のトリプルを格納できるようになる。図２４は、メモリに格納されうる、潜在的に数千個のそのようなトリプルのうち、少数を示す。
【０４４３】
（テーブルＩＩでは、述部のすべてが、それらの主部のためにも、それらの目的部のためにも、個人名を使用するとは限らない。例えば、述部のうち１つは、「ＨａｓＧｅｎｄｅｒ（性別を有する）」である。この述部の主部は個人名であるが、この述部の目的部は「Ｍａｌｅ（男性）」又は「Ｆｅｍａｌｅ（女性）」である。これらの後者の２つのデータには、テーブルＩＩのコード２５４及び２５５が割り当てられてもよい。）
【０４４４】
図２２に戻ると、ロイヤルブルーピクセルは、メモリ内で、レンダリングされた画像内のその所望の提示の位置に対応するロケーションに格納される。述べたように、スマートフォン内のフレームバッファは典型的には、表示内のピクセル要素との１対１のマッピングを有する。したがって、ロイヤルブルーデータ｛４３，３５，２１６｝がメモリ内で格納される位置は、メモリからレンダリングされるようになる図において、その青ピクセルがどこに現れるかに影響を及ぼす。
【０４４５】
ＲＤＦトリプルを格納するとき、−メモリ内で−どこにトリプルが格納されるべきであるかを指図する、メモリと表示の間の固有のマッピングはない。例えば、図２３では、｛６，３，４｝トリプルは、１２８×１２８ピクセルメモリ内の１６，３８４個のロケーションのいずれかに格納されうる。
【０４４６】
画像メモリ内でピクセルデータを処理して、所望のグラフィック効果を達成する代わりに、図２３のメモリ内のＲＤＦトリプルデータが処理されて、セマンティックな推論ルールが適用される。例示的な例では、推論は、人々の間の追加の関係情報を推測する。
【０４４７】
少数のＲＤＦトリプルがポピュレートされた、スマートフォンメモリの小さい抜粋を示す、図２５を考えられたい。（８ビットコード及び対応するテキストがともに、説明の便宜上、描かれる。）
【０４４８】
わかるように、ＲＤＦデータは、アリスに姉／妹ヘレンがいることをアサートする。また、データは、ボブに２人の姉／妹（メアリー及びスー）、子供（テッド）、及び、２人の兄／弟（チャック及びジョン）がいることをアサートする。
【０４４９】
この例では、ＧＰＵは、ルールベースの推論を適用して、個人間の新しいタイプの関係−叔父であるという関係−を見極めるようにプログラムされる。プレインイングリッシュで述べられた、そのような推測ルールは、ある人に子供も兄／弟もいる場合、兄／弟は子供の叔父である、というものでありうる。ブール疑似コード方式で分析されると、このルールは、以下のように表現されうる。
ＩＦ（ＰＥＲＳＯＮ１  ＨａｓＣｈｉｌｄ  ＰＥＲＳＯＮ２）
ＡＮＤ  ＩＦ（ＰＥＲＳＯＮ１  ＨａｓＢｒｏｔｈｅｒ  ＰＥＲＳＯＮ３），
ＴＨＥＮ  ＰＥＲＳＯＮ２  ＨａｓＵｎｃｌｅ  ＰＥＲＳＯＮ３．
【０４５０】
ＧＰＵがこの推論ルールを図２５に描かれたデータに適用する場合、ＧＰＵは、２つの新しいセマンティックなアサーションを作成することによって結論付けるようになる。
１．ＴＥＤ  ＨａｓＵｎｃｌｅ  ＣＨＵＣＫ（テッドにはチャックという叔父がいる）
２．ＴＥＤ  ＨａｓＵｎｃｌｅ  ＪＯＨＮ（テッドにはジョンという叔父がいる）
【０４５１】
これらの２つの新しいアサーションは、図２５のＲＤＦデータストアに追加されうる。
【０４５２】
上記で述べたように、どこに特定のトリプルが格納されるべきであるかを指図する、メモリと表示の間の固有のマッピングはない。しかし、この例では、出願人は、類似の主部をともにグループ化することを選ぶ。特に、メモリは、概念的に、３×３ブロック（３０２、３０４、その他）に分割され−各々は、異なるＲＤＦ主部に向けられる。この分割を、図２５で濃い線によって示す。各ＲＤＦ主部について、最大９個の異なるトリプルアサーションを、そのような３×３ブロック内に格納することができる。
【０４５３】
そのような空間的局所性（ｓｐａｔｉａｌ  ｌｏｃａｌｉｔｙ）とともにデータを編成することは、ＧＰＵの複数のコア−及び、各コアに入力及び出力を提供するバス構成−が一般に、隣り合っているピクセルの区域に働きかけるように最適化されるという、利点をもたらす。空間的局所性をデータ上で実施することによって、特定の主部に関するすべてのアサーションを、同じＧＰＵコアによって処理することができる。これにより、処理の速度が速くなり、例えば、その理由は、データが通常、コア間で共有される必要がないからである。
【０４５４】
推論を実行するソフトウェアを、異なる方法で実装することができる。各コアが９個のトリプルのドメインに働きかけると仮定すると、一実装形態は、以下のように機能する。
・９個の述部の各々をチェックして、そのコード＝５であるかどうかを確かめ、そうである場合、カウンタ「ｉ」を増分する
・ｉ＝０である場合、終了する
・残りの述部の各々をチェックして、そのコード＝３であるかどうかを確かめ、そうである場合、カウンタ「ｊ」を増分する
・ｊ＝０である場合、終了する
・Ｘ及びＹのすべての組み合わせを使用して、ｉ＊ｊ個の新しいアサーション「Ｘ  ＨａｓＵｎｃｌｅ  Ｙ（ＸにはＹという叔父がいる）」を作成し、但し、Ｘは、その述部がコード＝３を有する目的部であり、Ｙは、その述部がコード＝５を有する目的部である。
【０４５５】
図示の例では、ＧＰＵの演算テーブルに、上記の手順を実行するための命令がロードされる。ＧＰＵ演算が次いで呼び出されるとき、デバイスは、ｉ＝１及びｊ＝２を発見し、上記で識別されたような、２つの新しいアサーションを作成する。
【０４５６】
前述の手順は時々、メモリ内のトリプルのストレージにさらなる空間的制約を課すことによって、短くすることができる。つまり、同じ主部を有するトリプルを一緒に共通ブロック内でグループ化することに加えて、トリプルはまた、ブロック内でそれらの述部コードに基づいて順序付けも行われる。そのようなソートにより、９個の述部が、完全な検索なしに、特定のコードについてチェック可能になることが多い。
【０４５７】
例えば、図２５では、述部が、各ブロックの左上のセルで開始して、降順にリストされる。上記で詳述した手順では、述部をコード「５」についてチェックするとき、「５」未満のコードに遭遇するとき、チェックは停止することが可能である。図２５のブロック３０４内でチェックされた第５の述部（すなわち、３×３ブロック内の中心のセル）は、コード「３」を有する。この時点で、「５」についてのチェックは停止することができ−それ以上はないであろう。
【０４５８】
同様に、コード「３」についてチェックするとき、そのチェックは、「５」についてのチェックが停止したところで開始することが可能であり−その理由は、「３」がその順序で以前に生じることがないからである。同様に、「３」についてのチェックは、「３」未満の最初の述部が発見されるとき、停止することが可能である。（空のセルは、「０」の値を格納し、「０」の値は、例示を明確にするために図示しない。）
【０４５９】
ブロック内のトリプルをこの方式で述部によってソートすることによって、「５」コード及び「３」コードの数をカウントするために、９個の述部を２回チェックすることは必要ではない。代わりに、５個がチェックされて、すべての「５」が合算され（つまり、最初の「３」に遭遇するとき、停止する）、さらに２個がチェックされて、すべての「３」が合算される（つまり、中心のセルで開始し、次のセル−「０」述部−に遭遇するとき、停止する）。
【０４６０】
異なる実装形態は、テンプレートマッチングに基づく。図２６及び図２７を考えられたい。図２６は、含まれるテンプレートのサブセットを示す。これらのテンプレートでは、空のボックスは、「気にしない」を指示する。（図２７は単に、ブロック内のトリプルの各々に文字の名前を与えて、図２６のテンプレートを説明するときに言及を容易にするものである。）
【０４６１】
ＧＰＵコアは、トリプルメモリ（例えば、３０４）内のブロックの３×３述部プレーンを、テンプレートの各々に対してチェックして、マッチするコードパターンを識別する。各マッチについて、新しい「ＨａｓＵｎｃｌｅ（叔父がいる）」アサーションが生成される。
【０４６２】
例えば、図２６の左上のテンプレートの適用において、コアは、トリプル「ａ」が述部＝３を有し、且つ、トリプル「ｃ」が述部＝５を有するかどうかをチェックする。そうである場合、入力トリプル「ａ」の目的部をその主部として、入力トリプル「ｃ」の目的部をその目的部として、新しい「ＨａｓＵｎｃｌｅ」トリプルが作成される。
【０４６３】
同様に、ＧＰＵコアは、図２６の第２のテンプレートを適用して、トリプル「ｂ」が述部＝３を有し、且つ、トリプル「ｃ」が述部＝５を有するかどうかをチェックする。そうである場合、入力トリプル「ｂ」の目的部をその主部として、入力トリプル「ｃ」の目的部をその目的部として、新しい「ＨａｓＵｎｃｌｅ」トリプルが作成される。などとなる。
【０４６４】
マッチングの対象の６４個のテンプレートがあるが、そのような比較は、ＧＰＵコアによって迅速に行われる。そして、百以上の異なるトリプルデータのブロックが、異なるＧＰＵコアによって並列に処理されうるので、それにもかかわらず、高スループットが達成される。
【０４６５】
図２５のブロック３０４に適用されると、図２６の２つの太字のテンプレートが、描かれたデータ内のパターンにマッチし、上記で識別された２つの新しいアサーションが生じることは理解されよう。
【０４６６】
図２５でトリプルをソートすることで、最初に定義した手順を支援できることと全く同じように、図２５でトリプルをソートすることで、テンプレートベースの手順を同様に支援することができる。特に、トリプルを述部でソートすることによって、必要とされるテンプレートの数を半分にすることができる。
【０４６７】
より詳細には、−（図２５に示すように）述部で降順にソートされる場合−図２６の左上のテンプレート内で描かれた構成が発生することがないことは理解されよう。つまり、ブロックの左上角に「３」、及び、その右に「５」が来ることは決してない。同様に、第２のテンプレートは、同じ理由のために必要とされない。実際に、可能性のあるテンプレートのうち半分（すなわち、「５」の前に「３」を配置するもの）は、必要とされない。
【０４６８】
本技術のいくつかの実装形態は、整数論を使用して、推論を助けるか、又は速度を速める。
【０４６９】
上記で挙げた例では、整数論手順が最初に−ブロック内の入力データから見極められるべき、いずれかの「ＨａｓＵｎｃｌｅ」アサーションがあるかどうかを判定するためのチェックとして−適用されうる。この予備的チェックが肯定的である場合にのみ、テンプレートマッチング手順、又は、別のそのような手順が呼び出される。
【０４７０】
この場合に使用されうる例示的整数論は、素因数を含む。「ＨａｓＣｈｉｌｄ」述部にも、「ＨａｓＢｒｏｔｈｅｒ（兄／弟がいる）」述部にも、素数コード（すなわち、３及び５）が割り当てられることは理解されよう。３×３ブロック内のゼロでない述部コードのすべてが掛け合わされる場合（又は、「１」が「０」の代わりに用いられて、すべての９個の述部コードが掛け合わされる場合）、結果として生じる積は、そのブロックが少なくとも１つの「３」及び少なくとも１つの「５」を含む場合、常に１５の倍数となる。
【０４７１】
ＧＰＵコアは、この計算を行い−ブロック内の述部コードを掛け合わせる。この結果が次いで、（ＧＰＵコアによって、又は他の方法で）１５で除算される。余りがある場合（すなわち、積が１５で均等に割り切れない場合）、そのブロックは、３と５をともに有していない。そのブロックは、したがって、いかなる「ＨａｓＵｎｃｌｅ」アサーションを生成することもできず、テンプレートマッチング手順（又は、他のそのような手順）は、実際的な意味がないとしてスキップされうる。
【０４７２】
同じ乗算の積をまた使用して、入力データのブロック内の１つ又は複数の「ＨａｓＡｕｎｔ（叔母がいる）」関係の存在について、選別することもできる。「ＨａｓＡｕｎｔ」についてのルールは、「ＨａｓＵｎｃｌｅ」についてのルールに類似しているが、代わりに「ＨａｓＳｉｓｔｅｒ（姉／妹がいる）」を使用する。プレインイングリッシュでは、ある人に子供も姉／妹もいる場合、姉／妹は子供の叔母である。
【０４７３】
テーブルＩＩでは、「ＨａｓＳｉｓｔｅｒ」述部に、７の（素数）コードが割り当てられる。入力トリプルのブロック内にいずれかの「ＨａｓＡｕｎｔ」関係がある場合、その述部の積は常に、２１（すなわち、３＊７）で均等に割り切れるようになる。
【０４７４】
整数０〜２５５の中に、５４個の異なる素数がある。これらの素数コードが、セマンティックな推論ルールによってともに論理積が取られうる述部に割り当てられる（そのような割り当てが、テーブルＩＩの場合のように、おそらく他の値をスキップする）場合、述部データのブロック内の素数コードのいかなるグループの存在（又は、共在（ｃｏ−ｐｒｅｓｅｎｃｅ））も、すべての９個の述部コードの積が、その素数のグループの積によって均等に割り切れるかどうかをチェックすることによって、判定することができる。（例えば、２、３及び１１の共起をチェックするには、６６で割り切れることをチェックする。）
【０４７５】
ＧＰＵは、３×３ブロックのトリプルデータごとに１つのコアを有していないことがある。例えば、メモリは、１０００個の３×３ブロックのトリプルデータを有することがあるが、ＧＰＵは、２００個のコアしか有していないことがある。このことに対処することができる、多数の方法がある。１つは、ＧＰＵが素数選別手順を最初の２００個のブロックに適用すること、及び、「ＨａｓＵｎｃｌｅ」関係を有することが発見されたブロックを、フレームバッファにコピーすることである。この処理が、第２、第３、第４及び第５の２００個のブロックに対して繰り返し、「ＨａｓＵｎｃｌｅ」関係を有すると判定されたブロックのコピーが、フレームバッファに追加される。最後に、以前に詳述したパターンマッチング（又は、別の手順）が、フレームバッファ内のブロックで実行されて（ブロックのすべてが潜在的な「ＨａｓＵｎｃｌｅ」関係を有することがわかっている）、新しいアサーションが生成される。
【０４７６】
素数の積は、適用可能である整数論の１つのタイプである。多数の他のタイプがある。別のクラスは、加法的整数論を含む。簡単な例についての、以下の述部コードのテーブルを考えられたい。
【表７】
0006054870.tif 000008
【０４７７】
このテーブルはまばらであり、大部分の８ビットコードは、述部が組み合わせられるときに所望の整数論結果を生じるために、割り当てから予約されている。実際には、このテーブル内のコードは、１、１０及び１００のみである。
【０４７８】
この述部値の割り当ては、１つ又は複数の「ＨａｓＵｎｃｌｅ」関係が所与のトリプルのブロックから推論されうるかどうかの、別のチェックを可能にする。この特定の実装形態では、ブロック内の９個の述部コードが合計される。（やはり、いかなる空のセルにも「０」が使用される。）この特定のまばらな整数の割り当ては、少なくとも１つの「ＨａｓＣｈｉｌｄ」述部、及び、少なくとも１つの「ＨａｓＢｒｏｔｈｅｒ」述部がある場合、和の最後の２つの１０進数の桁の各々がゼロでなくなるように、設計される。ＧＰＵコアは、このチェックを行い、このチェックが満たされる場合、ＧＰＵは次いで、上記で説明した手順のうち１つによってなど、ブロックをさらに処理して、新しい「ＨａｓＵｎｃｌｅ」アサーション（複数可）を抽出することができる。
【０４７９】
（この加法的手順の変形もまた、１つ又は複数の「ＨａｓＡｕｎｔ」関係についてチェックすることができる。このチェックでは、１００の値が最初に和から減算される。コアは次いで、（１）結果が正であること、及び、（２）結果の最後の桁がゼロでないことをチェックする。これらの条件が満たされる場合、１つ又は複数の「ＨａｓＡｕｎｔ」関係をデータからアサートすることができる。）
【０４８０】
前述の整数論の例は、単純であり、やや人為的であるが、基礎をなす原理を実証する。実際の実装形態は、通常は異なるようになる。（含まれる特定の演算は通常、使用されているＧＰＵコア（複数可）の基本命令セットから選択される。）
【０４８１】
前の例は、ゼロでない１０進数の桁についてチェックしたが、多数の応用例は、代わりに、整数論原理を２進又は１６進表現に適用するようになる。
【０４８２】
実装形態は、他の方法で、例示した例とは異なることが多くなる。例えば、推論ルールは、３個以上の述部を含むことがある。各ブロック内のトリプルの数は、９とは異なることがある。実際に、メモリの均等なブロック編成は必要とされず、いくつかの実装形態は、可変サイズのブロックを有するか、又は、ブロック編成を全くなしで済ませることがある。時々、ＧＰＵコアは、メモリの重複するエリア（例えば、重複するブロック）にアクセスすることがある。トリプルメモリの各プレーンは、８以外（例えば、１６）のビット深度を有することがある。メモリ内の空間的局所性が採用される場合、データは、主部のアイデンティティではなく、述部又は目的部のアイデンティティによってグループされうる。同様に、応用例に応じて、−各ブロック内で、又は、トリプルメモリ全体にわたって−主部、述部、又は目的部でソートすることが望ましいことがある。当然、異なる述部（又は、主部若しくは目的部）に割り当てるための特定の８ビットコードの選択は、特定のコンテキストによって決まることが多くなる。
【０４８３】
上記で詳述した推論演算によって出力される「ＨａｓＵｎｃｌｅ」アサーションを、トリプルデータベース（例えば、図２５）に追加できることと全く同じように、逆演算からの出力もそうすることができる。例えば、「ＨａｓＣｈｉｌｄ」の逆は、「ＨａｓＰａｒｅｎｔ（親がいる）」である。そのため、トリプル「ＢＯＢ  ＨａｓＣｈｉｌｄ  ＴＥＤ」を処理して、新しい逆のトリプル「ＴＥＤ  ＨａｓＰａｒｅｎｔ  ＢＯＢ（テッドにはボブという親がいる）」を生じることができる。同様に、推論演算の結果を逆にして、さらにより豊富な関係の表現をもたらすことができることが多い。例えば、上記で生成された出力「ＴＥＤ  ＨａｓＵｎｃｌｅ  ＣＨＵＣＫ」を逆にして、「ＣＨＵＣＫ  ＨａｓＮｅｐｈｅｗ  ＴＥＤ（チャックにはテッドという甥がいる）」を生じることができる。
【０４８４】
逆の関係自体を、図２５のメモリ内、又は他の場所でトリプルとして表現することができ、例えば、「ＨａｓＵｎｃｌｅ  ＨａｓＩｎｖｅｒｓｅ  ＨａｓＮｅｐｈｅｗ（叔父がいる、は、甥がいる、の逆である）」である。
【０４８５】
トリプルストアが販売用の車両についての情報を含む、異なる例を考えられたい。この情報は、ユーザがスマートフォンカメラを使用して、分類広告発行物の車両セクションの画像を取り込むことに応答して、スマートフォンのメモリに自動的にダウンロードされていてもよい（例えば、米国特許出願第１３／０７９３２７号を参照）。
【０４８６】
この例では、８ビット主部コードは、異なる車両を識別するテキスト文字列に対応してもよく、例えば、以下の通りである。
【表８】
0006054870.tif 000009
【０４８７】
このテーブルＩＶは、メイン主部テーブルと見なされうる。
【０４８８】
これらの主部の各々に関連付けられるものは、典型的には、複数の述部及び目的部となる。８ビットの述部コード、及び、それらの関連付けられた意味は、以下の通りでありうる。
【表９】
0006054870.tif 000010
【０４８９】
テーブルＶは、メイン述部テーブルと見なされうる。（このテーブル内の述部は、例示のために選ばれる。多数の実装形態は、確立されたＯＷＬオントロジーの語彙など、標準化された語彙を採用するようになる。）
【０４９０】
８ビットの主部コード、及び、それらの関連付けられた意味は、以下の通りでありうる。
【表１０】
0006054870.tif 000011
【０４９１】
テーブルＶＩは、メイン目的部テーブルと見なされうる。
【０４９２】
前述のように、スマートフォンメモリ内のトリプルは、これらの３つの語彙テーブルから選択された８ビットコードを使用して、アサーションを表現することができ、例えば、以下の通りである。
・１９８５年式ウィネベーゴ（Ｗｉｎｎｅｂａｇｏ）チーフテン（Ｃｈｉｅｆｔａｎ）  ＨａｓＧｒｏｓｓＶｅｈｉｃｌｅＷｅｉｇｈｔ  ６〜７トン（１９８５年式ウィネベーゴ・チーフテンは、６〜７トンの自動車総重量がある）は、｛３，３，６２｝と表現され、
・１９８５年式ウィネベーゴ・チーフテン  ＨａｓＥｘｔｅｒｉｏｒＣｏｌｏｒ  白（１９８５年式ウィネベーゴ・チーフテンは、白の外装色である）は、｛３，１，１７｝と表現される。
【０４９３】
メイン目的部テーブル内のいくつかのエントリは、メイン述部テーブル内のエントリの１つのみとともに使用されうることに留意されたい。例えば、目的部コード６２（例えば、６〜７トン）は、ＨａｓＧｒｏｓｓＶｅｈｉｃｌｅＷｅｉｇｈｔ（自動車総重量がある）述部のみとともに使用されうる。目的部テーブル内の他のエントリは、述部テーブル内のいくつかのエントリとともに使用されうる。例えば、目的部コード２〜５は、ＨａｓＰａｓｓｅｎｇｅｒＣａｐａｃｉｔｙ（乗客定員である）述部とともに、及び、ＨａｓＤｏｏｒｓ（ドアがある）述部とともに使用されることがある。（同様に、目的部コード１７〜１９は、ＨａｓＥｘｔｅｒｉｏｒＣｏｌｏｒ（外装色である）述部とともに、及び、ＨａｓＵｐｈｏｌｓｔｅｒｙＣｏｌｏｒ（座席カバー色である）述部とともに使用されることがある。）
【０４９４】
可能な目的部の値の数は、８ビットメモリプレーンに収容可能である２５６を超えることが多い。例えば、２５０台の車両の各々は、関連付けられた異なる価格も、異なる電話番号も有することがあり、つまり、５００個の異なる値を有することがある。
【０４９５】
その目的部が、メイン目的部テーブル内の８ビットコードに関連付けられうる２５６個の異なる値の中で収容不可能である述部については、「０」の目的部コードを、そのようなトリプル内で指定することができる。これにより、スマートフォンソフトウェアに、対応する目的部情報について、メイン目的部テーブルの代わりに補助データ構造（例えば、テーブル）を調べるように指図する。この異なる構造は、述部名（又は、その番号の相当するもの）によって識別されてもよい。
【０４９６】
例えば、トリプル｛３，４，０｝は、ウィネベーゴの価格に関する。しかし、目的部コード「０」は、価格が、メイン目的部テーブル（すなわち、上記のテーブルＶＩ）内の８ビットコードによってインデックス付けされた値によって指示されないことを、指示する。代わりに、「０」は、補助メモリテーブル＃４（述部の値４を指す）を調べるように、スマートフォンに指図する。補助メモリテーブル＃４は、対応する主部コード（理解しやすいように、丸括弧内で示される）に関連付けられた、すべての車両についての価格を有してもよく、例えば、以下の通りである。
【表１１】
0006054870.tif 000012
【０４９７】
いくつかの実施形態では、そのような補助テーブルは、主部コードではなく、関連付けられた目的部の値（ここでは、価格）でソートされて−検索が容易にされうる。
【０４９８】
スマートフォンＧＰＵは、メイン主部−述部−目的部メモリ内に格納されたデータをほぼ即座にフィルタリングして、ある探し求められたパラメータ（すなわち、メイン目的部テーブル内で表現されたパラメータ）を有する車両を識別することができる。例えば、ユーザが、（１）トラック、（２）４〜６人の乗客を座らせることができること、に関心がある場合、これらのパラメータを、従来のスマートフォングラフィカルユーザインターフェース（ＧＵＩ）を使用して入力することができ、結果を迅速に決定することができる。
【０４９９】
１つの例示的ＧＵＩは、ドロップダウンメニュー、又は、スクロール可能選択ホイールを提示し、ドロップダウンメニュー、又は、スクロール可能選択ホイールには、述部メインテーブル及び目的部メインテーブルから引き出されたリテラルがポピュレートされる。補助ＧＵＩテーブルが使用されて、情報の表示が容易にされ、例えば、述部のプレインイングリッシュ対応物が提供され、それにより検索が入力されうる特定のコードが指示されてもよい。
【０５００】
図２８、図２９Ａ及び図２９Ｂは、一例を示す。１つ若しくは複数のテーブル４００、又は他のデータ構造（複数可）は、ＧＵＩメニューの生成において使用される情報を格納する。ＧＵＩメニュー、４０２、４０４、その他のシーケンスは、スマートフォン画面上に提示され、ユーザが所望の検索パラメータを入力できるようにする。
【０５０１】
図示のＧＵＩ４０２は、テーブル４１０の列４１０からの異なるメニュー凡例が選択可能に表示される、第１のスクロール可能ウィンドウ部４２０を有する。図示のように、ユーザは、「何を探していますか？」オプションへスクロールしている。
【０５０２】
第２のスクロール可能ウィンドウ４２２には、テーブル４００を参照することによって決定されるような、ウィンドウ部４２０に示された選択に対応する第２のレベルのメニュー選択肢がポピュレートされる。例えば、ユーザがウィンドウ部４２０を「何を探していますか？」へスクロールしているので、スマートフォンは、第２のウィンドウ部４２２に「車」「トラック」「オートバイ」及び「その他」などの選択肢を提示することによって応答する。これらの特定のテキスト文字列は、テーブル４００の列４１２から引き出され、但し、これらの特定のテキスト文字列は、「何を探していますか？」トップレベルメニューに対応する。図示のように、ユーザは、ウィンドウ４２２をスクロールして、「トラック」を指示している。
【０５０３】
ＧＵＩ４０２は、ユーザがタップして、さらなる検索パラメータを入力することができる、ボタン４２４をさらに含む。代替として、ユーザは、ユーザにより入力されたパラメータ（複数可）に基づいた検索の結果を提示する「結果を取得」ボタン４２６を、タップすることができる。
【０５０４】
ユーザがボタン４２４をタップすると仮定すると、ＧＵＩは、ユーザによって入力されたばかりの値（すなわち、「何を探していますか？」及び「トラック」）、又は、そのような値に関連付けられた８ビットコード値を格納し、次いで、ユーザがウィンドウ４２０と、次いで再びウィンドウ４２２とインタラクトできるようにする。今回は、ユーザは、ウィンドウ４２０から「乗客定員は何人ですか？」を選択する。
【０５０５】
テーブル４００の列４１２を参照することによって、スマートフォンは、第２のウィンドウ４２２を、「１」、「２」、「３」、「４」、「５」及び「６」など、対応するオプションでポピュレートすることを知る（その理由は、これらのラベルが「乗客定員は何人ですか？」メニュー選択に関連付けられるからである）。テーブル４００内のフラグ（図示せず）は、ソフトウェアに対して、「乗客定員は何人ですか？」メニューオプションが選択されるとき、第２のウィンドウ４２２ａをレンダリングするべきであることを信号伝達することができ、第２のウィンドウ４２２ａ内で、ユーザは範囲の上限を指定することができる。（元のウィンドウ４２２は次いで、範囲の下限としての役目を果たす。）図２９Ｂで、ユーザは、ウィンドウ４２２を「４」へ、ウィンドウ４２２ａを「６」へスクロールしている。ユーザは、したがって、４人と６人の間の乗客を座らせることができるトラックに関心がある。
【０５０６】
ユーザは次いで、「結果を取得」ボタン４２６をタップすることによって、検索結果を要求することができる。
【０５０７】
ユーザがボタン４２６をタップするとき、トリプルストアの検索が開始可能である。（代替として、検索はより早く、すなわち、ユーザがボタン４２４をタップすることによって、第１の検索パラメータ（「トラック」）の入力を完了したとき、開始していてもよい。つまり、検索を、一連の連続する選別動作内で行うことができるので、ユーザが「結果を取得」ボタンをタップするとき、最終的なパラメータのみが、予め決定された暫定的な検索結果のセット内で検索されることが必要となる。）
【０５０８】
テーブル４００は、スマートフォンプロセッサがどのように、格納されたデータを検索して、ユーザの検索基準を満たす車両を識別するべきであるかを、指示する。
【０５０９】
例えば、ユーザが「トラック」を検索条件として選択したので、テーブル４００の行４３２は、この検索条件が、１２の述部コード（ＨａｓＶｅｈｉｂｌｅＴｙｐｅ（車両タイプである））、及び、１１５の目的部コード（トラック）に対応することを指示する。ＧＰＵは、これらの基準を満たすトリプルを求めて、メモリを検索する。
【０５１０】
このことが実装されうる１つの方法は、閾値処理−ＧＰＵコアが優れている演算−によるものである。つまり、メモリをフィルタリングして、１１よりも大きい、且つ、１３よりも小さい述部を有するトリプルを識別することができる。この最初の演算からの暫定結果−ＨａｓＶｅｈｉｃｌｅＴｙｐｅ述部を有するすべてのトリプルを含む−が、新しいフレームバッファにコピーされうる。（又は、この閾値テキストを満たさないトリプルを、｛０，０，０｝−画像処理では「黒」−に設定することができる。）
【０５１１】
上記で挙げた例では、さらなる処理のために、このステップによって複数のトリプルが識別されることがあり−典型的には、車両の各々につき１つのトリプル、例えば、｛１，１２，１１２｝−ホンダ（Ｈｏｎｄａ）ＣＲＸ、｛２，１２，１１５｝−フォード（Ｆｏｒｄ）レンジャー（Ｒａｎｇｅｒ）、｛３，１２，１１６｝−ウィネベーゴ、（トヨタ（Ｔｏｙｏｔａ）タコマ（Ｔａｃｏｍａ））、｛４，１２，１７｝−トヨタ・シエナ（Ｓｉｅｎｎａ）、その他である。
【０５１２】
第２の検索が次いで、（例えば、フレームバッファ内の）これらの暫定結果の全体で行われて−今回は、目的部コード１１５を有する（すなわち、「トラック」目的部についての）トリプルが識別される。１１５の目的部コードを有していないトリプルを、削除（又は、「黒」に設定）することができる。
【０５１３】
これらの２回の検索ステップの後に残るものは、（この例では）２つのトリプル、すなわち、｛２，１２，１１５｝及び｛５，１２，１１５｝である。主部＝２のトリプルは、フォード・レンジャーに対応し、主部＝５のトリプルは、トヨタ・タコマに対応する。検索の「トラック」部分は、これらの２つの主部コードの識別によって、完了されている。
【０５１４】
（前述の検索の段階を実装することができる別の方法は、対にされたテンプレートのセット−１つは、述部メモリプレーン内で１２のコードを探し、１つは、目的部メモリプレーン内で１１５のコードを探す−を用いた、テンプレートマッチングによるものである。ここでも、２つのトリプルが、それにより識別される。）
【０５１５】
スマートフォンは次に、第２の検索基準−４〜６人の乗客定員−を適用する。ソフトウェアは、テーブル４００の行４３４ａ及び４３４ｂ内で、この範囲が、２の述部コード（ＨａｓＰａｓｓｅｎｇｅｒＣａｐａｃｉｔｙ）、及び、５、６又は７の目的部コードに対応することを発見する。検索の第１の段階から、ソフトウェアは、主部コードが２又は５のいずれかに違いないことも知っている。これらの主部／述部／目的部条件を満たすデータが次いで、メイントリプルメモリ内のデータを調べることによって、又は、フレームバッファ内でデータのサブセット（すなわち、主部＝２又は主部＝５を有するすべてのトリプル）において演算することによって、（例えば、閾値処理演算によって）識別される。単一のトリプルが、すべてのこれらの基準を満たすことが発見され、すなわち、｛５，２，７｝である。これは、トヨタ・タコマトラックの６人の乗客定員を表現するトリプルである。
【０５１６】
この検索の第２の段階の結果から、スマートフォンは、ユーザのクエリにマッチする車両のための主部コード、すなわち、５を知る。（この例では１つのマッチがあるが、他の場合では、いくつかのマッチがありうる。）スマートフォンは次に、検索結果情報を、ユーザに提示するために準備する。この演算の結果レポート段階を、図３０を参照することによって例示する。
【０５１７】
どの主部コード（複数可）が、ユーザのクエリを満たす車両に対応するかを知り、スマートフォンはここで、メモリ内で５の主部コードを有するすべてのトリプルを識別する。複数のトリプルが発見され−そのうちのいくつかを図３０に示す（例えば、｛５，１，１７｝、｛５，２，７｝、｛５，３，５８｝、その他）。
【０５１８】
メイン主部テーブル、メイン述部テーブル、及びメイン目的部テーブル（上記のテーブルＩＶ、Ｖ及びＶＩ）が、それぞれの主部コード、述部コード、及び目的部コードに関連付けられた文字列又は他の値について調べられる。例えば、第１のトリプル、｛５，１，１７｝は、「２００７年式トヨタ・タコマ  ＨａｓＥｘｔｅｒｉｏｒＣｏｌｏｒ  白（２００７年式トヨタ・タコマは、白の外装色である）」を指示する。第２のトリプル、｛５，２，７｝は、「２００７年式トヨタ・タコマ  ＨａｓＰａｓｓｅｎｇｅｒＣａｐａｃｉｔｙ  ６（２００７年式トヨタ・タコマは、６人の乗客定員である）」を指示する。スマートフォンソフトウェアは、テンプレートフォームを満たし、テンプレートフォームは、異なるデータにプレインイングリッシュのタイトル（例えば、「ＨａｓＥｘｔｅｒｉｏｒＣｏｌｏｒ」の代わりに「Ｃｏｌｏｒ（色）」）でラベルを付けてもよく、スマートフォンソフトウェアは、リスト（例えば、上記の述部テーブルＶからのすべての使用可能なパラメータを含む）を、スマートフォン画面上でユーザに提示する。（電話は、あるパラメータに基づいて、異なるテンプレートを使用してもよく、例えば、トラックについて使用されるテンプレートは、車について使用されるテンプレートとは異なるものであってもよい。テンプレートは、必要に応じて、クラウドストレージから得られてもよく、又は、スマートフォンメモリ内に常駐してもよい。）
【０５１９】
述べたように、価格及び電話番号など、パラメータのいくつかは、メイン目的部テーブル内に格納されていないことがある。これらのパラメータは、「０」の目的部コードを有するトリプルによって指示される。そのようなトリプルからデータを提示するために、ソフトウェアは、述部に対応する補助テーブルを調べる（例えば、補助テーブル＃４は、ＨａｓＰｒｉｃｅ（価格である）値を提供する）。そのような補助テーブル情報を参照することによって、ソフトウェアは、トヨタ・タコマの価格が＄２４，５００であり、販売者の電話番号が５０３−５５５−１２３４であることを指示する情報を、フォームにポピュレートする。
【０５２０】
いくつかのパラメータは、トリプルとともにスマートフォン内にダウンロードされたデータにおいて指定されないことがあるが、代わりに、例えば、クラウド内の、リモートトリプルストアから（又は、グーグルのようなテキスト検索から）プルされることがある。例えば、ＥＰＡ燃費は、オンラインで容易に入手可能である政府統計値であり、他の車両情報を拡張するために得ることができる。
【０５２１】
そのようなユーザクエリの結果を提示する例示的画面は、１つ又は複数の写真（例えば、ＨａｓＬｉｎｋＦｏｒＭｏｒｅＩｎｆｏ（さらなる情報のリンクがある）述部によって指示されたＵＲＬから得られたもの）を、参照されたテンプレートフォームを使用して構成されたテキストとともに含んでもよい。そのようなテキストは、例えば、以下の通りになることがある。
「２００７年式トヨタ・タコマ、＄２４，５００、白（黄褐色の内装）で、５３，０００マイル。２．７リッターガソリンエンジンで、２１ｍｐｇのＥＰＡ燃料経済性。このトラックは、６人用の座席を特徴とし、３５００ポンドの牽引能力があります。５０３−５５５−１２３４にお電話下さい。」
【０５２２】
１つの画面表示につき単一の車両が詳述されてもよく、追加の車両は、タッチスクリーン表示を横切ってスワイプする動きによって表示されてもよい。そのような情報の提示についてのさらなる詳細は、例えば、米国特許出願第１３／０７９３２７号で見られる。
【０５２３】
他の実施形態では、４つ以上の８ビットデータプレーンを利用するトリプルストアを使用することができる。（いくつかの画像が４プレーン表現で格納され、例えば、シアン／マゼンタ／黄／黒、又はＲＧＢＡであり−但し、Ａはアルファ、すなわち透明度を表す。）一般に、「トリプル」の向上した形式と見なされるが、そのようなデータのセットはまた、「クワドラプル（ｑｕａｄｒｕｐｌｅ）」、又は、より一般には「Ｎ−タプル（Ｎ−ｔｕｐｌｅ）」（但し、Ｎ＝４）と呼ばれることもある。第４の８ビットデータプレーンは、様々な機能を可能にする。
【０５２４】
述べたように、価格は、メイン目的部テーブルによってコーディングするには不向きであり、その理由は、コーディングされる必要のある２５６個の異なる値があることがあり−他の情報を表すために使用可能な８ビットコードが残らないことがあるからである。しかし、２５６個の異なる価格を表す８ビットコードを、まばらにポピュレートされた第４の８ビットデータプレーンに格納することができる。
【０５２５】
図３１は、以前に説明した３つの８ビットプレーンを、価格のためのコードの格納専用の第４の８ビットプレーンとともに含む、例示的メモリの一部分を示す。このメモリは、実質的に、４×４ブロック−各々が異なる主部専用−に編成される。描かれた抜粋は、主部５（トヨタ・タコマトラック）に関連付けられたコードを詳述する。
【０５２６】
わかるように、述部コード４（すなわち、ＨａｓＰｒｉｃｅ）を有するトリプルは、その目的部コードで２５５を有する。この実装形態では、２５５のコードは、関連付けられたコードについてさらなる８ビットプレーン（述部コードによって指示されている特定のプレーン）を参照するように、ソフトウェアに命令する。この例では、関連付けられたコードは、２１８である。
【０５２７】
以前の例のように、テーブルは、異なる８ビットコードを異なる値に関連付けることができる。いくつかの実装形態では、価格コードを、ソートされた順序で、例えば、より小さいコードがより安い価格に対応するように、割り当てることが有利である。この８ビット価格コードメモリプレーンでは、サンプルのテーブルは以下の通りでありうる。
【表１２】
0006054870.tif 000013
【０５２８】
図３１及びこのテーブルを参照することによって、主部５に関連付けられた価格は＄２４，５００であると決定することができる。
【０５２９】
この構成の利点は、検索を容易にすることであり、その理由は、上記で詳述した技法−ＧＰＵの速度を、画像ストレージからの８ビット整数の処理に活用する−を利用できるからである。図２９Ｂのユーザインターフェースは、「価格はいくらですか？」と尋ねることができる。一対のウィンドウ４２２、４２２ａは次いで、メモリ内で詳述された車両の実際の価格の中でユーザがスクロールできるコントロールを提示し−最低価格及び最高価格を設定する。閾値処理、又は、他のそのようなＧＰＵ演算が次いで、価格メモリプレーン内の対応するコードに適用されて、指定された価格基準を満たす主部が迅速に識別される。
【０５３０】
複数のそのようなさらなる８ビットコードプレーンを、もうけることができる。（これらの８ビットコードプレーンは、ハードウェアがそのように構成される場合、第４の画像メモリプレーンに切り替えられてもよく、又は、他の場所で格納及びアクセスされうる。）図３１は、別のそのようなコードプレーン−エンジンサイズ（述部６に対応する）専用−を示す。ここでも、この８ビットプレーン内の対応するコードの格納は、検索クエリを迅速に実行可能にする。（ＧＰＵシェーダは典型的には、ＧＰＵシェーダが駆動する表示画面に同期される。アイフォン４電話の控えめなＧＰＵでも、毎秒約２５フレームでその６４０×９６０ピクセル表示画面をリフレッシュする。）
【０５３１】
いくつかの実装形態では、述部の大部分−又は、すべてさえも−は、図３１で価格及びエンジンサイズについて描かれたもののように、コードの格納のために８ビットメモリのそれら自体のプレーンを有してもよい。
【０５３２】
目的部コードを割り当てて、セマンティックな順序付けを表現することによって、検索が容易になることは理解されよう。このことは、乗客定員に関する前述の例から明らかであり、前述の例では、異なる数値が、関連付けられた８ビットコードの対応する優位により、昇順の方式で順序付けされる。これにより、上側コード及び下側コードを指定すること、及び、閾値処理演算を行うことによって、範囲ベースの検索が可能になる。
【０５３３】
同様の順序付けを、純粋に数ではないパラメータで実施することができる。例えば、色は、例えば、対応する波長最大値、及び／又は、強度若しくは輝度に基づいて、セマンティックな方法で順序付けされうる。したがって、青のすべて（ネイビーブルー、ロイヤルブルー、スカイブルー、アクアマリン色、その他）が同様のコードを有してもよく、すべての赤が同様のコードを有してもよく、青コード及び赤コードは、０〜２５５コード空間内で互いに離れて間隔があけられる。範囲ベースの色検索を次いで、容易に行うことができる。（例えば、ユーザは、図２９Ｂのウィンドウ４２２内で「ネイビーブルー」を選択し、ウィンドウ４２２ａ内で「アクアマリン色」を選択してもよく、これらの２つの範囲限界の色コード間のいかなる色コードを有する車両も識別される。）
【０５３４】
（色及び他の特徴を扱う別の方法は、ＲＤＦオントロジーを使用することによるものであり、ＲＤＦオントロジーは、項目をセマンティックにグループ化し、関連付ける。例えば、無数の異なる車メーカー色名を、以下のものなど、オントロジーによって検索可能パラメータに抜き出すことができる。
・ＡＱＵＡ  ＭＥＴＡＬＬＩＣ  ＨａｓＣｏｌｏｒ  ＢＬＵＥ（アクアメタリックは青の色である）
・ＤＥＥＰ  ＮＡＶＹ  ＨａｓＣｏｌｏｒ  ＢＬＵＥ（ディープネイビーは青の色である）
・ＤＥＥＰ  ＣＡＲＤＩＮＡＬ  ＨａｓＣｏｌｏｒ  ＲＥＤ（ディープカーディナルは赤の色である）
・ＣＲＹＳＴＡＬ  ＲＥＤ  ＨａｓＣｏｌｏｒ  ＲＥＤ（クリスタルレッドは赤の色である）
・ＣＨＡＲＣＯＡＬ  ＨａｓＣｏｌｏｒ  ＧＲＥＹ（チャコールはグレーの色である）
・ＧＲＡＮＩＴＥ  ＨａｓＣｏｌｏｒ  ＧＲＥＹ（グラニットはグレーの色である）
スマートフォンは、これらのトリプルを逆にして、結果として生じる主部（例えば、ＢＬＵＥ、ＲＥＤ、その他）を、図２９Ｂのウィンドウ４２２及び４２２ａ内など、ＧＵＩで提示することができる。この場合、ウィンドウ４２２及び４２２ａ内で選択された２つの値は、パラメータの範囲を定義しないが、むしろ、検索においてともに論理和が取られる２つの異なる値を定義するので、いずれかの値を満たすトリプルが選択されるようになる。）
【０５３５】
前述の例は、やや初歩的であるが、関係する原理を例示する役目を果たす。より複雑なセマンティックな推論を、当然実装することができる。例えば、電話が自動車の分類広告の画像を取り込む場合、電話は、ユーザにクエリを行って、ユーザが１年で運転するマイル数など、いくつかの事実を学習してもよい。（この情報は、ネットワーク化されたコンピュータ上に格納されたユーザプロファイル内、又は、ユーザの現在の車内のデータベース内など、他の場所で入手可能でありうる。）ユーザが、５０，０００マイルが典型的な年間走行距離であると指示することによって、このクエリに応答する場合、電話は、セマンティックな推論を採用して、１マイル当たりの車両運用コストがユーザにとって重要である可能性が高いことを見極めてもよい。この推測された情報により、電話は、ユーザにより指図された車両検索の結果を、（ユーザからの他の命令なしに）検索結果の中で最高の燃料経済性を有する車両を最初に提示することによって、レンダリングするように決定してもよい。
【０５３６】
ＥＰＡ燃費が、検索結果内の車両について入手可能でない場合、電話は、他のデータを使用して推論することができる。例えば、セマンティックな推論を使用して、１３００ｃｃエンジンによるエンジンが、４．７リッターエンジンによるエンジンよりも良い燃料経済性を有する可能性が高いと、結論付けることができる。同様に、そのような推論、又は、ネットワーク化された知識ベースは、ディーゼルエンジンがガソリンエンジンよりも良い燃料経済性を有する傾向があることを、指示してもよい。ここでも、そのような知識は、−単に、ユーザが年間５０，０００マイル運転するという事実に基づいて−検索結果の提示に情報を与えることができる。
【０５３７】
前述の技法を特にスマートフォン実装形態との関連で説明しているが、原理は、より幅広く適用可能である。また、ＧＰＵコアの使用が好ましいが、詳述した機能は、他のタイプのプロセッサで処理されるメモリ内で同様に適用可能である。
同期化されたバックグラウンド
【０５３８】
拡張現実の技法は、画像特徴を認識し、ラベルなどの情報をオーバーレイするために知られている。重ね合わせられたオーバーレイは、画像特徴（複数可）とともに幾何学的に登録されうるので、画像特徴が視野内で動くにつれて、オーバーレイが対応する動きで動くようになる。
【０５３９】
本技術の別の態様は、オーバーレイではなく、バックグラウンドの形態の拡張を提供することによって、そのような技法に基づいて前進する。
【０５４０】
前景で被写体を描く画像、及び、周囲のバックグラウンドを考えられたい。例示的画像は、ビートルズ（Ｂｅａｔｌｅｓ）のアビー・ロード（Ａｂｂｅｙ  Ｒｏａｄ）レコードアルバムであり、アビー・ロードの横断歩道を歩いて渡るビートルズの４人を描くものである。
【０５４１】
フォトショップ、ＧＩＭＰ、又は別のツールを使用して、ビートルズの４人が画像から抜粋されうる。２つの画像をそれにより形成することができ−ビートルズの４人のみ（周囲に何もないか、又は均等色−白など−によって囲まれている）の第１の画像、及び、バックグラウンドのみ（ビートルズがいたところに何もなくてもよく（又は、そこが白であってもよく）、そうでなくてもよい）の第２の画像である。
【０５４２】
第１の画像は、基層（ｓｕｂｓｔｒａｔｅ）上にプリントされてもよく、スマートフォンが使用されて、例えば、ビデオ取り込みモードで基層の画像が取り込まれる。スマートフォン内のソフトウェアは、第１の画像に対するカメラの姿勢を決定する。この情報により、ソフトウェアは、第２の（バックグラウンド）画像を幾何学的にワープさせるので、第２の（バックグラウンド）画像が、同じ姿勢から見られるかのような、スケール及び視点を有するようになる。電話が次いで、２つの画像−電話により取り込まれたビートルズの４人の画像、及び、バックグラウンド−画像の元の背景をもたらすようにワープされたもの−を合成する。２つの画像は、互いを補完して、基層に対する電話の姿勢から見られるかのような、元のアルバムカバーのように見える統合された画像を提示する。
【０５４３】
他のバックグラウンド画像が、元の画像の代わりに使用されてもよい。したがって、アビー・ロードの画像の代わりに、バックグラウンド画像は、ニューヨークのタイムズ・スクエアのブロードウェイを描いてもよい。抜粋されたビートルズ−プリントされた基層から（又は、電子表示画面から）撮像された−を、新しいバックグラウンド画像−やはり、基層に対するカメラと同じ姿勢で見えるようにワープ及びスケールされる−の上に重ね合わせることができる。したがって、この拡張は、従来の拡張現実オーバーレイよりもむしろ、よりアンダーレイに類似している。
【０５４４】
バックグラウンド画像を、基層−カメラ姿勢にマッチするように幾何学的にワープ及び登録することは、デジタルウォーターマーク、顕著な画像点、その他を使用するなど、様々な方法で行われうる。第１の画像が、ＱＲコード又は他のバーコードを有する場合、そのような特徴自体を使用して、姿勢情報を見極めることができる。そのような技法を、本開示の他のところでさらに詳述している。
【０５４５】
第１の画像に対する電話の姿勢が見極められると、第２の（バックグラウンド）画像を、姿勢の変化に基づいて修正して−３Ｄ効果を与えることができる。例えば、ユーザがカメラをパンする場合、追加のバックグラウンドの風景がフレームに入ることがある。ユーザがカメラを軽くさわって、より下方に向ける場合、街路の画像のより多くが視野に入ることが可能である（そして、一部の空の画像がフレームの上部から消えていく）。カメラの姿勢が変化するにつれて、第２の画像内に描かれたより近い特徴の変更された視点によって、第２の画像のある特徴が遮られるようになる−又は、現れるようになる。いくつかのそのような実施形態は、３Ｄモデルを採用して、バックグラウンド画像を生成する−電話の観点に基づいて、適切な２Ｄビューを計算する。
【０５４６】
例示的実施形態は、被写体の描写の周囲に何もないか、又は被写体の描写が均等色で囲まれた、第１の画像を使用したが、他の実施形態では、このことは必要ではない。被写体のアイデンティティが（例えば、フィンガープリンティング、マシン可読符号化、その他によって）わかると、そのような被写体の輪郭を、データベースを参照することによって決定することができる。カメラは次いで、第２の画像を第１の画像の周りにステッチし−画像の主要な被写体（例えば、ビートルズの４人）の、データベースにより定義された輪郭の外側にある、第１の画像の部分をふさぐことができる。
【０５４７】
ユーザが表示画面をタップする場合、電話のソフトウェアは、タップのロケーションに適した応答を提供することが望ましい。ユーザがジョン・レノン（Ｊｏｈｎ  Ｌｅｎｎｏｎ）をタップする場合、ジョン・レノンに関係付けられたコンテンツが提示される。そのようなタップは、タップされた表示の部分が、電話のカメラによって実際に取り込まれた画像を描くかどうか、又は、電話によって拡張として置かれた他の画像を描くかどうかにかかわらず、この振る舞いを呼び出す。（電話のソフトウェアは、ユーザのタップのＸロケーション及びＹロケーションを出力し、Ｘロケーション及びＹロケーションが次いで、表示された画像内の特にロケーションにマップされる。提示された画像の表示内のそのようなロケーションに対応するコンテンツを次いで、知られている方法によって決定することができ、知られている方法は、タップ座標でデータベースにインデックス付けすることによる、その領域のウォーターマークを復号することによる、その他などである。）
モバイルデバイスへの表示のリンク付け
【０５４８】
本技術のこの態様によれば、ウォーターマークが、ＬＣＤモニタなど、表示デバイス上で提示されることになる画像／コンテンツ／広告／ビデオ／ユーザインターフェース（例えば、ウェブページ）に埋め込まれる。埋め込みは、表示デバイスによって、関連付けられたコンピュータによって、又は、画像のリモートソースによって行うことができる。ウォーターマークは、スマートフォン又は他のモバイルデバイス内に存在する検出器で読み取り可能である。ウォーターマークからのペイロードは、テーブル又は他のデータ構造を通して、提示された表示に対応する情報のソースに論理的にリンクする。（ウェブページでは、情報は、ページのＵＲＬアドレスでありうる。）他の技法に勝る利点には、リアルエステート（ｒｅａｌ  ｅｓｔａｔｅ）の節約（画面上に表示された画像では、ウォーターマークがいかなる追加の空間も占有しない）、埋め込みコスト（印刷されたバーコードよりも安価）、全デジタルワークフロー、隠された特徴（必要とされる場合）、表示されたコンテンツとモバイルデバイスの間の通信チャネルが含まれる。応用例は多数であり−いくつかの例を以下で詳述する。
【０５４９】
１つの応用例は、地図作成に関する。ユーザが、マップクエスト（ＭａｐＱｕｅｓｔ）、ヤフーマップ（Ｙａｈｏｏ  Ｍａｐｓ）、又はグーグルマップ（Ｍａｐｓ）など、地図作成ツールを使用することによって、デスクトップ／ラップトップ上で道案内を探していると仮定する。所望の地図／道案内が画面表示（ウォーターマーキングされている）上に提示された後、ユーザは、モバイル電話を、画面上に表示された地図／道案内に向ける。符号化されたウォーターマークを読み取ると、電話は、表示された道案内のためのＵＲＬを得で、同じページを（ＷｉＦｉインターネット接続を使用するか、又は、ＧＰＲＳなどの通信リンクを通して）ロードする。その時点で、ユーザは、モバイル電話で直接、地図／道案内を持って、出かける用意ができている。
【０５５０】
モバイル電話がＧＰＳ能力を有する場合、ウォーターマークを読み取ると、スマートフォンは、すべてのロケーション／住所情報を手入力する必要なしに、地図／道案内をＧＰＳ機能性に直接リンクさせることができる。
【０５５１】
モバイル電話がＧＰＳ能力を有していないが、ユーザがＧＰＳを装備したデバイスを自分の車内に有する場合、ウォーターマーキングされたデスクトップ画面表示から電話によって復号されたペイロード情報を、ワイヤレス（例えば、ブルートゥース）接続を使用してＧＰＳデバイスに転送することができる。
【０５５２】
別の応用例は、電子商取引を容易にすることに関する。ある人が、自分のデスクトップ／ラップトップ上で靴の広告を見ており、この広告がウォーターマーキングされていると仮定する。モバイル電話を広告に向けることで、その人を、モバイル電話上に表示された「チェックアウト」ページに直接連れていくことが可能である。
【０５５３】
別の応用例は、画像の同期に関する。ユーザは、デスクトップ画面上に表示された特定の画像を気に入り、自分のスマートフォン上にほしくなることがある。このことは、電話を使用して、単に画面表示の画像を取り込むことによって達成されうる。電話は、ウォーターマークを復号し、それにより抽出されたペイロードを使用して、画像のコピーをその元のロケーションから得る。
【０５５４】
関連して、予定表の同期は、デスクトップ表示上の予定表プログラム（例えば、マイクロソフトアウトルック（Ｏｕｔｌｏｏｋ））から画像を取り込むことによって達成されうる。電話は、ウォーターマークペイロードを復号し、この情報を参照することによって、ローカルの予定表を表示されたアウトルック予定表と同期させるためのデータを得る。
【０５５５】
別の応用例は、ビジュアルブックマークである。ユーザが、デスクトップ／ラップトップ上でウェブページを見ており、（例えば、通勤帰りに）モバイル電話上でさらに閲覧するためにそのページをブックマークすることを望むと仮定する。ウェブページがウォーターマークを有する場合、ユーザは、単に電話をそのページに向けることができ、そのページ（又は、その対応するモバイルバージョン）のためのブックマークが、自動的にモバイル電話上に現れるようになる。
【０５５６】
さらに別の応用例は、アクティブリンクに関する。静的であるウェブページ上のリンク（ユーザが、興味深いことを起こすために、リンクをクリックするなどのアクションを取らなければならないということである）とは反対に、ウォーターマークは、「アクティブリンク」を容易にすることができる。つまり、モバイルデバイスをウェブページ（又は、他の関連のある表示）に向けて、ウォーターマークを読み取るだけで、アクションを−モバイルデバイス上、又は、（ワイヤレスリンクを通して）ディスプレイに接続されたコンピュータ上のいずれかで−自動的にトリガする。
【０５５７】
前述の概念をビデオに拡張して、モバイルデバイスを表示画面上のビデオストリーミングに向けることによって、動的に変化するウォーターマークを読み取ることを可能にすることができる。
【０５５８】
前述の構成のうち特定のものを実装する際に有用な追加の情報は、Ｍｏｄｒｏ他、Ｄｉｇｉｔａｌ  Ｗａｔｅｒｍａｒｋｉｎｇ  Ｏｐｐｏｒｔｕｎｉｔｉｅｓ  Ｅｎａｂｌｅｄ  ｂｙ  Ｍｏｂｉｌｅ  Ｍｅｄｉａ  Ｐｒｏｌｉｆｅｒａｔｉｏｎ、Ｐｒｏｃ．  ＳＰＩＥ、Ｖｏｌ  ７２５４、２００９年１月の論文で見られる。
デバイス間のタスクの移行
【０５５９】
本譲受人の米国特許出願公開第２０１０／０２０５６２８号は、ユーザがゲーム／コンテンツの流れにおける立場を失うことなく、ゲーム又はエンターテインメントコンテンツを、あるコンピュータシステム（例えば、デスクトップコンピュータ）から別のコンピュータシステム（例えば、スマートフォン）へ転送可能であることの望ましさに言及している。そのような構成によって、ユーザは、デバイスを切り替えるにもかかわらず、アクティビティをシームレスに継続することができる。
【０５６０】
本技術の別の態様によれば、コンピュータの画面上に提示された表示データは、アプリ状態可変（ａｐｐ−ｓｔａｔｅ−ｖａｒｉａｎｔ）ペイロードによりルーチン的にデジタルウォーターマーキングされる。つまり、コンピュータ内の表示ドライバ又は他のモジュールは、表示されたデータを定期的に、マルチビット識別子によりステガノグラフィ的に符号化する。この識別子は、時折変更される（例えば、フレームごとに、又は１〜１０秒ごとに、又は不規則な間隔で−閾値量の変化がプログラム若しくはコンピュータ状態で起こったときなど）。識別子が変更されるたびに、コンピュータは、コンピュータシステムの、又は、画面上に表示されているプログラムの、「完全な状態」を回復可能にするデータを書き込む。この情報が書き込まれるデータストアは、いくつかのエントリを含むことができ−基本データ状態を提供するもの、及び、連続する更新を提供する他のものである（ビデオフレームが、単に前のフレームとの差分を詳述するデータにより時々符号化される方法に類似している）。データベース（ルックアップテーブルと同じくらい簡単でありうる）は、格納されたデータのどの部分が、各ウォーターマークペイロードに対応するデバイス状態を再現するために必要とされるかを、識別する。
【０５６１】
図３７は、そのような構成をさらに詳述する。最初に縦軸を参照すると、時折の間隔で、第１のコンピュータ（例えば、デスクトップコンピュータ）が状態データをメモリに格納する。この状態データは、コンピュータの状態（又は、表示されているプログラムの状態）を異なるデバイス上で再現するために十分であることが望ましい。そのような状態データが格納されるたびに、新しいウォーターマークＩＤが割り当てられ（２２３、２２４、その他）、画面表示がその後、この識別子により符号化される。対応する更新が、ウォーターマークルックアップテーブルに対して行われる。
【０５６２】
格納された状態データは一般に、可変長である（図３７では、長方形の長さによって指示される）。時折、大きいデータのブロックが書き込まれるようになる（図３７の「基本データ」）。格納されたデータの後続のブロックは単に、基本データの差分更新でありうる。さらなる間隔の後、別の新しい、大きい基本データブロックが書き込まれることがある（例えば、「基本データ３８」）。
【０５６３】
格納された状態データは、この例では、線形メモリに連続アドレス（図３７の横軸に対応する）で書き込まれる。「基本データ３７」は、メモリアドレス１００４で開始して格納され、１０１２まで継続する。第１の更新である「３７Ａ」は、アドレス１０１３で開始して格納され、１０１６まで継続する。同様に、第２の更新である「３７Ｂ」は、アドレス１０１７で開始して格納され、１０２３まで継続する。これは、第３の更新「３７Ｃ」で継続する。次いで、基本データの新しいブロック（「基本データ３８」）が書き込まれる。
【０５６４】
消費者がスマートフォンを使用して、ウォーターマーク２２３が符号化されている表示画面の画像を取る場合、消費者のスマートフォンは、ウォーターマークを復号し、ウォーターマークを、対応する状態データが格納されているアドレス情報を提供するデータ構造（ローカル又はリモート）に入力する。図示の例では、データ構造は、メモリ範囲１００４〜１０１２を返す。（図３８は、そのようなウォーターマークルックアップテーブルを示す。）スマートフォンは、この範囲のデータを取得して使用し、異なるデバイス上にもかかわらず、実行中のプログラムを、ウォーターマーク２２３が最初に符号化されたときに存在した通りに再現する。
【０５６５】
消費者が、ウォーターマーク２２４が符号化されている表示画面の画像を取る場合、図３８のテーブルは、対応する基本データ（「基本データ３７」）を包含し、また差分更新「３７Ａ」をも含むように広がる、メモリ範囲を返す。このようにして、図３８のテーブルは、メモリアドレス範囲１００４〜１０１６を返す。ここでも、消費者のスマートフォンは、この情報を使用して、ウォーターマーク２２４が最初に符号化されたときにデスクトップコンピュータ上に存在した実行状態を−スマートフォン上で−再現することができる。
【０５６６】
図３７の下部は、−図３８のウォーターマークルックアップテーブル内で−異なるウォーターマークペイロードの各々に関連付けられた異なるメモリ範囲を、グラフィカルに示す。
【０５６７】
機能的に同様の構成は、実装がより複雑であるが、Ｃｈａｎｇ他、Ｄｅｅｐ  Ｓｈｏｔ：Ａ  Ｆｒａｍｅｗｏｒｋ  ｆｏｒ  Ｍｉｇｒａｔｉｎｇ  Ｔａｓｋｓ  Ａｃｒｏｓｓ  Ｄｅｖｉｃｅｓ  Ｕｓｉｎｇ  Ｍｏｂｉｌｅ  Ｐｈｏｎｅ  Ｃａｍｅｒａｓ，  Ｐｒｏｃｅｅｄｉｎｇｓ  ｏｆ  ｔｈｅ  ２０１１  ＡＣＭ  Ｃｏｎｆｅｒｅｎｃｅ  ｏｎ  Ｈｕｍａｎ  Ｆａｃｔｏｒｓ  ｉｎ  Ｃｏｍｐｕｔｉｎｇ  Ｓｙｓｔｅｍｓ（ＣＨＩ  ２０１１年）、２１６３〜２１７２ページに詳述されている。出願人の今説明した技術を、Ｃｈａｎｇシステムに有利に組み込むことができ、Ｃｈａｎｇシステムの教示を、今説明した構成において同様に採用することができる。
ＬＥＤ照明
【０５６８】
ＬＥＤオフィス照明は、デスクトップコンピュータに取り付けられた光モデムと通信する、データ信号のための光キャリア−光ＤＳＬネットワークに類似している−として使用されつつある。（例えば、米国特許出願公開第２００９／０１２９７８２号、及び、ＬＶＸシステム（ＬＶＸ  Ｓｙｓｔｅｍ，Ｉｎｃ．）による市版品を参照。）
【０５６９】
ＮＸＰセミコンダクター（ＮＸＰ  Ｓｅｍｉｃｏｎｄｕｃｔｏｒ）による照明のグリーンチップ（Ｇｒｅｅｎｃｈｉｐ）ラインは、統合されたＩＰ６接続性を有する、ＬＥＤライト（「ＳＳＬ」−ソリッドステートライト（ｓｏｌｉｄ  ｓｔａｔｅ  ｌｉｇｈｔｓ）と呼ばれることがある）を含む。つまり、あらゆるライトが、それ自体のインターネットアドレスを有する。「ＪｅｎＮｅｔ」−ＩＰネットワークソフトウェアは、ＬＥＤデバイスのためのワイヤレス接続性を提供する。ＪｅｎＮｅｔは、ＩＥＥＥ  ８０２．１５．４ベースのネットワーキングを採用する、６ＬｏＷＰＡＮメッシュアンダーツリーネットワーク（ｍｅｓｈ−ｕｎｄｅｒ  ｔｒｅｅ  ｎｅｔｗｏｒｋ）である。これらなどの構成を通して、ＬＥＤの動作パラメータを、配線網の全域で送信されるＩＰ６データに基づいて変更することができる。
【０５７０】
本技術のさらなる態様によれば、ＬＥＤ照明は、スマートフォン、及び、他のカメラを装備したデバイスと通信することができる。照明の輝度又はクロミナンスが、人間が知覚不可能な度合いで変化させられて、追加のデータが搬送される。これらの微妙な変化は、スマートフォンカメラによって取り込まれた画像に反映される。スマートフォンプロセッサによって実行されたウォーターマーク復号処理は次いで、カメラデータから、符号化された情報を抽出する。
【０５７１】
光モデムとは異なり、スマートフォンカメラは、取り込み画像フレームを毎秒１００フレーム未満（より典型的には、１０〜３０ｆｐｓ）で提供する。しかし、小さいが、このデータレートは、それにもかかわらず、有用な情報を搬送することができる。照明が、一般のスマートフォンによって検知された異なる色チャネル−赤、緑、及び青−のうち２つ以上で変調される場合、多少より高いデータレートを達成することができる。
【０５７２】
いくつかの応用例では、−色の変調にもかかわらず−一定の輝度を維持することが望ましいことがある。このことは、データを搬送するために色チャネルのうち２つを変調すること、及び、他の色による輝度変化を補償するために、必要に応じて第３のチャネルを変調し、一定の最終的な輝度を生じることによって、達成されうる。光の異なる波長に対する目の異なる感度のために、輝度は、緑の量に最も依存し、青の量に最も依存しない（Ｙ＝．５９Ｇ＋．３０Ｒ＋．１１Ｂ）。例示的実施形態は、赤及び青を変化させて、データを搬送し、輝度補償のために緑を変化させてもよい。
【０５７３】
他の応用例では、−輝度の変調にもかかわらず−一定の色相を維持することが望ましいことがある。やはり、このことは、駆動信号の適切な制御によって達成されうる。
【０５７４】
知られているデジタルウォーターマーキングシステム（例えば、６，５９０，９９６）の場合と同様に、ウォーターマークデータペイロードを、ＢＣＨ（「トレリス」）又は畳み込みコーディングなど、エラー訂正コードを使用して表して、データエラーに対するロバスト性をもたらすことができる。結果として生じる、時間的に変化する輝度又はクロミナンス変化を、（ＬＥＤが高速データで変調されるかどうかにかかわらず）既存のＬＥＤ制御信号に適用して、最も近いカメラセンサへのブロードキャストを実施することができる。
【０５７５】
通常、カメラは、画像の単一のフレームからデジタルウォーターマークデータの複数のビットを復号し、例えば、画像の異なる空間部分（例えば、ピクセル）間の輝度又はクロミナンスのわずかな差異を検出する。対照的に、本出願は、フレームのシーケンスからデジタルウォーターマークデータの複数のビットを復号し、経時的に輝度又はクロミナンスのわずかな差異を検出する。単一のフレーム内で、取り込まれた画像のすべての部分は、ＬＥＤ照明信号によって同様に影響を受けることがある。したがって、ウォーターマークを、単一のピクセルから、又は複数のピクセルから、又はピクセルのすべてから、出力された信号から復号することができる。後者の場合、例えば、復号アプリケーションは、カメラピクセルのすべてにわたって輝度及び／又はクロミナンスを合計又は平均し、この集計された信号を、ウォーターマーク符号化によって引き起こされた変化について解析することができる。
【０５７６】
そのような技術の１つの特定の応用例は、小売店内でロケーションを信号伝達することである。靴セクションのＬＥＤ電球器具は、ある特定の識別子により符号化されてもよく、紳士服セクションのＬＥＤ電球器具は、異なる識別子により符号化されてもよい。周囲の照明を簡単にサンプリングすることによって、電話は、店内のそのロケーションを決定することができる。
【０５７７】
別の応用例は、周囲のメディア環境からデータを検知し、検知された環境に基づいて情報を抽出するために、マイクロフォン又はカメラが装備されたＬＥＤ照明器具である。（このことは、オーディオウォーターマークを検出すること、又は、オーディオフィンガープリントデータを生成し、それに基づいて曲を認識すること、又は、取り込まれた画像から人の顔を認識すること、その他を含みうる。）この抽出された情報に関係付けられたデータは次いで、照明器具から発せられた光において符号化される。
【０５７８】
またさらに、ＬＥＤ自動車ヘッドライトを変調して、自動車の速度及びコンパス方位など、自動車の動作のパラメータを−接近する車両へ−搬送することができる。（そのような信号は、ユーザのスマートフォンではなく、車に組み込まれた光センサシステムを使用して復号されることが好ましい。そのようなセンサシステムは、スマートフォンカメラで可能であるよりも高い帯域幅でデータを取り込むように構成されうる。例えば、ヘッドランプは、１０００又は１０，０００ビット／秒のデータレートで符号化可能であり、センサシステムは、そのようなレートを復号するように構成されうる。）
【０５７９】
関連して、勤務先又は居住地の住所の屋外照明（例えば、正面玄関のライト）を変調して、番地を符号化することができる。
【０５８０】
そのような情報が得られると、ユーザ（又は、ユーザのデバイス）は、そのような情報に関してアクションを起こすことができる。例えば、小売りの例では、電話は、店内の別のロケーションへの道案内をユーザに与えることができ、又は、近くの商品のクーポンを提示することができる。車の例では、電話は、接近する車両が制限速度（又は、ユーザ自身の速度）を１０パーセントよりも多く超えた速度で走行中である場合、警告を信号伝達することができる。屋外照明の場合では、番地をユーザの電話に提示することができ、又は、そのロケーションの勤務先／居住者の名前を公的データベースから調べることができる。
【０５８１】
汎用ＬＥＤ照明以外の光源を、今説明した方法で制御できることは理解されよう。例えば、テレビ及びラップトップ照明を、この方式で変調することができる。クロミナンス変調は、色が重要なテレビシーン（例えば、肌の色合いを描くもの）には適さないことがあるが、他の情報表示は、クロミナンス変化に寛容である（例えば、デスクトップの色、ウェブページのバックグラウンド、その他）。
【０５８２】
図３８は、輝度ＬＥＤ変調を採用する例示的実施形態を示す。照明器具を搭載したデバイス３２０は、１つ又は複数のＬＥＤ３２２、直流電源３２４、及び、変調構成３２６を含む。描かれた構成はまた、ＪｅｎＮｅｔ  ＩＰ６リモート制御システム（論理ブロック３２７、及び、関連付けられた変調器３２９を含む）をも含むが、これは必須ではない。
【０５８３】
電源３２４は、従来のものであり、器具の交流電力（例えば、１２０ボルト）を、ＬＥＤ（複数可）３２２に適した直流電圧に変換する。（特に図示しないが、同じ電源は、必要とされる電圧（複数可）を変調構成３２６及びＪｅｎＮｅｔシステム３２７に供給することができる。）変調構成３２６は、例えば、無線又はオーディオ信号によってデバイスへ搬送され、アンテナ３２８又はマイクロフォン３３０によって検知された、入力データ信号３３３を受信する、データ受信機３３２を含む。データ受信機は、適切な復号（例えば、オーディオ信号の場合、ウォーターマーク抽出処理）を実現して、バイナリ出力データを供給する。このデータは、畳み込み符号器３３４に入力され、畳み込み符号器３３４は、出力信号を変調器３３６に供給し、変調器３３６は、ＬＥＤ（複数可）３２２に印加された直流信号を、それに応じて変化させる。（変調器３２９、３３６は、加算器として描かれるが、乗算器又は他の構成が代替として使用されうる。）
【０５８４】
実際の実施では、システム３２０は典型的には、赤色／緑色／青色／白色ＬＥＤ光源を採用し、ＬＥＤ光源は、１ＫＨｚ〜３０ＫＨｚの周波数の三刺激（ｔｒｉ−ｓｔｉｍｕｌｕｓ）パルス幅変調（ＰＷＭ）制御信号により駆動される。そのような構成では、駆動パルスの持続時間は、データ信号３３３のステガノグラフィ的符号化を実施するために、長くされ、及び／又は、短くされる。（典型的には、パルス長の変更は、２５％未満であり、１０％、５％又は２％未満でありうる。より大きい変更は、例えば、畳み込み符号器からの「１」及び「０」の出力に対応して、正の変更と負の変更がともに行われる場合、許容可能であり、その理由は、それらの時間平均が典型的にはゼロであるからである。）特定の変調率は、対象となっている応用例によって決まり、簡単な実験法によって決定されうる。（例えば、所与の畳み込み符号器では、望まれていない視覚効果が最も厳しい照明条件−夜間など−でちょうど現れ始めるまで、ＰＷＭ駆動信号への率の変更を増し、次いで、これらの効果が知覚不可能になるまで、率の変更を低減する。）
【０５８５】
変形実施形態では、図３２のデータ受信機３３２が、ＧＰＳ受信機、又は、他のロケーション検知モジュールで置き換えられる。（ＧＰＳよりも正確な技術は、特許７８７６２６６及び７，９８３，１８５、及び、特許公報２００９３１３３７０、２００９２３３６２１、及び２００９２１３８２８で教示されている。）。そのような構成では、光源は、ジオロケーションデータにより符号化された照明を発する。
【０５８６】
別の構成では、システム３２０は、データ受信機３３２を採用しないが、代わりに、（例えば、ＲＯＭ又はディップスイッチ構成によって設定されうる）固定の複数ビットデータペイロードによりハードコードされる。そのようなペイロードは、システムのための一意の識別子としての役目を果たすことができる。受信側のスマートフォンがそのようなシステムからの照明を検知し、複数ビット識別子を復号するとき、この電話は、識別子をリモートデータベースへ（例えば、インターネットを介して）送信することができ、リモートデータベースは、電話の使用のために、関連付けられた情報（例えば、住居番号、店の売り場名、その他）を返す。
【０５８７】
さらに別の構成では、ステガノグラフィ的に（つまり、スマートフォンによって検知可能なビットレートで）搬送されるべきデータが、電力線を介して搬送される。このことは、ＰＤＳＬ又はＢＰＬなど、知られている電力線通信（ＰＬＣ）技術を使用して行われうる。代替として、デバイスのグリーンチップラインによって採用された技術を使用することができる。
【０５８８】
スマートフォンがＬＥＤベースの光通信信号の受信機としての役目を果たすことができることと全く同じように、スマートフォンは、そのような信号の送信機としての役目を同様に果たすことができる。大部分のスマートフォン（及び、多数のより低能力の「フィーチャー」フォン）は、カメラにより取り込まれるシーンを照明するためにＬＥＤ「トーチ」を含む。そのようなＬＥＤを、上記で詳述した構成を使用して変調して、データを電話から光学的に搬送することができる。ブルートゥース及び他の短距離通信技術とは異なり、そのようなＬＥＤ通信は、ある程度のプライバシーを与え、その理由は、明確なサイトのラインが典型的には必要とされるからである。
【０５８９】
１つの特定の実施形態では、受信側のシステム（例えば、別のスマートフォン）は、応答データでＬＥＤ信号に応答する。このデータ応答は、受信された光信号の強度（例えば、信号対雑音のメトリックに対応する数）を指示する情報を含みうる。発信側の電話は次いで、そのＬＥＤ駆動電力を低減して、適度であるが過度ではない受信信号強度を第２のデバイスで供給するようにすることができる。節電に加えて、この方式でのＬＥＤ駆動電流のそのような低減は、意図されていない受光機の盗聴のための能力をさらに削減する。（発信側のスマートフォンに返信されるこの応答データは、ワイヤレスで、光学的に、又は他の方法で搬送されうる。）
総括
【０５９０】
総括するため、本明細書で詳述した新規の構成のいくつかを、以下のように要約することができる。
【０５９１】
デバイス内で、コンテンツ（例えば、オーディオコンテンツ）を表すデータを受信するステップを含む方法。アルゴリズムが、受信されたデータに適用されて、識別データが導出される。導出された識別データを参照することによって、特定のソフトウェアプログラムが、コンテンツとともに使用するために選択される。この選択するステップが、そのような行為を行うように構成される、デバイス内のプロセッサによって行われる。選択されたソフトウェアプログラムが次いで、起動される。この構成によって、データとともに使用される特定のソフトウェアプログラムの選択が、データ自体から導出された識別データに基づく。
【０５９２】
さらなる方法は、やはり、デバイス内で、コンテンツ（例えば、オーディオコンテンツ）を表すデータを受信するステップと、アルゴリズムを受信されたデータに適用して、識別データを導出するステップとを含む。導出された識別データを参照することによって、コンテンツとともに使用するために有利なソフトウェアプログラムが、選択される。この選択するステップが、そのような行為を行うように構成される、デバイス内のプロセッサによって行われる。有利なソフトウェアプログラムが次いで、ユーザに指示される。この構成によって、データとともに使用される有利なソフトウェアプログラムが、データ自体から導出された識別データに基づいて選択される。
【０５９３】
さらに別の方法は、デバイス内で、コンテンツ（例えば、オーディオコンテンツ）を表すデータを受信するステップを含む。このコンテンツは、デバイス内の第１のソフトウェアによってレンダリングされうるタイプのものである。コンテンツをこの第１のソフトウェアによりレンダリングするための試みに応答して、デバイスが、第２のソフトウェアが代わりに使用されるべきであることを指示する。この場合、コンテンツの創作者が、その創作者のコンテンツのために、第２のソフトウェアを好ましいものとして指定した。
【０５９４】
さらに別の方法は、デバイスのマイクロフォンにより、周囲環境からオーディオを受信するステップを含む。アルゴリズムが、受信されたオーディオを表すオーディオデータに適用されて、識別データが導出される。導出された識別データを参照することによって、オーディオに関係する商取引のために使用されるべき、対応するフルフィルメントサービスが選択される。この構成によって、第１の受信されたオーディオが、第１のオーディオに関係する商取引のために使用されるべき第１のフルフィルメントサービスの選択につながり、第２の異なる受信されたオーディオが、第２のオーディオに関係する商取引のために使用されるべき第２の異なるフルフィルメントサービスの選択につながる。
【０５９５】
さらなる方法は、ユーザの周囲環境内のコンテンツ（例えば、オーディオ）を識別するステップを含み、コンテンツが、ユーザデバイスによって以前にサンプリングされている。識別されたコンテンツについての情報が次いで、任意選択でユーザコンテキスト情報とともに、パブリッシュされる。このパブリッシュされた情報に応答して、１つ又は複数の第三者入札が受信される。決定が、落札、及び、落札に関連付けられた第三者について行われる。決定された第三者により識別されたソフトウェアが次いで有効化されて、ユーザデバイス上でユーザに購入機会が提示される。
【０５９６】
さらに別の方法は、所与のタイプ（例えば、オーディオ、画像又はビデオ）の受信されたコンテンツに対応する、デジタルデータのセットを受信するステップを含む。受信されたコンテンツに対応する識別データが生成され、それにより、受信されたコンテンツが、所与のタイプの他のコンテンツとは区別されうる。識別データを参照することによって、受信されたコンテンツに関連付けられ、且つ、所与のタイプのすべての他のコンテンツに関連付けられない、Ｎ個のアプリケーションプログラム（複数可）が決定され、但し、Ｎは１又は複数である。アクションが次いで、決定されたアプリケーションプログラム（複数可）のうち１つ又は複数により、取られる。
【０５９７】
この技術の別の態様は、オペレーティングシステム（ＯＳ）ソフトウェアが格納されている、コンピュータ可読ストレージ媒体である。ＯＳソフトウェアは、ＯＳサービスを、定義されたインターフェースを通して、要求側アプリケーションプログラムに提供するように、プロセッサを構成する役目を果たす。これらのＯＳサービスは、視覚又は聴覚の情報を表す信号データから、コンテンツ識別データを導出すること、及び、コンテンツ識別データを、定義されたインターフェースを通して、コンテンツ識別データをサブスクライブする１つ又は複数のアプリケーションプログラムによって使用するために、パブリッシュすることを含む。
【０５９８】
この技術の別の態様は、処理デバイスとメモリとを含む装置である。メモリはオペレーティングシステム（ＯＳ）命令を含み、該ＯＳ命令は、ＯＳサービスを、定義されたインターフェースを通して、要求側アプリケーションプログラムに提供するように、処理デバイスを構成するＯＳ命令を含む。装置は、デバイスの環境から周囲の視覚及び／又は音の刺激を検知するためであり、且つ、それに対応するコンテンツデータを作り出すための、検知システムをさらに含む。ＯＳサービスのうち１つは、作り出されたコンテンツデータからコンテンツ識別データを導出し、コンテンツ識別データを、定義されたインターフェースを通して、サブスクライブする要求側アプリケーションプログラムにパブリッシュする。
【０５９９】
この技術の別の態様は、処理デバイスとメモリとを含む装置である。メモリはオペレーティングシステム（ＯＳ）命令を含み、オペレーティングシステム（ＯＳ）サービスを、定義されたインターフェースを通して、要求側アプリケーションプログラムに提供するように、処理デバイスを構成するＯＳ命令を含む。これらの定義されたインターフェースのうち１つはコンテンツ識別メッセージキューを提供し、該コンテンツ識別メッセージキューがデバイスによって処理された視覚又は音の刺激に対応するコンテンツ識別データをパブリッシュする、、該コンテンツ識別メッセージキューを、１つ又は複数のアプリケーションプログラムがサブスクライブすることができる。
【０６００】
この技術の別の態様は、ユーザの周囲環境から、延長された期間（prolongedperiod; 例えば、１５分、１時間、又は６時間より長い）にわたって、音又は視覚の刺激を検知し、それにより、ユーザがその期間中に曝されていたコンテンツに気付くステップを含む、方法である。この検知された刺激を参照することによって、構成されたハードウェアプロセッサが使用されて、ユーザがこの期間中に曝されていたコンテンツのいくつかの異なる項目に対応するコンテンツ識別データが生成される。次いで、ユーザインターフェースとの後続のユーザインタラクションの過程で、この方法は、ユーザに対して、タイトルによって、ユーザの環境から気付かれたコンテンツの複数の異なる項目を識別し、ユーザが、識別されたコンテンツの項目のうち少なくとも１つに対する複数の異なるアクションの中で選択できるようにする。
【０６０１】
別の方法は、ユーザの周囲環境から、音又は視覚の刺激を検知し、それにより、ユーザが曝されていたコンテンツに気付くステップを含む。検知された刺激を参照することによって、構成されたハードウェアプロセッサが使用されて、コンテンツの少なくとも１つのそのような項目に対応するコンテンツ識別データが生成される。２つ以上の異なるソフトウェアアプリケーションが次いで、そのような生成されたコンテンツ識別データに少なくとも部分的に基づく情報により、用意される。この構成によって、ユーザが次に、異なるソフトウェアアプリケーションの各々を利用するとき、ユーザは、異なるソフトウェアアプリケーションの各々が、ユーザがコンテンツの項目に曝されたことを既に反映することを、発見するようになる。
【０６０２】
さらなる方法は、消費者電子デバイスを使用して、オーディオ、画像及び／又はビデオコンテンツを表すコンテンツデータを受信するステップを含み、但し、以前にインストールされたか、又は他の方法で、デバイスとともに使用するために使用可能にされた、第１のソフトウェアレンダリングプログラムのために、電子デバイスがレンダリングしてコンテンツ関連体験を作り出すことが可能であるタイプのファイルフォーマットで、コンテンツデータが受信される。受信されたコンテンツデータを参照することによって１つ又は複数のソフトウェアレンダリングプログラム（複数可）が決定され、該ソフトウェアレンダリングプログラム（複数可）は、受信されたコンテンツデータとともにコンテンツ関連ユーザ体験を作り出すためにコンテンツデータの所有者によって規定される。この方法は次いで、これらの決定されたソフトウェアレンダリングプログラムのいずれもが現在インストールされていないか、又は、デバイスとともに使用するために使用可能でないと決定し、したがって、可能な第１のソフトウェアレンダリングプログラムにもかかわらず、受信されたコンテンツデータをデバイス上でレンダリングすることを拒否する。そのような構成によって、消費者電子デバイスは、それによりコンテンツ関連ユーザ体験がユーザに配信されるべきである、ソフトウェアレンダリングプログラム（複数可）に関する、所有者の規定を尊重する。
【０６０３】
さらに別の方法は、ユーザのデバイスを使用して、アートをレンダリングすることに関し、但し、アートは、その所有者によって作り出されている。アートは、いくつかの異なるソフトウェアプログラムによってレンダリングされうるデータフォーマットで表される。この方法は、プログラムされたプロセッサを使用して、所有者により指定されたメタデータを調べて、アートデータをレンダリングするために利用されうるこれらのプログラムのサブセットを決定するステップと、このサブセットのうち１つのプログラムによりアートデータをレンダリングするステップとを、さらに含む。そのような構成によって、所有者に、アートがどのようにレンダリングされるかの、ある程度の制御権が与えられる。
【０６０４】
この技術の別の態様は、処理デバイスと、処理デバイスを構成するためのいくつかのソフトウェアプログラムを格納するコンピュータ可読ストレージ媒体と、装置の環境内の周囲の視覚又は音のコンテンツを表すデータを生成するための検知システムとを含む、装置である。ソフトウェアプログラムのうち少なくとも１つが、コンピュータ可読ストレージ媒体に、装置が装置の環境からある周囲のコンテンツを検知する結果として、格納される。
【０６０５】
この技術の別の態様は、プロセッサとメモリとを含むポータブルデバイス（例えば、スマートフォン）であり、メモリは、オペレーティングシステムソフトウェアと、複数のソフトウェアプログラムとを含む。これらのプログラムのうち第１のものは、音又は視覚のコンテンツを表すデータを解析して、対応する識別データを作り出す役目を果たし、そのような解析の結果を出力にパブリッシュする。これらのプログラムのうち第２のものは、第２のプログラムが調和するあるコンテンツについて、第１のプログラムの出力を監視し、あるコンテンツが気付かれるとき、アクションを取る役目を果たす。
【０６０６】
さらに別の方法は、見る姿勢から被写体の画像を取り込み、取り込まれた画像をポータブルデバイスの画面上に提示するステップを含む。見る姿勢の最適性が、取り込まれた画像を参照することによって評価される。この方法は次いで、取り込まれた画像の提示上に、評価の結果を指示するしるしをオーバーレイする。このオーバーレイされたしるしは、評価された最適性の変化とともに変化する。
【０６０７】
さらなる方法は、ポータブルデバイスを使用して、画像の複数のフレームを取り込むステップを含み、ポータブルデバイスは、画像センサ及び第２のセンサを有する。取り込まれたフレームのうち少なくとも２つのサブセットが、第２のセンサからのデータに基づいて選択される。これらの選択されたフレームが次いで、結合される。結合は、顕著点を使用することができ、結合された出力は、ポータブルデバイス内のデジタルウォーターマーク復号器に提供されうる。
【０６０８】
この技術の別の態様は、プロセッサと、メモリと、少なくともカメラ及びマイクロフォンを含む複数のセンサとを含む、ポータブルデバイス（例えば、スマートフォン）である。デバイスコンポーネントが協働して、オーディオフィンガープリント認識エージェント、バーコード認識エージェント、及び、画像ウォーターマーク認識エージェントなど、複数の認識エージェントを定義する。エージェントが、メモリのブラックボードデータ構造からデータを読み取り、且つ、メモリのブラックボードデータ構造へデータを書き込むように構成される。このブラックボードデータ構造がまた、センサからデータを受信するように、且つ、エージェントが処理する格納された画像データ及びオーディオデータのキューを編集するように構成される。これらの要素が、メモリ内の命令によって定義されたイベントコントローラの制御下で協働する。
【０６０９】
さらに別の方法は、人と複数のオブジェクトの間のネットワーク関係を決定するステップと、これらのネットワーク関係から、人にとってのオブジェクトの相対的重要性を見極めるステップとを含む。アクションが次いで、見極められた相対的重要性に基づいて取られる。
【０６１０】
さらに別の方法は、ポータブルデバイスにより、人の手のジェスチャーの画像を取り込むステップを含む。画像が処理されて、ジェスチャーから手話が見極められ、それに基づいて、アクションが取られる。
【０６１１】
さらなる方法は、第１及び第２の空間周波数部分を有する情報搬送パターンを定義するステップと、このパターンを基層上にプリントするステップとを含む。第１の部分が、見る人に、符号化された情報の存在への合図を出す、可視バックグラウンド織り込みパターンを定義し、第２の部分が、人間の視覚の範囲を超える空間周波数を含み、符号化された情報のうち、少なくとも特定のものを搬送する。
【０６１２】
さらに別の方法は、第１のデバイス内で、デジタルウォーターマーキングによって符号化されたペイロードデータを有するオーディオ又は画像のコンテンツデータを受信するステップを含む。このペイロードデータが復号され、次いで、少なくとも一部分が、デジタルウォーターマーキング以外の技法によって、第２のデバイスへ送信される。
【０６１３】
なお、さらなる方法は、ホームエンターテインメントシステム内で、オーディオ又は画像のコンテンツを受信し、メディアフィンガープリント情報を決定するステップを含む。メディアフィンガープリント情報が次いで、コンテンツがホームエンターテインメントシステムによってレンダリングされているユーザのポータブルデバイス（例えば、スマートフォン）へ、ワイヤレスで送信される。
【０６１４】
別の方法は、小売店内で、店内の買物客による製品関心を指示する信号を受信するステップと、次いで、受信された信号に基づいて、アクションを取るステップとを含む。このアクションは、買物客をサービスのためのキューに入れるサブステップと、買物客にサービスのための待ち時間を知らせるサブステップと、買物客に、サービスを提供するようになる小売店スタッフについての情報を提供するサブステップと、買物客に、サービスを待つように誘い物を提供するサブステップとのうち、少なくとも１つを含む。（そのような誘い物は、そうでない場合は料金が課されるはずのエンターテインメントコンテンツでありうる。）
【０６１５】
さらなる方法は、買物客のスマートフォンによって、小売店内に陳列された第１の製品から検知されたデータを参照することによって、第２の製品が第１の製品と互換性を有するかどうかを判定するステップと、次いで、そのような判定に基づいてアクションを取るステップと、を含む。
【０６１６】
さらに別の方法は、デジタルウォーターマーキングされたオブジェクトから画像を取り込むステップを含み、デジタルウォーターマークは、既知の参照特徴を含む。次いで、これらの既知の参照特徴がぼけカーネルの推定において使用され、取り込まれた画像がぼけカーネルにより処理されて画像ぼけが低減されうる。
【０６１７】
さらに別の方法は、ユーザのポータブルデバイス（例えば、スマートフォン）によって検知された情報を参照することによって、ユーザの関心を決定するステップと、次いで、決定された関心に基づいてアクションを取るステップと、を含む。
【０６１８】
さらに別の方法は、ユーザが選択することができる、ポータブルデバイスの画面上のテキスト文字の配列を表示するステップと、画面の一部分に向かうユーザの凝視を検知して、テキスト選択を行うステップと、次いで、ユーザが次に選択することができる、画面上の文字の配列を変更するステップとを含む。
【０６１９】
さらなる方法は、スマートフォンカメラを使用して、画像データのビデオシーケンスを取り込むステップと、取り込まれたデータ内で第１のマシン可読シンボロジー（ｓｙｍｂｏｌｏｇｙ）を識別するステップと、第１の識別されたシンボロジーに関係付けられた情報を格納するステップと、取り込まれたデータ内で第２のマシン可読シンボロジーを識別するステップと、第２の識別されたシンボロジーに関係付けられた情報を格納するステップとを含む。そのような構成によって、デバイスが、ストリーミングモードで動作して、取り込まれたビデオシーケンス内で発見されたマシン可読シンボロジーに関係付けられた情報を収集する。
【０６２０】
この技術の別の態様は、プロセッサと、メモリと、１つ又は複数のセンササブシステムと、タッチスクリーンとを含む、システムである。システムは、デバイスが、センササブシステムからの情報を、メモリ内にＲＤＦトリプルとして格納するように構成され、プロセッサが、格納されたＲＤＦトリプルに基づいて、アクションを取るように構成されることを特徴とする。
【０６２１】
この技術のさらに別の態様は、センサデータを受信するステップと、検知された情報を、格納のためにＲＤＦトリプルとして表すステップと、次いで、格納されたＲＤＦトリプルを処理するステップと、を含む、方法である。
【０６２２】
この技術の別の態様は、カメラと、プロセッサと、メモリとを含む、デバイスである。メモリが、カメラによって取り込まれた画像のセットを格納し、画像のセットについてのアサーションを作成する複数のＲＤＦトリプルをも格納する。デバイスプロセッサが、格納されたＲＤＦトリプルのうち１つ又は複数を参照することによって、格納された画像のセットにおいて演算を行うように構成される。
【０６２３】
別の方法は、第１のコンピュータ処理が、１つ又は複数の他のコンピュータ処理からのサービスを要求することを可能にし、要求をデータ構造に投稿するステップであって、要求がＲＤＦトリプルとして表現される、ステップを含む。
【０６２４】
さらに別の方法は、オーディオ情報を消費者電子デバイスで受信するステップを含み、但し、オーディオ情報がコンテンツ配給者によって用意されており、少なくとも第１及び第２のオーディオトラックを含む。このデバイス内で、第１及び第２のトラック間の比を設定する、制御信号が受信される。オーディオが次いで、この比に従って消費者にレンダリングされる。第２のオーディオトラックが、補助情報を搬送する、雑音のようなデジタルウォーターマーク信号を含む。
【０６２５】
この技術の別の態様は、第１のデバイスによってレンダリングされる場合、第２のデバイスの機能を制御する、コンテンツデータを含む、コンピュータ可読媒体である。このコンテンツデータは、オーディオ情報の少なくとも第１及び第２のトラックを含む。第１のトラックは、消費者の楽しみのためのオーディオを含み、第２のトラックは、第２のデバイスのための制御データを搬送する、雑音のようなデジタルウォーターマーク信号を含む。
【０６２６】
この技術の別の態様は、オーディオの少なくとも第１及び第２のトラックに対応するデータを含む、コンテンツ情報を格納するメモリを含む、装置である。オーディオ部が、コンテンツ情報を出力デバイス（例えば、スピーカ）にレンダリングするために提供される。このオーディオ部は、第２のトラックが第１のトラックに対してレンダリングされるべきであるレベルを設定するために、ユーザによって操作可能なコントロールを含む。オーディオの第２のトラックに対応する、格納されたデータは、第２の装置の機能を制御するための、雑音のようなデジタルウォーターマーク信号を表す。
【０６２７】
この技術の別の態様は、カメラを装備したポータブルデバイスによって取り込まれた画像に対応する第１のセットのデータを受信するステップを含む、方法であり、但し、画像は被写体を描く。ステガノグラフィ的に符号化されたデジタルウォーターマークペイロードデータが、第１のセットのデータから復号される。このペイロードデータを参照することによって、第２のセットのデータが得られる。この第２のセットのデータは、被写体に対応する顕著点データを含む。
【０６２８】
この技術の別の態様は、コンピューティングデバイスによって実行される場合、被写体を描く画像に対応する第１のセットのデータを受信すること、ステガノグラフィ的に符号化されたデジタルウォーターマークペイロードデータを、第１のセットのデータから復号すること、及び、ペイロードデータを参照することによって、第２のセットのデータを得ることを含む動作をコンピューティングデバイスに行わせるソフトウェア命令を含む、コンピュータ可読媒体である。第２のセットのデータは、被写体に対応する顕著点データを含む。
【０６２９】
この技術のさらなる態様は、ポータブルデバイス内で、オブジェクトに関連付けられたパッシブチップデバイスから検知された識別データを受信するステップを含む、方法である。この識別データを参照することによって、第２のセットのデータが得られる。この第２のセットのデータは、オブジェクトに対応する顕著点データを含む。
【０６３０】
この技術の別の態様は、ポケットサイズのハウジング内に配置された、メモリ及び処理部を含む、ポータブルデバイスである。メモリは第１の部分を含み、該第１の部分が、複数のコードベースのセマンティックトリプルを表すコードデータを格納す、トリプルの各々は、第１、第２及び第３のコードを含み、コードのうち１つが主部コードであり、１つが述部コードであり、１つが目的部コードである。メモリは第２の部分をさらに含み、該第２の部分が、異なるテキストリテラルを別々のコードに関連付けるリテラルデータを格納する。処理部はＧＰＵをさらに含み、該ＧＰＵが、メモリの第１の部分内のコードデータを処理して、メモリの第２の部分内のテキストリテラルによって表された情報において演算を行う。
【０６３１】
この技術の別の態様は、ポケットサイズのハウジング内に配置された、メモリ及び処理部を含む、ポータブルデバイスである。メモリはフレームバッファ部を含み、該フレームバッファ部が、複数のコードベースのセマンティックトリプルを表すコードデータを格納し、各トリプルは、主部コード、述部コード、及び目的部コードを含む。メモリは第２の部分をさらに含み、該第２の部分は、異なるテキストリテラルを別々のコードに関連付けるリテラルデータを格納する。処理部はＧＰＵを含み、該ＧＰＵが、メモリの第１の部分内のコードデータを処理して、メモリの第２の部分内のテキストリテラルを使用して表現された概念を含むセマンティックな推論を行う。
【０６３２】
この技術のさらなる態様は、ポケットサイズのハウジング内に配置された、メモリ及び処理部を含む、ポータブルデバイスである。処理部は、メモリ内に格納された命令によって構成され、ＧＰＵを含む。メモリは、複数のコードベースのセマンティックトリプルを表すコードデータを格納し、各トリプルは、主部コード、述部コード、及び目的部コードを含む。命令は、前記処理部が一連のテンプレートを格納されたコードデータに適用して、トリプルに基づいて演算を行うように、処理部を構成する。
【０６３３】
この技術の別の態様は、カメラを装備したポータブルデバイスによって取り込まれた画像に対応するデータのセットを受信するステップを含む、方法であり、但し、画像は被写体を描く。識別データが、受信されたデータのセットに基づいて決定される。識別データを参照することによって、第２のセットのデータが得られ、但し、この第２のセットのデータは、複数のＮ−タプルを含み、各々は、主部、述部及び目的部要素を含む。これらのＮ−タプルが処理され、そのような処理に基づいて、アクションが取られる。
【０６３４】
この技術のさらなる態様は、ポケットサイズのハウジング内に配置された、タッチスクリーン、メモリ及び処理部を含む、ポータブルデバイスである。メモリは、複数のコードベースのセマンティックトリプルを表すデータを含み、各トリプルは、主部コード、述部コード、及び目的部コードを含む。メモリは、別々のコードのためのそれぞれのテキストの意味を指示する、テキストリテラルを含む部分をさらに含む。メモリはまたソフトウェア命令をも含み、該命令は、処理部が、タッチスクリーン上で、テキストリテラルのうち特定のものがポピュレートされるユーザインターフェースを提示し、該ユーザインターフェースを通してユーザがコードベースのセマンティックトリプルのクエリを定義することができるように、処理部を構成する、。
【０６３５】
この技術の別の態様は、ポケットサイズのハウジング内に配置された、タッチスクリーン、メモリ及び処理部を含む、ポータブルデバイスである。メモリが、複数のデータＮ−タプルを含む、ストレージの複数のプレーンとして論理的に編成され、Ｎ−タプルの要素がテキストリテラルに対応する。処理部はＧＰＵを含み、該ＧＰＵは、タッチスクリーンユーザインターフェースを介して入力されたユーザクエリに応答することの一部として、データＮ−タプルにおいて演算するように構成されている。
【０６３６】
別の方法は、ユーザクエリに対応するデータを受信するステップを含む。第１のプレーン閾値処理テストが、Ｎ−タプルデータストアの１つのプレーン内に格納された値に適用され、但し、データストアが、複数のデータＮ−タプルを格納するデータのＮ個のプレーンを含むように論理的に編成され、但し、Ｎは少なくとも３である。このプレーン閾値処理テストは、ユーザクエリの第１の態様を満たす、格納されたデータＮ−タプルの第１のサブセットを識別する。
【０６３７】
さらに別の方法は、カメラを装備したポータブルデバイスによって取り込まれた画像に対応する第１のセットのデータを受信するステップを含み、但し、画像は、第１の解像度で被写体を描く。識別データが、第１のセットのデータに基づいて決定される。この識別データを参照することによって、第２のセットのデータが得られ、但し、第２のセットのデータは、被写体を描く画像に対応する。第２のセットのデータは、第１のセットのデータとは異なる視点から被写体を描き、第１の解像度よりも高い第２の解像度で被写体を描きうる。
【０６３８】
さらに別の方法は、オブジェクトから検知されたＮＦＣ識別データを受信するステップと、識別データを参照することによって、オブジェクトを描く画像データのセットを得るステップと、を含む。
【０６３９】
さらなる方法は、第１及び第２のデバイス間でアプリケーション状態を転送するステップに関し、各デバイスは、プロセッサと表示画面とを含む。この方法は、第１のデバイス内のカメラを使用して、第２のデバイスの表示画面上に提示された画像を検知するステップを含む。デジタルウォーターマークデータが、検知された画像から復号される。復号されたデジタルウォーターマークデータに基づいて、格納されたデータが識別され、該格納されたデータが第２のプロセッサのアプリケーション状態をメモリアライズする。この格納されたデータが次いで使用されて、第２のプロセッサがアプリケーション状態に初期化されうる。
【０６４０】
さらに別の方法は、プロセッサと表示画面とを有するデバイスを伴う。この方法は、アプリケーション状態データを時折格納するステップと、画像をデジタルウォーターマーキングして、その中の識別子を符号化するステップとを含み、但し、識別子は、格納されたアプリケーション状態データへのアクセスを容易にする。このデジタルウォーターマーキングされた画像が次いで、表示画面上に提示されうる。
【０６４１】
さらに別の方法は、ポータブルデバイス内のカメラを使用して、光（例えば、周囲光）を検知するステップを含む。識別子が、検知された光から復号され、情報が次いで、復号された識別子に基づいて得られる。
【０６４２】
さらなる方法は、動いている車両の方向及び／又は速度を符号化する信号を生成するステップと、そのような信号に従って、車両の１つ又は複数の外部ライト（例えば、ヘッドランプ）を制御するステップとを含む。
【０６４３】
別の方法は、照明器具によって照明された環境からデータを検知するステップと、検知されたデータを処理してそれに対応する情報を決定するステップとを含む。照明器具から発せられた光が次いで、決定された情報に従って符号化される。
【０６４４】
さらに別の方法は、デバイスのマイクロフォンにより、ユーザの周囲環境から、延長された間隔（例えば、少なくとも１５分、１時間、又は６時間）にわたって、オーディオを受信するステップを含む。アルゴリズムが次いで、受信されたオーディオを表すデータに適用されて、識別データが導出される。導出された識別データを参照することによって、ユーザがその間隔中に曝されたオーディオコンテンツの少なくとも第１及び第２の異なる項目が決定される。オーディオコンテンツのこれらの２つの項目を参照することによって、ソフトウェアが、ユーザによる後の使用のために用意される。この用意するステップは、補助コンテンツの第１及び第２の項目を、デバイスで、１つ又は複数のリモートリポジトリから受信するサブステップを含む。補助コンテンツの第１の項目が、オーディオコンテンツの第１の決定された項目に関連付けられ、補助コンテンツの第２の項目が、オーディオコンテンツの第２の決定された項目に関連付けられる。ユーザが次いで、オーディオコンテンツの決定された第１及び第２の項目を識別するリストを提示されうる。関心のあるものとしての、オーディオコンテンツのこれらの決定された項目のうち１つのユーザ選択に応答して、補助コンテンツの対応する項目を使用して、用意されたソフトウェアに従って、アクションが取られうる。そのような構成によって、ユーザが曝されるオーディオコンテンツの項目が監視され、ユーザがオーディオコンテンツの特定の項目を関心のあるものとして選択するより前に、関連付けられた補助コンテンツが、デバイスによって受信される。
【０６４５】
さらに別の方法は、ポータブルデバイスのマイクロフォンにより、ユーザの周囲環境から、延長された間隔にわたって、オーディオを受信するステップを含む。この間隔中のユーザのロケーションが、検知される。アルゴリズムが、受信されたオーディオを表すデータに適用されて、識別データが導出される。導出された識別データを参照することによって、ユーザがその間隔中に曝されたオーディオコンテンツの少なくとも第１及び第２の異なる項目が決定される。ポータブルデバイスのユーザインターフェースを通して、オーディオコンテンツの決定された第１及び第２の異なる項目が、ユーザに識別され、第１の項目を選択する、ユーザインターフェースを通して入力されたユーザ信号が、受信される。応答において、オーディオコンテンツの第１の項目の識別が、ユーザの検知されたロケーションを指示するデータとともに、オンラインソーシャルネットワークに投稿される。
【０６４６】
この技術の別の態様は、メモリ内の命令によって構成されるプロセッサを含む、システムである。これらの命令は、オペレーティングシステムソフトウェアを含む。オペレーティングシステムソフトウェアは、入力オーディオデータを受信するオーディオ識別サービス、又は、格納されたオーディオデータへのポインタを提供し、それに対応するメタデータを、オペレーティングシステムソフトウェアのオーディオ識別メッセージキューへ返す。
【０６４７】
さらなる方法は、モバイル電話デバイスのカメラ部分を使用して取り込まれ、デバイスの画面上に表示された、第１の被写体を描く画像のフレームを含む。この方法は、取り込まれた画像データを解析することによって、第１の被写体に関係付けられた識別子を作り出すステップを含む。第１のタグが、画面上に、画像の第１のフレームとともに表示される。この第１のタグが、画面上の第１の位置に位置し、第１の被写体に関連付けられたアクションを開始するようにユーザ選択可能である。第１のフレーム内に描かれた通りの第１の被写体を、表示された第１のタグに関連付ける、視覚的しるしが、画面上に提示される。この方法は、この第１のタグを、画面上に、第１の被写体を描く画像の第２のフレームとともに表示するステップをさらに含む。第１の被写体が、画像の第１及び第２のフレーム内の異なるロケーションに描かれるが、第１のタグが、画像の第１及び第２のフレームの両方とともに、画面上の同じ第１の位置に表示される。
【０６４８】
別の方法は、ユーザのモバイル電話のカメラ部分によって取り込まれた画像内で描かれた物理的オブジェクトを識別して、それにより、ユーザに関する物理的オブジェクトプリファレンス情報を見極めるステップを含む。それに基づいた物理的オブジェクトプリファレンスプロファイルデータが次いで、メモリ内に格納される。電子メディアがその後、格納された物理的オブジェクトプリファレンスプロファイルデータに少なくとも部分的に基づいて、処理されうる。
【０６４９】
さらに別の方法は、ポータブルデバイスのカメラ部分により、画像のシーケンスを取り込むステップを含む。シーケンスの１つの抜粋が解析されて、較正情報が見極められ、但し、較正情報は、この抜粋内で描かれた人の手の色を特徴付ける肌色データを含む。シーケンスの他の抜粋が解析されて、取り込まれた画像を格納された参照手型データとマッチングすることによって、画像内に描かれたアメリカ手話（Ａｍｅｒｉｃａｎ  Ｓｉｇｎ  Ｌａｎｇｕａｇｅ）の手型が識別される。語、音素及び／又は文字が次いで、前記解析に基づいて、出力デバイスに出力されうる。
他のコメント
【０６５０】
例示的な例を参照して、本発明の研究の原理を説明及び図示したが、この技術はそのように限定されないことは理解されよう。
【０６５１】
例えば、スマートフォンに言及しているが、この技術は、あらゆる種類のデバイス−ポータブルも固定も−とともに有用性を見いだすことは理解されよう。ポータブル音楽プレイヤ、デスクトップコンピュータ、ラップトップコンピュータ、タブレットコンピュータ、セットトップボックス、テレビ、ネットブック、ウルトラポータブル、ウェアラブルコンピュータ、サーバ、その他は、すべて、本明細書で詳述した原理を使用することができる。
【０６５２】
特に企図されるスマートフォンには、アップルアイフォン４、及び、グーグルのアンドロイド仕様に従うスマートフォン（例えば、ＨＴＣ  Ｃｏｒｐ．によって製造されたベライゾン（Ｖｅｒｉｚｏｎ）ドロイドエリス（Ｄｒｏｉｄ  Ｅｒｉｓ）電話、及び、モトローラ（Ｍｏｔｏｒｏｌａ）ドロイド（Ｄｒｏｉｄ）２電話）が含まれる。「スマートフォン」（又は、「携帯電話」）という用語は、厳密に言えばセルラーでも電話でもないものであっても、すべてのそのようなデバイスを包含するように解釈されるべきである。
【０６５３】
（アイフォンの詳細は、そのタッチインターフェースを含めて、アップルの特許出願公開２００８０１７４５７０で提供されている。）
【０６５４】
本開示で言及したスマートフォン及び他のコンピュータの設計は、当業者にはよく知られている。一般論として、各々は、１つ又は複数のプロセッサと、１つ又は複数のメモリ（例えば、ＲＡＭ）と、ストレージ（例えば、ディスク又はフラッシュメモリ）と、ユーザインターフェース（例えば、キーパッド、ＴＦＴ  ＬＣＤ若しくはＯＬＥＤ表示画面、タッチ若しくは他のジェスチャーセンサ、カメラ若しくは他の光センサ、コンパスセンサ、３Ｄ磁力計、３軸加速度計、３軸ジャイロスコープ、１つ若しくは複数のマイクロフォン、その他を、グラフィカルユーザインターフェースを提供するためのソフトウェア命令とともに含みうる）と、これらの要素間の相互接続（例えば、バス）と、他のデバイスと通信するためのインターフェース（ＧＳＭ、ＣＤＭＡ、Ｗ−ＣＤＭＡ、ＣＤＭＡ２０００、ＴＤＭＡ、ＥＶ−ＤＯ、ＨＳＤＰＡ、ＷｉＦｉ、ＷｉＭａｘ若しくはブルートゥースなどのワイヤレス、及び／又は、イーサネットローカルエリアネットワーク、Ｔ−１インターネット接続、その他によるなどのワイヤード）とを含む。
【０６５５】
本明細書は、譲受人の以前の特許出願との関係に以前に言及したが、繰り返しを有する。これらの開示は、同時に読まれ、全体として解釈されるべきである。出願人は、各開示における特徴及び実装形態の詳細が組み合わせられ、他の開示におけるそのような教示とともに使用されることを意図する。したがって、本出願で開示された方法、要素及び概念は、それらの関連出願で詳述された方法、要素及び概念と組み合わせられることを理解されたい。いくつかは本明細書で特に詳述されたが、−並べ換え及び組み合わせが多数であるため−多くは詳述されていない。しかし、すべてのそのような組み合わせの実装形態は、提供された教示から、当業者には容易である。
【０６５６】
本明細書で開示した異なる実施形態内の要素及び教示もまた、交換及び組み合わされるように意図されている。
【０６５７】
本明細書で詳述した処理及びシステムコンポーネントは、コンピューティングデバイスのための命令として実装されてもよく、これらの命令には、マイクロプロセッサ（例えば、アトム及びＡ４）、グラフィックス処理装置（ｎＶｉｄｉａ  Ｔｅｇｒａ  ＡＰＸ  ２６００など、ＧＰＵ）、及び、デジタル信号プロセッサ（例えば、テキサスインスツルメンツ（Ｔｅｘａｓ  Ｉｎｓｔｒｕｍｅｎｔｓ）ＴＭＳ３２０シリーズのデバイス）、その他を含む、様々なプログラマブルなプロセッサのための汎用プロセッサ命令が含まれる。これらの命令は、ソフトウェア、ファームウェア、その他として実装されてもよい。これらの命令はまた、様々な形式のプロセッサ回路で実装することもでき、これらのプロセッサ回路には、プログラマブル論理デバイス、フィールドプログラマブルゲートアレイ（例えば、Ｘｉｌｉｎｘ  Ｖｉｒｔｅｘシリーズのデバイス）、フィールドプログラマブルオブジェクトアレイ、並びに、特定用途向け回路−デジタル、アナログ、及び、混合のアナログ／デジタル回路を含む−が含まれる。命令の実行を、複数のプロセッサ間で分散させることができ、及び／又は、１つのデバイス内の複数のプロセッサにわたって、若しくは、デバイスのネットワークの全体で並列にすることができる。コンテンツ信号データの処理もまた、異なるプロセッサ及びメモリデバイス間で分散されうる。「クラウド」コンピューティングリソースも、同様に使用することができる。「プロセッサ」、「モジュール」又は「コンポーネント」への言及は、特定の形態の実装を必要とするのではなく、機能性を指すものと理解されたい。
【０６５８】
詳述した機能性を実装するためのソフトウェア命令は、当業者によって、本明細書で提供した説明から、過度の実験なしに書くことができ、例えば、Ｃ、Ｃ＋＋、ビジュアルベーシック（Ｖｉｓｕａｌ  Ｂａｓｉｃ）、Ｊａｖａ、パイソン（Ｐｙｔｈｏｎ）、Ｔｃｌ、パール（Ｐｅｒｌ）、スキーム（Ｓｃｈｅｍｅ）、ルビー（Ｒｕｂｙ）、その他で書くことができる。本技術のある実装形態による携帯電話及び他のデバイスは、異なる機能及び行為を行うためのソフトウェアモジュールを含みうる。
【０６５９】
知られているブラウザソフトウェア、通信ソフトウェア、及び、メディア処理ソフトウェアは、本明細書で詳述した使用の多数に合わせて構成されうる。
【０６６０】
コンテンツ所有者がそれによりある属性及び体験を（例えば、指定されたソフトウェアの呼び出しを通して）コンテンツによるものとするサービスは、典型的には、ソフトウェアをユーザデバイス上で−ＯＳ内で、又は、アプリケーションソフトウェアとして−使用する。代替として、このサービスは、リモートリソースを使用して−部分的に−実装されうる。
【０６６１】
ソフトウェア及びハードウェア構成データ／命令は一般に、磁気又は光ディスク、メモリカード、ＲＯＭ、その他など、有形の媒体によって搬送される１つ又は複数のデータ構造における命令として格納され、ネットワークを介してアクセスされうる。いくつかの実施形態は、（例えば、基本的な携帯電話の場合に一般的であるように）埋め込みシステム−ユーザには、オペレーティングシステムソフトウェア及びアプリケーションソフトウェアの区別がつかない、専用コンピュータシステム−として実装されてもよい。本明細書で詳述した機能性を、オペレーティングシステムソフトウェア、アプリケーションソフトウェア内で、及び／又は、埋め込みシステムソフトウェアとして実装することができる。
【０６６２】
別々の機能性を、異なるデバイス上で実装することができる。例えば、スマートフォンがリモートサービスプロバイダのサーバと通信するシステムでは、異なるタスクをあるデバイス若しくは他のデバイスによって排他的に行うことができ、又は、実行をデバイス間で分散させることができる。コンテンツからのフィンガープリント及びウォーターマークデータの抽出は、そのような方式で分散されうる処理の一例である。したがって、特定のデバイス（例えば、スマートフォン）によって行われているような動作の説明は、限定的ではなく例示的であり、別のデバイス（例えば、リモートサーバ）による、又は、デバイス間で共有される動作の性能もまた、明示的に企図されることを理解されたい。
【０６６３】
（同様に、特定のデバイス上に格納されているデータの説明もまた例示的であり、データを、ローカルデバイス、リモートデバイス、クラウド内、分散するなど、どこにでも格納することができる。）
【０６６４】
実際の実施では、本技術によって使用されるデータ構造は、分散されうる。例えば、異なるレコードレーベルは、それぞれ自社のカタログ内の音楽のための自社のデータ構造を維持することができる。あるシステムは、一連の中間データ構造（階層的であることが多い）をナビゲートして、必要とされる情報とともに１つを探し出す必要があることがある。（１つの適した構成は、ディジマークの米国特許第６９４７５７１号に詳述されている。）一般にアクセスされた情報は、ネットワーク内のサーバにキャッシュされて−ＤＮＳデータによく似ている−アクセスの速度が速められてもよい。
【０６６５】
ＧＰＵに言及したが、この用語は、同時に動作可能な複数のハードウェアコアを含むいかなるデバイスをも含むように意図される。インテル（Ｉｎｔｅｌ）は、例えば、「メニーインテグレーテッドコア（Ｍａｎｙ  Ｉｎｔｅｇｒａｔｅｄ  Ｃｏｒｅ）」、すなわち、インテルＭＩＣという用語を使用して、そのようなクラスのデバイスを示す。大部分の現代のＧＰＵは、グラフィックス処理のために最適化される命令セットを有する。アップルアイフォン４デバイスは、パワーＶＲ（ＰｏｗｅｒＶＲ）ＳＧＸ  ５３５  ＧＰＵ（他のデバイスとともに、システムオンチップ構成に含まれる）を使用する。大部分のそのようなデバイスは、命令セット内に、３プレーン画像又は４プレーン画像とともに機能するように調整される命令を含んで、ディスプレイへの出力のために意図されたフレームバッファ内の画像の構築を加速する。例えば、多数の命令は、データトリプルを入力として取り、データトリプルを出力として供給する。他の命令は、格納された画像フレーム内のデータ値の空間的な区域における演算を容易にする。
【０６６６】
同様に、ＮＦＣチップに言及したが、これは、あらゆる種類のチップを包含する−ＮＦＣリーダによる問い合わせを受けるとき、複数ビット識別子を搬送する信号を発する、他の名前（例えば、ＲＦＩＤチップ）によって知られるものを含む−ことは理解されよう。
【０６６７】
本開示は、行為の特定の順序付け、及び、要素の特定の組み合わせを詳述したが、他の企図される方法は、行為の順序を変えてもよく（場合によっては、いくつかの行為を省き、他の行為を追加する）、他の企図される組み合わせは、いくつかの要素を省き、他の要素を追加するなどしてもよいことは理解されよう。
【０６６８】
完全なシステムとして開示したが、詳述した構成の副次的組み合わせもまた、別々に企図される。
【０６６９】
オーディオ取り込み及び処理を行うシステムとの関連で主に詳述したが、対応する構成は、画像及びビデオを取り込み、処理するシステム、又は、複数の形式のメディアを取り込み、処理するシステムに等しく適用可能である。
【０６７０】
パブリッシュ／サブスクライブ機能性は、デバイス内のみではなく、ネットワークの全体で実装可能である。アドホックネットワークは、劇場内など、共通のロケーション内のユーザの間で形成されうる。あるユーザのスマートフォンによって生成されたコンテンツ認識情報が、アドホックネットワークにパブリッシュされてもよく、ネットワーク内の他者は、それに基づいてサブスクライブし、アクションを取ることができる。
【０６７１】
アップルのボンジュールソフトウェアは、そのような構成の例示的実装形態で使用されうる。ボンジュールは、アップルのゼロコンフ−サービス発見プロトコル−の実装形態である。ボンジュールは、デバイスをローカルネットワーク上で探し出し、マルチキャストドメインネームシステムサービス記録を使用して、各々が提供するサービスを識別する。（このソフトウェアは、アップルＭａｃ  ＯＳ  Ｘオペレーティングシステムに組み込まれ、また、アイフォンのためのアップル「リモート」アプリケーションにも含まれており−そこでは、ＷｉＦｉを介してアイチューンズライブラリへの接続を確立するために使用される。）ボンジュールサービスは、オペレーティングシステム内ではなく、標準的なＴＣＰ／ＩＰ呼び出しを主に使用して、アプリケーションレベルで実装される。アップルは、ボンジュールマルチキャストＤＮＳレスポンダのソースコード−サービス発見の中心的なコンポーネント−を、ダーウィン（Ｄａｒｗｉｎ）オープンソースプロジェクトとして入手可能にしている。このプロジェクトは、Ｍａｃ  ＯＳ  Ｘ、リナックス（Ｌｉｎｕｘ）、＊ＢＳＤ、ソラリス（Ｓｏｌａｒｉｓ）、及びウィンドウズを含む、広範囲のプラットフォームのためのレスポンダデーモンを構築するための、ソースコードを提供している。加えて、アップルは、ボンジュールフォーウィンドウズ（Ｂｏｎｊｏｕｒ  ｆｏｒ  Ｗｉｎｄｏｗｓ）と呼ばれる、ユーザによりインストール可能なサービスのセット、並びに、Ｊａｖａライブラリを提供している。ボンジュールはまた、デバイスとシステムの間の通信を含む、本技術の他の実施形態でも使用されうる。
【０６７２】
（他のソフトウェアは代替として、又は追加として、デバイス間でデータを交換するために使用されうる。例には、ユニバーサルプラグアンドプレイ（Ｕｎｉｖｅｒｓａｌ  Ｐｌｕｇ  ａｎｄ  Ｐｌａｙ）（ＵＰｎＰ）、及び、その後継のデバイシズプロファイルフォーウェブサービシズ（Ｄｅｖｉｃｅｓ  Ｐｒｏｆｉｌｅ  ｆｏｒ  Ｗｅｂ  Ｓｅｒｖｉｃｅｓ）（ＤＰＷＳ）が含まれる。これらは、ゼロ構成ネットワーキングサービスを実装する他のプロトコルであり、それを通して、デバイスは、接続し、デバイス自体を識別し、使用可能な能力を他のデバイスに宣伝し、コンテンツを共有するなどのことができる。他の実装形態は、ＣＯＲＢＡ（ＩＢＭウェブスフィア（ＷｅｂＳｐｈｅｒｅ）の別名でも知られる）など、オブジェクトリクエストブローカを使用してもよい。）
【０６７３】
ウォーターマークを符号化／復号するための技術は、例えば、ディジマークの特許文献６，６１４，９１４、６，５９０，９９６、６，１２２，４０３及び２０１００１５０４３４、並びに、係属中の米国特許出願第１２／７７４５１２号と、Ｎｉｅｌｓｅｎ（ニールセン）の特許６，９６８，５６４及び７，００６，５５５とに詳述されている。
【０６７４】
オーディオフィンガープリンティングの例は、特許公報の２００７０２５０７１６、２００７０１７４０５９及び２００８０３０００１１（ディジマーク）、２００８０２７６２６５、２００７０２７４５３７及び２００５０２３２４１１（ニールセン）、２００７０１２４７５６（グーグル）、７，５１６，０７４（Ａｕｄｉｔｕｄｅ）、並びに、６，９９０，４５３及び７，３５９，８８９（両方ともシャザム）に詳述されている。画像／ビデオフィンガープリンティングの例は、特許公報の７，０２０，３０４（ディジマーク）、７，４８６，８２７（Ｓｅｉｋｏ−Ｅｐｓｏｎ）、２００７０２５３５９４（Ｖｏｂｉｌｅ）、２００８０３１７２７８（Ｔｈｏｍｓｏｎ）、及び、２００２００４４６５９（ＮＥＣ）に詳述されている。
【０６７５】
簡潔さの法定要件に従いながら、包括的な開示を提供するため、出願人は、本明細書で参照された特許出願及び他の文献を参照により組み込む。（そのような資料は、それらの教示の特定のものに関連して上記で引用された場合であっても、それらの全体として組み込まれる。）これらの参考文献は、本明細書で詳述された構成に組み込むことができ、且つ、本明細書で詳述された技術及び教示がそれらに組み込まれうる、技術及び教示を開示している。読者は、そのような従来の研究に精通していると推定される。
［発明の例］
［例１］
ポータブルオーディオデバイス内で、オーディオコンテンツを表すオーディオデータを受信するステップと、
アルゴリズムを前記受信されたオーディオデータに適用して、識別データを導出するステップと、
前記導出された識別データを参照することによって、特定のソフトウェアプログラムを、前記オーディオコンテンツとともに使用するために選択するステップであり、前記選択するステップが、そのような行為を行うように構成される、前記ポータブルオーディオデバイス内のプロセッサによって行われる、ステップと、
前記選択されたソフトウェアプログラムを起動するステップと、
を含み、
前記オーディオデータとともに使用される前記特定のソフトウェアプログラムの選択が、前記オーディオデータから導出された識別データに基づく、方法。
［例２］
前記選択するステップが、前記オーディオコンテンツのための特定のレンダリングコーデックを、複数の可能なレンダリングコーデックの中から選択するサブステップを含む、例１に記載の方法。
［例３］
前記選択するステップが、前記導出された識別データを参照して、且つ、コンテキストデータをも参照して進行し、第１のソフトウェアプログラムが第１のコンテキスト内で選択され、第２のソフトウェアプログラムが第２のコンテキスト内で選択される、例１に記載の方法。
［例４］
前記コンテキストデータが年齢データを備える、例３に記載の方法。
［例５］
前記コンテキストデータが性別データを備える、例３に記載の方法。
［例６］
前記選択するステップの後、前記選択されたソフトウェアプログラムを、クラウドリポジトリから前記ポータブルオーディオデバイスへダウンロードするステップを含む、例１に記載の方法。
［例７］
前記ポータブルオーディオデバイスが、前記オーディオコンテンツとともに使用するためのソフトウェアプログラムを既に含むが、前記選択するステップが、異なるソフトウェアプログラムを識別し、前記方法が、前記異なるソフトウェアプログラムをダウンロードするステップと、前記異なるソフトウェアプログラムを起動するステップとを含む、例１に記載の方法。
［例８］
前記選択するステップが、複数の異なるソフトウェアプログラムを識別するサブステップと、前記識別されたソフトウェアプログラムのうちどれが、前記ポータブルオーディオデバイスのストレージ内で使用可能であるかをチェックするサブステップとを含む、例１に記載の方法。
［例９］
前記識別されたソフトウェアプログラムのうち２つ以上が、前記ポータブルオーディオデバイスのストレージ内で使用可能であることを発見するステップと、次いで、アルゴリズムに基づいて、前記使用可能なソフトウェアプログラムの間で自動的に選ぶステップとを含む、例８に記載の方法。
［例１０］
前記受信するステップが、前記ポータブルオーディオデバイスのマイクロフォンを使用して、周囲のオーディオを受信するサブステップを含む、例１に記載の方法。
［例１１］
ポータブルオーディオデバイス内で、オーディオコンテンツを表すオーディオデータを受信するステップと、
アルゴリズムを前記受信されたオーディオデータに適用して、識別データを導出するステップと、
前記導出された識別データを参照することによって、前記オーディオコンテンツとともに使用するために有利なソフトウェアプログラムを選択するステップであり、前記選択するステップが、そのような行為を行うように構成される、前記ポータブルデバイス内のプロセッサによって行われる、ステップと、
前記有利なソフトウェアプログラムをユーザに指示するステップと、
を含み、
前記オーディオデータとともに使用される前記有利なソフトウェアプログラムが、前記オーディオデータから導出された識別データに基づいて選択される、方法。
［例１２］
前記オーディオコンテンツとともに使用するためのソフトウェアプログラムを識別する、ユーザ入力を受信するステップと、
前記受信されたユーザ入力によって識別された前記ソフトウェアプログラムが前記有利なソフトウェアプログラムではない場合、前記識別されたソフトウェアプログラムを前記オーディオコンテンツとともに使用することを制限するステップと、
を含む、例１１に記載の方法。
［例１３］
ポータブルオーディオデバイス内で、オーディオコンテンツを表すオーディオデータを受信するステップであり、前記オーディオコンテンツが、前記ポータブルオーディオデバイス内の第１のソフトウェアによってレンダリングされうるタイプのものである、ステップと、
前記オーディオコンテンツを前記第１のソフトウェアによりレンダリングするための試みに応答して、前記ポータブルオーディオデバイスが、第２のソフトウェアが代わりに使用されるべきであることを指示するステップと、
を含み、
前記オーディオコンテンツの創作者が、その創作者のオーディオのために、前記第２のソフトウェアを好ましいものとして指定した、方法。
［例１４］
前記オーディオコンテンツを前記第１のソフトウェアによりレンダリングすることを拒否するステップを含む、例１３に記載の方法。
［例１５］
前記オーディオコンテンツを前記第１のソフトウェアとともに制限付きで使用することのみを可能にするステップを含む、例１３に記載の方法。
［例１６］
ポータブルデバイスのマイクロフォンにより、周囲環境からオーディオを受信するステップと、
アルゴリズムを前記受信されたオーディオを表すオーディオデータに適用して、識別データを導出するステップと、
前記導出された識別データを参照することによって、前記オーディオに関係する商取引のために使用されるべき、対応するフルフィルメントサービスを選択するステップと、
を含み、
第１の受信されたオーディオが、前記第１のオーディオに関係する商取引のために使用されるべき第１のフルフィルメントサービスの選択につながり、第２の異なる受信されたオーディオが、前記第２のオーディオに関係する商取引のために使用されるべき第２の異なるフルフィルメントサービスの選択につながる、方法。
［例１７］
ユーザの周囲環境内のオーディオを識別するステップであり、前記オーディオが、ユーザデバイスによって以前にサンプリングされている、ステップと、
前記識別されたオーディオについての情報を、ユーザコンテキスト情報とともに、パブリッシュするステップと、
前記パブリッシュされた情報に応答して、１つ又は複数の第三者入札を受信するステップと、
落札に関連付けられた第三者を決定するステップと、
前記決定された第三者により識別されたソフトウェアを有効化して、前記ユーザデバイス上で前記ユーザに購入機会を提示するステップと、
を含む、方法。
［例１８］
所与のタイプの受信されたコンテンツに対応する、デジタルデータのセットを受信するステップであり、前記タイプがオーディオ又はビデオを備える、ステップと、
前記受信されたコンテンツに対応する識別データを生成するステップであり、それにより、前記受信されたコンテンツが、前記所与のタイプの他のコンテンツとは区別されうる、ステップと、
前記識別データを参照することによって、前記受信されたコンテンツをレンダリングするためのＮ個の候補レンダリングエンジン（複数可）を、前記所与のコンテンツタイプのためのより多数の可能なレンダリングプログラムの中から決定するステップであり、但し、１＞＝Ｎである、ステップと、
前記受信されたコンテンツを、前記Ｎ個の候補レンダリングプログラム（複数可）のうち１つによりレンダリングするステップと、
を含み、
特定のレンダリングプログラムが、前記所与のコンテンツタイプのための複数の候補の中から、前記コンテンツを参照することによって決定される、方法。
［例１９］
Ｎ個の候補レンダリングエンジン（複数可）を決定するステップが、前記識別データ、及び、１つ又は複数のコンテキスト要素の両方に基づく、例１８に記載の方法。
［例２０］
前記コンテキスト要素（複数可）のうち１つが、前記コンテンツのレンダリングにおいて使用されるデバイスのタイプの識別を備える、例１９に記載の方法。
［例２１］
１つ又は前記コンテキスト要素（複数可）が、ロケーション関連情報を備える、例１９に記載の方法。
［例２２］
前記決定するステップが、
前記コンテンツの所有者によって提供された情報が格納されるデータ構造を調べるサブステップであり、前記情報が、前記Ｎ個のレンダリングプログラム（複数可）についての前記所有者のプリファレンスを指示する、サブステップを含み、
前記コンテンツの前記所有者に、前記コンテンツがレンダリングされるべき前記レンダリングプログラムを指定する特権が付与される、例１８に記載の方法。
［例２３］
前記所有者が、前記コンテンツの制作に関与した存在であり、単に前記コンテンツの配給者ではなく、前記コンテンツの前記配給者に、前記所有者に付与された前記特権が与えられない、例２２に記載の方法。
［例２４］
前記所有者が、前記コンテンツの制作に関与したアーティストである、例２２に記載の方法。
［例２５］
前記所有者が、前記コンテンツの少なくとも一部における著作権を保持する、例２２に記載の方法。
［例２６］
前記方法が、オーディオ又はビデオを表すデータを処理して、前記識別子を導出するステップを含み、特定のレンダリングプログラムが、前記所与のコンテンツタイプのための複数の候補の中から、オーディオ又はビデオを表すデータから導出された識別子に基づいて決定される、例１８に記載の方法。
［例２７］
Ｎ＞１であり、前記方法が、前記Ｎ個の候補レンダリングプログラムをユーザに結びつけるステップと、前記候補レンダリングプログラムのうち１つを使用するために選択する、ユーザ入力を受信するステップと、を含む、例１８に記載の方法。
［例２８］
ユーザデバイス内のマイクロフォンによって受信されたオーディオに対応する、デジタルデータのセットを受信するステップを含む、例１８に記載の方法。
［例２９］
所与のタイプの受信されたコンテンツに対応する、デジタルデータのセットを受信するステップであり、前記タイプがオーディオ、画像又はビデオを備える、ステップと、
前記受信されたコンテンツに対応する識別データを生成するステップであり、それにより、前記受信されたコンテンツが、前記所与のタイプの他のコンテンツとは区別されうる、ステップと、
前記識別データを参照することによって、前記受信されたコンテンツに関連付けられ、且つ、前記所与のタイプのすべての他のコンテンツに関連付けられない、Ｎ個のアプリケーションプログラム（複数可）を決定するステップであり、但し、Ｎが１又は複数である、ステップと、
前記決定されたアプリケーションプログラム（複数可）のうち１つ又は複数により、アクションを取るステップと、
を含む、方法。
［例３０］
前記アクションが、前記１つ又は複数の決定されたアプリケーションプログラム（複数可）を起動するサブステップを含む、例２９に記載の方法。
［例３１］
Ｎ個のアプリケーションプログラム（複数可）を決定するステップが、前記識別データ、及び、１つ又は複数のコンテキスト要素の両方に基づく、例２９に記載の方法。
［例３２］
前記コンテキスト要素（複数可）のうち１つが、前記コンテンツのレンダリングにおいて使用されるデバイスのタイプの識別を備える、例３１に記載の方法。
［例３３］
前記コンテキスト要素（複数可）のうち１つが、ロケーション関連情報を備える、例３１に記載の方法。
［例３４］
前記アクションが、前記決定されたアプリケーションプログラム（複数可）のうち１つ又は複数を前記ユーザに結びつけるサブステップと、前記決定されたアプリケーションプログラム（複数可）のうち１つ又は複数がインストール及び／又は起動されるべきであるかどうかについての入力を求めるサブステップと、を含む、例２９に記載の方法。
［例３５］
前記決定するステップが、オークションを実施して、前記Ｎ個のアプリケーションプログラム（複数可）のうち１つ又は複数を決定するサブステップを含む、例２９に記載の方法。
［例３６］
前記決定するステップが、
前記コンテンツの所有者によって提供された情報が格納されるデータ構造を調べるサブステップであり、前記情報が、前記Ｎ個のアプリケーションプログラム（複数可）についての前記所有者のプリファレンスを指示する、サブステップを含み、
前記コンテンツの前記所有者に、前記受信されたコンテンツに関連付けられるべき前記アプリケーションプログラム（複数可）を指定する特権が付与される、例２９に記載の方法。
［例３７］
前記所有者が、前記コンテンツの制作に関与した存在であり、単に前記コンテンツの配給者ではなく、前記コンテンツの前記配給者に、前記所有者に付与された前記特権が与えられない、例２９に記載の方法。
［例３８］
前記所有者が、前記コンテンツの制作に関与したアーティストである、例２９に記載の方法。
［例３９］
前記所有者が、前記コンテンツの少なくとも一部における著作権を保持する、例２９に記載の方法。
［例４０］
前記方法が、オーディオ、画像又はビデオを表すデータを処理して、前記識別子を導出するステップを含み、特定のアプリケーションプログラムが、前記所与のコンテンツタイプのための複数の候補の中から、オーディオ、画像又はビデオを表すデータから導出された識別子に基づいて決定される、例２９に記載の方法。
［例４１］
Ｎ＞１であり、前記方法が、前記Ｎ個の候補アプリケーションプログラムをユーザに結びつけるステップと、前記候補アプリケーションプログラムのうち１つをアクションのために選択する、ユーザ入力を受信するステップと、を含む、例２９に記載の方法。
［例４２］
ユーザデバイス内のマイクロフォンによって受信されたオーディオに対応する、デジタルデータのセットを受信するステップを含む、例２９に記載の方法。
［例４３］
オペレーティングシステム（ＯＳ）ソフトウェアが格納されているコンピュータ可読ストレージ媒体であって、
前記オペレーティングシステムソフトウェアは、ＯＳサービスを、定義されたインターフェースを通して、要求側アプリケーションプログラムに提供するように、プロセッサを構成する役目を果たし、
前記ＯＳサービスが、視覚又は聴覚の情報を表す信号データから、コンテンツ識別データを導出すること、及び、前記コンテンツ識別データを、定義されたインターフェースを通して、前記コンテンツ識別データをサブスクライブする１つ又は複数のアプリケーションプログラムによって使用するために、パブリッシュすること、を含む、コンピュータ可読ストレージ媒体。
［例４４］
前記導出することが、処理アルゴリズムを前記信号データに適用して、ビット削減コンテンツ識別データを生じることを含む、例４３に記載のコンピュータ可読ストレージ媒体。
［例４５］
前記導出することが、処理アルゴリズムを前記信号データに適用して、ビット削減コンテンツ識別データを生じること、及び、データストアにアクセスして、前記ビット削減コンテンツ識別データに対応するさらなる識別情報を得ること、を含む、例４３に記載のコンピュータ可読ストレージ媒体。
［例４６］
処理デバイスとメモリとを含む装置であって、
前記メモリがオペレーティングシステム（ＯＳ）命令を含み、該ＯＳ命令は、ＯＳサービスを、定義されたインターフェースを通して、要求側アプリケーションプログラムに提供するように、前記処理デバイスを構成し、
前記装置が、前記処理デバイスの環境から周囲の視覚及び／又は音の刺激を検知するためであり、且つ、それに対応するコンテンツデータを作り出すための、検知システムをさらに含み、
前記ＯＳサービスのうち１つが、前記作り出されたコンテンツデータからコンテンツ識別データを導出し、前記コンテンツ識別データを、定義されたインターフェースを通して、サブスクライブする要求側アプリケーションプログラムにパブリッシュする、装置。
［例４７］
処理デバイスとメモリとを含む装置であって、
前記メモリがオペレーティングシステム（ＯＳ）命令を含み、該ＯＳ命令は、ＯＳサービスを、定義されたインターフェースを通して、要求側アプリケーションプログラムに提供するように、前記処理デバイスを構成し、
前記定義されたインターフェースのうち１つがコンテンツ識別メッセージキューを提供し、該コンテンツ識別メッセージキューが前記デバイスによって処理された視覚又は音の刺激に対応するコンテンツ識別データをパブリッシュし、該コンテンツ識別メッセージキューを、１つ又は複数のアプリケーションプログラムがサブスクライブすることができる、装置。
［例４８］
前記装置が、前記装置の環境から周囲の視覚及び／又は音の刺激を検知するためであり、且つ、それに対応するコンテンツデータを作り出すための、検知システムをさらに含み、
前記コンテンツ識別メッセージキューが、前記装置の前記環境から検知された視覚又は音の刺激に対応するコンテンツ識別データを備えるメッセージを提供する、例４７に記載の装置。
［例４９］
ユーザの周囲環境から、延長された期間にわたって、音又は視覚の刺激をバックグラウンドで検知し、それにより、前記ユーザが前記期間中に曝されていたコンテンツに気付くステップと、
前記バックグラウンドで検知された刺激を参照することによって、構成されたハードウェアプロセッサを使用して、前記ユーザが前記期間中に曝されていたコンテンツのいくつかの異なる項目に対応するコンテンツ識別データを生成するステップと、
ユーザインターフェースとの後続のユーザインタラクションの過程で、前記ユーザに対して、タイトルによって、前記ユーザの環境から気付かれたコンテンツの複数の異なる項目を識別し、前記ユーザが、前記識別されたコンテンツの項目のうち少なくとも１つに対する複数の異なるアクションの中で選択できるようにするステップとを含む、方法。
［例５０］
ユーザの周囲環境から、音又は視覚の刺激を検知し、それにより、前記ユーザが曝されていたコンテンツに気付くステップと、
前記検知された刺激を参照することによって、構成されたハードウェアプロセッサを使用して、前記ユーザが曝されていたコンテンツの少なくとも１つの項目に対応するコンテンツ識別データを生成するステップと、
２つ以上の異なるソフトウェアアプリケーションを、前記生成されたコンテンツ識別データに少なくとも部分的に基づく情報により、用意するステップと、
を含み、
前記ユーザが次に、前記異なるソフトウェアアプリケーションの各々を利用するとき、前記ユーザは、前記異なるソフトウェアアプリケーションの各々が、前記ユーザが前記コンテンツの項目に曝されたことを既に反映することを、発見するようになる、方法。
［例５１］
３つ以上の異なるソフトウェアアプリケーションを、前記生成されたコンテンツ識別データに少なくとも部分的に基づく情報により、用意するステップを含む、例５０に記載の方法。
［例５２］
４つ以上の異なるソフトウェアアプリケーションを、前記生成されたコンテンツ識別データに少なくとも部分的に基づく情報により、用意するステップを含む、例５０に記載の方法。
［例５３］
前記用意するステップが、オーディオ若しくはビデオクリップ、又は画像をキャッシュするサブステップを含む、例５０に記載の方法。
［例５４］
消費者電子デバイスにより実施される方法であって、
オーディオ、画像及び／又はビデオコンテンツを表すコンテンツデータを受信するステップであり、以前にインストールされたか、又は他の方法で、前記デバイスとともに使用するために使用可能にされた、第１のソフトウェアレンダリングプログラムのために、前記電子デバイスがレンダリングしてコンテンツ関連体験を作り出すことが可能であるタイプのファイルフォーマットで、前記コンテンツデータが受信される、ステップと、
前記受信されたコンテンツデータを参照することによって、１つ又は複数のソフトウェアレンダリングプログラム（複数可）を決定するステップであって、該ソフトウェアレンダリングプログラム（複数可）は、前記受信されたコンテンツデータとともにコンテンツ関連ユーザ体験を作り出すために前記コンテンツデータの所有者によって規定される、ステップと、
前記決定されたソフトウェアレンダリングプログラムのいずれもが現在インストールされていないか、又は、前記デバイスとともに使用するために使用可能でないと決定するステップと、
前記可能な第１のソフトウェアレンダリングプログラムにもかかわらず、前記受信されたコンテンツデータを前記デバイス上でレンダリングすることを拒否するステップと、
を含み、
前記消費者電子デバイスが、それによりコンテンツ関連ユーザ体験が前記ユーザに配信されるべきである、前記ソフトウェアレンダリングプログラム（複数可）に関する、前記所有者の前記規定を尊重する、方法。
［例５５］
前記デバイスのユーザに情報を提示するステップであって、該情報は、前記所有者によって規定された前記ソフトウェアレンダリングプログラム（複数可）のうち１つ又は複数のインストールを前記ユーザが指図できるようにする、ステップをさらに含む、例５４に記載の方法。
［例５６］
前記所有者によって規定された１つ又は複数のソフトウェアレンダリングプログラム（複数可）を決定するステップが、１つ又は複数のコンテキスト要素にも基づく、例５４に記載の方法。
［例５７］
前記所有者によって規定された１つ又は複数のソフトウェアレンダリングプログラム（複数可）を決定するステップが、前記消費者電子デバイスのためのタイプ識別子の識別を備えるコンテキスト要素に基づく、例５６に記載の方法。
［例５８］
ユーザのデバイスを使用して、アートをレンダリングする方法であって、
前記アートが、その所有者によって作り出され、配給者によって配信されており、前記アートが、いくつかの異なるソフトウェアプログラムによってレンダリングされうるデータフォーマットで表され、
改良が、
プログラムされたプロセッサを使用して、所有者により指定されたメタデータを調べて、前記アートデータをレンダリングするために利用されうる前記プログラムのサブセットを決定するステップと、
前記サブセットのうち１つのプログラムにより前記アートデータをレンダリングするステップと
を含み、
前記所有者に、前記アートがどのようにレンダリングされるかについての、ある程度の制御権が与えられる、方法。
［例５９］
前記所有者に、前記アートがどのようにレンダリングされるかの、前記配給者よりも大きい制御権が与えられる、例５８に記載の方法。
［例６０］
処理デバイスと、前記処理デバイスを構成するための複数のソフトウェアプログラムを格納するコンピュータ可読ストレージ媒体と、装置の環境内の周囲の視覚又は音のコンテンツを表すデータを生成するための検知システムとを含む、装置であって、
前記ソフトウェアプログラムのうち少なくとも１つが、前記コンピュータ可読ストレージ媒体に、前記装置が前記装置の環境からある周囲のコンテンツを検知する結果として、格納される、装置。
［例６１］
前記ソフトウェアプログラムのうち少なくとも第１及び第２のものが、前記コンピュータ可読ストレージ媒体に、それぞれ、前記装置が前記装置の環境から第１及び第２の周囲のコンテンツを検知する結果として、格納される、例６０に記載の装置。
［例６２］
プロセッサとメモリとを含むスマートフォンであって、前記メモリが、オペレーティングシステムソフトウェアと、複数のアプリケーションプログラムとを含み、
前記アプリケーションプログラムのうち第１のものが、音又は視覚のコンテンツを表すデータを解析して、対応する識別データを作り出し、そのような解析の結果を出力にパブリッシュする役目を果たし、
前記アプリケーションプログラムのうち第２のものが、前記第２のアプリケーションプログラムが調和するあるコンテンツについて、前記第１のアプリケーションプログラムの前記出力を監視し、前記あるコンテンツが気付かれるとき、アクションを取る役目を果たす、スマートフォン。
［例６３］
前記アプリケーションプログラムのうち第３のものが、前記第３のアプリケーションプログラムが調和するあるコンテンツについて、前記第１のアプリケーションプログラムの前記出力を監視し、前記あるコンテンツが気付かれるとき、アクションを取る役目を果たす、例６２に記載のスマートフォン。
［例６４］
前記第３のアプリケーションプログラムが、前記第２のアプリケーションプログラムが前記出力を監視する同じコンテンツについて、前記第１のアプリケーションプログラムの前記出力を監視する、例６３に記載のスマートフォン。
［例６５］
前記第３のアプリケーションプログラムが、前記第２のアプリケーションプログラムが前記出力を監視するコンテンツとは異なるコンテンツについて、前記第１のアプリケーションプログラムの前記出力を監視する、例６３に記載のスマートフォン。
［例６６］
見る姿勢から被写体の画像を取り込み、前記取り込まれた画像をポータブルデバイスの画面上に提示するステップと、
前記見る姿勢の最適性を、前記取り込まれた画像を参照することによって評価するステップと、
前記取り込まれた画像の提示上に、前記評価の結果を指示するしるしをオーバーレイするステップと、
を含み、
前記オーバーレイされたしるしが、前記評価された最適性の変化とともに変化する、方法。
［例６７］
前記オーバーレイされたしるしのぼけ度（ｂｌｕｒｒｉｎｅｓｓ）が、前記評価された最適性の変化とともに変化する、例６６に記載の方法。
［例６８］
ポータブルデバイスを使用して、画像の複数のフレームを取り込むステップであり、前記ポータブルデバイスが、画像センサ及び第２のセンサを有する、ステップと、
前記取り込まれたフレームのうち少なくとも２つのサブセットを、前記第２のセンサからのデータに基づいて選択するステップと、
前記選択されたフレームを結合するステップと、
を含む、方法。
［例６９］
前記取り込まれたフレームの選択されたサブセット内の、対応する顕著点を見極めるステップと、
結合するステップより前に、前記選択されたフレームのうち少なくとも第１のものを変換するステップであって、
前記変換するステップが、
前記２つのフレーム内の対応する顕著点間の距離のヒストグラムを参照することによって、参照フレームに対する前記第１のフレームのためのスケール係数を推定するサブステップと、
その後、前記参照フレームに対する前記第１のフレームのためのｘ及びｙにおける変換を推定するサブステップと、
を含む、ステップと、
をさらに含む、例６８に記載の方法。
［例７０］
前記方法が、重み付け係数を、前記フレームの選択されたサブセットのうち少なくとも１つに適用するステップであって、前記重み付け係数が前記第２のセンサからのデータに基づく、ステップを含む、例６８に記載の方法。
［例７１］
プロセッサと、メモリと、少なくともカメラ及びマイクロフォンを含む複数のセンサとを含む、スマートフォンデバイスであって、
前記要素が協働して複数の認識エージェントを定義し、該認識エージェントがオーディオフィンガープリント認識エージェント、バーコード認識エージェント、及び、画像ウォーターマーク認識エージェントを含み、
前記エージェントが、前記メモリのブラックボードデータ構造からデータを読み取り、且つ、前記メモリの前記ブラックボードデータ構造へデータを書き込むように構成され、
前記ブラックボードデータ構造が、前記センサからデータを受信し、且つ、前記エージェントが処理する格納された画像データ及びオーディオデータのキューを編集するように構成され、
前記要素が、前記メモリ内の命令によって定義されたイベントコントローラの制御下で協働する、スマートフォンデバイス。
［例７２］
前記認識エージェントのうち複数が、機能を行うために必要とされるリソースコストを推定するとともに、そのような機能によって達成されうる結果の品質を推定するように、並びに、そのような推定値を前記ブラックボード構造に格納するように、それぞれ構成され、
前記イベントコントローラが、複数の認識エージェントからのそのような格納された推定値を評価するとともに、それに基づいて、どの認識エージェント（複数可）をアクティベートするべきかを決定するように構成される、例７１に記載のスマートフォンデバイス。
［例７３］
前記スマートフォンデバイスが、前記ブラックボードデータ構造を監視するとともにコンテキストのデータを推測するように構成された推測エンジンをさらに含み、
前記イベントコントローラが、どの認識エージェント（複数可）をアクティベートするべきかを決定することにおいて、前記コンテキストのデータを使用するように構成される、例７１に記載のスマートフォンデバイス。
［例７４］
前記デバイスが、オーディオ及び画像ストリームを別々のスレッド内で処理するように構成され、各認識エージェントがそれ自体のスレッド内で実行するように構成される、例７１に記載のスマートフォンデバイス。
［例７５］
前記センサが、加速度計をさらに含み、
前記デバイスが、画像を取り込み、それに関係付けられた輝度値を決定し、前記画像に関連付けられた加速度を評価し、前記画像の彩度を評価し、それに基づいて、画像品質を評価し、その後、前記評価された画像品質に基づいて、ウォーターマーク読み取り動作を前記画像上で呼び出すかどうかを決定するように構成される、例７１に記載のスマートフォンデバイス。
［例７６］
人と複数のオブジェクトの間のネットワーク関係を決定するステップと、
前記ネットワーク関係から、前記人にとってのオブジェクトの相対的重要性を見極めるステップと、
前記見極められた相対的重要性に基づいてアクションを取るステップと、
を含む、方法。
［例７７］
前記見極められた相対的重要性に基づいてデータを処理するステップと、
結果として生じる処理されたデータのセットを前記人に提示するステップと、
を含む、例７６に記載の方法。
［例７８］
前記処理するステップが、前記人への提示のために、前記見極められた相対的重要性に基づいて、より大きいコンテンツのセットの中からコンテンツのサブセットを選択するサブステップを含む、例７７に記載の方法。
［例７９］
ネットワーク関係を決定するステップが、前記人によって操作されたデバイスによって取り込まれた画像を解析するサブステップを含む、例７６に記載の方法。
［例８０］
ポータブルデバイスにより、人の手のジェスチャーの画像を取り込むステップと、
前記画像を処理して、前記ジェスチャーから手話を見極めるステップと、
前記見極められた手話に基づいて、アクションを取るステップと、
を含む、方法。
［例８１］
第１及び第２の空間周波数部分を有する情報搬送パターンを定義するステップと、
前記パターンを基層上にプリントするステップと、
を含み、
前記第１の部分が、見る人に、符号化された情報の存在への合図を出す、可視バックグラウンド織り込みパターンを定義し、
前記第２の部分が、人間の視覚の範囲を超える空間周波数を備え、前記符号化された情報のうち、少なくとも特定のものを搬送する、方法。
［例８２］
第１のデバイス内で、ペイロードデータを有するオーディオ又は画像のコンテンツデータを受信するステップであって、前記ペイロードデータがデジタルウォーターマーキングによって符号化されている、ステップと、
前記ペイロードデータを、前記受信されたコンテンツデータから復号するステップと、
前記ペイロードデータの少なくとも一部を、デジタルウォーターマーキング以外の技法によって、第２のデバイスへ送信するステップと、
を含む、方法。
［例８３］
前記技法が、ブルートゥース、ＩＲ、ＷｉＦｉ又はＮＦＣなど、ワイヤレス送信技法を含む、例８２に記載の方法。
［例８４］
ホームエンターテインメントシステム内で、オーディオ又は画像のコンテンツを受信し、メディアフィンガープリント情報を決定するステップと、
前記メディアフィンガープリント情報を、前記コンテンツが前記ホームエンターテインメントシステムによってレンダリングされているユーザのスマートフォンへ、ワイヤレスで送信するステップと、
を含む、方法。
［例８５］
前記決定するステップが、メディアフィンガープリントデータを決定するサブステップと、前記をリモートサーバへ送信するサブステップと、応答において、対応するメディアフィンガープリント情報を受信するサブステップと、を含む、例８４に記載の方法。
［例８６］
小売店内で、前記店内の買物客による製品関心を指示する信号を受信するステップと、
前記受信された信号に基づいてアクションを取るステップであり、
前記アクションが、
前記買物客をサービスのためのキューに入れるサブステップと、
前記買物客にサービスのための待ち時間を知らせるサブステップと、
前記買物客に、サービスを提供するようになる小売店スタッフについての情報を提供するサブステップと、
前記買物客に、サービスを待つように誘い物を提供するサブステップとのうち、少なくとも１つを含む、ステップと、
を含み、前記誘い物が、そうでない場合は料金が課されるはずのエンターテインメントコンテンツを備える、方法。
［例８７］
前記アクションが、前記買物客を、サービスのためのキュー内で、前記キューにより早く入った１人又は複数の他の買物客より前に入れるサブステップを含む、例８６に記載の方法。
［例８８］
買物客のスマートフォンによって、小売店内に陳列された第１の製品から検知されたデータを参照することによって、第２の製品が前記第１の製品と互換性を有するかどうかを判定するステップと、
前記判定に基づいてアクションを取るステップと、
を含む、方法。
［例８９］
デジタルウォーターマーキングされたオブジェクトから画像を取り込むステップであり、前記デジタルウォーターマークが、既知の参照特徴を含む、ステップと、
前記既知の参照特徴をぼけカーネルの推定において使用するステップであって、前記取り込まれた画像が前記ぼけカーネルにより処理されて画像ぼけが低減されうる、と、
を含む、方法。
［例９０］
フーリエドメイン内で前記既知の参照特徴を見極めるステップを含む、例８９に記載の方法。
［例９１］
前記デジタルウォーターマークが、前記フーリエドメイン内の画像統計値データをも搬送し、前記方法が、
前記画像から前記画像統計値データを見極めるステップと、
前記画像統計値データを、前記ぼけカーネルの推定において使用するステップと、
を含む、例９０に記載の方法。
［例９２］
ユーザのスマートフォンによって検知された情報を参照することによって、前記ユーザの関心を決定するステップと、
前記決定された関心に基づいてアクションを取るステップと、
を含む、方法。
［例９３］
前記アクションが、前記ユーザへの提示のために、前記決定された関心に基づいて、より大きいコンテンツのセットの中から、コンテンツのサブセットを選択するサブステップを含む、例９２に記載の方法。
［例９４］
前記ユーザのスマートフォンによって取り込まれた画像を参照することによって、前記ユーザの関心を決定するステップを含む、例９２に記載の方法。
［例９５］
前記ユーザのスマートフォンによって検知されたジオロケーション情報を参照することによって、前記ユーザの関心を決定するステップを含む、例９２に記載の方法。
［例９６］
ユーザが選択することができる、ポータブルデバイスの画面上のテキスト文字の配列を表示するステップと、
前記画面の一部分に向かうユーザの凝視を検知して、テキスト選択を行うステップと、
前記ユーザが次に選択することができる、前記画面上の前記文字の配列を変更するステップと、
を含む、方法。
［例９７］
スマートフォンカメラを使用して、画像データのビデオシーケンスを取り込むステップと、
前記取り込まれたデータ内で第１のマシン可読シンボロジーを識別するステップと、
前記第１の識別されたシンボロジーに関係付けられた情報を格納するステップと、
前記取り込まれたデータ内で第２のマシン可読シンボロジーを識別するステップと、
前記第２の識別されたシンボロジーに関係付けられた情報を格納するステップと、
を含み、
前記スマートフォンが、ストリーミングモードで動作して、前記取り込まれたビデオシーケンス内で発見されたマシン可読シンボロジーに関係付けられた情報を収集する、方法。
［例９８］
プロセッサと、メモリと、１つ又は複数のセンササブシステムと、タッチスクリーンとを備える、システムにおいて、
前記デバイスが、第１のセンササブシステムからの情報を、前記メモリ内にＲＤＦトリプルとして格納するように構成され、前記プロセッサが、前記格納されたＲＤＦトリプルに基づいて、アクションを取るように構成されることを特徴とする、システム。
［例９９］
前記第１のセンササブシステムが、カメラと、マイクロフォンと、加速度計と、ＧＰＳ受信機と、ワイヤレス信号センサと、近距離無線チップリーダと、画像分類器と、ユーザアクティビティセンサとからなるグループから選択される物理センサ又は論理センサを含む、例９８に記載のシステム。
［例１００］
前記第１のセンササブシステムが、前記検知された情報に対応するデータを、ＲＤＦトリプルとして出力するように構成される、例９８に記載のシステム。
［例１０１］
センサデータを受信するステップと、
前記検知された情報を、格納のためにＲＤＦトリプルとして表すステップと、
前記格納されたＲＤＦトリプルを処理するステップと、
を含む、方法。
［例１０２］
センサデータを受信するステップが、第１のユーザによって運ばれる第１のデバイス内のセンサを使用して、検知するサブステップを含む、例１０１に記載の方法。
［例１０３］
前記ＲＤＦトリプルを、前記デバイスとは別個のコンピュータ内に格納するステップを含む、例１０２に記載の方法。
［例１０４］
前記処理するステップが、第２の異なるユーザによって運ばれる第２のデバイスを使用して、前記格納されたＲＤＦトリプルを処理するサブステップを含む、例１０３に記載の方法。
［例１０５］
前記処理するステップが、前記ユーザによって運ばれる第１のデバイスによって行われ、センサデータを受信する前記ステップが、前記第１のデバイスとは別個である第２のデバイスからセンサデータを受信するサブステップを含む、例１０１に記載の方法。
［例１０６］
前記検知された情報が画像を備える、例１０１に記載の方法。
［例１０７］
ピクセルデータを、格納のためにＲＤＦトリプルとして表すステップを含む、例１０６に記載の方法。
［例１０８］
カメラと、プロセッサと、メモリとを備える、デバイスであって、前記メモリが、前記カメラによって取り込まれた画像のセットを格納し、前記メモリが、前記画像のセットについてのアサーションを作成する複数のＲＤＦトリプルをも格納し、前記プロセッサが、前記格納されたＲＤＦトリプルのうち１つ又は複数を参照することによって、前記格納された画像のセットにおいて演算を行うように構成される、デバイス。
［例１０９］
第１のコンピュータ処理が、１つ又は複数の他のコンピュータ処理からのサービスを要求するための方法であって、前記方法が、要求をデータ構造に投稿するステップであって、前記要求がＲＤＦトリプルとして表現される、ステップを含む、方法。
［例１１０］
前記データ構造が、ブラックボードデータ構造を備える、例１０９に記載の方法。
［例１１１］
第２の処理が、特定のタイプのＲＤＦトリプルを求めて前記データ構造を検索するクエリを実行するステップと、そのようなトリプルが発見されるときアクションを取るステップと、をさらに含む、例１０９に記載の方法。
［例１１２］
前記クエリが、ＳＰＡＲＱＬクエリを備える、例１１１に記載の方法。
［例１１３］
オーディオ情報を消費者電子デバイスで受信するステップであり、前記オーディオ情報がコンテンツ配給者によって用意されており、前記受信されたオーディオ情報が少なくとも第１及び第２のオーディオトラックを含む、ステップと、
前記デバイス内で、前記第１及び第２のトラック間の比を設定する、制御信号を受信するステップと、
前記オーディオ情報を、前記比に従って消費者にレンダリングするステップと、を含み、
前記第２のオーディオトラックが、補助情報を搬送する、雑音のようなデジタルウォーターマーク信号を備える、方法。
［例１１４］
前記第１及び第２のトラック間の比を設定する、消費者により操作されるコントロールからの信号を受信するステップを含む、例１１２に記載の方法。
［例１１５］
前記制御信号が、前記第２のトラックがレンダリングされない比を設定する、例１１２に記載の方法。
［例１１６］
第１のデバイスによってレンダリングされる場合、第２のデバイスの機能を制御する、第１のコンテンツデータを含む、コンピュータ可読媒体であって、
前記コンテンツデータが、オーディオ情報の少なくとも第１及び第２のトラックを含み、
前記第１のトラックが、消費者の楽しみのためのオーディオを備え、
前記第２のトラックが、前記第２のデバイスのための制御データを搬送する、雑音のようなデジタルウォーターマーク信号を備える、コンピュータ可読媒体。
［例１１７］
前記オーディオ情報の第１及び第２のトラックが、ドルビートゥルーＨＤフォーマットで格納される、例１１６に記載の媒体。
［例１１８］
コンテンツ情報を格納するメモリであり、前記コンテンツ情報が、オーディオの少なくとも第１及び第２のトラックに対応するデータを含む、メモリと、
前記コンテンツ情報を出力デバイスにレンダリングするためのオーディオ部であり、前記オーディオ部が、前記第２のトラックが前記第１のトラックに対してレンダリングされるべきであるレベルを設定するために、ユーザによって操作可能なコントロールを含む、オーディオ部と、
を備え、
前記オーディオの第２のトラックに対応する前記格納されたデータが、第２の装置の機能を制御するための、雑音のようなデジタルウォーターマーク信号を表す、装置。
［例１１９］
前記オーディオ部が、前記オーディオの第１及び第２のトラックを単一のチャネル内で結合するためのミキサをさらに備える、例１１８に記載の装置。
［例１２０］
前記オーディオの第２のトラックに対応する前記格納されたデータが、ＲＦ６４フォーマットでフォーマットされる、例１１８に記載の装置。
［例１２１］
カメラを装備したポータブルデバイスによって取り込まれた画像に対応する第１のセットのデータを受信するステップであり、前記画像が被写体を描く、ステップと、
ステガノグラフィ的に符号化されたデジタルウォーターマークペイロードデータを、前記第１のセットのデータから復号するステップと、
前記ペイロードデータを参照することによって、第２のセットのデータを得るステップと、
を含み、
前記第２のセットのデータが、前記被写体に対応する顕著点データを備える、方法。
［例１２２］
前記顕著点データの使用を通して、前記被写体に対する前記ポータブルデバイスのロケーションを決定するステップをさらに含む、例１２１に記載の方法。
［例１２３］
前記顕著点データの使用を通して、前記被写体に対する前記デバイスの位置を詳述する３Ｄ姿勢情報を決定するステップをさらに含む、例１２１に記載の方法。
［例１２４］
前記顕著点データの使用を通して、前記画像内に描かれた前記被写体の下位部分（ｓｕｂ−ｐａｒｔ）を識別するステップを含む、例１２１に記載の方法。
［例１２５］
前記識別された下位部分を参照することによって、第３のセットのデータを得るステップであり、前記第３のセットのデータが、前記被写体の前記下位部分に関する、ユーザへの情報の表示を提示するために有用な補助データを含む、ステップを含む、例１２４に記載の方法。
［例１２６］
前記顕著点データに従って、前記ポータブルデバイスの画面上に提示されたグラフィカルな特徴のサイズ決定又は位置決めをするステップをさらに含む、例１２１に記載の方法。
［例１２７］
前記顕著点データに基づいて前記デバイスの動作を制御するステップをさらに含む、例１２１に記載の方法。
［例１２８］
コンピューティングデバイスによって実行される場合、
被写体を描く画像に対応する第１のセットのデータを受信すること、
ステガノグラフィ的に符号化されたデジタルウォーターマークペイロードデータを、前記第１のセットのデータから復号すること、及び
前記ペイロードデータを参照することによって、第２のセットのデータを得ること
を含む動作を前記コンピューティングデバイスに行わせるソフトウェア命令を含み、
前記第２のセットのデータが、前記被写体に対応する顕著点データを備える、コンピュータ可読媒体。
［例１２９］
前記動作が、前記第２のセットのデータに基づいて前記デバイスの動作を制御することをさらに含む、例１２８に記載のコンピュータ可読媒体。
［例１３０］
ポータブルデバイス内で、オブジェクトに関連付けられたパッシブチップデバイスから検知された識別データを受信するステップと、
前記識別データを参照することによって、第２のセットのデータを得るステップと、
を含み、
前記第２のセットのデータが、前記オブジェクトに対応する顕著点データを備える、方法。
［例１３１］
前記ポータブルデバイスが、前記パッシブチップデバイスから前記識別データを検知するステップをさらに含む、例１３０に記載の方法。
［例１３２］
前記オブジェクトがポスターを備える、例１３０に記載の方法。
［例１３３］
前記第２のセットのデータが、前記オブジェクトに関連付けられた基準位置データをさらに備え、
前記方法が、前記基準位置データ及び前記顕著点データを参照することによって、前記ポータブルデバイスについての位置データを決定するステップを含み、前記デバイスのユーザが、位置依存の方法で前記オブジェクトとインタラクトすることができる、例１３０に記載の方法。
［例１３４］
前記識別データが、前記オブジェクトに関連付けられた基準位置データを含み、
前記方法が、前記基準位置データ及び前記顕著点データを参照することによって、前記ポータブルデバイスについての位置データを決定するステップを含み、前記デバイスのユーザが、位置依存の方法で前記オブジェクトとインタラクトすることができる、例１３０に記載の方法。
［例１３５］
前記ポータブルデバイスについての第１の位置データが決定されているとき、前記デバイスの画面上に、第１のセットの情報を提示するステップと、
前記ポータブルデバイスについての第２の位置データが決定されているとき、前記デバイスの前記画面上に、第２の異なるセットの情報を提示するステップと、
を含む、例１３３に記載の方法。
［例１３６］
ポケットサイズのハウジング内に配置された、メモリ及び処理部を備えており、
前記メモリが第１の部分を含み、前記第１の部分が、複数のコードベースのセマンティックトリプルを表すコードデータを格納し、前記トリプルの各々が、第１、第２及び第３のコードを含み、前記コードのうち１つが主部コードであり、前記コードのうち１つが述部コードであり、前記コードのうち１つが目的部コードであり、
前記メモリがさらに第２の部分を含み、前記第２の部分が、異なるテキストリテラルを別々の前記コードに関連付けるリテラルデータを格納し、
前記処理部がＧＰＵを含み、該ＧＰＵが、前記メモリの前記第１の部分内のコードデータを処理して、前記メモリの前記第２の部分内の前記テキストリテラルによって表された情報において演算を行う、ポータブルデバイス。
［例１３７］
前記演算が、セマンティックな推論演算を含み、それにより、前記処理部が、前記リテラルデータとともに前記セマンティックトリプルによってアサートされた事実に基づいて、論理的帰結を推測する、例１３６に記載のデバイス。
［例１３８］
前記デバイスが、表示画面をさらに含み、前記メモリの前記第１の部分が、前記表示画面のピクセル寸法にマッチするストレージ寸法を有するフレームバッファを備えて、グラフィックスとともに使用するために知られているフレームバッファ技術が、セマンティックトリプルとともに使用するために適用されるようになる、例１３６に記載のデバイス。
［例１３９］
前記処理部が、前記セマンティックな推論の結果を、前記フレームバッファ内に、追加のセマンティックトリプルとして格納するように構成される、例１３８に記載のデバイス。
［例１４０］
前記メモリの前記第１の部分が、任意の編成を有するのではなく、２Ｄ構成を有し、空間的局所性とともに編成され、
同じ第１のコードを含むトリプルがともにグループ化され、前記メモリの前記第１の部分内で隣り合っているロケーションに格納されて、前記処理部が、空間的局所性に依拠するＧＰＵ機能性をより良く採用することができるようになる、例１３６に記載のデバイス。
［例１４１］
前記第１のコードが主部コードを備える、例１４０に記載のデバイス。
［例１４２］
同じ第１のコードを含むトリプルがそれらの第２のコードの順序によってさらに編成されて、処理が容易になる、例１４０に記載のデバイス。
［例１４３］
前記第１のコードが主部コードを備え、前記第２のコードが述部コードを備える、例１４２に記載のデバイス。
［例１４４］
前記メモリの前記第１の部分が、主部コードとして格納される第１のコードの第１のインスタンスを含み、目的部コードとして格納される前記第１のコードの第２のインスタンスをも含み、前記第１のコードの両方のインスタンスが、前記メモリの前記第２の部分に格納されたデータによって、同じテキストリテラルに関連付けられる、例１３６に記載のデバイス。
［例１４５］
前記メモリが、ルールデータを格納する第３の部分をさらに含み、前記処理部が、前記ルールデータを前記セマンティックトリプルに適用して、以前に表現されていない情報を見極めるように構成される、例１３６に記載のデバイス。
［例１４６］
ポケットサイズのハウジング内に配置された、メモリ及び処理部を備えており、
前記メモリがフレームバッファ部を含み、前記フレームバッファ部が、複数のコードベースのセマンティックトリプルを表すコードデータを格納し、各トリプルが、主部コード、述部コード、及び目的部コードを備え、
前記メモリがさらに第２の部分を含み、前記第２の部分が、異なるテキストリテラルを別々の前記コードに関連付けるリテラルデータを格納し、
前記処理部がＧＰＵを含み、前記ＧＰＵが、前記メモリの前記第１の部分内のコードデータを処理して、前記メモリの前記第２の部分内の前記テキストリテラルを使用して表現された概念を含むセマンティックな推論を行う、ポータブルデバイス。
［例１４７］
ポケットサイズのハウジング内に配置された、メモリ及び処理部を備えており、
前記処理部は前記メモリ内に格納された命令によって構成され、前記処理部がＧＰＵを含み、
前記メモリは複数のコードベースのセマンティックトリプルを表すコードデータを格納し、各トリプルが、主部コード、述部コード、及び目的部コードを備え、
前記命令は、前記処理部が一連のテンプレートを前記格納されたコードデータに適用して前記トリプルに基づいて演算を行うように、前記処理部を構成する、ポータブルデバイス。
［例１４８］
前記命令は、前記処理部が前記一連のテンプレートを前記格納されたコードデータに適用して前記トリプルに基づいてセマンティックな推論を行うように、前記処理部を構成する、例１４７に記載のデバイス。
［例１４９］
カメラを装備したポータブルデバイスによって取り込まれた画像に対応するデータのセットを受信するステップであり、前記画像が被写体を描く、ステップと、
前記受信されたデータのセットに基づいて、識別データを決定するステップと、
前記識別データを参照することによって、第２のセットのデータを得るステップであり、前記第２のセットのデータが、複数のＮ−タプルを備え、各々が、主部、述部及び目的部要素を含む、ステップと、
前記Ｎ−タプルを処理するステップと、
前記処理に基づいてアクションを取るステップと、
を含む、方法。
［例１５０］
ポケットサイズのハウジング内に配置された、タッチスクリーン、メモリ及び処理部を備えており、
前記メモリは、複数のコードベースのセマンティックトリプルを表すデータを含み、各トリプルが、主部コード、述部コード、及び目的部コードを備えており、
前記メモリは、別々の前記コードのためのそれぞれのテキストの意味を指示する、テキストリテラルを含む部分をさらに備え、
前記メモリは、ソフトウェア命令をさらに含み、前記命令は、前記処理部が、前記タッチスクリーン上で前記テキストリテラルのうち特定のものがポピュレートされるユーザインターフェースを提示し、該ユーザインターフェースを通してユーザが前記コードベースのセマンティックトリプルのクエリを定義することができるように、前記処理部を構成する、ポータブルデバイス。
［例１５１］
ポケットサイズのハウジング内に配置された、タッチスクリーン、メモリ及び処理部を備えており、
前記メモリは、複数のデータＮ−タプルを含む、ストレージの複数のプレーンとして論理的に編成され、前記Ｎ−タプルの要素がテキストリテラルに対応し、
前記処理部がＧＰＵを含み、前記ＧＰＵは、タッチスクリーンユーザインターフェースを介して入力されたユーザクエリに応答することの一部として、前記データＮ−タプルにおいて演算するように構成されている、ポータブルデバイス。
［例１５２］
ユーザクエリに対応するデータを受信するステップと、
第１のプレーン閾値処理テストを、Ｎ−タプルデータストアの１つのプレーン内に格納された値に適用するステップであり、前記データストアが、複数のデータＮ−タプルを格納するデータのＮ個のプレーンを備えるように論理的に編成され、但し、Ｎが少なくとも３であり、前記プレーン閾値処理テストが、前記ユーザクエリの第１の態様を満たす、前記格納されたデータＮ−タプルの第１のサブセットを識別する、ステップと、
前記ユーザクエリの結果を前記ユーザに提示するステップと、
を含む、方法。
［例１５３］
１つ又は複数のテキストリテラルに基づくユーザクエリに対応するデータを受信するステップと、
前記１つ又は複数のテキストリテラルを、１つ又は複数の対応するデータコードにマッピングするステップと、
前記データコードのうち１つを、前記第１のプレーン閾値処理テストにおいて使用するステップと、
を含む、例１５２に記載の方法。
［例１５４］
第２のプレーン閾値処理テストを、前記データＮ−タプルの第１の識別されたサブセット内の値に適用して、前記ユーザクエリの第２の態様を満たす、データＮ−タプルのさらなるサブセットを識別するステップをさらに含む、例１５２に記載の方法。
［例１５５］
１つ又は複数のさらなるプレーン閾値処理テストを、データＮ−タプルの以前に識別されたサブセットに適用して、前記ユーザクエリのさらなる態様を満たす、データＮ−タプルの１つ又は複数のさらなるサブセットを連続して識別するステップを含む、例１５４に記載の方法。
［例１５６］
前記ユーザクエリの結果を前記ユーザに提示するステップが、テンプレートを１つ又は複数のテキストリテラルでポピュレートするサブステップを含み、前記複数のテキストリテラルが、１つ又は複数のデータＮ−タプルの識別されたサブセットからの１つ又は複数の値に対応する、例１５２に記載の方法。
［例１５７］
カメラを装備したポータブルデバイスによって取り込まれた画像に対応する第１のセットのデータを受信するステップであり、前記画像が、第１の解像度で被写体を描く、ステップと、
前記第１のセットのデータに基づいて、識別データを決定するステップと、
前記識別データを参照することによって、第２のセットのデータを得るステップであり、前記第２のセットのデータが、前記被写体を描く画像に対応する、ステップと、
を含み、
前記第２のセットのデータが、前記第１のセットのデータとは異なる視点から前記被写体を描き、前記第１の解像度よりも高い第２の解像度で前記被写体を描く、方法。
［例１５８］
オブジェクトから検知されたＮＦＣ識別データを受信するステップと、
前記識別データを参照することによって、画像データのセットを得るステップであり、前記画像データが前記オブジェクトを描く、ステップと、
前記画像データに対応する画像を、ポータブルデバイスのタッチスクリーン上に提示するステップと、
を含む、方法。
［例１５９］
前記方法が、
ユーザ入力を前記タッチスクリーン上で受信するステップと、
前記ユーザ入力に基づいて、アクションを取るステップと、
をさらに含み、
前記ユーザが前記提示された画像を第１のロケーションでタッチする場合、前記アクションが第１のアクションを備え、前記ユーザが前記提示された画像を第２の異なるロケーションでタッチする場合、前記アクションが第２の異なるアクションを備える、例１５８に記載の方法。
［例１６０］
第１及び第２のデバイス間でアプリケーション状態を転送するための方法であって、前記デバイスがそれぞれプロセッサと表示画面とを含み、前記方法が、
前記第１のデバイス内のカメラを使用して、前記第２のデバイスの表示画面上に提示された画像を検知するステップと、
デジタルウォーターマークデータを、前記検知された画像から復号するステップと、
前記復号されたデジタルウォーターマークデータに基づいて、格納されたデータを識別するステップであって、該格納されたデータが前記第２のプロセッサのアプリケーション状態をメモリアライズする、ステップと、
前記格納されたデータを使用して、前記第２のプロセッサを前記アプリケーション状態に初期化するステップと、
を含む、方法。
［例１６１］
前記格納されたデータを使用して、前記ポータブルデバイス内のプロセッサを前記アプリケーション状態に初期化するステップを含む、例１６０に記載の方法。
［例１６２］
プロセッサと表示画面とを含むデバイスを使用する方法であって、
アプリケーション状態データを時折格納するステップと、
画像をデジタルウォーターマーキングして、その中の識別子を符号化するステップであり、前記識別子が、前記格納されたアプリケーション状態データへのアクセスを容易にする、ステップと、
前記デジタルウォーターマーキングされた画像を前記表示画面上に提示するステップと、
を含む、方法。
［例１６３］
ポータブルデバイス内のカメラを使用して、光を検知するステップと、
前記検知された光から、識別子を復号するステップと、
前記復号された識別子に基づいて、情報を得るステップと、
を含む、方法。
［例１６４］
前記得るステップが、前記復号された識別子に基づいて小売店内のロケーションを決定するサブステップを含む、例１６３に記載の方法。
［例１６５］
前記得るステップが、前記復号された識別子に基づいて街路上のビルの番号を決定するサブステップを含む、例１６３に記載の方法。
［例１６６］
前記得るステップが、前記復号された識別子に基づいて車道上で接近する車両の速度を決定するサブステップを含む、例１６３に記載の方法。
［例１６７］
動いている車両の速度及び／又は方向を検知するステップと、
前記検知された情報が符号化されている信号を生成するステップと、
前記信号に従って、前記車両の１つ又は複数のヘッドライトを制御するステップと、
を含む、方法。
［例１６８］
照明器具によって照明された環境からデータを検知するステップと、
前記検知されたデータを処理して対応する情報を決定するステップと、
前記照明器具から発せられた光を、前記決定された情報に従って符号化するステップと、
を含む、方法。
［例１６９］
前記処理するステップが、デジタルウォーターマーク復号するサブステップを含む、例１６８に記載の方法。
［例１７０］
前記処理するステップが、パターン認識動作を行うサブステップを含む、例１６８に記載の方法。
［例１７１］
前記検知するステップが、前記照明器具に関連付けられたセンサから検知するサブステップを含む、例１６８に記載の方法。
［例１７２］
無線信号を検知するステップと、
前記検知された無線信号を処理して、ジオロケーション情報を決定するステップと、
前記照明器具から発せられた光を、前記決定されたジオロケーション情報に従って符号化するステップと、
を含む、例１６８に記載の方法。
［例１７３］
ポータブルデバイスのマイクロフォンにより、ユーザの周囲環境から、少なくとも１５分の延長された間隔にわたって、オーディオを受信するステップと、
アルゴリズムを、前記受信されたオーディオを表すデータに適用して、識別データを導出するステップと、
前記導出された識別データを参照することによって、前記ユーザが前記間隔中に曝されたオーディオコンテンツの少なくとも第１及び第２の異なる項目を決定するステップと、
前記オーディオコンテンツの決定された第１及び第２の異なる項目を参照することによって、前記ユーザによる後の使用のためにソフトウェアを用意するステップであり、前記用意するステップが、補助コンテンツの第１及び第２の項目を前記ポータブルデバイスで１つ又は複数のリモートリポジトリから受信するサブステップを含み、前記補助コンテンツの第１の項目が、前記オーディオコンテンツの第１の決定された項目に関連付けられ、前記補助コンテンツの第２の項目が、前記オーディオコンテンツの第２の決定された項目に関連付けられる、ステップと、
前記ユーザに、前記オーディオコンテンツの決定された第１及び第２の項目を識別するリストを提示するステップと、
関心のあるものとしての、前記オーディオコンテンツの決定された項目のうち１つのユーザ選択に応答して、補助コンテンツの対応する項目を使用して、前記用意されたソフトウェアに従って、アクションを取るステップと、
を含み、
前記ユーザが曝されるオーディオコンテンツの項目が監視され、前記ユーザがオーディオコンテンツの特定の項目を関心のあるものとして選択するより前に、関連付けられた補助コンテンツが、前記ポータブルデバイスによって受信される、方法。
［例１７４］
前記補助コンテンツの第１の項目が、音楽ビデオを備える、例１７３に記載の方法。
［例１７５］
前記補助コンテンツの第１の項目が、ゲームを備える、例１７３に記載の方法。
［例１７６］
ポータブルデバイスのマイクロフォンにより、ユーザの周囲環境から、少なくとも１５分の延長された間隔にわたって、オーディオを受信するステップと、
前記間隔中に前記ユーザのロケーションを検知するステップと、
アルゴリズムを、前記受信されたオーディオを表すデータに適用して、識別データを導出するステップと、
前記導出された識別データを参照することによって、前記ユーザが前記間隔中に曝されたオーディオコンテンツの少なくとも第１及び第２の異なる項目を決定するステップと、
前記ポータブルデバイスのユーザインターフェースを通して、前記オーディオコンテンツの決定された第１及び第２の異なる項目を、前記ユーザに識別するステップと、
前記オーディオコンテンツの決定された第１の項目を選択する、前記ユーザインターフェースを通したユーザ信号を、受信するステップと、
前記ユーザ信号に応答して、前記オーディオコンテンツの第１の項目の識別を、前記ユーザの検知されたロケーションを指示するデータとともに、オンラインソーシャルネットワークに投稿するステップと、
を含む、方法。
［例１７７］
メモリ内の命令によって構成されるプロセッサを含むシステムであって、
前記命令が、オペレーティングシステムソフトウェアを含み、前記オペレーティングシステムソフトウェアが、入力オーディオデータを受信するオーディオ識別サービス、又は、格納されたオーディオデータへのポインタを提供し、それに対応するメタデータを、前記オペレーティングシステムソフトウェアのオーディオ識別メッセージキューへ返す、システム。
［例１７８］
前記返されたメタデータが、オーディオフィンガープリントデータを備える、例１７７に記載のシステム。
［例１７９］
前記サービスが、複数のフィンガープリント処理のうちどれを適用すべきかを指定する、パラメータ入力データをも受信する、例１７８に記載のシステム。
［例１８０］
前記返されたメタデータが、復号されたオーディオウォーターマークデータを備える、例１７７に記載のシステム。
［例１８１］
前記サービスがパラメータ入力データをさらに受信し、前記パラメータ入力データは、複数のウォーターマーク復号処理のうちどれが、前記オペレーティングシステムソフトウェアの前記オーディオ識別サービスによって適用されるべきであるかを指定する、例１８０に記載のシステム。
［例１８２］
前記サービスが、前記返されたオーディオウォーターマークデータの明らかな有効性についてチェックする、例１８０に記載のシステム。
［例１８３］
前記返されたメタデータが、前記オーディオのタイトルと演奏するアーティストの名前とを与える、テキストを備える、例１７７に記載のシステム。
［例１８４］
前記サービスが、リモートメタデータレジストリと協働して、前記オーディオに関する情報を得る、例１７７に記載のシステム。
［例１８５］
モバイル電話デバイスのカメラ部分を使用して取り込まれ、前記デバイスの画面上に表示された、第１の被写体を描く画像のフレームを含む、方法であって、
取り込まれた画像データを解析することによって、前記第１の被写体に関係付けられた識別子を作り出すステップと、
第１のタグを、前記画面上に、画像の第１のフレームとともに表示するステップであり、前記第１のタグが、前記画面上の第１の位置に位置し、前記第１のタグが、前記第１の被写体に関連付けられたアクションを開始するようにユーザ選択可能である、ステップと、
前記第１のフレーム内に描かれた通りの前記第１の被写体を、前記表示された第１のタグに関連付ける、視覚的しるしを、前記画面上に提示するステップと、
前記第１のタグを、前記画面上に、前記第１の被写体を描く画像の第２のフレームとともに表示するステップと、
を含み、
前記第１の被写体が、前記画像の第１及び第２のフレーム内の異なるロケーションに描かれるが、前記第１のタグが、前記画像の第１及び第２のフレームの両方とともに、前記画面上の前記第１の位置に表示される、方法。
［例１８６］
前記視覚的しるしが視覚的つなぎ（ｖｉｓｕａｌ  ｔｅｔｈｅｒ）を備えており、前記視覚的つなぎが、前記画面上に表示された通りの前記第１の被写体に最も近い第１の端部を有し、且つ、前記表示された第１のタグに最も近い第２の端部を有しており、前記第１の端部が、前記画像の第１及び第２のフレーム内の前記第１の被写体の前記異なるロケーションとともに動く、例１８５に記載の方法。
［例１８７］
前記視覚的つなぎの前記第１の端部が、前記第１のフレーム内の前記第１の被写体の第１のハンドルロケーションに最も近く、前記第２のフレーム内の前記第１の被写体の第２の異なるハンドルロケーションに最も近い、例１８６に記載の方法。
［例１８８］
前記視覚的しるしが共通色を備えており、前記共通色が、前記第１のタグを、前記第１の被写体とともにレンダリングされたグラフィック効果に関連付ける、例１８５に記載の方法。
［例１８９］
前記視覚的しるしが、前記第１のタグを前記第１の被写体に視覚的に関連付ける、前記第１のタグのグラフィカルな外観を備える、例１８５に記載の方法。
［例１９０］
前記第１のタグを、前記画面の縁部に沿って表示するステップを含む、例１８５に記載の方法。
［例１９１］
前記方法が、前記識別子をリモートシステムへ送信するステップと、応答において情報を受信するステップであって、前記受信された情報が、前記第１の被写体に関する参照画像データを含む、ステップと、を含む、例１８５に記載の方法。
［例１９２］
前記受信された情報の使用を通して、前記第１及び第２の画像フレーム間で、前記第１の被写体の動きを追跡するステップをさらに含む、例１９１に記載の方法。
［例１９３］
前記受信された情報の使用を通して、前記第１の被写体と前記表示された第１のタグとの間に伸びるつなぎの終点を定義するステップをさらに含む、例１９１に記載の方法。
［例１９４］
前記方法が、第２の表示されたタグを、前記画面上に、前記画像の第２のフレームとともに追加するステップを含み、前記第２のタグが、前記画面上の第２の位置に位置し、前記第２のタグが、前記第２のフレーム内に描かれた第２の被写体に関連付けられたアクションを開始するようにユーザ選択可能であり、前記第２の位置が、前記第１のタグの前記第１の位置を変更することなく、前記画面上のその表示を可能にするように選択され、前記第１及び第２の位置が、前記画面の縁部に沿って位置する、例１８５に記載の方法。
［例１９５］
ユーザのモバイル電話のカメラ部分によって取り込まれた画像内で描かれた物理的オブジェクトを識別して、それにより、前記ユーザに関する物理的オブジェクトプリファレンス情報を見極め、それに基づいた物理的オブジェクトプリファレンスプロファイルデータを、メモリ内に格納するステップと、
電子メディアを、前記格納された物理的オブジェクトプリファレンスプロファイルデータに少なくとも部分的に基づいて、処理するステップと、を含む、方法。
［例１９６］
前記処理するステップが、前記格納された物理的オブジェクトプリファレンスプロファイルデータに少なくとも部分的に基づいて、前記ユーザに関連付けられた電子メールアカウントに向けて送られた電子メールを選別するサブステップを含む、例１９５に記載の方法。
［例１９７］
前記処理するステップが、特定のウェブページを、示唆されたお気に入りとして、前記ユーザに関連付けられたウェブブラウザに追加するサブステップを含み、前記特定のウェブページが、前記格納された物理的オブジェクトプリファレンスプロファイルデータに少なくとも部分的に基づいて決定される、例１９５に記載の方法。
［例１９８］
前記処理するステップが、パブリッシュされた電子メディアを監視するサブステップと、その選択された抜粋を前記ユーザに提供するサブステップと、を含み、前記選択が、前記格納された物理的オブジェクトプリファレンスプロファイルデータに少なくとも部分的に基づく、例１９５に記載の方法。
［例１９９］
前記パブリッシュされた電子メディアが、オンラインソーシャルネットワーキングサービスへの投稿を備える、例１９８に記載の方法。
［例２００］
ポータブルデバイスのカメラ部分により、画像のシーケンスを取り込むステップと、
前記シーケンスの最初の抜粋を解析して、較正情報を見極めるステップであり、前記較正情報が、前記最初の抜粋内で描かれた人の手の色を特徴付ける肌色データを含む、ステップと、
前記シーケンスの他の抜粋を解析して、取り込まれた画像を格納された参照手型データとマッチングすることによって、前記画像内に描かれたアメリカ手話の手型を識別するステップと、
前記解析に基づいて、語、音素、又は文字を出力デバイスに出力するステップと、
を含む、方法。
［例２０１］
前記方法が、前記ポータブルデバイスに装備される近接センサから出力された信号に少なくとも部分的に基づいて、前記シーケンスの前記最初の抜粋を解析するステップであって、人間の身体の一部分が前記デバイスに近接して検出されるとき、そのセンサが、前記出力信号を生じる、ステップを含む、例２００に記載の方法。
【図１】
0006054870.tif 000014
【図２】
0006054870.tif 000015
【図３】
0006054870.tif 000016
【図４】
0006054870.tif 000017
【図５】
0006054870.tif 000018
【図６】
0006054870.tif 000019
【図７】
0006054870.tif 000020
【図８】
0006054870.tif 000021
【図９】
0006054870.tif 000022
【図１０】
0006054870.tif 000023
【図１１】
0006054870.tif 000024
【図１２】
0006054870.tif 000025
【図１３】
0006054870.tif 000026
【図１４】
0006054870.tif 000027
【図１５】
0006054870.tif 000028
【図１６】
0006054870.tif 000029
【図１７】
0006054870.tif 000030
【図１８】
0006054870.tif 000031
【図１９】
0006054870.tif 000032
【図２０】
0006054870.tif 000033
【図２１】
0006054870.tif 000034
【図２２】
0006054870.tif 000035
【図２３】
0006054870.tif 000036
【図２４】
0006054870.tif 000037
【図２５】
0006054870.tif 000038
【図２６】
0006054870.tif 000039
【図２７】
0006054870.tif 000040
【図２８】
0006054870.tif 000041
【図２９Ａ】
0006054870.tif 000042
【図２９Ｂ】
0006054870.tif 000043
【図３０】
0006054870.tif 000044
【図３１】
0006054870.tif 000045
【図３２】
0006054870.tif 000046
【図３３】
0006054870.tif 000047
【図３４】
0006054870.tif 000048
【図３５】
0006054870.tif 000049
【図３６】
0006054870.tif 000050
【図３７】
0006054870.tif 000051
【図３８】
0006054870.tif 000052
【図３９】
0006054870.tif 000053