弁護士法人ITJ法律事務所

裁判例


戻る

平成26年3月26日判決言渡同日原本受領裁判所書記官
平成24年(行ケ)第10406号審決取消請求事件
口頭弁論終結日平成26年2月26日
判決
原告三星電子株式会社
訴訟代理人弁理士伊東忠彦
同伊東忠重
同大貫進介
同宮崎修
被告特許庁長官
指定代理人奥村元宏
同小池正彦
同樋口信宏
同山田和彦
主文
1原告の請求を棄却する。
2訴訟費用は原告の負担とする。
3この判決に対する上告及び上告受理申立てのための付加期間を
30日と定める。
事実及び理由
第1請求
特許庁が不服2010-22102号事件について平成24年7月9日にした審
決を取り消す。
第2事案の概要
1特許庁における手続の経緯等
(1)原告は,平成19年4月20日,発明の名称を「ソフトウェアモジュールの
組合せによってDSPコードを生成する装置及びその方法」とする発明(請求項の
数7)について特許出願(特願2007-111333号。パリ条約による優先権
主張:平成18年(2006年)5月3日,優先権主張国:大韓民国。以下「本願」
という。)をし,平成22年1月28日付けの拒絶理由通知を受けたことから,同年
5月7日付け手続補正書(請求項の数7)を提出したが,同年5月21日付けで拒
絶査定を受けたため,同年10月1日,これに対する不服の審判を請求し,併せて
同日付け手続補正書により特許請求の範囲を補正した(請求項の数5,以下「本件
補正」という。)(甲4,5,7~10)。
(2)特許庁は,前記(1)の請求を不服2010-22102号事件として審理し,
平成24年7月9日,「本件審判の請求は,成り立たない。」との審決(以下「本件
審決」という。)をし,その謄本は,同年7月24日,原告に送達された。
(3)原告は,平成24年11月21日,本件審決の取消しを求める本件訴訟を提
起した。
2本件審決が対象とした特許請求の範囲の記載
(1)本願発明
本件補正前の特許請求の範囲の請求項1の記載は,平成22年5月7日付け手続
補正書(甲7)により補正された次のとおりのものである。以下,この請求項1に
記載された発明を「本願発明」といい,本願に係る明細書(甲7)を「本願明細書」
という。
【請求項1】
デジタルシグナルプロセッサ(DSP)処理部と,
コーデックサーバから第1のソフトウェアモジュールをダウンロードする手段と,
ダウンロードされた第1のソフトウェアモジュールと,少なくとも第2のソフト
ウェアモジュールとを記憶する記憶部と,
前記記憶された第1と第2のソフトウェアモジュールを組み合わせてDSPコー
ドを生成し,前記DSP処理部にロードするDSPコード生成部と,を有し,
前記DSP処理部は前記ロードされたDSPコードをデコーディングして,前記
第1のソフトウェアモジュールに対応するマルチメディアコンテンツを処理するこ
とを特徴とする装置。
(2)本願補正発明
本件補正後の特許請求の範囲の請求項1の記載は,次のとおりである(甲10)。
以下,この請求項1に記載された発明を「本願補正発明」という。なお,文中の下
線部は,補正箇所を示す。
【請求項1】
デジタルシグナルプロセッサ(DSP)処理部と,
コーデックサーバから第1のソフトウェアモジュールをダウンロードする手段と,
ダウンロードされた第1のソフトウェアモジュールと,少なくとも第2のソフト
ウェアモジュールとを記憶する記憶部と,
前記記憶された第1と第2のソフトウェアモジュールを組み合わせてDSPコー
ドを生成し,前記DSP処理部にロードするDSPコード生成部と,を有し,
前記DSP処理部は前記ロードされたDSPコードをデコーディングして,前記
第1のソフトウェアモジュールに対応するマルチメディアコンテンツを処理し,
前記マルチメディアコンテンツは,前記コーデックサーバの位置情報と前記第1
のソフトウェアモジュールの識別情報とを含み,
前記マルチメディアコンテンツに対応する前記第1のソフトウェアモジュールが
前記記憶部に記憶されていない場合,前記コーデックサーバの位置情報と前記第1
のソフトウェアモジュールの識別情報とに基づき,外部ネットワークに位置した前
記コーデックサーバに前記第1のソフトウェアモジュールのダウンロードを要求す
るメッセージを生成及び伝送する制御部をさらに有することを特徴とする装置。
3本件審決の理由の要旨
(1)本件審決の理由は,要するに,①本願補正発明は,下記アの刊行物(以下「引
用例」という。)に記載された発明(以下「引用発明」という。),下記イ及びウの公
知文献及び技術常識に基づいて,当業者が容易に発明をすることができたものであ
り,特許法29条2項の規定により,特許出願の際独立して特許を受けることがで
きないものであるから,本件補正は,平成23年法律第63号改正附則2条18項
によりなお従前の例によるとされる同法による改正前の特許法(以下「法」という。)
17条の2第6項において準用する法126条5項の規定に適合していないことか
ら,特許法159条1項において読み替えて準用する同法53条1項の規定により
却下すべきものである,②本願発明は,引用発明及び技術常識に基づいて,当業者
が容易に発明をすることができたものであるから,特許法29条2項の規定により
特許を受けることができない,というものである。
ア引用例:“NaotoSHIMIZU,etal,ANovelDecoder-downloadableSystemfor
Content-orientedCoding,GlobalTelecommunicationsConference,2002.
GLOBECOM’02.IEEE,2002年11月17日,Volume.2,pages1638-1642”(平成14
年(2002年)11月17日刊行。甲1)
イ公知文献1:特表2006-511902号公報(平成18年4月6日公開。
甲2)
ウ公知文献2:特開2001-202094号公報(平成13年7月27日公
開。甲3)
(2)本件審決が認定した引用発明は,次のとおりである。
コアエンジンと,
デコーダサーバからデコーダのバイナリデータをダウンロードするデコーダ・コ
ンポーネント管理エンジンと,
ダウンロードされた複数のデコーダの管理をするデコーダ・コンポーネント管理
エンジンと,
デコーダは,コアエンジンでインストールされ,
コアエンジンは,メディアの再生を行い,
各コンテンツのためのプロファイルを記述したコンテンツ情報には,対応する最
適なデコーダ情報を含み,
デコーダがクライアント側に既に存在しているか否かについて,デコーダ・コン
ポーネント管理エンジンに確認し,対応するデコーダを有していない場合には,デ
コーダ情報を使用して,情報サーバから得られたデコーダURIにより,必要とな
るデコーダの問い合わせを行い,デコーダ・サーバからデコーダをダウンロードす
るデコーダ・コンポーネント管理エンジンを有するクライアント。
(3)本願補正発明と引用発明との対比
本件審決が認定した本願補正発明と引用発明との一致点及び相違点は,以下のと
おりである。
ア一致点
処理部と,
コーデックサーバからコーデックのバイナリデータをダウンロードする手段と,
ダウンロードされた複数のコーデックのバイナリデータを記憶する記憶部と,
前記記憶されたコーデックのバイナリデータを実行コードとして処理部にロード
する手段と,を有し,
前記処理部は,前記ロードされた実行コードにより前記コーデックのバイナリデ
ータに対応するマルチメディアコンテンツを処理し,
前記マルチメディアコンテンツに関する前記コーデックサーバの位置情報と前記
コーデックのバイナリデータの識別情報とが用いられ,
前記マルチメディアコンテンツに対応する前記コーデックのバイナリデータが前
記記憶部に記憶されていない場合,前記コーデックサーバの位置情報と前記コーデ
ックのバイナリデータの識別情報とに基づき,外部ネットワークに位置した前記コ
ーデックサーバに前記コーデックのバイナリデータのダウンロードを要求するメッ
セージを生成及び伝送する制御部を有する装置。
イ相違点1
本願補正発明では,「デジタルシグナルプロセッサ(DSP)」により処理が行わ
れるものであるのに対し,引用発明では,デジタルシグナルプロセッサ(DSP)
により処理が行われるものとはされていない点。
ウ相違点2
本願補正発明では,「ソフトウェアモジュールの識別情報」に基づき,「ソフトウ
ェアモジュール」をダウンロードして記憶し,記憶された複数の「ソフトウェアモ
ジュール」を組み合わせてコーデックのコードを生成し,「ソフトウェアモジュール」
に対応するマルチメディアコンテンツを処理するものであるのに対し,引用発明で
は,「デコーダ情報」に基づき,「デコーダのバイナリデータ」をダウンロードして
記憶し,「デコーダ」に対応するメディア又はコンテンツが再生されるものであり,
複数のソフトウェアモジュールを組み合せてデコーダのコードを生成することとは
されていない点。
エ相違点3
本願補正発明では,DSP処理部は,ロードされたDSPコードを「デコーディ
ング」して処理を実行するのに対し,引用発明では,コアエンジンが,読み込まれ
た実行コードをデコーディングするものとはされていない点。
オ相違点4
本願補正発明では,「マルチメディアコンテンツ」の中に,「コーデックサーバの
位置情報」と「第1のソフトウェアモジュールの識別情報」が含まれるのに対し,
引用発明では,「コンテンツ」の中に「デコーダURI」と「デコーダ情報」が含ま
れるものとはされていない点。
(4)本願発明と引用発明との対比
本件審決が認定した本願発明と引用発明との一致点及び相違点は,以下のとおり
である。
ア一致点
処理部と,
コーデックサーバからコーデックのバイナリデータをダウンロードする手段と,
ダウンロードされた複数のコーデックのバイナリデータを記憶する記憶部と,
前記記憶されたコーデックのバイナリデータを実行コードとして処理部にロード
する手段と,を有し,
前記処理部は,前記ロードされた実行コードにより前記コーデックのバイナリデ
ータに対応するマルチメディアコンテンツを処理する装置。
イ相違点1
本願発明では,「デジタルシグナルプロセッサ(DSP)」により処理が行われる
ものであるのに対し,引用発明では,デジタルシグナルプロセッサ(DSP)によ
り処理が行われるものとはされていない点。
ウ相違点2
本願発明では,「ソフトウェアモジュールの識別情報」に基づき,「ソフトウェア
モジュール」をダウンロードして記憶し,記憶された複数の「ソフトウェアモジュ
ール」を組み合わせてコーデックのコードを生成し,「ソフトウェアモジュール」に
対応するマルチメディアコンテンツを処理するものであるのに対し,引用発明では,
「デコーダ情報」に基づき,「デコーダのバイナリデータ」をダウンロードして記憶
し,「デコーダ」に対応するメディア又はコンテンツが再生されるものであり,複数
のソフトウェアモジュールを組み合せてデコーダのコードを生成することとはされ
ていない点。
エ相違点3
本願発明では,DSP処理部は,ロードされたDSPコードを「デコーディング」
して処理を実行するのに対し,引用発明では,コアエンジンが,読み込まれた実行
コードをデコーディングするものとはされていない点。
4取消事由
(1)本願補正発明の容易想到性の判断に係る手続違背(取消事由1)
(2)本願補正発明と引用発明との一致点の認定の誤り,相違点の看過(取消事由
2)
(3)本願補正発明と引用発明との相違点4に係る判断の誤り(取消事由3)
(4)本願補正発明と引用発明との相違点1及び2に係る判断の誤り(取消事由
4)
第3当事者の主張の要旨
1取消事由1(本願補正発明の容易想到性の判断に係る手続違背)について
〔原告の主張〕
(1)本件審決は,本願補正発明と引用発明との相違点4について,引用発明並び
に公知文献1及び2(甲2,3)に記載された公知技術に基づいて,当業者であれ
ば容易に想到できると判断したが,拒絶理由通知及び拒絶査定において,公知文献
1及び2は何ら引用されておらず,上記各公知文献は審決において初めて示された
ものであり,原告に対して,拒絶査定の理由と異なる新たな拒絶理由の通知はなく,
意見書提出の機会も与えられなかった。したがって,本件審決には,特許法159
条2項により準用される同法50条に違反する違法があり,その違法は審決の結論
に影響を及ぼすことが明らかである。
(2)特許法159条2項前段は,同法50条の規定を拒絶査定不服審判に準用す
ることから,当該審判の審理において,審判長は,拒絶査定の理由と異なる拒絶の
理由を発見した場合には,特許出願人(審判請求人)に対し,拒絶の理由を通知し,
相当の期間を指定して,意見書を提出する機会を与えなければならない。
これに対し,同法159条1項後段及び2項後段は,同法50条ただし書の規定
により拒絶理由を通知することなく補正却下できる例外的な場合として,「17条の
2第1項…第4号(拒絶査定不服審判請求時の補正)に掲げる場合」を追加する規
定となっていることから,特許出願人が拒絶査定不服審判を請求すると同時に特許
請求の範囲を補正した場合において,その補正が同法17条の2第3項ないし6項
の規定に違反するときは,拒絶理由が通知されずにいきなり補正却下され拒絶審決
を受けることがある。
補正却下の理由が,新規事項追加違反(同法17条の2第3項),技術的特徴変更
違反(同法17条の2第4項),限定的減縮違反(同法17条の2第5項)のいわゆ
る補正要件違反である場合には,補正要件違反であることを特許出願人がある程度
想定できる(補正要件違反は特許出願人の責任である場合もある)から,拒絶理由
通知なく補正却下され拒絶審決がされても,受忍できる範囲といえる。しかし,拒
絶査定不服審判を請求し,特許請求の範囲について拒絶査定の理由を解消するよう
な限定を付加して補正をした特許出願人(審判請求人)に対する補正却下の理由が,
特許出願人が想定し得ない新たな引用文献を引用した新たな拒絶の理由である独立
特許要件違反の場合には,特許出願人に何ら責任はなく,かかる場合にまで意見書
提出の機会を与えないことは,特許庁審判官による再度の審査(審理)を適正に受
ける権利を,特許出願人から不当に奪うものである。
そもそも補正却下の対象を規定した特許法53条は,拒絶査定を受けてもその後
拒絶査定不服審判請求時に補正が可能である審査に関するものであり,拒絶査定不
服審判における審理には当てはまらない。また,補正却下を適用する同法50条た
だし書は,いわゆる補正要件違反を念頭に置いたものである。さらに同法53条及
び50条ただし書を拒絶査定不服審判における審理に準用した同法159条1項及
び2項の立法趣旨は,拒絶査定不服審判請求時にした補正が新規事項を追加するも
のである場合において優先的に補正却下を適用することにあるのであって,拒絶査
定不服審判請求時に原査定の拒絶理由を解消すべく請求項を減縮した補正を,意見
書・補正書の提出機会を与えずに,新たな拒絶理由によって補正却下するような事
態に適用することにあるのではない。上記によれば,同法159条1項及び2項は
拒絶査定不服審判請求時にした補正が新規事項を追加するものである場合において
優先的に補正却下を適用するために規定されたものであり,その立法過程において,
拒絶査定不服審判請求時に原査定の拒絶理由を解消すべく請求項を減縮した補正が
新たな引用文献に基づく新たな拒絶理由によって,意見書・補正書の提出機会が与
えられずに補正却下されてしまう事態は想定されていない。
したがって,拒絶査定不服審判請求時にした補正を,補正違反の態様にかかわら
ず一律に補正却下の対象とした同法159条1項後段及び2項後段の規定自体が立
法の誤りであり,憲法31条に反し違憲であって,本件審決もまた違憲な規定に則
ったものであるから違憲である。
(3)また,本件のように拒絶査定不服審判請求時に原査定の拒絶理由を解消する
ために特許請求の範囲を減縮した補正を,新たな引用文献に基づく新たな拒絶理由
で却下する場合には,審判合議体は,いきなり補正却下・拒絶審決をするのではな
く,先ず拒絶理由を通知するとの運用をすることが,特許制度の趣旨及び憲法31
条に沿うものであるから,本件審決は,特許法159条1項後段及び2項後段の規
定を適切に運用することを怠った違法性,違憲性がある。
(4)被告は,特許出願人は,自らの判断で,多項制を活用して,出願時や最初の
拒絶理由通知に対する補正により特許請求の範囲に記載すれば補正却下を回避でき
る旨主張するが,本件審決において初めて示された公知文献1及び2並びに補正却
下の理由については,拒絶査定不服審判請求時に本件補正をするに当たっては知り
得ないものであるから,自らの判断で補正却下を回避することはできなかったので
あり,被告の上記主張は,特許実務からかけ離れた,補正制度を無視したものであ
り,失当である。
〔被告の主張〕
(1)本件補正は,特許法17条の2第1項4号に係る補正であるところ,特許法
は,159条1項において読み替えて53条1項の規定を準用し,159条2項に
おいて読み替えて50条ただし書きを準用し,17条の2第1項4号に係る補正(拒
絶査定不服審判請求時の補正)を却下する場合には,拒絶理由を通知することを必
要としていない。
本件審決が新たに公知文献1及び2(甲2,3)を挙げてした判断は,相違点4
についてしたものであり,相違点4に係る本願補正発明の構成は,「「マルチメディ
アコンテンツ」の中に,「コーデックサーバの位置情報」と「第1のソフトウェアモ
ジュールの識別情報」が含まれる」であり,この構成は拒絶査定不服審判請求時の
補正(本件補正)により新たに追加されたものであって,この追加は特許請求の範
囲の減縮である。そして,本件審決は,この特許請求の範囲の減縮を目的とする本
件補正について,法17条の2第6項において準用する法126条5項の規定に適
合していない,いわゆる独立特許要件に違反するとして,特許法159条1項にお
いて読み替えて準用する同法53条1項の規定によって却下したもの,すなわち,
特許法で拒絶理由を通知することを必要としない手続によって本件補正を却下した
のであり,原告に拒絶理由を通知せず,意見書の提出機会を付与しなかったことに
ついて本件審決に手続違背はない。
(2)特許法159条2項後段の規定は,補正に関する他の改正項目と同様に,迅
速・的確かつ公平な権利付与等の観点から設けられたものである。すなわち,各国
経済の相互依存の進化に伴い特許制度の国際調和が検討されていたところ,我が国
の特許制度については,補正回数や補正範囲の制限が不十分であるため,権利付与
までの期間が長期化し,また,第三者の監視負担が過大になる等の問題が指摘され
ていた。そこで,平成5年法律第26号では,2回目(最後)の拒絶理由通知以降
の補正に対して,独立特許要件も含めて補正の範囲の適正化を図り,また,拒絶理
由の通知について同法50条ただし書の規定が設けられるとともに,不適法な補正
は却下することとして同法53条1項ないし3項の規定が設けられ,拒絶査定不服
審判についても,迅速な権利付与の実現,出願間の公平な取扱い等の観点から,同
様の改正がされた(同法17条の2,159条)。
原告は,この点について,同法159条2項後段の立法趣旨は,拒絶査定不服審
判請求時にした補正が新規事項を追加するものである場合に,補正却下を適用する
ことにあると主張する。しかし,同法159条2項後段の立法趣旨は,審判請求時
の補正が不適法である場合の取扱いを,最後の拒絶理由通知に対する補正が不適法
である場合の取扱いと同様のものとすることによって,審理を迅速化し,第三者の
監視負担を軽減することにある。すなわち,同法159条2項後段の規定は,新規
事項を追加する補正のみを却下することを想定したものではなく,目的外の補正や
独立特許要件違反の補正についても却下することを想定したものである。このよう
に,同法159条2項後段の規定は,不適法な審判請求時の補正を却下することに
よって審理を迅速化し,第三者の負担を軽減するものであって,新しい技術を公開
した者(出願人)に対して迅速に権利を付与して発明を保護することと,権利の制
約を受ける第三者の利用を促すこととのバランスを図ったものであるから,特許法
の目的にも合致するものであって,憲法31条に反するものではない。
(3)拒絶査定不服審判は,審査に対する続審である(特許法158及び159条)
から,審判合議体は,審査においてした手続を土台として審理を続行し,新たな資
料をも補充し,拒絶査定が維持できるかどうかを審理するものであるから,審判請
求人は,審判合議体に対し拒絶査定が不服である理由を述べ,拒絶査定の妥当性に
ついて審理を受けることができる。
しかし,審判請求時に特許請求の範囲を拡張,変更する補正がされると,審理対象
が変更されるため新たな審理を行わざるを得なくなり,公平性を欠くことになるのみ
ならず,他の審判請求事件の審理の遅延をも生じるおそれがある。また,審判請求時
の補正が特許請求の範囲の減縮に相当する補正であるとしても,補正後の発明が特許
可能なものであれば,拒絶査定を取り消して特許査定すれば良く,審理が繰り返し行
われることを回避することができるが,補正後の発明が特許できないものについて,
仮に,審判において再度,拒絶の理由を通知し,審判請求人に意見書・補正書を提出
する機会を与えたならば,審理が繰り返し行われることを回避できなくなる。また,
仮に,審判請求人がこの機会を活用して出願を分割したならば,分割された出願につ
いて最初から審査がやり直されることとなり,しかも,第三者の監視負担が新たに発
生する。さらに,出願前に十分な先行技術調査を行い予め高品質な特許請求の範囲及
び明細書を作成し,多項制を積極的に活用して1回以下の拒絶理由通知で特許性を見
極め,審判請求前に迅速に権利を取得しようとしている他の出願人との公平性の観点
からも問題がある。特許出願人にとっても,十分な先行技術調査,多項制の活用等に
対するインセンティブが損なわる結果,迅速・的確な権利取得の確率が低下する。
そもそも,同法50条には補正却下するときに拒絶理由の通知を要しない旨の規定
はあるが,同法53条には拒絶理由を通知するときに補正却下を要しない旨の規定は
ない。万が一,補正却下せず拒絶理由を通知する運用としたならば,審判請求人は不
適法な補正の範囲内で補正する不利益を被り,補正却下しなかったことについて,審
判合議体の処分の違法性を問うことができる。また,仮に,補正却下せず拒絶理由を
通知する運用としたならば,審判請求人は,審判請求時に拒絶理由を内在する不適法
な減縮補正を行っただけで,特許庁に対し最初から審査(審理)をやり直させること
ができるようになる。原告が主張する運用は,実質的に,審判請求の段階になってか
ら審査を再スタートさせることを強いる運用であり,審理期間の遅延を招き,第三者
の監視負担を増大させるだけである。
以上のとおりであるから,審判請求時の補正が,単に,拒絶査定の理由を解消すべ
く特許請求の範囲を減縮した補正であることをもって審判において再度,拒絶の理由
を通知するという運用を採用することは,迅速・的確かつ公平な権利付与を図るとい
う前記(2)の平成5年法律第26号による改正の趣旨に合致しない。
(4)特許出願人は,自らの判断で,多項制を活用して,特許を受けようとする発
明について特許請求の範囲に請求項毎に記載し,本件のような補正却下を回避する
ことができる。本件でいえば,原告は,本件補正により追加された「「マルチメディ
アコンテンツ」の中に,「コーデックサーバの位置情報」と「第1のソフトウェアモ
ジュールの識別情報」が含まれる」との構成を含む発明を,出願時にあらかじめ特
許請求の範囲に記載していたならば,平成22年1月28日付け拒絶理由通知の段
階で,同構成についても審査を受けることができたし,あるいは同拒絶理由通知に
対する手続補正で特許請求の範囲に記載していたならば,審査官から最後の拒絶理
由通知を受けることができた。したがって,原告が主張する特許出願人にとっての
不利益は,多項制を活用することにより回避可能であるから,特許出願人に何ら責
任がないとはいえない。
また,新たな引用文献を引用した29条2項の規定により独立特許要件を満たさ
ないとの理由により補正が却下されることは,制度上予定されていることであるか
ら,特許出願人にとって全く想定できないものでもない。
2取消事由2(本願補正発明と引用発明との一致点の認定の誤り,相違点の看
過)について
〔原告の主張〕
(1)本件審決は,引用発明の「クライアント」と本願補正発明の「装置」とは,
「前記マルチメディアコンテンツに関する前記コーデックサーバの位置情報と前記
コーデックのバイナリデータの識別情報とが用いられ」ること,及び「前記コーデ
ックサーバの位置情報と前記コーデックのバイナリデータの識別情報とに基づき,」
外部ネットワークに位置した前記コーデックサーバに前記コーデックのバイナリデ
ータのダウンロードを要求するメッセージを生成及び伝送することを一致点として
認定した。
(2)しかし,引用発明において,「前記マルチメディアコンテンツに関する前記
コーデックサーバの位置情報と前記コーデックのバイナリデータの識別情報とを用
い」る主体は,情報サーバであって,クライアントではない。本願補正発明の「装
置」は,引用発明の情報サーバに対応するものではなく,クライアントに対応する
ものである。そうすると,本件審決が一致点として認定した「前記マルチメディア
コンテンツに関する前記コーデックサーバの位置情報と前記コーデックのバイナリ
データの識別情報とが用いられ」は,引用発明の「クライアント」と本願補正発明
の「装置」との一致点とはなり得ないから,本件審決は一致点の認定を誤り相違点
を看過している。
また,引用発明において,「前記コーデックサーバの位置情報と前記コーデックの
バイナリデータの識別情報」を知っているのは,情報サーバであって,クライアン
トではない。一方,本願補正発明の「装置」においては,「前記マルチメディアコン
テンツ」に含まれた「前記コーデックサーバの位置情報と前記第1のソフトウェア
モジュールの識別情報とに基づき」,第1のソフトウェアモジュールのダウンロード
を要求するのは,「装置」内部の制御部であって,サーバ側ではない。そうすると,
本件審決が一致点として認定した「前記コーデックサーバの位置情報と前記コーデ
ックのバイナリデータの識別情報とに基づき」は,引用発明の「クライアント」と
本願補正発明の「装置」との一致点とはなり得ないから,本件審決は一致点の認定
を誤り相違点を看過している。
(3)以上のとおり,本件審決は,前記相違点を看過することにより,誤って本願
補正発明の進歩性を否定したものであるから,取り消されるべきである。
〔被告の主張〕
(1)本件審決が一致点として認定した「コーデックサーバの位置情報」及び「コ
ーデックのバイナリデータの識別情報」は,それぞれ引用発明における「デコーダ
URI」及び「対応する最適なデコーダ情報」であり,引用例において,「デコーダ
URI」(「コーデックサーバの位置情報」)と,「対応する最適なデコーダ情報」(「コ
ーデックのバイナリデータの識別情報」)とは,クライアントが外部(情報サーバ)
から取得して,クライアントにおいてダウンロードに用いられる。他方,本願補正
発明の装置は,マルチメディアコンテンツに含まれる「コーデックサーバの位置情
報」と「第1のソフトウェアモジュールの識別情報」とをマルチメディアコンテン
ツとともに取得しダウンロードに用いる。
そうすると,これら情報をダウンロードに用いているという観点で,本件審決が,
「前記マルチメディアコンテンツに関する前記コーデックサーバの位置情報と前記
コーデックのバイナリデータの識別情報とが用いられ」ていることを,引用発明の
「クライアント」と本願補正発明の「装置」との一致点としたことに誤りはない。
(2)原告は,引用発明において,「前記コーデックサーバの位置情報と前記コー
デックのバイナリデータの識別情報」を知っているのは,情報サーバであって,ク
ライアントではないと主張するが,上記のとおり,引用例では,情報サーバが知っ
ている情報をクライアントが得て用いるのであり,クライアントが情報を得る情報
源が情報サーバであるとしても,クライアントにおいて,「前記マルチメディアコ
ンテンツに関する前記コーデックサーバの位置情報と前記コーデックのバイナリデ
ータの識別情報とが用いられ」ているといえるものである。
3取消事由3(本願補正発明と引用発明との相違点4に係る判断の誤り)につ
いて
〔原告の主張〕
(1)本件審決は,本願補正発明と引用発明との相違点4について,引用発明では,
「コンテンツ」の中に「デコーダURI」と「デコーダ情報」が含まれるものとは
されておらず,「コンテンツ」とは別に,情報サーバから,「デコーダURI」と,
各コンテンツに対応する「デコーダ情報」が提供されるものであるが,コンテンツ
とともにデコーダをダウンロードするためのサーバの位置情報を提供することや,
コンテンツの中にデコーダを識別するための情報が含まれるようにすることは,公
知文献1及び2に開示されているように既に知られた考え方であるから,引用発明
における「デコーダURI」及び「デコーダ情報」に,上記公知技術に係る考え方
を採用することで,本願補正発明のように,「マルチメディアコンテンツ」に「コー
デックサーバの位置情報」と「コーデックの識別情報」を含むように構成すること
は,当業者であれば容易に想到できる旨判断した。
(2)しかし,公知文献1(甲2)には,デコーダ全体ではなく,そのうちの一部
に相当する第1のソフトウェアモジュールのみをダウンロードするためのコーデッ
クサーバの位置情報がディスクに含まれているという記載はない。公知文献1記載
の技術を引用発明に組み合わせて本願補正発明の進歩性を否定するためには,公知
文献1において,単にデコーダが存在するウェブサイトのURLでは足りず,デコ
ーダ全体のうちの一部に相当する第1のソフトウェアモジュールのみをダウンロー
ドするためのコーデックサーバの位置情報がディスクに含まれている必要がある。
したがって,仮に公知文献1記載の技術を引用発明に適用できたとしても,本願
補正発明には至らない。
(3)公知文献2(甲3)においても同様に,仮にデコーダを識別するための情報
がコンテンツに含まれているという技術が公知文献2に記載されていたとしても,
デコーダ全体ではなく,そのうちの一部に相当する第1のソフトウェアモジュール
のみの識別情報がコンテンツに含まれているという記載はない。公知文献2記載の
技術を引用発明に組み合わせて本願補正発明の進歩性を否定するためには,公知文
献2において,単にデコーダの識別情報では足りず,デコーダ全体のうちの一部に
相当する第1のソフトウェアモジュールの識別情報がコンテンツに含まれている必
要がある。
したがって,仮に公知文献2記載の技術を引用発明に適用できたとしても,本願
補正発明には至らない。
(4)本願補正発明の「ソフトウェアモジュール」は,OS,コーデックライブラ
リ,メディアフレームワーク及びハードウェアライブラリを含む(本願明細書の段
落【0029】)。そして,本願補正発明は,「第1と第2のソフトウェアモジュール
を組み合わせてDSPコードを生成」することを要件としているから,例えば,「第
1のソフトウェアモジュール」がメディアフレームワークであり,「第2のソフトウ
ェアモジュール」がハードウェアライブラリである場合も包含する。
他方,引用発明においてダウンロードされる「デコーダモジュール」は,本願明
細書の「コーデック」(コーデックライブラリの一要素)に相当する。
そうすると,本件審決が相違点2として判断した「モジュールのみをダウンロー
ドする点」及び「得ようとする各情報が「モジュール」を対象としたものとするこ
と」とは,引用発明における「デコーダモジュール」,すなわちコーデックライブラ
リについて判断したものにすぎず,コーデックライブラリ以外の本願補正発明の「ソ
フトウェアモジュール」であるOS,メディアフレームワーク及びハードウェアラ
イブラリについては,何も判断していない。
(5)本願補正発明では,「前記マルチメディアコンテンツは前記コーデックサー
バの位置情報と前記第1のソフトウェアモジュールの識別情報を含み」及び「前記
コーデックサーバの位置情報と前記第1のソフトウェアモジュールの識別情報とに
基づき」の要件を満たしているために,装置側からサーバ側に対して「コーデック
サーバの位置情報と第1のソフトウェアモジュールの識別情報」を要求することな
く,マルチメディアコンテンツ自体に内在する「コーデックサーバの位置情報と第
1のソフトウェアモジュールの識別情報」をそのまま利用すれば足りる。
これに対して,引用発明においては,「クライアントが対応するデコーダを有して
いない場合には,スケジューラー管理エンジンは,デコーダURIを得ることをデ
コーダ・コンポーネント管理エンジンに指示する。デコーダ・コンポーネント管理
エンジンは,どこにデコーダが格納されているかをコンテンツサーバに要求する」
のであって,本願補正発明には,このような要求を必要としないという効果がある。
〔被告の主張〕
(1)本件審決は,相違点4に係る本願補正発明の構成として「「マルチメディア
コンテンツ」の中に,「コーデックサーバの位置情報」と「第1のソフトウェアモジ
ュールの識別情報」が含まれる」としているところ,モジュールのみをダウンロー
ドする点については,相違点2として判断し,相違点4は,そのような相違の下で,
本願補正発明が「「マルチメディアコンテンツ」の中に,「コーデックサーバの位置
情報」と「第1のソフトウェアモジュールの識別情報」が含まれる」ことを相違点
として挙げたのであって,ダウンロードに用いる情報を取得する手法について判断
したもの,すなわち,公知文献1及び2は,ダウンロードに際して必要となる,「ど
こから」「何を」の各情報を取得する手段として,各情報をコンテンツに含ませてコ
ンテンツとともに得る構成を容易というために用いている。
すなわち,得ようとする各情報が「モジュール」を対象としたものとすることは,
相違点2で判断した上で,さらに,相違点4について,公知文献1及び2の「コン
テンツとともに,デコーダをダウンロードするためのサーバの位置情報を提供する
こと」及び「コンテンツの中にデコーダを識別するための情報が含まれるようにす
ること」という公知技術を組み合わせることで,本願補正発明の「「マルチメディア
コンテンツ」の中に,「コーデックサーバの位置情報」と「第1のソフトウェアモジ
ュールの識別情報」が含まれる」とすることは容易であると判断したものである。
(2)本願補正発明は,マルチメデイアコンテンツの符号化の仕組みが異なる場合,
それを復号するために必要な復号プログラムを得るために,復号プログラム全体(全
体プログラム)をダウンロードするのではなく,「全体プログラム」を構成する各プ
ログラム(部分プログラム)の中で異なる符号化の仕組みに必要な「部分プログラ
ム」のみをダウンロードするというものである。
本件審決は,「全体プログラム」をダウンロードするのではなく,「部分プログラ
ム」をダウンロードすることについては,相違点2において,本願補正発明の「ソ
フトウェアモジュール」,すなわち,部分プログラムとして「第1のソフトウェアモ
ジュール」をダウンロードする点について判断しているのであるから,本件審決が
「本願補正発明の「ソフトウェアモジュール」については何も判断していないとす
る原告の主張は理由がない。
(3)原告は,本願補正発明は,各情報がコンテンツに含まれ,コンテンツととも
に得ることができるから,引用発明のようにクライアントからサーバにコンテンツ
とは別に各情報を要求する必要がないとの効果がある旨主張するが,相違点につい
てした判断の結果として容易に想到される構成から予測されるものであり,この効
果により特許を受けることができるとはいえない。
4取消事由4(本願補正発明と引用発明との相違点1及び2に係る判断の誤り)
について
〔原告の主張〕
(1)本件審決は,本願補正発明と引用発明との相違点1について,引用発明にお
ける「コアエンジン」について,引用例における記載に基づいて,DSPによるハ
ードウェアを採用することによって,本願補正発明のように,「デジタルシグナルプ
ロセッサ(DSP)処理部」とすることや,引用発明における実行コードを,本願
補正発明のように,「DSPコード」とすることは,当業者であれば容易に想到でき
る旨判断した。
また,本件審決は,本願補正発明と引用発明との相違点2について,引用発明に
おいて,「デコーダ情報」に基づき,「デコーダのバイナリデータ」をダウンロード
して記憶し,「デコーダ」に対応するメディア又はコンテンツが再生される構成につ
いて,引用例に開示されるような,デコーダが複数のモジュールにより構築される
モジュールベースデコーダの考え方を採用し,モジュールに対応するメディアコン
テンツやモジュール識別情報の構成,複数のデコーダモジュールを組み合わせてデ
コーダを生成する手段を設けることによって,本願補正発明のように,「ソフトウェ
アモジュールの識別情報」に基づきダウンロードして記憶し,記憶された複数の「ソ
フトウェアモジュール」を組み合わせてコーデックのコードを生成し,「ソフトウェ
アモジュール」に対応するマルチメディアコンテンツを処理するようにすることは,
当業者であれば容易に想到できる旨判断した。
(2)しかし,引用発明では“coreengine”にデコーダを設置しており,“core
engine”はメディア再生又は中止などを制御するCPUに該当するから,引用発明
のデコーダダウンロード及び設置に関するソフトウェアはCPU上で動作するソフ
トウェアであって本願補正発明のDSPコードとは異なる。引用発明には,コンポ
ーネント化されているソフトウェアによりデコーダを形成する一部モジュールに対
する変更を行う構成が開示されているかもしれないが,OSなどの実行環境が劣悪
であるというDSPの特性上コンポーネント化されていないソフトウェアを備える
しかないDSPに対し,新規コーデックが要求される際にコーデックを変更するた
めに最小限の資源を用いてDSP規格に合うDSPコードを容易に提供することに
ついては,引用例にはいかなる開示も示唆もない。
これに対して,本願補正発明は,コンポーネント化されたソフトウェアの使用が
容易ではないDSPによりコーデックを支援する回路環境で新規コーデックが要求
されるたびに大容量のDSPコードを適用及び交替することにより発生する相当量
のオーバーヘッドを最小化するため,コンテンツを再生するたびにリアルタイムで
CPU(DSPコード生成部)で適切なコーデックライブラリを選択するようにした
後,選択されたコーデックライブラリとOS及びメディアフレームワークを組み合
わせてDSPコードを生成し,生成されたDSPコードをDSP処理部に提供し,
DSP処理部では提供されたDSPコードに基づいてコンテンツを再生するための
デコーディングを行うことにより,DSPはコンテンツを再生するたびにCPUか
らDSPコードを提供される構成としたものであり,かかる構成,効果を検討せず
に相違点1及び2について容易想到であると判断した本件審決は誤りである。
(3)被告の主張(1)に対して
引用例には,いくつかのIDCTモジュールの中でDSPという「ハードウェア
仕様…に適したIDCTモジュールを選択」することができると記載されているの
であって,DSPで複数のIDCTモジュールを用いることができ,IDCTの変
更を実施できる旨の記載はない。
また,引用例に,一体化したソフトウェアの課題認識があったとしても,それは
システム全体としての課題認識であり,DSPにおける課題認識が示唆されている
ものではない。
さらに,本願補正発明では,コーデックライブラリだけでなく,OS,メディア
フレームワーク及びハードウェアライブラリのソフトウェアを組み合わせて新たな
「DSPコード」を生成しているのに対し,引用発明の「デコーダ・コンポーネン
ト管理エンジン」は「コアエンジン」に対して「デコーダモジュール」のみを供給
しているところ,この「デコーダモジュール」は,本願明細書の「コーデック」に
相当するものであり,新たなDSPコードを生成する機能は有していない。
(2)被告の主張(2)に対して
引用例には,ハードウェア仕様に適したデコーダを選択することは記載されてい
ても,同一のハードウェア仕様について複数のデコーダを選択的にダウンロードし
て用いることは記載されていない。
さらに,本願補正発明は,DSPに最適のDSPコードを提供するため,CPU
及びDSP間の連動構造を備えているのに対し,引用発明は,コアエンジンとして
DSPを採用する構成上の違いがある。
〔被告の主張〕
(1)本件審決は,引用例記載のコンポーネント化されているソフトウェアにより
デコーダを形成する一部モジュールに対する変更を行う構成を,引用発明に採用す
ることが容易であることについて相違点2において判断し,DSPに対するものと
することを相違点1において判断している。
引用例には,一体化したソフトウエアについての課題認識がある上,クライアン
トのハードウェア仕様をDSPとし,DSPに適しているIDCTモジュールを選
択する構成が例示されているのであって,DSPにおける課題認識も示唆されてい
るというべきであるから,当業者が引用発明のハードウェア仕様をDSPとして具
体化するに際し,DSPに適したモジュールを選択・組み合わせてDSPコードを
生成しDSPに提供する構成を採用することは容易である。
また,DSPとしたとき,一体化したソフトウエアの課題がDSPにおいても解
決されることは当然に予想されることであり,引用発明から容易に想到する構成に
おいて,本願補正発明が奏するDSPにおける効果は予測されるものである。
(2)原告の主張(3)に対して
引用例の「例えば,同じビットストリーム解析を共有するために,クライアント
のハードウェア仕様(MMX,3DNow!,DSP,ASICなど)に適してい
るIDCTモジュールを選択することができる。」との記載中,「IDCTモジュー
ル」とは,映像符号化において用いられる離散コサイン変換「DCT」を,復号に
おいて元に戻す逆DCT変換を行うプログラムを指し,変換にDCTを用いたコー
デックの場合を例にして説明したものである。そして,上記記載それ自体は,DS
Pに対してDSP用のIDCTモジュールを選択することを述べたものであるが,
同時に,引用例記載のフレキシブルデコーダにおいて,デコーダがインストールさ
れるパーツである「コアエンジン」としてDSPを採用することを示唆する記載で
もあり,この記載を相違点1の判断根拠とした本件審決に誤りはない。
第4当裁判所の判断
1本願補正発明について
(1)本願補正発明の特許請求の範囲は,前記第2の2(2)記載のとおりであると
ころ,本願明細書(甲7)には,おおむね次の内容の記載がある。
ア技術分野
本発明は,ソフトウェアモジュールの組合せによってDSPコードを生成する装置及びその
方法に係り,より詳細には,DSPコードのソフトウェアモジュールのうち必要なモジュール
のみを伝送されて,各々のソフトウェアモジュールを組み合わせて所定のDSPコードを生成
する装置及びその方法に関する(【0001】)。
イ背景技術
(ア)現在,放送,通信,及びインターネットの環境で多様なコーデックが発展しており,
また,コーデックの圧縮率が高くなって,拡張性が上がることによってコンテンツ提供者及び
ネットワーク事業者は多様なコーデックを使おうとする(【0002】)。
これによって,DTV,セットトップボックス(STB)などのレンダリング機器で多様な
メディアフォーマットを適用しようとDSP(DigitalSignalProcessing)を用いてメディア
デコーダを具現しようとする試みがあり,DSPで実行されるソフトウェアを異ならせて,さ
まざまのコーデックを適用できる(【0003】)。
一般的に,DSPは,高速性能を具現するようにパイプライン演算器を中心に構成する場合
が多い。特に,DSPは,リアルタイム処理が要求される分野で多く使われるので,ハードウ
ェア能力の限界まで性能を具現するようにソフトウェア作業を頻繁にしなければならない(【0
004】)。
(イ)
図1Aは,従来のDSP基盤のレンダリング機器の典型的な形態を示す図面である。示され
たように,レンダリング機器は,ホストCPU10,DSP20,及び記憶部(図1Aでは「貯
蔵部」,以下同じ。)例えば,ROM,及びRAM)30として構成される(【0009】)。
まず,DSPブーティングの時,DSP20が記憶部(例えば,ROM)30からDSPコ
ードを読み取って実行させ得る。しかし,ホストCPU10がDSP20に実行コードをロー
ディングした後,DSPをブーティングさせることもできる(【0010】)。
次いで,DSP基盤のデコーディングデバイスは,コーデック別にDSPコードが異なるの
で(すなわち,コーデックによって実行されるDSPが異なるので),ホストCPU10が現在
のコーデックに適合したDSPコードをDSP20にダウンロードさせる(【0011】)。
一方,ホストCPU10なしにDSP20のみで構成されても良く,この場合,ブーティン
グの時,DSP20が記憶部(例えば,ROM)30からDSPコードを読み取って実行する
(【0012】)。
(ウ)
図1Bは,従来のDSPコーデックの伝送及びダウンロードを実行する過程を示す図面であ
る。示されたように,ホストCPU10のROM30には,多様なDSPコードが存在できる
(例えば,H.264コーデック用DSPコード,MPEG2コーデック用DSPコードなど)。
ここで,ROM30に記憶されたDSPコードはブーティングの時,DSP20にロードされ
る(【0013】)。
一方,必要なDSPコーデックがシステム内部のROM30に存在しない場合,該当DSP
コードをネットワークを通じてコーデックサーバでダウンロードしてROM30に記憶してお
いて,必要の時ごとに使うようにする(【0014】)。
しかし,DSPコードは,一般的なPC用プログラムより動作環境が劣悪な問題点がある。
すなわち,PCのように汎用のOSがあって,アプリケーションプログラムが前記OS上で動
作する構造ではなく,DSP20に合うように具現されたコーデック用ソフトウェア全体(例
えば,OS,コーデックライブラリ,メディアフレームワーク,及びハードウェアライブラリ
など)が一つのDSPコードを形成しており,コーデックが変わるたびにこのDSPコード全
体が再びDSP20にローディングされなければならないという問題点がある(【0015】)。
したがって,ネットワークを通じて遠隔サーバでダウンロードされるDSPコードでコーデ
ックライブラリのみが変更されて,OS,メディアフレームワーク,及びハードウェアライブ
ラリなどは,ROM30に記憶された他のDSPコードと共通に所有する部分に,不要なソフ
トウェアモジュールが含まれて伝送されるので,DSPコードのダウンロードの時,ネットワ
ークにオーバーヘッドが発生し,また,ROMの記憶空間を多く占めるという問題点がある(【0
016】)。
ウ発明が解決しようとする課題
本発明は,外部ネットワークに位置したコーデックサーバからDSPコードのソフトウェア
モジュールのうち必要なモジュール(例えば,コーデックライブラリ)のみを伝送された後,
各々のソフトウェアモジュールを組み合わせて所定のDSPコードを生成するところにその目
的がある。
本発明は,前述した目的に制限されず,言及されなかったさらなる目的は,下記の記載から
当業者に明確に理解されるであろう(【0018】)。
エ発明の効果
本発明のソフトウェアモジュールの組合せによってDSPコードを生成する装置及びその方
法によれば,次のような効果が一つあるいはそれ以上ある(【0021】)。
外部ネットワークに位置したコーデックサーバからDSPコードのソフトウェアモジュール
のうち必要なモジュール(例えば,コーデックライブラリ)のみを伝送された後,各々のソフ
トウェアモジュールを組み合わせて該当DSPコードを生成することによって,必要なソフト
ウェアモジュールのみをダウンロードされるので,ソフトウェアをダウンロードされる時間を
減らし得る長所がある(【0022】)。
また,必要なソフトウェアモジュール(例えば,コーデックライブラリ)のみを伝送された
後,記憶することによって,記憶空間の無駄使いを減らすことができ,より効率的に記憶空間
を活用できる長所がある。また,DSPで駆動されるソフトウェアモジュールをより効果的に
管理できる長所がある(【0023】)。
オ発明を実施するための最良の形態
(ア)【図2】
図2は,本発明の一実施形態によるソフトウェアモジュールの組合せによってDSPコード
を生成する装置の内部ブロック図を示す図面である。ここで,マルチメディア再生装置100
は,放送コンテンツ及び一般動映像コンテンツを再生するもので,例えば,DTV,セットト
ップボックス,及び移動通信端末機などを言う(【0026】)。
示されたように,マルチメディア再生装置100は,受信部110,送信部120,記憶部
(図2では「貯蔵部」,以下同じ。)130,DSPコード生成部140,DSP処理部150,
及び制御部160を含んで構成される(【0027】)。
受信部110は,外部ネットワークに位置したコーデックサーバから伝送されたソフトウェ
アモジュールを受信する。ここで,ソフトウェアモジュールは,OS,コーデックライブラリ,
メディアフレームワーク,及びハードウェアライブラリを含む。ここで,OS,コーデックラ
イブラリ,メディアフレームワーク,及びハードウェアライブラリに構成されたコードをDS
Pコードと言う。また,コーデックの種類は,MPEG-2,MPEG-4,H.264,及
びVC1などに理解され得る。すなわち,受信されるコーデックライブラリは,例えば,MP
EG-2ライブラリ,H.264ライブラリである(【0029】)。
送信部120は,外部ネットワークに位置したコーデックサーバに所定のコーデックライブ
ラリのダウンロードを要求するコーデック要求メッセージを伝送する(【0030】)。
記憶部130は,所定マルチメディアコンテンツの動作実行のための少なくとも一つ以上の
ソフトウェアモジュールを記憶するが,ここで,記憶部130は,HDD,フラッシュロム(R
OM)などを言う(【0031】)。
DSPコード生成部140は,所定のマルチメディアコンテンツを実行させるためのDSP
コードを生成するもので,すなわち,記憶部130に記憶された各々のソフトウェアモジュー
ルを組み合わせて一つのDSPコードを生成する(【0032】)。
例えば,MPEG-2を支援するDSPコードが必要な場合,MPEG-2ライブラリとO
S,メディアフレームワーク,及びハードウェアライブラリとを組み合わせて最終DSPコー
ドを生成する。したがって,生成されたDSPコードは,MPEG-2コーデック用DSPコ
ードになる(【0033】)。
DSP処理部150は,DSPコード生成部140が生成したDSPコードを処理するもの
で,例えば,DSPコードをデコーディングして該当DSPコードを実行させ,所定マルチメ
ディアコンテンツを実行させる(【0034】)。
制御部160は,マルチメディア再生装置100内に所定のマルチメディアコンテンツを実
行させるためのコーデックライブラリが存在しない場合,コーデック要求メッセージを作成し
て外部ネットワークに位置したコーデックサーバに伝送する(【0035】)。
また,制御部160は,マルチメディアコンテンツ提供者から伝送されたデータパケットを
通じてマルチメディア再生装置100で実行させる所定マルチメディアコンテンツについての
コーデック情報が分かり,これによりユーザーの所定マルチメディアコンテンツ再生要求の時,
該当マルチメディアコンテンツを再生させるDSPコードをDSPコード生成部140に要求
する。以下の(ウ)の図4でデータパケットについては説明する(【0036】)。
また,制御部160は,マルチメディア再生装置100を構成する各機能性ブロック110
ないし150の動作を制御する(【0037】)。
(イ)【図3】
図3は,本発明の他の実施形態によるソフトウェアモジュールの組合せによってDSPコー
ドを生成する装置の動作を概略的に示す図面である。示されたように,記憶部(図3では「貯
蔵部」,以下同じ。)130には,各々のソフトウェアモジュール(例えば,OS,コーデック
ライブラリ,メディアフレームワーク,及びハードウェアライブラリ)が記憶されている(【0
038】)。
ユーザーが所定マルチメディアコンテンツの再生を要求することによって,制御部160が
所定マルチメディアコンテンツの実行に必要なDSPコードを要求して,これによりDSPコ
ード生成部140は,記憶部130に記憶されたソフトウェアモジュールを組み合わせて一つ
のDSPコードを生成する(【0039】)。
例えば,所定マルチメディアコンテンツを実行するためにMPEG-2コーデック(例えば,
コーデックライブラリ1)が必要な場合,DSPコード生成部140は,記憶部130に記憶
されたソフトウェアモジュールのうちOS,コーデックライブラリ1,メディアフレームワー
ク,及びハードウェアライブラリを組み合わせてMPEG-2コーデック用DSPコードを生
成する(【0040】)。
次いで,DSPコーデック生成部140は,生成されたMPEG-2コーデック用DSPコ
ードをDSP処理部150にローディングして,DSP処理部150は,ローディングされた
MPEG-2コーデック用DSPコードをデコーディングして,該当マルチメディアコンテン
ツを実行させる(【0041】)。
一方,マルチメディアコンテンツを実行するためにMPEG-2コーデックが記憶部130
に記憶されていない場合,制御部160は,該当コーデックライブラリ(例えば,MPEG-
2ライブラリ)を要求するコーデック要求メッセージを作成して外部ネットワークに位置した
コーデックサーバに伝送する(【0042】)。
以後,コーデックサーバから該当コーデックライブラリ(例えば,コーデックライブラリ4)
が伝送されれば,制御部160は,該当コーデックライブラリ(例えば,コーデックライブラ
リ4)を記憶部130に記憶して,DSPコーデック生成部140は,新しくダウンロードさ
れたコーデックライブラリを用いて該当DSPコードを生成する(【0043】)。
(ウ)【図4】
図4は,本発明のまた他の実施形態によるソフトウェアモジュールの組合せによってDSP
コードを生成する装置から所定マルチメディアコンテンツについてのコーデック情報を提供さ
れるデータパケットを示す図面である(【0044】)。
示されたように,マルチメディアコンテンツ提供者から伝送されたデータパケットには,マ
ルチメディアコンテンツの題目410,マルチメディアコンテンツを再生するのに必要なコー
デックの名称及びコーデックについての付加情報(例えば,該当コーデックの圧縮率及びバー
ジョン情報など)を含むコーデック情報420,及び該当コーデックをダウンロードされるこ
とができるコーデックサーバのアドレス430を含む(【0045】)。
したがって,前記データパケットを通じてマルチメディア再生装置100で実行されるマル
チメディアコンテンツのコーデック情報が分かる。これにより,ユーザーによって所定マルチ
メディアコンテンツが選択されれば,該当マルチメディアコンテンツを実行させ得るコーデッ
クライブラリに生成されたDSPコードが提供される(【0046】)。
(エ)【図5】
図5は,本発明のさらに他の実施形態によるソフトウェアモジュールの組合せによってDS
Pコードを生成する方法を示すフローチャートである。ここで,記憶部130にソフトウェア
モジュール,OS,メディアフレームワーク,及びハードウェアライブラリは記憶されている
と仮定する(【0047】)。
まず,ユーザーが所定マルチメディアコンテンツの再生を要求することによって制御部16
0は,前記マルチメディアコンテンツの実行に必要なDSPコード(例えば,MPEG-2コ
ーデック用DSPコード)を要求する(S510)。ここで,制御部160は,データパケット
を通じてユーザーが選択したマルチメディアコンテンツを実行させるコーデック情報が分かる
(【0048】)。
次いで,DSPコード生成部140は,制御部160が要求したDSPコードを生成するた
めに記憶部130に該当コーデックライブラリが存在するか否かを判断する(S520)。判断
の結果,記憶部130に該当コーデックライブラリ(例えば,MPEG-2ライブラリ)が存
在する場合(S530),DSPコード生成部140は,記憶部130に記憶されたコーデック
ライブラリ,OS,メディアフレームワーク,及びハードウェアライブラリを組み合わせて制
御部160が要求したDSPコードを生成する(S540)(【0049】)。
次いで,生成されたDSPコード(例えば,MPEG-2コーデック用DSPコード)をD
SP処理部150にローディングして(S550),DSP処理部150は,ローディングされ
たDSPコードをデコーディングして,該当マルチメディアコンテンツが実行されるように処
理する(S560)(【0050】)。
一方,判断の結果,記憶部130に該当コーデックライブラリ(例えば,MPEG-2ライ
ブラリ)が存在しない場合(S530),制御部160は,該当コーデックライブラリ(例えば,
MPEG-2ライブラリ)を要求するコーデック要求メッセージを作成して,作成されたコー
デック要求メッセージを送信部120を通じて外部ネットワークに位置したコーデックサーバ
に伝送する(S570)(【0051】)。
以後,コーデックサーバから該当コーデックライブラリ(例えば,MPEG-2ライブラリ)
が伝送されれば,受信部110は,伝送されたコーデックライブラリを受信して,受信された
コーデックライブラリは,記憶部130に記憶される。次いで,DSPコーデック生成部14
0によって該当DSPコードが生成される(【0052】)。
したがって,DSPコードを構成するソフトウェアモジュールのうち必要なモジュール(例
えば,コーデックライブラリ)のみを伝送されることによって,該当ソフトウェアモジュール
のダウンロード時間を減らすことができ,ネットワーク負荷を減らし得る(【0053】)。
(2)前記(1)の記載によれば,本願補正発明の概要は,以下のとおりのものであ
ると認められる。
DTV等のレンダリング機器では,DSPを用いてメディアデコーダを具現しよ
うとする試みがあり,DSPで実行されるソフトウェアを異ならせて様々なコーデ
ックを適用しているところ,レンダリング機器は,ホストCPU,DSP及び記憶
部で構成され,DSPが記憶部からDSPコードを読み取って実行させるものであ
るが,DSP基盤のデコーディングデバイスは,コーデック別にDSPコードが異
なるため,ホストCPUが現在のコーデックに適合したDSPコードをDSPにダ
ウンロードする。
ところで,従来,必要なDSPコードがシステム内部の記憶部に存在しない場合,
そのDSPコードをネットワークを通じてコーデックサーバからダウンロードし,
記憶部に記憶しておいて,必要なときに使うようにしていたが,DSPコードは,
PCのように汎用のOSがあってアプリケーションプログラムがOS上で動作する
構造ではなく,DSPに合うように具現されたコーデック用ソフトウェア全体(例
えば,OS,コーデックライブラリ,メディアフレームワーク,ハードウェアライ
ブラリ等)が一つのDSPコードを形成しており,コーデックが変わるたびにこの
DSPコード全体が再びDSPにローディングされなければならないという,一般
的なPC用プログラムより動作環境が劣悪な問題点があり,そのため,ネットワー
クを通じてダウンロードされるDSPコードのうち,コーデックライブラリのみが
変更され,OS,メディアフレームワーク,ハードウェアライブラリ等は,記憶部
に記憶された他のDSPコードと共通であるにもかかわらず,不要なOS,メディ
アフレームワーク,ハードウェアライブラリ等も含まれて伝送されるので,DSP
コードのダウンロードを行う際には,ネットワークにオーバーヘッドが発生し,記
憶部の記憶空間を多く占めるという問題点があった。
本願補正発明は,外部ネットワークに位置したコーデックサーバから,DSPコ
ードのソフトウェアモジュールのうち必要なモジュール(例えば,コーデックライ
ブラリ)のみを受信し,各々のソフトウェアモジュールを組み合わせて,所定のD
SPコードを生成することを目的として,本件補正後の特許請求の範囲請求項1の
とおり,デジタルシグナルプロセッサ(DSP)処理部と,コーデックサーバから
第1のソフトウェアモジュールをダウンロードする手段と,ダウンロードされた第
1のソフトウェアモジュールと,少なくとも第2のソフトウェアモジュールとを記
憶する記憶部と,前記記憶された第1と第2のソフトウェアモジュールを組み合わ
せてDSPコードを生成し,前記DSP処理部にロードするDSPコード生成部と,
を有し,前記DSP処理部は前記ロードされたDSPコードをデコーディングして,
前記第1のソフトウェアモジュールに対応するマルチメディアコンテンツを処理し,
前記マルチメディアコンテンツは前記コーデックサーバの位置情報と前記第1のソ
フトウェアモジュールの識別情報とを含み,前記マルチメディアコンテンツに対応
する前記第1のソフトウェアモジュールが前記記憶部に記憶されていない場合,前
記コーデックサーバの位置情報と前記第1のソフトウェアモジュールの識別情報と
に基づき,外部ネットワークに位置した前記コーデックサーバに前記第1のソフト
ウェアモジュールのダウンロードを要求するメッセージを生成及び伝送する制御部
をさらに有することを特徴とする装置である。
2引用例について
(1)引用例(甲1)には,おおむね,次の内容の記載がある。
「コンテンツ指向符号化のための新しいデコーダ・ダウンロード可能システム」
ア要約
(ア)この論文では,デコーダ・ダウンロード可能システムと呼ぶ新しいシステムアーキテ
クチャを説明する。このシステムの目的は,コンテンツの特徴を用いた画像圧縮に基づくマル
チメディア世界のための統一プラットフォームを提供することである。このシステムにより,
途切れなく遅延が最小となる再生のための,サーバとクライアント間のネゴシエーションによ
りデコーダの動的ダウンロードが可能となる。このネゴシエーション方式はJavaとCOR
BA(CommonObjectRequestBroker)により実装される。よって,このシステムのサーバと
クライアントはOSとハードウェア仕様とは独立である。このシステムは,インターネットス
トリーミングのみならずテレビ放送にも適している。
(イ)我々は,システムをより柔軟にするため,デコーダアーキテクチャを改善する。デコ
ーダは,ビットストリーム解析,画像圧縮アルゴリズム(DCT,ウェーブレット,動き推定
など)などの複数の機能を有する。しかし,従来のデコーダは一体のソフトウェアである。そ
のため,デコーダのパーツを共有することができない。提案する方法により,モジュールベー
スのデコーダと,複数のデコーダ間でモジュールを共有することが可能となる。結果として,
フレキシブルデコーダにより,デコーダの冗長なパーツのダウンロードを回避することにより,
ダウンロード時間を短くできる。また,スケーラビリティも実現され,このシステムをマルチ
メディアプレーヤのみならずマルチメディアコンテンツ検索システムなどのマルチメディアア
プリケーションで用いることができる。
イイントロダクション
(ア)MPEGやJPEGなどの離散余弦変換(DCT)ベースの符号化が画像圧縮に広く
使われている。しかし,DCTベースのアプローチは,全種類の画像に適しているというわけ
ではない。ある種の画像は,画像コンテンツの特徴を考慮した方法により,効率的に符号化で
きる。これを「コンテンツ指向符号化方式」と呼ぶ。その例として,アニメーション画像符号
化を研究している。この研究から,アニメーション画像デコーダをインターネットストリーミ
ングとTV放送で配信できるオープンシステムアーキテクチャが望まれる。しかし,要求を満
たすオープンシステムはまだ報告されていない。そこで,「デコーダ・ダウンロード可能システ
ム」と呼ぶシステムを実装する。この論文において,システムアーキテクチャを提示する。
(イ)コンテンツ指向符号化方式に基づくマルチメディアの世界では,画像圧縮アルゴリズ
ムの数は増加すると見込まれる。従来のデコーダはモノリシックのソフトウェアとして開発さ
れている。しかし,複数のデコーダが共有できるパーツがある。よって,モジュールベースの
デコーダを実現することにより,これらの冗長性をなくすことができる。モジュールベースの
デコーダはモジュールにより構成され,複数のデコーダ間でモジュールを共有するものである。
こうしたモジュールベースのデコーダを「フレキシブルデコーダ」と呼ぶ。このシステム中の
デコーダはフレキシブルデコーダとして設計されているため,複数の利点を提供できる。
…(略)…
ウデコーダ・ダウンロード可能システム
(ア)プラグインシステムの問題
MicrosoftMediaPlayerやRealPlayerなどのインターネット上のマルチメディアシステム
は,必要な時に適切なソフトウェアをインストールすることにより,新しいタイプのメディア
を処理する機能を提供する。任意的にダウンロードされるこうしたソフトウェアはプラグイン
と呼ばれる。しかし,プラグインシステムには次の問題がある。
新しいコンテンツが始まっても,クライアントが適したデコーダを有していない時に時間遅
延が生じる。デコーダをダウンロードするのに,追加的に時間がかかるからである。これによ
り,コンテンツの途切れのない再生が中断され,特にテレビ放送の場合には大きな問題となる。
…(略)…
(イ)提案するシステムアーキテクチャ
このセクションでは,デコーダを動的にダウンロードし,遅延なしに再生できるシステムア
ーキテクチャを提案する。
a提案するシステムアーキテクチャを図2に示す。
クライアントは5つのパーツにより構成される。5つのパーツとは,「コアエンジン」,「スケ
ジュール管理エンジン」,「デコーダコンポーネント管理エンジン」,「ファイルI/O」,「ユー
ザインタフェース」である。パーツ間の各インタフェースは図2において○数字で示した。
【図2】
サーバ側には,コンテンツの実際のビットストリームを格納する「コンテンツサーバ」,デコ
ーダのバイナリコードを格納する「デコーダサーバ」,及び各コンテンツのプロフィールを記述
した情報(以下,コンテンツ情報と呼ぶ)を格納する「情報サーバ」がある。対応するコンテ
ンツ情報を情報サーバにより容易に読み出すため,この情報は階層構造を有する。図3にコン
テンツ情報を示す。各サーバは同じマシン上にあっても,ロードバランシングができるように
異なるマシン上にあってもよい。(判決注:図3には,「情報サーバ」が格納する各コンテンツ
のプロフィールを記述した情報(コンテンツ情報;contentinformation)について,コンテン
ツ名(contentname),作者(author),コンテンツID(contentID)及び最適なデコーダ(optimum
decoder)等の情報から構成されることが記載されている。)
【図3】
クライアントシステムはJavaを用いて実装する。メディア処理の部分はJMF(Java
MediaFramework)を用いて開発されている。こうしたのは,提案するシステムが様々な環境で
動作しなければならないからである。現時点は,Javaを用いてメディア処理の部分を構成
することには多少の疑問がある。そのため,JMFに依存するメディア処理をするモジュール
は他の部分から完全に取り外せるように,システムアーキテクチャを設計した。しかし,Ja
vaにより開発したデコーダは,サーバがクライアントのオペレーティングシステムの種類を
心配しなくて良いとのメリットが得られる。これらのデコーダはフレキシブルデコーダとして
も有用である。
CORBA(CommonObjectRequestBroker)は,サーバとクライアントとの間の,ハード
ウェアの仕様とは独立であるインタフェースの規定に用いられる。さらに,このシステムは,
CORBAGIOP(GeneralInter-ORBProtocol)により,どのトランスポートプロトコ
ルからも独立している。それゆえ,このシステムは,インターネット,テレビ放送,モバイル
システムなどで利用できる。
bこのシステムのプロシージャは次の順序で実行される:
(a)クライアントシステムのスケジューラ管理エンジンがスタートし,コンテンツ情報を取
得する。このエンジンがコンテンツ情報を解析し,デコーダコンポーネント管理エンジンに,
クライアント側にデコーダがあるかどうか確認する。
(b)クライアントが対応するデコーダを有していない場合,スケジューラ管理エンジンはデ
コーダコンポーネント管理エンジンにデコーダURIを取得するように命令する。デコーダコ
ンポーネント管理エンジンは,コンテンツサーバに,デコーダがどこに記憶されているか要求
する。
(c)情報サーバは,デコーダ情報を用いて,要求されたデコーダがどこに記憶されているか
探し始める。クライアントにデコーダURIを返す。
(d)スケジューラ管理エンジンは,デコーダサーバからのデコーダのダウンロードを何時開
始するか決定し,デコーダコンポーネント管理エンジンに命令する。この命令をするタイミン
グは非常に重要である。何故なら,ネットワークの帯域幅が狭い場合などに,デコーダのダウ
ンロードにより連続的なメディア再生が中断されるからである。
cシステム中の各パーツの役割は次のとおりである:
・コアエンジン
このパーツは,メディア再生やトリックモードなどの実装を提供する。デコーダは実際には
このパーツにインストールされる。
・デコーダコンポーネント管理エンジン
このパーツは,クライアントシステム中のデコーダを管理し,どのデコーダが必要か問い合
わせ,デコーダをダウンロードし,ストックされているデコーダを削除する。
・スケジュール管理エンジン
このパーツは,メディア再生を何時開始するか,デコーダを何時ダウンロードするか,又は
デコーダを何時削除するか制御する。実際の機能を提供する各パーツに,タイムリーに命令す
る。
・ユーザインタフェース
このパーツはユーザ入力のインタフェースである。
・ファイルI/O
このパーツは,その使用目的に基づきプロトコルを選択する:1)CORBA,コンテンツ
情報の送受信,2)HTTP/FTP,デコーダのバイナリデータのダウンロード,3)RT
P/MPEG2-TS,メディアデータの受信。
dシステム中の各インタフェースを以下に説明する:
インタフェース1:デコーダに関する情報の交換
インタフェース2:コンテンツに関する情報の交換
インタフェース3:デコーダのバイナリデータのダウンロード
インタフェース4:コンテンツのメディアデータのダウンロード
インタフェース5:クライアントのスケジューラで用いられるEPG(電子番組案内)のダ
ウンロード
インタフェース6:コアエンジンへのデコーダモジュールの供給
インタフェース7:デコーダのメモリへのロードが何時始まるか示し,メモリロードがどの
状態にあるかに関する情報を提供
インタフェース8:デコーダが追加されるのか削除されるのかをユーザに示す
インタフェース9:コンテンツに関する情報を提供し,クライアントシステムにおいてデコ
ーダのダウンロード及び削除を何時開始するか示し,デコーダの存在を
確認
インタフェース10:ユーザによる入力情報の受け取り
インタフェース11:再生可能なコンテンツの情報の表示,ユーザによるコンテンツの選択
…(略)…
エフレキシブルデコーダ
(ア)機能
フレキシブルデコーダにより,モノリシックプログラムとして扱われず,複数の機能を提供
する複数のモジュールの集まりとして扱われるアーキテクチャが可能となる。フレキシブルデ
コーダは,MPEG-4システムにおける標準化で検討されたことがある。MPEG-4は,
効率的な圧縮だけでなくユーザのコンテンツベースの操作などの機能を提供する柔軟かつ拡張
可能なアーキテクチャを確立するように設計された。フレキシブルデコーダアーキテクチャは,
MPEG-4システムの標準には含まれないが,このアーキテクチャにより,新しいタイプの
メディアコンテンツが届いた時に,クライアントが,必要なモジュールのみをダウンロードす
ることによりデコーダを構成できる。このアーキテクチャにより,デコーダをダウンロードす
るためのネットワーク帯域幅とクライアント又はサーバのリソースを削減できる。それゆえ,
デコーダダウンロードシステムにおいてフレキシブルデコーダを用いると効率的である。
(イ)フレキシブルデコーダへのアプローチ
先行文献はフレキシブルデコーダのための方法を示している。この文献に基づきデコーダを
開発することにより,復号プロセスが継続中に,ユーザがDCTやウェーブレットなどの画像
処理アルゴリズムを変更できる。デコーダの機能の分離は,3コンポーネントモデルにより実
現できる。3コンポーネントモデルは,デコーダが,図5に示した,①ビットストリーム解析
ブロック,②データ再生ブロック,及び③画像再構成ブロックに分かれることを意味する。ビ
ットストリーム解析ブロックは,ビットストリームをそのシンタックスに従って解析する。画
像再構成ブロックは,実際の画像復号アルゴリズムを提供する。データ再生ブロックは,ビッ
トストリーム解析ブロックと画像再構成ブロックとの間の分離で重要な役割を有する。データ
再生ブロックは画像再構成ブロックに対してデータアライメントを提供する。これは,データ
再生ブロックと画像再構成ブロックとの間の変換プロセスと考えることができる。結果として,
データ再生ブロックがあることにより,一方の側での変更が他方の側に影響しなくなる。
このデコーダアーキテクチャは,フレキシブルデコーダにとって非常に有用であると思われ
る。しかし,デコーダをモノリシックプログラムとして開発することを意味する従来の方法と
比べて,このアーキテクチャに従ってデコーダを開発することは,より難しくなる。
【図5】
(ウ)ビットストリーム解析からの画像処理の分離
この提案では,ビットストリーム解析するモジュールは,画像を復号するモジュールから完
全に分離される。これにより,デコーダは,同じ画像復号アルゴリズムのための様々なモジュ
ールを用いられる。例えば,クライアントのハードウェア仕様(MMX,3DNow!,DS
P,ASICなど)に適したIDCTモジュールを選択して,同じビットストリーム解析を共
有できる。デコーダ・ダウンロード可能システムは,メディア処理のみならずサーチエンジン
などの様々なマルチメディアシステムに使うことができる。この柔軟性は,単に画像復号アル
ゴリズムのモジュールを他のプロセスのもので置き換えることにより実現できる。分離をより
柔軟にするため,Javaなどのクライアントに依存しないデコーダソフトウェアを利用する。
…(略)…
オ結論
本論文では,コンテンツ指向の符号化方式のための新しいシステムアーキテクチャを提案し
た。このシステムにより,クライアントとサーバとの間のネゴシエーションにより,デコーダ
を動的にダウンロードすることができる。それゆえ,クライアントは,画像符号化方式に関す
る知識がなくてもコンテンツを復号でき,メディアコンテンツを途切れなしに再生できる。こ
のシステムは,JavaとCORBAにより開発されたので,移植性に優れている。デコーダ
をフレキシブルデコーダとして開発すれば,デコーダ・ダウンロード可能システムにとって有
用であると言える。MSDL-Sを用いてビットストリーム解析を他の処理から分離する方法
も提案した。
(2)前記(1)の記載によれば,引用発明の概要は以下のとおりのものであると認
められる。
引用発明の目的は,デコーダ・ダウンロード可能システムにおいて,コンテンツ
の特徴を用いた画像圧縮に基づくマルチメディアのために統一プラットフォームを
提供するものであり,再生を途切れなく遅延が最小となるように,サーバとクライ
アント間のネゴシエーションにより,デコーダの動的ダウンロードを可能とするこ
とにある。
ところで,デコーダは,ビットストリーム解析,画像圧縮アルゴリズム(DCT,
ウェーブレット,動き推定など)などの複数の機能を有するが,従来のデコーダは
一体のソフトウェアであったため,デコーダのパーツを共有することができなかっ
た。
しかし,引用発明のシステムによれば,モジュールベースのデコーダ(フレキシ
ブルデコーダ)はモジュールにより構成され,複数のデコーダ間でモジュールを共
有することが可能となり,フレキシブルデコーダにより,デコーダの冗長なパーツ
のダウンロードを回避することによって,ダウンロード時間を短くすることができ
る。引用発明のシステムは,クライアントとサーバからなり,システムが様々な環
境で動作するように,クライアントシステムはJavaを用いて実装したため,J
avaにより開発したデコーダは,サーバがクライアントのオペレーティングシス
テムの種類を心配する必要がないというメリットがある。
そして,クライアントは,コンテンツ情報(コンテンツ情報は,最適なデコーダ
情報を含む。)を用いて,これに対応するデコーダがクライアント側にあるかどうか
を確認し,デコーダを有していない場合,コンテンツサーバに対して,デコーダが
どこに記憶されているのかを要求し,情報サーバは,デコーダ情報を用いて,要求
されたデコーダのデコーダURIをクライアントに返し,クライアントは,情報サ
ーバから取得したデコーダURIを用いてデコーダサーバからデコーダをダウンロ
ードする。
また,フレキシブルデコーダは,モノリシックプログラムとして扱われず,複数
の機能を提供する複数のモジュールの集まりとして扱われるアーキテクチャが可能
であるから,クライアントは,新しいタイプのメディアコンテンツが届いたときに,
必要なモジュールのみをダウンロードすることによりデコーダを構成できるため,
デコーダをダウンロードするためのネットワーク帯域幅とクライアント又はサーバ
のリソースを削減できる。
さらに,フレキシブルデコーダは,1)ビットストリーム解析ブロック,2)デ
ータ再生ブロック,及び3)画像再構成ブロックに分かれており,ビットストリー
ム解析をするモジュールは,画像を復号するモジュールから完全に分離されるから,
デコーダは,クライアントのハードウェア仕様(MMX,3DNow!,DSP,
ASICなど)に適したIDCTモジュールを選択して,同じビットストリーム解
析を共有できるなど,同じ画像復号アルゴリズムのための様々なモジュールを用い
ることができ,単に画像復号アルゴリズムのモジュールを他のプロセスのもので置
き換えることにより実現することができる。
3公知文献について
(1)公知文献1(甲2)
ア公知文献1には,おおむね,以下の内容の記載がある。
(ア)要約
本発明は,新しいコンテンツ形式を再生するようにアップグレード可能な拡張可能ディスク
プレイヤを提供する。プレイヤの機能は,インターネットを介してウェブサーバから適切なデ
コーダをダウンロードすることにより,拡張可能である。このように,プレイヤは,もともと
サポートしていないコンテンツを再生することができる。コンテンツ形式が未知である場合,
プレイヤは,ディスクが適切なデコーダを有するウェブサイトにリンクするURLを有するか否
かを検査する。ディスクがURLを有する場合,プレイヤはウェブサイトにアクセスして適切な
デコーダをダウンロードする。同様に,レコーダの機能も適切なエンコーダをダウンロードす
ることにより拡張され得る。
(イ)技術分野
本発明は,概してディスクプレイヤに関するものであり,特に新しいコンテンツ形式を再生
するようにアップグレード可能なディスクプレイヤに関するものである(【0001】)。
(ウ)背景技術
光ディスクは,多様なフォーマットでエンコードされ得るオーディオ,データ,ビデオ,画
像,アニメーション等のような多様な種類のメディアを格納するために広く使用されてきてい
る。例えば,MPEG-2やMPEG-4やDivXやH26.Lはビデオ用に使用されており,MP3やSACDはオ
ーディオ用に使用されており,FlashやSVGはアニメーション用に使用されている。一般的に
従来のプレイヤは,コンテンツ形式のサブセットのみをサポートする固定数のデコーダを有し
ている。新しいコンテンツ形式が市場に導入されると,この新しいフォーマットでディスクを
再生するために,消費者は新しいコンテンツ形式をサポートするデコーダを備えた新しいプレ
イヤを購入する必要がある。これは消費者にとって非常に高コストである。顧客は新しいプレ
イヤを今購入して結果として数年のうちに旧式になることがわかるか,新しいフォーマットを
備えたディスクを購入しないかについて困難な決定を行う必要がある。消費者の多数が新しい
フォーマットを備えたディスクを購入しないことを決定した場合,新しいフォーマットの採用
を著しく妨げ,新しい光ストレージ技術の開発にかなり影響を及ぼす(【0002】)。
(エ)発明が解決しようとする課題
したがって,既存のコンテンツ形式を再生できるだけでなく,新しいコンテンツ形式を再生
するようにアップグレード可能でもよいプレイヤを提供する必要がある(【0003】)。
(オ)課題を解決するための手段
本発明は,新しいコンテンツ形式を再生するようにアップグレード可能な拡張可能ディスク
プレイヤを提供する。プレイヤの機能は,インターネットを介してウェブサーバから適切なデ
コーダをダウンロードすることにより,拡張可能である。このように,プレイヤは,もともと
サポートしていないコンテンツを再生することができる(【0004】)。
本発明の一実施例によると,拡張可能ディスクプレイヤが提供される。プレイヤは,ディス
クのコンテンツオブジェクトのコンテンツ形式を決定する手段と,コンテンツ形式が未知であ
ると決定した場合に,ディスクが適切なデコーダを有するウェブサイトにリンクするURLを有
するか否かを検査する手段と,ディスクがURLを有することを検査した場合に,ウェブサイト
にアクセスして適切なデコーダをダウンロードする手段とを有する(【0005】)。
(カ)発明を実施するための最良の形態
a図1は,本発明の一実施例による拡張可能ディスクプレイヤ10の動作の概要を示してい
る。プレイヤ10はインターネットに接続可能であり,ウェブアクセス用の基本的なプロトコル
スタックのサポート(例えばHTTPプロトコルスタック)を有する。光ディスク20がプレイヤ10
に挿入されると,プレイヤはディスクの内容を認識して再生しようとする。プレイヤがコンテ
ンツのフォーマットを処理できない場合,インターネットを介してウェブサーバ30から適切な
デコーダを見つけてダウンロードすることを試みる。
デコーダがダウンロードされた後に,同じコンテンツ形式が次回認識されたときにプレイヤ
がそれを再びダウンロードする必要がないように,デコーダがプレイヤに格納されることが好
ましい(【0012】)。
【図1】
b図2は,本発明の一実施例に従って適切なデコーダを取得する拡張可能ディスクプレイ
ヤにより実行される処理100を示したフローチャートである。プレイヤへのディスクの挿入時
に,プレイヤはディスクのコンテンツオブジェクトを提示しようとし(ステップ102),プレイ
ヤに既知のコンテンツ形式を有しているか否かを決定する(ステップ106)。
コンテンツ形式がプレイヤに既知である場合,プレイヤはコンテンツオブジェクトをロード
して処理する(ステップ112)。しかし,プレイヤがコンテンツ形式を認識していない場合,適
切なデコーダを有するウェブサイトにリンクするURLがディスクで利用可能であるか否かを決
定しようとする(ステップ116)。
ステップ116でURLがディスクに存在することが決定されると,プレイヤはそのURLを使用
してウェブサイトにアクセスする(ステップ136)。次に,プレイヤはデコーダが見つかったか
否かを決定する(ステップ142)。見つかった場合,プレイヤはデコーダをダウンロードし(ステ
ップ152),コンテンツオブジェクトを処理し始める(ステップ156)。((【0013】,【0014】)。
【図2】
このように,DVDプレイヤのような再生装置の機能は,適切なデコーダモジュールをダウン
ロードすることにより拡張され得る(【0016】)。
イ前記アの記載によれば,公知文献1には,コンテンツとともに,このコンテ
ンツの再生を実行する適切なデコーダを有するウェブサイトにリンクするためのU
RLが記憶されたディスクをプレイヤに挿入することにより,ウェブサイトにアク
セスしてデコーダをダウンロードする技術が記載されていることが認められる。
(2)公知文献2(甲3)
ア公知文献2には,おおむね,以下の内容の記載がある。
(ア)発明の属する技術分野
本発明は,異なる圧縮方式で圧縮されたデータが混在して記録された記録媒体からデータを
読み出してデコードして再生するときに,デコードに必要とするデコードのためのプログラム
を,上記プログラムが記録されている場所に応じて取得するようにした再生装置,再生方法及
び再生システムに関する(【0001】)。
(イ)発明が解決しようとする課題
コンピュータ装置からディジタル音楽コンテンツをディジタルデータのままで記録媒体に記
録する機能を備えた携帯型のオーディオプレーヤは,特定のオーディオ圧縮方式に対応するも
のであって,例えばMP3プレーヤでは,MP3データを専用デコーダによりデコードしてオ
ーディオに戻すので,MP3以外の他のオーディオ圧縮方式のディジタル音楽コンテンツを取
り扱うことはできない(【0007】)。
今日,様々なオーディオ圧縮方式が提案されており,各種オーディオ圧縮方式に個別に対応
するオーディオプレーヤを所有することは,ユーザにとって不便であることから,複数のオー
ディオ圧縮方式に1台で対応できるマルチフォーマット対応の携帯型のオーディオプレーヤの
出現が望まれている(【0008】)。
そこで,本発明の目的は,複数のオーディオコーデックに対応するマルチコーデック対応の
オーディオシステムを安価に実現することにある(【0009】)。
(ウ)発明の実施の形態
aオーディオ再生装置4の電気的な構成を図3に示してある(【0023】)。
【図3】
このオーディオ再生装置4は,USB端子14を介してコンピュータ装置3とUSBケーブ
ル24で接続され,当該コンピュータ装置3から転送されたディジタル音楽コンテンツC1が
USBコントローラ25から内部バス26を介して転送されるCPU27を備える。上記内部
バス26には,フラッシュメモリ30,操作キーコントローラ31,デジタルシグナルプロセ
ッサ(DSP:DigitalSignalProcessor)32,出力増幅器33,EEPROM(Electrically
ErasableProgrammableRead‐OnlyMemory)34,LCD(LiquidCrystalDisplay)コント
ローラ35,RTC(RealTimeClock)回路36等が接続されている(【0024】)。
このオーディオ再生装置4では,大容量のメモリ空間をサポートするCPU27により音楽
データのダウンロードやユーザインターフェース,また,大容量の不揮発性メモリであるフラ
ッシュメモリ30の管理を行う。上記CPU27には,CPUコア27A以外にメモリ27B,
27Cも内蔵したワンチップマイクロコンピュータが採用されている。このCPU27のプロ
グラムメモリには内蔵のマスクROM(Read‐0nlyMemory)27Bが用いられている(【00
25】)。
上記オーディオ再生装置4は,複数のフォーマットのディジタル音楽コンテンツに対応する
ために,音楽コーデックをソフトウエアにて実現しており,所定の圧縮方式でデータ圧縮され
た音楽データD1に対応した伸長方式で再生するための再生用コードであるコーデックプログ
ラムをフラッシュメモリ30に予め格納しておき,このコーデックプログラムをフラッシュメ
モリ30から同じフラッシュメモリ30内にあるインデクスデータに基づいてDSP32内部
のRAM32B(RandomAccessMemory)上にコピーして,上記DSP32内部のメモリ空間
に置いたコーデックプログラムを実行することにより,音楽再生を行う(【0026】)。
すなわち,このオーディオ再生装置4において,CPU27は,音楽データとコーデックプ
ログラムが入った大容量の不揮発性メモリすなわちフラッシュメモリ30を管理する(【002
7】)。
このオーディシステムにおけるオーディオ再生装置4では,ソフトウエアにて音楽コーデッ
クを実現しているので,装置全体を小型かつ安価に作ることができる。なお,ハードウエアに
依存する音楽コーデックで複数フォーマットに対応するには,対応するコーデック毎にハード
ウエアが必要となる(【0028】)。
また,上記オーディオ再生装置4において,ソフトウエアによる音楽コーデックを実行する
DSPコア32Aは,コーデックのようにリアルタイムに信号を加工する処理のために特化さ
れたインストラクションを有するので,少ない消費電力で処理を完了することができる。また,
DSP32内部のメモリ空間は,外部のメモリ空間をアクセスする場合に比べ,結線による容
量性負荷が殆どないため,少ない消費電力で高速にアクセスすることができる(【0029】)。
コーデックプログラムは高速な演算が期待される処理であり,上記DSP32では,この処
理を効率的に実効することができる。なお,DSP32内部のメモリは,高速性を追求した構
造となっているため,一般的な外部メモリと比較してビット単価が高いが,現在使用するコー
デックのみを外部のフラッシュメモリ30から使用前にコピーするので,コーデック1個分の
容量があればよい(【0030】)。
ここで,コーデックプログラムを記憶するフラッシュメモリ30は,書換え可能であるので,
ユーザがコーデックプログラムを追加することができる。なお,フラッシュメモリ30に追加
記憶するコーデックプログラムは,上記EMDサーバ1からインターネット2を介して配信す
るようにしてもよい(【0031】)。
電子音楽配信サービスにより配信された例えば有料の音楽データは,コーデックプログラム
とともに不揮発性メモリに記憶される必要があり,コーデックプログラムとともに物理的に同
一のデバイスであるフラッシュメモリ30に記憶することは,デバイスの実装面積及び価格の
点で有利である(【0032】)。
bオーディオ再生装置4のCPU27は,実際に音楽再生を行う場合に,音楽データの先
頭に予め付加されているヘッダ情報をフラッシュメモリ30から読み込み,現在DSP32内
に設定してあるコーデックで再生可能な圧縮方式をRAM27Cから取得し,取得された情報
のうちの現在DSP32に設定してあるコーデックとヘッダ情報から得られた圧縮形式とが同
一であるか否かを判定する(【0039】)。
そして,上記CPU27は,DSP32に入っているコーデックが異なっている場合には,
フラッシュメモリ30に記憶されているインデクスデータに基づいてフラッシュメモリ30に
書き込まれているコーデックプログラムから,再生する音楽データフォーマットに合致したコ
ーデックプログラムを探し,DSP32にダウンロードするとともにRAM27CへDSP3
2にダウンロードしたコーディックに関する情報を記憶させる。RAM27Cに記憶されたコ
ーディックに関する情報を次の音楽データを再生するときに参照されることになる。上記CP
U27は,その後,フラッシュメモリ30から音楽データをDSP32に送って,音楽再生を
行う(【0040】)。
ここで,上記CPU27は,上記DSP32がデコードする音楽情報を管理し,上記音楽情
報の音楽フォーマットによらず,音楽情報の再生の進捗に同期して,音楽情報を一定量ずつ上
記DSP32に送って,音楽情報を再生する(【0041】)。
cこのオーディオシステムにおけるディジタル音楽コンテンツC1は,図8に示すように
ヘッダH1と音楽データD1とからなり,ヘッダH1にはファイルID,ヘッダサイズ,コン
テンツキー,ファイル,コーデックID,ファイル名及びファイル情報が格納されているとと
もに,再生制限に関する再生制限情報として再生制限データ,再生開始日,再生終了日,再生
可能回数,再生回数及びオーディオファイルが格納されている(【0044】)。
コンテンツキーは,音楽データD1に対する暗号化を解くための暗号データであり,実際上
コンピュータ装置3及びオーディオ再生装置4の間でディジタル音楽コンテンツC1の授受が
行われる際に,共通のセッションキーでさらに暗号化された状態で転送される。コーデックI
Dは,オーディオ再生装置4でディジタル音楽コンテンツC1の音楽データD1を再生する場
合の伸長方式に対応したID番号であり,例えば,1D番号「1」に対してはATRAC
(AdaptlveTransformAcousticCoding)3と呼ばれるデータ圧縮方法に応じた伸長方式が割
り当てられ,ID番号0x0000に対してはMP3(MPEGAudioLayer-3)と呼ばれるデー
タ圧縮方法に応じた伸長方式が割り当てられている。なお,“0x”を数値の前に付けることで
16進数であることを示している(【0045】)。
イ前記アの記載によれば,公知文献2には,音楽データD1(コンテンツ)と,
この音楽データD1を再生するコーデックのIDであるコーデックIDを含むヘッ
ダH1で音楽コンテンツC1が構成される技術が記載されていることが認められる。
4取消事由1(本願補正発明の容易想到性の判断に係る手続違背)について
(1)原告は,本件審決は,本願補正発明と引用発明との相違点4について,引用
発明並びに公知文献1及び2(甲2,3)に記載された公知技術に基づいて,当業
者であれば容易に想到できると判断したが,拒絶理由通知及び拒絶査定において,
公知文献1及び2は何ら引用されておらず,上記各公知文献は審決において初めて
示されたものであり,原告に対して,拒絶査定の理由と異なる新たな拒絶理由の通
知はなく,意見書提出の機会も与えられなかった。したがって,本件審決には,特
許法159条2項により準用される同法50条に違反する違法があり,その違法は
審決の結論に影響を及ぼすことが明らかである旨主張する。
しかし,特許法159条1項後段,同法53条1項,同法17条の2第1項4号,
法17条の2第6項及び法126条5項によれば,拒絶査定不服審判を請求する場
合において,その審判の請求と同時にした補正が,補正後における特許請求の範囲
に記載されている事項により特定される発明が特許出願の際独立して特許を受ける
ことができないものである場合には,審判合議体は,決定をもって当該補正を却下
しなければならず,この却下の決定をする場合には,特許法159条2項後段,同
法50条ただし書及び特許法17条の2第1項4号により,審判合議体は,拒絶査
定不服審判において査定の理由と異なる拒絶の理由を発見したときであっても,特
許出願人に対して,拒絶の理由を通知して意見書提出の機会を与える必要はないと
解される。
これを本件についてみると,本件審決は,拒絶査定不服審判の請求と同時にされ
た本件補正により特定された本願補正発明について,引用発明,公知文献1及び2
に記載の公知技術並びに技術常識に基づいて当業者が容易に発明をすることができ
たものであり,特許法29条2項により,特許出願の際独立して特許を受けること
ができないものであることを理由として,本件補正を却下しており,上記のとおり,
この場合には改めて拒絶の理由を通知して意見書提出の機会を与える必要はないと
解されるから,本件審決の手続に違法はない。
原告の上記主張は理由がない。
(2)原告は,拒絶査定不服審判を請求し,特許請求の範囲について拒絶査定の理
由を解消するような限定を付加して補正をした特許出願人(審判請求人)に対する
補正却下の理由が,特許出願人が想定し得ない新たな引用文献を引用した新たな拒
絶の理由である独立特許要件違反の場合には,特許出願人に何ら責任はなく,かか
る場合にまで意見書提出の機会を与えないことは,特許庁審判官による再度の審査
(審理)を適正に受ける権利を,特許出願人から不当に奪うものであること,そも
そも特許法159条1項及び2項の立法趣旨は,拒絶査定不服審判請求時にした補
正が新規事項を追加するものである場合において優先的に補正却下を適用すること
にあるのであって,拒絶査定不服審判請求時に原査定の拒絶理由を解消すべく請求
項を減縮した補正を,意見書・補正書の提出機会を与えずに,新たな拒絶理由によ
って補正却下するような事態に適用することは想定されていないのであるから,拒
絶査定不服審判請求時にした補正を,補正違反の態様にかかわらず一律に補正却下
の対象とした同法159条1項後段及び2項後段の規定自体が立法の誤りであり,
憲法31条に反し違憲であって,本件審決もまた違憲な規定に則ったものであるか
ら違憲である旨主張する。
特許法159条1項後段及び2項後段は,平成5年法律第26号により規定され
たものであることから,その立法経緯等について検討するに,従前の特許法におい
ては,特許請求の範囲の補正については,出願公告の決定謄本の送達前に出願当初
の明細書に記載された事項の範囲内において特許請求の範囲を増加,減少又は変更
する補正は,明細書の要旨を変更しないものとみなすと規定されているのみであっ
たことから,拒絶理由通知後であっても,特許請求の範囲の拡張,変更等の補正を
行うことが許容されていたのみならず,特許請求の範囲の補正の回数も制限されて
いなかったため,一つの出願において拒絶理由が通知されるたびに特許請求の範囲
の補正を行うことも許容されていた。そして,このような補正がされた場合には,
審査対象が変更されるため,そのたびに新たな先行技術の調査及びその結果に基づ
く対比判断等の新たな審査を行わざるを得なかったが,実際の出願において何回も
特許請求の範囲についての補正が行われた場合は,出願間の取扱いに公平性を欠く
ことになるのみならず,このような出願が存在することにより,他の出願の審査の
遅延をも生じるおそれがあるという弊害が生じていた。さらに,第三者にとっては,
出願公開後に補償金請求権が発生するにもかかわらず,特許請求の範囲の補正が何
回も行われることにより,特許が付与がされる対象が何回も変更されることとなり,
その監視負担が過大となるという弊害も生じていた。そこで,平成4年12月にと
りまとめられた工業所有権審議会の答申(以下「審議会答申」という。)においては,
昭和63年に我が国の特許法に主要国と同様の多項制が既に導入されており,その
利用も拡大しつつあること等も踏まえ,出願公告の決定謄本送達前の特許請求の範
囲の補正について,制度及び審査実務等の運用の国際的調和,出願間の取扱いの公
平性及び迅速な権利付与等の観点から適正化を図るべきであるとされた。
また,従前の特許法においては,出願公告の決定謄本の送達前に拒絶査定不服審
判を請求する際には,特許請求の範囲の拡張,減縮,変更を含めた広範な補正を行
うことが認められているとともに,審判請求時に補正がされた場合には,審査前置
制度により,審査官が再度審査を行い,拒絶査定の対象となった請求項が削除され
る等,拒絶査定をした理由が解消されている場合には,審査官に拒絶査定を取り消
す機会が与えられていた。この審査前置制度の趣旨は,審判請求時に補正がされた
場合は,審判合議体による審理の前に審査官に再度審査をさせることにより,審査
段階において得られた調査結果や出願内容の知識を活用し,出願内容の理解や調査
に要する時間を節約して処理を行うことにあった。しかしながら,審査前置制度は,
我が国の特許法が単項制を採用していた頃に導入されたものであり,拒絶査定不服
審判請求時に特許請求の範囲の拡張,変更を行う補正も許容されていたことから,
そのようは補正がされた場合は,拒絶査定を受けた発明とは別の発明について,審
査官による再度の審査(または審判官による審理)が行われることとなり,その結
果,もとの審査における審理の手続や結果が軽視され,新たに最初から審理がし直
されることともなりかねなかったことから,審理の迅速性及び的確性が十分に確保
され難いという問題を有していた。また,拒絶査定不服審判請求時に,特許請求の
範囲を拡張,変更する補正がされると,多項性の利用が拡大しつつある状況におい
ては,多項制を有意義に活用し,特許請求の範囲の請求項の削除等の補正のみを行
う出願との間において,出願の取扱いの公平性が担保されないこととなっていたの
みならず,前者の出願が存在することにより,後者の出願の審理が遅延するという
弊害をも生じていた。このため,審議会答申においては,拒絶査定不服審判におけ
る補正の範囲に関する主要国の制度及び運用も考慮しつつ,行政処分である拒絶査
定の瑕疵の是正をより迅速,的確かつ公平に行うため,出願公告の決定謄本送達前
の拒絶査定不服審判の請求時における補正の範囲の適正化を行うべきであるとされ
た。
そこで,平成5年法律第26号において,最後の拒絶理由通知に対する補正につ
いて,明細書及び図面に新規事項を追加しないものであるほか,特許請求の範囲の
減縮に当たる補正がされた場合においても,補正後の発明が独立して特許を受ける
ことができるもののみを許容すること(独立特許要件)を含めて補正の範囲の適正
化を図るべく特許法17条の2の規定が整備され,拒絶理由の通知について同法5
0条ただし書の規定が設けられるとともに,不適法な補正は却下することとして同
法53条1項ないし3項の規定が設けられた。このように,最後の拒絶理由通知に
対する補正が独立特許要件を含めて特許法17条の2の規定に違反する不適法なも
のであることが出願公告の決定謄本の送達前に認められた場合に,拒絶理由を通知
することなく当該補正を却下することとした理由は,補正により特許可能となる発
明については補正を認めることによって迅速に権利付与を行うことが出願人の利益
となるのに対し,補正後の発明が特許性を有しない場合に再度拒絶理由を通知する
こととした場合には拒絶理由通知に対して再度の補正が可能であるため,審査官は
当該補正について再度審査する必要があり,審査の迅速性が十分に確保され難く,
出願間の取扱いの公平性を欠くことになるためである。
そして,出願公告の決定謄本送達前に拒絶査定不服審判を請求する際の補正がで
きる範囲についても,審判制度の改善の一環として,制度の国際的調和を図るとと
もに,拒絶査定不服審判の審理の迅速化を図る観点から,最後の拒絶理由通知に対
する補正と同じ範囲とするとともに,特許法159条1項後段及び2項後段を規定
し,同法53条及び50条ただし書を準用することにより,独立特許要件を含めて
その補正が不適法な場合には,新たにその旨の拒絶理由を通知することなく,その
補正を却下することとした(以上について,乙1~9)。
上記でみたところによれば,特許法159条1項後段及び2項後段は,独立特許
要件違反を含め拒絶査定不服審判請求時にされた不適法な補正に対し,拒絶理由を
通知することなくこれを却下することにより,審理の迅速化,出願間の公平性の確
保及び第三者の監視負担の軽減等を図った合理的な規定であるというべきであるか
ら,これらの規定が憲法31条に違反する旨の原告の前記主張は採用することがで
きない。
(3)原告は,本件のように拒絶査定不服審判請求時に原査定の拒絶理由を解消す
るために特許請求の範囲を減縮した補正を,新たな引用文献に基づく新たな拒絶理
由で却下する場合には,審判合議体は,いきなり補正却下・拒絶審決をするのでは
なく,まず拒絶理由を通知するとの運用をすることが,特許制度の趣旨及び憲法3
1条に沿うものであるから,本件審決は,特許法159条1項後段及び2項後段の
規定を適切に運用することを怠った違法性,違憲性がある旨主張するが,かかる運
用を特許庁に義務づけることは,前記(2)で検討した平成5年法律第26号による改
正の趣旨を没却する結果となるものであることは明らかであるから,原告の上記主
張を採用することはできない。
(4)以上によれば,原告主張の取消事由1は理由がない。
5取消事由2(本願補正発明と引用発明との一致点の認定の誤り,相違点の看
過)について
(1)原告は,本願補正発明の「装置」は,引用発明の情報サーバに対応するもので
はなく,クライアントに対応するものであるところ,引用発明において,「前記マル
チメディアコンテンツに関する前記コーデックサーバの位置情報と前記コーデック
のバイナリデータの識別情報とを用い」る主体は,情報サーバであって,クライア
ントではないから,本件審決が一致点として認定した「前記マルチメディアコンテ
ンツに関する前記コーデックサーバの位置情報と前記コーデックのバイナリデータ
の識別情報とが用いられ」は,引用発明の「クライアント」と本願補正発明の「装
置」との一致点とはなり得ず,本件審決は一致点の認定を誤り相違点を看過してい
る旨主張する。
しかし,本件審決が一致点として認定した「コーデックサーバの位置情報」及び
「コーデックのバイナリデータの識別情報」は,それぞれ引用発明における「デコ
ーダURI」及び「対応する最適なデコーダ情報」に相当するものであるところ,
前記2(1)ウ(イ)bのとおり,引用発明においては,クライアントは,コンテンツ情
報(コンテンツ情報は,最適なデコーダ情報を含む。)を用いて,これに対応するデ
コーダがクライアント側にあるかどうかを確認し,デコーダを有していない場合,
コンテンツサーバに対して,デコーダがどこに記憶されているのかを要求し,情報
サーバは,デコーダ情報を用いて,要求されたデコーダのデコーダURIをクライ
アントに返し,クライアントは,情報サーバから取得したデコーダURIを用いて
デコーダサーバからデコーダをダウンロードする。
そうすると,引用発明において,クライアントが,情報サーバからデコーダUR
I(コーデックサーバの位置情報)を取得するにしても,デコーダのダウンロード
を行う際に,「マルチメディアコンテンツに関するコーデックサーバの位置情報」及
び「コーデックのバイナリデータの識別情報」を用いる主体はクライアントである
から,本件審決が,「前記マルチメディアコンテンツに関する前記コーデックサーバ
の位置情報と前記コーデックのバイナリデータの識別情報とが用いられ」ることを,
引用発明の「クライアント」と本願補正発明の「装置」との一致点と認定したこと
に誤りはない。
原告の上記主張は理由がない。
(2)原告は,引用発明において,「前記コーデックサーバの位置情報と前記コー
デックのバイナリデータの識別情報」を知っているのは,情報サーバであって,ク
ライアントではなく,一方,本願補正発明の「装置」においては,「前記マルチメデ
ィアコンテンツ」に含まれた「前記コーデックサーバの位置情報と前記第1のソフ
トウェアモジュールの識別情報とに基づき」,第1のソフトウェアモジュールのダウ
ンロードを要求するのは,「装置」内部の制御部であって,サーバ側ではないから,
本件審決が一致点として認定した「前記コーデックサーバの位置情報と前記コーデ
ックのバイナリデータの識別情報とに基づき」は,引用発明の「クライアント」と
本願補正発明の「装置」との一致点とはなり得ず,本件審決は一致点の認定を誤り
相違点を看過している旨主張する。
しかしながら,前記(1)のとおり,クライアントは,最適なデコーダ情報(コーデ
ックのバイナリデータの識別情報)及び情報サーバから取得したデコーダURI(コ
ーデックサーバの位置情報)を用いて,デコーダをダウンロードしているから,本
件審決が,「前記コーデックサーバの位置情報と前記コーデックのバイナリデータの
識別情報とに基づき,」外部ネットワークに位置した前記コーデックサーバに前記コ
ーデックのバイナリデータのダウンロードを要求するメッセージを生成及び伝送す
ることを,引用発明の「クライアント」と本願補正発明の「装置」との一致点と認
定したことに誤りはない。
原告の上記主張は理由がない。
(3)以上によれば,原告主張の取消事由2は理由がない。
6取消事由3(本願補正発明と引用発明との相違点4に係る判断の誤り)につ
いて
(1)原告は,本願補正発明の「ソフトウェアモジュール」は,OS,コーデック
ライブラリ,メディアフレームワーク及びハードウェアライブラリを含むところ,
本願補正発明は,「第1と第2のソフトウェアモジュールを組み合わせてDSPコー
ドを生成」することを要件としているから,「第1のソフトウェアモジュール」がメ
ディアフレームワークであり,「第2のソフトウェアモジュール」がハードウェアラ
イブラリである場合も包含するものであるが,引用発明においてダウンロードされ
る「デコーダモジュール」は,本願明細書の「コーデック」(コーデックライブラリ
の一要素)に相当するものであるから,本件審決が相違点2として判断した「モジ
ュールのみをダウンロードする点」及び「得ようとする各情報が「モジュール」を
対象としたものとすること」とは,引用発明における「デコーダモジュール」,すな
わちコーデックライブラリについて判断したものにすぎず,コーデックライブラリ
以外の本願補正発明の「ソフトウェアモジュール」であるOS,メディアフレーム
ワーク及びハードウェアライブラリについては,何も判断していない旨主張する。
そこで検討するに,本願補正発明の「DSPコード」は,「第1のソフトウェアモ
ジュール」と,「第2のソフトウェアモジュール」を組み合わせて生成されるもので
あり,マルチメディアコンテンツに対応する「第1のソフトウェアモジュール」が
記憶部に記憶されていない場合,「第1のソフトウェアモジュール」のダウンロード
を要求するものである。しかるに,前記1(1)ウ,エ,オ(ア),(イ),(エ)のとおり,
本願明細書(甲7)の発明の詳細な説明(段落【0018】,【0022】,【002
3】,【0030】,【0035】,【0042】,【0043】,【図5】,【0047】,【0
051】~【0053】)には,ダウンロードされる「第1のソフトウェアモジュー
ル」の例示として,コーデックライブラリが記載され,「第2のソフトウェアモジュ
ール」の例示として,コーデックライブラリ以外のOS,メディアフレームワーク
及びハードウェアライブラリが記載されているから,本願補正発明において,ダウ
ンロードされる「第1のソフトウェアモジュール」は,コーデックライブラリを含
むものであって,これを除外するものでないことは明らかである。
そうすると,前記2(2)のとおり,引用発明は,コンテンツ(マルチメディアコン
テンツ)に対応する「デコーダ」を有していない場合,コンテンツサーバに対して
デコーダがどこに記憶されているのかを要求し,情報サーバから取得したデコーダ
URIを用いて,デコーダサーバから「デコーダ」をダウンロードするものである
から,この点において,コーデックライブラリを含む「第1のソフトウェアモジュ
ール」のダウンロードを行う本願補正発明と相違するものではない。
そして,本件審決が,本願優先権主張日当時の公知文献として挙げた,公知文献
1(甲2)には,前記3(1)ア(ア),(カ)のとおり,コンテンツとともに,このコン
テンツの再生を実行する適切なデコーダを有するウェブサイトにリンクするための
URLが記憶されたディスクをプレイヤに挿入することにより,ウェブサイトにア
クセスしてデコーダをダウンロードする技術が,公知文献2(甲3)には,前記3
(2)ア(ウ)cのとおり,音楽データD1(コンテンツ)と,この音楽データD1を再
生するコーデックのIDであるコーデックIDを含むヘッダH1で音楽コンテンツ
C1が構成される技術がそれぞれ記載されている。したがって,コンテンツに,デ
コーダを有するウェブサイトにリンクするためのURL(コーデックサーバの位置
情報)やコーデックID(第1のソフトウェアモジュールの識別情報)を含むよう
に構成することは,本願優先権主張日当時の公知技術であると認められるから,引
用発明に当該公知技術を適用して,相違点4に係る本願補正発明の構成に至ること
は,当業者であれば,容易に想到し得るものである。
原告の上記主張は理由がない。
(2)原告は,公知文献1及び2には,デコーダ全体ではなく,そのうちの一部に
相当する第1のソフトウェアモジュールのみをダウンロードするためのコーデック
サーバの位置情報や,第1のソフトウェアモジュールのみの識別情報がディスクに
含まれているという記載はなく,公知文献1及び2記載の技術を引用発明に組み合
わせて本願補正発明の進歩性を否定するためには,公知文献1及び2において,単
にデコーダが存在するウェブサイトのURL及びデコーダの識別情報では足りず,
デコーダ全体のうちの一部に相当する第1のソフトウェアモジュールのみをダウン
ロードするためのコーデックサーバの位置情報及び第1のソフトウェアモジュール
の識別情報がディスクに含まれている必要があるから,仮に公知文献1及び2記載
の技術を引用発明に適用できたとしても,本願補正発明には至らない旨主張する。
しかし,前記2(1)エのとおり,引用発明は,モジュールベースのデコーダ(フレ
キシブルデコーダ)をモノリシックプログラムではなく複数の機能を提供する複数
のモジュールの集まりとし,クライアントは,新しいタイプのメディアコンテンツ
が届いたときに,必要なモジュールのみをダウンロードすることによりデコーダを
構成できるものである。本件審決は,本願補正発明と引用発明との相違点2につい
ては,引用発明から本願補正発明の構成に想到することは当業者であれば容易であ
る旨判断しているのであって,この点の判断には,後記7の「取消事由4(本願補
正発明と引用発明との相違点1及び2に係る判断の誤り)について」において説示
するとおり誤りはない。
そうすると,かかるフレキシブルデコーダの構成を採用する引用発明に,公知文
献1及び2の公知技術を適用して,ダウンロードされる「第1のソフトウェアモジ
ュール」であるコーデックライブラリに対するコーデックサーバの位置情報やデコ
ーダの識別情報をコンテンツの中に含ませることは,当業者であれば容易に想到し
得るものである。
原告の上記主張は理由がない。
(3)原告は,本願補正発明では,「前記マルチメディアコンテンツは前記コーデ
ックサーバの位置情報と前記第1のソフトウェアモジュールの識別情報を含み」及
び「前記コーデックサーバの位置情報と前記第1のソフトウェアモジュールの識別
情報とに基づき」の要件を満たしているから,装置側からサーバ側に対して「コー
デックサーバの位置情報と第1のソフトウェアモジュールの識別情報」を要求する
ことなく,マルチメディアコンテンツ自体に内在する「コーデックサーバの位置情
報と第1のソフトウェアモジュールの識別情報」をそのまま利用すれば足りるのに
対して,引用発明においては,「クライアントが対応するデコーダを有していない場
合には,スケジューラー管理エンジンは,デコーダURIを得ることをデコーダ・
コンポーネント管理エンジンに指示する。デコーダ・コンポーネント管理エンジン
は,どこにデコーダが格納されているかをコンテンツサーバに要求する」のであっ
て,本願補正発明には,このような要求を必要としないという効果がある旨主張す
る。
しかし,前記のとおり,「マルチメディアコンテンツ」に,「コーデックサーバの
位置情報」と「コーデックの識別情報」を含むように構成することは,当業者であ
れば容易に想到し得るものであるから,本願補正発明において,どこにデコーダが
格納されているかをコンテンツサーバに要求する必要がないとの効果は,当該構成
に付随する当然の効果であって,格別顕著な効果であると認めることはできない。
原告の上記主張は理由がない。
(4)以上によれば,原告主張の取消事由3は理由がない。
7取消事由4(本願補正発明と引用発明との相違点1及び2に係る判断の誤り)
について
(1)原告は,引用発明では“coreengine”にデコーダを設置しており,“core
engine”はCPUに該当するから,引用発明のデコーダダウンロード及び設置に関
するソフトウェアはCPU上で動作するソフトウェアであって本願補正発明のDS
Pコードとは異なるものであること,引用例には,OSなどの実行環境が劣悪であ
るというDSPの特性上コンポーネント化されていないソフトウェアを備えるしか
ないDSPに対し,新規コーデックが要求される際にコーデックを変更するために
最小限の資源を用いてDSP規格に合うDSPコードを容易に提供することについ
ては,いかなる開示も示唆もないこと,これに対し,本願補正発明は,コンポーネ
ント化されたソフトウェアの使用が容易ではないDSPによりコーデックを支援す
る回路環境で新規コーデックが要求されるたびに大容量のDSPコードを適用及び
交替することにより発生する相当量のオーバーヘッドを最小化するため,コンテン
ツを再生するたびにリアルタイムでCPU(DSPコード生成部)で適切なコーデッ
クライブラリを選択するようにした後,選択されたコーデックライブラリとOS及
びメディアフレームワークを組み合わせてDSPコードを生成し,生成されたDS
PコードをDSP処理部に提供し,DSP処理部では提供されたDSPコードに基
づいてコンテンツを再生するためのデコーディングを行うこととし,DSPはコン
テンツを再生するたびにCPUからDSPコードを提供される構成としたものであ
り,かかる構成,効果を検討せずに相違点1及び2について容易想到であると判断
した本件審決は誤りである旨主張する。
しかし,前記2(1)ア(イ)記載のとおり,引用発明は,従来のデコーダは一体のソ
フトウェアであったため,複数のデコーダ間において,デコーダを構成する画像圧
縮アルゴリズム(DCT,ウェーブレット,動き推定など)等が同じであったとし
ても,デコーダのパーツを共有することができなかったという課題を解決するため,
デコーダをモジュールベースとすることにより,同じ画像圧縮アルゴリズム等を複
数のデコーダ間で共有するように構成したものであると認められる。また,前記2
エウのとおり,引用例には,DSPなどのハードウェアに適したIDCTモジ
ュールを選択してデコーダを構成することが記載されているから,引用発明におい
て,DSPによってもデコーダを動作させ得ることが理解される。
そうすると,引用発明のコアエンジンについて,DSPによるハードウェアを採
用し,DSPでデコーダを動作させるように構成することは,当業者であれば容易
に想到し得るものである。また,DSPによってデコーダを動作させる場合,DS
Pに適したOS等のソフトウェアが必要であることは,本願優先権主張日当時の技
術常識であるというべきであるから,デコーダとOS等のソフトウェアを組み合わ
せてDSPで動作させること,すなわち,DSPコードを生成し,DSPでマルチ
メディアコンテンツの処理を行うことは,当業者であれば容易に想到し得るもので
ある。そして,原告が上記において主張する本願補正発明の効果も,引用発明から
容易に想到し得る本願補正発明の構成から予測し得る効果にすぎず,格別顕著な効
果であると認めることはできない。
原告の上記主張は理由がない。
なお,原告は,本願補正発明では,コーデックライブラリだけでなく,OS,メ
ディアフレームワーク及びハードウェアライブラリのソフトウェアを組み合わせて
新たな「DSPコード」を生成しているのに対し,引用発明の「デコーダ・コンポ
ーネント管理エンジン」は「コアエンジン」に対して「デコーダモジュール」のみ
を供給しているところ,この「デコーダモジュール」は,本願明細書の「コーデッ
ク」に相当するものであり,新たなDSPコードを生成する機能は有していない旨
主張するが,同主張に理由がないことは,上記において説示したとおりである。
(2)原告は,引用例には,いくつかのIDCTモジュールの中でDSPという「ハ
ードウェア仕様…に適したIDCTモジュールを選択」することができると記載さ
れているのであって,DSPで複数のIDCTモジュールを用いることができ,I
DCTの変更を実施できる旨の記載はない旨主張する。
しかし,DCT(DiscreteCosineTransform;離散コサイン変換)は,画像や動
画の圧縮を行う際に用いられる変換方法(アルゴリズム)であり,IDCT(Inverse
DiscreteCosineTransform;逆離散コサイン変換)は,DCTで変換した信号を復
号するために逆変換を行う変換方法であるところ,DSPが様々な画像アルゴリズ
ムに対応できるハードウェアであることは本願優先権主張日当時の技術常識である
というべきであるから,引用例に,DSPが複数のIDCTモジュールを使用し,
IDCTの変更を実施できる旨の記載がないからといって,DSPが単一のIDC
Tモジュールにしか対応し得ないものではないことは自明である。また,引用例に
は,前記2イアのとおり,画像圧縮アルゴリズムとしてDCTが広く使われて
いるが,DCTが全種類の画像に適しているわけではないことが記載され,また,
前記2(1)ア(イ)のとおり,デコーダを構成する画像圧縮アルゴリズムとして,DC
Tのほかにウェーブレット等が例示されていることからすれば,当業者であれば,
引用発明におけるDSPは,複数のIDCTモジュールに対応できるだけでなく,
DCT以外の他の画像圧縮アルゴリズムにも対応可能なものであることが,容易に
理解できるところである。
原告の上記主張は理由がない。
なお,原告は,引用例には,ハードウェア仕様に適したデコーダを選択すること
は記載されていても,同一のハードウェア仕様について複数のデコーダを選択的に
ダウンロードして用いることは記載されていない旨主張するが,同主張に理由がな
いことは,上記において説示したところから明らかである。
原告は,引用例に,一体化したソフトウェアの課題認識があったとしても,
それはシステム全体としての課題認識であり,DSPにおける課題認識が示唆され
ているものではない旨主張するが,前記2(2)のとおり,引用発明は,モジュールベ
ースのデコーダ(フレキシブルデコーダ)をモノリシックプログラムではなく複数
の機能を提供する複数のモジュールの集まりとして認識し,クライアントは,必要
なモジュールのみをダウンロードすることによりデコーダを構成するものであって,
ソフトウェアを一体化したものとしてのみ認識するものではなく,また,前記(1)
のとおり,DSPではデコーダとOS等のソフトウェアを組み合わせて動作させる
ものであるから,原告の上記主張は理由がない。
(4)原告は,本願補正発明は,DSPに最適のDSPコードを提供するため,C
PU及びDSP間の連動構造を備えているのに対し,引用発明は,コアエンジンと
してDSPを採用する構成上の違いがある旨主張する。
しかし,前記3(2)ア(ウ)aのとおり公知文献2(甲3)において,CPUで音楽
データのダウンロードを行い,DSPでコーデックプログラムを実行することによ
り音楽再生を行うことが記載されていること(段落【0023】,【図3】,【002
5】,【0026】,【0029】,【0030】)及び弁論の全趣旨によれば,CPUと
DSPが連動して処理を行うことは,本願優先権主張日当時の周知技術であること
が認められるから,引用発明において,CPUとDSPが連動して処理を行うよう
に構成することは,当業者であれば容易に想到し得るものである。
原告の上記主張は理由がない。
以上によれば,原告主張の取消事由4は理由がない。
8結論
以上の次第であるから,原告主張の取消事由はいずれも理由がなく,本件審決の
判断に誤りはないから,本件審決にこれを取り消すべき違法は認められない。
よって,原告の本訴請求は理由がないから,棄却されるべきである。
知的財産高等裁判所第4部
裁判長裁判官富田善範
裁判官大鷹一郎
裁判官田中芳樹

戻る



採用情報


弁護士 求人 採用
弁護士募集(経験者 司法修習生)
激動の時代に
今後の弁護士業界はどうなっていくのでしょうか。 もはや、東京では弁護士が過剰であり、すでに仕事がない弁護士が多数います。
ベテランで優秀な弁護士も、営業が苦手な先生は食べていけない、そういう時代が既に到来しています。
「コツコツ真面目に仕事をすれば、お客が来る。」といった考え方は残念ながら通用しません。
仕事がない弁護士は無力です。
弁護士は仕事がなければ経験もできず、能力も発揮できないからです。
ではどうしたらよいのでしょうか。
答えは、弁護士業もサービス業であるという原点に立ち返ることです。
我々は、クライアントの信頼に応えることが最重要と考え、そのために努力していきたいと思います。 弁護士数の増加、市民のニーズの多様化に応えるべく、従来の法律事務所と違ったアプローチを模索しております。
今まで培ったノウハウを共有し、さらなる発展をともに目指したいと思います。
興味がおありの弁護士の方、司法修習生の方、お気軽にご連絡下さい。 事務所を見学頂き、ゆっくりお話ししましょう。

応募資格
司法修習生
すでに経験を有する弁護士
なお、地方での勤務を希望する先生も歓迎します。
また、勤務弁護士ではなく、経費共同も可能です。

学歴、年齢、性別、成績等で評価はしません。
従いまして、司法試験での成績、司法研修所での成績等の書類は不要です。

詳細は、面談の上、決定させてください。

独立支援
独立を考えている弁護士を支援します。
条件は以下のとおりです。
お気軽にお問い合わせ下さい。
◎1年目の経費無料(場所代、コピー代、ファックス代等)
◎秘書等の支援可能
◎事務所の名称は自由に選択可能
◎業務に関する質問等可能
◎事務所事件の共同受任可

応募方法
メールまたはお電話でご連絡ください。
残り応募人数(2019年5月1日現在)
採用は2名
独立支援は3名

連絡先
〒108-0023 東京都港区芝浦4-16-23アクアシティ芝浦9階
ITJ法律事務所 採用担当宛
email:[email protected]

71期修習生 72期修習生 求人
修習生の事務所訪問歓迎しております。

ITJではアルバイトを募集しております。
職種 事務職
時給 当社規定による
勤務地 〒108-0023 東京都港区芝浦4-16-23アクアシティ芝浦9階
その他 明るく楽しい職場です。
シフトは週40時間以上
ロースクール生歓迎
経験不問です。

応募方法
写真付きの履歴書を以下の住所までお送り下さい。
履歴書の返送はいたしませんのであしからずご了承下さい。
〒108-0023 東京都港区芝浦4-16-23アクアシティ芝浦9階
ITJ法律事務所
[email protected]
採用担当宛