JP2010114928A

JP2010114928A - テレビジョンシステムにおいてメニューを表示する方法

Info

Publication number: JP2010114928A
Application number: JP2009297865A
Authority: JP
Inventors: Vito Mario De; ヴィトー，マリオデ; Louis Gregoire; グレグワール，ルイ
Original assignee: Thomson Multimedia SA
Current assignee: Technicolor SA
Priority date: 1995-11-30
Filing date: 2009-12-28
Publication date: 2010-05-20
Anticipated expiration: 2016-11-29
Also published as: MX9803655A; FR2741972A1; DE69613854T2; JP4947671B2; CN1203002A; CN1136727C; JP2000500942A; EP0864226A1; WO1997020431A1; JP4568384B2; BR9611803A; JP2012138919A; FR2741972B1; US20020080160A1; DE69613854D1; EP0864226B1; US6452616B1; JP4947641B2; JP2007195202A

Abstract

【課題】有料テレビジョン放送に用いられるスマートカードのデータを書き換える手段を提供する。
【解決手段】スマートカードに格納されたユーザインターフェースモジュール全体をデコーダによりロードして格納する段階であり、ユーザインターフェースモジュールがスマートカードに格納されたユーザ向け情報を参照するデータ構造を有し、該データ構造がメニューを表示させる段階、デコーダにより、主ユーザインターフェースと格納されたユーザインターフェースモジュールとの間の関係を確立して、ユーザによるユーザインターフェースモジュールへのアクセスを可能とし、メニューのリストのうち少なくとも１つのメニューをテレビジョンシステムの画面上に表示する段階、ユーザインターフェースモジュールを通じてユーザにより発せられたコマンドに応じて、デコーダとスマートカードとの間で、ユーザ向け情報の部分を順次交換する段階、を有する。
【選択図】図３

Description

本発明は、テレビジョン環境、特に、デジタルテレビジョン環境においてユーザインターフェースをロードする方法及びメニューを表示する方法に関する。本発明は、また、上記方法を実行する装置及び対応するスマートカードにも関する。本発明は、例えば、条件付きアクセステレビジョンシステムと共に使用される。

マイクロプロセッサカード（スマートカード）を有料テレビジョンシステムで用いることは公知である。かかるカードは、ユーザによりアクセスされ最終的にはユーザにより変更されるデータを含む種々のデータを収容する。例えば、カードは番組リストへのアクセス権を格納することができる。システムによっては、この情報は、デジタル送信システムの特定のデータパケットで又はアナログ送信システムのアナログビデオ信号の垂直ブランキング間隔（ＶＢＩ）で変調されて、放送局によりビデオデータと共に送信される。データが受信されるとそのデータはカードに格納される。ユーザは、この情報を直接変更することができなくとも、参照したいと望むことがある。カードに格納される情報の他の例は、親アクセスコード又は個人パスワードである。かかる情報は、対応する権限を有するユーザにより変更され得る。

米国においてデジタル衛星受信用としてＲＣＡブランドで販売されているデジタルテレビジョンデコーダ等のテレビジョンデコーダは、洗練されたユーザインターフェースを備えている。かかるユーザインターフェースは、一般に、番組案内及びデコーダ機能プログラミングツールを含み、デコーダのグラフィック機能を用いてユーザフレンドリー化を図っている。ユーザインターフェースの階層構造は、一連のメニューとして、又は、居間やショッピングモール等の親しみのある表示の下でユーザに提示される。

米国特許第５，３６７，５７１号はプラグイン拡張カードを備え、コードがダウンロードされる加入者端末に関する。

ＰＣＴ特許出願ＷＯ９４／１４２８４は、テレビ番組配送システムにおける再プログラム可能端末に関する。メニューテンプレートが生成され、この端末に送信されて格納される。
米国特許第５，３６７，５７１号公報ＰＣＴ特許出願ＷＯ９４／１４２８４

特定情報をユーザに提示し、かつ／又は、ユーザがこの情報を変更するには、ユーザインターフェースの一部がこの情報に適合されていることが必要である。ユーザに提供されるサービスの進展に伴い、かかる情報の性質は変化する。ユーザインターフェースは、かかる新しいタイプの情報の処理に常に適合されているとは限らない。このことは、特に、スマートカードに格納される情報にあてはまる。なぜなら、かかるカードは、本来的に交換可能だからである。新しいカードバージョンは、従来は使用できなかったサービスに関するデータを担っている可能性がある。

本発明は、主ユーザインターフェースを備えるデコーダと、該デコーダと協働する取り外し可能なスマートカードとを備えるテレビシステムにおいてユーザインターフェースをロードする方法又はメニューを表示する方法であって、
−前記スマートカードに格納されたユーザ向け情報を参照するデータ構造からなる前記スマートカードに格納されたユーザインターフェースモジュール全体を前記デコーダによりロードして格納し、
−前記デコーダにより、前記主ユーザインターフェースと前記格納されたユーザインターフェースモジュールとの間の関係を確立してユーザによる前記インターフェースモジュールへのアクセスを可能とし、
−前記ユーザにより前記ユーザインターフェースモジュールを介してコマンドが発せられると、前記デコーダと前記スマートカードとの間で、前記情報の部分を順次交換する、各段階よりなることを特徴とする方法に関する。

パラメータ及びデータを、これらのパラメータ及びデータを管理するユーザインターフェースモジュールと共にスマートカードに格納することにより、また、デコーダのユーザインターフェースとカードに格納されたユーザインターフェースモジュールとの間の関係を確立することにより、ユーザインターフェースの改良を可能とする柔軟な解決が得られる。

本発明は、更に、特定ユーザのカードに格納されたデータ及びパラメータに従って、ユーザインターフェースの各ユーザへの適合を可能とする。

ユーザインターフェースモジュールのロード及び格納は一度だけ実行される。ユーザインターフェースモジュールの一部の更なるロードは不要であり、スマートカードとの交換は（ユーザインターフェースに関する限り）、パラメータ値の交換に限られる。従って、ユーザによるユーザインターフェースの使用の間のカードのメモリへのアクセス頻度及び期間が低減される。

本発明の実施例の変形例によれば、前記ロードして格納する段階を、前記デコーダが、スマートカードインターフェースに前記スマートカードが存在することを最初に検出した際に実行する。
従って、前記モジュールのロード及び格納は、デコーダ及びカードが作動可能になると直ちに実行され、ユーザとデコーダとの間での相互作用が行われる前にデコーダ及びスマートカードの資源が開放される。

本発明の実施例の変形例によれば、前記主ユーザインターフェースと前記ユーザインターフェースモジュールとの間の前記関係を確立する前記段階は、前記ユーザインターフェースモジュールへの少なくとも１つのエントリーポイントを識別し、前記ユーザインターフェースモジュールへのアクセスを、前記少なくとも１つのエントリーポイントを通して前記主ユーザインターフェースにおいて前記ユーザに表示する段階よりなる。

上記実施例の変形例によれば、スマートカードに格納された前記情報はユーザ定義データよりなる。

上記実施例の変形例によれば、前記ユーザインターフェースモジュールはオブジェクトの少なくとも１つのリンクドリストとして格納される。

上記実施例の変形例によれば、オブジェクトの前記少なくとも１つのリンクドリストは、一連の画面よりなり、各リンクドリストの少なくとも１つの画面は前記エントリーポイントの１つよりなる。

上記実施例の変形例によれば、前記主ユーザインターフェースは前記少なくとも１つのエントリーポイントへの所定のポインタよりなり、前記デコーダにより前記主ユーザインターフェースと前記ユーザインターフェースモジュールとの間の関係を前記デコーダにより確立する前記段階は、前記ユーザインターフェースモジュールがロードされた場合にのみ、前記ユーザが前記エントリーポイントへのアクセスのトリガーを起動するのを許可する段階を更に備える。上記実施例の変形例によれば、前記主ユーザインターフェースと前記ユーザインターフェースモジュールとの間の関係を確立する前記段階は、前記主ユーザインターフェースのオブジェクトへリンクされるべき少なくとも１つのオブジェクトを前記スマートカードからロードする段階を更に備える。

この特定の場合において、主ユーザインターフェースは、ユーザに対して表示される予めプログラムされたアクセス手段を前もっては備えていない。ユーザインターフェースモジュールがダウンロードされた際、デコーダは、主ユーザインターフェースとユーザインターフェースモジュールとの間のブリッジを確立する機能を有するオブジェクトを探索する。これらのオブジェクト（特定の「ボタン」又はメニュー選択）はユーザに表示される。

本発明は、メモリと、マイクロプロセッサと、入力／出力手段とを備えるスマートカードであって、ユーザ向けデータと、情報を前記ユーザに提示するユーザインターフェースモジュールと、前記ユーザインターフェースモジュールから前記スマートカードが挿入される装置の主ユーザインターフェースモジュールへのブリッジを識別するデータとを備えることを特徴とするスマートカードにも関する。

本発明は、主ユーザインターフェースと、メモリと、メモリカードインターフェースと、ユーザコマンド入力装置とを備えるビデオ受信機であって、
− 前記メモリカードインターフェースに挿入されたメモリカードに格納されたユーザインターフェースモジュール全体をダウンロードする手段と、
− 前記ユーザインターフェースモジュールを格納するメモリと、
− 前記主ユーザインターフェースと前記ユーザインターフェースモジュールとの間の関係を確立する手段とを備えることを特徴とするビデオ受信機にも関する。

本発明に従えば、本発明の課題を達成することができる。

図面に示す非限定的な実施例についての以下の説明により、本発明はより良く理解され、他の特徴が明らかとなろう。

図１は、テレビデコーダのブロック図であり、
図２は、デコーダユーザインターフェースの一例であり、
図３は、スマートカードに格納されたユーザインターフェースモジュールのツリー構造であり、
図４は、ユーザインターフェースモジュールをデコーダのユーザインターフェースに統合するための主要ステップを示すフローチャートである。

実施例はデジタルテレビジョン環境に関して説明される。もちろん、本発明はかかる環境に限定されるものではなく、他の用途に容易に適合され得る。

デジタルテレビジョンシステムで用いられるデコーダが図１に示されている。かかるシステムにおいて、ビデオ、音声、及び他のデータはデータパケットで伝送される。このデコーダは、衛星（図示せず）を経由して放送局から信号を受信するアンテナ１に接続されている。信号は公知の如くチューナ２、復調器３、及び誤り訂正回路４へ転送される。復調され訂正されたデータパケットは、デマルチプレクサ５に転送される。デマルチプレクサ５の役割は、受信されたデータパケットを分析し、そのデータパケットの内容を適当なアプリケーションへ発信することである。デマルチプレクサ５はマイクロプロセッサ２３により制御される。マイクロプロセッサ２３は、デマルチプレクサのパケットフィルタリングパラメータをプログラムする。データパケットのフォーマットは例えば「ＭＰＥＧ２システム」標準で与えられるフォーマットである。

あるアプリケーションに転送されるべく選択されたデータパケット又はその一部はメモリ６に格納される。メモリ６は、各アプリケーション向けのバッファ領域を含んでいる。データはデマルチプレクサによりこのバッファ領域に書き込まれ、対応するアプリケーションにより読み出される。

「アプリケーション」という語は、ハードウェアアプリケーションだけではなくソフトウェアアプリケーションを指す場合にも用いられる。ソフトウェアアプリケーションは、典型的には番組案内である。番組案内は、放送会社から送信され、近い将来のイベントについてユーザに知らせる情報に依存する。かかるアプリケーションは、マイクロプロセッサ２３により実行される。ハードウェアアプリケーションには、音声デコーダ１６、ビデオデコーダ１７、テレテクストデコーダ１８及び条件付きアクセスサブシステム（７、８、９、及び１０）が含まれる。

マイクロプロセッサ２３はＲＯＭ１２及びＲＡＭすなわち再プログラム可能ＲＯＭ１９に接続されている。バッファメモリ６からのデータは、マイクロプロセッサ２３の命令によりメモリ１９に直接転送される。

マイクロプロッサは、リモートコントロール１１からの信号に応答する赤外リモートコントロールインターフェース２４に接続されている。マイクロプロセッサは、サブタイトル、メニュー及びグラフィックを生成するオンスクリーン表示生成回路１５をも制御する。

デコーダの別の機能部は、公衆電話交換網（ＰＳＴＮ）１４に接続されたモデム１３である。

ビデオデコーダ１７、テレテクストデコーダ１８、又はオンスクリーン表示生成回路１５により提供されるビデオ信号は、マイクロプロセッサ２３の制御の下で、マルチプレクサ２０によりマルチプレクスされる。マルチプレクサ２０は、ビデオカセットレコーダ２１及びテレビジョン２２に接続されたコネクタへ、音声デコーダ１６により提供された音声信号と共にビデオ信号を出力する。

条件付きアクセスサブシステムはデスクランブラー回路７、検証回路８、スマートカードインターフェース９、及び取り外し可能スマートカード１０を備えている。

ユーザが対応するアクセス権を有するならば、デマルチプレクサ５により受信されたスクランブル化データパケットは、バッファメモリ６に格納される前に、先ず、デスクランブラー回路７によりデスクランブルされる。このアクセス権はスマートカード１０に格納され、条件付きアクセスサブシステム行きの特定のデータパケットを通して放送会社により更新されている。検証回路８は、デコーダとスマートカードとの間の全ての通信を管理し、デスクランブラー回路を制御する。検証回路８は、また、例えばフィアットシャミール（Fiat-Shamir）インタラクティブアルゴリズムを用いてスマートカード自体の真正さをも検証する。スマートカードとの通信は、周知のＩＳＯ７８１６プロトコルに従っている。

スクランブル及びデスクランブル処理は以下の通りである。

発信側では、放送者は、所与のコードワードを用いた所与のスクランブル手法にしたがってデータパケットペイロードをスクランブル化する。スクランブル化されたデータは、適当なデータパケットで伝送される。コードワードは暗号化され、やはりデータパケットで伝送される。これは、資格制御メッセージ（Entitlement Control Messages; ＥＣＭ）と呼ばれる。

コードワードは頻繁に、例えば、数秒毎に変化する。

放送会社は各デコーダ又はデコーダ群へアクセス権をも送信する。対応するメッセージは資格管理メッセージ（Entitlement Management Messages;ＥＭＭ）と呼ばれる。

デコーダ側では、所与のデコーダに対応するＥＭＭは、デマルチプレクサによりフィルタリングされ、スマートカードへ転送される。スマートカードは対応するアクセス権を更新する。

スクランブル化サービスが受信されると、そのサービスに対応するＥＣＭがフィルタリングされスマートカードへ転送される。スマートカードは、格納されたアクセス権がその特定のサービスへのアクセスを認可するか否かを検査する。検査結果が肯定的であれば、スマートカードはＥＣＭのコードワードを解読し、それを検証回路８を介してデスクランブラー回路７へ転送する。検査結果が否定的であれば、マイクロプロセッサ２３は、検証回路８を介して通知され、対応するメッセージがユーザに対して表示される。

メモリ１２は、グラフィックユーザインターフェースを生成するのに必要なプログラム及びデータを収容している。リモートコントロール１１の「メニュー」ボタンを押すことにより開始されるデコーダのユーザインターフェースは、本発明によれば、ツリー状構造を有している。

内部的には、この構造は、「ユーザインターフェースオブジェクト」、すなわちＵＩオブジェクトを用いて表される。本実施例において、ＵＩオブジェクトは、画面上に表示され、ユーザにより起動された場合にマイクロプロセッサの反応をトリガーする能力を有するオブジェクトである。この起動は、例えば、画面上のメニュー項目が強調表示されているときにリモートコントロール１１の「ＯＫ」ボタンを押すことにより行われる。オブジェクトは、画面上の項目の起動の後、ユーザインターフェースがどのように振る舞うかを規定する。

ユーザインターフェース構造可視的表示すなわちグラフィック表示（フォント、背景グラフィックス等）については、記載を明確にするうえで必要な場合を除き詳細には説明しない。

オブジェクトのリンクドリストは、オブジェクトが別のオブジェクトを参照するオブジェクト群である。例えば、第１及び第２のオブジェクトの間の特定のリンクは、第１のオブジェクトが起動されたならば、第２のオブジェクトが画面上の第１のオブジェクトに置き換わるべきであることを示す。かかる種類のリンクは、ユーザが、リンク及びオブジェクトからなる予め規定された一連の経路をたどりながら１つのオブジェクトから別のオブジェクトへ進んで行くことを可能とする。

デコーダの常駐ユーザインターフェースは、かかるオブジェクトのリンクドリストの１つ、又は、数個の独立したリストから構成される。

オブジェクトのリンクドリストから構成された主ユーザインターフェースの構文は以下の通りである。

MainUI()｛
for(i=0;i<N;i++)UIList()
｝

UIList()｛
for(i=0;i<N;i++)Screen()
｝

Screen()｛
Trigger;
ExplanatoryText()
｝

List()｛
for(i=0;i<N;i++)Choice();
for(i=0;i<N;i++)VariableField();
for(i=0;i<N;i++)InputField()
｝

Choice()｛
ExplanatoryText();
DestinationScreenNumber;
TriggerEvent
｝
VariableField()｛
ExplanatoryText();
GetValueFunctionPointer
｝

InputField()｛
ExplanatoryText();
ProcessValueFunctionPointer
｝

ExplanatoryText()｛
data bytes
｝

"MainUI"はデコーダユーザインターフェース全体を記述し、"UIList"はリンクドオブジェクトのリストを記述する。

"Screen"は表示されるべき全画面を記述する。別の画面へ移動するには、ユーザは反応しなければならない。画面番号はUIListにおける画面のランクである。画面は数個のリストから構成される。

"Trigger"は、画面表示をトリガーすることになる予め規定されたイベントを特定する。ヌルトリガーの存在は、画面が別の画面からのみアクセスされ得ることを意味する。Triggerは、エントリーポイント画面（以下に述べる主メニュー画面はエントリーポイント画面の一例である）に対して非ヌルである。

"List"は画面のList領域及びその振る舞いを記述する。Listは、Choice、VariableFields、及び、InputFieldsより構成される。従って、Listは、イベントや番組等の情報の単純なリストであってもよく、あるいは、ユーザがオプションを選択するメニューであってもよい。

"Choice"はユーザに提供される可能な選択を記述し、この選択が起動された場合に表示されるべき目的画面を収容している。

"VariableField"は、変数の値が表示されるべき画面領域を記述する。例えば、かかる変数は、エベントのタイトル若しくはその持続時間、又は個人パスワードである。この構造は、また、説明テキスト及びファンクションコールを収容している。例えば、パスワードに対する説明テキストは「あなたの個人パスワードは：”であり、ファンクションコールは、変数の値を格納された場所から取り出すためのサブルーチンを呼び出す。デコーダの主ユーザインターフェースに関する限り、これは一般にはメモリ１９である。

"InputField"は、ユーザが処理のため値を入力することができ又は入力すべき画面領域を記述する。やはり、この構造は、説明テキスト、及び、要求された情報の処理及び最終的にはその格納をトリガーするファンクションコールを含んでいる。

"DestinationScreenNumber"は、UListでの画面のランクである。このパラメータは、所与のリンクドリスト内での１つの画面から別の画面へのリンクを特定する。

"TriggerEvent"は、別のリンクドリストに入るべく所与のリンクドリストUlistが起動されるべきか、又は、リンクドリストの所与の画面がそのリンクドリスト内からのみ呼び出されるべきかを特定するパラメータである。このパラメータは、主ユーザインターフェースリンクドリストの１つから出て、ユーザインターフェースモジュールのリンクドリストに入るのに用いられる。このパラメータは、リンクドリストへのエントリーポイントを規定する。

"GetValueFunctionPointer"及び"ProcessValueFunctionPointer"は、それぞれ、変数の値を読み出す関数、及び、値、又は、より一般的には、ユーザ入力を処理する関数を指す。

各リンクドリストは数個のエントリーポイントを有する。各エントリーポイントは、ユーザインターフェースセッションの開始を表す。

図２は、スマートカードが挿入されていない場合のユーザインターフェースの主メニュー画面を示す。上述の如く定義された構造を用いると、この画面は、Triggerがリモートコントロールの「メニュー」ボタンに対応する"Screen"構造に対応している。

タイトル及び指示はExplanatoryTextにより定義されている。

画面は、８つのChoice（番組案内、アトラクション、メールボックス、オプション、副音声、条件付きアクセス、ヘルプ、終了）を備える単一のメニューを有している。メニューは、VariableField及びInputFieldの何れも有していない。各ChoiceのDestinationScreenNumberは適当なサブメニュー画面を指している。

各入力フィールドに関連付けられた機能は、強調表示された選択の起動に反応する。この場合、唯一の認可された入力は（もちろん方向キーを除いて）、対応するリモートコントロールボタンの「ＯＫ」コードである。

使用できない選択は灰色で表示される。デコーダのスマートカードインターフェースにスマートカードが存在しない場合のメニューの条件付きアクセス項目の場合に、そのように表示される。

本発明によれば、スマートカードは、その機能、特に、収容する変数及びパラメータに関連するユーザインターフェース構造を収容している。以下の記載において、カードに格納されたユーザインターフェース構造を、「ユーザインターフェースモジュール」又は、単に「モジュール」という語で表し、デコーダの常駐ユーザインターフェースを「主ユーザインターフェース」と称する。

主ユーザインターフェースは、通常は、スマートカードパラメータに適合された構造を収容していない。

ユーザインターフェースモジュールの構造は、スマートカードが有するデータタイプ又はスマートカードが用いられるアプリケーション等の要因に依存する。

本実施例において、スマートカードは、デコーダの条件付きアクセスサブシステムと共に用いられ、一連のパスワード等のユーザ定義情報と共に上記した資格を格納する。

本実施例によれば、資格は所与の期間において番組毎にユーザに付与される。スマートカードは、ネットワークでの番組の識別コード、及び、識別された各番組の認可された視聴時間の開始と終了を格納している。ユーザは、自分が（郵便又はデコーダにより提供されるリターンチャンネルを用いて対話的に）申し込んだ番組のリストを呼び出すことができる。ユーザが新しい番組の申し込みを希望する場合もある。

デコーダの幾つかの機能へのアクセスを与える数種類のパスワードが設けられている。

第１のパスワードは、親コードすなわちチャイルドロックである。このパスワードを用いると、全ての利用可能な番組の一覧を示すメニューが表示され、各プラグラムに認可又は禁止のマークが付される。

第２のパスワードは、ホームショッピングサービスへアクセスするのに必要とされる。

各パスワードは、現在のパスワードを知っているユーザにより変更され得る。

最後に、条件付きアクセスアプリケーションに関連するヘルプ画面が利用可能である。

図３は、上記した情報に対応するユーザインターフェースモジュール画面構造を表すツリーである。

先に定義したオブジェクトを用いると、この構造は、以下のように翻訳される。全部で１０個の異なる画面が存在する。

−３つの選択を備える条件付きアクセス主画面２５
−リスト及び１つの選択を備える申し込み画面２６
−２つの選択を備えるパスワードメニュー画面２７
−３つの選択を備えるヘルプメニュー画面２８
−番組を申し込む画面２９
−チャイルドロックパスワードを変更する画面３０
−ホームショッピングパスワードを変更する画面３１
−３つのヘルプ画面３２から３４
「終了」又は「前の画面に戻る」に対応する選択は示されていない。

かかるユーザインターフェースモジュールに対応するオブジェクトは、先に定義したオブジェクト構造を用いて翻訳され得る。ユーザインターフェースモジュール構造からの抜粋の１つについて、以下、ある程度詳細に説明する。

本例は、ユーザインターフェースモジュールの最初の画面、すなわち、条件付きアクセス主画面へのアクセスに関連する。本例は、この画面がユーザインターフェースモジュールの外部のイベント（この場合は、デコーダの主ユーザインターフェースでのオプションの起動）によりトリガーされるため選ばれた。

UserInterfaceModule()｛
ScreenList [UIList type]
｝

ScreenList()｛
ConditionalAccessMainScreen [Screen type, rank 1]
ProgramListScreen [Screen type, rank 2]
PasswordMenuScreen [Screen type, rank 3]
HelpMenuScreen [Screen type, rank 4]
SubscriptionScreen [Screen type, rank 5]
ChildLockPasswordChangeScreen [Screen type, rank 6]
HomeShoppingPasswordScreen [Screen type, rank 7]
HelpScreenTopoic1 [Screen type, rank 8]
HelpScreenTopoic2 [Screen type, rank 9]
HelpScreenTopoic3 [Screen type, rank 10] ｝

ConditionalAccessMainScreen()｛
Trigger=2 [主ユーザインターフェースの主画面で選択
「条件付きアクセス」が起動された場合]
List1 [List type]
｝

List1()｛
MenuItemSubscription() [Choice type]
MenuItemPassword() [Choice type]
MenuItemHelp() [Choice type]
｝

MenuItemSubscription()｛
Text1(); [ExplanatoryText type]
DestinationScreenNumber=2
｝

MenuItemPassword()｛
Text2(); [ExplanatoryText type]
DestinationScreenNumber=3
｝

MenuItemHelp()｛
Text3(); [ExplanatoryText type]
DestinationScreenNumber=4
｝

Text1()｛
"(1) 申し込み"
｝

Text2()｛
"(2) パスワード"
｝

Text3()｛
"(3) ヘルプ画面"
｝

ランク１の画面は、ユーザインターフェースモジュールへのエントリーポイントである。従って、対応するトリガー（値２）は主ユーザインターフェース構造に実装されなければならない。

上述したように、"Trigger"に対するヌル値はユーザインターフェース（主ユーザインターフェース又はモジュール）へのエントリーポイントではない画面を示す。

このヌル値に加えて、"Trigger"パラメータに対する９つの異なる値がユーザインターフェースモジュールのため予約されている。ユーザインターフェース画面モジュールの画面のみがこれらの値を用いてトリガーされる。主ユーザインターフェースはこれらの値によってはトリガーされない。

"Trigger"値の属性は以下の通りである。

"0": 画面はユーザインターフェースへの
エントリーポイントではない
"1": 画面はスマートカードのみにより
呼び出される
"2"〜"9": 画面は主ユーザインターフェースの
予め規定されたイベントによりトリガーされる
"10"〜"255":他の用途

最後の値のうち幾つかは、本実施例の条件付きアクセスユーザインターフェースの場合と同様に、他のユーザインターフェースモジュールに割り当てられる。

ユーザインターフェースモジュールの主ユーザインターフェースへの統合は図４のフローチャートで示される以下に述べる処理により行われる。

本実施例によれば、統合はスマートカードがスマートカードインターフェースに挿入されたとき、又は、デコーダがオンされカードの存在を検出したときに行われる。カードの挿入又は存在の検出は、カードインターフェースのスロットに設置され、カードのエッジでトリガーされるスイッチの状態を調べることにより公知の方法で行われる。

デコーダは、メモリ１９に格納されたユーザインターフェースモジュール構造全体の転送を要求する。構造全体を一度に転送することにより、ユーザが実際にユーザインターフェースを進んで行く場合に転送すべきデータ量が低減される。スマートカードとのデータ交換は、パラメータ及び変数の読み出し及び書き込みに限られ、ユーザインターフェース構造情報の転送は行われない。スマートカードインターフェースは転送レートが数キロボー毎秒に制限されたシリアルインターフェースであることが多いので、データ交換量の低減はユーザコマンドに対するシステム応答時間を向上するうえで重要である。

ユーザインターフェースモジュールに関するデータ交換を容易とするため、上述したデータ構造は、Type、Length、Valueフォーマット（ＴＬＶフォーマット）によりコード化される。ここで、
"Type"は構造のタイプを示すバイトであり、
"Length"は"Value"フィールドの長さを与える２バイトワードであり、
"Value"は上記データ構造に適合する一連のデータバイトである。ＴＬＶ構造のValueフィールドは１又は数個のＴＬＶ構造を含んでもよい。

用いられる"Type"は以下の通りである：
UserINterfaceModule 00
UIList 01
Screen 02
Menu 03
Choice 04
VariableField 05
InputField 06
ExplanatoryText 07

ユーザインターフェースモジュール構造が転送されると、デコーダは、どのトリガー値がモジュールの画面に収容されているかを検査し、モジュール画面への可能なエントリーポイントのリストを作成する。この特定の実施例においては、認可されたアクセスは条件付きアクセス主画面を介するもののみであるため、ユーザインターフェースモジュールへのエントリーポイントを規定するただ１つのトリガー値（すなわち２）が存在するだけである。もちろん、２以上のエントリーポイントを定義してもよい。

デコーダは、主ユーザインターフェース（又は予め統合されたモジュール）のどのChoice構造が、ロードされたモジュールへのエントリーポイントを規定するトリガー値を参照しているかを検査する。この特定の場合においては、主ユーザインターフェース主メニューの「条件付きアクセス」項目に対応する選択構造である。この選択は、以後、ユーザにより起動され得る。

ユーザインターフェースモジュールが主ユーザインターフェースに統合されると、デコーダとその主ユーザインターフェースとスマートカードとの間のパラメータ及び変数の通信は、２つの専用関数、すなわち、CardRetrievalFunction及びCardWriteFunctionを用いて行われる。特定のポインタが各関数に関連付けられる。各関数に対する番組コードはスマートカードに格納されており、スマートカードのマイクロプロセッサにより実行される。コード実行は、デコーダが適当なデータと共に関数ポインタをカードへ送ることによりトリガーされる。これらの関数は、データがデコーダの内部メモリではなくスマートカードのメモリに格納される点を除いて、上記した"GetValue"及び"ProcessValue"関数と同様の役割を有している。

例えば、パスワードの現在値を得る場合、デコーダは、値が取り出されるべき変数を特定するポインタと共に、ポインタ"CardRetrievalFunctionPointer"をコマンドとしてスマートカードへ送る。

CardRetrievalFunctionは、表示されるべき画面でVariableField型のオブジェクト構造と遭遇する毎に呼び出される。

パスワード値をカードに書き込む場合、デコーダは、値がカードへ書き込まれるべき変数を特定するポインタ及びこの変数の新たな値と共に、"CardWriteFunctionPointer"をコマンドとしてスマートカードへ送る。

関数ポインタ及び変数ポインタは、モジュール構造が転送される際にスマートカードからデコーダへ転送されるデータの一部である。

画面が表示される際、デコーダはCardRetrievalFunctionを、ディスプレイ上の変数フィールドを適正な値で埋めるのに必要な回数だけ呼び出す。本実施例の変形例によれば、変数フィールドの値を要求するファンクションコールは、画面の他の全ての要素が表示された場合にのみ行われる。本実施例の別の変形例によれば、カードから変数フィールドの値を要求するファンクションコールは、ユーザが画面上の対応するオブジェクトを起動した場合にのみ、これらのフィールドの少なくとも幾つかについて行われる。これは、例えば、ユーザが滅多に必要としないデータに適合し、ユーザインターフェース画面の全体表示速度を増加させる。

上記実施例によれば、主ユーザインターフェースは、統合されるべきユーザインターフェースモジュールへの潜在的なブリッジであるオブジェクトを備えていると考えられる。ユーザによるオブジェクトの操作は、モジュール統合が行われるまで制限される。

上記実施例の変形例によれば、主ユーザインターフェースは、かかるオブジェクトを前もっては含んでいない。この場合、スマートカードはユーザインターフェースモジュール構造だけではなく、主モジュールに統合された後、このモジュールへのユーザによるアクセスを可能とする数個のオブジェクトの構造をも収容している。

デコーダがスマートカードからモジュール構造をダウンロードする際、デコーダは、主ユーザインターフェース構造を参照する更なる構造をも転送する。

第１実施例において、オプション"Access Control（アクセス制御）"は、ユーザインターフェースモジュールの統合前は使用できないにもかかわらず、デコーダの主ユーザインターフェースの主メニューに表示された。更なる実施例によれば、このオプションは主ユーザインターフェースに存在しない。このオプションに対応する"Choice"型構造はスマートカードに格納される。スマートカードは、この"Choice"構造が主ユーザインターフェースのメニュー構造に挿入されるべきことを示す情報をも収容しており、これにより、そのオプションが主ユーザインターフェースの主メニューの項目リストに加えられる。

第３実施例によれば、上記主ユーザインターフェース及び上記ユーザインターフェースモジュールは、ユーザが別個のコマンド又はキーを用いることにより呼び出された。この場合、モジュールの画面へのアクセスを与える主ユーザインターフェースのオプションを有することは不要であり、ユーザインターフェースモジュールは、主ユーザインターフェースと並行して実行され得る。従って、主ユーザインターフェースとモジュールとの間の関係は、モジュールがロードされた後、主ユーザインターフェースによるモジュールへのアクセスが自由となるまでに制限される。

テレビデコーダのブロック図である。デコーダユーザインターフェースの一例である。スマートカードに格納されたユーザインターフェースモジュールのツリー構造である。ユーザインターフェースモジュールをデコーダのユーザインターフェースに統合するための主要ステップを示すフローチャートである。

Claims

主ユーザインターフェースプログラムを備えるデコーダと、該デコーダと協働する取り外し可能なスマートカードとを備えるテレビジョンシステムにおいて、メニューを表示する方法であって：
前記スマートカードに格納されたユーザインターフェースモジュール全体を前記デコーダによりロードして格納する段階であり、前記ユーザインターフェースモジュールが前記スマートカードに格納されたユーザ向け情報を参照するデータ構造を有し、該データ構造がメニューを表示させる、段階；
前記デコーダにより、前記主ユーザインターフェースプログラムと前記の格納されたユーザインターフェースモジュールとの間の関係を確立して、ユーザによる前記ユーザインターフェースモジュールへのアクセスを可能とし、メニューのリストのうち少なくとも１つのメニューを前記テレビジョンシステムの画面上に表示する段階；及び
前記ユーザインターフェースモジュールを介して前記ユーザにより発せられたコマンドに応じて、前記デコーダと前記スマートカードとの間で、前記ユーザ向け情報の部分を順次交換する段階；
を有する方法。
前記の画面上に表示されるメニューが条件付きアクセスメニューである、請求項１記載の方法。
前記の画面上に表示されるメニューが申し込み選択用メニューである、請求項１記載の方法。
前記の画面上に表示されるメニューがパスワードを入力するメニューである、請求項１記載の方法。
前記の画面上に表示されるメニューがヘルプメニューである、請求項１記載の方法。
前記の画面上に表示されるメニューが番組を申し込むためのメニューである、請求項１記載の方法。
前記の画面上に表示されるメニューがチャイルドロックパスワードを変更するためのメニューである、請求項１記載の方法。
前記の画面上に表示されるメニューがホームショッピングパスワードを変更するためのメニューである、請求項１記載の方法。