JP2006304286A - ネットワーク利用を追跡するための方法及びシステム - Google Patents

Abstract

【課題】番組配信システムで視聴者の番組選択及び利用情報を収集・処理すること。
【解決手段】画面表示装置に連結されるセットトップボックスにプログラミングを配布する双方向性のメディア配信ネットワークの加入者の利用を追跡するための方法及びシステムが開示される。このシステムでは、各々のアプリケーションは、アプリケーションのID、イベント及びタイムスタンプを含むイベント記録を形成する。収集されたイベント記録は、一時保存され、圧縮され、パケット単位に区切られ、統合処理装置に送られ、そこでイベント記録とネットワークを通じて配布されたプログラミングを示す内容データとが統合される。そのイベント記録と内容データは、各加入者のセットトップボックスのイベント経時記録を形成し、それはある選択された時間にわたる加入者の行動あるいは加入者により実行されたプログラムを示す。
【選択図】図５

Description

ネットワーク利用を追跡するための方法及びシステム
本発明は、ネットワークアプリケーション、特に双方向性メディアあるいはビデオ番組の配信を含むネットワークアプリケーションの加入者による利用を追跡するための方法及び装置（システム）に関する。

発明の背景
テレビ放送及びケーブルテレビは、視覚メディア市場で長い間優勢であった。しかしながら、新しい通信技術が、ビデオオンデマンド、双方向性ビデオ、対話型ゲーム、通信販売、対話型広告のような新しい種類のメディアを急速に発展させてきた。通常のテレビ放送とは異なり、これらサービスの視聴者は、通常、“加入者”として料金を支払っている。同時に広告業者からの支払はこれらメディアサービスの配信費用の大部分に費やされている。

広告業者が費やした費用の効果を測るために、広告業者は視聴者の視聴パターンに関する情報をずっと求めてきた。そのような情報を収集するために数多くの装置や技術が存在する。例えばCheungによる米国特許第4,258,386号及びNickersonらによる米国特許第4,556,030号は、ある特定の時間にどのチャンネルを見ているかといった視聴習慣を明らかにするデータを蓄積するために、視聴者のテレビジョンセット（“ＴＶ”）をモニターするための装置を視聴者の家庭に配備することの包括的な概念を記述している。蓄積データは、分析のために電話回線を通じて中央に送られる。Cheungはデータを、予め選択した特異的な時間“窓”に、特定のモニター局から送り、その窓の時間内に電送が妨害されると、Cheungのシステムはデータを別の時間に送ることになる。

その他のシステム及び方法は、視聴されているチャンネル番号および視聴時間以外のデータを用いている。しかしながら、大抵その情報は視聴者のわずかな部分を成すに過ぎない。このようにMcKennaらの米国特許第4,816,904号、Allison３世らの第4,912,552号、Welshの第5,374,951号では、どれもが“パネリスト”のＴＶ利用をモニターすることを開示しており、その目的は、パネリストの視聴パターンに関する情報を、特定のマーケティング情報と同様に収集することにある。一般に、パネリストのモニターは、選択された“パネリスト”グループへの広告効果を評価するために用いられ、その各々は、“パネル”を構成するグループ、大概は特定の地域の一世帯である。

モニターは、どの宣伝広告およびＴＶ番組がパネリストに視聴されているかを調査するだけでなく、どの製品がパネリストに購入されているかについての情報も収集することが可能であろう。例えば、McKennaの米国特許では、パネリストの家庭に設置される遠隔操作によるデータ収集装置が開示されており、その装置により視聴者識別データおよびＴＶ機能（例えば、チャンネル視聴、ビデオ視聴、ゲーム使用など）がモニターされることが開示されている。さらに、購入された品物のバーコード入力という便利な手法が設けられている。モニターされたデータは電話回線を通して中央に送られ、そこでは、パネリストに質問事項をダウンロードし回答を得ることもできる。Allison及びWelshは同様のモニタリングシステムを開示している。特定の時間にパネリストが視聴しているチャンネル番号を単純にモニターする代りに、Welshは、予め選択されたコマーシャルを識別する識別情報をモニターすることを開示しており、その情報はテレビ信号の中断間隔に伝えられる。パネリストに視聴された特定のコマーシャルを識別する識別情報を検出および保存した後、そのデータは分析のため電話回線によって中央に伝送される。

モニターシステムは、初期の双方向性メディアシステムのいくつかにも利用されてきた。Remillardによる米国特許第5,404,393号は双方向性のＴＶシステムを開示している。システムの他の要素の間で、制御部がＴＶチャンネル及びチャンネルを選択した日時の記録をモニターすることにより、間接的に視聴者の番組選択をモニターすることが可能になる。データは“利用者情報”として集められ、電話回線を通じて適切な施設に送られる。

それにもかかわらず、Allison、McKenna及びWelshのようなパネリスト監視システム、あるいは、Remillardのような双方向性テレビジョン監視システムは、純粋にＴＶチューニングデータというよりはそれ以外の監視データを供給するものであり、限定されたグループだけのためのものである。例えば、より多くのデータ（購入情報など）が収集される場合、システムはシステム全体の加入者のためというよりはむしろパネリストグループのためだけに用いられている。同様にバーコード調査を行うMcKennaのようなシステムは、受動的かつ自動的なデータ収集ではなく、データ収集のために利用者の動作を必要とする煩わしいものである。その他のシステムは、加入者の利用頻度により生ずるデータの一部分のみ、あるいは、視聴率情報の一部分のみを捕えようとするものである。例えば、前述のシステムは、通常、加入者が番組の間に流されるコマーシャルを見ていたかどうかよりも、視聴しているテレビ番組を特定することで視聴率情報を得るものである。

おそらくより重要なこととして、番組情報と視聴されているチャンネルの“生”情報とを適合させようとする装置（システム）はこれまで存在していない。加えて、より“的を絞った”広告を供給するために、特定の利用者についての人口統計情報と、視聴パターン情報とを結び付けるシステムも存在しない。

発明の概要
本発明では、加入者の行動あるいは番組の変更などの、関心のあるあらゆる“イベント”についての情報を取得するために、加入者のセットトップボックス（“ＳＴＢ”）に結合した収集装置を使用する。視聴しているチャンネルから音量の変化、呼び出されている双方向性アプリケーションまでの事実上どのようなイベントに関するデータでも、収集装置によって収集することが可能であろう。それらのデータから成るイベント記録は、関連するアプリケーション自体及びイベント時間と同様に、逐次保存される。定期的にあるいは命令によって、イベント記録は、ＳＴＢとの二重通信が可能な双方向性ネットワークなどを通じて、一時保存領域から統合処理装置にアップロードされる。統合処理装置は、そのメディア配信ネットワークに連結されるかその一部をなすヘッドエンドサーバーあるいはワークステーションコンピュータであり、次のものを受信する。（１）イベントデータ及び（２）そのシステムが展開されている地域を通じて配信あるいは放送される番組内容を識別する内容データ（content data）。次いで、時間ごとに発生した特定のイベントを示す経時記録が、各加入者ごとに生成されるであろう。イベントの経時記録は、単に視聴されているチャンネル及び日時を特定するというよりはむしろ、選択した時間にわたって（例えば２４時間）、加入者が選択あるいは視聴している番組あるいは双方向性アプリケーションを示す。

この統合処理装置は、収集され統合されたデータをさらに選別し、一人の利用者の視聴パターンの記述から、選択した時間内に特定の番組を視聴したあるいは参加した数多くの利用者の非常に詳細な視聴パターンにまで渡る報告を作成する。そのうえ、ある特定の加入者あるいは加入者グループの視聴および関連する購買パターンに関する詳細な情報を供給するために、その情報は宣伝広告及び人口統計情報と結び付けることが可能である。

従って、本発明は、加入者に呼び出された各アプリケーションに関する詳細情報及び視聴されている番組の種類に関する情報を取得するための方法を含んでいる。第一の段階は、関心のあるイベントの発生を示すデータを識別することである。これらイベントは以下のものを含んでいる。視聴されているチャンネル、他のチャンネルへの切り替え、コマーシャルによる中断あるいは新しい番組への移行に起因する番組の受動的変化、ビデオカセットレコーダー（ＶＣＲ）あるいはその他付属装置の利用、双方向性アプリケーションの呼び出し及びそのアプリケーション実行中にシステムに与えられる加入者の命令である。イベントデータは、開始及び終了時刻、加入者のＳＴＢの識別情報、あるいは、特定の双方向性あるいは他のアプリケーションをも記録するのに必要となる特異的データの識別情報も含んでいる。

イベント記録はこの収集データから構成され、双方向性のメディア配信ネットワークあるいは他のメディア配信ネットワークを通じて、ヘッドエンドサーバーあるいは第三者のデータ解析システムにアップロードされる前に一時保存される。アップロードの前に、収集データは送信のために圧縮され、パケット単位に区切られ得る。

本発明のシステムあるいは方法を用いることにより、サービス供給者（プロバイダ）は視聴率情報と、加入者の視聴パターン及び双方向アプリケーションの利用に関する詳細情報とを入手することが可能になる。それゆえ、本発明では、広告を含めた特定の番組を視聴している数多くの加入者を追跡することが可能である。また、ビデオオンデマンドのような特定の双方向アプリケーションの利用状況の追跡も可能である。本発明は、番組内容を示すデータと、チャンネル、または、加入者に呼び出されたあるいは利用されたアプリケーションを示すイベントデータとを自動的に適合させる。これは、本発明が利用者の“チャンネルサーフィン”を総合的に追跡することを可能にする。また、本発明では、加入者に対してコマーシャルを最適なものにするために、加入者の人口統計あるいは広告に関する情報を、視聴パターン情報と比較することができる。例えば、ある人口統計上選ばれた背景の加入者が目的のコマーシャルを見たかどうか、あるいは、選択されたコマーシャルを見た加入者の人口統計を特定することができる。

この分野に十分精通した人物であれば、本発明が様々な種類のメディア配信ネットワークシステムに利用できるであろうことを認識するはずである。例えば、本発明の方法あるいはシステムは、双方向性メディア配信システム、従来型のケーブルテレビジョンネットワークを使用法において改善したシステム、無線のケーブルテレビジョンネットワークシステム、あるいは衛星テレビジョンネットワークシステムなどに展開できる。

従って、本発明の目的は、加入者の視聴パターン及びメディア配信システム利用についての情報を収集するためのシステム及び方法を提供することである。

本発明の別の目的は、特定の加入者に利用されているネットワークアプリケーション、特に双方向性アプリケーションを特定するためのシステム及び方法を提供することである。

本発明の付加的な目的は、収集した情報を統合処理装置に通信するためのシステム及び方法を提供することである。

本発明の更なる目的は、メディア配信システムを通して配布される番組の内容についての情報を統合処理装置に供給することである。

本発明の別の目的は、加入者に視聴された番組、あるいは加入者によって呼び出されたネットワークアプリケーションについての総合的な情報を取得するために、収集した情報と番組情報とを統合するシステム及び方法を提供することである。本発明のその他の目的、特徴、および利点は、本明細書の以下の内容を読むことによって明らかとなるであろう。

図１は、本発明のシステムの一具体例における構成要素のブロックダイヤグラムを示している。 図２は、図１に示される本発明の具体例に用いられ、且つクリックストリーム処理装置を備える、セットトップボックスのブロックダイヤグラムを示している。 図３は、収集されたイベントデータのアップロードサイクルを表す概略図を示している。 図４Ａは、収集されたイベントデータが、ある選択されたセットトップボックスからネットワークを通じて、図１及び図５に描かれている中継サーバーにアップロードされる様子を示している。 図４Ｂは、収集されたイベントデータが、ある選択されたセットトップボックスからネットワークを通じて、図１及び図５に描かれている中継サーバーにアップロードされる様子を示している。 図５は、中継サーバー、その機能、及び様々なデータソースとの内部連絡の概要を示している。 図６Ａは、本発明により収集されたイベント及び内容データを統合し解析するために必要とされるシステムの要素を示している。 図６Ｂは、統合及び解析処理を完了するために必要な内容データの優先順位指定を示している。 図７Ａは、本発明の統合及び解析処理の結果を示している。 図７Ｂは、本発明の統合及び解析処理の結果を示している。

図面の詳細な説明
システムの概要
図１は、システム２０の構成要素のブロックダイヤグラムを示している。システム２０は、人口統計及び番組の視聴率データ収集並びに解析のシステムであり、このシステム２０はBellSouth Interactive Media Servicesにより展開される双方向性ビデオサービスネットワークのような双方向性メディア配信システムを利用するために配備されるであろう。この双方向性システムは、本発明の譲受人に譲渡された、同時に係属している出願番号第08/428,718号に記述されており、その内容すべてを援用し本文の記載の一部とする。しかしながら、この分野に精通している者であれば、本発明が、様々な種類の双方向性メディア配信システム、標準的なあるいは無線のケーブルテレビジョンシステム、衛星テレビジョンシステム、又は、テレビセットのような加入者の画面表示装置に設置されるセットトップボックス（“ＳＴＢ“）３０との二重通信方式を可能にする（おそらく、独立した（例えば電話回線）ネットワークを介した返信経路を持つ）他のメディア配信システムなどにも、利用できることを認識するはずである。

どのような場合においても、図１は、様々なシステム２０の要素並びに補助システムを示しており、それらは、収集した情報、データエラーの検出機構及びデータ受信通知を送信するために相互に通信する。簡単に説明すると、ＳＴＢ３０は、配信ネットワーク５２を介してビデオサーバー６０と通信し、ビデオサーバー６０はビデオ／オブジェクト蓄積データベース５４を伴うビデオ交換エンジン（“ＶＴＥ”）のようなものであり、Hewlett Packard（“ＨＰ”）から入手できるであろう。ビデオサーバー６０は、Sybaseから入手されるInter Media Serverのようなビデオ制御サーバー５６に連結され、データベース５８を伴うＨＰ９０００のようなプラットフォーム上に配備される。ビデオサーバー制御部５６は、ビデオサーバー６０及びその使用に関する履歴情報を制御する。中継サーバー７０は、収集されたイベント記録を受信する。これらの“イベント記録”はビデオサーバー制御部５６を通過する。この制御部はマーケティング及び情報システム（“ＭＫＩＳ”）１００と連結されている。このシステムは中継サーバー６０と連結され、中継サーバーは、次のものを受信する。（１）イベント記録、及び、（２）図１に示されている様々なソース１２０、１４０及び１６０からの内容データ。この内容データは、すべての加入者に双方向性ネットワークを通して利用可能な番組の内容を示すデータである。ＭＫＩＳ１００は、顧客サービスとして供給できる第三者の検索及び解析システム１１０に連結されるであろう。

ＳＴＢ３０は、以下を行うプラットフォームを備える。（１）内容を選択したビデオ形式（例えばＮＴＳＣやＰＡＬ）に変換し、加入者に提供する。（２）双方向性システムのために、メッセージをネットワーク５２を通して中継サーバー７０と交換する（ビデオデータを含む）。ＳＴＢ３０はまた、以下のことを行えるプラットフォームを含み得るであろう。（１）手に持てる遠隔操作ユニットのような利用者の入力装置からのメッセージを受信する。（２）ビデオ信号を、ネットワーク固有のフォーマットからテレビあるいは他の画面表示装置で用いることができるフォーマットに変換する。（３）テキスト情報あるいは映像情報を、ビデオ映像上に“上書き”するためにその情報をビデオ信号の流れに挿入する。（４）利用者に映像あるいは音響の繰り返しを提供する。（５）最も基本的な機能として、従来のテレビ放送信号を、ＳＴＢ３０に連結された画面表示装置に単に送信する。ＳＴＢに類似した用語には次のものが含まれる。セット トップ端末（“ＳＴＴ”）、ケーブル変換器、家庭用通信端末（“ＨＣＴ”）、及び加入者に番組を見せるための画面表示装置に連結しうる、あるいはその一部分をなしうるあらゆる装置。一般的には、ＳＴＢ３０はScientific Atlantaから入手可能なRichmondあるいは8600X、General Instrumentsから入手可能なCFT2200、Thomson’s DSSあるいは次のものを装備したどのような他の装置であってもよい。（１）マイクロプロセッサー、（２）操作命令及び保存のための記憶装置、（３） 加入者の遠隔操作装置あるいは操作板からの加入者の命令を受理するための制御インターフェース。

図面に示されているシステム２０の特定の具体例のために、システム２０を通しての送信のためにパッケージされた収集イベント記録は、“クリックストリーム”データあるいは情報と呼ばれる。図２は、ＳＴＢ３０のＤＲＡＭなどの記憶装置（メモリ）に存在するクリックストリーム処理装置３４を示しており、クリックストリーム処理装置３４は、クリックストリームの中核部３６、一時記憶装置（バッファ）４２あるいは４４、クリックストリームアップロード実行部４０、クリックストリーム制御部３８、及び、クリックストリームイベントＡＰＩ（アプリケーションプログラミングインタフェース）４１を内部に有する。

簡単に説明すると、クリックストリーム中核部３６は、クリックストリームイベントＡＰＩ４１を通して、様々なネットワークアプリケーションによりもたらされたイベントを一時的に保存する。クリックストリーム制御部３８は、中継サーバー７０からの制御命令を受け取り、適宜料金を保存する。典型的な命令は、データリンクを通して拡張スーパーフレーム（“ＥＳＦ”）に送られ、そしてクリックストリームデータのアップロードを制御し得る。クリックストリームのアップロード実行部４０はシステム２０からの制御命令を受け入れる。その命令は、ネットワーク５２の逆経路を通り、収集されたクリックストリームデータのアップロードを制御する。また、クリックストリームアップロード実行部４０はそれらの命令の適切な荷重料金及び使用可能な記憶容量を保存し、アップロードされたクリックストリームデータの受信を確認するために送られたそのメッセージを受け取る。

再び図１を参照すると、ビデオサーバー６０は、ビデオ／オブジェクト記憶装置５４からの情報をシステム２０が展開される特定の双方向システムに供給する。ＳＴＢ３０で収集されたクリックストリームデータは、数多くの経路で中継サーバー７０にアップロードすることが可能である。例えば、図１は、配信ネットワーク５２が直接中継サーバー７０に連結する可能性を示しており、ＳＴＢ３０から送信されたクリックストリームデータパケットを中継サーバー７０に直接送ることを可能にし、次いで中継サーバー７０はネットワーク５２を経てデータ受信の通知を返信する。ネットワーク管理制御部５０は、ネットワーク５２を通る情報の流れを制御する。また、図１、及び、より詳しい図４Ｂには、クリックストリームデータパケットが、ビデオサーバー６０に繋がる配信ネットワーク５２に送信されるであろうことが示されている。ビデオサーバー６０は、様々なＳＴＢ３０からのクリックストリームデータ及びＳＴＢ３０に返却される受信通知の両方を通過させる。ビデオサーバー６０内部の情報送信部は、通信内容を適切な行き先に向け直す。ビデオサーバー制御部５６は同様に、中継サーバー７０に向かうＳＴＢ３０のクリックストリームデータの通過装置として、並びに、ＳＴＢ３０に向かう中継サーバー７０のデータ受信通知の通過装置として動作する。また、ビデオサーバー制御部５６は、特定のＳＴＢ３０により呼び出された双方向性アプリケーションを特定する履歴情報を供給することも可能であろう。その履歴情報は中継サーバ７０に供給され、ビデオサーバー制御部５６もまた、ＥＰＧメタデータソース１２０、一般広告放送のメタデータソース１６０、あるいは広告通信量制御メタデータソースのようなネットワークを通して入手できる別の内容データソースとして動作するようになる。中継サーバー７０はそのようなあらゆるクリックストリームデータ及び内容データを収集し、解析し、そしてＭＫＩＳデータベース１００、または、第三者の解析エンジン及びデータベース１００にそれらのデータを送信する。その様子は図５−７に関連する説明に詳細に記載されている。

イベントデータの定期的報告
クリックストリーム処理装置３４は、全てのイベントあるいは選択された関心のあるイベントについて、“日誌（journal）”あるいは履歴を作成するために情報を収集する。イベントは、ある行動あるいはＳＴＢ３０の状態の変化であり、加入者あるいはその視聴パターンに基づく情報を構築するのに重要であると考えられる。例えば、イベントには、キーを押す動作により、チャンネルや音量を変化させる、消音する、双方向性システムの案内を呼び出す、ＳＴＢ３０のスイッチを入れるあるいは切る、ビデオオンデマンドアプリケーションにより入手したビデオを早送りする、一時停止するあるいは巻きもどすことが含まれる。それらイベントには加入者により呼び出されたアプリケーションも含まれる。例えば、双方向性のゲーム、電子番組案内、ビデオオンデマンドあるいはそれに類似のアプリケーション、対話型通信販売、またはThe Weather Channelのウェザーオンデマンド、World Spanのトラベルオンデマンド、Light Spanの対話型教育番組のような特定の会社の双方向性アプリケーションなどである。イベントには、ビデオカセットレコーダーやビデオディスクプレイヤーのようなＳＴＢ３０あるいは画面表示装置に接続された周辺機器の加入者の使用やそれらへの制御命令が含まれる。

ＳＴＢ３０に在駐する各々のアプリケーションは、クリックストリーム処理装置３４とインターフェースを通して連結され、所望の定期的報告を維持するために、選択されたデータを送信する。システム２０が双方向システムと共に用いられるとすれば、多くの異なるアプリケーションがそのシステムを通して配備され、加入者によって呼び出されるであろう。呼び出されるかなり典型的なアプリケーションとしては、次のものが含まれる。
・加入者が（チャンネルや音量の変化などを）遠隔操作するケーブルテレビのアプリケーション
・TV Data、PrevueあるいはStar Sightの双方向性サービスのような電子番組案内アプリケーション
・対話型ゲーム
・ビデオオンデマンドあるいはそれに類似したアプリケーション
・会社特有のアプリケーションであり、the Weather Channel、MTV、Showtime、その他特定の内容提供者から供給される可能性のあるもの
・利用者の選択を補助するためのナビゲータアプリケーション
これらのアプリケーションの各々には、システム２０がモニターしようとする内部のアプリケーションと同様に、特定のアプリケーション識別名が割り当てられる。

クリックストリーム処理装置３４は、ＳＴＢ３０のオペレーティングシステム３２に内在する様々なアプリケーション及び、第三者のアプリケーション３３とインターフェースを通して連結されている。図面に説明されている具体例とは異なる種類のＳＴＢ３０を使用するシステムでは、それらのＳＴＢ３０はオペレーティングシステムを必要としないことに注意されたい。その代りに、全ての命令をその特別なＳＴＢの記憶装置に、直接書き込むことができる。アプリケーション３３は、新しいソフトウェア全体を直接記憶装置にダウンロードすることにより、または、以下に説明するような新しい表をダウンロードすることにより、加えることができる。

アプリケーション３３は、関心のある“イベント”が生成された時点で、記憶装置にイベント記録を保存する。次いで、アプリケーション３３は、クリックストリーム中核部３６にイベント記録を送り出す。そのイベント記録には以下のような情報が含まれる。（１）アプリケーション３３の識別コード（例えば“ケーブルテレビジョンアプリケーション”あるいは特定の双方向性アプリケーションなど）、（２）報告される情報の量（バイト数）、（３）例えば、日時、正確に何時何分何秒を指定することによって、特定の時刻を示す“タイムスタンプ”、（４）イベントの識別コード、または、（５）イベントデータの記憶位置。クリックストリーム中核部３６は、アプリケーション３３によりもたらされた情報を、イベントデータを収集するため、イベントデータをフォーマットするため、及び、イベントデータを一時記憶装置４２あるいは４４への収納するために用いる。表Ｉは、一般にクリックストリーム処理装置３４から一時記憶装置４２あるいは４４へ送られる情報の種類を示している。

一覧表ＩＩは、各アプリケーションが、識別し、収集し、“アプリケーション固有のデータ”領域に保存し、そして、クリックストリーム中核部３６に通知するイベントを定義している。これらイベントは、“リモコン”のボタンを押すことにより放送チャンネルを変えるのと同様に、簡単に変えることができるであろう。これらイベントの種類は全て、各アプリケーションからアクセスでき且つ利用できる。各アプリケーションが、全種類のイベントを使用することはないであろうが、収集のために利用しうる数多くのイベントは、システム２０が解析のために、直接関係する使用情報を引き出すことを可能にする。また、一覧表ＩＩのそのような利用は、システム２０の効率を増大させる。なぜなら、イベントの種類が、修正、追加、削除することができるためである。

表ＩＩは相対的な音量変化（例えば“音量調節５０％以下”“音量調節２５％以下”など）を定めていることに注意されたい。アプリケーションは、これらの相対音量変化を生じさせる実際のボタン操作を獲得することもできるであろうが、そこまでの詳細な情報はシステム２０のオペレータにほとんど利用されないものである。また、そのような細部の情報すべてを捕捉すると記録量が増え、これらの記録が転送される時に、通信ネットワーク５２に対する要求が増大することになる。アプリケーションは、加入者の他の行動の必要のない細部の情報を“フィルター”にかける役割をすることができるであろう。例えば、加入者が短時間にいくつものチャンネルを何度も切り替えて“チャンネルサーフィン”するような場合、アプリケーションは、加入者が決められた時間（例えば１５から３０秒）以上の間行動を止めない限り、チャンネル変化を記録しないよう構成することができるであろう。このことにより、ほとんど利用されない情報は除去され、ネットワーク通信量が減少する。

表ＩＩＩは、全国放送および地域放送を識別するためのコードを提供するチャンネル識別−覧表の例のごく一部分を定義したものである。このような表により、加入者が一般放送及びケーブルテレビの番組を視聴している間に生じたイベントを定期的に通信するアプリケーションが、一覧表ＩＩの一部を用いて、ネットワークが提供する番組内容を識別することを可能にする。このようにして、一般放送あるいはケーブルネットワークの識別子がそのままであっても、チャンネルラインナップを変更することが可能である。この割り当ての手順を使用することにより、既に変更されたチャンネル番号をネットワークに割り当てる必要性がなくなる。

以下の表ＩＶは、特定のアプリケーションのための可能ないくつかの識別コードを示している。各アプリケーションは、アプリケーションＩＤコードを、表ＩＶにアクセスすることなくイベント記録に挿入するようにプログラムされ得ることに注意されたい。しかし、各アプリケーションが定期的通信過程で表ＩＶにアクセスすることによって、システム２０のアプリケーションＩＤを修正するあるいは追加する能力を容易に増大させる。なぜなら、そのようなコードは、更新された表ＩＶのダウンロードによって、システム２０に植え付けられることができるからである。新しい表のダウンロードにより、アプリケーションの足跡及びシステム２０の複雑さが増加する。従って、表はアプリケーション番組の一部にできる。

特定のアプリケーションの各々は、イベント記録の構築のために総合アプリケーション、イベント及びチャンネル識別表（定期的に更新、ＳＴＢ３０へのダウンロードが可能であろう）を参照できる。この方法で作成されるであろうアプリケーションに特有のイベント記録の例は、以下の表Ｖから表ＶＩＩＩに示され、本文中に説明されている。

ケーブルＴＶアプリケーション３３は、アナログあるいはデジタルの放送サービスを同調できるであろう。チャンネル変更の命令が入力されると、ケーブルＴＶアプリケーション３３が呼び出される。そのアプリケーション３３は、アプリケーションＩＤ及びタイムスタンプを記録に挿入することにより、イベント記録の構築を開始する。次いで、アプリケーション３３は、正確なコードのため、命令をイベントＩＤ一覧表ＩＩと照らし合わせることにより、“イベントＩＤ”を決定する。次いで、アプリケーション３３は“チャンネルＩＤ”を報告する。

チャンネルＩＤは単にチャンネル番号でも良いが、その情報はあまり意味がない。チャンネル６がチャンネル７より視聴されている事実は、結局のところネットワーク及びそれが配信する内容が特定のチャンネルと対応していない限りは、意味を成さない。従って、チャンネルＩＤは、１６ビット領域のような領域であって、特定のチャンネルに表示される放送ネットワークを個々に区別するものであろう。チャンネルＩＤは、ケーブルＴＶアプリケーション３３の番組によって決定され、同調されたチャンネル番号を上記の放送チャンネル識別−覧表ＩＩＩと比較して正確なチャンネル識別コードを決定し得る。チャンネル番号と、表ＩＩＩに示されているチャンネル識別コードとを関係づけることにより、チャンネルが特定の地域内で異なるケーブルＴＶヘッドエンドと違っている場合や、個々のチャンネルのラインナップがある時間に渡って変更されるような場合でさえも、正確な報告を確実にすることができる。異なる地域的なチャンネルラインナップに関する相関が存在することを条件として、チャンネル番号とチャンネル識別コードとの相関をとることは、中継サーバー７０においてイベント記録を全部受信した後でも行えるであろう。

以下の表ＶＩは、案内（ナビゲータ）アプリケーションを示しており、そのアプリケーションは、双方向性ネットワークの多くの利用可能な番組及びアプリケーションの中からの選択を補助する対話型メニューを加入者に提供するために供給されるであろう。“イベントＩＤ”は、案内アプリケーションに関連する命令の識別コードを意味し、そのコードは上記のイベントＩＤ一覧表ＩＩを参照することで突き止められるであろう。表ＶＩは、また、加入者によって利用され、且つ追跡するのに便利であろう案内者（ナビゲータ）の特徴をいくつか示している。“サイズ／データ”の右の欄では、第１に“アプリケーション状態ＩＤ”の隣にその記録の位置を示す８ビット領域があり、第２にそれ以下の行に渡って、加入者がアクセスした個々の画面（例えば、概要、メインメニューなど）を指し示す特定のコードを示している。これらの情報は、利用者が頻繁にあるいはたまに視聴している画面がシステム２０の運営者に分かるようにすることができるようにし、それにより、あまり人気のない画面をより有用な画面に交換する、あるいは、頻繁に利用される画面の広告に、より高い料金を請求することができる。

表ＶＩＩは、同様に、ビデオオンデマンドアプリケーション３３について収集された定期報告する情報を示しており、そのアプリケーションは、上記の案内アプリケーションあるいはそれと同等のものを通じて開始されるであろう。ここで収集された情報には、一時停止、早送り、及び、巻き戻し回数を含むものもあるであろう。さらに、サービス提供者（プロバイダ）は、録画料金を請求するために、視聴者がビデオを録画しているかどうかを調査したいであろう。同様の情報は、典型的には一時停止、早送り、あるいは巻き戻しの増加のみを可能にするビデオオンデマンド類似のサービスのために収集することができよう。

以下の表ＶＩＩＩは、電子番組案内（ＥＰＧ）アプリケーション３３のイベント記録を示している。ＥＰＧアプリケーション３３は、ちょうど表ＶからＶＩＩに説明されている上記アプリケーションがするように、アプリケーションＩＤ、タイムスタンプ及びイベントＩＤを記録する。さらに、それは以下に示すように、加入者がどの画面にアクセスしているかを識別するアプリケーション３３の状態ＩＤ領域を有する。

一般に、他のアプリケーション３３についての同様の情報は、同様の方法で追跡することが可能であり、そのようなアプリケーションとしては例えば、通信販売、対話型ゲーム、双方向性又は他のメディア配信システムの提供するその他新しいアプリケーションなどがある。さらに、定期的通信の過程は、システム２０のエラーを追跡するのにも用いられ、上記と同じ方法でクリックストリーム中核部３６がそのようなエラーを報告するであろう。

システム２０の定期的通信の必要性、あるいは、システム２０自身は時間を経て徐々に発展して行くものであってよい。アプリケーションは変化し、新しいものが展開してゆくであろう。新しいイベントが、システム２０のオペレータにとって関心のあるものとなるであろう。システム２０に柔軟性を持たせるために、オペレータはＳＴＢ３０に、新しいあるいは交換用アプリケーションをダウンロードすることができ、それらのアプリケーションは関心のあるすべてのイベントを報告するために、必要な過程を含むであろう。

定期的通信の例
スミス氏が午後７時３０分に、チャンネル５でニュースを３０分間見るために、双方向性テレビのスイッチを入れると仮定する。チャンネル５は、ニュース分野のＣＮＮに対応している。午後８時、彼はビデオオンデマンドアプリケーションを通してビデオを注文するために、案内アプリケーションにアクセスする。その後、彼はビデオオンデマンドアプリケーションにアクセスする。そのアプリケーションは、自動的に、８時４分にビデオ放送を開始し、８時５０分に一時停止し、８時５５分に放送を再開し、９時４５分に終了するまで放送を続け、その時点で彼は双方向性テレビのスイッチを切る。

スミス氏の行動は、以下の表ＩＸに示されるような連続したイベント記録を生成する（簡単のため、単一のアプリケーションにおいて生じた複数のイベントは、操作により独立の記録が生成される場合でも、グループにまとめてある）。

イベント記録アップロードサイクル
様々な大きさのイベント記録が収集され、二つのクリックストリーム一時記憶装置４２あるいは４４の一つに保存される。それらの一時記憶装置の容量は静的に準備されていてもよいし、あるいは、システム２０が特定のＳＴＢ３０に、一時記憶装置４２あるいは４４の適切な容量を、アドレスを利用してダウンロードするようにしてもよい。一時記憶装置４２あるいは４４はアドレスを割り振られ、それによりＳＴＢ３０の記憶装置に隣接する未使用領域を、イベント記録の一時保存にのみ用いる。リンクリストや記録ポインタを用いるような発展的なデータベース技術が用いられるであろうが、それらはアプリケーションの記録及び複雑さを増すことになるであろう。約１５ｋＢの一時記憶容量が、恐らくほとんどのアプリケーションで必要な定期通信を収容するので、進んだデータベース技術は一時記憶容量が大きいときにのみ必要となる。１５ｋＢまでの一時記憶容量は、アップロードの間に、少なくとも４時間から８時間のピーク時のチャンネル“サーフィン”（チャンネルサーフィンが、大概もっとも主要なイベント記録を生成するであろう）を可能にするはずである。どのイベントについても、ネットワーク利用に関する経験的分析で、最適な一時記憶容量を決定するべきである。

単一の、あるいは、より多くの一時記憶装置がシステム２０で使用できるが、イベント記録は、二つの一時記憶装置４２あるいは４４のうちの一つに向かう。十分考えられることとして、システム２０はイベント記録を即時通信するために、修正されるであろう。しかしながら、その場合、ネットワーク上に情報量の瞬間的過負荷を生ずる可能性が非常に大きくなる。そこで、システム２０は、収集したイベント記録をアップロードするまで一時的に保存するために、一時記憶装置４２あるいは４４を用いるのが好ましい。

イベント記録は特定のＳＴＢ３０からあるフォーマットでアップロードされ得、そのフォーマットは、配信ネットワーク５２を通して、中継サーバー７０へのイベント記録の転送を補助する。ヘッダー記録が、一時記憶装置４２あるいは４４が最初に開いた時刻、その一時記憶装置のバイト数、アドレスによる開始したＳＴＢ３０、記録を生成したクリックストリーム中核部３６のバージョン、及び、それに続くデータ（もしあれば）に用いられるデータ圧縮の種類を指定できるであろう。最初のヘッダー記録は、固定した長さであり、非圧縮であろう。“圧縮の種類”に続く情報は、転送の幅を小さくするため圧縮されていてもよい。以下の表Ｘは、この一般的なヘッダーフォーマットを示している。

（１）一時記憶装置４２あるいは４４が一杯である、（２）アップロードタイマーイベントが満了した、あるいは、（３）中継サーバー７０からの命令がある場合に、クリックストリーム処理装置３４はアップロード過程を開始する。この過程で、アップロードを行う一時記憶装置４２はロックされ、後続のイベント記録は、二番目の一時記憶装置４４に向けられ、そこで保存される。一時記憶装置４２のアップロードが完了すると、記録は次のアップロード時刻まで続けて一時記憶装置４４に一時保存される。一時記憶装置４４がロックされた後、記録は一時記憶装置４２に向かう。このサイクルは繰り返し続けられる。

図３はアップロード周期のダイヤグラムを示しており、ダイヤグラムは、イベント記録のアップロードにより、ネットワーク５２上で増加する情報量を均等に分配する一つの方法を描いている。クリックストリームのアップロードサイクルは、開始時間及びデータをアップロードするサイクルを決定するいくつかのパラメーターから構成されている。“最初の実行”パラメーターは、そのサイクルが開始するヒストリにおける開始時刻を決定する。“サイクルタイム”パラメーターは、アップロードサイクルの期間の間に経過する時間を決定する。一つのサイクルが完了すると、“アップロード継続”時間が開始され、各ＳＴＢ３０のクリックストリーム処理装置３４は、アップロード継続中に実際のアップロード時間をランダム化する。このアップロードのタイミングは、ネットワーク荷重を、全体のアップロード継続期間に渡って均等に分散させるであろう。

これらパラメーターの使用例は、データをアップロードするために、システム２０中のＳＴＢ３０の毎日の時間を決定するであろう。典型的には、システム２０のオペレータは、解析のために入手可能なデータを毎朝要求するであろう。主要な放送の時間あるいは双方向性サービスの利用のピークは、典型的には午後７時から午後１２時であろう。この間、アップロードは、ネットワーク５２の負担を最小にするため、控えるべきである。午後１２時から、一時記憶装置４２あるいは４４から外部へのイベント記録のアップロードが開始されるであろう。全てのＳＴＢ３０を午前８時前にアップロードするために、ＳＴＢ３０は、アップロードグループ３２に分割され得、各グループのアップロードは選択された時間（例えば１５分）に渡って行われる。このアップロードサイクルを実行するために次のようなパラメーターが、図３のサイクル及び表ＸＩで定義されている。四つのアップロードサイクルの合計がＳＴＢ３０の各グループごとに定められ、そのグループは、毎週のアップロードあるいは他のサイクルの任意の組み合わせがネットワーク５２の通信時間のピークに作動することを可能にするであろう。

ＳＴＢ３０は、クリックストリームアップロード制御部３８の扱う適切な命令を中継サーバー７０から送ることにより、アップロードにおけるその役割を指示することができる。例えば、次のような命令が、アドレスを割り当てられ、中継サーバー７０により単一あるいはグループのＳＴＢ３０へ送られるであろう。システムがどのように構成されているかにより、命令はＳＴＢ３０に以下のような内容を指示する。１）様々なグループあるいは全部のＳＴＢ３０で、周期的アップロードを定義する。２）命令あるいはポーリング制御（アドレス使用）により、ＳＴＢ３０にアップロードを要求する。３）一時記憶装置４２あるいは４４が一杯の場合、アップロードを停止する。４）特定のＳＴＢ３０あるいはＳＴＢ３０のグループによる、オンオフイベント記録の収集。

イベント記録のフォーマット、アップロード及び捕捉
アップロード過程の開始信号が送られた後、各ＳＴＢ３０は、典型的には、第一に一時記憶装置４２あるいは４４をアップロードのためにロックし、次いで、記憶内容を圧縮することによりアップロードを開始する。数多くの異なる圧縮技術を用い得るが、およそ５０％の圧縮がＬＺＷ圧縮ユーティリティ ソフトウェアにより実行されるであろう。この圧縮は、実質的に、多数のＳＴＢ３０のイベント記録アップロードにより引き起こされるネットワーク５２の負荷を減少させる。圧縮されたデータは、送信用“トランザクション”あるいは“パケット”に分割され、パケットヘッダーは、パケット識別、行き先のＩＰアドレスなどを指し示すように、アドレスが割り振られている。実際のネットワークへの接続は、特定のＳＴＢ３０のためのオペレーティングシステムによって開始される。当業者であれば、呼び出され、且つ実行されるネットワーク接続の種類及び手法が、システム２０の配備されているメディア配信ネットワークの種類に大きく依存して変わることを認識するであろう。

例えば、ＳＴＢ３０は、ＩＳＯにより出版されたＲＦＣ７９１あるいはＲＦＣ７６８の仕様を採用した、ＵＤＰ／ＩＰヘッダー及びトレーラー（最後に付する記録）を挿入するよう適合することができる。各データパケットは、レベル１通過ヘッダーで構築されたＵＤＰ／ＩＰプロトコルを有しているであろう。それらは以下の表ＸＩＩＩに示されている。

図面に示されている具体例では、クリックストリーム処理装置３４は、これらのデータパケットの行き先として図４Ｂに示されているようなＶＳＰ６６のよう特定のＶＳＰ、即ち、サービスを配信するためにネットワーク５２を接続する存在であるビデオサービスプロバイダーを識別するであろう。アップロードされるデータの全ては、ＳＴＢ３０、ネットワーク５２、ネットワーク管理制御部５０、中継サーバー７０上のイベント捕捉過程７１において“有料荷重”として現れる。ＳＴＢ３０において適切なヘッダー及びトレーラーを挿入した後、アップロードデータパケットは、表ＸＩＶに示されているフォーマットを有するであろう。

二つの一時記憶装置４２、４４を提供することにより、イベント記録収集をアップロードの間継続させることができる。一時記憶装置４２の内容をアップロードする場合、第２の一時記憶装置４４がそのアップロードの間に一杯になれば、記憶装置の容量超過が起こる。このような場合を考慮に入れ、一時保存状態のトレーラー記録（バッファトレーラー記録）が、アップロードの間にＳＴＢ３０から送られ、そのようなエラー状態を通知するであろう。そのバッファトレーラー記録は、以下の表ＸＶに示されるような構造をとり、それにはタイムスタンプ、割当てられたアプリケーションの識別信号、長さ及びアップロードコードが含まれる。

これらのアップロード状態コードは、一時記憶装置４２あるいは４４でオーバーフローが生じた時のアップロードプロセスの段階を特定する。従って、アップロードコードのいくつかは次の情報を含むことが可能である。その情報としては、アップロードが使用されていない、アップロード進行中、アップロードは完了したが確認が受信されていない、アップロードは完了したが確認は部分的にしか受信されていない、あるいは、アップロードは行われようとしなかった、などが含まれるであろう。これらのコードは、中継サーバー７０に、最初の時点で、ＳＴＢ３０のイベント記録が紛失したかどうかを知らせることになる。同様に一時記憶容量超過の記録を受信することは、中継サーバー７０に、一時記憶装置４２あるいは４４の容量が適切に設定されていなかったことを通知する。そこで、一時記憶装置４２あるいは４４の容量は、適当な命令をＳＴＢ３０に送信することにより、更新あるいは特定のＳＴＢ３０に開放するために、リセットされそしてシステム２０に開放される。

上記のようなパケット化は、システム２０の一つの具体例のためであることに注意されたい。しかしながら、一般的には、収集されたイベント記録のアップロードのために、ＳＴＢ３０は、システム２０とともに使用される双方向性のケーブルテレビあるいはその他のメディア配信システムにより用いられるいずれの“アップストリーム”データ転送処理をも開始できる。この処理は、イベント記録を適切なシステムフォーマットでアップロードする。

どのような場合においても、システム２０のために、クリックストリームデータパケットは、ＳＴＢ３０のALOHA（協議に基づいた標準輸送プロトコル）スロットデータ転送を通して、中継サーバー７０にアップロードされる。中継サーバー７０からのデータ受信通知は、各々が特定のＳＴＢ３０にアドレスを割り当てられ送られる。データ受信通知の周期と期間は、ネットワークエラーの頻度、ネットワークパケットエラー頻度、これらの種類の転送エラーの原因を考慮して決定されるであろう。

図４Ａ及び４Ｂは、システム２０を流れるクリックストリームデータフローをより詳細に示している。簡単に説明すると、図４Ａは、イベント記録のクリックストリームパケットが、各ＳＴＢ３０からネットワーク管理制御部５０へ転送されることを示しており、その管理制御部はビデオサービスプロバイダーの発送者（ルータ）として働く。ネットワーク５２を流れる情報量を管理するネットワーク管理制御部５０から、パケットはネットワーク５２、ビデオサーバー６０及びビデオサーバー制御部５６を経て、ＭＫＩＳ１００及び解析エンジン１１０に接続されている中継サーバー７０に送信される。このように、ＳＴＢ３０で収集され一時保存されたイベント記録は、収集及び解析のために中継サーバー７０に送信される。

図４Ｂは、この過程をより詳細に示しており、同時に中継サーバー７０におけるイベント記録の捕捉過程７１を示している。

一旦一時記憶装置４２あるいは４４が一杯になるか、クリックストリーム処理装置３４が他の理由（時間の終了、システムの利用減少、アップロード命令など）によりデータのアップロードを決定すると、一時記憶装置４２あるいは４４のデータはフォーマットされ、圧縮され、そして、システム２０を通して中継サーバー７０にアップロードされる。このアップストリームデータパケットは、ネットワーク管理制御部５０から配信ネットワーク５２を通してビデオサーバー６０へ、ＩＰ（“インターネットプロトコル”）トンネリングと呼ばれる過程を通して移動する。ＩＰ トンネリングは、本質的には、パケットの料金情報に基づき、自動的にＩＰに従って通信することである。同一の過程が、ビデオサーバー６０を通過することなく直接ネットワーク５２を通り、中継サーバー７０にパケットを発送するために用いられる。図４Ｂは、ビデオサーバー６０において、Ｌ１通過処理６３が、行き先ＩＰアドレスを、受け取ったデータパケットに挿入された対応するタグに関係づけるために、ＶＳＰ発送表６７を用いることを示している。この過程は、タグを適切な行き先、ここではアプリケーションサーバー６６に関係付けることにより、データパケットをアプリケーションサーバー６６のＬ１通過プロセス６３へ再び方向づける。アプリケーションサーバー６６上のＬ１通過プロセス６３は、データパケットに対し同様の機能を持っており、有料荷重識別子（トランザクションコードあるいはその他）に基づきパケットを中継サーバー７０上のイベント記録を捕捉するオープンサーバープロセス（“ＥＣＡＰ”）７１に送る。

ＥＣＡＰプロセス７１がクリックストリームデータパケットを受け取る場合には、データパケットを受け取り、特定のＳＴＢ３０で既に進行中のアップロードセッションにデータパケットのソースアドレスを関連付ける。もし仮に、そのＳＴＢ３０について進行中のアップロードがないとすると、アップロードが開始されるべきであると考えられる。ＥＣＡＰプロセス７１は、アップロードされたデータを、システム２０の必要とする特定のプロトコルに従って処理する。特定のＳＴＢ３０からのアップロードと関連付けられた全てのクリックストリームデータパケットを受信した後、そのＥＣＡＰプロセス７１は、パケットを正しい順序に並べ替え（あるパケットは、ネットワーク５２上の送信遅延のため、本来の転送の順番から外れて到着する可能性がある）、パケットの圧縮を解凍し、輸送の際の添付情報をはずし（トレーラー、ヘッダーなど）、そして、後の解析のためにフラットファイルなどとして保存する。例えば２４時間など、選択した期間の終了時には、そのファイルは閉じられ、新しいファイルが開かれる。それにより、連続した統合及び解析処理が、別々の期間に渡る別々のファイルのバッチ処理を実行することを可能にする。ＥＣＡＰプロセス７１の間及び開始後すぐに、操作履歴が、各アップロードセッションの開始及び終了並びに存在するエラーについての情報を記録するために開かれる。

図５に示されているように、中継サーバー７０は、アップロード過程で使用された各ＳＴＢ３０に、データ受信通知を定式化し、送信する。そのような一つの方法は、ＳＴＢ３０への、ネットワーク５２を通るアドレス化可能なダウンストリームのレベル１パススルートランザクションとして、受信通知を送ることである。そのようなデータ受信通知は冗長誤り訂正をもたらす。なぜなら、受信に失敗すると、ＳＴＢ３０に、起こりうる転送エラーの警告を与え得るからである。

統合及び解析
図６Ａおよび６Ｂは、統合及び解析処理の概略を示し、図７はその過程に伴う結果例を示している。簡単に説明すると、統合解析処理の目的は、各ＳＴＢ３０のイベント記録を様々な“メタデータ”と併合することである。“メタデータ”とは、（１）番組を供給している時間及び一般放送あるいはケーブルネットワークを含む、システム２０に示される仮想的なあらゆる種類の番組及び、（２）加入者に呼び出される双方向性のアプリケーションを意図する。例えば、メタデータは次のようなデータ源を含む。ＥＰＧ−般放送の番組スケジュールデータ８２、一般放送の広告スケジュールデータ８４、地域広告スケジュールデータあるいはセッションサービス広告スケジュールデータ８６、及びセッションサービスの番組スケジュールデータ８８である（セッションサービス広告とは、ビデオサーバー６０により挿入される広告であり、それは特定の加入者による双方向性セッション、すなわち、セッションサービス番組の間に流される）。

集合的には、これらのデータの全ては、統合解析エンジン９０に入力され、このエンジンは各ＳＴＢ３０についてのイベントの経時記録９２を作成する。統合解析エンジン９０は、中継サーバー７０あるいはＭＫＩＳシステム１００上に配備されるであろう。中継サーバー７０上に統合解析エンジン９０が配備されることにより、収集されたイベント記録の統合及び解析が可能となる。生成されたイベント経時記録９２は、ＭＫＩＳシステム１００に送られ、より詳しく分析される。

経時記録９２は、選択した時間（例えば２４時間）あるいは選択したイベントについて、特定のＳＴＢ３０における活動の断片（スナップショット）を与える。例えば、経時記録９２は、選択した時間に流れる特定のあるいは複数の番組（例えば、有料番組が競合する場合）に同調している各ＳＴＢ３０に対して作成されるであろう。経時記録９２は、選択した時間にネットワークより利用可能な番組についてのメタデータを、イベント記録と統合することにより、作成される。

それらのデータを統合するため、正しい優先順位がデータに割り当てられねばならない。そうでなければ衝突が起こりうる。例えば、一般放送広告データ８４は、ある公共広告が時刻Ａで流れていることを示す。一方、仮にシステム２０が双方向性システム及びサーバーであり、標的づけられた広告（“ad”）が同時に時刻Ａで供給されると、セッションサービス広告データ８６が示すように、標的付けられた広告は時刻Ａで公共広告の上に挿入される。このように、セッションサービス広告データ８６に公共放送の広告データ８４より高い優先順位をつけることにより、統合解析エンジン９０は、特定のＳＴＢ３０に配布される番組のより正確な経時記録を作成することができる。同様に、従来のケーブルネットワーク、あるいは、無線のケーブルネットワークにおいても優先順位が必要とされる。通常、地域のケーブルオペレータは大概、地域広告をある公共広告の上に挿入することが許されている（地域広告時間の販売が可能であるとする）。

図６Ｂは、そのような優先順位の割り当てを描写している。図６Ｂは、いくつかのデータソースを示しており、それはＥＰＧメタデータ、公共及び地域の挿入広告メタデータ、及び双方向性会議メタデータなどである。ＥＰＧメタデータは通常大変幅が広く、例えばチャンネル１で午後１時から４時までサッカーゲームを放送する。従ってＥＰＧメタデータは、公共広告メタデータより優先順位が低い。なぜなら、特定の公共広告は、ＥＰＧにより幅広く設定された特定の時間枠に重ねることができるからである。一方、地域挿入広告メタデータは、公共広告メタデータより優先される。これは、公共広告メタデータは、地域ネットワークあるいは支部が、特定の時間枠のために予定した公共広告上に、地域広告を挿入する状況を考慮していないと思われるからである。最後に、加入者の選択を反映する双方向性セッションメタデータは、最も高い優先順位を持つ。なぜなら、加入者は、特定のチャンネルの視聴を止め、その代わりに双方向性セッションを呼び出すからである。

これらの優先規則を適用することにより、各加入者の経時記録９４が作成される。図６Ａに描写されているように、統合解析エンジン９０により、付加的な選別基準９４が、より正確な経時記録９４を作成するために適用される。例えば、イベント記録が、特定の加入者が入力した頻繁な音量増やチャンネル増のような特殊で非常に細切れの情報を含むかもしれない。選別基準９４のある一つの組み合わせでは、経時記録９２が、閾値（例えば１５秒）を超えて視聴された場合のチャンネルのみを含むようにできるであろう。これは加入者の頻繁なチャンネル切り替えを除き、それによってイベント経時記録９２は単純化される。なぜなら、その基準９４にそぐわないものは、イベント経時記録９２から篩い分けられるからである。

統合解析エンジン９０は、図６に示されているように、選別された経時記録９４（あるいは元の経時記録９２）に、他の基準を適用することができる。特に広告業者は、“眺める（view）”及び“注視する（watch）”基準９６を適用したいと思うかもしれない。この基準９６は、ある時間の閾値よりも短い時間、加入者が“眺めている”番組あるいは広告を区別する。その閾値以上に加入者が見ている番組は”注視する“番組として識別されるであろう。例えば、３０秒間の広告については、閾値は１５秒がよいであろう。仮に加入者が、その広告を１５秒も表示せずにチャンネルを変えたとすると、彼は単にそれを”眺めた“とみなされるであろう。一方加入者が広告を流すチャンネルを広告の長さのうち２５秒経って変えたとすると、彼はそれを”注視していた“とみなされるであろう。この基準９６は、システム２０のオペレータに、単に”眺めた“ものに対し、より”注視した“広告に料金を請求することを可能にする。同様の基準は、より正確に視聴率を調査するために、番組に対しても適用できる。このように、３０分間の番組であれば、仮に使用者が１０分以内に番組を変えたとすると、その基準９６は番組をただ”眺めた“だけと判断するであろう。どのようなイベントにおいても、この眺める、注視するという基準９６の適用により、統合解析エンジン９０は”眺める“及び”注視する“リスト９８を作成し、それはシステム２０オペレータ及びその運営者（オペレータ）と契約する広告業者にとって有用なものとなる。

単にどれだけの時間特定のチャンネルに同調していたかとは異なる基準が、眺めるおよび注視する基準９６に含まれ得ることに注意されたい。例えば、別の基準は音量でもありうる。仮に視聴者がある広告時間の３０秒全体をそのチャンネルにしていたとしても、消音ボタンを押すかある閾値より低い音量に変えたとすると、この基準９６は、その広告を“眺めた”広告に分類するであろう。

一般に統合及び解析は、２４時間ごとの断片（セグメント）のような、離散化したデータの断片について行われ、解明されないイベントの生成を最小にするためにできるだけ早く行うべきである。言い換えれば、離散化したイベントは全体像の断片にすぎない。クリックストリームイベントデータのわずか数時間の解析が、番組の“注視する”、“眺める”といった事柄を判断できるわけではないであろう。

図７は、イベント記録あるいはクリックストリームデータ８０、Ｐｒｅｖｕｅあるいは同様のサービスからのＥＰＧデータ８２及びクリックストリームの経時記録９２を生成する一般放送の広告データ８４の単純な統合を示している。図７は加入者が選んだチャンネル及び、そのチャンネルを見ている間に表示された内容の両方を示している。

各ＳＴＢ３０の経時記録９２は、中継サーバー７０によって構築され，ＭＩＫＳデータベース１００あるいは第三者の解析エンジン及びデータベース１１０にアップロードされる。そのどちらかは人口統計データを保存し得、それらの統計とイベント経時記録９２に対し質問を実行するために用いられ得る。経時記録９２と人口統計情報を結び付けることにより、加入者及びその視聴行動について、より詳細で凝縮された情報の入手が可能になる。例えば、以下のような例が考えられる。

・例１：Widget Co.は、システム２０上に流れる１０の異なる広告を有している。Widget Co.は、加入者が特定の広告を“眺めている”のか、“注視している”のかを知りたいと希望している。本発明のシステム２０により捕捉された詳細な情報ゆえに、次の事項を判断するため質問を公式化できる。（ａ）どの加入者がある特定の３０秒間の広告を、１５秒以上“注視している”のか、に対し（ｂ）どの加入者が１５秒以未満の時間ただ“眺めている”だけであるのか、という判断である。

・例２：イベント経時記録９２（あるいは、眺める及び注視するリスト９８）が、ＭＫＩＳ１００あるいは解析エンジン１１０に呼び出された場合、同一の質問が、特定の人口統計グループに対して実行される。例えば、Widget Co.は、他の“眺めている”広告に対してどの広告が、第一の消費者基盤である４０代５０代のベビーブーマーで年収５万ドル以上の収入のある人々に、“注視されている”のか、知りたいと希望している。

明らかに、システム２０は、解析され統合されたデータのフィードバックに基づき、特定の人口統計の世帯向けに広告の狙いを修正することも可能である。そこで、それら狙いを定めた広告が、システム２０を通して放送された後に生ずるイベント記録を調査して、標的とした特定の人口統計上の市場が、その広告を注視していたか眺めていたかを判断することができる。

前記は、本発明のより有用な具体例を説明するため及び開示するために提供され、改変することが可能であるが、それは以下に続く請求の範囲内に包含されるであろう。例えば、アーキテクチャ及びシステムのプログラミングが修正され得る。又は、異なるメーカーのサービス、セットトップボックス、あるいはデータベースなどの様々な種類のものが、このシステムの改善のため配置される可能性がある。特定の識別コード及び割り当てたサイズは、表に示され本文中に説明されているが、同様に大幅に変更され得る。前述の具体例に対する更なる修正及び応用は、この分野に十分精通した人々には明らかになるであろうし、本発明及び後続する請求の範囲の精神、あるいは観点から逸脱すること無しに行われるであろう。

Claims (1)

1. メディア配信ネットワークを通じて配布される番組の加入者の選択及び利用についての情報を収集および処理するためのシステムであって、
   ａ）情報交換する手段を介して、以下のｂ）と連結された統合処理装置と、
   ｂ）番組を提供するための複数のセットトップボックスであって、各々のセットトップボックスが、
   （１）加入者が特定のセットトップボックスへ向けて選択したイベントを示す複数のイベント記録を収集し、
   （２）統合処理装置へイベント記録を送信して加入者からの一つ以上のイベントを定期報告するための処理装置を含んでいるセットトップボックスとを含み、
   ｃ）ここで、上記イベント記録は、各々、セットトップボックスに在駐するアプリケーションの識別コード、該アプリケーションに関連するイベントの識別コード、加入者が特定のセットトップボックスへ向けてイベントを選択した時間、及び、イベント記録のデータサイズを含み、統合処理装置は、上記選択した時間のイベント記録と、その選択した時間にメディア配信ネットワークを経て利用可能である番組のメタデータとを統合することによって、別々の時間に配布された番組の加入者の選択を示すイベントの経時記録を作成するシステム。

Images