【事件の表示】
　平成１０年特許願第　４１９９４号「デジタルテレビ放送受信装置」拒絶査定不服審判事件〔平成１１年　８月３１日出願公開、特開平１１−２３９３０５〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１．手続の経緯
　本願は平成１０年２月２４日の出願であって、手続の概要は以下のとおりである。
　
　手続補正　　　　　　　　　　　　：平成１７年　１月１９日
　拒絶理由通知　　　　　　　　　　：平成１９年　４月１２日（起案日）
　手続補正　　　　　　　　　　　　：平成１９年　６月１８日
　拒絶理由通知　　　　　　　　　　：平成１９年　７月　５日（起案日）
　手続補正　　　　　　　　　　　　：平成１９年　９月１０日
　拒絶査定　　　　　　　　　　　　：平成１９年１０月　２日（起案日）
　拒絶査定不服審判請求　　　　　　：平成１９年１１月　９日
　手続補正　　　　　　　　　　　　：平成１９年１２月１０日
　前置審査報告　　　　　　　　　　：平成２０年　５月　２日（作成日）
　審尋　　　　　　　　　　　　　　：平成２２年　１月　６日（起案日）
　回答書　　　　　　　　　　　　　：平成２２年　３月　８日
　拒絶理由通知（当審）　　　　　　：平成２２年　７月２２日（起案日）
　手続補正　　　　　　　　　　　　：平成２２年　９月１０日
　
第２．本願発明
　本願の請求項１に係る発明（以下、「本願発明」という。）は、平成２２年９月１０日付けの手続補正書により補正された特許請求の範囲の請求項１に記載された事項により特定される、以下のとおりのものである。
　　【請求項１】
　複数の放送番組に関するデータが多重化されたデジタル放送信号を受信するチューナ部と、
　前記チューナ部により受信されたデジタル放送信号を復調し、トランスポートストリームを出力する復調部と、
　前記復調部により出力された前記トランスポートストリームから前記放送番組に関する圧縮された映像信号および音声信号と、前記放送番組に関する電子番組表データと、所定の作成言語で記述されたブラウザで処理可能な情報データを抽出する放送番組情報抽出部と、
　前記放送番組情報抽出部により抽出された前記放送番組に関する圧縮された映像信号および音声信号を圧縮解凍し、放送番組に関する映像信号および音声信号を出力する圧縮解凍処理部と、
　前記電子番組表データや自機において生成する表示データ等の表示用データを、表示部へ表示するための映像信号に変換するグラフィックス処理部と、
　格納されている複数種類のブラウザの中から、抽出された前記情報データの作成言語に対応するブラウザを選択し、選択した前記ブラウザを用いて、抽出された前記情報データを、前記グラフィックス処理部において処理可能な前記番組表データと同様の形式の表示用データに変換するブラウザ実行部と、
　前記ブラウザ実行部を制御して、抽出された前記情報データから変換された前記表示用データを前記グラフィックス処理部へ出力させる制御部と
　を有するデジタルテレビ放送受信装置。
　
第３．当審が通知した拒絶理由通知の概要
　当審が通知した拒絶の理由は、概略、以下のとおりである。
　本願の請求項１に係る発明は、下記刊行物に記載された発明および周知技術に基づいて当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により、特許を受けることができない。
　　　　　記　
刊行物１．特開平９−６５３００号公報
刊行物２．特開平１０−３２８０２号公報
刊行物３．「マルチメディアサービスをめざすデータ放送」，磯部忠，テレビジョン学会技術報告  Ｖｏｌ．１９  Ｎｏ．３８，１９９５年８月，２５−３０頁
刊行物４．「新しいマルチメディア放送サービス‘ＰＲＥＳＥＮＴ’」，妹尾宏，ＮＨＫ技研だより  Ｎｏ．５７，１９９４年１０月，７−１１頁
刊行物５．「インターネットによるエレクトロニック・コマース」，鈴木弘幸著，株式会社ソフト・リサーチ・センター発行，１９９６年５月２５日，１６８−１７０頁
刊行物６．「マルチメディアビジネスの展開  第１８回（テレビ電波によるインターネット配信サービス−データ放送「ＡＤＡＭＳ」）」，星野肇夫，ビジネスコミュニケーション  第３４巻  第９号，９８−１０２頁
刊行物７．「営業放送を開始した「データウエーブ」方式によるデータ放送サービス「Ａｄａｍｓ」」，佐々木哲雄，映像情報メディア学会技術報告  Ｖｏｌ．２１  Ｎｏ．４５，１９９７年８月２９日，２５−３０頁
　
第４．刊行物の記載　
　当審における拒絶の理由の通知において引用された特開平９−６５３００号公報（平成９年３月７日出願公開。以下、「刊行物１」という。）には、図面と共に以下の事項が記載されている。
　
【０００１】
【発明の属する技術分野】本発明は、少なくとも動画像情報とこの動画像情報の内容に関連した付加情報とを多重して送信し、その多重情報を受信して情報別に分離し再生する情報送受信システム、このシステムに用いられる送信情報生成装置及び受信情報再生装置に関する。
【０００２】
【従来の技術】近年のマルチメディアという表現に代表されるように、様々な分野において、映像、音、データの電子化及び融合の応用が広がっている。例えば、コンピュータ、出版、教育などがあげられる。また、もともと映像と音声の複合メディアであるテレビジョン（以下、ＴＶと記す）放送においても、それらに文字や簡単なグラフィック情報を付加して、より多様な情報を送受信する放送が、文字多重放送という形で既に実現されている。さらに、既に米国で実用化が始まっているディジタルＴＶ放送システムにおいても、同等あるいはそれ以上のサービスが可能である。
【０００３】映像信号をディジタル化して伝送するＴＶ放送の１つの利点として、１つの伝送チャンネルに複数の番組を伝送できることがあげられる。ここでいう伝送チャンネルとは現行ＴＶ放送におけるチャンネルのことで、地上放送では６ＭＨｚの帯域がある。
【０００４】文献（１）「日経エレクトロニクスブックス、データ圧縮技術とディジタル変調技術」によれば、一般的な１６ＱＡＭ変調を用いてディジタル伝送を行う場合、１シンボルに４ビット（２4 ＝１６値）を割り当て、４ビット／秒／Ｈｚで伝送することになる。従って、現行地上波１チャンネルにおいて１６ＱＡＭ変調を使用する場合には、６Ｍ×４＝２４Ｍ／秒で伝送できることになる。但し、実際の伝送速度は隣接チャンネル間の干渉を防ぐためのフィルタ特性や誤り訂正符号によるオーバーヘッドが必要になるため、これよりも若干小さくなる。
【０００５】１９９４年１１月に国際標準に制定されたＭＰＥＧ２においては、圧縮後のレートが５Ｍｂｐｓ程度で現行ＮＴＳＣ並みの品質、また、圧縮された音声信号は数百Ｋｂｐｓなので、現行ＴＶのような番組であれば、１つの伝送チャンネル内で４番組を同時に伝送できる。さらに、映像や音声の他に、番組内容を補足するためのデータや、文字多重放送と同様な各種データも多重して伝送することが可能である。従って、従来の文字多重放送のようなサービス形態のみならず、映像と音声から構成される通常の番組を補足するために、別の映像を送受信することも可能である。
【０００６】さて、こうした多様な情報を送受信するシステムにおいて、映像と音声から構成される本来の番組以外のデータ要素を参照するための手順について、ＭＰＥＧ２を例にして以下説明する。
【０００７】まず、ＭＰＥＧ２において複数の番組とデータ要素を送信するための多重方法と、多重データを受けて所定の番組を選択し試聴する方法について、文献（２）「INTERNATIONAL ORGANIZATION FOR STANDARDIZATION ORGANISATION INTERNATIONALE DE NORMALISATION ISO/IEC JTC1/SC29/WG11 CODEING OF MOVING PICTURESAND ASSOCIATED AUDIO」に記述されているＭＰＥＧ２のシステムレイヤに準じて説明する。
【０００８】図１５を用いて、送信側の処理内容を説明する。一般的に、番組は映像、音声、データなどいくつかのデータ要素のディジタルストリームから構成される。それぞれのデータ要素ストリームは、ＰＩＤ（Packet Initial Data ）と呼ばれるユニークな番号で識別される固定長のパケットとして多重される。また、１つの番組がどのようなデータ要素ストリームから構成されているかを示すため、ＰＭＴ（Program Map Table ）と呼ばれるテーブルが定義されている。
【０００９】映像、音声データは、ディジタルストリームのデータ圧縮処理を行い、ＰＥＳ（Packetized Elementary Stream）と呼ばれるパケット化されたデータストリームとした後に多重するのが一般的である。
【００１０】例えば番組Ａは２つの映像ストリーム（Ｖｉｄｅｏ１，Ｖｉｄｅｏ２）、２つの音声ストリーム（Ａｕｄｉｏ１，Ａｕｄｉｏ２）、１つのデータストリーム（Ｄａｔａ１）の５つのストリームを適宜圧縮した後、こうした内容を示すテーブルであるＰＭＴ（Ａ）と共に多重器（ＭＵＸ）１１により多重して、一つのトランスポートストリームＴＳ（Ａ）にまとめたものである。尚、ＰＭＴには、場合によっては番組内容の記述も含まれる。
【００１１】同様にして、番組Ｂ、Ｃの映像、音声、データ、ＰＭＴについて多重器１２，１３によって多重して、トランスポートストリームＴＳ（Ｂ），ＴＳ（Ｃ）が構成される。この場合、ＰＭＴは各番組に１づつ必要となるが、これらＰＭＴを統括するテーブルとしてＰＡＴ（ Program Asociation Table ）がある。ＰＡＴは、各番組とそれぞれのＰＭＴの対応を示すテーブルである。
【００１２】例えば、３つの番組Ａ、Ｂ、Ｃの各トランスポートストリームＴＳ（Ａ），ＴＳ（Ｂ），ＴＳ（Ｃ）を多重器（ＭＵＸ）１４により多重することでＴＳ（ＡＬＬ）が構成される。それぞれの番組にはＰＭＴ（Ａ）、ＰＭＴ（Ｂ）、ＰＭＴ（Ｃ）があり、これらを取りまとめるテーブルがＰＡＴである。尚、ＰＡＴ，ＰＭＴも、データ要素ストリームと同様にＰＩＤで識別できる固定長パケットとして多重され、特にＰＡＴはＰＩＤ＝０と規定されている。
【００１３】次に、多重ＴＳ（ＡＬＬ）のデコード方法と視聴者による番組選択について、図１６を用いて説明する。同図において、チューナー２１から出力される受信信号は、復調後の多重ＴＳ（ＡＬＬ）である。多重ＴＳ（ＡＬＬ）はＦＩＦＯメモリ２２〜２５、ＳＲＡＭ２６、番組表メモリ２７に分配供給される。
【００１４】多重ＴＳ（ＡＬＬ）の各パケットには、先に説明したようにパケット識別のためにＰＩＤやパケット同期を含むヘッダが含まれている。そこで、このデコーダでは、図示しないパケット同期回路により、ヘッダ中のパケット同期の周期性からパケットの切り出し位相（固定長パケットの切れ目）を再生する。
【００１５】この位相情報をもとにして、同じくパケットヘッダに含まれるＩＤ番号をデパケットコントローラ２８で指示することで、各メモリ（ＦＩＦＯ２２〜２５、ＳＲＡＭ２６、番組表メモリ２７）に必要なパケットのみを抜き出して書き込むことが可能となる。
【００１６】尚、ＰＡＴパケットは、視聴選択に不可欠であるという性質上、固定のＩＤ番号が割り当てられる。ＭＰＥＧ２では先に説明したようにそのＩＤを０としている。
【００１７】まず、デパケットコントローラ２８は、ＭＰＵ２９からの指令を受けて、ＰＩＤ＝０を取り込むように番組表メモリ２７に指示する。番組表メモリ２７に取り込まれるデータは、図１５に示したＰＡＴをパケット化したものである。このＰＡＴはバス３０を介してＭＰＵ２９に読み込まれる。
【００１８】このとき、ＭＰＵ２９は、ＰＡＴを復元してメモリ３１に格納し、ＰＡＴをもとに３つの番組Ａ，Ｂ，ＣのＰＭＴそれぞれのＰＩＤを取得し、デパケットコントローラ２８を通じて取り込むように番組表メモリ２７に指示する。
【００１９】さらに、ＭＰＵ２９は、バス３０を介してＰＭＴを読み込み、パケットを解いて復元してメモリ３１に格納する。このようにしてメモリ３１に格納されたＰＡＴとＰＭＴによるプログラム情報は、ＶＲＡＭ３２、Ｄ／Ａ変換器３３、画面合成器３４を経由して表示装置３５へ送られ表示される。
【００２０】図１７に番組構成テーブルの表示の一例を示す。この例では、現在放送中の３つの番組名を表示している。ＰＩＤの数値自体は視聴者が直接知る必要がないので、特に表示する必要はない。
【００２１】尚、上記の記載では、番組表メモリ２７に番組Ａ，Ｂ，ＣのＰＭＴそれぞれのＰＩＤをパケット化された状態で取り込んで、デパケット処理をＭＰＵ２９が行うと説明したが、番組表メモリ２７にデパケットされた状態で書き込むようにデパケットコントローラ２８を通じて指示してもよい。
【００２２】こうして表示された番組構成より、視聴者がリモートコントローラ３６を用いて番組Ａを選択したとする。視聴者による番組選択指示は、赤外受光部３７、マイコン（マイクロコンピュータの略）３８を介してＭＰＵ２９とデパケットコントローラ２８とに送られる。
【００２３】ＭＰＵ２９においては、番組Ａが選択されたことを示すように、例えば図１７において番組Ａと表示している部分の色を変更するなどして、視聴者によるリモコン操作を画面にフィードバックする処理を行うと共に、メモリ３１上のＰＡＴ、ＰＭＴを参照して、番組Ａを構成している映像及び音声のそれぞれのＰＩＤを得る。図１５に示したように、１つの番組中に映像、音声が複数存在する場合には、送信側で優先順位を付けるなどしてデフォルトでデコードされるべき信号を指示して送信する。
【００２４】受信側ではこの指示に従って映像、音声を１組選択するか、あるいは、優先度が同一または優先度が高い順に複数の映像、音声を同時に選択することができる。ここでは前者の例で説明する。
【００２５】番組Ａを構成している映像及び音声のそれぞれのＰＩＤを得ると、ＭＰＵ２９はデパケットコントローラ２８を通じて、指示された映像のＰＩＤを持つパケットのみをデパケットして取り込むようＦＩＦＯ２２を制御すると共に、指示された音声のＰＩＤパケットのみをデパケットして取り込むようＦＩＦＯ２４を制御する。こうしてＦＩＦＯ２２，２４にはそれぞれ、圧縮された映像信号、音声信号が取り込まれる。
【００２６】ここで、ＰＣＲ（Program Clock Reference ）を含むパケットヘッダはクロック再生回路４８に取り込まれ、デコード処理に必要なクロックを再生する。この再生クロックを基に、ＦＩＦＯ２２の映像データは映像デコーダ３９により伸張され、画面合成器４１、Ｄ／Ａ変換器４２、画面合成器３４を介して表示装置３５に送られ表示される。
【００２７】１段目の画面合成器４１は、２つの映像デコーダ３９，４０からの映像信号を画面に同時に表示する場合にその処理を行い、２段目の画面合成器３４は、映像信号とＶＲＡＭ３２から出力されるグラフィックデータとを合成する。この画面合成器３４とＤ／Ａ変換器３３の構成は、必ずしもこの順序でこの構成である必要はない。
　
【００３２】以上説明したようにして、パケット多重されたディジタル放送を受信し、希望する番組を選択し試聴することができる。引き続き、データ要素参照の手順について説明する。一般的には、番組Ａを試聴している状態において、視聴者がリモートコントローラ３６を用いて、例えば［付加情報］というボタンを操作する。視聴者による付加情報表示指示は、赤外受光部３７、マイコン３８を介してＭＰＵ２９へに送られる。
【００３３】ＭＰＵ２９においては、前述した映像や音声と同様にメモリ３１上のＰＡＴ、ＰＭＴを参照して、番組Ａを構成しているその他のデータストリームのＰＩＤとその内容を得る。この場合は、図１５において、試聴している画面が映像（Ｖｉｄｅｏ１）、音声（Ａｕｄｉｏ１）、その他のデータストリームが映像（Ｖｉｄｅｏ２）、音声（Ａｕｄｉｏ２）、データ（Ｄａｔａ１）である。
【００３４】次に、ＭＰＵ２９はデパケットコントローラ２８を通じて、指示されたＰＩＤを持つパケットのみをデパケットして取り込むようＳＲＡＭ２６を制御する。ＳＲＡＭ２６に取り込まれたデータストリームパケットは、ＭＰＵ２９において表示に適当な形式にデコードされた後、ＶＲＡＭ３２、Ｄ／Ａ変換器３３、画面合成器３４によって現在視聴中の画面と合成されて、例えば画面上に図１８に示すような付加情報メニューを表示される。このようにして、リモートコントローラ３６で指示することで、現在送信されている付加情報の内容を表示できる。
【００３５】番組Ａが日本対韓国のサッカー中継番組であるとすれば、図１８の画面５１には試合中の動画が表示され、さらに５２〜５５のようなメニューがオーバーラップして表示される。５２は同じサッカー中継を別アングルのカメラで撮影しているもので、図１５におけるＶｉｄｅｏ２，Ａｕｄｉｏ２に相当する。５３〜５５は図１５におけるＤａｔａ１に相当するデータベース情報であり、場合によっては非実時間的な映像、音声も含む。
【００３６】さて、サッカーの試合にて日本チームに得点が入ったときに、シュートした選手のプロフィールを背番号を頼りにして表示する操作について説明する。まず、以上説明したようにリモートコントローラ３６により［付加情報］を指示して図１８の内容を表示する。次に５５を選択指示すると、図１９（ａ）に示す情報が表示される。さらにメニュー６１を選択指示すると、図１９（ｂ）に示す情報が表示され、メニュー６２を選択指示すると、図１９（ｃ）に示す情報が表示される。
【００３７】ここでシュートした選手の背番号（６３）を選択指示すると、図１９（ｄ）に示す情報が表示され、希望する選手のプロフィールを得ることができる。以上説明した図１８、図１９の表示を実現するためのデータストリームＤａｔａ１に含まれるデータ構造について、図２０を用いて説明する。
【００３８】図２０はデータストリームＤａｔａ１に含まれるテキストデータであり、［］で囲まれた部分がメニューＩＤ、それ以降に続いているのがメニュー内容を示す。例えば、７１は図１８に示したメニューのＩＤであり、タイトルが７２によって示されている。さらにメニューを構成するアイテム数がｎＩｔｅｍによって示され（７３）、その後ｎＩｔｅｍ分だけメニュー項目が続く（７４〜７７）。
【００３９】各メニュー項目は、メニュータイトル及び選択された場合に次に表示するメニューＩＤの組からなる。例えば７７は図１８のメニュー５５に対応しており、「選手プロフィール」と表示し、選択されれば[Menu1-3] ７８にジャンプする。[Menu1-3] ７８において、タイトル、アイテム数、各メニュー項目等は［Ｍｅｎｕ０］と同様であり、図１９（ａ）のようなメニューが表示される。同図においてメニュー６１を選択すると、８１を参照して[Menu2-1] ８３にジャンプする。以下同様にして、[Menu4-2] ８４に到達し、図１９（ｄ）に示した選手のプロフィールを表示することができる。
【００４０】図２０の[Menu4-2] ８４において、８５は選択された場合のジャンプ先メニューがＮＯＮＥとなっている。この場合には選択されても何処にもジャンプしない。
【００４１】以上のような一連の操作によって、番組に付加された情報を参照することができる。以上説明したように、多様な情報を送受信するシステムにおいて、映像と音声から構成される本来の番組以外のデータ要素を参照するための、従来のメニュー表示／選択方法では、必要なデータに到達するまでの手続きが非常に多くなるという問題点がある。
　
【００７４】また、「付加情報」として選手プロフィールをいう文字情報を例にして説明したが、文字に限らず、映像や音声などの他のデータを適応することも可能である。
　
第５．刊行物に記載された発明
　以上の記載によれば、刊行物１には、次の発明が記載されている。
　
（１）チューナについて
　【００１３】の記載によれば、「チューナー２１から出力される受信信号は、復調後の多重ＴＳ（ＡＬＬ）である。多重ＴＳ（ＡＬＬ）はＦＩＦＯメモリ２２〜２５、ＳＲＡＭ２６、番組表メモリ２７に分配供給される。」ものであり、【００１２】の記載によればＴＳ（ＡＬＬ）は「例えば、３つの番組Ａ、Ｂ、Ｃの各トランスポートストリームＴＳ（Ａ），ＴＳ（Ｂ），ＴＳ（Ｃ）を多重器（ＭＵＸ）１４により多重することでＴＳ（ＡＬＬ）が構成される」ものである。
　すなわち、刊行物１のチューナは、受信した信号を復調することにより、３つの番組Ａ、Ｂ、Ｃの各トランスポートストリームを多重化したＴＳ（ＡＬＬ）を出力するものであるから、チューナが受信している信号は、復調前の３つの番組Ａ、Ｂ、Ｃの各トランスポートストリームを多重化したＴＳ（ＡＬＬ）の信号であるといえる。そして、復調前の３つの番組Ａ、Ｂ、Ｃの各トランスポートストリームを多重化したＴＳ（ＡＬＬ）の信号は３つ（複数）の番組に関するデータが多重化された信号ということができる。
　そして、　刊行物１発明の属する技術分野は、刊行物１の【０００２】に「
もともと映像と音声の複合メディアであるテレビジョン（以下、ＴＶと記す）放送
多様な情報を送受信する放送が、文字多重放送という形で既に実現されている
ディジタルＴＶ放送システムにおいても、同等あるいはそれ以上のサービスが可能
　また、刊行物１発明のチューナが受信する信号は、その前提が【０００７】、【０００８】の記載から見てＭＰＥＧ２における受信に関するものであるから、デジタル信号であることも明らかである。
　以上のことから見て、刊行物１のチューナは、複数の放送番組に関するデータが多重化されたデジタル放送信号を受信し、さらに、上記受信した信号を復調し、トランスポートストリームＴＳ（ＡＬＬ）を出力する出力部を備えているといえる。
　
（２）デパケットコントローラについて
　【００１３】ないし【００１５】の記載によれば、「復調後の多重ＴＳ（ＡＬＬ）はＦＩＦＯメモリ２２〜２５、ＳＲＡＭ２６、番組表メモリ２７に分配供給される」ようになされており、具体的には、「多重ＴＳ（ＡＬＬ）の各パケットに含まれているヘッダ中のパケット同期の周期性からパケットの切り出し位相（固定長パケットの切れ目）を再生し、この位相情報をもとにして、同じくパケットヘッダに含まれるＩＤ番号をデパケットコントローラ２８で指示することで、各メモリ（ＦＩＦＯ２２〜２５、ＳＲＡＭ２６、番組表メモリ２７）に必要なパケットのみを抜き出して書き込む」ことを可能としている。
　そして、上記デパケットコントローラの指示により抜き出されるパケットは、【００１７】ないし【００２０】、【００２５】、【００２６】、【００３３】、【００３４】の記載によれば、以下のとおりである。
＜番組構成テーブルの表示のためのデータ＞
　ＰＩＤ＝０のパケット（すなわちＰＡＴ）を取り込み、ＰＡＴを復元してメモリ３１に格納し、各番組（Ａ、Ｂ、Ｃ）のＰＭＴそれぞれのＰＩＤを取得し、デパケットコントローラ２８を通じて番組表メモリ２７に取り込み、さらに、（上記取得したＰＩＤに対応する）ＰＭＴを読み込み、パケットを解いて復元してメモリ３１に格納する。このようにしてメモリ３１に格納されたＰＡＴとＰＭＴによるプログラム情報は、ＶＲＡＭ３２、Ｄ／Ａ変換器３３、画面合成器３４を経由して表示装置３５へ送られ表示される。
　そして、「図１７に番組構成テーブルの表示の一例を示す。この例では、現在放送中の３つの番組名を表示している。」として、図１７を参酌すると、現在放送中の番組表が表示されている状態が理解できる。
＜映像表示、音声出力のためのデータ＞
　番組Ａを構成している映像及び音声のそれぞれのＰＩＤを得ると、ＭＰＵ２９はデパケットコントローラ２８を通じて、指示された映像のＰＩＤを持つパケットのみをデパケットして取り込むようＦＩＦＯ２２を制御すると共に、指示された音声のＰＩＤパケットのみをデパケットして取り込むようＦＩＦＯ２４を制御する。こうしてＦＩＦＯ２２，２４にはそれぞれ、圧縮された映像信号、音声信号が取り込まれる。
　ＦＩＦＯ２２の映像データは映像デコーダ３９により伸張され、画面合成器４１、Ｄ／Ａ変換器４２、画面合成器３４を介して表示装置３５に送られ表示される。
　音声信号は、音声デコーダ４３で再生クロックに基づいて伸張され、セレクタ４５、Ｄ／Ａ変換器４６を介してスピーカー４７より音声出力される。
＜付加情報表示のためのデータ＞
　ＭＰＵ２９においては、前述した映像や音声と同様にメモリ３１上のＰＡＴ、ＰＭＴを参照して、番組Ａを構成しているその他のデータストリームのＰＩＤとその内容を得る。
　次に、ＭＰＵ２９はデパケットコントローラ２８を通じて、指示されたＰＩＤを持つパケットのみをデパケットして取り込むようＳＲＡＭ２６を制御する。ＳＲＡＭ２６に取り込まれたデータストリームパケットは、ＭＰＵ２９において表示に適当な形式にデコードされた後、ＶＲＡＭ３２、Ｄ／Ａ変換器３３、画面合成器３４によって現在視聴中の画面と合成されて、例えば画面上に図１８に示すような付加情報メニューを表示される。このようにして、リモートコントローラ３６で指示することで、現在送信されている付加情報の内容を表示できる。
　以上のことから見て、刊行物１では、デパケットコントローラの指示により、復調後の多重ＴＳ（ＡＬＬ）から、番組を構成している圧縮された映像信号、音声信号、放送中の番組名を表示するためのデータ、付加情報を表示するためのデータを取り出している。
　
（３）映像デコーダ、音声デコーダ
　【００２５】、【００２６】の記載によれば、ＦＩＦＯ２２には、デパケットコントローラを通じて指示された、番組Ａを構成している映像のＰＩＤを持つパケットのみがデパケットされ、圧縮された映像信号として取り込まれ、ＦＩＦＯ２２の映像データは映像デコーダ３９により伸張され、画面合成器４１、Ｄ／Ａ変換器４２、画面合成器３４を介して表示装置３５に送られ表示される。
　また、ＦＩＦＯ２４には、（デパケットコントローラを通じて）指示された、番組Ａを構成している音声のＰＩＤパケットのみがデパケットされ圧縮された音声信号として取り込まれ、（ＦＩＦＯ２４の）音声信号は、音声デコーダ４３で再生クロックに基づいて伸張され、セレクタ４５、Ｄ／Ａ変換器４６を介してスピーカー４７より音声出力される。
　以上のことから見て、刊行物１の映像デコーダは、デパケットコントローラを通じて指示された番組Ａを構成している圧縮された映像信号を伸張し、出力するものであり、音声デコーダは、デパケットコントローラを通じて指示された番組Ａを構成している圧縮された音声信号を伸張し、出力するものである。
　
（４）ＭＰＵにおけるプログラム情報の表示
　【００１８】、【００１９】の記載によれば、「ＭＰＵ２９は、ＰＡＴを復元してメモリ３１に格納し、ＰＡＴをもとに３つの番組Ａ，Ｂ，ＣのＰＭＴそれぞれのＰＩＤを取得し、デパケットコントローラ２８を通じて取り込むように番組表メモリ２７に指示し、さらに、ＭＰＵ２９は、バス３０を介してＰＭＴを読み込み、パケットを解いて復元してメモリ３１に格納する。このようにしてメモリ３１に格納されたＰＡＴとＰＭＴによるプログラム情報は、ＶＲＡＭ３２、Ｄ／Ａ変換器３３、画面合成器３４を経由して表示装置３５へ送られ表示される。」ものであり、具体的な表示例としては、「図１７に番組構成テーブルの表示の一例を示す。この例では、現在放送中の３つの番組名を表示している。」（【００２０】）とされ、図１７には、枠に囲まれた「番組Ａ」、「番組Ｂ」、「番組Ｃ」の表示の他に、「−現在放送中の番組−」の表示がされることが理解できる記載がある。
　これらの記載から見て、刊行物１のＭＰＵは番組表のデータとともに、これに付加して表示される「−現在放送中の番組−」の表示データを、表示装置で表示するための信号として生成しているといえる。
　
（５）ＭＰＵにおける付加情報の表示
　【００３３】、【００３４】の記載によれば、ＭＰＵ２９においては、前述した映像や音声と同様にメモリ３１上のＰＡＴ、ＰＭＴを参照して、番組Ａを構成しているその他のデータストリームのＰＩＤとその内容を得、次に、ＭＰＵ２９はデパケットコントローラ２８を通じて、指示されたＰＩＤを持つパケットのみをデパケットして取り込むようＳＲＡＭ２６を制御し、ＳＲＡＭ２６に取り込まれたデータストリームパケットは、ＭＰＵ２９において表示に適当な形式にデコードされた後、ＶＲＡＭ３２、Ｄ／Ａ変換器３３、画面合成器３４によって現在視聴中の画面と合成されて、例えば画面上に図１８に示すような付加情報メニューを表示される。
　すなわち、ＭＰＵは、指示された（付加情報を表示するのに必要な）パケットをＳＲＡＭに取り込み、「ＶＲＡＭ３２、Ｄ／Ａ変換器３３、画面合成器３４によって現在視聴中の画面と合成される」のに適当な形式にデコードし、出力している。
　
（６）ディジタルＴＶ放送システム
　刊行物１の【０００１】によれば「本発明は、少なくとも動画像情報とこの動画像情報の内容に関連した付加情報とを多重して送信し、その多重情報を受信して情報別に分離し再生する情報送受信システム、このシステムに用いられる送信情報生成装置及び受信情報再生装置に関する。」とあり、上記「多重情報を受信して情報別に分離し再生する情報送受信システム」として、【０００２】には「テレビジョン（以下、ＴＶと記す）放送においても、それらに文字や簡単なグラフィック情報を付加して、より多様な情報を送受信する放送が、文字多重放送という形で既に実現されている。さらに、既に米国で実用化が始まっているディジタルＴＶ放送システムにおいても、同等あるいはそれ以上のサービスが可能である。」とあるから、刊行物１はディジタルＴＶ放送システムの受信システムに関するものであることが記載されている。
　
（７）まとめ
　以上まとめると、刊行物１に記載された発明（以下「刊行物１発明」という）として、以下のとおりのものを認定することができる。
　
　複数の放送番組に関するデータが多重化されたデジタル放送信号を受信し、さらに、上記受信した信号を復調し、トランスポートストリームＴＳ（ＡＬＬ）を出力する出力部を備えたチューナと、
　復調後の多重ＴＳ（ＡＬＬ）から、番組を構成している圧縮された映像信号、音声信号、放送中の番組名を表示するためのデータ、付加情報を表示するためのデータを取り出すための指示を行うデパケットコントローラと、
　デパケットコントローラを通じて指示された番組Ａを構成している圧縮された映像信号を伸張し、出力する映像デコーダ、および、デパケットコントローラを通じて指示された番組Ａを構成している圧縮された音声信号を伸張し、出力する音声デコーダと、
　番組表のデータとともに、これに付加して表示される「−現在放送中の番組−」の表示データを、表示装置で表示するための信号として生成するＭＰＵと、
　指示された（付加情報を表示するのに必要な）パケットをＳＲＡＭに取り込み、「ＶＲＡＭ３２、Ｄ／Ａ変換器３３、画面合成器３４によって現在視聴中の画面と合成される」のに適当な形式にデコードし、出力するＭＰＵと、
　を有するディジタルＴＶ放送システムの受信システム。
　
第６．対比
　本願発明と刊行物１発明とを対比する。
　
（１）「複数の放送番組に関するデータが多重化されたデジタル放送信号を受信するチューナ部と、
　前記チューナ部により受信されたデジタル放送信号を復調し、トランスポートストリームを出力する復調部と」について
　刊行物１発明の「チューナ」は、「複数の放送番組に関するデータが多重化されたデジタル放送信号を受信し、さらに、上記受信した信号を復調し、トランスポートストリームＴＳ（ＡＬＬ）を出力する出力部を備えたチューナ」であるから、複数の放送番組に関するデータが多重化されたデジタル放送信号を受信するための受信部、受信した信号を復調する復調部を有し、復調部からトランスポートストリームを出力するものであることは明らかである。
　そして、上記刊行物１発明の「チューナ」が備える「受信部」、「復調部」は、それぞれ、本願発明の「チューナ部」、「復調部」に相当する。
　以上のことから見て、本願発明と刊行物１発明とは
「複数の放送番組に関するデータが多重化されたデジタル放送信号を受信するチューナ部と、
　前記チューナ部により受信されたデジタル放送信号を復調し、トランスポートストリームを出力する復調部」について相違がない。
　
（２）「前記復調部により出力された前記トランスポートストリームから前記放送番組に関する圧縮された映像信号および音声信号と、前記放送番組に関する電子番組表データと、所定の作成言語で記述されたブラウザで処理可能な情報データを抽出する放送番組情報抽出部と」について　
（２ａ）抽出動作について
　刊行物１発明の「デパケットコントローラ」は、復調後の多重ＴＳ（ＡＬＬ）からデータを取り出すための指示を行うのに対し、本願発明の「放送番組情報抽出部」は、復調部により出力された（すなわち復調された）前記トランスポートストリームからデータを抽出している。
　刊行物１発明の復調されたＴＳ（ＡＬＬ）は、復調手段（すなわち復調部）により復調されていることは明らかである。
　刊行物１発明の「ＴＳ（ＡＬＬ）」はトランスポートストリームである点で、本願発明のトランスポートストリームと相違がない。
　また、刊行物１発明の「デパケットコントローラ」が抽出するデータは、放送番組に関する情報であることは明らかである。
　してみると、刊行物１発明の「デパケットコントローラ」と本願発明の「放送番組情報抽出部」は「前記復調部により出力された前記トランスポートストリームからデータを抽出する放送番組情報抽出部」である点で一致している。
　
（２ｂ）抽出するデータについて
　刊行物１発明の「デパケットコントローラ」は、復調後のＴＳ（ＡＬＬ）から、
ア）番組を構成している圧縮された映像信号、音声信号、
イ）放送中の番組名を表示するためのデータ、
ウ）付加情報を表示するためのデータ
　を取り出すための指示を行うものである。
＜ア）番組を構成している圧縮された映像信号、音声信号＞について
　刊行物１発明の「番組を構成している圧縮された映像信号、音声信号」は、「放送番組に関する圧縮された映像信号および音声信号」といいうるものであり、この点で本願発明と相違がない。
＜イ）放送中の番組名を表示するためのデータ＞について
　番組名等をデータに基づき表示装置に表示するものが電子番組表であり、刊行物１発明の番組名の表示は、「放送中の番組名を表示するためのデータ」に基づいて、表示装置で表示するものであるから、電子番組表といえる。また、刊行物１発明の「放送中の番組名」も「放送番組に関する」ものである点で、本願発明と相違がない。してみると、刊行物１発明の「放送中の番組名を表示するためのデータ」は、本願発明の「放送番組に関する電子番組表データ」と相違がない。
＜ウ）付加情報を表示するためのデータ＞について
　刊行物１発明の「付加情報」は、ＥＰＧあるいは、映像信号とは異なる情報を表示するためのデータである。
　本願発明の「所定の作成言語で記述されたブラウザで処理可能な情報データ」は、該情報データに基づきにＷｅｂページなどの表示を行っている（本願明細書【００７７】以下参照。）。すなわち、本願発明のＷｅｂページなどの表示は、ＥＰＧあるいは、映像信号とは異なる情報の表示であり、本願発明の情報データは、ＥＰＧあるいは、映像信号とは異なる情報を表示するためのデータである。
　以上のことから見て、刊行物１発明の「付加情報を表示するためのデータ」と、本願発明の「情報データ」とは、ともに、ＥＰＧあるいは、映像信号とは異なる情報を表示するための「情報データ」である点で相違がない。
　もっとも、本願発明の「情報データ」は「所定の作成言語で記述されたブラウザで処理可能な情報データ」であるのに対し、刊行物１発明の「付加情報を表示するためのデータ」は、「ＭＰＵ２９において表示に適当な形式にデコードされ」【００３４】るようなものではあるが、「所定の作成言語で記述されたブラウザで処理可能な」データではない点で相違する。
　
　以上まとめると、刊行物１発明は
　「前記復調部により出力された前記トランスポートストリームからデータを抽出する放送番組情報抽出部であって、抽出するデータは、
　前記放送番組に関する圧縮された映像信号および音声信号と、
　前記放送番組に関する電子番組表データと、
　情報データ、」
　である点で、本願発明と相違がない。
　もっとも、抽出するデータに関して、本願発明の「情報データ」は「所定の作成言語で記述されたブラウザで処理可能な情報データ」であるのに対し、刊行物１発明の「情報データ」は、「ＭＰＵ２９において表示に適当な形式にデコードされ」【００３４】るようなデータではあるが、「所定の作成言語で記述されたブラウザで処理可能な」データではない点で相違する。
　
（３）「前記放送番組情報抽出部により抽出された前記放送番組に関する圧縮された映像信号および音声信号を圧縮解凍し、放送番組に関する映像信号および音声信号を出力する圧縮解凍処理部と、」について
　　
　刊行物１発明の「映像デコーダ」および「音声デコーダ」は「デパケットコントローラを通じて指示された番組Ａを構成している圧縮された映像信号を伸張し、出力する映像デコーダ、および、デパケットコントローラを通じて指示された番組Ａを構成している圧縮された音声信号を伸張し、出力する音声デコーダ」であり、刊行物１発明の「デパケットコントローラ」、「番組Ａを構成している圧縮された映像信号」、「番組Ａを構成している圧縮された音声信号」、「伸張」は、本願発明の「放送番組情報抽出部」、「放送番組に関する圧縮された映像信号」、「放送番組に関する圧縮された音声信号」、「圧縮解凍」に対応することは明らかであり、この点において、本願発明と刊行物１発明に相違がない。
　以上のことから見て、刊行物１発明は「前記放送番組情報抽出部により抽出された前記放送番組に関する圧縮された映像信号および音声信号を圧縮解凍し、放送番組に関する映像信号および音声信号を出力する圧縮解凍処理部」を備えているといえる。
　
（４）「前記電子番組表データや自機において生成する表示データ等の表示用データを、表示部へ表示するための映像信号に変換するグラフィックス処理部と」について
　
　刊行物１発明の「ＭＰＵ」は「番組表のデータとともに、これに付加して表示される「−現在放送中の番組−」の表示データを、表示装置で表示するための信号として生成するＭＰＵ」である。すなわち、電子番組表のデータを表示装置で表示するための信号を生成している点において、本願発明の「前記電子番組表データを、表示部へ表示するための映像信号に変換する処理部」である点で相違がない。
　刊行物１発明では、番組表として、ＰＡＴとＰＭＴによるプログラム情報から表示信号が生成されるのであり、上記「ＰＡＴとＰＭＴによるプログラム情報」には「−現在放送中の番組−」のような表示を行うためのデータは通常含まれておらず、これは自機において生成している表示信号である。したがって、刊行物１発明の「−現在放送中の番組−」なる表示を行うためのデータは、本願発明の自機において生成する表示データということができるものであり、番組表に付加して表示される「−現在放送中の番組−」なる表示を表示装置で表示するための信号として生成するＭＰＵは、本願発明の「自機において生成する表示データ等の表示用データを、表示部へ表示するための映像信号に変換するグラフィックス処理部」と相違がない。
　以上のことから見て、刊行物１発明のＭＰＵは、「前記電子番組表データや自機において生成する表示データ等の表示用データを、表示部へ表示するための映像信号に変換するグラフィックス処理部」と相違がない。
　
（５）「格納されている複数種類のブラウザの中から、抽出された前記情報データの作成言語に対応するブラウザを選択し、選択した前記ブラウザを用いて、抽出された前記情報データを、前記グラフィックス処理部において処理可能な前記番組表データと同様の形式の表示用データに変換するブラウザ実行部と」について
　
　刊行物１発明は、情報データから表示用の信号を生成する際に、ブラウザを用いておらず、「格納されている複数種類のブラウザの中から、抽出された前記情報データの作成言語に対応するブラウザを選択し、選択した前記ブラウザを用いて、抽出された前記情報データを、前記グラフィックス処理部において処理可能な前記番組表データと同様の形式の表示用データに変換するブラウザ実行部」は有していない。
　よって、本願発明は「格納されている複数種類のブラウザの中から、抽出された前記情報データの作成言語に対応するブラウザを選択し、選択した前記ブラウザを用いて、抽出された前記情報データを、前記グラフィックス処理部において処理可能な前記番組表データと同様の形式の表示用データに変換するブラウザ実行部」を有しているのに対し、刊行物１発明は、当該構成を有しない点で相違する。
　
（６）「前記ブラウザ実行部を制御して、抽出された前記情報データから変換された前記表示用データを前記グラフィックス処理部へ出力させる制御部」について
　
　刊行物１発明の「付加情報を表示するためのデータ」と、本願発明の「情報データ」とは、ともに、ＥＰＧあるいは、映像信号とは異なる情報を表示するための「情報データ」である点で相違がないことは、上記（２）で検討したとおりである。
　刊行物１発明の「ＭＰＵ」は、「（デパケットコントローラを通じて）指示された（付加情報を表示するのに必要な）パケットをＳＲＡＭに取り込み、「ＶＲＡＭ３２、Ｄ／Ａ変換器３３、画面合成器３４によって現在視聴中の画面と合成される」のに適当な形式にデコードし、出力」するものであり、また、「番組表のデータとともに、これに付加して表示される「−現在放送中の番組−」の表示データを、表示装置で表示するための信号として生成する」ものでもある。
　すなわち、刊行物１発明の「（デパケットコントローラを通じて）指示された（付加情報を表示するのに必要な）パケット」は、付加情報を表示するためのデータであるから「情報データ」である。
　そして、刊行物１発明の「ＭＰＵ」は、上記「情報データ」から、番組表とは異なる情報を表示するための映像信号を生成している。
　また、刊行物１発明の「ＭＰＵ」は、番組表を表示するための処理も行っているグラフィックス処理部であることは、上記（４）で検討したとおりである。
　以上のことから見て、刊行物１発明の「ＭＰＵ」は、抽出された前記情報データに基づく表示用データを処理するグラフィックス処理部といえる。
　そして、上記「ＭＰＵ」において、情報データに基づく表示用データを処理するグラフィックス処理を行うためには、情報データに基づく表示用データを前記グラフィックス処理部へ出力させる制御部を有する必要があることは明らかである。
　してみると、刊行物１発明は「抽出された前記情報データに基づく前記表示用データを前記グラフィックス処理部へ出力させる制御部」を有している点で、本願発明と相違がない。
　もっとも、本願発明の「抽出された前記情報データに基づく前記表示用データを前記グラフィックス処理部へ出力させる制御部」は「前記ブラウザ実行部を制御して、抽出された前記情報データから変換された前記表示用データを前記グラフィックス処理部へ出力させる制御部」であるのに対し、刊行物１発明の「番組表とは異なる情報を表示するためのデータを処理部へ出力させる制御部」はそのような制御部でない点で相違する。
　
（７）「デジタルテレビ放送受信装置」について
　
　刊行物１発明の「ディジタルＴＶ放送システムの受信システム」には、デジタルテレビ放送の受信装置も含まれることは明らかであり、刊行物１発明と本願発明はともに「デジタルテレビ放送受信装置」に関する発明である点で相違がない。
　
第７．一致点・相違点　
　本願発明と刊行物１発明との上記対比によれば、本願発明と刊行物１発明とは、
    　
《一致点》
　複数の放送番組に関するデータが多重化されたデジタル放送信号を受信するチューナ部と、
　前記チューナ部により受信されたデジタル放送信号を復調し、トランスポートストリームを出力する復調部と、
　前記復調部により出力された前記トランスポートストリームからデータを抽出する放送番組情報抽出部であって、抽出するデータは、
　前記放送番組に関する圧縮された映像信号および音声信号と、
　前記放送番組に関する電子番組表データと、
　情報データ、であって、
　前記放送番組情報抽出部により抽出された前記放送番組に関する圧縮された映像信号および音声信号を圧縮解凍し、放送番組に関する映像信号および音声信号を出力する圧縮解凍処理部と、
　前記電子番組表データや自機において生成する表示データ等の表示用データを、表示部へ表示するための映像信号に変換するグラフィックス処理部と、
　抽出された前記情報データに基づく前記表示用データを前記グラフィックス処理部へ出力させる制御部と、
　を有するデジタルテレビ放送受信装置
　
《相違点》
１．本願発明では、「情報データ」が、「所定の作成言語で記述されたブラウザで処理可能な情報データ」であるのに対し、
　刊行物１発明では、「情報データ」が、「ＭＰＵ２９において表示に適当な形式にデコードされ」【００３４】るデータではあるが、「所定の作成言語で記述されたブラウザで処理可能な」データではない点。　
２．本願発明では「格納されている複数種類のブラウザの中から、抽出された前記情報データの作成言語に対応するブラウザを選択し、選択した前記ブラウザを用いて、抽出された前記情報データを、前記グラフィックス処理部において処理可能な前記番組表データと同様の形式の表示用データに変換するブラウザ実行部」を有しているのに対し、刊行物１発明は、当該構成を有しない点。　
３．本願発明では、「抽出された前記情報データに基づく前記表示用データを前記グラフィックス処理部へ出力させる制御部」が、「前記ブラウザ実行部を制御して、抽出された前記情報データから変換された前記表示用データを前記グラフィックス処理部へ出力させる制御部」であるのに対し、
　刊行物１発明では、「番組表とは異なる情報を表示するためのデータを処理部へ出力させる制御部」が、そのような制御部でない点。　　
　
第８．判断
（１）相違点１について
　上記拒絶理由通知書にて当審が通知した刊行物２ないし４には以下のとおりの記載がある。
　
ａ）刊行物２
【０００１】
【発明の属する技術分野】この発明は、テレビジョン放送等に多重化されたコンテンツ情報、例えばインターネット上のコンテンツ情報またはこれに関連するコンテンツ情報を映像表示する情報表示方法および装置に関し、とくにコンテンツ情報の表示中に他のコンテンツ情報を自動的に取り出して表示できるようにしたものである。
　
【００１８】この実施例においては、放送局１０は、ＷＷＷサーバからのＨＴＭＬ（ハイパーテキストマークアップランゲージ）で記述されたウェブ情報（ウェブページ）を受け取り、通常の放送プログラムの放送信号に多重して放送する。この場合ウェブ情報を直接用いて送信するのでなく、コンテンツ製作用端末１２で加工して送信してもよく、コンテンツ製作用端末１２で個別に用意した情報を送信するようにしてもよい。多重して送信する情報のフォーマットや多重化の方法については後述する。
　
【００３９】ブラウザ部４７は、シーケンス制御部５３、コンテンツ解析部５４、コンテンツ表示部５５およびアイコン表示部５６等からなっている。シーケンス制御部５３は、直近の予定を記憶し、内部に持つタイマを監視して、指定の時刻にＢ−ＨＴＴＰサービス部４６を呼び出してコンテントメッセージを取得する。コンテンツ解析部５４は、取得したコンテントメッセージを解析する。例えばＨＴＭＬ文法で記述された文書の解析等を行う。コンテンツ表示部５５は、コンテンツ解析部５４の解析結果に基づいて表示を行う。アイコン表示部５６は、メッセージを受信したことを示すアイコンを画面に表示する。
　
【００４１】画面表示は例えば図１２に示すように行える。この例では、画面に表示する要素が、ウェブ画面４７ａおよびテレビ画面４７ｂである。ウェブ画面４７ａはインターネットのＷＷＷブラウザと同様な外観とユーザインターフェースを有する。画面の表示モードは例えばつぎの３つであり、切り替えることができる。
テレビ表示モード：テレビ画面を全画面に表示する。
ウェブ表示モード：ウェブ画面を全画面に表示する。
複合表示モード：ウェブ画面の一部にテレビ画面を表示する。
アイコン情報を含むメッセージを受信すると、有効期間開始時刻に、例えば画面下部に対応するアイコンを表示する。そのメッセージ中にブラウザに表示するコンテントボディが含まれている場合、アイコンをクリックすると、ウェブ画面にそのコンテンツボディが表示される。このときテレビ表示モードであれば、モードが複合画面モードに移行する。ウェブ画面が表示されるウェブモードまたは複合表示モードではコンテンツボディが表示される。この場合、ユーザは自動更新表示モードと手動表示モードとを選択できる。自動更新表示モードにおいては、現在のコンテントメッセージの表示を、有効期間開始時刻が新たに到来したライブモードのコンテントメッセージの表示で更新する。手動表示モードにおいては、有効期間開始時刻が到来したライブモードのコンテントメッセージをスプールしておき、ユーザ操作に基づいて順次に、あるいはダイアローグで選択して、表示する。
　
【００４４】［ウェブ画面表示］図１６は、ライブモードエレメントにより指定時刻に自動的に表示されるべき情報をウェブ画面に表示する動作を示している。この図において、有効期間開始時刻（図６の’Ｓ’）を参照してタイマ（図示しない）がウェブ表示動作を開始する（Ｓ１０１）。そうすると、表示タイミング順にインデックス要素を１つ取りだし（Ｓ１０２）、ライブフラグを用いてライブモードかどうかを判定し（Ｓ１０３）。ライブモードでなければ（例えばダウンロード用メッセージの場合）、そのまま処理をせずに終了する。ライブモードの場合には、キャッシュからメッセージを読み出し、ＨＴＭＬ文書を解析し、ウェブ画面に表示する（Ｓ１０４、Ｓ１０６、Ｓ１０７）。
【００４５】ステップＳ１０５ではレイアウト情報の取り出しが行われる。レイアウト情報がある場合にはブラウザのレイアウトが変更される。図１７にも示すように、ブラウザのレイアウトの情報には、ブラウザ自体またはブラウザに表示されるコンテンツの配置、色、形状、背景、フォント、その他の装飾情報が含まれている。例えば図１７に示すように、ブラウザ内に表示されるテレビ画面（複合表示モード）についてｘ＝２０、ｙ＝２０、ｈ＝２４０、ｗ＝３２０と指定することにより、図１８に示すようなレイアウトに変更することができる。
　
ｂ）刊行物３　　
「３．衛星データ放送
　衛星放送のデータチャンネルの伝送方式には１９８８年３月に、また、ＨＤＴＶについては１９９０年６月に電通技審から答申されている。・・・
　このデータチャンネルを使用する放送サービスの方式規格について、ＢＴＡなどの議論を踏まえて１９９３年６月に当審がまとめられた。・・・
　その後、番組への受信者の容易なアクセス、ＨＤＴＶ字幕や各種グラフィックスなどを含む文字情報、自動楽器の演奏情報を放送するテレミュージック、将来のマルチメディアへの対応などを検討して今回の当審がまとめられた。マルチメディアに関連する複合データ信号について次に述べる。」（２８頁右欄１９行−３８行）　
　
「３．２リンクの符号化
　マルチメディアへサービスにおける対話的な視聴やそれを利用した番組アクセス支援のサービスのためにリンク情報の符号化が規定されている。これまでの放送方式との共通性、将来のマルチメディアサービスへの拡張性を考慮して、固定形式と汎用形式の二つを規定した。固定形式はＦＭ多重放送における選択制御のようにリンク元とリンク先との対応関係を示す。汎用形式はＭＨＥＧ、ＨｙｐｅｒＯＤＡなどの国際標準やＨＴＭＬなどの業界標準に対応できるよう、拡張性が確保されている。」（２９ページ右欄２行−１４行）　
　
ｃ）刊行物４
　当所では、衛星放送のデータチャンネルや、将来の放送衛星および地上での統合デジタル放送・・を通じて、新しいマルチメディア放送番組をサービスする‘ＰＲＥＳＥＮＴ’・・の開発を進めている。ＰＲＥＳＥＮＴは、ニュースや生活情報など幅広い分野の情報を常に更新しつつ放送し、知りたい最新の情報を受信者が興味に応じてあたかも受信機と対話するかのようにして視聴できる放送サービスである。それぞれの情報は、文字、図形、静止画、動画、音声などのメディアデータを統合したマルチメディアの放送番組である。
　・・・・
　ここでは、ＰＲＥＳＥＮＴのシステムの概要を紹介し、・・・受信者側で多様な視聴法ができるようにマルチメディアデータを統合する「構造化」について述べる。」（７頁左欄２行−最下行）
　
　「構造化
　マルチメディアに関する技術の１つに構造化がある。構造化は、受信機が受信したマルチメディアデータをその能力に応じてディスプレイすることができるように、各メディアデータをどのように組み立てればよいかということを表現するためのものである。構造化の国際標準に、ＯＤＡ、ＨｙＴｉｍｅおよびＭＨＥＧなどがある。」（１０ページ左欄１６行−最下行）
　
　以上の刊行物２ないし４の記載を見れば、放送局側で放送に付加したデータによりマルチメディアサービス提供し、それを受信者がテレビ受像器で表示するとき、当該表示のためのデータを送受信する際、「ＨＴＭＬ」、「ＭＨＥＧ」、「ＨｙｐｅｒＯＤＡ」、「ＨｙＴｉｍｅ」などの言語で記述された情報データを用いることが周知の技術であったことが理解できる。加えて、上記「ＨＴＭＬ」、「ＭＨＥＧ」、「ＨｙｐｅｒＯＤＡ」、「ＨｙＴｉｍｅ」などの言語を利用して、表示装置で表示する際、上記言語で記述されたデータを処理して、表示のためのデータを生成するプログラムをブラウザと言うことは技術常識である。
　そして、刊行物１発明の「付加情報」は、放送に付加した文字や簡単なグラフィックであり、刊行物２ないし４のマルチメディアサービスで提供される情報と同じである。
　してみると、刊行物１発明の「付加情報を表示するためデータ（すなわち「情報データ」）」は、刊行物２ないし４のマルチメディアサービスで提供される情報データと同様のデータであり、刊行物１発明において、何らかのデータ形式で情報データを送受信することが必要なことは当たり前のことであるから、刊行物２ないし４で開示されている周知の所定の作成言語で記述されたブラウザで処理可能なデータを利用しようとすることは、当業者であれば、ごく普通に想起し得たことといえる。
　そうすると、刊行物１発明の「情報データ」として、「所定の作成言語で記述されたブラウザで処理可能な情報データ」を採用することは、当業者が容易に推考し得たことであるといえる。
　
（２）相違点２、３について
　上記拒絶理由通知書にて当審が通知した刊行物５には以下のとおりの記載がある。
　
　「７．１ＷＷＷ（Ｗｏｒｌｄ　Ｗｉｄｅ　Ｗｅｂ）サーバーとブラウザー
　商品デモや説明に必要となる情報を管理するのが、ＷＷＷサーバーの役割である。一般的にこの情報（コンテンツという）は、ＷＷＷの規約に則ってＨＴＭＬ（Ｈｙｐｅｒ　Ｔｅｘｔ　Ｍａｒｋｕｐ　Ｌａｎｇｕａｇｅ）の言語で記述されているが、画像や音声に加えて文字などのコンテンツの関係を表記するものである。
　少々難しくなるが、このＨＴＭＬは、文章や画像、絵などの位置や、他のコンテンツへの連携を表記するレイアウト言語にすぎない。したがって、消費者が、電子商品カタログなどに記載されている多くのメニューの中から、目的とする商品をすぐに取り出そうとすると、少々時間がかかってしまう。また、コンテンツを取り出す（ダウンロード）機能を持つブラウザーは、音声や動画を再生する機能までは持っていないので、これらを再生するには、通常ブラウザーとは別のソフト（ヘルパー・プログラムやプラグイン・プログラム）が必要となる（図７．１）。
　さらに、消費者が動画や音声を利用したければ、静止画像と比較して、大量のデータ通信回線を通じてサーバーから取り出さなければならず、時間と費用がかかってしまう欠点がある。これは、現状では技術的な問題というよりは、消費者が負担する回線費用の問題の方が大きいのである。コストの安いスーパーハイウェイでもすぐに実現できれば問題ないであろうが、当面、現状のインターネットの通信回線スピードには米国ですら制約があるので、他の技術を併用するしか手がないのである。
　そこで、新しい試みが米国で開始された。“ＶＲＭＬ”（Ｖｉｒｔｕａｌ　Ｒｅａｌｉｔｙ　Ｍｏｄｅｌｉｎｇ　Ｌａｎｇｕａｇｅ）と“Ｊａｖａ”と呼ばれる方式である。ＶＲＭＬ（仮想現実表記言語）は、製造業の設計現場などで使われているＣＡＤ（Ｃｏｍｐｕｔｅｒ−Ａｉｄｅｄ　Ｄｅｓｉｇｎ；コンピュータ支援による設計）の技術からの応用である。米国のＳｉｌｉｃｏｎ　Ｇｒａｐｈｉｃｓ（ＳＧＩ）社により開発されたもので、ＣＡＤで作成した商品の３次元グラフィックス情報から、直接ＶＲＭＬ言語で、その商品の色、形、大きさ、その位置などをテキストデータ形式にて表記することができる。
　この技術を使うと、３次元画像が、データ量の多いビット情報でなくデータ量の少なくてすむテキスト・データで表記できるので、効率が極めて良い。専用ブラウザーにより、動画よりも少ないデータ量で商品の３次元空間でのデモ（ＶｉｒｔｕａｌＲｅａｌｉｔｙ；仮想現実）ができ、しかも臨場感ある商品表現が可能となる。消費者が、対話的に操作することもできる機能を有し、車や家具、インテリアなどの商品を、その視点を変えてみられるので、魅力的な商品デモが提供できる。多くの期待を担って、今、まさに試行が始まろうとしている。
　ただ、ＶＲＭＬは、ＷＷＷサーバの標準仕様であるＨＴＭＬとは全く関係がないため、専用のブラウザーを必要とする難点がある。また、いくら少ない回線容量でよいとはいっても、現行のアナログ回線の回線速度（最大２８．８Ｋｂｐｓ）では十分とは言えず、なめらかな動画表現を行うためには、やはりＩＳＤＮによる６４Ｋｂｐｓ以上が必要だと言われている。だらに、３次元の画像を再生するＣＰＵやグラフィック・ボードの処理能力も強力なものが要求されており、その普及には課題が多いのも現実である（図７．２）。」（１６８ページ１行−１７０頁４行）
　そして、上記された図７．２を見ると、サーバーとパソコンとがインターネットで接続され、ＨＴＭＬ言語で作成された文章とＶＲＭＬに変換された画像とがサーバーからパソコンに別々に送られ、パソコン側で両者（ＨＴＭＬ言語で作成された文章とＶＲＭＬに変換された画像）を表示するため、ＶＲＭＬ用ブラウザーとＨＴＭＬ用ブラウザーの両者を装備していることが理解できる。
　
　以上のことから見て、刊行物５の記載から、パソコンの技術分野ではあるが、複数の言語で記述された表示用データが送られてくる端末側において、上記複数の言語で記述された表示用データから画面表示を行うため、各言語に対応したブラウザをそれぞれ装備し、当該複数のブラウザを用いて表示を行うことが知られていたことが理解できる。
　
　上記第８．（１）で検討したように、放送にマルチメデイアサービスのためのデータを付加して送信し、受信側で上記データから、マルチメディア情報を表示するとき所定の言語（「ＨＴＭＬ」、「ＭＨＥＧ」、「ＨｙｐｅｒＯＤＡ」、「ＨｙＴｉｍｅ」）で記述されたデータを利用することはよく知られていたことであり、また、上に列挙したように複数の言語が、上記所定の言語として採用される候補として考慮されていたことも理解できる。
　ところで、刊行物１発明が送受信しようとしているマルチメディアデータは、（テレビ放送のような）映像データ、テキストデータ、図形データ、音声データ、（その他のデータ）のように、異なる特徴を持つ様々なデータであり、また、マルチメディアデータがこのように異なる特長を有するデータであるため、これを送受信するために採用する言語とデータの組み合わせによって、効率的に送受信できる場合と、そうでない場合があったことが、刊行物５の記載から読み取ることができる。
　そして、異なる特長を有するデータごとに、効率的に送受信することができる言語が異なっている場合、各データを最大限効率的に送受信を行うためには、各データ毎に異なる最適な言語を利用し、送受信装置において、これらすべての言語に対応できるようにすることは当業者が容易に推考し得たことである。
　そして、受信側で複数の言語に対応するように複数のブラウザを装備することは、刊行物５に記載されるように知られているのであるから、刊行物１発明において、「所定の作成言語で記述されたブラウザで処理可能な情報データ」を採用しようとする際、上記所定の作成言語が複数あることも考慮し、複数の作成言語に対応できるように複数のブラウザを装備することは当業者が容易に想到しえたことであるといえる。
　さらに、複数の作成言語に対応した、複数のブラウザを装備して処理を行う際、作成言語に対応したブラウザを利用しなければ正しい表示が行われないことは明らかであるから、そのために受信されたデータを解析し、言語を特定し、上記特定された作成言語に対応したブラウザを選択することは、複数のブラウザを採用すれば必然的に採用される構成である。
　また、刊行物１発明では、番組表の表示データと付加情報の表示データとを同じＭＰＵにて処理していることから見て、番組表の表示データと付加情報の表示データとが、共通のデータ形式であれば、ＭＰＵは番組表と付加情報に対して同様の処理を行えばよいことは当業者であれば当然類推し得たことであり、刊行物１発明に対して、「所定の作成言語で記述されたブラウザで処理可能な情報データ」を採用したとき、ブラウザの処理として、「番組表データと同様の形式の表示用データに変換する」ようにすることは当業者が容易に想到しえたことである。
　
  審判請求人は平成２２年９月１０日付け意見書にて
「２．本願発明が特許されるべき理由」において、概略「引用文献５に記載されている周知技術は、インターネット上から取得した情報データをパーソナルコンピュータを用いて処理することを前提としています。
　これに対して本願発明は、放送信号に包含されて送信された情報データをデジタルテレビ放送受信装置によって処理するものです。
・・・
　したがって、本願発明のように、放送信号に包含されて送信された情報データを処理するデジタルテレビ放送受信装置に、インターネット上から取得した情報データを処理するパーソナルコンピュータに対する周知技術を、当業者が容易に採用できるとは到底認めることができません。」
と主張している。　
　
　「ＨＴＭＬ」等の作成言語を用いて、文章や図形等のマルチメディアデータをやりとりすることは、インターネット上から取得した情報データを処理するパーソナルコンピュータにおける周知技術である。
　しかし、上記第８．（１）で検討したとおり、デジタルテレビ放送の受信装置において、「ＨＴＭＬ」、「ＭＨＥＧ」、「ＨｙｐｅｒＯＤＡ」、「ＨｙＴｉｍｅ」などの言語で記述された情報データを用いて、文章や図形等のマルチメディアデータをやりとりすることが周知の技術であったのであるから、パーソナルコンピュータにおける前記周知技術が、既に、デジタルテレビ放送受信装置に採用されていたということができる。
　また、上記第８．（１）で検討したとおり、刊行物１発明において、パーソナルコンピュータにおける周知技術である「「ＨＴＭＬ」、「ＭＨＥＧ」、「ＨｙｐｅｒＯＤＡ」、「ＨｙＴｉｍｅ」などの言語で記述された情報データを用いて、文章や図形等のマルチメディアデータをやりとりする」技術事項を採用することは当業者が容易に推考し得たことであり、刊行物１発明において、当該技術事項を採用した際、当該技術事項に関連する刊行物５に記載された「パーソナルコンピュータにおける周知技術」も刊行物１発明に適用しようとすることは、当業者であれば容易に想到し得たことである。
　したがって、審判請求人の上記主張は採用することができない。
　
　なお、上記第６．（４）において、本願発明の「自機において生成する表示データ」が、刊行物１発明の「付加して表示される「−現在放送中の番組−」の表示データ」と相違がないとしたが、仮に、本願発明の「自機において生成する表示データ」が、番組表に付加されるようなデータではない（すなわち番組表とは関係のない）表示に関するデータであって、この点相違するとしても、上記相違点は当業者が容易に推考し得たことである。
　すなわち、通常、テレビ受像器が、放送映像とは異なる表示（メニュー、お知らせ等）を行うことは周知のことであり、そのような表示画像の生成は、番組表の画像を生成する画像生成部と兼用することは、例えば、特開平１０−４５２７号公報にあるとおり本願出願前周知の技術事項であるから、本願発明の「自機において生成する表示データ」が番組表に付加されるようなデータではない（すなわち番組表とは関係のない）表示に関するデータであったとしても当該相違点は、当業者が容易に推考し得たことである。
　
（４）まとめ（判断）
　以上のとおり、上記相違点に係る構成は、当業者が容易に想到しえたことである。
　また、本願発明の作用効果は、刊行物１ないし５及び周知技術から当業者が予測できる範囲のものであり、格別顕著なものであるとは認められない。
　
第９．まとめ
　したがって、本願発明は、刊行物１に記載された発明及び刊行物２ないし５に記載された技術事項に基づいて当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　
　よって、本願は拒絶されるべきものである。 
　
　よって、本願は拒絶されるべきものである。