JP2004505377A - 広告の効果を高めるためのコンピュータ化されたシステムおよび方法 - Google Patents

Abstract

広告を放送する番組の中で広告の効果に関するデータを収集し分析する、ソフトウェア情報システムを含む、広告することの効果を高めるための報奨を出す雑学コンテストを実施するシステムと方法を開示する。このシステムを使用して、Ｗｅｂベースの配信システム（ＲＥＷＡＲＤＴＶ．ＣＯＭ）を介して想起、理解、好ましさ、およびその他のパフォーマンス測定基準に関するデータを広告主およびその他のクライアントに報告することができる。広告に関係する雑学問題の第１のセットとコンテンツに関係する雑学問題の第２のセットがシステムに格納される。雑学問題の第１と第２のセットはコンテンツとともに広告の放送（ＲＴＶ．ＣＯＭ・ＡＤＶＥＲＴＩＳＥＲ）と関連させられる。会員への送信（ＲＴＶ．ＣＯＭ／ＮＥＴＷＯＲＫ）のため第１と第２の雑学問題のサブセットを選択する。会員の返信を受信して、正しい答えであればポイントを与える。与えられたポイントに基づいて報奨（ＩＮＣＥＮＴＩＶＥＳ）を会員（ＴＶ　ＶＩＥＷＥＲ）に与える。

Description

【０００１】
本出願は、開示全体が引用により本出願に取り込まれている２０００年７月３１日出願の米国特許仮出願第６０／２２１，７７６号が有用であることを主張する。
【０００２】
本出願は、著作権保護に従う資料を含む。著作権所有者は、特許商標庁のファイルまたは記録の記載に従い誰が特許開示のファクシミリ複製を行おうと反対しないが、他の手段については何であれすべての著作権を留保する。
【０００３】
本出願は、４０５３枚のフレームと４２枚のフィッシュを持つマイクロフィッシュの付録を含む。マイクロフィッシュは、これにより本明細書の一部に取り込まれ、その一部となっているソース・コードを含む。
【０００４】
（発明の分野）
本発明は、一般には、広告用のソフトウェアおよびハードウェア・システムの分野に関するものであり、具体的には、広告およびその他の放送の効果を向上させる新規性のあるシステムおよび方法に関するものである。
【０００５】
（発明の背景）
広告主は年間５００億ドルを超える費用を投じテレビを通じて消費者に訴えかけているが、今のところ、放送される番組のコンテキストでその広告の効果を測定できないでいる。現在、多くの広告主は「フォーカス・グループ」およびその他の調査手法を用いて広告を打つ前に広告を事前テストし、広告の放送後に主に電話聞き取り調査により多くの事後テストを行っている。時として、広告主は電話聞き取り調査により継続的に広告の効果をテストし、広告キャンペーンに対する認識の継続を測定する。この方法は、全放映で放送されるすべての広告に対し継続的に調査を実施する費用が法外に高いため広くは使われていない。
【０００６】
それで、広告のパフォーマンスに関する正確な連続データの必要性は、テレビ広告に対する注目度が実質的に低下し、テレビ広告の費用が実質的に増大しているため、テレビ広告主にとってあまり重要なものでなくなってきている。２５年前、３社の放送網がテレビ業界を支配していた。今日では、消費者は、追加のネットワーク、特定分野のケーブルテレビ局、映画チャネル、衛星放送システム、および電子ゲームやインターネットなどの新しい形態の家庭向け娯楽といった、さまざまな選択肢を持つ。さらに、広告主にとって問題がますます複雑になるのは、視聴者が同時に複数の娯楽および情報媒体を使用する（テレビ、インターネット、雑誌、電子ゲーム）、つまり視聴者はテレビを「見ながら」何か別のことをしているという点である。
【０００７】
広告主は年間５００億ドルの費用を投じてテレビを介して消費者に訴えかけているが、テレビ視聴者の５０％はチャネルを切り替えたり、部屋から出ていったり、コマーシャルの時間にテレビ以外の何かに注目したりしており、決して広告を見ることがない。さらに、テレビの広告を見ている消費者のうちわずかに２０％がその広告を覚えているだけである。また、広告のメッセージを理解するのは１０％未満である。
【０００８】
視聴者は広告に対し注意を払わない（または決して見ない）ため、消費者に訴えかけるための実効費用はおおよそネットワーク報告ＣＰＭ（Ｃｏｓｔ Ｐｅｒ Ｔｈｏｕｓａｎｄ）率の２０倍ほどである。これは、広告主にとって大きな財務上の意味を持つものであり、広告のパフォーマンスに関するきちんと整理されたデータを提供することにより効率を高める好機が市場にあることを示している。
【０００９】
（発明の概要）
好ましい実施形態では、本発明は、広告を放送する番組で広告の効果に関するデータを収集し分析するソフトウェア情報システムを含む、広告することの効果を高めるため、報奨を出す雑学コンテストを実施するシステムと方法を開示する。このシステムを使用して、Ｗｅｂベースの配信システムを介して想起、理解、好ましさ、およびその他のパフォーマンス測定基準に関するデータを広告主およびその他のクライアントに報告することができる。広告に関係する雑学問題の第１のセットとコンテンツに関係する雑学問題の第２のセットがシステムに格納される。雑学問題の第１と第２のセットはコンテンツとともに広告の放送と関連させられる。会員への送信のため第１と第２の雑学問題のサブセットを選択する。会員の返信を受信して、正しい答えであればポイントを与える。与えられたポイントに基づいて報奨を会員に与える。
【００１０】
好ましい実施形態における本発明の方法及びシステムから供給されるデータにより、広告主は番組、番組のジャンル、およびネットワーク別にパフォーマンスを比較し、それにより、広告主はターゲット視聴者に最も効果的に訴えかけられるところで広告が放送されるようにリソースと広告インベントリを再配分することができる。
【００１１】
システムから供給されるデータはさらに、広告主が製品配置広告、つまり番組休止中に異なるコンテンツ断片として現れるのではなく、番組自体のコンテンツに組み込まれている広告のパフォーマンスを理解するのに役立つ。広告に対する注目率が低下し、視聴者が見ている番組から広告を完全に消し去ることができる新しい技術が登場したため、この形態の広告がますます重要になってくる。広告およびテレビ業界内では、製品配置広告に関するパフォーマンス・データを提供する標準または測定形式は今のところ存在していない。
【００１２】
それと同時に、システムによって供給されるデータを使用することで、テレビジョン・ネットワークおよび番組制作者は、プロット、キャラクター、テーマ音楽、およびその他のクリエーティブな要素を含む番組コンテンツに対する視聴者の反応を評価することができる。
【００１３】
本発明の他の機能および利点については以下で説明するが、ある程度説明から明らかであろうし、また本発明を実施することにより学ぶこともできる。本発明の目的およびその他の利点は、書かれている説明およびその請求項さらに付属の図面で特に指摘されている構造から理解され、実施できるであろう。
【００１４】
本発明の詳細を理解できるように添付され、また本明細書に取り込まれその一部を構成する付属の図面は、本発明の実施形態を示し、その説明とあわせて、本発明の原理を説明するのに使用される。
【００１５】
（好ましい実施形態の詳細な説明）
本発明の好ましい実施形態を詳細に参照し、その例を付属の図面に示す。
本発明のシステムをおよび方法は、テレビ広告主、メディアおよび広告代理店、コンテンツ制作者、放送事業者にとって情報に関する解決策となる。報奨番組モデルは、娯楽を報奨、懸賞、およびその他の形態の経済的報酬と組み合わせてテレビに適用され、テレビ視聴者の大規模で安価なリサーチ・パネルを構築する。このリサーチ・パネルは、テレビ広告キャンペーンおよび番組コンテンツの有効性に関する豊かな情報のデータベースとなるものであって、毎日更新されるのが好ましい。データベースに熟練している当業者であれば、本発明の精神から逸脱することなく、データベースを毎時間、毎分、リアルタイムなどさまざまな間隔で更新できることは理解するであろう。モデルの重要なマーケティング・コンポーネントとシステムに内在するインセンティブにより、（１）選択された広告キャンペーンをインターネットに拡張することにより個々の広告の影響力を強めることができる、（２）番組切り替えの頻度を減らし、視聴者の忠実さを高め、視聴者が新しい番組コンテンツを受け入れられるようにするためのユニークなツールをテレビジョン・ネットワークに装備できるという２つの利点が得られる。
【００１６】
視聴者は、テレビを見るということについて補償され、視聴習慣に関するデータを提供するように報奨により奨励される。本発明の一態様では、視聴者はテレビ番組およびコマーシャルを見た後Ｗｅｂサイトを介してシステムにアクセスし、その番組および広告に関する質問に答える。好ましい実施形態に関して本発明で規定しているのと同じ原理を適用し、無線デバイス、セットトップ・ボックス、ＰＤＡ、電話、対話型音声応答システム（ＩＶＲ）などの他の通信媒体およびデバイスを利用するシステムおよび方法を実現することができる。
【００１７】
図１に示されているように、テレビ番組を見ているときまたは見た後、視聴者は、所定の期間内に本発明のＷｅｂサーバの消費者セクションにログオンし、番組と広告に関する一連の雑学ゲーム的な質問に答える。このような広告は、従来のコマーシャルでも、またたとえば製品が番組のコンテンツの中に現れる「製品配置」タイプの広告であっても良い。これらの質問に答える視聴者は、商品、サービス、および賞品と引き換えることができる専用「通貨」を受け取ることができる。
【００１８】
本発明の一実施形態によれば、番組を見た後、視聴者は最初に、Ｗｅｂサーバにログオンし、一連の質問に答えることでその意見を登録するため最大２４時間の猶予が与えられる。システムは、この質問セットを完了し、質問に正しく答えられるように視聴者にクレジットを割り当てる。システムではさらに、会員が無線および対話型テレビを含むさまざまなプラットフォーム上で質問に答えられるようにもできる。この点に関して、「会員」とは、システムに関連するＷｅｂサイトに登録しているテレビ視聴者とすることができる。
【００１９】
本発明のシステムは、Ｗｅｂサイトのユーザが提供したデータを集めて分析し、その結果をクライアントに渡す。この点に関して、「クライアント」は、たとえば、システムを通じてオフライン広告の成功を追跡するエンティティまたは個人である。クライアントはまた、広告またはコンテンツの注目、想起、メッセージ理解、および好みに関する広告またはデータの効果に関心のある業界のネットワーク、メディア会社、およびその他のエンティティであってよい。クライアントはまた、アカウント・タイプ、たとえば、ユーザまたは管理者で分類することもできる。このように分類することで、情報に関して設定されるセキュリティ・アクセスの種類を指定することができる。
【００２０】
本発明のシステム全体は、消費者サイトとクライアント・サイトの２つの主要なエリアに分割するのが好ましい。消費者サイトは、会員情報を捕捉し、保持するために使用される。このサイト内では、会員はたとえば、テレビ番組欄を見、テレビのコンテンツを閲覧し、勘定残高を確認し、番組レベル統計量を調べ、報奨カタログを見て突き合わせて引き換えを行い、テレビ番組に関する雑学的質問調査に参加することができる。この調査コンポーネントは、複数のエリアをつないで１つにし、テレビ関連雑学的問題を会員に提示する。さらに重要なのは、調査ツールが調査の自動マーキングのための手段となることである。調査により、広告主の広告、テレビ番組欄、フライティング計画、および会員が１つにまとめられ、テレビ広告および番組の有効性に関係するデータが得られる。
【００２１】
消費者サイトから捕捉された情報は、集計および分析のためトレンドレポータ・コンポーネントに送られる。トレンドレポータは、クライアント・サイトと関連するデータ・ウェアハウスであり、これによりクライアントは広告および番組の効果を見て分析することができる。このリサーチ・ツールを利用すると、クライアントはＷｅｂベース方法を用いて、番組およびその他の広告のコンテキストにおいて、夜毎にそのコマーシャルの効果を測定することができる。本発明のシステムは、たとえば、注目度、想起、メッセージ理解および好みに関するデータを集めて分析し、好ましくは、その情報を毎日クライアントに提供するが、これは、放映されているときだけでなくキャンペーン全体でも各広告の影響を非常に詳しく見ることができる。トレンドレポータ・コンポーネントは、視聴規模の変化を定量化し、パフォーマンス・データおよび分析結果を出力するので、広告クライアントにとっては、パフォーマンス最高の広告および番組をサポートするために広告の混合比を再配分し、実際の広告効果に基づいて広告料金を交渉する手段となる。本発明のシステムおよび方法は、報告の速度を改善し、大きなサンプル・サイズを提供し、サンプリング手法を繰り返す（したがって精密化する）ことができる。
【００２２】
本発明は、データ報告機能の柔軟性が高まるように構成するのが好ましい。高速で簡素化された要約結果が必要な上級マーケティング管理者は、トレンドレポータ・コンポーネントを使用して、完全な国内テレビ予算のパフォーマンスを分析し、放送された広告のデジタル化されたバージョンを見ることができる。ブランド管理者、メディア計画者、およびメディア購入者は、個々の番組および広告のパフォーマンスに関する得られた詳細データを利用して、クライアント向けのより効果的なメディア・キャンペーンを張ることができる。
消費者サイトの技術的概要
図２は、本発明のシステムの消費者サイト部分を実施するために使用できるアーキテクチャの一例を示すエンティティ関係図である。消費者サイト全体を複数のエリアに分割し、統合したときに、競争力分析とともに有効性情報をクライアントに提供することができる。以下ではそれぞれについて詳述する。
【００２３】
クライアント・エンティティ−クライアントとそのブランド分類構造。
広告エンティティ−既存のクライアントおよび潜在的クライアントの広告を含む。
【００２４】
テレビ番組欄および広告エンティティ−テレビ番組欄とフライティング計画を含む。
クライアント・ドメイン構造−広告主の製品および広告を含む。
【００２５】
調査エンティティ−番組に関する雑学的問題事項および質問を含む。
質問エンティティ−会員に対して潜在的に問いかけられる可能性のあるさまざまな質問。これは、番組と広告関係の質問を含む。
【００２６】
会員エンティティ−会員の人口統計、調査結果、勘定残高、報奨カタログ項目、および引き換え履歴を含む。
会員回答エンティティ−調査質問に対する会員回答を詳細に記載する。
【００２７】
報奨エンティティ−報奨カタログを含む。
懸賞エンティティ−さまざまな懸賞提供物を含む。
コミュニティ・イベント・エンティティ−会員のグループがたとえば商品を求めて競争するチームとしてプレーするイベントを含む。
テレビ番組欄の技術的概要
テレビ番組欄情報を使用して、テレビ番組、放送会社、および放送会社の番組スケジュールの関係を維持する。システムは、国内のテレビ番組欄および娯楽コンテンツ・ストーリーに会員がアクセスできるようにするのが好ましい。また、この情報は、調査を実施し、放送局の広告（フライティング）計画を維持するときにシステムによっても使用される。
【００２８】
テレビ番組欄は、２つのレベルからなる再帰的構造を持つのが好ましく、第１レベルは番組、映画、およびスポーツ・イベントを維持するレベルで、第２レベルはオプションであり、ＴＶシリーズ番組の全体の詳細を維持するレベルである。第２のレベルは、第１のレベルが番組のエピソードである場合のみ適用できる。この構造を利用することにより、システムはテレビ・シリーズの履歴に関してエピソードのリストを維持することができる。個々のエピソードを維持することにより、質問を書き、そのエピソードに関連付けることができるため、番組の放映（配給）期間全体にわたって質問を拡張してゆくことができる。
【００２９】
一般に、質問はエピソード、映画、またはスポーツ・イベントに関連付けられており、それぞれの個別番組には任意の数の質問を設定できる。
図３は、本発明の好ましい実施形態によりテレビの番組欄およびフライティング計画サブジェクト・エリアのアーキテクチャを示すエンティティ関係図である。この図では、ＳｈｏｗＰｒｏｇｒａｍＧｅｎｒｅ、ＳｈｏｗＣｒｅｄｉｔｓ、ＳｈｏｗＰｒｏｇｒａｍＣａｓｔ、Ｇｏｓｓｉｐ、ＳｈｏｗＰｒｏｇｒａｍ、ＢｒｏａｄｃａｓｔＳｔａｔｉｏｎ、ＢｒｏａｄｃａｓｔｅｒＰｒｏｇｒａｇｍＳｃｈｅｄｕｌｅおよびＢｒｏａｄｃａｓｔＳｈｏｗＡｄエンティティはテレビ番組欄およびフライティング計画テーブルであり、「Ｑｕｅｓｔｉｏｎ」エンティティは質問（Ｑｕｅｓｔｉｏｎｓ）テーブルのサブセットであり、ＭｅｍｂｅｒＦａｖｏｒｉｔｅＳｈｏｗｓエンティティは会員のテーブルのサブセットであり、ＳｕｒｖｅｙおよびＳｕｒｖｅｙＴｙｐｅＱｕｅｓｔｉｏｎｓエンティティは調査（Ｓｕｒｖｅｙｓ）テーブルであり、ＭｅｍｂｅｒＳｕｒｖｅｙエンティティは会員の応答のサブセットであり、Ａｄｓエンティティはクライアント（Ｃｌｉｅｎｔｓ）ドメイン構造テーブルであり、Ｇｅｎｒｅ、ＧｏｓｓｉｐＴｙｐｅ、ＴｉｍｅＺｏｎｅ、ＤＭＡ、ＺｉｐＣｏｄｅ、ＱｕｅｓｔｉｏｎＳｕｂｊｅｃｔ、ＬｅｖｅｌＯｆＤｉｆｆｌｃｕｌｔｙおよびＴｙｐｅＯＦＱｕｅｓｔｉｏｎエンティティはコード・テーブルのサブセットである。
【００３０】
テレビ番組欄サブジェクト・エリアのデータ・モデルの詳細を示している図１３ａと１３ｂを参照されたい。
調査質問の技術的概要
消費者サイトの調査セクションは、（１）アトミック・レベルの質問と（２）調査テンプレートの２つの別々の部分に分けるのが好ましい。
【００３１】
質問は、（１）番組関係の質問、（２）広告関係の質問、（３）その他の関係の質問の３つのサブジェクト・エリアに分類できる。それぞれの質問は、質問とその可能な回答で構成される。次に、質問に対する回答で、０個以上のフォローアップ質問が再帰的に呼び出され得る。最終的に、一組の質問が「アトミック」質問に組み立てられる。特定の調査に参加したときに会員に対して最初に提示されるのがこれらのアトミック質問である。本質的に、「アトミック」質問は一連の質問の中の最初の質問である。アトミック質問は、分解され１つの完全な質問を形成する、つまりそれ以上の質問を含まない質問である。これらの質問は国際化され、言語の数にかかわらず質問と回答が用意される。図４は、アトミック・レベルの質問の一例を示す。
【００３２】
好ましい実施形態における質問管理ツールセットのアーキテクチャ面の特徴の１つに、調査作成者が質問に「マーク」を付けられるという点がある。本質的に、調査作成者は、それぞれの質問の回答について、「ビン」および数量、つまり会員がその回答を選択した場合にこのビンに加えられる値を示す。これらの「ビン」は、広告主およびその他のクライアントが最終的に集計形式で受け取るものを含む。図５は、この広告質問「ビン」プロセスがどのように機能するかを示す一例である。
【００３３】
ビン・システムは、非常に柔軟性が高く、適応性も高い。それぞれの質問にビンをいくつでも関連付けることができ、その後、質問内のそれぞれの回答に関連付けることができる。質問の作成時に、管理者（たとえば、データ入力担当者、製品管理、システム内コンテンツ回転）は潜在的ビンのリストを使用して適用されるビンを示す。質問に対するそれぞれの回答の中で、管理者はビンのリストからそれらのビンに加える値を識別する。一般にこの値は１である。しかし、柔軟性を高めるために、任意の数値を使用できる。たとえば、好みについてテストする質問を定義することができる。この質問には、本当に好き、好き、好きではない、嫌いの４つの回答があり、それぞれビン値３、２、１、および０が設定される。個々の値は任意の方法で集計でき、たとえば、広告主は広告の有効性を示すデータを得ることができ、またネットワークまたはメディア・クライアントはそのコンテンツに関する好みを示すデータを得ることができる。ビンに追加されたそれぞれの項目は、たとえば、次の情報を含むことができる。
【００３４】
○　ＭｅｍｂｅｒＩＤ−特定の会員へのエントリを識別する。
○　Ｖａｌｕｅ−ビンに加えられるその値を識別する。
○　Ｎｕｍ Ｈｉｎｔｓ ｒｅｑｕｅｓｔｅｄ−会員にヒントを与えたかどうかを示す。
【００３５】
○　Ｓｈｏｗ Ｃｏｎｆｉｄｅｎｃｅ Ｆａｃｔｏｒ−調査で会員が正しく答えられた番組関係の質問のパーセンテージを示す。
○　Ａｄ Ｃｏｎｆｉｄｅｎｃｅ Ｆａｃｔｏｒ−調査で会員が正しく答えられた広告関係の質問のパーセンテージを示す。
【００３６】
○　Ｐｒｏｆｉｌｅ Ｍａｔｃｈｉｎｇ Ｉｎｄｉｃａｔｏｒ−資格のある会員に質問を出したかどうかを示す。
○　Ｔｉｍｅ Ｓｐｅｎｔ Ｒｅｓｐｏｎｄｉｎｇ−会員が質問の回答に要した推定時間を示す。
【００３７】
会員のプライバシーを保護するために情報集計してデータ・ウェアハウスに転送する前に会員固有の個人情報（たとえば、名前、電子メール・アドレス、社会保険番号、クレジットカード情報）を削除しておくのが好ましい。上記の情報から始めて、クライアントに対して「自分の広告を何人が識別したか？」、「何人がヒントを必要としたか？」、「ヒントがあってもメッセージを理解しなかったのは何人か？」などの質問の答えを提供することができる。さらに分析を実施し、年齢、性別、軍隊での地位、所得レベルなどの人口統計を考慮することもできる。
【００３８】
大部分、これらの質問群は１つの主要な違いがあっても同じ機能を持ち、番組関係の質問は特定の番組に関係し、広告関係の質問は特定のクライアントの広告に関係し、他の関係質問は特定の番組または広告問題に依存しない。ツールのコアは、柔軟な調査作成メカニズムとなる。システムは、番組または広告に縛られない他の種類の質問も許容するように設計するのが好ましい。本発明のシステムおよび方法の調査ツール・コンポーネントは、クライアント向けに追加調査を作成する場合にも使用することができる。
【００３９】
ビンは、質問回答に関連付けられ、質問は、広告、番組、またはその他の関係トピックに関連付けることができる。ドメイン構造とそのアクセス制御権を備えるシステムを使用することで、クライアント独自のドメイン構造を利用し権限のあるスタッフに広告の分析結果を提供することができる。
調査の技術的概要
一般に、リサーチ業界内では、問われる実際の質問をリストにした調査が作成される。本発明のシステムおよび方法はこれらの従来の調査方法を取り扱うように構成することもできるが、調査が質問のリストを使用する実際の調査よりも、よりテンプレートとして機能できる、さらに堅牢なアプローチを使用するのが好ましい。この機能によれば、管理者は調査を定義するときに処理規則を作成する。この機能によるテンプレート調査はいくつかの点で従来の特定の質問のリストとは異なる。まず、これを使用して無作為選択質問のサブセットを会員に提示することができる。第２に、会員が調査に答えることを決めたときにのみ、システムは会員に対してどの広告質問セットで質問するかを選択する。会員が番組を指示し、放送会社および放送時間を示した場合、システムは番組放映中に放映する広告を決定することができる。第３に、処理規則を使用することで、調査作成者は会員に尋ねる質問の動的置換を示すことができる。調査を作成するときに、管理者は会員に問う番組内容質問の数と広告関係内容質問を定義することができる。さらに、管理者は、調査テンプレートを拡張し質問を難易レベルなどのカテゴリや質問のカテゴリ（テーマ、キャラクターなど）に絞り込むことができる。この概念を示すために、サンプル・テンプレートを以下の表にまとめた。
【００４０】
【表１】

【００４１】
好ましい実施形態では、会員が調査を実施するときに、調査方式を解決し、番組および広告質問を無作為に選択し、無作為に順序付け、スタックに積む。質問をこのスタックの一番上から一度に１つずつ取り出し、会員に提示する。会員の回答に基づき質問がフォローアップ質問を呼ぶ場合、その質問または複数の質問がスタックに積まれる。スタックが空になると調査は完了である。調査周辺の詳細なプロセスおよび設計機能については「消費者調査インターフェイス」のセクションを参照のこと。
調査および質問の統合に関する技術的概要
図６は、好ましい実施形態による調査および質問のサブトピック・データ・モデルの一例を示すエンティティ関係図である。図では、ＳｈｏｗＰｒｏｇｒａｍおよびＢｒｏａｄｃａｓｔｅｒＰｒｏｇｒａｍＳｃｈｅｄｕｌｅエンティティはテレビ番組欄およびフライティング計画テーブルのサブセットを含み、Ａｄｓエンティティはドメイン構造テーブルであり、ＳｕｒｖｅｙＳｔａｔｕｓ、ＤｅｆａｕｌｔＲＴＶＤｏｌｌａｒ、ＱｕｅｓｔｉｏｎＳｕｂｊｅｃｔ、ＱｕｅｓｔｉｏｎＳｔａｔｕｓ、ＬｅｖｅｌＯｆＤｉｆｆｉｃｕｌｔｙ、ＱｕｅｓｔｉｏｎｓＣａｔｅｇｏｒｙ、ＴｙｐｅＯｆＱｕｅｓｔｉｏｎ、ＰｒｏｆｉｌｅＶａｒｉａｎｔＴｙｐｅ、ＰｒｏｆｉｌｅＶａｒｉａｎｔＶａｌｕｅ、ＯｔｈｅｒＳｕｒｖｅｙＴｙｐｅ、ＬａｎｇｕａｇｅＴｙｐｅおよびＲｅｃａｌｌＢｉｎｓエンティティはコード・テーブルのサブセットを含み、ＲＴＶＭｅｍｂｅｒエンティティは会員のテーブルのサブセットを含み、ＳｈｏｗｃａｓｅＧａｍｅｓ、Ｓｕｒｖｅｙ、ＳｕｒｖｅｙＳｕｐｐｏｒｔｅｄＬａｎｇｕａｇｅｓ、ＳｕｒｖｅｙＴｙｐｅＱｕｅｓｔｉｏｎｓ、ＳａｍｐｌｅＧａｍｅｓ、ＳａｍｐｌｅＱｕｅｓｔｉｏｎｓ、ＯｔｈｅｒＳｕｒｖｅｙｓ、ＯｔｈｅｒＳｕｒｖｅｙＰｒｏｆｉｌｅおよびＯｔｈｅｒＳｕｒｖｅｙＱｕｅｓｔｉｏｎｓエンティティは調査テーブルを含み、ＱｕｅｓｔｉｏｎＳｕｐｐｏｒｔｅｄＬａｎｇｕａｇｅｓ、ＱｕｅｓｔｉｏｎＴｒａｎｓｌａｔｉｏｎ、ＲｅｓｐｏｎｓｅＴｒａｎｓｌａｔｉｏｎ、ＱｕｅｓｔｉｏｎＲｅｓｐｏｎｓｅ、ＰｏｓｔＲｅｓｐｏｎｓｅＴｒａｎｓｌａｔｉｏｎ、Ｑｕｅｓｔｉｏｎ、ＦｏｌｌｏｗｕｐＱｕｅｓｔｉｏｎ、ＱｕｅｓｔｉｏｎＨｉｎｔｓ、ＨｉｎｔＴｒａｎｓｌａｔｉｏｎ、ＱｕｅｓｔｉｏｎＰｒｏｆｉｌｅ、ＱｕｅｓｔｉｏｎＢｉｎおよびＱｕｅｓｔｉｏｎＲｅｓｐｏｎｓｅＢｉｎｓエンティティは質問テーブルを含み、ＭｅｍｂｅｒＳｕｒｖｅｙ、ＭｅｍｂｅｒＳｕｒｖｅｙＱｕｅｓｔｉｏｎおよびＭｅｍｂｅｒＱｕｅｓｔｉｏｎＲｅｓｐｏｎｓｅエンティティは会員の回答のサブセットを含む。図１４ａおよび１４ｂは、質問および調査サブジェクト・エリアのデータ・モデルの詳細を示すエンティティ関係図である。
会員に関する技術的概要
会員情報は、たとえば、サインアップ人口統計情報、追加プロファイリング情報、お気に入りの番組およびランキング、引き換えおよび調査結果を含むことができる。会員の実際の調査回答およびその質問の回答に関連する専用通貨の額を維持する。実際のビン、したがってビンに加えられた価値は、調査および質問セクション内に保持することが好ましい。
【００４２】
会員の勘定残高を保持するために、ライン品目を会員の専用通貨口座に対して発生した取引毎に作成するのが好ましい。これらの取引は可能な限り、取引の全詳細へのリンクを保持する。たとえば、調査ライン品目は特定の会員調査記録、したがって全詳細取引記録への参照を保持する。引き換えライン品目は、会員が引き換えた品目の参照記録を保持する。
【００４３】
図７は、会員のサブトピック・データ・モデルのアーキテクチャの一例を示す。図では、ＰｒｉｚｅＬｅｖｅｌ、ＺｉｐＣｏｄｅ、ＭｅｍｂｅｒＳｔａｔｕｓ、ＰｒｏｆｉｌｅＶａｒｉａｎＶａｌｕｅ、ＰｒｏｆｌｌｅＶａｒｉａｎｔＴｙｐｅ、ＡｃｃｏｕｎｔＬｉｎｅＩｔｅｍＴｙｐｅ、ＲｅｃａｌｌＢｉｎｓエンティティはコード・テーブルのサブセットを含み、Ｓｕｒｖｅｙエンティティは調査テーブルのサブセットを含み、Ｑｕｅｓｔｉｏｎ、ＱｕｅｓｔｉｏｎＲｅｓｐｏｎｓｅおよびＱｕｅｓｔｉｏｎＲｅｓｐｏｎｓｅＢｉｎｓエンティティは質問テーブルのサブセットを含み、ＥｖｅｎｔＰｒｉｚｅｓ、Ｅｖｅｎｔ、ＥｖｅｎｔＳｐｏｎｓｏｒ、ＥｖｅｎｔＴｅａｍ、ＭｅｍｂｅｒＲｅｆｅｒｒａｌＰｒｏｇｒａｍ、ＲＴＶＭｅｍｂｅｒ、ＭｅｍｂｅｒＦａｖｏｒｉｔｅＳｈｏｗｓ、ＲＴＶＭｅｍｂｅｒＰｒｏｆｉｌｅ、ＭｅｍｂｅｒＡｃｃｏｕｎｔ、Ｒｅｄｅｍｐｔｉｏｎｓ、ＳｕｒｖｅｙｓＩｔｅｍｓおよびＯｔｈｅｒＩｔｅｍｓエンティティは会員のテーブルを含み、ＢｒｏａｄｃａｓｔＰｒｏｇｒａｍＳｃｈｅｄｕｌｅエンティティはテレビ番組欄およびフライティング計画テーブルのサブセットを含み、ＭｅｍｂｅｒＳｕｒｖｅｙおよびＭｅｍｂｅｒＱｕｅｓｔｉｏｎＲｅｓｐｏｎｓｅエンティティは会員の回答のサブセットを含む。図１５ａおよび１５ｂは、会員サブジェクト・エリアのデータ・モデルの詳細を示すエンティティ関係図である。
コミュニティ・イベントの技術的概要
消費者提案の全体的な効果を高めるために、会員の仮想コミュニティを編成し、コミュニティ・イベントで会員の他のチームとの競争を行うようにできる。イベントの有効期間中、各メンバーが貯めた専用通貨を数えてチームの集計得点とする。イベントが完了すると、チームの集計得点により終了時の順位が決定される。受賞者は、チームの集計得点に基づく。たとえば、第１位の賞は最高得点のチームに与えられ、第２位の賞は次点のチームに与えられる。タイの場合、チーム得点履歴を使用して、チームが勝ち取る賞パッケージを決定することができる。
【００４４】
図８は、コミュニティ・イベントのサブトピック・データ・モデルを示すエンティティ関係図である。図で、ＰｒｉｚｅＬｅｖｅｌエンティティはコード・テーブルのサブセットを含み、ＥｖｅｎｔＰｒｉｚｅｓ、Ｅｖｅｎｔ、ＥｖｅｎｔＳｐｏｎｓｏｒ、ＥｖｅｎｔＴｅａｍおよびＲＴＶＭｅｍｂｅｒエンティティは会員コミュニティ・テーブルを含み、Ａｄｖｅｒｔｉｓｅｒエンティティはドメイン構造テーブルを含み、ＳｈｏｐＰｒｏｄｕｃｔエンティティは報奨カタログ・テーブルを含む。図１５ａおよび１５ｂは、会員サブジェクト・エリアのデータ・モデルの詳細を示すエンティティ関係図である。
報奨の技術的概要
報奨は、たとえば、会員カタログを通じて会員が利用できる品目および／または、会員への価値提案全体の一部であるが、直接には会員の報奨カタログ内の品目として提供されない報奨（たとえば、二重、三重の専用通貨、および特別な懸賞品目）を含む。報奨エンジン全体は、言語の数に制限のないように設計されていることが好ましい。報奨エンジンは、報奨管理者が製品のリストだけでなく、製品の分散も保持できる自己管理モデルを中心に設計するのが好ましい。ある製品の分散は、他の製品の分散と異なる場合がある。たとえば、衣類の分散は、サイズと色を含む。
【００４５】
図９は、本発明の好ましい実施形態による報奨サブトピック・データ・モデルの一例を示すエンティティ関係図である。図では、ＺｉｐＣｏｄｅ、ＬａｎｇｕａｇｅＴｙｐｅ、ＳｗｅｅｐｓｔａｋｅＴｙｐｅ、ＣｏｕｎｔｒｙおよびＳｔａｔｅエンティティはコード・テーブルのサブセットを含み、ＲＴＶＭｅｍｂｅｒおよびＭｅｍｂｅｒＡｃｃｏｕｎｔエンティティは会員コミュニティ・テーブルを含み、ＳｈｏｐＳｅａｒｃｈｅｄ，ＳｈｏｐＢａｓｋｅｔＳｔａｔｓ、ＳｗｅｅｐｓｔａｋｅＰｌａｙｅｒｓ、ＫｅｙｗｏｒｄＩｇｎｏｒｅ、Ｓｗｅｅｐｓｔａｋｅ、ＳｗｅｅｐｓｔａｋｅＰｒｉｚｅｓ、ＳｈｏｐＷｉｎＬｉｓｔ、ＳｈｏｐＤｅｐａｒｔｍｅｎｔＦｅａｔｕｒｅｄ、ＳｈｏｐＰｒｏｄｕｃｔＬａｎｇｕａｇｅＶａｌｕｅ、ＳｈｏｐＰｒｏｄｕｃｔ、ＳｈｏｐＫｅｙｗｏｒｄ、ＳｈｏｐＶｅｎｄｏｒ、ＳｈｏｐＰｒｏｄｕｃｔＤｅｐａｒｔｍｅｎｔ、ＳｈｏｐＲｅｃｅｉｐｔ、ＳｈｏｐＶａｒｉａｎｔＴｙｐｅＬａｎｇｕａｇｅ、ＳｈｏｐＶａｒｉａｎｔＴｙｐｅ、ＳｈｏｐＶａｒｉａｎｔＶａｌｕｅ、ＳｈｏｐＰｒｏｄｕｃｔＶａｒｉａｎｔ、ＳｈｏｐＢａｓｋｅｔＩｔｅｍ、ＳｈｏｐＤｅｐａｒｔｍｅｎｔＬａｎｇａｇｅＶａｌｕｅ、ＳｈｏｐＤｅｐａｒｔｍｅｎｔ、ＳｈｏｐＢａｓｋｅｔ、ＳｈｏｐＲｅｃｅｉｐｔｉｔｅｍおよびＳｗｅｅｐｓｔａｋｅｓ２ＳＳＯエンティティは報奨カタログ・テーブルを含む。図１６ａおよび１６ｂは、報奨カタログ・サブジェクト・エリアのデータ・モデルの詳細を示すエンティティ関係図である。
消費者サイトの技術的まとめ
図１０は、消費者サイトの好ましいエンティティ関係モデル全体を示すエンティティ関係図である。このモデルは、ソリューション全体を生み出すさまざまなセクションの間の相互関係を示している。
サイト管理保守
調査管理アプリケーション
このアプリケーションの目的は、技術畑でないユーザがＷｅｂサイトに表示されるテスト（たとえば、ユーザに表示される一連の質問）を管理できるようにすることである。アプリケーションは、システムの管理者が使用する。非技術管理者は、質問、可能な解答、解答タイプ、ヒント、広告、およびポイント合計を挿入する。広告主は、広告キャンペーンおよび製品ブランドに質問を関連付けることができる。複数の質問を単一のテストにまとめる。テストを提示用Ｗｅｂサイトに表示する前に、管理者がそれを承認しなければならない。
【００４６】
調査管理アプリケーションの操作は次のようであるのが好ましい。管理者は、目的の言語を選択し、ＨＴＭＬテキスト・ボックスに質問を入力する。管理者はさらに、質問のタイプ、たとえば、チェックボックス、ラジオボタン、単一プルダウン、または複数プルダウンを選択する。管理者は、好きな数だけ解答を挿入することができる。質問に正しい解答があれば、ヒントを挿入できる。正しい解答をトリガしようと努力しているとヒントが会員に表示される。管理者は、質問に対し違った答え、正しい答えを行ったユーザに対し与えるポイント数を選択または入力する。また、ユーザが質問の答えを間違えたときに表示するバナー広告を選択することを許可することもできる。調査管理アプリケーションでは、管理者が質問のタイプ、つまり、質問がコンテンツ質問であるか広告質問であるかを選択できるようにするのが好ましい。
管理モジュール
調査作成ツールセットに組み込むのが好ましいビジネス機能の一部に次のようなものがある。
●　各オプションは、複数の並列条件分岐を持つ。つまり、オプションを選択することにより、消費者は複数の質問を受ける。
●　質問、回答、またはヒントに翻訳の欠落があれば、質問を公開できない。
●　ツールセットにより、会員はまだ有効な調査を再開し、会員が調査の範囲内でされた質問の記録を保持する。これにより、システムは、不完全な調査が与えられた場合に、ユーザが抜けたところから開始することができ、これを使用して、前の質問に戻ることにより会員が調査情報を歪めるのを制限することができる。
●　たとえば、以下のタイプの質問を使用できる。
【００４７】
○　はい／いいえ
○　真／偽
○　複数選択
○　適用されるすべてを選択する
○　スケーリング
●　事後メッセージをオプションごとに定義できる。
●　メディア（画像、音声、ビデオ．．．）を質問に関連付けることができる。
●　調査の作成者およびその調査の最終更新者を捕捉する。
●　個々の質問の作成者およびその質問の最終更新者を捕捉する。
●　質問に関する詳細を作成する。
【００４８】
○　質問の説明（複数言語）
○　メディア（画像、音声、ビデオ．．．）を各質問に関連付ける。メディアを配置し（質問の前、後、質問の中に埋め込む）、メディアのサイズを決定する。
【００４９】
○　すべての質問テキスト、オプション、およびヒントにＨＴＭＬタグを埋め込めるようにする。これにより、テキストを会員に表示する機能の柔軟性が高まる。
【００５０】
○　各質問の上にポイント通算合計を入れる。
○　各質問の上に質問番号および残りの質問の個数を示す。
○　各選択には、ポイント数が関連付けられている。
【００５１】
○　各選択には、潜在的フォローアップ質問が関連付けられている。
○　すべての調査で複数の言語をサポートする。
１．会員へのゲーム配信
ここで「Ｐｌａｙ ＲｅｗａｒｄＴＶ」と呼ぶソフトウェア・アプリケーションを用意し、ゲームを会員に配信し、会員がたとえば、テレビ番組および番組中に発生した広告に関する質問に答えることによりポイントを稼げるようにする。会員はテストを１回だけ受けられる。結果はデータベースに格納され、結果の分析がトレンドレポータ（データ・ウェアハウス）内で実行される。
２．広告選択アルゴリズム
次の広告選択方法例は、クライアント広告の有効性を測定するのに使用する。
ａ）　広告ショーケース規則−所定の時間範囲で、管理者は直接、会員の応答を測定したい広告のセットに注目できる。システムは、広告が選択された後、会員に尋ねる特定の質問に直接焦点を絞ることができる。
ｂ）　プロファイル・マッチング−この選択プロセスを効果的に管理するために、会員および広告にプロファイルが関連付けられている。たとえば、「性別」、「年齢」、「軍隊の地位」、および「所得水準」がある。システムは、会員のプロファイルおよび広告のプロファイル（番組で放送される）を相互参照して、会員のプロファイルと一番よく一致する広告を決定する。さらに効果的な選択基準を用意するために、広告に割り当てられたそれぞれのプロファイル・タイプにあるレベルの重要度（「ＳｅｌｅｃｔｉｏｎＷｅｉｇｈｔｉｎｇＦａｃｔｏｒ」）属性を割り当てる。たとえば、性別に関するマッチングは、所得水準に関するマッチングよりも重要度が高いと考える。広告主はある人口統計的構成に合わせてその広告のプロファイルを作成する（ターゲットとする）。システムは、「プロファイル・マッチング」を使用して、会員のプロファイルとそのプロファイルに向けられた広告とが最もよく一致するようにする。プロファイル相互参照により、この重み係数で広告を配列し、得点係数が最高の所定の個数の最上の広告を選択する。
【００５２】
上の規則を組み込んで、より精密で的が絞られた番組を会員向けに効果的に実施することができる。
フライティング計画広告とプロファイル・マッチング・アルゴリズムと比較して、プロファイル・マッチング得点を出力するのが好ましい。今日の日付を対象とする広告ショーケース規則がある場合、フライティング計画広告に対してその規則を適用し、ショーケース・マッチング得点を出力する。広告ショーケース・マッチングおよびプロファイル・マッチング得点を集計する。選択した実際の広告の個数は、調査テンプレートに基づいている。
質問選択アルゴリズム
会員および広告の場合のように、質問にオプションのプロファイリングが関連付けられているのが好ましい。広告の場合のように、質問のプロファイリングでは、適切なプロファイル・タイプを選択して、重要度のレベル（「ＳｅｌｅｃｔｉｏｎＷｅｉｇｈｔｉｎｇＦａｃｔｏｒ」）を示す必要がある。プロファイル相互参照により、この重み係数で質問のリストを配列し、得点係数が最高の所定の個数の最上の質問を選択する。このアルゴリズムを番組に対して適用し、尋ねられる実際の番組関連質問を決定する。選択された広告のそれぞれに対して類似のアルゴリズムを適用し（セクション４．５．４．１）、どの広告の質問を尋ねるかを決定する。番組および広告質問の実際の個数は、調査テンプレートに基づいている。
バックグラウンド処理ステップ
３．ステップ１−調査の選択。　本発明のシステムおよび方法の「情報システム」コンポーネントは、会員から番組、放送の日時、およびネットワーク・ブロードキャスタを捕捉する。これは、会員が特定の番組を選択した後実行される。この情報は、「ＢｒｏａｄｃａｓｔｅｒＰｒｏｇｒａｍＳｃｈｅｄｕｌｅ」プライマリ・キーの形式でパラメータとして提供される。情報システムでは、このレコードを使用して、「ＳｈｏｗＰｒｏｇｒａｍ」レコードおよび「Ｓｕｒｖｅｙ」に格納されている番組のアクティブな調査を決定する。
４．ステップ２−質問のタイプを識別する−ステップ１で識別された「Ｓｕｒｖｅｙ」レコードを使用して、調査の構成を決定し、システムは「Ｓｕｒｖｅｙ」および「ＳｕｒｖｅｙＩｔｅｍ」情報を使用して、質問の個数と明細を決定する。たとえば、番組コンテンツ質問の個数と広告コンテンツ質問の個数を決定する。さらに、「ＳｕｒｖｅｙＩｔｅｍｓ」テーブルで難易度レベル（容易、困難．．．）および会員に尋ねる潜在的質問のリストをさらに制限するカテゴリ（テーマ、キャラクター、設定．．．）を詳細に記述する。たとえば、調査には以下の調査項目がある。
【００５３】
○　２つの広告関係質問。難易度レベルが「やや難しい」の「テーマ」カテゴリに関する１つの質問。難易度レベルが「難しい」の「設定」カテゴリに関する１つの質問。
【００５４】
○　４つの番組関係質問。難易度レベルが「やや難しい」の「テーマ」カテゴリに関する２つの質問。難易度レベルが「難しい」の「設定」カテゴリに関する１つの質問。難易度レベルが「難しい」の「キャラクタ」カテゴリに関する１つの質問。
【００５５】
ステップ３−広告のフライティング計画を識別する−システムは、ステップ１内で決定した番組、時間、場所、およびネットワークを使用して、番組で放映されている実際のフライティング（広告）を決定する。これは、「ＢｒｏａｄｃａｓｔｅｒＰｒｏｇｒａｍＳｃｈｅｄｕｌｅ」と「ＢｒｏａｄｃａｓｔＳｈｏｗＡｄｓ」テーブルとを結合することにより行う。５．ステップ４−広告の選択−システムは、ステップ２および３の結果とともに上に列挙されている「広告選択アルゴリズム」を使用して、会員に尋ねる実際のアトミック質問を選択する。これらは、「ＭｅｍｂｅｒＳｕｒｖｅｙＱｕｅｓｔｉｏｎｓ」テーブル内に記録される。
６．ステップ５−質問の選択−システムは、ステップ２の結果とともに上に示されている「質問選択アルゴリズム」を使用して、会員に尋ねる実際のアトミック質問を選択する。これらは、「ＭｅｍｂｅｒＳｕｒｖｅｙＱｕｅｓｔｉｏｎｓ」テーブル内に記録される。
７．ステップ６−質問の順序付け−ステップ４および５から得られる質問は無作為に順序付けられ、会員に表示される。これは、番組および広告に関係する質問を含む。質問の順序が識別されると、スタックに積まれる。スタックは、次の解答されていない質問を引き出し会員に表示するメカニズムとして使用される。フォローアップ質問はスタックの一番上に積まれる。スタックが空になると調査は完了である。
８．フォアグラウンド処理ステップ
９．ステップ７−調査実行のボーナス額の決定−会員は、調査に参加すると基本レベルの専用通貨を与えられる。データベースにより、この金額がいくらであるかが決定され、この金額を会員に表示する。
１０．ステップ８−調査価値を決定する−システムは、質問の選択されたリストおよび質問のすべての潜在的リストをトラバースし、この調査時にこれらの質問に利用できる最大ポイント数を決定することができる。この数値は、ＭｅｍｂｅｒＳｕｒｖｅｙテーブル内に記録される。質問テーブルには、属性「ＴｏｔａｌＡｔｏｍｉｃＲＴＶＤｏｌｌａｒｓ」が含まれる。このフィールドには、この質問に対する潜在的専用通貨と、この質問構造に対する後続のすべてのフォローアップ質問が含まれる。この金額は調査スコアボード内で会員に表示される。
１１．ステップ９−会員に質問を表示する−システムはスタックの１番上から質問を取り出し、その質問と回答のリストをメンバーに表示する。質問の最大値（フォローアップ質問は考慮しない）は最大専用通貨金額が設定されている回答である。データベース（ＱｕｅｓｔｉｏｎＣｏｎｆｉｒｍａｔｉｏｎＭｅｓｓａｇｅ）にアクセスし、会員が質問に正しく回答したかまたは間違って回答したかを判別し、適切な確認メッセージを表示する。
【００５６】
ステップ１０−ヒントを表示する−会員が質問に対する回答を間違えた場合、システムはその質問に関連するヒントがあるかどうかを調べる。関連するヒントがある場合、そのヒント（テキストおよびメディア・ファイル）を表示し、その回答を空白のままにし、質問の値を引き下げ、会員が質問に再度回答をするのを許可する。
１２．ヒントは１つまたは複数の「ＱｕｅｓｔｉｏｎＨｉｎｔｓ」テーブルに格納される。低減額は、「質問」テーブル内にある。質問に対してヒントは０個以上関連付けることができる。ヒントに対しポイント内の減額があった場合、その質問に対する現在のポイント合計が更新される。ヒント・メディア・ファイルは、「ＱｕｅｓｔｉｏｎＨｉｎｔｓ」テーブル内に格納される。テキストは、「ＨｉｎｔＴｒａｎｓｌａｔｉｏｎ」テーブル内で関連付けられる。システムは、会員の回答がヒントが与えられたことに基づいていることを記録する。
【００５７】
ステップ１１−事後メッセージを表示する−会員が質問に回答した後何らかの「事後メッセージ」が表示され、次の質問に進む（ヒントはすでに表示されている）。各質問には、いったん定義されると、１つ例外はあるがすべての回答に対し表示される全体的な「事後回答」がありえる。各質問回答には、それ専用の事後回答メッセージおよび／またはメディア・ファイルが設定され得る。その場合であれば、会員がその応答を解答として選択したときに、そのメッセージがデフォルトの全体的な事後回答の代わりに表示される。
１３．ステップ１２−フォローアップ質問を処理する−システムは、ユーザの選択した回答に基づいて、フォローアップ質問があるかどうかをチェックする。これは、スタック上に表示されない（つまり、すでに尋ねられているか、またはこれから尋ねられる）回答のフォローアップ質問のすべてをスタックの一番上に積む。回答には０個またはそれ以上のフォローアップ質問を関連付けることができる。
【００５８】
ステップ１３−調査スコアボードを更新する−システムは、会員の選択した解答に基づいて、調査のスコアボードを再計算し、更新する。このスコアボードには、会員がこの調査で受け取ったポイント数の詳細が表示される。
【００５９】
ステップ１４−次の質問−会員が必要なすべての質問に答えるまでステップ９から１３までを繰り返す。
ステップ１５−会員がこの調査で受け取ったポイント総数を計算する。調査が完了すると、会員の勘定残高が更新される。さらに、取引が「ＭｅｍｂｅｒＡｃｃｏｕｎｔ」テーブルに記録される。
クライアント・サイトの技術的概要
クライアント・サイト全体を複数のサービス、つまりクライアント製品構造、クライアント・トレンドレポータ、および多次元分析に分類するのが好ましい。これらについて以下で詳述する。
クライアント製品ドメイン
クライアント製品ドメイン構造を使用することで、クライアントはその製品構造を自己定義することができる。各クライアントは、個別のドメイン構造を持ち、ただ１つのクライアントとそのクライアントの指定したユーザのみがその構造にアクセスできる。この重要な関係は、データベース・レベルで保持され、クライアントは他のクライアントのドメイン構造にアクセスすることができないようになっている。
【００６０】
本質的に、クライアントはその製品構造を定義し保持することができる。ドメイン構造は、レベルで構成され、それぞれのレベルに１つまたは複数のドメイン・レベル項目が設定されている。以下に、潜在的クライアント・ドメイン分類構造の一例を挙げる。レベル０にクライアントはおり、レベル１にクライアントの複数のブランドがあり、レベル２に各ブランド内の特定の製品がある。ドメイン内のレベルの数に制限はない。ドメイン項目に対するアクセス権がグループに与えられる。ユーザは１つまたは複数のグループに割り当てられる。複数のドメイン項目にアクセスできるユーザは、そのドメインのその部門の最高レベルが与えられる。１つのドメインの項目にアクセスすると、そのドメイン項目の下にあるすべての項目（レベル）のアクセス権が自動的に与えられる。割り当てられたサブドメインを保持するために、グループに対してセキュリティ権限が割り当てられる。これらの権限により、クライアントは、ユーザの作成、更新、および削除を行い、それらを彼らのサブドメイン内のグループに割り当てることができる。
【００６１】
クライアントの広告は、クライアント製品ドメイン構造のどのレベルにも属すことができる。たとえば、広告に特定の製品を関連づけ、その一方で他の広告をドメイン構造の他のレベルで定義することができる。特定の製品と関連付けられていない広告は、そのサブドメイン構造の下のすべてのレベルを対象とすることができる。たとえば、自動車メーカーは特定の自動車ではなく、すべての自動車を対象とする広告を設定できる。
【００６２】
さらに、システムは広告のさまざまな分類に十分対応できるように柔軟に設計されていることが好ましい。広告は、他のドメイン構造内に配置して広告の異なる分類に応じることができる。たとえば、広告の効果に関して集めたデータを、クライアントの製品構造に従って分類できるだけでなく、他の製品構造（ＮｉｅｌｓｅｎやＣＭＲなど）に再分類することもできる。この再分類は、広告に関する効果のデータを集める方法とは無関係に行える。
【００６３】
このクライアント製品ドメイン構造を使用することで、クライアントは広告の分析を非常に柔軟に実行することができる。その他の重要なコンポーネントとして、テレビ番組欄、調査および質問、会員のプロファイルがある。たとえば、広告の効果をドメイン・レベルでＡｄｓにより分析したり、効果をドメイン項目の下にあるすべての広告の効果を集計した結果とすることもできる。
【００６４】
図１１は、本発明の好ましい実施形態によるクライアント製品ドメイン構造データ・モデルを示すエンティティ関係図である。図では、ＢｒｏａｄｃａｓｔｅｒＰｒｏｇｒａｍＳｃｈｅｄｕｌｅおよびＢｒｏａｄｃａｓｔＳｈｏｗＡｄエンティティはテレビ番組欄およびフライティング計画テーブルのサブセットを含み、ＡｄＲｅｌａｔｅｄおよびＱｕｅｓｔｉｏｎエンティティは質問テーブルのサブセットを含み、ＡｄＰｒｏｆｉｌｅ、ＤｏｍａｉｎＡｄｓ、ＤｏｍａｉｎＣｏｎｔａｃｔｓ、Ａｄｓ、ＡｄＳｅｌｅｃｔｉｏｎ、Ｒｕｌｅ、ＡｄＳｅｌｅｃｔｉｏｎ、ＡｄＳｅｌｅｃｔｉｏｎＱｕｅｓｔｉｏｎｓおよびＡｄｖｅｒｔｉｓｅｒエンティティはドメイン構造テーブルを含み、ＺｉｐＣｏｄｅ、ＰｒｏｆｉｌｅＶａｒｉａｎｔＶａｌｕｅ、ＰｒｏｆｉｌｅＶａｒｉａｎｔＴｙｐｅ、ＤｏｍａｉｎおよびＴｙｐｅエンティティはコード・テーブルのサブセットを含む。図１７ａおよび１７ｂは、広告主ドメイン・サブジェクト・エリアのデータ・モデルの詳細を示すエンティティ関係図である。
【００６５】
ドメイン構造は、柔軟性の高い報告および分析サブシステムであり、クライアントはその製品階層を自由に自己管理することができる。最低レベル（データベース・エンティティおよび規則）、クライアントの広告を他の広告主のドメイン内に置くことはできない。さらに、ユーザはクライアントに割り当てられ、そのクライアントのドメイン構造の一部とする（データベース・レベルで実装する）ことしかできない。つまり、データベースでは、ユーザは他のクライアントのドメイン見ることはできない。
【００６６】
この構造により、クライアントの製品階層に選択的にアクセスできる安全な報告環境を実現できる。たとえば、管理者はドメイン構造の任意のレベルでユーザにアクセス権を与えることができる。さらに、ユーザにドメイン構造のさまざまなレベルのアクセス権を与えることもできる。たとえば、クライアントの広告代理店に、それが責任を有するドメイン構造のレベルだけのアクセス権を与えることができる。これらは、組織内の他のドメイン構造を認識しない。このため、クライアントは広告代理店に、実施しているキャンペーンの報告および分析結果をリアルタイムで伝えることができる。このような柔軟性の高い報告構造のため、さらに、ユーザが実行できる活動にも対応できる。たとえば、ドメイン構造の任意のレベルで管理グループを設置し、そのサブドメインの自己管理を行うようにできる。本質的に、このため、管理権限の委譲により製品構造の管理を行う負担およびボトルネックを低減することができる。
クライアント・トレンドレポータ
本発明の好ましい実施形態により、広告構造は、ここでクライアント・トレンドレポータと呼んでいる、トレンド報告コンポーネントを含む。クライアントが広告の効果を分析する際に使用するのが、報告構造である。消費者サイトからのデータを抽出し、変形し、報告に適している構造にロードする（ＥＴＬ）。このＥＴＬには３つの理由がある。まず１つは、ＥＴＬは広告主の報告に影響を及ぼす消費者の作業負荷を低減するために実行される。第２に、情報の収集を行う手段が、情報を報告する手段と非常に異なるという点である。第３に、ＥＴＬはクライアント・データから消費者データを物理的に抽象化するレベルを提供するために実行される。
クライアント・データ・モデル−スター・スキーマ
クライアント・データ・モデルは、報告構造をより効率的なものとするために、「スター・スキーマ」に編成することが好ましい。このスキーマは、１つの「事実」と複数の「次元」テーブルに細分される。事実テーブルは、次元の集計機能、またはより正確にいうと、次元を測定するものである。したがって、たとえば、事実テーブルはＢｉｎＱｕａｎｔｉｔｙ、ＮｕｍｂｅｒＯｆＨｉｎｔｓおよびＴｉｍｅＳｐｅｎｔＲｅｓｐｏｎｄｉｎｇを含む。
【００６７】
このデータ・モデルを使用することにより、システムは、どの特定の広告に対するどのような種類の回答がどの様な年代から得られたかなどのさまざまな種類の質問に対する答を与えることができる。図１２は、クライアント・ドメイン・サブジェクト・エリアを示すエンティティ関係図である。図から分かるように、次元を任意に組み合わせて効果の異なる集計（測定）を出力することができる。図では、ＳｈｏｗＣｒｅｄｉｔＤｉｍｅｎｓｉｏｎ、ＳｈｏｗＣａｓｔＤｉｍｅｎｓｉｏｎ、ＳｈｏｗＤｉｍｅｎｓｉｏｎ、ＳｈｏｗＧｅｎｒｅＤｉｍｅｎｓｉｏｎおよびＢｒｏａｄｃａｓｔｅｒＤｉｍｅｎｓｉｏｎエンティティはテレビ番組欄およびフライティング計画テーブルのサブセットを含み、ＲｅｓｐｏｎｓｅＤｉｍｅｎｓｉｏｎ、ＱｕｅｓｔｉｏｎＤｉｍｅｎｓｉｏｎおよびＱｕｅｓｔｉｏｎＨｉｎｔＤｉｍｅｎｓｉｏｎエンティティは質問テーブルのサブセットを含み、ＡｄＤｉｍｅｎｓｉｏｎ、ＡｄｖｅｒｔｉｓｅｒＤｉｍｅｎｓｉｏｎおよびＡｄＰｒｏｆｉｌｅＤｉｍｅｎｓｉｏｎエンティティはドメイン構造テーブルを含み、ＬｏｃａｔｉｏｎＤｉｍｅｎｓｉｏｎ、ＤａｔｅＤｉｍｅｎｓｉｏｎ、ＴｉｍｅＤｉｍｅｎｓｉｏｎおよびＲｅｃａｌＢｉｎＤｉｍｅｎｓｉｏｎエンティティはコード・テーブルのサブセットを含む。図１８は、クライアント・データウェアハウス・サブジェクト・エリアのデータ・モデルの詳細を示すエンティティ関係図である。
クライアント・ドメイン構造アプリケーション
このサブシステムでは、ＲＴＶまたはクライアント管理者は、クライアント・ドメイン構造の保守を行うためのツールを利用できる。セキュリティの観点から、１つのクライアントのみがドメイン構造内で広告を所有できる。このレベルのセキュリティは、データ・モデル・レベルで強制される。したがってそのクライアントに割り当てられているユーザのみをそのクライアントのドメイン構造に割り当てることができる。異なるユーザに、異なるレベルのアクセス権を割り当てることができる。ドメイン構造はさらに、広告の構造も含む。クライアント・ドメイン・サブシステムは、自己管理を完全に行えるように設計される。管理者は、管理者自身のドメイン・レベルの管理権限またはそれよりも下の管理権限をユーザに与えることができる。さらに、ドメイン・サブシステム内で他のセキュリティ権限も保持する。上記の機能は使い勝手のよいインターフェイス内に含まれる。
抽出、変換およびロード（ ＥＴＬ ）プロセス
ＥＴＬプロセスを使用して、情報をデータ・ウェアハウス内に入力し保持する。このプロセスにより、ソース・システム（消費者サイト）からデータを抽出し、報告要件に合わせて変換し、報告構造（スター・スキーマ）にロードする。
スター・スキーマの次元完全性ＥＴＬプロセス
このプロセスは、消費者サイトとクライアント・データ・ウェアハウス・システムとの間の完全性を維持するように定義される。さらにメタ・データ・テーブル「ＡｄｖｅｒｔｉｓｅｒＥＴＬＭｅｔａＤａｔａ」が消費者サイト・テーブルに追加される。このテーブルには、データ・ウェアハウスのデータを保持するために使用されるリスト・テーブルが含まれる。それぞれの行は、テーブルが正常に抽出され、変換され、データ・ウェアハウスにロードされた最終日時とともにテーブル名を含む。
【００６８】
以下の消費者サイト・テーブルは、システム完全性ＥＴＬプロセスを維持するように設定できる。
【００６９】
【表２】

【００７０】
広告主トレンドレポータ
トレンドレポータを使用して、広告主に広告キャンペーンの効果に関する見解を提示する。トレンドレポータは、スケジュール・レポートを表示し、また以下のことに関するレポートにも使用できる。
【００７１】
Ｎｉｅｌｓｅｎ Ａ１８−４９ Ｒｔｇ　−　所定の番組を見ていた合計Ａ１８−４９全体の％
ＲｅｗａｒｄＴＶ Ａ１８−４９ Ｒｔｇ　−　所定の番組任意の一部を見ており、エピソード質問に正しく解答したＲＴＶＡ１８−４９全体の％
ＲｅｗａｒｄＴＶ ｖｓ．ＮＴＩ Ｉｎｄｅｘ　−　１００を平均とした表したＲｅｗａｒｄＴＶ格付けとＮＴＩ格付けの関係。
【００７２】
Ａｖｇ．Ａｄ Ｒｅｃａｌｌ　−　この番組の平均的エピソード内の任意の広告を正確に想起する視聴者の平均％
Ｂｒａｎｄ Ｒｅｃａｌｌ　−　特定のブランドの広告を正確に想起するこの番組のこのエピソードの視聴者の％
Ｒｅｃａｌｌ Ｉｎｄｅｘ　−　１００を平均とするインデックスとして表したＡｄ ＲｅｃａｌｌとＢｒａｎｄ Ｒｅｃａｌｌの関係
ＲｅｗａｒｄＴＶ Ｒｅｃａｌｌ Ｒｔｇ　−　ＲｅｗａｒｄＴＶ格付けにＲｅｃａｌｌ Ｉｎｄｅｘを掛けて格付けを再計算し、この広告主に対する想起を改善できるよう番組を向上させる
Ｔｏｐ ２ ｂｏｘ ｌｉｋｉｎｇ　−　ブランドの広告を想起し、「大変好きだ」や「少し好きだ」などの格付けを広告に行った視聴者の％
％ ｆａｖｏｒｉｔｅｓ　−　３つのお気に入り番組の１つとしてこの番組を挙げた合計ユーザ全体の％
ＱＵＡＬ Ｓｃｏｒｅ　−　ブランド想起、上位２ボックス好み、およびお気に入り得点％を組み合わせたもの。これは、重みをつけて平均し、それぞれの異なる要因の重要度を反映するようにできる。
【００７３】
ＱＵＡＬ Ｉｎｄｅｘ　−　１００を平均とした場合をインデックスとして表したキャンペーンに対する各番組のＱＵＡＬ得点と平均ＱＵＡＬ得点の関係
広告主にシステムの到達範囲および効果を理解させるために、ユーザの人数に関する統計量を表示できる。このセクションで実行できる予定レポートを以下に示す。
【００７４】
ＲＴＶ＿Ｕｎｉｖｅｒｓｅ−Ｒｅｐｏｒｔ＿１　−　ユーザを年齢グループに分け、ユーザの数、構成割合、昨晩のカバー率を表示する。
ＲＴＶ＿Ｕｎｉｖｅｒｓｅ−Ｒｅｐｏｒｔ＿２　−　ユーザを年齢グループに分け、ユーザの数、構成割合、先週のカバー率を表示する。
【００７５】
ＲＴＶ＿Ｕｎｉｖｅｒｓｅ−Ｒｅｐｏｒｔ＿３　−　ユーザを年齢グループに分け、ユーザの数、構成割合、先月のカバー率を表示する。
ＲＴＶ＿Ｕｎｉｖｅｒｓｅ−Ｒｅｐｏｒｔ＿４　−　ユーザを年齢グループに分け、ユーザの数、構成割合、年初来カバー率を表示する。
【００７６】
ＲＴＶ＿Ｕｎｉｖｅｒｓｅ−Ｒｅｐｏｒｔ＿５　−　ユーザを性別グループに分け、ユーザの数、構成割合、昨晩のカバー率を表示する。
ＲＴＶ＿Ｕｎｉｖｅｒｓｅ−Ｒｅｐｏｒｔ＿６　−　ユーザを性別グループに分け、ユーザの数、構成割合、先週のカバー率を表示する。
【００７７】
ＲＴＶ＿Ｕｎｉｖｅｒｓｅ−Ｒｅｐｏｒｔ＿７　−　ユーザを性別グループに分け、ユーザの数、構成割合、先月のカバー率を表示する。
ＲＴＶ＿Ｕｎｉｖｅｒｓｅ−Ｒｅｐｏｒｔ＿８　−　ユーザを性別グループに分け、ユーザの数、構成割合、年初来のカバー率を表示する。
広告パフォーマンス
トレンドレポータを使用するとクライアントはチャートを含むすでに生成されたレポートを表示することができる。クライアントは、トレンドレポータによって提供されるデータに関係する広告を表示することができる。クライアントは、たとえば、ブランド想起、広告コピー分析、格付け比較、格付け分析、およびネットワーク・パフォーマンスなどの領域のデータを表示するすでに生成されているチャートを見ることができる。
【００７８】
レポートは、その日の指定された時刻に実行することができる。必要なすべてのデータをコンパイルし、ＨＴＭＬページに結果を表示する。これにより、クライアントは広告キャンペーンの効果を簡単に確認することができる。以下に、クライアントからアクセスできるレポートの例を示す。
【００７９】
ＲＴＶ＿Ａｄ＿Ｐｅｒｆｏｒｍａｎｃｅ−Ｒｅｐｏｒｔ＿１　−　昨晩の期間に広告が放映されたネットワークに基づきＲｅｗａｒｄＴＶ ｖｓ．ＮＴＩ Ｉｎｄｅｘ、Ｒｅｃａｌｌ Ｉｎｄｅｘ、Ｔｏｐ ２ ＬｉｋｉｎｇおよびＱｕａｌ Ｉｎｄｅｘの統計量を表示する。
【００８０】
ＲＴＶ＿Ａｄ＿Ｐｅｒｆｏｒｍａｎｃｅ−Ｒｅｐｏｒｔ＿２　−　昨晩の期間の広告コピーに基づきＲｅｗａｒｄＴＶ ｖｓ．ＮＴＩ Ｉｎｄｅｘ、Ｒｅｃａｌｌ Ｉｎｄｅｘ、Ｔｏｐ ２ ＬｉｋｉｎｇおよびＱｕａｌ Ｉｎｄｅｘの統計量を表示する。
【００８１】
ＲＴＶ＿Ａｄ＿Ｐｅｒｆｏｒｍａｎｃｅ−Ｒｅｐｏｒｔ＿３　−　昨晩の期間のジャンルに基づきＲｅｗａｒｄＴＶ ｖｓ．ＮＴＩ Ｉｎｄｅｘ、Ｒｅｃａｌｌ Ｉｎｄｅｘ、Ｔｏｐ ２ ＬｉｋｉｎｇおよびＱｕａｌ Ｉｎｄｅｘの統計量を表示する。
【００８２】
ＲＴＶ＿Ａｄ＿Ｐｅｒｆｏｒｍａｎｃｅ−Ｒｅｐｏｒｔ＿４　−　昨晩の期間の番組に基づきＲｅｗａｒｄＴＶ ｖｓ．ＮＴＩ Ｉｎｄｅｘ、Ｒｅｃａｌｌ Ｉｎｄｅｘ、Ｔｏｐ ２ ＬｉｋｉｎｇおよびＱｕａｌ Ｉｎｄｅｘの統計量を表示する。
【００８３】
ＲＴＶ＿Ａｄ＿Ｐｅｒｆｏｒｍａｎｃｅ−Ｒｅｐｏｒｔ＿５　−　先週の期間に広告が放映されたネットワークに基づきＲｅｗａｒｄＴＶ ｖｓ．ＮＴＩ Ｉｎｄｅｘ、Ｒｅｃａｌｌ Ｉｎｄｅｘ、Ｔｏｐ ２ ＬｉｋｉｎｇおよびＱｕａｌ Ｉｎｄｅｘの統計量を表示する。
【００８４】
ＲＴＶ＿Ａｄ＿Ｐｅｒｆｏｒｍａｎｃｅ−Ｒｅｐｏｒｔ＿６　−　先週の期間の広告コピーに基づきＲｅｗａｒｄＴＶ ｖｓ．ＮＴＩ Ｉｎｄｅｘ、Ｒｅｃａｌｌ Ｉｎｄｅｘ、Ｔｏｐ ２ ＬｉｋｉｎｇおよびＱｕａｌ Ｉｎｄｅｘの統計量を表示する。
【００８５】
ＲＴＶ＿Ａｄ＿Ｐｅｒｆｏｒｍａｎｃｅ−Ｒｅｐｏｒｔ＿７　−　先週の期間のジャンルに基づきＲｅｗａｒｄＴＶ ｖｓ．ＮＴＩ Ｉｎｄｅｘ、Ｒｅｃａｌｌ Ｉｎｄｅｘ、Ｔｏｐ ２ ＬｉｋｉｎｇおよびＱｕａｌ Ｉｎｄｅｘの統計量を表示する。
【００８６】
ＲＴＶ＿Ａｄ＿Ｐｅｒｆｏｒｍａｎｃｅ−Ｒｅｐｏｒｔ＿８　−　先週の期間の番組に基づきＲｅｗａｒｄＴＶ ｖｓ．ＮＴＩ Ｉｎｄｅｘ、Ｒｅｃａｌｌ Ｉｎｄｅｘ、Ｔｏｐ ２ ＬｉｋｉｎｇおよびＱｕａｌ Ｉｎｄｅｘの統計量を表示する。
【００８７】
ＲＴＶ＿Ａｄ＿Ｐｅｒｆｏｒｍａｎｃｅ−Ｒｅｐｏｒｔ＿９　−　先月の期間に広告が放映されたネットワークに基づきＲｅｗａｒｄＴＶ ｖｓ．ＮＴＩ Ｉｎｄｅｘ、Ｒｅｃａｌｌ Ｉｎｄｅｘ、Ｔｏｐ ２ ＬｉｋｉｎｇおよびＱｕａｌ Ｉｎｄｅｘの統計量を表示する。
【００８８】
ＲＴＶ＿Ａｄ＿Ｐｅｒｆｏｒｍａｎｃｅ−Ｒｅｐｏｒｔ＿１０　−　先月の期間の広告コピーに基づきＲｅｗａｒｄＴＶ ｖｓ．ＮＴＩ Ｉｎｄｅｘ、Ｒｅｃａｌｌ Ｉｎｄｅｘ、Ｔｏｐ ２ ＬｉｋｉｎｇおよびＱｕａｌ Ｉｎｄｅｘの統計量を表示する。
【００８９】
ＲＴＶ＿Ａｄ＿Ｐｅｒｆｏｒｍａｎｃｅ−Ｒｅｐｏｒｔ＿１１　−　先月の期間のジャンルに基づきＲｅｗａｒｄＴＶ ｖｓ．ＮＴＩ Ｉｎｄｅｘ、Ｒｅｃａｌｌ Ｉｎｄｅｘ、Ｔｏｐ ２ ＬｉｋｉｎｇおよびＱｕａｌ Ｉｎｄｅｘの統計量を表示する。
【００９０】
ＲＴＶ＿Ａｄ＿Ｐｅｒｆｏｒｍａｎｃｅ−Ｒｅｐｏｒｔ＿１２　−　先月の期間の番組に基づきＲｅｗａｒｄＴＶ ｖｓ．ＮＴＩ Ｉｎｄｅｘ、Ｒｅｃａｌｌ Ｉｎｄｅｘ、Ｔｏｐ ２ ＬｉｋｉｎｇおよびＱｕａｌ Ｉｎｄｅｘの統計量を表示する。
【００９１】
ＲＴＶ＿Ａｄ＿Ｐｅｒｆｏｒｍａｎｃｅ−Ｒｅｐｏｒｔ＿１３　−　年初来の期間に広告が放映されたネットワークに基づきＲｅｗａｒｄＴＶ ｖｓ．ＮＴＩ Ｉｎｄｅｘ、Ｒｅｃａｌｌ Ｉｎｄｅｘ、Ｔｏｐ ２ ＬｉｋｉｎｇおよびＱｕａｌ Ｉｎｄｅｘの統計量を表示する。
【００９２】
ＲＴＶ＿Ａｄ＿Ｐｅｒｆｏｒｍａｎｃｅ−Ｒｅｐｏｒｔ＿１４　−　年初来の期間の広告コピーに基づきＲｅｗａｒｄＴＶ ｖｓ．ＮＴＩ Ｉｎｄｅｘ、Ｒｅｃａｌｌ Ｉｎｄｅｘ、Ｔｏｐ ２ ＬｉｋｉｎｇおよびＱｕａｌ Ｉｎｄｅｘの統計量を表示する。
【００９３】
ＲＴＶ＿Ａｄ＿Ｐｅｒｆｏｒｍａｎｃｅ−Ｒｅｐｏｒｔ＿１５　−　年初来の期間のジャンルに基づきＲｅｗａｒｄＴＶ ｖｓ．ＮＴＩ Ｉｎｄｅｘ、Ｒｅｃａｌｌ Ｉｎｄｅｘ、Ｔｏｐ ２ ＬｉｋｉｎｇおよびＱｕａｌ Ｉｎｄｅｘの統計量を表示する。
【００９４】
ＲＴＶ＿Ａｄ＿Ｐｅｒｆｏｒｍａｎｃｅ−Ｒｅｐｏｒｔ＿１６　−　年初来の期間の番組に基づきＲｅｗａｒｄＴＶ ｖｓ．ＮＴＩ Ｉｎｄｅｘ、Ｒｅｃａｌｌ Ｉｎｄｅｘ、Ｔｏｐ ２ ＬｉｋｉｎｇおよびＱｕａｌ Ｉｎｄｅｘの統計量を表示する。
昨夜の広告パフォーマンス
クライアント・サイトは、テストを受けたユーザの人数に関する統計量を参照できるようクライアントにアクセス権を与えるセクションを含むのが好ましい。このセクションは拡張して広告主が期間別に統計量を参照できるようになっている。利用可能な期間としてはたとえば、以下のものがある。
【００９５】
ＲＴＶ＿Ｌａｓｔ＿Ｎｉｇｈｔ−Ｒｅｐｏｒｔ＿１　−　昨晩の期間に広告が放映されたネットワークに基づきＮｉｅｌｓｅｎ Ａ１８−４９ Ｒｔｇ、ＲｅｗａｒｄＴＶ Ａ１８−４９ Ｒｔｇ、Ａｖｇ．Ａｄ Ｒｅｃａｌｌ、Ｂｒａｎｄ Ｒｅｃａｌｌ、Ｒｅｃａｌｌ Ｒｔｇ、Ｔｏｐ２ ｂｏｘ ｌｉｋｉｎｇおよび％ ｆａｖｏｒｉｔｅｓの統計量を表示する。
【００９６】
ＲＴＶ＿Ｌａｓｔ＿Ｎｉｇｈｔ−Ｒｅｐｏｒｔ＿２　−　昨晩の期間の広告コピーに基づきＮｉｅｌｓｅｎ Ａ１８−４９ Ｒｔｇ、ＲｅｗａｒｄＴＶ Ａ１８−４９ Ｒｔｇ、Ａｖｇ．Ａｄ Ｒｅｃａｌｌ、Ｂｒａｎｄ Ｒｅｃａｌｌ、Ｒｅｃａｌｌ Ｒｔｇ、Ｔｏｐ２ ｂｏｘ ｌｉｋｉｎｇおよび％ ｆａｖｏｒｉｔｅｓの統計量を表示する。
【００９７】
ＲＴＶ＿Ｌａｓｔ＿Ｎｉｇｈｔ−Ｒｅｐｏｒｔ＿３　−　昨晩の期間のジャンルに基づきＮｉｅｌｓｅｎ Ａ１８−４９ Ｒｔｇ、ＲｅｗａｒｄＴＶ Ａ１８−４９ Ｒｔｇ、Ａｖｇ．Ａｄ Ｒｅｃａｌｌ、Ｂｒａｎｄ Ｒｅｃａｌｌ、Ｒｅｃａｌｌ Ｒｔｇ、Ｔｏｐ２ ｂｏｘ ｌｉｋｉｎｇおよび％ ｆａｖｏｒｉｔｅｓの統計量を表示する。
【００９８】
ＲＴＶ＿Ｌａｓｔ＿Ｎｉｇｈｔ−Ｒｅｐｏｒｔ＿４　−　昨晩の期間の番組に基づきＮｉｅｌｓｅｎ Ａ１８−４９ Ｒｔｇ、ＲｅｗａｒｄＴＶ Ａ１８−４９ Ｒｔｇ、Ａｖｇ．Ａｄ Ｒｅｃａｌｌ、Ｂｒａｎｄ Ｒｅｃａｌｌ、Ｒｅｃａｌｌ Ｒｔｇ、Ｔｏｐ２ ｂｏｘ ｌｉｋｉｎｇおよび％ ｆａｖｏｒｉｔｅｓの統計量を表示する。
【００９９】
ＲＴＶ＿Ｌａｓｔ＿Ｎｉｇｈｔ−Ｒｅｐｏｒｔ＿５　−　先週の期間に広告が放映されたネットワークに基づきＮｉｅｌｓｅｎ Ａ１８−４９ Ｒｔｇ、ＲｅｗａｒｄＴＶ Ａ１８−４９ Ｒｔｇ、Ａｖｇ．Ａｄ Ｒｅｃａｌｌ、Ｂｒａｎｄ Ｒｅｃａｌｌ、Ｒｅｃａｌｌ Ｒｔｇ、Ｔｏｐ２ ｂｏｘ ｌｉｋｉｎｇおよび％ ｆａｖｏｒｉｔｅｓの統計量を表示する。
【０１００】
ＲＴＶ＿Ｌａｓｔ＿Ｎｉｇｈｔ−Ｒｅｐｏｒｔ＿６　−　先週の期間の広告コピーに基づきＮｉｅｌｓｅｎ Ａ１８−４９ Ｒｔｇ、ＲｅｗａｒｄＴＶ Ａ１８−４９ Ｒｔｇ、Ａｖｇ．Ａｄ Ｒｅｃａｌｌ、Ｂｒａｎｄ Ｒｅｃａｌｌ、Ｒｅｃａｌｌ Ｒｔｇ、Ｔｏｐ２ ｂｏｘ ｌｉｋｉｎｇおよび％ ｆａｖｏｒｉｔｅｓの統計量を表示する。
【０１０１】
ＲＴＶ＿Ｌａｓｔ＿Ｎｉｇｈｔ−Ｒｅｐｏｒｔ＿７　−　先週の期間のジャンルに基づきＮｉｅｌｓｅｎ Ａ１８−４９ Ｒｔｇ、ＲｅｗａｒｄＴＶ Ａ１８−４９ Ｒｔｇ、Ａｖｇ．Ａｄ Ｒｅｃａｌｌ、Ｂｒａｎｄ Ｒｅｃａｌｌ、Ｒｅｃａｌｌ Ｒｔｇ、Ｔｏｐ２ ｂｏｘ ｌｉｋｉｎｇおよび％ ｆａｖｏｒｉｔｅｓの統計量を表示する。
【０１０２】
ＲＴＶ＿Ｌａｓｔ＿Ｎｉｇｈｔ−Ｒｅｐｏｒｔ＿８　−　先週の期間の番組に基づきＮｉｅｌｓｅｎ Ａ１８−４９ Ｒｔｇ、ＲｅｗａｒｄＴＶ Ａ１８−４９ Ｒｔｇ、Ａｖｇ．Ａｄ Ｒｅｃａｌｌ、Ｂｒａｎｄ Ｒｅｃａｌｌ、Ｒｅｃａｌｌ Ｒｔｇ、Ｔｏｐ２ ｂｏｘ ｌｉｋｉｎｇおよび％ ｆａｖｏｒｉｔｅｓの統計量を表示する。
【０１０３】
ＲＴＶ＿Ｌａｓｔ＿Ｎｉｇｈｔ−Ｒｅｐｏｒｔ＿９　−　先月の期間に広告が放映されたネットワークに基づきＮｉｅｌｓｅｎ Ａ１８−４９ Ｒｔｇ、ＲｅｗａｒｄＴＶ Ａ１８−４９ Ｒｔｇ、Ａｖｇ．Ａｄ Ｒｅｃａｌｌ、Ｂｒａｎｄ Ｒｅｃａｌｌ、Ｒｅｃａｌｌ Ｒｔｇ、Ｔｏｐ２ ｂｏｘ ｌｉｋｉｎｇおよび％ ｆａｖｏｒｉｔｅｓの統計量を表示する。
【０１０４】
ＲＴＶ＿Ｌａｓｔ＿Ｎｉｇｈｔ−Ｒｅｐｏｒｔ＿１０　−　先月の期間の広告コピーに基づきＮｉｅｌｓｅｎ Ａ１８−４９ Ｒｔｇ、ＲｅｗａｒｄＴＶ Ａ１８−４９ Ｒｔｇ、Ａｖｇ．Ａｄ Ｒｅｃａｌｌ、Ｂｒａｎｄ Ｒｅｃａｌｌ、Ｒｅｃａｌｌ Ｒｔｇ、Ｔｏｐ２ ｂｏｘ ｌｉｋｉｎｇおよび％ ｆａｖｏｒｉｔｅｓの統計量を表示する。
【０１０５】
ＲＴＶ＿Ｌａｓｔ＿Ｎｉｇｈｔ−Ｒｅｐｏｒｔ＿１１　−　先月の期間のジャンルに基づきＮｉｅｌｓｅｎ Ａ１８−４９ Ｒｔｇ、ＲｅｗａｒｄＴＶ Ａ１８−４９ Ｒｔｇ、Ａｖｇ．Ａｄ Ｒｅｃａｌｌ、Ｂｒａｎｄ Ｒｅｃａｌｌ、Ｒｅｃａｌｌ Ｒｔｇ、Ｔｏｐ２ ｂｏｘ ｌｉｋｉｎｇおよび％ ｆａｖｏｒｉｔｅｓの統計量を表示する。
【０１０６】
ＲＴＶ＿Ｌａｓｔ＿Ｎｉｇｈｔ−Ｒｅｐｏｒｔ＿１２　−　先月の期間の番組に基づきＮｉｅｌｓｅｎ Ａ１８−４９ Ｒｔｇ、ＲｅｗａｒｄＴＶ Ａ１８−４９ Ｒｔｇ、Ａｖｇ．ＲｅｗａｒｄＴＶ Ａｄ Ｒｅｃａｌｌ、Ｂｒａｎｄ Ｒｅｃａｌｌ、Ｒｅｃａｌｌ Ｒｔｇ、Ｔｏｐ２ ｂｏｘ ｌｉｋｉｎｇおよび％ ｆａｖｏｒｉｔｅｓの統計量を表示する。
【０１０７】
ＲＴＶ＿Ｌａｓｔ＿Ｎｉｇｈｔ−Ｒｅｐｏｒｔ＿１３　−　年初来の期間に広告が放映されたネットワークに基づきＮｉｅｌｓｅｎ Ａ１８−４９ Ｒｔｇ、ＲｅｗａｒｄＴＶ Ａ１８−４９ Ｒｔｇ、Ａｖｇ．Ａｄ Ｒｅｃａｌｌ、Ｂｒａｎｄ Ｒｅｃａｌｌ、Ｒｅｃａｌｌ Ｒｔｇ、Ｔｏｐ２ ｂｏｘ ｌｉｋｉｎｇおよび％ ｆａｖｏｒｉｔｅｓの統計量を表示する。
【０１０８】
ＲＴＶ＿Ｌａｓｔ＿Ｎｉｇｈｔ−Ｒｅｐｏｒｔ＿１４　−　年初来の期間の広告コピーに基づきＮｉｅｌｓｅｎ Ａ１８−４９ Ｒｔｇ、ＲｅｗａｒｄＴＶ Ａ１８−４９ Ｒｔｇ、Ａｖｇ．Ａｄ Ｒｅｃａｌｌ、Ｂｒａｎｄ Ｒｅｃａｌｌ、Ｒｅｃａｌｌ Ｒｔｇ、Ｔｏｐ２ ｂｏｘ ｌｉｋｉｎｇおよび％ ｆａｖｏｒｉｔｅｓの統計量を表示する。
【０１０９】
ＲＴＶ＿Ｌａｓｔ＿Ｎｉｇｈｔ−Ｒｅｐｏｒｔ＿１５　−　年初来の期間のジャンルに基づきＮｉｅｌｓｅｎ Ａ１８−４９ Ｒｔｇ、ＲｅｗａｒｄＴＶ Ａ１８−４９ Ｒｔｇ、Ａｖｇ．Ａｄ Ｒｅｃａｌｌ、Ｂｒａｎｄ Ｒｅｃａｌｌ、Ｒｅｃａｌｌ Ｒｔｇ、Ｔｏｐ２ ｂｏｘ ｌｉｋｉｎｇおよび％ ｆａｖｏｒｉｔｅｓの統計量を表示する。
【０１１０】
ＲＴＶ＿Ｌａｓｔ＿Ｎｉｇｈｔ−Ｒｅｐｏｒｔ＿１６　−　年初来の期間の番組に基づきＮｉｅｌｓｅｎ Ａ１８−４９ Ｒｔｇ、ＲｅｗａｒｄＴＶ Ａ１８−４９ Ｒｔｇ、Ａｖｇ．Ａｄ Ｒｅｃａｌｌ、Ｂｒａｎｄ Ｒｅｃａｌｌ、Ｒｅｃａｌｌ Ｒｔｇ、Ｔｏｐ２ ｂｏｘ ｌｉｋｉｎｇおよび％ ｆａｖｏｒｉｔｅｓの統計量を表示する。
【０１１１】
本発明のシステムは、会員がクレジットを稼ぐためにその回答を記録している間に会員向けにオンライン広告を放送するように設定できる。この点に関して、このシステムを利用すると、広告主は関連する番組のテレビ広告に晒されている同じ視聴者にオンライン広告を放映することができる。さらに、本発明のシステムおよび方法を使用すると、広告主はプリファレンス・データに基づき特にオンライン広告のターゲットを個々の会員とし、報奨および娯楽ベースの番組を利用して広告主の中核消費者グループ間の購入頻度を高めることができて好ましい。
【０１１２】
１４．　本発明の重要な利点として、実際に人が見ると得になるときに、関連する番組に対する視聴者のテレビ視聴習慣が高まるという点が挙げられる。視聴者の忠実さが高まる、つまり、頻繁にかつ一貫してテレビを見るようになる可能性があるということである。さらに、本発明の報奨システムは特に、新番組に対し有効であり、ネットワーク側でこのような番組に関連してより独自性の強い「通貨」を用意し、したがってこのような番組の頻繁な連続する視聴に対する報奨を増やすように選択できるため、週始めの番組放映で視聴者を獲得する代替え手段となる。
【０１１３】
本発明のシステムおよび方法を使用すれば、消費者のすべてのテレビ広告に対する反応の仕方をデータベースにすることができ、広告主がその努力の結果を競合相手または以前のキャンペーンと比較し対照することができる。データを分析して、特定のネットワークの番組のパフォーマンスを、視聴者によって生じる注目と忠実度のレベルに基づき測定することができる。
【０１１４】
本発明は、特定の実施形態を参照しながら詳細に説明したが、本発明の精神と範囲を逸脱することなく、各種の変更および修正を加えられることは当業者には明白であろう。したがって、本発明は付属の請求項とその同等の項目の範囲内に収まれば本発明の修正およびバリエーションをも対象とすることを意図する。
【図面の簡単な説明】
【図１】好ましい実施形態による本発明のいくつかの広範な原理を示す図である。
【図２】本発明のシステムの消費者サイト部分を実施するために使用できるアーキテクチャの一例を示すエンティティ関係図である。
【図３】本発明の好ましい実施形態によりテレビの番組欄およびフライティング計画サブジェクト・エリアのアーキテクチャを示すエンティティ関係図である。
【図４】アトミック・レベルの質問の一例を示すブロック図である。
【図５】広告質問「ビン」プロセスの一例を示すブロック図である。
【図６】本発明の好ましい実施形態による調査および質問のサブトピック・データ・モデルの一例を示すエンティティ関係図である。
【図７】会員のサブトピック・データ・モデルのアーキテクチャの一例を示すエンティティ関係図である。
【図８】コミュニティ・イベントのサブトピック・データ・モデルを示すエンティティ関係図である。
【図９】本発明の好ましい実施形態による報奨サブトピック・データ・モデルの一例を示すエンティティ関係図である。
【図１０】本発明の消費者サイトの好ましいエンティティ関係モデル全体を示すエンティティ関係図である。
【図１１】本発明の好ましい実施形態によるクライアント製品ドメイン構造データ・モデルを示すエンティティ関係図である。
【図１２】クライアント・ドメイン・サブジェクト・エリアを示すエンティティ関係図である。
【図１３】図１３ａは、テレビ番組欄サブジェクト・エリアの論理モデルを示すエンティティ関係図である。
図１３ｂは、テレビ番組欄サブジェクト・エリアの論理モデルを示すエンティティ関係図である。
【図１４】図１４ａは、質問および調査サブジェクト・エリアのデータ・モデルの詳細を示すエンティティ関係図である。
図１４ｂは、質問および調査サブジェクト・エリアのデータ・モデルの詳細を示すエンティティ関係図である。
【図１５】図１５ａは、会員サブジェクト・エリアのデータ・モデルの詳細を示すエンティティ関係図である。
図１５ｂは、会員サブジェクト・エリアのデータ・モデルの詳細を示すエンティティ関係図である。
【図１６】図１６ａは、報奨カタログ・サブジェクト・エリアのデータ・モデルの詳細を示すエンティティ関係図である。
図１６ｂは、報奨カタログ・サブジェクト・エリアのデータ・モデルの詳細を示すエンティティ関係図である。
【図１７】図１７ａは、広告主ドメイン・サブジェクト・エリアのデータ・モデルの詳細を示すエンティティ関係図である。
図１７ｂは、広告主ドメイン・サブジェクト・エリアのデータ・モデルの詳細を示すエンティティ関係図である。
【図１８】クライアント・データウェアハウス・サブジェクト・エリアのデータ・モデルの詳細を示すエンティティ関係図である。

Claims (25)

1. 報奨で奨励する雑学コンテストを実施し広告の効果を高める方法であって、
   コンピュータ・システム内に広告に関係する雑学問題の第１のセットを格納するステップと、
   前記コンピュータ・システム内にコンテンツに関係する雑学問題の第２のセットを格納するステップと、
   雑学問題の前記第１と第２のセットを前記のコンテンツとともに前記広告の放送に関連付けるステップと、
   会員に尋ねるために前記第１および第２の雑学問題のサブセットを選択するステップと、
   通信メディアを介して雑学問題の前記サブセットを前記会員に送信し、それに対する前記会員の回答を受信するステップと、
   雑学問題の前記サブセットに対する応答としての前記会員のパフォーマンスを得点として記録するステップと、
   前記得点の結果に基づき前記会員に報奨を提供するステップを含む方法。
2. 雑学問題の前記第１と第２のセットを放送に関連付ける前記のステップが前記放送と関連してどの広告を放映するかを示すデータを格納する、請求項１に記載の方法。
3. 前記放送がテレビ放送を含む、請求項１に記載の方法。
4. 前記放送がラジオ放送を含む、請求項１に記載の方法。
5. 前記放送がネットワーク接続を介するマルチメディア・コンテンツの表示を含む、請求項１に記載の方法。
6. 前記ネットワーク接続がインターネット接続を含む、請求項５に記載の方法。
7. 前記通信メディアがインターネット接続を含む、請求項１に記載の方法。
8. 前記通信メディアが対話型テレビを含む、請求項１に記載の方法。
9. 前記通信メディアがセットトップ・ボックスを含む、請求項１に記載の方法。
10. 前記通信メディアが無線デバイスを含む、請求項１に記載の方法。
11. 前記通信メディアがデータ・ネットワークを含む、請求項１に記載の方法。
12. ユーザ・プロファイルを使用して雑学コンテストを実施する方法であって、
    コンピュータ・システム内に広告に関係する雑学問題の第１のセットを格納するステップと、
    前記コンピュータ・システム内にコンテンツに関係する雑学問題の第２のセットを格納するステップと、
    雑学問題の前記第１と第２のセットを前記のコンテンツとともに前記広告の放送に関連付けるステップと、
    前記コンピュータ・システム内に少なくとも一人の会員の人口統計プロファイルを格納するステップと、
    前記人口統計プロファイルを使用して前記会員に尋ねる前記第１および第２の雑学問題のサブセットを選択するステップと、
    通信メディアを介して雑学問題の前記サブセットを前記会員に送信し、それに対する前記会員の回答を受信するステップを含む方法。
13. 前記コンピュータ・システムがネットワークを介して相互接続された複数のコンピュータを含む、請求項７に記載の方法。
14. 広告のパフォーマンスを測定する方法であって、
    コンピュータ・システム内に広告に関係する雑学問題の第１のセットを格納するステップと、
    前記コンピュータ・システム内にコンテンツに関係する雑学問題の第２のセットを格納するステップと、
    雑学問題の前記第１と第２のセットを前記のコンテンツとともに前記広告の放送に関連付けるステップと、
    会員に尋ねる前記第１および第２の雑学問題のサブセットを選択するステップと、
    通信メディアを介して雑学問題の前記サブセットを前記会員に送信し、それに対する前記会員の回答を受信するステップと、
    雑学問題の前記サブセットに対する前記会員の解答に基づいて広告パフォーマンスを測定するステップを含む方法。
15. 製品配置の効果を測定する方法であって、
    コンピュータ・システム内に製品に関係する雑学問題の第１のセットを格納するステップと、
    前記コンピュータ・システム内にコンテンツに関係する雑学問題の第２のセットを格納するステップと、
    雑学問題の前記第１と第２のセットを前記のコンテンツとともに前記広告の放送に関連付けるステップと、
    会員に尋ねる前記第１および第２の雑学問題のサブセットを選択するステップと、
    通信メディアを介して雑学問題の前記サブセットを前記会員に送信し、それに対する前記会員の回答を受信するステップと、
    雑学問題の前記サブセットに対する前記会員の解答に基づいて前記コンテンツの中に前記製品を配置する効果を測定するステップを含む方法。
16. 広告の効果を示すレポートを作成する方法であって、
    コンピュータ・システム内に前記広告に関係する雑学問題の第１のセットを格納するステップと、
    前記コンピュータ・システム内にコンテンツに関係する雑学問題の第２のセットを格納するステップと、
    雑学問題の前記第１と第２のセットを前記のコンテンツとともに前記広告の放送に関連付けるステップと、
    通信メディアを介して雑学問題の前記第１および第２のサブセットを会員に送信し、それに対する前記会員の回答を受信するステップと、
    雑学問題の前記第１および第２のセットへの解答を使用して、前記の広告の効果を示すレポートを作成するステップを含む方法。
17. レポート作成する前記ステップがさらに、前記レポートを作成するため複数の人口統計プロファイルを使用するステップを含む、請求項１１に記載のレポートを作成する方法。
18. 前記広告がコマーシャルを含む、請求項１１に記載の方法。
19. 前記広告が前記コンテンツの中に製品を配置することを含む、請求項１１に記載の方法。
20. 報奨で奨励する雑学コンテストを実施し広告の効果を高め、広告のパフォーマンスを測定し、コンテンツのパフォーマンスを測定する方法であって、
    コンピュータ・システム内に広告に関係する雑学問題の第１のセットを格納するステップと、
    前記コンピュータ・システム内にコンテンツに関係する雑学問題の第２のセットを格納するステップと、
    前記コンピュータ・システム内に少なくとも一人の会員の人口統計プロファイルを格納するステップと、
    雑学問題の前記第１と第２のセットを前記のコンテンツとともに前記広告の放送に関連付けるステップと、
    前記人口統計プロファイルを使用して前記放送を受信した会員に尋ねる前記第１および第２の雑学問題のサブセットを選択するステップと、
    通信メディアを介して雑学問題の前記サブセットを前記会員に送信し、それに対する前記会員の回答を受信するステップと、
    雑学問題の前記サブセットに対する応答としての前記会員のパフォーマンスを得点として記録するステップと、
    前記得点の結果に基づき前記会員に報奨を提供するステップと、
    雑学問題の前記第１および第２のセットへの解答を使用して、前記の広告の効果を示すレポートを作成するステップを含む方法。
21. 想起、理解、好み、またはその他の放送パフォーマンス測定を示すレポートを作成する方法であって、
    コンピュータ・システム内に放送のコンテンツに関係する雑学問題のセットを格納するステップと、
    前記雑学問題を前記コンテンツの放送に関連付けるステップと、
    通信メディアを介して雑学問題の前記セットを会員に送信し、それに対する前記会員の回答を受信するステップと、
    雑学問題の前記サブセットに対する応答としての前記会員のパフォーマンスを得点として記録するステップと、
    前記得点の結果に基づき前記会員に報奨を提供するステップと、
    雑学問題の前記セットに対する前記回答を使用して、少なくとも１つの放送パフォーマンス要因を示すレポートを作成するステップと、
    前期レポートをクライアントに送信するステップを含む方法。
22. 前記放送パフォーマンス要因が想起を含む、請求項１６に記載の方法。
23. 前記放送パフォーマンス要因が理解を含む、請求項１６に記載の方法。
24. 前記放送パフォーマンス要因が好みを含む、請求項１６に記載の方法。
25. 報奨で奨励する雑学コンテストを実施し広告の効果を高める方法であって、
    コンピュータ・システム内に広告に関係する雑学問題のセットを格納するステップと、
    雑学問題の前記セットを前記広告の放送の期間に関連付けるステップと、
    通信メディアを介して雑学問題の前記セットを会員に送信し、それに対する前記会員の回答を受信するステップと、
    雑学問題の前記セットに対する応答としての前記会員のパフォーマンスを得点として記録するステップと、
    前記得点の結果に基づき前記会員に報奨を提供するステップを含む方法。

Images