(57)【要約】双方向テレビのための記録装置又は再生・記録装置においてフォントを処理する方法（４９、５５）である。フォントは、記録可能な記憶媒体（２２０）上に記憶され、ここで、前記フォントは、ダウンロードされる双方向テレビアプリケーションの一部である。記録する場合、ダウンロードされる前記フォントは、前記アプリケーションとは別に、好ましくは前記記録可能な記憶媒体上のフォントライブラリ内に記憶され、前記記録可能な記憶媒体は、好ましくは、取り外し可能な媒体、好ましくは、光学的な記憶媒体である。各フォントは、前記記憶媒体上の複数のアプリケーションが走るのにそのフォントを必要とする場合でも、１つのコピーでしか記憶されない。前記記憶媒体から前記アプリケーションを再生する場合、前記フォントライブラリ内の前記記憶媒体からのどのフォントが該記憶媒体からの前記アプリケーションの再生のために必要とされるかということについての表示情報が供給される。斯くして、フォントの多重記憶が防止され、前記記憶媒体における所要記憶空間を最小限にする。
2006510299.tif 000002
【特許請求の範囲】
【請求項１】
双方向テレビのための記録装置においてフォントを処理する方法であり、前記フォントが、記録可能な記憶媒体上に記憶され、前記フォントが、双方向テレビアプリケーションの一部であり、前記アプリケーションが、少なくともアプリケーションプログラムと、少なくともフォントとを有する方法であって、
ダウンロードされる前記フォントを、前記アプリケーションとは別に、前記記録可能な記憶媒体上に記憶するステップを有し、それによって、各フォントが、前記記録可能な記憶媒体上に一度しか記憶されない方法。
【請求項２】
前記アプリケーションが、アプリケーションプログラム及びフォントを有するアプリケーションモジュールを有することを特徴とする請求項１に記載の方法。
【請求項３】
前記ダウンロードされるフォントがフォントライブラリ内に記憶されることを特徴とする請求項１又は２に記載の方法。
【請求項４】
前記アプリケーションを走らせるのに必要とされる少なくとも１つのフォントを示す包含されているフォントデータについて該アプリケーションを解析するステップと、
ダウンロードされるストリームから前記アプリケーションと前記フォントとを分離するステップと、
前記フォントが前記フォントライブラリ内にまだ記憶されていない場合には、前記フォントデータ及び前記フォントを新たなフォントとして前記フォントライブラリ内に記憶するステップと
その他の場合には、前記フォントを無視するステップと、
前記フォントを持たない前記アプリケーションモジュールを前記記憶媒体上に記憶するステップとを更に有することを特徴とする請求項１乃至３のいずれか一項に記載の方法。
【請求項５】
前記フォントライブラリが個別のファイルを有することを特徴とする請求項１乃至４のいずれか一項に記載の方法。
【請求項６】
前記フォントライブラリが単一のファイルから成ることを特徴とする請求項５に記載の方法。
【請求項７】
前記フォントライブラリが、好ましくは、該フォントライブラリ内の前記フォントのフォント記憶位置情報、フォントライブラリのサイズ、フォントのタイプ、フォント名及びフォントの言語についてのデータを有するフォント索引によって索引を付けられることを特徴とする請求項１乃至６のいずれか一項に記載の方法。
【請求項８】
前記記憶媒体上に既に記憶されているフォント以外は、iTVブロードキャストのフォント索引ファイル内に示されている全てのフォントを記録するステップを更に有することを特徴とする請求項１に記載の方法。
【請求項９】
前記記録可能な記憶媒体が取り外し可能な記憶媒体であることを特徴とする請求項１乃至８のいずれか一項に記載の方法。
【請求項１０】
前記取り外し可能な記憶媒体が光ディスクであることを特徴とする請求項９に記載の方法。
【請求項１１】
前記双方向テレビが、MHP、OpenTV又はDASEであることを特徴とする請求項１乃至１０のいずれか一項に記載の方法。
【請求項１２】
前記フォントが中国語であることを特徴とする請求項１乃至１１のいずれか一項に記載の方法。
【請求項１３】
前記フォントライブラリ内に記憶される前記フォントデータが、該フォントライブラリ内の前記必要とされるフォントの順序位置又はパス位置についての情報を有することを特徴とする請求項４に記載の方法。
【請求項１４】
前記フォントライブラリ内に記憶される前記フォントデータが、アプリケーションプログラムを走らせるのに必要とされるフォントの位置を突き止めることを可能にする前記必要とされるフォントの名前についての情報を有することを特徴とする請求項４に記載の方法。
【請求項１５】
前記アプリケーションを走らせるのに必要とされる少なくとも１つのフォントを示す包含されているフォントデータについて前記アプリケーションを解析するステップと、
ダウンロードされるストリームから前記アプリケーションと前記フォントとを分離するステップと、
前記フォントが前記フォントライブラリ内にまだ記憶されていない場合には、前記フォントデータ及び前記フォントを新たなフォントとして前記フォントライブラリ内に記憶するステップと
その他の場合には、前記フォントライブラリ内に既に記憶されている前記フォントを前記ダウンロードされるストリームから分離される前記フォントに置き換えるステップと、
前記フォントを持たない前記アプリケーションモジュールを前記記憶媒体上に記憶するステップとを更に有することを特徴とする請求項１乃至３のいずれか一項に記載の方法。
【請求項１６】
記録された記憶媒体のための再生・記録装置においてフォントを処理する方法であり、前記媒体が、再生されるべき双方向テレビを有し、前記フォントが、前記記録可能な記憶媒体上のフォントライブラリ内に記憶され、前記フォントが、記録される双方向テレビアプリケーションの一部である方法であって、
前記フォントライブラリ内のどのフォントが前記記憶媒体からの前記アプリケーションの再生のために必要とされるかを示すステップと、
前記アプリケーションを走らせるために、前記記憶媒体上に記憶されているアプリケーションと、必要とされる前記フォントをマージするステップとを有する方法。
【請求項１７】
双方向テレビを記録及び／又は再生する装置であり、記憶媒体に双方向テレビを記録し、記憶媒体から双方向テレビを再生するよう適応されている装置であり、
フォント処理装置を有し、前記フォント処理装置が前記装置のために適応させられている装置であって、ダウンロードされる双方向テレビアプリケーションの一部であるフォントが、前記フォント処理装置の使用中、前記記録可能な記憶媒体上に記憶されており、前記フォントは、前記アプリケーションとは別に、前記記録可能な記憶媒体上に記憶され、それによって、各フォントが１つのコピーでしか記憶されない装置。
【請求項１８】
コンピュータによって処理するためのコンピュータプログラムをコンピュータ読取り可能な媒体上に包含しているコンピュータ読取り可能な媒体であり、
前記コンピュータプログラムが、双方向テレビアプリケーションからのダウンロードされるフォントを記憶媒体上に記憶するためのコードセグメントを有するコンピュータ読取り可能な媒体であって、前記コードセグメントが、前記フォントライブラリ内に異なるフォントの１つのコピーしか記憶しないよう前記コンピュータに命令するコンピュータ読取り可能な媒体。
【請求項１９】
請求項１に記載の方法の使用。
【請求項２０】
双方向テレビのための記憶媒体であって、
前記記憶媒体上に記録される少なくとも２つの双方向テレビアプリケーションを有し、前記アプリケーションが、該アプリケーションを走らせるのに必要とされるフォントとは別に記憶され、
前記双方向テレビアプリケーションのうちの少なくとも２つが同じフォントを使用し、
それによって、各フォントの２つ以上のコピーが前記記憶媒体上に記憶されない記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、広くは、双方向テレビの分野に関し、より詳細には、双方向テレビのコンテンツの記録に関し、更により詳細には、双方向テレビのコンテンツの記録の分野におけるフォントの処理に関する。
【背景技術】
【０００２】
双方向テレビ(iTV)はますます普及しつつある。双方向テレビの例は、マルチメディアホームプラットフォーム(MHP)であり、マルチメディアホームプラットフォーム(MHP)は、インターネット及びワールド・ワイド・ウェブに対するアクセス及び双方向性とデジタルテレビ(DTV)を組み合わせることを目的とするデジタルビデオブロードキャスト(DVB)規格である。DTVのサービスプロバイダは、多様なオーディオビジュアル(A/V)のテレビ番組を供給し、TV及び該TVのコンテンツと視聴者／ユーザの対話を可能にする多様なアプリケーションも供給する。アプリケーションは、A/Vコンテンツと共にブロードキャストされ、このタスクのために適応されたテレビ、又は別個のセットトップボックス(STB)において実行される。
【０００３】
ブロードキャストストリームを記録するのにビデオテープを用いるアナログテレビ放送のための今日のビデオ記録装置に似ている、記録されたブロードキャストを記憶するのに光ディスクなどの取り外し可能な媒体又はハードディスクのいずれかを用いる双方向テレビのためのデジタルビデオ記録装置が開発されている。双方向テレビのためのデジタルビデオ記録装置は、A/Vテレビコンテンツと、より遅い時点での再生のためのアプリケーションとの両方を記録する。
【０００４】
双方向テレビのアプリケーションは、実行されるアプリケーションプログラム部分から成り、前記アプリケーションプログラム部分は、キャラクタ(character)を表示する場合にフォントを用いる。これらのフォントは、セットトップボックス(STB)内に常駐し得る、又は該フォントを用いるアプリケーションと共にダウンロードされ得る。STB内の常駐フォントは一般にデフォルトフォントと呼ばれる。
【０００５】
iTVブロードキャストコンテンツを記録する場合、ダウンロードされるフォント（即ち、ブロードキャストトランスポートストリームに埋め込まれるフォント）の場合には、ダウンロードされるフォントは、現在、各アプリケーションプログラムと一緒に、アプリケーションを再生する場合により後の時点にアプリケーションを走らせるために該アプリケーションプログラムによって必要とされる他のファイルと共に記憶される。ラテン語のアルファベットの場合には、フォントを記憶するのに必要とされるサイズは、相対的に小さく、約５０キロバイト未満の範囲内である。しかしながら、例えば中国語のアルファベットといったアジアのアルファベットなどの或る他のアルファベットの場合には、フォントのサイズは、著しく大きく、例えば２メガバイトである。
【０００６】
上記のようにアプリケーションを記録する場合、アプリケーションを実行する装置、例えばSTBにおいてどのフォントが利用可能であるかは通例分からないので、フォントは各アプリケーションと共に記録される。更に、ブロードキャスタが、例えば審美的な理由で、多数のアプリケーションに対して、該アプリケーションの同じルック＆フィールを生成する同じダウンロード可能なフォントを用いることが見込まれる。斯くして、全てが同じフォントを用いる複数のアプリケーションが記録される場合、フォントは、多数回記録、即ち、記憶されなければならないであろう。記憶空間の量は限られているので、ダウンロードされる同じフォントデータのこの多数回の記録は、記憶媒体において大量の記憶空間をとる。それ故、とりわけ、各フォントが大きなサイズを持つ場合、又は記憶媒体上に記憶されるファイルの数、即ち、フォントの数が多い場合、記憶媒体の大部分がフォントのために用いられる。記憶媒体上に可能な限り多くのiTVコンテンツを記録することが出来るように、アプリケーションのために用いられる空間の量を可能な限り少なくしておくことが望ましい。
【０００７】
米国特許公報第US-6,141,002号は、セットトップボックス(STB)において多数の言語のユニコードテキストをレンダリングするシステム及び方法を開示している。STBはデフォルトフォントのセットを含む。STBが、デフォルトフォントの一部ではないキャラクタを持つブロードキャストアプリケーションを受け取る場合、STBは、ダウンロードされるアプリケーションを介して利用可能なフォントを調べ、代わりにダウンロードフォントを用いる。その場合、このダウンロードされるフォントは、ダウンロードされたフォントを有する別個のメモリ内に記憶され、故に、今ダウンロードされたフォントグリフは将来において利用可能である。この方法は、A/Vコンテンツ及びアプリケーションが光ディスクなどの取り外し可能な媒体上に記録されなければならない場合、フォントはアプリケーションと共にディスク上に記録されなければならないという不利な点を持つ。これは、記録された取り外し可能な媒体が、該取り外し可能な媒体が記録された記録装置とは別の記録装置において再生される場合があるという事実のためである。これは、米国特許公報第US-6,141,002号によって開示されているようにSTBがメモリ内に必要なフォントを持つ場合でも、少なくともディスクが取り外し可能である場合には、フォントは今までどおりディスク上に記憶されなければならないことを意味する。更に、フォント情報が、如何なるアプリケーションとも無関係に記憶され、斯くして、記憶されるべきフォントの数の増大に伴ってメモリ空間の問題を引き起こす、即ち、現在のどのアプリケーションにも必要とされない複数のフォントがフォントダウンロードメモリ内に常駐するであろう。ダウンロードメモリは物理的に限られるので、STBは利用可能なダウンロードメモリを使い切る。それ故、アプリケーションのために用いられる空間の量を可能な限り少なくしておくという問題は、開示されているシステム及び方法によっては解決されない。
【発明の開示】
【発明が解決しようとする課題】
【０００８】
本発明の目的は、記憶媒体上に可能な限り多くのiTVコンテンツを記録することが出来るように、アプリケーションのために用いられる空間の量を可能な限り少なくしておくことにある。
【０００９】
より良い理解のために、この開示において用いられる用語のより詳細な定義が以下に記載されている。
【００１０】
セットトップボックス(STB)は、テレビが既存のアナログテレビでデジタルテレビ(DTV)のブロードキャストを受け取り、復号することを可能にする装置である。STBはまた、テレビがインターネットに対するユーザインタフェースになることも可能にし得る。高性能のセットトップボックスは、記録されたテレビブロードキャスト、ダウンロードソフトウェア、及びDTVサービスプロバイダによって供給される他のアプリケーションの記憶のためのハードディクスドライブを含む。
【００１１】
フォントは、特定のスタイル及びサイズの印刷可能又は表示可能なテキストキャラクタのセットである。
【００１２】
キャラクタは、音声上の意味又は絵文字的な意味を持ち、通常、テキストの単語の一部を形成する又は数を表わす又は文法上の句読を表わす印刷可能な記号である。キャラクタは、意味及び音の点で他のキャラクタと区別され得る。
【課題を解決するための手段】
【００１３】
本発明は、本発明の一態様に基づいて、双方向テレビのための記録装置又は再生・記録装置においてフォントを処理する方法であって、前記フォントが、記録型DVDなどの記録可能な記憶媒体上に記憶される方法を提供することによって、当業界の上記の不利な点を克服し、上記の問題を解決する。前記フォントは、ダウンロードされる双方向テレビアプリケーションの一部であり、前記方法は、双方向テレビコンテンツを記録する場合に、ダウンロードされる前記フォントを、アプリケーションプログラムとは別に、前記記録可能な記憶媒体上のフォントライブラリ内に記憶するステップを有する。各フォントは、記憶媒体上に一度しか記憶されない。本発明の別の態様に基づいて前記アプリケーションを再生する場合、方法は、前記記憶媒体上の複数のフォントを有する前記フォントライブラリのどの１つ又は複数のフォントが、該記憶媒体からの前記アプリケーションの再生のために必要とされるかを示し、その後、前記アプリケーションのためのフォントを選び、次いで、選ばれた前記フォントと前記アプリケーションプログラムをマージするステップを有する。
【００１４】
本発明の別の態様による、双方向テレビコンテンツの記録及び／又は再生のために用いられる装置であって、フォント処理装置を有する装置が開示されている。このフォント処理装置は、前記装置における使用のために適応させられる。ダウンロードされる双方向テレビアプリケーションの一部であるフォントは、記録可能な記憶媒体上に記憶される。前記フォントは、前記アプリケーションとは別に、前記記録可能な記憶媒体上のフォントライブラリ内に記憶され、それによって、各フォントは１つのコピーでしか記憶されない。
【００１５】
本発明の更に別の態様による、上記の方法を行なうための命令を有するコンピュータ読取り可能な媒体であって、前記コンピュータ読取り可能な媒体上にコンピュータによって処理するためのコンピュータプログラムを含むコンピュータ読取り可能な媒体が開示されている。前記コンピュータプログラムは、双方向テレビアプリケーションからのダウンロードされるフォントを記憶媒体上に記憶するためのコードセグメントであって、前記フォントライブラリ内に異なるフォントの１つのコピーしか記憶しないよう前記コンピュータに命令するコードセグメントを有する。
【００１６】
本発明の他の態様は、別個のフォントライブラリと、別個に記憶されるアプリケーションモジュールとを有する双方向テレビのための記憶媒体である。前記記憶媒体は、該記憶媒体上に記録される少なくとも２つの双方向テレビアプリケーションを有する。前記アプリケーションは、該アプリケーションを走らせるのに必要とされる前記フォントとは別に記憶される。前記記憶媒体は、フォントを有するフォントライブラリを更に有し、それよって、前記フォントライブラリは、前記記憶媒体上に記憶された全アプリケーションを走らせるのに必要とされる前記フォントの各々の２つ以上のコピーを有さない。
【００１７】
ダウンロードされるフォントは、アプリケーションとは別に、iTV記憶媒体上のフォントライブラリ内に記憶される。各フォントは、該フォントが多数のアプリケーションで用いられる場合でも、一度しか記憶されない。
【００１８】
本発明の好ましい実施例によれば、iTVアプリケーションは、記録中、該iTVアプリケーションが含むフォントについて解析される。次いで、前記アプリケーションモジュールから前記フォントが取り外される。前記フォントが、既にダウンロードされている場合には、即ち、前記フォントが、前記記憶媒体、好ましくは、取り外し可能な媒体の上の前記フォントライブラリ内に既に記憶されている場合には、ダウンロードされる前記フォントのコピーは無視される。その他の場合には、前記ダウンロードされるフォントは、前記記憶媒体上の前記フォントライブラリ内に記憶される。前記フォントを持たない修正されたアプリケーションモジュールは、前記記憶媒体上に記憶される。
【００１９】
再生の場合は、情報ファイルが、前記アプリケーションの再生のためにはどのフォントが必要とされるかを示す。前記フォントは、前記フォントライブラリからロードされ、前記アプリケーションプログラム及び記録された前記アプリケーションを走らせるための他のアプリケーションファイルとマージされる。
【００２０】
斯くして、本発明は、多数のiTVアプリケーションが同じフォントを用いる場合にフォントが記憶媒体上の不必要に大量の記憶空間を使用するという問題を解決する。
【００２１】
下記の実施例及び図面を参照して本発明のこれら及び他の態様を説明し、明らかにする。
【００２２】
以下の詳細な開示には、本発明の多数の例示的な実施例が記載されており、添付図面に対する参照がなされる。
【発明を実施するための最良の形態】
【００２３】
一般に、iTVブロードキャストは多数のファイルを含み、前記ファイルの幾つかは、一般にJavaにおいて実行可能なコードから成るアプリケーションであり、幾つかは、上記のフォントファイルを含むデータファイルである。アプリケーションは、一般に、アプリケーションプログラムを走らせるのに用いられるべきフォントを指示する。TVにおいてiTVアプリケーションを受け取り、表示するためには、フォントが、デフォルトフォントとして、若しくはダウンロードされ、STB内に記憶されたフォントとして、セットトップボックスにおいて利用可能でなければならない、又はフォントが、ブロードキャスト内にファイルとして含まれていなければならない。より後の時点に再生されるためアプリケーションを記憶媒体上に記憶する場合、アプリケーションによって用いられるフォントも記憶されなければならない。本発明によれば、フォントは、該フォントを用いる特定のアプリケーションと一緒に記憶される代わりに、記憶媒体上のフォントライブラリ内に記憶される。斯くして、アプリケーションは、例えば特定のフォントファイルの記憶位置を示すために、修正される必要がない。必要なフォントファイルは、好ましくは光ディスクである記憶媒体上の別個の記憶位置に記憶され、フォントライブラリ内にフォントファイルの重複がないことが確実にされる。再生においては、フォントライブラリが、アプリケーションが使用したいフォントを求めてサーチされる。本発明のこの原理は、以下の本発明の実施例の説明により詳細に記載されている。
【００２４】
図１Ａには最新技術によるiTVブロードキャストストリーム１００が示されている。ブロードキャストストリームは、iTVクリップA/Vコンテンツ１０１とアプリケーション１０２との両方を有する。この例においては、３つのアプリケーション１０３、１０４及び１０５が示されている。各アプリケーションは、アプリケーションプログラム１０６、１０９、１１２及びフォント１０８、１１１、１１４を有し、随意に、該アプリケーションを走らせるのに必要とされるアプリケーションファイル１０７、１１０、１１３を更に有する。示されている例においては、フォント１０８とフォント１１４とが同一であり、同じフォントが、別々のアプリケーション１０３及び１０５において、ブロードキャストストリーム１００内に２度含まれることが見られ得る。図１Ｂによれば、記憶媒体１１５上に記録された状態の図１Ａのブロードキャストストリーム１００が示されている。本発明によれば、ダウンロードされたフォント１０８、１１１、１１４は、アプリケーションとは別に、フォントモジュール１１６及び１１７として、記録可能な記憶媒体１１５上のフォントライブラリ１１８内に記憶され、ここで、記録されるフォント１１６は、ストリーミングされるアプリケーションフォント１０８及び１１４に対応し、記録されるフォント１１７は、ストリーミングされるフォント１１１に対応する。この例においては、記憶媒体１１５においてフォント１１４を記憶するのに必要とされる空間が他の記憶目的のために節減される。
【００２５】
実際には、同じブロードキャスト内の２つのアプリケーションが同じフォントを使用する場合には、前記フォントは一度しかブロードキャストされる必要がない。一般に、ブロードキャストは、ブロードキャストされるファイルのセットを同じブロードキャストセクション内に有する。２つのアプリケーションが同じブロードキャストにおいて同時にブロードキャストされる特別な場合には、これらのアプリケーションは同じブロードキャストからの同じフォントファイルを用いることが出来る。他方で、アプリケーションがより遅い時点にブロードキャストされ、このアプリケーションがより早くブロードキャストされたアプリケーションと同じフォントを用いる場合には、前記フォントは、下記の別個の戻りチャネルの場合も例外なしに、両方のブロードキャスト内に含まれる。下記の別個の戻りチャネルの場合には、記憶媒体上に既に記憶されているフォントファイルのその後のダウンロードが随意に回避され得る。本発明によれば、フォントファイルが、記憶媒体上に記録されるべきであるiTVブロードキャストによってどのくらいの頻度で送信されるかに無関係に、且つ同じフォントを用いるアプリケーションがいくつ同じ記憶媒体上に記録されるかに無関係に、フォントファイルは記憶媒体上に一度しか記録されない。
【００２６】
図２Ａには最新技術によるiTVブロードキャストストリーム１２０が示されている。iTVクリップA/Vコンテンツを有するブロードキャストストリームのほかに、アプリケーション１２１が別個に記憶される。この例においては、３つのアプリケーション１２２、１３９、１２３が示されている。各アプリケーション１２２、１３９、１２３は、アプリケーションプログラム１２４、１２７、１３０及びフォント１２６、１２９、１３２を有し、随意に、該アプリケーションを走らせるのに必要とされるアプリケーションファイル１２５、１２８、１３１を更に有する。示されている例においては、フォント１２６とフォント１３２とが同一であり、同じフォントが、別々のアプリケーション１２２及び１２３において、アプリケーション１２１内に２度含まれることが見られ得る。図２Ｂによれば、記憶媒体１４０上に記録された状態のアプリケーション１２２、１３９、１２３と一緒の図２Ａのブロードキャストストリーム１２０が示されている。本発明によれば、ダウンロードされたフォント１２６、１２９、１３２は、アプリケーションとは別に、フォントモジュール１３３及び１３５として、記録可能な記憶媒体１４０上のフォントライブラリ１３４内に記憶され、ここで、記録されるフォント１３３は、ダウンロードされるアプリケーションフォント１２６及び１３２に対応し、記録されるフォント１３５は、ストリーミングされるフォント１２９に対応する。この例においては、記憶媒体１４０においてフォント１３２を記憶するのに必要とされる空間が他の記憶目的のために節減される。
【００２７】
アプリケーションはまた、ブロードキャスト内に組み込まれるだけでなく、別個の戻りチャネルを通じても、例えば、インターネット接続を介してもダウンロードされ得る。本発明は、これが行われる場合でも等しく適用される。この場合には、フォントライブラリは、現在のアプリケーションによって必要とされるフォントが記憶媒体上のフォントライブラリ内に既に記憶されているかどうかを随意に調べられることが出来る。フォントが既に記憶されている場合には、フォントは、上記インターネット接続などの戻りチャネルを通じてダウンロードされる必要がなく、フォントファイルがダウンロードされることは回避される。これは、戻りチャネルの帯域幅及び／又は接続コストに関して有利である。
【００２８】
図３Ａは、とりわけMHP記録のための、しかしMHP記録に限定されない別のiTV記録構造を示しており、ここで、ダウンロードされるフォントは、図１に従ってMHPモジュールファイル１０、１１内に記憶される。各iTVクリップは、MHPアプリケーションに関するブロードキャストの一部を含む該iTVクリップ自体のMHPモジュールファイルを有する。このファイルは、ブロードキャストストリーム内のいずれかのフォントを含むであろう。斯くして、各クリップは、該クリップ自体のフォントモジュールと共に記憶され、これが上記の問題を招く。
【００２９】
図３Ｂは、記憶媒体１５上に記録される本発明の実施例による図３Ａの修正された構造を示している。MHPモジュールは、もはやフォントを含まない。各フォントは、多数のアプリケーションで用いられる場合でも、一度しかフォントライブラリ３０内に記憶されない。示されている図においては、MHPモジュール２０、２１は、もはやクリップのMHPアプリケーションを走らせるのに必要とされるフォントを含まない。図２には、２つのクリップのアプリケーションが、フォントライブラリ３０からロードされるフォントを用いて走らされる２つの例示的なクリップが示されている。
【００３０】
図１１Ａは、MHPアプリケーションなどのアプリケーション２５１が、フォント２６０、２６１、２６２、２６３、２７０、２７１、２７２、２７３のうちの幾つかを用いる別のiTV記録構造を示している。アプリケーションは、ブロードキャストトランスポートストリーム(TS)２５０内に組み込まれるように示されているが、上記のようにアプリケーション２５１が別の通信チャネルを介してダウンロードされることもまた適用可能である。フォント２６０、２６１、２６２、２６３は、ブロードキャストTSで送信されるのに対して、フォント２７０、２７１、２７２、２７３は、別の場所に、例えばSTB内にデフォルトフォントとして記憶される。フォント２６０、２６１、２６２、２６３、２７０、２７１、２７２、２７３の数は、例示目的だけのために、４つに限定されている。この特別な場合には、アプリケーションモジュールは、それが走るのにどの１つ又は複数のフォントを必要とするかに関して別個のファイルにおいて情報を示さない。その代わりに、図１１Ａに図示されているように、フォントファイルに適用されるフォント名によるマッピングを与えるフォント索引ファイル２５２がブロードキャスト内に含まれる。更に、フォント索引ファイル２５２は、どの特定のアプリケーションがどの特定のフォントを用いるかは示さないが、アプリケーションが探しているフォントをSTBが見つけることを可能にする。MHPブロードキャストTSにおいては、フォント索引ファイル２５２は、通常、デフォルトフォントではないフォント、したがって、一般に、STB内に常駐しているデフォルトフォントとして利用可能でないフォントについての情報を含み、即ち、フォント索引ファイル２５２は、TS内に含まれているアプリケーション２５１が走るのに必要であるが、おそらく、TSを受け取るSTB内に既に記憶されているものとして利用可能ではないであろうフォントについての情報を含む。フォント索引ファイル２５２がアプリケーション２５１と一緒にダウンロードされる場合、フォント索引ファイル２５２は、一般に、そのアプリケーション２５１によって必要とされるフォントについての情報しか含まない。フォント索引ファイル２５２は、他のフォントについての情報も含み得るが、実際には、そうではないであろう。他方で、他のアプリケーション（図示せず）がブロードキャストされ、このアプリケーションがSTBのデフォルトフォントではない別のフォントを用いる場合、このアプリケーションは、該アプリケーションの新しいフォントをフォント索引ファイル２５２に付する。
【００３１】
斯くして、アプリケーション及びフォントを記録する場合に、どのフォントがアプリケーションと一緒に記録されるべきであるかということについての情報を取り出すことは不可能である。この情報は、アプリケーションが走らされる場合にフォント名としてしか与えられない。本発明の実施例によれば、上記のように、フォント索引ファイル２５２内にどのフォントが列挙されているか、実際にはブロードキャスト内及び各々の他の場所にどのフォントがあるかが対照される。フォント索引ファイル２５２内に列挙されており、アプリケーション２５１が記録されるべきである記憶媒体２８０上にまだ記憶されていないフォントファイルのみが、その記憶媒体２８０上に記録される。斯くして、あり得る記録が図１１Ｂに図示されている。フォント２６３及び２７３は、図１１Ａによるフォント索引ファイル２５２がこれらのフォントに対するマッピングを含まないことから記録されない。フォント２６０乃至２６２は記録される。この例においては、フォント２６０乃至２６２のいずれも、媒体２８０上により早くは記録されていない。更に、フォント２７０乃至２７２は、記憶媒体２８０が、デフォルトフォントとしてフォント２７０乃至２７２を有するSTBに対して再生されるであろうことが保証され得ない場合に、随意に記録されるので、フォント２７０乃至２７２は点線で図示されている。この例においては、フォントライブラリ２８１内には、フォント２６０乃至２６２が記憶され、随意に、フォント２７０乃至２７２が記憶される。記憶媒体２８０上のフォント索引ファイル２５３（図１１Ｂ参照）は、記憶媒体２８０上に記憶される新しいフォントについての情報を含む。フォント索引ファイル２５３が予め空になっている場合、即ち、フォントライブラリ２８１内にフォントがない場合には、フォント索引ファイル２５３は、TSからのフォント索引ファイル２５２のコンテンツのコピーを含む。フォントライブラリ２８１が予め空になっていない場合には、記憶媒体２８０上のフォント索引ファイル２５３に新しいフォントの情報が付加される。MHP規格に従う構造を持つTS内のフォント索引ファイル２５２の例においては、記憶媒体２８０上のフォント索引ファイル２５３も、MHPによって規定されるフォント索引の同じシンタックスに従う。フォント索引ファイル２５３は、一般に、記憶媒体２８０上に記憶される全てのフォントについての情報を含む。具体的に言えば、記憶媒体２８０上に新しいフォントが記憶されるたびに、これらの新しいフォントに関する情報が、フォント索引ファイル２５３に付加される。上記の場合であって、ブロードキャストTS２５０内の他のアプリケーション（図示せず）が該他のアプリケ―ションのフォントをフォント索引ファイル２５２に付している場合には、フォント索引ファイル２５３は、両アプリケーション及び該両アプリケーションのフォントが記憶媒体２８０上に記憶される場合に、両アプリケーションのためのフォントについての情報を含むであろう。
【００３２】
図４に従う本発明の別の実施例には、iTVアプリケーションモジュール４０を記録する方法４９が図示されている。モジュール４０は、アプリケーションを走らせるのに必要とされるフォントを有する。ステップ４１において、アプリケーションモジュール４０は、モジュール内に含まれるフォントについて解析される。更に、ステップ４２において、フォント情報、即ち、アプリケーションを走らせるのにどのフォントファイルが必要とされるかということついての情報が、アプリケーションモジュール４０から取り出される。その後、ステップ４３において、ステップ４２において取り出された情報によって示されるフォントが既に記憶媒体上に記憶されているかどうかが調べられる。この実施例においては、フォントは、記憶媒体上のフォントライブラリ内に記憶される。斯くして、アプリケーションモジュール４０によって必要とされるフォントが、フォントライブラリ内に既に存在し、記憶されている場合には、前記フォントはステップ４４において廃棄される。その他の場合には、即ち、アプリケーションによって必要とされるフォントが、まだフォントライブラリに記憶されていない新たなフォントとして識別される場合には、新たなフォントはステップ４５においてフォントライブラリ内に記憶される。その後、ステップ４６において、フォントライブラリのフォント情報ファイルが、例えば、フォントファイル名及びディレクトリ名を示すことによって、記憶媒体上のどこで、即ち、この場合には、フォントライブラリ内のどこで、アプリケーションを走らせるのに必要とされるフォントが見つけられるかということについての情報を有するように、フォント情報ファイルが修正される。最後に、アプリケーションモジュール、即ち、アプリケーションプログラムと、該アプリケーションプログラムを走らせるのに必要とされるフォントファイル以外の他のファイルとがステップ４７において記憶され、アプリケーションの記録が終了される。
【００３３】
MHP規格においては、MHPアプリケーションによるフォントライブラリの場所が規定されていることに注意されたい。アプリケーションは、アプリケーションが使用し得るフォントについてのフォント情報ファイルを供給する。記憶媒体中に記憶されるフォント情報ファイルは、記憶媒体中に記憶される全てのフォントを記述するために用いられる。好ましくは、その構造は、アプリケーションモジュール内のものと同じである。ブロードキャストストリーム内のものとはコンテンツ及びサイズしか異ならない。
【００３４】
記録されたアプリケーションモジュールをより後の時点に記憶媒体から再生する場合、アプリケーションモジュールは、アプリケーションプログラムを走らせるのにどのフォントが必要とされるかを示す。この場合には、必要とされるフォントがフォントライブラリ内のどこにあるのか、及び／又は必要とされるフォントがデフォルトフォントであるかどうかが調べられる。
【００３５】
もはや用いられないフォントは、この特定のフォントを必要とする全てのアプリケーションの記録が記憶媒体から消去される場合に、消去されることが出来、斯くして、このフォントの記憶空間を他の目的のために利用可能にする。
【００３６】
本発明の別の実施例においては、ステップ４４は、記憶媒体上のフォントライブラリ内の記憶フォントが、受け取られるiTVアプリケーションモジュール内のフォントに置き換えられるステップに取って代わられる。
【００３７】
本発明の他の実施例が図５に図示されている。図５は、記録型DVDなどの記録可能な記憶媒体上に記憶されたiTVアプリケーションモジュール５０の再生の場合を図示している。方法５５のステップ５１においては、どのフォントが必要とされるかということについての情報がアプリケーションから取り出される／抜き出される。この情報は、例えば、上記のように、MHP情報ファイル内に記憶されることが出来る。このフォントは、ステップ５２においてロードされ、ステップ５４においてアプリケーションモジュールとマージされる。その後、ステップ５３において、アプリケーションが、ステップ５１においてフォントライブラリから取り出される必要とされるフォントを用いて走らされる。
【００３８】
図６Ａ及び６Ｂには、本発明の実施例のフォントライブラリの構造の別の例が示されている。図６Ａには、フォントディレクトリ６０内の単一のファイル６９内にフォント６２、６３、６４が記憶される構造が記載されている。フォント索引６１もまた、フォントファイル６９の一部である。ファイル６９のコンテンツは、ひとつながりのブロードキャスト(broadcast concatenated)からのフォントファイルによって構築される。幾つかのファイルシステムにとってそうであるファイルの数の増大が問題となる場合に単一のファイルは有利である。
【００３９】
図６Ｂによれば、フォントファイル６６、６７、６８は、別個の個々のファイル内に記憶され、フォント索引は、記憶されたフォントをどこで取り出すべきかということについての情報を有する。好ましくは、フォント索引は、図７に従うフォントについての付加的な情報を有する。
【００４０】
どちらの場合にも、フォントは、好ましくは、ブロードキャストのために用いられるのと同じ形式で記憶される。しかしながら、フォントファイルを適切に圧縮することによって、使用記憶空間の更なる最小化が達成され得る。
【００４１】
図７は、本発明の実施例のフォント索引７０の好ましい構造を示している。フォントライブラリからのフォントを必要とする全てのアプリケーションのために、フォントがフォントラブラリ内のどこに位置しているのかが調査される必要がある。調査のために、フォントの言語、フォント名、フォントのタイプ、フォントライブラリのサイズ及びフォント・アドレスについての情報を有するフォント索引の構造が規定される。フォント・アドレスは、フォントが記憶媒体上のどこにあるのかを示す。フォントライブラリが単一のファイル内に記憶される場合には、このアドレス情報は、フォントファイル内のオフセットとして規定される。各フォントが別個のファイル内に記憶される場合には、パスを含むファイル名が記憶される。プログラムのために用いられる言語は、ブロードキャストストリームから得られ得るので、所与の例においては、このプログラムにリンクされるアプリケーションもまたこの言語を用いることが保証される。表形式のフォント索引（下記参照）は、まず、言語についてサーチされ、これは、サーチ速度を固定する。例えば、プログラムの言語が中国語と知られている場合には、フォント名を比較することによってフォントの所在を突き止めるために直に中国語の表に行く。以下の表にはフォント索引付け構造の例が与えられている。
【００４２】
【表１】
2006510299.tif 000003
【００４３】
一例として、他の言語のためのリストは空である。
【００４４】
図８は、本発明の好ましい実施例によるiTV記録装置２００の概略図を示している。装置２００は、フォント処理装置２０１を有し、ここで、ダウンロードされる双方向テレビアプリケーションの一部であるフォントは、前記フォント処理装置の使用中には、記録可能な記憶媒体上に記憶されている。フォントは、アプリケーションとは別に、前記記録可能な記憶媒体上のフォントライブラリ内に記憶され、各フォントは、多数のアプリケーションが同じフォントを必要とする場合でも、本発明に基づいて１つのコピーでしか記憶されない。
【００４５】
図９は、本発明の別の好ましい実施例によるコンピュータ読取り可能な媒体２１０の概略図を示している。コンピュータ読取り可能な媒体２１０は、コンピュータ２１２によって処理するためのコンピュータプログラム２１１を有する。コンピュータプログラム２１１は、双方向テレビアプリケーションからのダウンロードされるフォントを記憶媒体上に記憶するためのコードセグメントを有し、コードセグメントは、異なるフォントの１つのコピーしか前記フォントライブラリ内に記憶しないようコンピュータ２１２に命令する。
【００４６】
図１０は、本発明の他の好ましい実施例による記憶媒体２２０の概略図である。双方向テレビの記憶のための記憶媒体２２０は、該媒体２２０上に記録される少なくとも２つのアプリケーション２２１を有する。アプリケーションは、該アプリケーションを走らせるのに必要とされるフォントと別に記憶される。記憶媒体２２０は、フォントライブラリ２２２を更に有する。フォントライブラリ２２２はフォントを有し、フォントライブラリは、記憶媒体２２０上に記憶される全てのアプリケーション２２１を走らせるのに必要とされるフォントの各々の２つ以上のコピーを有さない。斯くして、実際には、記憶媒体上に記憶されるフォントの数は劇的に減らされる。
【００４７】
上記では、本発明は、特定の実施例に関して記載されている。しかしながら、上記の好ましい実施例以外の実施例、例えば、上記のものと異なるフォント記憶方法、上記のものと異なるファイル記憶構造、ブロードキャストストリーム、多数のアプリケーション若しくはフォントと共にアプリケーションを伝送する異なるやり方、ハードウェア若しくはソフトウェアによって上記の方法を実施する異なるやり方、又はフォントの代わりにグリフを用いる異なるやり方、MHP、OpenTV、デジタルテレビアプリケーションソフトウェア環境（DASE）などの任意の形式の双方向TVにおいて実施される異なるやり方、又はDVD、SFFO(Small Form Factor Optical Storage)などといった別の記憶媒体を用いる異なるやり方も、同様に、添付されている特許請求の範囲内であり得る。更に、１つのアプリケーションが複数のフォントを用いてもよい。本発明によれば、この複数のフォントの１つ１つの２つ以上のコピーは記憶媒体上に記憶されない。
【００４８】
更に、「有する」という用語は、他の要素又はステップを除外せず、単数形表記は、複数性を除外せず、単一のプロセッサ又は他のユニットは、特許請求の範囲に列挙されているユニット又は回路の幾つかの機能を実現し得る。
【００４９】
本出願は、双方向テレビのための記録装置又は再生・記録装置においてフォントを処理する方法（４９、５５）と要約され得る。フォントは、記録可能な記憶媒体（２２０）上に記憶され、ここで、フォントは、ダウンロードされる双方向テレビアプリケーションの一部である。記録する場合、ダウンロードされるフォントは、アプリケーションとは別に、好ましくは記録可能な記憶媒体上のフォントライブラリ内に記憶され、前記記録可能な記憶媒体は、好ましくは、取り外し可能な媒体、好ましくは光学的な記憶媒体である。各フォントは、記憶媒体上の複数のアプリケーションが走るのにそのフォントを必要とする場合でも、１つのコピーでしか記憶されない。記憶媒体からアプリケーションを再生する場合、フォントライブラリ内の記憶媒体からのどのフォントが該記憶媒体からの前記アプリケーションの再生のために必要とされるかということについての表示情報が供給される。斯くして、フォントの多重記憶が防止され、記憶媒体における所要記憶空間を最小限にする。
【図面の簡単な説明】
【００５０】
【図１Ａ】記録されるべきiTVの構造の概略図を示す。
【図１Ｂ】本発明の実施例によるフォントライブラリを含む図１Ａの構造のiTVの記録の概略図を示す。
【図２Ａ】記録されるべきiTVの構造の概略図を示す。
【図２Ｂ】本発明の実施例によるフォントライブラリを含む図２Ａの構造のiTVの記録の概略図を示す。
【図３Ａ】記録されるべきiTVの構造の概略図を示す。
【図３Ｂ】本発明の実施例によるフォントライブラリを含む図３Ａの構造のiTVの記録の概略図を示す。
【図４】本発明の実施例による双方向テレビアプリケーションの記録をフローチャートで図示する。
【図５】本発明の実施例による双方向テレビアプリケーションの再生のフローチャートを示す。
【図６Ａ】本発明の実施例のフォントライブラリの構造の別の例の概略図である。
【図６Ｂ】本発明の実施例のフォントライブラリの構造の別の例の概略図である。
【図７】本発明の実施例の例示的なフォント索引の構造を概略図で図示する。
【図８】本発明の好ましい実施例によるiTV記録装置の概略図を示す。
【図９】本発明の別の好ましい実施例によるコンピュータ読取り可能な媒体の概略図を示す。
【図１０】本発明の他の好ましい実施例による記憶媒体の概略図を示す。
【図１１Ａ】記録されるべきiTVの構造の概略図を示す。
【図１１Ｂ】本発明の実施例によるフォントライブラリを含む図１１Ａの構造のiTVの記録の概略図を示す。
2006510299.tif 000004
2006510299.tif 000005
【図３Ａ】
2006510299.tif 000006
【図３Ｂ】
2006510299.tif 000007
【図４】
2006510299.tif 000008
【図５】
2006510299.tif 000009
【図６Ａ】
2006510299.tif 000010
【図６Ｂ】
2006510299.tif 000011
【図７】
2006510299.tif 000012
【図８】
2006510299.tif 000013
【図９】
2006510299.tif 000014
【図１０】
2006510299.tif 000015
2006510299.tif 000016
【国際調査報告】
2006510299.tif 000017
2006510299.tif 000018
2006510299.tif 000019