JP5160439B2 - 要求に応じて、通信ネットワークに結合された端末に対話型メニューを提供する方法 - Google Patents

Description

本発明は、コンテンツおよびそれらの対応する対話型メニューを通信端末に送信することが可能であり、コンテンツおよびそれらの対応する対話型メニューが通信端末の画面に表示されることが可能な固定またはモバイルの通信ネットワークに関する。

本明細書では、「コンテンツ」という用語は、テレビプログラム、またはビデオもしくは音声（ラジオもしくは音楽）プログラム、またはゲーム、またはマルチメディア、またはコンピュータファイル（もしくは「データ」）を定義する多量のデータのセットを指す。

さらに、本明細書では「通信ネットワーク」という用語は、いわゆる「片方向」通信チャネルで、そこに結合された通信端末にコンテンツを送信するために、および「バックチャネル」として知られている双方向通信チャネルで、同じ通信端末とデータまたはメッセージを交換するために有線または電波を使用する任意の種類の通信ネットワークケーブルを指す。任意のコンテンツ送信方式は、特にはユニキャスト方式、マルチキャスト方式またはブロードキャスト方式が考えられてもよい。例えばこのネットワークは、ケーブル（もしくは光ファイバ）、またはｘＤＳＬ回線、または場合よっては衛星中継を使用するモバイル（もしくはセルラ式）電話通信ネットワークなど、中速または高速の双方向データ送信回線を含む固定の通信ネットワークであってもよい。

さらに、本明細書では「通信端末」という用語は、上述の種類のネットワークからコンテンツ受信することができ、また同通信ネットワークとデータ、メッセージおよび要求を交換することができる任意の種類の通信装置のことを指す。例えば通信端末は、モバイル（もしくはセルラ式）電話、携帯情報端末（もしくはＰＤＡ）、暗号化されたビデオもしくはテレビプログラムのためのデコーダ、テレビプログラムを受信するための「セットトップボックス」、ビデオもしくは音楽プログラムを受信する装置、またはデスクトップもしくはラップトップコンピュータ、または車両（自動車、トラック、バス、電車および同様の車両）の中の車両搭載装置であってもよい。

一部のコンテンツ配信業者は、顧客に送信するコンテンツに関連したさらなる情報および／または機能を利用可能にするために、および／またはそのコンテンツについての顧客の意見を知るために、顧客と対話することを望んでいる。そのために、配信業者は顧客に送信するコンテンツデータに対話性データを統合し、場合によってはメニューの形態で、予め設定された時間で対話型サービスを提供する。この方法では、結合されている通信ネットワークを介して、自分の端末を使用して受信されたコンテンツを見ている（または聞いている）顧客は、世論調査に応答するために所与の瞬間に示される特定のメッセージによって招待されてもよく、電話の着信音または映画もしくは音楽作品をダウンロードしてもよく、またはスローモーションリプレイを見てもよい。

この対話型方式には、少なくとも３つの欠点がある。第１に、コンテンツがブロードキャストされる間、顧客に対話型メッセージを押し付け、これが不快であるかもしれない。第２に、対話型サービスは予め設定された時間にしか顧客に利用可能とならず、顧客がサービスを本当に欲する場合、または必要とする場合には利用可能とならない。第３に（あまり重要ではないが）、対話型方式は、パーソナライズされた対話型サービスではなく、平均的な顧客のプロフィールに対応すると思われる対話型サービスしか提供しない。

したがって本発明の目的は、コンテンツ配信業者の顧客の要求に応じて、顧客が欲する場合には常に、対話型の、場合によってはコンテキストベースのメニューをコンテンツ配信業者の顧客に提供することを可能にすることによって、上述の状況を改良することである。

この目的のために、本発明は、双方向通信ネットワークを介して、ユーザの通信端末からの要求に応じて対話型メニューを提供するために専用化される方法を開示する。

この方法は、ネットワークによって送信されるコンテンツが片方向チャネル上の端末によって配信される場合に、
ｉ）表示されるコンテンツに関連した対話型メニューを送信するための要求を、双方向バックチャネルを介してネットワーク上で送信するように、通信端末（場合によってはコンテンツを配信させるものとは異なる端末）の中の専用機能を起動するステップと、
ｉｉ）この要求が受信されるときに、表示されるコンテンツに関連した第１データを記憶する第１記憶手段にアクセスすることと、
ｉｉｉ）少なくとも表示されるコンテンツに関連した第１データのために、対話型メニューを生成するステップと、
ｉｖ）前記生成された対話型メニューを、要求を出す端末にネットワークバックチャネルを介して送信して、要求を出す端末がコンテンツを表示することができるように、およびユーザが、コンテンツが含む要素のうちの少なくとも１つを選択することができるようにするステップとから構成されているという事実によって特徴付けられる。

この本発明の方法は、別々に、または組み合わせて取り入れられてもよい、特には以下のもののような、その他の特徴を含んでもよい。

ステップｉ）で、要求を出す端末は、表示されるコンテンツを表す識別子を要求の中に統合してもよい。１つの変形形態では、コンテンツがライブおよびユニキャスト方式で要求を出す端末（このような場合には、配信を行う端末でもある）に送信される場合には常に、ステップｉｉ）が、送信されるコンテンツを表す識別子を判定することも含む。

ステップｉ）で、要求を出す端末は、そのユーザを表す識別子を要求の中に統合してもよい。１つの変形形態では、コンテンツがライブおよびユニキャスト方式で要求を出す端末（このような場合には、配信を行う端末でもある）に送信される場合には常に、ステップｉｉｉ）が、要求を出す端末のユーザを表す識別子を判定することも含む。

ステップｉｉｉ）で、第２メモリ手段は、ユーザ識別子（その人のユーザプロフィールなど）によって示されるユーザについての情報を第２データから抽出するために、アクセスされてもよく、その後、第１データに基づいて、第２データを考慮に入れて対話型メニューが生成されてもよい。

ステップｉｉｉ）で、対話型メニューは、表示されるコンテンツを求める要求が送信された瞬間を表す時間情報の一部を考慮に入れて、第１データに基づいて生成されてもよい。

要求を出す端末（この場合は配信を行う端末）にライブで送信されるコンテンツが表示される場合、ステップｉｉｉ）で、要求を出す端末によって要求が送信された時間である時間情報が判定されてもよい。

１つの変形形態で、要求を出す端末はステップｉ）で、時間情報を要求の中に統合してもよい。この場合、コンテンツが要求を出す端末（このような場合には、配信を行う端末でもある）に以前に送信されており、その後そこに記憶されている場合には常に、時間情報はコンテンツの表示の開始から経過した時間を表し、一方で要求を出す端末にコンテンツがライブで送信された場合には常に、時間情報は要求が生成された瞬間のことである。

第１データのうちの少なくとも一部は、大体ライブで編集および／または更新されてもよい。

要求を出す端末の画面は、ユーザにとって利用可能にされたコンテンツのために、対話型メニューを表す第３データを表示することができる。例えば、第３データは、コンテンツの配信の開始の直前の一定期間か、またはコンテンツの配信の間の少なくとも選択された期間の間、表示されてもよい。

本方法は、端末における要求が、ユーザによって選択される各要素の指示をメニューの中に含むメッセージを送信するステップｖ）と、送信されるメッセージのコンテンツが、ユーザからの要求を満たし、および／または送信されたメッセージから抽出された情報を保存するような方法で処理されるステップｖｉ）とを含んでもよい。

ステップｉｉ）、ｉｉｉ）およびｖｉ）は、通信ネットワークに接続された通信装置（サーバなど）の中で実行されてもよい。

また本発明は、双方向通信ネットワークに結合されることが意図されており、また双方向バックチャネル上で要求を出す端末によって送信され、端末（場合によっては要求を出す端末とは異なる端末）によって配信されるコンテンツに関連した対話型メニューの送信を求める要求を受信する場合には常に、ｉ）配信されるコンテンツに関連した第１データを記憶している第１記憶手段にアクセスすることと、ｉｉ）少なくとも配信されるコンテンツに関連した第１データに基づいて対話型メニューも生成し、ｉｉｉ）要求を出す端末が対話型メニューを表示することができ、ユーザが、対話型メニューが含む要素のうちの少なくとも１つを選択することができるように、ネットワークバックチャネルを介して対話型メニューを、要求を出す端末に送信することを開始することとが課された処理手段を含む通信装置も開示する。

本発明の通信装置は、別々に、または組み合わせて取り入れられてもよい、特には以下のもののような、その他の特徴を含んでもよい。

ライブおよびピアツーピア方式で送信されるコンテンツの一部を、要求を出す端末によって配信するために、その処理手段には、送信されるコンテンツを表す識別子を判定することが課されてもよい。１つの変形形態で、この要求は、送信されるコンテンツを表す識別子を直接含んでもよい。

本発明の処理手段には、ユーザ識別子によって示されるユーザについての情報を表す第２データを抽出し、その後第２データを考慮に入れて、第１データに基づいて対話型メニューを生成するための第２記憶手段にアクセスすることが課されてもよい。

要求を出す端末がライブおよびピアツーピア方式でコンテンツを配信している場合、その処理手段には、要求を出す端末のユーザを表す識別子を判定することが課されてもよい。１つの変形形態で、この要求は、要求を出す端末のユーザを表す識別子を直接含んでもよい。

本発明の処理手段には、第１データに基づいて、コンテンツのブロードキャストに関して要求が送信された瞬間を表す時間情報の一部を考慮に入れて、対話型メニューを生成することが課されてもよい。

要求を出す端末が、ライブで送信されるコンテンツを配信している場合、その処理手段には、要求を出す端末によって要求が送信された時間である時間情報を判定することが課されてもよい。１つの変形形態で、この要求は、時間情報の一部を直接含んでもよい。

要求を出す端末によって送信されるメッセージが受信され、前記メッセージがそのユーザによって選択される各要素の指示をメニューの中に含む場合、その処理手段には、ユーザからの要求を満たし、および／または受信されたメッセージから抽出された情報を保存するような方法で、受信されたメッセージのコンテンツを処理することが課されてもよい。

本発明のその他の特徴および利点は、以下の詳細な説明、および唯一の図が概略的および機能的に、コンテンツサーバが接続されている通信ネットワークを示している添付の図面を吟味する上で明らかになると思われ、通信装置の例示の実施形態は、通信端末の要求に応じて対話型メニューを生成するために専用化される。添付の図面は、本発明を完成させるためだけに役立つのではなく、必要に応じて、本発明を定義することの一助となってもよい。

本発明の目的は、通信端末が通信ネットワークを介して受信されるコンテンツを、前記コンテンツに関連した対話型メニューを用いてリアルタイムで表示する間に、前述のような要求を作る通信端末を提供することを可能にすることである。

続いて、非限定的な例を目的として、通信端末は、ＵＭＴＳネットワーク（またはその変形形態もしくは等価物）などのモバイル（またはセルラ式）電話通信ネットワークに接続されており、前記ネットワークを介してビデオ、テレビプログラム、またはラジオプログラムなどのコンテンツを受信することができるモバイル（またはセルラ式）電話とみなす。しかしながら、本発明はこの種類の通信端末に限定されるわけではない。実際本発明は、冒頭部で定義されるすべての種類の通信端末、すべての種類のネットワークおよびすべての種類のコンテンツに適している。

本発明は実際には、配信されるコンテンツの種類に影響を受けることはなく、その実装の細部だけがコンテンツの送信方式に左右される。

単一の図面は、通信端末Ｔｉ（ここではｉ＝１から３であるが、任意のゼロ以外の値であってもよい）、および場合によっては少なくとも１つのコンテンツ配信端末Ｔ’（テレビセットまたはＭＰ３プレイヤーなど）が接続されている（通信）ネットワークＲ１を示す。

本発明はまた、端末が「片方向」チャネルを介して、（双方向通信）ネットワークＲ１によって送信されるコンテンツの一部を配信する場合には常に、このネットワークＲ１の顧客に属するものであり、配信を行う端末であるか、または配信を行う端末Ｔ’とは異なるが、そのごく近くの環境に配置された端末のいずれかでもある通信端末Ｔｉに、その要求に応じてネットワークＲ１を介し、このコンテンツに関連した対話型メニューを提供することを可能にする方法を開示する。コンテンツは、必ずしもネットワークＲ１のオペレータでなくてもよい、コンテンツ配信業者に属するコンテンツサーバＳＣによって送信される。

この方法は、少なくとも４つのステップを含む。

第１ステップは、ユーザの要求に応じて、表示されるコンテンツに関連した対話型メニューの送信を求める要求を双方向「バックチャネル」を介してネットワークＲ１に送信する目的で、場合によっては片方向チャネル上でネットワークＲ１に送信されるコンテンツを配信するものとは異なる、例えばＴｉなどの通信端末の中で、専用機能を起動することから構成されている。

本発明は、配信端末Ｔ’が、所与の瞬間に配信しているコンテンツの一部を受信するか、または受信しており、要求を行う端末であり、配信端末Ｔ’の隣にある通信端末Ｔｉが配信端末によって配信されたコンテンツに関連した要求を生成する第１の状況に適用され、また通信端末Ｔｉが、所与の瞬間に配信しているコンテンツの一部を受信するか、または受信しており、配信しているコンテンツに関連した要求を生成する第２の状況にも適用されるという点に留意することが重要である。場合によってはコンテンツの配信を取り扱ってもよい通信端末Ｔｉだけが要求を生成することが可能であり、したがって要求を出す端末と呼ばれることが可能である。

さらに、配信されるコンテンツが音声および／または映像（テレビプログラム、ビデオまたはデータなど）であってもよい点に留意することも重要である。以下では、非限定的な例を目的として、配信されるコンテンツが映像であり、その結果コンテンツは、通信端末Ｔｉのための画面ＭＡか、または配信端末Ｔ’のための画面ＭＡ’上に表示されることによって配信されるということが仮定される。

コンテンツは要求を出す端末Ｔｉの画面ＭＡか、または配信端末Ｔ’の画面ＭＡ’上に表示されるので、要求を出す端末Ｔｉのユーザの主導で任意の時間に起動されてもよい。

端末の画面上にネットワークの一部を表示することはライブで、すなわちネットワークがコンテンツを配信するのと同時に行われてもよく、または遅れて、すなわちネットワークＲ１によって一旦コンテンツが送信されて、その後端末ＴｉまたはＴ’のメモリに記憶されてから行われてもよいという点に留意することが重要である。

この起動を可能にするために、要求を出す端末Ｔｉには、対話型メニューを提供するために専用化されるアプリケーションＡＴが備えられていなければならない。このアプリケーションは、好ましくはソフトウェアモジュールの形態で提供され、場合によってはユーザの要求に応じて、もしくはネットワークＲ１のオペレータによってダウンロードされてもよく、または（後で全体部分を形成する）メディアリーダの内部などに、要求を出す端末が製造されるときに設置されてもよい。

この専用アプリケーションＡＰは、要求を出す端末Ｔｉ上のキーによって、またはメニューもしくはサブメニューから要素を選択することによって、または音声コマンドによって制御される。

専用アプリケーションＡＰが起動されている場合、要求を出す端末Ｔｉの画面ＭＡか、または配信端末Ｔ’の画面ＭＡ’上に表示されるコンテンツに関連した対話型メニューの送信を求める要求を生成する。

専用アプリケーションＡＰは、表示されるコンテンツを表す識別子をこの要求の中に統合してもよい。このことは、コンテンツが遅れて表示される場合、すなわち要求を出す端末Ｔｉに送信されて、その後そこに記憶された後で表示される場合には常に、またはコンテンツの複数の部分が一旦ブロードキャスまたはマルチキャスト方式で送信される場合には常に必須である。すべてのその他の状況では、コンテンツ配信業者と協議することによって配信されるコンテンツ、すなわち表示されるコンテンツの識別子を判定することが可能であるとすると、１つの選択肢しか存在しない。コンテンツは、配信端末Ｔ’によって配信される場合には常に、表示されるコンテンツを表す識別子を専用アプリケーションに対して示さなければならないのは、要求を出す通信端末Ｔｉの使用である。

専用アプリケーションＡＰはまた、設置されている要求を出す端末Ｔｉのユーザを表す識別子を要求の中に統合してもよい。このことは、コンテンツが遅れて表示される場合には常に、またはコンテンツがブロードキャストもしくはマルチキャスト方式で送信される場合には常に、またはコンテンツが要求を出す端末Ｔｉによってではなく、配信端末Ｔ’によって配信される場合には常に必須である。すべてのその他の状況では、ネットワークＲ１と協議することによって、そのバックチャネルのうちの１つを介して要求を送信している要求を出す端末Ｔｉのユーザの識別子を判定することが可能であるとすると、１つの選択肢しか存在しない。

専用アプリケーションＡＰはまた、時間情報の一部を、表示されるコンテンツに関して、それが送信された瞬間を表す要求の中に統合してもよい。後に再度言及されることになる本発明の特定の実施形態では、要求を出す端末Ｔｉの画面ＭＡか、または配信端末Ｔ’の画面ＭＡ’上でコンテンツの配信が開始して以来どれだけの時間が経過したのかを遠隔の装置が判定することができないとすると、ディスプレイ上にコンテンツが表示される場合には常に、この統合が必要である。そのような場合、時間情報の一部は、例えば配信が開始してから経過した時間の量を表してもよい。すべてのその他の状況では、表示されるコンテンツの部分に大体対応する、要求が生成された瞬間を判定することが可能であるとすると、１つの選択肢しか存在しない。

各要求は、（必ずしもその一部ではないが）ネットワークＲ１に結合されており、アドレスを有する通信装置ＥＣによって処理されることが意図されている。この通信装置ＥＣは、例えばアプリケーションサーバの形態で提供されてもよい。

各々が１つの種類のコンテンツか、または１つのコンテンツ配信業者に専用化される複数の通信装置ＥＣが設計されてもよいということに留意することが重要である。実際、第１通信装置がビデオコンテンツに関連した要求の処理に専用化され、第２通信装置がテレビプログラムコンテンツに関連した要求の処理に専用化され、第３通信装置が音声またはラジオプログラムコンテンツに関連した要求の処理に専用化されるということが予見されてもよい。

複数の通信装置ＥＣがネットワークに結合されているが、要求を出す端末Ｔｉに設置されたアプリケーションＡＰがそれらの要求を送信するための単一のアドレスしか持たない場合、すべての要求を収集し、要求の各々をどの通信装置ＥＣが処理すべきなのかを判定するために要求を分析することが課されている、さらなる通信装置ＥＧが含まれてもよい。

通信装置ＥＣが要求を出す端末Ｔｉから要求を受信する場合には常に、第２ステップが開始する。

この第２ステップは、対象とされる要求の受信者である通信装置ＥＣによって処理される、すべてのコンテンツに関連した第１データが記憶された第１記憶手段ＢＤに、要求を出す端末Ｔｉ（または配信端末Ｔ’）によって表示されるコンテンツに関連した第１データのうちのすべてを第１記憶手段ＢＤから抽出することを目的にアクセスすることから構成されている。

そのために、各通信装置ＥＣは、受信する要求を処理することが課された処理モジュールＭＴを有する。より正確には、処理モジュールＭＴは最初に、受信された要求によって求められているコンテンツの識別子を判定しなければならない。上で示されているように、このコンテンツの識別子は要求の一部であってもよい。その他の場合、処理モジュールＭＴはコンテンツ配信業者と協議することによって（これは、要求を出す端末もまたコンテンツを配信するものである場合には可能ではない）、コンテンツの識別子を判定しなければならない。

処理モジュールＭＴが一旦コンテンツの識別子を有すると、識別されたコンテンツに関連した第１データをそこから抽出する目的で第１記憶手段ＢＤにアクセスするために、含有する抽出モジュールＭＥをロードする。

第１記憶手段ＢＤは、必ずしも通信装置ＥＣの一部ではないということに留意することが重要である。これは特に、唯一の図面の中で示された例において当てはまる。ＢＤは、コンテンツ配信業者によって提供、編集および更新される情報を含む。結果的に、第１記憶手段ＢＤは、コンテンツサーバＳＣなどのコンテンツ配信業者の装置上に設置されてもよい。重要なことは、ＢＤがネットワークＲ１を介して通信装置ＥＣにアクセス可能であるということである。

これらの第１記憶手段ＢＤは、特にはメモリまたはデータベースの形態など、任意の形態で提供されてもよい。

さらに第１データは、配信業者にとって、たとえ離れていても、配信されるコンテンツに関連している限り任意の種類のものであってよい。例えば、サッカーの試合などのスポーツプログラムについては、第１データは選手および監督に関連した情報、その監督によって一般に用いられる戦略、またはプレイ中のチームについての（および場合によっては、同じリーグまたは他国のリーグのすべてのその他のチームについての）情報、ならびに特にはそれらの各々の記録、シーズン開始以来のそれらの各々の試合結果およびそれらの次の試合についての情報であってもよい。さらに、第１データが編集および／または更新が可能な場合には常に、スローモーションリプレイを提供する目的で、ちょうど再生したところのシーケンスのイメージから構成されてもよい。

コンテンツがミュージカルである場合には常に、第１データは例えば、コンテンツ配信業者によってその作品が配信されているオーケストラ、歌手またはバンドについての情報、および特にはそれらのディスコグラフィもしくは近く行われるコンサートの日時および会場についての情報、またはそれらのレコーディングのうちの少なくとも１つを有料でダウンロードするための方法であってもよい。

抽出モジュールＭＥは、一旦要求されているコンテンツに関連した第１データのすべてを抽出すると、それらを、例えば、本発明の方法の第３ステップを実施することが課されている処理モジュールＭＴの生成モジュールＭＧに通信してもよい。

この第３ステップは、少なくとも（第１記憶手段ＢＤから抽出された）表示されたコンテンツに関連した第１データに基づいて、対話型メニューを生成することから構成されている。

この第３ステップで、生成モジュールＭＧは要求を送信した要求を出す端末Ｔｉを対象とした対話型メニューを、端末Ｔｉの画面ＭＡ上に（または近隣の配信端末Ｔ’の画面ＭＡ’上に）表示されているコンテンツに関連した第１データに基づいて構築する。

処理モジュールＭＴが表示されているコンテンツに関連した、要求が送信された瞬間を表す時間情報の一部を有する場合には常に、その生成モジュールＭＧは対話型メニューを改良または完成してもよい。この場合、生成モジュールＭＧは、要求を出す端末Ｔｉの画面ＭＡ上に（または近隣の配信端末Ｔ’の画面ＭＡ’上に）ちょうど表示されているコンテンツの一部に関連した１つまたは複数の要素を、対話型メニューの中に統合してもよい。次いで、対話型メニューは文脈によって決まるようになる。上述のスポーツプログラムの例では、例えば１つまたは複数の角度から見られた、ちょうど起こったばかりの（またはちょうど表示されたところの）プレイについての１つまたは複数のスローモーションリプレイが、この方法でメニューの中に提供されてもよい。

上で示されているように、時間情報の一部は要求の中に含まれているか、またはコンテンツ配信業者のコンテンツサーバＳＣと同期されたクロックを使用して処理モジュールＭＴによって判定される。後者の場合、処理モジュールＭＴは、要求が生成された日時とともに、要求を受信した日時を識別する。

当然のことながら、時間情報の使用を可能にするために、第２データは時間（および場合によっては日付）と関連して記憶されなければならない。

処理モジュールＭＴが要求を送信した要求を出す端末Ｔｉのユーザについての識別子を有する場合には常に、その生成モジュールＭＧは、ユーザについての情報を表す第２データに基づいて、パーソナライズされた（または文脈によって決まる）対話型メニューを有利に構成してもよい。この第２データは、ネットワークＲ１に結合された第２記憶手段ＢＰの中に記憶される。第２データは例えば、それらのユーザ識別子と関連して記憶されたユーザのプロフィール（またはその部分）であってもよい。

第２記憶手段ＢＰは必ずしも通信装置ＥＣの一部ではないということに留意することが重要である。これは特に、唯一の図面の中で示されている例において当てはまる。ＢＰは、コンテンツ配信業者によって、または（必要なわけではないが）それらがそれ自体の顧客である場合にはネットワークＲ１のオペレータによって提供、編集および更新される情報を含む。結果的に、第２記憶手段ＢＰは、コンテンツ配信業者の装置（そのコンテンツサーバＳＣなど）のうちの１つか、またはネットワークオペレータの装置のうちの１つに設置されてもよい。重要なことは、ＢＰがネットワークＲ１を介して通信装置ＥＣにアクセス可能であるということである。

これらの第２記憶手段ＢＰは、特にはメモリまたはデータベースの形態など、任意の形態で提供されてもよい。

さらに第２データは、たとえ離れていても、要求を出す端末Ｔｉのユーザに関連している限り任意の種類のものであってよい。したがって第２データは、世代のグループ、性別、プログラムの種類の好み、嗜好、興味のある分野、趣味、プログラムを閲覧するための時間枠、および全般的に言って、ユーザをパーソナライズすることを可能にすることができるすべてのものであってよい。このユーザについての情報は一般に、特には視聴者層の分析または視聴率を精査するために、コンテンツ配信業者によって使用される。

文脈によって決まる対話型メニューのうちの１つの要素は、場合によっては要求を出す端末Ｔｉのユーザに提供することを目的としたサブメニュー上で、ユーザが見ている（または聞いている）コンテンツに間接的に結び付けられた行為を呼び出してもよいということに留意されたい。この方法で、サブメニューは、ユーザと同じコンテンツを同じ時間に見ている仲間のリスト、またはユーザと同じ地理的領域にいる仲間のリストなどのコミュニティ情報をユーザが利用できるようにしてもよく、または仲間とのチャットウィンドウを開く能力をユーザが利用できるようにしてもよい。

当然のことながら、そのようなサービスを提供するために、ユーザプロフィール（または第２データ）はそれを考慮に入れなければならず、仲間の識別子は第２データの形態で記憶されなければならない。また通信装置ＥＣは、ユーザの端末の地理的位置など、ネットワークコアの中に含まれた、さらなる情報へアクセスすることを許可されなければならない。

上で示されているように、要求を出す端末Ｔｉのユーザの識別子は、要求の中に含まれているか、またはネットワークＲ１と協議することによって、処理モジュールＭＴによって判定される。後者の場合では、要求を出す通信端末Ｔｉが、そのバックチャネルのうちの１つを介してその要求を送信しているので、ネットワークＲ１には要求を出す通信端末Ｔｉの識別子がわかる。したがって、特に前記要求を出す端末Ｔｉの識別子と同じものである場合、そこから要求を出す端末Ｔｉのユーザの識別子を推論することは比較的容易である。

処理モジュールＭＴは一旦（文脈によって決まるもの、すなわちパーソナライズされているか、または一時的に改良されたものであってもよい）対話型メニューを有すると、要求を出す端末Ｔｉに送信されるメッセージの形態で、ネットワークＲ１を介して対話型メニューを送信することを開始する。この送信は、本発明の方法の第４ステップを構成する。

要求を出す端末Ｔｉは、以前に要求を送信するために使用されたバックチャネル（すなわち同じチャネル）を介してネットワークからメッセージを受信する場合には常に、メッセージをその専用アプリケーションＡＰに送信する。このアプリケーションは対話型メニューを抽出して、その要求を出す端末Ｔｉの表示手段に、例えば表示されるコンテンツの一番上に覆い被せることなどによって、画面ＭＡ上に対話型メニューを表示するように命じる。

次いで、要求を出す端末Ｔｉのユーザは、必要に応じて、画面ＭＡ上に表示された対話型メニューの中に含まれた要素のうちの少なくとも１つを選択してもよい。

次いで本方法は、専用アプリケーションＡＰが、要求を出す端末Ｔｉのユーザによって対話型メニューから選択された各要素の指示を含むメッセージを生成する第５ステップへ続いてもよく、次いで前記要求を出す端末Ｔｉに、以前に使用されたバックチャネルを介して、このメッセージを対話型メニューに送信する通信装置ＥＣにメッセージを送信するように命じる。

通信装置ＥＣがネットワークＲ１を介して、要求を出す端末Ｔｉからメッセージを受信する場合には常に、その処理モジュールは、メッセージを処理する目的で、メッセージからコンテンツを抽出する。これは、本発明の方法の起こりうる第６ステップを構成する。

より正確には、処理モジュールＭＴは、ユーザが（対話型メニューの中に含まれた要素に関して）特定の要求を作っているかどうかを判定し、もし作っている場合には、その人の要求を満たすことを可能にするオペレーションを実行する。これらのオペレーションは、例えば、表示されたコンテンツに関連した特定の情報を送信すること、または、音楽レコーディングを送信することが課されたものか、もしくは購入品の代金を支払うために専用化されるものなど、別のサーバとの接続を確立することから構成されていてもよい。処理モジュールＭＴはまた、送信されたメッセージから抽出された情報をメモリ（不図示、必ずしも通信装置ＥＣの一部ではない）の中に記憶してもよい。この情報は、例えば視聴層の分析を指示しまたは視聴率を向上させるために、コンテンツ配信業者にとって有益なものであってもよい。

本発明の各通信装置ＥＣの処理モジュールＭＴは、電子回路、ソフトウェア（またはコンピュータ）モジュール、または回路とソフトウェアとの組み合わせの形態で構成されてもよい。

ユーザを対話機能に慣れさせるために、専用アプリケーションＡＰは、その要求を出す端末Ｔｉの画面ＭＡ上に、例えば覆い被せることなどによって、コンテンツに関連した対話型メニューの有効性を表す第３データを表示するような方法で構成されてもよい。例えば、この第３データは、画面ＭＡ上へのコンテンツの表示の開始に即時に先行する時間間隔で、またはコンテンツが表示される期間の１つまたは複数の選択された時間間隔で表示されてもよい。

この第３データは、例えばテキストまたは音声メッセージ、および／またはロゴを構成してもよい。

本発明は、以下のようないくつかの利点を提供する。
本発明は、コンテンツデータにメニューデータを添付する必要性をなくすことができる。
本発明は、配信端末（場合によっては公共の場所に設置されたテレビセットなど）によって表示されるコンテンツの一部を見ている通信端末のユーザに、前記表示されるコンテンツに関連したメニューを、同じ配信端末上で前記コンテンツを見ているかもしれない別の人々に配信することなく、提供することを可能にする。
本発明は、ユーザが欲するときにいつでも対話型メニューにアクセスすることを可能にする。
本発明は、送信方式からの独立を提供する。
本発明は、ユーザにとって利用可能な新しいサービスおよびアプリケーションを可能にする。
本発明は、固定通信ネットワークと、モバイル（またはセルラ式）通信ネットワークとの両方に適している。
本発明は、文脈によって決まる情報（ユーザプロフィールおよび／または時間関連の情報）を考慮に入れることができる。

本発明は、単に例として示されている、上述のような対話型メニューを提供する方法および通信装置の実施形態に限定されるわけではなく、むしろ本発明は、当業者が冒頭の特許請求の範囲の枠組み内で想定することができるすべての変形形態を包含する。

通信端末Ｔｉおよび少なくとも１つのコンテンツ端末Ｔ’が接続されている通信ネットワークＲ１を示す。

Claims (18)

1. 端末（Ｔｉ、Ｔ’）が片方向チャネル上でネットワーク（Ｒ１）によって送信されるコンテンツの一部を配信しているときに、ｉ）前記配信されるコンテンツに関連した情報の一部の送信を求める要求を、双方向バックチャネルを介して前記ネットワーク（Ｒ１）に送信するように、専用機能が通信端末（Ｔｉ）の中で起動され、ｉｉ）前記要求を受信した上で、前記配信されたコンテンツに関連した第１データが記憶されている第１記憶手段（ＢＤ）がアクセスされる、双方向通信ネットワーク（Ｒ１）に結合された通信装置（ＥＣ）によって、ユーザの通信端末（Ｔｉ）の要求に応じて対話型メニューを提供する方法であって、要求される情報が対話型メニューであり、ｉｉｉ）対話型メニューが、少なくとも前記配信されるコンテンツに関連した前記第１データに基づいて生成され、ｉｖ）コンテンツの配信の間に、前記生成された対話型メニューがネットワーク（Ｒ１）の前記バックチャネルを介して、前記要求を出す通信端末（Ｔｉ）に送信されて、前記要求を出す通信端末（Ｔｉ）が前記生成された対話型メニューを表示することができ、前記端末Ｔｉのユーザが、前記対話型メニューが含む要素のうちの少なくとも１つを選択することができるようにする、ことを特徴とする方法。
2. ステップｉ）で、前記要求を出す端末（Ｔｉ）が、配信されるコンテンツを表す識別子を前記要求の中に統合することを特徴とする、請求項１に記載の方法。
3. 前記要求を出す端末（Ｔｉ）が前記配信を行う端末であること、および前記要求を出す端末（Ｔｉ）に送信されるコンテンツがライブおよびピアツーピア方式で送信される場合に、送信されるコンテンツを表す識別子がステップｉｉ）で判定されることを特徴とする、請求項１に記載の方法。
4. 要求を出す端末（Ｔｉ）のユーザを表す識別子が前記通信装置（ＥＣ）によって判定され、ｉｉｉ）第２記憶手段（ＢＰ）が、前記ユーザの識別子によって指定されるユーザについての情報を表す第２データを抽出する目的で前記通信装置（ＥＣ）によってアクセスされ、次いで前記対話型メニューが前記第１データに基づいて前記通信装置（ＥＣ）によって生成され、前記第２データを考慮に入れることを特徴とする、請求項３に記載の方法。
5. 前記第２データがユーザのプロフィールを表すことを特徴とする、請求項４に記載の方法。
6. ステップｉｉｉ）で、前記対話型メニューが前記第１データから生成され、配信されるコンテンツに関して前記要求が送信された瞬間を表す時間情報の一部を考慮に入れることを特徴とする、請求項５に記載の方法。
7. 前記要求を出す端末（Ｔｉ）が前記配信を行う端末であること、および前記要求を出す端末（Ｔｉ）に送信されるコンテンツの一部がライブで配信される場合に、前記要求が前記要求を出す端末（Ｔｉ）によって送信された時間である前記時間情報の一部がステップｉｉｉ）で判定されることを特徴とする、請求項６に記載の方法。
8. 前記ユーザに前記コンテンツについての対話型メニューを提供することを表す第３データが、前記要求を出す端末（Ｔｉ）の画面（ＭＡ）に表示されることを特徴とする、請求項１から７のいずれか一項に記載の方法。
9. 前記第３データが、前記コンテンツの配信開始の直前の期間に表示されることを特徴とする、請求項８に記載の方法。
10. 前記第３データが、少なくとも前記コンテンツが配信される期間の選択された時間間隔の間表示されることを特徴とする、請求項９に記載の方法。
11. 前記要求を出す端末（Ｔｉ）が、そのユーザによって前記メニューの中で選択される各要素の指示を含むメッセージを送信するステップｖ）と、前記送信されたメッセージのコンテンツが、前記ユーザによる要求を満たすように前記通信装置（ＥＣ）によって処理される、および／または送信されたメッセージから抽出された情報が前記通信装置（ＥＣ）によって記録されるステップｖｉ）とを含むことを特徴とする、請求項１から１０のいずれか一項に記載の方法。
12. ステップｉｉ）、ｉｉｉ）およびｖｉ）が、前記通信ネットワーク（Ｒ１）に結合されたサーバ（ＥＣ）で実行されることを特徴とする、請求項１から１１のいずれか一項に記載の方法。
13. ネットワーク（Ｒ１）の双方向バックチャネル上で、要求を出す端末（Ｔｉ）によって送信された要求を受信して、端末（Ｔｉ、Ｔ’）によって配信されるコンテンツに関連した対話型メニューの送信を求める場合に、ｉ）前記配信されるコンテンツに関連した第１データが記憶されている第１記憶手段（ＢＤ）にアクセスし、次いでｉｉ）少なくとも前記配信されるコンテンツに関連した前記第１データに基づいて対話型メニューを生成し、ｉｉｉ）ネットワーク（Ｒ１）の前記バックチャネルを介した、前記要求を出す端末（Ｔｉ）への前記対話型メニューの送信を開始して、前記要求を出す端末（Ｔｉ）が前記対話型メニューを表示することができ、前記端末Ｔｉのユーザが、前記対話型メニューが含む要素のうちの少なくとも１つを選択することができるように構成された処理手段を含むことを特徴とする、双方向通信ネットワーク（Ｒ１）に結合されることが可能な通信装置（ＥＣ）。
14. 前記通信装置（ＥＣ）の処理モジュール（ＭＴ）が、前記要求を出す端末がライブおよびピアツーピア方式で送信されるコンテンツの一部を配信しているときに、送信されたコンテンツを表す識別子を判定するように構成されていることを特徴とする、請求項１３に記載の装置。
15. 前記要求が、前記送信されるコンテンツを表す識別子を含むことを特徴とする、請求項１３に記載の装置。
16. 前記処理手段（ＭＴ）が、ユーザ識別子によって示されるユーザについての情報を表す第２データを抽出するために第２記憶手段（ＢＰ）にアクセスし、次いで前記第２データを考慮に入れて、前記第１データから前記対話型メニューを生成するように構成されていることを特徴とする、請求項１３から１５のいずれか一項に記載の装置。
17. 前記処理手段（ＭＴ）が、前記第１データに基づいて、前記表示されるコンテンツに関して前記要求が送信された瞬間を表す時間情報の一部を考慮に入れて前記対話型メニューを生成するように構成されていることを特徴とする、請求項１３から１６のいずれか一項に記載の装置。
18. 前記要求を出す端末（Ｔｉ）によって送信され、そのユーザによって前記メニューの中で選択される各要素の指示を含むメッセージが受信される場合には常に、前記処理手段（ＭＴ）が、前記ユーザからの要求を満たすように、および／または前記受信されたメッセージから抽出された情報を保存するように、前記受信されたメッセージのコンテンツを処理するように構成されていることを特徴とする、請求項１３から１７のいずれか一項に記載の装置。

Images