【事件の表示】
　特願２００５−１６４５４７「マルチメディアコンテンツ再生装置、再生方法、生成装置、生成方法、及びそのマルチメディアコンテンツを記録した記録媒体」拒絶査定不服審判事件〔平成１８年　２月　９日出願公開、特開２００６−　４０５１１〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯・本願発明
　
　本願は、平成１７年６月３日（パリ条約による優先権主張　２００４年６月５日　韓国（ＫＲ））に出願したものであって、手続の概要は以下のとおりである。
　
　拒絶理由通知　　　　　　　：平成２２年　７月２６日（起案日）
　意見書　　　　　　　　　　：平成２２年１１月　２日
　手続補正　　　　　　　　　：平成２２年１１月　２日
　拒絶理由通知　　　　　　　：平成２２年１１月３０日（起案日）
　意見書　　　　　　　　　　：平成２３年　３月　７日
　拒絶査定　　　　　　　　　：平成２３年１０月２８日（起案日）
　拒絶査定不服審判請求　　　：平成２４年　２月２１日
　手続補正　　　　　　　　　：平成２４年　２月２１日
　審尋　　　　　　　　　　　：平成２４年　５月１０日（起案日）
　回答書　　　　　　　　　　：平成２４年　８月１５日
　拒絶理由通知（当審）　　　：平成２４年　９月　６日（起案日）
　意見書　　　　　　　　　　：平成２４年１２月１１日
　
　本願の請求項１ないし１６に係る発明は、平成２４年２月２１日付け手続補正により補正された特許請求の範囲の請求項１ないし１６に記載された事項により特定されるとおりのものと認められるところ、請求項１に係る発明（以下「本願発明」という。）は、次のとおりのものである。
　
「　【請求項１】
　マルチメディア再生装置において、
　マルチメディアコンテンツと前記マルチメディアコンテンツをデコーディングするコーデックとが結合されたマルチメディアデータを記録媒体から読み出す読出部と、
　前記読み出されたマルチメディアデータから抽出された前記コーデックを利用して、前記マルチメディアコンテンツを再生する再生部と
　を含み、
　前記マルチメディアデータは、前記コーデックの特性に関する情報が記録されたヘッダと、前記マルチメディアコンテンツをデコーディングするコーデックの実行コードが記録されたコーデックトラックとをさらに含み、
　前記再生部は、前記ヘッダを参照して、前記コーデックトラックにあるコーデックをメモリにロードして実行させることによって、前記マルチメディアコンテンツをデコーディングする汎用エンジンを含むことを特徴とするマルチメディア再生装置。」
　
２．引用例
　
　当審の平成２４年９月６日付け拒絶理由通知に引用した、本願の優先権主張の日前に頒布された刊行物である特開２００１−６７８０７号公報（平成１３年３月１６日公開、以下「引用例１」という。）には、図面と共に、以下の記載がある。（なお、下線は当審で付与した。）
　
（１）「【０００１】
【産業上の利用分野】この発明は、音声再生装置に関し、特にたとえば、着脱可能な記録媒体に符号化された状態で記録された音声信号を再生する、音声再生装置に関する。
【０００２】
【従来の技術】音声信号を符号化／復号化するフォーマットには、ＭＰ３(MPEG-1 AUDIO Layer 3），ＴｗｉｎＶＱなどがある。従来の音声再生装置では、このような複数のフォーマットのいずれか１つに対応する復号プログラムをメモリに格納し、同じフォーマットで符号化された音声信号をこの復号プログラムによって復号していた。
【０００３】
【発明が解決しようとする課題】しかし、上述のように音声信号の符号化／復号化フォーマットは複数存在するため、自分が持っている音声再生装置が対応していないフォーマットの音声信号は、聴取することができなっかった。
【０００４】それゆえに、この発明の主たる目的は、どのようなフォーマットで符号化された音声信号も再生できる、音声再生装置を提供することである。」
　
（２）「【００１６】
【実施例】図１を参照してこの実施例の
携帯型音声記録再生装置
　
（３）「【００１９】
メモリカード１８に記録されるオーディオファイルのデータ構造を図４に示す。オーディオファイルのヘッダ以降には、セキュリティ情報，コンテンツ情報，付加情報がこの順で収納され、所定フォーマットで圧縮処理および暗号化処理を施された１曲分の音楽データ（音声データ）が、付加情報に続いて収納されている。
【００２０】
コンテンツ情報には、音楽データがどのようなフォーマットで圧縮されているかを示す圧縮フォーマット情報、
付加情報としてどのようなデータが含まれているかを示す付加情報管理テーブル
などが含まれる。
【００２１】
付加情報には、音楽データを伸長するためのデコードソフト（復号プログラム）
が含まれる。
【００２２】圧縮フォーマットとしては、ＭＰ３，ＴｗｉｎＶＱ，ＡＡＣ，ＡＣ−３（Dolby Digital），ｅＰＡＣなどの複数のフォーマットがある。このため、オーディオファイルに含まれる音楽データがｅＰＡＣフォーマットで圧縮されている場合、圧縮フォーマット情報は“ｅＰＡＣ”を示し、音楽データがＭＰ３フォーマットで圧縮されている場合、圧縮フォーマット情報は“ＭＰ３”を示す。
【００２３】また、
再生装置に設けられたＤＳＰ（Digital Signal Processor）のタイプ（たとえば１６ビット演算であるか２４ビット演算であるか）によって、対応できるデコードソフトが異なる。
付加情報管理テーブルには
デコードソフト情報が含まれる。
デコードソフト情報は、圧縮フォーマット情報およびタイプ情報を含む概念である。
　
（４）「【００２９】
このようにしてメモリカード１８に記録されたオーディオファイルを再生するとき、携帯型音声記録再生装置１０に含まれるＣＰＵ２０は、図９〜図１２に示すフロー図を処理する。
　
（５）「【００３１】ＣＰＵ２０は続いて、ステップＳ９でメモリカード１８にオーディオファイルが存在するかどうかを判別する。このとき、上述のファイル管理情報が用いられる。ここでオーディオファイルが１つもなければ、ＣＰＵ２０は、ステップＳ１１でその旨のメッセージをＬＣＤ３６に表示し、所定時間経過したときに、ステップＳ８３の終了処理を経てステップＳ８５で電源をオフする。これに対して、メモリカード１８にオーディオファイルが１つでも存在すれば、ＣＰＵ２０はステップＳ１３に進み、
メモリカード１８内のオーディオファイルＮからヘッダ，セキュリティ情報およびコンテンツ情報を読み出す。
　
（６）「【００３３】オーディオファイルＮが適法に入手されたファイルである場合、ＣＰＵ２０はステップＳ１５でＮＯと判断し、ステップＳ２３に進む。このステップでは、
オーディオファイルＮの圧縮フォーマットとＤＳＰ２２のＲＯＭ２２ａに予め準備されたデコードソフトのフォーマットが一致するかどうか判断する。
　
（７）「【００３６】一方、ステップＳ２３での判定結果が不一致を示す場合、ＣＰＵ２３はステップＳ２４に進み、ＤＳＰ２２に適したデコードソフトがオーディオファイルＮに収納されているかどうか判断する。上述のように、デコードソフトとＤＳＰ２２との間でタイプが相違すれば、そのデコードソフトはＤＳＰ２２によって起動できない。このため、ステップＳ２４では、
付加情報管理テーブルを参照して、オーディオファイルＮに収納されたデコードソフトのタイプが、ＤＳＰ２２のタイプと一致するかどうか判定するようにしている。
　
（８）「【００３９】オペレータがボタン操作により再生を指示すると、ＣＰＵ２０はステップＳ３５でＹＥＳと判断し、ステップＳ６３でＤＳＷＦフラグの状態を判別する。ここでＤＳＷＦフラグがセット状態であれば、ＣＰＵ２０はステップＳ６５に進む。ステップＳ６５では、
付加情報管理テーブルを参照して、オーディオファイルＮに収納されたデコードソフトのうち、ＤＳＰ２２に対応するデコードソフトをメモリカードから読み出し、ＤＳＰ２２に設けられたＲＡＭ２２ｂにロードする。
　
（９）「【００４３】ＣＰＵ２０は続いて、ステップＳ７３でＤＳＰ２２を起動し、ステップＳ７５でＤＳＰ２２からＣＰＵ２０に与えられる要求を有効化する。この要求に基づいて、
メモリカード１８に記録されたオーディオファイルＮから音楽データが読み出される。
ＤＳＰ２２は、まず音楽データの暗号を解読し、次にＲＡＭ２２ｂに格納されたデコードソフトに従ってデコードする。
　
（１０）「【００５４】なお、
上述の実施例では、ＤＳＰに設けられたＲＯＭに少なくとも１つのデコードソフトを格納するようにしたが、ＤＳＰには、ボリュームコントロールなどの最低限のソフトを除いていかなるデコードソフトも格納せず、常にオーディオファイルに含まれるデコードソフトによって音楽データをデコードするようにしてもよい。
　
　上記摘示事項及び図面の記載から以下のことがいえる。
　
（ａ）実施例は、「携帯型音声記録再生装置」である（【００１６】）。
　
（ｂ）「メモリカード」に記録される「オーディオファイル」には、「付加情報」と「音楽データ」とが収納され（【００１９】）、「付加情報」には、「音楽データを伸長するためのデコードソフト（復号プログラム）」が含まれる（【００２１】）。「ＣＰＵ」は、「オーディオファイル」に収納された「デコードソフト」を「メモリカード」から読み出し（【００３９】）、「メモリカード」に記録された「オーディオファイル」から「音楽データ」を読み出す（【００４３】）。
　したがって、「ＣＰＵ」は、「音楽データ」と「音楽データを伸長するためのデコードソフト（復号プログラム）」とが収納されている「オーディオファイル」を「メモリカード」から読み出すといえる。
　
（ｃ）「ＣＰＵ」は、「オーディオファイル」に収納された「デコードソフト」を「メモリカード」から読み出し、「ＤＳＰ」に設けられた「ＲＡＭ」にロードする（【００３９】）。「ＤＳＰ」は、「ＲＡＭ」に格納された「デコードソフト」に従って「音楽データ」をデコードする（【００４３】）。
　したがって、「ＤＳＰ」は、「メモリカード」から読み出された「オーディオファイル」に収納された「デコードソフト」に従って、「音楽データ」をデコードするといえる。
　
（ｄ）「オーディオファイル」のヘッダ以降には、セキュリティ情報，コンテンツ情報，「付加情報」がこの順で収納され、所定フォーマットで圧縮処理を施された１曲分の「音楽データ（音声データ）」が、「付加情報」に続いて収納されている（【００１９】）。
　
（ｅ）コンテンツ情報には、「音楽データ」がどのようなフォーマットで圧縮されているかを示す圧縮フォーマット情報、「付加情報」としてどのようなデータが含まれているかを示す付加情報管理テーブルが含まれる（【００２０】）。
　
（ｆ）「付加情報」には、「音楽データを伸長するためのデコードソフト（復号プログラム）」が含まれる（【００２１】）。
　
（ｇ）「ＤＳＰ」のタイプ（１６ビット演算であるか２４ビット演算であるか）によって、対応できる「デコードソフト」が異なる（【００２３】）。
　
（ｈ）付加情報管理テーブルには「デコードソフト情報」が含まれ、「デコードソフト情報」は、圧縮フォーマット情報およびタイプ情報を含む概念である（【００２３】）。
　
（ｉ）「ＣＰＵ」は、付加情報管理テーブルを参照して、「オーディオファイル」に収納された「デコードソフト」のうち、「ＤＳＰ」に対応する「デコードソフト」を「メモリカード」から読み出し、「ＤＳＰ」に設けられた「ＲＡＭ」にロードし（【００３９】）、「メモリカード」に記録された「オーディオファイル」から「音楽データ」を読み出す（【００４３】）。
　
（ｊ）「ＤＳＰ」は、「音楽データ」を「ＲＡＭ」に格納された「デコードソフト」に従ってデコードする（【００４３】）。
　
　以上を総合勘案すると、引用例１には、次の発明（以下「引用発明」という。）が記載されているものと認める。
　
「携帯型音声記録再生装置において、
　音楽データと音楽データを伸長するためのデコードソフト（復号プログラム）とが収納されているオーディオファイルをメモリカードから読み出すＣＰＵと、
　メモリカードから読み出されたオーディオファイルに収納されたデコードソフトに従って、音楽データをデコードするＤＳＰと
　を含み、
　オーディオファイルのヘッダ以降には、セキュリティ情報，コンテンツ情報，付加情報がこの順で収納され、所定フォーマットで圧縮処理を施された１曲分の音楽データ（音声データ）が、付加情報に続いて収納されており、
　コンテンツ情報には、音楽データがどのようなフォーマットで圧縮されているかを示す圧縮フォーマット情報、付加情報としてどのようなデータが含まれているかを示す付加情報管理テーブルが含まれ、
　付加情報には、音楽データを伸長するためのデコードソフト（復号プログラム）が含まれ、
　ＤＳＰのタイプ（１６ビット演算であるか２４ビット演算であるか）によって、対応できるデコードソフトが異なり、
　付加情報管理テーブルに含まれるデコードソフト情報は、圧縮フォーマット情報およびタイプ情報を含む概念であり、
　ＣＰＵは、付加情報管理テーブルを参照して、オーディオファイルに収納されたデコードソフトのうち、ＤＳＰに対応するデコードソフトをメモリカードから読み出し、ＤＳＰに設けられたＲＡＭにロードし、メモリカードに記録されたオーディオファイルから音楽データを読み出し、
　ＤＳＰは、音楽データをＲＡＭに格納されたデコードソフトに従ってデコードする携帯型音声記録再生装置。」
　
　なお、引用例１には、ＤＳＰには、いかなるデコードソフトも格納せず、常にオーディオファイルに含まれるデコードソフトによって音楽データをデコードするようにしてもよい（【００５４】）ことが記載されており、この記載からも、引用発明を上記のように認定し得る。
　
　同じく、当審の平成２４年９月６日付け拒絶理由通知に引用した、本願の優先権主張の日前に頒布された刊行物である特開２００２−３１８５９８号公報（平成１４年１０月３１日公開、以下「引用例２」という。）には、図面と共に、以下の記載がある。（なお、下線は当審で付与した。）
　
（１１）「【０００２】
【従来の技術】音声や映像等のデータサイズを高能率に圧縮するために、様々な方式の符号化（データ圧縮）技術が提案されている。例えば、携帯型音楽再生装置の分野では、限られた容量の半導体メモリの中に、より高音質で、より大量の音楽信号を記録するための符号化方式であるＭＰ３（MPEG Audio Layer 3）方式に対応した音楽再生装置が普及しつつあり、また、ＭＰ３方式以外にも、ＡＡＣ（Advanced Audio Coding）方式やＷＭＡ（Ｗｉｎｄｏｗｓ（登録商標）  Ｍｅｄｉａ  Ａｕｄｉｏ）方式など、新しい符号化方式が次々に登場している。
【０００３】一般に、新製品開発が激しい分野では、その製品のライフサイクルは非常に短いものになってしまう。例えば、新しい符号化方式が普及してしまうと、古い符号化方式にのみ対応している再生装置では新方式に対応できず、そのためユーザは新方式に対応した製品を新たに購入しなければならない。
【０００４】ところが、このような再生装置のハードウェア構成は、符号化方式が変わっても大きな差はなく、情報の復号化を行う部分のアルゴリズムが若干異なるのみである。
【０００５】そこで、復号化の処理部分をソフトウェアによる処理で実現し、再生装置内部の半導体メモリに複数種類の復号化ソフトウェアを搭載することで、異なる符号化方式に対応可能な再生装置や、再生装置内部の半導体メモリに搭載されている符号化プログラムを書き換え可能にすることで、新方式の復号化技術に対応可能な再生装置なども登場している。」
　
（１２）「【００４１】第１の半導体メモリ１３には、例えば、図２に示すようなファイル構造で、符号化された音楽データと復号化処理プログラムを記録しておく。図２に示した例では、フォルダを符号化方式の種類別に分け、ＭＰ３方式の「フォルダＭＰ３」、ＡＡＣ方式の「フォルダＡＡＣ」、ＷＭＡ方式の「フォルダＷＭＡ」の３つのフォルダが作成されており、各フォルダには、その符号化方式に対応した符号化プログラムと、その符号化方式で符号化された音楽データとが格納されている。例えば、「フォルダＭＰ３」には、「mp3decode.prg」というＭＰ３方式に対応した復号化プログラムと、「01title.mp3」「02title.mp3」「03title.mp3」、等々、ＭＰ３方式にて符号化された音楽データである、音声デジタルデータのファイル群とが格納されている。また、
各音声デジタルデータのヘッダ情報等には、どのような符号化方式にて符号化されたかを示す情報が格納されている。
　
（１３）「【００６７】一般に、光学的記録媒体は、半導体メモリカードなどに比べると記録容量が非常に豊富であるため、以上説明したような音楽情報の再生だけでなく、画像情報、あるいは音声情報と画像情報との組み合わせなどの再生装置としても利用することができる。動画像の符号化方式も様々な方式が開発されており、例えば、ＭＰＥＧ１（Moving Picture Experts Group phase 1）、ＭＰＥＧ２（Moving Picture Experts Group phase 2）、ＭＰＥＧ４（Moving Picture Experts Group phase 4）、ＷＭＶ（Windows Media Video）などの符号化方式が普及している。
【００６８】従来、ある特定の符号化方式に専用に対応した再生装置（例えば、ＭＰＥＧ１方式の動画像デジタルデータをＣＤ−ＲＯＭに記録したＶｉｄｅｏ−ＣＤフォーマット専用の再生装置）では、異なる符号化方式（例えば、ＭＰＥＧ４方式やＷＭＶ方式）で符号化された動画像デジタルデータを再生することができなかった。
【００６９】これに対して、本発明の情報再生装置３０によれば、デジタル情報を記録するＣＤ−ＲＯＭディスク３３に、ＭＰＥＧ１、ＭＰＥＧ２、ＭＰＥＧ３、ＷＭＶ等の各種符号化方式に対応した復号化プログラムをそれぞれ記録させておくだけで、複数種類の符号化方式に、あるいは新しい種類の符号化方式に、容易に且つ柔軟に対応することができる。」
　
３．対比
　
　そこで、本願発明と引用発明とを対比する。
　
（１）マルチメディア再生装置
　引用発明は「音声記録再生装置」であるところ、「音声記録再生装置」は、「音声を再生する装置」を含んでおり、音声は１つのメディアであるから、引用発明の「音声記録再生装置」は、「メデイアを再生する装置」、すなわち、「メディア再生装置」といい得るものである。
　もっとも、再生するメディアがマルチメディアとはしていないから、「
マルチ
マルチ
　
（２）読出部
　本願発明の「マルチメディアコンテンツと前記マルチメディアコンテンツをデコーディングするコーデックとが結合されたマルチメディアデータ」に対応するものとして、引用発明でも「オーディオファイル」が認められ、当該「オーディオファイル」には、「所定フォーマットで圧縮処理を施された１曲分の音楽データ（音声データ）」が「音楽データを伸長するためのデコードソフト（復号プログラム）が含まれ」る「付加情報に続いて収納されて」いるところ、
　引用発明の、上記「音楽データ」は、「メディアコンテンツ」といえ、
　「デコードソフト（復号プログラム）」は、「音楽データ」を復号するためのものであるから、「デコーディングするコーデック」といえ、
　これらが、同じ「オーディオファイル」に収納されているのであるから、これらが「結合」されているといえ、また、「オーディオファイル」は「メディアデータ」ともいい得るものである。
　そうすると、引用発明の「オーディオファイル」も、「メディアコンテンツと前記メディアコンテンツをデコーディングするコーデックとが結合されたメディアデータ」といい得、そのようにいい得る点においては、本願発明の「マルチメディアコンテンツと前記マルチメディアコンテンツをデコーディングするコーデックとが結合されたマルチメディアデータ」と相違しない。
　もっとも、「メディアコンテンツ」「前記メディアコンテンツをデコーディングするコーデック」「メディアデータ」を「
マルチ
マルチ
マルチ
　引用発明の「メモリカード」は「記録媒体」といい得、引用発明の「ＣＰＵ」は、「オーディオファイル」をメモリカードから読み出すから、引用発明も「メディアデータ」を「記録媒体」から読み出す「読出部」を備えている。
　したがって、本願発明と引用発明は、
　「メディアコンテンツと前記メディアコンテンツをデコーディングするコーデックとが結合されたメディアデータを記録媒体から読み出す読出部」を含んでいる点で一致し、
　上記「メディアコンテンツ」「前記メディアコンテンツをデコーディングするコーデック」「メディアデータ」が、本願発明では「
マルチ
マルチ
マルチ
　
（３）再生部
　引用発明の「ＣＰＵ」は、オーディオファイルに収納されたデコードソフトのうち、ＤＳＰに対応するデコードソフトを読み出し、ＤＳＰに設けられたＲＡＭにロードするから、「前記読み出されたメディアデータから」「前記コーデック」を「抽出」するといえる。引用発明の「ＤＳＰ」は、音楽データをＲＡＭに格納されたデコードソフトに従ってデコードするから、「抽出された前記コーデックを利用して、前記メディアコンテンツを再生する」といえる。
　したがって、引用発明も「前記読み出されたメディアデータから抽出された前記コーデックを利用して、前記メディアコンテンツを再生する再生部」を備えている。
　もっとも、「メディアデータ」「メディアコンテンツ」を「
マルチ
マルチ
　
（４）マルチメディアデータの構造
　〈マルチメディアデータ〉
　本願発明の「マルチメディアデータ」は、「前記コーデックの特性に関する情報が記録されたヘッダと、前記マルチメディアコンテンツをデコーディングするコーデックの実行コードが記録されたコーデックトラックとをさらに含み」としていて、その「ヘッダ」、「コーデックトラック」は、「メディアデータ」の『区分けされた部分領域』といえるところ、
　本願発明の「マルチメディアデータ」に対応し「メディアデータ」といい得る点で一致する引用発明の「オーディオファイル」も、「ヘッダ以降には、セキュリティ情報，コンテンツ情報，付加情報がこの順で収納され、所定フォーマットで圧縮処理を施された１曲分の音楽データ（音声データ）が、付加情報に続いて収納されており」としていて、その「ヘッダ」、「セキュリティ情報」、「コンテンツ情報」、「付加情報」、「音楽データ」も、「メディアデータ」の『区分けされた部分領域』といい得るものである。
　
　〈ヘッダ（前記コーデックの特性に関する情報が記録されたヘッダ）〉
　そして、引用発明の「コンテンツ情報」には、「音楽データがどのようなフォーマットで圧縮されているかを示す圧縮フォーマット情報、付加情報としてどのようなデータが含まれているかを示す付加情報管理テーブルが含まれ」、その「コンテンツ情報」の「付加情報管理テーブル」に含まれる「デコードソフト情報」は、デコードソフトが従う圧縮フォーマットと対応するＤＳＰのタイプを示す情報であるから、「コーデックの特性に関する情報」ということができる。
　すなわち、引用発明では「メディアデータ」（オーディオファイル）の『区分けされた部分領域』である「コンテンツ情報」に「コーデックの特性に関する情報が記録され」ている。
　そうすると、引用発明も「メディアデータは、前記コーデックの特性に関する情報が記録された『区分けされた部分領域』」を含むといえ、この点では本願発明と一致する。もっとも、（先頭の『区分けされた部分領域』と解される）「ヘッダ」とする本願発明とは相違する。
　
　〈コーデックトラック（マルチメディアコンテンツをデコーディングするコーデックの実行コードが記録されたコーデックトラック）〉
　また、引用発明の『区分けされた部分領域』である「付加情報」には、「音楽データを伸長するためのデコードソフト（復号プログラム）」が含まれるから、その『区分けされた部分領域』である「付加情報」は、本願発明でいう「コーデックトラック」ということができる。
　《実行コード》
　本願発明でいう「実行コード」についてみるに、該「実行コード」とは、明細書の記載（段落【００３２】「コーデックの実行コードは、実行可能なバイナリコードの形式または解釈可能なスクリプト形式で具現できる。例えば、特定のプラットホームに最適化されたバイナリコードの形式には、ｗｉｎ３２ ｅｘｅｃｕｔａｂｌｅ形式の実行コードが含まれることができる。また、コーデックの動作を記述したスクリプト言語形式の実行コードが含まれることもある。」）、および、請求項１の「前記コーデックトラックにあるコーデックをメモリにロードして実行させることによって、前記マルチメディアコンテンツをデコーディングする」に照らせば、
　プログラムの特定の形式（実行可能なバイナリコードの形式とか記述言語（スクリプト言語）形式とか）に限定するものではなく、結果的に「メモリにロードして実行させること」ができるコードであれば足りると解されるところ、
　引用発明は、「デコードソフト（復号プログラム）」の形式について特定していないが、「ＣＰＵは、付加情報管理テーブルを参照して、オーディオファイルに収納されたデコードソフトのうち、ＤＳＰに対応するデコードソフトをメモリカードから読み出し、ＤＳＰに設けられたＲＡＭにロードし、メモリカードに記録されたオーディオファイルから音楽データを読み出し、
　ＤＳＰは、音楽データをＲＡＭに格納されたデコードソフトに従ってデコードする」ものであって、結果的に「メモリにロードして実行させること」ができるプログラムであることは明らかであり、
　また、プログラムである以上、実行可能なバイナリコードの形式や記述言語（スクリプト言語）形式など、何らかの具体形式で記録された「コード」であると普通に想定されるものである。
　したがって、引用発明の、本願発明でいう「コーデックトラック」といい得る（『区分けされた部分領域』である）「付加情報」、に含まれる「デコードソフト（復号プログラム）」も、本願発明でいう「実行コード」が記録されたもの、といえ、この点において相違するものとはいえない。
　
　〈まとめ〉
　以上によれば、本願発明と引用発明は、
　「前記メディアデータは、前記コーデックの特性に関する情報が記録された『区分けされた部分領域』と、前記メディアコンテンツをデコーディングするコーデックの実行コードが記録されたコーデックトラックとをさらに含み、」といい得る点においては、相違しない。
　もっとも、「メディアデータ」「前記メディアコンテンツをデコーディングするコーデック」を「
マルチ
マルチ
　
（５）再生部の構造
　引用発明において、ＣＰＵは、付加情報管理テーブルを参照して、オーディオファイルに収納されたデコードソフトのうち、ＤＳＰに対応するデコードソフトをメモリカードから読み出し、ＤＳＰに設けられたＲＡＭにロードし、ＤＳＰは、音楽データをＲＡＭに格納されたデコードソフトに従ってデコードするから、引用発明の「ＲＡＭ」は、「コーデック」が「ロード」される「メモリ」といえる。引用発明の「ＤＳＰ」は、音楽データをデコードするから、音楽データをデコードする「エンジン」といえ、さらに、ＲＡＭにロードされるデコードソフトを変えれば処理内容を変えることができ、「どのようなフォーマットで符号化された音声信号も再生できる」（【０００４】）ようにするものといえ、「汎用」の「エンジン」、すなわち、「汎用エンジン」といえる。
　したがって、引用発明においても、「前記再生部は、前記『区分けされた部分領域』を参照して、前記コーデックトラックにあるコーデックをメモリにロードして実行させることによって、前記メディアコンテンツをデコーディングする汎用エンジンを含む」。
　もっとも、「メディアコンテンツ」を「
マルチ
　
　そうすると、本願発明と引用発明とは、次の点で一致する。
　
＜一致点＞
　
「メディア再生装置において、
　メディアコンテンツと前記メディアコンテンツをデコーディングするコーデックとが結合されたメディアデータを記録媒体から読み出す読出部と、
　前記読み出されたメディアデータから抽出された前記コーデックを利用して、前記メディアコンテンツを再生する再生部と
　を含み、
　前記メディアデータは、前記コーデックの特性に関する情報が記録された『区分けされた部分領域』と、前記メディアコンテンツをデコーディングするコーデックの実行コードが記録されたコーデックトラックとをさらに含み、
　前記再生部は、前記『区分けされた部分領域』を参照して、前記コーデックトラックにあるコーデックをメモリにロードして実行させることによって、前記メディアコンテンツをデコーディングする汎用エンジンを含むメディア再生装置。」の点。
　
　そして、次の点で相違する。
　
＜相違点＞
　
（１）「メディア再生装置」「メディアコンテンツ」「メディアコンテンツをデコーディングするコーデック」「メディアデータ」が、
　本願発明では、「マルチメディア再生装置」「マルチメディアコンテンツ」「マルチメディアコンテンツをデコーディングするコーデック」「マルチメディアデータ」であるのに対して、
　引用発明では、「音楽記録再生装置」「音楽データ」「音楽データを伸長するためのデコードソフト（復号プログラム）」「オーディオファイル」であって、「
マルチ
マルチ
マルチ
マルチ
　
（２）「コーデックの特性に関する情報が記録された『区分けされた部分領域』」が、本願発明では、「ヘッダ」であるのに対して、引用発明では、ヘッダ以降の「コンテンツ情報」であって、「ヘッダ」とはしていない点。
　
　なお、請求人は、平成２４年１２月１１日付け意見書において、本願発明の「汎用エンジン」を含む装置では、プラットフォームまたはＯＳに制限されずに、コーデックトラックに含まれたコーデックをロードしてコンテンツを再生できる旨主張している。
　しかしながら、明細書には、汎用エンジンとしてＪＡＶＡ仮想マシンを採用することにより、プラットホームやＯＳの種類に関係なく、ＪＡＶＡで具現されたコーデックを実行させることができることは記載されているものの、「汎用エンジン」自体が、プラットフォームまたはＯＳに制限されずに、コーデックトラックに含まれたコーデックをロードしてコンテンツを再生できるものに限られるとの記載はなく、本願発明の「汎用エンジン」をそのようなものに限定して解することはできない。
　
　また、請求人は、同意見書において、引用例１では、ＤＳＰのＲＯＭに既に保有しているデコードソフトを先に検討してから、ようやくオーディオファイルに含まれたデコードソフトを使用することができるという点で本願発明と相違する旨主張している。
　しかしながら、前述したように、引用発明は、ＤＳＰには、いかなるデコードソフトも格納せず、常にオーディオファイルに含まれるデコードソフトによって音楽データをデコードするものも含む。
　また、請求項１に記載された本願発明は、「前記コーデックトラックにあるコーデックをメモリにロードして実行させることによって、前記マルチメディアコンテンツをデコーディングする」ことができれば足り、請求項１の記載からは、既にメモリにロードされているコーデックを使用することができる場合でもなお、改めてコーデックトラックにあるコーデックをメモリにロードするものに限られるとは解し得ない。
　
　したがって、一致点・相違点を上記のように認定し得る。
　
４．判断
　
　そこで、上記相違点について検討する。
　
相違点（１）について
　引用例１に接した当業者が、引用発明におけるメディアである音声を、映像と音声のマルチメディアに変更することは、容易に想起するというべきである。
　なぜなら、音声に多くの符号化方式があるのと同様に、例えば、マルチメディアとして典型的な、映像と音声のマルチメディアにおいても、多くの符号化方式があることは、技術常識かつ周知であり、
　また、音声においてもマルチメディアにおいても、符号化されたものを再生するには、それぞれ対応するコーデックを使用しなければならないことに変わりはないこともまた、技術常識かつ周知であるからであり（例えば、引用例２【０００２】〜【０００５】【００６７】〜【００６９】等参照）、
　映像と音声のマルチメディアにおいても、引用発明の構成を適用すれば、引用発明と同様の課題解決ができることは、当業者に自明であるからである。
　そして、そのように変更すれば、引用発明における「音楽記録再生装置」（メディア再生装置）「音楽データ」（メディアコンテンツ）「オーディオファイル」（メディアデータ）は、「マルチメディア再生装置」「マルチメディアコンテンツ」「マルチメディアデータ」となり、結果、「音楽データを伸長するためのデコードソフト（復号プログラム）」（メディアコンテンツをデコーディングするコーデック）は、「マルチメディアコンテンツをデコーディングするコーデック」となり、そして相違点１は克服される。
　したがって、上記相違点１を克服して、「音楽記録再生装置」「音楽データ」「音楽データを伸長するためのデコードソフト（復号プログラム）」「オーディオファイル」を「マルチメディア再生装置」「マルチメディアコンテンツ」「マルチメディアコンテンツをデコーディングするコーデック」「マルチメディアデータ」とすることは、当業者が容易に想到し得る。
　
相違点（２）について
　ファイルの属性に関する情報を、ファイルの実質的な内容に先行する、ファイルの先頭部分に格納することはごく普通に行われている。そして、引用例２には、どのような符号化方式にて符号化されたかを示す情報を各音声デジタルデータのヘッダ情報に格納する構成が記載されている（【００４１】）。
　当業者は係る知見を有しており、当業者であれば、引用発明における、圧縮フォーマット情報およびタイプ情報を含む概念であるデコードソフト情報が収納される位置をオーディオファイルのコンテンツ情報の位置に代えて、ヘッダの位置とすることは、容易に想到し得る。
　あるいは、引用発明における、「ヘッダ」、「セキュリティ情報」、「コンテンツ情報」、「付加情報」および「音楽データ」がこの順で収納されるオーディオファイルの、「付加情報」および「音楽データ」をファイルの実質的な内容と捉え、これに先行するファイルの先頭から「音楽データがどのようなフォーマットで圧縮されているかを示す圧縮フォーマット情報、付加情報としてどのようなデータが含まれているかを示す付加情報管理テーブルが含まれ」る「コンテンツ情報」までをヘッダと称することは、当業者が容易に想到し得る。
　
　効果についてみても、上記構成の変更に伴って当然に予測される程度のことに過ぎず、格別顕著なものがあるとは認められない。
　
５．むすび
　
　以上のとおり、本願の請求項１に係る発明は、引用例１、２に記載された発明に基づいて当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　したがって、本願は、その余の請求項について論及するまでもなく拒絶すべきものである。
　
　よって、結論のとおり審決する。