JP4603367B2 - 通信ネットワークを介し受信されるサービスの実行のための装置 - Google Patents

Description

発明の詳細な説明

本発明は、一方において限定的決定装置及び受信サービスの実行方法に関し、他方においてサービス及び関連する製品に関する情報メッセージの編集装置及び方法に関する。

本発明は、ユーザによる対話的サービスとのやりとりを可能にする対話型テレビ及びセットトップボックス（ＳＴＢ）に適用される。これのため、上記端末は通常、アナログまたはデジタル一方向配信ネットワーク（マイクロ波、ケーブル、衛星テレビ送信ネットワーク）とポイント・ツー・ポイントタイプ（電話ネットワークなど）双方向ネットワーク（モデムリターンチャネル、ケーブルなど）から構成される１または２つの通信ネットワークに接続される。以下の説明は、より詳細には、ＴＡＫ（ｅＴＶ）というブランド名で販売されている受信機、ＤＶＢ（Ｄｉｇｉｔａｌ Ｖｉｄｅｏ Ｂｒｏａｄｃａｓｔｉｎｇ）デコーダ及びインターネットデコーダを含む対話型消費者端末に関する。

このような端末では、送信されるプログラムに加えて対話型サービスの実行は、特にディスプレイのためなどの端末の具体的特徴に基づく。これら具体的特徴はしばしば、ユーザからの介入を必要とすることなくマルチメディアオブジェクトが存在すると自動的に動作するプラグイン、すなわち、既存のソフトウェアに加えてアプリケーションソフトウェアを含む埋め込みソフトウェア群の形式をとるに過ぎない。これらプラグインは、通常はウェブブラウザに付属されている。しばしばインターネットを介し無料でダウンロードされ、それらは例えば音声や映像を視聴するのに利用される。例えば、広範に利用されているプラグインとして、Ｍａｃｒｏｍｅｄｉａによる「Ｆｌａｓｈ」といい名称で販売されるものがあげられる。このインターネットページアニメーションプラグインは、アニメーションをＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）形式のページに挿入するのに利用される。

サービス提供者は、主として放送局や広告主である。サービス運営者は、これらのサービスの提供者と直接的または間接的（下請け）に契約した契約により、対話的サービスの送信を制御する。後者は、通常はライブイベントやテレビゲーム（このとき、提供者は放送局である）、あるいは対話型の宣伝（このとき、提供者は広告主である）に関する。何れの場合も、サービス運営者は、サービスの正確な送信を約束し（送信数、送信スケジュールや正確な実行など）、あるＱｏＳに加えて、可能な限り多くの端末による受信を保証する。

従って、対話型消費者端末はエンハンストプログラム、言い換えると、対話型サービスがリンクされるオーディオビジュアルプログラムを受信する。従来、各対話型サービスは、ＡＴＶＥＦ（Ａｄｖａｎｃｅｄ Ｔｅｌｅｖｉｓｉｏｎ Ｅｎｈａｎｃｅｍｅｎｔ Ｆｏｒｕｍ）規格に従う送信のため、ＧＩＦ（Ｇｒａｐｈｉｃｓ Ｉｎｔｅｒｃｈａｎｇｅ Ｆｏｒｍａｔ）やＪＰＥＧ（Ｊｏｉｎｔ Ｐｈｏｔｏｇｒａｐｈｉｃ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ）フォーマットの画像やＦｌａｓｈアニメーションなどの従属物及びＨＴＭＬページから構成される。この処理は、同じようにＨＴＭＬに基づくＤＶＢ−ＭＨＰ（Ｍｕｌｔｉｍｅｄｉａ Ｈｏｍｅ Ｐｌａｔｆｏｒｍ）規格に従う送信に対しても同様である。

典型的には、エンハンストプログラムが配信されると、端末は対話型サービスを取得することにより始動する。このとき、運営者により送信される信号の受信は、映像上に重ね合わせされたグラフィックやテキスト表示を発生させ、ユーザが当該サービスとやりとりするのを容易にする。適切な場合には運営者の選択に応じて、このプロンプト表示が省略され、サービスが直接提供される。ＡＴＶＥＦでは、対話型サービスの送信及び表示は、以下のステップから構成される。すなわち、
−対話性が提供されていることを端末に通知するサービス通知メッセージの送信 このとき、端末は対話型サービスの内容を聴取し、従って当該サービスを構成するすべての付属物とＨＴＭＬページの受信を待機し、トリガー形式により（表示トリガーと共にサービス更新トリガー）当該サービスを実行するよう指示する。
−コンテンツの送信
−トリガーの送信
ＭＨＰでは、同様の処理がなされ、サービス通史メッセージは通知形式をとる。

現在、プラグインは急速に進化し、多数の後継バージョンが存在する。このため現在は、Ｆｌａｓｈプラグインは、何れもが広範に使用されているＦｌａｓｈ３、Ｆｌａｓｈ４及びＦｌａｓｈ５のバージョンから構成される。このとき、Ｆｌａｓｈ５プラグインを有する端末は、Ｆｌａｓｈ３アニメーションを表示することが可能であるが、それがＦｌａｓｈ３のみを有する場合、Ｆｌａｓｈ４またはＦｌａｓｈ５モードに実行されるアニメーションを含むＨＴＭＬページを正確に表示することは不可能である。さらに、サービス提供者は常に、最新のプラグインバージョンを利用し、それらの機能から最大の効果を取得し、対話型サービスの提供に対し仕上げ処理を行うことを所望する傾向がある。

対話型端末側では、通常の更新を行う必要がある。サービスが一様なターゲットに対し単一のエンティティにより運営される限り、このような運営は依然として制御可能である。しかしながら、２つのサービス運営者が運営を行なったり、あるいはＳＴＢや対話型テレビのターゲットにインストールされたベースが一様でなくなると、問題が生じる。このため例えば、端末が直近のソフトウェアダウンロードキャンペーンにおいて更新されなかった場合、当該端末はもはや一定の送信された対話型サービスを表示することが不可能となる可能性がある。必ずしもすべての端末がシステマチックに更新されなかったため、端末のインストールされたベースが一様でなくなる可能性が、消費者アプリケーションにはある。

この問題に対処するため、送信されたサービスが完全な実行に要するプラグインとそのバージョンを端末に示すような方法が知られている。このとき、端末は低質モードによりＨＴＭＬページを表示することを意図したとしても、それが指定されたものより低いパワーのバージョンではあるが、当該サービスに対し利用可能なものを有する場合、利用可能な手段に従って当該サービスを実行するか決定することが可能である。

このアプローチは、情報技術社会のものと対照的なものであり、ユーザは例えば、ＨＴＭＬページを表示するのに必要とされるプラグインの最新バージョンをダウンロードするよう促される。このとき、ユーザによるこの選択に問題はない。なぜなら、この要求は比較的一般的なものであり、ダウンロード時間はＱｏＳ（送信に同期しない）に影響を与えるものでないからである。ＩＴ社会との類似性により、対話型端末のユーザが双方向ネットワークを用いて、最新の必要とされるプラグインバージョンを持っていなかったとしても情報を要求する場合、ユーザ自身がサービスを実行するイニチアチブを有するとすると、低質モードの表示は受け入れられる。

他方、配信により受信されるサービスの場合、運営者とサービス提供者との間で以前になされた契約に従って、サービス（例えば、対話型宣伝など）がそれを受信するすべての消費者端末上で完璧に実行されることが重要である。サービスの実行不可などの低質モードによる表示は、提供されるサービスの品質を害するリスクがある。

最新バージョンである１．１．１（ＥＴＳＩ ＴＳ１０２８１２Ｖ１．１．１）のＭＨＰ規格は、プラグインアプリケーションの識別やそれのスタートアップモードなどの関連サービス（セクション１０．１３．２）の実行に要するプラグインに関する情報の表示を信号処理により提供する。さらに、サービス（セクション１０．１３．３）は、プラグイン手段により実行可能な各アプリケーションを選好順に整列された当該用途に利用可能ないくつかのプラグイン（デフォルトでは１つ）と関連付けることが可能である。しかしながら、実行されるアプリケーションに利用可能なプラグインの何れもが端末においてローカルに利用可能でないとき、上記規格は当該情報を利用することに関し対処していない。おそらく、当該分野における現在の利用法は、サービスの実行が拒絶されることを招く。

サービスの実行不可または概略的な実行により生じる困難を部分的に解消するため、上記プラグインがローカルに利用可能でないとき、ＭＨＰＭＨＰ信号処理で必要な好ましいプラグインをシステマチックにダウンロードすることが可能であろう。このような解決策は、少なくともこれらプラグインに関する以降の要求を予期することを可能にするであろう。

しかしながら、利用可能でないプラグインによるサービスの実行の問題は、弊害をもたらし続けるであろう。実際、多数の場合において、コンテンツやトリガーが実行されるときには、ダウンロードは終了していない可能性がある。このとき、受信したサービスが実行不可となるリスクが存在するだけでなく、端末はしばしば当該サービスのコンテンツを不必要に取得するであろう。さらに、プラグインを自動的にダウンロードする処理は、特に帯域幅と記憶領域の占有の点など、多くの点において問題がある。

以上の理由から、最も自然な解決策は、必要とされるプラグイン（信号処理において言及される）がローカルに利用可能であるどうかに従って、ユーザに関するローカル工背イン管理を完全なものとするため、欠落しているプラグインを考慮したとしても、関連するアプリケーションを限定的に実行することに関するものであるかもしれない。このような端末のポーリング（ｐｏｌｌｉｎｇ）に基づく更新プロセスは、何れのケースにおいても将来的に有用であり、プラグインの新しいバージョンや現在は必要とされていないプラグインを最初に要求するサービスに適用可能でない。

本発明は、対象となる端末の使用に障害となるダウンロード処理やユーザにとって複雑かつ面倒な管理を回避しながら、サービスが実行不可となるケースを大きく減少させることを可能にすることにより、上記問題点の多くを解決する受信サービスを実行するための限定的決定装置を提案する。さらに、本発明の限定的決定装置は、端末において利用可能な機能のフレキシブルかつ効果的な更新を容易にするかもしれない。

本発明はまた、本発明の決定装置に対応する限定的実行決定方法と、情報メッセージ及び関連する製品を編集する装置及び方法に関する。

本発明は、特にテレビ技術に適用されるが、ラジオや所定の寿命を有するサービスの送信を伴う他の任意のセクタにもまた効果的に適用可能である。さらに、本発明はアナログ及びデジタル環境に等しく動作可能である。

ここでは、「サービス」という用語は、配信により送信されるプログラムの上記端末による受信と並行して、端末への送信及び端末上での実行のための機能群を意味するものと解される。このサービスは対話的なものであってもよいし、そうでなくてもよく、対話性自体は、おそらくローカルであるかもしれないし（ユーザと端末との通信）、あるいはリターンチャネルを介しリモートなものであるかもしれない（端末を介したユーザとサービス運営者との間の通信）。

従って、本発明の課題は、通信ネットワークを介し受信される所定の寿命を有するサービスの実行のための限定的決定装置を生成することである。本装置は、
−前記サービスの実行前に前記サービスに関する情報を受信するため設けられ、前記サービスに関する情報を受信するモジュールと、
−前記受信した情報から、前記情報に関するサービスを実行するのに要するコンピュータプログラムに関する情報を特定するモジュールと、
−前記特定されたコンピュータプログラムのローカルな利用性をチェックするモジュールと、
−前記サービスに必要とされるコンピュータプログラムがローカルに利用可能である場合、前記サービスの実行を可能にするよう設けられ、サービスの実行に対する選択的決定モジュールと、
から構成される。

本発明によると、当該装置はさらに、
−前記コンピュータプログラムがローカルに利用可能でない場合、前記サービスに対し必要とされるコンピュータプログラムのダウンロードをトリガーすることが可能なコンピュータプログラムを取得するモジュールと、
−前記サービスに関する情報に少なくとも従って、前記サービスに必要なローカルに利用可能でないコンピュータプログラムのダウンロードを許可及び回避することが可能なコンピュータプログラムを取得する自動選択的決定モジュールと、
を有する。

従って驚くべきことに、本発明は、サービスの送信前に十分早い段階での直近のプラグインをシステマチックに提供などするための送信レベルの適応化と、端末のリソースを帯域幅と格納容量に関して増加させるなどによる受信レベルの適応化によるものでない。対照的に、本発明の装置は、送信により供給される情報（必要とされるコンピュータプログラムに関する情報）とローカル情報（必要とされるコンピュータプログラムの利用性、ダウンロードに関する決定基準）の両方を利用した送受信間の相互作用によるものである。

このようにして、受信機は、以降において受信されるサービスにより必要とされるコンピュータプログラム（好ましくは、プラグイン）をダウンロードするか否か決定することにより、状況に自動的かつフレキシブルに適応することが可能となる。本発明の成功した実施例では、受信機は、このダウンロードがサービスのユーザと送信側との間で満足行くものであるときは常に、欠落しているコンピュータプログラムのダウンロードをトリガーし、その他のケースでは当該処理を回避することが可能である。従って、サービスのコンテンツは、端末がそれを実行できない場合には、端末による取得は行われない。

組み合わせ可能な好適な実施例では、
−現在実行中のサービスを開始することが意味のないこととみなされると（例えば、ゲームの始めを欠くことがかなりのロスとなる送信中の対話的ゲームなど）、対象となるサービスが開始されるときに完了されている場合に限り、ダウンロードは実行される。
−現在実行中のサービスを開始することが有用であるとみなされると（例えば、試合中のサッカーの結果など）、対象となるサービスが終了するまでに完了されている場合に限り、ダウンロードは実行される。
−ダウンロードされるコンピュータプログラムが一般に大変有用であり、他のサービスにも利用可能であるため、あるいは対象となるサービスの以降の発生に有用であるため、対象となるサービスには利用可能でなくても、ダウンロードは実行される。
−所定の帯域幅に限定され、及び／または所定の限定された格納領域しか占有しない場合にのみ、ダウンロードは実行される。

送信される情報は、直接的にこの決定プロセスのためのもであってもよいし、そうでなくてもよい。特に、このプラグインが標識に関するサービスの実行中のみ利用可能となるということを意味したとしても、あるいはこのプラグインが当該サービスの時間に間に合うようダウンロードされず、以降のサービスに有用であると意味する場合でさえ、当該情報は、あらゆる状況においてプラグインのダウンロードを課す標識であってもよい。それはまた、プラグインの識別など（ＭＨＰ規格と同様）に関する特定のアプリケーションから独立してサービス通知メッセージによりアクセス可能な情報に関する。あらゆる場合において、本発明の重要な特徴は、受信レベルでの決定基準と当該情報の利用の組み合わせである。

さらに、この情報に加えて、ローカルリソースなどの決定に関する要素があってもよい。

本決定装置は、効果的に端末（特に、テレビ、対話型ラジオ、ＳＴＢなど）に搭載される。しかしながら、他の実施例では、それは送信機と端末との間の中間受信機に配置される。例えば、このような受信機は、帯域幅と格納領域（企業や建物など）をポーリングする端末グループに対し利用される。

サービスを送信するのに利用される通信ネットワークに関し、それは一方向または双方向であってもよい。サービスに関する情報の送信モードは、この同一のネットワークを介し好ましくは適用されるが、必須ではない。例えば、当該サービス及び情報は、ケーブル、マイクロ波あるいは衛星を介し同一のネットワークに配信することにより通信される。他の例では、関連するサービスが配信される前に、情報はインターネットにより通信される（あるいはより一般には、リターンチャネルにより）。

既存の規格に基づき実施形態のユーザフレンドリ及びその容易さのため特に効果的なケースは、特にＡＴＶＥＦ及びＭＨＰ規格に対し、サービス通知メッセージの対象となるサービス内で情報が通信されるということである（コンテンツとサービス通知メッセージを含むサービス）。このとき、受信モジュールは、サービス通知メッセージにより上記サービスに関する情報を受信するよう構成され、情報特定モジュールは、これらサービス通知メッセージから情報を抽出するよう構成される。

従って好適な実施例では、対話型サービスは、使用するプラグインを記述する情報とダウンロードを強制するか否かに関する情報の両方を有し、これにより、端末はこれらのプラグインをダウンロードするか否か決定することができる。この情報は、例えば、フォームから対話型サービスを発行するときに、効果的に入力される。従って、対話型サービスデータを生成するとき、この情報はサービスを構成するファイルに挿入される。端末に関して、それはサービスの寿命及びプラグインのサイズに従って、プラグインのダウンロードを行うか否か決定するためのアルゴリズムを有する。

アナログテレビ及びＡＴＶＥＦでは、上記情報は、必要とされるプラグインのリストにより通知のＳＤＰ（Ｓｅｓｓｉｏｎ Ｄｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ、サービス通知メッセージペイロードフォーマット）部分に効果的に挿入される。この追加情報は、好ましくは、すべてのサービスにグローバルに示される。例えば、ＡＴＶＥＦサービスの場合、対話型サービスを構成する各ＨＴＭＬサービスにおいて、どのプラグインが当該ページの実行に必要とされるか示すことは、実際には望ましくない。これは、サービスの各ページに負荷がかかり過ぎることになり、サービスの最初のページが端末により表示可能であるが、第２ページはそうでないなどのため、ユーザはそれにおいてナビゲートできずに、さービスの一部のみにアクセスするリスクがあるかもしれない。

デジタルテレビ及びＤＶＢでは、当該情報は、存在する利用可能なすべてのプラグインを列挙したテーブルから割当てられた識別子により通知ストリーム記述子に効果的に挿入される。

これらの前提条件がわかると、端末はまず、必要であるが利用可能でないプラグインとソフトウェアバージョンをダウンロードするか決定し、第２段階で、対話型サービスを表示するか決定することができる。

好ましくは、サービスに関する情報はサービスの実行有効性に関する時間情報を含むため、選択的取得決定モジュールは、少なくとも当該時間情報に従ってダウンロードを許可及び回避することができる。実際、ダウンロードするか否か決定するのに、サービスの時期（スタート、エンド、決定ステップなど）を考慮することは興味深いことであり、この時期は通常は関連するプログラムの配信と同期される。

効果的には、選択的取得決定モジュールは、時間情報から抽出できるサービスの所定の時点以前に、ダウンロードが完了すると予想される場合にはダウンロードを許可し、そうでない場合にはダウンロードを回避するよう構成される。

従って、時間情報が考慮される第１の方法によると、上記所定の時点は、サービスの実行の有効性の終わりを指定する。長いサービスの場合（１日単位で連続的にアクセス可能なポータルタイプサービスやサッカーの試合などのスポーツイベントの再送など）、実際には、欠落しているプラグインをダウンロードし（２,３分しかかからない処理）、その後にこのサービスを視聴者に提供することが重要である。

時間情報が考慮される第２の方法によると、上記所定の時点は、サービスの実行の有効性の始まりを指定する。受信される追加情報が２つのケースを区別するのに利用可能である限り（例えば、決定基準に関する具体的な標識、あるいは「連続的にアクセス可能なポータル」などのタイプのサービスに関する情報など）、２つのフォームは効果的に合成される。

ダウンロードの承認がサービスの所定の時点に従属する場合、選択的取得決定モジュールは、好ましくは、ローカルに利用可能でない要求されるコンピュータプログラムのダウンロード時間を取得し、このダウンロードが完了することが予想される時点を推定することが可能である。この取得モードは、コンピュータプログラムのサージなどの受信情報と、利用可能な帯域幅などのローカル情報とから、効果的に取得される。

好ましくは、サービスに関する情報は始動値と非始動値とを有する少なくとも１つの強制ダウンロード標識を含むため、選択的取得決定モジュールは、当該強制ダウンロード標識が始動値を有する場合、ダウンロードを強制許可するよう構成される。

より詳細には、実施例によると、欠落しているプラグ因果表示されるサービスの現在の生成を可能にしないときでさえ（サービスの寿命より長いダウンロード時間）、以下の利用の１つのため、欠落しているコンポーネントを端末にダウンロードさせることが効果的である。すなわち、
−当該対話型サービス（例えば、短い宣伝など）は、その月にｎ回送信される必要があり、この対話型宣伝が送信されるたびに、端末はこのプラグインをダウンロードする時間を持たない。上記構成でない場合、それはこのサービスを視聴者に提供しないであろう。強制ダウンロード標識の実施例は、視聴者が宣伝の残りのｎ−１回の送信を利用することが可能となるように、このプラグインのダウンロードを強制するのに利用することができる。
−このプラグインは広く利用されているため、回避することができない。この場合、強制ダウンロード標識の実施例は、当該時点で提示されているサービスにより利用可能でなかったとしても、インストールされているベースのすべての端末にそれを取得させるのに利用することができる。

これら何れの場合も、ダウンロードされたプラグインが永久メモリに保存されるべきであり、すなわち、フラッシュメモリまたはハードディスクにインストールされるべきである。

好ましくは、一般には、本発明の限定的実行決定装置はまた、ローカルに利用可能でなく必要とされるコンピュータプログラムのサイズを取得するモジュールを有し、選択的取得決定モジュールは、これらのサイズによりダウンロードを許可及び回避することができる。

上記サイズを利用する第１の方法は、すでに上述された。選択的取得決定モジュールは、これらのサイズとコンピュータプログラムのローカル受信能力に従って、ローカルに利用可能でない必要とされるコンピュータプログラムのダウンロード時間を推定し、サービスの少なくとも部分的の以降の実行が許可されるとき、ダウンロードを許可するよう構成される。

上記サイズを利用する第２の方法によると（第１の方法と組み合わせ可能である）、決定モジュールは、情報が関連するサービスのコンテンツまで長い時間到達したとしても、ダウンロードを許可しないと決定することができる。なぜなら、受信機は必要とされるコンピュータプログラムの１つのサイズが与えられると、限定的すぎるリソースを有するためである。このリソースの制限は、受信機に特有のものであるかもしれないし（遅すぎるモデム、限定的すぎるディスクスペースまたはより一般的には格納領域）、あるいは受信機動作モードから生じるものであってもよい（他のタイプの受信に主として利用可能な状態を維持するのに必要であり、例えば、１０％の空きを残す帯域幅）。

本発明はまた、限定的決定装置に対応する通信ネットワークを介し受信されるサービスの実行のための限定的決定方法に関し、好ましくは、何れかの実施例による装置などを利用して実現されるよう構成される。

本発明はまた、サービスに関する情報メッセージを編集する装置であって、前記メッセージは、前記関連するサービスの実行前にユーザに送信されるためのものである。当該装置は、前記サービスの実行に要するコンピュータプログラムに関する情報を前記メッセージに組み込む手段を有する。

本発明によると、組み込み手段は、始動値と非始動値とを有する少なくとも１つの強制ダウンロード標識を前記情報に含むよう構成され、前記標識は、該標識が前記始動値を有する場合、前記必要とされるコンピュータプログラムのダウンロードを強制許可するよう構成される。

当該メッセージ編集装置は好ましくは、本発明の実施例の何れかに記載よる限定的実行決定装置のためのメッセージを生成するよう構成される。

本発明はさらに、情報メッセージ編集装置に対応する情報メッセージ編集方法に適用され、好ましくは、当該メッセージ編集装置を用いて実現される。

本発明の他の課題は、コンピュータ上で実行されると、本発明による限定的実行決定方法または情報メッセージ編集方法の各ステップの実行のためのプログラムコード命令からなるコンピュータプログラムを生成することである。「コンピュータプログラム」という用語は、ディスケットやカセットなどのプログラムを含む格納領域だけでなく、電気または光信号などの信号からも構成されるコンピュータプログラム媒体を意味するのに使用される。

本発明はまた、少なくとも１つのサービスに関連し、少なくとも１つの受信機により自動的に利用される情報を含む制御情報メッセージであって、当該メッセージは、前記サービスの実行前に前記受信機に送信されるよう構成され、前記サービスの実行に必要な少なくとも１つのコンピュータプログラムに関する情報を有するメッセージに関する。

本発明によると、この情報は、始動値と非始動値とを有する少なくとも１つの強制ダウンロード標識を含み、当該標識は、該標識が前記始動値を有する場合、前記必要とされるコンピュータプログラムのダウンロードを強制許可するためのものである。

本発明の制御情報メッセージは好ましくは、本発明によるメッセージ編集装置により生成されるためのものである。

本発明はまた、本発明の実施例の何れかによる限定的実行決定装置を有することを特徴とするデコーダに適用される。

本発明は、添付される図面を参照しながら、限定することを意図せず、以下の実施例及び実現形態により良好に理解及び図示されるであろう。

図中、同一または類似の要素は同一の参照番号により表される。異なる実体を有する対応する要素は、同一の番号と添え字により示される（添え字ＡとＢはそれぞれ、ＡＴＶＥＦ規格とＭＨＰ規格を参照する）
さらに、説明及び図示される機能的エンティティは（特に図１〜３において）、必ずしもシステムの物理的に異なるエンティティに対応する必要はなく、例えば、同一のソフトウェアまたは同一のコンポーネント回路の機能から構成されてもよい。他方、同一のモジュールは、いくつかの物理的に個別のエンティティの形態により実現されてもよい。

送受信システム（図１）は、ネットワーク６を介し通信する送信機１と受信機２から構成され、送信機１は受信機２にサービスを送信するよう構成される。

受信機２には、受信されるサービス１１の実行のため、サービス実行ユニット４０と限定的決定装置２０が設けられる。受信機２はまた、特にサービス１１を実行するのに用いられるコンピュータ機能を格納するのに設けられる格納領域３０を有する。

送受信システムはさらに、限定的決定装置２０にネットワーク７（ネットワーク６と同一であってもよい）を介しサービスに関連する情報１２を提供するよう構成されたリンク８を介した送信機１に関する情報ソース３を有する。この情報１２は、特にサービス１１の実行に要するコンピュータプログラムに関する情報を有する。コンピュータプログラムソース４は、特に格納領域３０の節約のため、受信機２に対するサービス１１の実行に要するコンピュータプログラム１２のダウンロードをトリガーするため、限定的決定装置２０により利用される。

より詳細には（図２）、限定的実行決定装置２０は、
−サービス１１に関連する情報１２を受信する手段２１と、
−この情報１２の中のサービス１１を実行するのに要するコンピュータプログラムに関する情報を特定するモジュール２２と、
−正式に特定されたコンピュータプログラムのローカルな利用可能性（格納領域３０における）をチェックするモジュール２３と、
−要求されたコンピュータプログラムがローカルに利用可能である場合、サービス１１の実行のための選択的決定モジュール２４と、
−上記サービス１１の（適切な時点における）実行をトリガーするモジュール２７と、
−コンピュータプログラムのダウンロードの許可または回避を行うよう構成され、必要とされるが、ローカルに利用可能でないコンピュータプログラム１３の自動取得２５のための選択的決定モジュールと、（このため、選択的決定モジュール２５は、情報１２から抽出される情報と情報１２に含まれる他の要素（特に、サービス１１のスタート及びエンド時間など）だけでなく、格納領域３０に以前に格納されたものなどの受信機２のローカル機能１５と上記プログラム１３のサイズのソース５からサイズを取得するためのモジュール２８を介しアクセス可能な必要とされるコンピュータプログラム１３のサイズ１４もまた考慮することができる。）
−ソース４から必要とされるコンピュータプログラム１３を取得し、必要に応じて、選択的取得決定モジュール２５のトリガーに応答して、格納領域１３に上記プログラム１３を格納するモジュール２６と、
から構成される。

情報ソース３（図３）に関して、情報ソース３は、必要とされるコンピュータプログラムに関する情報を情報１２に組み込む装置３１を有する。装置３１は、上記コンピュータプログラムに関する詳細（名称やバージョンなど）を組み込むためのモジュール３２と、上記コンピュータプログラムのダウンロードに関する指示（ダウンロードモードやアクセスするためのアドレスなど）を組み込むためのモジュール３３とから構成される。

動作に関して、限定的決定装置２０はまず、情報ソース３から送信機１から得られるサービス１１を実行するのに必要とされるコンピュータプログラムに関する情報を情報ソース３から受信する。必要とされるすべてのコンピュータプログラムがすでに受信機２に利用可能である場合、選択的決定装置２４は、適切な時点においてサービス１１を実行すること決定する。

そうでない場合、選択的取得決定装置２５が、必要とされるが利用可能でないプログラム１３がダウンロードされる必要があるか決定するため、選択アルゴリズムを適用する。肯定的な応答がなされると、選択的取得決定モジュール２５は、取得モジュール２６によるソース４からの欠落したコンピュータプログラム１３のダウンロードを開始する。この場合、すべてが正しく進行し、必要とされるすべてのコンピュータプログラムが要求された時点において受信機２において利用可能である場合、選択的実行決定モジュール２４は、前述のように、適切な時点にサービス１１を実行することを決定する。選択的取得決定モジュール２５がダウンロードを許可しない場合、あるいはこのダウンロードが決定されたが、不具合が生じたと判明したとき、あるいはそれが正常に進行したが、完了するのに時間がかかり過ぎるときでさえ、選択的実行決定モジュール２４は、対象となるサービス１１を実行しないよう決定する。

サービス１１がＡＴＶＥＦまたはＭＨＰ規格に従うあるケースでは（図４）、対話型サービス１１に関する情報１２は、当該サービスに対する通知メッセージにより送信される。受信機２がこの通知メッセージを受信すると（ステップ４１）、当該サービスを正確に表示するのに必要なソフトウェアバージョンとプラグインを特定する（ステップ４２）。その後、受信機２は、必要とされるすべての要素がローカルに利用可能であるかチェックし（ステップ４３）、この応答が肯定的である場合、適切な時点において対話型サービスを表示する（ステップ４４）。そうでない場合、受信機は、欠落している要素をダウンロードするか決定する（ステップ４５）。この決定が否定的なものである場合、受信機は、対話型サービスを表示することを拒絶する（ステップ４７）。この決定が肯定的なものである場合、受信機は、欠落している要素を回復し（ステップ４６）、対話型サービスを表示する（ステップ４４）。

パーソナルコンピュータ（ＰＣ）世界におけるＡＴＶＥＦ及びＭＨＰサービスのより詳細な実施例が詳述される。

１．ＡＴＶＥＦサービス
以下に説明されるＡＴＶＥＦに基づく解決策は、アナログとデジタル両方の領域に等しく提供される。以下において、当該解決策のすべての含意が詳述される（対話的サービスの発行から端末上での受信まで）。

対話型サービス１１を生成するときの実現形態（情報組み込み装置３１）は、当該サービスに関する情報１２の通知への挿入を有する。例えば、ＴＡＫという名称により販売されている対話型テレビ技術に関して、この情報１２は、フォームなどから対話型サービス１１の発行時に入力される。ＴＡＫのメーカーは、対話型サービスを発行する各サービス提供者にサービス発行パックを提供する。このパックは、対話型テレビ、ミニマリストデータサーバ及び映像挿入モジュールから構成されるシミュレータと発行ソフトウェアを含む。一変形では、当該パックは、シリアルリンクまたはＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）により接続されるテレビとパーソナルコンピュータ（ＰＣ）のみから構成される。従って、この発行プロセスは、以下のステップから構成される。すなわち、
−対話型サービス１１の生成（ＨＴＭＬページ、Ｆｌａｓｈアニメーション、ＪａｖａＳｃｒｉｐｔ言語による指示などを書き込み、異なるトリガーを記述することによる対話型サービスの開発）
−使用されるプラグイン（例えば、埋め込まれたＦｌａｓｈ４アニメーションなど）を記述するフォームとダウンロードを強制する標識の完成
−当該対話型サービス１１を構成するＡＴＶＥＦファイルの生成（ＨＴＭＬページ、適切な場合には、Ｆｌａｓｈ及び画像ファイルなどのあらゆるコンテンツ及びトリガーのＡＴＶＥＦ通知の生成）
情報１２のフォーマットに関して、必要なプラグインを指定することによりメディアを記述するのに第１フィールドが利用される。この記述は、メディアのフォーマット（ＦｌａｓｈやＭＰ３など）と、当該メディアのバージョンの２つのパラメータから構成され、このフィールドは、プラグインが存在する回数だけ繰り返される。他の一意的なフィールドは、欠落しているプラグインのダウンロード及びインストールを強制するのに利用される。

例えば、欧州のＡＴＶＥＦ規格に準拠したトランスポートレイヤに従って、通知がカプセル化され、ＳＡＰ（Ｓｅｓｓｉｏｎ Ａｎｎｏｕｎｃｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）フォーマットによるヘッダとＳＤＰ（Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ）フォーマットによるペイロードを有する（ＲＦＣ２３２７−Ｒｅｑｕｅｓｔ Ｆｏｒ Ｃｏｍｍｅｎｔを参照されたい）。対話型サービス１１を記述する情報は、ユーザにより適応可能な属性フィールド「ａ＝」を提供するＳＤＰに含まれる。

使用されるプラグインと必要とされるバージョンのリストが、
ａ＝＜ａｔｔｒｉｂｕｔｅ＞：＜ｖａｌｕｅ＞
（ただし、＜ａｔｔｒｉｂｕｔｅ＞＝ｍｅｄｉａＦｏｒｍａｔ ｏｒ ｍｅｄｉａＶｅｒｓｉｏｎ、及び＜ｖａｌｕｅ＞＝ｃｈａｒａｃｔｅｒ ｓｔｒｉｎｇである）
のフォームによりＳＤＰに挿入される。

任意的であるｍｅｄｉａＶｅｒｓｉｏｎ属性に対し、＜ｖａｌｕｅ＞は、
＜ＶｅｒｓｉｏｎＭａｊｏｒ［Ｓｅｐａｒａｔｏｒ］［ＶｅｒｓｉｏｎＭｉｎｏｒ］
のタイプとなる。ここで、ＶｅｒｓｉｏｎＭａｊｏｒフィールドは必須であり、端末には知られている必要があるＳｅｐａｒａｔｏｒは、ＶｅｒｓｉｏｎＭｉｎｏｒが指定されるときのみ利用される。

例えば、ＭｙＰｌｕｇｉｎ４．３のタイプのプラグインを扱い、選ばれたＳｅｐａｒａｔｏｒがカンマ「“，”」である場合、
ｍｅｄｉａＦｏｒｍａｔ＝ＭｙＰｌｕｇｉｎ
ｍｅｄｉａＶｅｒｓｉｏｎ＝４．３
となる。

ｍｅｄｉａＶｅｒｓｉｏｎフィールドが存在する場合、それは先行するｍｅｄｉａＦｒｏｍａｔフィールドに必ず付属される。当該フィールドがない場合、指定されるバージョンがないか、あるいはプラグインにより提供される基本機能のみが利用される。このため、どのバージョンのプラグインが存在したとしても、当該サービスを正確に表示することが可能である。

プラグインのダウンロードを強制する標識は、それがない場合には、
ａ＝ｍｅｄｉａＤｏｗｎｌｏａｄ：ｔｒｕｅ ｏｒ ｆａｌｓｅのフォームによりＳＤＰに挿入される。

デフォルトでは、このｍｅｄｉａＤｏｗｎｌｏａｄ属性が指定されていない場合、それは非アクティブ（ｆａｌｓｅ）とみなされる。この結果、端末はプラグインをダウンロードすべきか否か決定する。そうでない場合、それがｔｒｕｅと割当てられている場合、あらゆるケースにおいて、プラグインはダウンロードされる。

ＳＤＰの一例が以下に展開される。

この例では、端末のブラウザは、Ｆｌａｓｈ４、ＭＨＥＧ（Ｍｕｌｔｉｍｅｄｉａ Ｈｙｐｅｒｍｅｄｉａ Ｅｘｐｅｒｔ Ｇｒｏｕｐ）規格に従うマルチメディアアプリケーション及びＭＰ３フォーマットによる音声ファイルをサポートしている必要がある。さらに、１以上のコンポーネントがない場合、それらはダウンロードされる必要がある。

以下に注目することは興味深い。
−上記属性はメディアレベル属性であり、セッションレベル属性ではない。すなわち、それらはメディアを記述するのに利用されるが、現在のセッションからは独立したものである。
−上記メディア記述属性は、セッション記述属性の後に挿入されねばならない（ＲＦＣ２３２７を参照せよ）
−受信機が上記属性を「理解しない」場合、それらは無視される。

アナログテレビに対する対話型端末５２における本実施例の実現形態（図５）が、説明される。端末５２は、ソフトウェアコンポーネント形式により、
−受信したＡＶ信号（サービス１１と情報１２）により伝送されたデータを抽出するための１以上のＶＢＩ（Ｖｅｒｔｉｃａｌ Ｂｌａｎｋｉｎｇ Ｉｎｔｅｒｖａｌ）と（デジタルテレビの領域では、当該コンポーネントはデマルチプレクサと置換される）、
対話型サービス１１を管理するためのブラウザ５５と（それは、サービス１１を表示し、リモコンを介し視聴者からコマンドを受信し、要求された動作（ハイパーナビゲーションやスクリプトの実行など）を実行する）
−サービス１１を表示するのに必要とされるが利用可能でないプラグイン１３を回復することが可能な限定的実行決定装置２０（ソフトウェア形式による）
−格納領域３０Ｓの対話型サービス１１（おそらく特に、ＨＴＭＬページ、ＪａｖａＳｃｒｉｐｔによる指示及びＦｌａｓｈアニメーション）
配信器５１（送信機１）は、ネットワーク６を介し端末５２とＡＴＶＥＦサービス１１を通信する。これらのサービス１１の各々は、通知６１、コンテンツ６２及びトリガー６３から構成される。配信器５１は、双方向通信ネットワーク８を介し端末５２と通信するサービス運営者５３に双方向接続される。

サービス１１の１つをダウンロード及び表示するかに関する決定は、何れのケースにおいても処理することができない不要なデータにより端末５２をロードしないように、当該サービスのコンテンツ６２の取得前に、限定的取得決定装置２０により効果的に行われる。トリガー６３及びコンテンツ６２に関する聴取チャネルをオープンする前に、対話的端末５２は、通知６２の受信により対話的サービス１１を表示することが可能であるかチェックする。表示することができない場合（必要なすべてのプラグインを備えず、サービス１１の終了期限前にそれらをダウンロードする時間を持たない場合）、当該コンテンツの聴取を開始せず、それを無視するようにしてもよい。

より詳細には、対話型端末５２（図６）は、ドライバ５４、ブラウザ５５及びサービス１１のための格納領域３０Ｓに加えて（ソフトウェアコンポーネントと関連するストレージ）、マイクロカーネル５７、汎用テレビ（放送、通信）ライブラリ５６と限定的実行決定装置２０を含む「ミドルウェア」（アプリケーションとネットワークソフトウェアとの間において透過的に用いられるソフトウェア）、及びプラグインのための格納領域３０Ｐから構成される。

動作に関して、送信されたオーディオビジュアルストリーム１６を受信すると、ドライバ５４、チューナ（図示せず）及びＶＢＩスライサ（図示せず）は、映像及び音声プログラムから情報データを分離する。その後、このオーディオビジュアルプログラムは視聴者に提供され、１つしかない場合には、対話型サービス１１が画面上への表示候補となる。限定的実行決定装置２０により適用されるフィルタリングプロセスが行われるのは、この時点においてである（図７）。

フィルタリングプロセスは、以下のステップから構成される。すなわち、
−欧州におけるアナログテレビの領域において必要とされるプロトコルスタックの形式によるＡＴＶＥＦパケットの受信、ＩＤＬ（Ｉｎｄｅｐｅｎｄｅｎｔ Ｄａｔａ Ｌｉｎｅ）Ｂレベルパケットの抽出、ＩＤＬ Ｂ及びＳＬＩＰ（Ｓｅｒｉａｌ Ｌｉｎｅ Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）レイヤのカプセル解除、必要に応じたエラーコード（ＦＥＣ、順方向誤り訂正）の検証及び訂正、汎用ライブラリ５６によるブラウザ５５に対する正当に取得されたＵＤＰ（Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ Ｄａｔａ Ｐｒｏｔｏｃｏｌ）／ＩＰパケットの指示
パケットがＡＴＶＥＦ通知６１を介し聴取チャネルに到着した場合（ステップ４１Ａ）、ブラウザ５５はそれをカプセル解除し、ＳＤＰペイロードを回復する。
−限定的実行決定装置２０は、様々なチェックを実行し、対象となるサービス１１を実行するのに必要とされるプラグインのリスト及びパラメータを回復する（ステップ４２Ａ）。それはまた、対話型サービス１１の寿命とプラグインのダウンロードを強制可能な標識の値を回復する（ＳＤＰペイロードのｔｖｅ＿ｅｎｄフィールド、属性ｔ＝＜ｓｔａｒｔ ｔｉｍｅ＞＜ｓｔｏｐ ｔｉｍｅ＞により指定された値）。
−装置２０は、埋め込みリストと必要とされるプラグインのリストを比較する（ステップ４３Ａ）。
−送信されたサービスにより必要とされるプラグインが、埋め込みプラグインのリストに存在する場合、サービス１１が承認される。すなわち、ブラウザ５５はＡＴＶＥＦコンテンツ６２に関する聴取チャネルと（ステップ７１Ａにおけるコンテンツ６２の回復）、トリガー６３に関する聴取チャネルと（ステップ７２Ａにおけるトリガー６３の回復）をオープンする。これにより、対話的サービス１１が表示される（ステップ４４Ａ）。
−そうでない場合、装置２０は、欠落している必要とされるすべてのプラグイン１３をダウンロードする時間を推定し（ステップ７３Ａ）、それをサービスの寿命と比較する（ステップ４５Ａ）。
−この時間（プラス定数）がサービス１１の期日より大きい場合、装置２０は、プラグインダウンロード強制標識の値をチェックし（ステップ４５Ａ’）、場合に応じて、プラグイン１３のダウンロードが実行され（強制ダウンロードに対するステップ４６Ａ’）、サービス１１は取得及び表示される状況にはない（ステップ４７Ａ）。プラグイン１３がダウンロードされる場合、それらはその後、永久メモリにインストールされる。
−前記時間（プラス定数）がサービス１１の期日より小さい場合、プラグインのダウンロードが実行され（ステップ４６Ａ）、これと並行して、サービス１１が取得される（ステップ７４Ａ、このとき、ブラウザ５５は、ＡＴＶＥＦコンテンツ６２に関する聴取チャネルと、トリガー６３に関する聴取チャネルとをオープンする）。プラグインが端末５２上にインストールされると、ブラウザ５５は、トリガー６３上でオープンされたチャネルを聴取し、表示トリガーが受信されると（ステップ７５Ａ）、サービス１１を表示する（ステップ４４Ａ）。

必要であるが利用可能でないプラグイン１３をダウンロードするための時間の推定及びダウンロード方法が、詳述される。

プラグイン１３は、配信（配信器５１または他の送信機から）またはサーバとの双方向通信（サービス運営者５３または他のソースからのリターンチャネルを介し）の何れの２つのタイプのチャネルを介し回復することが可能である。

配信によって、サービス運営者５３または端末のオペレータは、このタイプの更新に対する既知の手段を利用することが可能である。例えば、何れかから送信されるプラグインを回復する手段を記述する通知を端末５２に送信する。端末５２は、この通知を解析することにより、欠落したプラグイン１３をダウンロードする手順を適用することができる。この方法の効果は、電話接続が不要なため、それが端末５２のユーザにコストがかからないとういうことである。このような方法のある実現形態は、更新データの送受信方法を説明する文献ＥＰ−１．２４５．１１６に記載されていることが見つけられる。開示された技術によると、更新データが以降において送信される時点を示す通知信号が当該データの送信に先行する。

サーバとの通信によって、端末のオペレータまたはサービス運営者５３は、このタイプの更新に対し既知の手段を利用することが可能である。例えば、オンラインサーバ上の何れかにおいて利用可能なプラグイン１３を回復する手段を端末５２に記述する通知が送信される。端末５２は、この通知を解析することにより、電話またはＡＤＳＬ（Ａｓｙｍｍｅｔｒｉｃ Ｄｉｇｉｔａｌ Ｓｕｂｓｃｒｉｂｅｒ Ｌｉｎｅ）チャネルを介し欠落しているプラグイン１３をダウンロードする手順を適用する。他の機構によると、サーバとの接続が開始され、端末５２とサーバとの間で端末５２のユーザに透過なネゴシエーションが開始される。その後、サーバは端末５２に欠落しているプラグイン１３を供給する。

推定ダウンロード時間は、プラグイン１３のサイズとそれを回復するのに用いられるチャネルタイプ（ビットレート）に依存する。サイズの回復に関して、本方法は、配信チャネル、サーバとの双方向通信、あるいは埋め込み情報の利用を伴いうる。

配信によって、端末のオペレータまたはサービス運営者５３は、最新の利用可能なプラグインバージョンの各々の現在のサイズを示す通知ストリームを連続的に送信する。この方法の効果はそれのスピードであり、オンラインサーバに接続し、問い合わせる必要がないためである（時間の浪費）。

サーバとの通信によって、端末５２は、既知のすべてのプラグインサイズを指示することが可能なオンラインサーバと接続するよう構成される。この方法の効果は、データを連続的に送信する必要がないことによる帯域幅の節約である。

埋め込み情報の利用では、端末５２は、永久メモリに埋め込まれた既知のプラグイン記述テーブルを有する。このテーブルは、例えば、視聴者が接続すると、オンラインにより、あるいは配信により（各ダウンロードセッションのストリームにおけるテーブルの送信）、定期的に更新することが可能である。この方法の効果は、それが必要とされるプラグイン１３のサイズを即座に提供するということである（このとき、端末５２は迅速に決定を行うことが可能である）。

様々な方法を組み合わせることが可能である。例えば、端末５２は、埋め込みテーブルの必要なプラグイン１３のサイズを検出することにより開始される。このプラグイン１３がそこにない場合（テーブルが古すぎて）、端末５２は、情報を回復するためオンラインサーバとの接続を開始する。

２．ＭＨＰサービス
この系統の実施例は、デジタル領域のみに関する。

対話型サービス１１の生成に関する実現形態では（情報組み込み装置３１）、使用されているアプリケーション（例えば、埋め込みＦｌａｓｈ４アニメーション）のタイプに関する情報が、例えば、フォームから当該サービス１１の発行時に入力される。これにより、対話型サービス１１のソースと当該サービスの正確な実行に関するすべての情報（トリガーのタイミング、必要とされるプラグインのリストなど）を含むファイルが生成される。ＭＰＥＧ（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ）ストリームの生成により、当該ファイルはインポートされ、各種情報がストリーム記述子に入力される。この情報のフォーマットは、ＭＨＰ規格によるデジタルテレビ領域で用いられるものである。

以下において、対話型ＭＨＰ端末８２（図８）における限定的実行決定装置２０の実現形態が詳述される。端末８２は、
−ドライバ８４と、
−汎用テレビライブラリ８６（「サービス情報」や通信などのためのＤＶＢ−ＳＩデータ）、限定受信ユニット８９及び限定的実行決定装置２０を含むミドルウェア８８と、
−ＤＶＢ−ＨＴＭＬユニット９０に付属する提示エンジン８５（ブラウザ）と、
−ＤＶＢ−Ｊユニット９０’に付属する対話型エンジン８５’（Ｊａｖａ（登録商標） ＶＭ）と、
−マイクロカーネル８７と、
−対話型サービスとプラグインのそれぞれにための格納領域３０Ｓ及び３０Ｐと、
を有するソフトウェア及びストレージコンポーネントから構成される。

動作に関して、送信されたＭＨＰストリーム１７を受信すると、ドライバ８４、チューナ及びデマルチプレクサを利用して、受信したストリーム１７のコンテンツを記述する通知を回復するため、ＭＰＥＧ２ストリームからＰＭＴ（Ｐｒｏｇｒａｍ Ｍａｐ Ｔａｂｌｅ）をまず抽出する。

その後、一方ではオーディオビジュアルプログラムが視聴者に提供され、他方では、１つ存在する場合、対話型サービス１１が画面上への表示候補となる。限定的実行決定装置２０のフィルタリングプロセスが適用されるのはこの時点である。

本方法のステップは以下のように記述することができる（図９）。すなわち、
−オーディオビジュアル及びサービスストリームのオープン（ステップ９１及び９２）と、通知を含むＭＰＥＧ２パケットの抽出
−ドライバ８４による通知の回復とライブラリ８６への送信を実行し（ステップ９３）、サービス１１の利用性を検出し（ステップ９４）、限定的実行決定装置２０に通知する（ステップ９５）。
−ＳＩを管理するためのライブラリ８６を利用して、ｄａｔａ＿ｂｒｏａｄｃａｓｔ＿ｉｄ記述子を回復し、サービス１１が視聴者の画面上に正しく表示されるのに必要なプラグインのリストを編集する。この処理はミドルウェア８８により駆動される（ステップ４２Ｂ）。
−その後、このリストは解析され、装置２０により埋め込みプラグインの所持リストと比較される（ステップ４３Ｂ）。
−送信されたサービスにより必要とされるプラグインが、埋め込みプラグインのリストに存在する場合、サービス１１は受け入れられる。そうでない場合、装置２０は、ＡＴＶＥＦに対し説明した方法と同様にして、欠落しているプラグイン１３のダウンロードが必要か決定する。図示された例と同様に、装置２０がダウンロードを実行しないことを決定した場合、サービス１１は無視される（ステップ４７Ｂ）。

３．ＰＣ領域
主たる関心は、ＰＣ上のテレビの対話型アプリケーションにある（ＰＣは配信ネットワークに接続されている）。ＨＴＭＬページが発行されると（情報組み込み装置３１）、名前と値のフィールドのペア「Ｎａｍｅ／Ｖａｌｕｅ」が、サービス１１を実行するのに必要なプラグインを指定するよう定義される。これらのペアは、以下のようにＨＴＭＬページのヘッダに含まれるメタデータに導入される。

＜ＭＥＴＡ ＮＡＭＥ＝“ｍｅｄｉａＦｏｒｍａｔ”ＣＯＮＴＥＮＴ＝“＜Ｐｌｕｇｉｎ＿Ｎａｍｅ＞，［ｖｅｒｓｉｏｎ］”＞
ここで、＜Ｐｌｕｇｉｎ＿Ｎａｍｅ＞は必須パラメータであり、［ｖｅｒｓｉｏｎ］は必要に応じて、必要とされるプラグインの最小のバージョンを示す任意的パラメータである。

欠落しているプラグイン１３強制的にダウンロードされる必要があるか否かの標識が、以下のように挿入される。

＜ＭＥＴＡ ＮＡＭＥ＝“ｍｅｄｉａＤｏｗｎｌｏａｄ”ＣＯＮＴＥＮＴ＝“＜ＴＲＵＥ ｏｒ ＦＡＬＳＥ＞”＞
ここで、ＴＲＵＥの場合、欠落しているプラグイン１３の強制ダウンロードが行われ、ＦＡＬＳＥの場合、サービス１１の寿命にしたがってプラグイン１３をダウンロードするかどうかブラウザ１０５により決定される。

サービスの寿命のコンセプトもまた挿入される。すなわち、
＜ＭＥＴＡ ＮＡＭＥ＝“ＳｅｒｖｉｃｅＶａｌｉｄｉｔｙＷｉｎｄｏｗ” ＣＯＮＴＥＮＴ＝“＜Ｓｔａｒｔ Ｔｉｍｅ＞，＜Ｅｎｄ Ｔｉｍｅ＞”＞
ＨＴＭＬページは、例えば以下のフォームをとる。すなわち、

限定的実行決定装置２０を実現可能なＰＣ１０２（図１０）は、装置２０を搭載したブラウザ１０５と、プラグインとサービスのそれぞれに対する格納領域３０Ｐと３０Ｓとから構成される。ブラウザ１０５は、上述のように規定されたＮａｍｅ／Ｖａｌｕｅペアを回復及び理解することができるよう構成される。

動作に関して、ＰＣ１０２は、上述のようなヘッダを有するＨＴＭＬページから構成されるストリーム１８を受信する。その後、ブラウザ１０５は、必要なプラグイン１３をダウンロード及びインストールすべきか決定し、ＡＴＶＥＦに対し説明された方法と同様にして対応するサービス１１を表示する。利用可能またはダウンロードされたプラグインは、常にハードディスク上にインストールされる。

図１は、本発明による限定的実行決定装置を実現する送受信システムの概略図である。 図２は、図１の限定的決定装置をより詳細にブロック図により表す。 図３は、図１のシステムで利用される本発明による情報メッセージ編集装置を示す。 図４は、図１及び２の限定的決定装置によるサービスの表示に関する決定プロセスをフロー図により示す。 図５は、ＡＴＶＥＦ規格に適用される対話型端末を有する限定的実行決定装置の第１実施例による図１のシステムのソフトウェア実現形態を表す。 図６は、図５の対話型端末を詳述する。 図７は、図５及び６の対話型端末の限定的実行決定装置によるサービスの表示及びプラグインのダウンロードのための決定プロセスをフロー図により示す。 図８は、ＭＨＰ規格に適用される図１及び２の限定的実行決定装置の第２実施例を搭載する対話型端末を詳述する。 図９は、図８の対話型端末を利用して取得された手順の典型的なステップシーケンスを示す。 図１０は、図１及び２の限定的実行決定装置の第３実施例を搭載するパーソナルコンピュータを図解的に表す。

Claims (8)

1. 通信ネットワークを介し受信される所定のスタート時間とエンド時間とを有するサービスの実行のための装置であって、
   前記サービスの実行前に前記サービスに関する情報であって、前記サービスを実行するのに要するコンピュータプログラムの特定を可能にする情報を受信するため設けられ、情報ソースから前記サービスに関する情報を受信するモジュールと、
   前記受信した情報から、前記情報に関するサービスを実行するのに要するコンピュータプログラムを特定するモジュールと、
   前記特定されたコンピュータプログラムのローカル記憶スペースにおける利用性をチェックするモジュールと、
   前記サービスに必要とされるコンピュータプログラムが前記ローカル記憶スペースにおいて利用可能である場合、前記サービスの実行を許可する、サービスの実行のための選択的決定モジュールと、
   を有し、
   当該装置はさらに、
   前記コンピュータプログラムが前記ローカル記憶スペースにおいて利用可能でない場合、前記サービスに対し必要とされるコンピュータプログラムのダウンロードをトリガーするコンピュータプログラムをコンピュータプログラムソースから取得するモジュールと、
   前記サービスに関する情報に少なくとも従って、前記サービスに必要であって、前記ローカル記憶スペースにおいて利用可能でない前記コンピュータプログラムのダウンロードを許可又は回避するコンピュータプログラムを前記コンピュータプログラムソースから取得する自動選択的決定モジュールと、
   を有し、
   前記サービスに関する情報は、前記サービスの実行の有効性に関する時間情報を含み、
   前記ダウンロードは、当該ダウンロードが前記時間情報から抽出可能な前記サービスの所定の時点前に完了すると予想される場合には許可され、そうでない場合には回避され、
   前記ダウンロードが前記所定の時点前に完了するかの予測は、前記サービスに必要であって、前記コンピュータプログラムのための前記ローカル記憶スペースとローカル受信能力とにおいて利用可能でない前記コンピュータプログラムのサイズに関する情報から推定されることを特徴とする装置。
2. 請求項１記載の装置であって、
   前記所定の時点は、前記サービスの実行の有効性の終わりを指定することを特徴とする装置。
3. 請求項１または２記載の装置であって、
   前記所定の時点は、前記サービスの実行の有効性の始まりを指定することを特徴とする装置。
4. 請求項１または２記載の装置であって、
   前記ダウンロードが前記所定の時点前に完了するかの予測は、前記自動選択的決定モジュールにより実行されることを特徴とする装置。
5. 請求項１乃至４何れか一項記載の装置であって、
   前記サービスに関する情報は、始動値と非始動値とを有する少なくとも１つの強制ダウンロード標識を有するため、前記自動選択的決定モジュールは、前記強制ダウンロード標識が前記始動値を有する場合、前記ダウンロードを強制許可するよう構成されることを特徴とする装置。
6. 請求項５記載の装置であって、
   前記自動選択的決定モジュールは、前記コンピュータプログラムの前記ローカル受信能力と前記サイズに従って、前記ローカル記憶スペースにおいて利用可能でない必要とされるコンピュータプログラムのダウンロード時間を推定し、前記ダウンロードが前記サービスの少なくとも部分的な以降の実行を許可するとき、前記ダウンロードを許可するよう構成されることを特徴とする装置。
7. 請求項１乃至６何れか一項記載の装置であって、
   前記サービスは、コンテンツ及びサービスの通知メッセージを有するため、前記受信モジュールは、前記サービスの通知メッセージにより前記サービスに関する情報を受信するよう構成され、
   前記特定するモジュールは、前記サービス通知メッセージから前記情報を抽出するよう構成されることを特徴とする装置。
8. 請求項１乃至７何れか一項記載の装置を有することを特徴とするセットトップボックス。

Images