JP2012524447A - Ｉｐｔｖ（インターネットプロトコルテレビジョン）においてコンテンツストリーム内に広告を挿入するための方法及びシステム - Google Patents

Abstract

ＩＰＴＶにおいてコンテンツストリーム内に広告を挿入するための方法は、前記コンテンツストリーム内の広告の挿入機会を外部の決定点へ通知することと、前記広告の送信機会に挿入されるべき、前記外部の決定点により選択された広告を、前記通知に応じて受信することと、前記コンテンツストリームへの挿入についての選択された前記広告に関連するポリシーを、制御ノードへ送信することと、を含む。当該方法は、記広告の挿入機会について前記外部の決定点へ通知するための広告管理サービスと、選択された前記広告を前記通知に応じて受信するための入力モジュールと、前記コンテンツストリームへの挿入についての選択された前記広告に関連するポリシーを、制御ノードへ送信するための出力モジュールと、含むシステムにおいて実行される。
【選択図】図２

Description

本発明は、一般的に、ＩＰＴＶネットワーク内の広告に関する。より具体的には、本発明は、ＩＰＴＶにおいてコンテンツストリーム内に広告を挿入するための方法及びシステムに関する。

ターゲット化された（targeted）広告は、個人向けの（personalized）ＩＰＴＶについて言うと非常に魅力的な特徴を形成する。実際、そうした広告を特別に加工して、各個人の興味や嗜好に合うように個人向けにすることができる。そのようにすれば、ターゲット化された広告を非常に効率的にすることができ、それにより多くの収入を生み出すことができる。ＳＣＴＥ（Society of Cable Telecommunication Engineers）は、“SCTE 130-3 2009 Digital Program Insertion- Advertising Systems Interfaces Part 3-Ad Management Service (ADM) Interface”というタイトルの標準を公表した。これは、
http://www.scte.org/documents/pdf/Standards/Top Ten/SCTE
130-3 2009.pdf
において公に利用可能であり、参照によりここに取り入れられる。ＳＣＴＥ１３０−３標準は、複数の他の標準化団体により及びサービスプロバイダにより採用されてきている。

ＳＣＴＥにより仕様化された主なインタラクションは、ＡＤＭ（ADvertisement Management service）及びＡＤＳ（Advertisement Decision Service）と呼ばれる２つのエンティティの間のものである。その双方は、ＳＣＴＥ１３０標準の他の部分において定義されているＣＩＳ（Content Information Service）、ＳＩＳ（Subscriber Information Service）及びＰＯＩＳ（Placement Opportunity Information Service）などのエレメントを含むバックグラウンドシステムとの間でもインタラクションする。

ＡＤＭは、トリガ及び他の手段に基づき、特定のコンテンツストリーム内に広告を配置する機会、即ちどこに広告を挿入できるか、についてＡＤＳへ通知を行う。例えば、コマーシャルブレイク、ＶｏＤ（Voice on Demand）セッションの冒頭、ＶｏＤの末尾、又はエンドユーザによりトリガされる“一時停止”コマンドの後などに、広告を挿入することができる。ＡＤＭの役割は、一般的には機会の提供に制限されており、ＡＤＳの役割は、一般的には特定のコンテンツストリーム内にいずれの広告を挿入するかを決定することである。ＡＤＳは、ＡＤＭに応答して、選択した広告を伴う自身の決定を返答する。ＡＤＭは、ＡＤＳにアクティビティイベントをレポートすることにより、機会決定のライフサイクルを完了する。

当然ながら、ＡＤＭとＡＤＳとの間には、機会及び挿入のために選択された実際の新しい広告、並びにキャンセルされる広告などについて、互いに更新を行うなどの他のインタラクションは存在し得る。

ＡＤＳがＡＤＭからの配置（placement）の提案を受け入れると、エンドユーザへデリバリされる特定のコンテンツストリーム内に、選択された広告が挿入される。

ＳＣＴＥ標準は、主にこれら２つのエンティティに焦点を当てている。従って、ＳＣＴＥエンティティを用いるシステムが望ましいであろう。

より具体的には、本発明によれば、ＩＰＴＶにおいてコンテンツストリーム内に広告を挿入するための方法が提供される。当該方法は、上記コンテンツストリーム内の広告の挿入機会を外部の決定点へ通知することと、上記広告の送信機会に挿入されるべき、上記外部の決定点により選択された広告を、上記通知に応じて受信することと、上記コンテンツストリームへの挿入についての選択された上記広告に関連するポリシーを、制御ノードへ送信することと、を含む。

本発明の別の観点によれば、ＩＰＴＶにおいてコンテンツストリーム内に広告を挿入するためのシステムが提供される。当該システムは、上記コンテンツストリーム内の広告の挿入機会を外部の決定点へ通知するための広告管理サービスと、上記広告の送信機会に挿入されるべき、上記外部の決定点により選択された広告を、上記通知に応じて受信するための入力モジュールと、上記コンテンツストリームへの挿入についての選択された上記広告に関連するポリシーを、制御ノードへ送信するための出力モジュールと、を含む。

本発明の上述の及び他の目的、利点及び特徴は、添付図面への参照のみを伴う例としての、その例示的な実施形態の限定的でない以下の説明を読むことで、より明白になるであろう。

本発明の限定的でない例示的な実施形態に係る、ＩＰＴＶと外部ネットワークとの間の相互的なアーキテクチャの概略図である。 本発明の限定的でない例示的な実施形態に係る、ＩＰＴＶにおいてコンテンツストリーム内に広告を挿入する方法を示すフローチャートである。 本発明の限定的でない例示的な実施形態に係る、ＩＰＴＶにおいてコンテンツストリーム内に広告を挿入するためのシステムの概略図である。 広告の挿入のネットワークアプローチについての、図２の広告を挿入する方法をより詳細に示す呼のフローである。 広告の挿入のネットワークアプローチについての、図２の広告を挿入する方法をより詳細に示す呼のフローである。 広告の挿入のネットワークアプローチについての、図２の広告を挿入する方法をより詳細に示す呼のフローである。 広告の挿入のユーザ端末アプローチについての、図２の広告を挿入する方法をより詳細に示す呼のフローである。 広告の挿入のユーザ端末アプローチについての、図２の広告を挿入する方法をより詳細に示す呼のフローである。

説明に移る前に、本発明の実施形態及び説明を通じて使用される略語をよりよく理解するために、略語集が提供される。

略語集
ＡＤＭ （ADvertisement Management service）
ＡＤＳ （Advertisement Decision Service）
ＡＳＭ （Authentication and Session Management）
ＣＣ （Cluster Controller）
ＣＤＦ （Content Delivery Function）
ＣＤＮＣ （Content Delivery Network Controller）
ＣＩＳ （Content Information Service）
ＣＳ （Content Server）
ＨＴＴＰ （HyperText Transfer Protocol）
ＩＧ （IMS Gateway）
ＩＭＳ （Internet protocol Multimedia Subsystem）
ＩＰＴＶ （Internet Protocol Television）
ＩＰＴＶ ＣＳ （Internet Protocol Television Control Server）
ＯＩＴＦ （Open IPTV Terminal Function）
ＰＯＩＳ （Placement Opportunity Information Service）
ＲＡＣ （Resource Admission Control）
ＲＴＳＰ （Real Time Streaming Protocol）
ＳＣＴＥ （Society of Cable Telecommunication Engineers）
ＳＤＰ （Session Description Protocol）
ＳＩＰ （Session Initiation Protocol）
ＳＩＳ （Subscriber Information Service）
ＵＥ （User Equipment）
ＶｏＤ （Video on Demand）
ＸＭＬ （eXtensible Markup Language）

概して言えば、本発明の実施形態は、コンテンツオンデマンドセッションの間に、ＳＣＴＥ１３０標準において定義されたようなＡＤＭ及びＡＤＳを用いて、ＩＰＴＶにおけるコンテンツストリーム内に広告を挿入することを可能とする。実際、例えばＩＰＴＶコントロールサーバ（ＩＰＴＶ ＣＳ）内に位置するＡＤＭは、外部ネットワーク内に位置するＡＤＳへ、広告を挿入することのできる配置機会（placement opportunities）について通知を行う。すると、ＡＤＳは、ＡＤＭから受信された配置機会に適した広告を識別し及び選択し、選択した広告をＡＤＭへ送信する。ＡＤＭは、選択された広告を受信すると、コンテンツストリーム内への挿入についての選択された広告に関連付けられるポリシーを定義する。そして、当該ポリシーは制御ノードへ送信され、制御ノードは受信したポリシーに従って実際の広告の挿入を行うことになる。コンテンツのオンデマンドセッションは、マルチメディア又はビデオオンデマンドセッションであってよい。

背景のセクションで述べたように、ＳＣＴＥ１３０標準は、広告の配置機会及びコンテンツストリーム内に配置され又は挿入される広告の選択に関して、ＡＤＭ及びＡＤＳという２つのエンティティの間の様々なインタラクションを定義している。しかしながら、ＳＣＴＥ１３０標準は、選択された広告の実際の配置をどのように実行すべきか、即ち、選択された広告の実際の配置に関連するポリシーがどのように定義され適切なノードへ送信されるかについて、何らの仕組み又は示唆も提供していない。適切なノードとは、定義されたポリシーに従って広告の実際の挿入を行うことになるノードである。本発明の実施形態は、これら欠点を克服することができる。

ここで、図１に移り、ＩＰマルチメディアサブシステム（ＩＭＳ）などのＩＰＴＶをサポートするシステムと、ＳＴＣＥ標準を用いる外部ネットワークとの間の相互的なアーキテクチャ１０の概略図について説明する。本発明の限定的でない例示的な実施形態が、相互的なアーキテクチャ１０を基盤とする文脈において説明されるであろう。

より具体的には、アーキテクチャ１０は、外部ネットワーク１４と接続される、ＩＰＴＶサービスを提供するためのＩＰＴＶコンテンツサーバ（ＩＰＴＶ ＣＳ）１２を含む。ＩＰＴＶ ＣＳ１２は、ＳＣＴＥ１３０標準により定義されたようなＡＤＭ１６を含み、外部ネットワーク１４は、ＳＣＴＥ１３０標準により定義されたようなＡＤＳ１８を含む。ＡＤＭ１６は、論理エンティティ、１つのソフトウェア、１つのハードウェア又はその双方の組合せであってよい。

ＩＰＴＶ ＣＳ１２及びＡＤＳ１８は、共に制御ノードに接続され得る。制御ノードは、図１に示した本発明の第１の限定的でない実施形態によれば、オープンＩＰＴＶフォーラムにより定義されたような、ＣＤＮＣ（Content Delivery Network Controller）／ＣＣ（Cluster Controller）２０であってもよい。但し、制御ノードは、本発明の第２の実施形態によれば、ＯＩＴＦ（Open IPTV Terminal Function）３０などのユーザ機器（ＵＥ）であってもよい。

なお、ＣＤＮＣは、オープンＩＰＴＶフォーラムにおいて、ＩＰＴＶ制御機能エンティティにより発行されるリクエストに基づくＣＤＮ（Content Delivery Network）内のクラスタの選択を実行する機能エンティティとして定義されている。同じＣＤＮ内に、ＣＤＮＣの多くのインスタンスが共存してよい。それらは、正しいクラスタの選択の目的のために、インタラクションし得る。ＣＣ（Cluster Controller）は、コンテンツデリバリ機能（ＣＤＦ）のセット、即ちＣＤＦのクラスタ、を管理する機能エンティティである。それは、例えば、ＩＰＴＶサービスセッションのセットアップを終端し、コンテンツデリバリセッションのセットアップをハンドリングし、ＣＤＦとＩＴＦとの間の全てのメッセージ交換を代理し、メディアサービスの状態を維持（コンテンツデリバリ機能）する。コンテンツデリバリ機能（ＣＤＦ）は、ＣＣの制御の下で、メディア処理、デリバリ及び配信（distribution）に責任を有する機能エンティティである。

また、ＣＤＮＣ／ＣＣ２０がＳＣＴＥ ＡＤＭの機能性を含んでもよいことに留意すべきである。その理由は、ＩＰＴＶ ＣＳ１２及びＣＤＮＣ／ＣＣ２０の双方が広告の配置の機会についての異なるＩＰＴＶイベントを検出することができるためである。例えば、ＩＰＴＶ ＣＳ１２は、エンドユーザにより新たなコンテンツオンデマンドセッションが開始されることなどを、ＩＰＴＶセッション制御レベルで検出することができる。一方で、ＣＤＮＣ／ＣＣ２０は、コンテンツオンデマンドセッションの視聴の間にエンドユーザにより実行されるプリロール（pre-roll）、パストロール（past-roll）、一時停止（pause）又は再開（resume）コマンドなどのメディアレベルでのイベントを検出することができる。

ＣＤＮＣ／ＣＣ２０はコンテンツデリバリ機能（ＣＤＦ）２２に接続され、ＣＤＦ２２は、コンテンツオンデマンドセッションのためのビデオなどの実際のコンテンツ、及びターゲット化された広告のコンテンツを提供する。当然ながら、ＣＤＮＣ／ＣＣ２０に接続される１つよりも多くのＣＤＦ２２が存在してもよい。

一度ＡＤＭ１６によって広告の配置機会がＡＤＳ１８に通知され、ＡＤＳ１８により広告の配置機会に適した広告が選択されると、選択された広告がＡＤＭ１６に送り返される。そして、選択された広告の挿入が、ネットワークアプローチ又はユーザ機器アプローチのいずれかを通じて行われ得る。ネットワークアプローチにおいて、ＣＤＮＣ／ＣＣ２０は、デリバリのために、及びＡＤＭ１６により送信されるポリシーに従ってＩＰＴＶにおけるコンテンツストリーム内に選択された広告を挿入するために、１つ以上のＣＤＦ２２によってリアルタイムストリーミングプロトコル（ＲＴＳＰ）のセッションをセットアップする。ユーザ機器アプローチにおいて、ＯＩＴＦ３０などのユーザ端末は、デリバリのために、及びＡＤＭ１６により送信されるポリシーに従ってＩＰＴＶにおけるコンテンツストリーム内に選択された広告を挿入するために、１つ以上のＣＤＦ２２によってＲＴＳＰセッションをセットアップする。

図２に移り、ＩＰＴＶにおいてコンテンツストリーム内に広告を挿入するための方法１００について説明する。当該コンテンツストリームは、マルチメディアストリーム若しくはビデオストリーム、又はエンドユーザにとって有益なコンテンツを有する他のいかなるストリームであってもよい。

方法１００は、ステップ１０２によって開始され、ＡＤＳ１８などの外部の決定点（decision point）に、ＡＤＭ１６によってコンテンツストリーム内の広告の送信機会が通知される。ＡＤＳ１８への通知の前に、ＡＤＭ１６は、まず、エンドユーザが視聴しているコンテンツストリーム内の１つ以上の広告の配置機会を検出する。より具体的には、外部の決定点へ通知するために、ＡＤＭ１６は、例えば、広告配置機会リクエストを当該決定点へ送信する。当該広告配置機会リクエストは、少なくともコンテンツＩＤと、ユーザＩＤと、検出された配置機会にとって適切な広告をＡＤＳ１８が選択することを可能とする他の情報とを含んでよい。

次に、ステップ１０４において、上記通知に応じて、ＡＤＭ１６は、上記外部の決定点によって選択された、広告の挿入機会へ挿入されるべき広告を受信する。実質的には、外部の決定点は、広告配置機会リクエストを受信した後に、受信された当該リクエストに含まれる情報に従って、挿入されるべき適切な広告を選択し、そして選択された当該広告をＡＤＭ１６へ送信する。

ステップ１０６において、ＡＤＭ１６は、選択された広告を受信すると、コンテンツストリームへの挿入についての選択された広告に関連するポリシーを、制御ノードへ送信する。より具体的には、ＡＤＭ１６は、受信された広告及び他の情報に基づいて、上記ポリシーを定義する。

制御ノードは、一度ポリシーを受信すると、ＡＤＭ１６から受信されたポリシーに基づいて、選択された広告の挿入を処理する。

挿入されるべき広告に関連する上記ポリシーは、例えば、挿入されるべき選択された広告を識別する広告ＩＤ、選択された広告を取得するための例えばＵＲＬ（Uniform Resource Locator）を用いたリンク、選択された広告の期間、などを含む。

図３は、図２の方法１００を実行することのできる、ＩＰＴＶにおいてコンテンツストリーム内に広告を挿入するためのシステム２００を示している。システム２００は、例えばＩＰＴＶ ＣＳ１２であってよい。

より具体的には、システム２００は、コンテンツストリーム内の広告の配置／挿入の機会を外部の決定点に通知するための、例えばＡＤＭ１６などの広告管理サービスを含む。また、システム２００は、入力モジュール２０２及び出力モジュール２０４を含む。

外部の決定点への通知の前に、ＡＤＭ１６は、まず、エンドユーザが視聴しているコンテンツストリーム内の広告配置／挿入機会を検出する。例えば、ＡＤＭ１６は、エンドユーザが新たなコンテンツオンデマンドセッションを開始したこと、又は彼／彼女が例えば一時停止コマンドをトリガしたことを検出することができる。

入力モジュール２０２は、上記通知に応じて、検出された広告の配置機会に挿入されるべき、外部の決定点により選択された広告の受信を可能とする。実質的には、外部の決定点は、一度上記通知を受信すると、広告の配置機会に挿入することに適した広告を選択し、それらをＡＤＭ１６へ返す。さらに、挿入されるべき選択された広告に更新又は変更がある場合には、入力モジュール２０２は、例えば、外部の決定点から、それら更新をも受信する。また、出力モジュール２０４は、アクティビティイベントをＡＤＳ１８へレポートバックすることを可能とし、例えば、広告の配置、配置の実行など、及びＡＤＳ１８（例えば、関連するイベントの閲覧者）にとって関心のある他の履行（fulfillment）データに関連するイベントがレポートされる。

一度入力モジュール２０２が外部の決定点から選択された広告を受信すると、ＡＤＭ１６は、受信された広告及び他の情報に基づいていくつかのポリシーを定義する。そして、システム２００の出力モジュール２０４は、挿入されるべき選択された広告に関連するそれらポリシーを、ＣＤＮＣ／ＣＣ２０又はＵＥ３０であってよい制御ノードへ送信することを可能とする。制御ノードは、受信されるポリシー、即ち選択された広告をいつどこに及びどれだけの期間挿入すべきかなど、に従って、選択された広告の挿入を処理する。また、入力モジュール２０２が外部の決定点から挿入されるべき選択された広告に関連する更新を受信すると、ＡＤＭ１６によりポリシーが更新され、出力モジュール２０４により、選択された広告の更新に関連する更新されたポリシーが制御ノードへ転送される。

ここで、図４Ａ、４Ｂ及び４Ｃに移り、図１の相互的なアーキテクチャの文脈において実行される際の呼のフロー３００において、方法１００をより詳細に説明する。なお、図４Ａ〜４Ｃは、ＡＤＭ１６及びＡＤＳ１８がそれぞれ広告の配置機会及び挿入されるべき選択された適切な広告を検出した後の、選択された広告の挿入のためのネットワークアプローチを示している。

前提として、ＡＤＭ１６及びＡＤＳ１８の間には、ＳＣＴＥ１３０標準によって実行要件とされている全ての事前の動作が存在するが、それらは、本発明の実施形態に関係しないため、図４Ａ〜４Ｃの呼のフロー３００において示されていない。また、この例示的なフロー３００において、現在のＩＰＴＶ及びＩＭＳ標準に即して、多くのメッセージがＡＳＭ（Authentication and Session Management）を通じてやり取りされる。とは言え、ＡＳＭは、本発明の実施形態には加わらない。よって、ＡＳＭは、これ以上説明されない。同様に、ＩＧ（IMS Gateway）及びＲＡＣ（Resource Admission Control）がＩＰＴＶ及びＩＭＳ標準に即して存在するが、これらは本発明の実施形態に加わらない。但し、これら様々な要素（ＡＳＭ、ＩＧ、ＲＡＣなど）及びそれらのインタラクションについてのさらなる詳細を、“Open IPTV Forum：Functional Architecture vl.2”（2008-12-08）という参考文献において見出すことができ、これは次のリンクにおいて公に利用可能である：
http://www.openiptvforum.org/docs/OIPF-Functional_Architecture-V1.2bis-APPROVED.pdf.

ステップ３０２〜３２０は、ビデオオンデマンドセッションなどのコンテンツオンデマンドセッションを確立するためのものとして当分野においてよく知られていると考えられるため、それ以上の説明を行わない。

ステップ３２２において、ＩＰＴＶ ＣＳ１２は、例えばサブスクリプション又は制御のタイプ（例えばＴＶプログラム）を通じて、現在のコンテンツオンデマンドセッションがターゲット化された広告の対象であることを認識する。そこで、ＡＤＭ１６は、このセッションについて広告の配置機会の検出を開始する。そのために、ＡＤＭ１６は、ＣＩＳ、ＰＯＩＳ又は助けになる他のエンティティなど、他のＳＣＴＥエンティティからの支援を求めてもよい。なお、これら要素は本発明の実施形態には関連しないが、ＡＤＭ１６及びＡＤＳ１８の間のインタラクションをさらに広く理解する際の助けとなり得る。広告の配置機会の探索あるいは検出は、コンテンツオンデマンドセッション中にエンドユーザによりコンテンツが要求されたこと、エンドユーザの識別、及び他の要因に基づいて行われてよい。

広告の配置機会の検出の後、ＡＤＭ１６は、ステップ３２４において、ＡＤＳ１８に広告の配置機会を通知するために、ＡＤＳ１８へ広告配置リクエストを送信する。なお、ＡＤＳ１８は、何らかの広告の選択及びデリバリについて決定を行う。広告配置リクエストは、例えば、コンテンツＩＤと、ユーザＩＤと、エンドユーザへ現在のコンテンツをストリーミングするために選択されるＣＤＦ２２のアドレスと、ＡＤＳ１８が当該セッションのためにターゲット化された広告を選択することを可能とする他の情報と、を含んでよい。

ステップ３２６において、広告配置リクエストの受信の後、ＡＤＳ１８は、何らかのＳＣＴＥエンティティの支援を受けて、挿入されることになる広告についての決定を行う。

図４Ｂのステップ３２８において、ＡＤＳ１８は、ＩＰＴＶ ＣＳ１２のＡＤＭ１６へその応答を返す。当該応答は、例えば、挿入されるべき選択された広告を含む。

ステップ３３０及び３３２において、ＩＰＴＶ ＣＳ１２は、ＡＳＭに（及びＡＳＭからＣＤＮＣ／ＣＣ２０へ）確認応答を送信することにより、ＩＭＳセッションの１つの目的を完了する。

ステップ３３４において、ＡＤＭ１６は、ＡＤＳ１８により選択された広告に関連するポリシーを生成又は定義する。ＡＤＭ１６は、ネットワークアプローチの場合にはＣＤＮＣ／ＣＣ２０である制御ノードへ、それらポリシーを送信する。

より具体的には、ＩＰＴＣ ＣＳ１２は、挿入されるべき広告のＩＤ、広告のＵＲＬ、広告についての期間、挿入時点、他の情報などを含む定義されたポリシーを、ＳＩＰ ＵＰＤＡＴＥを用いてＣＤＮＣ／ＣＣ２０にレポートし、それによりＣＤＮＣ／ＣＣ２０が受信したポリシーを活用することができる。なお、挿入されるべき広告に関連するポリシーについての情報は、前のステップの確認応答メッセージ内では送信されない。これは、そうすることでＳＩＰのオファー−アンサーモデルを崩すことになるからである。結果として、ポリシーについての情報は、ＳＩＰ ＵＰＤＡＴＥメッセージ内で別個に送信される。

ステップ３３４は、ＵＰＤＡＴＥメッセージがＡＳＭへ送信されＣＤＮＣ／ＣＣ２０へ返送されるという、ステップ３３６〜３４０をさらに含む。

そして、ＣＤＮＣ／ＣＣ２０は、ステップ３４２において選択された広告の各々について別個のＲＴＳＰセッションを開始する。ポリシーにより定義されている通りの広告の挿入のための実際の時刻又は挿入時点が到来すると、ＣＤＮＣ／ＣＣ２０は、コンテンツオンデマンドセッションのコンテンツストリームを一時停止（pause）し、選択された広告の再生を開始し、当該選択された広告が終了すると、実際のコンテンツのストリーミングを再開（resume）する。なお、実際のコンテンツのストリーミングが再開する前に、１つよりも多くの広告がストリーミングされてよい（ステップ３４４〜３４８参照）。広告が記憶されるＣＤＦ２２は、コンテンツオンデマンドセッションのコンテンツを供給するサーバとしての同一のサーバ内にあってもよく、又は１つ以上の異なるサーバ内にあってもよい。

最終的に、ステップ３００〜３２０を通じてエンドユーザにより開始された、発信側のＩＭＳセッションは、ステップ３５０〜３５６において完了し、それによりエンドユーザにとってコンテンツオンデマンドセッションのビデオなどのコンテンツのストリーミングを開始することが可能となる。

なお、図４Ａ〜４Ｃの呼のフローにおいて、ＳＩＰ ＵＰＤＡＴＥが使用されている。その代わりに、ｉｎｆｏイベントパッケージを使用するＳＩＰ ＩＮＦＯが、制御ノードあるいはＣＤＮＣ／ＣＣ２０へ挿入されるべき選択された広告についてのポリシーを伝送するために使用されてもよい。このオプションによれば、ｉｎｆｏイベントパッケージ内の何らの変更もなく、ＳＣＴＥにより定義された通りのＸＭＬデータを含めることが可能であり、それはＳＣＴＥ１３０−３ＸＭＬデータに適合するように定義され得る。この場合、方法３００のステップ３３６〜３４０は、ＳＩＰ ＩＮＦＯの代わりにＳＩＰ ＩＮＦＯに変更される。

図５Ａ及び図５Ｂは、ユーザ端末アプローチが適用される場合の方法１００の呼のフロー４００をより詳細に示している。

呼のフロー４００は、ステップ４０２〜４２８と共に開始し、図４Ａの呼のフロー３００のステップ３０２〜３２８と同様、広告の配置機会の通知についてのコンテンツオンデマンドセッションが確立され、ＡＤＳ１８へ広告配置リクエストが送信され、ＡＤＳ１８から応答が受信され、当該応答は挿入されるべき選択された広告を含む。

ステップ４３０〜４３８において、ＩＰＴＶ ＣＳ１２は、ＡＤＭ１６により定義された、選択された広告に関連するポリシーを、図１に示したようなＯＩＴＦ３０などのＵＥへ送信する。当該ポリシーは、例えば、コンテンツオンデマンドセッションの開始フェーズ中に２００ＯＫメッセージにおいてＵＥへ送信されてもよい。

一度ＵＥあるいはＯＩＴＦ３０がポリシーを受信すると、ＵＥあるいはＯＩＴＦ３０は、選択された広告を取得し及び受信されたポリシーに従ってそれらを挿入するための複数のオプションを有する。

例えば、ＵＥは、“ＨＴＴＰ”を用いて選択された全ての広告を取得し、ＵＥ内にローカルに記憶してもよい。広告のための時刻が到来すると、ＵＥは、コンテンツストリームを一時停止し、受信されたポリシーに従って対応する広告をレンダリングする。

また、ＵＥは、各広告について１つずつ、複数のＲＴＳＰセッションを確立してもよい。各広告について、当該広告のための時刻が到来すると、ＵＥはコンテンツストリームを一時停止し、そして広告を再生する。

上で言及したように、ＡＤＭ１６及びＡＤＳ１８の間の追加的なインタラクションは、お互いの更新をも含む。例えば、ＡＤＳ１８は、配置ステータス通知（Placement Status Notification）を送信することにより広告のアベイラビリティにおける変更についてＡＤＭ１６を更新してもよく、それに対してＡＤＭ１６は配置ステータス確認応答（Placement Status Acknowledgement）で応答する。そして、当該更新情報は、広告の挿入のネットワークアプローチについてはＳＩＰ ＵＰＤＡＴＥメッセージにおいてＣＤＮＣ／ＣＣ２０へ送信される。ユーザアプローチでは、当該更新情報は、当該情報を有効化するために、ＳＩＰ ＵＰＤＡＴＥメッセージにおいてＵＥ３０へ送信される。なお、ＳＩＰ ＩＮＦＯがＳＩＰ ＵＰＤＡＴＥの代わりに使用されてもよい。

図１の相互的なアーキテクチャ１０において、イベントの収集及びレポーティングもまた可能である。より具体的には、エンドユーザがターゲット化された広告の挿入を含むコンテンツオンデマンドセッションを開始した瞬間から当該コンテンツオンデマンドセッションの終了までの間に発生し得るエンドユーザのメディアプレイアウト関連のイベントを収集することが可能である。例えば、エンドユーザメディアプレイアウトイベントは、“一時停止（pause）”、“再開（resume）”、“早送り（ＦＦ：Fast Forwarding）”などのイベントを含み得る。これらイベントをレポートし及び収集することは、ターゲット化された広告の成功に関する有益な情報、即ち、広告が見られたかスキップされたかなど、をサービスプロバイダが集めるための助けとなる。これは、ターゲット化された広告の実質的な有効性にアクセスするためのフィードバックの仕組みを構成してもよい。

さらに、イベント及び広告時刻に関連付けられるスタンプを通じて、エンドユーザのある広告に対する傾向と共に、エンドユーザへの広告の効果を見ることも可能である。

例えば、イベントをレポートし及び収集するための２つのオプションが存在する。

第１のオプションは、イベントをレポートするためにＣＤＮＣ／ＣＣ２０を使用する。そのために、ＣＤＮＣ／ＣＣ２０は、イベントについての情報を含む配置ステータス通知（Placement Status Notification）メッセージをＡＤＳ１８へ送信する。ＣＤＮＣ／ＣＣ２０は、セッションをセットアップするためにシグナリング制御プレーンにあり、ＲＴＳＰメディア制御リクエストの経路内にいるため、一時停止、再生、ＦＦなどのイベントへのアクセスを有し、配置ステータス通知（Placement Status Notification）などのＳＣＴＥメッセージを用いてそれらをレポートすることができる。ＡＤＳ１８は、確認応答メッセージを送信することにより、ＣＤＮＣ／ＣＣ２０へ返答する。

第２のオプションは、例えばイベントコレクタを通じてイベントをレポートするために、ＩＰＴＶ ＣＳ１２を使用する。そのために、配置ステータス通知（Placement Status Notification）メッセージがＡＤＳ１８へ送信される。ＩＰＴＶ ＣＳ１２は、セッションをセットアップするためにシグナリング制御プレーン内にある。ＩＰＴＶ ＣＳ１２は、ＲＴＳＰメディア制御リクエストへのアクセスを有しないため、一時停止、再開、再生、ＦＦなどのイベントを取得できない。しかし、ＩＰＴＶ ＣＳ１２は、ＳＩＰ ＳＵＢＳＣＲＩＢＥ／ＮＯＴＩＦＹの仕組みを通じて、又は他の仕組みを通じて、ＣＤＮＣ／ＣＣ２０からそれらイベントについての情報を得ることができる。ＡＤＳ１８は、確認応答メッセージを送信することにより、ＩＰＴＶ ＣＳ１２へ返答する。

第２のオプションの１つの利点として、ＩＰＴＶ ＣＳ１２は、中央のノードであることから、イベントをＡＤＳ１８へレポートする前に、多くの異なるセッションに関連する複数の他のノードからの情報を統合することができる。

当業者には、ここまでの説明及び関連する図面において提示された教示の恩恵を有する開示された発明の修正及び他の実施形態が想起されるであろう。従って、本発明が開示された特定の実施形態に限定されるものではないこと、並びに修正及び他の実施形態が本開示の範囲内に含まれることが意図されているものと理解されるべきである。ここでは特定の用語が採用されているが、それらは一般的かつ説明のための意味においてのみ使用されており、限定を目的としない。

Claims (24)

1. ＩＰＴＶにおいてコンテンツストリーム内に広告を挿入するための方法であって、
   前記コンテンツストリーム内の広告の挿入機会を外部の決定点へ通知することと；
   前記広告の送信機会に挿入されるべき、前記外部の決定点により選択された広告を、前記通知に応じて受信することと；
   前記コンテンツストリームへの挿入についての選択された前記広告に関連するポリシーを、制御ノードへ送信することと；
   を含む方法。
2. 前記広告の挿入機会を前記外部の決定点へ通知することは、まず、エンドユーザによりコンテンツオンデマンドセッションが開始されることを検出することにより、ＩＰＴＶセッション制御レベルで前記広告の挿入機会を検出すること、を含む、請求項１の方法。
3. 前記広告の挿入機会を前記外部の決定点へ通知することは、まず、プリロール、パストロール、一時停止及び再開コマンドの１つをコンテンツオンデマンドセッションの間に検出することにより、コンテンツレベルで前記広告の送信機会を検出すること、を含む、請求項１の方法。
4. 前記広告の挿入機会を前記外部の決定点へ通知することは、少なくともコンテンツＩＤと、ユーザＩＤと、前記広告の挿入機会に適した広告を前記外部の決定点が選択することを可能とする他の情報とを含む広告配置リクエストを、前記外部の決定点へ送信すること、を含む、請求項１の方法。
5. 前記コンテンツストリームへの挿入についての選択された前記広告に関連する前記ポリシーは、少なくとも選択された前記広告のＩＤと、選択された前記広告のリンクと、選択された前記広告の挿入のための期間と、を含む、請求項１の方法。
6. 選択された前記広告に関連する前記ポリシーを送信することは、ＳＩＰ ＵＰＤＡＴＥを用いることを含む、請求項１の方法。
7. 選択された前記広告に関連する前記ポリシーを送信することは、ＳＩＰ ＩＮＦＯを用いることを含む、請求項１の方法。
8. 選択された前記広告に関連する前記ポリシーを送信する前に、受信された前記広告に基づいて前記ポリシーを定義することを含む、請求項１の方法。
9. 前記ポリシーを前記制御ノードへ送信することは、広告のデリバリのために少なくとも１つのコンテンツデリバリ機能によってリアルタイムストリーミングプロトコルのセッションをセットアップするコンテンツデリバリコントローラに、前記ポリシーを送信すること、を含む、請求項１の方法。
10. 前記ポリシーを前記制御ノードへ送信することは、広告のデリバリのために少なくとも１つのコンテンツデリバリ機能によってリアルタイムストリーミングプロトコルのセッションをセットアップするユーザ端末に、前記ポリシーを送信すること、を含む、請求項１の方法。
11. 前記外部の決定点から、挿入のために選択された前記広告に関連する更新を受信すること、をさらに含む、請求項１の方法。
12. 前記更新を受信することは、前記外部の決定点から広告のアベイラビリティにおける変更を受信すること、を含む、請求項１１の方法。
13. 前記制御ノードへ前記変更を転送すること、をさらに含む、請求項１２の方法。
14. ＩＰＴＶにおいてコンテンツストリーム内に広告を挿入するためのシステムであって、
    前記コンテンツストリーム内の広告の挿入機会を外部の決定点へ通知するための広告管理サービスと；
    前記広告の送信機会に挿入されるべき、前記外部の決定点により選択された広告を、前記通知に応じて受信するための入力モジュールと；
    前記コンテンツストリームへの挿入についての選択された前記広告に関連するポリシーを、制御ノードへ送信するための出力モジュールと；
    を含むシステム。
15. 前記広告管理サービスは、エンドユーザによりコンテンツオンデマンドセッションが開始されることを検出することにより、ＩＰＴＶセッション制御レベルで前記広告の挿入機会を検出するようにさらに構成される、請求項１４のシステム。
16. 前記広告管理サービスは、プリロール、パストロール、一時停止及び再開コマンドの１つをコンテンツオンデマンドセッションの間に検出することにより、コンテンツレベルで前記広告の送信機会を検出するようにさらに構成される、請求項１４のシステム。
17. 前記広告管理サービスは、少なくともコンテンツＩＤと、ユーザＩＤと、前記広告の挿入機会に適した広告を前記外部の決定点が選択することを可能とする他の情報とを含む広告配置リクエストを送信するようにさらに構成される、請求項１４のシステム。
18. 前記コンテンツストリームへの挿入についての選択された前記広告に関連する前記ポリシーは、少なくとも選択された前記広告のＩＤと、選択された前記広告のリンクと、選択された前記広告の挿入のための期間と、を含む、請求項１４のシステム。
19. 前記出力モジュールは、広告のデリバリのために少なくとも１つのコンテンツデリバリ機能によってリアルタイムストリーミングプロトコルのセッションをセットアップするコンテンツデリバリコントローラに、前記ポリシーを送信する、請求項１４のシステム。
20. 前記出力モジュールは、広告のデリバリのために少なくとも１つのコンテンツデリバリ機能によってリアルタイムストリーミングプロトコルのセッションをセットアップするユーザ端末に、前記ポリシーを送信する、請求項１４のシステム。
21. 前記入力モジュールは、前記外部の決定点から、挿入のために選択された前記広告に関連する更新をさらに受信する、請求項１４のシステム。
22. 前記更新は、広告のアベイラビリティにおける変更を含む、請求項２１のシステム。
23. 前記出力モジュールは、前記制御ノードへ前記変更を転送する、請求項２２のシステム。
24. 選択された前記広告についての統計量及び有効性を収集し及びレポートするためのイベントコレクタをさらに含む、請求項１４のシステム。
    

Images