(57)【特許請求の範囲】
【請求項１】
配信コンテンツを生成する方法であって、
配信コンテンツを構成するモジュールの１つとして作成された複数の文字又は文字列からなるスクリプトの内部を検索して、冗長性の高い文字列からなる要素を抽出し、抽出された各要素についてのスクリプト中での出現頻度を積算し、出現頻度の大きい文字又は文字列ほどより文字数の短い文字又は文字列からなる適用文字を割り当てて、要素と適用文字との対応関係を対応表に保存する対応表登録ステップと、
スクリプト中の各センテンスに存在する前記対応表に保存されている要素を対応する適用文字で置き換えるスクリプト置換処理ステップと、
スクリプトの内部が前記スクリプト置換処理ステップにより要素が対応する適用文字に置換された後のモジュールからなるコンテンツを生成後の配信コンテンツとして出力するステップと、
を含むことを特徴とする配信コンテンツ生成方法。
【請求項２】
置換後の配信コンテンツを配信する前に一時蓄積するステップを含むことを特徴とする請求項１に記載の配信コンテンツ生成方法。
【請求項３】
前記の冗長性の高い文字又は文字列は関数名や変数名を含むことを特徴とする請求項１に記載の配信コンテンツ生成方法。
【請求項４】
前記の冗長性の高い文字又は文字列を冗長性の低い文字又は文字列で置き換えるステップでは、冗長性の低い文字列としてのシステム予約語の使用を排除することを特徴とする請求項１に記載の配信コンテンツ生成方法。
【請求項５】
さらに、配信コンテンツの受信側で実行される処理に関与しない文字又は文字列からなる文を抽出するステップと、該抽出された文を削除するステップとを含むことを特徴とする請求項１に記載の配信コンテンツ生成方法。
【請求項６】
前記の配信コンテンツの受信側で実行される処理に関与しない文字又は文字列からなる文は、所定のデリミッタで区切られたコメント文であることを特徴とする請求項５に記載の配信コンテンツ生成方法。
【請求項７】
複数のデータ・モジュールで構成されるコンテンツを配信するコンテンツ配信方法であって、
複数の文字又は文字列からなるスクリプト言語形式で記述されたデータ・モジュールの内部を検索して、冗長性の高い文字列からなる要素を抽出し、抽出された各要素についてのスクリプト中での出現頻度を積算し、出現頻度の大きい文字又は文字列ほどより文字数の短い文字又は文字列からなる適用文字を割り当てて、要素と適用文字との対応関係を対応表に保存する対応表登録ステップと、
スクリプト中の各センテンスに存在する前記対応表に保存されている要素を対応する適用文字で置き換えるステップと、
置換後のデータ・モジュールを蓄積するステップと、
蓄積されたデータ・モジュールを配信するステップと、
を含むことを特徴とするコンテンツ配信方法。
【請求項８】
複数のデータ・モジュールで構成されるコンテンツを配信するコンテンツ配信装置であって、
複数の文字又は文字列からなるスクリプト言語形式で記述されたデータ・モジュールの内部を検索して、冗長性の高い文字列からなる要素を抽出し、抽出された各要素についてのスクリプト中での出現頻度を積算し、出現頻度の大きい文字又は文字列ほどより文字数の短い文字又は文字列からなる適用文字を割り当てて、要素と適用文字との対応関係を対応表に保存する対応表登録手段と、
スクリプト中の各センテンスに存在する前記対応表に保存されている要素を対応する適用文字で置き換える手段と、
置換後のデータ・モジュールを蓄積する手段と、
蓄積されたデータ・モジュールを配信する手段と、
を含むことを特徴とするコンテンツ配信装置。
【請求項９】
前記の冗長性の高い文字又は文字列は関数名や変数名を含むことを特徴とする請求項８に記載のコンテンツ配信装置。
【請求項１０】
前記の冗長性の高い文字又は文字列を冗長性の低い文字又は文字列で置き換える手段は、冗長性の低い文字列としてのシステム予約語の使用を排除することを特徴とする請求項８に記載のコンテンツ配信装置。
【請求項１１】
さらに、配信コンテンツの受信側で実行される処理に関与しない文字又は文字列からなる文を抽出する手段と、該抽出された文を削除する手段とを含むことを特徴とする請求項８に記載のコンテンツ配信装置。
【請求項１２】
前記の配信コンテンツの受信側で実行される処理に関与しない文字又は文字列からなる文は、所定のデリミッタで区切られたコメント文であることを特徴とする請求項１１に記載のコンテンツ配信装置。
【請求項１３】
コンピュータ処理に関する意味を持つ複数の文字又は文字列で構成されるソース・コードを変換する方法であって、
ソース・コード中を検索して、冗長性の高い文字列からなる要素を抽出し、抽出された各要素についてのスクリプト中での出現頻度を積算し、出現頻度の大きい文字又は文字列ほどより文字数の短い文字又は文字列からなる適用文字を割り当てて、要素と適用文字との対応関係を対応表に保存する対応表登録ステップと、
ソース・コード中の各センテンスに存在する前記対応表に保存されている要素を対応する適用文字で置き換えるステップと、
ソース・コードの内部が前記スクリプト置換処理ステップにより要素が対応する適用文字に置換された後のソース・コードを変換後のソース・コードとして出力するステップと、
を含むことを特徴とするコード変換方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、衛星デジタル放送やマルチメディア・コンテンツの通信など、デジタル・データ配信技術に係り、特に、コンピュータ言語の命令で構成されるデジタル・データを配信する技術に関する。
【０００２】
更に詳しくは、本発明は、任意に定義可能なタグを使用するマークアップ言語（例えば、ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ））形式のデジタル・データを配信するデジタル・データ配信技術に係り、特に、いわゆるスクリプトなどのテキスト・データからなる配信コンテンツの伝送効率と受信側での実行効率を向上するデジタル・データ配信に関する。
【０００３】
【従来の技術】
放送の技術分野において、データのデジタル化が急速に進められている。デジタル信号の方が、アナログ信号よりも安定性に優れ、データ圧縮率も高い。また、デジタル信号は、ケーブル、地上波、衛星波を問わず、一定の帯域でアナログ信号よりも多くのチャンネルを確保することができる。また、従来の情報伝達においては文書、音声、映像の各情報は全く別物であったが、放送データをデジタル化することにより分け隔てなく伝送することができる。
【０００４】
例えば、デジタル・データであれば、ＥＰＧ（Ｅｌｅｃｔｒｉｃ  Ｐｒｏｇｒａｍ  Ｇｕｉｄｅ：電子番組ガイド）など各種のシステム情報等を映像情報や音声情報とともに送ることによって、ユーザ（視聴者）へのサービスを向上させることができる（ＥＰＧは、放送番組の放送スケジュールや番組名などの提示情報の他、ＶＴＲへの録画予約などの機能を包含する）。
【０００５】
デジタル形式のデータは、汎用コンピュータ・システムなどテレビジョン以外の情報機器との親和性も高い。例えば、汎用コンピュータ・システムに衛星放送用チューナ・カードを取り付けて、受信したＥＰＧデータをコンピュータ内で解析して、番組表をコンピュータ・ディスプレイ上にウィンドウ表示して、番組切換や録画予約などをマウス・カーソルによる操作で実現することができる。勿論、放送データをコンピュータの内蔵ハード・ディスクにそのままデジタル録画することも可能である。
【０００６】
また、帯域を活用して、映像や音声などの放送番組本体以外のデータを送信することにより、放送番組の対話性を高めることができる。例えば、択一式のクイズを提供するような放送番組であれば、映像・音声データとともに解答を併せて送信することにより、衛星テレビ放送受信機（すなわち視聴者）側では、コンピュータ・ディスプレイ上に解答メニュー・ボタンを用意し、マウス・カーソルなどのポインティング・デバイスによる解答操作に応答して答合わせを行うことができる。
【０００７】
さらに対話性が高まれば、家庭内のテレビ受信機は、単に映像コンテンツを扱うだけでなく情報管制塔として飛躍することが期待できる。例えば、テレビ受信機は、インターネット端末や電子商取引端末にもなり得る。
【０００８】
日本では、ＡＲＩＢ（電波産業会）が中心となって、デジタル衛星データ放送に関する標準化作業が進められている。これによれば、デジタル衛星データ放送では、衛星放送番組本体を構成する映像と音声のデータ（ＡＶデータ）の他に、放送番組に付随するデジタル伝送データが並行して配信される。より具体的には、ＭＰＥＧ（Ｍｏｔｉｏｎ  Ｐｉｃｔｕｒｅ  Ｅｘｐｅｒｔｓ  Ｇｒｏｕｐ）２など所定の圧縮方式で圧縮されたＡＶデータと、デジタル伝送データとを多重化して構成される「トランスポート・ストリーム」（後述）の形式で、放送波として伝播される。
【０００９】
デジタル伝送データに載せられる放送番組情報の一例は、先述のＥＰＧ（Ｅｌｅｃｔｒｉｃ  Ｐｒｏｇｒａｍ  Ｇｕｉｄｅ：電子番組情報）である。また、放送番組情報は、放送番組本体のタイトルや日付、番組のキャスティングなど放送番組本体に関する固有の情報を含むことができる。また、放送番組情報が含むデータの種類やデータ構造は、番組本体が提供するサービス内容に応じてある程度系統化される。例えば、料理番組における献立や食材に関する情報や、選挙速報番組における時々刻々更新される得票状況、プロ野球中継における各選手の打撃・投球に関する個人成績やチーム順位などである。
【００１０】
放送番組情報は、デジタル衛星データ放送受信システム（以下、単に「受信システム」とする）側では、放送番組本体を表示出力するディスプレイ・スクリーンの一部の領域を使用して表示される。この受信システムは、通常は、放送波を受信・選局・デコードする受信機（セット・トップ・ボックス：ＳＴＢ）と、表示出力するテレビジョンとで構成され、一般家庭内に設置される。
【００１１】
ここで、デジタル伝送データとして配信されるコンテンツ（以下、「配信コンテンツ」とする）の構造について、図１３を参照しながら説明しておく。
【００１２】
図１３に示すように、配信コンテンツは、テキスト・データの他、静止画、動画、音声などの各種様々なモノメディア・データと、これら各々のモノメディア・データを統合的すなわちマルチメディアとして取り扱い、放送番組情報の有様を規定する表示・出力制御プログラム（以下では、「マルチメディア符号化アプリケーション」とも呼ぶ）とで構成される。表示・出力制御プログラムには、各モノメディア・データに対する参照（リンク）情報を組み込むことができる。
【００１３】
先述したＡＲＩＢによるデジタル衛星データ放送の標準化作業では、この配信コンテンツとしてのマルチメディア符号化アプリケーションを記述する形式（フォーマット）として、当初はＭＨＥＧ（Ｍｕｌｔｉｍｅｄｉａ  ａｎｄ  Ｈｙｐｅｒｍｅｄｉａ  Ｅｘｐｅｒｔ  Ｇｒｏｕｐ）の利用が検討されてきた。ＭＨＥＧは、データ属性を定義する記述言語の一種であり、マルチメディア・コンテンツをテレビに表示し、ビデオ・オン・デマンド（ＶＯＤ）やデジタル・テレビ放送において視聴者が所望の情報を引き出すような用途を想定している。日本のＣＳデジタル放送（ＳＫＹＰｅｒｆｅｃＴＶ）のように、既にＭＨＥＧ−５が使用されている例もある。
【００１４】
しかしながら、ＭＨＥＧは、符号化空間が固定的であり拡張性に欠ける。すなわち、一意に定められた符号化空間のみを用いて記述しなければならないので、例えば関数（ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍｍｉｎｇ  Ｉｎｔｅｒｆａｃｅ）など）を一つ変更するのにさえ、相当の修正作業を要する。また、ＭＨＥＧは、一般的な認知度が低く、ＭＨＥＧで記述されたデータ・コンテンツがあまり流通しておらず、この意味において汎用コンピュータとの親和性が比較的低い。
【００１５】
そこで、ＡＲＩＢ（先述）では、ＭＨＥＧに代わって、ＸＭＬ（ｅＸｔｅｎｄｅｄ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）をベースとしたデータ放送の標準化作業が検討されている。
【００１６】
ＸＭＬは、タグの定義が任意、すなわち属性の記述の仕方に制約がないので、自由度が高く、また、汎用コンピュータやインターネットとの親和性が高いことなどが、ＭＨＥＧよりも有利な点として挙げられる。また、ＸＭＬは、次世代インターネットの記述言語としての策定も進められている。
【００１７】
ＸＭＬをデジタル衛星放送の標準言語で用いた場合、デジタル放送用データを、コンピュータやテレビジョン、電話機など、多種多様な情報機器間で情報交換を行うことができる。また、ＸＭＬは、タグの属性を任意に定義できることから、レイアウト指定に特化したＨＴＭＬに比しデータ処理に強い。このため、電子商取引を含め、各分野への利用も急速に進みつつある。
【００１８】
ＸＭＬ文書において任意なタグの設定が許容することは、言い換えれば、文書中に書かれた文字列を意味の付けられたデータとして扱うことを目的とするものである。すなわち、タグの定義により、タグで区切られた各タグ・データを、単なる表示目的以外の意味を持ったデータとして表現することができる。さらに、タグの構造を定義することで、ＸＭＬ文書又は該文書中のデータを構造化して記述することが可能となる。
【００１９】
既に述べたように、ＡＲＩＢでは、ＸＭＬをベースにしてデジタル衛星データ放送の標準化を進めている。より具体的には、「基本ＸＭＬ」と、基本ＸＭＬの拡張版である「高度ＸＭＬ」に分けて、作業が行われている。基本ＸＭＬは、ＸＭＬインスタンスをディスプレイ上に表現するプレゼンテーション形式を、タグを用いて記述することを規定したものである。
【００２０】
これに対し、高度ＸＭＬは、ＸＭＬインスタンスの属性情報を付加できるようにしたものである。属性情報の記述方法（すなわちタグの文法）を定めたものが、ＤＴＤ（Ｄｏｃｕｍｅｎｔ  Ｔｙｐｅ  Ｄｅｆｉｎｉｔｉｏｎ）と呼ばれる規約である。基本ＸＭＬではタグが定義する属性情報は固定で、ＤＴＤは不要である。これに対し、高度ＸＭＬでは、ＤＴＤは任意に定義可能であり、例えば各業界毎にＤＴＤを一意に定めることができる。ここで言うタグの属性情報には、例えばテレビ受信機とコンピュータのように異機種間で接続したときに、各機器が互いにコンテンツの意味を理解して処理するために必要な情報などが含まれる。
【００２１】
ＸＭＬインスタンス自体は、表現形式に関するスタイル情報を包含していないこともある。この場合、ＸＭＬインスタンスの表現方法は、ＤＴＤとは別の文書ファイルである「スタイルシート」によって記述される。
【００２２】
スタイルシートは、例えば、ＸＭＬインスタンスをディスプレイ・スクリーン上に表示出力する形式に変換する（あるいはプリンタへの印刷出力形式に変換する）ための文書ファイルである。ＸＭＬインスタンス用のスタイルシートは、特に「ＸＳＬ（ｅＸｔｅｎｓｉｂｌｅ  Ｓｔｙｌｅｓｈｅｅｔ  Ｌａｎｇｕａｇｅ）」形式の言語、「ＣＳＳ（Ｃａｓｃａｄｅ  Ｓｔｙｌｅｓｈｅｅｔ）」形式の言語、あるいは、その派生規格である「ＸＳＬＴ（ＸＳＬ  Ｔｒａｎｓｆｏｒｍａｔｉｏｎ）」形式の言語を用いて記述することかできる。スタイルシートの記述次第で、書体やそのサイズ・色などを変化させて、同じＤＴＤコンテンツを全く別の形式で表現することができる。スタイルシートは、ＤＴＤとは別のファイルにして送信される。
【００２３】
なお、スタイルシートの他に、音声や静止画、動画など各モノメディアからなるマルチメディア・コンテンツに関しては、ＸＭＬインスタンス又はスタイルシート内で、ＸＭＬやＸＳＬとは別のスクリプトと呼ばれる言語によって動作を規定することもできる。このようなスクリプトは、例えばＪａｖａＳｃｒｉｐｔ，ＥＣＭＡＳｃｒｉｐｔ，Ｊｓｃｒｉｐｔなどのスクリプト言語で記述されるが、ＸＭＬ及びＸＳＬ等の規格では、基本的にはＥＣＭＡＳｃｒｉｐｔで記述するように規定されている（”ＥＣＭＡＳｃｒｉｐｔ”は、欧州電子計算機工業会（ＥＣＭＡ）が規格化したスクリプト言語である）。
【００２４】
ＸＭＬ文書からなる配信コンテンツは、ＸＭＬ文書の他に、例えばＤＴＤ文書とスタイルシートを伴なう。但し、ＸＭＬ文書がＤＴＤ文書を含まれない場合や、ＸＭＬ文書の配信とは異なるタイミングでスタイルシートが送付されることもある。また、配信コンテンツの記述言語は、必ずしもＸＭＬには限定されず、ＳＧＭＬ（Ｓｔａｎｄａｒｄ  Ｇｅｎｅｒａｌｉｚｅｄ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）やＨＴＭＬなど、その他のマークアップ言語形式であってもよい。また、例えばＸＭＬ文書がＴＶ放送に適用され、他のリアルタイム型のデータとともに動作してプレゼンテーションを行う場合には、各種のモノメディア・コンテンツのＵＲＩ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｎｔｉｆｉｅｒ）と呼ばれる放送データ・モジュール内のモノメディア位置情報も、ＸＭＬ文書本体に組み込まれることもある。
【００２５】
受信システム側では、受信したＸＭＬインスタンスを「ＸＭＬパーザ（Ｐｅｒｓｅｒ）」と呼ばれる構文解析プログラムでパージング処理する。すなわち、ＸＭＬパーザは、ＤＴＤ文書及びＸＭＬインスタンスを構造解析して、文書オブジェクトを出力する。この文書オブジェクトは、元のＸＭＬ文書中のタグに従って木構造が形成された構造化文書である。受信システムの表示機能は、この文書の構造を解釈することで、画面上のレイアウト等を決定し、ディスプレイへの表示出力が可能となる。
【００２６】
ところで、デジタル・データを放送やネットワーク通信などの伝送手段で配信する場合、ＸＭＬ文書やスクリプトなどのデータ・コンテンツを、元のテキスト形式からバイナリ（２進表示）形式の記述にデータ圧縮してから送信することも考えられる。
【００２７】
しかしながら、バイナリ形式のファイル構造は、コンピュータ・システムやソフトによって異なるため、アプリケーションや端末間でのコンテンツ交換の障害になりかねない。また、デジタル衛星データ放送の上り回線として、ＴＣＰ／ＩＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）ベースで接続されるインターネットも想定している。このインターネットでは、テキスト形式のコンテンツ配信を採用することで、端末の種類やソフトウエアに依存しない環境が築き上げられてきたという歴史的経緯がある。
【００２８】
そこで、デジタル衛星データ放送においては、インターネットとの親和性やプラットフォーム間のコンテンツ互換性を勘案し、テキスト形式のままデータ・コンテンツを配信することが検討されている。
【００２９】
ここで問題となるのが、配信コンテンツとしてのテキスト・データのサイズである。何故ならば、データ・サイズに比例して、伝送路の負荷が増大し、伝送効率が低下するからである。
【００３０】
例えば、ＸＭＬ文書の高機能化又は高付加価値化が進むにつれ、その表現形式や動作を規定するスクリプトの文書サイズは肥大化する。今後、スクリプトが表示対象そのものであるＸＭＬ文書本体よりもデータ・サイズが大きくなることも予想される。肥大化したスクリプトの配信は、有限な帯域の負荷に与える影響は大きい。
【００３１】
また、配信コンテンツを受信する受信装置においても、膨大なデータを受信するには大容量のバッファ・メモリを用意する必要があり、コスト増大を招来する。また、メモリ・ロードに要する時間も長くなるため実行効率が低下してしまう。
【００３２】
受信システムとして汎用コンピュータ・システムを用いる場合、通常、大容量のメモリを標準で搭載しているので、メモリ負荷の問題は比較的小さい。これに対し、セット・トップ・ボックスのような専用の衛星放送受信機の場合、標準メモリのサイズは一般に小さいので、大容量の配信コンテンツは致命的である。
【００３３】
【発明が解決しようとする課題】
本発明の目的は、テキスト・データからなるコンテンツ配信の伝送効率を向上することができる、優れたデータ配信技術を提供することにある。
【００３４】
本発明の更なる目的は、テキスト・データからなる配信コンテンツを受信する受信装置における実行効率を向上するとともに、メモリ負荷を低減することができる、優れたデータ配信技術を提供することにある。
【００３５】
【課題を解決するための手段】
本発明は、上記課題を参酌してなされたものであり、その第１の側面は、配信コンテンツを生成する方法であって、
配信コンテンツを構成するモジュールの１つとして作成された複数の文字又は文字列からなるスクリプトの内部を検索して、冗長性の高い文字又は文字列を抽出するステップと、
スクリプト中で抽出された冗長性の高い文字又は文字列を冗長性の低い文字又は文字列で置き換えるステップと、
を含むことを特徴とする配信コンテンツ生成方法である。前記の冗長性の高い文字又は文字列は、例えば、関数名や変数名などに相当する。
【００３６】
本発明の第１の側面に係る配信コンテンツ生成方法は、さらに、置換後の配信コンテンツを配信する前に一時蓄積するステップを含んでもよい。
【００３７】
また、前記の冗長性の高い文字又は文字列を冗長性の低い文字又は文字列で置き換えるステップでは、冗長性の低い文字列としてのシステム予約語の使用を排除するようにしてもよい。システム予約語まで抽出し且つ他の文字又は文字列に置き換えてしまうと、元のスクリプトが本来持つ意味、すなわちスクリプトが規定する動作内容の変更を伴うことになり、許容し難いからである。
【００３８】
また、該配信コンテンツ生成方法は、さらに、配信コンテンツの受信側で実行される処理に関与しない文字又は文字列からなる文を抽出するステップと、該抽出された文を削除するステップとを含んでもよい。ここで言う処理に関与しない文字又は文字列からなる文は、例えば、所定のデリミッタで区切られたコメント文に相当する。
【００３９】
また、該配信コンテンツ生成方法は、さらに、前記の冗長性の高い文字又は文字列を抽出するステップで抽出された文字又は文字列の各々についてのスクリプト中での出現頻度を積算するステップを含み、
前記の冗長性の高い文字又は文字列を冗長性の低い文字又は文字列に置き換えるステップでは、出現頻度の大きい文字又は文字列ほどより文字数の短い文字又は文字列に置き換えるようにしてもよい。出現頻度の大きいものほど、より短い文字又は文字列で表現されるので、データ圧縮の効果が高まる。
【００４０】
また、本発明の第２の側面は、複数のデータ・モジュールで構成されるコンテンツを配信するコンテンツ配信方法又は装置であって、
複数の文字又は文字列からなるスクリプト言語形式で記述されたデータ・モジュールの内部を検索して、冗長性の高い文字又は文字列を抽出するステップ又は手段と、
スクリプト中で抽出された冗長性の高い文字又は文字列を冗長性の低い文字又は文字列で置き換えるステップ又は手段と、
置換後のデータ・モジュールを蓄積するステップ又は手段と、
蓄積されたデータ・モジュールを配信するステップ又は手段と、
を含むことを特徴とするコンテンツ配信方法又は装置である。ここで言う冗長性の高い文字又は文字列とは、例えば、関数名や変数名に相当する。
【００４１】
また、前記の冗長性の高い文字又は文字列を冗長性の低い文字又は文字列で置き換えるステップ又は手段は、冗長性の低い文字列としてのシステム予約語の使用を排除するようにしてもよい。システム予約語まで抽出し且つ他の文字又は文字列に置き換えてしまうと、元のスクリプトが本来持つ意味、すなわちスクリプトが規定する動作内容の変更を伴うことになり、許容し難いからである。
【００４２】
また、本発明の第２の側面に係るコンテンツ配信方法又は装置は、さらに、配信コンテンツの受信側で実行される処理に関与しない文字又は文字列からなる文を抽出するステップ又は手段と、該抽出された文を削除するステップ又は手段を含んでもよい。ここで言う処理に関与しない文字又は文字列からなる文は、所定のデリミッタで区切られたコメント文に相当する。
【００４３】
また、本発明の第２の側面に係るコンテンツ配信方法又は装置は、さらに、前記の冗長性の高い文字又は文字列を抽出するステップで抽出された文字又は文字列の各々についてのスクリプト中での出現頻度を積算するステップ又は手段を含み、
前記の冗長性の高い文字又は文字列を冗長性の低い文字又は文字列に置き換えるステップ又は手段は、出現頻度の大きい文字又は文字列ほどより文字数の短い文字又は文字列に置き換えるようにしてもよい。出現頻度の大きいものほど、より短い文字又は文字列で表現されるので、データ圧縮の効果が高まる。
【００４４】
また、本発明の第３の側面は、コンピュータ処理に関する意味を持つ複数の文字又は文字列で構成されるソース・コードを変換する方法であって、
ソース・コード中を検索して、冗長性の高い文字又は文字列を抽出するステップと、
抽出された冗長性の高い文字又は文字列を冗長性の低い文字又は文字列で置き換えるステップと、
を含むことを特徴とするコード変換方法である。ここで言う冗長性の高い文字列とは、例えば、関数名や変数名に相当する。
【００４５】
本発明の第３の側面に係るコード変換方法において、前記の冗長性の高い文字又は文字列を冗長性の低い文字又は文字列で置き換えるステップでは、冗長性の低い文字列としてのシステム予約語の使用を排除するようにしてもよい。システム予約語まで抽出し且つ他の文字又は文字列に置き換えてしまうと、元のスクリプトが本来持つ意味、すなわちスクリプトが規定する動作内容の変更を伴うことになり、許容し難いからである。
【００４６】
また、本発明の第３の側面に係るコード変換方法は、さらに、ソース・コード中で該コードの実行に関与しない文字又は文字列からなる文を抽出するステップと、該抽出された文を削除するステップとを含んでもよい。ここで言うコードの実行に関与しない文字又は文字列からなる文は、所定のデリミッタで区切られたコメント文に相当する。
【００４７】
また、本発明の第３の側面に係るコード変換方法は、さらに、前記の冗長性の高い文字又は文字列を抽出するステップで抽出された文字又は文字列の各々についてのスクリプト中での出現頻度を積算するステップ又は手段を含み、
前記の冗長性の高い文字又は文字列を冗長性の低い文字又は文字列に置き換えるステップ又は手段は、出現頻度の大きい文字又は文字列ほどより文字数の短い文字又は文字列に置き換えるようにしてもよい。出現頻度の大きいものほど、より短い文字又は文字列で表現されるので、データ圧縮の効果が高まる。
【００４８】
【作用】
本発明は、デジタル衛星データ放送において、放送番組とともに配信されるデジタル伝送データ、特に、該伝送データのうちテキスト形式で記述されたデータ・ファイルに対して好適に適用することができる。
【００４９】
［従来の技術］の欄で既に説明したように、デジタル伝送データを構成するモジュールは、静止画、動画、音声などの各種様々なモノメディア・データと、これら各々のモノメディア・データを統合的すなわちマルチメディアとして取り扱い、放送番組情報の有様を規定する表示・出力制御プログラム（以下では、「マルチメディア符号化アプリケーション」とも呼ぶ）とで構成される。
【００５０】
このモジュール内のファイルのうち、テキスト形式データで構成されるものの１つは、表示・出力制御プログラムであり、そのコンテンツはタグでデータ属性が定義されるマークアップ記述言語（ＸＭＬやＳＧＭＬ、ＨＴＭＬなど）で記述されている。
【００５１】
また、該モジュールに含まれる他のテキスト形式データは、この音声や静止画、動画などの各者メディア・データの動作を規定するスクリプトである。スクリプトは、例えばＪａｖａＳｃｒｉｐｔ，ＥＣＭＡＳｃｒｉｐｔ，ＪＳｃｒｉｐｔなどのスクリプト言語で記述することができる（ＸＭＬ及びＸＳＬ等の規格では、基本的にはＥＣＭＡＳｃｒｉｐｔで記述するように規定されている）。
【００５２】
ＸＭＬ形式等で記述された表示・出力制御プログラム自体は、画面表示又は印刷出力する情報そのものを規定したものであり、そのテキスト・データの内容変更はデータ自体の意味（すなわち該プログラムが規定する動作）の変化を伴なってしまうので、許容し難い。
【００５３】
他方、スクリプトの場合、コード中に含まれる関数名や変数名、コメント文などは冗長性を含み、伝送効率上致命的となる。関数名や変数名などは、そもそも、スクリプト作成者が、コーディングやデバッグ作業における可読性などの便宜のため（あるいは個人的な好みに従って）命名したものであり、スクリプト自体が規定する動作機能とは無関係である。言い換えれば、これら関数名や変数名は、スクリプト自体の動作機能を維持したままで、他の文字列との可換性がある。また、コメント文は、スクリプト実行には無関係であり、省略することすら可能である。
【００５４】
本発明は、このようなテキスト形式で記述されたスクリプトが包含する冗長性に着眼してなされたものである。要するに、本発明は、スクリプト中に存在する、比較的長い文字列からなる関数名や変数名を、より短い文字列（例えばアルファベット１文字）で置き換えることにより、スクリプトのデータ・サイズを削減するものである。また、さらにスクリプト中のコメント文を削除することにより、データ・サイズを削減するものである。
【００５５】
スクリプト中の関数名や変数名は、スクリプトの作成者が、各々の関数や変数の人手による可読性を保つために便宜上命名したものであり、人が理解可能な意味を持つ程度の比較的長い文字列で構成される。また、コメント文は、スクリプト中の各部分（例えばルーチン文など）の機能をメモするためにソース・コード中に埋め込まれるが、それ自体はスクリプトの機能実現に寄与しない。
【００５６】
これら長い文字列からなる関数名や変数名、コメント文は、デバックまでの間は意味を持つが、デバッグ以降は、人が解釈可能な意味を持つ必要はない。特に、衛星データ放送のように一方向性のコンテンツ配信に適用する場合には、送信した以後の段階でのソース・コードの再利用を考慮する必要がない。言い換えれば、スクリプト中の関数名や変数名を他の短い文字列に置き換えたり、コメント文を削除して、人がソース・コードの意味内容を解釈し難くなっても、その弊害はほとんどないと言える。
【００５７】
本発明を、デジタル衛星データ放送におけるデジタル伝送データに適用することにより、伝送データ・サイズを削減することができ、配信時においては伝送効率が向上する。
【００５８】
また、受信局においては、受信データ・サイズが低下するので、比較的小容量の受信メモリを用意するだけで済み、コスト削減につながる。また、スクリプト中の関数名や変数名の文字列長が最小になることから、スクリプトを実行するインタープリタがメモリに割り当てる関数テーブル、変数テーブルのサイズを小さくすることができる。この結果、関数や変数を呼び出す際のオーバーヘッドが少なくなる。すなわち、スクリプトの実行効率が向上する上に、メモリを小容量化して受信機コストを削減することができる。受信機のユーザ（すなわち視聴者）は、実行効率の向上により、より高速なシステムの反応を期待することかできる。
【００５９】
本発明のさらに他の目的、特徴や利点は、後述する本発明の実施例や添付する図面に基づくより詳細な説明によって明らかになるであろう。
【００６０】
【発明の実施の形態】
以下、図面を参照しながら本発明の実施例を詳解する。
【００６１】
図１には、本発明の実施に供される衛星デジタル放送システム１０００の概略構成を示している。同図に示すように、衛星デジタル放送システム１０００は、放送サービスを提供する放送局（Ｂｒｏａｄｃａｓｔ  Ｓｅｒｖｅｒ）１と、放送データを中継する放送衛星（Ｓａｔｅｌｌｉｔｅ）５と、放送衛星５から放送データを受信する受信局（Ｒｅｃｅｉｖｅｒ／Ｄｅｃｏｄｅｒ）１０とで構成される。
【００６２】
放送局１は地上に１基以上存在し、放送衛星５は地球のはるか上空に散在する。また、受信局１０は、一般家庭などに相当し、実際には地上に無数存在する。放送局１及び放送衛星５を介したデータ配信すなわち放送は、一方向通信である。
【００６３】
デジタル・データ放送では、１０〜５０Ｍｂｐｓの転送レートでデータ伝送される。放送局１は、放送番組本体を構成するＡＶデータと、放送番組に付随する番組情報を含んだデジタル伝送データを多重化して配信する。ＡＶデータは、通常、ＭＰＥＧ（Ｍｏｔｉｏｎ  Ｐｉｃｔｕｒｅ  Ｅｘｐｅｒｔｓ  Ｇｒｏｕｐ）２形式でデータ圧縮して送信される。
【００６４】
デジタル伝送データには、テキストや静止画、動画、音声など各種モノメディア・データと、これらモノメディア・データの表示・出力を制御するプログラムである「マルチメディア符号化アプリケーション」とで構成されるモジュールが、データ・カルーセル化されて格納されている。マルチメディア符号化アプリケーションは、ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）言語形式で記述されており、文書の型式を定義するＤＴＤ文書と、ＸＳＬなどの言語形式で記述されたスタイルシートを含む（但し、ＤＴＤ文書及び／又はスタイルシートを配信コンテンツに含まない場合もある）。また、各モジュールには、音声や静止画、動画などの動作を規定するスクリプトが含まれている。
【００６５】
各受信局１０と放送局１との間は、インターネットのような広域ネットワーク７、又は、専用線（図示しない）などによって双方向接続されていてもよい。この場合、インターネット７を、受信局１０から放送局１に向かう上り回線として使用することができる。例えば、インターネット７を利用した一部オンデマンド放送サービスを提供することも可能である。但し、この場合、両者間は、５６ｋｂｐｓ以上の高速アナログ電話回線、１０〜６４ｋｂｐｓ程度の高速ワイヤレス通信、１２８ｋｂｐｓのＩＳＤＮ（Ｉｎｔｅｇｒａｔｅｄ  Ｓｅｒｖｉｃｅｓ  Ｄｉｇｉｔａｌ  Ｎｅｔｗｏｒｋ）、あるいは５〜３０Ｍｂｐｓクラスのケーブルによって接続されていることが好ましい。
【００６６】
図２には、放送局１すなわち送信システムの構成を模式的に示している。同送信システム１は、制作部１００と、送出部２００と、伝送部３００とで構成される。以下、各部について説明する。
【００６７】
制作部１００は、放送番組のコンテンツを制作する現場に相当する。制作部１００は、データ放送の内容を記述したＸＭＬ文書と、このＸＭＬ文書の動作を規定するスクリプトと、放送番組の本体であるＡＶデータなどの情報を制作し、それぞれをローカルの大容量記憶装置１０２及び１０３に蓄積する。
【００６８】
ＸＭＬ文書とスクリプトは、デジタル伝送データを構成する各モジュールのリソース（後述及び図７，図８を参照のこと）に相当する。これらデジタル伝送データは、編集システム１０１上でコーディング／デバッグ等の編集処理が行われる。編集システム１０１の実体は、ワークステーションやパーソナル・コンピュータと呼ばれる汎用コンピュータ・システムでよい。
【００６９】
ＸＭＬ文書は、任意に定義可能なタグを使用したマークアップ言語（前述）であり、文書型を定義するＤＴＤ文書を添付してもよい。この場合のＸＭＬ文書は、受信局１０における出力用のデータ本体である。スクリプトは、ＸＭＬ文書の動作を規定したものであり、ＪａｖａＳｃｒｉｐｔ，ＥＣＭＡＳｃｒｉｐｔ，ＪＳｃｒｉｐｔなどのスクリプト言語で記述されたテキスト形式のファイルである（ＸＭＬ及びＸＳＬ等の規格では、基本的にはＥＣＭＡＳｃｒｉｐｔで記述するように規定されている）。なお、デジタル伝送データは、ＸＭＬ文書とスクリプト以外に、音声データや静止画データなどのマルチメディア・コンテンツを含んでいてもよい。
【００７０】
制作部１００において制作され蓄積されたこれら配信コンテンツは、例えば、放送局１内に敷設されたＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）経由で、送出部２００に転送される。
【００７１】
送出部２００では、コンテンツ送信系２０１、ベースバンド制御系１０２及びＡＶエンコーダ２０３の各々によって送出データがパケット化されて、伝送部３００に渡す。ＡＶエンコーダ２０３は、放送番組の本体であるＡＶデータを、例えばＭＰＥＧ２などの圧縮方式により符号化圧縮する。
【００７２】
伝送部３００では、コンテンツ系のデータはマルチメディア符号化部３０１において符号化されてコンテンツ伝送系３０２に渡される。合成部３０４は、コンテンツ伝送系３０２及びＡＶデータ伝送系３０３の各々の出力データを合成する。そして、変調部３０５では、合成信号をＲＦ変調して、ＲＦ伝送路を介して受信局１０へ向けて送信する。
【００７３】
ＲＦ伝送路では、ＲＦ信号は、まず、放送局１に設置された送信アンテナから放送衛星５へ送信され、次いで、放送衛星５を経由して受信局１０の受信アンテナで受信される。
【００７４】
図３には、受信局１０に設置されるデジタル衛星データ放送受信システムの一例１０−Ａのハードウェア構成を模式的に示している。該受信システム１０−Ａは、例えばＳＴＢ（セット・トップ・ボックス）と呼ばれる形態で一般家庭に普及している。受信システム１０Ａ内では、メイン・コントローラとしてのＣＰＵ１１は、バス５０を介して各ハードウェア・コンポーネントと相互接続して、各コンポーネントに対して統括的な制御を実行するようになっている。以下、各部について説明する。
【００７５】
アンテナ（図示しない）で受信された放送波は、チューナ５１に供給される。放送波は、規定のフォーマットに従っており、例えば番組ガイド情報（ＥＰＧ：Ｅｌｅｃｔｒｉｃ  Ｐｒｏｇｒａｍ  Ｇｕｉｄｅ）等を含んでいる。なお、放送波としては、上記した放送波以外に、有線放送波や地上波でもよく、特に限定されない。
【００７６】
チューナ５１は、ＣＰＵ１１からの指示に従い、所定チャネルの放送波のチューニングすなわち選局を行い、後続の復調器５２に受信データを出力する。復調器５２では、デジタル変調されている受信データを復調する。なお、送信されてくる放送波がアナログかデジタルかに応じて、チューナ１１の構成を適宜変更又は拡張することができる。
【００７７】
復調されたデジタル・データは、ＭＰＥＧ２圧縮されたＡＶデータと、デジタル伝送データとが多重化されて構成される「トランスポート・ストリーム」である。前者のＡＶデータは、放送番組本体を構成する映像及び音声情報である。また、後者のデジタル伝送データは、この放送番組本体に付随するデータであり、例えばＥＰＧ（Ｅｌｅｃｔｒｉｃ  Ｐｒｏｇｒａｍ  Ｇｕｉｄｅ：電子番組ガイド）を含む。デジタル伝送データについては後に詳解する。なお、トランスポート・ストリームは、ＯＳＩ（Ｏｐｅｎ  Ｓｙｓｔｅｍｓ  Ｉｎｔｅｒｃｏｎｎｅｃｔｉｏｎ）参照モデルで言う「トランスポート層」に分類される。
【００７８】
ＴＳデコーダ５３は、このトランスポート・ストリームを解釈して、ＭＰＥＧ２圧縮されたＡＶデータとデジタル伝送データとに分離して、前者をＡＶデコーダ５４に送出するとともに、後者をバス５０経由でＣＰＵ１１に送信する。ＴＳデコーダ５３は、作業データ保管用のメモリ５３Ａを自己のローカルに備えていてもよい。
【００７９】
ＡＶデコーダ５４は、ＭＰＥＧ２方式で圧縮されたリアルタイムＡＶデータをＴＳデコーダ５３から受け取ると、圧縮映像データと圧縮音声データとに分離する。そして、映像データに対してはＭＰＥＧ２伸長処理してもとの映像信号を再生し、音声データに対してはＰＣＭ（Ｐｕｌｓｅ  Ｃｏｄｅ  Ｍｏｄｕｌａｔｉｏｎ）デコードした後に付加音と合成して再生音声信号とする。ＡＶデコーダ５４は、作業データ保管用のメモリ５４Ａを自己のローカルに備えていてもよい。再生映像信号は、マルチプレクサ５５Ｂを介してディスプレイ６１に表示出力され、また、再生音声信号は、マルチプレクサ５５Ａを介してスピーカ６２に音声出力される。
【００８０】
ユーザ・インターフェース制御部５６は、ユーザからの入力操作を処理するモジュールであり、例えば、ユーザが直接マニュアル操作するための操作ボタン／スイッチ（図示しない）や、赤外線（ＩＲ）などを介したリモコン６６からの遠隔操作を受容する機能を備えている。また、現在の設定内容を表示するための表示パネルやＬＥＤインジケータ（図示しない）を含んでいてもよい。
【００８１】
ユーザ・インターフェース制御部５６が持つ操作ボタン、又は、リモコン６６が持つ操作ボタンの１つは、ＯＳＣ表示コントローラ５７からの表示出力（すなわちデジタル伝送データに基づく番組情報等の表示出力）の有効化／無効化を操作するボタンに割り当てられている。
【００８２】
ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）１１は、受信システム１０−Ａ全体の動作を統括するメイン・コントローラである。また、ＣＰＵ１１は、バス５０経由で転送されてくるデジタル伝送データの処理を行うことができる。デジタル伝送データは、ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）言語形式で記述されており（後述）、ＣＰＵ１１は、このＸＭＬ文書に対するＸＭＬパージングブラウジング（表示出力又は印刷出力）などの処理ソフトウェア（後述）を、オペレーティング・システム（ＯＳ）によって提供されるプラットフォーム上で、実行することができる。
【００８３】
ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）１２は、ＣＰＵ１１の実行プログラム・コードをロードしたり、実行プログラムの作業データを書き込むために使用される、書き込み可能な揮発性メモリである。また、ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）１３は、受信システム１０−Ａの電源投入時に実行する自己診断・初期化プログラムや、ハードウェア操作用のマイクロコードを恒久的に格納する読み出し専用メモリである。
【００８４】
シリアル入出力（ＳＩＯ）コントローラ１４は、受信システム１０−Ａ外部の機器とシリアル的なデータ交換を行うための周辺コントローラである。ＳＩＯコントローラ１４が用意するシリアル・ポートには、アナログ電話回線上の伝送データを変復調するための高速モデム６３（例えば、転送レートが５６Ｋｂｐｓ）が外部接続されている。この高速モデム６３によって所定のアクセス・ポイント（図示しない）にＰＰＰ（Ｐｏｉｎｔ−ｔｏ−Ｐｏｉｎｔ  Ｐｒｏｔｏｃｏｌ）接続することで、受信システム１０−Ａは広域ネットワークとしてのインターネット７に接続される。
【００８５】
ＩＥＥＥ１３９４インターフェース１５は、数１０ＭＢｐｓ程度のデータ送受信が可能なシリアル高速インターフェースである。ＩＥＥＥ１３９４ポートには、ＩＥＥＥ１３９４対応の外部機器をデイジーチェーン接続又はツリー接続することができる。ＩＥＥＥ１３９４対応機器としては、例えば、ビデオ・カメラ６４やスキャナ（図示しない）などが挙げられる。
【００８６】
ハード・ディスク・ドライブ（ＨＤＤ）１７は、プログラムやデータなどを所定フォーマットのファイル形式で蓄積するための外部記憶装置であり、通常、数ＧＢ程度の比較的大容量を持つ。ＨＤＤ１７は、ハード・ディスク・インターフェース１８を介してバス５０に接続される。
【００８７】
カード・インターフェース１８は、カード・スロット１９に装填されたカード型デバイス６５とバス５０との間でのバス・プロトコルを実現するための装置である。カード型デバイス６５の一例は、クレジットカード・サイズでカートリッジ式に構成されたＰＣカードである。ＰＣカードは、ＰＣＭＣＩＡ（Ｐｅｒｓｏｎａｌ  Ｃｏｍｐｕｔｅｒ  Ｍｅｍｏｒｙ  Ｃａｒｄ  Ｉｎｔｅｒｆａｃｅ  Ａｓｓｏｃｉａｔｉｏｎ）及びＪＥＩＤＡ（Ｊａｐａｎ  Ｅｌｅｃｔｒｏｎｉｃ  Ｉｎｄｕｓｔｒｙ  Ｄｅｖｅｌｏｐｍｅｎｔ  Ａｓｓｏｃｉａｔｉｏｎ）が共同で策定した仕様”ＰＣ  Ｃａｒｄ  Ｓｔａｎｄａｒｄ”に準拠する。
【００８８】
ＰＣカードの一例は、ＥＥＰＲＯＭ（Ｅｌｅｃｔｒｉｃａｌｌｙ  Ｅｒａｓａｂｌｅ  ａｎｄ  Ｐｒｏｇｒａｍｍａｂｌｅ  ＲＯＭ）などの不揮発且つ消去再書き込み可能なメモリ・チップで構成されるメモリ・カードである。受信システム１０−Ａが比較的小型且つ安価に構成される場合、大容量且つ大容積のＨＤＤ１７を搭載することが、設計上困難な場合がある。このような場合、システム１０−Ａに対して着脱自在で可搬性に優れたメモリ・カードを適用することが好ましいと想定される。但し、着脱式のメモリ６５は、ＰＣカードのフォームファクタに限定されず、所謂「メモリ・スティック」であってもよい。
【００８９】
表示コントローラ５７は、デジタル伝送データに基づく放送番組情報等の表示出力を制御するための専用コントローラである。
【００９０】
このデジタル衛星データ受信システム１０−Ａでは、ＣＰＵ１１は、ユーザ・インターフェース制御部５６を介したユーザ入力コマンドに従って、チューナ５１の選局動作を制御するとともに、番組情報の表示制御などが行われる。すなわち、ＣＰＵ１１は、ＴＳデコーダ５３から転送されてきたデジタル放送用データを処理して、表示用のデータに変換して表示コントローラ５７に供給する。表示コントローラ５７は、この表示データを基に番組情報の画像信号を生成し、マルチプレクサ５５Ｂに供給する。また、ＣＰＵ１１は、デジタル放送用データに含まれる音声データも処理して、これをバス５０経由でマルチプレクサ５５Ａに供給する。マルチプレクサ５５Ａ及び５５Ｂは、ＣＰＵ１１から供給された表示用データと音声データの各々を、ＡＶデコーダ５４から出力される放送番組本体としての映像データ及び音声データと多重化して、ディスプレイ６１とスピーカ６２の各々に外部出力する。なお、デジタル放送用データの処理については、後に詳解する。
【００９１】
図４には、他の例に係るデジタル放送データ受信システム１０−Ｂのハードウェア構成を模式的に示している。この例に係る受信システム１０−Ｂは、例えば、汎用コンピュータ・システム３０に対して衛星デジタル放送用のデジタル・チューナ・カード４０を装備する、という形態で実装される。
【００９２】
デジタル・チューナ・カード４０は、チューナ５１と、復調器５２と、ＴＳデコーダ５３と、ＡＶデコーダ５４と、各ＲＡＭ５３Ａ及び５４Ａと、マルチプレクサ５５Ａ及び５５Ｂとで構成される。図３に示したものと同じ参照番号を持つハードウェア・ブロックとは、その構成及び機能は略同一である。このデジタル衛星放送用チューナ・カード４０は、バス・インターフェース（ＰＣＩインターフェース）５８（図示）を介してコンピュータ・システム３０内のシステム・バス（ＰＣＩバス）３１に接続される。
【００９３】
アンテナ（図示しない）から受信された放送波は、チューナ５１で選局され、復調器５２で復調される。ＴＳデコーダ５３は、トランスポート・ストリームを解釈し、ＭＰＥＧ２圧縮されたＡＶデータとデジタル伝送データに分離する。ＡＶデータの方はＡＶデコーダ５４に供給され、上述と同様に処理され、ディスプレイ６１やスピーカ６２などに外部出力される。また、デジタル伝送データの方は、ＰＣＩインターフェース５８経由でコンピュータ・システム３０側に転送され、該システム内部のＣＰＵ１１によって処理される（後述）。
【００９４】
他方、汎用コンピュータ・システム３０は、ＣＰＵ１１（後述）を始めとする主要回路コンポーネントを搭載した印刷配線基板（図示しない）を含んである。該基板は「マザーボード」とも呼ばれる。先述のチューナ・カード４０は、例えば「アダプタ・カード」の形態で提供され、マザーボード上に配設されたバス・スロット（図示しない）に装着される。
【００９５】
但し、チューナ・カード４０は、アダプタ・カードという形態ではなく、ＰＣＭＣＩＡ（Ｐｅｒｓｏｎａｌ  Ｃｏｍｐｕｔｅｒ  Ｍｅｍｏｒｙ  Ｃａｒｄ  Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ａｓｓｏｃｉａｔｉｏｎ）／ＪＥＩＤＡ（Ｊａｐａｎ  Ｅｌｅｃｔｒｏｎｉｃ  Ｉｎｄｕｓｔｒｙ  Ｄｅｖｅｌｏｐｍｅｎｔ  Ａｓｓｏｃｉａｔｉｏｎ）の策定仕様に準拠したＰＣカードの形式で提供され、ＰＣカード・スロット１９（後述）に挿入することによっても、コンピュータ・システム３０のシステム構成に組み込まれる。
【００９６】
ＣＰＵ１１は、コンピュータ・システム３０全体の動作を統括的に制御するメイン・コントローラである。この例に係るＣＰＵ１１は、オペレーティング・システム（ＯＳ）によって提供されるプラットフォーム上で、ＸＭＬパージングやＸＳＬプロセッシング、ブラウジングなど、ＸＭＬコンテンツ処理のための各種ソフトウェア・プログラム（後述）を実行することができる。
【００９７】
ＣＰＵ１１の外部ピンに直結したプロセッサ・バスは、バス・ブリッジ２０を介してシステム・バス３１に相互接続されている。
【００９８】
本実施例のバス・ブリッジ２０は、プロセッサ・バスとシステム・バス３１間の速度差を吸収するためのデータ・バッファの他、ＲＡＭ１２へのメモリ・アクセスを制御するメモリ・コントローラを含んだ構成となっている。
【００９９】
ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）１２は、ＣＰＵ１１の実行プログラム・コードをロードしたり、実行プログラムの作業データを書き込むために使用される、書き込み可能な揮発性メモリである。通常は、複数個のＤＲＡＭ（ダイナミックＲＡＭ）チップで構成される。
【０１００】
システム・バス３１は、アドレス・バス、データ・バス、コントロール・バスなどを含んだ共通信号伝送路であり、例えばＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ  Ｃｏｍｐｏｎｅｎｔ  Ｉｎｔｅｒｃｏｎｎｅｃｔ）バスがこれに相当する。システム・バス３１上には、ＰＣＩインターフェース仕様に合致した各種周辺機器が相互接続されている。周辺機器の一例は、先述のデジタル衛星放送用チューナ・カード４０である。これらバス３１上の各周辺機器にはそれぞれに固有のＩ／Ｏアドレス（又はメモリ・アドレス）が割り振られており、ＣＰＵ１１（より厳密にはＣＰＵ１１が実行するプログラム）は、Ｉ／Ｏアドレス（又はメモリ・アドレス）を指定することで所望の周辺機器に対するデータやコマンドの転送を実現することができる。
【０１０１】
ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）１３は、コンピュータ・システム３０の電源投入時に実行する自己診断プログラム（ＰＯＳＴ）や、ハードウェア操作用の基本入出力システム（ＢＩＯＳ）を恒久的に格納する読み出し専用メモリである。ＲＯＭ１３は、例えば電気的な消去及び再書き込み動作が可能なＥＥＰＲＯＭ（Ｅｌｅｃｔｒｉｃａｌｌｙ  Ｅｒａｓａｂｌｅ  ａｎｄ  Ｐｒｏｇｒａｍｍａｂｌｅ  ＲＯＭ）で構成されていてもよい。
【０１０２】
シリアル入出力（ＳＩＯ）コントローラ１４は、コンピュータ・システム３０外部の機器とシリアル的なデータ交換を行うための周辺コントローラである。ＳＩＯコントローラ１４が用意するシリアル・ポートには、アナログ電話回線上の伝送データを変復調するための高速モデム６３（例えば、転送レートが５６Ｋｂｐｓ）が外部接続されている。高速モデム６３によって所定のアクセス・ポイント（図示しない）にＰＰＰ（Ｐｏｉｎｔ−ｔｏ−Ｐｏｉｎｔ  Ｐｒｏｔｏｃｏｌ）接続することで、コンピュータ・システム３０（すなわち受信システム１０−Ｂ）はインターネットに接続される。
【０１０３】
ＩＥＥＥ１３９４インターフェース１５は、数１０ＭＢｐｓ程度のデータ送受信が可能なシリアル高速インターフェースである。ＩＥＥＥ１３９４ポートには、ＩＥＥＥ１３９４対応の外部機器をデイジーチェーン接続又はツリー接続することができる。ＩＥＥＥ１３９４対応機器には、例えば、ビデオ・カメラ６４やスキャナ（図示しない）などが挙げられる。
【０１０４】
ハード・ディスク・ドライブ（ＨＤＤ）１７は、プログラムやデータなどを所定フォーマットのファイル形式で蓄積するための外部記憶装置であり、通常、数ＧＢ程度の比較的大容量を持つ。ＨＤＤ１７は、ハード・ディスク・インターフェース１６を介してシステム・バス３３に接続される。ハード・ディスク・ドライブをコンピュータ・システム３０に接続するインターフェース規格は、例えばＩＤＥ（Ｉｎｔｅｇｒａｔｅｄ  Ｄｒｉｖｅ  Ｅｌｅｃｔｒｏｎｉｃｓ）やＳＣＳＩ（Ｓｍａｌｌ  Ｃｏｍｐｕｔｅｒ  Ｓｙｓｔｅｍ  Ｉｎｔｅｒｆａｃｅ）などである。
【０１０５】
キーボード／マウス・コントローラ（ＫＭＣ）２１は、キーボード２２やマウス２３などからのユーザ入力を処理するための専用コントローラである。ＫＭＣ２１は、キーボード２２からのスキャン・コード入力やマウス２３からの座標指示入力を検出したことに応答して、ＣＰＵ１１に対して割り込み要求を発行する。本実施例では、コンピュータ・システム３０に対する通常のコマンド入力の他、チャネルの選択などの受信システム１０−Ｂに対する入力操作も、キーボード２２やマウス２３を介して行うことができる。
【０１０６】
キーボード２２が持つファンクション・キーの１つ、又は、ディスプレイ６１上に配設されたメニュー・ボタンの１つは、ビデオ・コントローラ２４からの表示出力（すなわちデジタル伝送データに基づく番組情報等の表示出力）の有効化／無効化を操作するボタンに割り当てられている。
【０１０７】
カード・インターフェース１８は、バス５０とカード・スロット１９に装填されたカード型デバイス６５との間でのバス・プロトコルを実現するための装置である。カード型デバイス６５の一例は、クレジットカード・サイズでカートリッジ式に構成されたＰＣカードである。ＰＣカードは、ＰＣＭＣＩＡ（Ｐｅｒｓｏｎａｌ  Ｃｏｍｐｕｔｅｒ  Ｍｅｍｏｒｙ  Ｃａｒｄ  Ｉｎｔｅｒｆａｃｅ  Ａｓｓｏｃｉａｔｉｏｎ）及びＪＥＩＤＡ（Ｊａｐａｎ  Ｅｌｅｃｔｒｏｎｉｃ  Ｉｎｄｕｓｔｒｙ  Ｄｅｖｅｌｏｐｍｅｎｔ  Ａｓｓｏｃｉａｔｉｏｎ）が共同で策定した仕様”ＰＣ  Ｃａｒｄ  Ｓｔａｎｄａｒｄ”に準拠する。
【０１０８】
ＰＣカードの一例は、ＥＥＰＲＯＭ（Ｅｌｅｃｔｒｉｃａｌｌｙ  Ｅｒａｓａｂｌｅ  ａｎｄ  Ｐｒｏｇｒａｍｍａｂｌｅ  ＲＯＭ）などの不揮発且つ消去再書き込み可能なメモリ・チップで構成されるメモリ・カードである。デジタル衛星放送受信システム１０−Ｂが比較的小型且つ安価に構成される場合、大容量且つ大容積のＨＤＤ１７を搭載することが、設計上困難な場合がある。このような場合、受信システム１０−Ｂに対して着脱自在で可搬性に優れたメモリ・カードを適用することが好ましいと想定される。但し、着脱式のメモリ６５は、ＰＣカードのフォームファクタに限定されず、所謂「メモリ・スティック」であってもよい。
【０１０９】
ビデオ・コントローラ２４は、ＣＰＵ１１からの描画命令に従って画面表示を制御する専用コントローラであり、描画情報を一時格納するためのフレーム・メモリ（ＶＲＡＭ）２５を備えている。なお、本発明を好適に具現するためには、ビデオ・コントローラ２４は、ＶＧＡ（Ｖｉｄｅｏ  Ｇｒａｐｈｉｃｓ  Ａｒｒａｙ）以上の描画能力（例えば、ＳＶＧＡ（Ｓｕｐｅｒ  ｖｉｄｅｏ  Ｇｒａｐｈｉｃｓ  Ａｒｒａｙ）やＸＧＡ（ｅＸｔｅｎｄｅｄ  Ｇｒａｐｈｉｃｓ  Ａｒｒａｙ））を有することが好ましい。
【０１１０】
このデジタル衛星放送受信システム１０−Ｂでは、ＣＰＵ１１は、キーボード２２やマウス２３を介したユーザ入力コマンドに従って、チューナ１１の選局動作を制御するとともに、番組情報の表示制御などを行う。すなわち、ＣＰＵ１１は、ＴＳデコーダ５３から供給されたデジタル放送用データを処理して、表示用のデータに変換してビデオ・コントローラ２４に供給する。ビデオ・コントローラ２４は、この表示データを基に番組情報の画像信号を生成し、マルチプレクサ５５Ｂに供給する。また、ＣＰＵ１１は、デジタル放送用データに含まれる音声データも処理して、これをバス５０経由でマルチプレクサ５５Ａに供給する。マルチプレクサ５５Ａ及び５５Ｂは、ＣＰＵ１１から供給された表示用データと音声データの各々を、ＡＶデコーダ５４から出力される放送番組本体としての映像データ及び音声データと多重化して、ディスプレイ６１とスピーカ６２の各々に外部出力する。なお、デジタル放送用データの処理については、後に詳解する。
【０１１１】
なお、衛星デジタル・データ受信システム１０を構成するためには、図３や図４に示した以外にも多くの電気回路等が必要である。但し、これらは当業者には周知であり、また、本発明の要旨を構成するものではないので、本明細書中では省略している。また、図面の錯綜を回避するため、図中の各ハードウェア・ブロック間の接続も一部しか図示していない点を了承されたい。
【０１１２】
例えば、図３及び図４には図示しないが、受信システム１０は、ＦＤ（Ｆｌｏｐｐｙ  Ｄｉｓｃ）やＣＤ−ＲＯＭ、ＭＯ（Ｍａｇｎｅｔｏ−Ｏｐｔｉｃａｌ  ｄｉｓｃ）などの可搬型の記録メディアを装填してデータ・アクセス可能なＦＤＤ（Ｆｌｏｐｐｙ  Ｄｉｓｃ  Ｄｒｉｖｅ）、ＣＤ−ＲＯＭドライブ、ＭＯドライブのような外部記憶装置を備えていてもよい。
【０１１３】
図５には、デジタル放送データ受信システム１０において実行される各種ソフトウェア・プログラム間における階層的構成を模式的に図解している。以下、各層のソフトウェアの機能について説明する。
【０１１４】
最下層のハードウェア制御層は、オペレーティング・システム（ＯＳ）等の上位ソフトウェアに対してハードウェアの相違を吸収する目的を持ち、各ハードウェアに対する直接的な入出力動作やハードウェア割り込みに対応した処理を実行する。
【０１１５】
ハードウェア制御層は、例えばＲＯＭ１３に恒久的に格納されたＢＩＯＳ（Ｂａｓｉｃ  Ｉｎｐｕｔ／Ｏｕｔｐｕｔ  Ｓｙｓｔｅｍ）、あるいは、ＨＤＤ１７にインストールされた「デバイス・ドライバ」という形態で、デジタル衛星放送受信システム１０に提供される。
【０１１６】
オペレーティング・システム（ＯＳ）は、衛星放送受信システム１０内のハードウェア及びソフトウェアを総合的に管理するための基本ソフトウェアのことである。ＯＳは、ＨＤＤ１７上のファイルの記録を管理する「ファイル・マネージャ」や、メモリ空間を管理する「メモリ・マネージャ」、システム・リソースの割り振りを管理する「リソース・マネージャ」、タスク実行を管理する「スケジューラ」、ディスプレイ上のウィンドウ表示を制御する「ウィンドウ・システム」などのサブシステムを含んでいる。
【０１１７】
システム・サービスは、アプリケーションなどの上位プログラムがＯＳに対して各機能を呼び出す（コールする）ための関数の集まりであり、ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍｍｉｎｇ  Ｉｎｔｅｒｆａｃｅ）やラン・タイム・ライブラリ（又はダイナミック・リンク・ライブラリ）がこれに相当する。システム・サービスの存在により、アプリケーションは各ハードウェアを直接操作する必要がなくなり、ハードウェア操作の統一性が担保される。
【０１１８】
ＸＭＬアプリケーションは、データ放送の表示・出力などの有様を制御するためのプログラムであり、ＸＭＬという任意の定義付けが可能なタグ付の言語で記述されたＸＭＬ文書である。各ＸＭＬ文書には、文書型定義のためのＤＴＤ文書と、表示形式を規定するＸＳＬ文書（又は、ＣＳＳや、ＸＳＬの派生規格であるＸＳＬＴ）等のスタイルシートが付随してもよい。
【０１１９】
ＸＭＬパーザは、ＤＴＤ文書を用いてＸＭＬ文書を解析するソフトウェア・プログラムであり、解析結果としての文書オブジェクトをＸＳＬプロセッサに渡す。この文書オブジェクトは、元のＸＭＬ文書中のタグに従って木構造が形成された構造化文書である。
【０１２０】
次に、衛星データ受信システム１０において、放送データを受信する処理手順について、図６〜図８を参照しながら説明する。
【０１２１】
デジタル衛星放送システムでは、図６に示すように、まず、放送局１から放送衛星５に対して放送波が送信され、衛星５から受信局１０に向かって転送される。この送信放送波のコンテンツは、衛星放送番組本体を構成する映像と音声のデータ（ＡＶデータ）と、この放送番組本体に付随するデジタル伝送データとで構成される。
【０１２２】
図７には、放送波として伝播される放送コンテンツの構成を模式的に示している。同図に示すように、放送コンテンツは、ＭＰＥＧ（Ｍｏｔｉｏｎ  Ｐｉｃｔｕｒｅ  Ｅｘｐｅｒｔｓ  Ｇｒｏｕｐ）２など所定の圧縮方式で圧縮されたＡＶデータと、デジタル伝送データとを多重化した「トランスポート・ストリーム」として構成される（トランスポート・ストリームは、ＯＳＩ（Ｏｐｅｎ  Ｓｙｓｔｅｍｓ  Ｉｎｔｅｒｃｏｎｎｅｃｔｉｏｎ）参照モデルのトランスポート層に分類される）。
【０１２３】
既に述べたように、ＴＳデコーダ５３は、このトランスポート・ストリームを解釈してＡＶデータ部分とデジタル伝送データ部分とに分離する。ＡＶデータ部分は、ＡＶデコーダ５４で処理され、デジタル伝送データ部分はＣＰＵ１１において処理される。
【０１２４】
デジタル伝送データ部分は、複数のモジュールで構成される。各モジュールは、ＥＰＧや広告情報、その他放送番組本体に付随する各種情報を含んでいる。また、該デジタル伝送データ部分は、データ・カルーセル（回転木馬式データ）化されており、各モジュールは番組本体の放送中に繰り返し出現する（この結果、視聴者としての受信システム１０は、番組放送期間中の任意のタイミングでモジュールを取得することができ、キャッシュ用のメモリを省略できる）。また、ＭＰＥＧ２圧縮されているＡＶデータの中には、モジュールの表示出力時期との同期をとるための自動開始フラグを埋め込むことができる。
【０１２５】
図８には、モジュールのデータ構造を模式的に示している。同図に示すように、１つのモジュールは、データ放送の表示や出力の有様を規定する制御プログラム（マルチメディア符号化アプリケーション）や、動作を規定するスクリプト、音声、テキスト・データ、静止画、動画などのモノメディア・データなど、複数のリソース要素で構成される。各モノメディア・データは、データ放送の一部を構成するオブジェクトであり、マルチメディア符号化アプリケーションによって統合的に取り扱われる。
【０１２６】
モジュールを構成する各リソース要素は、それぞれ所定フォーマットを持つ独立したファイルである。音声データは、例えばＡＩＦＦやＷＡＶ、ＡＡＣなど音声専用のファイル・フォーマットで記述され、静止画は、ＪＰＥＧやＰＮＧ、ＧＩＦなど画像専用のファイル・フォーマットで記述される。先頭のリソース・ロケーション情報は、モジュール内における各リソース要素の位置情報を記述している。
【０１２７】
「マルチメディア符号化アプリケーション」は、ＥＰＧや広告情報、その他、放送番組本体に付随する各種データ放送の表示・出力の有様を制御するプログラムであり、ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）形式で記述されたＸＭＬアプリケーションである。但し、必ずしもＸＭＬ言語には限定されず、ＳＧＭＬやＨＴＭＬなど、その他のマークアップ言語形式で記述されてもよい。ＸＭＬ文書は、文書型定義を行うＤＴＤ文書を含んでもよい。また、ＸＭＬ文書には、現実の表現形式を指定するスタイル情報が包含されていないので、スタイルシートを添付してもよい。
【０１２８】
スタイルシートは、出力コンテンツとしてのＸＭＬ文書（さらに、その他の音声・静止画などのマルチメディア・コンテンツを含んでもよい）の実際の表現形式を規定したデータ・ファイルである。スタイルシートは、ＸＭＬ文書をディスプレイ６１上に表示出力する形式に変換する（あるいはプリンタ（図示しない）への印刷出力形式に変換する）ための、ＸＳＬ（ｅＸｔｅｎｓｉｂｌｅ  Ｓｔｙｌｅｓｈｅｅｔ  Ｌａｎｇｕａｇｅ）形式で記述された文書ファイルである。
【０１２９】
また、スタイルシートとは別には、音声、テキスト、静止画、動画などの各種モノメディア・データからなるマルチメディア・コンテンツの動作を規定したスクリプトを配信してもよい（スクリプトは、例えばＪａｖａＳｃｒｉｐｔ，ＥＣＭＡＳｃｒｉｐｔ，Ｊｓｃｒｉｐｔなどのスクリプト言語で記述される。但し、ＸＭＬ及びＸＳＬ等の規格では、基本的にはＥＣＭＡＳｃｒｉｐｔで記述するように規定されている）。
【０１３０】
受信システム１０側では、これら受信した配信コンテンツのうち必要なものは、ＨＤＤ１７（又はメモリ・カード６５）のような、システム１０のローカルな記憶装置に一旦蓄積される。
【０１３１】
衛星放送のように一方向性の送信環境では、標準的なＸＭＬ言語で記述されたコンテンツは、使用するスタイルシートを限定しない限り、ＸＭＬ文書とスタイルシートが同梱された形態で送信される。
【０１３２】
本実施例では、放送コンテンツのうちのデジタル伝送データ部分は、出力コンテンツ（ＸＭＬ文書）とスタイルシート（ＸＳＬ文書又はＣＳＳ文書など）が同梱されたもの以外に、ＸＭＬ文書本体のみの伝送、ＸＳＬ文書のみの伝送というケースも想定している。また、ＸＳＬ文書は、放送以外による配信・配布の形態、例えばインターネットのようなネットワーク経由でのファイル・ダウンロードや、ＦＤやＣＤ−ＲＯＭ、ＭＯ、メモリ・スティックなどの可搬型記憶媒体に担持されて供給を受けることができる。
【０１３３】
また、本実施例に係る受信システム１０は、供給されたＸＭＬ文書とＸＳＬ文書（又はＣＳＳ文書など）を分離して蓄積する。すなわち、これら供給された文書ファイルを蓄積するＨＤＤ１７（又は、メモリ・カード６５）には、ＸＭＬ文書（但し、ＤＴＤ文書を含んでもよい）のみを保存・管理する文書本体保存部８０と、スタイルシートとしてのＸＳＬ文書のみを保存・管理するスタイルシート保存部９０が設けられている。
【０１３４】
次に、デジタル衛星放送受信システム１０において、放送局１がデジタル伝送データ部分を送信する処理手順について説明する。
【０１３５】
既に上述したように、放送局１が配信するコンテンツは、放送番組本体としてのＭＰＥＧ２圧縮されたＡＶデータの他に、デジタル伝送データを含む。図７及び図８を参照しながら説明したように、デジタル伝送データを構成する各モジュールには、テキスト形式データで構成される２つのファイルが含まれている。このうちの１つは出力用データ・ファイルであり、そのコンテンツはタグでデータ属性が定義されるマークアップ記述言語（ＸＭＬやＨＴＭＬなど）で記述されている。
【０１３６】
また、モジュールに含まれる他のテキスト形式データは、音声や静止画、動画などの各者メディア・データの動作を規定するスクリプトである。このスクリプトは、例えば、ＪａｖａＳｃｒｉｐｔ，ＥＣＭＡＳｃｒｉｐｔ，ＪＳｃｒｉｐｔなどのスクリプト言語で記述される（ＸＭＬ及びＸＳＬ等の規格では、基本的にはＥＣＭＡＳｃｒｉｐｔで記述するように規定されている）。スクリプトは、ソフトウェアに実行させる処理手順をテキスト形式で記述したものであり、通常、アプリケーションやＯＳ上で、エンド・ユーザが制御できる操作手順を組み合わせた一連の処理を自動化するために利用される。
【０１３７】
ＸＭＬ形式等で記述された出力用データ自体は、画面表示又は印刷出力する情報そのものを規定したものであり、そのテキスト・データの内容変更は許容し難い。
【０１３８】
これに対し、スクリプトのソース・コード中に含まれる関数名や変数名、コメント文などは、冗長性を含み、伝送効率上は致命的となる。関数名や変数名などは、そもそも、スクリプト作成者が、人手による可読性などの便宜上（又は個人的な好みに従って）命名したものであり、スクリプト自体が規定する動作機能とは無関係である。言い換えれば、これら関数名や変数名は、スクリプト自体の動作機能を維持したままで、他の文字列との可換性がある。また、コメント文は、スクリプトの実行とは無関係であり、省略することさえ可能である。
【０１３９】
本発明は、このようなテキスト形式で記述されたスクリプトが包含する冗長性に着眼してなされたものである。要するに、本発明は、スクリプト中に存在する、比較的長い文字列からなる関数名や変数名を、より短い文字列（例えばアルファベット１文字）で置き換えることにより、スクリプトのデータ・サイズを削減するものである。また、さらにスクリプト中のコメント文を削除することにより、データ・サイズを削減するものである。
【０１４０】
図９には、テキスト形式のスクリプト・ファイルを変換する処理ルーチンをフローチャートの形式で示している。このスクリプト・ファイル変換処理ルーチンは、例えば、放送局１内の番組制作者（より具体的には、制作部１００の編集システム１０１（図２を参照のこと）上）において、デジタル伝送データ作成完了後に行われる。以下、このフローチャートの各ステップについて説明する。
【０１４１】
まず、ステップＳ１０では、冗長性の高い文字列と置き換えるための冗長性の低い文字列（以下では、「適用文字」と呼ぶ）と、変数ｉを初期値に設定する。本実施例では、適用文字として、アルファベット１文字を昇順で使用する。また、適用文字がＡから始まってＺまで到達すると、ＡＡ，ＡＢ，ＡＣ，…，ＺＺ，ＡＡＡ，…という具合に、該昇り順に従い文字数を１ずつ増加させることとする。
【０１４２】
また、ＥＣＭＡＳｃｒｉｐｔには、予約語が小文字から始まるという規則がある。したがって、処理対象となるスクリプトがＥＣＭＡＳｃｒｉｐｔ形式で記述されている場合には、適用文字が大文字で始まるように規定することにより、ＥＣＭＡＳｃｒｉｐｔの予約語との一致を容易に排除することができる。したがって、この場合には、適用文字がスクリプトの予約語と一致するか否かの判定（図１２のステップＳ２３：後述）は、必要ない。
【０１４３】
次いで、ステップＳ１２では、処理対象となるスクリプトをスキャンして、冗長性の高い文字列を抽出して、リストアップする。
【０１４４】
ここで言う冗長性の高い文字列とは、例えば関数名や変数名である。これらは、コーディングやデバッグ作業の際の人手による可読性を高めるために、意味を持つ単語を使用した結果として冗長性が高い。例えば、以下に示す規則に従って、関数名や変数名をスクリプト中から抽出することができる。すなわち、
【０１４５】
（１）予約語”ｆｕｎｃｔｉｏｎ”の直後に続くワードは関数名である。
（２）関数名の直後に続く括弧の中身は変数名とカンマの列である。
（３）予約語”ｖａｒ”の次のワードは変数名である。
（４）代入された左辺は変数名である。
【０１４６】
次いで、リストの１番目の要素（すなわち元の関数名や変数名）を取り出して（ステップＳ１４）、この要素に対して適用文字を適用して、新しい関数名や変数名とし、要素と適用文字との対応関係を対応表に保存する（ステップＳ１６）。作成された対応表は、後述する［表１］に示す通りである。
【０１４７】
ステップＳ１８では、適用文字がＺn、すなわちＺだけからなる文字列に到達したか否かを判別する（但し、文字列の個数ｎをｎの冪乗で表記したものである）。
【０１４８】
該判断ブロックの結果が否定的であれば、ステップＳ２０に進んで、アルファベットの昇り順に従い、適用文字を次の文字列に更新する。また、該判断結果が肯定的であれば、ステップＳ２２に進んで、アルファベットの昇り順に従い、適用文字を１文字増やす（例えば適用文字がＺであればＡＡに更新し、ＺＺでれあばＡＡＡに更新する）。
【０１４９】
次いで、ステップＳ２４ではｉを１だけ増分してリストの次の要素に進み、ステップＳ２６ではリスト中に未処理の要素が残っているか否かを判別する。未処理エントリが残っていれば、ステップＳ１４に復帰して、次の要素に対して上述と同様の処理を繰り返し実行する。また、リスト中の全て要素を対応表に登録し終えたならば、後続のスクリプト置換処理ルーチン（Ｓ３０）に進む。該ルーチンでは、元のスクリプト中の関数名や変数名などの冗長文字列を冗長性の低い適用文字に置換して、スクリプトのサイズを圧縮する。そして、この処理ルーチン全体を終了する。
【０１５０】
ステップＳ３０のスクリプト置換処理は、別途定義済みの処理ルーチンであり、図１１にはその処理手順をフローチャートの形式で示している。以下、このフローチャートの各ステップについて説明する。
【０１５１】
まず、ステップＳ３１では、対応表（［表１］を参照のこと）からエントリを１つ取り出し、次いで、ステップＳ３２では、元のスクリプトから１センテンスを取り出す。但し、ここで言うセンテンスは、ブランクから次のブランク又は次の改行位置までの区間の文字列を指し、ブランクは含まないものとする。
【０１５２】
ステップＳ３３では、センテンス中に、エントリで規定された変数名や関数名が存在するか否かを判別する。判別結果が否定的であれば、次ステップＳ３４をスキップし、逆に肯定的であれば、ステップＳ３４において変数名や関数名を対応する適用文字に置換する。
【０１５３】
次いで、ステップＳ３５では、センテンスがコメント文か否かを判別する。ＥＣＭＡＳｃｒｉｐｔ形式のスクリプトであれば、コメント文はデリミッタ”／／”以降で次の改行位置までの文字列である。該判別結果が肯定的であれば、ステップＳ３６に進み、このコメント文をスクリプトから削除する。
【０１５４】
次いで、ステップＳ３７では次のセンテンスの取得を試み、ステップＳ３８では最後のセンテンスであったか否かを判別する。センテンスが未だ残っていれば、ステップＳ３２に復帰して、次のセンテンスに対して上述と同様の処理を繰り返し実行する。
【０１５５】
また、最後のセンテンスに到達していた場合には、対応表中の最後のエントリであったか否かを判別する（ステップＳ３９）。未だエントリが残っていれば、ステップＳ３１に復帰して、次のエントリが規定する対応関係について、上記と同様の処理を繰り返し実行する。また、全ての対応関係について処理し終えていれば、この処理ルーチン全体を終了する。
【０１５６】
このスクリプト変換処理は、制作部１００においてスクリプト作成の際に実行して、変換処理後のスクリプトをリソースとして大容量記憶装置１０２に格納することが好ましい。スクリプト作成直後ではなく、送出直前にスクリプトを変換処理することも考えられるが、この場合、リソースのモジュール・サイズが変更するため、モジュールの再構築が必要となる可能性がある。ゆえに、スクリプト作成時に変換処理を実行しておいた方がよい。（例えば、変換処理前に、モジュール長の制約から１つのモジュールを２つ以上のモジュールに分割して格納していたような場合、変換処理により単一のモジュール長に収まることもある。）
【０１５７】
図１０には、図９に示した変換処理を実行する前後のスクリプトのソース・コードを対比している。但し、このスクリプトは、ＥＣＭＡＳｃｒｉｐｔ（ＥＣＭＡＳｃｒｉｐｔは、欧州電子計算機工業会が規格化したスクリプト言語である）で記述されたテキスト・データであり、また、完結したプログラムではなくその一部の抜粋である点を了解されたい。
【０１５８】
元のソース・コード中で、”ｆｕｎｃｔｉｏｎ”なる予約語の直後に続く文字列（例えば、”ｂｕｉｌｄＡｒｒａｙ”など）は関数名であり、より短い文字列に置き換える対象となる。
【０１５９】
また、代入された左辺の文字列（例えば、”ｔｅｍｐｏｒａｒｙ＿ａｒｇｕｍｅｎｔ”など）は変数名に該当し、同様に短い文字列に置き換える対象となる。スクリプト内で定義された変数を挙げたが、本発明の要旨はこれに限定されない。例えば、ＸＭＬやＨＴＭＬなどの文書中の表示用符号化データの属性を操作する操作子としての変数にも、同様に、短い文字列への置換処理を適用することができる。
【０１６０】
また、デリミッタ”／／”で始まる行末までの文字列は、コメント文である。本実施例に係る置換処理では、ソース・コード中で、”／／”から始まる１文を検索して、その行末までの文字を全て無視すなわち削除する。
【０１６１】
図１０に示す元のソース・コードに対して図９に示す変換処理を実行した結果、以下の［表１］に示す対応表が生成される。そして、抽出された変数名や関数名などの冗長性の高い文字列は、冗長性の低い適用文字に変換される。
【０１６２】
【表１】
0004776050.tif 000002
【０１６３】
図１０を参照して判るように、元のソース・コード中の変数名や関数名は、アルファベット１文字に置き換えられ、コメント文は削除される。また、同図で視認される通り、コード量は大幅に削減され、伝送効率は大いに向上する。
【０１６４】
変換処理後も、スクリプトが規定する処理そのものは変換前と全く同じである。したがって、変換処理されたスクリプトを受信する衛星放送受信システム１０では、スクリプトの実行系はこのサイズ削減処理がなされたか否かを意識せず同じように取り扱うことができる。
【０１６５】
スクリプト中の関数名や変数名の文字列長が最小になることは、受信システム１０における実行効率の観点からも好ましい。何故ならば、スクリプトを実行するインタープリタがメモリに割り当てる関数テーブル、変数テーブルのサイズを小さくすることができる。この結果、関数や変数を呼び出す際のオーバーヘッドが少なくなるからである。
【０１６６】
図９に示すスクリプト変換処理ルーチンによれば、可読性を持つゆえに冗長であった関数名や変数名を、冗長性を排除した短い文字列すなわち適用文字に変換することで、スクリプトのサイズを好適に圧縮することができる。
【０１６７】
置換対象となる関数名や変数名の個数が２６以下、すなわち、アルファベット文字の総数以下であれば、いかなる順序で適用文字への置換処理を行っても、変換後のサイズに相違はない。
【０１６８】
これに対し、置換対象が２６個を越える場合には、１文字の適用文字の他に、２文字以上の適用文字を使用することになる（図９のステップＳ２２を参照のこと）。より長い文字列を短い文字列に置換した方が、データ圧縮の効果は高い。
【０１６９】
図１２には、図９に示したものとは別のスクリプト変換処理ルーチンの例をフローチャートの形式で示しているが、該フローチャートではこのデータ圧縮効率の点を勘案している。すなわち、ステップＳ１２とステップＳ１４の間に、リスト中の要素を再ソートするステップＳ１３を挿入した。すなわち、このステップＳ１３では、スクリプト中での出現頻度が大きい順にリスト中の各要素を再ソートする。この結果、以後の置換処理では、出現頻度の大きい文字又は文字列ほど、より文字数の短い文字又は文字列に置き換えられることになり、データ圧縮の効果が高まる。
【０１７０】
また、図１２に示すルーチンでは、さらに、ステップＳ２０とＳ２４の間に、更新された適用文字がシステム予約語か否かを判断し（ステップＳ２３）、予約語であればステップＳ１８に復帰して文字列変換の対象から除外するようにしている。予約語に変換してしまうと、元のスクリプト本来の意味、すなわちスクリプトが規定する動作が変更してしまうため、許容し難いからである。
【０１７１】
スクリプト中の関数名や変数名は、スクリプトの作成者が、各々の関数名や変数名の人手による可読性を保つために便宜上命名したものであり、人が理解可能な意味を持つ比較的長い文字列で構成される。また、コメント文は、スクリプト中の各部分（例えばルーチン文など）の機能をメモするためにソース・コード中に埋め込まれるが、それ自体は機能実現に寄与しない。
【０１７２】
これら長い文字列からなる関数名や変数名、コメント文は、デバックまでの間は意味を持つが、デバッグ以降は、人が解釈可能な意味を持つ必要はない。特に、衛星放送のように一方向性のコンテンツ配信に適用する場合には、送信した以後の段階でのソース・コードの再利用を考慮する必要がない。言い換えれば、スクリプト中の関数名や変数名を他の短い文字列に置き換えたり、コメント文を削除して、ソース・コードが人手での可読性を失っても、その弊害はほとんどないのである。
【０１７３】
本発明を、デジタル衛星データ放送におけるデジタル伝送データに適用することにより、伝送データ・サイズを削減することができ、配信時においては伝送効率が向上する。
【０１７４】
また、受信局においては、受信データ・サイズが低下するので、比較的小容量の受信メモリを用意するだけで済み、コスト削減につながる。また、関数名や変数名の文字列長が最小になることから、スクリプトを実行するインタープリタがメモリに割り当てる関数テーブル、変数テーブルのサイズを小さくすることができる。この結果、関数や変数を呼び出す際のオーバーヘッドが少なくなる。すなわち、スクリプトの実行効率が向上する上に、メモリを小容量化して受信機コストを削減することができる。
【０１７５】
［追補］
以上、特定の実施例を参照しながら、本発明について詳解してきた。しかしながら、本発明の要旨を逸脱しない範囲で当業者が該実施例の修正や代用を成し得ることは自明である。すなわち、例示という形態で本発明を開示してきたのであり、限定的に解釈されるべきではない。本発明の要旨を判断するためには、冒頭に記載した特許請求の範囲の欄を参酌すべきである。
【０１７６】
【発明の効果】
以上詳記したように、本発明によれば、テキスト・データからなる配信コンテンツの伝送効率を向上することができる、優れたデータ配信技術を提供することができる。
【０１７７】
また、本発明によれば、テキスト・データからなる配信コンテンツを受信する受信装置における実行効率を向上するとともに、メモリ負荷を低減することができる、優れたデータ配信技術を提供することができる。
【０１７８】
本発明をデジタル衛星放送などのデジタル・データの配信に適用した場合、テキスト形式で記述されたスタイルシートを、その処理内容を変えずにデータ量を削減することができる。この結果、コンテンツ配信元である放送局においては、スタイルシートの作成作業は従来のままで、配信コンテンツの伝送効率を向上させることができる。
【０１７９】
また、受信局側においては、受信データ・サイズが低下するので、比較的小容量の受信メモリを用意するだけで済み、コスト削減につながる。
【０１８０】
さらに、スクリプト中の関数名や変数名の文字列長が最小になることから、スクリプトを実行するインタープリタがメモリに割り当てる関数テーブル、変数テーブルのサイズを小さくすることができる。この結果、関数や変数を呼び出す際のオーバーヘッドが少なくなり、スクリプトの実行効率が向上する。したがって、受信機のユーザ（すなわち視聴者）は、実行効率の向上により、より高速なシステムの反応を期待することかできる。
【０１８１】
また、スクリプトを配信する放送局側では、変換前後でのスクリプトの意味・内容は変化させていないので、受信側では既存の解釈ソフトウェアを用いてスクリプトを駆動することができる。言い換えれば余分なソフトウェア開発を必要としない。
【図面の簡単な説明】
【図１】本発明の実施に供される衛星デジタル放送システム１０００の概略構成を示した図である。
【図２】放送局１すなわち送信システムの構成を模式的に示した図である。
【図３】受信局１０（すなわち一般家庭）における受信システムの一例１０−Ａのハードウェア構成を模式的に示した図であり、より具体的には、ＳＴＢ（セット・トップ・ボックス）と呼ばれる形態で実装された受信システム１０−Ａの構成を示した図である。
【図４】他の例に係る受信システム１０−Ｂのハードウェア構成を模式的に示した図であり、より具体的には、汎用コンピュータ・システムに衛星デジタル放送用のチューナ・カードを装備するという形態で実装された受信システム１０−Ｂのハードウェア構成を示した図である。
【図５】デジタル放送データ受信システム１０において実行される各種のソフトウェア・プログラムにおける階層的構成を模式的に図解している。
【図６】放送コンテンツが放送局１から放送衛星５を介して受信局１０に転送される様子を模式的に示した図である。
【図７】放送波として伝播される放送コンテンツの構成を模式的に示した図である。
【図８】デジタル伝送データを構成するモジュールのデータ構造を模式的に示した図である。
【図９】スクリプトを変換する処理ルーチンを示したフローチャートである。
【図１０】図９に示した変換処理を実行する前後のスクリプトのソース・コードを対比した図である。
【図１１】別途定義されたスクリプト置換処理ルーチン（ステップＳ３０）を示したフローチャートである。
【図１２】スクリプトを変換する処理ルーチンの他の例を示したフローチャートである。
【図１３】デジタル伝送データとして配信コンテンツのデータ構造を模式的に示した図である。
【符号の説明】
１…放送局（デジタル放送データ送信システム）
５…放送衛星，７…広域ネットワーク（インターネット）
１０…受信局（一般家庭：デジタル放送データ受信システム）
１１…ＣＰＵ，１２…ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）
１３…ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ），１４…ＳＩＯコントローラ
１５…ＩＥＥＥ１３９４コントローラ
１６…ハード・ディスク・インターフェース
１７…ハード・ディスク・ドライブ（ＨＤＤ）
１８…カード・インターフェース，１９…カード・スロット
２０…バス・ブリッジ
２１…キーボード／マウス・コントローラ（ＫＭＣ）
２２…キーボード，２３…マウス
２４…ビデオ・コントローラ，２５…ＶＲＡＭ
３０…汎用コンピュータ・システム
３１…システム・バス（ＰＣＩバス）
４０…デジタル・チューナ・カード
５０…バス，５１…チューナ，５２…復調器，
５３…ＴＳデコーダ５４…ＡＶデコーダ
５３Ａ，５４Ａ…ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）
５５Ａ，Ｂ…マルチプレクサ（ＭＵＸ）
５６…ユーザ・インターフェース制御部
５７…表示コントローラ，５８…バス（ＰＣＩ）・インターフェース
６１…ディスプレイ，６２…スピーカ
６３…高速モデム，６４…ビデオ・カメラ，６５…メモリ・カード
６６…リモコン
１００…制作部，１０１…編集システム
１０２，１０３…大容量記憶装置
２００…送出部，２０１…コンテンツ送信系
２０２…ベースバンド制御系，２０３…ＡＶエンコーダ
３００…伝送部，３０１…マルチメディア符号化部
３０２…コンテンツ伝送部，３０３…ＡＶデータ伝送部
３０４…合成部，３０５…変調部
１０００…デジタル衛星データ放送システム
【図１】
0004776050.tif 000003
【図２】
0004776050.tif 000004
【図３】
0004776050.tif 000005
【図４】
0004776050.tif 000006
【図５】
0004776050.tif 000007
【図６】
0004776050.tif 000008
【図７】
0004776050.tif 000009
【図８】
0004776050.tif 000010
【図９】
0004776050.tif 000011
【図１０】
0004776050.tif 000012
【図１１】
0004776050.tif 000013
【図１２】
0004776050.tif 000014
【図１３】
0004776050.tif 000015