平成２６年３月２６日判決言渡同日原本受領裁判所書記官
平成２４年（行ケ）第１０４０６号審決取消請求事件
口頭弁論終結日平成２６年２月２６日
判決
原告三星電子株式会社
訴訟代理人弁理士伊東忠彦
同伊東忠重
同大貫進介
同宮崎修
被告特許庁長官
指定代理人奥村元宏
同小池正彦
同樋口信宏
同山田和彦
主文
１ 原告の請求を棄却する。
２ 訴訟費用は原告の負担とする。
３ この判決に対する上告及び上告受理申立てのための付加期間を
３０日と定める。
事実及び理由
第１ 請求
特許庁が不服２０１０－２２１０２号事件について平成２４年７月９日にした審決を取り消す。
第２ 事案の概要
１ 特許庁における手続の経緯等
(1) 原告は，平成１９年４月２０日，発明の名称を「ソフトウェアモジュールの組合せによってＤＳＰコードを生成する装置及びその方法」とする発明（請求項の数７）について特許出願（特願２００７－１１１３３３号。パリ条約による優先権主張：平成１８年（２００６年）５月３日，優先権主張国：大韓民国。以下「本願」という。）をし，平成２２年１月２８日付けの拒絶理由通知を受けたことから，同年５月７日付け手続補正書（請求項の数７）を提出したが，同年５月２１日付けで拒絶査定を受けたため，同年１０月１日，これに対する不服の審判を請求し，併せて同日付け手続補正書により特許請求の範囲を補正した（請求項の数５，以下「本件補正」という。）（甲４，５，７～１０）。
(2) 特許庁は，前記(1)の請求を不服２０１０－２２１０２号事件として審理し，平成２４年７月９日，「本件審判の請求は，成り立たない。」との審決（以下「本件審決」という。）をし，その謄本は，同年７月２４日，原告に送達された。
(3) 原告は，平成２４年１１月２１日，本件審決の取消しを求める本件訴訟を提起した。
２ 本件審決が対象とした特許請求の範囲の記載
(1) 本願発明
本件補正前の特許請求の範囲の請求項１の記載は，平成２２年５月７日付け手続補正書（甲７）により補正された次のとおりのものである。以下，この請求項１に記載された発明を「本願発明」といい，本願に係る明細書（甲７）を「本願明細書」という。
【請求項１】
デジタルシグナルプロセッサ（ＤＳＰ）処理部と，
コーデックサーバから第１のソフトウェアモジュールをダウンロードする手段と，ダウンロードされた第１のソフトウェアモジュールと，少なくとも第２のソフト
ウェアモジュールとを記憶する記憶部と，
前記記憶された第１と第２のソフトウェアモジュールを組み合わせてＤＳＰコードを生成し，前記ＤＳＰ処理部にロードするＤＳＰコード生成部と，を有し，
前記ＤＳＰ処理部は前記ロードされたＤＳＰコードをデコーディングして，前記第１のソフトウェアモジュールに対応するマルチメディアコンテンツを処理することを特徴とする装置。
(2) 本願補正発明
本件補正後の特許請求の範囲の請求項１の記載は，次のとおりである（甲１０）。以下，この請求項１に記載された発明を「本願補正発明」という。なお，文中の下線部は，補正箇所を示す。
【請求項１】
デジタルシグナルプロセッサ（ＤＳＰ）処理部と，
コーデックサーバから第１のソフトウェアモジュールをダウンロードする手段と，ダウンロードされた第１のソフトウェアモジュールと，少なくとも第２のソフトウェアモジュールとを記憶する記憶部と，
前記記憶された第１と第２のソフトウェアモジュールを組み合わせてＤＳＰコードを生成し，前記ＤＳＰ処理部にロードするＤＳＰコード生成部と，を有し，
前記ＤＳＰ処理部は前記ロードされたＤＳＰコードをデコーディングして，前記第１のソフトウェアモジュールに対応するマルチメディアコンテンツを処理し，前記マルチメディアコンテンツは，前記コーデックサーバの位置情報と前記第１のソフトウェアモジュールの識別情報とを含み，
前記マルチメディアコンテンツに対応する前記第１のソフトウェアモジュールが前記記憶部に記憶されていない場合，前記コーデックサーバの位置情報と前記第１のソフトウェアモジュールの識別情報とに基づき，外部ネットワークに位置した前記コーデックサーバに前記第１のソフトウェアモジュールのダウンロードを要求するメッセージを生成及び伝送する制御部をさらに有することを特徴とする装置。
３ 本件審決の理由の要旨
(1) 本件審決の理由は，要するに，①本願補正発明は，下記アの刊行物（以下「引用例」という。）に記載された発明（以下「引用発明」という。），下記イ及びウの公知文献及び技術常識に基づいて，当業者が容易に発明をすることができたものであり，特許法２９条２項の規定により，特許出願の際独立して特許を受けることができないものであるから，本件補正は，平成２３年法律第６３号改正附則２条１８項によりなお従前の例によるとされる同法による改正前の特許法（以下「法」という。）１７条の２第６項において準用する法１２６条５項の規定に適合していないことから，特許法１５９条１項において読み替えて準用する同法５３条１項の規定により却下すべきものである，②本願発明は，引用発明及び技術常識に基づいて，当業者が容易に発明をすることができたものであるから，特許法２９条２項の規定により特許を受けることができない，というものである。
ア 引用例：“Naoto SHIMIZU, et al, A Novel Decoder-downloadable System forContent-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) 本件審決は，本願補正発明と引用発明との相違点４について，引用発明並びに公知文献１及び２（甲２，３）に記載された公知技術に基づいて，当業者であれば容易に想到できると判断したが，拒絶理由通知及び拒絶査定において，公知文献１及び２は何ら引用されておらず，上記各公知文献は審決において初めて示されたものであり，原告に対して，拒絶査定の理由と異なる新たな拒絶理由の通知はなく，意見書提出の機会も与えられなかった。したがって，本件審決には，特許法１５９条２項により準用される同法５０条に違反する違法があり，その違法は審決の結論に影響を及ぼすことが明らかである。
(2) 特許法１５９条２項前段は，同法５０条の規定を拒絶査定不服審判に準用することから，当該審判の審理において，審判長は，拒絶査定の理由と異なる拒絶の理由を発見した場合には，特許出願人（審判請求人）に対し，拒絶の理由を通知し，相当の期間を指定して，意見書を提出する機会を与えなければならない。
これに対し，同法１５９条１項後段及び２項後段は，同法５０条ただし書の規定により拒絶理由を通知することなく補正却下できる例外的な場合として，「１７条の２第１項…第４号（拒絶査定不服審判請求時の補正）に掲げる場合」を追加する規定となっていることから，特許出願人が拒絶査定不服審判を請求すると同時に特許請求の範囲を補正した場合において，その補正が同法１７条の２第３項ないし６項
の規定に違反するときは，拒絶理由が通知されずにいきなり補正却下され拒絶審決を受けることがある。
補正却下の理由が，新規事項追加違反（同法１７条の２第３項），技術的特徴変更違反（同法１７条の２第４項），限定的減縮違反（同法１７条の２第５項）のいわゆる補正要件違反である場合には，補正要件違反であることを特許出願人がある程度想定できる（補正要件違反は特許出願人の責任である場合もある）から，拒絶理由通知なく補正却下され拒絶審決がされても，受忍できる範囲といえる。しかし，拒絶査定不服審判を請求し，特許請求の範囲について拒絶査定の理由を解消するような限定を付加して補正をした特許出願人（審判請求人）に対する補正却下の理由が，特許出願人が想定し得ない新たな引用文献を引用した新たな拒絶の理由である独立特許要件違反の場合には，特許出願人に何ら責任はなく，かかる場合にまで意見書提出の機会を与えないことは，特許庁審判官による再度の審査（審理）を適正に受ける権利を，特許出願人から不当に奪うものである。
そもそも補正却下の対象を規定した特許法５３条は，拒絶査定を受けてもその後拒絶査定不服審判請求時に補正が可能である審査に関するものであり，拒絶査定不服審判における審理には当てはまらない。また，補正却下を適用する同法５０条ただし書は，いわゆる補正要件違反を念頭に置いたものである。さらに同法５３条及び５０条ただし書を拒絶査定不服審判における審理に準用した同法１５９条１項及び２項の立法趣旨は，拒絶査定不服審判請求時にした補正が新規事項を追加するものである場合において優先的に補正却下を適用することにあるのであって，拒絶査定不服審判請求時に原査定の拒絶理由を解消すべく請求項を減縮した補正を，意見書・補正書の提出機会を与えずに，新たな拒絶理由によって補正却下するような事態に適用することにあるのではない。上記によれば，同法１５９条１項及び２項は拒絶査定不服審判請求時にした補正が新規事項を追加するものである場合において優先的に補正却下を適用するために規定されたものであり，その立法過程において，拒絶査定不服審判請求時に原査定の拒絶理由を解消すべく請求項を減縮した補正が
新たな引用文献に基づく新たな拒絶理由によって，意見書・補正書の提出機会が与えられずに補正却下されてしまう事態は想定されていない。
したがって，拒絶査定不服審判請求時にした補正を，補正違反の態様にかかわらず一律に補正却下の対象とした同法１５９条１項後段及び２項後段の規定自体が立法の誤りであり，憲法３１条に反し違憲であって，本件審決もまた違憲な規定に則ったものであるから違憲である。
(3) また，本件のように拒絶査定不服審判請求時に原査定の拒絶理由を解消するために特許請求の範囲を減縮した補正を，新たな引用文献に基づく新たな拒絶理由で却下する場合には，審判合議体は，いきなり補正却下・拒絶審決をするのではなく，先ず拒絶理由を通知するとの運用をすることが，特許制度の趣旨及び憲法３１条に沿うものであるから，本件審決は，特許法１５９条１項後段及び２項後段の規定を適切に運用することを怠った違法性，違憲性がある。
(4) 被告は，特許出願人は，自らの判断で，多項制を活用して，出願時や最初の拒絶理由通知に対する補正により特許請求の範囲に記載すれば補正却下を回避できる旨主張するが，本件審決において初めて示された公知文献１及び２並びに補正却下の理由については，拒絶査定不服審判請求時に本件補正をするに当たっては知り得ないものであるから，自らの判断で補正却下を回避することはできなかったのであり，被告の上記主張は，特許実務からかけ離れた，補正制度を無視したものであり，失当である。
〔被告の主張〕
(1) 本件補正は，特許法１７条の２第１項４号に係る補正であるところ，特許法は，１５９条１項において読み替えて５３条１項の規定を準用し，１５９条２項において読み替えて５０条ただし書きを準用し，１７条の２第１項４号に係る補正（拒絶査定不服審判請求時の補正）を却下する場合には，拒絶理由を通知することを必要としていない。
本件審決が新たに公知文献１及び２（甲２，３）を挙げてした判断は，相違点４
についてしたものであり，相違点４に係る本願補正発明の構成は，「「マルチメディアコンテンツ」の中に，「コーデックサーバの位置情報」と「第１のソフトウェアモジュールの識別情報」が含まれる」であり，この構成は拒絶査定不服審判請求時の補正（本件補正）により新たに追加されたものであって，この追加は特許請求の範囲の減縮である。そして，本件審決は，この特許請求の範囲の減縮を目的とする本件補正について，法１７条の２第６項において準用する法１２６条５項の規定に適合していない，いわゆる独立特許要件に違反するとして，特許法１５９条１項において読み替えて準用する同法５３条１項の規定によって却下したもの，すなわち，特許法で拒絶理由を通知することを必要としない手続によって本件補正を却下したのであり，原告に拒絶理由を通知せず，意見書の提出機会を付与しなかったことについて本件審決に手続違背はない。
(2) 特許法１５９条２項後段の規定は，補正に関する他の改正項目と同様に，迅速・的確かつ公平な権利付与等の観点から設けられたものである。すなわち，各国経済の相互依存の進化に伴い特許制度の国際調和が検討されていたところ，我が国の特許制度については，補正回数や補正範囲の制限が不十分であるため，権利付与までの期間が長期化し，また，第三者の監視負担が過大になる等の問題が指摘されていた。そこで，平成５年法律第２６号では，２回目（最後）の拒絶理由通知以降の補正に対して，独立特許要件も含めて補正の範囲の適正化を図り，また，拒絶理由の通知について同法５０条ただし書の規定が設けられるとともに，不適法な補正は却下することとして同法５３条１項ないし３項の規定が設けられ，拒絶査定不服審判についても，迅速な権利付与の実現，出願間の公平な取扱い等の観点から，同様の改正がされた（同法１７条の２，１５９条）。
原告は，この点について，同法１５９条２項後段の立法趣旨は，拒絶査定不服審判請求時にした補正が新規事項を追加するものである場合に，補正却下を適用することにあると主張する。しかし，同法１５９条２項後段の立法趣旨は，審判請求時の補正が不適法である場合の取扱いを，最後の拒絶理由通知に対する補正が不適法
である場合の取扱いと同様のものとすることによって，審理を迅速化し，第三者の監視負担を軽減することにある。すなわち，同法１５９条２項後段の規定は，新規事項を追加する補正のみを却下することを想定したものではなく，目的外の補正や独立特許要件違反の補正についても却下することを想定したものである。このように，同法１５９条２項後段の規定は，不適法な審判請求時の補正を却下することによって審理を迅速化し，第三者の負担を軽減するものであって，新しい技術を公開した者（出願人）に対して迅速に権利を付与して発明を保護することと，権利の制約を受ける第三者の利用を促すこととのバランスを図ったものであるから，特許法の目的にも合致するものであって，憲法３１条に反するものではない。
(3) 拒絶査定不服審判は，審査に対する続審である（特許法１５８及び１５９条）から，審判合議体は，審査においてした手続を土台として審理を続行し，新たな資料をも補充し，拒絶査定が維持できるかどうかを審理するものであるから，審判請求人は，審判合議体に対し拒絶査定が不服である理由を述べ，拒絶査定の妥当性について審理を受けることができる。
しかし，審判請求時に特許請求の範囲を拡張，変更する補正がされると，審理対象が変更されるため新たな審理を行わざるを得なくなり，公平性を欠くことになるのみならず，他の審判請求事件の審理の遅延をも生じるおそれがある。また，審判請求時の補正が特許請求の範囲の減縮に相当する補正であるとしても，補正後の発明が特許可能なものであれば，拒絶査定を取り消して特許査定すれば良く，審理が繰り返し行われることを回避することができるが，補正後の発明が特許できないものについて，仮に，審判において再度，拒絶の理由を通知し，審判請求人に意見書・補正書を提出する機会を与えたならば，審理が繰り返し行われることを回避できなくなる。また，仮に，審判請求人がこの機会を活用して出願を分割したならば，分割された出願について最初から審査がやり直されることとなり，しかも，第三者の監視負担が新たに発生する。さらに，出願前に十分な先行技術調査を行い予め高品質な特許請求の範囲及
び明細書を作成し，多項制を積極的に活用して１回以下の拒絶理由通知で特許性を見極め，審判請求前に迅速に権利を取得しようとしている他の出願人との公平性の観点からも問題がある。特許出願人にとっても，十分な先行技術調査，多項制の活用等に対するインセンティブが損なわる結果，迅速・的確な権利取得の確率が低下する。そもそも，同法５０条には補正却下するときに拒絶理由の通知を要しない旨の規定はあるが，同法５３条には拒絶理由を通知するときに補正却下を要しない旨の規定はない。万が一，補正却下せず拒絶理由を通知する運用としたならば，審判請求人は不適法な補正の範囲内で補正する不利益を被り，補正却下しなかったことについて，審判合議体の処分の違法性を問うことができる。また，仮に，補正却下せず拒絶理由を通知する運用としたならば，審判請求人は，審判請求時に拒絶理由を内在する不適法な減縮補正を行っただけで，特許庁に対し最初から審査（審理）をやり直させることができるようになる。原告が主張する運用は，実質的に，審判請求の段階になってから審査を再スタートさせることを強いる運用であり，審理期間の遅延を招き，第三者の監視負担を増大させるだけである。
以上のとおりであるから，審判請求時の補正が，単に，拒絶査定の理由を解消すべく特許請求の範囲を減縮した補正であることをもって審判において再度，拒絶の理由を通知するという運用を採用することは，迅速・的確かつ公平な権利付与を図るという前記(2)の平成５年法律第２６号による改正の趣旨に合致しない。
(4) 特許出願人は，自らの判断で，多項制を活用して，特許を受けようとする発明について特許請求の範囲に請求項毎に記載し，本件のような補正却下を回避することができる。本件でいえば，原告は，本件補正により追加された「「マルチメディアコンテンツ」の中に，「コーデックサーバの位置情報」と「第１のソフトウェアモジュールの識別情報」が含まれる」との構成を含む発明を，出願時にあらかじめ特許請求の範囲に記載していたならば，平成２２年１月２８日付け拒絶理由通知の段階で，同構成についても審査を受けることができたし，あるいは同拒絶理由通知に
対する手続補正で特許請求の範囲に記載していたならば，審査官から最後の拒絶理由通知を受けることができた。したがって，原告が主張する特許出願人にとっての不利益は，多項制を活用することにより回避可能であるから，特許出願人に何ら責任がないとはいえない。
また，新たな引用文献を引用した２９条２項の規定により独立特許要件を満たさないとの理由により補正が却下されることは，制度上予定されていることであるから，特許出願人にとって全く想定できないものでもない。
２ 取消事由２（本願補正発明と引用発明との一致点の認定の誤り，相違点の看過）について
〔原告の主張〕
(1) 本件審決は，引用発明の「クライアント」と本願補正発明の「装置」とは，「前記マルチメディアコンテンツに関する前記コーデックサーバの位置情報と前記コーデックのバイナリデータの識別情報とが用いられ」ること，及び「前記コーデックサーバの位置情報と前記コーデックのバイナリデータの識別情報とに基づき，」外部ネットワークに位置した前記コーデックサーバに前記コーデックのバイナリデータのダウンロードを要求するメッセージを生成及び伝送することを一致点として認定した。
(2) しかし，引用発明において，「前記マルチメディアコンテンツに関する前記コーデックサーバの位置情報と前記コーデックのバイナリデータの識別情報とを用い」る主体は，情報サーバであって，クライアントではない。本願補正発明の「装置」は，引用発明の情報サーバに対応するものではなく，クライアントに対応するものである。そうすると，本件審決が一致点として認定した「前記マルチメディアコンテンツに関する前記コーデックサーバの位置情報と前記コーデックのバイナリデータの識別情報とが用いられ」は，引用発明の「クライアント」と本願補正発明の「装置」との一致点とはなり得ないから，本件審決は一致点の認定を誤り相違点を看過している。
また，引用発明において，「前記コーデックサーバの位置情報と前記コーデックのバイナリデータの識別情報」を知っているのは，情報サーバであって，クライアントではない。一方，本願補正発明の「装置」においては，「前記マルチメディアコンテンツ」に含まれた「前記コーデックサーバの位置情報と前記第１のソフトウェアモジュールの識別情報とに基づき」，第１のソフトウェアモジュールのダウンロードを要求するのは，「装置」内部の制御部であって，サーバ側ではない。そうすると，本件審決が一致点として認定した「前記コーデックサーバの位置情報と前記コーデックのバイナリデータの識別情報とに基づき」は，引用発明の「クライアント」と本願補正発明の「装置」との一致点とはなり得ないから，本件審決は一致点の認定を誤り相違点を看過している。
(3) 以上のとおり，本件審決は，前記相違点を看過することにより，誤って本願補正発明の進歩性を否定したものであるから，取り消されるべきである。
〔被告の主張〕
(1) 本件審決が一致点として認定した「コーデックサーバの位置情報」及び「コーデックのバイナリデータの識別情報」は，それぞれ引用発明における「デコーダＵＲＩ」及び「対応する最適なデコーダ情報」であり，引用例において，「デコーダＵＲＩ」（「コーデックサーバの位置情報」）と，「対応する最適なデコーダ情報」（「コーデックのバイナリデータの識別情報」）とは，クライアントが外部（情報サーバ）から取得して，クライアントにおいてダウンロードに用いられる。他方，本願補正発明の装置は，マルチメディアコンテンツに含まれる「コーデックサーバの位置情報」と「第１のソフトウェアモジュールの識別情報」とをマルチメディアコンテンツとともに取得しダウンロードに用いる。
そうすると，これら情報をダウンロードに用いているという観点で，本件審決が，「前記マルチメディアコンテンツに関する前記コーデックサーバの位置情報と前記コーデックのバイナリデータの識別情報とが用いられ」ていることを，引用発明の「クライアント」と本願補正発明の「装置」との一致点としたことに誤りはない。
(2) 原告は，引用発明において，「前記コーデックサーバの位置情報と前記コーデックのバイナリデータの識別情報」を知っているのは，情報サーバであって，クライアントではないと主張するが，上記のとおり，引用例では，情報サーバが知っている情報をクライアントが得て用いるのであり，クライアントが情報を得る情報源が情報サーバであるとしても，クライアントにおいて，「前記マルチメディアコンテンツに関する前記コーデックサーバの位置情報と前記コーデックのバイナリデータの識別情報とが用いられ」ているといえるものである。
３ 取消事由３（本願補正発明と引用発明との相違点４に係る判断の誤り）について
〔原告の主張〕
(1) 本件審決は，本願補正発明と引用発明との相違点４について，引用発明では，「コンテンツ」の中に「デコーダＵＲＩ」と「デコーダ情報」が含まれるものとはされておらず，「コンテンツ」とは別に，情報サーバから，「デコーダＵＲＩ」と，各コンテンツに対応する「デコーダ情報」が提供されるものであるが，コンテンツとともにデコーダをダウンロードするためのサーバの位置情報を提供することや，コンテンツの中にデコーダを識別するための情報が含まれるようにすることは，公知文献１及び２に開示されているように既に知られた考え方であるから，引用発明における「デコーダＵＲＩ」及び「デコーダ情報」に，上記公知技術に係る考え方を採用することで，本願補正発明のように，「マルチメディアコンテンツ」に「コーデックサーバの位置情報」と「コーデックの識別情報」を含むように構成することは，当業者であれば容易に想到できる旨判断した。
(2) しかし，公知文献１（甲２）には，デコーダ全体ではなく，そのうちの一部に相当する第１のソフトウェアモジュールのみをダウンロードするためのコーデックサーバの位置情報がディスクに含まれているという記載はない。公知文献１記載の技術を引用発明に組み合わせて本願補正発明の進歩性を否定するためには，公知文献１において，単にデコーダが存在するウェブサイトのＵＲＬでは足りず，デコ
ーダ全体のうちの一部に相当する第１のソフトウェアモジュールのみをダウンロードするためのコーデックサーバの位置情報がディスクに含まれている必要がある。したがって，仮に公知文献１記載の技術を引用発明に適用できたとしても，本願補正発明には至らない。
(3) 公知文献２（甲３）においても同様に，仮にデコーダを識別するための情報がコンテンツに含まれているという技術が公知文献２に記載されていたとしても，デコーダ全体ではなく，そのうちの一部に相当する第１のソフトウェアモジュールのみの識別情報がコンテンツに含まれているという記載はない。公知文献２記載の技術を引用発明に組み合わせて本願補正発明の進歩性を否定するためには，公知文献２において，単にデコーダの識別情報では足りず，デコーダ全体のうちの一部に相当する第１のソフトウェアモジュールの識別情報がコンテンツに含まれている必要がある。
したがって，仮に公知文献２記載の技術を引用発明に適用できたとしても，本願補正発明には至らない。
(4) 本願補正発明の「ソフトウェアモジュール」は，ＯＳ，コーデックライブラリ，メディアフレームワーク及びハードウェアライブラリを含む（本願明細書の段落【００２９】）。そして，本願補正発明は，「第１と第２のソフトウェアモジュールを組み合わせてＤＳＰコードを生成」することを要件としているから，例えば，「第１のソフトウェアモジュール」がメディアフレームワークであり，「第２のソフトウェアモジュール」がハードウェアライブラリである場合も包含する。
他方，引用発明においてダウンロードされる「デコーダモジュール」は，本願明細書の「コーデック」（コーデックライブラリの一要素）に相当する。
そうすると，本件審決が相違点２として判断した「モジュールのみをダウンロードする点」及び「得ようとする各情報が「モジュール」を対象としたものとすること」とは，引用発明における「デコーダモジュール」，すなわちコーデックライブラリについて判断したものにすぎず，コーデックライブラリ以外の本願補正発明の「ソ
フトウェアモジュール」であるＯＳ，メディアフレームワーク及びハードウェアライブラリについては，何も判断していない。
(5) 本願補正発明では，「前記マルチメディアコンテンツは前記コーデックサーバの位置情報と前記第１のソフトウェアモジュールの識別情報を含み」及び「前記コーデックサーバの位置情報と前記第１のソフトウェアモジュールの識別情報とに基づき」の要件を満たしているために，装置側からサーバ側に対して「コーデックサーバの位置情報と第１のソフトウェアモジュールの識別情報」を要求することなく，マルチメディアコンテンツ自体に内在する「コーデックサーバの位置情報と第１のソフトウェアモジュールの識別情報」をそのまま利用すれば足りる。
これに対して，引用発明においては，「クライアントが対応するデコーダを有していない場合には，スケジューラー管理エンジンは，デコーダＵＲＩを得ることをデコーダ・コンポーネント管理エンジンに指示する。デコーダ・コンポーネント管理エンジンは，どこにデコーダが格納されているかをコンテンツサーバに要求する」のであって，本願補正発明には，このような要求を必要としないという効果がある。〔被告の主張〕
(1) 本件審決は，相違点４に係る本願補正発明の構成として「「マルチメディアコンテンツ」の中に，「コーデックサーバの位置情報」と「第１のソフトウェアモジュールの識別情報」が含まれる」としているところ，モジュールのみをダウンロードする点については，相違点２として判断し，相違点４は，そのような相違の下で，本願補正発明が「「マルチメディアコンテンツ」の中に，「コーデックサーバの位置情報」と「第１のソフトウェアモジュールの識別情報」が含まれる」ことを相違点として挙げたのであって，ダウンロードに用いる情報を取得する手法について判断したもの，すなわち，公知文献１及び２は，ダウンロードに際して必要となる，「どこから」「何を」の各情報を取得する手段として，各情報をコンテンツに含ませてコンテンツとともに得る構成を容易というために用いている。
すなわち，得ようとする各情報が「モジュール」を対象としたものとすることは，
相違点２で判断した上で，さらに，相違点４について，公知文献１及び２の「コンテンツとともに，デコーダをダウンロードするためのサーバの位置情報を提供すること」及び「コンテンツの中にデコーダを識別するための情報が含まれるようにすること」という公知技術を組み合わせることで，本願補正発明の「「マルチメディアコンテンツ」の中に，「コーデックサーバの位置情報」と「第１のソフトウェアモジュールの識別情報」が含まれる」とすることは容易であると判断したものである。
(2) 本願補正発明は，マルチメデイアコンテンツの符号化の仕組みが異なる場合，それを復号するために必要な復号プログラムを得るために，復号プログラム全体（全体プログラム）をダウンロードするのではなく，「全体プログラム」を構成する各プログラム（部分プログラム）の中で異なる符号化の仕組みに必要な「部分プログラム」のみをダウンロードするというものである。
本件審決は，「全体プログラム」をダウンロードするのではなく，「部分プログラム」をダウンロードすることについては，相違点２において，本願補正発明の「ソフトウェアモジュール」，すなわち，部分プログラムとして「第１のソフトウェアモジュール」をダウンロードする点について判断しているのであるから，本件審決が「本願補正発明の「ソフトウェアモジュール」については何も判断していないとする原告の主張は理由がない。
(3) 原告は，本願補正発明は，各情報がコンテンツに含まれ，コンテンツとともに得ることができるから，引用発明のようにクライアントからサーバにコンテンツとは別に各情報を要求する必要がないとの効果がある旨主張するが，相違点についてした判断の結果として容易に想到される構成から予測されるものであり，この効果により特許を受けることができるとはいえない。
４ 取消事由４（本願補正発明と引用発明との相違点１及び２に係る判断の誤り）について
〔原告の主張〕
(1) 本件審決は，本願補正発明と引用発明との相違点１について，引用発明にお
ける「コアエンジン」について，引用例における記載に基づいて，ＤＳＰによるハードウェアを採用することによって，本願補正発明のように，「デジタルシグナルプロセッサ（ＤＳＰ）処理部」とすることや，引用発明における実行コードを，本願補正発明のように，「ＤＳＰコード」とすることは，当業者であれば容易に想到できる旨判断した。
また，本件審決は，本願補正発明と引用発明との相違点２について，引用発明において，「デコーダ情報」に基づき，「デコーダのバイナリデータ」をダウンロードして記憶し，「デコーダ」に対応するメディア又はコンテンツが再生される構成について，引用例に開示されるような，デコーダが複数のモジュールにより構築されるモジュールベースデコーダの考え方を採用し，モジュールに対応するメディアコンテンツやモジュール識別情報の構成，複数のデコーダモジュールを組み合わせてデコーダを生成する手段を設けることによって，本願補正発明のように，「ソフトウェアモジュールの識別情報」に基づきダウンロードして記憶し，記憶された複数の「ソフトウェアモジュール」を組み合わせてコーデックのコードを生成し，「ソフトウェアモジュール」に対応するマルチメディアコンテンツを処理するようにすることは，当業者であれば容易に想到できる旨判断した。
(2) しかし，引用発明では“core engine”にデコーダを設置しており，“coreengine”はメディア再生又は中止などを制御するＣＰＵに該当するから，引用発明のデコーダダウンロード及び設置に関するソフトウェアはＣＰＵ上で動作するソフトウェアであって本願補正発明のＤＳＰコードとは異なる。引用発明には，コンポーネント化されているソフトウェアによりデコーダを形成する一部モジュールに対する変更を行う構成が開示されているかもしれないが，ＯＳなどの実行環境が劣悪であるというＤＳＰの特性上コンポーネント化されていないソフトウェアを備えるしかないＤＳＰに対し，新規コーデックが要求される際にコーデックを変更するために最小限の資源を用いてＤＳＰ規格に合うＤＳＰコードを容易に提供することについては，引用例にはいかなる開示も示唆もない。
これに対して，本願補正発明は，コンポーネント化されたソフトウェアの使用が容易ではないＤＳＰによりコーデックを支援する回路環境で新規コーデックが要求されるたびに大容量のＤＳＰコードを適用及び交替することにより発生する相当量のオーバーヘッドを最小化するため，コンテンツを再生するたびにリアルタイムでＣＰＵ(ＤＳＰコード生成部)で適切なコーデックライブラリを選択するようにした後，選択されたコーデックライブラリとＯＳ及びメディアフレームワークを組み合わせてＤＳＰコードを生成し，生成されたＤＳＰコードをＤＳＰ処理部に提供し，ＤＳＰ処理部では提供されたＤＳＰコードに基づいてコンテンツを再生するためのデコーディングを行うことにより，ＤＳＰはコンテンツを再生するたびにＣＰＵからＤＳＰコードを提供される構成としたものであり，かかる構成，効果を検討せずに相違点１及び２について容易想到であると判断した本件審決は誤りである。
(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）及び最適なデコーダ（optimumdecoder）等の情報から構成されることが記載されている。）
【図３】
クライアントシステムはＪａｖａを用いて実装する。メディア処理の部分はＪＭＦ（JavaMedia Framework）を用いて開発されている。こうしたのは，提案するシステムが様々な環境で動作しなければならないからである。現時点は，Ｊａｖａを用いてメディア処理の部分を構成することには多少の疑問がある。そのため，ＪＭＦに依存するメディア処理をするモジュール
は他の部分から完全に取り外せるように，システムアーキテクチャを設計した。しかし，Ｊａｖａにより開発したデコーダは，サーバがクライアントのオペレーティングシステムの種類を心配しなくて良いとのメリットが得られる。これらのデコーダはフレキシブルデコーダとしても有用である。
ＣＯＲＢＡ（Common Object Request Broker）は，サーバとクライアントとの間の，ハードウェアの仕様とは独立であるインタフェースの規定に用いられる。さらに，このシステムは，ＣＯＲＢＡＧＩＯＰ（General Inter-ORB Protocol）により，どのトランスポートプロトコルからも独立している。それゆえ，このシステムは，インターネット，テレビ放送，モバイルシステムなどで利用できる。
ｂ このシステムのプロシージャは次の順序で実行される：
(a) クライアントシステムのスケジューラ管理エンジンがスタートし，コンテンツ情報を取得する。このエンジンがコンテンツ情報を解析し，デコーダコンポーネント管理エンジンに，クライアント側にデコーダがあるかどうか確認する。
(b) クライアントが対応するデコーダを有していない場合，スケジューラ管理エンジンはデコーダコンポーネント管理エンジンにデコーダＵＲＩを取得するように命令する。デコーダコンポーネント管理エンジンは，コンテンツサーバに，デコーダがどこに記憶されているか要求する。
(c) 情報サーバは，デコーダ情報を用いて，要求されたデコーダがどこに記憶されているか探し始める。クライアントにデコーダＵＲＩを返す。
(d) スケジューラ管理エンジンは，デコーダサーバからのデコーダのダウンロードを何時開始するか決定し，デコーダコンポーネント管理エンジンに命令する。この命令をするタイミングは非常に重要である。何故なら，ネットワークの帯域幅が狭い場合などに，デコーダのダウンロードにより連続的なメディア再生が中断されるからである。
ｃ システム中の各パーツの役割は次のとおりである：
・コアエンジン
このパーツは，メディア再生やトリックモードなどの実装を提供する。デコーダは実際には
このパーツにインストールされる。
・デコーダコンポーネント管理エンジン
このパーツは，クライアントシステム中のデコーダを管理し，どのデコーダが必要か問い合わせ，デコーダをダウンロードし，ストックされているデコーダを削除する。
・スケジュール管理エンジン
このパーツは，メディア再生を何時開始するか，デコーダを何時ダウンロードするか，又はデコーダを何時削除するか制御する。実際の機能を提供する各パーツに，タイムリーに命令する。
・ユーザインタフェース
このパーツはユーザ入力のインタフェースである。
・ファイルＩ／Ｏ
このパーツは，その使用目的に基づきプロトコルを選択する：１）ＣＯＲＢＡ，コンテンツ情報の送受信，２）ＨＴＴＰ／ＦＴＰ，デコーダのバイナリデータのダウンロード，３）ＲＴＰ／ＭＰＥＧ２－ＴＳ，メディアデータの受信。
ｄ システム中の各インタフェースを以下に説明する：
インタフェース１：デコーダに関する情報の交換
インタフェース２：コンテンツに関する情報の交換
インタフェース３：デコーダのバイナリデータのダウンロード
インタフェース４：コンテンツのメディアデータのダウンロード
インタフェース５：クライアントのスケジューラで用いられるＥＰＧ（電子番組案内）のダウンロード
インタフェース６：コアエンジンへのデコーダモジュールの供給
インタフェース７：デコーダのメモリへのロードが何時始まるか示し，メモリロードがどの状態にあるかに関する情報を提供
インタフェース８：デコーダが追加されるのか削除されるのかをユーザに示す
インタフェース９：コンテンツに関する情報を提供し，クライアントシステムにおいてデコ
ーダのダウンロード及び削除を何時開始するか示し，デコーダの存在を
確認
インタフェース１０：ユーザによる入力情報の受け取り
インタフェース１１：再生可能なコンテンツの情報の表示，ユーザによるコンテンツの選択…（略）…
エ フレキシブルデコーダ
(ア) 機能
フレキシブルデコーダにより，モノリシックプログラムとして扱われず，複数の機能を提供する複数のモジュールの集まりとして扱われるアーキテクチャが可能となる。フレキシブルデコーダは，ＭＰＥＧ－４システムにおける標準化で検討されたことがある。ＭＰＥＧ－４は，効率的な圧縮だけでなくユーザのコンテンツベースの操作などの機能を提供する柔軟かつ拡張可能なアーキテクチャを確立するように設計された。フレキシブルデコーダアーキテクチャは，ＭＰＥＧ－４システムの標準には含まれないが，このアーキテクチャにより，新しいタイプのメディアコンテンツが届いた時に，クライアントが，必要なモジュールのみをダウンロードすることによりデコーダを構成できる。このアーキテクチャにより，デコーダをダウンロードするためのネットワーク帯域幅とクライアント又はサーバのリソースを削減できる。それゆえ，デコーダダウンロードシステムにおいてフレキシブルデコーダを用いると効率的である。
(イ) フレキシブルデコーダへのアプローチ
先行文献はフレキシブルデコーダのための方法を示している。この文献に基づきデコーダを開発することにより，復号プロセスが継続中に，ユーザがＤＣＴやウェーブレットなどの画像処理アルゴリズムを変更できる。デコーダの機能の分離は，３コンポーネントモデルにより実現できる。３コンポーネントモデルは，デコーダが，図５に示した，①ビットストリーム解析ブロック，②データ再生ブロック，及び③画像再構成ブロックに分かれることを意味する。ビットストリーム解析ブロックは，ビットストリームをそのシンタックスに従って解析する。画像再構成ブロックは，実際の画像復号アルゴリズムを提供する。データ再生ブロックは，ビットストリーム解析ブロックと画像再構成ブロックとの間の分離で重要な役割を有する。データ
再生ブロックは画像再構成ブロックに対してデータアライメントを提供する。これは，データ再生ブロックと画像再構成ブロックとの間の変換プロセスと考えることができる。結果として，データ再生ブロックがあることにより，一方の側での変更が他方の側に影響しなくなる。このデコーダアーキテクチャは，フレキシブルデコーダにとって非常に有用であると思われる。しかし，デコーダをモノリシックプログラムとして開発することを意味する従来の方法と比べて，このアーキテクチャに従ってデコーダを開発することは，より難しくなる。【図５】
(ウ) ビットストリーム解析からの画像処理の分離
この提案では，ビットストリーム解析するモジュールは，画像を復号するモジュールから完全に分離される。これにより，デコーダは，同じ画像復号アルゴリズムのための様々なモジュールを用いられる。例えば，クライアントのハードウェア仕様（ＭＭＸ，３ＤＮｏｗ！，ＤＳＰ，ＡＳＩＣなど）に適したＩＤＣＴモジュールを選択して，同じビットストリーム解析を共有できる。デコーダ・ダウンロード可能システムは，メディア処理のみならずサーチエンジンなどの様々なマルチメディアシステムに使うことができる。この柔軟性は，単に画像復号アルゴリズムのモジュールを他のプロセスのもので置き換えることにより実現できる。分離をより柔軟にするため，Ｊａｖａなどのクライアントに依存しないデコーダソフトウェアを利用する。…（略）…
オ 結論
本論文では，コンテンツ指向の符号化方式のための新しいシステムアーキテクチャを提案した。このシステムにより，クライアントとサーバとの間のネゴシエーションにより，デコーダ
を動的にダウンロードすることができる。それゆえ，クライアントは，画像符号化方式に関する知識がなくてもコンテンツを復号でき，メディアコンテンツを途切れなしに再生できる。このシステムは，ＪａｖａとＣＯＲＢＡにより開発されたので，移植性に優れている。デコーダをフレキシブルデコーダとして開発すれば，デコーダ・ダウンロード可能システムにとって有用であると言える。ＭＳＤＬ－Ｓを用いてビットストリーム解析を他の処理から分離する方法も提案した。
(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）３２，出力増幅器３３，ＥＥＰＲＯＭ（ElectricallyErasable 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) 原告は，本件審決は，本願補正発明と引用発明との相違点４について，引用発明並びに公知文献１及び２（甲２，３）に記載された公知技術に基づいて，当業者であれば容易に想到できると判断したが，拒絶理由通知及び拒絶査定において，公知文献１及び２は何ら引用されておらず，上記各公知文献は審決において初めて示されたものであり，原告に対して，拒絶査定の理由と異なる新たな拒絶理由の通知はなく，意見書提出の機会も与えられなかった。したがって，本件審決には，特許法１５９条２項により準用される同法５０条に違反する違法があり，その違法は審決の結論に影響を及ぼすことが明らかである旨主張する。
しかし，特許法１５９条１項後段，同法５３条１項，同法１７条の２第１項４号，法１７条の２第６項及び法１２６条５項によれば，拒絶査定不服審判を請求する場合において，その審判の請求と同時にした補正が，補正後における特許請求の範囲に記載されている事項により特定される発明が特許出願の際独立して特許を受けることができないものである場合には，審判合議体は，決定をもって当該補正を却下しなければならず，この却下の決定をする場合には，特許法１５９条２項後段，同法５０条ただし書及び特許法１７条の２第１項４号により，審判合議体は，拒絶査定不服審判において査定の理由と異なる拒絶の理由を発見したときであっても，特許出願人に対して，拒絶の理由を通知して意見書提出の機会を与える必要はないと解される。
これを本件についてみると，本件審決は，拒絶査定不服審判の請求と同時にされた本件補正により特定された本願補正発明について，引用発明，公知文献１及び２に記載の公知技術並びに技術常識に基づいて当業者が容易に発明をすることができたものであり，特許法２９条２項により，特許出願の際独立して特許を受けることができないものであることを理由として，本件補正を却下しており，上記のとおり，この場合には改めて拒絶の理由を通知して意見書提出の機会を与える必要はないと解されるから，本件審決の手続に違法はない。
原告の上記主張は理由がない。
(2) 原告は，拒絶査定不服審判を請求し，特許請求の範囲について拒絶査定の理由を解消するような限定を付加して補正をした特許出願人（審判請求人）に対する補正却下の理由が，特許出願人が想定し得ない新たな引用文献を引用した新たな拒絶の理由である独立特許要件違反の場合には，特許出願人に何ら責任はなく，かかる場合にまで意見書提出の機会を与えないことは，特許庁審判官による再度の審査（審理）を適正に受ける権利を，特許出願人から不当に奪うものであること，そもそも特許法１５９条１項及び２項の立法趣旨は，拒絶査定不服審判請求時にした補正が新規事項を追加するものである場合において優先的に補正却下を適用することにあるのであって，拒絶査定不服審判請求時に原査定の拒絶理由を解消すべく請求項を減縮した補正を，意見書・補正書の提出機会を与えずに，新たな拒絶理由によって補正却下するような事態に適用することは想定されていないのであるから，拒絶査定不服審判請求時にした補正を，補正違反の態様にかかわらず一律に補正却下の対象とした同法１５９条１項後段及び２項後段の規定自体が立法の誤りであり，憲法３１条に反し違憲であって，本件審決もまた違憲な規定に則ったものであるから違憲である旨主張する。
特許法１５９条１項後段及び２項後段は，平成５年法律第２６号により規定されたものであることから，その立法経緯等について検討するに，従前の特許法においては，特許請求の範囲の補正については，出願公告の決定謄本の送達前に出願当初の明細書に記載された事項の範囲内において特許請求の範囲を増加，減少又は変更する補正は，明細書の要旨を変更しないものとみなすと規定されているのみであったことから，拒絶理由通知後であっても，特許請求の範囲の拡張，変更等の補正を行うことが許容されていたのみならず，特許請求の範囲の補正の回数も制限されていなかったため，一つの出願において拒絶理由が通知されるたびに特許請求の範囲の補正を行うことも許容されていた。そして，このような補正がされた場合には，審査対象が変更されるため，そのたびに新たな先行技術の調査及びその結果に基づく対比判断等の新たな審査を行わざるを得なかったが，実際の出願において何回も
特許請求の範囲についての補正が行われた場合は，出願間の取扱いに公平性を欠くことになるのみならず，このような出願が存在することにより，他の出願の審査の遅延をも生じるおそれがあるという弊害が生じていた。さらに，第三者にとっては，出願公開後に補償金請求権が発生するにもかかわらず，特許請求の範囲の補正が何回も行われることにより，特許が付与がされる対象が何回も変更されることとなり，その監視負担が過大となるという弊害も生じていた。そこで，平成４年１２月にとりまとめられた工業所有権審議会の答申（以下「審議会答申」という。）においては，昭和６３年に我が国の特許法に主要国と同様の多項制が既に導入されており，その利用も拡大しつつあること等も踏まえ，出願公告の決定謄本送達前の特許請求の範囲の補正について，制度及び審査実務等の運用の国際的調和，出願間の取扱いの公平性及び迅速な権利付与等の観点から適正化を図るべきであるとされた。
また，従前の特許法においては，出願公告の決定謄本の送達前に拒絶査定不服審判を請求する際には，特許請求の範囲の拡張，減縮，変更を含めた広範な補正を行うことが認められているとともに，審判請求時に補正がされた場合には，審査前置制度により，審査官が再度審査を行い，拒絶査定の対象となった請求項が削除される等，拒絶査定をした理由が解消されている場合には，審査官に拒絶査定を取り消す機会が与えられていた。この審査前置制度の趣旨は，審判請求時に補正がされた場合は，審判合議体による審理の前に審査官に再度審査をさせることにより，審査段階において得られた調査結果や出願内容の知識を活用し，出願内容の理解や調査に要する時間を節約して処理を行うことにあった。しかしながら，審査前置制度は，我が国の特許法が単項制を採用していた頃に導入されたものであり，拒絶査定不服審判請求時に特許請求の範囲の拡張，変更を行う補正も許容されていたことから，そのようは補正がされた場合は，拒絶査定を受けた発明とは別の発明について，審査官による再度の審査（または審判官による審理）が行われることとなり，その結果，もとの審査における審理の手続や結果が軽視され，新たに最初から審理がし直されることともなりかねなかったことから，審理の迅速性及び的確性が十分に確保
され難いという問題を有していた。また，拒絶査定不服審判請求時に，特許請求の範囲を拡張，変更する補正がされると，多項性の利用が拡大しつつある状況においては，多項制を有意義に活用し，特許請求の範囲の請求項の削除等の補正のみを行う出願との間において，出願の取扱いの公平性が担保されないこととなっていたのみならず，前者の出願が存在することにより，後者の出願の審理が遅延するという弊害をも生じていた。このため，審議会答申においては，拒絶査定不服審判における補正の範囲に関する主要国の制度及び運用も考慮しつつ，行政処分である拒絶査定の瑕疵の是正をより迅速，的確かつ公平に行うため，出願公告の決定謄本送達前の拒絶査定不服審判の請求時における補正の範囲の適正化を行うべきであるとされた。
そこで，平成５年法律第２６号において，最後の拒絶理由通知に対する補正について，明細書及び図面に新規事項を追加しないものであるほか，特許請求の範囲の減縮に当たる補正がされた場合においても，補正後の発明が独立して特許を受けることができるもののみを許容すること（独立特許要件）を含めて補正の範囲の適正化を図るべく特許法１７条の２の規定が整備され，拒絶理由の通知について同法５０条ただし書の規定が設けられるとともに，不適法な補正は却下することとして同法５３条１項ないし３項の規定が設けられた。このように，最後の拒絶理由通知に対する補正が独立特許要件を含めて特許法１７条の２の規定に違反する不適法なものであることが出願公告の決定謄本の送達前に認められた場合に，拒絶理由を通知することなく当該補正を却下することとした理由は，補正により特許可能となる発明については補正を認めることによって迅速に権利付与を行うことが出願人の利益となるのに対し，補正後の発明が特許性を有しない場合に再度拒絶理由を通知することとした場合には拒絶理由通知に対して再度の補正が可能であるため，審査官は当該補正について再度審査する必要があり，審査の迅速性が十分に確保され難く，出願間の取扱いの公平性を欠くことになるためである。
そして，出願公告の決定謄本送達前に拒絶査定不服審判を請求する際の補正がで
きる範囲についても，審判制度の改善の一環として，制度の国際的調和を図るとともに，拒絶査定不服審判の審理の迅速化を図る観点から，最後の拒絶理由通知に対する補正と同じ範囲とするとともに，特許法１５９条１項後段及び２項後段を規定し，同法５３条及び５０条ただし書を準用することにより，独立特許要件を含めてその補正が不適法な場合には，新たにその旨の拒絶理由を通知することなく，その補正を却下することとした（以上について，乙１～９）。
上記でみたところによれば，特許法１５９条１項後段及び２項後段は，独立特許要件違反を含め拒絶査定不服審判請求時にされた不適法な補正に対し，拒絶理由を通知することなくこれを却下することにより，審理の迅速化，出願間の公平性の確保及び第三者の監視負担の軽減等を図った合理的な規定であるというべきであるから，これらの規定が憲法３１条に違反する旨の原告の前記主張は採用することができない。
(3) 原告は，本件のように拒絶査定不服審判請求時に原査定の拒絶理由を解消するために特許請求の範囲を減縮した補正を，新たな引用文献に基づく新たな拒絶理由で却下する場合には，審判合議体は，いきなり補正却下・拒絶審決をするのではなく，まず拒絶理由を通知するとの運用をすることが，特許制度の趣旨及び憲法３１条に沿うものであるから，本件審決は，特許法１５９条１項後段及び２項後段の規定を適切に運用することを怠った違法性，違憲性がある旨主張するが，かかる運用を特許庁に義務づけることは，前記(2)で検討した平成５年法律第２６号による改正の趣旨を没却する結果となるものであることは明らかであるから，原告の上記主張を採用することはできない。
(4) 以上によれば，原告主張の取消事由１は理由がない。
５ 取消事由２（本願補正発明と引用発明との一致点の認定の誤り，相違点の看過）について
(1) 原告は，本願補正発明の「装置」は，引用発明の情報サーバに対応するものではなく，クライアントに対応するものであるところ，引用発明において，「前記マル
チメディアコンテンツに関する前記コーデックサーバの位置情報と前記コーデックのバイナリデータの識別情報とを用い」る主体は，情報サーバであって，クライアントではないから，本件審決が一致点として認定した「前記マルチメディアコンテンツに関する前記コーデックサーバの位置情報と前記コーデックのバイナリデータの識別情報とが用いられ」は，引用発明の「クライアント」と本願補正発明の「装置」との一致点とはなり得ず，本件審決は一致点の認定を誤り相違点を看過している旨主張する。
しかし，本件審決が一致点として認定した「コーデックサーバの位置情報」及び「コーデックのバイナリデータの識別情報」は，それぞれ引用発明における「デコーダＵＲＩ」及び「対応する最適なデコーダ情報」に相当するものであるところ，前記２(1)ウ(イ)ｂのとおり，引用発明においては，クライアントは，コンテンツ情報（コンテンツ情報は，最適なデコーダ情報を含む。）を用いて，これに対応するデコーダがクライアント側にあるかどうかを確認し，デコーダを有していない場合，コンテンツサーバに対して，デコーダがどこに記憶されているのかを要求し，情報サーバは，デコーダ情報を用いて，要求されたデコーダのデコーダＵＲＩをクライアントに返し，クライアントは，情報サーバから取得したデコーダＵＲＩを用いてデコーダサーバからデコーダをダウンロードする。
そうすると，引用発明において，クライアントが，情報サーバからデコーダＵＲＩ（コーデックサーバの位置情報）を取得するにしても，デコーダのダウンロードを行う際に，「マルチメディアコンテンツに関するコーデックサーバの位置情報」及び「コーデックのバイナリデータの識別情報」を用いる主体はクライアントであるから，本件審決が，「前記マルチメディアコンテンツに関する前記コーデックサーバの位置情報と前記コーデックのバイナリデータの識別情報とが用いられ」ることを，引用発明の「クライアント」と本願補正発明の「装置」との一致点と認定したことに誤りはない。
原告の上記主張は理由がない。
(2) 原告は，引用発明において，「前記コーデックサーバの位置情報と前記コーデックのバイナリデータの識別情報」を知っているのは，情報サーバであって，クライアントではなく，一方，本願補正発明の「装置」においては，「前記マルチメディアコンテンツ」に含まれた「前記コーデックサーバの位置情報と前記第１のソフトウェアモジュールの識別情報とに基づき」，第１のソフトウェアモジュールのダウンロードを要求するのは，「装置」内部の制御部であって，サーバ側ではないから，本件審決が一致点として認定した「前記コーデックサーバの位置情報と前記コーデックのバイナリデータの識別情報とに基づき」は，引用発明の「クライアント」と本願補正発明の「装置」との一致点とはなり得ず，本件審決は一致点の認定を誤り相違点を看過している旨主張する。
しかしながら，前記(1)のとおり，クライアントは，最適なデコーダ情報（コーデックのバイナリデータの識別情報）及び情報サーバから取得したデコーダＵＲＩ（コーデックサーバの位置情報）を用いて，デコーダをダウンロードしているから，本件審決が，「前記コーデックサーバの位置情報と前記コーデックのバイナリデータの識別情報とに基づき，」外部ネットワークに位置した前記コーデックサーバに前記コーデックのバイナリデータのダウンロードを要求するメッセージを生成及び伝送することを，引用発明の「クライアント」と本願補正発明の「装置」との一致点と認定したことに誤りはない。
原告の上記主張は理由がない。
(3) 以上によれば，原告主張の取消事由２は理由がない。
６ 取消事由３（本願補正発明と引用発明との相違点４に係る判断の誤り）について
(1) 原告は，本願補正発明の「ソフトウェアモジュール」は，ＯＳ，コーデックライブラリ，メディアフレームワーク及びハードウェアライブラリを含むところ，本願補正発明は，「第１と第２のソフトウェアモジュールを組み合わせてＤＳＰコードを生成」することを要件としているから，「第１のソフトウェアモジュール」がメ
ディアフレームワークであり，「第２のソフトウェアモジュール」がハードウェアライブラリである場合も包含するものであるが，引用発明においてダウンロードされる「デコーダモジュール」は，本願明細書の「コーデック」（コーデックライブラリの一要素）に相当するものであるから，本件審決が相違点２として判断した「モジュールのみをダウンロードする点」及び「得ようとする各情報が「モジュール」を対象としたものとすること」とは，引用発明における「デコーダモジュール」，すなわちコーデックライブラリについて判断したものにすぎず，コーデックライブラリ以外の本願補正発明の「ソフトウェアモジュール」であるＯＳ，メディアフレームワーク及びハードウェアライブラリについては，何も判断していない旨主張する。そこで検討するに，本願補正発明の「ＤＳＰコード」は，「第 1 のソフトウェアモジュール」と，「第２のソフトウェアモジュール」を組み合わせて生成されるものであり，マルチメディアコンテンツに対応する「第 1 のソフトウェアモジュール」が記憶部に記憶されていない場合，「第１のソフトウェアモジュール」のダウンロードを要求するものである。しかるに，前記１(1)ウ，エ，オ(ア)，(イ)，(エ)のとおり，本願明細書（甲７）の発明の詳細な説明（段落【００１８】，【００２２】，【００２３】，【００３０】，【００３５】，【００４２】，【００４３】，【図５】，【００４７】，【００５１】～【００５３】）には，ダウンロードされる「第 1 のソフトウェアモジュール」の例示として，コーデックライブラリが記載され，「第２のソフトウェアモジュール」の例示として，コーデックライブラリ以外のＯＳ，メディアフレームワーク及びハードウェアライブラリが記載されているから，本願補正発明において，ダウンロードされる「第１のソフトウェアモジュール」は，コーデックライブラリを含むものであって，これを除外するものでないことは明らかである。
そうすると，前記２(2)のとおり，引用発明は，コンテンツ（マルチメディアコンテンツ）に対応する「デコーダ」を有していない場合，コンテンツサーバに対してデコーダがどこに記憶されているのかを要求し，情報サーバから取得したデコーダＵＲＩを用いて，デコーダサーバから「デコーダ」をダウンロードするものである
から，この点において，コーデックライブラリを含む「第 1 のソフトウェアモジュール」のダウンロードを行う本願補正発明と相違するものではない。
そして，本件審決が，本願優先権主張日当時の公知文献として挙げた，公知文献１（甲２）には，前記３(1)ア(ア)，(カ)のとおり，コンテンツとともに，このコンテンツの再生を実行する適切なデコーダを有するウェブサイトにリンクするためのＵＲＬが記憶されたディスクをプレイヤに挿入することにより，ウェブサイトにアクセスしてデコーダをダウンロードする技術が，公知文献２（甲３）には，前記３(2)ア(ウ)ｃのとおり，音楽データＤ１（コンテンツ）と，この音楽データＤ１を再生するコーデックのＩＤであるコーデックＩＤを含むヘッダＨ１で音楽コンテンツＣ１が構成される技術がそれぞれ記載されている。したがって，コンテンツに，デコーダを有するウェブサイトにリンクするためのＵＲＬ（コーデックサーバの位置情報）やコーデックＩＤ（第 1 のソフトウェアモジュールの識別情報）を含むように構成することは，本願優先権主張日当時の公知技術であると認められるから，引用発明に当該公知技術を適用して，相違点４に係る本願補正発明の構成に至ることは，当業者であれば，容易に想到し得るものである。
原告の上記主張は理由がない。
(2) 原告は，公知文献１及び２には，デコーダ全体ではなく，そのうちの一部に相当する第１のソフトウェアモジュールのみをダウンロードするためのコーデックサーバの位置情報や，第１のソフトウェアモジュールのみの識別情報がディスクに含まれているという記載はなく，公知文献１及び２記載の技術を引用発明に組み合わせて本願補正発明の進歩性を否定するためには，公知文献１及び２において，単にデコーダが存在するウェブサイトのＵＲＬ及びデコーダの識別情報では足りず，デコーダ全体のうちの一部に相当する第１のソフトウェアモジュールのみをダウンロードするためのコーデックサーバの位置情報及び第１のソフトウェアモジュールの識別情報がディスクに含まれている必要があるから，仮に公知文献１及び２記載の技術を引用発明に適用できたとしても，本願補正発明には至らない旨主張する。
しかし，前記２(1)エのとおり，引用発明は，モジュールベースのデコーダ（フレキシブルデコーダ）をモノリシックプログラムではなく複数の機能を提供する複数のモジュールの集まりとし，クライアントは，新しいタイプのメディアコンテンツが届いたときに，必要なモジュールのみをダウンロードすることによりデコーダを構成できるものである。本件審決は，本願補正発明と引用発明との相違点２については，引用発明から本願補正発明の構成に想到することは当業者であれば容易である旨判断しているのであって，この点の判断には，後記７の「取消事由４（本願補正発明と引用発明との相違点１及び２に係る判断の誤り）について」において説示するとおり誤りはない。
そうすると，かかるフレキシブルデコーダの構成を採用する引用発明に，公知文献１及び２の公知技術を適用して，ダウンロードされる「第１のソフトウェアモジュール」であるコーデックライブラリに対するコーデックサーバの位置情報やデコーダの識別情報をコンテンツの中に含ませることは，当業者であれば容易に想到し得るものである。
原告の上記主張は理由がない。
(3) 原告は，本願補正発明では，「前記マルチメディアコンテンツは前記コーデックサーバの位置情報と前記第１のソフトウェアモジュールの識別情報を含み」及び「前記コーデックサーバの位置情報と前記第１のソフトウェアモジュールの識別情報とに基づき」の要件を満たしているから，装置側からサーバ側に対して「コーデックサーバの位置情報と第１のソフトウェアモジュールの識別情報」を要求することなく，マルチメディアコンテンツ自体に内在する「コーデックサーバの位置情報と第１のソフトウェアモジュールの識別情報」をそのまま利用すれば足りるのに対して，引用発明においては，「クライアントが対応するデコーダを有していない場合には，スケジューラー管理エンジンは，デコーダＵＲＩを得ることをデコーダ・コンポーネント管理エンジンに指示する。デコーダ・コンポーネント管理エンジンは，どこにデコーダが格納されているかをコンテンツサーバに要求する」のであっ
て，本願補正発明には，このような要求を必要としないという効果がある旨主張する。
しかし，前記のとおり，「マルチメディアコンテンツ」に，「コーデックサーバの位置情報」と「コーデックの識別情報」を含むように構成することは，当業者であれば容易に想到し得るものであるから，本願補正発明において，どこにデコーダが格納されているかをコンテンツサーバに要求する必要がないとの効果は，当該構成に付随する当然の効果であって，格別顕著な効果であると認めることはできない。原告の上記主張は理由がない。
(4) 以上によれば，原告主張の取消事由３は理由がない。
７ 取消事由４（本願補正発明と引用発明との相違点１及び２に係る判断の誤り）について
(1) 原告は，引用発明では“core engine”にデコーダを設置しており，“coreengine”はＣＰＵに該当するから，引用発明のデコーダダウンロード及び設置に関するソフトウェアはＣＰＵ上で動作するソフトウェアであって本願補正発明のＤＳＰコードとは異なるものであること，引用例には，ＯＳなどの実行環境が劣悪であるというＤＳＰの特性上コンポーネント化されていないソフトウェアを備えるしかないＤＳＰに対し，新規コーデックが要求される際にコーデックを変更するために最小限の資源を用いてＤＳＰ規格に合うＤＳＰコードを容易に提供することについては，いかなる開示も示唆もないこと，これに対し，本願補正発明は，コンポーネント化されたソフトウェアの使用が容易ではないＤＳＰによりコーデックを支援する回路環境で新規コーデックが要求されるたびに大容量のＤＳＰコードを適用及び交替することにより発生する相当量のオーバーヘッドを最小化するため，コンテンツを再生するたびにリアルタイムでＣＰＵ(ＤＳＰコード生成部)で適切なコーデックライブラリを選択するようにした後，選択されたコーデックライブラリとＯＳ及びメディアフレームワークを組み合わせてＤＳＰコードを生成し，生成されたＤＳＰコードをＤＳＰ処理部に提供し，ＤＳＰ処理部では提供されたＤＳＰコードに基
づいてコンテンツを再生するためのデコーディングを行うこととし，ＤＳＰはコンテンツを再生するたびにＣＰＵからＤＳＰコードを提供される構成としたものであり，かかる構成，効果を検討せずに相違点１及び２について容易想到であると判断した本件審決は誤りである旨主張する。
しかし，前記２(1)ア(イ)記載のとおり，引用発明は，従来のデコーダは一体のソフトウェアであったため，複数のデコーダ間において，デコーダを構成する画像圧縮アルゴリズム（ＤＣＴ，ウェーブレット，動き推定など）等が同じであったとしても，デコーダのパーツを共有することができなかったという課題を解決するため，デコーダをモジュールベースとすることにより，同じ画像圧縮アルゴリズム等を複数のデコーダ間で共有するように構成したものであると認められる。また，前記２ エ ウ のとおり，引用例には，ＤＳＰなどのハードウェアに適したＩＤＣＴモジュールを選択してデコーダを構成することが記載されているから，引用発明において，ＤＳＰによってもデコーダを動作させ得ることが理解される。
そうすると，引用発明のコアエンジンについて，ＤＳＰによるハードウェアを採用し，ＤＳＰでデコーダを動作させるように構成することは，当業者であれば容易に想到し得るものである。また，ＤＳＰによってデコーダを動作させる場合，ＤＳＰに適したＯＳ等のソフトウェアが必要であることは，本願優先権主張日当時の技術常識であるというべきであるから，デコーダとＯＳ等のソフトウェアを組み合わせてＤＳＰで動作させること，すなわち，ＤＳＰコードを生成し，ＤＳＰでマルチメディアコンテンツの処理を行うことは，当業者であれば容易に想到し得るものである。そして，原告が上記において主張する本願補正発明の効果も，引用発明から容易に想到し得る本願補正発明の構成から予測し得る効果にすぎず，格別顕著な効果であると認めることはできない。
原告の上記主張は理由がない。
なお，原告は，本願補正発明では，コーデックライブラリだけでなく，ＯＳ，メディアフレームワーク及びハードウェアライブラリのソフトウェアを組み合わせて
新たな「ＤＳＰコード」を生成しているのに対し，引用発明の「デコーダ・コンポーネント管理エンジン」は「コアエンジン」に対して「デコーダモジュール」のみを供給しているところ，この「デコーダモジュール」は，本願明細書の「コーデック」に相当するものであり，新たなＤＳＰコードを生成する機能は有していない旨主張するが，同主張に理由がないことは，上記において説示したとおりである。
(2) 原告は，引用例には，いくつかのＩＤＣＴモジュールの中でＤＳＰという「ハードウェア仕様…に適したＩＤＣＴモジュールを選択」することができると記載されているのであって，ＤＳＰで複数のＩＤＣＴモジュールを用いることができ，ＩＤＣＴの変更を実施できる旨の記載はない旨主張する。
しかし，ＤＣＴ（Discrete Cosine Transform；離散コサイン変換）は，画像や動画の圧縮を行う際に用いられる変換方法（アルゴリズム）であり，ＩＤＣＴ（InverseDiscrete Cosine Transform；逆離散コサイン変換）は，ＤＣＴで変換した信号を復号するために逆変換を行う変換方法であるところ，ＤＳＰが様々な画像アルゴリズムに対応できるハードウェアであることは本願優先権主張日当時の技術常識であるというべきであるから，引用例に，ＤＳＰが複数のＩＤＣＴモジュールを使用し，ＩＤＣＴの変更を実施できる旨の記載がないからといって，ＤＳＰが単一のＩＤＣＴモジュールにしか対応し得ないものではないことは自明である。また，引用例には，前記２ イ ア のとおり，画像圧縮アルゴリズムとしてＤＣＴが広く使われているが，ＤＣＴが全種類の画像に適しているわけではないことが記載され，また，前記２(1)ア(イ)のとおり，デコーダを構成する画像圧縮アルゴリズムとして，ＤＣＴのほかにウェーブレット等が例示されていることからすれば，当業者であれば，引用発明におけるＤＳＰは，複数のＩＤＣＴモジュールに対応できるだけでなく，ＤＣＴ以外の他の画像圧縮アルゴリズムにも対応可能なものであることが，容易に理解できるところである。
原告の上記主張は理由がない。
なお，原告は，引用例には，ハードウェア仕様に適したデコーダを選択すること
は記載されていても，同一のハードウェア仕様について複数のデコーダを選択的にダウンロードして用いることは記載されていない旨主張するが，同主張に理由がないことは，上記において説示したところから明らかである。
原告は，引用例に，一体化したソフトウェアの課題認識があったとしても，それはシステム全体としての課題認識であり，ＤＳＰにおける課題認識が示唆されているものではない旨主張するが，前記２(2)のとおり，引用発明は，モジュールベースのデコーダ（フレキシブルデコーダ）をモノリシックプログラムではなく複数の機能を提供する複数のモジュールの集まりとして認識し，クライアントは，必要なモジュールのみをダウンロードすることによりデコーダを構成するものであって，ソフトウェアを一体化したものとしてのみ認識するものではなく，また，前記(1)のとおり，ＤＳＰではデコーダとＯＳ等のソフトウェアを組み合わせて動作させるものであるから，原告の上記主張は理由がない。
(4) 原告は，本願補正発明は，ＤＳＰに最適のＤＳＰコードを提供するため，ＣＰＵ及びＤＳＰ間の連動構造を備えているのに対し，引用発明は，コアエンジンとしてＤＳＰを採用する構成上の違いがある旨主張する。
しかし，前記３(2)ア(ウ)ａのとおり公知文献２（甲３）において，ＣＰＵで音楽データのダウンロードを行い，ＤＳＰでコーデックプログラムを実行することにより音楽再生を行うことが記載されていること（段落【００２３】，【図３】，【００２５】，【００２６】，【００２９】，【００３０】）及び弁論の全趣旨によれば，ＣＰＵとＤＳＰが連動して処理を行うことは，本願優先権主張日当時の周知技術であることが認められるから，引用発明において，ＣＰＵとＤＳＰが連動して処理を行うように構成することは，当業者であれば容易に想到し得るものである。
原告の上記主張は理由がない。
以上によれば，原告主張の取消事由４は理由がない。
８ 結論
以上の次第であるから，原告主張の取消事由はいずれも理由がなく，本件審決の
判断に誤りはないから，本件審決にこれを取り消すべき違法は認められない。
よって，原告の本訴請求は理由がないから，棄却されるべきである。
知的財産高等裁判所第４部
裁判長裁判官 富田善範
裁判官 大鷹一郎
裁判官 田中芳樹
出典：裁判所ウェブサイト「裁判例検索」（https://www.courts.go.jp/hanrei/84075/detail7/index.html）。本文は同サイト掲載の判決書PDFからTaiLexi AIがテキスト化・整形したもの（正確な文言は原本PDFを参照）。判示事項・裁判要旨・参照法条は裁判所の公表どおり。