デジタル放送システム用のコピープロテクトアプリケーション
コピープロテクトアプリケーションは、Multimedia Home Platform（MHP）のようなデジタル放送システムで端末（60）に放送される。アプリケーションは、ランチャー・アプリケーション（310）とメインアプリケーション（320）とを有する。ランチャー・アプリケーション（310）は、端末（60）でHTTPサーバ（315）のようなサーバを端末に生成させる。DVBClassLoader（316）のようなアプリケーション・ローダは、サーバ（315）を介して端末にメインアプリケーションをロードする。メインアプリケーションは、サーバ（315）を通過するときに解読される暗号化アプリケーションでもよい。ランチャー・アプリケーション（310）は、解読での処理の前に、外部関係者から許可を取得する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、デジタル放送システムに関し、特にそのようなシステムでの端末へのアプリケーションの配信に関する。
【背景技術】
【０００２】
Digital Video Broadcasting（DVB）システムは、もともとオーディオ及びビデオ資料を配信するために開発された。近年、端末によりダウンロード及び実行可能なアプリケーションを配信することに更なる関心が生じてきている。Digital Video Broadcasting Multimedia Home Platform（DVB-MHP）は、マルチメディア・セットトップボックス用の標準を一致させる取り組みの結果である。それは、インタラクティブ・デジタル・テレビ用のオープンで公開された標準である。DVB-MHP又は簡単にはMHPは、インタラクティブ・デジタル・アプリケーションと、これらのアプリケーションを実行する端末との間の一般的なインタフェースを規定する。ETSI TS 101 812 V1.3.1のようなMHP標準は、www.etsi.orgで見ることができる。MHP標準の1.0.3版は、‘Xlets’と呼ばれる自由にダウンロード可能なアプリケーションをサポートしている。ETSI TS 102 819で提出されたDigital Video Broadcasting Globally Executable MHP（DVB-GEM）もまた、ダウンロード可能なアプリケーションをサポートしている。
【０００３】
いくつかの放送局は、サービスに加入している人に対してのみ放送チャンネル又はアプリケーションのようなコンテンツへのアクセスを制限するために、限定受信（CA：conditional access）システムを使用して全放送ストリームを暗号化するように選択している。これは、コンテンツの侵害行為に対して高度のプロテクトを提供することが証明されているが、ユーザのセットトップボックスで専用のスクランブル解除ハードウェアを必要とする。視聴者は、CAシステムを有する特別のセットトップボックスを必要とし、又はDVB Common Interface（DVB-CI）に準拠するスロットを備えたセットトップボックスとCAシステムを含むCIモジュールとを必要とする。視聴者はまた、それを特定するスマートカードを必要とし、放送局は、許可されたスマートカードの中央データベースを保持する必要がある。多数の放送局は、CAシステムについて独自にあつらえた暗号化アルゴリズムを使用する。現実的には、月額受信料を請求する放送局のみが、CAシステムに必要なインフラを設定することができる。前記のことを考慮して、多数の放送局は、このように全トランスポートストリームを暗号化しないことを選択している。
【０００４】
ユーザ端末にゲームのような利用回数制料金を供給することに関心が存在する。その理由は、放送局に更なる収益をもたらし得るからである。しかし、現在のMHP標準は、暗号化アプリケーションのサポートを含んでいない。アプリケーションを暗号化する機能がなければ、ユーザ端末に配信される如何なるアプリケーションも侵害行為を受けやすくなる。実際に、何らかのアプリケーション用のコードを含み、放送システムの一部として放送されたファイルシステムの全コンテンツを‘横取り’して、これをハードディスクに保存することができる装置を入手することが既に可能になっている。
【０００５】
MHPはJavaTM Virtual Machineに主に基づいており、アプリケーションはJava（登録商標）で記述され、Java（登録商標）バイトコードにコンパイルされる。放送ストリームで送信されるJavaTMクラスファイルを暗号化することが望ましい。Javaクラスファイルを暗号化する方法は、文献“How do I store a Java App in a Self-Executing Encrypted File?”、Dave Angel及びAndy Wilson、Dobb’s Journal、February 1999と、http://www.webtechniques.com/archives/2001/08/travis/にあるGreg Travisによる“Encrypted Class Files”とに記載されている。公開されている方法の主要な要件はJava（登録商標）の‘ClassLoader’の使用である。しかし、MHP標準の全ての現行版は、特に通常のClassLoader又はClassLoaderクラスの何らかのサブクラス（すなわち修正版）の生成を禁じている。従って、これらの文献により教示された方法で、クラスを解読するカスタムClassLoaderを生成することは不可能である。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
本発明は、暗号化アプリケーションを端末に配信する方法を提供することを目的とする。
【課題を解決するための手段】
【０００７】
従って、本発明の第１の態様は、デジタル放送システムにおいて端末でアプリケーションをダウンロードする方法を提供し、
ランチャー・アプリケーションを受信するステップと、
ランチャー・アプリケーションを開始するステップと、
端末でサーバを生成するステップと、
サーバを介して端末にメインアプリケーションをロードするアプリケーション・ローダを生成するステップと
を有する。
【０００８】
メインアプリケーションは、暗号化アプリケーションであり、ランチャー・アプリケーションは、サーバを介してダウンロードされたときにメインアプリケーションを解読するように構成されることが好ましい。
【０００９】
端末でのサーバの生成により、解読済アプリケーションが端末に安全に格納され、ハッカーへの発覚を最小化することが可能になる。端末で新しく生成されたサーバはポートを備えており、ポートのアドレスはアプリケーション・ローダに提供される。一般的に、アドレスはlocalhost又は127.0.0.1である。
【００１０】
端末がMHP端末である場合、ユニフォーム・リソース・ロケータ（URL：uniform resource locator）からクラスをロードすることになる‘DVBClassLoader’の形式のアプリケーション・ローダが使用可能になる。サーバはURLを割り当てられており、URLはDVBClassLoader関数に供給される。
【００１１】
ランチャー・アプリケーション及びメインアプリケーションは一緒に（すなわち、連続して、直後に相次いで）受信されてもよく、異なる時に受信されてもよい点に留意すべきである。また、ランチャー・アプリケーション及びメインアプリケーションは、同じ配信チャンネルを介して送信されてもよく、異なる配信チャンネルを介して送信されてもよい。一例として、ランチャー・アプリケーション及びメインアプリケーションは、双方ともに放送チャンネルを介して受信されてもよい。他の例では、ランチャー・アプリケーションは放送チャンネルを介して受信され、メインアプリケーションはインターネットの配信チャンネルを介して受信される。
【００１２】
サーバは、端末内で生じた接続要求にのみ応答し、アプリケーションを安全に保持することを確保することが好ましい。
【００１３】
その方法は、メインアプリケーションを解読する前に、外部関係者にコンタクトして許可を取得することを更に有することが好ましい。解読鍵は、ユーザが認証されたことに応じて、外部関係者から受信されることが好ましい。しかし、簡単な変更で、解読鍵はランチャー・アプリケーションに備えられてもよい。
【００１４】
端末はセットトップボックス（STB）の形式になる可能性が高いが、セットトップボックスの機能を組み込んだマルチメディアパーソナルコンピュータ（PC）又はテレビセットのような他の形式になってもよい。
【００１５】
本発明は、Multimedia Home Platform（MHP）の現バージョンへの拡張として特に適用可能であるが、デジタルビデオ放送システムへの広範囲の適用を有する。それには次のものが含まれる。
・DVB-GEM（TS 102 819）=Globally Executable MHP、これはDVB-SIに依存しないMHPのサブセットである。
・OCAP=OpenCable Application Platform、GEMに基づく新しい米国ケーブル標準
・ATSC-DASE=Advanced Television Systems Committee（ATSC） Digital TV Applications Software Environment（DASE）、GEMに基づいて現在書き換えられている米国地上波標準
・ARIB-AE=ARIB（日本のTV標準機関）、GEMに基づく標準B-23“Application Execution Engine Platform for Digital Broadcasting”（ARIB-AE）
本発明の更なる態様は、デジタル放送システムにおける端末への送信用のアプリケーションを生成する方法、そのようなアプリケーションを生成するオーサリング・ソフトウェア、デジタル放送システムにおいて端末にアプリケーションを送信する方法、デジタル放送システムにおける端末への送信用のアプリケーションのためのソフトウェア、及びデジタル放送システムでの送信用の信号を提供する。
【発明を実施するための最良の形態】
【００１６】
本発明の実施例について、添付図面を参照して、一例のみとして説明する。
【００１７】
図１は、端末にアプリケーションを配信する全体的なデジタルビデオ放送システムを示している。コンテンツは放送局30により生成され、放送チャンネル35を介してユーザ施設100に送信するために適切なフォーマットに変換される。１つのこのような施設100が図示されている。一般的に、放送チャンネル35は、衛星を介して配信されるが、地上波伝送ネットワーク、ケーブル配信ネットワーク又はデータネットワーク（インターネット等）により配信されてもよく、配信方法は本発明に重要ではない。ユーザ施設の端末（STB）60は、放送ストリームを受信し、この例では、その放送ストリームはアンテナ18を介したものである。放送チャンネル35を介して配信される放送ストリームは、オーディオ及びデータコンテンツと、様々なサービス及びアプリケーションをサポートするデータとを有する。DVB-MHP仕様では、アプリケーション用のデータは、Digital Storage Media-Command and Control（DSM-CC） Object Carouselの一部として放送される。これは、様々なアプリケーション用のデータファイルを含む繰返し放送ファイルシステムである。DSM-CCを含むDVB-MHPシステム用の放送チャンネルのフォーマットは、ISO/ISC13818-6に設定されており、更なる情報については、当業者に対してそのISO/ISC13818-6に示されている。
【００１８】
アプリケーションは、放送局30により生成されてもよく、また、DSM-CCへの挿入用に放送局30に所要のファイルを供給する独立アプリケーションプロバイダ50により生成されてもよい。アプリケーションの例は、電子番組ガイド（EPG）、ゲーム、クイズ、教育案内及び電子商取引アプリケーション（ホームバンキング等）を含む。
【００１９】
セットトップボックス60はまた、セットトップボックス60が外部関係者にデータを送信し、外部関係者からデータを受信することを可能にするための帰路（又はインタラクション）チャンネル85をサポートするモデムを備えている。一般的に、インタラクション・チャンネルは、POTSのような従来の電話ネットワークを使用する。インタラクション・チャンネル85は、アプリケーションプロバイダ50への直接のダイヤルアップ（POTS）接続、データネットワークを通じて運ばれるアプリケーションプロバイダ50とゲートウェイとの間の接続を備えたデータネットワーク（インターネット等）のゲートウェイへの接続、ケーブル・バックチャンネルとアプリケーションプロバイダへのデータネットワーク（インターネット）を通じた接続との組み合わせ、ADSL又は他のブロードバンドインターネット接続、衛星アップリンク又はISDN回線の形式になってもよい。
【００２０】
セットトップボックス60はまた、ユーザ入力を受け取るリモコン20又はキーボードとのユーザインタフェースと、テレビディスプレイ12に供給されるビデオ信号10に重ねられ得るグラフィック出力とを有する。
【００２１】
MHP端末はJavaTM Virtual Machine（JVM）を中心に構築され、アプリケーションはJava（登録商標）で記述される。Java（登録商標）の使用は、各種の端末で仮想機械が、その端末に存在する特定のハードウェア及びソフトウェアに互換のある形式にJava（登録商標）バイトコードを変換することで、アプリケーションが共通のフォーマットで記述され得るという利点を有する。
【００２２】
図２は、一般的なMHP端末60内の機能ブロックを示している。既知のように、端末60は、受信放送信号35を処理するフロントエンドを有する。これは、所要のチャンネルを選択及び復調するチューナ61及び復調器と、信号を解読する任意選択の限定受信ユニット62とを有する。結果のデジタルデータストリームは、オーディオ及びビデオデータを表すデータストリーム（一般的にMPEG-2フォーマット）と、繰返し放送のDSM-CC Object Carousel64の形式のアプリケーション用のデータとに逆多重化される63。オーディオ及びビデオデータは、ユーザへの提示用に、適切な出力信号12、14を得るように更に処理され得る65。放送ストリームからダウンロードされると、アプリケーション（又は複数のアプリケーション）は、端末のメモリ69に存在し、端末のマイクロプロセッサ68により実行される。アプリケーションは、ユーザ入力22を受け取り、オーディオ及びビデオ出力を生成し、インタラクション・チャンネル85にアクセスしてもよい。マイクロプロセッサ68を動作する制御ソフトウェアもまた、メモリ装置に存在する。図２は、放送配信チャンネルを介して信号を受信することを目的とした端末を示している点に留意すべきである。端末の他の実施例では、非放送配信チャンネルとインタフェースすることを目的としており、チューナ／復調器61は、配信チャンネルに適したネットワークインタフェースと交換される。これは、インターネットプロトコル（IP）ベースの配信チャンネルでもよい。
【００２３】
図３及び４は、放送ストリームから暗号化アプリケーションをダウンロードする処理を示している。図３は、送信されるアプリケーションの構成要素を示しており、図４は、アプリケーションをダウンロードして作動するために端末60により実行される処理のフローチャートを示している。ステップ400において、ユーザはアプリケーション“X”がダウンロードされることを要求する。その要求は、ユーザがスクリーン上のメニューをナビゲーションしてリモコン20のキーを押すこと等により、従来の方法で行われてもよい。要求されたアプリケーションは２つの部分（併せてブロック300として図示する）で放送される。
−暗号化されていないフォーマットで放送される‘ランチャー’又は‘ローダ’Xlet310
−暗号化されたフォーマットで放送されるメインアプリケーション320
メインアプリケーション320はクラス321及びデータ322を有し、その双方が暗号化されている。
【００２４】
暗号化メインアプリケーションは、DSM-CC Data Carousel、DSM-CC MPE（IPマルチキャスト・カプセル化）、Data Piping又はインターネットを介して送信されてもよい。
【００２５】
ランチャー・アプリケーション310及び暗号化メインアプリケーション320は、一緒に送信されてもよく、別々に送信されてもよい。別々に送信される場合には、双方ともDSM-CCのような同じトランスポートストリームを介して送信されてもよく、異なるトランスポートストリームを介して送信されてもよい（一方は放送で、他方はインターネットを介して送信される）。このように、本発明を使用して、インターネットで暗号化クラスを送信し、それを端末で解読することが可能になる。
【００２６】
ステップ402において、端末は、放送ストリームでオブジェクト・カルーセル64からアプリケーションXに必要なファイルを取り出す。次に、ランチャー・アプリケーション310が開始される。ランチャー・アプリケーション310は、インタラクション・チャンネル85でアプリケーションプロバイダ50にコンタクトし、許可要求314を送信する。アプリケーションプロバイダ50にコンタクトする目的は、ユーザがアプリケーションを作動することを許可されていることを確保するためである。このステップは、アプリケーションの使用を許可する前に、ユーザから支払を収集することを有してもよい。ユーザが許可されると、インタラクション・チャンネル85でアプリケーションプロバイダ50から解読鍵313を受信する。ユーザが許可されない場合、ステップ406において、メッセージは端末60に返信され、このことを通知するメッセージがユーザに対して表示される。更に何も生じず、メインアプリケーション320は解読されない。許可が実現できる様々な方法が存在する。許可を取得するいくつかの可能な方法には次のようなものがある。
【００２７】
ランチャー・アプリケーション310はクレジットカードの詳細についてユーザに促す。クレジットカードの詳細を受信すると317、ランチャー・アプリケーション310はアプリケーションプロバイダ50の支払許可エンティティ55にコンタクトし、クレジットカードの詳細を渡す。支払が受け入れられると、解読鍵313は、インタラクション・チャンネル85でアプリケーションプロバイダ50から端末60に返信される。
【００２８】
ランチャー・アプリケーション310は、アプリケーションプロバイダ50により運営されているプレミアムレートの電話番号にダイヤルする。端末60のユーザにより負担された電話呼出のコストがアプリケーションの価格に等しくなるまで、電話が維持される。この時点で、アプリケーションプロバイダ50は解読鍵313をランチャー・アプリケーション310に送信し、電話が終了する。
【００２９】
ランチャー・アプリケーション310は加入又はクラブ会員番号について、場合によってはパスワード又はPINと共にユーザに促す。ランチャー・アプリケーションはアプリケーションプロバイダ50にコンタクトし314、この情報を提供する。ユーザが許可されると、解読鍵313はアプリケーションプロバイダ50から端末60に送信される。
【００３０】
ランチャー・アプリケーション310は、端末60のカードリーダに挿入されたスマートカード（例えばGerman GeldKarte）から支払を行い、解読鍵を取得するためにアプリケーションプロバイダ50にコンタクトする。
【００３１】
好ましくは何らかの方法でアプリケーションプロバイダ50に支払った後で、ランチャー・アプリケーション310が解読鍵313を取得するためにアプリケーションプロバイダ50にコンタクトする場合に、その他の手段が使用されてもよいことがわかる。
【００３２】
再び図４を参照すると、ステップ408において、ランチャー・アプリケーション310はMHPアプリケーション320を解読して作動する必要がある。ClassLoaderを生成することに対する制約を克服するために、ランチャー・アプリケーション310は端末60で小型HTTPサーバ315を生成するコードを有する。許可が受信されると、ランチャー・アプリケーション310はこのHTTPサーバ315を開始する。HTTPサーバ315は、指定のポートでjava.net.ServerSocketクラスを生成する。次に、ランチャー・アプリケーション310はDVBClassLoader316を生成する。DVBClassLoaderはMHP標準の一部であり、URLからの（例えばHTTPサーバからの）クラスのみをロードすることができる。ランチャー・アプリケーション310は、まさに生成されたHTTPサーバ315のURLをDVBClassLoader316に渡す。DVBClassLoaderがこのポートに接続すると、ソケット（java.net.Socket）接続が生成される。この接続は双方向接続で使用可能である。次に、ランチャー・アプリケーション310はDVBClassLoader316内のメインアプリケーション330を開始し得る。メインアプリケーション及びそれが必要とする何らかのデータを解読することは、如何なる標準的な解読アルゴリズムで行われてもよい。これらの例には、Data Encryption Standard（DES）、Triple Data Encryption Standard（3DES）及びAdvanced Encryption Standard（AES）が含まれる。解読アルゴリズムは、アプリケーションと共に放送されることを必要としてもよい。解読の好ましい方法は、オンデマンドの解読である。すなわち、アプリケーションがクラスをロードする必要があるときに、そのクラスのデータについて要求がDVBClassLoaderからHTTPサーバに送信される。暗号化クラスファイルはDSM-CCからダウンロードされ、解読され、それらが抽出されたHTTPサーバ315に渡される。このことはメモリ使用量を減少させる。その理由は、解読済のクラスファイルは短期間しかメモリに存在せず、如何なる時点においても少数の要求のみが処理される可能性があるからである。
【００３３】
セキュリティのため、HTTPサーバ315は、MHP端末内から生じていない如何なる接続をも拒否する。理想的には、HTTPサーバ315は、‘localhost’のIPアドレスでのみ受信すべきであり、通常のTCP/IP動作は外部接続をブロックする。これは、解読済のクラスがMHP端末60を離れないということを意味する。TCP/IPをサポートする装置は、複数のネットワークインタフェースを有してもよい。一般的に、各ネットワークインタフェースは、単一の物理ネットワーク接続に対応する。しかし、全てのTCP/IP装置は‘ループバック’インタフェースと呼ばれる特別の仮想ネットワークインタフェースを有する。これは装置内からのみアクセス可能であり、リモートからそれにアクセスすることはできない。TCP/IPサーバソケットが生成されると、全てのネットワークインタフェースからアクセス可能になることがデフォルトである。しかし、それを単一のネットワークインタフェースに制限又は‘束縛’することが可能である。従って、サーバが（IPアドレス127.0.0.1で）ループバックインタフェースに結び付けられている場合、STBの外部からはアクセスすることができない。HTTPサーバは、暗号化アプリケーションの有効期間に存在する。
【００３４】
更なるセキュリティのため、ランチャー・アプリケーション310とメインアプリケーション320との双方のコードは、リバース・エンジニアリングされることを困難にするようにあいまいになっている。これは、記述ラベルが小さい記述ラベルに除去又は名称変更されるようにコードが処理されることを意味する。従って、ハッカーがアプリケーションをうまく解読したとしても、アプリケーションの動作を変更することを困難にすることがわかる。短い記述的でないラベルの使用もまた、コードのサイズを低減することに役立つ。
【００３５】
アプリケーション320により使用されるデータは、同じ鍵313を使用して解読されるが、HTTPサーバ315を通じて送信される必要はない。その代わりに、解読済のデータがメインアプリケーション330に直接渡される。
【００３６】
前述の説明では、メインアプリケーションにより使用される暗号化データ322は解読され、メインアプリケーション330に直接渡される。代替として、そのデータはHTTPサーバ315に渡されてもよい。
【００３７】
サーバ315はHTTPサーバである必要なく、FTPを含み、MHP端末によりサポートされる如何なるプロトコル用のサーバでもよい。
【００３８】
前記の実施例では、許可エンティティ55は、アプリケーションプロバイダ50の一部として図示されている。これは必ずしも必要ではない。許可エンティティ55は、アプリケーションプロバイダから物理的に離れて、アプリケーションプロバイダ50の代わりに許可機能を実行してもよい。
【００３９】
前記の実施例では、解読鍵313は、ユーザの支払又は適切な許可に応じて、アプリケーションプロバイダ50により提供される。しかし、この技術は、単にアプリケーションをリバース・エンジニアリングされにくくするために使用されてもよい。その場合、解読鍵313は、ランチャー・アプリケーション310の一部として提供されてもよい。クラスは依然としてHTTPサーバ315内で解読され、端末60の内部に残る。
【００４０】
本発明は、ここで説明した実施例に限定されず、本発明の範囲を逸脱することなく、変更又は変形されてもよい。
【図面の簡単な説明】
【００４１】
【図１】本発明を具現したデジタルビデオ放送（DVB）システム
【図２】図１のシステムで使用される加入者端末内の機能ブロック
【図３】本発明による暗号化アプリケーションの構成要素
【図４】暗号化アプリケーションを処理するフローチャート
【技術分野】
【０００１】
本発明は、デジタル放送システムに関し、特にそのようなシステムでの端末へのアプリケーションの配信に関する。
【背景技術】
【０００２】
Digital Video Broadcasting（DVB）システムは、もともとオーディオ及びビデオ資料を配信するために開発された。近年、端末によりダウンロード及び実行可能なアプリケーションを配信することに更なる関心が生じてきている。Digital Video Broadcasting Multimedia Home Platform（DVB-MHP）は、マルチメディア・セットトップボックス用の標準を一致させる取り組みの結果である。それは、インタラクティブ・デジタル・テレビ用のオープンで公開された標準である。DVB-MHP又は簡単にはMHPは、インタラクティブ・デジタル・アプリケーションと、これらのアプリケーションを実行する端末との間の一般的なインタフェースを規定する。ETSI TS 101 812 V1.3.1のようなMHP標準は、www.etsi.orgで見ることができる。MHP標準の1.0.3版は、‘Xlets’と呼ばれる自由にダウンロード可能なアプリケーションをサポートしている。ETSI TS 102 819で提出されたDigital Video Broadcasting Globally Executable MHP（DVB-GEM）もまた、ダウンロード可能なアプリケーションをサポートしている。
【０００３】
いくつかの放送局は、サービスに加入している人に対してのみ放送チャンネル又はアプリケーションのようなコンテンツへのアクセスを制限するために、限定受信（CA：conditional access）システムを使用して全放送ストリームを暗号化するように選択している。これは、コンテンツの侵害行為に対して高度のプロテクトを提供することが証明されているが、ユーザのセットトップボックスで専用のスクランブル解除ハードウェアを必要とする。視聴者は、CAシステムを有する特別のセットトップボックスを必要とし、又はDVB Common Interface（DVB-CI）に準拠するスロットを備えたセットトップボックスとCAシステムを含むCIモジュールとを必要とする。視聴者はまた、それを特定するスマートカードを必要とし、放送局は、許可されたスマートカードの中央データベースを保持する必要がある。多数の放送局は、CAシステムについて独自にあつらえた暗号化アルゴリズムを使用する。現実的には、月額受信料を請求する放送局のみが、CAシステムに必要なインフラを設定することができる。前記のことを考慮して、多数の放送局は、このように全トランスポートストリームを暗号化しないことを選択している。
【０００４】
ユーザ端末にゲームのような利用回数制料金を供給することに関心が存在する。その理由は、放送局に更なる収益をもたらし得るからである。しかし、現在のMHP標準は、暗号化アプリケーションのサポートを含んでいない。アプリケーションを暗号化する機能がなければ、ユーザ端末に配信される如何なるアプリケーションも侵害行為を受けやすくなる。実際に、何らかのアプリケーション用のコードを含み、放送システムの一部として放送されたファイルシステムの全コンテンツを‘横取り’して、これをハードディスクに保存することができる装置を入手することが既に可能になっている。
【０００５】
MHPはJavaTM Virtual Machineに主に基づいており、アプリケーションはJava（登録商標）で記述され、Java（登録商標）バイトコードにコンパイルされる。放送ストリームで送信されるJavaTMクラスファイルを暗号化することが望ましい。Javaクラスファイルを暗号化する方法は、文献“How do I store a Java App in a Self-Executing Encrypted File?”、Dave Angel及びAndy Wilson、Dobb’s Journal、February 1999と、http://www.webtechniques.com/archives/2001/08/travis/にあるGreg Travisによる“Encrypted Class Files”とに記載されている。公開されている方法の主要な要件はJava（登録商標）の‘ClassLoader’の使用である。しかし、MHP標準の全ての現行版は、特に通常のClassLoader又はClassLoaderクラスの何らかのサブクラス（すなわち修正版）の生成を禁じている。従って、これらの文献により教示された方法で、クラスを解読するカスタムClassLoaderを生成することは不可能である。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
本発明は、暗号化アプリケーションを端末に配信する方法を提供することを目的とする。
【課題を解決するための手段】
【０００７】
従って、本発明の第１の態様は、デジタル放送システムにおいて端末でアプリケーションをダウンロードする方法を提供し、
ランチャー・アプリケーションを受信するステップと、
ランチャー・アプリケーションを開始するステップと、
端末でサーバを生成するステップと、
サーバを介して端末にメインアプリケーションをロードするアプリケーション・ローダを生成するステップと
を有する。
【０００８】
メインアプリケーションは、暗号化アプリケーションであり、ランチャー・アプリケーションは、サーバを介してダウンロードされたときにメインアプリケーションを解読するように構成されることが好ましい。
【０００９】
端末でのサーバの生成により、解読済アプリケーションが端末に安全に格納され、ハッカーへの発覚を最小化することが可能になる。端末で新しく生成されたサーバはポートを備えており、ポートのアドレスはアプリケーション・ローダに提供される。一般的に、アドレスはlocalhost又は127.0.0.1である。
【００１０】
端末がMHP端末である場合、ユニフォーム・リソース・ロケータ（URL：uniform resource locator）からクラスをロードすることになる‘DVBClassLoader’の形式のアプリケーション・ローダが使用可能になる。サーバはURLを割り当てられており、URLはDVBClassLoader関数に供給される。
【００１１】
ランチャー・アプリケーション及びメインアプリケーションは一緒に（すなわち、連続して、直後に相次いで）受信されてもよく、異なる時に受信されてもよい点に留意すべきである。また、ランチャー・アプリケーション及びメインアプリケーションは、同じ配信チャンネルを介して送信されてもよく、異なる配信チャンネルを介して送信されてもよい。一例として、ランチャー・アプリケーション及びメインアプリケーションは、双方ともに放送チャンネルを介して受信されてもよい。他の例では、ランチャー・アプリケーションは放送チャンネルを介して受信され、メインアプリケーションはインターネットの配信チャンネルを介して受信される。
【００１２】
サーバは、端末内で生じた接続要求にのみ応答し、アプリケーションを安全に保持することを確保することが好ましい。
【００１３】
その方法は、メインアプリケーションを解読する前に、外部関係者にコンタクトして許可を取得することを更に有することが好ましい。解読鍵は、ユーザが認証されたことに応じて、外部関係者から受信されることが好ましい。しかし、簡単な変更で、解読鍵はランチャー・アプリケーションに備えられてもよい。
【００１４】
端末はセットトップボックス（STB）の形式になる可能性が高いが、セットトップボックスの機能を組み込んだマルチメディアパーソナルコンピュータ（PC）又はテレビセットのような他の形式になってもよい。
【００１５】
本発明は、Multimedia Home Platform（MHP）の現バージョンへの拡張として特に適用可能であるが、デジタルビデオ放送システムへの広範囲の適用を有する。それには次のものが含まれる。
・DVB-GEM（TS 102 819）=Globally Executable MHP、これはDVB-SIに依存しないMHPのサブセットである。
・OCAP=OpenCable Application Platform、GEMに基づく新しい米国ケーブル標準
・ATSC-DASE=Advanced Television Systems Committee（ATSC） Digital TV Applications Software Environment（DASE）、GEMに基づいて現在書き換えられている米国地上波標準
・ARIB-AE=ARIB（日本のTV標準機関）、GEMに基づく標準B-23“Application Execution Engine Platform for Digital Broadcasting”（ARIB-AE）
本発明の更なる態様は、デジタル放送システムにおける端末への送信用のアプリケーションを生成する方法、そのようなアプリケーションを生成するオーサリング・ソフトウェア、デジタル放送システムにおいて端末にアプリケーションを送信する方法、デジタル放送システムにおける端末への送信用のアプリケーションのためのソフトウェア、及びデジタル放送システムでの送信用の信号を提供する。
【発明を実施するための最良の形態】
【００１６】
本発明の実施例について、添付図面を参照して、一例のみとして説明する。
【００１７】
図１は、端末にアプリケーションを配信する全体的なデジタルビデオ放送システムを示している。コンテンツは放送局30により生成され、放送チャンネル35を介してユーザ施設100に送信するために適切なフォーマットに変換される。１つのこのような施設100が図示されている。一般的に、放送チャンネル35は、衛星を介して配信されるが、地上波伝送ネットワーク、ケーブル配信ネットワーク又はデータネットワーク（インターネット等）により配信されてもよく、配信方法は本発明に重要ではない。ユーザ施設の端末（STB）60は、放送ストリームを受信し、この例では、その放送ストリームはアンテナ18を介したものである。放送チャンネル35を介して配信される放送ストリームは、オーディオ及びデータコンテンツと、様々なサービス及びアプリケーションをサポートするデータとを有する。DVB-MHP仕様では、アプリケーション用のデータは、Digital Storage Media-Command and Control（DSM-CC） Object Carouselの一部として放送される。これは、様々なアプリケーション用のデータファイルを含む繰返し放送ファイルシステムである。DSM-CCを含むDVB-MHPシステム用の放送チャンネルのフォーマットは、ISO/ISC13818-6に設定されており、更なる情報については、当業者に対してそのISO/ISC13818-6に示されている。
【００１８】
アプリケーションは、放送局30により生成されてもよく、また、DSM-CCへの挿入用に放送局30に所要のファイルを供給する独立アプリケーションプロバイダ50により生成されてもよい。アプリケーションの例は、電子番組ガイド（EPG）、ゲーム、クイズ、教育案内及び電子商取引アプリケーション（ホームバンキング等）を含む。
【００１９】
セットトップボックス60はまた、セットトップボックス60が外部関係者にデータを送信し、外部関係者からデータを受信することを可能にするための帰路（又はインタラクション）チャンネル85をサポートするモデムを備えている。一般的に、インタラクション・チャンネルは、POTSのような従来の電話ネットワークを使用する。インタラクション・チャンネル85は、アプリケーションプロバイダ50への直接のダイヤルアップ（POTS）接続、データネットワークを通じて運ばれるアプリケーションプロバイダ50とゲートウェイとの間の接続を備えたデータネットワーク（インターネット等）のゲートウェイへの接続、ケーブル・バックチャンネルとアプリケーションプロバイダへのデータネットワーク（インターネット）を通じた接続との組み合わせ、ADSL又は他のブロードバンドインターネット接続、衛星アップリンク又はISDN回線の形式になってもよい。
【００２０】
セットトップボックス60はまた、ユーザ入力を受け取るリモコン20又はキーボードとのユーザインタフェースと、テレビディスプレイ12に供給されるビデオ信号10に重ねられ得るグラフィック出力とを有する。
【００２１】
MHP端末はJavaTM Virtual Machine（JVM）を中心に構築され、アプリケーションはJava（登録商標）で記述される。Java（登録商標）の使用は、各種の端末で仮想機械が、その端末に存在する特定のハードウェア及びソフトウェアに互換のある形式にJava（登録商標）バイトコードを変換することで、アプリケーションが共通のフォーマットで記述され得るという利点を有する。
【００２２】
図２は、一般的なMHP端末60内の機能ブロックを示している。既知のように、端末60は、受信放送信号35を処理するフロントエンドを有する。これは、所要のチャンネルを選択及び復調するチューナ61及び復調器と、信号を解読する任意選択の限定受信ユニット62とを有する。結果のデジタルデータストリームは、オーディオ及びビデオデータを表すデータストリーム（一般的にMPEG-2フォーマット）と、繰返し放送のDSM-CC Object Carousel64の形式のアプリケーション用のデータとに逆多重化される63。オーディオ及びビデオデータは、ユーザへの提示用に、適切な出力信号12、14を得るように更に処理され得る65。放送ストリームからダウンロードされると、アプリケーション（又は複数のアプリケーション）は、端末のメモリ69に存在し、端末のマイクロプロセッサ68により実行される。アプリケーションは、ユーザ入力22を受け取り、オーディオ及びビデオ出力を生成し、インタラクション・チャンネル85にアクセスしてもよい。マイクロプロセッサ68を動作する制御ソフトウェアもまた、メモリ装置に存在する。図２は、放送配信チャンネルを介して信号を受信することを目的とした端末を示している点に留意すべきである。端末の他の実施例では、非放送配信チャンネルとインタフェースすることを目的としており、チューナ／復調器61は、配信チャンネルに適したネットワークインタフェースと交換される。これは、インターネットプロトコル（IP）ベースの配信チャンネルでもよい。
【００２３】
図３及び４は、放送ストリームから暗号化アプリケーションをダウンロードする処理を示している。図３は、送信されるアプリケーションの構成要素を示しており、図４は、アプリケーションをダウンロードして作動するために端末60により実行される処理のフローチャートを示している。ステップ400において、ユーザはアプリケーション“X”がダウンロードされることを要求する。その要求は、ユーザがスクリーン上のメニューをナビゲーションしてリモコン20のキーを押すこと等により、従来の方法で行われてもよい。要求されたアプリケーションは２つの部分（併せてブロック300として図示する）で放送される。
−暗号化されていないフォーマットで放送される‘ランチャー’又は‘ローダ’Xlet310
−暗号化されたフォーマットで放送されるメインアプリケーション320
メインアプリケーション320はクラス321及びデータ322を有し、その双方が暗号化されている。
【００２４】
暗号化メインアプリケーションは、DSM-CC Data Carousel、DSM-CC MPE（IPマルチキャスト・カプセル化）、Data Piping又はインターネットを介して送信されてもよい。
【００２５】
ランチャー・アプリケーション310及び暗号化メインアプリケーション320は、一緒に送信されてもよく、別々に送信されてもよい。別々に送信される場合には、双方ともDSM-CCのような同じトランスポートストリームを介して送信されてもよく、異なるトランスポートストリームを介して送信されてもよい（一方は放送で、他方はインターネットを介して送信される）。このように、本発明を使用して、インターネットで暗号化クラスを送信し、それを端末で解読することが可能になる。
【００２６】
ステップ402において、端末は、放送ストリームでオブジェクト・カルーセル64からアプリケーションXに必要なファイルを取り出す。次に、ランチャー・アプリケーション310が開始される。ランチャー・アプリケーション310は、インタラクション・チャンネル85でアプリケーションプロバイダ50にコンタクトし、許可要求314を送信する。アプリケーションプロバイダ50にコンタクトする目的は、ユーザがアプリケーションを作動することを許可されていることを確保するためである。このステップは、アプリケーションの使用を許可する前に、ユーザから支払を収集することを有してもよい。ユーザが許可されると、インタラクション・チャンネル85でアプリケーションプロバイダ50から解読鍵313を受信する。ユーザが許可されない場合、ステップ406において、メッセージは端末60に返信され、このことを通知するメッセージがユーザに対して表示される。更に何も生じず、メインアプリケーション320は解読されない。許可が実現できる様々な方法が存在する。許可を取得するいくつかの可能な方法には次のようなものがある。
【００２７】
ランチャー・アプリケーション310はクレジットカードの詳細についてユーザに促す。クレジットカードの詳細を受信すると317、ランチャー・アプリケーション310はアプリケーションプロバイダ50の支払許可エンティティ55にコンタクトし、クレジットカードの詳細を渡す。支払が受け入れられると、解読鍵313は、インタラクション・チャンネル85でアプリケーションプロバイダ50から端末60に返信される。
【００２８】
ランチャー・アプリケーション310は、アプリケーションプロバイダ50により運営されているプレミアムレートの電話番号にダイヤルする。端末60のユーザにより負担された電話呼出のコストがアプリケーションの価格に等しくなるまで、電話が維持される。この時点で、アプリケーションプロバイダ50は解読鍵313をランチャー・アプリケーション310に送信し、電話が終了する。
【００２９】
ランチャー・アプリケーション310は加入又はクラブ会員番号について、場合によってはパスワード又はPINと共にユーザに促す。ランチャー・アプリケーションはアプリケーションプロバイダ50にコンタクトし314、この情報を提供する。ユーザが許可されると、解読鍵313はアプリケーションプロバイダ50から端末60に送信される。
【００３０】
ランチャー・アプリケーション310は、端末60のカードリーダに挿入されたスマートカード（例えばGerman GeldKarte）から支払を行い、解読鍵を取得するためにアプリケーションプロバイダ50にコンタクトする。
【００３１】
好ましくは何らかの方法でアプリケーションプロバイダ50に支払った後で、ランチャー・アプリケーション310が解読鍵313を取得するためにアプリケーションプロバイダ50にコンタクトする場合に、その他の手段が使用されてもよいことがわかる。
【００３２】
再び図４を参照すると、ステップ408において、ランチャー・アプリケーション310はMHPアプリケーション320を解読して作動する必要がある。ClassLoaderを生成することに対する制約を克服するために、ランチャー・アプリケーション310は端末60で小型HTTPサーバ315を生成するコードを有する。許可が受信されると、ランチャー・アプリケーション310はこのHTTPサーバ315を開始する。HTTPサーバ315は、指定のポートでjava.net.ServerSocketクラスを生成する。次に、ランチャー・アプリケーション310はDVBClassLoader316を生成する。DVBClassLoaderはMHP標準の一部であり、URLからの（例えばHTTPサーバからの）クラスのみをロードすることができる。ランチャー・アプリケーション310は、まさに生成されたHTTPサーバ315のURLをDVBClassLoader316に渡す。DVBClassLoaderがこのポートに接続すると、ソケット（java.net.Socket）接続が生成される。この接続は双方向接続で使用可能である。次に、ランチャー・アプリケーション310はDVBClassLoader316内のメインアプリケーション330を開始し得る。メインアプリケーション及びそれが必要とする何らかのデータを解読することは、如何なる標準的な解読アルゴリズムで行われてもよい。これらの例には、Data Encryption Standard（DES）、Triple Data Encryption Standard（3DES）及びAdvanced Encryption Standard（AES）が含まれる。解読アルゴリズムは、アプリケーションと共に放送されることを必要としてもよい。解読の好ましい方法は、オンデマンドの解読である。すなわち、アプリケーションがクラスをロードする必要があるときに、そのクラスのデータについて要求がDVBClassLoaderからHTTPサーバに送信される。暗号化クラスファイルはDSM-CCからダウンロードされ、解読され、それらが抽出されたHTTPサーバ315に渡される。このことはメモリ使用量を減少させる。その理由は、解読済のクラスファイルは短期間しかメモリに存在せず、如何なる時点においても少数の要求のみが処理される可能性があるからである。
【００３３】
セキュリティのため、HTTPサーバ315は、MHP端末内から生じていない如何なる接続をも拒否する。理想的には、HTTPサーバ315は、‘localhost’のIPアドレスでのみ受信すべきであり、通常のTCP/IP動作は外部接続をブロックする。これは、解読済のクラスがMHP端末60を離れないということを意味する。TCP/IPをサポートする装置は、複数のネットワークインタフェースを有してもよい。一般的に、各ネットワークインタフェースは、単一の物理ネットワーク接続に対応する。しかし、全てのTCP/IP装置は‘ループバック’インタフェースと呼ばれる特別の仮想ネットワークインタフェースを有する。これは装置内からのみアクセス可能であり、リモートからそれにアクセスすることはできない。TCP/IPサーバソケットが生成されると、全てのネットワークインタフェースからアクセス可能になることがデフォルトである。しかし、それを単一のネットワークインタフェースに制限又は‘束縛’することが可能である。従って、サーバが（IPアドレス127.0.0.1で）ループバックインタフェースに結び付けられている場合、STBの外部からはアクセスすることができない。HTTPサーバは、暗号化アプリケーションの有効期間に存在する。
【００３４】
更なるセキュリティのため、ランチャー・アプリケーション310とメインアプリケーション320との双方のコードは、リバース・エンジニアリングされることを困難にするようにあいまいになっている。これは、記述ラベルが小さい記述ラベルに除去又は名称変更されるようにコードが処理されることを意味する。従って、ハッカーがアプリケーションをうまく解読したとしても、アプリケーションの動作を変更することを困難にすることがわかる。短い記述的でないラベルの使用もまた、コードのサイズを低減することに役立つ。
【００３５】
アプリケーション320により使用されるデータは、同じ鍵313を使用して解読されるが、HTTPサーバ315を通じて送信される必要はない。その代わりに、解読済のデータがメインアプリケーション330に直接渡される。
【００３６】
前述の説明では、メインアプリケーションにより使用される暗号化データ322は解読され、メインアプリケーション330に直接渡される。代替として、そのデータはHTTPサーバ315に渡されてもよい。
【００３７】
サーバ315はHTTPサーバである必要なく、FTPを含み、MHP端末によりサポートされる如何なるプロトコル用のサーバでもよい。
【００３８】
前記の実施例では、許可エンティティ55は、アプリケーションプロバイダ50の一部として図示されている。これは必ずしも必要ではない。許可エンティティ55は、アプリケーションプロバイダから物理的に離れて、アプリケーションプロバイダ50の代わりに許可機能を実行してもよい。
【００３９】
前記の実施例では、解読鍵313は、ユーザの支払又は適切な許可に応じて、アプリケーションプロバイダ50により提供される。しかし、この技術は、単にアプリケーションをリバース・エンジニアリングされにくくするために使用されてもよい。その場合、解読鍵313は、ランチャー・アプリケーション310の一部として提供されてもよい。クラスは依然としてHTTPサーバ315内で解読され、端末60の内部に残る。
【００４０】
本発明は、ここで説明した実施例に限定されず、本発明の範囲を逸脱することなく、変更又は変形されてもよい。
【図面の簡単な説明】
【００４１】
【図１】本発明を具現したデジタルビデオ放送（DVB）システム
【図２】図１のシステムで使用される加入者端末内の機能ブロック
【図３】本発明による暗号化アプリケーションの構成要素
【図４】暗号化アプリケーションを処理するフローチャート
【特許請求の範囲】
【請求項１】
デジタル放送システムにおいて端末でアプリケーションをダウンロードする方法であって、
ランチャー・アプリケーションを受信するステップと、
前記ランチャー・アプリケーションを開始するステップと、
前記端末でサーバを生成するステップと、
前記サーバを介して前記端末にメインアプリケーションをロードするアプリケーション・ローダを生成するステップと
を有する方法。
【請求項２】
請求項１に記載の方法であって、
前記メインアプリケーションは、暗号化アプリケーションである方法。
【請求項３】
請求項２に記載の方法であって、
前記ランチャー・アプリケーションは、前記サーバからダウンロードされたときに、前記メインアプリケーションを解読するように構成される方法。
【請求項４】
請求項３に記載の方法であって、
前記メインアプリケーションを解読する前に、外部関係者にコンタクトして許可を取得するステップを更に有する方法。
【請求項５】
請求項４に記載の方法であって、
前記ユーザが許可されたことに応じて、前記外部関係者から解読鍵を受信することを更に有する方法。
【請求項６】
請求項４又は５に記載の方法であって、
前記端末のユーザから支払の詳細を収集するステップを更に有する方法。
【請求項７】
請求項４ないし６のうちいずれか１項に記載の方法であって、
前記端末のユーザから支払を収集するステップを更に有する方法。
【請求項８】
請求項１ないし７のうちいずれか１項に記載の方法であって、
前記メインアプリケーションは、クラスとデータとを有し、
前記アプリケーション・ローダは、前記サーバを介して前記クラスのみをロードするように構成される方法。
【請求項９】
請求項１ないし８のうちいずれか１項に記載の方法であって、
前記サーバは、前記端末内で生じた接続要求のみに応答するように構成される方法。
【請求項１０】
請求項１ないし９のうちいずれか１項に記載の方法であって、
前記サーバはHTTPサーバである方法。
【請求項１１】
請求項１ないし１０のうちいずれか１項に記載の方法であって、
前記メインアプリケーションは、前記ランチャー・アプリケーションを受信するために使用されるものと異なる配信チャンネルを介して受信される方法。
【請求項１２】
請求項１ないし１１のうちいずれか１項に記載の方法であって、
前記デジタル放送システムは、Multimedia Home Platform（MHP）である方法。
【請求項１３】
請求項１０ないし１２のうちいずれか１項に記載の方法であって、
前記端末は、Multimedia Home Platform（MHP）に準拠する方法。
【請求項１４】
デジタル放送システムにおける端末への送信用のアプリケーションを生成する方法であって、
前記方法は、ランチャー・アプリケーションとメインアプリケーションとを生成することを有し、
前記ランチャー・アプリケーションは、送信される端末でサーバを生成し、前記サーバを介して前記端末に前記メインアプリケーションをロードするためのアプリケーション・ローダを生成するように構成される方法。
【請求項１５】
請求項１４に記載の方法であって、
前記メインアプリケーションは、暗号化アプリケーションである方法。
【請求項１６】
請求項１５に記載の方法であって、
前記ランチャー・アプリケーションは、前記サーバを介してダウンロードされたときに、前記メインアプリケーションを解読するように構成される方法。
【請求項１７】
請求項１６に記載の方法であって、
前記ランチャー・アプリケーションは、前記メインアプリケーションを解読する前に、外部関係者にコンタクトして許可を取得するように構成される方法。
【請求項１８】
請求項１７に記載の方法であって、
前記ランチャー・アプリケーションは、前記ユーザが許可されたことに応じて、前記外部関係者から解読鍵を受信するように構成される方法。
【請求項１９】
請求項１７又は１８に記載の方法であって、
前記ランチャー・アプリケーションは、前記端末のユーザから支払の詳細を収集する手段を更に有する方法。
【請求項２０】
請求項１７又は１８に記載の方法であって、
前記ランチャー・アプリケーションは、前記端末のユーザから支払を収集するように構成される方法。
【請求項２１】
請求項１４ないし２０のうちいずれか１項に記載の方法であって、
前記メインアプリケーションは、クラスとデータとを有し、
前記アプリケーション・ローダは、前記サーバを介して前記クラスのみをロードするように構成される方法。
【請求項２２】
請求項１４ないし２１のうちいずれか１項に記載の方法であって、
前記サーバは、前記端末内で生じた接続要求のみに応答するように構成される方法。
【請求項２３】
請求項１４ないし２２のうちいずれか１項に記載の方法であって、
前記サーバはHTTPサーバである方法。
【請求項２４】
アプリケーションを生成するためのオーサリング・ソフトウェアであって、
請求項１４ないし２３のうちいずれか１項に記載の方法を実行するコードを有するオーサリング・ソフトウェア。
【請求項２５】
デジタル放送システムにおいて端末にアプリケーションを送信する方法であって、
前記方法は、ランチャー・アプリケーションとメインアプリケーションとを前記端末に送信することを有し、
前記ランチャー・アプリケーションは、送信される端末でサーバを生成し、前記サーバを介して前記端末に解読済メインアプリケーションをロードするためのアプリケーション・ローダを生成するように構成される方法。
【請求項２６】
デジタル放送システムにおいて端末に送信するアプリケーション用のソフトウェアであって、
ランチャー・アプリケーションとメインアプリケーションとを有し、
前記ソフトウェアは、前記端末のプロセッサにより実行されると、
前記端末でサーバを生成するステップと、
前記サーバを介して前記端末に前記メインアプリケーションをロードするアプリケーション・ローダを生成するステップと
を前記プロセッサに実行させるコードを有するソフトウェア。
【請求項２７】
デジタル放送システムにおける伝送用の信号であって、
請求項２６に記載のソフトウェアを具現した信号。
【請求項２８】
実質的に添付図面を参照して説明し、添付図面に図示した、アプリケーションをダウンロードする方法、アプリケーションを生成する方法、ソフトウェア又は信号。
【請求項１】
デジタル放送システムにおいて端末でアプリケーションをダウンロードする方法であって、
ランチャー・アプリケーションを受信するステップと、
前記ランチャー・アプリケーションを開始するステップと、
前記端末でサーバを生成するステップと、
前記サーバを介して前記端末にメインアプリケーションをロードするアプリケーション・ローダを生成するステップと
を有する方法。
【請求項２】
請求項１に記載の方法であって、
前記メインアプリケーションは、暗号化アプリケーションである方法。
【請求項３】
請求項２に記載の方法であって、
前記ランチャー・アプリケーションは、前記サーバからダウンロードされたときに、前記メインアプリケーションを解読するように構成される方法。
【請求項４】
請求項３に記載の方法であって、
前記メインアプリケーションを解読する前に、外部関係者にコンタクトして許可を取得するステップを更に有する方法。
【請求項５】
請求項４に記載の方法であって、
前記ユーザが許可されたことに応じて、前記外部関係者から解読鍵を受信することを更に有する方法。
【請求項６】
請求項４又は５に記載の方法であって、
前記端末のユーザから支払の詳細を収集するステップを更に有する方法。
【請求項７】
請求項４ないし６のうちいずれか１項に記載の方法であって、
前記端末のユーザから支払を収集するステップを更に有する方法。
【請求項８】
請求項１ないし７のうちいずれか１項に記載の方法であって、
前記メインアプリケーションは、クラスとデータとを有し、
前記アプリケーション・ローダは、前記サーバを介して前記クラスのみをロードするように構成される方法。
【請求項９】
請求項１ないし８のうちいずれか１項に記載の方法であって、
前記サーバは、前記端末内で生じた接続要求のみに応答するように構成される方法。
【請求項１０】
請求項１ないし９のうちいずれか１項に記載の方法であって、
前記サーバはHTTPサーバである方法。
【請求項１１】
請求項１ないし１０のうちいずれか１項に記載の方法であって、
前記メインアプリケーションは、前記ランチャー・アプリケーションを受信するために使用されるものと異なる配信チャンネルを介して受信される方法。
【請求項１２】
請求項１ないし１１のうちいずれか１項に記載の方法であって、
前記デジタル放送システムは、Multimedia Home Platform（MHP）である方法。
【請求項１３】
請求項１０ないし１２のうちいずれか１項に記載の方法であって、
前記端末は、Multimedia Home Platform（MHP）に準拠する方法。
【請求項１４】
デジタル放送システムにおける端末への送信用のアプリケーションを生成する方法であって、
前記方法は、ランチャー・アプリケーションとメインアプリケーションとを生成することを有し、
前記ランチャー・アプリケーションは、送信される端末でサーバを生成し、前記サーバを介して前記端末に前記メインアプリケーションをロードするためのアプリケーション・ローダを生成するように構成される方法。
【請求項１５】
請求項１４に記載の方法であって、
前記メインアプリケーションは、暗号化アプリケーションである方法。
【請求項１６】
請求項１５に記載の方法であって、
前記ランチャー・アプリケーションは、前記サーバを介してダウンロードされたときに、前記メインアプリケーションを解読するように構成される方法。
【請求項１７】
請求項１６に記載の方法であって、
前記ランチャー・アプリケーションは、前記メインアプリケーションを解読する前に、外部関係者にコンタクトして許可を取得するように構成される方法。
【請求項１８】
請求項１７に記載の方法であって、
前記ランチャー・アプリケーションは、前記ユーザが許可されたことに応じて、前記外部関係者から解読鍵を受信するように構成される方法。
【請求項１９】
請求項１７又は１８に記載の方法であって、
前記ランチャー・アプリケーションは、前記端末のユーザから支払の詳細を収集する手段を更に有する方法。
【請求項２０】
請求項１７又は１８に記載の方法であって、
前記ランチャー・アプリケーションは、前記端末のユーザから支払を収集するように構成される方法。
【請求項２１】
請求項１４ないし２０のうちいずれか１項に記載の方法であって、
前記メインアプリケーションは、クラスとデータとを有し、
前記アプリケーション・ローダは、前記サーバを介して前記クラスのみをロードするように構成される方法。
【請求項２２】
請求項１４ないし２１のうちいずれか１項に記載の方法であって、
前記サーバは、前記端末内で生じた接続要求のみに応答するように構成される方法。
【請求項２３】
請求項１４ないし２２のうちいずれか１項に記載の方法であって、
前記サーバはHTTPサーバである方法。
【請求項２４】
アプリケーションを生成するためのオーサリング・ソフトウェアであって、
請求項１４ないし２３のうちいずれか１項に記載の方法を実行するコードを有するオーサリング・ソフトウェア。
【請求項２５】
デジタル放送システムにおいて端末にアプリケーションを送信する方法であって、
前記方法は、ランチャー・アプリケーションとメインアプリケーションとを前記端末に送信することを有し、
前記ランチャー・アプリケーションは、送信される端末でサーバを生成し、前記サーバを介して前記端末に解読済メインアプリケーションをロードするためのアプリケーション・ローダを生成するように構成される方法。
【請求項２６】
デジタル放送システムにおいて端末に送信するアプリケーション用のソフトウェアであって、
ランチャー・アプリケーションとメインアプリケーションとを有し、
前記ソフトウェアは、前記端末のプロセッサにより実行されると、
前記端末でサーバを生成するステップと、
前記サーバを介して前記端末に前記メインアプリケーションをロードするアプリケーション・ローダを生成するステップと
を前記プロセッサに実行させるコードを有するソフトウェア。
【請求項２７】
デジタル放送システムにおける伝送用の信号であって、
請求項２６に記載のソフトウェアを具現した信号。
【請求項２８】
実質的に添付図面を参照して説明し、添付図面に図示した、アプリケーションをダウンロードする方法、アプリケーションを生成する方法、ソフトウェア又は信号。
【図１】
【図２】
【図３】
【図４】
【図２】
【図３】
【図４】
【公表番号】特表２００７−５０１４６１（Ｐ２００７−５０１４６１Ａ）
【公表日】平成１９年１月２５日（２００７．１．２５）
【国際特許分類】
【出願番号】特願２００６−５２２４３８（Ｐ２００６−５２２４３８）
【出願日】平成１６年７月２８日（２００４．７．２８）
【国際出願番号】ＰＣＴ／ＩＢ２００４／００２５７３
【国際公開番号】ＷＯ２００５／０１３１２７
【国際公開日】平成１７年２月１０日（２００５．２．１０）
【出願人】（５９００００２４８）コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ (12,071)
【氏名又は名称原語表記】Ｋｏｎｉｎｋｌｉｊｋｅ Ｐｈｉｌｉｐｓ Ｅｌｅｃｔｒｏｎｉｃｓ Ｎ．Ｖ．
【住所又は居所原語表記】Ｇｒｏｅｎｅｗｏｕｄｓｅｗｅｇ １，５６２１ ＢＡ Ｅｉｎｄｈｏｖｅｎ， Ｔｈｅ Ｎｅｔｈｅｒｌａｎｄｓ
【Ｆターム（参考）】
【公表日】平成１９年１月２５日（２００７．１．２５）
【国際特許分類】
【出願日】平成１６年７月２８日（２００４．７．２８）
【国際出願番号】ＰＣＴ／ＩＢ２００４／００２５７３
【国際公開番号】ＷＯ２００５／０１３１２７
【国際公開日】平成１７年２月１０日（２００５．２．１０）
【出願人】（５９００００２４８）コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ (12,071)
【氏名又は名称原語表記】Ｋｏｎｉｎｋｌｉｊｋｅ Ｐｈｉｌｉｐｓ Ｅｌｅｃｔｒｏｎｉｃｓ Ｎ．Ｖ．
【住所又は居所原語表記】Ｇｒｏｅｎｅｗｏｕｄｓｅｗｅｇ １，５６２１ ＢＡ Ｅｉｎｄｈｏｖｅｎ， Ｔｈｅ Ｎｅｔｈｅｒｌａｎｄｓ
【Ｆターム（参考）】
[ Back to top ]