【事件の表示】
　特願２００８−１２６２１５「マルチメディア信号の符号化」拒絶査定不服審判事件〔平成２１年　１月２２日出願公開、特開２００９−　１７５３５〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１　経緯
　本件出願は、平成２０年５月１３日（パリ条約による優先権主張２００７年５月２５日、米国）の出願であって、平成２２年１１月１９日付けで拒絶理由の通知がなされ、これに対し、平成２３年３月１日付けで手続補正がなされたが、平成２３年５月６日付けで拒絶査定がなされたものである。
　本件は、上記拒絶査定を不服として平成２３年９月１５日付けで請求された拒絶査定不服審判であって、同日付けで手続補正（明細書、特許請求の範囲又は図面について請求と同時にする補正）がなされたものである。
　
２　補正の却下の決定
　平成２３年９月１５日付けの手続補正について次のとおり決定する。
　
〈補正の却下の決定の結論〉
　平成２３年９月１５日付けの手続補正を却下する。
　
〈補正の却下の決定の理由〉
（１）補正の内容
　平成２３年９月１５日付けの手続補正（以下、本件補正という）は、請求項４についてする次の補正を含むものである。
　
［補正前］（【請求項４】）（平成２３年３月１日付けで補正されたもの）
　外部ソースによって提供されるマルチメディア信号を符号化する方法であって、
　前記マルチメディア信号を符号化するためのコマンドを中央処理ユニット（ＣＰＵ）からグラフィックス処理ユニット（ＧＰＵ）に送るステップであって、該コマンドは、ランダムアクセス可能なシステムメモリに格納されている、該ステップと、
　前記マルチメディア信号を表す複数のデジタル値を、前記システムメモリに格納することなく、前記外部ソースから前記外部ソースに接続するインタフェースを介して、前記ＧＰＵにおいて受け取るステップであって、前記ＧＰＵは該複数のデジタル値をＧＰＵメモリに格納する、該ステップと、
　前記ＧＰＵにおいて前記複数のデジタル値を符号化して複数の符号化された値を生成するステップと、
　前記複数の符号化された値を前記ＧＰＵによって前記システムメモリに格納するステップと、
を含む方法。
　
［補正後］（【請求項４】）
　外部ソースによって提供されるマルチメディア信号を符号化する方法であって、
　前記マルチメディア信号を符号化するためのコマンドを中央処理ユニット（ＣＰＵ）からグラフィックス処理ユニット（ＧＰＵ）に送るステップであって、該コマンドは、ランダムアクセス可能なシステムメモリに格納されている、該ステップと、
　前記マルチメディア信号を表す複数のデジタル値を、前記システムメモリに格納することなく、前記外部ソースから前記外部ソースに接続するインタフェースを介して、前記ＧＰＵにおいて受け取るステップであって、前記ＧＰＵは該複数のデジタル値を前記ＧＰＵの外部に配置されたＧＰＵメモリに格納する、該ステップと、
　前記ＧＰＵにおいて前記複数のデジタル値を符号化して複数の符号化された値を生成するステップと、
　前記複数の符号化された値を前記ＧＰＵによって前記システムメモリに格納するステップと、
を含む方法。
　
　この請求項４についてする補正は、「ＧＰＵメモリ」について、「前記ＧＰＵの外部に配置された」とさらに特定するものである。
　
（２）補正の適法性
　上記のとおり、請求項４についてする補正は、「ＧＰＵメモリ」について、「前記ＧＰＵの外部に配置された」とさらに特定するものであって、特許請求の範囲の減縮を目的とする補正であると認められるから、独立特許要件について検討する。
　
　ア　補正後発明
　本件補正後の特許請求の範囲の請求項４に係る発明（以下、補正後発明という）は、上記の本件補正後の特許請求の範囲の請求項４に記載されたとおりのものと認める。
　
　イ　刊行物１
　「竹本卓　他，コンフィギュアラブルプロセッサを利用した携帯機器向け３Ｄグラフィックスプロセッサ，電子情報通信学会技術研究報告，社団法人電子情報通信学会，２００４年１０月２２日，Ｖｏｌ．１０４，Ｎｏ．３６８，ｐｐ．１〜６」（査定の理由で示した引用文献３。以下、刊行物１という）には、図、表と共に次の記載がある。
（刊行物１の記載）
　「コンフィギュアラブルプロセッサを利用した携帯機器向け３Ｄグラフィックスプロセッサ」（１頁　表題）
　
　「あらまし　３．５Ｍｐｏｌｙｇｏｎ／ｓｅｃの３ＤＣＧエンジン、１５ｆｐｓ＠ＱＶＧＡのＭＰＥＧ４　ｃｏｄｅｃエンジン、最大２ＭｐｉｘｅｌのＪＰＥＧエンジン、カメラＩ／Ｆ、ＳＤカードＩ／Ｆ、ＬＣＤＩ／Ｆ、および２０ＭｂｉｔのＤＲＡＭを１ｃｈｉｐに集積した携帯機器向けメディアプロセッサＴ４Ｇの開発について述べる。３ＤＣＧエンジンは東芝のコンフィギュアラブルプロセッサＭｅＰを応用することにより実現されている。ＤＲＡＭを内蔵したことにより、３Ｄエンジンとメモリ間のバンド幅は２Ｇｂｙｔｅ／ｓｅｃに達する。このチップでは、０．１３μｍ　ＣＭＯＳ　ＤＲＡＭ混載プロセスを使用し、２０Ｍｔｒａｎｓｉｓｔｏｒのロジックと２０ＭｂｉｔのＤＲＡＭを集積した。３ＤＣＧ処理時の最大消費電力は１７０ｍＷである。
　キーワード　コンフィギュアラブルプロセッサ，ＭｅＰ，３Ｄグラフィックス，携帯電話，メディアプロセッサ」（１頁　あらまし　および　キーワード）
　
　「１．Ｉｎｔｒｏｄｕｃｔｉｏｎ
　近年、携帯機器、特に携帯電話に対して要求される機能は飛躍的に増大し、カメラ機能、動画処理機能だけでなく、コンソールゲーム機器並みの処理能力を要する３ＤＣＧ機能が要求されるようになってきている。一方、大変コストセンシティブな市場でもあり、上記要求を満たしつつトータルコストを最小にするソリューションが求められている。
　以前、我々は携帯機器におけるＭＰＥＧ４　ｃｏｄｅｃの要求に対するソリューションとしてＴ４を開発した［１］。Ｔ４は、専用ＭＰＥＧエンジンとｅＤＲＡＭ（ｅｍｂｅｄｄｅｄ　ＤＲＡＭ）の組み合わせにより、低コスト、低消費電力で高品位な動画の圧縮・伸張機能を携帯機器にもたらした。Ｔ４は、ｅＤＲＡＭを集積したことで比較的容量の大きな内蔵メモリを持つことになった。このことは、新たな機能をＴ４に追加するときのコスト上昇を最小にする可能性がある。
　今回我々は、Ｔ４にコンソールゲーム機並みの３ＤＣＧ描画能力を追加したメディアプロセッサＴ４Ｇを開発した。Ｔ４Ｇは、Ｔ４におけるＭＰＥＧ機能と同様、外付けメモリを全く必要とせずに、高品位な３ＤＣＧ機能を実現できる。ｅＤＲＡＭはＭＰＥＧ４エンジンと３ＤＣＧエンジンで共用する。外付けメモリが不要ということは、システムコストの面だけでなく、消費電力の面でも有利といえる。
　Ｔ４Ｇにおける３Ｄ処理の一部は、東芝のコンフィギュアラブル且つ拡張可能な組み込み向けプロセッサＭｅＰ［２］［３］により実装されている。ＭｅＰをＤＳＰ拡張することにより、完全なプログラマビリティと高い３ＤＣＧ処理性能を両立することができる。このプログラマビリティにより、Ｔ４Ｇは高い抽象度のコマンドを実行することができる。このことは、低コストな携帯電話システムにおいて常に問題となる、ベースバンドプロセッサとメディアプロセッサ間の通信バンド幅不足を緩和するために重要である。
　この論文では、まず３ＤＣＧの処理過程を説明しＴ４Ｇの開発コンセプトについて述べる。次にアーキテクチャ設計過程および各ブロックの詳細について述べる。最後にチップの実装について述べる。」（１頁左欄１行〜２頁左欄２５行）
　
　「２．３Ｄグラフィックスの処理過程
　一般的な３Ｄグラフィックスシステムの処理の階層を図１に示す。アプリケーションレイヤとはゲームでいえば、シナリオの進行を制御したり、キャラクタの動作を決定したりする処理レイヤで、ゲームのメインプログラムに相当する。ＡＰＩレイヤとはアプリケーションレイヤに対してＯｐｅｎＧＬ・ＥＳ［４］等のＡＰＩを提供するレイヤで、上位レイヤからの指示に従いデータを構築、必要なパラメータを生成するとともに、各種バッファの管理、レンダリングステートの更新等を行う。頂点処理レイヤとは頂点単位の座標変換や照光処理を行うレイヤ、ピクセル処理レイヤとはピクセル単位のカラー演算を行うレイヤである。フレームバッファレイヤとはＣｏｌｏｒバッファやＺバッファといった物理的なメモリそのものを指す。一般に頂点処理レイヤから下、もしくはピクセル処理レイヤから下がハードウエア化される。また実際はハードウエアとソフトウエアの境界には、ハードウエアを抽象化するためのデバイスドライバレイヤが挿入される。
　図１において、上の層にいくほどプログラマビリティが要求される傾向がある。また、下の層にいくほど、演算処理量が増え、層間のデータトラフィックも増大する傾向がある。
　携帯電話システムでは消費電力や輻射の問題から、チップ間の通信バンド幅は著しく制限される。よって、理想的にはアプリケーションレイヤからフレームバッファレイヤまですべてが１ｃｈｉｐになっていることが望ましい。アプリケーションを実行する高速な汎用プロセッサを集積して、アプリケーションレイヤ以下を１ｃｈｉｐで提供するのは、いわゆるアプリケーションプロセッサのソリューションである。このソリューションは、大規模なソフトウエアを格納するための外付けメモリを必要とし、コストや消費電力の面からコストセンシティブなレンジの製品にはただちに適用しづらい面がある。このことからＴ４ＧではＡＰＩレイヤからフレームバッファレイヤを１ｃｈｉｐ化し、コストとパフォーマンスのバランスをとることにした。
　Ｔ４Ｇシステムではアプリケーションを実行するホストプロセッサは、演算負荷の大きい３ＤＣＧ処理やＭＰＥＧ　ｃｏｄｅｃ処理から解放される。大きなプログラムメモリが必要であるがスループットがそれほど要求されない処理はホストプロセッサｃｈｉｐで、必要なメモリ量は限られるが非常に高いスループットが求められる処理はメディアプロセッサｃｈｉｐで、という処理の切り分けがＴ４Ｇの基本コンセプトである。
　
（　図１　３Ｄグラフィックスの処理階層）
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　」
（２頁左欄２６行〜右欄２３行）
　
　「３．アーキテクチャの設計
　抽象度の高いＡＰＩを定義すれば、ホストプロセッサとＴ４Ｇ間の通信トラフィックを下げることができる。たとえば、１００トライアングルで構成された球を描画するとき、最も原始的なトライアングル描画命令しかなければ１００命令になるが、より抽象度の高い球を描画する命令があれば１命令ですむ。このような高抽象度のＡＰＩを提供するためには、ＡＰＩレイヤおよびその直下の頂点処理レイヤを担当するエンジンはプログラマブルであることが望ましい。ただし、頂点処理には非常に多くの浮動小数点演算が含まれるため、汎用の組み込みプロセッサで実用的な性能を得るのは難しい。これらのことからＴ４Ｇでは、これらのレイヤを担当するエンジンとして、コンフィギュアラブルプロセッサＭｅＰを採用した。
　ＭｅＰをＤＳＰ拡張することによりプログラマビリティと高いスループットを両立することができる。また、すでに確立されたＭｅＰＦｒａｍｅｗｏｒｋを使用できるため、ハードウエア、ソフトウエア双方の開発コストの多くを削減できる。特に今回、非常に短い開発期間しか与えられなかった我々にとって、このことは最も重要なことであった。
　
（　図２　Ｔ４Ｇのブロックダイヤグラム）
　
　Ｔ４Ｇのブロックダイヤグラムを図２に示す。３ＤエンジンはＭｅＰ　ＭｏｄｕｌｅとＲｅｎｄｅｒｉｎｇ　Ｅｎｇｉｎｅからなる。ＭｅＰ　ＭｏｄｕｌｅはＡＰＩレイヤと頂点処理レイヤ内の照光処理までを担当する。頂点処理レイヤ内のクリッピング処理とピクセル処理レイヤ以下はＲｅｎｄｅｒｉｎｇ　Ｅｎｇｉｎｅが担当し、それらはハードワイヤードロジックで実装されている。
　ｅＤＲＡＭには、ＭｅＰのプログラムコード、頂点配列、テクスチャバッファ、カラーバッファ、Ｚバッファ等を自由に配置することができる（Ｕｎｉｆｉｅｄ　Ｍｅｍｏｒｙ　Ａｒｃｈｉｔｅｃｔｕｒｅ）。ＭＰＥＧエンジン非動作時は２０Ｍｂｉｔすべてを、ＭＰＥＧエンジン動作時は１６Ｍｂｉｔが動画処理に使われてしまうので残りの４Ｍｂｉｔを、これらに割り当てることができる。
　ＭｅＰ　Ｍｏｄｕｌｅはｃｏｍｍｏｎｂｕｓを介して各デバイスを制御することができる。また、ＭｅＰ　Ｍｏｄｕｌｅ内のＤＳＰは、一般的なジオメトリエンジン（たとえば三菱のＺ３Ｄ［７］内のＤＳＰ）と異なり、汎用プロセッサにおけるコプロセッサに似た使い方ができる。これらのことから、ＭｅＰ　Ｍｏｄｕｌｅは、広く３ＤＣＧ以外の用途にも使用できるようになっている。
　ＭｅＰ　ＭｏｄｕｌｅおよびＲｅｎｄｅｒｉｎｇ　Ｅｎｇｉｎｅについて、詳細を以下に述べる。」（２頁右欄２４行〜３頁右欄１行）
　
　「３．１．ＭｅＰ　Ｍｏｄｕｌｅ．
　ＭｅＰに浮動小数点計算能力を付加する時、その方法は２種類ある。１つはＤＳＰ拡張［５］、もう１つはＶＬＩＷ拡張[５］[６］である。これらの主な違いは、データメモリに対するアクセス方法である。ＤＳＰ拡張では演算命令のオペランドに直接データメモリを指定することができる。一方、ＶＬＩＷ拡張では、演算命令のオペランドにはレジスタしか指定できない。データメモリとレジスタ間のデータ転送はｌｏａｄ／ｓｔｏｒｅ命令を別途使用しなければならない。その代わり演算命令とｌｏａｄ／ｓｏｔｒｅ命令が同時に発行できるようになっている。
　
（　表１　ＤＳＰ拡張とＶＬＩＷ拡張の評価結果）
　
　　　　　　　ＤＳＰ　　　　　　ＶＬＩＷ
サイクル数　　６９Ｃｙｃｌｅｓ　６７Ｃｙｃｌｅｓ
コードサイズ　２５２Ｂｙｔｅｓ　５３６Ｂｙｔｅｓ
ゲート規模　　５０ＫＧａｔｅｓ　５５ＫＧａｔｅｓ
　
　今回、それぞれにＩＳＡを定義し、実際に頂点処理における最内ループ部分のコードを記述して、消費サイクル数およびコードサイズを評価した。また拡張部分のゲート数についても評価した。評価に使用したコードは、１頂点について、座標変換と１平行光源の照光処理（ディフューズおよびスペキュラ）を行うコードである。これらの結果を表１に示す。
　一般的には、ＶＬＩＷアーキテクチャの方が、サイクル当たりにアクティブにできる実行ユニット数を増やしやすいので性能が高くなるが、今回の用途においてはＤＳＰアーキテクチャとさほど性能が変わらないことが分かった。一方、ＶＬＩＷはＤＳＰの２倍以上のコードサイズになる。コードサイズが大きいということは、命令キャッシュのサイズや消費電力の面で不利である。このことから我々は、ＤＳＰ拡張を選択した。
　ＤＳＰにおける演算は３２ｂｉｔ浮動小数点形式で行われる。ＤＳＰの命令には、積和、逆数、逆数ルートといった３Ｄ処理でよく使われる命令に加え、さまざまな型変換命令を用意した。標準の３２ｂｉｔ浮動小数点形式だけでなく、８ｂｉｔ，１６ｂｉｔ，３２ｂｉｔの固定小数点形式および１６ｂｉｔ浮動小数点形式を柔軟に利用できるようになっている。このことは、さまざまな頂点フォーマットへの対応を容易にするだけでなく、８ｂｉｔや１６ｂｉｔの形式を積極的に使用することで、頂点バッファのサイズおよびベースバンドプロセッサとＴ４Ｇ間の通信トラフィックを節約することに役立つ。
　
（　図３　ＭｅＰ　Ｍｏｄｕｌｅのブロックダイヤグラム）
　
（　図４　ＤＳＰのパイプライン構造）
　
　ＭｅＰ　Ｍｏｄｕｌｅのブロックダイヤグラムを図３に、ＤＳＰのパイプライン構図を図４にそれぞれ示す。図３において、新規に開発したユーザー拡張モジュールはＤＳＰ，ＲＥＩＦ，ＢｕｓＢｒｉｄｇｅの３つである。それ以外はＭｅＰ　Ｆｒａｍｅｗｏｒｋ内で用意されている標準ＩＰである。
　ＲＥＩＦはＲｅｎｄｅｒｉｎｇ　Ｅｎｇｉｎｅに頂点処理後のデータを転送する機能を持つ。ＢｕｓＢｒｉｄｇｅは各バス間のプロトコル変換を行う機能を持つ。
　３ＤＣＧ処理時のデータの流れの例を以下に述べる。まずＤＭＡＣがｅＤＲＡＭ上にある頂点配列をＭｅＰコア内のデータメモリ（Ｄｍｅｍ）に転送する。次に、ＤＳＰがＤｍｅｍ内の頂点列に対して座標変換処理や照光処理を施す。変換後の頂点列は、ＲＥＩＦとＤＭＡＣにより、ＤｍｅｍからＲｅｎｄｅｒｉｎｇ　Ｅｎｇｉｎｅに転送される。ＤＳＰによる演算処理とＤＭＡＣによるデータ転送は同時に動作する。したがって、ＤＳＰはその性能をほぼ１００％発揮することができる。ＭｅＰアーキテクチャでは、Ｍｅｐ　Ｍｏｄｕｌｅ内に高速なローカルバスが定義されている。このため、ＲＥＩＦとＤＭＡＣは、グローバルバスに負荷をかけずに、効率よく変換後の頂点をＲｅｎｄｅｒｉｎｇ　Ｅｎｇｉｎｅに渡すことができる。
　このＭｅＰ　Ｍｏｄｕｌｅの頂点処理の性能は、照光処理なしの場合およそ３．５Ｍ　Ｖｅｒｔｅｘ／ｓｅｃ（＠１２５ＭＨｚ）、１平行光源の照光処理を行う場合およそ１．５Ｍ　Ｖｅｒｔｅｘ／ｓｅｃ（＠１２５ＭＨｚ）である。」（３頁右欄２行〜４頁右欄９行）
（刊行物１の記載、以上）
　
　以上の記載によると、刊行物１には、
　「以前、我々は携帯機器におけるＭＰＥＧ４　ｃｏｄｅｃの要求に対するソリューションとしてＴ４を開発した［１］。Ｔ４は、専用ＭＰＥＧエンジンとｅＤＲＡＭ（ｅｍｂｅｄｄｅｄ　ＤＲＡＭ）の組み合わせにより、低コスト、低消費電力で高品位な動画の圧縮・伸張機能を携帯機器にもたらした。Ｔ４は、ｅＤＲＡＭを集積したことで比較的容量の大きな内蔵メモリを持つことになった。・・・
　今回我々は、Ｔ４にコンソールゲーム機並みの３ＤＣＧ描画能力を追加したメディアプロセッサＴ４Ｇを開発した。Ｔ４Ｇは、Ｔ４におけるＭＰＥＧ機能と同様、外付けメモリを全く必要とせずに、高品位な３ＤＣＧ機能を実現できる。ｅＤＲＡＭはＭＰＥＧ４エンジンと３ＤＣＧエンジンで共用する。外付けメモリが不要ということは、システムコストの面だけでなく、消費電力の面でも有利といえる。」
　との記載から、
　「専用ＭＰＥＧエンジンとｅＤＲＡＭ（ｅｍｂｅｄｄｅｄ　ＤＲＡＭ）の組み合わせにより、低コスト、低消費電力で高品位な動画の圧縮・伸張機能を携帯機器にもたらした」「Ｔ４にコンソールゲーム機並みの３ＤＣＧ描画能力を追加したメディアプロセッサＴ４Ｇ」に関する技術が記載されている。
　この「Ｔ４Ｇ」は、「Ｔ４」に「３ＤＣＧ描画能力を追加した」ものであり、「Ｔ４」が有する「専用ＭＰＥＧエンジンとｅＤＲＡＭ（ｅｍｂｅｄｄｅｄ　ＤＲＡＭ）の組み合わせにより、低コスト、低消費電力で高品位な動画の圧縮・伸張機能」を有するものである。このことは、図２に図示される「Ｔ４Ｇのブロックダイヤグラム」に「ＭＰＥＧ４エンジン」が示されていることにも現れている。
　また、「Ｔ４におけるＭＰＥＧ機能と同様、外付けメモリを全く必要とせずに、高品位な３ＤＣＧ機能を実現できる。」との記載から、「Ｔ４Ｇ」の「ＭＰＥＧ機能」は、「Ｔ４」と同様に「外付けメモリを全く必要とせずに」「機能を実現できる。」ものいえる。
　したがって、「Ｔ４Ｇ」は「専用ＭＰＥＧエンジンとｅＤＲＡＭ（ｅｍｂｅｄｄｅｄ　ＤＲＡＭ）の組み合わせにより、低コスト、低消費電力で高品位な動画の圧縮・伸張機能を携帯機器にもたら」すものであり、「外付けメモリを全く必要とせずに」「機能を実現できる」「ＭＰＥＧ機能」を有するといえる。
　
　この「Ｔ４Ｇ」の「ＭＰＥＧ機能」は「動画の圧縮・伸張機能」といえ、「専用ＭＰＥＧエンジン」すなわち図２の「ＭＰＥＧ４エンジン」によって実現されるものと認められる。
　この「ＭＰＥＧ４エンジン」は、図２によると、
　「カメラＩ／Ｆ」に接続され、
　「ｃｏｍｍｏｎ　ｂｕｓ」を介して「Ｈｏｓｔ　Ｉ／Ｆ」に接続され、
　「ｍｅｍｏｒｙ　ｂｕｓ」を介して「ｅＤＴＡＭ」に接続される。
　
　「携帯電話システムでは消費電力や輻射の問題から、チップ間の通信バンド幅は著しく制限される。よって、理想的にはアプリケーションレイヤからフレームバッファレイヤまですべてが１ｃｈｉｐになっていることが望ましい。アプリケーションを実行する高速な汎用プロセッサを集積して、アプリケーションレイヤ以下を１ｃｈｉｐで提供するのは、いわゆるアプリケーションプロセッサのソリューションである。このソリューションは、大規模なソフトウエアを格納するための外付けメモリを必要とし、コストや消費電力の面からコストセンシティブなレンジの製品にはただちに適用しづらい面がある。このことからＴ４ＧではＡＰＩレイヤからフレームバッファレイヤを１ｃｈｉｐ化し、コストとパフォーマンスのバランスをとることにした。
　Ｔ４Ｇシステムではアプリケーションを実行するホストプロセッサは、演算負荷の大きい３ＤＣＧ処理やＭＰＥＧ　ｃｏｄｅｃ処理から解放される。大きなプログラムメモリが必要であるがスループットがそれほど要求されない処理はホストプロセッサｃｈｉｐで、必要なメモリ量は限られるが非常に高いスループットが求められる処理はメディアプロセッサｃｈｉｐで、という処理の切り分けがＴ４Ｇの基本コンセプトである。」
　と記載され、
　「Ｔ４Ｇ」は「ＡＰＩレイヤからフレームバッファレイヤを１ｃｈｉｐ化し」たものであり、
　また、「Ｔ４Ｇシステムではアプリケーションを実行するホストプロセッサは、演算負荷の大きい３ＤＣＧ処理やＭＰＥＧ　ｃｏｄｅｃ処理から解放される。」ことから、この「Ｔ４Ｇ」を含む「Ｔ４Ｇシステム」が認められ、「Ｔ４Ｇシステム」は「アプリケーションを実行するホストプロセッサ」を有するものであることが認められる。この「アプリケーションを実行するホストプロセッサ」は「演算負荷の大きい３ＤＣＧ処理やＭＰＥＧ　ｃｏｄｅｃ処理から解放される。」とされることから、「ＭＰＥＧ　ｃｏｄｅｃ処理」（動画の圧縮・伸張機能）は上記したように「Ｔ４Ｇ」の「ＭＰＥＧ４エンジン」によってなされるといえ、「アプリケーションを実行するホストプロセッサ」は「ＭＰＥＧ　ｃｏｄｅｃ処理」（動画の圧縮・伸張機能）を行わないといえる。
　
　「Ｔ４Ｇのブロックダイヤグラムを図２に示す。３ＤエンジンはＭｅＰ　ＭｏｄｕｌｅとＲｅｎｄｅｒｉｎｇ　Ｅｎｇｉｎｅからなる。ＭｅＰ　ＭｏｄｕｌｅはＡＰＩレイヤと頂点処理レイヤ内の照光処理までを担当する。頂点処理レイヤ内のクリッピング処理とピクセル処理レイヤ以下はＲｅｎｄｅｒｉｎｇ　Ｅｎｇｉｎｅが担当し、それらはハードワイヤードロジックで実装されている。
　ｅＤＲＡＭには、ＭｅＰのプログラムコード、頂点配列、テクスチャバッファ、カラーバッファ、Ｚバッファ等を自由に配置することができる（Ｕｎｉｆｉｅｄ　Ｍｅｍｏｒｙ　Ａｒｃｈｉｔｅｃｔｕｒｅ）。ＭＰＥＧエンジン非動作時は２０Ｍｂｉｔすべてを、ＭＰＥＧエンジン動作時は１６Ｍｂｉｔが動画処理に使われてしまうので残りの４Ｍｂｉｔを、これらに割り当てることができる。」
　と記載されており、「ＭＰＥＧエンジン動作時は１６Ｍｂｉｔが動画処理に使われてしまう」ことから、「ＭＰＥＧ４エンジン」は「動画処理」に「ｅＤＲＡＭ」を「１６Ｍｂｉｔ」使用する、すなわち、「ＭＰＥＧ４エンジン」は「ｅＤＲＡＭ」を使用して「動画処理」を行うと認められる。
　
　これらのことから、刊行物１に、「Ｔ４Ｇシステム」において「動画処理」特に動画の圧縮を行う技術を認めることができる。
　「Ｔ４Ｇシステム」は、「アプリケーションを実行するホストプロセッサ」、「メディアプロセッサＴ４Ｇ」を有する。
　「Ｔ４Ｇ」は、「ＭＰＥＧ４エンジン」を有し、
　「ＭＰＥＧ４エンジン」は、「カメラＩ／Ｆ」に接続され、「ｃｏｍｍｏｎ　ｂｕｓ」を介して「Ｈｏｓｔ　Ｉ／Ｆ」に接続され、「ｍｅｍｏｒｙ　ｂｕｓ」を介して「ｅＤＴＡＭ」に接続され、「外付けメモリを全く必要とせずに」「ｅＤＲＡＭ」を使用して動画の圧縮を行う。
　「ホストプロセッサ」は動画の圧縮を行わない。
　
　以上から、刊行物１には、「Ｔ４Ｇシステム」において動画の圧縮を行う技術が認められ、これを刊行物１に記載された発明（以下、「刊行物１発明」ともいう）として、次のとおり認める。
　
［刊行物１発明］
　「アプリケーションを実行するホストプロセッサ」、「メディアプロセッサＴ４Ｇ」を有する「Ｔ４Ｇシステム」において動画の圧縮を行う技術であって、
　「Ｔ４Ｇ」は、「ＭＰＥＧ４エンジン」を有し、
　「ＭＰＥＧ４エンジン」は、「カメラＩ／Ｆ」に接続され、「ｃｏｍｍｏｎ　ｂｕｓ」を介して「Ｈｏｓｔ　Ｉ／Ｆ」に接続され、「ｍｅｍｏｒｙ　ｂｕｓ」を介して「ｅＤＴＡＭ」に接続され、「外付けメモリを全く必要とせずに」「ｅＤＲＡＭ」を使用して動画の圧縮を行い、
　「ホストプロセッサ」は動画の圧縮を行わない
　動画を圧縮する技術。
　
　ウ　対比
　補正後発明と刊行物１発明とを対比する。
　
　（ア）　「外部ソースによって提供されるマルチメディア信号を符号化する方法」
　
　刊行物１発明は、動画を圧縮する技術であるところ、この動画を圧縮する技術は、「Ｔ４Ｇ」を有するシステムを用いて動画を圧縮する方法と捉えることもできる。
　刊行物１発明は、「Ｔ４Ｇ」（「ＭＰＥＧ４エンジン」）において、動画の圧縮がなされるものであるところ、この「動画の圧縮」は、「ＭＰＥＧ４エンジン」が行うのであって、刊行物１で「ＭＰＥＧ　ｃｏｄｅｃ処理」とも説明されることから、動画を「符号化する」ということができる。
　刊行物１発明でこの「符号化する」対象となる動画について、刊行物１に直接的な記載はなく、どの「動画」を「符号化する」対象とするのか特定できない。しかし、刊行物１発明で「符号化する」対象の動画は、なんらかの「信号」とはいい得る。
　したがって、補正後発明と刊行物１発明とは
　「信号を符号化する方法」という点で一致し、
　「符号化する」対象の「信号」が、
　補正後発明では、「外部ソースによって提供されるマルチメディア信号」であることに対し、
　刊行物１発明は、そうでない点で相違する。
　
　（イ）　「前記マルチメディア信号を符号化するためのコマンドを中央処理ユニット（ＣＰＵ）からグラフィックス処理ユニット（ＧＰＵ）に送るステップであって、該コマンドは、ランダムアクセス可能なシステムメモリに格納されている、該ステップ」
　
　刊行物１発明の「Ｔ４Ｇシステム」は、「アプリケーションを実行するホストプロセッサ」を有しており、「ホストプロセッサ」は、「Ｔ４Ｇシステムではアプリケーションを実行するホストプロセッサは、演算負荷の大きい３ＤＣＧ処理やＭＰＥＧ　ｃｏｄｅｃ処理から解放される。」と説明されることから、元々は「ＭＰＥＧ　ｃｏｄｅｃ処理から解放され」ておらず、すなわち、「ＭＰＥＧ　ｃｏｄｅｃ処理」を行っていたものであり、この「Ｔ４Ｇ」を用いた「Ｔ４Ｇシステム」とすることで「ＭＰＥＧ　ｃｏｄｅｃ処理から解放され」るものとなったものといえ、また、「Ｔ４Ｇ」は、「ホストプロセッサ」の行っていた「ＭＰＥＧ　ｃｏｄｅｃ処理」を「ホストプロセッサ」に代わって行う「メディアプロセッサ」といわれる「プロセッサ」であり、「ホストプロセッサ」に代わって「ＭＰＥＧ　ｃｏｄｅｃ処理」を含む「メディア」に関する処理を行い、「ホストプロセッサ」の処理を助ける「プロセッサ」ということができる。
　この「ホストプロセッサ」と「Ｔ４Ｇ」との関係は、「ホストプロセッサ」が「中央処理」のプロセッサであり、「Ｔ４Ｇ」が「中央処理」のプロセッサを助ける周囲のプロセッサという関係であると認められる。
　
　補正後発明における、「中央処理ユニット（ＣＰＵ）」と「グラフィックス処理ユニット（ＧＰＵ）」との関係は、刊行物１発明の「ホストプロセッサ」と「Ｔ４Ｇ」と同様に、「中央処理」のプロセッサとそれを助ける周囲のプロセッサという関係であると認められ、補正後発明の「中央処理ユニット（ＣＰＵ）」と「グラフィックス処理ユニット（ＧＰＵ）」は、刊行物１発明の「ホストプロセッサ」と「Ｔ４Ｇ」と対応するものと認められる。そして、刊行物１発明の「ホストプロセッサ」は、「Ｔ４Ｇ」との上記関係だけでなく、「アプリケーションを実行する」ものであって、「Ｔ４Ｇシステム」として、例えば、刊行物１において想定される携帯電話において、中心的な処理を行うプロセッサとなるものと認められるから、中央処理ユニット（ＣＰＵ）いい得る。また、刊行物１発明の「Ｔ４Ｇ」は、「メディアプロセッサ」とされ、「ＭＰＥＧ　ｃｏｄｅｃ処理」を行うものであって、動画の処理を行うものであり、刊行物１では３Ｄ処理をもすると説明されており、「グラフィックス処理」を行う「プロセッサ」といえ、すなわち、「グラフィックス処理ユニット（ＧＰＵ）」といい得る。
　
　そうすると、補正後発明と刊行物１発明とは、いずれも、「中央処理ユニット（ＣＰＵ）」と「グラフィックス処理ユニット（ＧＰＵ）」を有するといえ、この点で一致する。
　
　もっとも、補正後発明は、
　「前記マルチメディア信号を符号化するためのコマンドを中央処理ユニット（ＣＰＵ）からグラフィックス処理ユニット（ＧＰＵ）に送るステップであって、該コマンドは、ランダムアクセス可能なシステムメモリに格納されている、該ステップ」を含むところ、
　刊行物１発明は、そうでない点で相違する。
　
　（ウ）　「前記マルチメディア信号を表す複数のデジタル値を、前記システムメモリに格納することなく、前記外部ソースから前記外部ソースに接続するインタフェースを介して、前記ＧＰＵにおいて受け取るステップであって、前記ＧＰＵは該複数のデジタル値を前記ＧＰＵの外部に配置されたＧＰＵメモリに格納する、該ステップ」
　
　刊行物１発明において、「Ｔ４Ｇ」は「ＭＰＥＧ４エンジン」により動画の圧縮を行なうのであり、（ア）で述べたとおり、「信号」を符号化するといえるところ、「Ｔ４Ｇ」は、符号化の対象となるその信号を、「Ｔ４Ｇ」の外部から取得して符号化を行うことを想定するものといえ、「Ｔ４Ｇ」は、符号化の対象を受け取るものと認められる。そして、「Ｔ４Ｇ」の外部から「受け取る」ために、当然にインターフェイスを介するといえ、具体的には「カメラＩ／Ｆ」もしくは「Ｈｏｓｔ　Ｉ／Ｆ」を介することとなるものと認められる。
　
　補正後発明において、「前記ＧＰＵにおいて受け取る」「前記マルチメディア信号を表す複数のデジタル値」は、符号化の対象といえ、刊行物１発明において「Ｔ４Ｇ」が受け取るものと認められる符号化の対象と対応するといえる。
　そうであるから、補正後発明と刊行物１発明とは、共に「符号化の対象を、インタフェースを介して、前記ＧＰＵにおいて受け取るステップ」を含むといえ、この点で一致する。
　
　また、刊行物１発明は「「ｅＤＲＡＭ」を使用して動画の圧縮を行」うのであり、この「ｅＤＲＡＭ」は「Ｔ４Ｇ」に含まれ（図２）、「Ｔ４Ｇ」は「ＭＰＥＧ　ｃｏｄｅｃ処理」のみならず「３Ｄ」の処理もこの「ｅＤＲＡＭ」を用いて行うことから、ＧＰＵであるところの「Ｔ４Ｇ」用のメモリ、すなわち、「ＧＰＵメモリ」といいうる。
　補正後発明は、符号化の対象である「該複数のデジタル値を前記ＧＰＵの外部に配置されたＧＰＵメモリに格納する」のであり、符号化にＧＰＵメモリを使用するといえるから、補正後発明と刊行物１発明とは、共に「ＧＰＵメモリを使用して符号化を行う」といえ、この点で一致する。
　そうであるから、補正後発明と刊行物１発明とは「符号化の対象を、インタフェースを介して、前記ＧＰＵにおいて受け取り、ＧＰＵメモリを使用して符号化を行うステップ」を含む点で一致する。
　
　もっとも、
　補正後発明では、
　「符号化の対象」が「前記マルチメディア信号を表す複数のデジタル値」であって、「前記外部ソースから」受け取るものであり、
　「符号化の対象」を受け取るための「インターフェイス」が「前記外部ソースに接続する」ものであり、
　「符号化の対象」を受け取るとき、（「符号化の対象」である「前記マルチメディア信号を表す複数のデジタル値」を）「前記システムメモリに格納することなく、」受け取るものであり、
　さらに、
　「符号化の対象」である「該複数のデジタル値」を「前記ＧＰＵの外部に配置されたＧＰＵメモリに格納する」ものである
　ことに対して、
　刊行物１発明は、そうでない点で相違する。
　
　（エ）　「前記ＧＰＵにおいて前記複数のデジタル値を符号化して複数の符号化された値を生成するステップ」
　
　刊行物１発明は、「Ｔ４Ｇ」、すなわち、補正後発明でいう「前記ＧＰＵ」において、動画の符号化を行う。
　符号化を行うから、当然にその符号化の結果としての符号化データが生成されるといい得るところ、上記したように、刊行物１発明で符号化を行う対象は「前記マルチメディア信号を表す複数のデジタル値」ではなく、生成される符号化データが、そのような（符号化の対象である）「複数のデジタル値」を符号化した「複数の符号化された値」でない。
　そうであるから、補正後発明と刊行物１発明とは、共に、「前記ＧＰＵにおいて「符号化の対象」を符号化して「符号化されたデータ」を生成するステップ」を含むということができ、この点で一致する。
　もっとも、補正後発明では、「符号化の対象」が「前記複数のデジタル値」であって、「符号化されたデータ」が「複数の符号化された値」であることに対して、
　刊行物１発明は、そうでない点で相違する。
　
　（オ）　「前記複数の符号化された値を前記ＧＰＵによって前記システムメモリに格納するステップ」
　
　刊行物１発明では、符号化されたデータをいずれに格納するか特定していないから、「符号化されたデータ」（前記複数の符号化された値）「を前記ＧＰＵによって前記システムメモリに格納するステップ」を含まない。
　したがって、補正後発明が「前記複数の符号化された値を前記ＧＰＵによって前記システムメモリに格納するステップ」を含むことに対して、
　刊行物１発明は、そうでない点で相違する。
　
　（カ）　相違点の整理
　以上のとおり構成毎に対比され、補正後発明と刊行物１発明とは、
　
　「信号を符号化する方法」であって、
　「中央処理ユニット（ＣＰＵ）」と「グラフィックス処理ユニット（ＧＰＵ）」を有し、
　「符号化の対象を、インタフェースを介して、前記ＧＰＵにおいて受け取り、ＧＰＵメモリを使用して符号化を行うステップ」と、
　「前記ＧＰＵにおいて「符号化の対象」を符号化して「符号化されたデータ」を生成するステップ」と
　を含む方法。
　
　で一致し、構成毎の相違は次のとおりである。
　
　・「符号化する」対象の「信号」が、
　補正後発明では、「外部ソースによって提供されるマルチメディア信号」であることに対し、
　刊行物１発明は、そうでない点。
　
　・補正後発明は、「前記マルチメディア信号を符号化するためのコマンドを中央処理ユニット（ＣＰＵ）からグラフィックス処理ユニット（ＧＰＵ）に送るステップであって、該コマンドは、ランダムアクセス可能なシステムメモリに格納されている、該ステップ」を含むところ、
　刊行物１発明は、そうでない点。
　
　・補正後発明では、
　「符号化の対象」が「前記マルチメディア信号を表す複数のデジタル値」であって、「前記外部ソースから」受け取るものであり、
　「符号化の対象」を受け取るための「インターフェイス」が「前記外部ソースに接続する」ものであり、
　「符号化の対象」を受け取るとき、（「符号化の対象」である「前記マルチメディア信号を表す複数のデジタル値」を）「前記システムメモリに格納することなく、」受け取るものであり、
　さらに、
　「符号化の対象」である「該複数のデジタル値」を「前記ＧＰＵの外部に配置されたＧＰＵメモリに格納する」ものである
　ことに対して、
　刊行物１発明は、そうでない点。
　
　・補正後発明では、
　「符号化の対象」が「前記複数のデジタル値」であって、
　「符号化されたデータ」が「複数の符号化された値」であることに対して、
　刊行物１発明は、そうでない点。
　
　・補正後発明が「前記複数の符号化された値を前記ＧＰＵによって前記システムメモリに格納するステップ」を含むことに対して、
　刊行物１発明は、そうでない点。
　
　これら構成における相違は、技術的に次のように整理される。
　
　・補正後発明において、「符号化する」対象の「信号」がどのようなものであるか具体的に特定していることに対して、刊行物１発明が具体的に特定していないことに起因して、
　「符号化する」対象の「信号」が、補正後発明では、「外部ソースによって提供されるマルチメディア信号」であって、「前記外部ソースから」受け取るものであり、「符号化の対象」を受け取るための「インターフェイス」が「前記外部ソースに接続する」ものであり、
　補正後発明では、「符号化の対象」が「前記マルチメディア信号を表す複数のデジタル値」であり、「符号化されたデータ」が「複数の符号化された値」であることに対して、
　刊行物１発明は、そうでない点。
　
　・補正後発明において、「システムメモリ及びＧＰＵメモリの経路上のバスといったコンポーネントにおけるボトルネックを軽減する。」（本件出願明細書【０００９】）ための構成として、「ＧＰＵ１３０が、経路１３９及び１４１を使用して、受け取った未加工のデータをＧＰＵメモリ１４０に格納する。ＣＰＵ１１０が未加工のデータを最初にシステムメモリ１２０に格納してそれらをＧＰＵメモリ１４０に転送するのではなく、未加工のデータをＧＰＵメモリ１４０に直接格納することによって、システムメモリ及びＧＰＵメモリの経路上のバス等のコンポーネントにおける上述したようなボトルネックを軽減することができる。」（本件出願明細書【００３９】）と説明され、システムバス１１５のような共用バスを介して接続されず、そのようなバスを介して「符号化の対象」を受け取らないために、
　補正後発明では、「符号化の対象」を受け取るとき、（「符号化の対象」である「前記マルチメディア信号を表す複数のデジタル値」を）「前記システムメモリに格納することなく、」受け取るものであり、さらに、「符号化の対象」である「該複数のデジタル値」を「ＧＰＵメモリに格納する」ものであることに対して、
　刊行物１発明は、そうでない点。
　
　・本件出願明細書では「本説明では、未加工のデータをＧＰＵメモリ１４０に格納した後に符号化することを想定しているが、適切な修正（例えば、レジスタ等の更なるハードウェアを設けること）によって、未加工のデータをＧＰＵメモリ１４０に格納することなく符号化することができることを理解されたい。」（本件出願明細書【００４０】）と説明され、補正後発明における、「ＧＰＵメモリ」が「前記ＧＰＵの外部に配置された」ものであることの「外部に配置」とは、「適切な修正（例えば、レジスタ等の更なるハードウェアを設けること）によって、未加工のデータをＧＰＵメモリ１４０に格納することなく符号化することができる」とする「レジスタ等の更なるハードウェア」が、「レジスタ」として普通にＣＰＵ等のプロセッサの内部に設けられるように、ＧＰＵ１３０内部に設けられることに対して、ＧＰＵメモリ１４０が経路１４１を介してＧＰＵ１３０に接続されること、つまり、「システムメモリ及びＧＰＵメモリの経路上のバスといったコンポーネントにおけるボトルネックを軽減する。」ためにバスを介さないで、しかし、レジスタのようにＧＰＵの内部ではないＧＰＵの外部に接続することをいうと認められる。
　刊行物１発明では「外付けメモリを全く必要とせずに」「ｅＤＲＡＭ」を使用するのであって、また、図２においても「ｅＤＲＡＭ」は「Ｔ４Ｇ」の内部にある。
　そうであるから、「ＧＰＵメモリ」の配置に関して、補正後発明では、「ＧＰＵメモリ」が「前記ＧＰＵの外部に配置された」ものであることに対して、
　刊行物１発明は、そうでない点。
　
　・ＣＰＵとＧＰＵとの処理の関係において、ＣＰＵがＧＰＵに処理をさせ、その結果をＣＰＵが用いるようにするために、補正後発明は、
　「前記マルチメディア信号を符号化するためのコマンドを中央処理ユニット（ＣＰＵ）からグラフィックス処理ユニット（ＧＰＵ）に送るステップであって、該コマンドは、ランダムアクセス可能なシステムメモリに格納されている、該ステップ」、
　「前記複数の符号化された値を前記ＧＰＵによって前記システムメモリに格納するステップ」を含むことに対して、
　刊行物１発明は、そうでない点。
　
　エ　一致点相違点
　以上の対比によると、補正後発明と刊行物１発明との一致点、相違点は次のとおりである。
　
［一致点］
　「信号を符号化する方法」であって、
　「中央処理ユニット（ＣＰＵ）」と「グラフィックス処理ユニット（ＧＰＵ）」を有し、
　「符号化の対象を、インタフェースを介して、前記ＧＰＵにおいて受け取り、ＧＰＵメモリを使用して符号化を行うステップ」と、
　「前記ＧＰＵにおいて「符号化の対象」を符号化して「符号化されたデータ」を生成するステップ」と
　を含む方法。
　
［相違点］
（相違点１）
　補正後発明において、「符号化する」対象の「信号」がどのようなものであるか具体的に特定していることに対して、刊行物１発明が具体的に特定していないことに起因して、
　「符号化する」対象の「信号」が、補正後発明では、「外部ソースによって提供されるマルチメディア信号」であって、「前記外部ソースから」受け取るものであり、「符号化の対象」を受け取るための「インターフェイス」が「前記外部ソースに接続する」ものであり、
　補正後発明では、「符号化の対象」が「前記マルチメディア信号を表す複数のデジタル値」であり、「符号化されたデータ」が「複数の符号化された値」であることに対して、
　刊行物１発明は、そうでない点。
　
（相違点２）
　補正後発明において、「システムメモリ及びＧＰＵメモリの経路上のバスといったコンポーネントにおけるボトルネックを軽減する。」（本件出願明細書【０００９】）ための構成として、「符号化の対象」を受け取るときに「システムメモリ」「ＧＰＵメモリの経路上のバス（図１でＧＰＵメモリは経路１４１を介してＧＰＵに接続され、システムバス１１５のような共用バスを介して接続されていない。）」を介さないために、
　補正後発明では、「符号化の対象」を受け取るとき、（「符号化の対象」である「前記マルチメディア信号を表す複数のデジタル値」を）「前記システムメモリに格納することなく、」受け取るものであり、さらに、「符号化の対象」である「該複数のデジタル値」を「ＧＰＵメモリに格納する」ものであることに対して、
　刊行物１発明は、そうでない点。
　
（相違点３）
　「ＧＰＵメモリ」の配置に関して、補正後発明では、「ＧＰＵメモリ」が「前記ＧＰＵの外部に配置された」ものであることに対して、
　刊行物１発明は、そうでない点。
　
（相違点４）
　ＣＰＵとＧＰＵとの処理の関係において、ＣＰＵがＧＰＵに処理をさせ、その結果をＣＰＵが用いるようにするために、補正後発明は、
　「前記マルチメディア信号を符号化するためのコマンドを中央処理ユニット（ＣＰＵ）からグラフィックス処理ユニット（ＧＰＵ）に送るステップであって、該コマンドは、ランダムアクセス可能なシステムメモリに格納されている、該ステップ」、
　「前記複数の符号化された値を前記ＧＰＵによって前記システムメモリに格納するステップ」を含むことに対して、
　刊行物１発明は、そうでない点。
　
　オ　相違点の検討、判断
　（ア）　相違点１について
　　刊行物１において、「携帯機器、特に携帯電話に対して要求される機能は飛躍的に増大し、カメラ機能、動画処理機能だけでなく、コンソールゲーム機器並みの処理能力を要する３ＤＣＧ機能が要求されるようになってきている。」と説明されることから、「Ｔ４Ｇ」は携帯電話に用いられることが想定されており、図２における「カメラＩ／Ｆ」は、その先に携帯電話におけるカメラ機能のためのカメラを接続して用いることが容易に想到できる。
　　また、先にも述べたように、「Ｔ４Ｇシステム」における「アプリケーションを実行するホストプロセッサ」は、携帯電話において、中心的な処理を行うプロセッサとなるものと認められ、そのホストプロセッサが実行するアプリケーションとして、携帯電話のカメラ、カメラ機能を利用して、画像を取り込み利用するアプリケーションが容易に想到できる。
　　そうであるから、刊行物１発明において、圧縮（符号化）の対象として「カメラＩ／Ｆ」の先に接続されるカメラからの映像信号を容易に想到できる。
　　刊行物１発明は、
　　「ホストプロセッサ」は動画の圧縮を行わないのであり、「携帯電話システムでは消費電力や輻射の問題から、チップ間の通信バンド幅は著しく制限される。」ことから、チップ間の通信、すなわち、ホストプロセッサとＴ４Ｇとの間のＨｏｓｔ　Ｉ／Ｆを介した通信の通信量に課題があることが示唆されること、
　　Ｈｏｓｔ　Ｉ／ＦとカメラＩ／Ｆとが別にあること、
　　カメラＩ／Ｆがその名称からカメラ専用のインターフェイスであって、カメラに直接つながることを思わせること
　　から、カメラＩ／Ｆから先にカメラを接続するときの通信経路を、カメラＩ／Ｆとカメラとを直接接続することを容易に想到できるといえる。
　　そうであるから、刊行物１発明において、カメラＩ／Ｆとカメラとを直接接続し、カメラからの映像を符号化することを、当業者は容易に想到できる。その際、「Ｔ４Ｇ」がデータ処理するために、カメラから映像をデジタルデータとして送るようにすることを容易に想到できる。そして、そのようなデジタルデータが通常複数のデジタル値であることから、カメラからの映像を複数のデジタル値で送ることも自然に想到できるといえる。
　　ここで、携帯電話において、カメラは映像のソースということができ、外部にあることは明らかであって、外部ソースといい得るものであり、その映像は、多くの形態を取るマルチメディアのひとつの形態としてマルチメディア信号といい得る。また、そのような映像を符号化したとき、「複数の符号化された値」となることも普通に想到できる。
　
　　したがって、刊行物１発明を携帯電話に採用することを想定して、カメラＩ／Ｆとカメラとを直接接続して、カメラからの映像を符号化するようにし、刊行物１発明において、「符号化する」対象の「信号」を「外部ソースによって提供されるマルチメディア信号」とし、「前記外部ソースから」受け取るものとし、「符号化の対象」を受け取るための「インターフェイス」を「前記外部ソースに接続する」ものとし、「符号化の対象」を「前記マルチメディア信号を表す複数のデジタル値」とし、「符号化されたデータ」を「複数の符号化された値」とすることで、相違点１に係る補正後発明の構成とすることは、当業者が容易に想到できることといえる。
　
　（イ）　相違点２について
　　刊行物１発明は、「ホストプロセッサ」を有し、「Ｔ４Ｇ」の「Ｈｏｓｔ　Ｉ／Ｆ」の先にバスを介して接続されると普通に想到できる。同時に、「ホストプロセッサ」として通常「ＣＰＵ」といわれる中央処理プロセッサを想到し、システムメモリを用いて通常の動作を行う仕組みを想到できる。
　　上記（ア）で述べたとおり、
　　「ホストプロセッサ」は動画の圧縮を行わないのであり、「携帯電話システムでは消費電力や輻射の問題から、チップ間の通信バンド幅は著しく制限される。」ことから、チップ間の通信、すなわち、ホストプロセッサとＴ４Ｇとの間のＨｏｓｔ　Ｉ／Ｆを介した通信の通信量に課題があることが示唆されていて、刊行物１発明において、カメラＩ／Ｆとカメラとを直接接続することは容易に想到できる。そうであるから、「符号化の対象」を「前記システムメモリに格納することなく、」受け取ることを容易に想到できる。
　　「符号化の対象」を「前記マルチメディア信号を表す複数のデジタル値」とし、「符号化されたデータ」を「複数の符号化された値」とすることは上記のとおり容易に想到できることである。
　　そうであるから、刊行物１発明において、「符号化の対象」を受け取るとき、（「符号化の対象」である「前記マルチメディア信号を表す複数のデジタル値」を）「前記システムメモリに格納することなく、」受け取る構成を容易に想到できる。
　
　　刊行物１発明の「Ｔ４Ｇ」が符号化を行う「ＭＰＥＧ４エンジン」は、符号化に際して「ｅＤＲＡＭ」を使用する。どのように「ｅＤＲＡＭ」を使用するかは特定できないが、動画のＭＰＥＧによる符号化に当たって、入力されるデータが「複数のデジタル値」であって、アナログ信号のようにリアルタイムで変換処理を行えるものではなく、少なくともひとつのデジタル値としてまとまったデータを処理する必要から、受け取ったデータを一旦貯えてから貯えたデータを処理することは容易に想到でき、その際、データを貯える場所を、符号化に使用するメモリ、すなわち、記憶する場所である「ｅＤＲＡＭ」とすることは容易に想到できる。したがって、「符号化の対象」である「該複数のデジタル値」を「ＧＰＵメモリに格納する」ようにすることは容易に想到できるといえる。
　　
　　そうすると、刊行物１発明において、「符号化の対象」を受け取るとき、（「符号化の対象」である「前記マルチメディア信号を表す複数のデジタル値」を）「前記システムメモリに格納することなく、」受け取り、さらに、「符号化の対象」である「該複数のデジタル値」を「ＧＰＵメモリに格納する」ものとすることは、当業者が容易に想到できるといえる。
　
　（ウ）　相違点３について
　　刊行物１には、「Ｔ４は、ｅＤＲＡＭを集積したことで比較的容量の大きな内蔵メモリを持つことになった。このことは、新たな機能をＴ４に追加するときのコスト上昇を最小にする可能性がある。
　今回我々は、Ｔ４にコンソールゲーム機並みの３ＤＣＧ描画能力を追加したメディアプロセッサＴ４Ｇを開発した。Ｔ４Ｇは、Ｔ４におけるＭＰＥＧ機能と同様、外付けメモリを全く必要とせずに、高品位な３ＤＣＧ機能を実現できる。ｅＤＲＡＭはＭＰＥＧ４エンジンと３ＤＣＧエンジンで共用する。外付けメモリが不要ということは、システムコストの面だけでなく、消費電力の面でも有利といえる。」と記載されている。
　　ここで、「外付けメモリが不要」とする「外付けメモリ」とは、「Ｔ４は、ｅＤＲＡＭを集積したことで比較的容量の大きな内蔵メモリを持つことになった」とされる「内蔵メモリ」に対して「外付けメモリ」というと理解され、「Ｔ４」が「内蔵メモリ」を持たず「外付けメモリ」を必要とした場合、「Ｔ４」が追加されるシステムにおいて、「Ｔ４」がチップとしてＣＰＵ等が接続される共通バスに接続されて追加されると共に、「外付けメモリ」も共通バスに接続されて追加されると理解できる。このことは、このように「外付けメモリ」が共通バスに接続されて追加されることにより、「携帯電話システムでは消費電力や輻射の問題から、チップ間の通信バンド幅は著しく制限される。」と説明される「チップ間の通信」すなわち共通バスを用いた通信における消費電力の問題が、「内蔵メモリ」とすることによって「外付けメモリが不要ということは、システムコストの面だけでなく、消費電力の面でも有利といえる。」と解決されるように説明されることからも理解できる。
　　
　　刊行物１発明は、「外付けメモリを全く必要とせずに」「ｅＤＲＡＭ」を使用するものであり、図２のように「ｅＤＲＡＭ」は「Ｔ４Ｇ」に内蔵される。このことで、上記のような消費電力の問題が解決されるところ、それは、「Ｔ４Ｇ」が使用する「ｅＤＲＡＭ」がＨｏｓｔ　Ｉ／Ｆの先に想定される共通バスに接続されず、共通バスを介さずに、「Ｔ４Ｇ」が直接に使用できることにより奏する効果であることは普通に理解できる。
　　刊行物１では、
　　「ｅＤＲＡＭには、ＭｅＰのプログラムコード、頂点配列、テクスチャバッファ、カラーバッファ、Ｚバッファ等を自由に配置することができる（Ｕｎｉｆｉｅｄ　Ｍｅｍｏｒｙ　Ａｒｃｈｉｔｅｃｔｕｒｅ）。ＭＰＥＧエンジン非動作時は２０Ｍｂｉｔすべてを、ＭＰＥＧエンジン動作時は１６Ｍｂｉｔが動画処理に使われてしまうので残りの４Ｍｂｉｔを、これらに割り当てることができる。
　ＭｅＰ　Ｍｏｄｕｌｅはｃｏｍｍｏｎｂｕｓを介して各デバイスを制御することができる。また、ＭｅＰ　Ｍｏｄｕｌｅ内のＤＳＰは、一般的なジオメトリエンジン（たとえば三菱のＺ３Ｄ［７］内のＤＳＰ）と異なり、汎用プロセッサにおけるコプロセッサに似た使い方ができる。これらのことから、ＭｅＰ　Ｍｏｄｕｌｅは、広く３ＤＣＧ以外の用途にも使用できるようになっている。」
　　と説明され、「広く３ＤＣＧ以外の用途にも使用できる」「ＭｅＰ　Ｍｏｄｕｌｅ」が使用するメモリである「ｅＤＲＡＭ」は「ＭＰＥＧエンジン非動作時は２０Ｍｂｉｔすべてを、ＭＰＥＧエンジン動作時は１６Ｍｂｉｔが動画処理に使われてしまうので残りの４Ｍｂｉｔを」用いることになって、「ＭＰＥＧエンジン」と「ＭｅＰ　Ｍｏｄｕｌｅ」とが「ｅＤＲＡＭ」を共用、競合することが理解される。
　　そして、「ＭｅＰ　Ｍｏｄｕｌｅ」が「広く３ＤＣＧ以外の用途にも使用できる」とされ、今後新たな処理を「ＭｅＰ　Ｍｏｄｕｌｅ」に負わせることを当業者であれば予測するといえ、その際、新たな処理によっては現在実装している「ｅＤＲＡＭ」の容量が将来不足することが予測されるのも自然である。
　　そうであるから、「ｅＤＲＡＭ」の容量が将来不足することを想定して、将来のその時の要求に従って「ｅＤＲＡＭ」を適宜に増設又は置換できるように、外付けすることが普通に想到される。
　　しかしながら、システムとして通常のようにメモリをＨｏｓｔ　Ｉ／Ｆの先に想定される共通バスに接続すると、メモリを共通バスに接続しないことによる「Ｔ４」「Ｔ４Ｇ」の上記のような利点が失われることも、普通に理解できる。
　　そうであるから、メモリを共通バスに接続しないことによる利点を残したまま、「ｅＤＲＡＭ」を増設又は置換するために、「Ｔ４Ｇ」のｍｅｍｏｒｙ　ｂｕｓに対して、「ｅＤＲＡＭ」を外付けすることが当業者であれば容易に想到されるといえる。
　　そうすると、「ｅＤＲＡＭ」を共通バスに接続しないで「Ｔ４Ｇ」に外付けすることとなり、補正後発明と同じく、「ＧＰＵメモリ」が「前記ＧＰＵの外部に配置された」構成となる。
　　このように、補正後発明の相違点３に係る構成は、当業者が容易に想到できるといえる。
　
　（エ）　相違点４について
　　上記（ア）で述べたように、ホストプロセッサが実行するアプリケーションとして、携帯電話のカメラ、カメラ機能を利用して、画像を取り込み利用するアプリケーションが容易に想到できる。
　　そのような携帯電話のカメラ、カメラ機能を利用するアプリケーションとして、画像の取り込み、すなわち、カメラからの画像を符号化して、表示、記録、加工などの処理のために符号化後の画像データを取得することは、容易に想到できる。
　　その取得のために、アプリケーションを実行する「ホストプロセッサ」（ＣＰＵ）から符号化を行う「Ｔ４Ｇ」に必要なコマンド（例えば符号化の開始や符号化処理のオプションなど）を送り、符号化後の画像データをアプリケーションが利用できるように、アプリケーションを実行する「ホストプロセッサ」（ＣＰＵ）が利用するシステムメモリに格納させることは、容易に想到できる。
　　そして、「Ｔ４Ｇ」に送る「必要なコマンド」を、アプリケーションを実行する「ホストプロセッサ」（ＣＰＵ）が利用するシステムメモリに格納しておき、その格納しておいたコマンドを送るようにすることは、
　　ＣＰＵがシステムメモリにプログラム等を展開してそのプログラムの下で動作すること、
　　「Ｔ４Ｇ」が新たに開発されたプロセッサであり、刊行物１発明を携帯電話に採用する際に、「ホストプロセッサ」として携帯電話の従来からある「プロセッサ」を用いて、「Ｔ４Ｇ」に特化した「プロセッサ」ではないものを用いることが容易に想到されるから、新たに開発されたプロセッサである「Ｔ４Ｇ」に対するコマンドが「ホストプロセッサ」に内蔵されておらず、外部から「ホストプロセッサ」に与える必要が容易に想到できること
　　から、
　　「Ｔ４Ｇ」に対するコマンドを外部から「ホストプロセッサ」に与えるために、そのコマンドをシステムメモリに格納して「ホストプロセッサ」に使用させるようにして、容易に想到できることといえる。
　
　　ここで、符号化を行う「Ｔ４Ｇ」に必要なコマンドは「前記マルチメディア信号を符号化するためのコマンド」ということができるから、このように、「Ｔ４Ｇ」に送る「必要なコマンド」を、アプリケーションを実行する「ホストプロセッサ」（ＣＰＵ）が利用するシステムメモリに格納しておき、その格納しておいたコマンドを送るようにすることは、
　「前記マルチメディア信号を符号化するためのコマンドを中央処理ユニット（ＣＰＵ）からグラフィックス処理ユニット（ＧＰＵ）に送るステップであって、該コマンドは、ランダムアクセス可能なシステムメモリに格納されている、該ステップ」、
　「前記複数の符号化された値を前記ＧＰＵによって前記システムメモリに格納するステップ」
　ということができ、
　　補正後発明の相違点４に係る構成とすることは、当業者が容易に想到できることといえる。
　
　（オ）　総合
　　以上のとおり、相違点１ないし４に係る補正後発明の構成は、それぞれ容易に想到できるといえるところ、これらを総合した構成における補正後発明の効果も予測できると認められる。
　　したがって、補正後発明は、刊行物１に記載された発明に基づいて、当業者が容易に発明をすることができたものである。
　
　カ　独立特許要件のまとめ
　以上のとおり、本件補正後の請求項４に係る発明は、刊行物１に記載された発明に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許出願の際独立して特許を受けることができるものであるとはいえない。
　
（３）補正の却下の決定の理由のまとめ
　以上のとおり、本件補正後の請求項４に係る発明は、特許法第２９条第２項の規定により特許出願の際独立して特許を受けることができるものであるとはいえない。
　したがって、平成２３年９月１５日付けの手続補正は、平成２３年法律第６３号改正附則第２条第１８項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第６項において準用する同法第１２６条第５項の規定に違反するので、同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　よって、補正の却下の決定の結論のとおり、決定する。
　
３　本願発明
　上記のとおり、平成２３年９月１５日付けの手続補正は却下した。
　したがって、本件出願の請求項１ないし８に係る発明は、平成２３年３月１日付けで補正された特許請求の範囲の請求項１ないし８に記載されたとおりのものであり、そのうち、請求項４に係る発明（以下、本願発明という）は、次のとおりである。
　
　［本願発明］（【請求項４】）
　外部ソースによって提供されるマルチメディア信号を符号化する方法であって、
　前記マルチメディア信号を符号化するためのコマンドを中央処理ユニット（ＣＰＵ）からグラフィックス処理ユニット（ＧＰＵ）に送るステップであって、該コマンドは、ランダムアクセス可能なシステムメモリに格納されている、該ステップと、
　前記マルチメディア信号を表す複数のデジタル値を、前記システムメモリに格納することなく、前記外部ソースから前記外部ソースに接続するインタフェースを介して、前記ＧＰＵにおいて受け取るステップであって、前記ＧＰＵは該複数のデジタル値をＧＰＵメモリに格納する、該ステップと、
　前記ＧＰＵにおいて前記複数のデジタル値を符号化して複数の符号化された値を生成するステップと、
　前記複数の符号化された値を前記ＧＰＵによって前記システムメモリに格納するステップと、
を含む方法。
　
　　本願発明は、上記したように、補正後発明に対して、「ＧＰＵメモリ」について、「前記ＧＰＵの外部に配置された」の特定を削除するものである。
　
４　刊行物１
　上記［２　（２）　イ］のとおり、刊行物１発明が認められる。
　
５　対比
　本願発明と刊行物１発明とは、上記［２　（２）　ウ］と同様に対比され、本願発明と刊行物１発明との一致点、相違点は次のとおりであると認められる。なお、相違点３を欠番とした。
　
［一致点］
　「信号を符号化する方法」であって、
　「中央処理ユニット（ＣＰＵ）」と「グラフィックス処理ユニット（ＧＰＵ）」を有し、
　「符号化の対象を、インタフェースを介して、前記ＧＰＵにおいて受け取り、ＧＰＵメモリを使用して符号化を行うステップ」と、
　「前記ＧＰＵにおいて「符号化の対象」を符号化して「符号化されたデータ」を生成するステップ」と
　を含む方法。
　
［相違点］
（相違点１）
　補正後発明において、「符号化する」対象の「信号」がどのようなものであるか具体的に特定していることに対して、刊行物１発明が具体的に特定していないことに起因して、
　「符号化する」対象の「信号」が、補正後発明では、「外部ソースによって提供されるマルチメディア信号」であって、「前記外部ソースから」受け取るものであり、「符号化の対象」を受け取るための「インターフェイス」が「前記外部ソースに接続する」ものであり、
　補正後発明では、「符号化の対象」が「前記マルチメディア信号を表す複数のデジタル値」であり、「符号化されたデータ」が「複数の符号化された値」であることに対して、
　刊行物１発明は、そうでない点。
　
（相違点２）
　補正後発明において、「システムメモリ及びＧＰＵメモリの経路上のバスといったコンポーネントにおけるボトルネックを軽減する。」（本件出願明細書【０００９】）ための構成として、「符号化の対象」を受け取るときに「システムメモリ」「ＧＰＵメモリの経路上のバス（図１でＧＰＵメモリは経路１４１を介してＧＰＵに接続され、システムバス１１５のような共用バスを介して接続されていない。）」を介さないために、
　補正後発明では、「符号化の対象」を受け取るとき、（「符号化の対象」である「前記マルチメディア信号を表す複数のデジタル値」を）「前記システムメモリに格納することなく、」受け取るものであり、さらに、「符号化の対象」である「該複数のデジタル値」を「ＧＰＵメモリに格納する」ものであることに対して、
　刊行物１発明は、そうでない点。
　
（相違点４）
　ＣＰＵとＧＰＵとの処理の関係において、ＣＰＵがＧＰＵに処理をさせ、その結果をＣＰＵが用いるようにするために、補正後発明は、
　「前記マルチメディア信号を符号化するためのコマンドを中央処理ユニット（ＣＰＵ）からグラフィックス処理ユニット（ＧＰＵ）に送るステップであって、該コマンドは、ランダムアクセス可能なシステムメモリに格納されている、該ステップ」、
　「前記複数の符号化された値を前記ＧＰＵによって前記システムメモリに格納するステップ」を含むことに対して、
　刊行物１発明は、そうでない点。
　
６　判断
　上記相違点１、２、４は、補正後発明と刊行物１発明との相違点１、２、４と同じであり、上記［２　（２）　オ］と同じく判断されるから、本願発明は、刊行物１に記載された発明に基づいて、当業者が容易に発明をすることができたものである。
　
７　まとめ　むすび
　以上のとおり、本件出願の請求項４に係る発明は、刊行物１に記載された発明に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　したがって、本件出願は、残る請求項１ないし３、請求項５ないし８に係る発明について特に検討するまでもなく拒絶されるべきものである。
　よって、結論のとおり審決する。