CZ331399A3 - Způsob zavádění dat do MPEG přijímače/dekodéru a MPEG vysílací systém pro jeho realizaci - Google Patents

Abstract

V digitálním satelitním televizním systému, ve kterém televize přijímá svůj signál přes přijímač/dekodér (2020), jako je nastavovací řídící skříň, mohou být interaktivní aplikace stahovány a spouStčny na přijímači/dekodéru (2020). Aplikační kód je uspořádán ve formě modulů a stahování modulů předchází vyhledání adresářového modulu uvnitř specifikovaných místních adres. Modulyjsou označeny (podepsány) a adresářový modul je podepsán a kódován tak, že jedno kódování platí pro všechny moduly tvořící aplikaci. Vícenásobné veřejné kódovací klíče jsou uloženy v ROM přijímače/dekodéru (2020), takže aplikace mohou být vytvářeny různými zdroji, aniž by tyto zdroje musely vzájemně znát ostatní privátní kódovací klíče. Je zajištěno opatření pro umožnění dočasného uložení kódovacího klíče v RAM přijímače/dekodéru (2020), takže výrobce přijímače/dekodéru(2020) může ověřitjeho funkčnost Podpis adresáře může být skrytý na různých polohách v bloku fiktivních dat v adresářovém modulu. Aplikace určené ke stažení mohou být kontrolovány vzhledem k bitové mapě pro ověření platnosti aplikace, uložené v přijímači/dekodéru )2020). Dáleje předmětem vynálezu přijímač/dekodér (2020) pro použití při realizací tohoto způsobu, který zahrnuje prostředek pro přijímání MPEG tabulek, prostředek pro ukládání množství veřejných klíčů a zpracovatelský prostředek naprogramovaný pro zvolení jednoho z uložených veřejných klíčů.

Description

Oblast techniky

Předkládaný vynález se týká:5 • způsobu zavádění (stahování) dat do MPEG přij ímače/dekodéru;

• MPEG přijímače/dekodéru; a • MPEG vysílacího systému.

Dosavadní stav techniky

Nástup digitálních vysílacích systémů určených primárně pro vysílání televizních signálů, zejména, ale ne výhradně, satelitních televizních systémů, otevřel možnost využití těchto systémů pro další účely. Jedním z těchto účelů je zajištění interaktivity s koncovým uživatelem.

Jedním způsobem pro realizaci tohoto záměru je spustit aplikaci na přijímači/dekodéru, kterým je přijímán televizní signál. Kód pro aplikaci by mohl být trvale uložen v přijímači/dekodéru. Ovšem toto uspořádání by bylo spíše omezující. Výhodně by měl být přijímač/dekodér schopen stahovat kód pro požadovanou aplikaci. Tímto způsobem může být dosaženo větší pružnosti a aplikace mohou být aktualizovány podle požadavků bez jakýchkoliv zásahů na straně uživatele.

V MPEG systému může být aplikační kód stahován v MPEG tabulkách. Je zde ale omezení ve velikosti jednoho kódu, který může být stažen prostřednictvím jedné MPEG tabulky. Navíc, pokud je požadováno, aby byla stažena celá aplikace předtím, než může být spuštěna, může tímto způsobem vzniknout · ··

9« 9 9 9 9 *

99 zpoždění, které je pro uživatele zcela nepřijatelné. Existuje tudíž potřeba možnosti stahovat aplikace ve formě množství modulů. To ale potom vytváří problém s možností identifikace a vyjímání z MPEG bitového toku modulů požadovaných pro určitou aplikaci. První aspekt předkládaného vynálezu se zabývá tímto problémem.

* >

Podstata vynálezu t

Podle prvního aspektu předkládaného vynálezu je tedy IQ navržen způsob zavádění alespoň části aplikace do MPEG přijímače/dekodéru, který zahrnuje kroky: rozdělení aplikace do množství modulů; formátování každého z modulů jako odpovídající MPEG tabulku, přičemž tyto tabulky mají stejnou tabulkovou identifikaci (TID) a odpovídající odlišná tabulková identifikační rozšíření (TID-rozšíření) jiná, než je předem stanovené TID-rozšíření; vytvoření adresářové MPEG tabulky pro moduly, která má stejnou uvedenou TID a uvedené předem stanovené TID-rozšíření, přičemž adresář obsahuje pro každý modul jméno tohoto modulu a odpovídající TID-rozšíření;

cyklického vysílání adresářové MPEG tabulky a modulových MPEG tabulek v MPEG bitovém toku; a v MPEG přijímači/dekodéru:přijímání MPEG bitového toku; stahování té jedné z MPEG „ tabulek, která má předem stanovené TID-rozšíření tak, aby byla stažena adresářová MPEG tabulka; určování z obsahu ^r 25 adresářové MPEG tabulky TID-rozšíření modulových MPEG tabulek; a stahování alespoň jedné z modulových MPEG tabulek majících stejnou TID, jako je TID stažené adresářové MPEG tabulky, a TID-rozšíření určené ze stažené adresářové MPEG tabulky.

s>

A AAA

A A «

A A · AAA • A A AAAA

Podle toho tedy může být aplikace sestavena z určitého počtu modulů, které mohou být staženy, a pokud je to vhodné spuštěny, podle požadavku. Adresářová tabulka může být snadno identifikována, protože má určité TID-rozšíření, a jakmile jíž byla stažena, umožňuje tato tabulka příjímači/dekodéru identifikovat modulové tabulky z jejich t

příslušných TID-rozšíření.

+ Způsob výhodně dále zahrnuje kroky: začlenění do vysílané adresářové MPEG tabulky identifikací verze pro tuto o

tabulku; a v přijímači/dekodéru:- určování zda identifikace verze právě vysílané adresářové PMT MPEG tabulky je aktuálnější než identifikace verze právě stažené adresářové

MPEG tabulky, a pokud ano, opakování kroků stahování adresářové MPEG tabulky, určování TID-rozšíření, a stahování i 5 alespoň jedné z modulových MPEG tabulek.

Podle toho tedy, pokud by aplikace byla měněna, může to být automaticky zjištěno a mohou být staženy aktualizovaný adresář a jakékoliv aktualizované moduly.

2Q Alespoň jedna z modulových MPEG tabulek může být formátována jako množství MPEG úseků, které jsou vysílány samostatně v MPEG bitovém toku, přičemž každý tento MPEG úsek „ obsahuje v jeho předem stanovené části identifikaci tohoto

MPEG úseku v MPEG tabulce a indikaci počtu úseků v MPEG ' 25 tabulce.

Podle druhého aspektu předkládaného vynálezu je vytvořen MPEG přijímač/dekodér pro použití při realizaci části způsobu podle prvního aspektu předkládaného vynálezu, který zahrnuje: přijímač pro přijímání MPEG bitového toku;

paměťový prostředek; a zpracovatelský prostředek, který je €

• «4 • · v « · · · · * • · · · 4 • · · ·

44 •»« «··« naprogramován pro řízení stahování té jedné z přijímaných MPEG tabulek, která má předem stanovené MPEG-rozšíření, do paměťového prostředku, určování z obsahu adresářové MPEG tabulky TID-rozšíření modulových MPEG tabulek, a pro řízení stahování do paměťového prostředku alespoň jedné z modulových MPEG tabulek, která má stejnou TID, jako je TID stažené adresářové MPEG tabulky, a TID-rozšíření určené ze stažené adresářové MPEG tabulky.

Výhodně je zpracovatelský prostředek naprogramován θ pro určování, zda identifikace verze právě přijímané adresářové MPEG tabulky je aktuálnější, než je identifikace verze stažené adresářové MPEG tabulky, a pokud ano, pro opakování stahování adresářové MPEG tabulky, určování TID-rozšíření a stahování alespoň jedné z modulových MPEG tabulek.

V případě, ve kterém je přijÍmač/dekodér uspořádán pro přijímání alespoň jedné z modulových tabulek formátovaných jako množství samostatně vysílaných úseků, je zpracovatelský prostředek výhodně naprogramován pro řízení opakovaného stahování MPEG úseků do paměťového prostředku, dokud zpracovatelský prostředek neurčí z identifikaci úseků a indikace počtu úseků stahovaných úseků, že již byly staženy všechny z úseků.

Výhodně přijímač/dekodér dále zahrnuje paralelní port a/nebo sériový port uspořádaný pro přijetí aplikace formátované jako alespoň jedna MPEG tabulka, přičemž v tomto případě je výhodně použito krátkého formátu MPEG-2, zatímco dlouhý MPEG-2 formát je výhodně použit pro dálkový příjem, například prostřednictvím satelitu nebo kabelu.

* 4 4 4 « « 4* tf 4 · 4 * · 4 • 4 ·4 • 4 »4

To je obzvláště užitečné v případě, ve kterém si výrobce přeje testovat určité znaky přijímače/dekodéru, protože aplikace může být stažena, aniž by musela být vysílána přes satelitní televizní systém.

Podle třetího aspektu předkládaného vynálezu je ' , vytvořen MPEG vysílací systém, který zahrnuje: prostředek pro rozdělení aplikace určené ke stažení do MPEG přijímače/dekodéru na množství modulů; prostředek pro formátování každého z modulů jako odpovídající MPEG tabulky, přičemž tyto tabulky mají stejnou TID a příslušná odlišná TID-rozšíření, jiná než je předem stanovené TID-rozšíření; prostředek pro vytváření adresářové MPEG tabulky pro moduly, která má stejnou uvedenou TID a uvedené předem stanovené TID-rozšíření, přičemž adresář obsahuje pro každý z modulů jméno tohoto modulu a příslušné TID-rozšíření; a prostředek pro cyklické vysílání adresářové MPEG tabulky a modulových MPEG tabulek v MPEG bitovém toku.

Výhodně systém dále zahrnuje prostředek pro vytváření identifikace verze pro adresářovou MPEG tabulku; přičemž ²⁰ prostředek pro vytváření adresářové MPEG tabulky je uspořádán pro začlenění do adresářové MPEG tabulky vytvořené identifikace verze pro tuto tabulku.

Prostředek pro formátování modulů může být uspořádán ^r 25 P^ro formátování alespoň jedné z modulových MPEG tabulek jako množství MPEG úseků, z nichž každý v jeho předem stanovené části obsahuje identifikací tohoto MPEG úseku v této MPEG tabulce a indikaci počtu MPEG úseků v této MPEG tabulce.

Výhodně by přijímač/dekodér měl být chráněn proti 30 stahování neautorizovaných aplikací, které by mohly »· · ·· · *** ···· obsahovat, například, viry. Podle toho lze tedy předpokládat určité koncepty kódování a označování (podepisování) alespoň části aplikačního kódu.

Podle čtvrtého aspektu předkládaného vynálezu je navržen způsob zavádění dat do MPEG přijímaČe/dekodéru, který zahrnuje kroky: vytváření podpisu pro data určená ke stažení; kódování podpisu s použitím privátního klíče; formátování dat určených ke stažení, kódovaného podpisu a identifikace pro privátní klíč jako MPEG tabulky; vysílání MPEG tabulky; a v přijímači/dekodéru:- přijímání MPEG tabulky; zvolení jednoho z množství veřejných klíčů podle identifikace klíče v přijaté MPEG tabulce; dekódování kódovaného podpisu v přijaté MPEG tabulce s použitím zvoleného veřejného klíče pro vytvoření dekódovaného podpisu; vytváření podpisu pro data v přijaté MPEG tabulce; a porovnání dekódovaného podpisu a podpisu vytvořeného v přijímači/dekodéru pro přijatá data.

Podle toho tedy může být přijímač/dekodér použit pro stahování aplikací majících kódované podpisy z více než jednoho zdroje, aniž by tyto zdroje musely znát všechny ostatní privátní klíče.

Tento způsob podle vynálezu může dále zahrnovat kroky: stahování do přijímaČe/dekodéru aplikace mající podpis kódovaný s použitím privátního klíče majícího předem stanovenou identifikaci klíče; spuštění aplikace v přijímači/dekodéru pro řízení příjímače/dekodéru pro přijetí dalšího klíče; uložení tohoto dalšího klíče v oblasti energeticky závislé paměti přijímaČe/dekodéru. V tomto případě může být v průběhu kroku spuštění aplikace další klíč předáván lokálně do přijímaČe/dekodéru, například přes paralelní port, sériový port nebo čtecí zařízení • · « <

* ··» · »· • » *· • » · · ·♦ «· ··· ·««>

·· ·· inteligentních karet přijímače/dekodéru. Pokud přijímač/dekodér má modemové připojení, je tento přijímač/dekodér výhodně uspořádán pro zabránění tomu, aby nějaký takový další klíč byl předáván přes modem.

Tyto znaky umožňují výrobci, který může potřebovat otestovat přijímač/dekodér, stahovat klíč do přij ímače/dekodéru.

Způsob podle vynálezu může dále zahrnovat kroky: v přijímači/dekodéru: vyhledávání v chráněné oblasti paměti přijímače/dekodéru příznaku platnosti pro zvolený veřejný klíč; a zamezení nebo přerušení stahování dat, pokud vyhledaný příznak platnosti není nastaven.

Podle toho tedy, přestože v paměti přijímače/dekodéru 25 může být permanentně zajištěno množství veřejných klíčů, může být kterýkoliv z nich selektivně zablokován, což může být potřebné v tom případě, například, kdy bylo narušeno soukromí privátního klíče sdruženého s nějakým určitým veřejným klíčem, nebo kdy se dva operátoři, kteří používali stejné

2Q klíče, rozhodnou, že si přejí používat samostatné klíče.

V případě, ve kterém je přijímač/dekodér uspořádán pro stahování aplikace mající podpis kódovaný s použitím privátního klíče majícího předem stanovenou identifikaci klíče, jak bylo uvedeno výše, může mít v chráněné oblasti paměti přijímače/dekodéru privátní klíč mající předem stanovenou identifikaci klíče příznak platnosti, který může být měněn prostřednictvím uvedené aplikace, přičemž schopnost přijímat další klíč je určena v závislosti na stavu tohoto příznaku platnosti.

« · * • » ·* « «« • « * · • 9 ··· ··· ·· 9·

Tyto posledně uvedené znaky příznaků platnosti pro veřejné klíče mohou být zajištěny nezávisle na čtvrtém aspektu předkládaného vynálezu. Podle toho tedy je podle pátého aspektu předkládaného vynálezu navržen způsob zavádění dat do MPEG přijímače/dekodéru, který zahrnuje kroky:

vytváření podpisu pro data určená ke stažení; kódování podpisu s použitím privátního klíče; formátování dat určených ke stažení, kódovaného podpisu a identifikace pro privátní klíč jako MPEG tabulky; vysílání MPEG tabulky; a v přijímači/dekodéru:- přijímání MPEG tabulky; vyhledávání v chráněné oblasti paměti příjímače/dekodéru příznaku platnosti pro veřejný klíč odpovídající privátnímu klíči identifikovanému v přijaté MPEG tabulce; a pokud je vyhledaný příznak platností nastaven:- dekódování kódovaného podpisu v přijaté MPEG tabulce s použitím veřejného klíče odpovídajícího privátnímu klíči identifikovanému v přijaté MPEG tabulce pro vytvoření dekódovaného podpisu; vytváření podpisu pro data v přijaté MPEG tabulce; a porovnání dekódovaného podpisu a podpisu vytvořeného v přijímači/dekodéru pro přijatá data.

Způsoby podle čtvrtého a pátého aspektu předkládaného vynálezu výhodně dále zahrnují kroky:- vytvoření ověřovacího kódu pro data určená ke stažení, přičemž tento ověřovací kód je kódován s podpisem v kódovacím kroku a je dekódován s podpisem v dekódovacím kroku; vyhledání uloženého ověřovacího kódu v chráněné oblasti pamětí přijímače/dekodéru; a porovnání vyhledaného ověřovacího kódu a dekódovaného ověřovacího kódu.

Podle tohoto příjímač/dekodér může být nastaven pro přijímání pouze určitých aplikací nebo typů aplikací.

• · 44 i 4 » · · I

Φ · 4 · * · 44 Φ·4 ·ΦΦ • 44« · Φ « ·

4· 4« ««· ·« φ» «φ

Tyto znaky mohou být zajištěny nezávisle na čtvrtém a pátém aspektu předkládaného vynálezu. Podle toho tedy je podle šestého aspektu předkládaného vynálezu navržen způsob zavádění dat do MPEG přijímače/dekodéru, který zahrnuje kroky:- vytváření ověřovacího kódu pro data určená ke stažení; vytváření podpisu pro data určená ke stažení, nebo jejich části; kódování ověřovacího kódu a podpisu s použitím privátního klíče; formátování dat určených ke stažení a kódovaného ověřovací kódu a podpisu jako alespoň jedné MPEG tabulky; vysílání uvedené jedné nebo každé MPEG tabulky; a v příjímači/dekodéru:- přijímání uvedené jedné nebo každé MPEG tabulky; dekódování kódovaného ověřovacího kódu a podpisu v přijatých MPEG tabulkách s použitím veřejného klíče odpovídajícího privátnímu klíči; vyhledání uloženého ověřovacího kódu v chráněné oblastí pamětí přijímače/dekodéru; porovnání vyhledaného ověřovacího kódu a dekódovaného ověřovacího kódu; vytváření podpisu pro data v přijatých MPEG tabulkách, nebo jejich část; a porovnání dekódovaného podpisu s podpisem vytvořeným v přijímači/dekodéru pro přijatá data.

Výhodně způsob podle vynálezu dále zahrnuje krok zamezení nebo přerušení stahování dat, pokud si v kroku porovnávání ověřovacích kódů vyhledaný ověřovací kód a dekódovaný ověřovací kód vzájemně neodpovídají.

Ve čtvrtém až šestém aspektu předkládaného vynálezu může být zajištěno, že podpis dat určených ke stažení je kódován v bloku dat, včetně dalších dat, se zvoleným posunutím mezi začátkem datového bloku a začátkem podpisu, a kódovaný datový blok je dekódován v kroku dekódování v 30 přijímači/dekodéru, přičemž způsob podle vynálezu dále • · ·· · **·4« · · · · · V 4 99·

9·· · 9 9 9 ·· 999 9999 99 99 zahrnuje kroky v přijímači/dekodéru:- vyhledávání alespoň jednoho uloženého posunutí v chráněné oblasti paměti přijímače/dekodéru; a vyjmutí podpisu z dekódovaného datového bloku s použitím uvedeného jednoho vyhledaného posunutí od začátku dekódovaného datového bloku.

Podle toho tedy podpis může být skrytý mezi dalšími fiktivními daty, čímž je dosaženo toho, že je mnohem obtížnější nalézt umístění podpisu. Alternativně, nebo přídavně, tento znak umožňuje, aby data byla vytvořena jako přístupná pouze pro jednu nebo více určitých skupin přij ímačů/dekodérů.

Tyto znaky mohou být zajištěny nezávisle na čtvrtém až šestém aspektu předkládaného vynálezu. Podle toho je tedy podle sedmého aspektu předkládaného vynálezu navržen způsob zavádění dat do MPEG přijímače/dekodéru, který zahrnuje kroky:- vytváření podpisu pro data určená ke stažení; začlenění podpisu a dalších dat do bloku dat se zvoleným posunutím mezi začátkem datového bloku a začátkem podpisu; kódování datového bloku s použitím privátního klíče;

formátování dat určených ke stažení a kódovaného datového bloku jako MPEG tabulky; vysílání této MPEG tabulky; a v přijímači/dekodéru:- přijímání MPEG tabulky; dekódování kódovaného datového bloku v přijaté MPEG tabulce s použitím veřejného klíče odpovídajícího privátnímu klíči; vyhledání 25 alespoň jednoho uloženého posunutí v chráněné oblasti paměti přijímače/dekodéru; vyjmutí podpisu z dekódovaného datového bloku s použitím uvedeného jednoho vyhledaného posunutí od začátku dekódovaného datového bloku; vytváření podpisu pro data v přijaté MPEG tabulce; a porovnání podpisu vyjmutého z

0· 0 • 000 «00 «

*· ··

0*· · · · · • 0 · Φ

0* · • 0« «··* dekódovaného datového bloku s podpisem vytvořeným v přijímači/dekodéru pro přijatá data.

V případě, ve kterém uvedená chráněná oblast paměti má alespoň dvě takováto uložená posunutí, pak, pokud v kroku porovnání si vyjmutý podpis a vytvořený podpis vzájemně neodpovídají, zahrnuje způsob výhodně kroky opakování kroků vyhledání, vyjmutí a porovnání s použitím dalšího z uložených posunutí.

Alespoň nějaká z uvedených dalších dat v bloku dat mohou být fiktivní nebo libovolná data, ale pokud je tomu tak, pak výhodně žádný úsek těchto fiktivních dat neopakuje podpis.

Ve čtvrtém až sedmém aspektu předkládaného vynálezu mohou být data stahována jako množství modulů dat, přičemž způsob podle předkládaného vynálezu může zahrnovat kroky:vytváření modulového podpisu pro každý modul dat, určený ke stažení; formátování modulů dat jako příslušných modulových MPEG tabulek; vytváření adresáře včetně identifikace každé modulové MPEG tabulky a příslušného podpisu, přičemž tento adresář je subjektem kroku vytváření podpisu; a v přijímači/dekodéru:- vytváření příslušného modulového podpisu pro každý z modulů v přijatých modulových MPEG tabulkách; a porovnání každého modulového podpisu v přijaté adresářové MPEG tabulce s příslušným modulovým podpisem vytvořeným v přij ímači/dekodéru.

Podle toho tedy, přestože data určená ke stažení jsou sestavena z množství modulů, je vyžadován pouze jeden kódovací proces za účelem kódování modulů, a je požadován

I * « «

I 1 I «II · 4 ' * pouze jeden dekódovací proces za účelem umožnění ověření podpisů.

Tyto znaky mohou být zajištěny nezávisle na čtvrtém až sedmém aspektu předkládaného vynálezu. Podle toho tedy podle osmého aspektu předkládaného vynálezu je navržen způsob zavádění množství modulů dat do MPEG přijímače/dekodéru, který zahrnuje kroky:- vytváření modulového podpisu pro každý modul dat určených ke stažení; formátování modulů dat jako příslušných modulových MPEG tabulek; vytváření adresáře včetně identifikace každé modulové MPEG tabulky a příslušného podpisu; vytváření adresářového podpisu pro adresář; kódování adresářového podpisu s použitím privátního klíče; formátování adresáře a kódovaného adresářového podpisu jako adresářové MPEG tabulky; vysílání adresářové a modulových MPEG tabulek; a v při]ímači/dekodéru:- přijímání adresářové a modulových MPEG tabulek; dekódování kódovaného adresářového podpisu v přijaté adresářové MPEG tabulce s použitím veřejného klíče odpovídajícího privátnímu klíči; vytvoření adresářového podpisu pro adresář v přijaté adresářové MPEG tabulce; porovnání dekódovaného adresářového podpisu a adresářového podpisu vytvořeného v příjímači/dekodéru; vytvoření příslušného modulového podpisu pro každý z modulů v přijatých modulových MPEG tabulkách; a porovnání každého modulového podpisu v přijaté adresářové MPEG tabulce s příslušným modulovým podpisem vytvořeným v přijímači/dekodéru.

Způsob podle vynálezu výhodně dále zahrnuje krok zabránění nebo přerušení stahování takového modulu dat, pokud v kroku porovnání modulových podpisů si modulový podpis v přijaté adresářové MPEG tabulce a příslušný modulový podpis v · Φ· φ φ φ φ φ φ φ ·· ·· * V ν * V • « Φ «ΦΦ Φ·Φ

Φ Φ Φ Φ «ΦΦ ΦΦΦΦ · «Φ vytvořený v přijímači dekodéru pro tento modul vzájemně neodpovídáj i.

Způsoby popisované výše výhodně rovněž zahrnují krok zabránění nebo přerušení stahování dat, pokud si v kroku (krocích) porovnání jeden nebo každý dekódovaný podpis a vytvořený podpis vzájemně neodpovídají.

Podle devátého aspektu předkládaného vynálezu je vytvořen MPEG přijímač/dekodér pro použití při realizaci způsobu podle čtvrtého aspektu předkládaného vynálezu, který zahrnuje: prostředek pro přijímáni MPEG tabulek; prostředek pro ukládání množství veřejných klíčů a identifikace pro každý z veřejných klíčů; a zpracovatelský prostředek, který je naprogramován pro zvolení jednoho z uložených veřejných klíčů podle identifikace klíče v přijaté MPEG tabulce; pro 15 dekódování kódovaného podpisu v přijaté MPEG tabulce s použitím zvoleného veřejného klíče pro vytvoření dekódovaného podpisu; pro vytvoření podpisu pro data v přijaté MPEG tabulce; a pro porovnání dekódovaného podpisu a podpisu vytvořeného v přijímači/dekodéru pro přijatá data.

Paměťový prostředek pro uložení klíčů je výhodně zajištěn prostřednictvím ROM, a identifikace pro každý z veřejných klíčů může být zajištěna prostřednictvím paměťového místa tohoto veřejného klíče v paměťovém prostředku pro uložení klíčů.

Přijímač/dekodér může dále zahrnovat oblast energeticky závislé paměti, přičemž zpracovatelský prostředek může být uspořádán pro stahování aplikace mající podpis kódovaný s použitím privátního klíče majícího předem stanovenou identifikaci klíče, pro spuštění této aplikace pro • 9 « · 9 • 9 99« 9··

9 99 9 * * · · » 9 ♦ 9 · · 99 9 9 ·· ·· ·99 9999 *· ·9 řízení přijímače/dekodéru pro přijetí dalšího klíče, a pro řízení uložení tohoto dalšího klíče do oblasti energeticky závislé paměti.

Přijímač/dekodér může dále zahrnovat prostředek pro 5 přijetí takového dalšího klíče, který je předáván lokálně do přijímače/dekodéru, jako je paralelní port, sériový port a/nebo čtecí zařízení pro čtení inteligentních karet v w přijímači/dekodéru. Energeticky závislá paměť je výhodně zajištěna prostřednictvím RAM. Opět, pokud přijímač/dekodér má modemové spojení, je tento přijímač/dekodér výhodně uspořádán pro zabránění předání takového dalšího klíče přes modem.

Přijímač/dekodér může dále zahrnovat chráněnou oblast paměti pro uložení příznaku platnosti pro každý z alespoň 15 nějakých veřejných klíčů, přičemž zpracovatelský prostředek může být naprogramován pro vyhledání v této chráněné oblasti paměti příznaku platností pro zvolený veřejný klíč, a pro zabránění nebo přerušení stahování dat, pokud tento vyhledaný příznak platností není nastaven.

Přijímač/dekodér může rovněž dále zahrnovat chráněnou oblast paměti pro uložení příznaku platnosti pro privátní klíč mající předem stanovenou identifikaci klíče, přičemž zpracovatelský prostředek může být uspořádán při spuštění » 25 uvedené aplikace pro změnu tohoto příznaku platnosti a je uspořádán pro umožnění takovéhoto uložení dalšího klíče v závislosti na stavu tohoto příznaku platnosti.

Tento posledně uvedený znak může být zajištěn nezávisle na devátém aspektu předkládaného vynálezu. Podle toho tedy je podle desátého aspektu předkládaného vynálezu • * ·· · «*»*· ····· · ·♦ ··· ·* ···· ·» · · ·· ·· »· ···· · ·« vytvořen MPEG příjímač/dekodér, který zahrnuje: prostředek pro příjímání MPEG tabulek; prostředek pro ukládání veřejného klíče a identifikace pro tento veřejný klíč; a chráněnou oblast paměti pro uložení příznaku platnosti pro veřejný klíč; a zpracovatelský prostředek, který je naprogramován pro vyhledání v této chráněné oblasti paměti přijímače/dekodéru příznaku platnosti pro veřejný klíč odpovídající privátnímu klíčí identifikovanému v přijaté MPEG tabulce; a, pokud je vyhledaný příznak platnosti nastaven, pro dekódování kódovaného podpisu v přijaté MPEG tabulce s použitím veřejného klíče odpovídájícího privátnímu klíči identifikovanému v přijaté MPEG tabulce pro vytvoření dekódovaného podpisu; pro vytvoření podpisu pro data v přijaté MPEG tabulce; a pro porovnání dekódovaného podpisu a podpisu vytvořeného v přijímači/dekodéru pro přijatá data.

Paměť pro uložení příznaku (příznaků) platnosti pro klíče je výhodně zajištěna prostřednictvím přepisovatelné paměti nezávislé na zdroji energie.

V případě, ve kterém je uloženo množství takových ²⁰ veřejných klíčů, je paměť pro uložení příznaku (příznaků) platnosti výhodně uspořádána jako bitová mapa.

Přijímač/dekodér podle devátého nebo desátého aspektu předkládaného vynálezu může dále zahrnovat chráněnou oblast paměti pro uložení ověřovacího kódu, přičemž zpracovatelský prostředek může být naprogramován pro dekódování ověřovacího kódu v přijaté MPEG tabulce, pro vyhledání uloženého ověřovacího kódu, a pro porovnání vyhledaného ověřovacího kódu a dekódovaného ověřovacího kódu.

♦ Φ · »

Φ·· ···

Φ Φ

ΦΦ ΦΦ • 9 ·· • · · · • · · Φ • Φ ·Φ • Φ • « Φ • Φ ΦΦ· ΦΦ·Φ

Tento posledně uvedený znak může být zajištěn nezávisle na devátém nebo desátém aspektu předkládaného vynálezu. Podle toho tedy je podle jedenáctého aspektu předkládaného vynálezu vytvořen MPEG přijímač/dekodér, který zahrnuje: prostředek pro přijímání MPEG tabulek; prostředek pro ukládáni veřejného klíče a identifikace pro tento veřejný klíč; chráněnou oblast paměti pro uložení ověřovacího kódu; a zpracovatelský prostředek, který je naprogramován pro dekódování kódovaného ověřovacího kódu a podpisu v přijatých

MPEG tabulkách s použitím uloženého veřejného klíče odpovídajícího privátnímu klíči; pro vyhledání uloženého ověřovacího kódu v chráněné oblasti paměti; pro porovnání vyhledaného ověřovacího kódu a dekódovaného ověřovacího kódu; pro vytvoření podpisu pro data v přijaté MPEG tabulce nebo jejich část; a pro porovnání dekódovaného podpisu a podpisem vytvořeným v přijímači/dekodéru pro přijatá data.

Zpracovatelský prostředek je výhodně naprogramován pro zabránění nebo přerušení stahování dat, pokud si vyhledaný ověřovací kód a dekódovaný ověřovací kód vzájemně neodpovídají.

Paměť pro uložení ověřovacích kódů je výhodně zajištěna prostřednictvím přepisovatelné paměti nezávislé na zdroji energie, přičemž tato paměť a může být uspořádána jako bitová mapa.

Přijímač/dekodér podle devátého až jedenáctého aspektu předkládaného vynálezu může dále zahrnovat chráněnou oblast pamětí pro uložení alespoň jednoho posunutí, přičemž zpracovatelský prostředek může být naprogramován pro dekódování kódovaného datového bloku v přijaté MPEG tabulce, pro vyhledání uvedeného jednoho uloženého posunutí v chráněné «« • · 0 0 0 0 0 0 0 ··· 000 0 0 0 0 •00 0000 00 00 oblasti paměti, a pro vyjmutí podpisu z dekódovaného datového bloku s použitím vyhledaného posunutí od začátku dekódovaného datového bloku.

Tento posledně uvedený znak může být zajištěn nezávisle na devátém až jedenáctém aspektu předkládaného vynálezu. Podle toho tedy je podle dvanáctého aspektu předkládaného vynálezu vytvořen MPEG přijímač/dekodér, který zahrnuje: prostředek pro přijímání MPEG tabulek; prostředek pro uložení veřejného klíče a identifikace pro tento veřejný klíč; chráněnou oblast paměti pro uložení alespoň jednoho posunutí; a zpracovatelský prostředek, který je naprogramován pro dekódování kódovaného datového bloku v přijaté MPEG tabulce s použitím uloženého veřejného klíče odpovídajícího privátnímu klíči; pro vyhledání uvedeného jednoho uloženého posunutí v chráněné oblasti paměti; pro vyjmutí podpisu z dekódovaného datového bloku s použitím vyhledaného posunutí od začátku dekódovaného datového bloku; pro vytvoření podpisu pro data v přijaté MPEG tabulce; a pro porovnání podpisu vyjmutého z dekódovaného datového bloku s podpisem vytvořeným v přijímači/dekodéru pro přijatá data.

Paměť pro uložení posunutí je výhodně zajištěna prostřednictvím přepisovatelné paměti nezávislé na zdroji energie.

V přijímači/dekodéru podle devátého až dvanáctého aspektu předkládaného vynálezu může být zpracovatelský prostředek naprogramován pro vytvoření příslušného modulového podpisu pro každý z modulů v přijatých MPEG tabulkách, a pro porovnání každého modulového podpisu v přijaté adresářové MPEG tabulce s příslušným modulovým podpisem vytvořeným v přij ímači/dekodéru.

w · » AAAA • · A A

A A A A

A· ♦* •

A

A A ·♦> ···>

• ♦ A * ··· ··· • A

AA AA

Tento posledně uvedený znak vynálezu může být zajištěn nezávisle na devátém až dvanáctém aspektu předkládaného vynálezu. Podle toho tedy je podle třináctého aspektu předkládaného vynálezu vytvořen MPEG přijímač/dekodér, který zahrnuje: prostředek pro přijímání adresářové a modulových MPEG tabulek; prostředek pro uložení veřejného klíče a identifikace pro tento veřejný klíč; a zpracovatelský prostředek, který je naprogramován pro dekódování kódovaného adresářového podpisu v přijaté adresářové MPEG tabulce s použitím uloženého veřejného klíče odpovídajícího privátnímu klíči; pro vytvoření adresářového podpisu pro adresář v přijaté adresářové MPEG tabulce; pro porovnání dekódovaného adresářového podpisu a adresářového podpisu vytvořeného v přijímači/dekodéru; pro vytvoření příslušného modulového podpisu pro každý z modulů v přijatých modulových MPEG tabulkách; a pro porovnání každého modulového podpisu v přijaté adresářové tabulce s příslušným modulovým podpisem vytvořeným v přijímači/dekodéru.

Zpracovatelský prostředek je výhodně naprogramován

0 pro zabránění nebo přerušení stahování modulu dat, pokud si modulový podpis v přijaté adresářové MPEG tabulce a příslušný modulový podpis vytvořený v přijímači/dekodéru pro tento modul vzájemně neodpovídají.

V přijímači/dekodéru podle kteréhokoliv z devátého až třináctého aspektu podle vynálezu je zpracovatelský prostředek výhodně naprogramován pro zabránění nebo přerušení stahování dat, pokud si jeden nebo každý dekódovaný podpis a vytvořený podpis vzájemně neodpovídají.

• 4 4 4 4 «·4 4·4

4 44 4

4 4 4 4 4 «

4 4 4 4 ·

4« 44 44φ 4444

4

44

V následujícím popisu budcu popsány výhodné znaky předkládaného vynálezu čistě prostřednictvím příkladů ve spojení s odkazy na připojené výkresy.

Přehled obrázků na výkresech

Obr.1 znázorňuje celkovou architekturu digitálního televizního systému;

Obr. 2 znázorňuje architekturu interaktivního systému digitálního televizního systému podle obr. 1;

Obr. 3 je schematické znázornění rozhraní přijímače/ dekodéru, který tvoří část systému podle obr. 1 a obr. 2;

Obr.4 je schematické znázornění dálkového ovladače použitého v digitálním televizním systému;

Obr. 5 znázorňuje uspořádání souborů uvnitř modulu staženého do paměti interaktivního přijímače/ dekodéru;

Obr. 6 ilustruje vzájemný vztah mezi množstvím komponentů MPEG datového toku;

Obr. 7 ilustruje, jak může být aplikace sestavena z modulů/tabulek, které dále mohou být sestaveny z úseků;

Obr. 8 ilustruje obsah adresářového modulu;

Obr. 9 ilustruje ve větším detailu část obsahu adresářového modulu; a

Obr.10 ilustruje různé oblastí paměti v přijímači/ dekodéru televizního systému.

9« » 99

9 9 9

9 9 • 9 9 · • 9 · 99«

9 9

999 ·999 99

999

Příklady provedení vynálezu

Celkový přehled digitálního televizního systému 1000 podle předkládaného vynálezu je znázorněn na obr. 1. Vynález zahrnuje většinou běžný digitální televizní systém 2000, který využívá známý MPEG-2 kompresní systém pro vysílání komprimovaných digitálních signálů. Přesněji MPEG-2 komprimátor 2002 ve vysílacím centru přijímá tok digitálního signálu (obvykle tok video signálů). Komprimátor 2002 je spojen s multiplexorem a kodérem 2004 prostřednictvím spojení

2006. Multiplexor 2004 přijímá množství dalších vstupních signálů, sestavuje jeden nebo více vysílacích toků a vysílá komprimované digitální signály do vysílače 2008 vysílacího centra přes spojení 2010, které samozřejmě může být představováno velkým množstvím různých forem včetně 15 telekomunikačních linek. Vysílač 2008 vysílá elektromagnetické signály přes vzestupné spojení 2012 směrem k satelitnímu odpovídači 2014, kde jsou tyto signály elektronicky zpracovány a vysílány přes teoretické sestupné spojení 2016 do pozemního přijímače 2018, běžně ve formě parabolické antény vlastněné nebo pronajímané koncovým uživatelem. Signály přijímané přijímačem 2018 jsou vysílány do integrovaného přijímače/dekodéru 2020 vlastněného nebo pronajímaného koncovým uživatelem a spojeného s televizním zařízením 2022 koncového uživatele. Přijímač/dekodér 2020 25 dekóduje komprimovaný MPEG-2 signál na televizní signál pro televizní zařízení 2022.

Systém 3000 podmíněného přístupu je spojen s multiplexorem 2004 a přijímačem/dekodérem 2020 a je umístěn částečně ve vysílacím centru a částečně v dekodéru. Tento systém umožňuje koncovému uživateli přístup k digitálním • · · · » • 4 ··* 44« • « • 4 44 • 4 · ·>·« 4 4 · 4

44 4·· 4444 44 44 televizním vysíláním (přenosům) od jednoho nebo více dodavatelů (poskytovatelů) vysílání. Inteligentní karta, schopná dekódování zpráv týkajících se komerčních nabídek (to jest jeden nebo několik televizních programů, které jsou prodávány dodavatelem vysílání), může být vložena do přijímaČe/dekodéru 2020. S použitím dekodéru 2020 a inteligentní karty může koncový uživatel nakupovat komerční nabídky buď v módu předplacení nebo v módu platby za shlédnutí.

S multiplexorem. 2004 a přijímačem/dekodérem 2020 je rovněž spojen interaktivní systém 4000, který je opět umístěn částečně ve vysílacím centru a částečně v dekodéru a který umožňuje koncovému uživateli interagovat s různými aplikacemi přes modemový zpětný kanál 4002.

Obr. 2 znázorňuje obecnou architekturu interaktivního televizního systému 4000 digitálního televizního systému 1000 podle předkládaného vynálezu.

Například tento interaktivní systém 4000 .umožňuje koncovým uživatelům nakupovat položky z katalogů zobrazených na obrazovce (on-screen), konzultovat místní zprávy a meteorologické mapy na požádání a hrát hry prostřednictvím jejich televizních zařízení.

V přehledu zahrnuje interaktivní systém 4000 čtyři hlavní prvky:• tvůrčí nástroj 4004 ve vysílacím centru nebo kdekoliv jinde pro umožnění poskytovateli vysílání vytvářet, vyvíjet, ladit a testovat aplikace;

• aplikační a datový obslužný kanál 4006 ve vysílacím centru, spojený s tvůrčím nástrojem 4004 pro umožnění * 25 » · ·· · ·*«*· ····* · ·« ··· ··* * · · * * * · · ·· ·· ··· ···· ·· ·· poskytovateli vysílání připravovat, ověřovat a formátovat aplikace a data pro dodání do multiplexoru a kodéru 2004 pro začlenění do MPEG-2 transportního datového toku (obvykle jeho privátní části), aby byla vysílána ke koncovému uživateli;

• virtuální počítač včetně prováděcího prostředku (RTE) 4008, který je v proveditelném kódu nainstalován v přijímači/dekodéru 2020 vlastněném nebo pronajatém koncovým uživatelem pro umožnění koncovému uživateli přijímat, ověřovat, dekomprimovat a stahovat (zavádět) aplikace do pracovní pamětí dekodéru 2020 pro vykonání. Tento prováděcí prostředek 4008 rovněž realizuje rezidentní aplikace obecného účelu. Prováděcí prostředek 4008 je nezávislý na hardwaru a operačním systému;

• modemový zpětný kanál 4002 mezi přijímačem/dekodérem 2020 a aplikačním a datovým obslužným kanálem 4006 pro umožnění signálům instruujícím tento aplikační a datový obslužný kanál 4006 zavádět data a aplikace do MPEG-2 transportního datového toku na žádost koncového uživatele.

Interaktivní televizní systém pracuje s použitím aplikací, které řídí funkce přijímače/dekodéru a různých zařízení v něm obsažených. Aplikace jsou reprezentovány v prováděcím prostředku 4008 jako zdrojové soubory. Modul je sestava zdrojových souborů a dat. Objem paměti přijímač/dekodéru je paměťový prostor pro moduly. Moduly mohou být stahovány do přijímače/dekodéru 2020 z MPEG-2 transportního datového toku.

0 0 0

000 0*0

0

00 *

• 0 00

0 9 0 * • 0 0 0 ♦ 00

0

Φ 000 0000

Fyzická rozhraní (propojení) přijímače/dekodéru 2020 jsou použita pro stahování dat. Ve spojení s odkazy na obr. 3 je patrné, že dekodér 2020 obsahuje, například, šest zaváděcích (stahovacích) zařízení; ladič 4028 MPEG toku, sériové rozhraní 4030, paralelní rozhraní 4032, modem 4034 a dvě zařízení 4036 pro čtení inteligentních karet.

Pro účely tohoto popisu je aplikace úsek strojového kódu pro řízení vysokoúrovňových funkcí výhodně přijímače/dekodéru 2020. Například, když koncový uživatel namíří ohnisko dálkového ovladače 2026 (jak je detailněji znázorněno na obr. 4) na tlačítkový objekt viděný na obrazovce televizního zařízení 2022 a stlačí potvrzovací klávesu, spustí se sekvence instrukcí, sdružená s tímto tlačítkem.

Interaktivní aplikace nabízí menu a vykonává příkazy na žádost koncového uživatele a poskytuje data týkající se účelu této aplikace. Aplikace mohou být buď rezidentními aplikacemi, to znamená, že jsou uloženy v ROM (nebo FLASH nebo jiné energeticky nezávislé paměti) přijímače/dekodéru 2020, nebo mohou být vysílány a stahovány do RAM ( nebo FLASH) tohoto dekodéru 2020.

Příklady aplikací jsou:• Inicializační aplikace. Přijímač/dekodér 2020 je vybaven rezidentní inicializační aplikací, která je adaptabilním souhrnem modulů (tento termín je podrobněji definován níže), umožňujícím přijímači/ dekodéru 2020 okamžitě pracovat v prostředí MPEG-2.

Tato aplikace zajišťuje základní znaky, které mohou být modifikovány poskytovatelem vysílání, pokud je to ··+· · » * 9 * v • · * · · · « ♦ ··· 9·· • t 9 9 9 · 9 9 »9 99 999 ·*99 99 99 žádoucí. Tato aplikace rovněž zajišťuje rozhraní mezi rezidentními aplikacemi a stahovanými aplikacemi.

• Spouštěcí aplikace. Spouštěcí aplikace umožňuje jakékoliv aplikaci, ať již stahované nebo rezidentní, pracovat v přijímači/dekodéru 2020. Tato aplikace působí jako samozaváděcí program vykonaný při vstupu do služby za účelem spuštění aplikace. Spouštěcí aplikace je stažena do RAM a tudíž může být snadno aktualizována. Může být uspořádána tak, že interaktivní 10 aplikace dostupné na každém kanálu mohou být zvoleny a spuštěny bud’ bezprostředně po stažení nebo po stažení předem. V případě stažení předem je aplikace stažena do paměti 2024 a je aktivována spouštěcí aplikací na požádání.

· Programový průvodce. Programový průvodce je interaktivní aplikace, která poskytuje ucelenou informaci o programech. Například může poskytovat informaci, řekněme, o televizních programech na jeden týden, které budou uváděny na každém kanálu souboru digitální televize. Stlačením klávesy na dálkovém ovladači 2026, koncový uživatel vstoupí do přídavné obrazovky, překrývající událost (relaci) znázorněnou na obrazovce televizního zařízení 2Q22 Tato přidaná obrazovka je vyhledávač (browser) poskytující informaci ' 25 o současných a následujících událostech (relacích) na každém kanálu souboru digitální televize. Stlačením další klávesy na dálkovém ovladači 2026 koncový uživatel vstoupí do další aplikace, která zobrazí seznam informací o událostech během jednoho týdne.

Koncový uživatel může rovněž vyhledávat a třídit ··« ·»·· •t· ··· události podle jednoduchých a přizpůsobených kritérií.

Koncový uživatel může rovněž vstoupit přímo do zvoleného kanálu.

Aplikace plateb za zhlédnutí. Aplikace plateb za shlédnuti je interaktivní služba dostupná na každém PPV kanálu souboru digitální televize ve spojení se systémem 3000 podmíněného přístupu. Koncový uživatel může vstoupit do této aplikace s použitím programového průvodce nebo vyhledávače kanálů. Navíc se aplikace spustí automaticky, jakmile je PPV událost zjištěna na PPV kanálu. Koncový uživatel potom může koupit probíhající událost buď prostřednictvím své dceřinné inteligentní karty 3020 nebo přes komunikační obslužný kanál 3022 (s použitím modemu, telefonu a DTMF kódů, systému MINITEL nebo podobně). Tato aplikace může být buď rezidentní v ROM přjímače/dekodéru 2020 nebo stažitelná do RAM přijímače/dekodéru 2020.

Aplikace PC stahování. Na žádost může koncový uživatel stahovat počítačový software s použitím této aplikace PC stahování.

Aplikace časopisový vyhledávač. Tato aplikace časopisového vyhledávače zahrnuje cyklické video vysílání obrazů s navigací koncového uživatele prostřednictvím tlačítek znázorněných na obrazovce. Aplikace kviz. Kviz aplikace je výhodně synchronizována s vysíláním kviz programu. Například jsou na obrazovce televizního zařízení 2022 zobrazeny otázky s několika odpovědimi a koncový uživatel může zvolit odpověď s použitím dálkového ovladače 2026. Aplikace kviz může • 44 · · 4 •4« ···· « Μ 4 4 · · · «4 44 informovat uživatele, zda odpověď je správná nebo ne, a může počítat skóre uživatele.

• Aplikace teleshopping. V jednom příkladu tato aplikace teleshopping jsou nabídky zboží na prodej vysílány do přijímače/dekodéru 202Q a zobrazovány na televizním zařízení 2022. S použitím dálkového ovladače 2026 může uživatel zvolit určitou položku, kterou chce koupit. Objednávka této položky je vyslána přes modemový zpětný kanál 4002 do aplikačního a datového obslužného kanálu

4006 nebo do samostatného prodejního systému, jehož telefonní číslo bylo staženo do příjímače/dekodéru 2020, případně s příkazem pro zatížení účtu kreditní karty, která byla vložena do jednoho zařízení 4036 pro čtení inteligentních karet v přijímači/dekodéru 2020.

· Aplikace telebanking. V jednom příkladu této aplikace telebanking uživatel vloží bankovní kartu do jednoho ze zařízení 4036 pro čtení inteligentních karet v příjímači/dekodéru 2020. Přijímač/dekodér 2020 zavolá banku uživatele s použitím telefonního čísla uloženého v bankovní kartě nebo uloženého v přijímači/dekodéru

2020, a potom tato aplikace poskytuje množství možností, které mohou být zvoleny s použitím dálkového ovladače 2026, například staženi přes telefonní linku stavu účtu, převod položek mezí účty, žádost o šekovou knížku a podobně.

• Aplikace internetovský vyhledávač. V jednom příkladu této aplikace internetovského vyhledávače jsou instrukce od uživatele, jako je žádost o sledování webové stránky mající určité URL, zadávány s použitím dálkového ovladače 2026 a tyto instrukce jsou vysílány • 44 4·· φ·4 ·»♦·

4 « · φ • 4 φφ prostřednictvím modemového zpětného kanálu 4002 do aplikačního a datového obslužného kanálu 4006.

Příslušná webová stránka je potom začleněna do vysílání z vysílacího centra, přijata přijímačem/dekodérem 2020 přes vzestupné spojení 2012, odpovídač 2014 a sestupné spojení 2016, a je zobrazena na televizním zařízení 2022.

Aplikace jsou uloženy v paměťových místech přijímači/dekodéru 2020 a jsou reprezentovány jako zdrojové soubory. Zdrojové soubory zahrnují soubory jednotky popisu grafických objektů, soubory jednotky proměnných bloků, soubory instrukčních sekvencí, aplikační soubory a datové soubory.

Soubory jednotek popisu grafických objektů popisují obrazovky, rozhraní mezi člověkem a počítačem aplikace. Soubory jednotek proměnných bloků popisují datové struktury zpracovávané aplikací. Soubory instrukčních sekvencí popisují zpracovatelské operace aplikace. Aplikační soubory zajišťují vstupní body pro aplikace.

Aplikace tvořené tímto způsobem mohou využít datové soubory, jako jsou knihovní soubory ikon, obrazové soubory, soubory znakových fontů, soubory tabulek barev a ASCII textové soubory. Interaktivní aplikace mohou rovněž získat přímá (on-line) data provedením vstupů a/nebo výstupů.

Prováděcí prostředek 4008 zavádí do své paměti pouze ty zdrojové soubory, které potřebuje v daném okamžiku. Tyto zdrojové soubory jsou čteny ze souborů jednotek popisu grafických objektů, souborů instrukčních sekvencí a ‘ 25 ···»»·« • t* ι·» aplikačních souborů; soubory jednotek proměnných bloků jsou uloženy v paměti následně po vyvolání procedury pro stažení modulů a zde zůstávají zajištěny, dokud není provedeno specifické volání procedury pro vyjmutí modulů.

Ve spojení s odkazy na obr. 3 je modul 4010, jako je nákupní modul popisovaný podrobněji níže, sestava zdrojových souborů a dat, která zahrnuje následující:

jeden aplikační soubor 4012;

neurčený počet souborů 4014 jednotky popisu grafických objektů;

neurčený počet souborů 4016 jednotky proměnných bloků;

neurčený počet souborů 4018 instrukčních sekvencí; a kde je to vhodné, datové soubory 4020, jako jsou knihovní soubory ikon, obrazové soubory, soubory znakových fontů, soubory tabulek barev a ASCII textové soubory.

Ve spojení s odkazy na obr. 5 je modul 4010, jako je nákupní modul popisovaný podrobněji níže, sestava zdrojových souborů a dat, která zahrnuje následující:

jeden aplikační soubor 4012;

neurčený počet souborů 4014 jednotky popisu grafických objektů;

neurčený počet souborů 4016 jednotky proměnných bloků;

neurčený počet souborů 4018 instrukčních sekvencí; a

9 «

• 9

999 9999

99

999 99» kde je to vhodné, datové soubory 4020, jako jsou knihovní soubory ikon, obrazové soubory, soubory znakových fontů, soubory tabulek barev a ASCII textové soubory.

Koncept modulů společně s konceptem stahování malých částí kódu umožňuje snadný vývoj aplikací. Aplikace mohou být staženy do permanentní FLASH paměti dekodéru 2020 jako rezidentní software, nebo mohou být vysílány, aby byly staženy do RAM dekodéru 2020, pouze když je koncový uživatel potřebuj e.

Pro stažení modulu 4010 z nosného signálu je nejprve stažen adresář dostupný na nosném signálu. Tento adresář jednoduše obsahuje seznam jmen modulů 4010, které mohou být staženy z nosného signálu. Jakmile již byl tento adresář stažen, je možné stahovat pro aplikaci jeden nebo více modulů 4010. V případě MPEG toku je adresář transportován v jedné samostatné MPEG tabulce. Navíc je v jedné samostatné tabulce transportován jeden modul 4010. V případě modulů vysílaných do ladiče 4028 MPEG toku je použito dlouhého formátu MPEG-2 s delším záhlavím a CRC kódem. To je rovněž případ pěti dalších rozhraní (sériové rozhraní 4030, paralelní rozhraní 4032, modem 4034 a dvě zařízení 4036 pro čtení inteligentních karet) až na to, že je použito krátkého” MPEG-2 formátu s kratším záhlavím a bez CRC kódu.

jak je patrné zejména z obr. 6 a jak je známo, zahrnuje MPEG-2 bitový tok tabulku IQ přístupu do programů (PAT), která má identifikaci paketu (PID) na hodnotě 0. PAT 10 obsahuje odkazy na PID tabulek 12 mapování programů (PMT) množství programů. Každá PMT 12 obsahuje odkazy na PID toků audio MPEG tabulek 14 a video MPEG tabulek 16 pro tento program. Paket mající PID nula, to jest tabulka 20 • φφφ φφφ φ φ * φ φ φ «· φφφφ φφ «φ přístupu do programů, zajišťuje vstupní bod pro veškerý MPEG přístup.

Za účelem stahování aplikací a dat pro tyto aplikace jsou definovány dva nové typy toků a relevantní PMT 12 rovněž obsahuje odkazy na PID toků aplikačních MPEG tabulek 18 (nebo jejich úseků) a datových MPEG tabulek 20 (nebo jejich úseků).

Jak je patrné na obr. 7, aby bylo možné stahovat aplikaci 22, je tato aplikace rozdělena do modulů 24, z nichž každý je tvořen MPEG tabulkou, přičemž některé z nich jsou sestaveny z jednoho úseku 18 a jiné jsou sestaveny z množství úseků 18. Typický úsek 18 má záhlaví 26, které zahrnuje jedno-bytovou identifikaci 28 tabulky (TID), číslo 30 úseku pro tento úsek v tabulce, celkový počet 32 úseků v této tabulce a dvou-bytové TID-rozšíření 34. Každý úsek rovněž zahrnuje datovou část 36 a CRC 38. Pro určitý modul/tabulku 24 mají všechny z úseků 18 tvořící tuto tabulku/modul 24. stejnou TID 28 a stejné TID-rozšíření 34. Pro určitou aplikaci 22 všechny z tabulek 24 tvořící tuto aplikaci 22 mají stejnou TID 28, ale různé odpovídající TID-rozšíření 34.

Pro každou aplikaci 22 existuje jedna taková MPEG tabulka 24., která je použita jako adresář a která je ve větším detailu znázorněna na obr. 8. Adresářová tabulka 40 zahrnuje záhlaví 26, adresářovou část 42, identifikací 44 klíče, kódovaný podpis 46 a CRC 38. Ze shora uvedeného popisu by mělo být zcela zřejmé, že adresářová tabulka 40 má ve svém záhlaví 26 stejnou TID 28 jako ostatní moduly/tabulky 24.

tvořící aplikaci 22.. Adresářová tabulka 40 má ale předem stanovené TID-rozšíření 34 s hodnotou nula, a všechny z • fefe fefefe fe » fefe fefe > fe t · · » fefe fe • fe fefe ostatních modulů/tabulek 24 mají nenulová TlD-rozšíření 34. Záhlaví 26 rovněž zahrnuje číslo 48 verze pro adresářovou tabulku 40. Adresářová část 42 zahrnuje pro každý z dalších modulů/tabulek 24 tvořících aplikaci 22 jméno 50 tohoto modulu 24, TID-rozšíření 34 pro tento modul 24 a podpis 52 tohoto modulu 24. Adresářová část může rovněž zahrnovat pro každý z dalších modulů/tabulek 24 délku tohoto modulu 24 a číslo verze tohoto modulu 24.

Jak je opět patrné z obr. 6, jsou při činnosti systému PAT 10. PMT 12 a aplikační a datové tabulky 18, 20 cyklicky vysílány, přičemž jsou aktualizovány podle potřeby. Každá aplikace, která je vysílána má příslušnou předem stanovenou TID 28. Pro stažení aplikace je do přijímače/dekodéru 2020 stažena MPEG tabulka mající odpovídající TID a TID-rozšíření s hodnotou nula. To je tedy adresářová tabulka 40 pro požadovanou aplikaci. Data v adresáři jsou potom zpracována přijímačem/dekodérem 2020 pro určení TID-rozšíření 34 modulových tabulek tvořících tuto požadovanou aplikaci, a potom může být stažena jakákoliv požadovaná modulová tabulka mající stejnou TID jako adresářová tabulka a TID-rozšíření určené z adresáře.

Přijímač/dekodér 2020 je uspořádán pro ověření adresářové tabulky pro její jakoukoliv aktualizaci. To může být provedeno prostřednictvím stahování adresářové tabulky periodicky vždy znovu, například každých 30 sekund, nebo jednu či pět minut, a porovnáváním čísla verze čerstvě stažené adresářové tabulky s číslem verze předtím stažené adresářové tabulky. Pokud čerstvě stažené číslo verze je pozdější, pak jsou moduly sdružené s předcházející adresářovou tabulkou, nebo jakékoliv takové moduly, pro které • w

0 0 »· · · · Μ* 000 »000 · » · 0 • 0 ·· 0·0 0000 00 »0 jsou zde starší čísla verzí, demontovány a pozdější moduly jsou staženy a namontovány. V-’alternativním uspořádání je přicházející bitový tok filtrován s použitím masky odpovídající TID, TID-rozšíření a číslu verze, s hodnotami nastavenými na TID aplikace, TID-rozšíření nula a číslo verze o jednu větší, než je číslo verze právě staženého adresáře. Podle toho tedy může být detekován přírůstek v číslu verze, a jakmile je detekován, je adresář stažen a aplikace je aktualizována, jak je popisováno výše. Další popis takového filtrování je popsán v souběžné patentové přihlášce (číslo zástupce: 73151/PT). Pokud aplikace má být ukončena, je vysílán prázdný adresář s příštím číslem verze, ale bez jakýchkoliv modulů uvedených v tomto adresáři. V odezvě na přijetí takovéhoto prázdného adresáře je přijímač/dekodér

2020 naprogramován pro demontáž aplikace.

Použití podpisů a kódování pro aplikační tabulky bude nyní popsáno poněkud podrobněji.

Jak je popisováno výše, zahrnuje vstup pro každý

2Q modul v adresářové tabulce 40 modulový podpis. Modulový podpis je vytvořen s použitím známého procesu vytvářejícího MD5 podpis na datech v odpovídající modulové tabulce.

Navíc adresářová tabulka 40 zahrnuje kódovaný podpis 46, který je vytvářen způsobem, který bude nyní popsán ve spojení s odkazy na obr. 9. Je vytvořen blok 54 o 64 bytech dat. První byte 56 je nula. Následující tři byty 58 mohou zahrnovat fiktivní nebo libovolná data. Následujících osm bytů 60 vytvářejí bitovou mapu pro ověření platnosti aplikace, která bude dále popsána. Poslední čtyři byty 62 jsou rezervovány. Zbývajících 32 bytů obsahuje 16-bytový podpis 64, který začíná v posunutí mezi 0 a 31 bytem po φ

φ φ ··· φφφφ • φ φ φ • · ·Φ φ φ φφ φ φ φ φ φ φ φ· «φ prvním bytu následujícím po bytech bitové mapy 60 pro ověření platnosti aplikace. Fiktivní data 66 jsou vložena mezi bitovou mapu 60 pro ověření platnosti aplikace a podpis 64 a/nebo mezi podpis 64 a rezervované byty 62. Podpis 64 je vytvářen s použitím známého procesu pro vytváření MD5 podpisu na adresářové části 42 v adresářové tabulce 40. Blok 54 je potom kódován s použitím známého kódovacího procesu a určitého privátního klíče pro vytvoření bloku 46 kódovaného podpisu a kódované bitové mapy pro věření platnosti aplikace. Tento datový blok 46 je začleněn do adresářové tabulky 40., a jedno-bytová identifikace privátního klíče, který byl použit pro kódování tohoto bloku, je začleněna do adresářové tabulky jako identifikace 44 klíče.

Pro shrnutí vytváření aplikace a její vysílání zahrnuje následující kroky:• vytvoření aplikace jako množství modulů;

• zaznamenání předem stanovené TID 28 pro aplikaci;

• přiděleni jmen a nenulových TID-rozšíření 34 pro moduly;

» formátování každého modulu jako MPEG tabulky 24 nebo úseků 18 MPEG tabulky;

• vytvoření MD5 podpisu 52 každého modulu;

• vytvoření adresáře 42;

• vytvoření MD5 podpisu 64 pro adresář;

• zvolení bitu platnosti v bitové mapě 60 pro ověření platnosti aplikace;

• zvolení posunutí;

• vytvoření bloku 54;

• kódování bloku 54 s použitím kódování se zvoleným privátním klíčem;

φφφ φφφ φ·· φφφφ

Φ φ Φ 1

Φ φ Φ ι φφ ·Φ φφ φφ • vytvoření adresářové MPEG tabulky 40 s přidělenou PID 28, TID-rozšířením nula, adresářem 42, identifikací 44 privátního klíče a kódovaným podpisem 46;

• vysílání adresářové tabulky 40 a modulových tabulek 24 nebo úseků 18.

V následujícím popisu bude popsána činnost přijímače/dekodéru 2020 při zpracovávání podpisů a při dekódování v průběhu stahování aplikace. Jak je patrné z obr. 10, zahrnuje přijímač/dekodér 2020 paměti EEPROM 68, ROM 70 a RAM 72. EEPROM 68 zahrnuje chráněnou oblast 74., která je používána virtuálním počítačem a kam může zapisovat pouze virtuální počítač (a ne běžná aplikace). Tato chráněná oblast 74 zahrnuje bitovou mapu 76 pro ověření klíče o velikosti 16 nebo 256 bitů, bitovou mapu 78 pro ověření aplikace o velikosti 64 bitů, a bitovou mapu 80 posunutí o velikosti 32 bitů. ROM 70 zahrnuje v jednom provedení šestnáct veřejných klíčů 82, přičemž v tomto případě je použito 16-bitové bitové mapy 76 pro ověření klíče, a v dalším provedení 256 veřejných klíčů 82, přičemž v tomto případě je použité 256-bitové bitové mapy 76 pro ověření klíče. Veřejné klíče 76 jsou identifikovány prostřednictvím jejich fyzických poloh v ROM 7Q, nebo alternativně mohou být začleněny ve vyhledávací tabulce, přičemž identifikace určitého klíče bude ukazovat na odpovídající veřejný klíč 76.. RAM 72 může být použita pro uložení dočasného klíče 84.

Jak bylo zmiňováno výše, když má být stažena aplikace, je nejprve stažena adresářová tabulka mající předem stanovenou TID pro tuto aplikaci a TID-rozšíření nula. Identifikace 44 klíče je potom vyjmuta z adresářové tabulky a je provedeno ověření bitové mapy 76 pro ověření klíče v • · • *

A A A AAA ·ΑΑ • A A · A ·· «ΑΑ AAAA ·· ·Α chráněné oblasti 21, že bit odpovídající vyjmuté identifikaci 44 klíče je nastaven. Pokud není, pak další stahování aplikace je přerušeno. Pokud je ale příslušný klíč nastaven, pak je z ROM 70 zvolen veřejný klíč 82 odpovídající vyjmuté identifikaci 44 klíče. Zvolený veřejný klíč 82 a známý dekódovací proces jsou potom použity pro dekódování kódovaného bloku 4 6 v adresářové tabulce 40. pro vytvoření bloku 21· Potom je z dekódovaného bloku 54 vyjmuta bitová mapa 60 pro ověření platnosti aplikace a je s ní proveden logický součin (funkce AND) s bitovou mapou 78 pro ověření platnosti aplikace, která je uložena v chráněné oblasti 21 paměti. Pokud výsledek funkce AND je nula, pak další stahování aplikace je přerušeno. Pokud je ale výsledek funkce AND nenulový, pak je vyhledáno posunutí v bitové mapě 22 posunutí v chráněné oblastí 74 paměti, nebo, pokud je nastaven více než jeden bit posunutí, je vyhledán každý bit posunutí, a z dekódovaného bloku 54 je vyjmuto šestnáct bytů dat začínajíc s vyhledaným posunutím od prvního bytu za bitovou mapou 60 pro ověření platnosti aplikace. Pro uvedené jedno nebo každé vyhledané posunutí, je těchto 16 bytů považováno za podpis vysílaný s adresářovou tabulkou 40.

Podpis vstupů v adresářové části 42 adresářové tabulky 40 je vypočítán s použitím známého MD5 procesu a tento vypočítaný podpis je porovnán s podpisem vyjmutým z bloku 51· Pokud si tyto dva podpisy pro uvedené jedno nebo každé vyhledané posunutí nedopovídají, pak je další stahování aplikace přerušeno. Pokud ale jeden z podpisů odpovídá, pak může pokračovat stahování modulů specifikovaných v adresářové části 42. Jak bylo zmiňováno výše, pro stažení určitého modulu je z adresářové části 42 získáno TID-rozšíření pro ftft* ··♦ • « ftft v «ftftftft · «ft ftftftft ftft ft* • ft ftft ftftft ftftftft ftft ftft tento modul a je stažena MPEG tabulka 24 nebo úseky 18 se stejnou TID, jako má adresářová tabulka, a se získaným TID-rozšířením. Jakmile jíž byla modulová MPEG tabulka stažena, přijímač/dekodér 2020 vypočítá podpis stažené tabulky s použitím známého MD5 procesu a potom porovná tento vypočítaný podpis s podpisem obsaženým ve vstupu adresáře.

Pokud si podpisy odpovídají, pak je modul akceptován, pokud se ale neodpovídají, pak je modul vyřazen.

Všechny z modulů aplikace mohou tedy být staženy způsobem specifikovaným výše, a aplikace může být spuštěna přijímačem/dekodérem 2020.

Po tomto popisu znaků operace stahování, která je obvykle používána, bude učiněn popis některých znaků použitých při nastavování přijímače/dekodéru 2020 a při změnách jeho nastavení.

Přijímač/dekodér 2020 je naprogramován tak, že chráněná oblast 74 paměti může být měněna, ale pouze aplikací, která již byla stažena s použitím určité jedné z

2q identifikací klíče, například klíče 15, a s určitým posunutím, například posunutí nula bytů od prvního bytu po bitové mapě 60 pro ověření platnosti aplikace. Chráněnou oblast 74 paměti by mohlo být potřeba změnit, například, pokud se dva operátoři, kteří používali stejný veřejný klíč, rozhodnou, že si přejí používat různé veřejné klíče, nebo pokud obsah privátního klíče byl odhalen, přičemž v tomto případě odpovídající veřejný klíč může být v bitové mapě 76 pro ověření klíče označen jako neplatný.

Příjímač/dekodér 2020 může být uspořádán tak, že jeden z klíčů, například klíč 15, je vždy dostupný, přičemž v • * • 4 • 44 ♦···

··· ··· • 4 • 4 44 tomto případě tento klíč nevyžaduje bit v bitové mapě 76 pro ověření klíče. Podle toho tedy může být tento bit použit pro jiný účel. Přesněji tedy aplikace, která již byla ověřena s použitím klíče 15, může být uspořádána pro nastavení tohoto určitého bitu na 1, přičemž v tomto případě je přijímač/dekodér 2020 naprogramován pro umožnění stažení dočasného klíče 84 do RAM 72, ale pouze tehdy, když je to prostřednictvím sériového rozhraní 4030. paralelního rozhraní 4032 nebo jednoho ze dvou zařízení 4036 pro čtení inteligentních karet. Toto opatření může být využito, například, výrobcem přijímače/dekodéru 2020, kterým může být zadána aplikace pro použití aktivace stahování dočasného klíče do přijímače/dekodéru 2020, takže tento přijímač/dekodér 2020 může být testován.

Kódovací a podpisové uspořádání popisované výše zajišťuje množství důležitých znaků. Zejména:• aplikace může být stažena pouze tehdy, když přijímač/dekodér 2020 má ve své paměti uložen příslušný veřejný klíč odpovídající identifikací 44 klíče ve stažené adresářové tabulce;

• pro všechny až na jeden z klíčů může být aplikace stažena pouze s použitím určitého klíče, pokud je v paměti při j ímače/dekodéru 2020 nastavena bitová mapa 76 pro ověření klíče tak, že umožňuje použití tohoto klíče;

• aplikace může být stažena pouze, když nastavený bit v bitové mapě 80 posunutí, uložené v paměti přijímače/dekodéru 2020, odpovídá posunutí použitému při vytváření adresářové tabulky;

• 9 99 Ww-w• 9 9 9 9 9 99 ·99 999 • 999 99 99 • 9 9« 999 9999 99 9· * 25 • aplikace může být stažena pouze tehdy, když je bitová mapa 78 pro ověření platnosti aplikace, uložená v paměti přijímače/dekodéru 2020, vhodně nastavena pro umožnění stažení aplikace;

• aplikace může být stažena pouze tehdy, když adresářová tabulka nebyla poškozena poté, co byl původně vytvořen její podpis;

• každý modul aplikace může být stažen pouze tehdy, když odpovídající modulová tabulka nebyla poškozena poté, co byl původně vytvořen její podpis;

' při přípravě aplikace pro stažení je vyžadován pouze jeden kódovací proces bez ohledu na to, že aplikace je sestavena z několika MPEG tabulek, a pro stažení celé aplikace jev přijímači/dekodéru 2020 vyžadován pouze jeden dekódovací proces;

• může být použito vícenásobných klíčů, takže různí poskytovatelé služeb mohou mít různé privátní klíče;

• může být použit dočasný klíč, například výrobcem, pro testovací účely.

Mělo by být zcela zřejmé, že předkládaný vynález byl popsán výše čistě prostřednictvím příkladu, a že v rozsahu tohoto vynálezu mohou být provedeny modifikace jednotlivých detailů.

Každý znak popisovaný v popisu a (kde je to vhodné) v nárocích a na výkresech může být vytvořen nezávisle nebo v jakékoliv vhodné kombinaci.

Ve shora zmiňovaných výhodných provedeních byly určité znaky předkládaného vynálezu realizovány s použitím počítačového softwaru. Ovšem osobám v oboru znalým je přirozeně zcela zřejmé, že jakýkoliv z těchto znaků může být • · ·· • 0 · 0 · • · 0 0 • 0 00 • 00 ····

00* 00· 0 0

0* realizován s použitím hardwaru. Navíc by mělo být zcela zřejmé, že funkce prováděné hardwarem, počítačovým softwarem a podobně jsou prováděny na nebo s použitím elektrických a podobných signálů.

Na tomto místě je učiněn odkaz na souběžné patentové přihlášky stejného přihlašovatele, které mají stejné datum podání a následující názvy: vytváření a vysílání signálů (značka zástupce: 73142/PT), Inteligentní karta pro použití s přijímačem kódovaných vysílaných signálů a přijímač (značka zástupce: 73143/PT), Vysílací a přijímací systém a systém s podmíněným přístupem (značka zástupce: 73145/PT), Stahování počítačového souboru z vysílače přes přijímač/dekodér do počítače (značka zástupce: 73146/PT), Vysílání a příjem televizních programů a jiných dat (značka zástupce:

73147/PT), Způsob zavádění dat do MPEG přijímače/dekodéru a MPEG vysílací systém pro jeho realizaci (značka zástupce: 73148/PT), Organizace počítačové paměti (značka zástupce: 73149/PT), Způsob vývoje a testování řídícího programu (značka zástupce: 73150/PT), Vybírání datových úseků z vysílaného datového toku (značka zástupce: 73151/PT), Systém řízení přístupu (značka zástupce: 73152/PT), Systém pro zpracování dat (značka zástupce: 73153/PT), Vysílací a přijímací systém, přijímač/dekodér a vzdálená řídící jednotka (značka zástupce: 73154/PT). Popisy těchto dokumentů jsou začleněny do tohoto popisu prostřednictvím odkazu. Seznam přihlášek obsahuje předkládanou přihlášku.

Zastupuje :

Claims (56)

1. PATENTOVÉ NÁROKY

   1. Způsob zavádění alespoň části aplikace do MPEG přijímače/dekodéru, vyznačující se tím, že zahrnuje kroky:

   rozdělení aplikace do množství modulů;

   formátování každého z modulů jako odpovídající MPEG tabulku, přičemž tyto tabulky mají stejnou tabulkovou identifikaci (TID) a odpovídající odlišná tabulková identifikační rozšíření (TID-rozšíření) jiná, než je předem stanovené TID-rozšíření;

   vytvoření adresářové MPEG tabulky pro moduly, která má stejnou uvedenou TID a uvedené předem stanovené

   TID-rozšíření, přičemž adresář obsahuje pro každý modul jméno tohoto modulu a odpovídající TID-rozšíření;

   cyklického vysílání adresářové MPEG tabulky a modulových MPEG tabulek v MPEG bitovém toku; a v MPEG přijímači/dekodéru:přijímání MPEG bitového toku;

   stahování té jedné z MPEG tabulek, která má předem stanovené TID-rozšíření tak, aby byla stažena adresářová MPEG tabulka;

   určování z obsahu adresářové MPEG tabulky TID-rozšíření modulových MPEG tabulek; a stahování alespoň jedné z modulových MPEG tabulek majících stejnou TID, jako je TID stažené adresářové MPEG tabulky, a TID-rozšíření určené ze stažené adresářové MPEG tabulky.
2. 2. Způsob podle nároku 1, vyznačující se tím, že dále zahrnuje kroky:

   začlenění čo vysílané adresářové MPEG tabulky identifikaci ···· ·· 9 9 «999

   9 9** 9 · · * 9 9

   9 9··* * « * *·9 **·

   9999 * * * * ·· 9* ·9* ·9·· *9 99 verze pro tuto tabulku; a v přijímači/dekodéru: určování zda identifikace verze právě vysílané adresářové PMT MPEG tabulky je aktuálnější než

   5 identifikace verze právě stažené adresářové MPEG tabulky, a pokud ano, opakování kroků stahování adresářové MPEG tabulky, určování TID-rozšíření, a stahování alespoň jedné z modulových MPEG tabulek,
3. 3. Způsob podle nároku 1 nebo 2, vyznačuj ící se t í m , že alespoň jedna z modulových MPEG tabulek je formátována jako množství MPEG úseků, které jsou vysílány samostatně v MPEG bitovém toku, přičemž každý tento MPEG úsek obsahuje v jeho předem stanovené části identifikaci tohoto

   MPEG úseku v MPEG tabulce a indikaci počtu úseků v MPEG 15 tabulce.
4. 4. MPEG přijímač/dekodér pro použití při realizaci části způsobu podle kteréhokoliv z předcházejících nároků, vyznačující se tím, že zahrnuje:

   20 přijímač pro přijímání MPEG bitového toku; paměťový prostředek; a zpracovatelský prostředek, který je naprogramován pro řízení , stahování té jedné z přijímaných MPEG tabulek, která má předem stanovené MPEG-rozšíření, do paměťového prostředku, “ 25 pro určování z obsahu adresářové MPEG tabulky TID-rozšíření modulových MPEG tabulek, a pro řízení stahování do paměťového prostředku alespoň jedné z modulových MPEG tabulek, která má stejnou TID, jako je TID stažené adresářové MPEG tabulky, a TID-rozšíření určené ze stažené adresářové MPEG tabulky.

   • • 44 • · 4 * • * • 4 4 4 4 4 4 «·* 444 4 4 4 4 4 4 4 4 • • 44 4*4 4444 44 44
5. 5. Přijímač/dekodér podle nároku 4 pro použití se způsobem podle nároku 2, vyznačující se tím, že zpracovatelský prostředek je naprogramován pro určování, zda identifikace verze právě přijímané adresářové MPEG tabulky je

   5 aktuálnější, než je identifikace verze stažené adresářové

   MPEG tabulky, a pokud ano, pro opakování stahování adresářové MPEG tabulky, určování TID-rozsíření a stahování alespoň ječné z modulových MPEG tabulek.
6. 6. Přijímač/dekodér podle nároku 4 nebo 5 pro použití se způsobem podle nároku 3, vyznačující se tím, že zpracovatelský prostředek je naprogramován pro řízení opakovaného stahování MPEG úseků do paměťového prostředku, dokud zpracovatelský prostředek neurčí z identifikací úseků a indikace počtu úseků stahovaných úseků, 15 že již byly staženy všechny z úseků.
7. 7. Přijímač/dekodér podle kteréhokoliv z nároků 4 až β, vyznačující se tím, že dále zahrnuje paralelní port a/nebo sériový port uspořádaný pro přijetí

   20 aplikace formátované jako alespoň jedna MPEG tabulka.
8. 8. MPEG vysílací systém, vyznačující se tím, že zahrnuje:

   prostředek pro rozdělení aplikace určené ke stažení do MPEG přijímače/dekodéru na množství modulů;

   25 - , , , prostředek pro formátováni každého z modulů jako odpovídající MPEG tabulky, přičemž tyto tabulky mají stejnou TID a příslušná odlišná TID-rozšíření, jiná než je předem stanovené TID-rozšíření;

   prostředek pro vytváření adresářové MPEG tabulky pro moduly, ³⁰ která má stejnou uvedenou TID a uvedené předem stanovené » v a * a · a * * 4* 4

   4 4 ·4 4 4 4 4 4 4

   44»·· · 4 * *44 444

   4 4 4 4 44 4*

   44 44 444 4444 44 4·

   TID-rozšíření, přičemž adresář obsahuje pro každý z modulů jméno tohoto modulu a příslušné TID-rozšíření; a prostředek pro cyklické vysílání adresářové MPEG tabulky a modulových MPEG tabulek v MPEG bitovém toku.
9. 9. Systém podle nároku 8, vyznačující se tím, že dále zahrnuje prostředek pro vytváření identifikace verze pro adresářovou MPEG tabulku; přičemž prostředek pro vytváření adresářové MPEG tabulky je uspořádán pro začlenění do adresářové MPEG tabulky vytvořené identifikace verze pro tuto tabulku.
10. 10. systém podle nároku 8 nebo 9, vyznačuj ící se t í m , že prostředek pro formátování modulů je uspořádán pro formátování alespoň jedné z modulových MPEG ]_5 tabulek jako množství MPEG úseků, z nichž každý v jeho předem stanovené části obsahuje identifikaci tohoto MPEG úseku v této MPEG tabulce a indikaci počtu MPEG úseků v této MPEG tabulce.
11. 11. Způsob zavádění dat do MPEG přijímače/dekodéru, vyznačující se tím, že zahrnuje kroky: vytváření podpisu pro data určená ke stažení; kódování podpisu s použitím privátního klíče; formátování dat určených ke stažení, kódovaného podpisu a identifikace pro privátní klíč jako MPEG tabulky;

    25 vysílání MPEG tabulky; a v příjímači/dekodéru:přijímání MPEG tabulky;

    zvolení jednoho z množství veřejných klíčů podle identifikace klíče v přijaté MPEG tabulce; dekódování kódovaného podpisu v přijaté MPEG tabulce s • 0 • 9 · • 9 ·· • 9 · 0 9

    9 9 9 9

    9 9 99

    9 9999 «9 9

    0 9 « »90 999

    0 0

    90 99 použitím zvoleného veřejného klíče pro vytvoření dekódovaného podpisu;

    vytváření podpisu pro data v přijaté MPEG tabulce; a porovnání dekódovaného podpisu a podpisu vytvořeného v

    5 přijímači/dekodéru pro přijatá data.
12. 12. Způsob podle nároku 11, vyznačující se tím, že dále zahrnuje kroky: stahování do přijímače/dekodéru aplikace mající podpis kódovaný s použitím privátního klíče majícího předem stanovenou identifikaci klíče; spuštění aplikace v přijímači/dekodéru pro řízení přijímače/dekodéru pro přijetí dalšího klíče; uložení tohoto dalšího klíče v oblasti energeticky závislé paměti přij ímače/dekodéru.

    15
13. 13. Způsob podle nároku 12, vyznačující se tím, že v průběhu kroku spuštění aplikace je další klíč předáván lokálně do přijímače/dekodéru.
14. 14. Způsob podle nároku 13, vyznačující se tím, že další klíč je předáván do přijímače/dekodéru přes paralelní port, sériový port nebo čtecí zařízení inteligentních karet přijímače/dekodéru.
15. 15. Způsob podle kteréhokoliv z nároků 11 až

    14, vyznačující se tím, že dále zahrnuje kroky: v přijímači/dekodéru: vyhledávání v chráněné oblasti paměti přijímače/dekodéru příznaku platnosti pro zvolený veřejný klíč; a zamezení nebo přerušení stahování dat, pokud vyhledaný příznak platnosti není nastaven.

    4 · · ·

    4 4 4 4

    44< «44

    4 4 • 4 44 « * · « · • 4 ·· • · 4 4 ·

    4 · · 4 «4 4» 4 ♦ ····
16. 16, Způsob podle nároku 15 závislého na kterémkoliv z nároků 12 až 14,vyznačující se tím, že v chráněné oblasti paměti přijímaČe/dekodéru privátní klíč mající předem stanovenou identifikaci klíče má příznak platnosti, který může být měněn prostřednictvím uvedené aplikace, přičemž schopnost přijímat další klíč je určena v závislosti na stavu tohoto příznaku platnosti.
17. 17. Způsob zavádění dat do MPEG přijímaČe/dekodéru, vyznačující se tím, že zahrnuje kroky:vytváření podpisu pro data určená ke stažení;

    kódování podpisu s použitím privátního klíče;

    formátování dat určených ke stažení, kódovaného podpisu a identifikace pro privátní klíč jako MPEG tabulky; vysílání MPEG tabulky; a v přijímači/dekodéru:přijímání MPEG tabulky;

    vyhledávání v chráněné oblasti paměti přijímaČe/dekodéru příznaku platnosti pro veřejný klíč odpovídající privátnímu klíči identifikovanému v přijaté MPEG tabulce; a pokud je vyhledaný příznak platnosti nastaven:dekódování kódovaného podpisu v přijaté MPEG tabulce s použitím veřejného klíče odpovídajícího privátnímu klíči identifikovanému v přijaté MPEG tabulce pro vytvoření dekódovaného podpisu; vytváření podpisu pro data v přijaté MPEG tabulce; a porovnání dekódovaného podpisu a podpisu vytvořeného v přijímači/dekodéru pro přijatá data.

    0 ·«

    0 0 0 • 00

    0 0

    0 0

    000 0000 • * 0 >

    • 0 · • · 0 * * • 0 0 0

    0· ·0 «

    ·*0

    00 00
18. 18. Způsob podle kteréhokoliv z nároků 11 až

    17, vyznačující se tím, že dále zahrnuje kroky:vytvoření ověřovacího kódu pro data určená ke stažení,

    5 přičemž tento ověřovací kód je kódován s podpisem v kódovacím kroku a je dekódován s podpisem v dekódovacím kroku; vyhledání uloženého ověřovacího kódu v chráněné oblasti paměti přijímače/dekodéru; a

    F porovnání vyhledaného ověřovacího kódu a dekódovaného 10 ověřovacího kódu.
19. 19. Způsob zavádění dat do MPEG přijímače/dekodéru, vyznačující se tím, že zahrnuje kroky:vytváření ověřovacího kódu pro data určená ke stažení;

    vytváření podpisu pro data určená ke stažení, nebo jejich 15 části;

    kódování ověřovacího kódu a podpisu s použitím privátního klíče;

    formátování dat určených ke stažení a kódovaného ověřovací kódu a podpisu jako alespoň jedné MPEG tabulky;

    vysílání uvedené jedné nebo každé MPEG tabulky; a v přijímači/dekodéru:přijímání uvedené jedné nebo každé MPEG tabulky; dekódování kódovaného ověřovacího kódu a podpisu v přijatých MPEG tabulkách s použitím veřejného klíče * 25 odpovídajícího privátnímu klíči;

    vyhledání uloženého ověřovacího kódu v chráněné oblasti paměti přijímače/dekodéru;

    porovnání vyhledaného ověřovacího kódu a dekódovaného ověřovacího kódu;

    vytváření podpisu pro data v přijatých MPEG tabulkách, * · 9 · 9 ·

    9 9 9 999 999

    9 9 9 9 • 99 9999 99 *»

    9 9 nebo jejich část; a porovnání dekódovaného podpisu s podpisem vytvořeným v přijímači/dekodéru pro přijatá data.
20. 20. Způsob podle nároku 18 nebo 19, vyznačuj ící se t í m , že dále zahrnuje krok zamezení nebo přerušení stahování dat, pokud si v kroku porovnávání ověřovacích kódů vyhledaný ověřovací kód a dekódovaný ověřovací kód vzájemně neodpovídej í.
21. 21. Způsob podle kteréhokoliv z nároků 11 až

    20, vyznačující se tím, že podpis dat určených ke stažení je kódován v bloku dat, včetně dalších dat, se zvoleným posunutím mezi začátkem datového bloku a začátkem podpisu, a kódovaný datový blok je dekódován v kroku dekódování v přijímači/dekodéru, přičemž způsob podle vynálezu dále zahrnuje kroky v přijímači/dekodéru:vyhledávání alespoň jednoho uloženého posunutí v chráněné oblasti paměti přijímače/dekodéru; a vyjmutí podpisu z dekódovaného datového bloku s použitím uvedeného jednoho vyhledaného posunutí od začátku dekódovaného datového bloku.
22. 22. Způsob zavádění dat do MPEG přijímače/dekodéru, vyznačující se tím, že zahrnuje kroky vytváření podpisu pro data určená ke stažení;

    začlenění podpisu a dalších dat do bloku dat se zvoleným posunutím mezi začátkem datového bloku a začátkem podpisu; kódování datového bloku s použitím privátního klíče; formátování dat určených ke stažení a kódovaného datového bloku jako MPEG tabulky;

    vysílání této MPEG tabulky; a v přijímači/dekodéru:48 ·· 00 • 0 »0 0 • 0 0 0 0 · • 0 0 0 0 • · 0 0 00 0

    0 0 0* 00 přijímání MPEG tabulky;

    dekódování kódovaného datového bloku v přijaté MPEG tabulce s použitím veřejného klíče odpovídajícího privátnímu klíči;

    5 vyhledání alespoň jednoho uloženého posunutí v chráněné oblasti paměti přijímače/dekodéru; vyjmutí podpisu z dekódovaného datového bloku s použitím uvedeného jednoho vyhledaného posunutí od začátku dekódovaného datového bloku;

    10 vytváření podpisu pro data v přijaté MPEG tabulce; a porovnání podpisu vyjmutého z dekódovaného datového bloku s podpisem vytvořeným v přijímači/dekodéru pro přijatá data.
23. 23. Způsob podle nároku 21 nebo 22, vyznačuj ící 15 se t í m , že uvedená chráněná oblast paměti má alespoň dvě takováto uložená posunutí, přičemž, pokud v kroku porovnání si vyjmutý podpis a vytvořený podpis vzájemně neodpovídají, zahrnuje způsob dále kroky opakování kroků vyhledání, vyjmutí a porovnání s použitím dalšího z uložených posunutí.
24. 24. Způsob podle kteréhokoliv z nároků 21 až

    23, vyznačující se tím, že alespoň nějaká z uvedených dalších dat v bloku dat jsou fiktivní nebo . 25 libovolná data.
25. 25. Způsob podle kteréhokoliv z nároků 11 až

    24, vyznačující se tím, že data jsou stahována jako množství modulů dat, přičemž způsob dále zahrnuje kroky vytváření modulového podpisu pro každý modul dat, určený ke ·· · ··9 9 • · ·· • * * · • · · 9 t 9 · * «99 · 9 * stažení;

    formátování modulů dat jako příslušných modulových MPEG tabulek;

    vytváření adresáře včetně identifikace každé modulové MPEG tabulky a příslušného podpisu, přičemž tento adresář je subjektem kroku vytváření podpisu podle kteréhokoliv z nároků 11 až 24; a v přijímači/dekodéru:vytváření příslušného modulového podpisu pro každý z modulů v přijatých modulových MPEG tabulkách; a porovnání každého modulového podpisu v přijaté adresářové MPEG tabulce s příslušným modulovým podpisem vytvořeným v přijímači/dekodéru.
26. 26. Způsob zavádění množství modulů dat do MPEG přijímače/dekodéru, vyznačující se tím, že zahrnuje kroky:vytváření modulového podpisu pro každý modul dat určených ke stažení;

    formátování modulů dat jako příslušných modulových MPEG tabulek;

    vytváření adresáře včetně identifikace každé modulové MPEG tabulky a příslušného podpisu;

    vytváření adresářového podpisu pro adresář;

    kódování adresářového podpisu s použitím privátního klíče;

    formátování adresáře a kódovaného adresářového podpisu jako adresářové MPEG tabulky;

    vysílání adresářové a modulových MPEG tabulek; a v přijímači/dekodéru;přijímání adresářové a modulových MPEG tabulek; dekódování kódovaného adresářového podpisu v přijaté » fefe fefe · · • · · adresářové MPEG tabulce s použitím veřejného klíče odpovídajícího privátnímu klíči;

    vytvoření adresářového podpisu pro adresář v přijaté adresářové MPEG tabulce;

    porovnání dekódovaného adresářového podpisu a adresářového podpisu vytvořeného v přijímači/dekodéru; vytvoření příslušného modulového podpisu pro každý z modulů v přijatých modulových MPEG tabulkách; a porovnání každého modulového podpisu v přijaté adresářové MPEG tabulce s příslušným modulovým podpisem vytvořeným v přijímači/dekodéru.
27. 27. Způsob podle nároku 25 nebo 26, vyznačuj ící se t í m , že dále zahrnuje krok zabránění nebo přerušení stahování takového modulu dat, pokud v kroku porovnání modulových podpisů si modulový podpis v přijaté adresářové MPEG tabulce a příslušný modulový podpis vytvořený v přijímači dekodéru pro tento modul vzájemně neodpovídají.
28. 28. Způsob podle kteréhokoliv z nároků 11 až

    27, vyznačující se tím, že zahrnuje krok zabránění nebo přerušení stahování dat, pokud si v kroku (krocích) porovnání jeden nebo každý dekódovaný podpis a vytvořený podpis vzájemně neodpovídají.
29. 29. MPEG přijímač/dekodér pro použití při realizaci způsobu podle nároku 11, vyznačující se tím, že zahrnuj e:

    prostředek pro přijímání MPEG tabulek;

    prostředek pro ukládání množství veřejných klíčů a identifikace pro každý z veřejných klíčů; a zpracovatelský prostředek, který je naprogramován pro zvolení • AA • v • ·

    A

    A * · A A A

    A AAA · A A jednoho z uložených veřejných klíčů podle identifikace klíče v přijaté MPEG tabulce; pro dekódování kódovaného podpisu v přijaté MPEG tabulce s použitím zvoleného veřejného klíče pro vytvoření dekódovaného podpisu; pro vytvoření podpisu pro

    5 data v přijaté MPEG tabulce; a pro porovnání dekódovaného podpisu a podpisu vytvořeného v přijímači/dekodéru pro přijatá data.
30. 30. Přijímač/dekodér podle nároku 29, vyznačuj ící se t i m , že paměťový prostředek pro uložení klíčů je zajištěn prostřednictvím ROM.
31. 31. Přijímač/dekodér podle nároku 29 nebo

    30, vyznačující se tím, že identifikace pro každý z veřejných klíčů je zajištěna prostřednictvím

    5 paměťového místa tohoto veřejného klíče v paměťovém prostředku pro uložení klíčů.
32. 32. Přijímač/dekodér podle kteréhokoliv z nároků 29 až 31 pro použití ve způsobu podle nároku 14, vyznačující se t í m , že dále zahrnuje oblast energeticky závislé

    3 paměti, přičemž zpracovatelský prostředek je uspořádán pro stahování aplikace mající podpis kódovaný s použitím privátního klíče majícího předem stanovenou identifikaci klíče, pro spuštění této aplikace pro řízení přijímače/dekodéru pro přijetí dalšího klíče, a pro řízení

    3 uložení tohoto dalšího klíče do oblasti energeticky závislé paměti.
33. 33. Přijímač/dekodér podle nároku 32, vyznačuj ící se t í m , že dále zahrnuje prostředek pro přijetí takového dalšího klíče, který je předáván lokálně do přij ímače/dekodéru.

    • 4 44 * 4 • 44 4444

    4 4 4 •a· ···

    4 4

    44 44
34. 34. Přijímač/dekodér podie nároku 33, vyznačuj ící se t í m , že prostředkem pro přijetí dalšího klíče je paralelní port, sériový port a/nebo čtecí zařízení pro čtení inteligentních karet v přijímači/dekodéru.
35. 35. Přijímač/dekodér podle kteréhokoliv z nároků 32 až 34,vyznačující se tím, že energeticky závislá paměť je zajištěna prostřednictvím RAM.
36. 36. Přijímač/dekodér podle kteréhokoliv z nároků 29 až 35 ]_q pro použití ve způsobu podle nároku 15, vyznačuj ící se t í m , že dále zahrnuje chráněnou oblast paměti pro uložení příznaku platnosti pro každý z alespoň nějakých veřejných klíčů, přičemž zpracovatelský prostředek je naprogramován pro vyhledání v této chráněné oblasti paměti

    25 příznaku platnosti pro zvolený veřejný klíč, a pro zabránění nebo přerušení stahování dat, pokud tento vyhledaný příznak platnosti není nastaven.
37. 37. Přijímač/dekodér podle nároku 36 závislého na kterémkoliv z nároků 32 až 35, vyznačující se t í m , že dále zahrnuje chráněnou oblast paměti pro uložení příznaku platnosti pro privátní klíč mající předem stanovenou identifikaci klíče, přičemž zpracovatelský prostředek je uspořádán při spuštění uvedené aplikace pro změnu tohoto příznaku platnosti a je uspořádán pro umožnění takovéhoto uložení dalšího klíče v závislosti na stavu tohoto příznaku platnosti.
38. 38. MPEG přijímač/dekodér pro použití při realizaci části způsobu podle nároku 17, vyznačující se

    30 t í m , že zahrnuje:

    prostředek pro přijímání MPEG tabulek;

    • · ·· 9 9 ····« · ·· ··♦· · · · · ·· ·· ··· «··· ·· «· prostředek pro ukládání veřejného klíče a identifikace pro tento veřejný klíč; a chráněnou oblast paměti pro uložení příznaku platnosti pro veřejný klíč; a zpracovatelský prostředek, který je naprogramován pro vyhledání v této chráněné oblasti paměti přijímače/dekodéru příznaku platnosti pro veřejný klíč odpovídající privátnímu klíči identifikovanému v přijaté MPEG tabulce; a, pokud je vyhledaný příznak platnosti nastaven, pro dekódování kódovaného podpisu v přijaté MPEG tabulce s použitím veřejného klíče odpovídajícího privátnímu klíči identifikovanému v přijaté MPEG tabulce pro vytvoření dekódovaného podpisu; pro vytvoření podpisu pro data v přijaté MPEG tabulce; a pro porovnání dekódovaného podpisu a podpisu vytvořeného v přijímači/dekodéru pro přijatá data.
39. 39. Přijímač/dekodér podle kteréhokoliv z nároků 36 až

    38, vyznačující se tím, že paměť pro uložení příznaku (příznaků) platnosti pro klíče je zajištěna prostřednictvím přepisovatelné paměti nezávislé na zdroji energie.
40. 40. Přijímač/dekodér podle kteréhokoliv z nároků 36 až

    39, vyznačující se tím, že v případě, ve kterém je uloženo množství takových veřejných klíčů, je paměť pro uložení příznaku (příznaků) platnosti uspořádána jako bitová mapa.
41. 41. Přijímač/dekodér kteréhokoliv z nároků 29 až 40 pro použití ve způsobu podle nároku 17, vyznačuj ící se t í m , že dále zahrnuje chráněnou oblast paměti pro uložení ověřovacího kódu, přičemž zpracovatelský prostředek • ft· • · · **· ···· ·· ftft ft •ftft ··· je naprogramován pro dekódování ověřovacího kódu v přijaté MPEG tabulce, pro vyhledání uloženého ověřovacího kódu, a pro porovnání vyhledaného ověřovacího kódu a dekódovaného ověřovacího kódu.
42. 42. MPEG přijímač/dekodér pro použití při realizaci části * způsobu podle nároku 17, vyznačující se tím, že zahrnuje:

    prostředek pro přijímání MPEG tabulek;

    prostředek pro ukládání veřejného klíče a identifikace pro tento veřejný klíč;

    chráněnou oblast paměti pro uložení ověřovacího kódu; a zpracovatelský prostředek, který je naprogramován pro dekódování kódovaného ověřovacího kódu a podpisu v přijatých

    MPEG tabulkách s použitím uloženého veřejného klíče 15 odpovídajícího privátnímu klíči; pro vyhledání uloženého ověřovacího kódu v chráněné oblasti paměti; pro porovnání vyhledaného ověřovacího kódu a dekódovaného ověřovacího kódu; pro vytvoření podpisu pro data v přijaté MPEG tabulce nebo jejich část; a pro porovnání dekódovaného podpisu s podpisem ²⁰ vytvořeným v přijímači/dekodéru pro přijatá data.
43. 43. Příjímač/dekodér podle nároku 41 nebo

    42, vyznačující se tím, že zpracovatelský prostředek je naprogramován pro zabránění nebo přerušení stahování dat, pokud si vyhledaný ověřovací kód a dekódovaný ověřovací kód vzájemně neodpovídají.
44. 44. Přijímač/dekodér podle kteréhokoliv z nároků 41 až

    43, vyznačující se tím, že paměť pro uložení ověřovacích kódů je zajištěna prostřednictvím přepisovatelné paměti nezávislé na zdroji energie.

    Φ »

    Φ «

    Φ ·

    Φ

    ΦΦΦ φφφφ

    4 ·· Φ ΦΦΦ

    Φ ·

    Φ· ΦΦ
45. 45. Přijímač/dekodér podle kteréhokoliv z nároků 41 až 43, vyznačujíc! se t í m , že paměť pro uložení ověřovacích kódů je uspořádána jako bitová mapa.
46. 46. Přijímač/dekodér podle kteréhokoliv z nároků 29 až 45 pro použití ve způsobu podle nároku 21, vyznačuj ící se t í m , že dále zahrnuje chráněnou oblast paměti pro uložení alespoň jednoho posunutí, přičemž zpracovatelský prostředek je naprogramován pro dekódování kódovaného datového bloku v přijaté MPEG tabulce, pro vyhledání uvedeného jednoho uloženého posunutí v chráněné oblasti pamětí, a pro vyjmutí podpisu z dekódovaného datového bloku s použitím vyhledaného posunutí od začátku dekódovaného datového bloku.
47. 47. MPEG přijímač/dekodér pro použití při realizací způsobu podle nároku 22, vyznačující se tím, že zahrnuj e:

    prostředek pro přijímání MPEG tabulek;

    prostředek pro uložení veřejného klíče a identifikace pro tento veřejný klíč;

    chráněnou oblast paměti pro uložení alespoň jednoho posunutí; a zpracovatelský prostředek, který je naprogramován pro dekódování kódovaného datového bloku v přijaté MPEG tabulce s použitím uloženého veřejného klíče odpovídajícího privátnímu klíčí; pro vyhledání uvedeného jednoho uloženého posunutí v chráněné oblasti paměti; pro vyjmutí podpisu z dekódovaného datového bloku s použitím vyhledaného posunuti od začátku dekódovaného datového bloku; pro vytvoření podpisu pro data v přijaté MPEG tabulce; a pro porovnání podpisu vyjmutého z • * · ··«*« • φ φ · · ·· ·· φφφ φ»·· φφ φφ dekódovaného datového bloku s podpisem vytvořeným v přijímači/dekodéru pro přijatá data.
48. 48. Přijímač/dekodér podle nároku 46 nebo

    47, vyznačující se tím, že alespoň dvě

    5 , ...

    takováto posunuti jsou uložena v chráněně oblasti paměti, * přičemž zpracovatelský prostředek je uspořádán, pokud si vyjmutý podpis a vytvořený podpis vzájemně neodpovídají, pro * opakování vyhledání, vyjmutí a porovnání s použitím dalšího z uložených posunutí.
49. 49. Přijímač/dekodér podle kteréhokoliv z nároků 46 až

    48, vyznačující se tím, že paměť pro uložení posunutí je zajištěna prostřednictvím přepisovatelné pamětí nezávislé na zdroji energie.

    Ί 5
50. 50. Přijímači/dekodér podle kteréhokoliv z nároků 29 až 49 pro použití ve způsobu podle nároku 25, vyznačuj ící se t í m , že zpracovatelský prostředek je naprogramován pro vytvoření příslušného modulového podpisu pro každý z modulů v přijatých MPEG tabulkách, a pro porovnání každého modulového podpisu v přijaté adresářové MPEG tabulce s příslušným modulovým podpisem vytvořeným v přij ímači/dekodéru.

    i
51. 51. MPEG přijímač/dekodér pro použití při realizaci způsobu . podle nároku 26, vyznačující se tím, že zahrnuje:

    prostředek pro přijímání adresářové a modulových MPEG tabulek;

    prostředek pro uložení veřejného klíče a identifikace pro 30 tento veřejný klíč; a zpracovatelský prostředek, který je naprogramován pro

    444 *444

    44* **· • 4

    44 ·· dekódování kódovaného adresářového podpisu v přijaté adresářové MPEG tabulce s použitím uloženého veřejného klíče odpovídajícího privátnímu klíči; pro vytvoření adresářového podpisu pro adresář v přijaté adresářové MPEG tabulce; pro porovnání dekódovaného adresářového podpisu a adresářového podpisu vytvořeného v přijímači/dekodéru; pro vytvoření příslušného modulového podpisu pro každý z modulů v přijatých modulových MPEG tabulkách; a pro porovnání každého modulového podpisu v přijaté adresářové tabulce s příslušným modulovým podpisem vytvořeným v přijímači/dekodéru.
52. 52. Přijímač/dekodér podle nároku 50 nebo

    51, vyznačující se tím, že zpracovatelský prostředek je naprogramován pro zabránění nebo přerušení stahování modulu dat, pokud si modulový podpis v přijaté adresářové MPEG tabulce a příslušný modulový podpis vytvořený v přijímači/dekodéru pro tento modul vzájemně neodpovídají.
53. 53. Přijímači/dekodér podle kteréhokoliv z nároků 29 až

    52, vyznačující se tím, že zpracovatelský prostředek je naprogramován pro zabránění nebo přerušení stahování dat, pokud si jeden nebo každý dekódovaný podpis a vytvořený podpis vzájemně neodpovídají.
54. 54. Způsob zavádění alespoň části aplikace do MPEG příjímače/dekodéru v podstatě podle zde uvedeného popisu ve spojení s odkazy na připojené výkresy.
55. 55. MPEG přijímač/dekodér v podstatě podle zde uvedeného popisu ve spojení s odkazy na připojené výkresy.
56. 56. MPEG vysílací systém v podstatě podle zde uvedeného popisu ve spojení s odkazy na připojené výkresy.