ポートフォリオ機能
この判例には、下記の判例・審決が関連していると思われます。
| 審判番号（事件番号） | データベース | 権利 |
|---|---|---|
| 平成25行ケ10176審決取消請求事件 | 判例 | 特許 |
| 平成25行ケ10207審決取消請求事件 | 判例 | 特許 |
| 平成25行ケ10215審決取消請求事件 | 判例 | 特許 |
| 平成25行ケ10249審決取消請求事件 | 判例 | 特許 |
| 平成25行ケ10235審決取消請求事件 | 判例 | 特許 |
| 元本PDF |
裁判所収録の全文PDFを見る
 |
|---|
| 事件 |
平成
24年
(行ケ)
10406号
審決取消請求事件
|
|---|---|
| 裁判所のデータが存在しません。 | |
| 裁判所 | 知的財産高等裁判所 |
| 判決言渡日 | 2014/03/26 |
| 権利種別 | 特許権 |
| 訴訟類型 | 行政訴訟 |
| 判例全文 | |
|---|---|
|
判例全文
平成２６年３月２６日判決言渡 同日原本受領 裁判所書記官 平成２４年（行ケ）第１０４０６号 審決取消請求事件 口頭弁論終結日 平成２６年２月２６日 判 決 原 告 三 星 電 子 株 式 会 社 訴訟代理人弁理士 伊 東 忠 彦 同 伊 東 忠 重 同 大 貫 進 介 同 宮 崎 修 被 告 特 許 庁 長 官 指 定 代 理 人 奥 村 元 宏 同 小 池 正 彦 同 樋 口 信 宏 同 山 田 和 彦 主 文 １ 原告の請求を棄却する。 ２ 訴訟費用は原告の負担とする。 ３ この判決に対する上告及び上告受理申立てのための付加期間を ３０日と定める。 事実及び理由 第１ 請求 特許庁が不服２０１０−２２１０２号事件について平成２４年７月９日にした審 決を取り消す。 第２ 事案の概要 １ 特許庁における手続の経緯等 (1) 原告は，平成１９年４月２０日，発明の名称を「ソフトウェアモジュールの 組合せによってＤＳＰコードを生成する装置及びその方法」とする発明（請求項の 数７）について特許出願（特願２００７−１１１３３３号。パリ条約による優先権 主張：平成１８年（２００６年）５月３日，優先権主張国：大韓民国。以下「本願」 という。）をし，平成２２年１月２８日付けの拒絶理由通知を受けたことから，同年 ５月７日付け手続補正書（請求項の数７）を提出したが，同年５月２１日付けで拒 絶査定を受けたため，同年１０月１日，これに対する不服の審判を請求し，併せて 同日付け手続補正書により特許請求の範囲を補正した（請求項の数５，以下「本件 補正」という。（甲４，５，７〜１０） ） 。 (2) 特許庁は，前記(1)の請求を不服２０１０−２２１０２号事件として審理し， 平成２４年７月９日，「本件審判の請求は，成り立たない。」との審決（以下「本件 審決」という。）をし，その謄本は，同年７月２４日，原告に送達された。 (3) 原告は，平成２４年１１月２１日，本件審決の取消しを求める本件訴訟を提 起した。 ２ 本件審決が対象とした特許請求の範囲の記載 (1) 本願発明 本件補正前の特許請求の範囲の請求項１の記載は，平成２２年５月７日付け手続 補正書（甲７）により補正された次のとおりのものである。以下，この請求項１に 記載された発明を「本願発明」といい，本願に係る明細書（甲７）を「本願明細書」 という。 【請求項１】 デジタルシグナルプロセッサ（ＤＳＰ）処理部と， コーデックサーバから第１のソフトウェアモジュールをダウンロードする手段と， ダウンロードされた第１のソフトウェアモジュールと，少なくとも第２のソフト ウェアモジュールとを記憶する記憶部と， 前記記憶された第１と第２のソフトウェアモジュールを組み合わせてＤＳＰコー ドを生成し，前記ＤＳＰ処理部にロードするＤＳＰコード生成部と，を有し， 前記ＤＳＰ処理部は前記ロードされたＤＳＰコードをデコーディングして，前記 第１のソフトウェアモジュールに対応するマルチメディアコンテンツを処理するこ とを特徴とする装置。 (2) 本願補正発明 本件補正後の特許請求の範囲の請求項１の記載は，次のとおりである（甲１０）。 以下，この請求項１に記載された発明を「本願補正発明」という。なお，文中の下 線部は，補正箇所を示す。 【請求項１】 デジタルシグナルプロセッサ（ＤＳＰ）処理部と， コーデックサーバから第１のソフトウェアモジュールをダウンロードする手段と， ダウンロードされた第１のソフトウェアモジュールと，少なくとも第２のソフト ウェアモジュールとを記憶する記憶部と， 前記記憶された第１と第２のソフトウェアモジュールを組み合わせてＤＳＰコー ドを生成し，前記ＤＳＰ処理部にロードするＤＳＰコード生成部と，を有し， 前記ＤＳＰ処理部は前記ロードされたＤＳＰコードをデコーディングして，前記 第１のソフトウェアモジュールに対応するマルチメディアコンテンツを処理し， 前記マルチメディアコンテンツは，前記コーデックサーバの位置情報と前記第１ のソフトウェアモジュールの識別情報とを含み， 前記マルチメディアコンテンツに対応する前記第１のソフトウェアモジュールが 前記記憶部に記憶されていない場合，前記コーデックサーバの位置情報と前記第１ のソフトウェアモジュールの識別情報とに基づき，外部ネットワークに位置した前 記コーデックサーバに前記第１のソフトウェアモジュールのダウンロードを要求す るメッセージを生成及び伝送する制御部をさらに有することを特徴とする装置。 ３ 本件審決の理由の要旨 (1) 本件審決の理由は，要するに，@本願補正発明は，下記アの刊行物（以下「引 用例」という。）に記載された発明（以下「引用発明」という。，下記イ及びウの公 ） 知文献及び技術常識に基づいて，当業者が容易に発明をすることができたものであ り，特許法29条2項の規定により，特許出願の際独立して特許を受けることがで きないものであるから，本件補正は，平成２３年法律第６３号改正附則2条18項 によりなお従前の例によるとされる同法による改正前の特許法（以下「法」という。） 17条の2第6項において準用する法126条5項の規定に適合していないことか ら，特許法159条1項において読み替えて準用する同法53条1項の規定により 却下すべきものである，A本願発明は，引用発明及び技術常識に基づいて，当業者 が容易に発明をすることができたものであるから，特許法29条2項の規定により 特許を受けることができない，というものである。 ア 引用例：“Naoto SHIMIZU, et al, A Novel Decoder-downloadable System for Content-oriented Coding, Global Telecommunications Conference, 2002. GLOBECOM’ 02.IEEE, 2002 年 11 月 17 日，Volume.2, pages 1638-1642”（平成１４ 年（２００２年）１１月１７日刊行。甲１） イ 公知文献１ 特表２００６−５１１９０２号公報 ： （平成１８年４月６日公開。 甲２） ウ 公知文献２：特開２００１−２０２０９４号公報（平成１３年７月２７日公 開。甲３） (2) 本件審決が認定した引用発明は，次のとおりである。 コアエンジンと， デコーダサーバからデコーダのバイナリデータをダウンロードするデコーダ・コ ンポーネント管理エンジンと， ダウンロードされた複数のデコーダの管理をするデコーダ・コンポーネント管理 エンジンと， デコーダは，コアエンジンでインストールされ， コアエンジンは，メディアの再生を行い， 各コンテンツのためのプロファイルを記述したコンテンツ情報には，対応する最 適なデコーダ情報を含み， デコーダがクライアント側に既に存在しているか否かについて，デコーダ・コン ポーネント管理エンジンに確認し，対応するデコーダを有していない場合には，デ コーダ情報を使用して，情報サーバから得られたデコーダＵＲＩにより，必要とな るデコーダの問い合わせを行い，デコーダ・サーバからデコーダをダウンロードす るデコーダ・コンポーネント管理エンジンを有するクライアント。 (3) 本願補正発明と引用発明との対比 本件審決が認定した本願補正発明と引用発明との一致点及び相違点は，以下のと おりである。 ア 一致点 処理部と， コーデックサーバからコーデックのバイナリデータをダウンロードする手段と， ダウンロードされた複数のコーデックのバイナリデータを記憶する記憶部と， 前記記憶されたコーデックのバイナリデータを実行コードとして処理部にロード する手段と，を有し， 前記処理部は，前記ロードされた実行コードにより前記コーデックのバイナリデ ータに対応するマルチメディアコンテンツを処理し， 前記マルチメディアコンテンツに関する前記コーデックサーバの位置情報と前記 コーデックのバイナリデータの識別情報とが用いられ， 前記マルチメディアコンテンツに対応する前記コーデックのバイナリデータが前 記記憶部に記憶されていない場合，前記コーデックサーバの位置情報と前記コーデ ックのバイナリデータの識別情報とに基づき，外部ネットワークに位置した前記コ ーデックサーバに前記コーデックのバイナリデータのダウンロードを要求するメッ セージを生成及び伝送する制御部を有する装置。 イ 相違点１ 本願補正発明では，「デジタルシグナルプロセッサ（ＤＳＰ）」により処理が行わ れるものであるのに対し，引用発明では，デジタルシグナルプロセッサ（ＤＳＰ） により処理が行われるものとはされていない点。 ウ 相違点２ 本願補正発明では，「ソフトウェアモジュールの識別情報」に基づき，「ソフトウ ェアモジュール」をダウンロードして記憶し，記憶された複数の「ソフトウェアモ ジュール」を組み合わせてコーデックのコードを生成し，ソフトウェアモジュール」 「 に対応するマルチメディアコンテンツを処理するものであるのに対し，引用発明で は，「デコーダ情報」に基づき，「デコーダのバイナリデータ」をダウンロードして 記憶し，「デコーダ」に対応するメディア又はコンテンツが再生されるものであり， 複数のソフトウェアモジュールを組み合せてデコーダのコードを生成することとは されていない点。 エ 相違点３ 本願補正発明では，ＤＳＰ処理部は，ロードされたＤＳＰコードを「デコーディ ング」して処理を実行するのに対し，引用発明では，コアエンジンが，読み込まれ た実行コードをデコーディングするものとはされていない点。 オ 相違点４ 本願補正発明では，「マルチメディアコンテンツ」の中に，「コーデックサーバの 位置情報」と「第１のソフトウェアモジュールの識別情報」が含まれるのに対し， 引用発明では， 「コンテンツ」の中に「デコーダＵＲＩ」と「デコーダ情報」が含ま れるものとはされていない点。 (4) 本願発明と引用発明との対比 本件審決が認定した本願発明と引用発明との一致点及び相違点は，以下のとおり である。 ア 一致点 処理部と， コーデックサーバからコーデックのバイナリデータをダウンロードする手段と， ダウンロードされた複数のコーデックのバイナリデータを記憶する記憶部と， 前記記憶されたコーデックのバイナリデータを実行コードとして処理部にロード する手段と，を有し， 前記処理部は，前記ロードされた実行コードにより前記コーデックのバイナリデ ータに対応するマルチメディアコンテンツを処理する装置。 イ 相違点１ 本願発明では，「デジタルシグナルプロセッサ（ＤＳＰ）」により処理が行われる ものであるのに対し，引用発明では，デジタルシグナルプロセッサ（ＤＳＰ）によ り処理が行われるものとはされていない点。 ウ 相違点２ 本願発明では，「ソフトウェアモジュールの識別情報」に基づき，「ソフトウェア モジュール」をダウンロードして記憶し，記憶された複数の「ソフトウェアモジュ ール」を組み合わせてコーデックのコードを生成し， 「ソフトウェアモジュール」に 対応するマルチメディアコンテンツを処理するものであるのに対し，引用発明では， 「デコーダ情報」に基づき， 「デコーダのバイナリデータ」をダウンロードして記憶 し， 「デコーダ」に対応するメディア又はコンテンツが再生されるものであり，複数 のソフトウェアモジュールを組み合せてデコーダのコードを生成することとはされ ていない点。 エ 相違点３ 本願発明では，ＤＳＰ処理部は，ロードされたＤＳＰコードを「デコーディング」 して処理を実行するのに対し，引用発明では，コアエンジンが，読み込まれた実行 コードをデコーディングするものとはされていない点。 ４ 取消事由 (1) 本願補正発明の容易想到性の判断に係る手続違背（取消事由１） (2) 本願補正発明と引用発明との一致点の認定の誤り，相違点の看過（取消事由 ２） (3) 本願補正発明と引用発明との相違点４に係る判断の誤り（取消事由３） (4) 本願補正発明と引用発明との相違点１及び２に係る判断の誤り（取消事由 ４） 第３ 当事者の主張の要旨 １ 取消事由１（本願補正発明の容易想到性の判断に係る手続違背）について 〔原告の主張〕 (1) 本件審決は，本願補正発明と引用発明との相違点４について，引用発明並び に公知文献１及び２（甲２，３）に記載された公知技術に基づいて，当業者であれ ば容易に想到できると判断したが，拒絶理由通知及び拒絶査定において，公知文献 １及び２は何ら引用されておらず，上記各公知文献は審決において初めて示された ものであり，原告に対して，拒絶査定の理由と異なる新たな拒絶理由の通知はなく， 意見書提出の機会も与えられなかった。したがって，本件審決には，特許法１５９ 条２項により準用される同法50条に違反する違法があり，その違法は審決の結論 に影響を及ぼすことが明らかである。 (2) 特許法159条2項前段は，同法50条の規定を拒絶査定不服審判に準用す ることから，当該審判の審理において，審判長は，拒絶査定の理由と異なる拒絶の 理由を発見した場合には，特許出願人（審判請求人）に対し，拒絶の理由を通知し， 相当の期間を指定して，意見書を提出する機会を与えなければならない。 これに対し，同法159条1項後段及び２項後段は，同法50条ただし書の規定 により拒絶理由を通知することなく補正却下できる例外的な場合として，17条の 「 ２第１項…第４号（拒絶査定不服審判請求時の補正）に掲げる場合」を追加する規 定となっていることから，特許出願人が拒絶査定不服審判を請求すると同時に特許 請求の範囲を補正した場合において，その補正が同法17条の2第3項ないし６項 の規定に違反するときは，拒絶理由が通知されずにいきなり補正却下され拒絶審決 を受けることがある。 補正却下の理由が，新規事項追加違反（同法17条の2第3項），技術的特徴変更 違反（同法17条の2第4項），限定的減縮違反（同法17条の2第5項）のいわゆ る補正要件違反である場合には，補正要件違反であることを特許出願人がある程度 想定できる（補正要件違反は特許出願人の責任である場合もある）から，拒絶理由 通知なく補正却下され拒絶審決がされても，受忍できる範囲といえる。しかし，拒 絶査定不服審判を請求し，特許請求の範囲について拒絶査定の理由を解消するよう な限定を付加して補正をした特許出願人（審判請求人）に対する補正却下の理由が， 特許出願人が想定し得ない新たな引用文献を引用した新たな拒絶の理由である独立 特許要件違反の場合には，特許出願人に何ら責任はなく，かかる場合にまで意見書 提出の機会を与えないことは，特許庁審判官による再度の審査（審理）を適正に受 ける権利を，特許出願人から不当に奪うものである。 そもそも補正却下の対象を規定した特許法53条は，拒絶査定を受けてもその後 拒絶査定不服審判請求時に補正が可能である審査に関するものであり，拒絶査定不 服審判における審理には当てはまらない。また，補正却下を適用する同法50条た だし書は，いわゆる補正要件違反を念頭に置いたものである。さらに同法53条及 び50条ただし書を拒絶査定不服審判における審理に準用した同法159条1項及 び２項の立法趣旨は，拒絶査定不服審判請求時にした補正が新規事項を追加するも のである場合において優先的に補正却下を適用することにあるのであって，拒絶査 定不服審判請求時に原査定の拒絶理由を解消すべく請求項を減縮した補正を，意見 書・補正書の提出機会を与えずに，新たな拒絶理由によって補正却下するような事 態に適用することにあるのではない。上記によれば，同法159条1項及び２項は 拒絶査定不服審判請求時にした補正が新規事項を追加するものである場合において 優先的に補正却下を適用するために規定されたものであり，その立法過程において， 拒絶査定不服審判請求時に原査定の拒絶理由を解消すべく請求項を減縮した補正が 新たな引用文献に基づく新たな拒絶理由によって，意見書・補正書の提出機会が与 えられずに補正却下されてしまう事態は想定されていない。 したがって，拒絶査定不服審判請求時にした補正を，補正違反の態様にかかわら ず一律に補正却下の対象とした同法159条1項後段及び２項後段の規定自体が立 法の誤りであり，憲法31条に反し違憲であって，本件審決もまた違憲な規定に則 ったものであるから違憲である。 (3) また，本件のように拒絶査定不服審判請求時に原査定の拒絶理由を解消する ために特許請求の範囲を減縮した補正を，新たな引用文献に基づく新たな拒絶理由 で却下する場合には，審判合議体は，いきなり補正却下・拒絶審決をするのではな く，先ず拒絶理由を通知するとの運用をすることが，特許制度の趣旨及び憲法３１ 条に沿うものであるから，本件審決は，特許法159条1項後段及び２項後段の規 定を適切に運用することを怠った違法性，違憲性がある。 (4) 被告は，特許出願人は，自らの判断で，多項制を活用して，出願時や最初の 拒絶理由通知に対する補正により特許請求の範囲に記載すれば補正却下を回避でき る旨主張するが，本件審決において初めて示された公知文献１及び２並びに補正却 下の理由については，拒絶査定不服審判請求時に本件補正をするに当たっては知り 得ないものであるから，自らの判断で補正却下を回避することはできなかったので あり，被告の上記主張は，特許実務からかけ離れた，補正制度を無視したものであ り，失当である。 〔被告の主張〕 (1) 本件補正は，特許法17条の2第1項4号に係る補正であるところ，特許法 は，159条1項において読み替えて53条1項の規定を準用し，159条2項に おいて読み替えて50条ただし書きを準用し，17条の2第1項4号に係る補正（拒 絶査定不服審判請求時の補正）を却下する場合には，拒絶理由を通知することを必 要としていない。 本件審決が新たに公知文献１及び２（甲２，３）を挙げてした判断は，相違点４ についてしたものであり，相違点４に係る本願補正発明の構成は，「マルチメディ 「 アコンテンツ」の中に， 「コーデックサーバの位置情報」と「第１のソフトウェアモ ジュールの識別情報」が含まれる」であり，この構成は拒絶査定不服審判請求時の 補正（本件補正）により新たに追加されたものであって，この追加は特許請求の範 囲の減縮である。そして，本件審決は，この特許請求の範囲の減縮を目的とする本 件補正について，法17条の2第6項において準用する法126条5項の規定に適 合していない，いわゆる独立特許要件に違反するとして，特許法159条1項にお いて読み替えて準用する同法53条1項の規定によって却下したもの，すなわち， 特許法で拒絶理由を通知することを必要としない手続によって本件補正を却下した のであり，原告に拒絶理由を通知せず，意見書の提出機会を付与しなかったことに ついて本件審決に手続違背はない。 (2) 特許法159条2項後段の規定は，補正に関する他の改正項目と同様に，迅 速・的確かつ公平な権利付与等の観点から設けられたものである。すなわち，各国 経済の相互依存の進化に伴い特許制度の国際調和が検討されていたところ，我が国 の特許制度については，補正回数や補正範囲の制限が不十分であるため，権利付与 までの期間が長期化し，また，第三者の監視負担が過大になる等の問題が指摘され ていた。そこで，平成５年法律第２６号では，２回目（最後）の拒絶理由通知以降 の補正に対して，独立特許要件も含めて補正の範囲の適正化を図り，また，拒絶理 由の通知について同法50条ただし書の規定が設けられるとともに，不適法な補正 は却下することとして同法53条1項ないし３項の規定が設けられ，拒絶査定不服 審判についても，迅速な権利付与の実現，出願間の公平な取扱い等の観点から，同 様の改正がされた（同法17条の2，159条）。 原告は，この点について，同法159条2項後段の立法趣旨は，拒絶査定不服審 判請求時にした補正が新規事項を追加するものである場合に，補正却下を適用する ことにあると主張する。しかし，同法159条2項後段の立法趣旨は，審判請求時 の補正が不適法である場合の取扱いを，最後の拒絶理由通知に対する補正が不適法 である場合の取扱いと同様のものとすることによって，審理を迅速化し，第三者の 監視負担を軽減することにある。すなわち，同法159条2項後段の規定は，新規 事項を追加する補正のみを却下することを想定したものではなく，目的外の補正や 独立特許要件違反の補正についても却下することを想定したものである。このよう に，同法159条2項後段の規定は，不適法な審判請求時の補正を却下することに よって審理を迅速化し，第三者の負担を軽減するものであって，新しい技術を公開 した者（出願人）に対して迅速に権利を付与して発明を保護することと，権利の制 約を受ける第三者の利用を促すこととのバランスを図ったものであるから，特許法 の目的にも合致するものであって，憲法31条に反するものではない。 (3) 拒絶査定不服審判は，審査に対する続審である（特許法１５８及び159条） から，審判合議体は，審査においてした手続を土台として審理を続行し，新たな資 料をも補充し，拒絶査定が維持できるかどうかを審理するものであるから，審判請 求人は，審判合議体に対し拒絶査定が不服である理由を述べ，拒絶査定の妥当性に ついて審理を受けることができる。 しかし，審判請求時に特許請求の範囲を拡張，変更する補正がされると，審理対象 が変更されるため新たな審理を行わざるを得なくなり，公平性を欠くことになるのみ ならず，他の審判請求事件の審理の遅延をも生じるおそれがある。また，審判請求時 の補正が特許請求の範囲の減縮に相当する補正であるとしても，補正後の発明が特許 可能なものであれば，拒絶査定を取り消して特許査定すれば良く，審理が繰り返し行 われることを回避することができるが，補正後の発明が特許できないものについて， 仮に，審判において再度，拒絶の理由を通知し，審判請求人に意見書・補正書を提出 する機会を与えたならば，審理が繰り返し行われることを回避できなくなる。また， 仮に，審判請求人がこの機会を活用して出願を分割したならば，分割された出願につ いて最初から審査がやり直されることとなり，しかも，第三者の監視負担が新たに発 生する。さらに，出願前に十分な先行技術調査を行い予め高品質な特許請求の範囲及 び明細書を作成し，多項制を積極的に活用して１回以下の拒絶理由通知で特許性を見 極め，審判請求前に迅速に権利を取得しようとしている他の出願人との公平性の観点 からも問題がある。特許出願人にとっても，十分な先行技術調査，多項制の活用等に 対するインセンティブが損なわる結果，迅速・的確な権利取得の確率が低下する。 そもそも，同法50条には補正却下するときに拒絶理由の通知を要しない旨の規定 はあるが，同法53条には拒絶理由を通知するときに補正却下を要しない旨の規定は ない。万が一，補正却下せず拒絶理由を通知する運用としたならば，審判請求人は不 適法な補正の範囲内で補正する不利益を被り，補正却下しなかったことについて，審 判合議体の処分の違法性を問うことができる。また，仮に，補正却下せず拒絶理由を 通知する運用としたならば，審判請求人は，審判請求時に拒絶理由を内在する不適法 な減縮補正を行っただけで，特許庁に対し最初から審査（審理）をやり直させること ができるようになる。原告が主張する運用は，実質的に，審判請求の段階になってか ら審査を再スタートさせることを強いる運用であり，審理期間の遅延を招き，第三者 の監視負担を増大させるだけである。 以上のとおりであるから，審判請求時の補正が，単に，拒絶査定の理由を解消すべ く特許請求の範囲を減縮した補正であることをもって審判において再度，拒絶の理由 を通知するという運用を採用することは，迅速・的確かつ公平な権利付与を図るとい う前記(2)の平成５年法律第２６号による改正の趣旨に合致しない。 (4) 特許出願人は，自らの判断で，多項制を活用して，特許を受けようとする発 明について特許請求の範囲に請求項毎に記載し，本件のような補正却下を回避する ことができる。本件でいえば，原告は，本件補正により追加された「「マルチメディ アコンテンツ」の中に， 「コーデックサーバの位置情報」と「第１のソフトウェアモ ジュールの識別情報」が含まれる」との構成を含む発明を，出願時にあらかじめ特 許請求の範囲に記載していたならば，平成２２年１月２８日付け拒絶理由通知の段 階で，同構成についても審査を受けることができたし，あるいは同拒絶理由通知に 対する手続補正で特許請求の範囲に記載していたならば，審査官から最後の拒絶理 由通知を受けることができた。したがって，原告が主張する特許出願人にとっての 不利益は，多項制を活用することにより回避可能であるから，特許出願人に何ら責 任がないとはいえない。 また，新たな引用文献を引用した29条2項の規定により独立特許要件を満たさ ないとの理由により補正が却下されることは，制度上予定されていることであるか ら，特許出願人にとって全く想定できないものでもない。 ２ 取消事由２（本願補正発明と引用発明との一致点の認定の誤り，相違点の看 過）について 〔原告の主張〕 (1) 本件審決は，引用発明の「クライアント」と本願補正発明の「装置」とは， 「前記マルチメディアコンテンツに関する前記コーデックサーバの位置情報と前記 コーデックのバイナリデータの識別情報とが用いられ」ること，及び「前記コーデ ックサーバの位置情報と前記コーデックのバイナリデータの識別情報とに基づき，」 外部ネットワークに位置した前記コーデックサーバに前記コーデックのバイナリデ ータのダウンロードを要求するメッセージを生成及び伝送することを一致点として 認定した。 (2) しかし，引用発明において，「前記マルチメディアコンテンツに関する前記 コーデックサーバの位置情報と前記コーデックのバイナリデータの識別情報とを用 い」る主体は，情報サーバであって，クライアントではない。本願補正発明の「装 置」は，引用発明の情報サーバに対応するものではなく，クライアントに対応する ものである。そうすると，本件審決が一致点として認定した「前記マルチメディア コンテンツに関する前記コーデックサーバの位置情報と前記コーデックのバイナリ データの識別情報とが用いられ」は，引用発明の「クライアント」と本願補正発明 の「装置」との一致点とはなり得ないから，本件審決は一致点の認定を誤り相違点 を看過している。 また，引用発明において， 「前記コーデックサーバの位置情報と前記コーデックの バイナリデータの識別情報」を知っているのは，情報サーバであって，クライアン トではない。一方，本願補正発明の「装置」においては， 「前記マルチメディアコン テンツ」に含まれた「前記コーデックサーバの位置情報と前記第１のソフトウェア モジュールの識別情報とに基づき」第１のソフトウェアモジュールのダウンロード ， を要求するのは，「装置」内部の制御部であって，サーバ側ではない。そうすると， 本件審決が一致点として認定した「前記コーデックサーバの位置情報と前記コーデ ックのバイナリデータの識別情報とに基づき」は，引用発明の「クライアント」と 本願補正発明の「装置」との一致点とはなり得ないから，本件審決は一致点の認定 を誤り相違点を看過している。 (3) 以上のとおり，本件審決は，前記相違点を看過することにより，誤って本願 補正発明の進歩性を否定したものであるから，取り消されるべきである。 〔被告の主張〕 (1) 本件審決が一致点として認定した「コーデックサーバの位置情報」及び「コ ーデックのバイナリデータの識別情報」は，それぞれ引用発明における「デコーダ ＵＲＩ」及び「対応する最適なデコーダ情報」であり，引用例において， 「デコーダ ＵＲＩ」 （「コーデックサーバの位置情報」 と， ） 「対応する最適なデコーダ情報」 （「コ ーデックのバイナリデータの識別情報」）とは，クライアントが外部（情報サーバ） から取得して，クライアントにおいてダウンロードに用いられる。他方，本願補正 発明の装置は，マルチメディアコンテンツに含まれる「コーデックサーバの位置情 報」と「第１のソフトウェアモジュールの識別情報」とをマルチメディアコンテン ツとともに取得しダウンロードに用いる。 そうすると，これら情報をダウンロードに用いているという観点で，本件審決が， 「前記マルチメディアコンテンツに関する前記コーデックサーバの位置情報と前記 コーデックのバイナリデータの識別情報とが用いられ」ていることを，引用発明の 「クライアント」と本願補正発明の「装置」との一致点としたことに誤りはない。 (2) 原告は，引用発明において，「前記コーデックサーバの位置情報と前記コー デックのバイナリデータの識別情報」を知っているのは，情報サーバであって，ク ライアントではないと主張するが，上記のとおり，引用例では，情報サーバが知っ ている情報をクライアントが得て用いるのであり，クライアントが情報を得る情報 源が情報サーバであるとしても，クライアントにおいて，「前記マルチメディアコ ンテンツに関する前記コーデックサーバの位置情報と前記コーデックのバイナリデ ータの識別情報とが用いられ」ているといえるものである。 ３ 取消事由３（本願補正発明と引用発明との相違点４に係る判断の誤り）につ いて 〔原告の主張〕 (1) 本件審決は，本願補正発明と引用発明との相違点４について，引用発明では， 「コンテンツ」の中に「デコーダＵＲＩ」と「デコーダ情報」が含まれるものとは されておらず，「コンテンツ」とは別に，情報サーバから，「デコーダＵＲＩ」と， 各コンテンツに対応する「デコーダ情報」が提供されるものであるが，コンテンツ とともにデコーダをダウンロードするためのサーバの位置情報を提供することや， コンテンツの中にデコーダを識別するための情報が含まれるようにすることは，公 知文献１及び２に開示されているように既に知られた考え方であるから，引用発明 における「デコーダＵＲＩ」及び「デコーダ情報」に，上記公知技術に係る考え方 を採用することで，本願補正発明のように， 「マルチメディアコンテンツ」に「コー デックサーバの位置情報」と「コーデックの識別情報」を含むように構成すること は，当業者であれば容易に想到できる旨判断した。 (2) しかし，公知文献１（甲２）には，デコーダ全体ではなく，そのうちの一部 に相当する第１のソフトウェアモジュールのみをダウンロードするためのコーデッ クサーバの位置情報がディスクに含まれているという記載はない。公知文献１記載 の技術を引用発明に組み合わせて本願補正発明の進歩性を否定するためには，公知 文献１において，単にデコーダが存在するウェブサイトのＵＲＬでは足りず，デコ ーダ全体のうちの一部に相当する第１のソフトウェアモジュールのみをダウンロー ドするためのコーデックサーバの位置情報がディスクに含まれている必要がある。 したがって，仮に公知文献１記載の技術を引用発明に適用できたとしても，本願 補正発明には至らない。 (3) 公知文献２（甲３）においても同様に，仮にデコーダを識別するための情報 がコンテンツに含まれているという技術が公知文献２に記載されていたとしても， デコーダ全体ではなく，そのうちの一部に相当する第１のソフトウェアモジュール のみの識別情報がコンテンツに含まれているという記載はない。公知文献２記載の 技術を引用発明に組み合わせて本願補正発明の進歩性を否定するためには，公知文 献２において，単にデコーダの識別情報では足りず，デコーダ全体のうちの一部に 相当する第１のソフトウェアモジュールの識別情報がコンテンツに含まれている必 要がある。 したがって，仮に公知文献２記載の技術を引用発明に適用できたとしても，本願 補正発明には至らない。 (4) 本願補正発明の「ソフトウェアモジュール」は，ＯＳ，コーデックライブラ リ，メディアフレームワーク及びハードウェアライブラリを含む（本願明細書の段 落【００２９】。そして，本願補正発明は， ） 「第１と第２のソフトウェアモジュール を組み合わせてＤＳＰコードを生成」することを要件としているから，例えば， 「第 １のソフトウェアモジュール」がメディアフレームワークであり， 「第２のソフトウ ェアモジュール」がハードウェアライブラリである場合も包含する。 他方，引用発明においてダウンロードされる「デコーダモジュール」は，本願明 細書の「コーデック」（コーデックライブラリの一要素）に相当する。 そうすると，本件審決が相違点２として判断した「モジュールのみをダウンロー ドする点」及び「得ようとする各情報が「モジュール」を対象としたものとするこ と」とは，引用発明における「デコーダモジュール」，すなわちコーデックライブラ リについて判断したものにすぎず，コーデックライブラリ以外の本願補正発明の「ソ フトウェアモジュール」であるＯＳ，メディアフレームワーク及びハードウェアラ イブラリについては，何も判断していない。 (5) 本願補正発明では，「前記マルチメディアコンテンツは前記コーデックサー バの位置情報と前記第１のソフトウェアモジュールの識別情報を含み」及び「前記 コーデックサーバの位置情報と前記第１のソフトウェアモジュールの識別情報とに 基づき」の要件を満たしているために，装置側からサーバ側に対して「コーデック サーバの位置情報と第１のソフトウェアモジュールの識別情報」を要求することな く，マルチメディアコンテンツ自体に内在する「コーデックサーバの位置情報と第 １のソフトウェアモジュールの識別情報」をそのまま利用すれば足りる。 これに対して，引用発明においては， 「クライアントが対応するデコーダを有して いない場合には，スケジューラー管理エンジンは，デコーダＵＲＩを得ることをデ コーダ・コンポーネント管理エンジンに指示する。デコーダ・コンポーネント管理 エンジンは，どこにデコーダが格納されているかをコンテンツサーバに要求する」 のであって，本願補正発明には，このような要求を必要としないという効果がある。 〔被告の主張〕 (1) 本件審決は，相違点４に係る本願補正発明の構成として 「「マルチメディア コンテンツ」の中に， 「コーデックサーバの位置情報」と「第１のソフトウェアモジ ュールの識別情報」が含まれる」としているところ，モジュールのみをダウンロー ドする点については，相違点２として判断し，相違点４は，そのような相違の下で， 本願補正発明が「「マルチメディアコンテンツ」の中に，「コーデックサーバの位置 情報」と「第１のソフトウェアモジュールの識別情報」が含まれる」ことを相違点 として挙げたのであって，ダウンロードに用いる情報を取得する手法について判断 したもの，すなわち，公知文献１及び２は，ダウンロードに際して必要となる， 「ど こから」 「何を」の各情報を取得する手段として，各情報をコンテンツに含ませてコ ンテンツとともに得る構成を容易というために用いている。 すなわち，得ようとする各情報が「モジュール」を対象としたものとすることは， 相違点２で判断した上で，さらに，相違点４について，公知文献１及び２の「コン テンツとともに，デコーダをダウンロードするためのサーバの位置情報を提供する こと」及び「コンテンツの中にデコーダを識別するための情報が含まれるようにす ること」という公知技術を組み合わせることで，本願補正発明の「「マルチメディア コンテンツ」の中に， 「コーデックサーバの位置情報」と「第１のソフトウェアモジ ュールの識別情報」が含まれる」とすることは容易であると判断したものである。 (2) 本願補正発明は，マルチメデイアコンテンツの符号化の仕組みが異なる場合， それを復号するために必要な復号プログラムを得るために，復号プログラム全体（全 体プログラム）をダウンロードするのではなく， 「全体プログラム」を構成する各プ ログラム（部分プログラム）の中で異なる符号化の仕組みに必要な「部分プログラ ム」のみをダウンロードするというものである。 本件審決は，「全体プログラム」をダウンロードするのではなく，「部分プログラ ム」をダウンロードすることについては，相違点２において，本願補正発明の「ソ フトウェアモジュール」，すなわち，部分プログラムとして「第１のソフトウェアモ ジュール」をダウンロードする点について判断しているのであるから，本件審決が 「本願補正発明の「ソフトウェアモジュール」については何も判断していないとす る原告の主張は理由がない。 (3) 原告は，本願補正発明は，各情報がコンテンツに含まれ，コンテンツととも に得ることができるから，引用発明のようにクライアントからサーバにコンテンツ とは別に各情報を要求する必要がないとの効果がある旨主張するが，相違点につい てした判断の結果として容易に想到される構成から予測されるものであり，この効 果により特許を受けることができるとはいえない。 ４ 取消事由４（本願補正発明と引用発明との相違点１及び２に係る判断の誤り） について 〔原告の主張〕 (1) 本件審決は，本願補正発明と引用発明との相違点１について，引用発明にお ける「コアエンジン」について，引用例における記載に基づいて，ＤＳＰによるハ ードウェアを採用することによって，本願補正発明のように， 「デジタルシグナルプ ロセッサ（ＤＳＰ）処理部」とすることや，引用発明における実行コードを，本願 補正発明のように， 「ＤＳＰコード」とすることは，当業者であれば容易に想到でき る旨判断した。 また，本件審決は，本願補正発明と引用発明との相違点２について，引用発明に おいて，「デコーダ情報」に基づき，「デコーダのバイナリデータ」をダウンロード して記憶し， 「デコーダ」に対応するメディア又はコンテンツが再生される構成につ いて，引用例に開示されるような，デコーダが複数のモジュールにより構築される モジュールベースデコーダの考え方を採用し，モジュールに対応するメディアコン テンツやモジュール識別情報の構成，複数のデコーダモジュールを組み合わせてデ コーダを生成する手段を設けることによって，本願補正発明のように， 「ソフトウェ アモジュールの識別情報」に基づきダウンロードして記憶し，記憶された複数の「ソ フトウェアモジュール」を組み合わせてコーデックのコードを生成し， 「ソフトウェ アモジュール」に対応するマルチメディアコンテンツを処理するようにすることは， 当業者であれば容易に想到できる旨判断した。 (2) しかし，引用発明では“core engine”にデコーダを設置しており，“core engine”はメディア再生又は中止などを制御するＣＰＵに該当するから，引用発明 のデコーダダウンロード及び設置に関するソフトウェアはＣＰＵ上で動作するソフ トウェアであって本願補正発明のＤＳＰコードとは異なる。引用発明には，コンポ ーネント化されているソフトウェアによりデコーダを形成する一部モジュールに対 する変更を行う構成が開示されているかもしれないが，ＯＳなどの実行環境が劣悪 であるというＤＳＰの特性上コンポーネント化されていないソフトウェアを備える しかないＤＳＰに対し，新規コーデックが要求される際にコーデックを変更するた めに最小限の資源を用いてＤＳＰ規格に合うＤＳＰコードを容易に提供することに ついては，引用例にはいかなる開示も示唆もない。 これに対して，本願補正発明は，コンポーネント化されたソフトウェアの使用が 容易ではないＤＳＰによりコーデックを支援する回路環境で新規コーデックが要求 されるたびに大容量のＤＳＰコードを適用及び交替することにより発生する相当量 のオーバーヘッドを最小化するため，コンテンツを再生するたびにリアルタイムで ＣＰＵ(ＤＳＰコード生成部)で適切なコーデックライブラリを選択するようにした 後，選択されたコーデックライブラリとＯＳ及びメディアフレームワークを組み合 わせてＤＳＰコードを生成し，生成されたＤＳＰコードをＤＳＰ処理部に提供し， ＤＳＰ処理部では提供されたＤＳＰコードに基づいてコンテンツを再生するための デコーディングを行うことにより，ＤＳＰはコンテンツを再生するたびにＣＰＵか らＤＳＰコードを提供される構成としたものであり，かかる構成，効果を検討せず に相違点１及び２について容易想到であると判断した本件審決は誤りである。 (3) 被告の主張(1)に対して 引用例には，いくつかのＩＤＣＴモジュールの中でＤＳＰという「ハードウェア 仕様…に適したＩＤＣＴモジュールを選択」することができると記載されているの であって，ＤＳＰで複数のＩＤＣＴモジュールを用いることができ，ＩＤＣＴの変 更を実施できる旨の記載はない。 また，引用例に，一体化したソフトウェアの課題認識があったとしても，それは システム全体としての課題認識であり，ＤＳＰにおける課題認識が示唆されている ものではない。 さらに，本願補正発明では，コーデックライブラリだけでなく，ＯＳ，メディア フレームワーク及びハードウェアライブラリのソフトウェアを組み合わせて新たな 「ＤＳＰコード」を生成しているのに対し，引用発明の「デコーダ・コンポーネン ト管理エンジン」は「コアエンジン」に対して「デコーダモジュール」のみを供給 しているところ，この「デコーダモジュール」は，本願明細書の「コーデック」に 相当するものであり，新たなＤＳＰコードを生成する機能は有していない。 (2) 被告の主張(2)に対して 引用例には，ハードウェア仕様に適したデコーダを選択することは記載されてい ても，同一のハードウェア仕様について複数のデコーダを選択的にダウンロードし て用いることは記載されていない。 さらに，本願補正発明は，ＤＳＰに最適のＤＳＰコードを提供するため，ＣＰＵ 及びＤＳＰ間の連動構造を備えているのに対し，引用発明は，コアエンジンとして ＤＳＰを採用する構成上の違いがある。 〔被告の主張〕 (1) 本件審決は，引用例記載のコンポーネント化されているソフトウェアにより デコーダを形成する一部モジュールに対する変更を行う構成を，引用発明に採用す ることが容易であることについて相違点２において判断し，ＤＳＰに対するものと することを相違点１において判断している。 引用例には，一体化したソフトウエアについての課題認識がある上，クライアン トのハードウェア仕様をＤＳＰとし，ＤＳＰに適しているＩＤＣＴモジュールを選 択する構成が例示されているのであって，ＤＳＰにおける課題認識も示唆されてい るというべきであるから，当業者が引用発明のハードウェア仕様をＤＳＰとして具 体化するに際し，ＤＳＰに適したモジュールを選択・組み合わせてＤＳＰコードを 生成しＤＳＰに提供する構成を採用することは容易である。 また，ＤＳＰとしたとき，一体化したソフトウエアの課題がＤＳＰにおいても解 決されることは当然に予想されることであり，引用発明から容易に想到する構成に おいて，本願補正発明が奏するＤＳＰにおける効果は予測されるものである。 (2) 原告の主張(3)に対して 引用例の「例えば，同じビットストリーム解析を共有するために，クライアント のハードウェア仕様（ＭＭＸ，３ＤＮｏｗ！，ＤＳＰ，ＡＳＩＣなど）に適してい るＩＤＣＴモジュールを選択することができる。」との記載中，「ＩＤＣＴモジュー ル」とは，映像符号化において用いられる離散コサイン変換「ＤＣＴ」を，復号に おいて元に戻す逆ＤＣＴ変換を行うプログラムを指し，変換にＤＣＴを用いたコー デックの場合を例にして説明したものである。そして，上記記載それ自体は，ＤＳ Ｐに対してＤＳＰ用のＩＤＣＴモジュールを選択することを述べたものであるが， 同時に，引用例記載のフレキシブルデコーダにおいて，デコーダがインストールさ れるパーツである「コアエンジン」としてＤＳＰを採用することを示唆する記載で もあり，この記載を相違点１の判断根拠とした本件審決に誤りはない。 第４ 当裁判所の判断 １ 本願補正発明について (1) 本願補正発明の特許請求の範囲は，前記第２の２(2)記載のとおりであると ころ，本願明細書（甲７）には，おおむね次の内容の記載がある。 ア 技術分野 本発明は，ソフトウェアモジュールの組合せによってＤＳＰコードを生成する装置及びその 方法に係り，より詳細には，ＤＳＰコードのソフトウェアモジュールのうち必要なモジュール のみを伝送されて，各々のソフトウェアモジュールを組み合わせて所定のＤＳＰコードを生成 する装置及びその方法に関する（【０００１】 。 ） イ 背景技術 (ア) 現在，放送，通信，及びインターネットの環境で多様なコーデックが発展しており， また，コーデックの圧縮率が高くなって，拡張性が上がることによってコンテンツ提供者及び ネットワーク事業者は多様なコーデックを使おうとする（【０００２】 。 ） これによって，ＤＴＶ，セットトップボックス（ＳＴＢ）などのレンダリング機器で多様な メディアフォーマットを適用しようとＤＳＰ（Digital Signal Processing）を用いてメディア デコーダを具現しようとする試みがあり，ＤＳＰで実行されるソフトウェアを異ならせて，さ まざまのコーデックを適用できる（【０００３】。 ） 一般的に，ＤＳＰは，高速性能を具現するようにパイプライン演算器を中心に構成する場合 が多い。特に，ＤＳＰは，リアルタイム処理が要求される分野で多く使われるので，ハードウ ェア能力の限界まで性能を具現するようにソフトウェア作業を頻繁にしなければならない 【０ （ ００４】。 ） (イ) 図１Ａは，従来のＤＳＰ基盤のレンダリング機器の典型的な形態を示す図面である。示され たように，レンダリング機器は，ホストＣＰＵ１０，ＤＳＰ２０，及び記憶部（図１Ａでは「貯 蔵部」，以下同じ。）例えば，ＲＯＭ，及びＲＡＭ）３０として構成される（【０００９】。 ） まず，ＤＳＰブーティングの時，ＤＳＰ２０が記憶部（例えば，ＲＯＭ）３０からＤＳＰコ ードを読み取って実行させ得る。しかし，ホストＣＰＵ１０がＤＳＰ２０に実行コードをロー ディングした後，ＤＳＰをブーティングさせることもできる（【００１０】。 ） 次いで，ＤＳＰ基盤のデコーディングデバイスは，コーデック別にＤＳＰコードが異なるの で（すなわち，コーデックによって実行されるＤＳＰが異なるので），ホストＣＰＵ１０が現在 のコーデックに適合したＤＳＰコードをＤＳＰ２０にダウンロードさせる（【００１１】。 ） 一方，ホストＣＰＵ１０なしにＤＳＰ２０のみで構成されても良く，この場合，ブーティン グの時，ＤＳＰ２０が記憶部（例えば，ＲＯＭ）３０からＤＳＰコードを読み取って実行する （【００１２】。 ） (ウ) 図１Ｂは，従来のＤＳＰコーデックの伝送及びダウンロードを実行する過程を示す図面であ る。示されたように，ホストＣＰＵ１０のＲＯＭ３０には，多様なＤＳＰコードが存在できる （例えば， ２６４コーデック用ＤＳＰコード， Ｈ． ＭＰＥＧ２コーデック用ＤＳＰコードなど）。 ここで，ＲＯＭ３０に記憶されたＤＳＰコードはブーティングの時，ＤＳＰ２０にロードされ る（【００１３】。 ） 一方，必要なＤＳＰコーデックがシステム内部のＲＯＭ３０に存在しない場合，該当ＤＳＰ コードをネットワークを通じてコーデックサーバでダウンロードしてＲＯＭ３０に記憶してお いて，必要の時ごとに使うようにする（【００１４】。 ） しかし，ＤＳＰコードは，一般的なＰＣ用プログラムより動作環境が劣悪な問題点がある。 すなわち，ＰＣのように汎用のＯＳがあって，アプリケーションプログラムが前記ＯＳ上で動 作する構造ではなく，ＤＳＰ２０に合うように具現されたコーデック用ソフトウェア全体（例 えば，ＯＳ，コーデックライブラリ，メディアフレームワーク，及びハードウェアライブラリ など）が一つのＤＳＰコードを形成しており，コーデックが変わるたびにこのＤＳＰコード全 体が再びＤＳＰ２０にローディングされなければならないという問題点がある（【００１５】 。 ） したがって，ネットワークを通じて遠隔サーバでダウンロードされるＤＳＰコードでコーデ ックライブラリのみが変更されて，ＯＳ，メディアフレームワーク，及びハードウェアライブ ラリなどは，ＲＯＭ３０に記憶された他のＤＳＰコードと共通に所有する部分に，不要なソフ トウェアモジュールが含まれて伝送されるので，ＤＳＰコードのダウンロードの時，ネットワ ークにオーバーヘッドが発生し，また，ＲＯＭの記憶空間を多く占めるという問題点がある 【０ （ ０１６】。 ） ウ 発明が解決しようとする課題 本発明は，外部ネットワークに位置したコーデックサーバからＤＳＰコードのソフトウェア モジュールのうち必要なモジュール（例えば，コーデックライブラリ）のみを伝送された後， 各々のソフトウェアモジュールを組み合わせて所定のＤＳＰコードを生成するところにその目 的がある。 本発明は，前述した目的に制限されず，言及されなかったさらなる目的は，下記の記載から 当業者に明確に理解されるであろう（【００１８】。 ） エ 発明の効果 本発明のソフトウェアモジュールの組合せによってＤＳＰコードを生成する装置及びその方 法によれば，次のような効果が一つあるいはそれ以上ある（【００２１】。 ） 外部ネットワークに位置したコーデックサーバからＤＳＰコードのソフトウェアモジュール のうち必要なモジュール（例えば，コーデックライブラリ）のみを伝送された後，各々のソフ トウェアモジュールを組み合わせて該当ＤＳＰコードを生成することによって，必要なソフト ウェアモジュールのみをダウンロードされるので，ソフトウェアをダウンロードされる時間を 減らし得る長所がある（【００２２】。 ） また，必要なソフトウェアモジュール（例えば，コーデックライブラリ）のみを伝送された 後，記憶することによって，記憶空間の無駄使いを減らすことができ，より効率的に記憶空間 を活用できる長所がある。また，ＤＳＰで駆動されるソフトウェアモジュールをより効果的に 管理できる長所がある（【００２３】。 ） オ 発明を実施するための最良の形態 (ア) 【図２】 図２は，本発明の一実施形態によるソフトウェアモジュールの組合せによってＤＳＰコード を生成する装置の内部ブロック図を示す図面である。ここで，マルチメディア再生装置１００ は，放送コンテンツ及び一般動映像コンテンツを再生するもので，例えば，ＤＴＶ，セットト ップボックス，及び移動通信端末機などを言う（【００２６】。 ） 示されたように，マルチメディア再生装置１００は，受信部１１０，送信部１２０，記憶部 （図２では「貯蔵部」，以下同じ。）１３０，ＤＳＰコード生成部１４０，ＤＳＰ処理部１５０， 及び制御部１６０を含んで構成される（【００２７】。 ） 受信部１１０は，外部ネットワークに位置したコーデックサーバから伝送されたソフトウェ アモジュールを受信する。ここで，ソフトウェアモジュールは，ＯＳ，コーデックライブラリ， メディアフレームワーク，及びハードウェアライブラリを含む。ここで，ＯＳ，コーデックラ イブラリ，メディアフレームワーク，及びハードウェアライブラリに構成されたコードをＤＳ Ｐコードと言う。また，コーデックの種類は，ＭＰＥＧ−２，ＭＰＥＧ−４，Ｈ．２６４，及 びＶＣ１などに理解され得る。すなわち，受信されるコーデックライブラリは，例えば，ＭＰ ＥＧ−２ライブラリ，Ｈ．２６４ライブラリである（【００２９】。 ） 送信部１２０は，外部ネットワークに位置したコーデックサーバに所定のコーデックライブ ラリのダウンロードを要求するコーデック要求メッセージを伝送する（【００３０】。 ） 記憶部１３０は，所定マルチメディアコンテンツの動作実行のための少なくとも一つ以上の ソフトウェアモジュールを記憶するが，ここで，記憶部１３０は，ＨＤＤ，フラッシュロム（Ｒ ＯＭ）などを言う（【００３１】 。 ） ＤＳＰコード生成部１４０は，所定のマルチメディアコンテンツを実行させるためのＤＳＰ コードを生成するもので，すなわち，記憶部１３０に記憶された各々のソフトウェアモジュー ルを組み合わせて一つのＤＳＰコードを生成する（【００３２】。 ） 例えば，ＭＰＥＧ−２を支援するＤＳＰコードが必要な場合，ＭＰＥＧ−２ライブラリとＯ Ｓ，メディアフレームワーク，及びハードウェアライブラリとを組み合わせて最終ＤＳＰコー ドを生成する。したがって，生成されたＤＳＰコードは，ＭＰＥＧ−２コーデック用ＤＳＰコ ードになる（【００３３】。 ） ＤＳＰ処理部１５０は，ＤＳＰコード生成部１４０が生成したＤＳＰコードを処理するもの で，例えば，ＤＳＰコードをデコーディングして該当ＤＳＰコードを実行させ，所定マルチメ ディアコンテンツを実行させる（【００３４】 。 ） 制御部１６０は，マルチメディア再生装置１００内に所定のマルチメディアコンテンツを実 行させるためのコーデックライブラリが存在しない場合，コーデック要求メッセージを作成し て外部ネットワークに位置したコーデックサーバに伝送する（【００３５】。 ） また，制御部１６０は，マルチメディアコンテンツ提供者から伝送されたデータパケットを 通じてマルチメディア再生装置１００で実行させる所定マルチメディアコンテンツについての コーデック情報が分かり，これによりユーザーの所定マルチメディアコンテンツ再生要求の時， 該当マルチメディアコンテンツを再生させるＤＳＰコードをＤＳＰコード生成部１４０に要求 する。以下の(ウ)の図４でデータパケットについては説明する（【００３６】。 ） また，制御部１６０は，マルチメディア再生装置１００を構成する各機能性ブロック１１０ ないし１５０の動作を制御する（【００３７】 。 ） (イ) 【図３】 図３は，本発明の他の実施形態によるソフトウェアモジュールの組合せによってＤＳＰコー ドを生成する装置の動作を概略的に示す図面である。示されたように，記憶部（図３では「貯 蔵部」，以下同じ。）１３０には，各々のソフトウェアモジュール（例えば，ＯＳ，コーデック ライブラリ，メディアフレームワーク，及びハードウェアライブラリ）が記憶されている（【０ ０３８】。 ） ユーザーが所定マルチメディアコンテンツの再生を要求することによって，制御部１６０が 所定マルチメディアコンテンツの実行に必要なＤＳＰコードを要求して，これによりＤＳＰコ ード生成部１４０は，記憶部１３０に記憶されたソフトウェアモジュールを組み合わせて一つ のＤＳＰコードを生成する（【００３９】。 ） 例えば，所定マルチメディアコンテンツを実行するためにＭＰＥＧ−２コーデック（例えば， コーデックライブラリ１）が必要な場合，ＤＳＰコード生成部１４０は，記憶部１３０に記憶 されたソフトウェアモジュールのうちＯＳ，コーデックライブラリ１，メディアフレームワー ク，及びハードウェアライブラリを組み合わせてＭＰＥＧ−２コーデック用ＤＳＰコードを生 成する（【００４０】 。 ） 次いで，ＤＳＰコーデック生成部１４０は，生成されたＭＰＥＧ−２コーデック用ＤＳＰコ ードをＤＳＰ処理部１５０にローディングして，ＤＳＰ処理部１５０は，ローディングされた ＭＰＥＧ−２コーデック用ＤＳＰコードをデコーディングして，該当マルチメディアコンテン ツを実行させる（【００４１】。 ） 一方，マルチメディアコンテンツを実行するためにＭＰＥＧ−２コーデックが記憶部１３０ に記憶されていない場合，制御部１６０は，該当コーデックライブラリ（例えば，ＭＰＥＧ− ２ライブラリ）を要求するコーデック要求メッセージを作成して外部ネットワークに位置した コーデックサーバに伝送する（【００４２】。 ） 以後，コーデックサーバから該当コーデックライブラリ（例えば，コーデックライブラリ４） が伝送されれば，制御部１６０は，該当コーデックライブラリ（例えば，コーデックライブラ リ４）を記憶部１３０に記憶して，ＤＳＰコーデック生成部１４０は，新しくダウンロードさ れたコーデックライブラリを用いて該当ＤＳＰコードを生成する（【００４３】。 ） (ウ) 【図４】 図４は，本発明のまた他の実施形態によるソフトウェアモジュールの組合せによってＤＳＰ コードを生成する装置から所定マルチメディアコンテンツについてのコーデック情報を提供さ れるデータパケットを示す図面である（【００４４】。 ） 示されたように，マルチメディアコンテンツ提供者から伝送されたデータパケットには，マ ルチメディアコンテンツの題目４１０，マルチメディアコンテンツを再生するのに必要なコー デックの名称及びコーデックについての付加情報（例えば，該当コーデックの圧縮率及びバー ジョン情報など）を含むコーデック情報４２０，及び該当コーデックをダウンロードされるこ とができるコーデックサーバのアドレス４３０を含む（【００４５】。 ） したがって，前記データパケットを通じてマルチメディア再生装置１００で実行されるマル チメディアコンテンツのコーデック情報が分かる。これにより，ユーザーによって所定マルチ メディアコンテンツが選択されれば，該当マルチメディアコンテンツを実行させ得るコーデッ クライブラリに生成されたＤＳＰコードが提供される（【００４６】。 ） (エ) 【図５】 図５は，本発明のさらに他の実施形態によるソフトウェアモジュールの組合せによってＤＳ Ｐコードを生成する方法を示すフローチャートである。ここで，記憶部１３０にソフトウェア モジュール，ＯＳ，メディアフレームワーク，及びハードウェアライブラリは記憶されている と仮定する（【００４７】。 ） まず，ユーザーが所定マルチメディアコンテンツの再生を要求することによって制御部１６ ０は，前記マルチメディアコンテンツの実行に必要なＤＳＰコード（例えば，ＭＰＥＧ−２コ ーデック用ＤＳＰコード）を要求する（Ｓ５１０）。ここで，制御部１６０は，データパケット を通じてユーザーが選択したマルチメディアコンテンツを実行させるコーデック情報が分かる （【００４８】。 ） 次いで，ＤＳＰコード生成部１４０は，制御部１６０が要求したＤＳＰコードを生成するた めに記憶部１３０に該当コーデックライブラリが存在するか否かを判断する（Ｓ５２０）。判断 の結果，記憶部１３０に該当コーデックライブラリ（例えば，ＭＰＥＧ−２ライブラリ）が存 在する場合（Ｓ５３０），ＤＳＰコード生成部１４０は，記憶部１３０に記憶されたコーデック ライブラリ，ＯＳ，メディアフレームワーク，及びハードウェアライブラリを組み合わせて制 御部１６０が要求したＤＳＰコードを生成する（Ｓ５４０）【００４９】。 （ ） 次いで，生成されたＤＳＰコード（例えば，ＭＰＥＧ−２コーデック用ＤＳＰコード）をＤ ＳＰ処理部１５０にローディングして（Ｓ５５０），ＤＳＰ処理部１５０は，ローディングされ たＤＳＰコードをデコーディングして，該当マルチメディアコンテンツが実行されるように処 理する（Ｓ５６０）【００５０】。 （ ） 一方，判断の結果，記憶部１３０に該当コーデックライブラリ（例えば，ＭＰＥＧ−２ライ ブラリ）が存在しない場合（Ｓ５３０） 制御部１６０は， ， 該当コーデックライブラリ（例えば， ＭＰＥＧ−２ライブラリ）を要求するコーデック要求メッセージを作成して，作成されたコー デック要求メッセージを送信部１２０を通じて外部ネットワークに位置したコーデックサーバ に伝送する（Ｓ５７０）【００５１】 。 （ ） 以後，コーデックサーバから該当コーデックライブラリ（例えば，ＭＰＥＧ−２ライブラリ） が伝送されれば，受信部１１０は，伝送されたコーデックライブラリを受信して，受信された コーデックライブラリは，記憶部１３０に記憶される。次いで，ＤＳＰコーデック生成部１４ ０によって該当ＤＳＰコードが生成される（【００５２】。 ） したがって，ＤＳＰコードを構成するソフトウェアモジュールのうち必要なモジュール（例 えば，コーデックライブラリ）のみを伝送されることによって，該当ソフトウェアモジュール のダウンロード時間を減らすことができ，ネットワーク負荷を減らし得る（【００５３】。 ） (2) 前記(1)の記載によれば，本願補正発明の概要は，以下のとおりのものであ ると認められる。 ＤＴＶ等のレンダリング機器では，ＤＳＰを用いてメディアデコーダを具現しよ うとする試みがあり，ＤＳＰで実行されるソフトウェアを異ならせて様々なコーデ ックを適用しているところ，レンダリング機器は，ホストＣＰＵ，ＤＳＰ及び記憶 部で構成され，ＤＳＰが記憶部からＤＳＰコードを読み取って実行させるものであ るが，ＤＳＰ基盤のデコーディングデバイスは，コーデック別にＤＳＰコードが異 なるため，ホストＣＰＵが現在のコーデックに適合したＤＳＰコードをＤＳＰにダ ウンロードする。 ところで，従来，必要なＤＳＰコードがシステム内部の記憶部に存在しない場合， そのＤＳＰコードをネットワークを通じてコーデックサーバからダウンロードし， 記憶部に記憶しておいて，必要なときに使うようにしていたが，ＤＳＰコードは， ＰＣのように汎用のＯＳがあってアプリケーションプログラムがＯＳ上で動作する 構造ではなく，ＤＳＰに合うように具現されたコーデック用ソフトウェア全体（例 えば，ＯＳ，コーデックライブラリ，メディアフレームワーク，ハードウェアライ ブラリ等）が一つのＤＳＰコードを形成しており，コーデックが変わるたびにこの ＤＳＰコード全体が再びＤＳＰにローディングされなければならないという，一般 的なＰＣ用プログラムより動作環境が劣悪な問題点があり，そのため，ネットワー クを通じてダウンロードされるＤＳＰコードのうち，コーデックライブラリのみが 変更され，ＯＳ，メディアフレームワーク，ハードウェアライブラリ等は，記憶部 に記憶された他のＤＳＰコードと共通であるにもかかわらず，不要なＯＳ，メディ アフレームワーク，ハードウェアライブラリ等も含まれて伝送されるので，ＤＳＰ コードのダウンロードを行う際には，ネットワークにオーバーヘッドが発生し，記 憶部の記憶空間を多く占めるという問題点があった。 本願補正発明は，外部ネットワークに位置したコーデックサーバから，ＤＳＰコ ードのソフトウェアモジュールのうち必要なモジュール（例えば，コーデックライ ブラリ）のみを受信し，各々のソフトウェアモジュールを組み合わせて，所定のＤ ＳＰコードを生成することを目的として，本件補正後の特許請求の範囲請求項１の とおり，デジタルシグナルプロセッサ（ＤＳＰ）処理部と，コーデックサーバから 第１のソフトウェアモジュールをダウンロードする手段と，ダウンロードされた第 １のソフトウェアモジュールと，少なくとも第２のソフトウェアモジュールとを記 憶する記憶部と，前記記憶された第１と第２のソフトウェアモジュールを組み合わ せてＤＳＰコードを生成し，前記ＤＳＰ処理部にロードするＤＳＰコード生成部と， を有し，前記ＤＳＰ処理部は前記ロードされたＤＳＰコードをデコーディングして， 前記第１のソフトウェアモジュールに対応するマルチメディアコンテンツを処理し， 前記マルチメディアコンテンツは前記コーデックサーバの位置情報と前記第１のソ フトウェアモジュールの識別情報とを含み，前記マルチメディアコンテンツに対応 する前記第１のソフトウェアモジュールが前記記憶部に記憶されていない場合，前 記コーデックサーバの位置情報と前記第１のソフトウェアモジュールの識別情報と に基づき，外部ネットワークに位置した前記コーデックサーバに前記第１のソフト ウェアモジュールのダウンロードを要求するメッセージを生成及び伝送する制御部 をさらに有することを特徴とする装置である。 ２ 引用例について (1) 引用例（甲１）には，おおむね，次の内容の記載がある。 「コンテンツ指向符号化のための新しいデコーダ・ダウンロード可能システム」 ア 要約 (ア) この論文では，デコーダ・ダウンロード可能システムと呼ぶ新しいシステムアーキテ クチャを説明する。このシステムの目的は，コンテンツの特徴を用いた画像圧縮に基づくマル チメディア世界のための統一プラットフォームを提供することである。このシステムにより， 途切れなく遅延が最小となる再生のための，サーバとクライアント間のネゴシエーションによ りデコーダの動的ダウンロードが可能となる。このネゴシエーション方式はＪａｖａとＣＯＲ ＢＡ（Common Object Request Broker）により実装される。よって，このシステムのサーバと クライアントはＯＳとハードウェア仕様とは独立である。このシステムは，インターネットス トリーミングのみならずテレビ放送にも適している。 (イ) 我々は，システムをより柔軟にするため，デコーダアーキテクチャを改善する。デコ ーダは，ビットストリーム解析，画像圧縮アルゴリズム（ＤＣＴ，ウェーブレット，動き推定 など）などの複数の機能を有する。しかし，従来のデコーダは一体のソフトウェアである。そ のため，デコーダのパーツを共有することができない。提案する方法により，モジュールベー スのデコーダと，複数のデコーダ間でモジュールを共有することが可能となる。結果として， フレキシブルデコーダにより，デコーダの冗長なパーツのダウンロードを回避することにより， ダウンロード時間を短くできる。また，スケーラビリティも実現され，このシステムをマルチ メディアプレーヤのみならずマルチメディアコンテンツ検索システムなどのマルチメディアア プリケーションで用いることができる。 イ イントロダクション (ア) ＭＰＥＧやＪＰＥＧなどの離散余弦変換（ＤＣＴ）ベースの符号化が画像圧縮に広く 使われている。しかし，ＤＣＴベースのアプローチは，全種類の画像に適しているというわけ ではない。ある種の画像は，画像コンテンツの特徴を考慮した方法により，効率的に符号化で きる。これを「コンテンツ指向符号化方式」と呼ぶ。その例として，アニメーション画像符号 化を研究している。この研究から，アニメーション画像デコーダをインターネットストリーミ ングとＴＶ放送で配信できるオープンシステムアーキテクチャが望まれる。しかし，要求を満 たすオープンシステムはまだ報告されていない。そこで， 「デコーダ・ダウンロード可能システ ム」と呼ぶシステムを実装する。この論文において，システムアーキテクチャを提示する。 (イ) コンテンツ指向符号化方式に基づくマルチメディアの世界では，画像圧縮アルゴリズ ムの数は増加すると見込まれる。従来のデコーダはモノリシックのソフトウェアとして開発さ れている。しかし，複数のデコーダが共有できるパーツがある。よって，モジュールベースの デコーダを実現することにより，これらの冗長性をなくすことができる。モジュールベースの デコーダはモジュールにより構成され，複数のデコーダ間でモジュールを共有するものである。 こうしたモジュールベースのデコーダを「フレキシブルデコーダ」と呼ぶ。このシステム中の デコーダはフレキシブルデコーダとして設計されているため，複数の利点を提供できる。 …（略）… ウ デコーダ・ダウンロード可能システム (ア) プラグインシステムの問題 Microsoft Media Player や RealPlayer などのインターネット上のマルチメディアシステム は，必要な時に適切なソフトウェアをインストールすることにより，新しいタイプのメディア を処理する機能を提供する。任意的にダウンロードされるこうしたソフトウェアはプラグイン と呼ばれる。しかし，プラグインシステムには次の問題がある。 新しいコンテンツが始まっても，クライアントが適したデコーダを有していない時に時間遅 延が生じる。デコーダをダウンロードするのに，追加的に時間がかかるからである。これによ り，コンテンツの途切れのない再生が中断され，特にテレビ放送の場合には大きな問題となる。 …（略）… (イ) 提案するシステムアーキテクチャ このセクションでは，デコーダを動的にダウンロードし，遅延なしに再生できるシステムア ーキテクチャを提案する。 ａ 提案するシステムアーキテクチャを図２に示す。 クライアントは５つのパーツにより構成される。５つのパーツとは， 「コアエンジン」「スケ ， ジュール管理エンジン」 「デコーダコンポーネント管理エンジン」 「ファイルＩ／Ｏ」「ユー ， ， ， ザインタフェース」である。パーツ間の各インタフェースは図２において○数字で示した。 【図２】 サーバ側には，コンテンツの実際のビットストリームを格納する「コンテンツサーバ」，デコ ーダのバイナリコードを格納する「デコーダサーバ」，及び各コンテンツのプロフィールを記述 した情報（以下，コンテンツ情報と呼ぶ）を格納する「情報サーバ」がある。対応するコンテ ンツ情報を情報サーバにより容易に読み出すため，この情報は階層構造を有する。図３にコン テンツ情報を示す。各サーバは同じマシン上にあっても，ロードバランシングができるように 異なるマシン上にあってもよい。（判決注：図３には，「情報サーバ」が格納する各コンテンツ のプロフィールを記述した情報（コンテンツ情報；content information）について，コンテン ツ名（content name） 作者 ， （author） コンテンツＩＤ ， （content ID）及び最適なデコーダ（optimum decoder）等の情報から構成されることが記載されている。） 【図３】 クライアントシステムはＪａｖａを用いて実装する。メディア処理の部分はＪＭＦ（Java Media Framework）を用いて開発されている。こうしたのは，提案するシステムが様々な環境で 動作しなければならないからである。現時点は，Ｊａｖａを用いてメディア処理の部分を構成 することには多少の疑問がある。そのため，ＪＭＦに依存するメディア処理をするモジュール は他の部分から完全に取り外せるように，システムアーキテクチャを設計した。しかし，Ｊａ ｖａにより開発したデコーダは，サーバがクライアントのオペレーティングシステムの種類を 心配しなくて良いとのメリットが得られる。これらのデコーダはフレキシブルデコーダとして も有用である。 ＣＯＲＢＡ（Common Object Request Broker）は，サーバとクライアントとの間の，ハード ウェアの仕様とは独立であるインタフェースの規定に用いられる。さらに，このシステムは， ＣＯＲＢＡ ＧＩＯＰ（General Inter-ORB Protocol）により，どのトランスポートプロトコ ルからも独立している。それゆえ，このシステムは，インターネット，テレビ放送，モバイル システムなどで利用できる。 ｂ このシステムのプロシージャは次の順序で実行される： (a) クライアントシステムのスケジューラ管理エンジンがスタートし，コンテンツ情報を取 得する。このエンジンがコンテンツ情報を解析し，デコーダコンポーネント管理エンジンに， クライアント側にデコーダがあるかどうか確認する。 (b) クライアントが対応するデコーダを有していない場合，スケジューラ管理エンジンはデ コーダコンポーネント管理エンジンにデコーダＵＲＩを取得するように命令する。デコーダコ ンポーネント管理エンジンは，コンテンツサーバに，デコーダがどこに記憶されているか要求 する。 (c) 情報サーバは，デコーダ情報を用いて，要求されたデコーダがどこに記憶されているか 探し始める。クライアントにデコーダＵＲＩを返す。 (d) スケジューラ管理エンジンは，デコーダサーバからのデコーダのダウンロードを何時開 始するか決定し，デコーダコンポーネント管理エンジンに命令する。この命令をするタイミン グは非常に重要である。何故なら，ネットワークの帯域幅が狭い場合などに，デコーダのダウ ンロードにより連続的なメディア再生が中断されるからである。 ｃ システム中の各パーツの役割は次のとおりである： ・コアエンジン このパーツは，メディア再生やトリックモードなどの実装を提供する。デコーダは実際には このパーツにインストールされる。 ・デコーダコンポーネント管理エンジン このパーツは，クライアントシステム中のデコーダを管理し，どのデコーダが必要か問い合 わせ，デコーダをダウンロードし，ストックされているデコーダを削除する。 ・スケジュール管理エンジン このパーツは，メディア再生を何時開始するか，デコーダを何時ダウンロードするか，又は デコーダを何時削除するか制御する。実際の機能を提供する各パーツに，タイムリーに命令す る。 ・ユーザインタフェース このパーツはユーザ入力のインタフェースである。 ・ファイルＩ／Ｏ このパーツは，その使用目的に基づきプロトコルを選択する：１）ＣＯＲＢＡ，コンテンツ 情報の送受信，２）ＨＴＴＰ／ＦＴＰ，デコーダのバイナリデータのダウンロード，３）ＲＴ Ｐ／ＭＰＥＧ２−ＴＳ，メディアデータの受信。 ｄ システム中の各インタフェースを以下に説明する： インタフェース１：デコーダに関する情報の交換 インタフェース２：コンテンツに関する情報の交換 インタフェース３：デコーダのバイナリデータのダウンロード インタフェース４：コンテンツのメディアデータのダウンロード インタフェース５：クライアントのスケジューラで用いられるＥＰＧ（電子番組案内）のダ ウンロード インタフェース６：コアエンジンへのデコーダモジュールの供給 インタフェース７：デコーダのメモリへのロードが何時始まるか示し，メモリロードがどの 状態にあるかに関する情報を提供 インタフェース８：デコーダが追加されるのか削除されるのかをユーザに示す インタフェース９：コンテンツに関する情報を提供し，クライアントシステムにおいてデコ ーダのダウンロード及び削除を何時開始するか示し，デコーダの存在を 確認 インタフェース１０：ユーザによる入力情報の受け取り インタフェース１１：再生可能なコンテンツの情報の表示，ユーザによるコンテンツの選択 …（略）… エ フレキシブルデコーダ (ア) 機能 フレキシブルデコーダにより，モノリシックプログラムとして扱われず，複数の機能を提供 する複数のモジュールの集まりとして扱われるアーキテクチャが可能となる。フレキシブルデ コーダは，ＭＰＥＧ−４システムにおける標準化で検討されたことがある。ＭＰＥＧ−４は， 効率的な圧縮だけでなくユーザのコンテンツベースの操作などの機能を提供する柔軟かつ拡張 可能なアーキテクチャを確立するように設計された。フレキシブルデコーダアーキテクチャは， ＭＰＥＧ−４システムの標準には含まれないが，このアーキテクチャにより，新しいタイプの メディアコンテンツが届いた時に，クライアントが，必要なモジュールのみをダウンロードす ることによりデコーダを構成できる。このアーキテクチャにより，デコーダをダウンロードす るためのネットワーク帯域幅とクライアント又はサーバのリソースを削減できる。それゆえ， デコーダダウンロードシステムにおいてフレキシブルデコーダを用いると効率的である。 (イ) フレキシブルデコーダへのアプローチ 先行文献はフレキシブルデコーダのための方法を示している。この文献に基づきデコーダを 開発することにより，復号プロセスが継続中に，ユーザがＤＣＴやウェーブレットなどの画像 処理アルゴリズムを変更できる。デコーダの機能の分離は，３コンポーネントモデルにより実 現できる。３コンポーネントモデルは，デコーダが，図５に示した，@ビットストリーム解析 ブロック，Aデータ再生ブロック，及びB画像再構成ブロックに分かれることを意味する。ビ ットストリーム解析ブロックは，ビットストリームをそのシンタックスに従って解析する。画 像再構成ブロックは，実際の画像復号アルゴリズムを提供する。データ再生ブロックは，ビッ トストリーム解析ブロックと画像再構成ブロックとの間の分離で重要な役割を有する。データ 再生ブロックは画像再構成ブロックに対してデータアライメントを提供する。これは，データ 再生ブロックと画像再構成ブロックとの間の変換プロセスと考えることができる。結果として， データ再生ブロックがあることにより，一方の側での変更が他方の側に影響しなくなる。 このデコーダアーキテクチャは，フレキシブルデコーダにとって非常に有用であると思われ る。しかし，デコーダをモノリシックプログラムとして開発することを意味する従来の方法と 比べて，このアーキテクチャに従ってデコーダを開発することは，より難しくなる。 【図５】 (ウ) ビットストリーム解析からの画像処理の分離 この提案では，ビットストリーム解析するモジュールは，画像を復号するモジュールから完 全に分離される。これにより，デコーダは，同じ画像復号アルゴリズムのための様々なモジュ ールを用いられる。例えば，クライアントのハードウェア仕様（ＭＭＸ，３ＤＮｏｗ！，ＤＳ Ｐ，ＡＳＩＣなど）に適したＩＤＣＴモジュールを選択して，同じビットストリーム解析を共 有できる。デコーダ・ダウンロード可能システムは，メディア処理のみならずサーチエンジン などの様々なマルチメディアシステムに使うことができる。この柔軟性は，単に画像復号アル ゴリズムのモジュールを他のプロセスのもので置き換えることにより実現できる。分離をより 柔軟にするため，Ｊａｖａなどのクライアントに依存しないデコーダソフトウェアを利用する。 …（略）… オ 結論 本論文では，コンテンツ指向の符号化方式のための新しいシステムアーキテクチャを提案し た。このシステムにより，クライアントとサーバとの間のネゴシエーションにより，デコーダ を動的にダウンロードすることができる。それゆえ，クライアントは，画像符号化方式に関す る知識がなくてもコンテンツを復号でき，メディアコンテンツを途切れなしに再生できる。こ のシステムは，ＪａｖａとＣＯＲＢＡにより開発されたので，移植性に優れている。デコーダ をフレキシブルデコーダとして開発すれば，デコーダ・ダウンロード可能システムにとって有 用であると言える。ＭＳＤＬ−Ｓを用いてビットストリーム解析を他の処理から分離する方法 も提案した。 (2) 前記(1)の記載によれば，引用発明の概要は以下のとおりのものであると認 められる。 引用発明の目的は，デコーダ・ダウンロード可能システムにおいて，コンテンツ の特徴を用いた画像圧縮に基づくマルチメディアのために統一プラットフォームを 提供するものであり，再生を途切れなく遅延が最小となるように，サーバとクライ アント間のネゴシエーションにより，デコーダの動的ダウンロードを可能とするこ とにある。 ところで，デコーダは，ビットストリーム解析，画像圧縮アルゴリズム（ＤＣＴ， ウェーブレット，動き推定など）などの複数の機能を有するが，従来のデコーダは 一体のソフトウェアであったため，デコーダのパーツを共有することができなかっ た。 しかし，引用発明のシステムによれば，モジュールベースのデコーダ（フレキシ ブルデコーダ）はモジュールにより構成され，複数のデコーダ間でモジュールを共 有することが可能となり，フレキシブルデコーダにより，デコーダの冗長なパーツ のダウンロードを回避することによって，ダウンロード時間を短くすることができ る。引用発明のシステムは，クライアントとサーバからなり，システムが様々な環 境で動作するように，クライアントシステムはＪａｖａを用いて実装したため，Ｊ ａｖａにより開発したデコーダは，サーバがクライアントのオペレーティングシス テムの種類を心配する必要がないというメリットがある。 そして，クライアントは，コンテンツ情報（コンテンツ情報は，最適なデコーダ 情報を含む。 を用いて， ） これに対応するデコーダがクライアント側にあるかどうか を確認し，デコーダを有していない場合，コンテンツサーバに対して，デコーダが どこに記憶されているのかを要求し，情報サーバは，デコーダ情報を用いて，要求 されたデコーダのデコーダＵＲＩをクライアントに返し，クライアントは，情報サ ーバから取得したデコーダＵＲＩを用いてデコーダサーバからデコーダをダウンロ ードする。 また，フレキシブルデコーダは，モノリシックプログラムとして扱われず，複数 の機能を提供する複数のモジュールの集まりとして扱われるアーキテクチャが可能 であるから，クライアントは，新しいタイプのメディアコンテンツが届いたときに， 必要なモジュールのみをダウンロードすることによりデコーダを構成できるため， デコーダをダウンロードするためのネットワーク帯域幅とクライアント又はサーバ のリソースを削減できる。 さらに，フレキシブルデコーダは，１）ビットストリーム解析ブロック，２）デ ータ再生ブロック，及び３）画像再構成ブロックに分かれており，ビットストリー ム解析をするモジュールは，画像を復号するモジュールから完全に分離されるから， デコーダは，クライアントのハードウェア仕様（ＭＭＸ，３ＤＮｏｗ！，ＤＳＰ， ＡＳＩＣなど）に適したＩＤＣＴモジュールを選択して，同じビットストリーム解 析を共有できるなど，同じ画像復号アルゴリズムのための様々なモジュールを用い ることができ，単に画像復号アルゴリズムのモジュールを他のプロセスのもので置 き換えることにより実現することができる。 ３ 公知文献について (1) 公知文献１（甲２） ア 公知文献１には，おおむね，以下の内容の記載がある。 (ア) 要約 本発明は，新しいコンテンツ形式を再生するようにアップグレード可能な拡張可能ディスク プレイヤを提供する。プレイヤの機能は，インターネットを介してウェブサーバから適切なデ コーダをダウンロードすることにより，拡張可能である。このように，プレイヤは，もともと サポートしていないコンテンツを再生することができる。コンテンツ形式が未知である場合， プレイヤは，ディスクが適切なデコーダを有するウェブサイトにリンクする URL を有するか否 かを検査する。ディスクが URL を有する場合，プレイヤはウェブサイトにアクセスして適切な デコーダをダウンロードする。同様に，レコーダの機能も適切なエンコーダをダウンロードす ることにより拡張され得る。 (イ) 技術分野 本発明は，概してディスクプレイヤに関するものであり，特に新しいコンテンツ形式を再生 するようにアップグレード可能なディスクプレイヤに関するものである（【０００１】。 ） (ウ) 背景技術 光ディスクは，多様なフォーマットでエンコードされ得るオーディオ，データ，ビデオ，画 像，アニメーション等のような多様な種類のメディアを格納するために広く使用されてきてい る。例えば，MPEG-2 や MPEG-4 や DivX や H26.L はビデオ用に使用されており，MP3 や SACD はオ ーディオ用に使用されており，Flash や SVG はアニメーション用に使用されている。一般的に 従来のプレイヤは，コンテンツ形式のサブセットのみをサポートする固定数のデコーダを有し ている。新しいコンテンツ形式が市場に導入されると，この新しいフォーマットでディスクを 再生するために，消費者は新しいコンテンツ形式をサポートするデコーダを備えた新しいプレ イヤを購入する必要がある。これは消費者にとって非常に高コストである。顧客は新しいプレ イヤを今購入して結果として数年のうちに旧式になることがわかるか，新しいフォーマットを 備えたディスクを購入しないかについて困難な決定を行う必要がある。消費者の多数が新しい フォーマットを備えたディスクを購入しないことを決定した場合，新しいフォーマットの採用 を著しく妨げ，新しい光ストレージ技術の開発にかなり影響を及ぼす（【０００２】。 ） (エ) 発明が解決しようとする課題 したがって，既存のコンテンツ形式を再生できるだけでなく，新しいコンテンツ形式を再生 するようにアップグレード可能でもよいプレイヤを提供する必要がある（【０００３】。 ） (オ) 課題を解決するための手段 本発明は，新しいコンテンツ形式を再生するようにアップグレード可能な拡張可能ディスク プレイヤを提供する。プレイヤの機能は，インターネットを介してウェブサーバから適切なデ コーダをダウンロードすることにより，拡張可能である。このように，プレイヤは，もともと サポートしていないコンテンツを再生することができる（【０００４】 。 ） 本発明の一実施例によると，拡張可能ディスクプレイヤが提供される。プレイヤは，ディス クのコンテンツオブジェクトのコンテンツ形式を決定する手段と，コンテンツ形式が未知であ ると決定した場合に，ディスクが適切なデコーダを有するウェブサイトにリンクする URL を有 するか否かを検査する手段と，ディスクが URL を有することを検査した場合に，ウェブサイト にアクセスして適切なデコーダをダウンロードする手段とを有する（【０００５】 。 ） (カ) 発明を実施するための最良の形態 ａ 図１は，本発明の一実施例による拡張可能ディスクプレイヤ 10 の動作の概要を示してい る。プレイヤ 10 はインターネットに接続可能であり，ウェブアクセス用の基本的なプロトコル スタックのサポート(例えば HTTP プロトコルスタック)を有する。光ディスク 20 がプレイヤ 10 に挿入されると，プレイヤはディスクの内容を認識して再生しようとする。プレイヤがコンテ ンツのフォーマットを処理できない場合，インターネットを介してウェブサーバ 30 から適切な デコーダを見つけてダウンロードすることを試みる。 デコーダがダウンロードされた後に，同じコンテンツ形式が次回認識されたときにプレイヤ がそれを再びダウンロードする必要がないように，デコーダがプレイヤに格納されることが好 ましい（【００１２】 。 ） 【図１】 ｂ 図２は，本発明の一実施例に従って適切なデコーダを取得する拡張可能ディスクプレイ ヤにより実行される処理 100 を示したフローチャートである。プレイヤへのディスクの挿入時 に，プレイヤはディスクのコンテンツオブジェクトを提示しようとし(ステップ 102)，プレイ ヤに既知のコンテンツ形式を有しているか否かを決定する(ステップ 106)。 コンテンツ形式がプレイヤに既知である場合，プレイヤはコンテンツオブジェクトをロード して処理する(ステップ 112)。しかし，プレイヤがコンテンツ形式を認識していない場合，適 切なデコーダを有するウェブサイトにリンクする URL がディスクで利用可能であるか否かを決 定しようとする(ステップ 116)。 ステップ 116 で URL がディスクに存在することが決定されると，プレイヤはその URL を使用 してウェブサイトにアクセスする(ステップ 136)。次に，プレイヤはデコーダが見つかったか 否かを決定する(ステップ 142)。見つかった場合，プレイヤはデコーダをダウンロードし(ステ ップ 152)，コンテンツオブジェクトを処理し始める(ステップ 156)。 【００１３】 ００１４】。 （（ ， 【 ） 【図２】 このように，DVD プレイヤのような再生装置の機能は，適切なデコーダモジュールをダウン ロードすることにより拡張され得る（【００１６】。 ） イ 前記アの記載によれば，公知文献１には，コンテンツとともに，このコンテ ンツの再生を実行する適切なデコーダを有するウェブサイトにリンクするためのＵ ＲＬが記憶されたディスクをプレイヤに挿入することにより，ウェブサイトにアク セスしてデコーダをダウンロードする技術が記載されていることが認められる。 (2) 公知文献２（甲３） ア 公知文献２には，おおむね，以下の内容の記載がある。 (ア) 発明の属する技術分野 本発明は，異なる圧縮方式で圧縮されたデータが混在して記録された記録媒体からデータを 読み出してデコードして再生するときに，デコードに必要とするデコードのためのプログラム を，上記プログラムが記録されている場所に応じて取得するようにした再生装置，再生方法及 び再生システムに関する（【０００１】。 ） (イ) 発明が解決しようとする課題 コンピュータ装置からディジタル音楽コンテンツをディジタルデータのままで記録媒体に記 録する機能を備えた携帯型のオーディオプレーヤは，特定のオーディオ圧縮方式に対応するも のであって，例えばＭＰ３プレーヤでは，ＭＰ３データを専用デコーダによりデコードしてオ ーディオに戻すので，ＭＰ３以外の他のオーディオ圧縮方式のディジタル音楽コンテンツを取 り扱うことはできない（【０００７】。 ） 今日，様々なオーディオ圧縮方式が提案されており，各種オーディオ圧縮方式に個別に対応 するオーディオプレーヤを所有することは，ユーザにとって不便であることから，複数のオー ディオ圧縮方式に１台で対応できるマルチフォーマット対応の携帯型のオーディオプレーヤの 出現が望まれている（【０００８】。 ） そこで，本発明の目的は，複数のオーディオコーデックに対応するマルチコーデック対応の オーディオシステムを安価に実現することにある（【０００９】。 ） (ウ) 発明の実施の形態 ａ オーディオ再生装置４の電気的な構成を図３に示してある（【００２３】。 ） 【図３】 このオーディオ再生装置４は，ＵＳＢ端子１４を介してコンピュータ装置３とＵＳＢケーブ ル２４で接続され，当該コンピュータ装置３から転送されたディジタル音楽コンテンツＣ１が ＵＳＢコントローラ２５から内部バス２６を介して転送されるＣＰＵ２７を備える。上記内部 バス２６には，フラッシュメモリ３０，操作キーコントローラ３１，デジタルシグナルプロセ ッサ（DSP:Digital SignalProcessor）３２，出力増幅器３３，ＥＥＰＲＯＭ（Electrically Erasable Programmable Read‐Only Memory）３４，ＬＣＤ（Liquid Crystal Display）コント ローラ３５，ＲＴＣ（Real Time Clock）回路３６等が接続されている（【００２４】。 ） このオーディオ再生装置４では，大容量のメモリ空間をサポートするＣＰＵ２７により音楽 データのダウンロードやユーザインターフェース，また，大容量の不揮発性メモリであるフラ ッシュメモリ３０の管理を行う。上記ＣＰＵ２７には，ＣＰＵコア２７Ａ以外にメモリ２７Ｂ， ２７Ｃも内蔵したワンチップマイクロコンピュータが採用されている。このＣＰＵ２７のプロ グラムメモリには内蔵のマスクＲＯＭ（Read‐０nly Memory）２７Ｂが用いられている（【００ ２５】。 ） 上記オーディオ再生装置４は，複数のフォーマットのディジタル音楽コンテンツに対応する ために，音楽コーデックをソフトウエアにて実現しており，所定の圧縮方式でデータ圧縮され た音楽データＤ１に対応した伸長方式で再生するための再生用コードであるコーデックプログ ラムをフラッシュメモリ３０に予め格納しておき，このコーデックプログラムをフラッシュメ モリ３０から同じフラッシュメモリ３０内にあるインデクスデータに基づいてＤＳＰ３２内部 のＲＡＭ３２Ｂ（Random Access Memory）上にコピーして，上記ＤＳＰ３２内部のメモリ空間 に置いたコーデックプログラムを実行することにより，音楽再生を行う（【００２６】。 ） すなわち，このオーディオ再生装置４において，ＣＰＵ２７は，音楽データとコーデックプ ログラムが入った大容量の不揮発性メモリすなわちフラッシュメモリ３０を管理する 【００２ （ ７】。 ） このオーディシステムにおけるオーディオ再生装置４では，ソフトウエアにて音楽コーデッ クを実現しているので，装置全体を小型かつ安価に作ることができる。なお，ハードウエアに 依存する音楽コーデックで複数フォーマットに対応するには，対応するコーデック毎にハード ウエアが必要となる（【００２８】。 ） また，上記オーディオ再生装置４において，ソフトウエアによる音楽コーデックを実行する ＤＳＰコア３２Ａは，コーデックのようにリアルタイムに信号を加工する処理のために特化さ れたインストラクションを有するので，少ない消費電力で処理を完了することができる。また， ＤＳＰ３２内部のメモリ空間は，外部のメモリ空間をアクセスする場合に比べ，結線による容 量性負荷が殆どないため，少ない消費電力で高速にアクセスすることができる（【００２９】 。 ） コーデックプログラムは高速な演算が期待される処理であり，上記ＤＳＰ３２では，この処 理を効率的に実効することができる。なお，ＤＳＰ３２内部のメモリは，高速性を追求した構 造となっているため，一般的な外部メモリと比較してビット単価が高いが，現在使用するコー デックのみを外部のフラッシュメモリ３０から使用前にコピーするので，コーデック１個分の 容量があればよい（【００３０】 。 ） ここで，コーデックプログラムを記憶するフラッシュメモリ３０は，書換え可能であるので， ユーザがコーデックプログラムを追加することができる。なお，フラッシュメモリ３０に追加 記憶するコーデックプログラムは，上記ＥＭＤサーバ１からインターネット２を介して配信す るようにしてもよい（【００３１】。 ） 電子音楽配信サービスにより配信された例えば有料の音楽データは，コーデックプログラム とともに不揮発性メモリに記憶される必要があり，コーデックプログラムとともに物理的に同 一のデバイスであるフラッシュメモリ３０に記憶することは，デバイスの実装面積及び価格の 点で有利である（【００３２】。 ） ｂ オーディオ再生装置４のＣＰＵ２７は，実際に音楽再生を行う場合に，音楽データの先 頭に予め付加されているヘッダ情報をフラッシュメモリ３０から読み込み，現在ＤＳＰ３２内 に設定してあるコーデックで再生可能な圧縮方式をＲＡＭ２７Ｃから取得し，取得された情報 のうちの現在ＤＳＰ３２に設定してあるコーデックとヘッダ情報から得られた圧縮形式とが同 一であるか否かを判定する（【００３９】。 ） そして，上記ＣＰＵ２７は，ＤＳＰ３２に入っているコーデックが異なっている場合には， フラッシュメモリ３０に記憶されているインデクスデータに基づいてフラッシュメモリ３０に 書き込まれているコーデックプログラムから，再生する音楽データフォーマットに合致したコ ーデックプログラムを探し，ＤＳＰ３２にダウンロードするとともにＲＡＭ２７ＣへＤＳＰ３ ２にダウンロードしたコーディックに関する情報を記憶させる。ＲＡＭ２７Ｃに記憶されたコ ーディックに関する情報を次の音楽データを再生するときに参照されることになる。上記ＣＰ Ｕ２７は，その後，フラッシュメモリ３０から音楽データをＤＳＰ３２に送って，音楽再生を 行う（【００４０】。 ） ここで，上記ＣＰＵ２７は，上記ＤＳＰ３２がデコードする音楽情報を管理し，上記音楽情 報の音楽フォーマットによらず，音楽情報の再生の進捗に同期して，音楽情報を一定量ずつ上 記ＤＳＰ３２に送って，音楽情報を再生する（【００４１】。 ） ｃ このオーディオシステムにおけるディジタル音楽コンテンツＣ１は，図８に示すように ヘッダＨ１と音楽データＤ１とからなり，ヘッダＨ１にはファイルＩＤ，ヘッダサイズ，コン テンツキー，ファイル，コーデックＩＤ，ファイル名及びファイル情報が格納されているとと もに，再生制限に関する再生制限情報として再生制限データ，再生開始日，再生終了日，再生 可能回数，再生回数及びオーディオファイルが格納されている（【００４４】。 ） コンテンツキーは，音楽データＤ１に対する暗号化を解くための暗号データであり，実際上 コンピュータ装置３及びオーディオ再生装置４の間でディジタル音楽コンテンツＣ１の授受が 行われる際に，共通のセッションキーでさらに暗号化された状態で転送される。コーデックＩ Ｄは，オーディオ再生装置４でディジタル音楽コンテンツＣ１の音楽データＤ１を再生する場 合の伸長方式に対応したＩＤ番号であり，例えば，１Ｄ番号「１」に対してはＡＴＲＡＣ （Adaptlve Transform Acoustic Coding）３と呼ばれるデータ圧縮方法に応じた伸長方式が割 り当てられ，ＩＤ番号０ｘ００００に対してはＭＰ３（MPEG Audio Layer-3）と呼ばれるデー タ圧縮方法に応じた伸長方式が割り当てられている。なお， “０ｘ”を数値の前に付けることで １６進数であることを示している（【００４５】。 ） イ 前記アの記載によれば，公知文献２には，音楽データＤ１（コンテンツ）と， この音楽データＤ１を再生するコーデックのＩＤであるコーデックＩＤを含むヘッ ダＨ１で音楽コンテンツＣ１が構成される技術が記載されていることが認められる。 ４ 取消事由１（本願補正発明の容易想到性の判断に係る手続違背）について (1) 原告は，本件審決は，本願補正発明と引用発明との相違点４について，引用 発明並びに公知文献１及び２（甲２，３）に記載された公知技術に基づいて，当業 者であれば容易に想到できると判断したが，拒絶理由通知及び拒絶査定において， 公知文献１及び２は何ら引用されておらず，上記各公知文献は審決において初めて 示されたものであり，原告に対して，拒絶査定の理由と異なる新たな拒絶理由の通 知はなく，意見書提出の機会も与えられなかった。したがって，本件審決には，特 許法159条2項により準用される同法50条に違反する違法があり，その違法は 審決の結論に影響を及ぼすことが明らかである旨主張する。 しかし，特許法159条1項後段，同法53条1項，同法17条の2第1項4号， 法17条の2第6項及び法126条5項によれば，拒絶査定不服審判を請求する場 合において，その審判の請求と同時にした補正が，補正後における特許請求の範囲 に記載されている事項により特定される発明が特許出願の際独立して特許を受ける ことができないものである場合には，審判合議体は，決定をもって当該補正を却下 しなければならず，この却下の決定をする場合には，特許法159条2項後段，同 法50条ただし書及び特許法17条の2第1項4号により，審判合議体は，拒絶査 定不服審判において査定の理由と異なる拒絶の理由を発見したときであっても，特 許出願人に対して，拒絶の理由を通知して意見書提出の機会を与える必要はないと 解される。 これを本件についてみると，本件審決は，拒絶査定不服審判の請求と同時にされ た本件補正により特定された本願補正発明について，引用発明，公知文献１及び２ に記載の公知技術並びに技術常識に基づいて当業者が容易に発明をすることができ たものであり，特許法29条2項により，特許出願の際独立して特許を受けること ができないものであることを理由として，本件補正を却下しており，上記のとおり， この場合には改めて拒絶の理由を通知して意見書提出の機会を与える必要はないと 解されるから，本件審決の手続に違法はない。 原告の上記主張は理由がない。 (2) 原告は，拒絶査定不服審判を請求し，特許請求の範囲について拒絶査定の理 由を解消するような限定を付加して補正をした特許出願人（審判請求人）に対する 補正却下の理由が，特許出願人が想定し得ない新たな引用文献を引用した新たな拒 絶の理由である独立特許要件違反の場合には，特許出願人に何ら責任はなく，かか る場合にまで意見書提出の機会を与えないことは，特許庁審判官による再度の審査 （審理）を適正に受ける権利を，特許出願人から不当に奪うものであること，そも そも特許法159条1項及び２項の立法趣旨は，拒絶査定不服審判請求時にした補 正が新規事項を追加するものである場合において優先的に補正却下を適用すること にあるのであって，拒絶査定不服審判請求時に原査定の拒絶理由を解消すべく請求 項を減縮した補正を，意見書・補正書の提出機会を与えずに，新たな拒絶理由によ って補正却下するような事態に適用することは想定されていないのであるから，拒 絶査定不服審判請求時にした補正を，補正違反の態様にかかわらず一律に補正却下 の対象とした同法159条1項後段及び２項後段の規定自体が立法の誤りであり， 憲法31条に反し違憲であって，本件審決もまた違憲な規定に則ったものであるか ら違憲である旨主張する。 特許法159条1項後段及び２項後段は，平成５年法律第２６号により規定され たものであることから，その立法経緯等について検討するに，従前の特許法におい ては，特許請求の範囲の補正については，出願公告の決定謄本の送達前に出願当初 の明細書に記載された事項の範囲内において特許請求の範囲を増加，減少又は変更 する補正は，明細書の要旨を変更しないものとみなすと規定されているのみであっ たことから，拒絶理由通知後であっても，特許請求の範囲の拡張，変更等の補正を 行うことが許容されていたのみならず，特許請求の範囲の補正の回数も制限されて いなかったため，一つの出願において拒絶理由が通知されるたびに特許請求の範囲 の補正を行うことも許容されていた。そして，このような補正がされた場合には， 審査対象が変更されるため，そのたびに新たな先行技術の調査及びその結果に基づ く対比判断等の新たな審査を行わざるを得なかったが，実際の出願において何回も 特許請求の範囲についての補正が行われた場合は，出願間の取扱いに公平性を欠く ことになるのみならず，このような出願が存在することにより，他の出願の審査の 遅延をも生じるおそれがあるという弊害が生じていた。さらに，第三者にとっては， 出願公開後に補償金請求権が発生するにもかかわらず，特許請求の範囲の補正が何 回も行われることにより，特許が付与がされる対象が何回も変更されることとなり， その監視負担が過大となるという弊害も生じていた。そこで，平成４年１２月にと りまとめられた工業所有権審議会の答申（以下「審議会答申」という。 においては， ） 昭和６３年に我が国の特許法に主要国と同様の多項制が既に導入されており，その 利用も拡大しつつあること等も踏まえ，出願公告の決定謄本送達前の特許請求の範 囲の補正について，制度及び審査実務等の運用の国際的調和，出願間の取扱いの公 平性及び迅速な権利付与等の観点から適正化を図るべきであるとされた。 また，従前の特許法においては，出願公告の決定謄本の送達前に拒絶査定不服審 判を請求する際には，特許請求の範囲の拡張，減縮，変更を含めた広範な補正を行 うことが認められているとともに，審判請求時に補正がされた場合には，審査前置 制度により，審査官が再度審査を行い，拒絶査定の対象となった請求項が削除され る等，拒絶査定をした理由が解消されている場合には，審査官に拒絶査定を取り消 す機会が与えられていた。この審査前置制度の趣旨は，審判請求時に補正がされた 場合は，審判合議体による審理の前に審査官に再度審査をさせることにより，審査 段階において得られた調査結果や出願内容の知識を活用し，出願内容の理解や調査 に要する時間を節約して処理を行うことにあった。しかしながら，審査前置制度は， 我が国の特許法が単項制を採用していた頃に導入されたものであり，拒絶査定不服 審判請求時に特許請求の範囲の拡張，変更を行う補正も許容されていたことから， そのようは補正がされた場合は，拒絶査定を受けた発明とは別の発明について，審 査官による再度の審査（または審判官による審理）が行われることとなり，その結 果，もとの審査における審理の手続や結果が軽視され，新たに最初から審理がし直 されることともなりかねなかったことから，審理の迅速性及び的確性が十分に確保 され難いという問題を有していた。また，拒絶査定不服審判請求時に，特許請求の 範囲を拡張，変更する補正がされると，多項性の利用が拡大しつつある状況におい ては，多項制を有意義に活用し，特許請求の範囲の請求項の削除等の補正のみを行 う出願との間において，出願の取扱いの公平性が担保されないこととなっていたの みならず，前者の出願が存在することにより，後者の出願の審理が遅延するという 弊害をも生じていた。このため，審議会答申においては，拒絶査定不服審判におけ る補正の範囲に関する主要国の制度及び運用も考慮しつつ，行政処分である拒絶査 定の瑕疵の是正をより迅速，的確かつ公平に行うため，出願公告の決定謄本送達前 の拒絶査定不服審判の請求時における補正の範囲の適正化を行うべきであるとされ た。 そこで，平成５年法律第２６号において，最後の拒絶理由通知に対する補正につ いて，明細書及び図面に新規事項を追加しないものであるほか，特許請求の範囲の 減縮に当たる補正がされた場合においても，補正後の発明が独立して特許を受ける ことができるもののみを許容すること（独立特許要件）を含めて補正の範囲の適正 化を図るべく特許法17条の2の規定が整備され，拒絶理由の通知について同法５ 0条ただし書の規定が設けられるとともに，不適法な補正は却下することとして同 法53条1項ないし３項の規定が設けられた。このように，最後の拒絶理由通知に 対する補正が独立特許要件を含めて特許法17条の2の規定に違反する不適法なも のであることが出願公告の決定謄本の送達前に認められた場合に，拒絶理由を通知 することなく当該補正を却下することとした理由は，補正により特許可能となる発 明については補正を認めることによって迅速に権利付与を行うことが出願人の利益 となるのに対し，補正後の発明が特許性を有しない場合に再度拒絶理由を通知する こととした場合には拒絶理由通知に対して再度の補正が可能であるため，審査官は 当該補正について再度審査する必要があり，審査の迅速性が十分に確保され難く， 出願間の取扱いの公平性を欠くことになるためである。 そして，出願公告の決定謄本送達前に拒絶査定不服審判を請求する際の補正がで きる範囲についても，審判制度の改善の一環として，制度の国際的調和を図るとと もに，拒絶査定不服審判の審理の迅速化を図る観点から，最後の拒絶理由通知に対 する補正と同じ範囲とするとともに，特許法159条1項後段及び２項後段を規定 し，同法53条及び50条ただし書を準用することにより，独立特許要件を含めて その補正が不適法な場合には，新たにその旨の拒絶理由を通知することなく，その 補正を却下することとした（以上について，乙１〜９）。 上記でみたところによれば，特許法159条1項後段及び２項後段は，独立特許 要件違反を含め拒絶査定不服審判請求時にされた不適法な補正に対し，拒絶理由を 通知することなくこれを却下することにより，審理の迅速化，出願間の公平性の確 保及び第三者の監視負担の軽減等を図った合理的な規定であるというべきであるか ら，これらの規定が憲法31条に違反する旨の原告の前記主張は採用することがで きない。 (3) 原告は，本件のように拒絶査定不服審判請求時に原査定の拒絶理由を解消す るために特許請求の範囲を減縮した補正を，新たな引用文献に基づく新たな拒絶理 由で却下する場合には，審判合議体は，いきなり補正却下・拒絶審決をするのでは なく，まず拒絶理由を通知するとの運用をすることが，特許制度の趣旨及び憲法３ 1条に沿うものであるから，本件審決は，特許法159条1項後段及び２項後段の 規定を適切に運用することを怠った違法性，違憲性がある旨主張するが，かかる運 用を特許庁に義務づけることは，前記(2)で検討した平成５年法律第２６号による改 正の趣旨を没却する結果となるものであることは明らかであるから，原告の上記主 張を採用することはできない。 (4) 以上によれば，原告主張の取消事由１は理由がない。 ５ 取消事由２（本願補正発明と引用発明との一致点の認定の誤り，相違点の看 過）について (1) 原告は，本願補正発明の「装置」は，引用発明の情報サーバに対応するもので はなく，クライアントに対応するものであるところ，引用発明において， 「前記マル チメディアコンテンツに関する前記コーデックサーバの位置情報と前記コーデック のバイナリデータの識別情報とを用い」る主体は，情報サーバであって，クライア ントではないから，本件審決が一致点として認定した「前記マルチメディアコンテ ンツに関する前記コーデックサーバの位置情報と前記コーデックのバイナリデータ の識別情報とが用いられ」は，引用発明の「クライアント」と本願補正発明の「装 置」との一致点とはなり得ず，本件審決は一致点の認定を誤り相違点を看過してい る旨主張する。 しかし，本件審決が一致点として認定した「コーデックサーバの位置情報」及び 「コーデックのバイナリデータの識別情報」は，それぞれ引用発明における「デコ ーダＵＲＩ」及び「対応する最適なデコーダ情報」に相当するものであるところ， 前記２(1)ウ(イ)ｂのとおり，引用発明においては，クライアントは，コンテンツ情 報（コンテンツ情報は，最適なデコーダ情報を含む。）を用いて，これに対応するデ コーダがクライアント側にあるかどうかを確認し，デコーダを有していない場合， コンテンツサーバに対して，デコーダがどこに記憶されているのかを要求し，情報 サーバは，デコーダ情報を用いて，要求されたデコーダのデコーダＵＲＩをクライ アントに返し，クライアントは，情報サーバから取得したデコーダＵＲＩを用いて デコーダサーバからデコーダをダウンロードする。 そうすると，引用発明において，クライアントが，情報サーバからデコーダＵＲ Ｉ（コーデックサーバの位置情報）を取得するにしても，デコーダのダウンロード を行う際に， 「マルチメディアコンテンツに関するコーデックサーバの位置情報」及 び「コーデックのバイナリデータの識別情報」を用いる主体はクライアントである から，本件審決が， 「前記マルチメディアコンテンツに関する前記コーデックサーバ の位置情報と前記コーデックのバイナリデータの識別情報とが用いられ」ることを， 引用発明の「クライアント」と本願補正発明の「装置」との一致点と認定したこと に誤りはない。 原告の上記主張は理由がない。 (2) 原告は，引用発明において，「前記コーデックサーバの位置情報と前記コー デックのバイナリデータの識別情報」を知っているのは，情報サーバであって，ク ライアントではなく，一方，本願補正発明の「装置」においては， 「前記マルチメデ ィアコンテンツ」に含まれた「前記コーデックサーバの位置情報と前記第１のソフ トウェアモジュールの識別情報とに基づき」第１のソフトウェアモジュールのダウ ， ンロードを要求するのは，「装置」内部の制御部であって，サーバ側ではないから， 本件審決が一致点として認定した「前記コーデックサーバの位置情報と前記コーデ ックのバイナリデータの識別情報とに基づき」は，引用発明の「クライアント」と 本願補正発明の「装置」との一致点とはなり得ず，本件審決は一致点の認定を誤り 相違点を看過している旨主張する。 しかしながら，前記(1)のとおり，クライアントは，最適なデコーダ情報（コーデ ックのバイナリデータの識別情報）及び情報サーバから取得したデコーダＵＲＩ（コ ーデックサーバの位置情報）を用いて，デコーダをダウンロードしているから，本 件審決が，前記コーデックサーバの位置情報と前記コーデックのバイナリデータの 「 識別情報とに基づき，外部ネットワークに位置した前記コーデックサーバに前記コ 」 ーデックのバイナリデータのダウンロードを要求するメッセージを生成及び伝送す ることを，引用発明の「クライアント」と本願補正発明の「装置」との一致点と認 定したことに誤りはない。 原告の上記主張は理由がない。 (3) 以上によれば，原告主張の取消事由２は理由がない。 ６ 取消事由３（本願補正発明と引用発明との相違点４に係る判断の誤り）につ いて (1) 原告は，本願補正発明の「ソフトウェアモジュール」は，ＯＳ，コーデック ライブラリ，メディアフレームワーク及びハードウェアライブラリを含むところ， 本願補正発明は，第１と第２のソフトウェアモジュールを組み合わせてＤＳＰコー 「 ドを生成」することを要件としているから， 「第１のソフトウェアモジュール」がメ ディアフレームワークであり， 「第２のソフトウェアモジュール」がハードウェアラ イブラリである場合も包含するものであるが，引用発明においてダウンロードされ る「デコーダモジュール」は，本願明細書の「コーデック」 （コーデックライブラリ の一要素）に相当するものであるから，本件審決が相違点２として判断した「モジ ュールのみをダウンロードする点」及び「得ようとする各情報が「モジュール」を 対象としたものとすること」とは，引用発明における「デコーダモジュール」，すな わちコーデックライブラリについて判断したものにすぎず，コーデックライブラリ 以外の本願補正発明の「ソフトウェアモジュール」であるＯＳ，メディアフレーム ワーク及びハードウェアライブラリについては，何も判断していない旨主張する。 そこで検討するに，本願補正発明の「ＤＳＰコード」は， 「第 1 のソフトウェアモ ジュール」と， 「第２のソフトウェアモジュール」を組み合わせて生成されるもので あり，マルチメディアコンテンツに対応する「第 1 のソフトウェアモジュール」が 記憶部に記憶されていない場合， 「第１のソフトウェアモジュール」のダウンロード を要求するものである。しかるに，前記１(1)ウ，エ，オ(ア)，(イ)，(エ)のとおり， 本願明細書（甲７）の発明の詳細な説明（段落【００１８】【００２２】【００２ ， ， ３】【００３０】【００３５】【００４２】【００４３】【図５】【００４７】【０ ， ， ， ， ， ， ， ０５１】〜【００５３】）には，ダウンロードされる「第 1 のソフトウェアモジュー ル」の例示として，コーデックライブラリが記載され， 「第２のソフトウェアモジュ ール」の例示として，コーデックライブラリ以外のＯＳ，メディアフレームワーク 及びハードウェアライブラリが記載されているから，本願補正発明において，ダウ ンロードされる「第１のソフトウェアモジュール」は，コーデックライブラリを含 むものであって，これを除外するものでないことは明らかである。 そうすると，前記２(2)のとおり，引用発明は，コンテンツ（マルチメディアコン テンツ）に対応する「デコーダ」を有していない場合，コンテンツサーバに対して デコーダがどこに記憶されているのかを要求し，情報サーバから取得したデコーダ ＵＲＩを用いて，デコーダサーバから「デコーダ」をダウンロードするものである から，この点において，コーデックライブラリを含む「第 1 のソフトウェアモジュ ール」のダウンロードを行う本願補正発明と相違するものではない。 そして，本件審決が，本願優先権主張日当時の公知文献として挙げた，公知文献 １（甲２）には，前記３(1)ア(ア)，(カ)のとおり，コンテンツとともに，このコン テンツの再生を実行する適切なデコーダを有するウェブサイトにリンクするための ＵＲＬが記憶されたディスクをプレイヤに挿入することにより，ウェブサイトにア クセスしてデコーダをダウンロードする技術が，公知文献２（甲３）には，前記３ (2)ア(ウ)ｃのとおり，音楽データＤ１（コンテンツ）と，この音楽データＤ１を再 生するコーデックのＩＤであるコーデックＩＤを含むヘッダＨ１で音楽コンテンツ Ｃ１が構成される技術がそれぞれ記載されている。したがって，コンテンツに，デ コーダを有するウェブサイトにリンクするためのＵＲＬ（コーデックサーバの位置 情報）やコーデックＩＤ（第 1 のソフトウェアモジュールの識別情報）を含むよう に構成することは，本願優先権主張日当時の公知技術であると認められるから，引 用発明に当該公知技術を適用して，相違点４に係る本願補正発明の構成に至ること は，当業者であれば，容易に想到し得るものである。 原告の上記主張は理由がない。 (2) 原告は，公知文献１及び２には，デコーダ全体ではなく，そのうちの一部に 相当する第１のソフトウェアモジュールのみをダウンロードするためのコーデック サーバの位置情報や，第１のソフトウェアモジュールのみの識別情報がディスクに 含まれているという記載はなく，公知文献１及び２記載の技術を引用発明に組み合 わせて本願補正発明の進歩性を否定するためには，公知文献１及び２において，単 にデコーダが存在するウェブサイトのＵＲＬ及びデコーダの識別情報では足りず， デコーダ全体のうちの一部に相当する第１のソフトウェアモジュールのみをダウン ロードするためのコーデックサーバの位置情報及び第１のソフトウェアモジュール の識別情報がディスクに含まれている必要があるから，仮に公知文献１及び２記載 の技術を引用発明に適用できたとしても，本願補正発明には至らない旨主張する。 しかし，前記２(1)エのとおり，引用発明は，モジュールベースのデコーダ（フレ キシブルデコーダ）をモノリシックプログラムではなく複数の機能を提供する複数 のモジュールの集まりとし，クライアントは，新しいタイプのメディアコンテンツ が届いたときに，必要なモジュールのみをダウンロードすることによりデコーダを 構成できるものである。本件審決は，本願補正発明と引用発明との相違点２につい ては，引用発明から本願補正発明の構成に想到することは当業者であれば容易であ る旨判断しているのであって，この点の判断には，後記７の「取消事由４（本願補 正発明と引用発明との相違点１及び２に係る判断の誤り）について」において説示 するとおり誤りはない。 そうすると，かかるフレキシブルデコーダの構成を採用する引用発明に，公知文 献１及び２の公知技術を適用して，ダウンロードされる「第１のソフトウェアモジ ュール」であるコーデックライブラリに対するコーデックサーバの位置情報やデコ ーダの識別情報をコンテンツの中に含ませることは，当業者であれば容易に想到し 得るものである。 原告の上記主張は理由がない。 (3) 原告は，本願補正発明では，「前記マルチメディアコンテンツは前記コーデ ックサーバの位置情報と前記第１のソフトウェアモジュールの識別情報を含み」及 び「前記コーデックサーバの位置情報と前記第１のソフトウェアモジュールの識別 情報とに基づき」の要件を満たしているから，装置側からサーバ側に対して「コー デックサーバの位置情報と第１のソフトウェアモジュールの識別情報」を要求する ことなく，マルチメディアコンテンツ自体に内在する「コーデックサーバの位置情 報と第１のソフトウェアモジュールの識別情報」をそのまま利用すれば足りるのに 対して，引用発明においては， 「クライアントが対応するデコーダを有していない場 合には，スケジューラー管理エンジンは，デコーダＵＲＩを得ることをデコーダ・ コンポーネント管理エンジンに指示する。デコーダ・コンポーネント管理エンジン は，どこにデコーダが格納されているかをコンテンツサーバに要求する」のであっ て，本願補正発明には，このような要求を必要としないという効果がある旨主張す る。 しかし，前記のとおり，「マルチメディアコンテンツ」に，「コーデックサーバの 位置情報」と「コーデックの識別情報」を含むように構成することは，当業者であ れば容易に想到し得るものであるから，本願補正発明において，どこにデコーダが 格納されているかをコンテンツサーバに要求する必要がないとの効果は，当該構成 に付随する当然の効果であって，格別顕著な効果であると認めることはできない。 原告の上記主張は理由がない。 (4) 以上によれば，原告主張の取消事由３は理由がない。 ７ 取消事由４（本願補正発明と引用発明との相違点１及び２に係る判断の誤り） について (1) 原告は，引用発明では“core engine”にデコーダを設置しており，“core engine”はＣＰＵに該当するから，引用発明のデコーダダウンロード及び設置に関 するソフトウェアはＣＰＵ上で動作するソフトウェアであって本願補正発明のＤＳ Ｐコードとは異なるものであること，引用例には，ＯＳなどの実行環境が劣悪であ るというＤＳＰの特性上コンポーネント化されていないソフトウェアを備えるしか ないＤＳＰに対し，新規コーデックが要求される際にコーデックを変更するために 最小限の資源を用いてＤＳＰ規格に合うＤＳＰコードを容易に提供することについ ては，いかなる開示も示唆もないこと，これに対し，本願補正発明は，コンポーネ ント化されたソフトウェアの使用が容易ではないＤＳＰによりコーデックを支援す る回路環境で新規コーデックが要求されるたびに大容量のＤＳＰコードを適用及び 交替することにより発生する相当量のオーバーヘッドを最小化するため，コンテン ツを再生するたびにリアルタイムでＣＰＵ(ＤＳＰコード生成部)で適切なコーデッ クライブラリを選択するようにした後，選択されたコーデックライブラリとＯＳ及 びメディアフレームワークを組み合わせてＤＳＰコードを生成し，生成されたＤＳ ＰコードをＤＳＰ処理部に提供し，ＤＳＰ処理部では提供されたＤＳＰコードに基 づいてコンテンツを再生するためのデコーディングを行うこととし，ＤＳＰはコン テンツを再生するたびにＣＰＵからＤＳＰコードを提供される構成としたものであ り，かかる構成，効果を検討せずに相違点１及び２について容易想到であると判断 した本件審決は誤りである旨主張する。 しかし，前記２(1)ア(イ)記載のとおり，引用発明は，従来のデコーダは一体のソ フトウェアであったため，複数のデコーダ間において，デコーダを構成する画像圧 縮アルゴリズム（ＤＣＴ，ウェーブレット，動き推定など）等が同じであったとし ても，デコーダのパーツを共有することができなかったという課題を解決するため， デコーダをモジュールベースとすることにより，同じ画像圧縮アルゴリズム等を複 数のデコーダ間で共有するように構成したものであると認められる。また，前記２ エ ウ のとおり，引用例には，ＤＳＰなどのハードウェアに適したＩＤＣＴモジ ュールを選択してデコーダを構成することが記載されているから，引用発明におい て，ＤＳＰによってもデコーダを動作させ得ることが理解される。 そうすると，引用発明のコアエンジンについて，ＤＳＰによるハードウェアを採 用し，ＤＳＰでデコーダを動作させるように構成することは，当業者であれば容易 に想到し得るものである。また，ＤＳＰによってデコーダを動作させる場合，ＤＳ Ｐに適したＯＳ等のソフトウェアが必要であることは，本願優先権主張日当時の技 術常識であるというべきであるから，デコーダとＯＳ等のソフトウェアを組み合わ せてＤＳＰで動作させること，すなわち，ＤＳＰコードを生成し，ＤＳＰでマルチ メディアコンテンツの処理を行うことは，当業者であれば容易に想到し得るもので ある。そして，原告が上記において主張する本願補正発明の効果も，引用発明から 容易に想到し得る本願補正発明の構成から予測し得る効果にすぎず，格別顕著な効 果であると認めることはできない。 原告の上記主張は理由がない。 なお，原告は，本願補正発明では，コーデックライブラリだけでなく，ＯＳ，メ ディアフレームワーク及びハードウェアライブラリのソフトウェアを組み合わせて 新たな「ＤＳＰコード」を生成しているのに対し，引用発明の「デコーダ・コンポ ーネント管理エンジン」は「コアエンジン」に対して「デコーダモジュール」のみ を供給しているところ，この「デコーダモジュール」は，本願明細書の「コーデッ ク」に相当するものであり，新たなＤＳＰコードを生成する機能は有していない旨 主張するが，同主張に理由がないことは，上記において説示したとおりである。 (2) 原告は，引用例には，いくつかのＩＤＣＴモジュールの中でＤＳＰという「ハ ードウェア仕様…に適したＩＤＣＴモジュールを選択」することができると記載さ れているのであって，ＤＳＰで複数のＩＤＣＴモジュールを用いることができ，Ｉ ＤＣＴの変更を実施できる旨の記載はない旨主張する。 しかし，ＤＣＴ（Discrete Cosine Transform；離散コサイン変換）は，画像や動 画の圧縮を行う際に用いられる変換方法（アルゴリズム）であり，ＩＤＣＴ（Inverse Discrete Cosine Transform；逆離散コサイン変換）は，ＤＣＴで変換した信号を復 号するために逆変換を行う変換方法であるところ，ＤＳＰが様々な画像アルゴリズ ムに対応できるハードウェアであることは本願優先権主張日当時の技術常識である というべきであるから，引用例に，ＤＳＰが複数のＩＤＣＴモジュールを使用し， ＩＤＣＴの変更を実施できる旨の記載がないからといって，ＤＳＰが単一のＩＤＣ Ｔモジュールにしか対応し得ないものではないことは自明である。また，引用例に は，前記２ イ ア のとおり，画像圧縮アルゴリズムとしてＤＣＴが広く使われて いるが，ＤＣＴが全種類の画像に適しているわけではないことが記載され，また， 前記２(1)ア(イ)のとおり，デコーダを構成する画像圧縮アルゴリズムとして，ＤＣ Ｔのほかにウェーブレット等が例示されていることからすれば，当業者であれば， 引用発明におけるＤＳＰは，複数のＩＤＣＴモジュールに対応できるだけでなく， ＤＣＴ以外の他の画像圧縮アルゴリズムにも対応可能なものであることが，容易に 理解できるところである。 原告の上記主張は理由がない。 なお，原告は，引用例には，ハードウェア仕様に適したデコーダを選択すること は記載されていても，同一のハードウェア仕様について複数のデコーダを選択的に ダウンロードして用いることは記載されていない旨主張するが，同主張に理由がな いことは，上記において説示したところから明らかである。 原告は，引用例に，一体化したソフトウェアの課題認識があったとしても， それはシステム全体としての課題認識であり，ＤＳＰにおける課題認識が示唆され ているものではない旨主張するが，前記２(2)のとおり，引用発明は，モジュールベ ースのデコーダ（フレキシブルデコーダ）をモノリシックプログラムではなく複数 の機能を提供する複数のモジュールの集まりとして認識し，クライアントは，必要 なモジュールのみをダウンロードすることによりデコーダを構成するものであって， ソフトウェアを一体化したものとしてのみ認識するものではなく，また，前記(1) のとおり，ＤＳＰではデコーダとＯＳ等のソフトウェアを組み合わせて動作させる ものであるから，原告の上記主張は理由がない。 (4) 原告は，本願補正発明は，ＤＳＰに最適のＤＳＰコードを提供するため，Ｃ ＰＵ及びＤＳＰ間の連動構造を備えているのに対し，引用発明は，コアエンジンと してＤＳＰを採用する構成上の違いがある旨主張する。 しかし，前記３(2)ア(ウ)ａのとおり公知文献２（甲３）において，ＣＰＵで音楽 データのダウンロードを行い，ＤＳＰでコーデックプログラムを実行することによ り音楽再生を行うことが記載されていること（段落【００２３】【図３】【００２ ， ， ５】【００２６】【００２９】【００３０】 ， ， ， ）及び弁論の全趣旨によれば，ＣＰＵと ＤＳＰが連動して処理を行うことは，本願優先権主張日当時の周知技術であること が認められるから，引用発明において，ＣＰＵとＤＳＰが連動して処理を行うよう に構成することは，当業者であれば容易に想到し得るものである。 原告の上記主張は理由がない。 以上によれば，原告主張の取消事由４は理由がない。 ８ 結論 以上の次第であるから，原告主張の取消事由はいずれも理由がなく，本件審決の 判断に誤りはないから，本件審決にこれを取り消すべき違法は認められない。 よって，原告の本訴請求は理由がないから，棄却されるべきである。 知的財産高等裁判所第４部 裁判長裁判官 富 田 善 範 裁判官 大 鷹 一 郎 裁判官 田 中 芳 樹 |