JP7568734B2 - マルチメディアコンテンツを配信するためのシステム及び方法 - Google Patents

Description

関連出願の相互参照
本出願は、２０１８年１０月２４日に出願人としてＲｏｂｅｒｔ Ｂ．Ｈｕｂｂａｒｄ、及び発明者としてＣａｒｌ Ｆｒｅｅｒによって提出された、「ＳＹＳＴＥＭ ＡＮＤ ＭＥＴＨＯＤ ＦＯＲ ＴＲＡＮＳＭＩＴＴＩＮＧ ＡＮＤ ＲＥＣＥＩＶＩＮＧ ＭＵＬＴＩＭＥＤＩＡ ＣＯＮＴＥＮＴ」と題された米国特許出願第１６／１６９，１３９号（代理人整理番号：ＳｍａｒｔＡｄｄｓ－１Ｂ）からの優先権を主張し、参照により、２０１９年１月１日に出願人Ｒｏｂｅｒｔ Ｂ．Ｈｕｂｂａｒｄと共に発明者としてＣａｒｌ Ｆｒｅｅｒに対して発行された、「ＳＹＳＴＥＭ ＡＮＤ ＭＥＴＨＯＤ ＦＯＲ ＴＲＡＮＳＭＩＴＴＩＮＧ ＡＮＤ ＲＥＣＥＩＶＩＮＧ ＭＵＬＴＩＭＥＤＩＡ ＣＯＮＴＥＮＴ」と題された米国特許第１０，１６９，７８０号明細書（代理人整理番号：ＳｍａｒｔＡｄｄｓ－１Ａ）を組み込む。
分野：
本技術は、通信システムに関する。より具体的には、本技術は、テレビネットワーク、セルラーネットワーク、及びモバイル無線デバイス間で通信するためのシステムに関する。

当該技術分野では、マルチメディア広告コンテンツの視聴率を確認して、広告視聴履歴及び嗜好に関する情報を共有することによる報酬を視聴者に与えるためのシステム又は方法が必要とされている。

当該技術分野における必要性は、２０１９年１月１日にＲ．Ｂ．Ｈｕｂｂａｒｄに対して発行され、その教示が参照により本明細書に組み込まれる「Ｓｙｓｔｅｍ ａｎｄ Ｍｅｔｈｏｄ Ｆｏｒ Ｔｒａｎｓｍｉｔｔｉｎｇ ａｎｄ Ｒｅｃｅｉｖｉｎｇ Ｍｕｌｔｉｍｅｄｉａ Ｃｏｎｔｅｎｔ」と題された、米国特許第１０，１６９，７８０号明細書によって対処された。

上記で引用したＨｕｂｂａｒｄ特許の教示は、当該技術分野における必要性を述べているが、さらなる必要性が残っており、それらは、Ｈｕｂｂａｒｄシステムの有用性及び機能性をテレビネットワーク及び市場に拡大するためのシステムの必要性を少なくとも含む。

当該技術分野における必要性は、本技術のシステム及び方法によって対処される。本発明のシステムは、マルチメディアコンテンツを送信、受信、及び出力し、その視聴の確認を提供するように適合されており、ネットワークを介してマルチメディアコンテンツを送信するためのサーバであって、該コンテンツが、オーディオ及びビデオコンテンツを含む、サーバと、テレビコンテンツを受信及び視聴するためのシステムと、ユーザによるテレビでのコンテンツの視聴を確認するのに有効な信号をサーバに自動的に提供するためのモバイルコンピューティング及び通信プラットフォームと、を含む。

例示的な実施形態では、システムは、テレビ、モバイル、パーソナルコンピューティング、及びゲームプラットフォームを含む、コンテンツを視聴するための代替プラットフォームを自動的に検出及び選択するためのコードを有するソフトウェアを格納及び実行するように適合されている。１つの代替プラットフォームから別の代替プラットフォームにコンテンツを送信するためのコードが含まれている。

さらに、ユーザプロンプト、視線追跡、組み込まれたＱＲコード（登録商標）の読み取り、及び自動コンテンツ認識を含む複数の確認モードが提供される。

本教示によるマルチメディア用システムの例示的なハードウェア実装を示すブロック図である。 本教示の例示的な実施形態によるアプレットによって提供される機能のマップである。 図１のシステムの動作の制御を行うためにコントローラ上で実行される例示的なソフトウェアのフロー図である。 本教示の代替的な実施形態によるスケジュール及びコンテンツダウンローディングロジックのフロー図である。 再生機能の例示的な実施態様を示すフロー図である。 本教示による図３及び図５に示すコンテンツ表示機能の例示的な実施態様のフロー図である。 本教示による図３及び図５に示す視聴確認機能の例示的な実施態様のフロー図である。 本教示による受信側プラットフォームの例示的な実施形態の簡略化されたブロック図である。

次に、本技術の有利な教示を開示するために、添付の図面を参照して例示的な実施形態及び例示的な用途を説明する。

本技術は、特定の用途のための例示的な実施形態を参照して本明細書で説明されるが、本技術はそれに限定されないことを理解されたい。本明細書で提供される教示にアクセスする当業者は、その範囲内における追加の修正、応用、及び実施形態、並びに本技術が重要な有用性を有し得る追加的な分野を認識するであろう。

図１は、本技術の教示による、マルチメディアコンテンツをモバイル無線プラットフォームに配信するためのシステムの例示的な実施態様を示すブロック図である。図１に示すように、システム１０は、インターフェース２１を介してマルチメディアコンテンツを受信するエンコーダ３８を含む。インターフェース２１は、ウェブサーバ６４を介してウェブに接続されるプロバイダインターフェースである。代替として、コンテンツは、ディスク又は他の手段を介して提供されてもよい。エンコーダ３８は、コンテンツを符号化及び圧縮して、ハブ４０にコンテンツを格納する。例えば、１０～３０秒のファイルは、１５０～３００キロバイトのパケットに圧縮され得る。ハブ４０は、コンテンツサーバのバンク等、保管設備である。ハブ４０は、５つのサーバ４１～４５と共に示されている。しかしながら、当業者は、本技術が、使用されるサーバの数が限定されないことを理解するであろう。

ハブ４０は、本教示によれば、とりわけスケジューラとして機能する、コントローラ５０に動作可能に結合されている。実際には、スケジュールは、ＰＣインターフェース５４を使用してローカルに又はウェブを介して入力され得る。

システム１０は、以下により詳細に論述するように、コンテンツに対するユーザ応答に関連するデータを格納するためのフィードバックデータベース３６をさらに含む。登録サーバ５２が、ユーザデータ（登録及び嗜好）をユーザデータベース５３に格納するために含まれている。このデータは、ユーザのＰＣインターフェース５５を介してユーザからウェブを介して受信され得る。オプションの課金サーバ５６も同様にコントローラに結合されている。課金サーバ５６はまた、オプションのクレジット、バーコード、及びバウチャサーバ５７、５８、及び５９と通信する。メッセージサーバが、コントローラ５０に結合されており、メッセージ関連データを提供する。マッピングデータベースは、本明細書で論述するように、場所ベースのサービスに含まれている。

本教示によれば、コントローラ５０は、スケジュールに従って、トランシーバ５１を介して、テレビプラットフォーム１２、スマートフォンプラットフォーム１４、及び／又はＰＣゲームプラットフォーム１８を含む１つ以上の選択されたプラットフォームユニットにコンテンツを送信する。

システムは、組み込まれた又は追加のアプリケーションとしてＧＰＳ（全地球測位システム）を利用するプラットフォームを受信するための補完的なサービスを使用する。このサービスは、ユーザの場所、ユーザ位置に関連した（広告主の）最も近い販売店の場所、場合によっては販売店までのターンバイターン経路方向を提供する。代替として、ユーザの場所データは、セルラー位置測位システムによって提供されてもよい。

最良のモードでは、アプレットが各モバイルユニットに送信される。
図２は、本教示の例示的な実施形態による、アプレット７０によって提供される機能のマップである。アプレット７０は、Ｃ若しくはＣ^＋＋又は他の適切なプログラムで書かれた小規模なプログラムである。７２に示すように、アプレット７０は、プレインストールされていてもよく、ＧＰＲＳ、ＣＤＭＡ、若しくは他の適切なリンクを介してＯＴＡをダウンロードされてもよく、又はＰＣから転送されてもよい。

プログラムは、デバイスのオペレーティングシステム（例えば、Ａｎｄｒｏｉｄ（Ｇｏｏｇｌｅ）、ｉＯＳ（Ａｐｐｌｅ）、Ｂａｄａ（Ｓａｍｓｕｎｇ）、Ｂｌａｃｋｂｅｒｒｙ ＯＳ（Ｒｅｓｅａｒｃｈ ｉｎ Ｍｏｔｉｏｎ）、Ｗｉｎｄｏｗｓ ＯＳ（Ｍｉｃｒｏｓｏｆｔ）、Ｓｙｍｂｉａｎ ＯＳ（Ｎｏｋｉａ）、Ｔｉｚｅｎ（Ｓａｍｓｕｎｇ）等）と互換性があるべきであり、各受信プラットフォーム上で受信されたコンテンツを復号及び解凍するためのコードを含むべきである。

例示的な一実施形態では、アプレットは、コンテンツの再生のためのスケジュールを含むＸＭＬファイルを抽出する。しかしながら、コンテンツは、要求若しくはコマンドに応じて又は所定のユーザ入力のセットに基づいて直ちに再生されてもよい。７４に示すように、アプレットは、例えば、氏名、ＤＯＢ、性別、郵便番号等の元の登録の細目をサーバにアップロードするために使用され得る。アプレットは、オペレーティングシステム、画面解像度、及びパフォーマンスを含む受信プラットフォームの技術パラメータを通信するために使用され得る。追加の情報及び嗜好は、アプリを介して追加することができる。

例示的な実施形態では、７６に示すように、アプレット７０は、オープンソースコーデック上に設けられている。本明細書で論述するように、アプレット７０はスケジュールをダウンロードする。スケジュールは、定期的に（例えば、毎日）各デバイスによってサーバから要求され得る。好ましい実施形態では、スケジュールはＸＭＬファイルである。

好ましくは、コンテンツは、転送制御プロトコル／インターネットプロトコル（ＴＣＰ／ＩＰ）内で具現化されるものとしてのハイパーテキスト転送プロトコル（ｈｔｔｐ）、ハイパーテキスト転送プロトコル・セキュア（ｈｔｔｐｓ）、ファイル転送プロトコル（ＦＴＰ）、若しくはＴＣＰ／ＩＰ環境内の任意の他のフォーマット、又は無線ネットワークオペレータのプロトコルスペクトルを介したＯＴＡのいずれかで配信される。

受信プラットフォームがマルチメディアメッセージを受信することができる前に、アプレットは、ユーザから隠されたサーバからのＯＴＡ ＳＭＳメッセージか、又はこれがアプレット自体内で指定されるかのいずれかによって起動される。起動されると、受信プラットフォームは、スケジュールについてサーバを定期的にチェックし始めることとなる。これは、デバイスを起動してスケジュールを検索するアプレットをインターフェースする。あるいは、アプレットは、本教示の範囲から逸脱することなく、自己起動又は他の条件に基づいて起動され得る。好ましくは、アプレットはプラットフォーム間でアジャイルである。当該技術分野で知られているように、これは、ターゲットプラットフォームのそれぞれのオペレーティングシステムでのコンパイルによって達成され得る。

例示的な実施形態では、コンテンツは、無線ネットワークオペレータ、モバイル・バーチャル・ネットワーク・オペレータ（ＭＶＮＯ）、又は任意の他のライセンスされたネットワークのエアタイムプロバイダによって提供されている無線ネットワークを介して送信されて、含まれている、符号化されてスケジュールされた再生時刻の十分に前に、（「再生」命令と共に）デバイス１２にダウンロードされる。当業者は、これにより、コンテンツの配信をその再生時刻に対してずらすことができることを認識するであろう。したがって、コンテンツは、同時に、ローカル若しくは所定の時間帯における特定の時刻に、又はユーザの活動に基づく相対時刻に、再生するようにタイミングを合わせることができる。

コンテンツを送信するために、任意の適切に高速であるネットワークが使用され得る。グローバル・システム・フォー・モバイル・コミュニケーション（ＧＳＭ）ネットワークでは、汎用パケット無線サービス（ＧＰＲＳ）を使用してアプレット及び広告が送信され得る。
ｈｔｔｐ：／／ｗｗｗ．ｇｓｍｗｏｒｌｄ．ｃｏｍ／ｔｅｃｈｎｏｌｏｇｙ／ｇｐｒｓ／ｉｎｔｒｏ．ｓｈｔｍｌ＃１を参照されたい。

ＧＰＲＳは、２．５Ｇとも呼ばれ、既存の第二世代ＧＳＭネットワークに基づいており、ＡｄＸｅｒｏ Ａｄの配信によく適している。しかしながら、本方法は、本教示の範囲から逸脱することなく、３Ｇ符号分割多元接続（ＣＤＭＡ）又は広帯域ＣＤＭＡ（ＷＣＤＭＡ：登録商標）又は時分割多元接続（ＴＤＭＡ）ネットワークにおいて実装されてもよい。

最良のモードでは、モバイルプラットフォームは、ＧＳＭ、ＣＤＭＡ、ＴＤＭＡ、又は他の適切なＩＰベースのネットワークに適合したセルラートランシーバを含む。ＴＶプラットフォームは、アプリをダウンロードしてコンテンツを再生することができる、ＩＰ接続されたＳｍａｒｔＴＶ、ゲームコンソール、又は接続されたＴＶデバイス、すなわちＲｏｋｕ、ＡｐｐｌｅＴＶ、Ｃｈｒｏｍｅｃａｓｔ、ＦｉｒｅＴＶ等を含む。ＧＰＲＳ等のサブチャネルの使用は、本教示の範囲から逸脱することなく、クラウドベースのサービス、及びダイレクト、ラジオ、又はテレビ放送送信と共にオプションである。したがって、本明細書又は図面におけるＧＰＲＳへの言及は、そのような代替的な実施形態を指すと理解されるべきである。

コンテンツは、これらのセルラーチャネルのうちの１つ以上を介して転送され、かつ任意の他の一般的なＰＣＳシステムに適応可能であり、受信後、再生までターゲット受信プラットフォームのメモリに単に存在する。

次に、本技術の動作が、例示的な広告アプリケーションに対して提供される。それにもかかわらず、当業者は、本教示が本教示の範囲から逸脱することなく、他のコンテンツ配信アプリケーションに利用され得ることを理解するであろう。

図３は、図１のシステムの動作の制御を行うためにコントローラ上で実行される例示的なソフトウェアのフロー図である。図１に示すように、メッセージサーバ６０は、コントローラ５０と直接又はネットワークのいずれかを介して接続されている。図３に示すように、方法１００によれば、ステップ１２２において、メッセージサーバ６０は、コントローラ５０によって供給されるデバイスのセットの各デバイスに選択的に送信されるべきマルチメディアメッセージの選択及びタイミングを定義する、メッセージ配信メトリックのデータベースにアクセスする。各デバイスは、代替的に、スケジュールに従って所定の時刻にメッセージを提示するためにメッセージングモジュールによって処理される別個のスケジュールファイルを有する１つ以上のマルチメディアメッセージを受信して格納してもよい。ステップ１２４において、システムは、場所ベースのサービスが要求されているかどうかを確認するためにチェックする。そうである場合、ステップ１２６において、サーバは、モバイルプラットフォームアセットのデータベース５３からデータを引き出す。ステップ１２８において、サーバは次いで、加入者を場所ベースのサービス要求と照合し、ステップ１３２に進む。

ステップ１２４において場所ベースのサービスが要求されていない場合、ステップ１３０及び１３２において、コントローラ５０は、いくつかのコンテンツプロバイダ（例えば、広告主）のコンテンツデータのデータベース６３にアクセスして、例えば、各メッセージファイルが所与のプロバイダに固有のビデオクリップを含むように、個々のメッセージファイルを生成できるようにする。メッセージサーバ６０は、プレゼンテーションデータ６１のデータベースにアクセスし、プレゼンテーションデータは、スタイル、マルチメディアメッセージプロバイダに固有のロゴ、及び制御ユニットの観点からビデオクリップが提示される方法を定義している。デバイスに配信されている１つ以上のマルチメディアメッセージのセットを開始するために、サーバは、そのデバイス上のアプレットにメッセージを送信する（ステップ１３４）。受信プラットフォーム上のアプレットは、低電力状態からデバイスを起動させ、かつスケジュールされたファイルのアプレット内に見るための新しいコンテンツがあることをユーザに通知する、アラートメッセージを受信する。好ましい実施形態では、通知メッセージは登録時に送信される。サーバは、スケジュールダウンロードを初期化するための通知メッセージを連続的に送信する必要はない。代替として、ダウンロードアドレスが規定され、その後、アプレットをインストールした時点でデバイスにロードされてもよい。

メッセージは、ステップ１５２において受信され、ステップ１５４において、各デバイスは、モバイルネットワークを介してＧＰＲＳセッションを開始することによって通知に応答して、スケジュールファイルを要求する。それに応答して、ステップ１４０において、サーバは、受信プラットフォームにおいて受信及び格納されるべくＧＰＲＳ又はＴＣＰを介してスケジュールファイルを送信する（ステップ１４２）。

上述したように、スケジュールファイルは、メッセージファイルごとに、メッセージファイルにアクセスすることができるサーバ内のアドレスを含む、１つ以上のマルチメディアメッセージファイルのセットの詳細を含むＸＭＬファイルである。このアドレスはステップ１４４で抽出され、ステップ１４６でサーバからメッセージをダウンロードするために使用される（ステップ１４８）。例示的な実施形態では、デバイスはＧＰＲＳを介してマルチメディアメッセージファイルを要求する。次いで、メッセージは、ＧＰＲＳによって受信プラットフォームに送信され、そこで受信及び格納される（ステップ１４８）。

ステップ１５０において、受信プラットフォームは、スケジュールファイルに定義された方法でメッセージファイルを再生する。これは、メッセージファイルの有効期限に達するまで、１日以上の期間にわたって予め定義された間隔でメッセージファイルを再生することを伴ってもよい。満了が検出されたとき、メッセージファイルは削除される。

マルチメディアメッセージの表示は、好ましくは、現在再生されているゲーム又は映画は中断されないが、終了するとすぐに、受信プラットフォームユーザがマルチメディアメッセージを見るように招待され、マルチメディアメッセージが表示されるまで、受信プラットフォームのエンターテインメント機能のさらなる使用が禁止されるように制御される。

ファイルの連続するデータフィールドは以下のように設定される。
・ＸＭＬスケジュールファイルのバージョンが示される。デバイスは、スケジュールファイルの現在の発行がファイルバージョンを表す値によって識別されることが適切であるように、ＸＭＬファイルに対する更新を定期的に要求する。
・ＸＭＬタグ、例えば「ＡｄＸｅｒｏ Ａｄ」は、メッセージファイルをダウンロードできるアドレスを定義する。
・「ファイル名」フィールドは、マルチメディアメッセージを含むファイルの名前を提供する。
・「開始時刻」フィールドは、メッセージファイルが再生されるべき最も早い時刻、言い換えれば、マルチメディアメッセージの配信が開始されるべき開始日時を示す。
・同様に、有効期限が示され、マルチメディアメッセージが配信されるべき最後の日時を提供し、メッセージファイルの削除をトリガする。
・「再生タイプ」フィールドは、コンテンツが再生することができる「開始時刻」後の最も早い機会を定義する。
・「繰り返し回数」フィールドは、メッセージが削除される前に繰り返すことができる回数を定義する。
・「繰り返し時間」フィールドは、繰り返しメッセージ再生の間隔の分単位を定義する。
・「順序」フィールドは、競合するマルチメディアメッセージファイル間の階層順序を定義し、最上位順序を有するメッセージファイルは、ＸＭＬファイルに含まれるフィールド値で定義された下位順序を有するものよりも優先して再生される。

例示的な実施形態では、スケジュールファイルの使用は、マルチメディアメッセージファイルの効率的な管理を提供し、かつ一連のマルチメディアメッセージを開始するためにモバイルネットワークを介した単一のＳＭＳメッセージのみを必要とし、メッセージファイルのダウンロード及び再生は、ＸＭＬファイルによって制御され、その連続するバージョンは、受信プラットフォームによって受信される。例示的な実施形態では、受信プラットフォームは、指定された時間ウィンドウ内でサーバを自動的にチェックして、ダウンロードする新しいスケジュールがあるかどうかを確認する。代替として、スケジュールは、次のスケジュールが検索されるべき時刻に関するデータを含んでもよく、また、ＯＴＡ通知コマンドを使用してスケジュール更新がデバイスにプッシュされてもよい。例外的な状況では、さらなる通知メッセージは、即時効果を有するマルチメディアメッセージの回収を再構築する必要があるときに、新しいスケジュールファイルのダウンロードをトリガすることができる。

代替的な実施形態は、競合又は調査の場合のように、直ちに再生されるか、又はユーザインターフェースを介したユーザ対話を必要とするマルチメディアメッセージを提供する。後者の場合、メッセージは、全ての必要なユーザ応答が受信されたときに終了するアプリケーションセッションの形態をとり得る。

特定の場所で利用可能な製品又はサービスに関するマルチメディアメッセージは、その位置が直近の地域又は指定された半径内にあると判定されたデバイスをターゲットとしてもよい。

サーバが、例えばマルチメディアメッセージプロバイダから、そのような局所化されたマルチメディアメッセージが生成されることに対する要求を受信した場合。サーバは、システムにおいて現在動作しているデバイスのアセットの各々の詳細を含むデータベースを参照し、マルチメディアメッセージのターゲットとなる資格のあるデバイスのサブセットを選択するために、各デバイスの加入者情報をマルチメディアメッセージの詳細と照合する。

この照合プロセスは、各デバイスについて、加入者がそのようなマルチメディアメッセージを受信することを選択したかどうかを判定する最初のステップから開始する、いくつかの段階を含んでもよい。加入者が所与の期間内に指定された数のマルチメディアメッセージ、例えば１日につき１２メッセージを受信することに同意した場合、送信されたメッセージの数が許可された数を超えないことを保証するために、以前のマルチメディアメッセージの送信履歴をチェックする必要がある。同様に、加入者は、特定の時刻又は特定の曜日にメッセージを受け入れることに同意している可能性があり、この情報は、マルチメディアメッセージに対する現在の需要と比較される。

結果として得られるサブセットは、加入者がメッセージを受け入れることに同意し、かつ現在要求されているマルチメディアメッセージを各加入者の同意されたスケジュールに従って配信することができるデバイスを表す。さらなるフィルタリングは、広告の特徴を、スポーツ、音楽、及びゲームへの興味等の加入者の嗜好と一致させることに依拠してもよい。

ステップ１２４において、サブセットの各デバイスの場所データが要求されると、サーバは各デバイスに、デバイスの現在位置の指示を要求するメッセージを送信する。デバイスは、そのＧＰＳソフトウェアモジュールからの位置データで応答し、それにより、サーバがサブセット内の各デバイスの位置データを蓄積することを可能にする。次いで、例えば、特定の製品の販売促進のために小売店の半径１マイル内で局所化されたマルチメディアメッセージが必要とされる場合に、それらの位置データから半径１マイル外であると識別されたデバイスがサブセットから除外されることとなるように、局所化されたマルチメディアメッセージに対する受信された需要の位置基準がサブセットをフィルタリングするために使用され、それにより、必要な場所にデバイスのフィルタリングされたサブセットが提供される。

この要求は、サーバで発信する代わりに、受信プラットフォームによって開始されてもよい。すなわち、この場合、ユーザが「私の最寄りを見つける」を選択すると、デバイスはＧＰＳ位置を更新して、このデータをＧＰＲＳ接続を介してサーバに送信する。そうすることで、サーバに緯度及び経度が送信されることとなる。次いで、マッピングサーバ６２は、ユーザの位置及び要求された販売店に基づいて、地図、ルート、及び他の、場所ベースのサービスを提供する。サーバは、その返信として、地図画像及びルーティング情報を受信プラットフォームに送信することとなる。この時点で、デバイスはウェブブラウザを開き、地図及びルーティング情報を表示する。

マルチメディアメッセージは、フィルタリングされたサブセットの各デバイスに提供される。この実施形態では、通知メッセージがフィルタリングされたサブセットの各デバイスに送信され、メッセージには、上述の手順を使用してインターネットを介してスケジュールファイル、次いでマルチメディアメッセージをダウンロードすることができるユニバーサル・リソース・ロケータ（ＵＲＬ）が含まれている。デバイスによってダウンロードされるマルチメディアメッセージは、典型的には、ビデオクリップの形態のマルチメディアメッセージを含むサイズ２～３００ｋのファイルであってもよい。次いで、デバイスユーザは、販売店の場所を示す地図をダウンロードするように招待されてもよい。

マルチメディアメッセージはまた、値引き又はプロモーションオファーのために小売店で交換することができる償還可能なトークンを含んでもよい。トークンは、販売時点で表示されて従来のバーコードリーダによってスキャンすることができる、バーコード等の機械可読証印の形態であってもよく、その結果、トークンを償還するために、デバイスユーザは、バーコードリーダを使用してデバイスの表示画面に表示されたバーコードを読み取る販売時点でデバイスを単に提示する。したがって、このアプリケーションでは、表示画面は、バーコードが確実に検出されるのに十分な表示解像度を有する必要がある。

サーバ、地図データプロバイダ、及びマルチメディアメッセージプロバイダはともに、マルチメディアメッセージを提供するための制御システムを備える。これらのエンティティは、別々に配置され、ネットワークによってリンクされてもよく、また、単一のエンティティとして同じ場所に配置されてもよく、サーバコンピュータ等の１つ以上の処理ユニットを備えてもよい。

代替的な一実施形態では、サーバは、マルチメディアメッセージをデバイスに直接送信する。必要に応じて、他のメッセージングプロトコルが使用されてもよい。

別の代替的な構成では、モバイルネットワークからセル識別情報を取得することによって各デバイスのおおよその場所を決定する最初のステップであって、そのような情報は、デバイスがモバイルネットワークに登録され、かつセルラーネットワークのセルのうちの１つ内で信号を受信するときに、一般に利用可能である、最初のステップ。利用可能な位置情報は、デバイス自体のＧＰＳデータを介して利用可能なものよりも具体的ではないが、検討中のデバイスのサブセットを最初に削減するために使用することができ、それにより、各デバイスからＧＰＳ位置データを取得するために第２のステップで送信する必要があるメッセージの数を削減する。

システムは、広告のコンテンツを表す広告プロファイルをデバイスに関する加入者情報と比較することによって、広告メッセージを受信するためのデバイスのサブセットを選択してもよい。そのとき、マルチメディアプロファイルが加入者情報と一致する場合、マルチメディアメッセージを受信するために候補を選択することができる。例えば、スポーツに興味があることが分かっている加入者は、スポーツのプロモーション資料を受信してもよく、自動車に関する広告を受け取らないことを希望した購読者は、そのような資料を受信することから除外してもよい。

加入者プロファイルに基づく選択は、デバイスの現在の場所に基づく選択と組み合わせて使用されてもよく、また、選択は、任意の位置情報とは無関係に行われてもよい。

好ましくは、各デバイスは、広告メッセージが視聴される各時刻の記録を、視聴時のデバイスの現在の場所、視聴が発生した時刻、及び広告主にとって関心のある任意の他の情報と共にメモリに格納する。この情報はサーバにアップロードされ、広告メッセージプロバイダによる使用のために処理される。このようなデータのアップロードは、スケジュールファイルの受信と同時に行われてもよい。

次いで、ステップ１５６において、広告メッセージプロバイダは、各デバイスのログから、そのデバイスに関連付けられた加入者の広告視聴履歴を表す視聴プロファイルデータを抽出してもよい。この情報は、さらなる広告メッセージのターゲティングを精緻化する際に、又は他の目的のために使用され得る。送信された広告メッセージの数、マルチメディアメッセージを受信している各デバイスユーザのアイデンティティ、広告がデバイスユーザを指定された場所に誘導するのに成功したか否か、及びバーコードが特別なオファーを利用するために使用されたか否かに関する情報は、その後の分析のために収集されてもよい。次いで、この収集された情報は、その後のマルチメディアキャンペーンで使用するためのフィードバックとして広告主に提供される適切なメトリクスでフォーマットされてもよい。

デバイスごとの情報のログはまた、デバイスユーザに報酬を与えるために使用されてもよい。広告メッセージを視聴する各インスタンスについて、広告メッセージを複数回視聴することに対するクレジットを蓄積することにより、蓄積されたクレジットの量をユーザに報酬として与えるための基準として使用できるように、
一実施形態では、システムは、加入者アカウントを管理する会計システムを含み、そのようなクレジットは、電気通信サービスの使用に関して加入者に対して引き落とされる額を減少させる。加入者は、例えば、携帯電話の通話のためのプリペイドサブスクリプションアカウントを有し得、クレジットを蓄積することによって、そのような通話の割引又は無料使用を取得してもよい。
他の報酬は、販売時点で償還可能なトークンの形態であってもよく、そのようなトークンは、例えばバーコードとしてデバイス上に表示するために送信される。

したがって、そのようなシステムを使用するためのビジネスモデルは、デバイスユーザが最小限の支出を有するように構築することができる。広告メッセージをデバイスに配信したいマルチメディアエンティティは、メッセージがいつどこで配信され、どの加入者に配信されたかを確認するためにユーザログから抽出された情報を受信する見返りとして、メッセージ配信インスタンス広告ごとの金額を支払ってもよい。一方、デバイスユーザは、例えば、１日当たり１０個の広告メッセージを見ることに同意することに対して、デバイスを低コスト又はゼロコストで提供されるように報酬を得ることができる。

例えば、

３タイプのＯＴＡメッセージを受信プラットフォームに送信して、ＡｄＸｅｒｏ Ａｄを制御することができる。全てのダウンロード場所は、シェル構成で設定されたリンクによって設定される。この例は、以下のとおりであり得る。
アドレス：ｈｔｔｐ：／／ｗｗｗ．ＡｄＸｅｒｏＡｄｓ．ｃｏｍ／ｄｏｗｎｌｏａｄ／
このアドレスは、ＯＴＡメッセージを使用して更新することができる。メッセージは、フィードバック情報のダウンロード及びアップロードに使用されるべき新しいアドレスを含み、これにより、必要に応じて将来の柔軟性及びロケール固有の構成が追加される。

スケジュールを即時に更新する必要がある場合、以下のタイプのＯＴＡ構成メッセージを送信することができる。
・再生前に特定のＡｄＸｅｒｏ Ａｄを削除する
ｏ１つ以上の特定の広告を参照できる（ＯＴＡメッセージにスペースがある場合）
・残りの全ての広告を削除し、スケジュールの更新を強制する
ｏよって、現在のローカル時刻に関係なく、新しいＡｄＸｅｒｏ ａｄをダウンロードすることができる。

ダウンロードのスケジュール
スケジュールファイルは、ダウンロードすべきＡｄＸｅｒｏ ａｄ、ダウンロードすべき時刻、及び再生すべき時刻等の情報を指定し、再生に関する特別な指示及び満期情報が含まれている。

スケジュールのダウンロード場所は、ダウンロードアドレスに基づく事前設定された場所である。これはＡｄＸｅｒｏ ａｄスケジュールアドレスと呼ばれ得、ダウンロード場所を設定するためにＯＴＡメッセージを再送することによって変更することができる。このアドレスの例は、以下となり得る。
「ＩＤ」タグは、基本的な暗号化メカニズムを介して実行された後の、割り当てられた受信プラットフォームの一意のＩＤである。

図４は、本教示の代替的な実施形態による、スケジュール及びＡｄＸｅｒｏ ａｄダウンロードロジックのフロー図である。この実施形態では、スケジュール情報ファイルは、フライトモードが無効にされた状態で１日に一度検索され（ステップ１７０～１７４）、フライトモードは全てのモデム機能を無効にする。したがって、受信プラットフォームがフライトモードを有効にしている場合、ユーザは、ＳＭＳ、ＭＭＳ、音声通話、ＧＰＲＳ等と同様にＡｄＸｅｒｏ ａｄも受信しないこととなる。フライトモード機能は、多くの最近の電話タイプで利用可能である。（未再生のＡｄＸｅｒｏ ａｄがまだ保留中でない限り）。ステップ１７６～１８０（偶数のみ）において、ユニットは、フィードバックファイルをアップロードし、スケジュールファイルをダウンロードし、マルチメディアコンテンツをそれぞれダウンロードする。ユニットは、例えば、ダウンロードが完了するまで、３０分ごとに再試行してもよい。完了すると、ユニットは翌日の起動タイマを設定する。

図５は、再生機能の例示的な実施態様を示すフロー図である。この実施態様では、メッセージが受信されて格納された後（ステップ１１０）、「メッセージ待ち」インジケータが表示される（ステップ１１１）。次いで、エンターテインメント機能が無効にされ（ステップ１１２）、ユニットは表示要求を待つ（ステップ１１３）。要求を受信すると、ユニットはマルチメディアメッセージを再生する（ステップ１１４）。メッセージが完了すると、エンターテインメント機能が復元される（ステップ１１６）。

スケジュールＸＭＬインターフェース
例示的な実施形態では、スケジュール情報はＸＭＬファイル内に含まれている。例示的な有効な属性及び値、並びにその動作説明を以下に示す。

マルチメディアコンテンツは、ｐｌａｙＳｔａｒｔＴｉｍｅ及びｐｌａｙＥｘｐｉｒｅＴｉｍｅ ＸＭＬタグで指定された時間の間に再生されることとなる。

コンテンツは順序タグによって優先付けされ、２つ以上のメッセージが所与の時間にわたって有効である場合、上位順序のコンテンツが下位順序のコンテンツの前に再生される。

コンテンツは、再生後に削除することができる。代替として、コンテンツは、Ｂｌｕｅｔｏｏｔｈ、赤外線、又はその他の機能を用いて、１つのデバイスから別のデバイスへ転送されてもよい（ピアツーピア）。必要に応じて、かつ代替として、コンテンツ（例えば、ＡｄＸｅｒｏ ａｄ）のユーザ・レコード・ロケータ（Ｕｓｅｒ Ｒｅｃｏｒｄ Ｌｏｃａｔｏｒ：ＵＲＬ）のみが、１つのデバイスから別のデバイスへ転送されてもよい。これは、受信デバイスに最適化されたサーバからバージョンをダウンロードすることを可能にするため、デバイスが類似していない場合に特に有利である。

スケジュールのＸＭＬテーマヘッダには、ｍｉｎＢａｃｋＴｏＢａｃｋタグを用いて、ＡｄＸｅｒｏ ａｄの再生間隔の最小時間を指定することができる。そうでなければ、所定の、例えば、最小３０分の連続再生が想定され得る。これは、２つ以上の広告を同時に再生できる場合に使用される。このルールは、第１の広告が再生された後の第２の広告の即時再生を停止する。

例示的な実施形態では、ユーザがホーム画面に進むと、有効なＡｄＸｅｒｏ ａｄが再生される（これが一番上のメニューである）。ＡｄＸｅｒｏ ａｄがダウンロード／再生／格納されると、この情報のログがデバイス上に格納される。例示的な実施形態では、次のスケジュールがダウンロードされる前に、この情報がサーバに投稿される。

スケジュールファイルは、例えば、ＸＭＬ形式である。

ＡＤＸＥＲＯ ＡＤタグ

スケジュールタグ

ユニットタグ

ＡｄＸｅｒｏ ａｄアプリケーションがインストールされると、登録プロセスが実行されることとなる。このプロセスは、サーバを用いてウェブブラウザを開く。ユーザは、以下を網羅する一連のページを辿る。
・ユーザの詳細（氏名、生年月日、性別、郵便番号等）、
・ユーザの嗜好（好き嫌い）
・受信プラットフォーム選択
・法令情報

例示的な実施形態では、受信プラットフォーム及びＳＩＭの組合せを識別するために、登録プロセスにおいて一意のシリアル番号が生成される。これは、ターゲットのＡｄＸｅｒｏ ａｄ受信プラットフォームを識別するために使用される。デバイスを購入する時点で、購入者は、例えば、月あたりの特定の数のメッセージに限定され得るマルチメディアメッセージのスケジュールを受信することを約束するオプションを受け入れるように招待される。

好ましくは、登録プロセスはウェブベースであり、したがって、異なる受信プラットフォーム表示出力に合わせて調整することができる。例示的な実施形態では、受信プラットフォームの登録の後、ネットワークは、受信プラットフォームの以下の基本的な事実を把握することとなる。
・一意の登録番号
・受信プラットフォーム上で実行される正確な電話及びＯＳ
・画面要件
・ビデオコーデック要件
・音声コーデック要件

次いで、ユーザは、ウェブサイトを訪問し、かつユーザのエンターテインメントの興味に関する情報を提供するように、招待されてもよい。ユーザがこのウェブページにログインした場合、ユーザはユーザ名及びパスワードを提供し、これは、その応答をユーザの一意のシリアル番号に、よって初期登録情報にリンクバックする。これにより、エンターテインメントの興味、及び端末登録から集められた性別／年齢／自宅の場所によって、この情報を提供するユーザのセグメント化が可能になる。

所定の間隔で、例えば２４時間ごとに１回、指定された「ウィンドウ」（深夜に開始するようにプログラムされている）内で、各受信プラットフォームは自動的にサーバにクエリする。これは、受信プラットフォームがオン又は待機モードのいずれかにある場合に発生する。受信プラットフォームがオフにされている場合、受信プラットフォームは、オンにされてサーバにアクセスするか、又は次にオンにされたときにサーバにアクセスすることとなる（その時刻が何であれ）。受信プラットフォームに正常にダウンロードされるまで、スケジュールを定期的に、例えば３０分ごとにダウンロードし続ける。

受信プラットフォームに供給されるようにスケジュールされたＡｄＸｅｒｏ ａｄがある場合、ダウンロードする準備ができているＸＭＬファイルがあることとなる。ＸＭＬファイルがダウンロードされる。それは、その受信プラットフォーム（広告タイプ、再生時刻）の送信スケジュールを含む。スケジュールは、選択する限り、前もって作成することができる（次の週の広告又は翌日の広告のみ）。

スケジュールがダウンロードされると、ＡｄＸｅｒｏ ａｄ自体がＧＰＲＳを介してダウンロードされて、デバイス上に格納される。ＡｄＸｅｒｏ ａｄコンテンツのダウンロード先はスケジュールファイルに詳述されており、これらは任意のＦＴＰ／ＨＴＴＰ／ＨＴＴＰＳアドレスとすることができる。

例：ある広告の再生ウィンドウは０９：００～翌日の１２：００である。０９：００に、受信プラットフォームは、「ビープ音」、すなわち、到着するテキストメッセージの音声を発する。受信プラットフォームがメインメニューページ上にある場合、ユーザが次に押さなければならないボタンは「メッセージ再生」ボタンである。ボタンは押されるまで機能しない。広告は最後まで再生しなければならない（この場合もボタンは機能しない）。この例における０９：００において、ユーザが受信プラットフォーム上で何かを行っていた（テキストを送信している／音楽を聴いている等）場合、ユーザはテキストアラート音を取得するが、ユーザの活動は妨げられない。しかし、次にメインメニューに戻るとき、又は受信プラットフォームをオフにしようとした場合、最初にメッセージ／広告を再生する必要があり、再生が完了するまで他のボタンは機能しない。

次いで、受信プラットフォームは、メッセージが視聴を待っているという指示をデバイスユーザに提供する。この実施形態では、受信プラットフォームは、マルチメディアメッセージファイルを受信したことをユーザに示し、表示画面に通知メッセージを表示させる出力データを生成する。そして、受信プラットフォームは、メッセージを表示するための命令として制御パッドを介してデバイスユーザからの入力を受信するのを待つ。広告が再生されている間、受信プラットフォームのエンターテインメント機能は一時的に無効にされる。これらの機能は、ゲームをプレイし、ビデオ及びオーディオ素材を再生し、かつ受信プラットフォームの任意の他のエンターテインメント機能を提供する、能力を含む。

これにより、デバイスユーザは、ビデオクリップ、オーディオクリップ、又はアニメーショングラフィック等の他のフォーマットの形態のマルチメディアメッセージを提示される。マルチメディアメッセージの再生が完了したと判定されると、受信プラットフォームのエンターテインメント機能は完全に復元され、さらなるメッセージが待機される。エンターテインメント機能の可用性のこの一時的な中断は、マルチメディアメッセージがデバイスユーザに確実に配信されるようにするインセンティブを提供する。

広告が受信プラットフォームを介して再生されると、ユーザは、広告、クーポン、及びウェブリンクを保存するオプションを有する。同じウィンドウ内で再生するようにスケジュールされた多数の広告がある場合、例示的に構成された３０分間再生連続構成がデフォルトとして設定される。これはスケジュールごとに構成することができる。

本教示によれば、ＡｄＸｅｒｏ ａｄプロセスの全ての態様に関する情報を提供するためにフィードバックが生成される。例えば、受信プラットフォームがサーバに次回ログインしたときに、それが報告するのは以下である。
・受信プラットフォームの登録情報
・前回のスケジュールダウンロード時刻
・各ＡｄＸｅｒｏ ａｄのダウンロード時刻と成功情報
・各ＡｄＸｅｒｏ ａｄの再生
・再生成功（再生の時刻を含む）
・再生を試みることができる前に期限切れ
・ＡｄＸｅｒｏ ａｄに関するユーザアクション
・ＡｄＸｅｒｏ ａｄが今後の視聴のために保存された
・ＡｄＸｅｒｏ ａｄが再生後に破棄された
・ＡｄＸｅｒｏ ａｄが再度視聴された

このデータは、サーバから生成された送信レポートで提供される。プロセスは、ユーザには見えないようであるべきである。

最良のモードでは、デバイスは、デバイスの位置を判定するために全地球測位システム（ＧＰＳ）衛星からの信号に応答する受信機を装備し、ＧＰＳデータは、場所及び方向についての目的に使用される。これらのデバイスのユーザの場合、広告主が広告の最後に「私の最寄りの店舗を見つける」オプションを有する場合、ユーザは、好ましくは２回のボタンクリックで店舗リストを見る機能が提供される。

「私の最寄りを見つける」機能は、ユーザの現在の場所を確認し、ユーザを選択された店舗にルーティングする。解決策は、この情報に地図及び／又はターンごとの方向を提供する。解決策は、以下のとおりであり得る。
・広告から抜け出て、「ＧＰＳ及びウェブサービス」を選択する
・「ＡｄＸｅｒｏ ａｄ広告主の場所」と呼ばれる別のフォルダがあり得る
・そのフォルダでは、広告主はアルファベット順である。
・広告主を選択する。
・その選択により（裏で）地図情報データベースにリンクして、地図を呼び出す。

上述したように、本発明のシステムは、マルチメディアコンテンツを送信、受信、及び出力し、その視聴の確認を提供するように適合されており、ネットワークを介してマルチメディアコンテンツを送信するためのサーバであって、該コンテンツが、オーディオ及びビデオコンテンツを含む、サーバと、テレビコンテンツを受信及び視聴するためのシステムと、ユーザによるテレビでのコンテンツの視聴を確認するのに有効な信号をサーバに自動的に提供するためのモバイルコンピューティング及び通信プラットフォームと、を含む。

例示的な実施形態では、システムは、テレビ、モバイル、パーソナルコンピューティング、及びゲームプラットフォームを含む、コンテンツを視聴するための代替プラットフォームを自動的に検出及び選択するためのコードを有するソフトウェアを格納及び実行するように適合されている。１つの代替プラットフォームから別の代替プラットフォームにコンテンツを送信するためのコードが含まれている。

さらに、ユーザプロンプト、視線追跡、組み込まれたＱＲコードの読み取り、及び自動コンテンツ認識を含む複数の確認モードが提供される。

これは、以下の図６～図８に示してある。
図６は、本教示による受信側プラットフォームの例示的な実施形態の簡略化されたブロック図である。以下でより完全に論述するように、例示的な実施形態では、受信側プラットフォーム又はデバイス２００は、ネットワークインターフェース２２０を介して図１のサーバ４０及びネットワーク１６からコンテンツを受信するように適合された、１つ以上のプロセッサ２１０を含む。コンテンツ及びコンテンツを表示するための命令は、プロセッサ２１０によって受信されて、メモリ２３０に格納される。メモリ２３０に予め格納された命令及びユーザＩ／Ｏ嗜好、並びにサーバ４０から受信した任意のスケジュールデータに従って、プロセッサ２１０は、受信したコンテンツをテレビ画面、ゲームプラットフォーム、スマートフォン、又は他のディスプレイ２４０に表示する。

ユーザプロンプトは、ユーザ入出力（Ｉ／Ｏ）インターフェース２５０及び／又はカメラ２５０を介してプロセッサ２１０によって受信される。すなわち、代替的な一実施形態では、メモリ２３０に格納された視線追跡ソフトウェアは、プロセッサ２１０が内蔵された又は動作可能に結合されたカメラ２６０を介してユーザの眼球運動を追跡して、より完全に上述したようにコンテンツ視聴の確認を提供することを可能にする。

最良のモードでは、受信側プラットフォーム２００は、以下の図７及び図８に示すステップを用いて、ユーザがテレビ画面上の広告及び他のコンテンツを視聴することを可能にする。

図７は、本教示による、図３及び図５に示すコンテンツ表示機能の例示的な実施態様のフロー図である。すなわち、図７は、スケジュールされた時刻におけるメッセージの再生に関する図３のステップ１５０の例示的な実施態様を示している。本教示によれば、ステップ２７０において、プロセッサ２１０は、インストール及びセットアップ時に最初に決定されたユーザ嗜好に基づいて、かつその後、ユーザ嗜好及び／又は近接度に基づいて、プラットフォーム選択を実行する。

すなわち、ステップ２７２において、最初にデフォルトプラットフォームがユーザのスマートフォンであるように、システム２００が設定されてもよい。その後、テレビ、パーソナルコンピューティング、又はゲームプラットフォームが起動される場合、システム２００のプロセッサ２１０上で実行されるソフトウェアコードは、任意選択的にプラットフォームに対するユーザの場所に基づいて、自動起動のためにこれらのプラットフォームのうちのいずれかを選択するオプションをユーザに与えることとなる。

ステップ２７４～２８４において、サーバ４０から送信されたコンテンツは、ステップ２７０において選択され、かつステップ２７２において検出された、プラットフォームによって受信される。コンテンツの伝送経路は、ステップ２８２に示すように、テレビ放送チャネル、ＷｉＦｉネットワークを介して、又はＷｉＦｉ、Ｂｌｕｅｔｏｏｔｈ、又はユーザのスマートフォンからの他の無線若しくは有線接続を介して、選択されたプラットフォームに対して直接的であってもよい。スマートフォンからテレビにキャストするためのソフトウェア及びシステムは当該技術分野で周知であるが、本教示の範囲から逸脱することなく、コンテンツは、当該技術分野で現在周知であるものと同じ又は同様の方法を使用して任意のプラットフォームから別のプラットフォームにキャストされ得ることを理解されたい。

いずれの場合も、ステップ２８６～２９０において、コンテンツは、上述したように通知に対するユーザ応答に基づいてユーザが視聴するために表示される。

視聴後、ステップ２８２において、ユーザは視聴の確認を促される。ステップ１５２、１５４（図３）による視聴を確認するためにステップ２９２を実施する方法が、図８に示されている。

図８は、本教示による、図３及び図５に示す視聴確認機能の例示的な実施態様のフロー図である。ステップ３００において、確認は、最初に、システム２００内のファームウェアに基づくセットアップ、ユーザセットアップ、及び／又はサーバ４０からのコマンドで自動的に選択され、その後、ユーザによって提供された嗜好又はプロンプトへの応答に基づいて手動で選択される。

最も簡単な実施態様では、上述したように、コンテンツが表示されて、ユーザ応答がサーバにアップロードされた後に、プロンプトが表示画面上に表示される。テレビアプリケーションでは、本教示によれば、コンテンツは画面上に表示され、ユーザは、テレビのリモコンとして機能するようにプログラムされていても、また、されていなくてもよいリモートコントロールユニット又はスマートフォンを使用して、プロンプトに応答する。

代替的な一実施形態では、コンテンツの再生中又はそれ以降にＱＲコードが画面上に表示される。ステップ３０８（図８）において、メモリ２３０に格納され、かつプロセッサ２１０によって実行されるユーザのスマートフォン上のソフトウェアは、カメラ２６０（図６を参照）によって受信されたＱＲコードを復号する。スマートフォンカメラを使用してＱＲコードを読み取るためのソフトウェアは、当該技術分野において周知であり、典型的には、最近のスマートフォンにおいて提供される。それに応答して、ステップ３１４において、プロセッサ２１０（図６）は、確認データをコントローラ５０（図１）に直接、又は外部ＨＴＭＬ若しくは他のリンクを介して送信する。

代替的な一実施形態によれば、図８のステップ３０４において、視線追跡ソフトウェアがプラットフォーム２００にインストールされる。この場合、ステップ３１０として、コンテンツの再生中にユーザの眼球運動を追跡することによって、コンテンツの視聴が自動的に確認される。さらに、ユーザの注意の焦点の場所を決定し、ステップ３１６において、サーバプラットフォームに転送して、ユーザが最も興味を持ったコンテンツのあらゆる態様及び時間に関する追加データを提供することができる。

さらに別の実施形態では、画像認識が実装される。この場合、ステップ３１２において、コンテンツが１つのプラットフォーム（テレビ、ＰＣ、又はゲーム画面等）上に表示され、ユーザのスマートフォン上にインストールされて実行される画像認識ソフトウェアがコンテンツを認識し、その間、ユーザは自分のスマートフォンカメラを画面に向け、ステップ３１８において、視聴確認をサーバプラットフォームに自動的に送信する。メタデータは、コンテンツに格納され、かつユーザには見えないが依然としてスマートフォンカメラ及びプロセッサによって検出されるように表示されてもよい。
いずれの場合でも、コンテンツに関連する音声は、図６には示していないユーザのスマートフォン上のマイクロフォンを介して検出されて、上述したように同様に、ビデオ自体に加えて、又はその代わりに、自動認識及び確認に使用され得ることに留意されたい。

視聴を確認することに加えて、上記で開示された自動認識方式はまた、一次コンテンツの検出に応答して二次オーディオ又はビデオコンテンツを表示するために使用されてもよいことに留意されたい。すなわち、広告を検出することで、他の広告又はプログラムを表示させることができる。二次広告を視聴するユーザは、通常の過程で補償されてもよく、また、コンテンツプロバイダの嗜好に従って二次又は三次コンテンツを視聴してそれに応答したことに対する特別な分配又は賞を与えられてもよく、一連の連結された広告又は他のコンテンツは、本教示の範囲から逸脱することなく無限に拡張してもよい。

したがって、本技術によって提供される広告の広告指名は「スマート広告」である。いずれの場合でも、本教示は、広告又は「ａｄ」との使用に限定されない。逆に、本教示は、コンテンツの視聴の確認が望まれる任意のシナリオで利用されてもよい。例えば、本教示は、瞬間的な視聴率及び／又は評価システムを提供するために、通常の番組コンテンツの視聴を確認するために使用され得る。

さらに、本教示は、上記の例示的な実施形態で論述したユーザプラットフォームに限定されない。本教示から逸脱することなく、拡張現実（ＡＲ）等の追加のプラットフォーム及びディスプレイ技術が使用されてもよい。ＡＲアプリケーションでは、本教示の範囲から逸脱することなく、サーバからのコンテンツがＡＲに投影されてもよく、また、一次コンテンツから生じる二次コンテンツがＡＲに投影されてもよい。

本教示にアクセスする当業者は、その範囲内における追加の修正、応用、及び実施形態を認識するであろう。

したがって、添付の特許請求の範囲は、本技術の範囲内の任意のかつ全てのそのような用途、修正、及び実施形態を網羅することを意図している。

大まかに言えば、この文書は少なくとも以下の「概念」を提示している。

１．マルチメディアコンテンツの送信、受信、及び出力、並びにその視聴の確認のためのシステムであって、前記システムが、
ネットワークを介してマルチメディアコンテンツを送信するためのサーバであって、前記コンテンツが、オーディオ及びビデオコンテンツを含む、サーバと、
テレビコンテンツを受信及び視聴するためのシステムと、
ユーザによるテレビでの前記コンテンツの視聴を確認するのに有効な信号を前記サーバに自動的に提供するためのモバイルコンピューティング及び通信プラットフォームと、
を含む、システム。

２．前記コンテンツを視聴するための代替プラットフォームを選択するための、前記モバイルコンピューティング及び通信プラットフォーム上で実行可能なコードをさらに含む、概念１に記載のシステム。

３．前記コンテンツを視聴するための代替プラットフォームを自動的に検出するために前記モバイルコンピューティング及び通信プラットフォーム上で実行されるコードをさらに含む、概念２に記載のシステム。

４．前記コンテンツを視聴するための代替プラットフォームを自動的に検出及び選択するために前記モバイルコンピューティング及び通信プラットフォーム上で実行されるコードをさらに含む、概念３に記載のシステム。

５．１つの代替プラットフォームから別の代替プラットフォームへ前記コンテンツを送信するためのコードをさらに含む、概念２に記載のシステム。

６．前記代替プラットフォームが、テレビ、モバイル、パーソナルコンピューティング、及びゲームである、概念２に記載のシステム。

７．複数の確認モードを実施するためのコードを含む、概念２に記載のシステム。

８．前記モードのうちの１つが、ユーザプロンプトである、概念２に記載のシステム。

９．前記モードのうちの別の１つが、ユーザ視線追跡システムによって提供される、概念２に記載のシステム。

１０．前記モードのうちの１つが、前記コンテンツに組み込まれたＱＲコードの読み取りに基づく、概念２に記載のシステム。

１１．前記モードのうちの１つが、自動コンテンツ認識を伴う、概念２に記載のシステム。

１２．マルチメディアコンテンツの送信、受信、及び出力、並びにその視聴の確認のためのシステムであって、
ネットワークを介してマルチメディアコンテンツを送信するためのサーバであって、前記コンテンツが、オーディオ及びビデオコンテンツを含む、サーバと、
テレビコンテンツを受信及び視聴するためのシステムと、
ユーザによるテレビでの前記コンテンツの視聴を確認するのに有効な信号を前記サーバに自動的に提供するためのモバイルコンピューティング及び通信プラットフォームと、含み、前記プラットフォームが、
プロセッサと、
有形の媒体に固定されたメモリと、
前記プロセッサによって実行可能な前記メモリに格納されたソフトウェアと、を含み、前記ソフトウェアが、
前記コンテンツを視聴するための代替プラットフォームを選択することであって、前記代替プラットフォームが、テレビ、モバイル、パーソナルコンピューティング、及びゲームである、選択することと、
前記コンテンツを視聴するための代替プラットフォームを自動的に検出及び選択することと、
１つの代替プラットフォームから別の代替プラットフォームへ前記コンテンツを送信することと、
複数の確認モードを実施することであって、前記モードのうちの１つが、ユーザプロンプトであり、前記モードのうちの１つが、前記コンテンツに組み込まれたＱＲコードの読み取りに基づいており、前記モードのうちの１つが、自動コンテンツ認識を伴う、実施することと、
のためのものである、
システム。

１３．マルチメディアコンテンツを送信、受信、及び出力するためのシステムであって、
第１のネットワークを介してマルチメディアコンテンツを送信するための送信機であって、前記コンテンツが、オーディオ及びビデオコンテンツを含む、送信機と、
前記第１のネットワークを介して前記コンテンツを自動的に受信するためのテレビプラットフォームと、
前記プラットフォーム上で実行されるアプレットと、を含み、前記アプレットが、
ユーザによる前記プラットフォームの使用に関して前記プラットフォームの状態に従う所定の時間又は場所において、前記プラットフォームで前記コンテンツを自動的に再生することと、
前記ユーザがコンテンツを視聴したことを確認することと、
その前記視聴に関するデータを前記マルチメディアコンテンツのソースに送信することと、
に適合されており、
これにより、クレジットが前記ユーザのアカウントに自動的に適用され得る、
システム。

以下の概念も提示している。
マルチメディアコンテンツを送信、受信、及び出力し、その視聴の確認を提供するためのシステムであって、ネットワークを介してマルチメディアコンテンツを送信するためのサーバであって、該コンテンツが、オーディオ及びビデオコンテンツを含む、サーバと、テレビコンテンツを受信及び視聴するためのシステムと、ユーザによるテレビでのコンテンツの視聴を確認するのに有効な信号をサーバに自動的に提供するためのモバイルコンピューティング及び通信プラットフォームと、を含む、システム。例示的な実施形態では、システムは、テレビ、モバイル、パーソナルコンピューティング、及びゲームプラットフォームを含む、コンテンツを視聴するための代替プラットフォームを自動的に検出及び選択するためのコードを有するソフトウェアを格納及び実行するように適合されている。１つの代替プラットフォームから別の代替プラットフォームにコンテンツを送信するためのコードが含まれている。さらに、ユーザプロンプト、視線追跡、組み込まれたＱＲコードの読み取り、及び自動コンテンツ認識を含む複数の確認モードが教示される。

本明細書に記載の全ての要素、部分、及びステップが含まれることが好ましい。当業者には明らかであると思われるように、これらの要素、部分、及びステップのいずれも、他の要素、部分、及びステップによって置き換えられてもよく、また、完全に削除されてもよいことを理解されたい。

Claims (11)

1. マルチメディアコンテンツの送信、受信、及び出力、並びにその視聴の確認のために構成されたシステム（１０）であって、前記システムが、
   ネットワーク（１６）を介してマルチメディアコンテンツを送信するように構成されたサーバ（６４）であって、前記マルチメディアコンテンツは、ビデオコンテンツだけでなくオーディオコンテンツも含む、サーバ（６４）と、
   テレビコンテンツを受信及び視聴するように構成されたテレビシステム（１２）と、
   を含み、
   前記マルチメディアコンテンツを受信して格納（１１０）した後、要求に応じて前記マルチメディアコンテンツが表示されることを待っていることを示すインジケータを表示し（１１１）、ユーザによる要求（１１３）に応じて前記マルチメディアコンテンツが表示される（１１４）まで前記テレビコンテンツ（１１６）の視聴を無効にし（１１２）、ユーザによる前記テレビシステム（１２）での前記マルチメディアコンテンツの視聴を確認するのに有効な信号を前記サーバに自動的に提供するように構成される、システム（１０）。
2. 前記マルチメディアコンテンツを視聴するための代替プラットフォームを選択するようにさらに構成された、請求項１に記載のシステム。
3. 前記マルチメディアコンテンツを視聴するための代替プラットフォームを自動的に検出するようにさらに構成された、請求項２に記載のシステム。
4. 前記マルチメディアコンテンツを視聴するための代替プラットフォームを自動的に検出及び選択するようにさらに構成された、請求項３に記載のシステム。
5. １つの代替プラットフォームから別の代替プラットフォームへ前記マルチメディアコンテンツを送信するようにさらに構成された、請求項２に記載のシステム。
6. 前記代替プラットフォームが、テレビ、モバイル、パーソナルコンピューティング、及びゲームである、請求項２に記載のシステム。
7. 複数のコンテンツの視聴を確認するための確認モードを実施するようにさらに構成された、請求項２に記載のシステム。
8. 前記確認モードのうちの１つが、ユーザプロンプトを含む、請求項７に記載のシステム。
9. 前記確認モードのうちの１つが、ユーザ視線追跡システムによって提供される、請求項７に記載のシステム。
10. 前記確認モードのうちの１つが、前記マルチメディアコンテンツに組み込まれたＱＲコードの表示に基づく、請求項７に記載のシステム。
11. 前記確認モードのうちの１つが、自動コンテンツ認識のために提供されるコンテンツの表示を伴う、請求項７に記載のシステム。