JP4955903B2 - インタラクティブ・テレビ・システムの管理方法およびそのためのコンピュータ読み取り可能媒体 - Google Patents

Description

著作権表示
本出願文書の開示の一部に、著作権保護の主張の対象となる資料（コード・リスティングおよびメッセージ・リスティング）が含まれている。著作権所有者は、米国特許商標庁のファイルまたは記録の記載に従い誰が特許文書または特許開示をそのままの複製を行うことに異存はないが、いかなる形であれ他のすべての著作権を留保する。Ｃｏｐｙｒｉｇｈｔ ２００１ ＯｐｅｎＴＶ，Ｉｎｃ．

本発明は、分散コンピュータ・システム内のサービス群を管理することに関するものであり、特に、クライアント受信契約者のグループに提供されるインタラクティブ・テレビ・システムのサービス群を管理することに関する。

インタラクティブ・テレビ・システムを利用して、さまざまなサービスを視聴者に提供することができる。インタラクティブ・テレビ・システムは、標準的なテレビ番組ストリーム、インタラクティブ・テレビ・アプリケーション、テキストおよびグラフィック画像、Ｗｅｂページおよびその他の種類の情報を配信することができる。インタラクティブ・テレビ・システムはさらに、視聴者のアクションまたは応答を登録することもでき、マーケティング、娯楽、および教育などの目的に使用できる。ユーザまたは視聴者によるシステムのインタラクティブな操作では、広告の製品またはサービスの注文、ゲーム番組出場者との競争、特定の番組に関する専門情報の要求、または数ページ分の情報の検索などを行うことができる。

通常、放送サービス・プロバイダまたはネットワーク・オペレータが、視聴者のテレビに送信するためのインタラクティブ・テレビ信号を生成する。インタラクティブ・テレビ信号には、アプリケーション・コードまたは制御情報からなるインタラクティブ部分とテレビ番組またはその他の情報表示からなるオーディオ／ビデオ部分が含まれる。放送サービス・プロバイダは、オーディオ／ビデオおよびインタラクティブ部分を単一の信号にまとめて、ユーザのテレビに接続されている受信機に送信する。この信号は、一般に、送信前に圧縮され、ケーブル・テレビ（ＣＡＴＶ）回線や直接衛星送信システムなどの通常の放送チャンネルを通じて送信される。

通常、テレビのインタラクティブ機能の制御には、テレビに接続されているセットトップ・ボックスを使用する。セットトップ・ボックスは、放送サービス・プロバイダによって送信された放送信号を受信し、オーディオ・ビデオ部分からインタラクティブ部分を分離し、信号のそれぞれの部分を伸張して復元する。セットトップ・ボックスでは、インタラクティブ情報を使用して、オーディオ／ビデオ情報がテレビに送信されている間に、たとえばアプリケーションを実行する。セットトップ・ボックスは、情報テレビに送信する前に、オーディオ／ビデオ情報をインタラクティブ・アプリケーションによって生成されたインタラクティブ・グラフィックスまたオーディオと組み合わせることができる。インタラクティブ・グラフィックスおよびオーディオは、視聴者に追加情報を提示したり、視聴者に入力を求めたりすることができる。セットトップ・ボックスは、モデム接続またはケーブルを介して視聴者の入力またはその他の情報を放送サービス・プロバイダに送ることができる。

その総体的な性質から、インタラクティブ・テレビ・システムは、放送サービス・プロバイダ／ネットワーク・オペレータから情報を受け取るクライアントまたは視聴者によって理解されなければならないさまざまな通信プロトコルを用いてさまざまなサービス・プロバイダのコンテンツを送る。通常、クライアントはプロセッサの処理能力が限られているセットトップ・ボックスである。インタラクティブ・テレビ環境におけるコンテンツ、広告、およびＥコマースの規制のための包括的管理ソリューションを規定するアーキテクチャが必要である。また、インタラクティブ・テレビ環境においてアクセス、コンテンツ、およびスケジューリングの適応制御を行う包括的アーキテクチャも必要である。さらに、サービス・プロバイダおよびインタラクティブ・テレビ・システムのプラットフォーム接続、またインタラクティブ・テレビ・システムに送られるコンテンツの完全性を監視する必要もある。

本発明は、分散コンピュータ・システムにおけるＥコマース、コンテンツ、およびサービス・プロバイダによるアクセスの提示および規制を管理する方法と装置である、サービス・プラットフォーム・スイートを提供する。特に、本発明は、サーバ、クライアント、およびサービス・プロバイダの間の相互作用が行われるインタラクティブ・テレビ環境で運用され、クライアントは視聴者、消費者、または購入者であり、サービス・プロバイダはベンダーであり、サーバはクライアントとサービス・プロバイダとの間の相互作用を円滑化する機能である。本発明は、サービス・プロバイダによって提供される品目の購入または配送を管理し、遂行するためのコンポーネントで構成されるサービス・プラットフォーム・スイートを備えている。サービス・プロバイダは、サーバの外部にあっても内部にあってもよい。本発明では、Ｅコマースに対する３つの異なるシナリオをサポートする。パススルー・シナリオと呼ぶ第１のシナリオでは、クライアントと外部サービス・プロバイダとの間で直接情報を受け渡す。部分ホスト・シナリオと呼ぶ第２のシナリオでは、サーバがサービス・カタログのホストとなるが、注文の支払いおよび履行について注文を店またはサービスに受け渡す。完全ホスト・シナリオと呼ぶ第３のシナリオでは、サーバがカタログのホストとなり、さらに注文も処理する。

クライアントが取り引きを遂行する、または購入を実施するために必要な情報は、サーバ・データベースに格納するのが好ましい。このクライアント情報の部分的記録は、セキュリティを損なうことなく取り引きまたは購入を円滑化するためクライアント・デバイスに格納される。クライアント・デバイスは、単一の視聴者デバイスまたは複数の視聴者デバイスとして動作することができ、それぞれの視聴者に関係する別々の情報が格納される。購入取り引きは、クライアントがたとえば、リモート・コントロール・デバイス上のボタンを押すことにより取り引きを開始したときに始まる。このときに、必要な情報を即座に送信するか、またはネットワーク・トラフィックが非常に混雑しているか、またはクライアントがオフラインになっていると判断された場合にクライアント・デバイスにいったん格納しておき後で送信することができる。クライアントの取り引きでは、クライアントおよび購入品目のリストから得られる部分的クライアント情報からなるクライアント情報を使用する。クライアントから部分的情報を受信した後、サーバがそのデータベース内にある対応する追加関連情報を取り出して、取り引きを完了するためにこの取り出されたデータを購入品目のリストとともにサーバから送信する。本発明の利点は、取り引き実行時のサーバの機能である、キャッシャのトランスペアレンシーにある。クライアントとサーバとの相互作用では、最低限、必要ならばログオンし、注文を検討し、支払形式を選択するだけである。したがって、クライアント情報を提供するサーバ・データベースとサービス・プロバイダとの間の相互作用はユーザにとってトランスペアレントである。

サーバ上の取り引きのための中央管理コンポーネントは、インタラクティブ・サービス・マネージャ（ＩＳＭ）である。ＩＳＭは、購入取り引きのさまざまな側面を取り扱うビジネス・エージェントを備える。ビジネス・エージェントでは、取り引きのログ記録、Ｅレシートの作成、パッチのログ記録、エラー・イベントのログ記録、および視聴者のログ記録を行う。

本発明はさらに、利害関係者が視聴者の特定のイベントまたは番組および広告に対する振る舞いおよび反応を測定できるようにする方法も含む。すでに表示されている広告のバナーまたは番組への応答としてのクライアントの視聴活動およびクリック活動に基づいて定量的プロファイルを作成する。このプロファイルは、クライアント・デバイスに格納される。この情報は、電波中継局のサーバによりクライアント・デバイスからマイニングまたは引き出され、視聴者の振る舞いの統計調査に使用することができる。統計調査は、視聴者参加者のデータ・サンプルに関連する個人情報を侵害することはない。引き出された情報を編集し、電波中継局のサーバに格納し、サーバとビジネス契約のある格付け機関からアクセスできるようにする。引き出された情報をさらに編集した場合も、内部レポートとしてさらに編集される。

本発明はさらに、広告をクライアントに適応配信する方法も含む。サーバは、サーバを使って広告をスケジューリングするためのサービス・プロバイダとのインターフェイスを備える。広告は、契約に従ってスケジューリングされ、キャンペーン規則および望んでいる実行時間に明示される。広告は、キャンペーン規則などの基準によりフィルタ処理され、ビジネス規則に則って合意した後、放送ストリームに載せられる。広告サービス・プロバイダは、広告をサーバにアップロードしたり、削除したりすることができる。スケジュールしてから、広告のグループが放送ストリームに送信され、その後、視聴者に表示する広告をこのグループから選択する。クライアント・デバイス上に常駐する視聴者のプロファイルは、特定の広告を選択し、視聴者の番組鑑賞習慣の調査を行うための基準として使用される。

本発明のサービス・プラットフォーム・マネージャはさらに、インタラクティブ・テレビ・ネットワークの完全性および接続も監視する。プラットフォーム・モニタは、中央データベースを必要としない分散型ソフトウェアの方法である。サービス・プラットフォーム・マネージャのオペレータがポートを使ってマシン・レベルの接続性をチェックし、サーバの活動のプロセス・レベルでのオペレーションをチェックし、データ・レベルでのファイル完全性をチェックし、たとえば、ファイルが最新かどうかを確認する。サービス・プラットフォーム・マネージャのオペレータは、監視対象の品目のリストからサービス・プロバイダから提供されるサービスを選択または削除することができる。サービス・プラットフォーム・マネージャはさらに、統計レポートを作成し、所定の時刻に、または所定のスケジュールで、オペレータ側の望む通りに、テストを自動実行するように設定可能なアラーム・システムを備えている。本発明の一実施形態では、サービス・プラットフォーム・マネージャが、パーソナル・コンピュータ上に表示される。他の実施形態では、サービス・プラットフォーム・マネージャは、たとえば、携帯電話やＰＤＡなどの他のデジタル・インターフェイス上で動作する。他の実施形態では、本発明は、フロッピー・ディスク、従来のハード・ディスク、ＣＤ−ＲＯＭ、フラッシュＲＯＭ、不揮発性ＲＯＭおよびＲＡＭを含む知られているあるいは知られていない任意の種類のコンピュータ・メモリなどのコンピュータ読み取り可能媒体で提供され、実行されたときにコンピュータが本発明を実行する命令が格納される。

本発明の他の目的および利点は、以下の詳細な説明を読み、添付図面を参照することで明白になるであろう。

以下の説明では、本発明の好ましい実施形態のいくつかの実施例を取りあげる。
はじめに

アカウントは、プロキシ・コンポーネント、アプリケーション・サーバ・コンポーネント、データ・リポジトリ・コンポーネント、登録コンポーネント、および管理コンポーネントの５つの主要コンポーネントから成り立っている。プロキシ・コンポーネントは、クライアント・デバイスとサービス・プロバイダのコマース・サーバとの通信リンク内に置かれる。プロキシ・コンポーネントは、プロキシ・サーバとして機能する。プロキシは、クライアント・デバイスとサービス・プロバイダ・サーバとの間で送信されるメッセージをインターセプトする。プロキシは、メッセージをアプリケーション・サーバに渡して（必要ならば）処理してから、そのメッセージを本来の送信先に転送する。プロキシは、クライアントからの要求またはメッセージとサーバ・プロバイダのサーバからの応答の両方をインターセプトできるという点で双方向サーバである。

メッセージは、プロキシ・コンポーネントによりフィルタ処理され、ネットワーク・オペレータ（ＮＯ）が資格を管理する、つまり、どのクライアントがメッセージを送信することができ、どのサービス・プロバイダがメッセージを受信することができ、どのような種類のメッセージを送信できるかを管理することができる。そこで、ＮＯがＮＯ受信契約者またはクライアントから利用できるすべてのインタラクティブ・サービスを制御するポータルまたは塀で囲まれた庭を提供することができる。

プロキシ・コンポーネントは、任意のメッセージ形式を処理し、メッセージはＡＳＣＩＩベースで、プロトコルはｈｔｔｐであることが好ましい。アカウントは、プロキシ・コンポーネントの上に作成され、これは、クライアントとサーバ・プロバイダの立場からトランスペアレントであり、このため、本発明は、元の取り引きステップに影響を及ぼすことなく視聴者データをメッセージ内にトランスペアレントに挿入するという意味で、独特のものとなっている。

アプリケーション・サーバ・コンポーネントは、インタラクティブ・サービス・マネージャ、ビジネス・エージェント、およびデータ・アクセス・コンポーネントから成り立っている。インタラクティブ・サービス・マネージャ（ＩＳＭ）は、アプリケーション・サーバの重要コンポーネントである。ＩＳＭは、クライアントおよびサーバとの間でやり取りされるメッセージ・ヘッダを見る。メッセージがクライアントからサービス・プロバイダに送信されているときに、メッセージ・ヘッダ（ｃｏｏｋｉｅヘッダを含む）はメッセージを送信しているアプリケーションを識別する情報（アプリケーション識別子）、メッセージを送信しているデバイスを識別する情報（デバイス識別子）、メッセージを送信している家庭の中にいる視聴者を識別する情報（視聴者ニックネーム）、視聴者の認証ＰＩＮを識別する情報、アカウント処理を必要とするメッセージかどうかを示す情報（処理フラグ）、および必要な処理の種類、つまり同期処理または非同期処理のどれであるかを識別する情報（ａｓｙｎｃフラグ）を含む。メッセージ・ヘッダ内に用意される情報に基づき、ＩＳＭは複数のタスクを実行する。データ・リポジトリからの情報に基づき、ＩＳＭでは、アプリケーションに、メッセージ（データ・リポジトリ内のアクティブなアプリケーション−アプリケーション、および資格に対応するアプリケーション識別子）を送信する許可を設定するようにし、デバイスはメッセージを送信することができる（データ・リポジトリ内の非義務不履行デバイスに対応するデバイス識別子−デバイス資格）。処理が必要ない場合、ＩＳＭはメッセージをプロキシ・コンポーネントに送り返し、さらにこれはメッセージを本来の送信先に転送する。そうでない場合、ＩＳＭはメッセージの処理を続ける。ここでは、分散処理も採用することができ、クライアント・デバイスはまずメッセージをスキャンしてから、送信し、メッセージにアカウント・キーワードが含まれていないか調べて、もし含まれていなければ、クライアントまたはＩＳＭが処理フラグを０にセットする。さらに、アプリケーション開発時に、アプリケーション開発者側で、メッセージにアカウント・キーワードが含まれるかどうかを知り、含まれなければ、処理ビットを０にセットすることができる。パラメータ（処理および非同期ビットを含む）は、メッセージごとに異なる場合があり、したがって１つの取り引きセッション内で、パラメータがメッセージごとに変わる場合がある。

非同期処理には２つの方法があり、１つは、クライアント・デバイスがクライアントとサーバとの間の通信リンクのピーク負荷を低減するために使用するストアアンドフォワード非同期処理である。通信リンクがビジー状態であったり、クライアント・アプリケーションがストアアンドフォワードをサポートするようにプログラムされている場合、クライアント・デバイスは取り引き要求を一時メモリ（ＲＡＭ）または永続的メモリ（フラッシュ、ハード・ドライブ）に格納し、その要求を後でアカウントに転送する。この時間遅延はランダム・パラメータ、計算済みパラメータ（現在の時刻およびポイントツーポイント・ネットワーク・パラメータに基づく）、またはこの両方の組合せとすることができる。

もう１つは、メッセージが（メッセージ・ヘッダ内のフラグまたはデータ・リポジトリ内のアプリケーション設定パラメータのいずれかにより）非同期と指定されている場合、ＩＳＭがメッセージをキュー内に置き、応答をプロキシに返し、その後プロキシがその応答をクライアントに送り返すというものである。応答により、メッセージがすでにキューの中に置かれており、取り引きの結果が後で（たとえば、電子メール、ＳＭＳなどで）送信されることがクライアントに通知される。非同期メッセージを使用すると、サービス・プロバイダに転送する前にメッセージがアカウント内にキャッシュされるので、サービス・プロバイダのサーバへのピーク負荷を低減できる。さらに、キャッシュがアカウント内に一括して置かれるため、サービス・プロバイダごとにそれ専用のキャッシュを用意する必要がなくなる。

ＩＳＭは、メッセージをスキャンして、アカウント特殊キーワードを検索する。各キーワードは、アカウントによって実行される特別なオペレーションに対応しており、各キーワードは、キーワード自体とクライアントによって提供されるパラメータの２つの部分からなる。キーワードとしては、視聴者の連絡先情報（たとえば、出荷先および請求情報）、視聴者の電子財布情報（たとえば、クレジット・カード情報）、視聴者の住所録情報（インスタント・メッセージ・バディー・リストを含む友人および家族の情報）、および取り引き（Ｅレシート）などがある。キーワード・オペレーションのターゲットは、データ・リポジトリとメッセージそれ自体である。各キーワードは、データ・リポジトリからレコードの断片を取り出す操作、レコードをデータ・リポジトリ内に書き込む（または作成する）操作、またはリポジトリからレコードを削除する操作に対応する。キーワードに対応する他のアクションをさらに定義することもできる。

ＩＳＭがキーワードを処理した後、ＩＳＭはキーワードをデータ・リポジトリからのレコードで置き換え、そのキーワードを削除し、かつ／またはそのキーワードをそのパラメータと入れ替える。ＮＯがサービス・プロバイダから視聴者の素性を隠し、アカウントの許可なくして視聴者情報が公開されないようにするため、アカウントでは、セッション識別子という概念を採用している。プロキシとクライアントとの間でやり取りされるメッセージでは、デバイスと視聴者を識別する情報をメッセージ・ヘッダ内に保持する（それぞれデバイス識別子と視聴者ニックネーム）。デバイス識別子と視聴者ニックネームは、クライアント・デバイスまたはクライアント・デバイス・ユーザが変更しない限り変わらない永続的データ項目である。この情報は、プロキシによって削除され、セッション識別子で置き換えられる。デバイス識別子にアクセスするプロキシ・コンポーネントは、サービス・プロバイダから隠されているデバイス識別子の秘密性の完全性を維持するため、サービス・プロバイダまたはサービス・プロバイダ・アプリケーションからは利用できないようになっている。このセッション識別子は一時的なものである、つまり取り引きセッション内でのみ有効であり、そのため、サービス・プロバイダは同じセッションに対応するメッセージに関係するセッション識別子を使用することしかできない。このセッション識別子は、異なる取り引きセッションでは無効になるため、サービス・プロバイダはこの一時的セッション識別子を使用して視聴者を識別することはできない。このセッション識別子は、期限切れパラメータと組み合わせた視聴者は識別子の機能出力により生成される。この機能は、識別子「アカウント」またはＮＯしか知らないときにはサービス・プロバイダには知りようがない。アカウントまたはＮＯのみがセッション識別子を解決して元の視聴者識別子に戻せる。機能出力をさらに暗号化して、元の視聴者識別子のランダムなハッキングを防止できるが、アカウントはセッション識別子と視聴者識別子とのマッピング・テーブルを保持する。

さらに、セッション識別子により、アプリケーションが、受信した視聴者情報を記録し、デバイス識別子とリンクするのを防止することができる。デバイス識別子は、アプリケーションの制御範囲外のコンポーネント（たとえば、リンクまたは条件付きアクセス・コンポーネント）により生成され、アプリケーション側はこの情報断片を認識しない。

ＩＳＭは定期的に、データ・リポジトリから構成パラメータを読み出す。元のデータを上書きすることなく新しいデータが一時ロケーションにまず読み込まれ、新しいメッセージ内で新たに読み込まれたデータを使用する。元のデータを使用したすべてのメッセージで処理が完了すると、元のデータがリリースされる。このメカニズムを採用することにより、ＩＳＭを停止せずにオンザフライでＩＳＭの構成パラメータを更新することができる。ビジネス・エージェントが、サポート・コンポーネントとしてＩＳＭに提供されるが、それぞれのビジネス・エージェントは何らかの特別なビジネス機能を実行する。主要なビジネス・エージェント機能として、取り引きマネージャ（ＴＭ）とも呼ぶ取り引き（Ｅレシート）ビジネス・エージェントがある。

ＴＭでは、新しい取り引きごとに取り引き識別子を作成することにより取り引きを円滑にする。同じ取り引きセッション内の各メッセージに、同じ取り引き識別子のタグが付けられる。ＴＭは、取り引き日、金額、通貨、ステータス、および説明を含む各取り引きの詳細をロギングする。適切なキーワードにより、ＴＭビジネス・エージェントは特定の視聴者のＥレシートと詳細をデータ・リポジトリから取り出す。

視聴者ビジネス・エージェントは視聴者マネージャ（ＶＭ）とも呼ばれるが、適切なキーワードとともに、ＶＭは視聴者のレコードを検索したり、更新（または作成）したり、削除したりする。ＶＭは、視聴者ニックネームおよびデータ・リポジトリに格納されているものと一致するＰＩＮを確認することにより視聴者に対し認証（視聴者資格）を実行する。ロギング機能とエラー・ビジネス・エージェントにより、各メッセージをデータ・リポジトリに記録し、後からデータ・マイニングおよびレポート作成に使用する。また、データ・リポジトリ内への各キーワードの出現を記録し、後で、データ・マイニングおよび請求に使用する。

各ビジネス・エージェントは、ＩＳＭに登録され、ＩＳＭに取り扱えるキーワードを通知する。この通知は、ＩＳＭ起動時のビジネス・エージェントの初期化、またはデータ・リポジトリ内のエントリを通じて実行できる。ＩＳＭは、各キーワードを、キーワード処理できる一組のビジネス・エージェントにマッピングするテーブルを備える。ＩＳＭは、メッセージをスキャンし、キーワードが見つかると、キーワードを処理する対応するビジネス・エージェントを呼び出す。ＩＳＭおよびビジネス・エージェントは、データ・アクセス・コンポーネントを通じてデータ・リポジトリと通信する。ＤＡＣにより、データ・リポジトリとシステムのそれ以外の部分とが隔てられ、データ・リポジトリを別のベンダーまたは異なる技術のもので置き換える場合に（たとえば、データベースの代わりにＬＤＡＰ）、データ・アクセス・コンポーネント（ＤＡＣ）のみを交換すればよく、システムの他の部分に影響を及ぼすことがない。

ＤＡＣはデータ・リポジトリ接続のプールを保持し、この接続のプールを最適な形で使い、データベース・オペレーションを実行する。ＤＡＣは、ＩＳＭおよびビジネス・エージェントとインターフェイスし、レコードを読み込む、レコード更新または作成する、およびレコードを削除するなどのデータ・リポジトリのオペレーションを実行する。ＩＳＭおよびビジネス・エージェントは、ＤＡＣと同期または非同期的にインターフェイスすることができる。同期ＤＡＣオペレーションでは、呼び出し時にファンクション・コールが処理される。非同期ＤＡＣオペレーションでは、ファンクション・コールはまずキューに入れられ、後で処理される。これは、非同期メッセージの概念とは異なる。

データ・リポジトリ・コンポーネントは、アカウントの動作に使用する重要情報を格納する。情報の大半は、アカウントに接続されているデータ・リポジトリ・サーバに格納されるが、情報の一部を分散し、クライアントに格納することで、視聴者による入力の手間を省くことができる。リポジトリ・サーバに格納されている情報としては、視聴者の関連情報（住所情報、電子財布情報、住所録情報）、取り引き（Ｅレシート）関連情報（注文日、金額、店舗名、ステータスなど）、ＩＳＭ構成パラメータ（ロギング・レベルなど）、およびネットワーク、サービス・プロバイダ、アプリケーション、およびデバイス情報がある。

クライアントに格納される情報としては、家庭内の視聴者とニックネームのリスト、クレジット・カードのエイリアス（たとえば、発券銀行名）またはクレジット・カードの下４ケタなどの部分的電子財布情報がある。視聴者が入力する必要のある項目数を減らすことにより、この情報を商取引目的に使用できる。さらに、アカウントは、視聴者がクライアント・デバイスを通じてオンラインで登録できるように登録コンポーネントを備える。このコンポーネントにより、視聴者は、プロファイルの作成およびデータ・リポジトリへの必要な情報（たとえば、名前、住所、電子財布など）の提供、視聴者プロファイル情報の更新、Ｅレシート（取り引き）履歴のレビューを行うことができる。

本発明により個人情報の共有を行える。個人がデータ・リポジトリに登録された後、個人情報を共有することを決定することができる。この情報の所有者は、その後、この個人情報に対する特権を付与することができる。この情報に対する特権には、表示、更新、および削除がある。Ｅコマース活動の取り引き情報などの情報が共有されると、複数のアプリケーションにより使用できるようになる。この共有情報にアクセスするには、この実施形態で述べている同じ「キーワード・プロセス」を使用する。

たとえば、住所録を共有することができる。視聴者は、祖母の住所や電話番号など、その住所録情報へのアクセス権を付与することができる。この情報は、いったん共有されると、共有者の家庭と関連する、または許可されたユーザの定義されているグループ内のすべての視聴者によって使用される。たとえば、共有された住所録情報は生花店アプリケーションで使用できる。花を購入した視聴者の場合、配送情報の入力を求められると、花購入アプリケーションが個人住所のリストとさらに共有住所を家庭内のすべての視聴者または共有情報の許可された全ユーザから取得する。次に、配送または出荷先住所について住所を選択する。この場合、特に祖母の住所が家族の一員による共有住所である可能性が最も高い。さらに、視聴者がクレジット・カード番号または銀行口座番号などの個人情報が収められている電子財布をセットアップかつ／または作成できるアプリケーションも用意される。セットアップが済んだら、この電子財布の所有者は、この電子財布情報を使用して家族の他の一員がクレジット・カードまたは銀行口座番号を使用できるようにする使用特権を与えることができる。視聴者がショッピング・アプリケーションで注文を出した後、視聴者は一連の確認操作を求められるが、これには、家族の他の一員により共有されている電子財布の詳細またはその個人の電子財布の詳細が含まれる。次に、視聴者は、当該店に渡す選択項目の電子財布を選択する。

ＮＯによるアカウント・オペレーションの制御、設定、ネットワーク、サービス・プロバイダ、およびアプリケーション・パラメータの設定、データ・リポジトリ内の視聴者情報の取得、修正、または削除、アカウントを通じた活動に関連するさまざまなレポートの作成のための管理コンポーネントが用意される。

図１Ａを参照する。サービス・プラットフォーム・スイート（ＳＰＳ）５０は、コンテンツ変換１０４、トランザクション制御／ビジネス機能１０６、およびトランスポート変換１０８という３つのカテゴリに大まかに分けられるアプリケーションのグループからなる。ＳＰＳにより、サービス・プロバイダ１００はクライアント１１２とやり取りすることができる。サービス・プロバイダ１００は、通信リンク１０２を通じてＳＰＳ ５０と通信する。次に、ＳＰＳ ５０は、クライアント１１２、たとえば、ＤＣＴ ２０００セットトップ・ボックス（ＳＴＢ）と通信する。クライアント１１２はＳＴＢ、デジタル・アシスタント、携帯電話、または通信リンク１１０を通じてサービス・プラットフォーム・スイートと通信できるその他の通信デバイスとすることができる。コンテンツ変換１０４およびトランスポート変換１０８サービスは、コンテンツおよび通信機能を備え、ビジネス機能サービスはＳＰＳを介してサービスとクライアントとの間の取り引きを実行するビジネス制御機能を備える。

図１Ｂには、図１Ａに示されているのよりも一般的なアーキテクチャを示している。図１Ｂでは、トランザクション制御／ビジネス機能２０６はサービス・プラットフォーム・スイートとさらに強力なクライアント２１２、たとえばＤＣＴ ５０００ ＳＴＢに分散されている。たとえば、より強力なクライアントは一部のビジネス機能（たとえば、広告キャンペーン規則および広告／ビジネス・フィルタを実行し表示する広告を選択する）を実行し、クライアント２１２により適しているコンテンツを選択することができる（たとえば、ユーザ・プロファイルに合う広告または番組を選択する）。これらの機能は、あまり強力でないクライアント、たとえばＤＣＴ ２０００ ＳＴＢや携帯電話向けにサーバで実行される。

ＳＰＳ機能は図２に展開されている。図２に示されているように、トランスポートおよび通信２１４はコンテンツ変換２０４、ビジネス・エージェント２２６、およびトランスポート変換２０７を備える。コンテンツ変換２０４は、コンテンツ・フィルタ２２４を含む。トランスポート変換２０７は、放送２３４ストリーム通信機能、負荷分散２３６機能、およびポイントツーポイント（Ｐｔ−ｔｏ−Ｐｔ）２３２通信機能を備える。ビジネス機能２０６は、サービス・データ２１６、ネットワーク・データ２１８、ユーザ・データ２２０、およびビジネス規則２２２にアクセスする。

図２の機能は図３に展開されている。図３に示されているように、ビジネス機能２０６は、サービス・マネージャ２３８、視聴者マネージャ２４０、取り引きマネージャ２４２、および広告マネージャ２４４の４つの主要機能コンポーネントを備える。好ましい実施形態の高水準の動作の流れを示す一実施形態を以下に示す。

図３によれば、サービス・プロバイダ２００は、ネットワーク・オペレータと交渉して、オペレータのＳＰＳ ５０を介して受信契約者にサービスを提供する。ネットワーク・オペレータは、サービス・マネージャ２３８を使用してサービスおよびそのサービスと関連する交渉済みビジネス規則２２２（たとえば、スケジュール、帯域幅要件、視聴者情報へのあるレベルのサービス・アクセスの提供）を登録する。サービス・マネージャ２３８は、サービス・データ２１６（たとえば、ＵＲＬアドレス、コンテンツ）を格納する。ビジネス規則２２２およびサービス・データ２１６に基づいて、サービス・マネージャ２３８は放送通信２３４機能と通信して、コンテンツ・プロバイダからコンテンツを取り出す。

コンテンツは、サービス・プロバイダ２００から取り出されると、コンテンツ変換２０４とコンテンツ・フィルタ２２４により処理され、クライアント・デバイス２１２に適した形式に変換される。放送２３４機能により、コンテンツが放送２３４ネットワークに適した形式に変換される。変換されたコンテンツは、放送リンク２４１を介してクライアント２１２に届く。クライアント２１２およびサービス・プロバイダ２００は、トランスポート変換２０７の一部であるポイントツーポイント・リンク２１０およびポイントツーポイント機能２３２を介してやり取りする。サービス・プロバイダ２００は、ショッピング、オーディオ／ビデオ、ゲーム、投票、広告、メッセージ送受信、またはその他のサービスに対応している。

クライアント２１２は、ポイントツーポイント２３２通信リンクを通して、ＳＰＳ ５０およびサービス・プロバイダ２００と通信する。負荷分散機能２３６は、ビジネス機能２０６とやり取りし、放送２３４の通信リンク２１１とポイントツーポイント２３２の通信リンク２１０への最適な負荷分散を決定する。ビジネス・エージェント２２６は、ビジネス規則２２２を使用して、サービス２００とクライアント２１２の間の情報のやり取りおよび交換を制御する。たとえば、ネットワーク・オペレータは選択により、サービス・プロバイダ２００がユーザ情報にアクセスするのを禁止することができる。サービス・プロバイダ２００は、ユーザ情報にアクセスするにあたってビジネス規則２２２およびサービス・データ２１６に基づく料金を支払うのが好ましい。

視聴者マネージャ２４０は、クライアント／ユーザ情報をユーザ・データ２２０に格納する。ビジネス・エージェント２２６は、サービス・プロバイダ２００への視聴者情報の流れを制御する。取り引きマネージャ２４２は、サービス・プロバイダ２００とクライアント２１２との間で交換される取り引き情報を記録する。広告マネージャ２４４は、ビジネス規則２２２およびユーザ・データ２２０に基づいて、放送２３４リンク２４１およびポイントツーポイント２３２リンク２１０を介してクライアントに提示される広告と広告の種類を決定する。

図４は、ＳＰＳ ５０の好ましい実装の他の実施形態を示している。サービス・プロバイダ２００は、インターネットまたは他のネットワークまたはネットワーク・オペレータからアクセス可能な通信チャネルを介してショッピング、チャット、およびその他のサービスを提供する。ネットワーク・オペレータ（ＮＯ）は、ＳＰＳを使用して、これらのサービスにアクセスする。サービス・マネージャ２３８を含むビジネス機能２０６は、カルーセル・マネージャ２５４とやり取りして、サービス・プロバイダ２００からコンテンツを取り出す。カルーセルは、ＳＰＳ ５０からクライアントへのオーディオ／ビデオ／インタラクティブ・データ放送の反復ストリームを含む。カルーセル・マネージャ２５４、取り引きマネージャ２４２、およびサービス・マネージャ２３８は、放送カルーセルにコンテンツを挿入したり、削除したりする操作を制御する。サービス・コンテンツが取り出され、Ｈ２Ｏ ２４８によりクライアントに適した形式に変換される。Ｈ２Ｏ ２４８は、コンテンツ変換２０４およびコンテンツ・フィルタ２２４の可能な一実装である。Ｈ２Ｏは、ＨＴＭＬコンテンツをサービス・プラットフォームのクライアント読み取り可能コンテンツに変換する。変換されたコンテンツは、データ・カルーセルにフォーマットされ、オープン・ストリーマー２５６により多重化され、クライアント２１２に放送される。クライアント２１２は、サービスとやり取りし、必要ならば、ＳＰＳ ５０およびサービス・プロバイダ２００と通信する。ポイントツーポイント通信はサービス・ゲートウェイ２４６を通る。負荷分散機能２３６は、ビジネス機能２０６、カルーセル・マネージャ２５４、およびサービス・ゲートウェイ２４６とやり取りし、放送リンク２４１とポイントツーポイント通信リンク２１０との間の最適な負荷分散を決定する。ビジネス機能２０６は、ビジネス・エージェント２２６とやり取りして、サービス・プロバイダ２００とクライアント２１２の間のアクセスおよび情報交換を制御する。

図５は、クライアント・デバイスが、たとえば、ＤＣＴ ２０００ではなくＭｏｔｏｒｏｌａ ＤＣＴ ５０００ ＳＴＢを使用している場合により高い処理能力を備える環境でのＳＰＳの他の実施形態を示している。コンテンツ変換（たとえば、Ｈ２Ｏ）およびポイントツーポイント・トランスポート変換（サービス・ゲートウェイ／ＤＡＰＴ）は両方とも、クライアント２１２プロセッサに組み込まれている。したがって、クライアント２１２はサービス・プロバイダ２００と直接通信することができる。なおビジネス機能２０６および他のＳＰＳコンポーネントはすでに述べたように対応する機能を実行する。

サービス・ゲートウェイは、サービス・プラットフォーム・スイートのリターン・パス対応コンポーネントである。これは、ＳＴＢクライアントをコンテンツ・プロバイダのバックエンド・システムに接する。メッセージがＳＴＢクライアントからコンテンツ・プロバイダのバックエンド・システムに転送されるが、その際にＨＴＴＰおよびＳＭＴＰなどの標準インターネット・プロトコルを使用する。サービス・ゲートウェイでは、プロトコル・アダプタを使用して、セットトップ・ボックスで使用している低水準通信プロトコルと高水準インターネット・プロトコルとの間の変換を行う。サービス・ゲートウェイでは、ＤＡＴＰ（ＤｉｇｉｔａｌＴＶ Ａｐｐｌｉｃａｔｉｏｎ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）と呼ばれる効率のよい軽量なプロトコルを使用し、セットトップ・ボックスのリターン・パス・ネットワークを介してメッセージをトランスポートする。このため、貴重なＳＴＢ資源が節約され、このような通信スタックをサポートできないローエンドのＳＴＢでも標準インターネット・アプリケーション・サーバとやり取りすることができる。リターン・パス・ネットワークとしては、たとえば、オープン・インターネット、ＶＰＮ（仮想プライベート・ネットワーク）、またはクローズドＷＡＮ（ワイド・エリア・ネットワーク）がある。

ＳＰＳを使用すると、ＮＯは視聴者に対しさまざまなインタラクティブ・サービスを必要なだけ提供することができ、そのため、視聴者はサービスを定期的に、繰り返し利用することができる。取り引き対応サービスでは、ＮＯはインタラクティブ・サービスから利用できる収益機会を拡大できる。ＳＰＳを使用すると、すべてのインタラクティブ・サービスおよびターゲットとなる広告について広告インベントリの管理を行うことができ、また多数のサービス（パブリッシュ、広告、Ｔコマース、およびメッセージ送受信）をｉＴＶアプリケーションに組み込むことができる。ＮＯは、ＳＰＳの機能を利用して、最終視聴者との顧客関係の管理を保持することができ、顧客サービスを改善できる。注文追跡を通じてＳＰＳを利用することで、ネットワーク・オペレータは適切なレベルの顧客サービスを視聴者とコンテンツ・プロバイダに提供することができる。既存のインターネット標準を使用できるため、ＳＰＳは日用品インフラ・コンポーネントを利用できる。ＮＯは、ＳＰＳを使用して、ネットワーク上で提供されるインタラクティブ・サービスを一括集中管理することができる。

ＳＰＳにより、コンテンツ・プロバイダは標準のＷｅｂ開発に匹敵するコストで新しいｉＴＶアプリケーションを迅速に開発し配備することができる。ＳＰＳを利用すると、コンテンツ・プロバイダは既存のインターネット・ベースのインフラストラクチャ、プロセス、およびプロシージャをコンテンツのパブリッシュと取り引きの処理の両方に対して再利用することができる。ＳＰＳでは、ｉＴＶアプリケーションのリアルタイムの動的更新が可能であり、コンテンツ・プロバイダは正確で、秒まで最新の情報とともにアプリケーションを提供することができる。基本レベルのＳＰＳでは、コンテンツ・プロバイダは好みおよび電子財布を含む視聴者詳細へのアクセスを制御することができる。高度レベルのＳＰＳでは、コンテンツ・プロバイダはすべてのｉＴＶアプリケーションの視聴者利用で得られるビジネス・インテリジェンスを活用できる。コンテンツ・プロバイダは、これを利用して、ターゲットのプロモーションおよび推奨などの特徴を含む個人化されたサービスを提供することができる。

ＳＰＳを使用すると、視聴者に一貫した体験をしてもらうことができ、アプリケーションを視聴者にとって使い勝手のよいものにできる。視聴者は、個人情報およびクレジット・カードの詳細の機密が保たれているという認識を利用できる。通信は統一され、一体化されているため、視聴者は電子メール、チャット、インスタント・メッセージング、テキスト・メッセージング（ＳＭＳ）を使用して簡単にかつ迅速に通信することができる。視聴者は、定められた好みまたはトランスペアレントなプロファイリングを通じて、自分の要件およびプロファイルに合わせて個人化されているアプリケーションを楽しむことができる。このため、視聴者に関連するプロモーション、推奨、および広告が得られる。

Ｅコマースサポート・シナリオ
本発明のＳＰＳのアプリケーションの概要および各図に示されている各機能の説明を以下に述べる。ＳＰＳの主要な目的の１つは、ネットワーク・オペレータがＥコマースを提供し管理できるようにすることである。異なるＥコマースシナリオが、ネットワーク・オペレータおよび選択されたサービスの要件に応じてＳＰＳによりサポートされる。ＳＰＳを利用すると、オペレータのＥコマースへの参加水準を柔軟にできる。

後述のＥコマースシナリオのそれぞれで、ネットワーク・オペレータはポータルを管理し、ポータルに表示できる店および／サービスの種類を決定する。ＳＰＳは、すべてのシナリオにおいて視聴者情報の流れを制御する。第１のＥコマースシナリオは「パススルー」シナリオと呼ばれ、ＳＰＳはサービスとクライアントの間の仲介役である。ＳＰＳは、サービスによって提供される製品カタログ（たとえば、サービスによって提供される書籍および価格のリスト）のホストとなること、あるいは注文（たとえば、ＳＰＳを介してサービスから書籍を購入すること）を処理するということはしない。ＳＰＳは、視聴者情報へのアクセスを制御し、サービスの取り引きをロギングするだけである。第２のシナリオは「部分ホスト」シナリオと呼ばれ、ＳＰＳはサービス・カタログのホストとなるが、注文の支払いおよび履行について注文を店またはサービスに受け渡す。第３のシナリオは「完全ホスト」シナリオと呼ばれ、オペレータがカタログのホストとなり、注文を処理する。

ＳＰＳ ５０を使用するネットワーク・オペレータは、１つのネットワーク内で３つのすべてのシナリオを同時にサポートすることができる。パススルー・シナリオの下での動作を選択できるサービスもあれば、部分ホストまたは完全ホスト・シナリオの下での動作を選択できるサービスもある。ＳＰＳは、３つすべてのＥコマースシナリオを同時にサポートする。たとえば、ＳＰＳが主にサービス・クライアント間のつなぎ役として動作する場合、パススルー・シナリオではオペレータの商取引への最低限の関与が必要である。しかし、オペレータの商取引への関与が最低限であっても、ネットワーク・オペレータが顧客の電話問い合わせに答えられることが多くの場合に望ましい。たとえば、顧客がどのサービスから購入したか判断できず、問題が生じたときに、オペレータに電話をかけることになる。そこで、適切な顧客関係を保持し、視聴者呼び出しを質問に対する回答と注文の問題解決にふさわしいサービスに回すためにもオペレータが注文を追跡するようにする。

履行／支払いオペレーションなしのＥコマース対応を含む部分ホスト・シナリオでは、オペレータが関与する第２のレベルが必要である。この場合、サービス・プラットフォーム・スイートにより、ＮＯはＥコマースサービス（ショッピング、チャット、映画注文など）を構築し、サービスの取り引きの流れを制御し、サービス製品データベースのホストとなり、デフォルト・ソリューションなどの内部Ｅコマース・エンジンを提供することができる。しかし、ＳＰＳでは、クライアントからサービスへの注文の支払いおよび履行を処理しない。部分ホスト・シナリオでは、Ｅコマース対応サービスはＳＰＳの外部にある自カスタムＥコマースインフラストラクチャを実行し、自Ｅコマース・エンジンとの自カスタム・サービス作成インターフェイスを提供することができる。

ＳＰＳによって完全に制御される、完全ホスト商取引機能をサポートするためには、オペレータの関与の第３のレベルが必要である。完全ホスト・シナリオでは、ＳＰＳがネットワークおよびクライアントまたは視聴者情報へのサービスのアクセスを制御する。ネットワーク・オペレータは、ポータル管理を実行するが、これは、サービスの追加削除、サービス・データ内のサービス・プロパティの変更（ストア／ショップ／サービスのバージョン、ストア／ショップ／サービスの種類、製品の種類、帯域幅、スケジューリングなど）、およびサービス製品提供物カタログの更新を含む。

ＳＰＳを使用するとさらに、ＮＯはさまざまなショップまたはサービス間で動作するマクロ機能を管理することができる。たとえば、ＳＰＳを使用して、ストア／サービスのリスト、製品提供ページ、およびすべてのショップ／サービスにわたる検索機能を提供することができる。ＳＰＳはさらに、モール・ディレクトリ機能および異なるショップにまたがるグローバル製品検索エンジンを備える。ＳＰＳでは、ポータルのルック・アンド・フィールの管理を行うことができ、広告スペース、コンテンツ、およびスケジューリングの広範な適応型オペレータ制御を行うことができる。ＳＰＳ視聴者プロファイリング機能により、適応型広告作成およびコンテンツ管理を行える。適応型管理はさらに、トラフィック・ピークおよび伝送障害の運転中監視機能も備える。

サービス・プラットフォーム・キャッシュ１３８はさらに、キャッシュ内のコンテンツのステージング機能を持つ、つまり、クライアントへの放送前にサービス・コンテンツ放送を遅らせたり、チェックしたりするということである。サービス・プラットフォーム・取り引きマネージャは、取り引きのデータベースにすべての取り引きを記録し、正確なオペレータ収益回収（ＳＴＢがオフになっている場合でも）および視聴者プロファイル１６２および視聴者カテゴリ１６０内の受信契約者プロファイル（視聴者購入および視聴習慣）を確実なものとするが、これにより、ネットワーク・オペレータは付加価値データを得られる。

ＳＰＳは、視聴者情報はネットワーク・オペレータ側のみがネットワーク・オペレータの制御に従いサービスに送らなければならないとすることで、オペレータの貴重な受信契約者プロファイル・データベースを保護する。受信契約者の識別情報を保護するために、サービスが取り引き詳細をＳＰＳに送信するセッションで、抽象化されたユーザ識別子（つまり、セッション識別子）をサービスに送信する。ユーザ識別子またはセッション識別子はセッション固有である。家族が同じＳＴＢを使用する場合のように、クライアント・デバイスと関連する複数のユーザ識別子がありえる。家族の各メンバおよび家庭ＳＴＢは、サービス・プラットフォーム視聴者マネージャにより個別に視聴者カテゴリを割り当てられ、追跡され、プロファイルが作成される。サービス・プロバイダは、セッション識別子を通じてのみクライアントまたはＳＴＢ識別子を知る。ネットワーク・オペレータのみが、セッション識別子を注文の履行に必要な視聴者情報詳細（氏名、住所、出荷情報、クライアント・デバイス・ハードウェア識別子など）に解決できる。クライアント・デバイス・ハードウェア識別子がないと、サービス・プロバイダはＳＰＳを通さずにクライアント・デバイスと接触することはできない。したがって、クライアント・デバイス・ハードウェア識別子は、サービス・プロバイダに公開されない。オペレータ側でクレジット・カード集金またはその他の取り引きの実行を望んでいない場合には、クレジット・カード番号またはその他の情報については例外とすることができる。ＳＰＳの機能は選択可能である。

取り引きログも、累積的ユーザ・プロファイルの生成のためクライアントの視聴および取り引きデータをマイニングするのに役立ち、また協調フィルタリングなどのより高度なプロファイリング手法にも使用される。視聴者またはクライアントは、視聴者ユーザ・プロファイルに基づき１つまたは複数のカテゴリ（たとえば、「スポーツ・ファン」、「フランス人シェフ」）に分けることができる。カテゴリを使用することで、ネットワーク・オペレータが視聴者／クライアントの長期および短期視聴および購入動向に基づき適応型ターゲット広告作成および放送を行うことができる。

ＳＰＳは、財布機能を備えるが、これはチェックアウト／購入サポート機能を持つ。この財布機能は、ＳＰＳによってサポートされているが、選択されたショップまたはサービスは自分のチェックアウト・プロシージャに有利なようにこの財布機能をバイパスすることもできる。財布機能は、視聴者プロファイル、視聴者カテゴリ、および取り引きログに関するデータを記録し、そのようなデータにアクセスする。したがって、この財布機能により、ユーザによるデータのタイピングまたは入力が最小限に抑えられる。この機能は、特に、ユーザがデータ入力容量に制限のあるＴＶリモート・コントロールで注文するときに役立つ。通常、財布機能向けのコンテンツは下４桁を取り除いたクレジット・カード番号であり、ユーザは確認のためその下４桁を補うか、または出荷先住所を入力するだけでよい。

オプションにより、すべてのユーザ情報が財布機能に入れられ、サービスから隠される。財布情報は、ＳＰＳとクライアントの両方に存在する。ＳＰＳ上の財布情報に、クライアント出荷先住所、クライアント完全クレジット・カード番号など、できる限りの情報を収めるのが好ましい。ＳＴＢ内の財布情報には、どのクレジット・カードで購入を行ったかを視聴者に覚えておいてもらうためのクレジット・カードの下４桁などの部分情報のみを含めることができる。部分情報は、ＳＴＢデータにアクセス可能なＳＴＢを使用する信頼できない人および信頼できないアプリケーションから保護するためにＳＴＢ内に格納される。

視聴者がクリックしてＥコマースアプリケーションまたはサービスの呼び出しがトリガされたときなどリンクが発生すると、ＳＰＳは、受信契約者のナビゲーション位置を決定して、それを取り引きのデータベース１５８に記録する。ＳＰＳはさらに、視聴者がストアへのリンクを辿ったとき、または視聴者が購入（「衝動買い」と呼ぶ）を決定したときに見ていた番組を決定し、記録する。取り引きのデータベース１５８を使用すると、オペレータは詳細なコンテキストおよび購入履歴を記憶し受信契約者に提供することができる。さらに、コンテキストおよび購入履歴をこのように格納するのは、受信契約者プロファイルおよびカテゴリ情報を改善するのに役立ち、これにより、追加収益を発生しかつ／またはＥコマースプロバイダとのチャンネル取引の一部となることができる。

ＳＰＳは、サービス・カタログをパブリッシュする（ＨＴＭＬベース）。ＳＰＳは、Ｅコマースをサポートする衝動買いおよびスケジューリングをサポートする。ＳＰＳはさらに、ストアアンドフォワード機能も備え、これにより、多数の注文に対する送信ピークの管理が可能になり、通信コストが低減される。クリックでインタラクティブ広告を見ていく機能が、ＳＰＳサポートでサポートされているが、それは、パンフレットを注文するのは無料商取引に相当するからである。

ＳＰＳが備えるデフォルト（およびオプション）のＥコマース・エンジンは、高速で扱いやすいＥコマースショップ・ページ作成機能、マルチショップ・ホスティング、カタログベースのＥコマース（放送およびオンライン）、衝動買い機能、組み込み電子メール機能、マーケティング・キャンペーンを円滑にする動的／適応型ページ生成（ギフト、個人化されたプロモーション、歓迎特別品など）、カタログ・ページ作成のための個人化された規則、リアルタイムの取り引きサポート（たとえば、発券）、トランザクション制御、広告キャンペーン測定レポート、および衝動買い用の電子番組ガイド（ＥＰＧ）との同期処理を特徴とする。

ＳＰＳＥコマースコンポーネントは、ＴＶからＥコマース取り引きを有効にすることで、受信契約者１人当たりのネットワーク・オペレータ収益を高める。サービス・プラットフォーム・スイートは、適用型ターゲット・マーケティングの受信契約者の視聴および購入習慣をネットワーク・オペレータが知る能力を高める。サービス・プラットフォーム・スイートは、家庭の購入習慣をおよび好みの「ポータル」または「塀で囲まれた庭」の貴重なデータベースを提供し、開発を加速し、生産性ツールを備えてインタラクティブＥコマースショップおよびサービスを迅速に作成することによりＥコマース対応サービスの配備コストを低減する。

サービス・プラットフォーム・スイートを使用すると、サービスでは自身の内部スタッフを頼りにインタラクティブＴＶプレゼンスを作成し、必要ならば、テレビ放送および視聴者との対話操作用に最適化されている、ＳＰＳによって提供されるネットワーク・オペレータのデフォルト商取引エンジンを使用することができる。したがって、ＳＰＳは、オペレーション・コスト（放送管理、ストアアンドフォワードなど）を引き下げ、それにより、オペレータの帯域幅により生まれる価値または収益を高める。

ＳＰＳを使用することで、ネットワーク・オペレータは自ネットワークへのＥコマースの配備を円滑化し、Ｅコマース収益の分け前を捕捉できる。ＳＰＳ財布機能を使用すると、ＮＯはクレジットを管理し、支出限度を課し、少額決済を有効にすることができる。サービスは、サービス・マネージャおよび視聴者マネージャとやり取りして、視聴者プロファイルおよびカテゴリに基づきクライアントに提示するためにＮＯがＳＰＳを介して選択するサービスのグループを提供することができる。ＮＯは、逆に、その受信契約者プロファイルをサービス・プロバイダに公開し、受信契約者への専用視聴者ターゲット提供物および広告を要求することができる。

ＳＰＳは、カタログ放送パブリッシュ機能および外部Ｅコマース・プラットフォームによるオンライン取り引き実行機能を備える。ＳＰＳはさらに、オペレータ側で使用する一括集中取り引きログも用意する。ＳＰＳが備えるＥコマース・エンジンが備えるのは、ＳＫＵリポジトリ、製品提供物カタログ作成および管理ツール、カタログ検索エンジン、ショッピング・カート機能、注文リポジトリおよび管理機能、注文履行および管理機能、製品在庫追跡および管理機能、適応型価格設定およびプロモーション管理機能、Ｅコマース・ビジネス・シナリオ作成機能、動的マーケティング管理機能、およびビジネス・レポート作成（視聴者カテゴリ／プロファイル購入表示トレンド）およびビジネス規則により許可されたときの視聴者管理アクセス機能である。

ＳＰＳでは、ビデオ・イベントによりトリガされる特別オファーなどのビデオと同期した動的適応型コンテンツを使用できる。視聴者注文用のストアアンドフォワード機能により、広告が実施されて、多数のクライアントが注文または問い合わせで応答したときなどの取り引きピークを緩和し、制御することができる。サービス・プラットフォーム・スイートではさらに、視聴者／クライアントがオフラインのときにサービスから視聴者注文にアクセスすることができる。また、サービス・プラットフォーム・スイートでは、視聴者オンラインカタログ閲覧、ユーザ・プロファイル管理、プロファイリングによるコンテンツ・ターゲット、およびユーザ・プロファイルおよびカテゴリに基づくターゲット電子メールを使用できる。サービス・プラットフォーム・スイートは、請求、支払い処理および精算、および暗号化およびセキュリティの機能を備える。ＳＰＳを備えるコンポーネントおよび好ましい実施形態においてインタラクティブ・テレビ環境を管理するためにどのようにやり取りするかについて詳述する。

図４に示されているように、ＮＯは、サービス・マネージャ２３８を使用して、サービス・プロバイダによって提供されるサービスを制御し管理することができる。特に、サービス・マネージャ２３８では、ＮＯはサービスを登録し、サービスを開始し、サービスを管理し、サービスを終了することができる。サービス・マネージャ２３８６は、サービスによって占有されている帯域幅（放送およびポイントツーポイント）へのアクセスをスケジュールし、アクセスできるようにする。サービス・マネージャ２３８は、請求書作成のためサービス提供コンテンツおよびモニタ・サービスをキャッシュし、ホストとなり、管理する。

サービス・マネージャ２３８は、放送、コンテンツ・フィルタ、およびプラットフォーム・ビジネス・エージェント・パラメータ２２６とやり取りする。サービス・マネージャ２３８は、複数のネットワーク・マルチプレックスおよび電波中継局に対するサービス制御（サービスの開始および停止）を実行する。サービス・マネージャ２３８は、サービス・プロバイダ契約のセキュリティ管理および実施のため視聴者取り引きのビジネス規則を作成して強制し、視聴者／クライアント情報へのアクセスを制御するという形でコンテンツ・プロバイダを管理する。サービス・マネージャ２３８はさらに、放送スケジューリング、帯域幅管理、およびコンテンツ管理の機能を備え、サービス／クライアントのバージョニング、セルフサービス・サービス登録、ワークフローのコミショニングおよび配備、コンテンツ・プロバイダ請求書作成、および調停の機能を含む。

図４に示されているように、取り引きマネージャ２４２は、取り引きのデータベースに取り引きを記録し、管理する。これらの取り引きは、購入および広告応答からサービス・コンテンツ要求までさまざまである。取り引きマネージャ２４２を使用することで、ネットワーク・オペレータは取り引きのデータベースの追跡、クエリの実行、修正を行って、取り引きに関する顧客要求に応答することができる。また、取り引きマネージャ２４２では、ＮＯはサービス・プロバイダに対して、サービスからＮＯ受信契約者クライアント・ベースまでの間に発生した取り引きの量について請求することができる。取り引きマネージャ２４２は、外部支払いサービスとやり取りして、金融取引を実行する。さらに、取り引きマネージャ２４２は、視聴者／クライアント注文情報にアクセスできるように外部と内部の両方の商取引エンジンとのインターフェイスを備える。取り引きマネージャ２４２を使用して、注文をクライアント・デバイス内にキャッシュしておきストアアンドフォワードオペレーションを実行するか、または取り引きマネージャ２４２にキャッシュしてバッチ処理することができる。

取り引きマネージャ２４２は、さらに、１回限りの取り引き関連セッション識別子によりセッション管理を実行する。取り引きマネージャ２４２は、サービスに対する拡張可能なソリューションを使用可能にする非同期取り引き処理および取り引き格納を実行する。このような非同期バッチ処理を行うと、サービスに単純な機能（たとえば、投票やクイズ）の取り引きインフラストラクチャを用意する必要はない。さらに、取り引きマネージャ２４２は、注文捕捉、コンテンツ・プロバイダ更新、視聴者アクセス・アプリケーション、およびサービス・プロバイダへのメッセージ送受信またはＵＲＬリンクを含む注文ステータス管理を実行する。さらに、取り引きマネージャ２４２は、アフィニティ・スキーム(Affinity Scheme)、発送時支払い、および取り引き・ベース・コンテンツ・プロバイダ請求書作成の機能も備える。

図４に示されているように、視聴者マネージャ２５２は受信契約者／ユーザ登録２６４、好み、およびプロファイル情報２６２を管理する。視聴者マネージャ２５２により、ユーザはデータベース内の個人情報を登録し記録することができる。個人情報には、視聴パターン、販促に関する好み、個人、財布、および人口統計情報などが含まれる。この記録された情報およびユーザの活動に基づいて、視聴者マネージャ２５２はプロファイル情報を生成し、ユーザ・プロファイル２６２および予想される好みおよびニーズに合わせてユーザをカテゴリに分類し、ターゲット・サービス、コンテンツおよび広告を製作する。さらに視聴者マネージャ２５２は、サービスおよび視聴者パラメータの一括更新も実行する。

ＳＰＳを使用すると、ネットワーク・オペレータは視聴者データベースへのアクセスを制御し、ネットワーク・オペレータと特権情報（たとえば、クレジット・カード番号、視聴者の実際の氏名、家の住所、電話番号、社会保険番号、クライアント・デバイスの物理的アドレス、クライアント・デバイス・ハードウェア識別子など）にアクセスできる契約を事前に交わしているサービス・プロバイダのみを許可するようにできる。分散機能については、つまり、クライアントが十分な処理能力と記憶容量を備えている場合、視聴者マネージャ２５２により、クライアント・デバイスに格納されている個人およびプロファイル情報にアクセスすることができ、またクライアント・デバイスがユーザの好みのコンテンツを選択するようにできる。クライアントは、クライアント・デバイス（たとえば、ＳＴＢ）内のビジネス・フィルタを介してユーザの好みのコンテンツを選択する。

視聴者マネージャ２５２は、家庭／受信契約者／ＳＴＢ（またはその他のクライアント・デバイス）識別および認証を行うことができ、サービス・ゲートウェイおよび親制御機能をサポートする。視聴者マネージャ２５２は、ニックネームおよび個人識別番号を介した単一ＳＴＢでの複数視聴者識別および登録認証をサポートする。視聴者識別子は、クライアント・デバイス識別番号から導くのが好ましい。視聴者マネージャ２５２は、観察されている累積ＴＶ視聴および購入習慣にリンクされているロギング、生成、および組合せ決定を通じて家庭および個人の視聴者プロファイリングを実行する。視聴者マネージャ２５２は、ＳＰＳとＳＴＢとの間の分散データ捕捉および格納をサポートしており、また双方向同期もサポートする。視聴者マネージャ２５２では、すべてのＳＰＳアプリケーションの間で分散プロファイルを使用することができ、外部ＳＭＳ／ＣＲＭとの同期処理を行う。

視聴者マネージャ２５２では、ＳＴＢまたはその他のクライアント・デバイスへのニックネーム、フルネーム、およびＰＩＮ格納を含む抽象視聴者識別子を使用した単一のＳＴＢまたはクライアント・デバイスに対する複数の視聴者登録が可能である。ビジネス・エージェント２２６は、サービス・プロバイダと視聴者との間のやり取りの取り引きビジネス規則を強制する。ネットワーク・オペレータによって定められているビジネス規則に基づき、またサービス・プロバイダとの契約に基づき、ビジネス・エージェント２２６はユーザ情報への取り引きおよびサービス・プロバイダによるアクセスを制御する。ビジネス・エージェント２２６は、取り引きの実行時に視聴者情報の取り込み、置き換え、および削除を行うことができる。

ビジネス・エージェント２２６は、受信契約者とサービス・プロバイダとの間のセッションを確立する。ビジネス・エージェント２２６は、視聴者情報詳細へのアクセスを制御し、サービス・プロバイダに提示される視聴者情報の取り込み、置き換え、および削除により視聴者情報を操作する。ビジネス・エージェント２２６は、デフォルト値を定め、ユーザ情報へのアクセスを制御する。ビジネス・エージェント２２６はさらに、取り引きロギング、メッセージ・ロギング、負荷／取り引き監視を実行する。アカウントでは、小売業者またはサービス・プロバイダではなくＮＯが受信契約者および視聴者との直接的関係を持つことができる。クライアントは、クライアントがサインオンしたときにＳＰＳサービス・ゲートウェイにより生成されたセッション識別子により提供されるサービスに対して識別される。サービス・プロバイダがハードウェア・デバイスを識別し、ユーザと直接接触するのに使用できてしまうクライアント・ハードウェア識別子は、サービス・プロバイダに公開されない。クライアント・ハードウェア識別子はクライアント・デバイスのネイティブ・トランスポート・レベルから取り出され、テーブルに格納され、ＳＰＳとクライアント・ハードウェア識別子との間の取り引き実行時に利用されるセッション識別子の間の相互参照に使用される。視聴者または受信契約者がＮＯに登録され、そのアカウント情報がＮＯによって制御されているＯｐｅｎ ＴＶ Ａｃｃｏｕｎｔデータベースに格納される。視聴者は、自分のアカウント情報を見せずにＳＰＳ上で利用可能な小売サービスまたはサービス・プロバイダにアクセスすることができるが、それは、ＮＯがすでに、アカウント情報をＳＰＳに格納しており、すべての必要な情報を簡単に取り引きに挿入できるからである。しかし、小売業者は、特定の情報へのアクセスを許可するＮＯとのビジネス契約を通じてクライアント情報を取得することしかできない。

インタラクティブ・テレビを使用して実行される商取引は、ここでは、テレビジョン・コマースまたはＴ−コマースと呼ぶ。たとえば、アカウントの好ましい実施形態の下で処理されるＴ−コマース取り引きは、１）クライアント・デバイス・ユーザが上述の氏名、住所、および電子財布情報を提示してアカウントに登録される。クライアントはさらに認証のため後で使用するユーザ名およびＰＩＮを選択し、２）認証時にハードウェア識別子も使用でき、３）クライアントは製品をショッピング・カートに追加することによりＴ−コマース・アプリケーションまたはサービス・プロバイダとやり取りする。クライアントは、自分のユーザ名およびＰＩＮを入力してチェックアウトし、４）Ｔ−コマース・アプリケーションは本発明のアカウント機能に接続する。アカウントは、クライアント識別子とユーザ名を使用してそのデータベース内の視聴者を一意に識別する。ＰＩＮは、視聴者を認証するために使用され、５）Ｔ−コマース・アプリケーションはアカウントを通じてショッピング・カート情報をサービス・プロバイダの小売業者に送信する。アカウントはクライアント情報を取り引き内に挿入して小売業者またはサービス・プロバイダがクライアントを識別し、クレジット・カード番号および出荷先住所などの重要なクライアント情報を受信するようにでき、６）Ｔ−コマース小売業者またはサービス・プロバイダは注文を受け取り、出荷および取り扱い費用、税金、全費用の計算を実行し、その結果をクライアントに送り返し、７）クライアントは費用情報を検討して、注文を確認し、小売業者は確認番号をクライアントに送り返し、８）すべての取り引きについて、アカウントが取り引きＩＤを挿入して、同じ取り引きセッションに属するすべてのメッセージを追跡し、９）アカウントはさらに、顧客サービスおよびデータ・マイニングに関してＮＯを支援する異なる種類のロギング機能を備え、１０）さらに、小売業者またはＴ−コマース・アプリケーションのいずれかにより注文説明および注文費用などのＥレシート情報を送信する必要があり、アカウントは今後の顧客問い合わせおよび取り引き記録に関してＥレシート・レコードを提供する。

キーワードにより、Ｅコマースまたはその他の種類の取り引き実行時にデータ交換が行いやすくなる。取り引きは、これらのキーワードの受け渡しおよびキーワードに対するアクションにより完了する。キーワードは、データをデータ・リポジトリに書き込む機能、データをロギングする機能、キーワードとそのデータ・パラメータまたは値とを入れ替える機能、キーワードに対応する値を作成する機能、データ・リポジトリのコンテンツを削除する機能、キーワードにその実際の値をパッチする機能などさまざまな機能を実行する。キーワードがデータ・リポジトリからの対応する値に合わせて置き換えられるときにパッチが行われる。キーワードにより、クライアントの認証および識別、データベースの更新、取り引きのログ記録、セッションの追跡、およびエラー・メッセージの送信が行える。

たとえば、一般化されたキーワードは、＿Ｏ＿＜ｋｅｙｗｏｒｄ＿ｎａｍｅ＞（ｐａｒａｍ１，ｐａｒａｍ２，．．．ｐａｒａｍＮ）の形式であり、ｋｅｙｗｏｒｄ＿ｎａｍｅでキーワードの機能を指定し、キーワード名の最後の文字は英字Ｐ、Ｒ、Ｓ、Ｃ、Ｗ、またはＤのうちの１つであり、対応するアクションであるパッチ、除去、入れ替え、作成、書き込み、または削除を表す。ｐａｒａｍは、テキスト・コンテンツであるか、またはリスト内の順序値を表す数値である。ｐａｒａｍを空白値にすると、第１の、またはデフォルトの値となる。たとえば、キーワード＿Ｏ＿ｖＢｌｎＰ（）を使用すると、購入に対して請求された人のラストネームのパッチを要求する。このキーワードを受け取った後、たとえば、アカウントは、ＭｙＳｈｏｐ＿ＢｉｌｌｔｏＬａｓｔＮａｍｅ＝＿０＿ｖＢｌｎＰ（）にパッチをあて、ＭｙＳｈｏｐ＿ＢｉｌｌｔｏＬａｓｔＮａｍｅ＝Ｓｍｉｔｈとするが、Ｓｍｉｔｈはデータ・リポジトリ内のクライアント・プロファイルの請求ラストネームのリスト内の最初の名前である。購入項目に関係するキーワードは、Ｅレシートに対して使用されるタグを含む。タグの例として、注文費用、注文通貨、注文説明、注文ステータス、および注文ステータスＵＲＬがある。

本発明は、アカウント・トランザクションのサーバサイド・キーワードを用意しており、視聴者住所録、電子財布キーワード、Ｅレシート・キーワード、Ｅレシート取り引きキーワード、およびエラー・キーワードおよびその他のＳＰＳ機能をサポートする。

視聴者住所録機能を使用すると、視聴者は自分の友人の名前および住所をＯｐｅｎ ＴＶ Ａｃｃｏｕｎｔデータ・リポジトリに登録することができる。許可されているアプリケーションは、Ｏｐｅｎ ＴＶ Ａｃｃｏｕｎｔの視聴者の住所録を調べて、その情報を取り引きのために使用することができる。たとえば、Ｔ−コマース・アプリケーションを使用すると、視聴者は自分の住所録から項目を１つ選んで、購入品目をこの住所に送ることができる。電子財布知能では、視聴者は複数のクレジット・カード番号とともに請求情報をＯｐｅｎ ＴＶ Ａｃｃｏｕｎｔデータ・リポジトリに格納することができる。取り引きの詳細を記録するためアカウントでＥレシート・キーワードが使用される。データは、後で顧客サービスおよび請求目的に使用される。

ＮＯは、キーワードをアカウントによって生成された一意的な取り引きＩＤに関連付け、すべての小売業者およびＳＰＳに知られているすべてのクライアント・デバイスにわたって一様に取り引きセッションを追跡する。アカウントで不正な許可コードなどのエラーが発生した場合、ＨＴＴＰ応答をクライアントに送信し、エラーが発生したことと対応するアクションを知らせる。アカウントは複数プラットフォーム・クライアントを同時に操作するので、実際のエラー応答はアカウント内に設定されているパラメータであり、アカウントはエラー応答をＨＴＭＬ、ＸＭＬ、さらには名前−値の形式でクライアントに送信することができる。

取り引きは、ＨＴＭＬの名前−値のペアに基づいており、依存のインターネット・アプリケーション・サーバに簡単に組み込めるようＨＴＴＰを使用して発行される。ＨＴＴＰは、埋め込まれているＨＴＴＰ通信スタックを使用するか、またはサービス・ゲートウェイとクライアント・デバイス互換トランスポート通信プロトコルＤＡＴＰを介してセットトップ・ボックスから直接使用される。

一連の取り引きガジェットを含む取り引きガジェット・キットが用意されている。ガジェットとは、ＳＰＳ上で実行される機能または方法である。一組のガジェットが用意されており、サービス・プロバイダ、クライアント、およびＮＯによって追加ガジェットを作成し、指定することができる。たとえば、テーブル・ガジェットは、一組の名前付き列を格納する一連のレコード（または行）と見なされる矩形テーブルのメモリ内格納および管理機能を備える。テーブル・ガジェットは、テーブル提示ガジェットとともに機能する。テーブル提示ガジェットは、テーブル・ガジェット・コンテンツの列と行の部分集合の提示に割り当てられている。テーブルの交換は、名前が列名と一致する一組のスマート変数を介して一度に１レコードずつ実行される。リンクされているテーブル提示ガジェットの更新は、テーブル・コンテンツが更新されると必ず自動的にトリガされる。テーブル全体のスマート変数へのロード／保存を一度に行うこともサポートされている。

ＳｍａｒｔＶａｒｉａｂｌｅガジェットを使用して、スマート変数にアクセスできる。スマート変数を使用すると、ＳＰＳアプリケーションは値を格納できるが、それらの値に基づいて機能をトリガすることもできる。たとえば、スマート変数は、購入を行うときに視聴者が指定した数量を保持することができる。この値には、取り引き注文の作成時にアクセスできるが、数量の画面表示を更新する場合にも使用される。スマート変数は、数値とテキスト値を保持することができる。数値は、整数、浮動小数点数、および数式である。ＳｍａｒｔＬｉｓｔｅｎｅｒガジェットは、一組のスマート変数の更新を監視する。スマート変数の１つが変化すると、ハンドラがトリガされる。ＨＴＴＰＲｅｑｕｅｓｔガジェットは、ＨＴＴＰ要求をフォーマットし、リモートＨＴＴＰサーバに送信する機能を備えている。これは、ＥＮ２ ＨＴＴＰ拡張またはＤＡＴＰを使用するサービス・ゲートウェイを介して行う。ＱｕｅｒｙＳｔｒｉｎｇガジェットはＵＲＬエンコード・クエリ文字列（名前−値のペア）をフォーマットして構文解析する。クエリ文字列のコンテンツは、一組のスマート変数にフォーマットするかまたは一組のスマート変数から展開することができる。

ＳｍａｒｔＥｖａｌガジェットは、スマート変数オペランドの１つが変化すると必ず演算式を再評価する。ＳｍａｒｔＣｏｍｐａｒｅガジェットは、スマート変数を監視し、変化すると、その値を定数値と比較する。比較の結果に応じて２つのハンドラのうちの一方が呼び出される。比較は、より大きい、より小さい、等しい、等しくないなどである。ハンドラは、比較結果が真か偽かに基づいて呼び出される。ＰＩＮＣｈｅｃｋｅｒガジェットは、条件付きアクセス（ＣＡ）ＰＩＮチェックのインターフェイスを備える。好ましい実施形態では、これは、埋め込みＣＡ親制御ＰＩＮに組み込まれる。チェックの結果はスマート変数に入れられる。ＣｒｅｄｉｔＣａｒｄＣｈｅｃｋｅｒは、セットトップ・ボックス内でクレジット・カード情報のチェックを実行する。チェックの結果はスマート変数に入れられる。

ＴｅｘｔＩｎｐｕｔガジェットは、セットトップ・ボックスのリモート・コントロールまたは赤外線キーボードからテキストを入力する機能をサポートしている。入力はスマート変数に入れられる。動的テキスト・ガジェットは、スマート変数の値の動的字幕追跡を行う。このガジェットは、セットトップ・ボックス内に表示されるテキストの動的更新を行う。ＳｍａｒｔＬａｎｇｕａｇｅガジェットは、アプリケーションで使用すべき言語を決定するためのインターフェイスを備える。

ＤＡＴＰガジェットは、ＤＡＴＰを使用するサービス・ゲートウェイへのアクセスをサポートするライブラリである。ＤＡＴＰＬｉｎｋガジェットは、サービス・ゲートウェイのＤＡＴＰライブラリへのリンクである。接続の状態はスマート変数に保持されている。

ＳｔａｔｉｏｎＣｏｎｔｒｏｌガジェットは、ビデオおよびオーディオ・ストリームの制御および新しいサービスへの切り替えの機能をサポートする。ＳｈａｐｅＡｎｉｍガジェットは、基本的な形状およびビットマップのアニメーション機能を備える。

購入取り引きは、クライアントが購入のためｃｏｏｋｉｅおよびキーワードと関連するセッション識別子を含むメッセージをサーバに送信したときに始まる。ＳＰＳは、セッション識別子およびｃｏｏｋｉｅをセッションＩＤテーブルに関連付ける。セットトップ・ボックス・アプリケーションにより注文メッセージがコンテンツ・プロバイダに送信されると、ＳＰＳがそのメッセージをインターセプトし、注文パラメータ内のプレースホルダを置き換えることにより視聴者詳細をメッセージにパッチし（つまり、クレジット・カード番号を記載する）、注文明細をログに記録し、そのメッセージをコンテンツ・プロバイダ・アプリケーション・サーバに転送する。アプリケーション・サーバは注文を処理して、確認をセットトップ・ボックスに返す。ＳＰＳは応答をインターセプトし、注文ログを更新して確認を反映させ、セットトップ・ボックスに転送する。実際、このタイプの商取引はより複雑になる可能性があり、セットトップ・ボックス・アプリケーションとアプリケーション・サーバとの間でやり取りされるメッセージが増える。ＳＰＳは、複数の交換で注文の状態を監視できる。セットトップ・ボックス・アプリケーションは、ＳＰＳ電子財布からの決済カード明細などの情報をサービス・プラットフォーム・マネージャから直接取り出すことができる。

オプションとして、クライアントはサービス・プロバイダから直接購入することもできる。ただし、アカウント・サーバを通じて購入する場合は、クライアントは購入時に最低限の情報を提供するだけでよく、ＳＴＢがシングル・ユーザ・モードで動作している場合には、視聴者はすでにログオンしており、自分を識別させる必要はない。マルチユーザ・モードでは（視聴者が多数いる家族などで）、視聴者はシステムにログオンして、自分を正しく識別させる必要がある。本発明ではキーワードを使用しているため取り引きが高速化され、クライアントの観点とサービス・プロバイダの観点から取り引きをトランスペアレントにすることができ、視聴者は、たとえば、クレジット・カード情報を取得するため、あるいはたとえば、Ｍｉｃｒｏｓｏｆｔ Ｐａｓｓｐｏｒｔで購入することに決めるため他のサイトにアクセスする必要がない。このクライアント情報は、キーワードによってトランスペアレントに提供される、つまり、ユーザはこのやり取りに気づかない。

アカウントの高水準の図が図９に示されている。アカウントは、インタラクティブ・サービス・マネージャ（ＩＳＭ）（９０１）、プロキシ・コンポーネント（９０３）、パーサ（９０５）、ビジネス・エージェント（９０７）、およびリレーショナル・データベース、ＬＤＡＰ、Ａｃｔｉｖｅｒ Ｄｉｒｅｃｔｏｒｙなどの１つまたは複数のデータ・リポジトリ（９０９）の５つの主要コンポーネントを備える。ＩＳＭを使用すると、ＮＯは複数の作業を実行できる。ＮＯは、各インタラクティブ・サービス・プロバイダのクライアント・データにアクセスできるレベルを設定できる。第２に、ＮＯは、サービスごとにクライアント・データのパッチのレベルを設定し、パッチ・タイプの請求、またはパッチ履歴のレビューによる請求を行うことができる。第３に、ＮＯは、サービスごとにＥレシートを捕捉し、Ｅレシート請求機能を有効にすることができる。第４に、ＮＯは、サービスごとにロギングのレベルを設定し、クライアント・データを顧客関係に利用することができる。第５に、ＮＯはさらに、サービスごとにストアアンドフォワード・メッセージ送受信の非同期要件を設定することもできる。第６に、ＮＯは、サービスごとに認証要件を設定することができる。

アカウントは、取り引き管理目的と、拡張機能で課金構成を有効にするためのさまざまな種類のロギング機能を備える。Ｅレシート・ロギングおよびバッチ・ロギングなどの追加ロギング・タイプでは、ＮＯはサービス・プロバイダに課金するオプションが用意される。メッセージに表示され、取り引きの結果（たとえば、テレビの購入）に応じてサービス・プロバイダに課金することが可能になれば必ず、Ｅレシート・ロギングは、タグ（つまり、注文説明）などの取り引き変数を記録する。パッチ・ロギングでは、アカウントがサービス・プロバイダごとに各パッチングの出現を記録し、そのサービスに対して実行されたパッチの種類および数に応じてサービス・プロバイダに請求する操作を有効にする。

非同期メッセージ送受信機能（ストアアンドフォワードなど）により、同期応答（たとえば、データベースへのロギング）を必要としないタスクを非同期に実行して、ピーク・メッセージ転送負荷を低くすることができる。このようにする際に、非同期メッセージ送受信を行うことにより、取り引きメッセージを後で送信できるように格納しておき、メッセージ処理時間を短縮することができる。

ビジネス・エージェントは、データ・アクセス・コンポーネント（ＤＡＣ）とビジネス・ロジック２つの独立のコンポーネントに分けられる。ビジネス・ロジックでは、特定のビジネス要件を処理する、つまり、クライアント・レコードの処理を行い、ＤＡＣはデータ・リポジトリへのアクセス専用となっている。また、柔軟性の高いビジネス・エージェント・アーキテクチャであるため、外部ビジネス・エージェントを容易に追加できる。たとえば、ＮＯは、タグとキーワードを作成して提供し、ビジネス・エージェントにそれらのタグおよびキーワードを処理させることが簡単にできる。

アカウントの機能について高水準の説明を行う。プロキシ・コンポーネント（９０３）は、クライアントからＨＴＴＰ要求を受け取る。この要求には、取り引きのｃｏｏｋｉｅとキーワードが含まれる。要求ごとに、プロキシ・コンポーネントは、要求をバッファ・オブジェクトにパッケージし、ＩＳＭに渡す。ＩＳＭでは、まず、資格マネージャ（ＥＭ）（９１０）を呼び出して、送信元および送信先の許可を確認する。次に、ＩＳＭは、メッセージのヘッダｃｏｏｋｉｅ／セッション識別子内のＯＴＶＦｌａｇフィールドから要求が同期か非同期かを判別する。要求が同期であれば、ＩＳＭはその要求をパーサ（９０５）に直接送信する。要求が非同期であれば、ＩＳＭは非同期処理を行えるようにその要求をＭＳキュー・コンポーネント（ＱＣ）（９１３）に入れ、あらかじめ生成されている応答クライアントに送り返す。そこで、パーサは、同期呼び出しまたはキュー・コンポーネント・プレーヤーを通じて要求を受け取る。パーサは、さらに、許可されているタグを含むテーブルと、それらのタグを処理できる「ビジネス・エージェント」ＣＯＭオブジェクトを受け取る。ＩＳＭがそれらのタグのうちの１つを見つけると、適切な「ビジネス・エージェント」ＣＯＭオブジェクトを呼び出して、実際の機能を実行する。ログ・ライター（９２１）、Ｅレシート・ライター（９２２）、パッチ・ライター（９２３）、視聴者プロファイラ（９２４）、およびエラー・ハンドラなどの重要な機能を実行する組み込み「ビジネス・エージェント」が多数ある。外部ビジネス・エージェント（９２５）を追加するには、自分自身とＩＳＭで処理できる新しい「タグ」を登録する。それぞれのビジネス・エージェントは、対応するデータ・アクセス・コンポーネント（ＤＡＣ）を呼び出して、適切なデータ・ソースと交信させる。

プロキシ・コンポーネントは、ＩＩＳフィルタおよびＩＩＳ拡張の２つの部分として実装される。ＩＩＳフィルタは、クライアントからプロキシに要求が発行されるときに必ず呼び出される。その後、ＵＲＬがＩＩＳフィルタによりパッチされ、ＩＩＳ拡張が呼び出される。ＩＩＳ拡張により、要求は、再作成されて、バッファ内に格納され、バッファがＣＯＭインターフェイスにパッケージされ、そのインターフェイスを実装するＩＳＭに渡される。

ＩＳＭはアクティブなすべてのアプリケーションのリストにアクセスする。また、ＳＰＳサービス、さらにデフォルトのロギング・レベルおよびＥレシート・ロギング・レベルへの受信契約を禁止されている受信契約者のブラック・リストにアクセスすることもできる。ＳＰＳに登録されているサービスごとに、ＩＳＭは、サービスＩＤ、ステータス（アクティブまたは非アクティブ）、サービス・プロバイダと関連するドメイン名のリスト、サービス・プロバイダと関連する許可されているキーワード、サービス・プロバイダと関連するデフォルトの言語、請求要件（請求またはＥレシートのパッチ実行）、およびロギング・レベルなどのサービス固有のデータを提供する。

ＩＳＭは、ＥＭ（９１０）、非同期決定コンポーネント（９１２）、およびレジストリ・コンポーネント（９１４）を含む。ＥＭ（９１０）は、要求／応答を処理する第１のコンポーネントである。資格マネージャは、送信元にメッセージを送信する資格があるかどうか、送信先にメッセージを受信する資格があるかどうかを判別する門番のような機能を果たす。メッセージの受理または拒絶を決めるのに使用する情報は、すべてのアクティブなサービスのリスト、各サービスに関連する重要情報（つまり、ステータス、ドメイン名、許可されているキーワードなど）、および受信契約者のブラック・リストである。

ＩＳＭの非同期決定コンポーネント（ＡＤＣ）（９１２）は、受信したＨＴＴＰ要求のセッション識別子／ｃｏｏｋｉｅヘッダ内のＯＴＶＦｌａｇフィールドそのステータスに基づき、その要求がキューに入れられているかどうかを判別する。要求が同期であれば、ＡＤＣはパーサを直接呼び出す。要求が非同期であれば、要求をＭＳキュー・コンポーネント（ＱＣ）に入れ、要求をＱＣに入れようとして成功したか失敗したかを通知する応答をクライアントに返す。

レジストリ・コンポーネントは、ビジネス・エージェントが自動的にＩＳＭに登録できるようにする採用登録方式を備える。登録情報には、ビジネス・エージェントの名前およびそのＰｒｏｇＩＤ名と、ビジネス・エージェントが処理できるキーワードが含まれる。好ましい実施形態では、ビジネス・エージェントの実装は、まず、ＩＳＭの初期化段階で、ビジネス・エージェント側がビジネス・エージェントのＣＯＭオブジェクトのそれぞれのインスタンスを作成する必要がある。この作成段階で、ＩＳＭは各ビジネス・エージェントが処理できるキーワード群を問い合わせることができる。ＩＳＭは次に、その情報をテーブルに格納し、パーサに渡す。

パーサ（９０５）は、メッセージを解析し修正する中心的コンポーネントである。パーサはＩＳＭから、１組の許可されているキーワードと、キーワードごとに、キーワードを処理できるビジネス・エージェントＣＯＭオブジェクト、ログ・ライターおよびＥレシート・ライターのロギング・レベルの情報を受け取る。パーサは、キーワードのメッセージを構文解析し、対応するビジネス・エージェントを呼び出して、そのキーワードを処理する。上述のように、パーサは同期機能呼び出し、またはＱＣプレーヤーを介した非同期メッセージを通じて同期メッセージを受信する。パーサは、メッセージの処理を開始すると、メッセージを同期して受信したかのように取り扱い、すべてのアクションを一度に実行する。非同期メッセージについては、パーサはまず、キーワードのメッセージを処理し、その後、プロキシに戻ることなくＨＴＴＰを通じてメッセージをＵＲＬに送信するが、それは、プロキシ内の元の接続がクライアントへのあらかじめ生成された応答により閉じているからである。したがって、パーサはプロキシに依存せずにメッセージを送信する。

それぞれのビジネス・エージェントは、特定のビジネス機能を処理する個別コンポーネントである。Ｏｐｅｎ ＴＶ Ａｃｃｏｕｎｔは、ロギング、視聴者プロファイリング、エラー処理などの機能を実行する１組の組み込みビジネス・エージェントを備える。ＮＯは、特定のメッセージ・キーワードおよび定義されている対応するビジネス機能を処理する外部ビジネス・エージェントをプラグインすることができる。

各ビジネス・エージェントは、ビジネス・ロジックとデータ・アクセス・コンポーネント（ＤＡＣ）２つの独立のコンポーネントに分けられる。ＤＡＣは、ビジネス・エージェントの内部にあるコンポーネントであり、ビジネス・エージェントに代わって、データをデータ・リポジトリに書き込んだり、そこから取り出したりする。データ・アクセス部分を専用のＤＡＣに分離するという概念を採用したことで、アカウントはさまざまなスキーマおよびさまざまな数および種類のデータ・リポジトリで働くように簡単に適応できる。アカウントには２つのＤＡＣがある。１つはＩＳＭ ＤＡＣ（９３１）で、もう１つは視聴者プロファイラＤＡＣ（９３２）である。ＩＳＭ ＤＡＣは、ＩＳＭおよび視聴者プロファイラを除くすべてのビジネス・エージェントとのインターフェイスを受け持つ。視聴者ＤＡＣは、視聴者プロファイラＢＡのみとのインターフェイスを受け持つ。独立したＤＡＣが公開されている視聴者ＤＡＣ ＡＰＩに対応するので、ＬＤＡＰなどの異なる視聴者データ・リポジトリで作動させるために異なる視聴者プロファイラＤＡＣを簡単に入れ替えることができる。

ログ・ライター・コンポーネントは、４つのレベルのロギングをサポートしており、ＩＳＭで設定されているレベルに応じてログを記録する。ＳＰＳによって設定できるグローバル・ロギング・レベルもあるが、サービス・レベル・ロギングがグローバル・ロギング・レベルに優先する。ログ・ライターは、ＭＳ ＱＣを使用して非同期に実行されるため、データベースへの書き込み待機時間を短縮することができる。ロギングがあまり早く実行されないように注意する必要がある。たとえば、ロギングが実行される前に取り引きＩＤを生成しなければならない。

Ｅレシート・ライター・コンポーネントは、クライアント注文タグをデータベースに記録する役目を持つ。これらの注文タグは、サービスとクライアントの両方のＥレシート（注文要約）として使用される。ＮＯは、この情報を使用して、Ｅレシートに記録されている金額に応じてサービスの課金を行い、受信契約者からの注文問い合わせに答える顧客サービス・サポートを実施し、それぞれの受信契約者の注文履歴を作成する。好ましい実施形態では、Ｅレシート・ライターは、ＭＳ ＱＣを使用して実行され、待機時間が短縮される。

パッチ・ライターは、たとえば、クレジット・カード番号を取り引きメッセージにパッチするときに、メッセージごとに実行されるパッチをロギングする役目を持つ。パッチ・ライターを使用すると、ＮＯはそのサービスについて実施されたパッチの量と種類に応じてサービスに課金することができる。パッチ・ライターへの入力は、ｃｏｏｋｉｅ情報とともにパッチされたすべてのタグである。好ましい実施形態では、これは、ＭＳ ＱＣを非同期コンポーネントとして使用して実行される。

エラー・ライターは、エラー状況をデータベースに記録する役割を持つ。エラーは、送信元または送信先資格失敗、視聴者認証失敗、許可されていないタグがあった場合の要求パッチ、およびＨＴＴＰエラーのうちの少なくとも１つである。好ましい実施形態では、エラー・ライターは、ＭＳ ＱＣを非同期コンポーネントとして使用して実行される。

視聴者プロファイラは、取り引き変数に基づく視聴者アドレス情報、視聴者電子財布情報、視聴者連絡先リスト情報、および視聴者注文履歴を含む視聴者プロファイル情報を読み書きする役割を持つ。メッセージ処理のはじめに、視聴者プロファイラが視聴者レコードをそのキャッシュに読み込む。処理が終わると、視聴者プロファイルはキャッシュを解放する。

ビジネス・エージェントは、メッセージからメッセージへの状態情報を保持しない。ビジネス・エージェントは、すべてステートレス・コンポーネントであり、メッセージのはじめにメッセージ・パラメータにより初期化するのが好ましい。

Ｏｐｅｎ ＴＶ Ａｃｃｏｕｎｔは、ＮＯが自分のタグを追加し、対応するビジネス・エージェントがそのビジネス機能に対してＮＯ側で使用できるキーワードを処理できるように設計されている。たとえば、ＮＯは、テレビ・コマーシャルによる広告から生じる取り引きに特別なキーワードを含めるよう要求する場合がある。アカウントに差し込むために、外部ビジネス・エージェントは自分自身をＩＳＭに登録しなければならない。登録するには、ビジネス・エージェントＣＯＭ（ＰｒｏｇＩＤ）をＩＳＭ ＣＯＭオブジェクトのレジストリに追加する必要がある。ＩＳＭは、初期化されると、インターフェイスを必要とするビジネス・エージェントＣＯＭオブジェクトそれぞれのインスタンスを作成する。次に、それぞれのビジネス・エージェントＣＯＭオブジェクトで、そのＣＯＭオブジェクトがどのようなキーワードを処理できるかを問い合わせ、キーワードとビジネス・エージェントＣＯＭとの間のマッピングをテーブル（キーワード処理テーブル）に格納する。ＩＳＭは、メッセージ、サービスの許可されたタグ、およびキーワード処理テーブルをパーサに渡す。パーサが、キーワードに出合うと、キーワード処理テーブルに従って、対応するビジネス・エージェントＣＯＭオブジェクトを呼び出す。さらに、複数のビジネス・エージェントＣＯＭオブジェクトでキーワードを処理することができ、オブジェクトは、ビジネス・エージェントがＩＳＭレジストリに登録されている順序で呼び出される。

アカウントを用いると、ＮＯは受信契約者の情報を厳しく管理することにより受信契約者１人当たりの収益を増やし、各種のログを記録して個々のサービスおよび顧客関係管理に対するさまざまな種類の請求を利用することができる。これらのログは、さらにデータ・マイニングにも使用できる。

広告マネージャ（ＡＭ）を使用すると、ＮＯは視聴者に配信する広告のコンテンツおよびスケジュールを管理することができる。ＡＭはマッチメーカー・コンポーネントを提供し、これによりネットワーク・オペレータは異なるサービスからの異なる広告をターゲットとする広告キャンペーン規則を設定することができる。また、ＡＭは、異なるプロファイルを持つユーザをターゲットとする。ＡＭは、広告に対するユーザの応答を追跡し、レポートを作成し、レポートに基づいて新しいキャンペーン規則を作成する。そこで、ＳＰＳは、クライアント／ユーザ応答からのフィードバック、時刻、利用可能なプログラミン、利用可能な広告、利用可能な広告スペース、視聴者好みおよびプロファイルに基づいて適応型広告作成を行うことができる。ＡＭは、放送とポイントツーポイント・リンクの両方とのインターフェイスを備え、２つの配信チャネル間の相補的広告相互作用を使用できるようにする。たとえば、放送（プッシュ）広告では、ＳＰＳを介して広告サービスへのポイントツーポイント接続がトリガされ、ユーザは製品を購入したり、製品に関係する詳細な情報を取得したりすることができる。また、放送広告をポイントツーポイント・コンテンツに入れて、放送サービスを利用できることをユーザに知らせることもできる（たとえば、インフォマーシャル）。

ＡＭを使用すると、ＮＯは広告インベントリと広告資産の管理を行うことができる。インベントリは、静止画像（ｂｍｐ、ｊｐｅｇ、またはｍｐｅｇ）、アニメーション、音声、およびリンクなど一組の標準サイズと標準媒体タイプに制限される。またＡＭはインプレッション追跡も実行するが、インプレッション追跡はネットワーク・インフラストラクチャに応じて、サンプリング、または推定のいずれかであり、インプレッション詳細を取得するには、ＳＴＢポーリングまたはピギーバックを使用する。ＡＭは、ＳＴＢキャプチャ、ストアアンドフォワード、サーバ処理、および格納と報告作成を実行する。インプレッション追跡、ポーリングおよび表示カウントは、適応型広告におけるフィードバックとみなされる。

ＡＭはユーザ・クリック追跡を実行し、さらに、サイズ、コンテンツ、カテゴリ、および自動サイズ検査／検出およびサービス、時刻、曜日、および広告期間などの使用制限を含むセルフ・サービス広告掲示／広告販売を実行する。ＡＭは自動／セルフ・サービス広告スポット／スペース定義、サービスおよび種類別、およびカテゴリ別のページ・タグ付けを実行する。ＡＭは、ＳＴＢベースの組合せ決定、サーバ・ベース／放送組合せ決定、および時間感知広告提供／マッチング、電波中継局特定およびサービスに対するほとんどのポイントツーポイントまたは放送による広告のリダイレクトを実行する。

ＡＭは、オンライン・コンテンツへの放送広告提供を実行し、サービス・マネージャへのリンクによりマイクロサイトのスケジューリングを制御する。サービス・マネージャ、Ｈ２Ｏ、カルーセル・マネージャ、およびオープン・ストリーマーを使用してＳＰＳにより放送カルーセルを生成する。カルーセルの生成は、サービス・マネージャ・データベース内のサービス規則、業者によってトリガされた製品更新、およびイベント・スケジューラにより誘導される。視聴者プロファイルおよびカテゴリを使用して、視聴者／クライアントに提示する製品および広告を選択する。場合によっては、複数の製品または広告セグメント（アド）を視聴者またはクライアントに放送し（プッシュ、つまり視聴者から要求がなくても送信する）、ＳＴＢまたはクライアントに放送する。視聴者に関連するビジネス・フィルタはスマートＳＴＢ（たとえば、Ｍｏｔｏｒｏｌａ ＤＣＴ ５０００）に置かれるのが好ましいが、これを使用して、視聴者にぴったりの広告を選択する。たとえば、ＳＰＳは、料理番組のときに視聴者に放送する料理広告のグループをスケジュールすることができる。この広告グループには、イタリア料理、フランス料理、インド料理、およびドイツ料理に料理広告が含まれる。ＳＴＢまたはクライアントと関連するまたは配置されているビジネス・フィルタにより、クライアントまたは視聴者に提示する料理広告の種類を選択する。ある視聴者はフランス料理広告を見ており、別の視聴者はインド料理広告を見る。

広告キャンペーン管理では、視聴者データ・マイニングおよび分析システムを使用して、製品、広告、および放送のタイミングの最良の選択を提案することができる。ＳＰＳは、規則ベースのシステムを備え、「スマート」広告キャンペーンを作成する。これらのキャンペーンは、ユーザの好み、プロファイル、購入および表示習慣、および人口統計調査に基づく適応型である。ＡＭは、広告コンテンツ・データベース、キャンペーン規則データベース、サービス・マネージャ、およびカルーセル・マネージャから得られる情報に基づき、視聴者に掲示する最良の製品を決定する。これは、カルーセル・マネージャが放送カタログを再構築するのをトリガする。ＡＭはさらに、ビジネス・エージェントとインターフェイスし、視聴者がオンラインになっている間、視聴者に提示する広告コンテンツを提案する。

本発明は、ユーザの基本的プロファイル、商品の種類、およびコンテキスト（ページ、時刻）に応じて正しい製品を提示するターゲット決定技術を実現する。本発明はさらに、前の注文／要求を分析して視聴者が何に興味あるかを推測する「予測」技術も実現する。これらの技術では、統計学とルール・ベース・システムを組み合わせたものを使用して、知的な「推測」を行う。

ＳＰＳでは、Ｗｅｂ商取引インフラストラクチャを再利用することができる。ＳＰＳは、「通常の」ＨＴＭＬテンプレートをＴＶ対応形式で置き換える。ビジネス・エージェントは、サービス・ゲートウェイを通じてＳＴＢまたはクライアントから注文要求を受け取る。サービス・ゲートウェイがメッセージをキューに入れると（ピークの管理のため）、一部の注文が遅延を伴ってビジネス・エージェントに届くことがある（どのような形式の確認も必要としない注文であればこの方式を使用するのが好ましい）。ビジネス・エージェントは、視聴者情報を注文に追加する。注文／メッセージに記載されている視聴者情報の量と種類は、サービス／小売契約に応じてビジネス規則により決められる。通信はサービスと視聴者／クライアントとの間の交換なので、この情報はトランスポート・ストリームごとにカルーセルが単一として別々のカルーセルに送信されるか、または既存のアプリケーション・カルーセルにまとめられる。

その後、注文処理が進行するが、必要に応じて、ＳＰＳに備えられている「クレジット・カード精算」機能を使用することができる。確認が小売業者から送り返されると、注文がリアルタイムでユーザに送り返されるか、電子メールでユーザに送信されるか、または何らかの形式の顧客重視アプリケーションを通じてオンデマンドで入手できるようにされる。

ＳＰＳは、オフライン視聴者識別を実行し、これにより、オンライン視聴者接続を確立しなくても視聴者を識別または認証することができる。したがって、接続遅延（たとえば、１０〜４０秒）を購入プロセス内の最も適切な場所に設定することができる。さらに、ストアアンドフォワードの状況で視聴者の識別も行える。この機能により、ＳＴＢまたはオンとオフを間欠的に繰り返すその他のクライアント・デバイスで注文／オペレーションの通信および完了を行える。

オフライン注文フォーム機能では、ＳＰＳはＴコマース・サービスを提供し、視聴者はこれを利用して、オンラインでなくても、品目を注文フォーム（ショッピング・カート）に追加することができる。ストアアンドフォワード機能は、拡張性を高める場合に重要である。ストアアンドフォワードは、ピーク外の時間に転送するか、または単純に、取り引きが開始した後所定の期間に負荷を散らす。完全ストアアンドフォワード・ソリューションが、「ナビゲータ」、ＥＰＧ、または制御タスクに組み込まれており、いつでも任意のチャネルから応答を転送することができる。ストアアンドフォワードは、機能強化されたＥコマース、Ｔコマース取り引きに使用できる。オフライン視聴者認証により、オフライン支払い選択を実行できる。オフライン支払い選択がサービス・プラットフォーム・スイートに用意されており、購入プロセスを改善し、ストアアンドフォワード機能をＴコマース／Ｅコマースとともに使用できるようになっている。

広告ツールはすべてのＳＰＳアプリケーションをトラバースする。ＳＰＳアプリケーションはすべて、広告スペースとバナーを提供できる。ＡＭは、すべてのアプリケーションに対して中央登録ポイントを備え、すべてのアプリケーションの広告供給にアクセスできる。広告マネージャのオペレータの観点からは、ＡＭは関連する画像、およびサービス（アプリケーション、ＴＶチャンネル）、ミニサイトへのリンクで広告をスケジュールし、監査のため報告書を作成できる。

ＡＭを使用すると、広告主は特定の視聴者グループまたは番組に合わせて手直ししたキャンペーンを作成し、ＨＴＭＬツールを通じて結果を確認することができる。リポジトリ・コンポーネントにより、広告キャンペーン（規則、スケジュール、プロパティ、および資産）の保存／管理を行う。キャンペーン・マネージャは、送信するこれらの広告を用意する。キャンペーン・マネージャは、視聴者にいつどの報告を送信するかを決定するために、キャンペーンおよび報告書作成からのフィードバックと関連する規則を用意する。

「配信」コンポーネントは、オープン・ストリーマー放送またはポイントツーポイント通信リンクを使用してキャンペーン・マネージャによって選択された広告のキャンペーンを送信する。オープン・ストリーマーは、広告をＮ個のサービス・プラットフォーム・カルーセルとして、トランスポート・ストリームごとに１つずつパッケージし、帯域幅の使用を最適化する。ＳＴＢクライアント・アプリケーションは広告ライブラリとともに放送される。このライブラリは、キャンペーン獲得、組合せ決定、追跡、レポート作成の機能を実行する。キャンペーン獲得クライアント・コンポーネントは、クライアント・アプリケーションと並列に実行され、キャンペーン・カルーセルを監視し、情報をキャッシュし、資産を事前フェッチする。組合せ決定クライアント・コンポーネントは、ローカル・パラメータ（表示されるページの種類、ユーザ情報、キャンペーンを打った回数など）でそれぞれの広告キャンペーンを評価し、最良の広告にアクセスして表示する。

広告では、視聴者追跡機能（測定）および視聴者プロファイリング（ターゲット）をサポートし、実際のインプレッション、ＨＴＭＬサポート、日時別広告のターゲッティング、およびビデオ広告にぴったりのソリューションをサポートする拡張に基づいて、その後の広告の配信を調整する。

広告アーキテクチャの図を図６に示す。広告は、４層の放送プラットフォームにまたがって動作する。第１層はここでは、管理層（６００）と呼ばれ、Ｗｅｂアプリケーション・サーバ（６０２）を備える。Ｗｅｂアプリケーション・サーバ（６０２）は、さまざまな広告会社（広告代理店、Ｃｏｃａ−Ｃｏｌａ、Ｐ＆Ｇなど）の販売担当から受け取った情報を広告データベース（６０４）に格納する。すべてのユーザ（管理者、広告販売担当者、および広告営業スタッフなど）がセキュリティ保護されたセッションを介してＷｅｂ ＧＵＩアプリケーションを使ってシステムにアクセスする。Ｗｅｂアプリケーション・サーバは、媒体販売担当者用のＷｅｂベースのインターフェイスを用意しており、キャンペーン・プランニング・モジュール、在庫予測モジュール、広告カタログ・モジュール、レポート作成モジュール、請求書作成モジュール、販売サイクル管理モジュール、およびセキュリティ・モジュールを備える。キャンペーン・プランニング・モジュールは、特定のインタラクティブ・アプリケーションで広告バナーをターゲットとするようにキャンペーンを構成し管理する。在庫予測モジュールを使用すると、広告の利用可能な在庫、予想キャンペーン配信、スケジュール、および進捗状況のスナップショットを素早くかつ正確に示すことができる。広告カタログ・モジュールは、数千ものバナー広告を代理店および広告主の連絡先および名称とともに表示し、管理し、格納する。レポート作成モジュールでは、レポートを一般的なキャンペーン配信ステータスおよびパフォーマンス・レビューのためリアルタイムで生成できる。請求書作成モジュールは、既存の請求書作成システムに簡単に組み込むことができるので、ターンキー方式の組み込みが容易であり、既存のオペレータ・アーキテクチャへの中断も最小限で済む。販売サイクル管理モジュールを利用すると、オペレータ媒体販売担当者は在庫の表示、挿入注文の入力、および販売サイクルの短縮を行うことができる。セキュリティ・モジュールでは、システムのすべてのユーザ（広告主／代理店、広告事業者、トラフィックおよび請求書作成、広告販売など）に対してさまざまなレベルのセキュリティおよびアクセス権を設定するだけでなく、特定の許可権利も設定する。

第２層はここでは、スケジューリング層（６１０）と呼ばれ、電波中継局スケジューラ（ＨＥＳ）（６１２）、およびＩＴＶコンテンツ配信サーバ（６１４）を備える。ＨＥＳは、バナー広告のスケジュールを決めて、利用可能な広告スペース／帯域幅を満たし、キャンペーン規則に従いながらターゲット・アプリケーションから必要なインプレッションが得られるようにする。広告利用可能情報、特定の時間枠内で監視している受信契約者の数に関する情報、および販売された広告スポットはすべて、ＨＥＳ（６１２）に供給され、広告データベース（６０４）に格納されている高水準配信計画が作成される。次に何の広告を表示するか尋ねられると、ｉＴＶコンテンツ配信サーバ（６１４）のリアルタイム・サーバが広告データベース上の配信計画を読み込み、次に表示するアプリケーションの広告のリストを返す。広告は、広告優先度、広告重み、最短広告表示時間、充填論理値、スポット内セッション頻度上限、アプリケーション内セッション頻度上限、業界除外事項、全体的な頻度上限、最小回転間隔、広告スペック、広告タイプ、広告ターゲットなどの制約条件に基づいて選択される。優先度の高い広告は常にそれよりも低い優先度のものよりも前に表示され、広告重みを付けると、同じ優先度レベル内の広告が乱数と重みに基づくバイアスとに応じて表示される。たとえば、広告＃４の重みは０．９、広告＃５の重みは０．１とする。すると、スケジューラはその時間の９０％で＃５の前に＃４を指示し、その時間の１０％で＃４の前に＃５を指示する。

充填論理値を使用すると、広告は低い値として識別されるが、他の広告がキューに入っていないときに限り使用する。頻度上限により、広告表示回数が制限される。スポット内セッション頻度上限を指定すると、特定のスポット内に広告を表示できる回数が制限される。アプリケーション内セッション頻度上限を指定すると、現在のアプリケーションが実行されている間に広告を表示できる回数が制限される。全体的な頻度上限を指定すると、すべてのアプリケーションおよび特定のアプリケーションのすべての起動にまたがって広告を表示できる回数が制限される。アプリケーションによっては、ある種の広告を遮断する産業タイプのものもある。業界除外では、たとえば、Ｄｏｍｉｎｏのアプリケーションは自動車広告を表示し、ファーストフードの広告を表示できないようにできる。最短広告表示時間では、広告を表示しなければならない最短時間を設定する。最小回転間隔では、この広告が同じスポット内に再表示する資格を得る前に表示しなければならない最低限の広告を設定する。広告スペックと広告タイプは、アプリケーションのサイズおよび形式（ＭＰＥＧ、ｊｐｅｇなど）との広告の互換性と一致する。広告ターゲットは、たとえば、広告の人口統計と一致する。

第３層はここでは、放送層（６２０）と呼ばれ、広告挿入エンジン（６２２）を備える。広告挿入エンジンは、広告、たとえばバナー広告をｉＴＶコンテンツ配信サーバ（６１４）に要求し、広告を広告対応アプリケーションの放送ストリームに挿入する。広告は、ビデオまたはオーディオなどどのような形式のものでもよく、現在表示されている画像またはアクティブなオーディオ・トラックに挿入または置き換えることができる。広告は、広告挿入エンジン（６２２）からカルーセル・マネージャへ送信され、そこでクライアント、たとえばセットトップ・ボックスにより受信される必要な媒体（衛星、送信機、ケーブルなど）により放送される。その後広告が表示され、クライアントで確認される。広告は定期的に要求され、必要な頻度で回転が与えられる。広告配信コンポーネントは、広告サーバコンポーネントとは独立しており、将来のＨＴＭＬ準拠広告配信モジュールへの柔軟な移行が可能である。

そこで、広告サイクルのデータの流れについて説明する。管理層では、販売代理店が広告オペレーション・セクションＷｅｂインターフェイスを使用して広告、ターゲット・アプリケーション、日付範囲、および望むインプレッションの件数に関する情報を入力する。ターゲッティングの試行ごとに、電波中継局スケジューラ（６１２）がトリガされ、有効スペース対要求されたインプレッションの簡易シミュレーションを実行して、必要なインプレッションを実行できるかどうかを調べる。成功すると、一組のキャンペーン関連レコードが、ビジネス契約が確認されるまで予約状態として作成され、確認が取れるとステータスはアクティブ状態に変更される。広告主のパーソナル・コンピュータからコンテンツ・サーバへ添付ファイルをアップロードする。スケジューラが定期的に実行され、優先度と重みを広告に割り当てる。スケジューラは、一組の最適化の高い極端に複雑なスケジューリング・アルゴリズムを実行し、広告キャンペーンの正確かつ円滑な配信をできる限り行おうとする。広告ごとに配信計画が作成される。広告グループの回転時期が来たら、広告挿入エンジンは、ＨＴＴＰを介して、ＸＭＬでコーディングされた広告グループ要求をコンテンツ配信サーバ（６１４）に送信する。広告挿入エンジンは、広告グループ応答の中の広告メタ・データを使用して、コンテンツ・サーバから広告を取得し、その後、フォーマットし直して、アプリケーションのフロー・ファイルに取り込む。コンテンツ配信サーバが広告を特定の利用可能なものについて広告グループ応答の中に含める場合、レコードをデータベースに書き込み、広告放送であることを示す。

バナー広告に対する肯定的応答またはユーザの要求時の肯定的応答により、「コマーシャル」に対し、現在実行されている画像／オーディオ・データの部分的置換または全部の置換がトリガされることがある。広告ガジェットを使用して、クライアント・デバイスに現在表示されているかつ／または聞こえている画像およびオーディオ・データを挿入することができる。第４層はここでは、クライアント層（６３０）と呼ばれ、広告ガジェット・キット（６３４）、ターゲット（６３６）、および測定（６３８）を備える。広告はターゲットに送信され、そこでクライアントＳＴＢ上に常駐する視聴者プロファイルと一致する広告が選択される。選択された広告が、広告ガジェット・キットに転送され、視聴者に表示される。広告ガジェット・キットにより、アプリケーションはクリック・スルー機能が装備されている広告の回転を表示することができる。視聴者は、広告内の項目をクリックして広告と対話することができる。測定（６３８）では、広告主にとって興味深い項目、つまりクリック・スルー・レート（視聴者が積極的にインプレッションに応答する率）、購入率、およびインプレッションカウントに関して視聴者活動をサンプリングし、広告の有効性を評価する。図６に示されているように、測定（６３８）の結果は広告データベース（６０４）に送信される。

測定のアーキテクチャを図７に示す。クライアント側では、測定（７０６）がクライアント・デバイス、たとえば、セットトップ・ボックス上で実行され、ログ・ファイル・コレクタ・ガジェット（７０４）からデータが編集される。ログ・ファイル・コレクタ・ガジェットは、未処理のザップ・データ（何のチャネルが同調されているか）およびログ・データ（何が購入されたか）を収集する。サンプル・モデルでデータのサンプリングを行うことができ、その場合ＳＴＢが所定の期間にわたって、または絶対モデル上で記録することを選択する。ログ・ファイルは、ＳＴＢ上で前処理しておくことができるが、処理の大半はサーバ上で実行される。局所的には、活動ログのデータはフラッシュ・ファイル・システムに格納される。格納した詳細は、圧縮して、必要なフラッシュ記憶領域を縮小するのが好ましい。ロギング・モデルが異なれば、必要なフラッシュ・ファイルも異なる。転送ライブラリはＳＴＢ上に常駐しており、常駐アプリケーションに取り込むものとして使用され、それにより、活動ログがサーバに転送される。転送には、一定時間枠内で転送を分散するためランダム要素を含める。情報は、ＳＴＢ上の測定機能からサービス・ゲートウェイ（７０８）に送信され、さらに、データが電波中継局層のＴＶ測定サーバ（７１０）に渡される。

サーバ側では、アプリケーション・サーバによって活動ログが収集され、データベースに格納される。活動ログは、未圧縮形式で格納されるため、分析および操作が簡単に行える。データベースへのＡＰＩにより、サードパーティ製システム（７１４）、つまりテレビ測定会社による活動ログへのアクセスが可能である。ある範囲の基本レポートに、活動ログの分析をまとめるが、その際に、使用するサンプルを考慮し、補間された結果を提示する。サンプリングされたＳＴＢの割合は１％と小さく、母集団全体を適切に表している。本発明の好ましい実施形態では、データはＳＴＢから匿名で収集される。他のオプションとして、測定およびプロファイルが両方とも配備され、家庭プロファイルを活動ログとともに報告することができる。好ましい実施形態では、ログ・ファイルの処理および分析の方法は、ＴＶ測定会社（たとえば、Ｎｉｅｌｓｅｎ）で使用している方法である。他のプロセスおよび分析方法も使用できる。ＴＶ番組およびインタラクティブ・アプリケーションに対する継続的ＴＶ格付けを行うための処理がサーバ上で実行される。継続的に追跡したデータから、テレビ別の毎日のテレビ視聴者数がわかり、放送およびケーブル・テレビ番組およびインタラクティブ・アプリケーションの利用に関する格付けをより明確に分析することができる。個々のクライアント応答がセットトップ・ボックス上のプロファイルに格納され、一般的民衆視聴習慣の情報が電波中継局サーバに格納される。本発明の好ましい実施形態では、Ｐｒｅｄｉｃｔｉｖｅ Ｎｅｔｗｏｒｋｓの商用ソフトウェアを使用している。

図８は、ターゲットのアーキテクチャ図を示している。ターゲットはＳＴＢベースのソフトウェアであり、広告でクライアント視聴者のプロファイルを作成し、その視聴者をターゲットとすることを目的としている。ターゲットは、電波中継局層、放送層、およびクライアント層にまたがって動作する。電波中継局では、一組のクラス・スキームにより広告が分類される。テレビおよび娯楽産業では、ローカル・チャネル、ＥＰＧ、およびインタラクティブ・アプリケーションと同様にメタ・データを供給する。放送層では、広告の「ユニバーサル」な説明がデータのプロファイルに入る。

図８に示されているようにクライアント層は、すべての届いたターゲット広告またはＳＴＢに到着したＴコマースイニシアティブとして動作するＳＴＢ内の小さな常駐プロファイル（ターゲット・プロファイル）を提供する。クライアント層は、活動捕捉およびプロファイル更新用のログ・ファイル・コレクタ・ガジェット（８０１）およびリアルタイム・プロファイリング用のガジェット（８０３）だけでなく、ターゲット・プロファイル（８０５）も備える。常駐プロファイルの性質は、使用されている技術によって異なる。好ましい実施形態では、Ｐｒｅｄｉｃｔｉｖｅ Ｎｅｔｗｏｒｋｓのソフトウェアを使用して、プロファイルを約１４０の変数で構成している。ログ・ファイル・コレクタ・ガジェット（８０１）は、クライアント・デバイス上に常駐しており、ザップ・データ（何のチャネルが同調されているか）およびログ・データ（何が購入されたか）を捕捉する。コレクタ・ガジェットは、測定（６３８）およびターゲット（６３６）と共通して使用される。コア・プロファイリング・アルゴリズム（８０３）では、収集されたデータを使用してリアルタイムでログ・ファイル結果に従いターゲット・プロファイル（８０５）を更新することができる。プロファイルはＳＴＢ上に全体が常駐し、受信ターゲット広告またはＴコマースをフィルタ処理する。プロファイルをローカルのＳＴＢに常駐させることで、プロファイルへのアクセスを制御できる。広告が要求されると、ターゲット・プロファイルと広告の「ユニバーサル」プロファイルとの一致に応じて放送ストリームから広告が選択される。

図１０を参照すると、管理者が１つまたは複数のＳＰＳシステムの安全性および接続性、および外部サーバからのデータ・ストリーム、ファイル・データの適切な時期などを追跡できるようにする分散方式をＳＰＳが採用している。図１０は、外部サーバ、ＳＰＳサーバ、放送機器、およびクライアントの間の標準的な接続を示している。

サービス・プロバイダ１００１は、Ｃｏｍｍｅｒｃｅ ２Ｋ、ＦｅｔｃｈＭａｉｌ、ＦＴＰサービスなどのサービスを使用し、ファイアウォールを介して、インターネットに接続されている。１００３として示されている外部サービス・プロバイダは、ＡｃｃｕＷｅａｔｈｅｒ、ＣａｂｌｅＳｏｆｔ、ＧＩＳＴ、Ｒｅｕｔｅｒｓなどのサービスを備える。これらのサービスは、多重化されたファイル、データ、およびＩｎｓｔａｎｔ ＭｅｓｓｅｎｇｅｒサービスをＳＰＳに提供し、またインターネット経由で利用することもできる。これらのサービス・プロバイダから得られる情報は、サービス機器１００５に送信され、これはさらに、放送機器１００７を介してクライアントとやり取りする。

ＳＰＳは、複数の異なる層レベルで分散コンピュータ・システムとして動作するため、中央データベースを必要としない。すべてのサービス（たとえば、Ｒｅｕｔｅｒｓ）は、そのサービス用のステータス、スケジュール初期化ファイル、設定ファイルなどを持つ。監視システムがＳＰＳサービス・プロバイダ（１０１１）、所有者放送機器（１０１５）、および放送ストリーム層（１０１７）で接続する。概略を述べたＳＰＳは、ハードウェア障害が発生したとき、データ・サービス障害が発生したとき（ｆｔｐ／ｈｔｔｐ／電子メールなど）、裏チャネルに障害が発生したとき、予定データ更新が失敗したとき、またはスケジュールＭＵＸ更新が失敗したときにＮＯに警告する。外部サーバに接続されているモニタは、ＡｃｃｕＷｅａｔｈｅｒ、Ｒｅｕｔｅｒｓ、ＦｅｔｃｈＭａｉｌなどのシステムに常駐するファイル群を監視することができる。放送サービスでは、ＳＰＭが、天候、ニュース、ストリームなどクライアントに送信された項目だけでなく、サービス・ゲートウェイおよびＭｅｒｇｅｒやＦＴＰエージェントなどのローカル・アプリケーションを監視する。

ＳＰＭはすべてのＳＰＳストリームを監視する。放送機器が故障した場合、このモニタが不適合または欠損ストリームのフラグを立てる。ＳＰＳはさらに、サービスが動作していることもチェックする。また、ＳＰＳは、データの有効性および適時性をチェックするが、これは特に、一時的なデータの場合に重要である。たとえば、株価は１５分おきに更新されるが、天気情報は少なくとも１日１回更新される。そうでなければ、エラーが発生する。

ＳＰＳにより、システムに接続されている端末から監視することができる。ＳＰＭは、サービス、ＳＮＭＰ、可聴音アラート、ページャ・アラート、電子メール・アラート、プラグイン監視エージェント（たとえば、ＳＧＷ）、ブラウザによるリモート・アクセス、要約画面およびネットワークの詳細マップ、およびサーバとサービスの連続的監視などの他の機能も備える。

代表的なソフトウェア・コンソールを図１１に示す。ソフトウェアは、ネットワーク・モニタ・ページを備え、これはオプションで、要約表示、トップ表示、およびログ表示から表示可能である。管理者は、アプリケーション・サーバ、放送電波中継局、およびデータ・プロバイダを監視する選択ができ、ファイルの完全性、適時性、およびステータスを監視する。

本発明では、さまざまな品質のサービスが受信契約者の満足度を高め、頻繁な売買を減らし、受信契約者１人あたりの収益を高めることが実証されていると述べた。しかし、このような好ましい結果は、受信契約者が１日２４時間、１年３６５日、信頼性を損なうことなくこれらのＩＴＶサービスにアクセスできる場合に限られる。ＩＴＶサービスの完全性の監視には、従来のテレビ送信の監視とは別の要求条件がある。したがって、ＩＴＶサービスの完全性を監視し、問題を効率よく診断するためには、ＩＴＶコンテンツの制作および配布の連鎖全体を監視しなければならない。このような制作と配布の連鎖には、外部データベース（たとえば、天気、ニュース、株式）が定期的にアクセスされるデータ収集ポイント、データ（たとえば、天気データ）がテンプレート（天気ナビゲーション・ページ）とまとめられ最終的なサービスを作成するサービス・アセンブリ・ポイント、サービスがＨＦＣネットワークに注入される放送ポイント、および注文（たとえば、ピザ）が集められ、個人データ（たとえば、電子メール）が個々のユーザに配信されるオンライン・サーバが含まれる。

制作および配布連鎖のすべての構成要素が、ディスパッチされたときにアラームを、サードパーティ・サービス・プロバイダ（たとえば、天気）、ＯｐｅｎＴＶ（たとえば、ゲーム）、またはネットワーク・オペレータ（たとえば、マルチプレクサ）を含む関連当事者に送信するサービス・プラットフォーム監視機器により監視される。ＳＮＭＰをできる限り使用するが、単独では使用しないのが好ましい。パブリック・インターフェイス監視は、ＳＮＭＰが利用できない場合に使用され、また利用できる場合はＳＮＭＰとタンデムで使用する。採用されているパブリック・インターフェイス監視は、すべてＴＣＰ／ＩＰベースである。知られているサービス管理者の知られているポート（たとえば、ＦＴＰ：ポート２１）およびこれらのポート上の定期的なテスト・トランザクションは、関連サービスがまだ稼働していることを判別するための方法を実現する。このタイプの監視は、一方が外部サービス・プロバイダに依存している場合に非常に役立ち、このような状況では、ＳＮＭＰ監視機能はただ単に利用できない可能性が最も高い。パブリック・インターフェイス監視はさらに、ＳＮＭＰとともに使用でき、これにより、接続性および破滅的イベント−トラップが単に発生しないとき−の発生の検出の完全性が確実なものとなる。また、ＳＮＭＰ ＭＩＢＳは、ステージング領域のディスク空き領域など、最低システム要件について定期的に問い合わせされる。

ＥＴＲ ２９０ライブ・ストリーム・アナライザを使用することで、放送されることが予想されるすべてのポータル・ストリームが存在し、許容できる品質で放送されること保証するのが好ましい。アプリケーション・ストリームが放送サーバから出た後、複数システムをオペレータまたはネットワーク・オペレータの機器でうまくいかないことがまだ多い。機器に対し監視アクセスを行わない場合、ＥＴＲ２９０アナライザはソフトウェア、ハードウェア、構成、および多重化の潜在的なすべての問題を検出する最後の監視ゲートなのである。

リターン・パスまたは裏チャネルはインフラストラクチャにおいてポータルおよび収益モデルの幹線にとって不可欠なものである。したがって、リターン・パスをインフラストラクチャに不具合が生じると、ポータルの完全性に重大な影響を及ぼす可能性がある。このような事態を監視するために、ＣＯＭオブジェクトが定期的に、視聴者の家庭内のＳＴＢ群にｐｉｎｇを実行する。範囲を複数の組に分けることで、階層的なケーブル・インフラストラクチャをカバーする。ポータルが依存するものでさらに微妙ではあるが等しく重要なものとして、データ・ソースとテレビ・アプリケーションがある。アプリケーションのデータまたはアプリケーション自体を定期的に更新する必要がある場合、更新できないと、ポータルの完全性に支障が出る。データにはデータ・スケジュールが関連付けられている。データ・スケジュールは、図１３に示されているように、一定期間に基づくデータ断片の「有効期限」を示す。そこで、任意の時点に、データ断片は関連する有効期限が設定されており、これは時刻、曜日、週（１年のうちの何週目か）に応じて変わる。したがって、データの完全性は、あらかじめ定められているシンタックスに基づきもはやそれに依存しなくなっている。データ断片、またはサービスは、現在の有効期限を超えると完全性を失う。データ完全性はシンタックスに関する既存のコンポーネントを補完する新しい時間的コンポーネントを持つ。

これらの依存関係を監視するために、本発明では、ＳＮＭＰ対応スケジュール・モニタ（スケジュール完全性モニタ）を提示している。どのような形式のデータまたはアプリケーション・ファイルも、アプリケーションまたはデータが従わなければならない１つまたは複数の関連スケジュールを持つ。これらのスケジュールに従って更新／リフレッシュされないと、監視機器にＳＮＭＰトラップが発生する。データ障害はアプリケーション障害と同じ重大度で取り扱われるが、両方ともポータルおよびその結果の視聴者利用の完全性に影響を及ぼすからである。監視情報およびレポート作成機能へのアクセスにはすべて、Ｗｅｂインターフェイスを使用する。この方法は、データにアクセスする方法として最も柔軟性が高い。最低限のコストを余分にかけるだけで、監視ステーションを文字通り世界中のどこにでも設置することができる。

ネットワーク・モニタ・ページが図１２に示されている。列の見出しは、サービスの名前、サービスの種類、調査件数、回答のあったパーセント、回答のなかったパーセント、ダウンタイム、期間、アラート発生件数、平均遅延、最大遅延、および最小遅延などの注目している項目を示している。たとえば、ＨＭＢ＿ＮｅｗｓのＣＤマージャー・サービスは、９回調査が行われており、回答があったのが７７．７８％で、回答がなかったのが２２．２２％であることを示している。ダウンタイムは０秒で、判明しているアラートはない。平均遅延は２４６ミリ秒で、最小遅延は０ミリ秒、最大遅延は１０４６ミリ秒である。管理者は、ＨＭＢ＿Ｎｅｗｓリンクをマウスでクリックして、ＨＭＢ＿Ｎｅｗｓ専用のサービス・タイプの画面を表示することができる。

ポータル・プラットフォーム管理では、管理者は監視されているサービスの種類を変更することができる。サービスの名前とともに、そのステータスが「サーバ詳細」というタイトルのページに表示されている表に詳しく示される。サービスと関連するチェックボックスをクリックして、管理対象のサービスを選択する。管理者はさらに、ホストの追加、ホストの削除、イベント・レポートの取得、統計レポートの取得、設定の確認、カウンタのリセット、またはシステムの他のツールからの選択などの機能を利用できる。

モニタは、所定の速度で、ＴＣＰ／ＩＰポートを通じてテストを送信し、応答を取得することにより外部サーバのステータスをチェックする。応答がない場合、管理者は、通信回線に切断が生じている可能性が警告される。

管理者は、ファイル（データ・ファイル、ＭＵＸファイル、設定ファイル、実行可能ファイル）が指定時刻よりも古くなっている場合にアラームを設定することでデータ完全性を維持し監視することができる。たとえば、現在使用しているＡｃｃｕＷｅａｔｈｅｒファイルは１５分おきに更新しなければならない。１回限りのファイルについては１回、天気、ホロスコープ、株価など時間に左右されるデータの場合は定期的に、アラームを設定することができる。管理者は、目的のアラーム・スケジュールを作成する。

ＳＰＳはさらに所定の期間にわたる一連のテスト結果をレポートにまとめるが、このレポートによりファイル更新のステータスの統計的分析を行うことができる。このようなレポートの利点は、サービス・プロバイダが定められた契約条件を守っていることを管理者が確認できるという点である。

フロントエンド・ページが表示デバイスを通じて管理者に表示される。このようなデバイスとして、ＰＣやラップトップ、携帯電話、ＰＤＡ、またはその他の互換性のあるデバイス上のＩｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒがある。このソフトウェアは、たとえば、Ｍｉｃｒｏｓｏｆｔ ＷｉｎｄｏｗｓＮＴやＵｎｉｘ上のシステム・オペレーティングで動作しているシステムを備えるオペレーティング・システム・プラットフォーム上で監視することができる。

管理者は、サービスをクリックすることで、サービス・スケジュール・モニタ・ページを呼び出すことができる。このようなページとして代表的なのは、ファイル名、最終更新時刻、ステータス、およびスケジュールを表示するものがある。たとえば、ファイル名が「ａｃｃｕ＿ｗｅａｔｈｅｒ．ｄａｔ」で、ファイル・ステータスは「期限切れ」または「ＯＫ」とすることができる。このファイルのスケジューリング・グリッドには、列ごとの日にラベルが付けられている７つの列と当日の時間ブロックを表すいくつかの行が表示される。このグリッド内にある分のラベルが付いている数値は、前記ファイルが更新される頻度を示す。たとえば、「Ｍｏｎ」というラベルの列と「９：００」というラベルの行では、１２０分という時間リスティングは、「ａｃｃｕ＿ｗｅａｔｈｅｒ．ｄａｔ」が２時間おきに更新されることを示す。

本発明は、ｉＴＶシステムの一実施形態を取りあげたが、分散コンピュータ・システムでも実装できる。他の実施形態では、本発明は、実行されるとコンピュータに本発明を実行させる命令が格納されるコンピュータ読み取り可能媒体、たとえば、ＲＯＭ、ＲＡＭ、ＣＤＲＯＭ、フラッシュ・メモリ、または現在知られているあるいは知られていないその他のメモリを備える。

本発明のサービス・プラットフォームの好ましい実施形態の高水準アーキテクチャ図である。 本発明のサービス・プラットフォームの好ましい実施形態の高水準アーキテクチャ図の代替実施形態の図である。 高水準アーキテクチャの詳細を説明している図である。 図２の詳細説明アーキテクチャ図である。 本発明のサービス・プラットフォームの好ましい実施形態の一実施形態の図である。 本発明のサービス・プラットフォームの他の実施形態の一実施形態の図である。 広告アーキテクチャの図である。 測定のアーキテクチャの図である。 ターゲットのアーキテクチャの図である。 アカウントのアーキテクチャの図である。 サービス・プラットフォーム・マネージャのアーキテクチャの図である。 サービス・プラットフォーム・マネージャのソフトウェア実装の図である。 サービス・プラットフォーム・マネージャのネットワーク・モニタ・ページの図である。 データ監視の有効期限の図である。

Claims (10)

1. 広告マネージャ手段がサーバのキャンペーン規則にアクセスするステップであって、前記キャンペーン規則は複数の広告の内のどの広告がターゲットに配信されるべきかを特定し、前記ターゲットは少なくとも１つのクライアント・デバイスを含むステップと、
   広告マネージャ手段が少なくとも１つのクライアント・デバイスを備えるターゲットへの配信のために第１の広告を広告コンテンツ・データベースから前記キャンペーン規則に基づいて選択するステップであって、クライアント・デバイスのユーザに付随する各ユーザ・プロファイルを含む複数のユーザ・プロファイルから視聴者マネージャ手段によって集成されたユーザ・データベースに格納されたプロファイルのデータに基づいて選択するステップと、
   前記広告マネージャ手段が、前記選択された第１の広告をクライアント・デバイスに送信するステップと、
   前記クライアント・デバイスにおいてビジネス・フィルタ手段が、前記選択された第１の広告を前記クライアント・デバイスに格納するかどうかを、前記クライアント・デバイスにおける各ユーザ・プロファイルを表すパラメータを前記集成されたプロファイルのパラメータと比べて決定するステップと、
   前記広告マネージャ手段が、前記第１の広告へのクライアント・デバイスのユーザの応答を前記サーバの規則生成コンポーネントで受信するステップであって、前記規則生成コンポーネントは、前記ユーザの応答に前記キャンペーン規則を適用して前記ユーザの関心をさらに予測し、その予測したユーザの関心に基づいて新たなキャンペーン規則を生成するように構成され、前記新たなキャンペーン規則に基づいて前記サーバが前記ターゲットに配信されるべき新たな広告を選択する、ステップと、そして
   前記サーバが配信マネージャをトリガーして前記新たな広告を前記ターゲットに配信するステップと
   を含む、インタラクティブ・テレビ・システムを管理するための方法。
2. 請求項１に記載の方法において、前記広告マネージャ手段が、
   キャンペーン規則へのアクセスを、配信用の第２の広告の選択のために行い、
   前記第２の広告をターゲットに送信し、
   前記第２の広告に対するクライアント・デバイスのユーザ応答を測定し、
   クライアント・デバイスの前記ユーザ応答に基づいて新しいキャンペーン規則を構築し、
   前記新しいキャンペーン規則に基づいて第３の広告を選択し、
   前記新しいキャンペーン規則に基づく前記第３の広告をターゲットに送信する
   ことを特徴とする方法。
3. 請求項１に記載の方法において、前記広告マネージャ手段が、要求されたインプレッションに基づき、前記第１の広告の選択をする、ことを特徴とする方法。
4. 請求項１に記載の方法において、前記広告マネージャ手段が、見ているクライアント・デバイス・ユーザの数に基づき、前記第１の広告の選択をする、ことを特徴とする方法。
5. 請求項２に記載の方法において、前記広告マネージャ手段が、ユーザの応答に基づいてターゲットに提示する製品カタログを構築する、ことを特徴とする方法。
6. インタラクティブ・テレビ・システムを管理するための方法をコンピュータに実行させる命令を格納しているコンピュータ読み取り可能媒体であって、前記方法は、
   広告マネージャ手段がサーバのキャンペーン規則にアクセスするステップであって、前記キャンペーン規則は複数の広告の内のどの広告がターゲットに配信されるべきかを特定し、前記ターゲットは少なくとも１つのクライアント・デバイスを含むステップと、
   広告マネージャ手段が少なくとも１つのクライアント・デバイスを備えるターゲットへの配信のために第１の広告を広告コンテンツ・データベースから前記キャンペーン規則に基づいて選択するステップであって、クライアント・デバイスのユーザに付随する各ユーザ・プロファイルを含む複数のユーザ・プロファイルから視聴者マネージャ手段によって集成されたユーザ・データベースに格納されたプロファイルのデータに基づいて前記選択が行われるステップと、
   前記広告マネージャ手段が、前記選択された第１の広告をクライアント・デバイスに送信するステップと、
   前記クライアント・デバイスにおいてビジネス・フィルタ手段が、前記選択をされた第１の広告を前記クライアント・デバイスに格納するかどうかを、前記クライアント・デバイスにおける各ユーザ・プロファイルを表すパラメータを前記集成されたプロファイルのパラメータと比べて決定するステップと、
   前記広告マネージャ手段が、前記第１の広告へのクライアント・デバイスのユーザの応答を前記サーバの規則生成コンポーネントで受信するステップであって、前記規則生成コンポーネントは、前記ユーザの応答に前記キャンペーン規則を適用して前記ユーザの関心をさらに予測し、その予測したユーザの関心に基づいて新たなキャンペーン規則を生成するように構成され、前記新たなキャンペーン規則に基づいて前記サーバが前記ターゲットに配信されるべき新たな広告を選択する、ステップと、そして
   前記サーバが配信マネージャをトリガーして前記新たな広告を前記ターゲットに配信するステップと
   を含む、コンピュータ読み取り可能媒体
7. 請求項６に記載のコンピュータ読み取り可能媒体において、前記広告マネージャ手段が、 キャンペーン規則へのアクセスを、配信用の第２の広告の選択のために行い、
   前記第２の広告をターゲットに送信し、
   前記第２の広告に対するクライアント・デバイスのユーザ応答を測定し、
   クライアント・デバイスの前記ユーザ応答に基づいて新しいキャンペーン規則を構築し、
   前記新しいキャンペーン規則に基づいて第３の広告を選択し、
   前記新しいキャンペーン規則に基づく前記第３の広告をターゲットに送信する
   ことを特徴とする、コンピュータ読み取り可能媒体。
8. 請求項６に記載のコンピュータ読み取り可能媒体において、前記広告マネージャ手段が、要求されたインプレッションに基づき、前記第１の広告の選択をする、ことを特徴とする、コンピュータ読み取り可能媒体。
9. 請求項６に記載のコンピュータ読み取り可能媒体において、前記広告マネージャ手段が、見ているクライアント・デバイス・ユーザの数に基づき、前記第１の広告の選択をする、ことを特徴とする、コンピュータ読み取り可能媒体。
10. 請求項７に記載のコンピュータ読み取り可能媒体において、前記広告マネージャ手段が、ユーザの応答に基づいてターゲットに提示する製品カタログを構築する、ことを特徴とする、コンピュータ読み取り可能媒体。

Images