JP2001028585A

JP2001028585A - 配信コンテンツ生成方法、コンテンツ配信方法および装置、並びに、コード変換方法

Info

Publication number: JP2001028585A
Application number: JP11198483A
Authority: JP
Inventors: Yoshiharu Ideha; 義治出葉
Original assignee: Sony Corp
Current assignee: Sony Corp
Priority date: 1999-07-13
Filing date: 1999-07-13
Publication date: 2001-01-30
Anticipated expiration: 2019-07-13
Also published as: EP1115207A1; WO2001005038A1; US7653752B2; US7308508B1; US20080028101A1; CN1321362A; JP4776050B2; EP1115207A4

Abstract

(57)【要約】【課題】テキスト形式のスクリプトからなるコンテン
ツ配信の伝送効率や受信側での実行効率を向上する。【解決手段】マークアップ言語で記述された出力用デ
ータ自体は、表示出力する情報そのものを規定したもの
で、その内容変更は許容し難い。一方スクリプト中に含
まれる関数名や変数名、コメント文などは、冗長性を含
み、伝送効率上致命的となる。そこで、スクリプト中に
存在する、比較的長い文字列からなる関数名や変数名
を、より短い文字列（例えばアルファベット１文字）で
置き換えることにより、スクリプトのデータ・サイズを
削減する。また、さらにスクリプト中のコメント文を削
除することにより、データ・サイズを削減する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、衛星デジタル放送
やマルチメディア・コンテンツの通信など、デジタル・
データ配信技術に係り、特に、コンピュータ言語の命令
で構成されるデジタル・データを配信する技術に関す
る。

【０００２】更に詳しくは、本発明は、任意に定義可能
なタグを使用するマークアップ言語（例えば、ＸＭＬ
（ｅＸｔｅｎｓｉｂｌｅＭａｒｋｕｐＬａｎｇｕａ
ｇｅ））形式のデジタル・データを配信するデジタル・
データ配信技術に係り、特に、いわゆるスクリプトなど
のテキスト・データからなる配信コンテンツの伝送効率
と受信側での実行効率を向上するデジタル・データ配信
に関する。

【０００３】

【従来の技術】放送の技術分野において、データのデジ
タル化が急速に進められている。デジタル信号の方が、
アナログ信号よりも安定性に優れ、データ圧縮率も高
い。また、デジタル信号は、ケーブル、地上波、衛星波
を問わず、一定の帯域でアナログ信号よりも多くのチャ
ンネルを確保することができる。また、従来の情報伝達
においては文書、音声、映像の各情報は全く別物であっ
たが、放送データをデジタル化することにより分け隔て
なく伝送することができる。

【０００４】例えば、デジタル・データであれば、ＥＰ
Ｇ（ＥｌｅｃｔｒｉｃＰｒｏｇｒａｍＧｕｉｄｅ：
電子番組ガイド）など各種のシステム情報等を映像情報
や音声情報とともに送ることによって、ユーザ（視聴
者）へのサービスを向上させることができる（ＥＰＧ
は、放送番組の放送スケジュールや番組名などの提示情
報の他、ＶＴＲへの録画予約などの機能を包含する）。

【０００５】デジタル形式のデータは、汎用コンピュー
タ・システムなどテレビジョン以外の情報機器との親和
性も高い。例えば、汎用コンピュータ・システムに衛星
放送用チューナ・カードを取り付けて、受信したＥＰＧ
データをコンピュータ内で解析して、番組表をコンピュ
ータ・ディスプレイ上にウィンドウ表示して、番組切換
や録画予約などをマウス・カーソルによる操作で実現す
ることができる。勿論、放送データをコンピュータの内
蔵ハード・ディスクにそのままデジタル録画することも
可能である。

【０００６】また、帯域を活用して、映像や音声などの
放送番組本体以外のデータを送信することにより、放送
番組の対話性を高めることができる。例えば、択一式の
クイズを提供するような放送番組であれば、映像・音声
データとともに解答を併せて送信することにより、衛星
テレビ放送受信機（すなわち視聴者）側では、コンピュ
ータ・ディスプレイ上に解答メニュー・ボタンを用意
し、マウス・カーソルなどのポインティング・デバイス
による解答操作に応答して答合わせを行うことができ
る。

【０００７】さらに対話性が高まれば、家庭内のテレビ
受信機は、単に映像コンテンツを扱うだけでなく情報管
制塔として飛躍することが期待できる。例えば、テレビ
受信機は、インターネット端末や電子商取引端末にもな
り得る。

【０００８】日本では、ＡＲＩＢ（電波産業会）が中心
となって、デジタル衛星データ放送に関する標準化作業
が進められている。これによれば、デジタル衛星データ
放送では、衛星放送番組本体を構成する映像と音声のデ
ータ（ＡＶデータ）の他に、放送番組に付随するデジタ
ル伝送データが並行して配信される。より具体的には、
ＭＰＥＧ（ＭｏｔｉｏｎＰｉｃｔｕｒｅＥｘｐｅｒ
ｔｓＧｒｏｕｐ）２など所定の圧縮方式で圧縮された
ＡＶデータと、デジタル伝送データとを多重化して構成
される「トランスポート・ストリーム」（後述）の形式
で、放送波として伝播される。

【０００９】デジタル伝送データに載せられる放送番組
情報の一例は、先述のＥＰＧ（ＥｌｅｃｔｒｉｃＰｒ
ｏｇｒａｍＧｕｉｄｅ：電子番組情報）である。ま
た、放送番組情報は、放送番組本体のタイトルや日付、
番組のキャスティングなど放送番組本体に関する固有の
情報を含むことができる。また、放送番組情報が含むデ
ータの種類やデータ構造は、番組本体が提供するサービ
ス内容に応じてある程度系統化される。例えば、料理番
組における献立や食材に関する情報や、選挙速報番組に
おける時々刻々更新される得票状況、プロ野球中継にお
ける各選手の打撃・投球に関する個人成績やチーム順位
などである。

【００１０】放送番組情報は、デジタル衛星データ放送
受信システム（以下、単に「受信システム」とする）側
では、放送番組本体を表示出力するディスプレイ・スク
リーンの一部の領域を使用して表示される。この受信シ
ステムは、通常は、放送波を受信・選局・デコードする
受信機（セット・トップ・ボックス：ＳＴＢ）と、表示
出力するテレビジョンとで構成され、一般家庭内に設置
される。

【００１１】ここで、デジタル伝送データとして配信さ
れるコンテンツ（以下、「配信コンテンツ」とする）の
構造について、図１３を参照しながら説明しておく。

【００１２】図１３に示すように、配信コンテンツは、
テキスト・データの他、静止画、動画、音声などの各種
様々なモノメディア・データと、これら各々のモノメデ
ィア・データを統合的すなわちマルチメディアとして取
り扱い、放送番組情報の有様を規定する表示・出力制御
プログラム（以下では、「マルチメディア符号化アプリ
ケーション」とも呼ぶ）とで構成される。表示・出力制
御プログラムには、各モノメディア・データに対する参
照（リンク）情報を組み込むことができる。

【００１３】先述したＡＲＩＢによるデジタル衛星デー
タ放送の標準化作業では、この配信コンテンツとしての
マルチメディア符号化アプリケーションを記述する形式
（フォーマット）として、当初はＭＨＥＧ（Ｍｕｌｔｉ
ｍｅｄｉａａｎｄＨｙｐｅｒｍｅｄｉａＥｘｐｅ
ｒｔＧｒｏｕｐ）の利用が検討されてきた。ＭＨＥＧ
は、データ属性を定義する記述言語の一種であり、マル
チメディア・コンテンツをテレビに表示し、ビデオ・オ
ン・デマンド（ＶＯＤ）やデジタル・テレビ放送におい
て視聴者が所望の情報を引き出すような用途を想定して
いる。日本のＣＳデジタル放送（ＳＫＹＰｅｒｆｅｃＴ
Ｖ）のように、既にＭＨＥＧ−５が使用されている例も
ある。

【００１４】しかしながら、ＭＨＥＧは、符号化空間が
固定的であり拡張性に欠ける。すなわち、一意に定めら
れた符号化空間のみを用いて記述しなければならないの
で、例えば関数（ＡＰＩ（ＡｐｐｌｉｃａｔｉｏｎＰ
ｒｏｇｒａｍｍｉｎｇＩｎｔｅｒｆａｃｅ）など）を
一つ変更するのにさえ、相当の修正作業を要する。ま
た、ＭＨＥＧは、一般的な認知度が低く、ＭＨＥＧで記
述されたデータ・コンテンツがあまり流通しておらず、
この意味において汎用コンピュータとの親和性が比較的
低い。

【００１５】そこで、ＡＲＩＢ（先述）では、ＭＨＥＧ
に代わって、ＸＭＬ（ｅＸｔｅｎｄｅｄＭａｒｋｕｐ
Ｌａｎｇｕａｇｅ）をベースとしたデータ放送の標準
化作業が検討されている。

【００１６】ＸＭＬは、タグの定義が任意、すなわち属
性の記述の仕方に制約がないので、自由度が高く、ま
た、汎用コンピュータやインターネットとの親和性が高
いことなどが、ＭＨＥＧよりも有利な点として挙げられ
る。また、ＸＭＬは、次世代インターネットの記述言語
としての策定も進められている。

【００１７】ＸＭＬをデジタル衛星放送の標準言語で用
いた場合、デジタル放送用データを、コンピュータやテ
レビジョン、電話機など、多種多様な情報機器間で情報
交換を行うことができる。また、ＸＭＬは、タグの属性
を任意に定義できることから、レイアウト指定に特化し
たＨＴＭＬに比しデータ処理に強い。このため、電子商
取引を含め、各分野への利用も急速に進みつつある。

【００１８】ＸＭＬ文書において任意なタグの設定が許
容することは、言い換えれば、文書中に書かれた文字列
を意味の付けられたデータとして扱うことを目的とする
ものである。すなわち、タグの定義により、タグで区切
られた各タグ・データを、単なる表示目的以外の意味を
持ったデータとして表現することができる。さらに、タ
グの構造を定義することで、ＸＭＬ文書又は該文書中の
データを構造化して記述することが可能となる。

【００１９】既に述べたように、ＡＲＩＢでは、ＸＭＬ
をベースにしてデジタル衛星データ放送の標準化を進め
ている。より具体的には、「基本ＸＭＬ」と、基本ＸＭ
Ｌの拡張版である「高度ＸＭＬ」に分けて、作業が行わ
れている。基本ＸＭＬは、ＸＭＬインスタンスをディス
プレイ上に表現するプレゼンテーション形式を、タグを
用いて記述することを規定したものである。

【００２０】これに対し、高度ＸＭＬは、ＸＭＬインス
タンスの属性情報を付加できるようにしたものである。
属性情報の記述方法（すなわちタグの文法）を定めたも
のが、ＤＴＤ（ＤｏｃｕｍｅｎｔＴｙｐｅＤｅｆｉ
ｎｉｔｉｏｎ）と呼ばれる規約である。基本ＸＭＬでは
タグが定義する属性情報は固定で、ＤＴＤは不要であ
る。これに対し、高度ＸＭＬでは、ＤＴＤは任意に定義
可能であり、例えば各業界毎にＤＴＤを一意に定めるこ
とができる。ここで言うタグの属性情報には、例えばテ
レビ受信機とコンピュータのように異機種間で接続した
ときに、各機器が互いにコンテンツの意味を理解して処
理するために必要な情報などが含まれる。

【００２１】ＸＭＬインスタンス自体は、表現形式に関
するスタイル情報を包含していないこともある。この場
合、ＸＭＬインスタンスの表現方法は、ＤＴＤとは別の
文書ファイルである「スタイルシート」によって記述さ
れる。

【００２２】スタイルシートは、例えば、ＸＭＬインス
タンスをディスプレイ・スクリーン上に表示出力する形
式に変換する（あるいはプリンタへの印刷出力形式に変
換する）ための文書ファイルである。ＸＭＬインスタン
ス用のスタイルシートは、特に「ＸＳＬ（ｅＸｔｅｎｓ
ｉｂｌｅＳｔｙｌｅｓｈｅｅｔＬａｎｇｕａｇ
ｅ）」形式の言語、「ＣＳＳ（ＣａｓｃａｄｅＳｔｙ
ｌｅｓｈｅｅｔ）」形式の言語、あるいは、その派生規
格である「ＸＳＬＴ（ＸＳＬＴｒａｎｓｆｏｒｍａｔ
ｉｏｎ）」形式の言語を用いて記述することかできる。
スタイルシートの記述次第で、書体やそのサイズ・色な
どを変化させて、同じＤＴＤコンテンツを全く別の形式
で表現することができる。スタイルシートは、ＤＴＤと
は別のファイルにして送信される。

【００２３】なお、スタイルシートの他に、音声や静止
画、動画など各モノメディアからなるマルチメディア・
コンテンツに関しては、ＸＭＬインスタンス又はスタイ
ルシート内で、ＸＭＬやＸＳＬとは別のスクリプトと呼
ばれる言語によって動作を規定することもできる。この
ようなスクリプトは、例えばＪａｖａＳｃｒｉｐｔ，Ｅ
ＣＭＡＳｃｒｉｐｔ，Ｊｓｃｒｉｐｔなどのスクリプト
言語で記述されるが、ＸＭＬ及びＸＳＬ等の規格では、
基本的にはＥＣＭＡＳｃｒｉｐｔで記述するように規定
されている（”ＥＣＭＡＳｃｒｉｐｔ”は、欧州電子計
算機工業会（ＥＣＭＡ）が規格化したスクリプト言語で
ある）。

【００２４】ＸＭＬ文書からなる配信コンテンツは、Ｘ
ＭＬ文書の他に、例えばＤＴＤ文書とスタイルシートを
伴なう。但し、ＸＭＬ文書がＤＴＤ文書を含まれない場
合や、ＸＭＬ文書の配信とは異なるタイミングでスタイ
ルシートが送付されることもある。また、配信コンテン
ツの記述言語は、必ずしもＸＭＬには限定されず、ＳＧ
ＭＬ（ＳｔａｎｄａｒｄＧｅｎｅｒａｌｉｚｅｄＭ
ａｒｋｕｐＬａｎｇｕａｇｅ）やＨＴＭＬなど、その
他のマークアップ言語形式であってもよい。また、例え
ばＸＭＬ文書がＴＶ放送に適用され、他のリアルタイム
型のデータとともに動作してプレゼンテーションを行う
場合には、各種のモノメディア・コンテンツのＵＲＩ
（ＵｎｉｆｏｒｍＲｅｓｏｕｒｃｅＩｄｅｎｎｔｉ
ｆｉｅｒ）と呼ばれる放送データ・モジュール内のモノ
メディア位置情報も、ＸＭＬ文書本体に組み込まれるこ
ともある。

【００２５】受信システム側では、受信したＸＭＬイン
スタンスを「ＸＭＬパーザ（Ｐｅｒｓｅｒ）」と呼ばれ
る構文解析プログラムでパージング処理する。すなわ
ち、ＸＭＬパーザは、ＤＴＤ文書及びＸＭＬインスタン
スを構造解析して、文書オブジェクトを出力する。この
文書オブジェクトは、元のＸＭＬ文書中のタグに従って
木構造が形成された構造化文書である。受信システムの
表示機能は、この文書の構造を解釈することで、画面上
のレイアウト等を決定し、ディスプレイへの表示出力が
可能となる。

【００２６】ところで、デジタル・データを放送やネッ
トワーク通信などの伝送手段で配信する場合、ＸＭＬ文
書やスクリプトなどのデータ・コンテンツを、元のテキ
スト形式からバイナリ（２進表示）形式の記述にデータ
圧縮してから送信することも考えられる。

【００２７】しかしながら、バイナリ形式のファイル構
造は、コンピュータ・システムやソフトによって異なる
ため、アプリケーションや端末間でのコンテンツ交換の
障害になりかねない。また、デジタル衛星データ放送の
上り回線として、ＴＣＰ／ＩＰ（Ｔｒａｎｓｍｉｓｓｉ
ｏｎＣｏｎｔｒｏｌＰｒｏｔｏｃｏｌ／Ｉｎｔｅｒ
ｎｅｔＰｒｏｔｏｃｏｌ）ベースで接続されるインタ
ーネットも想定している。このインターネットでは、テ
キスト形式のコンテンツ配信を採用することで、端末の
種類やソフトウエアに依存しない環境が築き上げられて
きたという歴史的経緯がある。

【００２８】そこで、デジタル衛星データ放送において
は、インターネットとの親和性やプラットフォーム間の
コンテンツ互換性を勘案し、テキスト形式のままデータ
・コンテンツを配信することが検討されている。

【００２９】ここで問題となるのが、配信コンテンツと
してのテキスト・データのサイズである。何故ならば、
データ・サイズに比例して、伝送路の負荷が増大し、伝
送効率が低下するからである。

【００３０】例えば、ＸＭＬ文書の高機能化又は高付加
価値化が進むにつれ、その表現形式や動作を規定するス
クリプトの文書サイズは肥大化する。今後、スクリプト
が表示対象そのものであるＸＭＬ文書本体よりもデータ
・サイズが大きくなることも予想される。肥大化したス
クリプトの配信は、有限な帯域の負荷に与える影響は大
きい。

【００３１】また、配信コンテンツを受信する受信装置
においても、膨大なデータを受信するには大容量のバッ
ファ・メモリを用意する必要があり、コスト増大を招来
する。また、メモリ・ロードに要する時間も長くなるた
め実行効率が低下してしまう。

【００３２】受信システムとして汎用コンピュータ・シ
ステムを用いる場合、通常、大容量のメモリを標準で搭
載しているので、メモリ負荷の問題は比較的小さい。こ
れに対し、セット・トップ・ボックスのような専用の衛
星放送受信機の場合、標準メモリのサイズは一般に小さ
いので、大容量の配信コンテンツは致命的である。

【００３３】

【発明が解決しようとする課題】本発明の目的は、テキ
スト・データからなるコンテンツ配信の伝送効率を向上
することができる、優れたデータ配信技術を提供するこ
とにある。

【００３４】本発明の更なる目的は、テキスト・データ
からなる配信コンテンツを受信する受信装置における実
行効率を向上するとともに、メモリ負荷を低減すること
ができる、優れたデータ配信技術を提供することにあ
る。

【００３５】

【課題を解決するための手段】本発明は、上記課題を参
酌してなされたものであり、その第１の側面は、配信コ
ンテンツを生成する方法であって、配信コンテンツを構
成するモジュールの１つとして作成された複数の文字又
は文字列からなるスクリプトの内部を検索して、冗長性
の高い文字又は文字列を抽出するステップと、スクリプ
ト中で抽出された冗長性の高い文字又は文字列を冗長性
の低い文字又は文字列で置き換えるステップと、を含む
ことを特徴とする配信コンテンツ生成方法である。前記
の冗長性の高い文字又は文字列は、例えば、関数名や変
数名などに相当する。

【００３６】本発明の第１の側面に係る配信コンテンツ
生成方法は、さらに、置換後の配信コンテンツを配信す
る前に一時蓄積するステップを含んでもよい。

【００３７】また、前記の冗長性の高い文字又は文字列
を冗長性の低い文字又は文字列で置き換えるステップで
は、冗長性の低い文字列としてのシステム予約語の使用
を排除するようにしてもよい。システム予約語まで抽出
し且つ他の文字又は文字列に置き換えてしまうと、元の
スクリプトが本来持つ意味、すなわちスクリプトが規定
する動作内容の変更を伴うことになり、許容し難いから
である。

【００３８】また、該配信コンテンツ生成方法は、さら
に、配信コンテンツの受信側で実行される処理に関与し
ない文字又は文字列からなる文を抽出するステップと、
該抽出された文を削除するステップとを含んでもよい。
ここで言う処理に関与しない文字又は文字列からなる文
は、例えば、所定のデリミッタで区切られたコメント文
に相当する。

【００３９】また、該配信コンテンツ生成方法は、さら
に、前記の冗長性の高い文字又は文字列を抽出するステ
ップで抽出された文字又は文字列の各々についてのスク
リプト中での出現頻度を積算するステップを含み、前記
の冗長性の高い文字又は文字列を冗長性の低い文字又は
文字列に置き換えるステップでは、出現頻度の大きい文
字又は文字列ほどより文字数の短い文字又は文字列に置
き換えるようにしてもよい。出現頻度の大きいものほ
ど、より短い文字又は文字列で表現されるので、データ
圧縮の効果が高まる。

【００４０】また、本発明の第２の側面は、複数のデー
タ・モジュールで構成されるコンテンツを配信するコン
テンツ配信方法又は装置であって、複数の文字又は文字
列からなるスクリプト言語形式で記述されたデータ・モ
ジュールの内部を検索して、冗長性の高い文字又は文字
列を抽出するステップ又は手段と、スクリプト中で抽出
された冗長性の高い文字又は文字列を冗長性の低い文字
又は文字列で置き換えるステップ又は手段と、置換後の
データ・モジュールを蓄積するステップ又は手段と、蓄
積されたデータ・モジュールを配信するステップ又は手
段と、を含むことを特徴とするコンテンツ配信方法又は
装置である。ここで言う冗長性の高い文字又は文字列と
は、例えば、関数名や変数名に相当する。

【００４１】また、前記の冗長性の高い文字又は文字列
を冗長性の低い文字又は文字列で置き換えるステップ又
は手段は、冗長性の低い文字列としてのシステム予約語
の使用を排除するようにしてもよい。システム予約語ま
で抽出し且つ他の文字又は文字列に置き換えてしまう
と、元のスクリプトが本来持つ意味、すなわちスクリプ
トが規定する動作内容の変更を伴うことになり、許容し
難いからである。

【００４２】また、本発明の第２の側面に係るコンテン
ツ配信方法又は装置は、さらに、配信コンテンツの受信
側で実行される処理に関与しない文字又は文字列からな
る文を抽出するステップ又は手段と、該抽出された文を
削除するステップ又は手段を含んでもよい。ここで言う
処理に関与しない文字又は文字列からなる文は、所定の
デリミッタで区切られたコメント文に相当する。

【００４３】また、本発明の第２の側面に係るコンテン
ツ配信方法又は装置は、さらに、前記の冗長性の高い文
字又は文字列を抽出するステップで抽出された文字又は
文字列の各々についてのスクリプト中での出現頻度を積
算するステップ又は手段を含み、前記の冗長性の高い文
字又は文字列を冗長性の低い文字又は文字列に置き換え
るステップ又は手段は、出現頻度の大きい文字又は文字
列ほどより文字数の短い文字又は文字列に置き換えるよ
うにしてもよい。出現頻度の大きいものほど、より短い
文字又は文字列で表現されるので、データ圧縮の効果が
高まる。

【００４４】また、本発明の第３の側面は、コンピュー
タ処理に関する意味を持つ複数の文字又は文字列で構成
されるソース・コードを変換する方法であって、ソース
・コード中を検索して、冗長性の高い文字又は文字列を
抽出するステップと、抽出された冗長性の高い文字又は
文字列を冗長性の低い文字又は文字列で置き換えるステ
ップと、を含むことを特徴とするコード変換方法であ
る。ここで言う冗長性の高い文字列とは、例えば、関数
名や変数名に相当する。

【００４５】本発明の第３の側面に係るコード変換方法
において、前記の冗長性の高い文字又は文字列を冗長性
の低い文字又は文字列で置き換えるステップでは、冗長
性の低い文字列としてのシステム予約語の使用を排除す
るようにしてもよい。システム予約語まで抽出し且つ他
の文字又は文字列に置き換えてしまうと、元のスクリプ
トが本来持つ意味、すなわちスクリプトが規定する動作
内容の変更を伴うことになり、許容し難いからである。

【００４６】また、本発明の第３の側面に係るコード変
換方法は、さらに、ソース・コード中で該コードの実行
に関与しない文字又は文字列からなる文を抽出するステ
ップと、該抽出された文を削除するステップとを含んで
もよい。ここで言うコードの実行に関与しない文字又は
文字列からなる文は、所定のデリミッタで区切られたコ
メント文に相当する。

【００４７】また、本発明の第３の側面に係るコード変
換方法は、さらに、前記の冗長性の高い文字又は文字列
を抽出するステップで抽出された文字又は文字列の各々
についてのスクリプト中での出現頻度を積算するステッ
プ又は手段を含み、前記の冗長性の高い文字又は文字列
を冗長性の低い文字又は文字列に置き換えるステップ又
は手段は、出現頻度の大きい文字又は文字列ほどより文
字数の短い文字又は文字列に置き換えるようにしてもよ
い。出現頻度の大きいものほど、より短い文字又は文字
列で表現されるので、データ圧縮の効果が高まる。

【００４８】

【作用】本発明は、デジタル衛星データ放送において、
放送番組とともに配信されるデジタル伝送データ、特
に、該伝送データのうちテキスト形式で記述されたデー
タ・ファイルに対して好適に適用することができる。

【００４９】［従来の技術］の欄で既に説明したよう
に、デジタル伝送データを構成するモジュールは、静止
画、動画、音声などの各種様々なモノメディア・データ
と、これら各々のモノメディア・データを統合的すなわ
ちマルチメディアとして取り扱い、放送番組情報の有様
を規定する表示・出力制御プログラム（以下では、「マ
ルチメディア符号化アプリケーション」とも呼ぶ）とで
構成される。

【００５０】このモジュール内のファイルのうち、テキ
スト形式データで構成されるものの１つは、表示・出力
制御プログラムであり、そのコンテンツはタグでデータ
属性が定義されるマークアップ記述言語（ＸＭＬやＳＧ
ＭＬ、ＨＴＭＬなど）で記述されている。

【００５１】また、該モジュールに含まれる他のテキス
ト形式データは、この音声や静止画、動画などの各者メ
ディア・データの動作を規定するスクリプトである。ス
クリプトは、例えばＪａｖａＳｃｒｉｐｔ，ＥＣＭＡＳ
ｃｒｉｐｔ，ＪＳｃｒｉｐｔなどのスクリプト言語で記
述することができる（ＸＭＬ及びＸＳＬ等の規格では、
基本的にはＥＣＭＡＳｃｒｉｐｔで記述するように規定
されている）。

【００５２】ＸＭＬ形式等で記述された表示・出力制御
プログラム自体は、画面表示又は印刷出力する情報その
ものを規定したものであり、そのテキスト・データの内
容変更はデータ自体の意味（すなわち該プログラムが規
定する動作）の変化を伴なってしまうので、許容し難
い。

【００５３】他方、スクリプトの場合、コード中に含ま
れる関数名や変数名、コメント文などは冗長性を含み、
伝送効率上致命的となる。関数名や変数名などは、そも
そも、スクリプト作成者が、コーディングやデバッグ作
業における可読性などの便宜のため（あるいは個人的な
好みに従って）命名したものであり、スクリプト自体が
規定する動作機能とは無関係である。言い換えれば、こ
れら関数名や変数名は、スクリプト自体の動作機能を維
持したままで、他の文字列との可換性がある。また、コ
メント文は、スクリプト実行には無関係であり、省略す
ることすら可能である。

【００５４】本発明は、このようなテキスト形式で記述
されたスクリプトが包含する冗長性に着眼してなされた
ものである。要するに、本発明は、スクリプト中に存在
する、比較的長い文字列からなる関数名や変数名を、よ
り短い文字列（例えばアルファベット１文字）で置き換
えることにより、スクリプトのデータ・サイズを削減す
るものである。また、さらにスクリプト中のコメント文
を削除することにより、データ・サイズを削減するもの
である。

【００５５】スクリプト中の関数名や変数名は、スクリ
プトの作成者が、各々の関数や変数の人手による可読性
を保つために便宜上命名したものであり、人が理解可能
な意味を持つ程度の比較的長い文字列で構成される。ま
た、コメント文は、スクリプト中の各部分（例えばルー
チン文など）の機能をメモするためにソース・コード中
に埋め込まれるが、それ自体はスクリプトの機能実現に
寄与しない。

【００５６】これら長い文字列からなる関数名や変数
名、コメント文は、デバックまでの間は意味を持つが、
デバッグ以降は、人が解釈可能な意味を持つ必要はな
い。特に、衛星データ放送のように一方向性のコンテン
ツ配信に適用する場合には、送信した以後の段階でのソ
ース・コードの再利用を考慮する必要がない。言い換え
れば、スクリプト中の関数名や変数名を他の短い文字列
に置き換えたり、コメント文を削除して、人がソース・
コードの意味内容を解釈し難くなっても、その弊害はほ
とんどないと言える。

【００５７】本発明を、デジタル衛星データ放送におけ
るデジタル伝送データに適用することにより、伝送デー
タ・サイズを削減することができ、配信時においては伝
送効率が向上する。

【００５８】また、受信局においては、受信データ・サ
イズが低下するので、比較的小容量の受信メモリを用意
するだけで済み、コスト削減につながる。また、スクリ
プト中の関数名や変数名の文字列長が最小になることか
ら、スクリプトを実行するインタープリタがメモリに割
り当てる関数テーブル、変数テーブルのサイズを小さく
することができる。この結果、関数や変数を呼び出す際
のオーバーヘッドが少なくなる。すなわち、スクリプト
の実行効率が向上する上に、メモリを小容量化して受信
機コストを削減することができる。受信機のユーザ（す
なわち視聴者）は、実行効率の向上により、より高速な
システムの反応を期待することかできる。

【００５９】本発明のさらに他の目的、特徴や利点は、
後述する本発明の実施例や添付する図面に基づくより詳
細な説明によって明らかになるであろう。

【００６０】

【発明の実施の形態】以下、図面を参照しながら本発明
の実施例を詳解する。

【００６１】図１には、本発明の実施に供される衛星デ
ジタル放送システム１０００の概略構成を示している。
同図に示すように、衛星デジタル放送システム１０００
は、放送サービスを提供する放送局（Ｂｒｏａｄｃａｓ
ｔＳｅｒｖｅｒ）１と、放送データを中継する放送衛
星（Ｓａｔｅｌｌｉｔｅ）５と、放送衛星５から放送デ
ータを受信する受信局（Ｒｅｃｅｉｖｅｒ／Ｄｅｃｏｄ
ｅｒ）１０とで構成される。

【００６２】放送局１は地上に１基以上存在し、放送衛
星５は地球のはるか上空に散在する。また、受信局１０
は、一般家庭などに相当し、実際には地上に無数存在す
る。放送局１及び放送衛星５を介したデータ配信すなわ
ち放送は、一方向通信である。

【００６３】デジタル・データ放送では、１０〜５０Ｍ
ｂｐｓの転送レートでデータ伝送される。放送局１は、
放送番組本体を構成するＡＶデータと、放送番組に付随
する番組情報を含んだデジタル伝送データを多重化して
配信する。ＡＶデータは、通常、ＭＰＥＧ（Ｍｏｔｉｏ
ｎＰｉｃｔｕｒｅＥｘｐｅｒｔｓＧｒｏｕｐ）２
形式でデータ圧縮して送信される。

【００６４】デジタル伝送データには、テキストや静止
画、動画、音声など各種モノメディア・データと、これ
らモノメディア・データの表示・出力を制御するプログ
ラムである「マルチメディア符号化アプリケーション」
とで構成されるモジュールが、データ・カルーセル化さ
れて格納されている。マルチメディア符号化アプリケー
ションは、ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅＭａｒｋｕ
ｐＬａｎｇｕａｇｅ）言語形式で記述されており、文
書の型式を定義するＤＴＤ文書と、ＸＳＬなどの言語形
式で記述されたスタイルシートを含む（但し、ＤＴＤ文
書及び／又はスタイルシートを配信コンテンツに含まな
い場合もある）。また、各モジュールには、音声や静止
画、動画などの動作を規定するスクリプトが含まれてい
る。

【００６５】各受信局１０と放送局１との間は、インタ
ーネットのような広域ネットワーク７、又は、専用線
（図示しない）などによって双方向接続されていてもよ
い。この場合、インターネット７を、受信局１０から放
送局１に向かう上り回線として使用することができる。
例えば、インターネット７を利用した一部オンデマンド
放送サービスを提供することも可能である。但し、この
場合、両者間は、５６ｋｂｐｓ以上の高速アナログ電話
回線、１０〜６４ｋｂｐｓ程度の高速ワイヤレス通信、
１２８ｋｂｐｓのＩＳＤＮ（ＩｎｔｅｇｒａｔｅｄＳ
ｅｒｖｉｃｅｓＤｉｇｉｔａｌＮｅｔｗｏｒｋ）、あ
るいは５〜３０Ｍｂｐｓクラスのケーブルによって接続
されていることが好ましい。

【００６６】図２には、放送局１すなわち送信システム
の構成を模式的に示している。同送信システム１は、制
作部１００と、送出部２００と、伝送部３００とで構成
される。以下、各部について説明する。

【００６７】制作部１００は、放送番組のコンテンツを
制作する現場に相当する。制作部１００は、データ放送
の内容を記述したＸＭＬ文書と、このＸＭＬ文書の動作
を規定するスクリプトと、放送番組の本体であるＡＶデ
ータなどの情報を制作し、それぞれをローカルの大容量
記憶装置１０２及び１０３に蓄積する。

【００６８】ＸＭＬ文書とスクリプトは、デジタル伝送
データを構成する各モジュールのリソース（後述及び図
７，図８を参照のこと）に相当する。これらデジタル伝
送データは、編集システム１０１上でコーディング／デ
バッグ等の編集処理が行われる。編集システム１０１の
実体は、ワークステーションやパーソナル・コンピュー
タと呼ばれる汎用コンピュータ・システムでよい。

【００６９】ＸＭＬ文書は、任意に定義可能なタグを使
用したマークアップ言語（前述）であり、文書型を定義
するＤＴＤ文書を添付してもよい。この場合のＸＭＬ文
書は、受信局１０における出力用のデータ本体である。
スクリプトは、ＸＭＬ文書の動作を規定したものであ
り、ＪａｖａＳｃｒｉｐｔ，ＥＣＭＡＳｃｒｉｐｔ，Ｊ
Ｓｃｒｉｐｔなどのスクリプト言語で記述されたテキス
ト形式のファイルである（ＸＭＬ及びＸＳＬ等の規格で
は、基本的にはＥＣＭＡＳｃｒｉｐｔで記述するように
規定されている）。なお、デジタル伝送データは、ＸＭ
Ｌ文書とスクリプト以外に、音声データや静止画データ
などのマルチメディア・コンテンツを含んでいてもよ
い。

【００７０】制作部１００において制作され蓄積された
これら配信コンテンツは、例えば、放送局１内に敷設さ
れたＬＡＮ（ＬｏｃａｌＡｒｅａＮｅｔｗｏｒｋ）
経由で、送出部２００に転送される。

【００７１】送出部２００では、コンテンツ送信系２０
１、ベースバンド制御系１０２及びＡＶエンコーダ２０
３の各々によって送出データがパケット化されて、伝送
部３００に渡す。ＡＶエンコーダ２０３は、放送番組の
本体であるＡＶデータを、例えばＭＰＥＧ２などの圧縮
方式により符号化圧縮する。

【００７２】伝送部３００では、コンテンツ系のデータ
はマルチメディア符号化部３０１において符号化されて
コンテンツ伝送系３０２に渡される。合成部３０４は、
コンテンツ伝送系３０２及びＡＶデータ伝送系３０３の
各々の出力データを合成する。そして、変調部３０５で
は、合成信号をＲＦ変調して、ＲＦ伝送路を介して受信
局１０へ向けて送信する。

【００７３】ＲＦ伝送路では、ＲＦ信号は、まず、放送
局１に設置された送信アンテナから放送衛星５へ送信さ
れ、次いで、放送衛星５を経由して受信局１０の受信ア
ンテナで受信される。

【００７４】図３には、受信局１０に設置されるデジタ
ル衛星データ放送受信システムの一例１０−Ａのハード
ウェア構成を模式的に示している。該受信システム１０
−Ａは、例えばＳＴＢ（セット・トップ・ボックス）と
呼ばれる形態で一般家庭に普及している。受信システム
１０Ａ内では、メイン・コントローラとしてのＣＰＵ１
１は、バス５０を介して各ハードウェア・コンポーネン
トと相互接続して、各コンポーネントに対して統括的な
制御を実行するようになっている。以下、各部について
説明する。

【００７５】アンテナ（図示しない）で受信された放送
波は、チューナ５１に供給される。放送波は、規定のフ
ォーマットに従っており、例えば番組ガイド情報（ＥＰ
Ｇ：ＥｌｅｃｔｒｉｃＰｒｏｇｒａｍＧｕｉｄｅ）
等を含んでいる。なお、放送波としては、上記した放送
波以外に、有線放送波や地上波でもよく、特に限定され
ない。

【００７６】チューナ５１は、ＣＰＵ１１からの指示に
従い、所定チャネルの放送波のチューニングすなわち選
局を行い、後続の復調器５２に受信データを出力する。
復調器５２では、デジタル変調されている受信データを
復調する。なお、送信されてくる放送波がアナログかデ
ジタルかに応じて、チューナ１１の構成を適宜変更又は
拡張することができる。

【００７７】復調されたデジタル・データは、ＭＰＥＧ
２圧縮されたＡＶデータと、デジタル伝送データとが多
重化されて構成される「トランスポート・ストリーム」
である。前者のＡＶデータは、放送番組本体を構成する
映像及び音声情報である。また、後者のデジタル伝送デ
ータは、この放送番組本体に付随するデータであり、例
えばＥＰＧ（ＥｌｅｃｔｒｉｃＰｒｏｇｒａｍＧｕ
ｉｄｅ：電子番組ガイド）を含む。デジタル伝送データ
については後に詳解する。なお、トランスポート・スト
リームは、ＯＳＩ（ＯｐｅｎＳｙｓｔｅｍｓＩｎｔ
ｅｒｃｏｎｎｅｃｔｉｏｎ）参照モデルで言う「トラン
スポート層」に分類される。

【００７８】ＴＳデコーダ５３は、このトランスポート
・ストリームを解釈して、ＭＰＥＧ２圧縮されたＡＶデ
ータとデジタル伝送データとに分離して、前者をＡＶデ
コーダ５４に送出するとともに、後者をバス５０経由で
ＣＰＵ１１に送信する。ＴＳデコーダ５３は、作業デー
タ保管用のメモリ５３Ａを自己のローカルに備えていて
もよい。

【００７９】ＡＶデコーダ５４は、ＭＰＥＧ２方式で圧
縮されたリアルタイムＡＶデータをＴＳデコーダ５３か
ら受け取ると、圧縮映像データと圧縮音声データとに分
離する。そして、映像データに対してはＭＰＥＧ２伸長
処理してもとの映像信号を再生し、音声データに対して
はＰＣＭ（ＰｕｌｓｅＣｏｄｅＭｏｄｕｌａｔｉｏ
ｎ）デコードした後に付加音と合成して再生音声信号と
する。ＡＶデコーダ５４は、作業データ保管用のメモリ
５４Ａを自己のローカルに備えていてもよい。再生映像
信号は、マルチプレクサ５５Ｂを介してディスプレイ６
１に表示出力され、また、再生音声信号は、マルチプレ
クサ５５Ａを介してスピーカ６２に音声出力される。

【００８０】ユーザ・インターフェース制御部５６は、
ユーザからの入力操作を処理するモジュールであり、例
えば、ユーザが直接マニュアル操作するための操作ボタ
ン／スイッチ（図示しない）や、赤外線（ＩＲ）などを
介したリモコン６６からの遠隔操作を受容する機能を備
えている。また、現在の設定内容を表示するための表示
パネルやＬＥＤインジケータ（図示しない）を含んでい
てもよい。

【００８１】ユーザ・インターフェース制御部５６が持
つ操作ボタン、又は、リモコン６６が持つ操作ボタンの
１つは、ＯＳＣ表示コントローラ５７からの表示出力
（すなわちデジタル伝送データに基づく番組情報等の表
示出力）の有効化／無効化を操作するボタンに割り当て
られている。

【００８２】ＣＰＵ（ＣｅｎｔｒａｌＰｒｏｃｅｓｓ
ｉｎｇＵｎｉｔ）１１は、受信システム１０−Ａ全体
の動作を統括するメイン・コントローラである。また、
ＣＰＵ１１は、バス５０経由で転送されてくるデジタル
伝送データの処理を行うことができる。デジタル伝送デ
ータは、ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅＭａｒｋｕｐ
Ｌａｎｇｕａｇｅ）言語形式で記述されており（後
述）、ＣＰＵ１１は、このＸＭＬ文書に対するＸＭＬパ
ージングブラウジング（表示出力又は印刷出力）などの
処理ソフトウェア（後述）を、オペレーティング・シス
テム（ＯＳ）によって提供されるプラットフォーム上
で、実行することができる。

【００８３】ＲＡＭ（ＲａｎｄｏｍＡｃｃｅｓｓＭ
ｅｍｏｒｙ）１２は、ＣＰＵ１１の実行プログラム・コ
ードをロードしたり、実行プログラムの作業データを書
き込むために使用される、書き込み可能な揮発性メモリ
である。また、ＲＯＭ（ＲｅａｄＯｎｌｙＭｅｍｏ
ｒｙ）１３は、受信システム１０−Ａの電源投入時に実
行する自己診断・初期化プログラムや、ハードウェア操
作用のマイクロコードを恒久的に格納する読み出し専用
メモリである。

【００８４】シリアル入出力（ＳＩＯ）コントローラ１
４は、受信システム１０−Ａ外部の機器とシリアル的な
データ交換を行うための周辺コントローラである。ＳＩ
Ｏコントローラ１４が用意するシリアル・ポートには、
アナログ電話回線上の伝送データを変復調するための高
速モデム６３（例えば、転送レートが５６Ｋｂｐｓ）が
外部接続されている。この高速モデム６３によって所定
のアクセス・ポイント（図示しない）にＰＰＰ（Ｐｏｉ
ｎｔ−ｔｏ−ＰｏｉｎｔＰｒｏｔｏｃｏｌ）接続する
ことで、受信システム１０−Ａは広域ネットワークとし
てのインターネット７に接続される。

【００８５】ＩＥＥＥ１３９４インターフェース１５
は、数１０ＭＢｐｓ程度のデータ送受信が可能なシリア
ル高速インターフェースである。ＩＥＥＥ１３９４ポー
トには、ＩＥＥＥ１３９４対応の外部機器をデイジーチ
ェーン接続又はツリー接続することができる。ＩＥＥＥ
１３９４対応機器としては、例えば、ビデオ・カメラ６
４やスキャナ（図示しない）などが挙げられる。

【００８６】ハード・ディスク・ドライブ（ＨＤＤ）１
７は、プログラムやデータなどを所定フォーマットのフ
ァイル形式で蓄積するための外部記憶装置であり、通
常、数ＧＢ程度の比較的大容量を持つ。ＨＤＤ１７は、
ハード・ディスク・インターフェース１８を介してバス
５０に接続される。

【００８７】カード・インターフェース１８は、カード
・スロット１９に装填されたカード型デバイス６５とバ
ス５０との間でのバス・プロトコルを実現するための装
置である。カード型デバイス６５の一例は、クレジット
カード・サイズでカートリッジ式に構成されたＰＣカー
ドである。ＰＣカードは、ＰＣＭＣＩＡ（Ｐｅｒｓｏｎ
ａｌＣｏｍｐｕｔｅｒＭｅｍｏｒｙＣａｒｄＩ
ｎｔｅｒｆａｃｅＡｓｓｏｃｉａｔｉｏｎ）及びＪＥ
ＩＤＡ（ＪａｐａｎＥｌｅｃｔｒｏｎｉｃＩｎｄｕｓ
ｔｒｙＤｅｖｅｌｏｐｍｅｎｔＡｓｓｏｃｉａｔｉ
ｏｎ）が共同で策定した仕様”ＰＣＣａｒｄＳｔａ
ｎｄａｒｄ”に準拠する。

【００８８】ＰＣカードの一例は、ＥＥＰＲＯＭ（Ｅｌ
ｅｃｔｒｉｃａｌｌｙＥｒａｓａｂｌｅａｎｄＰ
ｒｏｇｒａｍｍａｂｌｅＲＯＭ）などの不揮発且つ消
去再書き込み可能なメモリ・チップで構成されるメモリ
・カードである。受信システム１０−Ａが比較的小型且
つ安価に構成される場合、大容量且つ大容積のＨＤＤ１
７を搭載することが、設計上困難な場合がある。このよ
うな場合、システム１０−Ａに対して着脱自在で可搬性
に優れたメモリ・カードを適用することが好ましいと想
定される。但し、着脱式のメモリ６５は、ＰＣカードの
フォームファクタに限定されず、所謂「メモリ・スティ
ック」であってもよい。

【００８９】表示コントローラ５７は、デジタル伝送デ
ータに基づく放送番組情報等の表示出力を制御するため
の専用コントローラである。

【００９０】このデジタル衛星データ受信システム１０
−Ａでは、ＣＰＵ１１は、ユーザ・インターフェース制
御部５６を介したユーザ入力コマンドに従って、チュー
ナ５１の選局動作を制御するとともに、番組情報の表示
制御などが行われる。すなわち、ＣＰＵ１１は、ＴＳデ
コーダ５３から転送されてきたデジタル放送用データを
処理して、表示用のデータに変換して表示コントローラ
５７に供給する。表示コントローラ５７は、この表示デ
ータを基に番組情報の画像信号を生成し、マルチプレク
サ５５Ｂに供給する。また、ＣＰＵ１１は、デジタル放
送用データに含まれる音声データも処理して、これをバ
ス５０経由でマルチプレクサ５５Ａに供給する。マルチ
プレクサ５５Ａ及び５５Ｂは、ＣＰＵ１１から供給され
た表示用データと音声データの各々を、ＡＶデコーダ５
４から出力される放送番組本体としての映像データ及び
音声データと多重化して、ディスプレイ６１とスピーカ
６２の各々に外部出力する。なお、デジタル放送用デー
タの処理については、後に詳解する。

【００９１】図４には、他の例に係るデジタル放送デー
タ受信システム１０−Ｂのハードウェア構成を模式的に
示している。この例に係る受信システム１０−Ｂは、例
えば、汎用コンピュータ・システム３０に対して衛星デ
ジタル放送用のデジタル・チューナ・カード４０を装備
する、という形態で実装される。

【００９２】デジタル・チューナ・カード４０は、チュ
ーナ５１と、復調器５２と、ＴＳデコーダ５３と、ＡＶ
デコーダ５４と、各ＲＡＭ５３Ａ及び５４Ａと、マルチ
プレクサ５５Ａ及び５５Ｂとで構成される。図３に示し
たものと同じ参照番号を持つハードウェア・ブロックと
は、その構成及び機能は略同一である。このデジタル衛
星放送用チューナ・カード４０は、バス・インターフェ
ース（ＰＣＩインターフェース）５８（図示）を介して
コンピュータ・システム３０内のシステム・バス（ＰＣ
Ｉバス）３１に接続される。

【００９３】アンテナ（図示しない）から受信された放
送波は、チューナ５１で選局され、復調器５２で復調さ
れる。ＴＳデコーダ５３は、トランスポート・ストリー
ムを解釈し、ＭＰＥＧ２圧縮されたＡＶデータとデジタ
ル伝送データに分離する。ＡＶデータの方はＡＶデコー
ダ５４に供給され、上述と同様に処理され、ディスプレ
イ６１やスピーカ６２などに外部出力される。また、デ
ジタル伝送データの方は、ＰＣＩインターフェース５８
経由でコンピュータ・システム３０側に転送され、該シ
ステム内部のＣＰＵ１１によって処理される（後述）。

【００９４】他方、汎用コンピュータ・システム３０
は、ＣＰＵ１１（後述）を始めとする主要回路コンポー
ネントを搭載した印刷配線基板（図示しない）を含んで
ある。該基板は「マザーボード」とも呼ばれる。先述の
チューナ・カード４０は、例えば「アダプタ・カード」
の形態で提供され、マザーボード上に配設されたバス・
スロット（図示しない）に装着される。

【００９５】但し、チューナ・カード４０は、アダプタ
・カードという形態ではなく、ＰＣＭＣＩＡ（Ｐｅｒｓ
ｏｎａｌＣｏｍｐｕｔｅｒＭｅｍｏｒｙＣａｒｄ
ＩｎｔｅｒｎａｔｉｏｎａｌＡｓｓｏｃｉａｔｉｏ
ｎ）／ＪＥＩＤＡ（ＪａｐａｎＥｌｅｃｔｒｏｎｉｃ
ＩｎｄｕｓｔｒｙＤｅｖｅｌｏｐｍｅｎｔＡｓｓ
ｏｃｉａｔｉｏｎ）の策定仕様に準拠したＰＣカードの
形式で提供され、ＰＣカード・スロット１９（後述）に
挿入することによっても、コンピュータ・システム３０
のシステム構成に組み込まれる。

【００９６】ＣＰＵ１１は、コンピュータ・システム３
０全体の動作を統括的に制御するメイン・コントローラ
である。この例に係るＣＰＵ１１は、オペレーティング
・システム（ＯＳ）によって提供されるプラットフォー
ム上で、ＸＭＬパージングやＸＳＬプロセッシング、ブ
ラウジングなど、ＸＭＬコンテンツ処理のための各種ソ
フトウェア・プログラム（後述）を実行することができ
る。

【００９７】ＣＰＵ１１の外部ピンに直結したプロセッ
サ・バスは、バス・ブリッジ２０を介してシステム・バ
ス３１に相互接続されている。

【００９８】本実施例のバス・ブリッジ２０は、プロセ
ッサ・バスとシステム・バス３１間の速度差を吸収する
ためのデータ・バッファの他、ＲＡＭ１２へのメモリ・
アクセスを制御するメモリ・コントローラを含んだ構成
となっている。

【００９９】ＲＡＭ（ＲａｎｄｏｍＡｃｃｅｓｓＭ
ｅｍｏｒｙ）１２は、ＣＰＵ１１の実行プログラム・コ
ードをロードしたり、実行プログラムの作業データを書
き込むために使用される、書き込み可能な揮発性メモリ
である。通常は、複数個のＤＲＡＭ（ダイナミックＲＡ
Ｍ）チップで構成される。

【０１００】システム・バス３１は、アドレス・バス、
データ・バス、コントロール・バスなどを含んだ共通信
号伝送路であり、例えばＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ
ＣｏｍｐｏｎｅｎｔＩｎｔｅｒｃｏｎｎｅｃｔ）バ
スがこれに相当する。システム・バス３１上には、ＰＣ
Ｉインターフェース仕様に合致した各種周辺機器が相互
接続されている。周辺機器の一例は、先述のデジタル衛
星放送用チューナ・カード４０である。これらバス３１
上の各周辺機器にはそれぞれに固有のＩ／Ｏアドレス
（又はメモリ・アドレス）が割り振られており、ＣＰＵ
１１（より厳密にはＣＰＵ１１が実行するプログラム）
は、Ｉ／Ｏアドレス（又はメモリ・アドレス）を指定す
ることで所望の周辺機器に対するデータやコマンドの転
送を実現することができる。

【０１０１】ＲＯＭ（ＲｅａｄＯｎｌｙＭｅｍｏｒ
ｙ）１３は、コンピュータ・システム３０の電源投入時
に実行する自己診断プログラム（ＰＯＳＴ）や、ハード
ウェア操作用の基本入出力システム（ＢＩＯＳ）を恒久
的に格納する読み出し専用メモリである。ＲＯＭ１３
は、例えば電気的な消去及び再書き込み動作が可能なＥ
ＥＰＲＯＭ（ＥｌｅｃｔｒｉｃａｌｌｙＥｒａｓａｂ
ｌｅａｎｄＰｒｏｇｒａｍｍａｂｌｅＲＯＭ）で
構成されていてもよい。

【０１０２】シリアル入出力（ＳＩＯ）コントローラ１
４は、コンピュータ・システム３０外部の機器とシリア
ル的なデータ交換を行うための周辺コントローラであ
る。ＳＩＯコントローラ１４が用意するシリアル・ポー
トには、アナログ電話回線上の伝送データを変復調する
ための高速モデム６３（例えば、転送レートが５６Ｋｂ
ｐｓ）が外部接続されている。高速モデム６３によって
所定のアクセス・ポイント（図示しない）にＰＰＰ（Ｐ
ｏｉｎｔ−ｔｏ−ＰｏｉｎｔＰｒｏｔｏｃｏｌ）接続
することで、コンピュータ・システム３０（すなわち受
信システム１０−Ｂ）はインターネットに接続される。

【０１０３】ＩＥＥＥ１３９４インターフェース１５
は、数１０ＭＢｐｓ程度のデータ送受信が可能なシリア
ル高速インターフェースである。ＩＥＥＥ１３９４ポー
トには、ＩＥＥＥ１３９４対応の外部機器をデイジーチ
ェーン接続又はツリー接続することができる。ＩＥＥＥ
１３９４対応機器には、例えば、ビデオ・カメラ６４や
スキャナ（図示しない）などが挙げられる。

【０１０４】ハード・ディスク・ドライブ（ＨＤＤ）１
７は、プログラムやデータなどを所定フォーマットのフ
ァイル形式で蓄積するための外部記憶装置であり、通
常、数ＧＢ程度の比較的大容量を持つ。ＨＤＤ１７は、
ハード・ディスク・インターフェース１６を介してシス
テム・バス３３に接続される。ハード・ディスク・ドラ
イブをコンピュータ・システム３０に接続するインター
フェース規格は、例えばＩＤＥ（Ｉｎｔｅｇｒａｔｅｄ
ＤｒｉｖｅＥｌｅｃｔｒｏｎｉｃｓ）やＳＣＳＩ
（ＳｍａｌｌＣｏｍｐｕｔｅｒＳｙｓｔｅｍＩｎ
ｔｅｒｆａｃｅ）などである。

【０１０５】キーボード／マウス・コントローラ（ＫＭ
Ｃ）２１は、キーボード２２やマウス２３などからのユ
ーザ入力を処理するための専用コントローラである。Ｋ
ＭＣ２１は、キーボード２２からのスキャン・コード入
力やマウス２３からの座標指示入力を検出したことに応
答して、ＣＰＵ１１に対して割り込み要求を発行する。
本実施例では、コンピュータ・システム３０に対する通
常のコマンド入力の他、チャネルの選択などの受信シス
テム１０−Ｂに対する入力操作も、キーボード２２やマ
ウス２３を介して行うことができる。

【０１０６】キーボード２２が持つファンクション・キ
ーの１つ、又は、ディスプレイ６１上に配設されたメニ
ュー・ボタンの１つは、ビデオ・コントローラ２４から
の表示出力（すなわちデジタル伝送データに基づく番組
情報等の表示出力）の有効化／無効化を操作するボタン
に割り当てられている。

【０１０７】カード・インターフェース１８は、バス５
０とカード・スロット１９に装填されたカード型デバイ
ス６５との間でのバス・プロトコルを実現するための装
置である。カード型デバイス６５の一例は、クレジット
カード・サイズでカートリッジ式に構成されたＰＣカー
ドである。ＰＣカードは、ＰＣＭＣＩＡ（Ｐｅｒｓｏｎ
ａｌＣｏｍｐｕｔｅｒＭｅｍｏｒｙＣａｒｄＩ
ｎｔｅｒｆａｃｅＡｓｓｏｃｉａｔｉｏｎ）及びＪＥ
ＩＤＡ（ＪａｐａｎＥｌｅｃｔｒｏｎｉｃＩｎｄｕｓ
ｔｒｙＤｅｖｅｌｏｐｍｅｎｔＡｓｓｏｃｉａｔｉ
ｏｎ）が共同で策定した仕様”ＰＣＣａｒｄＳｔａ
ｎｄａｒｄ”に準拠する。

【０１０８】ＰＣカードの一例は、ＥＥＰＲＯＭ（Ｅｌ
ｅｃｔｒｉｃａｌｌｙＥｒａｓａｂｌｅａｎｄＰ
ｒｏｇｒａｍｍａｂｌｅＲＯＭ）などの不揮発且つ消
去再書き込み可能なメモリ・チップで構成されるメモリ
・カードである。デジタル衛星放送受信システム１０−
Ｂが比較的小型且つ安価に構成される場合、大容量且つ
大容積のＨＤＤ１７を搭載することが、設計上困難な場
合がある。このような場合、受信システム１０−Ｂに対
して着脱自在で可搬性に優れたメモリ・カードを適用す
ることが好ましいと想定される。但し、着脱式のメモリ
６５は、ＰＣカードのフォームファクタに限定されず、
所謂「メモリ・スティック」であってもよい。

【０１０９】ビデオ・コントローラ２４は、ＣＰＵ１１
からの描画命令に従って画面表示を制御する専用コント
ローラであり、描画情報を一時格納するためのフレーム
・メモリ（ＶＲＡＭ）２５を備えている。なお、本発明
を好適に具現するためには、ビデオ・コントローラ２４
は、ＶＧＡ（ＶｉｄｅｏＧｒａｐｈｉｃｓＡｒｒａ
ｙ）以上の描画能力（例えば、ＳＶＧＡ（Ｓｕｐｅｒ
ｖｉｄｅｏＧｒａｐｈｉｃｓＡｒｒａｙ）やＸＧＡ
（ｅＸｔｅｎｄｅｄＧｒａｐｈｉｃｓＡｒｒａ
ｙ））を有することが好ましい。

【０１１０】このデジタル衛星放送受信システム１０−
Ｂでは、ＣＰＵ１１は、キーボード２２やマウス２３を
介したユーザ入力コマンドに従って、チューナ１１の選
局動作を制御するとともに、番組情報の表示制御などを
行う。すなわち、ＣＰＵ１１は、ＴＳデコーダ５３から
供給されたデジタル放送用データを処理して、表示用の
データに変換してビデオ・コントローラ２４に供給す
る。ビデオ・コントローラ２４は、この表示データを基
に番組情報の画像信号を生成し、マルチプレクサ５５Ｂ
に供給する。また、ＣＰＵ１１は、デジタル放送用デー
タに含まれる音声データも処理して、これをバス５０経
由でマルチプレクサ５５Ａに供給する。マルチプレクサ
５５Ａ及び５５Ｂは、ＣＰＵ１１から供給された表示用
データと音声データの各々を、ＡＶデコーダ５４から出
力される放送番組本体としての映像データ及び音声デー
タと多重化して、ディスプレイ６１とスピーカ６２の各
々に外部出力する。なお、デジタル放送用データの処理
については、後に詳解する。

【０１１１】なお、衛星デジタル・データ受信システム
１０を構成するためには、図３や図４に示した以外にも
多くの電気回路等が必要である。但し、これらは当業者
には周知であり、また、本発明の要旨を構成するもので
はないので、本明細書中では省略している。また、図面
の錯綜を回避するため、図中の各ハードウェア・ブロッ
ク間の接続も一部しか図示していない点を了承された
い。

【０１１２】例えば、図３及び図４には図示しないが、
受信システム１０は、ＦＤ（ＦｌｏｐｐｙＤｉｓｃ）
やＣＤ−ＲＯＭ、ＭＯ（Ｍａｇｎｅｔｏ−Ｏｐｔｉｃａ
ｌｄｉｓｃ）などの可搬型の記録メディアを装填してデ
ータ・アクセス可能なＦＤＤ（ＦｌｏｐｐｙＤｉｓｃ
Ｄｒｉｖｅ）、ＣＤ−ＲＯＭドライブ、ＭＯドライブ
のような外部記憶装置を備えていてもよい。

【０１１３】図５には、デジタル放送データ受信システ
ム１０において実行される各種ソフトウェア・プログラ
ム間における階層的構成を模式的に図解している。以
下、各層のソフトウェアの機能について説明する。

【０１１４】最下層のハードウェア制御層は、オペレー
ティング・システム（ＯＳ）等の上位ソフトウェアに対
してハードウェアの相違を吸収する目的を持ち、各ハー
ドウェアに対する直接的な入出力動作やハードウェア割
り込みに対応した処理を実行する。

【０１１５】ハードウェア制御層は、例えばＲＯＭ１３
に恒久的に格納されたＢＩＯＳ（ＢａｓｉｃＩｎｐｕ
ｔ／ＯｕｔｐｕｔＳｙｓｔｅｍ）、あるいは、ＨＤＤ
１７にインストールされた「デバイス・ドライバ」とい
う形態で、デジタル衛星放送受信システム１０に提供さ
れる。

【０１１６】オペレーティング・システム（ＯＳ）は、
衛星放送受信システム１０内のハードウェア及びソフト
ウェアを総合的に管理するための基本ソフトウェアのこ
とである。ＯＳは、ＨＤＤ１７上のファイルの記録を管
理する「ファイル・マネージャ」や、メモリ空間を管理
する「メモリ・マネージャ」、システム・リソースの割
り振りを管理する「リソース・マネージャ」、タスク実
行を管理する「スケジューラ」、ディスプレイ上のウィ
ンドウ表示を制御する「ウィンドウ・システム」などの
サブシステムを含んでいる。

【０１１７】システム・サービスは、アプリケーション
などの上位プログラムがＯＳに対して各機能を呼び出す
（コールする）ための関数の集まりであり、ＡＰＩ（Ａ
ｐｐｌｉｃａｔｉｏｎＰｒｏｇｒａｍｍｉｎｇＩｎ
ｔｅｒｆａｃｅ）やラン・タイム・ライブラリ（又はダ
イナミック・リンク・ライブラリ）がこれに相当する。
システム・サービスの存在により、アプリケーションは
各ハードウェアを直接操作する必要がなくなり、ハード
ウェア操作の統一性が担保される。

【０１１８】ＸＭＬアプリケーションは、データ放送の
表示・出力などの有様を制御するためのプログラムであ
り、ＸＭＬという任意の定義付けが可能なタグ付の言語
で記述されたＸＭＬ文書である。各ＸＭＬ文書には、文
書型定義のためのＤＴＤ文書と、表示形式を規定するＸ
ＳＬ文書（又は、ＣＳＳや、ＸＳＬの派生規格であるＸ
ＳＬＴ）等のスタイルシートが付随してもよい。

【０１１９】ＸＭＬパーザは、ＤＴＤ文書を用いてＸＭ
Ｌ文書を解析するソフトウェア・プログラムであり、解
析結果としての文書オブジェクトをＸＳＬプロセッサに
渡す。この文書オブジェクトは、元のＸＭＬ文書中のタ
グに従って木構造が形成された構造化文書である。

【０１２０】次に、衛星データ受信システム１０におい
て、放送データを受信する処理手順について、図６〜図
８を参照しながら説明する。

【０１２１】デジタル衛星放送システムでは、図６に示
すように、まず、放送局１から放送衛星５に対して放送
波が送信され、衛星５から受信局１０に向かって転送さ
れる。この送信放送波のコンテンツは、衛星放送番組本
体を構成する映像と音声のデータ（ＡＶデータ）と、こ
の放送番組本体に付随するデジタル伝送データとで構成
される。

【０１２２】図７には、放送波として伝播される放送コ
ンテンツの構成を模式的に示している。同図に示すよう
に、放送コンテンツは、ＭＰＥＧ（ＭｏｔｉｏｎＰｉ
ｃｔｕｒｅＥｘｐｅｒｔｓＧｒｏｕｐ）２など所定
の圧縮方式で圧縮されたＡＶデータと、デジタル伝送デ
ータとを多重化した「トランスポート・ストリーム」と
して構成される（トランスポート・ストリームは、ＯＳ
Ｉ（ＯｐｅｎＳｙｓｔｅｍｓＩｎｔｅｒｃｏｎｎｅ
ｃｔｉｏｎ）参照モデルのトランスポート層に分類され
る）。

【０１２３】既に述べたように、ＴＳデコーダ５３は、
このトランスポート・ストリームを解釈してＡＶデータ
部分とデジタル伝送データ部分とに分離する。ＡＶデー
タ部分は、ＡＶデコーダ５４で処理され、デジタル伝送
データ部分はＣＰＵ１１において処理される。

【０１２４】デジタル伝送データ部分は、複数のモジュ
ールで構成される。各モジュールは、ＥＰＧや広告情
報、その他放送番組本体に付随する各種情報を含んでい
る。また、該デジタル伝送データ部分は、データ・カル
ーセル（回転木馬式データ）化されており、各モジュー
ルは番組本体の放送中に繰り返し出現する（この結果、
視聴者としての受信システム１０は、番組放送期間中の
任意のタイミングでモジュールを取得することができ、
キャッシュ用のメモリを省略できる）。また、ＭＰＥＧ
２圧縮されているＡＶデータの中には、モジュールの表
示出力時期との同期をとるための自動開始フラグを埋め
込むことができる。

【０１２５】図８には、モジュールのデータ構造を模式
的に示している。同図に示すように、１つのモジュール
は、データ放送の表示や出力の有様を規定する制御プロ
グラム（マルチメディア符号化アプリケーション）や、
動作を規定するスクリプト、音声、テキスト・データ、
静止画、動画などのモノメディア・データなど、複数の
リソース要素で構成される。各モノメディア・データ
は、データ放送の一部を構成するオブジェクトであり、
マルチメディア符号化アプリケーションによって統合的
に取り扱われる。

【０１２６】モジュールを構成する各リソース要素は、
それぞれ所定フォーマットを持つ独立したファイルであ
る。音声データは、例えばＡＩＦＦやＷＡＶ、ＡＡＣな
ど音声専用のファイル・フォーマットで記述され、静止
画は、ＪＰＥＧやＰＮＧ、ＧＩＦなど画像専用のファイ
ル・フォーマットで記述される。先頭のリソース・ロケ
ーション情報は、モジュール内における各リソース要素
の位置情報を記述している。

【０１２７】「マルチメディア符号化アプリケーショ
ン」は、ＥＰＧや広告情報、その他、放送番組本体に付
随する各種データ放送の表示・出力の有様を制御するプ
ログラムであり、ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅＭａ
ｒｋｕｐＬａｎｇｕａｇｅ）形式で記述されたＸＭＬ
アプリケーションである。但し、必ずしもＸＭＬ言語に
は限定されず、ＳＧＭＬやＨＴＭＬなど、その他のマー
クアップ言語形式で記述されてもよい。ＸＭＬ文書は、
文書型定義を行うＤＴＤ文書を含んでもよい。また、Ｘ
ＭＬ文書には、現実の表現形式を指定するスタイル情報
が包含されていないので、スタイルシートを添付しても
よい。

【０１２８】スタイルシートは、出力コンテンツとして
のＸＭＬ文書（さらに、その他の音声・静止画などのマ
ルチメディア・コンテンツを含んでもよい）の実際の表
現形式を規定したデータ・ファイルである。スタイルシ
ートは、ＸＭＬ文書をディスプレイ６１上に表示出力す
る形式に変換する（あるいはプリンタ（図示しない）へ
の印刷出力形式に変換する）ための、ＸＳＬ（ｅＸｔｅ
ｎｓｉｂｌｅＳｔｙｌｅｓｈｅｅｔＬａｎｇｕａｇ
ｅ）形式で記述された文書ファイルである。

【０１２９】また、スタイルシートとは別には、音声、
テキスト、静止画、動画などの各種モノメディア・デー
タからなるマルチメディア・コンテンツの動作を規定し
たスクリプトを配信してもよい（スクリプトは、例えば
ＪａｖａＳｃｒｉｐｔ，ＥＣＭＡＳｃｒｉｐｔ，Ｊｓｃ
ｒｉｐｔなどのスクリプト言語で記述される。但し、Ｘ
ＭＬ及びＸＳＬ等の規格では、基本的にはＥＣＭＡＳｃ
ｒｉｐｔで記述するように規定されている）。

【０１３０】受信システム１０側では、これら受信した
配信コンテンツのうち必要なものは、ＨＤＤ１７（又は
メモリ・カード６５）のような、システム１０のローカ
ルな記憶装置に一旦蓄積される。

【０１３１】衛星放送のように一方向性の送信環境で
は、標準的なＸＭＬ言語で記述されたコンテンツは、使
用するスタイルシートを限定しない限り、ＸＭＬ文書と
スタイルシートが同梱された形態で送信される。

【０１３２】本実施例では、放送コンテンツのうちのデ
ジタル伝送データ部分は、出力コンテンツ（ＸＭＬ文
書）とスタイルシート（ＸＳＬ文書又はＣＳＳ文書な
ど）が同梱されたもの以外に、ＸＭＬ文書本体のみの伝
送、ＸＳＬ文書のみの伝送というケースも想定してい
る。また、ＸＳＬ文書は、放送以外による配信・配布の
形態、例えばインターネットのようなネットワーク経由
でのファイル・ダウンロードや、ＦＤやＣＤ−ＲＯＭ、
ＭＯ、メモリ・スティックなどの可搬型記憶媒体に担持
されて供給を受けることができる。

【０１３３】また、本実施例に係る受信システム１０
は、供給されたＸＭＬ文書とＸＳＬ文書（又はＣＳＳ文
書など）を分離して蓄積する。すなわち、これら供給さ
れた文書ファイルを蓄積するＨＤＤ１７（又は、メモリ
・カード６５）には、ＸＭＬ文書（但し、ＤＴＤ文書を
含んでもよい）のみを保存・管理する文書本体保存部８
０と、スタイルシートとしてのＸＳＬ文書のみを保存・
管理するスタイルシート保存部９０が設けられている。

【０１３４】次に、デジタル衛星放送受信システム１０
において、放送局１がデジタル伝送データ部分を送信す
る処理手順について説明する。

【０１３５】既に上述したように、放送局１が配信する
コンテンツは、放送番組本体としてのＭＰＥＧ２圧縮さ
れたＡＶデータの他に、デジタル伝送データを含む。図
７及び図８を参照しながら説明したように、デジタル伝
送データを構成する各モジュールには、テキスト形式デ
ータで構成される２つのファイルが含まれている。この
うちの１つは出力用データ・ファイルであり、そのコン
テンツはタグでデータ属性が定義されるマークアップ記
述言語（ＸＭＬやＨＴＭＬなど）で記述されている。

【０１３６】また、モジュールに含まれる他のテキスト
形式データは、音声や静止画、動画などの各者メディア
・データの動作を規定するスクリプトである。このスク
リプトは、例えば、ＪａｖａＳｃｒｉｐｔ，ＥＣＭＡＳ
ｃｒｉｐｔ，ＪＳｃｒｉｐｔなどのスクリプト言語で記
述される（ＸＭＬ及びＸＳＬ等の規格では、基本的には
ＥＣＭＡＳｃｒｉｐｔで記述するように規定されてい
る）。スクリプトは、ソフトウェアに実行させる処理手
順をテキスト形式で記述したものであり、通常、アプリ
ケーションやＯＳ上で、エンド・ユーザが制御できる操
作手順を組み合わせた一連の処理を自動化するために利
用される。

【０１３７】ＸＭＬ形式等で記述された出力用データ自
体は、画面表示又は印刷出力する情報そのものを規定し
たものであり、そのテキスト・データの内容変更は許容
し難い。

【０１３８】これに対し、スクリプトのソース・コード
中に含まれる関数名や変数名、コメント文などは、冗長
性を含み、伝送効率上は致命的となる。関数名や変数名
などは、そもそも、スクリプト作成者が、人手による可
読性などの便宜上（又は個人的な好みに従って）命名し
たものであり、スクリプト自体が規定する動作機能とは
無関係である。言い換えれば、これら関数名や変数名
は、スクリプト自体の動作機能を維持したままで、他の
文字列との可換性がある。また、コメント文は、スクリ
プトの実行とは無関係であり、省略することさえ可能で
ある。

【０１３９】本発明は、このようなテキスト形式で記述
されたスクリプトが包含する冗長性に着眼してなされた
ものである。要するに、本発明は、スクリプト中に存在
する、比較的長い文字列からなる関数名や変数名を、よ
り短い文字列（例えばアルファベット１文字）で置き換
えることにより、スクリプトのデータ・サイズを削減す
るものである。また、さらにスクリプト中のコメント文
を削除することにより、データ・サイズを削減するもの
である。

【０１４０】図９には、テキスト形式のスクリプト・フ
ァイルを変換する処理ルーチンをフローチャートの形式
で示している。このスクリプト・ファイル変換処理ルー
チンは、例えば、放送局１内の番組制作者（より具体的
には、制作部１００の編集システム１０１（図２を参照
のこと）上）において、デジタル伝送データ作成完了後
に行われる。以下、このフローチャートの各ステップに
ついて説明する。

【０１４１】まず、ステップＳ１０では、冗長性の高い
文字列と置き換えるための冗長性の低い文字列（以下で
は、「適用文字」と呼ぶ）と、変数ｉを初期値に設定す
る。本実施例では、適用文字として、アルファベット１
文字を昇順で使用する。また、適用文字がＡから始まっ
てＺまで到達すると、ＡＡ，ＡＢ，ＡＣ，…，ＺＺ，Ａ
ＡＡ，…という具合に、該昇り順に従い文字数を１ずつ
増加させることとする。

【０１４２】また、ＥＣＭＡＳｃｒｉｐｔには、予約語
が小文字から始まるという規則がある。したがって、処
理対象となるスクリプトがＥＣＭＡＳｃｒｉｐｔ形式で
記述されている場合には、適用文字が大文字で始まるよ
うに規定することにより、ＥＣＭＡＳｃｒｉｐｔの予約
語との一致を容易に排除することができる。したがっ
て、この場合には、適用文字がスクリプトの予約語と一
致するか否かの判定（図１２のステップＳ２３：後述）
は、必要ない。

【０１４３】次いで、ステップＳ１２では、処理対象と
なるスクリプトをスキャンして、冗長性の高い文字列を
抽出して、リストアップする。

【０１４４】ここで言う冗長性の高い文字列とは、例え
ば関数名や変数名である。これらは、コーディングやデ
バッグ作業の際の人手による可読性を高めるために、意
味を持つ単語を使用した結果として冗長性が高い。例え
ば、以下に示す規則に従って、関数名や変数名をスクリ
プト中から抽出することができる。すなわち、

【０１４５】（１）予約語”ｆｕｎｃｔｉｏｎ”の直後
に続くワードは関数名である。（２）関数名の直後に続く括弧の中身は変数名とカンマ
の列である。（３）予約語”ｖａｒ”の次のワードは変数名である。（４）代入された左辺は変数名である。

【０１４６】次いで、リストの１番目の要素（すなわち
元の関数名や変数名）を取り出して（ステップＳ１
４）、この要素に対して適用文字を適用して、新しい関
数名や変数名とし、要素と適用文字との対応関係を対応
表に保存する（ステップＳ１６）。作成された対応表
は、後述する［表１］に示す通りである。

【０１４７】ステップＳ１８では、適用文字がＺｎ、す
なわちＺだけからなる文字列に到達したか否かを判別す
る（但し、文字列の個数ｎをｎの冪乗で表記したもので
ある）。

【０１４８】該判断ブロックの結果が否定的であれば、
ステップＳ２０に進んで、アルファベットの昇り順に従
い、適用文字を次の文字列に更新する。また、該判断結
果が肯定的であれば、ステップＳ２２に進んで、アルフ
ァベットの昇り順に従い、適用文字を１文字増やす（例
えば適用文字がＺであればＡＡに更新し、ＺＺでれあば
ＡＡＡに更新する）。

【０１４９】次いで、ステップＳ２４ではｉを１だけ増
分してリストの次の要素に進み、ステップＳ２６ではリ
スト中に未処理の要素が残っているか否かを判別する。
未処理エントリが残っていれば、ステップＳ１４に復帰
して、次の要素に対して上述と同様の処理を繰り返し実
行する。また、リスト中の全て要素を対応表に登録し終
えたならば、後続のスクリプト置換処理ルーチン（Ｓ３
０）に進む。該ルーチンでは、元のスクリプト中の関数
名や変数名などの冗長文字列を冗長性の低い適用文字に
置換して、スクリプトのサイズを圧縮する。そして、こ
の処理ルーチン全体を終了する。

【０１５０】ステップＳ３０のスクリプト置換処理は、
別途定義済みの処理ルーチンであり、図１１にはその処
理手順をフローチャートの形式で示している。以下、こ
のフローチャートの各ステップについて説明する。

【０１５１】まず、ステップＳ３１では、対応表（［表
１］を参照のこと）からエントリを１つ取り出し、次い
で、ステップＳ３２では、元のスクリプトから１センテ
ンスを取り出す。但し、ここで言うセンテンスは、ブラ
ンクから次のブランク又は次の改行位置までの区間の文
字列を指し、ブランクは含まないものとする。

【０１５２】ステップＳ３３では、センテンス中に、エ
ントリで規定された変数名や関数名が存在するか否かを
判別する。判別結果が否定的であれば、次ステップＳ３
４をスキップし、逆に肯定的であれば、ステップＳ３４
において変数名や関数名を対応する適用文字に置換す
る。

【０１５３】次いで、ステップＳ３５では、センテンス
がコメント文か否かを判別する。ＥＣＭＡＳｃｒｉｐｔ
形式のスクリプトであれば、コメント文はデリミッタ”
／／”以降で次の改行位置までの文字列である。該判別
結果が肯定的であれば、ステップＳ３６に進み、このコ
メント文をスクリプトから削除する。

【０１５４】次いで、ステップＳ３７では次のセンテン
スの取得を試み、ステップＳ３８では最後のセンテンス
であったか否かを判別する。センテンスが未だ残ってい
れば、ステップＳ３２に復帰して、次のセンテンスに対
して上述と同様の処理を繰り返し実行する。

【０１５５】また、最後のセンテンスに到達していた場
合には、対応表中の最後のエントリであったか否かを判
別する（ステップＳ３９）。未だエントリが残っていれ
ば、ステップＳ３１に復帰して、次のエントリが規定す
る対応関係について、上記と同様の処理を繰り返し実行
する。また、全ての対応関係について処理し終えていれ
ば、この処理ルーチン全体を終了する。

【０１５６】このスクリプト変換処理は、制作部１００
においてスクリプト作成の際に実行して、変換処理後の
スクリプトをリソースとして大容量記憶装置１０２に格
納することが好ましい。スクリプト作成直後ではなく、
送出直前にスクリプトを変換処理することも考えられる
が、この場合、リソースのモジュール・サイズが変更す
るため、モジュールの再構築が必要となる可能性があ
る。ゆえに、スクリプト作成時に変換処理を実行してお
いた方がよい。（例えば、変換処理前に、モジュール長
の制約から１つのモジュールを２つ以上のモジュールに
分割して格納していたような場合、変換処理により単一
のモジュール長に収まることもある。）

【０１５７】図１０には、図９に示した変換処理を実行
する前後のスクリプトのソース・コードを対比してい
る。但し、このスクリプトは、ＥＣＭＡＳｃｒｉｐｔ
（ＥＣＭＡＳｃｒｉｐｔは、欧州電子計算機工業会が規
格化したスクリプト言語である）で記述されたテキスト
・データであり、また、完結したプログラムではなくそ
の一部の抜粋である点を了解されたい。

【０１５８】元のソース・コード中で、”ｆｕｎｃｔｉ
ｏｎ”なる予約語の直後に続く文字列（例えば、”ｂｕ
ｉｌｄＡｒｒａｙ”など）は関数名であり、より短い文
字列に置き換える対象となる。

【０１５９】また、代入された左辺の文字列（例え
ば、”ｔｅｍｐｏｒａｒｙ＿ａｒｇｕｍｅｎｔ”など）
は変数名に該当し、同様に短い文字列に置き換える対象
となる。スクリプト内で定義された変数を挙げたが、本
発明の要旨はこれに限定されない。例えば、ＸＭＬやＨ
ＴＭＬなどの文書中の表示用符号化データの属性を操作
する操作子としての変数にも、同様に、短い文字列への
置換処理を適用することができる。

【０１６０】また、デリミッタ”／／”で始まる行末ま
での文字列は、コメント文である。本実施例に係る置換
処理では、ソース・コード中で、”／／”から始まる１
文を検索して、その行末までの文字を全て無視すなわち
削除する。

【０１６１】図１０に示す元のソース・コードに対して
図９に示す変換処理を実行した結果、以下の［表１］に
示す対応表が生成される。そして、抽出された変数名や
関数名などの冗長性の高い文字列は、冗長性の低い適用
文字に変換される。

【０１６２】

【表１】

【０１６３】図１０を参照して判るように、元のソース
・コード中の変数名や関数名は、アルファベット１文字
に置き換えられ、コメント文は削除される。また、同図
で視認される通り、コード量は大幅に削減され、伝送効
率は大いに向上する。

【０１６４】変換処理後も、スクリプトが規定する処理
そのものは変換前と全く同じである。したがって、変換
処理されたスクリプトを受信する衛星放送受信システム
１０では、スクリプトの実行系はこのサイズ削減処理が
なされたか否かを意識せず同じように取り扱うことがで
きる。

【０１６５】スクリプト中の関数名や変数名の文字列長
が最小になることは、受信システム１０における実行効
率の観点からも好ましい。何故ならば、スクリプトを実
行するインタープリタがメモリに割り当てる関数テーブ
ル、変数テーブルのサイズを小さくすることができる。
この結果、関数や変数を呼び出す際のオーバーヘッドが
少なくなるからである。

【０１６６】図９に示すスクリプト変換処理ルーチンに
よれば、可読性を持つゆえに冗長であった関数名や変数
名を、冗長性を排除した短い文字列すなわち適用文字に
変換することで、スクリプトのサイズを好適に圧縮する
ことができる。

【０１６７】置換対象となる関数名や変数名の個数が２
６以下、すなわち、アルファベット文字の総数以下であ
れば、いかなる順序で適用文字への置換処理を行って
も、変換後のサイズに相違はない。

【０１６８】これに対し、置換対象が２６個を越える場
合には、１文字の適用文字の他に、２文字以上の適用文
字を使用することになる（図９のステップＳ２２を参照
のこと）。より長い文字列を短い文字列に置換した方
が、データ圧縮の効果は高い。

【０１６９】図１２には、図９に示したものとは別のス
クリプト変換処理ルーチンの例をフローチャートの形式
で示しているが、該フローチャートではこのデータ圧縮
効率の点を勘案している。すなわち、ステップＳ１２と
ステップＳ１４の間に、リスト中の要素を再ソートする
ステップＳ１３を挿入した。すなわち、このステップＳ
１３では、スクリプト中での出現頻度が大きい順にリス
ト中の各要素を再ソートする。この結果、以後の置換処
理では、出現頻度の大きい文字又は文字列ほど、より文
字数の短い文字又は文字列に置き換えられることにな
り、データ圧縮の効果が高まる。

【０１７０】また、図１２に示すルーチンでは、さら
に、ステップＳ２０とＳ２４の間に、更新された適用文
字がシステム予約語か否かを判断し（ステップＳ２
３）、予約語であればステップＳ１８に復帰して文字列
変換の対象から除外するようにしている。予約語に変換
してしまうと、元のスクリプト本来の意味、すなわちス
クリプトが規定する動作が変更してしまうため、許容し
難いからである。

【０１７１】スクリプト中の関数名や変数名は、スクリ
プトの作成者が、各々の関数名や変数名の人手による可
読性を保つために便宜上命名したものであり、人が理解
可能な意味を持つ比較的長い文字列で構成される。ま
た、コメント文は、スクリプト中の各部分（例えばルー
チン文など）の機能をメモするためにソース・コード中
に埋め込まれるが、それ自体は機能実現に寄与しない。

【０１７２】これら長い文字列からなる関数名や変数
名、コメント文は、デバックまでの間は意味を持つが、
デバッグ以降は、人が解釈可能な意味を持つ必要はな
い。特に、衛星放送のように一方向性のコンテンツ配信
に適用する場合には、送信した以後の段階でのソース・
コードの再利用を考慮する必要がない。言い換えれば、
スクリプト中の関数名や変数名を他の短い文字列に置き
換えたり、コメント文を削除して、ソース・コードが人
手での可読性を失っても、その弊害はほとんどないので
ある。

【０１７３】本発明を、デジタル衛星データ放送におけ
るデジタル伝送データに適用することにより、伝送デー
タ・サイズを削減することができ、配信時においては伝
送効率が向上する。

【０１７４】また、受信局においては、受信データ・サ
イズが低下するので、比較的小容量の受信メモリを用意
するだけで済み、コスト削減につながる。また、関数名
や変数名の文字列長が最小になることから、スクリプト
を実行するインタープリタがメモリに割り当てる関数テ
ーブル、変数テーブルのサイズを小さくすることができ
る。この結果、関数や変数を呼び出す際のオーバーヘッ
ドが少なくなる。すなわち、スクリプトの実行効率が向
上する上に、メモリを小容量化して受信機コストを削減
することができる。

【０１７５】［追補］以上、特定の実施例を参照しなが
ら、本発明について詳解してきた。しかしながら、本発
明の要旨を逸脱しない範囲で当業者が該実施例の修正や
代用を成し得ることは自明である。すなわち、例示とい
う形態で本発明を開示してきたのであり、限定的に解釈
されるべきではない。本発明の要旨を判断するために
は、冒頭に記載した特許請求の範囲の欄を参酌すべきで
ある。

【０１７６】

【発明の効果】以上詳記したように、本発明によれば、
テキスト・データからなる配信コンテンツの伝送効率を
向上することができる、優れたデータ配信技術を提供す
ることができる。

【０１７７】また、本発明によれば、テキスト・データ
からなる配信コンテンツを受信する受信装置における実
行効率を向上するとともに、メモリ負荷を低減すること
ができる、優れたデータ配信技術を提供することができ
る。

【０１７８】本発明をデジタル衛星放送などのデジタル
・データの配信に適用した場合、テキスト形式で記述さ
れたスタイルシートを、その処理内容を変えずにデータ
量を削減することができる。この結果、コンテンツ配信
元である放送局においては、スタイルシートの作成作業
は従来のままで、配信コンテンツの伝送効率を向上させ
ることができる。

【０１７９】また、受信局側においては、受信データ・
サイズが低下するので、比較的小容量の受信メモリを用
意するだけで済み、コスト削減につながる。

【０１８０】さらに、スクリプト中の関数名や変数名の
文字列長が最小になることから、スクリプトを実行する
インタープリタがメモリに割り当てる関数テーブル、変
数テーブルのサイズを小さくすることができる。この結
果、関数や変数を呼び出す際のオーバーヘッドが少なく
なり、スクリプトの実行効率が向上する。したがって、
受信機のユーザ（すなわち視聴者）は、実行効率の向上
により、より高速なシステムの反応を期待することかで
きる。

【０１８１】また、スクリプトを配信する放送局側で
は、変換前後でのスクリプトの意味・内容は変化させて
いないので、受信側では既存の解釈ソフトウェアを用い
てスクリプトを駆動することができる。言い換えれば余
分なソフトウェア開発を必要としない。

【図面の簡単な説明】

【図１】本発明の実施に供される衛星デジタル放送シス
テム１０００の概略構成を示した図である。

【図２】放送局１すなわち送信システムの構成を模式的
に示した図である。

【図３】受信局１０（すなわち一般家庭）における受信
システムの一例１０−Ａのハードウェア構成を模式的に
示した図であり、より具体的には、ＳＴＢ（セット・ト
ップ・ボックス）と呼ばれる形態で実装された受信シス
テム１０−Ａの構成を示した図である。

【図４】他の例に係る受信システム１０−Ｂのハードウ
ェア構成を模式的に示した図であり、より具体的には、
汎用コンピュータ・システムに衛星デジタル放送用のチ
ューナ・カードを装備するという形態で実装された受信
システム１０−Ｂのハードウェア構成を示した図であ
る。

【図５】デジタル放送データ受信システム１０において
実行される各種のソフトウェア・プログラムにおける階
層的構成を模式的に図解している。

【図６】放送コンテンツが放送局１から放送衛星５を介
して受信局１０に転送される様子を模式的に示した図で
ある。

【図７】放送波として伝播される放送コンテンツの構成
を模式的に示した図である。

【図８】デジタル伝送データを構成するモジュールのデ
ータ構造を模式的に示した図である。

【図９】スクリプトを変換する処理ルーチンを示したフ
ローチャートである。

【図１０】図９に示した変換処理を実行する前後のスク
リプトのソース・コードを対比した図である。

【図１１】別途定義されたスクリプト置換処理ルーチン
（ステップＳ３０）を示したフローチャートである。

【図１２】スクリプトを変換する処理ルーチンの他の例
を示したフローチャートである。

【図１３】デジタル伝送データとして配信コンテンツの
データ構造を模式的に示した図である。

【符号の説明】

１…放送局（デジタル放送データ送信システム）５…放送衛星，７…広域ネットワーク（インターネッ
ト）１０…受信局（一般家庭：デジタル放送データ受信シス
テム）１１…ＣＰＵ，１２…ＲＡＭ（ＲａｎｄｏｍＡｃｃｅ
ｓｓＭｅｍｏｒｙ）１３…ＲＯＭ（ＲｅａｄＯｎｌｙＭｅｍｏｒｙ），
１４…ＳＩＯコントローラ１５…ＩＥＥＥ１３９４コントローラ１６…ハード・ディスク・インターフェース１７…ハード・ディスク・ドライブ（ＨＤＤ）１８…カード・インターフェース，１９…カード・スロ
ット２０…バス・ブリッジ２１…キーボード／マウス・コントローラ（ＫＭＣ）２２…キーボード，２３…マウス２４…ビデオ・コントローラ，２５…ＶＲＡＭ３０…汎用コンピュータ・システム３１…システム・バス（ＰＣＩバス）４０…デジタル・チューナ・カード５０…バス，５１…チューナ，５２…復調器，５３…Ｔ
Ｓデコーダ５４…ＡＶデコーダ５３Ａ，５４Ａ…ＲＡＭ（ＲａｎｄｏｍＡｃｃｅｓｓ
Ｍｅｍｏｒｙ）５５Ａ，Ｂ…マルチプレクサ（ＭＵＸ）５６…ユーザ・インターフェース制御部５７…表示コントローラ，５８…バス（ＰＣＩ）・イン
ターフェース６１…ディスプレイ，６２…スピーカ６３…高速モデム，６４…ビデオ・カメラ，６５…メモ
リ・カード６６…リモコン１００…制作部，１０１…編集システム１０２，１０３…大容量記憶装置２００…送出部，２０１…コンテンツ送信系２０２…ベースバンド制御系，２０３…ＡＶエンコーダ３００…伝送部，３０１…マルチメディア符号化部３０２…コンテンツ伝送部，３０３…ＡＶデータ伝送部３０４…合成部，３０５…変調部１０００…デジタル衛星データ放送システム

───────────────────────────────────────────────────── フロントページの続きＦターム(参考） 5B082 GA02 HA05 5B089 JA33 JB02 JB08 KA06 KA08 KC44 KC51 KC53 KC54 KH23 KH28 5C064 BA01 BA07 BB05 BB10 BC10 BC16 BC20 BC27 BD07 BD08 BD09 BD13 5K030 HB21 LD07 LD13 9A001 BB04 CC08 DD09 DD10 EE04 JJ19 JJ20 JJ25 JJ67 KK60

Claims

【特許請求の範囲】

【請求項１】配信コンテンツを生成する方法であって、配信コンテンツを構成するモジュールの１つとして作成
された複数の文字又は文字列からなるスクリプトの内部
を検索して、冗長性の高い文字又は文字列を抽出するス
テップと、スクリプト中で抽出された冗長性の高い文字又は文字列
を冗長性の低い文字又は文字列で置き換えるステップ
と、を含むことを特徴とする配信コンテンツ生成方法。
【請求項２】置換後の配信コンテンツを配信する前に一
時蓄積するステップを含むことを特徴とする請求項１に
記載の配信コンテンツ生成方法。
【請求項３】前記の冗長性の高い文字又は文字列は関数
名や変数名を含むことを特徴とする請求項１に記載の配
信コンテンツ生成方法。
【請求項４】前記の冗長性の高い文字又は文字列を冗長
性の低い文字又は文字列で置き換えるステップでは、冗
長性の低い文字列としてのシステム予約語の使用を排除
することを特徴とする請求項１に記載の配信コンテンツ
生成方法。
【請求項５】さらに、配信コンテンツの受信側で実行さ
れる処理に関与しない文字又は文字列からなる文を抽出
するステップと、該抽出された文を削除するステップと
を含むことを特徴とする請求項１に記載の配信コンテン
ツ生成方法。
【請求項６】前記の配信コンテンツの受信側で実行され
る処理に関与しない文字又は文字列からなる文は、所定
のデリミッタで区切られたコメント文であることを特徴
とする請求項５に記載の配信コンテンツ生成方法。
【請求項７】さらに、前記の冗長性の高い文字又は文字
列を抽出するステップで抽出された文字又は文字列の各
々についてのスクリプト中での出現頻度を積算するステ
ップを含み、前記の冗長性の高い文字又は文字列を冗長性の低い文字
又は文字列に置き換えるステップでは、出現頻度の大き
い文字又は文字列ほどより文字数の短い文字又は文字列
に置き換える、ことを特徴とする請求項１に記載の配信
コンテンツ生成方法。
【請求項８】複数のデータ・モジュールで構成されるコ
ンテンツを配信するコンテンツ配信方法であって、複数の文字又は文字列からなるスクリプト言語形式で記
述されたデータ・モジュールの内部を検索して、冗長性
の高い文字又は文字列を抽出するステップと、スクリプト中で抽出された冗長性の高い文字又は文字列
を冗長性の低い文字又は文字列で置き換えるステップ
と、置換後のデータ・モジュールを蓄積するステップと、蓄積されたデータ・モジュールを配信するステップと、
を含むことを特徴とするコンテンツ配信方法。
【請求項９】前記の冗長性の高い文字又は文字列は関数
名や変数名を含むことを特徴とする請求項８に記載のコ
ンテンツ配信方法。
【請求項１０】前記の冗長性の高い文字又は文字列を冗
長性の低い文字又は文字列で置き換えるステップでは、
冗長性の低い文字列としてのシステム予約語の使用を排
除することを特徴とする請求項８に記載のコンテンツ配
信方法。
【請求項１１】さらに、配信コンテンツの受信側で実行
される処理に関与しない文字又は文字列からなる文を抽
出するステップと、該抽出された文を削除するステップ
とを含むことを特徴とする請求項８に記載のコンテンツ
配信方法。
【請求項１２】前記の配信コンテンツの受信側で実行さ
れる処理に関与しない文字又は文字列からなる文は、所
定のデリミッタで区切られたコメント文であることを特
徴とする請求項１１に記載のコンテンツ配信方法。
【請求項１３】さらに、前記の冗長性の高い文字又は文
字列を抽出するステップで抽出された文字又は文字列の
各々についてのスクリプト中での出現頻度を積算するス
テップを含み、前記の冗長性の高い文字又は文字列を冗長性の低い文字
又は文字列に置き換えるステップでは、出現頻度の大き
い文字又は文字列ほどより文字数の短い文字又は文字列
に置き換える、ことを特徴とする請求項８に記載のコン
テンツ配信方法。
【請求項１４】複数のデータ・モジュールで構成される
コンテンツを配信するコンテンツ配信装置であって、複数の文字又は文字列からなるスクリプト言語形式で記
述されたデータ・モジュールの内部を検索して、冗長性
の高い文字又は文字列を抽出する手段と、スクリプト中で抽出された冗長性の高い文字又は文字列
を冗長性の低い文字又は文字列で置き換える手段と、置換後のデータ・モジュールを蓄積する手段と、蓄積されたデータ・モジュールを配信する手段と、を含
むことを特徴とするコンテンツ配信装置。
【請求項１５】前記の冗長性の高い文字又は文字列は関
数名や変数名を含むことを特徴とする請求項１４に記載
のコンテンツ配信装置。
【請求項１６】前記の冗長性の高い文字又は文字列を冗
長性の低い文字又は文字列で置き換える手段は、冗長性
の低い文字列としてのシステム予約語の使用を排除する
ことを特徴とする請求項１４に記載のコンテンツ配信装
置。
【請求項１７】さらに、配信コンテンツの受信側で実行
される処理に関与しない文字又は文字列からなる文を抽
出する手段と、該抽出された文を削除する手段とを含む
ことを特徴とする請求項１４に記載のコンテンツ配信装
置。
【請求項１８】前記の配信コンテンツの受信側で実行さ
れる処理に関与しない文字又は文字列からなる文は、所
定のデリミッタで区切られたコメント文であることを特
徴とする請求項１７に記載のコンテンツ配信装置。
【請求項１９】さらに、前記の冗長性の高い文字又は文
字列を抽出するステップで抽出された文字又は文字列の
各々についてのスクリプト中での出現頻度を積算する手
段を含み、前記の冗長性の高い文字又は文字列を冗長性の低い文字
又は文字列に置き換える手段では、出現頻度の大きい文
字又は文字列ほどより文字数の短い文字又は文字列に置
き換える、ことを特徴とする請求項１４に記載のコンテ
ンツ配信装置。
【請求項２０】コンピュータ処理に関する意味を持つ複
数の文字又は文字列で構成されるソース・コードを変換
する方法であって、ソース・コード中を検索して、冗長性の高い文字又は文
字列を抽出するステップと、抽出された冗長性の高い文字又は文字列を冗長性の低い
文字又は文字列で置き換えるステップと、を含むことを
特徴とするコード変換方法。
【請求項２１】前記の冗長性の高い文字又は文字列は関
数名や変数名を含むことを特徴とする請求項２０に記載
のコード変換方法。
【請求項２２】前記の冗長性の高い文字又は文字列を冗
長性の低い文字又は文字列で置き換えるステップでは、
冗長性の低い文字列としてのシステム予約語の使用を排
除することを特徴とする請求項２０に記載のコード変換
方法。
【請求項２３】さらに、ソース・コード中で該コードの
実行に関与しない文字又は文字列からなる文を抽出する
ステップと、該抽出された文を削除するステップとを含
むことを特徴とする請求項２０に記載のコード変換方
法。
【請求項２４】前記のコード実行に関与しない文字又は
文字列からなる文は、所定のデリミッタで区切られたコ
メント文であることを特徴とする請求項２３に記載のコ
ード変換方法。
【請求項２５】さらに、前記の冗長性の高い文字又は文
字列を抽出するステップで抽出された文字又は文字列の
各々についてのスクリプト中での出現頻度を積算するス
テップを含み、前記の冗長性の高い文字又は文字列を冗長性の低い文字
又は文字列に置き換えるステップでは、出現頻度の大き
い文字又は文字列ほどより文字数の短い文字又は文字列
に置き換える、ことを特徴とする請求項２０に記載のコ
ード変換方法。