JP2012516495A - セットトップボックスにおいてｉｍｓ機能を実現する方法 - Google Patents

Abstract

セットトップボックス（５０）は、ＩＭＳゲートウェイ（２０）とセットトップボックスの埋込ＯＩＴＦ（５６）との間のＩＰＴＶセッションシグナリングを達成するために、セットトップボックス（５０）の宣言型アプリケーション環境（５４）で動作するスクリプト型のＩＭＳアプリケーション（４０）を提供することによって、ＩＭＳサービス群を処理するために実現される。その結果、事前に構成設定されていて、かつネイティブＩＭＳ機能をインストールしているセットトップボックス（５０）を用意することなく、ホームネットワーク（１）内のユーザ群にＩＭＳサービス群を提供することができる。
【選択図】 なし

Description

本発明は、一般的にはＩＰＴＶ及びＩＭＳに関するものであり、特に、そのようなＩＰＴＶ及びＩＭＳ機能とそのケイパビリティとをセットトップボックスに提供することに関連するものである。

インターネットプロトコル（ＩＰ）マルチメディアサービスは、音声、ビデオ、メッセージング、データ等を同一セッション内で動的に組み合わせて提供する。異なる利用可能なアプリケーション群とメディアタイプ群を持つことは、エンドユーザに提案されるサービスの数を増やすことができ、また、個人間の通信体験を豊かにすることができる。これは、パーソナライズされた豊かなマルチメディア通信サービスを可能にする。

ＩＰテレビ（ＩＰＴＶ）は、新興のシステムであり、これは、デジタルテレビとマルチメディアサービスが、ＩＰオーバネットワークインフラストラクチャを使用して家庭環境に置かれるセットトップボックス群に配信される。今日、ＩＰＴＶはビデオオンデマンド（ＶｏＤ）とライブＴＶサービスに最も頻繁に関連付けられている。しかしながら、ＩＰＴＶはインターネットサービス、例えば、ウェブアクセスとボイスオーバＩＰ（ＶｏＩＰ）をも提供することができる。ＩＰＴＶの更なる特徴は、他のマルチメディアサービス群との統合と収束の機会があることである。この機会は、ＩＰＴＶ環境においてＩＰマルチメディアサービスを配信するための構造上のフレームワークを提供するＩＰマルチメディアサブシステム（ＩＭＳ）によって主に影響が与えられる。セットトップボックスとともに使用することができるこのようなＩＭＳベースのサービスは、チャット、プレゼンスサービス、コンタクトリストサービス及び、インスタントメッセージングのような様々なメッセージングサービスを含み、ＩＰＴＶユーザ間での通信を可能にする。

ＩＭＳは、標準化ＩＭＳサービスイネーブラの使用を通じてエンドユーザ個人間の通信体験を豊かにするための主要な特徴を提供し、これは、ＩＰベースのネットワークを介して、新規の豊かな個人間、即ち、クライアント間の通信サービスを容易にし、それに加えて、個人とコンテンツ間、即ち、クライアントとサーバ間のサービスを容易にする。

一般的には、ＩＰＴＶサービスをエンドユーザに提供するＩＰベースのネットワークは、管理ネットワークあるいはいわゆるオープンインターネットあるいは非管理ネットワークの形態をとることができる。後者の形態は、サービス品質を保証することなく、インターネットを通じてＩＰＴＶサービスを提供する。前者の例は、ネットワークオペレータによって管理される無線ベースの通信ネットワークであり、これは、保証されたサービス品質レベルでＩＰＴＶサービスを提供することができる。

ＩＰＴＶサービスに影響を与える家庭環境に置かれるユーザ端末、いわゆる、セットトップボックス（ＳＴＢ）群は、一般的には、管理ネットワークあるいはオープンインターネットで使用されるかに依存して様々なタイプのものがある。例えば、管理ネットワーク用のセットトップボックスは、ＩＭＳサービス群を実現するための、埋込あるいはネイティブの機能、即ち、コンピュータプログラムコードを備えるように製造することができる。その結果、セットトップボックスは、ＩＭＳセッションをセットアップし、管理するために必要とされる、局所的にインストールされているネイティブロジック群及びハードウェア要素群の少なくとも一方を備え、これには、ネイティブあるいは埋込ＩＭＳアプリケーションとリモートＩＭＳゲートウェイ（ＩＧ）との間でホームネットワークインタフェース−ＩＭＳゲートウェイインタフェース（ＨＮＩ−ＩＧＩ）を使用するケイパビリティを含んでいる。また、セットトップボックスは、このようなＩＭＳに関連する通信がどのようにして実行されるかを定義する実装済ＩＭＳスタックコードを有している。

しかしながら、セットトップボックス群、ＴＶ群と他のＩＰＴＶ端末群は、新規の機能をこれらに迎え入れる場合に、購入ユーザに対して極めて高価になるという観点から、極めてコストに敏感である。これは、ＩＭＳサービス群を実現することを可能にするために、ユーザは、自身の既存のセットトップボックスを、ＩＭＳサービス群を実現可能にするために必要なロジック群とアプリケーション群とを含めるように事前に構成設定されているセットトップボックスに置き換えなければならないということを意味する。しかしながら、このような解決策は、コストがかかり、かつユーザにとって柔軟性がない。

このように、実装済のネイティブあるいは埋込ＩＭＳ機能を備えるように製造されていない、セットトップボックスにおいて、管理されるＩＰＴＶとＩＭＳサービス群の使用を可能にする必要性が存在する。

一般的な目的は、セットトップボックス群に対してＩＭＳサービス群を実現可能にすることである。

特定の目的は、ＩＭＳ機能をセットトップボックス群に提供することである。

簡単に言えば、本発明は、セットトップボックス内のブラウザ環境におけるＩＭＳ機能とアプリケーションの提供を開示し、その結果、任意のネイティブ、即ち、プレインストールされ、かつ構成設定されている、セットトップボックスにおけるＩＭＳ用のサポートを持つことを必要としない。宣言型のアプリケーション環境におけるウェブブラウザで動作するスクリプト型のＩＭＳアプリケーションは、セットトップボックスにおけるＩＭＳアプリケーションの役割を担い、かつ必要なデータ処理と外部ユニット群とのＩＰＴＶセッションシグナリングとを実行するように設計されている。

より詳細には、実施形態の一態様は、ホームネットワーク内のセットトップボックスで実現されるように構成されているＩＭＳアプリケーションに関連する。ＩＭＳアプリケーションは、ＩＰＴＶセッションをセットアップし制御するためのセットトップボックスに代えて、ＩＭＳゲートウェイに向けられているＩＰＴＶセッション信号群を生成するように構成されている信号ジェネレータを備える。ＩＭＳアプリケーションのアドレスプロバイダは、アドレス情報を、セットトップボックスに実装されている埋込あるいはネイティブオープンＩＰＴＶ端末機能（ＯＩＴＦ）システムに提供するように構成されている。このアドレス情報は、ホームネットワークに接続されるグローバルネットワーク内のメディアサーバから利用可能なメディアデータに関連付けられており、このメディアデータは、セットトップボックスにおけるＩＰＴＶセッション中に再現されるべきデータである。受信されるアドレス情報はＩＭＳゲートウェイから発生するものである。この態様のＩＭＳアプリケーションは、セットトップボックスで実現されるウェブブラウザによって実行されるように構成されているスクリプト型のＩＭＳアプリケーションであり、それゆえ、プレインストールされた埋込あるいはネイティブＩＭＳ機能を備えるように製造されていないセットトップボックスあるいはそうでなければ構成されていないセットトップボックスで使用することができる。

第１の態様は、スクリプト型のＩＭＳアプリケーションと、ＩＭＳゲートウェイとの通信を可能にするように構成されている通信インタフェースとを備えるセットトップボックスに関連する。ウェブブラウザは、いわゆる宣言型のアプリケーション環境を提供し、ここでは、スクリプト型のＩＭＳアプリケーションは、セットトップボックスのディスプレイスクリーン装置あるいはセットトップボックスに接続されているディスプレイスクリーン装置に表示可能なウェブページを生成するように実行される。埋込ＯＩＴＦシステムは、通信インタフェースに接続されているセットトップボックスで実現され、また、スクリプト型のＩＭＳアプリケーションによって提供されるアドレス情報に基づいてメディアリクエストを生成するように構成されている。このメディアリクエストは、進行中のＩＰＴＶセッション内で、セットトップボックスにおいてレンダリングするためのメディアデータをリクエストするために、グローバルネットワーク内のメディアサーバへ通信インタフェースによって通信される。

別の態様は、ホームネットワーク内のセットトップボックスとグローバルネットワーク内のサーバ群との通信を可能にするように構成されている通信インタフェースを備えるＩＭＳゲートウェイに関するものである。登録プロセッサが、セットトップボックスのユーザのユーザ識別子を含み、かつグローバルネットワーク内のＩＭＳサーバに向けられている、登録リクエストを生成するように構成されている。ＩＭＳゲートウェイの加入プロセッサは、グローバルネットワーク内のＩＰＴＶのサービスプロバイダに向けられている加入リクエストを生成するように構成されている。これによって、ＩＭＳゲートウェイは、セットトップボックスに代って、登録と、サービスディスカバリ及び選択を取り扱う。アドレス変換プロセッサは、グローバルネットワークからのユーザに利用可能なＩＰＴＶサービスそれぞれに対して、加入リクエストに応じて受信されるアドレス情報を、ＩＭＳゲートウェイを指示している、それぞれのＩＰＴＶサービス群に関連付けられている、変換済のアドレス情報へマッピングするように構成されている。ＩＭＳゲートウェイは、更に、変換済のアドレス情報を含み、かつディスプレイスクリーン装置上のウェブブラウザによる表示のためのセットトップボックス内のスクリプト型のＩＭＳアプリケーションに向けられている、ウェブページを生成するように構成されている。

ＩＰＴＶセッションをセットアップする方法は、１つの態様に従えば、セットトップボックス内で実現されるウェブブラウザ内のスクリプト型のＩＭＳアプリケーションを実行するステップを有する。スクリプト型のＩＭＳアプリケーションは、セットトップボックスのユーザ入力装置あるいはセットトップボックスに接続されているユーザ入力装置の起動に基づいて、ＩＰＴＶセッションセットアップ信号群を生成する。このＩＰＴＶセッションセットアップ信号群は、ＩＭＳゲートウェイへ通信され、一方、ＩＭＳゲートウェイは、スクリプト型のＩＭＳアプリケーションによって受信されるアドレス情報を送信する。メディアサーバから利用可能なメディアデータに関連付けられているこのアドレス情報は、ＩＰＴＶセッション内で、メディアデータに対するメディアリクエストの生成をトリガーするために、セットトップボックスの埋込ＯＩＴＦシステムへ、スクリプト型のＩＭＳアプリケーションによって転送される。

別の態様では、ＩＰＴＶセッションをセットアップする方法は、セットトップボックスのユーザのユーザ識別子を含む登録リクエストのＩＭＳサーバへのＩＭＳゲートウェイによる送信を有する。ＩＭＳゲートウェイは、また、ＩＰＴＶのサービスプロバイダに向けられている加入リクエストを送信し、ここで、ＩＰＴＶサービスプロバイダは、アドレス情報をＩＭＳゲートウェイへ返信することによって応答する。このアドレス情報は、利用可能なＩＰＴＶサービス群に関連付けられていて、また、ＩＭＳゲートウェイによって、そのＩＭＳゲートウェイを指示している変換済のアドレス情報へマッピングされる。変換済のアドレス情報はウェブページをコンパイルするために利用され、このウェブページはセットトップボックスのスクリプト型のＩＭＳアプリケーションへ送信される。

それゆえ、ＩＭＳゲートウェイとのＩＰＴＶとＩＭＳセッション通信を行うために要求されるプロトコル群及びロジック群は、セットトップボックスにプレインストールされる必要はなく、逆に、ブラウザによって実現されるスクリプト型のＩＭＳアプリケーションによって処理することができる。これは、ＩＭＳサービス群が、宣言型のアプリケーション環境を実現するウェブブラウザを有するあらゆるセットトップボックスに提供することができることを意味する。

ＩＰテレビ（ＩＰＴＶ）供給網の概観を示す図である。 ホームネットワーク内で、従来技術に従うセットトップボックス（ＳＴＢ）の構造的アーキテクチャの概観を示す図である。 ホームネットワーク内の実施形態に従うＳＴＢの構造的アーキテクチャの概観を示す図である。 ＩＰマルチメディアサブシステム（ＩＭＳ）セッションをセットアップする実施形態を示す信号図である。 ＩＰマルチメディアサブシステム（ＩＭＳ）セッションをセットアップする実施形態を示す信号図である。 ＩＭＳセッションをセットアップする別の実施形態を示す信号図である。 ＩＭＳセッションをセットアップする別の実施形態を示す信号図である。 ビデオオンデマンド（ＶｏＤ）セッションをセットアップし終了する実施形態の信号図である。 スケジュール済のコンテンツを含むＩＭＳセッションをセットアップし、制御し終了する実施形態を示す信号図である。 スケジュール済のコンテンツを含むＩＭＳセッションをセットアップし、制御し終了する別の実施形態を示す信号図である。 ＩＭＳアプリケーションの実施形態のブロック図である。 ＳＴＢの実施形態のブロック図である。 ＩＭＳゲートウェイ（ＩＧ）の実施形態のブロック図である。

図面を通して、同一の参照番号は、同様のあるいは対応する要素群に対して使用される。

実施形態は、インストール済の埋込あるいはネイティブアプリケーション群としてセットトップボックス群に存在する任意の事前構成ＩＭＳアプリケーション群を必要とすることなく、インターネットプロトコル（ＩＰ）マルチメディアサブシステム（ＩＭＳ）サービス群をユーザ端末群とセットトップボックス群へ提供することに関連する。

図１は２つの相互接続ネットワークである、ホームネットワーク１とグローバルネットワーク２とを基本的に備えるＩＰテレビ（ＩＰＴＶ）システムの概要である。グローバルネットワーク２は、ネットワークオペレータによって操作される、管理あるいは専用ネットワークであり得る。選択的には、グローバルネットワーク２は非管理あるいはオープンネットワークであり、典型的には、従来よりのオープンインターネットを意味する。どちらの場合も、グローバルネットワーク２は、メディアコンテンツへのアクセスを有する１つ以上のコンテンツプロバイダあるいはメディアサーバ７０を収容し、このメディアコンテンツは、ホームネットワーク１に存在するユーザ機器あるいはセットトップボックス５０に配信される。これらのメディアサーバ７０は、ネットワークに配置される専用メディアサーバ群であり得り、あるいは、実際には、自身のそれぞれのホームネットワークにおいて他のユーザ群から利用可能なメディアの形態でコンシューマによって生成されるメディアである。

メディアは、一般的には、１つ以上のＩＰＴＶプロバイダあるいはＩＰＴＶアプリケーションサーバ８０と、１つ以上のアクセスプロバイダ９０を通じてホームネットワーク１で利用可能である。前者は、ネットワーク実装エンティティを表し、これは、ＩＰＴＶシステムのユーザ群へＩＰＴＶサービス群を提供し、一方、後者は、実際のトランスポートと、ホームネットワーク２へ提供されるサービス群へのアクセスを提供する。

図１に示されるグローバルネットワーク２は、ＩＰＴＶシステムのグローバルネットワーク部分の単なる例示として示されるべきである。本実施形態の教示に影響を与えることなく、図示されるものよりも多いあるいは少ないネットワークエンティティを備える他のネットワークソリューションを、代替として、使用することができる。例えば、いくつかのネットワークでは、単一のオペレータあるいはサーバは、機能群：メディアサーバ７０、ＩＰＴＶプロバイダ８０及びアクセスプロバイダ９０の内のすべてあるいはいくつかの役割を担うことができる。

ホームネットワーク１は、時には、住居ネットワークあるいはコンシューマネットワークとも呼ばれ、いくつかの実施形態では、イーサネット、あるいは既存の有線ホームネットワーキング技術群の１つに基づくことができる。この既存の有線ホームネットワーキング技術には、例えば、家庭電話線ネットワーキングアライアンス（ホームＰＮＡ）あるいは電気通信標準セクタ（ＩＴＵ−Ｔ）Ｇ．ｈ規格がある。この規格は、既存の家庭配線を使用して、高速ローカルエリアネットワークを作成する能力を提供するものである。他の例には、様々なローカルエリアネットワーク（ＬＡＮ）ソリューション群がある。これは、ＩＭＳサービス群を含むＩＰＴＶ関連サービス群が、ＩＰと顧客のブロードバンド接続を介して配信することができる。このブロードバンド接続は、例えば、非対称デジタル加入者回線（ＡＤＳＬ）、超高速デジタル加入者回線（ＶＤＳＬ）、公衆イーサネット等がある。無線ネットワークソリューションも、有線技術と無線技術との組み合わせを含むローカルネットワークを確立するために使用することができる。

ホームネットワーク１のデバイス２０−５０は、一般的には、２つのネットワーク１、２との間のインタフェースを提供するゲートウェイ（ＧＷ）１０を通じてグローバルネットワーク２と相互に接続される。このゲートウェイ１０は、ホームネットワーク１から、ユーザが生成したＩＰＴＶサービスリクエスト群のようなデータをグローバルネットワーク２へ転送し、かつグローバルネットワーク２から、ＩＰＴＶサービス群及びそれに関連付けられているメディアのようなデータをホームネットワーク１へ転送するという意味で、ルータと同様に動作する。

図１に示される実施形態では、ホームネットワーク１も、ホームＩＭＳゲートウェイ（ＨＩＧＡ）を備え、これは、従来より単にＩＭＳゲートウェイ（ＩＧ）２０とも呼ばれ、一般的には、ＩＭＳ終端を管理し、かつホームネットワーク１内で相互動作する。ＩＧ２０は、結果として、１つ以上のＩＭＳ機能付きデバイス３０、３５、５０との有線あるいは無線接続を有することができ、これらは、非限定的なものとして、図では、電話３０、コンピュータ／ラップトップ３５、及び汎用セットトップボックス（ＳＴＢ）で示されている。

ＩＧ２０は、図示されるように、ＧＷ１０に接続されるスタンドアローンデバイスであり得る。選択的には、ＩＧ２０の機能は、ＧＷ１０として同一の物理デバイスに提供され得る。これによって、基本的には、ＩＭＳゲート機能と、ネットワーク相互接続及びゲート機能を１つのデバイスに組み込んでいる。このようなデバイスは、モデムあるいは他のゲートウェイユニットであり得る。

ＩＧ２０は図ではホームネットワーク１の一部を形成するように示されているが、これは単に例示の実施形態と見なされるべきである。また、ネットワーク実装ＩＧソリューションが実施形態の範囲内で可能であり、ここで、ＩＧ２０は、グローバルネットワーク２で完全にあるいは少なくとも部分的に実現される。このような場合、ＩＧ２０は、効果的にネットワークノードに実装され、かつグローバルネットワーク２の他の機能、例えば、ＩＰＴＶプロバイダ８０とアクセスプロバイダ９０の少なくとも一方と一緒に配置することができる。

ホームネットワーク１は、典型的には、１つ以上のセットトップボックス５０を備え、これは、ＩＰＴＶメディアを処理し、かつレンダリングすることができるデバイスである。膨大な量の異なるユーザ機器、端末群、デバイス群が存在し、これらは、ホームネットワーク１内のセットトップボックス５０の役割を担うことができる。いくつかの非制限的な例では、デコーダ、コンピュータ等があり、これらは、ＩＰＴＶ８０とゲートウェイ１０からメディアデータを受信する機能を有し、また、処理する機能、即ち、メディアデータをデコードして、搭載されるあるいは接続されるディスプレイスクリーン装置６０にレンダリングする機能を有している。デジタルＴＶシステム群における伝統的なデコーダ群とセットトップボックス群と比較して、ＩＰＴＶシステムでは、セットトップボックス５０は、ＩＰネットワーク上で双方向通信を提供し、かつストリーム化メディアをデコードすることを可能にする。また、移動デバイス３０、３５は、オプションとして、ＩＧ２０を通じてゲートウェイ１０と無線通信し、そして、実施形態に従うセットトップボックスとして動作することができる。つまり、図に示される移動電話３０とコンピュータ／ラップトップ３５は、セットトップボックス群として見なすことができる。セットトップボックスは、ディスプレイデバイス、例えば、ＩＰＴＶ機能付ＴＶに統合することもできる。

以下では、セットトップボックスは、任意のユーザ機器、端末あるいはデバイスを示すために使用される。これらは、ホームネットワークに提供することができ、また、一人以上のユーザへＩＰＴＶサービス群を提供するためのアプリケーションを動作させることができ、そして、接続されているディスプレイスクリーン装置に表示するためのＩＰＴＶ関連メディアを処理する機能と接続されているスピーカによって再生するためのＩＰＴＶ関連メディアを処理する機能との少なくとも一方を有し、接続されているディスプレイスクリーン装置に表示するためのＩＰＴＶ関連メディアには、例えば、ビデオ、画像群、テキスト等のメディア形式があり、また、接続されているスピーカによって再生するためのＩＰＴＶ関連メディアには、オーディオの形式がある。

従来では、オープンＩＰＴＶ端末機能（ＯＩＴＦ）あるいはＩＰＴＶ端末機能（ＩＴＦ）は、時には、セットトップボックスと、ＩＰＴＶセッションをセットアップし、かつ管理するために必要とされる機能群を示すために採用されている。しかしながら、本明細書のセットトップボックスは、一貫して、ホームネットワーク内で提供され、かつＩＭＳサービス群を含むＩＰＴＶサービス群をユーザへ提供するように設計されるデバイスを示すために使用される。

ＩＰＴＶとは、マルチメディアサービス群を網羅するように広く解釈されるべきである。このマルチメディアサービス群には、例えば、ＩＰベースのネットワークを介して、ホームネットワークのユーザ機器へ配信される、テレビ、ビデオ、オーディオ、テキスト、グラフィック、データがあり、そのホームネットワークでは、ローカル処理、即ち、メディアのレンダリング及び再生の少なくとも一方が達成される。

セットトップボックスは、一般的には、ＩＰＴＶサービス群をユーザ群へ提供する様々なＩＰＴＶ関連アプリケーション群を備えるあるいは実行することができる。伝統的なＩＰＴＶシステム群では、これらのＩＰＴＶ関連アプリケーション群、特に、ＩＭＳアプリケーション群は、主に、埋込あるいはネイティブアプリケーション群の形態となっている。このような埋込アプリケーション群は、局所的にセットトップボックスにインストールされ、そして実行される。そして、セットトップボックスは、このようなインストール済の埋込アプリケーションを前もって装備することができる。以下では、「埋込ＯＩＴＦシステム」は、セットトップボックスに埋め込まれていて、かつネイティブとなっている、セットトップボックスのＯＩＴＦ機能の一部を示している。これは、この埋込ＯＩＴＦシステムがセットトップボックスに局所的にインストールされて実行され、また、典型的には、販売時にはそのセットトップボックス内にプレインストールされている。これによって、セットトップボックスは、ハードウェア構造と実行用のプログラムコード要素群の少なくとも一方を備え、セットトップボックスの汎用プロセッサによって動作する場合には、ＯＩＴＦシステムの機能群を備える。それゆえ、埋込ＯＩＴＦシステムは、自身が所有する直接のユーザ対話を有し、これには、例えば、リモートコントロール、キーボード、マウス等があり、また、オーディオ／ビデオレンダリング機能、オプションとしてのグラビング（grabbing）機能、これには、例えば、ディスプレイ、スピーカ、カメラ、マイクがあり、あるいはホームネットワーク通信を通じて通過させることなく、他のオーディオ／ビデオレンダリング／グラビングデバイスと直接接続され得る。

図２は従来技術に従うＯＩＴＦ機能が実装されているセットトップボックス５０の概要を示している。このＯＩＴＦは、ＯＩＴＦ ＩＰＴＶフォーラムによって定義されるように、ＩＰＴＶとＩＭＳサービス群とをセットトップボックス５０へ提供することを担当する。図では、ホームネットワークインタフェース−ＩＭＳゲートウェイインタフェース（ＨＮＩ−ＩＧＩ）に基づく通信はＩＭＳセッション群に関連する。つまり、ＨＮＩ−ＩＧＩプレーヤイネーブラが、オーディオ／ビデオ（ＡＶ）プレーヤ、ブロードキャストアプリケーション、メディアプレーヤ及びＩＧ２０との間のインタフェースとして提供することができる。また、ユーザ管理、登録及びサービスディスカバリ（service discovery：サービス発見）及び選択（ＳＤ＆Ｓ）は、ＩＧ２０と通信するためにＨＮＩ−ＩＧＩメッセージングを使用する。これらの受信されるＨＮＩ−ＩＧＩメッセージ群は、一般的には、ＩＧ２０によってセッション開始プロトコル（ＳＩＰ）メッセージ群に変換され、このメッセージ群はローカルエリアネットワーク（ＬＡＮ）を通じてゲートウェイ１０へ転送され、そして、更に、図では、ワイドエリアネットワーク（ＷＡＮ）として表されるグローバルネットワーク２に送信される。この状況では、ＩＧ２０はハイパーテキスト転送プロトコル（ＨＴＴＰ）サーバとして動作することができ、また、ＯＩＴＦはＨＴＴＰクライアントとして動作することができる。これは、ＨＮＩ−ＩＧＩメッセージ群が、一般的には、ＨＮＩ−ＩＧＩ ＨＴＴＰリクエスト群あるいは応答群の形式であることを意味し、例えば、以下のようになる。

HTTP/1.1＜HTTP response＞
＜HTTP headers＞
＜X-OITF extension headers＞ or ＜X-HNI-IGI extension headers＞
Content-Type:＜...＞
Content-Length:＜Number＞
＜Message body＞
ＨＮＩ−ＩＧＩメッセージはＳＩＰタイプのメッセージとすることができ、ここで、このメッセージは、ＳＩＰメッセージに対応するＨＮＩ−ＩＧＩメッセージである。ＩＧ２０は、関連するヘッダ群を追加及び変更することによって、このメッセージを対応するＳＩＰメッセージに変換する。ＡＵＸタイプのＨＮＩ−ＩＧＩメッセージはＨＮＩ−ＩＧＩメッセージであり、これは、ＳＩＰメッセージには変換しない。これに代えて、ＩＧ２０は、このメッセージを処理して、それに従って応答する。ＨＮＩ−ＩＧＩメッセージングと、ＯＩＴＦとＩＧとの間の通信についての詳細な情報については、２００９年１月６日の、オープンＩＰＴＶフォーラム−リリース１仕様書、第４巻−プロトコル、Ｖ１．０を参照されたい。この情報の教示内容は、参照することによって本明細書に完全に組み込まれ、特に、セクション５．５はプロトコルシステムインフラストラクチャ機能群に関連し、セクション５．５．１はＯＩＴＦ−ＩＧインタフェース（ＨＮＩ−ＩＧＩ）に関連する。

これは、このような局所的にインストールされているＩＭＳアプリケーション群を持たないセットトップボックス５０と、ＩＧ２０との通信を行うロジック群が、ＩＰＴＶシステム群で現在利用可能である、あるいは将来設計されることになる、膨大な数の利用可能なＩＭＳサービス群を利用できないことを意味する。更に、セットトップボックス５０は、ＩＰＴＶとＩＭＳセッション群をリクエストし、セットアップし、そして管理する目的のために、ＩＧ２０と通信するために必要な機能が欠如している。

本明細書で開示される実施形態群は、伝統的なネイティブあるいは埋込ＩＭＳアプリケーション群を、スクリプト型ブラウザベースのＩＭＳアプリケーションに置き換える。ウェブブラウザ環境で実行させる、このようなスクリプト型のアプリケーション群は、従来では、ウェブアプリケーション群と時には呼ばれるものであり、特に、ＩＰＴＶ分野では宣言型アプリケーション環境（ＤＡＥ）アプリケーション群と呼ばれる。埋込ＩＭＳアプリケーションとは対照的に、スクリプト型のＩＭＳアプリケーションは、ウェブブラウザを介してネットワーク、例えば、インターネットあるいはイントラネットにアクセスする。スクリプト型のアプリケーションは、一般的には、ブラウザでサポートされる言語で符号化されているソフトウェアアプリケーションである。このスクリプト型のアプリケーションは、実行可能なアプリケーションを再現するためのウェブブラウザに依存している。

図３は本実施形態に従う、埋込ＯＩＴＦシステムとスクリプト型のＩＭＳアプリケーション４０を備えるセットトップボックス５０の概要である。この実施形態では、セットトップボックス５０と埋込ＯＩＴＦシステムに代えてＩＧ２０とのＨＮＩ−ＩＧＩシグナリングがブラウザページで動作するスクリプト型のＩＭＳアプリケーションを通じて実行される。

スクリプト型のＩＭＳアプリケーション４０は、ＤＡＥ環境で提供される、即ち、ブラウザが動作し、かつ好ましくは、ＩＧ２０とのＨＴＴＰインタフェースを使用する。これは、スクリプト型のＩＭＳアプリケーション４０は、セットトップボックス５０に代えてＩＧ２０とのシグナリングを達成するために、標準化ＨＴＴＰベースのインタフェース、即ち、ＨＮＩ−ＩＧＩを使用することができることを意味する。

図２と図３を比較することによって確認されるように、埋込ＯＩＴＦシステムとＩＧ２０との間の必要なＨＮＩ−ＩＧＩシグナリングは、ここでは、従来のように、埋込ＯＩＴＦシステム内の様々な機能群とＩＧ２０との間で行われる代わりに、スクリプト型のＩＭＳアプリケーションによって管理される。これは、図２の従来技術と比較して、図３のセットトップボックス５０は、任意のプレインストールされたネイティブあるいは埋込ＩＭＳアプリケーションとＩＭＳプロトコルスタックを持つ必要がないことを意味する。その結果、このスクリプト型のＩＭＳアプリケーション４０は、埋込ＯＩＴＦシステム及び機能群と、埋込アプリケーション群との間のゲートウェイとして動作する。ここで、埋込アプリケーション群は、ＩＭＳデータを処理するために使用されるものであり、例えば、プレーヤあるいはＡＶプレーヤ、及びＩＧ２０がある。

一般的には、ＩＭＳシグナリング機能は、こうして、セットトップボックス５０のネイティブあるいは埋込コード、あるいは構造群から、スクリプト型のＩＭＳアプリケーション４０へ移行されている。これは、サービスディスカバリ、加入及び登録用の機能が、埋込ＯＩＴＦシステムに代えてＩＧ２０に効果的に提供されることを意味する。しかしながら、これらの機能群が実行される実施形態群に制限する意図はない。一般的には、これらの機能のすべてあるいはいくつかの部分だけがＩＧ２０で実行することができる。これについては、更に必要な場合は、以下でより詳細に説明される。

図４Ａと図４Ｂは、セットトップボックスを起動する目的のためのＯＩＴＦ開始の実施形態を示すシグナリング図であり、その起動により、必要に応じて、ＩＰＴＶあるいはＩＭＳセッションをセットアップする準備をする。図では、「ＯＩＴＦ」は埋込ＯＩＴＦシステムを表していて、これは、一般的には、埋込あるいはネイティブコード及び機能群として提供され、これらは、典型的には、コンピュータあるいは処理ユニットの内部メモリに直接ロード可能なコンピュータプログラムとして提供され、また、これは、必要な機能群を実行するためのソフトウェアコード部分を備える。コンピュータは、固定あるいはポータブルであるかに関わらず、任意のデバイスあるいは端末を含むように広く解釈されるべきであり、これは、本明細書で記載される埋込ＯＩＴＦ機能を備えている。このようなコンピュータは、上述の任意のセットトップボックスの例とすることができる。「ＤＡＥ−ＩＭＳ」アプリケーションは、セットトップボックス内で動作するウェブブラウザ、即ち、ＤＡＥで動作するスクリプト型のＩＭＳアプリケーションを表している。典型的な実施形態では、埋込ＯＩＴＦシステムとスクリプト型のＩＭＳアプリケーションは同一の物理デバイスに存在しているが、選択的には、デバイス間との有線あるいは無線接続を有する異なるデバイス群に収容することができる。ＩＰＴＶ ＡＳは、ＩＰＴＶアプリケーションサーバを示していて、これは、図１のＩＰＴＶ（サービスプロバイダ）に対応する。

開始手順は、一般的には、埋込ＯＩＴＦシステムがまだ実行されていない場合に、その埋込ＯＩＴＦシステムをスタートアップすることによって開始する。これは、従来技術の手順に従って行われる。これに対応して、ＩＧは、ユーザ識別子群のプロビジョニングを行い、また、例えば、動的ホスト構成設定プロトコル（ＤＨＣＰ）を使用してスタートアップを行う。これは、ＩＰネットワークで動作するための構成設定情報を取得するために使用されるネットワークアプリケーションプロトコルである。ここで、特に、好ましい場合、ＩＧは、サービスディスカバリ情報を取得することに関連するＤＨＣＰオプション１２４と１２５を実装することができる。

一旦、埋込ＯＩＴＦシステムがスタートすると、自動的にスタートアップリクエストを発行することが好ましく、このリクエストは、スクリプト型のＩＭＳアプリケーション、より正確には、ウェブブラウザを、特定のアドレス、例えば、ＩＧのｈｔｔｐ：／／ＩＧ．ｆｉｘｅｄ．ｌｏｃａｌへ向けるための内部コールである。ここで、ＩＧは、時には、絶対ドメインネームとも呼ばれる固定の完全記述ドメインネーム（ＦＱＤＮ）を有していることが好ましい。ＦＱＤＮはドメインネームシステム（ＤＮＳ）のツリー階層の自身の実際の位置を指定するドメインネームである。この固定のＦＱＤＮはＩＧを指示し、そうすることで、ＩＧは、そのＦＱＤＮが自身を指示するためのＤＮＳサーバ自身として動作する。ＦＱＤＮは、好ましくは、開始手順が行われるそれぞれの時点かつ行われる毎に、埋込ＯＩＴＦシステムにＦＱＤＮを通知することをＩＧに対して要求することなく、そのＦＱＤＮを符号化できる、あるいは埋込ＯＩＴＦシステムコードあるいは構造に記憶することができるということを意味する不変なものである。選択的には、埋込ＯＩＴＦシステムは、スクリプト型のＩＭＳアプリケーションを使用するＩＧからあるいはいくつかの他のユニットからこのＦＱＤＮをリクエストしなければならない。

上述のメッセージ群をＩＧへルーティングする方法は、ＩＧが存在しない場合に、ＤＮＳサーバの役割を担うアクセスネットワークプロバイダがＩＧ ＦＱＤＮを解決して、それをウェブサーバへ指示できるという付加価値を有している。このウェブサーバは、例えば、ＩＰＴＶサービスへ加入者がどのようにして加入できるかについての商用情報を表示することができる。

受信したスタートアップリクエストに基づいて、ＩＧはユーザに表示するために、スクリプト型のＩＭＳアプリケーションに返信されるユーザ選択ページを提供する。このユーザ選択ページは、ＩＧにプレインストールすることができる、あるいはＩＧが、スタートアップリクエストの受信に基づいて、オンデマンドで生成する。このユーザ選択ページは、セットトップボックスを使用することができる利用可能なユーザの少なくとも１つのユーザ識別子を備え、これは、本実施形態では、ＯＩＴＦシステムに提供される。ユーザ識別子（群）は、ユーザ（群）の識別を可能にする、任意の識別子（群）あるいは情報とすることができる。非制限的な例としては、ユーザ名、所与の名前、及びオプションでは、名字、コンピュータによって生成された、ＩＭＳによって選択されるユーザ識別子等がある。

次に、スクリプト型のＩＭＳアプリケーションは、受信したユーザ選択ページをウェブブラウザによってセットトップボックスのディスプレイスクリーン装置あるいはそれに接続されているディスプレイスクリーン装置に提示する。ここで、ユーザは、ＩＧでプロビジョンされる異なるユーザから選択することができる。例えば、父、母、及び２人の子供からなる家族は、５つの異なるプロビジョンされるユーザを有することができる。これには、パーソナライズされていないデフォルトのユーザプロファイルが含まれる。ユーザは、ユーザが使用したい特定のユーザ識別子あるいは名前をクリックするあるいは選択する。ユーザの入力の起動は、例えば、マウスキー、タッチセンサ画面あるいはキーボードキーがあり、これは、選択されたユーザに関連付けられているユーザ識別子を含むユーザ選択コマンドを生成する。オプションでは、認証手順が開始され、ここでは、ユーザは選択されたユーザプロファイルへのアクセスを得るためにパスワードあるいはＰＩＮコードを入力することを要請される。この認証手順は、ＨＴＴＰ：４０１ 未承認メッセージを生成して、スクリプト型のＩＭＳアプリケーションへ送信し、そして、ユーザに対してＩＧへ返信されるパスワードあるいはＰＩＮコードを入力することを要請することによって行うことができる。

選択されたユーザがＩＧへ一旦通知されると、選択されたユーザに関する登録リクエストがＩＧによって作成される。登録リクエストは、好ましくは、ＳＩＰ：登録（ＲＥＧＩＳＴＥＲ）メッセージであり、これには選択されたユーザのユーザ識別子が含まれる。ＩＧは、この登録リクエストをＩＭＳへ送信する。ＩＭＳは、確認応答メッセージをＳＩＰ：２００ ＯＫの形式で返信する。このシグナリングは、従来技術においても行われるが、かなりの違いがある。つまり、ＩＧは、従来技術のような埋込ＯＩＴＦシステムに代えて、ＩＭＳへユーザ登録を行う。

これに対応して、ＩＰＴＶ ＡＳからの確認応答であるＳＩＰ：２００ＯＫでの返信に続く、典型的には、ＳＩＰ：加入（ＳＵＢＳＣＲＩＢＥ）メッセージの形式の加入者リクエストの、ＩＧによる生成及び送信を含む加入手順が実行される。ＩＰＴＶ ＡＳも、サービスディスカバリ及び選択（ＳＤ＆Ｓ）に関連するＳＩＰ通知（ＮＯＴＩＦＹ）メッセージを送信し、そして、ＩＧはＳＩＰ：２００ＯＫを送信することによってこれに応答する。本明細書における新規の特徴は、埋込ＯＩＴＦシステムでないＩＧが加入とＳＤ＆Ｓ通信にＩＰＴＶ ＡＳを用いて関与することである。

次に、ＩＧは、ＩＭＳサービス群を含むＩＰＴＶサービス群の情報を含むウェブページを作成する、これは、ＳＤ＆Ｓ通知を通じて、サービスプロバイダ、即ち、ＩＰＴＶ ＡＳから通知される、加入済かつ登録済のユーザに利用可能なものである。ＩＧは、更に、加入リクエストに応じて受信されるアドレス情報を、ＩＧを指示する変換済のアドレス情報に解決するあるいは変換する。例えば、ＩＧは、ＩＧにおいて指示するために、効果的に、ＩＰＴＶ ＡＳから受信される各ユニバーサルリソースロケータ（ＵＲＬ）をマッピングする。これは、各通知されるＵＲＬをＩＧにおけるローカルＵＲＬへマッピングすることによって、あるいは実際にＵＲＬ群を書き換えることによって行うことができる。

ＩＧは、オプションで、プロキシとして、トランスポートレイヤセキュリティ（ＴＬＳ）及び認証を取り扱うために、ＩＰＴＶ ＡＳからのＩＰＴＶサービス選択肢を実際のＩＰＴＶプロバイダを関連付けることもできる。

ＩＧにおいてサービスプロバイダ選択ページを作成して提供することの効果は、ＩＧが単一のＩＰＴＶサービスプロバイダあるいはＩＰＴＶ ＡＳからＩＰＴＶサービス選択肢を追加することだけでなく、異なるＩＰＴＶサービスプロバイダ群からもＩＰＴＶサービス選択肢を追加することができることである。例えば、ＩＧは通常のＡＤＳＬモデムにインストールするあるいは接続することができる。この場合、ＩＧは、実際にＩＰＴＶ ＡＳと通信するだけでなく、例えば、ＩＰＴＶセッション内のユーザへメディアサービス群を提供することができるケーブルＴＶプロバイダと通信することができる。これは、ＩＧが、様々な技術を含む複数の異なるサービスプロバイダ群から利用可能なサービス群の情報を収集して、この情報をユーザのウェブブラウザを使用してユーザに対して表示される単一の提示ページに作成することができることを意味する。

セットトップボックスのディスプレイスクリーン装置あるいはセットトップボックスに接続されるディスプレイスクリーン装置上のウェブブラウザでユーザに対して表示すべき作成されたサービスプロバイダ選択ページが、スクリプト型のＩＭＳアプリケーションへ送信される。表示されるウェブページは、ＳＤ＆Ｓ手順に基づいてＩＰＴＶ ＡＳによって提供されるＩＰＴＶサービス選択肢をリスト表示する。オプションでは、ＴＬＳ及び認証の少なくとも一方を処理することもできる。この表示されるウェブページは、様々なサービスプロバイダ識別子、利用可能なサービスプロバイダを識別し、かつ選択することをユーザに可能にする名前あるいは情報をリスト表示する。これらのサービスプロバイダ識別子は、ＩＧによって生成された変換済のアドレス情報であり得る、あるいはそうでなければサービスプロバイダ選択ページで提供され、かつＳＤ＆Ｓ手順で受信されるデータに基づいてＩＧによって提供される他の情報であり得る。

この実施形態の利点は、ＩＧがサービスプロバイダ群と、実際のＩＰＴＶでない選択情報を提示できることである。非ＩＰＴＶデータは、例えば、ケーブルＴＶ、デジタル地上ＴＶあるいは衛星ＴＶであっても良い。セットトップボックスのユーザがこれらのサービス群を選択する場合、それらのサービス群は、標準ＩＰＴＶ端末で、かつＩＰＴＶセッション内でサービスを実行するために、実際のオリジナルのフォーマットからＩＰＴＶフォーマットへ変換される。

次に、ユーザは、セットトップボックスのユーザ入力装置あるいはセットトップボックスに接続されているユーザ入力装置を起動することによって、サービスプロバイダ群の１つを選択する。ユーザ入力起動は、選択されたサービスプロバイダのプロバイダ識別子を含むサービスプロバイダコマンドを生成するために、スクリプト型のＩＭＳアプリケーションをトリガーする。実施形態では、サービスプロバイダコマンドは、サービスプロバイダ選択ページで提供される変換済あるいは書換済のＵＲＬ群に基づいて、スクリプト型のＩＭＳアプリケーションによって生成される。これらの変換済のＵＲＬ群は、オリジナルのＩＰＴＶアプリケーションサーバでなくＩＧを指示し、サービスプロバイダコマンドは、そのＩＧへ向けられることになる。

ＩＧは、選択されたサービスプロバイダに関連するデータをサービス選択メッセージの形式で返信する。サービス選択メッセージは、好ましくは、選択されたサービスプロバイダで利用可能なＩＰＴＶサービス群のアドレス情報を備える。サービス選択メッセージはスクリプト型のＩＭＳアプリケーションへ送信され、そこで、サービス記述ロードコマンドを生成して、埋込ＯＩＴＦシステムへ転送する。このサービス記述ロードコマンドは、例えば、サービスプロバイダのＵＲＬとタイプ情報を含んでいる。埋込ＯＩＴＦシステムは、好ましくは、確認応答あるいはＯＫメッセージを返信する。埋込ＯＩＴＦシステムは、また、ＩＰＴＶ ＡＳからディスカバリデータを取得するために、ＨＴＴＰリクエストも発行する。このディスカバリデータ、例えば、電子プログラムガイド（ＥＰＧ）の形式であっても良く、これは、サービスプロバイダから利用可能なＩＰＴＶコンテンツとメディアをリスト表示していて、例えば、時間、タイトル、チャネル、ジャンル等によってメディアコンテンツを案内して、選択させて、かつ発見することを可能にするものである。ＩＰＴＶ ＡＳにおいて利用可能なＩＰＴＶサービス群をユーザに通知する、他のタイプの記述情報も使用することができる。ＩＰＴＶ ＡＳは、ディスカバリデータを含む確認応答を、例えば、ＨＴＴＰ：２００ ＯＫメッセージの形式で返信する。

選択的には、ＩＧは別のサービスプロバイダをサービスプロバイダ選択ページ、例えば、ケーブルＴＶディストリビュータあるいはデジタルビデオブロードキャスティング（ＤＶＢ）コンテンツに追加する場合、ＨＴＴＰ取得ディスカバリデータがＩＧへ送信される、これは、ＩＧがディスカバリを自身に指示するからである。次に、ＩＧは、ディスカバリデータを含む確認応答を埋込ＯＩＴＦシステムへ返信することになる。

実施形態では、スクリプト型のＩＭＳアプリケーションが、ポータルページ、即ち、ＩＧへ送信されるサービスプロバイダコマンドで提供されるサービスプロバイダデータをロードするためにポータル通信メッセージを生成して、ＩＧへ送信する。ＩＧは、このリクエストをプロキシして、そして、そのＨＴＴＰポータルメッセージを、ＩＰＴＶ ＡＳへ送信されるＨＴＴＰセキュア（ＨＴＴＰ（Ｓ））ポータル通信へ変換することができる。オプションの汎用ブートストラッピングアーキテクチャ（ＧＢＡ）がセキュリティメカニズムを提供するために使用することができる。ＩＰＴＶ ＡＳは、次に、ＨＴＴＰ（Ｓ）：４０１ 未承認（ＵＮＡＵＴＨＯＲＩＺＥＤ）メッセージをＩＧへ返信する。これは、ＧＢＡセキュリティメカニズムが使用される場合での信用証明書情報の返信に続くものである。ＩＰＴＶ ＡＳは、また、ＩＧへの応答確認応答、ＨＴＴＰ（Ｓ）：２００ ＯＫによってＨＴＴＰ（Ｓ）ポータル通信の受信を確認する。この確認応答は、初期手順が成功していることを通知するために、ＩＧによってスクリプト型のＩＭＳアプリケーションへ転送される。

スクリプト型のＩＭＳアプリケーションは、好ましくは、いわゆるペンディングコマンド、例えば、ＨＮＩ-ＩＧＩペンディング＿ＩＧメッセージの形式で返信する。これは、ペンディングＨＴＴＰリクエストである。このリクエストは、ＩＧに、ネットワーク、例えば、ＩＰＴＶ ＡＳからの着信リクエストの結果として、埋込ＯＩＴＦシステムへ通信する必要がある場合に応答することを可能にする。

図４Ａ及び図４Ｂで示される上述の信号手順は、ユニバーサルプラグアンドプレイ（ＵＰｎＰ）を使用することなく実行することができる。ＵＰｎＰは、コンピュータプロトコル群のセットであり、これは、デバイス群に、切れ目のなく接続することを可能にし、かつデータ共有、通信およびエンターテイメント用のホームネットワークの実装を容易にすることを可能にする。デバイス群、即ち、セットトップボックス、及びＩＧ実装デバイスはＵＰｎＰを使用して互いに通信することができる場合、図５Ａ及び図５Ｂで示されるような多少異なる初期手順を使用することができる。

この手順は、図４Ａと同様に、埋込ＯＩＴＦシステムのスタートアップと、ＩＧのプロビジョニング及びスタートアップを伴って開始する。図４Ａで示されていない、図５Ａで示される後続の５つのシグナリングステップは、ＵＰｎＰシグナリングに関連する。つまり、この実施形態では、別のブートストラッピング手順が行われる。図４Ａの実施形態が固定のＩＧ ＦＱＤＮに基づいているのに対して、図５ＡはＵＰｎＰを使用する。それゆえ、この埋込ＯＩＴＦシステムは、ＵＰｎＰディスカバリプロトコルの一部を形成するＵＰｎＰサーチリクエストをコンパイルして、送信する。ＩＧは、ＩＧについてのいくつかの本質的な仕様群、特に、ＩＧについてのより詳細な情報に対するＵＲＬあるいはポインタを含む応答メッセージを返信する。

埋込ＯＩＴＦシステムがＩＧを発見した後、埋込ＯＩＴＦシステムは依然としてＩＧについてはかなりわずかしか知らない。ＩＧについてのより詳細な情報とそのケイパビリティを学習するために、あるいはＩＧと対話するために、埋込ＯＩＴＦシステムはＩＧの記述を、ディスカバリメッセージ、典型的には、ＨＴＴＰ：取得（ＧＥＴ）メッセージの形式で提供されるＵＲＬから取得する。ＩＧは、リクエストされた方法、例えば、サポートされる方法とそのＵＲＬ（ＩＧ ＵＲＬ）をＨＴＴＰ：２００ ＯＫ応答の形式で返信する。通知されたＩＧ ＵＲＬを含むＨＴＴＰ ＧＥＴメッセージは、スクリプト型のＩＭＳアプリケーションへ送信され、また、ＩＧへ転送される。

登録、加入及びＳＤ＆Ｓ手順を含む後続の手順が、図４Ａ及び図４Ｂに関して上述した方法と同一の方法で行われる。

次に、ＩＧはサービスプロバイダ選択ページをコンパイルして、そのコンパイルしたプロバイダ選択ページを、スクリプト型のＩＭＳアプリケーションによってウェブブラウザでユーザに提示する。選択されたサービスプロバイダの情報は、サービスプロバイダコマンドでＩＧへ返信される。この実施形態では、ＩＧは、サービスプロバイダデータ、例えば、ＨＴＴＰ：リダイレクト（ＲＥＤＩＲＥＣＴ）メッセージの形式にコンパイルして、それを、ＳＤ＆Ｓに基づいて提供され、かつウェブブラウザ上のスクリプト型のＩＭＳアプリケーションによって提示される、ウェブ提案あるいは提案ページへ送信する。図５Ｂの後続の通信は、図４Ｂと同様である。オプションの特徴であるＧＢＡセキュリティメカニズムは、図５Ｂで示される実施形態では省略している。

つまり、開示される信号図では、ＩＧは、管理されるサポート、例えば、登録手順を取り扱うことになり、また、ネイティブＨＮＩ-ＩＧＩサポートは要求されない。ＩＰＴＶ ＡＳに対して受信されるＳＤ＆ＳデータはＩＧによって解析され、かつセットトップボックスのスクリプト型のＩＭＳアプリケーションとウェブブラウザによってユーザに提示されるウェブページを生成するために使用される。

図４Ａから図５Ｂでは、ＩＰＴＶサービスプロバイダは、１つのエンティティ、即ち、ＩＰＴＶ ＡＳとして例示されている。選択的には、ＩＰＴＶサービスプロバイダは、専用のＩＰＴＶコントローラとＩＰＴＶアプリケーションを備えることができる。このような場合、ＳＤ＆Ｓ通信は、好ましくは、ＩＧとＩＰＴＶコントローラとの間で行われ、一方、ポータル通信は、ＩＧとＩＰＴＶアプリケーションとの間で実行される。

代替の方法では、埋込ＯＩＴＦシステムは、サービスディスカバリを行うことができる。そのような場合、サービスディスカバリは、ＤＨＣＰを用いるが、ＩＭＳを用いずに行うことができる。次に、ＩＧは、埋込ＯＩＴＦシステムからのＤＨＣＰに応答し、そして、ＩＭＳなしでサービスプロバイダディスカバリ情報を提示することになる。今日、ＤＨＣＰオプション１２４／１２５には３つのオプションがあり、それらは、ＩＰアドレス、ＤＮＳネームあるいはＩＭＳであり、後者は、管理ネットワーク群に対して使用される。これは、本実施形態で、ＩＭＳは必要とされないが、ＤＣＨＰに対する他のオプションを代わりに使用できることを意味する。

図４Ａと図５Ａは、様々な実施形態のブートストラップを示している。更に別の実施形態では、ＤＨＣＰはＩＧを検出するために使用される。このような実施形態は、ＤＣＨＰが使用されることになる以外は、ＵＰｎＰの実施形態と同様に動作する。

図６はビデオオンデマンド（ＶｏＤ）の形式でのＩＰＴＶセッションの一例である。従来のソリューションと比較して、図６に示されるＨＮＩ−ＩＧＩベースの通信は、図３と比べると、ウェブブラウザで動作するスクリプト型のＩＭＳアプリケーションとＩＧとの間で実行される。従来のソリューションは、ＨＮＩ−ＩＧＩ通信を達成するために埋込ＯＩＴＦシステム内に事前にネイティブコードを構成設定しているので、図２で参照されるように、埋込ＯＩＴＦシステムとＩＧとの間でＨＮＩ−ＩＧＩメッセージングを有する。

オプションのステップでは、スクリプト型のＩＭＳは、ユーザを変更する必要がある場合に、関連するユーザの識別子を含む、ＨＮＩ−ＩＧＩ：登録（ＲＥＧＩＳＴＥＲ）メッセージを送信する。ＩＧは、そのＨＮＩ−ＩＧＩメッセージを、ユーザ識別子を含む対応するＳＩＰ：登録メッセージに変換し、そして、それをＩＭＳへ送信する。登録したユーザを変更する必要がない場合、このシグナリングは省略することができる。

スクリプト型のＩＭＳアプリケーションは、ＩＰＴＶ ＡＳに対するサーバケイパビリティ群を問い合わせるために、ＨＮＩ−ＩＧＩ：オプション（ＯＰＴＩＯＮＳ）リクエストをコンパイルする。オプションリクエストは、典型的には、元々は、ウェブサーバから到来する、あるいはローカルのスクリプト型のＩＭＳアプリケーションから到来する。オプションリクエストは、好ましくは、リクエストされたＶｏＤデータ、例えば、ＵＲＬあるいは他のアドレス情報の形式での識別子を含んでいる。ＩＧは、ＨＧ−ＩＧＩメッセージを受信し、それを通常のＳＩＰ：オプションリクエストに処理して、それに含まれている識別子を識別子ＵＲＬ２に置換する。ＳＩＰ：オプションリクエストは、ＩＰＴＶ ＡＳへ送信され、ＩＰＴＶ ＡＳは、ＩＰＴＶセッションを開始するために、スクリプト型のＩＭＳアプリケーションによって利用される情報であるＳＤＰ１を含む、応答メッセージであるＳＩＰ：２００ ＯＫを返信する。添付されている情報には、セッション記述プロトコル（ＳＤＰ）フォーマットのセッション記述を含んでいることが好ましい。その応答はＩＧへ返信され、そこで、ＳＩＰ応答を対応するＨＮＩ−ＩＧＩ応答へマッピングし、そのメッセージをスクリプト型のＩＭＳアプリケーションへ転送する。

スクリプト型のＩＭＳアプリケーションは、ポートリクエストを用いて、埋込ＯＩＴＦシステムからＶｏＤセッションで使用されるビデオポート、及び好ましくはオーディオポートの情報をリクエストする。埋込ＯＩＴＦシステムは、リクエストされた情報、即ち、関連するビデオポート及びビデオポートの少なくとも１つのポート識別子を含む応答メッセージを返信する。

スクリプト型のＩＭＳアプリケーションはＨＮＩ−ＩＧＩ：招待（ＩＮＶＩＴＥ）メッセージを生成して、好ましくは、メディアデータが送信されるべきビデオポート及びオーディオポートの情報を含むＳＤＰ提案を含む、ＨＮＩ−ＩＧＩ：招待メッセージを送信する。この招待メッセージは、ＩＰＴＶセッションに対するリクエストを表している。ＩＧは招待メッセージを処理して、そして、それを、ＩＰＴＶ ＡＳに送信される、ＳＩＰ：招待メッセージに変換する。応答メッセージである、ＳＩＰ：２００ＯＫは、リクエストされたメディアのアドレス情報（ＵＲＬ２）を含む指定されたＳＤＰ回答を含み、これはＩＧへ返信される。ＩＧは、スクリプト型のＩＭＳアプリケーションへ送信する前に、その応答メッセージをＨＮＩ−ＩＧＩ：２００ＯＫ応答に変換する。

スクリプト型のＩＭＳアプリケーションは、ここで、ＨＮＩ−ＩＧＩ：２００ ＯＫ応答から受信されるメディアデータに関連付けられているアドレス情報へのアクセスを有している。スクリプト型のＩＭＳアプリケーションは、それゆえ、好ましくは、アドレス情報、即ち、ＵＲＬ２を伴う再生リクエストを生成し、そして、それを埋込ＯＩＴＦシステムへ送信することで、埋込ＯＩＴＦシステムに、メディアサーバ（ＭＳ）から、所望のメディアストリーム、即ち、ＶｏＤメディアストリームをリクエストさせる。この再生リクエストは、好ましくは、埋込ＯＩＴＦシステムによって実行されるべきセットアップ手順はないことを示す表示を含んでいる。これは、スクリプト型のＩＭＳアプリケーションは、既に、ＩＧとＩＰＴＶ ＡＳとのセットアップ手順を行っているからである。

リアルタイムストリーミング（ＲＴＳＰ）再生リクエストの形式のメディアリクエストが、次に、作成され、そして、埋込ＯＩＴＦシステムによってＵＲＬ２によって定義されるメディアサーバへ送信される。メディアサーバは、ＶｏＤデータのリクエストされたユニキャストストリームをＯＩＴＦシステムへ返信し、そこで、データは復号され、そして、搭載されているあるいは接続されているディスプレイスクリーン装置にビデオを表示し、かつ搭載されるあるいは接続されるスピーカで音声を再生するためにレンダリングされる。

ユーザがＶｏＤセッションの停止を選択する場合、ユーザはスクリプト型のＩＭＳアプリケーションによってウェブブラウザに提示されるウェブページの停止機能を起動して、メディアデータのレンダリングを停止するために、埋込ＯＩＴＦシステムに転送される停止メッセージを生成する。ＨＮＩ−ＩＧＩ：ＢＹＥメッセージの形式で、セッションを終了するためのリクエストも作成され、そしてＩＧへ送信される。ＩＧは、そのリクエストをＳＩＰ：ＢＹＥメッセージへ変換し、それは、セッションを終了し、メディアデータの配信を停止するためにＩＰＴＶ ＡＳへ送信される。ＳＰＩ：２００ ＯＫ応答がＩＧへ返信され、かつＨＮＩ−ＩＧＩ：２００ＯＫメッセージへ変換され、それは、セッションが終了していることを示すためにスクリプト型のＩＭＳアプリケーションへ転送される。

こうして、ウェブブラウザで動作するスクリプト型のＩＭＳアプリケーションは、従来技術とは比べて明らかに、ＩＧとのすべてのＨＮＩ−ＩＧＩシグナリングを行う。また、この情報をＩＧを介してＩＰＴＶ ＡＳへ転送するために、ポートのプレフェッチング（pre-fetching：事前フェッチ）を達成する。このスクリプトは、また、指定の表示を含むＲＴＳＰシグナリングの表示を生成する。この指定の表示は、埋込ＯＩＴＦシステムによって開始されるべきＲＴＳＰ：セットアップ（ＳＥＴＩＵＰ）手順はないという表示である。

図７は、ＩＰＴＶセッションをセットアップし、かつ管理する別の実施形態を示す信号図である。この例では、いわゆるスケジュールされたコンテンツセッションが示されている。スケジュール化されたコンテンツは、ユーザ以外のエンティティによって再生スケジュールが決定され、かつコンテンツを即時に消費するためにユーザに配信される場合に関係している。これは、様々なＴＶあるいはメディアチャネル群をユーザへ提供する形式とすることができる。マルチキャストは、一般には、ＩＰＴＶ内のスケジュールされているコンテンツサービス群を配信するために使用されるが、上述したように、配信元は、ＩＰＴＶに限定されるものではなく、むしろ、非ＩＰＴＶサービスプロバイダ群、例えば、ケービルＴＶ、デジタル地上テレビ、あるいは衛星ＴＶであっても良く、ここで、ＩＧは、図４Ｂに関して説明されるサービスプロバイダ選択ページに加入している。

この手順は、必要であれば、オプションのユーザ登録手順で開始する。

この例では、利用可能なメディアチャネル群は、事前に、ＩＧであるネットワーク、即ち、ＩＰＴＶ ＡＳによる通信を通じて、あるいはローカルＤＡＥインタフェースによる通信を通じて、スクリプト型のＩＭＳアプリケーションに知られている。スクリプト型のＩＭＳアプリケーションは、指定のＳＤＰ提案を含むＨＮＩ−ＩＧＩ：招待メッセージをコンパイルして、それをＩＧへ送信し、更に、ＩＧは、それを、ＩＰＴＶ ＡＳに向けられる、対応するＳＩＰ：招待メッセージに変換する。ＩＰＴＶ ＡＳは、受信したメッセージに基づいて、指定のＳＤＰ回答を含むＳＩＰ：２００ＯＫ応答を生成する。この応答は、ＩＧによって対応するＨＮＩ−ＩＧＩ応答に処理され、そして、スクリプト型のＩＭＳアプリケーションへ送信される。

ＩＧから受信されるセッション記述メッセージは、メディアソースからメディアデータに関連付けられているアドレス情報を提供するために、スクリプト型のＩＭＳアプリケーションによって使用される。この実施形態では、関連するアドレス情報は、所望のメディアチャネルであり、好ましくは、メディアチャネルのインターネットグループ管理プロトコル（ＩＧＭＰ）アドレスの形式である。関連するメディアチャネルアドレスは、設定チャネルコマンドで、埋込ＯＩＴＦシステムへ通信される。埋込ＯＩＴＦシステムは、この情報を、メディアリクエストをコンパイルして、マルチキャストソース、即ち、メディアサーバへ送信するために使用する。このメディアリクエストは、ここでは、ＩＧＭＰ：参加（ＪＯＩＮ）リクエストによって表される。これによって、埋込ＯＩＴＦシステムを収容するセットトップボックスは、マルチキャストチャネルあるいはブロードキャストチャネルに参加して、マルチキャストストリームのメディアデータの受信を開始する。この受信するデータは復号され、ユーザに対して表示及び再生するためにレンダリングされる。

ユーザはメディアセッション中にチャネルの変更を希望する場合、ユーザは単に、スクリプト型のＩＭＳアプリケーションによってウェブブラウザで提示されるウェブページ上で、他の利用可能なメディアチャネル群の１つを選択する。スクリプト型のＩＭＳアプリケーションは、次に、新規のメディアチャネルのＩＧＭＰアドレスを含む新規の設定チャネルコマンドをコンパイルして、埋込ＯＩＴＦシステムへ送信する。複合ＩＧＭＰ：離脱／参加（ＬＥＡＶＥ／ＪＯＩＮ）メッセージ、あるいは、ＩＧＭＰ：離脱メッセージとＩＧＭＰ：参加メッセージとがコンパイルされて、マルチキャストソースへ送信される。そうすることで、マルチキャストソースに、古いチャネルのメディアデータの配信を停止させ、代わりに、新規のチャネルのメディアデータの配信を開始させる。

次に、ユーザがメディアセッションの停止を希望する場合、ユーザは、ウェブページ上の停止機能を起動する。そうすることで、図６で上述したように、ＨＮＩ−ＩＧＩ：ＢＹＥメッセージの生成及び送信を行う。スクリプト型のＩＭＳアプリケーションは、また、解放メッセージを通じてセッションを終了することを埋込ＯＩＴＦシステムへ指示する。

上述の実施形態では、メディアチャネルは、ＩＧＭＰアドレスに基づいて設定される。その場合、必要なデータとパラメータ群はブロードキャストディスカバリレコードからフェッチすることができる。これは、スクリプト型のＩＭＳアプリケーションによってＸＭＬ文書を読み取ることによって実行することができる。

図８は別の方法を示していて、ここでは、ブロードキャストディスカバリレコードが埋込ＯＩＴＦシステムに含まれる。スクリプト型のＩＭＳアプリケーションは、埋込ＯＩＴＦシステムあるいはコードからＨＮＩ−ＩＧＩ：招待で使用される、ＳＤＰデータ、特に、ＩＧＭＰアドレスをリクエストする。これは、選択されたメディアチャネルの所望のＩＧＭＰアドレスが、そのメディアチャネルに含まれる識別子に基づいてリクエストされることを意味する。この識別子は、図４Ａ−図５Ｂに関して説明されるように、セットアップ手順からスクリプト型のＩＭＳアプリケーションへ提供される。埋込ＯＩＴＦシステムは、リクエストされた情報を含むＳＤＰを返信する。

スクリプト型のＩＭＳアプリケーションは、オプションで、埋込ＯＩＴＦシステムから、所望のチャネルの帯域幅特性の情報をリクエストすることができる。埋込ＯＩＴＦシステムは、好ましくは、このような帯域幅の情報、例えば、最大ビットレート（ＭＢＲ）と目標送信レート（ＴＴＲ）を返信する。

残りの手順は、チャネルの変更がユーザによって開始される場合に、新規のオプションの帯域幅の情報リクエストが、好ましくは、スクリプト型のＩＭＳアプリケーションによってコンパイルされ、かつ埋込ＯＩＴＦシステムへ送信されること以外は、図７で説明したものと同一である。

図４−図８の信号図で開示される上述の実施形態は、例示のものとして示されるべきであり、この実施形態はこれに制限されるものではない。例えば、上述のメッセージタイプ群とシグナリングプロトコル群は、現在の標準的な状況に基づいている。従来では、規格群に関連する開発中のものが存在する。つまり、これらに代えて、上述で記載される所望の効果を達成するために使用することができる他のメッセージングタイプ群と標準プロトコル群を、実施形態の範囲内で使用することができる。

つまり、ＩＰＴＶセッションをセットアップする一般的な実施形態では、この方法は、セットトップボックスで実現されるウェブブラウザにおいて、スクリプト型のＩＭＳアプリケーションを実行することを含んでいる。スクリプト型のＩＭＳアプリケーションは、セットトップボックスのユーザ入力装置の起動あるいはセットトップボックスに接続されるユーザ入力装置の起動に基づいて、ＩＰＴＶセッションセットアップ信号群を生成する。セッションセットアップ信号群は、ホームネットワーク内に存在するセットトップボックスに接続されているＩＧへ通信される。スクリプト型のＩＭＳアプリケーションは、更に、ＩＧから、ホームネットワークに接続されるグローバルネットワーク内のメディアサーバから利用可能なメディアデータに関連付けられているアドレス情報を受信する。このアドレス情報は、スクリプト型のＩＭＳアプリケーションからセットトップボックスの埋込ＯＩＴＦシステムへ転送され、これによって、ＩＰＴＶセッション内で、メディアデータに対するメディアリクエストであって、メディアサーバに向けられているメディアリクエストの生成をトリガーする。

特定の実施形態では、スクリプト型のＩＭＳアプリケーションは、図４Ａで示される埋込ＯＩＴＦシステムからのスタートアップリクエストを受信し、かつそのスタートアップリクエストをＩＧへ転送する。それによって、ユーザ選択ページの生成をトリガーする。この方法は、更に、利用可能なユーザ群の少なくとも１つの識別子を含むユーザ選択ページの、スクリプト型のＩＭＳアプリケーションにおける受信を有する。スクリプト型のＩＭＳアプリケーションは、ウェブブラウザによってユーザ選択ページをディスプレイスクリーン装置上に提示し、セットトップボックスのユーザ入力装置の起動に基づいて生成された、選択されたユーザのユーザ識別子を含むユーザ選択コマンドをＩＧへ送信する。

この方法は、スクリプト型のＩＭＳアプリケーションにおいて、グローバルネットワークからユーザに利用可能なサービスプロバイダ群に関連付けられている各プロバイダ識別子を含むサービスプロバイダ選択ページをＩＧから受信することを有する。しかしながら、これらのプロバイダ識別子は、サービスプロバイダ群に代えて、ＩＧに対して指示するためにＩＧによって指定される。スクリプト型のＩＭＳアプリケーションは、選択されたサービスプロバイダのプロバイダ識別子を含むサービスプロバイダコマンドを送信する。このサービスプロバイダコマンドは、セットトップボックスのユーザ入力装置の起動に基づいて生成され、そして、ＩＧへ送信される。

この方法は、好ましくは、更に、スクリプト型のＩＭＳアプリケーションにおいて、選択されたサービスプロバイダに利用可能なＩＰＴＶサービス群のアドレス情報を含むサービス選択メッセージをＩＧから受信することを有する。スクリプト型のＩＭＳアプリケーションは、このアドレス情報を含むサービス記述ロードコマンドをコンパイルして、そして、埋込ＯＩＴＦシステムへ送信する。

更なる方法のステップには、グローバルネットワークから埋込ＯＩＴＦシステムへ任意の着信リクエスト群を転送することをＩＧに実現可能にするために、スクリプト型のＩＭＳアプリケーションからペンディングＨＴＴＰリクエストを含むペンディングコマンドの送信を含んでいる。

特定のＩＰＴＶセッションがＶｏＤのようなメディアオンデマンドを含んでいる場合、この方法は、更に、スクリプト型のＩＭＳアプリケーションから埋込ＯＩＴＦシステムへポートリクエストを送信することと、セットトップボックスの少なくとも１つのメディアポートのポート識別子を含む招待メッセージを選択されたサービスプロバイダへ送信することを有し、ここで、招待メッセージは、埋込ＯＩＴＦシステムからの少なくとも１つのポート識別子を含む応答メッセージに基づいてスクリプト型のＩＭＳアプリケーションによって生成されている。

この場合、スクリプト型のＩＭＳアプリケーションによるアドレス情報の転送には、埋込ＯＩＴＦシステムへ、メディアサーバにおいて利用可能なリクエストされたメディアデータに関連付けられているアドレス情報を含む再生リクエストを送信することを含んでいる。この再生リクエストは、更に、ＩＰＴＶセッションが既にスクリプト型のＩＭＳアプリケーションによってセットアップされていて、また、ここでは、埋込ＯＩＴＦシステムによって実行されるべきセットアップ手順がないことを示す表示を含んでいる。

例示のメディアデータタイプとしてスケジュールされたコンテンツを含むＩＰＴＶセッションに向けられている別の実施形態では、スクリプト型のＩＭＳアプリケーションは、セッション記述メッセージをＩＧから受信し、このメッセージは、マルチキャストあるいはブロードキャストのチャネル情報の形式のアドレス情報を含んでいる。埋込ＯＩＴＦシステムへのアドレス情報の転送には、マルチキャストあるいはブロードキャストメディアチャネルへ参加するために埋込ＯＩＴＦシステムをトリガーするために、マルチキャストあるいはブロードキャストチャネル情報をへ送信することを含んでいる。

ＩＰＴＶセッションをセットアップする一般的な方法でＩＧによって行われる動作ステップ群には、セットトップボックスのユーザのユーザ識別子を含む登録リクエストをＩＭＳへ送信することを含んでいる。ＩＧは、また、ＩＰＴＶサービスプロバイダに向けられている加入リクエストを送信し、そして、それの応答でアドレス情報を受信し、ここで、このアドレス情報は、グローバルネットワークからユーザに利用可能なＩＰＴＶサービス群に関連するものである。ＩＧは、アドレス情報を、サービス群に関連付けられているが、ＩＧを指示している、変換済のアドレス情報にマッピングする。これは、変換済のアドレス情報に基づくサービスリクエストの生成及び送信は、サービスリクエストをＩＧへ案内することになるが、ＩＰＴＶサービスプロバイダへは案内しないことを意味する。変換済のアドレス情報はウェブページにコンパイルされ、このウェブページは、ＩＧによって、セットトップボックスにおけるウェブブラウザで動作するスクリプト型のＩＭＳアプリケーションへ送信される。

特定の実施形態では、ＩＧは、少なくとも１つのいわゆる補助サービスプロバイダに関連付けられている補助アドレス情報を、ＩＰＴＶサービスプロバイダからのアドレス情報に追加する。これは、ＩＧに、上述の現在のＩＰＴＶセッション内で選択することができ、かつ実行することができる、更なるサービス群をユーザに提示する。補助アドレス情報は、補助サービスプロバイダ（群）に関連付けられていて、かつＩＧを指示する変換済の補助アドレス情報に変換されるあるいはマッピングされる。変換済の補助アドレス情報は、次に、スクリプト型のＩＭＳアプリケーションへ送信すべきウェブページを生成する場合に、変換済のアドレス情報と組み合わせられる。

特定の実施形態では、この方法は、更に、セットトップボックスからのユーザ選択リクエストに応じて、セットトップボックスに対して潜在的に利用可能な複数のユーザのユーザ識別子を含むウェブページをＩＧが生成することを有している。ＩＧは、次に、ウェブブラウザを使用して、スクリプト型のＩＭＳアプリケーションによって表示用のユーザ識別子を含むウェブページを返信する。

また、ＩＧが上述のセットトップボックスからペンディングＨＴＴＰリクエストを含むペンディングコマンドを一旦受信すると、ＩＧは、グローバルネットワークからの任意の着信リクエスト群をセットトップボックスの埋込ＯＩＴＦシステムへ送信することになる。

図９は、ホームネットワーク内のセットトップボックスに実装されるように構成されているＩＭＳアプリケーション４０のブロック図である。ＩＭＳアプリケーション４０は、セットトップボックスで実現されるウェブブラウザによって動作するように構成されているスクリプト型のＩＭＳアプリケーション４０である。スクリプト型のＩＭＳアプリケーション４０は、一般的には、ブラウザでサポートされる言語でコード化されているソフトウェアアプリケーションであり、この言語には、例えば、ＪａｖａＳｃｒｉｐｔ、Ｊａｖａ、ＥＣＭＡｓｃｒｉｐｔ、Ｆｌａｓｈ、ＡｃｔｉｖｅＸ等がある。スクリプト型のＩＭＳアプリケーション４０は、実行可能なアプリケーションを再現するためのウェブブラウザに依存する。特定の実施形態では、スクリプト型のＩＭＳアプリケーション４０は、ダウンロードされたＨＴＭＬ／ＪＳページからＸＭＬＨｔｔｐＲｅｑｕｅｓｔを通してブラウザページ内のＪａｖａＳｃｒｉｐｔ（ＪＳ）で提供することができる。非同期ＪａｖａＳｃｒｉｐｔとＸＭＬ（ＡＪＡＸ）は、ＸＭＬＨｔｔｐＲｅｑｕｅｓｔを通じて必要なスクリプト型のＩＭＳ機能を達成するために使用することができる。ＡＪＡＸは、インタラクティブなウェブアプリケーション群あるいは豊かなインターネットアプリケーション群を作成するために使用されるウェブ開発技術である。ＡＪＡＸを使用することによって、スクリプト型のＩＭＳアプリケーション４０を含むウェブアプリケーション群は、既存のページの表示と挙動を干渉することなく、バックグランドで非同期にサーバからデータを取得することができる。データはＸＭＬＨｔｔｐＲｅｑｕｅｓｔオブジェクトを使用して取得され、ここで、ＸＭＬＨｔｔｐＲｅｑｕｅｓｔはアプリケーションプログラミングインタフェース（ＡＰＩ）であり、これは、ＨＴＴＰリクエストを直接ウェブブラウザ、例えば、ＩＧへ送信し、かつウェブブラウザスクリプティング言語に直接サーバ応答をロードするために、ＪａｖａＳｃｒｉｐｔのようなウェブブラウザスクリプティング言語内で使用することができる。

特定の実施形態では、スクリプト型のＩＭＳアプリケーション４０は、ＩＰＴＶセッションをセットアップし制御するためのＩＧに向けられているＩＰＴＶセッション信号群を生成するように構成されている信号ジェネレータ４２の機能を備えている。信号ジェネレータ４２は、好ましくは、ＨＴＴＰ信号プロトコルと、特に、ＩＰＴＶセッション群用に定義されているＨＴＴＰベースのＨＮＩ−ＩＧＩ信号プロトコルを使用して、そのようなＩＰＴＶセッションシグナリングを行うように構成されている。

スクリプト型のＩＭＳアプリケーション４０は、また、セットトップボックス内の埋込ＯＩＴＦシステムにアドレス情報を提供するように構成されているアドレスプロバイダ４４の機能を有する。このアドレス情報は、グローバルネットワーク内のメディアサーバから利用可能なリクエストされたメディアデータに関連付けられていて、また、ＩＧから受信されている。

図１０は、ホームネットワークにおける構成及び動作に対して適している、セットトップボックス５０あるいは他のユーザ機器、端末あるいはデバイスの実施形態のブロック図である。セットトップボックス５０は、他のデバイス群、特にＩＧと通信するためのユニットあるいは機能を備える。このユニットは、図では通信インタフェース５２として表わされ、これは、一般的な入出力（Ｉ／Ｏ）ユニットとして動作する。実際には、通信インタフェース５２は、外部デバイス及びリモートデバイスとの有線接続のための一般的な入出力インタフェースであり得り、あるいは、無線接続用の受信機／送信機あるいは送受信機の形式であり得る。

セットトップボックス５０は、好ましくは、図９で定義されるような、スクリプト型のＩＭＳアプリケーション４０を備える。スクリプト型のＩＭＳアプリケーション４０は、セットトップボックス５０で実現されるウェブブラウザ５４によって動作するように構成されている。このウェブブラウザ５４は、本明細書で開示されるＤＡＥを表しており、一般的には、セットトップボックス５０に局所的にインストールされ動作するソフトウェアプログラムの形式で提供される。また、ハードウェア利用も可能であり、これは実施形態の範囲に含まれる。ウェブブラウザ５４は、特に、典型的には、通信インタフェース５２を通じて、セットトップボックスと接続されるディスプレイスクリーン装置あるいはセットトップボックスのディスプレイスクリーン装置に表示可能なウェブページ群を生成するように構成されている。セットトップボックス５０は、また、埋込ＯＩＴＦシステム５６を備え、これは、ハードウェア、ソフトウェアあるいはそれらの組み合わせで提供することができる。ソフトウェア実装では、埋込ＯＩＴＦシステム５６は、コンピュータあるいは他の処理ユニット上で動作させる場合に、埋込ＯＩＴＦシステム５６の機能群を達成するコンピュータプログラム要素群を備える。この埋込ＯＩＴＦシステム５６は、スクリプト型のＩＭＳアプリケーション４０と、特に、スクリプト型のＩＭＳアプリケーション４０のアドレスプロバイダ４４（図９参照）から受信されるアドレス情報に基づいてメディアリクエストを生成するように構成されている。埋込ＯＩＴＦシステム５６によって生成されるメディアリクエストは、ＩＰＴＶセッション内で再現されるメディアデータに対するものであり、また、グローバルネットワーク内で存在するメディアサーバに向けられている。

通信インタフェース５２は、特に、ＩＧとのＨＴＴＰベースの通信、好ましくは、セットトップボックス５０のスクリプト型のＩＭＳアプリケーション４０とＩＧとの間のＨＴＴＰベースのＨＮＩ−ＩＧＩ通信を行うように構成されている。

通信インタフェース５２は、好ましくは、ＩＧから、スクリプト、例えば、ＨＴＴＰ／ＪＳページを受信するように構成されていて、これは、ＩＭＳとＩＰＴＶセッション群、即ち、スクリプト型のＩＭＳアプリケーション４０を実現するために必要な機能群を提供する。受信したスクリプトデータは、ウェブブラウザ５４あるいはＤＡＥアプリケーションへ転送され、そこで、ＩＴＰＶセッションに関連する情報をウェブブラウザ５４内でユーザに対して表示することになるブラウザ環境が実現され動作する。

スクリプト型のＩＭＳアプリケーション４０は、典型的には、一旦起動されると、埋込ＯＩＴＦシステム５６からスタートアップリクエストを受信するように構成されている。次に、スクリプト型のＩＭＳアプリケーション４０は、ユーザ選択ページの生成をＩＧにおいて開始するために、スタートアップリクエスト、例えば、ＩＧを指示する固定のＦＱＤＮを転送する。通信インタフェース５２がこのユーザ選択ページをＩＧから一旦受信すると、それは、セットトップボックス５０のディスプレイスクリーン装置あるいはセットトップボックス５０に接続されているディスプレイスクリーン装置上のウェブブラウザ５４によって表示するためにスクリプト型のＩＭＳアプリケーション４０に提示される。次に、ユーザは、意図されるユーザを指示するために、通信インタフェース５２との有線接続あるいは無線接続でユーザ入力を起動する。このユーザ入力の起動は、選択されたユーザのユーザ識別子を含むユーザ選択コマンドを生成するためにスクリプト型のＩＭＳアプリケーション４０をトリガーする。このユーザ選択コマンドは、通信インタフェース５２によってＩＧへ送信される。

スクリプト型のＩＭＳアプリケーション４０は、更に、好ましくは、通信インタフェース５２から、ＩＧから発信しているサービスプロバイダ選択ページを受信する。サービスプロバイダ選択ページは、グローバルネットワーク内に存在するサービスプロバイダ群のそれぞれのプロバイダ識別子を含んでいる。これらのプロバイダ識別子群は、それぞれのサービスプロバイダに関連付けられていて、また、ＩＧによってＩＧを指示するように設計されている。サービスプロバイダ選択ページは、ユーザ選択ページと同様にユーザに表示される。接続されているユーザ入力の起動は、スクリプト型のＩＭＳアプリケーション４０による、ＩＧに向けられているサービスプロバイダコマンドであって、選択されたサービスプロバイダのプロバイダ識別子を含むサービスプロバイダコマンドの生成をトリガーする。

スクリプト型のＩＭＳアプリケーション４０は、好ましくは、選択されたサービスプロバイダ群で利用可能なＩＰＴＶサービス群のアドレス情報を含むサービス選択メッセージを受信する。サービス選択メッセージは、ＩＧから生じるものであり、また、ＩＰＴＶサービス群の関連アドレス情報を含むサービス記述ロードコマンドを生成するためのスクリプト型のＩＭＳアプリケーションによって採用される。このサービス記述ロードコマンドは、埋込ＯＩＴＦシステム５６へ転送される。

ＩＰＴＶセッションが一旦セットアップすると、スクリプト型のＩＭＳアプリケーション４０は、好ましくは、ペンディングＨＴＴＰリクエストを含むペンディングコマンドを生成して、ＩＧへ送信する。ＩＧは、次に、ペンディングＨＴＴＰリクエストに基づいて、グローバルネットワークから生じる任意の着信リクエスト群を埋込ＯＩＴＦシステム５６へ転送することになる。

スクリプト型のＩＭＳアプリケーション４０は、好ましくは、進行中のＩＰＴＶセッション中に、特に、メディアオンデマンドＩＰＴＶセッション中に、ポートリクエストを生成して、埋込ＯＩＴＦシステム５６へ送信する。埋込ＯＩＴＦシステム５６は、セットトップボックス５０の少なくとも１つのメディアポートのリクエストされたポート識別子（群）を含む応答メッセージで応答する。スクリプト型のＩＭＳアプリケーション（４０）はポート識別子（群）を含む招待メッセージを生成し、そして、通信インタフェース５２とＩＧによって選択されたサービスプロバイダに送信される。

メディアサーバから利用可能なメディアデータに関連付けられているアドレス情報へのアクセスをスクリプト型のＩＭＳアプリケーション４０が一旦取得すると、メディアオンデマンドＩＰＴＶセッション中に、ＩＭＳアプリケーション４０は、再生リクエストを生成して、埋込ＯＩＴＦシステム５６へ送信する。この再生リクエストはアドレス情報を含み、好ましくは、埋込ＯＩＴＦシステム５６によって実行されるべきセットアップ手順がないことを示す表示を含んでいる。これは、セットアップ手順が、既に、スクリプト型のＩＭＳアプリケーション（４０）とＩＰＴＶサービスプロバイダとの間で行われているからである。

メディアデータのマルチキャスティングあるいはブロードキャスティングを含むスケジュールされたコンテンツＩＰＴＶセッションあるいは同様のセッションでは、スクリプト型のＩＭＳアプリケーション４０は、ＩＧから、メディアデータのアドレス情報を含むセッション記述メッセージを受信するように構成されている。この場合、アドレス情報は、メディアサーバから利用可能なマルチキャストあるいはブロードキャストメディアチャネルのアドレス情報の形式である。このアドレス情報は、マルチキャストあるいはブロードキャストメディアチャネルに参加するための埋込ＯＩＴＦシステム５６をトリガーするために、埋込ＯＩＴＦシステム５６へ送信される。

別の実施形態では、あまり一般的ではないが、ウェブブラウザアプリケーション５４と埋込ＯＩＴＦシステム５６は、異なるセットトップボックスで実現することができる。これらの異なるセットトップボックスは、通信インタフェース５２を介して、有線であるいは無線で互いに接続される。

加えて、セットトップボックス５０は、受信したメディアコンテンツを復号してレンダリングするための機能を有するメディアプロセッサを備えていても良く、あるいはそのメディアプロセッサに有線であるいは無線で接続されていても良い。セットトップボックスあるいはメディアプロセッサは、メディアを表示するためのディスプレイスクリーン装置を備えるあるいはディスプレイスクリーン装置に接続されていて、好ましくは、メディアを再生するためのスピーカを備えるあるいはスピーカに接続されている。

図１１は、ＩＧ２０の実施形態の外観である。ＩＧ２０は、典型的には、図１に示されるホームネットワークで実現され、これによって、ホームネットワーク内に提供されるセットトップボックス（群）とホームネットワーク内で通信する。ＩＧ２０は、スタンドアローンデバイスとしてホームネットワーク内に存在することができる。選択的には、ホームネットワークとグローバルネットワークとの間のプロキシ機能を構成する図１のゲートウェイとともに実現される。このようなプロキシ機能は、モデムあるいは他のプロキシユニットによって達成することができる。ホームネットワークのセットトップボックス群の１つにおいて実現されるＩＧ２０を実際に有することも可能である。

基本的に異なる実現方法では、ＩＧ２０はホームネットワーク内ではなくグローバルネットワーク内で実現され、例えば、グローバルネットワークの個別のネットワークエンティティあるいはサーバとしてアクセスプロバイダあるいはＩＰＴＶプロバイダ内で実現される。ホームネットワークあるいはグローバルネットワークで実現されるかに関わらず、ＩＧ２０は、ＨＴＴＰ通信とＳＩＰ通信との間を変換するための機能を依然として提供し、かつＩＭＳとＩＰＴＶアプリケーションサーバと通信することができる。ホームネットワーク内で実現される場合、ＩＧ２０は、自身が発信側である場合には、ＨＴＴＰシグナリングを終了し、かつＳＩＰシグナリングをセットアップする。これは、スクリプト型のＩＭＳアプリケーションがネットワークアドレス変換（ＮＡＴ）ユニットの配下にあるという事実を隠蔽するものである。ネットワークで実現されるＩＧ２０はプロキシとして動作し、スクリプト型のＩＭＳアプリケーションへのかつからのルーティング情報を保持する。ＩＭＳは、ＮＡＴに関する問題を取り扱うことができる。

ＩＧ２０は、ホームネットワーク内の他のデバイス群と通信するためのユニットあるいは機能を備え、これには、特に、セットトップボックスがあり、かつこれは、好ましくは、オプションで、ゲートウェイ経由で、グローバルネットワーク内のユニット群あるいはサーバ群と接続している。このユニットは、図では汎用のＩ／Ｏユニットとして動作する通信インタフェース２１として表される。特に、通信インタフェース２１は、外部デバイス及びリモートデバイスと有線接続するための汎用の入出力インタフェースであっても良く、あるいは無線接続用の受信機／送信機あるいは送受信機の形式であっても良い。

ＩＧは、セットトップボックスの選択されたユーザのユーザ識別子を備える登録リクエストを生成するように構成されている登録プロセッサ２２を備える。この登録リクエストは、ＩＭＳに向けられているものであり、また、通信インタフェース２１によってＩＭＳへ送信される。加入プロセッサ２３は、グローバルネットワーク内の選択されたＩＰＴＶサービスプロバイダに向けられる加入リクエストを生成するように構成されている。この加入リクエストは、ＩＰＴＶサービス情報のアドレス情報を、好ましくは、ＳＤ＆Ｓデータの形式で受信することをＩＧ２０に可能にする。このアドレス情報は、ＩＧ２０を指示するのではなく、ＩＰＴＶサービスプロバイダに関連付けられている変換済のアドレス情報に受信したアドレス情報をマッピングするために、ＩＧ２０のアドレス変換プロセッサ２４によって利用される。ページ構築プロセッサ２５は、ウェブページを生成するために変換済のアドレス情報を使用する。このウェブページは、即ち、通信インタフェースによって、そのセットトップボックスへ送信され、その中のスクリプト型のＩＭＳアプリケーションで動作するサービスプロバイダ選択ページである。

特定の実施形態では、アドレス変換プロセッサ２４は、ＩＰＴＶセッション内で潜在的に動作し、かつ提供され得るメディアサービス群を有する他のサービスプロバイダ群に関連付けられている補助アドレス情報をマッピングするように構成されている。このアドレス変換プロセッサ２４は、これによって、ＩＧ２０を指示しているが、そのような他のサービスプロバイダ（群）に関連付けられている変換済の補助アドレス情報を生成する。ページ構築プロセッサ２５は、ウェブページを生成する場合には、また、この変換済の補助アドレス情報を使用する。

オプションであるが、好ましい、ＨＴＴＰーＳＩＰ変換プロセッサ２６がＩＧ２０内で実現され、また、このＨＴＴＰーＳＩＰ変換プロセッサ２６は、スクリプト型のＩＭＳアプリケーションからのＨＮＩ−ＩＧＩメッセージを含む、セットトップボックスから生じるＨＴＴＰベースのメッセージを、ＩＭＳあるいはＩＰＴＶサービスプロバイダに向けられる、対応するＳＩＰベースのメッセージに変換するように構成されている。これに対応して、ＨＴＴＰ−ＳＩＰ変換プロセッサ２６は、グローバルネットワークから生じる着信するＳＩＰベースのメッセージを、セットトップボックスに向けられる、対応するＨＴＴＰベースのメッセージに変換するように構成されている。

ページ構築プロセッサ２５は、好ましくは、セットトップボックスから生じるユーザ選択リクエストに応じて、セットトップボックスに対して潜在的に利用可能な複数のユーザのユーザ識別子群を含むウェブページあるいはユーザ選択ページを生成するように構成されている。このような場合、ＩＧ２０は、好ましくは、ホームネットワークの従前に登録されているユーザのユーザ識別子を保護するメモリ（不図示）を備える。ページ構築プロセッサ２５は、これらの記憶されているユーザ識別子群をメモリからユーザ選択リクエストの受信に応じて取得する。別の方法では、ＩＧは、別のソース、例えば、ＩＭＳからユーザ識別子群を取得する。通信インタフェース２１は、ユーザ選択リクエストをホームネットワークあるいはＩＧ２０の識別子とともにＩＭＳへ転送することで、ＩＭＳに、ホームネットワークあるいはＩＧ２０の従前に登録されているユーザ群を識別することを可能にする。ユーザ識別子群は、次に、通信インタフェース２１へ返信され、そして、ページ構築プロセッサ２５へ転送される。

通信インタフェース２１は、好ましくは、セットトップボックスからのペンディングＨＴＴＰリクエストを含むペンディングコマンドを受信するように構成されている。このペンディングコマンドは、通信インタフェース２１をトリガーして、ＩＭＳあるいはＩＰＴＶアプリケーションサーバのようなグローバルネットワークから生じる任意の着信リクエスト群をセットトップボックスへ送信する。

図１０及び図１１で示されるようなセットトップボックスあるいはＩＧの任意の機能はソフトウェアで実現され、また、セットトップボックスあるいはＩＧのコンピュータあるいは処理ユニットの内部メモリに直接ロード可能なコンピュータプログラムとして提供される。また、このコンピュータプログラムは、必要な機能群を実行するためのソフトウェアコード部分を含んでいる。コンピュータは、本明細書に記載される関連する機能群を含む、固定あるいはポータブルに関わらない、任意のデバイス、サーバ、ゲートウェイあるいは端末を含むように広く解釈されるべきである。

上述の実施形態群は、本発明のいくつかの例示として理解されるべきである。当業者であれば、本発明の範囲から逸脱することなく実施形態群に対して様々な修正、組み合わせ及び変形が行われても良いことが理解されるであろう。特に、様々な実施形態における異なる部分のソリューションは、技術的に可能であれば、他の構成群と組み合わせることができる。本発明の範囲は、添付の請求項によって定義される。

Claims (30)

1. ホームネットワーク（１）内のセットトップボックス（５０）で実現されるように構成されているＩＰマルチメディアサブシステムであるＩＭＳのＩＭＳアプリケーション（４０）であって、
   ＩＰＴＶセッションをセットアップし制御するために、ＩＭＳゲートウェイ（２０）に向けられている、ＩＰテレビであるＩＰＴＶのＩＰＴＶセッション信号群を生成するように構成されている信号ジェネレータ（４２）と、
   前記セットトップボックス（５０）において実現される、オープンＩＰＴＶ端末機能であるＯＩＴＦのＯＩＴＦシステム（５６）へ、前記ホームネットワーク（１）に接続されているグローバルネットワーク（２）内のメディアサーバ（７０）で利用可能なメディアデータに関連付けられていて、かつ前記ＩＭＳゲートウェイ（２０）から受信される、アドレス情報を提供するように構成されているアドレスプロバイダ（４４）とを備え、
   前記ＩＭＳアプリケーション（４０）は、前記セットトップボックス（５０）で実現されるウェブブラウザ（５４）によって実行されるように構成されているスクリプト型のＩＭＳアプリケーション（４０）である
   ことを特徴とするＩＭＳアプリケーション（４０）。
2. セットトップボックス（５０）であって、
   ＩＰマルチサブシステムであるＩＭＳのＩＭＳゲートウェイ（２０）と通信することを可能にするように構成されている通信インタフェース（５２）と、
   前記セットトップボックス（５０）のディスプレイスクリーン装置（６０）あるいは前記セットトップボックス（５０）に接続されているディスプレイスクリーン装置（６０）に表示可能なウェブページを生成するように構成されているウェブブラウザ（５４）と、
   前記通信インタフェース（５２）に接続されている、オープンＩＰＴＶ機能であるＯＩＴＦの埋込ＯＩＴＦシステム（５６）と、
   前記ウェブブラウザ（５４）によって実行されるように構成されているスクリプト型のＩＭＳアプリケーション（４０）とを備え、
   前記スクリプト型のＩＭＳアプリケーション（４０）は、
   ＩＰＴＶセッションをセットアップし制御するために、前記ＩＭＳゲートウェイ（２０）に向けられている、ＩＰテレビであるＩＰＴＶのＩＰＴＶセッション信号群を生成するように構成されている信号ジェネレータ（４２）と、
   前記埋込ＯＩＴＦシステム（５６）へ、前記ホームネットワーク（１）に接続されているグローバルネットワーク（２）内のメディアサーバ（７０）で利用可能なメディアデータに関連付けられていて、かつ前記ＩＭＳゲートウェイ（２０）から受信される、アドレス情報を提供するように構成されているアドレスプロバイダ（４４）とを備え、
   前記埋込ＯＩＴＦシステム（５６）は、前記スクリプト型のＩＭＳアプリケーション（４０）からの前記アドレス情報に基づいて、前記ＩＰＴＶセッション内の前記メディアデータ用のメディアリクエストであって、前記メディアサーバ（７０）に向けられているメディアリクエストを生成するように構成されている
   ことを特徴とするセットトップボックス。
3. 前記通信インタフェース（５２）は、前記ＩＭＳゲートウェイ（２０）とＨＴＴＰベースの通信を行うように構成されている
   ことを特徴とする請求項２に記載のセットトップボックス。
4. 前記スクリプト型のＩＭＳアプリケーション（４０）は、前記埋込ＯＩＴＦシステム（５６）からのスタートアップリクエストを受信し、かつユーザ選択ページの生成を開始するために、前記通信インタフェース（５２）によって、前記スタートアップリクエストを前記ＩＭＳゲートウェイ（２０）へ転送するように構成されている
   ことを特徴とする請求項２または３に記載のセットトップボックス。
5. 前記スクリプト型のＩＭＳアプリケーション（４０）は、前記ＩＭＳゲートウェイ（２０）から利用可能なユーザ群の少なくとも１つのユーザ識別子を含む前記ユーザ選択ページを受信し、前記ディスプレイスクリーン装置（６０）上の前記ウェブブラウザ（５４）によって前記ユーザ選択ページを提示し、そして、前記ＩＭＳゲートウェイ（２０）へ、前記セットトップボックス（５０）のユーザ入力装置あるいは前記セットトップボックス（５０）に接続されているユーザ入力装置の起動に基づいて生成されたユーザ選択コマンドであって、選択されたユーザのユーザ識別子を含むユーザ選択コマンドを送信するように構成されている
   ことを特徴とする請求項４に記載のセットトップボックス。
6. 前記スクリプト型のＩＭＳアプリケーション（４０）は、前記ＩＭＳゲートウェイ（２０）から、前記グローバルネットワーク（２）に存在する利用可能なサービスプロバイダ（８０）それぞれに対し、前記サービスプロバイダ（８０）に関連付けられていて、かつ前記ＩＭＳゲートウェイ（２０）を指示しているプロバイダ識別子を含むサービスプロバイダ選択ページを受信し、かつ、前記ＩＭＳゲートウェイ（２０）へ、選択されたサービスプロバイダ（８０）のプロバイダ識別子を含み、かつ前記セットトップボックス（５０）のユーザ入力装置あるいは前記セットトップボックス（５０）に接続されているユーザ入力装置の起動に基づいて生成される、サービスプロバイダコマンドを送信するように構成されている
   ことを特徴とする請求項２乃至５のいずれか１項に記載のセットトップボックス。
7. 前記スクリプト型のＩＭＳアプリケーション（４０）は、前記ＩＭＳゲートウェイ（２０）から、前記グローバルネットワーク（２）に存在する選択されたサービスプロバイダ（８０）において利用可能なＩＰＴＶサービス群のアドレス情報を含むサービス選択メッセージを受信し、かつ、前記埋込ＯＩＴＦシステム（５６）へ、前記ＩＰＴＶサービス群の前記アドレス情報を含むサービス記述ロードコマンドを送信するように構成されている
   ことを特徴とする請求項２乃至６のいずれか１項に記載のセットトップボックス。
8. 前記スクリプト型のＩＭＳアプリケーション（４０）は、前記ＩＭＳゲートウェイ（２０）に、前記グローバルネットワーク（２）から生じる着信リクエストを前記埋込ＯＩＴＦシステム（５６）へ転送することを可能にするために、前記ＩＭＳゲートウェイ（２０）へ、ペンディングＨＴＴＰリクエストを含むペンディングコマンドを送信するように構成されている
   ことを特徴とする請求項２乃至７のいずれか１項に記載のセットトップボックス。
9. 前記スクリプト型のＩＭＳアプリケーション（４０）は、前記埋込ＯＩＴＦシステム（５６）へポートリクエストを送信し、前記埋込ＯＩＴＦシステム（５６）から前記セットトップボックス（５０）の少なくとも１つのメディアポートのポート識別子を含む応答メッセージを受信し、かつ前記グローバルネットワーク（２）内の選択されたサービスプロバイダ（８０）へ、前記ＩＭＳゲートウェイ（２０）によって、前記ポート識別子を含む招待メッセージを送信するように構成されている
   ことを特徴とする請求項２乃至８のいずれか１項に記載のセットトップボックス。
10. 前記スクリプト型のＩＭＳアプリケーション（４０）は、前記埋込ＯＩＴＦシステム（５６）へ、前記メディアサーバ（７０）から利用可能な前記メディアデータに関連付けられているアドレス情報と、前記埋込ＯＩＴＦシステム（５６）によって実行されるべきセットアップ手順はないことを示す表示を含む再生リクエストを送信するように構成されている
    ことを特徴とする請求項２乃至９のいずれか１項に記載のセットトップボックス。
11. 前記スクリプト型のＩＭＳアプリケーション（４０）は、前記ＩＭＳゲートウェイ（２０）から、前記メディアサーバ（７０）から利用可能なマルチキャストあるいはブロードキャストメディアチャネルのアドレス情報の形式の前記アドレス情報を含むセッション記述メッセージを受信し、かつ、前記マルチキャストあるいはブロードキャストメディアチャネルへ参加させることを前記埋込ＯＩＴＦシステム（５６）へトリガーするために、前記埋込ＯＩＴＦシステム（５６）へ前記アドレス情報を送信するように構成されている
    ことを特徴とする請求項２乃至８のいずれか１項に記載のセットトップボックス。
12. ＩＰマルチメディアサブシステムであるＩＭＳのＩＭＳゲートウェイ（２０）であって、
    ホームネットワーク（１）内に存在するセットトップボックス（５０）と、前記ホームネットワーク（１）に接続されているグローバルネットワーク（２）内のサーバ群（７０、８０）との通信を可能にするように構成されている通信インタフェース（２１）と、
    前記セットトップボックス（５０）のユーザのユーザ識別子を含み、かつ前記グローバルネットワーク（２）内のＩＭＳサーバに向けられている、登録リクエストを生成するように構成されている登録プロセッサ（２２）と、
    前記グローバルネットワーク（２）内に存在するＩＰテレビであるＩＰＴＶのサービスプロバイダ（８０）に向けられている加入リクエストを生成するように構成されている加入プロセッサ（２３）と、
    前記グローバルネットワーク（２）からの前記ユーザに利用可能なＩＰＴＶサービスそれぞれに対して、前記加入リクエストに応じて受信されるアドレス情報を、前記ＩＭＳゲートウェイ（２０）を指示している変換済のアドレス情報へマッピングするように構成されているアドレス変換プロセッサ（２４）と、
    前記ＩＭＳゲートウェイ（２０）を指示している前記変換済のアドレス情報を含み、かつ前記セットトップボックス（５０）に向けられている、ウェブページを生成するように構成されているページ構築プロセッサ（２５）と
    を有することを特徴とするＩＭＧゲートウェイ。
13. 前記アドレス変換プロセッサ（２４）は、補助サービスプロバイダに関連付けられている補助アドレス情報を、前記ＩＭＳゲートウェイ（２０）を指示する変換済の補助アドレス情報へマッピングするように構成されていて、
    前記ページ構築プロセッサ（２５）は、前記変換済のアドレス情報と前記変換済の補助アドレス情報とを含む前記ウェブページを生成するように構成されている
    ことを特徴とする請求項１２に記載のＩＭＳゲートウェイ。
14. 前記セットトップボックス（５０）から生じるＨＴＴＰベースのメッセージを、前記ＩＭＳサーバあるいは前記ＩＰＴＶのサービスプロバイダ（８０）に向けられている、対応するＳＩＰベースのメッセージへ変換し、かつ前記ＩＭＳサーバあるいは前記ＩＰＴＶのサービスプロバイダ（８０）から生じるＳＩＰベースのメッセージを、前記セットトップボックス（５０）に向けられているＨＴＴＰベースのメッセージへ変換するように構成されているＨＴＴＰ−ＳＩＰ変換プロセッサ（２６）を更に有する
    ことを特徴とする請求項１２または１３に記載のＩＭＳゲートウェイ。
15. 前記ページ構築プロセッサ（２５）は、前記セットトップボックス（５０）から生じるユーザ選択リクエストに応じて、前記セットトップボックス（５０）に対して潜在的に利用可能な複数のユーザのユーザ識別子群を含むウェブページを生成するように構成されていて、
    前記通信インタフェース（２１）は、前記セットトップボックス（５０）へ、前記ユーザ識別子群を含む前記ウェブページを送信するように構成されている
    ことを特徴とする請求項１２乃至１４のいずれか１項に記載のＩＭＳゲートウェイ。
16. 前記通信インタフェース（２１）は、前記セットトップボックス（５０）からペンディングＨＴＴＰリクエストを含むペンディングコマンドを受信し、前記ペンディングコマンドに応じて、前記セットトップボックス（５０）へ、前記グローバルネットワーク（２）から生じる着信リクエストを送信するように構成されている
    ことを特徴とする請求項１２乃至１５のいずれか１項に記載のＩＭＳゲートウェイ。
17. 前記通信インタフェース（２１）は、前記セットトップボックス（５０）内のウェブブラウザ（５４）によって動作するように構成されているスクリプト型のＩＭＳアプリケーション（４０）との通信を可能にするように構成されている
    ことを特徴とする請求項１２乃至１６のいずれか１項に記載のＩＭＳゲートウェイ。
18. ＩＰテレビであるＩＰＴＶのＩＰＴＶセッションをセットアップする方法であって、
    セットトップボックス（５０）で実現されるウェブブラウザ（５０）内でスクリプト型のＩＰマルチメディアサブシステムであるＩＭＳのＩＭＳアプリケーション（４０）を実行するステップと、
    前記スクリプト型のＩＭＳアプリケーション（４０）が、前記セットトップボックス（５０）のユーザ入力装置あるいは前記セットトップボックス（５０）に接続されているユーザ入力装置の起動に基づいて、ＩＰＴＶセッションセットアップ信号群を生成するステップと、
    ホームネットワーク（１）内の前記セットトップボックス（５０）に接続されているＩＭＳゲートウェイ（２０）へ、前記ＩＰＴＶセッションセットアップ信号群を通信するステップと、
    前記スクリプト型のＩＭＳアプリケーション（４０）が、前記ＩＭＳゲートウェイ（２０）から、前記ホームネットワーク（１）に接続されているグローバルネットワーク（２）内のメディアサーバ（７０）から利用可能なメディアデータに関連付けられているアドレス情報を受信するステップと、
    前記スクリプト型のＩＭＳアプリケーション（４０）が、ＩＰＴＶセッション内で、前記メディアデータに対するメディアリクエストであって、前記メディアサーバ（７０）に向けられているメディアリクエストの生成をトリガーするために、オープンＩＰＴＶ機能であるＯＩＴＦの埋込ＯＩＴＦシステム（５６）へ、前記アドレス情報を転送するステップと
    を有することを特徴とする方法。
19. 前記スクリプト型のＩＭＳアプリケーション（４０）が、前記埋込ＯＩＴＦシステム（５６）から、スタートアップリクエストを受信するステップと、
    前記スクリプト型のＩＭＳアプリケーション（４０）が、ユーザ選択ページの生成をトリガーするために、前記ＩＭＳゲートウェイ（２０）へ、前記スタートアップリクエストを転送するステップと
    を更に有することを特徴とする請求項１８に記載の方法。
20. 前記スクリプト型のＩＭＳアプリケーション（４０）が、前記ＩＭＳゲートウェイ（２０）から利用可能なユーザ群の少なくとも１つの識別子を含む前記ユーザ選択ページを受信するステップと、
    前記スクリプト型のＩＭＳアプリケーション（４０）が、前記セットトップボックス（５０）のディスプレイスクリーン装置（６０）あるいは前記セットトップボックス（５０）に接続されているディスプレイスクリーン装置（６０）上の前記ウェブブラウザ（５４）によって、前記ユーザ選択ページを提示するステップと、
    前記スクリプト型のＩＭＳアプリケーション（４０）が、前記ＩＭＳゲートウェイ（２０）へ、選択されたユーザのユーザ識別子を含み、かつ前記セットトップボックス（５０）のユーザ入力装置あるいは前記セットトップボックス（５０）に接続されているユーザ入力装置の起動に基づいて生成される、ユーザ選択コマンドを送信するステップと
    を更に有することを特徴とする請求項１９に記載の方法。
21. 前記スクリプト型のＩＭＳアプリケーション（４０）が、前記ＩＭＳゲートウェイ（２０）から、前記グローバルネットワーク（２）に存在する利用可能なサービスプロバイダ（８０）それぞれに対し、前記サービスプロバイダ（８０）に関連付けられていて、かつ前記ＩＭＳゲートウェイ（２０）を指示しているプロバイダ識別子を含むサービスプロバイダ選択ページを受信するステップと、
    前記スクリプト型のＩＭＳアプリケーション（４０）が、前記ＩＭＳゲートウェイ（２０）へ、選択されたサービスプロバイダ（８０）のプロバイダ識別子を含み、かつ前記セットトップボックス（５０）のユーザ入力装置あるいは前記セットトップボックス（５０）に接続されているユーザ入力装置の起動に基づいて生成される、サービスプロバイダコマンドを送信するステップと
    を更に有することを特徴とする請求項１８乃至２０のいずれか１項に記載の方法。
22. 前記スクリプト型のＩＭＳアプリケーション（４０）が、前記ＩＭＳゲートウェイ（２０）から、前記グローバルネットワーク（２）に存在する選択されたサービスプロバイダ（８０）において利用可能なＩＰＴＶサービス群のアドレス情報を含むサービス選択メッセージを受信するステップと、
    前記スクリプト型のＩＭＳアプリケーション（４０）が、前記埋込ＯＩＴＦシステム（５６）へ、前記ＩＰＴＶサービス群の前記アドレス情報を含むサービス記述ロードコマンドを送信するステップと
    を更に有することを特徴とする請求項１８乃至２１のいずれか１項に記載の方法。
23. 前記スクリプト型のＩＭＳアプリケーション（４０）が、前記ＩＭＳゲートウェイ（２０）へ、前記グローバルネットワーク（２）から生じる着信リクエストを前記埋込ＯＩＴＦシステム（５６）へ転送することを可能にするために、前記ＩＭＳゲートウェイ（２０）へ、ペンディングＨＴＴＰリクエストを含むペンディングコマンドを送信するステップを更に有する
    ことを特徴とする請求項１８乃至２２のいずれか１項に記載の方法。
24. 前記スクリプト型のＩＭＳアプリケーション（４０）が、前記埋込ＯＩＴＦシステム（５６）へポートリクエストを送信するステップと、
    前記スクリプト型のＩＭＳアプリケーション（４０）が、前記埋込ＯＩＴＦシステム（５６）から前記セットトップボックス（５０）の少なくとも１つのメディアポートのポート識別子を含む応答メッセージを受信するステップと、
    前記スクリプト型のＩＭＳアプリケーション（４０）が、前記グローバルネットワーク（２）内の選択されたサービスプロバイダ（８０）へ、前記ＩＭＳゲートウェイ（２０）によって、前記ポート識別子を含む招待メッセージを送信するステップと
    を更に有することを特徴とする請求項１８乃至２３のいずれか１項に記載の方法。
25. 前記アドレス情報を転送するステップは、前記スクリプト型のＩＭＳアプリケーション（４０）が、前記埋込ＯＩＴＦシステム（５６）へ、前記メディアサーバ（７０）において利用可能な前記メディアデータに関連付けられているアドレス情報と、前記埋込ＯＩＴＦシステム（５６）によって実行されるべきセットアップ手順はないことを示す表示を含む再生リクエストを送信するステップを有する
    ことを特徴とする請求項１８乃至２４のいずれか１項に記載の方法。
26. 前記スクリプト型のＩＭＳアプリケーション（４０）が、前記ＩＭＳゲートウェイ（２０）から、前記メディアサーバ（７０）から利用可能なマルチキャストあるいはブロードキャストメディアチャネルのアドレス情報の形式の前記アドレス情報を含むセッション記述メッセージを受信するステップを更に備え、
    前記アドレス情報を転送するステップは、前記スクリプト型のＩＭＳアプリケーション（４０）が、前記マルチキャストあるいはブロードキャストメディアチャネルへ参加させることを前記埋込ＯＩＴＦシステム（５６）へトリガーするために、前記埋込ＯＩＴＦシステム（５６）へ前記アドレス情報を送信するステップを有する
    ことを特徴とする請求項１８乃至２３のいずれか１項に記載の方法。
27. ＩＰテレビであるＩＰＴＶのＩＰＴＶセッションをセットアップする方法であって、
    ＩＰマルチメディアサブシステムであるＩＭＳのＩＭＳゲートウェイ（２０）が、ホームネットワーク内のセットトップボックス（５０）のユーザのユーザ識別子を含む登録リクエストを、前記ホームネットワーク（１）に接続されているグローバルネットワーク（２）内のＩＭＳサーバへ送信するステップと、
    前記ＩＭＳゲートウェイ（２０）が、前記グローバルネットワーク（２）内に存在するＩＰＴＶのサービスプロバイダ（８０）に向けられている加入リクエストを送信するステップと、
    前記ＩＭＳゲートウェイ（２０）が、前記グローバルネットワーク（２）からの前記ユーザに利用可能なＩＰＴＶサービスそれぞれに対して、前記加入リクエストに応じて受信されるアドレス情報を、前記ＩＭＳゲートウェイ（２０）を指示している変換済のアドレス情報へマッピングするステップと、
    前記ＩＭＳゲートウェイ（２０）が、前記ＩＭＳゲートウェイ（２０）を指示している前記変換済のアドレス情報を含むウェブページを生成するステップと、
    前記ＩＭＳゲートウェイ（２０）が、前記セットトップボックス（５０）へ、前記ウェブページを送信するステップと
    を有することを特徴とする方法。
28. 前記ＩＭＳゲートウェイ（２０）が、補助サービスプロバイダに関連付けられている補助アドレス情報を、前記ＩＭＳゲートウェイ（２０）を指示する変換済の補助アドレス情報へマッピングするステップを更に有し、
    前記ウェブページを生成するステップは、前記変換済のアドレス情報と前記変換済の補助アドレス情報とを含む前記ウェブページを生成することを含んでいる
    ことを特徴とする請求項２７に記載の方法。
29. 前記ＩＭＳゲートウェイ（２０）が、前記セットトップボックス（５０）から生じるユーザ選択リクエストに応じて、前記セットトップボックス（５０）に対して潜在的に利用可能な複数のユーザのユーザ識別子群を含むウェブページを生成するステップと、
    前記ＩＭＳゲートウェイ（２０）が、前記セットトップボックス（５０）へ、前記ユーザ識別子群を含む前記ウェブページを送信するステップと
    を更に有することを特徴とする請求項２７または２８に記載の方法。
30. 前記ＩＭＳゲートウェイ（２０）が、前記セットトップボックス（５０）からペンディングＨＴＴＰリクエストを含むペンディングコマンドを受信するステップと、
    前記ＩＭＳゲートウェイ（２０）が、前記ペンディングコマンドに応じて、前記セットトップボックス（５０）へ、前記グローバルネットワーク（２）から生じる着信リクエストを送信するステップと
    を更に有することを特徴とする請求項２７乃至２９のいずれか１項に記載の方法。

Images