拒絶査定不服の審決｜不服2012-3322 - 特許審決データベース

会員機能

ランキング

請求人別審判件数

判例データベース

審決データベース

ポートフォリオ機能

ポートフォリオを新規に作成して保存		追加
既存のポートフォリオに追加保存		追加

この審決の個人情報、企業機密に関する修正依頼をする

PDF	PDFをダウンロード

審決分類	審判査定不服 2項進歩性特許、登録しない(前置又は当審拒絶理由) G11B
管理番号	1276090
審判番号	不服2012-3322
総通号数	164
発行国	日本国特許庁(JP)
公報種別	特許審決公報
発行日	2013-08-30
種別	拒絶査定不服の審決
審判請求日	2012-02-21
確定日	2013-06-26
事件の表示	特願2005-164547「マルチメディアコンテンツ再生装置、再生方法、生成装置、生成方法、及びそのマルチメディアコンテンツを記録した記録媒体」拒絶査定不服審判事件〔平成18年 2月 9日出願公開、特開2006- 40511〕について、次のとおり審決する。
結論	本件審判の請求は、成り立たない。
理由	1.手続の経緯・本願発明本願は、平成17年6月3日(パリ条約による優先権主張 2004年6月5日韓国(KR))に出願したものであって、手続の概要は以下のとおりである。拒絶理由通知 :平成22年 7月26日(起案日) 意見書 :平成22年11月 2日手続補正 :平成22年11月 2日拒絶理由通知 :平成22年11月30日(起案日) 意見書 :平成23年 3月 7日拒絶査定 :平成23年10月28日(起案日) 拒絶査定不服審判請求 :平成24年 2月21日手続補正 :平成24年 2月21日審尋 :平成24年 5月10日(起案日) 回答書 :平成24年 8月15日拒絶理由通知(当審) :平成24年 9月 6日(起案日) 意見書 :平成24年12月11日本願の請求項1ないし16に係る発明は、平成24年2月21日付け手続補正により補正された特許請求の範囲の請求項1ないし16に記載された事項により特定されるとおりのものと認められるところ、請求項1に係る発明(以下「本願発明」という。)は、次のとおりのものである。「【請求項1】マルチメディア再生装置において、マルチメディアコンテンツと前記マルチメディアコンテンツをデコーディングするコーデックとが結合されたマルチメディアデータを記録媒体から読み出す読出部と、前記読み出されたマルチメディアデータから抽出された前記コーデックを利用して、前記マルチメディアコンテンツを再生する再生部とを含み、前記マルチメディアデータは、前記コーデックの特性に関する情報が記録されたヘッダと、前記マルチメディアコンテンツをデコーディングするコーデックの実行コードが記録されたコーデックトラックとをさらに含み、前記再生部は、前記ヘッダを参照して、前記コーデックトラックにあるコーデックをメモリにロードして実行させることによって、前記マルチメディアコンテンツをデコーディングする汎用エンジンを含むことを特徴とするマルチメディア再生装置。」 2.引用例当審の平成24年9月6日付け拒絶理由通知に引用した、本願の優先権主張の日前に頒布された刊行物である特開2001-67807号公報(平成13年3月16日公開、以下「引用例1」という。)には、図面と共に、以下の記載がある。(なお、下線は当審で付与した。) (1)「【0001】【産業上の利用分野】この発明は、音声再生装置に関し、特にたとえば、着脱可能な記録媒体に符号化された状態で記録された音声信号を再生する、音声再生装置に関する。【0002】【従来の技術】音声信号を符号化/復号化するフォーマットには、MP3(MPEG-1 AUDIO Layer 3),TｗinVQなどがある。従来の音声再生装置では、このような複数のフォーマットのいずれか1つに対応する復号プログラムをメモリに格納し、同じフォーマットで符号化された音声信号をこの復号プログラムによって復号していた。【0003】【発明が解決しようとする課題】しかし、上述のように音声信号の符号化/復号化フォーマットは複数存在するため、自分が持っている音声再生装置が対応していないフォーマットの音声信号は、聴取することができなっかった。【0004】それゆえに、この発明の主たる目的は、どのようなフォーマットで符号化された音声信号も再生できる、音声再生装置を提供することである。」 (2)「【0016】【実施例】図1を参照してこの実施例の携帯型音声記録再生装置10は、パーソナルコンピュータのような通信端末400と接続される。通信端末400は、電話回線を通じてインターネット100と接続され、オペレータは、インターネット100を介して複数のWEBサイト300a,300b…,300nにアクセスできる。」 (3)「【0019】メモリカード18に記録されるオーディオファイルのデータ構造を図4に示す。オーディオファイルのヘッダ以降には、セキュリティ情報,コンテンツ情報,付加情報がこの順で収納され、所定フォーマットで圧縮処理および暗号化処理を施された1曲分の音楽データ(音声データ)が、付加情報に続いて収納されている。ここで、セキュリティ情報は、オーディオファイルが不正にコピーされないようにするための暗号化キー情報であり、この暗号化キー情報を用いることで暗号が解読される。【0020】コンテンツ情報には、音楽データがどのようなフォーマットで圧縮されているかを示す圧縮フォーマット情報、音楽データがどのようなフォーマットで暗号化されているかを示す暗号化フォーマット情報、付加情報としてどのようなデータが含まれているかを示す付加情報管理テーブル、アーティスト名,曲名,アルバム名,作曲家名,プロデューサ名のようなこのオーディオファイルに関連する情報などが含まれる。【0021】付加情報には、音楽データを伸長するためのデコードソフト(復号プログラム)、音楽の曲調を調整するためのイコライザソフト、アーティストの画像データ、アーティストのメッセージ,アルバム作成時のエピソードなどのテキストデータが含まれる。【0022】圧縮フォーマットとしては、MP3,TｗinVQ,AAC,AC-3(Dolby Digital),ePACなどの複数のフォーマットがある。このため、オーディオファイルに含まれる音楽データがePACフォーマットで圧縮されている場合、圧縮フォーマット情報は“ePAC”を示し、音楽データがMP3フォーマットで圧縮されている場合、圧縮フォーマット情報は“MP3”を示す。【0023】また、再生装置に設けられたDSP(Digital Signal Processor)のタイプ(たとえば16ビット演算であるか24ビット演算であるか)によって、対応できるデコードソフトが異なる。つまり、DSPが16ビット演算のプロセサであれば、タイプAのデコードソフトしか起動せず、DSPが24ビット演算のプロセサであれば、タイプBのデコードソフトしか起動しない。このため、付加情報に含まれるデコードソフトがePACフォーマットに従いかつ16ビット演算のDSPに対応している場合、付加情報管理テーブルには“ePACデコードソフト-タイプA”のデコードソフト情報が含まれる。また、16ビット演算および24ビット演算のいずれのDSPにも対応できるように、ePACフォーマットに従う2つのデコードソフトが付加情報に含まれている場合、付加情報管理テーブルには“ePACデコードソフト-タイプA”および“ePACデコードソフト-タイプB”というデコードソフト情報が含まれる。なお、デコードソフト情報は、圧縮フォーマット情報およびタイプ情報を含む概念である。」 (4)「【0029】このようにしてメモリカード18に記録されたオーディオファイルを再生するとき、携帯型音声記録再生装置10に含まれるCPU20は、図9?図12に示すフロー図を処理する。なお、このフロー図の処理は、電源の投入に応答して開始される。」 (5)「【0031】CPU20は続いて、ステップS9でメモリカード18にオーディオファイルが存在するかどうかを判別する。このとき、上述のファイル管理情報が用いられる。ここでオーディオファイルが1つもなければ、CPU20は、ステップS11でその旨のメッセージをLCD36に表示し、所定時間経過したときに、ステップS83の終了処理を経てステップS85で電源をオフする。これに対して、メモリカード18にオーディオファイルが1つでも存在すれば、CPU20はステップS13に進み、メモリカード18内のオーディオファイルNからヘッダ,セキュリティ情報およびコンテンツ情報を読み出す。そして、オーディオファイルNが不正にコピーされたファイルであるかどうかを、ステップS15でセキュリティ情報に基づいて判別する。」 (6)「【0033】オーディオファイルNが適法に入手されたファイルである場合、CPU20はステップS15でNOと判断し、ステップS23に進む。このステップでは、オーディオファイルNの圧縮フォーマットとDSP22のROM22aに予め準備されたデコードソフトのフォーマットが一致するかどうか判断する。」 (7)「【0036】一方、ステップS23での判定結果が不一致を示す場合、CPU23はステップS24に進み、DSP22に適したデコードソフトがオーディオファイルNに収納されているかどうか判断する。上述のように、デコードソフトとDSP22との間でタイプが相違すれば、そのデコードソフトはDSP22によって起動できない。このため、ステップS24では、付加情報管理テーブルを参照して、オーディオファイルNに収納されたデコードソフトのタイプが、DSP22のタイプと一致するかどうか判定するようにしている。いずれのデコードソフトもDSP22のタイプと一致しなければ、CPU20はステップS25でその旨のメッセージをLCD36に所定時間表示し、ステップS79に進む。これに対して、少なくとも1つのデコードソフトのタイプがDSP22と一致していれば、CPU20は、ステップS26でDSWFフラグをセットし、ステップS29に進む。」 (8)「【0039】オペレータがボタン操作により再生を指示すると、CPU20はステップS35でYESと判断し、ステップS63でDSWFフラグの状態を判別する。ここでDSWFフラグがセット状態であれば、CPU20はステップS65に進む。ステップS65では、付加情報管理テーブルを参照して、オーディオファイルNに収納されたデコードソフトのうち、DSP22に対応するデコードソフトをメモリカードから読み出し、DSP22に設けられたRAM22bにロードする。DSP22が16ビット演算のプロセサである場合、オーディオファイルNが図5および図6のいずれの付加情報管理テーブルを持つときでも、“ePAC-タイプA”のデコードソフトがRAM22bにロードされる。」 (9)「【0043】CPU20は続いて、ステップS73でDSP22を起動し、ステップS75でDSP22からCPU20に与えられる要求を有効化する。この要求に基づいて、メモリカード18に記録されたオーディオファイルNから音楽データが読み出される。読み出された音楽データは、上述のように暗号化処理および圧縮処理を施されており、このような音楽データが、インタフェース14を介してDSP22に与えられる。DSP22は、まず音楽データの暗号を解読し、次にRAM22bに格納されたデコードソフトに従ってデコードする。さらに、特殊効果を発揮するような処理が、必要に応じて音楽データに施される。このような処理を施された音楽データは、D/A変換器24によって音声信号(アナログ信号)に変換され、変換された音声信号は、アンプ26および出力端子28を介してヘッドフォン30に出力される。この結果、オペレータはヘッドフォン30を通して音楽を聴取できる。」 (10)「【0054】なお、上述の実施例では、DSPに設けられたROMに少なくとも1つのデコードソフトを格納するようにしたが、DSPには、ボリュームコントロールなどの最低限のソフトを除いていかなるデコードソフトも格納せず、常にオーディオファイルに含まれるデコードソフトによって音楽データをデコードするようにしてもよい。また、この発明は、本の朗読,英会話などの音楽以外のコンテンツにも適用できる。圧縮フォーマットには、音楽ならびに人の話し声のような音声のそれぞれに適した複数のフォーマットがある。このため、この発明は、1つの装置によって音楽ならびに音楽以外の音声を再生する場合に、特に効果がある。」上記摘示事項及び図面の記載から以下のことがいえる。 (a)実施例は、「携帯型音声記録再生装置」である(【0016】)。 (b)「メモリカード」に記録される「オーディオファイル」には、「付加情報」と「音楽データ」とが収納され(【0019】)、「付加情報」には、「音楽データを伸長するためのデコードソフト(復号プログラム)」が含まれる(【0021】)。「CPU」は、「オーディオファイル」に収納された「デコードソフト」を「メモリカード」から読み出し(【0039】)、「メモリカード」に記録された「オーディオファイル」から「音楽データ」を読み出す(【0043】)。したがって、「CPU」は、「音楽データ」と「音楽データを伸長するためのデコードソフト(復号プログラム)」とが収納されている「オーディオファイル」を「メモリカード」から読み出すといえる。 (c)「CPU」は、「オーディオファイル」に収納された「デコードソフト」を「メモリカード」から読み出し、「DSP」に設けられた「RAM」にロードする(【0039】)。「DSP」は、「RAM」に格納された「デコードソフト」に従って「音楽データ」をデコードする(【0043】)。したがって、「DSP」は、「メモリカード」から読み出された「オーディオファイル」に収納された「デコードソフト」に従って、「音楽データ」をデコードするといえる。 (d)「オーディオファイル」のヘッダ以降には、セキュリティ情報,コンテンツ情報,「付加情報」がこの順で収納され、所定フォーマットで圧縮処理を施された1曲分の「音楽データ(音声データ)」が、「付加情報」に続いて収納されている(【0019】)。 (e)コンテンツ情報には、「音楽データ」がどのようなフォーマットで圧縮されているかを示す圧縮フォーマット情報、「付加情報」としてどのようなデータが含まれているかを示す付加情報管理テーブルが含まれる(【0020】)。 (f)「付加情報」には、「音楽データを伸長するためのデコードソフト(復号プログラム)」が含まれる(【0021】)。 (g)「DSP」のタイプ(16ビット演算であるか24ビット演算であるか)によって、対応できる「デコードソフト」が異なる(【0023】)。 (h)付加情報管理テーブルには「デコードソフト情報」が含まれ、「デコードソフト情報」は、圧縮フォーマット情報およびタイプ情報を含む概念である(【0023】)。 (i)「CPU」は、付加情報管理テーブルを参照して、「オーディオファイル」に収納された「デコードソフト」のうち、「DSP」に対応する「デコードソフト」を「メモリカード」から読み出し、「DSP」に設けられた「RAM」にロードし(【0039】)、「メモリカード」に記録された「オーディオファイル」から「音楽データ」を読み出す(【0043】)。 (j)「DSP」は、「音楽データ」を「RAM」に格納された「デコードソフト」に従ってデコードする(【0043】)。以上を総合勘案すると、引用例1には、次の発明(以下「引用発明」という。)が記載されているものと認める。「携帯型音声記録再生装置において、音楽データと音楽データを伸長するためのデコードソフト(復号プログラム)とが収納されているオーディオファイルをメモリカードから読み出すCPUと、メモリカードから読み出されたオーディオファイルに収納されたデコードソフトに従って、音楽データをデコードするDSPとを含み、オーディオファイルのヘッダ以降には、セキュリティ情報,コンテンツ情報,付加情報がこの順で収納され、所定フォーマットで圧縮処理を施された1曲分の音楽データ(音声データ)が、付加情報に続いて収納されており、コンテンツ情報には、音楽データがどのようなフォーマットで圧縮されているかを示す圧縮フォーマット情報、付加情報としてどのようなデータが含まれているかを示す付加情報管理テーブルが含まれ、付加情報には、音楽データを伸長するためのデコードソフト(復号プログラム)が含まれ、 DSPのタイプ(16ビット演算であるか24ビット演算であるか)によって、対応できるデコードソフトが異なり、付加情報管理テーブルに含まれるデコードソフト情報は、圧縮フォーマット情報およびタイプ情報を含む概念であり、 CPUは、付加情報管理テーブルを参照して、オーディオファイルに収納されたデコードソフトのうち、DSPに対応するデコードソフトをメモリカードから読み出し、DSPに設けられたRAMにロードし、メモリカードに記録されたオーディオファイルから音楽データを読み出し、 DSPは、音楽データをRAMに格納されたデコードソフトに従ってデコードする携帯型音声記録再生装置。」なお、引用例1には、DSPには、いかなるデコードソフトも格納せず、常にオーディオファイルに含まれるデコードソフトによって音楽データをデコードするようにしてもよい(【0054】)ことが記載されており、この記載からも、引用発明を上記のように認定し得る。同じく、当審の平成24年9月6日付け拒絶理由通知に引用した、本願の優先権主張の日前に頒布された刊行物である特開2002-318598号公報(平成14年10月31日公開、以下「引用例2」という。)には、図面と共に、以下の記載がある。(なお、下線は当審で付与した。) (11)「【0002】【従来の技術】音声や映像等のデータサイズを高能率に圧縮するために、様々な方式の符号化(データ圧縮)技術が提案されている。例えば、携帯型音楽再生装置の分野では、限られた容量の半導体メモリの中に、より高音質で、より大量の音楽信号を記録するための符号化方式であるMP3(MPEG Audio Layer 3)方式に対応した音楽再生装置が普及しつつあり、また、MP3方式以外にも、AAC(Advanced Audio Coding)方式やWMA(Windｏｗｓ(登録商標) Media Aｕdiｏ)方式など、新しい符号化方式が次々に登場している。【0003】一般に、新製品開発が激しい分野では、その製品のライフサイクルは非常に短いものになってしまう。例えば、新しい符号化方式が普及してしまうと、古い符号化方式にのみ対応している再生装置では新方式に対応できず、そのためユーザは新方式に対応した製品を新たに購入しなければならない。【0004】ところが、このような再生装置のハードウェア構成は、符号化方式が変わっても大きな差はなく、情報の復号化を行う部分のアルゴリズムが若干異なるのみである。【0005】そこで、復号化の処理部分をソフトウェアによる処理で実現し、再生装置内部の半導体メモリに複数種類の復号化ソフトウェアを搭載することで、異なる符号化方式に対応可能な再生装置や、再生装置内部の半導体メモリに搭載されている符号化プログラムを書き換え可能にすることで、新方式の復号化技術に対応可能な再生装置なども登場している。」 (12)「【0041】第1の半導体メモリ13には、例えば、図2に示すようなファイル構造で、符号化された音楽データと復号化処理プログラムを記録しておく。図2に示した例では、フォルダを符号化方式の種類別に分け、MP3方式の「フォルダMP3」、AAC方式の「フォルダAAC」、WMA方式の「フォルダWMA」の3つのフォルダが作成されており、各フォルダには、その符号化方式に対応した符号化プログラムと、その符号化方式で符号化された音楽データとが格納されている。例えば、「フォルダMP3」には、「mp3decode.prg」というMP3方式に対応した復号化プログラムと、「01title.mp3」「02title.mp3」「03title.mp3」、等々、MP3方式にて符号化された音楽データである、音声デジタルデータのファイル群とが格納されている。また、各音声デジタルデータのヘッダ情報等には、どのような符号化方式にて符号化されたかを示す情報が格納されている。」 (13)「【0067】一般に、光学的記録媒体は、半導体メモリカードなどに比べると記録容量が非常に豊富であるため、以上説明したような音楽情報の再生だけでなく、画像情報、あるいは音声情報と画像情報との組み合わせなどの再生装置としても利用することができる。動画像の符号化方式も様々な方式が開発されており、例えば、MPEG1(Moving Picture Experts Group phase 1)、MPEG2(Moving Picture Experts Group phase 2)、MPEG4(Moving Picture Experts Group phase 4)、WMV(Windows Media Video)などの符号化方式が普及している。【0068】従来、ある特定の符号化方式に専用に対応した再生装置(例えば、MPEG1方式の動画像デジタルデータをCD-ROMに記録したVideｏ-CDフォーマット専用の再生装置)では、異なる符号化方式(例えば、MPEG4方式やWMV方式)で符号化された動画像デジタルデータを再生することができなかった。【0069】これに対して、本発明の情報再生装置30によれば、デジタル情報を記録するCD-ROMディスク33に、MPEG1、MPEG2、MPEG3、WMV等の各種符号化方式に対応した復号化プログラムをそれぞれ記録させておくだけで、複数種類の符号化方式に、あるいは新しい種類の符号化方式に、容易に且つ柔軟に対応することができる。」 3.対比そこで、本願発明と引用発明とを対比する。 (1)マルチメディア再生装置引用発明は「音声記録再生装置」であるところ、「音声記録再生装置」は、「音声を再生する装置」を含んでおり、音声は1つのメディアであるから、引用発明の「音声記録再生装置」は、「メデイアを再生する装置」、すなわち、「メディア再生装置」といい得るものである。もっとも、再生するメディアがマルチメディアとはしていないから、「マルチメディア再生装置」とはいえず、この点、「マルチメディア再生装置」とする本願発明とは相違する。 (2)読出部本願発明の「マルチメディアコンテンツと前記マルチメディアコンテンツをデコーディングするコーデックとが結合されたマルチメディアデータ」に対応するものとして、引用発明でも「オーディオファイル」が認められ、当該「オーディオファイル」には、「所定フォーマットで圧縮処理を施された1曲分の音楽データ(音声データ)」が「音楽データを伸長するためのデコードソフト(復号プログラム)が含まれ」る「付加情報に続いて収納されて」いるところ、引用発明の、上記「音楽データ」は、「メディアコンテンツ」といえ、「デコードソフト(復号プログラム)」は、「音楽データ」を復号するためのものであるから、「デコーディングするコーデック」といえ、これらが、同じ「オーディオファイル」に収納されているのであるから、これらが「結合」されているといえ、また、「オーディオファイル」は「メディアデータ」ともいい得るものである。そうすると、引用発明の「オーディオファイル」も、「メディアコンテンツと前記メディアコンテンツをデコーディングするコーデックとが結合されたメディアデータ」といい得、そのようにいい得る点においては、本願発明の「マルチメディアコンテンツと前記マルチメディアコンテンツをデコーディングするコーデックとが結合されたマルチメディアデータ」と相違しない。もっとも、「メディアコンテンツ」「前記メディアコンテンツをデコーディングするコーデック」「メディアデータ」を「マルチメディアコンテンツ」「前記マルチメディアコンテンツをデコーディングするコーデック」「マルチメディアデータ」とはしていない点で本願発明とは相違する。引用発明の「メモリカード」は「記録媒体」といい得、引用発明の「CPU」は、「オーディオファイル」をメモリカードから読み出すから、引用発明も「メディアデータ」を「記録媒体」から読み出す「読出部」を備えている。したがって、本願発明と引用発明は、「メディアコンテンツと前記メディアコンテンツをデコーディングするコーデックとが結合されたメディアデータを記録媒体から読み出す読出部」を含んでいる点で一致し、上記「メディアコンテンツ」「前記メディアコンテンツをデコーディングするコーデック」「メディアデータ」が、本願発明では「マルチメディアコンテンツ」「前記マルチメディアコンテンツをデコーディングするコーデック」「マルチメディアデータ」としている点で引用発明と相違する。 (3)再生部引用発明の「CPU」は、オーディオファイルに収納されたデコードソフトのうち、DSPに対応するデコードソフトを読み出し、DSPに設けられたRAMにロードするから、「前記読み出されたメディアデータから」「前記コーデック」を「抽出」するといえる。引用発明の「DSP」は、音楽データをRAMに格納されたデコードソフトに従ってデコードするから、「抽出された前記コーデックを利用して、前記メディアコンテンツを再生する」といえる。したがって、引用発明も「前記読み出されたメディアデータから抽出された前記コーデックを利用して、前記メディアコンテンツを再生する再生部」を備えている。もっとも、「メディアデータ」「メディアコンテンツ」を「マルチメディアデータ」「マルチメディアコンテンツ」とはしていない点で本願発明とは相違する。 (4)マルチメディアデータの構造〈マルチメディアデータ〉本願発明の「マルチメディアデータ」は、「前記コーデックの特性に関する情報が記録されたヘッダと、前記マルチメディアコンテンツをデコーディングするコーデックの実行コードが記録されたコーデックトラックとをさらに含み」としていて、その「ヘッダ」、「コーデックトラック」は、「メディアデータ」の『区分けされた部分領域』といえるところ、本願発明の「マルチメディアデータ」に対応し「メディアデータ」といい得る点で一致する引用発明の「オーディオファイル」も、「ヘッダ以降には、セキュリティ情報,コンテンツ情報,付加情報がこの順で収納され、所定フォーマットで圧縮処理を施された1曲分の音楽データ(音声データ)が、付加情報に続いて収納されており」としていて、その「ヘッダ」、「セキュリティ情報」、「コンテンツ情報」、「付加情報」、「音楽データ」も、「メディアデータ」の『区分けされた部分領域』といい得るものである。〈ヘッダ(前記コーデックの特性に関する情報が記録されたヘッダ)〉そして、引用発明の「コンテンツ情報」には、「音楽データがどのようなフォーマットで圧縮されているかを示す圧縮フォーマット情報、付加情報としてどのようなデータが含まれているかを示す付加情報管理テーブルが含まれ」、その「コンテンツ情報」の「付加情報管理テーブル」に含まれる「デコードソフト情報」は、デコードソフトが従う圧縮フォーマットと対応するDSPのタイプを示す情報であるから、「コーデックの特性に関する情報」ということができる。すなわち、引用発明では「メディアデータ」(オーディオファイル)の『区分けされた部分領域』である「コンテンツ情報」に「コーデックの特性に関する情報が記録され」ている。そうすると、引用発明も「メディアデータは、前記コーデックの特性に関する情報が記録された『区分けされた部分領域』」を含むといえ、この点では本願発明と一致する。もっとも、(先頭の『区分けされた部分領域』と解される)「ヘッダ」とする本願発明とは相違する。〈コーデックトラック(マルチメディアコンテンツをデコーディングするコーデックの実行コードが記録されたコーデックトラック)〉また、引用発明の『区分けされた部分領域』である「付加情報」には、「音楽データを伸長するためのデコードソフト(復号プログラム)」が含まれるから、その『区分けされた部分領域』である「付加情報」は、本願発明でいう「コーデックトラック」ということができる。《実行コード》本願発明でいう「実行コード」についてみるに、該「実行コード」とは、明細書の記載(段落【0032】「コーデックの実行コードは、実行可能なバイナリコードの形式または解釈可能なスクリプト形式で具現できる。例えば、特定のプラットホームに最適化されたバイナリコードの形式には、ｗin32 eｘecｕｔable形式の実行コードが含まれることができる。また、コーデックの動作を記述したスクリプト言語形式の実行コードが含まれることもある。」)、および、請求項1の「前記コーデックトラックにあるコーデックをメモリにロードして実行させることによって、前記マルチメディアコンテンツをデコーディングする」に照らせば、プログラムの特定の形式(実行可能なバイナリコードの形式とか記述言語(スクリプト言語)形式とか)に限定するものではなく、結果的に「メモリにロードして実行させること」ができるコードであれば足りると解されるところ、引用発明は、「デコードソフト(復号プログラム)」の形式について特定していないが、「CPUは、付加情報管理テーブルを参照して、オーディオファイルに収納されたデコードソフトのうち、DSPに対応するデコードソフトをメモリカードから読み出し、DSPに設けられたRAMにロードし、メモリカードに記録されたオーディオファイルから音楽データを読み出し、 DSPは、音楽データをRAMに格納されたデコードソフトに従ってデコードする」ものであって、結果的に「メモリにロードして実行させること」ができるプログラムであることは明らかであり、また、プログラムである以上、実行可能なバイナリコードの形式や記述言語(スクリプト言語)形式など、何らかの具体形式で記録された「コード」であると普通に想定されるものである。したがって、引用発明の、本願発明でいう「コーデックトラック」といい得る(『区分けされた部分領域』である)「付加情報」、に含まれる「デコードソフト(復号プログラム)」も、本願発明でいう「実行コード」が記録されたもの、といえ、この点において相違するものとはいえない。〈まとめ〉以上によれば、本願発明と引用発明は、「前記メディアデータは、前記コーデックの特性に関する情報が記録された『区分けされた部分領域』と、前記メディアコンテンツをデコーディングするコーデックの実行コードが記録されたコーデックトラックとをさらに含み、」といい得る点においては、相違しない。もっとも、「メディアデータ」「前記メディアコンテンツをデコーディングするコーデック」を「マルチメディアデータ」「前記マルチメディアコンテンツをデコーディングするコーデック」とはしていない点で本願発明とは相違する。 (5)再生部の構造引用発明において、CPUは、付加情報管理テーブルを参照して、オーディオファイルに収納されたデコードソフトのうち、DSPに対応するデコードソフトをメモリカードから読み出し、DSPに設けられたRAMにロードし、DSPは、音楽データをRAMに格納されたデコードソフトに従ってデコードするから、引用発明の「RAM」は、「コーデック」が「ロード」される「メモリ」といえる。引用発明の「DSP」は、音楽データをデコードするから、音楽データをデコードする「エンジン」といえ、さらに、RAMにロードされるデコードソフトを変えれば処理内容を変えることができ、「どのようなフォーマットで符号化された音声信号も再生できる」(【0004】)ようにするものといえ、「汎用」の「エンジン」、すなわち、「汎用エンジン」といえる。したがって、引用発明においても、「前記再生部は、前記『区分けされた部分領域』を参照して、前記コーデックトラックにあるコーデックをメモリにロードして実行させることによって、前記メディアコンテンツをデコーディングする汎用エンジンを含む」。もっとも、「メディアコンテンツ」を「マルチメディアコンテンツ」とはしていない点で本願発明とは相違する。そうすると、本願発明と引用発明とは、次の点で一致する。＜一致点＞「メディア再生装置において、メディアコンテンツと前記メディアコンテンツをデコーディングするコーデックとが結合されたメディアデータを記録媒体から読み出す読出部と、前記読み出されたメディアデータから抽出された前記コーデックを利用して、前記メディアコンテンツを再生する再生部とを含み、前記メディアデータは、前記コーデックの特性に関する情報が記録された『区分けされた部分領域』と、前記メディアコンテンツをデコーディングするコーデックの実行コードが記録されたコーデックトラックとをさらに含み、前記再生部は、前記『区分けされた部分領域』を参照して、前記コーデックトラックにあるコーデックをメモリにロードして実行させることによって、前記メディアコンテンツをデコーディングする汎用エンジンを含むメディア再生装置。」の点。そして、次の点で相違する。＜相違点＞ (1)「メディア再生装置」「メディアコンテンツ」「メディアコンテンツをデコーディングするコーデック」「メディアデータ」が、本願発明では、「マルチメディア再生装置」「マルチメディアコンテンツ」「マルチメディアコンテンツをデコーディングするコーデック」「マルチメディアデータ」であるのに対して、引用発明では、「音楽記録再生装置」「音楽データ」「音楽データを伸長するためのデコードソフト(復号プログラム)」「オーディオファイル」であって、「マルチメディア再生装置」「マルチメディアコンテンツ」「マルチメディアコンテンツをデコーディングするコーデック」「マルチメディアデータ」とはしていない点。 (2)「コーデックの特性に関する情報が記録された『区分けされた部分領域』」が、本願発明では、「ヘッダ」であるのに対して、引用発明では、ヘッダ以降の「コンテンツ情報」であって、「ヘッダ」とはしていない点。なお、請求人は、平成24年12月11日付け意見書において、本願発明の「汎用エンジン」を含む装置では、プラットフォームまたはOSに制限されずに、コーデックトラックに含まれたコーデックをロードしてコンテンツを再生できる旨主張している。しかしながら、明細書には、汎用エンジンとしてJAVA仮想マシンを採用することにより、プラットホームやOSの種類に関係なく、JAVAで具現されたコーデックを実行させることができることは記載されているものの、「汎用エンジン」自体が、プラットフォームまたはOSに制限されずに、コーデックトラックに含まれたコーデックをロードしてコンテンツを再生できるものに限られるとの記載はなく、本願発明の「汎用エンジン」をそのようなものに限定して解することはできない。また、請求人は、同意見書において、引用例1では、DSPのROMに既に保有しているデコードソフトを先に検討してから、ようやくオーディオファイルに含まれたデコードソフトを使用することができるという点で本願発明と相違する旨主張している。しかしながら、前述したように、引用発明は、DSPには、いかなるデコードソフトも格納せず、常にオーディオファイルに含まれるデコードソフトによって音楽データをデコードするものも含む。また、請求項1に記載された本願発明は、「前記コーデックトラックにあるコーデックをメモリにロードして実行させることによって、前記マルチメディアコンテンツをデコーディングする」ことができれば足り、請求項1の記載からは、既にメモリにロードされているコーデックを使用することができる場合でもなお、改めてコーデックトラックにあるコーデックをメモリにロードするものに限られるとは解し得ない。したがって、一致点・相違点を上記のように認定し得る。 4.判断そこで、上記相違点について検討する。相違点(1)について引用例1に接した当業者が、引用発明におけるメディアである音声を、映像と音声のマルチメディアに変更することは、容易に想起するというべきである。なぜなら、音声に多くの符号化方式があるのと同様に、例えば、マルチメディアとして典型的な、映像と音声のマルチメディアにおいても、多くの符号化方式があることは、技術常識かつ周知であり、また、音声においてもマルチメディアにおいても、符号化されたものを再生するには、それぞれ対応するコーデックを使用しなければならないことに変わりはないこともまた、技術常識かつ周知であるからであり(例えば、引用例2【0002】?【0005】【0067】?【0069】等参照)、映像と音声のマルチメディアにおいても、引用発明の構成を適用すれば、引用発明と同様の課題解決ができることは、当業者に自明であるからである。そして、そのように変更すれば、引用発明における「音楽記録再生装置」(メディア再生装置)「音楽データ」(メディアコンテンツ)「オーディオファイル」(メディアデータ)は、「マルチメディア再生装置」「マルチメディアコンテンツ」「マルチメディアデータ」となり、結果、「音楽データを伸長するためのデコードソフト(復号プログラム)」(メディアコンテンツをデコーディングするコーデック)は、「マルチメディアコンテンツをデコーディングするコーデック」となり、そして相違点1は克服される。したがって、上記相違点1を克服して、「音楽記録再生装置」「音楽データ」「音楽データを伸長するためのデコードソフト(復号プログラム)」「オーディオファイル」を「マルチメディア再生装置」「マルチメディアコンテンツ」「マルチメディアコンテンツをデコーディングするコーデック」「マルチメディアデータ」とすることは、当業者が容易に想到し得る。相違点(2)についてファイルの属性に関する情報を、ファイルの実質的な内容に先行する、ファイルの先頭部分に格納することはごく普通に行われている。そして、引用例2には、どのような符号化方式にて符号化されたかを示す情報を各音声デジタルデータのヘッダ情報に格納する構成が記載されている(【0041】)。当業者は係る知見を有しており、当業者であれば、引用発明における、圧縮フォーマット情報およびタイプ情報を含む概念であるデコードソフト情報が収納される位置をオーディオファイルのコンテンツ情報の位置に代えて、ヘッダの位置とすることは、容易に想到し得る。あるいは、引用発明における、「ヘッダ」、「セキュリティ情報」、「コンテンツ情報」、「付加情報」および「音楽データ」がこの順で収納されるオーディオファイルの、「付加情報」および「音楽データ」をファイルの実質的な内容と捉え、これに先行するファイルの先頭から「音楽データがどのようなフォーマットで圧縮されているかを示す圧縮フォーマット情報、付加情報としてどのようなデータが含まれているかを示す付加情報管理テーブルが含まれ」る「コンテンツ情報」までをヘッダと称することは、当業者が容易に想到し得る。効果についてみても、上記構成の変更に伴って当然に予測される程度のことに過ぎず、格別顕著なものがあるとは認められない。 5.むすび以上のとおり、本願の請求項1に係る発明は、引用例1、2に記載された発明に基づいて当業者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。したがって、本願は、その余の請求項について論及するまでもなく拒絶すべきものである。よって、結論のとおり審決する。
審理終結日	2013-01-25
結審通知日	2013-01-29
審決日	2013-02-12
出願番号	特願2005-164547(P2005-164547)
審決分類	P 1 8・ 121- WZ (G11B)
最終処分	不成立
前審関与審査官	堀洋介、下林義明
特許庁審判長	乾雅浩
特許庁審判官	馬場慎関谷隆一
発明の名称	マルチメディアコンテンツ再生装置、再生方法、生成装置、生成方法、及びそのマルチメディアコンテンツを記録した記録媒体
代理人	渡邊隆
代理人	実広信哉

プライバシーポリシーセキュリティーポリシー運営会社概要サービスに関しての問い合わせ