【事件の表示】
　特願２００７−１１１３３３「ソフトウェアモジュールの組合せによってＤＳＰコードを生成する装置及びその方法」拒絶査定不服審判事件〔平成１９年１１月１５日出願公開、特開２００７−３００６１３〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
　
　本願は、平成１９年４月２０日（パリ条約による優先権主張　２００６年５月３日（ＫＲ）大韓民国）の出願であって、平成２２年１月２８日付けの拒絶理由通知に対し同年５月７日付けで手続補正がなされたところ、同年５月２１日付けで拒絶査定がなされ、これに対し、同年１０月１日付けで拒絶査定不服審判の請求がなされるとともに、同日付けで手続補正がなされたものである。
　
第２　平成２２年１０月１日付けの手続補正についての補正却下の決定
　
［補正却下の決定の結論］
　平成２２年１０月１日付けの手続補正を却下する。
　
［理由］
１　補正前と補正後の特許請求の範囲
　平成２２年１０月１日付けの手続補正（以下、「本件補正」という。）は、平成２２年５月７日付け手続補正書の特許請求の範囲に記載された、
　
（補正前の特許請求の範囲）
「【請求項１】
　デジタルシグナルプロセッサ（ＤＳＰ）処理部と、
　コーデックサーバから第１のソフトウェアモジュールをダウンロードする手段と、
　ダウンロードされた第１のソフトウェアモジュールと、少なくとも第２のソフトウェアモジュールとを記憶する記憶部と、
　前記記憶された第１と第２のソフトウェアモジュールを組合せてＤＳＰコードを生成し、前記ＤＳＰ処理部にロードするＤＳＰコード生成部と、を有し、
　前記ＤＳＰ処理部は前記ロードされたＤＳＰコードをデコーディングして、前記第１のソフトウェアモジュールに対応するマルチメディアコンテンツを処理することを特徴とする装置。
　　【請求項２】
　前記第２のソフトウェアモジュールは、ＯＳ、メディアフレームワーク、またはハードウェアライブラリであることを特徴とする請求項１に記載の装置。
　　【請求項３】
　前記マルチメディアコンテンツに対応する前記第１のソフトウェアモジュールが前記記憶部に記憶されていない場合、外部ネットワークに位置した前記コーデックサーバに前記第１のソフトウェアモジュールのダウンロードを要求するメッセージを生成及び伝送する制御部をさらに含むことを特徴とする請求項１に記載の装置。
　　【請求項４】
　前記コーデックサーバから伝送される第１のソフトウェアモジュールは、コーデックライブラリであることを特徴とする請求項３に記載の装置。
　　【請求項５】
　所定マルチメディアコンテンツをＤＳＰ処理部に実行させるためのＤＳＰコードを要求する段階と、
　前記マルチメディアコンテンツを実行させるコーデックライブラリが記憶されているか否かを判断する段階と、
　前記判断結果、該当コーデックライブラリが記憶されていれば、前記コーデックライブラリと他のソフトウェアモジュールとを組合せてＤＳＰコードを生成し、前記ＤＳＰ処理部にロードする段階と、
　前記ロードされたＤＳＰコードをデコーディングして、前記ＤＳＰ処理部に前記マルチメディアコンテンツを実行させる段階と、
を含むことを特徴とする方法。
　　【請求項６】
　前記他のソフトウェアモジュールは、ＯＳ、メディアフレームワーク、及びハードウェアライブラリであることを特徴とする請求項５に記載の方法。
　　【請求項７】
　前記判断結果、該当コーデックライブラリが記憶されていない場合、外部ネットワークに位置したコーデックサーバに前記コーデックライブラリを要求する段階と、
　前記コーデックサーバから伝送されたコーデックライブラリを受信してダウンロードする段階と、
をさらに含むことを特徴とする請求項５に記載の方法。」を、
　
　平成２２年１０月１日付けの手続補正書の特許請求の範囲に記載された、
　
（補正後の特許請求の範囲）
「【請求項１】
　デジタルシグナルプロセッサ（ＤＳＰ）処理部と、
　コーデックサーバから第１のソフトウェアモジュールをダウンロードする手段と、
　ダウンロードされた第１のソフトウェアモジュールと、少なくとも第２のソフトウェアモジュールとを記憶する記憶部と、
　前記記憶された第１と第２のソフトウェアモジュールを組合せてＤＳＰコードを生成し、前記ＤＳＰ処理部にロードするＤＳＰコード生成部と、を有し、
　前記ＤＳＰ処理部は前記ロードされたＤＳＰコードをデコーディングして、前記第１のソフトウェアモジュールに対応するマルチメディアコンテンツを処理
し、
　
前記マルチメディアコンテンツは前記コーデックサーバの位置情報と前記第１のソフトウェアモジュールの識別情報とを含み、
　
前記マルチメディアコンテンツに対応する前記第１のソフトウェアモジュールが前記記憶部に記憶されていない場合、前記コーデックサーバの位置情報と前記第１のソフトウェアモジュールの識別情報とに基づき、外部ネットワークに位置した前記コーデックサーバに前記第１のソフトウェアモジュールのダウンロードを要求するメッセージを生成及び伝送する制御部をさらに有する
　　【請求項２】
　前記第２のソフトウェアモジュールは、ＯＳ、メディアフレームワーク、またはハードウェアライブラリであることを特徴とする請求項１に記載の装置。
　　【請求項
３
　前記コーデックサーバから伝送される第１のソフトウェアモジュールは、コーデックライブラリであることを特徴とする請求項
１
　　【請求項
４
　所定マルチメディアコンテンツをＤＳＰ処理部に実行させるためのＤＳＰコードを要求する段階と、
　前記マルチメディアコンテンツを実行させるコーデックライブラリが記憶されているか否かを判断する段階と、
　前記判断結果、該当コーデックライブラリが記憶されていれば、前記コーデックライブラリと他のソフトウェアモジュールとを組合せてＤＳＰコードを生成し、前記ＤＳＰ処理部にロードする段階と、
　前記ロードされたＤＳＰコードをデコーディングして、前記ＤＳＰ処理部に前記マルチメディアコンテンツを実行させる段階と、
を含む方法であって、
　
前記マルチメディアコンテンツはコーデックサーバの位置情報と前記コーデックライブラリの識別情報とを含み、
　
前記方法は、さらに、
　
前記判断結果、該当コーデックライブラリが記憶されていない場合、前記コーデックサーバの位置情報と前記コーデックライブラリの識別情報とに基づき、外部ネットワークに位置した前記コーデックサーバに前記コーデックライブラリを要求する段階と、
　
前記コーデックサーバから伝送されたコーデックライブラリを受信してダウンロードする段階と、
を含むことを特徴とする方法。
　　【請求項
５
　前記他のソフトウェアモジュールは、ＯＳ、メディアフレームワーク、及びハードウェアライブラリであることを特徴とする請求項
４
　に変更することを含むものである。（なお、下線部は、補正前の特許請求の範囲に対する補正箇所である。）
　
２　補正の適否
（１）新規事項の有無、補正の目的要件
　本件補正は、願書に最初に添付した明細書又は図面に記載した事項の範囲内においてなされたものであって、
　上記補正前の請求項１を削除し、上記補正前の請求項１を引用する上記補正前の請求項３に記載された発明に対して、「マルチメディアコンテンツ」が、「コーデックサーバの位置情報と前記第１のソフトウェアモジュールの識別情報とを含」むものであると具体的に限定し、さらに、前記マルチメディアコンテンツに対応する前記第１のソフトウェアモジュールが前記記憶部に記憶されていない場合、「前記コーデックサーバの位置情報と前記第１のソフトウェアモジュールの識別情報とに基づき」、外部ネットワークに位置した前記コーデックサーバに前記第１のソフトウェアモジュールのダウンロードを要求するメッセージを生成及び伝送するものであると、具体的に限定したものを、上記補正後の請求項１とし、
　同様に、上記補正前の請求項５を削除し、上記補正前の請求項５を引用する上記補正前の請求項７に記載された発明に対して、「マルチメディアコンテンツ」が、「コーデックサーバの位置情報と前記コーデックライブラリの識別情報とを含」むものであると具体的に限定し、さらに、該当コーデックライブラリが記憶されていない場合、「前記コーデックサーバの位置情報と前記コーデックライブラリの識別情報とに基づき」、外部ネットワークに位置した前記コーデックサーバに前記コーデックライブラリを要求するものであると、具体的に限定したものを、上記補正後の請求項４とするものであるから、
　本件補正は、上記補正前の特許請求の範囲に記載された発明を特定するために必要な事項を限定して特許請求の範囲を減縮したものに該当し、特許法第１７条の２第３項（新規事項）および同条第５項第２号（特許請求の範囲の減縮）の規定に適合している。
　
（２）独立特許要件
　本件補正は、特許請求の範囲の減縮を目的とするものであるから、次に、本件補正後における特許請求の範囲に記載されている事項により特定される発明が特許出願の際独立して特許を受けることができるものであるのかどうかについて以下に検討する。
　
ア　補正後の発明
　補正後における特許請求の範囲に記載される事項により特定される発明は、上記「１　補正前と補正後の特許請求の範囲」の項で認定したとおりであるところ、請求項１に係る発明は、平成２２年１０月１日付け手続補正書の特許請求の範囲の請求項１に記載された以下のとおりのものである。
　
「【請求項１】
　デジタルシグナルプロセッサ（ＤＳＰ）処理部と、
　コーデックサーバから第１のソフトウェアモジュールをダウンロードする手段と、
　ダウンロードされた第１のソフトウェアモジュールと、少なくとも第２のソフトウェアモジュールとを記憶する記憶部と、
　前記記憶された第１と第２のソフトウェアモジュールを組合せてＤＳＰコードを生成し、前記ＤＳＰ処理部にロードするＤＳＰコード生成部と、を有し、
　前記ＤＳＰ処理部は前記ロードされたＤＳＰコードをデコーディングして、前記第１のソフトウェアモジュールに対応するマルチメディアコンテンツを処理し、
　前記マルチメディアコンテンツは前記コーデックサーバの位置情報と前記第１のソフトウェアモジュールの識別情報とを含み、
　前記マルチメディアコンテンツに対応する前記第１のソフトウェアモジュールが前記記憶部に記憶されていない場合、前記コーデックサーバの位置情報と前記第１のソフトウェアモジュールの識別情報とに基づき、外部ネットワークに位置した前記コーデックサーバに前記第１のソフトウェアモジュールのダウンロードを要求するメッセージを生成及び伝送する制御部をさらに有することを特徴とする装置。」（以下、「補正後の発明」という。）
　
イ　引用例１
（ア）引用例１の記載事項
　原審の拒絶理由に引用され、本願の優先日前に頒布された“Naoto SHIMIZU,et al, A Novel Decoder-downloadable System for Content-oriented Coding, Global Telecommunications Conference, 2002. GLOBECOM '02. IEEE, 2002年11月17日, Volume.2, pages.1638-1642”（以下、「引用例１」という。）には、“A Decorder-downloadable System”に関して、図面とともに下記の事項が記載されている。
　
　ａ　「Abstract−
　In this paper, a new system architecture called decoder downloadable system is described. The purpose of this system is to provide a uniform platform for the multimedia world based on image compressions using characteristics of the contents. This system enables dynamic decoder downloading by negotiation between servers and clients for seamless and minimum delay playback. This negotiation scheme is implemented by Java and CORBA (Common Object Request Broker). Thus, servers and clients in this system are independent from OSes and hardware specifications. This system is suitable for TV broadcasting as well as Internet streaming.
　We improve a decoder architecture in order to make the system more flexible. A decoder has some functions such as bitstream parsing, image compression algorithm (DCT, Wavelet, Motion estimation and so on). However, conventional decoders are monolithic software. Thus, it is impossible to share parts of decoders. The proposed method enables a module-based decoder and sharing some modules among some decoders. Consequently, the flexible decoder can make downloading time shorter by avoidance to download redundant parts of decoders. It also achieves scalability enabling this system to be used in some multimedia applications, such as a multimedia content search system as well as a multimedia player. 」（１６３８頁左欄１〜２４行）
　
（訳文　要約
　この論文では、デコーダ・ダウンローダブル・システムと呼ばれる新しいシステム・アーキテクチャが述べられている。このシステムの目的は、コンテンツの特性を使用して、画像圧縮に基づいたマルチメディア界のための一定のプラットフォームを提供することである。このシステムは、シームレスで、遅延を最小にする再生のための、サーバおよびクライアントの間のネゴシエーションによってダウンロードするダイナミックなデコーダを可能にする。このネゴシエーション機構は、ジャバおよびＣＯＲＢＡ（共通オブジェクト・リクエスト・ブローカー）によってインプリメントされる。したがって、このシステムでのサーバおよびクライアントは、ＯＳやハードウェアの仕様からは独立している。このシステムはインターネット・ストリームと同様にテレビ放送にも適している。
　我々は、システムをより柔軟にするためにデコーダ・アーキテクチャを改善する。デコーダにはビットストリーム解析、映像圧縮アルゴリズム（ＤＣＴ、ウェーブレット、モーション推定など）のようないくつかの機能を有する。しかしながら、従来のデコーダは単一体のソフトウェアである。したがって、デコーダの一部分を共有することができない。提案された方法は、モジュールベースのデコーダおよびいくつかのデコーダ中に数モジュールを共有することを可能にする。従って、フレキシブル・デコーダは、デコーダの冗長部分をダウンロードすることを回避することによって、ダウンロードする時間をより短くすることができる。さらに、それは、マルチメディア・プレーヤーと同様にマルチメディアのコンテンツ検索システムのような、いくつかのマルチメディアアプリケーションの中でこのシステムが使用されることを可能にすることにより、スケーラビリティを達成するものである。）
　
　ｂ　「Ｉ. INTRODUCTION
　Discrete Cosine Transform (DCT) based coding, such as MPEG and JPEG, has been widely used for image compression. However, DCT-based approach may not be suitable for all kinds of images. Some types of images may be encoded efficiently by a method taking the characteristics of the image content into account. We call it Content-oriented coding scheme. As its example, we have been studying animation image coding [1]. From this study, an open system architecture that we can distribute our animation image decoder on Internet Streaming and TV broadcasting is desired. However, no open system fulfilling the requirement has been reported. Thus, we implement the system called decoder-downloadable system. In this paper, we present the system architecture. 
　In multimedia world based on Content-oriented coding scheme, it is anticipated that the number of image compression algorithm increases. Conventional decoders are developed as monolithic software. However, there are parts that decoders can share. Thus, their redundancies are eliminated by realizing module-based decoders, which are composed some modules and share them among decoders. We call these module based decoders flexible decoder. Designed decoders in this system as flexible decoder provide several advantages. 
　These proposal concept model is shown in Fig.1. The proposed system architecture provides a new way for all multimedia applications to share a variety of modules and functionality in a platform-, vendor-, and location-neutral environment.
　
II. DECODER-DOWNLOADABLE SYSTEM
A. Problem of plug-in system
　Multimedia systems on the Internet, such as Microsoft Media Player, Real player, provide functions to deal with new types of media by installing the appropriate software when it is required. Such optionally downloaded software is called Plug-in.」（１６３８頁左欄２５行〜右欄１９行）
　
（訳文　Ｉ．はじめに
　ＭＰＥＧやＪＰＥＧのような離散コサイン変換（ＤＣＴ）ベースの符号化は、画像圧縮に広く使用されている。しかしながら、ＤＣＴベースのアプローチは、すべての種類の画像に適しているわけではない。いくつかのタイプの画像は、映像コンテンツの特性を考慮して効率的に符号化されてもよい。我々は、これを「コンテンツ指向のコーディング・スキーム」と呼ぶ。その例として、我々は、［１］のアニメーション画像のコーディングを検討している。この研究から、私たちがアニメーション画像デコーダを分配することができるオープンシステム・アーキテクチャ、インターネット・ストリーミングやテレビ放送が望まれる。しかしながら、要求を満たすオープンシステムは報告されていない。したがって、我々は、「デコーダ・ダウンローダブル・システム」と呼ばれるシステムをインプリメントする。この論文では、我々はシステム・アーキテクチャを示す。
　コンテンツ指向のコーディング・スキームに基づいたマルチメディア界では、映像圧縮アルゴリズムの数が増加することが予想される。従来のデコーダは単一体のソフトウェアとして開発されている。しかしながら、デコーダが共有することができる部分が存在する。したがって、それらの冗長性はモジュールベースのデコーダの実現により除去される。それは複数のモジュールを構成し、デコーダの間でそれらを共有する。我々はこれらのモジュールベースのデコーダを「フレキシブル・デコーダ」と呼ぶ。このシステムにおいてフレキシブル・デコーダとして構想されるデコーダは、いくつかの利点を備えている。
　これらの提案概念モデルは図１に示される。提案システム・アーキテクチャは、すべてのマルチメディアアプリケーションにモジュールの多様性と、プラットフォーム・ベンダー・所在の何れに対しても中立な環境の機能性を共有する新たな方法を提供する。
　
ＩＩ．デコーダ・ダウンローダブル・システム
Ａ．プラグイン方式の問題
　マイクロソフト・メディア・プレイヤーやリアルプレイヤーのようなインターネット上のマルチメディア・システムは、それが必要とされる場合に適切なソフトウェアをインストールすることにより新しいタイプのメディアに対処する機能を提供する。そのような自由にダウンロードしたソフトウェアはプラグインと呼ばれる。）
　
　ｃ　「B. Proposed system architecture
　In this section, we propose the system architecture that enables to download decoders dynamically and to play back without delay. 
　The proposed system architecture is shown in Fig.2.
　A client is composed of five parts, which are Core engine, Schedule management engine, Decoder component management engine, File I/O, User Interface. Each interface between them is shown as a number of circles in Fig.2. Their details are described below.
　At a server-side, there are Content server storing actual bitstreams of contents, Decoder server storing binary codes of the decoders and Information server storing information describing a profile for each content (here after called content information). To detect the corresponding content information easily by information server, this information has a hierarchical structure. Content information is shown in Fig.3. Each server may be on the same machine or the different machines, which enable to archive load balancing. 
　We implement a client system by using Java. The part of media processing is developed with JMF (Java Media Framework)[3]. This is because the proposed system should work in the various environments. At the present time, it throws a little doubt to construct the part of media processing by using Java. Therefore, we design the system architecture in such a way that the module for media processing depending on JMF can be detached from other parts entirely. However, decoders developed by Java give a merit that server do not have to take care of the type of the client operating system. They are also useful for flexible decoder.
　CORBA (Common Object Request Broker) [4] is used to define its interface between servers and clients being independent from the hardware specification. Moreover, the system is independent from any transport protocol by CORBA GIOP (General Inter-ORB Protocol). Therefore, the system can be employed on the Internet, TV broadcasting, and mobile system and so on. 
　The procedure in the system is executed in the following order: 
(1) The scheduler management engine in the client system starts to get the content information. It parses the information and confirms the decoder component management engine whether the decoder has already existed in the client's side or not.
(2) If a client does not have the corresponding decoder, the scheduler management engine instructs the decoder component management engine to get the decoder URI. Decoder component management engine requires content server where the decoder is stored.
(3) Information server starts to find where the requested decoder is stored using decoder information. It returns decoder URI to the client.
(4) The scheduler management engine decides when to start downloading the decoder from decoder server and instructs the decoder component management engine. The timing to give the instruction is very important, because decoder downloading interrupt continuous media playback in case, such as low network bandwidth.
　
The role of each part in the system is as follows:
・Core engine
This part provides the implementation of media play, trick mode and so forth. The decoders are actually installed in this part.
・Decoder component management engine
This part manages decoders in the client's system, queries about what decoder is needed, downloads decoders, and deletes decoders in the stock.
・Schedule management engine
This part controls when to start media play, to download or to delete decoders. It instructs to each part that provides actual above functions in timely manner.
・User interface
This part is the interface for user input.
・File I/O
This part selects a protocol based on its usage: 1) CORBA, Sending and Receiving Content information, 2) HTTP / FTP, Downloading the binary data of decoders, or 3) RTP / MPEG2-TS, Receiving media data.
　
Each interface in the system is described below:
interface 1: Exchanging the information about decoders.
interface 2: Exchanging the information about the contents.
interface 3: Downloading binary data of decoders.
interface 4: Downloading media data of contents.
interface 5: Downloading EPG (Electronic Program Guide) data that is used in the client's scheduler.
interface 6: Providing of decoder modules to Core Engine.
interface 7: Indicating when decoder's memory load starts, providing the information about what state the memory load is.
interface 8: Indicating whether the decoder is added or deleted to the users.
interface 9: Providing the information about the contents, indicating when to start downloading the decoder and deleting the decoder in the client system, confirming for existence of decoders.
interface 10: Accepting of the input information by the users.
interface 11: Indicating the information of contents that can be played back, choosing the contents by the users.」（１６３９頁左欄２０行〜１６４０頁右欄１５行）
　
（訳文　Ｂ．提案システム・アーキテクチャ
　このセクションで、我々は、デコーダをダイナミックにダウンロードし、遅延なしに再生することを可能にするシステム・アーキテクチャを提案する。
　提案システム・アーキテクチャは図２に示される。
　クライアントは、「コアエンジン」、「スケジュール管理エンジン」、「デコーダ・コンポーネント管理エンジン」、「ファイル入出力」、「ユーザ・インターフェース」の５つの部分から構成される。それらの間のインターフェースはそれぞれ図２に円付きの数字として示されている。それらの詳細は下記のとおりである。
　サーバ側には、実際のコンテンツのビットストリームを格納する「コンテンツサーバ」、デコーダのバイナリコードを格納する「デコーダ・サーバ」、および各コンテンツのためのプロファイルを記述した情報（以下、コンテンツ情報という。）を格納する「情報サーバ」を有する。情報サーバによって対応するコンテンツ情報を容易に検知するために、この情報には階層構造を有する。コンテンツ情報は図３に示される。サーバはそれぞれ同じマシンあるいは負荷が均一になるように保管可能とするため、異なるマシン上に存在していても良い。
　我々はＪａｖａの使用によりクライアントシステムをインプリメントする。メディア・プロセシングの部分はＪＭＦ（ジャバ・メディア・フレームワーク）［３］で開発されている。これは提案システムが様々な環境で働くべきであるからである。現時点において、Ｊａｖａを使ってメディア・プロセシング部分を構築することには、少々疑問がある。したがって、我々は、他の部分から、ＪＭＦに依存するメディア・プロセシング用のモジュールを完全に分離することができるような方法でシステム・アーキテクチャを設計する。しかしながら、ジャバによって開発されたデコーダは、そのサーバがクライアントのオペレーティングシステムの種類に対応する必要がないという点で長所を有している。また、それらはフレキシブル・デコーダに役立つ。
　ＣＯＲＢＡ（共通オブジェクト・リクエスト・ブローカー）［４］はサーバと、クライアント間におけるハードウェア仕様から独立したインターフェースを定義するために使用される。さらに、システムは、ＣＯＲＢＡ　ＧＩＯＰ（一般的なＯＲＢ間プロトコル）により、任意の転送プロトコルからも独立している。したがって、システムはインターネット、テレビ放送およびモバイルシステム上で使用することができる。
　システムでの手続きは次の順に実行される：
（１）クライアントシステムでのスケジューラー管理エンジンはまずコンテンツ情報を得る。それは、その情報を解析し、デコーダがクライアント側に既に存在しているか否かについて、デコーダ・コンポーネント管理エンジンを確認する。
（２）もしも、クライアントが対応するデコーダを有していない場合には、スケジューラー管理エンジンは、デコーダＵＲＩを得ることをデコーダ・コンポーネント管理エンジンに指示する。デコーダ・コンポーネント管理エンジンは、どこにデコーダが格納されているかをコンテンツサーバに要求する。
（３）情報サーバは、デコーダ情報を使用して、要求されたデコーダがどこに格納されているかを見つける。クライアントにデコーダＵＲＩを返す。
（４）スケジューラー管理エンジンは、デコーダ・サーバからいつデコーダをダウンロードし始めるかを決定し、デコーダ・コンポーネント管理エンジンに指示を行う。デコーダのダウンロードは、狭いネットワーク帯域幅の下でのメディア再生を断続的に中断することになるため、指示を与えるタイミングは非常に重要である。
　
このシステムにおける各部分の役割は以下のとおりである：
・コアエンジン
この部分は、メディアの再生、トリックモードなどのインプリメンテーションを提供する。複数のデコーダは、この部分で実際にインストールされる。
・デコーダ・コンポーネント管理エンジン
この部分は、クライアントシステム上の複数のデコーダの管理、必要となるデコーダの問い合わせ、複数のデコーダのダウンロード、保存された複数のデコーダの削除をする。
・スケジュール管理エンジン 
この部分は、メディア再生、複数のデコーダダウンロードや削除の開始時間を管理する。適時、実際の上記機能を提供する各部分に指示を与える。
・ユーザ・インターフェース 
この部分は、ユーザの入力に対するインターフェースである。
・ファイル入出力
この部分は、各プロトコルを用途に応じて選択する。
１）ＣＯＲＢＡ，コンテンツ情報の送受信を行う　２）ＨＴＴＰ／ＦＴＰ，複数のデコーダのバイナリデータをダウンロードする　３）ＲＴＰ／ＭＰＥＧ２−ＴＳ，受信メディアデータ
　
このシステムにおける各インタフェースは以下のとおりである：
インターフェース１：複数のデコーダに関する情報の交換
インターフェース２：コンテンツに関する情報の交換
インターフェース３：複数のデコーダのバイナリデータのダウンロード
インターフェース４：コンテンツのメディアデータのダウンロード
インターフェース５：クライアントのスケジューラー中で使用されるＥＰＧ（電子番組ガイド）データのダウンロード
インターフェース６：コアエンジンへの複数のデコーダモジュールの提供
インターフェース７：メモリロードの状況に関する情報の提供、デコーダのメモリロードの開始時間の表示
インターフェース８：デコーダが追加されたか削除されたかのユーザに対する表示
インターフェース９：複数のデコーダの存在の確認、クライアントシステム上でのデコーダのダウンロードや削除の開始時間の表示、コンテンツに対する情報の提供
インターフェース１０：ユーザによる入力情報の受け入れ
インターフェース１１：再生可能なコンテンツの情報の表示、ユーザによるコンテンツの選択）
　
　ｄ　「III. FLEXIBLE DECODER
A. Features
　Flexible decoder enables the architecture that is not treated as the monolithic program but that is as the aggregation of the modules that provide functions. Flexible decoder was once considered in the standardization work in MPEG-4 Systems [5]. MPEG-4 was designed to establish a flexible and extensible architecture that provides some functions such as users' content-based manipulation as well as the efficient compression. Although flexible decoder architecture is not included in the standard of MPEG-4 Systems, it enables that clients construct decoders by downloading only necessary modules when a new type media content arrives. It reduces network bandwidth and clients' / servers' resources for downloading decoders. Therefore, it is efficient to apply flexible decoder in decoder-download system.
　
B. Approach for Flexible decoder
　Previous work [6] shows a method for Flexible decoder. In this work, users can change the image processing algorithms, such as DCT and Wavelet, by developing decoders based on the [6], while decoding process is still in progress. Separation of decoder's functions is achieved by three components model. Three components model means that a decoder is separated into 1) bitstream parsing block, 2) data restorer block and 3) image reconstructor block shown in Fig5. Bitsream parsing block provides parsing bitstream in accordance with the one's syntax. Image reconstructor block provides each actual image decoding algorithm. Data restorer block has a key role for the separation between bistream parsing block and image reconstructor block. Data restorer block provides data alignment for image reconstructor block. It can be viewed as a conversion process between them. Consequently, the existence of data restorer block ensures that the modification to one side will not influence the other side.（この摘記事項中の“reconstrutor”は、Fig.5の説明や技術常識等からみて、“reconstru
c
e
　This decoder architecture can be regarded very useful for Flexible decoder. However, it becomes more difficult to develop them in accordance with the architecture compared with the conventional way, which means developing decoders as a monolithic program. 
　
C. Detach image processing from bitstream parsing
　In this proposal, the modules for bitstream parsing are entirely detached from the ones for image decoding. This enables decoders to use various modules for the same image decoding algorithms. For example, it is possible to select an IDCT module suitable for clients' hardware specification (MMX, 3DNow!, DSP, ASIC and so forth), to share same bitstream parsing. Decoder-downloadable system can be used for the various multimedia system such as the search engine [7] as well as the media processing. This flexibility can be realized simply by replacing the modules for image decoding algorithms with the ones for the other processes. Client-independent decoder software such as JAVA is exploited to make the separation more flexible.」（１６４１頁左欄１５行〜右欄３７行）
　
（訳文　ＩＩＩ．フレキシブル・デコーダ
Ａ．特徴
　フレキシブル・デコーダは、単一体のプログラムとしてではなく、機能を提供するモジュールの集合体として扱われるアーキテクチャを可能にする。フレキシブル・デコーダは、過去に、ＭＰＥＧ−４システム［５］の標準化作業において検討された。ＭＰＥＧ−４は、効率的な圧縮と同様に、ユーザのコンテンツベースの操作の複数の機能を提供する、柔軟で拡張性のあるアーキテクチャを確立することを目指した。フレキシブル・デコーダ・アーキテクチャはＭＰＥＧ−４システムの標準には含まれていないが、新たなタイプのメディアコンテンツが現れたときには、必要なモジュールだけをダウンロードすることにより、クライアントがデコーダを構築することを可能にする。それは、デコーダをダウンロードするためのネットワーク帯域幅と、クライアントやサーバのリソースを減らす。したがって、デコーダ・ダウンロードシステムに、フレキシブル・デコーダを適用することは効率が良い。　
　
Ｂ．フレキシブル・デコーダのためのアプローチ
従前の研究［６］は、フレキシブルなデコーダのための方法を示す。この研究では、ユーザは、デコーディング・プロセスがまだ進行中である間に、［６］に基づいたデコーダの開発により、ＤＣＴやウェーブレットのような画像処理アルゴリズムを変更することが可能である。デコーダの機能分割は３つのコンポーネントモデルによって達成される。３つのコンポーネントモデルとは、図５のように、デコーダが１）ビットストリーム解析ブロック、２）データ復元ブロック、３）イメージ再現ブロック、へと分割されることを意味する。ビットストリーム解析ブロックは、その構文に従って解析ビットストリームを提供する。イメージ再現ブロックは、それぞれの実画像復号アルゴリズムを提供する。データ復元ブロックには、ビットストリーム解析ブロックと、イメージ再現ブロックの間を分離するという重要な役割がある。データ復元ブロックはイメージ再現ブロックのためにデータ・アラインメントを提供する。それは、それらの間の変換過程として見ることができる。従って、データ復元ブロックの存在は、一方の側における変更が他方の側に影響を及ぼさないことを保証する。
　このデコーダ・アーキテクチャは、フレキシブル・デコーダにとって非常に役にたつものと評価することができる。しかしながら、単一体のプログラムとしてデコーダを開発するという従来の方法と比較すると、このアーキテクチャに従ってそれらを開発することは、より困難になる。
　
Ｃ．ビットストリーム解析からのイメージ処理の分離
　この提案では、ビットストリーム解析用のモジュールは、画像復号用のモジュールから完全に分離される。これにより、デコーダが様々なモジュールを同じ画像復号アルゴリズムに使用することを可能にする。例えば、同じビットストリーム解析を共有するために、クライアントのハードウェア仕様（ＭＭＸ、３ＤＮｏｗ！、ＤＳＰ、ＡＳＩＣなど）に適しているＩＤＣＴモジュールを選択することができる。デコーダ・ダウンローダブル・システムは、メディアプロセッシングと同様に、サーチエンジン［７］のような様々なマルチメディア・システムに使用することができる。この柔軟性は、画像復号アルゴリズム用のモジュールを他のプロセス用のモジュールに取り替えることだけで実現することができる。ＪＡＶＡのようなクライアント−独立なデコーダ・ソフトウェアは、分離をより柔軟にするために活用される。）
　
（イ）引用例１の上記摘記事項ｃおよび図面に記載された発明
　
　ａ　クライアント
　
　上記摘記事項ｃの１６３９頁左欄２４〜２９行における“The proposed system architecture is shown in Fig.2. A client is composed of five parts, which are Core engine, Schedule management engine, Decoder component management engine, File I/O, User Interface.”（提案システム・アーキテクチャは図２に示される。クライアントは、「コアエンジン」、「スケジュール管理エンジン」、「デコーダ・コンポーネント管理エンジン」、「ファイル入出力」、「ユーザ・インターフェース」の５つの部分から構成される。）の記載によれば、引用例１には、コアエンジンと、デコーダ・コンポーネント管理エンジンとを有するクライアントが記載されている。
　
　ｂ　デコーダ・コンポーネント管理エンジン
　
　上記摘記事項ｃの１６３９頁左欄３０〜３４行における“At a server-side, there are ・・・ Decoder server storing binary codes of the decoders ・・・.”（サーバ側には、・・・（略）・・・デコーダのバイナリコードを格納する「デコーダサーバ」・・・を有する）の記載や、図２及び同摘記事項ｃの１６４０頁左欄２１〜２４行、３１〜３５行、３９行に開示される“Decoder server”（デコーダサーバ）から“File I/O”（ファイル入出力）の“HTTP/FTP”を経由し、“interface 3”（インターフェース３）を介して、“binary data of decoders”（デコーダのバイナリデータ）をダウンロードする“Decoder component management engine”（デコーダ・コンポーネント管理エンジン）の構成を参酌すると、引用例１には、デコーダサーバから、デコーダのバイナリデータをダウンロードするデコーダ・コンポーネント管理エンジンが記載されている。
　
　また、上記摘記事項ｃの１６４０頁左欄２１〜２４行における“・Decoder component management engine　This part manages decoders in the client's system, queries about what decoder is needed, downloads decoders, and deletes decoders in the stock.”（・デコーダ・コンポーネント管理エンジン　この部分は、クライアントシステム上の複数のデコーダの管理、必要となるデコーダの問い合わせ、複数のデコーダのダウンロード、保存された複数のデコーダの削除をする。）の記載によれば、引用例１には、ダウンロードされた複数のデコーダの管理をするデコーダ・コンポーネント管理エンジンが記載されている。
　
　ｃ　コアエンジン
　
　上記摘記事項ｃの１６４０頁左欄１７〜２０行における“・Core engine　This part provides the implementation of media play, trick mode and so forth. The decoders are actually installed in this part.”（・コアエンジン　この部分は、メディアの再生、トリックモードなどのインプリメンテーションを提供する。複数のデコーダは、この部分で実際にインストールされる。）の記載によれば、引用例１には、デコーダは、コアエンジンでインストールされ、コアエンジンは、メディアの再生を行うことが記載されている。
　
　ｄ　コンテンツ情報
　
　上記摘記事項ｃの１６３９頁左欄３０〜３６行における“At a server-side, there are ・・・ Information server storing information describing a profile for each content (here after called content information). To detect the corresponding content information easily by information server, this information has a hierarchical structure. Content information is shown in Fig.3. ”（サーバ側には、・・・各コンテンツのためのプロファイルを記述した情報（以下、コンテンツ情報という。）を格納する「情報サーバ」を有する。情報サーバによって対応するコンテンツ情報を容易に検知するために、この情報には階層構造を有する。コンテンツ情報は図３に示される。）との記載や、図３において“content information”（コンテンツ情報）には、“1) content name  2) author  3) content ID  4) optimum decoder etc”（１）コンテンツ名　２）作者　３）コンテンツＩＤ　４）対応する最適なデコーダ　等）の情報が含まれる旨の記載を参酌すると、引用例１には、各コンテンツのためのプロファイルを記述したコンテンツ情報には、対応する最適なデコーダ情報を含むものであることが記載されている。
　
　ｅ　デコーダのダウンロード
　
　上記摘記事項ｃの１６３９頁右欄１２行〜１６４０頁左欄１２行における“(1) The scheduler management engine in the client system starts to get the content information. It parses the information and confirms the decoder component management engine whether the decoder has already existed in the client's side or not. (2) If a client does not have the corresponding decoder, the scheduler management engine instructs the decoder component management engine to get the decoder URI. Decoder component management engine requires content server where the decoder is stored. (3) Information server starts to find where the requested decoder is stored using decoder information. It returns decoder URI to the client. (4) The scheduler management engine decides when to start downloading the decoder from decoder server and instructs the decoder component management engine.”（（１）クライアントシステムでのスケジューラー管理エンジンはまずコンテンツ情報を得る。それは、その情報を解析し、デコーダがクライアント側に既に存在しているか否かについて、デコーダ・コンポーネント管理エンジンを確認する。（２）もしも、クライアントが対応するデコーダを有していない場合には、スケジューラー管理エンジンは、デコーダＵＲＩを得ることをデコーダ・コンポーネント管理エンジンに指示する。デコーダ・コンポーネント管理エンジンは、どこにデコーダが格納されているかをコンテンツサーバに要求する。（３）情報サーバは、デコーダ情報を使用して、要求されたデコーダがどこに格納されているかを見つける。クライアントにデコーダＵＲＩを返す。（４）スケジューラー管理エンジンは、デコーダ・サーバからいつデコーダをダウンロードし始めるかを決定し、デコーダ・コンポーネント管理エンジンに指示を行う。）の記載、及び「デコーダコンポーネント管理エンジン」が、デコーダをダウンロードする際に、上記摘記事項ｃの１６４０頁左欄２１〜２４行において“queries about what decoder is needed”（必要となるデコーダの問い合わせ）が行われることが開示されることからみて、引用例１には、デコーダがクライアント側に既に存在しているか否かについて、デコーダ・コンポーネント管理エンジンに確認し、対応するデコーダを有していない場合には、デコーダ情報を使用して、情報サーバから得られたデコーダＵＲＩにより、必要となるデコーダの問い合わせを行い、デコーダ・サーバからデコーダをダウンロードするデコーダ・コンポーネント管理エンジンが記載されている。
　
　したがって、上記ａ〜ｅによれば、上記引用例１の上記摘記事項ｃおよび図面（図２、図３）に記載された「デコーダ・ダウンローダブル・システム」には、以下の発明（以下、「引用発明１」という。）が開示されている。
　
　（引用発明１）
　「コアエンジンと、
　デコーダサーバからデコーダのバイナリデータをダウンロードするデコーダ・コンポーネント管理エンジンと、
　ダウンロードされた複数のデコーダの管理をするデコーダ・コンポーネント管理エンジンと、
　デコーダは、コアエンジンでインストールされ、
　コアエンジンは、メディアの再生を行い、
　各コンテンツのためのプロファイルを記述したコンテンツ情報には、対応する最適なデコーダ情報を含み、
　デコーダがクライアント側に既に存在しているか否かについて、デコーダ・コンポーネント管理エンジンに確認し、対応するデコーダを有していない場合には、デコーダ情報を使用して、情報サーバから得られたデコーダＵＲＩにより、必要となるデコーダの問い合わせを行い、デコーダ・サーバからデコーダをダウンロードするデコーダ・コンポーネント管理エンジンを有するクライアント。」
　
ウ　対比
（ア）補正後の発明と引用発明１とを対比する。
　
　ａ　「デジタルシグナルプロセッサ（ＤＳＰ）処理部」について
　
　補正後の発明では、ＤＳＰ処理部は、ＤＳＰコードを実行させ、所定マルチメディアコンテンツを実行させるものであるところ、
　引用発明１の「コアエンジン」も、実行コードであるデコーダが実際にインストールされ、メディアの再生等が行われる処理部である。
　
　すると、補正後の発明の「デジタルシグナルプロセッサ（ＤＳＰ）処理部」と、引用発明１の「コアエンジン」は、 処理部 の機能を有している点で一致する。
　
　しかしながら、一致点である 処理部 に関し、補正後の発明は、「デジタルシグナルプロセッサ（ＤＳＰ）」により処理が行われるものであるのに対し、引用発明１では、デジタルシグナルプロセッサ（ＤＳＰ）により処理が行われるものとはされていない点で相違する。
　
　ｂ　「コーデックサーバから第１のソフトウェアモジュールをダウンロードする手段」について
　
　補正後の発明では、「コーデックサーバから第１のソフトウェアモジュールをダウンロードする手段」を有するものであるところ、
　引用発明１では、「デコーダコンポーネント管理エンジン」は、「デコーダサーバからデコーダのバイナリデータをダウンロードする」手段のことであるのだから、補正後の発明の「ダウンロードする手段」と、実質的に同じ機能を有する手段である。
　
　（ａ）　「コーデック」について
　補正後の発明では、「コーデック」は、マルチメディア再生装置でマルチメディアコンテンツを再生させるためのソフトウェアのことであるところ、
　引用発明１の「デコーダ」は、クライアント上でメディアを再生するためのソフトウェアのことであるから、補正後の発明の「コーデック」と、引用発明１の「デコーダ」は、実質的に同じ機能を有するソフトウェアである。
　
　（ｂ）　「ソフトウェアモジュール」について
　補正後の発明では、「ソフトウェアモジュール」は、コーデックのＤＳＰコードを構成するためのモジュールのことであって、一般にＤＳＰコードは、ビットの並びから構成されるバイナリデータであると解されるところ、
　引用発明１の「デコーダ」は、上記（ａ）のとおり「コーデック」と実質的に同じ機能を有するソフトウェアであり、コンテンツを再生するためのバイナリデータであるから、補正後の発明の「ソフトウェアモジュール」は、引用発明１の「デコーダ」と、コーデックのバイナリデータである点で一致する。
　
　したがって、補正後の発明の「コーデックサーバから第１のソフトウェアモジュールをダウンロードする手段」は、引用発明１の「デコーダサーバからデコーダのバイナリデータをダウンロードするデコーダ・コンポーネント管理エンジン」と、 コーデックサーバからコーデックのバイナリデータをダウンロードする手段 である点で一致する。
　
　しかしながら、
　一致点である コーデックのバイナリデータ に関し、補正後の発明では、「第１のソフトウェアモジュール」がダウンロードされるのに対し、引用発明１では、「デコーダのバイナリデータ」がダウンロードされる点、
　また、補正後の発明では、複数の「ソフトウェアモジュール」を組合せてコーデックのＤＳＰコードが生成されるものであるのに対し、引用発明１では、複数のソフトウェアモジュールを組合せてコーデックのコードを生成することとはされていない点
　で、それぞれ相違する。
　
　ｃ　「ダウンロードされた第１のソフトウェアモジュールと、少なくとも第２のソフトウェアモジュールとを記憶する記憶部」について
　
　補正後の発明の「ダウンロードされた第１のソフトウェアモジュールと、少なくとも第２のソフトウェアモジュールとを記憶する記憶部」は、ダウンロードされた複数のソフトウェアモジュールを貯蔵しておくための記憶部のことであり、第１、第２というのは、複数のソフトウェアモジュールであるということを表現しているものと認められるところ、
　引用発明１の「デコーダコンポーネント管理エンジン」は、引用例１の摘記事項ｃの１６４０頁左欄２１〜２４行に「・デコーダ・コンポーネント管理エンジン　この部分は、クライアントシステム上の複数のデコーダの管理、必要となるデコーダの問い合わせ、複数のデコーダのダウンロード、保存された複数のデコーダの削除をする。」と記載されていることからも明らかなように、デコーダ・コンポーネント管理エンジンにより、クライアント側にダウンロードされたデコーダが保存され、管理されているものである。そして、引用例１の摘記事項ｃの１６３９頁右欄１２行〜１６４０頁左欄１行に「クライアントシステムでのスケジューラー管理エンジンはまずコンテンツ情報を得る。それは、その情報を解析し、デコーダがクライアント側に既に存在しているか否かについて、デコーダ・コンポーネント管理エンジンを確認する。」と記載されることから、デコーダがクライアント側に既に存在しているか否かについて、必要となるデコーダの問い合わせがあると、クライアント側にデコーダが記憶されているかどうか、デコーダの存在を確認するものであるということができる。
　すると、デコーダコンポーネント管理エンジンは、複数のデコーダを記憶する記憶部の機能を有するものであるということができる。
　なお、補正後の発明の「ソフトウェアモジュール」は、上記ｂ（ｂ）のとおり、引用発明１の「デコーダ」と、コーデックのバイナリデータである点で一致している。
　
　したがって、補正後の発明の「ダウンロードされた第１のソフトウェアモジュールと、少なくとも第２のソフトウェアモジュールとを記憶する記憶部」は、引用発明１の「ダウンロードされた複数のデコーダの管理をするデコーダ・コンポーネント管理エンジン」と、 ダウンロードされた複数のコーデックのバイナリデータを記憶する記憶部 を有する点で一致する。
　
　しかしながら、補正後の発明では、「第１のソフトウェアモジュール」を記憶するのに対し、引用発明１では、「デコーダ」を記憶する点で相違する。
  
　ｄ　「前記記憶された第１と第２のソフトウェアモジュールを組合せてＤＳＰコードを生成し、前記ＤＳＰ処理部にロードするＤＳＰコード生成部」について
　
　補正後の発明の「ＤＳＰコード生成部」は、所定のマルチメディアコンテンツを実行させるためのＤＳＰコードを生成するもので、記憶部に記憶された第１と第２のソフトウェアモジュールを組合せて、該当するＤＳＰコードを生成し、生成されたＤＳＰコードをＤＳＰ処理部にロードするものであるところ、
　引用発明１でも、「デコーダは、コアエンジンでインストール」されるものであるから、デコーダをコアエンジンにインストールする手段を有しているものであるということができる。
　
　（ａ）　「ＤＳＰコード」について
　補正後の発明の「ＤＳＰコード」は、ＤＳＰ処理部において実行される実行コードのことであると解されるところ、
　引用発明１の「デコーダ」も、コアエンジンにおいて実行される実行コードのことであるから、両者は、実行コードである点で一致する。
　
　ここで、引用発明１の「デコーダ」は、上記ｂ（ａ）のとおり、補正後の発明の「ソフトウェアモジュール」と、コーデックのバイナリデータである点で一致し、上記（ａ）のとおり、補正後の発明の「ＤＳＰコード」と、実行コードである点で一致している。
　また、引用発明１の「コアエンジン」は、上記ａのとおり、補正後の発明の「デジタルシグナルプロセッサ（ＤＳＰ）処理部」と、処理部の機能を有している点で一致している。
　そして、補正後の発明の「ロード」は、生成されたＤＳＰコードを実行させるために、ＤＳＰ処理部に読み込ませることであると解されるところ、引用発明１の「インストール」も、デコーダを実行コードとして、コアエンジンの処理を行う部分に読み込ませることであるから、補正後の発明の「ロード」と実質的に同じ動作を意味するものである。
　
　したがって、補正後の発明の「前記記憶された第１と第２のソフトウェアモジュールを組合せてＤＳＰコードを生成し、前記ＤＳＰ処理部にロードするＤＳＰコード生成部」は、引用発明１の「デコーダは、コアエンジンでインストールされ」る点と、 コーデックのバイナリデータを実行コードとして処理部にロードする手段 を有する点で一致する。
　
　しかしながら、
　補正後の発明では、「記憶された第１と第２のソフトウェアモジュールを組合せてＤＳＰコードを生成」するものであるのに対し、引用発明１では、複数のソフトウェアモジュールを組合せてデコーダのコードを生成することとはされていない点、
　補正後の発明では、「デジタルシグナルプロセッサ（ＤＳＰ）」による実行コードであるのに対し、引用発明１では、デジタルシグナルプロセッサ（ＤＳＰ）による実行コードであるとはされていない点
　で、それぞれ相違する。
　
　ｅ　「前記ＤＳＰ処理部は前記ロードされたＤＳＰコードをデコーディングして、前記第１のソフトウェアモジュールに対応するマルチメディアコンテンツを処理し」について
　
　補正後の発明の「前記ＤＳＰ処理部は前記ロードされたＤＳＰコードをデコーディングして、前記第１のソフトウェアモジュールに対応するマルチメディアコンテンツを処理し」では、まず、マルチメディアコンテンツを再生するのに必要なＤＳＰコードが、対応するソフトウェアモジュールを組合せることで生成され、ＤＳＰ処理部は、生成されたＤＳＰコードをロードして、ロードされたＤＳＰコードをデコーディングして、ＤＳＰコードを実行することで、マルチメディアコンテンツを再生する処理が行われるものであるところ、
　引用発明１では、補正後の発明のように、コアエンジンにおいて、デコーダをデコーディングするものとはされていないものの、引用発明１の「コアエンジンは、メディアの再生を行い」では、コアエンジンにインストールされた実行コードであるデコーダを実行することにより、メディアの再生が行われるものであって、さらに「各コンテンツのためのプロファイルを記述したコンテンツ情報には、対応する最適なデコーダ情報を含」むものであって、デコーダとコンテンツが対応付けられているものであるから、引用発明１では、コアエンジンは、インストールされた実行コードであるデコーダを実行することにより、デコーダに対応するメディアを処理するものであるということができる。
　
（ａ）「マルチメディアコンテンツ」について
　補正後の発明の「マルチメディアコンテンツ」は、対応するコーデックにより、マルチメディア再生装置で再生されるコンテンツであるところ、
　引用発明１の「メディア」も、対応するデコーダにより、クライアント上で再生されるコンテンツのことであるから、引用発明１の「メディア」と、補正後の発明の「マルチメディアコンテンツ」は、実質的に同じものである。
　
　ここで、引用発明１の「コアエンジン」は、上記ａのとおり、補正後の発明の「デジタルシグナルプロセッサ（ＤＳＰ）処理部」と、処理部の機能を有している点で一致しており、引用発明１の「メディア」は、上記（ａ）のとおり、補正後の発明の「マルチメディアコンテンツ」と実質的に同じものであって、引用発明１の「デコーダ」は、上記ｂ（ａ）のとおり、補正後の発明の「ソフトウェアモジュール」と、コーデックのバイナリデータである点で一致するものである。
　
　したがって、補正後の発明の「前記ＤＳＰ処理部は前記ロードされたＤＳＰコードをデコーディングして、前記第１のソフトウェアモジュールに対応するマルチメディアコンテンツを処理」する点は、引用発明１の「コアエンジンは、メディアの再生を行」う点と、 処理部は、ロードされた実行コードによりコーデックのバイナリデータに対応するマルチメディアコンテンツを処理する 点で一致する。
　
　しかしながら、補正後の発明では、「デジタルシグナルプロセッサ（ＤＳＰ）」により処理が行われものであるのに対し、引用発明１では、デジタルシグナルプロセッサ（ＤＳＰ）により処理が行われるものとはされていない点、
　また、補正後の発明では、「ソフトウェアモジュール」に対応するマルチメディアコンテンツを処理するものであるのに対し、引用発明１では、「デコーダ」に対応するメディアが再生されるものである点、
　そして、補正後の発明では、ＤＳＰ処理部は、ロードされたＤＳＰコードを「デコーディング」して処理を実行するのに対し、引用発明１では、コアエンジンが、読み込まれた実行コードをデコーディングするものとはされていない点
　で、それぞれ相違する。
　
　ｆ　「前記マルチメディアコンテンツは前記コーデックサーバの位置情報と前記第１のソフトウェアモジュールの識別情報とを含み」について
　
　補正後の発明では、「マルチメディアコンテンツ」は「コーデックサーバの位置情報」と「第１のソフトウェアモジュールの識別情報」とを含むものであるところ、
　引用発明１では、「コンテンツのためのプロファイルを記述したコンテンツ情報」には、「対応する最適なデコーダ情報」を含むものであるのだから、このコンテンツ情報は、「コンテンツ」に関する「デコーダ情報」を含んでいるということができる。
　同様に、引用発明１では、「対応するデコーダを有していない場合には、デコーダ情報を使用して、情報サーバから得られたデコーダＵＲＩにより、必要となるデコーダの問い合わせを行」うものであるのだから、情報サーバから、該コンテンツに関する「デコーダＵＲＩ」を得ているものである。
　また、補正後の発明では、「コーデックサーバの位置情報」と「第１のソフトウェアモジュールの識別情報」が用いられるものであるところ、引用発明１でも、「デコーダＵＲＩ」と「対応する最適なデコーダ情報」が用いられるものでもある。
　
　そして、引用発明１の「デコーダ」は、上記ｂ（ａ）のとおり、補正後の発明の「ソフトウェアモジュール」と、コーデックのバイナリデータである点で一致しており、引用発明１の「対応する最適なデコーダ情報」は、コーデックのバイナリデータの識別情報のことであるといい得るものであり、「デコーダＵＲＩ」は、デコーダサーバの位置情報であるから、上記ｂを踏まえると、補正後の発明の「コーデックサーバの位置情報」と実質的に同じものであるということができ、引用発明１の「コンテンツ」は、補正後の発明の「マルチメディアコンテンツ」と実質的に同じものである。
　
　したがって、補正後の発明の「前記マルチメディアコンテンツは前記コーデックサーバの位置情報と前記第１のソフトウェアモジュールの識別情報とを含」む点は、引用発明１の「各コンテンツのためのプロファイルを記述したコンテンツ情報には、対応する最適なデコーダ情報を含」み、「対応するデコーダを有していない場合には、デコーダ情報を使用して、情報サーバから得られたデコーダＵＲＩにより、必要となるデコーダの問い合わせを行」う点と、 マルチメディアコンテンツに関するコーデックサーバの位置情報とコーデックのバイナリデータの識別情報とが用いられる 点で一致する。
　
　しかしながら、
　補正後の発明では、「マルチメディアコンテンツ」の中に「コーデックサーバの位置情報」と「第１のソフトウェアモジュールの識別情報」が含まれるのに対し、引用発明１では、「コンテンツ」の中に「デコーダＵＲＩ」と「デコーダ情報」が含まれるものとはされていない点、
　また、補正後の発明では、マルチメディアコンテンツに関する情報が、「第１のソフトウェアモジュールの識別情報」であるのに対し、引用発明１では、コンテンツ情報が、「デコーダ情報」である点
　で、それぞれ相違する。
　
　ｇ　「前記マルチメディアコンテンツに対応する前記第１のソフトウェアモジュールが前記記憶部に記憶されていない場合」について
　
　補正後の発明の「前記マルチメディアコンテンツに対応する前記第１のソフトウェアモジュールが前記記憶部に記憶されていない場合」とは、マルチメディアコンテンツの再生に必要なＤＳＰコードを生成するためのソフトウェアモジュールが記憶部に記憶されていない場合であるところ、
　引用発明１の「デコーダコンポーネント管理エンジン」は、上記ｃのとおり、記憶部の機能を有するものであって、引用発明１の「デコーダ」は、上記ｅ及びｆで検討したとおり、コンテンツに対応するものであるから、引用発明１の「デコーダがクライアント側に既に存在しているか否かについて、デコーダ・コンポーネント管理エンジンに確認し、対応するデコーダを有していない場合」とは、コンテンツに対応するデコーダが当該記憶部に記憶されていない場合であるということができる。
　ここで、引用発明１の「コンテンツ」は、上記ｆのとおり、補正後の発明の「マルチメディアコンテンツ」と実質的に同じものであり、引用発明１の「デコーダ」は、上記ｂ（ｂ）のとおり、補正後の発明の「ソフトウェアモジュール」と、コーデックのバイナリデータである点で一致している。
　
　したがって、補正後の発明の「マルチメディアコンテンツに対応する第１のソフトウェアモジュールが記憶部に記憶されていない場合」と、引用発明１の「デコーダがクライアント側に既に存在しているか否かについて、デコーダ・コンポーネント管理エンジンに確認し、対応するデコーダを有していない場合」は、 マルチメディアコンテンツに対応するコーデックのバイナリデータが記憶部に記憶されていない場合 である点で一致する。
　
　しかしながら、補正後の発明では、「ソフトウェアモジュール」が、マルチメディアコンテンツに対応するものであるのに対し、引用発明１では、「デコーダ」が、コンテンツに対応するものである点で相違する。
　
　ｈ　「前記コーデックサーバの位置情報と前記第１のソフトウェアモジュールの識別情報とに基づき、外部ネットワークに位置した前記コーデックサーバに前記第１のソフトウェアモジュールのダウンロードを要求するメッセージを生成及び伝送する制御部」について
　
　補正後の発明の「制御部」は、「コーデックサーバの位置情報と第１のソフトウェアモジュールの識別情報とに基づき、外部ネットワークに位置したコーデックサーバに第１のソフトウェアモジュールのダウンロードを要求するメッセージを生成及び伝送する」ものであるところ、
　引用発明１の「デコーダ・コンポーネント管理エンジン」は、「デコーダ情報を使用して、情報サーバから得られたデコーダＵＲＩにより、」必要となるデコーダの問い合わせを行い、「デコーダ・サーバからデコーダをダウンロードする」ものであるのだから、「デコーダ情報」と「デコーダＵＲＩ」とに基づき、「デコーダ・サーバからデコーダをダウンロードする」ものであり、この「デコーダＵＲＩ」は、デコーダサーバの位置情報のことであるということができる。
　さらに、引用発明１で、「デコーダをダウンロードする」際には、ダウンロードを要求するための「必要となるデコーダの問い合わせ」を行うものであるのだから、補正後の発明の「ダウンロードを要求するメッセージを生成及び伝送する制御部」の機能を実質的に有するものであるということができる。
　また、引用発明１の「デコーダサーバ」は、引用例１の図２に“Decoder server”として示されるように、クライアント側から見て、外部ネットワークに位置しているものである。
　ここで、引用発明１の「デコーダ情報」は、上記ｆで検討したとおり、コーデックのバイナリデータの識別情報のことであり、引用発明１の「デコーダサーバ」は、上記ｂのとおり、補正後の発明の「コーデックサーバ」の一種であり、引用発明１の「デコーダ」は、上記ｂ（ａ）のとおり、補正後の発明の「ソフトウェアモジュール」と、コーデックのバイナリデータである点で一致している。
　
　したがって、補正後の発明の「コーデックサーバの位置情報と第１のソフトウェアモジュールの識別情報とに基づき、外部ネットワークに位置したコーデックサーバに第１のソフトウェアモジュールのダウンロードを要求するメッセージを生成及び伝送する制御部」は、引用発明１の「デコーダ情報を使用して、情報サーバから得られたデコーダＵＲＩにより、必要となるデコーダの問い合わせを行い、デコーダ・サーバからデコーダをダウンロードするデコーダ・コンポーネント管理エンジン」と、 コーデックサーバの位置情報とコーデックのバイナリデータの識別情報とに基づき、外部ネットワークに位置したコーデックサーバにコーデックのバイナリデータのダウンロードを要求するメッセージを生成及び伝送する制御部 である点で一致する。
　
　しかしながら、補正後の発明では、「マルチメディアコンテンツ」の中に「コーデックサーバの位置情報」が含まれるのに対し、引用発明１では、「コンテンツ」の中に「デコーダＵＲＩ」が含まれるものとはされていない点で相違する。
　
　ｉ　「装置」について
　
　補正後の発明の「装置」は、デジタルシグナルプロセッサ（ＤＳＰ）処理部と、ソフトウェアモジュールをダウンロードする手段と、ダウンロードしたソフトウェアモジュールを記憶する記憶部と、ソフトウェアモジュールの組合せてＤＳＰコードを生成し、ＤＳＰ処理部にロードするＤＳＰコード生成部と、ソフトウェアモジュールのダウンロードを要求するメッセージを生成及び伝送する制御部を有し、マルチメディアコンテンツを再生する装置であるところ、
　引用発明１の「クライアント」も、コアエンジンと、デコーダ・コンポーネント管理エンジンを有し、コンテンツを再生させる装置である。
　ここで、引用発明１の「コアエンジン」は、上記ａで検討したとおり、補正後の発明の「デジタルシグナルプロセッサ（ＤＳＰ）処理部」と、「処理部」の機能を有する点で一致し、上記ｄ（ａ）で検討したとおり、補正後の発明の「ＤＳＰコード生成部」と、「ロードする手段」をする点で一致しており、
　引用発明１の「デコーダコンポーネント管理エンジン」は、上記ｂ（ｂ）、ｃ、ｈで検討したとおり、補正後の発明の「ダウンロードする手段」、「記憶部」、「制御部」の機能をそれぞれ有している。
　
　したがって、補正後の発明の「装置」は、引用発明１の「クライアント」と、同様な機能を持つ装置として一致している。
　
　ｊ　相違点の整理
　
　上記ａ、ｄ、ｅにおける相違点によれば、
　補正後の発明では、「デジタルシグナルプロセッサ（ＤＳＰ）」により処理が行われるものであるのに対し、引用発明１では、デジタルシグナルプロセッサ（ＤＳＰ）により処理が行われるものとはされていない点、
　また、補正後の発明では、「デジタルシグナルプロセッサ（ＤＳＰ）」による実行コードであるのに対し、引用発明１では、デジタルシグナルプロセッサ（ＤＳＰ）による実行コードであるとはされていない点
　で、それぞれ相違しているものであるが、該「デジタルシグナルプロセッサ（ＤＳＰ）」による実行コードであるか否かに係る相違点は、「デジタルシグナルプロセッサ（ＤＳＰ）」により処理が行われるものであるか否かに係る相違点に起因するものであるから、これらの相違点は、以下の相違点に集約されるものであると認められる。
　
　補正後の発明では、「デジタルシグナルプロセッサ（ＤＳＰ）」により処理が行われるものであるのに対し、引用発明１では、デジタルシグナルプロセッサ（ＤＳＰ）により処理が行われるものとはされていない点
　
（イ）よって、上記ａ〜ｊから、補正後の発明と引用発明１は、以下の点で一致し、また相違している。
　
　（一致点）
　「処理部と、
　コーデックサーバからコーデックのバイナリデータをダウンロードする手段と、
　ダウンロードされた複数のコーデックのバイナリデータを記憶する記憶部と、
　前記記憶されたコーデックのバイナリデータを実行コードとして処理部にロードする手段と、を有し、
　前記処理部は、前記ロードされた実行コードにより前記コーデックのバイナリデータに対応するマルチメディアコンテンツを処理し、
　前記マルチメディアコンテンツに関する前記コーデックサーバの位置情報と前記コーデックのバイナリデータの識別情報とが用いられ、
　前記マルチメディアコンテンツに対応する前記コーデックのバイナリデータが前記記憶部に記憶されていない場合、前記コーデックサーバの位置情報と前記コーデックのバイナリデータの識別情報とに基づき、外部ネットワークに位置した前記コーデックサーバに前記コーデックのバイナリデータのダウンロードを要求するメッセージを生成及び伝送する制御部を有する装置。」
　
　（相違点１）
　補正後の発明では、「デジタルシグナルプロセッサ（ＤＳＰ）」により処理が行われるものであるのに対し、引用発明１では、デジタルシグナルプロセッサ（ＤＳＰ）により処理が行われるものとはされていない点。
　
　（相違点２）
　補正後の発明では、「ソフトウェアモジュールの識別情報」に基づき、「ソフトウェアモジュール」をダウンロードして記憶し、記憶された複数の「ソフトウェアモジュール」を組合せてコーデックのコードを生成し、「ソフトウェアモジュール」に対応するマルチメディアコンテンツを処理するものであるのに対し、引用発明１では、「デコーダ情報」に基づき、「デコーダのバイナリデータ」をダウンロードして記憶し、「デコーダ」に対応するメディア又はコンテンツが再生されるものであり、複数のソフトウェアモジュールを組合せてデコーダのコードを生成することとはされていない点。
　
　（相違点３）
　補正後の発明では、ＤＳＰ処理部は、ロードされたＤＳＰコードを「デコーディング」して処理を実行するのに対し、引用発明１では、コアエンジンが、読み込まれた実行コードをデコーディングするものとはされていない点。
　
　（相違点４）
　補正後の発明では、「マルチメディアコンテンツ」の中に、「コーデックサーバの位置情報」と「第１のソフトウェアモジュールの識別情報」が含まれるのに対し、引用発明１では、「コンテンツ」の中に「デコーダＵＲＩ」と「デコーダ情報」が含まれるものとはされていない点。
　
エ　当審の判断
（ア）相違点１についての検討
　
　引用例１に係る摘記事項ａの１６３８頁左欄９〜１１行の記載“・・・ servers and clients in this system are independent from OSes and hardware specifications. ”（・・・このシステムでのサーバおよびクライアントは、ＯＳやハードウェアの仕様からは独立している。）、同摘記事項ｃの１６３９頁左欄４６行〜右欄２行の記載“・・・decoders developed by Java give a merit that server do not have to take care of the type of the client operating system. They are also useful for flexible decoder.”（・・・ジャバによって開発されたデコーダは、そのサーバがクライアントのオペレーティングシステムの種類に対応する必要がないという点で長所を有している。）を参酌すると、引用例１のシステムでは、クライアントのアーキテクチャがＯＳやハードウェアには依存しないものであることが開示されている。
　そして、同摘記事項ｄの１６４１行右欄２８〜３１行には、“For example, it is possible to select an IDCT module suitable for clients' hardware specification (MMX, 3DNow!, DSP, ASIC and so forth), to share same bitstream parsing.”（例えば、同じビットストリーム解析を共有するために、クライアントのハードウェア仕様（ＭＭＸ、３ＤＮｏｗ！、ＤＳＰ、ＡＳＩＣなど）に適しているＩＤＣＴモジュールを選択することができる。）と記載があり、クライアント側のハードウェア仕様がＤＳＰである場合にも適用できることが例示されている。
　したがって、引用発明１における「コアエンジン」について、上記引用例１における記載に基づいて、ＤＳＰによるハードウェアを採用することによって、補正後の発明のように、「デジタルシグナルプロセッサ（ＤＳＰ）処理部」とすることや、引用発明１における実行コードを、補正後の発明のように、「ＤＳＰコード」とすることは、当業者であれば容易に想到できることである。
　
（イ）相違点２についての検討
　
　（デコーダが複数のモジュールにより構築されるモジュールベースデコーダ）
　引用例１に係る摘記事項ａの１６３８行左欄１６〜２１行には、“However, conventional decoders are monolithic software. Thus, it is impossible to share parts of decoders. The proposed method enables a module-based decoder and sharing some modules among some decoders. Consequently, the flexible decoder can make downloading time shorter by avoidance to download redundant parts of decoders.”（しかしながら、従来のデコーダは単一体のソフトウェアである。したがって、デコーダの一部分を共有することができない。提案された方法は、モジュールベースのデコーダおよびいくつかのデコーダ中に数モジュールを共有することを可能にする。従って、フレキシブル・デコーダは、デコーダの冗長部分をダウンロードすることを回避することによって、ダウンロードする時間をより短くすることができる。）と記載され、
　同摘記事項ｂの１６３８行右欄１６〜２１行には、“Conventional decoders are developed as monolithic software. However, there are parts that decoders can share. Thus, their redundancies are eliminated by realizing module-based decoders, which are composed some modules and share them among decoders. We call these module based decoders flexible decoder.”（従来のデコーダは単一体のソフトウェアとして開発されている。しかしながら、デコーダが共有することができる部分が存在する。したがって、それらの冗長性はモジュールベースのデコーダの実現により除去される。それは複数のモジュールを構成し、デコーダの間でそれらを共有する。我々はこれらのモジュールベースのデコーダを「フレキシブル・デコーダ」と呼ぶ。）と記載され、
　この“flexible decoder”（フレキシブル・デコーダ）について、同摘記事項ｄの１６４１行左欄１７〜２７行には、“Flexible decoder enables the architecture that is not treated as the monolithic program but that is as the aggregation of the modules that provide functions. ・・・ it enables that clients construct decoders by downloading only necessary modules when a new type media content arrives.”（フレキシブル・デコーダは、単一体のプログラムとしてではなく、機能を提供するモジュールの集合体として扱われるアーキテクチャを可能にする。・・・新たなタイプのメディアコンテンツが現れたときには、必要なモジュールだけをダウンロードすることにより、クライアントがデコーダを構築することを可能にする。）と記載されている。
　以上の記載からみて、引用例１には、デコーダが複数のモジュールにより構築され、新たなメディアコンテンツに対応する、必要なモジュールだけをダウンロードすることにより、クライアントが必要となるデコーダを構築することができるモジュールベースデコーダの考え方が開示されている。
　
　（モジュールに対応するメディアコンテンツと、モジュール識別情報）
　上記で示した摘記事項ｄの１６４１行左欄１７〜２７行の「新たなタイプのメディアコンテンツが現れたときには、必要なモジュールだけをダウンロードすることにより、クライアントがデコーダを構築することを可能にする。」の記載から明らかなように、「新たなタイプのメディアコンテンツ」が現れたときには、「必要なモジュール」をダウンロードするものであるのだから、「新たなタイプのメディアコンテンツ」に対応するデコーダの「必要なモジュール」は、自明な対応関係を有するものである。
　そして、デコーダは、引用例１の図５に示されるように、複数の機能ブロックへモジュールが分けられるものであって、例えば、所定のデコーダに対して、所定の画像復号用モジュールが自明的に対応付けられるものであるから、引用発明１における該コンテンツについての「コンテンツ情報」に含まれる「デコーダ情報」を、モジュールを識別する情報とすることは、当業者であれば容易に想到できることである。
　
　（複数のデコーダモジュールを組合せてデコーダを生成する手段）
　上記で示した摘記事項ｄの１６４１行左欄１７〜２７行の「フレキシブル・デコーダは、単一体のプログラムとしてではなく、機能を提供するモジュールの集合体として扱われるアーキテクチャを可能にする。」の記載から明らかなように、デコーダは、機能を提供するモジュールの集合体として扱われるものであって、複数のデコーダモジュールが組合せられてデコーダとされるものである。
　このデコーダモジュールに関する記載として、引用例１の図２における“interface 6”（インターフェース６）の説明について、同摘記事項ｃの１６４０頁右欄１行には、Decoder component management engine”（デコーダ・コンポーネント管理エンジン）から“Core Engine”（コアエンジン）へ“decorder modules”（複数のデコーダモジュール）が提供されることが記載されている。つまり、デコーダ・コンポーネント管理エンジンから、コアエンジンへは、複数の「デコーダモジュール」が提供されているものである。
　そして、同摘記事項ｃの１６４０頁左欄１７〜２０行に「・コアエンジン　この部分は、メディアの再生、トリックモードなどのインプリメンテーションを提供する。複数のデコーダは、この部分で実際にインストールされる。」として示されるとおり、そのデコーダがコアエンジン部分にインストールされるものであるのだから、複数のデコーダモジュールを組合せてデコーダを生成するコード生成部を設け、そのデコーダがコアエンジンにインストールされるようにする手段を設けることは、当業者であれば容易に想到できることである。
　
　したがって、引用発明１において、「デコーダ情報」に基づき、「デコーダのバイナリデータ」をダウンロードして記憶し、「デコーダ」に対応するメディア又はコンテンツが再生される構成について、上記引用例１に開示されるような、デコーダが複数のモジュールにより構築されるモジュールベースデコーダの考え方を採用し、モジュールに対応するメディアコンテンツやモジュール識別情報の構成、複数のデコーダモジュールを組合せてデコーダを生成する手段を設けることによって、補正後の発明のように、「ソフトウェアモジュールの識別情報」に基づきダウンロードして記憶し、記憶された複数の「ソフトウェアモジュール」を組合せてコーデックのコードを生成し、「ソフトウェアモジュール」に対応するマルチメディアコンテンツを処理するようにすることは、当業者であれば容易に想到できることである。
　
（ウ）相違点３についての検討
　
　プロセッサが処理を行うときには、実行コードをプロセッサにフェッチして取込み、その取り込んだコードをデコーディングによりプロセッサが解釈できるようにしてから、コードが実行されるものであることは、プロセッサの動作原理における技術常識として知られていることであるから、上記引用例１に記載されるコアエンジンにおいても、デコーダがインストールされ、コードが取り込まれた後に、デコーディングを経て実行されることは、当該技術常識から容易に導き出される事項である。
　
（エ）相違点４についての検討
　
　引用発明１では、「コンテンツ」の中に「デコーダＵＲＩ」と「デコーダ情報」が含まれるものとはされておらず、「コンテンツ」とは別に、情報サーバから、「デコーダＵＲＩ」と、各コンテンツに対応する「デコーダ情報」が提供されるものであるが、コンテンツとともに、デコーダをダウンロードするためのサーバの位置情報を提供することは、例えば、特表２００６−５１１９０２号公報の第１頁の要約に開示されているように、既に知られているような考え方であり、また、コンテンツの中にデコーダを識別するための情報が含まれるようにすることも、例えば、特開２００１−２０２０９４号公報の図８、４４〜４５段落に開示されるように、既に知られているような考え方である。
　引用発明１においても、デコーダサーバのＵＲＩやデコーダ情報は、コンテンツに対応づけられて提供されているものであり、該コンテンツとは別体で提供されるデコーダサーバのＵＲＩやデコーダ情報を、コンテンツに含まれるようにすることで、該コンテンツについてのデコーダサーバのＵＲＩとデコーダ情報の対応付けを行って、一体的に情報を提供しようとすることは、当業者が当然行おうとすることであると考えられるから、引用発明１における、「デコーダＵＲＩ」及び「デコーダ情報」に、上記公知技術に係る考え方を採用することで、補正後の発明のように、「マルチメディアコンテンツ」に「コーデックサーバの位置情報」とコーデックの識別情報を含むように構成することは、当業者であれば容易に想到できることである。
　なお、コーデックの識別情報を、「ソフトウェアモジュールの識別情報」とすることは、相違点２で検討したとおりである。
　
（オ）発明の効果について
　
　なお、補正後の発明が奏する効果についても、いずれも引用発明１、上記公知文献及び技術常識により想到される上記構成から、当然に予測される程度のものにすぎず、格別顕著なものではない。
　
（カ）したがって、上記（ア）〜（オ）から、補正後の発明は引用発明１、上記公知文献及び技術常識に基づいて容易に発明をすることができたものであるから、特許法第２９条第２項の規定により、特許出願の際独立して特許を受けることができないものである。
　
３　むすび
　以上のとおり、補正後の発明は、特許出願の際独立して特許を受けることができないものであるから、本件補正は、平成２３年法律第６３号改正附則第２条第１８項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第６項において準用する同法第１２６条第５項の規定に適合していない。
　したがって、本件補正は、特許法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　
第３　本願発明について
　
１　本願発明
　平成２２年１０月１日付けの手続補正は上記のとおり却下されるべきものであるので、本願の特許請求の範囲に記載される事項により特定される発明は、平成２２年５月７日付け手続補正により補正された特許請求の範囲、明細書の記載からみて、上記「第２　平成２２年１０月１日付けの手続補正についての補正却下の決定」の「１　補正前と補正後の特許請求の範囲」の項中で、補正前の特許請求の範囲に記載されたとおりのものであるところ、請求項１に係る発明は、以下のとおりのものである。
　
「【請求項１】
　デジタルシグナルプロセッサ（ＤＳＰ）処理部と、
　コーデックサーバから第１のソフトウェアモジュールをダウンロードする手段と、
　ダウンロードされた第１のソフトウェアモジュールと、少なくとも第２のソフトウェアモジュールとを記憶する記憶部と、
　前記記憶された第１と第２のソフトウェアモジュールを組合せてＤＳＰコードを生成し、前記ＤＳＰ処理部にロードするＤＳＰコード生成部と、を有し、
　前記ＤＳＰ処理部は前記ロードされたＤＳＰコードをデコーディングして、前記第１のソフトウェアモジュールに対応するマルチメディアコンテンツを処理することを特徴とする装置。」（以下、「本願発明」という。）
　
２　引用発明１
　これに対して、原審の拒絶理由に引用された引用例１および引用発明１は、上記「第２　平成２２年１０月１日付けの手続補正についての補正却下の決定」の「２　補正の適否」の「（２）独立特許要件」の「イ　引用例１」の項中で認定したとおりである。
　
３　対比
　本願発明は、上記「第２　平成２２年１０月１日付けの手続補正についての補正却下の決定」の「２　補正の適否」の「（１）新規事項の有無、補正の目的要件」の項中で検討したように、補正後の発明から、本件補正に係る構成の限定を省いたものであるから、以下のように対比される。
　
（１）本願発明と、引用発明１とを対比する。
　
　ア　「デジタルシグナルプロセッサ（ＤＳＰ）処理部」について
　
　上記「第２　平成２２年１０月１日付けの手続補正についての補正却下の決定」の「２　補正の適否」の「（２）独立特許要件」の「ウ　対比」における（ア）のａの検討と同様に、
　本願発明の「デジタルシグナルプロセッサ（ＤＳＰ）処理部」と、引用発明１の「コアエンジン」は、 処理部 の機能を有している点で一致し、
　本願発明は、「デジタルシグナルプロセッサ（ＤＳＰ）」により処理が行われるものであるのに対し、引用発明１では、デジタルシグナルプロセッサ（ＤＳＰ）により処理が行われるものとはされていない点で相違する。
　
　イ　「コーデックサーバから第１のソフトウェアモジュールをダウンロードする手段」について
　
　上記「第２　平成２２年１０月１日付けの手続補正についての補正却下の決定」の「２　補正の適否」の「（２）独立特許要件」の「ウ　対比」における（ア）のｂの検討と同様に、
　本願発明の「コーデックサーバから第１のソフトウェアモジュールをダウンロードする手段」は、引用発明１の「デコーダサーバからデコーダのバイナリデータをダウンロードするデコーダ・コンポーネント管理エンジン」と、 コーデックサーバからコーデックのバイナリデータをダウンロードする手段 である点で一致し、
　本願発明では、「第１のソフトウェアモジュール」がダウンロードされるのに対し、引用発明１では、「デコーダのバイナリデータ」がダウンロードされる点、
　また、本願発明では、複数の「ソフトウェアモジュール」を組合せてコーデックのＤＳＰコードが生成されるものであるのに対し、引用発明１では、複数のソフトウェアモジュールを組合せてコーデックのコードを生成することとはされていない点
　で、それぞれ相違する。
　
　ウ　「ダウンロードされた第１のソフトウェアモジュールと、少なくとも第２のソフトウェアモジュールとを記憶する記憶部」について
　
　上記「第２　平成２２年１０月１日付けの手続補正についての補正却下の決定」の「２　補正の適否」の「（２）独立特許要件」の「ウ　対比」における（ア）のｃの検討と同様に、
　本願発明の「ダウンロードされた第１のソフトウェアモジュールと、少なくとも第２のソフトウェアモジュールとを記憶する記憶部」は、引用発明１の「ダウンロードされた複数のデコーダの管理をするデコーダ・コンポーネント管理エンジン」と、 ダウンロードされた複数のコーデックのバイナリデータを記憶する記憶部 を有する点で一致し、
　本願発明では、「第１のソフトウェアモジュール」を記憶するのに対し、引用発明１では、「デコーダ」を記憶する点で相違する。
　
　エ　「前記記憶された第１と第２のソフトウェアモジュールを組合せてＤＳＰコードを生成し、前記ＤＳＰ処理部にロードするＤＳＰコード生成部」について
　
　上記「第２　平成２２年１０月１日付けの手続補正についての補正却下の決定」の「２　補正の適否」の「（２）独立特許要件」の「ウ　対比」における（ア）のｄの検討と同様に、
　本願発明の「前記記憶された第１と第２のソフトウェアモジュールを組合せてＤＳＰコードを生成し、前記ＤＳＰ処理部にロードするＤＳＰコード生成部」は、引用発明１の「デコーダは、コアエンジンでインストールされ」る点と、 コーデックのバイナリデータを実行コードとして処理部にロードする手段 を有する点で一致し、
　本願発明では、「記憶された第１と第２のソフトウェアモジュールを組合せてＤＳＰコードを生成」するものであるのに対し、引用発明１では、複数のソフトウェアモジュールを組合せてデコーダのコードを生成することとはされていない点、
　本願発明では、「デジタルシグナルプロセッサ（ＤＳＰ）」による実行コードであるのに対し、引用発明１では、デジタルシグナルプロセッサ（ＤＳＰ）による実行コードであるとはされていない点
　で、それぞれ相違する。
　
　オ　「前記ＤＳＰ処理部は前記ロードされたＤＳＰコードをデコーディングして、前記第１のソフトウェアモジュールに対応するマルチメディアコンテンツを処理する」について
　
　上記「第２　平成２２年１０月１日付けの手続補正についての補正却下の決定」の「２　補正の適否」の「（２）独立特許要件」の「ウ　対比」における（ア）のｅの検討と同様に、
　本願発明の「前記ＤＳＰ処理部は前記ロードされたＤＳＰコードをデコーディングして、前記第１のソフトウェアモジュールに対応するマルチメディアコンテンツを処理」する点は、引用発明１の「コアエンジンは、メディアの再生を行」う点と、 処理部は、ロードされた実行コードによりコーデックのバイナリデータに対応するマルチメディアコンテンツを処理する 点で一致し、
　本願発明では、「デジタルシグナルプロセッサ（ＤＳＰ）」により処理が行われものであるのに対し、引用発明１では、デジタルシグナルプロセッサ（ＤＳＰ）により処理が行われるものとはされていない点、
　本願発明では、「ソフトウェアモジュール」に対応するマルチメディアコンテンツを処理するものであるのに対し、引用発明１では、「デコーダ」に対応するメディアが再生されるものである点、
　本願発明では、ＤＳＰ処理部は、ロードされたＤＳＰコードを「デコーディング」して処理を実行するのに対し、引用発明１では、コアエンジンが、読み込まれた実行コードをデコーディングするものとはされていない点
　で、それぞれ相違する。
　
　カ　「装置」について
　
　本願発明の「装置」は、デジタルシグナルプロセッサ（ＤＳＰ）処理部と、ソフトウェアモジュールをダウンロードする手段と、ダウンロードしたソフトウェアモジュールを記憶する記憶部と、ソフトウェアモジュールの組合せてＤＳＰコードを生成し、ＤＳＰ処理部にロードするＤＳＰコード生成部と、を有し、マルチメディアコンテンツを再生する装置であるところ、
　引用発明１の「クライアント」も、コアエンジンと、デコーダ・コンポーネント管理エンジンを有し、コンテンツを再生させる装置である。
　ここで、引用発明１の「コアエンジン」は、上記 ア のとおり、本願発明の「デジタルシグナルプロセッサ（ＤＳＰ）処理部」と、「処理部」の機能を有する点で一致し、上記 エ のとおり、本願発明の「ＤＳＰコード生成部」と、「ロードする手段」をする点で一致しており、引用発明１の「デコーダコンポーネント管理エンジン」は、上記 イ、ウ のとおり、本願発明の「ダウンロードする手段」、「記憶部」の機能をそれぞれ有しているから、
　本願発明の「装置」は、引用発明１の「クライアント」と、同様な機能を持つ装置として一致している。
　
（２）よって、上記ア〜カから、本願発明と引用発明１は、以下の点で一致し、また相違している。
　
　（一致点）
　「処理部と、
　コーデックサーバからコーデックのバイナリデータをダウンロードする手段と、
　ダウンロードされた複数のコーデックのバイナリデータを記憶する記憶部と、
　前記記憶されたコーデックのバイナリデータを実行コードとして処理部にロードする手段と、を有し、
　前記処理部は、前記ロードされた実行コードにより前記コーデックのバイナリデータに対応するマルチメディアコンテンツを処理する装置。」
　
　（相違点１）
　本願発明では、「デジタルシグナルプロセッサ（ＤＳＰ）」により処理が行われるものであるのに対し、引用発明１では、デジタルシグナルプロセッサ（ＤＳＰ）により処理が行われるものとはされていない点。
　
　（相違点２）
　本願発明では、「ソフトウェアモジュールの識別情報」に基づき、「ソフトウェアモジュール」をダウンロードして記憶し、記憶された複数の「ソフトウェアモジュール」を組合せてコーデックのコードを生成し、「ソフトウェアモジュール」に対応するマルチメディアコンテンツを処理するものであるのに対し、引用発明１では、「デコーダ情報」に基づき、「デコーダのバイナリデータ」をダウンロードして記憶し、「デコーダ」に対応するメディア又はコンテンツが再生されるものであり、複数のソフトウェアモジュールを組合せてデコーダのコードを生成することとはされていない点。
　
　（相違点３）
　本願発明では、ＤＳＰ処理部は、ロードされたＤＳＰコードを「デコーディング」して処理を実行するのに対し、引用発明１では、コアエンジンが、読み込まれた実行コードをデコーディングするものとはされていない点。
　
４　当審の判断
（１）上記相違点１〜相違点３についての検討
　上記「第２　平成２２年１０月１日付けの手続補正についての補正却下の決定」の「２　補正の適否」の「（２）独立特許要件」の「エ　当審の判断」において、（相違点１）から（相違点３）において示したとおり、引用発明１及び技術常識に基づいて当業者が容易に発明をすることができたものである。
　
（２）発明の効果について
　なお、本願発明が奏する効果についても、いずれも引用発明１及び技術常識により想到される上記構成から、当然に予測される程度のものにすぎず、格別顕著なものではない。
　
５　むすび
　以上のとおり、本願発明は、引用発明１及び技術常識に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　
　したがって、本願は、他の請求項について検討するまでもなく、拒絶されるべきものである。
　
　よって、結論のとおり審決する。